Buscar en Gazafatonario IT

domingo, septiembre 30, 2012

Casos de Abuso, Parte 10: Los flujos de eventos en los casos de uso son escritos en pseudocódigo


Este es el que yo llamo “síndrome del programador que se volvió analista”, algo así como el hombre-lobo del proceso de desarrollo de software. Creo que todos los que hemos recorrido este largo pero tortuoso laberinto que significa el ciclo de vida del desarrollo de software hemos experimentado, al menos, una o más de esas manifestaciones “fenomenoides” del universo informático. Además, este abuso es primo del abuso 5, donde usamos detalles técnicos en la documentación del caso de uso.
El antídoto es sencillo: un caso de uso siempre, sin ninguna excepción, se escribe en terminología del negocio, con las palabras que usa el usuario en sus actividades diarias. Si esto no es posible, quizás no estamos ante un caso de uso.
Nada de incluir expresiones como: “si ocurre esto entonces hacer aquello”, en cambio usar distintas secuencias o flujos alternos; o “mientras se cumpla una condición, realizar estas acciones”, en vez de ello, describir el conjunto de acciones para un elemento-sujeto de la condición y en los requisitos especiales del caso de uso dejar de manifiesto que puede haber uno o más elementos para esa condición. Y mucho menos usar nombres de “variables”, ciclos for o while o selección múltiple. Lo único que lograremos con ello es confundir a los usuarios.
Veamos con un caso de uso algo escueto un ejemplo típico:
Caso de uso: Retirar fondos
Actor: Cliente
Secuencia Básica:
1.    El caso de uso inicia cuando el cliente decide retirar dinero en efectivo de un cajero automático
2.    El sistema solicita la cantidad de dinero a retirar
3.    El Cliente ingresa la cantidad de dinero a retirar
4.    El sistema verifica el saldo del Cliente
5.    Si el Saldo del Cliente es mayor que o igual a la cantidad a retirar, el cajero entrega el dinero. De lo contrario, muestra el mensaje “Fondos insuficientes”
6.    El caso de uso termina
Los pasos 4 y 5 de este caso de uso son una muestra de lo que no se debe hacer al documentar requisitos. En cambio, podríamos decir:
4.    El sistema verifica que el Cliente tiene saldo suficiente en su cuenta y entrega el dinero.
5.    El caso de uso termina
Para el caso de falta de fondos, escribimos una secuencia alternativa. Esta estrategia además posibilita una implementación más rápida y “limpia” del caso de uso y permite al equipo de pruebas tener mayor visibilidad de los escenarios para verificar el software.
Impacto en la calidad: Alto.

PD. Para saber más de sobre casos de uso, abecés, anatomía, prácticas y requisitos en general, puedes visitar mi Sección Lecturas Fundamentales en mi Gazafatonario IT.

2 comentarios:

  1. Hola!...todo muy interesante. Gracias por todos los aportes. Tengo una pregunta en base a este post, ¿cada caso de uso seria para el cliente entonces? ¿que le llega al programador?
    Gracias por tus respuestas. Un saludos cordial! Sandra

    ResponderBorrar
  2. Sandra, al programador le llega el caso de uso, pero también le llega el diseño del caso de uso, lo que se llama en algunas metodologías la "realización del caso de uso" y otras especificaciones de diseño.

    Te recomiendo mi Lectura Fundamental 10: Realización de Casos de Uso: De los Objetos y sus Interacciones.
    La encuentras aquí mismo en:
    http://gazafatonarioit.blogspot.com/2007/10/lecturas-fundamentales-10-lectura_3046.html

    Saludos.

    Lucho

    ResponderBorrar