200809 - RUP y Patrones de Software en CMMi Technical Solution

4,484 views
4,371 views

Published on

Discutir la importancia de las arquitecturas model-drive y reuse-drive en los procesos de creación de software para la pequeña y mediana empresa. Discutir las técnicas propuestas por el proceso unificado (RUP) y su implementación como parte del área de proceso “Solución Técnica” en el modelo CMMI en empresas pequeñas y medianas. Aplicación de patrones de arquitectura y diseño ¿para qué? ¿cómo? i ¿dónde? Como soporte a CMMI (en el área de proceso de solución técnica).

Published in: Technology, Business
0 Comments
15 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,484
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
15
Embeds 0
No embeds

No notes for slide

200809 - RUP y Patrones de Software en CMMi Technical Solution

  1. 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. 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. 3. CONTEXTO CMMi RUP TS software architecture 3 javiergs@acm.org
  4. 4. EXPECTACTIVAS ¿Qué esperas aprender en este taller ? miscellaneous / client developer engineer manager ¿Cuál es tu perfil? 4 javiergs@acm.org
  5. 5. CONOCIMIENTO PREVIO Tú experiencia con: 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. 6. LA BATALLA 6 javiergs@acm.org
  7. 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. 8. OBJETIVO Comprender en toda su 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. 9. CMMi Technical Solution javiergs@acm.org
  10. 10. DEFINICIÓN El área de proceso 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. 11 javiergs@acm.org
  12. 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. 13. RUP 13 javiergs@acm.org
  14. 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. 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. 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. 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. 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. 19. CMMi TS :: SP2.2 Establecer el Paquete Técnico Component Modelos Diagrams 19 javiergs@acm.org
  20. 20. CMMi TS :: SP2.3 Diseñar las interfaces del producto y componentes en base a los criterios establecidos 20 javiergs@acm.org
  21. 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. 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. 23. Práctica en Equipo ¿Cómo? 23 javiergs@acm.org
  24. 24. Arquitecturas, Modelos y Patrones javiergs@acm.org
  25. 25. Antecedentes Los “cambios” son mis amigos … Necesidades requerimientos producto 25 javiergs@acm.org
  26. 26. El modelo LEGO La “creatividad” es positiva … … componentes 26 javiergs@acm.org
  27. 27. Arquitectura… y de software… 27 javiergs@acm.org
  28. 28. El arquitecto Arquitectura de software 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. 29. ¿Por qué una arquitectura? 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. 30. casas vs software 30 javiergs@acm.org
  31. 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. 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. 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. 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. 35. Modelo de Aplicación 35 javiergs@acm.org
  36. 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. 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. 38. Gang of Four 38 javiergs@acm.org
  39. 39. De Monitos a Código 39 javiergs@acm.org
  40. 40. Práctica en Equipo 40 javiergs@acm.org
  41. 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. 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. 43. Observer 43 javiergs@acm.org
  44. 44. Facade 44 javiergs@acm.org
  45. 45. Decorator 45 javiergs@acm.org
  46. 46. Builder 46 javiergs@acm.org
  47. 47. Strategy 47 javiergs@acm.org
  48. 48. Composite 48 javiergs@acm.org
  49. 49. Memento 49 javiergs@acm.org
  50. 50. Chain of Responsability 50 javiergs@acm.org
  51. 51. Patrones con Patrones 51 javiergs@acm.org
  52. 52. Patrones de Arquitectura Patrones de 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. 53. Antipatrones Antipatrones aplicados en desarrollo 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. 54. Práctica en Equipo 54 javiergs@acm.org
  55. 55. RUP: Ingeniería de software orientado a resuso javiergs@acm.org
  56. 56. RUP 56 javiergs@acm.org
  57. 57. Fundamento Necesidad Notación requerimientos modelos Proceso (diagramas) metodología Herramientas Producto 57 javiergs@acm.org
  58. 58. Ciclo de Vida fases Fuente: Jacobson et al., 2000 58 javiergs@acm.org
  59. 59. Diagramas Los diagramas expresan grá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. 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. 61. Agrupando Modelos 61 javiergs@acm.org
  62. 62. Modelando Casos de Uso Clases Actividades Nombre Estados Atributos Secuencias Métodos Objetos IEEE SRS 62 javiergs@acm.org
  63. 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. 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. 65. Práctica en Equipo 65 javiergs@acm.org
  66. 66. Casos y Actividad Práctica javiergs@acm.org
  67. 67. Práctica en Equipo 67 javiergs@acm.org
  68. 68. Conclusiones y Referencias javiergs@acm.org
  69. 69. AHORRO DE RECURSOS 69 javiergs@acm.org
  70. 70. CALIDAD 70 javiergs@acm.org
  71. 71. RUP es un BUFFET 71 javiergs@acm.org
  72. 72. REFERENCIAS Software Architecture in Practice, 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. 73. Javier González Sánchez javiergs@acm.org / in / javiergs http://javiergs.com/ciisa2008 73

×