En ingeniería de software y sistemas , la frase caso de uso es un polisema con dos sentidos :
Este artículo analiza este último sentido. (Para más información sobre el otro sentido, consulte, por ejemplo, persona de usuario ).
Un caso de uso es una lista de acciones o pasos de eventos que generalmente definen las interacciones entre un rol (conocido en el Lenguaje Unificado de Modelado (UML) como actor ) y un sistema para lograr un objetivo. El actor puede ser un ser humano u otro sistema externo. En ingeniería de sistemas, los casos de uso se utilizan a un nivel más alto que dentro de la ingeniería de software , y a menudo representan misiones u objetivos de las partes interesadas . Los requisitos detallados pueden luego capturarse en Systems Modeling Language (SysML) o como declaraciones contractuales.
En 1987, Ivar Jacobson presentó el primer artículo sobre casos de uso en la conferencia OOPSLA '87. [1] Describió cómo se utilizó esta técnica en Ericsson para capturar y especificar los requisitos de un sistema utilizando técnicas de modelado textual, estructural y visual para impulsar el análisis y el diseño orientados a objetos. [2] Originalmente había usado los términos escenarios de uso y caso de uso (este último una traducción directa de su término sueco användningsfall ), pero descubrió que ninguno de estos términos sonaba natural en inglés y finalmente se decidió por caso de uso . [3]
En 1992 fue coautor del libro Ingeniería de software orientada a objetos: un enfoque basado en casos de uso , [4] que sentó las bases del método de ingeniería de sistemas OOSE y ayudó a popularizar los casos de uso para capturar requisitos funcionales , especialmente en el desarrollo de software . En 1994 publicó un libro sobre casos de uso y técnicas orientadas a objetos aplicadas a modelos de negocio y reingeniería de procesos de negocio . [5]
Al mismo tiempo, Grady Booch y James Rumbaugh trabajaron para unificar sus métodos de diseño y análisis orientados a objetos , el método Booch y la técnica de modelado de objetos (OMT) , respectivamente. En 1995 Ivar Jacobson se unió a ellos y juntos crearon el Lenguaje Unificado de Modelado (UML) , que incluye el modelado de casos de uso. UML fue estandarizado por el Object Management Group (OMG) en 1997. [6] Jacobson, Booch y Rumbaugh también trabajaron en un refinamiento del proceso de desarrollo de software Objectory . El Proceso Unificado resultante se publicó en 1999 y promovió un enfoque basado en casos de uso. [7]
Desde entonces, muchos autores han contribuido al desarrollo de la técnica, en particular: Larry Constantine desarrolló en 1995, en el contexto del diseño centrado en el uso , los llamados "casos de uso esenciales" que tienen como objetivo describir las intenciones del usuario en lugar de secuencias de acciones. o escenarios que podrían limitar o sesgar el diseño de la interfaz de usuario; [8] Alistair Cockburn publicó en 2000 una práctica de casos de uso orientada a objetivos basada en narrativas de texto y especificaciones tabulares; [9] Kurt Bittner e Ian Spence desarrollaron en 2002 prácticas avanzadas para analizar requisitos funcionales con casos de uso; [10] Dean Leffingwell y Don Widrig propusieron aplicar casos de uso para cambiar la gestión y las actividades de comunicación con las partes interesadas; [11] Gunnar Overgaard propuso en 2004 extender los principios de los patrones de diseño a los casos de uso. [12]
En 2011, Jacobson publicó con Ian Spence y Kurt Bittner el libro electrónico Use Case 2.0 para adaptar la técnica a un contexto ágil, enriqueciéndola con "porciones" de casos de uso incrementales y promoviendo su uso a lo largo de todo el ciclo de vida de desarrollo [13] después de haber presentado el enfoque renovado en la conferencia anual del IIBA. [14] [15]
Los casos de uso son una técnica para capturar, modelar y especificar los requisitos de un sistema. [10] Un caso de uso corresponde a un conjunto de comportamientos que el sistema puede realizar en interacción con sus actores, y que produce un resultado observable que contribuye a sus objetivos. Los actores representan el papel que tienen los usuarios humanos u otros sistemas en la interacción.
En el análisis de requisitos , en su identificación, se nombra un caso de uso de acuerdo con el objetivo de usuario específico que representa para su actor principal. El caso se detalla aún más con una descripción textual o con modelos gráficos adicionales que explican la secuencia general de actividades y eventos, así como variantes como condiciones especiales, excepciones o situaciones de error.
Según el Cuerpo de conocimientos de ingeniería de software (SWEBOK) , [16] los casos de uso pertenecen a las técnicas de obtención de requisitos basadas en escenarios , así como a las técnicas de análisis basado en modelos . Pero los casos de uso también respaldan la recopilación de requisitos basada en narrativas, la adquisición incremental de requisitos, la documentación del sistema y las pruebas de aceptación. [1]
Existen diferentes tipos de casos de uso y variaciones en la técnica:
El alcance de un caso de uso se puede definir por un tema y por objetivos:
Se sabe que los casos de uso se aplican en los siguientes contextos:
Hay muchas formas de escribir un caso de uso en el texto, desde un caso de uso breve , informal , esbozado , hasta completamente vestido, etc., y con plantillas variadas. Escribir casos de uso en plantillas diseñadas por varios proveedores o expertos es una práctica común en la industria para obtener requisitos funcionales del sistema de alta calidad.
La plantilla definida por Alistair Cockburn en su libro Writing Effective Use Cases ha sido uno de los estilos de escritura de casos de uso más utilizados. [ cita necesaria ]
Cockburn sugiere anotar cada caso de uso con un símbolo para mostrar el "Alcance del diseño", que puede ser un cuadro negro (los detalles internos están ocultos) o un cuadro blanco (se muestran los detalles internos). Hay cinco símbolos disponibles: [20]
Otros autores a veces llaman a los casos de uso a nivel de organización "casos de uso empresarial". [21]
Cockburn sugiere anotar cada caso de uso con un símbolo para mostrar el "Nivel de objetivo"; [22] el nivel preferido es "Objetivo de usuario" (o coloquialmente "nivel del mar" [23] : 101 ).
A veces, al escribir texto, un nombre de caso de uso seguido de un símbolo de texto alternativo (! +, -, etc.) es una forma más concisa y conveniente de indicar niveles, por ejemplo, ¡ realizar un pedido! , acceso- .
Cockburn describe una estructura más detallada para un caso de uso, pero permite simplificarla cuando se necesitan menos detalles. Su plantilla de caso de uso completa enumera los siguientes campos: [24]
Además, Cockburn sugiere utilizar dos dispositivos para indicar la naturaleza de cada caso de uso: iconos para el alcance del diseño y el nivel de objetivo.
El enfoque de Cockburn ha influido en otros autores; por ejemplo, Alexander y Beus-Dukic generalizan la plantilla de "caso de uso completo" de Cockburn desde software a sistemas de todo tipo, con los siguientes campos que difieren de Cockburn: [26]
Cockburn reconoce que es posible que los proyectos no siempre necesiten casos de uso detallados y "completamente diseñados". Describe un caso de uso informal con los campos: [24]
Martin Fowler afirma: "No existe una forma estándar de escribir el contenido de un caso de uso y diferentes formatos funcionan bien en diferentes casos". [23] : 100 Describe "un estilo común de usar" de la siguiente manera: [23] : 101
El estilo Fowler también puede verse como una variante simplificada de la plantilla Cockburn. Esta variante se llama historia de usuario .
Alistair Cockburn declaró: [27]
Piense en una historia de usuario como un caso de uso con 2 bits de precisión. El bit 1 de precisión nombra el objetivo del caso de uso y el bit 2 agrega el escenario principal. El bit 3 agrega las condiciones de falla, el bit 4 agrega las acciones de falla. El bit 5 añade una descripción de los datos de entrada/salida. Yo pondría Catalysis en el sexto bit de precisión, ya que también incluyen un modelo del destinatario del mensaje. En la familia CrystalMethodology, los proyectos con fundamentos diferentes utilizan casos con diferentes niveles de precisión. Un proyecto metodológicamente ligero utiliza Historias de usuarios, un proyecto metodológicamente más pesado utiliza casos de uso con 4 bits de precisión y Catalysis utiliza 6 bits de precisión.
Martin Fowler declaró: [27]
Se trata de cómo la gente usa los casos. He visto a muchas personas usar casos de manera muy formalizada. Kent hace sus UserStories de una manera mucho más accesible. Utilizo casos de la misma manera que Kent lo hace con las Historias de usuarios. Los invito a utilizar casos para comunicarse mejor con otros desarrolladores e influir en ellos para que utilicen un enfoque más ligero.
Un caso de uso define las interacciones entre actores externos y el sistema bajo consideración para lograr un objetivo. Los actores deben poder tomar decisiones, pero no necesitan ser humanos: "Un actor puede ser una persona, una empresa u organización, un programa de computadora o un sistema informático: hardware, software o ambos". [28] Los actores son siempre partes interesadas , pero no todas las partes interesadas son actores, ya que es posible que "nunca interactúen directamente con el sistema, aunque tienen derecho a preocuparse por cómo se comporta el sistema". [28] Por ejemplo, "los propietarios del sistema, la junta directiva de la empresa y los órganos reguladores como el Servicio de Impuestos Internos y el Departamento de Seguros" podrían ser todos interesados, pero es poco probable que sean actores. [28]
De manera similar, una persona que utiliza un sistema puede ser representada como un actor diferente debido a que desempeña roles diferentes. Por ejemplo, el usuario "Joe" podría desempeñar el papel de Cliente cuando usa un cajero automático para retirar efectivo de su propia cuenta o desempeñar el papel de Cajero de Banco cuando usa el sistema para reabastecer el cajón de efectivo en nombre del banco. .
Los actores suelen trabajar en nombre de otra persona. Cockburn escribe que "hoy en día escribo 'representante de ventas para el cliente' o 'empleado del departamento de marketing' para captar que el usuario del sistema actúa en nombre de otra persona". Esto le dice al proyecto que la "interfaz de usuario y las autorizaciones de seguridad" deben diseñarse para el representante de ventas y el empleado, pero que el departamento de atención al cliente y de marketing son los roles que se preocupan por los resultados. [29]
Una parte interesada puede desempeñar un papel tanto activo como inactivo: por ejemplo, un Consumidor es a la vez un "comprador del mercado masivo" (que no interactúa con el sistema) y un Usuario (un actor que interactúa activamente con el producto comprado). [30] A su vez, un Usuario es a la vez un "operador normal" (un actor que utiliza el sistema para el fin previsto) y un "beneficiario funcional" (una parte interesada que se beneficia del uso del sistema). [30] Por ejemplo, cuando el usuario "Joe" retira efectivo de su cuenta, está operando el cajero automático y obteniendo un resultado en su propio nombre.
Cockburn aconseja buscar actores entre las partes interesadas de un sistema, los actores primarios y secundarios (secundarios) de un caso de uso, el propio sistema bajo diseño (SuD) y, finalmente, entre los "actores internos", es decir, los componentes del sistema bajo diseño. diseño. [28]
De la misma manera que un caso de uso describe una serie de eventos e interacciones entre un usuario (u otro tipo de Actor) y un sistema, con el fin de producir un resultado de valor (objetivo), un caso de uso empresarial describe la interacción más general. entre un sistema empresarial y los usuarios/actores de ese sistema para producir resultados empresariales de valor. La principal diferencia es que el sistema considerado en un modelo de caso de uso empresarial puede contener personas además de sistemas tecnológicos. Estas "personas del sistema" se denominan trabajadores empresariales. En el ejemplo de un restaurante, se debe tomar la decisión de tratar a cada persona como un actor (por lo tanto fuera del sistema) o un trabajador de una empresa (dentro del sistema). Si un camarero se considera un actor, como se muestra en el siguiente ejemplo, entonces el sistema del restaurante no incluye al camarero y el modelo expone la interacción entre el camarero y el restaurante. Una alternativa sería considerar al camarero como parte del sistema del restaurante (un trabajador del negocio) y considerar al cliente como algo fuera del sistema (un actor). [31]
Los casos de uso no son sólo textos sino también diagramas si es necesario. En el Lenguaje de modelado unificado , las relaciones entre casos de uso y actores se representan en diagramas de casos de uso originalmente basados en la notación Objetoria de Ivar Jacobson . SysML usa la misma notación a nivel de bloque del sistema.
Además, también se pueden utilizar otros diagramas UML de comportamiento, como diagramas de actividad , diagramas de secuencia , diagramas de comunicación y diagramas de máquina de estados, para visualizar los casos de uso en consecuencia. Específicamente, un diagrama de secuencia del sistema (SSD) es un diagrama de secuencia que se usa a menudo para mostrar las interacciones entre los actores externos y el sistema bajo diseño (SuD), generalmente para visualizar un escenario particular de un caso de uso.
El análisis de casos de uso generalmente comienza dibujando diagramas de casos de uso. Para un desarrollo ágil, un modelo de requisitos de muchos diagramas UML que representen casos de uso más algunas descripciones textuales, notas o resúmenes de casos de uso sería muy liviano y suficiente para un uso en proyectos pequeños o fáciles. Como buenos complementos de los textos de casos de uso, las representaciones de diagramas visuales de los casos de uso también son herramientas facilitadoras efectivas para una mejor comprensión, comunicación y diseño de requisitos de comportamiento de sistemas complejos.
A continuación se muestra un caso de uso de muestra escrito con una versión ligeramente modificada de la plantilla estilo Cockburn. Tenga en cuenta que no hay botones, controles, formularios ni ningún otro elemento ni operación de la interfaz de usuario en la descripción del caso de uso básico, donde solo se expresan los objetivos, subobjetivos o intenciones del usuario en cada paso del flujo básico o las extensiones. Esta práctica aclara la especificación de requisitos y maximiza la flexibilidad del diseño y la implementación.
Caso de uso : editar un artículo
Actor principal : Miembro (Usuario registrado)
Alcance : un sistema Wiki
Nivel : ! (Objetivo del usuario o nivel del mar)
Breve : (equivalente a una historia de usuario o una epopeya)
Partes interesadas
...
Poscondiciones
Condiciones previas :
Desencadenantes :
Flujo básico :
Extensiones :
2–3.
4a. Se acabó el tiempo:
...
Desde el inicio del movimiento ágil, la técnica de historias de usuario de Extreme Programming ha sido tan popular que muchos piensan que es la única y mejor solución para los requisitos ágiles de todos los proyectos. Alistair Cockburn enumera cinco razones por las que todavía escribe casos de uso en desarrollo ágil . [32]
En resumen, especificar los requisitos del sistema en casos de uso tiene estos beneficios aparentes en comparación con los enfoques tradicionales u otros:
Centrado en el usuario
Los casos de uso constituyen una herramienta poderosa y centrada en el usuario para el proceso de especificación de requisitos de software. [33] El modelado de casos de uso generalmente comienza con la identificación de los roles clave de las partes interesadas ( actores ) que interactúan con el sistema, y sus metas u objetivos que el sistema debe cumplir (una perspectiva externa). Estos objetivos de usuario se convierten entonces en los candidatos ideales para los nombres o títulos de los casos de uso que representan las características funcionales deseadas o los servicios proporcionados por el sistema. Este enfoque centrado en el usuario garantiza que se desarrolle lo que tiene un valor comercial real y que el usuario realmente desea, no aquellas funciones triviales especuladas desde la perspectiva (interna) del desarrollador o del sistema.
La creación de casos de uso ha sido una herramienta de análisis importante y valiosa en el ámbito del diseño centrado en el usuario (DCU) durante años.
Mejor comunicación
Los casos de uso suelen escribirse en lenguajes naturales con plantillas estructuradas. Esta forma textual narrativa (historias de requisitos legibles), comprensible para casi todos y complementada con diagramas UML visuales, fomenta comunicaciones mejores y más profundas entre todas las partes interesadas, incluidos clientes, usuarios finales, desarrolladores, evaluadores y gerentes. Unas mejores comunicaciones dan como resultado requisitos de calidad y, por tanto, sistemas de calidad entregados.
Requisitos de calidad mediante exploración estructurada.
Una de las cosas más poderosas de los casos de uso reside en los formatos de las plantillas de casos de uso, especialmente el escenario de éxito principal (flujo básico) y los fragmentos del escenario de extensión (extensiones, flujos excepcionales y alternativos). Analizar un caso de uso paso a paso, desde las condiciones previas hasta las condiciones posteriores, explorando e investigando cada paso de acción de los flujos del caso de uso, desde lo básico hasta las extensiones, para identificar aquellos requisitos difíciles, normalmente ocultos e ignorados, aparentemente triviales pero, de manera realista, a menudo costosos (como mencionó Cockburn). arriba), es una forma estructurada y beneficiosa de conseguir requisitos claros, estables y de calidad de forma sistemática.
Minimizar y optimizar los pasos de acción de un caso de uso para lograr el objetivo del usuario también contribuye a un mejor diseño de interacción y experiencia de usuario del sistema.
Facilitar las pruebas y la documentación del usuario.
Con contenido basado en una estructura de flujo de acciones o eventos, un modelo de casos de uso bien escrito también sirve como base excelente y pautas valiosas para el diseño de casos de prueba y manuales de usuario del sistema o producto, lo cual es una inversión que vale la pena. -frente. Existen conexiones obvias entre las rutas de flujo de un caso de uso y sus casos de prueba. Derivar casos de prueba funcionales a partir de un caso de uso a través de sus escenarios (instancias en ejecución de un caso de uso) es sencillo. [34]
Las limitaciones de los casos de uso incluyen:
Los malentendidos comunes sobre los casos de uso son:
Las historias de usuarios son ágiles; los casos de uso no lo son.
Agile y Scrum son neutrales en cuanto a las técnicas de requisitos. Como afirma el Scrum Primer [39] ,
Los elementos del Product Backlog se articulan de cualquier manera que sea clara y sostenible. Contrariamente al malentendido popular, el Product Backlog no contiene "historias de usuarios"; simplemente contiene elementos. Esos elementos pueden expresarse como historias de usuarios, casos de uso o cualquier otro enfoque de requisitos que el grupo encuentre útil. Pero cualquiera que sea el enfoque, la mayoría de los artículos deberían centrarse en ofrecer valor a los clientes.
Las técnicas de casos de uso han evolucionado para tener en cuenta los enfoques ágiles mediante el uso de porciones de casos de uso para enriquecer incrementalmente un caso de uso. [13]
Los casos de uso son principalmente diagramas.
Craig Larman destaca que "los casos de uso no son diagramas, son texto". [40]
Los casos de uso tienen demasiado contenido relacionado con la interfaz de usuario.
Como dicen algunos, [ ¿quién? ]
Los casos de uso a menudo contendrán un nivel de detalle (es decir, nombres de etiquetas y botones) que los hace no adecuados para capturar los requisitos de un nuevo sistema desde cero.
Malentendidos de novatos. Cada paso de un caso de uso bien escrito debe presentar los objetivos o intenciones de los actores (la esencia de los requisitos funcionales) y normalmente no debe contener ningún detalle de la interfaz de usuario, por ejemplo, denominación de etiquetas y botones, operaciones de la interfaz de usuario, etc., lo cual es un mala práctica y complicará innecesariamente la redacción del caso de uso y limitará su implementación.
En cuanto a capturar los requisitos para un nuevo sistema desde cero, los diagramas de casos de uso y los resúmenes de casos de uso a menudo se utilizan como herramientas útiles y valiosas, al menos tan livianas como las historias de usuarios. [ cita necesaria ]
Escribir casos de uso para sistemas grandes es tedioso y una pérdida de tiempo.
Como dicen algunos, [ ¿quién? ]
El formato del caso de uso hace difícil describir un sistema grande (por ejemplo, un sistema CRM) en menos de varios cientos de páginas. Lleva mucho tiempo y terminará perdiendo tiempo haciendo una cantidad innecesaria de trabajo.
[ cita necesaria ]
Pasar mucho tiempo escribiendo casos de uso tediosos que agregan poco o ningún valor y dan como resultado una gran cantidad de retrabajo es un mal olor que indica que los escritores no están bien capacitados y tienen poco conocimiento sobre cómo escribir casos de uso de calidad de manera eficiente y efectiva. Los casos de uso deben crearse de forma iterativa, incremental y evolutiva ( ágil ). La aplicación de plantillas de casos de uso no significa que todos los campos de una plantilla de casos de uso deban usarse y completarse de manera integral desde el principio o durante una etapa especial dedicada, es decir, la fase de requisitos en el modelo de desarrollo en cascada tradicional .
De hecho, los formatos de casos de uso formulados por esos estilos de plantilla populares, por ejemplo, RUP y Cockburn (también adoptados por el método OUM ), etc., han demostrado en la práctica ser herramientas valiosas y útiles para capturar, analizar y documentar requisitos complejos. de grandes sistemas. La calidad de una buena documentación de caso de uso ( modelo ) no debe juzgarse en gran medida o únicamente por su tamaño. También es posible que un modelo de caso de uso integral y de calidad de un sistema grande finalmente evolucione a cientos de páginas principalmente debido a la complejidad inherente del problema en cuestión, no a las malas habilidades de escritura de sus autores. [ cita necesaria ]
A menudo se utilizan editores de texto y/o procesadores de texto con soporte de plantillas para escribir casos de uso. Para requisitos de sistemas grandes y complejos, las herramientas de casos de uso dedicadas son útiles.
Algunas de las herramientas de casos de uso más conocidas incluyen:
La mayoría de las herramientas UML admiten tanto la escritura de texto como el modelado visual de casos de uso.