La calidad de los productos implementados tiene relación directa con la calidad del proceso utilizado [4]. Cada cosa que ocurra en el proyecto durante el desarrollo, afecta a algún atributo del producto y, por lo tanto, a la calidad total del producto [34].
72
La afirmación anterior se ha determinado por medios cualitativos. Por experiencia, se sabe que organizaciones que implementan un proceso disciplinado tienden a tener mejores resultados y más consistentes. Sin embargo, la relación entre la calidad del proceso, los métodos seleccionados para el desarrollo del producto, y la calidad del código liberado nunca ha sido establecida de manera cuantitativa [34].
Uno de los problemas que dificultan la conexión entre la calidad del proceso y la del producto es la complejidad para definir, y posteriormente medir, la calidad del proceso [34].
Los procesos, actividades y tareas deberían planificarse y realizarse usando un modelo de ciclo de vida apropiado para la naturaleza de un proyecto software, considerando el tamaño, la complejidad, la seguridad, los riesgos y la integridad [49].
Como se ha mencionado anteriormente, la calidad está fuertemente ligada con las métricas [12]. Estas métricas sirven para medir la efectividad del proceso de la organización. Se pueden medir por separado la efectividad del análisis, del diseño, de la codificación y de las pruebas de los requisitos [12]. Para recolectar métricas del proceso, se recomienda:
• Identificar y definir las métricas a aplicar, para cada etapa del proceso.
• Documentar lo anterior.
• Acumular datos históricos.
• Decidir dónde se colocarán los datos de las mediciones.
• Designar quién administrará la recolección de datos por cada etapa.
• Programar revisiones de los datos recolectados, para aprender de la experiencia.
Los valores resultantes de la aplicación de las métricas, por si solos no sirven para evaluar la calidad del proceso. Estos números deben contrastarse con las normas y estándares establecidos en la organización [12]. Baker y Fisher [34] indican que implementar y ejecutar estándares de procesos organizacionales, no garantiza productos de alta calidad.
Además del uso mencionado de las métricas, según Sommerville [17], la utilidad de los estándares para los procesos de software radica en los siguientes aspectos:
• Proveen mejores prácticas y capturan el conocimiento de la organización.
• Proveen un marco de trabajo que permite implementar el aseguramiento de la calidad.
• Facilitan la continuidad y reasignación de tareas, es decir, la responsabilidad de una tarea puede cambiar de un integrante del equipo a otro, sin generar retrasos ni problemas, dado que todos en la organización realizan las tareas de la misma forma.
73
Entre los estándares aplicables a los procesos, se encuentran [17]:
• Definiciones de procesos.
• Descripción de los documentos que debe generar cada proceso.
La Figura 2. 17 muestra la relación existente entre los estándares de proceso y los de producto. En ella, se observa que los productos son generados por los procesos de software, a los cuales se les aplican estándares de proceso, que aseguran la aplicación de estándares del producto durante su desarrollo.
Figura 2. 17.- Relación entre los estándares de proceso y producto
Algunos ejemplos de estándares para los procesos incluyen [17]:
• Proceso de entrega de las versiones del producto software.
• Proceso de aprobación del plan de proyecto.
• Proceso de control de cambios.
• Proceso de registro de las pruebas.
La gestión de calidad de los procesos comprende [17]:
• Definir los estándares de proceso.
• Supervisar el proceso de desarrollo.
• Informar sobre el proceso a la dirección del proyecto.
Este último punto, si es visto desde la perspectiva del proveedor en un proyecto de adquisición, significa que los desarrolladores informan a la dirección del equipo de proyecto. Si se mira desde la perspectiva del cliente, significa que el proveedor debe informar al cliente sobre el desarrollo del proceso.
La alta calidad de los productos generalmente es el resultado del desarrollo avanzado del software. Por lo tanto, las acciones de mejora deben ser seleccionadas sobre la base del conocimiento de las dependencias entre los atributos de calidad del producto de software y el proceso de desarrollo del mismo [54]. Proceso Software Producto Estándar Proceso Genera Se aplicaa Se aplicaa Asegura su aplicación Estándar Producto
74
Para asegurar la calidad del proceso, se debe asegurar la calidad de cada una de sus etapas. A continuación, se incluyen algunas consideraciones específicas para cada etapa del proceso de desarrollo.
2.8.1. Calidad en la etapa de Diseño y Desarrollo
La norma ISO 9001:2000 [49] define que la planificación de las etapas de diseño y desarrollo deben determinar cuáles serán las etapas a realizar; la revisión, verificación y validación apropiadas para cada una de las etapas; y las responsabilidades y autoridades para el diseño y desarrollo.
Los resultados de las etapas de Diseño y Desarrollo deben estar conformes a [49]:
• Cumplir los requisitos de las entradas (requisitos funcionales, de rendimiento, legales, entre otros).
• Proporcionar información apropiada para la compra, producción y prestación de servicio.
• Contener o referenciar los criterios de aceptación del producto.
• Especificar las características del producto que son esenciales para su uso seguro y correcto.
Cualquier cambio durante el Diseño y Desarrollo debe ser identificado y registrado. Los cambios deben verificarse y validarse, y requieren de aprobación antes de su implementación. Se debe tener presente los posible efectos colaterales que los cambios pueden provocar en otros componentes del sistema [49].
2.8.2. Calidad en la etapa de integración
Esta es la etapa que requiere de mayor participación del equipo de aseguramiento de la calidad.
Cuando se realiza la integración de los distintos componentes desarrollados, que conformarán el producto de software final, se deben considerar, entre otras, las siguientes métricas [12]:
• Densidad de fallos. Corresponde al cociente entre el número de fallos distintos encontrados durante las pruebas, y el número de líneas de código.
• Densidad de defectos. Corresponde al cociente entre el número de fallos distintos encontradas por inspección, y el número de líneas de código.
• Cobertura de pruebas de defectos. Corresponde al cociente entre el número de requisitos funcionales probados, y el número total de requisitos.
• Índice de madurez del software. Esta métrica es un indicador de la estabilidad de un producto software. A medida que el índice se aproxima a 1, el producto comienza a estabilizarse y, por lo tanto, requerirá menos esfuerzo para su mantenimiento.
75
• Nivel de pureza del software. Es una estimación de la falta de fallos en el programa durante las etapas operativas.
• Tiempo medio entre fallos. Se mide registrando el tiempo transcurrido entre dos fallos consecutivos observados y calculando el promedio de estos tiempos.
El estándar ISO/IEC 12207:2008 [38] recomienda para la validación de la integración, los siguientes criterios:
• Los componentes de software y unidades de cada elemento del software han sido integrados completa y correctamente en el sistema.
• Las tareas de integración han sido desarrolladas de acuerdo con el plan de integración.