V & V

1. UNIDAD I
Introducción al proceso de verificación y validación.
VALIDACIÓN Y VERIFICACIÓN.-
El proceso de control que asegura que el software cumple con su especificación y satisface las
necesidades del usuario Muchas veces se confunde “verificación” con validación”. Boehm
(1979) puso en claro con pocas palabras la diferencia:
• Validación: ¿Estamos construyendo el producto correcto? Se ocupa de controlar si el producto
satisface los requerimientos del usuario
• Verificación: ¿Estamos construyendo correctamente el producto? implica controlar que el
producto conforma su especificación inicial
1.1 Contextualización de la verificación y validación.

2. Verificación y Validación
de Software
1.1 Contextualización de la Verificación y
Validación

3. Verificación y Validación v&v
 Conjunto de procesos de comprobación y
análisis que aseguran que el software que se
desarrolla está acorde a su especificación y
cumple las necesidades de los clientes.

4. Verificación
 ¿Estamos construyendo el producto
correctamente?
 Se prueba que el software cumple los
requisitos funcionales y no funcionales de su
especificación.

5. Validación
 ¿Estamos construyendo el producto
correcto?
 Comprueba que el software cumple las
expectativas que el cliente espera.

6. Importante
 Nunca se va a poder demostrar que el
software está completamente libre de
defectos.

7. Objetivos de V&V
 Descubrir defectos (para corregirlos)
 Provocar fallas (una forma de detectar
defectos)
 Revisar los productos
 Evaluar la calidad de los productos
 El probar o revisar el software da una idea de
la calidad del mismo.

8. Identificación y Corrección de
Defectos
 Identificación de defectos
 Es el proceso de determinar que defecto o
defectos causaron la falla.
 Corrección de defectos
 Es el proceso de cambiar el sistema para
remover los defectos.

9. Ejemplo
 El programa lee tres números enteros, los
que son interpretados como
representaciones de las longitudes de los
lados de un triángulo. El programa escribe un
mensaje que informa si el triángulo es
escaleno, isósceles o equilátero.
 Quiero detectar defectos probando el
programa

10.  Posibles casos a probar:
 Lado1 = 0, lado2 = 1, lado3 = 0
 Resultado = error
 Lado1 = 2, lado = 2, lado3 = 3
 Resultado = isósceles
 Estos son Casos de Prueba

11.  Después se compara el resultado esperado con el
obtenido.
 Si son distintos probablemente haya fallado el
programa.
 Intuitivamente que otros caos sería bueno probar.
 Lado1 = 2, lado2 = 3, lado3 = 4
 Resultado = escaleno
 Casos de prueba para cada posible respuesta del
programa (error, escaleno, isósceles, equilátero.)

12. ¿Quién Verifica?
 Los desarrolladores
 Verificadores (especialistas en verificación)
 Depende de los tipos de pruebas que se
vallan a aplicar.

13. Revisiones
 Informales
 Semi-formales
 Formales

14. Informales
 No hay procedimientos definidos, por lo que la
revisión se realiza de la forma más flexible.
 Ventajas -> menor coste y esfuerzo,
preparación corta, etc.
 Desventajas ->Detectan menos defectos.

15. Semi-formales
 Se definen unos procedimientos mínimos a
seguir.

16. Formales
 Se define completamente el proceso.
 Revisión 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
estándares utilizados en la empresa.
 Señalar las desviaciones sobre los estándares
y las especificaciones.
 Recopilar datos que realimenten inspecciones
posteriores (defectos recogidos, esfuerzo
empleado, etc.)

18. Terminología de
proceso del software

19. El Proceso de Desarrollo Software

20.  El SDP define el qué, quién, cuándo y cómo del desarrollo de
software.
 Cuatro actividades fundamentales que son comunes para todos
los procesos de desarrollo de software :
—Especificación del software
—Desarrollo del software
—Validación del software
—Evolución del software
 Modelo de proceso:
—Descripción simplificada (abstracción) de un proceso de
desarrollo de software real.

21. Ejemplo: Proceso en Cascada

22. Enfoques y Nomenclaturas

23. Testing: terminología básica
• Error: desatino del programador (el cual resulta en la introducción de un bug).
• Defecto, “bug”: manifestación concreta del error de programación en el código.
• Falla: resultado de la ejecución de un bug.
Un test es una prueba de software, compuesta usualmente por:
• una precondición (condiciones bajo las cuales se ejecuta el código a testear),
• una porción de código (bloque a testear).
• una condición de aceptación (criterio para saber si el código “pasó” la prueba).

24. Testing: clasificaciones básicas
Existen diferentes tipos de testing, de acuerdo a las características de sus partes.
Algunos de estos tipos son los siguientes:
• Sistema: el bloque a testear es todo el sistema.
• Integración: el bloque a testear es la composición de varios módulos, y la condición
de aceptación corresponde a propiedades de la ejecución combinada de los módulos.
• Regresión: la condición de aceptación es preservar el comportamiento de versiones
anteriores del software.
• Diferencial: la condición de aceptación es mantener un comportamiento similar a
otro software con el mismo propósito que el testeado.

26. El proceso de verificación y
validación.

28. • La Verificación y Validación deberían conceder
confianza en que el software alcanza su
propósito.
• Esto NO significa que esté libre de defectos
• Mas bien debería ser lo suficientemente bueno
para su uso y el tipo de uso determinará el grado
de confianza que es necesaria

29. Calidad de Software.

30. Fallas de software.
una falla de software ocurre cuando un
programa no cumple con las
especificaciones, es decir, con el
comportamiento esperado de dicho
programa.

31. Verificación y Validación

32. V&V Estática y dinámica
• Inspecciones de Software: relacionadas con
el análisis de una representación estática de un
sistema para descubrir problemas (V&V
estática)
• –Puede ser un suplemento de un documento
basado en una herramienta y análisis de código
• Prueba de Software: relacionadas con
pruebas y observaciones del comportamiento
del producto (V&V dinámica)
• –El sistema es ejecutado con datos de prueba y
es observado su comportamiento operacional

36. proceso de pruebas de software
• La forma más común de organizar las actividades relacionadas al
proceso de pruebas de software [Burnstein, 2003] son:
• Planeación, fija las metas y una estrategia general de pruebas
• Preparación, se describe el procedimiento general de pruebas y se
generan los casos de prueba específicos
• Ejecución, incluye la observación y medición del comportamiento
del producto
• Análisis, incluye verificación y análisis de resultados para
determinar si se observaron fallas
• Seguimiento, si se detectaron fallas, se inicia un monitoreo para
asegurar que se remueva el origen de éstas

38. Tipos de Errores
Existen tres tipos de errores:
• De sintaxis (sintácticos).
• De ejecución.
• De lógica (lógicos).

39. Errores de sintaxis
• Cuando en alguna instrucción del código fuente de un programa
existe un error de sintaxis, dicho error impedirá, tanto al
compilador como al intérprete, traducir dicha instrucción, ya que,
ninguno de los dos entenderá qué le está diciendo el programador.
Por ejemplo, en lenguaje C, si en vez de la instrucción:

40. printf( "n Introduzca el primer numero (entero): " ); un programador escribe:
prrintf( "n Introduzca el primer numero (entero): " );
cuando el compilador o el intérprete lean esta línea de código, ninguno de los
dos entenderá qué es "prrintf" y, por tanto, no sabrán traducir esta instrucción a
código máquina, por lo que, ambos pararán la traducción y avisarán al
programador con un mensaje de error.
En resumen, los errores de sintaxis se detectan en el proceso de traducción del
código fuente a código binario. Al contrario que ocurre con los errores de
ejecución y de lógica, que sólo se pueden detectar cuando el programa se está
ejecutando.

41. Errores de ejecución
Un error de ejecución se produce cuando el ordenador no puede ejecutar
alguna instrucción de forma correcta. Por ejemplo, en lenguaje C, la
instrucción:
c = 5 / 0;
es correcta sintácticamente y será traducida a código binario. Sin embargo,
cuando la computadora intente realizar la división:
5 / 0
se producirá un error de ejecución, ya que, matemáticamente, no se puede
dividir entre cero.

42. Errores de lógica
En cuanto a los errores de lógica son los más difíciles de detectar. Cuando un programa no
tiene errores de sintaxis ni de ejecución, pero, aún así, no funciona bien, esto es debido a la
existencia de algún error lógico. De manera que, un error de lógica se produce cuando los
resultados obtenidos no son los esperados. Por ejemplo, en lenguaje C, si en vez de la
instrucción:
c = a + b;
un programador hubiera escrito:
c = a * b;
hasta que no se mostrase por pantalla el resultado de la operación, el programador no podría
darse cuenta del error, siempre que ya supiese de antemano el resultado de la suma. En este
caso, el programdor podría percatarse del error fácilmente, pero, cuando las operaciones son
más complejas, los errores de lógica pueden ser muy difíciles de detectar.

43. Responsabilidad
de Pruebas
El Metodo Fagan
El Equipo
Moderador
Diseñador
Implementador/Codificador
Encargado de Pruebas
El Plan de Pruebas
Responsabilidad de errores.mmap - 04/06/2014 - Mindjet

44. TEMA: RESPONSABILIDAD DE ERRORES
NOMBRE DE LA ASIGNATURA: VERIFICACIÓN Y VALIDACIÓN DEL SOFTWARE
INTEGRANTES DEL EQUIPO:
RAFAEL VALLE CASTELÁN
JUAN DE DIOS RAMÍREZ VIVAR
NOMBRE DEL PROFESOR: L.C.C. MIGUEL FUENTES CORTES
CARRERA: INGENIERÍA INFORMÁTICA
SEMESTRE: 8º.
GRUPO: “C”
DEL DOCENTE: L.I. RAÚL GARCÍA HERRERA
ACATLÁN DE OSORIO PUE; A 24 DE MAYO DE 2014.

45. Responsabilidad de Errores
 ¿Qué se busca ?
La reducción de defectos, fallas, errores,
etc. en el sistema de software.

46. EL MÉTODO FAGAN PARA INSPECCIONES
 El método de inspección más utilizado hasta
el momento, es el de Fagan (1976).
 Fagan (1976) menciona que las inspecciones
son un método formal, eficiente y económico
para encontrar errores en el diseño y el
código.
 Para su método, Fagan propone un conjunto
de roles y un proceso a seguir durante las
inspecciones.

47. El equipo
 Moderador
 Diseñador
 Implementador/Codificador
 Encargado de pruebas

48. El Moderador
 Es la persona clave en una inspección exitosa.
 Debe ser un programador competente, pero no necesita ser un
técnico experto en el programa siendo inspeccionado.
 Es recomendable usar un moderador de un proyecto no
relacionado, para preservar la objetividad, e incrementar la
integridad de la inspección.
 Debe administrar al equipo de inspección y ofrecer un
liderazgo.
 Sus tareas incluyen:
 Calendarizar reuniones y lugares de reunión
 Reportar los resultados de la inspección
 Dar seguimiento al retrabajo

49. EL DISEÑADOR
 Es el responsable de producir el diseño del programa.
EL IMPLEMENTADOR/CODIFICADOR
 El responsable de transformar el diseño en código.
EL ENCARGADO DE LAS PRUEBAS
 El responsable de escribir y/o ejecutar los casos de prueba o
alguna otra forma de probar los productos del diseñador y el
codificador.

50. El plan de pruebas
Es un documento que describe el enfoque que será utilizado
para las actividades de pruebas, e incluye:
 Los elementos a ser probados
 Los tipos de pruebas que serán realizadas
 El calendario de pruebas
 Los recursos humanos
 Procedimientos de reporte
 Criterios de evaluación,
 etc.

51. CALENDARIZACIÓN
 Fagan menciona que cuatro miembros es un buen tamaño
para el equipo de inspección. Sin embargo, puede crecer
si el programa tiene interfaces con otros, dado que los
programadores de estas interfaces deberían también
participar en las inspecciones.
 Fagan también menciona que con un grupo de cuatro, las
inspecciones llevarán entre 90 y 100 horas hombre.
 Recomienda que las reuniones de inspección no
sobrepasen las dos horas, y que dos reuniones de dos
horas al día es aceptable.
 El tiempo para realizar las inspecciones y el retrabajo
resultante, debe calendarizarse como cualquier otra
actividad importante del proyecto.

52. EL PROCESO
Fagan propone un proceso de inspección
constituido por las siguientes actividades
 1.Vista general
 2.Preparación
 3.Inspección
 4.Retrabajo
 5.Seguimiento

53. 1.-VISTA GENERAL
 Participa todo el equipo.
 El diseñador describe el área general que será
abordada, y entonces especifica el área que él ha
diseñado en detalle (lógica, caminos,
dependencias, etc.).
 La documentación del diseño se distribuye entre
todos los participantes.
 En la inspección de código se requiere usar el
listado del código y la especificación de diseño
como material de la inspección.
 En la segunda inspección, el moderador debe
tener un especial escrutinio de todas las partes
que hayan sido modificadas después de la
inspección de diseño, ya sea por retrabajo debido
a errores, o por alguna otra causa.

54. 2.-PREPARACIÓN
 Es una actividad individual.
 Los participantes tratan de entender el diseño, su
intención y lógica.
 Algunos errores se pueden encontrar durante esta
proceso, pero no suelen ser tantos como durante
la reunión de inspección.
 Se debe estudiar la distribución de tipos de
errores de inspecciones anteriores, para
concentrarse en las áreas que con mayor
probabilidad podrían tener errores.
 También se debe estudiar las listas de verificación
de errores.

55. 3.-INSPECCIÓN
 Se realiza por todo el equipo.
 Un lector, elegido por el moderador, describe
cómo implementará el diseño.
 Parafrasea el diseño de la forma en que lo expresó
el diseñador.
 Cada pieza de lógica es cubierta al menos una vez,
y cada rama es tomada al menos una vez.
 Durante la inspección se debe contar con:
 Toda la documentación de alto nivel,
especificación de diseño de alto nivel,
especificación de lógica, etc.

56. 3.-INSPECCIÓN
 Listado de bloques de control
 Una vez que se entendió el diseño, el objetivo es
encontrar errores.
 Hasta que un error se descubre, se realizan
preguntas.
 El moderador captura los errores, clasifica su tipo,
e identifica su severidad (menor, mayor, etc.), y se
continúa con la inspección.
 Si la solución del problema es obvia, se anota,
pero no se espera definir soluciones durante la
inspección.
 Al finalizar las conclusiones de las inspecciones del
día, el moderador debe escribir un reporte de las
inspecciones y sus resultados para asegurarse que
se tomen en cuenta en las operaciones de
retrabajo y seguimiento.

59. 4.-RETRABAJO
 Todos los errores o problemas detectados en la
inspección son resueltos por el diseñador o
implementador/codificador
5.-SEGUIMIENTO
 Es responsabilidad del moderador asegurarse de
que todos los aspectos, errores, problemas, etc.
descubiertos en la inspección hayan sido resueltos
por el diseñador o el implementador/codificador
en su caso.
 Si más de un 5% del material ha sido retrabajado,
se recomienda realizar una nueva inspección del
100%.
 En otro caso, el moderador puede usar su criterio
para determinar la calidad del retrabajo por él
mismo, o programar una reinspección de una parte
o todo el trabajo.

60. CONCLUSIONES:
 Las inspecciones incrementan la productividad y la
calidad del sistema. También ayudan a mejorar el
control del proceso y la administración de los
proyectos por que las inspecciones pueden ayudar
a encontrar entre un 60 y 90% de los errores.

62. INTRODUCCIÓN AL PROCESO DE
VERIFICACIÓN Y VALIDACIÓN.
ORGANIZACIÓN DE PROCESOS DE
PRUEBAS

63. EXISTEN DIVERSOS TIPOS DE PRUEBAS COMO.
• Unitarias:
• Integración:
• construcción
• Funcionales
• Transición
• Aceptación

64. ALGUNAS DEFINICIONES
• Estrategia: se refiere al conjunto de acciones planificadas anticipadamente,
cuyo objetivo es alinear los recursos y potencialidades de una empresa para
el logro de sus metas y objetivos
• La planificación es el proceso metódico diseñado para obtener
un objetivo determinado

65. ESTRATEGIA DE PRUEBAS
• Planea la estrategia que se va a seguir para analizar, diseñar, implementar y
ejecutar las pruebas de algún proyecto Así mismo se define qué tipos de
pruebas se van a realizar y cómo se ejecutarán.

66. RECURSOS DEL PLAN DE PRUEBAS:
• Se identifican los recursos humanos y no humanos (hardware, software,
herramientas de soporte, configuración de entorno de pruebas, entre otros),
necesarios para desarrollar el proceso del plan de pruebas de la solución del
Sistema.

67. EVALUACIÓN DE PRUEBAS EJECUTADAS
• Describe los métodos de evaluación de las pruebas ejecutadas, de tal forma
que permitirá evaluar los grados de aceptación de las pruebas.
• se describen los documentos anexos que se utilizarán para la especificación y
la documentación de la ejecución de las pruebas.

68. TÉCNICAS DE ESPECIFICACIÓN DE LAS PRUEBAS
•es la aplicación de las estrategias planificadas
previamente haciendo uso de los recursos disponibles
para estas.

69. CICLO DEL PLAN DE PRUEBAS
. Cronograma detallado de la ejecución de las pruebas es un documento donde
se especifica qué prueba se realiza, cuánto tiempo se estima para su ejecución,
recursos a utilizar (humanos y tecnológicos); este cronograma se encuentra
dentro del cronograma general del proyecto y específicamente en la fase
desarrollo
El ciclo de pruebas comprende seis actividades las cuales deberán ser
desarrolladas de la siguiente manera:

71. EN LA DEFINICIÓN DEL PLAN DE PRUEBAS, SE
VALORARÁ:
El alcance de la aplicación.
La complejidad de sus procesos.
Plataforma/s en las que se debe probar.
Conocimientos y formación de quienes ejecutarán las pruebas.
Normativas legales aplicables.
Otros recursos involucrados.

72. SE TENDRÁ EN CUENTA QUE:
Las pruebas estarán presentes a lo largo de todo el ciclo de vida del
desarrollo, de la solución.
Siempre hay errores.
Probar exhaustivamente el software es imposible.
No es recomendable que el programador pruebe sus propios programas.
Se puede disponer de herramientas.
Se debe considerar la importancia de actualización del plan de pruebas
con el fin de reflejar los cambios que se produzcan en los requisitos y/o
proceso de desarrollo del producto.

73. PLANIFICACIÓN
Se planifican pruebas personalizando los estándares específicamente para
el proyecto de notificaciones.
Se definen niveles de pruebas a aplicar.
Se especifican las técnicas a utilizar.
Se establece el tiempo para la ejecución de cada una de las pruebas.
Uso de herramientas.
Criterios de aceptación.
Recursos involucrados.

74. RESULTADO DE LA PLANIFICACIÓN:
Formatos a utilizar para el diseño de las pruebas.
Formatos a utilizar para el registro y análisis de los resultados de las
pruebas.
Herramientas a utilizar para la gestión de incidencias.
Procedimientos para el control de cambios.
Herramientas a utilizar para la ejecución de las pruebas.

75. DISEÑO DE LAS PRUEBAS
• Para el diseño de las pruebas, se tendrán en cuenta aspectos que permitirán
encontrar defectos en el periodo de desarrollo del software, la realización de
pruebas propias de verificación y validación de datos, según se aclara en los
siguientes ítems:

76. ALCANCE.
• El alcance de las pruebas estará dado por el marco del Sistema que se
encuentra en desarrollo, (Información tomada de los términos de referencia y
del documento de Arquitectura General Detallada)

77. INVENTARIO DE LAS PRUEBAS:
el inventario de las pruebas permitirá:
Definir y asignar prioridades como; alta, media o baja.
Establecer un orden de trabajo.
Decidir qué casos entrarían en una regresión y cuáles no con mayor facilidad.
Recortar alcance en forma rápida y ordenada.
Se estima el tiempo en probar cada funcionalidad.
Evaluar aspectos técnicos del sistema.

78. RESULTADO DE LA EJECUCIÓN DE LAS PRUEBAS:
• En este punto se resaltan las entradas fundamentales que son la partida para
la ejecución del plan de pruebas.
Inventario de pruebas priorizado.
Estimación de esfuerzo de cada funcionalidad.
Plan de desarrollo del producto.
Plazos previstos para el proyecto.

79. CICLO DE LA PRUEBA:
• Las actividades de la prueba se realizarán para una determinada versión
del producto, sobre la cual se ejecutan las pruebas y se reportan los
incidentes encontrados. Para cada versión del producto se realizan alguna o
todas las tareas asociadas a las pruebas.

80. PLAN DE DESARROLLO

81. CICLOS DE PLAN DE DESARROLLO
El proceso de planificación se ajusta al comenzar cada ciclo
debido a posibles:
Atrasos de desarrollo
Modificaciones en los requerimientos iníciales
Cambios en el alcance del producto
Calidad del producto

82. • Es el proceso de identificar y definir los elementos o ítems de configuración
del sistema, controlando la entrega y el cambio de estos elementos a través
del ciclo de vida del sistema, almacenando el estado de los mismos y de las
solicitudes de cambio, y verificando la completitud con respecto a los
requisitos especificados.
ADMINISTRACIÓN DE CONFIGURACIONES:

83. COMITÉ DE CONTROL DE CAMBIOS:
• Grupo con la autoridad para evaluar, aprobar y/o rechazar la
implementación de un cambio. El establecimiento de un Comité de control de
cambios tiene como objetivo proveer un mecanismo para asegurar que toda
solicitud de cambio es direccionada adecuadamente.

84. ESTRUCTURA GENERAL PARA LA EJECUCIÓN DE
PRUEBAS
• ¿Como podemos interpretar el siguiente diagrama?

85. EVALUACIÓN Y CIERRE
• Para la evaluación y cierre de las pruebas se presentará el informe de
pruebas donde se documentará el resultado de cada una de las diferentes
pruebas ejecutadas. El contenido de este informe estará compuesto de la
manera descrita en la “Propuesta de esquema y contenido del Informé de
pruebas”; esto ya que el informe de pruebas es un entregable independiente.

87. COSTOS DE ERROR

88. COSTOS DE ERROR
Para conocer el
costo de un error??

89.  La estimación del Tamaño del proyecto, como
el costo del proyecto
 Las horas de programacion

92. COSTOS DE ERROR
 Primer problema: los errores se aceptan. Esto no
es productivo en el tratamiento del problema
 Bug: algo que se arrastra por propia voluntad en el
código y produce problemas. No atribuible a una
persona, involuntario los bugs se pueden aceptar,
los defectos NO el primer paso para lograr calidad
es identificar los defectos como lo que son, fallas
individuales

93. COSTO DE ERROR
 spoilage: esfuerzo dedicado al diagnóstico y
eliminación de fallas que fueron introducidas
durante el proceso de desarrollo.
 Representa el 55 % del costo total del
sistema

94. COSTOS DE ERROR
 La alternativa de remover defectos es
abstenerse de los mismos desarrollo con cero
defectos el costo de los defectos constituye de
un 35 % a un 55 % del costo de desarrollo
 en la mayoría de los proyectos hay personas
que introducen más spoilage que el valor de su
producción tener una persona con producción
pobre en el equipo, es a veces mejor que tener
uno más productivo

95.  El costo de detección y corrección de errores
 durante y después de las etapas de integración
y test resultan entre 10 y 15 veces más que en
las etapas de desarrollo y codificación.
 Estudios realizados concluyen que el medio
 ambiente en el que se desarrolla el Software
 contribuye enormemente al aumento de errores.

96. POR QUE SE SURGEN LOS ERROS DURANTE EL
DESARROLLO DEL SISTEMA
 Ignorancia de los requerimientos del usuario.
 Ignorancia del entorno en que se utiliza el
Software.
 Escaso flujo de información entre usuario y
programador
 Escasa documentación del Software.

97. Gracias