Proceso Unificado de desarrollo

1. Proceso Unificado de desarrollo

2. Objetivos • Ofrecer una visión general del proceso unificado, sus actividades y herramientas. • Presentar una visión simplificada del Lenguaje Unificado de Modelado (UML). • Aprender la noción de proceso y metodología en la Orientación a Objetos

3. Contenido • Introducción al Proceso Unificado • Los flujos de trabajo fundamentales • Fases del proceso • Organización del proyecto

4. Introducción al Proceso Unificado

5. El proceso Unificado: ¿ Que es ? • Los sistemas son cada día más grandes, existe una tendencia generalizada, esto hace que los procesos iterativos e incrementales sean imprescindibles. • Es necesario un proceso común, un método que integre: • Guía para ordenar las actividades de un equipo. • Dirección de las tareas de cada desarrollador por separado y del equipo como un todo. • Especificación de los artefactos que deben ser desarrollados. • Criterios para el control y la medición de los productos y actividades del proyecto.

6. El proceso Unificado: Características • Está basado en componentes e interfaces bien definidas • Utiliza el Lenguaje Unificado de Modelado (UML) • Aspectos característicos: • Dirigido por casos de uso • Centrado en la arquitectura • Iterativo e incremental

7. El proceso Unificado: Estructura

8. El Proceso Unificado Dirigido por casos de uso • Caso de uso: Fragmento de funcionalidad que proporciona al usuario un resultado importante • Modelo de casos de uso:Funcionalidad total del sistema • ¿Qué debe hacer el sistema … para cada usuario? • Guían todo el proceso de desarrollo • En cada iteración se identifican e implementan unos cuantos casos de uso • Los casos de uso sirven para idear la arquitectura • Se seleccionan los casos de uso más representativos • Se utiliza como partida para escribir el manual de usuario

9. El Proceso Unificado Dirigido por casos de uso • Modelo de análisis a partir de casos de uso • Crece incrementalmente • Se especifican a través de diagramas de clases y de colaboración • Al principio se examinan unos pocos casos de uso y se crean sus realizaciones • Cada clasificador puede participar en varias realizaciones distintas con distintos roles • Clases estereotipadas de análisis (entorno, control y entidad)

10. Cuenta Sacar dinero Interfaz cajero Salida Retirada efectivo Un proceso dirigido por casos de uso Realización de un caso de uso (análisis): Modelo de casos de uso Modelo de análisis Sacar dinero «trace»

11. Cuenta Cliente del banco Cliente del banco Salida Receptor dinero Interfaz cajero Retirada efectivo Transferencia Ingreso Un proceso dirigido por casos de uso Modelo de casos de uso Modelo de análisis Sacar dinero Ingresar dinero Transferencia

12. 2: solicitar retirada :Cuenta 1:Identificación 3: validar y retirar :Cliente del banco 5: entrega dinero 4: autorizar entrega :Salida :Interfaz cajero :Retirada efectivo Un proceso dirigido por casos de uso Diagrama de colaboración para describir una realización:

13. Modelo de casos de uso Modelo de análisis Modelo de diseño Sacar dinero Sacar dinero Sacar dinero «trace» «trace» Un proceso dirigido por casos de uso • Modelo de diseño a partir del modelo de análisis • Se adapta al entorno de implementación • Se define con los mismos diagramas • El modelo de diseño es más “físico” y el modelo de análisis más “conceptual”

14. Cuenta Interfaz cajero Retirada efectivo Salida Un proceso dirigido por casos de uso Modelo de análisis Modelo de diseño «trace» «trace» «trace» «trace» Teclado Cuenta Gestor de Cliente Sensor de salida Retirada de efectivo Clase Persistente Dispositivo de visualización Alimentador de la salida Gestor de Transacciones Gestor de Cuentas Contador de efectivo Lector de tarjetas

15. Lector de tarjetas Gestor de Transacciones Dispositivo de visualización Gestor de Cliente Teclado Clase Persistente Retirada de efectivo Alimentador de la salida Contador de efectivo Gestor de Cuentas Cliente del banco Sensor de salida Cuenta Un proceso dirigido por casos de uso

16. :Lector de tarjetas :Dispositivo de visualización :Teclado :Gestor de Cliente :Contador de efectivo :Gestor de Transacciones Disponib. Saldo(C) Código PIN Cantidad(C) Introducir tarjeta Tarjeta introducida(ID) Validar código PIN Especificar cantidad Solicitar retirada cantidad(C) Especificar código PIN Solicitar PIN Mostrar petición Solicitar cantidad a retirar Mostrar petición :Cliente del banco Un proceso dirigido por casos de uso …

17. «subsystem» Gestión de Cuentas «subsystem» Transacciones «subsystem» Interfaz del CA Clase Persistente Lector de tarjetas Gestor de Transacciones Gestor de Cuentas Dispositivo de visualización Gestor de Cliente Cuenta «subsystem» Efectivo Teclado Retirada de efectivo Contador de efectivo Alimentador de la salida Cliente del banco Sensor de salida IRetirada ITransferen IEntrega Un proceso dirigido por casos de uso • Las clases se agrupan en subsistemas

18. «file» «file» «exe» Salida.cpp Cliente.exe Cliente.cpp Un proceso dirigido por casos de uso • Modelo de implementación a partir del modelo de diseño Modelo de diseño Modelo de implementación Gestor de Cliente «trace» Sensor de salida «compilation» Alimentador de la salida «trace» Contador de efectivo

19. Modelo de casos de uso Modelo de pruebas Sacar dinero «trace» X Sacar dinero Un proceso dirigido por casos de uso • Pruebas • Modelo de pruebas compuesto por: • Casos de prueba • Procedimientos de prueba

20. Describe diferentes vistas del sistema Incluye los aspectos estáticos y dinámicos más significativos Es la forma del software La arquitectura y los casos de uso evolucionan en paralelo Se empieza por la parte que no es específica de los casos de uso Casos de uso • Software del sistema • Capa intermedia • Sistemas heredados • Estándares y políticas • Requisitos no funcionales • Necesidades de distribución Arquitectura Experiencia El Proceso Unificado Centrado en la arquitectura

21. Un proceso centrado en la arquitectura • La arquitectura se desarrolla principalmente en la fase de elaboración • ¿Qué casos de uso tener en cuenta? • Los que representen riesgos más importantes • Los más importantes para el usuario • Funcionalidades significativas • Línea base de la arquitectura • Esqueleto con pocos músculos

22. El Proceso Unificado Iterativo e incremental • Beneficios de un proceso iterativo controlado: • Coste del riesgo a un solo incremento • Reduce el riesgo de no sacar el producto en el calendario previsto • Acelera el ritmo de desarrollo • Se adapta mejor a las necesidades del cliente • Se divide el trabajo en mini-proyectos • Cada mini-proyecto es una iteración que resulta en un incremento • La iteración • Trata un conjunto de casos de uso • Trata los riesgos más importantes • En cada iteración se persiguen unos objetivos concretos

23. Un proceso iterativo e incremental • Iteración genérica: • Planificación • Requisitos • Análisis • Diseño • Implementación • Prueba • Evaluación de la iteración

24. Un proceso iterativo e incremental • Fases del proceso: • Inicio: Objetivos del ciclo de vida • Establecer ámbito del sistema • Reducir peores riesgos • Preparar el análisis del negocio • Elaboración: Arquitectura del ciclo de vida • Obtener línea base de la arquitectura • Capturar mayoría de requisitos • Reducir siguientes riesgos

25. Un proceso iterativo e incremental • Fases del proceso • Construcción: Funcionalidad operativa inicial • Desarrollo del sistema entero • Transición: Versión del producto • Producto preparado para su entrega al usuario • Se enseña a los usuarios a utilizarlo

26. Personas, Proyecto, Producto y Proceso • Personas • Arquitectos, desarrolladores, ingenieros de prueba, personal de gestión, usuarios, clientes • El proceso de desarrollo afecta a las personas (viabilidad, gestión del riesgo, estructura de los equipos, planificación, comprensión, cumplimiento) • Formación, entrenamiento y experiencia • De recurso a trabajador (puestos que asumen las personas) • Cada trabajador tiene un conjunto de responsabilidades y lleva a cabo un conjunto de actividades

27. Personas, Proyecto, Producto y Proceso • Proyecto • Elemento organizativo de gestión • El proyecto construye el producto • Secuencia de cambio. El sistema evoluciona • Serie de iteraciones. Cada iteración implementa un conjunto de casos de uso o atenúa algunos riesgos. Mini-proyecto • Patrón organizativo. Tipos de trabajadores y artefactos a conseguir

28. Personas, Proyecto, Producto y Proceso • Producto • Artefactos que se crean durante la vida del proyecto • Artefactos: Modelos, código, ejecutables, documentación, diagramas UML, bocetos de la interfaz de usuario, prototipos, componentes, planes de prueba • Artefactos de ingeniería y de gestión • Colección de modelos

29. Personas, Proyecto, Producto y Proceso • Proceso • Conjunto de actividades para crear el producto • Es una plantilla para crear proyectos (Instancia del proceso) • Se define en términos de flujos de trabajo (conjunto de actividades) • Se identifican trabajadores y artefactos • Adaptación o especialización del proceso • Se utilizan diagramas de actividad de UML para describir los flujos de trabajo

30. Los flujos de trabajo fundamentales

31. Tópicos • Artefactos • Trabajadores • Flujo de Trabajo

32. Work Flow de Requisitos

33. Introducción • El esfuerzo principal en esta fase (requisitos) es desarrollar un modelo del sistema que se va a construir utilizando casos de uso y los límites bajo los cuales opera. • Los casos de uso son un medio intuitivo. • Énfasis en el valor añadido que proporciona al usuario. • Descripción en tres pasos: • Artefactos a desarrollar, • Trabajadores que participan y • El flujo de trabajo.

34. Artefacto • Pieza de información utilizada o producida por un proceso de desarrollo de software • Artefactos implicados durante la captura de requisitos • Modelo de Casos de Uso • Actor • Glosario • Caso de Uso • Prototipo de Interfaz de Usuario • Descripción de la Arquitectura

35. Casos de Uso ¿Qué es un caso de uso? • Un caso de uso es una secuencia de interacciones entre uno o varios actores y el sistema que tiene lugar bajo ciertas circunstancias y que: • Es iniciada por un actor. • Se puede describir como una secuencia de actividades. • Produce un resultado de valor observable para algún actor.

36. Casos de uso • Se capturan requisitos de usuario a través de casos de uso • Son fundamentales para: • Identificar y especificar clases, subsistemas e interfaces • Identificar y especificar casos de prueba • Planificar las iteraciones e integración del sistema • Nos guían a través de los flujos de trabajo • En cada iteración se identifican e implementan unos cuantos casos de uso • Los casos de uso sirven para idear la arquitectura • Se seleccionan los casos de uso más representativos • Se utiliza como partida para escribir el manual de usuario

37. Work Flow de Requisitos Encontrar Actores y Casos de Uso Estructurar el Modelo de Casos de Uso Analista de Sistemas Priorizar los Casos de Uso Arquitecto Detallar los Casos de Uso Especificador CU Diseñador de Interfaz de usuario Prototipar la Interfaz de Usuario

38. Actividad: Encontrar actores y casos de uso • Lista de características • Se utiliza sólo para planificación • Estructura de las características: • Nombre y breve descripción • Estado (propuesto, aprobado, incluido,…) • Coste estimado implementación • Prioridad • Nivel de riesgo (crítico, significativo, …)

39. Actividad: Detallar un caso de uso • Alternativas: • Precondición + Camino básico + Caminos alternativos + Poscondición • Diagramas de estado • Diagramas de actividades • Diagramas de interacción

40. Actividad: Estructurar los casos de uso • Identificar descripciones de funcionalidad compartida (herencia) • Casos de uso reales • Casos de uso abstractos • Identificar descripciones de funcionalidad adicional y opcional (extensión) • Otras relaciones (inclusión)

41. Ejemplo “Cuando el cliente inserta su tarjeta en el cajero, la pantalla del cajero le pide que seleccione un idioma. El cliente realiza su selección. El cajero pregunta entonces al cliente cuál es su número de identificación personal ... ... el cliente recoge su dinero de la ranura del dispensador y saca su tarjeta de la ranura de tarjetas”.

42. ¿Por qué utilizar casos de uso? • Un caso de uso ayuda a contestar las siguientes preguntas: • ¿Quién hace qué? • ¿Cuándo lo hace? • ¿Qué actividades se realizan? • ¿Qué elementos del sistema se utilizan?

43. Caso Práctico: Documento de Requisitos Requisitos, Antecedentes, Objetivos y Alcance Los requisitos iniciales se han obtenido directamente del cliente y usuario final. Se desea desarrollar una aplicación para dar soporte a la matriculación de los alumnos de una universidad. La aplicación debe dar soporte a las siguientes funcionalidades: - Un alumno puede matricularse de curso completo o de asignaturas sueltas. - Cada alumno se matricula para una asignatura en concreto en un grupo en concreto, durante un periodo académico concreto. - Un profesor imparte una asignatura en un grupo - La aplicación debe incorporar la gestión de profesores, es decir, añadir un nuevo profesor, borrarlo o modificar sus datos. - La aplicación debe permitir al administrador inscribir alumnos en la universidad. - Entendemos por inscripción crear su expediente, es decir, un alumno puede tener expediente pero no estar matriculado. - Si el alumno se matricula de curso completo elegirá grupo y cursará todas las asignaturas en ese mismo grupo. - También debe ser posible modificar el expediente de un alumno y en casos especiales borrarlo. - Todas las operaciones de borrado se realizan únicamente a nivel lógico. - La aplicación debe permitir al administrador crear nuevos grupos y también borrarlos. - La aplicación también debe dar soporte a la gestión de asignaturas, es decir, añadir, borrar y modificar. - El administrador también debe poder asignar un profesor a un grupo para una asignatura concreta. - La aplicación funcionará en pc’s con windows 95 y pocos recursos. - La aplicación debe funcionar con un esquema cliente servidor, central. - El sistema desarrollado debe ser lo más estándard posible. - Los alumnos se validarán para usar el sistema introduciendo su login y password en formulario.

44. Caso Práctico: Casos de Uso (Vista Parcial)

45. Caso Práctico: Descripción de un Caso de Uso Descripción de Casos de Uso Número: 001 Nombre de Caso de Uso: “Matricular Asignaturas Sueltas” Actor(es): Alumno Descripción Proceso que sigue un alumno a la hora de matricular una o varias asignaturas sueltas. Flujo de Eventos - Entrada en el sistema - Selección de las asignaturas que desea - Realizar matrícula Requerimientos Especiales: El actor no puede ser un alumno de nuevo ingreso. Pre-Condiciones: Haber realizado un login exitoso en la aplicación.

46. Caso Práctico: Descripción de un Caso de Uso Descripción de Casos de Uso Número: 002 Nombre de Caso de Uso: “Logín” Actor(es): Alumno Descripción Proceso que sigue un alumno para entrar en el sistema. Flujo de Eventos - Introducir el nombre de usuario - Introducir la password - Realizar Login Requerimientos Especiales: El actor no puede ser un alumno de nuevo ingreso. Pre-Condiciones: N/A.

47. Caso Práctico: Prototipo de la Interfaz de Usuario • Caso de Uso Hacer Matrícula

48. Caso Práctico: Prototipo de la Interfaz de Usuario • Actividad: Login

49. Work Flow de Análisis

50. Objetivos de Análisis • Ofrecer una especificación más precisa de los requisitos que la que tenemos como resultado de los requisitos. • Estructurar los requisitos de un modo que facilita su compresión, su preparación, su modificación y en general su mantenimiento. • Considerar una primera aproximación al Diseño.