Ayer estuve en el encuentro tecnológico “Medidas y calidad del software”.

Las charlas fueron bastante interesantes. Destaco dos:

“Situación de la calidad del software en España: Estudios e Indicadores”

En esta charla Ignacio Caño (Inteco) Luna nos mostraba el último estudio realizado desde Inteco: un sondeo basado en encuestas a PYMES y grandes empresas. De él se desprendía el bajo conocimiento de las normas en cuanto a calidad, y proponía el conocimiento a través de certificaciones (en otras charlas se dijo exactamente lo contrario, en fin, son puntos de vista, veremos que depara el futuro), en cualquier caso el estudio realizado era bastante interesante.

“Métricas de la calidad del software”

Esmeralda Mancheño (Matchmind) nos presentó a uno de sus clientes, ISBAN. La responsable de calidad de ISBAN nos hizo partícipes del criticismo de la calidad en los productos orientados a la banca, donde los errores son tan caros que no pueden permitirse. Proponía la medición de todo tipo de parámetros como una forma de mejorar el producto tomando decisiones en función del resultado de estas mediciones. Me sorprendió una frase: “En ISBAN no tenemos presupuesto para la gestión de la calidad, el director dice que está todo pagado”. Supongo que un fallo en algún sistema informático del banco puede hacerles perder más dinero del que hayan invertido en 10 años en calidad…

Si tenemos por objetivo que un proyecto fracase estrepitosamente, no tenemos más que cumplir las siguientes directrices (o buenas prácticas) de forma escrupulosa:

1. No usar un sistema de control de versiones, lo mejor es que cada desarrollador trabaje en su propia máquina.
2. No documentar absolutamente nada, el propio código es la mejor documentación.
3. Cada desarrollador debe hacer lo que quiera, sin nadie que coordine su trabajo y sin ningún tipo de comunicación entre ellos.
4. Es fundamental que no se defina ningún tipo de prueba, y prohibir terminantemente el uso de sistemas de integración continua.
5. No compilar de forma frecuente, a lo sumo, una vez a la semana.
6. Si el proyecto comprende bloques funcionales independientes, es imprescindible no realizar ninguna prueba de integración, solamente se hará una, el día antes de poner la aplicación en producción.
7. Asegurar que nunca se sabrá quién hizo qué, de esta forma, a falta de documentación (véase punto 2), mantendremos los indices de inmantenibilidad en los valores deseados.
8. El proceso de despliegue de la aplicación debe ser lo más complejo posible, por supuesto indocumentado y ligado a la máquina en la que se desarrolló.
9. Y claro está, lo más importante, las palabras “Quality Assurance” jamás serán pronunciadas.