CARRERA: TECNICO SUPERIOR EN SISTEMAS INFORMATICOS

TEMA: DESARROLLO DE SISTEMAS CRITICOS

MATERIA: INGENIERIA DE SOFTWARE
DOCENTE: Lic. DIOEGENES PONCE
ESTUDIANTES: GIAN VIDAL FLOWER
HADE NOEMI LOAYZA MAMANI
GRUPO: SIM-008
GESTION: 2017
Los fallos de funcionamiento del software son relativamente comunes. En la mayora de los casos, estos
fallos provocan molestias. Sin embargo, en algunos sistemas un fallo de funcionamiento puede ocasionar
prdidas econmicas significativas, dao fsico o amenazas a la vida humana. Estos sistemas se conocen
como sistemas crticos.
 SISTEMAS CRITICOS

Los sistemas crticos son sistemas tcnicos o socio-tcnicos de los cuales dependen las personas o los
negocios. Si estos sistemas no ofrecen sus servicios de la forma esperada, pueden provocar graves
problemas y prdidas importantes.

Hay tres tipos principales de sistemas crticos:

Sistemas de seguridad crticos: Son sistemas cuyo fallo de funcionamiento puede provocar perjuicio,
prdida de vidas o daos graves al medio ambiente.

Sistemas de misin crticos: Son sistemas cuyo fallo de funcionamiento puede provocar errores en
algunas actividades dirigidas por objetivos.

Sistemas de negocio crticos: Son sistemas cuyo fallo de funcionamiento puede provocar costes muy
elevados para el negocio que utiliza un sistema de este tipo.

La propiedad ms importante de un sistema crtico es su confiabilidad. El trmino confiabilidad fue

propuesto por Laprie (Laprie, 1995) para hacer referencia a las siguientes propiedades relacionadas de los
sistemas: disponibilidad, fiabilidad, seguridad y proteccin.

Existen varias razones por las que la confiabilidad es la propiedad ms importante de los sistemas crticos:

Los sistemas que son no fiables, inseguros o desprotegidos son rechazados a menudo por sus usuarios. Si los
usuarios no confan en un sistema, se negarn a utilizarlo. Es ms , tambin rehusarn comprar o utilizar
productos de la misma compaa que produjo el sistema no confiable, puesto que creen que stos
tampoco son confiables.

Los costes de los fallos de funcionamiento del sistema pueden ser enormes. En algunas aplicaciones, como
un sistema de control de reactores o un sistema de navegacin area, el coste de un fallo en el sistema es
mayor en varios rdenes de magnitud que el coste de dicho sistema de control.

Los sistemas no confiables pueden provocar prdida de informacin. Es muy cara la captura y
mantenimiento de los datos; algunas veces cuesta ms que el sistema informtico que los procesa. Se
tiene que hacer un gran esfuerzo e invertir mucho dinero para duplicar los datos importantes a fin de
protegerlos de cualquier corrupcin.
El elevado coste de un fallo de funcionamiento en los sistemas crticos implica que se deben usar mtodos
y tcnicas confiables en su desarrollo. Como consecuencia, los sistemas crticos generalmente se desarrollan
utilizando tcnicas muy probadas en lugar de tcnicas novedosas que no han sido objeto de una extensa
experiencia prctica. En vez de utilizar mtodos y tcnicas novedosas, los desarrolladores de sistemas
crticos son conservadores por naturaleza. Prefieren utilizar tcnicas antiguas cuyas ventajas e
inconvenientes son muy conocidos, en lugar de nuevas tcnicas que aparentemente son mejores pero
cuyos problemas a largo plazo se desconocen.

Para el desarrollo de sistemas crticos, a menudo se utilizan tcnicas de ingeniera del software que por lo
general no son rentables. Una razn por la que se usan estos mtodos formales es que ayudan a reducir
la cantidad de pruebas requeridas. Para sistemas crticos, los costes de verificacin y validacin
generalmente son muy elevados ms del 50% de los costes totales de desarrollo del sistema.

Si bien un nmero reducido de sistemas se pueden automatizar completamente, la mayora de los sistemas
crticos son sistemas socio-tcnicos en los que las personas monitorizan y controlan el funcionamiento de
dichos sistemas informticos. Los costes de un fallo de funcionamiento de los sistemas crticos
generalmente son tan altos que es necesario contar con personal adicional en el sistema que pueda hacer
frente a situaciones inesperadas, y que pueda recuperar el funcionamiento normal del sistema cuando las
cosas van mal.

Desde luego, a pesar de que los operadores del sistema pueden ayudar a recuperarlo cuando algo va mal,
ellos mismos a su vez pueden generar problemas si cometen errores. Existen tres tipos de componentes
de sistemas susceptibles de generar un fallo en el sistema:

El hardware del sistema puede fallar debido a errores en su diseo, tambin debido a que los
componentes fallan como resultado de errores de fabricacin, o debido a que dichos
componentes han llegado al final de su vida til.

El software del sistema puede fallar debido a errores en su especificacin, diseo o implementacin.

Los operadores del sistema pueden provocar fallos en el sistema debido a un uso incorrecto del
mismo. As como el hardware y el software son cada vez ms fiables, hoy en da los fallos debidos a
un mal uso del sistema son probablemente la principal causa de fallos de funcionamiento en el
sistema.

Estos fallos pueden interrelacionarse. Un componente hardware que deja de funcionar puede implicar
que los operadores del sistema tengan que afrontar una situacin inesperada y una carga de trabajo
adicional. Esto hace que los operadores trabajen en estado de estrs y las personas que sufren estrs a
menudo cometen errores. Esto puede ocasionar que el software falle, lo que supone ms trabajo para los
operadores, ms estrs, y as sucesivamente.

Como resultado de todo lo anterior, es particularmente importante que los diseadores de los sistemas
crticos adopten una perspectiva holstica del sistema en lugar de centrarse en un nico aspecto del
mismo. S el hardware, el software y las formas de utilizacin del sistema se disean de forma separada sin
tener en cuenta los puntos dbiles potenciales del resto de las partes del sistema, entonces ser ms
probable que los errores se produzcan en las interfaces entre las distintas partes del sistema.
DESARROLLO DE SISTEMAS CRITICOS

Los sistemas crticos tales como aquellos que controlan maquinaria automtica, sistemas mdicos, centrales
de comunicacin o aviones necesitan niveles ms altos de confiabilidad.

Existen aproximaciones complementarias para desarrollar software confiable:

Prevencin de defectos.- El proceso de diseo e implementacin del sistema debera utilizar
aproximaciones al desarrollo del software que ayuden a evitar errores de programacin y as
minimizar el nmero de defectos en un programa.
Deteccin de defectos.- Los procesos de verificacin y validacin se disean para descubrir y validar
defectos en un programa antes de que ste sea desplegado para su uso.
Tolerancia a defectos.- El sistema se disea para que los defectos o comportamientos inesperados
del sistema durante la ejecucin sean detectados y gestionados de tal forma que no ocurran fallos
de funcionamiento.

Resulta fundamental, para conseguir la confiabilidad en cualquier sistema, nociones bsicas sobre
redundancia y diversidad.

Los sistemas crticos pueden incluir componentes que reproducen la funcionalidad de otros componentes o
cdigo de comprobacin adicional que no es estrictamente necesario para que el sistema funcione es
redundancia. Si los componentes redundantes no son exactamente iguales que otros componentes es
diversidad, aadir diversidad y redundancia a los sistemas los hacen ms complejos por lo tanto ms
difciles de entender.

El software libre de defectos es aquel software que cumple exactamente con su especificacin, sin embargo
esto no significa que el software nunca llegue a fallar ya que puede haber errores en la especificacin que se
refleja en el software o los usuarios pueden no comprender o no usar correctamente el sistema software.
Para sistemas de tamao pequeo y medio, las tcnicas de ingeniera de software son tales que
probablemente sea posible desarrollar software libre de defectos, para alcanzar este objetivo es necesario
utilizar varias tcnicas de ingeniera del software:

Procesos software confiable.- El uso de un proceso software confiable con actividades de

verificacin y validacin adecuadas resulta esencial si tiene que minimizarse el nmero de defectos
en el programa y tiene que detectarse aquellos que se produzcan.
Gestin de calidad.- La organizacin que desarrolla el sistema debe tener una cultura en la que la
calidad guie el proceso software. Esta cultura debera motivar al desarrollo de software libre de
errores y debera establecer estndares de diseo y desarrollo, as como procedimientos para
comprobar que dichos estndares se cumplen.
Especificacin formal.- debe realizarse una especificacin del sistema precisa que defina el sistema
que se va a implementar. Muchos errores de diseo y programacin son el resultado de una mala
interpretacin de una especificacin ambigua o pobremente redactada.
 Verificacin esttica.- Las tcnicas de verificacin estticas como el uso de analizadores estticos
pueden encontrar caractersticas anmalas en el programa que podran ser defectos.
Tipado fuerte.- Para el desarrollo se debe usar un lenguaje de programacin fuertemente tipado,
como Java, si el lenguaje es fuertemente tipado, el compilador del lenguaje puede detectar
muchos errores de programacin antes de que puedan ser introducidos en el programa a entregar.
Programacin segura.- Algunas construcciones de lenguaje de programacin son ms complejas y
propensas a error que otras, y es ms probable que se cometan errores si se usan. La
programacin segura significa evitar o al menos minimizar el uso de estas construcciones.
Informacin protegida.- Debera utilizarse una aproximacin para el diseo e implementacin del
software basada en la ocultacin y encapsulamiento de la informacin.

A medida que el software se hace ms fiable se necesita emplear ms y ms tiempo y esfuerzo para
encontrar menos y menos defectos. En algn momento, los costes de este esfuerzo para encontrar menos y
menos defectos se convierten en justificables. Como consecuencia las compaas desarrolladoras de
software siempre tendrn algn defecto residual.

Procesos confiables
Los procesos confiables estn adaptados a la prevencin y deteccin de defectos. Los procesos confiables
estn definidos y son repetibles, e incluyen una variedad de actividades de verificacin y validacin.

Un proceso bien definido es un proceso que ha sido estandarizado y documentado.

Un proceso repetible es aquel que no depende de un juicio e interpretacin individual,
independientemente de la gente implicada en el proceso.

Un proceso confiable debera incluir siempre actividades de verificacin y validacin bien planificadas y
organizadas cuyo objetivo es asegurar el descubrimiento de defectos residuales en el software antes de que
ste sea desplegado. Las actividades del proceso que se llevan a cabo para prevenir y detectar los defectos
son:

Inspeccin de requerimientos.- Estas pretenden descubrir problemas en la especificacin del

sistema. Una proporcin elevada de defectos en el software entregado es consecuencia de errores
en los requerimientos. Si estos pueden descubrirse y eliminarse de la especificacin entonces esta
clase de defectos se minimizaran.
Gestin de requerimientos.- Est relacionada con la realizacin de un seguimiento de los cambios
en los requerimientos y extender dicho seguimiento a lo largo del diseo y la implementacin.
Muchos errores en los sistemas entregados son el resultado de no asegurar que realmente se
incluya un cambio de requerimientos en el diseo e implementacin del sistema.
Verificacin de modelos.- La verificacin de modelos implica el uso de herramientas CASE para
analizar los modelos del sistema y asegurar su consistencia interna y externa.
La consistencia interna significa que un modelo del sistema es consistente.
La consistencia externa significa que diferentes modelos del sistema por ejemplo un
modelo de estados y un modelo de objetos son consistentes.
Inspecciones de diseo y cdigo.- las inspecciones de diseo y cdigo frecuentemente se basan en
lneas de verificacin de defectos comunes y pretenden descubrir y eliminar estos defectos antes de
la prueba del sistema.
Anlisis esttico.- El anlisis esttico es una tcnica automtica de anlisis de programas en la que
el programa se analiza con detalle para encontrar condiciones potencialmente errneas.
 Planificacin y gestin de las pruebas.- Debera disearse un conjunto completo de pruebas para el
sistema y gestionar cuidadosamente el proceso de pruebas para asegurar una cobertura completa
de las pruebas y el seguimiento de los requerimientos y el diseo del sistema a travs de las
pruebas.

Programacin confiable
La programacin confiable implica el uso de tcnicas y construccin de programacin que contribuyen a
prevenir y tolerar los defectos. Mientras que algunos errores tienen lugar debido a que los programadores
cometen errores o a malas interpretaciones de la especificacin, otros tienes lugar debido a la complejidad
de los programas o al uso de construcciones propensas a error, para alcanzar la confiabilidad sera preciso
realizar diseos simples, proteger la informacin de accesos no autorizados y minimizar el uso de
construcciones de programacin no seguras.

Las tcnicas de programacin para la prevencin de defectos se basan en el hecho de que hay una distincin
entre defectos y fallos de ejecucin.
Un fallo de ejecucin es algo que es observable para los usuarios de un sistema.
Un defecto de ejecucin es una caracterstica interna del sistema.
Si un defecto se manifiesta en un programa en ejecucin es posible tolralo detectndolo y realizando la
accin de recuperacin antes de que se convierta en un fallo de ejecucin del sistema.

Informacin protegida
Es la proteccin de los datos del sistema, es decir que los componentes del programa deberan tener acceso
solo a los datos que necesitan para su implementacin de ese modo pueden protegerse otros datos y
ocultarlos desde otra partes del programa ya que si se oculta informacin esta no puede llegar a ser
corrompida por los componentes del programa que se supone no la utilizan.

La proteccin de informacin es mucho ms sencilla en Java que en lenguajes ms antiguos, debido a que
estos lenguajes no tienen construcciones de encapsulacin tales como clases de objetos. Generalmente
cuando se programa en lenguaje orientado a objetos, proporciona mtodos que acceden a estos atributos
directamente, esto significa que puede cambiarse la representacin del atributo sin preocuparse de cmo
otros objetos utilizan el atributo, es importante utilizar esta aproximacin para estructuras de datos y otros
atributos complejos.

La construccin de definiciones de interfaces Java hace posible utilizar esta aproximacin y es posible
declarar la interfaz de un objeto sin hacer referencia a su implementacin.

Los usuarios de los objetos de tipo Queue pueden

insertar objetos en la cola, eliminarlos de la cola y
consultar el tamao de la cola, sin embargo en la
clase que implementa esta interfaz la
implementacin real debera ocultarse declarando
los atributos y mtodos como particulares de esa
clase de objetos.

Una especificacin de una cola utilizando

una declaracin de interfaz Java.
Otro tipo de proteccin de proteccin de informacin: en situaciones en las que un conjunto de valores
limitados puede asignarse a alguna variable, esto valores deberan declarase como contantes. Lenguajes
tales como C soportan tipos enumerados, pero en Java esto debe implementarse asociando estas
restricciones con la declaracin de la clase.

Consideremos un sistema de sealizacin, implementando en Java que soporte luces rojas, amarillas y
verdes, debera definirse un tipo Signal que incluya declaraciones de constantes que reflejan estos colores,
por lo tanto es posible hacer referencia a Signal.red, Signal.yellow, Signal.green y asi sucesivamente,esto
evitara asignaciones de valores incorrectos a las variable de tipo Signal.

Class Signal {
Por lo tanto, se estn protegiendo variables de
tipo Signal de asignaciones incorrectas y al
static public final int red=1 ;
mismo tiempo ocultando la representacin de static public final int yellow=2 ;
rojo, amarillo y verde. Pueden cambiarse estos static public final int green=3 ;
valores constantes ms tarde sin tener que
realizar ningn otro cambio en el programa.
public int sigState ;

}
Una declaracin de una seal en JAVA que oculta el
tipo de representacin.

Programacin segura
La sentencia Goto o salto incondicional era una construccin de programacin propensa a error. Esta
observacin condujo al desarrollo de la programacin estructurada, este tipo de programacin es sin
sentencias Goto utilizando solamente bucles while y sentencias if como construcciones de control y un
diseo mediante una aproximacin descendente.

Es menos probable introducir defectos en los programas si se evitan o al menos se usan lo menos posible,
las construcciones potencialmente propensas a error, estas comprenden:
Nmeros en coma flotante.- Los nmeros en coma flotante son imprecisos, este es un problema
particular cuando hay comparaciones debido a que la imprecisin en la representacin puede
llevar a comparaciones incorrectas.
Punteros.- Los punteros son construcciones de bajo nivel que almacenan direcciones que hacen
referencia directamente a zonas de memoria de la mquina.
Asignacin dinmica de memoria.- La memoria del programa puede asignarse en tiempo de
ejecucin en lugar de en tiempo de compilacin.
 Paralelismo.- El paralelismo es peligroso debido a las dificultades de predecir los efectos sutiles de
las interacciones temporales entre los procesos en paralelo. Los problemas temporales
normalmente no pueden detectarse mediante la inspeccin de programa, el paralelismo puede
ser inevitable pero su uso debera ser cuidadosamente controlado para minimizar las
dependencias entre los procesos.
Recursin.- LA recursin se produce cuando un proceso o mtodo se llama a s mismo o llama
otro procedimiento, el cual a su vez llama al procedimiento original que realizo la llamada. Su uso
puede generar programas concisos, pero puede ser difcil seguir la lgica de los programas
recursivos, por lo tanto los errores de programacin son ms difciles de detectar.
Interrupciones.- Son un modo de forzar la transferencia de control a una seccin de cdigo
independientemente del cdigo que se est ejecutando actualmente, pero la interrupcin puede
provocar la terminacin de una operacin crtica.
Herencia.- el problema de la herencia en la programacin orientada a objetos es que el cdigo
asociado con el objeto no est todo en un mismo sitio, esto hace ms difcil comprender el
comportamiento del objeto.
Aliasing.- Esto ocurre cuando se utiliza ms de un nombre para referir a la misma entidad en un
programa.
Vectores no limitados.- Los vectores son formas de acceder a la memoria y pueden hacerse
asignaciones ms all del final de un vector. El soporte de ejecucin del sistema no comprueba
que las asignaciones realmente se refieren a los elementos del vector. Una vulnerabilidad
conocida de la proteccin es el desbordamiento del bfer en el que un intruso deliberadamente
desarrolla un programa para escribir en la memoria ms all del final de un bfer que se
implementa como un vector.
Procesamiento de entradas por defecto.- Algunos sistemas proporcionan un procesamiento de las
entradas por defecto independientemente de las entrada presentada al sistema, esto es un
agujero en la proteccin, que un intruso puede aprovechar para presentar al programa entradas
no esperadas y que no sean rechazadas por el sistema.

Todas estas construcciones y tcnicas son tiles, pero tienen que utilizarse con cuidado siempre y cuando
sea posible, sus potenciales efectos peligrosos deberan controlarse utilizndolos dentro de tipos abstractos
de datos u objetos, estos actan limitando el dao ocasionado si se producen errores.

Manejo de excepciones
Los errores o eventos no esperados ocurren inevitablemente, esto puede darse debido a un defecto en el
programa o puede ser el resultado de circunstancias externas no predecibles. Un error o un evento
inesperado que ocurra durante la ejecucin de un programa se denominan una excepcin, esta puede ser
provocada por condiciones de hardware o software. Cuando ocurre una excepcin, esta debe ser manejada
por el sistema, esto puede hacerse dentro del mismo programa o puede implicar la transferencia de control
a un mecanismo de manejo de excepciones del sistema.
Algunos lenguajes de programacin como Java, C , incluyen construcciones que soportan el manejo de
excepciones de forma que no se necesitan sentencias condicionales adicionales para comprobar las
excepciones, en su lugar el lenguaje de programacin incluye un tipo de construccin especial, con
frecuencia llamado Exception y diferentes excepciones pueden declararse con este tipo. Cuando ocurre una
situacin excepcional, la excepcin es capturada y el soporte de ejecucin del lenguaje transfiere el control
a un manejador de excepciones adecuadas para manejar cada excepcin.

En Java pueden declararse nuevos tipos de excepciones extendiendo la clase Exception, las excepciones son
provocadas en Java utilizando una sentencia throw. El manejador de una excepcin se indica por la palabra
clave catch, seguida por un bloque de cdigos que maneja la excepcin.

Esta clase Java es una implementacin de un congelador de temperatura de un congelador de comida. La

temperatura requerida puede fijarse entre -18 y -40 grados Celsius, la comida congelada puede comenzar a
descongelarse y las bacterias se vuelven activas a temperaturas por encima de -18 grados.

El sistema de control mantiene la temperatura alternando el encendido y apagado de una bomba

refrigerante de acuerdo con el valor de un sensor de temperatura, si la temperatura requerida no puede
mantenerse, el controlador dispara una alarma.

En la implementacin Java, la temperatura

del congelador se obtiene interrogando a un
objeto denominado tempSensor, y la
temperatura requerida se obtiene
inspeccionando un objeto denominado
temDial. Un objeto bomba (Pump) responde
a las seales para cambiar su estado, una vez
que la bomba ha sido encendida, el sistema
espera durante algn tiempo (llamado a
Thread.sleep) para que la temperatura se
reduzca, si no ha sido disminuido
suficientemente se lanza una excepcin
denominada FreezerTooHotException.

El manejador de excepciones (situado al final

del cdigo catch) captura esta excepcin y
activa el objeto Alarm, tambin se incluye un
manejador para la excepcin
InterrupmtedException que puede ser
provocada por Thread.sleep, este registra la
excepcin y a continuacin vuelve a provocar
la excepcin para su manejo en el mtodo
principal.
Tolerancia a defectos

Un sistema tolerante a defectos puede continuar en funcionamiento despus de que se manifiesten algunos
defectos en el programa, los mecanismos de tolerancia a defectos en el sistema aseguran que estos
defectos del sistema no provocan fallos de funcionamiento del sistema. Se necesita tolerancia a defectos en
situaciones en las que un fallo de funcionamiento del sistema podra provocar un accidente catastrfico o
en las que una prdida de funcionamiento del sistema pudiese causar grandes prdidas econmicas. Existen
cuatro aspectos a considerar en la tolerancia a defectos:

Deteccin de defectos.- El sistema debe detectar un defecto que podra conducir a un fallo de
ejecucin del sistema. Generalmente esto implica comprobar que el estado del sistema es
consistente.
Evaluacin de los daos.- Se deben detectar las partes del estado del sistema que han sido
afectadas por el defecto.
Recuperacin de defectos.- El sistema debe restaurar su estado a u estado <<seguro>> conocido.
Esto puede conseguirse corrigiendo el estado daado (recuperacin de errores hacia adelante) o
restaurando el sistema a un estad <<seguro>> conocido (recuperacin de errores hacia atrs).
Reparacin de defectos.- Esto implica modificar el sistema para que no vuelva a aparecer el
defecto. Sin embargo muchos defectos del software se manifiestan como estados transitorios, no es
necesario realizar ninguna reparacin y el procesamiento normal puede continuarse
inmediatamente despus de la recuperacin de los defectos.

Si no hay defectos en el sistema podra parecer que no hay ninguna posibilidad de un fallo de ejecucin del
sistema, pero libre de defectos no significa libre de fallos de ejecucin.

Deteccin de defectos y evaluacin de daos

La primera etapa de la tolerancia a defectos es detectar que un defecto (un estado del sistema errneo) ha
ocurrido u ocurrir a menos que se realice inmediatamente alguna accin. Existen dos tipos de deteccin de
defectos que se pueden utilizar.

Deteccin de defectos preventiva.- El mecanismo de defectos se inicia antes de que se produzca un

cambio en el estado. Si se detecta un estado potencialmente errneo, entonces el cambio de
estado no se realiza.
Deteccin de defectos retrospectiva.- El mecanismo de deteccin de defectos se inicia despus de
que el estado del sistema ha sido cambiado para comprobar si ha tenido lugar un defecto. Si se
descubre un defecto, se provoca una excepcin y se utiliza un mecanismo de reparacin para
recuperarse de ese efecto.
En Java la forma ms segura de implementar la deteccin de defectos preventiva es comprobar la presencia
de defectos y utilizar el mecanismo de manejo de excepciones en el lenguaje para indicar que un estado
errneo del sistema ha sido detectado.

La deteccin de defectos preventiva es posible cuando se conoce el rango de valores que pueden asignarse
a una variable de estado. Sin embargo cuando un valor valido depende del valor asignado a otro valor
asignado a otras variables en el estado, la deteccin de defectos preventiva puede muy difcil.

Una forma de implementar la deteccin de defectos retrospectiva en Java consiste en asociar una funcin
comprobado con un objeto. Esta funcin puede llamarse despus de que los cambios en el estado hayan
tenido lugar para asegurar que se cumplan las restricciones del estado, estas pueden llamarse cuando sea
necesario (puede que no sea necesario comprobar el estado despus de cada cambio haya tenido lugar)

Interfaz que puede ser utilizada para funciones de comprobacin.

Los objetos a comprobar son instancias de una clase de objetos que implementan esta interfaz, por lo que
cada objeto tiene una funcin de comprobacin asociada. Cada clase de objetos implementan su propia
funcin de comprobacin que define las restricciones particulares que se aplican a los objetos de esa clase,
cuando se comprueba un estado en su totalidad se utiliza enlaces dinmicos para asegurar que se aplica la
funcin de comprobacin adecuada para la clase de objeto que se est comprobando.

La funcin check comprueba que los elementos de un vector satisfacen alguna restriccin.

La evaluacin de daos implica analizar el estado del sistema para estimar el alcance de la corrupcin del
estado, la evaluacin de daos es necesaria cuando no se puede evitar realizar un cambio de estado o
cuando un defecto tiene lugar por una secuencia invalida de cambios de estado correctos individualmente.

Otras tcnicas de deteccin de defectos y de evaluacin de daos depende de la representacin de los

estados del sistema y del tipo de aplicacin estas tcnicas de evaluacin de daos incluyen:

El uso de comprobaciones de cdigo y sumas de verificacin en las comunicaciones de datos y

comprobaciones de dgitos en datos numricos.
El uso de enlaces redundantes en estructuras de datos que contienen punteros.
El uso de temporizadores en sistemas concurrentes.
Recuperacin y reparacin de defectos

La recuperacin de defectos es el proceso de modificar el espacio de estados del sistema para que los
efectos del defecto sean eliminados o reducidos. La recuperacin hacia adelante implica intentar corregir el
sistema daado y crear el estado esperado. La recuperacin hacia atrs restaura el estado del sistema a un
estado <<correcto>> conocido.

La recuperacin de errores hacia adelante solo es posible en situaciones en las que la informacin del
estado incluye redundancia. Existen dos situaciones generales en las que pueden aplicarse tcnicas de
recuperacin de errores:

Cuando los datos del cdigo estn daados.- El uso de tcnicas de codificacin que aaden
redundancia a los datos permite corregir los errores as como detectarlo.
Cuando las estructuras enlazadas estn daadas.- Cuando los punteros hacia adelante y hacia
atrs se incluyen en la estructura de datos, la estructura puede volverse a crear. Esta tcnica se
utiliza frecuentemente para sistemas de ficheros y reparacin de base de datos.

La recuperacin de errores hacia atrs es una tcnica que restaura el estado a un estado seguro conocido
despus de haberse detectado un error, la mayora de los sistemas de base de datos incluyen recuperacin
de errores hacia atrs.

Arquitecturas tolerantes a defectos

Para la mayora de los sistemas crticos puede necesitarse una arquitectura especfica del sistema diseada
para soportar la tolerancia a defectos. Durante muchos aos ha habido una necesidad de construir
hardware tolerante a defectos, las tcnicas ms comnmente utilizada de tolerancia a defectos hardware
est basada en la nocin de redundancia modular triple (TMR).

La unidad hardware se reproduce tres veces (o algunas veces ms) , la salida de cada unidad se enva a un
comprobador de salida que normalmente se implementa como un sistema de votaciones, si una de las
unidades falla y no produce la misma salida que el resto de las unidades, se pasa por alto su salida. Un
gestor de defecto puede intentar reparar la unidad defectuosa de forma automtica, pero si esto es
imposible el sistema continua funcionando con dos unidades.

Redundancia modular triple para tratar los fallos de ejecucin del hardware.
Esta aproximacin a la tolerancia a defectos cubre la mayora de fallos de ejecucin del hardware que son el
resultado de fallos en los componentes en lugar de defectos de diseo, por lo tanto es probable que los
componentes fallen de forma independiente. Se supone que cuando son completamente funcionales todas
las unidades hardware funcionan de acuerdo con su especificacin, por lo tanto hay una baja probabilidad
de fallos simultneas en los componentes en todas las unidades hardware.

Si los requerimientos de disponibilidad y fiabilidad de un sistema son tales que se necesita utilizar hardware
tolerante a defectos tambin puede necesitar software tolerante a defectos. Existen dos aproximaciones
relacionadas con la provisin de software tolerante a defectos, estas son:

Programacin con n-versiones.- Utilizando una especificacin comn, el sistema software se

implementa en varias versiones por diversos equipos, estas versiones se ejecutan en paralelo
sobre computadoras diferentes. Sus salidas se comparan utilizando un sistema de votaciones y las
salidas inconsistentes o las que no se producen a tiempo son rechazadas. Al menos deberan estar
disponibles tres versiones del sistema para que dos versiones fuesen consistentes en el caso de que
slo una de ellas fallase. Esta es la aproximacin comnmente ms utilizada para tolerancia
defectos del software.

Programacin con n-versiones

Bloques de recuperacin.- En esta aproximacin, cada componente del programa incluye una
prueba para verificar que el componente se ha ejecutado con xito, tambin incluye cdigo
alternativo que permite que el sistema vuelva hacia atrs y repita los clculos si la prueba detecta
un fallo de ejecucin. De forma delibera, las implementaciones son interpretaciones diferentes de
la misma especificacin. Se ejecutan en secuencia en lugar de en paralelo de forma que no se
requiere la replicacin de hardware.

Bloques de recuperacin
 Bibliografa

Ingeniera de software de Ian Sommerville

http://idsuba.blogspot.com/2014/06/sistemas-criticos.html