La metodología requiere que es incluyan “Casos de Uso” en el Análisis de un sistema, pero… ¿tenemos claro realmente qué son los casos de uso? ¿Por qué se hacen? ¿Para que sirven?
Una historia ficticia (no tanto)
Empezaré contando una historia ficticia: Julián fue a encargarse un coche a medida. Puso varios requisitos: que fuera blanco, con techo solar, que no fuera muy contaminante y que tuviera lector de MP3 para escuchar música. Cuando tres meses más tarde fue a buscar su “coche”, le entregaron en el taller esto:
Julián no estaba muy convencido, pero los del taller le insistieron de que era lo mejor y que además cumplía con todos los requisitos que habían acordado y que él mismo había firmado de su puño y letra. Al final, como necesitaba el coche urgentemente se lo llevó… No llegó muy lejos porque el gas propano del pequeño depósito se acabó enseguida. Julián no estaba nada contento… “Yo quería este coche para irme en verano a la playa y para ir a trabajar todos los días y ¡ni siquiera puedo ir al Carrefour a hacer la compra! ¡no tiene maletero!” Los del taller le respondieron: “acordamos unos requisitos y este coche cumple con todos, no dijimos nada de llevar maletas o la compra, si no puedes usar el coche para ir al Carrefour lo siento mucho, tenías que habérmelo dicho desde el principio”
| Requisitos | Casos de Uso |
| El coche será de color blanco | Usuario - Ir a trabajar todos los días |
| El coche tendrá un techo solar | Usuario - Ir a la playa en verano |
| El coche no consumirá combustible diesel | Usuario - Ir al carrefour a hacer la compra |
| El coche tendrá lector de MP3 que permitirá escuchar música | |
Los casos de uso se inventaron para evitar la situación en la que,
con la mejor intención, se recoge una lista de requisitos detallados con todo cuidado,
se negocian y acuerdan con el usuario durante largo tiempo,
se diseña, construye y prueba el software respetando escrupulosamente esos requisitos
y al final, el software resultante NO SIRVE PARA NADA
y además, no sabemos cómo hemos llegado a esta situación.
Si, vale, pero… ¿Qué son los casos de uso?
La definición académica dice que: “Es la descripción de una secuencia de eventos que, tomados en conjunto hacen que un sistema haga algo de utilidad para un usuario”. En UML se representan así:
En lenguaje corriente, un caso de uso responde a la pregunta: “¿Para qué necesita el usuario el sistema?” “¿Qué quiere hacer con el sistema?”. Los usuarios de Microsoft Word no quieren cambiar la fuente del texto, ni cortar y pegar palabras, ni corregir textos ortográficamente. Estas acciones, aunque necesarias, no son útiles en si mismas. Los usuarios, lo que realmente quieren es escribir cartas, redactar informes o preparar documentos técnicos, para declarar su amor, conseguir presupuesto para su departamento o vender un producto. Y la mayoría de usuarios si pudieran hacerlo sin utilizar un ordenador, lo harían.
Entonces … ¿Cómo se utilizan?
Vale… ya sabemos lo que es un caso de uso… pero ¿cómo se utilizan? ¿cómo identifico los casos de uso de un sistema y cómo me ayudan a evitar el desastre de trabajar durante meses y que al final no sirva para nada?
En primer lugar, para identificarlos hay que hablar con los usuarios en su propio lenguaje y no forzar al usuario a que haga nuestro trabajo de determinar los requisitos que mejor se ajustan a sus necesidades. No le preguntes cuantos asientos quiere en su coche, sino cuantos hijos tiene y si piensa aumentar la familia o llevar a la abuela. No le preguntes el tamaño del coche, sino si tiene plaza de garaje o si va a hacer viajes largos o cortos. El desarrollador es el experto en sistemas de información, y debe tomar la responsabilidad de hacer un buen sistema. Hay que construir el sistema que el usuario “necesita”, no el que el usuario “quiere” o “cree que quiere”. De todo lo que nos diga el usuario debemos filtrar las necesidades reales y no cerrar requisitos anticipadamente. Si el usuario dice: “necesito una BB.DD. Oracle”, probablemente tenga razón y realmente la necesite, pero debe ser el desarrollador el que decida si las necesidades, los casos de uso justifican realmente una BBDD y si Oracle es el mejor fabricante.
Una vez que tenemos claros los casos de uso del sistema, y los tenemos priorizados identificaremos los requisitos que el sistema debe cumplir para que los casos de uso se puedan completar. Habrá requisitos explícitos “quiero el coche blanco” e implícitos (de los que nadie se acuerda inicialmente pero que son esenciales para que el sistema sirva de algo), Por ejemplo: para el caso de uso “ir a la compra con el coche”, tengo que poner varios requisitos: “queremos un coche”, “que pueda circular por las calles de la localidad donde vive el usuario”, “que pueda cargar la compra cómodamente”, “que sea fácil de aparcar”, “que tenga una autonomía suficiente para al menos llegar desde mi casa hasta el hipermercado”. Si consideramos el caso de uso “ir a la playa en verano”, muchos requisitos serán repetidos “queremos un coche”, otros serán parecidos “que pueda cargar el equipaje cómodamente” y otros serán totalmente nuevos “quiero aire acondicionado”.
Ya tengo los Casos de Uso y los requisitos ¿por donde empezamos a desarrollar?
Los casos de uso son una buena forma de “ordenar” el trabajo de desarrollo. En lugar de empezar por el primer requisito y terminar por el último, debemos empezar por el caso de uso más importante o prioritario, implementando los requisitos necesarios para completar este caso de uso.
Durante el desarrollo, se toman a diario muchas pequeñas (o grandes) decisiones que no están especificadas en los requisitos. (p.ej. “¿Qué tamaño debe tener el depósito de combustible?”). Si al tomar cada pequeña decisión no tenemos presentes los casos de uso, corremos el riesgo de hacer que el sistema no sea utilizable (no se puedan completar los casos de uso) aun a pesar de cumplir todos los requisitos que habíamos identificado explícitamente.
¿Y si hay cambios?
Cuando alguien (el usuario o un desarrollador) proponga cambios en los requisitos, tenemos que contrastarlos con los casos de uso, para ver si el cambio se justifica con la utilidad que se le piensa dar al sistema o es solamente una ocurrencia. A veces al examinar requisitos a la luz de los casos de uso vemos que son innecesarios o menos prioritarios de lo que parecía (por ejemplo Gmail no tiene carpetas para organizar el correo… el usuario no quiere organizar su correo en categorías, lo que realmente quiere es encontrar los correos antiguos cuando los necesita)
Y también las pruebas
Otra utilidad importante de los Casos de Uso es que ayudan a organizar y planificar las pruebas. El equipo de pruebas puede seguir la secuencia de eventos documentada en el caso de uso y verificar si el sistema, efectivamente, sirve para lo que hemos dicho que sirve o hay algo que lo impida. Esta forma de probar es mucho más útil que probar requisito a requisito. Como ya hemos dicho, podemos tener un sistema con el 90% de los requisitos implementados de acuerdo a la especificación y que la utilidad del sistema sea el 0% porque no se puede completar ningún caso de uso. Lamentablemente tener completado el 100% de los requisitos no garantiza la utilidad del sistema.
En resumen
Los casos de uso ayudan a que las entrevistas entre desarrollador y usuario se lleven a cabo en el lenguaje del usuario, centrándose en la utilidad prevista del sistema, en lugar de negociar requisitos aislados que tomados por separado no tienen ningún sentido.
Además, ayudan a identificar los requisitos “ocultos” o “implícitos” que se dan por supuesto por parte del usuario y que deben ser tenidos en cuenta por parte del desarrollador.
Sirven para ordenar y priorizar las tareas de desarrollo, para implementar primero los requisitos necesarios para completar los casos de uso más importantes y prioritarios.
Finalmente son una buena forma de organizar y planificar las pruebas. Podemos evaluar el grado de avance de una aplicación por el número de casos de uso completados, es decir por la cantidad de cosas útiles para el usuario que es capaz de hacer.
Epílogo
El ejemplo del “coche” que no sirve para ir a hacer la compra puede parecer exagerado, pero en este caso se aplica lo de que la realidad siempre supera a la ficción. Yo he visto con mis propios ojos a un desarrollador explicarle al Director de Tecnología de Correos que con el flamante sistema GIS que le estaba desarrollando se podían cambiar las rutas de los carteros pero no se podía buscar la ruta que le correspondía a un cartero e imprimirla en un papel. “No estaba en los requisitos” fue su explicación.
