Introduction to Capability Maturity Model Integration V.1.2

Este es el tí­tulo del íºltimo Curso al que he podido asistir. El curso es requisito indispensable para poder participar en las auditorí­as para obtener el nivel de madurez 2 del modelo CMMI. Certificación que ofrece el ESI, el Instituto Europeo de Software.
Curso de 21 horas en el Instituto Tecnológico de Aragón. Demasiado teórico a mi gusto, prácticamente 15 horas fueron teóricas. En parte es algo difí­cil de evitar, sobre todo porque partimos de la base de que sólo disponemos de 21 horas. La metodologí­a necesita su tiempo para poder ver cómo está organizada, y como intenta abordar las diferentes areas de proceso.
La verdad es que por fin tuve la oportunidad de poder conocer in situ el funcionamiento del CMMI, y entender bastante mejor las crí­ticas que conocí­a sobre el modelo.
Como rápido resumen sobre el modelo, digamos que su máxima es que la calidad de un producto depende directamente de la calidad de los procesos que se realizan para llevarlo a cabo. El problema de enfocar tanto la gestión a los procesos, es que almenos en la definición del modelo se está dejando de lado totalmente a las personas, y no nos da ningíºn tipo de guí­a al respecto.
Veremos ahora qué pasa con la auditorí­a. Tenemos hasta octubre para prepararla.
Saludos!
Miguel.

Resolución de Errores de Software.

De todos es sabido que los errores en el software son el pan nuestro de cada dí­a. Alguna de las aplicaciones con las que nos toca trabajar dan más problemas que otras, y lo más normal es que si una aplicación se mantiene viva, con constantes actualizaciones y mejoras, los problemas vayan surgiendo a medida que se añaden nuevas funcionalidades. Por no hablar por supuesto de nuevas aplicaciones, recien salidas del horno, en las que tras una arquitectura moderna y robusta, puede esconderse una falta de testeo de algunos módulos o funcionalidades, o simplemente algunos descuidos de programación que aíºn no ha degenerado en error ya que para explotar necesitan verse inmersas bajo una serie de condicionantes que en entornos de desarrollo es difí­cil simular.
Y estoy hablando de errores, de errores de programación, tí­picos mensajes de alerta, con nuesto querido sí­mbolo de admiración, o su triangulito… no de errores provenientes de una mala toma de requerimientos (modulos que no fallan pero no hacen lo que se supone que tení­an que hacer). Petadas, reventadas, bugs… ya sabéis de lo que hablo.
Sobre prevención de errores hablaremos otro dí­a, pero… ¿cómo resolvemos los errores de software una vez se han producido?
Si tenemos suerte y nuestro Proyecto cuenta con un Plan de Riesgos en el cual se ha contemplado el riesgo de errores en el software y se ha documentado cuales son los pasos que debemos seguir en caso de que se produzca un error… tendremos bastante ganado. Vamos a suponer que no es así­, para hacer el “más difí­cil todaví­a”.
La posibilidad de resolver un error comienza cuando este se produce (obvio), lo que no es tan obvio es que debemos disponer de medios para detectar el error lo antes posible, cosa de la que a veces nos olvidamos. “Bueno, si falla ya llamarán”. “No ha llamado nadie en toda la mañana, eso es que va bien”. ¿Por qué debemos esperar a la llamada de un usuario para ponernos en marcha? ¿No serí­a mucho mejor que una vez se ha producido un error, la propia aplicación sea capaz de enviarnos una alarma al equipo de trabajo, y así­ poder ponernos a investigar prácticamente en el acto? Que bonito serí­a que antes de que llamara el usuario llamarle tíº. Hola buenas tardes señor Fulanito, hemos observado que ha surgido un error en la Aplicación durante el proceso de blablabla, le informamos que tenemos el error controlado, que no ha afectado a la transacción que estaba llevando a cabo, y que tenemos ya a una persona resolviendo la incidencia. O… que te llamara el usuario… Ah si, buenas tardes sr Menganito, somos conocedores del error que se le ha producido en la aplicación, se ha realizado un análisis del mismo, y visto que su nivel de importancia es medio, y no produce ningíºn bloqueo en la aplicación, hemos postpuesto la publicación del parche a la primera hora de mañana, para así­ juntarlo con otras mejoras que tení­amos pendientes.
Qué diferencia eh. Y no es tan difí­cil conseguir que una aplicación mande un SMS o un E-Mail cuando se ha producido una excepción en la aplicación.
Y para finalizar unas cuantas frases.
“Los errores de software desprestigian a la empresa, desprestigian al producto, desprestigian al grupo de trabajo y desprestigian al programador. Además, cabrean.”
“La confianza del usuario en un producto es inversamente proporcional al níºmero de errores generados por la aplicación, multiplicado por la importancia de los mismos (y añadirí­a también por aquí­ algo sobre la media de la distancia de tiempo entre errores)”.
“Esta claro que no se puede tratar igual la gestión de errores de sistemas crí­ticos como el de una central nuclear o un cohete espacial, pero eso no quiere decir que nos tengamos que olvidar de la gestión de errores de un simple editor de texto. Siempre que lo queramos vender, claro.”
Seguimos en la siguiente parte.
Saludos.
Miguel.