¿Cómo se mide la calidad en el software?

¿Qué es la calidad en el software?¿Se puede medir?¿Cómo?
Cuando decimos que para nosotros la calidad es muy importante, ¿a que nos referimos?

En primer lugar quiero puntualizar las siguientes afirmaciones de dicho artículo:

• Directivos y personal de Márketin dan más importancia al número de características que tiene un software que a la calidad, porque la calidad no se puede poner en un anuncio o en una oferta.
• Algunos directivos al mando de empresas que construyen software caen en el error de pensar en la producción de software desde los parámetros habituales en otras industrias. La producción de software es muy diferente, es un proceso creativo no un proceso manufacturero. (Léase ejemplo de bolígrafos en dicho artículo)
• La principal diferencia cuando ‘fabricamos’ software es que la calidad no es opcional, no puedes elegir fabricar software de baja calidad y rebajar el precio. Puedes restarle funcionalidad, pero no calidad.
• Nadie recuerda a quien hizo un buen software (de calidad), pero nadie olvida el que fallaba constantemente (¿os acordáis de los pantallazos azules del w95?)
• Paradójicamente, y esto es un hecho, es que añadir calidad a nuestro software, al contrario de lo que puede parecer a primera vista, reduce los costes de desarrollo y acorta los plazos.

Y por último quiero citar un párrafo textualmente:

“He visitado empresas, con grandes carteles en recepción del estilo “La calidad es nuestra esencia” o “La calidad al servicio del cliente” y con todas las certificaciones habidas y por haber de ‘calidad’ que no tienen ni un solo especialista en calidad del software, ni un solo especialista en probar aplicaciones. Y no, los desarrolladores, no son expertos en calidad y pruebas.”

Bien, dicho esto, y reflexionado sobre ello, podemos afirmar que en otros entornos percibimos la calidad perfectamente, cuando probamos un coche de gama alta, percibimos la calidad, ¡y no tenemos conocimiento del proceso de producción!, pero si palpamos la calidad, por ejemplo (y siguiendo con el ejemplo del coche), cuando aceleras sientes rendimiento, cuando tomas una curva y percibes estabilidad, cuando frenas, notas seguridad… realmente son indicadores (“métricas”), que se podrían medir y poner una puntuación de calidad a cada vehículo.

¡¡Vamos a intentar medir la calidad del software!!

Primero vamos a intentar identificar los factores que desde un punto de vista externo definen la calidad del software, no me refiero a los procesos internos de desarrollo, como pruebas unitarias, gestión de cambios, calidad del código… no!! me refiero a lo que se percibe, una vez el software está terminado, implantado y en producción, lo que nota un usuario. Intentemos pensar (como ejemplo para evaluar la calidad) en un producto software…, uno de los primeros que desarrollamos o probamos, así veremos mejor su evolución y evaluaremos la calidad teniendo en cuenta factores temporales.

• Satisfacción del cliente (se suelen hacer encuestas para obtener este dato)
  • Interfaz de usuario (usabilidad, accesibilidad, facilidad de manejo, curva de aprendizaje, diseño…)
  • Rendimiento de la aplicación, Seguridad, Despliegue, Actualizaciones, Integración con sistemas…
  • …
• Número de bugs en producción (bugs encontrados y la importancia de los mismos, se podría incluir en satisfacción del cliente)
• Rentabilidad económica (%, precio de venta – coste de desarrollo)
  • Este factor no es relevante para el usuario, pero tiene mucha información subliminal y por eso lo quiero incluir. Para mí está muy ligada la rentabilidad a la calidad, por muchas cosas como la (la buena estimación, buena planificación, gestión, previsión, pruebas, buena arquitectura, buen código, pocos bugs, aplicación modular y bien preparada para el cambio…) por ello lo quiero incluir como factor a tener en cuenta, aunque no le afecte al cliente diréctamente, si indirectamente, ya que si el software es rentable, el cliente obtendrá un mejor servicio, soporte, mantenimiento… en definitiva un buen producto…(bueno este es otro tema)
• Tiempo de vida por cliente (años que el software está funcionando)
  • El usuario quiere algo que le satisfaga y si (por ejemplo) en el banco de Cuenca tienen una aplicación Cobol, desarrollada hace 15 años, que les satisface las necesidades actuales, desde luego que es un aplicativo con calidad. Al igual que un coche, de hecho es muy típico ver mercedes de hace 20 años rodando a diario por las carreteras.
• Número de clientes (clientes que tiene el software implantado y en producción)
  • Otro factor importante es el número de clientes que tiene un software, (no voy a poner más ejemplos de coches), por ejemplo existen productos software que están muy estandarizados (SAP, Subversion, PhotoShop, Office…) es software muy popular, muy testeado, en diferentes entornos y condiciones, y yo creo que eso es un síntoma de calidad.

Estos son los factores que se me han ocurrido, seguro que hay muchos mas (espero vuestros comentarios ).

Una vez apuntados los factores vamos a medir la calidad, … ¿qué?¿cómo?… si si, vamos a medir la calidad…, de las propiedades del software de calidad, podemos sacar métricas y de esas métrica (de una manera muy simple y lógica) vamos a preparar una primera versión de la fórmula:

Por si alguién no se ha dado cuenta está fórmula me la acabo de sacar “de la manga”, pero yo creo que tiene los factores clave para darnos una medida de la calidad que percibe un usuario de software.

Es tan dificil medir la calidad…, no cabe duda de que si diésemos con una fórmula válida, nos haríamos multimillonarios, pero la calidad no es algo tan trivial, que se pueda medir en una escala de 0 a 10… la calidad tampoco es binario o 0 o 1, o se tiene o no se tiene, es algo mas complejo, la calidad es el día a día, el trabajo meticuloso, de trabajo organizado y estructurado, probado y documentado, orientado a la petición de cambio del cliente y a la facilidad para llevar a cabo el cambio en el equipo de desarrollo, la calidad no es CMMI o SCRUM, aunque si es cierto que cualquier metodología actual sienta las bases para desarrollar un producto de calidad.

Por todo esto y para terminar, decir que la calidad no se puede medir, pero los factores que afectan a la calidad si se pueden identificar y mejorar… por lo tanto la calidad está en la mejora diaria, en cada uno de los eslabones del desarrollo de software, en la buena gestión, en cada línea de código, … todos deben aportar calidad, desde la codificación (tratando de documentar el código, haciendolo, legible, mantenible…), hasta la implantación del producto (haciendo un aterrizaje suave sobre un entorno de pre-producción, pasar de nuevo el plan de pruebas), hasta incluso después de la puesta en producción aportando al cliente un buen bug-tracker y comunicación continua…

¿Entonces, que tengo que hacer para aplicar calidad a mis desarrollos? … ¡mejorar! Mejorar en todos y cada uno de los procesos, hitos y tareas de la producción de software. (Y para decir esta frase el rollo que he soltado…)
PD: Si has tenido la paciencia de leer hasta el final, ¡¡enhorabuena!! estás reálmente interesado en mejorar y ese es el requisito fundamental para aplicar calidad al software.

Fuente:

• Rodrigo Corral

• Miguel Sierra