La Confiabilidad en el Software

Palma de Mallorca, 28 y 29 de mayo de 1999

C

1

j

La Confiabilidad en el Software

J. L. Roca


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


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


J. L. Roca


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


J. L. Roca


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.


J. L. Roca


6

Relación Costos Hardware-Software

% del Costo Total

100

Hardware

50 C

j

Software 0 1960


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.


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


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.


J. L. Roca

11


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.


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


J. L. Roca

14


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


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


Codificación Test

Operación J. L. Roca

16


 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”


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.


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


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


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)


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


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


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.


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


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


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.


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


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


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)


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


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


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


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


J. L. Roca

40


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


J. L. Roca

41


DOMINIO DE LAS ENTRADAS Se estudia la reacción ante la variabilidad de las entradas C j NELSON RAMAMOORTHY-BASTANI


J. L. Roca

42


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


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


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


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.


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)


t3

t4

ti

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

J. L. Roca

47


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


J. L. Roca

48


n i=1 C

n

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

j

= n / [N.

n

i=1 n

ti -

i=1


.

ti

i=1

N, (i-1). ti ]

J. L. Roca

49


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


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


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


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


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)


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


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


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


J. L. Roca

61


C

j

Las HERRAMIENTAS están sólo hay que UTILIZARLAS


J. L. Roca