CMMi y la Necesidad de un Modelo Integrado

A mediados de la decada los 80' se hizo evidente para el Departamento de Defensa de los Estados Unidos de que la gran cantidad de sistemas que se estaban desarrollando para aplicaciones de defensa que eran intensivos en software, no estaban cumpliendo con los requisitos establecidos y se estaban elevando descontroladamente los costos.

El Software Engineering Institute (SEI), como parte de la Carnegie Mellon University, fue fundado por el Departamento de Defensa como un centro de para la investigación y desarrollo, con la misión de liderar y promover las prácticas de la Ingeniería de Software para mejorar la calidad de los sistemas basados en software.

Inicialmente el modelo se enfocó predominantemente en los procesos de Ingeniería de Software. Las actividades del ciclo de vida del software que coincidían con las descripciones encontradas en la ISO9001:1994 fueron colocadas todas juntas en una Area de Proceso Clave (Key Process Area) llamada Ingeniería de Producto.

Muchos debates tomaron lugar en los sagrados salones del SEI durante el desarrollo del CMMI v1.0 con respecto a la necesidad de una descripción más detallada de las actividades del ciclo de vida versus mantener un cierto tamaño y un número de Areas de Proceso Claves que fueron desarrolladas en el Nivel 3 de Madurez. Al final, se decidió mantener sólo una Área de Proceso Clave llamada "Ingeniería" donde se describen las actividades o funciones que se mantendría compatibles con el resto de KPA en CMM.

Mientras el uso de CMM crecía rápidamente alrededor del mundo, comenzó a verse clara y rápidamente que el foco estricto en la Ingeniería de Software, no satisfacía las necesidades de negocio o sistemas intensivos en software. Una asesoría conducida por Jeff Perdue del Institute of Software Process Improvement (ISPI) mostró que la necesidad por un proceso de mejora de "sistemas" de ingeniería era inmediata y los resultados serían precisos. Finalmente varios modelos CMM fueron desarrollados para una gran variedad de disciplinas, aparte de la ingeniería de software. Estos modelos incluidos para la adquisición de software, la gestión de personas, desarrollo y la integración de producto y procesos.

Aunque estos modelos resultaron útiles para muchas organizaciones, el uso de múltiples modelos también se convirtió en un problema. Las organizaciones que deseaban centrarse en su mejora en todas las disciplinas tuvieron dificultades. Las diferencias entre los modelos específicos de cada disciplina, incluyendo sus arquitecturas, contenidos y enfoques, limitaban la habilidad de las organizaciones para enfocar sus esfuerzos en mejorar sus procesos exitosamente. Adicionalmente, la aplicación de múltiples modelos que no estaban consistentemente integrados dentro y a través de una organización, resultaba en altos costos en términos de capacitación, evaluaciones y actividades de mejora.

El proyecto CMMi fue formado para superar el problema de usar múltiples CMM. La misión del equipo del modelo CMMi fue combinar tres modelos:

1. SW-CMM: Capability Maturity Model for Software (v2.0 draft C).
2. Electronic Industries Alliance Interim Standard (EIA/IS 731).
3. Integrates Product Development Capability Maturyty Model (IPD-CMM v0.98)

En definitiva, el objetivo era integrar estos modelos en un único framework para su uso por organizaciones que persiguen en toda la empresa la mejora de sus procesos.

La necesidad de un modelo integrado se puede apreciar en como evolucionó CMMi en el set de modelos que representa hoy en día.

REFERENCIAS:

• Introduction to the Architecture of the CMMI® Framework
• Addison Wesley - CMMI for Development 3rd Edition Mar 2011
• Addison Wesley Professional - CMMI for Services - Guidelines for Superior Service - 2nd Edition - Mar 2011
• Practical Insight into CMMI

Arquitectura de Software Empresarial & Servicios Financieros

La mayoría de las empresas hoy en día no poseen una arquitectura formal (Gartner, 2003). La solución no es otra super inversión que provoque un Big-Bang en la organización. Si en un proyecto no se ha definido una arquitectura de sistema confiable, flexible y escalable, simplemente éste no debe proceder.

La arquitectura juega un papel fundamental al permitir que una organización cumpla con sus objetivos de negocio. Arquitectura tiene un precio (el costo de su desarrollo, cuidado), pero vale la pena por sí mismo generosamente al permitir la organización para lograr sus los objetivos con el sistema y ampliar las capacidades del software. La arquitectura es un activo que tiene un valor tangible a la organización de desarrollo más allá del proyecto para el cual fue creado. La arquitectura estrictamente desde un punto de vista de la ingeniería de software aporta tanto a proyecto de desarrollo, además de que el valor devuelto a la empresa.

La arquitectura de software en década del 90' surgió como un subcampo de la ingeniería del software , cuando se hizo ampliamente reconocida la idea de que conseguir la arquitectura correcta era un elemento clave para la creación de un sistema de software que cumpliera con los requerimientos. Tras esto se siguió una serie vertiginosa de las propuestas de anotaciones, herramientas, técnicas y procesos para apoyar el diseño arquitectónico y de integrarlo con las prácticas de desarrollo de software existentes. Y, sin embargo, a pesar de la existencia de este cuerpo de conocimiento, en la arquitectura de software existen aún muchos casos en los que no se sigue una práctica estandarizada.

Parte de la razón de esto ha sido una especie de polarización de opiniones sobre el papel que la arquitectura debe jugar. Por un lado es una escuela de pensamiento que defiende la arquitectura centrada en el diseño, en la que la arquitectura juega un crucial y esencial papel durante el proceso de desarrollo de software. La gente en este campo han tendido arquitectura para centrarse en los diseños arquitectónicos detallados y completos y bien definidos hitos y normas explícitas para la documentación de la arquitectura. En el otro lado es una escuela de pensamiento que menos énfasis arquitectura, con el argumento de que surjan naturalmente, como un subproducto de un buen diseño.

Es obvio que para la clase de sistema. La gente en este campo han tendido a centrarse en la minimización de diseño de la arquitectura como una actividad separada de la aplicación, y en la reducción o la eliminación de documentación arquitectónica.

Claramente, ninguno de estos campos tiene derecho para todos los sistemas. De hecho, la pregunta que uno debe plantearse es: "¿Cuánto diseño arquitectónico se requiere para desarrollar un sistema dado? "

En el libro, George Fairbanks se propone una respuesta: "Sólo Arquitectura suficiente." En un primer momento a esto podría ser: "Bueno, duh!", Porque ¿quién querría demasiado o muy poco. Como tal, proporciona una manera refrescante y no dogmático de enfoque de software arquitectura - con un enorme valor práctico.

Fairbanks señala que el criterio básico para determinar la cantidad de la arquitectura es suficiente la reducción del riesgo. Donde hay poco riesgo en un diseño, la arquitectura poco es necesario. Pero cuando dura problemas de diseño del sistema surgen, la arquitectura es una herramienta con la un enorme potencial. En concreto, se centra en la reducción de riesgos de ingeniería se alinea los beneficios con los costos, asegurando que el diseño arquitectónico se utiliza en situaciones donde se requiera cumplir con ciertas expectativas.

Naturalmente, hay un montón de cuestiones secundarias para responder. ¿Qué riesgos son los mejores dirigida a la arquitectura de software? ¿Cómo se aplican los principios de diseño arquitectónico para resolver un problema de diseño? ¿Qué escribir acerca de su arquitectura compromisos para que los demás saben lo que son? ¿Cómo se puede ayudar a asegurar que compromisos arquitectónicos son respetados por los ejecutores de abajo?

REFERENCIAS:

Enterprise Software Architecture & Financial Services Industry – Future Trends, Challenges & Frameworks - MIT [Ahmad Shuja, 2003]
Software Architecture in Practice 2nd Edition - The SEI Series in Software Engineering
Just Enough Software Architecture - [Fairbanks, 2010]