Buscar en Gazafatonario IT

martes, septiembre 25, 2012

Casos de Abuso, Parte 8: Precondiciones vs. Validaciones y Poscondiciones vs. Resultados


A este caso de abuso originalmente lo titulé:
Las precondiciones son validaciones que hace el caso de uso al comienzo del mismo o en algún paso siguiente. Las poscondiciones y el resultado del caso de uso son una misma cosa.
Este es quizás el mayor de los abusos. Las precondiciones no ocurren dentro del caso de uso, es justamente lo contrario. Las precondiciones representan el estado en el que debe estar el sistema para que se ejecute el caso de uso a la que pertenecen. Son acciones que ocurren antes, en algún momento del tiempo, de la ejecución (o de la necesidad de ejecución) del caso de uso. Y cuando digo “en algún momento del tiempo” no me refiero a que tiene que ser inmediatamente antes del caso de uso, puede ser en cualquier instante, mientras sea antes de la ejecución del caso de uso. Para usar términos bastante reconocidos por nosotros, si un caso de uso tiene precondiciones, se encuentra deshabilitado hasta tanto todas las precondiciones no se hayan ejecutado y hayan producido los resultados necesarios para que el caso de uso se habilite y pueda ejecutarse.
Figura 2: Representación Visual de las Precondiciones y las poscondiciones de un caso de uso. Fuente: Adaptado de IBM Rational Unified Process
El error más común ocurre cuando confundimos una precondición con la validación a un elemento específico del negocio, por ejemplo, que el Cliente debe tener una cuenta corriente para solicitar aumento de cupo de sobregiro. Esta, a todas luces, es una verificación que debe ocurrir en el caso de uso “solicitar aumento de cupo de sobregiro” después de que el cliente se haya identificado, antes no es posible.
Un análisis similar puede hacerse para las poscondiciones, confundidas casi siempre con los resultados del caso de uso. Por ejemplo, es frecuente leer en la especificación de un caso de uso: “el sistema almacena los datos de la solicitud.”, “el sistema muestra el mensaje ‘no se pudo realizar la operación’.”, “el sistema cancela la ejecución del proceso.” Todas estos detalles corresponden a eventos que ocurren (deben ocurrir) dentro del caso de uso, no después de su ejecución, que es el terreno donde se mueven las poscondiciones.
Una poscondición típica puede ser: “el cliente puede consultar el estado de sus facturas.” Otra puede ser: “la cuenta del usuario queda deshabilitada.” Una más: “el cliente VIP puede modificar el estado de su reserva.” Todas estas son acciones que los usuarios pueden hacer después de que un determinado caso de uso se haya ejecutado, satisfactoriamente o no. El momento en el que se haga tampoco tiene que ser inmediatamente después, casi siempre depende de las necesidades de los usuarios particulares de cada funcionalidad.
Una situación adicional que ocurre en muchas oportunidades es que nos quedamos buscando precondiciones y poscondiciones del caso de uso durante un tiempo considerablemente extenso. Siempre recomiendo a los neófitos que si no las encuentran en las primeras de cambio pueden estar sucediendo dos cosas importantes:
  • No tenemos información suficiente del caso de uso (o no lo hemos entendido bien)

O
  • No tenemos la experiencia práctica o el conocimiento teórico suficiente para lidiar con estos dos aspectos de los casos de uso.

En el primer caso, debemos siempre buscar la información que nos hace falta con las personas involucradas, los usuarios; en el segundo caso es un poco más difícil, pero mientras este tema se nos vuelve una costumbre, recomiendo no quedarnos mucho tiempo paralizados por ello y seguir adelante. Las precondiciones y las poscondiciones son aspecto importantes para el diseño y la implementación del caso de uso, pero si no las encontramos, existen otras formas de llegar a la misma solución, quizás tome un poco más de tiempo a los diseñadores, pero este será mucho menos que si los analistas se quedan horas o días buscando algo que no conocen.
Otra cosa más, tanto las precondiciones como las poscondiciones son opcionales: no siempre son un elemento adherido al caso de uso. Es posible que haya casos de uso que no tengan unas o las otras, o ambas.
Impacto en la calidad: Alto.
PD. Para saber más de precondiciones y poscondiciones y de otras características de los casos de uso pueden leer mi Lectura Fundamental 3: “Casos de Uso: del todo y de sus partes”, en mi Gazafatonario IT:

jueves, septiembre 20, 2012

Casos de Abuso, Parte 7: La realización o diseño de un caso de uso siempre se hace


Esta es el más debatible de todos los abusos. Está en una zona gris. En aras de la calidad del producto, objetivo último de todo proyecto, siempre deberíamos hacer la realización del caso de uso [3], sin tener en cuenta el grado de mayor o menor complejidad del mismo. Sin embargo, siempre encontramos factores limitantes de tiempo, de recursos y de costos que lo impiden.
Ya en el primer abuso decía que mínimo debemos hacer la realización de los casos de uso arquitectónicos. Seguramente, si hacemos bien nuestro trabajo de diseñadores de software, de esta actividad surgirán la mayoría de las  entidades del sistema, los objetos controladores, las fachadas y las interfaces, entre otros tipos de objetos. El número de casos de uso arquitectónicos varía de un proyecto a otro, pero debería girar en torno a un 20% del total de casos de uso del producto. Es una cifra un tanto arbitraria pero parece funcionar en la mayoría de los casos, al grado de haberse convertido en una práctica generalizada.
¿Y el otro 80%? Yo siempre uso el precepto de “modelar para entender lo que vamos a construir.” Si alguien en el equipo de desarrollo no entiende un caso de uso, lo que hace o como lo implementa, entonces debemos apoyarnos en el modelado para subsanar esta situación. Y la realización del caso de uso es un buen comienzo para ello. ¿De cuántos diagramas preciso? Los que sean necesarios para entender. Ni más ni menos.
Impacto en la calidad: Bajo.
PD. Sobre diseño de casos de uso, más específicamente, sobre realización de casos de uso, los invito a leer mi Lectura Fundamental 10: Realización de Casos de Uso: De los Objetos y sus Interacciones en mi Gazafatonario IT.

lunes, septiembre 17, 2012

Casos de Abuso, Parte 6: Un escenario y un caso de uso es lo mismo

Simplemente no. Muchas veces los términos se usan indistintamente, yo mismo me he visto diciendo “caso de uso” cuando realmente quiero decir “escenario”. Pero ese es otro problema.
 Figura 1: Representación Visual de un escenario de un caso de uso

Un escenario es el flujo que sigue un caso de uso durante su ejecución de acuerdo a un estímulo recibido desde el exterior, vía el Actor del caso de uso, es decir, el usuario. Las cosas así, un caso de uso puede derivar en muchos escenarios, docenas, cientos o miles, dependiendo de la complejidad y el tamaño del caso de uso. Esta es la razón principal por la cual no existe el concepto de Pruebas Exhaustivas, porque es inviable probar con anticipación todos y cada uno de los escenarios de un caso de uso. Un escenario es una instancia de un caso de uso, casi de la misma forma como un objeto es una instancia de una clase. Me refiero a que una instancia de un caso de uso es un camino concreto a través del cual la pareja actor-caso de uso es reemplazada por una persona específica (una instancia de un actor), donde valores y respuestas específicos son dados, y solamente un camino simple es tomado a través de uno o más posibles flujos del caso de uso. Los escenarios están descritos de una manera narrativa, incorporan características concretas de los usuarios y de la materia prima que estos entregan al sistema.

Un caso de uso, por su parte, está constituido por secuencias paso a paso de acciones que conforman el comportamiento de un sistema, asociados a un actor específico. Un caso de uso es muy detallado y típicamente incluye actores, una breve descripción, precondiciones, la secuencia principal y las alternativas, y hasta flujos de excepción; también describe el estado del sistema una vez que ha terminado cada secuencia, es decir, las poscondiciones.

A propósito de este mal uso, otra situación que nos está pasando es que nuestros diseños de software carecen de los escenarios de usuario como entrada principal, lo que constituye una falta importante puesto que los escenarios incluyen todos los detalles que los diseñadores requieren entender sobre lo que los usuarios están tratando de hacer y lo que ellos necesitan. Muchos desarrolladores que nunca ha escuchado acerca de un escenario de uso son capaces de adaptar los casos de uso para incluir esta información de usuario, rica y contextual.

Impacto en la calidad: Alto.
Figura 2: Representación Visual de otro escenario de un caso de uso

Obsérvese de las dos figuras que las posibilidades son virtualmente infinitas.

miércoles, septiembre 12, 2012

Casos de Abuso, Parte 5: El caso de uso contiene detalles de formularios (pantallas) y otros aspectos técnicos (bases de datos, componentes, etc.)


Este error es reiterativo y cuando digo eso me refiero a que siempre hago énfasis en que no es así, pero algunos analistas funcionales insisten en hacer exactamente lo contrario.
Un caso de uso especifica lo que debe hacer un sistema de software. No es correcto incluir detalles de la interfaz gráfica resultante, como botones, cuadros de texto, listas de opciones, entre otros, lo mismo que otros mecanismos relativos a los elementos de software con los que se implementará el caso de uso, como referencias a componentes de software, a librerías de acceso a datos, o a tablas u otros objetos de bases de datos. Todo esto hace parte del “como” se implantará el caso de uso en el sistema una vez que esté terminado, son detalles poco entendibles para el usuario final, interesado principal en la especificación del caso de uso y de los requisitos en general.
Recordemos además que un caso de uso detalla la interacción entre el actor y el software, desde el punto de vista del usuario; es decir, al usuario solo le interesa conocer sobre los insumos que tiene que proporcionarle al sistema a través de ese caso de uso y también de los resultados que el sistema le sirve de vuelta, no cómo ese resultado es calculado, encontrado, o procesado al interior del sistema.
Ahora bien, suele ocurrir que algunos usuarios, a fuerza de lidiar durante tantos años con los sistemas, conocen de nombres de tablas y hasta de procedimientos almacenados y son capaces de establecer explícitamente de qué tabla quieren que se tome un dato o cual procedimiento requieren ejecutar en cierto momento. Estos detalles se documentan, pero se formalizan durante la etapa de Análisis y Diseño del caso de uso, cuando este se suplementa.
Los requisitos del software, y con ellos los casos de uso cuando se utilicen como mecanismo de especificación, son independientes de diseño y de implementación.
Impacto en la calidad: Medio.

martes, septiembre 11, 2012

Casos de Abuso, Parte 4: Resumen ejecutivo


Recapitulemos. Tenemos una lista corta de escenarios en donde estamos usando mal los casos de uso como instrumentos para identificar, organizar, documentar y administrar requisitos de software, tanto funcionales como no funcionales.
Estos son los casos enumerados hasta el momento:
Impacto en la calidad: Alto.
Impacto en la calidad: Bajo.
Impacto en la calidad: Medio.
Impacto en la calidad: Medio.
Entonces, ya sabemos que la especificación de requisitos de software (ERS) viene, o puede aparecer, en recipientes de distintos tamaños y diferentes formas y colores: algunos son cacharros escuetos pero con significado y suficiencia para quien los elabora y para los interesados en los mismos, otros son cristalerías sofisticadas que se aproximan a lo mundano, en el sentido de cosmopolita. Pero contienen requisitos de software, al fin y al cabo.
En términos de artefactos de especificación y modelado de sistemas de información, estoy hablando de folios de especificación funcional, con sus requisitos en prosa y todo el detalle aledaño que siempre los acompaña; pero también me refiero a la descripción de procesos del negocio, desde macro-procesos, hasta tareas simples y atómicas, pasando por procesos y subprocesos; representaciones de herramientas visuales como prototipos estáticos y simuladores.
También hago alusión a diagramas de UML, como  diagramas de actividad y de estado, diagramas de procesos, diagramas de contexto y mapas mentales, entre algunos otros; descripción de reglas y políticas del negocio; acuerdos de entendimiento entre los usuarios y el área de tecnología; listas de deseos escritas a mano; y, las más usadas, historias de usuario y casos de uso. Incluso, con las nuevas tecnologías, los requisitos de software bien pueden aparecerse en formato de videos o audios digitales, fotografías de alta definición capturadas por teléfonos inteligentes, mensajes electrónicos y trinos de 140 caracteres o menos.
Usualmente, la ERS se exhibe en una combinación de dos o más de estos instrumentos y lo único que importa es que provenga de las personas apropiadas e interesadas en el producto de software y que cada requisito cumpla o pueda cumplir con algunos atributos o rasgos de calidad:
·         Claridad
·         Atómicidad
·         Precisión
·         Verificabilidad
·         Necesidad u oportunidad
·         Priorización
La ERS, por su parte, debe ser:
·         Independiente de diseño
·         Completa
·         Consistente
·         Rastreable
·         Modificable / Extensible
Ahora ya sabemos cómo corregir algunos de esos defectos. ¿Ustedes qué creen?
Salud@s.