¿Cómo se mide la calidad?

... O más bien debería ser más específico: ¿cómo se mide la calidad del software?

Parece ser que la calidad es el atributo favorito a la hora de ser incluído en propuestas y propaganda variada de los productos software, pero nunca nos hemos preguntado ¿qué es la calidad? ¿cuánta calidad tiene? ¿Si no puedo medir la calidad de un producto para qué me sirve que lo pongan en un folleto o hablen de él los comerciales? (si hasta los terremotos tienen una medida universal gracias al señor Richter).

Hace poco leía un blog y me sorprendía la frase: "no puedes elegir fabricar software de baja calidad y rebajar el precio. Puedes restarle funcionalidad, pero no calidad". Por desgracia para el mundo del desarrollo de software, no es así. Claro que se puede ahorrar calidad. Simplemente, eliminando las actividades que le aportan y aseguran esa calidad.

¿Dónde está la calidad?:

• En arquitecturas conocidas, probadas y para las que se han obtenido datos de experiencias (buenas prácticas, problemas a evitar, cómo mejorar en el futuro, etc.) Es lo que se conoce como mejora continua.
• En las metodologías de trabajo conocidas y probadas. Y no sólo hablo de desarrollo. También de repositorios de documentos, tener claro quién es el responsable de qué...El tener el control de qué hay, dónde está, cómo acceder a ello, y cómo usarlo.
• En las pruebas del software antes de la entrega al cliente.
• En las pruebas del software en la implantación.
• En las auditorías de calidad.
• En las auditorías internas del equipo de desarrollo.
• En las revisiones entre pares (sí, sí, las Peer Review famosas).

¿Cómo medir la calidad? Pues midiendo la calidad de nuestro proceso de desarrollo:

• Calidad del análisis: ¿cuántos requisitos se han modificado? ¿cuántos se han añadido? ¿cuántos se han eliminado?
• Calidad del diseño: ¿cuántos cambios se han producido en el diseño técnico?
• Calidad de la arquitectura: ¿cuántos cambios de arquitectura se han producido?
• Calidad del desarrollo: ¿cuántos defectos se han detectado en pruebas unitarias?
• Calidad de las pruebas: ¿cuántos defectos ha detectado el cliente en producción vs defectos encontrados en pruebas en general? ¿cuál es el ratio nº defectos encontrados vs horas invertidas en pruebas?

¿Y la calidad del producto? Pues aunque está relacionado, tendríamos otros factores:

• Tiempo que lleva el cliente usando el producto. En mi opinión no es significativo. Por razones varias, el cliente puede verse obligado a usar un pésimo software. Realmente el problema está en la competencia y en el precio. Si es suficientemente barato un software alternativo, poco importará la calidad de nuestro software, es probable que el cliente acabe actualizándolo por otro distinto, si los costes encajan.
• Satisfacción del cliente. Bueno, volvemos a la cruda realidad. ¿Quién es el cliente? ¿El director general? ¿el que compró el software? ¿El jefe de departamento que lo usa? ¿Los usuarios finales? Al final, la satisfacción es difícil de medir. Bueno, para eso podéis leer mi anterior blog sobre encuestas de satisfacción.
• Número de fallos en producción. Realmente no sólo es una medida de calidad del software, sino de su proceso de desarrollo.
• Número de clientes. Pues ahora mismo se me ocurren unos cuantos ejemplos de software vendido por millares (por no decir millones), y de calidad pésima. Al final, el número de clientes lo deciden una serie de factores ajenos a la calidad: precio, esfuerzo comercial, renombre de la marca comercial, etc.
• Número de años en uso. Uf. Por esa regla de 3, tendríamos que el software hecho en cobol en los años 80 debía de ser de calidad asombrosa, porque se ha usado hasta hace muy poco, o sigue en uso. A la hora de la verdad, este factor no depende de la calidad, sino de la competencia, de la facilidad de actualizar el producto. Si encontramos repuestos de ruedas, las cambiaremos fácilmente. Si no encontramos repuestos, pues...habrá que fastidiarse y seguirlos usando (independientemente de su calidad).

Lo importante es destacar que no tendremos calidad del producto basándonos únicamente en tener equipos de personas buenas y maravillosas, todos senior y super-motivados, y blah, blah. La calidad se consigue a través de un método, proceso y control. Quien confunde el control con desconfianza en el equipo, tiene un problema (y más vale que se lo haga mirar).

El siguiente link está en la línea de lo que digo, aunque hay varios argumentos en los que no estoy 100% de acuerdo (ojo, no digo que él esté equivocado):
http://geeks.ms/blogs/msierra/archive/2008/08/25/_BF00_C_F300_mo-se-mide-la-calidad-en-el-software_3F00_.aspx