Diapositivas de la sesión 04: taller sobre la construcción de soluciones basadas en desarrollo de modelos

1. 10/09/2009 Universidad del Cauca Departamento de Telemática PROCESO UNIFICADO (UP) Ambientes de Desarrollo

3. Contienen modelos y reflejan perspectivas particulares de la realidad basándose en un conjunto de paradigmas filosóficos.

5. Los usuarios de las metodologías las interpretan según su punto de vista

7. Recolección y refinamiento de requisitos Producto Diseño rápido Refinamiento del prototipo Construcción del prototipo Evaluación del prototipo por el cliente Modelos y estilos 2/4

8. Req Req Req Ana Ana Ana Dis Dis Dis Cod Cod Cod Pru Pru Pru Modelos y estilos 3/4

9. PROGRESO A TRAVÉS DETERMINAR OBJETIVOS, ALTERNATIVAS Y RESTRICCIONES DE LAS ITERACIONES EVALUAR ALTERNATIVAS, IDENTIFICAR Y RESOLVER RIESGOS Análisis de riesgos Análisis de riesgos Análisis de riesgos Prototipo operativo Prototipo 3 An. Riesgo. Proto- tipo 1 Prototipo 2 - REVISIÓN Plan de requerimientos Plan de ciclo de vida Simulaciones, modelos, pruebas comparativas . Concepto de operación Requerimientos de software Diseño del producto Diseño detallado Plan de desarrollo Validación de requerimientos Codificar Plan de integración y prueba Diseño de validación y verificación Prueba de unidad PLANIFICAR SIGUIENTE FASE Prueba de integración Prueba de aceptación - Explotación DESARROLLAR, VERIFICAR PRODUCTO DE SIGUIENTE NIVEL Modelos y estilos 4/4

10. RUP Proceso Unificado de Rational Proceso de Desarrollo de Software soportado en el Lenguaje Unificado de Modelado, y que es iterativo, centrado en la arquitectura y dirigido por casos de uso

11. Orígenes Método Ericsson Método de Rational Proceso Objectory UML Otras Fuentes Proceso Objectory de Rational Proceso Unificado de Rational

13. Administración de Requerimientos,

14. Uso de Arquitecturas Basadas en Componentes,

15. Modelado Visual del Software,

16. Verificación de la Calidad del Software,

18. Desarrollo iterativode aplicaciones Dada la complejidad de las aplicaciones y programas actuales, es posible hacer de manera secuencial la definición completa del problema, diseñar la solución completa, construir la aplicación y por probarla. El descubrimiento de faltas de conformidad con los requisitos en fases posteriores de diseño dan como resultado un aumento en los costos y/ó la cancelación del proyecto. El tiempo y dinero gastados en la implementación de un diseño fallido, son no recuperables.

19. Requisitos Análisis y Diseño Implementación Evaluación Pruebas Desarrollo Iterativo Cada iteraciónproduce un producto ejecutable

20. Características deldesarrollo iterativo Permite un entendimiento incremental del problema a través de refinamientos sucesivos. Posibilita una fácil interacción y retroalimentación de usuario. Metas específicas permiten que el equipo de desarrollo mantenga su atención en producir resultados. El progreso es medido conforme avanzan las implementaciones.

21. Administración de Requisitos Elicitar, organizar, y documentar la funcionalidad y restricciones requeridas. Llevar un registro y documentación de cambios y decisiones. Los requerimientos de negocio son fácilmente capturados y comunicados a través de casos de uso. Los casos de uso son instrumentos importantes de planeación.

22. Arquitectura basadaen componentes Se enfoca en el rápido desarrollo de una arquitectura ejecutable robusta, con las siguientes características: resistente al cambio mediante el uso de interfaces bien definidas, intuitivamente comprensible, promueve un reuso más efectivo de código, es derivada a partir de los casos de uso más importantes.

23. Modelación visualde aplicaciones Captura la estructura y comportamiento de arquitecturas y componentes. Muestra cómo encajan de forma conjunta los elementos del sistema. Mantiene la consistencia entre un diseño y su implementación. Promueve una comunicación no ambigua entre participantes.

24. Verificación de la calidadde las aplicaciones Crea pruebas para cada escenario para asegurar que todos los requisitos están propiamente implementados. Verifica la calidad de la aplicación con respecto a los requisitos basados en la confiabilidad, funcionalidad, desempeño de la aplicación y del sistema. Prueba cada iteración Los problemas de las aplicaciones son de 200 a 500 veces más costosos de encontrar y reparar después del desarrollo.

25. Control de cambiosde las aplicaciones Controlar, llevar un registro, y monitorear cambios para permitir un desarrollo iterativo. Establece espacios de trabajo seguros para cada desarrollador Provee aislamiento de cambios hechos en otros espacios de trabajo Controla todos los artefactos de software – modelos, código, documentos, etc…

26. Características Dirigido por Casos de Uso Centrado en Arquitectura Iterativo e incremental

30. Incluye los aspectos estáticos y dinámicos más significativos

31. Plataforma en la que va a operar

32. Reutilización, sistemas heredados

34. Relación Casos de Uso y Arquitectura La función Casos de Uso La forma Arquitectura

35. Registrarse al servicio Ver Video Visitante Buscar Videos Gestionar Videos Suscriptor Administrador Modificar Información Gestionar Suscriptores Ejemplo de Caso de Uso (SVV)

36. Java applet JMF java.net Browser HTML Pages HTTP Java Server Pages JServer J2EE Apache Web Server Oracle8i Videos Business objects Java Beans Ejemplo de Arquitectura (SVV)

38. Cada mini-proyecto es una iteración

39. Las iteraciones deben estar controladas

41. RUP - terminología 2/3 Rol: Definición del comportamiento y responsabilidades de los participantes Actividad: Unidad de trabajo que puede ejecutar un individuo en un rol específico Artefacto: Pieza de información producida, modificada y utilizada en un proceso

42. RUP - terminología 3/3 Flujo de Trabajo: Forma de describir significativamente la secuencias de actividades que producen resultados y las interacciones entre cargos Hito: Punto en el tiempo en donde se evalúan objetivos logrados y se pueden tomar decisiones críticas

43. Organización por Componentes Flujos de trabajo yactividades Artefactos Trabajadores Agrupan las actividades de acuerdo a su naturaleza Representan la estructura del Proceso. Expresados en términos de:

44. Diseño de Casos de uso Caso de Uso Paquete deCaso de Uso Idea del proceso Trabajador ¿Quién? Actividad ¿Cómo? Describe una unidad de trabajo que puede ser asignada a un trabajador. Rol que puede ser desempeñado por un individuo o conjunto de individuos en la organización de desarrollo Diseñador Artefacto ¿Qué? responsable de Pieza de información que es producida, modificada, ó utilizada por un proceso

45. 10/09/2009 Organización por Organización en el tiempo Componentes FASES COMPONENTES DEL PROCESO Modelado de la Organización Captura de Requisitos Gestación Preparación Construcción Transición Análisis Diseño Implementación Pruebas Puesta en Servicio COMPONENTES DE SOPORTE Gestión de Configuración y Cambios Gestión del Proyecto Entorno Prep.#1 Prep. #2 Const. #1 Const. #2 Const. #N Trans. #1 Trans. #2 Inicial Iteraciones Flujos de Trabajo 1/2

46. 10/09/2009 Satisfacción Del Cliente Alcances yObjetivos Versión Beta Arquitectura Inicio Elaboración Construcción Transición Fases: Iteración Iteración Iteración Iteración Iteraciones: Requerimientos Análisis y Diseño EntregasInternas Codificación Disciplinas: Prueba Admin. Proyecto Gestión Configuracióny Cambio Flujos de Trabajo 2/2

47. 10/09/2009 Trabajadores

48. 10/09/2009 Requisitos Requisitos Análisis Análisis Diseño Diseño Relación Temporal Implementación Implementación Pruebas Pruebas Trabajadores y flujos de trabajo 1/2 Estructurar el Modelo de Casos de Uso Planear prueba Diseñar prueba Evaluar prueba Encontrar actores y casos de uso Detallar un caso de uso Integrar sistema Construir prototipo de Interfaz de usuario Realizar pruebas de integración Priorizar casos de uso Implementación de la arquitectura Analizar la arquitectura Realizar pruebas de sistema Diseño de la arquitectura Analizar un caso de uso Diseñar un caso de uso actividades Analizar una clase Implementar una clase Implementar pruebas Diseñar una clase Diseñar un subsistema Analizar un paquete Implementar un subsistema Realizar pruebas de unidad

49. 10/09/2009 Estructurar el Modelo de Casos de Uso Planear prueba Diseñar prueba Evaluar prueba Encontrar actores y casos de uso Analista Especificador Diseñador Arquitecto Casos de Uso Componentes Pruebas Integrador Integración Sistema Detallar un caso de uso Integrar sistema Construir prototipo de Interfaz de usuario Realizar pruebas de integración Priorizar casos de uso Implementación de la arquitectura Analizar la arquitectura Realizar pruebas de sistema Diseño de la arquitectura Analizar un caso de uso Diseñar un caso de uso Requisitos Análisis Analizar una clase Implementar una clase Implementar pruebas Diseñar una clase Diseñar un subsistema Diseño Relación Temporal Implementación Analizar un paquete Implementar un subsistema Realizar pruebas de unidad actividades Pruebas Trabajadores y flujos de trabajo 2/2

50. 10/09/2009 Aplicación del RUP Herramientas Proceso Producto Proyecto Personas

52. Modelado Visual,

53. Herramientas de Programación,

54. Aseguramiento de la Calidad,

56. ¿Preguntas?¿Observaciones?