“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.
Excelentes consejos, gracias
ResponderBorrarIng. Daniel Ayala
Excelentes Consejos, gracias.
ResponderBorrarSaludos
Ing. Daniel Ayala
Daniel, muchas gracias por el mensaje.
ResponderBorrarSaludos.
Tengo una duda, considerando el caso de uso de ejemplo de este articulo, pero desde el punto de vista de un alta de usuario y suponiendo que hay una propiedad mas que seria "Es administrador" y que solamente tendria dos opciones (SI/NO).
ResponderBorrar-El sistema solicita el tipo de usuario
-El Cliente informa si el Usuario es o no Administrador
Considerando este y otro articulo, desde mi punto de vista veo 2 temas que recomendas EVITAR.
Tomando en cuenta la secuencia correspondiente al Cliente.
Creo que en este caso habria un poco de logica (IF) y tambien se estaria decidiendo ya un checkbox.
Mi pregunta seria, si estoy en lo cierto, como representar mejor esto.
Este comentario ha sido eliminado por el autor.
ResponderBorrarHola Toki.
ResponderBorrarEn cualquier caso no tendríamos que mencionar un “checkbox” para nada.
Es posible que tengamos un caso en el que haya que adicionar una secuencia alternativa al caso de uso, pero eso se daría solo si el comportamiento del sistema cambia una vez que el valor de la propiedad es proporcionado. Por ejemplo, si cuando el usuario es Administrador el sistema hace una cosa que sea “observable” para el usuario y cuando no lo es hace otra. Pero si no hay ninguna validación o comportamiento especial, el caso de uso simplemente adiciona dos pasos más a la secuencia básica:
El sistema solicita el tipo de usuario,
El cliente proporciona el tipo de usuario
Si se da el primer caso que menciono (comportamiento distinto para cada opción) entonces podemos proceder así:
6. El sistema solicita el tipo de usuario
7. El cliente indica que es Administrador
8. [AQUÍ VIENE LO QUE EL SISTEMA HACE CUANDO EL CLIENTE ES ADMINISTRADOR]
N. El caso de uso termina
Secuencia Alternativa 1
7A. El Cliente indica que es usuario regular
7A1. [AQUÍ VIENE LO EL SISTEMA HACE CUANDO EL CLIENTE NO ES ADMINISTRADOR]
M. El caso de uso continúa en el paso N de la secuencia básica
Saludos,
Gracias por la respuesta Lucho.
ResponderBorrarExcelentes los materiales
Lucho. Tengo una inquietud. Regularmente ese "gestionar" lo usan como dices, como un comodin. Pero cuando se usa puede ser para agrupar la creación, modificación, elimininación de lo que se busque con el caso de Uso. Es mejor entonces separar estos y no tener un CU de gestión de?
ResponderBorrarGracias!
En general, "Gestionar" es un término amplio que puede significar a veces más cosas de las que queremos. Entonces es mejor evitarlo. En la práctica es mejor tener un caso de uso por cada una de las transacciones de Adición, Modificación, Eliminación y Consulta, lo que pasa es que nos da pereza física y mental hacerlo.
BorrarAunque, de hecho, si la transacción es "plana", en el sentido de simple, directa, sin reglas de negocio adicionales, quizás ni siquiera sea necesario tener un caso de uso para cada una de ellas ni para todas como grupo. Recordemos que el objetivo de los casos de uso es que haya consenso en lo que se va a construir (consenso en todas las personas del equipo y los interesados) y que todos entiendan lo mismo. Si esto se logra por otros medios, bienvenido.
Saludos,