1. MODELO DE REQUISITOS Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción

2. Tiene como objetivo delimitar el sistema y capturar la funcionalidad que debe ofrecer desde la perspectiva del usuario. Este modelo puede funcionar como un contrato entre el desarrollador y el cliente o usuario del sistema, y por lo tanto proyecta lo que el cliente desea según la percepción del desarrollador. El propósito del modelo de requisito es comprender completamente el problema y sus implicaciones. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción

6. El modelo de casos de uso describe un sistema en término de sus distintas formas de utilización, cada uno de estas formas es conocida como un caso de uso. Cada caso de uso o flujo se compone de una secuencia de eventos iniciada por el usuario. Para comprender los casos de uso de un sistema primero es necesario saber quienes son sus usuarios. Por ejemplo, conducir un automóvil es distinto a arreglarlo, donde los usuarios también son distintos, el dueño del automóvil y el mecánico, respectivamente. Para ello se define el concepto de actor Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión

7. Los actores son entidades distintas a los usuarios, en el sentido que los usuarios son las personas reales que utilizan el sistema, mientras que los actores representan un cierto papel que una persona real puede jugar. Utilizando terminología orientada a objetos, se considera al actor como una clase de usuario, mientras que los usuarios se consideran como objetos o instancias de esa clase. Los actores modelan cualquier entidad externa que necesite intercambiar información con el sistema. Los actores no están restringidos a ser personas físicas, pudiendo representar otros sistemas externos al actual. Lo esencial es que los actores representen entidades externas al sistema. Además, cada uno de estos actores podrá ejecutar una o más tareas del sistema. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión

8. Para especificar los actores de un sistema, se dibuja un diagrama correspondiente a la delimitación del sistema, la cual representa al sistema como una “caja negra” y a los diferentes actores como entidades externas a ésta, como se muestra en la figura. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión

9. Volviendo a la distinción entre actor y persona, una misma persona puede jugar el papel del actor Usuario cuando hace reservas y además puede trabajar para el sistema de reservaciones, por ejemplo como Operador, correspondiente a otro actor no mostrado en nuestro ejemplo. Delimitación del sistema de reservaciones de vuelo. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión

10. El actor Usuario se considera un actor primario, ya que el sistema se construye pensando en sus usuarios, mientras que Base de Datos de Reservas y Base de Datos de Registro son ambos actores secundarios, ya que si no existieran usuarios no habría necesidad del sistema. Delimitación del sistema de reservaciones de vuelo. Actor Abstracto Actor Concreto Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión

11. Caso de Uso, se define la funcionalidad propia del sistema por medio de los casos de uso. Utilizando terminología orientada a objetos, cada caso de uso define una clase o forma particular de usar el sistema mientras que cada ejecución del caso de uso se puede ver como una instancia del caso de uso, o sea, un objeto, con estado y comportamiento. Cada caso de uso constituye un flujo completo de eventos especificando la interacción que toma lugar entre el actor y el sistema. El actor primario es encargado de dar inicio a esta interacción, mientras que los casos de uso son instanciados como respuesta al evento anterior . Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión

12. En el sistema de reservaciones de vuelos utilizamos los actores ya identificados como punto de partida. Dado que el Usuario es el actor primario se comienza con él. El sistema tiene que poder dar ciertos servicios al usuario, como consultas y reservas. De aquí podemos definir nuestros casos de uso principales, Consultar Información y Hacer Reservación. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión

13. Cuando diferentes actores juegan roles similares ellos pueden heredar de un actor abstracto común, como se muestra mediante el actor abstracto Base de Datos en el ejemplo de la figura siguiente. El resto de los actores se conoce como actores concretos, utilizando terminología similar a aquella de herencia. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión

14. En la descripción del problema se menciona que para poder utilizar el sistema el usuario debe estar registrado , por lo cual agregamos un caso de uso Registrar Usuario . Por otro lado, se debe incluir la Base de Datos de Reservas, y la Base de Datos de Registro ya que son actores secundarios necesarios. Estos tres casos de uso se muestran en la figura. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión

15. La extensión especifica cómo un caso de uso puede insertarse en otro para extender la funcionalidad del anterior. El caso de uso donde se va a insertar la nueva funcionalidad debe ser un flujo completo, por lo cual éste es independiente del caso de uso a ser insertado. De esta manera, el caso de uso inicial no requiere consideraciones adicionales al caso de uso a ser insertado, únicamente especificando su punto de inserción. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión

16. Inclusión. Es una relación adicional entre casos de uso es la inclusión. A diferencia de una extensión, la inclusión se define como una sección de un caso de uso que es parte obligatoria del caso de uso básico. El caso de uso donde se va a insertar la funcionalidad depende del caso de uso a ser insertado. Se etiqueta la relación con “incluye” (“include”). Por ejemplo, en el Sistema de Reservaciones de Vuelos, el caso de uso de Consultar Información incluye el caso de uso Validar Usuario como se muestra en la figura. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión

17. Generalización. Es una relación adicional entre casos de uso es la generalización la cual apoya la reutilización de los casos de uso. Mediante la relación de generalización es necesario describir las partes similares una sola vez en lugar de repetirlas para todos los casos de uso con comportamiento común. Se conoce a los casos de uso que se extraen como casos de uso abstractos, ya que no serán instanciados independientemente Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión

18. Los casos de uso adicionales en este diagrama son la extensión de Registrar Tarjeta y Pagar Reservación. Este último caso de uso es interesante por que extiende Hacer Reservación e incluye Registrar Tarjeta, ambos requisitos para poder comprar un boleto con el sistema. Además de la inclusión anterior, también se incluyen los casos de uso de Validar Usuario y Ofrecer Servicios en los casos de uso básicos: Registrar Usuario, Consultar Información y Hacer Reservación. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión

19. A continuación se presentan los diagramas de casos de uso planteados para cada uno de los subsistemas definidos para la empresa. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión RR.HH Contabilidad Marketing Logística Envíos Almacén Ventas

20. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión RR.HH Contabilidad Marketing Logística Envíos Almacén Ventas

21. Descripción El Jefe de Ventas o el Ingeniero de Logística inicia el caso de uso. El sistema le muestra una pantalla donde puede crear diversas estadísticas sobre conceptos relacionados con la empresa. Por ejemplo, ventas por sección, ventas de los representantes, pedidos realizados a las operadoras, beneficio de la empresa, etc. Una vez creada una estadística puede ser impresa o guardada en el sistema para su consulta posterior. CU-CONTROL DE ESTADISTICA Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión RR.HH Contabilidad Marketing Logística Envíos Almacén Ventas

24. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión RR.HH Contabilidad Marketing Logística Envíos Almacén Ventas

25. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión RR.HH Contabilidad Marketing Logística Envíos Almacén Ventas

26. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión RR.HH Contabilidad Marketing Logística Envíos Almacén Ventas

27. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión RR.HH Contabilidad Marketing Logística Envíos Almacén Ventas

28. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión RR.HH Contabilidad Marketing Logística Envíos Almacén Ventas

29. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión RR.HH Contabilidad Marketing Logística Envíos Almacén Ventas

30. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión RR.HH Contabilidad Marketing Logística Envíos Almacén Ventas

31. Stakeholders: Los representantes de los usuarios y portavoces de las necesidades de la empresa son los stakeholders. En este proyecto solamente se ha tratado con un stakeholder como representante de los usuarios y necesidades de la empresa, sin embargo se han dividido representativamente según los distintos departamentos. La matriz de atributos de los stakeholders es la siguiente: Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión Clase Caso de Usos Características del Software Actores stakeholders

32. Stakeholders: La matriz de trazabilidad de los stakeholders relaciona a éstos con las características de software de tal manera que se puede conocer qué stakeholder propuso qué característica. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión Clase Caso de Usos Características del Software Actores stakeholders

33. Actores: Se define este requerimiento para listar los usuarios potenciales del sistema, en este proyecto se han definido los siguientes actores: Ingeniero de Logística, Jefe de Almacén, Técnico de Almacén, Jefe de Ventas, Representante de Ventas, Contable, Empleado de Marketing, Cliente Online, Operadora, Encargado de Transporte, Jefe de Recursos Humanos y Empleado de Recursos Humanos . La Matriz de Atributos para los actores es la siguiente: Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión Clase Caso de Usos Características del Software Actores stakeholders

34. Actores: La matriz de trazabilidad de los actores relaciona a éstos con los casos de uso de tal manera que se puede conocer qué actor utiliza qué caso de uso. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión Clase Caso de Usos Características del Software Actores stakeholders

35. Características de Software: Las características software son las necesidades de los usuarios propuestas por los stakeholders de la empresa, son los requisitos que debe cumplir el sistema para satisfacer las necesidades de los trabajadores y de la empresa. Las características definidas son las que aparecen en la matriz de atributos, siendo las indicadas como subcaracterísticas las derivadas según una clasificación jerárquicas. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión Clase Caso de Usos Características del Software Actores stakeholders

36. Características de Software: La matriz de trazabilidad de las características de software relaciona a éstas con los casos de uso de tal manera que se puede conocer qué caso de uso deriva de qué característica. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión Clase Caso de Usos Características del Software Actores stakeholders

37. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión Clase Caso de Usos Características del Software Actores stakeholders

38. Casos de Uso: derivados de las características software, son el resultado del análisis de las necesidades de los usuarios, cuyas especificaciones están recogidas en el paquete Especificaciones de Casos de Uso definido en Requisite Pro. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión Clase Caso de Usos Características del Software Actores stakeholders

39. Casos de Uso: derivados de las características software, son el resultado del análisis de las necesidades de los usuarios, cyas especificaciones están recogidas en el paquete Especificaciones de Casos de Uso definido en Requisite Pro. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión Clase Caso de Usos Características del Software Actores stakeholders

40. Casos de Uso: derivados de las características software, son el resultado del análisis de las necesidades de los usuarios, cuyas especificaciones están recogidas en el paquete Especificaciones de Casos de Uso definido en Requisite Pro. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión Clase Caso de Usos Características del Software Actores stakeholders

41. Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión Clase Caso de Usos Características del Software Actores stakeholders

42. Clases: Las clases son requerimientos derivados de los casos de uso como necesidad de representación del modelo de datos. La matriz de atributos de las clases es la siguiente: Prueba Implementación Análisis/Diseño Requisitos Modelado del Negocio Gestión del Proyecto Introducción Glosario Gestión de Requisitos Casos de Usos Visión Clase Caso de Usos Características del Software Actores stakeholders

43. Preguntas Muchas Gracias [---------- Expositor ----------] MSc. Manuel Sánchez Chero [email_address]