archivo

Archivo de la etiqueta: Capability Maturity Model Integration

Del caos del nivel 1 de CMMI, al nivel 2 donde se gestionan/administran determinados procesos, en donde por lo menos a nivel de proyecto se quiere establecer un orden y de ahí al nivel 3 donde los procesos tienen un ámbito de aplicación organizativo (se pretenden eliminar las repúblicas independientes, que tanto daño hacen a las organizaciones que desarrollan software o que tienen que gestionar este tipo de servicios) y en donde se pretende normalizar el proceso de desarrollo de software.

La tendencia de las organizaciones, conforme van creciendo o cuando ya han llegado a un número de empleados y/o proyectos que no se puede gestionar de manera adecuada (no hace falta especificar un número concreto de unos o de otros, ya que un gestor de cualquier entidad de este tipo y si me apuráis, cualquier empleado, se da cuenta cuando la maquinaria no funciona y para verlo no es necesario revisar resultados económicos) debería ser establecer un modelo organizativo orientado al proceso.

Los procesos pueden gustar o no, pero permiten definir un ámbito de trabajo, siempre es mejor esto, que el hecho de que cada cual haga su guerra por separado y se pierda la visión de que la empresa puede ser un conjunto de piezas distribuidas, pero siempre atendiendo a un interés común.

La clave de la implantación de CMMI o de cualquier otro tipo de modelo orientado a procesos se encuentra en ajustarlo a la realidad de la organización donde se implanta, a su contexto y a su negocio. Es decir, no se puede implantar un modelo que no se pueda cumplir, un modelo a ciegas que no tenga en cuenta qué es la organización, qué puede asumir y hacia dónde se va a dirigir. Precisamente éste es uno de los factores de fracaso de la aplicación de este tipo de modelos, definirlo como si la organización no existiera.

La aplicación de CMMI no asegura que los proyectos salgan mejor, ya que el éxito o el fracaso de los proyectos trasciende a los procesos, pero sí que determina un buen punto de partida y habla bien a las claras de cómo es la organización de la entidad que desarrolla el software. Por eso no es de extrañar que tanto administraciones públicas, como organizaciones privadas tengan cada vez más en cuenta la adecuación de las entidades a las que contratan servicios de desarrollo de software a modelos organizativos orientados a procesos basados en algún estándar o modelo reconocido internacionalmente.

Como mínimo una entidad debe aspirar a tener el nivel 3, si bien, en función de su estado actual, podría optar por pasar primero por el nivel 2 y aplicar algún área de proceso de nivel 3. ¿Se requieren muchos cambios? Se requieren cambios y si son muchos o pocos, significativos o no, depende de cómo la organización funcione actualmente y también dependerá de la definición de un modelo de procesos acorde a las necesidades y naturaleza de la organización. Desde mi punto de vista se ve CMMI nivel 3 como un muro insoslayable y sin embargo, un simple vistazo a sus áreas de proceso, permite darnos cuenta de que el monstruo no es tan fiero como lo pintan.

A continuación, se enumeran las áreas de proceso de nivel 3.

CMMI-DEV

Desarrollo de requisitos.
Solución técnica.
Integración de producto.
Verificación.
Validación.
Enfoque en el proceso organizativo.
Definición de proceso organizativo.
Formación organizativa.
Análisis de riesgo.
Análisis de decisiones y soluciones.
Gestión de proyectos integrada.
Gestión de proveedores integrada.

CMMI-DEV + IPPD

Equipos integrados.
Ambiente organizacional para la integración.

El nivel 1 de CMMI se considera nivel inicial porque hace referencia a la ausencia de procesos o en el caso de que existan a la ausencia de control, seguimiento y/o cumplimiento de los mismos.

Una organización dedicada al desarrollo de software que se encuentre en este nivel se entiende que no tiene un control real sobre los proyectos en los que está trabajando: no se conoce realmente el grado de ejecución de los mismos, no hay control de plazos, no hay control de los costes económicos, no existe una motivación para la toma de determinadas decisiones, etc…

Estamos ante una situación en la que cada proyecto es quien maneja las riendas y no la organización quien las lleva, por tanto, si ya es complicado intentar conseguir un comportamiento predecible en un proyecto de desarrollo de software, todavía lo es más cuando no existe un control sobre el mismo y predomina la reacción ante las circunstancias que van aconteciendo a la acción.

Este nivel se caracteriza, por tanto, por el comportamiento impredecible de los proyectos por la ausencia de procesos definidos o por el no cumplimiento de los mismos (que viene a ser lo mismo) de manera que cada equipo de proyecto o incluso cada desarrollador sigue su propia estrategia o metodología, como una decisión personal o de grupo, pero no siguiendo unas directrices a nivel organizativo.

La mejora de la eficiencia en el proceso de desarrollo de software busca la obtención de una base para la consecución de productos software de calidad (es importante que se tenga en cuenta que ninguna metodología o modelo o garantiza nada, lo único que hace es proporcionar un camino del que si no te sales y ejecutas las tareas de manera adecuada te permite alcanzar como mínimo unos umbrales objetivo para la misma), que se realizan en un entorno controlado (entendiéndose el control como el hecho de que tu influencia sobre el proyecto y sobre todo el entorno sea mayor que la que el proyecto ejerce sobre ti) y que trata de cumplir presupuestos y plazos (siempre y cuando estos sean acordes con la naturaleza del proyecto).

Visto de esta forma a nadie se le escapa que una organización que proporciona servicios de desarrollo de software tenga como objetivo una mejora continua de sus procesos, es decir, de cómo hace las cosas. Esto resulta lógico y razonable ya que un mercado con tanta competencia y en donde actualmente existe crisis económica, si no evolucionas, si no mejoras, si no te adaptas, estás condenado a sufrir mucho, salvo que tengas una posición dominante en algún segmento de mercado que permita tomarte cierto tipo de licencias.

CMMI no es más que la conjunción de una serie de modelos (integración de buenas prácticas, estándares, etc..) orientados a la mejora de determinados servicios (a través de la mejora los procesos a través de los cuales se gestionan/controlan/implementan los mismos): desarrollo de productos y servicios, adquisición de productos y servicios y la gestión y entrega de servicios (cada uno de estos servicios tiene su propia constelación de procesos, en este artículo y los que voy a ir escribiendo sobre esta temática me voy a centrar en los relacionados con el desarrollo de software).

Surgió en los Estados Unidos como medio para combatir la crisis del software que se producía de manera crónica en los proyectos software relacionados con el Departamento de Defensa de los Estados Unidos para lo que se convocó un concurso que ganó la Carnegie Mellon University.

CMMI plantea un modelo en base a qué es lo que hay que hacer y no entra en cómo hay que hacerlo, esto puede suponer una ventaja en cuanto a que proporciona flexibilidad y un inconveniente en el sentido de que no proporciona fórmulas exactas (es como si tienes un mapa, pero tú te las tienes que averiguar para llegar de manera adecuada al destino).

Un aspecto importante de CMMI es que contempla diferentes niveles de madurez en cuanto a la implantación de los procesos, lo que permite que cada organización pueda plantear una estrategia de mejora continua (implanto un proceso, lo consolido, observo ventajas e inconvenientes y tomo la decisión de si me quedo como estoy o intento acceder al siguiente escalón) hasta llegar al nivel de madurez adecuado a las expectativas de la organización y a lo que ésta puede dar de sí.

No se certifica a las organizaciones en CMMI aunque esto es un tema sobre todo más formal que real, ya que lo que se hace es evaluar el nivel de madurez de una organización y otorgándole su pertenencia a uno de los niveles de madurez definidos en el modelo (se empezaría por el nivel 2 de los 5 niveles existentes). No obstante, también es posible realizar una evaluación por áreas de proceso (cada nivel del modelo tiene como objetivo satisfacer los objetivos de todas las áreas de proceso que lo conforman) y determinar el nivel de capacidad de las mismas (permitiendo de esta que se puedan tener procesos más evolucionados que otros, ya sea porque sean más importantes para la organización y/o les resulta más sencillos de conseguir por las características de los procesos ya implantados, su madurez, las características del personal, la cultura de empresa, etc…).

En los próximos artículos sobre la materia pasaré a tratar brevemente los cinco niveles de madurez definidos.