Mtricas posiblemente engaosas

El costo de la calidad y el costo de la mala calidad

Pablo Straub AgileShift

Todos sabemos que la calidad tiene un costo, pero cunto es? Si bien existe una definicin estndar de costo de la calidad para el desarrollo de software, esta mtrica puede resultar engaosa si no se interpreta en su debido contexto. De hecho, un uso descontextualizado de esta mtrica desalienta aumentos de productividad.
Medir el costo de la calidad resulta fundamental en un programa de mejoramiento de calidad. Si la calidad no tiene costos asociados, por qu debiramos tener un programa de calidad en primer trmino? Pero todos sabemos que la mala calidad s tiene costos, tanto por el costo de correccin como por los problemas que le acarrea a nuestros clientes, que bien podran dejar de serlo.

Definicin del costo de la [mala] calidad del software

El costo de la calidad tiene dos componentes: lo que invertimos en obtener buena calidad y lo que pagamos por no lograrla. La primera componente es decidida por nosotros y controlada; la segunda no la decidimos sino que se manifiesta en las fallas de nuestro producto. Invertimos en tener buena calidad mediante prevencin (evitar errores) y evaluacin (verificar que no tenemos errores). Por otro lado, las fallas pueden ser de dos tipos: internas (las que encuentran los desarrolladores) y externas (las que encuentran los clientes). Esto se resume en el modelo PEF (en ingls PAF, prevention, appraisal & failure) mostrado en la figura.

El Modelo PEF

PREVENCIN

EVALUACIN

FALLA
Interna Externa

www.AgileShift.cl

1 de 5

2006 Pablo Straub

Las frmulas para definir el costo de calidad y el costo de la mala calidad son muy sencillas y usualmente estn basadas en medir los costos en horas. En general interesa no slo el esfuerzo absoluto de la calidad, sino el esfuerzo relativo de la calidad en relacin al esfuerzo de desarrollo (ver Recuadro 1).

Recuadro 1: Frmulas del costo de la calidad Si llamamos P, E, Fi, Fe y C a las horas totales usados en el proyecto para actividades categorizadas como Prevencin, Evaluacin, Fallas internas, Fallas externas y Creacin, respectivamente, tenemos que: Esfuerzo de Calidad = EoQ = (P+E+ Fi+Fe) Costo de Calidad = CoQ = (P+E+Fi+Fe) / (P+E+Fi+Fe+C) Esfuerzo de Mala Calidad = EoPQ = Fi+Fe Costo de Mala Calidad = CoPQ = (Fi+Fe) / (P+E+Fi+Fe+C)

Ejemplo En un proyecto se usaron 1280 horas de las cuales 280 horas se usaron en adminis tracin, 60 en entrenamiento para el proyecto, 40 en adaptaciones del proceso para el proyecto, 420 en creacin, 50 en inspecciones, 160 en pruebas, 30 en correcciones debido a inspecciones, y 150 en debugging antes de la entrega, y 90 en correcciones finales despus de la entrega. Quedan 1000 horas en actividad del proyecto propiamente tal descontadas las horas de administracin. Entonces tenemos: P=60+40, E=50+160, Fi=30+150, Fe=90, C=420, EoQ=580, CoQ=58%, EoPQ=270, CoPQ=27% y Overhead=280/1280=21,9%.

Interpretacin
Lo primero que llama la atencin de las frmulas de arriba es que nos olvidamos completamente de los costos no incurridos por el equipo de desarrollo. Esto es tan usual como es peligroso. La versin cnica es que es muy difcil medir los costos como consecuencia indirecta de la mala calidad de modo tal que es ms fcil olvidarse de ellos. La versin ms pragmtica es que las mtricas y el anlisis deben interpretarse en el contexto de la organizacin de software y por eso slo se refieren a ella. En cualquier caso, si se usan este tipo de mtricas siempre hay que recordar que representan una versin muy parcial de la calidad. De hecho hay varios factores asociados al costo de la mala calidad que no miden, como prdida de reputacin, insatisfaccin del cliente, costos incurridos por el cliente, ventas futuras no realizadas, etc. En lo que sigue supondremos que efectivamente usaremos estas mtricas y que al interpretar los nmeros resultantes seremos consistentes con ello. Una pregunta obvia es qu valores de costo de calidad son razonables. Como toda buena pregunta, la respuesta es: depende. Depende del tipo de software, del equipo, de la metodologa, y de muchas otras cosas. No nos vamos a escudar en el depende para no dar ningn valor, sino que slo lo usaremos para advertir al lector que hay mucha variacin. Tiene sentido para una organizacin con altos niveles de calidad tener valores de CoQ entre 25% y 50% y de CoPQ entre 3% y 10%. (El ejemplo de arriba corresponde a una www.AgileShift.cl 2 de 5 2006 Pablo Straub

organizacin ficticia con un nivel de madurez de procesos relativamente bajo.) Si bien en la literatura se postula que organizaciones con alto nivel de madurez (CMM nivel 5) debieran tener un CoQ menor que 20% ese nmero no lo he visto y me cuesta creer que se puede alcanzar. Despus de todo hay que hacer inspecciones, entrenamiento, pruebas, correcciones, etc. En un ambiente de desarrollo razonablemente maduro se debiera tener objetivos asociados a las mtricas de software. En particular, tiene sentido un objetivo del tipo CoQ<40% y CoPQ<5%. Si se estn introduciendo nuevas tecnologas o metodologas, es posible que el primer nmeros sean un ms alto debido a que todo el entrenamiento se considera prevencin.

Cmo medir en forma eficiente

La forma estndar de medir el costo de la calidad en el desarrollo de software es registrar el esfuerzo en horas dedicadas a actividades asociadas a la calidad. Esto es muy barato si ya se cuenta con un sistema de reporte de horas de proyectos. En ese caso, a cada actividad del proyecto se le asigna una categora respecto del costo de la calidad (ver Recuadro 2). Los miembros del proyecto reportan las horas dedicadas a cada actividad con el sistema usual, y a partir de eso se suman las horas dedicadas en el proyecto para cada categora. Esto es relativamente simple y se puede implementar con un sistema a la medida, con extensiones al sistema de reporte de horas, o simplemente con una planilla Excel que se alimenta de los informes del sistema de reporte de horas. Como en todo plan de mtricas, es fundamental que las mtricas no sean usadas para la evaluacin o compensacin del personal. En caso contrario, los nmeros sern cocinados o por lo menos estarn sesgados. Pero empleados motivados a entregar mtricas que reflejen fielmente la realidad no son suficientes. Claro que no es tan simple saber cmo clasificamos correctamente una actividad en las categoras de costo de calidad. Recuadro 2: Categoras del costo de la calidad Prevencin: actividades para evitar correcciones (ejemplos, entrenamiento asociado al proyecto, mejoras de procesos para el proyecto, recoleccin y anlisis de mtricas). Evaluacin: actividades para determinar la calidad de los entregables (ejemplos, crear casos de prueba, inspecciones de cdigo, auditoras). Fallas internas: actividades para corregir entregables (ejemplos, modificaciones a un documento despus de una inspeccin, debugging). Fallas externas: actividades para corregir productos ya entregados (ejemplos, correccin de defectos de productos instalados, correcciones de datos). Creacin: actividades para hacer los entregables del proyecto (ejemplos, levantamiento de requerimientos, codificacin). Otro: actividades no relacionadas con los entregables del proyecto (ejemplos, reporte del estado del proyecto, actividades administrativas).

Analicemos el trabajo involucrado en determinar los requerimientos de software. Las entrevistas, escritura de requisitos, anlisis de requisitos son claramente actividades de Creacin. Una revisin por pares es claramente una actividad de tipo Evaluacin. Pero qu pasa con el tiempo que el autor del documento de requisitos dedica a revisar su propio trabajo

www.AgileShift.cl

3 de 5

2006 Pablo Straub

mientras lo est completando? Esta actividad tiene tanto creacin como evolucin, y en condiciones normales ser considerada parte de la creacin.

Mtrica peligrosa
Si la gerencia plantea objetivos de reduccin de las mtricas de costo de calidad (CoQ) y costo de la mala calidad (CoPQ) pueden producirse algunos vicios, especialmente si las mtricas estn ligadas a la evaluacin del personal. El problema es que si el autor de un documento no quiere tener fallas internas podra dedicar demasiado tiempo a las revisiones personales informales, es decir, el autor dedica ms tiempo a revisar en forma personal para asegurar una inspeccin triunfal. Este tiempo extra ser medido como creacin. Veamos qu pasa con las mtricas: ha aumentado el tiempo de creacin y ha bajado el tiempo de falla, lo que genera un CoQ y un CoPQ mucho mejor. Pero en realidad el tiempo de las revisiones personales del autor debi haberse medido como evaluacin, empeorndo la mtrica CoQ en lugar de mejorarla. Consideremos otro ejemplo ms extremo. Un desarrollador utiliza una herramienta que le permite programar mucho ms rpidamente (ejemplo, parte del cdigo lo produce un generador de cdigo). La herramienta no ayuda ni perjudica a los procesos de pruebas y revisiones. En este caso, la introduccin de la herramienta, si bien no modifica el esfuerzo de calidad EoQ, s aumenta el costo de la calidad CoQ por tener una base menor de comparacin.

La raz del problema

Veamos ahora un problema que est en el meollo del asunto: qu son los entregables? Ms importante an qu entregables debiramos hacer? y qu entregables realmente agregan valor al cliente? Estas cuestiones aparentemente triviales son fundamentales. Hay cuatro razones por las que crear un entregable: agrega valor directo al cliente (ejemplo, el cdigo, el manual del usuario), agrega valor indirecto al cliente (ejemplo, el documento de requerimientos), sirve de paso intermedio para crear otro entregable (ejemplo, diseo detallado), y est en la lista especificada por contrato o por proceso (ejemplo, carta Gantt). La forma en que se aplica esta mtrica es suponer que todas las actividades de creacin de documentos son iguales. Pero esto es incorrecto: slo debiera considerarse creacin aquello que agrega valor al cliente. Es poco claro que efectivamente se agregue valor al cliente con documentacin detallada. Normalmente el beneficio de parte de la documentacin es ms bien prevenir errores en el cdigo antes que dar un valor agregado al cliente. Si para un documento ese fuera el caso, entonces todo el esfuerzo asociado a hacer el documento debiera considerarse prevencin y no creacin. Pero eso no es todo: si hemos creado una funcionalidad que no era til para los clientes (en ISO/IEC 9126 estos requisitos se llaman requisitos no pertinentes), entonces debiramos descontar el esfuerzo de su creacin porque en realidad su desarrollo no fue creacin del proyecto sino tiempo malgastado. Profundizando un poco ms en el concepto de valor agregado al cliente, ocurre que una buena parte de la funcionalidad no se usa o se usa muy infrecuentemente, de modo que en estricto rigor no agrega valor, pero eso es materia de otra columna.

www.AgileShift.cl

4 de 5

2006 Pablo Straub

Medir la productividad
Debemos entonces abandonar la mtrica de costo de calidad? No, pero s debemos complementarla con alguna medida de productividad. Complementada con una medida de productividad (es decir produccin dividida por esfuerzo), entonces s tiene sentido usar las mtricas de costo de calidad. Algunas medidas son simplemente nmero de lneas de cdigo y pginas de documentacin. Otras medidas cuentan puntos de funcin o alguna mtrica similar, que tiene la ventaja que se acerca un poco ms al problema y depende menos de la tecnologa usada. Desde ese punto de vista, una mtrica ideal sera algo as como requerimientos de usuario implementados a satisfaccin del cliente. En resumen, si bien el costo de la calidad es muy importante, el costo del producto lo es ms. Medir slo el costo de la calidad puede tener impactos negativos en el costo del producto.

www.AgileShift.cl

5 de 5

2006 Pablo Straub