Caso de uso

Un diagrama de casos de uso muy simple de un sistema Wiki.

Desarrollo de software
Actividades centrales de la ingeniería de software Procesos Requisitos Diseño Construcción Pruebas Depuración Despliegue Mantenimiento
Paradigmas y modelos Ágil Sala limpia Incremental Creación de prototipos Espiral Modelo V Cascada
Metodologías y marcos TEA DevOps PADRE DSDM FDD IID Kanban Lean SD Menos MDD MSF PSP RAD RUP A salvo Melé SEMAT TSP Abrir ARRIBA XP
Disciplinas de apoyo Gestión de la configuración Documentación Aseguramiento de la calidad del software Gestión de proyectos Experiencia de usuario
Practicas ATDD BDD CCO CI CD DDD PÁGINAS SBE Levántate TDD
Instrumentos Compilador Depurador Perfilador Diseñador de GUI Modelado IDE Automatización de construcción Automatización de lanzamientos Infraestructura como código Pruebas
Estándares y cuerpos de conocimiento BABOK CMMI Estándares IEEE ISO 9001 Normas ISO / IEC PMBOK SWEBOK ITIL IREB
Glosarios Inteligencia artificial Ciencias de la Computación Ingeniería eléctrica y electrónica
Contornos Esquema del desarrollo de software
v t mi

En ingeniería de software y sistemas, la frase caso de uso es un polisema con dos sentidos :

1. Un escenario de uso de una pieza de software; se utiliza a menudo en plural para sugerir situaciones en las que un software puede resultar útil.
2. Un escenario potencial en el que un sistema recibe una solicitud externa (como una entrada del usuario) y responde a ella.

Este artículo analiza el último sentido.

Un caso de uso es una lista de acciones o pasos de eventos que típicamente 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 humano u otro sistema externo. En la ingeniería de sistemas, los casos de uso se utilizan a un nivel más alto que en la ingeniería de software, y a menudo representan misiones o objetivos de las partes interesadas. Los requisitos detallados se pueden capturar en el lenguaje de modelado de sistemas (SysML) o como declaraciones contractuales.

• 1 Historia
• 2 Principio general
  • 2.1 Variaciones
  • 2.2 Alcance
  • 2.3 Uso
• 3 plantillas
  • 3.1 estilo Cockburn
    • 3.1.1 Ámbitos de diseño
    • 3.1.2 Niveles de objetivos
    • 3.1.3 Completamente vestido
    • 3.1.4 Casual
  • 3.2 Estilo Fowler
• 4 actores
• 5 Caso de uso empresarial
• 6 Modelado visual
• 7 ejemplos
• 8 ventajas
• 9 Limitaciones
• 10 conceptos erróneos
• 11 herramientas
• 12 Véase también
• 13 referencias
• 14 Lecturas adicionales
• 15 Enlaces externos

Historia

En 1987, Ivar Jacobson presentó el primer artículo sobre casos de uso en la conferencia OOPSLA '87. 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 orientado a objetos. 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 el caso de uso.

En 1992 fue coautor del libro Ingeniería de software orientada a objetos: un enfoque basado en casos de uso, 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.

Al mismo tiempo, Grady Booch y James Rumbaugh trabajaron en 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 de modelado unificado (UML), que incluye el modelado de casos de uso. UML fue estandarizado por Object Management Group (OMG) en 1997. 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.

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 restringir o sesgar el diseño de la interfaz de usuario; Alistair Cockburn publicó en 2000 una práctica de casos de uso orientada a objetivos basada en narrativas de texto y especificaciones tabulares; Kurt Bittner e Ian Spence desarrollaron en 2002 prácticas avanzadas para analizar requisitos funcionales con casos de uso; Dean Leffingwell y Don Widrig propusieron aplicar casos de uso a la gestión del cambio y las actividades de comunicación con las partes interesadas; Gunnar Overgaard propuso en 2004 extender los principios de los patrones de diseño a los casos de uso.

En 2011, Jacobson publicó con Ian Spence y Kurt Bittner el ebook Use Case 2.0 para adaptar la técnica a un contexto ágil, enriqueciéndola con "porciones" incrementales de casos de uso y promoviendo su uso durante todo el ciclo de vida del desarrollo después de haber presentado el enfoque renovado. en la conferencia anual del IIBA.

Principio general

Los casos de uso son una técnica para capturar, modelar y especificar los requisitos de un sistema. 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 los usuarios humanos u otros sistemas tienen en la interacción.

En el análisis de requisitos, en su identificación, un caso de uso se nombra de acuerdo con el objetivo de usuario específico que representa para su actor principal. El caso se detalla 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.

De acuerdo con el Cuerpo de Conocimientos de Ingeniería de Software (SWEBOK), los casos de uso pertenecen a las técnicas de elicitación de requisitos basadas en escenarios, así como a las técnicas de análisis basadas en modelos. Pero los casos de uso también admiten la recopilación de requisitos basada en narrativas, la adquisición de requisitos incrementales, la documentación del sistema y las pruebas de aceptación.

Variaciones

Hay diferentes tipos de casos de uso y variaciones en la técnica:

• Los casos de uso del sistema especifican los requisitos de un sistema a desarrollar. Identifican en su descripción detallada no solo las interacciones con los actores sino también las entidades que están involucradas en el procesamiento. Son el punto de partida para futuros modelos de análisis y actividades de diseño.
• Los casos de uso empresarial se centran en una organización empresarial en lugar de en un sistema de software. Se utilizan para especificar modelos comerciales y requisitos de procesos comerciales en el contexto de iniciativas de reingeniería de procesos comerciales.
• Los casos de uso esenciales, también llamados casos de uso abstracto, describen las intenciones potenciales de los actores y cómo el sistema las aborda, sin definir ninguna secuencia ni describir un escenario. Esta práctica se desarrolló con el objetivo de respaldar el diseño centrado en el usuario y evitar inducir sesgos sobre la interfaz de usuario en la etapa inicial de las especificaciones del sistema.
• El caso de uso 2.0 adapta la técnica al contexto de los métodos de desarrollo ágiles. Esta técnica enriquece la práctica de recopilación de requisitos con soporte para narrativas de historias de usuarios. También proporciona "porciones" de casos de uso para facilitar la obtención incremental de requisitos y permitir una implementación incremental.

Alcance

El alcance de un caso de uso se puede definir por tema y por objetivos:

• El sujeto identifica el sistema, subsistema o componente que proporcionará las interacciones.
• Los objetivos se pueden estructurar jerárquicamente, teniendo en cuenta el nivel organizativo interesado en el objetivo (por ejemplo, empresa, departamento, usuario) y la descomposición del objetivo del usuario en subobjetivos. La descomposición del objetivo se realiza desde el punto de vista de los usuarios, e independientemente del sistema, lo que se diferencia de la descomposición funcional tradicional.  

Uso

Se sabe que los casos de uso se aplican en los siguientes contextos:

• Ingeniería de Software Orientada a Objetos (OOSE), como elemento impulsor;
• Lenguaje de modelado unificado (UML), como instrumento de modelado de comportamiento;
• Proceso Unificado de Desarrollo de Software (UP) y su precursor, el Proceso Unificado IBM Rational (RUP) ;
• documentación inicial de la especificación de requisitos de software (SRS), como estructura alternativa para los requisitos funcionales;
• derivar el diseño de los requisitos utilizando el enfoque de frontera de control de entidad ;
• y desarrollo ágil.

Plantillas

Hay muchas formas de escribir un caso de uso en texto, desde un caso de uso breve, informal, contorneado, 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 de la industria para obtener requisitos de sistema funcionales de alta calidad.

Estilo cockburn

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.

Ámbitos de diseño

Cockburn sugiere anotar cada caso de uso con un símbolo para mostrar el "Alcance del diseño", que puede ser una caja negra (los detalles internos están ocultos) o una caja blanca (se muestran los detalles internos). Hay cinco símbolos disponibles:

Alcance	Icono
Organización (caja negra)	Casa llena
Organización (caja blanca)	Casa sin llenar
Sistema (caja negra)	Caja llena
Sistema (caja blanca)	Caja sin llenar
Componente	Tornillo o perno

Otros autores a veces denominan casos de uso a nivel de organización "Casos de uso de negocios".

Niveles de objetivos

Jerarquía de niveles de objetivos

Cockburn sugiere anotar cada caso de uso con un símbolo para mostrar el "Nivel de objetivo"; el nivel preferido es "Objetivo de usuario" (o coloquialmente "nivel del mar").

Nivel de objetivo	Icono	Símbolo
Resumen muy alto	Nube	++
Resumen	Cometa voladora	+
Objetivo de usuario	Olas en el mar	!
Sub función	Pez	-
Demasiado baja	Concha de almeja de los fondos marinos	-

A veces, en la escritura de 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 denotar niveles, por ejemplo, ¡ hacer un pedido!, iniciar sesión-.

Completamente vestido

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 completamente vestida enumera los siguientes campos:

• Título: "una frase de objetivo con verbo activo que nombra el objetivo del actor principal"
• Actor principal
• Objetivo en contexto
• Alcance
• Nivel
• Partes interesadas e intereses
• Condición previa
• Garantías mínimas
• Garantías de éxito
• Desencadenar
• Escenario principal de éxito
• Extensiones
• Lista de variaciones de tecnología y datos

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 la meta.

El enfoque de Cockburn ha influido en otros autores; por ejemplo, Alexander y Beus-Dukic generalizan la plantilla de "casos de uso completamente equipados" de Cockburn desde el software a los sistemas de todo tipo, con los siguientes campos que difieren de Cockburn:

• Escenarios de variación "(tal vez saliendo del escenario principal y tal vez regresando al mismo)"
• Excepciones "es decir, eventos de excepción y sus escenarios de manejo de excepciones"

Casual

Cockburn reconoce que es posible que los proyectos no siempre necesiten casos de uso detallados "completamente vestidos". Describe un caso de uso casual con los campos:

• Título (gol)
• Actor principal
• Alcance
• Nivel
• (Historia): el cuerpo del caso de uso es simplemente un párrafo o dos de texto, describiendo informalmente lo que sucede.

Estilo cazador

Martin Fowler afirma que "no existe una forma estándar de escribir el contenido de un caso de uso, y diferentes formatos funcionan bien en diferentes casos". Describe "un estilo común de usar" de la siguiente manera:

• Título: "objetivo que el caso de uso intenta satisfacer"
• Escenario principal de éxito: lista numerada de pasos
  • Paso: "una simple declaración de la interacción entre el actor y un sistema"
• Extensiones: listas numeradas por separado, una por extensión
  • Extensión: "una condición que resulta en interacciones diferentes de... el escenario principal de éxito". Una extensión del paso principal 3 se numera 3a, etc.

El estilo Fowler también se puede ver como una variante simplificada de la plantilla Cockburn.

Actores

Artículo principal: Actor (UML)

Un caso de uso define las interacciones entre los actores externos y el sistema en consideración para lograr un objetivo. Los actores deben poder tomar decisiones, pero no es necesario que sean 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". Los actores son siempre partes interesadas, pero no todas las partes interesadas son actores, ya que "nunca interactúan directamente con el sistema, aunque tienen derecho a preocuparse por cómo se comporta el sistema". Por ejemplo, "los propietarios del sistema, la junta directiva de la empresa y los organismos reguladores como el Servicio de Impuestos Internos y el Departamento de Seguros" podrían ser partes interesadas, pero es poco probable que sean actores.

De manera similar, una persona que usa un sistema puede ser representada como diferentes actores debido a que desempeña diferentes roles. Por ejemplo, el usuario "Joe" podría estar desempeñando el papel de un Cliente cuando usa un cajero automático para retirar efectivo de su propia cuenta, o desempeñando el papel de un cajero de banco cuando usa el sistema para reabastecer el cajón de efectivo en nombre del Banco.

Los actores a menudo trabajan en nombre de otra persona. Cockburn escribe que "En estos días escribo 'representante de ventas del cliente' o 'empleado del departamento de marketing' para captar que el usuario del sistema está actuando 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 cliente y el departamento de marketing son los roles que se preocupan por los resultados.

Una parte interesada puede desempeñar un papel tanto activo como inactivo: por ejemplo, un consumidor es tanto un "comprador del mercado masivo" (que no interactúa con el sistema) como un usuario (un actor que interactúa activamente con el producto comprado). A su vez, un Usuario es tanto un "operador normal" (un actor que usa el sistema para su propósito previsto) como un "beneficiario funcional" (un interesado que se beneficia del uso del sistema). 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 sistema en diseño (SuD) en sí mismo y, finalmente, entre los "actores internos", es decir, los componentes del sistema. bajo diseño.

Caso de uso empresarial

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, para 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 comerciales. En el ejemplo de un restaurante, se debe decidir si tratar a cada persona como un actor (por lo tanto, fuera del sistema) o como un trabajador comercial (dentro del sistema). Si un mesero se considera un actor, como se muestra en el ejemplo siguiente, entonces el sistema de restaurante no incluye al mesero y el modelo expone la interacción entre el mesero y el restaurante. Una alternativa sería considerar al camarero como parte del sistema del restaurante (un trabajador comercial), mientras que se considera que el cliente está fuera del sistema (un actor).

Un diagrama de casos de uso empresarial muestra un modelo de varios casos de uso empresarial (objetivos) que representan las interacciones entre un restaurante (el sistema empresarial) y sus principales interesados ​​( actores empresariales y trabajadores empresariales).

Modelado visual

Tipos de diagramas UML
Diagramas estructurales UML
Diagrama de clase Diagrama de componentes Diagrama de estructura compuesta Diagrama de implementación Diagrama de objetos Diagrama del paquete Diagrama de perfil
Diagramas de comportamiento UML
Diagrama de actividad Diagrama de comunicación Diagrama de descripción general de la interacción Diagrama de secuencia Diagrama de estado Diagrama de tiempo Use el diagrama del caso
v t mi

Los casos de uso no son solo textos, sino también diagramas, si es necesario. En el lenguaje de modelado unificado, las relaciones entre los casos de uso y los actores se representan en diagramas de casos de uso basados ​​originalmente en la notación Objectory de Ivar Jacobson. SysML usa la misma notación a nivel de bloque del sistema.

Además, otros diagramas UML de comportamiento, como diagramas de actividad, diagramas de secuencia, diagramas de comunicación y diagramas de máquinas de estado, también se pueden utilizar 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 representan casos de uso más algunas descripciones textuales, notas o resúmenes de casos de uso sería muy liviano y lo suficiente para el uso de 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 de facilitación efectivas para la mejor comprensión, comunicación y diseño de los requisitos de comportamiento del sistema complejo.

Ejemplos de

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 o cualquier otro elemento y operación de la interfaz de usuario en la descripción del caso de uso básico, donde solo los objetivos, subobjetivos o intenciones del usuario se expresan en cada paso del flujo básico o extensiones. Esta práctica hace que la especificación de requisitos sea más clara y maximiza la flexibilidad del diseño y las implementaciones.

Caso de uso: editar un artículo

Actor principal: Miembro (Usuario registrado)

Alcance: un sistema Wiki

Nivel:! (Objetivo de usuario o nivel del mar)

Breve: (equivalente a una historia de usuario o una epopeya)

El miembro edita cualquier parte (el artículo completo o solo una sección) de un artículo que está leyendo. La vista previa y la comparación de cambios se permiten durante la edición.

Partes interesadas

...

Postcondiciones

Garantías mínimas:

Garantías de éxito:

• El artículo se guarda y se muestra una vista actualizada.
• El sistema crea un registro de edición para el artículo, por lo que los observadores del artículo pueden ser informados de la actualización más adelante.

Condiciones previas:

El artículo con la edición habilitada se presenta al miembro.

Desencadenantes:

El miembro invoca una solicitud de edición (para el artículo completo o solo una sección) en el artículo.

Flujo básico:

1. El sistema proporciona una nueva área / caja de editor llena con todo el contenido relevante del artículo con un resumen de edición informativo para que el miembro lo edite. Si el miembro solo desea editar una sección del artículo, solo se muestra el contenido original de la sección, y el título de la sección se completa automáticamente en el resumen de la edición.
2. El miembro modifica el contenido del artículo hasta que esté satisfecho.
3. El miembro completa el resumen de la edición, le dice al sistema si desea ver este artículo y envía la edición.
4. El sistema guarda el artículo, registra el evento de edición y finaliza cualquier procesamiento posterior necesario.
5. El sistema presenta la vista actualizada del artículo al miembro.

Extensiones:

2-3.

un. Mostrar vista previa:

1. El miembro selecciona Mostrar vista previa que envía el contenido modificado.
2. El sistema vuelve a ejecutar el paso 1 con la adición del contenido actualizado renderizado para la vista previa, e informa al miembro que sus ediciones aún no se han guardado y luego continúa.

B. Mostrar cambios:

1. El miembro selecciona Mostrar cambios que envía el contenido modificado.
2. El sistema vuelve a ejecutar el paso 1 con la adición de mostrar los resultados de comparar las diferencias entre las ediciones actuales del miembro y la versión guardada más reciente del artículo, luego continúa.

C. Cancelar la edición:

1. El miembro selecciona Cancelar.
2. El sistema descarta cualquier cambio que haya realizado el miembro y luego pasa al paso 5.

4a. Se acabó el tiempo:

...

Ventajas

Desde el inicio del movimiento ágil, la técnica de historia 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.

1. La lista de nombres de objetivos proporciona el resumen más breve de lo que ofrecerá el sistema (incluso que las historias de usuarios ). También proporciona un esqueleto de planificación de proyectos, que se utilizará para crear prioridades iniciales, estimaciones, asignación de equipos y tiempos.
2. El escenario de éxito principal de cada caso de uso proporciona a todos los involucrados un acuerdo sobre lo que hará básicamente el sistema y lo que no hará. Proporciona el contexto para cada requisito de línea de pedido específico (por ejemplo, historias de usuario detalladas), un contexto que es muy difícil de obtener en cualquier otro lugar.
3. Las condiciones de extensión de cada caso de uso proporcionan un marco para investigar todas las cosas pequeñas y molestas que de alguna manera ocupan el 80% del tiempo y el presupuesto de desarrollo. Proporciona un mecanismo de anticipación, por lo que las partes interesadas pueden detectar problemas para los que probablemente tomará mucho tiempo obtener respuestas. Estos problemas pueden y deben adelantarse al cronograma, de modo que las respuestas puedan estar listas cuando el equipo de desarrollo comience a trabajar en ellos.
4. Los fragmentos de escenarios de extensión de casos de uso proporcionan respuestas a muchas preguntas comerciales detalladas, a menudo engañosas e ignoradas: "¿Qué se supone que debemos hacer en este caso?" Es un marco de pensamiento / documentación que coincide con la declaración if... then... else que ayuda a los programadores a analizar los problemas. Excepto que se hace en el momento de la investigación, no en el momento de la programación.
5. El conjunto completo de casos de uso muestra que los investigadores han pensado en las necesidades de cada usuario, cada objetivo que tienen con respecto al sistema y cada variante comercial involucrada.

En resumen, especificar los requisitos del sistema en los 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 poderosa herramienta centrada en el usuario para el proceso de especificación de requisitos de software. El modelado de casos de uso generalmente comienza con la identificación de los roles de las partes interesadas clave ( 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 en 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 el valor comercial real y el usuario realmente desea, no esas funciones triviales especuladas desde la perspectiva del desarrollador o del sistema (desde adentro).

La creación de casos de uso ha sido una herramienta de análisis importante y valiosa en el dominio del Diseño Centrado en el Usuario (UCD) durante años.

Mejor comunicación

Los casos de uso a menudo se escriben en lenguajes naturales con plantillas estructuradas. Esta forma textual narrativa (historias de requisitos legibles), comprensible para casi todos, 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. Las mejores comunicaciones dan como resultado requisitos de calidad y, por lo tanto, se entregan sistemas de calidad.

Requisitos de calidad por 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 principal de éxito (flujo básico) y los fragmentos del escenario de extensión (extensiones, flujos excepcionales y / o alternativos). Analizar un caso de uso paso a paso desde las condiciones previas a las condiciones posteriores, explorar e investigar cada paso de acción de los flujos de casos de uso, desde los básicos hasta las extensiones, para identificar esos requisitos difíciles, normalmente ocultos e ignorados, aparentemente triviales pero a menudo realistas y 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 del usuario del sistema.

Facilitar las pruebas y la documentación del usuario

Con contenido basado en una estructura de flujo de eventos o acciones, un modelo de casos de uso bien escritos también sirve como una base excelente y guías valiosas para el diseño de casos de prueba y manuales de usuario del sistema o producto, que es una inversión que vale la pena. en la delantera. Hay 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 (ejecutar instancias de un caso de uso) es sencillo.

Limitaciones

Las limitaciones de los casos de uso incluyen:

• Los casos de uso no son adecuados para capturar los requisitos de un sistema que no se basan en la interacción (como los requisitos de algoritmo o matemáticos) o los requisitos no funcionales (como la plataforma, el rendimiento, el tiempo o los aspectos críticos para la seguridad). Estos se especifican mejor declarativamente en otro lugar.
• Como no existen definiciones completamente estándar de casos de uso, cada proyecto debe formar su propia interpretación.
• Algunas relaciones de casos de uso, como las extensiones, son ambiguas en la interpretación y pueden ser difíciles de entender para las partes interesadas, como señaló Cockburn (problema n. ° 6)
• Los desarrolladores de casos de uso a menudo tienen dificultades para determinar el nivel de dependencia de la interfaz de usuario (UI) para incorporar en un caso de uso. Si bien la teoría de casos de uso sugiere que la interfaz de usuario no se refleja en los casos de uso, puede ser incómodo abstraer este aspecto del diseño, ya que dificulta la visualización de los casos de uso. En ingeniería de software, esta dificultad se resuelve aplicando la trazabilidad de requisitos, por ejemplo con una matriz de trazabilidad. Otro enfoque para asociar elementos de IU con casos de uso es adjuntar un diseño de IU a cada paso del caso de uso. Esto se denomina guión gráfico de casos de uso.
• Los casos de uso se pueden enfatizar demasiado. Bertrand Meyer analiza cuestiones como la conducción del diseño del sistema de forma demasiado literal a partir de casos de uso y el uso de casos de uso con exclusión de otras técnicas de análisis de requisitos potencialmente valiosas.
• Los casos de uso son un punto de partida para el diseño de pruebas, pero dado que cada prueba necesita sus propios criterios de éxito, es posible que sea necesario modificar los casos de uso para proporcionar condiciones posteriores independientes para cada ruta.
• Aunque los casos de uso incluyen objetivos y contextos, si estos objetivos y motivaciones detrás de los objetivos (preocupaciones de las partes interesadas y sus evaluaciones, incluida la no interacción) entran en conflicto o afectan de forma negativa / positiva a otros objetivos del sistema, están sujetos a técnicas de modelado de requisitos orientados a objetivos (como BMM, I *, KAOS y ArchiMate ARMOR).

Conceptos erróneos

Los malentendidos comunes sobre los casos de uso son:

Las historias de usuario son ágiles; los casos de uso no lo son.

Agile y Scrum son neutrales en cuanto a técnicas de requisitos. Como dice Scrum Primer,

Los elementos de la cartera de productos se articulan de forma 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 usuario, casos de uso o cualquier otro enfoque de requisitos que el grupo considere útil. Pero sea cual sea el enfoque, la mayoría de los artículos deben 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 gradualmente un caso de uso.

Los casos de uso son principalmente diagramas.

Craig Larman destaca que "los casos de uso no son diagramas, son texto".

Los casos de uso tienen demasiado contenido relacionado con la interfaz de usuario.

Como dicen algunos,

Los casos de uso a menudo contienen un nivel de detalle (es decir, nombres de etiquetas y botones) que lo hacen no adecuado 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 del actor (la esencia de los requisitos funcionales), y normalmente no debe contener ningún detalle de la interfaz de usuario, por ejemplo, nombres de etiquetas y botones, operaciones de la interfaz de usuario, etc., lo cual es un mal práctica y complicará innecesariamente la redacción de casos de uso y limitará su implementación.

En cuanto a la captura de requisitos para un nuevo sistema desde cero, los diagramas de casos de uso más los resúmenes de casos de uso se utilizan a menudo como herramientas útiles y valiosas, al menos tan ligeras como las historias de usuario.

Escribir casos de uso para sistemas grandes es tedioso y una pérdida de tiempo.

Como dicen algunos,

El formato del caso de uso dificulta la descripción de un sistema grande (por ejemplo, un sistema CRM) en menos de varios cientos de páginas. Lleva mucho tiempo y se encontrará gastando tiempo haciendo una cantidad innecesaria de reelaboración.

Pasar mucho tiempo escribiendo casos de uso tediosos que agregan poco o ningún valor y dan como resultado una gran cantidad de reelaboración es un mal olor que indica que los escritores no están bien capacitados y tienen poco conocimiento de cómo escribir casos de uso de calidad de manera eficiente y efectiva. Los casos de uso deben ser creados de manera 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 dedicada especial, es decir, la fase de requisitos en el modelo de desarrollo de cascada tradicional.

De hecho, los formatos de casos de uso formulados por esos estilos de plantilla populares, por ejemplo, los RUP y los Cockburn (también adoptados por el método OUM ), etc., se han demostrado en la práctica como herramientas valiosas y útiles para capturar, analizar y documentar requisitos complejos de grandes sistemas. La calidad de una buena documentación de casos de uso ( modelo) no debe juzgarse en gran medida o solo por su tamaño. También es posible que un modelo de caso de uso completo y de calidad de un sistema grande pueda finalmente evolucionar a cientos de páginas principalmente debido a la complejidad inherente del problema en cuestión, no debido a las deficientes habilidades de escritura de sus autores.

Instrumentos

Los editores de texto y / o procesadores de texto con soporte para plantillas se utilizan a menudo para escribir casos de uso. Para requisitos de sistema grandes y complejos, las herramientas de casos de uso dedicadas son útiles.

Algunas de las herramientas de casos de uso más conocidas incluyen:

• CaseComplete
• Arquitecto Empresarial
• MagicDraw
• RequisitePro de Rational Software : una de las primeras y más conocidas herramientas de gestión de requisitos y casos de uso de la década de 1990.
• Modelador de ideas de software
• Software wiki : buenas herramientas para que los equipos creen y gestionen casos de uso de forma colaborativa.

La mayoría de las herramientas UML admiten tanto la escritura de texto como el modelado visual de casos de uso.

Ver también

• Caso de abuso
• Caso de negocio
• Límite de control de entidad
• Partición de eventos
• Característica
• Lista de herramientas UML
• Caso de mal uso
• Requisito
• Obtención de requisitos
• Guión
• Storyboard
• Caso de prueba
• Puntos de casos de uso

Referencias

Otras lecturas

• Alexander, Ian y Beus-Dukic, Ljerka. Descubrimiento de requisitos: cómo especificar productos y servicios. Wiley, 2009.
• Alexander, Ian y Maiden, Neil. Escenarios, historias, casos de uso. Wiley 2004.
• Armour, Frank y Granville Miller. Modelado avanzado de casos de uso: sistemas de software. Addison-Wesley, 2000.
• Kurt Bittner, Ian Spence, Modelado de casos de uso, Addison-Wesley Professional, 20 de agosto de 2002.
• Cockburn, Alistair. Redacción de casos de uso eficaz. Addison-Wesley, 2001.
• Larry Constantine, Lucy Lockwood, Software para uso: una guía práctica de los modelos y métodos esenciales de diseño centrado en el uso, Addison-Wesley, 1999.
• Denney, Richard. Tener éxito con los casos de uso: trabajar de forma inteligente para ofrecer calidad. Addison-Wesley, 2005.
• Fowler, Martin. UML Distilled (tercera edición). Addison-Wesley, 2004.
• Jacobson Ivar, Christerson M., Jonsson P., Övergaard G., Ingeniería de software orientada a objetos: un enfoque basado en casos de uso, Addison-Wesley, 1992.
• Jacobson Ivar, Spence I., Bittner K. Use Case 2.0: La guía para tener éxito con los casos de uso, IJI SA, 2011.
• Dean Leffingwell, Don Widrig, Gestión de requisitos de software: un enfoque de caso de uso, Addison-Wesley Professional. 7 de diciembre de 2012.
• Kulak, Daryl y Eamonn Guiney. Casos de uso: requisitos en contexto. Addison-Wesley, 2012.
• Meyer, Bertrand. Construcción de software orientado a objetos. (2ª edición). Prentice Hall, 2000.
• Schneider, Geri y Winters, Jason P. Aplicación de casos de uso 2ª edición: una guía práctica. Addison-Wesley, 2001.
• Wazlawick, Raul S. Análisis y diseño orientado a objetos para sistemas de información: modelado con UML, OCL e IFML. Morgan Kaufmann, 2014.

enlaces externos

• Columna de casos de uso y plantilla de casos de uso básicos de Alistair Cockburn
• Casos de uso en Usabilidad.gov de GSA
• Aplicación de casos de uso para el análisis de las partes interesadas "Proyecto Ícaro" en Academia.edu
• Busque "caso de uso" en IBM Developer