Control de la calidad, aseguramiento de la calidad y calidad total en el desarrollo de software

0
16030

0. Índice de contenidos.

1. Introducción

Ayer estuve hablando en el evento XPDay y, como sólo disponía de media hora, y me enrollo con facilidad, no pude explicar como quería algunas de las transparencias y aprovecho ahora para hacerlo.

2. Control de calidad

Cuando se construye un proyecto de lo que sea, aunque centrémonos con el software, podemos comprobar la calidad al final del proyecto. Parece evidente que si se encuentra un error y ya hay plazos comprometidos con terceras partes (como campañas de marketing), si hay algún error va a ser complicado poder reaccionar. Estamos acostumbrados a zafarranchos de última hora con decenas de personas haciendo un sobre-esfuerzo y sacrificando la calidad…

Para evitar sorpresas al final del proyecto se podrían establecer controles de calidad en puntos intermedios. Mejor todavía, si se hace en bases regulares. Esto, al menos, ayuda a detectar carencias formativas importantes.

Es de esperar que deberíamos controlar aquellos puntos que previamente hemos definido. Imagina que subcontratamos un proyecto sin especificar previamente los criterios de aceptación y luego sorprendemos al proveedor con miles de condiciones… eso provocará un conflicto. Por tanto, deberíamos diferenciar en nuestro vocabulario el concepto "planificación de la calidad" y "control de calidad"

3. Aseguramiento de la calidad

El control de la calidad al final, por si mismo, parece insuficiente. Parece lógico que el propio proceso de construcción de software debería disponer de unos procedimientos que garanticen que la calidad está integrada, lo que vamos a llamar medidas de "aseguramiento de la calidad".

Para mi, las medidas de aseguramiento de la calidad tiene que estar a tres niveles:

1 – Gestión de la configuración y técnicas de XP, entre las que incluimos :

  • Uso eficiente de repositorios de código, aunque haya un sólo programador.
  • Desarrollo en base a TDD: primero hacer los test y luego los programas para tener garantías de que no rompemos cosas al arreglar otras. Lo podríamos sofisticar con BDD.
  • Definición del ciclo de vida del proyecto externo a herramientas particulares:
    • Etiquetado, extracción de código, compilación, empaquetamiento, despliegue, ejecución de pruebas, obtención de métricas de calidad.
  • Uso de integración continua: para que todo lo anterior se haga cada vez que se cambia un fuente, sin intervención humana.
  • Aplicación de técnicas avanzadas de desarrollo OOP, patrones de diseño y de refactorización.

Es importante destacar que podemos obtener métricas automáticas:

  • Porcentaje de líneas duplicadas.
  • Complejidad del código.
  • Porcentaje de código cubierto por test automáticos.
  • Nivel y criticidad de ruptura de reglas generales y particulares.
  • Gráfica de evolución de roturas de test automáticos y no compilaciones automáticas.

2 – Metodologías ágiles

El agilismo está siendo una revolución en la industria porque proporciona una ventaja importante:

  • Descomponer un problema grande en unidades manejables.
  • Involucrar a negocio desde el principio en la definición y priorización.
  • Transmitir la necesidad a los equipos de adquirir una técnica de estimación.
  • Trabajar en ciclos cortos con presentación regular de resultados completos a cliente.
  • Obtención de realimentación por parte de los usuarios.
  • Mantenimiento del pulso del equipo con reuniones diarias.
  • Enfoque en la mejora continua con retrospectivas y talleres.

Obtenemos automáticamente métricas de:

  • Velocidad de desarrollo del equipo.
  • Avance global del proyecto.
  • Desviación entre estimaciones y realidad: lo que puede ayudar a aprender a mejorar las técnicas de estimación.

3 – Frameworks y arquitecturas:

Aunque el desarrollo informático cambia constantemente hay componentes, de más o menos nivel, que se van constituyendo como estándares de facto en la industria porque solucionan de un modo estándar decenas de problemas. Si desarrollamos soluciones a medida tenemos que invertir tiempo en que mejoren. Si usamos elementos utilizados y desarrollados por miles de personas, sin hacer, nada estos evolucionan y se adaptan a nuevas necesidades.

Parece sensato al menos conocerlos para determinar su idoneidad al aplicarlos a un problema específico.

Muchos desarrolladores simplemente los descartan por la falta de control que les provoca no haberlos construido ni poder seguir sus cambios. Esto puede ser un síntoma de inmadurez o un exceso de individualismo. Un grupo de profesionales puede tener un conocimiento general de todos los componentes y cada individuo especializarse en uno de ellos. Con una buena gestión del conocimiento, en el día a día, un equipo puede ser extremadamente eficiente. El conocimiento es demasiado basto como para heroicidades.

Tampoco está mal recordar que muchos buenos profesionales tienen prejuicios contra los frameworks porque mucha gente "apaga su cerebro", sin querer entender su funcionamiento de un modo profundo, creando unos graves problemas en una madeja todavía más gorda que si no se usasen.

He aquí algún ejemplo de piezas estándar que podemos utilizar en proyectos Java.

Cuando empezamos a medir podemos detectar puntos de mejora. Eso sí, las métricas no nos pueden esclavizar porque son un medio y no un fin en si mismo.

4. Mejora continua y calidad total

No debemos olvidar que para negocio muchas veces las áreas de tecnología son esos reductos de frikis a los que nadie entiende, que siempre gastan más de lo que se espera, ponen pegas por hacer más cosas en paralelo, no saben reportar en la forma e inmediatez deseada, se retrasan y rompen cosas al arreglar otras siendo poco fiables. Esto ha sido un gran argumento para descapitalizar las empresas con outsourcing descomunales.

Hay que comprender que no sólo hay que hacer un buen trabajo técnico desde nuestra perspectiva, sino que hay que satisfacer las necesidades, en los aspectos anteriores, de los patrocinadores: de negocio. Sobre todo si queremos conservar nuestros puestos de trabajo 😉

El responsable de tecnología tiene que gestionar: si no se manejan números no se está gestionando y esto se debe hacer en muchos frentes:

  • Manejar un porfolio de proyecto y tareas críticas, y disponer de mecanismos sencillos para comunicar. El agilismo proporciona métricas, y mejor todavía, cercanía con negocio que sabe exactamente cómo está el proyecto porque están dentro de él.
  • Tomar medidas correctoras en tiempo tempranos: las métricas de calidad automáticas ayudan a captar olores. Las métricas ágiles también.

Los técnicos tienen que ponérselo fácil a los gestores no viendo esta gestión como un enemigo, sino como una imperiosa necesidad. Lo ideal es contar con unos indicadores numéricos clave (KPIs) para ayudar en la gestión: pocos pero útiles. Estas métricas deben integrar situación de proyectos, niveles de calidad y costes.

Cuando alguien me dice que prefiere un lenguaje respecto a otros porque su curva de aprendizaje es mejor cuanto menos le miro con caras raras, porque el lenguaje es sólo una parte, importante, pero una parte.

Que una persona aprenda a resolver problemas con un lenguaje es sencillo: semanas o meses.

Para que un equipo de gente trabaje como un todo, con fiabilidad y solvencia como el que comentamos, hacen falta muchos años en un entorno disciplinado, eso diferencia profesionales. Eso diferencia empresas.

Debemos recordar que los costes de software suelen repartirse en un 20% su construcción inicial y un 80% para el mantenimiento, porcentajes que parecen argumentos suficientes para cuidar su calidad y mantenibilidad.

Si habéis visto la película 300 … la fuerza está en el equipo disciplinado, entrenado y acostumbrado a luchar juntos. 🙂

Dejar respuesta

Please enter your comment!
Please enter your name here