EJERCICIO PRÁCTICO DE DIAGRAMA DE PARETO

Está usted interesado en analizar los principales problemas a los que se

enfrentan los empleados del Hospital La Alegría de la Huerta. Para ello ha
decidido realizar, en primer lugar, un diagrama causa-efecto para
posteriormente aplicar un diagrama de Pareto. Como primer ha realizado un
conjunto de entrevistas con empleados y mandos del hospital.

En la presente tabla se muestran los resultados obtenidos:

Problemas principales Frecuencia

Las políticas de la empresa requieren demasiada información 3
Las políticas exigen procedimientos complicados 3
Demasiada burocracia 7
Presupuestos muy limitados 8
Cuadrantes inadecuados 42
Políticas inadecuadas 6
El personal sanitario tiene demasiadas tareas en casa 7
El personal sanitario tiene otros trabajos 15
El personal sanitario carece de puntualidad 21
Los empleados del hospital no tienen suficiente formación 6
Los empleados no están suficientemente motivados 12
El personal sanitario se muestra despreocupado 4
El personal sanitario no sigue el plan de trabajo 59
No hay suficiente colaboración entre los empleados del hospital 8
Los métodos utilizados están ya obsoletos 28
Habría que mejorar tecnológicamente el hospital 10
Los procedimientos requieren mucho tiempo 30

Se le pide, a partir de la información proporcionada, que elabore, en primer

lugar, un diagrama de causa-efecto y, posteriormente, un gráfico de Pareto.
¿Como se interpretaría?
Métricas posiblemente engañosas

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

Pablo Straub
AgileShift

Todos sabemos que la calidad tiene un costo, pero ¿cuánto es? Si bien existe una
definición estándar de costo de la calidad para el desarrollo de software, esta
métrica puede resultar engañosa si no se interpreta en su debido contexto. De
hecho, un uso descontextualizado de esta métrica 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é debiéramos tener un programa de calidad en
primer término? Pero todos sabemos que la mala calidad sí tiene costos, tanto por el costo de
corrección como por los problemas que le acarrea a nuestros clientes, que bien podrían dejar
de serlo.

Definición 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 prevención (evitar errores) y evaluación (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 inglés PAF, prevention, appraisal & failure) mostrado en la figura.

El Modelo PEF

PREVENCIÓN EVALUACIÓN

FALLA
Interna Externa

www.AgileShift.cl 1 de 5 © 2006 Pablo Straub

Las fórmulas para definir el costo de calidad y el costo de la mala calidad son muy sencillas y
usualmente están basadas en medir los costos en horas. En general interesa no sólo el esfuerzo
absoluto de la calidad, sino el esfuerzo relativo de la calidad en relación al esfuerzo de
desarrollo (ver Recuadro 1).

Recuadro 1: Fórmulas 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 Prevención, Evaluación, Fallas internas, Fallas
externas y Creación, 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­
tración, 60 en entrenamiento para el proyecto, 40 en adaptaciones del proceso para el
proyecto, 420 en creación, 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 después de
la entrega. Quedan 1000 horas en actividad del proyecto propiamente tal descontadas las
horas de administración. 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%.

Interpretación
Lo primero que llama la atención de las fórmulas 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 versión cínica es que es muy difícil medir los costos como consecuencia
indirecta de la mala calidad de modo tal que es más fácil “olvidarse” de ellos. La versión más
pragmática es que las métricas y el análisis deben interpretarse en el contexto de la
organización de software y por eso sólo se refieren a ella. En cualquier caso, si se usan este
tipo de métricas siempre hay que recordar que representan una versión muy parcial de la
calidad. De hecho hay varios factores asociados al costo de la mala calidad que no miden,
como pérdida de reputación, insatisfacción del cliente, costos incurridos por el cliente, ventas
futuras no realizadas, etc.
En lo que sigue supondremos que efectivamente usaremos estas métricas y que al interpretar
los números 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
metodología, y de muchas otras cosas. No nos vamos a escudar en el depende” para no dar
ningún valor, sino que sólo lo usaremos para advertir al lector que hay mucha variación.
Tiene sentido para una organización 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

organización 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 número no lo he visto y me cuesta creer que se puede
alcanzar. Después de todo hay que hacer inspecciones, entrenamiento, pruebas, correcciones,
etc.
En un ambiente de desarrollo razonablemente maduro se debiera tener objetivos asociados a
las métricas de software. En particular, tiene sentido un objetivo del tipo CoQ<40% y
CoPQ<5%. Si se están introduciendo nuevas tecnologías o metodologías, es posible que el
primer números sean un más alto debido a que todo el entrenamiento se considera prevención.

Cómo medir en forma eficiente

La forma estándar 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 categoría respecto del costo de la calidad (ver Recuadro 2).
Los miembros del proyecto reportan
las horas dedicadas a cada actividad
Recuadro 2: Categorías del costo de la calidad
con el sistema usual, y a partir de eso
se suman las horas dedicadas en el Prevención: actividades para evitar correcciones
proyecto para cada categoría. Esto es (ejemplos, entrenamiento asociado al proyecto,
relativamente simple y se puede mejoras de procesos para el proyecto, recolección
implementar con un sistema a la y análisis de métricas).
medida, con extensiones al sistema Evaluación: actividades para determinar la calidad
de reporte de horas, o simplemente de los entregables (ejemplos, crear casos de
con una planilla Excel que se prueba, inspecciones de código, auditorías).
alimenta de los informes del sistema
de reporte de horas. Fallas internas: actividades para corregir entre-
gables (ejemplos, modificaciones a un documento
Como en todo plan de métricas, es después de una inspección, debugging).
fundamental que las métricas no sean
usadas para la evaluación o Fallas externas: actividades para corregir
compensación del personal. En caso productos ya entregados (ejemplos, corrección de
contrario, los números serán defectos de productos instalados, correcciones de
cocinados o por lo menos estarán datos).
sesgados. Pero empleados motivados Creación: actividades para hacer los entregables
a entregar métricas que reflejen del proyecto (ejemplos, levantamiento de
fielmente la realidad no son requerimientos, codificación).
suficientes.
Otro: actividades no relacionadas con los
Claro que no es tan simple saber entregables del proyecto (ejemplos, reporte del
cómo clasificamos correctamente estado del proyecto, actividades administrativas).
una actividad en las categorías de
costo de calidad.
Analicemos el trabajo involucrado en determinar los requerimientos de software. Las
entrevistas, escritura de requisitos, análisis de requisitos son claramente actividades de
Creación. Una revisión por pares es claramente una actividad de tipo Evaluación. 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 creación como evolución, y en
condiciones normales será considerada parte de la creación.

Métrica peligrosa
Si la gerencia plantea objetivos de reducción de las métricas de costo de calidad (CoQ) y
costo de la mala calidad (CoPQ) pueden producirse algunos vicios, especialmente si las
métricas están ligadas a la evaluación del personal.
El problema es que si el autor de un documento no quiere tener fallas internas podría dedicar
demasiado tiempo a las revisiones personales informales, es decir, el autor dedica más tiempo
a revisar en forma personal para asegurar una inspección triunfal. Este tiempo extra será
medido como creación. Veamos qué pasa con las métricas: ha aumentado el tiempo de
creación 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
evaluación, empeorándo la métrica CoQ en lugar de mejorarla.
Consideremos otro ejemplo más extremo. Un desarrollador utiliza una herramienta que le
permite programar mucho más rápidamente (ejemplo, parte del código lo produce un
generador de código). La herramienta no ayuda ni perjudica a los procesos de pruebas y
revisiones. En este caso, la introducción 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 comparación.

La raíz del problema

Veamos ahora un problema que está en el meollo del asunto: ¿qué son los entregables? Más
importante aún ¿qué entregables debiéramos 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 código, el
manual del usuario), agrega valor indirecto al cliente (ejemplo, el documento de
requerimientos), sirve de paso intermedio para crear otro entregable (ejemplo, diseño
detallado), y está en la lista especificada por contrato o por proceso (ejemplo, carta Gantt).
La forma en que se aplica esta métrica es suponer que todas las actividades de creación de
documentos son iguales. Pero esto es incorrecto: sólo debiera considerarse “creación” aquello
que agrega valor al cliente. Es poco claro que efectivamente se agregue valor al cliente con
documentación detallada. Normalmente el beneficio de parte de la documentación es más bien
prevenir errores en el código 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 prevención y no creación.
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 debiéramos
descontar el esfuerzo de su creación porque en realidad su desarrollo no fue creación del
proyecto sino tiempo malgastado.
Profundizando un poco más 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 métrica de costo de calidad? No, pero sí debemos
complementarla con alguna medida de productividad. Complementada con una medida de
productividad (es decir producción dividida por esfuerzo), entonces sí tiene sentido usar las
métricas de costo de calidad.
Algunas medidas son simplemente número de líneas de código y páginas de documentación.
Otras medidas cuentan puntos de función o alguna métrica similar, que tiene la ventaja que se
acerca un poco más al problema y depende menos de la tecnología usada. Desde ese punto de
vista, una métrica ideal sería algo así como requerimientos de usuario implementados a
satisfacción del cliente.
En resumen, si bien el costo de la calidad es muy importante, el costo del producto lo es más.
Medir sólo el costo de la calidad puede tener impactos negativos en el costo del producto.

www.AgileShift.cl 5 de 5 © 2006 Pablo Straub