Casos de uso 2.0
IVAR JACOBSON, IAN SPENCE, AND BRIAN KERR
El Hub del desarrollo de software
Los casos de uso han existido durante casi 30 años como un enfoque de requisitos y han sido parte de la inspiración para técnicas más recientes como las historias de usuario. Ahora la inspiración ha volado en la otra dirección.
Use Case 2.0 es el nuevo modelo de generación de desarrollo basado en casos de uso; ligero, ágil y lean; inspirado en las historias de usuarios y las metodologías ágiles Scrum y Kanban.
Use-Case 2.0 tiene todos los valores populares del pasado:
No solo para los requisitos de soporte, sino también para la arquitectura, el diseño, la prueba y la experiencia del usuario y es fundamental para el modelado de negocios y la reutilización de software.
Use-Case 2.0 se ha inspirado en historias de usuarios para ayudar con backlogs a la Scrum y flujo de una pieza con Kanban, con la introducción de un nuevo concepto importante, el uso en rebanadas del caso.
Este artículo presenta el argumento de que los casos de uso incluyen esencialmente las técnicas proporcionadas por el usuario: historias, pero ofrecen mucho más para sistemas más grandes, equipos más grandes y desarrollos más complejos y exigentes.
Son tan livianos como las historias de usuario, pero también pueden escalar en una forma suave y estructurada de incorporar tantos detalles según sea necesario. Lo más importante es que conducen y conectan muchos otros aspectos del desarrollo de software.
Casos de uso: ¿Por qué sigue siendo exitoso y popular?
Los casos de uso se introdujeron en OOPSLA 87 (Sistemas de programación, lenguajes y aplicaciones orientados a objetos), 6 aunque no fueron ampliamente adoptados hasta la publicación del libro de 1992 Ingeniería de software orientada a objetos: un enfoque basado en casos de uso.7
Desde entonces muchos otros autores han adoptado partes de la idea, en particular Alistair Cockburn 2
sobre los requisitos y Larry Constantine 4 sobre diseñando para mejores experiencias de usuario. Los casos de uso fueron adoptados como parte del estándar UML (Lenguaje unificado de modelado1 ) y sus diagramas (el caso de uso y el actor como iconos) se encuentran entre las partes del lenguaje más utilizadas. Se han escrito muchos otros libros y artículos sobre los casos de uso para todo tipo de sistemas, no solo para software, sino también para negocios, sistemas (como sistemas integrados) y sistemas de sistemas. Centrándonos en el presente y el futuro, las últimas macro tendencias, IoT (Internet de las cosas) e Internet industrial, han elegido los casos de uso.
La práctica de casos de uso ha evolucionado a lo largo de los años, inspirada por ideas de muchas personas diferentes, con las ideas más nuevas incorporadas en los casos de uso 2.0. Una nueva idea es cortar un uso en porciones de caso de uso. 5,8 La idea de dimensionar estas rebanadas para convertirse en elementos adecuados del backlog y relacionarlos con las historias de usuario es el núcleo de Use-Case 2.0.
Los casos de uso pueden y deben usarse para impulsar el desarrollo de software. No prescriben cómo debe planificar o administrar su trabajo de desarrollo, o cómo debe diseñar, desarrollar o probar su sistema. Sin embargo, proporcionan una estructura para la adopción exitosa de su seleccionado prácticas de gestión y desarrollo.
La razón del éxito del enfoque de casos de uso no es solo que sea una técnica muy práctica para capturar requisitos desde una perspectiva de uso o para diseñar prácticas experiencias de usuario, pero impacta en todo el ciclo vital de desarrollo. Los casos de uso clave, o para ser más precisos, las porciones clave de casos de uso (una porción es una parte cuidadosamente seleccionada de un caso de uso): ayuda sistemáticamente a encontrar la arquitectura de la aplicación. Impulsan la identificación de componentes u otros elementos de software en el diseño de software . Ellos son los elementos que deben someterse a pruebas y realmente respaldan el diseño basado en pruebas. Son los elementos a poner en el backlog al planificar los sprints o para poner en el tablero usando Kanban.
Los casos de uso de una empresa son los procesos del negocio; por lo tanto, la ventaja de hacer modelos de negocios con casos de uso es que conduce directamente a encontrar el uso según casos del sistema a desarrollar para dar soporte al negocio.
Además, los casos de uso ayudan a encontrar puntos en común, que dirigen el trabajo de arquitectura para lograr la reutilización del software. Hay muchos más valores similares en la aplicación de casos de uso, pero lo más importante es que la idea de casos de uso es intuitiva y se puede capturar. Se trata de una herramienta ligera, esbelta y ágil, escalable, enfoque versátil y fácil de usar. Mucha gente que escucha acerca de los casos de uso por primera vez los toma en serio; muchos empezar a usar el término en situaciones de la vida cotidiana sin pensar en todos los detalles que ayudan en tantos aspectos del desarrollo de software, los aspectos que son los rayos de la rueda de desarrollo de software en la que los casos de uso son el eje o hub (ver figura 1)
Por tanto, parece claro que los casos de uso han superado la prueba de tiempo y tenga un futuro muy saludable
Principios para la adopción de Casos de Uso
Hay seis principios básicos en el corazón de cualquier aplicación de casos de uso éxito:- Hágalo sencillo contando historias.
- Comprenda el panorama general.
- Céntrese en el valor.
- Construya el sistema en porciones.
- Entregue el sistema en incrementos.
- Adáptese a las necesidades del equipo.
Principio 1: hazlo simple contando historias
La narración es el medio por el cual las culturas sobreviven y progresan; es la forma más sencilla y eficaz de transmitir conocimientos de una persona a otra. Es la mejor forma de comunicar lo que un sistema debería hacer y hacer que todos trabajen en el sistema para centrarse en los mismos objetivos.
Los casos de uso capturan los objetivos del sistema. Comprendemos un caso de uso, contando historias. Las historias cubren cómo lograr el objetivo y cómo manejar los problemas que ocurren en el camino. Los casos de uso proporcionan una forma de identificar y capturar todas las diferentes historias pero relacionadas de una manera simple pero de manera completa. Esto permite que los requisitos del sistema sean fácilmente capturados, compartidos y entendidos.
Principio 2: Comprenda el panorama general
Ya sea que el sistema que se está desarrollando sea grande o pequeño, ya sea un sistema de software, un sistema de hardware o un sistema empresarial, comprender el panorama general es esencial. Sin una comprensión del sistema en su conjunto, resulta imposible tomar las decisiones correctas sobre lo que se incluye en el sistema, qué omitir, cuánto costará y qué beneficio proporcionará.
Un diagrama de casos de uso es una forma sencilla de presentar una descripción general de los requisitos de un sistema. La figura 2 es el diagrama de caso de uso de un sistema telefónico simple. Esta imagen muestra todas las formas en que se puede utilizar el sistema, quién inicia la interacción y cualquier otra parte involucrada. Por ejemplo, un suscriptor por llamada puede realizar una llamada local o de larga distancia, llamar a cualquiera de los suscriptores llamables del sistema. También se puede ver que los usuarios no tienen que ser personas, sino que pueden ser otros sistemas y en algunos casos, ambos (por ejemplo, el papel del suscriptor llamado puede ser un contestador automático y no un
persona)
Principio 3: Centrarse en el valor
Al intentar comprender cómo se utilizará un sistema, es siempre es importante centrarse en el valor que aportará a sus usuarios y otras partes interesadas. El valor se genera solo si se utiliza realmente el sistema, por lo que es mucho mejor centrarse en cómo se utilizará el sistema que en largas listas de las funciones o características que ofrecerá.
Los casos de uso proporcionan este enfoque al concentrarse en cómo el sistema se utilizará para lograr un objetivo específico para un usuario. Abarcan muchas formas de utilizar el sistema: aquellas que logren con éxito las metas y las que manejen cualquier problema que pueda ocurrir.
La Figura 3 muestra una narrativa de casos de uso estructurada en esta forma para el caso de uso de retiro de efectivo de un cajero automático. La forma más sencilla de lograr el objetivo se describe mediante el flujo. Los demás se presentan como flujos alternativos. En esta manera de crear un conjunto de flujos que estructuran y describen las historias, ayudando a encontrar los casos de prueba que completan su definición.
Principio 4: Construya el sistema en porciones
La mayoría de los sistemas requieren mucho trabajo antes de poder utilizarse y estar listo para su uso operativo. Tienen muchos requisitos, la mayoría de los cuales dependen de otros requisitos implementados antes de que puedan cumplirse y entregarse valor.
Siempre es un error intentar construir un sistema así de una vez. El sistema debe construirse en porciones, cada una de las cuales tiene un claro valor para los usuarios.
- Primero, identifique los más útiles cosa que el sistema tiene que hacer y enfocarse en eso.
- Entonces tome esa única cosa y córtela en rodajas más finas .
- Decidir por los casos de prueba que representan la aceptación de esas porciones.
- Elija el corte más central que recorra todo el concepto de un extremo a otro, o lo más cerca posible de eso.
- Estimarlo en equipo y empezar a construirlo.
Este es el enfoque adoptado por Use-Case 2.0, donde un caso de uso se corta para proporcionar elementos de trabajo de tamaño adecuado y donde el propio sistema evoluciona corte a corte. Aunque los casos de uso se han utilizado tradicionalmente para ayudar a comprender y capturar los requisitos, siempre han sido mucho más que esto. Las secciones de casos de uso analizan más que solo los requisitos; también cortan todos los otros aspectos del sistema y su documentación, incluyendo el diseño, la implementación, los casos de prueba y los resultados de las pruebas.
Principio 5: Entregue el sistema en incrementos
La mayoría de los sistemas de software evolucionan a lo largo de muchas generaciones. No se producen de una sola vez; están construidos como una serie de lanzamientos, cada uno basado en el anterior. Incluso los lanzamientos en sí mismos a menudo no se producen de una vez pero evolucionan a través de una serie de incrementos. Cada incremento proporciona una versión demostrable o utilizable del sistema. Esta es la forma en que deben producirse todos los sistemas.
La figura 4 muestra el desarrollo incremental de un lanzamiento del sistema. El primer incremento contiene solo un segmento: el primer segmento del caso de uso 1. El segundo incremento agrega otra porción del caso de uso 1 y la primera porción del caso de uso 2. Luego se agregan más rebanadas para crear el tercer y el cuarto incremento. El cuarto incremento se considera lo suficientemente completo y útil para ser lanzado.
Principio 6: Adaptarse para satisfacer las necesidades del equipo
Desafortunadamente, no existe una solución única para todos los desafíos del desarrollo de software; diferentes equipos y diferentes situaciones requieren diferentes estilos y diferentes niveles de detalle. Independientemente de qué prácticas y técnicas seleccione, debe asegurarse de que sean adaptables lo suficiente para satisfacer las necesidades continuas del equipo.
Use-Case 2.0 está diseñado con esto en mente y puede ser tan ligero como se desee. Los equipos pequeños y colaborativos pueden tener narrativas de casos de uso muy ligeras que capturan lo básico, lo esencial de las historias. Estos se pueden escribir a mano en simples fichas. Los equipos grandes distribuidos pueden tener más detalles narrativos de casos de uso presentados como documentos. Depende del equipo para decidir si necesitan ir más allá de los esenciales, agregando detalles de una manera natural a medida que se encuentran problemas que lo esencial no puede afrontar.
La práctica de los casos de uso 2.0
La práctica de los casos de uso 2.0 describe los conceptos clave para trabajar con ellos, los productos de trabajo son utilizados para describirlos y a un conjunto de actividades.
Conceptos con los que trabajar
El caso de uso 2.0 abarca los requisitos, el sistema a ser desarrollado debe cumplir con los requerimientos y las pruebas utilizadas para demostrar que el sistema cumple con los requisitos. El corazón del caso de uso 2.0 son el caso de uso, el segmento del caso de uso y la historia.
Los casos de uso capturan los requisitos y cada caso de uso se gestiona el alcance de uso, dividiéndolo en un conjunto de porciones de casos de uso que se pueden trabajar de forma independiente. Contando historias se establecen puentes sobre las brechas entre las partes interesadas, los casos de uso y las porciones de casos de uso. Así es como las partes interesadas comunican sus requerimientos y se exploran los casos de uso. La comprensión de las historias es también el mecanismo para encontrar el uso correcto de porciones de casos de uso para impulsar la implementación del sistema
Un caso de uso es:
Cuentos
- Una secuencia de acciones que realiza un sistema que produce un resultado observable de valor para un usuario en particular.
- Ese comportamiento específico de un sistema, que participa en colaboración con un usuario para ofrecer algo de valor para ese usuario.
- La unidad de actividad más pequeña que proporciona un resultado para el usuario.
- El contexto de un conjunto de requisitos relacionados.
El conjunto de todos los casos de uso agrupan todos los requisitos funcionales del sistema. La forma de entender un caso de uso es contando historias. Estas historias cubren tanto el cómo lograr una meta así como cómo el manejar cualquier problema que ocurra en el camino. Ayudan a los desarrolladores a comprender el caso de uso e implementarlo segmento por segmento.
Un caso de uso sufre varios cambios de estado definidos, comenzando con solo tener su objetivo establecido , a través de la estructura de la historia entendida , historia más simple cumplida, las suficientes historias cumplidas, todas las historias cumplidas. Los estados constituyen puntos de referencia importantes en la comprensión e implementación del caso de uso.
Rebanadas de casos de uso
Los casos de uso cubren muchas historias relacionadas de diversa importancia y prioridad. A menudo hay demasiadas historias para contar en un lanzamiento único y, en general, demasiadas para trabajar en un solo incremento. Por lo tanto, es necesario dividir los casos de uso en piezas más pequeñas.
Un segmento de caso de uso es una o más historias seleccionadas de una caso de uso para formar un elemento de trabajo que tiene un valor claro para el cliente. Actúa como marcador de posición para todo el trabajo requerido para completar la implementación de las historias seleccionadas. El segmento de caso de uso evoluciona para incluir los segmentos correspondientes a través del diseño, implementación y prueba. El segmento de caso de uso es el elemento más importante del Caso de Uso 2.0, ya que se utiliza no solo para ayudar con los requisitos, sino también para impulsar el desarrollo de un sistema para cumplirlos.
Un segmento de caso de uso sufre varios cambios de estado, desde su identificación inicial donde tiene el alcance , a través de ser elaborado, analizado, implementado y finalmente, verificado. Estos estados permiten la planificación y el seguimiento de la comprensión, implementación y prueba del segmento de caso de uso.
Para el observador casual que mira los estados, esto podría parecer a un proceso en cascada. Sin embargo, hay una gran diferencia ya que se trata de un segmento de caso de uso individual. Al otro lado del set de rebanadas, todas las actividades podrían estar sucediendo en paralelo. Mientras se está verificando un segmento de caso de uso, se está verificando otro segmento de caso de uso que se está implementando, se está preparando un tercero que está siendo analizado.
Contar historias es la forma en que los desarrolladores exploran casos de uso con las partes interesadas. Cada historia de valor para los usuarios y otros stakeholders es un hilo conductor a través de uno de los casos de uso. Las historias pueden ser de naturaleza funcional o no funcional.
Una historia se describe mediante una parte de la narrativa del caso de uso, uno o más flujos y requisitos especiales, y uno o más casos de prueba. La clave para encontrar historias efectivas es comprender la estructura de la narrativa de los casos de uso.
La red de flujos puede pensarse como un mapa que resume todas las historias necesarias para describir el caso de uso. En el ejemplo de cajero automático anterior de la figura 3, podría identificar historias específicas como "Retirar un monto estándar de $ 100”,“ Retirar un monto no estándar de $ 75 y obtenga un recibo” o “Responda a una tarjeta no válida”.
Cada historia atraviesa uno o más flujos que comienzan con el caso de uso al comienzo del flujo básico y terminando con el caso de uso al final del flujo básico. Esto asegura que todas las historias están relacionadas con la consecución del mismo objetivo, son completos y significativos y son complementarios, ya que todos se basan en la historia simple descrita por el flujo básico.
Los casos de uso y los segmentos de casos de uso son compatibles con varios productos de trabajo que el equipo utiliza para ayudar a compartir, comprender y documentarlos. Un modelo de caso de uso visualiza los requisitos como un conjunto de casos de uso, proporcionando un panorama general del sistema a ser construido. El modelo define los casos de uso y proporciona el contexto para la elaboración de casos de uso individuales.
Los casos de uso se exploran contando historias. Cada caso de uso es descrito por (1) una narrativa de caso de uso que describe sus historias como un conjunto de flujos; y (2) un conjunto de casos de prueba que completan la historia. Estos se pueden complementar con un conjunto de requisitos que se aplican a todo el caso de uso y que a menudo son no funcionales. Estos influirán en las historias, ayudarán a asignar las historias correctas para los segmentos de casos de uso para la implementación y, lo más importante, definir los casos de prueba adecuados.
El modelo de casos de uso se complementa con el soporte de información . Esto captura las definiciones de los términos utilizados en el modelo de caso de uso y al describir las historias en las narrativas de casos de uso. También captura cualquier sistema de todos los requisitos que se aplican a todos los casos de uso.
Se puede crear una realización de caso de uso para mostrar cómo los elementos del sistema colaboran para realizar un caso de uso. Piense en la realización del caso de uso como un "cómo" para complementar el "qué" de la narrativa del caso de uso. Maneras comunes de expresar realizaciones de casos de uso incluyen tablas simples, guiones gráficos o diagramas de secuencia.
Además de crear y rastrear los productos de trabajo, los desarrolladores necesitan rastrear los estados y propiedades de los casos de uso y sectores de casos de uso. Esto se puede hacer de muchas formas y con muchas herramientas. Los estados se pueden rastrear de manera muy simple usando notas adhesivas u hojas de cálculo. Si se requiere más formalidad, entonces uno de los muchos requisitos disponibles comercialmente-herramientas de gestión, gestión de cambios o seguimiento de defectos puede ser usado.
La Figura 5 muestra un caso de uso y algunas de sus porciones capturadas en un conjunto de notas adhesivas. El caso de uso que se muestra es “7. Explorar y comprar” desde una aplicación de compras.
Las secciones 1 y 2 del caso de uso se basan sobre historias individuales derivadas del flujo básico: "Seleccione y Compre 1 producto” y “Seleccione y compre 100 productos”. Rebanada 3 se basa en múltiples historias que cubren la disponibilidad de varios sistemas de soporte involucrados en el caso de uso.
Las propiedades esenciales para un caso de uso son su nombre, estado y prioridad. En este caso, el popular MoSCoW (Must, Should, se ha utilizado el esquema de priorización podría, lo haría). También deben estimarse los casos de uso. Aquí un esquema simple se ha utilizado la evaluación del tamaño y la complejidad relativas.
- Una lista de sus historias;
- Referencias al caso de uso y los flujos que definen las historias;
- Referencias a las pruebas y los casos de prueba que se utilizarán para verificar su cumplimiento; y
- Una estimación del trabajo necesario para implementar y probar la rodaja.
En este ejemplo, las historias se utilizan para nombrar el segmento y las referencias al caso de uso están implícitas en los números de segmentos y lista de flujos. Se han agregado las estimaciones más tarde después de consultar con el equipo. Estos son los grandes números hacia la parte inferior derecha de cada nota adhesiva. En el caso de que el equipo haya jugado Planning Poker para crear una relación de estimaciones utilizando puntos de historia. Los casos de uso y las porciones de casos de uso también deben ser ordenados de modo que los más importantes se aborden primero.
Mantener los productos de trabajo tan livianos como sea apropiado Todos los productos de trabajo se definen con una serie de niveles de detalle. El primer nivel define lo esencial, la cantidad mínima de información que se requiere para prácticamente poder trabajar. Se definen más niveles de detalle para ayudar al equipo a enfrentarse a cualquier circunstancia especial que pueda encontrarse.
Esto permite que los equipos pequeños y colaborativos tengan narrativas de casos de uso muy ligeras definidas en un índice simple de tarjetas y grandes equipos distribuidos para tener un uso más detallado de relatos de casos presentados como documentos. Los equipos pueden entonces hacer crecer las narrativas según sea necesario para ayudar con la comunicación o definir a fondo lo importante o crítico para la seguridad de los requisitos.
La buena noticia es que siempre comienzas de la misma manera, con lo esencial. El equipo puede adaptarse continuamente al nivel de detalle en sus narrativas de casos de uso para cumplir con sus necesidades emergentes.
Cosas para hacer
Use-Case 2.0 divide el trabajo en una serie de elementos de actividades esenciales que deben realizarse si los casos de uso deben proporcionar valor real para el equipo. La actividad Buscar actores y casos de uso produce un modelo de casos de uso que identifica a los casos de uso, que serán posteriormente cortados en rodajas . Estos segmentos de casos de uso serán preparados describiendo las historias relacionadas en la narrativa de los caso de uso y la definición de los casos de prueba.
Se analiza la rebanada para averiguar cómo interactuarán los elementos del sistema al realizar el caso de uso, luego es implementado y probado como una rodaja. El caso de uso 2.0 se puede considerar una forma de prueba de desarrollo, ya que crea los casos de prueba para cada segmento en la delantera. Finalmente, todo el sistema se prueba para garantizar que todas las rodajas funcionen juntas cuando se combinan.
Las actividades en sí mismas se realizarán muchas veces en el curso de su trabajo. Incluso una actividad simple como Buscar, es posible que los actores y los casos de uso deban realizarse muchas veces para encontrar todos los casos de uso y se puede realizar en paralelo con, o después, las otras actividades.
Por ejemplo, mientras continúa para encontrar actores y casos de uso, también puede estar implementando algunas de las secciones de los casos de uso que se encontraron anteriormente. A medida que avanza el proyecto, las prioridades cambian, las lecciones se aprenden y se solicitan cambios. Todos estos pueden tener un impacto en los casos de uso y porciones de casos de uso que ya se hayan implementado, así como los que aún están a la espera o en progreso. Esto significa que habrá una inspección y adaptación de la actividad a los casos de uso. Esto también adaptará la forma de trabajar con la práctica del caso de uso 2.0 para ajustar el tamaño de las rebanadas o el nivel de detalles en los productos de trabajo para cumplir con diferentes demandas del proyecto y del equipo.
Utilizando USE-CASE 2.0
Mucha gente piensa que los casos de uso son aplicables solo a usuarios de sistemas intensivos que tienen mucha interacción entre los usuarios humanos y el sistema. Esto es extraño porque la idea original de los casos de uso provino de la conmutación de sistemas de telecomunicaciones, que tienen tantos usuarios humanos (suscriptores, operadores) y usuarios de máquinas, en forma de otros sistemas interconectados. Los casos de uso son aplicables a todos los sistemas que se utilizan, es decir, todos los sistemas.
No es solo para aplicaciones de uso intensivo de usuarios.
De hecho, los casos de uso son igualmente útiles para sistemas embebidos con poca o ninguna interacción humana, ya que son para uso intensivo. La gente está usando casos de uso en el desarrollo de todo tipo de software embebido en diversos dominios como motor, electrónica de consumo, militar, aeroespacial e industrias médicas. Incluso sistemas de control de procesos en tiempo real utilizados para plantas químicas se pueden describir por casos de uso en los que cada caso de uso se centra en una parte específica del comportamiento del proceso de la planta y las necesidades de automatización.
No es solo para el desarrollo de software
La aplicación de casos de uso no se limita al desarrollo de software. También pueden ayudar a comprender los requisitos de negocios, analizar negocios existentes, diseñar nuevos y mejores procesos de negocio y explotar el poder de TI para transformar el negocio. Mediante el uso de casos de uso de forma recursiva para (1) Modelar el negocio y sus interacciones con el mundo exterior y (2) modelar los sistemas necesarios para apoyar y mejorar el negocio, los desarrolladores pueden identificar sin problemas dónde los sistemas afectarán al negocio y qué sistemas se necesitan para respaldar el negocio.
Manejo de todo tipo de requisitos
Aunque son una de las técnicas más populares para describir la funcionalidad de los sistemas, también se utilizan casos de uso para explorar características no funcionales. La más simple forma de hacer esto es capturarlos como parte del caso de uso en sí mismo, por ejemplo, relacionar el requisito de desempeño al tiempo transcurrido entre los pasos específicos de un caso de uso o enumerar los niveles de servicio esperados para un caso de uso como parte del propio caso de uso. Algunas características no funcionales son más sutiles que esto y se aplica a muchos, si no a todos, los casos de uso. Esto es particularmente cierto cuando se construyen arquitecturas en capas, incluyendo componentes de infraestructura como seguridad, gestión de transacciones, servicios de mensajería y administración de datos.
Los requisitos en estas áreas aún pueden ser expresados como casos de uso: casos de uso separados centrados en el uso técnico del sistema. Estos casos de uso adicionales se denominan casos de uso de infraestructura, 8 ya que los requisitos que contiene impulsará la creación de la infraestructura sobre la que la aplicación se ejecutará.
Aplicable a todos los enfoques de desarrollo
Use-Case 2.0 funciona con todos los enfoques del desarrollo de software popular, que incluyen:- Enfoques iterativos impulsados por el backlog, como Scrum, EssUP y OpenUP.
- Enfoques basados en flujo de una sola pieza, como Kanban.
- Enfoques todo en uno, como la cascada tradicional.
Antes de adoptar cualquier enfoque basado en el backlog, debe comprender qué elementos se incluirán en la cartera de pedidos. Existen diversas formas de trabajos pendientes que los equipos utilizan para impulsar su trabajo, incluyendo productos, lanzamientos y trabajos atrasados del proyecto. Sin importar la terminología utilizada, todos siguen los mismos principios.
En el caso de uso 2.0, los segmentos del caso de uso son los principales elementos de la cartera de pedidos. El uso de porciones de casos de uso asegura que los elementos de la cartera de pedidos están bien formados, ya que son naturalmente independientes, valiosos y comprobables. La estructuración de la narrativa del caso de uso que los define se asegura de que sean estimables y negociables y la división de casos de uso, es el mecanismo les permite cortarlos tan pequeños como sea necesario para apoyar al equipo de desarrollo.
Cuando se adopta un enfoque impulsado por el backlog, es importante darse cuenta de que la acumulación en el backog no esté construida y completada por adelantado, pero se trabaja y perfecciona continuamente. La secuencia típica de actividades para un trabajo guiado por el backlog, de enfoque iterativo se muestra en la figura 6.
El flujo de una pieza es una técnica tomada de la manufactura esbelta LEAN que evita la agrupación de los requisitos vistos en los enfoques iterativos y en cascada. Cada elemento de requisitos fluye rápidamente a través del proceso de desarrollo, pero para trabajar efectivamente, esta técnica necesita artículos pequeños y de tamaño regular.
Los casos de uso serían de tamaño demasiado irregular y demasiado grandes para fluir a través del sistema. Sin embargo, las porciones de casos de uso se pueden dimensionar adecuadamente y sintonizados para satisfacer las necesidades del equipo. El flujo de una pieza no significa que solo haya un elemento de requisitos en el que se trabaja a la vez o que no es solo una pieza de trabajo entre una estación de trabajo y la siguiente. Es necesario que haya suficientes elementos en el sistema para mantener al equipo ocupado. Los límites de trabajo en curso se utilizan para nivelar el flujo y evitar que se acumulen atrasos inútiles.
La figura 7 muestra un tablero Kanban simple para visualizar el flujo del caso de uso rebanado en rodajas. Los límites de trabajo en curso se muestran en rojo. Leer de izquierda a derecha, puede ver que los cortes deben identificarse y delimitados antes de que sean aportados al equipo. En esta figura el límite de trabajo en curso es cinco, y los clientes, producto propietario o equipo de requisitos que son la fuente de los requisitos tratan de mantener cinco porciones de casos de uso listas para la implementación en todo momento.
Tenga en cuenta que no existe un tablero Kanban definitivo o un conjunto de límites de trabajo en curso; depende de la estructura del equipo y prácticas laborales. La junta y el trabajo en curso los límites deben ajustarse al igual que las prácticas. Los estados para las porciones de casos de uso son una gran ayuda para este tipo de diseño de trabajo ya que pueden definir claramente en qué estado debe estar el segmento cuándo se va a pasar a la siguiente parte de la cadena.
Por varias razones, es posible que deba desarrollar software dentro las limitaciones de alguna forma de modelo de gobernanza en cascada. Por lo general, esto significa que se hará algún intento de capturar todos los requisitos por adelantado antes de que se entreguen a un tercero para el desarrollo. En un enfoque en cascada, los casos de uso no son continuamente trabajados y refinados para permitir que surja el sistema final pero se definen de una sola vez al inicio del trabajo.
La naturaleza de una cosa a la vez del enfoque de cascada significa que la composición del equipo cambia continuamente con el tiempo, por lo que la capacidad de utilizar la comunicación cara a cara al compartir las historias es muy limitado. Para hacer frente a esto, se necesita aumentar el nivel de detalle de los productos de trabajo, yendo más allá de lo esencial.
Otro aspecto importante de Use-Case 2.0 es su capacidad para adaptarse a las estructuras de equipo existentes y las funciones laborales mientras anima a los equipos a eliminar el desperdicio y aumentar eficiencia. Con este fin, Use-Case 2.0 no predefine ningún tipo de roles o estructuras de equipo particulares, pero define un conjunto de estados para cada uno de los elementos centrales (el caso de uso y el segmento del caso de uso)
Como se ilustra en la discusión sobre el caso de uso 2.0 y el flujo de una pieza, los estados indican cuándo los elementos están en reposo y podría pasar de una persona o equipo a otro. Esto permite que la práctica se utilice con equipos de todas las formas y tamaños, de pequeños equipos multifuncionales con poca o ningun traspasos a grandes redes de equipos especializados donde cada cambio de estado es responsabilidad de otro especialista.
Seguimiento de los estados y traspasos de estos elementos permite que el flujo de trabajo a través del equipo (o equipos) sean monitoreados y equipos para adaptar su forma de trabajo para mejorar su desempeño de forma continua.
Ningún enfoque predefinido se adapta a todos, por lo que el uso del caso de uso 2.0 debe escalarse en varias dimensiones:
- Los casos de uso se amplían para proporcionar más orientación a menos profesionales con experiencia (desarrolladores, analistas, probadores, etc.) o profesionales que deseen o necesiten más orientación.
- Se amplían para cubrir todo el ciclo de vida, sin cubrir solo análisis, diseño, codificación y prueba, pero también el uso operacional y el mantenimiento.
- Se amplían para admitir sistemas grandes y muy grandes como como sistemas de sistemas: sistemas empresariales, líneas de productos y sistemas en capas. Tales sistemas son complejos y típicamente desarrollado por muchos equipos que trabajan en paralelo en diferentes sitios, posiblemente para diferentes empresas, y reutilizando muchos sistemas heredados o soluciones empaquetadas.
Independientemente de la complejidad del sistema bajo desarrollo, el equipo de desarrollo siempre comienza en la misma manera mediante la identificación de los casos de uso más importantes y creando una gran imagen que sintetiza cuáles son las necesidades para ser construidas. El caso de uso 2.0 se puede adaptar para cumplir con las necesidades del equipo. De hecho, la práctica del caso de uso 2.0 insiste en que inspeccione y adapte continuamente su uso para eliminar el desperdicio, aumentar el rendimiento y mantener el ritmo de demandas siempre cambiantes del equipo.
Historias de usuarios y casos de uso: ¿Cuál es la diferencia?
La mejor manera de responder a esta pregunta es mirar las propiedades comunes de las historias de usuario y casos de uso: las cosas que hacen que ambos funcionen bien como elementos de la lista de trabajos pendientes y habilita tanto para apoyar enfoques ágiles populares como Scrum, Kanban, o el desarrollo impulsado por pruebas y especificación por ejemplo. Las secciones de casos de uso y las historias de usuario 3 comparten muchas características. Por ejemplo:
- Ambos definen partes de la funcionalidad que los equipos pueden terminar en un sprint.
- Ambos se pueden cortar en rodajas si son demasiado grandes, resultando en más artículos más pequeños.
- Ambos se pueden escribir en fichas.
- Ambos dan como resultado en casos de prueba que representan los criterios de aceptación.
- Ambos son marcadores de posición para una conversación y se benefician de las tres C inventadas por Ron Jeffries: tarjeta, conversación y confirmación
- Ambos pueden estimarse con técnicas como planificación de póquer.
- Un panorama general para ayudar a las personas a comprender el alcance del sistema y su valor.
- Mayor comprensión de lo que hace el sistema y cómo lo hace.
- Mejor organización, comprensión, aplicación y mantenimiento de los activos de prueba.
- Fácil generación y análisis de casos de prueba.
- Soporte para análisis de impacto continuo.
- Gestión activa del alcance que permite enfocarse fácilmente en proporcionar el producto mínimo viable.
- Documentación flexible y escalable para ayudar a afrontar trazabilidad u otras limitaciones contractuales.
- Soporte para sistemas simples, sistemas complejos y sistemas de sistemas.
- Identificación más sencilla de funciones redundantes y faltantes.
La pregunta sigue siendo: ¿Qué técnica debería utilizar, que, una vez que va más allá de las preferencias personales, es muy dependiente del contexto? Considere los siguientes factores: cómo hay mucho acceso a SMEs (expertos en la materia); y cuán severos serán los errores de requisitos si escapan a un ambiente vivo.
El punto óptimo para las historias de usuario se logra cuando hay fácil acceso a un SME y la gravedad de los errores es baja. Usar los casos y los segmentos de casos de uso son más adecuados cuando no hay
acceso a un SME o cuando las consecuencias son elevadas.Dado que el enfoque de caso de uso puede reducirse a un paquete de historias de usuarios, sin embargo, es posible que desee aplicarlos. Si el sistema de sujetos siempre estará en el punto óptimo de historias de usuarios, las historias de usuarios están bien, pero si lo espera para crecer fuera de esa área, debe considerar los casos de uso y porciones de casos de uso.
Conclusión
El caso de uso 2.0 existe como una práctica probada y bien definida que es compatible con muchos otros programas de desarrollo de software y sus prácticas como la integración continua, arquitectura intencional y desarrollo impulsado por pruebas. También funciona con todas las prácticas de gestión populares. En particular, tiene la ligereza y flexibilidad para apoyar a los equipos que trabajan en un modo ágil o Lean. También tiene la integridad y el rigor necesario para apoyar a los equipos que trabajan de una manera más formal o en entorno de cascada.
