Validación de sistemas críticos

Actividad 1:

Validación

1. ¿Describe las razones por las cuales es necesaria la validación?

a. Costes de fallos de ejecución. Los costes y las consecuencias de los fallos de ejecución de los sistemas críticos son potencial mente mucho más grandes que para los sistemas no críticos. Pueden reducirse los riesgos de los fallos del sistema invirtiendo más en verificación y validación del sistema. Normalmente es más económico encontrar y eliminar defectos antes de que el sistema sea entregado que pagar por los consecuentes costes de accidentes o de un mal funcionamiento de los servicios del sistema.

b. Validación de los atributos de confiabilidad. Puede tenerse que hacer una demostración formal a los clientes de que el sistema satisface sus requerimientos especificados de confiabilidad (disponibilidad, fiabilidad, seguridad y protección). Para evaluar estas características de confiabilidad se requieren actividades específicas de V & V explicadas más adelante en este capítulo. En algunos casos, los reguladores externos, tales como autoridades de aviación nacionales, pueden tener que certificar que el sistema es seguro antes de que éste sea desplegado. Para obtener esta certificación, pueden tenerse que diseñar y llevar a cabo procedimientos de V & V especiales que recogen la evidencia sobre la confiabilidad del sistema.

2. Cuál es el proceso para medir la fiabilidad de un software

Pruebas estadísticas

a. Se comienza estudiando los sistemas existentes del mismo tipo para establecer un per- fil operacional. Un perfil operacional identifica las clases de entradas al sistema y la probabilidad de que estas entradas ocurran en un uso normal.

b. A continuación, se construye un conjunto de datos de prueba que reflejan el perfil operacional. Esto significa que se crean datos de prueba con la misma distribución de probabilidad que los datos de prueba para los sistemas que se han estudiado. Normalmente, se utiliza un generador de datos de prueba para soportar este proceso.

c. Se prueba el sistema utilizando estos datos y se contabiliza el número y tipo de fallos que ocurren. Los instantes en los que ocurren estos fallos también son registrados. Tal y como se indicó en el Capítulo 9, las unidades de tiempo que se elijan deberían ser adecuadas para la métrica de fiabilidad utilizada.

d. Después de que se ha observado un número de fallos significativos estadísticamente, se puede calcular la fiabilidad del software y obtener el valor adecuado de la métrica de fiabilidad.

3. Que es y porque es importante un perfil de operaciones

Consiste en la especificación de clases de entradas y la probabilidad de su ocurrencia. Cuando un nuevo sistema software reemplaza a un sistema existente manual o automatizado, es razonablemente fácil evaluar el patrón de uso probable del nuevo software. Éste debería corresponderse con el uso del sistema existente, con algunas adiciones para las nuevas funcionalidades que (presumiblemente) se incluyen en el nuevo software. Por ejemplo, puede especificarse un perfil operacional para sistemas de centralitas de telecomunicaciones debido a que las compañías de telecomunicaciones conocen los patrones de llamadas que estos sistemas tienen que manejar.

El perfil operacional del software es importante por que refleja cómo se utilizará éste en la práctica.

4. La dificultad para la construcción de un perfil operacional de un software nuevo ¿Es igual para uno que se creó para remplazar a otro?

NO por que cuando un sistema software es nuevo e innovador, es difícil anticipar cómo será utilizado y, por lo tanto, generar un perfil operacional preciso.

5. Cómo funciona el modelo de crecimiento de fiabilidad

Un modelo de crecimiento de fiabilidad es un modelo de cómo cambia la fiabilidad del sistema a lo largo del tiempo durante el proceso de pruebas. Para predecir la fiabilidad, el modelo conceptual de crecimiento de la fiabilidad debe ser traducido a un modelo matemático.

Aquí no se entra en este nivel de detalle, sino que simplemente se plantea el principio del crecimiento de la fiabilidad.

6. ¿Es garantía de que la fiabilidad mejorara en cada entrega después de corregir fallos? ¿Por qué?

SI, por que a medida que se descubren los fallos del sistema, los defectos subyacentes que provocan estos fallos son reparados para que la fiabilidad del sistema mejore durante las pruebas y depuración.

Aunque los defectos del software no siempre se reparan durante la depuración, y cuando se cambia un programa, a menudo se introducen nuevos defectos. La probabilidad de ocurrencia de estos defectos puede ser mayor que la probabilidad de ocurrencia del defecto que ha sido reparado. Por lo tanto, la fiabilidad del sistema a veces puede empeorar en una nueva entrega en lugar de mejorar.

Por lo tanto no es garantía

7. ¿Hasta cuando las pruebas y depuración deben continuar?

Las pruebas pueden detenerse cuando se alcance el nivel requerido de fiabilidad del sistema.

8. Ventajas de la predicción de la predicción a partir de un modelo

Planificación de las pruebas. Dado el calendario actual de pruebas, puede predecirse cuándo se completarán las pruebas. Si el final de las pruebas tiene lugar después de la fecha planificada de entrega del sistema, entonces puede tenerse que desplegar recursos adicionales para probar y depurar, y así acelerar la tasa de crecimiento de fiabilidad.

Negociaciones con el cliente. Algunas veces el modelo de fiabilidad muestra que el crecimiento de la fiabilidad es muy lento y que se requiere una cantidad de esfuerzo de pruebas desproporcionada para obtener un beneficio relativamente pequeño.

Puede merecer la pena renegociar los requerimientos de fiabilidad con el cliente. De forma alternativa, puede ocurrir que el modelo prediga que la fiabilidad requerida probablemente nunca será alcanzada. En este caso, se tendrán que renegociar con el cliente los requerimientos de la fiabilidad del sistema.

9. Tipos de revisiones propuestas por el autor para ser obligatorias y garantizar la seguridad de un sistema

1. revisión para corregir la función que se pretende;

2. revisión para una estructura comprensible y mantenible;

3. revisión para verificar que el algoritmo y el diseño de las estructuras de datos son consistentes con el comportamiento especificado;

4. revisión de la consistencia del código y del diseño del algoritmo y de las estructuras de datos;

5. revisión de la adecuación de los casos de prueba del sistema

10. En qué consiste la técnica más efectiva para demostrar la seguridad del sistema (contradicción)

La técnica más efectiva para demostrar la seguridad de un sistema es la demostración por contradicción. Se comienza suponiendo que se está en un estado no seguro, el cual ha sido identificado por un análisis de contingencias del sistema, y que puede ser alcanzado ejecutando el programa. Se describe un predicado que define este estado no seguro.

A continuación, se analiza el código de forma sistemática y se muestra que, para todos los caminos del programa que conducen a ese estado, la condición de terminación de estos caminos contradice el predicado no seguro.

Si éste es el caso, la suposición inicial de un estado inseguro es incorrecta.

Si se repite esto para todas las contingencias identificadas, entonces el software es seguro.

a. Ejemplo:

Como ejemplo, consideremos el código de la Figura 24.6, que podría ser parte de la implementación del sistema de suministro de insulina. Desarrollar un argumento de seguridad para este código implica demostrar que la dosis de insulina administrada nunca es mayor que algún nivel máximo establecido para cada individuo diabético. Por lo tanto, no es necesario probar que el sistema suministra la dosis correcta, sino simplemente que nunca suministra una sobredosis al paciente.

Para construir un argumento de seguridad, se identifica la precondición para el estado in- seguro que, en este caso, es que currentDose > maxDose. Después se demuestra que todos los caminos del programa conducen a una contradicción de esta aserción no segura. Si éste es el caso, la condición no segura no puede ser cierta. Por lo tanto, el sistema es seguro. Se pueden estructurar y presentar los argumentos de seguridad de forma gráfica tal y como se muestra en la Figura 24.7. Los argumentos de seguridad, según se refleja en la citada figura, son mucho más cortos que las verificaciones formales de sistemas. Primero se identifica todos los posibles caminos que conducen a! estado potencial mente inseguro. Se trabaja hacia atrás a partir de este estado no seguro y se considera la última asignación de todas las variables de estado en cada camino que conduce a él. Pueden omitirse los cálculos previos (como la sentencia if 1 en la Fi- gura 24.7) en el argumento de seguridad. En este ejemplo, todo lo que se necesita saber es el conjunto de posibles valores de currentDose inmediatamente antes de que el método administerlnsulin sea ejecutado. En el argumento de seguridad mostrado en la Figura 24.7, existen tres posibles caminos en el programa que conducen a la llamada al método administerlnsulin. Queremos demostrar que la cantidad de insulina suministrada nunca excede del valor de maxDose. Se consideran todos los posibles caminos hasta administerlnsulin:

Fuente: ingeniería del software lan Sommenville