Mejorando las competencias arquitectónicas en una … · Mejorando las competencias arquitectónicas en una empresa Mexicana de desarrollo de Software Humberto Cervantes Maceda

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


Relanzam.

Postmortem


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


Relanzam.

Construcción

Postmortem

Relanzam.

Diseño AltoNivel

Postmortem

Lanzam.

Requisitos

Postmortem

Relanzam.

Postmortem


Relanzam.

Postmortem


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


12

Attribute Driven Design

Diseño de la arquitectura en base a tácticas y patrones


13

Views and Beyond

Documentación de la arquitectura


14

Enfoque del SEI

Método para evaluación de la arquitectura


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.”


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


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


Individuo

Equipo

Organización

t



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


Individuo

Equipo

Organización

t



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


Individuo

Equipo

Organización

t



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


Individuo

Equipo

Organización

t



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...

Documents

Mejorando las competencias arquitectónicas en una … · Mejorando las competencias arquitectónicas en una empresa Mexicana de desarrollo de Software Humberto Cervantes Maceda