domingo, 18 de julio de 2021

Estructuras de desglose de trabajo (EDT)

Un proyecto se organiza y se diseña para cumplir con al menos un objetivo. En más de una oportunidad alcanzar este objetivo no resulta sencillo (recordemos que un proyecto es una experiencia singular); por lo que se desagrega el cumplimiento del mismo en partes más pequeñas y manejables, en donde se puedan establecer las actividades que se deben realizar para alcanzar los objetivos.

Dicho fácil alcanzar un objetivo en un proyecto es establecer un conjunto de tareas o actividades que permiten alcanzar otras metas (probablemente menores), las cuales contribuyen a alcanzar el  objetivo grande.

Cada tarea se hace por una razón y dejaran evidencia de haber pasado por ahí (habrá productos de trabajo).

Estas actividades definen la estructura de trabajo del proyecto y son una base de comunicación para con todos los involucrados.

Estimar estas actividades resulta más simple que estimar el todo y además permite visualizar qué es lo que se debe hacer para alcanzar la meta. Las fases, un mecanismo de agrupación de actividades conseguirán metas medias.

Un proyecto de software, por alguna razón, tiene sus propias complejidades ( comparándolo con proyectos de otras área de conocimiento). Entre ellas encontramos que las tareas pueden ser compartidas por varios recursos, que los recursos pueden trabajar en paralelo, que los recursos tienen diferentes roles y por lo tanto tendrán diferentes asignaciones, etc.

La EDT es interesante para ayudar a comprender el trabajo que se debe realizar, a partir de ella se pueden derivar  los roles de la mano de obra que ocupa al proyecto.


A veces se simplifica la situación y se indica que se necesitan x profesionales para realizar una tarea, pero entonces ¿qué hace cada profesional o ellos se tienen que auto gestionar? y de haber problemas ¿los x serán responsables?¿como se dirimen situaciones de conflicto? O será mejor y más claro establecer qué subtarea realiza a cada uno y que realizaron en conjunto? Es probable que a causa de esto ciertas tareas se desglosen aún más y la estructura se profundice.

Un proyecto está cargado de incertidumbres. Estas incertidumbres introducen riesgos en el proyecto.

Un líder de proyecto o un gestor de proyectos, intentará por todos los medios eliminar o reducir los riesgos.

La estructura de desglose de trabajo de un proyecto permite visualizar, las tareas que conducen a concretar los objetivos del proyecto.

Un buen diseño de EDT permite:

  1. observar que se alcanza el objetivo planteado, 

  2. planear la asignación de recursos, 

  3. establecer fases de entregas, 

  4. reducir el desvío natural que se produce en las estimaciones.


viernes, 10 de enero de 2020

Política de versionado ejemplos y tips

¿Qué es una política? Introducción

Antes que nada, cuando hablamos de políticas o de una política, estamos queriendo significar un conjunto de reglas que gobierna el objeto al que se hace referencia. Así podemos hablar de políticas de nombres, de versionado, políticas organizacionales, etc. En definitiva son reglas de negocio, pero restringido a un ámbito o temática. Otra vez, al hablar de política de versionado estamos hablando de reglas de negocio de versionado.
Las políticas ayudan y guían tus acciones y decisiones dentro de la organización respecto de la temática que tratan.
La política de empresa es un conjunto de normas o reglas establecidas por la dirección de la misma para regular diferentes apartados del funcionamiento de la empresa. 
En algunos ámbitos la política se define como el criterio o directriz de acción elegida como guía en el proceso de toma de decisiones al poner en práctica o ejecutar las estrategias, programas y proyectos específicos del nivel institucional. Siendo así la política empresarial define previamente como quiere hacer las cosas la organización, en otras palabras se diría coloquialmente: "En esta empresa se hacen las cosas de esta manera", y no importa si la empresa es del mismo rubro, del mismo sector o subsector de mercado, sus políticas pueden ser diversas. 

Politicas de versionado

La política de versionado de un producto determinado (o todos en general) deberá estar formada por un conjunto de reglas que provean a la versión del producto de cierta consistencia e integridad, no dejando fisuras en las que permeen problemas asociados con el versionado.
Podemos hablar a diferentes niveles, así por ejemplo podemos hacer referencia a políticas que afectan de las versiones de productos de software, productos de trabajo, de archivos, etc.

Veamos un ejemplo

Especificaciones de formato de versión 1.0 para el versionado de productos de software de nuestra organización.

V<nro_producto>.<nro-funcional>.<nro-correccion>.<nro-recompilacion>
...

Políticas de versionado dentro de nuestra organización.

  1. Cada producto de software utiliza como estructura de versión, la especificación de versión 1.0 para el versionado de productos de software, a partir de 01 de marzo del 2014.
  2. Cada nuevo producto se inicia con un número secuencial creciente que comienza con el 1, la primera vez. La asignación es realizada por el Área de ventas. 
  3. Cada vez que se crea un producto, todas los secciones de la especificación de versión serán 0, excepto el correspondiente al número del producto. El número de producto se incrementa en uno respecto del último número usado.
  4. Cada vez que un producto atiende una solicitud de cambio que agrega, modifica o quita funcionalidad se incrementa en un dígito la sección correspondiente a funcionalidad. A partir de esta sección el resto de las secciones que le continúan se inicializan en 0.
  5. Cada vez que se corrige un error, la sección correspondiente a corrección se incrementa en un dígito. El resto de las secciones que le continúan se inicializan en 0.
  6. Cada vez que el código se compila, este incrementa en 1 dígito la compilación. Si es la primera compilación. Se pone 0.
  7. Independientemente de la cantidad o el tamaño de la funcionalidad siempre se incrementa en 1.
  8. De cada versión de producto entregada se guarda una linea base.
  9. Se debe especificar para cada versión cual es el corrección y se debe especificar que funcionalidad se agrega, cambia o quita. No se específica porque se compila en forma obligatoria.
  10. Gerencia es el sector de la organización que determina la discontinuidad de un producto y su correspondiente congelamiento de versión. A partir de esta decisión el producto de software no evolucionará y tampoco se comercializará.

Tips para la definición de reglas de una política de versionado

  1. Cada regla debe ser independiente. Cada regla debe entenderse por si misma.
  2. Cada regla tiene un identificador.
  3. Preste atención a no poner politicas por que si.
  4. Tenga en cuenta de explicitar los valores de las secciones cuyos valores dependen de otras secciones. Ejemplo regla 5
  5. Realice “mentalmente” un ciclo de vida de cada sección o grupo de secciones, es decir, evalúe cuando nace, como evoluciona y si puede caducar, agotarse  o volverse obsoleta una sección.
  6. Se pragmático y no consuma horas de discusión en cosas que no ocurrirán en el largo plazo, sus políticas se ajustaron en el mediano plazo por otros elementos no tenidos en cuenta. 
  7. Las políticas se versionan.
  8. Las políticas se auditan.
  9. No sea purista, es probable que las políticas contengan elementos que no sean reglas de negocio estrictas, si aportan valor y no generan confusión déjelos

lunes, 6 de enero de 2020

Eliminación de datos en cascada

Cuando se realiza el análisis de un sistema de información es importante analizar la vida útil de los objetos que han fallecido o que fallecerán. Este análisis suele ser importante pues, los datos fallecidos no vuelven a ser utilizados por el sistema de información a excepción de ciertas circunstancias muy particulares, tales como: una auditoría externa, una situación legal ocurrida por un reclamo, etc.
Sabemos que los objetos forman parte de la memoria de un sistema para siempre, serán eternos. Es decisión de su creador (aunque no arbitraria) por cuanto tiempo han de quedarse eternizados estos objetos en la memoria del sistema.

¿Por cuánto tiempo mantendremos al objeto hasta que nos empiece a molestar? 
La respuesta resulta simple, cuando el objeto comience a molestar en el sistema habrá llegado el momento de eliminarlo; ten por seguro que ese momento llegará.
La molestia comienza a presentarse cuando los tiempos de respuesta del sistema implementado decae, o simplemente se presenta información que ya no tiene sentido para el usuario. No creo que sean las únicas razones, pero seguro que están presente en los sistemas implementados en software.
Imagínate que todavía pudieras vender en tu sistema de ventas disquetes de 5 ¼, o cualquier producto que no se produce más, como un cassette; o ves a ese cliente que hace años que no te compra, o esa factura que jamás fue pagada, o simplemente esa persona que trabajaba con vos, pero ya no lo hace, y aún podés asignarle trabajo desde el sistema en funcionamiento. El dato / la información no corresponde que estén presente pues, ya produce efectos que no son buenos. Suelen poner de mal humor al usuario, o incluso producir errores no pensados.
Obviamente que los datos suelen ser borrados por razones más poderosas que las mencionadas, tienen que ver con la performance. Cuando las aplicaciones que implementan los sistemas se ponen lentas, el destino es borrar los datos que no tienen utilidad. Imagínate que se producen en tu ciudad, desde tu empresa, para tus 200.000 clientes, 200.000 facturas mensuales. Luego en 10 meses tenés 1 millón, luego en 5 años tendrás 6.000.000, pero si te fue bien tendrás más. Ahora imagínate las empresas que facturan servicios y, que en muchos casos son monopolio. Imagínate un municipio generando impuestos, o en un banco el nivel de transacciones diarias de sus clientes.

Las otras razones poderosas por la que los datos se mantienen por un tiempo y, hasta que no son necesarios, está dado por restricciones legales o porque son necesarios estadísticamente, o bien, su historia produce un beneficio social a largo plazo; luego solo pensaremos en destruirlos (Los datos que se mantiene para obtener estadísticas dentro del contexto social tienen una riqueza importante para comprender las sociedades en la que vivimos o vivíamos)

¿Qué debemos tener en cuenta para eliminar datos?
Sabemos que los datos no están solos en la memoria del sistema, sino que están dentro de una red de conexiones invisibles, por lo que, al momento de destruir, el analista debe analizar no solo que se borren los datos deseados, sino que también se borren los datos y las conexiones que los sostienen, los hacen estables o permiten que otros sean estables o comprendidos. Si vas a eliminar datos no podés dejar huecos en la memoria, no podes producir islas que constituyan puertas a errores que antes no existían, simplemente no te lo podés permitir.

Ejemplo: si quiero borrar un cliente que ha realizado compras y las compras tiene diferentes pagos, entonces borrar el cliente implica borrar sus compras y los pagos de estas. Si no lo hago dejo huecos de memoria irrecuperables, compras realizadas por humanos que se desconoce quienes son….un horror.
Entonces sin más preámbulos, borrar un objeto de la memoria, implica tomar todas los datos y las conexiones cuya vida depende del objeto y borrarlas también. Es lo que comúnmente llamamos una eliminación en cascada, pero ojo que si el dato conectado te sirve entonces quizás no corresponda borrar nada.
Definir estados anulados, cancelado o fuera de línea puede ayudar a quitar el dato obsoleto sin quitarlo realmente. Manejar bajar lógicas es otra historia del análisis que suele sacar de línea objetos obsoletos. Si tu problema no es de performance puede ser una solución buena, pero solo buena; cada nuevo requerimiento deberá ser analizado a luz de no contabilizar datos obsoletos, esto aumenta la complejidad.

martes, 16 de julio de 2019

Descubriendo clases asociativas. Modelo del Dominio. Edición 2019

Indice




Notas del autor

Este apunte asume que el lector conoce la idea o concepto de tipos de objeto asociativos y ha
tenido algun tipo de experiencia básica en el uso de tipos de objetos asociativos o clases asociativas.

Tipos de objetos asociativos. Clases asociativas.

Introducción

Dentro del universo del modelo del dominio, existen un gran número de asociaciones distintas de las
asociaciones binarias o asociaciones "normales". Una de ellas, es la clase asociativas o tipo de
objeto asociativo.
Las clases asociativas ( o tipos de objetos asociativos) son clases y asociaciones a la vez. Suele ser
muy difícil darse cuenta de su presencia en las primeras iteraciones del desarrollo de un modelo
conceptual; pero a no desesperar, la experiencia ayuda a detectarlas más rápido.
La intención primaria para distinguir una clase asociativa es el hecho de la información que brinda al
lector.
A continuación, presentaré un ejemplo de tipo de objeto asociativo y su “equivalente” con
asociaciones binarias (o binarizadas).
Caso 1 de ejemplo
Un cliente realiza la solicitud de un servicio que ofrece la organización. Esta solicitud se conserva
para posteriores requerimientos de información. Veamos los diferentes modelos


Ejemplo 1.a Asociaciones y tipos de objeto asociativo


Ejemplo 1.b. Asociaciones binarizadas
Observe que:
la lectura con la clase asociativa es más robusta, ya que, si hubiera más asociaciones,
el lector no entendería que las asociaciones del ejemplo 1.b se leen en conjunto
con las clases.cuando se establece la asociación, se crea un objeto de la clase asociativa y además,
cuando se destruye un objeto, se pierde la asociación.

la existencia de los objetos de la clase asociativa depende de la existencia previa de los objetos de
las clases con los que se asocia, Estos objetos deben existir en todas las clases que participan de la
asociación del tipo de objeto asociativa.


De todos modos, las clases asociativas son fácilmente descubiertas cuando el analista tiene cierta
experiencia, por lo que también es sano, que Ud. no se torture y deje que la clase asociativa clame
por aparecer en el modelo. Nota: suelen aparecer más de un clase asociativa en un modelo real.
Aquí van algunas ideas para descubrirlas.

Descubriendo clases asociativas 

Desde atributos

Es posible que al principio no lo veas, excepto que sea casual; pero cuando comenzás a definir
atributos comienzan a visualizarse las clases asociativas. En general, primero se detecta la
asociación y luego, con los atributos se vislumbra la clase.

Ejemplos

Aquí se presentan algunos casos, pero ojo no todos derivan en clases asociativas.
Ejemplo 1. Compra Repuestos
Estamos trabajando en el modelo del dominio de un Casa de repuestos.
Un cliente compra repuestos. Un repuesto es comprado por ninguno, 1 o más clientes. El modelo del
dominio en cuestión resulta tan sencillo como se describe a continuación:




Ampliemos un poco el problema, resulta que existe un requerimiento que dice que el sistema debe
informar las compras realizadas por un cliente, cuando el director de compras lo solicite. Pensemos
el DD:
e. Sol_Cliente = CUIL
s. Compras_Cliente = datos_cliente(e) + 1{ fecha_compra + 1 {nombre-repuesto + cantidad }n}n
¿Si el modelo del dominio representa la memoria, dónde ubicaría los datos de la estructura
mencionada, la fecha-compra, nombre-repuesto y cantidad?


Recuerde que las asociaciones no pueden recordar atributo...piense.


El dato nombre-repuesto es una atributo del repuesto, pero: ¿y la fecha de compra?¿y la cantidad?
¿Son características del repuesto, o del cliente, o no corresponde a ninguno de los dos?


La conclusión es que no tiene un mejor lugar, pero son datos de la compra, pero la compra es una
asociación. Por lo que ahí tenemos la punta de la presencia de una clase-asociación, o bien, una
clase asociativa.
Ejemplo 2. Comentarios en noticias
Nuestro nuevo contexto es un diario digital. Una empresa gráfica estaba en el negocio de los
impresos, pero ahora es totalmente digital. Este hecho permite cumplir con una meta de la
organización, en donde el lector puede participar interactuando con comentarios en las noticias.
Digamos que un lector lee noticias. Un lector comenta noticias. 




¿Dónde ubicaría el comentario?
Voy a pensar en dos situaciones: 
  1. No se quien comenta pero si sobre cuál noticia y que se comenta.
  2. Se quién hace el comentario, cuál es el comentario y sobre cuál noticia.


Observe que la solución “a” no necesita una nueva clase, pero en cambio la segunda si.


Solución a




Solución b
Ejemplo 3. Inscripción
Ahora estamos en una institución educativa. Resulta que estamos pensando un sistema que permita
que el alumno se inscriba en las asignaturas. Simplemente eso, no la compliquemos más.




Ahora supongamos, que necesitamos saber cuando se produjo la inscripción para saber cuántos
anotados hay.
Obvio que necesito la fecha de inscripción. Observe que este atributo debe ser alojado en la
asociación, pero no es posible por ser asociación, entonces lo transformamos en clase asociativa.
Hasta aquí descubrimos clases asociativas a partir de la presencia de atributos.

A partir de ciclos de vida de asociaciones

Uno puede imaginar que se crea una asociación entre 2 o más objetos, entonces nace una
asociación. Si la asociación también es clase, entonces cuando nace la asociación nace al menos un
objeto que se asocia con los objetos de las otras clases. Así mismo, cuando elimino un objeto
también estoy eliminando la asociación  que los une con los objetos de las otras clases.
Los objetos del tipo asociativo están asociados al menos a 2 objetos distintos. No existe un objeto
del tipo asociativo en donde participa un solo objeto.
Un ciclo de vida de un objeto refiere al momento en que se crea un objeto  (nacimiento), su
modificación en el tiempo (evolución o crecimiento) y su destrucción o eliminación (muerte).


Un alumno hace inscripción de asignatura.


La asignatura tiene un ciclo de vida. Similar el alumno, pero qué pasa con la inscripción.
La inscripción surgió cuando quise decir algo entre alumno y asignatura, y solo sobrevivirá mientras
me interese lo que puedo decir.
Si no me interesa más lo que tengo que decir entre asignatura y alumno se tendrá que destruir la
inscripción. Luego de destruir la inscripción el alumno sigue existiendo y la asignatura también, pero
no lo que puedo decir entre ambas.


Ahora me pregunto: puedo tener una inscripción habiendo destruido su asignatura, o a su alumno.


Respuesta: NOOOOOOOOOOOOOOO


Conclusión: Inscripción es asociativo de asignatura y alumno...GRRRRR.

Síntomas para pensar...

Cuando se habla de síntomas (señal o signo de que una cosa está ocurriendo o va a ocurrir), no
implica necesariamente enfermedad. Por lo que ahora te propongo una situación especial donde se
presentan síntomas de presencia de clases asociativas. Esto es, cuando existen asociaciones cuya
multiplicidad en ambos extremos de la asociación es *, entonces alerta, puede haber presencia de
una clase asociativa. 

Errores comunes

  1. Una clase asociativa es parte (o asociativa) de dos asociaciones distintas.
  1. Una clase es asociativa de una única clase
  1. .Hacer asociativa una clase que dio origen a otra que es asociativa y esta última clase
asociativa participa de la asociación. WTF?

Historial de versiones

Fecha
Versión
Autor
Descripción
Julio-2019
1.03
ALRO
Completado de introducción. Agregado de caso 1. Agregado de errores
comunes
Marzo-2019
1.02
ALRO
Mejora de descripción de ejemplos. Armado de ejercicios relacionados para
ampliación de práctica.
Junio-2018
1.01
ALRO
Revisión de texto, adaptación de encabezados y pie de página. Agregado de
historial de versiones
Mayo-2016
1.00
ALRO
Primera versión