UNIVERSIDAD POLITCNICA DE FRANCISCO I.

MADERO

INGENIERA EN SISTEMAS COMPUTACIONALES

MTODOS Y HERRAMIENTAS DE LA INGENIERA DEL SOFTWARE

VERIFICACIN Y VALIDACIN DEL SOFTWARE Ensayo Acadmico

NOMBRE DEL FACILITADOR: Lic. Vctor M. Zempoalteca Sirena

Erik Lpez Cruz

CUATRIMESTRE: 6

GRUPO: 2

FECHA DE ENTREGA: 11/06/12

NDICE
1. VERIFICACIN Y VALIDACIN DE SOFTWARE (Introduccin) ............................. 3

2. Marco referencial ............................................................................................................... 3

3. Qu es la verificacin y validacin del software? ................................................. 3 Figura 1. Planificacin de verificacin y validacin de software. ................................. 4

4. Tcnicas de validacin y verificacin estticas y dinmicas................................ 4 Figura 2. Abstraccin de la Relacin entre Evaluacin y Proceso Software. ............ 5

5. Estrategias para el desarrollo de casos de prueba ................................................. 6

6. Particularidad de las pruebas de caja blanca ............................................................ 7

7. CONCLUSIN ..................................................................................................................... 8

8. Bibliografas........................................................................................................................ 8

UNIDAD II VERIFICACIN Y VALIDACIN DE SOFTWARE

El proceso de desarrollo de software no es una tarea fcil y mucho menos se puede tomar a la ligera, ya que al ser un tarea dedicada al servicio de un tercero, se hace necesaria la necesidad de que todo salga de manera perfecta, de manera que ambas partes, servidor y cliente estn satisfechos con el producto de software que se produjo. Marco referencial Entonces, tomando en cuenta que la construccin de un sistema software tiene como objetivo satisfacer una necesidad planteada por un cliente, cmo puede saber un desarrollador si el producto construido se corresponde exactamente con lo que el cliente les pidi? y cmo puede un desarrollador estar seguro de que el producto que ha construido va a funcionar correctamente? Una de las posibles soluciones a este problema podra ser que el cliente evaluase el sistema que se ha construido una vez terminado. Sin embargo, esto tiene varias implicaciones: 1. Por una parte, puede que el cliente descubra que el producto desarrollado no cumple con sus expectativas, esto es, que el producto no hace lo que l esperara que hiciera. Sin embargo, el producto ha sido terminado, por lo que habra que comenzar de nuevo el desarrollo? 2. Por otra parte, la comprobacin que el cliente podra realizar no sirve para comprobar que no hay errores en el software, puesto que ello depende de la porcin del programa que se est ejecutando en el momento de esta comprobacin, pudiendo existir errores en otras partes del programa que no se ejecuten en ese momento. Por lo tanto, lo recomendable es que el producto software vaya siendo evaluado a medida que se va construyendo. Por lo tanto, como veremos posteriormente, se hace necesario llevar a cabo, en paralelo al proceso de desarrollo, un proceso de evaluacin o comprobacin de los distintos productos o modelos que se van generando, en el que participarn desarrolladores y clientes.

Qu es la verificacin y validacin del software? La verificacin y validacin es el nombre que se da a los procesos de comprobacin y anlisis que aseguran que el software que se desarrolla est acorde a su especificacin y cumple las necesidades de los clientes. La V&V es un proceso de ciclo de vida completo. Inicia con las revisiones de los requerimientos y contina con las revisiones del diseo y las inspecciones del cdigo hasta la

prueba del producto. Existen actividades de V&V en cada etapa del proceso de desarrollo del software. La verificacin y la validacin no son la misma cosa (Boehm, 1979): Verificacin: Estamos construyendo el producto correctamente? El papel de la verificacin comprende comprobar que el software est de acuerdo con su especificacin. Se comprueba que el sistema cumple los requerimientos funcionales y no funcionales que se le han especificado. Validacin: Estamos construyendo el producto concreto? La validacin es un proceso ms general. Se debe asegurar que el software cumple las expectativas del cliente. Va ms all de comprobar si el sistema est acorde con su especificacin, para probar que el software hace lo que el usuario espera a diferencia de lo que se ha especificado.

En el siguiente cuadro se muestra la planificacin que se tiene que hacer para la realizacin de la V&V.

Figura 1. Planificacin de verificacin y validacin de software.

Tcnicas de validacin y verificacin estticas y dinmicas Tanto para la realizacin de verificaciones como de validaciones se pueden utilizar distintos tipos de tcnicas. En general, estas tcnicas se agrupan en dos categoras:

Tcnicas de Evaluacin Estticas: Buscan faltas sobre el sistema en reposo. Esto es, estudian los distintos modelos que componen el sistema software buscando posibles faltas en los mismos. As pues, estas tcnicas se pueden aplicar, tanto a requisitos como a modelos de anlisis, diseo y cdigo. Tcnicas de Evaluacin Dinmicas: Generan entradas al sistema con el objetivo de detectar fallos, al ejecutar dicho sistema sobre esas entradas. Esto es, se pone el sistema a funcionar buscando posibles incongruencias entre la salida esperada y la salida real. La aplicacin de tcnica dinmicas es tambin conocido como pruebas del software o testing y se aplican generalmente sobre cdigo que es, hoy por hoy, el nico producto ejecutable del desarrollo.

Figura 2. Abstraccin de la Relacin entre Evaluacin y Proceso Software.

La Figura 2 muestra en detalle la aplicacin de las tcnicas estticas y dinmicas para evaluar software. La evaluacin esttica (conocida con el nombre genrico de Revisiones) se realiza en paralelo al proceso de construccin, constando de una actividad de evaluacin emparejada con cada actividad de desarrollo. Es decir, la actividad de Definicin de Requisitos de Usuario va acompaada de una actividad de Revisin de Requisitos de Usuario, la actividad de Definicin de Requisitos Software va emparejada con su correspondiente actividad de revisin y as, sucesivamente. Las actividades de revisin marcan el punto de decisin para el paso a la siguiente actividad de desarrollo.

La razn para buscar defectos en productos tempranos es porque stos se traducen en defectos en el producto final. Es decir, defectos en los requisitos se traducirn en defectos en el sistema final. Si un diseo contiene defectos, seguramente estos defectos se trasmitirn al cdigo cuando los programadores usen ese diseo como gua para su trabajo. La deteccin temprana de errores acarrea grandes beneficios. Si las revisiones nicamente se aplican al cdigo mejoran la calidad y producen ahorros en los costos del proyecto. Pero los ahorros son mayores si se inspeccionan artefactos tempranos del desarrollo. Estudiando los resultados publicados sobre ahorros con las revisiones, puede afirmarse que la utilizacin de inspecciones de cdigo produce un ahorro del 39% sobre el coste de detectar y corregir defectos, frente a nicamente utilizar la evaluacin dinmica. Sin embargo, el ahorro es del 44% si se inspecciona tambin el diseo.

La experiencia demuestra que entre el 30% y el 70% de los defectos, de diseo y cdigo son detectados por las tcnicas estticas. Esto supone un gran ahorro, pues la correccin es ms fcil y menos costosa durante la evaluacin esttica que durante la dinmica. Ntese que cuando durante la evaluacin dinmica del sistema se detecta un fallo en un programa, lo que se detecta es el fallo, no la falta que lo provoca. Es decir, tras la deteccin del fallo, se requiere una labor de localizacin en el programa de la falta que provoc el fallo. Sin embargo, con las tcnicas estticas, lo que se detecta son directamente faltas. Por tanto, una vez detectada, se puede pasar a la fase de correccin. Es decir, desaparece la tarea de localizacin de la falta. Esto significa, que las tcnicas estticas son ms baratas por falta que las dinmicas.

Estrategias para el desarrollo de casos de prueba La prueba de software implica la ejecucin de la implementacin de una manera controlada y utilizando datos de entrada cuidadosamente seleccionados para

luego observar el resultado. La prueba de software es un aspecto de la garanta de la calidad de software (Software Quality Assurance o SQA). Un caso de prueba se disea para ejercer una ejecucin particular o para verificar la conformidad con un requisito especfico. El objetivo de la prueba de software es encontrar errores y NO demostrar su ausencia, se debera probar que la aplicacin hace lo que tiene que hacer adems de generar los enfoques necesarios (caja negra y caja blanca). Toda prueba debe constar de varias fases (pruebas de unidades, de integracin y de sistema) que cubran todas las reas del sistema eligiendo los datos adecuados para deducir buenos resultados de las pruebas.

Particularidad de las pruebas de caja blanca A este tipo de tcnicas se le conoce tambin como Tcnicas de Caja Transparente o de Cristal. Este mtodo se centra en cmo disear los casos de prueba atendiendo al comportamiento interno y la estructura del programa. Se examina as la lgica interna del programa sin considerar los aspectos de rendimiento. El objetivo de la tcnica es disear casos de prueba para que se ejecuten, al menos una vez, todas las sentencias del programa, y todas las condiciones tanto en su vertiente verdadera como falsa. Como se ha indicado ya, puede ser impracticable realizar una prueba exhaustiva de todos los caminos de un programa. Por ello se han definido distintos criterios de cobertura lgica, que permiten decidir qu sentencias o caminos se deben examinar con los casos de prueba. Estos criterios son: - Cobertura de Sentencias: Se escriben casos de prueba suficientes para que cada sentencia en el programa se ejecute, al menos, una vez. - Cobertura de Decisin: Se escriben casos de prueba suficientes para que cada decisin en el programa se ejecute una vez con resultado verdadero y otra con el falso. - Cobertura de Condiciones: Se escriben casos de prueba suficientes para que cada condicin en una decisin tenga una vez resultado verdadero y otra falso. - Cobertura Decisin/Condicin: Se escriben casos de prueba suficientes para que cada condicin en una decisin tome todas las posibles salidas, al menos una vez, y cada decisin tome todas las posibles salidas, al menos una vez. - Cobertura de Condicin Mltiple: Se escriben casos de prueba suficientes para que todas las combinaciones posibles de resultados de cada condicin se invoquen al menos una vez. - Cobertura de Caminos: Se escriben casos de prueba suficientes para que se ejecuten todos los caminos de un programa. Entendiendo camino como una secuencia de sentencias encadenadas desde la entrada del programa hasta su salida.

CONCLUSIN

Bibliografas:

Introduccin a la Ingeniera del software

Autores: Simn Pickin Marisol Garca Valls

TCNICAS DE EVALUACIN DE SOFTWARE

Versin: 12.0 Fecha: 17 de octubre de 2005 Autoras: Natalia Juristo, Ana M. Moreno, Sira Vegas

Ingeniera Software
4 Fsicas Ingeniera de Programacin 2009