Upload
dotuyen
View
225
Download
0
Embed Size (px)
Citation preview
1
Mejorando las competencias arquitectónicas en una empresa Mexicana de
desarrollo de Software
Humberto Cervantes MacedaWorkshop 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
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 TSPAlrededor 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
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
Relanzam.
Postmortem
Integracióny Pruebas
Relanzam.
Construcción
Postmortem
Relanzam.
Diseño AltoNivel
Postmortem
Lanzam.
Requisitos
Postmortem
Relanzam.
Postmortem
Integracióny Pruebas
Relanzam.
Postmortem
Integracióny Pruebas
Relanzam.
Construcción
Postmortem
Relanzam.
Construcción
Postmortem
Relanzam.
Diseño AltoNivel
Postmortem
Relanzam.
Diseño AltoNivel
Postmortem
Lanzam.
Requisitos
Postmortem
Lanzam.
Requisitos
Postmortem
5
Fases principales de desarrollo en TSP
TSP divide el desarrollo en las siguientes fases
Relanzam.
Postmortem
Integracióny Pruebas
Relanzam.
Construcción
Postmortem
Relanzam.
Diseño AltoNivel
Postmortem
Lanzam.
Requisitos
Postmortem
Relanzam.
Postmortem
Integracióny Pruebas
Relanzam.
Postmortem
Integracióny Pruebas
Relanzam.
Construcción
Postmortem
Relanzam.
Construcción
Postmortem
Relanzam.
Diseño AltoNivel
Postmortem
Relanzam.
Diseño AltoNivel
Postmortem
Lanzam.
Requisitos
Postmortem
Lanzam.
Requisitos
PostmortemEtapasdonde sedesarrolla laarquitectura
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 HLDEstudio de documentación HLD de otros proyectosPláticas con arquitectos
Durante esta auditoria se identificaron diversas áreas de oportunidad para realizar mejoras
Requerimientos relacionados con la arquitecturaDiseño de la arquitectura y su documentaciónEvaluación del diseño
7
Problemáticas observadas
A nivel de RequerimientosDificultad de capturar y documentar los atributos de calidad de manera apropiada
A nivel de Diseño de alto NivelDificultad para realizar un diseño sistemático de la arquitectura
Variabilidad dependiendo de arquitectosDificultad 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 fondoDificultad para documentar riesgos asociados con arquitectura
8
Otras problemáticas
Dificultad de pasar de diseño arquitectural a diseño detallado
A nivel organizaciónFalta 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 ?
9
Otras problemáticas
Dificultad de pasar de diseño arquitectural a diseño detallado
A nivel organizaciónFalta 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 !
¿ 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
Bass, Clements, Kazman “Software Architecture In Practice”, Addison Wesley, 2003
11
Quality Attribute Workshop
Captura y documentación de atributos de calidad
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
Bass, Clements, Kazman “Software Architecture In Practice”, Addison Wesley, 2003
13
Views and Beyond
Documentación de la arquitectura
Bass, Clements, Kazman “Software Architecture In Practice”, Addison Wesley, 2003
14
Enfoque del SEI
Método para evaluación de la arquitectura
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 RUPLos métodos están definidos para un contexto particular de desarrollo
Gran número de participantesClientes con voluntad y conocimiento suficiente para participar
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
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.”
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
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
Etapa 1: Capacitación+ Acompañamiento Etapa 2: Implantación
Individuo
Equipo
Organización
t
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
Etapa 1: Capacitación+ Acompañamiento Etapa 2: Implantación
Individuo
Equipo
Organización
t
Características:- Mejoras a pequeña escala- Piloteo de adaptaciones
Características:- Mejoras a escala organizacional- Cambio en procesos
Alcancede proyecto
actual
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 TrainingTechnical SolutionOrganizational Innovation and Deployment
22
Capacitación
La capacitación está orientada a realizar mejoras a nivel del individuo
Etapa 1: Capacitación+ Acompañamiento Etapa 2: Implantación
Individuo
Equipo
Organización
t
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
TemasIntroducción a la arquitectura de softwareCaptura y especificación de requerimientosarquitecturalesDiseño de arquitecturas de softwareEvaluación de la arquitectura de softwareDocumentació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
Etapa 1: Capacitación+ Acompañamiento Etapa 2: Implantación
Individuo
Equipo
Organización
t
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
Comité de evaluación IngenierosArquitecto
Dis
eño
arqu
itect
ural
Activ
idad
es H
LD e
stán
dar
2. Documentar diseño arquitectural (QS-VaB)
1. Realizar diseño arquitectural (QS-ADD)
4. Revisar lista de riesgos
5. Definir estrategia de integración y pruebas del sistema
6. Documentar detalle del HLDD
7. Realizar inspección del HLDD
3. Realizar evaluación del diseño arquitectural (QS-ATAM)
Como entrada de este proceso se tendrían RFs y RNFs resultado de QS-QAW
8. Realizar puesta bajo configuración
9 Realizar Post-Mortem
HLD
REQ
Capacitacióninformal
Coaching
26
Acompañamiento
Estrategia de acompañamiento
Comité de evaluación IngenierosArquitecto
Dis
eño
arqu
itect
ural
Activ
idad
es H
LD e
stán
dar
2. Documentar diseño arquitectural (QS-VaB)
1. Realizar diseño arquitectural (QS-ADD)
4. Revisar lista de riesgos
5. Definir estrategia de integración y pruebas del sistema
6. Documentar detalle del HLDD
7. Realizar inspección del HLDD
3. Realizar evaluación del diseño arquitectural (QS-ATAM)
Como entrada de este proceso se tendrían RFs y RNFs resultado de QS-QAW
8. Realizar puesta bajo configuración
9 Realizar Post-Mortem
HLD
REQ
Capacitacióninformal
Coaching
- Definición y ejecución deadaptaciones a procesos- Evaluación- Mentoring
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
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
Etapa 1: Capacitación+ Acompañamiento Etapa 2: Implantación
Individuo
Equipo
Organización
t
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”
ResultadosDefinición de scripts siguiendo enfoque PSP/TSP relativos a los métodos del SEIPlantillas y checklists de soporteIntegración de métodos en TSPiExperimentación de la ejecución de los métodos en el contexto de un curso de arquitectura de software en maestría
Resultados satisfactorios
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
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 relacionadosDefinición de tablas de generación de atributos de calidadHerramientas de apoyo
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 relacionadosHerramientas de soporte al diseño arquitectónicoMétricas relacionadas con el diseñoEstrategias de reutilización de los diseños arquitectónicosDiseño basado en componentes del estante (COTS)
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 RUPEn el contexto del proyecto mencionado, se realizará integración con TSP. Aquí hay problemáticas complejas respecto a la estimación.
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 relacionadasAdaptación de métodos existentes (ej. ATAM)Métricas relacionadas con la evaluación.
Para guiar capacitación futura de arquitectos
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 relacionadasIntroducción de un enfoque de líneas de producto dentro de la organizaciónHerramientas de apoyo
36
Síntesis
En esta presentación se mencionaronLas problemáticas típicas de las empresas de desarrolloLas propuestas actuales del SEI enfocadas a resolver varias de esas problemáticasEl 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 mismaDiversas áreas de investigación aplicada que pueden surgir a raíz de este tipo de colaboración
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...