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.

La Documentación

Luego de muchos años de profesión como analista de sistemas , ya no me caben dudas sobre algunas cosas:

1. la documentación es sumamente importante para soportar y mantener el trabajo de un proyecto o producto
2. documentar absolutamente todo es demasiado y poco probable. En algunos casos inútil.

El reto de cualquier profesional de sistemas es el de encontrar el equilibrio sobre qué documentar, con qué grado de talle y cuándo hacerlo.

La documentación es cultural, si el profesional no documenta su obra, en mi criterio esa persona no es un profesional, es un artista hasta el primer mantenimiento y luego sin lugar a dudas un malabarista con todas las letras.

Es muy importante dejar rastro de la obra, sino la obra termina no existiendo.

Las documentación sirve para facilitar el mantenimiento y reducir las sensaciones, los conflictos y las malas interpretaciones.

Nadie lee todo y nadie sabe todo, pero existe un responsable del producto que debe tener ciertos elementos para hacer evolucionar  al producto de software desarrollado e implementado , en nuestra cultura es el analista-diseñador del sistemas.

El programador para bien o para mal tendrá siempre una visión parcial del producto total, excepto que el programador sea analista en el mismo proyecto, pero es algo que va perdiendo fuerza y sostenibilidad con los softwares cada vez más complejos.

La primera premisa básica en cualquier intervención sistémica es que debe existir un mínimo de documentación y no es el código ese mínimo, excepto que sea un prototipo, aún así lo pongo en dudas.

La documentación permite comunicar ideas, conceptos y decisiones. Alguna documentación resulta crítica para el proyecto / producto y otra resulta complementaria.

Como sea, y en cualquier metodología con la que desarrollemos nuestro  trabajo profesional, este debe quedar documentado.

Se documenta para los cambios, para la evolución del producto y para tener un punto de partida para el crecimiento del software, del sistema o de la aplicación (o como te guste llamarlo).

Se documenta para conocer el impacto.

No te olvides que los requerimientos, cambian, las reglas cambian, el cliente cambia y los trabajadores de tu organización cambian, incluso cambian los equipos, entonces tenemos buenas razones para documentar, pero no perdamos de vista que debemos documentar lo que merece la pena ser documentado. Por esto, la documentación irá evolucionando en la medida que se necesite.

Los requerimientos funcionales son necesariamente documentables; en definitiva ellos dicen que debe hacer el software.

Las reglas de negocio refieren a las normas y pautas sobre la que el software está limitado a funcionar dentro del marco de, por ejemplo, una organización.

Luego puede aparecer un set de modelos interesantes que serán más relevantes en ciertos proyectos que otros. En mi opinión es visión del profesional expandir la documentación, o bien, retraerla en la medida que así lo vea necesario.

Es importante pensar en un mínimo y en la calidad. Generar documentación que nadie entiende o nadie le resulta de utilidad es una pérdida de dinero.