Personas. Tecnología. Producto. Proceso

Transcripción

1 IS, RUP y UML en el Contexto de ADOO Análisis y Diseño OO, Luis Carlos Díaz, Angela Carrillo y Deicy Alvarado

2 Presentación del Curso

3 Ingeniería de Software Personas Tecnología Producto Proceso

4 sobre el producto! Lo que el director desea

5 sobre el producto! Como lo define el líder del proyecto

6 sobre el producto! Como se diseña el sistema

7 sobre el producto! Como lo desarrollan Los programadores

8 sobre el producto! Como es intalado por los operadores

9 sobre el producto! Lo que realmente quería el usuario

10 El ciclo de vida del Software Tiempo Ciclos desde su nacimiento hasta su muerte Nacimiento Muerte

11 Problemas en el desarrollo El dominio de la aplicación no es conocido Falta de comunicación con el usuario Falta de comunicación del grupo de desarrollo Carencia de una buena documentación Falta de planeación Sobrecostos Demoras y cancelación de proyectos Mala calidad d del producto No cumplimiento de las necesidades del Negocio

12 Ejemplo: Los Costos! Cómo solucionar estos problemas y suplir los retos del desarrollo de software? Tarea de la Ingeniería de Software! Apuesta: : Si el proceso es de calidad El producto resultante de ese proceso es de calidad!!!

13 Sobre el Proceso Construcción Desarrollo Mantenimiento del Software Requisitos nuevos o modificados Proceso de Desarrollo de Software Sistema nuevo o modificado

14 Modelos del Ciclo de Vida Diente de Sierra Cascada Espiral Diente Tiburón En V

15 Proceso General Resumen de los principales procesos de desarrollo de software: ADMINISTRACIÓN DEL PROYECTO Inicio, Supervisión, Control, Calidad PRE- DESARROLLO Exploración Asignación del sistema DESARROLLO Requerimientos Análisis Diseño Implementación POS- DESARROLLO Instalación Operación & Soporte Mantenimiento Retiro PROCESOS INTEGRALES PROCESOS INTEGRALES Verificación, Validación, Adm. de configuraciones, Documentación, Entrenamiento

16 Modelo de madurez de los Procesos de Desarrollo de Sw

17 RUP: Rational Unified Process

18 Fases Inception Elaboration Construction Transition Objetivos (Vision) Arquitectura Capacidad Operacional Inicial Release del Producto Tiempo

19 Fases Incepción o Inicio: i visión ió aproximada del producto final con base en las características del negocio Elaboración: Visión refinada, núcleo central, resolución de riesgos altos Construcción: implantación del sistema, implementación de requerimientos de menor riesgo y preparación para el despliegue Transición: Despliegue del producto

20 Fases e Iteraciones Alcance y Objetivos Arquitectura Versión Beta Versión Final Fases: Incepción Elaboración Construcción Transición Iteraciones: Iteración 1 Iteración 2 Iteración 3 Iteración 4 Disciplinas: Modelado del Negocio Requerimientos Análisis y Diseño Implementación Pruebas (Fiabilidad, Funcionalidad, Rendimiento) Entregas internas (Versiones)

21 Las Iteraciones En cada fase Análisis de Requerimientos Diseño Implementación Pruebas Se busca un refinamiento sucesivo del sistema Longitud máxima: 2 a 6 semanas Fijar iteraciones cortas y adaptables

22 Elementos del RUP Workflows (disciplinas primarias, de apoyo) Workers Actividades y Artefactos Artefactos Workers Actividades id d

23 Características Generales Dirigido por Casos de Uso Centrado en la Arquitectura Iterativo e Incremental Otros Desarrollo basado en componentes UML como lenguaje de Modelado Proceso Integrado

24 Ventajas del RUP Mitigación temprana de posibles riesgos altos Progreso visible en las primeras etapas Temprana retroalimentación que se ajuste a las necesidades reales Gestión de la complejidad Conocimiento adquirido en una iteración puede aplicarse de iteración a iteración

25 Buenas prácticas Abordar las cuestiones de alto riesgo y valor en las primeras iteraciones Usuarios involucrados continuamente Verificar continuamente la calidad desde el principio y con frecuencia Aplicar casos de uso Modelar el Software visualmente Gestión cuidadosa de requisitos Control de cambios

26 Modelado Simplificación de la realidad Proporciona los planos del sistema Contexto: Incluye elementos que tienen gran influencia y omite aquellos menores que no son relevantes para el nivel de abstracción dado Mundo Real Mundo Computacional Proceso Representaciones Modelado Situación Software

27 Modelos Ayudan a visualizar cómo es o cómo queremos que sea un sistema. Permiten especificar la estructura o el comportamiento de un sistema Proporcionan plantillas que nos guían en la construcción de un sistema Documentan adoptan las decisiones que se

28 Por qué modelar Software? Dimensión y complejidad Sistema Operativo Windows NT: 40 millones LOC No es hecho por una sola persona Equipos de desarrollo Entendimiento del desarrollo Representaciones simples Medio de manejar la complejidad Máximas: Una empresa de software con éxito es aquella que produce de una manera consistente software de calidad que satisface las necesidades del usuario Un buen software satisface las necesidades cambiantes de sus usuarios yde la empresa [RBJ]

29 Principios del modelado La elección de qué modelos creer tiene una profunda influencia sobre cómo se acomete un problema y cómo se da forma a una solución Todo modelo puede ser expresado a diferentes niveles de precisión Los mejores modelos están ligados a la realidad Un único modelo no es suficiente. Cualquier sistema no trivial se aborda mejor a través de un pequeño conjunto de modelos casi independientes [RJB]

30 UML: Unified Modeling Language Lenguaje de Modelado d Unificado! Booch Jacobson Rumbaugh Taller: Convenciones de modelado de un pequeño Apto. [The Unified Software Development Process. I. Jacobson, G. Booch and J. Rumbaugh. Addison-Wesley, 1999]

31 Breve Historia de UML Érase una vez Método de Booch El método OOSE (Object-OrientedOriented Software Engineering) g) de Jacobson El método OMT (Object Modeling Technique) e) de Rumbaugh

32 Breve Historia de UML Ventajas de cada uno: Método de Booch: : Expresivo en diseño y construcción de proyectos Método OOSE: : soporte para casos de uso y levantamiento t de requerimientos i Método OMT: : análisis y sistemas de información con gran cantidad de datos

33 Breve Historia de UML Al conocerse Cada uno de los métodos evolucionaba independientemente hacia los otros dos Se pretendía estabilizar orientado aobjetos el mercado Extraer y complementarse con lo mejor de cada uno de los métodos

34 Breve Historia de UML Cómo unir? Tener un lenguaje de especificación de requerimientos? Programación visual? Equilibrio simplicidad! entre expresividad y

35 Modelos, Vistas y Sistemas Modelo: Abstracción de un sistema Vista: Aspectos de un modelo Notación: representación de Vistas

36 UML: Diagramas de Casos de Uso Funcionalidad del sistema desde el punto de vista del usuario Sistema

37 UML: Diagramas de Clase Estructura del Sistema

38 UML: Diagramas de Secuencia Comportamiento entre actores y objetos del sistema

39 Bibliografía & Referencias Bernd Bruegge: Ingeniería de Software Orientado a Objetos. Prentice Hall, Jaime Oyarzo Espinosa: Notas de clase Introducción a la Informática. Universidad id d de Alcalá lá Hugo Cendales: Notas de clase ADOO. Universidad Javeriana, Luis Carlos Díaz: Notas de clase ADOO. Universidad Javeriana, Miguel Torres: Notas de clase ADOO. Universidad Javeriana, Otros Aportes: Comentarios y observaciones de docentes del curso: Deicy Alvarado & Angela Carrillo, 2007