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

http://www.ieee.org/portal/site/relsoc/index.jsp?pageID=relsoc_home


C j


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


C j


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).


C j


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


C j


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


C j


Relación Costos Hardware-Software100

50

0

Hardware

Software

% d

el Cos

toTot

al

1960 1975 2005Año

Introducción


C j


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.


C j


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.



C j


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.



C j


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.


C j


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



C j


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.



C j


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



C j


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.



C j


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



C j


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”



C j


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


C j


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.



C j


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



C j


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?


C j



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).


C j



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}


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) FALLAS (FAULTS)



C j


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


C j


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


C j


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


C j


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


C j


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


C j


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


C j


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


C j


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


C j


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


C j


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


C j


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


C j


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)


C j


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



C j


FASE MANTENIMIENTOAdición de nuevas posibilidades-Mejora de algoritmos

(Existen pocos modelos)

INPUT DOMAIN BASED MODEL



C j


MEDIDA DE EXACTITUD (CORRECTNESS)Medida de la confianza en el test


SIEMBRA DE ERRORES: BASIN,MILL,DE MILLO-LIPTON

FENOMENOLOGICOS: HALSTEAD

ESTADISTICOS: NELSON,EHRENBERGER,BROWN-LIPOW




C j


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


C j


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



C j


DOMINIO DE LAS ENTRADAS

Se estudia la reacción ante la variabilidad de las entradas

NELSON

RAMAMOORTHY-BASTANI



C j


MEDIDA DE EXACTITUD (CORRECTNESS)

Medida de la confianza en el test


SIEMBRA DE ERRORES: BASIN,MILL,DEMILLO-LIPTON

FENOMENOLOGICOS: HALSTEAD

ESTADISTICOS: NELSON,EHRENBERGER, BROWN-LIPOW




C j


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


C j


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


C j


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)


C j


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 ]



C j


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



C j


n n

[1/(N-i+1)] = . tii=1 i=1

n n

= n / [N. ti - (i-1). ti ]i=1 i=1

N,



C j


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



C j


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



C j


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


C j


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)


C j


Personal-MotivaciónEntrenamiento

Herramientasy Equipos

Procedimientos y Métodos

PROCESO

TQM : Total Quality Management


C j


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


C j


Proyecto A Proyecto B

Proyecto X

Hardware

Software

Sistema

Organización

TQM

CMM

TQM aplicado al Software

CMM : Capability Maturity Model

Proyecto C


C j


Inicial

Repetible

Definido

#1

#2

#3

#4

#5

Gestionado

Optimizado

Disciplinado

Estandarizado

Predecible

MejoradoContinuamente

CMM - 5 Niveles del Proceso de Maduración


C j


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


C j


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.


C j


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


C j


Actitud Creativa

No nos atrevemos a muchascosas porque son difíciles, peroson difíciles porque no nosatrevemos a hacerlas.

Séneca


C j


Las HERRAMIENTAS están sólo hay que

UTILIZARLAS

sin título de diapositiva - ieeeieee.eie.fceia.unr.edu.ar/pdf_software.pdf · palma de mallorca,...

Documents