Archivos para 27 septiembre 2008

Todo requisito debe ser preciso y legible

La especificación de un sistema es un trabajo retador. En él participan no solo los desarrolladores de aplicaciones, sino también los clientes. Esto significa que la especificación de requisitos, ya sea como casos de uso o como declaraciones tradicionales tipo “el sistema debe…” ha de ser entendida a la vez, por lo clientes y por los desarrolladores. Dicho en otras palabras: la especificación contiene detalles técnicos que los clientes luchan por entender, a la vez que incluye información sobre el negocio que es nueva y potencialmente confusa para los desarrolladores.

Esta situación nos obliga a luchar por dos atributos básicos en todo nuestro sistema de requisitos: la claridad y la precisión.

Precisión de un requisito. Un requisito es preciso cuando indica sin ambigüedad lo que se desea especificar. Debe ir directo al punto y evitar todo adorno en el lenguaje. Debe documentar solo un aspecto del sistema y lo debe de hacer en forma exacta.

Y también

Claridad o legibilidad de un requisito. Un requisito es legible cuando el lenguaje en el que esta escrito es fácil de entender, tanto por los clientes como los analistas. La legibilidad se extiende no solo a la especificación escrita, sino también a los formalismos gráficos como los diagramas de casos de uso.

Es curioso observar que en los cursos universitarios sobre el tema, los profesores tengan la presión de explicar métodos y técnicas avanzadas, como las relaciones de extensión e inclusión de casos de uso, forzando al estudiante a adoptar estar técnicas en forma demasiado temprana. Esto causa una deformación profesional en el estudiante, quien sale del curso con la creencia que es mejor una especificación sofisticada que haga uso de todo lo visto en el curso, en lugar de una aproximación más informal y relajada que puede en verdad ser entendida por el cliente.

El lugar correcto para la extensión y la inclusión, así como para todas las técnicas de modelado de requisitos más sofisticadas, es en aquellos dominios de aplicación donde los requisitos reales sean muy complejos. Es decir por lo tanto, que en la práctica el analista ha de hacer esfuerzos por mantenerse sencillo, normalmente no vale la pena la complejidad del modelo de requisitos.

También es de hacer notar, que en mi experiencia la mayoría de los clientes intentan hacer otro tanto. Ellos suelen expresar lo que necesitan en la forma más directa que tienen disponible, sin embargo dado que los clientes son a su vez profesionales en un área especifica, la forma correcta en la ellos se expresan suponen tensión a los desarrolladores, quienes deben luchar por desarrollar un vocabulario común con el cliente para poder comprender sin errores lo que este pide.

En conclusión: lo sencillo se entiende más y la especificación de un sistema ha de entenderse bien. Cuan sofisticado hagamos nuestro modelo de casos de uso o nuestro documento de especificación, no es ni de lejos lo que en verdad importa. Es mucho mejor un caso de uso sencillo pero que captura valor de negocio, que uno sofisticado que haga un uso abundante de las técnicas más esotericas de modelado.

, , , , , , , , , , ,

2 comentarios

Diagramas de Clase

De entre todos los tipos de diagramas UML, el más común y conocido es el diagrama de clases. Dicho diagrama ilustra una vista de los componentes estáticos del sistema, ya sean estos clases o módulos, indicando las relaciones entre estas y los atributos (datos) de las clases, así como sus métodos (código).

El diagrama de clases puede ser utilizado para presentar la vista estática del modelo de dominio, del modelo de diseño, o bien, del detalle de la implementación de un sistema en un lenguaje de programación orientado a objeto, como Eiffel, Java o C++. Para todos estos usos, lo que se desea es expresar las unidades en que el código se organiza -las clases- así como algunas características de estas, notablemente como dije antes, sus relaciones, atributos y métodos.

Es valido combinar los diagramas de clase con paquetes, dando lugar a un diagrama que muestra simultáneamente clases y paquetes. Dicha práctica ayuda a documentar elementos que estén en distintos paquetes pero que guarden alguna relación, aún cuando la especificación de UML habla de diagramas de tipos diferentes para los paquetes y las clases.

En este blog se encuentran muchos ejemplos de diagramas de clase, ya que se han incluido en los post que lo requieren como parte del asunto tratado. Algunos de estos son:

Por lo anterior, si se queiren ver ejemplos de un diagrama de clases, basta con dar un paseo por el blog, seguro encontrará muchos ejemplos apropiados.

, , , , ,

2 comentarios

Diagrama de definición de Elemento: UML::Classes::Kernel::Root

UML es un lenguaje de modelado capaz de describir sistemas como conjuntos de elementos y relaciones. Esta forma de describir sistemas es lo suficientemente potente como para poder describir las nociones del propio lenguaje UML como un conjunto de elementos y relaciones.

Como ejemplo de lo anterior podemos tomar el diagrama UML::Classes::Kernel::Root, parte del metamodelo de UML, en el cual se describe la noción de Elemento, en termino de sus relaciones con otros conceptos. Dicha descripción se presenta como un diagrama de clases convencional.

Fig. 1 – Descripción del concepto “Elemento” de UML
(Diagrama UML::Classes::Kernel::Root del metamodelo de UML)

Esta forma de definir los conceptos del lenguaje UML recurriendo a los propios mecanismos del lenguaje es conocido como Metamodelado y es uno de los puntos fuertes del lenguaje UML. Ahora, con el diagrama en mano, podemos ver los detalles del concepto de elemento simplemente leyendo las relaciones presentadas en el diagrama.

Por ejemplo, se deja ver en el diagrama que:

  • Un elemento puede tener cualquier número de comentarios. Cero, uno o más.
  • Un elemento puede o no, tener un dueño. En caso que lo tenga será único.
  • Un elemento puede ser dueño de cualquier número de elementos.
  • Las relaciones y comentarios son elementos a su vez.
  • Las relaciones tienen un tipo especializado: las relaciones dirigidas. Estas tienen un elemento de origen y otro de destino.
  • El origen y el destino de una relación dirigida puede ser el mismo elemento.

Entre otros posibles puntos mostrados en el gráfico.

, , , ,

3 comentarios

Casos de Uso: Flujos de Eventos

Un caso de uso es un escenario de interacción entre el sistema y un ente externo; es decir: es la descripción de una funcionalidad del sistema, visto desde el punto de vista de un ente externo que demanda dicha funcionalidad.

Al ente externo le llamamos actor por cuanto un caso de uso puede ser visto también como un guión, que a la manera de los guiones de una obra de teatro, dice paso a paso lo que el actor ha de hacer.

Es mucho lo que podemos decir de un caso de uso: nombre, descripción, pre condiciones, etc. Sin embargo, el aspecto más interesante de un caso de uso luego de la descripción del mismo es sin duda el flujo de eventos.

Al flujo de eventos lo podemos relacionar con un dialogo. Línea a línea, el flujo de eventos indica quien habla y qué dice. La secuencia se suele iniciar con algo dicho por el actor, y se continua intercalando sucesivamente lo hecho por el sistema con lo dicho por el actor. A cada una de estas líneas o indicaciones, le podemos llamar paso.

Un buen flujo de eventos recoge con detalle la identidad de quien realiza el paso, expresando sin ambigüedad la acción realizada. Es decir, que un buen paso ha de ser siempre una oración con sentido completo, escrita en voz activa, iniciando con el nombre del actor o bien del sistema que realiza la acción e indicando exhaustivamente los elementos de información que se intercambian.

Dichas oraciones con sentido completo, sin ambigüedad y demás características ya mencionadas, no son difíciles de redactar. Son de hecho la forma más directa de decir lo que hay que decir. Y es que a la hora de redactar un flujo de eventos debemos evitar recurrir a formas de redacción en prosa típicas de nuestros textos comunes. No vale sustituir el nombre del actor por un pronombre o demostrativo que le haga referencia. A la larga, dicha omisión del nombre del actor va a ser una fuente de ambigüedad y nos puede traer problemas.

Si bien para quienes acostumbran a redactar con estilo, estas normas para los flujos de eventos pueden sonar extrañas, son normas muy comunes para cuando queremos redactar documentos de requisitos. Básicamente estamos aplicando aquí los mismos consejos que se dan para redactar bien un requisito tradicional, del estilo “el sistema debe…” por lo que en Internet abundan los detalles sobre este particular.

Finalmente, la prosa tiene su refugio en la descripción breve de un caso de uso; y dado que es esta descripción breve la parte más importante del caso de uso, podemos decir que a la final todos vamos a poder estar contentos. Quienes quieren una redacción con estilo van a encontrar lo que buscan en la descripción breve y quienes necesitan los detalles operativos del caso de uso lo van a encontrar en los pasos del flujo de eventos.

, , , , , , , , ,

5 comentarios

¿Qué son las llamadas Mejores Prácticas?

Las mejores prácticas son características reconocibles de los procesos de las organizaciones de éxito. Suelen ser conductas observables, llenas de sentido común; que al estar presentes en las mejores empresas de cada sector, se piensa que son parte del éxito de dichas empresas. Por supuesto, se piensa también que de asumirse, toda empresa se puede beneficiar, por lo que la predica en pos de las mejores prácticas es parte importante de la planificación a largo plazo de las organizaciones que desean mejorar y crecer.

A nivel personal, podemos establecer un símil con los consejos más comunes sobre como llevar una vida sana y exitosa. Consejos tales como “pensar antes de actual” o bien el elemental “dormir lo suficiente cada noche” son el equivalente de las mejores prácticas, aplicadas a como conducir la propia vida.

En el caso de las empresas, se confía en los institutos de investigación de cada sector, quienes identifican sistemáticamente las prácticas en uso, con el objetivo de publicar catálogos de mejores prácticas, que sean apropiadas para el sector industrial que se este considerando. Dichos catálogos suelen ser de acceso libre y son conocidos bajo diferentes denominaciones, como si se estuviera hablando de cosas diferentes en cada sector. Pero no hay confusión que valga: para todo sector valen distintas mejores prácticas, pero llámense como se quieran llamar, todas son mejores prácticas y poco más.

Cuando se esta diseñando un proceso empresarial, es útil considerar las mejores prácticas conocidas del sector o actividad en la que el proceso vive. Dado que existen gran cantidad de sectores, el analista de procesos puede beneficiarse de conocer que se considera como una buena idea, dando entonces una base sistemática para identificar objetivos de diseño para los procesos, más allá de cubrir las necesidades inmediatas demandadas por los clientes.

He de hacer notar también, que muchas de las mejores prácticas pueden ser apoyadas por sistemas de información apropiados; o dicho de otra forma, que hoy en día existen gran cantidad de sistemas de información, muchos de ellos construidos para dar cumplimiento a una o más de las mejores prácticas de sector destino del sistema.

Así que el asunto de las prácticas conviene tenerlo en mente.

, , , , , , , ,

Deja un comentario