Ingenieria_de_confiabilidad_INGENIERIA DEL SOFTWARE

Vista previa del material en texto

CONTENIDO 
 
 TEMAS A DESARROLLAR FUENTE BIBLIOGRÁFICA 
1- Proceso de software - Sommerville I., Cap. 13 
2. Iteración de Procesos 
 
 
 
 
 
 
Curso de Auditorías 3 
“Se interesa por las técnicas 
usadas para mejorar la 
confiabilidad de los sistemas tanto 
críticos como no críticos” 
 
Curso de Auditorías 4 
Evitación de fallas 
en el desarrollo 
-El proceso de diseño 
construcción e 
implementación del software 
debe usar enfoques para el 
desarrollo que ayuden a 
evitar errores en dichas 
etapas. 
-Menos fallas en el desarrollo 
significa menos 
oportunidades de fallas 
durante el tiempo de 
ejecución 
Tolerancia a fallas en 
el desarrollo Detección y corrección de 
fallas en el desarrollo 
- Los procesos de 
verificación y validación se 
diseñan para descubrir y 
eliminar fallas en el 
desarrollo de un programa, 
antes de desplegarlo para 
uso operacional. 
- El sistema se diseña de 
modo que se detectan las 
fallas en el desarrollo o 
comportamiento inesperado 
del sistema en el tiempo de 
ejecución, y se gestionan para 
que no ocurra una falla del 
sistema. 
Curso de Auditorías 5 
-Aplicar técnicas para evitar, detectar y tolerar 
fallas en el desarrollo, conduce a una situación de 
baja de rendimientos. 
-El costo para encontrar y eliminar las fallas en el 
desarrollo restantes en un sistema de software se 
eleva exponencialmente a medidas que se 
descubren y eliminan las fallas del programa 
 
 
Curso de Auditorías 6 
 
 
vvvvvvvvvvv
vvvvvvvvvvv
vvvvvvvvvvv
vvvvvvvvvvv
vvvvvvvvvvv
vvvvvvvvvvv
vvvvvvvvvvv
vvvvvvvvvvv 
Auto 
Casa 
 
Muchos Pocos Muy Pocos 
vvvvvvv
vvvvvvv
vvvvvvv
vvvvvvv
vvvvvvv
vvvvvvv
vvvvvvv
vvvvvvv
vvvvvvv
vvvvvvv
vvvvvvv 
Número de errores residuales 
C
o
st
o
 p
o
r 
er
ro
r 
d
et
ec
ta
d
o
 
Aumento del costo por la eliminación de 
fallas residuales en el desarrollo 
Curso de Auditorías 7 
-Las compañías de desarrollo de software aceptan que 
su software siempre presentará algunas fallas 
residuales . 
-El nivel de fallas depende del sistema (críticos o no 
críticos) 
-La razón para aceptar fallas en el desarrollo es que , 
en caso de falla del sistema, es menos costoso pagar 
por las consecuencias que descubrir y eliminar las 
fallas en el desarrollo antes de entregar el sistema. 
 
 
Curso de Auditorías 8 
Redundancia 
-Significa que en un espacio 
se incluye capacidad de 
respuesta que está disponible 
si falla parte de dicho 
sistema. 
-Por ejemplo en los sistemas 
en los que la confiabilidad es 
crítica, se utilizan servidores 
redundantes. 
Diversidad 
- Son estrategias 
fundamentales para 
aumentar la confiabilidad de 
cualquier tipo de sistema 
-Significa que los 
componentes del sistema son 
de diferentes tipos , lo cual 
también aumenta las 
probabilidades que no fallen 
exactamente de la misma 
forma. 
-Por ejemplo el uso de 
diversos sistemas operativos 
asegura la funcionalidad y 
confiabilidad de los sistemas 
de aplicación. 
Curso de Auditorías 9 
“Los procesos de software 
confiables están diseñados para 
producir software confiable” 
 
- Una compañía que emplea un proceso confiable puede estar segura que el 
proceso se realizó y documentó adecuadamente, y que se utilizaron 
técnicas de desarrollo adecuadas para el diseño de sistemas críticos. 
- La razón para invertir en los procesos confiables es que es probable que un 
buen proceso de software conduzca a entregar un software con menos 
errores y además es menos probable que yerre en su ejecución 
Curso de Auditorías 10 
Curso de Auditorías 11 
 La arquitectura tiene que diseñarse para incluir 
componentes y mecanismos redundantes, que permitan 
cambiar el control de un componente a otro . 
 La realización más simple de una arquitectura confiable está 
en los servidores replicados, cuando dos o más servidores 
realizan la misma tarea. 
 El enfoque de servidores replicados (SR) se usa 
ampliamente para los sistemas de procesamiento de 
transacciones. 
 Los SR proporcionan redundancia aunque no aportan 
diversidad. 
 
Curso de Auditorías 12 
 
 1- Sistemas de protección 
 2- Arquitecturas de automonitorización 
 3- Programación de n-versión 
 4- Diversidad de software 
 
 
Arquitecturas 
 de Sistemas 
 Confiables 
 
Curso de Auditorías 13 
 1- Sistemas de protección (SP) 
- “Son sistemas especializados que se asocian con algún otro 
sistema, por lo general con un sistema de control para 
algunos procesos” 
- Un SP sólo incluye la funcionalidad crítica que se requiere 
para cambiar el sistema de un estado potencialmente 
inseguro a uno seguro (desactivación del sistema). 
- Los SP son un ejemplo más general de una arquitectura 
tolerante a fallas , donde un sistema principal recibe apoyo 
de un sistema de respaldo más pequeño y más simple que 
sólo incluye funcionalidad esencial. 
 
 
 
Curso de Auditorías 14 
- Arquitectura de un sistema de protección 
 
 
Curso de Auditorías 15 
 2- Arquitecturas de automonitorización (AA) 
- “Es una arquitectura de sistema en que éste se diseña para 
monitorizar su propia operación y tomar alguna acción al 
detectar un problema” 
- Esto se logra al realizar cálculos sobre canales separados y 
comparar las salidas de dichos cálculos. 
- Para ser efectivos en la detección de fallas de software y 
hardware los sistemas de automonitorización deben 
diseñarse de forma que: 
 . El hardware y el software utilizado en cada canal sea 
diverso. 
 
 
Curso de Auditorías 16 
 2- Arquitecturas de automonitorización (AA) 
 
 
Curso de Auditorías 17 
 3- Programación n-versión (Multiversión) 
 - Derivan de los sistemas de hardware, en los cuales durante 
años se utilizó la noción de redundancia modular triple 
(TMR) para construir sistemas que son tolerantes a las fallas 
de hardware. 
- En un sistema TMR la unidad de hardware se replica tres o 
más veces . 
- “La salida de cada unidad se pasa a un comparador que 
evalúa todas sus entradas y si dos o más son iguales, 
entonces dicho valor es la salida”. 
 
Curso de Auditorías 18 
 3- Programación n-versión (Multiversión) 
 
Sistema de Redundancia Modular Triple (TMR) 
Curso de Auditorías 19 
 3- Programación n-versión (Multiversión) 
 - Un enfoque similar puede utilizarse para software tolerante 
a fallas, donde n versiones diversas de un sistema de 
software se ejecutan en paralelo 
- Este enfoque de tolerancia a fallos se utiliza en sistemas de 
señalización ferroviaria, sistemas de aeronaves y sistemas 
de protección de reactores 
 
Curso de Auditorías 20 
 3- Programación n-versión (Multiversión) 
 - 
Programación de n-versión 
Curso de Auditorías 21 
 4- Diversidad de Software 
 - Todas las arquitecturas anteriores tolerantes a fallas se apoyan en 
la diversidad del software para lograr tolerancia a fallas. 
- Lo anterior se basa en la suposición que son independientes las 
implementaciones diversas de la misma especificación ( o una 
parte de la especificación para sistemas de protección). 
- No deben incluir errores comunes y además, no fallarán de la 
misma forma al mismo tiempo. 
- Esto requiere que el software lo escriban diferentes equipos y que 
no se comuniquen durante el proceso de desarrollo 
- Lo anterior reduce la posibilidad de malos entendidos o malas 
interpretaciones comunes de la especificación. 
 
Curso de Auditorías 22 
 4- Diversidad de Software 
 - La empresa puede incluir políticas de diversidad que tengan la 
intención de maximizar las diferencias entre versiones delsistema: 
. Exigir que deben usarse diferentes métodos de diseño (OO vs 
Estructurado) 
. Establecer que las implementaciones deben escribirse en en 
distintos lenguajes de prog. (Ada, C++, Java). 
. Requerir el uso de diferentes herramientas y entornos de 
desarrollo para el sistema (Eclipse, Netbeans, etc.) 
. Solicitar explícitamente el uso de diferentes algoritmos en algunas 
partes de la implementación. 
 
 
 
 
Curso de Auditorías 23 
 . Cuando se considera la ingeniería de confiabilidad hay un conjunto 
de Lineamientos de Programación Confiable (LPC) son buenas 
prácticas recomendables aceptadas, que son universales y ayudan 
a reducir las fallas de los sistemas entregados. 
. Los LPC pueden aplicarse en cualquier lenguaje de programación 
que se use para el desarrollo de sistemas. 
 
 
 
Curso de Auditorías 24 
1- Controlar la visibilidad de la información en un programa (A los 
componentes de un programa sólo se les debe dar acceso a los 
datos que necesita para su ejecución) 
2- Comprobar la validez de todas las entradas (comprobación del 
rango, de longitud, de formato, de racionalidad) 
3- Proporcionar un manejador para todas las excepciones (Detectar 
los errores por ej. Overflow, con un IF y enviarlo a una rutina que 
se encargue del error producido) 
4 – Minimizar el uso de códigos proclives a error (go-to, punto 
flotante, pointers, asig. memoria dinámica, paralelismo, etc.) 
5 – Ofrecer capacidades de reinicio (Checkpoints) 
Curso de Auditorías 25 
6 – Comprobar los límites de los arreglos (verificar la longitud de los 
array’s) 
7–Incluir interrupciones (timeout) cuando se soliciten componentes 
externos (Un timeout es una suposición automática que un 
componente solicitado falló y no producirá una respuesta) 
8 –Nombrar todas las constantes que representan valores del 
mundo real (Usar nombres no valores) 
 BIBLIOGRAFÍA 
 
- Sommerville, Ian, Ingeniería del Software,Pearson-Addison Wesley, 9na. Ed.,2011. 
- Pressman, Roger S. ,Ingeniería de Software, Un enfoque práctico, Mc. Graw Hill, 
7ma. Ed. 2010.