En el proceso de desarrollo guiado por casos de uso, los analistas de requerimientos enfrentan una tarea sumamente complicada, escribir casos de usos para los interesados. Digo que es complicada dado que las espectativas de cada uno dce los interesados varia y en algunos momentos estas se sopreponen.
¿Quienes son los interesados?
En el desarrollo de software a la medida podemos llegar a encontrar los siguientes interesados a medida que este se contruye: usuarios, arquitectos. diseñadores, testers, estimadores. Como pueden ver el caso de uso a través del tiempo va ha ser observado por diferentes roles y cada uno con diferentes espectativas sobre el documento.
Casos de uso para usuarios
Esta es una de las audiencias mas complicadas a los cuales se les debe escribir, y la razón es por que muchos dicen, sin importar como se escriba, “ESTA BIEN”. Algunos usuarios no tienen la educación adecuada para leer casos de uso y para ellos se vuelve complicado criticar el caso de uso. El caso de uso debe básicamente estar escrito en el idioma del usuario, pero por mas que se ponga el empeño en esto, se terminara incluyendo terminos a los que el usuario en su vida pudo haber esuchado(actor, poscondiciones, disparadores, includes, etc).
Casos de uso para Tester
“Los casos de uso deben ser escritos para ser probados”. Antes y despues de escribir el caso de uso me he detenido a pensar como podria probarlo, y algunas veces lo he reescrito para tratar de que los tester puedan tener buenas rutas para ser probadas. Sin embargo algunas veces no me ha sido posible reescribirlo y se que como está escrito al teste le costará trabajo armar sus casos de prueba. Encontre la siguiente frase en Pruebas de sistemas orientadas a objetos
Un caso de prueba elaborado incluye:
- Un nombre que identifica el caso;
- Sus entradas: es la secuencia exacta de acciones que debe realizar el usuario para ejecutar ejecutar el caso de prueba. Note que si las acciones involucran introducir valores, deben especificarse los valores exactos que deben introducirse;
- Su salida esperada: Los resultados exactos observables que debe producir el sistema al ejecutar el caso de prueba.
Si el analista escribe las entradas y salidas exactas, la especificación del caso de uso se vuelve dispendiosa y hasta tediosa de leer. Sin embargo si no se hace se pueden presentar fallos en la especificación. Usualmente lo que he realizado son especificaciones suplementarios para detallar esta parte. Pero como pueden ver existen tendencias que indican que esto debe ir en los casos de uso.
Bueno por hoy dejaré aca, cuidense
Como todo artefacto que se genera dentro de la ingeniería de software moderna, los casos de uso deben ser escritos para la audiencia que participa en la siguiente etapa que se defina en el proceso para cada contexto u organización envuelta en desarrollo de software. Los casos de uso adolecen de ser una herramienta tan genérica y de expresión tan libre que se evidencia uso y abuso sobre el modelado con éstos. Por eso nunca debe extralimitarse el alcance de su nivel de detalle o elaboración, al contexto en el cual son creados. El reto en sí, es lograr optimizarlos para satisfacer las necesidades de cada stake-holder que lo recibirá como insumo.
Como dice jorge, a los casos de uso se evidencia el uso y el reabuso, dado que muchos les han dado el lugar de reyes en el mundo de la especificacion. Pero que significa extralimitarse? que pasa si tienes un equipo lleno gente junior, debes hacerlo? o que pasa si el usuario se niega aprobarte el caso de uso si no tiene el detalle exhaustivo?
La definición del proceso debería especificar la audiencia y las exigencias que se deben aplicar a los casos de uso, a modo que satisfaga las necesidades de personas tanto del lado de los usuarios como del lado del desarrollo. Ahora bien, si uno tiene un equipo plagado de gente junior ya la problemática radica en la incapacidad de la organización para hacerse del staff más efectivo para sus proyectos; la carencia de habilidad de las personas del equipo para leer el artefacto que es insumo de su labor no debería ser una excusa para sobrecargar el artefacto de información, ésto debe ser más atacado con estrategias de coaching.