Sistemas de Información

Prof. Leonel Savery

ls3612@unphu.edu.do
Ingeniería de Fiabilidad
Fiabilidad del Software

 En general, los clientes de software esperan que todo el

software sea confiable. Sin embargo, para aplicaciones no
críticas, pueden estar dispuestos a aceptar algunas fallas
del sistema.
 Algunas aplicaciones (sistemas críticos) tienen requisitos
de confiabilidad muy altos y se pueden usar técnicas
especiales de ingeniería de software para lograrlo.
 Sistemas médicos
 Telecomunicaciones y sistemas eléctricos.
 Sistemas aeroespaciales
Faltas, Errores y Fallas
Término Descripción
Error humano o Comportamiento humano que resulta en la introducción de fallas en
error un sistema. Por ejemplo, en el sistema de clima en el desierto, un
programador puede decidir que la forma de calcular la hora para la
próxima transmisión es agregar 1 hora a la hora actual. Esto funciona
excepto cuando el tiempo de transmisión es entre las 23.00 y la
medianoche (la medianoche es 00.00 en el reloj de 24 horas).
Falta de sistema Una característica de un sistema de software que puede conducir a un
error del sistema. La falla es la inclusión del código para agregar 1
hora a la hora de la última transmisión, sin verificar si la hora es
mayor o igual a 23.00.
Error de sistema Un estado de sistema erróneo que puede provocar un comportamiento
inesperado del sistema por parte de los usuarios del sistema. El valor
del tiempo de transmisión se establece incorrectamente (a 24.XX en
lugar de 00.XX) cuando se ejecuta el código defectuoso.
Falla de sistema Un evento que ocurre en algún momento en el tiempo cuando el
sistema no entrega un servicio según lo esperado por sus usuarios. No
se transmiten datos meteorológicos porque el tiempo no es válido.
Faltas y Fallas

 Las fallas son generalmente un resultado de errores del sistema que

se derivan de fallas en el sistema
 Sin embargo, las faltas no necesariamente resultan en errores del
sistema
 El estado de sistema erróneo resultante de la falla puede ser transitorio y
"corregido" antes de que surja un error.
 El código defectuoso nunca puede ser ejecutado.
 Los errores no conducen necesariamente a fallas del sistema
 El error se puede corregir mediante la detección y recuperación de
errores incorporadas
 La falla puede ser protegida contra las instalaciones de protección
incorporadas. Estos pueden, por ejemplo, proteger los recursos del
sistema de los errores del sistema.
Manejo de Faltas

 Evitar fallos
 El sistema se desarrolla de tal manera que se evite el error
humano y, por lo tanto, se minimizan las fallas del sistema.
 El proceso de desarrollo se organiza para que las fallas en el
sistema sean detectadas y reparadas antes de la entrega al
cliente.
 Detección de fallas
 Las técnicas de verificación y validación se utilizan para descubrir
y eliminar fallas en un sistema antes de que se implemente.
 Tolerancia a fallos
 El sistema está diseñado para que las fallas en el software
entregado no resulten en una falla del sistema.
Logro de Fiabilidad

 Evitar fallos
 Se utilizan técnicas de desarrollo que minimizan la posibilidad de
errores o atrapan errores antes de que resulten en la introducción
de fallas en el sistema.
 Detección y eliminación de fallos.
 Se utilizan técnicas de verificación y validación que aumentan la
probabilidad de detectar y corregir errores antes de que el sistema
entre en servicio.
 Tolerancia a fallos
 Las técnicas de tiempo de ejecución se utilizan para garantizar
que las fallas del sistema no den como resultado errores del
sistema y / o que los errores del sistema no produzcan fallas en el
sistema.
Los Crecientes Costos de Eliminación de
Fallos Residuales
Disponibilidad y
Fiabilidad
Disponibilidad y Fiabilidad

 Fiabilidad
 La probabilidad de que el sistema funcione sin fallas durante un
tiempo específico en un entorno determinado para un propósito
determinado
 Disponibilidad
 La probabilidad de que un sistema, en un momento determinado,
esté operativo y sea capaz de prestar los servicios solicitados.
 Ambos de estos atributos pueden expresarse
cuantitativamente, p. la disponibilidad de 0.999 significa
que el sistema está en funcionamiento durante el 99.9%
del tiempo.
Fiabilidad y Especificaciones

 La fiabilidad solo se puede definir formalmente con

respecto a una especificación del sistema, es decir, una
falla es una desviación de una especificación.
 Sin embargo, muchas especificaciones son incompletas o
incorrectas, por lo tanto, un sistema que se ajuste a su
especificación puede "fallar" desde la perspectiva de los
usuarios del sistema.
 Además, los usuarios no leen las especificaciones, por lo
que no saben cómo debe comportarse el sistema.
 Por lo tanto, la fiabilidad percibida es más importante en
la práctica.
Percepciones de Fiabilidad

 La definición formal de fiabilidad no siempre refleja la

percepción del usuario de la fiabilidad de un sistema
 Los supuestos que se hacen sobre el entorno donde se usará un
sistema pueden ser incorrectos
 Es probable que el uso de un sistema en un entorno de oficina sea
bastante diferente del uso del mismo sistema en un entorno
universitario
 Las consecuencias de los fallos del sistema afectan la percepción
de fiabilidad.
 Los limpiaparabrisas no confiables en un automóvil pueden ser
irrelevantes en un clima seco
 Los fallos que tienen consecuencias graves (como una avería del
motor en un automóvil) reciben mayor peso de los usuarios que los
fallos que son inconvenientes
Un Sistema Como un Mapeo de Entrada /
Salida
Percepción de Disponibilidad

 La disponibilidad generalmente se expresa como un

porcentaje del tiempo que el sistema está disponible para
entregar servicios, por ejemplo. 99,95%.
 Sin embargo, esto no tiene en cuenta dos factores:
 El número de usuarios afectados por la interrupción del servicio.
La pérdida de servicio en medio de la noche es menos importante
para muchos sistemas que la pérdida de servicio durante los
períodos de uso máximo.
 La duración de la interrupción. Cuanto más larga es la
interrupción, más la interrupción. Varias interrupciones breves
tienen menos probabilidades de ser perjudiciales que una
interrupción prolongada. Los largos tiempos de reparación son un
problema particular.
Patrones de Uso del Software
Fiabilidad en Uso

 Eliminar el X% de las fallas en un sistema no

necesariamente mejorará la confiabilidad en un X%.
 Los defectos del programa pueden estar en secciones del
código que se ejecutan raramente, por lo que los usuarios
nunca pueden encontrarlos. La eliminación de estos no
afecta a la fiabilidad percibida.
 Los usuarios adaptan su comportamiento para evitar las
características del sistema que pueden fallar para ellos.
 Por lo tanto, un programa con fallas conocidas aún puede
ser percibido como confiable por sus usuarios.
Requerimientos de la
Fiabilidad
Requisitos de Fiabilidad del Sistema
 Los requisitos de confiabilidad funcional definen las
funciones del sistema y del software que evitan, detectan
o toleran fallas en el software y aseguran que estas fallas
no conduzcan a fallas en el sistema.
 Los requisitos de fiabilidad del software también pueden
incluirse para hacer frente a un error de hardware o un
error del operador.
 La confiabilidad es un atributo medible del sistema, por lo
que los requisitos de confiabilidad no funcionales pueden
especificarse cuantitativamente. Estos definen el número
de fallas que son aceptables durante el uso normal del
sistema o el tiempo en que el sistema debe estar
disponible.
Métricas de Fiabilidad
 Las métricas de fiabilidad son unidades de medida de la
fiabilidad del sistema.
 La fiabilidad del sistema se mide contando el número de
fallas operacionales y, cuando corresponde,
relacionándolas con las demandas realizadas en el sistema
y el tiempo que el sistema ha estado operativo.
 Se requiere un programa de medición a largo plazo para
evaluar la confiabilidad de los sistemas críticos.
 Métrica
 Probabilidad de fallo bajo demanda
 Tasa de ocurrencia de fallos / tiempo medio hasta el fallo
 Disponibilidad
Probabilidad de Fallo Bajo Demanda
(POFOD)
 Esta es la probabilidad de que el sistema falle cuando se realiza una solicitud
de servicio. Útil cuando las demandas de servicio son intermitentes y
relativamente infrecuentes.
 Adecuado para sistemas de protección donde los servicios se demandan
ocasionalmente y donde hay consecuencias graves si el servicio no se entrega.
 Relevante para muchos sistemas críticos para la seguridad con componentes
de administración de excepciones
 Sistema de parada de emergencia en una planta química.
Tasa de Ocurrencia de Fallas (ROCOF)

 Refleja la tasa de ocurrencia de fallas en el sistema.

 ROCOF de 0.002 significa que es probable que haya 2 fallos en cada
1000 unidades de tiempo operativas, por ejemplo. 2 fallos por 1000
horas de funcionamiento.
 Relevante para sistemas donde el sistema tiene que procesar un gran
número de solicitudes similares en poco tiempo
 Sistema de procesamiento de tarjetas de crédito, sistema de reserva
aérea.
 Recíproco de ROCOF es el tiempo medio de falla (MTTF)
 Relevante para sistemas con transacciones largas, es decir, donde el
procesamiento del sistema lleva mucho tiempo (por ejemplo, sistemas
CAD). MTTF debe ser más larga que la longitud de transacción esperada.
Disponibilidad

 Medida de la fracción del tiempo que el sistema está

disponible para su uso.
 Toma en cuenta el tiempo de reparación y reinicio.
 La disponibilidad de 0.998 significa que el software está
disponible para 998 de las 1000 unidades de tiempo.
 Relevante para sistemas continuos y sin interrupciones.
 Sistemas de conmutación telefónica, sistemas de señalización
ferroviaria.
 Especificación de Disponibilidad
Disponibilidad Explicación
0.9 El sistema está disponible para el 90% del tiempo.
Esto significa que, en un período de 24 horas
(1,440 minutos), el sistema no estará disponible
durante 144 minutos.
0.99 En un período de 24 horas, el sistema no está
disponible durante 14.4 minutos.
0.999 El sistema no está disponible durante 84 segundos
en un período de 24 horas.
0.9999 El sistema no está disponible durante 8.4
segundos en un período de 24 horas.
Aproximadamente, un minuto por semana.
Requisitos de Fiabilidad No Funcionales

 Los requisitos de confiabilidad no funcionales son

especificaciones de la fiabilidad y disponibilidad
requeridas de un sistema usando una de las métricas de
confiabilidad (POFOD, ROCOF o AVAIL).
 La fiabilidad cuantitativa y la especificación de
disponibilidad se han utilizado durante muchos años en
sistemas críticos para la seguridad, pero es poco común en
sistemas críticos para la empresa.
 Sin embargo, a medida que más y más compañías
demandan un servicio 24/7 de sus sistemas, tiene sentido
que sean precisas sobre sus expectativas de fiabilidad y
disponibilidad.
Beneficios de la Especificación de
Fiabilidad
 El proceso de decidir el nivel requerido de fiabilidad ayuda a aclarar
qué necesitan realmente las partes interesadas.
 Proporciona una base para evaluar cuándo dejar de probar un sistema.
Se detiene cuando el sistema ha alcanzado el nivel de confiabilidad
requerido.
 Es un medio para evaluar diferentes estrategias de diseño destinadas
a mejorar la confiabilidad de un sistema.
 Si un regulador tiene que aprobar un sistema (por ejemplo, todos los
sistemas que son críticos para la seguridad de vuelo en una aeronave
están regulados), entonces la evidencia de que se ha alcanzado un
objetivo de confiabilidad requerido es importante para la
certificación del sistema.
Especificando los Requisitos de
Fiabilidad
 Especifique los requisitos de disponibilidad y confiabilidad
para los diferentes tipos de fallas. Debería haber una
menor probabilidad de fallas de alto costo que de fallas
que no tengan consecuencias graves.
 Especifique los requisitos de disponibilidad y fiabilidad
para los diferentes tipos de servicio del sistema. Los
servicios críticos del sistema deben tener la más alta
confiabilidad, pero puede estar dispuesto a tolerar más
fallas en los servicios menos críticos.
 Piense si realmente se requiere un alto nivel de
confiabilidad. Se pueden utilizar otros mecanismos para
proporcionar un servicio de sistema confiable.
Especificación de Fiabilidad ATM

 Preocupaciones clave
 Para asegurarse de que sus cajeros automáticos realicen los
servicios al cliente según lo solicitado y que registren
correctamente las transacciones de los clientes en la base de
datos de la cuenta.
 Para garantizar que estos sistemas de cajeros automáticos estén
disponibles para su uso cuando sea necesario.
 Los mecanismos de transacción de la base de datos se
pueden usar para corregir problemas de transacción, por
lo que todo lo que se requiere es un bajo nivel de
confiabilidad de ATM.
 La disponibilidad, en este caso, es más importante que la
fiabilidad.
Especificación de Disponibilidad ATM

 Servicios del sistema

 El servicio de base de datos de la cuenta del cliente;
 Los servicios individuales proporcionados por un cajero automático como
"retirar efectivo", "proporcionar información de la cuenta", etc.
 El servicio de la base de datos es crítico, ya que la falla de este
servicio significa que todos los cajeros automáticos en la red están
fuera de acción.
 Debe especificar esto para tener un alto nivel de disponibilidad.
 La disponibilidad de la base de datos debe ser alrededor de 0.9999, entre
las 7 am y las 11 pm.
 Esto corresponde a un tiempo de inactividad de menos de 1 minuto por
semana.
Especificación de Disponibilidad ATM

 Para un cajero automático individual, los problemas clave

de confiabilidad dependen de la confiabilidad mecánica y
del hecho de que puede quedarse sin efectivo.
 Un nivel inferior de disponibilidad de software para el
software de cajeros automáticos es aceptable.
 Por lo tanto, la disponibilidad general del software de
cajeros automáticos se puede especificar como 0.999, lo
que significa que una máquina puede no estar disponible
entre 1 y 2 minutos cada día.
Especificación de Fiabilidad de la Bomba
de Insulina
 La probabilidad de falla (POFOD) es la métrica más
apropiada.
 Fallos transitorios que pueden ser reparados por acciones
del usuario, como la recalibración de la máquina. Un valor
relativamente bajo de POFOD es aceptable (por ejemplo,
0.002) - puede ocurrir una falla en cada 500 demandas.
 Las fallas permanentes requieren que el software sea
reinstalado por el fabricante. Esto debe ocurrir no más de
una vez al año. POFOD para esta situación debe ser
inferior a 0.00002.
Requerimientos de la Fiabilidad
Funcional
 Verificación de los requisitos que identifican las
comprobaciones para garantizar que se detecten datos
incorrectos antes de que se produzca una falla.
 Los requisitos de recuperación que están orientados a
ayudar al sistema a recuperarse después de que se haya
producido una falla.
 Requisitos de redundancia que especifican las
características redundantes del sistema que se incluirán.
 También se pueden incluir los requisitos de proceso de
confiabilidad que especifican el proceso de desarrollo a
utilizar.
Ejemplos de Requerimientos de
Fiabilidad Funcional
RF1: se debe definir un rango predefinido para todas las entradas del
operador y el sistema debe verificar que todas las entradas del
operador se encuentren dentro de este rango predefinido.
(Comprobación)
RF2: Las copias de la base de datos del paciente se mantendrán en
dos servidores separados que no se encuentran en el mismo edificio.
(Recuperación, redundancia)
RF3: la programación en versión N se utilizará para implementar el
sistema de control de frenado. (Redundancia)
RF4: El sistema se debe implementar en un subconjunto seguro de
Ada y se debe verificar mediante análisis estático. (Proceso)
Arquitecturas Tolerantes
a Fallos
Tolerancia a Fallos

 En situaciones críticas, los sistemas de software deben ser

tolerantes a fallos.
 Se requiere tolerancia a fallos cuando hay requisitos de
alta disponibilidad o cuando los costos de fallas del
sistema son muy altos.
 La tolerancia a fallos significa que el sistema puede
continuar en funcionamiento a pesar de un fallo del
software.
 Incluso si se ha demostrado que el sistema cumple con su
especificación, también debe ser tolerante a fallos ya que
puede haber errores de especificación o la validación
puede ser incorrecta.
Arquitecturas de Sistemas Tolerantes a
Fallos
 Las arquitecturas de sistemas tolerantes a fallas se
utilizan en situaciones donde la tolerancia a fallas es
esencial. Estas arquitecturas generalmente se basan en
redundancia y diversidad.
 Ejemplos de situaciones donde se utilizan arquitecturas
confiables:
 Sistemas de control de vuelo, donde la falla del sistema podría
amenazar la seguridad de los pasajeros.
 Sistemas de reactores donde la falla de un sistema de control
podría llevar a una emergencia química o nuclear
 Sistemas de telecomunicaciones, donde hay una necesidad de
disponibilidad 24/7.
Sistemas de Protección

 Un sistema especializado que está asociado con algún otro

sistema de control, que puede tomar medidas de
emergencia si ocurre una falla.
 Sistema para detener un tren si pasa una luz roja.
 Sistema para apagar un reactor si la temperatura / presión son
demasiado altas
 Los sistemas de protección monitorean
independientemente el sistema controlado y el medio
ambiente.
 Si se detecta un problema, emite comandos para tomar
medidas de emergencia para apagar el sistema y evitar
una catástrofe.
Arquitectura de los Sistemas de
Protección
Funcionalidad de los Sistemas de
Protección
 Los sistemas de protección son redundantes porque
incluyen capacidades de monitoreo y control que replican
aquellas en el software de control.
 Los sistemas de protección deben ser diversos y utilizar
una tecnología diferente del software de control.
 Son más simples que el sistema de control, por lo que se
puede gastar más esfuerzo en la validación y la garantía
de confiabilidad.
 El objetivo es garantizar que haya una baja probabilidad
de falla en la demanda del sistema de protección.
Arquitecturas de Autocontrol

 Arquitecturas multicanal donde el sistema monitorea sus

propias operaciones y toma medidas si se detectan
inconsistencias.
 Se realiza el mismo cálculo en cada canal y se comparan
los resultados. Si los resultados son idénticos y se
producen al mismo tiempo, se asume que el sistema está
funcionando correctamente.
 Si los resultados son diferentes, se asume un error y se
genera una excepción de error.
Arquitecturas de Autocontrol
Sistemas de Autocontrol

 El hardware en cada canal debe ser diverso para que la

falla del hardware en modo común no conduzca a que
cada canal produzca los mismos resultados.
 El software en cada canal también debe ser diverso, de lo
contrario, el mismo error de software afectaría a cada
canal.
 Si se requiere alta disponibilidad, puede usar varios
sistemas de autocontrol en paralelo.
 Este es el enfoque utilizado en la familia de aviones Airbus para
sus sistemas de control de vuelo.
Arquitectura del Sistema de Control de
Vuelo de Airbus
Discusión de la Arquitectura Airbus
 El Airbus FCS tiene 5 computadoras separadas, cualquiera
de las cuales puede ejecutar el software de control.
 Se ha hecho un amplio uso de la diversidad.
 Los sistemas primarios utilizan un procesador diferente de los
sistemas secundarios.
 Los sistemas primarios y secundarios utilizan conjuntos de chips de
diferentes fabricantes.
 El software en los sistemas secundarios es menos complejo que en
el sistema primario: proporciona solo una funcionalidad crítica.
 El software en cada canal es desarrollado en diferentes lenguajes
de programación por diferentes equipos.
 Diferentes lenguajes de programación utilizados en sistemas
primarios y secundarios.
Programación de la N Versión

 Múltiples versiones de un sistema de software realizan

cálculos al mismo tiempo. Debe haber un número impar
de computadoras involucradas, típicamente 3.
 Los resultados se comparan utilizando un sistema de
votación y el resultado mayoritario se considera el
resultado correcto.
 Enfoque derivado de la noción de redundancia triple
modular, tal como se utiliza en sistemas de hardware.
Tolerancia a Fallos del Hardware

 Depende de la redundancia triple-modular (TMR).

 Hay tres componentes idénticos replicados que reciben la
misma entrada y cuyas salidas se comparan.
 Si una salida es diferente, se ignora y se asume una falla
del componente.
 Basado en la mayoría de las fallas resultantes de fallas de
componentes en lugar de fallas de diseño y una baja
probabilidad de fallas de componentes simultáneas.
Redundancia Triple-Modular (TMR)
Programación N Versión
Programación N Versión

 Las diferentes versiones del sistema están diseñadas e

implementadas por diferentes equipos. Se asume que hay
una baja probabilidad de que cometan los mismos errores.
Los algoritmos utilizados deben pero no pueden ser
diferentes.
 Existe cierta evidencia empírica de que los equipos
comúnmente malinterpretan las especificaciones de la
misma manera y eligen los mismos algoritmos en sus
sistemas.
Diversidad de Software

 Los enfoques para la tolerancia a fallas de software

dependen de la diversidad de software donde se supone
que las diferentes implementaciones de la misma
especificación de software fallarán de diferentes
maneras.
 Se supone que las implementaciones son (a)
independientes y (b) no incluyen errores comunes.
 Estrategias para lograr la diversidad.
 Diferentes lenguajes de programación.
 Diferentes métodos de diseño y herramientas.
 Especificación explícita de diferentes algoritmos.
Problemas con la Diversidad de Diseño

 Los equipos no son culturalmente diversos, por lo que

tienden a abordar los problemas de la misma manera.
 Errores característicos
 Diferentes equipos cometen los mismos errores. Algunas partes de
una implementación son más difíciles que otras, por lo que todos
los equipos tienden a cometer errores en el mismo lugar;
 Errores de especificación;
 Si hay un error en la especificación, esto se refleja en todas las
implementaciones;
 Esto se puede abordar en cierta medida mediante el uso de
múltiples representaciones de especificación.
Dependencia de la Especificación

 Ambos enfoques de la redundancia de software son

susceptibles a errores de especificación. Si la
especificación es incorrecta, el sistema podría fallar
 Este también es un problema con el hardware, pero las
especificaciones del software suelen ser más complejas
que las especificaciones del hardware y más difíciles de
validar.
 Esto se ha abordado en algunos casos mediante el
desarrollo de especificaciones de software separadas de la
misma especificación del usuario.
Mejoras en la Práctica

 En principio, si se puede lograr la diversidad y la

independencia, la programación de varias versiones
conduce a mejoras muy significativas en la confiabilidad y
la disponibilidad.
 En la práctica, las mejoras observadas son mucho menos
significativas, pero el enfoque parece llevar a mejoras de
confiabilidad de entre 5 y 9 veces.
 La pregunta clave es si dichas mejoras valen o no los
considerables costos adicionales de desarrollo para la
programación de varias versiones.
Programación para la
Fiabilidad
Programación Confiable

 Se pueden adoptar buenas prácticas de programación que

ayudan a reducir la incidencia de fallas en los programas.
 Estas prácticas de programación soportan
 Evitar fallos
 Detección de fallas
 Tolerancia a fallos
Guía de Buenas Prácticas para una
Programación Confiable
Pautas de programación fiables

1. Limitar la visibilidad de la información en un programa.

2. Revise todas las entradas para la validez.
3. Proporcionar un controlador para todas las excepciones
4. Minimizar el uso de construcciones propensas a errores.
5. Proporcionar capacidades de reinicio.
6. Compruebe los límites de la matriz.
7. Incluir tiempos de espera al llamar a componentes externos.
8. Nombra todas las constantes que representan valores del mundo real.
(1) Limitar la Visibilidad de la
Información en un Programa
 A los componentes del programa solo se les debe permitir
el acceso a los datos que necesitan para su
implementación.
 Esto significa que la corrupción accidental de partes del
estado del programa por estos componentes es imposible.
 Puede controlar la visibilidad utilizando tipos de datos
abstractos donde la representación de los datos es privada
y solo permite el acceso a los datos a través de
operaciones predefinidas como get () y put ().
(2) Revise Todas las Entradas para la
Validez
 Todo el programa toma entradas de su entorno y hace
suposiciones sobre estas entradas.
 Sin embargo, las especificaciones del programa rara vez
definen qué hacer si una entrada no es consistente con
estas suposiciones.
 En consecuencia, muchos programas se comportan de
manera impredecible cuando se presentan con entradas
inusuales y, en ocasiones, son amenazas a la seguridad del
sistema.
 Por lo tanto, siempre debe verificar las entradas antes de
procesar las suposiciones hechas sobre estas entradas.
Chequeos de Validez
 Controles de rango
 Compruebe que la entrada se encuentre dentro de un rango
conocido.
 Verificaciones de tamaño
 Compruebe que la entrada no exceda un tamaño máximo, por
ejemplo, 40 caracteres para un nombre.
 Verificaciones de representación
 Verifique que la entrada no incluya caracteres que no deban ser
parte de su representación, por ejemplo. Los nombres no incluyen
números.
 Controles de razonabilidad
 Use la información sobre la entrada para verificar si es razonable
en lugar de un valor extremo.
(3) Proporcionar un Controlador Para
Todas las Excepciones
 Una excepción de programa es un error o algún evento
inesperado, como un fallo de alimentación.
 Las construcciones de manejo de excepciones permiten
que dichos eventos se manejen sin la necesidad de una
verificación continua del estado para detectar
excepciones.
 El uso de construcciones de control normales para
detectar excepciones requiere la adición de muchas
declaraciones adicionales al programa. Esto agrega una
sobrecarga significativa y es potencialmente propenso a
errores.
Manejo de Excepciones
Manejo de Excepciones

 Tres posibles estrategias de manejo de excepciones.

 Señale a un componente que llama que se ha producido una
excepción y proporcione información sobre el tipo de excepción.
 Realizar algún procesamiento alternativo al procesamiento donde
ocurrió la excepción. Esto solo es posible cuando el controlador de
excepciones tiene suficiente información para recuperarse del
problema que ha surgido.
 Pase el control a un sistema de soporte en tiempo de ejecución
para manejar la excepción.
 El manejo de excepciones es un mecanismo para
proporcionar alguna tolerancia a fallas
(4) Minimizar el Uso de Construcciones
Propensas a errores
 Los fallos del programa son generalmente una
consecuencia del error humano porque los programadores
pierden la pista de las relaciones entre las diferentes
partes del sistema
 Esto se ve agravado por construcciones propensas a
errores en lenguajes de programación que son
intrínsecamente complejos o que no verifican errores
cuando podrían hacerlo.
 Por lo tanto, al programar, debe intentar evitar o al menos
minimizar el uso de estas construcciones propensas a
errores.
Construcciones Propensas a Errores

 Bifurcaciones incondicionales (goto)

 Números de punto flotante
 Inherentemente impreciso. La imprecisión puede llevar a
comparaciones inválidas.
 Punteros
 Los punteros que se refieren a las áreas de memoria incorrecta
pueden dañar los datos. El uso de alias puede hacer que los
programas sean difíciles de entender y cambiar.
 Asignación de memoria dinámica
 La asignación en tiempo de ejecución puede causar un
desbordamiento de memoria.
Construcciones Propensas a Errores

 Paralelismo
 Puede resultar en errores de tiempo sutiles debido a la interacción
imprevista entre procesos paralelos.
 Recursión
 Los errores en la recursión pueden causar un desbordamiento de memoria
a medida que la pila del programa se llena.
 Interrupciones
 Las interrupciones pueden provocar la finalización de una operación
crítica y dificultar la comprensión de un programa.
 Herencia
 El código no está localizado. Esto puede provocar un comportamiento
inesperado cuando se realizan cambios y problemas para comprender el
código.
Construcciones Propensas a Errores

 Uso de Alias
 Usar más de 1 nombre para referirse a la misma variable de
estado.
 Arreglos sin límites
 Los fallos de desbordamiento de búfer pueden ocurrir si no se
realiza una comprobación de límite en las matrices.
 Procesamiento de entrada predeterminado
 Una acción de entrada que se produce independientemente de la
entrada.
 Esto puede causar problemas si la acción predeterminada es
transferir el control a otra parte del programa. Una entrada
incorrecta o deliberadamente maliciosa puede desencadenar un
fallo del programa.
(5) Proporcionar Capacidades de Reinicio

 Para los sistemas que involucran transacciones

prolongadas o interacciones con el usuario, siempre debe
proporcionar una capacidad de reinicio que permita que el
sistema se reinicie después de una falla sin que los
usuarios tengan que rehacer todo lo que han hecho.
 El reinicio depende del tipo de sistema.
 Guarde copias de los formularios para que los usuarios no tengan
que rellenarlos nuevamente si hay un problema.
 Guardar el estado periódicamente y reiniciar desde el estado
guardado
(6) Compruebe los Límites de la Matriz

 En algunos lenguajes de programación, como C, es posible

dirigirse a una ubicación de memoria fuera del rango
permitido en una declaración de matriz.
 Esto conduce a la conocida vulnerabilidad de "búfer
acotado" donde los atacantes escriben código ejecutable
en la memoria al escribir deliberadamente más allá del
elemento superior en una matriz.
 Si su idioma no incluye la verificación de límites, por lo
tanto, siempre debe verificar que el acceso a una matriz
esté dentro de los límites de la matriz.
(7) Incluir Tiempos de Espera al Llamar a
Componentes Externos
 En un sistema distribuido, la falla de una computadora
remota puede ser "silenciosa" para que los programas que
esperan un servicio de esa computadora nunca puedan
recibir ese servicio o cualquier indicación de que ha
habido una falla.
 Para evitar esto, siempre debe incluir tiempos de espera
en todas las llamadas a componentes externos.
 Después de que haya transcurrido un período de tiempo
definido sin respuesta, su sistema debe asumir un error y
tomar las medidas necesarias para recuperarse de esto.
(8) Nombre Todas las Constantes que
Representen Valores del Mundo Real
 Proporcione siempre constantes que reflejen los valores
del mundo real (como las tasas impositivas) en lugar de
usar sus valores numéricos y siempre se refieren a ellos
por su nombre.
 Es menos probable que cometa errores y escriba el valor
incorrecto cuando está usando un nombre en lugar de un
valor.
 Esto significa que cuando estas "constantes" cambian (de
seguro, no son realmente constantes), entonces solo tiene
que hacer el cambio en un lugar de su programa.
Mediciones de Fiabilidad
Mediciones de Fiabilidad
 Para evaluar la fiabilidad de un sistema, debe recopilar
datos sobre su funcionamiento. Los datos requeridos
pueden incluir:
 El número de fallas del sistema dado un número de solicitudes de
servicios del sistema. Esto se utiliza para medir el POFOD. Esto se
aplica independientemente del tiempo durante el cual se hacen
las demandas.
 El tiempo o el número de transacciones entre fallas del sistema
más el tiempo total transcurrido o el número total de
transacciones. Esto se utiliza para medir ROCOF y MTTF.
 El tiempo de reparación o reinicio después de una falla del sistema
que lleva a la pérdida del servicio. Esto se utiliza en la medición
de la disponibilidad. La disponibilidad no solo depende del tiempo
entre fallas, sino también del tiempo requerido para que el
sistema vuelva a funcionar.
Pruebas de Fiabilidad

 Las pruebas de confiabilidad (pruebas estadísticas)

implican ejecutar el programa para evaluar si ha
alcanzado o no el nivel de confiabilidad requerido.
 Normalmente, esto no puede incluirse como parte de un
proceso de prueba de defectos normal porque los datos
para la prueba de defectos son (generalmente) atípicos de
los datos de uso real.
 Por lo tanto, la medición de confiabilidad requiere un
conjunto de datos especialmente diseñado que replique el
patrón de entradas que debe procesar el sistema.
Pruebas Estadísticas

 Prueba de Software para confiabilidad en lugar de

detección de fallas.
 La medición del número de errores permite predecir la
confiabilidad del software. Tenga en cuenta que, por
razones estadísticas, se deben inducir más errores que los
permitidos en la especificación de confiabilidad.
 Se debe especificar un nivel aceptable de confiabilidad y
se debe probar y modificar el software hasta que se
alcance ese nivel de confiabilidad.
Mediciones de Fiabilidad
Problemas con las Mediciones de
Fiabilidad
 Incertidumbre del perfil operacional
 El perfil operativo puede no ser un reflejo preciso del uso real del
sistema.
 Altos costos de generación de datos de prueba.
 Los costos pueden ser muy altos si los datos de prueba para el sistema no
se pueden generar automáticamente.
 Incertidumbre estadística
 Necesita una cantidad estadísticamente significativa de fallas para
calcular la confiabilidad, pero los sistemas altamente confiables rara vez
fallarán.
 Reconociendo el fracaso
 No siempre es obvio cuando se produce un error, ya que puede haber
interpretaciones conflictivas de una especificación.
Perfil Operacional

 Un perfil operacional es un conjunto de datos de prueba

cuya frecuencia coincide con la frecuencia real de estas
entradas del uso "normal" del sistema. Es necesaria una
coincidencia cercana con el uso real, de lo contrario, la
confiabilidad medida no se reflejará en el uso real del
sistema.
 Puede generarse a partir de datos reales recopilados de
un sistema existente o (más a menudo) depende de
suposiciones sobre el patrón de uso de un sistema.
Un Perfil Operacional
Generación de Perfil Operacional

 Debe generarse automáticamente siempre que sea

posible.
 La generación automática de perfiles es difícil para los
sistemas interactivos.
 Puede ser sencillo para las entradas "normales", pero es
difícil predecir las entradas "improbables" y crear datos de
prueba para ellas.
 Se desconoce el patrón de uso de los nuevos sistemas.
 Los perfiles operativos no son estáticos, pero cambian a
medida que los usuarios aprenden sobre un nuevo sistema
y cambian la forma en que lo utilizan.
En Resumen

 La confiabilidad del software puede lograrse evitando la

introducción de fallas, detectando y eliminando fallas
antes del despliegue del sistema e incluyendo facilidades
de tolerancia a fallas que permiten que el sistema
permanezca operativo después de que una falla haya
causado una falla del sistema.
 Los requisitos de confiabilidad se pueden definir
cuantitativamente en la especificación de requisitos del
sistema.
 Las métricas de confiabilidad incluyen probabilidad de
falla bajo demanda (POFOD), tasa de ocurrencia de falla
(ROCOF) y disponibilidad (AVAIL).
En Resumen

 Los requisitos de fiabilidad funcional son requisitos para la

funcionalidad del sistema, como los requisitos de
verificación y redundancia, que ayudan al sistema a
cumplir sus requisitos de fiabilidad no funcionales.
 Las arquitecturas de sistema confiables son arquitecturas
de sistema que están diseñadas para tolerancia a fallas.
 Hay una serie de estilos arquitectónicos que admiten la
tolerancia a fallos, incluidos los sistemas de protección,
las arquitecturas de autocontrol y la programación en N
versiones.
En Resumen

 La diversidad de software es difícil de lograr porque es

prácticamente imposible asegurar que cada versión del
software sea verdaderamente independiente.
 La programación confiable se basa en incluir la
redundancia en un programa para verificar la validez de
las entradas y los valores de las variables del programa.
 Las pruebas estadísticas se utilizan para estimar la
confiabilidad del software. Se basa en probar el sistema
con datos de prueba que coinciden con un perfil
operacional, que refleja la distribución de entradas al
software cuando está en uso.