Ir al contenido principal

CIMM Modelo de capacidad inmadura

En el marco de la calidad de software existen diversas normas o enfoques de implantación, tales como ISO9001, CMM, SIX-SIXMA que clasifican de alguna forma a las organizaciones. Por ejemplo:



Hoy se plantea que existen otro tipo de organizaciones que escapan a estas clasificaciones.


CIMM (The Capability Im-Maturity Model) describe que hay organizaciones que no han alcanzado ni siquiera el primer nivel de CMM.

CIMM fue desarrollado por Anthony Finkelstein, profesor de UCL, University College London, en el que propuso que existen niveles negativos de madurez. Posteriormente este modelo fue refinado por Tom Schorsch, estudiante de doctorado de jornada completa del Instituto de Tecnología de la fuerza aérea de los Estados Unidos en la Base aérea WrightPatterson, Ohio.

Niveles de CIMM

0.Negligente
-1.Obstructivo
-2.Despectivo
-3.Sabotage

El nivel 0 se refiere a las organizaciones negligentes. Éstas impiden cualquier desarrollo de software exitoso. Su gran, y a veces única, preocupación es la reutilización del software.

El nivel -1 representa a organizaciones obstructivas. Imponen procesos contraproductivos para impedir cualquier avance. Se concentran en desarrollar entornos de desarrollo y repositorios.

El nivel -2 Organizaciones desdeñosas. Desprecian cualquier institucionalización de buenas prácticas, su gran objetivo es la programación automática.

El nivel -3 En este nivel existe una total y consciente negligencia. Desacreditan esfuerzos de mejoras de organizaciones de software. Funcionamiento pobre.

Esta clasificación no es muy conocida, pero representa la realidad de muchas empresas.

Comentarios

Unknown dijo…
Jaime,

te felicito... ojalá agregaras algunas referencias para profundizar más en el tema.

Organización desdeñoza. ¿Conoces alguna? :)
Hay algunas cosas que me gustaría que explicaras un poco mas en detalle, porque no me quedan bien claras. Específicamente las tareas en las que se centran estas organizaciones "inmaduras", de qué forma el centrarse en cada una de esas actividades limita la madurez de la organización?

Por ejemplo, la -2 se centra en programación automática; por qué esto es malo, considerando que la automatización de tareas puede mejorar la calidad del software desarrollado?
Anónimo dijo…
Jaime, me parece muy interesante la idea, la verdad no conocía este modelo.
Ojalá otros alumnos se motiven a compartir sus hallazgos.
Unknown dijo…
Jaime, si bien es cierto la automatización de la programación no es mala para una empresa madura, que tiene un proceso definido tanto a nivel de desarrollo, gestión y proceso, etc.

Puede ser muy dañina en empresas que trabajan en forma descuidada y sin límites claros en lo que se refiere a desarrollo.

He visto empresas, en Antofagasta, que tienen sus propias direcciones de informática donde el trabajo de desarrollo se hace realiza en forma artesanal. Estas empresas han optado por herramientas generadoras de código, donde el desarrollo no es fácil de mantener, extender y menos depurar, ya que las mismas herramientas generan código que es muy difícil de entender para personas que siempre han trabajado, por ejemplo, en Visual Basic y que ahora se enfrentan a un código foráneo como por ejemplo C# que involucra una serie de conceptos asociados a la POO.

Es más, una empresa que no tiene la madurez para el desarrollo donde su único objetivo es el uso de herramientas de generación automática terminará desarrollando software "a ciegas". El dicho "que funcione" obstaculiza el desarrollo de una herramienta integrada a la empresa, que madure y se adapte a medida que dura el ciclo de vida de esta.

No estoy diciendo que la automatización sea una mala práctica en empresas maduras, como TUXPAN que ha tenido éxito reconocido en estas materias, sino que hay que tener cuidado cuando el único fin de una jefatura informática es encontrar un sin número de herramientas de generación de código con la idea de que esta es la solución y lo único. Al igual que la programación tradicional orientada a objetos, el conocer o utilizar patrones de diseño no asegura que el software cumpla todas las exigencias de un producto de calidad. Para lograr productos de calidad se deben considerar muchos factores como: gestión de proyecto de software, gestión del desarrollo de software, gestión del proceso de software, etc. Esto sin duda permitirá que las empresas adopten estas tecnologías y que sean de utilidad más que una carga.

En resumen, cualquier entidad que desarrolle software (desde grandes proyectos a pequeños) debe considerar, cada vez más, que se necesitan profesionales capacitados para el desarrollo, que existen técnicas, métodos y metodologías que sin duda mejorán la producción de software y reducirán los costos. Hoy por hoy, no es suficiente sólo saber un lenguaje de programación (o una herramienta que genere código) sino que también hay que saber cuales son los conceptos básicos para el desarrollo y como comunicamos estas ideas a los clientes para una mejor comprensión del problema y retroalimentación. Para eso existen herramientas conceptuales para el análisis, diseño (incluida la arquitectura), modelamiento de las bases de datos, etc.

Eso es todo amigos... y todo esto es solo mi humilde opinión... ;)

Entradas más populares de este blog

Código Python para pasar de notación postfija a infija

Este código es un borrador en  Python que convierte una expresión en notación postfija a notación infija ordenada por paréntesis:

TIPS: Tres algoritmos para convertir una imagen de color a gris en python

Hace un tiempo necesitaba convertir unas imágenes que estaban en color a escalas de grises utilizando python. Buscando en internet encontré un sitio donde explicaban las fórmulas que se utilizan en el GIMP para realizar la conversión.

La tira cómica de Raulito el Friki

Buscando algunas cosas que necesitaba para comunicar un dispositivo por voip, me encontré en un grupo de interés que hacía referencias al sitio y luego de leer un rato no paré de reírme.