Diez Consejos Útiles y Simples Para Escribir Efectivamente Casos de Uso Efectivos, III

Puesto que es una buena (mejor) práctica encontrar primero los actores y a continuación los casos de uso, es recomendable también especificar el actor en la descripción de cada paso, en vez del término genérico “actor”, como en:

q. El sistema solicita la fecha de creación de la cuenta

q+1. El Analista de Crédito ingresa la fecha de creación de la cuenta

Recordemos que los actores, humanos o no, son externos a y delimitan el sistema y, por tanto, su funcionalidad. Es a los actores a quienes les interesa el resultado de cada caso de uso, cualquier proceso del sistema, así sea un proceso automático, ocurre porque en algún instante a alguien o a algo consultará o le resultará de vital importancia el resultado de ese proceso. Ningún caso de uso lo sería si no hay un actor involucrado, directa o indirectamente.

Con ello en mente, y ya que vamos a adoptar la rutina de identificar a cada actor del sistema y luego a los casos de uso subyacentes, en estos nombraremos al actor cada que ejecute una acción y no usaremos términos como “usuario”, “usuario final” o “actor”.

Ejemplo

Consideremos un caso de uso simple para consultar el saldo disponible en una cuenta bancaria vía Internet:

Caso de uso: Consultar saldo

Actor: Cuenta-habiente

Precondiciones: El Cuenta-habiente está debidamente autenticado ante el sistema virtual

Secuencia básica:

1.     El caso de uso inicia cuando el Cuenta-habiente quiere consultar el saldo disponible en su cuenta de ahorros

2.     El sistema solicita seleccionar la cuenta

3.     El Cuenta-habiente selecciona la cuenta de la cual consultar el saldo

4.     El sistema consulta la cuenta y muestra el saldo disponible

5.     El caso de uso termina

Poscondiciones: Él Cuenta-habiente puede transferir dinero a otra cuenta. El Cuenta-habiente puede hacer pagos a terceros.

El correcto nombramiento de los actores también ayuda a entender mejor el sistema que vamos a construir. Un banco, por ejemplo, tiene muchos tipos de clientes, algunos de estos tienen abierta una o más cuentas bancarias tradicionales, son los Cuenta-habientes. Al menos en Colombia, una persona puede tener una tarjeta de crédito emitida por un banco o un crédito de consumo y no tener ningún otro producto con la entidad financiera, son otros tipos de clientes, por lo que usar el término genérico Cliente no ayuda mucho.

Nótese en el caso de uso la especificación de precondiciones y poscondiciones que, entre otras características, hacen más clara y corta la especificación y permiten a los involucrados conocer más detalles de la operación que se está describiendo.

Ecos del Simposio Latinoamericano de Ingeniería de Software

Aunque ya pasó algún tiempo desde que escribí este artículo, el tema de Semat está cobrando vida y afectará el futuro de la Ingeniería de Software como la conocemos hoy. Por consiguiente, impactará en la manera cómo hacemos Ingeniería de Requisitos, en particular, y el universo de los métodos de software en general.

Este es un brevísimo resumen de lo que pasó durante los dos días del simposio: los temas expuestos, la presencia del experto internacional Ivar Jacobson, la creación del capítulo para Latinoamérica de la iniciativa SEMAT, una revolucionaria propuesta que el mismo Jacobson apoya junto a otros prominentes miembros de la industria del software y que busca refundar la ingeniería de software con una teoría sólida, principios probados y mejores prácticas refinadas.

El artículo completo lo pueden descargar en:


https://docs.google.com/file/d/0B5SNac-eZKMMdGY2V2xZVnFtQXc/edit?usp=sharing

El sitio de Semat Central es: http://www.semat.org.

Diez Consejos Útiles y Simples Para Escribir Correctamente Casos de Uso Correctos, II

Siempre que sea posible, debemos evitar secuencias de pasos como:

n. El sistema hace…

n+1. El sistema hace…

O

m. El actor hace…

m+1. El actor hace…

Donde n y m son números de pasos de una secuencia cualquiera del caso de uso. Es decir, ni el sistema ni el actor ejecutan dos pasos seguidos en el caso de uso. La escritura de casos de uso debe (ría) obedecer al siguiente patrón de diálogo:

p. El sistema hace…

p+1. El actor hace…

Donde “hace” se debe reemplazar por la acción que uno y otro ente realizan. Normalmente, el sistema “solicita” el ingreso o selección de datos y el actor “proporciona” datos, ya sea ingresándolos (por medio del teclado, en cuyo caso “digita” los datos) o seleccionando uno o más datos disponibles de una lista suministrada por el sistema. Nunca se debe especificar el mecanismo programático (formularios, ventanas, cuadros de texto, listas combinadas, cuadros de chequeo, botones de comando, entre otros) utilizado para crear y mostrar la lista. Ejecutar.

Además, nuestros usuarios siempre esperan que los sorprendamos con algo novedoso y una forma mejor de hacer las cosas. En el futuro cercano, por ejemplo, esperarían no tener que lidiar con la clásica interfaz gráfica de hoy sino con hologramas u otra suerte de mecanismos de comunicación Humano-Máquina. Pero ese es otro asunto.

Volviendo al consejo práctico que nos ocupa, normalmente cuando ocurre que debemos especificar varias actividades seguidas de un actor o del sistema, nos encontramos ante una de estas situaciones: estamos haciendo descomposición funcional que, en principio, es innecesaria. Recordemos que lo esencial en un caso de uso es especificar lo que hace el sistema que es relevante para el negocio o para ese actor en particular. Por ejemplo, para un actor es significativo que el sistema busque y muestre los datos de una factura o le indique que no la encontró, pero no es importante si esa búsqueda ocurre mediante un método secuencial, uno binario, la técnica de Fibonacci o un algoritmo genético, o si usa el mismo método de google para encontrar páginas en Internet.

También puede ocurrir que estamos especificando una funcionalidad del sistema que es posible documentar mejor con otros mecanismos como diagramas de actividad o estado o, si es necesario documentación textual, con requisitos escritos a la usanza tradicional de: “el sistema debe hacer algo…”. También se pueden usar escenarios, tableros de historias (storyboards), prototipos o simuladores, o una combinación de dos o más de estos artilugios.

Ejemplo

El siguiente caso de uso para reservar sillas en un viaje por avión nos ilustra muy bien esta sugerencia:

Caso de Uso: Reservar tiquetes

Actor: Cliente (Aerolínea)

Secuencia Básica:

1.    El caso de uso inicia cuando el Cliente decide reservar tiquetes aéreos

2.    El sistema solicita seleccionar la ciudad origen

3.    El Cliente selecciona la ciudad origen

4.    El sistema solicita seleccionar la ciudad destino

5.    El Cliente selecciona la ciudad destino

6.    El sistema solicita la fecha de ida

7.    El cliente ingresa la fecha de ida

8.    El Sistema solicita la fecha de regreso

9.    El Cliente ingresa la fecha de regreso

10.  El sistema solicita el número de pasajeros

11.  El cliente ingresa el número de pasajeros

12.  El sistema verifica que hay disponibilidad de vuelos entre las ciudades y fechas solicitadas

13.  El sistema verifica que hay disponibilidad de asientos para el número de pasajeros establecidos

14.  El sistema muestra el mensaje “Sí hay disponibilidad de vuelos  entre las ciudades y fechas establecidas”

15.  El sistema genera un número de reserva

16.  El sistema almacena la información de la reserva

17.  El caso de uso termina

Aquí caímos en la típica descomposición funcional que se debe evitar durante la etapa de requisitos. Los pasos 12 a 17 bien pueden reemplazarse por:

12. El sistema verifica que hay asientos disponibles y muestra el número de reserva.

13. El caso de uso termina

¿Y qué se hicieron las otras especificaciones? ¿Será que los programadores son capaces de inferirla? No. Estos otros detalles pueden documentarse como requisitos especiales en el caso de uso o como elementos de diseño (por ejemplo, estableciendo en un diagrama de secuencia cuáles son las entidades de almacenamiento de información o el algoritmo para generar el número de la reserva). Nótese que estos aspectos no son relevantes para el negocio.

Diez Consejos Útiles y Simples Para Escribir Correctamente Casos de Uso Correctos, I

“Todo debería hacerse lo más simple posible, pero no más simple.”

Frase atribuida a Albert Einstein

Presentación

Un caso de uso es un protocolo, en el sentido de conversación, normalmente entre un ser humano y un sistema de software y, como cualquier conversación en idioma español, debe ser fluida, sin tropiezos, en la que se usen términos y expresiones familiares o entendibles por los participantes. Durante esa charla, el sistema “solicita de”, “proporciona a”, o “procesa[1] información para”; mientras tanto, la persona que actúa como interlocutor suministra a, o requiere de, información. Es así de simple.

Ahora bien, la especificación de un caso de uso es una historia que escenifica las distintas situaciones que se pueden presentar en el diálogo antes mencionado. Y como historia, debe contarse de manera directa, sin adornos (adjetivos) y con objetividad. El autor del caso de uso, normalmente un Ingeniero de Requisitos, debe mantenerse al margen de los hechos, no debe hacer comentarios o dar explicaciones (sus percepciones) al respecto, no debe involucrarse en la historia.

Con todo lo anterior en mente, les traigo estos diez consejos que espero sean muy útiles a la hora de especificar requisitos de software vía casos de uso. Son lecciones que he aprendido con el tiempo y con la práctica y que me han funcionado bastante bien.

Consejo 1

Al escribir casos de uso se deben evitar términos como:

·         Automáticamente

·         Procesar

·         Administrar

·         Gestionar

Y sus sinónimos.

Automáticamente, relativo a automático,  se refiere a una cualidad que todos los sistemas tienen de manera intrínseca, que está en la naturaleza del software, ya que este sigue a determinadas circunstancias de un modo inmediato y la mayoría de las veces indefectible, es decir, cualquier cosa que hace el software es iniciada por un impulso externo, incluyendo los llamados “procesos automáticos” cuyo inicio obedece muchas veces al cumplimiento de una condición de tiempo, o sea, se ejecutan a una hora específica programada por una persona, o a un prerrequisito, es decir, otra acción o proceso se llevó a cabo y preparó los insumos necesarios para la tarea siguiente. Siempre hay un estímulo que precede a la acción automática.

Entre tanto, Procesar es una expresión genérica, abstracta por demás, que indica cualquiera de las operaciones que puede hacer un sistema de software y siempre debe reemplazarse por el nombre de la operación particular a la que queremos referirnos. Por ejemplo, hacer un cálculo, realizar una búsqueda, clasificar datos y almacenar datos. Ahora bien, es posible que el sistema realice más de una de estas acciones al tiempo o haga una combinación de varias de ellas, pero este es un asunto que abordaré en el consejo número seis.

Por su parte, Administrar y Gestionar son sinónimos entre sí y, al igual que Procesar, son comodines en el sentido de que sirven para acomodar cualquier acción o manipulación sobre la información; siempre debemos nombrar explícitamente la acción, como Transferir o Enviar, Recibir, Validar una condición específica y Generar o Mostrar datos, o el tipo de manipulación, como Ingresar, Modificar, Eliminar y Consultar datos.

Ejemplo

Consideremos el siguiente caso de uso típico para ingresar a un sistema transaccional con seguridad simple:

Caso de Uso: Ingresar al sistema

Actor: Cliente

Secuencia Básica:

1.     El caso de uso inicia cuando el Cliente decide autenticarse ante el sistema

2.     El sistema solicita el nombre de usuario del Cliente

3.     El Cliente ingresa el nombre de usuario

4.     El sistema solicita la contraseña del Cliente

5.     El Cliente ingresa su contraseña

6.     El sistema procesa el nombre de usuario y la contraseña y presenta un mensaje de bienvenida

7.     El caso de uso termina

En esta secuencia, el paso 6 debe modificarse por algo como:

6. El sistema verifica la información proporcionada y presenta un mensaje de bienvenida.

Nótese que este es el escenario “feliz” donde los datos ingresados por el usuario son correctos y el sistema permite su ingreso al sitio transaccional. Aquí “verifica” es sinónimo de “comprueba” o “identifica”, un significado más directo que el derivado de “procesa” en el caso de uso original.

---

[1] Estoy usando “procesar” en un sentido amplio, significando cualquiera de las funciones comunes que desempeña un computador, como calcular, buscar u ordenar datos, o una combinación de dos o más de estas.

Gerencia de Proyectos Dirigida por Riesgos: la estrategia del Maestro de ajedrez

No me gustan los artículos sobre Gerencia de Proyectos. Casi todos siguen la receta de “Cómo hacer esto o aquello”, “Cómo escribir un artículo de gerencia de proyectos”: 1) encuentra un tema sobre el cual escribir, donde incluso te dicen que puesto que eres un gerente de proyectos, trata el proceso de escribir el artículo como un proyecto; 2) organiza tu artículo, donde debes planear el alcance y ejecutar el plan, es decir, escribir la crónica y, por supuesto, cerrar el proyecto, que se traduce en publicar el artículo. Y luego te dan ideas de cómo mejorar el artículo y cosas así. De hecho, existen las recetas para que mantengas la certificación como PMP (PMI) escribiendo artículos sobre gerencia de proyectos “¡y ganas 15 créditos PDU!”

Y los que no son así, son escritos por autores cuyos proyectos han sido todos fallidos y quieren que nosotros no cometamos los mismos errores que ellos. Estos autores nos dicen precisamente que cuando llegaron al fondo, tuvieron una epifanía que ningún otro ser humano tuvo hasta entonces, así es que decidieron compartir su experiencia divina con el resto de los mortales. Son reseñas usualmente repetitivas, simples y, algunas, hasta absurdas.

Por eso no me gustan esa clase de trabajos, pero este artículo que les voy a recomendar, sobre gerencia de proyectos, tiene la palabra “paritariamente”. ¿Qué significa “paritariamente”? Eso quizás no es importante, el asunto realmente interesante es que este artículo tiene palabras de más de tres silabas y frases con sentido completo, de esas que aprendíamos mientras leíamos a los Clásicos antiguos o a Don Quijote de la Mancha. Este artículo se atreve a mencionar el juego de Ajedrez y hace una comparación entre la mente de los gerentes de proyectos y la de los grandes maestros del juego ciencia, habla de estrategia y la diferencia de la táctica, habla de la anticipación (palabras de más de tres silabas) y presenta el análisis pre-morten (frases con sentido completo), es decir, de prever algo y manejarlo antes de su ocurrencia.

Incluso este artículo se atreve a desmentir la muy archi-popular Ley de Murphy y nos presenta la primera Ley Anti-Murphy o Ley de la Proactividad, inclusive se atreve a decir que la mejor herramienta de administración de proyectos no es un sistema de software. El artículo va más allá de las herramientas automatizadas y le otorga confianza a la mente humana (la mente de los grandes maestros).

Por eso me gusta este artículo, llamado “Gerencia de Proyectos Dirigida por Riesgos: la estrategia del Maestro de ajedrez”. El artículo lo encuentran en el portal especializado LiderdeProyecto.com, en la dirección:

http://www.liderdeproyecto.com/articulos/gerencia_de_proyectos_dirigida_por_riesgos_la_estrategia_del_maestro_de_ajedrez.html

Ah, se me olvidaba decirles, yo soy el autor del artículo. ¡Por eso también me gusta!