24/08/2016

Captulo II.
Tcnicas de Revisin
(Revisiones informales, formales, inspecciones)

Objetivos del Captulo

Tcnicas de Revisin
Conocer las tcnicas de revisin, su formalidad y el
efecto que tienen sobre el producto final de SW

Verificacin y Validacin
Conocer el papel que juegan la verificacin y
validacin del software y, dentro de ellas, las
inspecciones y pruebas

24/08/2016

Contenido
1.

Tcnicas de Revisin
Aspectos Generales
Espectro de formalidad
de las revisiones
Revisin informales
Revisiones tcnicas
formales
Inspecciones

2. Verificacin y
Validacin
Objetivos
Actividades
Puntos clave

Referencia bsica:
Pressman Roger S., (2010). Ingeniera de Software. Madrid, McGraw Hill, Sptima Edicin,
Captulo 15: Tcnicas de revisin

1. Tcnicas de Revisin
Aspectos Generales:
Se aplican en varios puntos durante la ingeniera de
software y sirven para descubrir errores y defectos a fin
de poder eliminarlos.
Son el mecanismo ms eficaz para detectar errores en
una fase temprana del proceso de software
Son efectuados por ingenieros de software quienes
realizan una revisin tcnica, tambin llamada revisin
de pares, con sus colegas.
El resultado de una revisin es una lista de conceptos o
errores descubiertos. Adems, tambin se indica el
estado tcnico del producto final.

24/08/2016

1. Tcnicas de Revisin
Efecto de los defectos del software en el costo
En el contexto general, los trminos defecto y falla
pueden verse como sinnimos.
Implican un problema de calidad descubierto despus
de haberse liberado el SW (a usuarios finales o a un
proceso posterior).
El trmino error se usa para denotar un problema de
calidad descubierto por ingenieros de SW antes de
entregar el software.
Esta distincin se hace porque los errores y defectos
tienen muy distinto efecto econmico, empresarial,
sicolgico y humano.

1. Tcnicas de Revisin
Efecto de los defectos del software en el costo (..)
El objetivo principal de las revisiones tcnicas es
encontrar errores durante el proceso a fin de que no se
conviertan en defectos despus de liberar el software.
El beneficio obvio de las revisiones tcnicas es el
descubrimiento temprano de los errores, de modo que
no se propaguen a la siguiente etapa del proceso del
software.

24/08/2016

1. Tcnicas de Revisin
Espectro de formalidad en las revisiones.
Las revisiones tcnicas deben aplicarse con un nivel de
formalidad apropiado para el producto que se va a
elaborar, para el plazo que tiene el proyecto y para el
personal que realice el trabajo.
El trabajo efectuado cuando se utilizan
revisiones se refleja pronto en el
desarrollo de un incremento de
software, pero esta inversin temprana
paga dividendos debido a que se
reduce el esfuerzo necesario para hacer
pruebas y correcciones.

Las revisiones no quitan tiempo, lo ahorran!

De igual importancia es que la fecha

de entrega del desarrollo con
revisiones ocurre antes que la que se
hace sin revisiones.

1. Tcnicas de Revisin
Espectro de formalidad en las
revisiones ()
La formalidad de una revisin se
incrementa cuando:
1. Se definen explcitamente roles
distintos para los revisores,
2. Hay suficiente cantidad de
planeacin y preparacin para la
revisin,
3. Se define una estructura distinta para
la revisin (incluso tareas y productos
internos del trabajo) y
4. El seguimiento por parte de los
revisores tiene lugar para
cualesquiera correcciones que se
efecten.

Modelo de referencia para hacer

revisiones tcnicas

24/08/2016

1. Tcnicas de Revisin
Espectro de formalidad en las revisiones ()
Las revisiones de 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. Tcnicas de Revisin
Revisiones Informales
Incluyen una simple verificacin de escritorio de un
trabajo de ingeniera de software, hecha con algn
colega, o una reunin casual (con ms de dos personas)
con objeto de revisar un producto o aspectos orientados
a la revisin de programacin por pares.
La eficacia de tales revisiones es mucho menor que la de
los enfoques ms formales. Pero una verificacin de
escritorio sencilla descubre errores que de otro modo se
propagaran en el proceso del software.
Una forma de mejorar la eficacia de una verificacin de
escritorio es desarrollar un conjunto de listas de revisin
para cada producto grande del trabajo generado por el
equipo de software.

24/08/2016

1. Tcnicas de Revisin
Revisiones Tcnicas Formales
Una revisin tcnica formal (RTF) es una actividad del
control de calidad del software realizada por ingenieros
de software (y otras personas).
Los objetivos de una RTF son:
1.

2.

3.

4.
5.

Descubrir los errores en funcionamiento, lgica o

implementacin de cualquier representacin del software;
Verificar que el software que se revisa cumple sus
requerimientos;
Garantizar que el software est representado de acuerdo con
estndares predefinidos;
Obtener software desarrollado de manera uniforme y
Hacer proyectos ms manejables.

1. Tcnicas de Revisin
Revisiones Tcnicas Formales (..)
La RTF en realidad es una clase que incluye
walkthroughs e inspecciones.
Cada RTF se realiza como una reunin y tendr xito
slo si se planea, controla y ejecuta en forma apropiada.

24/08/2016

1. Tcnicas de Revisin / Tcnicas Formales

Reuniones de Revisin
stas deben cumplir las siguientes
restricciones:
En la revisin deben involucrarse
de tres a cinco personas
(normalmente).
Debe haber preparacin previa,
pero no debe exigir ms de dos
horas de trabajo de cada persona.
La duracin de la reunin de
revisin debe ser de al menos dos
horas.

Una RTF se centra en una parte

especfica (y pequea) del
software general.
Al reducir el alcance, la RTF tiene
mayor probabilidad de detectar
errores.

Al terminar la revisin, todos los

asistentes deben decidir si:
1.
2.

3.

Aceptan el producto sin

modificaciones,
Lo rechazan debido a errores
graves (una vez corregidos, se
realiza otra revisin),
Aceptan el producto de manera
provisional (se encontraron
errores menores que deben
corregirse, pero no se necesita
otra revisin).

Una vez tomada la decisin, todos

los asistentes a la RTF firman el
acta que indica su participacin y
su acuerdo con los
descubrimientos del equipo de
revisin.

1. Tcnicas de Revisin / Tcnicas Formales

Reporte y registro de la revisin

Al final de la revisin se
produce la lista de pendientes
de la revisin.
Adems se elabora un reporte
tcnico formal de la revisin.
ste responde tres preguntas:
1.
2.
3.

Qu fue lo que se revis?

Quin lo revis?
Cules fueron los
descubrimientos y las
conclusiones?

Debe establecerse un
procedimiento de
seguimiento para garantizar
que los pendientes de la lista
se corrijan de manera
apropiada.
A menos que esto se haga, es
posible que los pendientes
anotados se pierdan en el
camino.

24/08/2016

1. Tcnicas de Revisin / Inspecciones

Tcnica esttica en el que un sistema de software se revisa
para encontrar errores, omisiones y anomalas.
Generalmente se centran en el cdigo fuente, pero puede
inspeccionarse cualquier representacin legible del
software como los requerimientos o un modelo del diseo.
Existen tres ventajas fundamentales de la inspeccin sobre
las pruebas:
1.
2.
3.

Durante las pruebas, los errores pueden enmascarar

(ocultar) otros errores.
Pueden inspeccionarse versiones incompletas de un sistema
sin costes adicionales.
Adems de buscar los defectos de un programa, una
inspeccin tambin puede considerar atributos de calidad
ms amplios (cumplimiento de estndares, portabilidad,
mantenibilidad).

1. Tcnicas de Revisin / Inspecciones

Inspeccin de Programas.
Son revisiones cuyo objetivo es la deteccin de defectos en el
programa.
Es un mtodo bastante utilizado en ingeniera de sistemas
crticos.
Pueden encontrarse errores lgicos, anomalas en el cdigo
que podran indicar una condicin errnea, incumplimiento
de estndares.
Durante una inspeccin, se recomienda utilizar una lista de
comprobacin de errores de programacin comunes.
Puede basarse en ejemplos de listas de comprobacin de
libros, o en conocimiento de los defectos comunes en un
dominio de aplicacin particular.
Depende de cada lenguaje de programacin (debido a los
diferentes niveles de comprobacin proporcionado por el
compilador del lenguaje).

24/08/2016

1. Tcnicas de Revisin / Inspecciones

Inspeccin de programas (..)
Posibles comprobaciones que podran realizarse durante un
proceso de inspeccin:
Defecto

Descripcin

Defectos de
datos

Se inicializan todas las variables antes de que se utilicen todos sus

valores?
Tienen nombre todas las constantes?
Est controlado el lmite superior de los vectores?
Existe posibilidad de que el bfer se desborde?

Defectos de
control

Para cada sentencia condicional: es correcta la condicin?

Se garantiza que termina cada bucle?
En las sentencias case: se tienen en cuenta todos los posibles casos?
Se han incluido las sentencias break despus de cada caso?

Defectos de
entrada / salida

Se utilizan todos las variables de entrada?

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

1. Tcnicas de Revisin / Inspecciones

Inspeccin de programas (..)
Posibles comprobaciones que podran realizarse durante un
proceso de inspeccin (..):
Defecto

Descripcin

Defectos 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?

Defectos de
Si una estructura enlazada se modifica: se reasignan
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?
Defectos de
manejo de
excepciones

Se tienen en cuenta todas las condiciones de error posibles?

24/08/2016

2. Verificacin y Validacin
VV es un conjunto de procedimientos, actividades,
tcnicas y herramientas que se utilizan, paralelamente
al desarrollo de software, para asegurar que un
producto software resuelve el problema inicialmente
planteado
Las pruebas son una familia de tcnicas de VV

2. Verificacin y Validacin
Objetivos de la VV
El objetivo ltimo del proceso de VV es establecer la
seguridad de que el sistema de software est hecho para
un propsito.
El nivel de confianza requerido depende de:
Propsito del sistema (funcin de software).
Expectativas del usuario.
Entorno de mercado.

10

24/08/2016

2. Verificacin y Validacin
Objetivos de la VV
Acta sobre los productos intermedios que se generan
durante el desarrollo para:
Detectar y corregir cuanto antes sus defectos y las
desviaciones respecto al objetivo fijado.
Disminuir los riesgos, las desviaciones sobre los
presupuestos y sobre el calendario o programa de
tiempos del proyecto.
Mejorar la calidad y fiabilidad del software.
Valorar rpidamente los cambios propuestos y sus
consecuencias.

2. Verificacin y Validacin
Actividades de VV
Verificacin
Estamos construyendo
correctamente el producto?
El software
debe

Estar conforme a su especificacin

Objetivo

Demostrar la consistencia,
complecin y correccin de los
artefactos de las distintas fases
(productos intermedios)

Tcnica ms Revisiones
utilizada

Validacin
Estamos construyendo el producto
correcto?

Determinar la correccin del

producto final respecto a las
necesidades del usuario

Pruebas

11

24/08/2016

2. Verificacin y Validacin
Dentro del proceso de VV, existen dos aproximaciones
complementarias para el anlisis y comprobacin de
los sistemas:
Inspecciones de software.
Puede usarse en todas las etapas del proceso.
Son tcnicas estticas que no necesitan ejecutar el software en
una computadora.
Pueden usar algn tipo de anlisis automtico.

Pruebas de software.
Implican ejecucin del SW con datos de prueba.
Se examinan las salidas y el entorno operacional.
Son tcnicas dinmicas.

2. Verificacin y Validacin
Tcnicas estticas (inspecciones) vs Dinmicas
(pruebas)
Inspecciones

Video: Importancia del Aseg. Calidad de SW

12

24/08/2016

2. Verificacin y Validacin
Normalmente , los procesos de VV y depuracin se
intercalan.
Sin embargo, las pruebas y la depuracin tienen
diferentes objetivos:
Los procesos de VV intentan establecer la existencia de
defectos en el sistema de software.
La depuracin es un proceso que localiza y corrige estos
defectos.

2. Puntos clave en la VV
La verificacin y validacin no son lo mismo. La verificacin intenta
mostrar que un programa satisface su especificacin. La validacin
intenta mostrar que el programa hace lo que el usuario requiere.
Las tcnicas de verificacin esttica implican examinar y analizar el
cdigo fuente del programa para detectar errores. Deberan utilizarse
con las pruebas de programas como parte del proceso de VV.
Las inspecciones de programas son efectivas para encontrar errores en
ellos. El objetivo de una inspeccin es localizar defectos. Una lista de
comprobacin de defectos debera conducir el proceso de inspeccin.
Los planes de prueba deberan incluir una descripcin de los elementos
que hay que probar, la agenda de pruebas, los procedimientos para
gestionar el proceso de pruebas, los requerimientos de HW y SW, y
cualquier problema de pruebas que probablemente pueda surgir.

13

24/08/2016

Confianza en el equipo !!!

Un grupo de diez programadores es enviado a una clase para
aspirantes a managers. El profesor comienza con esta
pregunta:
Ustedes trabajan para una empresa que desarrolla software de
control de vuelo para aviones. Durante un viaje de negocios,
justo antes de un despegue, notan una placa que indica que el
avin est utilizando una versin beta del software
desarrollado por ustedes. Quin se bajara?

Confianza en el equipo !!!

Nueve de los diez programadores levantan la mano. El
profesor pregunta al restante: Y usted, por qu se quedara en
el avin?
El programador responde: Si el software fue desarrollado por
nosotros dudo que el avin pueda despegar, mucho menos
estrellarse.

14