Subido porJavier Gonzalez-Sanchez
200809 - RUP y Patrones de Software en CMMi Technical Solution
Este documento presenta una introducción al Rational Unified Process (RUP), patrones de software y su aplicación al área de proceso de Solución Técnica del modelo CMMi. Explica conceptos clave como arquitectura de software, patrones, diagramas UML y las fases del RUP. El objetivo es comprender cómo empatar las recomendaciones de CMMi TS y la adopción de RUP como metodología de desarrollo de software, integrando técnicas de arquitectura de software en RUP.
Más contenido relacionado
Similar a 200809 - RUP y Patrones de Software en CMMi Technical Solution
200809 - RUP y Patrones de Software en CMMi Technical Solution
- 1. Rational Unified Process(RUP) y Patrones de Software aplicados a CMMi Technical Solution Javier González Sánchez javiergs@acm.org CIISA 2008
- 2. AGENDA 1. CMMi Technical Solution 2. Arquitectura de Software y Patrones 3. Rational Unified Process (RUP) 7. Caso y Actividades 8. Conclusiones y Referencias 2 javiergs@acm.org
- 3. CONTEXTO CMMi RUP TS software architecture 3 javiergs@acm.org
- 4. EXPECTACTIVAS ¿Qué esperas aprender en este taller ? miscellaneous / client developer engineer manager ¿Cuál es tu perfil? 4 javiergs@acm.org
- 5. CONOCIMIENTO PREVIO Tú experienciacon: CMMi Procesos Arquitectura de software… Ingeniería de software … Diseño de componentes Reuso Patrones (diseño, arquitectura, código) Arquitectura Model-drive Arquitectura Reuse-drive 5 javiergs@acm.org
- 6. LA BATALLA 6 javiergs@acm.org
- 7. PRESENTACIÓN Estudios y Certificaciones Maestría en Ciencias Computacionales CMU Certified Instructor Object-Oriented Design IBM Mastering Object-Oriented Analysis and Design IBM Mastering Requirements Managements Experiencia Arquitecto de Software / Líder de proyecto / Desarrollador Consultor Profesor Director de programa académico 7 javiergs@acm.org
- 8. OBJETIVO Comprender en todasu extensión el concepto de Solución Técnica desde la perspectiva del modelo CMMi, así como los factores a considerar para cumplir con los objetivos de esta área de proceso utilizando el Proceso Unificado de Desarrollo (RUP) y los Patrones de Arquitectura y Diseño de Software CMMi RUP + TS + ARQ = "CÓMO" empatar las recomendaciones de CMMi TS y la adopción de RUP como metodología de creación de software. "CÓMO" integrar en RUP técnicas especificas de arquitectura de software benéficas para la creación de productos. 8 javiergs@acm.org
- 9. CMMi Technical Solution javiergs@acm.org
- 10. DEFINICIÓN El área deproceso de Solución Técnica : Pertenece a la categoría de Ingeniería Es una de las 14 áreas de proceso en nivel 3 Su propósito es diseñar, desarrollar e implementar (incluido el proceso de pruebas) soluciones que satisfagan el conjunto de requerimientos. Soluciones, diseños e implementaciones son parte de los productos, componentes y procesos del área. Productos o componentes 10 javiergs@acm.org
- 11. 11 javiergs@acm.org
- 12. PROBLEMA CMMi no es un proceso. CMMi es un Modelo de Proceso. Las practicas no se presentan en secuencia (aunque algunas veces lo parece). Se deben realizar las practicas especificas (SP) en el orden que tenga sentido para el negocio, y algunas veces incluso repetir SP. 12 javiergs@acm.org
- 13. RUP 13 javiergs@acm.org
- 14. CMMi TS ::SG1 Seleccionar las Soluciones para Productos y Componentes El diseño de la solución debe considerar la evaluación de varias alternativas de solución: arquitectura y modularización, desarrollo interno contra productos comerciales, etc. Estas decisiones deben fundamentarse en: Requerimientos Restricciones de diseño Evolución a futuro del producto Productos comerciales disponibles Cualidades del software 14 javiergs@acm.org
- 15. CMMi TS ::SP1.1 Desarrollar alternativas de solución y criterios de selección Identificar y analizar diversas soluciones alternas. Las alternativas de solución estarán basadas en arquitecturas propuestas que cumplan con las características críticas del producto. Las alternativas de solución caerán dentro de márgenes aceptables de costos, calendario y desempeño. 15 javiergs@acm.org
- 16. CMMi TS ::SP1.2 Seleccionar las soluciones para los componentes del producto que mejor satisfagan los criterios establecidos Establecer los requerimientos asociados al conjunto de soluciones, como los requerimientos asignados a los componentes asociados con dicho conjunto de soluciones. Identificar las soluciones que serán reutilizadas o compradas. Establecer y mantener la documentación de las soluciones, su evaluación y razones de selección o rechazo. 16 javiergs@acm.org
- 17. CMMi TS ::SG2 El diseño del producto o componentes debe incluir información para su implementación y demás fases del ciclo de vida del producto como son la instalación y mantenimiento. Además, la documentación del diseño provee una referencia que soporta el entendimiento del diseño con los agentes relevantes. 17 javiergs@acm.org
- 18. CMMi TS ::SP2.1 Desarrollar el diseño del producto o componentes Diseño preliminar ó arquitectónico. Define los elementos estructurales y de coordinación del producto o componente. Considera cualidades deseables Se debe evaluar el uso de productos comerciales o el reutilizar productos existentes para los componentes del producto. Considera el establecimiento de un framework que de soporte a familias de productos. Subpracticas: RUP y aplicación de patrones 18 javiergs@acm.org
- 19. CMMi TS ::SP2.2 Establecer el Paquete Técnico Component Modelos Diagrams 19 javiergs@acm.org
- 20. CMMi TS ::SP2.3 Diseñar las interfaces del producto y componentes en base a los criterios establecidos 20 javiergs@acm.org
- 21. CMMi TS ::SP2.4 Evaluar, en base a criterios establecidos, si los componentes se desarrollarán, comprarán o reutilizarán La decisión entre desarrollar, comprar o reutilizar comienza en los primeros diseños y se completa a medida que los diseños se van detallando y refinando. Patrones y anti patrones 21 javiergs@acm.org
- 22. CMMi TS ::SG3 Implementación del diseño del producto CMMi TS :: SP3.1 implementar (incluye pruebas) CMMi TS :: SP3.2 Documentar Hablemos de Trazabilidad 22 javiergs@acm.org
- 23. Práctica en Equipo ¿Cómo? 23 javiergs@acm.org
- 24. Arquitecturas, Modelos y Patrones javiergs@acm.org
- 25. Antecedentes Los “cambios”son mis amigos … Necesidades requerimientos producto 25 javiergs@acm.org
- 26. El modelo LEGO La“creatividad” es positiva … … componentes 26 javiergs@acm.org
- 27. Arquitectura… y desoftware… 27 javiergs@acm.org
- 28. El arquitecto Arquitectura desoftware NO IMPLICA DETALLES DE IMPLEMENTACION Arquitecto Obtener Información del problema y diseñar solución que satisfaga requerimiento (funcionales, no funcionales) PERO Apoyándose en patrones, modelos y Framework ADEMAS DE Participar activamente en el desarrollo. PERO no es un desarrollador Generar lineamientos GENERALES a considerarse en la creación de FAMILIAS de productos. 28 javiergs@acm.org
- 29. ¿Por qué unaarquitectura? construcción de la casa del perro construcción de una casa una persona estructura simple proceso simple Un equipo herramientas simples Modelado Procesos bien definidos Conocimiento teórico limitado Herramientas poderosas A medida que los sistemas crecen Los algoritmos y las estructuras de datos dejan de ser el mayor problema. 29 javiergs@acm.org
- 30. casas vs software 30 javiergs@acm.org
- 31. Conceptos estilo arquitectónico Orientada a eventos SOA tipo o clase de arquitectura física lógica tecnológica 31 javiergs@acm.org
- 32. Estilos ¿Arquitectura ? Columnas: ¿maya ó azteca? Dórico, Pirámides en ángulo Jónico, perfecto y columnas de piedra y Corintio Egipto mayor detalle y elaboración. Satisfacer a los dioses y a grandes y extravagantes, un placer a la vista. uno mismo (simetría y azoteas son impresionantes y detalladas naturaleza): Roca, madera en la estructura interna y clásico ventanales emplomados. Fuego, Poder y Belleza china Gótico 32 javiergs@acm.org
- 33. Tipos Aplicación o física Datos negocio Clase o tipo Estilos arquitectónicos arquitectura componente patrón reglas 33 javiergs@acm.org
- 34. Cualidades Arquitectónicas Estáticas: Modificabilidad, Portabilidad, Reusabilidad, Integrabilidad, Verificabilidad. Dinámicas: Desempeño, Disponibilidad, Funcionalidad, Usabilidad. Arquitectónicas: Integridad Conceptual, Correctitud, Completitud, Factibilidad económica 34 javiergs@acm.org
- 35. Modelo de Aplicación 35 javiergs@acm.org
- 36. Idioms Patrón de bajo nivel Soluciona problemas específicos de implementación en un lenguaje de programación Describe como implementar componentes o relaciones aplicando el lenguaje Ejemplos: Convenciones de nombres Formato para el código fuente Manejo de memoria Etc. 36 javiergs@acm.org
- 37. Patrones de Diseño Patrones de medio nivel, organizan la funcionalidad de subsistemas de manera independiente. Describe esquemas comunes de comunicación entre componentes para la solución de problemas generales en un contexto particular. Patrones de Creación Patrones Estructurales Patrones de Comportamiento 37 javiergs@acm.org
- 38. Gang of Four 38 javiergs@acm.org
- 39. De Monitos aCódigo 39 javiergs@acm.org
- 40. Práctica en Equipo 40 javiergs@acm.org
- 41. El modelo LEGO a) Relaciones b) Mini-componentes incluyentes c) Autonomía d) Estándar e) El “cambio” es mi amigo f) Creatividad g) Producto predecible 41 javiergs@acm.org
- 42. Hablando de Relaciones a) Ser a) Observar b) Usar b) Encubrir a… c) Tener c) Decorar a… d) Soy único e) Yo construyo a… f) Trabajar con … g) Soy parte de … 42 javiergs@acm.org
- 43. Observer 43 javiergs@acm.org
- 44. Facade 44 javiergs@acm.org
- 45. Decorator 45 javiergs@acm.org
- 46. Builder 46 javiergs@acm.org
- 47. Strategy 47 javiergs@acm.org
- 48. Composite 48 javiergs@acm.org
- 49. Memento 49 javiergs@acm.org
- 50. Chain of Responsability 50 javiergs@acm.org
- 51. Patrones con Patrones 51 javiergs@acm.org
- 52. Patrones de Arquitectura Patronesde alto nivel, applicable a la especificación fundamental del sistema de software Ejemplos: Distributed Layered Event-driven MVC Frame-based IR-centric Batch Subsumption Pipes and filters Disposable Repository-centric Blackboard Interpreter Rule-based 52 javiergs@acm.org
- 53. Antipatrones Antipatrones aplicados endesarrollo Lava Flow Spaghetti code Poltergeists: muchas clases God class: the blob Golden Hammer Aplicados a la arquitectura Reinventando la rueda Stovepipeline System Stovepipeline Enterprise Vendor Lock-in Aplicados a la gestión Mythical Man Month Death March Project Analysis paralysis Corncob 53 javiergs@acm.org
- 54. Práctica en Equipo 54 javiergs@acm.org
- 55. RUP: Ingeniería de software orientado a resuso javiergs@acm.org
- 56. RUP 56 javiergs@acm.org
- 57. Fundamento Necesidad Notación requerimientos modelos Proceso (diagramas) metodología Herramientas Producto 57 javiergs@acm.org
- 58. Ciclo de Vida fases Fuente: Jacobson et al., 2000 58 javiergs@acm.org
- 59. Diagramas Los diagramas expresangráficamente partes de un modelo desde cierta perspectiva Diagramas de Componentes Modelo(s) Estáticos Dinámicos De Estructura De funcionalidad De arquitectura De Comportamiento 59 javiergs@acm.org
- 60. Relación Modelo de Casos de Uso verificado por especificado por realizado por Modelo de distribuido por Prueba Modelo de Análisis Modelo de implementado por Diseño Modelo de Despliegue Modelo de Implementación 60 javiergs@acm.org
- 61. Agrupando Modelos 61 javiergs@acm.org
- 62. Modelando Casos de Uso Clases Actividades Nombre Estados Atributos Secuencias Métodos Objetos IEEE SRS 62 javiergs@acm.org
- 63. OOSE UML Cada modelos es examinado o Construir modelos que representan al manipulado por un grupo de stakeholders sistema Objetos, tipos, clases código cambiante sistemático modelo informal Problema sistema real OO-SE complejo Requerimientos – Analisis – Diseño - Implementacion -- Pruebas abstracto - iteraciones - concreto 63 javiergs@acm.org
- 64. OOSE OO-SE Comportamiento, mensajes Características, estados objetos encapsulamiento transición Modelan y codifican casos generalización/especialización (herencia) de uso relaciones asociación (objetos) dependencia (import) Generalización (herencia) de actores y casos paquetes código pruebas automáticas 64 javiergs@acm.org
- 65. Práctica en Equipo 65 javiergs@acm.org
- 66. Casos y Actividad Práctica javiergs@acm.org
- 67. Práctica en Equipo 67 javiergs@acm.org
- 68. Conclusiones y Referencias javiergs@acm.org
- 69. AHORRO DE RECURSOS 69 javiergs@acm.org
- 70. CALIDAD 70 javiergs@acm.org
- 71. RUP es unBUFFET 71 javiergs@acm.org
- 72. REFERENCIAS Software Architecture inPractice, Len Bass, Adisson Wesley 2003. Software Reuse: Architecture, Process and Organization for Business Success, Ivar Jacobson, ACM Press Design Patterns, Head First, Eric Freeman & Elisabeth Freeman CMMI Versión 1.1 SEI, 2002 72 javiergs@acm.org
- 73. Javier González Sánchez javiergs@acm.org / in / javiergs http://javiergs.com/ciisa2008 73