Ingeniería de software II - Parte 2

  • 5,606 views
Uploaded on

Material Académico de Ingeniería de Software - Universidad de Medellín (Colombia)

Material Académico de Ingeniería de Software - Universidad de Medellín (Colombia)

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
5,606
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
1
Likes
10

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. PARTE 1.1Metodologías de Desarrollo Proceso de Desarrollo Unificado (UP) Material Académico preparado por: Ph.D, Marta Silvia Tabares B. Fecha última actualización: 4-Sep-2011
  • 2. Ingeniería de Software II(mapa conceptual de tópicos de conocimiento) Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 3. Bibliografía• Roger Pressman. Ingeniería del Software (6ª ED.). Mcgraw-hill / Interamericana.• Alan Dennis, Barbara Haley Wixom and David Tegarden. Systems Analysis and Design with UML Version 2.0 - An Object Oriented Approach, Second Edition. John Wiley & Sons © 2005.• Ivar Jacobson, Grady Booch, James Rumbaugh. El Proceso Unificado de Desarrollo de Software. Adisson Wesley. 2001.• Arlow, J., and Neustad, I. UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design (2nd Edition). Addison-Wesley Object Technology Series. 2005.• OMG-UML. Unified Modeling Language: Superstructure. version 2.0, formal/05-07- 04. 2005.• Simon Bennett, Stee McRobb, y Ray Farmer. Análisis y Diseño Orientado a Objetos del Sistema, Usando UML. McGraw-Hill, 2006.• Atención: algunas fuentes de imágenes y otros es colocada anexo a la imagen. Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 4. Proceso de Desarrollo Unificado Marco de trabajo (framework) genérico cuyo proceso de desarrollo puede especializarse para una gran variedad de sistemas de software, diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaños de proyectos Fuente: Jacobson, I.; Booch, G.; Rumbaugh, J.; (2001).“El Proceso de Desarrollo Unificado de Desarrollo de Software. Adisson Wesley.
  • 5. Proceso Unificado + OpenUP Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 6. Modelo base del Proceso Unificado MODELO ESPIRAL [Boehm, 1988] Costo Acumulado 1. Determinar Objetivos, Progreso restricciones y a través de pasos 2. Análisis y prevención alternativas R del riesgo Evaluación de Riesgo Definición Costo Acumulado Prototipos Compromiso,R R partición Simulación, modelos, benchmarks Planeación Desarrollo, próxima verificación fase producto 4. Planificación siguiente nivel 3. Desarrollo del y dirección R producto R = Revisión Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 7. Modelo Espiral Win-Windel proceso de desarrollo de software [Boehm, 1989] 2. Identifique Las condiciones de triunfo de los grupos de participantes 3. Reconcilie 1. Identifique condiciones de triunfo. los grupos de participantes Establezca objetivos, restricciones del siguiente nivel y alternativas del siguiente nivel 7. Revisión y Compromiso 4. Evalúe alternativas de producto y proceso. 6. Valide definiciones Resuelva riesgos. de producto y proceso 5. Defina siguiente nivel de producto y proceso – incluyendo particiones Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 8. Los 4 ejes del desarrollo de Software • Los principales autores de un proyecto de software son ingenieros de requisitos, los arquitectos, desarrolladores, ingenieros de prueba, además de otros stakeholders tales como clientes, usuarios, proveedores, entre otros.Personas • Es el elemento que permite organizar y gestionar la ejecución del desarrollo del software. Se organiza a partir de un EDT como la Estructura de Desglose del plan de Trabajo. EDT un agrupamiento de los elementos de unProyecto proyecto orientado hacia los entregables, cuyo objetivo es organizar y definir el alcance total del proyecto. • Los productos son artefactos que se crean durante la vida del proyecto. Son entregables tales como modelos, código fuente, ejecutables, y documentación. • El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida e un sistema. Cada cicloProducto consta de sus cuatro fases : inicio, elaboración, construcción y transición. • Cada ciclo concluye con una VERSIÓN del producto para los clientes. Cada fase se subdivide a su vez en iteraciones. • El proceso de ingeniería de software es un conjunto completo de actividades necesarias para transformar los requisitos de usuario en un producto software. Un proceso es una plantilla para crear proyectos.Proceso Estos 4 ejes del desarrollo del software están soportados por Herramientas de Software tales como CASE, IDE, Frameworks para automatizar las actividades definidas en el proceso. Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 9. El Proceso de Desarrollo Unificado* (1) • Es un Proceso de Desarrollo, es decir es un conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software. • Es un Marco de Trabajo genérico que puede especializarse para una gran variedad de sistemas de software. • Está basado en Componentes, es decir que el sistema software en construcción está formado por componentes de software interconectados a través de interfaces bien definidas. • Utiliza el Lenguaje Unificado de Modelado (UML) para preparar todos los esquemas de un sistema de software. • Dirigido por Casos de Uso, Centrado en la Arquitectura, Iterativo e Incremental.* Unified Process – en inglés.* Rational Unified Process (RUP)– Producto Comercial de la IBM. Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 10. El Proceso de Desarrollo Unificado (2)1. Dirigido por REQUISITOS y RIESGOS – Significa que los Casos de Uso son la herramienta de modelado primaria para definir el comportamiento del sistema. Ellos son una forma de capturar los requisitos. • Los casos de uso son usados para identificar y comunicar los requisitos del sistema a los desarrolladores y cómo se debe escribir el sistema. Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 11. El Proceso de Desarrollo Unificado (3)2. Centrado en la ARQUITECTURA • Significa que la arquitectura de software subyacente a la especificación del sistema de desarrollo conduce la especificación, la construcción, y la documentación del sistema. • La arquitectura surge de las necesidades de la empresa, como las perciben los usuarios y los patrocinadores del proyecto. Además, se ve influenciada por factores tales como la plataforma en la que tiene que funcionar el software (arquitectura hardware, sistema operativo, sistema de gestión de base de datos, protocolos para las comunicaciones en red, etc.). Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 12. El Proceso de Desarrollo Unificado (4) Centrado en la Arquitectura• El análisis de sistemas orientado por objeto moderno y los acercamientos de diseño deben apoyarse al menos en tres vistas arquitectónicas (separadas pero interrelacionadas) de un sistema: funcional, estática, y dinámica. • Vista Funcional: describe el comportamiento externo de el sistema desde la perspectiva del usuario. • Los casos de uso y sus diagramas son la primera aproximación usada para representar la vista funcional. En algunos casos también son usados como complemento a los casos de uso. • Vista Estática: describe la estructura del sistema en términos de atributos, métodos, clases, y relaciones. • Los diagramas estructurales retratan la vista estática de un sistema de información orientado por objeto que evoluciona. • Vista Dinámica: describe el comportamiento interno del sistema en términos de mensajes pasados entre los objetos, y cambios de estado dentro de un objeto. • Los diagramas de comportamiento representan la vista dinámica. Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 13. El Proceso de Desarrollo Unificado (5) Centrado en la Arquitectura• Las arquitecturas del sistema son usadas por diversos conjuntos de personas en tiempos diferentes en el ciclo de desarrollo, por esta razón es frecuente ver que estas arquitecturas son separadas en vistas diferentes.• El Proceso Unificado Racional (RUP) identifica un conjunto de vistas estándar llamado 4+1 Vistas de Arquitectura.• Este enfoque permite que todos los grupos de participantes comuniquen las necesidades (es decir, requisitos), resuelvan los conflictos, y realicen los documentos de decisiones. Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 14. El Proceso de Desarrollo Unificado (6) Centrado en la Arquitectura: 4+1 Views (Philippe Kruchten) Logical View Implementation ViewEnd-users/Analysts/Designers ProgrammersFunctionality Configuration management Use Case View Process View Deployment ViewSystem integrators System engineeringPerformance System topologyScalability Delivery, Installation,Throughput Communication Conceptual Physical Figura tomada de: Clements, et al, Documenting Software Architectures Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 15. El Proceso de Desarrollo Unificado (7) Centrado en la Arquitectura: 4+1 Views• El +1 se refiere a la Vista de Casos de Uso, la cual contiene los casos de uso clave (base) que dirigen la arquitectura. Las otras cuatro vistas son:• Vista Lógica: describe la estructura del software y es usada para identificar los paquetes más importantes del diseño, clases, y otros elementos.• Vista de Procesos: orienta los aspectos actuales del sistema en tiempo de ejecución: tareas, hilos, procesos y sus interacciones.•• Vista de Desarrollo: muestra cómo los diferentes ejecutables y otros componentes en tiempo de ejecución son mapeados en plataformas subyacentes o nodos de cómputo.•• Vista de Implementación: proporciona la organización estática del software en términos de empaquetamiento, capas (layering), y dirección de configuración. Atención: Profundizar en este tema en presentación: Arquitectura 4 mas una vista Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 16. El Proceso de Desarrollo Unificado (8)3. ITERATIVO E INCREMENTAL – El desarrollo iterativo e incremental que se somete a pruebas continuas y refinamiento en todas partes de la vida del proyecto. Cada iteración del sistema lo trae más cerca y más cerca a verdaderas necesidades de usuario. – Cuando se desarrolla un producto de software es práctico dividir el trabajo en partes más pequeñas o mini-proyectos. – Cada mini-proyecto es una ITERACIÓN que resulta en un incremento. – Cada Iteración genera una línea base que compromete una versión parcial completa del sistema final incluyendo cualquier documentación asociada al proyecto. – La diferencia entre dos líneas base consecutivas se conoce como un incremento. Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 17. El Proceso de Desarrollo Unificado (9) Iterativo e Incremental• Las iteraciones hacen referencia a pasos en el flujo de trabajo, y los incrementos, al crecimiento del producto.• Las iteraciones deben estar controladas. Esto significa que deben seleccionarse y ejecutarse de una forma planificada, por esto se consideran mini-proyectos.• La iteración trata un grupo de casos de uso que juntos amplían la utilidad del producto desarrollado hasta un momento determinado del ciclo de vida.• Las iteraciones sucesivas se construyen sobre los artefactos de desarrollo tal y como quedaron al final de la última iteración.• Una iteración comienza con los casos de uso y continúan a través del trabajo de desarrollo subsiguiente: análisis, diseño, implementación, pruebas e implementación (de los casos de uso de dicha iteración).• Un INCREMENTO es la diferencia entre la versión interna de una iteración y la versión interna de la siguiente. Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 18. El Proceso de Desarrollo Unificado (10) Iterativo e Incremental ImplemenRequisitos Análisis Diseño Pruebas tación Una ITERACIÓNCADA ITERACIÓN CONSTITUYE UNA PASADA A TRAVÉS DE LOS CINCO FLUJOS DE TRABAJO (DISCIPLINAS) FUNDAMENTALES Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 19. El Proceso de Desarrollo Unificado (11) Interacción y Flujos de trabajo (workflows)• Cinco (5) flujos de trabajo especifican qué necesita ser hecho y qué habilidades son necesarias en cada iteración.• Flujos de Trabajo: – Requisitos: se captura lo que el sistema debe hacer. – Análisis: se refinan y estructuran los requisitos. – Diseño: se realizan los requisitos en la arquitectura del sistema. – Implementación: se construye el software. – Prueba: se verifica que los trabajos de implementación estén acorde a los requisitos. Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 20. El Proceso de Desarrollo Unificado (12) Detalle del Proceso Iterativo e Incremental Figura tomada de: Building J2EE Applications with the Rational Unified Process. Addison-Wesley. 2003 Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 21. El Proceso de Desarrollo Unificado (13) Roles Usuarios Arquitecto Ingenieros de Pruebas SISTEMA Jefe de Proyecto Diseñadores Analistas Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 22. Fases del Proceso Unificado INICIO• Inicio (Inception): objetivos del ciclo de vida – Descripción del producto final y se presenta el análisis de negocio para el producto. • Objetivos: – Establecer la factibilidad del proyecto. – Crear un caso de negocio para demostrar que el proyecto traerá beneficios económicos. – Capturar los requisitos esenciales para ayudar a alcanzar el sistema. – Identificar riesgos críticos. • Roles: – Jefe del Proyecto – Arquitecto del Sistema • Flujos de Trabajo: – Requisitos – Análisis – Diseño e Implementación son actividades soportadas por los prototipos. Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 23. Fases del Proceso Unificado ELABORACIÓN• Elaboración (Elaboration): arquitectura del ciclo de vida. • Se especifican la mayoría de los casos de uso del producto y se diseña la arquitectura del sistema. • Objetivos: • Crear una línea base arquitectónica ejecutable. • Refinar la evaluación del riesgo • Definir los atributos de calidad • Especificar los casos de uso para el 80% de los requisitos funcionales. • Crear un plan detallado para la fase de construcción. • Roles: • Analista • Diseñador • Arquitecto • Flujos de Trabajo: • Requisitos: refina el alcance del sistema y los requisitos. • Análisis: establecer qué se va a construir • Diseño: crear una arquitectura estable. • Implementación: construir la arquitectura base. • Prueba: Probar la línea base arquitectónica. Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 24. Fases del Proceso Unificado CONSTRUCCIÓN• Construcción (Construction): Capacidad Operativa Inicial. • Se completan todos los requisitos, análisis, y diseño; además evoluciona la línea base arquitectónica generada en la Elaboración del sistema final. • Objetivos: Mantener la integridad de la arquitectura del sistema. Refinar la evaluación del riesgo Desarrollar los productos a ser liberados Hacer la integración de subsistemas Realizar pruebas de unidad Realizar pruebas de integración. • Roles: • Diseñador • Ingenieros de Prueba • Arquitecto • Flujos de Trabajo: • Requisitos: descubre requisitos perdidos. • Análisis: termina el modelo de análisis. • Diseño: termina el modelo de diseño. • Implementación: construye la capacidad operativa inicial. • Prueba: pruebas la capacidad operativa inicial. Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 25. Fases del Proceso Unificado TRANSICIÓN• Transition (Transición): Liberación del Producto. • Inicia cuando la prueba Beta se completa y el sistema finalmente se desarrolla. Corrige errores encontrados en las pruebas Beta y prepara la versión de producto de salida en el lugar de los usuarios. • Objetivos: Corregir errores. Preparar los equipos y lugares de usuarios donde operará el nuevo sistema. Modificar el software si aparecen problemas inesperados. Crear manuales de usuarios y documentación necesaria para entregar el producto. Proporcionar consultoría a los usuarios Orientar una revisión de puesta en marcha del proyecto. • Roles: • Ingenieros de Prueba • Arquitecto • Flujos de Trabajo: • Requisitos: no aplica. • Análisis: no aplica. • Diseño: modificación del diseño si los problemas emergentes en la prueba Beta lo ameritan. • Implementación: adaptar el software para el lugar de los usuarios y corregir problemas no descubiertos en las pruebas Beta. • Prueba: pruebas Beta y aceptación de las pruebas en el lugar del usuario. Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 26. Proceso Unificado: Objetivos, Documentos, Entregables Fuente: IIE Instituto de Ingeniería Eléctrica.DesaSoft Desarrollo de Software para Ingeniería Eléctrica.Guías de clase. Parte II: Ingeniería de Software. Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 27. Fase de INICIO UP: Objetivos, Documentos, Entregables Fase Objetivos Generales Documento/Modelo Documento/Modelo de la Fase Fuente Producto de TrabajoInicio - Tomar decisiones - Modelo del negocio - Documento de visión tecnológicas - Documento - Modelar el negocio descriptivo del negocio - Capturar requisitos - Documento de - Identifica el riesgo crítico evaluación del riesgo - Modelo de requisitos funcionales - Modelo de casos de uso - Modelo del dominio - Prototipos desechables - Arquitectura candidata Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 28. Fase de INICIO UP: Objetivos, Documentos, Entregables Fuente: IIE Instituto de Ingeniería Eléctrica.DesaSoft Desarrollo de Software para Ingeniería Eléctrica.Guías de clase. Parte II: Ingeniería de Software. Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 29. Fase de ELABORACIÓN UP: Objetivos, Documentos, Entregables Fase Objetivos Generales Documento/Modelo ARTEFACTO de la Fase Fuente Producto de TrabajoElaboración - Crear arquitectura - Documento de visión - Documento de visión ejecutable - Documento de refinado - Evaluar el riesgo evaluación del riesgo - Documento de - Especificar los atributos de - Modelo de Requisitos evaluación del riesgo calidad - Modelo de casos de uso refinado - Especificar - refinar casos - Arquitectura candidata - Modelo de requisitos de uso No-funcionales - Crear del plan detallado de - Modelo de casos de la fase de construcción uso - Analizar el costo-beneficio arquitectónicamente del sistema solución significativos - Modelo de Clases - Modelo de componentes - Esquema de la base de datos - Prototipos definitivos - Arquitectura ejecutable - Modelo de Pruebas Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 30. Fase de ELABORACIÓN UP: Objetivos, Documentos, EntregablesFuente: IIE Instituto de Ingeniería Eléctrica.DesaSoft Desarrollo de Software para Ingeniería Eléctrica.Guías de clase. Parte II: Ingeniería de Software. Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 31. Fase de CONTRUCCIÓN UP: Objetivos, Documentos, Entregables Fase Objetivos Generales Documento/Modelo Documento/Modelo de la Fase Fuente Producto de TrabajoConstrucción - Desarrollar los productos - Arquitectura ejecutable - Modelo de Despliegue a ser liberados refinada - Programas de Software - Hacer la integración de - Modelo de componentes de la solución subsistemas - Esquema de la base de - Resultados de pruebas - Realizar pruebas de datos de unidad unidad - Realizar pruebas de integración Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 32. Fase de TRANSICIÓN UP: Objetivos, Documentos, Entregables Fase Objetivos Generales Documento/Modelo Documento/Modelo de la Fase Fuente Producto de TrabajoTransición - Ejecutar pruebas - Modelo de Despliegue - Resultado de pruebas operativas del sistema - Modelo de Componentes funcionales y de la - Corregir errores de refinado capacidad operativa del construcción - Esquema de la base de sistema - Hacer pruebas para datos refinado - Manuales de usuario liberación de productos de - Programas de software a - Manuales de operación trabajo ser liberados del sistema - Documento con plan de implantación Material Preparado por MARTA SILVIA TABARES B. UdeM