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.
El uso de las tic en la vida ,lo importante que son
CMMi TS, RUP y Patrones de Arquitectura
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
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 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
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
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
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
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
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. ¿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
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
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
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
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. 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
58. Ciclo de Vida
fases
Fuente: Jacobson et al., 2000
58 javiergs@acm.org
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. 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
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
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