«Todos somos muy ignorantes. Lo que ocurre es que no todos ignoramos las mismas cosas.»
Albert Einstein 1879 – 1955
De consultor BI a Trabajador Social
Vivencias y reflexiones de un ingeniero informatico, reconvertido en trabajador social
«Todos somos muy ignorantes. Lo que ocurre es que no todos ignoramos las mismas cosas.»
Albert Einstein 1879 – 1955
Hoy vamos a hablar brevemente de CMMI e ITIL, a muchos les sonaran estos conceptos, ¿pero que son exactamente?, y lo mas importante, ¿cómo se complementan?.
Cada vez más, a los departamentos de TI se les exige unos niveles de calidad y servicio directamente proporcionales a los niveles de calidad y servicio que se exige a las distintas líneas de negocio. En los últimos años han aparecido dos líneas metodológicas que están consiguiendo un gran protagonismo por su carácter práctico y por los buenos resultados obtenidos: CMMI (Capacity Madurity Model Integrated) e ITIL (Information Technology Infrastructure Library).
Principios básicos de CMMI
El modelo CMMI es una fusión de modelos de mejora de procesos para ingeniería de sistemas, ingeniería del software, desarrollo de productos integrados y adquisición de software. La gran ventaja de CMMI es que ha demostrado ser una metodología de gran eficacia, que ha permitido mejoras de gran impacto en procesos de desarrollo de productos software, tales como reducción del coste de desarrollo, localización y resolución de defectos, entre otras. El gran problema de CMMI es su falta de adecuación al enfoque a servicio que está experimentando el sector de las TI en todas sus líneas de actividad, así como el alto esfuerzo de implantación que exige.
Principios básicos de ITIL
La metodología ITIL por su parte, se basa en recopilar una serie de mejores prácticas en diferentes sectores de actividad a nivel mundial, que se publican de forma práctica y sistemática, con el objetivo de lograr una gestión eficiente de la infraestructura y los servicios de TI. La principal ventaja de ITIL es que ha demostrado su eficacia con su enfoque a la gestión de servicios de TI. El gran problema de ITIL es que no cubre adecuadamente las fases de desarrollo de software ni la gestión de proyectos asociada a esa fase de construcción de activos de software.
CMMI vs. ITIL: dos enfoques complementarios
Analizando ambos modelos, podemos observar que CMMI se centra en garantizar la calidad en el desarrollo de software mientras que ITIL garantiza la explotación del producto software. Por ello, muchas empresas consideran que ambas metodologías no son excluyentes, sino complementarias, embarcándose en proyectos de análisis y definición de procesos que permitan encajar ambas filosofías de trabajo.
Espero que esta breve introducción a estas populares metodologias de calidad os haya resultado interesante.
¡Nos vemos en próximas entradas!
«Yo creo bastante en la suerte. Y he constatado que, cuanto mas duro trabajo, mas suerte tengo.»
Thomas Jefferson 1743 – 1826

Es un error muy común pensar que la documentación es poco importante o directamente prescindible, hoy vamos a ver algunas de las posibles consecuencias de no ir generando una documentación adecuada a lo largo del ciclo de vida de un proyecto.
¿Cuántas veces en un proyecto que va retrasado se ha sacrificado una correcta documentación en favor de más tiempo de desarrollo?. Se tiende a pensar que la documentación no es más que un “mal necesario” y en la tabla de tareas suele estar en el último lugar, dejándose siempre para el último momento “si hay tiempo”.
La documentación es una parte muy importante del desarrollo de un proyecto, nos facilita su seguimiento, ayudándonos a encontrar con mayor facilidad posibles fallos que en su momento hubiesen podido pasar desapercibidos, por no hablar de ser un apoyo imprescindible en caso de que haya un cambio en el personal del proyecto. Asimismo permite una vez finalizados los proyectos, tener un repositorio de consulta sobre cómo se realizó el desarrollo de los mismos y los cambios y mejoras que se han dado desde entonces.
Pongamos un par de ejemplos ilustrativos.
1 – Durante el desarrollo de un proyecto, en una fase ya avanzada del mismo, uno de los programadores sufre un percance y coge una baja que le impedirá continuar desarrollando sus funciones. Como ha sido un percance, no estaba planificado y por tanto no se ha podido realizar un traspaso de conocimientos, de un día para otro uno de los puestos ha cambiado y se ha tenido que asignar a toda prisa a otro programador al proyecto para cubrir el puesto. En este escenario se pueden plantear dos opciones, la primera es que se haya ido realizando una correcta documentación del trabajo realizado, en este caso el nuevo programador podrá apoyarse en ella para comprender el trabajo de su predecesor y en un corto espacio de tiempo podrá continuar con su trabajo manteniendo una coherencia con el mismo al seguir los mismos patrones de desarrollo establecidos. La segunda opción es que el nuevo programador se siente frente al ordenador y desgrane toda la tarea de programación de su predecesor, teniendo que revisar línea a línea todas las funciones que se hayan implementado hasta la fecha para después empalmar su propio trabajo sin seguir una pauta concreta. En el primer escenario el trabajo sufre muy poco retraso y el desarrollo final no se ve apenas afectado, en el segundo, el tiempo necesario para continuar trabajando se multiplica exponencialmente al trabajo ya realizado y el cambio de patrones entre ambos programadores puede suponer nuevos retrasos al final del proyecto.
2 – Una empresa contrata a un equipo de consultores para añadir nuevas funcionalidades a su sistema “de toda la vida”, básicamente se busca añadir valor a una serie de funciones que llevan en uso 20 años o más, de hecho, nadie en el cliente recuerda exactamente quien las desarrolló y mucho menos como lo hicieron, además desde entonces se han producido numerosas “intervenciones” sobre dichas funciones para ir adaptándolas a las necesidades puntuales que iban surgiendo en su negocio. Nuevamente tenemos dos posibles escenarios, si hay una buena documentación guardada, en la que se detalla no solo como se realizaron las funciones originalmente, sino también un registro de quien, cuando y como se realizaron las “intervenciones” de mejora, el equipo de consultores tendrá una base sólida para comprender lo que hay y podrá realizar su labor rápida y eficientemente sin demasiado riesgo de alterar nada que no deba ser tocado. En el segundo escenario los consultores no tienen nada a lo que recurrir como apoyo a su trabajo, por lo que tendrán que investigar con minuciosidad todo el contenido del sistema, validando una a una sus funciones para garantizar que siguen en uso y que funcionan acorde a lo esperado. En este escenario las labores de consultoría se dilatan enormemente en el tiempo y se corre el riesgo de que alguna función cuyo contenido no está claro, sea alterada provocando errores y más retrasos.
Como podéis ver, ya seáis una empresa de servicios externos o un cliente final, es primordial planificar adecuadamente los tiempos de ejecución contando con márgenes prudenciales para que se pueda ir desarrollando una correcta documentación del proyecto en paralelo a los avances del mismo y nunca dejar de hacerla ya que no podéis preveer cuando la vais a poder necesitar.
Espero que os haya resultado interesante y que en adelante no volváis a dudar de la importancia de una buena documentación.
¡Nos vemos en próximas entradas!