Вы находитесь на странице: 1из 8

Calidad de software y costos de software

Los grandes proyectos de software por encima de los 10.000 puntos de función son empresas
comerciales peligrosas. La tasa de cancelación para grandes proyectos de software supera el
50 por ciento. De las grandes solicitudes que se completan, muchas llegan tarde y superan el
presupuesto. Una de las razones principales para la demora o la terminación se debe a los
volúmenes excesivos de defectos graves que no se descubren hasta la prueba, y luego
extienden los ciclos de prueba mucho más de lo previsto. Por el contrario, los grandes
proyectos de software que tienen éxito siempre se caracterizan por la excelencia tanto en la
prevención de defectos como en la eliminación de defectos, incluida la eliminación de defectos
previa a la prueba. Se puede concluir que el logro de niveles de vanguardia de calidad de
software es quizás el objetivo único más importante de las mejoras de procesos de software.

INTRODUCCIÓN

Este artículo explora la aplicación de dos marcos de métricas (costo de calidad del software
(CoQ) y contención de defectos de software) para modelar y administrar el costo y las
consecuencias de calidad entregadas de estrategias alternativas para la detección y corrección
de defectos de software durante el ciclo de vida de desarrollo de software. Se consideran
tanto los indicadores adelantados como los retrasados. Los datos en este artículo provienen de
dos fuentes principales. Una fuente consiste en una muestra de aproximadamente 13,000
aplicaciones de software examinadas entre 1973 y 2011 como resultado de estudios de
referencia y evaluación. La otra fuente es la información observada durante 12 demandas
relacionadas con proyectos cancelados o acusaciones de mala calidad donde el autor y sus
colegas trabajaron como testigos expertos. Los acuerdos de confidencialidad impiden
identificar organizaciones específicas. En total, los datos se obtuvieron de alrededor de 150
grandes corporaciones y 30 grupos gubernamentales a nivel estatal y federal. Para los datos
derivados de litigios, es significativo que cada caso, excepto uno, involucraba aplicaciones de
más de 10,000 puntos de función. Once de los casos fueron demandas de clientes contra
contratistas. El duodécimo caso fue una demanda de los accionistas corporativos contra la
gestión corporativa, afirmando que un control deficiente de la calidad del software estaba
reduciendo el valor de las acciones de la compañía.

Cuatro problemas comunes surgieron en las demandas:

1) control de calidad deficiente;

2) control de cambios deficiente combinado con requisitos progresivos que superan el 1 por
ciento de crecimiento por mes calendario;

3) seguimiento inadecuado del estado por parte de la administración que ocultó los problemas
hasta demasiado tarde para recuperarse; y

4) una estimación inadecuada o el rechazo arbitrario de estimaciones precisas por parte de


clientes que luego impusieron horarios inalcanzables.

El autor y sus colegas han examinado los resultados de aproximadamente 13,000 proyectos de
software entre 1973 y 2010.
La Tabla 1 muestra el porcentaje de proyectos que están a tiempo, temprano, tarde o
cancelados para mesetas de seis tamaños, cada uno con un orden de magnitud aparte. La
Tabla 1 usa métricas de puntos de función para expresar el tamaño del software. (Para obtener
información adicional sobre las métricas de puntos de función, es útil visitar el sitio web del
Grupo Internacional de Usuarios de Puntos de Función (IFPUG) en http://www.ifpug.org). Las
razones para usar puntos de función son que con más de 2,500 lenguajes de programación en
existencia, y múltiples lenguajes usados simultáneamente en miles de aplicaciones, las líneas
de código (LOC) no son adecuadas para estudios económicos a gran escala. Además, los
defectos en los requisitos y el diseño superan a los defectos del código y no se pueden medir
con métricas LOC. Como se puede ver en la Tabla 1, los proyectos de software pequeños
generalmente son exitosos, pero los sistemas grandes no lo son.

¿Por qué no?

Una razón es que las estimaciones optimistas son endémicas. También son endémicos los
rechazos de los clientes para aceptar estimaciones precisas, combinadas con la sustitución de
fechas imposibles de cumplir por los ejecutivos del cliente. (Un estudio separado del autor
señaló que el optimismo en las estimaciones de software aumentó con el tamaño de la
aplicación).

Una segunda razón es que la tasa medida de crecimiento de los requisitos es más del 1 por
ciento por mes calendario desde el final de la fase de requisitos hasta el comienzo de prueba.
Esta información proviene de contar puntos de función al completar los requisitos y luego
nuevamente al momento de la entrega. Para sistemas grandes con cronogramas de 36 meses
o más, el volumen total de requisitos de arrastre puede superar el 25 por ciento en
comparación con los requisitos originales. (En una demanda hubo 84 cambios importantes en
los requisitos, que casi duplicaron el tamaño de la aplicación en comparación con los requisitos
iniciales).
Una tercera razón para el fracaso es la desafortunada tendencia de los gerentes de proyecto a
omitir problemas serios en sus informes de estado a clientes y ejecutivos. Si los problemas no
se reconocen y se abordan temprano, a menudo es imposible recuperarse más tarde.

La cuarta y más grave razón es que la actividad más costosa y que consume más tiempo para
grandes proyectos de desarrollo de software es el costo de encontrar y corregir errores. Las
pruebas por sí solas no son muy eficientes para encontrar muchos tipos de defectos, y las
pruebas son muy caras. Si hay demasiados errores imprevistos cuando comienzan las pruebas,
los horarios de las pruebas se extenderán y retrasarán la entrega final de la aplicación. Los
costos de prueba aumentarán hasta que degraden el retorno de la inversión del proyecto a
niveles negativos.

La prevención de defectos, combinada con la eliminación de defectos previa a la prueba, como


las inspecciones y el análisis estático, puede reducir y eliminar los retrasos y los excesos debido
a la mala calidad. En general, lo que parece ser la razón principal del fracaso de los grandes
proyectos de software es la mala calidad. La frase "mala calidad" en este contexto tiene dos
significados:

1) Número excesivo de defectos o errores (menos de 6.0 por punto de función).

2) Actividades de eliminación de defectos inadecuadas (más del 85 por ciento de eficiencia de


eliminación de defectos).

Para saber qué volumen de defectos puede ser "excesivo" y qué nivel de eliminación de
defectos es "inadecuado", es útil conocer los promedios actuales de los EE. UU. La Tabla 2
muestra defectos que se originan en requisitos, diseños, códigos, documentos de usuario y
"correcciones erróneas" o defectos secundarios. La Tabla 2 muestra el número promedio de
defectos encontrados en proyectos de software y el porcentaje de defectos eliminados antes
de la entrega a los clientes.

La Tabla 2 ilustra tres aspectos desafortunados de los proyectos de software promedio:

1) grandes cantidades de defectos que pueden ocurrir;


2) la eficiencia de eliminación de defectos no es muy buena y especialmente para defectos que
no son de código; y

3) los defectos se originan en múltiples fuentes.

Sin embargo, al examinar los resultados de los proyectos de software desarrollados por
compañías líderes que han implementado programas exitosos de mejora de procesos, se
puede ver que los volúmenes totales de defectos son más bajos que el promedio, mientras que
los niveles de eficiencia de eliminación de defectos son mejores que el promedio La Tabla 3
ilustra los resultados típicos para los potenciales de defectos y los niveles de eliminación de
defectos basados en el modelo de madurez de capacidades (CMMI) desarrollado por el
Software Engineering Institute (SEI). Como se puede ver, los niveles 3, 4 y 5 son
significativamente mejores que los de EE. UU. promedios en términos de volúmenes generales
de defectos y niveles de eficiencia de eliminación de defectos. Uno de los principales
beneficios de lograr los niveles más altos de CMMI es un mejor control de calidad, que se
traduce en resultados más predecibles del proyecto. Esto plantea preguntas interesantes sobre
exactamente qué tipos de mejoras de proceso benefician los volúmenes de defectos y la
eficiencia de eliminación de defectos. Aunque los niveles de CMMI estadísticamente más altos
benefician la calidad, el estudio del autor observó una superposición entre los niveles. La
calidad de los mejores grupos de CMMI de nivel 1 fue mayor que la peor en el nivel 3. Algunos
proyectos de grupos de nivel 5 han tenido problemas de calidad. Existen métodos de mejora
de la calidad fuera del Modelo de Madurez de Capacidades. Estos incluyen el proceso unificado
racional, el proceso de software del equipo de Watts Humphrey y varias formas de desarrollo
ágil, como la programación extrema y el desarrollo de Crystal.

REDUCCIÓN DE VOLUMEN DE DEFECTOS

Dado que el número de defectos encontrados en los requisitos y diseños supera los defectos
de codificación, las empresas líderes y los proyectos líderes son muy exhaustivos en la
recopilación de requisitos y en la producción de especificaciones. Por supuesto, también es
importante reducir los defectos de codificación y las "malas soluciones".

Algunos de los métodos señalados que reducen los requisitos y defectos de diseño incluyen:
• Una junta conjunta de control de cambio de cliente / desarrollo o expertos de dominio
designados.

• Uso de la implementación de funciones de calidad (QFD).

• Revisión de garantía de calidad de arquitectura y documentos de diseño

• Uso de Six Sigma para software y / o Lean Six Sigma.


• Uso de los métodos japoneses como kaizen, kanban y poka yoke

• Uso de requisitos formales e inspecciones de diseño.


• Uso del diseño de aplicación conjunta (JAD) para minimizar los cambios posteriores.
• Uso de las prácticas que se encuentran en los niveles más altos de la CMMI

• Uso de prototipos formales para minimizar los cambios posteriores.


• Uso de componentes certificados reutilizables.
• Uso de minería de datos para extraer requisitos y diseños del software heredado.
• Revisiones formales de todas las solicitudes de cambio.
• Costos revisados y estimaciones de cronograma para todos los cambios mayores de 10
puntos de función.
• Priorización de solicitudes de cambio en términos de impacto comercial.
• Asignación formal de solicitudes de cambio a lanzamientos específicos.
• Uso de herramientas automatizadas de control de cambios con capacidades de referencia
cruzada.

Algunos métodos de prevención de defectos son solo parcialmente exitosos. Por ejemplo, el
método de desarrollo de sala limpia es efectivo cuando los requisitos son estables, pero no es
efectivo cuando el crecimiento de los requisitos supera el 1 por ciento por mes calendario.

El enfoque ágil de integrar a un usuario en un equipo de desarrollo para proporcionar


requisitos funciona cuando solo hay un pequeño número de usuarios totales, pero no es
efectivo para aplicaciones con miles o millones de usuarios. Ninguna persona comprende
todos los requisitos para tales aplicaciones. Se necesitan grupos de enfoque y encuestas de
mercado para capturar los requisitos potenciales para aplicaciones de alto uso como sistemas
operativos, sistemas de conmutación telefónica, sistemas de control automotriz y similares.

Tenga en cuenta que las inspecciones formales son efectivas de tres maneras distintas.
Obviamente, las inspecciones son efectivas en términos de eficiencia de eliminación de
defectos. Sin embargo, los participantes en las inspecciones formales evitan espontáneamente
cometer los mismos tipos de errores que encuentran las inspecciones. IBM notó este
fenómeno inicialmente en la década de 1970, cuando las inspecciones se estudiaron por
primera vez, y ha sido validado en muchas empresas. Como resultado, las inspecciones
formales se encuentran entre los métodos más efectivos de prevención de defectos. Un
beneficio final es que las inspecciones formales proporcionan mejores documentos de origen
para el diseño de casos de prueba, por lo que la eficiencia de las pruebas aumenta en un 5 por
ciento o más como subproducto del uso de inspecciones. Sin el uso de inspecciones, la calidad
de los EE. UU. Promedia aproximadamente 5.0 errores por punto de función y
aproximadamente 85 porcentaje en términos de eficiencia de eliminación de defectos. Cuando
se agregan inspecciones formales al ciclo, los potenciales de defectos caen gradualmente por
debajo de 3.0 por punto de función, mientras que los niveles de eficiencia de eliminación de
defectos rutinariamente superan el 95 por ciento y pueden alcanzar el 99 por ciento. Esta
combinación produce cronogramas de desarrollo más cortos y costos de desarrollo más bajos
que las pruebas solas. El análisis estático automatizado es una forma bastante nueva de
eliminación de defectos previa a la prueba que también tiene beneficios en términos de
prevención de defectos y eliminación de defectos. La advertencia con el análisis estático es
que hay más de 2.500 lenguajes de programación en uso alrededor de 2011. Las herramientas
de análisis estático solo funcionan para quizás 25 de los lenguajes más comunes, como C, C +,
C #, Java, COBOL, SQL y un pequeño un número interesante de otros. Un aspecto interesante
de controlar los requisitos es una reducción en los cambios no planificados o "aumento
progresivo de los requisitos". Los proyectos ordinarios en los EE. UU. promedian entre 1% y 2%
por mes en requisitos nuevos y cambiantes. Los proyectos líderes donde los requisitos se
recopilan y analizan cuidadosamente promedian solo una fracción del 1 por ciento por mes en
cambios no planificados. Las inspecciones de JAD, prototipos, QFD y requisitos son eficaces
para reducir el deslizamiento de requisitos no planificados. Sucede que los requisitos de
arrastre tienden a contener más errores que los requisitos originales. La eficacia de la
eliminación de defectos de prueba también es inferior a los requisitos de arrastre. Por lo tanto,
tanto el análisis estático como las inspecciones formales son herramientas de proceso clave
para minimizar los daños que a menudo se producen por un control de baja calidad de los
requisitos de arrastre.

AUMENTO DE NIVELES DE EFICIENCIA DE DESMONTAJE DE DEFECTOS

La mayoría de las formas de prueba son menos del 35 por ciento eficientes para encontrar
errores o defectos. Sin embargo, el diseño formal y las inspecciones de código son más del 65
por ciento eficientes para encontrar errores o defectos y, a veces, superan el 85 por ciento. El
análisis estático también tiene una alta eficiencia contra muchos tipos de defectos de
codificación. Por lo tanto, todos los proyectos líderes en empresas líderes utilizan inspecciones
formales, análisis estáticos y pruebas formales. Esta combinación es la única forma conocida
de lograr niveles acumulativos de eliminación de defectos superiores al 95 por ciento. La Tabla
4 ilustra los rangos medidos de los niveles de eficiencia de eliminación de defectos para una
variedad de revisiones, inspecciones, análisis estático y varios tipos de etapas de prueba.
Tenga en cuenta que la Tabla 4 es un extracto de un libro de próxima publicación, The
Economics of Software Quality (Jones y Subrmanyam 2011). Los bajos niveles de eficiencia de
eliminación de defectos de la mayoría de las formas de prueba explican por qué los mejores
proyectos no se basan solo en las pruebas. Los mejores proyectos utilizan requisitos formales,
arquitectura e inspecciones de diseño primero, y luego análisis estático de código,
inspecciones de código para características clave y una secuencia de prueba de etapas
múltiples después. Esta combinación de inspecciones seguidas de análisis estáticos y pruebas
conduce a los cronogramas de desarrollo generales más cortos y reduce las probabilidades de
fallas del proyecto.

MEDICIÓN DEL VALOR ECONÓMICO DE LA CALIDAD DEL SOFTWARE

Durante más de 50 años, el valor económico de la calidad del software se ha entendido mal
debido a las métricas y prácticas de medición inadecuadas. Las dos métricas de
software más comunes en los primeros días del software fueron LOC y "costo por
defecto". Desafortunadamente, ambas tienen serias fallas económicas. La métrica LOC
no puede usarse para medir requisitos o defectos de diseño, que colectivamente
superan en número defectos de codificación No es posible comprender el valor
económico real de la calidad si más del 50 por ciento de todos los defectos no se
incluyen en las medicionesmejo

Un problema más sutil con LOC es que esta métrica penaliza los lenguajes de alto nivel como
Java y Ruby y hace que los lenguajes de bajo nivel más antiguos como C y lenguaje
ensamblador se vean mejor de lo que realmente son. Por ejemplo, si una aplicación está
codificada en 1,000 líneas de código de ensamblaje que contiene 10 defectos, el resultado es
obviamente 10 defectos por KLOC. Si la misma aplicación está codificada en 250 líneas de Java
que contienen solo tres defectos, los resultados ahora son de hasta 12 defectos por KLOC,
aunque los defectos totales se reducen en un 70 por ciento. La métrica LOC ignora la
disminución sustancial en los volúmenes de defectos absolutos. Si ambas versiones tienen un
tamaño de cinco puntos de función, entonces la versión de ensamblaje tiene 2.0 defectos de
codificación por punto de función, mientras que la versión de Java tiene solo 0.6 defectos de
codificación por punto de función. métrica por defecto ”en realidad penaliza la calidad y tiende
a lograr el resultado más bajo para las aplicaciones más problemáticas. Este fenómeno se debe
a los costos fijos asociados con la eliminación de defectos, como el costo de escribir casos de
prueba y el costo de ejecutar casos de prueba. Incluso en situaciones donde la aplicación tiene
cero defectos, todavía habrá costos por escribir y ejecutar casos de prueba. El método más
efectivo para medir el valor económico de la calidad es analizar el costo total de propiedad
(TCO) de las aplicaciones de software. Se descubrirá que las aplicaciones con menos de
aproximadamente 3.0 defectos por punto de función y más del 95 por ciento en la eliminación
de defectos, la eficiencia costará alrededor de un 20 por ciento menos de desarrollo que los
proyectos idénticos con mala calidad. Los cronogramas de proyectos de alta calidad serán más
cortos en aproximadamente un 15 por ciento. Los costos anuales de mantenimiento serán más
bajos en aproximadamente un 40 por ciento. El TCO acumulativo de las aplicaciones de alta
calidad desde el comienzo de la primera versión hasta los cinco años de mantenimiento y
mejora será aproximadamente un 30 por ciento más bajo que los proyectos idénticos con mala
calidad. Un punto de valor final es muy importante. Para aplicaciones grandes, los niveles de
alta calidad minimizarán las posibilidades de falla. Esto se debe a que las aplicaciones de alta
calidad tienden a tener cronogramas de prueba más rápidos y, por lo tanto, cronogramas
generales más rápidos. El valor económico de excelente calidad es directamente proporcional
al tamaño de la aplicación. Cuanto más grande sea la aplicación de software, más valiosa será
la calidad.

A partir de 2011, los generadores de costos generales para el software indican por qué el
software tiene una mala reputación entre los CEO y los ejecutivos corporativos. Los dos
principales generadores de costos son encontrar y corregir errores y proyectos cancelados (ver
Tabla 5). No es de extrañar que el software sea mal considerado por los ejecutivos
corporativos. Ninguna verdadera disciplina de ingeniería debería tener reparaciones de
defectos y proyectos cancelados como los dos principales factores de costo. Para que la
ingeniería de software se convierta en una verdadera disciplina de ingeniería, el control de
calidad tendrá que ser mucho mejor de lo que es en 2011. La Tabla 6 muestra una
reorganización hipotética de los generadores de costos que deberían ser un objetivo para los
ingenieros de software durante quizás los próximos 15 años. El principal factor de costo debe
ser la innovación y el diseño de nuevas funciones, no la reparación de errores. La Tabla 6
ilustra cómo se deben distribuir los costos alrededor de 2025 suponiendo intentos serios de un
mejor control de calidad.

Si se mejora la calidad del software, debería ser posible gastar un porcentaje mucho mayor de
fondos disponibles en innovación, nuevas funciones y materiales reutilizables certificados. Los
principales impulsores de costos de hoy de reparaciones de defectos y proyectos cancelados
deberían estar al final de la lista de impulsores de costos y no al principio, como lo están en
2011.

RESUMEN Y CONCLUSIONES

La frase "mejora del proceso de software" es algo ambigua. La frase en sí misma no indica lo
que debe mejorarse. Sin embargo, a partir del análisis de una gran cantidad de proyectos que
fueron fallidos por un lado, o bastante exitosos por el otro, es obvio que el control de calidad
es el tema mejor clasificado que necesita ser mejorado. Con un control de calidad de
vanguardia, los proyectos exitosos se convierten en la norma. Con la prevención y eliminación
inadecuada de defectos, los proyectos cancelados y los desastres son la norma. Una ocupación
donde las fallas y los desastres son los principales generadores de costos no es una verdadera
disciplina de ingeniería. Para convertirse en una verdadera disciplina de ingeniería, la
ingeniería de software necesita un mejor control de calidad, mejores medidas de calidad y un
mejor análisis económico que las normas actuales.