Tcnicas de Evaluacin

de Software

Curso 05-06

Primera sesin

Segunda sesin (Slides 20 a 39)

Beneficios de Tcnicas estticas

Caractersticas de la calidad de los distintos productos software

Tercera sesin (Slide 39 a 55)

Presentacin asignatura (1/2 hora)

Intro a la Evaluacin del Software (Slide 3 a 19)

Tcnica de lectura ad-hoc y basada en listas de comprobacin

Ejercicio 1: Requisitos ABC sin lista de comprobacin
Ejercicio 2: Idem con lista de comprobacin
Ejercicio 3: Lectura de cdigo con lista (3 programas pequeos)

Cuarta sesin (Slide 55 a final)

Explicacin Tcnica de Abstraccin Sucesiva

Ejercicio de Count
Explicacin del proceso de Inspecciones

Construir software es ms difcil

de lo que parece

Proyectos exitosos 16,3%

El proyecto es completado en tiempo y en presupuesto, con todas las
caractersticas y funciones especificadas al comienzo del proyecto

Proyectos desafiantes 52,7% cuestan 189% mas que las

estimaciones

El proyecto es completado y operacional, pero con mayor presupuesto

que el pactado, tardando ms del tiempo pactado y ofreciendo menos
caractersticas y funciones de las especificadas inicialmente

Proyectos daados 31%

El proyecto es cancelado en cierto momento del desarrollo antes de

llegar a estar el sistema operacional

Son los errores del software

irremediables?: Situacin
Quin no ha sufrido algn error
informtico debido a un fallo
misterioso en el software?
Por qu?

Son los errores del software

irremediables?:
Complejidad

La extrema dificultad de los sistemas sw favorece

que existan errores remanentes en los sistemas
entregados y en operacin

Un programa de apenas unos centenares de

lneas de cdigo puede contener decenas de
decisiones, lo que permite miles de rutas
alternativas de ejecucin, resultando
materialmente imposible el ensayo de todas las
alternativas de ejecucin posibles

Son los errores del software

irremediables?: Falta Conocimiento

Nuestra capacidad para garantizar la fiabilidad del software

es muy inferior a lo necesario. No podemos demostrar
matemticamente la correccin de los programas, al
estilo de los otros ingenieros
Los otros ingenieros usan anlisis matemticos para predecir el
comportamiento de sus sistemas. Esa prediccin permite descubrir
defectos antes de que el producto est operativo

Las matemticas tradicionales, aptas para la

descripcin de sistemas fsicos, no son aplicables al

universo sinttico binario del software. Es la matemtica

discreta, una especialidad mucho menos madura y casi no
estudiada hasta la aparicin de las computadoras, la que
gobierna el campo de los sistemas software

Son los errores del software

irremediables?:
Estado Actual

Dada la imposibilidad de aplicar mtodos matemticos

rigurosos, el modo que tenemos para respaldar la
confianza de los programas es la ejercitacin:
Hacer funcionar los programas, observando directamente su
comportamiento y depurndolos cada vez que aparece una
deficiencia. La fiabilidad de los programas ir creciendo a lo largo
de este proceso

No obstante, la calidad que se puede obtener mediante

este procedimiento artesanal es bastante baja. De
ah que, a pesar de haber sido ensayados rigurosa y
sistemticamente, la mayora de los sistemas software
contengan todava defectos cuando son entregados

Pero
Esta situacin no debe ser
una licencia para el todo
vale!!!!

Profesionalidad = Calidad
El objetivo de un Ingeniero
Software debe ser entregar a los
clientes un producto de calidad

Qu es la Calidad del Software?

Al ser un concepto difcil de asir, se

descompone en atributos ms
palpables

Criterios de Calidad del Software

Funcionalidad: Realiza el trabajo deseado

Fiabilidad: Se mantiene operativo
Eficiencia: Responde con la velocidad apropiada
Usabilidad: El usuario est cmodo con l
Mantenibilidad: Permite realizar cambios
fcilmente y con una adecuada proporcin
cambio/costo
Portabilidad: Opera en diferentes entornos
informticos

Funcionalidad y Fiabilidad

Funcionalidad
El sistema software realiza el trabajo deseado por el
usuario

Fiabilidad
El sistema software se mantiene operativo

Pero...
Cmo se comprueban?

Evaluando la Funcionalidad

Si la Funcionalidad es
El software realiza el trabajo deseado por el
usuario

La Evaluacin se realizar
Comparando el trabajo del sistema con los
deseos del usuario (Especificacin de Requisitos)

Realiza las tareas encomendadas

Da las respuestas correctas o acordadas
Tiene los efectos correctos o acordados

Evaluando la Fiabilidad

Si la Fiabilidad es
El sistema software se mantiene operativo

La Evaluacin se realizar
Buscando defectos que provoquen la mala
operacin del sistema

Evaluando Funcionalidad y
Fiabilidad

Comparando el sistema con la

Especificacin de Requisitos

Realiza las tareas encomendadas

Da las respuestas correctas o acordadas
Tiene los efectos correctos o acordados

Buscando defectos que provoquen la

mala operacin del sistema

Cundo se Evalan?

Los posibles defectos con respecto a

No realizar todas las tareas esperadas

Realizar mal alguna de ellas (respuestas/efectos incorrectos)
Mala operacin del sistema

no slo pueden surgir en el cdigo

Muchos defectos del cdigo vienen gestados en

los productos anteriores (Especificacin, Diseo,)

Entonces?

T
ES

S
A
TIC

Deben evaluarse los productos del

desarrollo segn se generan
En lugar de esperar a tener cdigo!

S
A
C
I
CN

S
A
C
I
M

N
I
D
S
Debe ejercitarse
el
cdigo
adecuadamente
A
C
I
N
C

Evaluacin durante la
construccin
Sistema Aceptado
m
Din

n
Eva
lua
ci

w
eS

d
llo
ica
r ro
sa
tt
De
Es
in
ac
a lu
Ev

ica

Necesidad del Usuario

Cdigo

Actividades de desarrollo y
actividades de evaluacin
Necesidad del Usuario
Requisitos de
Usuario

Revisin de
Requisitos de
Usuario

Cdigo Aceptado

Definicin de
Requisitos de
Usuario

Requisitos de Usuario Revisados

Requisitos del Software

Revisin de
Requisitos del
Software

Cdigo instalado en
Los sistemas del usuario probado

Definicin de
Requisitos
Software

Pruebas de Sistema

Requisitos del softwareRevisados

Diseo Arquitectinico

Revisin del Diseo

Arquitectnico

Cdigo con la interaccin

entre mdulos probada

Diseo de la
Arquitectura

Pruebas de Integracin
Cdigo con los
mdulos probados

Diseo Arquitectnico Revisado

Diseo Detallado

Revisin del
Diseo
Detallado

Pruebas de Aceptacin

Diseo
Detallado

Pruebas de Unidad
Cdigo
Revisado

Diseo Detallado Revisado

Cdigo

Codificacin

Revisin del
Cdigo
Cdigo Revisado

Evaluacin y Defectos

La evaluacin busca defectos en los

productos (Req. Ds. Cdg) del desarrollo
No

se reflejan las tareas deseadas

Se producen respuestas/efectos incorrectos
Provocan mala operacin

Defecto: Error/Falta/Fallo

Error

Humano

Accin humana que produce una falta

Falta

Req, Dis, Codg,

Fallo

Sistema

Algo que est mal en unESTTICAS

producto
TCNICAS

Manifestacin
de una falta
DINMICAS
CAS
TCNI

DEFECTO

Tecnicas Estticas

I.- Beneficios

Beneficios de las Tcnicas

Estticas

Los defectos en productos tempranos se

traducen en defectos en el sistema

Beneficio 1:

Pronta deteccin = Menor coste

Defectos en los Requisitos

Los proyectos desafiantes (de Tipo 2)

tienen slo 42% de las funciones
deseadas
Un total de 78,4% de proyectos software
entregan slo el 74,2% de las funciones
deseadas

Requisitos: Fuente de problemas

CAUSAS DE PROBLEMAS

% RESPUESTAS

Requisitos incompletos

13,1%

Falta de participacin del usuario

12,4%

Falta de recursos

10,6%

Expectativas no realistas

9,9%

Falta de apoyo del nivel ejecutivo

9,3%

Cambio en los requisitos

8,7%

Pronta Deteccin

Entre el 30% y el 70% de los defectos de

diseo y cdigo pueden ser 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

Deteccin

Correccin

Coste Dinmica / Coste Esttica

Dinmica

Generar casos de
prueba
Detectar el fallo
Buscar la falta
provocadora

Esttica

-------

-------

Buscar la falta
provocadora

Beneficios de las Tcnicas

Estticas

Donde hay un defecto hay ms

Beneficio 2:
Pronta deteccin = Estimacin calidad

Pronta Deteccin

La cantidad de faltas encontradas en un

producto dan una idea de la calidad del
trabajo de desarrollo de dicho producto
Esto permite tomar medidas correctivas
del desarrollo si las mediciones indican
que se est llevando a cabo un trabajo
pobre

Deteccin = Prevencin y Control

II.- Defectos de los productos

del desarrollo

Objetivo de las Tcnicas

Estticas

Deteccin de faltas

Falta = Algo diferente a lo que debe ser

Cada producto tiene su tipo de falta, pues

tiene sus propios atributos de cmo debe
ser

Atributos de Calidad de los

Productos del Desarrollo

Correccin

Interna y con respecto al producto precedente

Complecin
Consistencia
Ambigedad
Claridad
Trazabilidad

Atributos de Calidad de
Requisitos

Correccin
Un requisito incorrecto ser aquel que no se corresponde con lo acordado o
adecuado

Completud
Est especificado todo lo que tiene que hacer el sistema y no incluye nada
que el sistema no deba hacer. Cada requisito contiene toda la informacin
necesaria

Consistencia
No hay requisitos contradictorios

Ambigedad
Los requisitos no pueden estar sujetos a interpretacin

Claridad

Se entiende claramente lo que est especificado

Ejemplo Requisito Incompleto y

Ambiguo

Requisito para un sistema de diagnstico

a bordo en los coches

El sistema deber proporcionar al conductor

indicaciones para llegar al garaje mecnico
ms cercano

Incompleto: Qu informacin deben

contener las indicaciones?
Ambiguo: Qu es el garaje ms cercano?

Atributos de Calidad de Diseo (I)

Correccin
Los errores de correccin se pueden referir a dos aspectos:
Defectos en el uso de la notacin de diseo empleada; Defectos
con respecto a los requisitos

Complecin
Disea todo el sistema marcado por los requisitos y no disea
ninguna parte no indicada en los requisitos

Consistencia
El diseo debe ser consistente entre todas sus partes. No
puede indicarse algo en una parte del diseo, y lo contrario en
otra

Atributos de Calidad de Diseo (II)

Factibilidad
El diseo debe ser realizable. Debe poderse
implementar

Trazabilidad
Se debe poder navegar desde un requisito hasta el
fragmento de diseo donde ste se encuentra
representado

Atributos de Calidad de Cdigo

Correccin
Los errores de correccin se pueden referir a varios aspectos:
Defectos en la notacin (algunos detectables en compilacin, otros
no); Defectos con respecto al diseo

Complecin
El cdigo debe estar completo. Nada falta ni nada sobra con respecto
al diseo

Claridad
El cdigo debe ser claro e inteligible

Trazabilidad
Debe ser posible navegar desde un requisito hasta el fragmento de
cdigo donde ste se ejecute, pasando por el fragmento de diseo

III.- Tcnicas de lectura

Tcnicas de Lectura: Qu son

Las tcnicas de lectura son guas que ayudan a

detectar defectos en los productos software

Una tcnica de lectura consiste en una serie de

pasos o procedimientos cuyo propsito es que
el inspector adquiere un conocimiento profundo
del producto software que inspecciona

Una tcnica de lectura puede verse como un

mecanismo para que los inspectores detecten
ms defectos en el producto inspeccionado

Tipos de Tcnicas de Lectura

Ad-hoc
Basada en Listas de Comprobacin
Abstraccin Sucesiva
Basada en Perspectivas

Lectura ad- hoc

El producto software se entrega a los

inspectores sin ninguna indicacin o gua sobre
cmo proceder con el producto ni qu buscar

Ad-hoc no significa que los participantes de la

inspeccin no escudrien sistemticamente el
producto inspeccionado

PRODUCTO: Todos

Ejercicio de Calidad de
Requisitos

Detalle de los requisitos del Sistema de Video

ABC

Bsqueda de Defectos: Correccin, Claridad,

Completud, Consistencia, Ambigedad.

Lectura con Listas de

Comprobacin

Apoyo mayor mediante preguntas que los

inspectores deben de responder mientras leen
el artefacto

PROBLEMA: Las preguntas son a menudo

generales y no suficientemente adaptadas a un
entorno de desarrollo particular

PRODUCTO: Todos

Lista de Comprobacin para

Requisitos

Estn especificadas todas las entradas al sistema,

incluyendo su origen, precisin, rango de valores y
frecuencia?
Estn especificadas todas las salidas del sistema,
incluyendo su destino, precisin, rango de valores,
frecuencia y formato?
Estn todos los formatos de los informes
especificados?
Estn especificados los interfaces con otros sistemas
software y hardware externos?
...

Ejercicio con Lista de

Comprobacin

Revisar los requisitos del Sistema ABC

ahora usando una lista de comprobacin

Solucin al Ejercicio
1.

2.

3.

Requisito funcional 2. Defecto de Ambigedad

Hay distintas formas potencialmente de interpretar estado actual
para clasificar las cintas: en tienda/alquilada, daada/buen estado,
rebajada/precio normal, ...
Requisito funcional 3. Defecto de Completud o Ambigedad
Qu es un registro de transaccin?
Requisito funcional 6. Defecto de Completud
No se especifica que deba haberse introducido el nmero de
cuenta antes de poder introducir el nmero de una cinta
Requisito funcional 10. Defecto de Completud o Claridad

4.

No se especifica el significado de actualizar los distintos ficheros

Lectura Basada en Perspectivas

Establece que un producto software debera

inspeccionarse bajo las perspectivas de los
distintos participantes en un proyecto de
desarrollo
Las perspectivas dependen del papel que los
distintos participantes tienen en el proyecto
Para cada perspectiva se han definido uno o
varios escenarios consistentes en actividades
repetibles que un inspector debe realizar y
preguntas que el inspector debe responder

Lectura Basada en Perspectivas:

Diseador

Est disponible toda la informacin necesaria para hacer

el diseo?
Hay puntos en los cuales no ests seguro de lo que
deberas hacer porque el requisito no est claro o no es
consistente?
Se han definido todos los objetos necesarios? (datos,
estructuras de datos y funciones)
Se han especificado todas las condiciones para todos los
objetos?
Se pueden definir todos los tipos de datos? (es decir, se
han especificado las unidades correspondientes as como
la precisin requerida?

Lectura Basada en perspectivas:

Probador

Puedes generar un caso de prueba para este

requisito?
Puedes estar seguro de cules son las soluciones
correctas para los casos de prueba que generes para
este requisito?
Hay otras interpretaciones de este requisito que el
implementador pueda hacer basndose en la forma en
que est definido el requisito? Afectar esto a los
casos de prueba que t generes?
Hay otro requisito para el que generaras un caso de
prueba similar pero que te conducira a un resultado
contradictorio?

Lista de Comprobacin para

Sentencias Condicionales

Sentencias if-then

Se comportan las comprobaciones if-then

correctamente con la igualdad?
Est la clusula else presente o
documentada?
Es la clusula else correcta?
Se usan las clusulas if y else
correctamente, no cambiadas?
Sigue el caso normal el if ms que el else?

Ejercicio de Cdigo con Lista de

Comprobacin

Programa Buscar-en
Programa Hay_mayor_tira
Programa media de nmeros positivos

Solucin Programa Buscar_en

No se inicializa n

El while debe ser un mayor no un menor

Solucin Programa
Hay_mayor_tira

La comparacin entre tira y letra es

errnea. Debera ser (tira[j]>letra)

Solucin Programa
media de nmeros positivos

No se inicializa adecuadamente la
variable suma: suma = 0

Pero no tenamos al especificacin de

requisitos del programa. Qu ocurre si la
especificacin es?

Especificacin Programa
media de nmeros positivos
El programa debe calcular la media de los
nmeros positivos de un archivo y la
imprime

Solucin Programa
media de nmeros positivos

No se inicializa adecuadamente la
variable suma: suma = 0

Imprime la cantidad de nmeros positivos

encontrados, no la media

Y si la especificaicn fuera?

Especificacin Programa
media de nmeros positivos

El programa debe calcular la media de los

nmeros positivos de un archivo e
imprimir la cantidad de nmeros positivos
encontrados

Solucin Programa
media de nmeros positivos

No se inicializa adecuadamente la variable

suma: suma = 0

No trata el caso de no encontrar valores

positivos. En ese caso el programa no imprime
ningn resultado. Falta aadir un else al ltimo if
para considerar este caso:
else printf("\nNo se encontraron valores positivos\n");

Tipos de errores/ Tipos de lectura

Esto nos indica que hay dos tipos de

defectos:

Defectos intrnsecos al producto (correccin)

Se detectan sin relacionar el producto con los

productos anteriores

Defectos de funcionalidad (validez)

Slo son detectables si se compara el producto

con los productos anteriores

Tipos de errores/ Tipos de lectura

La lectura con listas de comprobacin

detecta defectos de correccin

La lectura por abstraccin sucesiva

detecta defectos de validez

Lectura por Abstraccin Sucesiva

Deteccin de defectos mediante

comparacin entre la
especificacin del programa y lo
que hace realmente el programa

Todos aquellos puntos donde no

coincida lo que el programa
debera hacer con lo que el
programa hace es un defecto

Lectura por Abstraccin Sucesiva

Comparar cdigo con texto es imposible

Por tanto, se hace necesario convertir

ambos
artefactos
a
las
mismas
unidades

Se convierte el programa en una

especificacin en forma de texto

De este modo se compara especificacin

con especificacin

Relacin entre
Programacin y Abstraccin
Obtener una especificacin a
partir de un cdigo significa
recorrer el camino de la
programacin en sentido
inverso

Refinamiento sucesivo:
Programacin
1.

2.
3.
4.

Leer la especificacin hasta que el

programador ha entendido lo que el cdigo
debe hacer
Descomponer la tarea que el programa debe
hacer en subtareas
Descomponer cada funcin en estructuras de
programacin
Repetir el paso 3 hasta que las estructuras
son tan simples que puedpuedan
directamente traducirse en lineas de cdigo

Lectura por Abstraccin Sucesiva

1.

2.
3.
4.

Leer la especificacin varias veces hasta que el

programador ha entendido lo que el cdigo debe
hacer
Descomponer la tarea que el programa debe
hacer en subtareas
Descomponer cada funcin en estructuras de
programacin
Repetir el paso 3 hasta que las estructuras son
tan simples que pueden directamente traducirse
en lineas de cdigo

DESCOMPOSICIN

Abstraccin Sucesiva

COMPOSICIN

Abstraccin Sucesiva
1.
2.
3.

4.
5.

Leer por encima el cdigo

Descomponer en funciones
Descomponer cada funcin en
estructuras elementales
COMPOSICIN
Comprender
qu hace cada estructura
Componer lo que hace cada estructura
en lo que hace el programa completo

Ejercicio Programa count

Recordatorio de la tcnica
1. Realizar rbol de llamadas.
2. Comenzando desde las funciones hoja a la raz:
2.1. Identificar las estructuras elementales de cada funcin y
marcarlas de la ms interna a la ms externa
2.2. Determinar el significado de cada estructura comenzando
con la ms interna.
2.3. Especificar el comportamiento de la funcin entera
3. Combinar los resultados para especificar el comportamiento del
programa entero

Ejercicio de Abstraccin Sucesiva

Entregar cdigo del programa count
Aplicar la tcnica de Abstraccin
Sucesiva hasta obtener una
especificacin textual
Entregar especificacin
Comparar ambas y detectar defectos

Ejercicio Programa count

Especificacin
count cuenta el nmero de lneas, palabras y caracteres que hay en cada
fichero que se le pasa como argumento. Las palabras son secuencias de
caracteres que estn separadas por uno o ms espacios, tabuladores o saltos
de lnea.
Si alguno de los ficheros que se le pasa como argumento no existe, aparece
por la salida de error el mensaje de error correspondiente y se contina
procesando el resto de ficheros. Si no se indica ningn fichero, count lee de la
entrada estndar.
Se muestra por pantalla los valores computados para cada fichero (junto con
el nombre del fichero) as como la suma total de cada valor para todos los
ficheros. Si se procesa un nico fichero o si se procesan datos provenientes
de la entrada estndar, entonces no se imprime ninguna suma. La salida se
imprime en el orden siguiente: primero lneas, luego palabras, luego caracteres
y finalmente bien el nombre del fichero o la palabra total para la suma. Si se
ha ledo de la entrada estndar, el cuarto valor (nombre) no aparece.

Solucin Programa count:

Abstraccin

Todos los argumentos de la lnea de comandos se tratan como

nombres de ficheros, aunque siempre se intenta leer uno de ms
que no existe. Se distinguen tres casos:
1.

2.

3.

Se proporcionan argumentos, pero no hay ficheros con nombres

correspondientes a los argumentos. En este caso, el programa se para
con un mensaje de error que sale por la salida estndar.
Se proporcionan argumentos, y corresponden a ficheros que existen.
Para cada fichero, el nmero de lneas, palabras y caracteres se cuenta
y se imprime la suma junto con el nombre del programa.
No se proporcionan argumentos. En este caso, el programa intenta leer
de algo que no est inicializado y procede como en (2), a pesar de que
no se imprime el nombre del programa.

Si el nmero total de argumentos es al menos 1, se imprime la

suma total ms uno de todos los caracteres y palabras en todos los
ficheros y el nmero de lneas del ltimo fichero.

Solucin Programa count:

Abstraccin

Todos los argumentos de la lnea de comandos se tratan como nombres

de ficheros, aunque siempre se intenta leer uno de ms que no existe. Se
distinguen tres casos:
1.

2.

3.

Se proporcionan argumentos, pero no hay ficheros con nombres

correspondientes a los argumentos. En este caso, el programa se para
con un mensaje de error que sale por la salida estndar.
Se proporcionan argumentos, y corresponden a ficheros que existen. Para
cada fichero, el nmero de lneas, palabras y caracteres se cuenta y se
imprime la suma junto con el nombre del programa.
No se proporcionan argumentos. En este caso, el programa intenta leer de
algo que no est inicializado y procede como en (2), a pesar de que no
se imprime el nombre del programa.

Si el nmero total de argumentos es al menos 1, se imprime la

suma total ms uno de todos los caracteres y palabras en todos los
ficheros y el nmero de lneas del ltimo fichero .

SOLUCIN: countespecificacin
count cuenta el nmero de lneas, palabras y caracteres que hay en
cada fichero que se le pasa como argumento. Las palabras son
secuencias de caracteres que estn separadas por uno o ms espacios,
tabuladores o saltos de lnea.
Si alguno de los ficheros que se le pasa como argumento no existe,
aparece por la salida de error el mensaje de error correspondiente y
se contina procesando el resto de ficheros. Si no se indica ningn
fichero, count lee de la entrada estndar.
Se muestra por pantalla los valores computados para cada fichero (junto
con el nombre del fichero) as como la suma total de cada valor para
todos los ficheros. Si se procesa un nico fichero o si se procesan
datos provenientes de la entrada estndar, entonces no se imprime
ninguna suma. La salida se imprime en el orden siguiente: primero
lneas, luego palabras, luego caracteres y finalmente bien el nombre del
fichero o la palabra total para la suma. Si se ha ledo de la entrada
estndar, el cuarto valor (nombre) no aparece.

Programa count
#include <stdio.h>
main (argc, argv)
int argc;
char *argv[];
{
int c, i, inword;
FILE*fp;
long linect, wordct, charct;
long tlinect = 1, twordct = 1, tcharct = 1;
i = 1;
do {
if (argc > 1 && (fp=fopen(argv[i], "r")) ==
fprintf (stdout, "can't open %s\n", argv[i]);

exit (1);
}
linect = wordct = charct = 0;
inword = 0;
while ((c = getc(fp)) != EOF) {
++charct;
if (c == '\n')
++linect;

NULL) {

Programa count
if (c == ' ' || c == '\t' || c == '\n')
inword = 0;
else if (inword == 0) {
inword = 1;
++wordct;
}
}
printf("%7ld %7ld %7ld", linect, wordct, charct);
if (argc > 1)
printf(" %s\n", *argv);
else
printf("\n");
fclose(fp);
tlinect += linect;
twordct += wordct;
tcharct += charct;
} while (++i

<= argc);
if (argc > 1)
printf("%7ld %7ld %7ld total\n",
exit(0);
}

linect, twordct, tcharct);

Formatos para Registro de

Defectos

Aqu conviene que incluya los formatos

que van a ausar en la prctica para que
se vayan familiarizando. Estn en los
anexos de la ltima versin del doc.

Ejercicios (si hay tiempo)

Programa tokens para que vuelvan a

practicar con Lectura con Lista de
Comprobacin

Programa series para practica la

Lectura con Abstraccin Sucesiva

Ejercicio Pre-prctica obligatorio

Antes de acceder al aula para realizar las

prcticas es obligatorio entregar un
ejercicio preparatorio:

Programa XXXXXX

IV.- Inspecciones

Tipos de Tcnicas Estticas

Revisiones informales o Revisiones

Intercambio de opiniones entre los participantes

Revisiones formales o Inspecciones

Los participantes son responsables de la fiabilidad de la evaluacin,

y generan un informe que refleja el acto de la revisin

Walkthroughs o Recorridos

Simular la ejecucin de casos de prueba para el programa que se

est evaluando recorrindolo imitando lo que hara la computadora

Auditorias

Contrastan los artefactos generados durante el desarrollo con

estndares, generales o de la organizacin

Qu son las Inspecciones?

Proceso bien definido y disciplinado
donde un equipo de personas cualificadas
analizan un producto software usando
una tcnica de lectura con el propsito
de detectar defectos

Proceso de Inspeccin
1.

Inicio

Planificacin
Lanzamiento

2.

Deteccin de defectos

3.

Recoleccin de defectos

4.

Compilacin
Inspeccin en grupo

Correccin y seguimiento

Correccin
Seguimiento

Proceso de Inspeccin:
Planificacin

Seleccionar los participantes, asignarles roles,

preparar un calendario para la reunin y distribuir el
material a inspeccionar.
Roles:

Organizador
Moderador
Inspector
Lector
Autor
Escriba
Receptor

Proceso de Inspeccin:
Planificacin

Nmero de participantes
2a5

Seleccin de participantes
Personal involucrado en el desarrollo del
producto

Proceso de Inspeccin:
Lanzamiento
Consiste en una primera reunin donde el
autor explica el producto a inspeccionar a
los otros participantes

Proceso de Inspeccin:
Deteccin de defectos

Escudriar un artefacto software para

obtener defectos

Actividad individual y de grupo

Proceso de Inspeccin:
Compilacin y Reunin

Compilacin
Los defectos detectados por cada participante en la
inspeccin deben ser reunidos y documentados

Reunin
Debe decidirse si un defecto es realmente un defecto

Reinspeccin?
Alternativas a la reunin

Deposicin
Estudio en la organizacin