Calidad del Software Ing. Ramn Roque, M.C.

1
1
Calidad del software
Unidad I
Introduccin a la
calidad del software
2
Motivacin al estudio de la calidad
del software
Los clientes se vuelven mas selectivos y
comienzan a rechazar los productos poco
fiables o que no dan respuesta a sus
necesidades.
Necesidad de sistemas confiables, que
cumplan los requerimientos establecidos.
3
Estudio de la calidad
Calidad del PRODUCTO
Calidad del PROCESO de desarrollo.
Son
diferentes
4
Caractersticas especiales del
software
Es un producto MENTAL, sin
lmites por leyes de la fsica.
Es ABSTRACTO y su calidad
tambin lo es.
Se DESARROLLA, no se
fabrica. El costo est
fundamentalmente en el
proceso de diseo y no en la
produccin.
Calidad del Software Ing. Ramn Roque, M.C.
2
5
NO SE DETERIORA con el
tiempo. Sus fallos son
diferentes a los del hardware.
Todos los problemas durante el
mantenimiento estaban all
desde el principio y afectan a
todas las copias del mismo; no
se generan nuevos errores.
Es ARTESANAL en gran
medida.
Caractersticas especiales del
software (continuacin)
6
El mantenimiento de Software
es mas complejo que el
mantenimiento de Hardware.
Es engaosamente fcil
realizar cambios sobre un
producto de software: Los
efectos de los cambios se
propagan de forma explosiva
e incontrolada.
Caractersticas especiales del
software (continuacin)
7
Desarrollo de software es aun
joven. Las tcnicas tambin
por lo que no son totalmente
efectivas o no estn
totalmente calibradas.
El software con errores NO
se rechaza. Se asume que
es inevitable que el software
presente errores.
Caractersticas especiales del
software (continuacin)
8
Anlisis
Diseo
Cdigo
. etc.
CALIDAD
DEL
SOFTWARE
INVOLUCRA TODOS SUS ESTADOS DE EVOLUCION
Calidad del Software Ing. Ramn Roque, M.C.
3
9
El problema de la gestin de la calidad no es lo que la
gente NO sabe sobre ella, el problema es lo que creen
que saben
A este respecto, la calidad tiene mucho en comn con el
sexo: Todo el mundo lo quiere (bajo ciertas condiciones,
por supuesto). Todo el mundo cree que lo conoce
(incluso aunque no quiera explicarlo). Todo el mundo
piensa que su ejecucin solo es cuestin de seguir las
inclinaciones naturales (Despus de todo, nos las
arreglamos de alguna forma). Y por supuesto, la
mayora de la gente piensa que los problemas en estas
reas estn producidos por otra gente (Como si solo
ellos se tomaran el tiempo para hacer las cosas bien)
Philip Crosby. Libro: Quality Is free. Mc Graw Hill, 1979.
10
Problemas al abordar tema
Calidad de Software
Definicin misma de calidad
Comprobacin de la calidad
Control de Calidad.- Actividades para evaluar la calidad de
los productos desarrollados.
Mejora de la calidad
Gestin de Calidad.- Determinacin y aplicacin de las
polticas de calidad de la empresa.
Garanta o aseguramiento de la calidad.- Actividades
planificadas y sistemticas para proporcionar confianza en
que el software satisfar los requisitos dados de calidad.
11
Definiciones de Calidad
Conformidad con los requisitos y confianza en el
funcionamiento [Deming]
Adecuacin para su uso [Juran]
Hacerlo bien a la primera [Crosby]
Capacidad del producto software para satisfacer
los requisitos establecidos [DoD 2168]
12
Definiciones de calidad
(Continuacin)
Suma de todos aquellos aspectos o caracteristicas
de un producto o servicio que influyen en su
capacidad para satisfacer las necesidades
expresadas o implcitas [ISO 8402]
Grado con el cual el cliente o usuario percibe que el
software satisface sus expectativas [IEEE 729-83]
Calidad del Software Ing. Ramn Roque, M.C.
4
13
CALIDAD
Requisitos
que se desea
satisfacer
DEPENDE DE
REQUISITOS
PREESTABLECIDOS
PRODUCTO
REALMENTE
DESARROLLADO
COMPARACION
14
REQUISITOS
QUIERO
QUE ESTE
PROCESO
SEA Y
TENGA Y
YO
OBTENGA
SE LO QUE
QUIERO,
PERO NO SE
COMO
EXPRESARLO
REQUISITOS EXPLICITOS

REQUISITOS IMPLICITOS

15
Visiones de la calidad
Necesaria o Requerida.- La que quiere el
cliente
Programada o Especificada.- La que se ha
especificado explcitamente y se intenta
conseguir.
Realizada.- La que se ha conseguido.
OBJETIVO:
Que Coincidan las 3 visiones.
16
Visiones de la Calidad
Calidad
Requerida
Calidad
Realizada
Calidad
Percibida
(Cliente
Valora)
CUIDADO:
Calidad Realizada pero innecesaria = Gasto intil de tiempo y dinero
Calidad del Software Ing. Ramn Roque, M.C.
5
17
Modelos de calidad de software
Ayudan a definir la calidad del software de forma precisa
y til.
Ayudan en la puesta en prctica del concepto general de
calidad.
Convierten la calidad en algo concreto, que se puede
definir, medir y planificar.
Ayudan a comprender las relaciones que existen entre
diferentes caractersticas del software.
No ha sido demostrada su validez absoluta.
18
Forma jerrquica de la definicin
de Calidad con los Modelos
Calidad del Software
Factores de Calidad
Criterios de Calidad del producto
Mtricas del producto
Punto de Vista del Usuario
(Atributos de calidad Externos)
Punto de Vista del Software
(Atributos de calidad Internos)
Medidas cuantitativas que indican
el grado de calidad que posee un
atributo.
19
Ejemplo
20
Modelo de McCall
Calidad del Software Ing. Ramn Roque, M.C.
6
21
Portabilidad
Interoperabilidad
Facilidad de reutilizacin Transicin del producto
Flexibilidad
Facilidad de prueba
Facilidad de
Mantenimiento
Revisin del producto
Eficiencia
Fiabilidad
Correccin
Integridad
Facilidad de uso Operacin del producto
Factores Punto de vista
Modelo de McCall
22
Eficiencia en ejecucin
Eficiencia en
Almacenamiento
Eficiencia
Precisin
Consistencia
Tolerancia a fallos
Modularidad
Simplicidad
Fiabilidad
Completitud
Consistencia
Trazabilidad
Correccin
Control de Accesos
Facilidad de auditora
Integridad
Facilidad de operacion
Facilidad de
Comunicacin
Facilidad de Aprendizaje
Facilidad de uso Operacin del producto
Criterios Factores Punto de vista
23
Facilidad de uso, Integridad, correccin,
fiabilidad, eficiencia
24
Facilidad de uso, Integridad, correccin,
fiabilidad, eficiencia
Calidad del Software Ing. Ramn Roque, M.C.
7
25
Auto-descripcin
Capacidad de expansin
Generalidad
Modularidad
Flexibilidad
Modularidad
Simplicidad
Auto-descripcin
Instrumentacin
Facilidad de prueba
Modularidad
Simplicidad
Consistencia
Concisin
Auto descripcin
Facilidad de
Mantenimiento
Revisin del producto
Criterios Factores Punto de vista
26
Auto-descripcin
Modularidad
Independencia entre
sistema y hardware
Independencia del
hardware
Portabilidad
Modularidad
Compatibilidad de
comunicaciones
Compatibilidad de datos
Interoperabilidad
Auto-descripcin
Generalidad
Modularidad
Independencia entre
sistema y software
Independecia del
hardware
Facilidad de reutilizacin Transicin del producto
Criterios Factores Punto de vista
27
Ejemplo: Completitud dentro del factor Correccin
Suma de las 3
columnas / 3
Num de SI / 8 Num de SI / 8 Num de SI / 6
Numero Total de Respuestas SI
El cdigo concuerda con el diseo
El diseo concuerda con los requisitos
Todos los informes de problemas se han resuelto
Concuerdan todos los parmetros de llamada a
funciones definidos y referenciados
Se han definido todas las condiciones y procesamientos
para cada punto de decisin
Todas las referencias a funciones estn definidas
Todas las funciones definidas son utilizadas
Todas las referencias a datos definidas son calculadas u
obtenidas de una fuente externa
No hay referencias ambiguas
Implementacin Diseo Requerimientos Pregunta
28
Consejo para utilizar el
Modelo de McCall
Para que las mtricas se puedan usar sin
problemas se recomienda normalizar sus
valores en el intervalo [0 , 1]
Calidad del Software Ing. Ramn Roque, M.C.
8
29
Otras mtricas
Fiabilidad = 1 (Num de errores / Num lineas de codigo)
Facilidad de Mantenimiento = 1 0.1 * (Numero medio de
diasHombre por Correccin)
Portabilidad = 1 (Esfuerzo para portar /
esfuerzo para implementar)
Flexibilidad = 1 0.05 *
(Num medio de diasHombre por cambio)
30
Otros indicadores para evaluar la
Fiabilidad de un programa
Num de errores en el
programa
Num de errores en la
documentacin
Num de problemas que han
aparecido / meses de uso
Porcentaje de usuarios con
problemas
31
Otros indicadores para evaluar
Facilidad de mantenimiento
Probabilidad de que un la causa de un incidente sea
diagnosticado (o un fallo sea corregido).
Tiempo medido de reparacin o cambio
Numero de problemas sin resolver
Tiempo empleado en problemas sin resolver
Porcentaje de cambios que introducen defectos
Nmero de mdulos afectados por cada cambio
32
Estrategias de uso de
un modelo de calidad
Modelo fijo
Definicin particular
de calidad
Calidad del Software Ing. Ramn Roque, M.C.
9
33
MODELO FIJO
Se aceptan los factores, criterios y mtricas
que propone el modelo
Se aceptan las relaciones entre factores y
criterios y entre criterios y mtricas.
Solo es necesario seleccionar un subconjunto
de los factores de calidad como requisitos de
calidad para el proyecto
34
DEFINICION PARTICULAR DE CALIDAD
Se acepta la filosofa de la descomposicin.
Se selecciona un subconjunto de los factores
de calidad como requisitos de calidad para el
proyecto.
Se decide la descomposicin mas adecuada
para los factores de calidad seleccionados.
35
Pasos para el uso de un modelo de calidad
[al principio del proyecto]
Seleccionar cuales de los factores de calidad van a ser
requisitos de calidad en el sistema.
Organizarlos en orden de importancia.
El modelo proporciona los criterios asociados a esos
factores.
Para cada criterio se eligen las mtricas.
Se establecen valores deseables en funcin de datos
histricos.
Se establecen valores mnimos aceptables.
La explicacin de las decisiones realizadas se debe
documentar.
36
Consideraciones al seleccionar los
factores de calidad que sern requisitos
de calidad
La relacin que tienen
los factores con las
caractersticas
peculiares del
proyecto.
Facilidad de
reutilizacin
Algunas funciones del
sistema se usen por
largo periodo de
tiempo
Portabilidad El hardware
evolucione
rpidamente
Flexibilidad Las especificaciones
cambien
frecuentemente
Facilidad de
mantenimiento
Flexibilidad
El ciclo de vida del
sistema sea largo
Optar por este
Factor
Si se espera que
Calidad del Software Ing. Ramn Roque, M.C.
10
37
Consideraciones al seleccionar los
factores de calidad que sern requisitos
de calidad [continuacin]
El coste del factor de
calidad frente al
beneficio que
proporciona
Bajo Interoperabilidad
Alto Facilidad de
Mantenimiento
Alto Facilidad de prueba
Medio Flexibilidad
Medio Portabilidad
Medio Reusabilidad
Bajo Eficiencia
Medio Facilidad de uso
Bajo Integridad
Alto Fiabilidad
Alto Correccin
Ahorro que se puede
esperarsi se
consigue:
Factor
38
Consideraciones al seleccionar los
factores de calidad que sern requisitos
de calidad [continuacin]
Las implicaciones de los
factores de calidad sobre
el ciclo de vida.
Las relaciones entre
factores. Algunos factores
pueden ser conflictivos
entre s. Por ejemplo la
Eficiencia est en conflicto
con todos los dems.
39
Implementar las mtricas.
Analizar los resultados de las
mtricas.
Tomar medidas correctivas si es
necesario
(Si valores obtenidos < valores
mnimos aceptables)
Pasos para el uso de un modelo de calidad
[durante el desarrollo]
40
Validar las medidas predictivas
utilizadas y comprobar si en
efecto se pueden tomar como
indicadores de los valores
finales
Pasos para el uso de un modelo de calidad
[al final del proyecto]
Calidad del Software Ing. Ramn Roque, M.C.
11
41
Desventajas de los modelos de
calidad
Requieren planificacin detallada y una
cuidadosa recoleccin de medidas.
Puede ser costoso incluso para un
numero reducido de factores.
Requieren recursos adicionales.
Por estas razones muchas veces se
adopta una visin de la calidad mas
restringida llamada Visin simplista
42
Visin Simplista de la Calidad
Se basa en el numero de fallos es decir, numero de
Defectos conocidos.
Densidad de Defectos = Numero de Defectos / Tamao del producto
Oscila segn la industria entre 2 y 60 KNCSS
KNCSS = Kilo Non Comment Source Statements
KNCSS = Mil Instrucciones de cdigo fuente sin comentarios
43
Visin simplista de la calidad
Puede ser usada tambin en el
anlisis y diseo, tomando una
definicin de defecto adecuada,
basada en el nmero de cambios
requeridos.
PELIGRO : Puede ser mal utilizada
44
Consideraciones al utilizar la visin
simplista de la calidad
No todos los defectos conducen a un fallo.
Solo los fallos son percibidos por el usuario
(inciden en la calidad).
1/3 de los defectos totales conducen a fallos
que solo ocurren en promedio cada 5000 aos
de tiempo de ejecucin o mas .
Solo un 2 % de los defectos son responsables
de los fallos que ocurren cada 5 aos o
menos
Calidad del Software Ing. Ramn Roque, M.C.
12
45
Consideraciones al utilizar la visin
simplista de la calidad [continuacin]
Un producto que casi no falla puede
tener muchos defectosEl usuario
los percibe como de alta calidad
La visin simplista puede reflejar
ms el proceso de deteccin de
defectos que la calidad del
producto.
Un producto con pocos defectos
detectados puede indicar un
proceso de pruebas poco
exhaustivo y con defectos ocultos.
46
Terminologa
ERROR.- Incorreccin cometida por un humano durante el
proceso de desarrollo.
DEFECTO.-
Consecuencia de un error
Desviacin en el valor esperado.
No afecta el funcionamiento del sistema.
FALLO.- Manifestacin de un defecto en el software.
FALLAS.- Defectos an no detectados.
INCIDENTE.- Situacin en la que se produce y se informa
de un comportamiento no esperado del sistema.
47
Ejercicio
Cree Ud. Que se podra encontrar una nica
frmula matemtica que permitiese calcular el
grado de calidad de cualquier producto de
software?
Elija 3 de entre las 11 caractersticas de calidad
del modelo de McCall y sugiera 2 posibles
mtricas que se podran utilizar para evaluar
dicha caracterstica.
48
Calidad del software
Unidad II
Actividades de Control
de Calidad del Software
Calidad del Software Ing. Ramn Roque, M.C.
13
49
Objetivo de las actividades de
control de calidad
Comprobar si un producto posee o no
una determinada caracterstica de
calidad en el grado requerido.
Cuando un producto no posee una
determinada caracterstica de calidad
se dice que tiene un DEFECTO.
Puede decirse que el Objetivo del
Control de Calidad es identificar
defectos y corregirlos.
50
Actividades de Control de Calidad
Controles Estticos.- Analizan el objeto sin
necesidad de ejecutarlo.
Controles Dinmicos.- Requieren la
ejecucin del objeto que est siendo
probado.
51
Actividades
De
Control
Controles
Estticos
Controles
Dinmicos
Manuales
Automticos
Informales
Disciplinados
Comprobacin
de escritorio
Revisin por pares
Revisiones
Auditoras
Inspecciones
Walkthrough
Del producto
Del proceso
Del sistema
de garanta
de calidad
Anlisis
esttico
automtico
Verificacin formal
Compiladores
Anlisis de flujo
Ejecucin simblica
Mtodos
de caja negra
Mtodos
de caja blanca
Clases de equivalencia
Anlisis de valores frontera
Grafos causa/efecto
Adivinacin de errores
Mtricas de cobertura de
Mtricas de complejidad
Sentencias
Segmentos
Decis. de ramificacin
Condiciones
Combinacin de cond.
Caminos
Ciclomtica
Escencial
Real
52
Controles Estticos Manuales - Informales
Comprobacin de Escritorio.- (Desk checking)
Consiste en examinar a mano e individualmente el
objeto que se acaba de desarrollar. Es el mtodo mas
tradicional para analizar un programa.
Revisin por pares.- (Peer view) Consiste en la
revisin del cdigo de un programador por otros
programadores.
Calidad del Software Ing. Ramn Roque, M.C.
14
53
Controles Estticos Manuales - Disciplinados
Revisiones
Inspecciones
Walkthrough
Auditoras
Del producto
Del proceso
Del sistema de garanta de calidad
54
Revisiones
Reunin formal en la que se presenta el estado actual
de los resultados de un proyecto a un usuario, cliente u
otro tipo de persona interesada, y se realiza un anlisis
estructurado de los mismos.
La evaluacin tcnica no recae sobre las mismas
personas involucradas en la produccin del software.
Tipos de Revisiones:
Inspecciones
Walkthrough (Visita guiada)
55
.El trabajo tcnico necesita ser revisado por la
misma razn que los lapices necesitan gomas
de borrar: Errar es humano. La segunda
razn por la que necesitamos revisiones
tcnicas es que, aunque la gente es buena
descubriendo algunos de sus propios errores,
algunas clases de errores se le pasan por alto
mas facilmente al que los origina que a otras
personas. El proceso de revisin es, por lo
tanto, la respuesta a la plegaria de Robert
Burns:
`Qu gran regalo seria poder vernos
como nos ven los demas!'
."
Freedman y Weinberg
56
Inspecciones
Los participantes van leyendo el documento paso a
paso, guiados por el autor del mismo y comprobando en
cada paso el cumplimiento de los criterios en una lista
de comprobacin.
Calidad del Software Ing. Ramn Roque, M.C.
15
57
Fases en una
inspeccin
SI
NO
SI
NO
Al planificar una inspeccin tambin
se debe determinar:
Los objetivos de la inspeccin
Los criterios de finalizacin
El lugar y la fecha
Disponibilidad de todos los participantes
La agenda de la reunin
58
Documentos generados en una inspeccin
Informe resumen de la inspeccin.-
Conclusiones breves para la direccin
Que se revis, quien lo hizo y la conclusin.
Lista de acciones pendientes.-
Para los autores del producto. No llega a la direccin
Explica lo que est mal y como corregirlo.
Debe ser Claro y sencillo.
Informe de asuntos relacionados.-
Problemas relacionados INDIRECTAMENTE con el objeto revisado.
Informe del proceso de inspeccin.-
Su algo sale mal en el proceso de inspeccin en s mismo.
Informe final.-
Se informa a la direccin del cierre de la inspeccin.
59
Consejos para una inspeccin exitosa
Revisar el producto, no al productor.
Fijar una agenda y mantenerla.
Limitar el debate y las impugnaciones.
Enunciar reas de problemas, pero no intentar
resolver cualquier problema que se ponga de
manifiesto.
Tomar notas escritas.
Limitar el nmero de participantes e insistir en la
preparacin anticipada.
Desarrollar una lista de comprobacin.
Disponer recursos y una agenda.
Llevar a cabo un bien entrenamiento de los
revisores.
Repasar las revisiones anteriores,
60
Walkthrough (Visita Guiada)
Se demuestra la funcionalidad del objeto revisado
mediante la simulacin de su funcionamiento con casos
de prueba y ejemplos.
Se introducen los casos de prueba y se van registrando
los resultados intermedios
Calidad del Software Ing. Ramn Roque, M.C.
16
61
Fases en un walkthrough
Planificacin.- Similar a la planificacin de una
inspeccin, con la diferencia de que no es necesario
asignar roles especficos a los participantes, a excepcin
del presentador, que es quien organiza y gua la
reunin.
Preparacin individual.- Cada revisor examina el
objeto revisado. En este caso no hay lista de
comprobacin.
Reunin del walkthrough
62
Diferencias entre Inspecciones y Walkthrough
A quin ayudan?
Walkthrough.- Al desarrollador
Inspecciones.- Al Gestor
Cul es el objetivo?
Walkthrough.- Entendimiento y comprensin del objeto.
Inspecciones.- Detectar defectos
Quin gua el proceso?
Walkthrough.- La estructura del objeto revisado
Inspecciones.- Una lista de comprobacin (CheckList)
Qu tanta preparacin requieren?
Walkthrough.- No tan planificadas.
Inspecciones.- Se planifican mas formalmente
63
Diferencias entre Inspecciones y Walkthrough
64
Formalidad en las revisiones
(Inspecciones y walkthrough)
Formales
Evento pblico.
Se informa por escrito de los resultados.
Todos son responsables de la calidad de la revisin.
Ventajas:
Resultados son Exitos para el proyecto.
Al ser pblico, se promueve una mejor preparacin de los
participantes.
Desventajas:
Son Impersonales
Informales
Calidad del Software Ing. Ramn Roque, M.C.
17
65
Revisiones tcnicas y
Revisiones de gestin (de proyecto)
Tipos de Revisiones tcnicas
Revisin de la especificacin de los requisitos.
Revisin del diseo.
Revisin del cdigo.
Revisin de las pruebas.
Revisin del manual de usuario.
Objetivos de las Revisiones de gestin
Control de la progresin del proyecto
Evaluacin de los riesgos asociados al proyecto
Evaluacin general del producto
66
Controles Estticos - Automticos
Anlisis Esttico Automtico
Compiladores
Anlisis de flujo
Ejecucin simblica
Verificacin Formal
67
Anlisis Esttico Automtico :
- Compiladores
Pueden detectar:
Expresiones sintcticamente incorrectas
Incompatibilidades de tipo
Errores de Tipo semntico
Etc.
68
Representacin grfica (Grafos)
Nodos: sentencias o segmentos de programa
Arcos: Posibles transiciones de control desde un segmento a otro
Identifica caminos, analiza comportamiento, sita puntos de
ruptura.
Tcnica de Coke y Allen sigue la secuencia del valor de las
variables en cada instruccin ejecutada. Las clasifican en:
Referenciadas [R] .- (Parte derecha de una asignacin, o se accesa)
Definidas [D] .- (Parte izquierda de una asignacin)
No referenciadas [N] .- (Variables locales fuera de la subrutina)
No Afectadas [I] .- No modifica su valor
Anlisis Esttico Automtico :
- Anlisis de flujo
Calidad del Software Ing. Ramn Roque, M.C.
18
69
OJO con :
D D (Se ha definido dos veces sin ser referenciada).
N R( Se ha referenciado sin haberla definido previamente).
R (Se ha referenciado sin haberla definido previamente).
Ejemplo:
A = X + 1
A = 3
MsgBox str(A) etc.
Para la variable A : D D R
Para la variable X : R I I
Anlisis Esttico Automtico :
- Anlisis de flujo [continuacin]
70
Anlisis Esttico Automtico :
- Ejecucin Simblica
Consiste en la ejecucin simblica de ciertos caminos dentro del
programa, durante la cual se verifican ciertas expresiones
simblicas con respecto a ciertas condiciones y afirmaciones
preestablecidas.
Solo se usan smbolos y nombres de variables.
El resultado de la ejecucin simblica se compara con la
especificacin externa del programa y se verifica que coincidan.
Se puede usar un rbol para representar puntos de decisin.
Desventajas:
Programa sin ciclos = Arbol finito. Programa con ciclos = Arbol infinito
Crea indecisibilidad
71
Anlisis Esttico Automtico :
- Ejecucin Simblica [continuacin]
Ejemplo:
72
Anlisis Esttico Automtico :
- Ejecucin Simblica [continuacin]
Ejemplo en forma de rbol:
Calidad del Software Ing. Ramn Roque, M.C.
19
73
Demostracin matemtica de la correccin de un
programa con respecto a sus especificaciones.
Se considera el programa como una cadena de un
lenguaje formal, con sintaxis y semntica formal.
NO siempre es posible realizar este tipo de verificacin.
SOLO se utiliza para sistemas crticos debido al costo
alto que conlleva.
Anlisis Esttico Automtico :
- Verificacin formal
74
Controles dinmicos
Requieren la ejecucin del objeto que se est probando o de un
modelo del mismo.
Prueba del software.- Proceso en el que se ejecuta un sistema con
el objetivo de detectar fallos.
Depuracin.- Proceso de localizacin, correccin y evaluacin del
efecto de la correcin de un Defecto que causa un fallo.
El costo de deteccin de defectos es mas alto que el Costo de
correccin de los mismos.
El proceso de prueba puede toma hasta el 50% o 60% del esfuerzo
dedicado al proyecto.
75
Tipos de pruebas
De acuerdo al IEEE 1012-1986 el conjunto mnimo de pruebas que se
deben realizar son:
Prueba modular, unitaria o de Componentes.- Se prueba cada mdulo
aislado del resto.
Prueba de integracin.- Se prueba la inter-relacin entre los mdulos.
Prueba del sistema.- Comprueba que el sistema satisface los requisitos
del usuario.
Prueba de aceptacin.- Se realiza ya que el sistema se implant.
Demuestra al usuario que el sistema satisface sus necesidades.
Prueba de regresin*.- Comprueba que toda nueva versin de un software
es de no menos calidad que la versin anterior.
76
Controles Dinmicos
- Mtodos de prueba
Mtodos de Caja Negra.-
(Pruebas funcionales o pruebas
orientadas al diseo). Verifican
que el sistema cumpla su funcin
sin importar como lo haga.
Mtodos de caja blanca.-
(Pruebas estructurales). Verifican
la forma como el sistema cumple
con su funcin por medio de su
diseo detallado, diagramas de
flujos de datos, control, cdigo
fuente, etc.
Sistema
Salidas Entradas
Sistema
Salidas Entradas
Calidad del Software Ing. Ramn Roque, M.C.
20
77
Reflexiones sobre las pruebas
Un buen caso de prueba es aquel
que tiene una probabilidad muy alta
de descubrir un nuevo error.
Una prueba tiene xito si descubre un
nuevo error.
Una prueba NO asegura la ausencia
de defectos. SOLAMENTE puede
demostar que existen errores en el
software.
El 80% de los errores est en el 20%
de los mdulos. Hay que identificar
esos mdulos y probarlos muy bien.
78
Reflexiones sobre las pruebas [continuacin]
Las pruebas deben planificarse mucho antes
de que empiecen.
En una prueba es mejor empezar por lo
pequeo y progresar hacia lo grande.
Son mas efectivas las pruebas dirigidas por
un equipo independiente.
TIP: Si se definen casos de prueba con la
mayor probabilidad de encontrar el mayor
numero de errores, se invierte MENOS
cantidad de esfuerzo y tiempo.
Se recomienda disear casos prueba usando
Pruebas de caja blanca y caja negra.
79
Una buena prueba
Tiene una alta probabilidad de
encontrar un error.
No debe ser redundante.
Debe ser La mejor de la
cosecha
No debe ser ni demasiado
sencilla ni demasiado compleja.
80
Mtodos de caja negra
Mtodo de clases de equivalencia.- Dividir las entradas en
grupos, y cada grupo pruebe las mismas propiedades.
Anlisis de valores lmite.- Seleccionar datos de entrada
que caen en la frontera (justo a un lado, justo al otro y justo
en la frontera).
Grafos causa/efecto.- Causas = entradas. Efectos =
Salidas. Se construye un grafo para ver cuales causas
producen ciertos efectos. Se observan cuales causas
producen el mismo efecto.
Adivinacin de errores.- Imaginar cuales son los errores
que se pudieron cometer con mas probabilidad y generar
casos de prueba para comprobar dichos errores.
Calidad del Software Ing. Ramn Roque, M.C.
21
81
Mtodos de caja blanca
Basados en mtricas de cobertura.- Se representa el
programa mediante un grafo. Nodo = Sentencia(s). Arcos =
Flujo. La prueba consiste en probar cada camino posible.
Cobertura de sentencias
Cobertura de segmentos entre decisiones
Cobertura de decisiones de ramificacin
Cobertura de condiciones
Cobertura de todas las combinaciones de condiciones
Cobertura de caminos
Basados en mtricas de complejidad.- Se usa un grafo
para determinar el nmero de caminos independientes y
determinar cuantas pruebas son necesarias para ejecutar
cada camino al menos una vez.
82
Cmo hacer las pruebas
1. Planear la prueba
Objetivo
Objetos a probar
Caractersticas a probar y cuales no
Mtodo de prueba a utilizar
Los recursos a emplear
Plan de tiempos
Productos a generar durante las pruebas
El reparto de las responsabilidades.
83
Cmo hacer las pruebas [continuacin]
2. Disear la prueba.- Instrucciones detalladas
acerca de:
Como llevar a cabo la prueba
De qu forma se van a utilizar los mtodos de prueba
Qu objetos se van a probar en cada una de las
pruebas
Qu criterios se van a utilizar para determinar si el
objeto pasa o no pasa la prueba.
84
Cmo hacer las pruebas [continuacin]
3. Determinar los casos de prueba.-
Especificar el conjunto de casos prueba a
utilizar. Para cada caso se debe
especificar:
Qu objetos se van a probar
Que entradas se van a dar
Cuales son las salidas esperadas
Calidad del Software Ing. Ramn Roque, M.C.
22
85
Cmo hacer las pruebas [continuacin]
4. Planificar el procedimiento de prueba.- Fijar un
conjunto de pasos para la ejecucin de la
prueba. Se especifica detalladamente:
Secuencia exacta de ejecucin de los distintos casos
de prueba.
Los requisitos que hay que cumplir para la ejecucin
de cada caso.
Las condiciones de terminacin de cada uno de ellos.
5. Ejecucin de la prueba / Registro de resultados.
6. Anlisis y evaluacin de la prueba.