VALIDACIÓN DE SISTEMAS CRÍTICOS
Los procesos de validación y verifcación demuestran que el sistema cumple con las especifcaciones del cliente. Para sistemas críticos son necesarias pruebas y análisis para evidenciar que el sistema es confable, teniendo en cuenta los siguientes puntos: 1.- ostos de !allos de e"ecución. Los costes y las consecuencias de !allos de e"ecución de los sistemas críticos son muc#os más que los no críticos. $.$.- %alid alidac ació ión n de los los atri atribu buto toss de conf confab abil ilid idad ad.. Pued Puede e tene teners rse e que que rea eali li&a &arr una una demo demost stra raci ción ón !orm !ormal al a los los clie client ntes es que que el sist sistem ema a sati satis! s!ac ace e sus sus reque equeri rimi mien ento toss especifcando la confabilidad 'disponibilidad, fabilidad, seguridad, y protección(. Los costos de %)% para sistemas sistemas críticos son generalmente generalmente son muc#o mayores mayores que para otras clases de sistemas. *n el proceso de garantías o confabilidad es un parte importante de los estándares + /// para la gestión de la calidad, estos estándares requieren documentar los procesos que que se util utili& i&an an y las las ac acti tivi vida dade dess asoc asocia iada dass para para aseg asegur urar ar que que se #an #an segu seguir ir es esto toss procesos. 1. Validac alidación ión de la la Fiabi Fiabilid lidad ad
0ediante la utili&ación de mtricas se puede especifcar los requerimientos de fabilidad de un sistema, el proceso de medir la fabilidad de un sistema comprende cuatro etapas:
+dentifcar perfles
•
•
•
•
Preparar un con"unto de datos de
9plicar pruebas al sistema
alcular fabilidad
e comien&a estudiando los sistemas e2istentes del mismo tipo para establecer un perfl operacional. operacional. 3n perfl operacional operacional identifca las las clases de entradas entradas al sistema y la probabilidad de que estas entradas ocurran en un uso normal. e construye un con"unto de datos de prueba que re4e"an el perfl operacional. *sto signifca que se crean datos de prueba con la misma distribución de probabilidad que los datos datos de prueba prueba para para los sis sistem temas as que se #an #an estudi estudiado ado.. 5orma 5ormalm lment ente, e, se utili utili&a &a un genera generador dor de datos datos de prueb prueba a para para sopor soportar tar este este proceso. e prueba el sistema utili&ando estos datos y se contabili&a el n6mero y tipo de !allos !allos que ocur ocurre ren. n. Los Los instan instantes tes en los que ocur ocurre ren n estos estos !allo !alloss tambi tambin n son registrados. 7espus de que se #a observado un n6mero ero de !allos signifcativos estadísti estadísticame camente, nte, se puede calcular calcular la fabilidad fabilidad del so!t8ar so!t8are e y obtener obtener el valor adecuado de de la mtrica mtrica de fabilidad.
1.1.
Perfles Operacionales
*l perfl operacional del so!t8are re4e"a cómo se utili&ará ste en la práctica, cuando un nuevo sistema so!t8are reempla&a a un sistema e2istente manual o automati&ado, es ra&onablemente !ácil evaluar el patrón de uso probable del nuevo so!t8are este debería corresponderse con el uso del sistema e2istente, con algunas adiciones para las nuevas !uncionalidades que se incluyen en el nuevo so!t8are. *"emplo: Puede especifcarse un perfl 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 mane"ar. 1.2.
Predicción de Fiabilidad
7urante la validación del so!t8are, los gestores tienen que dedicar es!uer&o a las pruebas del sistema, las pruebas pueden detenerse cuando se alcance el nivel requerido de fabilidad del sistema. 3n modelo de crecimiento de fabilidad es un modelo de cómo cambia la fabilidad del sistema a lo largo del tiempo durante el proceso de pruebas. 9 medida que se descubren los !allos del sistema, los de!ectos subyacentes que provocan estos !allos son reparados para que la fabilidad del sistema me"ore durante las pruebas y depuración. *2isten varios modelos de crecimiento de la fabilidad que #an sido derivados de e2perimentos de fabilidad en varios dominios de aplicación di!erentes. ;al y como
*l modelo más simple que ilustra el concepto de crecimiento de la fabilidad es un modelo de !unciones por pasos '>elins?i y 0oranda, 1@$(. La fabilidad crece de !orma constante cada ve& que un de!ecto 'o un con"unto de de!ectos( es descubierto y reparado y una nueva versión del so!t8are es creada.
*ste modelo supone que las reparaciones del so!t8are se implementan siempre correctamente, de !orma que el n6mero de de!ectos del so!t8are y !allos asociados decrece en cada nueva versión del sistema. 9 medida que tienen lugar las reparaciones, la tasa de ocurrencia de !allos del so!t8are 'AB( debería por tanto reducirse, los periodos de tiempo sobre el e"e #ori&ontal re4e"an el tiempo entre entregas del sistema para pruebas, de !orma que normalmente tienen longitudes di!erentes.
0odelos posteriores, como los sugeridos por Little8ood y %errall 'Little8ood y %errall, 1@=( tienen en cuenta estos problemas introduciendo un elemento aleatorio en la me"ora del crecimiento de la fabilidad conseguida por una reparación del so!t8are. 9sí, cada reparación no da como resultado una cantidad igual de la me"ora de la fabilidad, sino que varía dependiendo de la perturbación aleatoria. *l modelo de Little8ood y %errall permite un crecimiento de la fabilidad negativo cuando una reparación del so!t8are introduce errores adicionales. ;ambin modela el #ec#o de que a medida que los de!ectos son reparados, el promedio de me"ora en cuanto a fabilidad por reparación disminuye. La ra&ón de esto es que los de!ectos más probables probablemente sean descubiertos pronto en el proceso de pruebas. La reparación de estos de!ectos contribuye más al crecimiento de la fabilidad. La predicción de la fabilidad del sistema a partir de un modelo de crecimiento de fabilidad tiene dos venta"as principales: 1. Planifcación de las pruebas. 7ado el calendario actual de pruebas, puede predecirse cuándo se completarán las pruebas. i el fnal de las pruebas tiene lugar despus de la !ec#a planifcada de entrega del sistema, entonces puede tenerse que desplegar recursos adicionales para probar y depurar, y así acelerar la tasa de crecimiento de fabilidad. $. Negociaciones con el cliente . 9lgunas veces el modelo de fabilidad muestra que el crecimiento de la fabilidad es muy lento y que se requiere una cantidad de es!uer&o de pruebas desproporcionada para obtener un benefcio relativamente
pequeo. Puede merecer la pena renegociar los requerimientos de fabilidad con el cliente. 7e !orma alternativa, puede ocurrir que el modelo prediga que la fabilidad requerida probablemente nunca será alcan&ada. *n este caso, se tendrán que renegociar con el cliente los requerimientos de la fabilidad del sistema. 2. Garantía de la Seguridad
e puede especifcar la fabilidad de !orma cuantitativa utili&ando alguna mtrica y a continuación medir la fabilidad del sistema completo. La seguridad, sin embargo, no puede especifcarse de !orma cuantitativa y, por lo tanto, no puede medirse cuando se prueba un sistema. La garantía de la seguridad está relacionada con establecer un nivel de confan&a en el sistema que podría variar desde Cmuy ba"oD #asta Cmuy altoD. Esta es una cuestión de "uicio pro!esional basado en evidencias sobre el sistema, su enlomo y su proceso de desarrollo. Los procesos de % ) % para sistemas de seguridad críticos tienen muc#o en com6n con los procesos comparables de cualquier otro sistema con altos requerimientos de fabilidad. e deben reali&ar unas pruebas generales para descubrir el mayor n6mero posible de de!ectos, y cuando resulte apropiado, pueden utili&arse pruebas estadísticas para evaluar la fabilidad del sistema. in embargo, debido a las tasas de !allos ultra ba"as requeridas en muc#os sistemas de seguridad críticos, las pruebas estadísticas no siempre proporcionan una estimación cuantitativa de la fabilidad del sistema. 2.1. Argumentos de la Seguridad
La tcnica más e!ectiva para demostrar la seguridad de un sistema es la demostración por contradicción. e comien&a suponiendo que se está en un estado no seguro, el cual #a sido identifcado por un análisis de contingencias del sistema, y que puede ser alcan&ado e"ecutando el programa. 9 continuación, se anali&a el código de !orma 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.
Podría ser parte de la implementación del sistema de suministro de insulina. 7esarrollar un argumento de seguridad para este código implica demostrar que la dosis de insulina administrada nunca es mayor que alg6n nivel má2imo establecido para cada individuo diabtico, 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 identifca la precondición para el estado inseguro que, en este caso, es que currentDose > maxDose. 7espus se demuestra que todos los caminos del programa conducen a una contradicción de esta aserción no segura. i ste es el caso, la condición no segura no puede ser cierta. Por lo tanto, el sistema es seguro. e pueden estructurar y presentar los argumentos de seguridad de !orma grafca tal como se muestra en la fgura.
Los argumentos de seguridad, seg6n se re4e"a en la citada fgura, son muc#o más cortos que las verifcaciones !ormales de sistemas. Primero se identifca todos los posibles caminos que conducen al estado potencialmente inseguro. e traba"a #acia atrás a partir de este estado no seguro y se considera la 6ltima asignación de todas las variables de estado en cada camino que conduce a l. Pueden omitirse los cálculos previos 'como la sentencia i! 1 en la fgura( en el argumento de seguridad. *n este e"emplo, todo lo que se necesita saber es el con"unto de posibles valores de currentDose inmediatamente antes de que el mtodo administernsuin sea e"ecutado. *n el argumento de seguridad mostrado en la Bigura $F.@, e2isten tres posibles caminos en el programa que conducen a la llamada al mtodo administerlnsulin. Gueremos demostrar que la cantidad de insulina suministrada nunca e2cede del valor de ma27ose. e consideran todos los posibles caminos #asta administerlnsulin: 1. 5inguna rama de la sentencia i! $ es e"ecutada. *sto sólo puede ocurrir si current7ose es mayor o igual que minimun7ose y menor o igual que ma27ose.
$. La rama t#en de la sentencia i! $ es e"ecutada. *n este caso, se asigna el valor de cero a current7ose. Por lo tanto, su postcondición es current7ose H /. =. La rama else-i! de la sentencia i! $ es e"ecutada. *n este caso, se asigna el valor ma27ose a current7ose. Por lo tanto, su postcondición es current7ose H ma27ose. *n los tres casos, las postcondiciones contradicen la precondición no segura de que la dosis administrada es mayor que ma27ose, por lo que el sistema es seguro. 2.2. Garantia del Proceso.
*l documento central de seguridad es el registro de contingencias, en el que se documentan y se lleva un seguimiento de las contingencias identifcadas durante el proceso de especifcación.
