Lectura Fundamental Anterior: “Casos de Uso: Del Todo y de Sus Partes”
Lectura # 4
Casos de Uso: ¿Cuándo Están Terminados?... ¿Y qué hacer con ellos a continuación? Parte 1 de 2
Volvamos a considerar el siguiente caso de uso típico de un sistema de reservaciones:
Caso de Uso: Reservar Vuelo
Actor: Pasajero Frecuente
Descripción: este caso de uso permite a una persona reservar un vuelo de ida y regreso entre dos ciudades distintas en las fechas de su elección. El sistema valida la disponibilidad de un asiento de las características que el Pasajero especifique. La reservación se hace vía Internet. La aerolínea sólo tiene aviones con asientos estándar.
Objetivo: Proporcionar un mecanismo rápido y seguro a un Pasajero Frecuente para hacer reservas en vuelos nacionales o internacionales de ida y regreso. No se incluye la funcionalidad de pagar o cambiar el estado de la reserva.
Precondiciones: El Pasajero debe estar plenamente identificado ante el sistema de reservas (Cuenta de Pasajero Frecuente, Identificación, Nombre y otros datos básicos).
Secuencia Básica:
1. El caso de uso inicia cuando el Pasajero decide Hacer una Reserva Aérea
2. El sistema solicita las ciudades origen y destino del vuelo
3. El Pasajero selecciona las ciudades origen y destino del vuelo
4. El sistema valida que las ciudades Origen y Destino sean distintas, que haya al menos un vuelo entre esas ciudades y solicita las fechas de ida y regreso
5. El Pasajero especifica las fechas de ida y regreso, incluyendo la hora de ambos viajes
6. El sistema valida que la fecha de regreso, incluyendo la hora, sea superior a la fecha de ida, incluyendo la hora, y pide seleccionar una opción de la lista de vuelos disponibles para las fechas y ciudades establecidas
7. El Pasajero selecciona una opción de vuelo
8. El sistema muestra los detalles del vuelo y solicita confirmación de la reserva
9. El Pasajero confirma la reserva
10. El Sistema asigna un asiento al Pasajero, genera y muestra un código de reserva
11. El caso de uso termina
Secuencia Alternativa 1:
4A. No hay vuelos entre las ciudades seleccionadas
4A1. El sistema muestra el mensaje: “No hay vuelos entre las ciudades seleccionadas. Verifique.”
4A2. El caso de uso termina
Secuencia Alternativa 2:
6A. No hay vuelos disponibles en las fechas especificadas
6A1. El sistema muestra el mensaje: “No hay vuelos disponibles en las fechas seleccionadas. Verifique.”
6A2. El caso de uso termina
Secuencia Alternativa 3:
6B. La fecha/hora de regreso es inferior a la fecha/hora de ida
6A1. El sistema muestra el mensaje: “La fecha de regreso es inferior a la fecha de ida. Especifíquelas nuevamente.”
6A2. El caso de uso continúa en el paso 5 de la secuencia básica
Poscondiciones: El Pasajero puede consultar el estado de su reserva. El Pasajero puede modificar o cancelar su reserva.
Requisitos Especiales: El sistema sólo muestra y permite seleccionar pares de vuelos disponibles en las fechas y entre las ciudades establecidas. El sistema de reservas es solo para el tipo de Pasajeros Frecuentes de la aerolínea.
Advertencia: todavía este continua siendo un caso de uso de una situación simulada, no intente usarlo en ningún proyecto en curso.
Voy a cerrar este primer ciclo de lecturas fundamentales sobre casos de uso basándome precisamente en una corta pero sustanciosa lista de chequeo para revisar casos de uso. Vale la pena decir que esta lista hace parte del proceso de Ingeniería de Requisitos institucionalizado en InterGrupo hace ya algún tiempo y que a su vez está cimentada en RUP.
Ley de la Terminación de un Caso de Uso
Un caso de uso está terminado cuando se cumplen al menos diez de las siguientes trece condiciones:
1. ¿El caso de uso tiene especificado el Actor que lo inicia?
2. ¿El caso de uso ha sido leído y entendido por todos los interesados en el mismo, incluyendo representantes de los usuarios finales y los programadores del mismo?
3. ¿La secuencia de comunicación entre el actor y el caso de uso cumple con las expectativas del usuario?
4. ¿La secuencia de comunicación entre el actor y el caso de uso cumple con las expectativas del usuario?
5. ¿Está claro cómo y cuándo comienzan y terminan los flujos de eventos del caso de uso?
6. ¿Está claro quién quiere ejecutar el caso de uso? ¿El propósito del caso de uso también está claro?
7. ¿Las interacciones del actor y la información intercambiada están claras?
8. ¿La descripción breve ofrece un cuadro verdadero del caso de uso?
9. ¿La secuencia básica del caso de uso tiene un número de pasos pequeño? (menos de 20)
10. ¿Está claro que el caso de uso no se puede dividir en dos o más casos de uso?
11. ¿Para un caso de uso incluido: se probó que si se modifica el caso de uso que lo incluye, el caso de uso incluido no se afecta?
12. ¿Cada caso de uso es independiente del resto?
13. ¿Este caso de uso hace algo muy parecido a otro caso de uso? De ser así, quizás deberían convertirse ambos en un único caso de uso.
¿El caso de uso tiene especificado el Actor que lo inicia?
No habría mucho que decir de este control si la búsqueda y posterior definición de los actores de un sistema no estuviera hoy tan desestimada. En principio tengo que decir que intentar definir un sistema sin conocer sus actores es un error bastante común. Antes que cualquier otra cosa es importante conocer para quien construimos el sistema, luego procedemos a documentar lo que hace cada uno de esos actores.
Debemos indagar por el perfil del actor y sus responsabilidades en el sistema. Recordemos que un actor bien podría ser alguien “abstracto” para el negocio, es decir, no equivale a un rol desempeñado por una persona o un grupo de personas dentro del negocio, razón por la cual, luego de hacer la abstracción, hay que mirarlo desde el punto de vista del sistema.
Con ese perfil, evaluamos si las actividades descritas en el caso de uso pueden ser ejecutadas por ese actor. Este es realmente el punto de chequeo, no simplemente asegurarnos de que haya un nombre cualquiera en la sección Actor del caso de uso.
Ahora bien, un caso de uso normalmente tiene un único actor que lo inicia; sin embargo, el caso de uso puede tener más actores. En este caso, los demás actores son pasivos, es decir, o simplemente reciben información, como en el caso de un sistema o un dispositivo externo, o son espectadores participes del proceso del negocio que envuelve el caso de uso, como en el caso de un cliente en un punto de venta. En cualquier caso, es importante enumerar a todos los actores que intervienen en el caso de uso por el horizonte que se extiende tanto para los analistas como para los desarrolladores y probadores del producto, en cuanto al entendimiento del mismo.
En el ejemplo, un “simple” Pasajero puede significar un cliente casual de la aerolínea, mientras que un Pasajero Frecuente es precisamente una persona que toma vuelos con una frecuencia uniforme o que, al menos, está registrado como tal ante la compañía.
¿El caso de uso ha sido leído y entendido por todos los interesados en el mismo, incluyendo representantes de los usuarios finales y los programadores del mismo?
Los usuarios son la última línea de defensa del caso de uso, son quienes confirman que está terminado, son quienes lo aprueban. Es tarea del Especificador de Requisitos obtener de ellos la información suficiente y necesaria para terminar el caso de uso. Siempre tenemos a la mano el “¿Qué más debo saber acerca de esta funcionalidad?” Otras preguntas importantes son: ¿Quién más está interesado en este caso de uso? ¿Quién debería leerlo? ¿Quién debería aprobarlo?
Una vez se tiene esa información, el revisor del caso de uso, si existe, puede indagar sobre el número de personas que leyeron y aprobaron el caso de uso para establecer si eso constituye una muestra representativa para dar por terminado el caso de uso.
En el ejemplo, puesto que el Pasajero es un actor externo a la compañía, alguien dentro de ésta es quien lo representa, es decir, es quien decide cómo quiere que los clientes de la aerolínea perciban el sistema. Por ello es importante documentar desde el principio del proyecto, no solo quienes son los usuarios finales, sino quienes serán sus representantes a lo largo del ciclo de vida.
¿La secuencia de comunicación entre el actor y el caso de uso cumple con las expectativas del usuario?
Es más que evidente. Otra vez, es sólo el usuario y nadie más que el usuario, quien decreta la correcta finalización del caso de uso. Por ello el caso de uso no debe incluir aspectos técnicos o detalles del diseño o implementación del mismo.
Se evidencia la participación dinámica y constante del usuario o de un grupo de usuarios durante la Ingeniería de Requisitos (por supuesto, también durante el resto del ciclo de vida, pero sin duda es esta etapa donde se hace más evidente la necesidad de contar con el mayor número de usuarios del producto).
El usuario regular no está interesado en conocer lo que ocurre “detrás del telón” del sistema. Para él sólo es importante el grupo de acciones donde él participa activamente, donde interactúa con el software y finalmente es quien indica si está satisfecho con lo que está documentado en el caso de uso.
Si, por ejemplo en el paso 6, dijéramos que la lista de vuelos se busca haciendo una intercalación multivía seguida de una selección por reemplazamiento, estaríamos adicionando detalles que confundirían innecesariamente al usuario común y corriente. Es más, ni siquiera tendríamos que mencionar las tablas y mucho menos los componentes involucrados en dicha búsqueda y selección.
¿Está claro cómo y cuándo comienzan y terminan los flujos de eventos del caso de uso?
Si mantenemos el caso de uso en su estado más simple, aunque con el suficiente detalle para pasar al siguiente estado, los momentos de inicio y finalización de cada secuencia de acciones deberían estar a la vista de todos.
Los errores más comunes se encuentran en las secuencias alternativas, al decidir si la acción retorna a la secuencia básica o si el caso de uso termina. También pasa que si el caso de uso tiene varios escenarios a partir de una misma acción, luego de escribir dos o tres de ellos perdamos el foco de la “horizontalidad” del caso de uso y empezamos a cubrir detalles que nos podrían llevar, desde el punto de vista del usuario, por caminos insubstanciales del caso de uso.
¿Los subflujos en el caso de uso están modelados con precisión?
Luego de mi lectura fundamental # 1 no volví a mencionar la palabra modelo. No es que cuando estamos documentando casos de uso no estamos modelando, es que precisamente a veces perdemos la conciencia de que es eso lo que estamos haciendo, aunque sea puramente texto lo que escribamos. De hecho, el modelo de casos de uso es mayormente texto.
Así que cuando hablo de modelar subflujos del caso de uso con precisión, me refiero a que proporcionemos toda la información necesaria al modelo: lugar donde se inicia el subflujo, motivo del subflujo, acciones del subflujo y método de terminación del subflujo.
Cabe decir que los subflujos no son sólo secuencias alternativas, también pueden ser “porciones” de la secuencia básica, normalmente, porciones pequeñas y extremadamente simples.
Sí, el concepto clave es simplicidad.
¿Está claro quién quiere ejecutar el caso de uso? ¿El propósito del caso de uso también está claro?
Una cosa es especificar un actor y otra es si ese actor representa adecuadamente al grupo de usuarios que ejecutará el caso de uso. Es posible que haya diferencias entre lo que piensa el representante de los usuarios asignado para proporcionar la información de, revisar y aprobar el caso de uso, y lo que finalmente quede documentado.
Un trabajo de campo, donde aseguremos que varios usuarios lean y acuerden el caso de uso ayuda mucho en estos casos. Así evitamos esa escena de terror que más de uno hemos vivido cuando mucho tiempo después de la especificación, probablemente durante las pruebas de certificación o ya en producción, nos preguntan “¿Quién dijo eso?”
De otro lado, el propósito puede estar implícito a lo largo y ancho de la declaración del caso de uso, o bien puede estar explícito en una sección inicial del mismo. Esta última opción es mi favorita porque permite verificar la consistencia del caso de uso lo mismo que medir su valor para el sistema y para los usuarios.
El propósito, si se especifica, debe escribirse a priori, quizás durante la etapa de descubrimiento del caso de uso, para que posea la menos subjetividad posible. Por supuesto, siempre podemos afinarla, aún antes de presentar el caso de uso para su última revisión.
El propósito debe incluir lo que el actor consigue del caso de uso y también lo que no consigue. Esto ayuda en las etapas posteriores al resto del equipo de desarrollo del proyecto a construir un sistema de alta usabilidad y gran aceptación.
Lo que Falta
Bien, hasta aquí la exploración a los primeros aspectos fundamentales que nos ayudan a decidir cuando un caso de uso está terminado. En la siguiente entrega volveré con el final de este artículo.
Esta lectura #4 continuará. Hasta entonces.
Lectura Fundamental Siguiente: “Casos de Uso: ¿Cuándo Están Terminados?... ¿Y qué hacer con ellos a continuación? Parte 2 de 2”
Este es mi punto de vista sobre las Tecnologías de la Información, Software y Pensamiento Ágil. Especialmente en lo que respecta a procesos y métodos, modelos y sistemas, marcos de trabajo y prácticas ágiles, experiencia en la industria, transformación organizacional, cultura, generación de Valor, trabajo colaborativo, Inspección y adaptación y mejoramiento continuo. Propuestas y experimentos, mejores prácticas y calidad de los productos (de software) y servicios.
Buscar en Gazafatonario IT
jueves, diciembre 07, 2006
Lecturas Fundamentales 4 (1 de 2)
Labels:
Analista del Software,
Caso de Uso,
Proceso,
Requisitos,
RUP
Suscribirse a:
Comentarios de la entrada (Atom)
No hay comentarios.:
Publicar un comentario