Mejorando las competencias arquitectónicas en una empresa Mexicana de desarrollo de Software

Transcripción

1 Mejorando las competencias arquitectónicas en una empresa Mexicana de desarrollo de Software Humberto Cervantes Maceda 1 Workshop Arquitectura de Software 22 de Junio de 2009

2 Acerca de mi Doctorado en 2004 en Universidad Joseph Fourier, Grenoble, Francia Desarrollo de software basado en componentes Desde 2004, profesor / investigador de tiempo completo en la Universidad Autónoma Metropolitana Iztapalapa Investigación principalmente en arquitectura de software 2 A partir de 2006 comencé a buscar vinculación con la industria De 2006 a 2008 Consultor para el desarrollo de una aplicación de administración de dispositivos en red en Interoperabilidad (PyME) A partir de 2008 Cooperación con Quarksoft enfocada al tema de la arquitectura de software

3 Acerca de Quarksoft Es una empresa de desarrollo fundada en 2001 que actualmente está evaluada en nivel 3 de CMMi Dentro de la organización se usan PSP y TSP Alrededor de 220 Ingenieros repartidos en varios estados de la república Alrededor de 15 arquitectos, de varios niveles de experiencia Actualmente la empresa esta en una fase de crecimiento Múltiples sitios de desarrollo 3 Antes de mi acercamiento con la empresa, ésta ya había identificado la necesidad de realizar mejoras relativas a la arquitectura de software

4 Fases principales de desarrollo en TSP TSP divide el desarrollo en las siguientes fases Lanzam. Requisitos Relanzam. Postmortem Diseño Alto Nivel Relanzam. Postmortem Construcción Relanzam. Postmortem Integración y Pruebas 4 Postmortem

5 Fases principales de desarrollo en TSP TSP divide el desarrollo en las siguientes fases Lanzam. Etapas donde se desarrolla la arquitectura Relanzam. Relanzam. Requisitos Diseño Alto Nivel Postmortem Postmortem Construcción Relanzam. Postmortem Integración y Pruebas 5 Postmortem

6 Identificación de áreas de oportunidad Auditoria realizada durante 2 meses (fin 2009) Estudio de documentación de procesos relativa a HLD Seguimiento de un proyecto durante HLD Estudio de documentación HLD de otros proyectos Pláticas con arquitectos Durante esta auditoria se identificaron diversas áreas de oportunidad para realizar mejoras Requerimientos relacionados con la arquitectura Diseño de la arquitectura y su documentación Evaluación del diseño 6

7 Problemáticas observadas A nivel de Requerimientos Dificultad de capturar y documentar los atributos de calidad de manera apropiada 7 A nivel de Diseño de alto Nivel Dificultad para realizar un diseño sistemático de la arquitectura Variabilidad dependiendo de arquitectos Dificultad para reutilizar Dificultad para realizar una documentación adecuada de la arquitectura Notación para documentación Hasta dónde documentar? Dificultad para evaluar el diseño arquitectónico Énfasis sobre la forma y no el fondo Dificultad para documentar riesgos asociados con arquitectura

8 Otras problemáticas Dificultad de pasar de diseño arquitectural a diseño detallado A nivel organización Falta de capacitación relativa a conceptos de arquitectura de software (enfoque tecnológico) Procesos no consideran la arquitectura suficientemente Son estos problemas específicos a ésta organización? 8

9 Otras problemáticas Dificultad de pasar de diseño arquitectural a diseño detallado A nivel organización Falta de capacitación relativa a conceptos de arquitectura de software (enfoque tecnológico) Procesos no consideran la arquitectura suficientemente Son estos problemas específicos a ésta organización? No... Estos son problemas típicos de muchas organizaciones de desarrollo con respecto a la arquitectura de software! 9 Existen propuestas de solución?

10 Metodología del SEI El SEI Propone una metodología que engloba 4 métodos enfocados a requerimientos, diseño, documentación y evaluación de la arquitectura 10 Bass, Clements, Kazman Software Architecture In Practice, Addison Wesley, 2003

11 Quality Attribute Workshop Captura y documentación de atributos de calidad 11 Bass, Clements, Kazman Software Architecture In Practice, Addison Wesley, 2003

12 Attribute Driven Design Diseño de la arquitectura en base a tácticas y patrones 12 Bass, Clements, Kazman Software Architecture In Practice, Addison Wesley, 2003

13 Views and Beyond Documentación de la arquitectura 13 Bass, Clements, Kazman Software Architecture In Practice, Addison Wesley, 2003

14 Enfoque del SEI Método para evaluación de la arquitectura 14 Bass, Clements, Kazman Software Architecture In Practice, Addison Wesley, 2003

15 Es ésta la panacea? Introducir los métodos del SEI para resolver los problemas de la organización parece una solución adecuada, sin embargo no es posible introducirlos tal cual y es necesario adaptarlos al contexto de las organizaciones Los métodos del SEI no están enfocados a una metodología específica Hay propuestas relativas a RUP Los métodos están definidos para un contexto particular de desarrollo Gran número de participantes Clientes con voluntad y conocimiento suficiente para participar 15 Sin embargo, adaptar los métodos no es suficiente...

16 Arquitectura y cambio organizacional De acuerdo al SEI: Creemos que el equipar a los arquitectos con las mejores herramientas y métodos contribuirá al objetivo global de producir arquitecturas de alta calidad. Sin embargo, creemos que mejorar factores dentro de la organización es crítico para poder adoptar estas herramientas y métodos a nivel de toda la empresa, y por lo tanto es la clave para lograr la promesa [de los beneficios que aporta] la arquitectura dentro de toda la organización Se habla de Competencia arquitectural El que una organización logre buenos resultados relativos a la arquitectura de manera consistente y predecible El que los resultados se logren independientemente de la competencia de un arquitecto particular 16 Bass et al, Evaluating the Software Architecture Competence of Organizations, WICSA 2008

17 Competencia arquitectural La competencia arquitectural de una organización es la habilidad de la organización para 'crecer', usar y mantener las habilidades y conocimientos necesarios para llevar a cabo prácticas centrales a la arquitectura de software de manera efectiva. Estas prácticas se realizan a nivel del individuo, del equipo y de la organización con el fin de producir arquitecturas a un costo aceptable que lleven a crear sistemas alineados con los objetivos de negocio de la organización. 17 Bass et al, Evaluating the Software Architecture Competence of Organizations, WICSA 2008

18 Competencia arquitectural La competencia arquitectural de una organización es la habilidad de la organización para 'crecer', usar y mantener las habilidades y conocimientos necesarios para llevar a cabo prácticas centrales a la arquitectura de software de manera efectiva. Estas prácticas se realizan a nivel del individuo, del equipo y de la organización con el fin de producir arquitecturas a un costo aceptable que lleven a crear sistemas alineados con los objetivos de negocio de la organización. Mejorar la producción de arquitecturas dentro de una organización requiere por lo tanto de cambios a nivel organizacional a todos los niveles El SEI no da guías para realizar esta mejora 18 Bass et al, Evaluating the Software Architecture Competence of Organizations, WICSA 2008

19 Estrategia en la empresa... Con el fin de resolver las problemáticas descritas al inicio, se definió una estrategia de dos etapas En colaboración con C. Montes de Oca y J. Castillo t Individuo Organización Equipo Etapa 1: Capacitación + Acompañamiento Etapa 2: Implantación 19 Características: - Mejoras a pequeña escala - Piloteo de adaptaciones Características: - Mejoras a escala organizacional - Cambio en procesos

20 Estrategia en la empresa... Con el fin de resolver las problemáticas descritas al inicio, se definió una estrategia de dos etapas En colaboración con C. Montes de Oca y J. Castillo Alcance de proyecto actual Individuo Organización t Equipo Etapa 1: Capacitación + Acompañamiento Etapa 2: Implantación 20 Características: - Mejoras a pequeña escala - Piloteo de adaptaciones Características: - Mejoras a escala organizacional - Cambio en procesos

21 Consideraciones Capacitación tiene que realizarse en tiempo muy limitado y es necesario poder evaluar que los participantes han asimilado el conocimiento No es posible pasar por procesos de cambio a nivel organizacional en un primer tiempo y es necesario tener cambios visibles en un corto plazo Es necesario considerar el que la mejora deje evidencia para futuras evaluaciones CMMi Organizational Training Technical Solution Organizational Innovation and Deployment 21

22 Capacitación La capacitación está orientada a realizar mejoras a nivel del individuo t Individuo Organización Equipo Etapa 1: Capacitación + Acompañamiento Etapa 2: Implantación 22 Características: - Mejoras a pequeña escala - Piloteo de adaptaciones Características: - Mejoras a escala organizacional - Cambio en procesos

23 Capacitación Capacitación (principalmente) teórica enfocada a soportar los deberes relacionados con la creación de arquitecturas 23 Temas Introducción a la arquitectura de software Captura y especificación de requerimientos arquitecturales Diseño de arquitecturas de software Evaluación de la arquitectura de software Documentación de la arquitectura de software

24 Acompañamiento El acompañamiento está orientado a introducir mejoras tanto a nivel de individuo como de equipo t Individuo Organización Equipo Etapa 1: Capacitación + Acompañamiento Etapa 2: Implantación 24 Características: - Mejoras a pequeña escala - Piloteo de adaptaciones Características: - Mejoras a escala organizacional - Cambio en procesos

25 Acompañamiento Estrategia de acompañamiento REQ Como entrada de este proceso se tendrían RFs y RNFs resultado de QS-QAW Comité de evaluación Arquitecto Ingenieros Diseño arquitectural 1. Realizar diseño arquitectural (QS-ADD) 2. Documentar diseño arquitectural (QS-VaB) 3. Realizar evaluación del diseño arquitectural (QS-ATAM) Coaching 4. Revisar lista de riesgos 5. Definir estrategia de integración y pruebas del sistema HLD Actividades HLD estándar 6. Documentar detalle del HLDD 7. Realizar inspección del HLDD 8. Realizar puesta bajo configuración Capacitación informal 9 Realizar Post-Mortem 25

26 Acompañamiento Estrategia de acompañamiento REQ Como entrada de este proceso se tendrían RFs y RNFs resultado de QS-QAW Comité de evaluación Arquitecto Ingenieros Diseño arquitectural 1. Realizar diseño arquitectural (QS-ADD) 2. Documentar diseño arquitectural (QS-VaB) 3. Realizar evaluación del diseño arquitectural (QS-ATAM) Coaching 4. Revisar lista de riesgos 5. Definir estrategia de integración y pruebas del sistema HLD - Definición y ejecución de adaptaciones a procesos - Evaluación - Mentoring Actividades HLD estándar 6. Documentar detalle del HLDD 7. Realizar inspección del HLDD 8. Realizar puesta bajo configuración 9 Realizar Post-Mortem Capacitación informal 26

27 Estatus actual del proyecto Se está realizado una primera ronda de capacitación a los arquitectos más experimentados Buena recepción a pesar del enfoque teórico Todavía no se define el esquema de evaluación Ya comenzó el acompañamiento del primer equipo de desarrollo Ciclo REQ está a punto de iniciar 27

28 Segunda etapa del proyecto La segunda etapa del proyecto se buscará implantar las mejoras a escala organizacional y comenzar otros trabajos más enfocados t Individuo Organización Equipo Etapa 1: Capacitación + Acompañamiento Etapa 2: Implantación 28 Características: - Mejoras a pequeña escala - Piloteo de adaptaciones Características: - Mejoras a escala organizacional - Cambio en procesos

29 Trabajos relacionados Proyecto de maestría Adaptación de una Metodología de Desarrollo Arquitectural al Contexto de Equipos de Desarrollo Pequeños Resultados Definición de scripts siguiendo enfoque PSP/TSP relativos a los métodos del SEI Plantillas y checklists de soporte Integración de métodos en TSPi Experimentación de la ejecución de los métodos en el contexto de un curso de arquitectura de software en maestría Resultados satisfactorios 29

30 Áreas de oportunidad Existen diversas áreas de oportunidad para realizar investigación aplicada Captura y especificación de atributos de calidad Mecanismos de apoyo para el diseño de la arquitectura Integración de métodos de desarrollo arquitectural con metodologías existentes Establecimiento de esquemas de evaluación de arquitecturas Integración del esquema de líneas de producto 30

31 Atributos de calidad El objetivo de ésta línea es identificar mecanismos que apoyen en la realización de captura de atributos de calidad y su documentación Aspectos relacionados Definición de tablas de generación de atributos de calidad Herramientas de apoyo 31

32 Apoyo para el diseño de arquitectura El objetivo de esta línea es identificar métodos que faciliten a los arquitectos que no tienen mucha experiencia el realizar diseños arquitectónicos apropiados (esto es, que satisfagan los requerimientos arquitectónicos del sistema). Aspectos relacionados Herramientas de soporte al diseño arquitectónico Métricas relacionadas con el diseño Estrategias de reutilización de los diseños arquitectónicos Diseño basado en componentes del estante (COTS) 32

33 Integración con metodologías Los métodos de desarrollo arquitectónico propuestos por el SEI son de reciente creación. Una problemática es identificar la manera en que se pueden integrar dentro de los procesos existentes de una organización, por ejemplo, si la organización usa RUP, TSP, metodologías ágiles, etc... Ya existe trabajo de integración con RUP En el contexto del proyecto mencionado, se realizará integración con TSP. Aquí hay problemáticas complejas respecto a la estimación. 33

34 Evaluación de los diseños En un reporte reciente de la NASA relativo a la complejidad del software de control de vuelos (flight software), se cita el establecimiento de revisiones arquitectónicas como una recomendación importante. Problemáticas relacionadas Adaptación de métodos existentes (ej. ATAM) Métricas relacionadas con la evaluación. Para guiar capacitación futura de arquitectos 34

35 Líneas de producto Las líneas de producto son conjuntos de sistemas intensivos de software que comparten un conjunto común y administrado de características que satisfacen necesidades específicas de una misión o segmento particular de mercado y que son desarrolladas de forma prescrita a partir de un conjunto común de bienes que forman un núcleo. Problemáticas relacionadas Introducción de un enfoque de líneas de producto dentro de la organización Herramientas de apoyo 35

36 Síntesis En esta presentación se mencionaron Las problemáticas típicas de las empresas de desarrollo Las propuestas actuales del SEI enfocadas a resolver varias de esas problemáticas El concepto de competencia arquitectural La estrategia actualmente aplicada dentro de una organización Mexicana de desarrollo con el fin de mejorar las competencias arquitecturales de la misma Diversas áreas de investigación aplicada que pueden surgir a raíz de este tipo de colaboración 36

37 Conclusión El tema de arquitectura de software provee de oportunidades de vinculación con la industria Es posible encontrar temáticas innovadoras Mi punto de vista es que en un primer tiempo es que hay que llegar con propuestas aterrizadas que resuelvan problemas inmediatos y posteriormente ya se puede buscar trabajar en áreas más innovadoras En la empresa se valora el que los investigadores estén presentes y, a mi gusto, esa es de las mejores maneras de ver donde están los problemas. Hay que convencer a la universidad... 37