Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Rational Unified Process (RUP)
       y Patrones de Software
              aplicados a CMMi
             Technical Solutio...
AGENDA


1.   CMMi Technical Solution



2.   Arquitectura de Software y Patrones



3.   Rational Unified Process (RUP)

...
CONTEXTO




    CMMi        RUP
     TS




                       software

                      architecture




3    ...
EXPECTACTIVAS



    ¿Qué esperas aprender en este taller ?




                                                          ...
CONOCIMIENTO PREVIO


Tú experiencia con:

    CMMi

    Procesos

    Arquitectura de software… Ingeniería de software …
...
LA BATALLA




6                javiergs@acm.org
PRESENTACIÓN


Estudios y Certificaciones

      Maestría en Ciencias Computacionales

      CMU Certified Instructor Obje...
OBJETIVO



Comprender en toda su extensión el concepto de Solución Técnica desde la
perspectiva del modelo CMMi, así como...
CMMi
Technical Solution
                     javiergs@acm.org
DEFINICIÓN


El área de proceso de Solución Técnica :


     Pertenece a la categoría de Ingeniería

     Es una de las 14...
11   javiergs@acm.org
PROBLEMA



     CMMi no es un proceso.

     CMMi es un Modelo de Proceso.

     Las practicas no se presentan en secuenc...
RUP




13         javiergs@acm.org
CMMi TS :: SG1



 Seleccionar las Soluciones para Productos y Componentes

 El diseño de la solución debe considerar la e...
CMMi TS :: SP1.1


Desarrollar alternativas de solución y criterios de selección


     Identificar y analizar diversas so...
CMMi TS :: SP1.2


Seleccionar las soluciones para los componentes del producto que
mejor satisfagan los criterios estable...
CMMi TS :: SG2



El diseño del producto o componentes debe incluir información para su
implementación y demás fases del c...
CMMi TS :: SP2.1


 Desarrollar el diseño del producto o componentes


     Diseño preliminar ó arquitectónico. Define los...
CMMi TS :: SP2.2
Establecer el Paquete Técnico




                                                          Component
   ...
CMMi TS :: SP2.3


Diseñar las interfaces del producto y componentes en base a los
criterios establecidos




20          ...
CMMi TS :: SP2.4



Evaluar, en base a criterios establecidos, si los componentes se
desarrollarán, comprarán o reutilizar...
CMMi TS :: SG3



Implementación del diseño del producto



     CMMi TS :: SP3.1 implementar (incluye pruebas)

     CMMi...
Práctica en Equipo



                          ¿Cómo?




23                             javiergs@acm.org
Arquitecturas,
Modelos y
Patrones
                 javiergs@acm.org
Antecedentes



 Los “cambios” son mis amigos …




     Necesidades
     requerimientos
                                 ...
El modelo LEGO



La “creatividad” es positiva …




                                      … componentes

26              ...
Arquitectura… y de software…




27                                  javiergs@acm.org
El arquitecto


Arquitectura de software

     NO IMPLICA DETALLES DE IMPLEMENTACION

Arquitecto

     Obtener Información...
¿Por qué una arquitectura?


     construcción de la casa del perro                    construcción de una casa




     u...
casas vs software




30                       javiergs@acm.org
Conceptos



     estilo arquitectónico

     Orientada a eventos

     SOA



     tipo o clase de arquitectura

     fís...
Estilos


                                                                                             ¿Arquitectura ?
   ...
Tipos


                      Aplicación o
     física                                        Datos
                      ...
Cualidades Arquitectónicas


     Estáticas:
     Modificabilidad,
     Portabilidad,
     Reusabilidad,
     Integrabilid...
Modelo de Aplicación




35                          javiergs@acm.org
Idioms


     Patrón de bajo nivel

     Soluciona problemas específicos de implementación en un lenguaje de
     programa...
Patrones de Diseño


 Patrones de medio nivel, organizan la funcionalidad de subsistemas de
 manera independiente.

 Descr...
Gang of Four




38                  javiergs@acm.org
De Monitos a Código




39                         javiergs@acm.org
Práctica en Equipo




40                        javiergs@acm.org
El modelo LEGO




           a) Relaciones

           b) Mini-componentes incluyentes

           c) Autonomía

        ...
Hablando de Relaciones




 a) Ser                a) Observar

 b) Usar               b) Encubrir a…

 c) Tener           ...
Observer




43              javiergs@acm.org
Facade




44            javiergs@acm.org
Decorator




45               javiergs@acm.org
Builder




46             javiergs@acm.org
Strategy




47              javiergs@acm.org
Composite




48               javiergs@acm.org
Memento




49             javiergs@acm.org
Chain of Responsability




50                             javiergs@acm.org
Patrones con Patrones




51                           javiergs@acm.org
Patrones de Arquitectura



Patrones de alto nivel, applicable a la especificación fundamental del sistema
de software

Ej...
Antipatrones


Antipatrones aplicados en desarrollo
   Lava Flow
   Spaghetti code
   Poltergeists: muchas clases
   God c...
Práctica en Equipo




54                        javiergs@acm.org
RUP:
Ingeniería de
software
orientado a
resuso
                javiergs@acm.org
RUP




56         javiergs@acm.org
Fundamento


 Necesidad
                                    Notación
     requerimientos




       modelos        Proceso...
Ciclo de Vida


                                                          fases




     Fuente: Jacobson et al., 2000



...
Diagramas


Los diagramas expresan gráficamente partes de un modelo desde cierta perspectiva




                         ...
Relación



          Modelo de
         Casos de Uso                                                verificado por




  ...
Agrupando Modelos




61                       javiergs@acm.org
Modelando


     Casos de Uso

     Clases

     Actividades
                                          Nombre
     Estados...
OOSE



                                                      UML
                                                        ...
OOSE


                                                                           OO-SE
             Comportamiento, mensa...
Práctica en Equipo




65                        javiergs@acm.org
Casos y
Actividad
Práctica
            javiergs@acm.org
Práctica en Equipo




67                        javiergs@acm.org
Conclusiones y
Referencias
                 javiergs@acm.org
AHORRO DE RECURSOS




69                        javiergs@acm.org
CALIDAD




70             javiergs@acm.org
RUP es un BUFFET




71                      javiergs@acm.org
REFERENCIAS




Software Architecture in Practice, Len Bass, Adisson Wesley 2003.

Software Reuse: Architecture, Process a...
Javier González Sánchez


          javiergs@acm.org

                 / in / javiergs

     http://javiergs.com/ciisa2008...
Upcoming SlideShare
Loading in …5
×

200809 - RUP y Patrones de Software en CMMi Technical Solution

4,757 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

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

×