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