CONFIABILIDAD EN EL SOFTWARE

• Habilidad que tiene un sistema o

componente de realizar sus funciones
requeridas bajo condiciones especificas en
periodos de tiempo determinados.
• Es decir, que trabaje SIN FALLAS en un
PERIODO DE TIEMPO y bajo un AMBIENTE
ESPECIFICO.
• El FALLO es cualquier no concordancia con los
requerimientos del software.
• La confiabilidad del software se encuentra en
un etapa de formación de desarrollo y es la
característica de rendimiento más costosa de
conseguir, difícil de conseguir y de garantizar.
• La generación de fallos depende del código
desarrollado, tales como tamaño y las
características del proceso desarrollado
(tecnologías y herramientas de ingeniería de
software usadas).
• La eliminación de fallos depende del tiempo y
del perfil operativo.
• La naturaleza del proyecto ayuda para la
formulación de estimaciones de costo y el
esfuerzo que asegure la CONFIABILIDAD
requerida.
 Como crear aplicaciones
CONFIABLES?
• Los siguientes puntos se recomiendan para la
obtención de un sistema CONFIABLE:
– Pensar en la confiabilidad:

– Eliminar los puntos de errores desde el diseño de

aplicaciones

– Proporcionar supervisión de confiablidad

CONTINUA

– Implementar cambios con cautela.

Están correctamente implementadas en la
aplicación las funciones descritas en las
especificaciones?

Satisface la aplicación las situaciones de usuario

previstas sin producir errores?

Se ajusta el perfil de confiabilidad de la aplicación

a los requisitos originales o los supera?
 Medios de la Confiabilidad
• Evitación de Defectos : Para evitar o prevenir la
introducción y ocurrencia de defectos.
• Tolerancia a Defectos: Para suministrar servicios
que cumplan con su especificación a pesar de la
existencia de defectos.
• Eliminación de Defectos :detectar la presencia
de defectos y eliminarlos.
 PRUEBAS DE CONFIABILIDAD
• Consiste en probar una aplicación para
descubrir y eliminar errores antes de que se
implemente el sistema.
 PRUEBAS DE ESTRES
• Consisten en la simulación de grandes cargas
de trabajo para para observar de que forma se
comporta la aplicación ante situaciones de uso
intenso.
De estos se describen dos subtipos:
– De componentes: Forzar cada componente en
forma aislada, mas de lo que la aplicación podría
experimentar en condiciones normales

– De integración: Interacción con otras estructuras

de datos, procesos y servicios tanto de
componentes internos como externos de la
aplicación
 PRUEBAS REALES
• El software que es confiable de forma aislada
en un entorno protegido puede no serlo en la
implementación real.

– Un entorno de prueba real garantiza que las

aplicaciones simultaneas no interfieren entre si.
 PRUEBAS DE DESTRUCCION
• Intenta por todos los medios bloquear la
aplicación o que esta produzca errores

Mejora la calidad del código ya que permiten

examinar el control de errores encontrados.
 PRUEBAS DE ESTRUCTURALES
• Conocidas también como las pruebas de “caja
blanca”

Son las pruebas donde se conoce la estructura

interna del componente a probar , esto para
verificar que su comportamiento sea el
esperado
 PRUEBAS DE INTEGRACION
• Verifica que las especificaciones de diseño
sean alcanzadas.