Lectura1 - tognuhome.files.wordpress.com · Lectura2 Capítulo12 Especificacionesde Fiabilidady...

Capítulo 12 – Especificaciones de Fiabilidad y Seguridad

Lectura 1

1Capítulo 12 Especificaciones de Fiabilidad y Seguridad

Temas tratados

² Especificación dirigida a riesgos

² Especificaciones de protección² Especificaciones de seguridad

² Especificación de la fiabilidad del software


Requerimientos de Fiabilidad

² Requerimientos funcionales para definir comprobaciónde errores y recuperación de instalaciones y proteccióncontra fallos del sistema.

² Requerimientos no funcionales definiendo la fiabilidadrequerida y la disponibilidad del sistema.

² Requerimientos excluíbles que definen los estados y condiciones que no deben surgir.


Especificación dirigida a riesgos

² La especificación de los sistemas críticos debe serdirigido por riesgo.

² Este enfoque ha sido ampliamente utilizado en los sistemas de protección y críticos para la seguridad.

² El objetivo del proceso de especificación debe serentender los riesgos (de protección, de seguridad, etc.) enfrentados por el sistema y definir los requerimientosque reduzcan estos riesgos.


Etapas de análisis basado en riesgos

² Identificación de riesgos§ Identificar los riesgos potenciales que puedan surgir.

² Análisis y clasificación de riesgos§ Evaluar la gravedad de cada riesgo.

² Descomposición de riesgos§ Descomponer los riesgos para descubrir sus potenciales causas

fundamentales.

² Evaluación de la reducción de riesgos§ Definir cómo se debe tomar cada riesgo en eliminarse o

reducirse cuando el sistema está diseñado.


Especificación dirigida a riesgos


Análisis de riesgo en fases

² Análisis preliminar de riesgos§ Identifica los riesgos del entorno de sistemas. El objetivo es

desarrollar un conjunto inicial de la seguridad del sistema y los requerimientos de confiabilidad.

² Análisis de riesgos del ciclo de vida§ Identifica los riesgos que surgen durante el diseño y desarrollo.

Por ejemplo, riesgos que están asociados con las tecnologías utilizadas para la construcción del sistema. Los requerimientosse extienden a la protección contra estos riesgos.

² Análisis de riesgo operacional§ Los riesgos asociados con la interfaz y los errores de operador

de usuario del sistema. Requerimientos de protección adicionales se pueden añadir para hacer frente a estos.


Especificaciones de protección

² El objetivo es identificar los requerimientos de protección que aseguren que los fallos del sistema no causenlesiones o muerte, o daños ambientales.

² Identificación de riesgos = Identificación de peligros

² Análisis de riesgos = Evaluación de peligros² Descomposición de riesgos = Análisis de peligros

² La reducción del riesgo = especificación de los requerimientos de protección


Identificación de los peligros

² Identificar los peligros que puedan amenazar el sistema.

² La identificación de peligros puede basarse en diferentes tipos de peligro:§ Peligros físicos§ Peligros eléctricos§ Peligros biológicos§ Peligros de falla de servicio§ Etcétera


Riesgos de la bomba de insulina

² La sobredosis de insulina (falla de servicio).² Dosis insuficiente de insulina (falla de servicio).² Falla de energía debido a la batería agotada (eléctrico).² Interferencia eléctrica con otros equipos médicos

(eléctrico).² Contacto deficiente del sensor y del accionador (físico).² Partes de la máquina se rompen en el cuerpo (físico).² Infección causada por la introducción de la máquina

(biológico).² Reacción alérgica a los materiales o la insulina

(biológico).10Capítulo 12 Especificaciones de Fiabilidad y Seguridad

Evaluación del peligro

² El proceso tiene que ver con la comprensión de la probabilidad de que surja un riesgo y las potencialesconsecuencias si ocurriese un accidente o incidente.

² Los riesgos pueden ser clasificados como:§ Intolerable. Nunca debe surgir o resultar en un accidente§ Tan bajo como sea razonablemente factible (ALARP). Debe

reducir al mínimo la posibilidad de riesgo dadas las restriccionesde costo y horario

§ Aceptable. Las consecuencias de los riesgos son aceptables y no hay costos adicionales que deben ser incurridos para reducirla probabilidad de peligro


La triángulo de riesgo


La aceptación social del riesgo

² La aceptabilidad de un riesgo se determina porconsideraciones humanas, sociales y políticas.

² En la mayoría de las sociedades, los límites entre lasregiones son empujados hacia arriba con el tiempo, esdecir, la sociedad está menos dispuesta a aceptar el riesgo§ Por ejemplo, los costos de la limpieza de la contaminación

pueden ser menores que los costos de la prevención, pero estopuede no ser socialmente aceptable.

² La evaluación del riesgo es subjetiva§ Los riesgos se identifican como probable, poco probable, etc

Esto depende de quién está haciendo la evaluación.


Valoración de peligros

² Estimar la probabilidad del riesgo y la gravedad del riesgo.

² Normalmente no es posible hacer esto precisamente, entonces se utilizan valores relativos como "improbable", "raro", "muy alto", etc.

² El objetivo debe ser para excluir los riesgos que puedansurgir o que tienen alta gravedad.


Clasificación de riesgos de la bomba de insulina

Peligro identificado Probabilidad de Peligros Gravedad del accidente Riesgoestimado

Aceptabilidad

1. Cómputo de sobredosis de insulina

Medio Alto Alto Intolerable

2. Cómputo de dosisinsuficiente de insulina

Medio Bajo Bajo Aceptable

3. Fallo de sistema de monitoreo de hardware

Medio Medio Bajo ALARP

4. Falla de energía Alto Bajo Bajo Aceptable

5. Máquina colocadaincorrectamente

Alto Alto Alto Intolerable

6. Máquina se rompe en el paciente

Bajo Alto Medio ALARP

7. Máquina causa infección

Medio Medio Medio ALARP

8. Interferencia eléctrica Bajo Alto Medio ALARP

9. Reacción alérgica Bajo Bajo Bajo Aceptable


Análisis de peligros

² Preocupados por el descubrimiento de las causasfundamentales de los riesgos en un sistema en particular.

² Las técnicas se han derivado principalmente de los sistemas críticos para la protección y pueden ser§ Técnicas inductivas, de abajo hacia arriba. Comienza con una

falla en el sistema propuesto y evalúa los riesgos que podríanresultar de dicha falla;

§ Técnicas deductivas, de arriba hacia abajo. Comienza con un peligro y deduce cuáles podrían ser las posibles causas.


Análisis del árbol de fallas

² Una técnica deductiva de arriba hacia abajo.

² Poner el riesgo o peligro en la raíz del árbol e identificarlos estados del sistema que podrían llevar a ese peligro.

² Cuando sea necesario, vincular estos con condiciones'y' ó 'o'.

² La meta debe ser el minimizar el número de causasindividuales de falla del sistema.


Un ejemplo de un árbol de fallas de un software


Análisis del árbol de fallas

² Tres condiciones posibles que pueden conducir a la entrega de la dosis incorrecta de insulina§ Medición incorrecta del nivel de azúcar en la sangre§ Falla del sistema de entrega§ Dosis administrada en el momento equivocado

² Mediante el análisis del árbol de fallas, las causasfundamentales de estos peligros relacionados con el software son:§ Error de algoritmo§ Error aritmético


Reducción de riesgos

² El objetivo de este proceso es identificar los requerimientos de confiabilidad que especifican cómo se deben administrar los riesgos y garantizar que no se producen accidentes/incidentes.

² Estrategias de reducción de riesgos§ Evitar el riesgo;§ Detección y eliminación de riesgos;§ Limitación de daños.


Uso de estrategias

² Normalmente, en sistemas críticos, se utiliza unacombinación de estrategias de reducción de riesgos.

² En un sistema de control de planta química, el sistemaincluirá sensores para detectar y corregir el exceso de presión en el reactor.

² Sin embargo, también incluirá un sistema de protecciónindependiente que se abre una válvula de alivio, si se detecta alta presión peligrosa.


Bomba de insulina - Riesgos de software

² Error aritmético§ Un cálculo hace que el valor de una variable se exceda o se

disminuya;§ Tal vez incluir un controlador de excepciones para cada tipo de

error aritmético.

² Error algorítmico§ Comparar la dosis que se suministrará con una dosis anterior o

las dosis máximas seguras. Reduzca la dosis si es demasiadoalta.


Ejemplos de los requerimientos de protección

SR1: El sistema no suministrará una sola dosis de insulina que sea mayor que una dosis máxima especificada para un usuario del sistema.SR2: El sistema no suministrará una dosis acumulativa diaria de insulina que sea mayor que una dosis diaria máxima especificada para un usuario del sistema.SR3: El sistema incluirá un centro de diagnóstico de hardware que se ejecuta al menos cuatro veces por hora.SR4: El sistema incluirá un controlador de excepciones para todas las excepciones que se identifican en la Tabla 3.SR5: La alarma audible sonará cuando se descubra cualquier anomalía de hardware o software y se mostrará un mensaje de diagnóstico, tal como se define en la Tabla 4.SR6: En caso de una alarma, se suspenderá la administración de insulina hasta que el usuario haya restablecido el sistema y apagado la alarma.


Puntos clave

² El análisis de riesgos es una actividad importante en la especificación de los requerimientos de seguridad y fiabilidad. Se trata de identificar los riesgos que pueden resultar en accidentes o incidentes.

² Se puede utilizar un enfoque dirigido a riesgos para comprender los requerimientos de protección para un sistema. Identificas peligros potenciales y éstos se descomponen (utilizando métodos como el análisis del árbol de fallas) para descubrir sus causas fundamentales.

² Los requerimientos de seguridad deben incluirse para garantizar que los riesgos y los accidentes no se producen o, si esto es imposible, para limitar los daños causados por la falla del sistema.


Capítulo 12 – Especificaciones de Fiabilidad y Seguridad

Lectura 2


Especificación de la fiabilidad del sistema

² La fiabilidad es un atributo del sistema medible por lo que los requerimientos de fiabilidad no funcionales pueden serespecificados cuantitativamente. Estos definen el número de fallos que son aceptables durante el uso normal del sistema o el tiempo en el que el sistema debe estar disponible.

² Los requerimientos funcionales de fiabilidad definen las funciones del sistema y del software que evitan, detectan o toleran fallos en el software y así asegurarse de que estas fallas no conduzcan a la falla del sistema.

² Los requerimientos de fiabilidad de software también pueden incluirse para hacer frente a un fallo de hardware o un error del operador.


Proceso de especificación de confiabilidad

² Identificación de riesgos§ Identificar los tipos de falla del sistema que pueden conducir a

pérdidas económicas.

² Análisis de riesgos§ Estimar los costos y consecuencias de los diferentes tipos de

falla de software.

² Descomposición de riesgos§ Identificar las causas fundamentales de la falla del sistema.

² Reducción de riesgos§ Generar especificaciones de fiabilidad, incluyendo

requerimientos cuantitativos que definen los niveles aceptables de falla.


Tipos de falla del sistema

Tipo de falla Descripción

Pérdida de servicio El sistema no está disponible y no puede prestar sus servicios a losusuarios. Usted puede separar esto en la pérdida de servicios críticosy la pérdida de los servicios no críticos, en los que las consecuenciasde un fallo en los servicios no críticos son menos que lasconsecuencias de la falla de servicios críticos.

Entrega de servicios incorrecta El sistema no proporciona un servicio correctamente a los usuarios.Una vez más, esto puede ser especificada en términos de errores oerrores menores y mayores en la prestación de los servicios críticos yno críticos.

Corrupción del sistema/ datos El fallo del sistema causa daños en el mismo sistema o en sus datos.Esto normalmente, pero no necesariamente, estará en conjuncióncon otros tipos de fallos.


Métricas de fiabilidad

² Las métricas de fiabilidad son las unidades de medida de la fiabilidad del sistema.

² La fiabilidad del sistema se mide contando el número de fallos operacionales y, en su caso, relacionando éstos a las demandas hechas en el sistema y el tiempo que el sistema ha estado operacional.

² Se requiere un programa de medición a largo plazo para evaluar la fiabilidad de los sistemas críticos.

² Métricas§ La probabilidad de falla en demanda§ Tasa de incidencia de fallas/tiempo medio al fallo§ Disponibilidad


Probabilidad de fallo en demanda (POFOD)

² Esta es la probabilidad de que el sistema fallará cuandose realiza una solicitud de servicio. Es útil cuando lasdemandas de servicio son intermitentes y relativamentepoco frecuentes.

² Apropiado para los sistemas de protección, donde los servicios se exigen en ocasiones y en los que hay seriasconsecuencias si el servicio no es entregado.

² Relevante para muchos sistemas críticos para la protección con componentes de gestión de excepciones§ Sistema de parada de emergencia en una planta química.


Tasa de incidencia de fallo (ROCOF)

² Refleja la tasa de ocurrencia de fallo en el sistema.

² ROCOF de 0,002 significa 2 fallos son probables en cada 1.000 unidades de tiempo de funcionamiento. Por ejemplo, 2 fallos por cada 1000 horas de funcionamiento.

² Relevante para sistemas donde el sistema tiene que procesar un gran número de peticiones similares en un corto tiempo§ Sistema de procesamiento de tarjetas de crédito, sistema de reservas

aéreas.

² El recíproco de ROCOF es el Tiempo Medio para el Gallo (MTTF)§ Relevante para los sistemas con transacciones largas, es decir, donde el

procesamiento del sistema tarda mucho tiempo (por ejemplo, sistemas de CAD). El MTTF debe ser más largo que la longitud de la transacción esperada.


Disponibilidad

² Medida de la fracción del tiempo que el sistema estádisponible para su uso.

² Toma en cuenta la reparación y el tiempo de reinicio² Una disponibilidad de 0.998 significa que el software

está disponible para 998 de 1000 unidades de tiempo.² Relevante para sistemas de funcionamiento continuo,

sin paros§ sistemas de conmutación telefónica, sistemas de señalización

ferroviaria.


Especificación de disponibilidad

Disponibilidad Explicación

0.9 El sistema está disponible para 90% del tiempo. Esto significa que, enun período de 24 horas (1440 minutos), el sistema no estará disponibledurante 144 minutos.

0.99 En un período de 24 horas, el sistema no está disponible para 14,4minutos.

0.999 El sistema no está disponible durante 84 segundos en un periodo de 24horas.

0.9999 El sistema no está disponible por 8,4 segundos en un período de 24horas. A grandes rasgos, un minuto por semana.


Consecuencias de las fallas

² Al especificar la confiabilidad, no es sólo importan el número de fallos en el sistema, sino también lasconsecuencias de estos fallos.

² Las fallas que tienen consecuencias graves son claramente más dañinos que aquellos en los que la reparación y la recuperación es sencilla.

² En algunos casos, por lo tanto, pueden ser definidasdiferentes especificaciones de fiabilidad para los diferentes tipos de fallos.


Exceso de especificación de fiabilidad

² El exceso de especificación de fiabilidad es una situación en la que se especifica un alto nivel de fiabilidad, pero no es rentable para lograrlo.

² En muchos casos, es más barato aceptar y lidiar con fallos en lugar de evitar que ocurran.

² Para evitar el exceso de especificación§ Especificar los requerimientos de fiabilidad para los diferentes

tipos de fallas. Fallos menores pueden ser aceptables.§ Especificar los requerimientos para los distintos servicios por

separado. Los servicios críticos deben tener los más altos requerimientos de fiabilidad.

§ Decidir si una alta fiabilidad es realmente necesaria o si las metas de confiabilidad se puede lograr de otra manera.


Pasos para una especificación de fiabilidad

² Para cada sub-sistema, analizar las consecuencias de posibles fallos del sistema.

² Desde el análisis de fallos del sistema, particionar los fallos en clases apropiadas.

² Para cada clase de fallo identificado, se establece la fiabilidad utilizando una métrica apropiada. Puedenusarse diferentes métricas para diferentesrequerimientos de fiabilidad.

² Identificar los requerimientos de seguridad funcionalpara reducir las posibilidades de fallos críticos.


Especificación de la bomba de insulina

² La probabilidad de fallo (POFOD) es la métrica más apropiada.

² Los fallos transitorios que pueden ser reparados por las acciones del usuario, como la recalibración de la máquina. Un valor relativamente bajo de POFOD es aceptable (por ejemplo 0.002) - un fallo puede ocurrir en cada 500 demandas.

² Las fallas permanentes requieren que el software sea re-instalado por el fabricante. Esto debería ocurrir no más de una vez al año. La POFOD para esta situación debe ser menor que 0,00002.


Requerimientos de fiabilidad funcional

² Comprobación de los requerimientos que identifican a controles para garantizar que se detectan datos incorrectos antes de que conduce a un fallo.

² Requerimientos de recuperación que están orientados a ayudar al sistema a recuperarse después de producirse un fallo.

² Requerimientos de redundancia que especifican características redundantes del sistema que deben incluirse.

² Requerimientos de proceso para la fiabilidad, que especifican el proceso de desarrollo que se utilizará, también pueden ser incluidos.


Ejemplos de requerimientos funcionales de fiabilidad para MHC-PMS

RR1: Se definirá un rango predefinido para todas las entradas de operador y el sistema comprobará que todas las entradas del operador se encuentran dentro de este rango predefinido. (Comprobación)RR2:Las copias de la base de datos de pacientes deberán mantenerse en dos servidores separados que no están alojados en el mismo edificio. (Recuperación, redundancia)RR3:Programación N-versión se utilizará para implementar el sistema de control de frenado. (Redundancia)RR4:El sistema debe ser implementado en un subconjunto de seguro de Ada y comprobado utilizando análisis estático. (Proceso)


Especificación de seguridad

² La especificación de seguridad tiene algo en común con especificación de los requerimientos de seguridad - en ambos casos, tu preocupación es evitar que suceda algo malo.

² Cuatro diferencias principales§ Los problemas de seguridad son accidentales - el software no está funcionando

en un ambiente hostil. En seguridad, se debe asumir que los atacantes tengan conocimiento de las debilidades del sistema

§ Cuando se producen fallos de seguridad, se puede buscar la causa principal o debilidad que llevó al fallo. Cuando el fallo resulta de un ataque deliberado, el atacante puede ocultar la causa del fallo.

§ El apagado de un sistema puede evitar un fallo relacionado con la seguridad. Causar un apagado puede ser el objetivo de un ataque.

§ Eventos relacionados con la seguridad no se generan a partir de un adversario inteligente. Un atacante puede sondear las defensas a través del tiempo para descubrir los puntos débiles.


Tipos de requerimientos de seguridad

² Requerimientos de identificación.² Requerimientos de autenticación.² Requerimientos de autorización.² Requerimientos de inmunidad.² Requerimientos de integridad.² Requerimientos de detección de intrusiones.² Requerimientos de no-repudio.² Requerimientos de privacidad.² Requerimientos de auditoría de seguridad.² Requerimientos de seguridad de mantenimiento del

sistema. 41Capítulo 12 Especificaciones de Fiabilidad y Seguridad

La proceso preliminar de evaluación del riesgopara los requerimientos de seguridad


Evaluación de riesgos de seguridad

² Identificación de activos§ Identificar los activos clave del sistema (o servicios) que tienen

que ser protegidos.

² Evaluación de valor de activos§ Estimar el valor de los activos identificados.

² Evaluación de la exposición§ Evaluar las pérdidas potenciales asociados a cada activo.

² Identificación de amenazas§ Identificar las amenazas más probables a los activos del sistema


Evaluación de riesgos de seguridad

² Evaluación de ataque§ Descomponer amenazas sobre posibles ataques contra el

sistema y las formas en que éstos pueden ocurrir.

² Identificación de Control§ Proponer los controles que se pueden poner en práctica para

proteger un activo.

² Evaluación de la viabilidad§ Evaluar la viabilidad técnica y el coste de los controles.

² Definición de requerimientos de seguridad§ Definir los requerimientos de seguridad del sistema. Estas

pueden ser los requerimientos de infraestructura o sistema de aplicación.


Análisis de activos en un informe preliminar de evaluación de riesgos para el MHC-PMS

Activo Valor Exposición

La sistema de información Alto. Requerido para admitir todaslas consultas clínicas. Potencialmente crítico para la seguridad.

Alto. La pérdida financiera comoclínicas puede tener que sercancelada. Los costos derestauración del sistema. Posibledaño al paciente si el tratamientono puede ser prescrito.

La base de datos del paciente Alto. Requerido para admitir todaslas consultas clínicas. Potencialmente crítico para la seguridad.

Alto. La pérdida financiera comoclínicas puede tener que sercancelada. Los costos derestauración del sistema. Posibledaño al paciente si el tratamientono puede ser prescrito.

Un registro de cada paciente Normalmente baja, aunque puedeser alta para los pacientes de altoperfil específicos.

Pérdidas directas bajas, peroposible pérdida de reputación.


Análisis de amenazas y control en un informepreliminar de evaluación de riesgos

Amenaza Probabilidad Control Factibilidad

Usuario no autorizadoobtiene acceso comoadministrador delsistema y hace que elsistema no estédisponible

Bajo Sólo permitirá la gestión del sistema desde ubicaciones específicas que son físicamente seguras.

Bajo coste de aplicación pero sedebe tener cuidado con ladistribución de claves y paraasegurar que las claves esténdisponibles en el caso de unaemergencia.

Un usuario no autorizadotiene acceso comousuario del sistema ytiene acceso ainformación confidencial

Alto Requiere que todos losusuarios se autentifiquenmediante un mecanismobiométrico.Registrar todos los cambiosen la información delpaciente para realizar unseguimiento del uso delsistema.

Técnicamente posible, pero es unasolución de alto costo. Resistenciaposible al usuario.

Simple y transparente paraimplementar y también escompatible con la recuperación.


Política de seguridad

² Una política de seguridad organizacional se aplica a todos los sistemas y establece lo que se debe y no se debe permitir.

² Por ejemplo, una política militar podría ser:§ Los lectores no conozcan los documentos cuya clasificación es

igual o por debajo del nivel de los lectores de investigación de antecedentes.

² Una política de seguridad establece las condiciones que deben ser mantenidos por un sistema de seguridad y por lo tanto ayuda a identificar los requerimientos de seguridad del sistema.


Requerimientos de seguridad para el MHC-PMS

² La información del paciente se puede descargar en el inicio de una sesión clínica a una zona segura en el cliente sistema que es utilizado por el personal clínico.

² Toda la información del paciente en el sistema cliente será encriptada.

² La información del paciente se carga en la base de datos después de que una sesión clínica ha terminado y suprimido desde la computadora cliente.

² Un registro en una computadora independiente del servidor de base de datos debe ser mantenido de todos los cambios realizados en la base de datos del sistema.


Especificación formal

² La especificación formal es parte de una colección másgeneral de las técnicas que se conocen como "métodosformales".

² Estos se basan en la representación matemática y análisis de software.

² Los métodos formales incluyen§ Especificación formal;§ Análisis y prueba de la especificación;§ Desarrollo transformacional;§ Verificación de programas.


El uso de métodos formales

² Los principales beneficios de los métodos formales son en la reducción del número de fallos en los sistemas.

² En consecuencia, su principal área de aplicación es en ingeniería de sistemas críticos. Se han realizado variosproyectos exitosos donde se han utilizado los métodosformales en esta área.

² En esta área, el uso de métodos formales es másprobable que sea rentable porque los altos costos de falla del sistema deben ser evitados.


Especificación en el proceso de software

² Las especificaciones y el diseño están inextricablementeentremezclados.

² El diseño arquitectónico es fundamental para estructuraruna especificacón y el proceso de especificación.

² Las especificaciones formales se expresan en unanotación matemática con vocabulario, sintaxis y semántica definidos precisamente.


Formal especificación de un software basado en el plan proceso


Beneficios de la especificación formal

² El desarrollo de una especificación formal requiere los requerimientos del sistema para ser analizadas en detalle. Esto ayuda a detectar problemas, inconsistencias e incompletitud de los requerimientos.

² A medida que la especificación es expresada en un lenguaje formal, se puede analizar automáticamente para descubrir inconsistencias e incompletitud.

² Si se utiliza un método formal, como el método B, se puede transformar la especificación formal en un programa"correcto".

² Los costos de las pruebas del programa podrán ser reducidos si el programa se verificó formalmente contra su especificación.


La aceptación de los métodos formales

² Los métodos formales han tenido un impacto limitado en el desarrollo de software práctico:§ Propietarios de problemas no pueden entender una

especificación formal y por tanto no puede evaluar si se trata de una representación exacta de sus requerimientos.

§ Es fácil evaluar los costos de desarrollar una especificación formal, pero es más difícil evaluar los beneficios. Por lo tanto, los gerentes pueden no estar dispuestos a invertir en métodos formales.

§ Los ingenieros de software no están familiarizados con este enfoque y por lo tanto son reacios a proponer el uso de MF.

§ Los métodos formales siguen siendo difíciles de escalar hasta grandes sistemas.

§ La especificación formal no es realmente compatible con los métodos de desarrollo ágil.


Puntos clave

² Los requerimientos de confiabilidad se pueden definir cuantitativamente. Éstos incluyen la probabilidad de fallo en demanda (POFOD), la tasa de ocurrencia de fallos (ROCOF) y disponibilidad (DISP).

² Los requerimientos de seguridad son más difíciles de identificar que los requerimientos de protección debido a que un atacante de sistema puede utilizar el conocimiento de las vulnerabilidades del sistema para planificar un ataque al sistema, y se puede aprender acerca de las vulnerabilidades de los ataques fallidos.

² Para especificar los requerimientos de seguridad, es necesario identificar los activos que van a ser protegidos y definir cómo se deben utilizar las técnicas y la tecnología de seguridad para proteger estos activos.

² Los métodos formales de desarrollo de software se basan en una especificación del sistema que se expresa como un modelo matemático. El uso de métodos formales evita la ambigüedad en una especificación de sistemas críticos.


Lectura1 - tognuhome.files.wordpress.com · Lectura2 Capítulo12 Especificacionesde Fiabilidady...

Documents

Transcript of Lectura1 - tognuhome.files.wordpress.com · Lectura2 Capítulo12 Especificacionesde Fiabilidady...