Dicen el Dr. Jacobson y sus colegas
que la materia prima de Casos de Uso 2.0 son los requisitos del software, el producto
de software mismo y las pruebas que demuestren que el producto obedece a esos requisitos
y los ejecuta a cabalidad.
En el corazón de Casos de Uso 2.0
están el caso de uso, la historia y la porción de caso de uso. Estos elementos
capturan los requisitos y conducen el desarrollo del sistema. La Figura muestra como estos conceptos
están relacionados entre sí. También muestra como los cambios y los defectos
impactan el uso de Casos de Uso 2.0. [1]
Mapa Conceptual de Casos de Uso 2.0. Fuente: eBook "Use Case 2.0", Jacobson
y otros.
Ya he hablado lo suficiente sobre Requisitos en general y de Casos de Uso en particular, así que
hablemos de los demás conceptos que aquí encontramos:
Los Interesados
son todas aquellas personas que de una u otra manera impactan del proyecto y se
ven afectados por este y por el producto que se está construyendo. Todos ellos
influencias directa o indirectamente al proyecto y no solo incluyen a los
usuarios del sistema, sino también a los patrocinadores, a los ejecutivos, a
otras áreas de la organización y a entidades externas relacionadas de alguna
forma con la organización. A todos hay que tenerlos en cuenta a la hora de
delimitar las funciones del sistema.
Uno de los principales mecanismos de
comunicación entre los Interesados y el equipo de construcción es que los
primeros nos cuenten historias a los segundos, sus Historias. Son narrativas acerca de lo que hacen y como lo hacen,
con qué, con quién interactúan y qué intercambian. Estas narrativas son el alma
de los casos de uso (no confundir con Historias de Usuario que son un
repositorio de esas historias, como los son los casos de uso, los requisitos en
prosa, los prototipos, los tableros de historias, entre otros).
En todo proyecto siempre hay Cambios, ya sea porque cambian las
políticas de la organización, cambian las expectativas de los usuarios, cambia aspectos
legales o contables, o cambian los interesados o los usuarios y estos últimos
quieren otra cosa. Estos cambios seguramente modificarán las historias y, por
consiguiente, los requisitos y los casos de uso. Incluso pueden requerir nuevas
historias. Los cambios pueden llegar en cualquier momento y las porciones de
casos de uso son una buena forma de analizar su impacto en el proyecto y de
incluirlos en el producto.
Las Pruebas
nunca deben faltar. Es lo único que asegura la calidad total del producto y
deben verse como algo intrínseco al ciclo de vida del software. Como el
software se implementó vía porciones de casos de uso, que ya incluyen los casos
de prueba en su especificación, esta unión “software-pruebas” se hace
finalmente indivisible, es uno de los grandes aspectos que nos enseña Casos de
Uso 2.0 y una práctica excepcional. El hecho de que las pruebas hagan parte de
la especificación de las porciones de casos de uso es a todas luces un paso más
allá hacia la solución de una gran cantidad de inconvenientes que encontramos
durante la práctica diaria de la construcción del software. Incluso, de esta
forma, es posible implementar prácticas como Desarrollo Conducido por Pruebas
(TDD por sus siglas en inglés –Test Driven
Development) y otros métodos ágiles de desarrollo de software.
Durante las pruebas encontramos Defectos y mientras estos existan sabremos
que la porción de casos de uso actual no está finalizada. Los defectos pueden
ser encontrados durante una revisión par, en etapas tempranas del ciclo de vida
e incluso de la iteración actual, durante la misma programación del sistema, con
las pruebas unitarias u otro tipo de pruebas del programador, o mientras
realizamos las pruebas de calidad final de cada porción de caso de uso y las
pruebas de integración del sistema. En este punto juegan un papel muy
importante el uso de herramientas para automatizar pruebas, como los Robots de
pruebas.
Estos son algunos de los conceptos más
importantes, inherentes a las prácticas expuestas en Casos de Uso 2.0. En el
libro electrónico de Jacobson [1] encuentran más detalles sobre este modelo
conceptual.
Referencias:
[1] El e-Book
"Use Case 2.0", sobre las buenas prácticas alrededor del uso de los
casos de uso, lo pueden encontrar en www.ivarjacobson.com.
Sobre Casos de Uso 2.0 pueden leer mi serie
de artículos en este Gazafatonario:
http://www.gazafatonarioit.com/2012/04/casos-de-uso-20-y-metodos-agiles.html
http://www.gazafatonarioit.com/2012/04/quiero-una-porcion-de-caso-de-uso.html
Sobre Casos de Uso pueden leer toda mi
sección de Lecturas
Fundamentales en este mismo Gazafatonario, empezando en:
Hola Lucho... excelente mapa y descripción del mismo. La verdad no estan lejos las historias de usuario de las porciones de casos de uso.
ResponderBorrarPuedes compartir un ejemplo de cada uno de los elementos te tu mapa? sería genial.
(aclarando que es lo primero que leo sobre este tema) tengo varias preguntas:
¿es necesario que existan casos de uso para que hayan porciones de casos de uso?
¿o puedo definir porciones de casos de uso y luego subir a casos de uso, realizando una síntesis?
Seguiremos en contacto.
Hola Jorge, en la sección de Referencias al final del artículo, hay enlaces a otros artículos sobre el mismo tema en este mismo Gazafatonario y el enlace al libro de Jacobson sobre el tema. Está disponible para descargar. En los próximos días estará en español en ese mismo sitio.
ResponderBorrarOtro artículo donde hablo del tema lo encuentras en: ¿Por qué existe Casos de Uso 2.0?
Y, finalmente, en este otro artículo exploro en detalle el tema de las porciones de casos de uso, Todavía Otra Lección Más Sobre Porciones de Casos de Uso.
Donde respondo algo de tu pregunta. En resumen, se puede hacer de las dos formas: primero el caso de uso, pero apenas esbozado y, a partir de allí, van surgiendo sus porciones. O al contrario. Te recomiendo este último artículo que te digo.
Sobre los ejemplos del mapa conceptual estoy escribiendo un artículo más.
Salud@s.