Revisiones Técnicas Formales
Tema 3. Gestión de Configuración
El responsable de soporte realiza el plan de gestión de configuración, define el formulario de petición de cambio de configuración y define el formulario de informe de estado de la configuración. Define también el Comité de Control de configuración (CCC)
y sus procedimientos, especifica las herramientas de soporte y facilidades necesarias.
El funcionamiento general del GCS es mantener copias de todas las versiones de cada producto y registrar todos los cambios hechos a la línea de base del producto. Así se conoce los contenidos del producto y si existen herramientas para dar marcha atrás.
La línea base es el conjunto de documentos y otros materiales que representan de manera oficial el producto en cualquier momento. Una vez que un elemento del producto ha sido puesto en la línea base nadie puede cambiarlo sin la autorización del CCC y el formulario de petición de cambios correspondientes.
Pasos para un EC nuevo:
1. Se propone al CCC añadir un producto a la línea base a través de una petición de configuración (CCR).
2. El CCC revisa la entrega, abre petición de cambio (PC), le asigna un identificador y pasa la petición al dpto. De Calidad.
3. El responsable de Calidad/Proceso confirma la calidad del producto.
4. El CCC revisa la entrega y la aprueba (reuníón final), solicita más información o la desaprueba.
Pasos para un EC existente:
1. Se propone al CCC modificar un producto de la línea base a través de una petición de cambios de configuración (CCR). 2. El CCC revisa la entrega y la aprueba (reuníón final), solicita más información o la desaprueba.
3
En caso de aprobación se solicita al tutor de dicho producto que implemente el cambio.
4. El responsable de Calidad/Proceso confirma la calidad del producto. 5. El CCC procede a realizar el cambio en la línea base (reuníón final).
Formulario de solicitud de petición de cambio (PC):
Se emplea cuando se envía un elemento de configuración (EC) al comité de control de cambios (CCC) para su inclusión en la línea base del producto.
Formulario de informe de estado de configuración (IEC):
Se utiliza para proporcionar semanalmente el estado de la información del sistema de gestión de configuración software.
Tema 4. Gestión de calidad
Economía de la calidad
La calidad es básicamente ajustarse a las necesidades de los usuarios. Estas necesidades comprenden: Realizar las tareas requeridas, Cumplir con requisitos de rendimiento, Poderse utilizar y ser conveniente, Ser económico y estar a tiempo, Ser fiable y confiable.
La calidad de un sistema software está condicionada por la calidad del peor de sus componentes. La calidad de un componente software está condicionada por el individuo que lo desarrolló.La calidad de un componente software está condicionada por el proceso del proceso que se usó para desarrollarla.
Se estima que +50% del tiempo de un programador es empleado en realizar pruebas para asegurar el correcto funcionamiento del programa. Se plantea gestionar la calidad y así conseguir que únicamente el 20% del tiempo sea dedicado a pruebas, lo que provoca una mayor productividad.
Las principales maneras de encontrar y corregir defectos son: Compilar, Pruebas Unitarias, Pruebas de integración y sistemas, Inspecciones y Revisiones personales.
Control de calidad de software
Se plantea que las revisiones son más eficientes que las pruebas. Las revisiones siguen un proceso disciplinado con guías, listas de comprobación y estándares que garantizan encontrar los defectos. Es común seguir una checklist para comprobar que todo se cumple.
Además de hacer revisiones sobre el código es muy recomendable hacer revisiones sobre el diseño del programa. Un buen diseño facilita la revisión de código a posteriori.
Gestión de calidad de software
Se emplean distinto tipos de métricas de calidad como el rendimiento, velocidad de revisión, defectos encontrados por unidad de tamaño, defectos inyectados y eliminados por hora, nivel de eliminación de defectos o coste de calidad.
Lo más común es contrastar el rendimiento (porcentaje de defectos encontrados en una revisión frente al total de defectos existentes) con la velocidad (en general LOC/hora).
Cuando los programas tienen muchos defectos simples, los inspectores se distraen y normalmente omiten problemas importantes.
Con un plan de calidad se pretende responder a preguntas como:
¿Cómo estamos fabricando? ¿Cómo de bien funcionan las inspecciones y revisiones? ¿Qué densidad tengo en pruebas? ¿Qué nivel de esfuerzo dedico? ¿Me paso en revisiones? ¿A qué marcha vamos revisando? ¿A qué marcha se introducen defectos? ¿A qué marcha se eliminan defectos? ¿Dónde se eliminan más defectos? ¿Inspecciones? ¿Revisiones? ¿Pruebas? ¿En qué fase fue inyectado un defecto?
En todo caso normalmente es caro encontrar defectos, y encima luego se tienen que corregir. La prevención de defectos representa pues un gran ahorro y es algo muy interesante conseguir.
En primer paso en un proceso de prevención es ajustar la prioridad a cierto tipo de defecto que son más frecuentes, más problemáticos o más fáciles de prevenir. Luego se entra en un ciclo contínuo de ajuste y mejora de las acciones de prevención hasta con dar con un método que funcione. Algunas de las técnicas utilizadas son los estándares de tipos de defecto para la clasificación de los defectos encontrados y el diagrama de pareto para detectar qué defectos son responsables del mayor número de problemas.