INGENIERIA DE SOFTWARE. Ing. Francisco Rodríguez Novoa

Transcripción

1 INGENIERIA DE SOFTWARE Ing. Francisco Rodríguez Novoa

2 Tema 6 Requisitos y Casos de Uso Ing. Francisco Rodríguez

3 Rational Unified Process (RUP) 3

4 Requisitos. Objetivos Llegar a un acuerdo formal con los clientes y usuarios finales sobre lo que el sistema debe hacer. Proporcionar a los miembros del proyecto una idea clara de los Requisitos del sistema. Delimitar las fronteras del sistema. Proporcionar las bases para la planificación del contenido técnico de las iteraciones. Proporcionar las bases para estimar los costos y el tiempo para el desarrollo del sistema. Definir la interfase gráfica del sistema. 4

5 Requisitos. Workflow 5

6 Requisitos. Artefactos 6

7 Qué es un requerimiento? Un requerimiento se define como una condición o capacidad a la que debe ajustarse el sistema que se construye 7

8 Cómo son interpretados los Requisitos? Necesito algo para balancearme bajo un árbol en las tardes de descanso Cómo lo explicó el cliente? 8

9 Cómo son manejados los Requisitos? Cómo lo entendió el lider del proyecto? Cómo fue descrito por el consultor? Cómo fue y diseñado? analizado 9

10 Cómo son manejados los Requisitos? Cómo fue programado? Cómo fue dcumentado? Cómo fue instalado? 10

11 Cómo son manejados los Requisitos? Cómo fue cobrado? Qué soporte se brindó? Qué necesitaba realmente el cliente? 11

12 Dónde identificar Requisitos? Socios Usuarios Requisitos Modelado del Negocio Clientes 12

13 UML Requisitos. Estereotipos Estereotipos más importantes en la etapa de Requisitos. Actor Paquete Caso de Uso 13

14 Requisitos. Actividades 1. Identificar los Requisitos del sistema. 2. Encontrar los actores y casos de uso del sistema. 3. Construir el Modelo de Casos de Uso del Sistema. 4. Estructurar el Modelo de Casos de Uso del Sistema. 5. Priorizar los casos de uso del sistema. 6. Detallar los casos de uso del sistema. 14

15 Requisitos 1. Identificar los Requisitos del sistema 15

16 1. Identificar los Requisitos del sistema 1. Identificar los Requisitos funcionales. Especifica lo que debe hacer el sistema en relación a su entornos (usuarios u otros sistemas) sin tener en cuenta restricciones físicas. Especifican el comportamiento de las entradas y salidas del sistema. Se redactan en lenguaje natural. Se capturan en dos artefactos. Especificación de Requisitos de Sosftware. Modelo de Casos de Uso del Sistemas. 16

17 1. Identificar los Requisitos del sistema 1. Identificar los Requisitos funcionales. Ejemplo: El sistema debe: Actualizar la información de los profesores. Consultar los horarios de los cursos. Registrar reglas de evaluación. Consultar la programación de los exámenes. Cerrar un curso. 17

18 1. Identificar los Requisitos del sistema 2. Identificar los Requisitos no funcionales. Describen los atributos del sistema, entorno o ambiente donde éste se desarrolla. Se capturan en dos artefactos. Especificación de Requisitos de Software. Modelo de Casos de Uso del Sistemas. 18

19 2. Identificar los Requisitos no funcionales Requisitos NO Funcionales. Describen atributos del sistema o del ambiente en donde éste se desarrolla. Se pueden capturar en los casos de uso pero no se necesitan especificar de manera detallada. 19

20 2. Identificar los Requisitos no funcionales Requisitos NO Funcionales. De Facilidad de Uso (Usability) Están incluidos en las siguientes sub-categorías: factores humanos estética consistencia de la interfaz de usuario ayudas en línea agentes y wizards documentación de usuario y material de entrenamiento 20

21 2. Identificar los Requisitos no funcionales Requisitos NO Funcionales. De Fiabilidad (Reliability) Estan incluidos en las siguientes sub-categorías: frecuencia / severidad de los errores capacidad de recuperación capacidad predictiva exactitud tiempo promedio entre fallas (MTBF) 21

22 2. Identificar los Requisitos no funcionales Requisitos NO Funcionales. De Rendimiento (Performance) Estos Requisitos afectan a los funcionales en la medida de parámetros como: velocidad eficiencia disponibilidad exactitud tiempo de respuesta tiempo de uso de recursos 22

23 2. Identificar los Requisitos no funcionales Requisitos NO Funcionales. De Soporte (Supportability) Incluyen la capacidad de: prueba extensión adaptación mantenimiento compatibilidad configuración instalación y localización 23

24 2. Encontrar actores y casos de uso del sistema 1. Identificar los actores del sistema (actors). Un actor del sistema (actor) representa un rol (humano, software o hardware) externo al sistema con el que se establece intercambio directo de información. Ejemplo: Vendedor. Jefe de Almacén. Asistente de Producción. Nombre del Actor 24

25 2. Encontrar actores y casos de uso del sistema Dónde encontrar a los actores del sistema? Trabajadores del negocio (bussiness workers). Por cada trabajador del negocio con actividades a automatizar identificar a un actor del sistema. Dar al actor del sistema el mismo nombre del trabajador del negocio. 25

26 2. Encontrar actores y casos de uso del sistema Dónde encontrar a los actores del sistema? Trabajadores del negocio (bussiness workers). 26

27 2. Encontrar actores y casos de uso del sistema Dónde encontrar a los actores del sistema? Trabajadores del negocio (bussiness workers). 27

28 2. Encontrar actores y casos de uso del sistema Otros elementos que ayudan a encontrar a los actores del sistema. Personas que usan el sistema. Personas que interactuarán con el sistema. Personas que proveen información al sistema. Usuarios que requieren ayuda de parte del sistema para poder desarrollar sus actividades o tareas. Usuarios que se requieren para ejecutar las funciones principales o más obvias del sistema. 28

29 2. Encontrar actores y casos de uso del sistema 2. Crear la lista de los actores del sistema. Nombre del actor. Debe dar idea clara del rol que representa o juega. Debe ser fácil de entender por los miembros del proyecto. Utilizar un sustantivo con letra inicial mayúscula. (UML). Siempre corresponde con el nombre de un trabajador o actor del negocio. Excepciones pueden ser roles de mantenimiento y administración del sistema. Descripción. Describir la función que realiza para el sistema. Tener en cuenta la responsabilidad que tiene. 29

30 2. Encontrar actores y casos de uso del sistema 3. Identificar los casos de uso del sistema (use cases). Un caso de uso del sistema identifica: Es un proceso específico del sistema con identidad propia. Define una secuencia de acciones que el sistema realiza para un actor en particular. Define la interacción con el actor correspondiente. Produce un resultado observable y esperado para el actor correspondiente. Nombre del caso de uso 30

31 2. Encontrar actores y casos de uso del sistema Dónde encontrar casos de uso del sistema? Cuáles son las actividades del negocio objetos de automatización? Cuáles son las tareas que el actor desea que el sistema desarrolle? El actor crea, almacena, cambia, elimina o consulta datos en el sistema? El actor necesita informar al sistema cambios generados en el entorno circundante al sistema? El actor necesita ser informado sobre la ocurrencia de situaciones externas al sistema? 31

32 2. Encontrar actores y casos de uso del sistema 4. Crear la lista de los casos de uso del sistema. Nombre del caso de uso del sistema. Debe dar idea clara de las acciones a realizar. Se concibe desde el punto de vista del actor. Debe ser fácil de entender por los miembros del equipo del proyecto. Debe ser un verbo o una frase verbal en infinitivo. (UML). Descripción. Se indica el objetivo fundamental del proceso. Debe indicar el propósito del caso de uso. 32

33 3. Construir el Modelo de Casos de Uso del Sistema Está formado por: Actores del sistema. Diagrama de Actores del sistema. Casos de uso del sistema. Paquetes. Dependencias entre paquetes. Asociaciones entre actores y casos de uso del sistema. Asociaciones entre casos de uso. Diagramas de Casos de Uso. 33

34 3. Construir el Modelo de Casos de Uso del Sistema 2. Construir el Diagrama de Casos de Uso del sistema El Diagrama de Casos de Uso del sistema es. Herramienta proporcionada por UML. Muestra gráficamente los Requisitos funcionales del sistema. Muestra los procesos que son usados por los roles del sistema. Solo se tiene en cuenta QUIÉN realiza QUÉ proceso? QUIÉN? (actor del sistema identificado). QUÉ? (caso de uso del sistema identificado). Relaciones entre ellos (asociaciones). No constituye un Diagrama de Flujo de Datos. 34

35 4. Estructurar Modelo de Casos de Uso del Sistema 1. Encontrar comportamiento común en varios casos de uso del sistema. Dentro de la ejecución de un caso de uso del sistema pueden encontrarse actividades que se repiten en otros. Considerarlos duplicados o triplicados hace que. Sea más complejo. La arquitectura del sistema se multiplique innecesariamente. Estás repeticiones se modelan a través. Asociaciones entre casos de uso. Asociación de tipo Inclusión (Include). Asociación de tipo Extensión (Extend). Asociación de tipo Generalización. 35

36 4. Estructurar Modelo de Casos de Uso del Sistema 2. Encontrar asociaciones de tipo Inclusión (Include) entre los casos de uso del sistema. Es una relación de dependencia entre dos casos de uso. El caso de uso base depende del caso de uso incluido. Se establece cuando el caso de uso base necesita incluir obligatoriamente la secuencia de acciones descritas por el caso de uso incluido. El caso de uso incluido es de obligatoria ejecución cuando ocurra el evento respectivo dentro del caso de uso base. 36

37 4. Estructurar Modelo de Casos de Uso del Sistema 2. Encontrar asociaciones de tipo Inclusión (Include) entre los casos de uso del sistema. Cuándo utilizar la inclusión? Cuando exista un comportamiento común a varios casos de uso (reuso). Las acciones similares en los casos de uso base se extraen al caso de uso incluido. Cuando existen casos de uso complejos: Se simplifica el caso de uso base extrayendo parte de las acciones al caso de uso incluido. 37

38 4. Estructurar Modelo de Casos de Uso del Sistema 2. Encontrar asociaciones de tipo Inclusión (Include) entre los casos de uso del sistema. La flecha se orienta de manera que indique que el caso de uso base es quien necesita incluir al caso de uso incluido. Se utiliza el estereotipo <<include>> y se coloca encima de la flecha. <<include>> Caso de Uso base Caso de Uso incluido 38

39 Ejemplo de <<include>> Reintegrar cuenta corriente <<include>> Cliente Validar operación <<include>> Reintegrar cuenta crédito 39

40 4. Estructurar Modelo de Casos de Uso del Sistema 3. Encontrar asociaciones de tipo Extensión (Extend) entre los casos de uso del sistema. Es una relación de dependencia entre dos casos de uso. El caso de uso extendido depende del caso de uso base. Se establece cuando el caso de uso extendido ocurre excepcionalmente en el caso de uso base. El caso de uso extendido ocurre solo cuando ocurra el evento respectivo dentro del caso de uso base. 40

41 4. Estructurar Modelo de Casos de Uso del Sistema 3. Encontrar asociaciones de tipo Extensión (Extend) entre los casos de uso del sistema. Al caso de uso base solo le interesa el resultado de la invocación del caso de uso extendido. El caso de uso base es el que conoce la asociación entre ambos. El caso de uso extendido no necesita conocer cuáles casos de uso se extienden a él. 41

42 4. Estructurar Modelo de Casos de Uso del Sistema 3. Encontrar asociaciones de tipo Extensión (Extend) entre los casos de uso del sistema. Cuándo utilizar la extensión? Cuando exista un comportamiento común a varios casos de uso (reuso). Las acciones similares en los casos de uso base se extraen al caso de uso extendido. Cuando existen casos de uso complejos: Se simplifica el caso de uso base extrayendo parte de las acciones al caso de uso extendido. 42

43 4. Estructurar Modelo de Casos de Uso del Sistema 3. Encontrar asociaciones de tipo Extensión (Extend) entre los casos de uso del sistema. La flecha se orienta de manera que indique que el caso de uso extendido constituye la extensión del caso de uso base. Se utiliza el estereotipo <<extended>> y se coloca encima de la flecha. <<extended>> Caso de Uso base Caso de Uso extendido 43

44 Casos de Uso ejemplo 1 <<extends>> Realizar Giro por Internet <<includes>> Realizar Giro Cliente Identificar Usuario 44

45 Casos de Uso ejemplo 2 45

46 4. Estructurar Modelo de Casos de Uso del Sistema 4. Encontrar asociaciones de tipo Generalización (Generalization) entre los casos de uso del sistema. Es una relación de herencia entre casos uso. Los casos de uso hijos heredan la estructura, comportamiento y asociaciones del caso de uso padre. El caso de uso padre es abstracto y solo se crean instancias de los casos de uso hijos. 46

47 4. Estructurar Modelo de Casos de Uso del Sistema 4. Encontrar asociaciones de tipo Generalización (Generalization) entre los casos de uso del sistema. Cuándo utilizar la generalización? Cuando existen dos o más casos de uso que poseen un comportamiento y estructura muy común. Las actividades comunes son llevadas hacia un caso de uso padre o generalizado. Las actividades diferentes y particulares se quedan en los casos de uso hijos. 47

48 4. Estructurar Modelo de Casos de Uso del Sistema 4. Encontrar asociaciones de tipo Generalización (Generalization) entre los casos de uso del sistema. Se utiliza una flecha con saeta transparente. La flecha se orienta de manera que indique que los casos de uso hijos necesitan heredar el comportamiento del caso de uso padre. Caso de Uso hijo 1 Caso de Uso padre Caso de Uso hijo 2 48

49 4. Estructurar Modelo de Casos de Uso del Sistema 5. Encontrar asociaciones de tipo Generalización (Generalization) entre los actores del sistema. Si existen dos o más actores que: Utilizan el sistema de la misma forma. Ocupar el rol de otro actor en un momento determinado. Entonces es posible. Establecer una relación de Generalización entre ellos. Simplificar el modelo de Casos de Uso. El actor hijo hereda el rol representado por el actor padre en la relación. 49

50 Un ejemplo: Sistema Académico El sistema permitirá: A los profesores: Consultar los horarios de sus cursos Consultar la programación de los exámenes Actualizar y ver su información personal Registrar y modificar las notas de los estudiantes a su cargo Cerrar un curso Requisitos funcionales 50

51 Un ejemplo: Sistema Académico A los estudiantes: Consultar los horarios de sus cursos Consultar la programación de los exámenes Actualizar y ver su información personal Consultar notas de un curso Requisitos funcionales 51

52 El actor Profesor y sus Casos de uso Consultar horarios de cursos (from Use Cases) Profesor (f rom Actors) Mantener información del profesor (from Use Cases) Consultar horarios de examenes Registrar notas de un curso (from Use Cases) (from Use Cases) Validar acceso (from Use Cases) 52

53 Relaciones entre actores Usuario Estudiante Profesor 53

54 Casos de uso del Usuario Consultar horarios de cursos Usuario (f rom Actors) Validar acceso Consultar horario de exámenes 54

55 Casos de uso del Estudiante Estudiante (f rom Actors) Mantener información del estudiante Consultar notas de un curso 55

56 Casos de uso del Profesor Mantener información del profesor Profesor (f rom Actors) Registrar notas de un curso Cerrar un curso 56

57 Modelo de Casos de uso del Sistema Académico Consultar horarios de cursos Estudiante (f rom Actors) Consultar notas de un curso Validar acceso Cerrar un curso Mantener información del estudiante Usuario (f rom Actors) Mantener información del profesor Consultar horario de exámenes Profesor (f rom Actors) Registrar notas de un curso 57

58 Construcción de Casos de uso Ejemplo: Sistema de Matricula La universidad quiere automatizar su sistema de matrícula de cursos de verano. Un Empleado inicializa la oferta de cursos ofrecidos para el verano. Un mismo curso tiene varias ofertas (secciones). Durante un cierto período de tiempo, después de que se haya definido la oferta de cursos, los estudiantes pueden utilizar el sistema para añadir o eliminar cursos a matricular. Los alumnos seleccionan 4 cursos obligatorios y 2 cursos electivos. Los profesores pueden utilizar el sistema para obtener las listas de alumnos matriculados en su curso. Los usuarios del sistema de matrícula acceden a él mediante un login y una password que le es asignada. 58

59 Construcción de Casos de uso Ejemplo: Sistema de Matricula Actores : Empleado Estudiante Profesor Casos de uso Ingresar Oferta de cursos Añadir o Eliminar Curso Obtener Listado de Alumnos 59

60 Caso Sistema de Matricula Construcción de Casos de uso Caso de uso : Ingresar oferta de cursos Actor : Empleado Precondición : Empleado ha sido admitido como usuario Poscondición : Se ha registrado la oferta de cursos Flujo Básico Actor 1.El C.U. comienza cuando Empleado Indica Ingresar oferta 2.Ingresa Código de Curso 3. Ingresa Sección, Horario y Aula 4. Repite 2 a 3 por cada curso 5. Indica Guardar Flujos Alternativos Sistema 1. El sistema muestra formulario Ingresar oferta 2.Muestra nombre del curso 3.Verifica aula disponible y horario sin cruce 4. Repite 2 a 3 por cada curso 5. Muestra mensaje de confirmación y el C.U. termina. 60

61 Priorización de Casos de Uso En base a la experiencia... Seleccionar los que influyan profundamente en la arquitectura básica, dando soporte al dominio y a las capas de servicio de alto nivel o Escoger los que presenten el máximo riesgo, funciones urgentes o complejas en las primeras iteraciones. 61

62 Priorización de Casos de Uso... Los que requieran investigación a fondo o nueva tecnología. Aquellos que representen procesos primarios o la línea de negocio. Los que apoyen directamente el aumento de ingresos o la reducción de costos. 62

63 Priorización de Casos de Uso En base a ponderaciones... Se definen valores a los atributos de los Requisitos. Se aplican pesos a los diferentes valores de los atributos. Se calcula el peso total de cada requerimiento. Se priorizan los Requisitos de mayor peso total. 63

64 CRITERIOS DE PRIORIZACION CASOS DE USOS Crear Proveedor Generar Orden de Compra Generar Cotización Generar Solicitud de Cotización Generar Documento por Compra en Efectivo Registrar Importación Seleccionar Cotizaciones Crear Moneda Crear País Modificar Proveedor Modificar Solicitud de Cotización Modificar Cotización Modificar Orden de Compra Eliminar Proveedor Eliminar Solicitud de Cotización Eliminar Cotización Eliminar Orden de Compra Modificar Moneda Modificar País Eliminar Moneda Eliminar País Emitir Reporte de Requerimientos pendientes Emitir Reporte de Situación de Requerimientos Emitir Reporte de Requerimientos por vencer Emitir Reporte de Cotizaciones Emitir Reporte de Orden de Compra por Proveedor Emitir Reporte de Orden de Compra por ítem Casos de usos primarios Casos de usos secundarios Casos de usos opcionales Complejidad Riesgo Precedencia Premura Calificación 64

65 Conclusiones La identificación de los Requisitos funcionales llevará a la proyección de las funciones del sistema. La descripción de los Requisitos no funcionales facilitarán la construcción de la plataforma del sistema. La construcción del Modelo de Casos de Uso del Sistema permitirá la definición de la arquitectura del sistema. 65

66 FIN 66