Certificación de Aplicaciones (Art. Completo)

¿El hombre es el único animal que tropieza dos veces con la misma piedra?
Seguro que cuando se acuño esta frase, todavía no existía la informática…

Después de más de 10 años en el mundo del desarrollo, creo que he visto casi de todo, y lo que no he visto, me lo han intentado vender. Reconozco que la revolución ha sido impresionante. Hemos visto emerger y desaparecer productos, empresas, paradigmas… sin embargo, hay un punto dentro de este mundo de constante cambio que ha seguido tozudamente constante: la cantidad de problemas que surgen, cuando temblando alguien se atreve a dar la orden final de pasar a producción una nueva versión o un parche de una aplicación.

Cuantas veces hemos escuchado “… hemos realizado un pequeño antes del paso a producción que solventaba un fallo y no se sabe como, ha introducido cuatro errores sobre funcionalidades anteriores…”

Realmente, cuando decimos que una aplicación está probada:

• ¿Alguien sabe “cuanto” está probada? (30% afirmativo)
• ¿Se están probando las áreas más críticas? (10% afirmativo)
• ¿Se ha asegurado que se mantiene el diseño original? (5% afirmativo)
• ¿Sabemos si el uso de la tecnología de base que se hace es suficientemente correcto como para no implicar un consumo masivo de recursos que degrada el sistema, independientemente del “hierro” que podamos meter? (10% afirmativo)
• ¿Alguien sabe si los cambios introducidos alteran los niveles de carga objetivo? Estos niveles de carga objetivo, ¿sobre que partes del sistema se están lanzado? (30% afirmativo)
• ¿Es posible garantizar la correspondencia entre las versiones del repositorio y las versiones en producción? (30% afirmativo)

Es curioso que casi todos los responsables de tecnología, consideren que se encuentran dentro del porcentaje que responde afirmativamente a estas preguntas. Sin embargo, cuando se entra al detalle de cada una de estas preguntas, aparecen los “peros”, que desembocan en que, desde una perspectiva práctica, la cobertura a estas preguntas es casi nula.

Para saber si se encuentra en esta situación, el mejor modo, no es iniciar una ronda de contactos internos para ver nuestra situación en cada uno de estos puntos, es más sencillo. Si usted se despierta en medio de la noche, y no es capaz de volver a conciliar el sueño porque empieza a pensar en cual es el estado real de un sistema en que se encuentra inmerso, sin duda, usted pertenece al “colectivo único” de responsables de TIC que “saben que no saben como van sus proyectos de sistemas”.

Por si no fuera poco enfrentarse a una bolsa de demanda de los usuarios que recurrentemente supera nuestra capacidad de ejecución y gestión de proyectos, un backlog que crece más rápido que decrece y un martilleo constante de los usuarios reflejando su descontento con la tecnología, añadamos el factor de incertidumbre de no tener la tranquilidad de saber el estado de nuestros sistemas de cara a los siguientes pasos a producción.

Para solventar esta problemática, hemos visto soluciones de todo tipo: metodologías, guías de desarrollo, normativas, directivas, oficinas de proyecto, etc.

Todo ello forma en cierta medida parte de la solución, pero estas soluciones, para poder atacar la problemática expuesta, implican un uso intensivo de recursos humanos, que en el mejor de los casos, no llegaría a ofrecer garantías, implicarían destinar recursos con altos conocimientos (y por tanto escasos) a tareas de revisión de bajo valor que implicarían tiempos de revisión prolongados…

Una solución “real”, pasa por automatizar todo el proceso de certificación de una aplicación. Este proceso de certificación, incluiría pasos como:

• Conectarse a un repositorio de versiones.
• Obtener la última versión.
• Compilarla (obligatorio para ser SOX compliance)
• Ejecutar las pruebas de la misma (unitarias, de navegación, de carga, etc).
• Determinar cuál es el grado de cobertura ofrecido por estas pruebas.
• Obtener índices de calidad.
• Detectar automáticamente errores y malas prácticas de programación.
• Comprobar si las partes más críticas del sistema están suficientemente probadas.
• Empaquetar y desplegar versiones.

En Aptivo Consulting, hemos implantado internamente este proceso para la certificación de nuestras aplicaciones e igualmente hemos implantado este enfoque junto a algunos de nuestros clientes, bajo la fórmula de Oficina de Certificación.

Esta Oficina de Certificación es la encargada de realizar todo el proceso descrito previo a los pasos a producción. Consideramos que uno de sus factores clave de nuestro enfoque, es que los productos utilizados son en su totalidad opensource/freeware, de manera que el coste recurrente para nuestros clientes es CERO.

Esto les posibilita poner el ciclo de certificación a disposición de sus proveedores, cosa que cuando utilizan productos comerciales, no hacen normalmente por los costes de licencias implicados. Cuando los proveedores no disponen de estos entornos de certificación, lo que sucede es que se detecta un “zurrón” de errores, justo antes de los pasos a producción (porque es el momento en que se utilizan las herramientas de pago con que cuentan), lo que nos pone de nuevo a los pies de los caballos, porque no hay tiempo para la corrección de todos los errores que se hayan detectado...

En definitiva, después de más de 10 años en el desarrollo, por fin he encontrado una solución al “insomnio de los sistemas”.

Una última reflexión. Para aquellos que se crean a salvo de esta problemática porque “nosotros vamos a construir una arquitectura de referencia para nuestros sistemas/proveedores, así que este no será más nuestro problema”… agarraros a la silla con celofán, porque se va a mover y mucho…

Cuando construyes una arquitectura de referencia, no estará siempre “quieta” y más pronto que tarde, tendrás que evolucionarla y modificarla. Esto implica que, de alguna manera tendrás que dar compatibilidad hacia atrás y asegurar que las aplicaciones que la nueva versión mejora la anterior y que sobre todo, que las aplicaciones que ya la están utilizando, no harán “crack” cuando despliegues las nueva versión.

En definitiva, que la arquitectura de referencia deberá estar bajo el control de la certificación de aplicaciones y no como un objetivo más, sino como un objetivo prioritario.

Otros enlaces de interés:

http://headrush.typepad.com/creating_passionate_users/2006/03/ultrafast_relea.html

http://headrush.typepad.com/creating_passionate_users/2006/01/death_by_riskav.html

http://martinfowler.com/articles/continuousIntegration.html

david.garcia@aptivoconsulting.com