A: creo que ya está muy explicado

B: averiguar

C: para la clase

D: ejemplos

A medida que los sistemas informáticos se han integrado profundamente en nuestro negocio y vida
personal, los problemas que resultan de la falla del sistema y el software están aumentando. Una falla
podría conducir a una pérdida importante de ingresos y clientes para esa empresa, como asi podría ser
un factor contribuyente en accidentes. La infección de computadoras en una compañía con malwares
requieren costosas operaciones de limpieza y podría conducir a la pérdida o daño de información
confidencial.

Debido a que los sistemas intensivos en software son tan importantes para los gobiernos, las empresas,
e individuos, tenemos que poder confiar en estos sistemas. El software debe estar disponible cuando
sea necesario, y debe funcionar. En resumen, deberíamos poder depender de nuestros sistemas de
software.

El término dependability (confiabilidad) fue propuesto por Jean-Claude Laprie en 1995 para cubrir los
atributos relacionados con los sistemas de disponibilidad, confiabilidad, seguridad y protección. Estas
propiedades están vinculadas, por lo que tener un solo término para abarcarlos a todos tiene sentido.

La fiabilidad de los sistemas suele ser más importante que su funcionalidad detallada por los siguientes
motivos:

1. Las fallas del sistema afectan a un gran número de personas. Muchos sistemas incluyen
funcionalidades que rara vez se usan. Si esta funcionalidad se dejó fuera del sistema, solo un pequeño
número de usuarios se vería afectado. Las fallas del sistema que afectan la disponibilidad de un sistema
potencialmente afectan a todos los usuarios del sistema.

2. Los usuarios a menudo rechazan sistemas que no son fiables, si un sistema no es fiable o es inseguro,
se negarán a usarlo. Además, También pueden negarse a comprar o usar otros productos de la
compañía que produjo el sistema poco fiable.

3. Los costos de falla del sistema pueden ser enormes para algunas aplicaciones, como un sistema de
control de un reactor o un sistema de navegación de una aeronave.

4. Los sistemas poco confiables pueden causar pérdida de información. Los datos son muy caros de
recopilar y mantener. El costo de recuperar datos perdidos o corruptos suele ser muy alto.

Sin embargo, un sistema puede ser útil sin ser muy confiable, debido a que, si es muy útil, se suelen
tolerar fallas ocasionales. Por ej: procesador de texto.

La construcción de software confiable es parte del proceso más general de ingeniería de sistemas
confiables. El software siempre forma parte de un sistema más amplio. Al diseñar un sistema confiable,
se debe tener en cuenta:

1. Fallo de hardware: puede fallar debido a errores en su diseño, porque los componentes fallan como
resultado de errores de fabricación, debido a factores ambientales como la humedad o las altas
temperaturas, o porque los componentes han llegado al final de su vida natural.
2. Falla del software: puede fallar debido a errores en su especificación, diseño o implementación.

3. Falla operacional: Los usuarios humanos pueden no usar u operar el sistema como fue destinado por
sus diseñadores. A medida que el hardware y el software se han vuelto más fiables, Las fallas en la
operación son ahora, quizás, la mayor causa de fallas del sistema.

Si el hardware, el software y los procesos operativos se diseñan por separado, sin tener en cuenta las
debilidades potenciales de otras partes del sistema, entonces es más probable que ocurran errores en
las interfaces entre las diferentes partes del sistema.

10.1 PROPIEDADES DE LA DEPENDABILITY

La fiabilidad de un sistema informático es una propiedad del sistema que refleja su confiabilidad. La
confiabilidad aquí esencialmente significa el grado de confianza que un usuario tiene en que el sistema
funcionará como esperan y que el sistema no "Fallara" en uso normal. No tiene sentido expresar
confiabilidad numéricamente. Por el contrario, los términos relativos como "no confiable", "muy
confiable" y "ultra confiable" pueden reflejar el grado de confianza que podríamos tener en un sistema.

Hay cinco dimensiones principales para la confiabilidad, como he demostrado en

Figura 10.1.

1. Disponibilidad Informal, es la probabilidad de que estar en funcionamiento y ser capaz de ofrecer

servicios útiles a los usuarios en cualquier momento.

2. fiabilidad Informal, es la probabilidad, sobre un determinado período de tiempo, que el sistema

entregará correctamente los servicios como lo espera el usuario.

3. Safety Informal, es un juicio de cuán probable es que el sistema causará daños a las personas o su
entorno.

4. Seguridad Informal, es un juicio de cuán probable es que el sistema puede resistir intrusiones
accidentales o deliberadas.

5. Resiliencia Informal, es un juicio de qué tan bien sistema puede mantener la continuidad de sus
servicios críticos en presencia de eventos disruptivos, como fallas en el equipo y ataques cibernéticos. La
resiliencia es una adición más reciente al conjunto de propiedades de confiabilidad que originalmente
sugerido por Laprie.

Las propiedades de confiabilidad son propiedades complejas que se puede dividir en varias propiedades
más simples. Por ejemplo, la seguridad incluye "Integridad" (asegurando que el programa de sistemas y
los datos no estén dañados) y "confidencialidad" (asegurando que solo las personas autorizadas tengan
acceso). La fiabilidad incluye "corrección" (garantizar que los servicios del sistema sean los
especificados), "precisión" (garantizar que la información se entregue a un nivel apropiado de detalle), y
"puntualidad" (asegurando que la información se entregue cuando se requiera).

Por supuesto, no todas las propiedades de confiabilidad son críticas para todos los sistemas.

PARA LA CLASE, QUE PROPIEDADES CREEN QUE SON CRITICAS PARA SU CASO DE ESTUDIO?
Para el sistema de clima salvaje, la disponibilidad y la confiabilidad son lo más importante propiedades
porque los costos de reparación pueden ser muy altos.

Otras propiedades del sistema están estrechamente relacionadas con estas cinco propiedades de
DEPENDABILITY e influyen en la fiabilidad de un sistema:

1. Reparabilidad: Las fallas del sistema de son inevitables, pero la interrupción causada por la falla puede
minimizarse si el sistema puede repararse rápidamente. Debe ser posible diagnosticar el problema,
acceder al componente que ha fallado y realizar cambios para arreglar ese componente.

2. Mantenibilidad: A medida que se utilizan los sistemas, surgen nuevos requisitos, y es importante
mantener el valor de un sistema cambiándolo para incluir estos nuevos requisitos. El software que se
puede mantener es un software que se puede adaptar económicamente para hacer frente a los nuevos
requisitos, y donde hay una baja probabilidad de que realizar cambios introducirá nuevos errores en el
sistema.

3. Tolerancia a errores: Esta propiedad puede considerarse parte de la usabilidad y refleja la medida en
que el sistema ha sido diseñado, de modo que los errores de entrada del usuario sean evitados y
tolerados. Cuando se producen errores del usuario, el sistema debe, en la medida de lo posible, detectar
estos errores y corregirlos automáticamente o solicitar al usuario volver a ingresar sus datos.

Se introdujo la noción de confiabilidad del sistema como una propiedad ya que abarca las propiedades
de confiabilidad de disponibilidad, seguridad, fiabilidad, protección y la resiliencia que están
estrechamente relacionadas.
Para desarrollar software confiable, debe asegurarse de que:

1. Evitar la introducción de errores accidentales en el sistema durante la especificación y desarrollo del

software.

2. Se tiene que diseñar procesos de verificación y validación que son efectivos para descubrir errores
residuales que afectan la confiabilidad del sistema.

3. Diseñar el sistema para que sea tolerante a fallas para que pueda continuar funcionando cuando las
cosas van mal.

4. Diseñar mecanismos de protección que protegen contra ataques externos que pueden comprometer
la disponibilidad o seguridad del sistema.

5. Configurar el sistema implementado y su software de soporte correctamente para su entorno

operativo.

6. Incluir capacidades del sistema para reconocer ciberataques externos y resistir estos ataques.

7. Diseñar sistemas para que puedan recuperarse rápidamente de fallas del sistema y ciberataques sin
pérdida de datos críticos.

La necesidad de tolerancia a fallas significa que los sistemas confiables deben incluir código redundante
para ayudarlos a monitorearse a sí mismos, detectar estados erróneos y recuperarse de las fallas antes
de que ocurran las fallas. Esto afecta el rendimiento de los sistemas, ya que se requiere una verificación
adicional cada vez que se ejecuta el sistema. Por lo tanto, los diseñadores, tiene que sacrificar la
performance y la dependability.

Construir sistemas confiables es costoso. Aumentando la fiabilidad de un sistema significará que se

incurrirá en costos adicionales para el diseño, implementación y validación del sistema. Los costos de
verificación y validación son particularmente altos para los sistemas que deben ser extremadamente
confiable, como los sistemas de control críticos para la seguridad. Además de validar que el sistema
cumple con sus requisitos, el proceso de validación puede tener que ser demostrado a un regulador
externo que el sistema es seguro. Por ejemplo, los sistemas de aeronaves tienen que demostrarlo a los
reguladores, como la Autoridad Federal de Aviación, que la probabilidad de una falla catastrófica del
sistema que afecta la seguridad de la aeronave es extremadamente baja.

La Figura 10.2 muestra la relación entre costos y mejoras incrementales en la confiabilidad. Si su

software no es muy dependeable, puede obtener importantes mejoras de forma bastante económica
mediante el uso de una mejor ingeniería de software. Sin embargo, si ya están utilizando buenas
prácticas, los costos de mejora son mucho mayores y Los beneficios de esa mejora son menores.

También existe el problema de probar el software para demostrar que es confiable. La prueba es un
proceso muy costoso, así que esto puede aumentar significativamente el costo de los sistemas de alta
confiabilidad.

10.2 SOCIOTECHNICAL SYSTEMS

En un sistema informático, el software y el hardware son interdependientes. Sin hardware, un sistema

de software es una abstracción, que es simplemente una representación de algunos conocimientos e
ideas humanas. Sin software, el hardware es un conjunto de dispositivos electrónicos inertes. Sin
embargo, si los juntas para formar un sistema, se crea una máquina que puede realizar cálculos
complejos y entregar los resultados de estos cálculos a su entorno.

Los sistemas tienen propiedades que se vuelven aparentes solo cuando sus componentes están
integrados y funcionan juntos. Los sistemas de software no son un sistema aislados, pero son parte de
sistemas más extensos que tienen un propósito humano, social u organizacional. Por lo tanto, la
ingeniería de software no es una actividad aislada sino una Parte intrínseca de la ingeniería de sistemas.
Por ejemplo, el software del sistema de clima salvaje controla los instrumentos en una estación
meteorológica. Se comunica con otros sistemas de software y forma parte de sistemas de pronóstico
meteorológico nacional e internacional. Además de hardware y software, estos sistemas incluyen
procesos para pronosticar el clima y para las personas que operan el sistema y analizan sus resultados.
El sistema también incluye a las organizaciones que dependen del sistema para ayudarles a proporcionar
pronósticos del tiempo a individuos, gobierno e industria.

Estos sistemas más amplios se denominan sistemas sociotécnicos. Incluyen elementos no técnicos,
como personas, procesos y regulaciones, así como componentes técnicos, como computadoras,
software y otros equipos. Los sistemas sociotécnicos son tan complejos que es imposible entenderlos
por completo. Más bien, debe verlos como capas, como se muestra en la Figura 10.3. Estas Las capas
forman la pila de sistemas sociotécnicos:
1. La capa de equipo está compuesta por dispositivos de hardware, algunos de los cuales pueden ser
ordenadores.

2. La capa del sistema operativo interactúa con el hardware y proporciona un conjunto de instalaciones
comunes para capas de software superiores en el sistema.

3. La capa de comunicaciones y gestión de datos amplía las instalaciones del sistema operativo y
proporciona una interfaz que permite la interacción con funciones más amplias, como el acceso a
sistemas remotos y el acceso a una base de datos del sistema. Esto a veces se llama middleware, ya que
se encuentra entre la aplicación y el sistema operativo.

4. La capa de aplicación ofrece la funcionalidad específica de la aplicación que es necesario. Puede haber
muchos programas de aplicación diferentes en esta capa.

5. La capa de proceso empresarial incluye los procesos empresariales organizativos, que hacen uso del
sistema de software.

6. La capa organizativa incluye procesos estratégicos de nivel superior, así como reglas, políticas y
normas comerciales que deben seguirse al usar el sistema.

7. La capa social se refiere a las leyes y regulaciones de la sociedad que gobiernan la operación del
sistema.

Observe que no hay una "capa de software" separada. El software de un tipo u otro es una parte
importante de todas las capas del sistema sociotécnico. El equipo es controlado por software embebido;
El sistema operativo y las aplicaciones son software. Los procesos comerciales, las organizaciones y la
sociedad dependen de Internet (software) y otros sistemas de software globales.

En principio, la mayoría de las interacciones deberían ser entre capas vecina, con cada capa oculta el
detalle de la capa inferior a la capa superior. En la práctica, sin embargo, puede haber interacciones
inesperadas entre capas, que dan lugar a problemas para el sistema. Por ejemplo, digamos que hay un
cambio en La ley que rige el acceso a la información personal. Esto viene de la capa social. Conduce a
nuevos procedimientos organizativos y cambios en los procesos comerciales. Es posible que el sistema
de aplicación en sí no pueda proporcionar el nivel de privacidad requerido, por lo que es posible que sea
necesario implementar cambios en las comunicaciones y los datos de la capa de gestión.

Pensar los sistemas de manera conjunta, en lugar de simplemente considerar el software aislado, es
esencial cuando se considera la seguridad y fiabilidad del software. Por lo tanto, se debería tener una
vista a nivel de sistema cuando se diseña el software que tiene que ser confiable y seguro. Tienes que
tener en cuenta las consecuencias de fallas de software para otros elementos en el sistema. También
necesitas entender cómo estos otros elementos del sistema pueden ser la causa de la falla del software
y cómo puede ayudar a protegerse y recuperarse de fallas de software.

Es importante asegurarse de que, siempre que sea posible, la falla del software no conduzca a falla
general del sistema. Por lo tanto, se debe examinar cómo interactúa el software con su entorno
inmediato para garantizar que:
1. Las fallas de software están, en la medida de lo posible, contenidas dentro de la capa envolvente de la
pila del sistema y no afectan seriamente el funcionamiento de otras capas en el sistema.

2. Entiende cómo los errores y fallos en las otras capas de la pila de sistemas pueden afectar al software.
También puede considerar cómo se pueden integrar comprobaciones en el software para ayudar a
detectar estos errores y cómo se puede proporcionar soporte técnico para recuperarse de errores.

Como el software es inherentemente flexible, los problemas inesperados del sistema a menudo se dejan
a los ingenieros de software para que lo resuelvan. Este tipo de situación, en la que los ingenieros de
software se quedan con el problema de Mejorar las capacidades del software sin aumentar el costo del
hardware es muy común. Muchas de las llamadas fallas de software no son consecuencia de problemas
de software inherentes, sino que son el resultado de intentar cambiar el software para acomodar los
requisitos modificados de ingeniería del sistema.

10.2.1 Regulation and compliance

Una empresa no puede ofrecer productos a la venta más baratos porque han reducido sus costos al
reducir la seguridad de sus productos. Los gobiernos han creado un conjunto de reglas y regulaciones en
diferentes áreas que definen estándares de seguridad y protección. También han establecido
reguladores u organismos reguladores cuyo trabajo es garantizar que las empresas que ofrecen
productos en un área cumplan con estas reglas. Los reguladores tienen amplios poderes. Pueden multar
a las empresas e incluso encarcelar a los directores si se violan las regulaciones. Pueden tener un rol de
licencia donde deben emitir una licencia antes de que puede utilizar un nuevo sistema. Por lo tanto, los
fabricantes de aviones deben tener un certificado de aeronavegabilidad del regulador en cada país
donde se utiliza la aeronave.

Para lograr la certificación, las compañías que están desarrollando sistemas críticos para la seguridad
tienen que producir un caso de seguridad extenso (discutido en el Capítulo 13) que muestre que se han
seguido las normas y reglamentos. El caso debe convencer a un regulador de que el sistema puede
funcionar de forma segura. Desarrollar este caso de seguridad es muy costoso. Puede ser que
desarrollar la documentación para la certificación sea tan costoso como desarrollar el sistema en sí.

10.3 Redundancy and diversity

Las fallas de componentes en cualquier sistema son inevitables. La gente comete errores, los errores no
descubiertos en el software causan un comportamiento indeseable y el hardware se quema. Usamos
una gama de estrategias para reducir la cantidad de fallas humanas, como el reemplazo de
componentes de hardware antes del final de su vida útil prevista y el software de verificación utilizando
herramientas de análisis estático. Sin embargo, no podemos estar seguros de que estos eliminarán los
errores de los componentes. Por lo tanto, debemos diseñar sistemas para que las fallas de los
componentes individuales no conduzcan a una falla general del sistema.
Las estrategias para lograr y mejorar la confiabilidad dependen tanto de la redundancia como de la
diversidad. La redundancia significa que la capacidad de repuesto se incluye en un sistema que se puede
utilizar si parte de ese sistema falla. La diversidad significa que los componentes redundantes de los
sistemas son de diferentes tipos, lo que aumenta las posibilidades de que no fallen exactamente de la
misma manera. Usamos redundancia y diversidad para mejorar la confiabilidad en nuestra vida
cotidiana. Comúnmente, para asegurar nuestros hogares usamos más de una cerradura (redundancia),
y, generalmente, las cerraduras utilizadas son de diferentes tipos (diversidad). Esto significa que, si los
intrusos encuentran una manera de derrotar una de las cerraduras, tienen que encontrar una forma
diferente de derrotando a las otras cerraduras antes de que puedan entrar. Como cuestión de rutina,
todos nosotros debemos hacer una copia de seguridad de nuestras computadoras y mantener copias
redundantes de nuestros datos. Para evitar problemas con la falla del disco, las copias de seguridad
deben mantenerse en un dispositivo externo independiente y diverso.

Los sistemas de software diseñados para la confiabilidad pueden incluir componentes redundantes que
proporcionan la misma funcionalidad que otros componentes del sistema. Estas se conectan al sistema
si falla el componente principal. Otra forma de redundancia es la inclusión del código de verificación,
que no es estrictamente necesario para que el sistema funcione. Este código puede detectar algunos
tipos de problemas, como la corrupción de datos, antes de que causen fallas. Puede invocar mecanismos
de recuperación para corregir problemas y asegúrese de que el sistema continúe funcionando.

En sistemas para los que la disponibilidad es un requisito crítico, los servidores redundantes son
normalmente utilizados. Estos entran en funcionamiento automáticamente si un servidor designado
falla. A veces, para garantizar que los ataques al sistema no puedan explotar una vulnerabilidad común,
estos servidores pueden ser de diferentes tipos y pueden ejecutar diferentes sistemas operativos. El uso
de diferentes sistemas operativos es un ejemplo de diversidad de software y redundancia, donde se
proporciona una funcionalidad similar de diferentes maneras.

La diversidad y la redundancia también pueden usarse en el diseño de procesos de desarrollo de

software confiables. Los procesos de desarrollo confiables evitan la introducción de fallas en un sistema.
En un proceso confiable, actividades como la validación de software no se basan en una sola
herramienta o técnica. Esto mejora la fiabilidad del software porque reduce las posibilidades de fallo del
proceso, donde los errores humanos cometidos durante el proceso de desarrollo de software conducen
a errores de software.

Por ejemplo, las actividades de validación pueden incluir pruebas de programas, inspecciones manuales
del programa y análisis estático como técnicas de búsqueda de fallas. Cualquiera de estas técnicas
podría encontrar fallas que se pierden con los otros métodos. Además, diferentes miembros del equipo
pueden ser responsables de la misma actividad del proceso (por ejemplo, una inspección del programa).
Las personas abordan las tareas de diferentes maneras según su personalidad, experiencia y educación,
por lo que este tipo de redundancia proporciona una perspectiva diversa sobre el sistema.
Sin embargo, el uso de redundancia y diversidad de software puede introducir errores en el software.
Diversidad y redundancia hacen sistemas más complejo y generalmente más difícil de entender. No solo
hay más código para escribir y verificar, también se debe agregar funcionalidad adicional al sistema para
detectar fallas de componentes y cambiar el control a componentes alternativos. Esta complejidad
adicional significa que es más probable que los programadores cometan errores y es menos probable
que las personas que verifican el sistema encuentren estos errores. Por lo tanto, algunos ingenieros
piensan que, como el software no puede desgastarse, es mejor evitar la redundancia y la diversidad de
software. Su punto de vista es que el mejor enfoque es diseñar el software para que sea lo más simple
posible, con procedimientos de verificación y validación de software extremadamente rigurosos. Se
pueden gastar más en verificación y validación debido a los ahorros que resultan de no tener que
desarrollar componentes de software redundantes.
Ambos enfoques se utilizan en sistemas de software comerciales críticos para la seguridad. Por ejemplo,
el hardware y software de control de vuelo Airbus 340 es diverso y redundante. El software de control
de vuelo en el Boeing 777 se ejecuta en hardware redundante, pero cada equipo ejecuta el mismo
software, que ha sido ampliamente validado. Los diseñadores del sistema de control de vuelo Boeing
777 se han centrado en la simplicidad en lugar de la redundancia. Ambos aviones son muy fiables, por lo
que tanto el enfoque diverso como el simple de la fiabilidad pueden tener éxito.

10.4 Dependable processes

Los procesos de software confiables son procesos de software diseñados para producir software
confiable. La razón para invertir en procesos confiables es que es probable que un buen proceso de
software conduzca a un software entregado que contenga menos errores y, por lo tanto, es menos
probable que falle en la ejecución. La figura 10.4 muestra algunos de los atributos de procesos de
software.

La evidencia de que se ha utilizado un proceso confiable a menudo es importante para convencer a un

regulador de que la práctica de ingeniería de software más efectiva ha sido aplicada en el desarrollo del
software. Los desarrolladores de sistemas normalmente presentarán un modelo del proceso a un
regulador, junto con evidencia de que se ha seguido el proceso. El regulador también tiene que estar
convencido de que el proceso es utilizado constantemente por todos los participantes del proceso y que
se puede utilizar en diferentes proyectos de desarrollo. Esto significa que el proceso debe definirse
explícitamente y repetirse:

1. Un proceso definido explícitamente es aquel que tiene un modelo de proceso definido que se utiliza
para impulsar el proceso de producción de software. Los datos deben recopilarse durante el proceso
que demuestre que el equipo de desarrollo ha seguido el proceso tal como se define en el modelo de
proceso.

2. Un proceso repetible es aquel que no se basa en la interpretación y el juicio individuales. Más bien, el
proceso se puede repetir en todos los proyectos y con diferentes miembros del equipo,
independientemente de quién esté involucrado en el desarrollo.

Las actividades que se utilizan en procesos confiables obviamente dependen del tipo del software que
se está desarrollando. En general, sin embargo, estas actividades deberían ser orientadas a evitar la
introducción de errores en un sistema, detectar y eliminar errores y mantener información sobre el
proceso en sí. Los ejemplos de actividades que podrían incluirse en un proceso confiable incluyen:

1. Comentarios de requisitos para comprobar que los requisitos son, en la medida de lo posible,
completos y consistentes.

2. Gestión de requisitos para garantizar que los cambios en los requisitos estén controlados y que el
impacto de los cambios de requisitos propuestos sea entendido por todos los desarrolladores afectados
por el cambio.
3. Especificación formal, donde se crea y analiza un modelo matemático del software. Tal vez su
beneficio más importante es que fuerza un análisis muy detallado de los requisitos del sistema. Este
análisis en sí es probable que descubra problemas de requisitos que pueden haberse perdido en las
revisiones de requisitos.

4. Modelado del sistema, donde el diseño del software se documenta explícitamente como un conjunto
de modelos gráficos y los vínculos entre los requisitos y estos modelos se documentan explícitamente.

5. Diseñar y programar inspecciones, donde las diferentes descripciones del sistema son inspeccionadas
y verificadas por diferentes personas. Se puede utilizar una lista de comprobación de errores comunes
de diseño y programación para enfocar el proceso de inspección.

6. Análisis estático, donde se realizan comprobaciones automatizadas en el código fuente del programa.
Estos buscan anomalías que podrían indicar errores u omisiones de programación. (Cubro el análisis
estático en el capítulo 12.).

7. Planificación y gestión de pruebas, donde se diseña un conjunto completo de pruebas del sistema. El
proceso de prueba debe gestionarse cuidadosamente para demostrar que estas pruebas proporcionan
cobertura de los requisitos del sistema y se han aplicado correctamente en el proceso de prueba.

Además de las actividades de proceso que se centran en el desarrollo y las pruebas del sistema, también
debe haber procesos de gestión de la calidad y gestión de cambios bien definidos. Los procesos de
gestión de calidad (cubiertos en el Capítulo 24) establecen un conjunto de procesos y normas de
producto. También incluyen actividades que capturan información del proceso para demostrar que se
han seguido estos estándares.

10.5 Formal methods and dependability

Los métodos formales son enfoques matemáticos para el desarrollo de software donde se define un
modelo formal del software. Luego, puede analizar formalmente este modelo para buscar errores e
incoherencias, demostrar que un programa es coherente con este modelo, o puede aplicar una serie de
transformaciones que preservan la corrección al modelo para generar un programa.

Los métodos formales se han aplicado con éxito en sistemas de control de trenes (Badeau y Amelot
2005), sistemas de tarjetas de efectivo (Hall y Chapman 2002) y sistemas de control de vuelo (Miller et
al. 2005).

El uso de un enfoque matemáticamente formal para el desarrollo de software se propuso en una etapa
temprana en el desarrollo de la informática. La idea era que una especificación formal y un programa
pudieran desarrollarse de forma independiente. Luego, se podría desarrollar una prueba matemática
para mostrar que el programa y su especificación eran consistentes. Inicialmente, las pruebas se
desarrollaron manualmente, pero este fue un proceso largo y costoso. Rápidamente quedó claro que las
pruebas manuales sólo podían desarrollarse para sistemas muy pequeños. La prueba del programa
ahora está respaldada por un software de prueba de teorema automatizado a gran escala, lo que ha
significado que se pueden probar sistemas más grandes.

Un enfoque alternativo, que evita una actividad de prueba separada, es el desarrollo basado en el
refinamiento. Aquí, una especificación formal de un sistema se refina a través de una serie de
transformaciones que preservan la corrección para generar el software. Debido a que estas son
transformaciones confiables, puede estar seguro de que el programa generado es consistente con su
especificación formal. Este fue el enfoque utilizado en el desarrollo de software para el sistema de
metro de París (Badeau y Amelot 2005). Usó un lenguaje llamado B (Abrial 2010), que fue diseñado para
soportar el refinamiento de las especificaciones.

Se han utilizado métodos formales basados en la verificación de modelos utilizado en varios sistemas.
Estos sistemas se basan en la construcción o generación de un modelo de estado formal de un sistema y
en el uso de un comprobador de modelos para comprobar que las propiedades del modelo, como las
propiedades de seguridad, siempre se mantienen. El programa de comprobación de modelos analiza
exhaustivamente la especificación e informa de que el modelo satisface la propiedad del sistema o
presenta un ejemplo que muestra que no está satisfecha. Si un modelo se puede generar de forma
automática o sistemática desde un programa, esto significa que se pueden destapar errores en el
programa.

Los métodos formales para la ingeniería de software son efectivos para descubrir o evitar dos clases de
error en las representaciones de software:

1. Errores y omisiones de especificación y diseño. El proceso de desarrollo y análisis de un modelo

formal del software puede revelar errores y omisiones en los requisitos del software. Si el modelo se
genera de forma automática o sistemática a partir del código fuente, el análisis mediante la
comprobación del modelo puede detectar estados no deseados que pueden producirse, como el
interbloqueo en un sistema simultáneo.

2. Inconsistencias entre una especificación y un programa. Si se utiliza un método de refinamiento, se

evitan los errores cometidos por los desarrolladores que hacen que el software sea incoherente con la
especificación. La demostración del programa descubre incoherencias entre un programa y su
especificación.

El punto de partida para todos los métodos formales es un modelo de sistema matemático, que actúa
como una especificación del sistema. Para crear este modelo, se traducen los requisitos de usuario del
sistema, que se expresan en lenguaje natural, diagramas y tablas, en un lenguaje matemático que ha
definido formalmente la semántica. La especificación formal es una descripción inequívoca de lo que el
sistema debe hacer.

Las especificaciones formales son la forma más precisa de especificar sistemas, por lo que reducen el
margen de incomprensión. Muchos partidarios de los métodos formales creen que la creación de
especificaciones formales, incluso sin refinamiento o prueba de programa, vale la pena. La construcción
de una especificación formal fuerza un análisis detallado de los requisitos y esta es una manera eficaz de
descubrir los problemas de los requisitos.

Las ventajas de desarrollar una especificación formal y usarla en un proceso formal de desarrollo son:

1. A medida que desarrolla una especificación formal en detalle, desarrolla una comprensión profunda y
detallada de los requisitos del sistema. Los problemas de requisitos que se descubren a tiempo suelen
ser mucho más baratos de corregir que si se encuentran en etapas posteriores del proceso de
desarrollo.

2. Como la especificación se expresa en un lenguaje con semántica definida formalmente, puede

analizarla automáticamente para descubrir incoherencias e incompletas.

3. Si utiliza un método como el método B, puede transformar la especificación formal en un programa a

través de una secuencia de transformaciones de conservación de correctividad. Por lo tanto, se
garantiza que el programa resultante cumpla con sus especificaciones.

4. Los costos de las pruebas del programa pueden reducirse porque usted ha verificado el programa con
su especificación. Por ejemplo, en el desarrollo del software para los sistemas del metro de París, el uso
del refinamiento significaba que no había necesidad de pruebas de componentes de software y sólo se
requerían pruebas del sistema.

A pesar de estas ventajas, los métodos formales han tenido un impacto limitado en el desarrollo
práctico de software, incluso para sistemas críticos. La industria se ha mostrado reacia a adoptar
métodos formales por varias razones:

1. Los propietarios de problemas y los expertos en dominios no pueden entender una especificación
formal, por lo que no pueden comprobar que representa con precisión sus requisitos. Los ingenieros de
software, que entienden la especificación formal, pueden no entender el dominio de la aplicación, por lo
que también no pueden estar seguros de que la especificación formal es un reflejo preciso de los
requisitos del sistema.

2. Es bastante fácil cuantificar los costos de crear una especificación formal, pero más difícil de estimar
los posibles ahorros de costos que resultarán de su uso. Como resultado, los gerentes no están
dispuestos a correr el riesgo de adoptar métodos formales.

3. La mayoría de los ingenieros de software no han sido entrenados para utilizar lenguajes de
especificación formal. Por lo tanto, son reacios a proponer su uso en los procesos de desarrollo.

4. Es difícil escalar los métodos formales actuales hasta sistemas muy grandes. Cuando se utilizan
métodos formales, es principalmente para especificar software de kernel crítico en lugar de sistemas
completos.

5. La compatibilidad con herramientas para métodos formales es limitada, y las herramientas

disponibles son a menudo de código abierto y difíciles de usar. El mercado es demasiado pequeño para
los proveedores de herramientas comerciales.

6. Los métodos formales no son compatibles con el desarrollo ágil donde los programas se desarrollan
de forma incremental. Sin embargo, esto no es un problema importante, ya que la mayoría de los
sistemas críticos todavía se desarrollan utilizando un enfoque basado en planes.