Ciclos de Vida guiados por la 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
Objetivos de la conferencia Agenda 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
La Adaptadode evolución Bill Curtis, de la Producción PSM User Conference 2011, Mystc, USA 4 Productos Arquitectura, atributos de calidad, Reuso 2000 y el futuro Para asegurar que el software es construido para satisfacer más que la funcionalidad requerida 3 Procesos CMMI, ITIL, Six Sigma 1990-2000 Más disciplina para poder aprovechar mejores prácticas 2 Métodos 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 1 Lenguajes Lenguajes de 3 y 4 generación, programación estructurada 1965-1980 Mayor poder de expresión en la programación Adaptado de Bill Curtis, 2006 Barry Bohem, 2008
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 Laarquitecturade un programa o sistema es laestructurao las estructuras del sistema que contienen a los componentes, laspropiedades visibles de esos componentes y lasrelaciones 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ó conflictosy buscó consensosentre 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íareflejar 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) Adaptadode 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 Implementa Objetivos del Negocio Arquitectura Sistema/Aplicación Satisface 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 Crear el caso de negocios para el Sistema Entender los requerimientos PALM METODOS / Procesos QAW, IPPD, QFD Crear y/o seleccionar la Arquitectura ADD, 4+1 Documentar y comunicar la Arquitectura Analizar/evaluarla Arquitectura Implementar el Sistema basado en la Arquitectura Views& Beyond, Views+Perspectives, AADL ATAM, basada en cuestionarios, prototipos, simulación, CBAM Agile, RUP, incremental, cascada Asegurar quela implementación satisface la Arquitectura ARID,Inspecciones de diseño basadas en cuestionarios Evolucionarla Arquitectura paraasegurar que continua alineada a los objetivos de negocios Workshops para mejorar la Arquitectura, AIW Asegurar unuso efectivo de las prácticas de Arquitectura Evaluación de competenciasen 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. Identificar la estructura de los equipos de desarrollo 2. Facilitar la estimación del desarrollo 3. Identificar nuevos roles/especialidades en el proceso 4. Incorporar nuevas actividades en el proceso, (ej. Migración de datos) 5. Planificar el paralelismo de actividades 6. Utilizar más de un ciclo de vida para un mismo proyecto 7. Anticipar actividades de verificación, (casos de prueba a partir de los escenarios) 8. Definir el Plan de pruebas y los ambientes 9. 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