Sin título de diapositiva - IEEEieee.eie.fceia.unr.edu.ar/PDF_SOFTWARE.pdf · Palma de Mallorca,...
Transcript of Sin título de diapositiva - IEEEieee.eie.fceia.unr.edu.ar/PDF_SOFTWARE.pdf · Palma de Mallorca,...
Palma de Mallorca, 28 y 29 de mayo de 19991
C j
J. L. RocaLa Confiabilidad en el Software
Palma de Mallorca, 28 y 29 de mayo de 19992
C j
J. L. RocaLa Confiabilidad en el Software
1.Introducción2.Calidad y Confiabilidad3.La Confiabilidad de un Software4.Errores y Fallas5.Confiabilidad y Complejidad 6.Modelos de Confiabilidad7.Obtención de Softwares Confiables8.Metodologías de Trabajo9.Herramientas10.Conclusiones
Palma de Mallorca, 28 y 29 de mayo de 19993
C j
J. L. RocaLa Confiabilidad en el Software
Introducción
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 deControl de Calidad por atributos o por variablescomo ser:AOQL (Average Outgoing Quality Level) a lasalida.AQL (Acceptable Quality Level) a la entrada.LPTD (Low Total Percentage Defects).
Palma de Mallorca, 28 y 29 de mayo de 19994
C j
J. L. RocaLa Confiabilidad en el Software
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 fuecreciendo.
Pocos utilizan las Herramientas propuestas por ladenominada Ingeniería del Software para mejorarla calidad y confiabilidad de un programa.
Debe hacerse un balance entre Disponibilidad(Availability) y Seguridad (Safety).
Introducción
Palma de Mallorca, 28 y 29 de mayo de 19995
C j
J. L. RocaLa Confiabilidad en el Software
Un sistema totalmente Seguro nunca funcionará.
Un sistema siempre Disponible nunca serátotalmente seguro.
Un “Bug” (error) en un software puede provocaruna falla (fault) que termine con una misiónespacial.
O puede implicar vidas humanas cuando laaplicación es electromédica.
Esta es la importancia que día a día esta teniendoel Software en un sistema.
Introducción
Palma de Mallorca, 28 y 29 de mayo de 19996
C j
J. L. RocaLa Confiabilidad en el Software
Relación Costos Hardware-Software100
50
0
Hardware
Software
% d
el Cos
toTot
al
1960 1975 2005Año
Introducción
Palma de Mallorca, 28 y 29 de mayo de 19997
C j
J. L. RocaLa Confiabilidad en el Software
Calidad y Confiabilidad
La Calidad es una medida de laperformance de un elemento en unpunto determinado del tiempo,presumiblemente t=0.
La Confiabilidad es una medida deperformance a lo largo del tiempo.
Una está relacionada con la variablealeatoria “proporción” la otra con lavariable aleatoria “tiempo”.
El Software no admite la mismadiscriminación.
Palma de Mallorca, 28 y 29 de mayo de 19998
C j
J. L. RocaLa Confiabilidad en el Software
Es posible hablar de Calidad, expresada ésta comoproporción de errores (Bugs) en el programa.
Mientras la Confiabilidad está expresada enfunción de la tasa de fallas (Hazard Failure Rate).
La mayoría de los especialistas hablan de Calidad yConfiabilidad en forma indistinta.
Lo cierto es que un Software no puede producirseen serie varias veces.
Una vez desarrollado, probado y liberado, todoslos Softwares serán copia de éste, en cualquiersistema que corran.
Calidad y Confiabilidad
Palma de Mallorca, 28 y 29 de mayo de 19999
C j
J. L. RocaLa Confiabilidad en el Software
Los errores, no así las fallas, seránsiempre los mismos, no importa elentorno en el que corran.
Por lo tanto, es mucho más correctohablar de Confiabilidad de unSoftware que de la Calidad delmismo.
Calidad y Confiabilidad
Palma de Mallorca, 28 y 29 de mayo de 199910
C j
J. L. RocaLa Confiabilidad en el Software
La Confiabilidad de un Software
Se dice que un Software esconfiable si realiza lo que el usuariodesea, 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 laConfiabilidad del Software.
Palma de Mallorca, 28 y 29 de mayo de 199911
C j
J. L. RocaLa Confiabilidad en el Software
55%
Análisis de Requerimientos
17%
Diseño
Operación y Mantenimiento
5%
Integración y Test
10%
Codificación y Test Modular
13%
Proporción de Errores de un Software durante su Ciclo de Desarrollo
La Confiabilidad de un Software
Palma de Mallorca, 28 y 29 de mayo de 199912
C j
J. L. RocaLa Confiabilidad en el Software
El 72% de los errores se originan en: “eltraslado de los requerimientos del usuario y enel diseño lógico”.
Podremos aumentar la Confiabilidad de unSoftware haciendo hincapié en estas dosprimeras etapas.
Fuentes de diversos tipos aseveran que, es en eldiseño, en donde debe ponerse énfasis parareducir la proporción de errores.
La Confiabilidad de un Software
Palma de Mallorca, 28 y 29 de mayo de 199913
C j
J. L. RocaLa Confiabilidad en el Software
Traslado de Requerimientos
36%
28%
Diseño Lógico
Otros 7%
Datos 6%
Interfase 6%
Documentación
2%
Cómputo
5%Humano 5%
Entorno 5%
Proporción de Errores de un Software por Áreas de Conflicto
La Confiabilidad de un Software
Palma de Mallorca, 28 y 29 de mayo de 199914
C j
J. L. RocaLa Confiabilidad en el Software
Hemos observado nueve categorías en las que sedivide la generación de errores.
La experiencia demuestra que:
Aproximadamente el 76% de los errores no sondescubiertos hasta bien entrada la etapa depruebas integrales.
La Confiabilidad de un Software
Palma de Mallorca, 28 y 29 de mayo de 199915
C j
J. L. RocaLa Confiabilidad en el Software
16
14
12
10
8
6
4
2
0
Requerimientos Diseño Codificación Test Operación
Tiempo
Costos de Corrección de Errores de un Software
La Confiabilidad de un Software
Palma de Mallorca, 28 y 29 de mayo de 199916
C j
J. L. RocaLa Confiabilidad en el Software
El costo de detección y corrección de erroresdurante y después de las etapas de integracióny test resultan entre 10 y 15 veces más que enlas etapas de desarrollo y codificación.
Estudios realizados concluyen que el medioambiente en el que se desarrolla el Softwarecontribuye enormemente al aumento de errores.
La Confiabilidad del Software pasa a ser unproblema de “Management” y no “Técnico”
La Confiabilidad de un Software
Palma de Mallorca, 28 y 29 de mayo de 199917
C j
J. L. RocaLa Confiabilidad en el Software
Históricamente, una forma deaumentar la Confiabilidad de unSoftware era correrlo y probarloextensivamente antes de liberarlo.
No es efectivo probar la Confiabilidaden el producto sino hacerla, es decirfabricarla en el mismo.
La Confiabilidad deberá ser diseñadaen el producto.
Errores y Fallas de un Software
Palma de Mallorca, 28 y 29 de mayo de 199918
C j
J. L. RocaLa Confiabilidad en el Software
Teniendo un 72% de errores generados en eltraslado de los requerimientos del usuario, elénfasis debe ser puesto en ese punto.
Es mucho más efectivo resolver los errores en lamisma fase de diseño que en la de prueba.
Cada vez que se corrige un error se generan nuevoscon una cierta probabilidad.
Errores y Fallas de un Software
Palma de Mallorca, 28 y 29 de mayo de 199919
C j
J. L. RocaLa Confiabilidad en el Software
Es mucho más costoso encontrar, corregir ydocumentar errores en los últimos peldaños del ciclode vida que al comienzo.
Es necesario utilizar Herramientas, que en base amodelos ayuden a determinar parámetros que sirvande análisis.
Las Herramientas son provistas por la asi llamadaIngeniería de Software
Errores y Fallas de un Software
Palma de Mallorca, 28 y 29 de mayo de 199920
C j
J. L. RocaLa Confiabilidad en el Software
E
F
S
PROGRAMA
ENTRADAS
SALIDAS
F(Ei)
EiE = {Ei/i = 1,2,....N}
N = # de entradas posibles
F(Ei) Real
F(Ei) Estimada^
F(Ei) F(Ei)^
FALLA
Esquema de un programa
¿Porqué Falla un Software?
Palma de Mallorca, 28 y 29 de mayo de 199921
C j
J. L. RocaLa Confiabilidad en el Software
¿Porqué Falla un Software?
Un programa establece una correspondencia entreentradas y salidas vía una determinada funciónestimada o propuesta
La diferencia entre esta función y la real ejecutadapor el programa para un conjunto determinado dedatos de entrada, es lo que da origen a la falla.
Son las entradas las que interactúan con undeterminado error en la programación y por lo tantogeneran salidas no esperadas (fallas).
Palma de Mallorca, 28 y 29 de mayo de 199922
C j
J. L. RocaLa Confiabilidad en el Software
¿Porqué Falla un Software?
Esquema de un programa
E = {Ei/i = 1,2,....N}
N = # de entradas posibles
La Falla aparece cuando el conjunto de Entradas Interactúa con el Error
Error
La FALLA se Auto expone
{E1}
{E2}
Palma de Mallorca, 28 y 29 de mayo de 199923
C j
J. L. RocaLa Confiabilidad en el Software
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) FALLAS (FAULTS)
¿Porqué Falla un Software?
Palma de Mallorca, 28 y 29 de mayo de 199924
C j
J. L. RocaLa Confiabilidad en el Software
Especificación de los Requerimientos
No Ambigua
Completa
Verificable
Consistente
Modificable
Trazable
Utilizable
Características de Una Especificación de Requerimientos de un software
ERS
Palma de Mallorca, 28 y 29 de mayo de 199925
C j
J. L. RocaLa Confiabilidad en el Software
Identificación del Problema
Diagnóstico del error
Corrección del error
Prueba de la corrección del error
Reinicio del programa
Proceso de Depuración o Debugging
Palma de Mallorca, 28 y 29 de mayo de 199926
C j
J. L. RocaLa Confiabilidad en el Software
Errores Previos Fijos: Persisten en elSoftware luego de que el programador hatrabajado en él corrigiendo un error ocambiando un código (Debugging).
Errores Generados: No existían en elSoftware, hasta que son introducidos comoconsecuencia del Debugging.
Definición de Errores
Palma de Mallorca, 28 y 29 de mayo de 199927
C j
J. L. RocaLa Confiabilidad en el Software
Matrices sobre grabadas
Errores en los bits de bandera
Errores en los bits de indexado
Errores en los bits de desplazamiento
Errores de complementación aritmética
Problemas de puntero
Errores de transferencia de control
Problemas de direccionamiento indirecto
Problema de reinicio del programa
Errores Clásicos
Palma de Mallorca, 28 y 29 de mayo de 199928
C j
J. L. RocaLa Confiabilidad en el Software
La complejidad de un programa de computación esuna medida de la dificultad para llevar a cabo esacomputación y está muy relacionada con suconfiabilidad.
Es evidente que cuanto mas complejo sea elalgoritmo de cómputo tanto mas probabilidad existede que se cometan errores en su programación y porlo tanto de fallas del software y deterioro de suconfiabilidad.
Confiabilidad y Complejidad
Palma de Mallorca, 28 y 29 de mayo de 199929
C j
J. L. RocaLa Confiabilidad en el Software
Esta demostrado que bajando la complejidad de un software su confiabilidad mejora.
Existen diversas teorías que permiten evaluar la complejidad del software.
Algunas son mas utilizadas que otras por su sencillez, sin embargo son dos las principales:
La complejidad McCabe y la Complejidad Halstead.
Confiabilidad y Complejidad
Palma de Mallorca, 28 y 29 de mayo de 199930
C j
J. L. RocaLa Confiabilidad en el Software
V(G) = e-n+2.p = 11–9+2.1 = 4
I
II
III
IV
V(G) = # de áreas en que deda dividido el plano
V(G) = # de desiciones + 1
Complejidad McCabe
Palma de Mallorca, 28 y 29 de mayo de 199931
C j
J. L. RocaLa Confiabilidad en el Software
Complejidad Halstead
Longitud del programa : N=N1+N2
Vocabulario utilizado en el programa : = 1+ 2
Volumen del programa : V=(N1+N2).log2 ( 1+ 2)=N.log2
Volumen potencial del programa : V*=(2+n).log2 (2+n)
Número de operandos de entrada-salida necesarios para el programa : 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
Palma de Mallorca, 28 y 29 de mayo de 199932
C j
J. L. RocaLa Confiabilidad en el Software
Ley de Zipf
Teoría del Lenguaje Natural Chomsky
Operadores Verbos
Operandos Nombres
Símbolos Palabras
Expresión Frase
Programa Libro
Módulo Párrafo
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
Palma de Mallorca, 28 y 29 de mayo de 199933
C j
J. L. RocaLa Confiabilidad en el Software
Existen tres clasificaciones importantes de los modelos utilizados en el análisis de Confiabilidad de un Software:
Modelos de acuerdo al
Ciclo de Vida.
Modelos de acuerdo a la
Naturaleza del Proceso de Falla.
Modelos de acuerdo a
Consideraciones Estructurales.
Modelos de Confiabilidad de un Software
Palma de Mallorca, 28 y 29 de mayo de 199934
C j
J. L. RocaLa Confiabilidad en el Software
Diagrama Operativo Utilizando Modelos
Datos
Modelo Apropiado
Estimación Parámetros
Alimentación ModeloSelección otro Modelo
Prueba de AjusteRechazo
Tiempo hasta próxima FallaErrores No Detectados
Estimación Perfomance
Confiabilidad
Decisión: Sistema listo para la Liberación
Aprobación
Palma de Mallorca, 28 y 29 de mayo de 199935
C j
J. L. RocaLa Confiabilidad en el Software
Modelos de Acuerdo al Ciclo de Vida
FASE DESARROLLOEl 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)
SHOOMAN (Determinístico)
POISSON (Determinístico)
SHICK-WOLVERTON (Determinístico)
TRIVEDI-SHOOMAN (Markoviano)
INPUT DOMAIN BASED (Estocástico)
LITTLEWOOD-VERRAL (Bayesiano)
Palma de Mallorca, 28 y 29 de mayo de 199936
C j
J. L. RocaLa Confiabilidad en el Software
FASE VALIDACIÓNEl software no se corrige-Se aprueba o rechaza
(Softwares para aplicaciones críticas)
NELSONSHOOMAN PATH RELIABILITYINPUT DOMAIN BASED MODEL
FASE OPERACIONALValidación continua-Entradas al software
dependientes
(Softwares para control de Procesos)
INPUT DOMAIN BASED MODELMARKOV PROCESS -LITTLEWOOD - CHENG
Modelos de Acuerdo al Ciclo de Vida
Palma de Mallorca, 28 y 29 de mayo de 199937
C j
J. L. RocaLa Confiabilidad en el Software
FASE MANTENIMIENTOAdición de nuevas posibilidades-Mejora de algoritmos
(Existen pocos modelos)
INPUT DOMAIN BASED MODEL
Modelos de Acuerdo al Ciclo de Vida
Palma de Mallorca, 28 y 29 de mayo de 199938
C j
J. L. RocaLa Confiabilidad en el Software
MEDIDA DE EXACTITUD (CORRECTNESS)Medida de la confianza en el test
(Softwares para aplicaciones críticas)
SIEMBRA DE ERRORES: BASIN,MILL,DE MILLO-LIPTON
FENOMENOLOGICOS: HALSTEAD
ESTADISTICOS: NELSON,EHRENBERGER,BROWN-LIPOW
INPUT DOMAIN BASED MODEL
Modelos de Acuerdo al Ciclo de Vida
Palma de Mallorca, 28 y 29 de mayo de 199939
C j
J. L. RocaLa Confiabilidad en el Software
TIEMPO ENTRE FALLAS
Se estudia el tiempo entre fallas
JELINSKI-MORANDA DE-EUTROPHICATION
GOEL-OKUMOTO-IMPERFECTO DEBUGGING
SCHICK-WOLVERTON
LITTLEWOOD-VERRAL-BAYESIANO
SIEMBRA DE ERRORES
Se estudia la reacción ante la introducción forzada de errores
MILLS
Modelos de Acuerdo al Proceso de Falla
Palma de Mallorca, 28 y 29 de mayo de 199940
C j
J. L. RocaLa Confiabilidad en el Software
CONTEO DE FALLAS
Se estudia el número de fallas detectadas
GOEL-OKUMOTO-POISSON NO HOMOGENEO
GOEL-POISSON NO HOMOGENEO GENERALIZADO
MUSA-TIEMPO DE EJECUCIÓN
SHOOMAN-EXPONENCIAL
POISSON GENERALIZADO
IBM-BINOMIAL-POISSON
MUSA-OKUMOTO-POISSON LOGARITMICO
Modelos de Acuerdo al Proceso de Falla
Palma de Mallorca, 28 y 29 de mayo de 199941
C j
J. L. RocaLa Confiabilidad en el Software
DOMINIO DE LAS ENTRADAS
Se estudia la reacción ante la variabilidad de las entradas
NELSON
RAMAMOORTHY-BASTANI
Modelos de Acuerdo al Proceso de Falla
Palma de Mallorca, 28 y 29 de mayo de 199942
C j
J. L. RocaLa Confiabilidad en el Software
MEDIDA DE EXACTITUD (CORRECTNESS)
Medida de la confianza en el test
(Softwares para aplicaciones críticas)
SIEMBRA DE ERRORES: BASIN,MILL,DEMILLO-LIPTON
FENOMENOLOGICOS: HALSTEAD
ESTADISTICOS: NELSON,EHRENBERGER, BROWN-LIPOW
INPUT DOMAIN BASED MODEL
Modelos de Acuerdo al Proceso de Falla
Palma de Mallorca, 28 y 29 de mayo de 199943
C j
J. L. RocaLa Confiabilidad en el Software
MACROMODELOS
Se estudia el software como una caja negra
JELINSKI-MORANDA
GOEL-OKUMOTO
SCHICK-WOLVERTON
LITTLEWOOD-VERRAL
SHOOMAN
MUSA
NELSON
MILLS
Modelos de Acuerdo a Estructura
Palma de Mallorca, 28 y 29 de mayo de 199944
C j
J. L. RocaLa Confiabilidad en el Software
MICROMODELOS
Se estudia la estructura interna del software
SHOOMAN
MODELOS DE DISPONIBILIDAD
Se estudia el proceso del mantenimiento del software
SHOOMAN-TRIVEDI
Modelos de Acuerdo a Estructura
Palma de Mallorca, 28 y 29 de mayo de 199945
C j
J. L. RocaLa Confiabilidad en el Software
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 ).= Constante de proporcionalidad.
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.
z (ti ) = .(N-i+1)
Macromodelo JELINSKI-MORANDA (1)
Palma de Mallorca, 28 y 29 de mayo de 199946
C j
J. L. RocaLa Confiabilidad en el Software
z (ti ) = .(N-i+1)
tit1
0t2
0t3
0t4
0 0
N N-1 N-2 N-3 N-4
C(ti ) = exp.[ - .(N-i+1).ti ]
Macromodelo JELINSKI-MORANDA (2)
Palma de Mallorca, 28 y 29 de mayo de 199947
C j
J. L. RocaLa Confiabilidad en el Software
C(ti ) = exp.[ - .(N-i+1).ti ]
n n
L(N, ) = f (ti ) = [ .(N-i+1)].exp.[ - .(N-i+1).ti ]i=1 i=1
n
L(N, ) = ln.[L(N, )] = {ln.(N-i+1) + ln. - (N-i+1). .ti }i=1
L(N, )/ N = 0 L(N, )/ = 0
Macromodelo JELINSKI-MORANDA (3)
Palma de Mallorca, 28 y 29 de mayo de 199948
C j
J. L. RocaLa Confiabilidad en el Software
n n
[1/(N-i+1)] = . tii=1 i=1
n n
= n / [N. ti - (i-1). ti ]i=1 i=1
N,
Macromodelo JELINSKI-MORANDA (4)
Palma de Mallorca, 28 y 29 de mayo de 199949
C j
J. L. RocaLa Confiabilidad en el Software
0
5
10
15
20
25
30
35
0 50 100 150 200 250
N(ti)
ti
N=31
=0,00734
i ti i ti
1 9 14 9
2 12 15 4
3 11 16 1
4 4 17 3
5 7 18 3
6 2 19 6
7 5 20 1
8 8 21 11
9 5 22 33
10 7 23 7
11 1 24 91
12 6 25 2
13 1 26 1
Macromodelo JELINSKI-MORANDA (5)
Palma de Mallorca, 28 y 29 de mayo de 199950
C j
J. L. RocaLa Confiabilidad en el Software
0
0,2
0,4
0,6
0,8
1
1,2
0 50 100 150 200 250
C(ti)
ti
N=31
=0,00734
0
0,05
0,1
0,15
0,2
0,25
0 50 100 150 200 250
z(ti)
ti
N=31
=0,00734
Macromodelo JELINSKI-MORANDA (6)
Palma de Mallorca, 28 y 29 de mayo de 199951
C j
J. L. RocaLa Confiabilidad en el Software
Obtención de Softwares Confiables
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
Palma de Mallorca, 28 y 29 de mayo de 199952
C j
J. L. RocaLa Confiabilidad en el Software
Metodologías de Trabajo
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)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)
Palma de Mallorca, 28 y 29 de mayo de 199953
C j
J. L. RocaLa Confiabilidad en el Software
Personal-MotivaciónEntrenamiento
Herramientasy Equipos
Procedimientos y Métodos
PROCESO
TQM : Total Quality Management
Palma de Mallorca, 28 y 29 de mayo de 199954
C j
J. L. RocaLa Confiabilidad en el Software
Trilogía de JURAN
Planeamientode la Calidad
Control dela Calidad
Cos
to d
e la N
o Calidad
Zona Original de CC
Nueva Zona de CC
Experiencia Ganada
Mejora de la Calidad
Tiempo
PérdidaCrónica
Palma de Mallorca, 28 y 29 de mayo de 199955
C j
J. L. RocaLa Confiabilidad en el Software
Proyecto A Proyecto B
Proyecto X
Hardware
Software
Sistema
Organización
TQM
CMM
TQM aplicado al Software
CMM : Capability Maturity Model
Proyecto C
Palma de Mallorca, 28 y 29 de mayo de 199956
C j
J. L. RocaLa Confiabilidad en el Software
Inicial
Repetible
Definido
#1
#2
#3
#4
#5
Gestionado
Optimizado
Disciplinado
Estandarizado
Predecible
MejoradoContinuamente
CMM - 5 Niveles del Proceso de Maduración
Palma de Mallorca, 28 y 29 de mayo de 199957
C j
J. L. RocaLa Confiabilidad en el Software
Modelo de Cascada - IEEE Std.
Modificación
Oper.& Mant.
Validación
Diseño Lógico
Liberación
Def.Requerim.
Integración
Implement.
RVS
RCD
RIS
RIHS
RLS
RRS
Especif.Requer.Plan Gestión Proyect.
Plan Control Config.
Plan de Verificación
Plan de Validación
Descrip.Diseño
Docum.Soft.
Docum.Sistema
IEEE Std. 1058.1IEEE Std. 983IEEE. Std. 830
IEEE. Std. 1016
IEEE. Std. 1012IEEE. Std. 1008
IEEE. Std. 1016
IEEE. Std. 1012
IEEE. Std. 1042IEEE. Std. 828
IEEE. Std. 1028
Documentación de las actividades
Revisiones
Inf.Validación
Inf.Liberación
Inf.Deficiencias
Documentación de las actividades
Palma de Mallorca, 28 y 29 de mayo de 199958
C j
J. L. RocaLa Confiabilidad en el Software
IEEE Std. 1058.1IEEE Std. 983
IEEE Std. 830
IEEE Std. 1028
IEEE Std. 828IEEE Std. 1042
IEEE Std. 1016
IEEE Std. 1012IEEE Std. 1008
IEEE Std. 1012
Pautas para la Gestión de Proyectos de Software
Pautas para la Documentación delos Requerimientos del Software
Pautas para las Revisiones Técnicas del Software
Pautas para la Gestión de laConfiguración del Software
Pautas para la Implementación del Software
Pautas para la Verificacióny Validación del Software
Pautas para la Documentaciónde Validación del Software
IEEE SOFTW
ARE E
NG. STDS
Modelo de Cascada - IEEE Std.
Palma de Mallorca, 28 y 29 de mayo de 199959
C j
J. L. RocaLa Confiabilidad en el Software
Obtener softwares cada vez más confiables yseguros es necesario tanto desde el punto devista práctico como ético.
Los objetivos solo pueden alcanzarse mediante laaplicación sistemática de herramientas a vecespoco conocidas. La divulgación de este paquete deconocimiento debe comenzar desde los primerospasos de la enseñanza universitaria y propagarse acada emprendimiento que en materia de softwarese comience.
Mejores softwares, menos complejos y másportables podrán obtener mejores resultadosaplicativos.
Conclusiones
Palma de Mallorca, 28 y 29 de mayo de 199960
C j
J. L. RocaLa Confiabilidad en el Software
Actitud Creativa
No nos atrevemos a muchascosas porque son difíciles, peroson difíciles porque no nosatrevemos a hacerlas.
Séneca
Palma de Mallorca, 28 y 29 de mayo de 199961
C j
J. L. RocaLa Confiabilidad en el Software
Las HERRAMIENTAS están sólo hay que
UTILIZARLAS