Estándares para planes de calidad de software. Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008

Transcripción

1 Estándares para planes de calidad de software Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008

2 DIFERENCIA ENTRE PRODUCIR UNA FUNCION Y PRODUCIR UNA FUNCION DE CALIDAD Una función consiste en el código que compila y parece trabajar Una función de calidad consiste en un código que: Satisface los requerimientos establecidos con claridad. Verifica sus entradas; reacciona de manera predecible a entradas ilegales. Se ha inspeccionado de manera íntegra por ingenieros que no son el autor. Se ha probado de modo exhaustivo en varias formas independientes. Esta bien documentado. Tiene una tasa de defectos confiable conocida, si los tiene.

3 DISEÑO DE ALTA CALIDAD Un diseño de alta calidad casi siempre: Se extiende ( es fácil mejorarlo para proporcionar funcionalidad adicional) Evoluciona ( se puede adaptar con facilidad a requerimientos diferentes) Se mueve ( se aplica a varios entornos) Es general (se aplica a varias situaciones diferentes)

4 MÉTRICAS Los ingenieros de software usan métricas, tales como: Número de clases Número de funciones por clase Cantidad de trabajo realizado, medido físicamente (como líneas de código) Tiempo que toma realizar el trabajo Tasa de defectos (defectos por 1000 líneas de código, defectos por página de documento, número de defectos fijos por mes, etcétera)

5 PROCESO DE ASEGURAMIENTO DE LA CALIDAD La principal responsabilidad de la calidad de un artefacto radica en la persona que lo crea. Al menos una persona debe revisar con detalle cada parte del trabajo de cada ingeniero, de preferencia alguien independiente del quien lo crea. Muchas organizaciones identifican un proceso separado de revisión sistemático y exhaustivo, que se conoce como aseguramiento de la calidad (QA, quality assurance). La función QA incluye revisiones, inspecciones (un tipo formal de revisión descrito en seguida) y pruebas. Un representante de QA puede participar con frecuencia en la inspección. Una persona ajena a la organización debe realizar el QA. En compañías muy pequeñas los ingenieros realizan las funciones de QA lt b j d t i i

6 TÉCNICAS DE CAJA NEGRA Y CAJA BLANCA - Las técnicas de caja negra de QA manejan aplicaciones, o partes de ellas, que ya están construidas. Estas técnicas verifican si el software cumple o no con sus requerimientos. - Las técnicas de caja blanca (o caja de vidrio) de QA se aplican a las componentes que forman la unidad que se está probando. - Los procesos de QA que no son uno de estos dos extremos suelen llamarse técnicas de caja gris.

7 TÉCNICAS DE CAJA NEGRA Y CAJA BLANCA (cont.) 1. Especificar cómo administrar los documentos del proyecto 1. QA desarrolla y o revisa los planes, estándares, etc. de administración de la configuración 5. QA revisa, inspecciona y prueba QA 4. QA revisa, inspecciona y prueba 2. Identificar el proceso 2. QA revisa que el proceso cumpla con las políticas de la organización 3. QA desarrolla y o revisa los suministros para las actividades de QA 5. Entregar y mantener el producto 4. Diseñar y construir 3. Planear

8 LA INSPECCIÓN Es una técnica de caja blanca para asegurar la calidad. Consiste en examinar las partes del proyecto (requerimientos, diseños, código, etcétera) para encontrar defectos. Fue establecido por Fagin. Es un proceso que señala al autor los defectos en el trabajo antes de que haga su entrega a la administración. Esto implica que las inspecciones deben ser un proceso entre colegas. El principio de inspección se puede extender a cuatro reglas: solo detección de defectos, proceso de colegas, roles especificados y preparación completa.

9 LA INSPECCIÓN (CONT.) 1. Sólo detección de defectos. Las inspecciones excluyen de modo específico la reparación de defectos. El proceso de reparación se deja al autor y no debe dedicarse tiempo de inspección ni siquiera a sugerencias. Éstas deben hacerse fuera de este tiempo. 2. Proceso de colegas. Un grupo de ingenieros de software debe realizar las inspecciones. El trabajo en proceso está sujeto a inspección, no el desempeño del autor. El trabajo que somete a inspección debe ser el resultado del mejor esfuerzo del autor, no un borrador o un diseño preliminar. 3. Roles especificados. El autor no debe desempeñar otro papel.

10 LA INSPECCIÓN (CONT.) El moderador es responsable de ver que se lleve a cabo la inspección de modo apropiado. El moderador también es un inspector. El autor es responsable del trabajo en sí, y repara los defectos encontrados (fuera de proceso). El autor también es un inspector y dedica tiempo a buscar defectos. El lector es responsable de conducir al equipo a través del trabajo en una forma adecuada e integral. Al mismo tiempo el lector inspecciona. El registrador es responsable de escribir las descripciones de los defectos y clasificarlos como lo decida el equipo. El registrador también es un inspector.

11 LA INSPECCIÓN (CONT.) Roles de inspección opcionales. La necesidad de su participación dependen del artefacto que inspecciona. Un inspector centrado inspecciona según un criterio específico (p. Ej., confiabilidad). Un inspector especializado es un experto en el área que cubre el artefacto sometido a inspección (p. Ej., experto en radares para una aplicación de control por radar). Un inspector llano no tiene otro papel que inspeccionar el material en busca de defectos.

12 LA INSPECCIÓN (CONT.) 4. Preparación completa 1. PLANEACIÓN Proceso nominal 2. PREPARACIÓN Proceso no-nominal ANÁLISIS CAUSAL 3. INSPECCIÓN VISIÓN GENERAL 4. RETRABAJO 5. SEGUIMIENTO

13 UNA MANERA DE PREPARAR Y REALIZAR LAS INSPECCIONES 1. Integrar las inspecciones en la programación del proyecto. Planear la inspección de todas las etapas, comenzando con los requerimientos Prevenir el tiempo de preparación ( consume tiempo! ) y de reuniones 2. Preparar la recolección de datos de inspección Incluir el número de defectos por unidad de trabajo (como KLOC), tiempo dedicado Desarrollar formas: incluye descripción, severidad y tipo Decidir quién, dónde, cómo almacenar y usar las métricas predeterminado: nombre de una sola persona responsable si no se decide, el resultado puede descartar los datos

14 UNA MANERA DE PREPARAR Y REALIZAR LAS INSPECCIONES (Cont.) 3. Asignar papeles a los participantes Adecuado, tres (autor, moderador/registrador, lector) Dos mejor que ninguno (autor, inspector) 4. Asegurar que cada participante se prepara Traer los defectos ingresados en las formas a la junta de inspección

15 VERIFICACIÓN Y VALIDACIÓN Son parte del plan de aseguramiento de la calidad. Se está construyendo bien? La verificación Se construyen justo las cosas de la etapa actual que se especificaron en la etapa anterior? Se construye el objeto correcto?, La validación Se satisface el deseo y la necesidad del cliente?

16 VERIFICACIÓN Y VALIDACIÓN (cont.) Ejemplo: EL cliente desea una aplicación que resuelva ecuaciones lineales de la forma ax + b = c. requerimientos 1. El usuario debe poder introducir números a,b y c de hasta 10 dígitos, con hasta cuatro lugares decimales. 2. La aplicación debe producir una solución para la ecuación ax + b = c a menos de 1/1000 dé la respuesta exacta. Después se escribe el programa para implementar este requerimiento. La validación de este producto consiste en realizar un conjunto de pruebas. Por ejemplo, se introduce a = 1, b = 1 y c = 1 y se valida que el programa produzca x = 0.

17 VERIFICACIÓN Y VALIDACIÓN (cont.) La validación no satisface la responsabilidad de entregar un producto libre de defecto. La responsabilidad restante es estar seguros de que se construyó la aplicación correcta. Verificación: Se procede de manera correcta desde el principio hasta el final. Aquí es necesario hacer los siguientes pasos: 1. Obtener los requerimientos del cliente. 2. Escribir los requerimientos detallados 3. Codificar la aplicación 4. Probar la aplicación

18 VERIFICACIÓN Y VALIDACIÓN (cont.) En la verificación: 1 2: Expresan los requerimientos lo que el cliente desea en realidad? Algunos aspectos de la verificación son los siguientes: Tiene ax + b = c la forma correcta? (compruebe con el cliente la precisión de la interpretación): qué pasa si se da un valor de 0 para a?, y otras preguntas. Las inspecciones de los requerimientos también son parte del proceso de verificación. 2 3: Implementa el código lo requerimientos escritos? Esto requiere una inspección del código, en la que se toma un requerimiento a la vez y se identifica el código que le corresponde. Puede incluir una demostración matemática. 3 4: La pruebas cubren toda la aplicación de manera adecuada? Esto también requiere una inspección de las pruebas.