CALIDAD

CUN MALO ES EL SOFTWARE

DEFECTUOSO?
Los ms expertos dicen que solo se
requiere de 3 4 defectos por cada 1000
lneas de cdigo para que un programa
tenga mal desempeo. Hay que pensar que
la mayora de los programadores cometen
un error en cada 10 lneas de cdigo que
escriben, lo que multiplicado por los
millones de lneas que hay en muchos
productos comerciales, permite imaginar
que la correccin de errores cuesta a los
vendedores de software al menos la mitad
de sus presupuestos de desarrollo durante
las pruebas.

CONCEPTO DE CALIDAD

Segn ISO 8402, 9000 , 14598 calidad es la capacidad de un

conjunto de caractersticas de un sistema, producto o proceso
para satisfacer los requisitos de clientes y otras partes
interesadas.

La calidad es un concepto complejo, es llegar a un estndar

ms alto que el de los dems.

La calidad desde el punto de vista de los ingenieros de

software es:

Satisfaccin del usuario = producto que

funciona+ buena calidad + entrega
dentro del plazo y del presupuesto fijado

GESTIN DE LA CALIDAD

1.Procesos de ciclo de vida

2.Tcnicas (Cmo?)
3.Organizacin (Quin?)
4.Infraestructura (Con qu?)

CALIDAD DEL SOFTWARE

Se define como:

PROCESO EFICAZ DE SOFTWARE QUE SE

APLICA DE
MANERA QUE CREA UN
PRODUCTO UTIL QUE PROPORCIONA
VALOR MEDIBLE A QUIENES PRODUCEN
YA
QUIENES LOS UTILIZAN.

REVISIN
DEL
PRODUC
TO

1. Facilidad de
recibir
mantenimien
to
2. Flexibilidad
3. Susceptibilid
ad
de
someterse a
prueba

1. Portabilidad
2. Reusabilidad
3. Interoperabilid
ad

TRANSICI
N DEL
PRODUCT
O

FACTORE
S DE
CALIDAD
DE
MCCALL

OPERACI
N DEL
PRODUCT
O

1. Correccin
2. Confiabilid
ad
3. Eficiencia
4. Usabilidad
5. Integridad

FACTORES DE CALIDAD ISO 9126

9126 1
Define el modelo en:
Calidad interna y externa
Calidad de datos.

Identifica seis atributos claves, los cuales son:

Funcionalidad
Confiabilidad
Usabilidad
Eficiencia
Facilidad de recibir mantenimiento
Portabilidad

Calidad interna y externa

Funcionalida
d

Confiabilida
d

Usabilidad

Eficiencia

Facilidad de
recibir
mantenimie
nto

Portabilidad

Adecuacin

Madurez

Fcil
comprensin

Comportamie
nto frente al
tiempo

Facilidad de
anlisis

Adaptabilidad

Exactitud

Tolerancia a
fallos

Fcil
aprendizaje

Uso de
recursos

Capacidad
para cambios

Facilidad de
instalacin

Interoperativi
dad

Capacidad de
recuperacin

Operatividad

Adherencia a
normas

Estabilidad

Coexistencia

Seguridad

Adherencia a
normas

Software
atractivo

Facilidad para
pruebas

Facilidad de
reemplazo

Adherencia a
normas

Adherencia a
normas

Adherencia a
normas

Adherencia a
normas

ISO 9126 - 1
La calidad de uso es definida como la capacidad del software que posibilita
obtencin de objetivos especficos con efectividad, productividad, satisfaccin
y
seguridad

Calidad
de uso
Efectividad

Productivid
ad
Satisfaccin

Seguridad

ISO 9126 2 (MTRICAS EXTERNAS)

Contiene
Terminologa de medidas de mtricas
Uso de mtricas y,
Mtricas externas

ISO 9126 3 (MTRICAS INTERNAS)

Se aplican a un producto de software no ejecutable.

Se aplican durante las etapas de desarrollo.

FACTORES DE CALIDAD QUE SE PERSIGUEN

Intuitiva.- De modo que un novato la pueda utilizar sin mucha
capacitacin.

La interfaz lleva a una comprensin fcil?

Todas las operaciones son fciles de localizar e iniciar?

La interfaz usa una metfora reconocible?

La entrada este especificada de modo que economiza el uso del

teclado o del ratn?

La entrada sigue las reglas de oro?

La esttica ayuda a la comprensin y uso?

Eficiencia.- Grado en que es posible localizar o iniciar las operaciones o

la informacin.

La distribucin y el estilo de la interfaz es eficiente?

Una secuencia de operaciones puede realizarse con economa de datos?

Los datos de salida o el contenido estn presentados de modo que se

entienden de Inmediato?

Operaciones jerrquicas que minimicen lo profundidad de navegacin?

FACTORES DE CALIDAD QUE SE PERSIGUEN

Robustez.- Grado en el que el software maneja entradas
errneas producidas que se presentan por la interaccin del
usuario.

El software reconocer el error si ingresan datos en el lmite

permitido, Continuar operando sin fallar ni degradarse?

La interfaz reconocer los errores cognitivos y guiar de

forma explcita al usuario de forma correcta?

La interfaz da un diagnstico y gua tiles cuando se

descubre una condicin de error asociada con la funcionalidad
del software?

Riqueza.- Grado en el que la interfaz provee un conjunto de

caractersticas
Puede personalizarse
especficas del usuario?

la

interfaz

segn

las

necesidades

La interfaz tiene gran capacidad para permitir al usuario

identificar una secuencia de operaciones comunes con una sola
accin o comando?

Efecto
Efecto de
de las
las acciones
acciones de
de
la
la administracin
administracin

Calidad y seguridad

Negligencia
Negligencia y
y responsabilidad
responsabilidad

Riesgos

Costo de calidad

Software suficientemente bueno

CALIDAD DE SOFTWARE

SOFTWARE SUFICIENTEMENTE BUENO

Contiene caractersticas de alta calidad
Contiene errores conocidos
Lanzar diferentes versiones

COSTO DE CALIDAD

Son los costos en bsqueda de la

calidad.
Prevencin(administracin,
tcnicas, pruebas y capacitacin)
Evaluacin (versiones)
Falla
Internas (antes del envo)
Externas (despus del envo)

COSTO DE CALIDAD
COSTO POR CORREGIR ERRORES EN CODIFICACION
POR DEFECTO

$977

SI SE CORRIGEN 200 ERRORES CRTICOS EL COSTO ES DE

$195400
FASE DE PRUEBAS
SI LOS ERRORES SON 50 (25%)
EL COSTO TOTAL

$7136
$356800
$2472100

150*14102 (mantenimiento)=2115300 + 356800

RIESGOS
Los riesgos no solo implican costos sino riesgos serios
producto de la mala calidad.

HISTORIA
En el mes de noviembre del ao 2000 en el hospital de
Panam, 28 pacientes recibieron rayos gama en su
tratamiento contra el cncer. En los siguientes meses
5 murieron por envenenamiento radiactivo y 15
sufrieron complicaciones serias. Causa?, un paquete
de software desarrollado por una compaa
estadounidense que fue modificado por los tcnicos
del hospital.
Los tres mdicos panameos fueron acusados de
asesinato en segundo grado. La empresa enfrent
grandes problemas en EEUU y en Panam.

NEGLIGENCIA Y RESPONSABILIDAD
Se afirma que el desarrollador es el negligente y
El cliente ha cambiado repetidas ocasiones los requerimientos

CALIDAD Y SEGURIDAD
El software de mala calidad est vulnerable al ingreso de intrusos,
lo que conlleva a muchos riesgos.

EFECTO DE LAS DECISIONES DE LA

ADMINISTRACIN

Decisiones de estimacin
Decisiones de programacin
Decisiones orientadas al riesgo

ECNICAS DE REVISIO

Oh, quiera Dios el regalo darnos

vernos a nosotros como los dems nos v

REVISION TCNICA
El objetivo de las revisiones tcnicas es encontrar
errores durante el proceso para que stos no se
conviertan en defectos despus de liberar el
software.

MODELO DE AMPLIFICACION DEL DEFECTO

ETAPA DEL DESARROLLO
DEFECTOS
ERRORES PASADOS
POR ALTO
ERRORES
DE LA
ETAPA
ANTERIOR

ERRORES
AMPLIFICADOS 1: X
NUEVOS ERRORES
GENERADOS

DETECCION

PORCENTAJE
DE EFICIENCIA
EN LA
DETECCION DE
ERRORES

ERRORES
QUE PASAN A LA
SIGUIENTE ETAPA

AMPLIFICACION DEL DEFECTO SIN REVISION

COSTO RELATIVO DE CORREGIR

ERRORES Y DEFECTOS

ETAPA

COSTO DE ELIMINAR
UN ERROR

DISEO

1.5 UNIDADES DE
COSTO

ANTES DE LAS PRUEBAS

6.5 UNIDADES DE
COSTO

DURANTE LAS PRUEBAS

15 UNIDADES DE COSTO

ENTREGA

67 UNIDADES DE COSTO

EJERCICIO
EJERCICIO 15.5
Estudie la situacin descrita en los ejercicios
anteriores. Si cada uno de los errores que salen al
pblico tiene un costo de $4800 por ser detectado
y corregido, hacer lo mismo para cada error
descubierto en la revisin cuesta $240. Cunto
dinero se ahorra por efectuar revisiones?

METRICAS DE REVISIN Y SU EMPLEO

Esfuerzo de preparacin, Ep: esfuerzo (horas-hombre) de
revisin antes de la revisin real.

Esfuerzo de evaluacin, Ea: esfuerzo (horas-hombre) que se

dedica a la revisin real.

Esfuerzo de la repeticin, Er: esfuerzo (horas-hombre)

dedicado a la correccin de los errores descubiertos durante la
revisin.

Tamao del producto del trabajo TPT, medicin del

tamao del producto del trabajo que se ha revisado, por
ejemplo lneas de cdigo, nmeros de pgina o nmeros de
modelos UML.
Errores menores detectados Errmenores, nmeros de
errores que pueden clasificarse como menores
Errores mayores detectados Errmayores, nmeros de
errores que pueden clasificarse como mayores

ANALISIS DE METRICAS
Erevisin =Ep + Ea + Er
Errtotal = Errmenores + Errmayores
Error de densidad representa el error encontrado por unidad de trabajo producido
en la revisin
Error de densidad = ErrTotal/TPT (tamao del producto del trabajo)
EJEMPLO:
Modelo de requerimientos
UML = 18 diagramas
32 pginas materiales descriptivos
Errores menores = 18
Errores mayores = 4
Errtotal= Errmenores + Errmayores
Errtotal= 18 +4

Errtotal = 22

Error de densidad = 22/32

Error de densidad = 0.68 por pgina

Error de densidad = 22/18

Error de densidad = 1.2 por UML

EFICACIA DEL COSTO DE LAS REVISIONES

Esfuerzo ahorrado por error = Epruebas Erevisiones
Erevisiones = 6
Epruebas = 45
Esfuerzo ahorrado por error = 45 6 30 horas-hombre/error

Las revisiones no quitan tiempo, lo

ahorran

ESPECTRO DE FORMALIDAD

MODELO DE REFERENCIA PARA HACER REVISIONES TCNICAS

REVISIONES INFORMALES

Verificacin de escritorio de un trabajo de IS, hecha con un

colega o una reunin casual.

La reunin de escritorio mejorar su eficiencia si se utiliza

una lista de revisin para cada producto.

Los errores se registran para ser resueltos tiempo despus

por el diseador.

La cantidad de material revisado es pequeo y el tiempo

dedicado es de 1 a 2 horas

Revisin tcnica por pares (verificacin de escritorio

continua)

REVISIONES FORMALES

Revisin tcnica formal (RTF) es una actividad de

control de calidad.

Se centra en una parte relativamente pequea de

un producto del trabajo.

OBJETIVOS de RTF
Descubrir errores de funcionamiento, lgica o
representacin
Verificar que el software cumple con los
requerimientos
Garantizar que el software est representado
con estndares definidos
Obtener software desarrollado de manera
uniforme
Hacer proyectos ms manejables

REUNION DE REVISION
1. Deben estar involucrados de 3 a 5 personas
2. Preparacin previa, no ms de 2 horas de trabajo por persona
3. Reunin debe ser de al menos dos horas

Finalizado trabajo
Desea revisin

LIDER DEL
PROYECTO

LIDER DE
REVISION

Evala
producto
Genera
copias

copias

PRODUCTO
R

1. Aceptan producto sin

modificaciones.
2. Rechazan debido a
errores graves
3. Aceptan de manera
provisional

Revisor
1

Secretar
io

Revisor
2

Anota
revisin
(problemas o
errores)

Revisor
3

REPORTE Y REGISTRO DE LA REVISION

El secretario registra todo lo que se plantea. Se produce una lista de
revisin y se elabora un reporte tcnico formal de la revisin.
Que debe responder las siguientes preguntas:
1. Qu fue lo que se revis?
2. Quin lo revis?
3. Cules fueron los descubrimientos y las conclusiones?
El resumen del reporte (1 hoja) se entrega al lder del proyecto y a
otras partes interesadas.
Lista de pendientes:
1. identificar reas problema
2. gua al productor
Elaborar un procedimiento(verifique pendientes)

LINEAMIENTOS
1. Revise el producto, no al productor
2. Establezca una agenda y sgala
3. Limite el debate y las contestaciones
4. Enuncie reas problema, pero no intente resolverlas
5. Tome notas por escrito
6. Limite el nmero de participantes e insista en la preparacin previa
7. Desarrolle una lista de verificacin para cada producto
8. Asigne recursos y programe tiempo para las revisiones tcnicas
formales
9. D una capacitacin significativa
10. Revise las primeras revisiones

REVISIONES ORIENTADAS AL MUESTREO

Se usan cuando no hay tiempo y los recursos son limitados.
ETAPAS
1. Inspeccionar una fraccin ai de cada producto de trabajo i. Registrar
el nmero de fallas f encontradas dentro de ai.
2. Desarrollar una estimacin gruesa f*(1/ai)
3. Ordenar descendentemente de acuerdo al nmero de fallas de cada
uno9
4. Dedicar los recursos a aquellos que tengan > nmero de fallas

PREGUNTAS
1. Explique la diferencia entre un error y un defecto
2. Por qu no puede esperarse a las pruebas para encontrar
y corregir todos los errores?
3. Cul de las caractersticas del modelo de referencia
piensa usted que tiene el mayor efecto en la formalidad de
la revisin? Explique por qu
4. Se le ocurre algn caso en el que una verificacin de
escritorio genere problemas en lugar de beneficios?
5. Una revisin tcnica formal es eficaz slo si cada quien se
prepara por adelantado. Cmo se reconoce a un
participante que no se haya preparado? Qu hara si
usted fuera el lder de la revisin?
6. Al considerar todos los lineamientos para la revisin, Cul
piensa que sea el ms importante? Y por qu?

ANALISIS DE LAS METRICAS

"Cuando no tengas tiempo para hacer
las cosas bien, siempre tendrs tiempo
para hacerlas otra vez. Ley de
Meskimen

ASEGURAMIE
NTO DE LA
CALIDAD
(Administracin de la calidad)

ASEGURAMIENTO DE LA CALIDAD DE
SOFTWARE
El control y aseguramiento de la calidad son importantes y esenciales para
cualquier negocio que genere productos que utilicen otras personas.
ELEMENTOS DE ASEGURAMIENTO DE LA CALIDAD DE SOFTWARE (ACS)
1. Estndares: Disponibles en IEEE y la ISO
2. Revisiones y auditoras (actividades de control de calidad)
3. Pruebas (detecta errores)
4. Coleccin y anlisis de los errores
5. Administracin del cambio (el cambio mal administrado genera mala
calidad)
6. Educacin(IS, Gerentes y otros participantes)
7. Administracin de los proveedores (paquetes contenidos en una caja
(Office), shell personalizado, software contratado)
8. Administracin de la seguridad (cortafuegos, sistemas de seguridad)
9. Seguridad (evaluar efecto de fallas para disminuir riesgos)
10.Administracin de riesgos (la administracin de riesgos se la realice en
forma apropiada).

TAREAS, METAS Y MTRICAS DEL ACS

Ingeniero de Software

Grupo de ACS

SOFTWARE
Planear
Supervisar
Registrar
Analizar
Hacer
Reportes

Trabajo Tcnico

METAS, ATRIBUTOS Y MTRICAS

1. Calidad de los requerimientos
Revisiones completas de los requerimientos
2. Calidad del diseo
El diseo debe estar apegado a los requerimientos
3. Calidad del cdigo
Estndares de codificacin
Fcil mantenimiento
4. Eficacia del control de calidad
Atributos como indicadores de calidad
Mtricas

PRUEBAS DE SOFTWARE
VERIFICACIN Y VALIDACIN V&V
Verificacin: Tareas que garantizan que el
implementa correctamente una funcin especfica.

software

Construimos el producto correctamente?

Validacin: Conjunto diferente de tareas que aseguran que el
software que se construye sigue los requerimientos del cliente.
Construimos el producto correcto?
Organizacin de las pruebas
El IS est puede ser un evaluador objetivo del software que
dise?
Cmo ve el IS a los evaluadores?
El IS debe estar presente junto con el grupo de prueba
independiente al momento de revisar el software? por qu?

PRUEBAS DE SOFTWARE CONVENCIONAL

1. PRUEBA DE UNIDAD.- Se prueba la unidad ms pequea el
componente o mdulo de software.
1.La interfaz se prueba para verificar que la informacin fluya de
manera adecuada hacia y desde la unidad de software.
2.Estructura de datos locales mantienen su integridad durante todos
los pasos de ejecucin de un algoritmo.
3.Todas las rutas se ejecutan para que el mdulo se ejecute al menos
una vez
4.Revisar pruebas a las estructuras selectivas, de modo que se
descubran errores en clculos.
5.Pruebas de frontera, se da cuando se procesa el ensimo elemento
de un arreglo, la ensima repeticin de un bucle.
6.Anticipar las condiciones de errores, enrutar o terminar
limpiamente un error (enfoque antierrores)
1.La descripcin del error no puede ser entendida
2.El error indicado no corresponde con el error que se encuentra
3.La condicin del error causa la intervencin del sistema antes de
manejar el error
4.El procesamiento de la excepcin-condicin es incorrecto
5.La descripcin del error es insuficiente

PROCEDIMIENTO DE PRUEBAS DE UNIDAD

PRUEBAS DE UNIDAD CODIFICACIN
GENERAR EL CDIGO PRUEBAS DE UNIDAD

Controlador

Mdulo
que se va
a probar

Representan
te
(stubs)

CASOS DE
PRUEBA

Representan
te
(stubs)
RESULTADOS

PRUEBAS DE INTEGRACIN
La integracin es muy importante una vez que se han
realizado pruebas de unidad.
La prueba big bang, se prueba el software como un
todo
La integracin incremental, el programa se construye
y prueba en pequeos incrementos.

INTEGRACIN DESCENDENTE
Programa
Principal

M2

M5

M8

M1

M3

M6

M4

M7

PASOS PARA INTEGRACIN DESCENDENTE

1. El mdulo de control principal se usa como controlador y los
representantes (stubs) se sustituyen con los componentes
directamente subordinados al mdulo de control principal.
2. Dependiendo el enfoque de integracin, los subordinados se
sustituyen uno a la vez con datos reales
3. Las pruebas se llevan a cabo conforme se integra cada componente
4. Al completar las pruebas, cada representante se sustituye con el
componente real.
5. Las pruebas de regresin se las realiza para asegurar que no se
introdujeron nuevos errores.

INTEGRACIN ASCENDENTE
Comienza la prueba con mdulos atmicos.
Se eliminan los representantes
Pasos:
1. Los componentes en el nivel inferior se combinan en grupos que
realizan una subfuncin de software especfica
2. Se escribe un controlador a fin de coordinar las entradas y salidas
de casos de prueba.
3. Se prueba el grupo
4. Los controladores se remueven y los grupos se
movindolos hacia arriba en la estructura del programa.

combinan

ESTRATEGIAS DE PRUEBA PARA SOFTWARE ORIENTADO A OBJETO

PRUEBA DE UNIDAD

Se prueba una clase encapsulada

Los mtodos son las unidades comprobables ms pequeas

Una operacin no se prueba como algo aislado sino como parte de

un todo.

CLASE A
Operacin
x
SUBCLASE
B
Operacin
x

SUBCLASE
C

SUBCLASE
D
Operacin
x

DIFERENCIA ENTRE PRUEBA DE UNIDAD CONVENCIONAL Y ORIENTADA A

OBJETO

CONVENCIONAL

OO

SE ENFOCA SOBRE EL
DETALLE ALGORITMICO DE UN
MDULO

SE ENFOCA EN LAS
OPERACIONES ENCAPSULADAS
POR LA CLASE Y EL
COMPORTAMIENTO DE ESTADO
DE LA MISMA.

PRUEBA DE INTEGRACIN EN EL CONTEXTO OO

1. Prueba basada en hebra.- Integra conjunto de clases para
responder a un evento.
Se analiza hebra por hebra.
Regresin para que no existan efectos colaterales.
2. Prueba basada en uso.- Se prueban las clases independientes y
luego las dependientes.

ESTRATEGIAS DE PRUEBA PARA WEBAPPS

1. El modelo para la Webapp se revisa para descubrir errores
2. Se revisa la interfaz para que todos los casos de uso puedan adecuarse
3. El modelo se revisa para descubrir errores de navegacin
4. Interfaz para descubrir errores en la presentacin y/o navegacin
5. A cada componente se le aplica una prueba de unidad
6. Se prueba la navegacin a lo largo de toda la aplicacin
7. Se implementa en varias configuraciones ambientales y se prueba su
compatibilidad en cada configuracin.
8. Se realizan pruebas de seguridad para encontrar vulnerabilidad
9. Se realizan pruebas de rendimiento
10. Se prueba mediante una poblacin de usuarios finales.

VALIDACION: PRUEBAS
Comienzan al finalizar las pruebas de integracin
Criterios
1. Las caractersticas de funcin o rendimiento se conforman de
acuerdo con las especificaciones y se acepta
2. Se descubre desviaciones y se crea una lista de deficiencias