Material para exponer VV

Resumen

La verificacin y validacin es una actividad que juega un papel importante en la consecucin

de procesos y productos de calidad.

. Por ello y dado los problemas que histricamente han surgido en los desarrollos software,
su estudio y mejora supone un avance importe para la futura evolucin de las tecnologas de la
informacin.

Para lo cual se presentan algunos conceptos que influyen directamente en el desarrollo de la

verificacin y validacin software como son: los modelos de calidad, los modelos de mejora del
proceso de pruebas, las estructuras organizativas, las competencias y los perfiles
profesionales.

Introduccion

El siguiente trabajo de investigacin tiene como finalidad dar a conocer todo lo referente al
proceso de verificacin y validacin en el desarrollo de software, as como tambin extender el
conocimiento sobre los conceptos de inspeccin de software, pruebas de software y las
herramientas necesarias para realizar estas, adems de entender el ciclo de vida de las
pruebas de software basndose en sus 4 pasos: Planear, Ejecutar, Chequear y Actuar.

1. PROCESOS DE VERIFICACIN Y VALIDACIN DEL SOFTWARE

El proceso de validacin y verificacin (V&V), es un conjunto de 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.

El objetivo del proceso de verificacin y validacin es establecer la seguridad de que el sistema

software est hecho para un propsito. Esto significa que el sistema debe ser lo
suficientemente bueno para su uso pretendido.

El nivel de confianza requerido depende del propsito del sistema, las expectativas de los
usuarios del sistema y el entorno de mercado actual del sistema:

Funcin del software: El nivel de confianza requerido depende de lo crtico que sea el
software para una organizacin. Por ejemplo, el nivel de confianza requerido para el software
que se utiliza para controlar un sistema de seguridad critico es mucho ms alto que el
requerido para un prototipo de un sistema software que ha sido desarrollado para demostrar
algunas ideas nuevas.

Expectativas del usuario: Una reflexin lamentable sobre la industria del software es que
muchos usuarios tienen pocas expectativas sobre su software y no se sorprenden cuando ste
falla durante su uso. Estn dispuestos a aceptar estos fallos del sistema cuando los beneficios
de su uso son mayores que sus desventajas. Sin embargo, la tolerancia de los usuarios a los
fallos de los sistemas est decreciendo desde los aos 90. Actualmente es menos aceptable
entregar sistemas no fiables, por lo que las compaas de software deben invertir ms esfuerzo
para verificar y validar.

Entorno de mercado: Cuando un sistema se comercializa, los vendedores del sistema deben
tener en cuenta los programas competidores, el precio que sus clientes estn dispuestos a
pagar por el sistema y la agenda requerida para entregar dicho sistema. Cuando una compaa
tiene pocos competidores, puede decidir entregar un programa antes de que haya sido
completamente probado y depurado, debido a que quiere ser el primero en el mercado.
Cuando los clientes no estn dispuestos a pagar precios altos por el software, pueden estar
dispuestos a tolerar ms defectos en l. Todos estos factores pueden considerarse cuando se
decide cuanto esfuerzo debera invertirse en el proceso V&V.

1.1 OBJETIVOS

El objetivo primordial del proceso de verificacin y validacin es la seguridad de que el sistema

est hecho para un propsito, es decir que el sistema debe ser lo bastante bueno para su uso
pretendido.

1.2 TCNICAS DE VERIFICACIN Y VALIDACIN

1.2.1 Tcnicas Estticas (Revisiones)

Revisin de software: analizan y comprueban las representaciones del sistema tales como el
documento de requerimientos, diagramas de diseo y cdigo fuente del programa. Puede
usarse en todas las etapas del proceso.

Las revisiones software pueden ser

Informales No hay procedimientos definidos, por lo que la revisin se realiza de la forma ms

flexible posible

Ventajas: menor coste y esfuerzo, preparacin corta, etc.

Desventajas: Detectan menos defectos.

Semi - Formales Se definen unos procedimientos mnimos a seguir (walkthroughs).

Formales (Inspecciones) Se define completamente el proceso. Revisin en detalle, por una

persona o grupo distintos del autor, para: Verificar si el producto se ajusta a sus
especificaciones o atributos de Calidad y a los estndares utilizados en la empresa. Sealar
las desviaciones sobre los estndares y las especificaciones. Recopilar datos que realimenten
inspecciones posteriores (defectos recogidos, esfuerzo empleado, etc.)

1.2.2 Tcnicas Dinmicas (Pruebas)

Pruebas de software: Consiste en contrastar las respuestas de una implementacin del

software a series de datos de prueba y examinar las respuestas del software y su
comportamiento operacional, para comprobar que se desempee conforme a lo requerido.
Llevar a cabo las pruebas es una tcnica dinmica de la verificacin y validacin ya que
requiere disponer de un prototipo ejecutable del sistema. Las tcnicas de inspeccin
comprenden las inspecciones del programa el anlisis automtico del cdigo fuente y la
verificacin formal.

Sin embargo las tcnicas estticas solo pueden comprobar la correspondencia entre un
programa y su especificacin (verificacin) no pueden demostrar que el software es
operacionalmente til. Tampoco se pueden usar tcnicas estticas para comprobar las
propiedades emergentes del software como rendimiento y fiabilidad.

1.3 PLANIFICACIN

La verificacin y validacin es un proceso caro, es necesario una planificacin cuidadosa para

obtener el mximo provecho de las inspecciones y pruebas controlando los costos del proceso
de verificacin y validacin.

Debera comenzarse desde etapas tempranas del proceso de desarrollo. Como parte del
proceso de planificacin de verificacin y validacin habra que decidir un equilibrio entre las
aproximaciones estticas y dinmicas de la verificacin y validacin, pensar en estndares y
procedimientos para las inspecciones y pruebas de software, establecer listas de
comprobacin y definir el plan de pruebas de software.

La planificacin de las pruebas est relacionada con el establecimiento de estndares para el

proceso de pruebas, no solo con la descripcin de los productos de las pruebas.

Los principales componentes de un plan de pruebas para un sistema grande son:

El proceso de pruebas: Una descripcin de las principales fases del proceso de prueba.

Trazabilidad de requerimientos: Los usuarios son los ms interesados que el sistema sea de
calidad.

Elementos probados: deberan especificarse los elementos que van a ser probados.

Calendarios de pruebas: Un calendario de todas las pruebas y asignacin de recursos

. Procedimiento de registro de pruebas: No es suficiente ejecutar simplemente las pruebas,

los resultados deben ser registrados sistemticamente.

2. INSPECCIONES DE SOFTWARE

Analizan y comprueban las representaciones del sistema (los diagramas de diseo, el cdigo
fuente del programa). Se aplica a todas las etapas del proceso de desarrollo y se
complementan con algn tipo de anlisis automtico del texto fuente y documentos
asociados.

Son tcnicas de verificacin y validacin estticas, no requieren que el sistema se ejecute.

Se contrasta estticamente las diferentes representaciones del sistema (Diagramas de

requerimientos, diagramas de diseo y cdigo fuente) en bsqueda de defectos.
Caracteristicas:

No requiere que el cdigo se ejecute

Debe realizarse durante todo el ciclo de desarrollo (IMAGEN)

2.1 Ventajas

Existen 3 ventajas fundamentales de la inspeccin sobre las pruebas

Durante las pruebas los errores pueden enmascarar otros errores. Cuando se descubre un
error nunca se puede estar seguro de si otras anomalas de salida son debidas a un nuevo error
o son efectos laterales del error original

. Pueden inspeccionarse versiones incompletas de un sistema sin costes adicionales.

Uso de recursos compartidos

Una inspeccin tambin puede considerar atributos de calidad ms amplios de un

programa tales como grado de cumplimiento con los estndares portabilidad y
mantenibilidad.

2.2 El Proceso de Inspeccin de Programas

Son revisiones cuyo objetivo es la deteccin de defectos en el programa.

Actualmente es un mtodo bastante utilizado de verificacin de programa, especialmente en

ingeniera de sistemas crticos. La diferencia principal entre las inspecciones de programas y
otros tipos de revisiones de calidad es que el objetivo primordial de las inspecciones es
encontrar defectos en el programa en lugar de considerar cuestiones de diseo ms generales.

La inspeccin de programas es un proceso formal realizado por un equipo de al menos cuatro

personas. Los miembros del equipo analizan sistemticamente el cdigo y sealan posibles
defectos, podemos observar los principales roles que asumen los miembros del equipo en la
Tabla 1 (IMAGEN)

2.3Actividades en el Proceso de Inspeccin

Las Actividades que debe seguir un proceso de inspeccin son:

Planificacin: El moderador del equipo de inspeccin es el responsable de la planificacin de

la inspeccin. Esto implica seleccionar un equipo de inspeccin, organizar una sala de
reuniones y asegurar que el material a inspeccionar y sus especificaciones estn completas.

Visin de conjunto: El programa a inspeccionar se presenta al equipo de inspeccin durante

la etapa de revisin general cuando el autor del cdigo describe lo que el programa debe
hacer.

Preparacin Individual: A continuacin cada miembro del equipo estudia la especificacin, el

programa y busca defectos en el cdigo.
 Reunin de inspeccin: La inspeccin en si misma debera ser bastante corta no mayor a dos
horas y debera centrarse en la deteccin de defectos, cumplimiento de estndares y detectar
programacin de baja calidad.

Repeticin de trabajo: El autor del programa deber realizar los cambios para corregir los
problemas identificados. En esta etapa el moderador deber decidir si se requiere una re-
inspeccin de cdigo o es aprobado.

Durante una inspeccin a menudo se utiliza una lista de comprobacin de errores de

programacin comunes para centrar el anlisis.

2.4 Comprobaciones de Inspeccin

Las comprobaciones de inspeccin son las principales inspecciones que se realizan en el

software.

(INCLUIR LA TABLA)

3. LISTA DE FALLOS O ERRORES

El proceso de inspeccin siempre se realiza utilizando una lista de los errores comunes de los
programadores. Esta se somete a discusin por el personal con experiencia y se actualiza
frecuentemente segn se vaya teniendo experiencia.

La lista de errores debe estar en funcin del lenguaje de programacin que se utilice

La cantidad de cdigo que se puede inspeccionar debe estar limitado, ya que a partir de un
tiempo de inspeccin se baja la atencin y se hace ineficaz. Existen estudios que establecen

Fallos de datos:

1. Las variables se inicializan antes que de que se utilicen los valores?

2. Todas las constantes tienen nombre?

3. El lmite superior de los arrays es igual al tamao de los mismos?

Fallos de control:

1. Para cada instruccin condicional Es correcta la condicin?

2. Todos los ciclos terminan?

3. Los bloques estn delimitados correctamente?

Fallos de entrada/salida:

1. Se utilizan todas las variables de entrada?

2. Antes de que salgan Se le han asignado valores a las variables de salida?

Fallos de la interfaz:
Fallos de gestin de almacenamiento:

Fallos de gestin de las excepciones:

4. PRUEBAS DE SOFTWARE

Las Pruebas de Software son una actividad ms en el proceso de "Aseguramiento de la

Calidad"

Las Pruebas son bsicamente un conjunto de actividades dentro del desarrollo de software.
Dependiendo del tipo de pruebas, estas actividades podrn ser implementadas en cualquier
momento de dicho proceso de desarrollo.

4.1 Tipos de Pruebas

4.1.1 Revisiones de Cdigo

Las revisiones de cdigo son las nicas que se podran omitir de todos los tipos de pruebas,
pero tal vez sea buena idea por lo menos hacer alguna de ellas:

Pruebas de escritorio

La prueba de escritorio rinde muy poco, tal vez menos de lo que cuesta, pero es una
costumbre difcil de desterrar

Recorridos de cdigo

Los recorridos rinden mucho ms.

. Inspecciones de cdigo

Las llamadas inspecciones de cdigo consisten en reuniones en conjunto entre los

responsables de la programacin y los responsables de la revisin. Tienen como objetivo
revisar el cdigo escrito por los programadores para chequear que cumpla con las normas que
se hayan fijado y para verificar la eficiencia del mismo.

4.1.2 Pruebas Unitarias

Las pruebas unitarias se realizan para controlar el funcionamiento de pequeas porciones de

cdigo como ser subprogramas (en la programacin estructurada) o mtodos (en POO).

Generalmente son realizadas por los mismos programadores puesto que al conocer con mayor
detalle el cdigo, se les simplifica la tarea de elaborar conjuntos de datos de prueba para
testearlo.

Si bien una prueba exhaustiva sera impensada teniendo en cuenta recursos, plazos, etc., es
posible y necesario elegir cuidadosamente los casos de prueba para recorrer tantos caminos
lgicos como sea posible.

4.1.3 Pruebas de Integracin

Las pruebas de integracin tienen como base las pruebas unitarias y consisten en una
progresin ordenada de testeos para los cuales los distintos mdulos van siendo
ensamblados y probados hasta haber integrado el sistema completo.

Si bien se realizan sobre mdulos ya probados en forma individual, no es necesario que se

terminen todas las pruebas unitarias para comenzar con las de integracin.

4.1.4 Pruebas de Sistema

Las pruebas de sistema se realizan una vez integrados todos los componentes.

Su objetivo es ver la respuesta del sistema en su conjunto, frente a distintas situaciones. Se

simulan varias alternativas que podran darse con el sistema implantado y en base a ellas se
prueba la eficacia y eficiencia de la respuesta que se obtiene.

Pruebas de Aceptacin

Las pruebas de aceptacin, al igual que las de sistema, se realizan sobre el producto
terminado e integrado; pero a diferencia de aquellas, estas estn concebidas para que sea
un usuario final quien detecte los posibles errores.

Se clasifican en dos tipos: Pruebas Alfa y Pruebas Beta.

Las pruebas Alfa se realizan por un cliente en un entorno controlado por el equipo de
desarrollo. Para que tengan validez, se debe primero crear un ambiente con las mismas
condiciones que se encontrarn en las instalaciones del cliente. Una vez logrado esto, se
procede a realizar las pruebas y a documentar los resultados.

Por otro lado, las pruebas Beta se realizan en las instalaciones propias de los clientes.

Para que tengan lugar, en primer trmino se deben distribuir copias del sistema para que cada
cliente lo instale en sus oficinas, dependencias y/o sucursales.

4.2 Pruebas de defecto

El objetivo de las pruebas de defecto es detectar los defectos latentes de un sistema software
antes de entregar el producto.

Una prueba de defectos exitosa es aquella que descubre un fallo, esto es, un
comportamiento contrario a la especificacin.
Las pruebas de defectos demuestran la existencia de un fallo, y no la ausencia de
cualquier fallo.

Las pruebas exhaustivas no son posibles y deben sustituirse por subconjuntos de casos de
prueba. Se deben establecer polticas para establecer esos casos de prueba. Por ejemplo:

Que todas las instrucciones del programa se ejecuten al menos una vez
Se deben probar todas las funciones del sistema que se acceden a travs de men.
Si la entrada es introducida por el operador, todas las funciones deben probarse con
entradas correctas e incorrectas.