Arquitectura de Software y CMMI

En la última década la arquitectura de software ha cobrado una importancia cada vez mayor. Esta tendencia probablemente continuará, entre otras razones, por qué en la nueva versión de CMMI-DEV (v1.3), se han realizado actualizaciones en las áreas de proceso de ingeniería y se han considerado diversos aspectos relacionados con la arquitectura de software [2]. En la entrega de hoy hablaré de forma resumida acerca de las áreas de proceso de CMMI-DEV que involucran aspectos relacionados con la arquitectura de software.

CMMI

De acuerdo al SEI, CMMI (Capacity Maturity Model Integration) es un enfoque de mejora de procesos que proporciona a las organizaciones los elementos esenciales de procesos efectivos que ayudan a mejorar su desempeño. La mejora de proceso basada en CMMI incluye la identificación de las fortalezas y debilidades de la organización en cuanto a procesos y la realización de cambios para transformar las debilidades en fortalezas [1].

Existen tres variantes de CMMI: CMMI-DEV (desarrollo), CMMI-SVC (servicios) y CMMI-ACQ (adqusiciones) aunque para ésta columna nos interesa CMMI-DEV que provee guías para medir, monitorear y administrar los procesos de desarrollo. El modelo CMMI está estructurado en niveles de madurez si se utiliza una representación llamada escalonada. En la representación escalonada se usan conjuntos establecidos de áreas de proceso para definir una ruta de mejora para la organización que se establece en términos de 5 niveles de madurez (del 1 al 5). Un área de proceso es un cúmulo de prácticas relacionadas en un área particular que, cuando son implementadas en conjunto, satisfacen un grupo de objetivos que se consideran importantes para hacer mejoras en esa área particular.

Los componentes del modelo se agrupan en tres categorías: requeridos, esperados e informativos. Los componentes requeridos son esenciales para lograr la mejora en un área de procesos particular. La satisfacción de objetivos específicos y genéricos se usa en las evaluaciones como una base para decidir si un área de proceso ha sido satisfecha. Los componentes esperados describen actividades que son importantes para lograr un componente requerido. Los componentes esperados guían a quienes implementan mejoras o realizan evaluaciones. Los componentes esperados en CMMI son las prácticas especificas y genéricas. Antes de que los objetivos puedan ser considerados como satisfechos, las prácticas descritas, o alternativas aceptables, deben estar presentes en los procesos planeados e implementados de la organización. Los componentes informativos, tales como sub-prácticas o ejemplos de productos de trabajo, son componentes de CMMI que ayudan a los usuarios del modelo a entender los componentes requeridos y esperados.

Arquitectura en áreas de proceso de ingeniería
Las áreas de proceso específicas a CMMI-DEV son las 5 que se agrupan en la categoría de Ingeniería:
•    Desarrollo de Requerimientos (RD)
•    Solución Técnica (TS)
•    Integración del Producto (PI)
•    Verificación (VER)
•    Validación (VAL)

Estas 5 áreas de proceso se encuentran, además, en el nivel 3 de madurez en la representación escalonada. A continuación se describen los aspectos relacionados con la arquitectura en cada una de éstas áreas de proceso.

Desarrollo de Requerimientos (RD)

El propósito del Desarrollo de Requerimientos es de capturar, analizar, y establecer requerimientos de cliente, de producto y de componentes del producto. En esta área de proceso encontramos varios aspectos relevantes en el contexto de la arquitectura de software: En la práctica específica 1.1 (Capturar Necesidades), se menciona como ejemplo de técnica los talleres de captura de atributos de calidad en donde participan involucrados. En la práctica específica 1.2 (Transformar Necesidades de Involucrados en Requerimientos de Cliente) se menciona como sub-practica la priorización de atributos de calidad. En la práctica específica 2.1 (Establecer Requerimientos de Producto y Componente de Producto) se menciona como sub-práctica el desarrollo de requerimientos arquitectónicos que capturen atributos de calidad críticos y sus métricas necesarias para establecer la arquitectura y diseño del producto. En la práctica específica 2.2 (Asignar Requerimientos a Componentes del Producto) se habla acerca de la manera en que los atributos de calidad se mapean a componentes del producto y se menciona como sub-práctica la asignación de requerimientos y restricciones a la arquitectura.

En la práctica específica 2.3 (Identificar requerimientos de interfaces) se menciona que los requerimientos de interfaces son una parte integral de la definición de la arquitectura. Finalmente, en la práctica específica 3.2 (Establecer una definición de Funcionalidad y Atributos de Calidad Requeridos) se menciona como sub-prácticas la identificación de funcionalidades y atributos de calidad deseables y la determinación de atributos de calidad significativos basados en los drivers de negocio.

De los métodos que han sido presentados en ediciones anteriores de ésta columna, QAW o algún método análogo de captura y especificación de atributos de calidad podría ser usado dentro de ésta área de proceso (Edición SG 28).

Solución Técnica (TS)

El propósito de Solución Técnica es de elegir, diseñar e implementar soluciones a los requerimientos. En ésta área de proceso encontramos también múltiples aspectos relativos a la arquitectura de software. En la práctica específica 1.1 (Desarrollar alternativas de solución y criterios de selección) se habla de que las soluciones están basadas en arquitecturas que satisfacen los atributos de calidad críticos y, como sub-práctica, se menciona la identificación de patrones arquitectónicos aplicables. La práctica específica 2.1 (Diseñar el Producto o Componentes del Producto) se enfoca particularmente en la creación de la arquitectura que, de hecho, es mencionada como un ejemplo de producto de trabajo. Cabe señalar que en CMMI, la creación de la arquitectura es parte del “Diseño Preliminar”. Como sub-prácticas relevantes se incluyen la identificación, desarrollo o adquisición de métodos de diseño apropiados para el producto y la documentación del diseño. En la práctica específica 2.2 (Establecer un Paquete de Datos Técnicos) se menciona que es muy útil usar la arquitectura como un medio de organización de los datos técnicos. Como sub-práctica relevante se menciona la determinación de vistas a ser usadas para documentar la arquitectura así como la documentación de decisiones clave de diseño.

De los métodos que han sido presentados en ediciones anteriores de ésta columna, ADD y Views and Beyond o métodos similares de diseño y documentación podrían ser usados dentro de ésta área de proceso (Edición SG 29 y 30).

Integración del Producto (PI)

El propósito de Integración del Producto es de ensamblar el producto a partir de sus componentes, asegurar que el producto una vez integrado se comporta de forma adecuada. En esta área de proceso se hace mucho menos referencia al concepto de arquitectura que en las áreas de proceso anteriormente descritas, sin embargo, hay dos puntos clave que están directamente relacionados con la arquitectura: la estrategia de integración y el aseguramiento de la compatibilidad de interfaces. Respecto a la estrategia de integración, CMMI hace énfasis en el hecho de que la integración del producto puede ser realizada de forma incremental, de acuerdo a un proceso de desarrollo iterativo. Por otro lado, también se menciona que la estrategia de integración debe estar en armonía con el diseño del producto del área de proceso de Solución Técnica (aquí es donde ocurre la conexión con la arquitectura). Por otro lado, en la integración de producto, las interfaces juegan un papel clave y éstas también son consideradas como parte fundamental de la arquitectura.

Ninguno de los métodos que han sido presentados en columnas anteriores se apoya directamente en ésta área de proceso, sin embargo, el uso de métodos en las áreas de proceso de RD y TS aumentaría la probabilidad de realizar una integración exitosa. Por otro lado, la estrategia de integración está relacionada con la manera en que se integran las actividades de desarrollo de arquitectura en el ciclo de vida de desarrollo (Edición SG 32).

Verificación (VER)

El propósito de la Verificación es de asegurar que los productos de trabajo seleccionados cumplan sus requerimientos especificados. En la práctica específica 1.1 (Seleccionar Productos de Trabajo para Verificación) se menciona, entre otros ejemplos de métodos de verificación, las evaluaciones de arquitectura. En la práctica específica 2.1 (Preparar para las Revisiones de Pares) una sub-práctica relevante es la determinación del tipo de revisión por pares a realizar y, como ejemplos, se mencionen las revisiones activas y la evaluación de conformidad de la implementación de la arquitectura.

De los métodos que han sido presentados en ediciones anteriores de ésta columna, ATAM, ARID o algún método análogo de evaluación de arquitectura podría ser usado dentro de ésta área de proceso (Edición SG 31).

Validación (VAL)

El propósito de Validación (VAL) es demostrar que un producto o componente de producto se ajusta a su uso previsto cuando se sitúa en su entorno previsto. Al igual que Integración del Producto, ésta área de proceso no hace mucho énfasis respecto a la arquitectura lo cual es entendible pues es relativamente inusual validarla, a diferencia de validar partes del sistema construidas sobre la arquitectura. Sin embargo, hacen una mención relevante: la práctica específica 1.1. (Seleccionar Productos para Validación) menciona como ejemplo de producto que puede ser validado el diseño del producto y como métodos las demostraciones de prototipos y los análisis del producto.

Al igual que para PI, ninguno de los métodos que han sido presentados en columnas anteriores se podría usar directamente en ésta área de proceso, sin embargo podría ser útil el tener una arquitectura ejecutable sobre la cual podrían realizarse pruebas para apoyar a realizar la validación (ver SG 32).

En conclusión

Como se puede apreciar, la versión 1.3 de CMMI-DEV incluye muchos aspectos relacionados con la arquitectura de software, principalmente en las áreas de proceso de la categoría de ingeniería. Una gran cantidad de prácticas específicas de las áreas de proceso incluyen sub-prácticas que se mapean directamente a los métodos del ciclo de vida de desarrollo de la arquitectura que han sido presentados en otras ediciones de ésta columna. Además, el glosario del modelo incluye diversas definiciones relevantes al tema. Por otro lado, otras áreas de proceso están conectadas con la arquitectura. Un ejemplo de ello es Análisis de Decisiones y Resolución (DAR, de nivel 3), pues a través del proceso definido para esta área, se pueden documentar las decisiones de diseño más importantes.

Finalmente, la introducción de métodos de arquitectura en la organización puede llevarse a cabo como una instancia del proceso asociado con el área de proceso de Administración del Desempeño Organizacional (OPM), de nivel 5 (ver SG 34).

Por todo lo anterior, es conveniente considerar seriamente la realización de un esfuerzo de introducción de métodos que cubran el ciclo de vida de desarrollo de arquitectura de software dentro de la organización, particularmente si dicha organización está buscando obtener una certificación de CMMI nivel 3 o superior.

Referencias

[1] CMMI Product Team, “CMMi for Development, Version 1.3”, Technical Report CMU/SEI-2010-CR-033, 2011
[2] Jones, L. y Konrad, M. “Capability Maturity Model Integration (CMMI) V1.3 and Architecture-Centric Engineering”, presentación en Software Process Improvement Network, Mayo 2011