Confiabilidad-de-Software PDF

Title Confiabilidad-de-Software
Author Daniel Subelza
Course Informática
Institution Universidad Nacional de Jujuy
Pages 6
File Size 178.3 KB
File Type PDF
Total Downloads 74
Total Views 188

Summary

Confiabilidad de Software...


Description

Confiabilidad de Software Denominamos confiabilidad de software como la probabilidad de una operación de software de estar libre de fallos por un periodo especifico de tiempo en un entorno específico. Aunque la confiabilidad del software es definida como una función probabilística, con noción temporal, debemos notar que, a diferencia del hardware, la confiabilidad del software no es una función directa del tiempo. La confiabilidad del software es un atributo importante de la calidad del software, junto con la funcionalidad, usabilidad, servicio, capacidad, instalabilidad, mantenibilidad y documentación. La confiabilidad es difícil de alcanzar, porque la complejidad del software tiende a ser alta. En cualquier sistema con un alto grado de complejidad, incluyendo el software, será muy difícil alcanzar un cierto nivel de confiabilidad considerando el rápido crecimiento del tamaño de los sistemas y la facilidad de realizarlo mediante la mejora de software. Mecanismos de fallos de software Las fallas de software pueden deberse debido a errores, ambigüedades, descuidos o mal interpretación de lo que el software está dispuesto a satisfacer, falta de cuidado o incompetencia en la codificación, testeo inadecuado, incorrecto; uso inesperado del software u otros problemas que no se pueden prever. Los fallos en el software son fallas de diseño, las cuales son mucho más difíciles de visualizar, clasificar, detectar y dominar. Una lista parcial de características distintas del software comparadas con el hardware puede ser la siguiente: •

Causas de fallos: Los defectos de software son principalmente defectos de diseño.



Desgaste: El software no tiene energía relacionada al proceso de desgaste. Los errores pueden ocurrir sin advertencia.



Conceptos de sistemas reparables: Reinicios periódicos pueden ayudar a arreglar problemas de software.



Dependencia de tiempo y ciclo de vida: Confiabilidad del software no es una función de tiempo operacional.



Factores de entorno: No afecta la confiabilidad del software, excepto que afecten las entradas del programa.



Predicción de confiabilidad: La confiabilidad del software no puede ser predicha mediante modelos físicos, ya que depende únicamente de los factores humanos en el diseño.



Redundancia: No puede mejorar la confiabilidad si componentes idénticos son usados.



Interfaces: Las interfaces son puramente conceptuales.



Motivadores de tasas de fallo: Usualmente no son predecibles desde análisis de sentencias separadas.



Construcción de componentes estándar: Partes estándar bien comprendidas y exhaustivamente probadas pueden ayudar a la mantenibilidad y confiabilidad. Pero en la industria del software, no se ha observado esta tendencia. La reutilización de código ha existido desde hace algún tiempo, pero en un grado muy limitado. Estrictamente hablando, no existen piezas estándar para el software a excepción de algunas estructuras de lógica.

Modelos de Confiabilidad de Software Los modelos de confiabilidad surgieron debido a intención de tratar de entender por qué un software falla, y trata de cuantificar la confiabilidad del software. Se han desarrollado más de 200 modelos a partir de los años 1970s, pero el cómo cuantificar la confiabilidad de un software sigue permaneciendo irresuelta. De los modelos creados, ninguno ha logrado poder ser usado en todas las situaciones. Ningún modelo es completo o representativo. Un modelo puede trabajar para un de forma correcta para un software, mientras que para otros puede causar problemas. a) Partes de los modelos: •

Hipótesis

Las hipótesis que presentan son las siguientes: -

El tiempo entre las fallas sucesivas tienden a ser independientes: El tiempo, o el número adicional de casos de prueba, a la falta siguiente puede depender de la naturaleza o el tiempo de la falta anterior.

-

Un fallo detectado se corrige inmediatamente. No se introducen nuevos errores durante el proceso de eliminación de fallos.

-

-

La tasa de fallos decrece con la prueba de tiempo, a medida que avanza la prueba, se detectan fallas. O bien son eliminados antes de que la prueba continúe o no se eliminan y la prueba se desplaza a otras partes del programa. Tasa de fracaso es proporcional al número de fallos restante. La confiabilidad es una función del número de fallos restante.



Factores: La aplicabilidad que posee cada modelo dependiendo del proceso de desarrollo del software.



Fase de diseño: las fallas se pueden detectar visualmente o por otros procedimientos formales o informales. Los modelos de confiabilidad del software que se suelen aplicar son los de predicción, debido a que aun no se encuentra un historial de fallos.



Fase de Prueba: El tiempo de los modelos dependientes, especialmente el tiempo entre los modelos de fracasos, no suelen ser aplicados. Los que se aplican son los modelos de estimación.



Función matemática que relaciona la fiabilidad con el factor: La función matemática es generalmente más alta orden exponencial o logarítmico.

b) Categorías

Los modelos de confiabilidad se pueden dividir en dos sub categorías, ambas técnicas están basadas en la observación y la acumulación de los errores de los datos y el análisis de la inferencia estadística. : •

Modelos de Predicción



Modelos de Estimación

Diferencias: Datos de Referencia

Cuando se utiliza Marco de Tiempo

Modelos de Predicción Utilización de datos históricos.

Modelos de Estimación Utilización de los datos de los actuales esfuerzos de desarrollo de software. Fase de Prueba

Fases de desarrollo o de prueba Predice la fiabilidad en Estimación de la algún momento futuro. fiabilidad, ya sea actual o en algún momento futuro.

Requerimiento de datos Los requisitos de datos para aplicar este modelo de recuento de falla son: 1. Contar el número de fallos en cada intervalo de prueba. 2. El tiempo de finalización de cada período que el software está bajo observación. Modelo De la hipótesis podemos ver que la función de valor medio debe ser de la forma:

Para algunas constantes b>0 y N>0. N es el total de numero de fallos que son eventualmente detectados. La función de la intensidad de fracaso es la derivada de µ(t) y tenemos.

Observe que la función de la intensidad de fracaso es estrictamente decreciente para t> 0. Porque pertenece a la clase exponencial, tenemos la distribución de un error individual, x:

La función de la intensidad de fracaso sería:

muestra la relación entre la función de la intensidad de fracaso y la función de densidad de probabilidad para un solo fallo. Goel y Okumoto han adaptado este modelo para utilizar el tiempo de ocurrencias de los fallos contados. Dentro de este marco también han determinado un tiempo de liberación óptima para un sistema de software. si la fiabilidad deseada es de R por un tiempo de funcionamiento especificados de O, luego de lograr el resultado deseado, la cantidad necesaria de tiempo que el software debe ser observado es:

En el documento de Goel y Okumoto, ellos determinan el tiempo de liberación óptima basada en los costos (el costo de las pruebas de encontrar y reparar una falla en el entorno de pruebas frente a la explotación).

Modelo de Shooman 1. Aplicabilidad Sirve para predecir el número de errores remanentes en el programa, a partir de la información estadística de errores descubiertos y corregidos. a. Supuestos •

Número total de instrucciones en lenguaje máquina en el programa es constante.



Número de errores al comienzo de la prueba de integración es constante y decrece proporcionalmente una vez que los errores son corregidos.



No se introducen nuevos errores durante la prueba

b. Fórmula

donde: eo

Es el número de errores iniciales.

I

Es el número total de instrucciones de lenguaje.

ec

Es el número de errores corregidos.

Ks

Es la constante de Shooman.

2. Ventaja •

El modelo Shooman se ajusta a los diferentes cambios en el tamaño del producto de software.

3. Desventaja •

Los supuestos del modelo Shooman deben ser válidos para que los resultados sean también válidos....


Similar Free PDFs