COPYRIGHT NOTICE
© This document has been produced by SAI Global with the
authorization of AENOR. Total or partial reproduction of PDF
documents is prohibited.
SAI Global makes no guarantees or warranties as to the correctness
of the document or as to the results arising from the purchase and
use of the document and is not responsible for problems in the
delivery of the document. Any difficulties or queries should be
addressed to SAI Global below.
In Europe Contact:SAI Global, Index House, Ascot, Berks, SL5 7EU, UK
: +44 (0)1344 636400
Web: www.ili.co.uk
Fax: +44 (0)1344 291194
Email: standards@saiglobal.com
In USA and Canada Contact:SAI Global, 610 Winters Avenue, Paramus, NJ 07652, USA
Toll Free 1-888-454-2688 or 201-986-1131 Fax: 201-986-7886
Email: uspubsales@saiglobal.com
Web: www.ili-info.com
In Asia/Pacific Contact:SAI Global Ltd, 286 Sussex Street, Sydney NSW 2000, Australia
: +61 2 8206 6060. Fax: +61 2 8206 6019
Web: www.saiglobal.com
Email: sales@saiglobal.com
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
norma
española
UNE-EN 50128
Octubre 2002
TÍTULO
Aplicaciones ferroviarias
Sistemas de comunicación, señalización y procesamiento
Software para sistemas de control y protección de ferrocarril
Railway applications. Communications, signalling and processing systems. Software for railway control
and protection systems.
Applications ferroviaires. Systèmes de signalisation, de télécommunication et de traitement. Logiciels pour
systèmes de commande et de protection ferroviaire.
CORRESPONDENCIA
Esta norma es la versión oficial, en español, de la Norma Europea EN 50128 de marzo
de 2001.
OBSERVACIONES
ANTECEDENTES
Esta norma ha sido elaborada por el comité técnico AEN/CTN 203 Equipamiento
Eléctrico y Sistemas Automáticos para la Industria cuya Secretaría desempeña
SERCOBE.
Editada e impresa por AENOR
Depósito legal: M 42039:2002
LAS OBSERVACIONES A ESTE DOCUMENTO HAN DE DIRIGIRSE A:
 AENOR 2002
Reproducción prohibida
C Génova, 6
28004 MADRID-España
107 Páginas
Teléfono
Fax
91 432 60 00
91 310 40 32
Grupo 59
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
S
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
NORMA EUROPEA
EUROPEAN STANDARD
NORME EUROPÉENNE
EUROPÄISCHE NORM
EN 50128
Marzo 2001
ICS 29.280; 45.060.10
Versión en español
Aplicaciones ferroviarias
Sistemas de comunicación, señalización y procesamiento
Software para sistemas de control y protección de ferrocarril
Railway applications. Communications,
signalling and processing systems.
Software for railway control and
protection systems.
Applications ferroviaires. Systèmes de
signalisation, de télécommunication et de
traitement. Logiciels pour systèmes de
commande et de protection ferroviaire.
Bahnanwendunge.
Telekommunikationstechnik, Signaltechnik und Datenverarbeitungssysteme.
Software für Eisenbahnsteuerungs- und
Überwachungssysteme.
Esta norma europea ha sido aprobada por CENELEC el 2000-11-01. Los miembros de CENELEC están sometidos al
Reglamento Interior de CEN/CENELEC que define las condiciones dentro de las cuales debe adoptarse, sin
modificación, la norma europea como norma nacional.
Las correspondientes listas actualizadas y las referencias bibliográficas relativas a estas normas nacionales, pueden
obtenerse en la Secretaría Central de CENELEC, o a través de sus miembros.
Esta norma europea existe en tres versiones oficiales (alemán, francés e inglés). Una versión en otra lengua realizada
bajo la responsabilidad de un miembro de CENELEC en su idioma nacional, y notificada a la Secretaría Central, tiene
el mismo rango que aquéllas.
Los miembros de CENELEC son los comités electrotécnicos nacionales de normalización de los países siguientes:
Alemania, Austria, Bélgica, Dinamarca, España, Finlandia, Francia, Grecia, Irlanda, Islandia, Italia, Luxemburgo,
Noruega, Países Bajos, Portugal, Reino Unido, República Checa, Suecia y Suiza.
CENELEC
COMITÉ EUROPEO DE NORMALIZACIÓN ELECTROTÉCNICA
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
SECRETARÍA CENTRAL: Rue de Stassart, 35 B-1050 Bruxelles
 2001 Derechos de reproducción reservados a los Miembros de CENELEC.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
-4-
ANTECEDENTES
Esta norma europea fue preparada por el SC 9XA, Sistemas de comunicación, señalización y
procesamiento, del TC 9X, Aplicaciones eléctricas y electrónicas para ferrocarriles, de CENELEC.
El texto del borrador fue sometido a voto formal y fue aprobado por CENELEC como Norma Europea
EN 50128 el 2000-11-01.
Se fijaron las siguientes fechas:
− Fecha límite en la que la norma europea debe ser adoptada
a nivel nacional por publicación de una norma
nacional idéntica o por ratificación
(dop)
2001-11-01
− Fecha límite de retirada de las normas
nacionales divergentes
(dow)
2003-11-01
Esta norma europea debería leerse conjuntamente con las Normas Europeas EN 50126: “Aplicaciones
ferroviarias. Especificación y demostración de la fiabilidad, de la mantenibilidad, de la disponibilidad y
de la seguridad (RAMS)” y EN 50129: “Aplicaciones ferroviarias. Sistemas electrónicos de seguridad
para señalización”.
Los anexos denominados “normativos” forman parte del cuerpo de la norma.
Los anexos denominados “informativos” se dan sólo para información.
En esta norma, el anexos A es normativo y es anexo B es informativo.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
-5-
EN 50128:2001
ÍNDICE
Página
INTRODUCCIÓN ....................................................................................................................................
7
1
OBJETO Y CAMPO DE APLICACIÓN ............................................................................
9
2
NORMAS PARA CONSULTA ............................................................................................
9
3
DEFINICIONES ....................................................................................................................
10
4
OBJETIVOS Y CONFORMIDAD ......................................................................................
12
5
5.1
5.2
NIVELES DE INTEGRIDAD DE SEGURIDAD DEL SOFTWARE ..............................
Objetivo ..................................................................................................................................
Requisitos ...............................................................................................................................
13
13
13
6
6.1
6.2
PERSONAL Y RESPONSABILIDADES............................................................................
Objetivo ..................................................................................................................................
Requisitos ...............................................................................................................................
14
14
14
7
7.1
7.2
ETAPAS DEL CICLO DE VIDA Y DOCUMENTACIÓN ...............................................
Objetivo ..................................................................................................................................
Requisitos ...............................................................................................................................
16
16
16
8
8.1
8.2
8.3
8.4
ESPECIFICACIÓN DE REQUISITOS DEL SOFTWARE..............................................
Objetivos ........................................................................................................................................
Documentos de entrada ................................................................................................................
Documentos de salida....................................................................................................................
Requisitos .......................................................................................................................................
19
19
19
19
19
9
9.1
9.2
9.3
9.4
ARQUITECTURA SOFTWARE.........................................................................................
Objetivos ........................................................................................................................................
Documentos de entrada ................................................................................................................
Documentos de salida....................................................................................................................
Requisitos .......................................................................................................................................
21
21
21
21
21
10
10.1
10.2
10.3
10.4
DISEÑO E IMPLEMENTACIÓN DEL SOFTWARE ......................................................
Objetivos ........................................................................................................................................
Documentos de entrada ................................................................................................................
Documentos de salida....................................................................................................................
Requisitos .......................................................................................................................................
23
23
23
23
23
11
11.1
11.2
11.3
11.4
VERIFICACIÓN Y ENSAYO DEL SOFTWARE.............................................................
Objetivo ..........................................................................................................................................
Documentos de entrada ................................................................................................................
Documentos de salida....................................................................................................................
Requisitos .......................................................................................................................................
26
26
26
26
27
12
12.1
12.2
12.3
12.4
INTEGRACIÓN SOFTWARE/HARDWARE ...................................................................
Objetivos ........................................................................................................................................
Documentos de entrada ................................................................................................................
Documentos de salida....................................................................................................................
Requisitos .......................................................................................................................................
29
29
29
30
30
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
-6-
13
13.1
13.2
13.3
13.4
VALIDACIÓN DEL SOFTWARE ...................................................................................
Objetivo .......................................................................................................................................
Documentos de entrada .............................................................................................................
Documentos de salida.................................................................................................................
Requisitos ....................................................................................................................................
31
31
31
31
31
14
14.1
14.2
14.3
14.4
EVALUACIÓN DEL SOFTWARE ..................................................................................
Objetivo .......................................................................................................................................
Documentos de entrada .............................................................................................................
Documentos de salida.................................................................................................................
Requisitos ....................................................................................................................................
33
33
33
33
33
15
15.1
15.2
15.3
15.4
ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE.........................................
Objetivos .....................................................................................................................................
Documentos de entrada .............................................................................................................
Documentos de salida.................................................................................................................
Requisitos ....................................................................................................................................
34
34
34
34
35
16
16.1
16.2
16.3
16.4
MANTENIMIENTO DEL SOFTWARE..........................................................................
Objetivo .......................................................................................................................................
Documentos de entrada .............................................................................................................
Documentos de salida.................................................................................................................
Requisitos ....................................................................................................................................
37
37
37
37
37
17
17.1
17.2
17.3
17.4
17.4.1
17.4.2
17.4.3
SISTEMAS CONFIGURADOS MEDIANTE DATOS DE APLICACIÓN ..................
Objetivos .....................................................................................................................................
Documentos de entrada .............................................................................................................
Documentos de salida.................................................................................................................
Requisitos ....................................................................................................................................
Ciclo de Vida de Preparación de Datos....................................................................................
Procedimientos y Herramientas para la Preparación de Datos ............................................
Desarrollo del Software .............................................................................................................
38
38
39
39
39
39
39
40
ANEXO A (Normativo)
CRITERIOS PARA LA SELECCIÓN
DE TÉCNICAS Y MEDIDAS .................................................................
47
BIBLIOGRAFÍA DE TÉCNICAS ..........................................................
60
Figura 1 Niveles de Integridad para Sistemas Relacionados con la Seguridad................................
41
Figura 2 Ciclo de Seguridad del Software............................................................................................
42
Figura 3 Ciclo de Vida de Desarrollo 1.................................................................................................
43
Figura 4 Ciclo de Vida de Desarrollo 2.................................................................................................
44
Figura 5 Independencia en función del Nivel de Integridad del Software........................................
45
Figura 6 Relación entre Desarrollo del Sistema Genérico y Desarrollo de la Aplicación ...............
46
ANEXO B (Informativo)
Figuras
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
-7-
EN 50128:2001
INTRODUCCIÓN
Esta norma forma parte de un grupo de normas relacionadas. Las otras son las Normas EN 50126: “Aplicaciones ferroviarias. Especificación y demostración de la fiabilidad, de la mantenibilidad, de la disponibilidad y de la seguridad
(RAMS)” y EN 50129: “Aplicaciones ferroviarias. Sistemas electrónicos de seguridad para señalización”. La Norma
EN 50126 considera los sistemas en su concepción más amplia, mientras que la Norma EN 50129 se refiere al proceso
de aprobación para sistemas particulares que pueden existir dentro del sistema global de protección y control del ferrocarril. Esta norma se concentra en los métodos que se necesitan utilizar para suministrar software que satisfaga los requisitos de integridad de la seguridad definidos por las normas antes mencionadas.
Esta norma se apoya en gran medida en el trabajo previo realizado por el Grupo de Trabajo 9 de CEI/TC 65. El trabajo
del WG 9 dio lugar a una norma genérica para software de sistemas de seguridad que ahora es parte de la Norma
CEI 61508. Un aspecto particular del trabajo del WG 9 es la inclusión del Nivel de Integridad del Software 0, que cubre
el software que no es de seguridad, así como los Niveles de Integridad del Software 1 a 4, que cubren el software relacionado con la seguridad y el software crítico para la seguridad. Esta norma también cubre los cinco Niveles de Integridad del Software.
Se ha tenido también en cuenta el trabajo de la Institución de Ingenieros de Señalización Ferroviaria (IRSE), en particular su Informe Técnico Número 1, que trata el mismo tema.
El concepto clave de esta norma es el de niveles de integridad de seguridad del software. Cuanto más peligrosas sean las
consecuencias de un fallo del software, más alto será el nivel de integridad de seguridad exigido al mismo.
Esta norma ha identificado técnicas y medidas para 5 niveles de integridad de seguridad del software, siendo 0 el nivel
mínimo y 4 el máximo. Cuatro de estos niveles, 1 al 4, se refieren a software relacionado con la seguridad, mientras que
el nivel 0 se refiere a software no relativo a la misma. Se ha incluido este nivel como normativo a fin de permitir una
transición gradual entre desarrollos de software para sistemas no relativos a la seguridad y aquellos que sí lo son. Las
técnicas y medidas requeridas para cada nivel de integridad de seguridad del software y para el nivel no relacionado con
la seguridad se muestran en las tablas. En esta versión, las técnicas requeridas para el nivel 1 son las mismas que para el
nivel 2, y las requeridas para el nivel 3 son las mismas que para el nivel 4. Esta norma no da indicaciones sobre qué
nivel de integridad del software es apropiado para un determinado riesgo. Esta decisión dependerá de muchos factores,
incluyendo la naturaleza de la aplicación, el grado en que otros sistemas llevan a cabo funciones de seguridad y factores
sociales y económicos.
Es función de las Normas EN 50126 y EN 50129 el especificar las funciones de seguridad asignadas al software.
Esta norma especifica las medidas necesarias para satisfacer dichos requisitos. El proceso se ilustra en la figura 1.
Las Normas EN 50126 y EN 50129 requieren que se adopte una aproximación sistemática para:
i) identificar amenazas, riesgos y criterios de riesgo;
ii) identificar la reducción de riesgo necesaria para cumplir con los criterios de riesgo;
iii) definir una Especificación de Requisitos de Seguridad del Sistema con las protecciones necesarias para conseguir la
reducción de riesgo requerida;
iv) seleccionar una arquitectura del sistema adecuada;
v) planificar, supervisar y controlar las actividades técnicas y de gestión necesarias para convertir la Especificación de
Requisitos de Seguridad del Sistema en un Sistema Relacionado con la seguridad con unas características de segur idad (o integridad de seguridad) validadas.
A medida que se descompone la especificación en un diseño que incluye sistemas y componentes relativos a la seguridad, se produce una nueva asignación de niveles de integridad de Seguridad. Finalmente, se llega a los niveles de integridad de seguridad requeridos para el software.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
-8-
El estado actual del arte es tal que ni la aplicación de métodos para garantizar la calidad (denominados medidas para
evitar defectos) ni la aplicación de soluciones de software tolerante a fallos, pueden garantizar la seguridad absoluta del
sistema. No hay manera conocida para probar la ausencia de defectos en un software relacionado con la seguridad razonablemente complejo, especialmente la ausencia de defectos de especificación y diseño.
Los principios aplicados en el desarrollo de software de alta integridad incluyen, pero no se limitan a:
− métodos de diseño descendentes (arriba-abajo);
− modularidad;
− verificación de cada fase del ciclo de vida de desarrollo;
− módulos y librerías de módulos verificados;
− documentación clara;
− documentos auditables; y
− ensayos de validación.
Estos y otros principios similares deben ser correctamente aplicados. Esta norma especifica el nivel de aseguramiento
requerido para demostrar la aplicación de dichos principios para cada nivel de integridad de seguridad del software.
Una vez obtenida o generada la Especificación de Requisitos de Seguridad del Sistema, que identifica todas las funciones de seguridad asignadas al software y determina el nivel de integridad de seguridad del sistema, los pasos funcionales para la aplicación de esta norma se muestran en la figura 2 y son los siguientes:
i) definir la Especificación de Requisitos del Software y en paralelo considerar la arquitectura del software. La arquitectura del software es donde se desarrolla la estrategia básica de seguridad y el nivel de integridad de seguridad del
software (capítulos 5, 8 y 9);
ii) diseño, desarrollo y ensayo del software de acuerdo al Plan de Aseguramiento de la Calidad del Software, nivel de
integridad de seguridad del software y ciclo de vida del software (capítulo 10);
iii) integrar el software en el hardware específico (capítulo 12);
iv) validar el software (capítulo 13);
v) si se requiere un mantenimiento del software durante la vida operativa, reactivar esta norma según sea apropiado
(capítulo 16).
Un número de actividades tienen lugar durante el desarrollo del software. Incluyen la verificación (capítulo 11), evalu ación (capítulo 14) y aseguramiento de la calidad (capítulo 15).
Se establecen requisitos para sistemas configurados mediante datos de aplicación (capítulo 17).
Se establecen también requisitos para la competencia del personal involucrado en el desarrollo del software (capítulo 6).
Esta norma no obliga a utilizar un determinado ciclo de vida para el desarrollo del software. Sin embargo, se da un ciclo
de vida y un conjunto de documentación recomendados (capítulo 7 y figuras 3 y 4).
Se han formulado tablas clasificando varias técnicas/medidas para los 5 niveles de integridad de seguridad del software.
Las tablas están en el anexo A. Hay una bibliografía que hace referencia a las tablas y da una breve descripción de cada
técnica/medida con referencias a fuentes de información adicionales. La bibliografía está en el anexo B.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
-9-
EN 50128:2001
1 OBJETO Y CAMPO DE APLICACIÓN
1.1 Esta norma especifica procedimientos y requisitos técnicos para el desarrollo de sistemas electrónicos programables para uso en aplicaciones de control y protección del ferrocarril. Se puede aplicar en cualquier área del ferrocarril,
con o sin implicaciones en la seguridad. Dichas áreas pueden ir desde las muy críticas, como la señalización de seguridad, a las no críticas, tales como sistemas de información y gestión. Estos sistemas pueden implementarse utilizando
microprocesadores dedicados, controladores lógicos programables, sistemas multiprocesadores distribuidos, sistemas de
procesador central de gran escala u otras arquitecturas.
1.2 Esta norma se aplica exclusivamente al software y a la interacción entre el software y el sistema del que forma
parte.
1.3 Los niveles de integridad de seguridad del software superiores a cero se usan en sistemas donde las consecuencias
de un fallo pueden dar lugar a pérdida de vidas. Sin embargo, consideraciones económicas o ambientales pueden justif icar también el uso de niveles de integridad de seguridad del software más altos.
1.4 Esta norma se aplica a todo el software utilizado en el desarrollo e implementación de sistemas de control y protección del ferrocarril, incluyendo:
programas de aplicación
sistemas operativos
herramientas de soporte
firmware
Los programas de aplicación comprenden la programación de alto nivel, bajo nivel y programas de propósito especial
(por ejemplo, Programación de Controladores Lógicos Programables).
1.5 El uso de herramientas y software normalizado y disponibles comercialmente está contemplado también en esta
norma.
1.6 Esta norma se aplica también a los requisitos de los sistemas configurados mediante datos de aplicación.
1.7 Esta norma no pretende considerar cuestiones comerciales. Dichas cuestiones deberían formar parte esencial de los
acuerdos contractuales. Será necesaria una cuidadosa consideración de todos los capítulos de esta norma en cualquier
situación comercial.
1.8 No se pretende que esta norma sea retroactiva. Por lo tanto, se aplica principalmente a nuevos desarrollos y solamente se aplica en su totalidad a sistemas existentes si se someten a modificaciones importantes. Para cambios menores,
solamente se aplica el capítulo 16.
2 NORMAS PARA CONSULTA
Esta norma europea incorpora disposiciones de otras normas por su referencia, con o sin fecha. Estas referencias normativas se citan en los lugares apropiados del texto de la norma y se relacionan a continuación. Las revisiones o modif icaciones posteriores de cualquiera de las normas referenciadas con fecha, sólo se aplican a esta norma europea cuando
se incorporan mediante revisión o modificación. Para las referencias sin fecha se aplica la última edición de esa norma
(incluyendo sus modificaciones).
EN 50126 − Aplicaciones Ferroviarias. Especificación y demostración de la fiabilidad, de la mantenibilidad, de la
disponibilidad y de la seguridad (RAMS).
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 10 -
EN 50129* − Aplicaciones Ferroviarias. Sistemas electrónicos de seguridad para señalización.
EN 50159-1 − Aplicaciones ferroviarias. Sistemas de comunicación, señalización y procesamiento. Parte 1: Comunicación segura en sistemas de transmisión cerrados.
EN 50159-2 − Aplicaciones ferroviarias. Sistemas de comunicación, señalización y procesamiento. Parte 2: Comunicación segura en sistemas de transmisión abiertos.
EN ISO 9001 − Sistemas de gestión de la calidad. Requisitos.
EN ISO 9000-3 − Gestión de la calidad y aseguramiento de la calidad. Parte 3: Directrices para la aplicación de la
Norma ISO 9001:1994 al desarrollo, suministro, instalación y mantenimiento del soporte lógico.
3 DEFINICIONES
Para los propósitos de esta norma, se aplican las definiciones siguientes. Para los términos no definidos aquí, deberían
consultarse las referencias siguientes por orden de prioridad:
EN ISO 8402 − Gestión y aseguramiento de la calidad: Vocabulario.
CEI 60050 (191) − Vocabulario Electrotécnico Internacional (Capítulo 191: Confiabilidad y calidad de servicio).
IEEE 610.12 − Glosario normalizado del IEEE sobre terminología de ingeniería software.
ISO/CEI 2382 − Vocabulario de Tecnología de la Información.
ISO/CEI 9126 − Tecnología de la Información: Evaluación de Productos Software: Características de Calidad y Guías
para su Uso.
3.1 evaluación: Proceso de análisis para determinar si la Autoridad de Diseño y el Validador han conseguido un producto que satisface los requisitos especificados y formar un juicio sobre si el producto es apto para su aplicación específica.
3.2 evaluador: Persona o agente designado para llevar a cabo la evaluación.
3.3 disponibilidad: Capacidad de un producto de estar en un estado en el que puede realizar la función requerida, bajo
condiciones establecidas, en un instante o intervalo de tiempo determinado, suponiendo que dispone de los recursos
externos necesarios.
3.4 software comercial de catálogo (COTS): Software definido por las necesidades del mercado, disponible comercialmente y cuya validez para su aplicación ha sido demostrada por un amplio espectro de usuarios comerciales.
3.5 autoridad de diseño: Ente responsable de formular una solución de diseño que satisfaga los requisitos especificados y supervisar el subsecuente desarrollo y puesta en funcionamiento de un sistema en su entorno específico.
3.6 diseñador: Una o más personas asignadas por la Autoridad de Diseño para analizar y transformar los requisitos
especificados en soluciones de diseño aceptables que tengan la integridad de seguridad requerida.
3.7 elemento: Parte de un producto que ha sido considerada como unidad básica o bloque de partida. Un elemento
puede ser simple o complejo.
*
En fase de borrador.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 11 -
EN 50128:2001
3.8 error: Desviación del diseño proyectado que podría dar lugar a un comportamiento del sistema no previsto o a un
fallo.
3.9 fallo*: Desviación de las prestaciones especificadas de un sistema. Un fallo es la consecuencia de un defecto o de
un error en un sistema.
3.10 defecto*: Condición anormal que podría conducir a un error o a un fallo en un sistema. Un defecto puede ser
aleatorio o sistemático.
3.11 prevención de fallos: Uso de técnicas de diseño dirigidas a evitar la introducción de defectos durante el diseño y
construcción del sistema.
3.12 tolerancia a fallos: Capacidad integrada en un sistema para proporcionar una ejecución correcta continua del
servicio especificado, en presencia de un número limitado de defectos de hardware o software.
3.13 firmware: Conjunto ordenado de instrucciones y datos asociados almacenados en una forma que es funcionalmente independiente del almacenamiento principal, normalmente en una ROM.
3.14 software genérico: Software genérico es el software que puede utilizarse para una variedad de instalaciones, suministrándole únicamente los datos de aplicación específicos.
3.15 implementador: Una o más personas asignadas por la Autoridad de Diseño para transformar los diseños especificados en sus realizaciones físicas.
3.16 producto: Colección de elementos interconectados para formar un sistema, subsistema o equipo de forma que
satisfaga los requisitos especificados. En esta norma, puede considerarse como producto aquel que consta únicamente
de elementos de software o documentación.
3.17 controlador lógico programable (PLC): Sistema de control de estado sólido que tiene una memoria programable
por el usuario para almacenamiento de instrucciones que implementan funciones específicas.
3.18 fiabilidad: Capacidad de un elemento de realizar una función requerida bajo condiciones establecidas durante un
período de tiempo determinado.
3.19 trazabilidad de requisitos: El objetivo de la trazabilidad de requisitos es garantizar la demostración de que todos
los requisitos han sido satisfechos adecuadamente.
3.20 riesgo: Combinación de la frecuencia, o probabilidad, y las consecuencias de un evento peligroso especificado.
3.21 seguridad: Ausencia de niveles de riesgo inaceptables.
3.22 autoridad de seguridad: Ente responsable de certificar que el sistema relacionado con la seguridad es apto para el
servicio y satisface los requisitos legales relevantes y los requisitos de seguridad.
*
NOTA A LA TRADUCCIÓN A LA VERSIÓN ESPAÑOLA:
En esta norma se ha traducido normalmente "fault" por "defecto" y "failure" por "fallo". En ocasiones, por ejemplo árbol de fallos, "fault" se ha
traducido por "fallo" debido a la expresión habitual en español. En estos casos, la palabra "fallo" se pone en cursiva para distinguirla de "fallo"
proveniente de "failure".
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 12 -
3.23 software relacionado con la seguridad: Software que conlleva responsabilidad para la seguridad.
3.24 software: Creación intelectual que comprende los programas, procedimientos, reglas y documentación asociada
relativos a la operación de un sistema.
NOTA - El software es independiente del medio utilizado para transportarlo.
3.25 ciclo de vida del software: Actividades que tienen lugar durante un periodo de tiempo que comienza cuando se
concibe el software y termina cuando el software deja de utilizarse. El ciclo de vida del software incluye típicamente
una fase de requisitos, fase de desarrollo, fase de ensayo, fase de integración, fase de instalación y fase de mantenimiento.
3.26 mantenibilidad del software: Capacidad de un sistema para modificarse corrigiendo sus defectos, mejorar prestaciones u otros atributos, o adaptarlo a un entorno diferente.
3.27 mantenimiento del software: Acción o conjunto de acciones llevadas a cabo sobre el software después de su
aceptación por el usuario final. El objetivo es mejorar, incrementar y/o corregir su funcionalidad.
3.28 nivel de integridad de seguridad del software: Número de clasificación que determina las técnicas y medidas
que tienen que aplicarse para reducir los defectos residuales del software a un nivel apropiado.
3.29 nivel de integridad de seguridad del sistema: Número que indica el grado de confianza requerido de que un
sistema satisfará sus características de seguridad especificadas.
3.30 trazabilidad: Grado en que puede establecerse una relación entre dos o más productos de un proceso de desarrollo, especialmente aquellos que tienen entre sí una relación predecesor/sucesor o maestro/subordinado.
3.31 validación: Actividad de demostración, mediante análisis y ensayo, de que un producto satisface en todos sus
aspectos los requisitos especificados.
3.32 validador: Persona o agente asignado para llevar a cabo la validación.
3.33 verificación: Actividad de determinación, mediante análisis y ensayo, de que la salida de cada fase del ciclo de
vida cumple los requisitos de la fase previa.
3.34 verificador: Persona o agente asignado para llevar a cabo la verificación.
4 OBJETIVOS Y CONFORMIDAD
4.1 En cada uno de los capítulos siguientes se detallan los objetivos y requisitos del capítulo.
4.2 Para cumplir con esta norma deberá demostrarse que se han satisfecho cada uno de los requisitos según el nivel de
integridad de seguridad del software definido y, por tanto, que se ha alcanzado el objetivo del capítulo.
4.3 Cuando se califica un requisito con las palabras "Según el grado requerido por el nivel de integridad de seguridad
del software", ello indica que se pueden usar un rango de técnicas y medidas para satisfacer dicho requisito.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 13 -
EN 50128:2001
4.4 Cuando se aplica el apartado 4.3, deberían usarse las tablas detalladas en esta norma para ayudar en la selección de
técnicas y medidas apropiadas al nivel de integridad de seguridad del software.
4.5 Si una técnica o medida está clasificada como altamente recomendada (AR) en las tablas, las razones para no utilizar dicha técnica deberían detallarse y registrarse en el Plan de Aseguramiento de la Calidad del Software o en otro
documento referenciado por dicho plan. Esto no es necesario si se usa una combinación aprobada de técnicas de la tabla
correspondiente.
4.6 Si se propone utilizar una técnica o medida que no está contenida en las tablas, se deberá justificar su efectividad y
aptitud para conseguir el requisito particular y el objetivo global del capítulo y se deberá registrar en el Plan de Aseguramiento de la Calidad del Software o en otro documento referenciado por dicho plan.
4.7 La conformidad con los requisitos de un capítulo particular y sus técnicas y medidas respectivas detalladas en las
tablas se deberá evaluar mediante la inspección de los documentos requeridos por esta norma, otra evidencia objetiva,
auditoría y testimonio de los ensayos.
4.8 Esta norma requiere el uso de un conjunto de técnicas y su correcta aplicación. Las técnicas requeridas se indican
en las tablas y se detallan en la bibliografía.
5 NIVELES DE INTEGRIDAD DE SEGURIDAD DEL SOFTWARE
5.1 Objetivo
Describir la asignación de niveles de integridad de seguridad al software.
5.2 Requisitos
5.2.1 Se deberán generar, de acuerdo con las Normas EN 50126 y EN 50129, los documentos:
− Especificación de Requisitos del Sistema;
− Especificación de Requisitos de Seguridad del Sistema;
− Descripción de la Arquitectura del Sistema;
− Plan de Seguridad del Sistema;
que incluyen:
− funciones de seguridad;
− configuración o arquitectura del sistema;
− requisitos de fiabilidad del hardware;
− requisitos de integridad de seguridad;
El nivel de integridad de seguridad del software deberá especificarse siguiendo el proceso general para obtener un nivel
de integridad de seguridad identificado en la Norma EN 50126.
5.2.2 El nivel de integridad de seguridad del software requerido se deberá decidir sobre la base del nivel de riesgo
asociado con el uso de software en el sistema y el nivel de integridad de seguridad del sistema.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 14 -
5.2.3 Sin precauciones adicionales, el nivel de integridad de seguridad del software deberá ser como mínimo, idéntico
al nivel de integridad de seguridad del sistema. Sin embargo, si existen mecanismos para evitar que el fallo de un módulo software produzca un estado inseguro del sistema, el nivel de integridad de seguridad del software del módulo
puede reducirse.
5.2.4 Los riesgos que se deberán tener en cuenta son aquellos asociados con las siguientes consecuencias peligrosas:
− pérdida de vidas humanas;
− daños o lesiones a las personas;
− contaminación ambiental; y
− pérdida o daños a la propiedad.
5.2.5 El riesgo puede cuantificarse, pero no es posible especificar la integridad de seguridad del software de la misma
manera. Por tanto, para esta norma, el nivel de integridad de seguridad del software se deberá especificar como uno de
los cinco niveles siguientes:
Nivel de Integridad de
Seguridad del Software
Descripción de la Integridad
De Seguridad del Software
4
Muy alta
3
Alta
2
Media
1
Baja
0
No Relacionado con la Seguridad
5.2.6 El nivel de integridad de seguridad del software se deberá especificar en la Especificación de Requisitos del
Software (capítulo 8). Si los diversos componentes software tienen niveles de integridad de seguridad del software
diferentes, éstos se deberán definir en la Especificación de la Arquitectura Software (capítulo 9).
6 PERSONAL Y RESPONSABILIDADES
6.1 Objetivo
Asegurar que todo el personal que tiene responsabilidades en el software es competente para asumir las mismas.
6.2 Requisitos
6.2.1 Como mínimo, el proveedor y/o el responsable del desarrollo y el cliente deberán implementar las partes relevantes de la Norma EN ISO 9001, de acuerdo con las pautas contenidas en la Norma EN ISO 9000-3.
6.2.2 Excepto para el nivel cero de integridad de seguridad del software, el proceso de seguridad se deberá implementar bajo el control de una organización de seguridad apropiada que cumpla el apartado "Organización de Seguridad" del
capítulo "Evidencia de Gestión de Seguridad" de la Norma EN 50129.
6.2.3 Todo el personal involucrado en las diferentes fases del Ciclo de Vida del Software, incluyendo las actividades
de gestión, deberá tener el entrenamiento, experiencia y cualificación apropiados.
6.2.4 Es altamente recomendable que el entrenamiento, experiencia y cualificación de todo el personal involucrado en
todas las fases del Ciclo de Vida del Software, incluyendo las actividades de gestión, sean justificados con respecto a la
aplicación particular, excepto para el nivel cero de integridad de seguridad del software.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 15 -
EN 50128:2001
6.2.5 La justificación contenida en el apartado 6.2.4 se deberá registrar en el Plan de Aseguramiento de la Calidad del
Software, y se deberá incluir evidencia de competencia en las siguientes áreas, según sea apropiado:
i) ingeniería apropiada al área de aplicación;
ii) ingeniería de software;
iii) ingeniería de sistemas informáticos;
iv) ingeniería de seguridad;
v) marco legal y regulador.
6.2.6 Se deberá nombrar un evaluador independiente para el software. Véanse los apartados 6.2.10 y 14.4.1.
6.2.7 Se deberá dar al evaluador la autoridad adecuada para realizar la evaluación del software.
6.2.8 A lo largo del Ciclo de Vida del Software, las partes involucradas deberán ser independientes en la medida requerida por el nivel de integridad de seguridad del software, de acuerdo con la figura 5, que se deberá interpretar como
sigue:
Para todos los niveles de integridad de seguridad del software, el evaluador deberá ser aprobado por la Autoridad de
Seguridad y deberá ser independiente del proveedor, excepto para las circunstancias definidas en el apartado 6.2.10.
El Diseñador/Implementador, Verificador y Validador pueden pertenecer a la misma compañía, pero deberán aplicarse
las siguientes reglas para garantizar una independencia mínima:
Para el nivel 0 de integridad de seguridad del software:
No hay restricciones; El Diseñador/Implementador, Verificador y Validador pueden ser la misma persona.
Para los niveles 1 y 2 de integridad de seguridad del software:
El Verificador y Validador pueden ser la misma persona pero no deberá ser el Diseñador/Implementador. Sin embargo, el Diseñador/Implementador, Verificador y Validador pueden depender todos del Director del Proyecto.
Para los niveles 3 y 4 de integridad de seguridad del software son admisibles dos casos:
a) El Verificador y Validador pueden ser la misma persona pero no deberá ser el Diseñador/Implementador. Además,
el Verificador y Validador no deberá depender del Director del Proyecto como el Diseñador/Implementador y deberá tener la autoridad suficiente como para impedir la liberación del producto.
b) El Diseñador/Implementador, Verificador y Validador deben ser personas distintas. El Diseñador/Implementador y
el Verificador pueden depender del Director del Proyecto, pero no el Validador, quien deberá tener la autoridad suficiente como para impedir la liberación del producto.
6.2.9 Las partes responsables de los diversos capítulos son como se indica a continuación:
Especificación de Requisitos del Software (capítulo 8)
Diseñador
Especificación de Ensayo de Requisitos del Software (capítulo 8)
Validador
Arquitectura Software (capítulo 9)
Diseñador
Diseño y Desarrollo Software (capítulo 10)
Diseñador
Verificación y Ensayo del Software (capítulo 11)
Verificador
Integración Hardware/Software (capítulo 12)
Diseñador
Validación del Software (capítulo 13)
Validador
Evaluación del Software (capítulo 14)
Evaluador
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 16 -
6.2.10 A criterio de la Autoridad de Seguridad, el Evaluador puede ser parte de la organización del proveedor o del
cliente, pero en tales casos el Evaluador deberá:
− ser autorizado por la Autoridad de Seguridad;
− ser totalmente independiente del equipo del proyecto;
− informar directamente a la Autoridad de Seguridad.
7 ETAPAS DEL CICLO DE VIDA Y DOCUMENTACIÓN
7.1 Objetivos
7.1.1 Estructurar el desarrollo del software en fases y actividades definidas.
7.1.2 Registrar toda la información pertinente del software a lo largo del ciclo de vida del mismo.
7.2 Requisitos
7.2.1 Se deberá seleccionar un modelo de ciclo de vida para el desarrollo del software. Ëste se deberá detallar en el
Plan de Aseguramiento de la Calidad del Software de acuerdo con el capítulo 15 de esta norma. Como ejemplo, dos
modelos de ciclo de vida se muestran en las figuras 3 y 4.
7.2.2 Los procedimientos de Aseguramiento de la Calidad se deberán seguir en paralelo con las actividades del ciclo
de vida y deberán utilizar la misma terminología.
7.2.3 Antes del comienzo de una fase se deberán definir todas las actividades a realizar en la misma. Cada fase del
ciclo de vida del software se deberá dividir en tareas elementales con una entrada, salida y actividad bien definidas para
cada una de ellas.
7.2.4 El Plan de Aseguramiento de la Calidad del Software deberá describir qué pasos de verificación e informes se
requieren.
7.2.5 Se deberán estructurar todos los documentos para permitir una expansión continuada en paralelo con el proceso
de diseño.
7.2.6 Se deberá asegurar la trazabilidad de los documentos mediante un número de referencia único y una relación
definida y documentada con otros documentos. Cada término, acrónimo o abreviatura deberá tener el mismo significado
en los distintos documentos. Si por razones históricas ello no es posible, se deberán enumerar los distintos significados
y dar las referencias.
Además, cada documento, excepto los relativos al software COTS (véase el apartado 9.4.5) o software desarrollado
previamente (véase el apartado 9.4.6) se deberá redactar de acuerdo a las siguientes reglas:
a) deberá contener o implementar todas las condiciones o requisitos aplicables del documento predecesor con el que
tenga una relación jerárquica;
b) no deberá contradecir al documento predecesor;
c) cada término, acrónimo o abreviatura deberá tener el mismo significado en todos los documentos;
d) cada elemento o concepto se deberá referenciar por el mismo nombre o descripción en todos los documentos.
7.2.7 El contenido de todos los documentos se deberá archivar en una forma apropiada para la manipulación, proceso
y almacenamiento.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 17 -
EN 50128:2001
7.2.8 En la medida requerida por el nivel de integridad de seguridad del software, se deberán generar los documentos
listados en la Tabla de Referencia Cruzada de Documentos.
7.2.9 Dependiendo del tamaño, complejidad y ciclo de vida del software que se desarrolle, variará el número de documentos que se deberán generar. Algunos documentos pueden ser combinados (asegurando que no haya pérdida del
detalle requerido en el proceso). Para proyectos grandes puede ser necesario subdividir la documentación listada (de
forma jerárquica) en un número de documentos hijos más manejables. Los documentos que han sido producidos por
equipos o entidades independientes no deberán combinarse en un único documento.
7.2.10 La relación entre los diversos documentos identificados en el capítulo 8 puede definirse también utilizando una
TRCD (una Tabla de Referencia Cruzada de Documentos). Para cada documento listado en la columna “Documentos”,
la fase y capítulo asociados con su creación pueden encontrarse leyendo horizontal y verticalmente desde la celda que
contiene el símbolo “g”. Las fases en las que se usa pueden encontrarse leyendo verticalmente desde las celdas marcadas con el símbolo “!“. El capítulo u otra referencia a la definición del documento pueden encontrase en la columna
“Dónde se define”. Cuando se indica un capítulo, deberían comprobarse también los capítulos siguientes ya que pueden
contener información adicional. Obsérvese que la referencia al Plan de Gestión de Configuración del Software se indica
entre paréntesis ya que ese capítulo simplemente hace referencia a la Norma EN ISO 9001.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 18 -
Tabla de referencia cruzada de documentos
Capítulo 8
título SRS
9
AS
10
DIS
11
12
13
VPS I S/H ValS
14
EvS
15
16
GCS MaS
FASES
(*) = en paralelo con
otras fases
ENTRADAS AL SISTEMA
DOCUMENTOS
!
!
!
!
!
!
!
!
PLANIFICACIÓN
(*)
SW
!
!
!
!
!
g
!
!
g
!
!
!
!
!
!
!
!
!
!
!
!
g
g
g
g
REQUISITOS SW
g
!
!
g
!
!
!
!
!
!
!
!
g
g
DISEÑO SW
g
!
g
!
!
MÓDULOS
!
!
g
!
!
!
!
!
!
!
!
!
INTEGRACIÓN SW
INTEGRACIÓN
SW/HW
VALIDACIÓN (*)
EVALUACIÓN (*)
MANTENIMIENTO
g
(15.4.2)
11.4.1
11.4.5
12.4.1
13.4.3
16.4.3
17.4.2.1
17.4.2.4
Especificación de Requisitos del Sw
Especificación de Requisitos de la
aplicación
Especificación de Ensayo de Requisitos
del Sw
Informe de Verificación de Requisitos
del Sw
8.4.1
17.4.1.1
9.4.1
10.4.3
11.4.12
8.4.13
11.4.11
Especificación de Diseño del Módulo
10.4.3
Sw
Especificación de Ensayo del Módulo
10.4.14
Sw
Informe de Verificación del Módulo Sw 11.4.13
!
Código Fuente Sw
Informe de Verificación del Código
Fuente Sw
11.4.14
!
Informe de Ensayos del Módulo Sw
10.4.14
g
Informe de Ensayos de Integración del
Sw
Informe de Ensayos de Datos
11.4.15
g
ENSAYO MÓDULOS
15.4.3
Especificación Arquitectura Sw
Especificación de Diseño del Sw
Verificación Arquitectura y Diseño Sw
!
!
Plan de Aseguramiento de la Calidad
del Sw
Plan de Gestión de Configuración del
Sw
Plan de Verificación del Sw
Plan de Ensayos de Integración del Sw
Plan de Ensayos de Integración Sw/Hw
Plan de Validación del Sw
Plan de Mantenimiento del Sw
Plan de Preparación de Datos
Plan de Ensayos de Datos
!
!
g
g
EN 50129,
anexo B.2.3
EN 50129,
anexo B.2.4
EN 50129,
anexo B.2.1
EN 50129 y
EN 50126
!
!
g
CODIFICACIÓN
Especificación de Requisitos del
Sistema
Especificación de Requisitos de
Seguridad del Sistema
Descripción de la Arquitectura del
Sistema
Plan de Seguridad del Sistema
!
!
g
DISEÑO
SW
Dónde se
define
g
Informe de Ensayos de Integración
Sw/Hw
g
g
g
g
17.4.2.4
12.4.8
Informe de Validación del Sw
13.4.10
Informe de Evaluación del Sw
14.4.9
Informes de Cambios del Sw
Informes de Mantenimiento del Sw
16.4.9
16.4.8
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 19 -
EN 50128:2001
8 ESPECIFICACIÓN DE REQUISITOS DEL SOFTWARE
8.1 Objetivos
8.1.1 Preparar un documento que defina un conjunto completo de requisitos para el software cumpliendo todos los
Requisitos del Sistema en la medida requerida por el nivel de integridad de seguridad del software. Su propósito es
servir como documento global para cada ingeniero de software y hacer innecesaria la tarea de buscar requisitos en otros
documentos.
8.1.2 Preparar la Especificación de Ensayo de Requisitos del Software.
8.2 Documentos de entrada
1) Especificación de Requisitos del Sistema.
2) Especificación de Requisitos de Seguridad del Sistema.
3) Descripción de la Arquitectura del Sistema.
4) Plan de Aseguramiento de la Calidad del Software.
8.3 Documentos de salida
1) Especificación de Requisitos del Software.
2) Especificación de Ensayo de Requisitos del Software.
8.4 Requisitos
8.4.1 La Especificación de Requisitos del Software deberá expresar las propiedades requeridas del software que se está
desarrollando, no los procedimientos para desarrollarlas. Estas propiedades, que están todas definidas (excepto la seguridad) en la Norma ISO/CEI 9126, deberán incluir:
− funcionalidad (incluyendo prestaciones de capacidad y tiempo de respuesta);
− fiabilidad y mantenibilidad;
− seguridad (incluyendo funciones de seguridad y sus niveles de integridad de seguridad del software asociados);
− eficiencia;
− usabilidad;
− portabilidad.
El nivel de integridad de seguridad del software se deberá obtener como se define en el capítulo 5 y registrarse en la
Especificación de Requisitos del Software.
8.4.2 En la medida requerida por el nivel de integridad de seguridad del software, la Especificación de Requisitos del
Software se deberá expresar y estructurar de manera que sea:
i) completa, clara, precisa, inequívoca, verificable, capaz de ser probada, mantenible y factible;
ii) trazable con respecto a todos los documentos mencionados en el apartado 8.2.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 20 -
8.4.3 La Especificación de Requisitos del Software deberá incluir expresiones y descripciones que sean comprensibles
para el personal responsable involucrado en el ciclo de vida completo del sistema.
8.4.4 La Especificación de Requisitos del Software deberá identificar y documentar todas las interfaces con otros
sistemas, dentro o fuera del equipo bajo control, incluyendo operadores, siempre que exista o esté planeada una conexión directa.
8.4.5 Se deberán detallar en la Especificación de Requisitos del Software todos los modos de operación relevantes.
8.4.6 Se deberán detallar en la Especificación de Requisitos del Software todos los modos relevantes de comportamiento de la electrónica programable, en particular el comportamiento ante defectos.
8.4.7 Se deberán identificar y documentar en la Especificación de Requisitos del Software todas las restricciones entre
el hardware y el software.
8.4.8 La Especificación de Requisitos del Software deberá indicar el grado de autocomprobación del software y el
grado especificado de comprobación del hardware por el software. La autocomprobación del software consiste en la
detección y manifestación, por parte del mismo software, de sus propios fallos y errores.
8.4.9 La Especificación de Requisitos del Software deberá incluir requisitos para el ensayo periódico de funciones en
la medida requerida por la Especificación de Requisitos de Seguridad del Sistema.
8.4.10 La Especificación de Requisitos del Software deberá incluir requisitos que permitan que todas las funciones de
seguridad se puedan ensayar durante el funcionamiento del sistema global, en la medida requerida por la Especificación
de Requisitos de Seguridad del Sistema.
8.4.11 Cuando se requiere del software la realización de funciones, especialmente aquellas relacionadas con la consecución del nivel de integridad de seguridad del sistema requerido, dichas funciones se deberán identificar claramente en
la Especificación de Requisitos del Software.
8.4.12 Cuando se requiere que el software realice funciones que no son de seguridad, dichas funciones se deberán
identificar claramente en la Especificación de Requisitos del Software.
8.4.13 Se deberá desarrollar una Especificación de Ensayo de Requisitos del Software a partir de la Especificación de
Requisitos del Software. Esta especificación de ensayo se deberá utilizar para la verificación de todos los requisitos
como se describe en la Especificación de Requisitos del Software y también como descripción de los ensayos a realizar
al software completo.
8.4.14 La Especificación de Ensayo de Requisitos del Software deberá identificar claramente para cada una de las
funciones requeridas los casos de ensayo, incluyendo:
i) las señales de entrada requeridas con sus secuencias y valores;
ii) las señales de salida previstas con sus secuencias y valores;
iii) los criterios de aceptación, incluyendo prestaciones y aspectos de calidad.
8.4.15 La trazabilidad con respecto a los requisitos deberá ser una consideración importante en la validación de un
sistema relacionado con la seguridad y se deberán proporcionar medios que permitan demostrarlo a lo largo de todas las
fases del ciclo de vida.
8.4.16 Se deberá demostrar que cualquier material no trazable no tiene influencia en la seguridad o integridad del sistema.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 21 -
EN 50128:2001
9 ARQUITECTURA SOFTWARE
9.1 Objetivos
9.1.1 Desarrollar una arquitectura software que satisfaga los requisitos de la Especificación de Requisitos del Software
en la medida requerida por el nivel de integridad de seguridad del software.
9.1.2 Revisar los requisitos asignados al software por la arquitectura del sistema.
9.1.3 Identificar y evaluar el significado de las interacciones Hardware/Software con respecto a la seguridad.
9.1.4 Elegir un método de diseño si no se ha definido previamente.
9.2 Documentos de entrada
1) Especificación de Requisitos del Software.
2) Especificación de Requisitos de Seguridad del Sistema.
3) Descripción de la Arquitectura del Sistema.
4) Plan de Aseguramiento de la Calidad del Software.
9.3 Documentos de salida
Especificación de la Arquitectura Software.
9.4 Requisitos
9.4.1 La arquitectura software propuesta la deberá establecer el proveedor del software y/o el responsable del desarrollo y detallada en la Especificación de la Arquitectura Software.
9.4.2 La Especificación de la Arquitectura Software deberá considerar la factibilidad de cumplir la Especificación de
Requisitos del Software para el nivel de integridad de seguridad del software requerido.
9.4.3 La Especificación de la Arquitectura Software deberá identificar, evaluar y detallar el significado de todas las
interacciones hardware/software. Tal como requieren las Normas EN 50126 y EN 50129, los estudios preliminares
relativos a las interacciones entre el hardware y el software se deberán haber registrado en la Especificación de Requisitos de Seguridad del Sistema.
9.4.4 La Especificación de la Arquitectura Software deberá identificar todos los componentes software, y para dichos
componentes:
i) si los componentes son nuevos, existentes o propios;
ii) si los componentes han sido validados previamente y, si es así, sus condiciones de validación;
iii) el nivel de integridad de seguridad software del componente.
9.4.5 El uso de software COTS deberá estar sujeto a las siguientes restricciones:
i) para el nivel de integridad de seguridad del software 0 se deberá aceptar el uso de software COTS sin precauciones
adicionales;
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 22 -
ii) si se va a utilizar software COTS en niveles de integridad de seguridad del software 1 y 2, esto se deberá incluir en
el proceso de validación del software.
iii) si se va a utilizar software COTS en niveles de integridad del software 3 y 4, se deberán tomar también las siguientes precauciones:
a) el software COTS se deberá incluir en los ensayos de validación;
b) se deberá llevar a cabo un análisis de posibles fallos;
c) se deberá definir una estrategia para detectar fallos en el software COTS y proteger al sistema de los mismos;
d) la estrategia de protección deberá ser objeto de ensayos de validación;
e) deberán existir registros de errores y se deberán evaluar;
f) en la medida de lo posible, sólo se deberán utilizar las funciones más simples del software COTS.
9.4.6 Si se va a usar software desarrollado previamente como parte del diseño, se deberá identificar y documentar
claramente. La Especificación de la Arquitectura Software deberá justificar la aptitud del software para satisfacer la
Especificación de Requisitos del Software y el nivel de integridad de seguridad del software. Los efectos de cualquier
cambio en el software sobre el resto del sistema deberán considerarse cuidadosamente a fin de decidir si es necesaria
una re-inspección o nueva evaluación. Se deberá tener una evidencia de que se han respetado las especificaciones de las
interfaces con otros módulos no re-verificados, re-validados o re-evaluados.
9.4.7 Siempre que sea posible, se deberán utilizar en el diseño módulos software existentes verificados y desarrollados
de acuerdo a esta norma.
9.4.8 La Arquitectura Software deberá minimizar la parte de seguridad de la aplicación.
9.4.9 Cuando el software incluya componentes de diferentes niveles de integridad de seguridad software, todos los
componentes software se deberán tratar como pertenecientes al nivel de integridad de seguridad software más alto, a
menos que haya evidencia de la independencia entre los componentes con nivel de integridad de seguridad software
más alto y los componentes con nivel de integridad de seguridad software más bajo. Esta evidencia se deberá registrar
en la Especificación de la Arquitectura Software.
9.4.10 La Especificación de la Arquitectura Software deberá identificar la estrategia para el desarrollo del software en
la medida requerida por el nivel de integridad de seguridad del software. La Especificación de la Arquitectura Software
se deberá expresar y estructurar de forma que sea:
i) Completa, clara, precisa, inequívoca, verificable, capaz de ser probada, mantenible y factible.
ii) Trazable con respecto a la Especificación de Requisitos del Software.
9.4.11 La Especificación de la Arquitectura Software deberá justificar el compromiso adoptado entre las estrategias
para evitar fallos y el manejo de los mismos.
9.4.12 La Especificación de la Arquitectura Software deberá justificar que las técnicas y medidas elegidas forman un
conjunto que satisface la Especificación de Requisitos del Software para el nivel de integridad de seguridad del software
requerido.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 23 -
EN 50128:2001
10 DISEÑO E IMPLEMENTACIÓN DEL SOFTWARE
10.1 Objetivos
10.1.1 Diseñar e implementar software de un nivel de integridad de seguridad definido a partir de la Especificación de
Requisitos del Software y la Especificación de la Arquitectura Software.
10.1.2 Obtener software que sea analizable, capaz de ser probado, verificable y mantenible. El ensayo de los módulos
se incluye también en esta fase. Puesto que la verificación y ensayo deberá ser un elemento crítico en la validación, se
deberá dar una consideración especial a las necesidades de verificación y ensayo a lo largo del diseño y desarrollo, a fin
de garantizar que el sistema resultante y su software sean fácilmente comprobables desde el principio.
10.1.3 Seleccionar un conjunto de herramientas adecuado, incluyendo lenguajes y compiladores, para el nivel de integridad de seguridad del software requerido, a lo largo del ciclo de vida completo del software, que ayuden durante la
verificación, validación, evaluación y mantenimiento.
10.1.4 Llevar a cabo la integración del software.
10.2 Documentos de entrada
1) Especificación de Requisitos del Software.
2) Especificación de la Arquitectura Software.
3) Plan de Aseguramiento de la Calidad del Software.
10.3 Documentos de salida
1) Especificación de Diseño del Software.
2) Especificación de Diseño del Módulo Software.
3) Especificación de Ensayo del Módulo Software.
4) Código Fuente del Software y documentación correspondiente.
5) Informe de Ensayos del Módulo Software.
10.4 Requisitos
10.4.1 La Especificación de Requisitos del Software y la Especificación de la Arquitectura Software deberán estar
disponibles, aunque no necesariamente finalizadas, antes del comienzo del proceso de diseño.
10.4.2 El tamaño y la complejidad del software desarrollado se deberá mantener al mínimo.
10.4.3 La Especificación de Diseño del Software deberá describir el diseño software en base a una descomposición en
módulos, teniendo cada uno una Especificación de Diseño del Módulo Software y una Especificación de Ensayo del
Módulo Software.
10.4.4 La Especificación de Diseño del Software deberá contemplar:
i) componentes software referidos a la arquitectura software y su nivel de integridad de seguridad;
ii) interfaces de los componentes software con el entorno;
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 24 -
iii) interfaces entre componentes software;
iv) estructura de datos;
v) distribución de los requisitos entre los componentes;
vi) algoritmos principales y secuencia;
vii)diagramas.
10.4.5 Las Especificaciones de Diseño del Módulo Software deberán incluir (una Especificación de Diseño del Módulo Software por módulo):
i) identificación de los componentes software más bajos (llamados módulos en esta norma) y sus relaciones con el
nivel superior;
ii) sus interfaces detalladas con el entorno y otros módulos, con entradas y salidas detalladas;
iii) su nivel de integridad de seguridad;
iv) algoritmos y estructuras de datos detalladas.
Cada Especificación de Diseño del Módulo Software debería ser auto-consistente y permitir la codificación del módulo
correspondiente
10.4.6 Cada módulo software deberá ser legible, comprensible y comprobable.
10.4.7 Se deberá seleccionar un conjunto de herramientas apropiado, incluyendo métodos de diseño, lenguajes y compiladores, para el nivel de integridad de seguridad del software requerido durante el ciclo de vida completo del software.
10.4.8 Cuando sea aplicable, se deberán utilizar herramientas de ensayo automáticas y herramientas de diseño integradas. Se deberán tener en cuenta las necesidades del Verificador y del Validador.
10.4.9 En la medida que lo exija el nivel de integridad de seguridad del software, el lenguaje de programación elegido
deberá tener un traductor/compilador que tenga una de las características siguientes:
i) un "Certificado de Validación" con respecto a una norma Nacional/Internacional reconocida;
ii) un informe de evaluación que detalle su aptitud para la aplicación;
iii) un proceso basado en un control de firma redundante que permita una detección de los errores de traducción.
10.4.10 El lenguaje escogido deberá satisfacer los requisitos siguientes:
i) deberá incluir prestaciones que faciliten la identificación de errores de programación;
ii) deberá soportar las características adaptadas al método de diseño.
10.4.11 Cuando no se pueda satisfacer el apartado 10.4.10 se deberá incluir en la Especificación de la Arquitectura
Software o en el Plan de Aseguramiento de la Calidad del Software una justificación para otro lenguaje alternativo
detallando su conveniencia para la aplicación.
10.4.12 Se deberán desarrollar y utilizar normas de codificación para el desarrollo de todo el software. Se deberán
incluir en el Plan de Aseguramiento de la Calidad del Software (véase el apartado 15.4.5).
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 25 -
EN 50128:2001
10.4.13 Las normas de codificación deberán especificar las buenas prácticas de programación, proscribir el uso de
características del lenguaje inseguras y describir procedimientos para la documentación del código fuente. Al menos,
cada módulo software deberá contener en el código fuente la información definida en la siguiente lista (no exhaustiva):
− autor
− histórico de configuración
− breve descripción
Se recomienda el uso de un formulario normalizado para esta información. Debería ser el mismo para todos los módulos.
10.4.14 Ensayo del Módulo Software: Cada módulo deberá tener una Especificación de Ensayo del Módulo Software
con respecto a la cual se deberá ensayar el módulo. Estos ensayos deberán demostrar que cada módulo desempeña su
función prevista. La Especificación de Ensayo del Módulo Software deberá definir el grado requerido que deberán
cubrir los ensayos.
Se deberá generar un Informe de Ensayo del Módulo Software que deberá incluir las características siguientes:
i) una declaración de los resultados de el ensayo y si cada módulo ha satisfecho los requisitos de su Especificación de
Diseño del Módulo Software;
ii) se deberá proporcionar para cada módulo una declaración de la cobertura del ensayo, mostrando que todas las instrucciones del código fuente se han ejecutado al menos una vez;
iii) deberá estar en un formato que sea auditable;
iv) los casos de ensayo y sus resultados se deberán registrar, en forma legible por máquina, para el análisis posterior.
Los ensayos deberían ser repetibles y realizados por medios automáticos, si ello es posible.
La comprobación de que cada módulo ha satisfecho correctamente su especificación de ensayo es una actividad de
verificación, véase el capítulo 11.
10.4.15 De acuerdo con el nivel de integridad de seguridad del software requerido, el método de diseño elegido deberá
incluir características que faciliten:
i) la abstracción, modularidad y otras características que controlen la complejidad;
ii) la expresión clara y precisa de:
− funcionalidad;
− flujo de información entre componentes;
− información relativa a la secuencia y tiempo;
− concurrencia;
− estructura de datos y propiedades;
iii) la comprensión humana;
iv) la verificación y validación.
10.4.16 El método de diseño elegido deberá incluir características que faciliten el mantenimiento del software. Dichas
características deberán incluir modularidad, ocultamiento de información y encapsulado.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 26 -
10.4.17 La integración de los módulos software deberá ser el proceso de combinar progresivamente módulos software
previamente ensayados de forma individual en un conjunto compuesto (o en un número de subsistemas compuestos) a
fin de que las interfaces de los módulos y el software ensamblado puedan ser adecuadamente ensayados antes de los
ensayos de integración del sistema.
10.4.18 Dentro del contexto de esta norma, y en la medida apropiada al nivel de integridad de seguridad del software
especificado, la trazabilidad deberá contemplar en particular:
i) trazabilidad de los requisitos en el diseño o en otros objetos que lo satisfagan;
ii) trazabilidad de los objetos de diseño en los objetos de implementación que los instancien.
La salida del proceso de trazabilidad deberá estar sujeta a gestión de configuración formal.
11 VERIFICACIÓN Y ENSAYO DEL SOFTWARE
11.1 Objetivo
En la medida requerida por el nivel de integridad de seguridad del software, ensayar y evaluar los productos de una fase
determinada para asegurar su corrección y consistencia con respecto a los productos y normas que han constituido la
entrada a esa fase.
11.2 Documentos de entrada
1) Especificación de Requisitos del Sistema.
2) Especificación de Requisitos de Seguridad del Sistema.
3) Especificación de Requisitos del Software.
4) Especificación de Ensayo de Requisitos del Software.
5) Especificación de la Arquitectura Software.
6) Especificación de Diseño del Software.
7) Especificación de Diseño del Módulo Software.
8) Especificación de Ensayo del Módulo Software.
9) Código Fuente Software y documentación correspondiente.
10)Plan de Aseguramiento de la Calidad del Software.
11)Informe de Ensayo del Módulo Software.
11.3 Documentos de salida
1) Plan de Verificación del Software.
2) Informe de Verificación de Requisitos del Software.
3) Informe de Verificación de la Arquitectura y el Diseño Software.
4) Informe de Verificación del Módulo Software.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 27 -
EN 50128:2001
5) Informe de Verificación del Código Fuente Software.
6) Plan de Ensayos de Integración del Software.
7) Informe de Ensayos de Integración del Software.
11.4 Requisitos
11.4.1 Se deberá crear un Plan de Verificación del Software a fin de poder dirigir adecuadamente las actividades de
verificación y satisfacer adecuadamente necesidades específicas de diseño u otras verificaciones. Durante el desarrollo
(y dependiendo del tamaño del sistema) el plan puede subdividirse en un número de documentos hijos que se van añadiendo de forma natural a medida que las necesidades detalladas de verificación están más claras.
11.4.2 El Plan de Verificación del Software deberá documentar todos los criterios, técnicas y herramientas a utilizar
durante el proceso de verificación de esa fase.
11.4.3 El Plan de Verificación del Software deberá describir las actividades a realizar para asegurar la corrección y
consistencia con respecto a los productos y normas de entrada a dicha fase.
11.4.4 El Plan de Verificación del Software deberá tener en cuenta lo siguiente:
i)
la selección de estrategias y técnicas de verificación. para evitar una complejidad indebida en la evaluación de las
actividades de verificación y ensayo, se debería dar preferencia a la selección de casos de ensayo y métodos, etc.,
que sean por si mismos fácilmente analizables;
ii)
la selección y utilización de equipos de ensayo del software;
iii) la selección y documentación de actividades de verificación;
iv)
la evaluación de los resultados de verificación obtenidos;
v)
la evaluación de los requisitos de fiabilidad;
vi)
los papeles y responsabilidades de aquellos implicados en el proceso de ensayo;
vii) el grado de cobertura de ensayos que se consigue.
11.4.5 El Plan de Ensayos de Integración del Software deberá documentar lo siguiente:
i) casos de ensayo y datos de ensayo;
ii) tipos de ensayos a realizar;
iii) entorno de ensayo, herramientas, configuración y programas;
iv) criterios de ensayo que servirán para juzgar que el ensayo es completo.
11.4.6 En cada fase de desarrollo se deberá demostrar que se satisfacen los requisitos funcionales, de fiabilidad, prestaciones y seguridad.
11.4.7 La verificación se deberá llevar a cabo por una parte independiente en la medida requerida por el nivel de integridad de seguridad del software como se define en la figura 5.
11.4.8 Los ensayos que no están totalmente documentados, llevados a cabo por el diseñador antes del proceso de verificación formal, no deberán considerarse como parte de la verificación.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 28 -
11.4.9 Los resultados de cada verificación deberán conservarse en una forma definida o referenciada en el Plan de
Verificación del Software que sea auditable.
11.4.10 Después de cada actividad de verificación se deberá generar un informe de verificación indicando si el software ha pasado el proceso de verificación o las razones de los fallos. Los informes de verificación deberán especificar
lo siguiente:
i) elementos que no cumplen la Especificación de Requisitos del Software, Especificación de Diseño Software o Especificaciones de Diseño del Módulo Software;
ii) elementos que no cumplen el Plan de Aseguramiento de la Calidad del Software;
iii) módulos, datos, estructuras y algoritmos pobremente adaptados al problema;
iv) errores o deficiencias detectados;
v) la identidad y configuración de los elementos verificados.
11.4.11 Verificación de Requisitos del Software: Una vez establecida la Especificación de Requisitos del Software, la
verificación deberá comprobar la:
i) suficiencia de la Especificación de Requisitos del Software para cumplir los requisitos establecidos en la Especificación de Requisitos del Sistema, en la Especificación de Requisitos de Seguridad del Sistema y en el Plan de Aseguramiento de la Calidad del Software;
ii) suficiencia de la Especificación de Ensayo de Requisitos del Software como ensayo de la Especificación de Requisitos del Software;
iii) consistencia interna de la Especificación de Requisitos del Software.
Los resultados deberán quedar registrados en el Informe de Verificación de Requisitos del Software.
11.4.12 Verificación de la Arquitectura y el Diseño Software: Una vez establecidas la Especificación de la Arquitectura
Software y la Especificación de Diseño del Software, la verificación deberá establecer la:
i) suficiencia de la Especificación de la Arquitectura Software y la Especificación de Diseño del Software para satisf acer la Especificación de Requisitos del Software;
ii) suficiencia de la Especificación de Diseño del Software para la Especificación de Requisitos del Software con respecto a consistencia y a que es completa;
iii) suficiencia del Plan de Ensayos de Integración del Software como un conjunto de casos de ensayo para la Especificación de la Arquitectura Software y la Especificación de Diseño del Software;
iv) la consistencia interna de las Especificaciones de la Arquitectura y el Diseño del Software.
Los resultados deberán quedar registrados en el Informe de Verificación de la Arquitectura y Diseño del Software.
11.4.13 Verificación del Módulo Software: Una vez establecida la Especificación de Diseño del Módulo Software, la
verificación deberá comprobar la:
i) suficiencia de la Especificación de Diseño del Módulo Software para cumplir la Especificación de Diseño del Software;
ii) suficiencia de la Especificación de Ensayo del Módulo Software como un conjunto de casos de ensayo para la Esp ecificación de Diseño del Módulo Software;
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 29 -
EN 50128:2001
iii) la descomposición de la Especificación de Diseño del Software en módulos software y las Especificaciones de
Diseño del Módulo Software en lo referente a:
− factibilidad de las prestaciones requeridas;
− comprobabilidad para la verificación posterior;
− disponibilidad por parte del equipo de desarrollo y verificación; y
− mantenibilidad para permitir la evolución posterior;
iv)
suficiencia de los Informes de Ensayo del Módulo Software como registro de los ensayos llevados a cabo de
acuerdo con la Especificación de Ensayo del Módulo Software.
Los resultados deberán quedar registrados en el Informe de Verificación del Módulo Software.
11.4.14 Verificación del Código Fuente Software: En la medida requerida por el nivel de integridad de seguridad del
software, el Código Fuente Software se deberá verificar para asegurar que es conforme a la Especificación de Diseño
del Módulo Software y al Plan de Aseguramiento de la Calidad del Software. Ello deberá incluir una comprobación
para determinar que las normas de codificación se han aplicado correctamente.
Los resultados deberán quedar registrados en un Informe de Verificación del Código Fuente Software.
11.4.15 Se deberá generar un Informe de Ensayos de Integración del Software como sigue:
i) se deberá generar un Informe de Ensayos de Integración del Software declarando los resultados de el ensayo y si se
han satisfecho los objetivos y criterios del Plan de Ensayos de Integración del Software. Si hay un fallo, se deberán
registrar las causas del mismo;
ii) el Informe de Ensayos de Integración del Software deberá estar en una forma que sea auditable;
iii) los casos de ensayo y sus resultados se deberán registrar preferiblemente en forma legible por máquina, para el análisis posterior;
iv) los ensayos deberían ser repetibles y realizados por medios automáticos, si ello es posible.
v) la identidad y configuración de los elementos verificados.
11.4.16 Con respecto a la integración software/hardware, véase el apartado 12.4.8.
12 INTEGRACIÓN SOFTWARE/HARDWARE
12.1 Objetivos
12.1.1 Demostrar que el software y el hardware interaccionan correctamente para realizar las funciones asignadas.
12.1.2 Combinar el software y el hardware, asegurando su compatibilidad para satisfacer la Especificación de Requisitos de Seguridad del Sistema y los requisitos del nivel de integridad de seguridad del software previsto.
12.2 Documentos de entrada
1) Especificación de Requisitos del Sistema.
2) Especificación de Requisitos de Seguridad del Sistema.
3) Descripción de la Arquitectura del Sistema.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 30 -
4) Especificación de Requisitos del Software.
5) Especificación de Ensayo de Requisitos del Software.
6) Especificación de la Arquitectura Software.
7) Especificación del Diseño del Software.
8) Especificación del Diseño del Módulo Software.
9) Especificación de Ensayo del Módulo Software.
10) Código Fuente Software y documentación correspondiente.
11) Documentación del Hardware.
12.3 Documentos de salida
1) Plan de Ensayos de Integración Software/Hardware.
2) Informe de Ensayos de Integración Software/Hardware
12.4 Requisitos
12.4.1 Para niveles de integridad de seguridad del software superiores al cero, se creará al comienzo del ciclo de vida
del desarrollo un Plan de Ensayos de Integración Software/Hardware, a fin de poder dirigir adecuadamente las actividades de integración y satisfacer adecuadamente las necesidades particulares del diseño u otras necesidades de integración. Durante el desarrollo (y dependiendo del tamaño del sistema), el plan puede subdividirse en un número de documentos hijos que se van añadiendo de forma natural a medida que evolucionan los diseños hardware y software y las
necesidades detalladas de integración están más claras.
12.4.2
El Plan de Ensayos de Integración Software/Hardware deberá documentar lo siguiente:
i) casos y datos de ensayo;
ii) tipos de ensayos a realizar;
iii) entorno de ensayos, incluyendo herramientas, software de soporte y descripción de configuración; y
iv) criterios de ensayos con respecto a los cuales se juzgarán los resultados de los mismos.
12.4.3 El Plan de Ensayos de Integración Software/Hardware deberá distinguir entre aquellas actividades que pueden
llevarse a cabo por parte del responsable del desarrollo en sus instalaciones y aquellas que requieren acceso al emplazamiento del usuario.
12.4.4
El Plan de Ensayos de Integración Software/Hardware deberá distinguir entre las actividades siguientes:
i) carga del software del sistema en el hardware real;
ii) integración del sistema.
12.4.5 Las herramientas e instalaciones identificadas en el Plan de Ensayos de Integración Software/Hardware deberían estar disponibles lo antes posible.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 31 -
EN 50128:2001
12.4.6 Cualquier modificación o cambio en el sistema integrado durante la Integración Software/Hardware se deberá
someter a un estudio de impacto que deberá identificar todos los módulos afectados y las actividades de re-verificación
necesarias.
12.4.7 Los casos de ensayo y sus resultados se deberán registrar, preferiblemente en forma legible por máquina, para el
análisis posterior.
12.4.8 Se deberá generar un Informe de Ensayos de Integración Software/Hardware como sigue:
i) el Informe de Ensayos de Integración Software/Hardware deberá declarar los resultados de los ensayos y si se han
alcanzado los objetivos y criterios del Plan de Ensayos de Integración Software/Hardware. Si hay un fallo, se deberá
registrar;
ii) el Informe de Ensayos de Integración Software/Hardware deberá estar en una forma que sea auditable;
iii) los casos de ensayo y sus resultados se deberán registrar preferiblemente en forma legible por máquina, para el análisis posterior;
iv) el Informe de Ensayos de Integración Software/Hardware deberá incluir también evidencia de que el verificador
aprueba la suficiencia del Informe de Ensayos de Integración Software/Hardware como registro de los ensayos llevados a cabo de acuerdo al Plan de Ensayos de Integración Hardware/Software;
v) el Informe de Ensayos de Integración Software/Hardware deberá documentar la identidad y configuración de los
elementos implicados.
13 VALIDACIÓN DEL SOFTWARE
13.1 Objetivo
Analizar y ensayar el sistema integrado para garantizar que cumple con la Especificación de Requisitos del Software
con especial énfasis en los aspectos funcionales y de seguridad de acuerdo al nivel de integridad de seguridad del software.
13.2 Documentos de entrada
1) Especificación de Requisitos del Software.
2) Documentación Hardware y Software completa.
3) Especificación de Requisitos de Seguridad del Sistema.
13.3 Documentos de salida
1) Plan de Validación del Software.
2) Informe de Validación del Software
13.4 Requisitos
13.4.1 El análisis y los ensayos deberá ser la actividad principal de la validación.
13.4.2 La simulación y el modelado pueden utilizarse para complementar el proceso de validación.
13.4.3 Se deberá establecer un Plan de Validación del Software y se deberá detallar en la documentación adecuada.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 32 -
13.4.4 El Plan de Validación del Software deberá ser desarrollado, realizado y evaluados sus resultados por una parte
independiente en la medida requerida por el nivel de integridad de seguridad del software.
13.4.5 Si se requiere por el nivel de integridad de seguridad del software, el alcance y los contenidos del Plan de Validación del Software se deberán consensuar con el evaluador. Este acuerdo deberá incluir también una cláusula referente
a la presencia del evaluador durante los ensayos.
13.4.6 El Plan de Validación del Software deberá incluir un resumen justificando la estrategia de validación elegida.
La justificación deberá incluir la consideración, según el nivel de integridad de seguridad del software requerido, de:
i) técnicas manuales o automáticas, o ambas;
ii) técnicas estáticas o dinámicas, o ambas;
iii) técnicas analíticas o estadísticas, o ambas.
13.4.7 El Plan de Validación del Software deberá identificar las etapas necesarias para demostrar la adecuación de la:
− Especificación de Requisitos del Software;
− Especificación de la Arquitectura Software;
− Especificación de Diseño del Software;
− Especificación de Diseño del Módulo Software.
para cumplir los requisitos de seguridad establecidos en la Especificación de Requisitos de Seguridad del Sistema. El
Validador deberá comprobar que el proceso de verificación es completo.
13.4.8 Los equipos de medición usados para la validación deberán estar calibrados adecuadamente. Se deberá demostrar que cualquier herramienta, hardware o software, utilizada para la validación es adecuada para el propósito que se
persigue.
13.4.9 Se deberá ejercitar el software mediante simulación de señales de entrada presentes en el funcionamiento normal, sucesos esperados y condiciones no deseadas que requieren acción por parte del sistema.
13.4.10 Los resultados de la validación se deberán documentar en el Informe de Validación del Software en una forma
que sea auditable.
13.4.11 Una vez terminada la integración hardware/software, se deberá generar un Informe de Validación del Software
como sigue:
i) deberá declarar si se han alcanzado los objetivos y criterios del Plan de Validación del Software. Si hay un fallo, se
deberá registrar;
ii) deberá declarar los resultados de los ensayos y si el software completo sobre la máquina real satisface los requisitos
establecidos en la Especificación de Requisitos del Software;
iii) se deberá proveer una evaluación sobre la medida en que los ensayos cubren los requisitos de la Especificación de
Requisitos del Software;
iv) el Informe de Ensayos de Requisitos del Software deberá estar en una forma que sea auditable;
v) los casos de ensayo y sus resultados se deberán registrar en forma legible por máquina, para el análisis posterior;
vi) los ensayos deberían ser repetibles y realizados por medios automáticos, si ello es posible.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 33 -
EN 50128:2001
13.4.12 El Informe de Validación del Software deberá documentar la identidad y configuración de la totalidad de:
i) el hardware y software usado;
ii) los equipos utilizados;
iii) la calibración de los equipos;
iv) los modelos de simulación empleados;
v) las discrepancias encontradas;
vi) las acciones correctivas tomadas.
13.4.13 Todas las discrepancias encontradas, incluyendo los errores detectados, se deberán identificar claramente en
una sección separada del Informe de Validación del Software y se deberán incluir en cualquier nota de la edición que
acompañe al software entregado.
13.4.14 El software se deberá ensayar con respecto a la Especificación de Ensayo de Requisitos del Software. Estos
ensayos deberán demostrar que todos los requisitos de la Especificación de Requisitos del Software se llevan a cabo
correctamente.
Los resultados se deberán registrar en el Informe de Validación del Software.
14 EVALUACIÓN DEL SOFTWARE
14.1 Objetivo
14.1.1 Evaluar que los procesos del ciclo de vida y los productos resultantes son tales que el software tiene el nivel de
integridad de seguridad definido y es apto para la aplicación a que se le destina.
14.2 Documentos de entrada
1) Especificación de Requisitos de Seguridad del Sistema.
2) Documentación Hardware y Software completa.
14.3 Documentos de salida
Informe de Evaluación del Software.
14.4 Requisitos
14.4.1
Para el nivel de integridad de seguridad del software cero:
i) el Evaluador solamente deberá confirmar que éste es el nivel de integridad de seguridad del software apropiado;
ii) es posible también acordar este nivel entre el proveedor y el usuario en el momento de la oferta.
14.4.2 El software que tenga un Informe de Evaluación de otro Evaluador no tiene que ser objeto de una nueva evaluación. El segundo Evaluador deberá comprobar que el software es del nivel de integridad de seguridad requerido y
que es apto para la aplicación a que se le destina sobre el ordenador elegido.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 34 -
14.4.3
yecto.
El Evaluador deberá tener acceso al proceso de diseño y desarrollo y a toda la documentación relativa al pro-
14.4.4
ño.
La evaluación del software se deberá llevar a cabo por un Evaluador que sea independiente del equipo de dise-
14.4.5 El Evaluador deberá evaluar que el software del sistema es apto para la aplicación a que está destinado y responde correctamente a los condicionantes de seguridad derivados de la Especificación de Requisitos de Seguridad del
Sistema.
14.4.6 En la medida requerida por el nivel de integridad de seguridad del software, el Evaluador deberá decidir si se
han seleccionado y aplicado métodos apropiados en cada fase del ciclo de vida del software.
14.4.7 Si se requiere por el nivel de integridad de seguridad del software, el Evaluador deberá aprobar el alcance y
contenidos del Plan de Validación del Software. Esta aprobación deberá incluir también una cláusula relativa a la presencia del Evaluador durante los ensayos.
14.4.8
El Evaluador puede solicitar trabajos de verificación y validación adicionales si así lo estima.
14.4.9
El Evaluador deberá elaborar un informe por cada revisión que deberá detallar los resultados de su evaluación.
14.4.10 Si en opinión del Evaluador el software es apto para su aplicación, el Informe de Evaluación del Software final
deberá incluir una declaración indicando el nivel de integridad de seguridad software alcanzado por el software.
14.4.11 Cuando el software no sea apto para la aplicación a que va destinado o no haya alcanzado el nivel de integridad
de seguridad requerido, el Evaluador deberá informar solamente sobre las no-conformidades en el Informe de Evaluación del Software y no deberá indicar las soluciones técnicas.
15 ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE
15.1 Objetivos
15.1.1 Identificar, supervisar y controlar todas aquellas actividades, tanto técnicas como de gestión, que son necesarias para asegurar que el software alcanza la calidad requerida. Esto es necesario para proporcionar las defensas cualitativas requeridas frente a defectos sistemáticos y asegurar que puede establecerse un seguimiento que permita que las
actividades de verificación y validación se lleven a cabo de forma efectiva.
15.1.2
Proporcionar evidencia de que las actividades anteriores se han llevado a cabo.
15.2 Documentos de entrada
Todos los documentos disponibles en cada etapa del ciclo de vida.
15.3 Documentos de salida
1) Plan de Aseguramiento de la Calidad del Software.
2) Plan de Gestión de Configuración del Software.
Todos estos planes se deberán emitir al comienzo del proyecto y se deberán poner al día durante el ciclo de vida.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 35 -
EN 50128:2001
15.4 Requisitos
15.4.1 El proveedor y/o responsable del desarrollo deberá tener y utilizar como mínimo un Sistema de Aseguramiento
de la Calidad que cumpla con las series de la Norma EN ISO 9000, a fin de soportar los requisitos de esta norma. La
acreditación de la Norma EN ISO 9001 es altamente recomendada.
15.4.2 Como mínimo, el proveedor y/o responsable del desarrollo y el cliente deberán implementar las partes relevantes de la Norma EN ISO 9001 para el desarrollo del software, de acuerdo con las pautas contenidas en la Norma
EN ISO 9000-3.
15.4.3 El proveedor y/o responsable del desarrollo deberá preparar y documentar para cada proyecto, un Plan de Aseguramiento de la Calidad del Software para implementar los requisitos de los apartados 15.4.1 y 15.4.2 de esta norma,
que se deberán expresar en términos medibles siempre que sea posible.
15.4.4 El Plan de Aseguramiento de la Calidad del Software deberá incluir un párrafo especificando detalles sobre su
puesta al día a lo largo del proyecto: frecuencia, responsabilidad, método.
15.4.5 Todas las actividades, acciones, documentos, etc. requeridos por todas las secciones de la Norma
EN ISO 9000-3 y esta norma (anexo A incluido) se deberán especificar o referenciar en el Plan de Aseguramiento de la
Calidad del Software y se deberán adaptar al desarrollo especifico. Ninguna de las listas de la Norma EN ISO 9000-3
deberá presuponerse como exhaustiva.
Como mínimo, excepto para el nivel de integridad de seguridad del software cero, los elementos que figuran a continuación se deberán especificar o referenciar también en el Plan de Aseguramiento de la Calidad del Software.
Esto es para garantizar que se cubren todos los aspectos de seguridad en el software con relación al nivel de integridad
de seguridad del software requerido.
La lista que se presenta a continuación no es exhaustiva:
i)
definición del modelo de ciclo de vida
definición de cada fase incluyendo:
− actividades y tareas elementales;
− criterios de entrada y salida;
− entradas y salidas de cada fase;
− actividades de calidad principales en cada fase;
− unidad organizativa responsable para cada actividad y tarea elemental.
ii)
requisitos de trazabilidad;
iii) trazabilidad de la estructura de la documentación;
iv)
documentación asociada con el desarrollo, verificación y validación, operación y mantenimiento del software;
v)
procedimientos de integración del sistema;
vi)
normas de codificación a utilizar;
vii) evaluación de los ensayos de validación previos;
viii) definición de la métrica (medidas cuantitativas) a aplicar tanto en el producto como en el proceso. En cuanto a la
métrica a aplicar al producto software, se deberá hacer referencia a las características de calidad y pautas de evaluación definidas por la Norma ISO/CEI 9126.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 36 -
15.4.6 Como mínimo, se deberá llevar a cabo una gestión de configuración de acuerdo con las pautas contenidas en la
Norma EN ISO 9000-3.
Cada documento software se deberá someter a control de configuración antes de sacar la primera versión aprobada. El
código fuente software se deberá someter al control de configuración antes del comienzo de los ensayos de módulo
documentados.
No deberá ser posible efectuar cambios no autorizados a cualquier elemento que esté bajo Control de Gestión de Conf iguración. Se deberán tomar precauciones para evitar o detectar errores que ocurran en el código durante el almacenamiento, transferencia, transmisión o duplicado.
La Gestión de Configuración no deberá estar limitada estrictamente al desarrollo y mantenimiento del producto, si no
que deberá comprender también el entorno utilizado durante el ciclo de vida completo. Esta ampliación, necesaria para
hacer reproducibles las actividades de desarrollo y mantenimiento, deberá incluir ficheros de configuración de ordenador, ensambladores, compiladores, depuradores y demás herramientas utilizadas.
15.4.7 Se deberán examinar la suficiencia y resultados de los Planes de Verificación del Software.
15.4.8 El proveedor y/o responsable del desarrollo deberán establecer, documentar y mantener procedimientos para el
Control de Proveedores Externos, incluyendo:
− métodos para asegurar que el software suministrado por proveedores externos se adapta a los requisitos establecidos.
Se deberá asegurar que el software desarrollado previamente cumple con el nivel de integridad de seguridad del
software y confiabilidad requeridos. El software nuevo se deberá desarrollar y mantener en conformidad con el Plan
de Aseguramiento de la Calidad del Software del Proveedor o con un Plan de Aseguramiento de la Calidad del
Software específico preparado por el proveedor externo de acuerdo con el Plan de Aseguramiento de la Calidad del
Software del Proveedor;
− métodos para asegurar que los requisitos impuestos al Proveedor de Software Externo son adecuados y completos.
15.4.9 El proveedor y/o responsable del desarrollo deberán establecer, documentar y mantener procedimientos para
Informar sobre Problemas y Acciones Correctivas. Estos procedimientos, como parte del Sistema de Aseguramiento de
la Calidad, deberán implementar las partes relevantes de la Norma EN ISO 9001, cubriendo especialmente al menos los
siguientes aspectos:
− definir la documentación necesaria para informar sobre problemas y/o acciones correctivas, con objeto de proporcionar realimentación a la dirección responsable;
− definir el análisis de la información recogida en los informes sobre problemas para identificar las causas;
− definir las prácticas a seguir para informar, seguir y resolver los problemas identificados, tanto durante la fase de
desarrollo del software como durante su mantenimiento;
− definir las acciones preventivas para tratar los problemas al nivel requerido por el nivel de integridad de seguridad
del software;
− definir las responsabilidades organizativas específicas en relación con el desarrollo y mantenimiento del software;
− definir cómo aplicar controles para asegurar que se han tomado las acciones correctivas y que son efectivas;
− definir los formularios a utilizar;
− definir los requisitos para nuevos ensayos, re-verificación, re-validación y nueva evaluación.
Como mínimo, se deberán gestionar los informes sobre problemas y acciones correctivas durante el ciclo de vida del
software que empieza inmediatamente después de la Integración del Software y antes de comenzar la Validación formal
del Software, cubriendo también la fase completa de Mantenimiento del Software.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 37 -
EN 50128:2001
16 MANTENIMIENTO DEL SOFTWARE
16.1 Objetivo
Asegurar que el software se comporta en la forma requerida, preservándose el nivel de integridad de seguridad y la
confiabilidad requeridos cuando se efectúan correcciones, mejoras o adaptaciones del propio software.
16.2 Documentos de entrada
Todos los documentos.
16.3 Documentos de salida
1) Plan de Mantenimiento del Software.
2) Registros de Cambios del Software.
3) Registro de Mantenimiento del Software.
16.4 Requisitos
16.4.1 Como mínimo, el mantenimiento se deberá llevar a cabo de acuerdo con las pautas contenidas en la Norma
EN ISO 9000-3.
Además, se deberán cumplir los siguientes requisitos relativos al mantenimiento del software.
16.4.2 La mantenibilidad se deberá incluir en el diseño del sistema software, en particular siguiendo los requisitos del
capítulo 10 de esta norma. Debería utilizarse también la Norma ISO/CEI 9126 para requerir y verificar un nivel mínimo
de mantenibilidad.
16.4.3 Se deberán establecer y registrar en el Plan de Mantenimiento del Software procedimientos para el mantenimiento del mismo. Estos procedimientos deberán incluir también:
i) control de informes de errores, libros de errores, registros de mantenimiento, autorización de cambio y configuración del software/sistema; y
ii) verificación, validación y evaluación;
iii) definición de la Autoridad que aprueba el software modificado.
16.4.4 Las actividades de mantenimiento se deberán auditar de acuerdo con el Plan de Mantenimiento del Software, a
intervalos definidos en el Plan de Aseguramiento de la Calidad del Software.
16.4.5 El mantenimiento se deberán realizar con el mismo nivel de experiencia, herramientas, documentación, planificación y gestión que el desarrollo inicial del sistema. Esto se deberá aplicar también a la gestión de configuración, control de cambios, control de documentos, e independencia de las partes implicadas.
16.4.6 No se pretende que esta norma sea retroactiva. Se aplica por tanto a nuevos desarrollos en principio y solo se
aplica en su totalidad a sistemas existentes cuando se someten a modificaciones importantes. Para niveles de integridad
de seguridad del software 3 y 4, las entidades contratantes deberán decidir, antes de empezar a trabajar en cualquier
cambio, si las acciones de mantenimiento se consideran importantes o menores o si los métodos de mantenimiento
existentes para el sistema son adecuados. Para niveles de integridad de seguridad del software 0, 1 y 2, la misma decisión deberá ser tomada por el proveedor.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 38 -
16.4.7 El control del proveedor externo, los informes sobre problemas y las acciones correctivas se deberán gestionar
con los mismos criterios especificados en los párrafos relevantes del capítulo de Aseguramiento de la Calidad del Software.
16.4.8 Se deberá establecer un Registro de Mantenimiento del Software para cada elemento de software antes de sacar
la primera versión y se deberá mantener. Además de los requisitos de la Norma EN ISO 9000-3 para “Registros de
Mantenimiento e Informes”, este registro deberá incluir también:
i) referencias a todos los Registros de Cambio de Software para ese elemento;
ii) información de la consecuencia del cambio;
iii) casos de ensayo para componentes, incluyendo datos para ensayos de re-validación y regresión;
iv) historia de configuración del software.
16.4.9 Se deberá establecer un Registro de Cambios de Software para cada actividad de mantenimiento. Este registro
deberá incluir:
i) a modificación o petición de cambio;
ii) un análisis del impacto de la actividad de mantenimiento sobre el sistema global, incluyendo hardware, software,
interacción humana y con el entorno y otras posibles interacciones;
iii) la especificación detallada de la modificación o cambio; y
iv) revalidación, ensayos de regresión y nueva evaluación de la modificación o cambio en la medida requerida por el
nivel de integridad de seguridad del software. La responsabilidad con respecto a la re-validación puede variar de
proyecto a proyecto según el nivel de integridad de seguridad del software. También el impacto de la modificación o
cambio en el proceso de re-validación puede confinarse a diferentes niveles del sistema (solamente los módulos modificados, todos los módulos que se hayan identificado como afectados, el sistema completo). Por tanto el Plan de
Validación del Software deberá tratar ambos problemas, según el nivel de integridad de seguridad del software. El
grado de independencia de la re-validación deberá ser el mismo que el de la validación.
17 SISTEMAS CONFIGURADOS MEDIANTE DATOS DE APLICACIÓN
17.1 Objetivos
17.1.1 Un aspecto característico de los sistemas de control y protección del ferrocarril es la necesidad de diseñar cada
instalación para satisfacer los requisitos individuales de una aplicación específica. Un sistema configurado por datos de
aplicación permite usar software genérico de un tipo aprobado, con los requisitos individuales de cada instalación definidos como datos (datos específicos de la aplicación). Estos datos se definen normalmente en forma de tablas o mediante un lenguaje específico de aplicación que es interpretado por el software genérico.
17.1.2 Para un sistema crítico con respecto a la seguridad, el alto nivel de recursos necesarios para desarrollar software
que alcance el nivel de integridad de seguridad requerido por el sistema hace muy atractiva la adopción de un sistema
configurado por datos de aplicación, ya que permite la reutilización del software genérico. Sin embargo, como es muy
probable que la operación segura del sistema dependa de lo correctos que sean los datos, los procedimientos utilizados
para el desarrollo de los mismos deben tener también un nivel de integridad de seguridad apropiado al sistema.
17.1.3 Las secciones que siguen describen los requisitos de esta norma para el desarrollo inicial del software genérico
para un sistema configurado por datos de aplicación, y para el desarrollo consiguiente de cada conjunto de datos para
una instalación específica.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 39 -
EN 50128:2001
17.2 Documentos de entrada
1) Especificación de Requisitos del Software.
2) Especificación de la Arquitectura Software.
17.3 Documentos de salida
1) Definición de los Requisitos de la Instalación.
2) Plan de Preparación de Datos.
3) Plan de Ensayos de Datos.
4) Informe de Ensayos de Datos.
17.4 Requisitos
17.4.1 Ciclo de vida de Preparación de Datos. La figura 6 ilustra un ciclo de vida para una aplicación que utiliza
hardware y software genérico, con datos específicos de la aplicación. Las fases del ciclo de vida son como sigue:
17.4.1.1 Especificación de los Requisitos de la Aplicación. Se deberán definir los requisitos para la aplicación. Ello
deberá incluir los requisitos que son específicos a la instalación particular (por ejemplo, disposición de vías, situación
de señales, límites de velocidad) y normas que deberá cumplir la aplicación (por ejemplo, principios de señalización,
niveles de integridad de seguridad del sistema).
17.4.1.2 Diseño de la Instalación Global. Se deberá definir la arquitectura del sistema, y se deberá especificar la
cantidad y tipo de componentes genéricos a utilizar. Aquellos componentes que contengan software deberán haber sido
desarrollados de acuerdo con esta norma. Las funciones especificadas en los requisitos se deberán asignar a los componentes, y se deberá definir la localización física de cada uno de ellos.
17.4.1.3 Preparación de Datos. El proceso de preparación de datos deberá incluir la elaboración de información
específica (por ejemplo, cuadros de incompatibilidades), generación del código fuente de los datos y su compilación,
comprobación y otras actividades de verificación, y ensayos de datos de aplicación.
17.4.1.4 Integración y aceptación. En algunos sistemas, los datos de aplicación se integrarán con el hardware y software genérico para un ensayo en fábrica antes de la instalación real. Esto puede ser innecesario cuando sea posible
obtener un grado de confianza suficiente por otros medios. El equipo se deberá instalar entonces en el emplazamiento
real y los ensayos de integración se deberán llevar a cabo en el nuevo equipo. Finalmente, el sistema se deberá poner en
servicio como plenamente operativo, y se deberá llevar a cabo un proceso final de aceptación en la instalación completa.
17.4.1.5 Validación y Evaluación. Las actividades de validación y evaluación deberán auditar el cumplimiento de
cada etapa del ciclo de vida.
17.4.2 Procedimientos y Herramientas para la Preparación de Datos. Para cada nuevo tipo de sistema configurado
por datos de aplicación, se deberán desarrollar procedimientos y herramientas de preparación de datos específicos que
permitan aplicar el ciclo de vida de preparación de datos especificado en el apartado 17.4.1 a instalaciones del nuevo
sistema. El desarrollo de dichos procedimientos y herramientas se deberá llevar a cabo de acuerdo con esta norma en
paralelo con el del software y hardware genérico del sistema. Las actividades de verificación, validación y evaluación
deberán garantizar que las herramientas de preparación de datos y el software genérico son compatibles.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 40 -
17.4.2.1 En la fase de Diseño del Software para el sistema configurado por datos de aplicación, se deberá generar un
Plan de Preparación de Datos que defina una estructura documental para el proceso de preparación de datos. Estos documentos deberán estar relacionados con el modelo de ciclo de vida de preparación de datos descrito en el apartado
17.4.1. El plan deberá especificar los procedimientos y herramientas para la preparación de datos a utilizar para satisfacer los niveles de integridad de seguridad del sistema requeridos. El plan deberá especificar los requisitos para la independencia entre el personal que lleva a cabo las tareas de verificación, validación y diseño.
17.4.2.2 El Plan de Preparación de Datos deberá asignar un nivel de integridad de seguridad a cualquier herramienta
hardware o software utilizada en el ciclo de vida de preparación de datos. Este nivel de integridad de seguridad se deberá derivar del nivel de integridad de seguridad que se requiere del sistema y del grado en que la salida de cada herramienta es comprobada por otros procedimientos manuales o automáticos.
17.4.2.3 Siempre que sea posible, el Plan de Preparación de Datos deberá utilizar notaciones familiares a los ingenieros de aplicación para especificar los requisitos y el diseño, por ejemplo, planos de señalización habituales y cuadros de
incompatibilidades. Cuando se introduzcan notaciones nuevas, se deberá suministrar la documentación de usuario necesaria y se deberá proveer también formación cuando sea apropiado.
17.4.2.4 Los informes de verificación, ensayo, validación y valoración requeridos para demostrar que la preparación
de datos se ha llevado a cabo de acuerdo con el plan, pueden ser estandarizados en forma de listas de comprobación
para minimizar el trabajo de producir documentación para cada instalación. Esta información deberá estar incluida en el
Plan de Ensayos de Datos y los resultados se deberán registrar en el Informe de Ensayos de Datos.
17.4.2.5 Todos los datos y documentación asociada se deberán someter a los requisitos de gestión de configuración de
la sección 15 de esta norma. Los registros de gestión de configuración deberán enumerar la versión del software genérico con el cual deberán funcionar los datos diseñados, y las versiones de las herramientas utilizadas en el proceso de
preparación de datos.
17.4.3 Desarrollo del Software. El desarrollo del software genérico a utilizar en un sistema configurado por datos de
aplicación deberá cumplir con los requisitos de los capítulos 1 a 16 de esta norma. Se deberán observar además los
siguientes requisitos adicionales:
17.4.3.1 Durante la fase de Especificación de Requisitos del Software, se deberán identificar aquellas funciones que
hacen uso de datos de aplicación en cada sistema y subsistema. El nivel de integridad de seguridad del sistema asignado
a cada subsistema determinará las normas a aplicar al desarrollo posterior de los datos para todas las instalaciones del
sistema.
17.4.3.2 Durante la fase de Diseño del Software se deberán especificar las interfaces detalladas entre el software genérico y los datos de aplicación, a menos que ello se haya hecho ya en una fase anterior del ciclo de vida, por ejemplo
como resultado de un requisito para utilizar un lenguaje específico de aplicación existente.
17.4.3.3 Durante la fase de Diseño del Módulo Software se deberá imponer una separación rígida entre el código del
programa y los datos, por ejemplo, deberá ser posible recompilar y actualizar bien el software genérico o bien los datos
sin que sea necesario actualizar el otro, a menos que haya habido un cambio en la interface definida entre el software y
los datos. De igual manera, los datos específicos de aplicación deberán estar separados de otros datos.
17.4.3.4 Durante la fase de Mantenimiento del Software, los procedimientos de control de cambios deberán asegurar
que cualquier corrección del software genérico puede ser instalado solamente si se ha establecido que el software revisado es compatible con los datos originales o bien se ha efectuado la revisión de datos necesaria.
17.4.3.5 Se deberá tener cuidado en el proceso de Verificación del Software y en la fase de Validación del Software
para asegurar que se consideran todas las combinaciones relevantes de datos.
17.4.3.6 El software genérico se deberá diseñar de forma que detecte datos de configuración corrompidos siempre que
sea factible.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 41 -
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Fig. 1 − Niveles de Integridad para Sistemas Relacionados con la Seguridad
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 42 -
Fig. 2 − Ciclo de Seguridad del Software
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 43 -
EN 50128:2001
Fig. 3 − Ciclo de Vida de Desarrollo 1
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 44 -
Fig. 4 − Ciclo de Vida de Desarrollo 2
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 45 -
EN 50128:2001
Fig. 5 − Independencia en función del Nivel de Integridad del Software
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 46 -
Fig. 6 − Relación entre Desarrollo del Sistema Genérico y Desarrollo de la Aplicación
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 47 -
EN 50128:2001
ANEXO A (Normativo)
CRITERIOS PARA LA SELECCIÓN DE TÉCNICAS Y MEDIDAS
Cada uno de los capítulos 7 a 16 de esta norma tiene una tabla capítulo asociada para ilustrar los medios de conseguir la
conformidad. Existen tablas de nivel inferior, las tablas detalladas, que expanden ciertas entradas en las tablas capítulos.
Por ejemplo, los Métodos Semi-Formales de la tabla capítulo 8 se expanden en la tabla D.7 detallada. También hay un
anexo B informativo al que se hace referencia en las tablas capítulo.
Con cada técnica o medida en las tablas hay un requisito para cada nivel de integridad de seguridad del software
(SIL SW) 1 a 4 y también para el nivel 0 no relacionado con la seguridad. En esta versión del documento, los requisitos
para los niveles de integridad de seguridad del software 1 y 2 son los mismos para cada técnica. De forma similar, cada
técnica tiene los mismos requisitos en los niveles de integridad de seguridad del software 3 y 4. Estos requisitos pueden
ser:
'O'
Este símbolo significa que el uso de la técnica es obligatorio.
'AR'
Este símbolo significa que la técnica o medida es Altamente Recomendada para ese nivel de integridad de
seguridad. Si la técnica o medida no se utiliza, las razones subyacentes para no hacerlo se deberían detallar
en el Plan de Aseguramiento de la Calidad del Software o en otro documento referenciado por él.
'R'
Este símbolo significa que la técnica o medida es Recomendada para ese nivel de integridad de seguridad.
Es un nivel de recomendación inferior que el 'AR' y dichas técnicas pueden combinarse formando parte de
un paquete.
'−'
Este símbolo significa que la técnica o medida no tiene recomendación a favor o en contra para utilizarse.
'NR'
Este símbolo significa que la técnica o medida es positivamente No Recomendada para ese nivel de integridad de seguridad. Si la técnica o medida es utilizada, las razones subyacentes para hacerlo se deberían detallar en el Plan de Aseguramiento de la Calidad del Software o en otro documento referenciado por él.
La combinación de técnicas o medidas se deberá establecer en el Plan de Aseguramiento de la Calidad del Software o
en otro documento referenciado por él, seleccionando una o varias a menos que las notas que acompañan a las tablas
establezcan otros requisitos. Dichas notas pueden incluir referencias a técnicas o combinaciones de técnicas aprobadas.
Si se utilizan esas técnicas o combinaciones de técnicas, el Evaluador las deberá aceptar como válidas y deberá comprobar solamente que han sido correctamente aplicadas. Si se ha usado un conjunto de técnicas diferentes y puede justificarse, el Evaluador puede admitirlo como aceptable.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 48 -
Tablas Capítulo
Tabla A.1
Etapas del Ciclo de Vida y Documentación (capítulo 7)
DOCUMENTACIÓN
SIL
SW 0
SIL
SW 1
SIL
SW 2
SIL
SW 3
SIL
SW 4
1
Documentos de Planificación del Software
R
AR
AR
AR
AR
2
Documentos de Requisitos S/W
R
AR
AR
AR
AR
3
Documentos de Diseño S/W
–
AR
AR
AR
AR
4
Documentos de Módulos S/W
–
AR
AR
AR
AR
5
Código Fuente y Documentación
R
AR
AR
AR
AR
6
Informes de Ensayos S/W
–
AR
AR
AR
AR
7
Informe de Ensayos de Integración S/W y H/W
–
AR
AR
AR
AR
8
Informe de Validación S/W
R
AR
AR
AR
AR
9
Informe de Evaluación S/W
–
AR
AR
AR
AR
10
Registros de Mantenimiento S/W
R
AR
AR
AR
AR
Requisito:
El cumplimiento con la Norma EN ISO 9000-3 implica la generación de la documentación adecuada para
todos los niveles de integridad de seguridad del software. Para el Nivel de Integridad de Seguridad del
Software 0, el diseñador deberá elegir los tipos de documentos adecuados.
Tabla A.2
Especificación de Requisitos del Software (capítulo 8)
TÉCNICA/MEDIDA
Ref
SIL
SW 0
SIL
SW 1
SIL
SW 2
SIL
SW 3
SIL
SW 4
1
Métodos Formales, incluyendo por ejemplo CCS,
CSP, HOL, LOTOS, OBJ, Lógica Temporal,
VDM Z y B
B.30
-
R
R
AR
AR
2
Métodos Semi-Formales
D.7
R
R
R
AR
AR
3
Metodología Estructurada, incluyendo por ejemplo JSD, MASCOT, SADT, SDL, SSADM y
Yourdon
B.60
R
AR
AR
AR
AR
Requisitos:
1
La Especificación de Requisitos del Software requerirá siempre una descripción del problema en
lenguaje natural y la notación matemática necesaria que refleje la aplicación.
2
La tabla refleja requisitos adicionales para definir de forma clara y precisa la aplicación. Se deberán
seleccionar una o varias técnicas para satisfacer el nivel de integridad de seguridad del software que se
esté utilizando.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 49 -
EN 50128:2001
Tabla A.3
Arquitectura Software (capítulo 9)
TÉCNICA/MEDIDA
Ref
SIL
SW 0
SIL
SW 1
SIL
SW 2
SIL
SW 3
SIL
SW 4
1
Programación Defensiva
B.15
–
R
R
AR
AR
2
Diagnosis y Detección de Defectos
B.27
–
R
R
AR
AR
3
Códigos de Corrección de Errores
B.20
–
–
–
–
–
4
Códigos de Detección de Errores
B.20
–
R
R
AR
AR
5
Programación con Detección de Fallos
B.25
–
R
R
AR
AR
6
Técnicas de Bolsa de Seguridad
B.54
–
R
R
R
R
7
Programación con Diversidad
B.17
–
R
R
AR
AR
8
Recuperación en Bloque
B.50
–
R
R
R
R
9
Recuperación Regresiva
B.5
–
NR
NR
NR
NR
10
Recuperación Progresiva
B.32
–
NR
NR
NR
NR
11
Mecanismos de Recuperación de Fallos por
Reintento
B.53
–
R
R
R
R
12
Memorización de Casos Ejecutados
B.39
–
R
R
AR
AR
13
Inteligencia Artificial – Corrección de Fallos
B.1
–
NR
NR
NR
NR
14
Reconfiguración Dinámica del software
B.18
–
NR
NR
NR
NR
15
Análisis de Efectos de Errores software
B.26
–
R
R
AR
AR
16
Análisis de Arbol de Fallos
B.28
R
R
R
AR
AR
Requisitos:
1
Combinaciones aprobadas de técnicas para los Niveles de Integridad de Seguridad del Software 3 y 4 son
las siguientes:
a) 1, 7 y una de 4, 5 ó 12;
b) 1, 4 y 5;
c) 1, 4 y 12;
d) 1, 2 y 4;
e) 1 y 4, y una de 15 y 16.
2
Con la excepción de las entradas 3, 9, 10, 13 y 14, se deberán seleccionar una o varias de estas técnicas
para satisfacer los requisitos de los Niveles de Integridad de Seguridad del Software 1 y 2.
3
Algunas de estas cuestiones pueden definirse a nivel del sistema.
4
Se pueden usar códigos de corrección de errores de acuerdo con los requisitos de la Normas EN 50159-1
y EN 50159-2.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 50 -
Tabla A.4
Diseño e Implementación del Software (capítulo 10)
TÉCNICA/MEDIDA
Ref
SIL
SW 0
SIL
SW 1
SIL
SW 2
SIL
SW 3
SIL
SW 4
1
Métodos Formales incluyendo por ejemplo CCS,
CSP, HOL, LOTOS, OBJ, Lógica Temporal,
VDM, Z y B
B.30
–
R
R
AR
AR
2
Métodos Semi-Formales
D.7
R
AR
AR
AR
AR
3
Metodología Estructurada incluyendo por ejemplo
JSD, MASCOT, SADT, SDL, SSADM y Yourdon
B.60
R
AR
AR
AR
AR
4
Aproximación Modular
D.9
AR
O
O
O
O
5
Estándares de Diseño y Codificación
D.1
AR
AR
AR
O
O
6
Programas Analizables
B.2
AR
AR
AR
AR
AR
7
Lenguaje de Programación Fuertemente Tipado
B.57
R
AR
AR
AR
AR
8
Programación Estructurada
B.61
R
AR
AR
AR
AR
9
Lenguaje de Programación
D.4
R
AR
AR
AR
AR
10
Subconjunto del Lenguaje
B.38
–
–
–
AR
AR
11
Traductor Validado
B.7
R
AR
AR
AR
AR
12
Traductor Probado por el Uso
B.65
AR
AR
AR
AR
AR
13
Librería de Módulos y Componentes Comprobados/Verificados
B.40
R
R
R
R
R
14
Ensayos Funcionales y de Caja-negra
D.3
AR
AR
AR
O
O
15
Ensayos de Prestaciones
D.6
–
AR
AR
AR
AR
16
Ensayos de Interfaces
B.37
AR
AR
AR
AR
AR
17
Registro y Análisis de Datos
B.13
AR
AR
AR
O
O
18
Lógica Borrosa
B.67
–
–
–
–
–
19
Programación Orientada a Objetos
B.68
–
R
R
R
R
Requisitos:
1
Se deberá escoger un conjunto adecuado de técnicas de acuerdo al nivel de integridad de seguridad del
software.
2
Para los niveles de integridad de seguridad del software 3 y 4, el conjunto de técnicas aprobado deberá
incluir una de las técnicas 1, 2 ó 3, junto con una de las técnicas 11 ó 12. A pesar de ello, las técnicas
restantes se deberán tratar de acuerdo a sus recomendaciones.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 51 -
EN 50128:2001
Tabla A.5
Verificación y Ensayos (capítulo 11)
TÉCNICA/MEDIDA
Ref
SIL
SW 0
SIL
SW 1
SIL
SW 2
SIL
SW 3
SIL
SW 4
1
Ensayo Formal
B.31
–
R
R
AR
AR
2
Ensayos Probabilísticos
B.47
–
R
R
AR
AR
3
Análisis Estático
D.8
–
AR
AR
AR
AR
4
Análisis y Ensayos Dinámicos
D.2
–
AR
AR
AR
AR
5
Evaluaciones
B.42
–
R
R
R
R
6
Matriz de Trazabilidad
B.69
–
R
R
AR
AR
7
Análisis de Efectos de Errores software
B.26
–
R
R
AR
AR
Requisitos:
1
Para los niveles de integridad de seguridad del software 3 y 4, las combinaciones de técnicas aprobadas
deberán ser:
a) 1 y 4;
b) 3 y 4; ó
c) 4, 6 y 7.
2
Para los niveles de integridad de seguridad del software 1 y 2, la técnica aprobada deberá ser 1 ó 4.
Tabla A.6
Integración Software/Hardware (capítulo 12)
TÉCNICA/MEDIDA
Ref
SIL
SW 0
SIL
SW 1
SIL
SW 2
SIL
SW 3
SIL
SW 4
1
Ensayos Funcionales y de Caja-negra
D.3
AR
AR
AR
AR
AR
2
Ensayos de Prestaciones
D.6
–
R
R
AR
AR
Requisitos:
1
Para el nivel de integridad de seguridad del software 0, la técnica 1 deberá ser la aprobada.
2
Para los niveles de integridad de seguridad del software 1, 2, 3 ó 4, la combinación de técnicas aprobada
deberá ser 1 y 2.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 52 -
Tabla A.7
Validación del Software (capítulo 13)
TÉCNICA/MEDIDA
Ref
SIL
SW 0
SIL
SW 1
SIL
SW 2
SIL
SW 3
SIL
SW 4
1
Ensayos Probabilísticos
B.47
–
R
R
AR
AR
2
Ensayos de Prestaciones
D.6
–
AR
AR
O
O
3
Ensayos Funcionales y de Caja negra
D.3
AR
AR
AR
O
O
4
Modelado
D.6
–
R
R
R
R
Requisito:
Para los niveles de integridad de seguridad del software 1, 2, 3 ó 4, una combinación de técnicas aprobada
deberá ser 2 y 3.
Tabla A.8
Capítulos a evaluar
CAPÍTULO A EVALUAR
Capítulo
SIL
SW 0
SIL
SW 1
SIL
SW 2
SIL
SW 3
SIL
SW 4
1
Niveles de Integridad de Seguridad del S/W
5
AR
AR
AR
AR
AR
2
Personal y Responsabilidades
6
–
R
R
AR
AR
3
Ciclo de Vida y Documentación
7
–
AR
AR
AR
AR
4
Especificación de Requisitos S/W
8
R
AR
AR
AR
AR
5
Arquitectura S/W
9
–
R
R
AR
AR
6
Diseño y Desarrollo
10
–
R
R
AR
AR
7
Verificación
11
–
AR
AR
AR
AR
8
Integración S/W-H/W
12
–
R
R
AR
AR
9
Validación S/W
13
–
AR
AR
AR
AR
10
Aseguramiento de la Calidad
15
–
AR
AR
AR
AR
11
Mantenimiento
16
–
AR
AR
AR
AR
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 53 -
EN 50128:2001
Tabla A.9
Evaluación del Software (capítulo 14)
Técnicas de Evaluación
TÉCNICA DE EVALUACIÓN
Ref
SIL
SW 0
SIL
SW 1
SIL
SW 2
SIL
SW 3
SIL
SW 4
1
Listas de Comprobación
B.8
AR
AR
AR
AR
AR
2
Análisis Estático del Software
B.14
B.42
D.8
R
AR
AR
AR
AR
3
Análisis Dinámico del Software
D.2
D.3
–
R
R
AR
AR
4
Diagramas de Causa Consecuencia
B.6
R
R
R
R
R
5
Análisis mediante Árbol de Eventos
B.23
–
R
R
R
R
6
Análisis mediante Árbol de Fallos
B.28
R
R
R
AR
AR
7
Análisis de Efectos de Errores Software
B.26
–
R
R
AR
AR
8
Análisis de Fallos de Modo Común
B.10
–
R
R
AR
AR
9
Modelos de Markov
B.41
–
R
R
R
R
10
Diagrama de Bloques de Fiabilidad
B.51
–
R
R
R
R
11
Ensayos de Campo antes de la Puesta en Servicio
–
R
AR
AR
AR
AR
Requisito:
Se deberá seleccionar una o varias de estas técnicas para satisfacer el nivel de integridad de seguridad del
software utilizado.
Tabla A.10
Aseguramiento de la Calidad del Software (capítulo 15)
TÉCNICA/MEDIDA
Capítulo
o Ref
SIL
SW 0
SIL
SW 1
SIL
SW 2
SIL
SW 3
SIL
SW 4
1
Acreditado según la Norma EN ISO 9001
15
R
AR
AR
AR
AR
2
Cumpliendo la Norma EN ISO 9000-3
15
O
O
O
O
O
3
Sistema de Calidad de la Compañía
15
O
O
O
O
O
4
Gestión de Configuración Software
B.56
O
O
O
O
O
Tabla A.11
Mantenimiento del Software (capítulo 16)
TÉCNICA/MEDIDA
Ref
SIL
SW 0
SIL
SW 1
SIL
SW 2
SIL
SW 3
SIL
SW 4
1
Análisis de Impacto
B.35
R
AR
AR
O
O
2
Registro y Análisis de Datos
B.13
AR
AR
AR
O
O
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 54 -
Tablas Detalladas
Tabla A.12
Normas de Diseño y Codificación (D.1)
Referenciada por el capítulo 10
TÉCNICA/MEDIDA
Ref
SIL
SW 0
SIL
SW 1
SIL
SW 2
SIL
SW 3
SIL
SW 4
1
Existencia de normas de Codificación
B.16
AR
AR
AR
AR
AR
2
Pautas para el Estilo de Codificación
B.16
AR
AR
AR
AR
AR
3
Ausencia de Objetos Dinámicos
B.16
–
R
R
AR
AR
4
Ausencia de Variables Dinámicas
B.16
–
R
R
AR
AR
5
Uso Limitado de Punteros
B.16
–
R
R
R
R
6
Uso Limitado de Recursividad
B.16
–
R
R
AR
AR
7
Ausencia de Saltos Incondicionales
B.16
–
AR
AR
AR
AR
Requisitos:
1
Se admite que las técnicas 3, 4 y 5 pueden estar presentes como parte de un compilador o traductor
validado.
2
Se deberá seleccionar un conjunto adecuado de técnicas de acuerdo al nivel de integridad de la seguridad del software.
Tabla A.13
Análisis Dinámico y Ensayos (D.2)
Referenciada por los capítulos 11 y 14
TÉCNICA/MEDIDA
Ref
SIL
SW 0
SIL
SW 1
SIL
SW 2
SIL
SW 3
SIL
SW 4
1
Ejecución de Casos de Ensayo a partir del Análisis de Valores Extremos
B.4
–
AR
AR
AR
AR
2
Ejecución de Casos de Ensayo a partir de Intuición de Errores
B.21
R
R
R
R
R
3
Ejecución de Casos de Ensayo a partir de Introducción de Errores
B.22
–
R
R
R
R
4
Modelado de Prestaciones
B.45
–
R
R
AR
AR
5
Clases de Equivalencia y Ensayos de Partición
de Entradas
B.19
–
R
R
AR
AR
6
Ensayos Basados en la Estructura
B.58
–
R
R
AR
AR
Requisitos:
1
El análisis de los casos de ensayo es a nivel de subsistema y se basa en la especificación y/o en la
especificación y el código.
2
Se deberá elegir un conjunto adecuado de técnicas en función del nivel de integridad de seguridad del
software.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 55 -
EN 50128:2001
Tabla A.14
Ensayo Funcional/Caja Negra (D.3)
Referenciada por los capítulos 10, 12, 13 y 14
TÉCNICA/MEDIDA
Ref
SIL
SW 0
SIL
SW 1
SIL
SW 2
SIL
SW 3
SIL
SW 4
1
Ejecución de Casos de Ensayo a partir de Diagramas de Causa Consecuencia
B.6
–
–
–
R
R
2
Prototipado/Animación
B.49
–
–
–
R
R
3
Análisis de Valores Extremos
B.4
R
AR
AR
AR
AR
4
Clases de Equivalencia y Ensayos de Partición de
Entradas
B.19
R
AR
AR
AR
AR
5
Simulación de Procesos
B.48
R
R
R
R
R
Requisitos:
1
El grado de perfección de la simulación dependerá del nivel de integridad de seguridad del software,
complejidad y aplicación.
2
Se deberá elegir un conjunto adecuado de técnicas en función del nivel de integridad de seguridad del
software.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 56 -
Tabla A.15
Lenguajes de Programación (D.4)
Referenciada por el capítulo 10
TÉCNICA/MEDIDA
Ref
SIL
SW 0
SIL
SW 1
SIL
SW 2
SIL
SW 3
SIL
SW 4
1
ADA
B.62
R
AR
AR
R
R
2
MODULA-2
B.62
R
AR
AR
R
R
3
PASCAL
B.62
R
AR
AR
R
R
4
Fortran 77
B.62
R
R
R
R
R
5
'C' o C++ (sin restricción)
B.62
R
–
–
NR
NR
6
Subconjunto de C o C++ con normas de codificación
B.62
B.38
R
R
R
R
R
7
PL/M
B.62
R
R
R
NR
NR
8
BASIC
B.62
R
NR
NR
NR
NR
9
Ensamblador
B.62
R
R
R
–
–
10
Diagramas de Escalera
B.62
R
R
R
R
R
11
Bloques Funcionales
B.62
R
R
R
R
R
12
Lista de Sentencias
B.62
R
R
R
R
R
Requisitos:
1
Para los Niveles de Integridad de Seguridad del Software 3 y 4, cuando se usa un subconjunto de los
lenguajes 1, 2, 3 y 4, la recomendación se convierte en AR.
2
Para ciertas aplicaciones, los lenguajes 7 y 9 pueden ser los únicos disponibles. Cuando no hay una
opción Altamente Recomendada para los niveles de integridad de seguridad del software 3 y 4, se
recomienda encarecidamente que para elevar la recomendación a 'R' debería haber un subconjunto de
esos lenguajes y un conjunto preciso de normas de codificación.
3
Para más información acerca de la evaluación sobre si un lenguaje de programación es adecuado,
consultar la referencia 'Lenguaje de Programación Adecuado' en la bibliografía del capítulo B.62.
4
Si un lenguaje específico no está en la tabla no significa que esté automáticamente excluido. Sin
embargo, debería ser conforme al capítulo B.62.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 57 -
EN 50128:2001
Tabla A.16
Modelado (D.5)
Referenciada por el capítulo 13
TÉCNICA/MEDIDA
Ref
SIL
SW 0
SIL
SW 1
SIL
SW 2
SIL
SW 3
SIL
SW 4
1
Diagramas de Flujo de Datos
B.12
–
R
R
R
R
2
Máquinas de Estados Finitos
B.29
–
AR
AR
AR
AR
3
Métodos Formales
B.30
–
R
R
AR
AR
4
Modelado de Prestaciones
B.45
–
R
R
AR
AR
5
Redes de Petri Temporales
B.64
–
AR
AR
AR
AR
6
Prototipado/Animación
B.49
–
R
R
R
R
7
Diagramas de Estructura
B.59
–
R
R
AR
AR
Requisito:
Se deberá elegir un conjunto adecuado de técnicas en función del nivel de integridad de seguridad del
software.
Tabla A.17
Ensayos de Prestaciones (D.6)
Referenciada por los capítulos 10, 12 y 13
TÉCNICA/MEDIDA
Ref
SIL
SW 0
SIL
SW 1
SIL
SW 2
SIL
SW 3
SIL
SW 4
1
Ensayos de Avalancha/Estrés
B.3
–
R
R
AR
AR
2
Tiempos de Respuesta y Limitaciones de Memoria
B.52
–
AR
AR
AR
AR
3
Requisitos de Prestaciones
B.46
–
AR
AR
AR
AR
Requisito:
Se deberá elegir un conjunto adecuado de técnicas en función del nivel de integridad de seguridad del
software.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 58 -
Tabla A.18
Métodos Semi-Formales (D.7)
Referenciada por los capítulos 8 y 10
TÉCNICA/MEDIDA
Ref
SIL
SW 0
SIL
SW 1
SIL
SW 2
SIL
SW 3
SIL
SW 4
1
Diagramas de Bloques Lógicos /Funcionales
–
R
R
R
AR
AR
2
Diagramas de Secuencia
–
R
R
R
AR
AR
3
Diagramas de Flujo de Datos
B.12
R
R
R
R
R
4
Máquinas de Estados Finitos/ Diagramas de
Transición de Estados
B.29
–
R
R
AR
AR
5
Redes de Petri Temporales
B.64
–
R
R
AR
AR
6
Tablas de Decisión/Verdad
B.14
R
R
R
AR
AR
Requisito:
Se deberá elegir un conjunto adecuado de técnicas en función del nivel de integridad de seguridad del
software.
Tabla A.19
Análisis Estático (D.8)
Referenciada por los capítulos 11 y 14
TÉCNICA/MEDIDA
Ref
SIL
SW 0
SIL
SW 1
SIL
SW 2
SIL
SW 3
SIL
SW 4
1
Análisis de Valores Extremos
B.4
–
R
R
AR
AR
2
Listas de Comprobación
B.8
–
R
R
R
R
3
Análisis de Flujo de Control
B.9
–
AR
AR
AR
AR
4
Análisis de Flujo de Datos
B.11
–
AR
AR
AR
AR
5
Intuición de Errores
B.21
–
R
R
R
R
6
Inspecciones de Fagan
B.24
–
R
R
AR
AR
7
Análisis de Caminos Furtivos
B.55
–
–
-
R
R
8
Ejecución Simbólica
B.63
–
R
R
AR
AR
9
Ensayos/Revisiones de Diseño
B.66
AR
AR
AR
AR
AR
Requisito:
Se deberá elegir un conjunto adecuado de técnicas en función del nivel de integridad de seguridad del
software.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 59 -
EN 50128:2001
Tabla A.20
Aproximación Modular (D.9)
Referenciada por el capítulo 10
TÉCNICA/MEDIDA
Ref
SIL
SW 0
SIL
SW 1
SIL
SW 2
SIL
SW 3
SIL
SW 4
1
Módulos de Tamaño Limitado
B.43
AR
AR
AR
AR
AR
2
Ocultamiento de la Información/ Encapsulado
B.36
R
AR
AR
AR
AR
3
Número de Parámetros Limitado
B.43
R
R
R
R
R
4
Un Punto de Entrada/Un Punto de Salida en
Subrutinas y Funciones
B.43
R
AR
AR
AR
AR
5
Interfaces Completamente Definidas
B.43
AR
AR
AR
O
O
Requisito:
Se deberá elegir un conjunto adecuado de técnicas en función del nivel de integridad de seguridad del
software.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 60 -
ANEXO B (Informativo)
BIBLIOGRAFÍA DE TÉCNICAS
B.1 Corrección de Errores basada en IA (Referenciada por el capítulo 9)
Objetivo
Ser capaz de reaccionar a posibles amenazas de forma muy flexible introduciendo una mezcla (combinación) de métodos y modelos de proceso y algún tipo de análisis de fiabilidad y seguridad durante el funcionamiento.
Descripción
En particular, la predicción de errores (calculando tendencias), corrección de errores, acciones de supervisión y mantenimiento pueden ser soportadas por sistemas basados en Inteligencia Artificial de forma muy eficiente en diversos canales de un sistema, ya que las reglas pueden derivarse directamente de las especificaciones y ser comprobadas respecto
a las mismas. Ciertos errores comunes que se introducen en las especificaciones al tener en mente ciertas reglas de diseño e implementación pueden evitarse de forma efectiva mediante esta aproximación, especialmente cuando se aplican
una combinación de modelos y métodos de manera funcional o descriptiva.
Los métodos se seleccionan de forma que puedan corregirse los errores y minimizar el efecto de los fallos, a fin de
obtener la seguridad y fiabilidad deseadas.
B.2 Programas Analizables (Referenciada por el capítulo 10)
Objetivo
Diseñar un programa de forma que su análisis sea factible de forma fácil. El comportamiento del programa debe ser
comprobable completamente basándose en el análisis.
Descripción
La intención es producir programas que sean fáciles de analizar usando métodos de análisis estático. A fin de conseguirlo, deberían seguirse las reglas de programación estructurada, como por ejemplo:
− El flujo de control del módulo deberá estar compuesto de construcciones estructuradas, esto es, secuencias, iteraciones y selección.
− Los módulos deberían ser pequeños.
− El número de caminos posibles dentro del módulo es pequeño.
− Las partes de programa individuales se tienen que diseñar de manera que estén tan desacopladas como sea posible.
− La relación entre los parámetros de entrada y salida debería ser lo más simple posible.
− No se debería utilizar cálculos complejos como base de bifurcaciones y decisiones de bucles.
− Las decisiones de bifurcación y bucles deberían estar relacionadas de forma simple con los parámetros de entrada
del módulo.
− Los límites entre diferentes ubicaciones en memoria deberán ser simples.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 61 -
EN 50128:2001
Referencias
Verificación - Problemas Prácticos. B.J.T. Webb and D.J. Mannering, SARSS 87, Nov. 1987, Altrincham, England,
Elsevier Applied Science, ISBN 1-85166-167-0, 1987.
Una Experiencia en Diseño y Validación del Software para un Sistema de Protección de un Reactor. S. Bologna, E. de
Agostino et. al., IFAC Workshop, SAFECOMP 1979, Stuttgart, 16-18 May 1979, Pergamon Press 1979.
B.3 Ensayos de Avalancha/Estrés (Referenciada por D.6)
Objetivo
Someter al objeto bajo ensayo a una carga de trabajo excepcionalmente alta a fin de demostrar que soportaría las cargas
de trabajo normales fácilmente.
Descripción
Hay una serie de condiciones de ensayo que se pueden aplicar en los ensayos de avalancha/estrés. Algunas de las mismas se indican a continuación:
− si se trabaja en modo de interrogación cíclica, el objeto bajo ensayo recibe muchos más cambios en las entradas por
unidad de tiempo que en condiciones normales;
− si se trabaja bajo demanda, el número de peticiones por unidad de tiempo sobre el objeto bajo ensayo se incrementa
por encima de las que se producen en condiciones normales;
− si el tamaño de una base de datos juega un papel importante, se incrementa por encima de las condiciones normales;
− dispositivos que influyen de forma importante se ajustan a su máxima o mínima velocidad respectivamente;
− para los casos extremos, todos los factores que tienen influencia, se llevan a las condiciones límite al mismo tiempo,
en la medida de lo posible.
Bajo estas condiciones de ensayo puede evaluarse el comportamiento en el tiempo del objeto bajo ensayo. Puede observarse la influencia de los cambios de la carga de trabajo. Puede comprobarse el correcto dimensionamiento de zonas de
almacenamiento temporal interno o variables dinámicas, pilas, etc.
B.4 Análisis de Valores Extremos (Referenciada por D.2, D.3 y D.8)
Objetivo
Eliminar errores de software que tienen lugar en los valores extremos o fronteras de los parámetros.
Descripción
El dominio de entrada del programa se divide en un número de clases de entrada. Los ensayos deberán cubrir las fronteras y extremos de las clases. Los ensayos comprobarán que las fronteras en el dominio de entrada de la especificación
coinciden con las del programa. El uso del valor cero, de forma directa o indirecta, es propenso al error y requiere especial atención:
− división por cero;
− caracteres ASCII blancos;
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 62 -
− pila o lista de elementos vacía;
− matriz nula;
− entrada en tabla vacía.
Normalmente las fronteras de la entrada tienen una correspondencia directa con las fronteras del rango de salida. Los
casos de ensayo se deberían escribir para forzar la salida a sus valores límites. Considerar también si es posible especificar un caso de ensayo que dé lugar a que la salida exceda los valores límites especificados.
Si la salida es una secuencia de datos, por ejemplo, una tabla impresa, se debería prestar especial atención al primero y
último elemento y a la lista que contiene ninguno, 1 y 2 elementos.
Referencia
El Arte de Ensayar Software. G. Myers, Wiley & Sons, New York, USA, 1979.
B.5 Recuperación Regresiva (Referenciada por el capítulo 9)
Objetivo
Proporcionar una operación funcional correcta en presencia de uno o varios fallos.
Descripción
Si se ha detectado un defecto, el sistema se reinicializa a un estado interno anterior cuya consistencia ya se ha comprobado previamente. Este método implica salvaguardar el estado interno frecuentemente en determinados puntos de comprobación bien definidos. Esto puede hacerse globalmente (para la base de datos completa) o incrementalmente (solamente los cambios entre puntos de comprobación). El sistema tiene que compensar los cambios que se han producido en
el intervalo mediante indagación (rastreo de acciones), compensación (los efectos de los cambios se anulan) o interacción (manual) externa.
B.6 Diagramas de Causa Consecuencia (Referenciada por el capítulo 14 y D.3)
Objetivo
Modelar, en forma de diagrama, las secuencia de eventos que pueden desarrollarse en un sistema como consecuencia de
combinaciones de eventos básicos.
Descripción
Puede contemplarse como una combinación de análisis mediante árbol de fallos y árbol de eventos. Comenzando por un
evento crítico, se traza un gráfico causa-consecuencia hacia atrás y hacia adelante. En dirección hacia atrás es equivalente a un árbol de fallos con el evento crítico como evento superior. En dirección hacia delante se identifican las posibles consecuencias que pueden derivarse de un evento. El gráfico puede contener símbolos de tipo angular que describen las condiciones de propagación a lo largo de las diferentes ramas desde el vértice. Pueden incluirse también retardos
temporales. Estas condiciones pueden describirse también con árboles de fallos. Las líneas de propagación pueden
combinarse con símbolos lógicos para hacer el diagrama más compacto. Hay definidos un conjunto de símbolos normalizados para uso en los diagramas causa consecuencia. Los diagramas pueden utilizarse para calcular la probabilidad de
ocurrencia de ciertas consecuencias críticas.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 63 -
EN 50128:2001
Referencia
El Método del Diagrama Causa Consecuencia como Base para el Análisis Cuantitativo de Accidentes. D.S. Nielsen,
Riso-M-1374, 1971.
B.7 Traductores y Herramientas Certificados (Referenciada por el capítulo 10)
Objetivo
Las herramientas son necesarias para ayudar al equipo de desarrollo del software en las diferentes fases de desarrollo
del mismo. Siempre que sea posible las herramientas deberían estar certificadas de forma que pueda tenerse un nivel de
confianza con respecto a la exactitud de las salidas.
Descripción
Una herramienta certificada es aquella que se ha catalogado como de una calidad concreta. La certificación de una herramienta se llevará a cabo generalmente por un organismo independiente, a menudo nacional, frente a criterios establecidos independientemente, típicamente normas nacionales o internacionales. Idealmente, las herramientas utilizadas en
todas las fases del desarrollo (definición, diseño, codificación, ensayos y validación) y las de gestión de configuración,
deberán someterse a certificación. Actualmente, solamente los compiladores (traductores) se someten regularmente a
procedimientos de certificación; estos son emitidos por organismos de certificación nacionales los cuales ejercitan los
compiladores (traductores) frente a estándares internacionales tales como los de Ada y Pascal.
Referencias
Secuencia de Validación Pascal. UK distributor: BSI Quality Assurance, PO Box 375, Milton Keynes, MK14 6LL.
Secuencia de Validación Ada. UK distributor: National Computing Centre (NCC), Oxford Road, Manchester, England.
B.8 Listas de Comprobación (Referenciada por el capítulo 14 y D.8)
Objetivo
Proporcionar un estímulo para una valoración crítica de todos los aspectos del sistema en lugar de formular los requisitos específicos.
Descripción
La persona que realiza la lista de comprobación completa un conjunto de cuestiones. Muchas de las cuestiones son de
carácter general y el Evaluador debe interpretarlas de la forma más apropiada para el sistema particular que está siendo
valorado.
Para acomodar las amplias variaciones en el software y en los sistemas sujetos a validación, la mayoría de las listas de
comprobación contienen cuestiones que se aplican a muchos tipos de sistemas. Como resultado, puede haber preguntas
en la lista que se está usando que no sean relevantes al sistema con el que se está tratando y se deberían ignorar. Igualmente, puede ser necesario para el sistema particular, complementar la lista normalizada con cuestiones dirigidas específicamente al sistema actual.
En cualquier caso deberá quedar claro que el uso de listas de comprobación depende de forma crítica de la experiencia y
criterio del ingeniero que selecciona y aplica la misma. Los resultados de las decisiones tomadas por el ingeniero con
respecto a la(s) lista(s) de ensayo seleccionada(s) y las cuestiones adicionales o superfluas, se deberían documentar y
justificarán completamente. El objetivo es garantizar que las listas de comprobación se puedan revisar y que se obtendrán los mismos resultados a menos que se usen criterios diferentes.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 64 -
El objetivo al completar una lista de ensayo es ser tan conciso como sea posible. Cuando sea necesaria una justificación
detallada se debería hacer mediante referencia a documentación adicional. Se debería usar un conjunto restringido de
palabras, tales como Cumple, Falla o No Concluyente o similar, para registrar los resultados de cada pregunta. La concisión simplifica grandemente el proceso de llegar a una conclusión global como resultado de la valoración de los resultados de la lista de ensayo.
Referencias
Sistemas Electrónicos Programables en Aplicaciones Relacionadas con la Seguridad. Health and Safety Executive, Her
Majesty's Stationary Office, London 1987.
Pautas para la Valoración de la Seguridad y Fiabilidad de Sistemas Industriales de Alta Integridad basados en Ordenadores. EWICS TC7, WP 489, 6th October 1987.
El Arte de Ensayar Software. G. Myers, Wiley & Sons, New York, USA 1979.
Software para Ordenadores en Sistemas de Seguridad de Plantas de Energía Nuclear. Norma CEI 60880, 1986.
B.9 Análisis del Flujo de Control (Referenciada por D.8)
Objetivo
Detectar estructuras de programa pobres y potencialmente incorrectas.
Descripción
El Análisis de Flujo de Control identifica áreas sospechosas de código que no siguen prácticas de programación buenas.
El programa se analiza para formar un gráfico dirigido que puede analizarse para:
− Código inaccesible, por ejemplo saltos incondicionales que dejan bloques de código sin acceso.
− Código anudado, que es código bien estructurado cuyo gráfico de control es reducible por sucesivas simplificaciones
del mismo a un nodo único. Código pobremente estructurado puede reducirse solamente a un lazo compuesto de varios nodos.
Referencias
RXVP80 - El Sistema de Verificación y Validación para FORTRAN. Manual de Usuario. General Research
Corporation, Santa Barbara, California, USA.
Flujo de Información y Datos de Programas Condicionales. J.F. Bergeretti and B.A. Carre, ACMTrans. on Prog. Lang.
and Syst., 1985.
B.10 Análisis de Fallos de Modo Común (Referenciada por el capítulo 14)
Objetivo
Identificar fallos potenciales en sistemas o subsistemas redundantes, que eliminen las ventajas de la redundancia debido
a la aparición de los mismos fallos en las partes redundantes a la vez.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 65 -
EN 50128:2001
Descripción
Los sistemas basados en ordenadores que controlan la seguridad de una planta utilizan a menudo redundancia en el
hardware y votación mayoritaria. Se usa esta técnica para evitar fallos aleatorios de componentes, que tenderían a impedir el proceso de datos correcto en el sistema de ordenadores.
Sin embargo, algunos fallos pueden ser comunes a más de un componente. Por ejemplo, si un sistema de ordenadores se
instala en una sola habitación, deficiencias en el aire acondicionado pueden reducir las ventajas de la redundancia. Lo
mismo puede decirse para otros efectos externos sobre el sistema de ordenadores, tales como: fuego, inundación, interferencia electromagnética, accidentes de aviación y terremotos. El sistema de ordenadores puede verse afectado también
por incidentes relacionados con la operación y el mantenimiento. Es esencial por tanto que se proporcionen procedimientos de operación y mantenimiento adecuados y bien documentados. Es también esencial un entrenamiento exhaustivo del personal de operación y mantenimiento.
Los efectos internos son también grandes contribuyentes a Fallos de Modo Común (FMC). Ellos pueden deberse a errores de diseño de componentes comunes o idénticos y de sus interfaces, así como a envejecimiento de componentes. El
Análisis de FMC tiene que investigar el sistema en busca de tales fallos comunes potenciales. Los métodos para el
Análisis de FMC son generalmente el control de calidad, las revisiones de diseño, verificación y ensayos por un equipo
independiente y análisis de incidentes reales con la realimentación de la experiencia de sistemas similares. El alcance
del análisis, sin embargo, va más allá del hardware. Incluso si se usa 'diversidad de software' en cadenas complicadas de
un sistema de ordenadores redundante, podría haber algo en común en las distintas aproximaciones software que diera
lugar a un FMC. Por ejemplo, errores en la especificación común.
Cuando los FMCs no ocurren exactamente al mismo tiempo, se deberán tomar precauciones por medio de métodos de
comparación entre las cadenas redundantes que lleven a la detección del fallo antes de que sea común a todas las cadenas. El análisis de FMC debería tener en cuenta esta técnica.
Referencias
Revisión de Fallos de Modo Común. I.A. Watson, UKAEA, Centre for Systems Reliability, Wigshaw Lane, WA3 4NE,
England, NCSR R 27, July 1981.
Fallos de Modo Común en Sistemas Redundantes. I.A. Watson and G.T. Edwards Nuclear Technology Vol. 46, Dec.
1979.
Sistemas Electrónicos Programables en Aplicaciones Relacionadas con la Seguridad. Health and Safety Executive, Her
Majesty's Stationary Office.
B.11 Análisis del Flujo de Datos (Referenciada por D.8)
Objetivo
Detectar estructuras de programa pobres y potencialmente incorrectas.
Descripción
El Análisis de Flujo de Datos combina información obtenida del análisis de flujo de control con información sobre qué
variables son leídas o escritas en diferentes áreas de código. El análisis puede comprobar:
− Variables que se leen antes de haber sido escritas. Esto es muy posiblemente un error, y ciertamente una mala práctica de programación.
− Variables que se escriben más de una vez antes de haber sido leídas. Esto puede indicar código omitido.
− Variables que se escriben pero nunca se leeen. Esto puede indicar código redundante.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 66 -
Hay una extensión del análisis de flujo de datos conocida como análisis de flujo de información, donde el flujo de datos
real (tanto dentro de las subrutinas como entre ellas) se compara con el objetivo del diseño. Esto se implementa normalmente con una herramienta de ordenador, donde se definen los flujos de datos proyectados mediante comentarios
estructurados que se pueden leer por la herramienta.
Referencias
RXVP80 − El Sistema de Verificación y Validación para FORTRAN. Manual de Usuario. General Research
Corporation, Santa Bárbara, California, USA.
Flujo de Información y Control de Programas Condicionales. J.F. Bergeretti and B.A. Carre, ACMTrans. on Prog.
Lang. and Syst., 1985.
B.12 Diagramas de Flujo de Datos (Referenciada por D.5 y D.7)
Objetivo
Describir en forma de diagrama el flujo de datos a través de un programa.
Descripción
Los Diagramas de flujo de Datos documentan cómo los datos de entrada son transformados en salidas, representando
cada etapa del diagrama una transformación distinta.
Los diagramas de flujo de datos incluyen tres componentes
1
Flechas Rotuladas − representan flujo de datos entrando a y saliendo de los centros de transformación, especificando la anotación de qué datos se trata.
2
Burbujas Rotuladas − representan los centros de transformación, especificando la anotación la transformación que
tiene lugar.
3
Operadores (AND, XOR) − Estos operadores se usan para unir las flechas rotuladas.
Los diagramas de flujo de datos describen cómo una entrada es transformada en una salida. No incluyen, ni deberían
hacerlo, información de control o de secuencia. Cada burbuja puede considerarse como una caja negra independiente,
que transforma sus entradas en salidas tan pronto como están disponibles.
Una de las principales ventajas de los diagramas de flujo de datos es que muestran las transformaciones sin hacer ninguna suposición acerca de cómo son implementadas las mismas.
La mejor aproximación para preparar los diagramas de flujo de datos es considerar las entradas del sistema y trabajar
hacia las salidas. Cada burbuja deberá representar una transformación definida − sus salidas deberían ser, en algún modo, diferentes de sus entradas. No hay reglas para determinar la estructura global del diagrama y la construcción de un
diagrama de flujo de datos es uno de los aspectos creativos del diseño del sistema. Como todo diseño, es un proceso
iterativo con intentos previos refinados en etapas posteriores hasta llegar al diagrama final.
Referencia
Ingeniería de software. I. Sommerville, Addison-Wesley 1982. ISBN 0-201-13795-X.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 67 -
EN 50128:2001
B.13 Registro y Análisis de Datos (Referenciada por los capítulos 10 y 16)
Objetivo
Registrar todos los datos, decisiones y razones en el proyecto software para facilitar la verificación, validación, valoración y mantenimiento.
Descripción
Se mantienen registros detallados durante el proyecto, sobre una base tanto general de proyecto como individual. Por
ejemplo, a un ingeniero se le pediría que mantuviese registros que podrían incluir:
− esfuerzo desarrollado en módulos individuales;
− ensayos efectuados en cada módulo;
− decisiones y sus razones;
− consecución de los hitos del proyecto;
− problemas y sus soluciones.
Durante y a la conclusión del proyecto pueden analizarse esos registros para establecer una amplia variedad de inform ación. En particular, el registro de datos es muy importante en el mantenimiento de sistemas basados en ordenador, ya
que las razones de ciertas decisiones tomadas durante el desarrollo del proyecto no son siempre conocidas por los ingenieros de mantenimiento.
B.14 Tablas de Decisión (Tablas de Verdad) (Referenciada por el capítulo 14 y D.7)
Objetivo
Proporcionar una especificación clara y coherente y un análisis de combinaciones lógicas complejas y de sus relaciones.
Descripción
Estos métodos relacionados usan tablas bidimensionales para describir concisamente las relaciones lógicas entre variables de programa Booleanas.
La concisión y naturaleza tabular de ambos métodos los hace apropiados como un medio de analizar combinaciones
lógicas complejas expresadas en forma de código.
Ambos métodos son potencialmente ejecutables si se usan como especificaciones.
B.15 Programación Defensiva (Referenciada por el capítulo 9)
Objetivo
Generar programas que detecten un flujo de control, un flujo de datos o valores de los mismos anómalo y que reaccionen a ello de forma predeterminada y aceptable.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 68 -
Descripción
Se pueden utilizar muchas técnicas durante la programación para comprobar anomalías en el control o en los datos.
Dichas técnicas se pueden aplicar sistemáticamente a lo largo de la programación de un sistema para disminuir la probabilidad de un proceso de datos erróneo.
Se pueden identificar dos áreas de técnicas defensivas que se solapan. Se diseña software intrínsecamente seguro frente
a errores a fin de acomodar sus propias deficiencias de diseño. Estas deficiencias pueden deberse a errores claros de
diseño o de codificación, o a requisitos erróneos. La siguiente lista indica algunas de las técnicas defensivas:
− comprobar el rango de las variables;
− siempre que sea posible, comprobar la plausibilidad de los valores;
− comprobar el tipo, dimensión y rango de los parámetros de las subrutinas a la entrada de las mismas.
Estas tres primeras recomendaciones ayudan a asegurar que los números que manipula el programa son razonables,
tanto en términos de la función del programa como del significado físico de las variables.
− Los parámetros de sólo lectura y sólo escritura deberían estar separados y sus accesos comprobados. Las funciones
deberían tratar todos los parámetros como de sólo lectura. Las constantes literales no deberían ser accesibles para
escritura. Esto ayuda a detectar sobrescrituras accidentales o uso erróneo de variables.
El software tolerante a errores está diseñado para 'esperar' fallos en su propio entorno o fuera de su uso nominal o de
condiciones esperadas, y comportarse de una forma predeterminada. Las técnicas incluyen lo siguiente:
− se debería comprobar la plausibilidad de las variables de entrada y variables intermedias con significado físico;
− se debería comprobar el efecto de las variables de salida, preferiblemente por observación directa de cambios asociados de estado del sistema;
− el software debería comprobar su configuración. Ello incluye tanto la existencia y accesibilidad del hardware esperado como que el propio software está completo. Esto es particularmente importante para conservar la integridad
después de los procedimientos de mantenimiento.
Algunas de las técnicas de programación defensiva como la comprobación de la secuencia del flujo de control, también
se enfrentan a problemas de fallos externos.
Referencias
Confiabilidad de Sistemas Críticos basados en Ordenador. Parte 1. E.F. Redmill (ed) Elsevier Applied Science 1988.
Confiabilidad de Sistemas Críticos basados en Ordenador. Parte 2. E.F. Redmill (ed) Elsevier Applied Science 1988.
Aspectos de Ingeniería Software sobre Conceptos de Programación en Tiempo Real. E. Schoitsch, Computer Physics
Communications 41 (1986) North Holland, Amsterdam.
B.16 Normas de Diseño y Codificación (Referenciada por D.1)
Objetivo
Asegurar una estructura uniforme de documentos de diseño y del código producido, imponer una programación sin ego
y un método de diseño normalizado.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 69 -
EN 50128:2001
Descripción
Las reglas a seguir son aceptadas al comienzo del proyecto por los participantes. Estas reglas deben comprender como
mínimo
− el método de desarrollo y las normas de codificación asociadas a seguir, por ejemplo JSP, MASCOT, Redes de
Petri, etc.;
− detalles de modularización, por ejemplo, formas de interface, tamaños de módulo;
− uso de encapsulado, herencia y polimorfismo, en caso de lenguajes orientados a objetos;
− uso o el evitar ciertas construcciones del lenguaje, por ejemplo, GOTO, EQUIVALENCE, objetos dinámicos, datos
dinámicos, recursividad, punteros, salidas, etc.; y
− el qué, dónde y cómo comentar.
Estas reglas se establecen para facilitar el desarrollo, verificación, valoración y mantenimiento. Por tanto, deberán considerar las herramientas disponibles, en particular analizadores y herramientas de ingeniería inversa.
B.17 Programación con Diversidad (Referenciada por el capítulo 9)
Objetivo
Detectar y enmascarar fallos de diseño software residuales durante la ejecución de un programa a fin de evitar fallos
críticos de seguridad del sistema y continuar la operación con alta fiabilidad.
Descripción
En la programación con diversidad, se implementa una especificación de programa determinada N veces en forma diferente. Se proporcionan los mismos valores de entrada a las N versiones y los resultados producidos por las mismas son
comparados. Si el resultado se considera válido, se transmite a las salidas del ordenador.
Las N versiones pueden correr en paralelo en ordenadores separados o alternativamente, correr todas en el mismo ordenador y someter los resultados a una votación interna. Dependiendo de los requisitos de la aplicación pueden utilizarse
diferentes estrategias de voto para las N versiones:
− Si el sistema tiene un estado seguro, es factible exigir un acuerdo completo (existe consenso entre las N) y en caso
contrario usar un valor de salida seguro. Para sistemas en los que existe una reacción segura única, el voto puede
polarizarse en esa dirección. En este caso, se tomaría la acción segura si cualquiera de las versiones lo demandase.
Esta aproximación usa típicamente sólo dos versiones (N = 2).
− Para sistemas sin estado seguro, pueden emplearse estrategias de votación mayoritaria. En los casos donde no hay
acuerdo colectivo, pueden emplearse aproximaciones probabilisticas a fin de maximizar la probabilidad de seleccionar el valor correcto, tomando por ejemplo el valor medio, congelando temporalmente las salidas hasta que se alca nce de nuevo el acuerdo, etc.
Esta técnica no elimina defectos de diseño software residuales, pero proporciona un medio para detectarlos y enmascararlos antes de que puedan afectar a la seguridad.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 70 -
Referencias
Procesamiento Confiable: De los Conceptos a la Diversidad del Diseño A. Avizienis, J.C. Laprie, Proc IEEE, Vol 74, 5,
May 1986.
Una Base Teórica para el Análisis de Software multi-versión sujeto a Fallos Coincidentes. D.E. Eckhardt and L.D. Lee,
IEEE Trans. SE-11, No 12, 1985.
B.18 Reconfiguración Dinámica (Referenciada por el capítulo 9)
Objetivo
Mantener la funcionalidad del sistema a pesar de un defecto interno.
Descripción
La arquitectura lógica del sistema deberá ser tal que pueda ser ubicada en un subconjunto de los recursos disponibles
del sistema. Es necesario que la arquitectura sea capaz de detectar un fallo en un recurso físico y reconfigurar entonces
la arquitectura lógica sobre los recursos limitados que quedan en funcionamiento. Aunque el concepto está tradicionalmente más restringido a la recuperación en caso de unidades hardware averiadas, es también aplicable a fallo en unidades software si hay suficiente redundancia en tiempo de ejecución para permitir un reintento software o si hay suficiente
redundancia de datos para permitir que el fallo individual y aislado tenga poca importancia.
Aunque aplicada tradicionalmente al hardware, esta técnica está siendo desarrollada para su aplicación al software, y
por tanto al sistema completo. Debe considerarse en la primera etapa de diseño del sistema.
Referencias
Cuestiones Criticas en el Diseño de un Ordenador de Control Reconfigurable. H. Schmid, J. Lam, R. Naro and K. Weir,
FTCS 14 June 1984 IEEE 1984.
Asignación de Procesos a los Procesadores: Una Aproximación tolerante a Fallos. June 1984 G. Kar and C.N.Nikolaou,
Watson Research Centre, Yorktown.
B.19 Clases de Equivalencia y Ensayos de Partición de Entrada (Referenciada por D.2 y D.3)
Objetivo
Ensayar el software adecuadamente utilizando un mínimo de datos de ensayo. Los datos de ensayo se obtienen seleccionando las particiones del dominio de entrada necesarias para ejercitar el software.
Descripción
Esta estrategia de ensayos se basa en la relación de equivalencia de las entradas, la cual determina una partición del
dominio de entrada.
Los casos de ensayo se seleccionan con el objetivo de cubrir todos los subconjuntos de esta partición. Al menos se toma
un caso de ensayo para cada clase de equivalencia.
Hay dos posibilidades básicas para la partición de las entradas, que son:
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 71 -
EN 50128:2001
− las clases de equivalencia se pueden definir en la especificación. La interpretación de la especificación puede estar
orientada hacia la entrada, por ejemplo, los valores seleccionados se tratan de la misma manera, o hacia la salida,
por ejemplo, conjuntos de valores que dan lugar al mismo resultado funcional; y
− las clases de equivalencia pueden estar definidas en la estructura interna del programa. En este caso, los resultados
de la clase de equivalencia se determinan del análisis estático del programa, por ejemplo, el conjunto de valores que
dan lugar a la ejecución del mismo camino.
Referencia
El Arte de Ensayar Software. G. Myers, Wiley & Sons, New York, USA, 1979.
B.20 Códigos de Detección y Corrección de Errores (Referenciada por el capítulo 9)
Objetivo
Detectar y corregir errores en información sensible.
Descripción
Para una información de n bits, se genera un bloque codificado de k bits que permite detectar y corregir errores. Entre
los diferentes tipos de código se incluyen:
− códigos de Hamming;
− códigos cíclicos;
− códigos polinomiales.
Referencias
La Tecnología de los Códigos de Corrección de Errores. E.R. Berlekamp, Proc. of the IEEE, 68, 5, 1980.
Un Curso Breve sobre Códigos de Corrección de Errores. N.J.A. Sloane, Springer-Verlag, Wien, 1975.
B.21 Intuición de Errores (Referenciada por D.2 y D.8)
Objetivo
Eliminar errores de programación corrientes.
Descripción
La experiencia en ensayos y la intuición, combinadas con el conocimiento y la curiosidad sobre el sistema bajo ensayo,
pueden añadir algunos casos de ensayo no catalogados al conjunto de casos de ensayo diseñados. Valores especiales o
combinaciones de valores que pueden ser propensos al error. Pueden derivarse casos de ensayo interesantes de la inspección de las listas de comprobación. Puede considerarse también si el sistema es suficientemente robusto. ¿Pueden
pulsarse las teclas del panel frontal demasiado rápido o muy frecuentemente? ¿Qué ocurre si se pulsan dos teclas simultáneamente?
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 72 -
B.22 Introducción de Errores (Referenciada por D.2)
Objetivo
Determinar si un conjunto de casos de ensayo es adecuado.
Descripción
Se insertan en el programa algunos tipos de error conocidos, y se ejecuta el programa con los casos de ensayo bajo las
condiciones de ensayo. Si solamente se encuentran algunos de los errores introducidos, el conjunto de casos de ensayo
no es adecuado. La relación entre el número de errores introducidos encontrados sobre el total de errores introducidos es
una estimación al número de errores reales encontrados sobre el número total de errores reales. Ello da la posibilidad de
estimar el número de errores remanentes y por tanto el esfuerzo de ensayo que resta.
Errorres introducidos hallados Errores reales hallados
=
Total errores introducidos
Total errores reales
La detección de todos los errores introducidos puede indicar que el conjunto de casos de ensayo es adecuado o que los
errores introducidos eran demasiado fáciles de encontrar. Las limitaciones del método son que, a fin de obtener resultados utilizables, los tipos de error así como las posiciones donde se introducen deberán reflejar la distribución estadística
de los errores reales.
B.23 Análisis mediante Árbol de Eventos (Referenciada por el capítulo 14)
Objetivo
Modelar, en forma de diagrama, la secuencia de eventos que pueden desencadenarse en un sistema después de un
evento inicial y como resultado indicar qué consecuencias serias pueden ocurrir.
Descripción
En la parte superior del diagrama se escribe la secuencia de condiciones que son relevantes en el desencadenamiento
que sigue al evento inicial, que es el objetivo del análisis. Comenzando en el evento inicial, se dibuja una línea a la
primera condición en la secuencia. Ahí el diagrama se bifurca en una rama 'sí' y otra 'no', describiendo como depende la
trayectoria futura de la condición. Para cada una de las ramas se continúa hacia la siguiente condición de forma similar.
No todas las condiciones son relevantes para todas las ramas. Siguiendo hasta el fin de la secuencia, cada rama del árbol
así construido representa una posible consecuencia. El árbol de eventos puede utilizarse para calcular la probabilidad de
las diversas consecuencias en función de la probabilidad y número de condiciones en la secuencia.
Referencia
Árboles de Eventos y su Tratamiento en Ordenadores Personales. N. Limnious and J.P. Jeannette, Reliability
Engineering, Vol. 18, No. 3 1987.
B.24 Inspecciones de Fagan (Referenciada por D.8)
Objetivo
Descubrir errores en todas las fases de desarrollo del programa.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 73 -
EN 50128:2001
Descripción
Se trata de una auditoría 'formal' sobre los documentos de aseguramiento de la calidad con objeto de encontrar errores y
omisiones. El proceso de inspección consta de cinco fases: Planificación, Preparación, Inspección, Re-elaboración y
Seguimiento. Cada una de estas fases tiene su objetivo específico. Debe inspeccionarse el desarrollo del sistema completo (especificación, diseño, codificación y ensayos).
Referencia
Inspecciones del Diseño y Codificación para Reducir Errores en el Desarrollo de Programas. M.E. Fagan, IBM Systems
Journal, No. 3, 1976.
B.25 Programación con Detección de Fallos (Referenciada por el capítulo 9)
Objetivo
Detectar errores residuales de diseño software durante la ejecución de un programa, a fin de evitar fallos críticos de
seguridad del sistema y continuar el funcionamiento con alta fiabilidad.
Descripción
El método de programación con detección sigue la idea de comprobar una pre-condición (antes de ejecutar una secuencia de sentencias se comensayo la validez de las condiciones iniciales) y una pos-condición (se comensayon los resultados después de ejecutar una secuencia de sentencias). Si no se cumple la pre-condición o la pos-condición, el procesamiento se interrumpe con un error.
Por ejemplo,
imponer <pre-condición>;
acción 1;
:
:
acción x;
imponer <pos-condición>;
Referencias
Una Disciplina de Programación. E.W. Dijkstra, Prentice Hall, 1976.
La Ciencia de la Programación. D. Gries, Springer-Verlag, 1981.
Desarrollo de Software - Una Aproximación Rigurosa. C.B. Jones, Prentice-Hall, 1980.
B.26 AEES - Análisis de Efectos de Errores Software (Referenciada por los capítulos 9, 11 y 14)
Objetivo
Identificar módulos software y su grado de criticidad; proponer medios para detectar errores software y mejorar su
robustez; evaluar el grado de validación necesario para cada uno de los componentes software.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 74 -
Descripción
El análisis se efectúa en tres fases:
− Identificación de módulos software vitales
Determinación de la profundidad del análisis (a nivel de línea de instrucción, grupo de instrucciones, módulo, etc.)
necesario para cada módulo software en base a su especificación.
− Análisis de errores software
El resultado de esta fase es una tabla con la siguiente información:
− nombre del módulo;
− error considerado;
− consecuencias del error a nivel del módulo;
− consecuencias a nivel del sistema;
− criterio de seguridad violado;
− criticidad del error;
− medios propuestos de detección del error;
− criterio violado si se implementa el mecanismo de detección;
− criticidad residual si se implementa el mecanismo de detección.
− Síntesis
La síntesis identifica los escenarios inseguros restantes y el esfuerzo de validación necesario dada la criticidad de
cada módulo.
El AEES, al ser un análisis en profundidad llevado a cabo por un equipo independiente, en un potente método para
descubrir errores.
Referencias
Equipamiento ferroviario fijo y en locomotoras. Proceso de datos. Confiabilidad del software. Métodos adaptados para
el análisis de seguridad del software, Norma Francesa NF F 71-013, December 1990.
Informe No. 1 del Comité Técnico Internacional del IRSE.
*VALIDACIÓN DE SISTEMAS DE SEGURIDAD con respecto a la aceptación mutua de sistemas de señalización por
los ferrocarriles*.
P. THIREAU.
*Metodología de Análisis de los Efectos de Errores Lógicos (AEEL) aplicada al estudio de un software de alta seguridad*.
5ª Conferencia Internacional sobre Fiabilidad y Mantenibilidad.
Biarritz - France - 1986.
D. J. REIFER.
*Modos de fallo del software y análisis de sus consecuencias*.
Transaction on reliability IEE - Vol. R28 No. 3.
August 79 - Páginas 247/249.
J. R. FRAGOLA and J. F. SPAMM.
*El análisis de las consecuencias de errores software, una herramienta de diseño cualitativa*.
IEEE Symposium Computer on Software Reliability.
1973 - Páginas 90/93.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 75 -
EN 50128:2001
B.27 Diagnosis y Detección de Defectos (Referenciada por el capítulo 9)
Objetivo
Detectar defectos en un sistema que pueden dar lugar a un fallo, proporcionando así las contramedidas que minimicen
las consecuencias de los fallos.
Descripción
La detección de defectos es el proceso de comprobación de un sistema para detectar estados erróneos (que están causados, como se ha explicado anteriormente, por un defecto dentro del (sub)sistema bajo comprobación). El objetivo principal de la detección de defectos es inhibir el efecto o los resultados erróneos. Un sistema que proporciona resultados
correctos o bien ningún resultado se dice que tiene "autocomprobación".
La detección de defectos se basa en los principios de redundancia (principalmente para detectar defectos hardware) y
diversidad (defectos software). Es necesario algún tipo de votación para decidir qué resultados son los correctos. Métodos especiales aplicables son las técnicas de programación con detección, la programación de N versiones y la bolsa de
seguridad, y para el nivel hardware la introducción de sensores, lazos de control, códigos de comprobación de errores,
etc.
La detección de defectos puede conseguirse mediante comprobaciones en el dominio de valores o del tiempo a varios
niveles, especialmente en el nivel físico (temperatura, voltaje, etc.), lógico (códigos de detección de error), funcional
(verificaciones) o externo (comprobaciones de plausibilidad). Los resultados de estas comprobaciones pueden almacenarse y asociarse con los datos afectados para permitir el seguimiento del fallo.
Los sistemas complejos están formados por subsistemas. La eficacia de la detección de defectos, diagnosis y compensación, depende de la complejidad de las interacciones entre los subsistemas, que afecta a la propagación de defectos.
La diagnosis de defectos aisla el subsistema más pequeño que puede ser identificado. Los subsistemas más pequeños
permiten una diagnosis más detallada de los defectos (identificación de estados erróneos).
B.28 Análisis mediante Arbol de Fallos (Referenciada por los capítulos 9 y 14)
Objetivo
Ayudar en el análisis de eventos, o combinaciones de los mismos, que darán lugar a una amenaza o consecuencia seria.
Descripción
Comenzando con un evento que sería la causa inmediata de una amenaza o consecuencia seria (el 'evento superior') se
lleva a cabo el análisis a lo largo de caminos de un árbol. Se describen combinaciones de causas con operadores lógicos
(and, or, etc.). Las causas intermedias se analizan de la misma forma, y así sucesivamente hasta retroceder a los eventos
básicos donde finaliza el análisis.
El método es gráfico, y se usan un conjunto de símbolos estandarizados para dibujar un árbol de fallos. Está dirigido
principalmente al análisis de sistemas hardware, pero ha habido intentos para aplicar esta aproximación al análisis de
fallos software.
Referencias
Metodología de Ingeniería de Fiabilidad de Sistemas: Una Discusión sobre el Estado del Arte. J.B. Fusseland J.S.
Arend, Nuclear Safety 20(5), 1979.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 76 -
Manual de Arbol de Fallos. W.E. Vesely et. al., NUREG-0942, Division of System Safety Office of Nuclear Reactor
Regulation, U.S. Nuclear Regulatory Commission Washington, D.C.20555, 1981.
Tecnología de la Fiabilidad. A.E. Greene and A.J. Bourne, Wiley-Interscience, 1972.
B.29 Máquinas de Estados Finitos/Diagramas de Transición de Estados (Referenciada por D.5 y D.7)
Objetivo
Definir o implementar la estructura de control de un sistema.
Descripción
Muchos sistemas pueden definirse en términos de sus estados, sus entradas y sus acciones. Así, cuando un sistema está
en el estado S1 y recibe una entrada I, puede llevar a cabo una acción A o cambiar al estado S2. Definiendo las acciones
de un sistema para cada entrada en cada estado se puede definir completamente el sistema. El modelo resultante del
sistema se conoce como Máquina de Estados Finitos (MEF). Se dibuja a menudo como un diagrama de transición que
muestra como se mueve el sistema de un estado a otro, o como una matriz cuyas dimensiones son estados y entradas y
las células de la matriz contienen la acción y el nuevo estado resultante al recibir una entrada en el estado actual.
Cuando el sistema es complicado o tiene una estructura natural, puede reflejarse en una MEF de varias capas.
Una especificación o diseño expresado como una MEF puede comprobarse que es completo (el sistema deberá tener
una acción y un nuevo estado para cada entrada en cada estado), consistente (solamente se define un cambio de estado
para cada pareja estado/entrada) y accesible (si es posible o no pasar de un estado a otro mediante una secuencia de
entradas). Estas son propiedades importantes para sistemas críticos y pueden ser comprobadas. Pueden escribirse fácilmente herramientas que soporten dichas comprobaciones. Existen también algoritmos que permiten la generación automática de casos de ensayo para verificar la implementación de una MEF o para la animación de un modelo de MEF.
Referencia
Introducción a la teoría de las Máquinas de Estados Finitos. A. Gill, McGraw-Hill 1962.
B.30 Métodos Formales (Referenciada por el capítulo 8, capítulo 10 y D.5)
Objetivo
Desarrollar software con una metodología basada en las matemáticas. Ello incluye técnicas de diseño y codificación
formales.
Descripción
Los métodos formales proporcionan un medio de desarrollar una descripción del sistema en alguna etapa del desarrollo
de su especificación, diseño o codificación. La descripción resultante tiene una forma matemática y puede someterse al
análisis matemático para detectar varias clases de inconsistencia o falta de corrección. Además, en algunos casos la
descripción se puede analizar mediante máquina con un rigor similar a la comprobación de la sintaxis de un programa
fuente por el compilador, o animada para presentar varios aspectos del comportamiento del sistema descrito. La animación puede proporcionar una confianza extra de que el sistema satisface los requisitos reales así como los especificados
formalmente.
Un método formal ofrecerá normalmente una notación (generalmente alguna forma de la matemática discreta utilizada),
una técnica para derivar una descripción en esa notación, y varias formas de análisis para comprobar que una descripción es correcta en sus diferentes propiedades.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 77 -
EN 50128:2001
Varios Métodos Formales se describen en las subsecciones siguientes de esta bibliografía. Estos Métodos Formales son
CCS, CSP, HOL, LOTOS, OBJ, Lógica Temporal, VDM y Z.
B.30.1 CCS − Cálculo de Sistemas de Comunicación
Objetivo
CCS es un medio para describir y razonar acerca del comportamiento de sistemas de procesos concurrentes que se comunican entre sí.
Descripción
Similar a CSP, CCS es un cálculo matemático relacionado con el comportamiento de sistemas. El diseño del sistema se
modela como una red de procesos independientes trabajando secuencialmente o en paralelo. Los procesos pueden comunicarse a través de puertos (similares a los canales de CSP), teniendo lugar la comunicación solamente cuando ambos procesos están preparados. Puede modelarse el comportamiento no determinista. Comenzando con una descripción
abstracta de alto nivel del sistema completo (conocida como traza), es posible llevar a cabo un refinamiento paso a paso
del sistema en forma de un conjunto de procesos que se comunican cuyo comportamiento global es el requerido para el
sistema. Es posible igualmente trabajar de abajo hacia arriba, combinando procesos y deduciendo las propiedades del
sistema resultante, usando reglas de deducción relacionadas con las reglas de composición.
Referencias
Un Cálculo de Sistemas de Comunicación. R Milner, Report number ECS-LFCS-86-7, Laboratory for Foundations of
Computer Science, Department of Computer Science, University of Edinburgh, UK.
La Especificación de Sistemas Complejos. B Cohen, W T Harwood, M I Jackson. Addison-Wesley, 1986.
B.30.2 CSP − Comunicación entre Procesos Secuenciales
Objetivo
CSP es una técnica para la especificación de sistemas de software concurrente, es decir, sistemas de procesos que trabajan concurrentemente y se comunican entre sí.
Descripción
CSP proporciona un lenguaje para la especificación de sistemas de procesos y el ensayo para verificar que la implementación de procesos satisface sus especificaciones (descrita como traza - secuencias de eventos permisibles).
Un sistema se modela como una red de procesos independientes. Cada proceso se describe en términos de sus posibles
comportamientos. Un sistema se modela componiendo procesos secuencialmente o en paralelo. Los procesos pueden
comunicarse (sincronizarse o intercambiar datos) a través de canales, teniendo lugar la comunicación solamente cuando
ambos procesos están preparados. Puede modelarse la temporización relativa de eventos.
La teoría que soporta CSP fue incorporada directamente en el transputer de INMOS, y el lenguaje OCCAM permite que
un sistema especificado mediante CSP se implemente directamente sobre una red de transputers.
Referencia
Comunicación entre Procesos Secuenciales. C A R Hoare, Prentice-Hall, 1985.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 78 -
B.30.3 HOL − Lógica de Orden Superior
Objetivo
Se trata de un lenguaje formal diseñado como base para la especificación y verificación del hardware.
Descripción
HOL (Lógica de Alto Nivel) se refiere a una notación lógica particular y su sistema de soporte máquina, desarrollados
ambos en el Laboratorio de Ordenadores de la Universidad de Cambridge. La notación lógica está tomada en su mayoría de la Teoría Simple de Tipos de Church y el sistema de soporte máquina está basado en el sistema LCF (Lógica de
Funciones Calculables).
Referencia
HOL : Una Máquina Orientada a la Formulación de Lógica de Alto Nivel. M. Gordon, University of Cambridge
Technical Report, Number - 68.
B.30.4 LOTOS
Objetivo
LOTOS es un medio para describir y razonar acerca del comportamiento de sistemas de procesos concurrentes que se
comunican entre sí.
Descripción
LOTOS (Lenguaje para la Especificación de Orden Temporal) está basado en CCS con características adicionales relacionadas con las álgebras de CSP y CIRCAL (Cálculo de Circuitos). Supera la debilidad de CCS en el manejo de estructuras de datos y expresiones con valores mediante la combinación con un segundo componente basado en el lenguaje de tipos de datos abstractos ACT ONE. La componente de definición de procesos de LOTOS puede utilizarse sin
embargo con otros formalismos para la descripción de tipos de datos abstractos.
Referencia
Sistemas de Proceso de Información - Interconexión de Sistemas Abiertos - LOTOS - Una Técnica de Descripción
Formal basada en el Orden Temporal del Comportamiento Observable. ISO DIS 8807, July 20, 1987.
B.30.5 OBJ
Objetivo
Proporcionar una especificación precisa del sistema con realimentación al usuario y validación del mismo antes de la
implementación.
Descripción
OBJ es un lenguaje de especificación algebraico. Los usuarios especifican los requisitos en términos de ecuaciones
algebraicas. Los aspectos de comportamiento del sistema, o aspectos constructivos, se especifican en términos de operaciones que actúan sobre tipos de datos abstractos (TDA). Un TDA es similar a un paquete ADA, donde el comportamiento del operador es visible, mientras que los detalles de implementación quedan 'ocultos'.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 79 -
EN 50128:2001
Una especificación OBJ, y la consiguiente implementación paso a paso, puede someterse a las mismas técnicas de ensayo formal que otras aproximaciones formales. Además, como los aspectos constructivos de la especificación OBJ son
ejecutables sobre máquina, es sencillo conseguir la validación del sistema a partir de la propia especificación. La ejecución es esencialmente la evaluación de una función mediante sustitución en la ecuación (re-escritura) que continúa hasta
que se obtiene el valor de salida específico. La ejecutabilidad permite a los usuarios finales del sistema en ciernes obtener una 'visión' del sistema final en la etapa de especificación del mismo sin la necesidad de tener familiaridad con las
técnicas de especificación formal subyacentes.
Como con otras técnicas TDA, OBJ se aplica solamente a sistemas secuenciales, o aspectos secuenciales de sistemas
concurrentes. OBJ se ha usado ampliamente para la especificación de aplicaciones industriales tanto de pequeña como
de gran escala.
Referencias
Una introducción a OBJ: Un lenguaje para la Escritura y Ensayo de Especificaciones. J A Goguen and J Tardo,
Specification of Reliable Software, IEEE Press 1979, reprinted in Software Specification Techniques, N Gehani, A
McGettrick (eds), Addison-Wesley, 1985.
Especificación Algebraica para la Producción de Software Práctico. C Rattray, Cogan Press, 1987.
Una Aproximación Algebraica a la Estandarización y Certificación de Software Gráfico. R Gnatz, Computer Graphics
Forum 2(2/3), 1983.
Guía DTI STARTS. 1987, NCC, Oxford Road, Manchester, UK.
B.30.6 Lógica Temporal
Objetivo
Expresión directa de los requisitos de seguridad y funcionales y demostración formal de que dichas propiedades se
mantienen en las etapas de desarrollo siguientes.
Descripción
La Lógica de Predicados de Primer Orden estándar no incluye el concepto del tiempo. La lógica temporal amplía la
lógica de Primer Orden añadiendo operadores modales (por ejemplo, 'De ahora en adelante' y 'Finalmente'). Estos operadores pueden utilizarse para cualificar aseveraciones sobre el sistema. Por ejemplo, puede requerirse que las propiedades de seguridad se mantengan 'de ahora en adelante', mientras que otros estados deseados del sistema sea necesario
que se alcancen 'finalmente' desde algún otro estado inicial. Las fórmulas temporales se interpretan como secuencias de
estados (comportamientos). Lo que constituye un 'estado' depende del nivel de descripción elegido. Puede referirse al
sistema completo, a un componente del sistema o al programa del ordenador. Intervalos de tiempo cuantificados y limitaciones no son manejados explícitamente por la lógica temporal. Una temporización absoluta tiene que manejarse
creando estados de tiempo adicionales como parte de la definición de estados.
Referencias
Programas de Lógica Temporal. F Kroger EATCS Monographs on Computer Science, Vol 8,Springer Verlag, 1987.
Diseño de Seguridad usando Lógica Temporal. J Gorski. SAFECOMP 86, Sarlat France, Pergamon Press, October
1986.
Lógica para la Programación de Ordenadores. D Gabay. Ellis Horwood.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 80 -
B.30.7 VDM − Método de Desarrollo de Viena
Objetivo
La especificación sistemática e implementación de programas secuenciales.
Descripción
VDM es una técnica de especificación basada en la matemática y una técnica para el refinamiento de las implementaciones de forma que permite ensayar que son correctas con respecto a la especificación.
La técnica de especificación se basa en un modelo en el cual se representa el estado del sistema en términos de estructuras teóricas establecidas sobre las que se definen invariantes (predicados), y las operaciones en ese estado se modelan
especificando sus pre y pos-condiciones en términos del estado del sistema. Puede demostrarse que las operaciones
preservan los invariantes del sistema.
La implementación de la especificación se efectúa mediante la materialización del estado del sistema en términos de
estructuras de datos en el lenguaje empleado y el refinamiento de las operaciones en términos de un programa en dicho
lenguaje. Los pasos de materialización y refinamiento dan lugar a compromisos de ensayo para establecer que son correctos. El llevar a cabo o no dichos compromisos es una decisión que toma el diseñador.
VDM se utiliza principalmente en la etapa de especificación, pero puede usarse en las de diseño e implementación que
dan lugar al código fuente. Solamente se puede aplicar a programas secuenciales o procesos secuenciales en sistemas
concurrentes.
Referencias
Desarrollo Software - Una Aproximación Rigurosa. C B Jones. Prentice-Hall, 1980.
Especificación Formal y Desarrollo Software. D Bjorner & C B Jones. Prentice-Hall, 1982.
Desarrollo Software Sistemático usando VDM. C B Jones. Prentice-Hall, 1986.
La Especificación de Sistemas Complejos. B Cohen, W T Harwood and M I Jackson. Addison-Wesley, 1986.
B.30.8 Z y B
Objetivo
Z es una notación de lenguaje de especificación para sistemas secuenciales y una técnica de diseño que permite a quien
trabaja en el desarrollo llegar, a partir de una especificación Z, a algoritmos ejecutables de forma que se puede ensayar
que son correctos con respecto a la especificación.
Z se usa principalmente en la etapa de especificación pero se ha ideado un método para ir desde la especificación al
diseño e implementación. Es especialmente adecuada para desarrollo de sistemas secuenciales orientados a datos.
B es un método asociado.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 81 -
EN 50128:2001
Descripción
Como VDM, la técnica de especificación se basa en un modelo en el cual se representa el estado del sistema en términos de estructuras teóricas establecidas sobre las que se definen invariantes (predicados), y las operaciones en ese estado se modelan especificando sus pre y pos-condiciones en términos del estado del sistema. Puede probarse que las operaciones preservan los invariantes del sistema demostrando así su consistencia. La parte formal de la especificación se
divide en esquemas que permiten el estructurado de especificaciones y su refinamiento.
Típicamente, una especificación Z es una mezcla de Z formal y texto explicativo en lenguaje natural. (El texto propiamente formal puede ser demasiado conciso para una lectura fácil y a menudo necesita explicarse su propósito, mientras
que el lenguaje natural informal puede fácilmente llegar a ser vago e impreciso).
A diferencia de VDM, Z es una notación más que un método completo. Sin embargo, se ha desarrollado un método
asociado (llamado B) que puede utilizarse en conjunción con Z. El método B se basa principalmente en el refinamiento
paso a paso.
Referencias
La notación Z. Un Manual de Referencia. J M Spivey, Prentice Hall, 1988.
Estudio de Casos de Especificación. Edited by I Hayes, Prentice-Hall, 1987.
Especificación del Almacenamiento de Ficheros en UNIX. C Morgan and B Sufrin. IEEE Transactions on Software
Engineering, SE-10, 2 March 1984.
El Libro de B. Asignación de Programas a Significados. J R Abrial, Cambridge United Press, 1996.
B.31 Ensayo Formal (Referenciada por el capítulo 11)
Objetivo
Utilizando modelos y reglas teóricas y matemáticas es posible ensayar que un programa es correcto sin ejecutarlo.
Descripción
Se establecen un número de declaraciones en varios puntos del programa y se usan como pre y pos-condiciones para los
diversos caminos dentro del mismo. El ensayo consiste en demostrar que el programa transfiere las pre-condiciones a
las pos-condiciones de acuerdo a un conjunto de reglas lógicas establecidas y que el programa termina.
Se describen varios métodos formales en esta bibliografía, por ejemplo, CCS, CSP, HOL, LOTOS, Lógica Temporal,
VDM y Z. Las descripciones de los mismos pueden encontrarse en la sección de 'Métodos Formales'.
Referencia
¿Pueden Comprobarse los Programas de Forma Práctica?. J. Dahl, Research Report, ISBN 82-90230-26-5 No33, Oslo,
May
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 82 -
B.32 Recuperación Adelantada (Referenciada por el capítulo 9)
Objetivo
Proporcionar operación funcional correcta en presencia de uno o varios defectos.
Descripción
Si se ha detectado un fallo, el estado actual del sistema es manipulado para obtener un estado que deberá ser consistente
posteriormente. Este concepto es especialmente adecuado para sistemas de tiempo real con una base de datos pequeña y
un cambio rápido del estado interno. Se supone que, al menos parte del estado del sistema puede ser impuesta al entorno, y solamente parte de los estados del sistema son influenciados (forzados) por el entorno.
B.33 Degradación Parcial
Objetivo
Mantener disponibles las funciones más críticas del sistema a pesar de los fallos, abandonando las funciones que lo son
menos.
Descripción
Esta técnica da prioridad a varias de las funciones que lleva a cabo el sistema. El diseño asegura entonces que en caso
de que haya recursos insuficientes para mantener todas las funciones del sistema, las de más alta prioridad se llevan a
cabo con preferencia sobre las de menor prioridad. Por ejemplo, el registro de errores y eventos pueden ser funciones
con menor prioridad que las de control del sistema. El control del sistema continuaría si el hardware asociado con el
registro de errores fallara. Incluso si el hardware del sistema de control fallase pero no el del registro de errores, entonces este último asumiría la función de control. Lo dicho se aplica predominantemente al hardware, pero se aplica al
sistema total. Debe considerarse en la fase más superior del diseño.
Referencias
Software de la Lanzadera Espacial. C.T. Sheridan, Datamation, Vol 24, July 1978.
La Evolución del Procesamiento Tolerante a Fallos. Vol 1 of Dependable Computing and Fault Tolerant Systems,
Edited by A. Avizienis, H. Kopetz, and J.C. Laprie, Springer-Verlag, ISBN 3-211-81941-X, 1987.
Tolerancia a Fallos, Principios y Prácticas. Vol 3 of [2] above, T. Anderson and P.A. Lee, Springer-Verlag,
ISBN 3-211-82077-9, 1987.
B.34 Estudio de Amenazas y Operatividad (HAZOP)
Objetivo
Establecer, mediante una serie de exámenes sistemáticos de las secciones componentes de un sistema basado en ordenador, modos de fallo que den lugar a situaciones potencialmente peligrosas en el sistema controlado.
Eventos peligrosos típicos en el sistema controlado son fuego, explosión, emisión de material tóxico (químico o nuclear) o pérdidas económicas serias.
Se supone que los eventos peligrosos en el sistema que se está controlando han sido identificados en un Análisis de
Amenazas separado y las consecuencias de los eventos peligrosos se han clasificado por su grado de seriedad.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 83 -
EN 50128:2001
El análisis cubre todas las etapas del ciclo de vida del proyecto, desde la especificación al diseño, mantenimiento y
modificación, y se pretende identificar en cada etapa los eventos/modos de fallo que pueden conducir a amenazas potenciales y de esa forma eliminarlos.
Descripción
El análisis se lleva a cabo por un equipo de ingenieros (cubriendo las disciplinas de ordenadores, instrumentos, electricidad, procesos, seguridad y funcionamiento) liderados por un especialista en técnicas de análisis de amenazas a través
de una serie de reuniones programadas.
Es importante asignar un tiempo fijo programado dentro del proyecto para las reuniones; la duración se fija en medio
día al menos y no se programan más de cuatro reuniones semanales para permitir el flujo de la documentación que deberá adjuntarse.
Antes del estudio se deberán haber compilado listas de comprobación consensuadas para el examen sistemático del
sistema, y para cada sección del sistema se expondrán cuestiones importantes como: ¿Qué sucede si? ¿Cómo puede
suceder? ¿Cuándo puede suceder? ¿Tiene importancia?. Cuando se obtengan respuestas positivas se hacen nuevas preguntas como: ¿Qué puede hacerse al respecto? ¿Cuándo debe hacerse? ¿Hay una alternativa? etc.
Para la primera parte del análisis se sugiere examinar la instalación de ordenadores en su conjunto. La segunda y sucesivas partes incluyen exámenes detallados de las partes relevantes del propio sistema de ordenadores.
En cada parte o etapa del análisis, el objetivo es identificar modos de fallo que conduzcan a amenazas potenciales en el
sistema controlado y el grado en el que afectan. Las partes principales del sistema de ordenadores son subdivididas
posteriormente y en la medida de lo necesario se someten a un análisis separado.
En momentos adecuados a lo largo del análisis sistemático se convocarán reuniones de revisión de acciones.
Es esencial el mantener registros detallados de las reuniones, ya que formarán parte esencial del dossier de amenazas/seguridad del sistema.
Después de un cierto número de reuniones se sugiere establecer una reunión de revisión para asegurar que se han completado las acciones, se han incorporado al estudio las acciones sugeridas durante las reuniones de estudio, etc.
Referencias
HAZOP y HAZAN. T.A. Kletz, 1986, 2nd Edition, Institution of Chemical Engineers, 165-171 Railway Terrace,
Rugby, CV1 3HQ, UK.
Criterios de Fiabilidad y Peligrosidad para Sistemas Electrónicos Programables en la Industria Química. E. Johnson,
Proc of 'Safety and Reliability of PES', PES 3 Safety Symposium, B.K. Daniels (ed), 28-30 May 1986, Guernsey
Channel Islands, Elsevier Applied Science, 1986.
Ingeniería de la Fiabilidad y Valoración de Riesgos. E.J. Henlty and H. Kumamoto, Prentice Hall, 1981.
Fiabilidad de Sistemas y Análisis de Riesgos. E.G., Frenkel, Martinus Nijhogg 1984.
B.35 Análisis de Impacto (Referenciada por el capítulo 16)
Objetivo
Identificar el efecto que tiene un cambio o mejora en el software del sistema sobre otros módulos del propio sistema o
sobre otros sistemas.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 84 -
Descripción
Antes de llevar a cabo una modificación o mejora en el software, se deberá realizar un análisis para identificar el impacto de la modificación o mejora en el software y para identificar también los sistemas y módulos software afectados.
Una vez completado el análisis, se requiere una decisión con respecto a la re-verificación del software del sistema. Ello
depende del número de módulos software afectados, la criticidad de los mismos y la naturaleza del cambio. Las decisiones posibles son:
i) Solamente se re-verifica el módulo cambiado;
ii) Todos los módulos afectados identificados se re-verifica; y
iii) El sistema completo se re-verifica.
B.36 Ocultamiento de la Información/Encapsulado (Referenciada por D.9)
Objetivo
Incrementar la fiabilidad y mantenibilidad del software.
Descripción
Los datos que son globalmente accesibles a todos los componentes del software pueden ser modificados accidental o
incorrectamente por cualquiera de dichos componentes. Cualquier cambio de esas estructuras de datos puede requerir
un examen detallado del código y extensas modificaciones.
El ocultamiento de la información es una aproximación general para minimizar dichas dificultades. Las estructuras de
datos clave son 'ocultadas' y sólo se pueden manipular a través de un conjunto establecido de procedimientos de acceso.
Ello permite modificar las estructuras internas o añadir procedimientos posteriormente sin afectar el comportamiento
del software restante. Por ejemplo, un nombre de directorio puede tener los procedimientos de acceso Insertar, Borrar y
Encontrar. Los procedimientos de acceso y las estructuras de datos internas pueden re-escribirse (por ejemplo, usar un
método de búsqueda diferente o almacenar los nombres en disco duro) sin afectar el comportamiento lógico del software restante que utiliza dichos procedimientos.
Este concepto de un tipo de datos abstracto está soportado directamente en un cierto número de lenguajes de programación, pero el principio básico puede aplicarse para cualquier lenguaje de programación que se utilice.
Referencias
Ingeniería del Software: Planificación de Cambios. D A Lamb, Prentice Hall, 1988.
Acerca del Diseño y Desarrollo de Familias de Programas. D L Parnas, IEEE Trans SE-2, Mar 1976.
B.37 Ensayos de Interfaces (Referenciada por el capítulo 10)
Objetivo
Demostrar que las interfaces de los subprogramas no contienen ningún tipo de error o errores que den lugar a fallos en
la aplicación particular del software o detectar todos los errores que pueden ser relevantes.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 85 -
EN 50128:2001
Descripción
Son posibles varios niveles de detalle o perfección de los ensayos. Los niveles más importantes son ensayar:
− todas las variables de interface en sus posiciones extremas;
− todas las variables de interface individualmente en sus valores extremos con otras variables de interface en valores
normales;
− todos los valores del dominio de cada variable de interface con otras variables de interface en valores normales;
− todos los valores de todas las variables de interface en combinación. Esto puede ser realizable solamente en interfaces pequeñas;
− las condiciones de ensayo especificadas relevantes a cada llamada de cada subrutina.
Estos ensayos son particularmente importantes si las interfaces no contienen verificaciones para detectar valores incorrectos de parámetros. Son importantes también después de generar configuraciones nuevas de subprogramas preexistentes.
B.38 Subconjunto del Lenguaje (Referenciada por el capítulo 10 y D.4)
Objetivo
Reducir la probabilidad de introducir defectos de programación e incrementar la probabilidad de detectar defectos remanentes.
Descripción
Se examina el lenguaje para identificar construcciones de programación que son propensas al error o difíciles de analizar, por ejemplo utilizando métodos de análisis estático. Se define así un subconjunto del lenguaje que excluye dichas
construcciones.
B.39 Memorización de Casos Ejecutados (Referenciada por el capítulo 9)
Objetivo
Forzar al software a un estado seguro si ejecuta un camino no autorizado.
Descripción
Durante la liberación (release) del software, se construye un registro con todos los detalles relevantes de cada ejecución
del programa. Durante el funcionamiento normal, la ejecución de cada programa se compara con el conjunto de ejecuciones autorizadas. Si hay diferencias, se toma una acción de seguridad.
El registro de ejecución puede ser una secuencia de caminos individuales entre decisión y decisión (caminos DD) o la
secuencia de accesos individuales a arrays, registros o volúmenes, o ambos.
Son posibles varios métodos para el almacenamiento de los caminos de ejecución. Pueden usarse métodos de codificación Nash para trasladar la secuencia de ejecución a un único número grande o a una secuencia de números. Durante el
funcionamiento normal, el valor de ejecución del camino debe comprobarse frente a los casos almacenados antes de
efectuar una operación de salida.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 86 -
Ya que las posibles combinaciones de caminos entre decisión y decisión a lo largo de un programa son muy grandes,
puede que no sea factible tratar programas completos. En este caso, puede aplicarse la técnica a nivel de módulo.
Referencia
Software Seguro ante Fallos - Algunos Principios y un Caso de Estudio. W. Ehrenberger, Proc. SARSS 1987,
Altringham, Manchester, UK, Elsevier Applied Science, 1987.
B.40 Librería de Módulos y Componentes Comprobados/Verificados (Referenciada por el capítulo 10)
Objetivo
Evitar la necesidad de revalidar extensivamente o rediseñar módulos software y componentes hardware para cada nueva
aplicación. También para sacar provecho de diseños que no han sido formal o rigurosamente validados pero que tienen
una historia operativa considerable.
Descripción
Los Sistemas Electrónicos Programables (SEP) bien diseñados y estructurados constan de un número de componentes y
módulos hardware y software claramente distintos y que interaccionan entre sí de manera clara y definida.
Diferentes SEP diseñados para diferentes aplicaciones contendrán un cierto número de módulos o componentes que son
iguales o muy similares. La construcción de una librería de tales módulos de aplicación general permite que muchos de
los recursos necesarios para validar los diseños sean compartidos por más de una aplicación.
Además, el uso de tales módulos en múltiples aplicaciones proporciona una evidencia empírica de su funcionamiento
correcto. Esta evidencia empírica mejora de forma justificada la confianza que los usuarios tienen en dichos módulos.
B.41 Modelos de Markov (Referenciada por el capítulo 14)
Objetivo
Evaluar la fiabilidad, seguridad o disponibilidad de un sistema.
Descripción
Se construye un gráfico del sistema. El gráfico representa el estado del sistema con respecto a sus estados de fallo (los
estados de fallo se representan mediante nodos del gráfico). Los ejes entre nodos, que representan los eventos de fallo o
reparación, son ponderados con la correspondiente tasa de fallo o reparación. Obsérvese que los eventos de fallo, estados y tasas pueden detallarse de forma que se obtenga una descripción precisa del sistema, por ejemplo, fallos detectados o no, manifestación de un fallo más grande, etc.
La técnica de Markov es apropiada para modelar sistemas redundantes donde el nivel de redundancia varía con el tiempo debido a los fallos y reparaciones de componentes. Otros métodos clásicos, por ejemplo, FMEA y FTA, no pueden
adaptarse fácilmente al modelado de fallos a lo largo del ciclo de vida del sistema ya que no existen fórmulas combinatorias simples para calcular las probabilidades correspondientes.
En los casos más simples, las fórmulas que describen las probabilidades del sistema están fácilmente disponibles en la
literatura o pueden calcularse manualmente. En casos más complejos, existen algunos métodos de simplificación (absorbiendo estados). Para casos muy complejos, los resultados pueden obtenerse por simulación del gráfico en ordenador.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 87 -
EN 50128:2001
Referencias
La Teoría de Procesos Estocásticos. R.E. Cox and H.D. Miller, Methuen and Co. Ltd, London, UK, 1968.
Cadenas de MARKOV Finitas. J.G. Kemeny and J.L. Snell, D. Van Nostrand Company Inc., Princeton, 1959.
Manual de Fiabilidad. B.A. Koslov and L.A. Ushakov, Holt Rinehart and Winston Inc., New York 1970.
Teoría y Práctica para el Diseño de Sistemas Fiables. D.P. Siewiorek and R.S. Swarz, Digital Press 1982.
B.42 Evaluaciones (Referenciada por el capítulo 11 y el capítulo 14)
Objetivo
Predecir los atributos de los programas a partir de las propiedades propias del software en lugar de considerar su historia
de desarrollo y ensayos.
Descripción
Estos modelos evalúan algunas propiedades estructurales del software y las relacionan con un atributo deseado tal como
la fiabilidad o la complejidad. Se requieren herramientas software para realizar la mayoría de estas evaluaciones. Algunas de las evaluaciones que se pueden aplicar se dan a continuación
− Complejidad Teórica del Gráfico: Esta medida puede aplicarse al comienzo del ciclo de vida para valorar inconvenientes, y se basa en la complejidad del gráfico de control del programa, representado por su número ciclomático;
− número de maneras de activar un determinado módulo (accesibilidad): cuanto más se pueda acceder a un módulo,
mayor es la probabilidad de que sea depurado;
− Ciencia Software: Esta medida calcula la longitud del programa contando el número de operadores y operandos.
Proporciona una medida de la complejidad y estima el número de recursos de desarrollo;
− número de entradas y salidas por módulo: minimizar el número de puntos de entrada/salida es una característica
fundamental de las técnicas de diseño y programación estructuradas.
Referencias
Una Medida de la Complejidad. T.J. McCabe, IEEE Trans. on Software Engineering, Vol. SE-2, No. 4, Dec 1976.
Modelos y Mediciones para las Valoraciones de la Calidad del Software. S.N. Mohanty, ACMComputing Surveys,
Vol 11, No. 3, Sep 1979.
Elementos de la Ciencia del Software. M.H. Halstead, Elsevier, North Holland, New York, 1977.
B.43 Solución Modular (Referenciada por D.9)
Objetivo
Descomposición de un sistema software en partes pequeñas comprensibles a fin de limitar la complejidad del problema.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 88 -
Descripción
La Solución Modular o modularización contiene varias reglas para las fases de diseño, codificación y mantenimiento de
un proyecto software. Estas reglas varían de acuerdo al método de diseño empleado. La mayoría de los métodos contienen las siguientes reglas:
− cada módulo deberá tener una sola tarea o función bien definida a ejecutar;
− las conexiones entre módulos deberán estar limitadas y estrictamente definidas, y la coherencia en el módulo deberá
ser fuerte;
− las colecciones de subprogramas se deberán construir proporcionando varios niveles de módulos;
− los tamaños de los subprogramas se deberán restringir a un valor especificado, típicamente de 2 a 4 pantallas;
− los subprogramas deberán tener una sola entrada y una sola salida;
− los módulos se deberán comunicar con otros módulos a través de sus interfaces. cuando se usen variables globales o
comunes deberán estar bien estructuradas, el acceso deberá estar controlado y su uso se deberá justificar en cada caso;
− todos los interfaces de los módulos deberán estar completamente documentados;
− cada modulo deberá ocultar algo de su entorno;
− cada interface de módulo deberá contener el mínimo número de parámetros necesarios para la función de los módulos; y
− se deberá especificar una restricción adecuada para el número de parámetros, normalmente 5.
B.44 Simulación de Monte-Carlo
Objetivo
Simular los fenómenos del mundo real en el software utilizando números aleatorios.
Descripción
Las simulaciones de Monte-Carlo se usan para resolver problemas. Estos problemas se dividen en dos clases:
− probabilísticos, donde se usan números aleatorios para generar un fenómeno estocástico del mundo real;
− determinísticos, que se trasladan matemáticamente a un problema probabilístico equivalente.
La simulación de Monte-Carlo inyecta un flujo de números aleatorios para simular ruido en una señal analítica o añadir
desviaciones aleatorias o tolerancias. Se corre la simulación de Monte-Carlo para obtener una muestra grande a partir de
la cual se obtienen resultados estadísticos.
Cuando se utilicen simulaciones de Monte-Carlo se debe tener cuidado en asegurar que las desviaciones, tolerancias o
ruido son de un valor razonable.
Un principio general de las simulaciones de Monte-Carlo es replantear y reformular el problema para que los resultados
sean lo más precisos posible, en lugar de fijar el problema como se estableció inicialmente.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 89 -
EN 50128:2001
B.45 Modelado de Prestaciones (Referenciada por D.2 y D.5)
Objetivo
Asegurar que la capacidad de trabajo del sistema es suficiente para alcanzar los requisitos especificados.
Descripción
La especificación de requisitos incluye capacidad de proceso y condicionantes de respuesta para funciones específicas,
combinados quizá con limitaciones en el uso de los recursos del sistema total. El diseño de sistema propuesto se compara con los requisitos establecidos mediante:
− la definición de un modelo de los procesos del sistema y sus interacciones;
− identificando el uso de recursos por cada uno de los procesos, por ejemplo, tiempo de procesador, ancho de banda de
comunicaciones, dispositivos de almacenamiento, etc.;
− identificando la distribución de peticiones que recibe el sistema en condiciones medias para el caso más desfavorable;
− calculando la capacidad de proceso media para el caso más desfavorable, y los tiempos de respuesta para las funci ones individuales del sistema.
Para sistemas sencillos, puede ser posible una solución analítica, mientras que para los más complejos se requerirá algún tipo de simulación para obtener resultados precisos.
Antes de ir a un modelo detallado, puede hacerse una comprobación más simple del 'presupuesto de recursos', sumando
los requisitos de recursos de cada proceso. Si los requisitos exceden la capacidad del sistema diseñada, el diseño no es
factible. Incluso si el diseño pasa esta comprobación, el modelado de prestaciones puede mostrar que tienen lugar retr asos y tiempos de respuesta excesivos debidos a la escasez de recursos. Para evitar esta situación, los ingenieros diseñan
normalmente sistemas que utilizan una fracción (por ejemplo, 50%) de los recursos totales a fin de reducir la probabilidad de la escasez de recursos.
B.46 Requisitos de Prestaciones (Referenciada por D.6)
Objetivo
Establecer que los requisitos relativos a las prestaciones de un sistema software han sido satisfechos.
Descripción
Se efectúa un análisis de las especificaciones de requisitos, tanto del sistema como del software, para identificar todas
las características generales y específicas, explícitas e implícitas requeridas.
Cada requisito de prestaciones se examina a su vez para determinar:
− los criterios en cuanto a los logros a obtener;
− si se puede establecer alguna medición para ello;
− la exactitud potencial de tales mediciones;
− las etapas del proyecto en las que se pueden estimar las mediciones;
− las etapas del proyecto en las que se pueden efectuar las mediciones.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 90 -
El grado en que es practicable cada requisito de prestaciones se analiza entonces a fin de obtener una lista de los mismos, criterios de logro y mediciones potenciales. Los principales objetivos son:
i) cada requisito de prestaciones está asociado al menos con una medición;
ii) siempre que sea posible, se seleccionan mediciones precisas y eficientes que puedan ser utilizadas tan pronto como
sea posible en el ciclo de desarrollo;
iii) identificar los requisitos de prestaciones esenciales y opcionales y sus criterios de logro; y
iv) siempre que sea posible se deberá aprovechar la posibilidad de usar una misma medición para más de un requisito
de prestaciones.
B.47 Ensayos Probabilísticos (Referenciada por el capítulo 11 y el capítulo 13)
Objetivo
Obtener una cifra cuantitativa sobre las propiedades de fiabilidad del software investigado. Esta cifra puede incluir los
niveles relativos de confianza y trascendencia y:
i) la probabilidad de fallo por demanda;
ii) la probabilidad de fallo durante un cierto período de tiempo;
iii) la probabilidad de errores remanentes.
A partir de estas cifras se pueden derivar otros parámetros como:
− la probabilidad de ejecución libre de fallos;
− la probabilidad de supervivencia;
− disponibilidad;
− MTBF (tiempo medio entre fallos) o tasa de fallos; y
− la probabilidad de ejecución segura.
Descripción
Las consideraciones probabilísticas se basan en ensayos del mismo tipo o en la experiencia de funcionamiento. Normalmente el número de casos de ensayo de los casos de funcionamiento observados es muy grande.
A fin de facilitar los ensayos, se usan normalmente ayudas automáticas. Los ensayos extensivos se corren en ordenadores grandes con la periferia de simulación del proceso adecuada. Los datos de ensayo se seleccionan desde el punto de
vista sistemático y aleatorio. Como primer objetivo, un control de ensayos global garantiza un perfil de datos de ensayo.
La selección aleatoria considera los casos de ensayo individual en detalle.
Los casos de ensayo individual, ejecuciones de ensayo y su supervisión se determinan a partir de los objetivos de ensayo detallados, como se describió anteriormente. Otras condiciones importantes se obtienen a partir de los pre-requisitos
matemáticos que se deberán satisfacer para permitir la evaluación de los ensayos en función del objetivo que se pretende con las mismas.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 91 -
EN 50128:2001
Cifras probabilísticas sobre el comportamiento de cualquier objeto bajo ensayo pueden derivarse también de la experiencia operativa. Suponiendo que se satisfacen las mismas condiciones, se pueden aplicar las mismas matemáticas para
evaluar los resultados de los ensayos.
B.48 Simulación de Procesos (Referenciada por D.3)
Objetivo
Comprobar las funciones de un sistema software, junto con su interface con el mundo exterior sin permitir que ello
modifique el mundo real en forma alguna.
Descripción
Se pretende crear un sistema, para propósitos de ensayo solamente, que imite el comportamiento del sistema a ser controlado por el sistema bajo ensayo.
La simulación puede ser software puramente o una combinación de software y hardware. La simulación debe:
− proporcionar al sistema bajo ensayo todas las entradas que existirán cuando el sistema sea instalado.
− responder a las salidas del sistema de una manera que represente fielmente la planta controlada;
− tener provisiones para entradas del operador a través de las cuales se introduzcan cualquier tipo de perturbación con
la que deba enfrentarse el sistema.
Cuando se está probando el software, la simulación puede ser la correspondiente al hardware real con sus entradas y
salidas.
Referencias
Un Simulador Software − Una Ayuda para la Puesta en Servicio de una Planta. S. Nunns, EWICS TC7.
Simulación de Defectos Físicos. F. Morillon, EWICS Document number WP460.
B.49 Prototipado/Animación (Referenciada por D.3 y D.5)
Objetivo
Comprobar la factibilidad de implementar el sistema con las limitaciones existentes. Comunicar al cliente la interpretación de quien ha especificado el sistema a fin de localizar malos entendidos.
Descripción
Se seleccionan un subconjunto de funciones del sistema, limitaciones y requisitos de prestaciones. Se construye un
prototipo utilizando herramientas de alto nivel. En esta etapa, no es necesario considerar limitaciones tales como el
ordenador real, lenguaje de implementación, tamaño del programa, mantenibilidad, fiabilidad y disponibilidad. Se evalúa el prototipo frente a los criterios del cliente y a la luz de dicha evaluación pueden modificarse los requisitos del
sistema.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 92 -
Referencias
Proc. de la Conferencia de Trabajo sobre Prototipado. Namur Oct 1983, Budde et al, Springer-verlag, 1984.
Uso de un lenguaje de especificación ejecutable para un sistema de información. S. Urban et. al, IEEE Trans Software
Engineering, Vol. SE-11 No. 7 July 1985.
B.50 Recuperación en Bloque (Referenciada por el capítulo 9)
Objetivo
Aumentar la probabilidad de que un programa realice la función que se pretende.
Descripción
Se escriben varias secciones de programa diferentes, a menudo independientemente, intentando que cada una de ellas
realice la función deseada. Se construye el programa final a partir de esas secciones. La primera sección, llamada primaria, se ejecuta primero. Esto va seguido de una ensayo de aceptación del resultado que se ha calculado. Si pasa el ensayo, el resultado se acepta y pasa a las partes siguientes del sistema. Si falla, se eliminan todos los efectos laterales de la
primera sección y se ejecuta la segunda, llamada primera alternativa. Lo cual va seguido de una ensayo de aceptación
también y tratado como el primer caso. Pueden proporcionarse una segunda, tercera o incluso más alternativas si se
desea.
Referencia
Estructura de Sistema para Software Tolerante a Fallos. B. Randall, IEEE Trans Software Engineering, Vol SE-1, No 2,
1975.
B.51 Diagrama de Bloques de Fiabilidad (Referenciada por el capítulo 14)
Objetivo
Modelar, en forma de diagrama, el conjunto de eventos que deben tener lugar y las condiciones que deberán satisfacerse
para un funcionamiento correcto de un sistema o tarea.
Descripción
El objeto del análisis se representa como un camino correcto que consta de bloques, líneas y funciones lógicas. Un
camino correcto comienza a un lado del diagrama y continúa a través de bloques y cruces hasta el otro lado del mismo.
Un bloque representa una condición o un evento, y el camino lo pasa si la condición es verdadera o ha tenido lugar el
evento. Si el camino llega a un cruce, continúa si se satisface la función lógica. Si llega a un nodo puede continuar a lo
largo de todas las líneas salientes. Si existe al menos un camino correcto a través del diagrama, el objeto del análisis
está funcionando correctamente.
Referencias
Metodología de Ingeniería de Fiabilidad de Sistemas: Una Parte del Estado del Arte. J.B. Fusseland J.S. Arend, Nuclear
Safety 20(5), 1979.
Manual del Árbol de Fallos. W.E. Vesely et al, NUREG-0942, Division of System Safety Office at Nuclear Reactor
Regulation, U.S. Nuclear Regulatory Commission, Washington, D.C. 20555, 1981.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 93 -
EN 50128:2001
B.52 Tiempos de Respuesta y Limitaciones de Memoria (Referenciada por D.6)
Objetivo
Asegurar que el sistema cumple los requisitos temporales y de memoria.
Descripción
La especificación de requisitos del sistema y del software incluye condicionantes de memoria y respuesta para funciones específicas, combinados quizá con limitaciones en el uso de los recursos globales del sistema. Se realiza un análisis
que deberá identificar las distribuciones de demandas en condiciones medias y en el caso peor. Este análisis requiere
estimar el uso de recursos y el tiempo empleado por cada función del sistema. Estas estimaciones se pueden obtener de
varias formas, por ejemplo, por comparación con un sistema existente o a través de prototipado y banco de ensayos de
sistemas críticos en el tiempo.
B.53 Mecanismos de Recuperación de Fallos por Reintento (Referenciada por el capítulo 9)
Objetivo
Intentar la recuperación funcional desde una condición de fallo detectado mediante mecanismos de reintento.
Descripción
En caso de un fallo o condición de error detectada, se efectúan intentos para recuperar la situación volviendo a ejecutar
el mismo código. La recuperación por reintento puede ser tan completa como un procedimiento de recarga y reinicio o
una pequeña tarea de reorganización y reinicio, después de transcurrido un tiempo de espera software o por acción de
un mecanismo de perro guardián. Las técnicas de reintento son de uso común en la recuperación de fallos o errores de
comunicación, y las condiciones de reintento pueden venir dadas por un error en el protocolo de comunicación (suma de
comprobación, etc.) o por una indicación del vencimiento del tiempo de espera de respuesta.
Referencia
Teoría y Práctica de Diseño de Sistemas Fiables. D.P. Siewiorek and R.S. Schwarz, Digital Press.
B.54 Bolsa de Seguridad (Referenciada por el capítulo 9)
Objetivo
Proteger frente a defectos residuales de especificación e implementación del software que afectan de forma adversa a la
seguridad.
Descripción
Una bolsa de seguridad es un supervisor externo, implementado en un ordenador independiente con arreglo a una especificación diferente. Esta bolsa de seguridad se preocupa únicamente en garantizar que el ordenador principal ejecuta
acciones seguras, aunque no necesariamente correctas. La bolsa de seguridad supervisa continuamente al ordenador
principal. Evita que el sistema llegue a un estado inseguro. Además, si detecta que el ordenador principal está entrando
en un estado potencialmente peligroso, el sistema tiene que volver al estado seguro mediante la bolsa de seguridad o
mediante el propio ordenador principal.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 94 -
Referencia
Utilizando Técnicas de Inteligencia Artificial para Mejorar la Seguridad del Software. Proc. IFAC SAFECOMP 88,
Sarlat, France, Oct 1986, Pergamon Press 1986.
B.55 Análisis de Caminos Furtivos (Referenciada por D.8)
Objetivo
Detectar un camino o flujo lógico inesperado dentro de un sistema, que bajo ciertas condiciones inicia una función
indeseada o inhibe una deseada.
Descripción
Un camino furtivo puede incluir al hardware, software, acciones del operador o combinaciones de estos elementos. Los
caminos furtivos no son resultado de fallos hardware sino que son condiciones latentes diseñadas inadvertidamente en
el sistema o codificadas en los programas software, que pueden causar una malfunción del mismo bajo ciertas condiciones.
Entre las clases de caminos furtivos están:
− Caminos furtivos que originan que la corriente, energía o secuencia lógica fluyan a lo largo de un camino inesperado
o en una dirección no prevista.
− Temporización furtiva, en la cual los eventos ocurren en una secuencia inesperada o conflictiva.
− Indicaciones furtivas, que originan una representación ambigua o falsa de las condiciones de operación del sistema,
y pueden ocasionar una acción indeseada por parte del operador.
− Etiquetas furtivos, que marcan incorrectamente o de forma imprecisa funciones del sistema, por ejemplo entradas
del sistema, controles, buses, etc. que pueden engañar al operador y hacerle aplicar un estímulo incorrecto al sistema.
El análisis de caminos furtivos se basa en el reconocimiento de patrones topológicos básicos con la estructura hardware
o software (por ejemplo, se identifican seis patrones básicos para el software). El análisis tiene lugar con la ayuda de
una lista de comprobación con preguntas sobre el uso y relaciones entre los componentes topológicos básicos.
Referencias
Análisis Furtivo y su Aplicación al Software. S.G. Godoy and G.J. Engels, J. Aircraft Vol. 15, No. 8, 1978.
Análisis de Caminos Furtivos. J.P. Rankin, Nuclear Safety, Vol. 14, No. 5, 1973.
B.56 Gestión de Configuración Software (Referenciada por el capítulo 15)
Objetivo
La Gestión de Configuración Software trata de asegurar la consistencia de grupos de entregables de desarrollo así como
de los cambios de los mismos. La Gestión de Configuración, en general, se aplica tanto al desarrollo hardware como
software.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 95 -
EN 50128:2001
Descripción
La Gestión de Configuración Software es una técnica usada a lo largo del desarrollo. En esencia, requiere que se registre la generación de cualquier versión de cada parte 'significativa' entregable y de todas las relaciones entre diferentes
versiones de las diferentes partes entregables. Los registros resultantes permiten determinar al diseñador el efecto de un
cambio de una versión sobre otras versiones (especialmente sobre sus componentes). En particular, pueden reconstruirse sistemas o subsistemas de forma fiable a partir de conjuntos consistentes de versiones de componentes.
Referencias
Prácticas de Gestión de Configuración para Sistemas, Equipos, Accesorios y Programas de Ordenador. MIL-STD-483.
Gestión de Configuración Software. J K Buckle, Macmillan Press, 1982.
Gestión de Configuración Software. W A Babich, Addison-Wesley, 1986.
Requisitos de Gestión de Configuración para Equipos de Defensa. UK Ministry of Defence Standard 05-57 Issue 1,
1980.
B.57 Lenguajes de Programación Fuertemente Tipados (Referenciada por el capítulo 10)
Objetivo
Reducir la probabilidad de fallos mediante la utilización de un lenguaje que permita un alto nivel de comprobación por
parte del compilador.
Descripción
Estos lenguajes normalmente permiten definir tipos de datos de usuario a partir de los tipos de datos básicos del lenguaje (como ENTERO, REAL). Esos tipos pueden utilizarse entonces exactamente de la misma manera que los tipos
básicos, pero se imponen estrictas comprobaciones para asegurar que se usa el tipo correcto. Estas comprobaciones se
imponen para todo el programa, incluso si se construye a partir de unidades compiladas separadamente. Las comprobaciones garantizan también que el número y tipo de argumentos de las subrutinas concuerdan, incluso cuando la referencia se hace desde módulos compilados separadamente.
Los lenguajes fuertemente tipados soportan también otros aspectos de la buena práctica en ingeniería software, tal como
estructuras de control fácilmente analizables (por ejemplo, IF..THEN..ELSE, DO..WHILE, etc.) que dan lugar a programas bien estructurados.
Ejemplos típicos de lenguajes fuertemente tipados son Pascal, Ada y Modula 2.
Referencias
Manual de Referencia para el Lenguaje de Programación Ada. ANSI/MIL-STD-815A 1983.
En busca de Diversidad Efectiva: un Estudio de Seis Lenguajes para Software de Control de Vuelo Tolerante a Fallos,
A Avizienis, M R Lyu, W Schutz, The Eighteenth International Symposium on Fault Tolerant Computing, Tokyo,
Japan 27-30 June 1988, IEEE Computer Society Press, ISBN 0-8186-0867-6.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 96 -
B.58 Ensayos Basadas en la Estructura (Referenciada por D.2)
Objetivo
Aplicar ensayos que ejerciten subconjuntos de la estructura del programa.
Descripción
Basándose en el análisis del programa, se escogen un conjunto de datos de entrada de forma que se ejerciten una gran
parte de elementos del programa seleccionado. Los elementos de programa ejercitados pueden variar dependiendo del
nivel de rigor requerido.
− Sentencias: Ésta es el ensayo menos rigurosa ya que es posible ejecutar todas las instrucciones del código sin ejercitar ambas ramas de una sentencia condicional.
− Bifurcaciones: Deberían comprobarse ambas ramas. Esto puede ser impracticable para algunos tipos de código defensivo.
− Condiciones Compuestas: Se ejercita cada condición en una bifurcación condicional compuesta (es decir, enlazada
mediante AND/OR).
− SCLYS: Una secuencia de código lineal y salto es cualquier secuencia lineal de instrucciones de código, incluyendo
saltos condicionales, terminada por un salto. Muchos sub-caminos potenciales serán impracticables debido a restricciones impuestas sobre los datos de entrada por la ejecución del código previo.
− Flujo de datos: Los caminos de ejecución se seleccionan sobre la base de uso de los datos, por ejemplo un camino
donde la misma variable es escrita y leída.
− Gráfico de Llamadas: Un programa se compone de subrutinas que pueden ser invocadas desde otras subrutinas. El
gráfico de llamadas es el árbol de invocaciones de subrutinas en el programa. Los ensayos se diseñan para cubrir todas las invocaciones en el árbol.
− Todos los Caminos: Ejecutar todos los caminos posibles a través del código. El ensayo completa es normalmente
impracticable debido al gran número de caminos potenciales.
Referencia
Fiabilidad de la Estrategia de Ensayo basada en el Análisis de Caminos. W. Howden, IEEE Trans Software
Engineering, Vol SE 3, 1976.
B.59 Diagramas de Estructura (Referenciada por D.5)
Objetivo
Mostrar la estructura de un programa en forma de diagrama.
Descripción
Los Diagrama de Estructura son una notación que complementa los Diagramas de Flujo de Datos. Describen el sistema
de programación y una jerarquía de partes y lo presentan gráficamente como un árbol. Documentan cómo pueden implementarse elementos de un diagrama de flujo de datos mediante una jerarquía de unidades de programa.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 97 -
EN 50128:2001
Un gráfico de estructura muestra las relaciones entre unidades de programa sin incluir información alguna sobre el
orden de activación de las mismas. Se dibujan utilizando los tres símbolos siguientes:
i) un rectángulo rotulado con el nombre de la unidad;
ii) una flecha conectando dichos rectángulos;
iii) una flecha dentro de un circulo, rotulada con el nombre de los datos pasados a y desde elementos en el diagrama de
estructura. Normalmente se dibuja paralela a la flecha que conecta los rectángulos en el gráfico.
A partir de un diagrama de flujo de datos no trivial es posible derivar un número de diagramas de estructura diferentes.
Los diagramas de estructura obtenidos a partir de diagramas de flujo de datos representan una estructura de primer nivel
del sistema, donde cada caja del gráfico de estructura representa una burbuja en el diagrama de flujo de datos. Por supuesto, se pueden describir niveles más profundos utilizando la misma técnica.
Referencias
Ingeniería Software. I. Sommerville, Addison-Wesley 1982. ISBN 0-201-13795-X.
Diseño Estructurado. L.L Constantine and E, Yourdon, Englewood Cliffs, New Jersey, Prentice Hall, 1979.
Software Fiable Mediante Diseño Compuesto. G.J Myers, New York, Van Nostrand, 1975.
B.60 Metodología Estructurada (Referenciada por el capítulo 8 y el capítulo 10)
Objetivo
El principal objetivo de las Metodologías Estructuradas es promover la calidad del desarrollo software concentrando la
atención en las primeras partes del ciclo de vida. Los métodos tratan de conseguirlo mediante procedimientos precisos e
intuitivos y notaciones (asistidas por ordenador) que identifiquen la existencia de requisitos y características de implementación en un orden lógico y de una manera estructurada.
Descripción
Existen una serie de Metodologías Estructuradas. Algunas como SSADM, LBMS están diseñadas para el proceso de
datos tradicional y funciones de proceso de transacciones, mientras que otras (MASCOT, JSD, Yourdon en tiempo real)
están más orientadas al control de procesos y aplicaciones en tiempo real (que tienden a ser más críticas en cuanto a
seguridad).
Los Métodos Estructurados son esencialmente 'herramientas de pensamiento' para percibir y dividir sistemáticamente
un problema o sistema. Sus características principales son:
− un orden lógico de pensar, dividiendo un problema grande en etapas manejables;
− identificación del sistema global, incluyendo el entorno así como el sistema requerido;
− descomposición de datos y funciones en el sistema requerido;
− listas de comprobación, es decir, listas del tipo de cosas que necesitan definición;
− gasto intelectual bajo − Simples, intuitivos, pragmáticos.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 98 -
Las notaciones que les dan soporte tienden a ser precisas en la identificación del problema y entidades del sistema (por
ejemplo, procesos y flujos de datos), pero las funciones de procesamiento llevadas a cabo por esas entidades tienden a
expresarse utilizando notaciones informales. Sin embargo algunos métodos hacen uso parcial de notaciones formales
(matemáticas) (por ejemplo, JSD usa expresiones regulares; Yourdon, SOM y SDL utilizan máquinas de estados finitos). Esta precisión no solamente reduce grado de mal entendimiento, sino que proporciona la posibilidad de un procesamiento automático.
Otro beneficio de la notación estructurada es su visibilidad, permitiendo que una especificación o diseño sea comprob ado intuitivamente por el usuario frente a sus propios conocimientos profundos del tema.
Esta bibliografía describe algunos de estas Metodologías Estructuradas con más detalle, por ejemplo la Expresión de
Requisitos Controlada, Desarrollo de Sistemas de Jackson, MASCOT, Yourdon en tiempo real y la Técnica de Análisis
y Diseño Estructurado (SADT).
Referencias
Desarrollo Estructurado para Sistemas en tiempo real (3 Volúmenes). P T Yourdon Press, 1985.
Análisis de Sistemas Esenciales. St M McMenamin, F Palmer, Yourdon Inc, 1984, N Y.
El Uso de Métodos Estructurados en el Desarrollo de Grandes Sistemas de Aviónica Basados en el Software. D J
Hatley, Proceedings DASC, Baltimore, 1984.
B.60.1 Expresión de Requisitos Controlada (CORE)
Objetivo
Asegurar que todos los requisitos son identificados y expresados.
Descripción
Esta aproximación pretende salvar el hueco entre el cliente/usuario final y el analista. No es matemáticamente rigurosa
pero ayuda en el proceso de comunicación - CORE está diseñada para la expresión de requisitos más que para la especificación. La aproximación es estructurada y la expresión pasa por varios niveles de refinamiento. El proceso CORE
incita a una visión más amplia del problema, introduciendo un conocimiento del entorno en que se usará el sistema y
diferentes puntos de vista de los diversos tipos de usuarios. CORE incluye pautas y tácticas para reconocer desviaciones
respecto al 'gran diseño'. Las desviaciones pueden corregirse o identificarse explícitamente y documentarse. Las especificaciones pueden no ser completas, pero se identifican problemas no resueltos o áreas de alto riesgo que tienen que
tratar en el diseño posterior.
B.60.2 JSD − Sistema de Desarrollo de Jackson
Objetivo
Método de desarrollo que cubre el desarrollo de sistemas software partiendo de los requisitos y pasando por el código,
con énfasis especial para sistemas en tiempo real.
Descripción
JSD es un proceso de desarrollo por etapas en donde el diseñador modela los procesos del mundo real sobre los que se
basan las funciones del sistema, determina las funciones requeridas y las inserta en el modelo y transforma la especificación resultante en una que sea realizable en el entorno objetivo. Por tanto cubre las fases tradicionales de definición,
diseño e implementación pero difiere un tanto de los métodos tradicionales en la medida en que no es arriba-abajo.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 99 -
EN 50128:2001
Además pone un gran énfasis en las primeras etapas de identificación de las entidades del mundo real que son incumbencia del sistema que se está construyendo, en su modelado y en lo que puede suceder a las mismas. Una vez hecho
este análisis del 'mundo real' y creado un modelo, se analizan las funciones del sistema requeridas para determinar como
pueden adaptarse a este modelo real. El modelo de sistema resultante se aumenta con descripciones estructuradas de
todos los procesos en el mismo y el conjunto se transforma entonces en programas que funcionarán en el software objetivo y en el entorno hardware.
Referencias
Una Visión General de JSD. J R Cameron, IEEE Trans SE-12 No 2 Feb 1986.
Desarrollo de Sistemas. M Jackson, Prentice-Hall, 1983.
B.60.3 MASCOT
Objetivo
Diseño e implementación de sistemas en tiempo real.
Descripción
MASCOT (Aproximación Modular a la Construcción, Operación y Ensayo del Software) es un método de diseño soportado por un sistema de programación. Es un método sistemático de expresar la estructura de un sistema en tiempo
real de forma que sea independiente del hardware de destino o del lenguaje de implementación. Impone una aproximación disciplinada al diseño que se basa en una estructura altamente modular, asegurando una estrecha correspondencia
entre los elementos funcionales del diseño y los elementos constructivos que aparecen en la integración del sistema. Un
sistema se diseña en términos de una red de procesos concurrentes que se comunican a través de canales. Los canales
pueden ser zonas comunes de datos fijos o colas (flujos de datos). El control de acceso a los canales se define independientemente de los procesos, en términos de mecanismos de acceso que también refuerzan las reglas de programación
de los procesos. Las versiones recientes de MASCOT se han diseñado teniendo en mente una implementación con Ada.
MASCOT soporta una estrategia de aceptación basada en el ensayo y verificación de módulos aislados y colecciones de
módulos relacionados funcionalmente. Está proyectado construir una implementación MASCOT en base a un núcleo
MASCOT − un conjunto de primitivas de programación que definen la implementación y soportan los mecanismos de
acceso.
Referencia
Guía de Usuario de MASCOT 3. MASCOT Users Forum, RSRE, Malvern, England, 1987.
B.60.4 Yourdon en tiempo-real
Objetivo
Pretende ser un método de desarrollo software completo, incluyendo técnicas de especificación y diseño orientadas al
desarrollo de sistemas en tiempo real.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 100 -
Descripción
El esquema de desarrollo fundamental de esta técnica supone una evolución en tres fases del sistema que esta siendo
desarrollado. La primera fase implica la construcción de un 'modelo esencial', que describe el comportamiento requerido por parte del sistema. La segunda incluye la construcción de un modelo de implementación que describe las estructuras y mecanismos que, una vez implementados, incorporan el comportamiento requerido. La tercera fase se refiere a la
construcción real del sistema en su hardware y software. Las tres fases se corresponden a grosso modo con las fases de
definición, diseño e implementación tradicionales, pero ponen más énfasis en el hecho de que en cada etapa el diseñador esta ocupado en una actividad de modelado.
El modelo esencial tiene dos partes: el modelo del entorno, que contiene la definición de la frontera entre el sistema y su
entorno y una descripción de los eventos externos a los que el sistema deberá responder, y el modelo de comportamiento, que contiene esquemas que definen la transformación que el sistema lleva a cabo en respuesta a los eventos y
una definición de los datos que deberá mantener el sistema para responder.
El modelo de implementación se divide también en dos sub-modelos: en este caso se trata de la asignación de los procesos individuales a los procesadores y la descomposición de los procesos en módulos.
Para capturar dichos modelos se combinan un número de técnicas bien conocidas: diagramas de flujo de datos, inglés
estructurado, diagramas de transición de estados y Redes de Petri.
Adicionalmente, el método contiene técnicas para simular un diseño de sistema propuesto, bien en papel o mecánicamente a partir de modelo que se ha dibujado.
Referencia
Desarrollo Estructurado de Sistemas en Tiempo Real (3 Volúmenes). PT Ward and SJ Mellor. Yourdon Press, 1985.
B.60.5 SADT − Técnica de Análisis y Diseño Estructurado
Objetivo
Modelar e identificar, en forma de diagrama que utiliza flujos de información, el proceso de toma de decisiones y las
tareas de gestión asociadas con un sistema complejo.
Descripción
En SADT, el concepto de Diagrama de Factor de Actividad juega un papel central. Un diagrama de F/A consta de actividades agrupadas en lo que se llama 'cajas de acción'. Cada caja de acción tiene un nombre único y se une con otras
cajas de acción mediante factores de relación (dibujados como flechas) que también tienen nombres únicos. Cada caja
de acción puede descomponerse jerárquicamente en cajas de acción y relaciones subsidiarias. Hay cuatro tipos de factores: entradas, controles, mecanismos y salidas.
Entrada: se indica mediante una flecha que entra en el lado izquierdo de la caja de acción. Las entradas pueden representar cosas materiales o inmateriales y son aptas para ser manipuladas por una o más actividades de la caja de acción.
Control: son típicamente instrucciones, procedimientos, criterios de elección y demás. Los controles dirigen la ejecución de una actividad y se muestran como flechas que entran en la caja de acción por su parte superior.
Mecanismo: es un recurso tal como el personal, unidades organizativas o equipos, que es necesario para que una actividad realice su tarea.
Salida: puede indicar cualquier cosa que produce una actividad, y se representa por una flecha que sale del lado derecho
de la caja de acción.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 101 -
EN 50128:2001
Cuando las actividades están fuertemente relacionadas entre sí por muchos factores de relación, es quizá mejor considerarlas como un grupo indivisible contenido en una caja de acción que no permite detallar más su contenido. El principio
director para agrupar actividades en cajas de acción es que las cajas resultantes estén acopladas par a par solamente por
unos pocos factores.
La jerarquía del modelo de los diagramas de F/A prosigue hasta que no tiene sentido detallar más las cajas de acción.
Esta etapa se alcanza cuando las actividades dentro de las cajas son inseparables o cuando un mayor detalle de las cajas
se sale fuera del alcance del análisis del sistema.
Referencias
Análisis Estructurado de la Definición de Requisitos. DT Ross, KE Schoman Jr, IEEE Trans. Software Eng. Vol SE-3,
1977, 6-15.
Análisis Estructurado (AE): Un lenguaje para la comunicación de las ideas. DT Ross, IEEE Trans. Software Eng., Vol
SE-3,1, 16-34.
Aplicaciones y Ampliaciones de SADT. DT Ross, Computer, April 1985, 25-34.
Técnica de Análisis y Diseño Estructurado - Aplicación a los Sistemas de Seguridad. W Heins, Risk Assessment and
Control Courseware, Module B1, chapter 11, 1989, Delft University of Technology, Safety Science Group, PO Box
5050, 2600 GB Delft, Netherlands.
B.61 Programación Estructurada (Referenciada por el capítulo 10)
Objetivo
Diseñar e implementar el programa de forma que sea práctico el análisis del mismo. Este análisis debería ser capaz de
revelar todos los comportamientos significativos del programa.
Descripción
El programa debería contener la mínima complejidad estructural. Debería evitarse las ramificaciones complicadas. El
control de los lazos y las ramificaciones deberán estar (en lo posible) relacionados de forma simple con los parámetros
de entrada. El programa debería dividirse en módulos adecuadamente pequeños y la interacción entre los mismos deberá ser explícita. Deberán utilizarse características del lenguaje de programación que favorezcan la aproximación anterior
en preferencia de otras que son (pretendidamente) más eficientes, excepto cuando la eficiencia tiene prioridad absoluta
(por ejemplo, algunos sistemas críticos de seguridad).
Referencias
Una Disciplina de Programación. E W Dijkstra, Englewood Cliffs N J, Prentice-Hall, 1976.
Valoración de una Clase de Herramientas Software. M A Hennell et al, 7th International conference on Software
Engineering, March 1984, Orlando.
Una Herramienta Software para la Programación Arriba-abajo. D C Ince, Software − Practice and Experience, Vol 13,
No 8, August 1983.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 102 -
B.62 Lenguajes de Programación Adecuados (Referenciada por D.4)
Objetivo
Soportar los requisitos de esta norma tanto como sea posible, en particular la programación defensiva, fuerte tipado,
programación estructurada y posibles verificaciones. El lenguaje de programación elegido debería dar lugar a un código
fácilmente verificable con un mínimo esfuerzo y facilitar el desarrollo, verificación y mantenimiento del programa.
Descripción
El lenguaje debería estar total e inequívocamente definido. El lenguaje debería estar orientado al usuario o al problema
más que a la máquina. Se prefieren lenguajes ampliamente utilizados, o subconjuntos de los mismos, a lenguajes de
propósito especial.
Además de las características ya mencionadas, el lenguaje debería proporcionar:
− estructura de bloque;
− comprobación en tiempo de traducción;
− comprobación de tipos y límites de arrays en tiempo de ejecución; y
− comprobación de parámetros.
El lenguaje deberá favorecer:
− el uso de módulos pequeños y manejables;
− restricción de acceso a datos en módulos definidos;
− definición de sub-rangos de variables;
− cualquier otro tipo de construcciones para limitar errores.
Es deseable que el lenguaje esté soportado por un traductor adecuado, librerías apropiadas de módulos pre-existentes,
un depurador y herramientas para control de versiones y desarrollo.
Características que hacen difícil la verificación y por tanto deberían evitarse son:
− saltos incondicionales, excluyendo las llamadas a subrutinas;
− recursividad;
− punteros, memoria de uso dinámico o cualquier tipo de variables u objetos dinámicos;
− manejo de interrupciones a nivel de código fuente;
− entradas o salidas múltiples de lazos, bloques o subprogramas;
− inicialización o declaración implícita de variables;
− estructuras de datos dinámicas y equivalencia; y
− parámetros procedurales.
Lenguajes de bajo nivel, en particular de tipo ensamblador, presentan problemas debido a que están orientados a la
máquina.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 103 -
EN 50128:2001
B.63 Ejecución Simbólica (Referenciada por D.8)
Objetivo
Mostrar el acuerdo entre el código fuente y la especificación.
Descripción
Se ejecuta el programa sustituyendo el lado izquierdo por el derecho en todas las asignaciones. Las ramificaciones condicionales y los lazos se traducen a sus expresiones booleanas. El resultado final es una expresión simbólica para cada
variable del programa. Esto puede contrastarse con la expresión esperada.
Referencias
Verificación Formal de Programas por medio de Ejecución Simbólica. R.B. Dannenberg and G.W. Ernst, IEEE Trans
Software Engineering, Vol. SE-8, No 1, 1982.
Ejecución Simbólica y Ensayos del Software. J.C. King, Comm. ACM, Vol. 19, No 7, 1976.
B.64 Redes de Petri Temporales (Referenciada por D.5 y D.7)
Objetivo
Modelar aspectos relevantes del comportamiento del sistema y valorar y posiblemente mejorar la seguridad y los requisitos funcionales a través del análisis y rediseño.
Descripción
Las redes de Petri pertenecen a una clase de modelos gráficos teóricos que son adecuados para representar el flujo de
información y control en sistemas que presentan concurrencia y comportamiento asíncrono.
Una red de Petri es una malla de lugares y transiciones. Los lugares pueden estar 'marcados' o 'sin marcar'. Una transición está 'autorizada' cuando todos los lugares de entrada a la misma están marcados. Una vez autorizada, se permite
(pero no se obliga) que se 'dispare'. Si se dispara, las marcas de entrada se quitan y en su lugar se marca cada lugar
salida de la transición.
Las amenazas potenciales pueden representarse como estados particulares (marcas) en el modelo. Las redes de Petri
ampliadas permiten modelar características temporales del sistema. Aunque las redes de Petri 'clásicas' se concentran en
los aspectos del flujo de control, se han propuesto varias ampliaciones para incorporar el flujo de datos al modelo.
Referencias
Teoría de Redes y Aplicaciones. W. Brauer (ed), Lecture Notes in Computer Science, Vol. 84, Springer 1980.
Teoría de las Redes de Petri y Modelado de Sistemas. J.L. Peterson, Prentice Hall, 1981.
Análisis de Seguridad utilizando Redes de Petri. N. Leveson and J. Stolzy, Proc. FTCS 15, Ann Arbor, Michigan, June
1985, IEEE 1985.
Una Herramienta para la Especificación de Requisitos y el Análisis de Software en Tiempo Real basada en las Redes de
Petri Temporales. S. Bologna, F. Pisacane, C Ghezzi, D. Mandrioli, Proc. SAFECOMP 88, 9-11 Nov. 1988, Fulda Fed.
Rep. of Germany 1988.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 104 -
B.65 Traductor(es) Probado(s) por el uso (Referenciada por el capítulo 10)
Objetivo
Evitar cualquier dificultad debido a fallos del traductor que pueden aparecer durante el desarrollo, verificación y mantenimiento de un paquete software.
Descripción
Se utiliza un traductor que se ha demostrado que se comporta correctamente en muchos proyectos. Traductores sin
experiencia operativa o con errores serios conocidos están prohibidos.
Si el traductor tiene deficiencias pequeñas conocidas, las construcciones del lenguaje afectadas se anotan y evitadas
cuidadosamente durante el proyecto de seguridad.
Otra versión de esa forma de trabajar es restringir el uso del lenguaje a sus prestaciones utilizadas normalmente.
Esta recomendación se basa en la experiencia de muchos proyectos. Se ha demostrado que traductores inmaduros son
un serio impedimento en cualquier desarrollo software. Hacen generalmente impracticable un desarrollo software relacionado con la seguridad.
También es conocido que, actualmente, no existe método que pruebe la corrección de todas las partes de un compilador.
B.66 Ensayos/Revisiones de diseño (Referenciada por D.8)
Objetivo
Detectar errores en algún producto del proceso de desarrollo tan pronto y tan económicamente como sea posible.
Descripción
El TC 56 de CEI ha publicado una Guía de Revisiones de Diseño Formales, que incluye una descripción general de las
mismas, sus objetivos, detalles de varios tipos de revisiones de diseño, la composición de un equipo de revisión de diseño y sus trabajos y responsabilidades asociadas. El documento CEI proporciona también pautas generales para la planificación y gestión de las revisiones de diseño formales, así como detalles específicos relativos al papel de especialistas
independientes dentro de un equipo de revisión de diseño. Ejemplos de las funciones de los especialistas, incluyen entre
otras Fiabilidad, Soporte de Mantenimiento y Disponibilidad.
CEI recomienda que "se deberán realizar una revisión de diseño formal para todo nuevo producto/proceso, nuevas aplicaciones, y revisiones de productos existentes y procesos de fabricación que afecten a la función, prestaciones, seguridad, fiabilidad, capacidad de inspeccionar la mantenibilidad, disponibilidad, capacidad - coste, y otras características
que influyan en el producto/proceso final, usuarios o espectadores".
Un ensayo a través del código consiste en un equipo al efecto que selecciona un pequeño conjunto de casos de ensayo,
conjuntos representativos de entradas y las correspondientes salidas esperadas del programa. Los datos de ensayo son
seguidos manualmente a través de la lógica del programa.
Referencias
El Arte de Ensayar Software. G. Myers, Wiley & Sons, New York, 1979.
Guía de Fiabilidad y Mantenibilidad para Revisiones de Diseño Formales (Borrador). International Electrotechnical
Commission, Technical Committee No 56, January 1988.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 105 -
EN 50128:2001
B.67 Lógica Borrosa (Referenciada por el capítulo 10)
Objetivo
La Lógica Borrosa es una disciplina matemática basada en la teoría de conjuntos borrosos que permite grados de verdad
y falsedad. Es una generalización de la lógica de dos niveles que proporciona un modelo para el razonamiento aproximado. Permite la incorporación de inteligencia humana en sistemas automáticos. Reconociendo la dificultad de definir
fronteras precisas, la Lógica Borrosa reduce la precisión requerida, y por tanto lleva a soluciones sencillas de alto nivel
que son fáciles de controlar.
Descripción
La parte esencial de una solución basada en Lógica Borrosa es un conjunto de reglas lingüísticas (reglas SI - ENTONCES) donde los antecedentes y consecuentes están asociados con conjuntos borrosos.
EJEMPLO: SI la velocidad es rápida y la distancia de parada es media
ENTONCES el acelerador está casi a cero y el frenado es suave
En este ejemplo, "velocidad" es una variable lingüística caracterizada por un conjunto borroso "rápida", que puede interpretarse como "velocidad por encima de 70 km/h". Si la velocidad es inferior a 60 km/h, el valor del contenido de
"rápida " es cero. Si la velocidad es superior a 80 km/h, el valor del contenido de "rápida" es 1. Si la velocidad está
entre 60 km/h y 80 km/h, el valor del contenido de "rápida" varía entre 0 y 1.
La lógica del proceso de selección se basa en clases matemáticas de operadores: las normas triangulares y las co-normas
triangulares.
Los sistemas basados en reglas de Lógica Borrosa difieren de otros sistemas expertos en muchos sentidos: (1) un menor
número de reglas, (2) el uso de encadenamiento hacia delante solamente, (3) no encadenamiento de inferencias (todas
las reglas se ejecutan en paralelo en una iteración), (4) las reglas definidas estadísticamente, (5) la velocidad de ejecución debida a la simplicidad de las soluciones, y (6) el determinismo.
Durante los últimos pocos años, la Lógica Borrosa ha encontrado numerosas aplicaciones en campos que van desde las
finanzas a la ingeniería de terremotos. En particular, el control borroso ha empezado a emerger para controlar sistemas
altamente no lineales, o sistemas cuya descripción matemática es desconocida o demasiado compleja para ser tratada
analíticamente, o sistemas en los que las mediciones disponibles son de poca calidad.
Aplicaciones notables de la lógica borrosa incluyen el control de vuelo de aeronaves y sistemas de potencia y control de
reactores nucleares. Más recientemente, el control borroso se ha aplicado con éxito a los sistemas de operación de trenes
automáticos.
Referencias
Conjuntos Borrosos: Zadeh. Información y Control, 1965, Vol 8, pp 338-353.
Lógica Borrosa en Sistemas de Control: Controlador Lógico Borroso, Parte I y II. Chuen Chien Lee. IEEE Transactions
on systems, man, and cybernetics, Vol. 20, No 2, March/April 1990.
Aplicaciones Industriales del Control Borroso: M.Sugeno Ed., Amsterdam North Holland, 1985.
Sistemas de Operación de Trenes Automáticos mediante Control Borroso Predictivo: Yasunobu, Miyamoto, in
Industrial Applications of Fuzzy Control, M.Sugeno Ed., Amsterdam North Holland, 1985.
Un método de operación automático para el control de barras en las plantas de BWR: Kinoshita, Fukusaki, Satoh,
Miyake, Proc. Specialists Meeting on In-Core Instrumentation and Reactor Core Assessment. Cadarache, France 1988.
Uso de sistemas basados en reglas para el control de procesos. Bernard. IEEE Contr. Syst. Mag., Vol.8, No.5, pp.3-13,
1988.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
EN 50128:2001
- 106 -
B.68 Programación Orientada a Objetos (Referenciada por el capítulo 10)
Objetivo
Permitir un rápido prototipado, reutilizar más fácilmente componentes software existentes, conseguir el ocultamiento de
la información, reducir la probabilidad de errores durante el ciclo de vida completo, reducir el esfuerzo necesario durante la fase de mantenimiento, descomponer problemas complejos en problemas pequeños más fácilmente manejables,
reducir las dependencias entre componentes software, crear aplicaciones más fácilmente ampliables.
Descripción
La programación orientada a objetos es fundamentalmente una nueva forma de pensar acerca del software basada en
abstracciones que existen en el mundo real más que en las abstracciones del mundo de los ordenadores. La programación orientada a objetos organiza el software como una colección de objetos que incorporan estructura de datos y comportamiento. Esto contrasta con la programación convencional donde la estructura de datos y el comportamiento están
solo débilmente conectados.
Objeto: Un objeto consta de un área de datos privada y un conjunto de operaciones - llamadas métodos - sobre ese objeto. Los métodos pueden ser públicos o privados. No está permitido que ningún otro componente software lea o cambie
los datos privados de un objeto directamente. Cada uno de los demás componentes software tiene que utilizar los métodos públicos sobre ese objeto para leer o escribir datos en el área privada de un objeto.
Clase del Objeto: Mediante la especificación de la clase del objeto (a menudo en forma de una definición de tipo) se
permite la instanciación de numerosos objetos de la misma clase, es decir, todas las instanciaciones tienen el área de
datos privados y los métodos definidos en la clase del objeto.
Herencia (múltiple): Un objeto puede heredar el área de datos privados y los métodos de una (o más) superclases (clases
de objeto por encima en la jerarquía de clase) permitiéndose añadir algunos datos privados, algunos métodos o modificar las implementaciones de los métodos heredados. Utilizando la Herencia múltiple pueden construirse árboles de clase
de objeto.
Polimorfismo: La misma operación se puede comportar de forma diferente en diferentes clase de objeto, por ejemplo,,
la operación de escritura sobre un objeto terminal escribe caracteres en ese terminal y la operación de escritura sobre un
fichero escribe caracteres en ese fichero.
Referencias
Construcciones Software Orientadas a Objetos. Bertrand Meyer, England: Prentice Hall International, 1988.
La Clasificación como paradigma del cálculo. Peter Wegner, Technical Report CS-86-11, Brown University, May 1986.
Aprendizaje del lenguaje. Peter Wegner, Byte (McGraw-Hill publication) March 1989.
Todo sobre SPOOLA (Sistemas de Programación Orientada a Objetos, Lenguajes y Aplicaciones) y CEPOO (Conferencia Europea sobre Programación Orientada a Objetos), conference proceedings.
B.69 Trazabilidad (Referenciada por el capítulo 11)
Objetivo
El objetivo de la Trazabilidad es asegurar que puede demostrarse que todos los requisitos han sido conseguidos de forma adecuada y que no se ha introducido material no trazable.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
- 107 -
EN 50128:2001
Descripción
Los requisitos de trazabilidad deberán ser una consideración importante en la validación de un sistema y se deberán
proporcionar medios que permitan demostrarlo a lo través de todas las fases del ciclo de vida.
La trazabilidad se deberá considerar aplicable tanto a los requisitos funcionales como no funcionales y deberá considerar en particular la:
a) trazabilidad de los requisitos con respecto al diseño u otros objetos que los satisfagan;
b) trazabilidad de los objetos del diseño a los objetos de la implementación que los instancien;
c) trazabilidad de los requisitos y objetos del diseño a los objetos operacionales y de mantenimiento que requieren ser
aplicados para un uso adecuado y seguro del sistema;
d) trazabilidad de los objetos de requisitos, diseño, operación y mantenimiento a los planes de verificación y ensayos y
especificaciones que determinen su aceptación;
e) trazabilidad de los planes de verificación y ensayos y especificaciones a el ensayo u otros informes que registren los
resultados de su aplicación.
Cuando los objetos de requisitos, diseño u otros se instancian como un número de documentos separados, se deberá
mantener la trazabilidad dentro del documento y de forma jerárquica.
La salida del proceso de Trazabilidad deberá ser el objeto de la Gestión de Configuración formal.
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795
Dirección
C Génova, 6
28004 MADRID-España
Teléfono 91 432 60 00
Fax 91 310 40 32
Licensed to !SYSTRA by SAI Global Ltd. Downloaded as a single PDF on 30 Mar 12 A01282795