CONTROL DE CALIDAD Y AUDITORA

Integrantes:

CHICAIZA ALCIVAR GUAYGUA ANDREA JARAMILLO HENRY PUCHA LUIS

ACTIVIDADES DE CONTROL DE CALIDAD EN LOS PROYECTOS DE DESARROLLO DE SOFTWARE

O OBJETIVO:

Comprobar si un producto posee o no una determinada caracterstica de calidad en el grado requerido. Un producto cuando carece de una determinada caracterstica de calidad se dice que tiene un DEFECTO. Por lo tanto, tambin que el objetivo del Control de Calidad es identificar defectos en el producto y corregirlos.

Se pueden clasificar las actividades de control de calidad en dos categoras:

Los primeros analizan el objeto sin necesidad de ejecutarlo mientras que los segundos requieren la ejecucin del objeto que est siendo probado.

O CONTROLES ESTTICOS:

Las actividades de control esttico se clasifican de la siguiente forma:

CONTROLES ESTTICOS MANUALES INFORMALES

O Comprobacin de escritorio (desk checking):

Consiste en examinar a mano e individualmente el objeto que se acaba de desarrollar. Se debe aplicar a los requisitos, especificaciones de diseo y cdigo segn se van desarrollando.
O Revisin por pares o iguales (peer review):

Consiste en la revisin del cdigo de un programador por otros programadores. Se puede poner en prctica creando un panel que se encarga de revisar peridicamente muestras de cdigo.

CONTROLES ESTTICOS MANUALES DISCIPLINADOS

Se encuentran lo que son las revisiones y auditoras

AUDITORAS : Sirven para determinar

Los procedimientos, instrucciones, especificaciones, cdigos, estndares u otros requisitos de tipo establecidos y aplicables. La efectividad y adecuacin de la implementacin realizada.

REVISIONES: Una revisin es como una reunin formal en la que se presenta el estado actual de los resultados de un proyecto a un usuario. Hay dos tipos de revisiones: las inspecciones y los walkthrough.

Inspecciones: Se van leyendo el documento, paso a paso y comprobando en cada paso el cumplimiento de los criterios de una lista de comprobacin. Walkthrough (visita guiada): Aqu se demuestra la funcionalidad del objeto revisado mediante la simulacin de su funcionamiento con casos de prueba y ejemplos.

Revisiones tcnicas y de gestin: Las revisiones tcnicas ms comunes son: Revisin de la especificacin de requisitos Revisin del diseo Revisin del cdigo Revisin de las pruebas Revisin del manual de usuario
o Revisin de la especificacin de requisitos: Este tipo de

revisin es muy til para facilitar el descubrimiento de los errores . Requisitos poco claros, contradictorios, errneos o imposibles de probar Requisitos incompletos o especificacin incompleta (faltan requisitos). Requisitos irrelevantes para el problema que se trata de resolver.

o Revisin del diseo: El objetivo es determinar y evaluar

el estado en el que se encuentra el proceso de diseo, as como descubrir errores o contradicciones. o Revisin del cdigo: Sus objetivos es determinar que el cdigo se corresponde con el diseo detallado realizado. Algunos de los aspectos que se examinan en una revisin de cdigo son los siguientes: interfaces estructura del programa utilizacin de variables frmulas entradas y salidas comentarios adherencia a los estndares de codificacin.

Revisiones de las pruebas: Se pueden efectuar dos tipos de revisiones de las pruebas: O Revisin del diseo de la prueba O Inspeccin de la prueba

El objetivo de la revisin del diseo de la prueba es comprobar que el diseo realizado para la prueba est de acuerdo con los objetivos que se persiguen.
Los objetivos de las inspecciones de las pruebas, por su parte, son: O Comprobar que la prueba se ha ejecutado correctamente, de acuerdo con el procedimiento de prueba especificado. O Anlisis de los resultados obtenidos con cada prueba.

CONTROLES ESTTICOS AUTOMTICOS

Dentro de esta categora tenemos el anlisis esttico automtico y la verificacin formal de programas. Otras tcnicas de anlisis esttico automtico de programas son: O Anlisis de Flujo O Ejecucin simblica
ANLISIS DE FLUJO: Se basa en una representacin grfica. Usan grafos en los que los nodos representan sentencias o segmentos de programa.

Va clasificando las variables en:

Referenciadas (r): Cuando se obtiene su valor en memoria durante la evaluacin de una expresin en una sentencia.

 Definidas (d): Cuando se obtiene un nuevo valor para la

variable como consecuencia de la ejecucin de una sentencia. No referenciadas (n): Cuando ya no se puede determinar el valor de la variable a partir del flujo del programa.

A partir de estos valores se generan expresiones de camino para cada variable, concatenando los valores asignados a los tokens de dicha variable en nodos consecutivos. Se analizan entonces las expresiones de camino para detectar anomalas: ...dd... se ha definido dos veces sin ser referenciada, ...nr... se ha referenciado sin haberla definido previamente, ..r... se ha referenciado sin haberla definido previamente, etc.

EJECUCIN SIMBLICA:

Consiste en la ejecucin simblica de ciertos caminos dentro del programa, durante la cual se verifican ciertas expresiones simblicas con respecto a ciertas condiciones y afirmaciones preestablecidas.
VERIFICACIN FORMAL

Consiste en demostrar matemticamente la correccin de un programa con respecto a sus especificaciones. Para ello, se considera el programa como un objeto formal, con una sintaxis y una semntica formal. Es tambin necesario que la especificacin se haya escrito en algn lenguaje formal. Por eso no siempre es posible realizar este tipo de verificacin.

CONTROLES DINMICOS
O Son aquellos que requieren la ejecucin

del objeto que se est probando o de un modelo del mismo. O Hasta la fecha no se ha desarrollado ninguna teora universalmente aceptada acerca de la prueba de software. Lo nico que hay es un conjunto de aproximaciones metodolgicas que facilitan y hacen ms eficiente el proceso de prueba.

PRUEBA

Proceso en que se ejecuta un sistema con el objetivo de detectar fallos.

DEPURACION

Proceso en el que se localiza el defecto que es la causa de un fallo. Se determina la forma de corregirlo. Se evala el efecto de la correccin. Se lleva a cabo la correccin.

O El costo de deteccin de los defectos

suele ser mucho mayor que el costo de correccin de los mismos.

O A continuacin veremos cules son las

actividades que es necesario realizar para probar un sistema software, y cules son los principales mtodos de prueba que se pueden utilizar.

TIPOS DE PRUEBAS
O El

proceso de prueba conlleva la realizacin de un conjunto de tareas a lo largo del ciclo de vida del sistema. O El conjunto mnimo de pruebas que se deben realizar son:
O Prueba modular, prueba unitaria o prueba de

componentes O Prueba de integracin O Prueba del sistema O Prueba de aceptacin

O La prueba modular consiste en la prueba

de cada mdulo aislado del resto del sistema. O La prueba de integracin se realiza a medida que los diferentes mdulos del sistema se integran en el mismo. Ya se ha realizado la prueba modular, y se supone que todos mdulos son correctos. El objetivo fundamental de esta prueba es comprobar que las interfaces entre los distintos mdulos son correctas.

O Se pueden utilizar tres posibles estrategias de

integracin:
O De

arriba a abajo (top-down): Consiste en empezar la integracin y la prueba por los mdulos que estn en los niveles superiores de abstraccin, e integrar incrementalmente los niveles inferiores. O De abajo a arriba (bottom-up): Consiste en empezar la integracin y la prueba por los mdulos que estn en los niveles inferiores de abstraccin, e integrar incrementalmente los niveles superiores. O Big-bang: Consiste en integrar y probar todo al mismo tiempo.

O La prueba del sistema se realiza cuando se han

integrado todos los mdulos, y su objetivo es comprobar que el sistema satisface los requisitos del usuario, tanto los funcionales como los no funcionales. O La prueba de aceptacin se realiza una vez que el sistema se ha implantado en su entorno real de funcionamiento, y su objetivo es demostrar al usuario que el sistema satisface sus necesidades. O La prueba de regresin tiene como objetivo comprobar que toda nueva versin de un producto software es de no menos calidad que la versin anterior, es decir, que al introducir cambios no se ha reducido la valoracin de ninguna de las caractersticas de calidad que tena el producto.

Mtodos de caja negra

O En este tipo de mtodos, el objeto que se

desea probar se ve como una caja negra. Esto quiere decir que la eleccin de los casos de prueba se va a basar en el conocimiento acerca de la funcionalidad deseada. O Los mtodos de seleccin del conjunto de casos de prueba ms usuales son:

Mtodo de clases de equivalencia

Consiste en dividir las posibles entradas al sistema en clases de equivalencia, de tal forma que todos los miembros de una misma clase de equivalencia prueben las mismas propiedades en el sistema.

Anlisis de valores frontera o valores lmite Grafos causa/efecto y tablas de decisin

Adivinacin de errores

Consiste en seleccionar como casos de prueba aquellos valores de entrada que caen en la frontera de las clases de equivalencia (justo a un lado, justo al otro y justo en la frontera).

Consiste en crear un grafo causa/efecto a partir de las especificaciones, y seleccionar suficientes casos de prueba. Se llama causas a las caractersticas de los datos de entrada y efectos a las clases de salidas que puede proporcionar el programa.

Consiste en tratar de imaginar cules son los errores que se pueden haber cometido con mayor probabilidad, y generar casos de prueba para comprobar dichos errores.

MTODOS DE CAJA BLANCA

O En este tipo de mtodos, el objeto que se

desea probar se ve como una caja blanca. Esto quiere decir que la eleccin de los casos de prueba se va a basar en el conocimiento que se tenga acerca de la estructura del objeto.

Mtodos basados en mtricas de cobertura:

Las mtricas ms utilizadas son: Cobertura de sentencias Cobertura de segmentos entre decisiones. Cobertura de decisiones de ramificacin Cobertura de condiciones Cobertura de todas las combinaciones de condiciones Cobertura de caminos

Mtodos basados en mtricas de complejidad:

Las mtricas de complejidad ms utilizadas en la generacin de casos de prueba son las de MacCabe: Complejidad ciclomtica (arcos - nodos + 2 * nmero de componentes conexos) Complejidad esencial (complejidad ciclomtica nmero de subgrafos propios de entrada y salida nica) Complejidad real (nmero de caminos ejecutados)

METODOLOGA DE PRUEBA
O Implica la realizacin de un conjunto de

actividades estndar, as como la produccin de un conjunto de salidas estndar.

Planificacin de la prueba:

El objetivo del proceso de prueba. Los objetos que hay que probar. Las caractersticas que se van a probar y las que no. El mtodo de prueba a utilizar. Los recursos que se van a emplear. El plan de tiempos. Los productos a generar durante las pruebas El reparto de las responsabilidades.

Diseo de la prueba:
Determinaci n de los casos de prueba:

De qu forma se van a utilizar. Qu objetos se van a probar. Qu criterios se van a utilizar para determinar si el objeto pasa o no pasa la prueba.

Qu objetos se van a probar, Qu entradas se les van a dar y Cules son las salidas esperadas.

Planificacin del procedimiento de prueba:

Esta actividad consiste en fijar un conjunto de pasos para la ejecucin de la prueba. Se especifica detalladamente: La secuencia exacta de ejecucin de los distintos casos de prueba, Los requisitos que hay que cumplir para la ejecucin de cada caso y Las condiciones de terminacin de cada uno de ellos.

Ejecucin de la prueba:

Esta actividad consiste en ejecutar cada caso de prueba, segn el procedimiento especificado en el paso anterior, y registrar los incidentes o problemas encontrados durante la misma.

Anlisis y evaluacin de la prueba:

Se examinan los resultados de la prueba y se decide si se han alcanzado los objetivos propuestos o se debe repetir la prueba.

PREGUNTAS
Cul es el objetivo de las actividades de control de calidad del software? 2. Cul es el mtodo de anlisis esttico de la Calidad del Software ms eficaz en las fases iniciales del desarrollo? 3. En cul de los mtodos de anlisis esttico de la Calidad del Software se utilizan listas de comprobacin? Para qu? 4. Se resuelven en la misma reunin de revisin los errores encontrados? 5. Qu tipo de revisin es ms formal, la inspeccin o el walkthrough? 6. Cules son las revisiones tcnicas ms comunes? 7. En qu orden se deben realizar los diferentes tipos de pruebas? 8. La utilizacin de valores frontera para las entradas al sistema es un mtodo de prueba de caja negra o de caja blanca? 9. De qu forma se comprueba si los casos de prueba elegidos son los ms adecuados? 10. Cules son los mtodos en que se clasifica la caja blanca?
1.

RESPUESTAS
1. Comprobar si un producto posee o no una

2.
3.

4. 5.

determinada caracterstica de calidad en el grado requerido, adems de identificar defectos en el producto y corregirlos. Las Revisiones. Revisiones por Inspeccin. Para que vaya comprobando que cumpla con criterios de salida entre etapas de desarrollo. Si. La inspeccin

Respuestas
6. Revisin de la especificacin de requisitos, de 7.

8.
9.

10.

diseo, de cdigo, de la prueba y del manual de usuario. Prueba modular, de Integracin, del sistema, y de aceptacin. Mtodos de la caja negra. Mediante la realizacin de un conjunto de actividades estndar y un conjunto de salida estndar. Basados en mtrica de cobertura y mtricas de complejidad.