1. No category

CONFIABILIDAD DEL SOFTWARE
ALFREDO GONZÁLEZ QUIRÓS
RESUMEN
El presente artículo representa una investigación realizada con respecto a la
confiabilidad del software, para ello se hace un énfasis principalmente a los
diferentes modelos utilizados en la estadística para el estudio de la
confiabilidad. Se abarca la importancia de la aplicación de estas técnicas para
la mejora continua de la calidad del software.
Para el desarrollo del documento se empleó un proceso investigativo mediante
libros y artículos, entre ellos se encuentran: “Practical Reliability Engineering”,
“Software reliability models: assumptions, limitations, and applicability”, y
“Software reliability: measurement, prediction, and application".
Dentro de las conclusiones obtenidas destaca la importancia de la confiabilidad
del software y la calidad en las predicciones para los patrocinadores,
desarrolladores, administradores y para los usuarios de los programas. Se
concluye que el estudio de la confiabilidad del software y la aplicación de
modelos estadísticos para la detección de fallas tempranas en las etapas de
desarrollo ayudan de manera significativa en el proceso de mejora de la
confiabilidad y calidad de una manera efectiva y de bajo costo.
INTRODUCCIÓN
La confiabilidad es una técnica que
permite estudiar la vida útil de los
productos a lo largo de la cadena de
suministros, este concepto surge a
raíz de la Segunda Guerra Mundial
con el propósito de que las armas
de los soldados no tuvieran ninguna
falla.
La confiabilidad del software se
refiere a la precisión con la que una
aplicación proporciona, sin errores,
los servicios que se establecieron
en las especificaciones originales.
La tecnología de software usada
hoy en día es imprescindible para
cualquier
sistema
informático,
puesto que sin él, este no
funcionaría. El software es quien da
las órdenes, quien indica que debe
hacer cada máquina con sus
elementos, cuando y como. Por eso
su gran importancia de que funcione
siempre de la mejor manera.
El diseño para favorecer la
confiabilidad, además de referirse al
tiempo de funcionamiento de la
aplicación antes de que se produzca
algún error, está relacionado
también con la consecución de
resultados correctos y con el control
de la detección de errores y de la
recuperación para evitar que se
produzcan errores. Se producen
errores en la aplicación por distintos
motivos:
•Comprobación inadecuada
•Problemas
relacionados
cambios en la administración
•Falta de
continuados
control
y
con
análisis
•Errores en las operaciones
•Código poco consistente
•Ausencia de procesos de diseño
de software de calidad
•Interacción con
servicios externos
aplicaciones
o
•Condiciones de funcionamiento
distintas (cambios en el nivel de
uso, sobrecargas máximas)
•Sucesos inusuales (errores de
seguridad, desbordamientos en la
difusión)
•Errores de hardware (discos,
controladores, dispositivos de red,
servidores, fuentes de alimentación,
memoria, CPU).
•Problemas
de
entorno
(red
eléctrica, refrigeración, incendios,
inundaciones, polvo, catástrofes
naturales)
Se dice que un software es
confiable si realiza lo que el usuario
desea, cuando así lo requiera.
Cuando corregimos los errores del
software sin introducir nuevos, la
confiabilidad final del software es
mejorada.
Es necesario utilizar Herramientas,
que en base a modelos ayuden a
determinar parámetros que sirvan
de análisis.
En la presente investigación se
explicarán algunos modelos.
MARCO TEORICO
A continuación se explican 4 de los
modelos más utilizados:
1. El modelo de Poisson:
Este modelo asume que pueden
existir errores aleatorios dentro
de una estructura de código y
que su aparición está en función
del tiempo de corrida del
programa. El número de errores
que ocurren en el tiempo t está
dado por la función 𝑁 (𝑡). Bajo
las siguientes condiciones:



𝑁 (0) = 0
No más de un error puede
ocurrir en el intervalo de
tiempo (t, t + dt)
La ocurrencia de un error es
independiente de los errores
previos.
Bajo estas condiciones la ocurrencia
de errores es descrita por una
distribución
Poisson
no
Homogénea:
𝑃[𝑁(𝑡) = 𝑛] =
[𝑚(𝑡)]𝑛
𝑒𝑥𝑝[−𝑚(𝑡)]
𝑛!
Con (𝑛 ≥ 0)
Donde:
𝑡
𝑚(𝑡) = ∫0 𝜆(𝑠)𝑑𝑠
𝑚(𝑡) Es la media esperada del
número de errores que ocurren en
el intervalo (0, t):
𝑚(𝑡) = 𝑎[1 − exp(−𝑏𝑡)]
Donde 𝑎 es el número total de
errores y 𝑏 es una constante. El
número de errores restantes
después del tiempo t, asumiendo
que cada error que ocurre es
corregido sin la introducción de
otros errores, es:
̅(𝑡) = 𝑎 exp(−𝑏𝑡)
𝑁
La función de confiabilidad, después
de que el error más reciente ocurre
y es corregido al tiempo s, es:
𝑅(𝑡) = 𝑒𝑥𝑝[−𝑎{exp(−𝑏𝑠) − 𝑒𝑥𝑝[−𝑏(𝑠 + 𝑡)]}]
Dentro del uso de un modelo
relacionado con el tiempo, la
interrogante surge en cuanto a que
unidades de tiempo deberán ser
usadas. El modelo Poisson ha sido
probado contra datos de error de
software usando un calendario de
tiempo durante el cual los errores
fueron detectados y corregidos y
valores para los parámetros 𝑎 y 𝑏
derivados. Sin embargo, desde que
los errores del software no están
relacionados en el tiempo como lo
están los procesos de fallas físicas
(Hardware), el uso de modelos
relacionados con el tiempo para los
errores de software se vuelve algo
problemático.
2. El modelo Musa:
El modelo Musa usa el tiempo de
ejecución del programa como la
variable independiente. Una versión
simplificada del modelo de Musa es:
𝑛 = 𝑁0 [1 − 𝑒𝑥𝑝 (
−𝐶𝑡
)]
𝑁𝑜 𝑇𝑜
Donde 𝑁0 es el número inherente de
errores, 𝑇0 el MTTF (Tiempo medio
de falla) al inicio de la prueba y 𝐶 el
factor de compresión de prueba
igual a la proporción del tiempo de
operación equivalente con el tiempo
de prueba.
El MTTF presente está dado por:
𝑇 = 𝑇𝑜 exp (
𝐶𝑡
)
𝑁𝑜 𝑇𝑜
La función de confiabilidad viene
dada por:
𝑅 = 𝑒𝑥𝑝 (
−𝑡
)
𝑇
De esta relación se puede derivar el
número de fallas que deben
encontrarse y ser corregidas
(MTTF), o el tiempo necesario de
ejecución del programa (𝑡), para
mejorar de 𝑇1 a 𝑇2:
1
1
∆𝑛 = 𝑁0 𝑇0 ( − )
𝑇1 𝑇2
𝑁0 𝑇0
𝑇2
) 𝐿𝑛 ( )
∆𝑡 = (
𝐶
𝑇1
3. Los
Modelos
Moranda
y
Wolverton:
JelinskiSchick-
Otros dos modelos del tipo
exponenciales
que
han
sido
sugeridos son el modelo JelinskiMoranda (JM) y el modelo SchickWolverton (SW). Dentro de los
modelos JM y SW, la función de
riesgo
ℎ (𝑡)
está
dada
respectivamente por:
ℎ(𝑡𝑖 ) = 𝜙[𝑁0 − 𝑛𝑖−1 ]
ℎ(𝑡𝑖 ) = 𝜙[𝑁0 − 𝑛𝑖−1 ]𝑡𝑖
Donde 𝑡𝑖 es la longitud del intervalo
de depuración 𝑖𝑒𝑠𝑖𝑚𝑜, que es el
tiempo entre el (𝑖 − 1)𝑒𝑠𝑖𝑚𝑜 y el
𝑖𝑒𝑠𝑖𝑚𝑜 de los errores y 𝜙 es una
constante.
4. Modelos Littlewood:
Los intentos de Littlewood por tomar
cuenta en el hecho de que
diferentes errores en el programa
tienen diferentes probabilidades de
causar fallas. Si 𝜙1 , 𝜙2 , … , 𝜙𝑁 son
las tasas de ocurrencia de los
errores 1, 2,…, N, la función de
probabilidad (PDF) para el tiempo
de falla del programa, después de
que el 𝑖𝑒𝑠𝑖𝑚𝑜 error ha sido fijado,
es:
𝑓 (𝑡) = 𝜆 exp(−𝜆𝑡)
Donde 𝜆 es la tasa de falla del
programa:
𝜆 = 𝜙1 + 𝜙2 + ⋯ + 𝜙𝑁−𝑖
𝜑 Es asumida para ser distribuidoGamma, estos errores no tienen
tasas constantes de ocurrencia pero
si tasas que son dependientes
sobre el uso del programa. Si los
parámetros de Gamma son (𝛼, 𝛽)
(equivalente a (𝑎, 1/𝜆)), entonces se
puede demostrar, usando un
enfoque de Bayes, que:
(𝑁−𝑖)𝛼
(𝑁 − 𝑖)𝛼(𝛽 + 𝑡 ´ )
𝑓 (𝑡 ) =
(𝛽 + 𝑡 ´ + 𝑡)1+(𝑁−𝑖)𝛼
Donde 𝑡 ´ es el tiempo tomado para
detectar y corregir 𝑖 errores. De
esto:
(𝑁−𝑖)𝛼
𝛽 + 𝑡´
𝑅 (𝑡 ) = (
)
𝛽 + 𝑡´ + 𝑡
Y
𝜆 (𝑡 ) =
(𝑁 − 𝑖)𝛼
𝛽 + 𝑡´ + 𝑡
En cada ocurrencia y corrección de
error, 𝜆(𝑡) cae por una cantidad de
𝛼/(𝛽 + 𝑡 ´). Se supone que todos los
errores detectados son corregidos,
sin que futuros errores sean
introducidos.
Tipos de pruebas
Las pruebas de software son las
investigaciones empíricas y técnicas
cuyo objetivo es proporcionar
información
objetiva
e
independiente sobre la calidad del
producto a la parte interesada
o stakeholder. Es una actividad más
en el proceso de control de calidad.
Las pruebas son básicamente un
conjunto de actividades dentro del
desarrollo
de software.
Dependiendo del tipo de pruebas,
estas actividades podrán ser
implementadas
en
cualquier
momento de dicho proceso de
desarrollo. Existen distintos modelos
de desarrollo de software, así como
modelos de pruebas. A cada uno
corresponde un nivel distinto de
involucramiento en las actividades
de desarrollo.

Pruebas estáticas
Son el tipo de pruebas que se
realizan sin ejecutar el código de la
aplicación (Ceferino).
Puede referirse a la revisión de
documentos, ya que no se hace una
ejecución de código. Esto se debe a
que se pueden realizar “pruebas de
escritorio “con el objetivo de seguir
los flujos de la aplicación.

Pruebas dinámicas
Todas aquellas pruebas que para su
ejecución requieren la ejecución de
la aplicación.
Las pruebas dinámicas permiten el
uso de técnicas de caja negra y caja
blanca con mayor amplitud. Debido
a la naturaleza dinámica de la
ejecución de pruebas es posible
medir con mayor precisión el
comportamiento de la aplicación
desarrollada.
Se denomina caja negra a aquel
elemento que es estudiado desde el
punto de vista de las entradas que
recibe y las salidas o respuestas
que produce, sin tener en cuenta su
funcionamiento interno. En otras
palabras, de una caja negra nos
interesará su forma de interactuar
con el medio que le rodea (en
ocasiones, otros elementos que
también podrían ser cajas negras)
entendiendo qué es lo que hace,
pero sin dar importancia a cómo lo
hace.

Pruebas de compatibilidad
Se comprueba el funcionamiento del
software desarrollado en muchas
plataformas: sistemas operativos,
navegadores, redes, hardware

Pruebas regresión
Se
evalúa
el
correcto
funcionamiento
del
software
desarrollado frente a evoluciones o
cambios funcionales.

Pruebas de integración
Se centra principalmente en las
comunicaciones y las conexiones
entre los diferentes módulos del
software desarrollado o con terceros
METODOLOGÍA
Proceso de la ingeniería de
confiabilidad
de
software
El proceso de la ICS puede verse
como un conjunto de actividades
adicionales y complementarias a las
ya realizadas dentro de cualquier
proceso
de
desarrollo.
Seis
actividades definen el marco de
trabajo de la ICS descritas a
continuación.
1. Definir el Producto.
Puede verse como un complemento
del Análisis de Requerimientos y
Diseño Arquitectónico. En esta
actividad se define quiénes son los
clientes, usuarios, proveedores y
otros sistemas relacionados.
2. Desarrollar
Operación.
el
Perfil
de
Se define el conjunto completo de
operaciones
(tareas
o
funcionalidades lógicas principales
del sistema) con su correspondiente
probabilidad de ocurrencia o uso
esperado. En esta etapa, la
administración de los recursos toma
un nivel cuantitativo basado en la
importancia de cada operación del
sistema.
1. Definir
la
Adecuada.
Confiabilidad
Se define lo que se considera como
“falla” para el producto en desarrollo
así como los
medios para
identificarla. Esta definición es
crítica para el proceso y debe ser
constante durante todo el ciclo de
vida.
En la segunda parte de esta
actividad se definen las medidas de
referencia
con
la
que
se
cuantificarán las intensidades de
falla, tales como el número de fallas
por tiempo o número de fallas por
unidad natural. Las unidades
naturales representan la cantidad de
proceso o trabajo realizado por el
sistema (transacciones, páginas
impresas, llamadas a funciones,
accesos, etcétera).
En la tercera parte de la actividad se
fijan las Intensidades de Falla
Objetivo (IFO) para cada sistema
asociado al producto. Las IFOs
representan la calidad del producto
en desarrollo y son definidas por el
cliente.
En la cuarta parte se seleccionan
las mejores estrategias de apoyo a
la confiabilidad de software que
ayuden a alcanzar los IFOs
respectivos al menor costo. Las
estrategias
de
apoyo
a
la
confiabilidad de software son
aquellas actividades y mecanismos
dentro del proceso de desarrollo
que reducen las intensidades de
falla y afectan positivamente los
costos y el tiempo de desarrollo.
Ejemplos de dichas estrategias
incluyen mecanismos de tolerancia
a fallos, inspecciones, revisiones,
distintos tipos de pruebas, etc.
La ICS proporciona pautas y cierta
información cuantitativa para la
determinación de la mezcla de
estrategias. Sin embargo, los
proyectos pueden mejorarse usando
la información que es particular a su
ambiente y al dominio propio del
producto.
2. Preparar las Pruebas.
Se definen los casos de prueba y
los métodos de prueba a partir de la
información
de
los
perfiles
operacionales y las estrategias de
apoyo a la confiabilidad de software.
Esta actividad puede integrarse con
el proceso de pruebas del modelo
de desarrollo que se tenga. Lo
importante en esta etapa es la
decisión de qué cosas se van a
probar y qué datos se usaran en los
casos de prueba.
3. Ejecutar las Pruebas.
Se asignan los tiempos para las
pruebas entre los sistemas, los tipos
de prueba (características, carga y
regresión) así como su ejecución.
4. Guiar las Pruebas.
Se procesa la información obtenida
en la ejecución de las pruebas para
varios propósitos. El primero es
monitorear el crecimiento de la
confiabilidad del sistema (o la
reducción de las intensidades de
falla) mientras se van reparando los
defectos
encontrados
que
generaron las fallas. Otro propósito
es el de poder determinar si es
necesario
seguir
probando;
finalmente, el tercero es el de dirigir
la fase del liberación del producto.
Algo muy importante dentro del
proceso de ICS es la recolección de
datos de campo (información sobre
el uso y las fallas encontradas en la
operación real del sistema). El
proceso de ICS no está completo
cuando se libera el producto dado
que la información que usamos
puede ser imprecisa. El recolectar
dicha información permitirá evaluar
con mayor detalle la satisfacción del
cliente y la calidad del producto.
En esta breve descripción del
proceso de la ICS se han omitido
detalles relacionados con aspectos
cuantitativos.
Existen
modelos
estadísticos
que
permiten
determinar el momento para detener
las actividades de prueba basados
en la información que se tiene de
las fallas encontradas, objetivos de
intensidades de falla y del número
de casos de prueba ejecutados.
CONCLUSIONES
Se podía decir que la efectividad
que presenta la ICS (Ingeniería de
la Confiabilidad del Software) reside
en una idea ya un concepto claro:
“No puedes controlar lo que no
puedes medir.”. La bondad de la
ICS reside en llevar dicha idea a
elementos concretos con beneficios
específicos
• La construcción del perfil de
operación mejora el análisis de
requerimientos dado que el proceso
de cuantificar las probabilidades de
uso de las operaciones del producto
exige un proceso adicional de
reflexión y trabajo con el cliente.
• Se debe tener presente, que los
errores que se presentan por
inconsistencias en el código del
software son errores frecuentes que
afectan la confiabilidad y el
funcionamiento del programa. Los
errores de este tipo son corregidos
mediantes las actualizaciones, una
vez
eliminado
el
error
la
confiabilidad del software aumenta.
• La definición de lo que se
considera como “falla” para el
producto involucra discutir con el
cliente y usuarios los criterios de
calidad del producto. Esta idea
establece las bases para medir la
calidad del producto reduciendo
riesgos.
• La determinación de qué
estrategias
de
apoyo
a
la
confiabilidad del software son
usadas para la calidad deseada del
producto provee de un medio
cuantitativo para optimizar los
recursos del proyecto.
• El monitoreo cuantitativo de los
resultados de las pruebas y del
crecimiento de la confiabilidad
permite
administrar
mejor
el
proyecto.
La ICS representa una práctica que
puede ser usada con resultados
positivos. El micro y pequeñas
industrias pueden incorporar dicha
práctica dentro de sus procesos no
sólo para mejorar la calidad de sus
productos.
BIBLIOGRAFÍA
Goel, A. L. (1985). Software
reliability models: assumptions,
limitations, and applicability. IEEE
Transaction
on
Software
Engineering, SE–11(12), 1411–
1423.
Musa, J. D. (2005). Software
reliability engineering: more reliable
software faster and cheaper (2nd
Ed.). Tata McGraw-Hill Publication.
Musa, J. D. (1993). Operational
profiles
in
software
reliability
engineering.
IEEE
Software
Magazine.
Musa, J. D., Iannino, A., & Okumoto,
K. (1987). Software reliability:
measurement,
prediction,
and
application. New York: McGraw–Hill
Publication.