Modelo del Dominio. El factor X.

Sin dar vueltas, un modelo del dominio es un representación gráfica de los objetos del negocio o sistema, sus relaciones y de las propiedades de estos.

Suele pasar por varias fases de evolución y desarrollo. En general, los profesionales de sistemas lo utilizan para modelar la primera memoria del sistema de información desde la nada o el caos, también suele ser utilizado para modelar los componentes del software que se desarrolla a partir del sistema de información.
El enfoque que se trabajará aquí es el que corresponde al modelado de la memoria.

Cuando se comienza un análisis, y sobre todo cuando no existe experiencia previa, puede resultar caótico comprender y desarrollar la memoria de un sistema de información. El modelo del dominio te ayudará descompactar el caos y armar las primeras bases de la memoria del sistema de información.

Para armar un modelo del dominio se necesitan encontrar objetos y la mejor manera de ir por los objetos es encontrando los sustantivos.

Importante: no todos los sustantivos encontrados sobrevivirán, tenelo muy presente.

Las reglas de negocio son las que, en primera instancia, bosquejan el modelo, y es muy importante que sean las reglas, pues resultan ser uno de los elementos mas fuertes y más restrictivos dentro del sistema que se estudia. Si la regla se mantiene, la parte del modelo que refiere a la regla se sostiene.
Las reglas en general también son proveedoras de asociaciones y de atributos. Están ahí. Se tienen que saber aprovechar.

Ejemplo
RN001: una luna gira alrededor de un planeta.
RN002: Cada luna tiene un diámetro en kilómetros.

Ambas reglas colaboran, RN001 crea 2 clases y una asociación. La regla RN002 es proveedora de un atributo.

Los requerimientos también ayudan en el modelo de dominio. De hecho también gobiernan al modelado del modelo del Dominio

Ejemplo
El sistema debe mostrar el porcentaje de diámetro entre una luna y su planeta. Resulta que el porcentaje es un cálculo (otra regla), porcentaje de diámetro de luna = diam luna / diam planeta.

El modelo del dominio es el más sensible de todos los modelos del sistema de información es impactado por cualquier omisión, olvido o error.

Antes comentamos que las asociaciones surgen de reglas, bueno no son las únicas, lamento decirlo tan en frío, pero los requerimientos también pueden proveer de asociaciones. Quizás no siempre tan directamente. 

Ejemplo
Listar los proveedores de una determinada ciudad. Esto debería implicar que entre las clases proveedor y ciudad debe existir un camino de enlaces que permite encontrar las ciudades de los proveedores ( o al revés). el requerimiento sugiere asociaciones.

Esta historia continuará

¿Cuándo termina el análisis de un sistema de información?

Una de las preguntas más comunes tiene que ver con poder responder cuando una fase se ha cumplimentado en un ciclo de desarrollo de un producto de software. 
Suele ser común que la respuesta no sea única y cuando hacemos la pregunta:
¿Cuándo termina el análisis de un sistema de información?
No resulta sencillo dar respuesta, pues depende de algunos factores. 

Requerimientos estables
El primero y más importante es haber logrado estabilizar los requerimientos del sistema con el usuario. Una tarea que no siempre resulta sencilla.

Lograr la consistencia del modelo
A pesar de haber logrado el modelo de análisis, el analista tiene que asegurar por lo menos, que hay consistencia técnica en el modelo planteado.
Esto es, que no falten requerimientos menores, que las reglas que se plantean se respeten, que la idea de solución cierre como un todo. 
Aquí se cruzan las decisiones tomadas en los diferentes modelos: Ejemplo chequear que lo que hace el sistema sea posible de acuerdo a la memoria modelada, que la memoria modelada se integre con la información que el sistema debe producir, que se encuentren todos los requerimientos que permiten mover los estados de cada objeto, entre otras. Nota: hay más de lo que uno piensa.

Nivel de detalle adecuado
En más de una ocasión se logró lo anterior, pero cuando pasa la especificación del analisis al diseño o la programación (debería primero pasar al diseño...:)); encontramos que nuestros sucesores requieren aclaraciones. Estas aclaraciones pueden resultar de una documentación pobre o incompleta, cosas que no son lo mismo.
Si el analista recibe preguntas continuamente de sus sucesores, entonces el análisis no ha terminado.

¿Qué es ser un analista de un sistema de información?

Realizar un análisis de un sistema de información es estudiar, investigar, organizar y documentar un sistema de información.

El analista debe prepararse para descubrir lo cubierto. No es un dibujante y no es un documentador, es  un comprendedor.

No copia; crea, sugiere, define y expone un sistema subyacente en una organización o negocio.

El analista de hoy recomienda e incorpora requerimientos que el usuario aún no visualiza; por lo menos los expone, luego el usuario tomará la decisión sobre si se quedan o se van. Casi siempre se quedan.

Algunos creen y es un pensamiento muy facilista que un analista tiene por objetivo documentar. Me gusta pensar que el analista deja pruebas de lo acontencido para el resto de los profesionales y del negocio respecto de los descubrimientos realizados.

El analista construye y deconstruye a la organización a partir de datos e información. Libera en su mente una sustancia llamada asociación que amalgama y teje redes entre los datos, los procesos y la información.

El analista abre los portales de un universo oculto y lo expone. Lo manifiesta. El analista, metafóricamente hablando, es un explorador de una dimensión no visible para el común de la gente.

Juntando pruebas para estimar el esfuerzo

Desde el comienzo cualquier oráculo (lease libro, incluye libros electrónicos) dirá que la estimación es una aproximación. Con esto básicamente todos los autores se lavan las manos e introducen alguno de los riesgos siguientes: subestimar o sobreestimar el esfuerzo de un proyecto de software. Estos son riesgos gemelos que nunca se verán (claro, cuando uno se presenta el otro no lo hace). 
Al estimar ya se introducen los 2 riesgos, pero uno solo se materializará. La única certeza es que uno de los 2 se hace presente. Nunca, pero nunca estimarás y concidirá con la realidad. JAMÁS. 
Superada esa necesidad de ser perfecto, como todo informático, alcanzarás el paraíso, aunque sea mientras estimás.
Lo único que podés hacer es reducir la incertidumbre, para ello debes hacer historia. Y todos sabemos que la historia se recuerda si se registra. Entonces lo que debes hacer es:

1.  Registrar la estimación, registrar los requerimientos que se estiman, los supuestos y las fuentes.
2. Monitorear tu proyecto. Hacer un registro de las circunstancias, hechos e impresiones detectadas.  Hacé un bitácora, si, una bitacora, como la de la película (film) de viaje a las estrellas.
3. Registrar el trabajo real
4. Llevar adelante un lecciones aprendidas o bien, una restrospectiva del proyecto.

Con loselementos mencionados juntarás la prueba que avalará tus decisiones.

Las pruebas según el CMMI: (esto es una visión totalmente personal, no está escrito en CMMI)

1. Nivel 1. Inicial. Arranco y dejo. Comienzo y abandono. Resultado: material incompleto. Moraleja: perdiste el tiempo; pero aprenderás. Aprenderás que así no funciona.
2. Nivel 2: generás tu historia, pero como lo haces a tu modo. Resultará útil solo para ti, pero  poco utilizada para otros. Te vuelves cada vez menos aproximado, pero nunca serás certero. Habrá quienes te crean y quienes te lean. Resultado: Tu sabes la verdad. Los desvíos son menos que en otros tiempos. Ups de repente tengo capacidades especiales (el poder X de estimar). Ojo hay otros heroes que juegan igual.
3. Nivel 3. La organización se preocupa y ocupa por cumplir los pasos mediante un mecanismo uniforme. Los datos ahora son comparables. Hay aprendizaje organizacional.
4. Nivel 4. Hay indicadores que regulan a la estimación. La organización cree en esos indicadores. Quien se corre de los indicadores es un disidente.
5. Nivel 5. Lo dejo a tu criterio.

Conclusión 
Estimar es una experiencia unica para quien cumpla con esa función, pero debe procurar aprender de sus errores o falsas visiones. Eso lo mejorará radicalmente como profesional. Los pasos son fundamentales para demostrar que soy serio al momento de hacer mi trabajo.

¿Cuál requerimiento analizo primero?

No resulta fácil distribuir el trabajo del análisis, y esto es por varias razones. 
La razón que vamos a trabajar aquí tiene que ver con las dependencias entre los requerimientos. Supóngase que tiene 10 casos de uso de usuario (no historias de usuario, hablo de casos de uso 😡) y el análisis lo tiene que distribuir entre 2 analistas o más.¿Cuáles son los casos que asigna a un analista y cuáles a otros?¿ Pueden comenzar los analistas a trabajar en paralelo?¿Debe haber una coordinación?

Para la explicación voy a plantear un ejemplo, pues transcribir el enunciado lo haría muy pesado. Estimado lector vas a tener que creerme que es así

El ejemplo trata de un sistema de información para cumplir con la meta de Realizar giras de álbumes de cantantes que los promocionan.
La matriz de dependencias de requerimientos que se plantea ( y no puede discutirse) es la siguiente:

		1.01	1.02	1.03	1.04
1.01	Definir Gira	---
1.02	Confirmar Gira	Si	---
1.03	Cerrar Gira	Si		---
1.04	Cerrar Presentación				---

¿Cómo se lee?
un cambio en el caso de uso de 1.03 afecta o impacta al caso de uso 1.01. Nota: recuerde que un caso de uso es un conjunto de requerimientos, principalmente funcionales)

Sin importar cuantos analistas hay, con la matriz de dependencias se puede evidenciar que los análisis de los casos de uso no son paralelos. Si se analiza el caso de uso 1.01, luego cuando se analice el caso de uso 1.03, el caso de uso 1.01 se modificará. 
Entonces está solución no aplica:

mientras que esta solución si:

Conclusión
La segunda programación es más realista y factible. Esto es independientemente de los recursos que se asignen.
Falta trabajar un poco más en la programación, pero esta segunda opción sin dudarlo es mejor que la primera.

Gestión de requerimientos adentro

Hoy en día nadie duda que el desarrollo de aplicaciones y especificamente el desarrollo de aplicaciones de sistemas de información resultan bastante más complejos que ayer, hace un año, 10 o 20. De esta afirmación no hay dudas.
Casi todos los desarrollos padecen del riesgo de requerimientos inestables y/o requerimientos incompletos, e independientemente del ciclo de vida en el que este basado, en el proyecto tarde o temprano volvemos sobre un requerimiento ya pensados. 
Puede parecer que la causa de esto sea que el cliente no tenga claro que necesita o una baja capacidad del analista en entender lo que el cliente intenta transmitir, pero quizás en muchos casos sea que todos estamos aprendiendo cuales son los requerimientos verdaderos. Entonces no podemos dejar de volver ya que encontramos inconsistencias o mejoras a las luz de nuevos conocimientos.
Si a lo anterior le agregamos escala o volumen, equipos de varios analistas, múltiples actores y docenas de puntos de vista, no cabe duda que alguien debe tomar el toro por las astas y guiar el trabajo, esa guía debe realizarse a través de la aplicación de la gestión de los requerimientos.

Definición: Gestionar requerimientos CMMI
El propósito de la Gestión de requerimientos (REQM) es gestionar los requerimientos de los productos y de los componentes del producto del proyecto, e identificar inconsistencias entre esos requerimientos y los planes y productos de trabajo del proyecto.

Prefiero entender las gestión de los requerimientos de la siguiente manera:

1. identificar requerimientos, 
2. determinar las relaciones que existen entre ellos, 
3. evaluar el impacto de un cambio, agregado o eliminación de un requerimiento, 
4. visualizar el cambio de alcance del desarrollo o mantenimiento,
5. controlar completitud e inconsistencas respecto de un plan de proyecto / trabajo o cualquier sinónimo del mismo y respecto de requerimientos versus requerimientos.
6. mantener la trazabilidad de las relaciones entre ellos.
7. monitorear el desarrollo de los requerimientos a lo largo de todo el proyecto y vida del producto.

Para hacer gestión se necesita un responsable. El responsable no es el lider de proyecto bajo ningún término. El responsable de la gestión de requerimiento trabajará desde la definción de los requerimientos como un lider en el analisis y verificador cuando se avance sobre otras areas/fases de desarrollo. Su rol, si se quiere es el de guardián de requerimientos. El intentará protegerlos de la exageración, el fanatismo y del olvido del resto del equipo (incluido el cliente). Algo que invariablemente sucederá.

No hacer gestión de requerimientos solo genera tensiones inútiles, inconsistencias, olvidos e incompletitudes, perdida de tiempo y perdida del por qué o para qué se hace lo que se hace.
Si en tu proyecto "mediano" no hay un responable de gestion de requerimientos al menos, considera que tenés un riesgo con alta probabilidad de ocurrencia.
No ahorrés dinero donde no conviene.