Safety y Requisitos No Funcionales
Anuncio
Safety y Requisitos No Funcionales Resumen de Trabajo Tutelado , Curso 2005-2006 Doctorando: Oscar Díez González Tutor: Andrés Silva Safety y Requisitos no funcionales Trabajo de Investigación Facultad de Informática 1. Indice 1. 2. 3. 4. Indice ........................................................................................................................................................ 2 Introducción.............................................................................................................................................. 2 Safety ........................................................................................................................................................ 3 Requisitos no funcionales ......................................................................................................................... 3 4.1. Safety y Requisitos no funcionales.................................................................................................. 3 5. Modelos de RNF (NFR) ........................................................................................................................... 3 5.1. NFR Framework de Chung ............................................................................................................. 3 5.1.1. Catálogos de Conocimiento ..................................................................................................... 4 5.2. NFR con UML................................................................................................................................. 4 5.2.1. Integración con Requisitos Funcionales................................................................................... 5 6. Propuestas de la Industria ......................................................................................................................... 6 6.1. Transporte........................................................................................................................................ 6 6.1.1. EN 50128:1997 Railway Applications: Software para el control y sistemas de protección de Trenes 6 6.1.2. Directriz para el desarrollo en Software de vehículos (MISRA), 1994 ................................... 7 6.2. Aeroespacial .................................................................................................................................... 7 6.2.1. RTCA/DO-178B ...................................................................................................................... 7 6.2.2. ECSS. Agencia Espacial Europea ............................................................................................ 8 6.2.3. NASA-STD-8719.13A y NASA GB-1740.13-96.................................................................... 9 6.3. Defensa............................................................................................................................................ 9 6.3.1. MIL-STD-882D: US DoDefense ............................................................................................. 9 6.3.2. DEF STAN 00-55: UK Ministry of Defence ......................................................................... 10 6.4. Nuclear .......................................................................................................................................... 11 6.4.1. IEC 60880: Software para ordenadores en plantas nucleares ................................................ 11 7. Estándares ............................................................................................................................................... 11 7.1. IEC61508-3 International Electrotechnical Comisión .................................................................. 11 7.2. SEMSPLC, IEE Guía Técnica 8.................................................................................................... 12 8. Conclusión .............................................................................................................................................. 13 9. Anexo A. Estandares de Software Safety ............................................................................................... 14 10. Anexo B. Tabla comparativa de Estandares ......................................................................................... 15 11. Bibliografía........................................................................................................................................... 16 2. Introducción Los sistemas y subsistemas basados en software cada vez son mas utilizados en todo tipo de productos y sistemas (automóviles, trenes, sistemas quirúrgicos, control aéreo, plantas nucleares), muchos de los cuales son críticos para la seguridad de las personas que los utilizan. Dado el mayor uso y la mayor complejidad de estos sistemas, el riesgo de producirse un error o accidente debido al uso de software es cada vez mayor. Como se vera mas adelante una parte importante a la hora de asegurar el buen funcionamiento de estos sistemas y de evitar accidentes es cerciorarse que los requisitos del sistema, y en particular los requisitos no funcionales que afectan al “safety” en el sistema se recojan y se plasmen el los requisitos del sistema y se incorporen al diseño. En este trabajo se presentaran algunas de las opciones que existen para recoger y representar estos requisitos (Safety y requisitos no funcionales), así como los usados por las distintas industrias junto con los actuales estándares utilizados y se intentara comparar estas opciones para presentar los posibles vacíos que existen actualmente. Oscar Diez 2/16 2006 Safety y Requisitos no funcionales Trabajo de Investigación Facultad de Informática 3. Safety Se va utilizar el término ingles ‘safety’ por que no encuentro una palabra exacta que pueda utilizar en castellano. La traducción más común seria seguridad, pero eso nos lleva a equivocarnos con la palabra ‘security’, también traducida como seguridad pero con un significado distinto. Por este motivo voy a mantener el termino ‘safety’ a lo largo del presente documento. Como define Modugno [5], un sistema seguro “safe”, es el que esta libre de accidentes o perdidas inaceptables. Cuando hablamos de ‘safety’ en un sistema, normalmente no se habla de un sistema 100% seguro, sino como Levenson [15] y Littlewood [16] dicen, el objetivo es tener un sistema lo suficientemente seguro sin por ello gastar mas recursos o menos recursos de los necesarios para su desarrollo. Un ejemplo es el agua, cuando se dice que es seguro beber agua no implica que el agua esta completamente limpia de microbios y otros contaminantes, sino que estos son mas bajos que el nivel considerado seguro para ser agua potable. Es por ello, que estos niveles de seguridad deben ser establecidos para cada producto, diseño, y el uso que se haga de el. 4. Requisitos no funcionales Es muy difícil establecer una separación entre requisitos funcionales y no funcionales, ya que la decisión de si es uno u otro puede venir por el nivel de detalle del documento de requisitos. Además, los requisitos no funcionales son difíciles de expresar, y mucho más de ser recogidos en un documento de requisitos utilizando las mismas técnicas que para los requisitos funcionales[14]. Hay que tener en cuenta, que normalmente, los errores debidos a requisitos no funcionales son los mas difíciles y caros de resolver. Los requisitos no funcionales deben establecer restricciones en el producto que esta siendo desarrollado, en el proceso de desarrollo y en restricciones especificas que el producto pueda tener. Una buena definición de requisito no funcional es la dada por Thayer [4]: es un requisito software que describe no lo que el software hará, sino como lo hará, como por ejemplo, requisitos de rendimiento. Los requisitos no funcionales son difíciles de verificar/testear, y por ello son evaluados subjetivamente. 4.1. Safety y Requisitos no funcionales Actualmente no existe un consenso sobre el significado de ‘safety requirement’. Algunas veces hace referencia todos los requisitos (ya sean funcionales o no funcionales) de los sistemas relacionados con ‘safety’. Otras veces se refiere al subconjunto de requisitos que están directamente relacionados con asegurar un correcto y seguro funcionamiento del sistema o requisitos en sistemas de protección que están diseñados para proteger contra accidentes. [1] 5. Modelos de RNF (NFR) 5.1. NFR Framework de Chung El framework de NFR creado por Chung [2] es uno de los trabajos mas completos en lo referente a requisitos no funcionales (NFR) y en el propone una estructura que usa los requisitos no funcionales para dirigir el proceso de diseño. Uno de los conceptos principales son los ‘softgoal’ que representa un objetivo que no tiene definidas claramente los criterios para definir si es satisfecho o no (suelen ser subjetivos). El modelo ofrece una estructura para representar y guardar los procesos de diseño y razonamiento en gráficos, llamados ‘softgoal interdependency graphs (SIGs)’. El modelo también ofrece la catalogación de conocimiento sobre los RNF y diseño, incluyendo conocimiento sobre técnicas de desarrollo. [2] Estos gráficos (SIG) recogen las consideraciones del desarrollador sobre los softgoals, y muestra la interdependencia entre estos softgoals. Para ello muestra los softgoals como nubes representando los requisitos principales en la parte superior del grafico, mostrando con líneas los enlaces de interdependencia, y utilizando etiquetas para representar el grado en el que el softgoal es conseguido. Oscar Diez 3/16 2006 Safety y Requisitos no funcionales Trabajo de Investigación Facultad de Informática Usabilidad [Funcion Usuario] Que de el servicio [Sistema de Precio] Componentes Del cliente ++ Componentes del servidor Utiliza mucho tiempo y es dificil de distribuir e instalar (fat client) Instalacion Soporte Tecnico -- -- ++ ++ Aplicacion de Cliente a medida Sistema Visualizacion Generico universal Navegador Web Fig.1 . Ejemplo de SIG [12] 5.1.1. Catálogos de Conocimiento Los desarrolladores pueden utilizar este marco como una base de conocimiento de previos proyectos organizados en tres tipos de catálogos, uno de conocimiento sobre determinados tipos de RFN, junto con sus conceptos y terminología. Otro tipo de catalogo usado para organizar las técnicas de desarrollo que ayudan a cumplir los requisitos, y el tercero muestra las interdependencias implícitas entre los distintos ‘softgoals’. El conocimiento es recogido en estos catálogos puede venir de distintas fuentes, como libros, su propia experiencia, o especialistas en la industria para conocimiento especifico en un determinado dominio. En concreto, el catalogo sobre los determinados tipos de RNF será el que se use para ir recogiendo estos requisitos en una jerarquía. Para recoger los RNF se construye un SIG (Softgoal interdependency graph) en el que se plasman los principales requisitos no funcionales que el sistema a desarrollar debe cumplir. Estos requisitos son NFR softgoals, que deberán ser priorizados, clarificados, elaborados, y descompuestos en ‘softgoals’ mas específicos mas adelante. Al final de todo este proceso se deben obtener soluciones que pueden ser aplicadas al sistema a desarrollar, presentando posibles alternativas, y escogiendo las que mas se adecuen al sistema a desarrollar. Tambien se puede relacionar gráficamente en el mismo SIG la interdependencia con los requisitos funcionales, aunque como se comenta mas adelante, este proceso no se trata con el suficiente detalle. 5.2. NFR con UML Aunque el anterior modelo es uno de los trabajos más completos en lo referente a requisitos no funcionales, no se trata en detalle la integración de estos RNF con los requisitos funcionales. Es por ello que existen varias propuestas para poder llenar ese vacío. La que se presenta aquí es la que se realiza utilizando UML y sus respectivas representaciones para incorporar los RNF e integrarlos con los funcionales [6]. En este caso se considera que el proceso de desarrollo esta compuesto de dos ciclos independientes, uno que se encarga de los aspectos funcionales y otro de los aspectos no funcionales, y se establecen puntos de convergencia en estos dos ciclos. Mediante estos puntos de convergencia se podrán se pueden añadir a la Oscar Diez 4/16 2006 Safety y Requisitos no funcionales Trabajo de Investigación Facultad de Informática vista funcional todas las acciones y datos que serán necesarios para satisfacer la vista no funcional. Para ello se utilizaran diagramas de clase de clases UML para expresar los RNF. En este modelo se utiliza un LEL (Lenguage Extended Lexicon) en el cual se registra todo el vocabulario del dominio del Sistema, de forma que se pueda entender el lenguaje del problema sin preocuparse demasiado en entender el problema. Y recogerá información relacionada con requisitos funcionales y no funcionales, así como sus interdependencias. Pero para la representación de los RNF se usa la misma notación y los mismos diagramas SIG que Chung propone, representado los softgoals/subsoftgoals en un estructura de árbol jerárquica, y de igual forma que en modelo de Chung, se priorizan, se descomponen y al final se “operazionalizan”, lo que quiere decir, que se obtienen requisitos funcionales para satisfacer los no funcionales. Estas “operazionalizaciones” pueden ser dinámicas (que se refieren a conceptos abstractos y requieren mas análisis) y las estáticas (que implican la necesidad de utilizar algún dato en el diseño para guardar información que es necesaria para satisfacer el RNF). En la figura 2 se puede ver un ejemplo de grafico de RNF [6] en el que se detalla la seguridad en un sistema de luces de una habitación. S S Safety [Habitacion] Safety [Habitacion. Luz de ambiente. Luz ambiente actual >= Iluminacion safe ] S Safety [Habitacion. Luz de ambiente. Iluminacion safe = 14 lux ] S Safety [Habitacion. Mal Funcionamiento] S Safety S [Habitacion. Mal Funcionamiento de OLS ] S S Safety [Habitacion. Mal Funcionamiento de OLS Todos CLG encendidos] Safety [Habitacion. Mal Funcionamiento Usuario Es informado] Safety [Habitacion. Mal Funcionamiento Detector de movimiento] S Safety [Habitacion. Mal Funcionamiento FM Es informado] S Safety [Habitacion. Mal Funcionamiento Detector de movimiento Poner habitacion como ocupada] Fig.2 Ejemplo de un grafico de RNF. [6] Para construir el modelo de RNF se buscara en el LEL por información que expresen la necesidad de RNF. Y por cada RNF se debe crear un grafico que exprese todas las “operalizaciones” necesarias para satisfacer ese RNF, así como las interdepencias entre estos RNFs, como por ejemplo, un RNF que hace referencia a seguridad puede tener un impacto negativo en otro RNF que hace referencia a usabilidad. 5.2.1. Integración con Requisitos Funcionales Para hacer la integración se utilizara el Lexicon LEL como punto común entre los gráficos de RNFs y los diagramas de clases. Para ello, toda raíz del grafico de RNF debe referir a un símbolo del LEL y toda clase del diagrama de clases tiene que ser nombrada utilizando un símbolo del LEL. De esta forma no solo se facilita la integración sino que también se validan ambos modelos. El modelo de integración se centra en la búsqueda de un símbolo que aparezca en los dos modelos y en evaluar el impacto de añadir las operalizaciones de RNF al diagrama de clases. El proceso seria seleccionar una clase del diagrama de clases, y buscar en los diagramas de RNF por la ocurrencia de esta clase. Para cada grafico en donde encontramos el nombre de la clase que buscamos, debemos identificar las operalizaciones dinámicas y estáticas. Y debemos comprobar si las operaciones, en el Oscar Diez 5/16 2006 Safety y Requisitos no funcionales Trabajo de Investigación Facultad de Informática caso de operalizaciones dinámicas, y los atributos, en el caso de operalizaciones estáticas, que pertenecen a la clase cumplen con las necesidades expresadas en el grafico de RNF. Y si no lo cumplen, debemos añadir atributos y operaciones para que lo cumplan. En algunos casos, se puede llegar a la inclusión de nuevas clases para satisfacer los RNFs. Una vez incorporadas las nuevas clases/operaciones/atributos, se procera según la metodología UML para el resto del proceso. 6. Propuestas de la Industria Una vez presentado los anteriores modelos para recoger los RNF e incorporarlos en el sistema, se presentaran desde el punto de vista de la recogida de requisitos en primer lugar las propuestas que la industria utiliza en cada una de sus principales ramas así como los estándares que existen al respecto. 6.1. Transporte El software juega un papel fundamental en la mayoría de los sistemas de transporte de tierra actualmente, tanto en trenes como en automóviles. Estos sistemas tienen características propias que los diferencian del resto de sistemas y por eso existen estándares específicos para estos sistemas. El “Safety” es estos sistemas esta muy determinado por las condiciones de la carretera o via, las condiciones medioambientales, nivel de destreza y conocimiento de los operadores y personal de mantenimiento y el diseño del vehiculo en lo referente a seguridad y fiabilidad. Los estandares son: 6.1.1. EN 50128:1997 Railway Applications: Software para el control y sistemas de protección de Trenes Este estándar fue preparado por el subcomité 9XA del comité técnico 9X de CENELEC (Normas Europeas), y es parte de un grupo de estándares sobre seguridad “safety” y fiabilidad en sistemas de ferrocarril. Entre otras muchos puntos el estándar cubre los procedimientos y requisitos técnicos para el desarrollo de sistemas electrónicos programables usados en sistemas de control y protección de ferrocarril. El estándar se organiza sobre el concepto de Niveles de Integridad de Software (Software Integrity level SIL), que indica el nivel de riesgo asociado con el uso de un sistema software, definiendo cinco niveles (0 no relacionado con la seguridad, 1 bajo, 2 medio, 3 alto, y 4 muy alto). Hay que diferenciar el concepto de SIL del de riesgo, ya que el riesgo esta asociado a un hazard determinado, y el SIL en cambio se asocia con la integridad de una guncion o sistema. De acuerdo con el estándar, cuanto más alto es el SIL, menos probable es que un fallo peligroso de un sistema software sea causado por una especificación software o un fallo en el diseño. El SIL para un sistema, subsistema, o componente particular debe ser descrito durante la especificación de requisitos del software. El estándar no especifica una metodología de desarrollo de software particular, pero si identifica varias fases de desarrollo, siendo la primera la especificación de requisitos. El estándar asume que el ciclo de desarrollo del software comienza tras haber asignado al software los requisitos funcionales y los no funcionales como safety, fiabilidad, rendimiento y seguridad. En lo referente a la especificación de requisitos, el estándar EN 50128 hace referencia a ISO/IEC 9126 para identificar las categorías de requisitos que son aplicables a sistema de protección y control de trenes como safety. El estándar dice que estos requisitos deben ser completos, consistentes, precisos, no ambiguos, entendibles y verificables. Además se debe especificar el SIL para todos los componentes del software estén o no relacionados con la seguridad “safety”, y dependiendo del nivel de SIL se usaran unas técnicas u otras durante la fase de recogida de requisitos (Metodologías estructuradas SIL 1-4, y métodos formales para 3-4). Al final se obtiene la especificación de requisitos software y la matriz de trazabilidad de requisitos (RTM) que será actualizada a lo largo del ciclo de vida para demostrar que todos los requisitos se pueden cumplir. Oscar Diez 6/16 2006 Safety y Requisitos no funcionales Trabajo de Investigación Facultad de Informática Este estándar de la industria hace referencia a la recogida de los requisitos de safety y a las distintas metodologías que se pueden utilizar dependiendo del tipo de requisitos y el riesgo que estos tengan, pero deja la decisión de metodología al desarrollador y hay que tener en cuenta que estas técnicas son las mismas que se usan para los requisitos funcionales. 6.1.2. Directriz para el desarrollo en Software de vehículos (MISRA), 1994 La Asociación de la fiabilidad de industria del motor (Motor Industry Reliability Association – MISRA) fue creada basada en una iniciativa del Reino Unido para abordar los problemas de fiabilidad y seguridad (safety) presentados en la industria automovilística, ya que cada vez mas esta industria depende mas del software en la construcción de los vehículos. La directriz enlaza las actividades de software al ciclo de vida de desarrollo del vehiculo de una forma integral. Se identifican siete actividades software clave (Planificación del proyecto, integridad, especificación de requisitos, diseño, programación, pruebas, soporte del producto). En lo que se refiere a la especificación de requisitos, indica que la especificación de requisitos software debe de ser derivada y debe de ser consistente con la especificación del vehiculo. Se propone dividir los requisitos en tres categorías, requisitos funcionales, requisitos de seguridad (safety), y requisitos no funcionales. Los requisitos de safety a su vez son subdivididos en requisitos funcionales de safety y requisitos de integridad de safety utilizando la siguiente jerarquía: Requisitos funcionales Requisitos de Safety Req. Funcionales de safety Req. De Integridad de safety Control de error Evitar faltas/errores Requisitos no funcionales Los requisitos de Safety deben identificar las técnicas de diseño necesarias para conseguir el control de errores y prevenir fallos. Siendo muy importante establecer limites en el sistema. Se puede ver que estas directrices adoptadas por la industria del automóvil tiene en cuenta los requisitos de seguridad como requisitos distintos de los funcionales, e incluso define distintas categorías de requisitos de seguridad para tratarlos de distintas formas, además incluye un apartado para los RNF, distintos de los requisitos de seguridad, lo que refuerza aun mas la idea de la importancia de los requisitos de safety en el software. 6.2. Aeroespacial El software es cada vez mas usado en todas las vertientes de la industria aeroespacial, ya sea comercial, aeroespacial, militar,… Las medidas de seguridad aquí suelen estar reguladas por autoridades publicas, y normalmente los aviones/naves son sistemas críticos en lo referente a safety/seguridad. 6.2.1. RTCA/DO-178B Este estándar es el principal a la hora de obtener la certificación para software usado en aviación comercial en la Unión Europea y en los Estados Unidos, lo que implica que sea ampliamente utilizado. El estándar esta construido sobre dos conceptos principales, la categorización de condiciones de fallo (catastrófico, peligroso/muy alto, alto, bajo, y sin efecto), y la definición de niveles de software o la Oscar Diez 7/16 2006 Safety y Requisitos no funcionales Trabajo de Investigación Facultad de Informática contribución del software a condiciones de potenciales fallos, y el nivel es asignado por componente software o función. El estándar se basa en seis procesos software, en lugar de utilizar un ciclo de vida de desarrollo como el resto. Estos procesos son la planificación del ciclo de vida de software, desarrollo, verificación, gestión de la configuración del software, comprobación de la calidad del software, y certificación. Como se puede ver no existe una fase especifica para recoger requisitos, y lo introduce como un subproceso del proceso de desarrollo del software. [13] Dentro de este subproceso de requisitos, los requisitos de fiabilidad y safety se obtienen de la especificación de requisitos del sistema, además de incluir otros del análisis de riesgos del sistema. Una vez recogidos los requisitos estos son categorizados como requisitos funcionales, rendimiento, safety, fiabilidad o seguridad (security). Los requisitos son analizados para verificar que son correctos, completos, no ambiguos, consistentes, verificables y que no contienen condiciones no definidas. Al final de este subproceso se obtendrá una especificación de requisitos que servirá de entrada para el siguiente subproceso, el de arquitectura, en el cual diferentes arquitecturas son examinadas para determinar si satisfacen los requisitos, en especial los de safety. En este estándar se hace una distinción de los requisitos funcionales y los no funcionales, identificando dentro de los RNF los de safety como unos de los más importantes. Sin embargo el proceso de recogida de requisitos esta considerado como un subproceso del diseño y no como un proceso en si mismo, no dándole la importancia que le dan el resto de los estándares a esta fase. Tampoco hace referencia a técnicas/herramientas para la incorporación de estos requisitos no funciones o de safety al sistema.[7] 6.2.2. ECSS. Agencia Espacial Europea La administración para la cooperación Europea para la estandarización del espacio (ECSS) presento en 1996 unos estándares para los sistemas y productos utilizados en el espacio. Estos estándares son el resultado de la cooperación entre la agencia espacial europea, las agencias espaciales nacionales y las asociaciones industriales europeas para desarrollar unos estándares comunes. Estos estándares están organizados en tres niveles, cada uno de los niveles con más detalle y más específico que el anterior. El nivel 1 (ECSS-Q-00A) es el documento de control, el nivel 2 (ECSS-Q-20A, ECSS-Q30A, ECSS-Q-40A, ECSS-Q-80A) implementa los objetivos del nivel 1 dentro de las disciplinas de ingeniería, como safety. Y el nivel 3 (ECSS-Q-80-2, ECSS-Q-80-3, ECSS-Q-80-4) incluye los aspectos de implementación del nivel 2 y son definidos según sean necesarios. Estos estándares definen el marco de referencia de gestión de calidad que debe ser usado en un proyecto, tanto por proveedores como por los que adquieren el software, como los procesos y las actividades del ciclo de vida asociadas deben ser definidas, y las características de calidad requeridas por el producto. El estándar define seis fases del ciclo de vida, 0: Análisis de la misión e identificación de necesidades, A: para análisis de viabilidad, B: para la definición preliminar, C/D: definición detallada y producción, E: operacional, F: Retirada del producto. El ciclo de vida de software en un subconjunto del ciclo de vida global y se integra con el. Una o mas revisiones de safety deben de realizarse en cada fase, por ejemplo, para la fase A se debe realizar una revisión preliminar de requisitos, en la B una revisión de requisitos del sistema y una revisión preliminar de diseño, y así para cada una de las fases. Durante la fase de análisis de requisitos, estos son clasificados como funcionales, de rendimiento, de safety, de seguridad (Security), y de fiabilidad. Y dentro de los requisitos de safety, se dividen en críticos y relacionados con safety. Se acuerda un método entre los proveedores y los que adquieren el software para hacer y controlar los cambios a los requisitos. También se definen requisitos de fiabilidad para las funciones de sistema implementadas en software así como para la interacción entre software y hardware. Estos requisitos se utilizan para optimizar el diseño del Oscar Diez 8/16 2006 Safety y Requisitos no funcionales Trabajo de Investigación Facultad de Informática sistema. Se realiza un análisis de criticalidad que incluye identificar funciones y componentes que son críticos para conseguir los objetivos. Al final de esta fase se obtiene una especificación de requisitos software junto a la matriz de trazabilidad de requisitos, que es utilizada para la siguiente fase, la de diseño, en la cual se establecen métodos y herramientas para facilitar y medir el progreso de cumplimiento de los objetivos de safety y fiabilidad. Este estándar también hace hincapié en la reutilización de software y como esta afecta al safety y a la fiabilidad del sistema, en parte debido al problema de la reutilización de software en el fallo del Ariane 5. La definición del estándar es muy completa y al estar dividido en tres niveles permite llegar a mayor nivel en determinados puntos del estándar, como el uso de ciertas técnicas y herramientas. También dedica una fase a la recogida de requisitos, y pese a que no agrupa a los RNF en un grupo, si distingue estos de los funcionales y en concreto los de safety los trata en mas detalle, estableciendo dos categorías, los críticos y relacionados con safety. 6.2.3. NASA-STD-8719.13A y NASA GB-1740.13-96 Los dos estándares se complementan entre si. El STD-8719.13A establece el que y el por que del software safety en lo referente a la planificación, desarrollo, y análisis [9]. El GB-1740.13-96 se centra en el como. Los estándares presentan una metodología de seguridad (safety) en los programas de la NASA y describe las actividades necesarias para asegurar que la seguridad (safety) es incorporada en el software adquirido o desarrollado por la NASA. Para conseguir esto se establecen un ciclo de vida en 7 fases (concepción e iniciación, requisitos, arquitectura, diseño detallado, implementación, integración y pruebas, y operaciones y mantenimiento) para integrar las actividades de safety en el desarrollo, y no hace referencia a ninguna metodología de desarrollo. También identifica tres actividades como tareas independientes durante las fases, entre las que se encuentra la trazabilidad de los requisitos de safety. [7] En la fase de requisitos se explica que los requisitos de safety del software pueden venir de dos fuentes: los requisitos que provienen de la especificación de seguridad (Safety) del sistema, y los requisitos que son derivados del análisis de riesgos, para luego obtener recomendaciones de safety para las próximas fases. Los requisitos son categorizados durante el análisis de requisitos como críticos respecto al safety, relacionados con safety, y no relacionados con safety. Y lo que se pretende es identificar los que son críticos y los relacionados con safety, y los relaciona con los posibles peligros que pueden conllevar, clasificando estos peligros en función de las consecuencias y su probabilidad de ocurrencia. Al final lo que se busca es dar mas importancia a los requisitos que sean mas importantes desde el punto de vista del peligro que puedan ocasionar si no se tienen en cuenta. [9] Este estándar enlaza la recogida de requisitos con el control de riesgos, incluyendo en detalle como deben evaluarse los requisitos. Pero aunque se centra en los requisitos de safety, no hace una diferenciación clara a la hora de tratar el resto de RNF. 6.3. Defensa Debido al uso de software en cada vez mas sistemas de defensa, y al desarrollo de nuevas armas como misiles o armas nucleares, y a los riesgos que conlleva el uso de estos sistemas, se ha realizado desde el principio un gran enfoque en seguridad (safety) para estos sistemas, siendo uno de los primeros sectores industriales en hacer este enfoque y continúan siendo pioneros. Se van a tratar dos estándares, uno de los EEUU y el otro del Reino Unido con bastantes similitudes. 6.3.1. MIL-STD-882D: US DoDefense Este estándar (MIL-STD-882D Mishap Risk Management) fue creado por el departamento de defensa Norteamericano en 1977 y se produjo una nueva versión en 1984, siendo la primera en utilizar el termino Oscar Diez 9/16 2006 Safety y Requisitos no funcionales Trabajo de Investigación Facultad de Informática “Software Safety”. Es importante destacar que este estándar como su propio nombre indica se centra en una gestión y control de riesgos para productos militares, y se hace referencia a otros estándares para requisitos software generales. El primer paso es el desarrollo de un plan de Seguridad (safety) en el sistema, en el que se describen las actividades y tareas para implementar el programa de safety. Dentro de este plan se deben recoger los requisitos de verificación para asegurar el safety en todo el proceso, así como los requisitos de certificación para el software y los dispositivos de safety. A partir de aquí el estándar indica que se debe realizar un análisis de riesgos para descubrir los peligros potenciales. Se realiza un control de riesgos según se van identificando los posibles peligros para eliminarlos o mitigarlos hasta que todos los peligros han sido eliminados o controlados a un nivel aceptable. Dentro de este control de riesgos se realiza una especificación de requisitos de fiabilidad y seguridad (safety) junto con su criterio de evaluación. Cada uno de los requisitos de seguridad (safety) del software son documentados en la especificación del sistema o subsistema apropiado, junto con los criterios objetivos para poder verificar que han sido cumplidos. A partir de aquí se utilizaran diversas técnicas para eliminar o controlar esos posibles peligros, detallando incluso ejemplos de características de seguridad para sistemas para controlar esos riesgos. Planes y pruebas de seguridad deben ser realizados a partir de los requisitos de seguridad (safety) para demostrar que los requisitos son completos, que han sido cumplidos, y que el riesgo residual ha sido controlado a un nivel aceptable, y por lo tanto el sistema puede operar de forma segura en el entorno deseado. Como se puede ver el estándar se basa en un análisis de riesgos para obtener los requisitos de safety, con las ventajas y desventajas que esto conlleva. El estándar da unas pautas a nivel de herramientas así como a nivel incluso de programación en ciertos escenarios. No se ve como en el resto una clara distinción entre RFN y RNF, y se refiere solo a los requisitos de safety, dejando el resto para ser tratados con otros estándares. 6.3.2. DEF STAN 00-55: UK Ministry of Defence El DEF STAN 00-55 (Requirements for safety related software) forma parte de una serie de estándares creados por el ministerio de defensa del Reino Unido. El estándar esta basado en el 00-56, que es una guía para la gestión de la seguridad (safety) en los sistemas de defensa. El estándar recoge las mejores prácticas para el desarrollo y análisis de safety en sistemas software de forma que estas técnicas puedan ser aplicadas a sistemas de defensa. El estándar se basa en un ciclo de vida formado por seis procesos: planificación de programa del sistema de seguridad (Safety), definición de requisitos de seguridad (safety), realización de un análisis de peligros, asignación de objetivos de safety/ requisitos a componentes del sistema, asegurar que el sistema cumple los objetivos de seguridad, y verificar que el resultado es adecuado. Dentro de la segunda fase, se analizan y especifican los requisitos funcionales, de rendimiento, de safety, de fiabilidad, y seguridad y las restricciones que se derivan de los requisitos del sistema asignados al software. Para ello los requisitos deben ser descompuestos con suficiente detalle. Estos requisitos deben ser especificados por cada peligro en términos de probabilidad de ocurrencia y por cada categoría de importancia en caso de accidente. Los requisitos deben ser recogidos en un notación formal, y estos requisitos expresados con notación formal deben ser probamos mediante un versión ejecutable de la especificación formal (una especie de prototipo). Una vez probados, se deben realizar una revisión formal de safety y fiabilidad para asegurar que cumplen el código de práctica de diseño, que cumplen los requisitos de fiabilidad y safety y que son correctos, consistentes y no son ambiguos. Además se recomienda realizar un estudio para descubrir posibles peligros asociados con el uso del sistema en el entorno intencionado. Este estándar reúne los conceptos de ciclo de vida de los anteriores estándares y el uso de gestión de riesgos del estándar de defensa norteamericano. Existe una fase propia para la recogida de requisitos y los requisitos de safety son tratados de forma diferente que los funcionales. Oscar Diez 10/16 2006 Safety y Requisitos no funcionales Trabajo de Investigación Facultad de Informática 6.4. Nuclear Al igual que en sistemas de defensa, existe una larga historia en el área de seguridad (safety) en los sistemas de energía nuclear, y mas desde que los sistemas de control de plantas nucleares pasaron a ser creados en software. 6.4.1. IEC 60880: Software para ordenadores en plantas nucleares Creado por el subcomité de la comisión electrotécnica internacional, fue uno de los primeros estándares en tratar la seguridad (safety) del software en la industria nuclear. El estándar cubre todo el ciclo de vida software, tanto durante el desarrollo como durante la parte operacional del software. El ciclo de vida se compone de siete fases con unas tareas y actividades asignadas a cada fase. Las fases son Análisis y especificación de requisitos del software, desarrollo, verificación, integración de hardware y software, validación del sistema, operación y mantenimiento y modificación. Al final de cada fase se realiza una revisión crítica. [7] El estándar hace hincapié en la fase de análisis de requisitos. Los requisitos software para funciones asignadas a sistemas de seguridad (safety) son recogidas de la especificación de requisitos del sistema. Para ello se recomienda un lenguaje de especificación formal para asegurar la claridad de los requisitos. Los requisitos deben ser marcados como obligatorios u opcionales, para ayudar a la priorizacion mas tarde, y deben incluir también lo que el software no debe hacer. [17] Como en la mayoría de estándares se hace una categorización de los requisitos, dividiéndolos en requisitos funcionales, requisitos de rendimiento del sistema, requisitos de fiabilidad, requisitos de gestión de errores, requisitos de monitorización continua, requisitos de interfaz ordenador-maquina, requisitos de interfaz de sistema, restricciones operacionales del entorno, y requisitos de datos. Toda esta información debe ser plasmada en la especificación de requisitos software. Para cada una de estas categorías, el estándar establece que se deben recoger los detalles de ese tipo de requisitos. Por ejemplo, para los requisitos funcionales que describen las funciones de seguridad (safety) del sistema asignadas al software se debe generar una lista de todas las funciones que realiza el software, y por cada función se debe ser descrita en términos de su objetivo, las entradas y salidas requeridas, interacción con otras funciones, y la relación con la fiabilidad del sistema. Lo que indica que el estándar recoge en mucho detalle cada una de los tipos de requisitos. 7. Estándares A continuación se describen algunos de los estándares existentes, centrándose en la parte de requisitos no funcionales y safety. 7.1. IEC61508-3 International Electrotechnical Comisión Dentro de esta estándar, es la parte 3 (dentro de las 7 que componen el estándar) la que incluye lo referente a requisitos del software. La primera versión fue publicada a principios de 1998 y recoge representantes de industria y 10 países [7]. El estándar se destina a cualquier software relacionado con la seguridad (safety) que incluya software que es parte de un sistema de seguridad (safety), software que es usado para desarrollar un sistema software relacionado con la seguridad (Safety) o las herramientas y sistemas que interaccionan con lo anterior. [11] Al igual que la mayoría de estándares define un ciclo de vida de seguridad (safety) en software que incluye ocho fases, siendo la primera la especificación de requisitos de software. El objetivo de esta primera fase es la especificación de los requisitos funcionales de seguridad (safety) del software, así como los requisitos de integridad del software. Normalmente, estos requisitos se derivan de la especificación de requisitos del software y reflejan el resultado de las actividades de planes de seguridad (safety) del sistema. Se indica en el estándar que estos requisitos deben ser escritos con un nivel razonable de detalle. También recomienda el uso de diagramas de bloque para aislar los errores de especificación, los errores aleatorios y sistemáticos, y las causas de fallo más comunes. [11] Oscar Diez 11/16 2006 Safety y Requisitos no funcionales Trabajo de Investigación Facultad de Informática Una vez se han definido los requisitos con un detalle suficiente y se han realizado los diagramas, se procede a la siguiente fase, que es el plan de validación de la seguridad (safety) del software, para más tarde pasar al diseño y al desarrollo. Aunque se habla de requisitos de safety, y se tratan de forma distinta a los requisitos funcionales, no se hace un tratamiento parecido para el resto de los RNF. Aunque si se indican algunas herramientas para el análisis mas en detalle de los requisitos. Otra de las ventajas de este estándar es que es muy abierto y permite ser usado por diferentes sectores. 7.2. SEMSPLC, IEE Guía Técnica 8 Fue publicado en 1996 por el Instituto de Ingenieros Eléctricos del Reino Unido. Su objetivo es servir como guía en el desarrollo de software de aplicación para controladores lógicos programables (PLC) usados en sistemas relacionados con la seguridad (Safety). Estas guías están organizadas sobre las fases del ciclo de vida del desarrollo, y se requiere realizar unas actividades para cada fase basadas en el SIL. Se describen tres procesos, que son la gestión del safety, la gestión de la verificación del software, y la gestión de la calidad. Estos se describen en términos de objetivos, entradas, salidas, procedimientos, verificación y autorización. [10] El ciclo de vida de desarrollo complementa estos procesos de gestión. Este consta de cinco fases, requisitos, diseño, diseño detallado, codificación y pruebas. Para cada fase se describen sus objetivos, las entradas y salidas, los procedimientos, actividades extras de seguridad (safety) para SIL 3 y 4, descripciones de las salidas de la fase, verificación y requisitos de autorización. [7] En la fase de requisitos se busca que estos sean precisos, consistentes, correctos, no ambiguos y verificables. Los requisitos deben tener en cuenta las restricciones conocidas del sistema, y deben ser comprensibles por clientes y desarrolladores. No hay que olvidar que en este estándar estamos hablando de PLC, y que estos normalmente operan en tiempo real, por lo que el tiempo aquí es crítico, y se examinan todos los posibles escenarios relacionados con el tiempo. [7] Como en otros estándares de los vistos anteriormente, los requisitos software de PLC son derivados de la especificación y el análisis de riesgos del sistema. Se establecen unas categorías para los requisitos. Requisitos de Seguridad (Safety) Req. Funcionales Req. De integridad Requisitos non-safety funcionales Requisitos No funcionales Req. Seguridad Req. Mantenimiento Req. Fiabilidad Req. Rendimiento Req. Disponibilidad La primera categoría de requisitos se documenta en la especificación de requisitos de seguridad (safety), que se produce durante el proceso de gestión del safety. Las categorías dos y tres son documentadas en la especificación de requisitos software, que es una salida de la fase de requisitos. Durante esta fase se debe crear un diccionario de datos preliminar, así como los interfaces del software con el software, hardware y los operadores. A cada uno de los requisitos se le debe asignar un SIL. [10] Durante esta fase se debe realizar un análisis para determinar como los peligros del sistema son afectados o pueden serlo por el software. Este análisis de riesgos puede ser realizado usando los métodos FTA o FMECA. Así mismo se debe realizar una evaluación del software para verificar que no se alcanzan estados no deseados. Con el fin de asegurar que los requisitos de seguridad (safety) son precisos, consistentes, completos, correctos, no ambiguos y verificables, para los requisitos asignados con SIL 3 o 4 se recomienda utilizar un lengua formal, prototipos, maquinas de estado finitas, y modelado de redes Petri. Oscar Diez 12/16 2006 Safety y Requisitos no funcionales Trabajo de Investigación Facultad de Informática Tras todo esto obtenemos como salidas de esta fase la especificación de requisitos software, el diccionario de datos, la especificación de pruebas para requisitos software, la especificación de las pruebas de aceptación, la verificación de los requisitos del software y el informe de seguridad (safety). El estándar da mas detalles para cada una de estas salidas. Antes de pasar a la siguiente fase, la de diseño, se deben resolver todos los problemas pendientes en esta fase. Este estándar incluye mas información practica que el resto de los estándares, indicando posibles técnicas o herramientas a usar, aunque no se centran en un lenguaje de programación o técnica especifica. Se ven puntos comunes a otros estándares como el uso del ciclo de vida de desarrollo y la categorización de los requisitos, aunque esta vez no incluye los requisitos de safety como requisitos no funcionales, y les dedica una de las categorías de igual forma que se hace en el estándar MISRA. 8. Conclusión Como se ha presentado, la mayoría de los estándares presentan muchas cosas en común en lo que se refiere a la recogida de requisitos, y en concreto a los requisitos de seguridad (safety), como son el considerar al software como parte del sistema y como un subsistema aislado. También la mayoría, aunque no todos, optan por el uso de un ciclo de vida de safety con una fase claramente definida para la recogida de requisitos. En lo que ya no hay tanto consenso según se puede ver en la tabla del anexo B, es en la división de los requisitos funcionales y no funcionales y en su tratamiento. Aunque la mayoría indica que los requisitos safety no son iguales que los requisitos funcionales, no establecen un marco común como el de Cheng presentado al principio del presente trabajo para el tratamiento de estos. Otro punto común a varios de los estándares es la recogida de los requisitos no funcionales a partir de la especificación de requisitos, y hay que tener en cuenta que no todas los requisitos no funcionales son recogidas en la especificación de requisitos. Tampoco se hace referencia, en la mayoría de estándares a técnicas o herramientas para la recogida de RNF y sobre todo técnicas para explicar como pasar estos requisitos no funcionales al diseño del sistema. Una posible excepción a lo anterior es el análisis de riesgos y su paso a diseño que se realizan en algunos de los estándares presentados. Una de las posibles mejoras en los estándares mostrados seria la inclusión o referencia a estas técnicas para la recogida de RNF y como transformar estos requisitos no funcionales en atributos y funciones del sistema. Oscar Diez 13/16 2006 Safety y Requisitos no funcionales Trabajo de Investigación Facultad de Informática 9. Anexo A. Estandares de Software Safety A continuación se enumeran en la tabla los principales estándares de safety en software en la actualidad, de los cuales se han utilizado algunos para el presente trabajo. Estandar IEEE 1059 IEEE 1228 BS EN 50128:2001 ANSI/UL 1998 IEC 60880 IEC 60950-1 BSI IEC 61508-1 Descripcion Guide for Software Verification and Validation Plans Software Safety Plans Railway applications. Communications, signaling and processing systems. Software for railway control and protection systems Software in Programmable Components, Second Edition Software for Computers in the Safety Systems of Nuclear Power Stations Safety of Information Technology Equipment - Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems IEC 61508-2 Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems - Part 2: Requirements for Electrical/Electronic/Programmable Electronic Safety-related Systems IEC 61508-3 Functional Safety of Eelectrical/Eelectronic/Programmable Eelectronic Safety-Related Systems - Part 3: Software Requirements IEC 61508-5 Functional Safety of Eelectrical/Eelectronic/Programmable Eelectronic Safety-Related Systems - Part 5: Examples of Methods for the Determination of Safety Integrity Levels RTCA DO- Software Considerations in Airborne Systems and Equipment Certification 178B/ED-12B IEE SEMSPLC 8 Guidelines: Safety-Related Application Software for Programmable Logic Controllers AECL CE-1001- Standard for Software Engineering of Safety Critical Software STD REV.2 ANS ANSI/IEEE Application Criteria for Programmable Digital Computer Systems in Safety Systems of 7.4.3.2 Nuclear Power Generating Stations ANSI/AAMI Medical device software - Software life cycle processes SW68 DEF 00-56 Part Safety Management Requirements for Defence Systems Part 1 1/2 DEF 00-56 Part Safety Management Requirements for Defence Systems Containing Programmable 2/2 Electronics Part 2: General Application Guidance SAE AS9006 Aerospace Software Supplement for AS9100A DoD MIL-STD- System Safety Program Requirements 882D EIA SEB6-A System Safety Engineering in Software Development Oscar Diez 14/16 2006 Safety y Requisitos no funcionales Trabajo de Investigación Facultad de Informática 10. Anexo B. Tabla comparativa de Estandares Estandar Distingue RF / RNF Distingue RNF/Req Safety EN 50128 MISRA (Automóviles) RTCA/DO-178B (aviación) ECSS (ESA) DEF STAN 00 55 IEC61508-3 SI SI Oscar Diez NO SI Indica Tecnicas/herramientas para RNF/Req Safety NO NO SI SI Interrelaciona la Gestion de Riesgos con Recogida de Requisitos NO NO NO SI NO NO NO NO NO NO SI SI SI NO NO SI SI SI SI NO SI NO 15/16 Fase propia de Recogida de Requisitos 2006 Safety - Requisitos no funcionales Facultad de Informática 11. Bibliografía [1] Kotonya, G., Sommerville, I., "Requirements Engineering Processes and Techniques", Jonh Wiley & Sons, 1998. [2] Chung, L., Nixon, B., Yu, E. and Mylopoulos,J. “Non-Functional Requirements in Software Engineering” Kluwer Academic Publishers, 2000. [3] Luiz Marcio Cysneiros, Julio César Sampaio do Prado Leite . “Using UML to Reflect Non-Functional Requirements”, 2001 [4] Dorfman, M. and Thayer, R., "Standards, Guidelines and Examples on System and Software Requirements Engineering", IEEE Computer Society Press, 1990. [5] Modugno, F., Leveson, N.G., Reese, J.D., Partridge, K.,and Sandys, S.D., “Integrated Safety Analysis of Requirements Specifications,” Requirements Engineering 2(2), 1997. [6] Luiz Marcio Cysneiros, Julio César Sampaio do Prado Leite, “Using UML to Reflect Non-Functional Requirements”, 2001 [7] Debra S. Herrmann, “Software Safety and Reliability”, IEEE, 1999 [8] IEC, “Functional Safety and IEC 61508”, Sept 2005 [9] NASA-STD-8719.13A: Software safety, NASA Technical standard, 1997. [10] SEMSPLC Guidelines, Safety-Related Application Software for Programmable Logic Controllers, IEE Technical Guidelines 8, 1996 [11] IEC 60880:1986-09, “Software for computers in safety systems of Nuclear Power Stations” [12] Sam Supakkul, Lawrence Chung, “Integrating FRs and NFRs: A Use Case and Goal Driven Approach”, 2005 [13] Kelly J. Hayhurst, "The Guidance and Control Software Project: A Software Engineering Case Study", NASA Langley Research Center, 1997 [14] DOE - Department of Energy EEUU, DOE Oversight Manual, “Safety Software Quality Assurance Draft”, 2006 [15] Nancy G. Leveson, "Safeware: System Safety and Computers", Addison Wesley, 1995 [16] B. Littlewood, Bryans, P. Ryan and L. Strigini, "E-voting: Dependability Requirements and Design for Dependability", 2006 [17] US Regulatory Commission, “Review Guidelines for Software Languages for Use in Nuclear Power Plant Safety Systems”, Final Report, 1997 Oscar Diez 16 08/09/2006
