Costo de la calidad
En general, la creencia de que la calidad es costosa es una idea que explica la resistencia por gestores del proyecto a la implementación de actividades de aseguramiento de la calidad (Laporte y April, 2018). Pensar en términos del costo de la falta de calidad en el producto que se entrega al cliente y el costo de las actividades de la calidad pone en contexto las decisiones que deben tomar gestores e ingenieros respecto de las actividades de calidad que deberían incluirse en sus proyectos.
Para entender el impacto de la gestión de la calidad en los proyectos de desarrollo de software, las organizaciones de software deberían establecer un modelo que les permita comparar los costos devengados en proyectos que están relacionados con las actividades de gestión de la calidad. Este modelo debe incluir (Pressman, 2006):
- Todos los costos que genera la búsqueda de la calidad
- Identificar una línea base que permita descubrir oportunidades que reduzcan el consto de la calidad
- Proporcionar una base normalizada para la comparación entre proyectos
- Relacionar los costos de la calidad en términos monetarios
Tipos de costo de la calidad
Los costos de la calidad, en general, se clasifican en varias categorías (Bourque y Fairley, 2014):
Costos de prevención. En estos se incluyen los costos relacionado con la inversión en iniciativas de mejora del proceso, infraestructura de calidad, herramientas de calidad, capacitación, auditorías, y gestión de revisiones. Estos costos, en general, no son específicos a un único proyecto y representan los costos de la calidad en el ámbito organizacional.
Costos de evaluación. Estos costos surgen de las actividades que identifican defectos durante la ejecución del proyecto. Los costos se pueden agrupar en costos de revisión y costos de prueba. En la primera subcategorías, se incluyen costos de revisión de pares, caminatas e inspecciones realizadas en los componentes estáticos del software (por ejemplo: revisión del documento de arquitectura del software o el algoritmo codificado de una función crítica del sistema). En la categoría de pruebas, se pueden incluir los costos asociados a la prueba de unidad, de integración, de sistema y de aceptación. La identificación de los diferentes tipos de prueba depende del modelo de proceso implementado en el proyecto de software. Por último, los costos de evaluación podrían incluir los costos relacionados con la prueba del software subcontradado.
Costo de corrección de fallas interna. Se presentan cuando se detecta un defecto en el software antes de enviarlo al cliente. En esta categoría de costos se deben incluir los costos relacionados con el análisis de la falla, la planeación del cambio en los distintos artefactos del software, la corrección del software y las pruebas de regresión.
Costos de las fallas externas. Estos costos se asocian a defectos identificados después de que el producto ha sido enviado al cliente. Incluye los costos relacionados a la resolución de quejas, devolución, reemplazo del producto, soporte, ayuda en línea y trabajo de garantía.
Algunos ejemplos del impacto de los defectos en los costos del proyecto
Laporte y April (2018) presentan un análisis de los costos de la calidad. Ellos presentan el trabajo de Selby y Selby (2007) en donde se informa de la efectividad de la detección de defectos aplicando revisiones de pares en 14 proyectos de gran escala. En su estudio de caso reportan que cerca de la mitad de los defectos del software bajo construcción se introduce en la etapa de análisis del sistema. Las otras etapas del proyecto también contribuyen con el problema de introducir defectos.
Los costos relativos para encontrar y reparar un defecto aumentan sustancialmente conforme se pasa de la prevención a detección y de la falla interna a los de falla externa. La figura 2 muestra que en producción, un defecto en la etapa de requisitos que no identificado en esa etapa puede costar hasta 1000 unidades de tiempo corregirlo (Pressman, 2006). Esto se debe a que se debe analizar el impacto de la corrección en cada una de las etapas del desarrollo de software y actualizar documentos, modelos, componentes de software, casos de software y la configuración del software afectadas.
Terminología del defecto de software
En temas de la gestión de la calidad es común encontrar términos como defecto, falla, falta o error. Cada uno de ellos tiene significados e impactos distintos, tanto en el mismo sistema de software, como en las percepciones de los usuarios. Además, cada uno de ellos se usa en distintos tiempos, según la etapa del proceso de desarrollo de software en donde se haya introducido (inyección del defecto) o su descubrimiento en etapa de operación al ejecutar el sistema (falla).
Por ejemplo, considerando que estamos en la etapa de construcción del software, el segmento de código escrito en el lenguaje de programación en C que se presenta a continuación ¿muestra un defecto, falla, falta o error?
if (calif > 60)
cout << “aprobado”;
else
cout << “reprobado”;
Suponga que el diseño detallado señala que para que una asignatura se considere reprobada, la calificación debe ser menor a 60. En caso contrario, se considera que la asignatura está aprobada.
Tomando como base la discusión que presenta Laporte y April (2018), Una falla es la manifestación de una falta (defecto) en el ambiente de operación. Una falla es la terminación de la capacidad de un componente de realizar la función para la cual fue diseñado. Las fallas se originan porque defectos (faltas) no fueron detectados por las actividades de revisión técnica o de pruebas. Un error se puede encontrar en la documentación, en las instrucciones de código fuente, en la ejecución del código, o en cualquier parte del ciclo de vida del sistema. Los errores se convierten en defectos cuando los documentos, y productos en general, se aprueban sin que el equipo de desarrollo los haya notado. Por otra parte las fallas se presentan durante la ejecución del software bajo desarrollo, o alguno de sus componentes.
Todos los desarrolladores de software introducen errores en los productos de software m edianamente complejos. Esto se debe a pasar por alto requisitos (implícitos y explícitos), malentendidos en la interpretación de requisitos, y errores tipográficos (Humphrey, 2008). Como los defectos son el resultado de los errores humanos, éstos no son lógicos. Por tanto, no ya un proceso lógico o deductivo que puede encontrar todos los tipos de defectos en un sistema (Humphrey, 2008). Así que para mejorar la calidad del software, el equipo de desarrollo debería ser capaz de identificar aquellos defectos que pongan en riesgo la vida de las personas o sus bienes.