¿Por qué Casos de Uso?.

Presentación del tema: "¿Por qué Casos de Uso?."— Transcripción de la presentación:

1 ¿Por qué Casos de Uso?

2 Índice ¿Por qué Casos de Uso?
Para capturar los requisitos que aportan valor añadido Para dirigir el proceso Para idear la arquitectura y más... La captura de casos de uso

3 ¿Por qué casos de uso? Existen varios motivos por los cuales los casos de uso son buenos, se han hecho populares y se han adoptado universalmente. Las dos razones fundamentales son: Proporcionan un medio sistemático e intuitivo de capturar requisitos funcionales (Capítulos 6 y 7) centrándose en el valor añadido para el usuario. Dirigen todo el proceso de desarrollo debido a que la mayoría de las actividades como el análisis, diseño y prueba se llevan a cabo partiendo de los casos de uso.

4 ¿Por qué casos de uso? El diseño y la prueba pueden también planificarse y coordinarse en términos de casos de uso. Esta característica es aún más evidente cuando la arquitectura se ha estabilizado en el proyecto, después del primer conjunto de iteraciones. Según Karl Wieger, “la perspectiva que proporcionan los casos de uso refuerza el objetivo último de la ingeniería del software: la creación de productos que permitan a los clientes realizar un trabajo útil.”

5 Para capturar los requisitos que aportan valor añadido
Existen varias razones por las cuales esto es cierto. En primer lugar, la idea de caso de uso permite la identificación del software que cumple con los objetivos del usuario. Los casos de uso son las funciones que proporciona un sistema para añadir valor a sus usuarios. Tomando la perspectiva de cada tipo de usuario, podemos capturar los casos de uso que necesitan para hacer su trabajo. Regresar

6 Para capturar los requisitos que aportan valor añadido
Por otro lado, si comenzamos pensando en un conjunto de buenas funciones del sistema sin pensar en los casos de uso que emplean los usuarios concretos, será difícil decir si esas funciones son importantes o incluso si son buenas. ¿A quién ayudan? ¿Qué necesidades del negocio satisfacen? ¿Cuánto valor añaden al negocio? Los mejores casos de uso son aquellos que añaden el mayor valor al negocio que implanta el sistema.

7 Para capturar los requisitos que aportan valor añadido
Un caso de uso que aporta un valor negativo o que permite hacer al usuario cosas que no debería poder hacer no es un caso de uso. Podríamos llamarlo un “caso de abuso”, ya que especifica formas de utilizar el sistema que deben prohibirse. Un ejemplo de un caso de uso de este tipo sería permitir a un cliente de un banco transferir dinero de la cuenta de otro a la suya. Los casos de uso que aportan poco o ningún valor se utilizarán con menos frecuencia; son “casos sin-uso” superfluos.

8 Para capturar los requisitos que aportan valor añadido
Se ha llegado a la conclusión de que preguntarse a sí mismos sobre qué quieren que haga el sistema no les ayuda a obtener las respuestas correctas. En su lugar, obtienen una lista de funciones del sistema, que a primera vista puede parecer valiosa, pero cuando se examina más en profundidad se ve que no necesariamente está relacionada con las necesidades del usuario. Puede parecer que la estrategia de los casos de uso que reformula la pregunta añadiendo tres palabras al final — ¿qué se quiere que haga el sistema para cada usuario?— es sólo un poco diferente, pero obtiene un resultado muy distinto.

9 Para capturar los requisitos que aportan valor añadido
Nos mantiene centrados en la comprensión de cómo el sistema debe dar soporte a cada uno de sus usuarios. Nos guía en la identificación de las funciones que cada usuario necesita. También nos ayuda a abstenernos de sugerir funciones superfinas que ninguno de los usuarios necesita. Además, los casos de uso son intuitivos. Los usuarios y los clientes no tienen que aprender una notación compleja. En su lugar, se puede usar simple castellano (es decir, lenguaje natural) la mayor parte del tiempo, lo que hace más fácil la lectura de los casos de uso y la propuesta de cambios. La captura de los casos de uso implica a los usuarios, a los clientes y a los desarrolladores.

10 Para capturar los requisitos que aportan valor añadido
Los usuarios y los clientes son los expertos en los requisitos. El papel de los desarrolladores es el de facilitar las discusiones y ayudar a los usuarios y a los clientes a comunicar sus necesidades. El modelo de casos de uso se utiliza para conseguir un acuerdo con los usuarios y clientes sobre qué debería hacer el sistema para los usuarios. Podemos pensar en el modelo de casos de uso como en una especificación completa de todas las formas posibles de utilizar el sistema (los casos de uso). Esta especificación puede utilizarse como parte del contrato con el cliente. El modelo de casos de uso nos ayuda a delimitar el sistema definiendo todo lo que debe hacer para sus usuarios. Regresar

11 Para dirigir el proceso
Como hemos dicho, el que un proyecto de desarrollo esté dirigido por los casos de uso significa que progresa a través de una serie de flujos de trabajo que se inician a partir de los casos de uso. Los casos de uso ayudan a los desarrolladores a encontrar las clases. Las clases se recogen de las descripciones de los casos de uso a medida que las leen los desarrolladores, buscando clases que sean adecuadas para la realización de los casos de uso2. Los casos de uso también nos ayudan a desarrollar interfaces de usuario que hacen más fácil a los usuarios el desempeño de sus tareas.

12 Para dirigir el proceso
Más adelante, las realizaciones de los casos de uso se prueban para verificar que las instancias de las clases pueden llevar a cabo los casos de uso. Los casos de uso no sólo inician un proceso de desarrollo sino que lo enlazan, como se muestra en la Figura 3.2. También tenemos que estar seguros de que capturamos los casos de uso correctos de forma que los usuarios obtengan los que realmente quieren. La mejor forma de conseguir esto es, por supuesto, hacer un buen trabajo durante el flujo de los requisitos. Pero con frecuencia no es suficiente. Un sistema en ejecución nos permite una validación adicional de los casos de uso con las necesidades reales del usuario.

13 Para dirigir el proceso
Los casos de uso ayudan a los jefes de proyecto a planificar, asignar y controlar muchas de las tareas que los desarrolladores realizan. Por cada caso de uso, un jefe de proyecto puede identificar unas cuantas tareas. Cada caso de uso a especificar es una tarea, cada caso de uso a diseñar es una tarea, y cada caso de uso a probar es una tarea. El jefe de proyecto puede incluso estimar el esfuerzo y el tiempo necesario para llevar a cabo esas tareas. Las tareas identificadas a partir de los casos de uso ayudan a los jefes a estimar el tamaño del proyecto y los recursos necesarios.

14 Para dirigir el proceso
Entonces esas tareas pueden asignarse a desarrolladores concretos que se hacen responsables de ellas. Un jefe de proyecto podría hacer responsable de la especificación de cinco casos de uso a una persona durante el flujo de requisitos, a otra responsable de diseñar tres casos de uso y a un tercero responsable de especificar los casos de prueba para dos casos de uso.

15 Para dirigir el proceso
Los casos de uso son un importante mecanismo para dar soporte a la trazabilidad a través de todos los modelos. Un caso de uso en el modelo de requisitos es trazable a su realización en el análisis y en el diseño, a todas las clases participantes en su realización, a componentes (indirectamente), y finalmente, a los casos de prueba que lo verifican. Esta trazabilidad es un aspecto importante de la gestión de un proyecto. Cuando se cambia un caso de uso, las realizaciones, clases, componentes y casos de prueba correspondientes tienen que comprobarse para ser actualizadas.

16 Para dirigir el proceso
De igual forma, cuando un componente de fichero(código fuente) se modifica, las clases, casos de uso y casos de prueba correspondientes que se ven afectados también deben comprobarse. La trazabilidad entre los casos de uso y el resto de los elementos del modelo hace más fácil mantener la integridad del sistema y conservar actualizado al sistema en su conjunto cuando tenemos requisitos cambiantes. Regresar

17 Para idear la arquitectura y más...
Los casos de uso nos ayudan a llevar a cabo el desarrollo iterativo. Cada iteración, excepto quizá la primera de todas en un proyecto, se dirige por los casos de uso a través de todos los flujos de trabajo, de los requisitos al diseño y a la prueba, obteniendo un incremento. Cada incremento del desarrollo es por tanto una realización funcional de un conjunto de casos de uso. En otras palabras, en cada iteración se identifican e implementan unos cuantos casos de uso.

18 Para idear la arquitectura y más...

19 Para idear la arquitectura y más...
Los casos de uso también nos ayudan a idear la arquitectura. Mediante la selección del conjunto correcto de casos de uso —los casos de uso significativos arquitectónicamente— para llevarlo a cabo durante las primeras iteraciones, podemos implementar un sistema con una arquitectura estable, que pueda utilizarse en muchos ciclos de desarrollo subsiguientes. (Capítulo 4). Los casos de uso también se utilizan como punto de partida para escribir el manual de usuario. Ya que cada caso de uso describe una forma de utilizar el sistema, son el punto de partida ideal para explicar cómo puede el usuario interactuar con el sistema.

20 Para idear la arquitectura y más...
Mediante la estimación de la frecuencia de uso de los diferentes caminos en los casos de uso, podemos estimar qué caminos necesitan el mejor rendimiento. Esas estimaciones pueden utilizarse para dimensionar la capacidad de proceso del hardware subyacente o para optimizar el diseño de la base de datos para ciertos usos. Pueden utilizarse estimaciones parecidas para conseguir una buena facilidad de uso, seleccionando los caminos más importantes para centrarnos en ellos durante el diseño de la interfaz de usuario. Regresar

21 La captura de casos de uso
Durante el flujo de trabajo de los requisitos identificamos las necesidades de usuarios y clientes como requisitos. Los requisitos funcionales se expresan como casos de uso en un modelo de casos de uso, y los demás requisitos o bien se "adjuntan" a los casos de uso a los que afectan, o bien se guardan en una lista aparte o se describen de alguna otra forma.

22 La captura de casos de uso
El modelo de casos de uso representa los requisitos funcionales El modelo de casos de uso ayuda al cliente, a los usuarios y a los desarrolladores a llegar a un acuerdo sobre cómo utilizar el sistema. La mayoría de los sistemas tienen muchos tipos de usuarios. Cada tipo de usuario se representa mediante un actor. Los actores utilizan el sistema al interactuar con los casos de uso. Todos los actores y casos de uso del sistema forman un modelo de casos de uso.

23 La captura de casos de uso
Un diagrama de casos de uso (Sección 7.4.1) describe parte del modelo de casos de uso y muestra un conjunto de casos de uso y actores con una asociación entre cada par actor/caso de uso que interactúan (véase la Figura 3.3). Regresar

24 Ejemplo, Un modelo de casos de uso para un sistema de cajero automático (CA)
El actor Cliente de Banco utiliza un sistema CA para retirar e ingresar dinero desde y en cuentas, y para transferir dinero entre cuentas. Esto se representa por los tres casos de uso que se muestran en la Figura 3.3, que poseen asociaciones con el actor para indicar su interacción. Regresar

25 La captura de casos de uso
Los actores son el entorno del sistema No todos los actores representan a personas. Pueden ser actores otros sistemas o hardware externo que interactuará con el sistema. Cada actor asume un conjunto coherente de papeles cuando interactúa con el sistema. Un usuario físico puede actuar como uno o varios actores, desempeñando los papeles de esos actores en su interacción con el sistema. Varios usuarios concretos pueden actuar como diferentes ocurrencias del mismo actor. Por ejemplo, puede haber miles de personas que actúan como el actor Cliente de Banco.

26 La captura de casos de uso
Los actores se comunican con el sistema mediante el envío y recepción de mensajes hacia y desde el sistema según éste lleva a cabo los casos de uso. A medida que definimos lo que hacen los actores y lo que hacen los casos de uso, trazaremos una clara separación entre las responsabilidades de los actores y las del sistema. Esta separación nos ayuda a delimitar el alcance del sistema. Podemos encontrar y especificar todos los actores examinando a los usuarios que utilizarán el sistema y a otros sistemas que deben interactuar con él. Cada categoría de usuarios o sistemas que interactúan se representan por tanto como actores.

27 La captura de casos de uso
Los casos de uso especifican el sistema Los casos de uso están diseñados para cumplir los deseos del usuario cuando utiliza el sistema. El modelo de casos de uso captura todos los requisitos funcionales del sistema. Definiremos un caso de uso de manera precisa como sigue: Un caso de uso especifica una secuencia de acciones, incluyendo variantes que el sistema puede llevar a cabo, y que producen un resultado observable de valor para un actor concreto. Identificamos los casos de uso examinando cómo los usuarios necesitan utilizar el sistema para realizar su trabajo.

28 La captura de casos de uso
Cada uno de esos modos de utilizar el sistema que añaden valor al usuario es un caso de uso candidato. Estos candidatos se ampliarán, se cambiarán, se dividirán en casos de uso más pequeños, o se integrarán en casos de uso más completos. El modelo de casos de uso está casi terminado cuando recoge todos los requisitos funcionales correctamente de un modo que puedan comprender los clientes, usuarios y desarrolladores. La secuencia de acciones realizada por un caso de uso durante su operación (es decir, una instancia del caso de uso) es un camino específico a través del caso de uso.

29 La captura de casos de uso
Puede haber muchos caminos, muchos de ellos muy parecidos —son variantes de la ejecución de la secuencia de acciones especificada en el caso de uso. Para hacer que un modelo de casos de uso sea más comprensible, podemos agrupar descripciones de caminos variantes parecidas en un solo caso de uso. Cuando decimos que identificamos y describimos un caso de uso, realmente estamos diciendo que identificamos y describimos los diferentes caminos que es práctico definir como un solo caso de uso. Regresar

30 Ejemplo, El caso de uso sacar dinero
La secuencia de acciones para un camino a través de este caso de uso es (de forma muy simplificada): El Cliente del Banco se identifica. El Cliente del Banco elige de qué cuenta sacar dinero y especifica qué cantidad. El sistema deduce la cantidad de la cuenta y entrega el dinero.

31 La captura de casos de uso
Los casos de uso también se utilizan como "contenedores" de los requisitos no funcionales (Capítulo 6), tales como los requisitos de rendimiento, disponibilidad, exactitud y seguridad que son específicos de un caso de uso. Por ejemplo, puede asociarse al caso de uso Sacar Dinero el siguiente requisito: el tiempo de respuesta para un Cliente de Banco medido desde la selección de la cantidad a sacar hasta la entrega de los recibos debe ser menor de 30 segundos en el 95 por ciento de los casos.

32 La captura de casos de uso
Resumiendo, todos los requisitos funcionales quedan atados mediante casos de uso, y muchos de los requisitos no funcionales pueden asociarse a los casos de uso. De hecho, el modelo de casos de uso es un vehículo para organizar los requisitos de un modo fácil de gestionar. Clientes y usuarios pueden comprenderlo y utilizarlo para comunicar sus necesidades de un modo consistente y no redundante. Los desarrolladores pueden dividir el trabajo de captura de requisitos entre ellos, y después utilizar los resultados (fundamentalmente los casos de uso) como entrada para el análisis, diseño, implementación y prueba del sistema. Regresar