Ya sabemos que Casos de Uso 2.0 es una
práctica escalable y ágil que usa casos de uso y porciones de casos de uso para
conducir el desarrollo incremental de sistemas de software. Sabemos que
cualquier tipo de equipo de desarrollo lo puede usar, desde uno pequeño y local
hasta uno grande y distribuido en varias locaciones, en cualquier tipo de esfuerzo de desarrollo,
desde la construcción de productos nuevos y simples hasta la elaboración de
productos complejos o multisistemas, con cualquier enfoque metodológico, desde
la tradicional cascada, hasta enfoques conducidos por bitácora de requisitos.
También sabemos que la porción de caso
de uso es el elemento más importante de Casos de Uso 2.0. Una porción de casos
de uso nos permite construir los sistemas de manera incremental, por partes,
conduciendo todo el esfuerzo, desde el análisis del caso de uso, de una o
varias porciones del mismo, pasando por el diseño de la porción, es decir, la
realización del caso de uso (de la porción), para luego ir a la implementación
de la porción, hasta someter el software a la verificación vía casos (scripts) de prueba; todo, en un ciclo
corto de desarrollo, por ejemplo, una iteración de dos semanas o de un mes
calendario.
Las porciones están
compuestas de historias y de sus casos de prueba asociados, es decir, hay una
sindicación entre las historias de un caso de uso y los casos de prueba que son
las que finalmente verificarán que la porción del caso de uso está bien
construida y satisface las necesidades del usuario. Esta compilación de
historias y de casos de prueba tiene un valor claro que es entendido y acordado
por los usuarios y los demás interesados en el producto. Por ejemplo, la
siguiente figura muestra un caso de uso típico de un sistema de publicación de
un periódico digital, con sus atributos más relevantes, y algunas de sus
porciones, que podrían implementarse en una iteración.
Propiedades de un Caso de Uso y de
algunas de sus Porciones en notas Post-it.
(Haga clic en la imagen para ampliarla)
Esta imagen, que muestra
un tablero “repleto” de notas post-it,
donde cada nota muestra el caso de uso con sus propiedades o la información
destacada de cada una de sus porciones. En estas últimas, vemos un
identificador de la porción (número y descripción), los flujos del caso de uso
que forman la porción, es decir, las historias, donde FB es Flujo Básico, y A1,
A2, etc., son las secuencias alternativas del caso de uso. Y también
encontramos los casos de prueba, estos son los escenarios que finalmente
comprobarán que la implementación de la porción fue exitosa.
No es necesario que estén
todos los casos de prueba para verificar la porción, en términos generales, una
historia y un caso de prueba serán suficientes para tener algo de valor para el
usuario y empezar a entregar el sistema mediante incrementos. Finalmente, los
números grandes en la esquina inferior derecha de cada nota post-it representan el esfuerzo que toma
implementar esa porción. Es un estimado que puede realizarse con cualquiera de
las técnicas habituales de estimación: puntos de historia, juicio de expertos,
la estimación de Fibonacci, etc. Lo bueno de las estimaciones es que no tienen
que ser exactas la primera vez, por eso se llaman estimaciones. ¡Si solo
entendiéramos eso!
Un
Ejemplo de Porciones de Casos de Uso
Con todo esto en mente,
veamos un ejemplo característico de una de las actividades principales que
incluye Casos de Uso 2.0: Preparar una porción de caso de uso. Si usamos el
enfoque iterativo y una bitácora de requisitos, podemos dividir las tareas en
dos grandes grupos:
- Tareas
antes del desarrollo
- Tareas
en cada iteración
En el primer grupo, Casos
de Uso 2.0 propone las actividades típicas de Encontrar Actores y Casos de Uso,
para conocer el “cuadro” completo, es decir, tener una visión de lo que será el
sistema de software; pero a continuación, Casos de Uso 2.0 incluye la práctica
de Dividir los Casos de Uso y la de Preparar una Porción de Caso de Uso. Entre
tanto, las tareas del segundo grupo se muestran en la figura a continuación:
Actividades de Caso de Uso
2.0 para Enfoques de Desarrollo Iterativos
Fuente:
Libro-e Use Case 2.
0 Jacobson y otros.
(Haga clic en la imagen para ampliarla)
En el caso de los actores
y casos de uso, la figura siguiente muestra un subconjunto del modelo de un
sistema de publicación de un periódico digital. Nómina y Facturación son dos
ejemplos de actores que no son personas, son sistemas de software, externos al
sistema que se está construyendo. Por su lado, Editor, Periodista, Bloguero y
Lector, representan actores persona, grupos de usuario del software. Cada uno
de estos tiene asociados uno o más casos de uso.
Diagrama (parcial) de
Casos de Uso de un Sistema de Publicación de un Periódico Digital
(Haga clic en la imagen para ampliarla)
Para ilustrar el ejemplo de las
porciones, tomemos el caso de uso Comprar Artículo, ejecutado por el Lector del
periódico. A continuación muestro la narrativa del caso de uso.
Narrativa
del caso de uso Comprar Artículos de un sistema de información de publicación
de un periódico digital
(Haga clic en la imagen para ampliarla)
Lo que sigue es encontrar algunas de
las historias del caso de uso con las que podamos iniciar el desarrollo, no de
todo el caso de uso, pero sí de algunas de sus partes que tengan valor claro y
entendido para el usuario.
Algunas historias del caso
de uso Comprar Artículos del Sistema de publicación digital
(Haga clic en la imagen para ampliarla)
Notamos que algunos de los flujos
están definidos explícitamente en la narrativa del caso de uso, mientras que
otros como el A8 y el A9 no lo están. Estos cabrían dentro del grupo “etcétera”
de la narrativa. Observamos también que el flujo básico es suficiente para
tener una historia con sentido completo, de valor para el usuario. A esta
historia le podemos “sumar” uno o más casos de prueba y estamos listos para
construir una pequeña parte del software que tiene un peso bien definido para
los usuarios.
Algunas porciones del caso
de uso Comprar Artículos del Sistema de publicación digital
(Haga clic en la imagen para ampliarla)
En este cuadro vemos algunas de estas
porciones para el caso de uso Comprar Artículos. Esto completa el trabajo de
dividir el caso de uso. A continuación, preparamos la porción, digamos la
primera de ellas, hacemos una estimación del esfuerzo que nos tomará someterla
al resto del ciclo de vida durante una iteración y seguimos con el proceso:
diseño (realización), implementación y verificación y, finalmente, demostración
del producto (parcial) a los usuarios.
Conclusión
En el pasado hemos visto como un caso
de uso puede llegar a ser lo suficientemente grande y complejo como para que se
pueda implementar en una iteración corta. Las porciones de casos de uso
proporcionan el medio y la coherencia de artilugios de las metodologías ágiles,
como las historias de usuario, con el poder del modelado de los casos de uso
para que no perdamos de vista el alcance completo del producto de software que
estamos construyendo, permitiendo fabricar en un ciclo corto (una iteración de
muy pocas semanas a un mes) una parte del producto que tiene valor
significativo para los usuarios.
De esta manera es posible, por
ejemplo, usar la práctica de Casos de Uso 2.0 con un marco de trabajo ágil como
Scrum o con otros enfoques como AUP u otras metodologías livianas. Pero de este
asunto hablaremos en los próximos días, cuando les presente La Esencia de la
Ingeniería de Software.
Nota:
Esta entrada se puede descargar como
artículo para su libre distribución, haciendo clic en:
