Verificacin y validacin

Verificacin y validacinVerificacin: Estamos construyendo el producto corrctamente?. El software debera ajustarse a su especificacin

Validacin: estamos construyendo el producto correcto?. El software debera hacer lo que el cliente realmente reclama.

El proceso V & VEs el proceso de todo un ciclo vital: La V & V debe aplicarse en cada etapa del software. Tiene dos objetivos principales El descubrimiento de defectos en el sistema; La evaluacn de si el sistema es til y

utilizable en una situacin operacional o no.

Metas de la V&VLa verificacin y la validacin deberan establecer la confianza de que el software es adecuado al propsito. Esto NO significa que est completamente libre de defectos. Sino que debe ser lo suficientemente bueno para su uso previsto y el tipo de uso determinar el grado de confianza que se necesita.

Confianza de la V&V

Depende del propsito del sistema, las expectativas del usuario Funcin del software El nivel de confianza depende de lo crtico que es el sistema para una organizacin. Expectativas del usuario Los usuarios pueden tener bajas expectativas para ciertas clases de software.

Verificacin dinmica y esttica

Inspecciones de software. Se ocupa del anlisis de representaciones estticas del sistema para describir problemas (verificacin esttica) Pueden ser complementadas por documentos

basados en herramientas y anlisis del cdigo

Pruebas del software. Se ocupa de la ejercitacin y la observacin del comportamiento del producto (verificacin dinmica) El sistema se ejecuta con datos de pruebas y se

observa su comportamiento operativo.

V & V esttica y dinmicaInspecciones de software

Especificaciones de requerimientos

Diseo de Alto nivel

Especificacin formal

Diseo detallado

Programa

Prototipo

Prueba de programas

Prueba del programaPuede revelar la presencia de errores NO su ausencia. Es la nica tcnica de validacin para requerimientos no funcionales ya que el software tiene que ser ejecutado para ver su comportamiento. Debera utilizarse en conjuncin con la verificacin esttica para proporcionar una covertura de V & V total.

Tipos de pruebas

Pruebas de defectos Pruebas diseadas para descubrir defectos en

el sistema. Una prueba de defectos exitosa es aquella que revela la presencia de defectos en un sistema.

Pruebas de validacin Previsto para mostrar que el software cumple

sus requerimientos. Una prueba con xito es aquella que muestra que un requerimiento se ha implementado correctamente.

Pruebas y depuracin

Las pruebas de defectos y depuracin son distintos procesos. La verificacin y validacin se ocupan de establecer la existencia de defectos en un programa. La depuracin se ocupa de ubicar y reparar estos errores. La depuracin implica formular una hiptesis sobre el comportamiento del programa y despus probar esta hiptesis y encontrar el error del sistema.

El proceso de depuracin

Resultados De pruebas

Especificacin

Casos De pruebas

Localizar error

Disear reparaciones de errores

Reparar errores

Probar de nuevo el programa

Planificacin de V &VSe requiere una cuidadosa planificacin para sacar el mximo de los procesos de inspeccin y pruebas. La planificacin debera comenzar pronto en el proceso de desarrollo. El plan debera identificar el balance entre la verificacin esttica y las pruebas. La planificacin trata de definir estndares para el proceso de prueba en lugar de describir pruebas de productos.

El modelo-V de desarrolloEspecificacin De requerimientos Especificacin Del sistema Diseo del sistema Diseo detallado

Plan de pruebas De aceptacin

Plan de pruebas de integracin del sistema

Plan de pruebas de integracin De los subsistemas

Cdigo y prueba de los mdulos y unidades

Servicio

Prueba de aceptacin

Prueba de integracin del sistema

Prueba de integracin De los subsistemas

Estructura de un plan de pruebas de softwareProceso de pruebas Trazabilidad* de requerimientos. Elementos probados. Calendario de pruebas. Procedimientos de registro de las pruebas. Requerimientos hardware y software. Restricciones.*

Es un conjunto de acciones, medidas y procedimientos tcnicos que permite identificar y registrar cada producto desde su nacimiento hasta el final

Plan de pruebas de software

El proceso de prueba Una descripcin de las principales fases del proceso de prueba. stas podran describirse como se hizo anteriormente en este captulo. Trazabilidad de requerimientos Los usuarios son los ms interesados en que el sistema satisfaga sus requerimientos y las pruebas deberan planificarse para que todos los requerimientos se prueben individualmente. Elementos probados Deberan especificarse los elementos del proceso de software que tienen que ser probados. Calendario de pruebas Un calendario de todas las pruebas y la asignacin de recursos para este calendario se enlaza obviamente, con la agenda general del desarrollo del proyecto. Procedimiento de registro de las pruebas No es suficiente ejecutar simplemente las pruebas; los resultados de la pruebas deben ser registrados sistemticamente. Debe ser posible auditar el proceso de pruebas para comprobar que se ha llevado a cabo correctamente Requerimientos de software y hardware En esta seccin deberan anticiparse las restricciones que afectan al proceso de pruebas como la escasez de personal. Restricciones En esta seccin deberan anticiparse las restricciones que afectan al proceso de pruebas como la escasez de personal.

Inspecciones de software

Implican que las personas examinen la representacin de la fuente con el propsito de descubrir anomalas y defectos Las inspecciones no requieren la ejecucin de un sistema por lo que debe utilizarse antes de la implementacin. Pueden estar aplicados a cualquier representacin del sistema (requerimientos, diseo, configuracin, datos, pruebas de datos, etc). Se ha demostrado que es una tcnica efectiva para descubrir errores del programa.

xito de la inspeccin

Pueden descubrirse muchos diferentes defectos en una sola inspeccin. Al probar, un defecto puede enmascarar a otro as que se requieren varias ejecuciones.

Inspecciones y pruebas

Las inspecciones y pruebas son complementarias y no tcnicas opuestas de verificacin. Ambas deben utilizarse durante el proceso V & V. Las inspecciones pueden comprobar el ajuste con una especificacin pero no la conformancia con los requerimientos reales del cliente. Las inspecciones no pueden comprobar caractersticas no funcionales como rendimiento, usabilidad, etc.

Inspecciones de programasEs la aproximacin formalizada a las revisiones del documento Est pensado explcitamente para la deteccin de defectos (no su correccin) Los defectos pueden ser errores lgicos, anomalas en el cdigo que pueden indicar una condicin errnea (p.ej: una variable no iniciada) o no conformidad con los estndares.

Precondiciones de la inspeccin

Debe haber una especificacin precisa disponible. Los miembros del equipo deben estar familiarizados con los estndares de organizacin. Debe estar disponible un cdigo sintcticamente correcto u otras representaciones del sistema. Debera prepararse una lista de errores. La gestin debe aceptar que la inspeccin aumentar los costes pronto en el proceso de software. La gestin no debera utilizar inspecciones para la evaluacin del personal, es decir, para encontrar quin comete errores.

El proceso de inspeccin

Planificacin

Visin de conjunto

Seguimiento Preparacin individual Repeticin de trabajo

Reunin de inspeccin

Proceso de inspeccin

Visin de conjunto del sistema presentado al equipo de inspeccin. Los cdigos y documentos asociados se distribuyen al equipo de inspeccin por adelantado. La inspeccin tiene lugar y se anotan los errores encontrados. Se hacen modificaciones para reparar los errores descubiertos. Puede requerirse o no una reinspeccin.

Roles en el proceso de inspeccinAutor o El programador o diseador responsable de generar el programa propietario o documento. Responsable de reparar los defectos descubiertos durante el proceso de inspeccin. Inspector Encuentra errores, omisiones e inconsistencias en los programas y documentos. Tambin puede identificar cuestiones ms generales que estn fuera del mbito del equipo de inspeccin. Presenta el cdigo o documento en una reunin de inspeccin Registra los resultados de la reunin de inspeccin

Lector Secretario

Presidente o Gestiona el proceso y facilita la inspeccin. Realiza un informe moderador de los resultados del proceso para el moderador jefe. Moderador jefe Responsable de las mejoras del proceso de inspeccin, actualizacin de las listas de comprobacin, estndares de desarrollo, etc.

Listas de inspeccin

Debera utilizarse una lista de errores comunes para guiar la inspeccin. Las listas de errores dependen del lenguaje de programacin y reflejan los errores caractersticos que es probable que aparezcan en el lenguaje. En general cuanto ms dbil sea la comprobacin del tipo, ms grande ser la lista. Ejemplos: inicializacin, nombramiento de constantes, terminacin de bucles, lmites de vectores, etc.

Comprobaciones de inspeccin 1Defectos de datos Se inicializan todas las variables antes de que se utilicen sus valores? tienen nombre las constantes? El lmite superior de los vectores es igual al tamao del vector o al tamao 21? Si se utilizan cadenas de caracteres, tienen un delimitador explcitamente asignado? Existe alguna posibilidad de que el bfer se desborde? Para cada sentencia condicional, es correcta la condicin? Se garantiza que termina cada bucle? estn puestas correctamente entre llaves las sentencias compuestas? En las sentencias case, se tienen en cuenta todos los posibles casos? Si se requiere una sentencia break despus de cada caso en las sentencias case Se ha incluido?

Defectos de control

Defectos Se utilizan todas las variables de entrada? de entrada Se les asigna un valor a todas las variables de salida? Pueden /salida provocar corrupciones de datos las entradas no esperadas?

Comprobaciones de inspeccin 2Defectos de interfaz Las llamadas a funciones y a mtodos tienen el nmero correcto de parmetros? Concuerdan los tipos de parmetros reales y formales? Estn en el orden correcto los parmetros? Si los componentes acceden a memoria compartida, tienen el mismo modelo de estructura de la memoria compartida?

Defectos Si una estructura enlazada se modifica, se reasignan de gestin de correctamente todos los enlaces? almacenamiento Si se utiliza almacenamiento dinmico se asigna correctamente el espacio de memoria? Se desasigna explcitamente el espacio de memoria cuando ya no se necesita? Defectos de manejo expcepciones Se tienen en cuenta todas las condiciones posibles de de error?

Cifras de inspeccin

500 sentencias/hora durante la visin de conjunto. 125 sentencias de cdigo fuente/hora durante la preparacin individual. Pueden inspeccionarse de 90 a 125 sentencias/hora. Por lo tanto la inspeccin es un proceso caro. Inspeccionar 500 lneas cuesta el esfuerzo de unas 40 horas/hombre (unos 4146 en cifras espaolas).

Anlisis esttico automatizadoLos analizadores estticos son herramientas de software para procesar textos fuente. Estos analizan sintcticamente el texto del programa y tratan de descubrir condiciones potencialmente errneas y llamar la atencin del equipo de V & V. Son una ayuda muy efectiva en las inspecciones ( son un complemento, no una sustitucin de las inspecciones)

Comprobaciones del anlisis estticoClase de defecto Defectos de datos Comprobacin del anlisis sintctico Variables utilizadas antes de su inicializacin. Variables declaradas pero nunca utilizadas Variables asignadas dos veces pero nunca utilizadas entre asignaciones. Posibles violaciones de los lmites de los vectores. Variables no declaradas Cdigo no alcanzable. Saltos incondicionales en bucles. de Las variables salen dos veces sin intervenir ninguna asignacin. Inconsistencias en el tipo de parmetros. Inconsistencias en el nmero de parmetros. Los resultados de las funciones no se utilizan. Existen funciones y procedimientos a los que no se les llama Punteros sin asignar. Aritmtica de punteros.

Defectos de control Defectos entrada/salida Defectos de interfaz

Defectos de gestin de almacenamiento

Etapas del anlisis estticoAnlisis del flujo de control. Comprueba los bucles con mltiples puntos de entrada o salida, encuentra cdigos inalcanzables. Anlisis de uso de los datos. Detecta variables no inicializadas, variables escritas dos veces sin que intervenga una asignacin, variables que se declaran pero nunca se usan, etc. Anlisis de interfaz. Comprueba la consistencia de una rutina, las declaraciones del procedimiento y su uso.

Etapas del anlisis esttico

Anlisis de flujo de informacin. Identifica las dependencias de las variables de salida. No detecta anomalas en s pero resalta informacin para la inspeccin o revisin del cdigo. Anlisis de caminos. Identifica los caminos del programa y arregla las sentencias ejecutadas en el camino. Nuevamente, es potencialmente ltil en el proceso de revisin. Ambas etapas generan grandes cantidades de informacin. Deben utilizarse con cuidado.

Anlisis esttico LINT138% more lint_ex.c #include printarray (Anarray) int Anarray; { printf(%d,Anarray); } main () { int Anarray[5]; int i; char c; printarray (Anarray, i, c); printarray (Anarray) ; } 139% cc lint_ex.c 140% lint lint_ex.c lint_ex.c(10): warning: c may be used before set lint_ex.c(10): warning: i may be used before set printarray: variable # of args. lint_ex.c(4) :: lint_ex.c(10) printarray, arg. 1 used inconsistently lint_ex.c(4) :: lint_ex.c(10) printarray, arg. 1 used inconsistently lint_ex.c(4) :: lint_ex.c(11) printf returns value which is always ignored

Uso del anlisis estticoEs particularmente valioso cuando se utiliza un lenguaje como C que tiene un tipado dbil y por tanto muchos errores no detectados por el compilador Es menos rentable para lenguajes como Java que tienen una fuerte comprobacin de tipado y por lo tanto pueden detectar muchos errores durante la compilacin.

Desarrollo de software de sala limpiaEl nombre se deriva de Sala limpia en la fabricacin de unidades de semiconductores. La filosofa es evitar los defectos en lugar de eliminarlos. Este proceso de desarrollo de software se basa en: Desarrollo incremental; Especificacin formal; Verificacin esttica utilizando argumentos de

correccin; Pruebas estticas para determinar la fiabilidad del programa.

El proceso de Sala limpia

Especificar formalmente el sistemaDefinir los incrementos de software Desarrollar el perfil operacional Construir el programa estructurado

Revisin de errores

Verificar formalmente el cdigo

Integrar el incremento

Disear las pruebas estticas

Probar el sistema integrado

Limpia

Caractersticas del proceso de Sala limpia Especificacin

formal que utiliza un modelo de transicin de estados. Desarrollo incremental en el que el cliente prioriza sus incrementos. Programacin estructurada: se utiliza un nmero limitado de estructuras de control y de abstracciones de datos. Verificacin esttica que utiliza inspecciones rigurosas.

Equipos de proceso de Sala LimpiaEquipo de especificacin. Responsable del desarrollo y mantenimiento de la especificacin del sistema. Equipo de desarrollo. Responsable de desarrollar y verificar el software. El software NO se ejecuta ni se compila durante este proceso Equipo de certificacin. Es responsable de desarrollar un conjunto de pruebas estadsticas para ejercitar el software despus de su desarrollo. Los modelos de crecimiento de fiabilidad se utilizan para determinar cundo es aceptable la fiabilidad.

Evaluacin del proceso de Sala LimpiaEl resultado de usar procesos de Sala Limpia ha sido realmente impresionante con los pocos fallos descubiertos en sistemas desarrollados. La valoracin independiente muestra que el proceso no es ms caro que otras aproximaciones. Hubo muy muchos menos errores que en el proceso de desarrollo tradicional. Sin embargo, el proceso generalmente no se utiliza. No est claro como puede ser transferida esta aproximacin a un entorno con ingenieros de software menos motivados o menos expertos.

Evaluacin del proceso con Caja NegraLas pruebas de caja negra son aquellas que se enfocan directamente en el exterior del mdulo, sin importar el cdigo, son pruebas funcionales en las que se trata de encontrar fallas.

Evaluacin del proceso con Caja de EstadoLa caja de estado encapsula los datos de estado y servicios (operaciones).

Evaluacin del proceso con Caja TransparenteUna caja transparente contiene el diseo de procedimiento para la caja de estado.

Ejemplo Caja Transparente

Ejemplo Caja Transparente

Puntos claveLa verificacin y la validacin no son lo mismo. La verificacin muestra el ajuste con la especificacin; La validacin muestra que el programa cumple las necesidades del cliente. Los planes de prueba deberan ser preparados para guiar el proceso de prueba. Las tcnicas de verificacin esttica implican el anlisis y examen del programa para la deteccin de errores.

Puntos claveLas inspecciones del programa son muy efectivas para descubrir errores. El cdigo del programa en las inspecciones es comprobado sistemticamente por un pequeo equipo para ubicar los fallos de software. Las herramientas de anlisis esttico pueden descubrir anomalas en el programa que pueden ser una indicacin de defectos en el cdigo. El proceso de desarrollo de Sala Limpia depende del desarrollo incremental, la verificacin esttica y las pruebas estadsticas.