Llegamos a ustedes gracias a:



Reportajes y análisis

Qué implica una certificación en calidad de software

[18/07/2017] Muchas veces las certificaciones son vistas meramente como un documento que indica que se ha aprobado un proceso de certificación, algo para utilizar como parte del material de marketing de la compañía. En realidad, es mucho más que eso. Una certificación implica esfuerzo y, sobre todo, un cambio que muchas organizaciones no tenían previsto cuando pensaron en el mero documento.

Recientemente, Contasis, empresa dedicada a las soluciones contables, hizo que su fábrica de software pasara por un proceso de certificación con el que obtuvieron la CMMI nivel 3. El proceso no fue sencillo y de él la empresa aprendió varias lecciones que compartió en una reunión, y que ciertamente son valiosas para todas aquellas organizaciones que quieran pasar por uno de estos procesos. En aquella reunión, además de los expositores se encontró a Jesús Capcha, CEO de Financont Corp. la empresa matriz de Contasis.

José Antonio Morales, futuro presidente de Apesoft.
Las metodologías

En la reunión, antes de abordar el caso de Contasis, José Antonio Morales, futuro presidente de Apesoft, realizó un recuento de las metodologías de gestión de la calidad de fabricación de software existentes, y qué es importante al elegir certificarse en una u otra.

Para comenzar, Morales indicó que "los modelos se complementan, no se contraponen, y que "el modelo debe ajustarse a la organización, no la organización al modelo. Otro punto que estableció Morales fue que se debe de trabajar bajo la premisa de que lo que uno hace actualmente está bien; con el modelo lo que se busca es mejorar la actividad de la firma.

Pero quizás uno de los errores más comunes y más peligrosos que señaló el expositor fue que las organizaciones "solo buscan el papel, no la mejora. Y quizás eso se deba a que hay muchos prejuicios con respecto a la utilización de los modelos.

Entre los prejuicios más destacaos se encuentran que los procesos crean documentación interminable y artefactos inútiles, que los procesos son solo para las grandes organizaciones, que interfieren con la creatividad, que cuestan mucho, y que son grandes y complejos.

La verdad es que cualquier iniciativa de mejora utilizada inapropiadamente puede causar cualquiera de estos problemas. La clave, dijo Morales, es enfocarse en lo que más beneficia a la organización y a los equipos.

Y hay varios modelos que se pueden seguir: CMMI, MoProSoft, ISO 29110 o Scrum-Agile. ¿Cuál es el mejor? Morales afirmó que en realidad no se puede decir que uno sea mejor que el otro, eso depende de la organización. Ésta tiene que elegir el modelo que más se adecúe a sus necesidades. Y, como se dijo al inicio, los modelos se complementan, no son excluyentes uno del otro.

Esto quiere decir que, si se realizan actividades para un modelo, es muy probable que estas mismas actividades se encuentren en los demás modelos; así al optar por un modelo ya se tiene el camino avanzado, si es que luego se quiere adoptar otro.

Por ejemplo, al comparar el ISO 29110 con MoProSoft nivel 2, Morales mostró que de las 67 actividades requeridas por la ISO en MoProSoft se cubren completamente 50 de ellas, cuatro requieren ajustes menores y 13 sí tienen que ser implementadas desde cero.

Amanda Durán, gerente de la fábrica de software de Contasys.
Amanda Durán, Contasys
El modelo de Contasis

El modelo que implementó Contasis, y en el que luego se certificó fue el CMMI nivel 3. Amanda Durán, gerente de la fábrica de software de la compañía, relató los detalles de lo que supuso para su compañía optar por ese modelo, y certificarse.

Hace un par de año, aproximadamente, el equipo de la fábrica de software -con el apoyo del resto de la compañía- decidió implementar el modelo CMMI. La iniciativa fue cofinanciada por el programa Innóvate del Ministerio de la Producción, quien apostó por algo que se hacía por primera vez, pues Durán fue la primera que se acercó a ellos en busca de financiamiento para un programa de calidad de software.

"No sabían de qué trataba, les explicamos, y decidieron ser parte de este proyecto, indicó Durán.

En primer lugar, explicó Durán, en CMMI no hay términos a medias, o se alcanza el 100% de las prácticas o uno no se certifica. No es posible, por ejemplo, certificarse alcanzando el 95% de las prácticas.

La empresa ya trabajaba con el marco de trabajo Scrum, pero Scrum no les proporcionaba todo lo que deseaban. Había entonces muchos vacíos que deseaban cubrir, y se decidió por implementar un modelo de calidad.

"La calidad nunca empieza en las áreas operativas, eso lo entendí cuando estuvimos trabajando con el equipo. La calidad siempre empieza desde arriba, porque necesitas todo el apoyo de arriba, indicó la ejecutiva.

En realidad, la fábrica trabaja con varios marcos de trabajo. Para los nuevos proyectos utilizan una versión modificada de Scrum -modificada de acuerdo con sus necesidades-, y utilizan Canvas para el mantenimiento. La decisión por CMMI iba a tener que complementarse con lo que ya venían utilizando. "CMMI nos ha definido el modelo de calidad a seguir y el proceso de mejora continua, detalló.

Normalmente, cualquier empresa que desarrolle software puede tener el nivel 1 de CMMI, pero ellos deseaban alcanzar el nivel 3. En el nivel 1 se afirma que la empresa tiene procesos impredecibles, poco controlados y reactivos; es decir, no están gestionados, el trabajo se realiza mediante el 'heroísmo' individual. En el segundo nivel, los procesos están caracterizados para proyectos y en ocasiones son reactivos; es decir, ya se tiene algo de gestión y se planifican las actividades.

El tercer nivel, que es el que deseaba alcanzar la compañía -y de hecho lo hizo- es un nivel en el que los procesos están caracterizados para la organización y son proactivos; es decir, todo ya está definido y se ejecutan planes. Contasis alcanzó el nivel 3 pero obviamente su meta -dentro de tres años- es alcanzar el nivel 5, donde existe un enfoque en la mejora continua y los procesos se encuentran optimizados y se actúa para mejorar las mediciones.

Durán afirmó que para logar el nivel 3 tuvo que cumplir con una serie de prácticas, cada una de las cuales tenían objetivos específicos. Entre esas prácticas se encontraban temas como la gestión de requisitos, la planificación de proyectos, el seguimiento y control del proyecto, las medidas y análisis, el aseguramiento de la calidad en el proceso y producto, entre otras.

El proceso de certificación se inició en diciembre del 2015 con un autodiagnóstico. Y aquí Durán recordó la evolución que se ha producido en su fábrica desde que se inició hace 10 años. Recordó, por ejemplo, que antes las planificaciones se realizaban con hojas de Excel, algo que ahora le parece sorprendente, pues ahora no podría concebir cómo realizar un proceso si no utilizara la herramienta Jira.

Del diagnóstico, y con la ayuda de un consultor, determinaron que se encontraban a un 25% de todas las actividades que les pedía un CMMI de nivel 3. Tuvieron, entonces, que comenzar a trabajar en el 75% que les faltaba.

En eso trabajaron aproximadamente 18 meses. Entre enero del 2016 y marzo del mismo año, realizaron una pre evaluación antes de lanzarse a la certificación. El consultor les dijo que aún le faltaba un poco menos de 8% para alcanzar el nivel, pero "que sí lo van a lograr. En tres meses vuelvo a certificarte o no, les dijo el consultor.

Luego el consultor volvió en mayo y durante 15 días hizo trabajar muy fuerte a todo el equipo. Hubo entrevistas diarias, preguntas, pero todos estaban listos para responder, a pesar de que no hubo un proceso de preparación para ello.

"No nos preparamos para la certificación, tenía que ser la foto de cómo estábamos en ese momento, y si estábamos mal, pues, estábamos mal, añadió Durán.

Había mucho que cambiar desde la primera evaluación, pero Durán reconoce que el cambio más importante se produjo en el propio equipo.

"Es la forma de trabajo, la forma de comunicación y la cultura organizacional lo que tiene que cambiar cuando alguien quiere implementar un modelo de calidad. El equipo tuvo que cambiar muchas cosas, estaban acostumbrados a no asumir la responsabilidad, y a partir de esta experiencia cada uno es responsable de lo que hace, reconoció Durán.

Además de la propia cultura del equipo, hubo cambios puntuales que se tuvieron que hacer para alcanzar la certificación como el registro de horas, las estimaciones, los versionados, la trazabilidad, la documentación, el seguimiento y control, entre otras.

Por ejemplo, ahora el equipo registra horas y saben que ese registro no es para controlarlos sino para obtener indicadores con los cuales podrán hacer estimaciones mucho más certeras, las cuales luego los van a ayudar. Durán recuerda que al principio su equipo no deseaba hacer registros, se resistieron, pero luego cambiaron.

Igualmente, ahora la trazabilidad en los requerimientos es clara, si alguien desea saber sobre algún requerimiento, Durán le puede decir casi inmediatamente el nivel de desarrollo que tiene en ese momento y el tiempo estimado en el que se entregará. Y eso es algo que les ha dado CMMI.

Incluso documentar -una tarea que no agrada a los desarrolladores- es ahora un acto más natural para ellos. El equipo ha entendido que la documentación sirve para, por ejemplo, no perder la ilación de lo ya hecho cuando uno de los desarrolladores abandona la compañía.

"Creo que hubo resistencia al cambio, pero al final todos entendimos que era lo que necesitábamos, finalizó Durán.