Mitos, Monstruos, Leyendas Urbanas y otros Desvaríos de Ágil y Scrum

La mitología es un conjunto de mitos relativamente cohesionados: relatos que forman parte de una determinada cultura. Los mitos son relatos basados en la tradición y en la leyenda, creados para explicar el universo, el origen del mundo, los fenómenos naturales y cualquier cosa para la que no haya una explicación simple [1]. En el bestiario mitológico de la humanidad encontramos seres fantásticos que nos hacen soñar o morir de miedo: el Dragón, el Fénix, el Grifo, el Kraken, el Cancerbero, la Hidra, el Minotauro, la Escila, el Pegaso y la Sirena, para citar algunos de los más arraigados en nuestros temores y pesadillas.

Se trata de esa necesidad inherente al ser humano de aferrarse a lo desconocido y a lo sobrehumano para entender mejor la realidad que lo rodea, o simplemente para escaparse de esta. En el caso de los métodos de software, por ejemplo, estas aprehensiones tienen su origen en la falta de conocimiento teórico-práctico sobre algo específico, en el miedo o rechazo al cambio o en la fobia a equivocarse de quienes practicamos el desarrollo de software. Lo que haré a continuación es mencionar brevemente algunos de estos arquetipos quiméricos que pululan en el universo de los métodos ágiles en general y de Scrum en particular.

Ágil no necesita documentación

¡Esta es la madre de todas las entelequias! Su origen está en ese valor expuesto en el Manifiesto Ágil que reza: “valoramos software funcionando sobre documentación extensiva” [2]. En ninguna parte del manifiesto dice que no se hace documentación, esta debe elaborarse justo cuando se necesita y solamente la suficiente y necesaria y en los formatos más adecuados, que llegue al público interesado, que entregue valor a la organización. Y siendo consecuentes con el primer valor del manifiesto, esta documentación no se requiere producir con herramientas sofisticadas.

Ágil significa “no hay un plan”

De hecho, ágil no soporta el desarrollo sin planeación. Los métodos ágiles usan planeación y estimación continua para maximizar el ROI. En realidad, ágil es sobre manejo de alcance. La planeación continua permite redireccionar el compás del proyecto de acuerdo con el entorno cambiante del mismo; también, asegura un foco consistente en las prioridades del negocio teniendo en cuenta las restricciones impuestas al proyecto. Además, la planeación constante posibilita tomar mejores decisiones y comunicarlas más efectivamente. Plan sí hay, solo que es dinámico y flexible.

Podemos rastrear el origen de este mito a otro  valor del Manifiesto Ágil que invoca: “valorar la respuesta ante el cambio sobre seguir un plan” [2]. Otra vez, se trata de un malentendido nocivo para la industria del software. Este artículo es un intento más por remediar esa situación.

Ágil es la solución tipo “bala de plata” a todos los problemas de la ingeniería de software (Existe una solución tipo bala de plata)

De todos los monstruos que llenan las pesadillas de nuestro folclor, ninguno más terrorífico que los llamados licántropos. Para ellos buscamos balas de plata que mágicamente los hacen desaparecer para siempre.

La industria del software tiene muchos problemas, aquellos que precisamente se quisieron arbitrar con el manifiesto ágil. Sin embargo, ningún método actual, por sí solo o combinado, es capaz de enfrentar la enorme cantidad de variables que se mezclan en el ambiente de los proyectos de software, dada la magnitud y complejidad de la mayoría de estos. Los métodos ágiles no son la excepción. Si bien su modelo iterativo y adaptativo de gestión posibilita en gran medida la resolución de muchos impedimentos, siempre habrá que poner de manifiesto nuestro sentido común para afrontar escenarios hostiles.

Es decir, además de recurrir a balas de plata, estacas de madera, ajos o apelaciones a la mediación divina (léase procesos y herramientas, documentación detallada, contratos y acuerdos de servicio, planes, etc.), necesitamos encontrar mecanismos que nos permitan interactuar mejor entre nosotros, construir productos de software por incrementos, colaborar íntimamente con los usuarios y reaccionar hábilmente ante los cambios que se presentan todo el tiempo durante un proyecto. Esto es lo que dice realmente el manifiesto ágil.

Ágil no necesita diseño previo

Este quizás es un derivado del primer mito. En la realidad, la pieza funcional de software que se entrega en cada iteración requiere de diseño, el suficiente y necesario para construir un producto con calidad. Se trata de un diseño funcional, tan robusto pero tan flexible como se requiera para que todos los cortes del software se puedan integrar en uno solo. Si pensamos en “diseñar a medida que avanzamos”, seguramente fallaremos en el intento y nuestro producto nunca verá la luz del día. El ciclo convencional del software no desaparece porque lo hagamos ágil: análisis, diseño, implementación, pruebas y despliegue. ¡Algunas cosas no cambian!

Ágil siempre usa “Historias de Usuario"

Esta leyenda también desciende de la primera. Es que la “no documentación” es el más arraigado de todos los mitos alrededor de los métodos ágiles. Tanto las organizaciones como los individuos necesitamos de conocimiento explícito, o sea, de aquel que tenemos y del que somos plenamente conscientes cuando lo ejecutamos, que está estructurado y muchas veces esquematizado para facilitar su difusión. Esas son las claves: estructurado y esquematizado, es decir, documentado. Otra cosa es el formato que usamos para documentar, quizás ese es el que debe cambiar, pero ese es un problema diferente.

Y en cuanto a las historias de usuario, rutinarias en los métodos ágiles, hay que decir que ágil no siempre las usa. Hay que usarlas sí, y solo sí, son apropiadas. Existen otros instrumentos, unos más efectivos que otros, como los prototipos, los tableros de historias, los simuladores. ¿Alguien ha intentado “porciones de caso de uso”? Estas últimas son tan livianas como las historias de usuario y tienen el poder de los casos de uso. Y otro error muy común es creer que las historias de usuario siempre son elaboradas por el Dueño de Producto.

Scrum siempre Funciona

Ya tenemos claro que ágil no es una bala de plata y Scrum es ágil, conclusión…

Primero debemos saber cuándo implementar Scrum en la organización. Y luego debemos saber cuándo usar Scrum en un proyecto. ¿Está preparado nuestro cliente/usuario? ¿Habrá un dueño de producto? Más importante aún, ¿está dispuesto nuestro equipo para entregar software probado y funcionando que sea potencialmente distribuible cada periodo corto de tiempo – 2 semanas –? ¿Están claros los valores y principios del manifiesto ágil? Este artículo es un síntoma de que no lo están. ¿El equipo es autogestionado y experto? ¿Nuestro usuario está dispuesto a involucrarse al 100%?

Entre otras, estas son algunas de las cuestiones que debemos responder y establecer antes de intentar Scrum en nuestros proyectos. Se requiere de cierta capacidad y de cierta madurez para enfrentar el reto.

Scrum Master igual a Gerente de Proyecto

Scrum Master es un rol de gestión, sí, pero no es un gerente como lo conocemos en los proyectos tradicionales, mucho menos un gerente tipo PMI o algo parecido. “El Scrum Master es un líder servil, al servicio del Equipo Scrum.” [3] Un SM es un facilitador, es alguien que se sitúa en algún lugar entre el equipo de desarrollo y el cliente. También puede verse como un “guardián de Scrum”, un custodio, alguien que vigila que el proceso se esté llevando a cabo como lo indica la guía de Scrum.

El SM puede venir de una PMO, es cierto, pero también puede llegar desde el equipo de Analistas o de cualquier otro miembro de la organización que tenga las habilidades y la empatía requerida. El SM tampoco es un desarrollador líder o arquitecto, también hay que decirlo.

Podemos hacer Scrum sin un Dueño de Producto o con muchos dueños de producto

Cuando no tenemos un dueño de producto que está fuera del equipo o, mejor, fuera de la jerarquía del equipo, perdemos algo precioso e inherente a ágil: la noción del cliente. Perdemos a la persona que nos puede ayudar a entender lo que realmente quiere el cliente. “El dueño de producto es el responsable de maximizar el valor del producto y del trabajo del Equipo de Desarrollo.” [4] El dueño de producto es quien establece los criterios reales de aceptación del producto, esto no lo puede hacer otro rol en el equipo o en la organización. Es un hecho, sin este personaje, el equipo no sabrá que hacer.

Ahora bien, el dueño del producto es uno solo, no un equipo o comité de dueños de productos. El dueño de producto es una sola voz y representa los intereses del cliente, es decir, de todos los interesados en el producto. Más de un dueño de producto puede “adicionar ruido” al proyecto, es decir, sumar variables que pueden llevar el proyecto a la devastación. Finalmente, este mito tiene sus orígenes en que ninguna persona por sí sola tiene el conocimiento completo de lo que quiere la organización, pero ello no es necesario, solo es suficiente con que tenga contacto con las personas apropiadas.

Scrum no funciona con CMMI u otros modelos de procesos y viceversa

He visto anuncios en la Web sobre “la gran pelea” entre Scrum y CMMI, seminarios virtuales, tertulias presenciales, diplomados para expertos, como si se tratara del campeonato de combate definitivo, la última de las grandes contiendas entre dos “gigantes” del deporte. Esta leyenda urbana tiene sus raíces en la creencia de que CMMI es predictivo mientras que Scrum es adaptativo. Pero lo que hay que saber realmente es que CMMI es un modelo de mejoramiento de procesos, nos indica qué buenas prácticas dan ventaja a nuestra organización, en tanto que Scrum aporta precisamente el cómo implementar esas prácticas.

En la realidad es posible integrar estos dos mundos y ponerlos a funcionar en beneficio de nuestros clientes y de nosotros mismos: a la vez que CMMI permite describir todos los procesos de la organización y su interacción, Scrum regula el procedimiento a seguir en el mero proceso de desarrollo. Quizás el detalle más oscuro en este análisis es aquel de las estadísticas inherentes a toda organización de alta madurez, pero la cultura ágil de alguna manera impuesta por Scrum sirve de fundamento sistemático a los requisitos de un proceso de control estadístico impuesto por CMMI. Las cosas así, es totalmente viable convivir con Scrum y CMMI en un mismo plano.

Scrum produce equipos de súper héroes, tipo los Vengadores o la Liga de la Justicia

Necesitamos expertos, es cierto. Pero estos no se hacen solos. Scrum no es una caneca de desechos biológicos o químicos y donde podamos caer y levantarnos con poderes extrasensoriales que permitan leer la mente de los usuarios o con una memoria prodigiosa que nos faculte a escribir solo las líneas de código correctas o realizar diseños perfectos en cuestión de segundos.

Si seguimos Scrum, si asistimos a las ceremonias propuestas por el marco de trabajo, seremos capaces de entender los obstáculos que evitan mejorar nuestro desempeño. Y sin la habilidad o deseo de remover esos impedimentos, apenas si podremos tener mayor visibilidad de los problemas. Y esto simplemente redundará en el aumento de nuestra frustración, lo que a su vez dejará notar nuestro comportamiento negativo y menos productivo. Ya lo he repetido, Scrum no es la solución definitiva, pero ayuda a ser mejores cada vez. La transparencia y la predictibilidad son los beneficios inmediatos.

¡El plan de mejoramiento personal y profesional lo ejecutamos de nuestra cuenta!

Más Mitos y Leyendas

Otros mitos, no menos perjudiciales, son:

• Estamos haciendo Scrum, así que no necesitamos otras prácticas ágiles como TDD, Refactoring, Pair Programming, etcétera
• Ágil es menos disciplinado y más fácil
• Podemos lograr agilidad sin cambio organizacional e individual
• Ágil es igual a Scrum
• Con Scrum podemos hacer cambio en cualquier momento

La lista realmente podría ser interminable.

Conclusiones

Scrum es una idea sencillamente empaquetada y de esta manera podemos transferirla rápidamente de una persona a otra y de un equipo a otro. Con todo y ello, es innegable la gran cantidad de concepciones erróneas que tenemos al respecto. Para sacar estos monstruos y mitos de nuestras mentes es necesario tener acompañamiento, no basta con aprender por sí solo, necesitamos entrenamiento de personas que hayan usado exitosamente el método. Las organizaciones, por su parte, deben concebir un buen plan de implantación del método: configurar el proceso, hacer proyectos piloto, medir, analizar los resultados, ajustar, entrenar a los equipos e institucionalizar.

¡Así lo estamos haciendo!

Referencias Web/Bibliográficas

[1] Colaboradores de Wikipedia. Mitología [en línea]. Wikipedia, La enciclopedia libre, 2013 [fecha de consulta: 11 de junio del 2013]. Disponible en http://es.wikipedia.org/w/index.php?title=Mitolog%C3%ADa&oldid=67124850

[2] El Manifiesto Ágil de Software: http://www.agilemanifesto.org/iso/es/

[3] La Guía de Scrum: http://www.scrum.org/Scrum-Guides

[4] La Guía de Scrum: http://www.scrum.org/Scrum-Guides

Actualización 20200220

Puedes ver y descargar la presentación asociada a este artículo aquí.

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:

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

Casos de Uso 2.0: Cosas con las cuales trabajar

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:

Casos de Uso 2.0

http://www.gazafatonarioit.com/2012/04/casos-de-uso-20.html

Casos de Uso 2.0 y Métodos Ágiles

http://www.gazafatonarioit.com/2012/04/casos-de-uso-20-y-metodos-agiles.html

¡Quiero una Porción de Caso de Uso!

http://www.gazafatonarioit.com/2012/04/quiero-una-porcion-de-caso-de-uso.html

Casos de Uso 2.0 – Aplicable a todos los tipos de sistemas y organizaciones

http://www.gazafatonarioit.com/2012/04/casos-de-uso-20-aplicable-todos-los.html

Sobre Casos de Uso pueden leer toda mi sección de Lecturas Fundamentales en este mismo Gazafatonario, empezando en:

http://www.gazafatonarioit.com/2006/11/lecturas-fundamentales.html

Diez Consejos Útiles y Simples Para Escribir Correctamente Casos de Uso Correctos: X

Consejo 10

No usemos expresiones del tipo: “el sistema verifica si se cumple tal condición” y más adelante: “si se cumple la condición, haga esto”, y para terminar: “si no se cumple la condición, haga esto otro.” Este es un patrón que viene de la programación de computadores, es más bien pseudocódigo y la primera de las acciones no cumple con una de las premisas importantes de un caso de uso y es que cada acción lleve la secuencia del caso de uso un paso más adelante que el anterior. Vemos claramente que “el sistema verifica si se cumple tal condición” no avanza en el proceso, en cambio, debemos esperar hasta la siguiente operación: “si se cumple…” para continuar la secuencia.

En cambio, escribamos el caso de uso en términos de escenarios:

n. El sistema verifica que tal condición se cumple y hace…

n+1. El actor hace…

En una secuencia alterna especificamos lo que ocurre cuando la condición no se cumple:

nA1. El sistema verifica que tal condición no se cumple y hace…

(n+1)A2. El actor hace…

Como en:

4. El sistema verifica que el Cliente tiene capacidad de endeudamiento y solicita el valor del crédito

5. El actor ingresa el valor del crédito

Y en la secuencia alterna:

4A1. El sistema verifica que el Cliente no tiene capacidad de endeudamiento y solicita la identificación del avalista

4A2. El actor ingresa la identificación del avalista

Ejemplo

Consideremos este fragmento de caso de uso para verificar los fondos de una cuenta bancaria con miras a hacer efectivo un cheque.

Caso de Uso: Verificar fondos cuenta

Actor: Cajero

Secuencia Básica:

1.     El caso de uso inicia cuando el Cajero decide verificar los fondos disponibles para un cheque

2.     El sistema solicita el tipo y número de cuenta

3.     El Cajero ingresa el tipo y número de cuenta

4.     El sistema verifica que el número de cuenta existe y que está Activa y solicita el número del cheque

5.     El cajero ingresa el número del cheque

6.     El sistema valida que el número del cheque está dentro del rango autorizado y que no está contraordenado, y solicita el valor del cheque

7.     El cajero ingresa el valor del cheque

8.     El sistema verifica que hay fondos suficientes para pagar el cheque

9.     El caso de uso termina

Secuencia Alterna 1:

4A. El número de cuenta no existe

4A.1. El sistema verifica que el número de cuenta no existe y muestra el mensaje: “El número de cuenta dado no existe. Verifique.”

4A.2. El caso de uso continúa en el paso 2 de la secuencia básica.

Secuencia Alterna 2:

6A. El número del cheque no está dentro del rango autorizado

6A.1. El sistema verifica que el número del cheque no está dentro del rango autorizado y muestra el mensaje “El número del cheque no está autorizado. Verifique.”

6A.2. El caso de uso continúa en el paso 5 de la secuencia básica

Secuencia Alterna 3:

8A. No hay fondos suficientes para pagar el cheque

8A.1. El sistema verifica que la cuenta no tiene fondos suficientes para pagar el cheque y muestra el mensaje “Fondos insuficientes. Verifique.”

8A.2. El caso de uso continúa en el paso 7 de la secuencia básica

La escritura limpia del caso de uso lo hace claro, preciso y consistente, entre otros atributos deseables en un caso de uso. Nótese que es posible que haya más secuencias alternas.

Para saber más de casos de uso pueden visitar la sección Lecturas Fundamentales de mi Gazafatonario IT. En particular, pueden leer la Lectura Fundamental 3: Casos de Uso: Del Todo y de sus Partes.

http://www.gazafatonarioit.com/2006/11/lecturas-fundamentales-3.html

Esta serie de consejos útiles para escribir casos de uso inicia en:

http://www.gazafatonarioit.com/2012/10/diez-consejos-utiles-y-simples-para.html

Diez Consejos Útiles y Simples Para Escribir Correctamente Casos de Uso Correctos: VIII y IX

Consejo 8

Cuando se trata de incluir casos de uso se escribe:

• El sistema ejecuta el caso de uso “AQUÍ VIENE EL NOMBRE DEL CASO DE USO INCLUIDO”

O simplemente,

• Se ejecuta el caso de uso “AQUÍ VIENE EL NOMBRE DEL CASO DE USO INCLUIDO”

En este último caso se entiende que el único que ejecuta casos de uso incluidos es el sistema. Como en:

n. El sistema ejecuta el caso de uso “Verificar Lista Clinton”

n+1. Se ejecuta el caso de uso “Hacer Análisis de Riesgo”

Consejo 9

La especificación de un caso de uso incluido se debe iniciar estableciendo los nombres de los casos de uso que incluyen este caso de uso, como en:

1.     Este caso de uso se incluye en los casos de uso:

        a.     Caso de uso base 1

        b.     Caso de uso base 2

        c.     …

        d.     Caso de uso base n

2.     El sistema hace…

3.     El actor hace…

…

n. El caso de uso termina

Donde n es el número del último paso del caso de uso incluido.

Recordemos que esta relación de inclusión se usa cuando queremos:

•      Factorizar o descomponer (en sentido matemático) el comportamiento del caso de uso base que no es necesario para entender el objetivo principal del mismo y donde solamente el resultado del caso de uso incluido es importante.
•      Distribuir en uno o más casos de uso, funcionalidad del caso de uso base que es común para dos o más casos de uso (reusabilidad).

La primera opción se usa especialmente en casos de uso largos o complejos donde algunas partes del mismo no son relevantes para el sentido primordial del caso de uso y no son necesarias, en primera instancia, para entenderlo y aprobarlo. Por ejemplo, un caso de uso para Ingresar un Cliente de Naturaleza Jurídica puede solicitar docenas o cientos de datos que se pueden agrupar de acuerdo a algunos criterios como Datos Generales, Datos del Tipo de Entidad y Naturaleza Jurídica, Datos del Gerente o Representante Legal, Datos de los Contactos, Referencias Comerciales, entre otros. Algunos de estos grupos de datos pueden incluirse en casos de uso complementarios que son ejecutados desde el caso de uso principal.

La segunda posibilidad de inclusión es la reusabilidad de funcionalidad del sistema, es decir, cuando existe un comportamiento del sistema que se ejecuta en dos o más casos de uso de la misma manera, podemos usar un caso de uso incluido que represente ese comportamiento común. Por ejemplo, un caso de uso Verificar Centrales de Riesgo, que se ejecuta desde varios casos de uso de un sistema financiero, como Matricular Cliente, Revisar Solicitud de Crédito, Abrir Cuenta Corriente, entre otros.

Para conocer más acerca de relaciones entre casos de uso, pueden leer la Lectura Fundamental 12 Casos de Uso: de Extensiones y de Inclusiones en mi Gazafatonario IT:

http://www.gazafatonarioit.com/2008/05/lectura-fundamental-12-lectura_8835.html

La serie completa de estos consejos la encuentran en:

http://www.gazafatonarioit.com/2012/10/diez-consejos-utiles-y-simples-para.html

http://www.gazafatonarioit.com/2012/11/diez-consejos-utiles-y-simples-para.html

http://www.gazafatonarioit.com/2012/11/diez-consejos-utiles-y-simples-para_4.html

http://www.gazafatonarioit.com/2012/11/diez-consejos-utiles-y-simples-para_6.html

http://www.gazafatonarioit.com/2012/11/diez-consejos-utiles-y-simples-para_8.html

Diez Consejos Útiles y Simples Para Escribir Correctamente Casos de Uso Correctos: V, VI y VII

Consejo 5

Cuando se trata de operaciones complejas (que en un caso de uso son realizadas únicamente por el sistema), se debe evitar la descripción de la operación. Simplemente se debe decir:

·         El sistema calcula…

·         El sistema busca…

·         El sistema clasifica… o El sistema ordena…

·         El sistema almacena…

La descripción del cálculo, de la búsqueda, de la clasificación u ordenamiento y del método y destino específico de almacenamiento se hace en los requisitos especiales del caso de uso o en un documento de especificación de requisitos funcionales y no funcionales y se referencian en el caso de uso que lo requiera. Como en:

·         El sistema calcula el valor de la liquidación del empleado

·         El sistema busca los créditos que cumplan con las condiciones establecidas

·         El sistema clasifica los datos de los empleados por fecha de ingreso

·         El sistema almacena los datos del crédito

Consejo 6

Cuando el sistema realiza más de una de estas funciones se especifica la de mayor relevancia para el usuario. Por ejemplo: si para hacer un cálculo específico, el sistema debe buscar uno o más datos, se especifica el cálculo. Si el sistema clasifica u ordena un conjunto de datos para buscar uno o varios de ellos, se especifica la búsqueda. Si el sistema calcula y luego almacena, se puede decir “el sistema calcula SUJETO DE CÁLCULO y almacena DATOS A ALMACENAR” como en:

“El sistema calcula el interés corriente y almacena los datos del crédito.”

La fórmula matemática para hacer el cálculo y la enumeración detallada de los datos a almacenar pueden ser objeto de uno o varios requisitos especiales del caso de uso o de requisitos generales del sistema escritos en forma declarativa. En cualquier caso, debe existir un mecanismo de trazabilidad entre esos requisitos y el caso de uso que incluya las acciones de cálculo y de almacenamiento del ejemplo.

Consejo 7

Las operaciones complejas de cálculo, búsqueda o clasificación de datos se describen mejor usando diagramas de actividad, de estados o de secuencia, según el caso.

Explicación

Recordemos que un caso de uso (del sistema) especifica lo que hace el sistema y es relevante para el negocio. Por ejemplo, al usuario le interesa que el sistema almacene la información, pero no es importante si el sistema usa un procedimiento almacenado, un servicio o cualquier otro mecanismo para realizar esa acción. De la misma forma, al usuario le interesa que el sistema le muestre un informe con ciertos criterios de clasificación y agrupamiento, pero no se preocupa por los aspectos puramente técnicos de cómo se realiza el ordenamiento o si se requiere almacenamiento temporal para hacer los agrupamientos de datos, entre otros.

Para conocer más sobre este asunto pueden visitar el caso de abuso 5 en este miso Gazafatonario IT.

Caso de Abuso 5: El caso de uso contiene detalles de formularios (pantallas) y otros aspectos técnicos (bases de datos, componentes, etc.)

http://www.gazafatonarioit.com/2012/09/casos-de-abuso-parte-5-el-caso-de-uso.html

También el caso de abuso 2:

El caso de uso es la única documentación necesaria para construir el software

http://www.gazafatonarioit.com/2012/09/casos-de-abuso-parte-2.html

Sobre el consejo 7 pueden leer mi Lectura Fundamental 10:

Realización de Casos de Uso: De los Objetos y sus Interacciones

http://www.gazafatonarioit.com/2007/10/lecturas-fundamentales-10-lectura_3046.html