Estándares para
planes de calidad de
software
Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II
DIFERENCIA ENTRE PRODUCIR UNA
FUNCION Y PRODUCIR UNA
FUNCION DE CALIDAD
9
Una función consiste en el código que compila y
parece “trabajar”
9
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.
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)
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)
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 l t b j d t i i
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.
TÉCNICAS DE CAJA NEGRA Y
CAJA BLANCA (cont.)
1. Especificar cómo administrar
los documentos del proyecto 2. Identificar el proceso
3. Planear 4. Diseñar
y construir 5. Entregar y mantener el
producto
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 4. QA revisa, inspecciona y prueba 5. QA revisa, inspecciona y prueba 1. QA desarrolla y o revisa los planes, estándares, etc. de administración de la configuración
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.
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.
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.
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.
LA INSPECCIÓN (CONT.)
4. Preparación completa
1. PLANEACIÓN 2. PREPARACIÓN 3. INSPECCIÓN 4. RETRABAJO 5. SEGUIMIENTO ANÁLISIS CAUSAL VISIÓN GENERAL Proceso nominal Proceso no-nominalUNA 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
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
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?,
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
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
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.
