ensayo

¿Cómo se mide la calidad?

Parece ser que la calidad es el atributo favorito a la hora de ser incluido 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?
Hace poco leía un blog y mesorprendí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 lasque 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ómousarlo.
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 hanmodificado? ¿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 defectosencontrados 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 yen 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 calidadpé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 lacalidad, 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,...