Buscar en Gazafatonario IT

miércoles, febrero 06, 2013

Todavía Otra Lección Más Sobre Porciones de Casos de Uso


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:
  1.    Tareas antes del desarrollo
  2.    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:


3 comentarios:

  1. Está interesante esto de representar y documentar los aspectos mas relevantes de un desarrollo para ganar tiempo y comunicar a cada parte lo debe saber.

    ResponderBorrar
  2. Me gustaria saber que opina y si le parece util, tal vez postear algo sobre la metodología UWE (UML basado en la Web).
    http://uwe.pst.ifi.lmu.de/teachingTutorialSpanish.html

    ResponderBorrar
  3. Martín, gracias por tus notas.

    Sobre UWE y temas similares estoy preparando un artículo más general sobre el tema de los perfiles (profiles) de UML, que es la base de UWE. Un perfil es, por definición, un subconjunto de la vasta notación de UML aplicado a un dominio particular (por ejemplo, para modelar aplicaciones Web), lo que constituye una ventaja para el equipo de construcción del software puesto que sólo debe lidiar con elementos específicos o subyacentes al problema que los ocupa.

    En algunos días encontrarás el artículo en este mismo Blog.

    Saludos,

    Lucho

    ResponderBorrar