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á

La prueba ataca

La prueba ha evolucionado; pasando de ser vista y tratada como arte hasta un visión de proceso.

De la nada y, observando la poca calidad de la entrega de un producto de software, la prueba se transformó en el primer instrumento de control, luego se hizo fase, más tarde un proceso que atravesaría todo el ciclo de vida de proyecto primero y de producto después.

Sin embargo, en el ADN de los profesionales de sistemas, la prueba continúa siendo maltratada y demonizada.
La prueba es un trabajo para principiantes, es poco relevante, es un trabajo "menor". Si un profesional piensa esto, tendrá que volver a re-pensarse.  Fea la actitud.
La prueba no es una actividad de segunda mano. Veamos que con los años se ha transformado en un proceso, a pesar de los profesionales, en segundo plano ha continuado creciendo a pesar de nosotros mismos, los profesionales de sistemas. Algo tiene que haber.
Me gusta ver la prueba como una guía para una planta que está creciendo. Me gusta ver a las personas que realizan esa función como "GUARDIANES de la calidad"
El probador, tester o responsable de ejecución de la prueba tiene una función vital. Asegurarse de encontrar errores antes que los encuentre el cliente en PRODUCCION.

La prueba es inevitable. Sin prueba no hay calidad y los errores aparecerán por docenas (para ser humilde) .

La prueba que no encuentra errores es una prueba deficiente. El responsable de prueba ( y no solo de ejecución) debe encontrar errores. Es su fin.

Con el tiempo se asimiló que cuanto antes se encuentran errores, más fáciles son de corregir.
También se observó que los errores no solo están en el código, sino que en el diseño, en el análisis, en la definición del producto y hasta en la misma prueba. Este pensamiento hizo que la prueba atravesara a todo el ciclo de vida del producto.

Otro mito interesante que surge en que la prueba es sentarse y ejecutar un programa y, ver que onda,  o sea, onda veo si encuentro error. Este es otro error.
La prueba debe ser pensada, por esto, algunos autores definen al proceso como:

Definir que probar
Diseñar la prueba
Ejecutar la prueba
Corregir los errores

Estas super actividades son subprocesos en si mismos, requieren diferentes roles y no refieren a sentarse y probar.
Así que ahora además tendremos que pensar que si la prueba está al menos involucrando estas cuestiones entonces se trata de algo más sentarse frente a un equipo, correr un programa y fijarse si se encuentra un error.

El proceso de prueba se irá "desarrollando" a lo largo del proyecto de desarrollo, no cabe de duda. Es un proceso continuo.

¿Por qué los programadores reniegan de los probadores?
Ponete a pensar que un programador, genera una “obra de arte” y el probador es el crítico de la obra de arte. Además si bien el probador realiza una crítica constructiva o regenerativa; el ego del programador le impide verla. Claro, esto también está cambiando; es CULTURAL.
Incluso algunas organizaciones contribuyen a la desmejora CULTURAL considerando el valor hora de la prueba de menor rango. Otro pensamiento erróneo instalado.

Igualmente convengamos que la ejecución de la prueba no es una actividad "FELIZ", pero habrá que buscarle la vuelta.
La actividad requiere de un perfil, me refiero a la ejecución, metódico y estructurado, que permita ver que su trabajo engrandece la calidad del producto. Una persona con espíritu crítico pero no soberbio. Al fin y al cabo cuando el probador encuentre el error, nadie podrá negarlo.
El probador debe tener las libertades para proponer nuevas miradas sobre la prueba en cualquiera de sus partes; el probador es el usuario de lo que se prueba.
El subproceso que define que probar necesita del conocimiento del sistema que se desarrolla, el diseño de la prueba requiere de algún conocimiento del negocio.
El área de control de calidad tiene la responsabilidad de definir buenas prácticas y lineamientos de trabajo. La Gerencia debe sponsorear la calidad sosteniendo la prueba a pesar del stress, los líderes de proyecto son artífices de sostener la prueba a pesar del stress.
Las auditorías internas y externas, las revisiones de pares son otras formas de controlar la calidad, son otra forma de probar.
Es muy significativa la imagen de la bola de nieve que comienza pequeña en la punta de la montaña pero se es impresionantemente grande al llegar al pie de la misma.
Un requerimiento mal encarado al principio produce ese efecto en el final del desarrollo de un producto. Probar lo antes posible es una premisa de este proceso continuo.
Por lo mencionado, es importante validar los requerimientos desde su concepción.

La prueba falla cuando no se encuentran errores. Ojo siempre hay errores algunos aun subyacentes, pero están.
Cuando una prueba no es eficiente deben encontrarse variantes.

El secreto de las herramientas. Un secreto gritado a voces.

Todos sabemos que las herramientas ayudan a los profesionales de todos las áreas en su trabajo.

Algunas herramientas son más completas, otras más eficaces, algunas facilitan el trabajo, otras permiten hacer el trabajo más rápido. Como sea, sin herramientas muchos trabajos no se podrían realizar.

Clavar un clavo sin un martillo o ajustar los tornillo de una rueda sin al menos un llave CRUZ, serían tareas demasiado complejas, difíciles o imposibles de ejecutar, incluso para profesionales avezados.

La herramienta sola no es nada, dependemos de la habilidad de quien la usa, la herramienta debe estar en manos de un trabajador (worker); él es quien cambia el destino de una batalla.

Tener la herramienta sin el worker sólo te hace poderoso en una mesa, durante una charla, pero no en el campo de batalla.

En el área de conocimiento de software las personas y las herramientas son elementos importantes de la calidad, diría que la interacción producida entre la persona y la herramienta es mucho más importantes que los elementos por separado. La persona tiene el conocimiento y el herramienta el don de facilitarlo. El conjunto es un simbiosis fundamental.

No es concebible desarrollar software sin ambos elementos, mucho menos con calidad; pero recuerda el verdadero secreto no es la herramienta sino la persona que la usa.

De este modo comprenderás que si pones tu éxito sólo en las herramientas te estarás equivocando y si solo lo ponés en las personas será insuficiente deberás realizar una mezcla útil.

Tampoco puedes esperar que la relación se base en tomar un individuo  y darle una herramienta. El individuo debe conocer y saber hacer con la herramienta.

El éxito de la relación lo consigues cuando el profesional sabe usar la herramienta y tiene arraigado los conceptos que le permiten volverla más eficaz.

De nada sirve que se tenga una herramienta para modelar diagramas de actividad, si el profesional no conoce sobre  diagramas de actividad. Puede que haga un dibujo con componentes de diagrama de actividad, pero ¿estará haciendo un diagrama de actividad?