Ciclo de vida guiados por la Arquitectura

Ciclos de Vida guiados por
la Arquitectura:
Arquitectura
Balanceando entre agilidad,
eficiencia y calidad
Alejandro J Bianchi
ATAM Evaluator Certificate
Software Architecture Professional Certficate
Software Engineering Institute, CMU University
22 de marzo, 2012
Agenda
Objetivos de la conferencia
Los desafíos de la sociedad y las oportunidades para el
Software
La evolución de la producción de Software
El rol de la Arquitectura de Software
Los ciclos de vida guiados por Arquitecturas
Algunas conclusiones
Reconocimientos
PSM, (Practical Software and System Measurement Method), es
marca registrada del US Army, USA
PALM, QAW, ADD, CBAM, ARID, AIW y ATAM, son marcas
registradas del Software Engineeering Institute, CMU University, USA
CMMI, TSP son marcas registradas del Software Engineeering
Institute, CMU University, USA
3
Acrónimos
ADD: Attribute Driven Design
AIW: Architectural Improvement Workshop
ARID: Active Review Intermediate Design
ATAM: Architecture Trade off Analysis Method
CBAM: Cost Benefit Analysis Method
CMMI: Capability Maturity Model Integrated
PSM: Practical Software and System Measurement
PALM: Pedigreed Attribute eLicitacion Method
QAW: Quality Attribute Workshops
4
Objetivos de la Conferencia
Compartir con los asistentes:
Las tendencias y oportunidades del desarrollo de software
La importancia de la calidad de producto
El rol del diseño de Arquitectura en el desarrollo de Software
Que los asistentes puedan incorporar:
Algunas ideas acerca de los ciclos de vida guiados por Arquitectura
De que manera la Arquitectura y la agilidad se complementan
De que forma se puede implantar esta asociación
Sintetizar a través de esos conceptos la visión de un proceso
superior para el desarrollo de Software
Los desafíos de la sociedad global
Mejora del medio ambiente
La vida en las grandes ciudades
Problemas sanitarios y Salud Pública
Transporte y energía
Seguridad pública
Nuevas tendencias de los negocios tradicionales
El desarrollo de Software
El cambio es una constante en el desarrollo de aplicaciones
Aplicaciones multi-capas, multi-plataformas, varios lenguajes, varios
proveedores trabajando en un mismo proyecto
Integración de componentes a través de interfaces complejas
Software abierto conviviendo con aplicaciones propietarias
Las aplicaciones son orientadas al cliente “no hay red”
Cloud Computing y Orientación a Servicios
Nuevas formas de hacer negocios con el software
Adaptado de Bill Curtis,
PSM User Conference
2011, Mystc, USA
Arquitectura, atributos de calidad, Reuso
La evolución de la Producción
2000 y el futuro
4
Productos
3
Procesos
2
Métodos
1
Lenguajes
Para asegurar que el software es
construido para satisfacer más que la
funcionalidad requerida
CMMI, ITIL, Six Sigma
1990-2000
Más disciplina para poder aprovechar mejores
prácticas
Métodos de diseño y herramientas CASE
1980-1990
Proveer a los desarrolladores de más herramientas
y ayudas para producir sistemas basados en software
Lenguajes de 3 y 4 generación, programación estructurada
Adaptado de Bill Curtis, 2006
1965-1980
Barry Bohem, 2008
Mayor poder de expresión en la programación
La evolución de la demanda
Hoy calidad no es solo satisfacer los requerimientos
funcionales
Los atributos de calidad definen el éxito de un producto de
software, (performance, escalabilidad, seguridad,
modificabilidad, etc.)
Los clientes no entienden o minimizan los requerimientos no
funcionales o atributos de calidad
Resolver problemas de atributos de calidad con el sistema en
producción implica costos difíciles de estimar y la cobertura de
las pruebas no es garantía de calidad
Definiendo Arquitectura - 1
“La arquitectura de un programa o sistema es la estructura o
las estructuras del sistema que contienen a los componentes,
las propiedades visibles de esos componentes y las relaciones
entre ellos”
[Bass, Clements & Kazman , “Software Architecture in Practice”, 1998]
Una extensión de la definición:
La arquitectura de una aplicación es un “puente” entre las
necesidades de los stakeholders y los grupos de producción de software, en
donde el arquitecto reflejó las soluciones y decisiones técnicas, resolvió
conflictos y buscó consensos entre todos los interesados/afectados para
lograr un diseño adecuado a los objetivos de negocios
10
Arquitectura: Estructuras + decisiones
Arquitectura es más que:
Componentes
Conectores
Tácticas
Patrones
Modelos de referencia
Vistas y perspectivas
El diseño de Arquitectura es la suma
de conocimiento arquitectural más
decisiones técnicas
11
Todo Sistema tiene una Arquitectura
Las Arquitecturas pueden ser:
Intencionales
Accidentales
Una Arquitectura intencional
puede/debería reflejar los
objetivos del negocio
Una Arquitectura accidental
resulta en una estrategia de
negocios de hecho, (puede ser
buena o no… es difícil de conocer y
sostener)
Adaptado de Grady Booch,
Handbook of Software Architecture
Importancia de la Arquitectura - 1
La arquitectura es importante por tres razones primarias:
Provee un vehículo para la comunicación entre diferentes
stakeholders:
Clientes
Usuarios
Gerentes y desarrolladores
Responsables de operación y mantenimiento
Es la manifestación temprana de decisiones de diseño que
fueron tomadas para satisfacer los atributos de calidad
esperados por los stakeholders
Es una abstracción reusable y transferible de un sistema.
13
Importancia de la Arquitectura - 2
Si, pero hacer diseño de arquitectura es caro y poco ágil…
Y, depende… contra que lo comparamos:
Análisis del contexto del producto/ambiente de
desarrollo/mercado, etc.
Coordinación del trabajo y de los equipos
Anticipar conflictos técnicos y reducir defectos
Administrar la “deuda técnica”, (Technical debt)
14
Ciclo guiados por la Arquitectura
Los métodos y procesos que usamos fallan, entre otras
causas, debido a:
Incremento del tamaño y complejidad de los sistemas
Diversidad de tipos de interfaces entre elementos
Fuertes restricciones impuestas por el negocio
Adherencia a planes y presupuestos
Complejos modelos de calidad, (performance, seguridad,
mantenibilidad, portabilidad, interoperabilidad, etc.)
Integración y reuso de componentes externos
Imposibilidad de sostener la integridad de la arquitectura
a lo largo del ciclo de vida
Nuevas especialidades en el proceso, (seguridad, etc.)
15
Ciclo guiados por la Arquitectura - 2
Un ciclo guiado por la Arquitectura,
es aquel que utiliza el diseño
arquitectural como punto de
referencia para la ejecución de las
demás actividades de
producción/evolución:
Planificación y seguimiento
Diseño de detalle y código
Verificación & Validación
Implantación
Operación y mantenimiento
16
Ciclos guiados por la Arquitectura - 3
Implementa y
evoluciona
Diseña
Objetivos del
Negocio
Implementa
Arquitectura
Satisface
Sistema/Aplicación
Respeta
Satisface
17
Ciclo guiados por la Arquitectura - 4
Más allá de la escala del sistema, la arquitectura es una
abstracción apropiada para razonar acerca como se
satisfacen los objetivos del negocio
Suficiente detalle para razonar acerca de los objetivos de
negocios y las restricciones de implantación
Adecuado nivel de abstracción para que un equipo
pequeño de arquitectos entienda los aspectos
conceptuales del sistema
Los atributos de calidad tienen una influencia dominante
en la arquitectura de un sistema
Los atributos de calidad surgen de los objetivos del
negocio
Los atributos de calidad críticos deben ser caracterizados
de un manera sistemática
18
Ciclo guiados por la Arquitectura - 5
Métodos basados en escenarios son una herramienta
poderosa para caracterizar los atributos de calidad y
representar la visión de cada uno de los stakeholders
La implementación del producto debe reflejar las
decisiones de diseño arquitectural
La Arquitectura debe ser el centro de las actividades de
desarrollo
El ciclo de desarrollo debe tener un foco explícito en
satisfacer los atributos de calidad
Los stakeholders deben participar del desarrollo
La arquitectura debe ser DESCRIPTIVA y PRESCRIPTIVA
Los arquitectos de Software deben ser agentes de
cambio
19
Ciclo guiados por la Arquitectura - 6
ACTIVIDAD
METODOS / Procesos
Crear el caso de negocios para el Sistema
PALM
Entender los requerimientos
QAW, IPPD, QFD
Crear y/o seleccionar la Arquitectura
ADD, 4+1
Documentar y comunicar la Arquitectura
Views & Beyond, Views+Perspectives,
AADL
Analizar/evaluar la Arquitectura
ATAM, basada en cuestionarios,
prototipos, simulación, CBAM
Implementar el Sistema basado en la Arquitectura
Agile, RUP, incremental, cascada
Asegurar que la implementación satisface la Arquitectura
ARID, Inspecciones de diseño basadas
en cuestionarios
Evolucionar la Arquitectura para asegurar que continua
alineada a los objetivos de negocios
Workshops para mejorar la
Arquitectura, AIW
Asegurar un uso efectivo de las prácticas de Arquitectura
Evaluación de competencias en Diseño
de Arquitecturas
20
Basado en Architecting Software Intensive System, Anthony J. Lattanze, 2009, CRC Press
Ciclo guiado por la Arquitectura - 7
El diseño de Arquitectura es un elemento importante al momento
de ajustar el proceso de desarrollo, (visión desde CMMI)
A partir de la vistas, perspectivas y decisiones de diseño es posible:
1.
2.
3.
4.
5.
6.
7.
8.
9.
Identificar la estructura de los equipos de desarrollo
Facilitar la estimación del desarrollo
Identificar nuevos roles/especialidades en el proceso
Incorporar nuevas actividades en el proceso, (ej. Migración de datos)
Planificar el paralelismo de actividades
Utilizar más de un ciclo de vida para un mismo proyecto
Anticipar actividades de verificación, (casos de prueba a partir de los
escenarios)
Definir el Plan de pruebas y los ambientes
Ajustar las actividades de Configuration Management
22
Ciclo guiados por la Arquitectura - 8
La Arquitectura permite en un, contexto ágil, reducir el esfuerzo de
“refactoring”
Gestionar de manera proactiva la “deuda técnica”
Balancear entre las necesidades del producto y las necesidades del
cliente/usuario
Por otro lado, la única manera de ganar velocidad de desarrollo,
más allá de la agilidad, es construyendo menos software o sea
POTENCIAR el REUSO. Sin arquitectura el nivel de reuso siempre
será mínimo.
23
Algunas cuestiones para ver
Si bien está claro el beneficio que aporta diseñar la
Arquitectura, quedan algunos temas que merecen atención:
1.
Cómo estimamos el esfuerzo para diseñar una Arquitectura?
2.
En un contexto ágil o tradicional, cómo identificamos cuándo un diseño
de Arquitectura está completo?
3.
En sistemas complejos, cómo gestionamos las propiedades
emergentes?
4.
Qué nivel de documentación es adecuado y con que notación?
5.
Cómo evaluamos la calidad de un diseño de Arquitectura, desde la
perspectiva de producto y del proceso?
6.
Qué alcance debe tener la formalización de las decisiones?
7.
Cómo identificamos a un buen Arquitecto?
24
Un Proceso Superior: Simple…
Control de los costos y
predicibilidad de los planes
Responder a las
necesidades de cambio
Minimizar costos de
desarrollo y de los planes
Que sea escalable
dependiendo del tamaño
del producto
Desarrollar productos de
calidad predecible
Conclusiones
A la producción de software se le exige agilidad, que sea abierta al cambio y
buscando siempre la manera de ser más eficiente y útil para sus clientes
La combinación de conocimiento, ambiente de trabajo, procesos
adecuados con foco en los objetivos de negocios son ingredientes básicos
para lograrlo y agregar valor
Lo que se espera de un proceso de desarrollo es que provea a la
organización y a los grupos de desarrollo de:
VISION
RITMO
COOPERACION
ANTICIPACION
SIMPLICIDAD
Pensar en integrar prácticas de diseño de Arquitectura es una manera de
facilitar un proceso superior
Más información…
www.sei.cmu.edu : reportes, papers, webinars, presentaciones en las
diferentes ediciones SATURN
www.bredemeyer.com
www.handbookofsoftwarearchitecture.com
Muchas gracias
alejandro.bianchi@liveware.com.ar