creciendo. ➢ Pocos utilizan las Herramientas propuestas por la denominada
Ingeniería del Software para mejorar la calidad y confiabilidad de un programa.
Palma de Mallorca, 28 y 29 de mayo de 1999
C
1
j
La Confiabilidad en el Software
J. L. Roca
Palma de Mallorca, 28 y 29 de mayo de 1999
2
1.Introducción 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.Obtención de Softwares Confiables 8.Metodologías de Trabajo 9.Herramientas 10.Conclusiones
La Confiabilidad en el Software
J. L. Roca
Introducción Palma de Mallorca, 28 y 29 de mayo de 1999
3
Esfuerzo de Desarrollo de Software 80%. Esfuerzo de Desarrollo de Hardware 20%. Hace tres décadas esta relación era inversa. Se utilizaban para el Hardware técnicas 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).
La Confiabilidad en el Software
J. L. Roca
Introducción Palma de Mallorca, 28 y 29 de mayo de 1999
4
Actualmente el Control estadístico de procesos: SQC (Statistics Quality Control) TQM (Total Quality Management) Desde hace una década la importancia del software a la hora de diseñar un sistema fue creciendo. C j Pocos utilizan las Herramientas propuestas por la denominada Ingeniería del Software para mejorar la calidad y confiabilidad de un programa. Debe hacerse un balance entre Disponibilidad (Availability) y Seguridad (Safety).
La Confiabilidad en el Software
J. L. Roca
Introducción Palma de Mallorca, 28 y 29 de mayo de 1999
5
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 misión C j espacial. O puede implicar vidas humanas cuando la aplicación es electromédica. Esta es la importancia que día a día esta teniendo el Software en un sistema.
La Confiabilidad en el Software
J. L. Roca
Introducción Palma de Mallorca, 28 y 29 de mayo de 1999
6
Relación Costos Hardware-Software
% del Costo Total
100
Hardware
50 C
j
Software 0 1960
La Confiabilidad en el Software
1975
Año
2005 J. L. Roca
y Confiabilidad Palma de Calidad Mallorca, 28 y 29 de mayo de 1999
7
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 “proporción” la otra con la variable aleatoria “tiempo”. El Software no admite la misma discriminación. La Confiabilidad en el Software
J. L. Roca
Palma de Calidad Mallorca, 28 y 29 de mayo de 1999 y Confiabilidad
8
Es posible hablar de Calidad, expresada ésta como proporción de errores (Bugs) en el programa. Mientras la Confiabilidad está expresada en función de la tasa de fallas (Hazard Failure Rate). La mayoría 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 serán copia de éste, en cualquier sistema que corran.
La Confiabilidad en el Software
J. L. Roca
Palma de Calidad Mallorca, 28 y 29 de mayo de 1999 y Confiabilidad
9
Los errores, no así las fallas, serán siempre los mismos, no importa el entorno en el que corran. Por lo tanto, es mucho más correcto hablar de Confiabilidad de un Software que de la Calidad del mismo. C
j
La Confiabilidad en el Software
J. L. Roca
10
de yun29 Software PalmaLadeConfiabilidad Mallorca, 28 de mayo de 1999
C
j
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.
La Confiabilidad en el Software
J. L. Roca
11
de yun29 Software PalmaLadeConfiabilidad Mallorca, 28 de mayo de 1999
Proporción de Errores de un Software durante su Ciclo de Desarrollo
Codificación y Test Modular
Integración y Test
13%
10%
C
Operación y Mantenimiento
5%
j
17% Diseño La Confiabilidad en el Software
55% Análisis de Requerimientos J. L. Roca
12
de yun29 Software PalmaLadeConfiabilidad Mallorca, 28 de mayo de 1999 El 72% de los errores se originan en: “el traslado de los requerimientos del usuario y en el diseño lógico”. 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 diseño, en donde debe ponerse énfasis para reducir la proporción de errores.
La Confiabilidad en el Software
J. L. Roca
13
de yun29 Software PalmaLadeConfiabilidad Mallorca, 28 de mayo de 1999 Proporción de Errores de un Software por Áreas de Conflicto Cómputo Humano 5% Entorno 5% C j
Documentación
5% 2%
Interfase 6% Datos 6% Otros 7%
Traslado de Requerimientos
36%
28% Diseño Lógico
La Confiabilidad en el Software
J. L. Roca
14
de yun29 Software PalmaLadeConfiabilidad Mallorca, 28 de mayo de 1999
Hemos observado nueve categorías en las que se divide la generación de errores. La experiencia demuestra que: C
j
Aproximadamente el 76% de los errores no son descubiertos hasta bien entrada la etapa de pruebas integrales.
La Confiabilidad en el Software
J. L. Roca
15
de yun29 Software PalmaLadeConfiabilidad Mallorca, 28 de mayo de 1999 Costos de Corrección de Errores de un Software
16 14
12 10 8 6
C
j
4 2
Tiempo
0 Requerimientos
Diseño
La Confiabilidad en el Software
Codificación Test
Operación J. L. Roca
16
de yun29 Software PalmaLadeConfiabilidad Mallorca, 28 de mayo de 1999
El costo de detección y corrección de errores durante y después de las etapas de integración y test resultan entre 10 y 15 veces más que en las etapas de desarrollo y codificación. 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 “Técnico”
La Confiabilidad en el Software
J. L. Roca
17
Errores y Fallas un Software Palma de Mallorca, 28de y 29 de mayo de 1999 Históricamente, 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 diseñada en el producto. La Confiabilidad en el Software
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 más efectivo resolver los errores en la misma fase de diseño que en la de prueba. Cada vez que se corrige un error se generan nuevos con una cierta probabilidad.
La Confiabilidad en el Software
J. L. Roca
19
Errores y Fallas un Software Palma de Mallorca, 28de y 29 de mayo de 1999
Es mucho más costoso encontrar, corregir y documentar errores en los últimos peldaños del ciclo de vida que al comienzo. Es necesario utilizar Herramientas, que en base a C j modelos ayuden a determinar parámetros que sirvan de análisis. Las Herramientas son provistas por la asi llamada Ingeniería de Software
La Confiabilidad en el Software
J. L. Roca
20
Falla28 unySoftware? Palma de¿Porqué Mallorca, 29 de mayo de 1999 ENTRADAS Ei
E
Esquema de un programa
E = {Ei/i = 1,2,....N} N = # de entradas posibles
C
j
PROGRAMA
F(Ei) SALIDAS La Confiabilidad en el Software
F
S
F(Ei) ^ F(Ei)
F(Ei)
Real Estimada ^ F(Ei)
FALLA J. L. Roca
21
Falla28 unySoftware? Palma de¿Porqué Mallorca, 29 de mayo de 1999 Un programa establece una correspondencia entre entradas y salidas vía una determinada función estimada o propuesta La diferencia entre esta función 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 interactúan con un determinado error en la programación y por lo tanto generan salidas no esperadas (fallas). La Confiabilidad en el Software
J. L. Roca
22
Falla28 unySoftware? Palma de¿Porqué Mallorca, 29 de mayo de 1999 Esquema de un programa
{E1} C
j
{E2}
E = {Ei/i = 1,2,....N} N = # de entradas posibles
Error
La Falla aparece cuando el conjunto de Entradas Interactúa con el Error La FALLA se Auto expone
La Confiabilidad en el Software
J. L. Roca
23
Falla28 unySoftware? Palma de¿Porqué Mallorca, 29 de mayo de 1999
C
j
Ignorancia de los requerimientos del usuario. Ignorancia del entorno en que se utiliza el Software. Escaso flujo de información entre usuario y programador Escasa documentación del Software.
ERRORES (BUGS)
La Confiabilidad en el Software
FALLAS (FAULTS)
J. L. Roca
24
PalmaEspecificación de Mallorca,de28losy Requerimientos 29 de mayo de 1999
No Ambigua
Completa
C
j
Características de Una Especificación de Requerimientos de un software ERS
Verificable Consistente Modificable
Trazable Utilizable
La Confiabilidad en el Software
J. L. Roca
25
de Depuración Debugging PalmaProceso de Mallorca, 28 y 29o de mayo de 1999 Identificación del Problema
Diagnóstico del error
C
j
Corrección del error Prueba de la corrección del error Reinicio del programa
La Confiabilidad en el Software
J. L. Roca
26
Definición28 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 código (Debugging). C
j
Errores Generados: No existían en el Software, hasta que son introducidos como consecuencia del Debugging.
La Confiabilidad en el Software
J. L. Roca
27
Errores Palma de Mallorca, 28Clásicos 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
j
Errores de complementación aritmética Problemas de puntero Errores de transferencia de control Problemas de direccionamiento indirecto Problema de reinicio del programa
La Confiabilidad en el Software
J. L. Roca
28
y Complejidad Palma deConfiabilidad Mallorca, 28 y 29 de mayo de 1999
La complejidad de un programa de computación es una medida de la dificultad para llevar a cabo esa computación y está muy relacionada con su confiabilidad. Es evidente que cuanto mas complejo sea el algoritmo de cómputo tanto mas probabilidad existe de que se cometan errores en su programación y por lo tanto de fallas del software y deterioro de su confiabilidad. C
j
La Confiabilidad en el Software
J. L. Roca
29
y Complejidad Palma deConfiabilidad Mallorca, 28 y 29 de mayo de 1999
Esta demostrado que bajando la complejidad de un software su confiabilidad mejora. Existen diversas teorías que permiten evaluar la complejidad del software. C
j
Algunas son mas utilizadas que otras por su sencillez, sin embargo son dos las principales: La complejidad McCabe y la Complejidad Halstead.
La Confiabilidad en el Software
J. L. Roca
30
Complejidad Palma de Mallorca, 28McCabe y 29 de mayo de 1999
I
III C
j
I I
I V
V(G) = e-n+2.p = 11–9+2.1
=4
V(G) = # de áreas en que deda dividido el plano V(G) = # de desiciones + 1 La Confiabilidad en el Software
J. L. Roca
31
Complejidad28 Halstead Palma de Mallorca, y 29 de mayo de 1999
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) Número de operandos de entrada-salida necesarios para el Cprograma j : n = 2. Relación de volúmenes : L=V*/V Esfuerzo de programación : E=V/L=V2/V* Número de errores : B=V/S*=V/3000
La Confiabilidad en el Software
J. L. Roca
32
Ley de28 Zipf Palma de Mallorca, y 29 de mayo de 1999 Teoría del Lenguaje Natural Operadores Operandos
Verbos Nombres
Símbolos C j
Palabras
Expresión
Frase
Programa
Libro
Módulo
Párrafo
La Confiabilidad en el Software
Chomsky
Tipos de Instrucciones
Calculado
Real
Tipos Distintos
t
n=t.(0,5772+ln t)
n
Operadores
12
36,7
31
Operandos
9
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 análisis 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. La Confiabilidad en el Software
J. L. Roca
34
Diagrama Operativo Modelos Palma de Mallorca, 28 yUtilizando 29 de mayo de 1999 Datos Modelo Apropiado Estimación Parámetros Selección otro Modelo C
j
Alimentación Modelo
Rechazo
Prueba de Ajuste Aprobación Estimación Perfomance
Errores No Detectados
Tiempo hasta próxima Falla
Confiabilidad
Decisión: Sistema listo para la Liberación La Confiabilidad en el Software
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 (Determinístico) MUSA (Determinístico) C
j
SHOOMAN (Determinístico)
POISSON (Determinístico) SHICK-WOLVERTON (Determinístico) TRIVEDI-SHOOMAN (Markoviano) INPUT DOMAIN BASED (Estocástico) LITTLEWOOD-VERRAL (Bayesiano)
La Confiabilidad en el Software
J. L. Roca
36
de Acuerdo Ciclo Vidade 1999 PalmaModelos de Mallorca, 28 yal29 de de mayo FASE VALIDACIÓN El software no se corrige-Se aprueba o rechaza (Softwares para aplicaciones críticas)
NELSON SHOOMAN PATH RELIABILITY INPUT DOMAIN BASED MODEL C
j
FASE OPERACIONAL Validación continua-Entradas al software dependientes (Softwares para control de Procesos) INPUT DOMAIN BASED MODEL MARKOV PROCESS -LITTLEWOOD - CHENG
La Confiabilidad en el Software
J. L. Roca
37
de Acuerdo Ciclo Vidade 1999 PalmaModelos de Mallorca, 28 yal29 de de mayo
FASE MANTENIMIENTO C
j
Adición de nuevas posibilidades-Mejora de algoritmos (Existen pocos modelos) INPUT DOMAIN BASED MODEL
La Confiabilidad en el Software
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 (Softwares para aplicaciones críticas) SIEMBRA DE ERRORES: BASIN,MILL,DE MILLO-LIPTON C
j
FENOMENOLOGICOS: HALSTEAD
ESTADISTICOS: NELSON,EHRENBERGER,BROWN-LIPOW INPUT DOMAIN BASED MODEL
La Confiabilidad en el Software
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
j
LITTLEWOOD-VERRAL-BAYESIANO
SIEMBRA DE ERRORES Se estudia la reacción ante la introducción forzada de errores MILLS
La Confiabilidad en el Software
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 número de fallas detectadas
GOEL-OKUMOTO-POISSON NO HOMOGENEO GOEL-POISSON NO HOMOGENEO GENERALIZADO C
j
MUSA-TIEMPO DE EJECUCIÓN SHOOMAN-EXPONENCIAL POISSON GENERALIZADO IBM-BINOMIAL-POISSON MUSA-OKUMOTO-POISSON LOGARITMICO
La Confiabilidad en el Software
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 reacción ante la variabilidad de las entradas C j NELSON RAMAMOORTHY-BASTANI
La Confiabilidad en el Software
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 (Softwares para aplicaciones críticas) C jSIEMBRA DE ERRORES: BASIN,MILL,DEMILLO-LIPTON FENOMENOLOGICOS: HALSTEAD ESTADISTICOS: NELSON,EHRENBERGER, BROWN-LIPOW INPUT DOMAIN BASED MODEL
La Confiabilidad en el Software
J. L. Roca
43
de Acuerdo a Estructura Palma Modelos de Mallorca, 28 y 29 de mayo de 1999
C
j
MACROMODELOS Se estudia el software como una caja negra JELINSKI-MORANDA GOEL-OKUMOTO SCHICK-WOLVERTON LITTLEWOOD-VERRAL SHOOMAN MUSA NELSON MILLS
La Confiabilidad en el Software
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
C
j
MODELOS DE DISPONIBILIDAD Se estudia el proceso del mantenimiento del software SHOOMAN-TRIVEDI
La Confiabilidad en el Software
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 reparación del software ). = CConstante de proporcionalidad. j N = Número total de errores del software. i = Número de errores encontrados y removidos después del periodo de tiempo ti de debugging.
La Confiabilidad en el Software
J. L. Roca
46
Macromodelo JELINSKI-MORANDA Palma de Mallorca, 28 y 29 de mayo(2) de 1999
C
j
N N-1
N-2
N-3
N-4
0 0
0
0
0
t1
z (ti ) =
t2 .(N-i+1)
La Confiabilidad en el Software
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
j
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
La Confiabilidad en el Software
J. L. Roca
48
Macromodelo JELINSKI-MORANDA Palma de Mallorca, 28 y 29 de mayo(4) de 1999
n i=1 C
n
[1/(N-i+1)] =
j
= n / [N.
n
i=1 n
ti -
i=1
La Confiabilidad en el Software
.
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
C
j
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
La Confiabilidad en el Software
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 )
1
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
La Confiabilidad en el Software
200
ti
0
250
0
50
100
150
200
ti
250
J. L. Roca
51
de Softwares Confiables Palma Obtención de Mallorca, 28 y 29 de mayo de 1999
C j
Existen técnicas de programación simples: ESTRUCTURACIÓN MODULARIZACIÓN KISS Técnicas de programación complejas: N-VERSIONES DE UN PROGRAMA BLOQUES RECUPERABLES
La Confiabilidad en el Software
J. L. Roca
52
Metodologías 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 Prevención de Defectos (Jones - 1990) 8.Modelo de Capacidad de Maduración (Humphrey -1989) 9.Modelo de Productividad (Jones - 1986) 10.Modelo Malcom Baldrige (DOC - 1988) 11. Modelo ISO 9000-3 (ISO - 1995)
La Confiabilidad en el Software
J. L. Roca
53
: Total Quality Management Palma TQM de Mallorca, 28 y 29 de mayo de 1999 Procedimientos y Métodos
C
j
PROCESO
Personal-Motivación Entrenamiento
Herramientas y Equipos La Confiabilidad en el Software
J. L. Roca
54
Planeamiento de la Calidad
C
j
Costo de la No Calidad
Trilogía 28 de y JURAN Palma de Mallorca, 29 de mayo de 1999
Control de la Calidad Zona Original de CC
Pérdida Crónica
Nueva Zona de CC Mejora de la Calidad Tiempo
Experiencia Ganada La Confiabilidad en el Software
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
j
Proyecto B Sistema
Proyecto C TQM
Hardware Software
CMM
Organización La Confiabilidad en el Software
J. L. Roca
56
CMM -de5 Mallorca, Niveles del28 Proceso de Maduración Palma y 29 de mayo de 1999 Mejorado Continuamente
Predecible Estandarizado C
j
Disciplinado
#1
#2
#3
#4
#5
Optimizado
Gestionado
Definido
Repetible
Inicial
La Confiabilidad en el Software
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 Gestión Proyect.
RRS
Documentación de las actividades Especif.Requer. Descrip.Diseño
Diseño Lógico IEEE. Std. 1016 RCD
Implement. IEEE. Std. 1016
Docum.Sistema
Integración
RIS Plan de Verificación C j IEEE. Std. 1012 IEEE. Std. 1008
RIHS
Validación RVS
Plan de Validación Revisiones Documentación de las actividades
Docum.Soft.
IEEE. Std. 1028 Plan Control Config.
IEEE. Std. 1012
Inf.Validación
Liberación
Inf.Liberación
RLS
Oper.& Mant.
Inf.Deficiencias
Modificación
IEEE. Std. 828 IEEE. Std. 1042
La Confiabilidad en el Software
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
La Confiabilidad en el Software
Pautas para la Gestión de Proyectos de Software Pautas para la Documentación de los Requerimientos del Software Pautas para las Revisiones Técnicas del Software Pautas para la Gestión de la Configuración del Software Pautas para la Implementación del Software Pautas para la Verificación y Validación del Software Pautas para la Documentación de Validación del Software J. L. Roca
59
Conclusiones Palma de Mallorca, 28 y 29 de mayo de 1999 Obtener softwares cada vez más confiables y seguros es necesario tanto desde el punto de vista práctico como ético. Los objetivos solo pueden alcanzarse mediante la aplicación sistemática de herramientas a veces poco conocidas. La divulgación de este paquete de conocimiento debe comenzar desde los primeros C j pasos de la enseñanza universitaria y propagarse a cada emprendimiento que en materia de software se comience. Mejores softwares, menos complejos y más portables podrán obtener mejores resultados aplicativos. La Confiabilidad en el Software
J. L. Roca
60
Actitud28 Creativa Palma de Mallorca, y 29 de mayo de 1999
C
j
No nos atrevemos a muchas cosas porque son difíciles, pero son difíciles porque no nos atrevemos a hacerlas.
Séneca
La Confiabilidad en el Software
J. L. Roca
61
Palma de Mallorca, 28 y 29 de mayo de 1999
C
j
Las HERRAMIENTAS están sólo hay que UTILIZARLAS
La Confiabilidad en el Software
J. L. Roca