Confiabilidad de Software

Palma de Mallorca, 28 y 29 de mayo de 1999
La Confiabilidad en el Software
J. L. Roca
1.Introduccin
2.Calidad y Confiabilidad
3.La Confiabilidad de un Software
4.Errores y Fallas
5.Confiabilidad y Complejidad
6.Modelos
de Confiabilidad
C j
7.Obtencin de Softwares Confiables
8.Metodologas de Trabajo
9.Herramientas
10.Conclusiones
J. L. Roca
Introduccin
Palma de Mallorca,
28 y 29 de mayo de 1999
Esfuerzo de Desarrollo de Software 80%.

Esfuerzo de Desarrollo de Hardware 20%.
Hace tres dcadas esta relacin era inversa.
Se utilizaban para el Hardware tcnicas de
Control de Calidad por atributos o por variables
C j
como
ser:
AOQL (Average Outgoing Quality Level) a la
salida.
AQL (Acceptable Quality Level) a la entrada.
LPTD (Low Total Percentage Defects).
J. L. Roca
Introduccin
Palma de Mallorca,
28 y 29 de mayo de 1999
Actualmente el Control estadstico de procesos:

SQC (Statistics Quality Control)
TQM (Total Quality Management)
Desde hace una dcada la importancia del
software a la hora de disear un sistema fue
creciendo.
C j
Pocos utilizan las Herramientas propuestas por la
denominada Ingeniera del Software para mejorar
la calidad y confiabilidad de un programa.
Debe hacerse un balance entre Disponibilidad
(Availability) y Seguridad (Safety).
J. L. Roca
Introduccin
Palma de Mallorca,
28 y 29 de mayo de 1999
Un sistema totalmente Seguro nunca funcionar.

Un sistema siempre Disponible nunca ser
totalmente seguro.
Un Bug (error) en un software puede provocar
una falla (fault) que termine con una misin
C j
espacial.
O puede implicar vidas humanas cuando la
aplicacin es electromdica.
Esta es la importancia que da a da esta teniendo
el Software en un sistema.
J. L. Roca
Introduccin
Palma de Mallorca,
28 y 29 de mayo de 1999
Relacin Costos Hardware-Software
% del Costo Total
100
Hardware
50
C
Software
0
1960
1975
Ao
2005
J. L. Roca
y Confiabilidad
Palma de Calidad
Mallorca,
28 y 29 de mayo de 1999
La Calidad es una medida de la

performance de un elemento en un
punto
determinado
del
tiempo,
presumiblemente t=0.
La Confiabilidad es una medida de
a lo largo del tiempo.
Cperformance
j
Una est relacionada con la variable
aleatoria proporcin la otra con la
variable aleatoria tiempo.
El Software no admite la misma
discriminacin.
J. L. Roca
Palma de Calidad
Mallorca,
28 y 29 de mayo de 1999
y Confiabilidad
Es posible hablar de Calidad, expresada sta como

proporcin de errores (Bugs) en el programa.
Mientras la Confiabilidad est expresada en
funcin de la tasa de fallas (Hazard Failure Rate).
La mayora de los especialistas hablan de Calidad y
Confiabilidad en forma indistinta.
C j
Lo cierto es que un Software no puede producirse
en serie varias veces.
Una vez desarrollado, probado y liberado, todos
los Softwares sern copia de ste, en cualquier
sistema que corran.
J. L. Roca
Palma de Calidad
Mallorca,
28 y 29 de mayo de 1999
y Confiabilidad
Los errores, no as las fallas, sern

siempre los mismos, no importa el
entorno en el que corran.
Por lo tanto, es mucho ms correcto
hablar de Confiabilidad de un
Software que de la Calidad del
mismo.
C
J. L. Roca
10
de yun29
Software
PalmaLadeConfiabilidad
Mallorca, 28
de mayo de 1999
Se dice que un Software es

confiable si realiza lo que el usuario
desea, cuando as lo requiera.
No es confiable si as no lo hiciera.
A nuestros fines un Software no es
Confiable cuando falla.
Las fallas se deben a errores en el
Software.
Si corregimos estos errores sin
introducir nuevos, mejoramos la
Confiabilidad del Software.
J. L. Roca
11
de yun29
Software
Mallorca, 28
de mayo de 1999
Proporcin de Errores de un Software durante su Ciclo de Desarrollo
Codificacin y Test
Modular
Integracin y
Test
13%
10%
Operacin y
Mantenimiento
5%
17%
Diseo
55%
Anlisis de Requerimientos
J. L. Roca
12
de yun29
Software
Mallorca, 28
de mayo de 1999
El 72% de los errores se originan en: el
traslado de los requerimientos del usuario y en
el diseo lgico.
Podremos aumentar
Software haciendo
C j
primeras etapas.
la Confiabilidad de un
hincapi en estas dos
Fuentes de diversos tipos aseveran que, es en el

diseo, en donde debe ponerse nfasis para
reducir la proporcin de errores.
J. L. Roca
13
de yun29
Software
Mallorca, 28
de mayo de 1999
Proporcin de Errores de un Software por reas de Conflicto
Cmputo
Humano 5%
Entorno
5%
C j
Documentacin
5% 2%
Interfase
6%
Datos
6%
Otros 7%
Traslado de
Requerimientos
36%
28%
Diseo Lgico
J. L. Roca
14
de yun29
Software
Mallorca, 28
de mayo de 1999
Hemos observado nueve categoras en las que se

divide la generacin de errores.
La experiencia demuestra que:
C
Aproximadamente el 76% de los errores no son

descubiertos hasta bien entrada la etapa de
pruebas integrales.
J. L. Roca
15
de yun29
Software
Mallorca, 28
de mayo de 1999
Costos de Correccin de Errores de un Software
16
14
12
10
8
6
4
2
Tiempo
0
Requerimientos
Diseo
Codificacin Test
Operacin
J. L. Roca
16
de yun29
Software
Mallorca, 28
de mayo de 1999
El costo de deteccin y correccin de errores

durante y despus de las etapas de integracin
y test resultan entre 10 y 15 veces ms que en
las etapas de desarrollo y codificacin.
Estudios realizados concluyen que el medio

C j
ambiente en el que se desarrolla el Software
contribuye enormemente al aumento de errores.
La Confiabilidad del Software pasa a ser un
problema de Management y no Tcnico
J. L. Roca
17
Errores
y Fallas
un Software
Palma de
Mallorca,
28de
y 29
de mayo de 1999
Histricamente,
una
forma
de
aumentar la Confiabilidad de un
Software era correrlo y probarlo
extensivamente antes de liberarlo.
CNo
es efectivo probar la Confiabilidad
j
en el producto sino hacerla, es decir
fabricarla en el mismo.
La Confiabilidad deber ser diseada
en el producto.
J. L. Roca
18
Errores
y Fallas
un Software
Palma de
Mallorca,
28de
y 29
de mayo de 1999
Teniendo un 72% de errores generados en el

traslado de los requerimientos del usuario, el
nfasis debe ser puesto en ese punto.
C jEs mucho ms efectivo resolver los errores en la
misma fase de diseo que en la de prueba.
Cada vez que se corrige un error se generan nuevos
con una cierta probabilidad.
J. L. Roca
19
Errores
y Fallas
un Software
Palma de
Mallorca,
28de
y 29
de mayo de 1999
Es mucho ms costoso encontrar, corregir y

documentar errores en los ltimos peldaos del ciclo
de vida que al comienzo.
Es necesario utilizar Herramientas, que en base a
C j
modelos ayuden a determinar parmetros que sirvan
de anlisis.
Las Herramientas son provistas por la asi llamada
Ingeniera de Software
J. L. Roca
20
Falla28
unySoftware?
Palma dePorqu
Mallorca,
29 de mayo de 1999
ENTRADAS
Ei
Esquema de un programa
E = {Ei/i = 1,2,....N}
N = # de entradas posibles
PROGRAMA
F(Ei)
SALIDAS
F(Ei)
^
F(Ei)
F(Ei)
Real
Estimada
^
F(Ei)
FALLA
J. L. Roca
21
Falla28
unySoftware?
Palma dePorqu
Mallorca,
29 de mayo de 1999
Un programa establece una correspondencia entre
entradas y salidas va una determinada funcin
estimada o propuesta
La diferencia entre esta funcin y la real ejecutada
por
el programa para un conjunto determinado de
C j
datos de entrada, es lo que da origen a la falla.
Son las entradas las que interactan con un
determinado error en la programacin y por lo tanto
generan salidas no esperadas (fallas).
J. L. Roca
22
Falla28
unySoftware?
Palma dePorqu
Mallorca,
29 de mayo de 1999
Esquema de un programa
{E1}
C
{E2}
E = {Ei/i = 1,2,....N}
N = # de entradas posibles
Error
La Falla aparece cuando

el conjunto de Entradas
Interacta con el Error
La FALLA se Auto expone
J. L. Roca
23
Falla28
unySoftware?
Palma dePorqu
Mallorca,
29 de mayo de 1999
Ignorancia de los requerimientos del usuario.

Ignorancia del entorno en que se utiliza el Software.
Escaso flujo de informacin entre usuario y programador
Escasa documentacin del Software.
ERRORES (BUGS)
FALLAS (FAULTS)
J. L. Roca
24
PalmaEspecificacin
de Mallorca,de28losy Requerimientos
29 de mayo de 1999
No Ambigua
Completa
Caractersticas de
Una Especificacin
de Requerimientos
de un software
ERS
Verificable
Consistente
Modificable
Trazable
Utilizable
J. L. Roca
25
de Depuracin
Debugging
PalmaProceso
de Mallorca,
28 y 29o de
mayo de 1999
Identificacin del Problema
Diagnstico del error
Correccin del error

Prueba de la correccin del error
Reinicio del programa
J. L. Roca
26
Definicin28
de yErrores
Palma de Mallorca,
29 de mayo de 1999
Errores Previos Fijos: Persisten en el

Software luego de que el programador ha
trabajado en l corrigiendo un error o
cambiando un cdigo (Debugging).
C
Errores Generados: No existan en el

Software, hasta que son introducidos como
consecuencia del Debugging.
J. L. Roca
27
Errores
Palma de Mallorca,
28Clsicos
y 29 de mayo de 1999
Matrices sobre grabadas
Errores en los bits de bandera
Errores en los bits de indexado
Errores en los bits de desplazamiento
C
Errores de complementacin aritmtica

Problemas de puntero
Errores de transferencia de control
Problemas de direccionamiento indirecto
Problema de reinicio del programa
J. L. Roca
28
y Complejidad
Palma deConfiabilidad
Mallorca, 28
La complejidad de un programa de computacin es

una medida de la dificultad para llevar a cabo esa
computacin y est muy relacionada con su
confiabilidad.
Es evidente que cuanto mas complejo sea el
algoritmo de cmputo tanto mas probabilidad existe
de que se cometan errores en su programacin y por
lo tanto de fallas del software y deterioro de su
confiabilidad.
C
J. L. Roca
29
y Complejidad
Palma deConfiabilidad
Mallorca, 28
Esta demostrado que bajando la complejidad de un

software su confiabilidad mejora.
Existen diversas teoras que permiten evaluar la
complejidad del software.
C
Algunas son mas utilizadas que otras por su

sencillez, sin embargo son dos las principales:
La complejidad McCabe y la Complejidad Halstead.
J. L. Roca
30
Complejidad
Palma de Mallorca,
28McCabe
III
C
I
I
I
V
V(G) = e-n+2.p = 119+2.1
=4
V(G) = # de reas en que deda dividido el plano

V(G) = # de desiciones + 1
J. L. Roca
31
Complejidad28
Halstead
Palma de Mallorca,
Longitud del programa : N=N1+N2

Vocabulario utilizado en el programa :
Volumen del programa : V=(N1+N2).log2 (
1+ 2
1+ 2)=N.log2
Volumen potencial del programa : V*=(2+n).log2 (2+n)

Nmero de operandos de entrada-salida necesarios para el
Cprograma
j
: n = 2.
Relacin de volmenes : L=V*/V
Esfuerzo de programacin : E=V/L=V2/V*
Nmero de errores : B=V/S*=V/3000
J. L. Roca
32
Ley de28
Zipf
Palma de Mallorca,
Teora del Lenguaje Natural
Operadores
Operandos
Verbos
Nombres
Smbolos
C j
Palabras
Expresin
Frase
Programa
Libro
Mdulo
Prrafo
Chomsky
Tipos de
Instrucciones
Calculado
Real
Tipos
Distintos
n=t.(0,5772+ln t)
Operadores
12
36,7
31
Operandos
25
24
Operadores +
Operandos
21
76
55
J. L. Roca
33
Modelos
de Confiabilidad
de de
un Software
Palma
de Mallorca,
28 y 29
mayo de 1999
Existen tres clasificaciones importantes de los
modelos utilizados en el anlisis de Confiabilidad
de un Software:
Modelos de acuerdo al
C j
Ciclo de Vida.
Modelos de acuerdo a la
Naturaleza del Proceso de Falla.
Modelos de acuerdo a
Consideraciones Estructurales.
J. L. Roca
34
Diagrama
Operativo
Modelos
Palma
de Mallorca,
28 yUtilizando
29 de mayo
de 1999
Datos
Modelo Apropiado
Estimacin Parmetros
Seleccin otro Modelo
C
Alimentacin Modelo
Rechazo
Prueba de Ajuste
Aprobacin
Estimacin Perfomance
Errores No
Detectados
Tiempo hasta prxima Falla
Confiabilidad
Decisin: Sistema listo para la Liberacin

J. L. Roca
35
de Acuerdo
Ciclo
Vidade 1999
PalmaModelos
de Mallorca,
28 yal29
de de
mayo
FASE DESARROLLO
El software se prueba y se corrige - La confiabilidad crece
(Crecimiento de la confiabilidad con el tiempo)
JELINSKI-MORANDA DE-EUTROPHICATION (Determinstico)
MUSA (Determinstico)
C
SHOOMAN (Determinstico)
POISSON (Determinstico)
SHICK-WOLVERTON (Determinstico)
TRIVEDI-SHOOMAN (Markoviano)
INPUT DOMAIN BASED (Estocstico)
LITTLEWOOD-VERRAL (Bayesiano)
J. L. Roca
36
de Acuerdo
Ciclo
Vidade 1999
PalmaModelos
de Mallorca,
28 yal29
de de
mayo
FASE VALIDACIN
El software no se corrige-Se aprueba o rechaza
(Softwares para aplicaciones crticas)
NELSON
SHOOMAN PATH RELIABILITY
INPUT DOMAIN BASED MODEL
C
FASE OPERACIONAL
Validacin continua-Entradas al software
dependientes
(Softwares para control de Procesos)
MARKOV PROCESS -LITTLEWOOD - CHENG
J. L. Roca
37
de Acuerdo
Ciclo
Vidade 1999
PalmaModelos
de Mallorca,
28 yal29
de de
mayo
FASE MANTENIMIENTO
C
Adicin de nuevas posibilidades-Mejora de algoritmos

(Existen pocos modelos)
J. L. Roca
38
de Acuerdo
Ciclo
Vidade 1999
PalmaModelos
de Mallorca,
28 yal29
de de
mayo
MEDIDA DE EXACTITUD (CORRECTNESS)

Medida de la confianza en el test
SIEMBRA DE ERRORES: BASIN,MILL,DE MILLO-LIPTON
C
FENOMENOLOGICOS: HALSTEAD
ESTADISTICOS: NELSON,EHRENBERGER,BROWN-LIPOW
J. L. Roca
39
Modelos
de Acuerdo
de Falla
Palma
de Mallorca,
28 aly Proceso
29 de mayo
de 1999
TIEMPO ENTRE FALLAS

Se estudia el tiempo entre fallas
JELINSKI-MORANDA DE-EUTROPHICATION
GOEL-OKUMOTO-IMPERFECTO DEBUGGING
SCHICK-WOLVERTON
C
LITTLEWOOD-VERRAL-BAYESIANO
SIEMBRA DE ERRORES
Se estudia la reaccin ante la introduccin forzada de errores
MILLS
J. L. Roca
40
Modelos
de Acuerdo
de Falla
Palma
de Mallorca,
28 aly Proceso
29 de mayo
de 1999
CONTEO DE FALLAS
Se estudia el nmero de fallas detectadas
GOEL-OKUMOTO-POISSON NO HOMOGENEO
GOEL-POISSON NO HOMOGENEO GENERALIZADO
C
MUSA-TIEMPO DE EJECUCIN
SHOOMAN-EXPONENCIAL
POISSON GENERALIZADO
IBM-BINOMIAL-POISSON
MUSA-OKUMOTO-POISSON LOGARITMICO
J. L. Roca
41
Modelos
de Acuerdo
de Falla
Palma
de Mallorca,
28 aly Proceso
29 de mayo
de 1999
DOMINIO DE LAS ENTRADAS

Se estudia la reaccin ante la variabilidad de las entradas
C j
NELSON
RAMAMOORTHY-BASTANI
J. L. Roca
42
Modelos
de Acuerdo
de Falla
Palma
de Mallorca,
28 aly Proceso
29 de mayo
de 1999
MEDIDA DE EXACTITUD (CORRECTNESS)

Medida de la confianza en el test
C jSIEMBRA DE ERRORES: BASIN,MILL,DEMILLO-LIPTON
FENOMENOLOGICOS: HALSTEAD
ESTADISTICOS: NELSON,EHRENBERGER, BROWN-LIPOW
J. L. Roca
43
de Acuerdo
a Estructura
Palma Modelos
de Mallorca,
28 y 29
de mayo de 1999
MACROMODELOS
Se estudia el software como una caja negra
JELINSKI-MORANDA
GOEL-OKUMOTO
SCHICK-WOLVERTON
LITTLEWOOD-VERRAL
SHOOMAN
MUSA
NELSON
MILLS
J. L. Roca
44
de Acuerdo
a Estructura
Palma Modelos
de Mallorca,
28 y 29
de mayo de 1999
MICROMODELOS
Se estudia la estructura interna del software
SHOOMAN
MODELOS DE DISPONIBILIDAD
Se estudia el proceso del mantenimiento del software
SHOOMAN-TRIVEDI
J. L. Roca
45
Macromodelo
JELINSKI-MORANDA
Palma
de Mallorca,
28 y 29 de mayo(1)
de 1999
z (ti ) =
.(N-i+1)
z (ti ) = Tasa de fallas del periodo de tiempo ti de debugging.

ti = Periodo de tiempo de debugging ( no incluye tiempos de
reparacin del software ).
= CConstante
de proporcionalidad.
j
N = Nmero total de errores del software.
i = Nmero de errores encontrados y removidos despus del
periodo de tiempo ti de debugging.
J. L. Roca
46
Macromodelo
JELINSKI-MORANDA
Palma
de Mallorca,
28 y 29 de mayo(2)
de 1999
N N-1
N-2
N-3
N-4
0 0
t1
z (ti ) =
t2
.(N-i+1)
t3
t4
ti
C(ti ) = exp.[ - .(N-i+1).ti ]
J. L. Roca
47
Macromodelo
JELINSKI-MORANDA
Palma
de Mallorca,
28 y 29 de mayo(3)
de 1999
C(ti ) = exp.[ - .(N-i+1).ti ]

L(N,
C
L(N,
)=
n
i=1
f (ti ) =
) = ln.[L(N,
n
i=1
n
)] =
[ .(N-i+1)].exp.[ - .(N-i+1).ti ]
{ln.(N-i+1) + ln.
i=1
- (N-i+1). .ti }
L(N, )/ N = 0
L(N, )/ = 0
J. L. Roca
48
Macromodelo
JELINSKI-MORANDA
Palma
de Mallorca,
28 y 29 de mayo(4)
de 1999
n
i=1
C
[1/(N-i+1)] =
= n / [N.
i=1
n
ti -
i=1
ti
i=1
N,
(i-1). ti ]
J. L. Roca
49
Macromodelo
JELINSKI-MORANDA
Palma
de Mallorca,
28 y 29 de mayo(5)
de 1999
i
1
2
3
4
5
6
7
8
9
10
11
12
13
ti
9
12
11
4
7
2
5
8
5
7
1
6
1
i
14
15
16
17
18
19
20
21
22
23
24
25
26
ti
9
4
1
3
3
6
1
11
33
7
91
2
1
35
30
N=31
=0,00734
25
N(ti )
20
15
10
5
0
0
50
100
150
200
ti
250
J. L. Roca
50
Macromodelo
JELINSKI-MORANDA
Palma
de Mallorca,
28 y 29 de mayo(6)
de 1999
0,25
1,2
C(ti )
N=31
=0,00734
0,2
z(ti )
N=31
=0,00734
0,8
0,15
0,6
C j 0,1
0,4
0,05
0,2
0
0
50
100
150
200
ti
250
50
100
150
200
ti
250
J. L. Roca
51
de Softwares
Confiables
Palma Obtencin
de Mallorca,
28 y 29 de
mayo de 1999
C j
Existen tcnicas de programacin simples:

ESTRUCTURACIN
MODULARIZACIN
KISS
Tcnicas de programacin complejas:
N-VERSIONES DE UN PROGRAMA
BLOQUES RECUPERABLES
J. L. Roca
52
Metodologas
Trabajo
Palma de Mallorca,
28 de
y 29
de mayo de 1999
1.Modelo de Cascada (Radice - 1985)

2.Modelo de Prototipo (Gomaa & Scott - 1981)
3.Modelo de Espiral (Bohem - 1988)
4.Modelo Iterativo (Basili & Turner - 1975)
5.Modelo Orientado a Objetos (Branson & Herness - 1992)
6.Modelo de Sala Limpia (Linger & Hausler - 1992)
C j
7.Modelo de Prevencin de Defectos (Jones - 1990)
8.Modelo de Capacidad de Maduracin (Humphrey -1989)
9.Modelo de Productividad (Jones - 1986)
10.Modelo Malcom Baldrige (DOC - 1988)
11. Modelo ISO 9000-3 (ISO - 1995)
J. L. Roca
53
: Total Quality
Management
Palma TQM
de Mallorca,
28 y 29
de mayo de 1999
Procedimientos y Mtodos
PROCESO
Personal-Motivacin
Entrenamiento
Herramientas
y Equipos
J. L. Roca
54
Planeamiento
de la Calidad
Costo de la No Calidad
Triloga 28
de y
JURAN
Palma de Mallorca,
29 de mayo de 1999
Control de
la Calidad
Zona Original de CC
Prdida
Crnica
Nueva Zona de CC
Mejora de la Calidad
Tiempo
Experiencia Ganada
J. L. Roca
55
: Capability
Model de 1999
Palma CMM
de Mallorca,
28 yMaturity
29 de mayo
TQM aplicado al Software
Proyecto A
Proyecto X
C
Proyecto B
Sistema
Proyecto C
TQM
Hardware
Software
CMM
Organizacin
J. L. Roca
56
CMM -de5 Mallorca,

Niveles del28
Proceso
de Maduracin
Palma
y 29 de
mayo de 1999
Mejorado
Continuamente
Predecible
Estandarizado
C
Disciplinado
#1
#2
#3
#4
#5
Optimizado
Gestionado
Definido
Repetible
Inicial
J. L. Roca
57
Modelo
de Cascada
Std. de 1999
Palma de
Mallorca,
28 y -29IEEE
de mayo
IEEE. Std. 830
IEEE Std. 1058.1

IEEE Std. 983
Def.Requerim.
Plan Gestin Proyect.
RRS
Documentacin
de las actividades
Especif.Requer.
Descrip.Diseo
Diseo Lgico IEEE. Std. 1016

RCD
Implement. IEEE. Std. 1016
Docum.Sistema
Integracin
RIS
Plan de Verificacin
C j
IEEE. Std. 1012
IEEE. Std. 1008
RIHS
Validacin
RVS
Plan de Validacin
Revisiones
Documentacin
de las actividades
Docum.Soft.
IEEE. Std. 1028

Plan Control Config.
IEEE. Std. 1012
Inf.Validacin
Liberacin
Inf.Liberacin
RLS
Oper.& Mant.
Inf.Deficiencias
Modificacin
IEEE. Std. 828

IEEE. Std. 1042
J. L. Roca
58
IEEE SOFTWARE ENG. STDS
Modelo
de Cascada
Std. de 1999
Palma de
Mallorca,
28 y -29IEEE
de mayo
IEEE Std. 1058.1
IEEE Std. 983
IEEE Std. 830
IEEE Std. 1028
C
IEEE Std. 828

j
IEEE
Std. 1042
IEEE Std. 1016
IEEE Std. 1012
IEEE Std. 1008
IEEE Std. 1012
Pautas para la Gestin de

Proyectos de Software
Pautas para la Documentacin de
los Requerimientos del Software
Pautas para las Revisiones
Tcnicas del Software
Pautas para la Gestin de la
Configuracin del Software
Pautas para la
Implementacin del Software
Pautas para la Verificacin
y Validacin del Software
Pautas para la Documentacin
de Validacin del Software
J. L. Roca
59
Conclusiones
Palma de Mallorca,
28 y 29 de mayo de 1999
Obtener softwares cada vez ms confiables y
seguros es necesario tanto desde el punto de
vista prctico como tico.
Los objetivos solo pueden alcanzarse mediante la
aplicacin sistemtica de herramientas a veces
poco conocidas. La divulgacin de este paquete de
conocimiento debe comenzar desde los primeros
C j
pasos de la enseanza universitaria y propagarse a
cada emprendimiento que en materia de software
se comience.
Mejores softwares, menos complejos y ms
portables
podrn obtener mejores resultados
aplicativos.
J. L. Roca
60
Actitud28
Creativa
Palma de Mallorca,
No nos atrevemos a muchas

cosas porque son difciles, pero
son difciles porque no nos
atrevemos a hacerlas.
Sneca
J. L. Roca
61
Las
HERRAMIENTAS
estn slo hay que
UTILIZARLAS
J. L. Roca

Confiabilidad de Software

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Confiabilidad de Software

Загружено:

Авторское право:

Доступные форматы

Palma de Mallorca, 28 y 29 de mayo de 1999

Palma de Mallorca, 28 y 29 de mayo de 1999

Esfuerzo de Desarrollo de Software 80%.

Actualmente el Control estadstico de procesos:

Un sistema totalmente Seguro nunca funcionar.

Relacin Costos Hardware-Software

% del Costo Total

La Calidad es una medida de la

Es posible hablar de Calidad, expresada sta como

Los errores, no as las fallas, sern

Se dice que un Software es

Proporcin de Errores de un Software durante su Ciclo de Desarrollo

Fuentes de diversos tipos aseveran que, es en el

Hemos observado nueve categoras en las que se

Aproximadamente el 76% de los errores no son

El costo de deteccin y correccin de errores

Estudios realizados concluyen que el medio

Teniendo un 72% de errores generados en el

Es mucho ms costoso encontrar, corregir y

La Falla aparece cuando

Ignorancia de los requerimientos del usuario.

Diagnstico del error

Correccin del error

Errores Previos Fijos: Persisten en el

Errores Generados: No existan en el

Errores de complementacin aritmtica

La complejidad de un programa de computacin es

Esta demostrado que bajando la complejidad de un

Algunas son mas utilizadas que otras por su

V(G) = e-n+2.p = 119+2.1

V(G) = # de reas en que deda dividido el plano

Longitud del programa : N=N1+N2

Volumen del programa : V=(N1+N2).log2 (

Volumen potencial del programa : V*=(2+n).log2 (2+n)

Tiempo hasta prxima Falla

Decisin: Sistema listo para la Liberacin

Adicin de nuevas posibilidades-Mejora de algoritmos

MEDIDA DE EXACTITUD (CORRECTNESS)

TIEMPO ENTRE FALLAS

DOMINIO DE LAS ENTRADAS

MEDIDA DE EXACTITUD (CORRECTNESS)

z (ti ) = Tasa de fallas del periodo de tiempo ti de debugging.

C(ti ) = exp.[ - .(N-i+1).ti ]

C(ti ) = exp.[ - .(N-i+1).ti ]

Existen tcnicas de programacin simples:

1.Modelo de Cascada (Radice - 1985)

CMM -de5 Mallorca,

IEEE Std. 1058.1

Plan Gestin Proyect.

Diseo Lgico IEEE. Std. 1016

Implement. IEEE. Std. 1016

IEEE. Std. 1028

IEEE. Std. 1012

IEEE. Std. 828

IEEE SOFTWARE ENG. STDS

IEEE Std. 828

Pautas para la Gestin de

No nos atrevemos a muchas

Palma de Mallorca, 28 y 29 de mayo de 1999

Вам также может понравиться