UNE-En 50128 2012

norma españolla

UN NE-EN 50128

Marzo 2012 TÍTULO

Aplicaaciones ferroviarias Sistem mas de comunicación, señalización y proccesamiento Softw ware para sistemas de control y protección n del ferrocarril

Railway applications. a Communication, signalling and processing systems. Sofftware for railway control and protectionn systems. Applicatioons ferroviaires. Systèmes de signalisation, de télécommunication ett de traitement. Logiciels pour systèmes de d commande et de protection ferroviaire.

CORRESPONDENCIA

Esta norrma es la versión oficial, en español, de la Norma Europpea EN 50128:2011.

OBSERVACIONES

Esta norrma anulará y sustituirá a las Normas UNE-EN 50128:22002 y UNE-EN N 50128:2002 Corr:2010 antes de 2014-04-25.

ANTECEDENTES

Esta noorma ha sido elaborada por el comité técnico AEN/C CTN 203 Equipamiento eléctricoo y sistemas automáticos para la industria cuya Secretaría desempeña SERCO OBE.

Editada e impresa por AENOR Depósito legal: M 11508:2012

LAS OBSE ERVACIONES A ESTE DOCUMENTO HAN DE DIRIGIRSE A:

© AENOR 2012 Reproducción prohibida

132 Páginas Génova, 6 28004 MADRID-Españña

[email protected] www.aenor.es

Tel.: 902 102 201 Fax: 913 104 032

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

NORMA EUROPEA EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM

EN 50128 Junio 2011

ICS 35.240.60; 45.020; 93.100

Sustituye a EN 50128:2001

Versión en español

Aplicaciones ferroviarias Sistemas de comunicación, señalización y procesamiento Software para sistemas de control y protección del ferrocarril

Railway applications. Communication, 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.

Bahnanwendungen. Telekommunikationstechnik, Signaltechnik und Datenverarbeitungssysteme. Software für Eisenbahnsteuerungs- und Überwachungssysteme.

Esta norma europea ha sido aprobada por CENELEC el 2011-04-25. 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, Bulgaria, Chipre, Croacia, Dinamarca, Eslovaquia, Eslovenia, España, Estonia, Finlandia, Francia, Grecia, Hungría, Irlanda, Islandia, Italia, Letonia, Lituania, Luxemburgo, Malta, Noruega, Países Bajos, Polonia, Portugal, Reino Unido, República Checa, Rumanía, 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: Avenue Marnix, 17-1000 Bruxelles © 2011 CENELEC. Derechos de reproducción reservados a los Miembros de CENELEC.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

-4-

ÍNDICE Página PRÓLOGO .............................................................................................................................................. 8 INTRODUCCIÓN ................................................................................................................................... 9 1

OBJETO Y CAMPO DE APLICACIÓN ........................................................................... 12

2

NORMAS PARA CONSULTA ........................................................................................... 13

3 3.1 3.2

TÉRMINOS, DEFINICIONES Y ABREVIATURAS ...................................................... 13 Términos y definiciones ....................................................................................................... 13 Abreviaturas ......................................................................................................................... 17

4

OBJETIVOS, CONFORMIDAD Y NIVELES DE INTEGRIDAD DE SEGURIDAD DEL SOFTWARE ................................................................................ 18

5 5.1 5.2 5.3

GESTIÓN Y ORGANIZACIÓN DEL DESARROLLO DEL SOFTWARE .................. 19 Organización, roles y responsabilidades ............................................................................ 19 Competencia del personal .................................................................................................... 23 Etapas del ciclo de vida y documentación .......................................................................... 24

6 6.1 6.2 6.3 6.4 6.5 6.6 6.7

GARANTÍA DEL SOFTWARE ......................................................................................... 26 Ensayos del Software............................................................................................................ 26 Verificación del software ..................................................................................................... 28 Validación del Software ....................................................................................................... 30 Evaluación del software ....................................................................................................... 32 Garantía de calidad del software ........................................................................................ 34 Modificaciones y control de las modificaciones ................................................................. 36 Herramientas de soporte y lenguajes .................................................................................. 37

7 7.1 7.2 7.3 7.4 7.5 7.6 7.7

DESARROLLO DE SOFTWARE GENÉRICO ............................................................... 41 Ciclo de vida y documentación para software genérico .................................................... 41 Requisitos del Software ........................................................................................................ 41 Arquitectura y diseño ........................................................................................................... 44 Diseño de componentes ........................................................................................................ 51 Implementación y ensayos de componentes ....................................................................... 53 Integración ............................................................................................................................ 55 Ensayos del Software en Conjunto / Validación Final ...................................................... 57

8 8.1 8.2 8.3 8.4

DESARROLLO DE LOS DATOS O ALGORITMOS DE APLICACIÓN: SISTEMAS CONFIGURADOS MEDIANTE DATOS O ALGORITMOS DE APLICACIÓN ................................................................................... 59 Objetivos ............................................................................................................................... 59 Documentos de entrada........................................................................................................ 60 Documentos de salida ........................................................................................................... 60 Requisitos .............................................................................................................................. 60

9 9.1 9.2

IMPLANTACIÓN Y MANTENIMIENTO DEL SOFTWARE ...................................... 65 Implantación del software ................................................................................................... 65 Mantenimiento del Software ............................................................................................... 67

ANEXO A (Normativo) A.1 A.2

CRITERIOS PARA LA SELECCIÓN DE TÉCNICAS Y MEDIDAS ............................................................................................. 71 Tablas de capítulos ............................................................................................................... 72 Tablas detalladas .................................................................................................................. 78

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

-5-

ANEXO B (Normativo)

EN 50128:2011

ROLES PRINCIPALES Y RESPONSABILIDADES RELATIVAS AL SOFTWARE .............................................................. 84

ANEXO C (Informativo) RESUMEN DEL CONTROL DE LOS DOCUMENTOS .................... 91 ANEXO D (Informativo) BIBLIOGRAFÍA DE LAS TÉCNICAS ................................................. 93 D.1 Inteligencia Artificial: Corrección de Errores ................................................................... 93 D.2 Programas Analizables ........................................................................................................ 93 D.3 Ensayos de Avalancha/Ensayos de Sobrecarga ................................................................. 94 D.4 Análisis de los Valores Límite ............................................................................................. 94 D.5 Recuperación Regresiva....................................................................................................... 95 D.6 Diagramas de Causa Efecto ................................................................................................. 95 D.7 Listas de Comprobación ...................................................................................................... 95 D.8 Análisis de Flujos de Control............................................................................................... 96 D.9 Análisis de Fallos de Causa Común .................................................................................... 96 D.10 Análisis del flujo de datos .................................................................................................... 97 D.11 Diagramas de Flujo de Datos............................................................................................... 97 D.12 Registro y análisis de los datos ............................................................................................ 98 D.13 Tablas de Decisión (Tablas de Verdad) .............................................................................. 99 D.14 Programación Defensiva ...................................................................................................... 99 D.15 Normas de Codificación y Guía de Estilo ......................................................................... 100 D.16 Programación con Múltiples Versiones ............................................................................ 100 D.17 Reconfiguración Dinámica ................................................................................................ 101 D.18 Ensayos de Clases de Equivalencia y de Partición de Entradas ..................................... 101 D.19 Códigos de Detección y Corrección de Errores ............................................................... 102 D.20 Suposición de Errores ........................................................................................................ 102 D.21 Inserción de Errores ........................................................................................................... 103 D.22 Análisis por Árbol de Eventos ........................................................................................... 103 D.23 Inspecciones de Fagan ........................................................................................................ 103 D.24 Programación con Aserciones ........................................................................................... 104 D.25 AEES. Análisis de los Efectos de los Errores del Software ............................................. 104 D.26 Detección de Errores y Diagnóstico .................................................................................. 105 D.27 Máquinas de Estados Finitos/Diagramas de Transición de Estado ............................... 105 D.28 Métodos Formales .............................................................................................................. 106 D.29 Demostración Formal......................................................................................................... 111 D.30 Recuperación Anticipada ................................................................................................... 112 D.31 Sistema Tolerante a Errores .............................................................................................. 112 D.32 Análisis de Impacto ............................................................................................................ 112 D.33 Ocultación de Información/Encapsulamiento.................................................................. 113 D.34 Ensayos de Interfaz ............................................................................................................ 113 D.35 Subconjunto del Lenguaje ................................................................................................. 114 D.36 Memorización de Casos Ejecutados.................................................................................. 114 D.37 Métricas ............................................................................................................................... 114 D.38 Enfoque Modular ............................................................................................................... 115 D.39 Modelado de las Prestaciones ............................................................................................ 115 D.40 Requisitos de las Prestaciones ........................................................................................... 116 D.41 Ensayos Probabilísticos ...................................................................................................... 117 D.42 Simulación de Procesos ...................................................................................................... 117 D.43 Prototipado/Animación ...................................................................................................... 118 D.44 Bloque de Recuperación .................................................................................................... 118 D.45 Tiempo de Respuesta y Limitaciones de Memoria .......................................................... 118 D.46 Mecanismos de Recuperación de Errores por Reintento ................................................ 119 D.47 Bolsa de Seguridad ............................................................................................................. 119 D.48 Gestión de la Configuración del Software ........................................................................ 119 D.49 Lenguajes de Programación Fuertemente Tipados ......................................................... 120 D.50 Ensayos Basados en la Estructura .................................................................................... 120 D.51 Diagramas de Estructura ................................................................................................... 121

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

D.52 D.53 D.54 D.55 D.56 D.57 D.58 D.59 D.60 D.61 D.62 D.63 D.64 D.65 D.66 D.67 D.68 D.69 D.70 D.71

-6-

Metodología Estructurada ................................................................................................. 121 Programación Estructurada .............................................................................................. 122 Lenguajes de Programación Adecuados........................................................................... 122 Redes de Petri Temporizadas ............................................................................................ 123 Revisión del Proyecto Estructurado/Revisión del Diseño ............................................... 124 Programación Orientada a Objetos .................................................................................. 124 Trazabilidad ........................................................................................................................ 125 Metaprogramación ............................................................................................................. 125 Programación por procedimientos ................................................................................... 126 Diagramas Secuenciales de Función (SFC, Sequential Function Charts) ...................... 126 Diagrama Ladder o en Escalera......................................................................................... 127 Diagramas de Bloques Funcionales .................................................................................. 127 Diagrama de Estados.......................................................................................................... 127 Modelado de datos .............................................................................................................. 127 Diagramas de Flujo de Control/Grafo de Flujo de Control............................................ 128 Diagrama de secuencia ....................................................................................................... 129 Métodos de Especificación en Tablas ............................................................................... 129 Lenguaje específico para la aplicación ............................................................................. 130 UML Lenguaje Unificado de Modelado ........................................................................... 130 Lenguajes específicos de dominio...................................................................................... 131

BIBLIOGRAFÍA ................................................................................................................................. 132 Figuras Figura 1 – Ilustración de las Etapas Funcionales Sucesivas del Software ........................................ 11 Figura 2 – Ilustración de la estructura organizativa preferida ......................................................... 20 Figura 3 – Ciclo de Vida del Desarrollo del Software ejemplo 1 ....................................................... 25 Figura 4 – Ciclo de Vida del Desarrollo del Software ejemplo 2 ....................................................... 26 Tablas Tabla 1 – Relación entre las clases de herramientas y los apartados aplicables .............................. 41 Tabla A.1 – Temas Relativos al Ciclo de Vida y Documentación (5.3) ............................................. 72 Tabla A.2 – Especificación de Requisitos del Software (7.2) ............................................................. 73 Tabla A.3 – Arquitectura del Software (7.3) ....................................................................................... 74 Tabla A.4 – Diseño del Software e Implementación (7.4) .................................................................. 75 Tabla A.5 – Verificación y Ensayos (6.2 y 7.3) .................................................................................... 76 Tabla A.6 – Integración (7.6)................................................................................................................ 76 Tabla A.7 – Ensayos de Software en Conjunto (6.2 y 7.7) ................................................................. 76 Tabla A.8 – Técnicas de Análisis del Software (6.3) ........................................................................... 77 Tabla A.9 – Garantía de Calidad del Software (6.5) .......................................................................... 77 Tabla A.10 – Mantenimiento del Software (9.2) ................................................................................. 77 Tabla A.11 – Técnicas de Preparación de Datos (8.4) ........................................................................ 78 Tabla A.12 – Normas de Codificación ................................................................................................. 78 Tabla A.13 – Análisis y Ensayos Dinámicos ........................................................................................ 79

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

-7-

EN 50128:2011

Tabla A.14– Ensayos Funcionales/Ensayos de Caja Negra ............................................................... 79 Tabla A.15 – Lenguajes de programación textual .............................................................................. 80 Tabla A.16 – Lenguajes Diagramáticos para Algoritmos de Aplicación .......................................... 80 Tabla A.17 – Modelado ......................................................................................................................... 81 Tabla A.18 – Ensayos de las Prestaciones ........................................................................................... 81 Tabla A.19 – Análisis Estático .............................................................................................................. 81 Tabla A.20 – Componentes ................................................................................................................... 82 Tabla A.21 – Cobertura de los Ensayos para los Códigos ................................................................. 82 Tabla A.22 – Arquitectura del Software Orientada a Objetos .......................................................... 83 Tabla A.23 – Diseño Detallado Orientado a Objetos ......................................................................... 83 Tabla B.1 – Especificación del Rol del Gestor de Requisitos ............................................................. 84 Tabla B.2 – Especificación del Rol del Diseñador .............................................................................. 85 Tabla B.3 – Especificación del Rol del Implementador ..................................................................... 85 Tabla B.4 – Especificación del Rol del Encargado de los Ensayos .................................................... 86 Tabla B.5 – Especificación del Rol del Verificador ............................................................................ 86 Tabla B.6 – Especificación del Rol del Integrador ............................................................................. 87 Tabla B.7 – Especificación del Rol del Validador............................................................................... 88 Tabla B.8 – Especificación del Rol del Evaluador .............................................................................. 89 Tabla B.9 – Especificación del Rol del Jefe de Proyecto .................................................................... 90 Tabla B.10 – Especificación del Rol del Gestor de Configuración .................................................... 90 Tabla C.1 – Resumen del Control de los Documentos ....................................................................... 91

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

-8-

PRÓLOGO Esta norma europea fue preparada por el Subcomité SC 9XA, Sistemas de comunicación, señalización y procesamiento, del Comité Técnico TC 9X, Aplicaciones eléctricas y electrónicas para ferrocarriles, de CENELEC. El texto del proyecto fue sometido a voto formal y fue aprobado por CENELEC como Norma EN 50128 el 2011-04-25. Esta norma sustituye a la Norma EN 50128:2001. Los cambios principales con respecto a la Norma EN 50128:2001 son los siguientes: •

se han añadido requisitos sobre la organización y gestión, definición de roles y competencias, implantación y mantenimiento del software;

•

se ha añadido un capítulo nuevo sobre herramientas, basado en la Norma EN 61508-2:2010;

•

se han actualizado las tablas del anexo A.

Se llama la atención sobre la posibilidad de que algunos de los elementos de este documento estén sujetos a derechos de patente. CEN y CENELEC no son responsables de la identificación de dichos derechos de patente. Se fijaron las siguientes fechas: − Fecha límite en la que la norma europea debe adoptarse a nivel nacional por publicación de una norma nacional idéntica o por ratificación

(dop)

2012-04-25

− Fecha límite en la que deben retirarse las normas nacionales divergentes con esta norma

(dow)

2014-04-25

Esta norma debería leerse conjuntamente con las Normas EN 50126-1:1999 "Aplicaciones ferroviarias. Especificación y demostración de la fiabilidad, de la mantenibilidad, de la disponibilidad y de la seguridad (RAMS). Parte 1: Requisitos básicos y procesos genéricos" y EN 50129:2003 "Aplicaciones ferroviarias. Sistemas de comunicación, señalización y procesamiento. Sistemas electrónicos relacionados con la seguridad para la señalización".

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

-9-

EN 50128:2011

INTRODUCCIÓN Esta norma forma parte de un grupo de normas relacionadas. Las otras normas son la Norma EN 50126-1:1999 "Aplicaciones ferroviarias. Especificación y demostración de la fiabilidad, de la mantenibilidad, de la disponibilidad y de la seguridad (RAMS). Parte 1: Requisitos básicos y procesos genéricos" y la Norma EN 50129:2003 "Aplicaciones ferroviarias. Sistemas de comunicación, señalización y procesamiento. Sistemas electrónicos relacionados con la seguridad para la señalización". La Norma EN 50126-1 considera los sistemas en su concepción más amplia, mientras que la Norma EN 50129 se refiere al proceso de homologación para sistemas particulares que pueden existir dentro de todo el sistema de protección y control del ferrocarril. Esta norma europea se concentra en los métodos que hay que utilizar para suministrar software que satisfaga los requisitos de integridad de la seguridad impuestos por consideraciones más amplias. Esta norma europea proporciona una serie de requisitos que se deben cumplir en el desarrollo, implantación y mantenimiento de cualquier software relacionado con la seguridad destinado a aplicaciones de control y protección de ferrocarriles. La norma define los requisitos relativos a la estructura organizativa, a la relación entre organizaciones y a la división de responsabilidades relativas a las actividades de desarrollo, implantación y mantenimiento. Esta norma europea proporciona además los criterios relativos a la cualificación, experiencia y competencia del personal. El concepto clave en esta norma europea es el de los niveles de integridad de seguridad del software. Esta norma europea identifica cinco niveles de integridad de seguridad del software, siendo 0 el nivel mínimo y 4 el máximo. Cuanto más peligrosas sean las consecuencias de un fallo del software, mayor será el nivel requerido de integridad de seguridad del software. Esta norma europea ha identificado técnicas y medidas para los cinco niveles de integridad de seguridad del software. En las tablas normativas del anexo A se muestran las técnicas y medidas requeridas para los niveles 0 a 4 de integridad de seguridad del software. En esta versión, las técnicas requeridas para el nivel 1 son las mismas que para el nivel 2 y las técnicas requeridas para el nivel 3 son las mismas que para el nivel 4. Esta norma europea no da indicaciones sobre qué nivel de integridad de seguridad del software es apropiado para un riesgo determinado. Esta decisión dependerá de muchos factores, incluyendo la naturaleza de la aplicación, del grado en que otros sistemas llevan a cabo funciones de seguridad y de factores sociales y económicos. Queda dentro del campo de aplicación de las Normas EN 50126-1 y EN 50129 el especificar las funciones de seguridad asignadas al software. Esta norma especifica las medidas necesarias para satisfacer dichos requisitos. Las Normas EN 50126-1 y EN 50129 requieren que se adopte un enfoque sistemático para: a) identificar peligros, evaluar riesgos y tomar decisiones en función de los criterios de riesgo; b) identificar la reducción de riesgo necesaria para cumplir con los criterios de aceptación de riesgos; c) definir una Especificación de Requisitos de Seguridad del Sistema global con las protecciones necesarias para conseguir la reducción de riesgo requerida; d) seleccionar una arquitectura del sistema adecuada; e) 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 validadas de integridad de seguridad. A medida que se descompone la especificación en un diseño que incluye sistemas y componentes relacionados con 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.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 10 -

El estado actual de la técnica es tal que ni la aplicación de métodos para garantizar la calidad (como las medidas para evitar y detectar errores) ni la aplicación de soluciones de software tolerante a errores, pueden garantizar la seguridad absoluta del sistema. No hay manera conocida para demostrar la ausencia de errores en un software relacionado con la seguridad razonablemente complejo, especialmente la ausencia de errores 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); – la modularidad; – la verificación de cada fase del ciclo de vida del desarrollo; – la verificación de los componentes y de las librerías de componentes; – una documentación y trazabilidad claras; – documentos auditables; – la validación; – la evaluación; – la gestión de la configuración y el control de las modificaciones; y – el estudio apropiado de las cuestiones de competencia del personal y de la organización. La Especificación de Requisitos de Seguridad del Sistema identifica todas las funciones de seguridad asignadas al software y determina el nivel de integridad de seguridad del sistema para dichas funciones. En la figura 1 se muestran las etapas funcionales sucesivas en la aplicación de esta norma europea y son las que se detallan a continuación: a) 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 de seguridad para el software y para el nivel de integridad de seguridad del software (7.2 y 7.3); b) diseño, desarrollo y ensayo del software de acuerdo con el Plan de Garantía de la Calidad del Software, el nivel de integridad de seguridad del software y el ciclo de vida del software (7.4 y 7.5); c) integrar el software en el hardware objetivo y verificar su funcionalidad (7.6); d) aceptar e implantar el software (7.7 y 9.1); e) si se requiere el mantenimiento del software durante su vida operativa, entonces se ha de reactivar esta norma europea según sea apropiado (9.2). Durante el desarrollo del software se realizan varias actividades. Éstas incluyen: ensayos (6.1), verificación (6.2), validación (6.3), evaluación (6.4), aseguramiento de la calidad (6.5) y modificación y control de las modificaciones (6.6). Se establecen requisitos para herramientas de soporte (6.7) y para sistemas configurados mediante datos de aplicación o algoritmos (capítulo 8). Se establecen también requisitos en lo que concierne a la independencia de roles y a la competencia del personal implicado en el desarrollo del software (5.1, 5.2 y anexo B). Esta norma europea no obliga a utilizar un ciclo de vida específico para el desarrollo del software. Sin embargo, en los apartados 5.3 y 7.1, así como en las figuras 3 y 4 se proporcionan ciclos de vida y conjuntos de documentación a modo ilustrativo.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 11 -

EN 50128:2011

Se han formulado tablas clasificando varias técnicas/medidas en relación a los niveles 0 a 4 de inteegridad de seguridad del software. Las tablas se encuentran en el anexo A. Hay una bibliografía referenciada en las tablaas y ofrece una breve descripción de cada técnica/medida con refeerencias a fuentes de información adicionales. La biblioggrafía de las técnicas se encuentra en el anexo D.

Figura 1 – Ilustración n de las Etapas Funcionales Sucesivas del Software

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 12 -

1 OBJETO Y CAMPO DE APLICACIÓN 1.1 Esta norma europea especifica los procedimientos y requisitos técnicos para el desarrollo de software para sistemas electrónicos programables para su uso en aplicaciones de control y protección del ferrocarril. Se puede aplicar en cualquier área del ferrocarril que tenga relación con la seguridad. 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 europea se aplica exclusivamente al software y a la interacción entre el software y el sistema del que forma parte. 1.3 Esta norma europea no es relevante para software que no tenga impacto en la seguridad, es decir, software cuyos fallos no afecten a funciones de seguridad identificadas. 1.4 Esta norma europea se aplica a todo el software relacionado con la seguridad utilizado en sistemas de control y protección del ferrocarril, incluyendo: – programación de aplicaciones; – sistemas operativos; – herramientas de soporte; – firmware. La programación de aplicaciones comprende la programación de alto nivel, de bajo nivel y la programación de propósito específico (por ejemplo, el controlador lógico programable de lenguaje ladder o en escalera). 1.5 Esta norma europea contempla también el uso de software y herramientas preexistentes. Dicho software puede utilizarse, si se cumplen los requisitos específicos de los apartados 7.3.4.7 y 6.5.4.16 relativos a software preexistente y del apartado 6.7 relativo a herramientas. 1.6 El software que se haya desarrollado de acuerdo con cualquier versión de esta norma europea se considerará conforme y no estará sujeto a los requisitos relativos a software preexistente. 1.7 Esta norma europea considera que el diseño moderno de aplicaciones utiliza a menudo software genérico que resulta adecuado como base para diversas aplicaciones. Dicho software genérico se configura después mediante datos, algoritmos, o ambos, para producir el software ejecutable para la aplicación. Los capítulos generales del 1 al 6, así como el capítulo general 9 de esta norma europea se aplican al software genérico y a datos de aplicación o algoritmos de aplicación. El capítulo específico 7 se aplica sólo al software genérico mientras que el capítulo 8 describe los requisitos específicos para los datos de aplicación y los algoritmos de aplicación. 1.8 Esta norma europea no tiene como objetivo tratar cuestiones comerciales. Dichas cuestiones deberían formar parte esencial de los acuerdos contractuales. Será necesario considerar cuidadosamente cada capítulo de esta norma europea en cualquier situación comercial. 1.9 Esta norma europea no pretende tener carácter retroactivo. Por lo tanto, se aplica principalmente a nuevos desarrollos y sólo se aplica en su totalidad a sistemas existentes si estos se someten a modificaciones importantes. Para modificaciones menores, solamente se aplica el apartado 9.2. El evaluador ha de analizar las pruebas proporcionadas en la documentación del software para confirmar si la determinación de la naturaleza y la extensión de las modificaciones del software son adecuadas. Sin embargo, es muy recomendable la aplicación de esta norma europea durante las actualizaciones y el mantenimiento del software existente.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 13 -

EN 50128:2011

2 NORMAS PARA CONSULTA Las normas que a continuación se indican son indispensables para la aplicación de esta norma. Para las referencias con fecha, solo se aplica la edición citada. Para las referencias sin fecha se aplica la última edición de la norma (incluyendo cualquier modificación de ésta). EN 50126-1:1999 Aplicaciones ferroviarias. Especificación y demostración de la fiabilidad, la disponibilidad, la mantenibilidad y la seguridad (RAMS). Parte 1: Requisitos básicos y procesos genéricos. EN 50129:2003 Aplicaciones ferroviarias. Sistemas de comunicación, señalización y procesamiento. Sistemas electrónicos relacionados con la seguridad para la señalización. EN ISO 9000 Sistemas de gestión de la calidad. Fundamentos y vocabulario. (ISO 9000:2005). EN ISO 9001 Sistemas de gestión de la calidad. Requisitos. (ISO 9001:2008). ISO/IEC 90003:2004 Ingeniería del software. Guía de aplicación de la ISO 9001:2000 al software. ISO/IEC 9126, serie Ingeniería del software. Calidad del producto software. 3 TÉRMINOS, DEFINICIONES Y ABREVIATURAS 3.1 Términos y definiciones Para los fines de este documento, se aplican los términos y definiciones siguientes: 3.1.1 evaluación: Proceso de análisis para determinar si el software, que puede incluir procesos, documentación, hardware del sistema o del subsistema y/o componentes software, cumple los requisitos especificados y para formar un juicio sobre si el producto es apto para su propósito previsto. La evaluación de la seguridad se centra pero no se limita a las propiedades de seguridad de un sistema. 3.1.2 evaluador: Entidad encargada de realizar una evaluación. 3.1.3 software comercial, COTS (Commercial Off-The-Shelf): Software definido por las necesidades del mercado, disponible comercialmente y cuya validez ha sido demostrada por un amplio espectro de usuarios comerciales. 3.1.4 componente: Parte constituyente del software que tiene interfaces y un comportamiento bien definidos en relación a la arquitectura y diseño del software y que cumple los siguientes criterios: – se diseña de acuerdo con los "Componentes" (véase la tabla A.20); – cubre un conjunto específico de requisitos para el software; – se identifica claramente y tiene una versión independiente dentro del sistema de gestión de la configuración o es parte de una colección de componentes (por ejemplo, los subsistemas) que cuentan con una versión independiente. 3.1.5 gestor de configuración: Entidad responsable de implementar y realizar los procesos para la gestión de la configuración de los documentos, del software y de las herramientas relacionadas, incluyendo la gestión de las modificaciones. 3.1.6 cliente: Entidad que compra un sistema de control y protección del ferrocarril que incluye el software.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 14 -

3.1.7 diseñador: Entidad que analiza y transforma los requisitos especificados en soluciones de diseño aceptables que tengan el nivel de integridad de seguridad requerido. 3.1.8 entidad: Persona, grupo u organización que desempeña uno de los roles definidos en esta norma europea. 3.1.9 error: Defecto, error o imprecisión que podrían resultar en un fallo o en una desviación de las prestaciones o del comportamiento previstos. 3.1.10 fallo: Diferencia inaceptable entre las prestaciones requeridas y las observadas. 3.1.11 tolerancia a errores: Capacidad integrada de un sistema para mantener una ejecución correcta continua del servicio especificado, en presencia de un número limitado de errores del hardware o del software. 3.1.12 firmware: Software almacenado en la memoria rom o en un dispositivo de almacenamiento semipermanente como una memoria flash, de forma que es funcionalmente independiente del software de aplicación. 3.1.13 software genérico: Software que puede utilizarse para varios tipos de instalaciones, simplemente suministrándole los datos y/o algoritmos específicos para la aplicación. 3.1.14 implementador: Entidad que transforma los diseños especificados en sus realizaciones físicas. 3.1.15 integración: Proceso de ensamblaje de elementos de software y/o hardware, de acuerdo con la especificación de arquitectura y de diseño, y de realización de ensayos en la unidad ensamblada. 3.1.16 integrador: Entidad que lleva a cabo la integración del software. 3.1.17 software preexistente: Software desarrollado antes de la aplicación en cuestión, incluyendo el software comercial COTS y el software de código abierto. 3.1.18 software de código abierto: Código fuente disponible al público general con restricciones de derechos de autor de carácter flexible o inexistentes. 3.1.19 controlador lógico programable: Sistema de control informatizado que cuenta con una memoria programable por el usuario para el almacenamiento de instrucciones para implementar funciones específicas. 3.1.20 dirección de un proyecto: Dirección técnica y/o administrativa de un proyecto, incluidos los aspectos de seguridad. 3.1.21 jefe de proyecto: Entidad encargada de realizar la dirección de un proyecto. 3.1.22 fiabilidad: Capacidad de un elemento para realizar una función requerida en condiciones determinadas durante un intervalo de tiempo determinado.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 15 -

EN 50128:2011

3.1.23 robustez: Capacidad de un elemento para detectar y gestionar las situaciones anormales. 3.1.24 gestor de requisitos: Entidad que lleva a cabo la gestión de requisitos. 3.1.25 gestión de requisitos: Proceso de obtención, documentación, análisis, clasificación por orden de prioridad y aceptación mediante acuerdo de los requisitos, y posterior control de las modificaciones y comunicación con las partes interesadas. Es un proceso continuo a lo largo de un proyecto. 3.1.26 riesgo: Combinación de la frecuencia de ocurrencia de accidentes e incidentes que ocasionan un daño (causados por una situación peligrosa) y el nivel de gravedad producido por dicho daño. 3.1.27 seguridad: Ausencia de niveles inaceptables de riesgo que pudieran producir daños a personas. 3.1.28 autoridad de seguridad: Organismo responsable de certificar que el software o los servicios relacionados con la seguridad cumplen los requisitos legales de seguridad pertinentes. 3.1.29 función de seguridad: Función que implementa un requisito de seguridad en parte o en su totalidad. 3.1.30 software relacionado con la seguridad: Software que realiza funciones de seguridad. 3.1.31 software: Creación intelectual que comprende los programas, procedimientos, reglas, datos y toda la documentación asociada en relación al funcionamiento de un sistema. 3.1.32 línea base del software: Conjunto completo y coherente de código fuente, archivos ejecutables, archivos de configuración, scripts de instalación y documentación necesario para la publicación de una versión de software. La información sobre compiladores, sistemas operativos, software preexistente y herramientas dependientes se almacena como parte de la línea base. La línea base permite a la organización reproducir versiones bien definidas y su uso como entrada para la publicación de futuras versiones con mejoras o actualizaciones realizadas dentro de la fase de mantenimiento. 3.1.33 implantación del software: Transferencia, instalación y activación de una línea base del software correspondiente a una versión ya publicada y evaluada. 3.1.34 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 estar disponible para su uso. El ciclo de vida del software incluye normalmente una fase de requisitos, una fase de diseño, una fase de ensayos, una fase de integración, una fase de implantación y una fase de mantenimiento. 3.1.35 mantenibilidad del software: Capacidad para poder modificar un software, para corregir sus errores, mejorar sus prestaciones u otros atributos, o adaptarlo a un entorno diferente. 3.1.36 mantenimiento del software: Acción, o conjunto de acciones, llevadas a cabo sobre el software después de su implantación con el objetivo de mejorar o corregir su funcionalidad.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 16 -

3.1.37 nivel de integridad de seguridad del software: Número de clasificación que determina las técnicas y medidas que tienen que aplicarse al software. NOTA El software relacionado con la seguridad se ha clasificado en cinco niveles de integridad de la seguridad, siendo 0 el nivel mínimo y 4 el máximo.

3.1.38 proveedor: Entidad que diseña y construye un sistema de control y protección del ferrocarril incluyendo el software o partes del mismo. 3.1.39 nivel de integridad de seguridad del sistema: Número de clasificación que indica el grado de confianza requerido sobre el hecho de que un sistema integrado, que comprende hardware y software, cumplirá con sus requisitos de seguridad especificados. 3.1.40 encargado de los ensayos: Entidad que realiza los ensayos. 3.1.41 ensayos: Proceso en el que se ejecuta el software en condiciones controladas para comprobar su comportamiento y prestaciones, contrastándolos con la especificación de requisitos correspondiente. 3.1.42 herramienta de clase T1: Herramienta que no genera salidas que puedan contribuir de forma directa o indirecta al código ejecutable (incluyendo los datos) del software. NOTA Son ejemplos de herramientas de clase T1: un editor de texto o una herramienta de soporte al diseño o a los requisitos sin capacidad de generación automática de código; herramientas de control de la configuración.

3.1.43 herramienta de clase T2: Permite el ensayo o verificación del diseño o del código ejecutable, cuando los errores en la herramienta hacen que no revele defectos pero no crean errores directamente en el software ejecutable. NOTA Son ejemplos de herramientas de clase T2: un generador de banco de ensayos; una herramienta de medición de la cobertura de los ensayos; una herramienta de análisis estático.

3.1.44 herramienta de clase T3: Herramienta que genera salidas que pueden contribuir de forma directa o indirecta al código ejecutable (incluyendo los datos) del sistema relacionado con la seguridad. NOTA Son ejemplos de herramientas de clase T3: los compiladores de código fuente, los compiladores de datos/algoritmos, las herramientas para modificar los puntos de consigna durante el funcionamiento del sistema; los compiladores de optimización en los que la relación entre el programa de código fuente y el código objeto generado no es evidente; un compilador que incorpora un paquete ejecutable en tiempo de ejecución dentro del código ejecutable.

3.1.45 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.1.46 validación: Proceso de análisis seguido de un juicio basado en pruebas para determinar si un elemento (por ejemplo, un proceso, documentación, software o una aplicación) responde a las necesidades de un usuario, en particular en lo que se refiere a seguridad y calidad, haciendo énfasis en la idoneidad de su funcionamiento de acuerdo con su objetivo en su entorno previsto. 3.1.47 validador: Entidad responsable de la validación.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 17 -

EN 50128:2011

3.1.48 verificación: Proceso de examen seguido de un juicio basado en pruebas que demuestren que los elementos de salida (procesos, documentación, software o aplicaciones) de una fase de desarrollo específica cumplen con los requisitos de dicha fase en lo que se refiere a su compleción, corrección y coherencia. NOTA La verificación se basa sobre todo en revisiones de documentos (documentos de diseño, de implementación, de ensayo, etc.).

3.1.49 verificador: Entidad responsable de una o más actividades de verificación. 3.2 Abreviaturas Para los fines de este documento, se aplican las abreviaturas siguientes. ASR

Evaluador (Assessor)

COTS

Comercial (Commercial off-the-shelf)

DES

Diseñador (Designer)

HR

Altamente recomendado (Highly Recommended)

IMP

Implementador

INT

Integrador

JSD

Metodología de Desarrollo de Sistemas de Jackson (Jackson System Development Method)

M

Obligatorio (Mandatory)

MASCOT

Método Modular de Construcción, Utilización y Ensayo del Software (Modular Approach to Software Construction, Operation and Test)

NR

No recomendado

PM

Jefe de proyecto (Project Manager)

R

Recomendado

RAMS

Fiabilidad, Disponibilidad, Mantenibilidad y Seguridad (Reliability, Availability, Maintainability and Safety)

RQM

Gestor de requisitos (Requirements Manager)

SDL

Lenguaje de Especificación y Descripción (Specification and Description Language)

SFC

Diagramas Secuenciales de Función (Sequential Function Charts)

SIL

Nivel de Integridad de Seguridad (Safety Integrity Level)

SOM

Modelado Orientado al Servicio (Service Oriented Modeling)

SSADM

Método de Diseño y Análisis de Sistemas Estructurados (Structured Systems Analysis & Design Methodology)

TST

Encargado de los Ensayos (Tester)

V&V

Verificación y validación

VAL

Validador

VER

Verificador

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 18 -

4 OBJETIVOS, CONFORMIDAD Y NIVELES DE INTEGRIDAD DE SEGURIDAD DEL SOFTWARE 4.1 La documentación del sistema debe identificar la asignación al software, así como a las interfaces del software, de las funciones del sistema relacionado con la seguridad. El sistema en el que el software está integrado debe estar totalmente definido en relación a los siguientes elementos: – funciones e interfaces; – condiciones de aplicación; – configuración o arquitectura del sistema; – situaciones peligrosas a controlar; – requisitos de integridad de seguridad; – asignación de requisitos y del SIL al software y al hardware; – restricciones de tiempo NOTA La asignación de requisitos de integridad de seguridad puede conducir a diferentes SIL para partes bien diferenciadas de software y hardware de un subsistema. Esta asignación depende de la contribución de las partes de software y hardware de un subsistema a las funciones relacionadas con la seguridad y depende también de los mecanismos para limitar los fallos incluyendo la separación de funciones con SIL diferente.

4.2 La integridad de seguridad del software debe especificarse como uno de cinco niveles, que van desde el SIL 0 (el nivel inferior) al SIL 4 (el nivel superior). 4.3 El nivel de integridad de seguridad del software requerido se debe decidir y evaluar a nivel del sistema, tomando como base el nivel de integridad de seguridad del sistema y del nivel de riesgo asociado con el uso de software en el sistema. 4.4 Se deben cumplir al menos los requisitos asociados al SIL 0 que se describen en esta norma europea para la parte de software de funciones que tengan un impacto en la seguridad por debajo del SIL 1. Esto se debe a que existe una incertidumbre en la evaluación del riesgo, e incluso en la identificación de situaciones peligrosas. Considerando las incertidumbres, es recomendable contar con un nivel bajo de integridad de la seguridad, representado por SIL 0, en lugar de no utilizar ninguno. 4.5 Para estar conforme con esta norma europea se debe demostrar que se ha satisfecho cada uno de los requisitos respecto al nivel de integridad de seguridad del software definido y que por tanto se ha cumplido con el objetivo del apartado en cuestión. 4.6 En los casos en los que se califique a un requisito con las palabras "dentro del alcance requerido por el nivel de integridad de seguridad del software", se está indicando que se deben utilizar una serie de técnicas y medidas para satisfacer dicho requisito. 4.7 En los casos en los que se aplique el apartado 4.6, se deben usar las tablas del anexo A normativo para ayudar en la selección de técnicas y medidas adecuadas al nivel de integridad de seguridad del software. Dicha selección debe documentarse en el Plan de Garantía de Calidad del Software o en otro documento al que haga referencia el Plan de Garantía de Calidad del Software. En el anexo D informativo se proporcionan indicaciones sobre estas técnicas.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 19 -

EN 50128:2011

4.8 Si no se utiliza una técnica o medida calificada como altamente recomendable (HR) en las tablas, se deben detallar entonces las razones para el uso de técnicas alternativas y deben registrarse en el Plan de Garantía de Calidad del Software o en otro documento al que haga referencia el Plan de Garantía de Calidad del Software. Esto no será necesario si se utiliza una combinación homologada de técnicas determinada en la tabla correspondiente. Se debe demostrar que se han aplicado las técnicas seleccionadas de forma correcta. 4.9 Si se propone utilizar una técnica o una medida que no aparezca en las tablas, se debe justificar entonces su efectividad e idoneidad para cumplir los requisitos particulares y los objetivos globales del apartado y se debe registrar en el Plan de Garantía de Calidad del Software o en otro documento al que haga referencia el Plan de Garantía de Calidad del Software. 4.10 La conformidad con los requisitos de un apartado particular y sus técnicas y medidas respectivas detalladas en las tablas debe verificarse mediante la inspección de los documentos requeridos por esta norma europea. Cuando proceda, se deben tener en cuenta también otras pruebas objetivas, auditorías y pruebas de ensayos. 5 GESTIÓN Y ORGANIZACIÓN DEL DESARROLLO DEL SOFTWARE 5.1 Organización, roles y responsabilidades 5.1.1 Objetivo 5.1.1.1 Garantizar que todo el personal responsable del software esté organizado, habilitado y capacitado para cumplir con sus responsabilidades. 5.1.2 Requisitos 5.1.2.1 El proveedor debe implementar, como mínimo, las partes de la Norma EN ISO 9001 relativas a la organización y gestión del personal y sus responsabilidades. 5.1.2.2 Las responsabilidades deben estar conformes a los requisitos definidos en el anexo B. 5.1.2.3 Se debe identificar y registrar al personal asignado a los roles implicados en el desarrollo o mantenimiento del software. 5.1.2.4 El proveedor, el cliente o la Autoridad de Seguridad debe designar a un Evaluador. 5.1.2.5 El Evaluador debe ser una figura independiente del proveedor o, a discreción de la Autoridad de Seguridad, ser parte de la organización del proveedor o de la del cliente. 5.1.2.6 El Evaluador debe ser una figura independiente del proyecto. 5.1.2.7 El Evaluador debe recibir una autorización para poder realizar la evaluación del software. 5.1.2.8 El Validador debe mostrar su acuerdo/desacuerdo sobre la publicación de una versión de software. 5.1.2.9 Durante el Ciclo de vida del Software, la atribución de roles a las personas debe estar de acuerdo con lo descrito desde el apartado 5.1.2.10 al 5.1.2.14, dentro del alcance requerido por el nivel de integridad de seguridad del software.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 20 -

Figura 2 – Ilustrración de la estructura organizativa preferida NOTA La figura 2 es solo una ilustración de la estructtura organizativa preferida.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 21 -

5.1.2.10

EN 50128:2011

La estructura organizativa preferida para el SIL 3 y el SIL 4 es:

a) Una misma persona puede desempeñar los roles de Gestor de requisitos, de Diseñador y de Implementador de un componente software. b) El Gestor de requisitos, Diseñador e Implementador de un componente software deben depender del Jefe de proyecto. c) Una misma persona puede desempeñar los roles de Integrador y Encargado de los Ensayos de un componente software. d) El Integrador y el Encargado de los Ensayos de un componente software pueden depender del Jefe de proyecto o del Validador. e) El Verificador puede depender del Jefe de proyecto o del Validador. f) El Validador no debe depender del Jefe de proyecto, es decir, el Jefe de proyecto no debe influir en las decisiones del Validador, aunque el Validador informa de sus decisiones al Jefe de proyecto. g) La persona con el rol de Gestor de requisitos, de Diseñador o de Implementador de un componente software no debe desempeñar los roles de Encargado de los Ensayos ni de Integrador de dicho componente software. h) La persona con el rol de Integrador o de Encargado de los Ensayos de un componente software no debe desempeñar los roles de Gestor de requisitos, de Diseñador ni de Implementador de dicho componente software. i) La persona con el rol de Verificador no debe desempeñar los roles de Gestor de requisitos, Diseñador, Implementador, Integrador, Encargado de los Ensayos ni de Validador. j) La persona con el rol de Validador no debe desempeñar los roles de Gestor de requisitos, Diseñador, Implementador, Integrador, Encargado de los Ensayos ni de Verificador. k) La persona con el rol de Jefe de proyecto puede desempeñar además los roles de Gestor de requisitos, Diseñador, Implementador, Integrador, Encargado de los Ensayos o Verificador siempre que se respeten los requisitos de independencia entre estos roles adicionales. l) El Jefe de proyecto, el Gestor de requisitos, el Diseñador, el Implementador, el Integrador, el Encargado de los Ensayos, el Verificador y el Validador pueden pertenecer a la misma organización. m) El Evaluador debe ser una figura independiente así como también debe ser organizativamente independiente de los roles del Jefe de proyecto, del Gestor de requisitos, del Diseñador, del Implementador, del Integrador, del Encargado de los Ensayos, del Verificador y del Validador. Sin embargo, se pueden aplicar las siguientes opciones: n) La persona con el rol del Validador puede desempeñar el rol de Verificador, pero siendo independiente del Jefe de proyecto. En este caso, otra persona competente con el mismo nivel de independencia que el Validador debe revisar los documentos de salida producidos por el Verificador. Esta opción organizativa debe quedar sujeta a la aprobación por parte del Evaluador. o) La persona con el rol de Verificador puede desempeñar también los roles de Integrador y de Encargado de los Ensayos, en cuyo caso, la persona con el rol de Validador debe comprobar la adecuación de las pruebas documentadas obtenidas de la integración y de los ensayos para los objetivos de verificación especificados, conservando por tanto dos niveles de comprobación dentro de la organización del proyecto.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

5.1.2.11

- 22 -

La estructura organizativa preferida para el SIL 1 y el SIL 2 es:

a) Una misma persona puede desempeñar los roles de Gestor de requisitos, de Diseñador y de Implementador de un componente software y debe depender del Jefe de proyecto. b) Una misma persona puede desempeñar los roles de Integrador y Encargado de los Ensayos de un componente software. c) El Integrador y el Encargado de los Ensayos de un componente software puede depender del Jefe de proyecto o del Validador. d) Una misma persona puede desempeñar los roles de Verificador y Validador. e) Verificador y Validador pueden depender del Jefe de proyecto. f) La persona con el rol de Gestor de requisitos, de Diseñador o de Implementador de un componente software no debe tener los roles de Encargado de los Ensayos ni de Integrador de dicho componente software. g) La persona con el rol de Integrador o de Encargado de los Ensayos de un componente software no debe desempeñar los roles de Gestor de requisitos, de Diseñador ni de Implementador de dicho componente software. h) La persona con el rol de Verificador o Validador no debe desempeñar los roles de Gestor de requisitos, Diseñador, Implementador, Integrador ni de Encargado de los Ensayos. i) La persona con el rol de Jefe de proyecto puede desempeñar además los roles de Gestor de requisitos, Diseñador, Implementador, Integrador, Encargado de los Ensayos, Verificador o Validador siempre que se respeten los requisitos de independencia entre estos roles adicionales. j) El Jefe de proyecto, el Gestor de requisitos, el Diseñador, el Implementador, el Integrador, el Encargado de los Ensayos, el Verificador y el Validador pueden pertenecer a la misma organización. k) El Evaluador debe ser una figura independiente así como también debe ser organizativamente independiente de los roles del Jefe de proyecto, del Gestor de requisitos, del Diseñador, del Implementador, del Integrador, del Encargado de los Ensayos, del Verificador y del Validador. Sin embargo, se pueden aplicar las siguientes opciones: l) La persona con el rol de Verificador puede desempeñar también el rol de Integrador y de Encargado de los Ensayos, en cuyo caso, la persona con el rol de Validador debe revisar los documentos de salida producidos por el Verificador conservando por tanto dos niveles de control dentro de la organización del proyecto. m) La persona con el rol de Validador puede desempeñar también el rol de Verificador, Integrador y Encargado de los Ensayos. En este caso, otra persona competente con el mismo nivel de independencia que el Validador debe revisar los documentos de salida producidos por el Verificador. Esta opción organizativa debe quedar sujeta a la aprobación por parte del Evaluador. 5.1.2.12

La estructura organizativa preferida para el SIL 0 es:

a) Una misma persona puede desempeñar los roles de Gestor de requisitos, de Diseñador y de Implementador de un componente software y debe depender del Jefe de proyecto. b) Una misma persona puede desempeñar los roles de Integrador, de Encargado de los Ensayos, de Verificador y de Validador de un componente software. c) El Integrador, Encargado de los Ensayos, Verificador y Validador pueden depender del Jefe de proyecto.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 23 -

EN 50128:2011

d) La persona con el rol de Gestor de requisitos, de Diseñador o de Implementador de un componente software no debe tener los roles de Encargado de los Ensayos ni de Integrador de dicho componente software. e) La persona con el rol de Verificador o Validador no debe desempeñar los roles de Gestor de requisitos, Diseñador ni de Implementador. f) La persona con el rol de Jefe de proyecto puede desempeñar además los roles de Gestor de requisitos, Diseñador, Implementador, Integrador, Encargado de los Ensayos, Verificador o Validador siempre que se respeten los requisitos de independencia entre estos roles adicionales. g) El Jefe de proyecto, el Gestor de requisitos, el Diseñador, el Implementador, el Integrador, el Encargado de los Ensayos, el Verificador y el Validador pueden pertenecer a la misma organización. h) El Evaluador debe ser una figura independiente así como también debe ser organizativamente independiente de los roles del Jefe de proyecto, del Gestor de requisitos, del Diseñador, del Implementador, del Integrador, del Encargado de los Ensayos, del Verificador y del Validador. Sin embargo, se pueden aplicar las siguientes opciones: i) Una misma persona puede desempeñar los roles de Gestor de requisitos, de Diseñador, de Implementador, de Integrador y de Encargado de los Ensayos. j) Una misma persona puede desempeñar los roles de Validador y Verificador; k) La persona con el rol de Verificador o Validador no debe desempeñar los roles de Gestor de requisitos, Diseñador ni de Implementador. 5.1.2.13 Las personas que desempeñen los roles de Gestor de requisitos, Diseñador e Implementador de un componente pueden desempeñar los roles de Encargado de los Ensayos y de Integrador de un componente distinto. 5.1.2.14 Los roles de Verificador y Validador deben quedar definidos a nivel de proyecto y deben permanecer inalterados durante el proyecto de desarrollo. 5.2 Competencia del personal 5.2.1 Objetivos 5.2.1.1 Garantizar que todo el personal que tiene responsabilidades sobre el software puede cumplir con dichas responsabilidades demostrando la capacidad para realizar las tareas pertinentes de forma correcta, eficaz y coherente con un nivel de alta calidad y en condiciones variables. 5.2.2 Requisitos 5.2.2.1 En el anexo B se definen las competencias clave necesarias para cada rol en el desarrollo de software. El Plan de Garantía de Calidad del Software debe definir si un rol en el ciclo de vida del software requiere experiencia, capacidades o cualificaciones adicionales. 5.2.2.2 La organización del proveedor debe conservar pruebas documentadas de la competencia del personal, incluyendo conocimientos técnicos, cualificaciones, experiencia relevante y formación apropiada para demostrar una organización de seguridad apropiada. 5.2.2.3 La organización debe mantener los procedimientos de gestión de la competencia del personal para que se adapten a los roles apropiados de acuerdo con las normas de calidad existentes.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 24 -

5.2.2.4 Una vez que se ha demostrado, a opinión de un evaluador o mediante certificación, la competencia de todo el personal asignado a distintos roles, cada individuo tendrá que demostrar que mantiene y desarrolla sus competencias de forma continua. Esto puede demostrarse llevando un registro que muestre que las actividades se realizan normalmente de forma correcta, y que la formación adicional se está realizando de acuerdo con el apartado 6.2.2 "Competencia, formación y toma de conciencia" de la Norma EN ISO 9001 y de la Norma ISO/IEC 90003:2004. 5.3 Etapas del ciclo de vida y documentación 5.3.1 Objetivos 5.3.1.1 Estructurar el desarrollo del software en fases y actividades definidas. 5.3.1.2 Registrar toda la información pertinente del software a lo largo del ciclo de vida del mismo. 5.3.2 Requisitos 5.3.2.1 Se debe seleccionar un modelo de ciclo de vida para el desarrollo del software. Se debe detallar en el Plan de Garantía de Calidad del Software de acuerdo con el apartado 6.5. En las figuras 3 y 4 se muestran dos ejemplos de modelos de ciclo de vida. 5.3.2.2 El modelo de ciclo de vida debe tener en cuenta la posibilidad de iteraciones en el interior de las fases y entre ellas. 5.3.2.3 Los procedimientos de Garantía de Calidad deben ir en paralelo con las actividades del ciclo de vida y deben utilizar la misma terminología. 5.3.2.4 El Plan de Garantía de Calidad del Software, el Plan de Verificación del Software, el Plan de Validación del Software y el Plan de Gestión de Configuración del Software deben elaborarse al inicio del proyecto y se deben mantener durante el ciclo de vida de desarrollo del software. 5.3.2.5 Antes del inicio de una fase se deben definir y planificar todas las actividades que se van a desarrollar durante dicha fase. 5.3.2.6 Se deben estructurar todos los documentos de forma que permitan un enriquecimiento continuo paralelo al proceso de desarrollo. 5.3.2.7 Se debe asegurar la trazabilidad de los documentos mediante un número de referencia único y una relación definida y documentada con otros documentos. 5.3.2.8 Cada término, acrónimo o abreviatura debe tener el mismo significado en los distintos documentos. Si no es posible por razones históricas, se deben enumerar los distintos significados y dar las referencias. 5.3.2.9 Todo documento, excepto aquellos relativos a software preexistente (véase 7.3.4.7), debe estar redactado siguiendo las siguientes reglas: – debe contener o implementar todas las condiciones y requisitos aplicables del documento que le precede con el que tenga una relación jerárquica; – no debe contradecir al documento que le precede. 5.3.2.10 Se debe hacer referencia con el mismo nombre o descripción a cada elemento o concepto en todos los documentos. 5.3.2.11 Los contenidos de todos los documentos deben registrarse de forma apropiada para su manipulación, tratamiento y almacenamiento.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 25 -

EN 50128:2011

5.3.2.12 Cuando los documentos produccidos por entidades con roles independientes se com mbinen en un solo documento, la relación con las partes produccidas por las entidades con roles independientes debe trrazarse en el seno del documento. 5.3.2.13 De acuerdo con el apartado 5.3.2..12 se pueden combinar o dividir documentos. Algunas etapas de desarrollo pueden combinarse, dividirse o, cuando see justifique, eliminarse, a discreción del Jefe de prooyecto y habiéndose alcanzado un acuerdo con el Validador. 5.3.2.14 Si se adopta un ciclo de vida o una u estructura de documentación alternativa se debe deemostrar que cumple todos los objetivos y requisitos de esta norm ma europea.

Figura 3 – Ciclo de Vida del Desarrollo del Software ejemplo 1

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 26 -

Figura 4 – Ciclo de Vida del Desarrollo del Software ejemplo 2

6 GARANTÍA DEL SOFTWARE 6.1 Ensayos del Software 6.1.1 Objetivo 6.1.1.1 El objetivo de los ensayos del softw ware, realizados por el Encargado de los Ensayos y/o ell Integrador, es el de comprobar el comportamiento o las preestaciones del software en relación con la especifficación de ensayos correspondiente en la medida alcanzable porr la cobertura del ensayo seleccionado. 6.1.2 Documentos de entrada 1) Toda Documentación del Sistema, del Hardware y del Software especificada en el Plan de Verificación del Software.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 27 -

EN 50128:2011

6.1.3 Documentos de salida 1) Especificación de Ensayos del Software en Conjunto. 2) Informe de Ensayos del Software en Conjunto. 3) Especificación de Ensayos de Integración del Software. 4) Informe de Ensayos de Integración del Software. 5) Especificación de Ensayos de Integración del Software/Hardware. 6) Informe de Ensayos de Integración del Software/Hardware. 7) Especificación de Ensayos de los Componentes Software. 8) Informe de Ensayos de los Componentes Software. 6.1.4 Requisitos 6.1.4.1 El Verificador puede aceptar ensayos realizados por otros, como el Gestor de requisitos, el Diseñador o el Implementador, si están bien documentados y cumplen con los siguientes requisitos. 6.1.4.2 El equipo de medición usado para los ensayos debe estar calibrado de forma adecuada. Se debe demostrar que las herramientas hardware o software utilizadas para los ensayos están adaptadas a sus objetivos. 6.1.4.3 Los ensayos del software deben estar documentados mediante una Especificación de Ensayos y un Informe de Ensayos, como se define en los siguientes apartados. 6.1.4.4 Cada Especificación de Ensayos debe documentar lo siguiente: a) objetivos de los ensayos; b) casos de ensayos, datos de los ensayos y resultados previstos; c) tipos de ensayos a realizar; d) entorno de los ensayos, herramientas, configuración y programas; e) criterios de los ensayos que servirán para juzgar la consecución o no del ensayo; f) los criterios a satisfacer y los grados de cobertura de los ensayos a alcanzar; g) los roles y responsabilidades del personal implicado en el proceso de ensayo; h) los requisitos cubiertos por la especificación de ensayo; i) la selección y utilización del equipo de ensayo del software. 6.1.4.5 El Informe de Ensayo se debe realizar según se detalla a continuación: a) el Informe de Ensayo debe recoger los nombres de los Encargados de los Ensayos, debe exponer los resultados de los ensayos y debe declarar si se han cumplido los objetivos del ensayo y si se han seguido los criterios de ensayo descritos en la Especificación de Ensayos. Se deben documentar y resumir los fallos que se produzcan; b) se deben registrar los casos de ensayos y sus resultados, preferiblemente en un formato legible por una máquina para su análisis posterior;

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 28 -

c) los ensayos se deben poder repetir, y, si es factible, se deben poder realizar con medios automáticos; d) se deben verificar los scripts de prueba para la ejecución automática de ensayos; e) se debe documentar la identidad y configuración de todos los elementos implicados (hardware usado, software usado, equipo usado, calibración del equipo, así como la información de la versión de la especificación de ensayos); f) se debe proporcionar una evaluación de la cobertura del ensayo y de su consecución anotándose cualquier desviación que se hubiera producido. 6.2 Verificación del software 6.2.1 Objetivo 6.2.1.1 El objetivo de la verificación del software es examinar y llegar a una conclusión basada en pruebas de que los elementos de salida (proceso, documentación, software o aplicación) de una fase de desarrollo específica cumplen con los requisitos y planes relativos a su compleción, corrección y coherencia. El encargado de gestionar estas actividades es el Verificador. 6.2.2 Documentos de entrada 1) Toda la documentación necesaria relativa al Sistema, al Hardware y al Software. 6.2.3 Documentos de salida 1) Plan de Verificación del Software. 2) Informe(s) de Verificación del Software. 3) Informe de Verificación de Garantía de Calidad del Software. 6.2.4 Requisitos 6.2.4.1 Se debe documentar la verificación con al menos un Plan de Verificación del Software y uno o más Informes de Verificación (relativos a los procesos). 6.2.4.2 Se debe redactar un Plan de Verificación del Software, bajo la responsabilidad del verificador, tomando la documentación necesaria como base. Los requisitos que se describen desde el apartado 6.2.4.3 al 6.2.4.9 hacen referencia al Plan de Verificación del Software. 6.2.4.3 El Plan de Verificación del Software debe describir las actividades a realizar para garantizar la verificación correcta y que las necesidades particulares en materia de diseño o de otras verificaciones se tienen en cuenta de forma correcta. 6.2.4.4 Durante el desarrollo (y dependiendo del tamaño del sistema) se puede subdividir el plan en una serie de subdocumentos que se añadirán a medida que se aclaren las necesidades detalladas de verificación. 6.2.4.5 El Plan de Verificación del Software debe documentar todos los criterios, técnicas y herramientas que se vayan a usar en el proceso de verificación. El Plan de Verificación del Software debe incluir técnicas y medidas que se elijan de entre las que aparecen en las tablas A.5, A.6, A.7 y A.8. La combinación seleccionada debe justificarse como un conjunto que satisfaga los apartados 4.8, 4.9 y 4.10. 6.2.4.6 El Plan de Verificación del Software debe describir las actividades que se van a realizar para garantizar la corrección y coherencia de las entradas de cada fase. Estas actividades comprenden la revisión, los ensayos y la integración.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 29 -

EN 50128:2011

6.2.4.7 En cada fase de desarrollo se debe demostrar que se cumplen los requisitos funcionales, relativos a las prestaciones y a la seguridad. 6.2.4.8 Los resultados de cada verificación deben conservarse en un formato definido o referenciado en el Plan de Verificación del Software. 6.2.4.9 El Plan de Verificación del Software debe incluir los elementos siguientes: a) la selección de las estrategias y técnicas de verificación (para evitar complicar inútilmente la evaluación de la verificación y los ensayos, se debe dar preferencia a la selección de técnicas que sean por sí mismas fácilmente analizables); b) la selección de técnicas de las tablas A.5, A.6, A.7 y A.8; c) la selección y documentación de actividades de verificación; d) la evaluación de los resultados de verificación obtenidos; e) la evaluación de los requisitos de seguridad y robustez; f) los roles y responsabilidades del personal implicado en el proceso de verificación; g) el grado de cobertura de los ensayos funcionales que es necesario alcanzar; h) la estructura y el contenido de cada etapa de verificación, en especial la Verificación de los Requisitos del Software (7.2.4.22), Arquitectura del Software y Verificación del Diseño (7.3.4.41 y 7.3.4.42), Verificación de los Componentes Software (7.4.4.13), Verificación del Código Fuente del Software (7.5.4.10) y Verificación de la Integración (7.6.4.13), de forma que facilite la revisión teniendo en cuenta el Plan de Verificación del Software. 6.2.4.10 Se debe redactar un Informe de Verificación de la Garantía de Calidad del Software, bajo la responsabilidad del verificador, tomando los documentos de entrada del apartado 6.2.2 como base. El requisito del apartado 6.2.4.11 hace referencia al Informe de Verificación de la Garantía de Calidad del Software. 6.2.4.11

Una vez que se haya establecido el Plan de Verificación del Software, la verificación debe recoger:

a) que el Plan de Verificación del Software cumple con los requisitos generales de legibilidad y trazabilidad que se describen desde el apartado 5.3.2.7 hasta el apartado 5.3.2.10 y desde el apartado 6.5.4.14 hasta el apartado 6.5.4.17, así como los requisitos específicos descritos desde el apartado 6.2.4.3 al apartado 6.2.4.9; b) la coherencia interna del Plan de Verificación del Software. Los resultados deben quedar registrados en un Informe de Verificación de la Garantía de Calidad del Software. 6.2.4.12 Cualquier Informe de Verificación del Software debe redactarse, bajo la responsabilidad del verificador, tomando la documentación de entrada como base. Estos informes pueden dividirse por razones de claridad y comodidad y deben seguir el Plan de Verificación del Software. El requisito del apartado 6.2.4.13 hace referencia a los Informes de Verificación del Software. 6.2.4.13

Cada Informe de Verificación del Software debe documentar lo siguiente:

a) la identidad y configuración de los elementos verificados, así como los nombres de los verificadores; b) los elementos que no cumplan con las especificaciones; c) los componentes, datos, estructuras y algoritmos que se adapten mal al problema;

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 30 -

d) los errores o deficiencias detectados; e) el cumplimiento, o desvío del Plan de Verificación del Software (en caso de desvío, el Informe de Verificación debe explicar si dicho desvío es crítico o no); f) las hipótesis, si las hay; g) un resumen de los resultados de verificación. 6.3 Validación del Software 6.3.1 Objetivo 6.3.1.1 El objetivo de la validación del software es demostrar que los procesos y sus salidas son tales que el software tiene el nivel definido de integridad de seguridad del software, que cumple los requisitos relativos al software y que es válido para su aplicación prevista. El validador es quien se encarga de realizar ésta actividad. 6.3.1.2 Las principales actividades de validación se utilizan para demostrar mediante análisis y/o ensayos que todos los requisitos del software se especifican, se implementan, se someten a ensayo y se cumplen según los requisitos del SIL aplicable, y para evaluar la criticidad para la seguridad de todas las anomalías y casos de no conformidad en función de los resultados de las revisiones, análisis y ensayos. 6.3.2 Documentos de entrada Documentación del sistema, del hardware y del software según se especifica en esta norma europea. 6.3.3 Documentos de salida 1) Plan de Validación del Software. 2) Informe de Validación del Software. 3) Informe de Verificación de Validación del Software. 6.3.4 Requisitos 6.3.4.1 Un validador con un nivel de independencia apropiado, como se define en el apartado 5.1, debe desarrollar y realizar las actividades de Validación del Software, con sus resultados evaluados. 6.3.4.2 La validación debe documentarse con al menos un Plan de Validación del Software y un Informe de Validación del Software, como se define a continuación. 6.3.4.3 Se debe redactar un Plan de Validación del Software, bajo la responsabilidad del Validador, tomando los documentos de entrada como base. Los requisitos que se describen desde el apartado 6.3.4.4 al 6.3.4.6 hacen referencia al Plan de Validación del Software. 6.3.4.4 El Plan de Validación del Software debe incluir un resumen que justifique la estrategia de validación elegida. La justificación, según el nivel de integridad de seguridad del software necesario, debe tener en cuenta: a) técnicas manuales o automatizadas o ambas; b) técnicas estáticas o dinámicas o ambas; c) técnicas analíticas o estadísticas o ambas; d) ensayos en entornos reales o simulados.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 31 -

EN 50128:2011

6.3.4.5 El Plan de Validación del Software debe identificar las etapas necesarias para demostrar la adecuación de cualquier Especificación de Software para satisfacer los requisitos de seguridad establecidos en la Especificación de Requisitos de Seguridad del Sistema. 6.3.4.6 El Plan de Validación del Software debe identificar las etapas necesarias para demostrar la adecuación de la Especificación de Ensayos del Software en Conjunto como ensayo en relación a la Especificación de Requisitos del Software. 6.3.4.7 Debe redactarse un Informe de Validación del Software, bajo la responsabilidad del Validador, tomando los documentos de entrada como base. Los requisitos que se describen desde el apartado 6.3.4.8 al 6.3.4.11 hacen referencia al Informe de Validación del Software. 6.3.4.8 Los resultados de la validación deben documentarse en el Informe de Validación del Software. 6.3.4.9 El validador debe comprobar que el proceso de verificación está completo. 6.3.4.10 El Informe de Validación del Software debe indicar de manera exhaustiva la línea base del software que ha sido validada. 6.3.4.11 El Informe de Validación debe identificar claramente cualquier deficiencia conocida en el software y el impacto que éstas podrían tener en el uso del mismo. 6.3.4.12 Se debe redactar un Informe de Verificación de la Validación del Software, bajo la responsabilidad del Verificador, tomando los documentos de entrada del apartado 6.3.2 como base. Los requisitos que se describen desde el apartado 6.3.4.13 al 6.3.4.14 hacen referencia al Informe de Verificación de la Validación del Software. 6.3.4.13

Una vez que se haya establecido el Plan de Validación del Software, la verificación debe recoger:

a) que el Plan de validación del Software cumple con los requisitos generales de legibilidad y trazabilidad que se describen desde el apartado 5.3.2.7 hasta el apartado 5.3.2.10 y desde el apartado 6.5.4.14 hasta el apartado 6.5.4.17, así como los requisitos específicos descritos desde el apartado 6.3.4.4 al apartado 6.3.4.6; b) la coherencia interna del Plan de Validación del Software. 6.3.4.14

Una vez que se haya establecido el Informe de Validación del Software, la verificación debe recoger:

a) que el Informe de validación del Software cumple con los requisitos generales de legibilidad y trazabilidad que se describen desde el apartado 5.3.2.7 hasta el apartado 5.3.2.10 y desde el apartado 6.5.4.14 hasta el apartado 6.5.4.17, así como los requisitos específicos descritos desde el apartado 6.3.4.8 al apartado 6.3.4.11 y desde el apartado 7.7.4.7 al apartado 7.7.4.11; b) la coherencia interna del Informe de Validación del Software. Los resultados deben quedar registrados en un Informe de Verificación de la Validación del Software. 6.3.4.15

El Validador debe estar habilitado para exigir o realizar revisiones, análisis y ensayos adicionales.

6.3.4.16

El software solo debe publicarse para su explotación después de que el Validador lo autorice.

6.3.4.17

Se pueden realizar simulaciones y modelados como complemento del proceso de validación.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 32 -

6.4 Evaluación del software 6.4.1 Objetivo 6.4.1.1 Evaluar que los procesos del ciclo de vida y sus salidas son tales que el software se encuentra entre los niveles definidos de integridad de seguridad para el software 1 a 4 y que es válido para su aplicación prevista. 6.4.1.2 Los requisitos de esta norma deben cumplirse para software con SIL 0, pero si se dispone de un certificado que declare la conformidad del software con la Norma EN ISO 9001, no será necesario realizar ninguna evaluación. 6.4.2 Documentos de entrada 1) Especificación de Requisitos de Seguridad del Sistema. 2) Especificación de Requisitos del Software. 3) Resto de documentos necesarios para realizar el proceso de evaluación. 6.4.3 Documentos de salida 1) Plan de Evaluación del Software. 2) Informe de Evaluación del Software. 3) Informe de Verificación de Evaluación del Software. 6.4.4 Requisitos 6.4.4.1 Un Evaluador independiente, como se describe en los apartados 5.1.2.6 y 5.1.2.7, debe encargarse de realizar la evaluación del software. 6.4.4.2 No es necesario realizar una nueva evaluación de aquel software que cuente con un Informe de Evaluación de Software realizado por otro Evaluador. El evaluador debe comprobar que el software es válido para su uso previsto dentro de su entorno previsto, y debe comprobar también que en la evaluación anterior el software ha alcanzado un nivel de integridad de seguridad al menos igual al nivel requerido. 6.4.4.3 El Evaluador debe tener acceso a toda la documentación relativa al proyecto durante el proceso de desarrollo. 6.4.4.4 Se debe redactar un Plan de Evaluación del Software, bajo la responsabilidad del Evaluador, tomando los documentos de entrada del apartado 6.4.2 como base. Cuando proceda, se puede usar un procedimiento o Plan de Evaluación del Software genérico documentado existente. El requisito del apartado 6.4.4.5 hace referencia al Plan de Evaluación del Software. 6.4.4.5 El Plan de Evaluación del Software debe incluir el siguiente campo de aplicación: a) aspectos de los que trate la evaluación; b) actividades durante el proceso de evaluación y su enlace secuencial con las actividades de ingeniería; c) documentos a tener en cuenta; d) declaraciones de los criterios de aceptación/rechazo y forma de tratar los casos de no conformidad; e) requisitos relativos al contenido y forma del Informe de Evaluación del Software. 6.4.4.6 Se debe redactar un Informe de Verificación de la Evaluación del Software, bajo la responsabilidad del Verificador, tomando los documentos de entrada del apartado 6.4.2 como base.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 33 -

EN 50128:2011

El requisito del apartado 6.4.4.7 hace referencia al Informe de Verificación de la Evaluación del Software. 6.4.4.7 Una vez que se haya establecido el Plan de Evaluación del Software, la verificación debe recoger: a) que el Plan de Evaluación del Software cumple con los requisitos generales de legibilidad y trazabilidad que se describen desde el apartado 5.3.2.7 hasta el apartado 5.3.2.10 y desde el apartado 6.5.4.14 hasta el apartado 6.5.4.17, así como los requisitos específicos descritos en el apartado 6.4.4.5; b) la coherencia interna del Plan de Evaluación del Software. Los resultados deben quedar registrados en un Informe de Verificación de la Evaluación del Software. 6.4.4.8 El Evaluador debe evaluar si el software del sistema es válido para su propósito previsto y responde de forma correcta a los temas relativos a la seguridad derivados de la Especificación de Requisitos de Seguridad del Sistema. 6.4.4.9 El Evaluador debe evaluar si se han seleccionado y aplicado una serie de técnicas del anexo A, adecuadas para el desarrollo previsto, en función del nivel de integridad de seguridad requerido. Además, el evaluador debe tener en cuenta hasta qué punto se aplica cada técnica del anexo A, es decir, si se aplica a todo el software o solo a parte de éste, y debe además encontrar pruebas que demuestren que se aplica de forma correcta. 6.4.4.10 El Evaluador debe evaluar la configuración y el sistema de gestión de las modificaciones así como las pruebas sobre su uso y aplicación. 6.4.4.11 El Evaluador debe revisar las pruebas relativas a la competencia del personal del equipo de proyecto de acuerdo con el anexo B y debe evaluar la organización para el desarrollo del software de acuerdo con el apartado 5.1. 6.4.4.12 El Evaluador debe comprobar en cualquier software que contenga condiciones de aplicación relacionadas con la seguridad que no existen desviaciones conocidas, casos de no conformidad con los requisitos ni casos de no conformidad registrados, que puedan tener impacto en la seguridad, y debe juzgar si la justificación proporcionada por el proyecto es aceptable. El resultado debe recogerse en el informe de evaluación. 6.4.4.13

El Evaluador debe evaluar las actividades de verificación y validación y las pruebas justificativas.

6.4.4.14 El Evaluador debe dar su aprobación sobre el campo de aplicación y los contenidos del Plan de Validación del Software. Dicha aprobación debe contar también con una declaración relativa a la presencia del Evaluador durante los ensayos. 6.4.4.15 El Evaluador puede realizar auditorías e inspecciones (por ejemplo, presenciando los ensayos) en cualquier momento del proceso de desarrollo. El Evaluador puede solicitar un trabajo adicional de verificación y validación. NOTA Se considera una ventaja que el Evaluador se implique desde las etapas iniciales del proyecto.

6.4.4.16 Debe redactarse un Informe de Evaluación del Software bajo la responsabilidad del Evaluador. Los requisitos que se describen desde el apartado 6.4.4.17 al 6.4.4.19 hacen referencia al Informe de Evaluación del Software. 6.4.4.17 El Informe de Evaluación del Software debe cumplir los requisitos del Plan de Evaluación del Software, y proporcionar una conclusión y recomendaciones. 6.4.4.18 El Evaluador debe registrar sus actividades como base coherente para el Informe de Evaluación del Software. Éstas deben aparecer resumidas en el Informe de Evaluación del Software. 6.4.4.19 El Evaluador debe identificar y evaluar cualquier caso de no conformidad con los requisitos de esta norma europea y juzgar el impacto sobre el resultado final. El Informe de Evaluación del Software debe recoger dichos casos de no conformidad y los juicios que se emitan sobre ellos.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 34 -

6.5 Garantía de calidad del software 6.5.1 Objetivos 6.5.1.1 Identificar, supervisar y controlar toda actividad, tanto técnica como de gestión, necesaria para garantizar que el software alcanza la calidad requerida. Es necesario para proporcionar la defensa cualitativa necesaria contra errores sistemáticos y para garantizar que se puede establecer una pista de auditoría que permita realizar las actividades de verificación y validación de forma efectiva. 6.5.1.2 Proporcionar pruebas de que se han realizado las actividades antes mencionadas. 6.5.2 Documentos de entrada Todos aquellos documentos disponibles en cada etapa del ciclo de vida. 6.5.3 Documentos de salida 1) Plan de Garantía de Calidad del Software. 2) Plan de Gestión de la Configuración del Software, si no está disponible a nivel del sistema. 3) Informe de Verificación de Garantía de Calidad del Software. 6.5.4 Requisitos 6.5.4.1 Todos los planes deben comunicarse al inicio del proyecto y deben actualizarse durante el ciclo de vida. 6.5.4.2 Las organizaciones involucradas en el desarrollo del software deben implementar y usar un Sistema de Garantía de Calidad conforme con la Norma EN ISO 9000, para satisfacer los requisitos de esta norma europea. Es altamente recomendable la certificación de conformidad con la Norma EN ISO 9001. 6.5.4.3 Se debe redactar un Plan de Garantía de Calidad del Software, bajo la responsabilidad del verificador, tomando los documentos de entrada del apartado 6.5.2 como base. Los requisitos que se describen desde el apartado 6.5.4.4 al 6.5.4.6 hacen referencia al Plan de Garantía de Calidad del Software. 6.5.4.4 Se debe redactar un Plan de Garantía de Calidad del Software que debe ser específico para el proyecto. Dicho plan debe implementar los requisitos del apartado 6.5.4.5. 6.5.4.5 Se deben especificar o hacer referencia como mínimo a los siguientes elementos en el Plan de Garantía de Calidad del Software. a) Definición del modelo del ciclo de vida: 1) actividades y tareas básicas compatibles con los planes, por ejemplo, el Plan de Seguridad que se ha establecido a Nivel del sistema; 2) criterios de entrada y salida de cada actividad; 3) entradas y salidas de cada actividad; 4) principales actividades de calidad; 5) entidad responsable de cada actividad. b) Estructura de la documentación.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 35 -

EN 50128:2011

c) Control de la documentación: 1) roles de aquellos implicados en su redacción, control y aprobación; 2) campo de aplicación de la distribución; 3) archivo. d) Seguimiento y trazabilidad de las desviaciones. e) Métodos, medidas y herramientas para la garantía de calidad en función de los niveles de integridad de seguridad asignados (véase el anexo A). f) Justificaciones, como las definidas desde el apartado 4.7 al 4.9, de que cada combinación de técnicas o medidas seleccionada de acuerdo con el anexo A es apropiada para cada nivel definido de integridad de seguridad del software. Cierta información requerida en el Plan de Garantía de Calidad del Software puede aparecer en otros documentos, como en un Plan de Gestión de la Configuración del Software, un Plan de Mantenimiento, un Plan de Verificación del Software y un Plan de Validación del Software separados. Los apartados del Plan de Garantía de Calidad del Software deben proporcionar la referencia de los documentos en los que aparece la información. En cualquier caso, se debe especificar el contenido de cada apartado del Plan de Garantía de Calidad del Software, ya sea directamente o mediante referencia a otro documento. Se deben revisar los documentos referenciados para garantizar que proporcionan la información requerida y para garantizar que se corresponden con todos los requisitos de esta norma europea. 6.5.4.6 El Plan de Garantía de Calidad del Software debe recoger las referencias o especificaciones de las actividades, acciones, documentos, etc., relativos a la Garantía de calidad que se requieren en cada uno de los apartados normativos de esta norma europea y que se deben ajustar a cada proyecto específico. 6.5.4.7 Se debe redactar un Informe de Verificación de la Garantía de Calidad del Software, bajo la responsabilidad del Verificador, tomando los documentos de entrada del apartado 6.5.2 como base. El requisito en el apartado 6.5.4.8 hace referencia al Informe de Verificación de la Garantía de Calidad del Software. 6.5.4.8 Una vez que se haya establecido el Plan de Garantía de Calidad del Software, la verificación debe recoger: a) que el Plan de Garantía de Calidad del Software cumple con los requisitos generales de legibilidad y trazabilidad que se describen desde el apartado 5.3.2.7 hasta el apartado 5.3.2.10 y desde el apartado 6.5.4.14 hasta el apartado 6.5.4.17, así como los requisitos específicos descritos desde el apartado 6.5.4.4 al apartado 6.5.4.6; b) la coherencia interna del Plan de Garantía de Calidad del Software. Los resultados deben quedar registrados en un Informe de Verificación de la Garantía de Calidad del Software. 6.5.4.9 Cada documento de planificación debe disponer de un texto que especifique los detalles sobre su propia actualización durante el proyecto: frecuencia, responsabilidad, método. 6.5.4.10 Cada documento relativo al software y cada producto de software a entregar debe someterse al control de configuración desde la publicación de la primera versión. 6.5.4.11 Deben autorizarse y registrarse las modificaciones realizadas en los elementos bajo el Control de Gestión de la Configuración. 6.5.4.12 Además del desarrollo del software, el Sistema de Gestión de la Configuración debe cubrir también el entorno de desarrollo del software utilizado durante el ciclo de vida completo.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 36 -

Ésta extensión, necesaria para la reproductibilidad del desarrollo y para las actividades de mantenimiento, debe incluir todas las herramientas, traductores, archivos de datos y de ensayos, archivos de parametrización y plataformas de hardware que soportan a los elementos anteriores. 6.5.4.13 El proveedor debe establecer, documentar y mantener procedimientos para el control de los proveedores externos, incluyendo – los métodos y registros pertinentes destinados a garantizar que el software proporcionado por proveedores externos cumple con los requisitos establecidos. Se debe garantizar que el software desarrollado previamente cumple con el nivel requerido de integridad de seguridad del software y de fiabilidad de funcionamiento. El nuevo software debe desarrollarse y mantenerse conforme al Plan de Garantía de Calidad del Software del Proveedor o conforme a un Plan de Garantía de Calidad del Software específico preparado por el proveedor externo siguiendo el Plan de Garantía de Calidad del Software del Proveedor; – métodos y registros pertinentes para garantizar que los requisitos proporcionados al Proveedor Externo son los adecuados y están completos. 6.5.4.14 La trazabilidad de los requisitos debe ser una de las consideraciones importantes a tener en cuenta para la validación de un sistema relacionado con la seguridad y se deben proporcionar los medios que permitan demostrarla durante todas las fases del ciclo de vida. 6.5.4.15 Dentro del contexto de esta norma europea, y dentro de un límite apropiado al nivel de integridad de seguridad del software especificado, la trazabilidad debe hacer referencia principalmente a: a) la trazabilidad de los requisitos con respecto al diseño u otros objetos que los satisfagan; b) la trazabilidad de los objetos de diseño en relación a los objetos de implementación que los instancian; c) la trazabilidad de los requisitos y de los objetos de diseño en relación a los ensayos (componente, integración, ensayo de conjunto) y los análisis que los verifiquen. La trazabilidad debe ser parte de la Gestión de la Configuración. 6.5.4.16 En determinados casos, por ejemplo, para softwares preexistentes o para prototipos de software, la trazabilidad puede establecerse después de la implementación y/o documentación del código, pero antes de la verificación/validación. En estos casos, se debe demostrar que la verificación/validación es tan efectiva como lo hubiera sido con la trazabilidad en todas las fases. 6.5.4.17 Se debe demostrar que los objetos de especificación de los requisitos, del diseño o de la implementación que no puedan trazarse de forma adecuada no tienen influencia en la seguridad o en la integridad del sistema. 6.6 Modificaciones y control de las modificaciones 6.6.1 Objetivos 6.6.1.1 Garantizar que el software funciona como se requiere, preservando la integridad de seguridad del software y la fiabilidad de funcionamiento cuando se modifique el software. 6.6.1.2 El Gestor de Configuración gestiona estos objetivos. 6.6.2 Documentos de entrada 1) Plan de Garantía de Calidad del Software. 2) Plan de Gestión de la Configuración del Software.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 37 -

EN 50128:2011

3) Todo documento pertinente de diseño, de desarrollo y de análisis. 4) Solicitudes de modificación. 5) Análisis del impacto de las modificaciones y autorización para las modificaciones. 6.6.3 Documentos de salida 1) Todos los documentos de entrada modificados. 2) Registros de Modificaciones del Software (véase 9.2.4.11). 3) Registros de Nueva Configuración. 6.6.4 Requisitos 6.6.4.1 El Proceso de Gestión de las Modificaciones debe definir los siguientes aspectos como mínimo: a) la documentación necesaria para informar de un problema y/o para adoptar acciones correctivas, con el objetivo de informar a la dirección responsable; b) el análisis de la información recogida en los informes de problemas para identificar sus causas; c) las prácticas a seguir para informar, seguir y resolver problemas identificados durante la fase de desarrollo y durante el mantenimiento del software; d) las responsabilidades organizativas específicas en relación al desarrollo y al mantenimiento del software; e) cómo aplicar controles para garantizar que se han adoptado acciones correctivas y que son efectivas; f) el análisis de impacto del efecto de las modificaciones sobre el componente software que se encuentre en desarrollo o ya entregado; g) el análisis de impacto debe indicar la reverificación, revalidación y reevaluación necesarias para la modificación; h) cuando se apliquen múltiples modificaciones, el análisis de impacto debe tener en cuenta el impacto acumulado; NOTA La acumulación de varias modificaciones puede requerir un nuevo ensayo completo.

i) la autorización antes de la implementación. 6.6.4.2 Todas las modificaciones deben desencadenar un retorno a una fase apropiada del ciclo de vida. Todas las fases posteriores deben realizarse de acuerdo con los procedimientos especificados para las fases específicas de acuerdo con los requisitos definidos en esta norma europea. 6.7 Herramientas de soporte y lenguajes 6.7.1 Objetivos 6.7.1.1 El objetivo es proporcionar pruebas de que fallos potenciales de las herramientas no afectan negativamente a la seguridad de las salidas producidas por el conjunto de herramientas sin que se detecten mediante medidas técnicas o/y organizativas externas a la herramienta. Para ello, las herramientas de software se dividen en tres categorías, conocidas como T1, T2 y T3 (véanse las definiciones en 3.1).

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 38 -

Cuando se utilicen herramientas en lugar de operaciones manuales, se puede aportar la prueba de integridad de la salida de las herramientas mediante las mismas etapas de procesos que si la salida se hubiera producido mediante una operación manual. Estas etapas de procesos podrían sustituirse por métodos alternativos si se proporciona una argumentación sobre la integridad de la salida de las herramientas y si el nivel de integridad del software no disminuye por la sustitución. 6.7.2 Documentos de entrada Especificación o manual de las herramientas. 6.7.3 Documentos de salida Informe de validación de las herramientas (véanse 6.7.4.4 o 6.7.4.6, cuando sea necesario). 6.7.4 Requisitos 6.7.4.1 Las herramientas de software se deben seleccionar como parte coherente de las actividades de desarrollo del software. NOTA Deberían utilizarse herramientas apropiadas de ayuda al desarrollo del software para aumentar la integridad del software y reducir la probabilidad de introducción o de no detección de errores durante el desarrollo. Algunos ejemplos de herramientas apropiadas para las fases del ciclo de vida del desarrollo de software incluyen: a) herramientas de transformación o traducción que convierten una representación de software o de diseño (por ejemplo, un texto o un diagrama) de un nivel de abstracción a otro: herramientas para el refinamiento del diseño, compiladores, ensambladores, vinculadores, enlazadores, cargadores y herramientas de generación de código; b) herramientas de verificación y validación como los analizadores de código estáticos, controladores de cobertura de ensayos, simuladores y verificadores de modelo; c) herramientas de diagnóstico utilizadas para mantener y controlar el software en condiciones de funcionamiento; d) herramientas de infraestructura como los sistemas de ayuda al desarrollo; e)

herramientas de control de la configuración como las herramientas de control de las versiones;

f)

herramientas de datos de aplicación que producen o mantienen datos necesarios para definir parámetros y para instanciar funciones del sistema, como por ejemplo, parámetros de función, rangos de los instrumentos, niveles de alarma y desconexión, estados de salida a adoptar ante fallos, distribución geográfica.

Las herramientas seleccionadas deberían poder cooperar. En este contexto, las herramientas cooperan si las salidas de una herramienta tienen el contenido y el formato adecuados para que se introduzcan como entradas en otra herramienta de forma automática, reduciendo así al máximo la posibilidad de que se introduzcan errores humanos en la manipulación de resultados intermedios. La elección de las herramientas debe basarse en su compatibilidad con las necesidades de la aplicación. Se debe tener en cuenta la disponibilidad de herramientas adecuadas para proporcionar los servicios necesarios durante toda la vida útil del software.

6.7.4.2 Se debe justificar la elección de herramientas de clase T2 y T3 (véase 7.3.4.12). La justificación debe incluir la identificación de fallos potenciales que pueden inyectarse en las salidas de las herramientas y las medidas para evitar o gestionar dichos fallos. 6.7.4.3 Las herramientas de las clases T2 y T3 deben contar con una especificación o un manual que defina claramente el comportamiento de la herramienta y con las instrucciones o restricciones que pudieran existir relativas a su uso. 6.7.4.4 Cada herramienta de clase T3 debe disponer de pruebas que demuestren que la salida de la herramienta cumple con la especificación de la salida o que demuestren que se detectan los fallos en la salida. Las pruebas pueden basarse en las mismas etapas que son necesarias para el proceso manual cuando se sustituye la herramienta y en un argumento si son posibles diferentes tipos de pruebas (por ejemplo, la validación de la herramienta). Las pruebas pueden basarse también en:

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 39 -

EN 50128:2011

a) una combinación adecuada de usos anteriores que tuvieron éxito en entornos similares y en aplicaciones similares (dentro de la organización o de otras organizaciones); b) la validación de la herramienta como se especifica en el apartado 6.7.4.5; c) los diversos códigos redundantes que permiten la detección y el control de fallos que resultan de los errores introducidos por una herramienta; d) la conformidad con los niveles de integridad de seguridad que se derivan del análisis de riesgos aplicado al proceso y a los procedimientos, incluyendo las herramientas; e) otros métodos apropiados para evitar o gestionar los fallos introducidos por las herramientas. NOTA 1 Un historial de las versiones puede proporcionar garantías sobre la madurez de la herramienta, y un registro de errores/ambigüedades asociadas con su uso en el entorno. NOTA 2 La prueba descrita para la herramienta de tipo T3 se puede utilizar también con herramientas de tipo T2 para juzgar la corrección de sus resultados.

6.7.4.5 Los resultados de la validación de la herramienta deben documentarse y se deben cubrir los siguientes resultados: a) un registro de las actividades de validación; b) la versión del manual de herramienta utilizado; c) las funciones de la herramienta validadas; d) herramientas y equipo usado; e) resultados de la actividad de validación; los resultados documentados de la validación deben indicar las razones por las que el software ha pasado la validación o las razones por las que ha sido rechazado; f) casos de ensayos y sus resultados para su análisis posterior; g) discrepancia entre los resultados obtenidos y los que estaban previstos. 6.7.4.6 Cuando no estén disponibles las pruebas de conformidad descritas en el apartado 6.7.4.4, se debe disponer de medidas efectivas para controlar los fallos del software ejecutable relacionado con la seguridad que se producen por errores atribuibles a la herramienta. NOTA 1 Un ejemplo es la generación de códigos redundantes diversos que permiten la detección y el control de fallos que provocan que un traductor introduzca errores. NOTA 2 Como ejemplo, la validez de un compilador no seguro puede justificarse de la siguiente forma. Se ha sometido al código objeto producido por el compilador a una combinación de ensayos, controles y análisis capaces de garantizar la corrección del código hasta el punto de ser compatible con el Nivel de Integridad de la Seguridad. En particular, se aplica lo siguiente a todos los ensayos, controles y análisis. – Se ha demostrado que los ensayos tienen una cobertura lo suficientemente alta del código implementado. Si hay códigos inaccesibles por medio de ensayos, se ha demostrado por medio de controles y análisis que la función concernida se ejecuta correctamente cuando se alcanza el código en el objetivo. – Se han aplicado los controles y análisis al código objeto y se ha demostrado que son capaces de detectar los tipos de errores que podrían producirse por un defecto en el compilador. –

Después de los ensayos, controles y análisis, no ha tenido lugar ninguna traducción más con el compilador.

–

Si se realizan más compilaciones o traducciones, se repetirán todos los ensayos, controles y análisis.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 40 -

6.7.4.7 La representación del software o del diseño seleccionada (incluido el lenguaje de programación) debe: a) disponer de un traductor que haya sido evaluado en relación a su validez, incluyendo, cuando proceda, su evaluación en relación a normas nacionales o internacionales; b) ser compatible con las características de la aplicación; c) contener las características que faciliten la detección de errores de diseño o de programación; d) soportar características compatibles con el método de diseño. Un lenguaje de programación es una clase de representación del software o del diseño. Un Traductor convierte una representación del software o del diseño (por ejemplo, un texto o un diagrama) de un nivel de abstracción en otro. Como ejemplos de Traductores se pueden citar a las herramientas para el refinamiento del diseño, a los compiladores, ensambladores, vinculadores, enlazadores, cargadores y a las herramientas de generación de código. La evaluación de un Traductor puede realizarse para un proyecto de aplicación específico o para una clase de aplicaciones. En este último caso, el usuario de la herramienta debe disponer de toda la información necesaria relativa al uso previsto y apropiado de la herramienta. La evaluación de la herramienta para un proyecto específico se puede reducir entonces a la comprobación general de la idoneidad de la herramienta para el proyecto y su conformidad con la "especificación o manual" (es decir, la utilización correcta de la herramienta). La utilización correcta podría incluir actividades de verificación adicionales dentro del proyecto específico. Se puede utilizar un paquete de validación para evaluar la validez de un Traductor en función de criterios definidos, que debe incluir requisitos funcionales y no funcionales. Para los requisitos funcionales del Traductor, los ensayos dinámicos pueden ser la técnica de validación principal. Si es posible, se debe usar un paquete de ensayos automáticos. 6.7.4.8 Cuando no se pueda cumplir totalmente con el apartado 6.7.4.7, se debe justificar y evaluar la validez del lenguaje y de cualquier medida adicional que haga referencia a cualquier deficiencia identificada del lenguaje. NOTA Véase la nota 2 en el apartado 6.7.4.6.

6.7.4.9 Cuando se produzca una generación automática de código o una traducción automática similar, se debe evaluar la idoneidad del Traductor automático para el desarrollo de software relacionado con la seguridad en el punto del ciclo de vida del desarrollo en el que se seleccionen las herramientas de ayuda al desarrollo. 6.7.4.10 La gestión de la configuración debe garantizar que para las herramientas de clase T2 y T3 solo se utilizan las versiones justificadas. 6.7.4.11 Se debe justificar cada versión nueva de una herramienta que se utilice (véase la tabla 1). Ésta justificación puede basarse en pruebas proporcionadas para una versión anterior si se demuestra de manera suficiente que: a) las diferencias funcionales (si las hubiera) no afectarán a la compatibilidad de la herramienta con el resto del conjunto de herramientas; b) no es probable que la nueva versión contenga errores significativos nuevos y desconocidos. NOTA Las pruebas de que la nueva versión no es susceptible de contener errores significativos nuevos y desconocidos se pueden basar en una identificación creíble de las modificaciones realizadas y en un análisis de las acciones de verificación y validación que se han realizado.

6.7.4.12

En la tabla 1 se define la relación entre las clases de herramientas y los apartados aplicables.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 41 -

EN 50128:2011

Tabla 1 – Relación entre las clases de herramientas y los apartados aplicables Clase de herramienta

Apartados aplicables

T1

6.7.4.1

T2

6.7.4.1, 6.7.4.2, 6.7.4.3, 6.7.4.10, 6.7.4.11

T3

6.7.4.1, 6.7.4.2, 6.7.4.3, 6.7.4.4, 6.7.4.5 o 6.7.4.6, 6.7.4.7, 6.7.4.8, 6.7.4.9, 6.7.4.10, 6.7.4.11

7 DESARROLLO DE SOFTWARE GENÉRICO 7.1 Ciclo de vida y documentación para software genérico 7.1.1 Objetivos 7.1.1.1 Proporcionar una descripción del software, desde los niveles de abstracción más altos hasta los niveles de refinamiento más detallados, con el fin de crear un marco para la demostración de la seguridad alcanzada así como para las futuras acciones de mantenimiento. 7.1.2 Requisitos 7.1.2.1 Se deben generar los documentos que se enumeran en la tabla A.1 para un software genérico, dentro del alcance requerido por el nivel de integridad de seguridad del software. 7.1.2.2 La secuencia de documentos a entregar descritas en la tabla A.1 refleja un modelo en cascada lineal ideal. Sin embargo, este modelo no está destinado a ser una referencia en lo que se refiere a la programación y relación de las actividades, ya que normalmente en la práctica sería difícil garantizar una conformidad estricta con el modelo. Las fases pueden solaparse pero las actividades de verificación y validación deben demostrar la coherencia de las entradas y salidas (documentos y software) dentro de las fases y entre éstas. Sin embargo, el objetivo principal de la documentación prevista es el de proporcionar una descripción del software, desde los niveles de abstracción más altos hasta los niveles de refinamiento más detallados, con el fin de crear un marco para la demostración de la seguridad alcanzada así como para las futuras acciones de mantenimiento. 7.2 Requisitos del Software 7.2.1 Objetivos 7.2.1.1 Describir un conjunto completo de requisitos para el software que cumpla todos los Requisitos del Sistema y de Seguridad y proporcione un conjunto exhaustivo de documentos para cada fase posterior. 7.2.1.2 Describir la Especificación de Ensayos del Software en Conjunto. 7.2.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) Especificaciones de la Interfaz Externa (por ejemplo, Especificación de la Interfaz del Software/Software, Especificación de la Interfaz del Software/Hardware).

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 42 -

5) Plan de Garantía de Calidad del Software. 6) Plan de Validación del Software. 7.2.3 Documentos de salida 1) Especificación de Requisitos del Software. 2) Especificación de Ensayos del Software en Conjunto. 3) Informe de Verificación de los Requisitos del Software. 7.2.4 Requisitos 7.2.4.1 Se debe redactar una Especificación de Requisitos del Software, bajo la responsabilidad del Gestor de Requisitos, tomando los documentos de entrada descritos en el apartado 7.2.2 como base. Los requisitos que se describen desde el apartado 7.2.4.2 al 7.2.4.15 hacen referencia a la Especificación de Requisitos del Software. 7.2.4.2 La Especificación de Requisitos del Software debe recoger las propiedades requeridas del software que se está desarrollando. Estas propiedades, definidas (a excepción de la seguridad) en la serie de Normas ISO/IEC 9126 deben incluir: a) la funcionalidad (incluidas la capacidad y las características del tiempo de respuesta); b) la robustez y mantenibilidad; c) la seguridad (incluidas las funciones de seguridad y sus niveles de integridad de seguridad del software asociados); d) la eficiencia; e) la usabilidad; f) la portabilidad. 7.2.4.3 El nivel de integridad de seguridad del software debe deducirse como se describe en el capítulo 4 y debe registrarse en la Especificación de Requisitos del Software. 7.2.4.4 Dentro del alcance requerido por el nivel de integridad de seguridad del software, la Especificación de Requisitos del Software debe expresarse y estructurarse de forma que sea: a) completa, clara, precisa, inequívoca, verificable, que se pueda someter a ensayo, que se pueda mantener y sea realizable; b) trazable hasta los documentos de entrada. 7.2.4.5 La Especificación de Requisitos del Software debe incluir modos de expresión y descripciones comprensibles para el personal responsable implicado en el ciclo de vida del software. 7.2.4.6 La Especificación de Requisitos del Software debe identificar y documentar todas las interfaces con otros sistemas, que se encuentren en el interior o en el exterior del equipo sometido a control, incluidos los operadores, cada vez que exista o esté prevista una conexión directa. 7.2.4.7 Deben detallarse todos los modos de funcionamiento pertinentes en la Especificación de Requisitos del Software.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 43 -

EN 50128:2011

7.2.4.8 Debe hacerse referencia o deben documentarse (por ejemplo, en la documentación a nivel del sistema) todos los modos de comportamiento pertinentes de los sistemas electrónicos programables, en particular, el comportamiento de fallo, en la Especificación de Requisitos del Software. 7.2.4.9 Debe hacerse referencia o debe documentarse cualquier restricción entre hardware y software (por ejemplo, en la documentación a nivel del sistema) en la Especificación de Requisitos del Software. 7.2.4.10 La Especificación de Requisitos del Software debe considerar, dentro del alcance requerido en la descripción de la documentación del sistema, la autocomprobación del software y la comprobación del hardware por parte del software. La autocomprobación del software consiste en la detección y en el envío de un informe por parte del software de sus propios fallos y errores. 7.2.4.11 La Especificación de Requisitos del Software debe incluir requisitos para los ensayos periódicos de funciones dentro del alcance requerido por la Especificación de Requisitos de Seguridad del Sistema. 7.2.4.12 La Especificación de Requisitos del Software debe incluir requisitos que permitan someter a ensayo a todas las funciones de seguridad durante el funcionamiento global del sistema dentro del alcance requerido por la Especificación de Requisitos de Seguridad del Sistema. 7.2.4.13 La Especificación de Requisitos del Software debe identificar claramente todas las funciones que el software vaya a realizar, y en especial aquellas que estén relacionadas con alcanzar el nivel requerido de integridad de seguridad del sistema. 7.2.4.14 La Especificación de Requisitos del Software debe identificar claramente cualquier función no relacionada con la seguridad que se requiera que realice el software. 7.2.4.15 La Especificación de Requisitos del Software debe apoyarse en las técnicas y medidas descritas en la tabla A.2. La combinación seleccionada debe justificarse como un conjunto que satisfaga los apartados 4.8 y 4.9. 7.2.4.16 Se debe redactar una Especificación de Ensayos del Software en Conjunto bajo la responsabilidad del Encargado de los Ensayos, tomando como base la Especificación de Requisitos del Software. Los requisitos que se describen desde el apartado 7.2.4.17 al 7.2.4.19 hacen referencia a la Especificación de Ensayos del Software en Conjunto. 7.2.4.17 La Especificación de Ensayos del Software en Conjunto debe ser una descripción de los ensayos a realizar en el software terminado. 7.2.4.18 La Especificación de Ensayos del Software en Conjunto debe seleccionar técnicas y medidas de entre las enumeradas en la tabla A.7. La combinación seleccionada debe justificarse como un conjunto que satisfaga los apartados 4.8 y 4.9. 7.2.4.19 La Especificación de Ensayos del Software en Conjunto debe identificar los casos de ensayos para cada una de las funciones requeridas, incluyendo: a) las señales de entrada requeridas con sus secuencias y sus valores; b) las señales de salida esperadas con sus secuencias y sus valores; c) los criterios de éxito para los ensayos, incluyendo los aspectos de las prestaciones y la calidad. 7.2.4.20 Se debe redactar un Informe de Verificación de los Requisitos del Software, bajo la responsabilidad del Verificador, tomando como base la Especificación de Requisitos de Seguridad del Sistema, la Especificación de Requisitos del Software, la Especificación de Ensayos del Software en Conjunto y el Plan de Garantía de Calidad del Software.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 44 -

Los requisitos que se describen desde el apartado 7.2.4.21 al 7.2.4.22 hacen referencia al Informe de Verificación de los Requisitos del Software. 7.2.4.21 El Informe de Verificación de los Requisitos del Software debe redactarse de acuerdo con los requisitos generales establecidos para todos los Informes de Verificación (véase 6.2.4.13). 7.2.4.22

Una vez que se haya establecido la Especificación de Requisitos del Software, la verificación debe recoger:

a) la adecuación de la Especificación de Requisitos del Software para cumplir con 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 Garantía de Calidad del Software; b) que la Especificación de Requisitos del Software cumple con los requisitos generales de legibilidad y trazabilidad que se describen desde el apartado 5.3.2.7 hasta el apartado 5.3.2.10 y desde el apartado 6.5.4.14 hasta el apartado 6.5.4.17, así como los requisitos específicos descritos desde el apartado 7.2.4.2 al apartado 7.2.4.15; c) la adecuación de la Especificación de Ensayos del Software en Conjunto como un ensayo en relación a la Especificación de Requisitos del Software; d) la definición de cualquier actividad adicional para demostrar la cobertura correcta de requisitos que no se pueden someter a ensayo; e) la coherencia interna de la Especificación de Requisitos del Software; f) la adecuación de la Especificación de Requisitos del Software para cumplir o tener en cuenta las restricciones entre hardware y software. Los resultados deben quedar registrados en un Informe de Verificación de los Requisitos del Software. 7.3 Arquitectura y diseño 7.3.1 Objetivos 7.3.1.1 Desarrollar una arquitectura del software que satisfaga los requisitos del mismo. 7.3.1.2 Identificar y evaluar la importancia para la seguridad de las interacciones hardware/software. 7.3.1.3 Seleccionar un método de diseño si no se hubiera definido uno previamente. 7.3.1.4 Diseñar software con un nivel definido de integridad de seguridad del software a partir de los documentos de entrada. 7.3.1.5 Garantizar que el sistema resultante y su software se podrán someter a ensayos fácilmente desde el principio. Ya que la verificación y los ensayos son elementos cruciales en la validación, se debe prestar atención en particular a las necesidades en materia de verificación y ensayos que se produzcan durante toda la implementación. 7.3.2 Documentos de entrada 1) Especificación de Requisitos del Software. 7.3.3 Documentos de salida 1) Especificación de la Arquitectura del Software. 2) Especificación de Diseño del Software.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 45 -

EN 50128:2011

3) Especificaciones de la Interfaz del Software. 4) Especificación de Ensayos de Integración del Software. 5) Especificación de Ensayos de Integración del Software/Hardware. 6) Informe de Verificación de Diseño y Arquitectura del Software. 7.3.4 Requisitos 7.3.4.1 Se debe redactar una Especificación de la Arquitectura del Software bajo la responsabilidad del Diseñador, tomando como base la Especificación de Requisitos del Software. Los requisitos que se describen desde el apartado 7.3.4.2 al 7.3.4.14 hacen referencia a la Especificación de la Arquitectura del Software. 7.3.4.2 La arquitectura del software propuesta debe establecerse y detallarse en la Especificación de la Arquitectura del Software. 7.3.4.3 La Especificación de la Arquitectura del Software debe recoger la viabilidad de realización de la Especificación de Requisitos del Software al nivel requerido de integridad de seguridad del software. NOTA La Arquitectura del Software debería minimizar el tamaño y la complejidad de la parte relativa a la seguridad de la aplicación.

7.3.4.4 La Especificación de la Arquitectura del Software debe identificar, analizar y detallar la importancia de las interacciones hardware/software. 7.3.4.5 La Especificación de la Arquitectura del Software debe identificar todos los componentes software y debe determinar para estos componentes: a) si estos componentes son nuevos o ya existían; b) si estos componentes se han validado de forma previa y de ser así, sus condiciones de validación; c) el nivel de integridad de seguridad del software del componente. 7.3.4.6 Los componentes software deben: a) cubrir un subconjunto definido de requisitos del software; b) estar identificados de manera clara y constituir versiones independientes dentro del sistema de gestión de la configuración. 7.3.4.7 El uso de software preexistente debe quedar sujeto a las siguientes restricciones. a) Para todos los niveles de integridad de seguridad del software se debe identificar y documentar claramente la siguiente información: – los requisitos que el software preexistente está destinado a satisfacer; – las hipótesis relativas al entorno del software preexistente; – las interfaces con otras partes del software. b) Para todos los niveles de integridad de seguridad del software se debe incluir el software preexistente en el proceso de validación del software completo.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 46 -

c) Para los niveles de integridad de seguridad del software SIL 3 o SIL 4, se deben tomar las siguientes precauciones: – se debe realizar un análisis de los posibles fallos del software preexistente y sus consecuencias en el software completo; – se debe definir una estrategia para detectar fallos del software preexistente y para proteger al sistema de estos fallos; – los procesos de verificación y validación deben garantizar 1) que el software preexistente cumple los requisitos asignados, 2) que se detectan los fallos del software preexistente y que el sistema en el que el software preexistente está integrado está protegido de esos fallos, 3) que se cumplen las hipótesis relativas al entorno del software preexistente. d) El software preexistente debe ir acompañado de una descripción (es decir, las funciones, las restricciones y las pruebas) lo suficientemente precisa (por ejemplo, que se limite a las funciones utilizadas) y completa. La descripción debe incluir las restricciones de hardware y/o software que el integrador debe conocer y tener en cuenta durante la aplicación. Es el medio en particular utilizado para informar al integrador de para qué se diseñó el software, de sus propiedades, de su comportamiento y de sus características. NOTA Se pueden utilizar pruebas estadísticas en la estrategia de validación del software preexistente.

7.3.4.8 En la medida de lo posible, se prefiere el uso de componentes software verificados existentes, desarrollados conforme a esta norma europea en lo que se refiere al diseño. 7.3.4.9 Cuando el software está constituido por componentes con diferentes niveles de integridad de seguridad del software, entonces, se debe tratar a todos los componentes software como si tuvieran el más alto de estos niveles a menos que se disponga de pruebas de independencia entre los componentes con un nivel de integridad de seguridad del software más alto y los componentes con un nivel de integridad de seguridad del software más bajo. Dichas pruebas deben quedar registradas en la Especificación de la Arquitectura del Software. 7.3.4.10 La Especificación de la Arquitectura del Software debe describir la estrategia para el desarrollo del software dentro del alcance requerido por el nivel de integridad de seguridad del software. La Especificación de la Arquitectura del Software debe expresarse y estructurarse de forma que sea: a) completa, coherente, clara, precisa, inequívoca, verificable, que se pueda someter a ensayo, que se pueda mantener y que sea realizable; b) trazable hasta la Especificación de Requisitos del Software. 7.3.4.11 La Especificación de la Arquitectura del Software debe incluir las medidas para gestionar los errores con el fin de alcanzar el equilibrio entre las estrategias para evitar errores y las estrategias de tolerancia a errores. 7.3.4.12 La Especificación de la Arquitectura del Software debe justificar que las técnicas, medidas y herramientas elegidas forman un conjunto que satisface la Especificación de Requisitos del Software al nivel requerido de integridad de seguridad del software. 7.3.4.13 La Especificación de la Arquitectura del Software debe tener en cuenta los requisitos del apartado 8.4.8 cuando el software esté configurado mediante datos o algoritmos de aplicación. 7.3.4.14 La Especificación de la Arquitectura del Software debe seleccionar técnicas y medidas de entre las enumeradas en la tabla A.3. La combinación seleccionada debe justificarse como un conjunto que satisfaga los apartados 4.8 y 4.9.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 47 -

7.3.4.15

EN 50128:2011

El tamaño y la complejidad de la arquitectura del software desarrollada deben estar equilibrados.

7.3.4.16 Se pueden utilizar prototipos en cualquier fase para identificar los requisitos o para obtener una vista más detallada sobre los requisitos y sus consecuencias. 7.3.4.17 Se puede usar el código de un prototipo en el sistema objetivo solo si se demuestra que el código y su desarrollo y documentación cumplen con los requisitos de esta norma europea. 7.3.4.18 Se debe redactar una Especificación de la Interfaz del Software para todas las Interfaces entre los componentes software y el límite del software global, bajo la responsabilidad del Diseñador, tomando como base la Especificación de Requisitos del Software y la Especificación de la Arquitectura del Software. El requisito del apartado 7.3.4.19 hace referencia a la Especificación de la Interfaz del Software. 7.3.4.19

La descripción de las interfaces debe recoger:

a) las precondiciones/postcondiciones; b) la definición y descripción de todos los valores límite para todos los datos especificados; c) el comportamiento cuando se sobrepasa el valor límite; d) el comportamiento cuando el valor está en el límite; e) para los datos de entrada y de salida de tiempos críticos: 1) restricciones de tiempo y requisitos para un funcionamiento correcto, 2) gestión de las excepciones; f) la memoria asignada para los búfer de la interfaz y los mecanismos para detectar que la memoria no puede ser asignada o que todos los búfer están llenos, según el caso; g) existencia de mecanismos de sincronización entre funciones [véase el punto e)]. Se deben definir todos los datos que provengan y tengan como destino las interfaces para el rango completo de valores definidos por el tipo de datos, incluidos los intervalos que no se utilizan cuando son procesados por las funciones: a) definición y descripción de todas las clases de equivalencia para todos los datos especificados y cada función del software que las utiliza; b) definición de clases de equivalencia no utilizadas o prohibidas. NOTA Los tipos de datos incluyen los siguientes: 1) parámetros de entrada y resultados de salida de las funciones y/o procedimientos; 2) datos especificados en los telegramas o paquetes de comunicación; 3) datos del hardware.

7.3.4.20 Debe redactarse una Especificación de Diseño del Software bajo la responsabilidad del Diseñador, tomando como base la Especificación de Requisitos del Software, la Especificación de la Arquitectura del Software y la Especificación de la Interfaz del Software. Los requisitos que se describen desde el apartado 7.3.4.21 al 7.3.4.24 hacen referencia a la Especificación de Diseño del Software.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 48 -

7.3.4.21 Los documentos de entrada deben estar disponibles, aunque no necesariamente finalizados, antes del inicio del proceso de diseño. 7.3.4.22 La Especificación de Diseño del Software debe describir el diseño del software basándose en un desglose en componentes, con cada componente constando de una Especificación de Diseño de los Componentes Software y una Especificación de Ensayos de los Componentes Software. 7.3.4.23

La Especificación de Diseño del Software debe describir:

a) los componentes software trazados hasta la arquitectura del software y sus niveles de integridad de la seguridad; b) las interfaces de los componentes software con su entorno; c) las interfaces entre los componentes software; d) las estructuras de datos; e) la asignación y trazabilidad de los requisitos sobre los componentes; f) los algoritmos principales y la secuenciación; g) los mecanismos de informe de error. 7.3.4.24 La Especificación de Diseño del Software debe seleccionar técnicas y medidas de entre las enumeradas en la tabla A.4. La combinación seleccionada debe justificarse como un conjunto que satisfaga los apartados 4.8 y 4.9. 7.3.4.25

Se deben desarrollar normas de codificación que especifiquen:

a) las buenas prácticas de programación, como las definidas en la tabla A.12; b) las medidas para evitar o detectar errores que puedan realizarse durante la aplicación del lenguaje y no puedan detectarse durante la verificación (véanse 7.5 y 7.6). Dichos fallos se deducen mediante análisis de todas las características del lenguaje; c) procedimientos para la documentación del código fuente. 7.3.4.26 La selección de una norma de codificación debe justificarse dentro del alcance requerido por el nivel de integridad de seguridad del software. 7.3.4.27 Las normas de codificación deben utilizarse para el desarrollo de todo el software y se debe hacer referencia a ellas en el Plan de Garantía de Calidad del Software. 7.3.4.28 De acuerdo con el nivel requerido de integridad de seguridad del software, el método de diseño elegido debe contar con características que faciliten: a) la abstracción, modularidad y otras características que controlen la complejidad; b) la expresión clara y precisa de 1) la funcionalidad, 2) el flujo de información entre componentes, 3) la secuenciación y la información relativa al tiempo, 4) la concurrencia, 5) la estructura y las propiedades de los datos;

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 49 -

EN 50128:2011

c) la comprensión humana; d) la verificación y la validación; e) el mantenimiento del software. 7.3.4.29 Debe redactarse una Especificación de Ensayos de Integración del Software bajo la responsabilidad del Integrador, tomando como base la Especificación de Requisitos del Software, la Especificación de la Arquitectura del Software, la Especificación de Diseño del Software y las Especificaciones de la Interfaz del Software. Los requisitos que se describen desde el apartado 7.3.4.30 al 7.3.4.32 hacen referencia a la Especificación de Ensayos de Integración del Software. 7.3.4.30 La Especificación de Ensayos de Integración del Software debe redactarse de acuerdo con los requisitos genéricos establecidos para una Especificación de Ensayos (véase 6.1.4.4). 7.3.4.31

La Especificación de Ensayos de Integración del Software debe recoger lo siguiente:

a) se debe demostrar que cada componente software proporciona las interfaces especificadas para los otros componentes ejecutando los componentes juntos; b) se debe demostrar que el software se comporta de manera apropiada cuando la interfaz está sujeta a entradas que están fuera de la especificación; c) los datos de entrada requeridos con sus secuencias y sus valores deben ser la base de los casos de ensayo; d) los datos anticipados de salida con sus secuencias y sus valores deben ser la base de los casos de ensayo; e) se debe mostrar qué resultados del ensayo de los componentes (véanse 7.5.4.5 y 7.5.4.7) están destinados a reutilizarse para el ensayo de integración del software. 7.3.4.32 La Especificación de Ensayos de Integración del Software debe seleccionar técnicas y medidas de entre las enumeradas en la tabla A.5. La combinación seleccionada debe justificarse como un conjunto que satisfaga los apartados 4.8 y 4.9. 7.3.4.33 Debe redactarse una Especificación de Ensayos de Integración del Software/Hardware, bajo la responsabilidad del Integrador, tomando como base la Descripción del Diseño del Sistema, la Especificación de Requisitos del Software, la Especificación de la Arquitectura del Software y la Especificación de Diseño del Software. Los requisitos que se describen desde el apartado 7.3.4.34 al 7.3.4.39 hacen referencia a la Especificación de Ensayos de Integración del Software/Hardware. 7.3.4.34 Debería crearse una Especificación de Ensayos de Integración del Software/Hardware al inicio del ciclo de vida de desarrollo para que se puedan gestionar correctamente los ensayos de integración y para que se puedan asegurar de forma correcta las necesidades particulares en materia de diseño o integración. Dependiendo del tamaño del sistema, la Especificación de Ensayos de Integración del Software/Hardware puede subdividirse durante el desarrollo en una serie de subdocumentos que serán completados de manera natural a medida que los diseños de hardware y software evolucionan y las necesidades detalladas de integración se hacen más claras. 7.3.4.35 La Especificación de Ensayos de Integración del Software/Hardware debe diferenciar entre aquellas actividades que el proveedor puede realizar en sus instalaciones y aquellas que requieren el acceso a las instalaciones del usuario. 7.3.4.36

La Especificación de Ensayos de Integración del Software/Hardware debe tratar los puntos siguientes:

a) se debe demostrar que el software funciona de manera correcta en el hardware utilizando el hardware por medio de las interfaces de hardware especificadas;

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 50 -

b) se debe demostrar que el software puede gestionar errores en el hardware según se requiera; c) se deben demostrar la temporización y las prestaciones requeridas; d) los datos de entrada requeridos con sus secuencias y sus valores deben ser la base de los casos de ensayo; e) los datos anticipados de salida con sus secuencias y sus valores deben ser la base de los casos de ensayo; f) se debe mostrar qué resultados del ensayo de componentes (véase 7.5.4.5) y del ensayo de integración del software (véase 7.6.4.3) están destinados a reutilizarse en el ensayo de integración del software/hardware. 7.3.4.37

La Especificación de Ensayos de Integración del Software/Hardware debe documentar lo siguiente:

a) los casos de ensayo y los datos de ensayo; b) los tipos de ensayos a realizar; c) el entorno de ensayo, incluidas las herramientas, el software de soporte y la descripción de la configuración; d) los criterios de los ensayos que servirán para juzgar la consecución o no del ensayo. 7.3.4.38 La Especificación de Ensayos de Integración del Software/Hardware debe redactarse de acuerdo con los requisitos genéricos establecidos para una Especificación de Ensayos (véase 6.1.4.4). 7.3.4.39 La Especificación de Ensayos de Integración del Software/Hardware debe seleccionar técnicas y medidas de entre las enumeradas en la tabla A.5. La combinación seleccionada debe justificarse como un conjunto que satisfaga los apartados 4.8 y 4.9. 7.3.4.40 Se debe redactar un Informe de Verificación de Diseño y Arquitectura del Software bajo la responsabilidad del Verificador, tomando como base la Especificación de Requisitos del Software, la Especificación de la Arquitectura del Software, la Especificación de Diseño del Software, la Especificación de Ensayos de Integración del Software y la Especificación de Ensayos de Integración del Software/Hardware. Los requisitos que se describen desde el apartado 7.3.4.41 al 7.3.4.43 hacen referencia al Informe de Verificación de Diseño y Arquitectura del Software. 7.3.4.41 El Informe de Verificación de Diseño y Arquitectura del Software debe redactarse de acuerdo con los requisitos genéricos establecidos para un Informe de Verificación (véase 6.2.4.13). 7.3.4.42 Después de que se hayan establecido las Especificaciones de Arquitectura, Interfaz y Diseño del Software, la verificación debe recoger: a) la coherencia interna de las Especificaciones de Arquitectura, Interfaz y Diseño del Software; b) la adecuación de las Especificaciones de Arquitectura, Interfaz y Diseño del Software para satisfacer la Especificación de Requisitos del Software en lo que se refiere a la coherencia y compleción; c) que la Especificación de la Arquitectura del Software cumple con los requisitos generales de legibilidad y trazabilidad que se describen desde el apartado 5.3.2.7 hasta el apartado 5.3.2.10, y desde el apartado 6.5.4.14 hasta el apartado 6.5.4.16, así como los requisitos específicos descritos desde el apartado 7.3.4.1 al apartado 7.3.4.14; d) que la Especificación de la Interfaz del Software cumple con los requisitos generales de legibilidad y trazabilidad que se describen desde el apartado 5.3.2.7 hasta el apartado 5.3.2.10, y desde el apartado 6.5.4.14 hasta el apartado 6.5.4.16, así como los requisitos específicos descritos desde el apartado 7.3.4.18 al apartado 7.3.4.19;

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 51 -

EN 50128:2011

e) que la Especificación de Diseño del Software cumple con los requisitos generales de legibilidad y trazabilidad que se describen desde el apartado 5.3.2.7 hasta el apartado 5.3.2.10, y desde el apartado 6.5.4.14 hasta el apartado 6.5.4.16, así como los requisitos específicos descritos desde el apartado 7.3.4.20 al apartado 7.3.4.24; f) la adecuación de la Especificación de la Arquitectura del Software y de la Especificación de Diseño del Software para tener en cuenta las restricciones de hardware y software. Los resultados deben quedar registrados en un Informe de Verificación de Diseño y Arquitectura del Software. 7.3.4.43 Después de que se hayan establecido las Especificaciones de Ensayos de Integración del Software y del Software/Hardware, la verificación debe recoger: a) que la Especificación de Ensayos de Integración del Software cumple con los requisitos generales de legibilidad y trazabilidad que se describen desde el apartado 5.3.2.7 hasta el apartado 5.3.2.10, y desde el apartado 6.5.4.14 hasta el apartado 6.5.4.16, así como los requisitos específicos descritos desde el apartado 7.3.4.29 al apartado 7.3.4.32; b) que la Especificación de Ensayos de Integración del Software/Hardware cumple con los requisitos generales de legibilidad y trazabilidad que se describen desde el apartado 5.3.2.7 hasta el apartado 5.3.2.10, y desde el apartado 6.5.4.14 hasta el apartado 6.5.4.16, así como los requisitos específicos descritos desde el apartado 7.3.4.33 al apartado 7.3.4.39. Los resultados deben quedar registrados en un Informe de Verificación de Diseño y Arquitectura del Software. 7.4 Diseño de componentes 7.4.1 Objetivos 7.4.1.1 Desarrollar un Diseño de Componentes Software que satisfaga los requisitos de la Especificación de Diseño del Software dentro del alcance requerido por el nivel de integridad de seguridad del software. 7.4.1.2 Desarrollar una Especificación de Ensayos de los Componentes Software que satisfaga los requisitos de la Especificación de Diseño de los Componentes Software dentro del alcance requerido por el nivel de integridad de seguridad del software. 7.4.2 Documentos de entrada 1) Especificación de Diseño del Software. 7.4.3 Documentos de salida 1) Especificación de Diseño de los Componentes Software. 2) Especificación de Ensayos de los Componentes Software. 3) Informe de Verificación del Diseño de los Componentes Software. 7.4.4 Requisitos 7.4.4.1 Se debe redactar, para cada componente, una Especificación de Diseño de los Componentes Software bajo la responsabilidad del Diseñador, tomando como base la Especificación de Diseño del Software. Los requisitos que se describen desde el apartado 7.4.4.2 al 7.4.4.6 hacen referencia a la Especificación de Diseño de los Componentes Software. 7.4.4.2 La siguiente información debe estar disponible para cada componente software:

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 52 -

– el autor; – la historia de la configuración; y – una descripción breve. La historia de la configuración debe incluir una identificación precisa de la versión actual y de todas las versiones anteriores del componente, especificando la versión, fecha y autor, y una descripción de las modificaciones realizadas desde la versión anterior. 7.4.4.3 La Especificación de Diseño de los Componentes Software debe tratar los elementos siguientes: a) la identificación de las unidades de software más pequeñas (por ejemplo, subrutinas, métodos, procedimientos) trazadas en relación a las unidades de nivel superior; b) sus interfaces detalladas con el entorno y otros componentes con entradas y salidas detalladas; c) sus niveles de integridad de la seguridad sin otras asignaciones dentro del mismo componente; d) los algoritmos y las estructuras de datos detallados. Cada Especificación de Diseño de los Componentes Software debe ser coherente y permitir la transformación en código de los componentes correspondientes. 7.4.4.4 Cada Especificación de Diseño de los Componentes Software debe ser legible, comprensible y se debe poder someter a ensayos. 7.4.4.5 El tamaño y la complejidad de cada Componente Software desarrollado deben estar equilibrados. 7.4.4.6 La Especificación de Diseño de los Componentes Software debe seleccionar técnicas y medidas de entre las enumeradas en la tabla A.4. La combinación seleccionada debe justificarse como un conjunto que satisfaga los apartados 4.8 y 4.9. 7.4.4.7 Se debe redactar, para cada componente, una Especificación de Ensayos de los Componentes Software, bajo la responsabilidad del encargado de los ensayos, tomando como base la Especificación de Diseño de los Componentes Software. Los requisitos que se describen desde el apartado 7.4.4.8 al 7.4.4.10 hacen referencia a la Especificación de Ensayos de los Componentes Software. 7.4.4.8 La Especificación de Ensayos de los Componentes Software debe redactarse de acuerdo con los requisitos genéricos establecidos para una Especificación de Ensayos (véase 6.1.4.4). 7.4.4.9 Se debe elaborar una Especificación de Ensayos de los Componentes Software y se debe someter a cada componente a ensayo en relación a la Especificación. Estos ensayos deben demostrar que cada componente realiza su función prevista. La Especificación de Ensayos de los Componentes Software debe definir y justificar los criterios requeridos y el grado de cobertura de los ensayos dentro del alcance requerido por el nivel de integridad del software. Los ensayos deben diseñarse para cumplir tres objetivos: a) confirmar que el componente realiza sus funciones previstas (ensayos de caja negra); b) controlar cómo interactúan las partes internas del componente para realizar sus funciones previstas (ensayos de caja negra/blanca); c) confirmar que todas las partes del componente se someten a ensayos (ensayos de caja banca).

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 53 -

EN 50128:2011

7.4.4.10 La Especificación de Ensayos de los Componentes Software debe seleccionar técnicas y medidas de entre las enumeradas en la tabla A.5. La combinación seleccionada debe justificarse como un conjunto que satisfaga los apartados 4.8 y 4.9. 7.4.4.11 Se debe redactar un Informe de Verificación del Diseño de los Componentes Software, bajo la responsabilidad del Verificador, tomando como base la Especificación de Diseño del Software, la Especificación de Diseño de los Componentes Software y la Especificación de Ensayos de los Componentes Software. Los requisitos que se describen desde el apartado 7.4.4.12 al 7.4.4.13 hacen referencia al Informe de Verificación del Diseño de los Componentes Software. 7.4.4.12 El Informe de Verificación del Diseño de los Componentes Software debe redactarse de acuerdo con los requisitos genéricos establecidos para un Informe de Verificación (véase 6.2.4.13). 7.4.4.13 Una vez que se haya establecido cada Especificación de Diseño de los Componentes Software, la verificación debe recoger: a) la adecuación de la Especificación de Diseño de los Componentes Software para satisfacer la Especificación de Diseño del Software; b) que la Especificación de Diseño de los Componentes Software cumple con los requisitos generales de legibilidad y trazabilidad que se describen desde el apartado 5.3.2.7 hasta el apartado 5.3.2.10 y desde el apartado 6.5.4.14 hasta el apartado 6.5.4.17, así como los requisitos específicos descritos desde el apartado 7.4.4.1 al apartado 7.4.4.6; c) la adecuación de la Especificación de Ensayos de los Componentes Software como un conjunto de casos de ensayo para la Especificación de Diseño de los Componentes Software; d) que la Especificación de Ensayos de los Componentes Software cumple con los requisitos generales de legibilidad y trazabilidad que se describen desde el apartado 5.3.2.7 hasta el apartado 5.3.2.10, y desde el apartado 6.5.4.14 hasta el apartado 6.5.4.17, así como los requisitos específicos descritos desde el apartado 7.4.4.7 al apartado 7.4.4.10; e) el desglose de la Especificación de Diseño del Software en componentes software y la Especificación de Diseño de los Componentes Software haciendo referencia a: 1) la viabilidad de las prestaciones requeridas, 2) la capacidad para realizar ensayos para una verificación posterior, y 3) la mantenibilidad para permitir una modificación posterior. Los resultados deben quedar registrados en un Informe de Verificación del Diseño de los Componentes Software. 7.5 Implementación y ensayos de componentes 7.5.1 Objetivos 7.5.1.1 Obtener un software que se pueda analizar, someter a ensayos, verificar y mantener. En esta fase también se incluyen los ensayos de componentes. 7.5.2 Documentos de entrada 1) Especificación de Diseño de los Componentes Software. 2) Especificación de Ensayos de los Componentes Software.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 54 -

7.5.3 Documentos de salida 1) Código Fuente del Software y documentación de apoyo. 2) Informes de Ensayos de los Componentes Software. 3) Informe de Verificación del Código Fuente del Software. 7.5.4 Requisitos 7.5.4.1 El Código Fuente del Software debe escribirse bajo la responsabilidad del Implementador tomando como base la Especificación de Diseño de los Componentes Software. Los requisitos que se describen desde el apartado 7.5.4.2 al 7.5.4.4 hacen referencia al código fuente. 7.5.4.2 El tamaño y la complejidad del código fuente desarrollado deben estar equilibrados. 7.5.4.3 El Código Fuente del Software debe ser legible, comprensible y se debe poder someter a ensayos. 7.5.4.4 El Código Fuente del Software debe someterse al control de la configuración antes del inicio de los ensayos documentados. 7.5.4.5 Se debe redactar un Informe de Ensayos de los Componentes Software bajo la responsabilidad del Encargado de los Ensayos, tomando como base la Especificación de Ensayos de los Componentes Software y el Código Fuente del Software. Los requisitos que se describen desde el apartado 7.5.4.6 al 7.5.4.7 hacen referencia al Informe de Ensayos de los Componentes Software. 7.5.4.6 El Informe de Ensayos de los Componentes Software debe redactarse de acuerdo con los requisitos genéricos establecidos para un Informe de Ensayos (véase 6.1.4.5). 7.5.4.7 El Informe de Ensayos de los Componentes Software debe incluir las siguientes características: a) Una declaración de los resultados de los ensayos y de si cada componente ha cumplido los requisitos de su Especificación de Diseño de los Componentes Software. b) Se debe proporcionar una declaración de la cobertura de los ensayos de cada componente, demostrando que se ha alcanzado el nivel requerido de cobertura de los ensayos para todos los criterios requeridos. 7.5.4.8 Se debe redactar un Informe de Verificación del Código Fuente del Software, bajo la responsabilidad del verificador, tomando como base la Especificación de Diseño de los Componentes Software, la Especificación de Ensayos de los Componentes Software y el Código Fuente del Software. Los requisitos que se describen desde el apartado 7.5.4.9 al 7.5.4.10 hacen referencia al Informe de Verificación del Código Fuente del Software. 7.5.4.9 El Informe de Verificación del Código Fuente del Software debe redactarse de acuerdo con los requisitos genéricos establecidos para un Informe de Verificación (véase 6.2.4.13). 7.5.4.10 Después de que se hayan establecido el Código Fuente del Software y el Informe de Ensayos de los Componentes Software, la verificación debe recoger: a) la adecuación del Código Fuente del Software como una implementación de la Especificación de Diseño de los Componentes Software; b) el uso correcto de las técnicas y medidas seleccionadas de entre las descritas en la tabla A.4 como un conjunto que satisfaga los apartados 4.8 y 4.9;

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 55 -

EN 50128:2011

c) la determinación de la aplicación correcta de las normas de codificación; d) que el Código Fuente del Software cumple con los requisitos generales de legibilidad y trazabilidad que se describen desde el apartado 5.3.2.7 hasta el apartado 5.3.2.10, y desde el apartado 6.5.4.14 hasta el apartado 6.5.4.17, así como los requisitos específicos descritos desde el apartado 7.5.4.1 al apartado 7.5.4.4; e) la adecuación del Informe de Ensayos de los Componentes Software como registro de los ensayos realizados de acuerdo con la Especificación de Ensayos de los Componentes Software. Los resultados deben quedar registrados en un Informe de Verificación del Código Fuente del Software. 7.6 Integración 7.6.1 Objetivos 7.6.1.1 Realizar la integración del software y del software/hardware. 7.6.1.2 Demostrar que el software y el hardware interactúan correctamente para realizar sus funciones previstas. 7.6.2 Documentos de entrada 1) Especificación de Ensayos de Integración del Software/Hardware. 2) Especificación de Ensayos de Integración del Software. 7.6.3 Documentos de salida 1) Informe de Ensayos de Integración del Software. 2) Informe de Ensayos de Integración del Software/Hardware. 3) Informe de Verificación de la Integración del Software. 7.6.4 Requisitos 7.6.4.1 La integración de los componentes software debe ser el proceso en el que se combinen de forma progresiva componentes individuales que se hayan sometido a ensayos previamente para formar una entidad, para que se puedan probar de forma adecuada las interfaces de los componentes y el software ensamblado antes de la integración y ensayo del sistema. 7.6.4.2 Durante la integración del software/hardware, cualquier modificación o cambio en el sistema integrado debe someterse a un estudio de impacto que debe identificar todos los componentes afectados y las actividades imprescindibles para una nueva verificación. 7.6.4.3 Se debe redactar un Informe de Ensayos de Integración del Software, bajo la responsabilidad del integrador, tomando como base la Especificación de Ensayos de Integración del Software. Los requisitos que se describen desde el apartado 7.6.4.4 al 7.6.4.6 hacen referencia al Informe de Ensayos de Integración del Software. 7.6.4.4 El Informe de Ensayos de Integración del Software debe redactarse de acuerdo con los requisitos genéricos establecidos para un Informe de Ensayos (véase 6.1.4.5). 7.6.4.5 El Informe de Ensayos de Integración del Software se debe realizar según se detalla a continuación:

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 56 -

a) el Informe de Ensayos de Integración del Software debe realizarse declarando los resultados del ensayo y debe precisar si se han cumplido los objetivos y criterios de la Especificación de Ensayos de Integración del Software. Si se produce un fallo, se deben registrar sus circunstancias en el Informe; b) se deben registrar los casos de ensayo y sus resultados, preferiblemente en un formato legible por una máquina para su análisis posterior; c) los ensayos se deben poder repetir, y, si es factible, se deben poder realizar con medios automáticos; d) el Informe de Ensayos de Integración del Software debe documentar la identidad y configuración de los elementos involucrados. 7.6.4.6 El Informe de Ensayos de Integración del Software debe demostrar el uso correcto de las técnicas y medidas elegidas de entre las descritas en la tabla A.6 como un conjunto que satisfaga los apartados 4.8 y 4.9. 7.6.4.7 Se debe redactar un Informe de Ensayos de Integración del Software/Hardware, bajo la responsabilidad del integrador, tomando como base la Especificación de Ensayos de Integración del Software/Hardware. Los requisitos que se describen desde el apartado 7.6.4.8 al 7.6.4.10 hacen referencia al Informe de Ensayos de Integración del Software/Hardware. 7.6.4.8 El Informe de Ensayos de Integración del Software/Hardware debe redactarse de acuerdo con los requisitos genéricos establecidos para un Informe de Ensayos (véase 6.1.4.5). 7.6.4.9 El Informe de Ensayos de Integración del Software/Hardware se debe realizar según se detalla a continuación: a) el Informe de Ensayos de Integración del Software/Hardware debe declarar los resultados del ensayo y debe precisar si se han cumplido los objetivos y criterios de la Especificación de Ensayos de Integración del Software/Hardware. Si se produce un fallo, se deben registrar sus circunstancias en el Informe; b) se deben registrar los casos de ensayo y sus resultados, preferiblemente en un formato legible por una máquina para su análisis posterior; c) el Informe de Ensayos de Integración del Software/Hardware debe documentar la identidad y configuración de los elementos involucrados. 7.6.4.10 El Informe de Ensayos de Integración del Software/Hardware debe demostrar el uso correcto de las técnicas y medidas elegidas de entre las descritas en la tabla A.6 como un conjunto que satisfaga los apartados 4.8 y 4.9. 7.6.4.11 Debe redactarse un Informe de Verificación de la Integración del Software bajo la responsabilidad del verificador, tomando como base la Especificación de Ensayos de Integración del Software y del Software/Hardware y los Informes de Ensayos correspondientes. Los requisitos que se describen desde el apartado 7.6.4.12 al 7.6.4.13 hacen referencia al Informe de Verificación de la Integración del Software. 7.6.4.12 El Informe de Verificación de la Integración del Software debe redactarse de acuerdo con los requisitos genéricos establecidos para un Informe de Verificación (véase 6.2.4.13). 7.6.4.13 Después de que se hayan establecido el Informe de Ensayos de Integración del Software y el Informe de Ensayos de Integración del Software/Hardware, la verificación debe recoger: a) la adecuación del Informe de Ensayos de Integración del Software como registro de los ensayos realizados de acuerdo con la Especificación de Ensayos de Integración del Software;

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 57 -

EN 50128:2011

b) si el Informe de Ensayos de Integración del Software cumple con los requisitos de legibilidad y trazabilidad que se describen desde el apartado 5.3.2.7 hasta el apartado 5.3.2.10, y desde el apartado 6.5.4.14 hasta el apartado 6.5.4.17, así como los requisitos específicos descritos desde el apartado 7.6.4.3 al apartado 7.6.4.6; c) la adecuación del Informe de Ensayos de Integración del Software/Hardware como registro de los ensayos realizados de acuerdo con la Especificación de Ensayos de Integración del Software/Hardware; d) si el Informe de Ensayos de Integración del Software/Hardware cumple con los requisitos generales de legibilidad y trazabilidad que se describen desde el apartado 5.3.2.7 hasta el apartado 5.3.2.10, y desde el apartado 6.5.4.14 hasta el apartado 6.5.4.17, así como los requisitos específicos descritos desde el apartado 7.6.4.7 al apartado 7.6.4.10. 7.7 Ensayos del Software en Conjunto / Validación Final 7.7.1 Objetivos 7.7.1.1 Analizar y someter a ensayos el conjunto integrado de software y hardware para garantizar que cumple con la Especificación de Requisitos del Software haciendo especial énfasis en aspectos funcionales y de seguridad de acuerdo con el nivel de integridad de seguridad del software y para comprobar si es válido para su aplicación prevista. 7.7.2 Documentos de entrada 1) Especificación de Requisitos del Software. 2) Especificación de Ensayos del Software en Conjunto. 3) Plan de Verificación del Software. 4) Plan de Validación del Software. 5) Toda la documentación del Hardware y Software, incluidos los resultados intermedios de la verificación. 6) Especificación de Requisitos de Seguridad del Sistema. 7.7.3 Documentos de salida 1) Informe de Ensayos del Software en Conjunto. 2) Informe de Validación del Software. 3) Nota de la Versión Publicada. 7.7.4 Requisitos 7.7.4.1 Se debe redactar un Informe de Ensayos del Software en Conjunto bajo la responsabilidad del Encargado de los Ensayos, tomando como base la Especificación de Ensayos del Software en Conjunto. Los requisitos que se describen desde el apartado 7.7.4.2 al 7.7.4.4 hacen referencia al Informe de Ensayos del Software en Conjunto. 7.7.4.2 El Informe de Ensayos del Software en Conjunto debe redactarse de acuerdo con los requisitos genéricos establecidos para un Informe de Ensayos (véase 6.1.4.5). 7.7.4.3 El validador debe especificar y realizar ensayos complementarios a su discreción o solicitar que los realice el Encargado de los Ensayos. Mientras los Ensayos de Software en Conjunto se basan principalmente en la estructura de la Especificación de Requisitos del Software, el valor añadido que debe aportar el Validador son los ensayos que someten al sistema a escenarios complejos que reflejan las necesidades reales del Usuario.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 58 -

7.7.4.4 Los resultados de todos los ensayos y análisis deben quedar registrados en el Informe de Ensayos del Software en Conjunto. 7.7.4.5 El software se debe someter a ensayo bien sea conectándolo a elementos reales del hardware o bien a sistemas reales con los que se conectaría en condiciones de funcionamiento normales, o bien simulando señales de entrada y cargas controladas por las salidas. Se debe someter a ensayo en las mismas condiciones que se dan durante el funcionamiento normal, en las condiciones presentes durante las situaciones previstas y en las condiciones no deseadas que requieren una acción del sistema. Cuando se utilicen entradas o cargas simuladas, se debe demostrar que éstas no difieren de forma significativa de las entradas y de las cargas que se encuentran durante el funcionamiento normal. NOTA Las entradas o cargas simuladas podrían sustituir a entradas o cargas presentes únicamente a nivel del sistema o en modos de error.

7.7.4.6 Debe redactarse un Informe de Validación del Software, bajo la responsabilidad del Validador, tomando el Plan de Validación del Software como base. Los requisitos que se describen desde el apartado 7.7.4.7 al 7.7.4.11 hacen referencia al Informe de Validación del Software. 7.7.4.7 El Informe de Validación del Software debe redactarse de acuerdo con los requisitos genéricos establecidos para el Informe de Validación (véase de 6.3.4.7 a 6.3.4.11). 7.7.4.8 Una vez terminada la integración y se hayan realizado los análisis y los ensayos de software en conjunto, se debe elaborar un Informe de Validación del Software como se indica a continuación: a) el informe debe indicar si se han cumplido los objetivos y criterios del Plan de Validación del Software. Se deben registrar y justificar las desviaciones respecto al plan; b) debe contener una declaración resumida sobre los resultados de los ensayos y sobre si el software en su totalidad instalado en su máquina objetivo satisface los requisitos establecidos en la Especificación de Requisitos del Software; c) debe proporcionar una evaluación de la cobertura de los ensayos en lo que se refiere a los requisitos de la Especificación de Requisitos del Software; d) debe realizar una evaluación de otras actividades de verificación de acuerdo con el Plan y el Informe de Verificación del Software acompañada de una verificación de que la trazabilidad de los requisitos se realiza y está cubierta de forma completa; e) si el Validador produce sus propios casos de ensayo sin remitírselos al Encargado de los ensayos, el Informe de Validación del Software debe documentar dichos casos como se describe desde el apartado 6.3.4.7 al apartado 6.3.4.11. 7.7.4.9 El Informe de Validación del Software debe contar con la confirmación de que cada combinación de técnicas o medidas seleccionadas de acuerdo con el anexo A es apropiada para el nivel definido de integridad de seguridad del software. El informe debe contar con una evaluación de la efectividad global de la combinación de las técnicas y medidas adoptadas, teniendo en cuenta el tamaño y la complejidad del software producido y teniendo en cuenta los resultados reales de los ensayos y de las actividades de verificación y validación. 7.7.4.10

El Informe de Validación del Software debe recoger los siguientes puntos:

a) la documentación de la identidad y de la configuración del software; b) la declaración que identifique de manera apropiada el software y los equipos de soporte técnicos; c) la declaración que identifique de manera apropiada los modelos de simulación utilizados; d) la declaración sobre la adecuación de la Especificación de Ensayos del Software en Conjunto;

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 59 -

EN 50128:2011

e) la recogida y seguimiento de cualquier desviación encontrada; f) la revisión y evaluación de todas las desviaciones en términos de riesgo (impacto); g) una declaración de que el proyecto ha gestionado apropiadamente las acciones correctivas de acuerdo con el proceso y procedimientos de gestión de las modificaciones y con una identificación clara de las discrepancias encontradas; h) la declaración de cada restricción provocada por las desviaciones de forma trazable; i) una conclusión relativa a si el software es válido para su aplicación prevista, teniendo en cuenta las condiciones y restricciones de aplicación. 7.7.4.11 Las discrepancias que se encuentren, incluidos los errores detectados y los casos de no conformidad con esta norma europea o con cualquier requisito o plan relativo al software, así como las restricciones y las limitaciones, deben quedar claramente identificadas en un apartado separado del Informe de Validación del Software, deben ser evaluadas en cuanto al nivel de integridad de la seguridad y deben incluirse en la Nota de la Versión Publicada que acompaña al software entregado. 7.7.4.12 La Nota de la Versión Publicada que acompañe al software entregado debe incluir todas las restricciones relativas al uso del software. Dichas restricciones se derivan de: a) los errores detectados; b) los casos de no conformidad con esta norma europea; c) el nivel de cumplimiento de los requisitos; d) el nivel de cumplimiento de cualquier plan. 8 DESARROLLO DE LOS DATOS O ALGORITMOS DE APLICACIÓN: SISTEMAS CONFIGURADOS MEDIANTE DATOS O ALGORITMOS DE APLICACIÓN 8.1 Objetivos 8.1.1 Un rasgo característico en muchas redes de ferrocarriles es la necesidad de diseñar cada instalación para que satisfaga los requisitos individuales de una aplicación específica. Un sistema configurado mediante datos de aplicación y/o algoritmos de aplicación permite adaptar un software genérico homologado a los requisitos individuales de cada aplicación específica. El objetivo del desarrollo de los datos de aplicación es la obtención correcta de datos a partir de una instalación determinada y el control del comportamiento previsto, seguidos de una evaluación del proceso de desarrollo usado para los datos de esa aplicación. Los requisitos para el desarrollo de los algoritmos de aplicación son los mismos que para el desarrollo de software genérico como se describe desde el capítulo 1 al 7 y en el capítulo 9. Un ejemplo típico es el de un sistema cuyo software genérico está preconfigurado para una aplicación ferroviaria genérica mediante una serie de algoritmos de aplicación, y que se configura a continuación para cada instalación específica mediante instancias e interconexiones de los algoritmos de aplicación y mediante una serie de datos de configuración. Por ejemplo, los principios de señalización de un sistema de enclavamiento (por ejemplo, la gestión de una señal, la gestión de la aguja) pueden implementarse mediante una serie de algoritmos de aplicación. Los datos de aplicación se presentan generalmente en forma de valores de parámetros o de descripciones (identidad, tipo, ubicación, etc.) de objetos externos. Los algoritmos de aplicación pueden adoptar por ejemplo la forma de diagramas de bloques funcionales, diagramas de estados o diagramas ladder o en escalera que determinan la respuesta deseada del sistema de acuerdo con sus entradas, de su estado actual y de sus valores de parámetros específicos. Los algoritmos de aplicación incluyen las conexiones y las operaciones lógicas a ejecutar.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 60 -

Los datos/algoritmos de aplicación se producen normalmente utilizando herramientas dedicadas. Se pueden expresar en forma de tablas o de diagramas, que se pueden interpretar o compilar en códigos ejecutables normalmente tras la conversión en códigos fuente gestionados por medio de lenguajes especializados (con sintaxis y semántica). La posibilidad de adaptar los sistemas a través de su capacidad de configuración proporciona al diseñador diferentes niveles de control sobre la funcionalidad detallada del software. 8.1.2 Los procedimientos y las herramientas usadas para su desarrollo deben ser apropiados para el nivel de integridad de seguridad del sistema como determina la función para la que se desarrollan. 8.1.3 Los siguientes apartados describen los requisitos para el desarrollo inicial de un sistema configurable y para el desarrollo posterior de cada serie de datos/algoritmos específicos para la aplicación. 8.2 Documentos de entrada 1) Especificación de Requisitos del Software para el software genérico. 2) Especificación de la Arquitectura del Software para el software genérico. 3) Condiciones de aplicación del software genérico y de las herramientas de aplicación. 4) Manuales de usuario del software genérico y de las herramientas de aplicación. 8.3 Documentos de salida 1) Plan de Preparación de la Aplicación. 2) Especificación de los Requisitos de la Aplicación. 3) Arquitectura y Diseño de la Aplicación. 4) Especificación de Ensayos de la Aplicación. 5) Informe de Ensayos de la Aplicación. 6) Informe de Verificación de Preparación de la Aplicación. 7) Código Fuente de los Datos/Algoritmos de Aplicación. 8) Informe de Verificación de los Datos/Algoritmos de Aplicación. 8.4 Requisitos 8.4.1 Proceso de Desarrollo de la Aplicación 8.4.1.1 Se debe redactar un Plan de Preparación de la Aplicación, bajo la responsabilidad del Gestor de Requisitos o del Diseñador, tomando los documentos de entrada descritos en el apartado 8.2 como base. Los requisitos que se describen desde el apartado 8.4.1.2 al 8.4.1.11 hacen referencia al Plan de Preparación de la Aplicación. 8.4.1.2 Se debe elaborar un Plan de Preparación de la Aplicación para definir y describir detalladamente el proceso de desarrollo de la aplicación, incluidas las actividades, los documentos a entregar y los roles de los encargados. Se puede elaborar o bien para cada aplicación específica o bien para cada clase de aplicaciones específicas, es decir, para una aplicación genérica.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 61 -

EN 50128:2011

8.4.1.3 El Plan de Preparación de la Aplicación debe definir una estructura de documentación para el proceso de preparación de la aplicación. 8.4.1.4 El Plan de Preparación de la Aplicación debe seleccionar técnicas y medidas de entre las enumeradas en la tabla A.11. La combinación seleccionada debe justificarse como un conjunto que satisfaga los apartados 4.8 y 4.9. 8.4.1.5 El Plan de Preparación de la Aplicación debe especificar los procedimientos y las herramientas de aplicación (clasificadas de acuerdo al apartado 6.7) para su uso en el proceso de desarrollo de la aplicación. 8.4.1.6 El Plan de Preparación de la Aplicación debe incluir las actividades de verificación y validación para garantizar que los datos/algoritmos de aplicación están completos, son correctos y compatibles entre ellos y con la aplicación genérica, y para proporcionar pruebas de que se cumplen las condiciones de aplicación de la aplicación genérica. Estas actividades de verificación y validación, así como las pruebas, pueden sustituirse por actividades de verificación y validación realizadas en las herramientas encargadas de producir los datos/algoritmos de aplicación. Los resultados se reúnen en el Informe de Verificación de Preparación de la Aplicación y en el Informe de Ensayos de la Aplicación. 8.4.1.7 El Plan de Preparación de la Aplicación debe incluir actividades de verificación y validación para garantizar que las herramientas de aplicación y el software genérico son compatibles entre ellos y con la aplicación específica, y para proporcionar pruebas de que se cumplen sus condiciones de aplicación. 8.4.1.8 Se debe realizar un análisis de riesgos que cubra el proceso de desarrollo de la aplicación, incluidos las herramientas y procedimientos de aplicación, con el fin de validar el Plan de Preparación de la Aplicación y para alcanzar el nivel requerido de integridad de seguridad del software. El Plan de Preparación de la Aplicación debe incluir el análisis de riesgos. 8.4.1.9 El Plan de Preparación de la Aplicación debe especificar los requisitos de independencia entre los miembros del personal encargados de realizar las tareas de verificación, de validación y de preparación de acuerdo con el apartado 5.1. NOTA Los diseñadores de la aplicación son los encargados de realizar las actividades de preparación de datos.

8.4.1.10 El Plan de Preparación de la Aplicación debe definir una clase de herramientas para cualquier herramienta de hardware o software que se utilice en el ciclo de vida de preparación de la aplicación. 8.4.1.11 Cuando sea posible, el Plan de Preparación de la Aplicación debe utilizar notaciones que sean familiares a los ingenieros de aplicaciones para especificar los requisitos y el diseño. Cuando se introduzcan nuevas notaciones, se debe proporcionar la documentación necesaria para el usuario, así como programas de formación si se considera oportuno. 8.4.1.12 Se debe redactar un Informe de Verificación de los Datos/Algoritmos de Aplicación, bajo la responsabilidad del Verificador, tomando los documentos de entrada del apartado 8.2 como base. El requisito del apartado 8.4.1.13 hace referencia al Informe de Verificación de los Datos/Algoritmos de Aplicación. 8.4.1.13

Una vez que se haya establecido el Plan de Preparación de la Aplicación, la verificación debe recoger:

a) que el Plan de Preparación de la Aplicación cumple con los requisitos generales de legibilidad y trazabilidad que se describen desde el apartado 5.3.2.7 hasta el apartado 5.3.2.10 y desde el apartado 6.5.4.14 hasta el apartado 6.5.4.17, así como los requisitos específicos descritos desde el apartado 8.4.1.2 al apartado 8.4.1.11; b) la coherencia interna del Plan de Preparación de la Aplicación. Los resultados se deben registrar en un Informe de Verificación de los Datos/Algoritmos de Aplicación. 8.4.1.14 La implementación del Plan de Preparación de la Aplicación se debe verificar y validar para cada aplicación específica.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 62 -

8.4.2 Especificación de los Requisitos de la Aplicación 8.4.2.1 Se debe redactar una Especificación de Requisitos de la Aplicación, bajo la responsabilidad del Gestor de Requisitos, tomando los documentos de entrada descritos en el apartado 8.2 como base. Los requisitos que se describen desde el apartado 8.4.2.2 al 8.4.2.3 hacen referencia a la Especificación de Requisitos de la Aplicación. 8.4.2.2 Los requisitos para la aplicación específica deben incluir los requisitos que son específicos para la instalación en estudio (por ejemplo, el trazado de la vía, la ubicación de las señales, los límites de velocidad para el sistema de señalización), así como un resumen o una referencia a las condiciones de aplicación del software genérico y de las herramientas de aplicación, y las normas con las que la aplicación debe cumplir (por ejemplo, los principios de señalización para un sistema de señalización). 8.4.2.3 En esta etapa se deben especificar los requisitos relativos a los datos y algoritmos de aplicación procesados por el software genérico del sistema. 8.4.2.4 Se debe redactar un Informe de Verificación de los Datos/Algoritmos de Aplicación, bajo la responsabilidad del Verificador, tomando los documentos de entrada del apartado 8.2 como base. El requisito del apartado 8.4.2.5 hace referencia al Informe de Verificación de los Datos/Algoritmos de Aplicación. 8.4.2.5 Una vez que se haya establecido la Especificación de Requisitos de la Aplicación, la verificación debe recoger: a) que la Especificación de Requisitos de la Aplicación cumple con los requisitos generales de legibilidad y trazabilidad que se describen desde el apartado 5.3.2.7 hasta el apartado 5.3.2.10 y desde el apartado 6.5.4.14 hasta el apartado 6.5.4.17, así como los requisitos específicos descritos desde el apartado 8.4.2.2 al apartado 8.4.2.3; b) la coherencia interna de la Especificación de Requisitos de la Aplicación. Los resultados se deben registrar en un Informe de Verificación de los Datos/Algoritmos de Aplicación. 8.4.3 Arquitectura y Diseño Se debe especificar la cantidad y tipo de componentes hardware y software genéricos que se van a utilizar en la aplicación específica. Debe definirse la ubicación de componentes y datos y algoritmos de aplicación en la arquitectura de la aplicación específica. En esta etapa se deben diseñar los datos y algoritmos de aplicación procesados por el software genérico. 8.4.4 Producción de los Datos/Algoritmos de Aplicación 8.4.4.1 El proceso de desarrollo de la aplicación debe incluir la producción y la compilación del código fuente de los datos/algoritmos genéricos y específicos, así como las actividades de verificación y de ensayo relativas a ésta producción. Se recomienda el uso de lenguajes diagramáticos para producir el código fuente de los algoritmos de aplicación. Véase la tabla A.16. 8.4.4.2 Se debe redactar un Informe de Ensayos de la Aplicación, bajo la responsabilidad del Encargado de los Ensayos, tomando los documentos de entrada del apartado 8.2 como base. El requisito del apartado 8.4.4.3 hace referencia al Informe de Ensayos de la Aplicación. 8.4.4.3 El Informe de Ensayos de la Aplicación debe documentar la ejecución correcta y completa de los ensayos definidos en la Especificación de Ensayos de la Aplicación. 8.4.4.4 El Informe de Verificación de Preparación de la Aplicación debe

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 63 -

EN 50128:2011

a) documentar cada actividad realizada para garantizar la corrección y compleción de los datos/algoritmos y su coherencia con los principios de la aplicación y la arquitectura de aplicación específica; b) evaluar la compatibilidad de los datos/algoritmos con la aplicación genérica. 8.4.4.5 Se debe redactar una Especificación de Ensayos de la Aplicación, bajo la responsabilidad del Encargado de los Ensayos, tomando los documentos de entrada del apartado 8.2 como base. El requisito del apartado 8.4.4.6 hace referencia a la Especificación de Ensayos de la Aplicación. 8.4.4.6 La Especificación de Ensayos de la Aplicación debe especificar los ensayos a realizar en la etapa intermedia o final de la preparación de datos/algoritmos con el fin de garantizar: a) la coherencia y compleción de los datos/algoritmos en relación a los principios de la aplicación; b) la coherencia y compleción de los datos/algoritmos en relación a la arquitectura específica de la aplicación. 8.4.4.7 Se debe redactar un Informe de Verificación de los Datos/Algoritmos de Aplicación, bajo la responsabilidad del Verificador, tomando los documentos de entrada del apartado 8.2 como base. El requisito del apartado 8.4.4.8 hace referencia al Informe de Verificación de los Datos/Algoritmos de Aplicación. 8.4.4.8 Una vez que se haya establecido la Especificación de Ensayos de la Aplicación, la verificación debe recoger: a) que la Especificación de Ensayos de la Aplicación cumple con los requisitos generales de legibilidad y trazabilidad que se describen desde el apartado 5.3.2.7 hasta el apartado 5.3.2.10 y desde el apartado 6.5.4.14 hasta el apartado 6.5.4.17, así como los requisitos específicos descritos en el apartado 8.4.4.6; b) la coherencia interna de la Especificación de Ensayos de la Aplicación. Los resultados se deben registrar en un Informe de Verificación de los Datos/Algoritmos de Aplicación. 8.4.5 Integración de la Aplicación y Aceptación de los Ensayos 8.4.5.1 En algunos sistemas, los datos/algoritmos de la aplicación pueden integrarse con el hardware y el software genéricos para un ensayo en fábrica antes de su instalación en el sistema objetivo. Esto no será necesario cuando se pueda obtener un grado de confianza suficiente por otros medios. La aplicación debe instalarse entonces en el sistema objetivo, y se deben realizar los ensayos de integración en la instalación completa. Finalmente el sistema objetivo debe ponerse en servicio como sistema plenamente operacional, y se debe realizar un proceso de aceptación final del sistema objetivo en la instalación completa. El Informe de Ensayos de la Aplicación debe documentar la ejecución correcta y completa de los ensayos definidos en la Especificación de Ensayos de la Aplicación. El Informe de Verificación de Preparación de la Aplicación debe comprobar la compleción y corrección de los ensayos realizados en la instalación completa. 8.4.5.2 Se debe redactar una Especificación de Ensayos de la Aplicación, bajo la responsabilidad del Encargado de los Ensayos, tomando los documentos de entrada del apartado 8.2 como base. El requisito del apartado 8.4.5.3 hace referencia a la Especificación de Ensayos de la Aplicación. 8.4.5.3 La Especificación de Ensayos de la Aplicación debe especificar los ensayos que se han de realizar para garantizar: a) la integración correcta de los datos/algoritmos en el hardware y software genérico, si fuera necesario; b) la correcta integración de los datos/algoritmos en la instalación completa.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 64 -

8.4.5.4 Se debe redactar un Informe de Verificación de los Datos/Algoritmos de Aplicación, bajo la responsabilidad del Verificador, tomando los documentos de entrada del apartado 8.2 como base. El requisito del apartado 8.4.5.5 hace referencia al Informe de Verificación de los Datos/Algoritmos de Aplicación. 8.4.5.5 Una vez que se haya establecido la Especificación de Ensayos de la Aplicación, la verificación debe recoger que la Especificación de Ensayos de la Aplicación cumple con los requisitos específicos descritos en el apartado 8.4.5.3. 8.4.6 Validación y Evaluación de la Aplicación Las actividades de validación y evaluación deben auditar las prestaciones de cada etapa del ciclo de vida. 8.4.7 Procedimientos y herramientas de preparación de la aplicación 8.4.7.1 Para cada tipo nuevo de sistema configurado mediante datos/algoritmos de aplicación, se deben desarrollar procedimientos y herramientas específicos que permitan que se aplique el proceso de desarrollo de la aplicación especificado en el apartado 8.4.1 a instalaciones del nuevo sistema. El desarrollo de estas herramientas debe realizarse de acuerdo con esta norma europea en paralelo con el software y hardware genéricos del sistema. Las actividades de verificación, validación y evaluación deben garantizar que las herramientas de preparación de datos y el software genérico son compatibles. 8.4.7.2 Se debe validar y evaluar todo proceso de compilación. Se debe tener en cuenta que son normalmente necesarios compiladores especializados para la conversión de datos y algoritmos. 8.4.7.3 Todos los datos/algoritmos de aplicación y la documentación asociada para cada aplicación específica deben estar sujetos a los requisitos de la implantación del software como se especifica en el apartado 9.1. 8.4.7.4 Todos los datos/algoritmos de aplicación y la documentación asociada deben estar sujetos a los requisitos de mantenimiento de software especificados en el apartado 9.2. 8.4.7.5 Todos los datos/algoritmos de aplicación y la documentación asociada deben ponerse bajo la gestión de la configuración de acuerdo con los requisitos especificados en los apartados 6.5 y 6.7. La gestión de la configuración de los datos/algoritmos de aplicación puede separarse de la parte del software genérico. 8.4.7.6 El Informe de Verificación de la Aplicación demuestra la cobertura y el cumplimiento de las condiciones de aplicación del software genérico y de las herramientas de aplicación. 8.4.8 Desarrollo de software genérico 8.4.8.1 El desarrollo de software genérico, que soporte la ejecución de los datos/algoritmos de aplicación, debe cumplir con los requisitos descritos desde el apartado 7.1 al 7.7 de esta norma europea. Se deben respetar igualmente los siguientes requisitos adicionales. 8.4.8.2 En los documentos de la Especificación de Requisitos del Software del software genérico se deben identificar los tipos o clases de funciones que pueden configurarse mediante datos/algoritmos de aplicación en cada sistema y subsistema. El nivel de integridad de la seguridad asignado a las funciones determinará las normas a aplicar en el desarrollo posterior de los datos/algoritmos de aplicación para todas las instalaciones del sistema. 8.4.8.3 Durante el diseño del software genérico se deben especificar las interfaces detalladas entre el software genérico y los datos/algoritmos de aplicación, a menos que ya se hubiera hecho en una etapa anterior del ciclo de vida, por ejemplo, como resultado del requisito de utilización de un lenguaje específico existente para la aplicación. 8.4.8.4 Se debe poner en práctica una separación rígida entre el software genérico y los datos/algoritmos de aplicación, es decir, se debe poder recompilar y actualizar o bien el software genérico o bien los datos/algoritmos de aplicación, sin necesidad de actualizar el otro, a menos que se haya producido una modificación en la interfaz definida entre el software genérico y los datos/algoritmos de aplicación. Del mismo modo, los datos/algoritmos específicos de aplicaciones deben separarse de los datos/algoritmos genéricos de aplicaciones.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 65 -

EN 50128:2011

8.4.8.5 Los procedimientos de control de las modificaciones deben garantizar que toda modificación que se realice en el software genérico solo puede instalarse después de que se haya establecido que o bien el software revisado es compatible con los datos/algoritmos de aplicación originales o que se han revisado los datos/algoritmos de aplicación. 8.4.8.6 Se debe prestar atención particular en el proceso de verificación y en la fase de ensayos de validación del software genérico con el fin de garantizar que se tienen en cuenta todas las combinaciones pertinentes de datos y algoritmos. Si no se han tenido en cuenta todas las combinaciones de datos y algoritmos en los procesos de verificación, ensayos y validación del software genérico, este hecho se debe identificar claramente como un límite en el uso del software genérico. Se debe realizar un complemento de los procesos de verificación, ensayos y validación del software genérico cuando se definan datos o algoritmos más allá de este límite. 8.4.8.7 El software genérico debe diseñarse para detectar datos/algoritmos de aplicación dañados, cuando sea factible. 8.4.8.8 Los diseñadores deben publicar la Nota de la Versión Publicada del software genérico y de las herramientas de aplicación como muy tarde durante la fase de Ensayos del Software en Conjunto/Fase de Validación Final del software genérico y de las herramientas de aplicación. El contenido de estos documentos debe estar sujeto a actividades de verificación y validación. En el documento "Condiciones de aplicación del software genérico y de las herramientas de aplicación" se debe recoger la siguiente información: 1) referencias a los manuales de usuario del software genérico y de otras herramientas de aplicación; 2) cualquier restricción en los datos/algoritmos de aplicación, por ejemplo, reglas de arquitectura o de codificación impuestas para cumplir con los niveles de integridad de la seguridad. 9 IMPLANTACIÓN Y MANTENIMIENTO DEL SOFTWARE 9.1 Implantación del software 9.1.1 Objetivo 9.1.1.1 Garantizar que el software funciona como se requiere, preservando el nivel requerido de integridad de seguridad del software y la fiabilidad cuando se implanta en el entorno final de aplicación. 9.1.2 Documentos de entrada Todo documento de diseño, desarrollo y análisis que sea pertinente para la implantación. 9.1.3 Documentos de salida 1) Versión del Software Publicado y Plan de Implantación. 2) Manual de Implantación del Software. 3) Notas de la Versión Publicada. 4) Registros de la Implantación. 5) Informe de Verificación de la Implantación. 9.1.4 Requisitos 9.1.4.1 La implantación debe realizarse bajo la responsabilidad del jefe de proyecto.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 66 -

9.1.4.2 Antes de realizar la entrega de una versión de software, se debe registrar la línea base del software y se debe mantener trazable bajo el control de la gestión de la configuración. Se debe incluir también el software preexistente y el software que se hubiera desarrollado de acuerdo con una versión anterior de esta norma europea. 9.1.4.3 La versión de software publicado se debe poder reproducir durante el ciclo de vida de la línea base. 9.1.4.4 Se debe redactar una Nota de la Versión Publicada, bajo la responsabilidad del Diseñador, tomando los documentos de entrada descritos en el apartado 9.1.2 como base. El requisito descrito en el apartado 9.1.4.5 hace referencia a la Nota de la Versión Publicada. 9.1.4.5 Se debe proporcionar una Nota de la Versión Publicada que defina: a) las condiciones de aplicación que se deben cumplir; b) la información de compatibilidad entre componentes software y entre software y hardware; c) las restricciones para la utilización del software (véase 7.7.4.12). 9.1.4.6 Se debe redactar un Manual de Implantación del Software tomando como base los documentos de entrada descritos en el apartado 9.1.2. El requisito descrito en el apartado 9.1.4.7 hace referencia al Manual de Implantación del Software. 9.1.4.7 El Manual de Implantación del Software debe definir procedimientos para identificar e instalar correctamente una versión de software publicado. 9.1.4.8 En caso de una implantación sucesiva (es decir, la implantación de componentes individuales), es altamente recomendable para los SIL 3 y SIL 4, y recomendable para los SIL 1 y SIL 2, que el software se diseñe de forma que incluya medios que garanticen la exclusión de la activación de versiones incompatibles de componentes software. 9.1.4.9 La gestión de la configuración debe garantizar que no se producirán daños por la coexistencia de diferentes versiones de los mismos componentes software en los casos en los que dicha coexistencia no se pueda evitar. 9.1.4.10 Cuando se instale una nueva versión de software, ésta debe contar con un procedimiento de reversión (es decir, contar con la capacidad de retornar a la versión anterior). 9.1.4.11 El software debe contar con mecanismos de autoidentificación integrados que permitan su identificación durante el proceso de carga y después de la carga en el objetivo. El mecanismo de autoidentificación debería indicar la información de la versión del software y de cualquier dato de configuración así como la identidad del producto. NOTA Se recomienda proteger mediante codificación los datos dentro del código que contienen la información sobre la versión de software publicado (véase la tabla A.3 "Códigos de Detección de Errores").

9.1.4.12 Se debe redactar un Registro de Implantación tomando como base los documentos de entrada descritos en el apartado 9.1.2. El requisito descrito en el apartado 9.1.4.13 hace referencia al Registro de Implantación del Software. 9.1.4.13 El Registro de Implantación debe demostrar que se ha cargado el software previsto a través del examen de los mecanismos de autoidentificación integrados (véase 9.1.4.11). Este registro debe almacenarse entre los documentos relativos al sistema entregado como las otras verificaciones y forma parte de la puesta en servicio y de la aceptación. 9.1.4.14

El software implantado debe poderse trazar hasta las instalaciones en las que se ha entregado.

NOTA Esto es de especial importancia cuando se descubren errores graves que es necesario corregir en más de una instalación.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 67 -

9.1.4.15

EN 50128:2011

El software debe proporcionar información de diagnóstico como parte del control de errores.

9.1.4.16 Se debe redactar un Informe de Verificación de la Implantación, bajo la responsabilidad del Verificador, tomando los documentos de entrada del apartado 9.1.2 como base. Los requisitos que se describen desde el apartado 9.1.4.17 al 9.1.4.19 hacen referencia al Informe de Verificación de la Implantación. 9.1.4.17

Una vez que se haya establecido el Manual de Implantación del Software, la verificación debe recoger:

a) que el Manual de Implantación del Software cumple con los requisitos generales de legibilidad y trazabilidad que se describen desde el apartado 5.3.2.7 hasta el apartado 5.3.2.10 y desde el apartado 6.5.4.14 hasta el apartado 6.5.4.17, así como los requisitos específicos descritos en el apartado 9.1.4.7; b) la coherencia interna del Manual de Implantación del Software. 9.1.4.18

Una vez que se haya establecido el Registro de Implantación, la verificación debe recoger:

a) que el Registro de Implantación cumple con los requisitos generales de legibilidad y trazabilidad que se describen desde el apartado 5.3.2.7 hasta el apartado 5.3.2.10 y desde el apartado 6.5.4.14 hasta el apartado 6.5.4.17, así como los requisitos específicos descritos en el apartado 9.1.4.13; b) la coherencia interna del Registro de Implantación. 9.1.4.19

Una vez que se haya establecido la Nota de la Versión Publicada, la verificación debe recoger:

a) que la Nota de la Versión Publicada cumple con los requisitos generales de legibilidad y trazabilidad que se describen desde el apartado 5.3.2.7 hasta el apartado 5.3.2.10 y desde el apartado 6.5.4.14 hasta el apartado 6.5.4.17, así como los requisitos específicos descritos en el apartado 9.1.4.5; b) la coherencia interna de la Nota de la Versión Publicada. Los resultados deben quedar registrados en un Informe de Verificación de la Implantación. 9.1.4.20 El paquete de software debe incluir medidas para evitar o detectar errores que se produzcan durante el almacenamiento, la transferencia, la transmisión o la duplicación del código ejecutable o de los datos. Se recomienda codificar el código ejecutable (véase la tabla A.3 "Códigos de Detección de Errores") como parte de la comprobación de la integridad del código en el proceso de carga. 9.2 Mantenimiento del Software 9.2.1 Objetivo 9.2.1.1 Garantizar que el software funciona como se requiere, preservando el nivel requerido de integridad de seguridad del software y la fiabilidad cuando se realizan correcciones, mejoras o adaptaciones del mismo software. Véase también el apartado 6.6 "Modificaciones y control de las modificaciones" de esta norma europea y la fase 13 de "Modificación y realimentación" en la Norma EN 50126-1. 9.2.2 Documentos de entrada Todo documento pertinente de diseño, desarrollo y análisis. 9.2.3 Documentos de salida 1. Plan de Mantenimiento del Software. 2. Registros de Modificaciones del Software.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 68 -

3. Registros de Mantenimiento del Software. 4. Informe de Verificación del Mantenimiento del Software. 9.2.4 Requisitos 9.2.4.1 Aunque esta norma europea no pretende tener carácter retroactivo, y se aplica principalmente a nuevos desarrollos y se aplica en su totalidad a software existente si se somete a modificaciones de gran envergadura, el apartado 9.2, relativo al mantenimiento de software, se aplica a todas las modificaciones, incluso a aquellas de poca envergadura. Sin embargo, es muy recomendable la aplicación de esta norma europea al completo durante las actualizaciones y el mantenimiento del software existente. 9.2.4.2 Para cualquier nivel de integridad de seguridad del software, el proveedor debe decidir, antes de comenzar cualquier modificación, si las acciones de mantenimiento son de poca o gran envergadura o si los métodos de mantenimiento existentes para el sistema son los adecuados. El proveedor debe justificar y registrar su decisión y debe remitirla al Evaluador para que éste la evalúe. 9.2.4.3 Las actividades de mantenimiento deben realizarse de acuerdo con las directrices que se describen en la Norma ISO/IEC 90003. 9.2.4.4 La mantenibilidad debe diseñarse como un aspecto inherente del software, siguiendo los requisitos de los apartados 7.3, 7.4 y 7.5 en particular. La serie de Normas ISO/IEC 9126 debe utilizarse también con el fin de implementar y verificar un nivel mínimo de mantenibilidad. 9.2.4.5 Se debe redactar un Plan de Mantenimiento del Software tomando como base los documentos de entrada descritos en el apartado 9.2.2. El requisito descrito en el apartado 9.2.4.6 hace referencia al Plan de Mantenimiento del Software. 9.2.4.6 Los procedimientos para el mantenimiento del software se deben establecer y registrar en el Plan de Mantenimiento del Software. Estos procedimientos deben tratar también: a) el control del informe de errores, el registro de errores, los registros de mantenimiento, las autorizaciones para realizar modificaciones y la configuración del software/sistema y las técnicas y medidas descritas en la tabla A.10; b) la verificación, validación y evaluación de toda modificación; c) la definición de la Autoridad que homologa la modificación del software; y d) la autorización para la modificación. 9.2.4.7 Se debe redactar un Informe de Mantenimiento del Software tomando como base los documentos de entrada descritos en el apartado 9.2.2. El requisito descrito en el apartado 9.2.4.8 hace referencia al Registro de Mantenimiento del Software. 9.2.4.8 Se debe establecer y actualizar de forma periódica un Registro de Mantenimiento del Software para cada Elemento de Software antes de que se publique la primera versión. Además de los requisitos de la Norma ISO/IEC 90003:2004 relativos a los "Registros e Informes de Mantenimiento" (véase la parte relativa a "Mantenimiento" de la Norma ISO/IEC 90003:2004), este registro debe incluir: a) las referencias a todos los Registros de Modificaciones del Software aplicables a dicho elemento de software; b) la evaluación del impacto de las modificaciones; c) los casos de ensayo de los componentes, incluidos los datos de los ensayos de revalidación y de regresión; y d) la historia de la configuración del software.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 69 -

EN 50128:2011

9.2.4.9 Se debe redactar un Registro de Modificaciones del Software tomando como base los documentos de entrada descritos en el apartado 9.2.2. El requisito descrito en el apartado 9.2.4.10 hace referencia al Registro de Modificaciones del Software. 9.2.4.10 Se debe establecer un Registro de Modificaciones del Software para cada actividad de mantenimiento. Este registro debe incluir: a) las solicitudes de modificación, la versión, la naturaleza de los errores, las modificaciones requeridas y las fuentes de las modificaciones; b) un análisis del impacto de las actividades de mantenimiento en el sistema global, incluyendo la interacción del hardware, del software, y la humana y las interacciones con el entorno y las interacciones posibles; c) la especificación detallada de la modificación realizada; y d) la revalidación, el ensayo de regresión y la reevaluación de la modificación dentro del alcance requerido por el nivel de integridad de seguridad del software. La responsabilidad de la revalidación puede variar de proyecto a proyecto, según el nivel de integridad de seguridad del software. Además, el impacto de la modificación en el proceso de revalidación puede limitarse a diferentes niveles del sistema (por ejemplo, solo a componentes que se hayan cambiado, a todos los componentes afectados que se hayan identificado, al sistema completo). Por tanto, el Plan de Validación del Software debe abordar ambos problemas, de acuerdo con el nivel de integridad de seguridad del software. El nivel de independencia de la revalidación debe ser el mismo que para la validación. 9.2.4.11 Se debe redactar un Informe de Verificación del Mantenimiento del Software, bajo la responsabilidad del Verificador, tomando los documentos de entrada del apartado 9.2.2 como base. Los requisitos que se describen desde el apartado 9.2.4.12 al 9.2.4.14 hacen referencia al Informe de Verificación del Mantenimiento del Software. 9.2.4.12

Una vez que se haya establecido el Plan de Mantenimiento del Software, la verificación debe recoger:

a) que el Plan de Mantenimiento del Software cumple con los requisitos generales de legibilidad y trazabilidad que se describen desde el apartado 5.3.2.7 hasta el apartado 5.3.2.10 y desde el apartado 6.5.4.14 hasta el apartado 6.5.4.17, así como los requisitos específicos descritos en el apartado 9.2.4.6; b) la coherencia interna del Plan de Mantenimiento del Software. 9.2.4.13

Una vez que se haya establecido el Registro de Mantenimiento del Software, la verificación debe recoger:

a) que el Registro de Mantenimiento del Software cumple con los requisitos generales de legibilidad y trazabilidad que se describen desde el apartado 5.3.2.7 hasta el apartado 5.3.2.10 y desde el apartado 6.5.4.14 hasta el apartado 6.5.4.17, así como los requisitos específicos descritos en el apartado 9.2.4.8; b) la coherencia interna del Registro de Mantenimiento del Software. 9.2.4.14 Una vez que se haya establecido el Registro de Modificaciones del Software, la verificación debe recoger: a) que el Registro de Modificaciones del Software cumple con los requisitos generales de legibilidad y trazabilidad que se describen desde el apartado 5.3.2.7 hasta el apartado 5.3.2.10 y desde el apartado 6.5.4.14 hasta el apartado 6.5.4.17, así como los requisitos específicos descritos en el apartado 9.2.4.10; b) la coherencia interna del Registro de Modificaciones del Software. 9.2.4.15

Las actividades de mantenimiento deben realizarse siguiendo el Plan de Mantenimiento del Software.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 70 -

9.2.4.16 Se deben seleccionar las técnicas y medidas de entre las enumeradas en la tabla A.10. La combinación seleccionada debe justificarse como un conjunto que satisfaga los apartados 4.8 y 4.9. 9.2.4.17 El mantenimiento debe realizarse con, al menos, el mismo nivel de conocimientos, herramientas, documentación, planificación y gestión que el utilizado para el desarrollo inicial del software. Esto se debe aplicar también a la gestión de la configuración, al control de las modificaciones, al control de los documentos y a la independencia de las partes implicadas. 9.2.4.18 El control de los proveedores externos, el informe de problemas y las acciones correctivas deben gestionarse con los mismos criterios especificados en los párrafos pertinentes de la Garantía de Calidad del Software (6.5), que aquellos aplicados a los desarrollos de software nuevo. 9.2.4.19 Se debe realizar un análisis de impacto en la seguridad por cada problema o por cada mejora de la que se informe. 9.2.4.20 Para el software en mantenimiento, se deben adoptar acciones de atenuación proporcionales al riesgo identificado para garantizar la integridad global del sistema mientras se investigan y corrigen los problemas de los que se ha informado.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 71 -

EN 50128:2011

ANEXO A (Normativo) CRITERIOS PARA LA SELECCIÓN DE TÉCNICAS Y MEDIDAS

Los capítulos de esta norma europea están asociados en este anexo a las tablas de capítulos (véase desde la tabla A.1 hasta la tabla A.11 en el capítulo A.1) para ilustrar los medios que garantizan la conformidad. Existen también tablas de nivel inferior, las tablas detalladas (véase desde la tabla A.12 hasta la tabla A.23 en el capítulo A.2), que desarrollan ciertas entradas de las tablas de capítulos. Por ejemplo, la entrada "Modelado" que aparece en la tabla A.2 se desarrolla en la tabla A.17. Existe también un anexo D informativo al que se hace referencia en las tablas de capítulos. Junto a cada técnica o medida que aparece en las tablas, hay un requisito para cada nivel de integridad de seguridad del software (SIL). 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. Del mismo modo, cada técnica tiene los mismos requisitos en los niveles de integridad de seguridad del software 3 y 4. Estos requisitos pueden ser: "M"

este símbolo significa que el uso de una técnica es obligatorio (Mandatory),

"HR"

este símbolo significa que la técnica o la medida es altamente recomendable (Highly Recommended) para ese nivel de integridad de la seguridad. Si no se utiliza esa técnica o medida se debe proporcionar una justificación detallada de por qué se han utilizado técnicas alternativas en el Plan de Garantía de Calidad del Software o en otro documento al que se haga referencia en el Plan de Garantía de Calidad del Software,

"R"

este símbolo significa que la técnica o la medida es recomendable (Recommended) para ese nivel de integridad de la seguridad. Éste es un nivel de recomendación inferior al "HR", y se pueden combinar dichas técnicas para formar parte de un paquete,

'-'

este símbolo significa que no existen recomendaciones ni a favor ni en contra relativas a la utilización de esa técnica o medida,

"NR"

este símbolo significa que la técnica o la medida NO es recomendable (Not Recommended) para ese nivel de integridad de la seguridad. La utilización de esta técnica o medida debe justificarse de forma detallada en el Plan de Garantía de Calidad del Software o en otro documento al que se haga referencia en el Plan de Garantía de Calidad del Software.

La combinación de técnicas o medidas se expondrá en el Plan de Garantía de Calidad del Software o en otro documento al que se haga referencia en el Plan de Garantía de Calidad del Software, seleccionando una o más técnicas o medidas a menos que las notas adjuntas a la tabla impongan otros requisitos. Dichas notas pueden incluir referencias a técnicas homologadas o a combinaciones homologadas de técnicas. Si se utilizan dichas técnicas o combinaciones de técnicas, incluidas todas las técnicas de carácter obligatorio, entonces el Evaluador debe aceptarlas como válidas y solo debe cerciorarse de que se apliquen correctamente. Si se utiliza un conjunto de técnicas diferente y puede justificarse, el Evaluador puede entonces considerarlas aceptables.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 72 -

A.1 Tablas de capítulos Tabla A.1 – Temas Relativos al Ciclo de Vida y Documentación (5.3) DOCUMENTACIÓN

SIL 0

SIL 1

SIL 2

SIL 3

SIL 4

Planificación 1.

Plan de Garantía de Calidad del Software

HR

HR

HR

HR

HR

2.

Informe de Verificación de la Garantía de Calidad del Software

HR

HR

HR

HR

HR

3.

Plan de Gestión de la Configuración del Software

HR

HR

HR

HR

HR

4.

Plan de Verificación del Software

HR

HR

HR

HR

HR

5.

Plan de Validación del Software

HR

HR

HR

HR

HR

Requisitos del software 6.

Especificación de Requisitos del Software

HR

HR

HR

HR

HR

7.

Especificación de Ensayos del Software en Conjunto

HR

HR

HR

HR

HR

8.

Informe de Verificación de los Requisitos del Software

HR

HR

HR

HR

HR

HR

HR

HR

HR

HR

10. Especificación de Diseño del Software

HR

HR

HR

HR

HR

11. Especificaciones de las Interfaces del Software

HR

HR

HR

HR

HR

12. Especificación de Ensayos de Integración del Software

HR

HR

HR

HR

HR

13. Especificación de Ensayos de Integración del Software/Hardware

HR

HR

HR

HR

HR

14. Informe de Verificación de Diseño y Arquitectura del Software

HR

HR

HR

HR

HR

15. Especificación de Diseño de los Componentes Software

R

HR

HR

HR

HR

16. Especificación de Ensayos de los Componentes Software

R

HR

HR

HR

HR

17. Informe de Verificación del Diseño de los Componentes Software

R

HR

HR

HR

HR

HR

HR

HR

HR

HR

R

HR

HR

HR

HR

HR

HR

HR

HR

HR

21. Informes de Ensayos de Integración del Software

HR

HR

HR

HR

HR

22. Informes de Ensayos de Integración del Software/Hardware

HR

HR

HR

HR

HR

23. Informe de Verificación de la Integración del Software

HR

HR

HR

HR

HR

24. Informe de Ensayos del Software en Conjunto

HR

HR

HR

HR

HR

25. Informe de Validación del Software

HR

HR

HR

HR

HR

R

HR

HR

HR

HR

HR

HR

HR

HR

HR

Arquitectura y diseño 9.

Especificación de la Arquitectura del Software

Diseño de Componentes

Implementación y Ensayos de Componentes 18. Código Fuente del Software y documentación de apoyo 19. Informes de Ensayos de los Componentes Software 20. Informe de Verificación del Código Fuente del Software Integración

Ensayos del Software en Conjunto / Validación Final

26. Informe de Validación de las Herramientas 27. Nota de la Versión Publicada

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 73 -

EN 50128:2011

DOCUMENTACIÓN

SIL 0

SIL 1

SIL 2

SIL 3

SIL 4

28. Especificación de Requisitos de la Aplicación

HR

HR

HR

HR

HR

29. Plan de Preparación de la Aplicación (véase la NOTA 2)

HR

HR

HR

HR

HR

30. Especificación de Ensayos de la Aplicación (véase la NOTA 2)

HR

HR

HR

HR

HR

31. Arquitectura y Diseño de la Aplicación (véase la NOTA 2)

HR

HR

HR

HR

HR

32. Informe de Verificación de Preparación de la Aplicación

HR

HR

HR

HR

HR

33. Informe de Ensayos de la Aplicación

HR

HR

HR

HR

HR

34. Código Fuente de los Datos/Algoritmos de Aplicación

HR

HR

HR

HR

HR

35. Informe de Verificación de los Datos/Algoritmos de Aplicación

HR

HR

HR

HR

HR

36. Plan de Implantación y Versión de Software Publicado

R

HR

HR

HR

HR

37. Manual de Implantación del Software

R

HR

HR

HR

HR

HR

HR

HR

HR

HR

39. Registros de la Implantación

R

HR

HR

HR

HR

40. Informe de Verificación de la Implantación

R

HR

HR

HR

HR

R

HR

HR

HR

HR

42. Registros de Modificaciones del Software

HR

HR

HR

HR

HR

43. Registros de Mantenimiento del Software

R

HR

HR

HR

HR

44. Informe de Verificación del Mantenimiento del Software

R

HR

HR

HR

HR

45. Plan de Evaluación del Software

R

HR

HR

HR

HR

46. Informe de Evaluación del Software

R

HR

HR

HR

HR

Sistemas configurados mediante datos/algoritmos de aplicación

Implantación del software

38. Notas de la Versión Publicada

Mantenimiento del software 41. Plan de Mantenimiento del Software

Evaluación del Software

NOTA 1 De acuerdo con los apartados 5.3.2.11 y 5.3.2.12, los documentos se pueden combinar de diferentes formas. NOTA 2 La consideración de los documentos 29, 30 y 31 como HR o R depende de la importancia definida en el proceso y de donde se realice la verificación. Por ejemplo, puede que solo sea necesario verificar los datos y someterlos a ensayos en el dominio del sistema, mientras que es necesario someter a ensayos y verificación a propiedades más funcionales. En este caso se ha marcado como HR pero puede ser R opcionalmente.

Tabla A.2 – Especificación de Requisitos del Software (7.2) TÉCNICA/MEDIDA

Ref

SIL 0

SIL 1

SIL 2

SIL 3

SIL 4

1. Métodos Formales (basados en un enfoque matemático)

D.28

–

R

R

HR

HR

2. Modelado

Tabla A.17

R

R

R

HR

HR

3. Metodología estructurada

D.52

R

R

R

HR

HR

4. Tablas de Decisión

D.13

R

R

R

HR

HR

Requisitos: 1) La Especificación de Requisitos del Software debe incluir una descripción del problema en lenguaje natural y todas las notaciones formales o semiformales necesarias. 2) La tabla refleja requisitos adicionales para definir la especificación de forma clara y precisa. Se deben seleccionar una o más de estas técnicas para satisfacer el nivel de integridad de seguridad del software utilizado.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 74 -

Tabla A.3 – Arquitectura del Software (7.3) TÉCNICA/MEDIDA

Ref

SIL 0

SIL 1

SIL 2

SIL 3

SIL 4

1.

Programación Defensiva

D.14

–

HR

HR

HR

HR

2.

Detección y Diagnóstico de Errores

D.26

–

R

R

HR

HR

3.

Códigos Correctores de Errores

D.19

–

–

–

–

–

4.

Códigos Detectores de Errores

D.19

–

R

R

HR

HR

5.

Programación con Aserciones

D.24

–

R

R

HR

HR

6.

Técnicas de Bolsa de Seguridad/Técnicas de Seguridad Controlada

D.47

–

R

R

R

R

7.

Programación con Múltiples Versiones

D.16

–

R

R

HR

HR

8.

Bloque de recuperación

D.44

–

R

R

R

R

9.

Recuperación Regresiva

D.5

–

NR

NR

NR

NR

10. Recuperación Anticipada

D.30

–

NR

NR

NR

NR

11. Mecanismos de Recuperación de Errores mediante Reintento

D.46

–

R

R

R

R

12. Memorización de Casos Ejecutados

D.36

–

R

R

HR

HR

13. Inteligencia Artificial – Corrección de Errores

D.1

–

NR

NR

NR

NR

14. Reconfiguración Dinámica del software

D.17

–

NR

NR

NR

NR

15. Análisis de los Efectos de los Errores de Software

D.25

–

R

R

HR

HR

16. Sistema Tolerante a Errores

D.31

–

R

R

HR

HR

17. Ocultación de la Información

D.33

–

–

–

–

–

18. Encapsulamiento de la Información

D.33

R

HR

HR

HR

HR

19. Interfaz Definida Completamente

D.38

HR

HR

HR

M

M

20. Métodos Formales

D.28

–

R

R

HR

HR

21. Modelado

Tabla A.17

R

R

R

HR

HR

22. Metodología estructurada

D.52

R

HR

HR

HR

HR

23. Modelado soportado por el diseño asistido por ordenador y por herramientas de especificación

Tabla A.17

R

R

R

HR

HR

Requisitos: 1) Las combinaciones de técnicas homologadas aplicables a los Niveles 3 y 4 de Integridad de Seguridad del Software son las siguientes: a) 1, 7, 19, 22 y una seleccionada de entre la 4, 5, 12 o 21; b) 1, 4, 19, 22 y una seleccionada de entre la 2, 5, 12, 15 o 21. 2) Las combinaciones de técnicas homologadas aplicables a los Niveles 1 y 2 de Integridad de Seguridad del Software son las siguientes: 1, 19, 22 y una seleccionada de entre la 2, 4, 5, 7, 12, 15 o 21. 3) Se pueden definir algunos de estos temas a nivel del sistema. 4) Se pueden utilizar códigos detectores de errores de acuerdo con los requisitos de la Norma EN 50159. NOTA La técnica/medida 19 es para Interfaces Externas.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 75 -

EN 50128:2011

Tabla A.4 – Diseño del Software e Implementación (7.4) TÉCNICA/MEDIDA

Ref

SIL 0

SIL 1

SIL 2

SIL 3

SIL 4

1.

Métodos Formales

D.28

–

R

R

HR

HR

2.

Modelado

Tabla A.17

R

HR

HR

HR

HR

3.

Metodología estructurada

D.52

R

HR

HR

HR

HR

4.

Enfoque Modular

D.38

HR

M

M

M

M

5.

Componentes

Tabla A.20

HR

HR

HR

HR

HR

6.

Normas de Diseño y Codificación

Tabla A.12

HR

HR

HR

M

M

7.

Programas Analizables

D.2

HR

HR

HR

HR

HR

8.

Lenguaje de Programación Fuertemente Tipado

D.49

R

HR

HR

HR

HR

9.

Programación Estructurada

D.53

R

HR

HR

HR

HR

10. Lenguaje de Programación

Tabla A.15

R

HR

HR

HR

HR

11. Subconjunto de Lenguaje

D.35

–

–

–

HR

HR

12. Programación Orientada a Objetos

Tabla A.22 D.57

R

R

R

R

R

13. Programación por procedimientos

D.60

R

HR

HR

HR

HR

14. Metaprogramación

D.59

R

R

R

R

R

Requisitos: 1) La combinación de técnicas homologada aplicable a los Niveles 3 y 4 de Integridad de Seguridad del Software es 4, 5, 6, 8 y una seleccionada de entre la 1 o 2. 2) La combinación de técnicas homologada aplicable a los Niveles 1 y 2 de Integridad de Seguridad del Software es 3, 4, 5, 6 y una seleccionada de entre la 8, 9 o 10. 3) La metaprogramación debe quedar limitada a la producción del código de la fuente del software antes de la compilación.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 76 -

Tabla A.5 – Verificación y Ensayos (6.2 y 7.3) TÉCNICA/MEDIDA

Ref

SIL 0

SIL 1

SIL 2

SIL 3

SIL 4

1.

Demostración Formal

D.29

–

R

R

HR

HR

2.

Análisis Estático

Tabla A.19

–

HR

HR

HR

HR

3.

Análisis y Ensayos Dinámicos

Tabla A.13

–

HR

HR

HR

HR

4.

Métricas

D.37

–

R

R

R

R

5.

Trazabilidad

D.58

R

HR

HR

M

M

6.

Análisis de los Efectos de los Errores de Software

D.25

–

R

R

HR

HR

7.

Cobertura del Ensayo para el Código

Tabla A.21

R

HR

HR

HR

HR

8.

Ensayos Funcionales/Ensayos de Caja Negra

Tabla A.14

HR

HR

HR

M

M

9.

Ensayos de las Prestaciones

Tabla A.18

–

HR

HR

HR

HR

D.34

HR

HR

HR

HR

HR

10. Ensayos de la Interfaz

Requisitos: 1) La combinación de técnicas homologadas aplicables a los Niveles 3 y 4 de Integridad de Seguridad del Software es 3, 5, 7, 8 y una seleccionada de entre la 1, 2 o 6. 2) Las combinaciones de técnicas homologadas aplicables a los Niveles 1 y 2 de Integridad de Seguridad del Software es la 5 junto con una seleccionada de entre la 2, 3 u 8. NOTA 1 Las técnicas/medidas 1, 2, 4, 5, 6 y 7 están dirigidas a actividades de verificación. NOTA 2 Las técnicas/medidas 3, 8, 9 y 10 están dirigidas a ensayos.

Tabla A.6 – Integración (7.6) TÉCNICA/MEDIDA

Ref

SIL 0

SIL 1

SIL 2

SIL 3

SIL 4

1.

Ensayos Funcionales/Ensayos de Caja Negra

Tabla A.14

HR

HR

HR

HR

HR

2.

Ensayos de las Prestaciones

Tabla A.18

–

R

R

HR

HR

Tabla A.7 – Ensayos de Software en Conjunto (6.2 y 7.7) TÉCNICA/MEDIDA

Ref

SIL 0

SIL 1

SIL 2

SIL 3

SIL 4

1.

Ensayos de las Prestaciones

Tabla A.18

–

HR

HR

M

M

2.

Ensayos Funcionales/Ensayos de Caja Negra

Tabla A.14

HR

HR

HR

M

M

3.

Modelado

Tabla A.17

–

R

R

R

R

Requisito: 1) La combinación de técnicas homologada aplicable a los Niveles 1 y 2 de Integridad de Seguridad del Software es 1 y 2.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 77 -

EN 50128:2011

Tabla A.8 – Técnicas de Análisis del Software (6.3) Ref

SIL 0

SIL 1

SIL 2

SIL 3

1.

Análisis Estático de Software

D.13 D.37 Tabla A.19

R

HR

HR

HR

SIL 4 HR

2.

Análisis Dinámico de Software

Tabla A.13 Tabla A.14

–

R

R

HR

HR

3.

Diagramas de Causa-Efecto

D.6

R

R

R

R

R

4.

Análisis por Árbol de Eventos

D.22

–

R

R

R

R

5.

Análisis de los Efectos de los Errores de Software

D.25

–

R

R

HR

HR

TÉCNICA/MEDIDA

Requisito: 1) Se deben seleccionar una o más de estas técnicas para satisfacer el Nivel de Integridad de Seguridad del Software utilizado.

Tabla A.9 – Garantía de Calidad del Software (6.5) TÉCNICA/MEDIDA

Ref

SIL 0

SIL 1

SIL 2

SIL 3

SIL 4

1.

Acreditada según la Norma EN ISO 9001

7.1

R

HR

HR

HR

HR

2.

Conforme con la Norma EN ISO 9001

7.1

M

M

M

M

M

3.

Conforme con la Norma ISO/IEC 90003

7.1

R

R

R

R

R

4.

Sistema de Calidad de la Compañía

7.1

M

M

M

M

M

5.

Gestión de la Configuración del Software

D.48

M

M

M

M

M

6.

Listas de Comprobación

D.7

R

HR

HR

HR

HR

7.

Trazabilidad

D.58

R

HR

HR

M

M

8.

Registro y Análisis de Datos

D.12

HR

HR

HR

M

M

Requisito: 1) Esta tabla se debe aplicar a diferentes roles y a todas las fases.

Tabla A.10 – Mantenimiento del Software (9.2) TÉCNICA/MEDIDA

Ref

SIL 0

SIL 1

SIL 2

SIL 3

SIL 4

1.

Análisis de Impacto

D.32

R

HR

HR

M

M

2.

Registro y Análisis de Datos

D.12

HR

HR

HR

M

M

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 78 -

Tabla A.11 – Técnicas de Preparación de Datos (8.4) TÉCNICA/MEDIDA

Ref

SIL 0

SIL 1

SIL 2

SIL 3

SIL 4

1.

Métodos de Especificación en Tablas

D.68

R

R

R

R

R

2.

Lenguaje Específico para la Aplicación

D.69

R

R

R

R

R

3.

Simulación

D.42

R

HR

HR

HR

HR

4.

Ensayos Funcionales

D.42

M

M

M

M

M

5.

Listas de Comprobación

D.7

R

HR

HR

M

M

6.

Inspección de Fagan

D.23

–

R

R

R

R

7.

Revisiones formales del diseño

D.56

R

HR

HR

HR

HR

8.

Demostración formal de corrección (de los datos)

D.29

–

–

–

HR

HR

9.

Revisión del proyecto estructurado

D.56

R

R

R

HR

HR

Requisitos: 1) La combinación de técnicas homologada aplicable a los Niveles 1 y 2 de Integridad de Seguridad del Software es 1 y 4. 2) Las combinaciones de técnicas homologadas aplicables a los Niveles 3 y 4 de Integridad de Seguridad del Software son 1, 4, 5 y 7 o 2, 3 y 6. NOTA La descripción de la referencia D.29 hace referencia a programas mientras la técnica 8, en este contexto, se aplica a la demostración formal de que los datos son correctos.

A.2 Tablas detalladas Tabla A.12 – Normas de Codificación TÉCNICA/MEDIDA

Ref

SIL 0

SIL 1

SIL 2

SIL 3

SIL 4

1.

Norma de Codificación

D.15

HR

HR

HR

M

M

2.

Guía de Estilo de la Codificación

D.15

HR

HR

HR

HR

HR

3.

Ausencia de Objetos Dinámicos

D.15

–

R

R

HR

HR

4.

Ausencia de Variables Dinámicas

D.15

–

R

R

HR

HR

5.

Uso Limitado de Punteros

D.15

–

R

R

R

R

6.

Uso Limitado de la Recursión

D.15

–

R

R

HR

HR

7.

Ausencia de Saltos Incondicionales

D.15

–

HR

HR

HR

HR

8.

Tamaño y complejidad limitadas de las Funciones, Subrutinas y Métodos

D.38

HR

HR

HR

HR

HR

9.

Estrategia de Punto de Entrada/Salida para las Funciones, Subrutinas y Métodos

D.38

R

HR

HR

HR

HR

9.

Número limitado de parámetros de subrutina

D.38

R

R

R

R

R

D.38

HR

HR

HR

M

M

10. Uso limitado de Variables Globales

Requisito: 1) Se acepta que las técnicas 3, 4 y 5 puedan estar presentes como parte integrante de un compilador o de un traductor validado.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 79 -

EN 50128:2011

Tabla A.13 – Análisis y Ensayos Dinámicos TÉCNICA/MEDIDA

Ref

SIL 0

SIL 1

SIL 2

SIL 3

SIL 4

1.

Ejecución de Casos de Ensayo a partir del Análisis de Valores Límite

D.4

–

HR

HR

HR

HR

2.

Ejecución de Casos de Ensayo a partir de la Suposición de Errores

D.20

R

R

R

R

R

3.

Ejecución de Casos de Ensayo a partir de la Inserción de Errores

D.21

–

R

R

R

R

4.

Modelado de las Prestaciones

D.39

–

R

R

HR

HR

5.

Ensayos de Clases de Equivalencia y de Particiones de Entradas

D.18

R

R

R

HR

HR

6.

Ensayos Basados en la Estructura

D.50

–

R

R

HR

HR

Requisito: 1) El análisis de los casos de ensayo se realiza a nivel del subsistema y se basa en la especificación y/o en la especificación y el código.

Tabla A.14– Ensayos Funcionales/Ensayos de Caja Negra TÉCNICA/MEDIDA

Ref

SIL 0

SIL 1

SIL 2

SIL 3

SIL 4

1.

Ejecución de Casos de Ensayo a partir de Diagramas de Causa Efecto

D.6

–

–

–

R

R

2.

Prototipado/Animación

D.43

–

–

–

R

R

3.

Análisis de los Valores Límite

D.4

R

HR

HR

HR

HR

4.

Ensayos de Clases de Equivalencia y de Particiones de Entradas

D.18

R

HR

HR

HR

HR

5.

Simulación de Procesos

D.42

R

R

R

R

R

Requisito: 1) La compleción de la simulación dependerá del alcance del nivel de integridad de seguridad del software, de la complejidad y de la aplicación.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 80 -

Tabla A.15 – Lenguajes de programación textual TÉCNICA/MEDIDA

Ref

SIL 0

SIL 1

SIL 2

SIL 3

SIL 4

1.

ADA

D.54

R

HR

HR

HR

HR

2.

MODULA-2

D.54

R

HR

HR

HR

HR

3.

PASCAL

D.54

R

HR

HR

HR

HR

4.

C o C++

D.54 D.35

R

R

R

R

R

5.

PL/M

D.54

R

R

R

NR

NR

6.

BASIC

D.54

R

NR

NR

NR

NR

7.

Ensamblador

D.54

R

R

R

R

R

8.

C#

D.54 D.35

R

R

R

R

R

9.

JAVA

D.54 D.35

R

R

R

R

R

D.54

R

R

R

R

R

10. Lista de Instrucciones

Requisitos: 1) La selección de los lenguajes debe realizarse en función a los requisitos descritos en los apartados 6.7 y 7.3. 2) No existen requisitos que justifiquen decisiones para excluir lenguajes de programación específicos. NOTA 1 Véase el apartado D.54 "Lenguajes de Programación Adecuados" para obtener más información sobre cómo evaluar la idoneidad de un lenguaje de programación. NOTA 2 El hecho de que un lenguaje específico no aparezca en la tabla, no quiere decir que quede excluido de forma automática. Sin embargo, debería cumplir con el apartado D.54. NOTA 3 El uso de sistemas en tiempo de ejecución asociados a los lenguajes seleccionados, que son necesarios para ejecutar programas de aplicación, debería justificarse según el Nivel de Integridad de Seguridad del Software.

Tabla A.16 – Lenguajes Diagramáticos para Algoritmos de Aplicación TÉCNICA/MEDIDA

Ref

SIL 0

SIL 1

SIL 2

SIL 3

SIL 4

1.

Diagramas de Bloques Funcionales

D.63

R

R

R

R

R

2.

Diagramas de Función Secuencial

D.61

–

HR

HR

HR

HR

3.

Diagrama Ladder o en Escalera

D.62

R

R

R

R

R

4.

Diagramas de Estado

D.64

R

HR

HR

HR

HR

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 81 -

EN 50128:2011

Tabla A.17 – Modelado TÉCNICA/MEDIDA

Ref

SIL 0

SIL 1

SIL 2

SIL 3

SIL 4

1.

Modelado de datos

D.65

R

R

R

HR

HR

2.

Diagramas de Flujo de Datos

D.11

–

R

R

HR

HR

3.

Diagramas de Flujo de Control

D.66

R

R

R

HR

HR

4.

Máquinas de Estados Finitos o Diagramas de Transición de Estados

D.27

–

HR

HR

HR

HR

5.

Redes de Petri Temporizadas

D.55

–

R

R

HR

HR

6.

Tablas de Decisión/Tablas de Verdad

D.13

R

R

R

HR

HR

7.

Métodos Formales

D.28

–

R

R

HR

HR

8.

Modelado de las Prestaciones

D.39

–

R

R

HR

HR

9.

Prototipado/Animación

D.43

–

R

R

R

R

10. Diagramas de Estructura

D.51

–

R

R

HR

HR

11. Diagramas de Secuencia

D.67

R

HR

HR

HR

HR

Requisitos: 1) Se deben definir y utilizar directrices de modelado. 2) Se debe seleccionar al menos una de las técnicas HR.

Tabla A.18 – Ensayos de las Prestaciones TÉCNICA/MEDIDA

Ref

SIL 0

SIL 1

SIL 2

SIL 3

SIL 4

1.

Ensayos de Avalancha/Ensayos de Sobrecarga

D.3

–

R

R

HR

HR

2.

Tiempo de Respuesta y Limitaciones de Memoria

D.45

–

HR

HR

HR

HR

3.

Requisitos de las prestaciones

D.40

–

HR

HR

HR

HR

Tabla A.19 – Análisis Estático TÉCNICA/MEDIDA

Ref

SIL 0

SIL 1

SIL 2

SIL 3

SIL 4

1.

Análisis de los Valores Límites

D.4

–

R

R

HR

HR

2.

Listas de Comprobación

D.7

–

R

R

R

R

3.

Análisis de Flujos de Control

D.8

–

HR

HR

HR

HR

4.

Análisis de Flujos de Datos

D.10

–

HR

HR

HR

HR

5.

Suposición de Errores

D.20

–

R

R

R

R

6.

Revisión del Proyecto Estructurado/Revisión del Diseño

D.56

HR

HR

HR

HR

HR

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 82 -

Tabla A.20 – Componentes TÉCNICA/MEDIDA

Ref

SIL 0

SIL 1

SIL 2

SIL 3

SIL 4

1.

Ocultación de la Información

D.33

–

–

–

–

–

2.

Encapsulamiento de la Información

D.33

R

HR

HR

HR

HR

3.

Límite del Número de Parámetros

D.38

R

R

R

R

R

4.

Interfaz Definida Completamente

D.38

R

HR

HR

M

M

Requisito: 1) La ocultación y el encapsulamiento de la información son altamente recomendables únicamente si no existe una estrategia general para el acceso a los datos. NOTA La técnica/medida 4 es para Interfaces Internas.

Tabla A.21 – Cobertura de los Ensayos para los Códigos Criterio de Cobertura de los Ensayos

Ref

SIL 0

SIL 1

SIL 2

SIL 3

SIL 4

1.

Instrucción

D.50

R

HR

HR

HR

HR

2.

Rama

D.50

–

R

R

HR

HR

3.

Condición Compuesta

D.50

–

R

R

HR

HR

4.

Flujos de Datos

D.50

–

R

R

HR

HR

5.

Ruta

D.50

–

R

R

HR

HR

Requisitos: 1) Para cada SIL, se debe desarrollar una medida cuantificada de cobertura para los ensayos realizados. Esto puede servir para apoyar la opinión sobre la confianza adquirida en los ensayos y la necesidad de técnicas adicionales. 2) Para los SIL 3 o 4, la cobertura de los ensayos a nivel componente debería medirse según las técnicas: – 2 y 3; o – 2 y 4; o – 5 o se debería medir la cobertura de ensayo a nivel de integración de acuerdo con una o más de las técnicas 2, 3, 4 o 5. 3) Se pueden usar otros criterios de cobertura de ensayo, siempre que puedan justificare. Dichos criterios dependerán de la arquitectura del software (véase la tabla A.3) y del lenguaje de programación (véanse la tabla A.15 y la tabla A.16). 4) Se debe demostrar la corrección de los códigos que no se puedan someter a ensayo utilizando una técnica adecuada, por ejemplo, el análisis estadístico descrito en la tabla A.19. NOTA 1 La cobertura de las instrucciones se consigue automáticamente mediante los elementos 2 a 5. NOTA 2 Los criterios de cobertura de ensayos de esta tabla se utilizan para los ensayos basados en la estructura (basados en códigos, caja blanca). En la tabla A.14 se determinan las técnicas/medidas para los ensayos funcionales (basados en la especificación, caja negra). NOTA 3 Normalmente es difícil conseguir un porcentaje alto de cobertura. La utilización de la ejecución de casos de ensayo a partir de valores límite (D.4) y los ensayos de clases de equivalencia y de particiones de entradas (D.18) pueden permitir obtener una cobertura suficiente con un pequeño número de ensayos. NOTA 4 La diferencia entre 2 y 3 depende en la práctica del nivel del lenguaje de programación y del uso de las condiciones compuestas. Cuando solo se utilizan condiciones simples, por ejemplo, como resultado de una compilación, se considera que 2 y 3 son idénticos.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 83 -

EN 50128:2011

Tabla A.22 – Arquitectura del Software Orientada a Objetos TÉCNICA/MEDIDA

Ref

SIL 0

SIL 1

SIL 2

SIL 3

SIL 4

1.

Trazabilidad del concepto de dominio de aplicación a las clases de la arquitectura

–

R

R

R

HR

HR

2.

Utilización de marcos apropiados, combinaciones de clases y patrones de diseño utilizados de forma habitual

–

R

R

R

HR

HR

3.

Diseño Detallado Orientado a Objetos

Tabla A.23

R

R

R

HR

HR

Requisito: 1) Cuando se utilicen marcos y patrones de diseño existentes, se aplican los requisitos del software preexistente a estos marcos y patrones. NOTA 1 El enfoque orientado a objetos presenta información de manera muy diferente a como se realiza en los enfoques procedimentales; la siguiente lista contiene recomendaciones que requieren consideraciones específicas: – la comprensión de las jerarquías de clases y la identificación de las funciones del software que se ejecutarán tras la invocación de un método determinado (incluyendo cuando se utilizan bibliotecas de clases existentes); – ensayos basados en la estructura (tabla A.13). La trazabilidad desde el dominio de aplicación a la arquitectura de clases es menos importante. NOTA 2 Para una parte del software previsto, podría existir un marco proveniente de software preexistente que haya resuelto con éxito una tarea similar y que el personal de desarrollo conozca bien. Se recomienda entonces la utilización de dicho marco.

Tabla A.23 – Diseño Detallado Orientado a Objetos TÉCNICA/MEDIDA

Ref

SIL 0

SIL 1

SIL 2

SIL 3

SIL 4

1.

Las clases deberían tener un único objetivo

–

R

R

R

HR

HR

2.

La herencia solo debería utilizarse si la clase derivada es un refinamiento de su clase base

–

R

HR

HR

HR

HR

3.

Profundidad de la herencia limitada por normas de codificación

–

R

R

R

HR

HR

4.

Sobrecarga de las operaciones (métodos) bajo control estricto

–

R

R

R

HR

HR

5.

Herencia múltiple utilizada únicamente para las clases de interfaz

–

R

HR

HR

HR

HR

6.

Herencia a partir de clases desconocidas

–

–

–

–

NR

NR

Requisitos: 1) Una clase se caracteriza por tener una responsabilidad, es decir, por tratar a los datos estrechamente conectados y las operaciones sobre dichos datos. 2) Es necesario evitar dependencias circulares entre objetos.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 84 -

ANEXO B (Normativo) ROLES PRINCIPALES Y RESPONSABILIDADES RELATIVAS AL SOFTWARE

Tabla B.1: Gestor de Requisitos Tabla B.2: Diseñador Tabla B.3: Implementador Tabla B.4: Encargado de los ensayos Tabla B.5: Verificador Tabla B.6: Integrador Tabla B.7: Validador Tabla B.8: Evaluador Tabla B.9: Jefe de Proyecto Tabla B.10: Gestor de Configuración Tabla B.1 – Especificación del Rol del Gestor de Requisitos Rol: Gestor de Requisitos Responsabilidades: 1. debe responsabilizarse de la especificación de requisitos del software 2. debe poseer la Especificación de Requisitos del Software 3. debe establecer y mantener la trazabilidad hasta y desde los requisitos a nivel del sistema 4. debe garantizar que los requisitos relativos a las especificaciones y al software están bajo el control de la gestión de las modificaciones y de la configuración, incluyendo el estado, la versión y el estado de la autorización 5. debe garantizar la coherencia y la compleción de la Especificación de Requisitos del Software (con referencia a los requisitos del usuario y al entorno final de la aplicación) 6. debe desarrollar y mantener los documentos de requisitos relativos al software Competencias principales: 1. debe ser competente en ingeniería de requisitos 2. debe tener experiencia en dominios de aplicación 3. debe tener experiencia en atributos de seguridad dentro del dominio de la aplicación 4. debe entender el rol global del sistema y el entorno de aplicación 5. debe entender las técnicas analíticas y sus resultados 6. debe entender la regulación aplicable 7. debe entender los requisitos de la Norma EN 50128

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 85 -

EN 50128:2011

Tabla B.2 – Especificación del Rol del Diseñador Rol: Diseñador Responsabilidades: 1. debe transformar los requisitos especificados relativos al software en soluciones aceptables 2. debe poseer las soluciones de arquitectura y de diseño descendente 3. debe definir o seleccionar métodos de diseño y herramientas de soporte 4. debe aplicar principios y normas de diseño apropiados 5. debe desarrollar especificaciones de componentes cuando proceda 6. debe mantener la trazabilidad hasta y desde los requisitos especificados relativos al software 7. debe desarrollar y mantener la documentación de diseño 8. debe garantizar que los documentos de diseño están bajo el control de la gestión de las modificaciones y de la configuración Competencias principales: 1. debe ser competente en ingeniería apropiada al dominio de aplicación 2. debe ser competente en principios de diseño de la seguridad 3. debe ser competente en análisis de diseño y en metodologías de ensayo del diseño 4. debe poder trabajar dentro de los límites de las restricciones de diseño en un entorno determinado 5. debe ser competente para entender el dominio del problema 6. debe entender todas las restricciones impuestas por el hardware, el sistema operativo y los sistemas de interfaces 7. debe entender las partes pertinentes de la Norma EN 50128

Tabla B.3 – Especificación del Rol del Implementador Rol: Implementador Responsabilidades: 1. debe transformar las soluciones de diseño en datos, códigos fuente y/o en otras representaciones de diseño 2. debe transformar el código fuente en código ejecutable/otra representación de diseño 3. debe aplicar principios de diseño de la seguridad 4. debe aplicar las normas especificadas de preparación de datos/codificación 5. debe realizar análisis para verificar los resultados intermedios 6. debe integrar el software en la máquina objetivo 7. debe desarrollar y mantener los documentos de implementación que comprenden los métodos, tipos de datos y listados aplicados 8. debe mantener la trazabilidad hasta y desde el diseño 9. debe mantener los datos/códigos generados o modificados bajo el control de la gestión de las modificaciones y de la configuración Competencias principales: 1. debe ser competente en ingeniería apropiada al dominio de aplicación 2. debe ser competente en el lenguaje de implementación y en las herramientas de soporte 3. debe poder aplicar las normas de codificación y los estilos de programación especificados 4. debe entender todas las restricciones impuestas por el hardware, el sistema operativo y los sistemas de interfaces 5. debe entender las partes pertinentes de la Norma EN 50128

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 86 -

Tabla B.4 – Especificación del Rol del Encargado de los Ensayos Rol: Encargado de los ensayos Responsabilidades: 1. debe garantizar la planificación de las actividades de ensayo 2. debe desarrollar la especificación de ensayos (objetivos y casos) 3. debe garantizar la trazabilidad de los objetivos de ensayo en relación a los requisitos especificados relativos al software así como la trazabilidad de los casos de ensayo en relación a los objetivos de ensayo especificados 4. debe garantizar que se implementan los ensayos planificados y que se realizan los ensayos especificados 5. debe identificar las desviaciones de los resultados previstos y registrarlos en los informes de ensayos 6. debe comunicar las desviaciones al organismo competente de la gestión de las modificaciones para su evaluación y toma de decisiones 7. debe registrar los resultados en los informes 8. debe seleccionar los equipos para el ensayo del software Competencias principales: 1. debe ser competente en el dominio en el que se realicen los ensayos, por ejemplo, requisitos relativos al software, datos, código, etc. 2. debe ser competente en varios enfoques/metodologías de ensayo y verificación y poder identificar el método más apropiado en un contexto determinado 3. debe poder deducir casos de ensayo a partir de especificaciones dadas 4. debe tener capacidad de pensamiento analítico y buenas capacidades de observación 5. debe entender las partes pertinentes de la Norma EN 50128

Tabla B.5 – Especificación del Rol del Verificador Rol: Verificador Responsabilidades: 1. debe desarrollar un Plan de Verificación del Software (que puede incluir cuestiones relativas a la calidad) exponiendo qué necesita verificarse y qué tipos de procesos (por ejemplo, revisiones, análisis, etc.) y ensayos se requieren como prueba 2. debe comprobar la adecuación (compleción, coherencia, corrección, relevancia y trazabilidad) de las pruebas documentadas a partir de las revisiones, de la integración y de los ensayos con los objetivos de verificación especificados 3. debe identificar las anomalías, evaluarlas en términos del riesgo (impacto) que suponen, y registrarlas y comunicarlas al organismo competente de la gestión de las modificaciones para su evaluación y toma de decisiones 4. debe gestionar el proceso de verificación (revisión, integración y ensayos) y garantizar la independencia de las actividades según sea necesario 5. debe desarrollar y mantener registros de las actividades de verificación 6. debe desarrollar un Informe de Verificación exponiendo el resultado de las actividades de verificación Competencias principales: 1. debe ser competente en el dominio en el que se realice la verificación, por ejemplo, requisitos relativos al software, datos, código, etc. 2. debe ser competente en varios enfoques/metodologías de verificación y poder identificar el método o la combinación de métodos más apropiados en un contexto determinado 3. debe poder deducir los tipos de verificación a partir de especificaciones determinadas 4. debe tener capacidad de pensamiento analítico y buenas capacidades de observación 5. debe entender las partes pertinentes de la Norma EN 50128

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 87 -

EN 50128:2011

Tabla B.6 – Especificación del Rol del Integrador Rol: Integrador Responsabilidades: 1. debe gestionar el proceso de integración utilizando las líneas bases del software 2. debe desarrollar la Especificación de Ensayos de Integración del Software y del Software/Hardware para los componentes software tomando como base las especificaciones y la arquitectura de los componentes del Diseñador exponiendo cuáles son los componentes de entrada necesarios, la secuencia de las actividades de integración y los componentes integrados resultantes 3. debe desarrollar y mantener registros de las actividades de integración 4. debe identificar las anomalías de integración, registrarlas y comunicarlas al organismo competente de la gestión de las modificaciones para su evaluación y toma de decisiones 5. debe desarrollar un informe de integración de los componentes y del sistema global que exponga los resultados de la integración Competencias principales: 1. debe ser competente en el dominio en el que se realice la integración de los componentes, por ejemplo, los lenguajes de programación relevantes, las interfaces del software, los sistemas operativos, los datos, las plataformas, los códigos, etc. 2. debe ser competente en varios enfoques/metodologías de integración y poder identificar el método o la combinación de métodos más apropiados en un contexto determinado 3. debe ser competente para entender el diseño y la funcionalidad requeridos en varios niveles intermedios 4. debe poder deducir los tipos de ensayos de integración a partir de un conjunto de funciones integradas 5. debe tener capacidad de pensamiento analítico y buenas capacidades de observación que le permitan la comprensión del sistema en su globalidad 6. debe entender las partes pertinentes de la Norma EN 50128

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 88 -

Tabla B.7 – Especificación del Rol del Validador Rol: Validador Responsabilidades: 1. debe desarrollar una comprensión del sistema de software dentro del entorno previsto de aplicación 2. debe desarrollar un plan de validación y especificar las tareas y actividades esenciales para la validación del software y ponerse de acuerdo sobre este plan con el evaluador 3. debe revisar los requisitos del software en relación a su uso/entorno previsto 4. debe revisar el software en relación a los requisitos del software de forma que se garantice que se cumplen todos ellos 5. debe evaluar la conformidad del proceso del software y del software desarrollado en relación a los requisitos de esta norma europea incluyendo el SIL asignado 6. debe revisar la corrección, coherencia y adecuación de la verificación y de los ensayos 7. debe comprobar la corrección, coherencia y adecuación de los casos de ensayo y de los ensayos realizados 8. debe garantizar que se realizan todas las actividades del plan de validación 9. debe revisar y clasificar todas las desviaciones en términos de riesgo (impacto), registrarlas y comunicarlas al organismo competente de la gestión de las modificaciones para su evaluación y toma de decisiones 10. debe proporcionar una recomendación sobre la idoneidad del software para su uso previsto e indicar cualquier restricción de la aplicación según sea apropiado 11. debe registrar las desviaciones a partir del plan de validación 12. debe realizar auditorías, inspecciones o revisiones del proyecto global (como instancias del proceso de desarrollo genérico) según sea apropiado en varias fases del desarrollo 13. debe revisar y analizar los informes de validación relativos a aplicaciones previas según sea apropiado 14. debe revisar si las soluciones desarrolladas son trazables hasta los requisitos del software 15. debe garantizar que se revisan los registros de situaciones peligrosas asociadas y los casos de no conformidad y que se resuelven todas las situaciones peligrosas de manera adecuada bien sea mediante medidas que las eliminen o con medidas de control/transferencia de los riesgos 16. debe desarrollar un informe de validación 17. debe expresar su acuerdo/desacuerdo sobre la versión del software publicada Competencias principales: 1. debe ser competente en el dominio en el que se realice la validación 2. debe tener experiencia en atributos de seguridad dentro del dominio de la aplicación 3. debe ser competente en varios enfoques/metodologías de validación y poder identificar el método o la combinación de métodos más apropiados en un contexto determinado 4. debe poder deducir los tipos de pruebas de validación requeridas a partir de las especificaciones determinadas teniendo en cuenta la aplicación prevista 5. debe poder combinar diferentes fuentes y tipos de pruebas y sintetizar una vista global sobre la validez o sobre las restricciones y limitaciones de la aplicación 6. debe tener capacidad de pensamiento analítico y buenas capacidades de observación 7. debe tener una comprensión y una perspectiva del software global incluyendo la comprensión del entorno de aplicación 8. debe entender los requisitos de la Norma EN 50128

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 89 -

EN 50128:2011

Tabla B.8 – Especificación del Rol del Evaluador Rol: Evaluador Responsabilidades: 1. debe desarrollar una comprensión del sistema de software dentro del entorno previsto de aplicación 2. debe desarrollar un plan de evaluación y comunicárselo a la autoridad de seguridad y a la organización del cliente (organismo contratante del evaluador) 3. debe evaluar la conformidad del proceso del software y del software desarrollado en relación a los requisitos de esta norma europea incluyendo el SIL asignado 4. debe evaluar la competencia del personal del equipo de proyecto y de la organización para el desarrollo del software 5. debe evaluar las actividades de verificación y validación y las pruebas justificativas 6. debe evaluar los sistemas de gestión de la calidad adoptados para el desarrollo del software 7. debe evaluar el sistema de gestión de las modificaciones y de la configuración y las pruebas de su uso y aplicación 8. debe identificar y evaluar en términos de riesgo (impacto) toda desviación de los requisitos del software en el informe de evaluación 9. debe garantizar que se implementa el plan de evaluación 10. debe realizar auditorías de seguridad e inspecciones del proceso de desarrollo global según sea apropiado durante varias fases del desarrollo 11. debe dar una opinión profesional sobre la validez del software desarrollado para su uso previsto detallando las restricciones, condiciones de aplicación y observaciones para el control de riesgos, según sea apropiado 12. debe desarrollar un informe de evaluación y mantener registros sobre el proceso de evaluación Competencias principales: 1. debe ser competente en el dominio/tecnologías en el/las que se realice la evaluación 2. debe estar habilitado o poseer una licencia de una autoridad de seguridad reconocida 3. debe esforzarse para adquirir de forma continua/tener niveles suficientes de experiencia en materia de principios de seguridad y en la aplicación de los principios dentro del dominio de aplicación 4. debe ser competente para comprobar que se haya aplicado un método o una combinación de métodos apropiado/s en un contexto determinado 5. debe ser competente para comprender los procesos pertinentes de gestión de la seguridad, de recursos humanos y de gestión de la calidad para cumplir los requisitos de la Norma EN 50128 6. debe ser competente en enfoques/metodologías de evaluación 7. debe tener capacidad de pensamiento analítico y buenas capacidades de observación 8. debe poder combinar diferentes fuentes y tipos de pruebas y sintetizar una visión global sobre la validez o sobre las restricciones y limitaciones de la aplicación 9. debe tener una comprensión y una perspectiva del software global incluyendo la comprensión del entorno de aplicación 10. debe ser capaz de juzgar la adecuación de cualquier proceso de desarrollo (como la gestión de la calidad, la gestión de la configuración, los procesos de validación y verificación) 11. debe entender los requisitos de la Norma EN 50128

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 90 -

Tabla B.9 – Especificación del Rol del Jefe de Proyecto Rol: Jefe de Proyecto Responsabilidades: 1. debe garantizar que se cumple el sistema de gestión de la calidad y la independencia de los roles de acuerdo con el apartado 5.1 y que se comprueba la evolución en relación a los planes previstos 2. debe dedicar una cantidad suficiente de recursos en el proyecto a realizar tareas esenciales, incluyendo las actividades de seguridad, teniendo en cuenta el espíritu de independencia necesario de los roles 3. debe garantizar que se ha nombrado a un validador apropiado para el proyecto como se define en la Norma EN 50128 4. debe ser el responsable de la entrega e implantación del software y garantizar que también se cumplen y se entregan los requisitos de seguridad de las partes interesadas 5. debe proporcionar suficiente tiempo para la implementación y el cumplimiento correcto de las tareas de seguridad 6. debe aprobar los productos de seguridad completos y parciales a entregar por el proceso de desarrollo 7. debe garantizar que se mantienen los registros y una trazabilidad suficientes durante la toma de decisiones relacionadas con la seguridad Competencias principales: 1. debe entender los requisitos de la Norma EN 50128 relativos a la calidad, a las competencias, a la organización y a la gestión 2. debe entender los requisitos del proceso de seguridad 3. debe poder ponderar diferentes opciones y entender el impacto en las características de la seguridad de una decisión o de las opciones seleccionadas 4. debe entender los requisitos del proceso de desarrollo del software 5. debe entender los requisitos de otras normas pertinentes

Tabla B.10 – Especificación del Rol del Gestor de Configuración Rol: Gestor de Configuración Responsabilidades: 1. debe ser responsable del plan de gestión de la configuración del software 2. debe poseer el sistema de gestión de la configuración 3. debe establecer que todos los componentes software se identifican claramente y se versionan de forma independiente dentro del sistema de gestión de la configuración 4. debe preparar Notas de las Versiones Publicadas que mencionen las versiones incompatibles de los componentes software Competencias principales: 1. debe ser competente en la gestión de la configuración del software 2. debe entender los requisitos de la Norma EN 50128

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 91 -

EN 50128:2011

ANEXO C (Informativo) RESUMEN DEL CONTROL DE LOS DOCUMENTOS

La tabla C.1 proporciona un resumen del documento. Tabla C.1 – Resumen del Control de los Documentos FASE

DOCUMENTACIÓN

Planificación

Requisitos del software

Arquitectura y diseño

Diseño de componentes

Implementación y ensayos de componentes

Escrito por a

1a 2a comprobación comprobación VER

VAL

1.

Plan de Garantía de Calidad del Software

2.

Informe de Verificación de Garantía de Calidad del Software

VER

3.

Plan de Gestión de la Configuración del Software

véase el capítulo B.10

4.

Plan de Verificación del Software

VER

5.

Plan de Validación del Software

VAL

VER

6.

Especificación de Requisitos del Software

REQ

VER

VAL

7.

Especificación de Ensayos del Software en Conjunto

TST

VER

VAL

8.

Informe de Verificación de los Requisitos del Software

VER

9.

Especificación de la Arquitectura del Software

DES

VER

VAL

10. Especificación de Diseño del Software

DES

VER

VAL

11. Especificaciones de la Interfaz del Software

DES

VER

VAL

12. Especificación de Ensayos de Integración del Software

INT

VER

VAL

13. Especificación de Ensayos de Integración del Software/Hardware

INT

VER

VAL

14. Informe de Verificación de Diseño y Arquitectura del Software

VER

15. Especificación de Diseño de los Componentes Software

DES

VER

VAL

16. Especificación de Ensayos de los Componentes Software

TST

VER

VAL

17. Informe de Verificación del Diseño de los Componentes Software

VER

18. Código Fuente del Software y Documentación de Apoyo

IMP

VER

VAL

19. Informe de Verificación del Código Fuente del Software

VER

20. Informes de Ensayos de los Componentes Software

TST

VAL VER

VAL VAL

VAL

VAL

VAL VER

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

VAL

EN 50128:2011

FASE

DOCUMENTACIÓN

Integración

Ensayos del Software en Conjunto / Validación Final

Sistemas configurados mediante datos/algoritmos de aplicación

Implantación del software

Mantenimiento del software

Evaluación del Software a

- 92 -

Escrito por

2a 1a comprobación comprobación

21. Informes de Ensayos de Integración del Software

INT

VER

VAL

22. Informes de Ensayos de Integración del Software/Hardware

INT

VER

VAL

23. Informe de Verificación de la Integración del Software

VER

24. Informe de Ensayos del Software en Conjunto

TST

VER

VAL

25. Informe de Validación del Software

VAL

VER

26. Informe de Validación de las Herramientas

a

VER

27. Nota de la Versión Publicada

a

VER

VAL

REQ

VER

VAL

29. Plan de Preparación de la Aplicación

REQ o DES

VER

VAL

30. Especificación de los Ensayos de la Aplicación

TST

VER

VAL

31. Arquitectura y Diseño de la Aplicación

DES

VER

VAL

32. Informe de Verificación de Preparación de la Aplicación

VER

33. Informe de los Ensayos de la Aplicación

TST

VER

VAL

34. Código Fuente de los Datos/Algoritmos de Aplicación

DES

VER

VAL

35. Informe de Verificación de los Datos/Algoritmos de Aplicación

VER

28. Especificación de Requisitos de la Aplicación

VAL

36. Versión del Software Publicado y Plan de Implantación

a

VER

VAL

37. Manual de Implantación del Software

a

VER

VAL

38. Notas de las Versiones Publicadas

a

VER

VAL

39. Registros de la Implantación

a

VER

VAL

40. Informe de Verificación de la Implantación

VER

41. Plan de Mantenimiento del Software

a

VER

VAL

42. Registro de Modificaciones del Software

a

VER

VAL

43. Registros de Mantenimiento del Software

a

VER

VAL

44. Informe de Verificación del Mantenimiento del Software

a

VER

VAL

45. Plan de Evaluación del Software

ASR

VER

46. Informe de Evaluación del Software

ASR

VER

No existe un rol específico definido.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 93 -

EN 50128:2011

ANEXO D (Informativo) BIBLIOGRAFÍA DE LAS TÉCNICAS

D.1 Inteligencia Artificial: Corrección de Errores Objetivo Poder reaccionar a los posibles peligros de manera muy flexible mediante la introducción de una mezcla (combinación) de modelos de métodos y procesos y algún tipo de análisis de seguridad y fiabilidad en línea. Descripción Los sistemas de Inteligencia Artificial pueden soportar en particular muy eficazmente la previsión de errores (calculando las tendencias), la corrección de errores, las acciones de mantenimiento y de supervisión en diversos canales de un sistema, ya que se podrían obtener las reglas directamente de las especificaciones y comprobarlas con respecto a éstas. 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 con este enfoque, más aún cuando se aplica una combinación de modelos y métodos de manera funcional o descriptiva. Los métodos se seleccionan para que se puedan corregir los errores y para que se puedan minimizar los fallos, para cumplir así con los requisitos de seguridad y fiabilidad deseados. D.2 Programas Analizables Objetivo Diseñar un programa de forma que el análisis del programa sea realizable fácilmente. El comportamiento del programa debe poderse someter a ensayo tomando como base el análisis. Descripción El objetivo consiste en producir programas fáciles de analizar usando métodos de análisis estático. Para lograrlo se deberían seguir las reglas de programación estructurada, por ejemplo: – el flujo de control del componente debería estar compuesto de elementos estructurados, es decir de secuencias, de iteraciones y de selecciones; – los componentes deberían ser de pequeñas dimensiones; – el número de rutas posibles a través de un componente es bajo; – las partes individuales del programa han de diseñarse para que puedan separarse lo máximo posible; – la relación entre los parámetros de entrada y salida debería ser tan simple como sea posible; – no deberían usarse cálculos complejos como base de decisiones de ramificación y bucles; – las decisiones de ramificación y bucles deberían estar ligadas a los parámetros de entrada de los componentes de forma simple; – los límites entre diferentes tipos de correspondencias debe ser simple.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 94 -

D.3 Ensayos de Avalancha/Ensayos de Sobrecarga Objetivo Cargar al objeto de ensayo con una carga de trabajo excepcionalmente elevada para demostrar que el objeto de ensayo puede soportar fácilmente cargas de trabajo normales. Descripción Hay una serie de condiciones de ensayo que se pueden aplicar a los ensayos de sobrecarga. A continuación se enumeran algunas de estas condiciones: – si se trabaja en modo de sondeo, entonces el objeto sometido a ensayo recibe muchas más modificaciones de entrada por unidad de tiempo que en condiciones normales; – si se trabaja bajo demanda, entonces el número de demandas por unidad de tiempo dirigidas al objeto sometido a ensayo aumentan por encima de las que se producen en condiciones normales; – si el tamaño de una base de datos juega un papel importante, entonces se aumenta su tamaño por encima del que tendría en condiciones normales; – los dispositivos influyentes se regulan a su velocidad máxima o mínima respectivamente; – en casos extremos y en la medida de lo posible, todos los factores influyentes se llevan a la vez al límite de sus condiciones. En estas condiciones de ensayo se puede evaluar el comportamiento temporal del objeto sometido a ensayo. Se puede observar la influencia de las variaciones de la carga de trabajo. Se puede comprobar la dimensión correcta de los búferes internos o de las variables dinámicas, de las pilas, etc. D.4 Análisis de los Valores Límite Objetivo Eliminar los errores de software que se produzcan en los límites de los parámetros. Descripción El dominio de entrada del programa se divide en varias categorías de entrada. Los ensayos deberían cubrir los límites y extremos de las categorías. Los ensayos comprueban que los límites del dominio de entrada de la especificación coinciden con aquellos del programa. El uso del valor cero, tanto en una traducción directa como en una traducción indirecta, es normalmente susceptible de error y exige una atención especial: – divisor cero; – caracteres de control que no se imprimen; – pilas o elementos de lista vacíos; – matriz nula; – entrada de tabla nula. Normalmente los límites para entradas tienen una correspondencia directa con los límites del rango de salida. Los casos de ensayo deberían redactarse de forma que fuercen las salidas a sus valores límite. Se ha de tener en cuenta también si es posible especificar un caso de ensayo que cause que las salidas excedan los valores límite de la especificación.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 95 -

EN 50128:2011

Si la salida es una secuencia de datos, por ejemplo, una tabla impresa, se debería prestar atención especial al primer y al último elemento y a las listas que contienen 1, 2 elementos y ninguno. D.5 Recuperación Regresiva Objetivo Permitir una explotación funcional correcta en caso de uno o más errores. Descripción Si se detecta un error, el sistema se restaura a un estado interno anterior, cuya coherencia se haya comprobado previamente. Este método implica que el estado interno se guarda de forma frecuente creando lo que se conoce como puntos de recuperación bien definidos. Esta operación se puede realizar de manera global (para la base datos al completo) o de manera incremental (modificaciones solo entre los puntos de recuperación). Es necesario entonces que el sistema compense las modificaciones que mientras tanto han tenido lugar mediante el uso del registro por diario (journaling, auditoría de las acciones), de compensación (se anulan los efectos de las modificaciones) o de interacción (manual) externa. D.6 Diagramas de Causa Efecto Objetivo Modelar, en forma de diagrama, la secuencia de eventos que puede desarrollarse en un sistema como consecuencia de las combinaciones de eventos básicos. Descripción Esta técnica se puede considerar como la combinación del análisis del árbol de errores y del árbol de eventos. Comenzando a partir de un evento crítico, se traza un grafo causa-efecto hacia atrás y hacia adelante. En la dirección hacia atrás es equivalente a un árbol de errores con el evento crítico situado en la parte más alta. En la dirección hacia adelante, se identifican las posibles consecuencias que podrían producirse a partir del evento crítico. El grafo podría contener símbolos de vértices que describan las condiciones para la propagación a lo largo de las diferentes ramas que parten del vértice. También se pueden incluir los retrasos. Estas condiciones también pueden describirse con árboles de errores. Las líneas de propagación se pueden combinar con símbolos lógicos para hacer los diagramas más compactos. Se ha definido una serie de símbolos normalizados para su uso en diagramas de causa-efecto. Los diagramas pueden utilizarse para calcular la probabilidad de ocurrencia de ciertas consecuencias críticas. D.7 Listas de Comprobación Objetivo Estimular la evaluación crítica de todos los aspectos del sistema en lugar de imponer requisitos específicos. Descripción Se trata de una serie de preguntas que ha de contestar la persona encargada de completar la lista de comprobación. Muchas de estas preguntas son de tipo general y el Evaluador debe interpretarlas de la manera que considere más apropiada para el sistema específico que se esté evaluando. Para cubrir la amplia variedad de software y sistemas que se han de validar, la mayoría de las listas de comprobación contienen preguntas que se pueden aplicar a muchos tipos de sistema. En consecuencia, las listas de comprobación pueden contener preguntas que no son relevantes para el sistema en cuestión y que deberían ignorarse. Del mismo modo, un sistema en concreto podría necesitar completar las listas de comprobación normalizadas con preguntas dirigidas de forma específica al sistema en cuestión.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 96 -

En cualquier caso, debería quedar claro que el uso de listas de comprobación depende principalmente del nivel de experiencia y del juicio del ingeniero que seleccione y aplique la lista de comprobación. En consecuencia, las decisiones que tome el ingeniero, con respecto a las listas de comprobación seleccionadas, y a cualquier pregunta adicional o superflua, deberían documentarse y justificarse de forma detallada. El objetivo es garantizar que las listas de comprobación de la aplicación puedan revisarse y que se conseguirán los mismos resultados a menos que se hayan usado criterios diferentes. El objetivo de completar una lista de comprobación es el de ser lo más conciso posible. Cuando sea necesaria una justificación exhaustiva, debería hacerse mediante referencia a documentación adicional. Deberían usarse los términos Satisfactorio, Insuficiente y No Concluyente, o similares para registrar los resultados de cada pregunta. Esta concisión simplifica mucho el proceso que permite llegar a una conclusión global a partir de los resultados de la evaluación de las listas de comprobación. D.8 Análisis de Flujos de Control Objetivo Detectar estructuras del programa débiles y potencialmente incorrectas. Descripción Los Análisis de Flujos de Control identifican zonas sospechosas de código que no siguen las buenas prácticas de programación. El programa se analiza para formar un grafo orientado que puede analizarse para: – un código inaccesible, por ejemplo, saltos incondicionales que dejan bloques de código inaccesibles; – un código arborescente, que es un código bien estructurado cuyo grafo de control se puede reducir a un solo nodo mediante reducciones de grafos sucesivas. Un código estructurado débilmente solo puede reducirse a un árbol compuesto de varios nodos. D.9 Análisis de Fallos de Causa Común Objetivo Identificar los fallos potenciales en sistemas redundantes o en subsistemas redundantes que disminuirían los beneficios de la redundancia a causa de la aparición simultánea de los mismos fallos en las partes redundantes. Descripción Los sistemas informáticos concebidos para proteger la seguridad de una unidad de producción utilizan a menudo la redundancia en el hardware y la votación por mayoría. Esta técnica se utiliza para evitar fallos aleatorios de los componentes, que tenderían a evitar el tratamiento correcto de los datos en un sistema informático. Sin embargo, hay fallos que pueden ser comunes en varios componentes. Por ejemplo, si se instala un sistema informático en una única estancia, los defectos que sufra el sistema de climatización pueden reducir los beneficios de la redundancia. Lo mismo ocurre con otros efectos externos que puedan afectar al sistema informático como por ejemplo: incendios, inundaciones, interferencias electromagnéticas, los accidentes de avión y los terremotos. El sistema informático puede verse también afectado por incidentes relativos a la explotación y al mantenimiento. Es fundamental por tanto, que se disponga de procedimientos adecuados y bien documentados para la explotación y el mantenimiento. Es también fundamental la formación permanente del personal encargado de la explotación y el mantenimiento.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 97 -

EN 50128:2011

Los efectos internos contribuyen igualmente de forma muy importante a los Fallos de Causa Común (CCF, Common Cause Failures). Estos pueden provenir de errores de diseño en componentes comunes o idénticos y en sus interfaces, así como del envejecimiento de los componentes. El Análisis de CCF ha de examinar el sistema en busca de fallos potenciales comunes. Los métodos de Análisis de CCF son el control general de la calidad, las revisiones de diseño, la verificación y los ensayos realizados por un equipo independiente y el análisis de incidentes reales con la información de la experiencia adquirida en sistemas similares. Sin embargo, el campo de aplicación del análisis va más allá del hardware. Incluso si se utilizan varios softwares en cadenas complejas de un sistema informático redundante, podría haber cierto grado de normalización en los enfoques relativos al software que podrían dar lugar a CCF. Como por ejemplo, errores en la especificación común. Cuando los CCF no se producen exactamente en el mismo momento, se pueden adoptar medidas de prevención por medio de métodos de comparación entre las cadenas redundantes que deberían conducir a la detección de un fallo antes de que éste sea común a todas las cadenas. Se debería tener en cuenta esta técnica en el Análisis de Fallos de Causa Común. D.10 Análisis del flujo de datos Objetivo Detectar estructuras del programa débiles y potencialmente incorrectas. Descripción El Análisis de Flujo de Datos combina la información obtenida en el análisis de flujos de control con la información sobre qué variables se leen o se escriben en diferentes porciones del código. El análisis puede buscar – variables que se leen antes de que se escriban. Esto probablemente se tratará un error, y sin duda es una mala práctica de programación; – variables que se escriben más de una vez sin que se lean. Esto podría indicar que se ha omitido código; – variables que se escriben pero que nunca se leen. Esto podría indicar que un código es redundante. Hay una extensión del análisis de flujo de datos que se conoce con el nombre de análisis de flujo de información, en la que los flujos de datos reales (tanto en el interior como entre los procedimientos) se comparan con el proyecto de diseño. Este análisis se implementa normalmente mediante una herramienta informática en la que se definen los flujos de datos previstos usando un comentario estructurado que puede leer la herramienta. D.11 Diagramas de Flujo de Datos Objetivo Describir en forma de diagrama el flujo de datos en un programa. Descripción Los Diagramas de Flujos de Datos documentan cómo las entradas de datos se transforman en salidas, representando cada etapa del diagrama una transformación distinta. Los componentes básicos de un diagrama de flujo de datos incluyen: – funciones, representadas por burbujas; – flujos de datos, representados por flechas;

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 98 -

– unidades de almacenamiento de datos, representadas por cuadros abiertos; – entradas/salidas, representadas por tipos de cuadros especiales. Los diagramas del flujo de datos describen cómo se transforma una entrada en una salida. No incluyen, y no deberían incluir, información de control ni información de secuenciación. Cada burbuja puede considerarse como una caja negra autónoma que, en cuanto sus entradas están disponibles, las transforma en sus salidas. Una de las ventajas principales de los diagramas de flujos de datos es que muestran las transformaciones sin emitir ninguna hipótesis sobre la manera en que se implementan. El mejor enfoque para la preparación de los diagramas de flujos de datos es tener en cuenta las entradas del sistema y evolucionar hacia las salidas del sistema. Cada burbuja debe representar una transformación distinta - su salida debería ser de algún modo distinta a su entrada. 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 todos los diseños, es un proceso iterativo compuesto de intentos iniciales que se refinan en distintas etapas para obtener como resultado el diagrama final. D.12 Registro y análisis de los datos Objetivo Facilitar la mejora del proceso de software mediante el registro, validación y análisis de datos pertinentes provenientes de proyectos y de personas individuales. La relevancia de los datos viene determinada por los objetivos estratégicos de la organización. Los objetivos pueden estar dirigidos a la evaluación de un método particular de desarrollo del software relativa a las demandas que le conciernen, por ejemplo, en relación a la eficacia en la prevención de defectos. Descripción El registro y análisis de datos constituye una parte esencial de la mejora del proceso de software. El registro de datos válidos representa una parte importante para saber más sobre el proceso de desarrollo del software y para evaluar métodos alternativos de desarrollo del mismo. Durante un proyecto se mantienen registros detallados relativos al proyecto mismo y a cuestiones individuales. Por ejemplo, se podría requerir que un ingeniero mantuviera registros que podrían incluir lo siguiente: – el esfuerzo desarrollado en los componentes individuales; – los ensayos realizados en cada uno de los componentes; – las decisiones adoptadas y el razonamiento que se ha realizado para adoptarlas; – la consecución de los hitos del proyecto; – los problemas y sus soluciones. Estos registros pueden analizarse durante el proyecto y en el momento de su conclusión para establecer una gran variedad de información. El registro de datos es muy importante en particular para el mantenimiento de sistemas informáticos ya que los ingenieros de mantenimiento no siempre conocen el razonamiento que se ha utilizado para adoptar ciertas decisiones durante el proyecto de desarrollo. A causa de una mala planificación, el registro de datos tiende normalmente a ocupar un volumen excesivo y a carecer de precisión. Esto puede evitarse si el registro de datos sigue el principio de que lo que es realmente importante para la organización debería basarse en objetivos, preguntas y métricas de relevancia.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 99 -

EN 50128:2011

Para conseguir la precisión deseada, el registro de datos y el proceso de validación deberían proceder simultáneamente con el desarrollo, por ejemplo, como parte del proceso de control de la configuración. D.13 Tablas de Decisión (Tablas de Verdad) Objetivo Proporcionar una especificación clara y coherente de las relaciones y combinaciones lógicas complejas. Descripción Estos métodos usan dos tablas bidimensionales para describir de forma concisa las relaciones lógicas entre las variables booleanas del programa. La concisión y naturaleza tabular de ambos métodos los hace apropiados como medio de análisis de combinaciones lógicas complejas expresadas en un código. Ambos métodos son potencialmente ejecutables si se utilizan como especificaciones. D.14 Programación Defensiva Objetivo Producir programas que detecten flujos de control, flujos de datos o valores de datos anormales durante su ejecución y reaccionar a estos de manera aceptable y predeterminada. Descripción Durante la programación se pueden utilizar diversas técnicas para comprobar la existencia de anomalías en el control o en los datos. Dichas técnicas se pueden aplicar de forma sistemática durante la programación de un sistema para disminuir la probabilidad de procesamiento erróneo de datos. Se pueden identificar dos zonas de solapamiento de técnicas defensivas. El software a prueba de errores con seguridad intrínseca está diseñado para tener en cuenta sus propias imperfecciones de diseño. Estas imperfecciones pueden ser debidas a simples errores de diseño o de codificación, o a requisitos erróneos. A continuación se recogen algunas técnicas defensivas: – debería verificarse el rango de las variables; – cuando sea posible, se debería comprobar la plausibilidad de los valores; – debería comprobarse el tipo, dimensión y rango de los parámetros de los procedimientos a la entrada del procedimiento. Estas tres primeras recomendaciones ayudan a garantizar que los números manipulados por el programa son razonables, tanto en lo que se refiere a la función del programa como a la significación física de las variables. Deberían separarse los parámetros de solo lectura y de lectura-escritura y se debería comprobar su acceso. Las funciones deberían tratar a todos los parámetros como de solo lectura. Las constantes literales no deberían ser accesibles a la escritura. Esto ayuda a detectar una sobrescritura accidental o una utilización errónea de las variables. Un software tolerante a errores está diseñado de forma que "espera" fallos en su propio entorno o un uso fuera de las condiciones normales o previstas, y se comporta de una manera predefinida. Las técnicas incluyen las siguientes:

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 100 -

– debería comprobarse la plausibilidad de las variables de entrada y de las variables intermedias con significancia física; – debería comprobarse el efecto de las variables de salida, preferiblemente mediante la observación directa de las modificaciones de estado del sistema asociado; – el software debería comprobar su propia configuración. Esto podría incluir tanto la existencia y accesibilidad del hardware previsto como también el estado completo del software. Esto es particularmente importante para mantener la integridad después de los procedimientos de mantenimiento. Algunas de las técnicas de programación defensiva como la comprobación de las secuencias de los flujos de control también se encargan de fallos externos. D.15 Normas de Codificación y Guía de Estilo Objetivo Garantizar una presentación uniforme de los documentos de diseño y del código producido, imponer una programación coherente e imponer un método de diseño normalizado que evite los errores. Descripción Las Normas de Codificación son reglas y restricciones relativas a un lenguaje de programación determinado para evitar errores potenciales que puedan cometerse cuando se utiliza el lenguaje en cuestión. El contenido de las normas de codificación debería incluir: – una justificación del lenguaje utilizado; – el campo de aplicación y la norma utilizada como base, cuando sea posible; NOTA Puede que no existan normas base para lenguajes específicos de dominio.

– el procedimiento de modificación de la norma de codificación; – el análisis de los errores potenciales y su tratamiento recomendado; – las restricciones para evitar errores; – la portabilidad. Las Guías de Estilo tratan asuntos como las convenciones de formateo y las convenciones de nomenclatura, y aunque pueden ser muy subjetivas, el estilo afecta principalmente a la legibilidad del código. El establecimiento de un estilo común y coherente para un proyecto facilitará la comprensión y el mantenimiento del código desarrollado por más de un programador, y hará más fácil para algunas personas cooperar en el desarrollo del mismo programa. D.16 Programación con Múltiples Versiones Objetivo Detectar y ocultar los errores residuales de diseño del software durante la ejecución de un programa, para evitar que el sistema sufra fallos críticos de seguridad y para que siga funcionando con mayor fiabilidad.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 101 -

EN 50128:2011

Descripción En la programación con múltiples versiones se implementa una especificación de programa determinada N veces de diferentes formas. Se dan los mismos valores de entrada a las N versiones y se comparan los resultados que producen las N versiones. Si se considera válido el resultado se transmite entonces a las salidas informáticas. Las N versiones pueden ejecutarse en paralelo en diferentes ordenadores, o ejecutarse en el mismo ordenador sometiendo a los resultados a una votación interna. Se pueden utilizar diferentes estrategias de votación en las N versiones dependiendo de los requisitos de la aplicación. – Si el sistema tiene un estado seguro, entonces es posible exigir un acuerdo completo (todas las N versiones); en caso contrario, se utiliza un valor de salida de estado seguro. En sistemas de desactivación simple la decisión puede estar influenciada a favor de la seguridad. En este caso, la acción de seguridad sería la de desconectar el sistema si una u otra versión lo exigiera. Normalmente, este enfoque solo utiliza dos versiones (N = 2). – Para sistemas que no tienen un estado seguro, se pueden utilizar estrategias de votación por mayoría. En el caso de que no exista un acuerdo colectivo, se pueden utilizar enfoques probabilísticos para maximizar la probabilidad de seleccionar el valor correcto, por ejemplo, tomando el valor medio, congelando temporalmente las salidas hasta que se vuelva a un acuerdo, etc. Esta técnica no elimina los errores residuales de diseño del software, pero proporciona una medida para detectarlos y ocultarlos antes de que puedan afectar a la seguridad. Desafortunadamente, los experimentos y los estudios analíticos muestran que la programación de N versiones no siempre es tan eficaz como se desearía. Incluso si se utilizan algoritmos diferentes, las múltiples versiones de software fallan a menudo en las mismas entradas. Dos alternativas a la programación de N versiones son la diversidad de diseño y la diversidad funcional. La diversidad de diseño comprende múltiples componentes, cada uno diseñado de forma diferente pero implementando la misma función. La diversidad funcional comprende resolver el mismo problema de maneras funcionalmente diferentes. Independientemente del enfoque, en la actualidad no existe un método efectivo para evaluar el nivel de diversidad. D.17 Reconfiguración Dinámica Objetivo Mantener la funcionalidad del sistema a pesar de los errores internos. Descripción La arquitectura lógica del sistema ha de ser tal que se pueda configurar sobre un subconjunto de los recursos disponibles del sistema. Es necesario que la arquitectura pueda detectar un fallo en un recurso físico y que a continuación pueda reconfigurar la arquitectura lógica sobre los recursos limitados que siguen funcionando. Aunque el concepto tradicionalmente ha hecho referencia a la recuperación a causa de unidades de hardware averiadas, se puede aplicar también a unidades de software si hay una "redundancia de ejecución" suficiente que permita un reintento del software o si hay datos redundantes suficientes para aislar el fallo. Aunque el concepto se haya aplicado tradicionalmente al hardware, está técnica se está desarrollando para su aplicación al software y, por tanto, a la totalidad del sistema. Se debe tener en cuenta en la primera etapa de diseño del sistema. D.18 Ensayos de Clases de Equivalencia y de Partición de Entradas Objetivo Someter al software a ensayos de manera adecuada utilizando un mínimo de datos de ensayo. Los datos de ensayo se obtienen seleccionando las particiones del dominio de entrada requeridas para someter al software a ensayo.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 102 -

Descripción Esta estrategia de ensayo se basa en la relación de equivalencia de las entradas, que determina una partición del dominio de entrada. La selección de los casos de ensayo tiene por objetivo cubrir todos los subconjuntos de esta partición. Se toma un caso de ensayo como mínimo de cada clase de equivalencia. Las dos posibilidades básicas para la partición de las entradas son las siguientes: – las clases de equivalencia se pueden definir a través de la especificación. La interpretación de la especificación puede estar orientada a las entradas, por ejemplo, los valores seleccionados se tratan de la misma manera, u orientada a las salidas, por ejemplo, el conjunto de valores conducen al mismo resultado funcional; y – las clases de equivalencia se pueden definir a través de la estructura interna del programa. En este caso, las clases de equivalencia se determinan a partir del análisis estático del programa, por ejemplo, el conjunto de valores que hace que se ejecute la misma ruta. D.19 Códigos de Detección y Corrección de Errores 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. Los diferentes tipos de código incluyen: – códigos de Hamming; – códigos cíclicos; – códigos polinomiales; – códigos hash; – códigos criptográficos. D.20 Suposición de Errores Objetivo Eliminar los errores de programación comunes. Descripción La experiencia realizando ensayos y la intuición junto con el conocimiento y la curiosidad sobre el sistema que está siendo sometiendo a ensayo pueden añadir algunos casos de ensayo no clasificados al conjunto de casos de ensayo que se había diseñado. Los valores específicos o las combinaciones de valores pueden ser propicias a error. Algunos casos de ensayo interesantes pueden surgir a partir de las listas de comprobación. Se puede tener en cuenta 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 a la vez?

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 103 -

EN 50128:2011

D.21 Inserción de Errores Objetivo Comprobar si un conjunto de casos de ensayo es adecuado. Descripción Algunos tipos de errores conocidos se insertan en el programa y éste se ejecuta con los casos de ensayo en condiciones de ensayo. Si solo se encuentran algunos de los errores introducidos, se considera que el conjunto de casos de ensayo no es adecuado. La relación entre el número de errores introducidos encontrados y el número total de errores introducidos es una estimación de la relación de errores reales encontrados y el número total de errores. Esto ofrece la posibilidad de realizar una estimación del número de errores restantes y por tanto del esfuerzo de ensayo restante.

Errores introducidos encontrados Errores reales encontrados = Número total de errores introducidos Número total de errores reales La detección de todos los errores introducidos puede indicar que el conjunto de casos de ensayo es el adecuado, o que fue demasiado fácil encontrar los errores introducidos. Este método comporta limitaciones ya que, para obtener resultados útiles, los tipos de errores así como las posiciones de las inserciones deben corresponder a la distribución estadística de los errores reales. Si se utiliza la técnica de inserción de errores, se debe registrar la ubicación de los errores, y el validador debe garantizar que se han eliminado todos los errores introducidos antes de la publicación de una versión de software. D.22 Análisis por Árbol de Eventos Objetivo

Modelar, en forma de diagrama, la secuencia de eventos que puede desencadenarse en un sistema después de un evento inicial, y como resultado, indicar las consecuencias graves que puede tener. Descripción

En la parte superior del diagrama está escrita la secuencia de condiciones relevantes en el desencadenamiento que siguen al evento inicial que es el objetivo del análisis. Empezando por el evento inicial se dibuja una línea a la primera condición en la secuencia. El diagrama se bifurca entonces en una rama 'sí' y otra 'no', describiendo cómo depende el desarrollo futuro de la condición. Con cada una de las ramas se continúa hacia la siguiente condición de forma similar. Sin embargo, no todas las condiciones son relevantes para todas las ramas. Se sigue hasta el fin de la secuencia, y 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 el número de condiciones en la secuencia. D.23 Inspecciones de Fagan Objetivo

Descubrir errores en todas las fases de desarrollo del programa. Descripción

Se trata de una auditoría "formal" sobre los documentos de garantía de 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 las fases tiene un objetivo específico. Debe inspeccionarse el desarrollo del sistema completo (especificación, diseño, codificación y ensayos).

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 104 -

D.24 Programación con Aserciones Objetivo

Detectar errores residuales durante la ejecución de un programa de software. Descripción

El método de programación con aserciones sigue el principio de comprobar una precondición (se comprueba la validez de las condiciones iniciales antes de que se ejecute una secuencia de instrucciones) y una postcondición (se comprueban los resultados después de la ejecución de una secuencia de instrucciones). Si no se cumplen la precondición o la postcondición, se interrumpe el procesamiento con un error. Por ejemplo, aserción ; acción 1; : : acción x; aserción ; D.25 AEES. Análisis de los Efectos de los Errores del Software Objetivo

Identificar los componentes software y su criticidad; proponer medios para detectar errores de software y mejorar la robustez del software; evaluar la cantidad de validación necesaria para los diversos componentes software. Descripción

El análisis se realiza en tres fases. •

Identificación de los componentes software vitales Determinación de la profundidad del análisis (a nivel de una simple línea de instrucción, de un grupo de instrucciones, de un componente, etc.) necesario para cada componente software en base a su especificación.

•

Análisis de los Errores del Software El resultado de esta fase es una tabla que recoge la siguiente información: – nombre del componente; – error considerado; – consecuencias del error a nivel del módulo; – consecuencias a nivel del sistema; – criterio de seguridad violado;

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 105 -

EN 50128:2011

– criticidad del error; – medios propuestos de detección del error; – criterio violado si se implementa el medio de detección; – criticidad residual si se implementa el medio 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 realizado por un equipo independiente, es un método potente para descubrir errores. D.26 Detección de Errores y Diagnóstico Objetivo

Detectar errores en un sistema, que puedan provocar un fallo, proporcionando así las contramedidas que minimicen las consecuencias de los fallos. Descripción

La detección de errores es el proceso de comprobación de un sistema para detectar estados erróneos (causados, como se ha explicado anteriormente, por un error dentro del (sub)sistema bajo comprobación). El objetivo principal de la detección de errores es inhibir el efecto de 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 errores se basa en los principios de redundancia (principalmente para detectar errores del hardware) y diversidad (defectos del software). Es necesario algún tipo de votación para decidir qué resultados son los correctos. Los métodos especiales aplicables son las técnicas de programación con aserciones, la programación de N versiones y la bolsa de seguridad, y a nivel del hardware la introducción de sensores, bucles de control, códigos de comprobación de errores, etc. La detección de errores puede conseguirse mediante comprobaciones en el dominio de valores o en el domino del tiempo a varios niveles, especialmente a nivel físico (temperatura, tensión, etc.), lógico (códigos de detección de error), funcional (aserciones) o a nivel 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 errores, del diagnóstico y de la compensación de errores, depende de la complejidad de las interacciones entre los subsistemas, que afecta a la propagación de los errores. El diagnóstico de los errores aísla al subsistema más pequeño que pueda identificarse. Los subsistemas más pequeños permiten un diagnóstico más detallado de los errores (identificación de estados erróneos). D.27 Máquinas de Estados Finitos/Diagramas de Transición de Estado Objetivo

Definir o implementar la estructura de control de un sistema.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 106 -

Descripción

Muchos sistemas pueden definirse en relación a sus estados, sus entradas y sus acciones. Así, cuando un sistema está en el estado S1 y recibe una entrada I, podría realizar una acción A y cambiar al estado S2. Definiendo las acciones de un sistema para cada entrada en cada estado se puede definir completamente un 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 cómo el sistema pasa de un estado a otro, o cómo una matriz cuyas dimensiones son estados y entradas y las celdas 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 simularse en una Máquina de Estados Finitos de varios niveles. En una especificación o diseño expresados como una Máquina de Estados Finitos se puede comprobar su compleción (el sistema debe tener una acción y un nuevo estado para cada entrada en cada estado), su coherencia (solamente se define una modificación de estado para cada pareja estado/entrada) y su accesibilidad (si es posible o no pasar de un estado a otro mediante una secuencia de entradas). Estas propiedades son importantes para sistemas críticos y se pueden comprobar. Se pueden escribir 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 Máquina de Estados Finitos o para la animación de un modelo de Máquina de Estados Finitos. Se han diseñado varias extensiones de las Máquinas de Estados Finitos para mejorar la descripción del comportamiento de un sistema complejo. Los llamados diagramas de estado añaden jerarquía, composición (paralelismo), transiciones entre niveles, estados anteriores, etc. Una característica especialmente útil es el anidamiento de estados y transiciones internas, dando la posibilidad de revelar u ocultar los estados internos según sea necesario. Los diagramas de estado son parte de UML (Lenguaje Unificado de Modelado), y por tanto, numerosas herramientas comerciales los soportan. D.28 Métodos Formales Objetivo

Los "Métodos Formales" hacen referencia a las técnicas y herramientas matemáticamente rigurosas usadas para la especificación, el diseño y la verificación de sistemas de software y hardware. Descripción

Por "matemáticamente rigurosas" se entiende que las especificaciones usadas en los métodos formales son instrucciones bien formadas en una lógica matemática y que las verificaciones formales son deducciones rigurosas en dicha lógica (es decir, cada etapa proviene de una regla de inferencia y por tanto puede verificarse mediante un proceso mecánico). El valor de los métodos formales es que proporcionan un medio para examinar de forma simbólica el total del espacio de los estados de un diseño digital (ya sea hardware o software) y que establecen una aserción o propiedad de seguridad que es cierta para todas las entradas posibles. Hoy en día sin embargo, rara vez se utilizan estos métodos (excepto para los componentes críticos de los sistemas críticos de seguridad) a causa de la enorme complejidad de los sistemas reales. Se utilizan varios enfoques para superar los espacios de tamaño astronómico de los estados asociados a los sistemas reales: – aplicar métodos formales a los requisitos y a los diseños de alto nivel en los que se abstraen la mayoría de los detalles; – aplicar métodos formales únicamente a los componentes más críticos; – analizar los modelos de software y hardware donde las variables se hacen discretas y los rangos se reducen de forma drástica; – analizar los modelos de sistema de una manera jerárquica que permita "dividir y vencer"; – automatizar la verificación lo máximo posible.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 107 -

EN 50128:2011

Aunque el uso de la lógica matemática es un tema unificador en la disciplina de los métodos formales, no existe un único "método formal" que pueda considerarse como el mejor. Cada dominio de aplicación requiere diferentes métodos de modelado y diferentes enfoques de demostración. Es más, incluso dentro de un dominio de aplicación particular, diferentes herramientas y técnicas pueden servir mejor a las diferentes fases del ciclo de vida. Por ejemplo, para analizar la validez de una descripción del nivel de transferencias de registros de un circuito de Transformación Rápida de Fourier sería mejor utilizar un demostrador de teoremas, mientras que podría ser mejor utilizar métodos de derivación algebraicos para analizar la validez de los refinamientos de diseño en el diseño al nivel de puertas. Existen por tanto un gran número de métodos formales en desarrollo repartidos por todo el mundo. En los siguientes apartados de esta bibliografía se describen varios ejemplos de Métodos Formales. La lista de ejemplos aquí descrita no es exhaustiva. Los Métodos Formales aquí descritos son el CSP, CCS, HOL, LOTOS, OBJ, Lógica Temporal, VDM, Método Z, Método B y Verificación de Modelo (Model Checking). D.28.1 CSP (Communicating Sequential Processes) – Comunicación de Procesos Secuenciales Objetivo

La CSP es una técnica para la especificación de sistemas de software concurrentes, es decir, sistemas de procesos que se comunican funcionando concurrentemente. Descripción

La CSP proporciona un lenguaje para la especificación de sistemas de procesos y la demostración para verificar que la implementación de procesos satisface sus especificaciones (descritas como una traza - secuencias permisibles de eventos). 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. La temporización relativa de eventos puede modelarse. La teoría que soporta la CSP fue incorporada directamente en el transputer de INMOS1), y el lenguaje OCCAM2) permite que un sistema especificado mediante CSP se implemente directamente sobre una red de transputers. D.28.2 CCS – Cálculo de Sistemas de Comunicación Objetivo

El CCS es un medio para describir y razonar acerca del comportamiento de sistemas de procesos concurrentes que se comunican entre sí. Descripción

Como la técnica de CSP, el 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 funcionando 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. El comportamiento no determinista puede modelarse. 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 inferencia relacionadas con las reglas de composición. 1) Inmos era una compañía británica de semiconductores que produjo en los años 80 una arquitectura innovadora de microprocesadores destinada al procesamiento en paralelo, llamada transputer. Más tarde Inmos se convirtió en parte de SGS-Thomson y posteriormente de STMicroelectronics. 2) OCCAM es un lenguaje de programación concurrente cuyo nombre se deriva del de Guillermo de Ockham conocido por su principio de la Navaja de Ockham. Es el lenguaje de programación nativo para el transputer de INMOS.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 108 -

D.28.3 HOL (Higher Order Logic) – Lógica de Primer Orden 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 Primer Orden) 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 se toma en su mayoría de la Teoría Simple de Tipos de Church y el sistema de soporte máquina se basa en el sistema Lógica de Funciones Computables, LCF (Logic of Computable Functions). D.28.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

El Lenguaje para la Especificación de Ordenación Temporal, LOTOS (Language for Temporal Ordering Specification) se basa 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 abstractos de datos ACT ONE. El componente de definición de procesos de LOTOS podría utilizarse sin embargo con otros formalismos para la descripción de tipos abstractos de datos. D.28.5 OBJ Objetivo

Proporcionar una especificación precisa del sistema con información para el usuario y validación del sistema antes de la implementación. Descripción

El OBJ es un lenguaje de especificación algebraica. 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 abstractos de datos (TAD). Un TAD es similar a un paquete Ada3), donde el comportamiento del operador es visible, mientras que los detalles de implementación quedan 'ocultos'. Una especificación OBJ, y la consiguiente implementación paso a paso, puede someterse a las mismas técnicas de demostración formal que otros enfoques 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 (reescritura) que continúa hasta que se obtiene el valor de salida específico. La posibilidad de ejecutar 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.

3) Ada es un lenguaje de programación informático de alto nivel estructurado, tipado de forma estática, imperativo, de amplio espectro, y orientado a objetos, que es una extensión de Pascal y otros lenguajes.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 109 -

EN 50128:2011

Como con otras técnicas TAD, OBJ se aplica solamente a sistemas secuenciales, o a 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. D.28.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 Estándar de Predicados de Primer Orden 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 aserciones sobre el sistema. Por ejemplo, puede requerirse que las propiedades de seguridad se mantengan 'de ahora en adelante', mientras puede que se requiera que otros estados deseados del sistema 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. La lógica temporal no maneja de forma explícita intervalos de tiempo cuantificados y restricciones. Una temporización absoluta tiene que manejarse creando estados de tiempo adicionales como parte de la definición de estados. D.28.7 VDM (Vienna Development Method) – Método de Desarrollo de Viena Objetivo

La especificación sistemática e implementación de programas secuenciales. Descripción

El 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 demostrar su corrección con respecto a la especificación. La técnica de especificación se basa en un modelo en el que el estado del sistema se modela 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 precondiciones y sus postcondiciones en términos del estado del sistema. Se puede demostrar 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 objetivo y mediante el refinamiento de las operaciones en términos de un programa en dicho lenguaje. Los pasos de materialización y refinamiento dan lugar a obligaciones de demostración 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 a procesos secuenciales en sistemas concurrentes. D.28.8 Método Z Objetivo

Z es una notación de lenguaje de especificación para sistemas secuenciales y una técnica de diseño que permite al diseñador llegar, a partir de una especificación Z, a algoritmos ejecutables de forma que se puede demostrar que son correctos con respecto a la especificación.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 110 -

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. Descripción

Como el VDM, la técnica de especificación se basa en un modelo en el cual se modela 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 precondiciones y postcondiciones en términos del estado del sistema. Se puede demostrar que las operaciones preservan los invariantes del sistema, demostrando así su coherencia. La parte formal de una especificación se divide en esquemas que permiten la estructuración de las especificaciones a través de su refinamiento. Normalmente, una especificación Z es una mezcla de Z formal y texto explicativo informal 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 del 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. D.28.9 Método B Objetivo

Como el VDM, el propósito del método B es modelar formalmente un sistema o un software y demostrar que el comportamiento del sistema o software respeta las propiedades que se establecieron como explícitas durante el modelado. Descripción

El modelado B apela a elementos matemáticos de la Teoría de Conjuntos. Por un lado, los invariantes (es decir, predicados) definen las propiedades estáticas del modelo. Por otra parte, las operaciones establecen las postcondiciones, definiendo su comportamiento dinámico. La especificación de un sistema o software complejo es posible por la descomposición del modelo en "máquinas" unidas por enlaces de semántica diferente. Se pueden distinguir dos categorías principales de modelado con el formalismo B. – La antigua (históricamente la primera) tiene como objetivo diseñar software: en este caso, el objetivo es producir un programa que respete la especificación. El modelo consiste en máquinas abstractas (no necesariamente deterministas) y refinamientos por etapas de dichas máquinas, que conducen a implementaciones deterministas escritas en un pseudocódigo llamado "B0". Dicho pseudocódigo se puede traducir entonces de forma automática a un lenguaje de programación objetivo. – La segunda categoría tiene como objetivo modelar sistemas y en este caso hablamos de un "Evento B" ("Event B"): el propósito es especificar, sin ambigüedades y de forma coherente, un sistema que cumpla las propiedades explícitas. El modelo tiene en cuenta el propio sistema y su entorno. Las dinámicas del sistema se modelan mediante “eventos”, y la técnica de refinamiento se usa para precisar las interacciones entre el sistema y su entorno. Se genera una serie de Obligaciones de Demostración (aserciones lógicas que se demuestran formalmente a partir de hipótesis extraídas del modelo formal B) de forma automática. Dichas Obligaciones de Demostración garantizan: – la existencia de datos que cumplen las propiedades estáticas y dinámicas del modelo; – que las operaciones (comportamiento dinámico del modelo) respetan al invariante; – que el refinamiento de los datos y de las operaciones (y el pseudocódigo B0, si es necesario) no contradicen la especificación escrita en las máquinas abstractas;

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 111 -

EN 50128:2011

– que se llama a cada operación dentro del contexto de su precondición; – en el caso del modelado de software, que el programa se termina (en particular, que se termina cada lazo). También se generan otras Obligaciones de Demostración, como por ejemplo la verificación del desbordamiento subdesbordamiento de enteros. D.28.10

Verificación de Modelo (Model Checking)

Objetivo

Dado un modelo de sistema, ensayar de forma automática que este modelo cumple una especificación determinada. Descripción

La verificación de modelo es el proceso consistente en verificar si una estructura determinada es un modelo de una fórmula lógica determinada. El concepto es general y se aplica a todos los tipos de lógicas y de estructuras apropiadas. Un simple problema de verificación de modelo es comprobar mediante un ensayo si una estructura determinada satisface una fórmula determinada en la lógica proposicional. Se ha desarrollado una clase importante de métodos de verificación de modelo para verificar mediante algoritmos los sistemas formales. Esto se consigue verificando si la estructura, que se deriva comúnmente de un diseño de hardware o software, satisface una especificación formal, normalmente una fórmula de lógica temporal. La verificación de modelo se aplica a menudo a los diseños de hardware. A causa de las indecisiones (véase la Teoría de la Computabilidad) el enfoque para el software no puede ser completamente algorítmico; a menudo no puede utilizarse para demostrar o descartar una propiedad determinada. La estructura se da normalmente como una descripción de un código fuente en un lenguaje de descripción de hardware industrial o en un lenguaje de propósito específico. Un programa así corresponde a una máquina de estados finitos, es decir, un grafo orientado formado por nodos (o vértices) y arcos. A cada nodo se asocia un conjunto de proposiciones atómicas, indicando normalmente qué elementos de memoria son uno. Los nodos representan los estados de un sistema, los arcos representan las transiciones posibles que pueden alterar el estado, mientras que las proposiciones atómicas representan las propiedades básicas que son válidas en un punto de la ejecución. Formalmente, el problema se puede exponer de la siguiente forma: dada una propiedad deseada, expresada como una fórmula de lógica temporal p, y una estructura M con un estado inicial s, decidir si. Si M es finita, como es el caso en el hardware, la verificación de modelo se reduce a una búsqueda de grafo. D.29 Demostración Formal Objetivo

Usando modelos teóricos y matemáticos y reglas es posible demostrar la corrección de un programa o modelo sin ejecutarlo. Descripción

Se establecen un número de aserciones en varios puntos del programa y se utilizan como precondiciones y postcondiciones para varias rutas dentro del mismo. La demostración consiste en demostrar que el programa transfiere las precondiciones a las postcondiciones de acuerdo con un conjunto de reglas lógicas establecidas y que el programa termina. En esta bibliografía se describen varios métodos formales, por ejemplo, CCS, CSP, HOL, LOTOS, OBJ, Lógica Temporal, VDM y Z. Las descripciones de los mismos pueden encontrarse en el apartado D.28 de 'Métodos Formales'.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 112 -

D.30 Recuperación Anticipada Objetivo

Permitir una explotación funcional correcta en caso de uno o más errores. Descripción

Si se detecta un error, se manipula el estado actual del sistema para obtener un estado que deberá ser coherente 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. D.31 Sistema Tolerante a Errores Objetivo

Mantener disponibles las funciones más críticas del sistema a pesar de los fallos, abandonando las funciones que son menos críticas. Descripción

Esta técnica da prioridad a varias de las funciones que realiza el sistema. El diseño asegura entonces que en caso de que haya recursos insuficientes para realizar todas las funciones del sistema, las de más alta prioridad se realizan con preferencia sobre las de menor prioridad. Por ejemplo, el registro de errores y eventos puede tener funciones con menor prioridad que las funciones de control del sistema, en cuyo caso, el control del sistema continuaría si el hardware asociado con el registro de errores fallase. Otro ejemplo sería el de un sistema de señalización, donde, en caso de pérdida de comunicación con el centro de control, el equipo local de señalización lateral establece de forma automática los itinerarios disponibles para la dirección tomada por los trenes con mayor prioridad. Este sería un ejemplo de sistema tolerante a errores ya que los trenes que circulan en rutas prioritarias podrían pasar por la zona afectada por la pérdida de comunicación con el centro de control, pero otro tipo de movimientos, como los movimientos de maniobras, no serían posibles. D.32 Análisis de Impacto Objetivo

Identificar el efecto que tiene una modificación o una mejora en el software sobre otros componentes de dicho software o sobre otros sistemas. Descripción

Antes de llevar a cabo una modificación o mejora en el software, se debe 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 componentes software afectados. Una vez completado el análisis, se requiere una decisión con respecto a la reverificación del software del sistema. Ello depende del número de componentes software afectados, la criticidad de los mismos y la naturaleza de las modificaciones. Las decisiones posibles son: a) solo se reverifican los componentes modificados; b) se reverifican todos los componentes afectados identificados; y c) se reverifica el sistema al completo.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 113 -

EN 50128:2011

D.33 Ocultación de Información/Encapsulamiento 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 modificación de esas estructuras de datos puede requerir un examen detallado del código y extensas modificaciones. La ocultación de la información es un enfoque general para minimizar dichas dificultades. Las estructuras de datos clave se "ocultan" y solo 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 al comportamiento del software restante. Por ejemplo, un directorio puede tener los procedimientos de acceso Insertar, Borrar y Encontrar. Los procedimientos de acceso y las estructuras de datos internas pueden reescribirse (por ejemplo, para usar un método de búsqueda diferente o para almacenar los nombres en un disco duro de forma diferente) sin afectar al 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. D.34 Ensayos de Interfaz Objetivo

Demostrar que las interfaces de los subprogramas no contienen ningún tipo de error o errores que den lugar a fallos en una aplicación particular del software o detectar todos los errores que pueden ser relevantes. Descripción

Existen varios niveles posibles de detalle o compleción de los ensayos. Los niveles más importantes son someter a ensayo: – todas las variables de interfaz en sus posiciones extremas; – todas las variables de interfaz individualmente en sus valores extremos con otras variables de interfaz en valores normales; – todos los valores del dominio de cada variable de interfaz con otras variables de interfaz en valores normales; – todos los valores de todas las variables de interfaz en conjunto (puede que esto solo pueda realizarse en interfaces pequeñas); – las condiciones de ensayo especificadas relevantes para cada llamada a cada subrutina. Estos ensayos son particularmente importantes si las interfaces no contienen aserciones para detectar valores incorrectos de parámetros. Son importantes también después de que se hayan generado configuraciones nuevas para subprogramas preexistentes.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 114 -

D.35 Subconjunto del Lenguaje Objetivo

Reducir la probabilidad de introducir errores de programación e incrementar la probabilidad de detectar errores 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. D.36 Memorización de Casos Ejecutados Objetivo

Forzar al software a un estado a prueba de fallos si ejecuta una ruta no autorizada. Descripción

Durante el proceso de autorización, 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 la secuencia de rutas individuales de decisión a decisión (rutas DD) o la secuencia de accesos individuales a matrices (arrays), registros o volúmenes, o ambos. Existen varios métodos posibles para el almacenamiento de las rutas de ejecución. Pueden usarse métodos de codificación hash para mapear la secuencia de ejecución a un único número grande o a una secuencia de números. Durante el funcionamiento normal, se debe comprobar el valor de la ruta de ejecución frente a los casos almacenados antes de efectuar una operación de salida. Ya que las combinaciones posibles de rutas de decisión a 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 componente. D.37 Métricas Objetivo

Predecir los atributos de los programas a partir de propiedades del propio software en lugar de a partir de su desarrollo o su historia de ensayos. Descripción

Estos modelos evalúan algunas propiedades estructurales del software y las asocian a un atributo deseado como la complejidad. Se necesitan herramientas de software para evaluar la mayoría de las medidas. A continuación se describen algunas de las métricas que pueden aplicarse: – Complejidad Teórica de los Grafos: esta medida puede aplicarse al principio del ciclo de vida para evaluar los compromisos (trade-offs) y se basa en la complejidad del grafo de control del programa, representada por su número ciclomático; – número de maneras de activar un determinado componente (accesibilidad): cuanto más se pueda acceder a un componente, mayor es la probabilidad de que sea depurado;

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 115 -

EN 50128:2011

– medida de complejidad de Halstead: 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 componente: 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. D.38 Enfoque Modular Objetivo

Descomposición de un software en partes pequeñas comprensibles a fin de limitar la complejidad del software. Descripción

El Enfoque 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 durante el diseño. La mayoría de los métodos contienen las siguientes reglas: – un módulo/componente debe tener una sola tarea o función bien definida a ejecutar; – las conexiones entre módulos/componentes deben estar limitadas y estrictamente definidas, y la coherencia en el módulo debe ser fuerte; – las colecciones de subprogramas se deben construir proporcionando varios niveles de módulos/componentes; – los subprogramas deben tener una sola entrada y una sola salida; – módulo/componentes se deben comunicar con otros módulos a través de sus interfaces. Las variables globales o comunes que se utilicen deben estar bien estructuradas, el acceso debe estar controlado y su uso se debe justificar en cada caso; – todas las interfaces de los módulos/componentes deben estar completamente documentadas; – las interfaces de módulos/componentes deben contener el mínimo número de parámetros necesarios para la función de los módulos/componentes; y – se debe especificar una restricción adecuada para el número de parámetros, normalmente 5. D.39 Modelado de las Prestaciones Objetivo

Garantizar que la capacidad de trabajo del sistema es suficiente para alcanzar los requisitos especificados. Descripción

La especificación de requisitos incluye requisitos relativos a la capacidad de procesamiento y de respuesta para funciones específicas, combinados quizá con restricciones en el uso de los recursos totales del sistema. 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; – la identificación del uso de recursos realizado por cada uno de los procesos, por ejemplo, tiempo de ocupación de la unidad central de proceso, ancho de banda de las comunicaciones, dispositivos de almacenamiento, etc.;

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 116 -

– la identificación de la distribución de peticiones que recibe el sistema en condiciones medias y en las condiciones más desfavorables; – el cálculo de la capacidad de procesamiento media y la más desfavorable, y los tiempos de respuesta para las funciones 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 modelado detallado, puede hacerse una comprobación simple del 'presupuesto de recursos', sumando los requisitos de recursos de cada proceso. Si los requisitos exceden la capacidad diseñada para el sistema, el diseño no es realizable. Incluso si el diseño pasa esta comprobación, el modelado de prestaciones puede mostrar que tienen lugar retrasos 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, el 50%) de los recursos totales a fin de reducir la probabilidad de la escasez de recursos. D.40 Requisitos de las Prestaciones Objetivo

Establecer que se han cumplido los requisitos de las prestaciones de un software. Descripción

Se realiza un análisis tanto de las Especificaciones de Requisitos del Software, como del Sistema, para identificar todos los requisitos generales, específicos, explícitos e implícitos de las prestaciones. Cada requisito de las prestaciones se examina a su vez para determinar: – los criterios de éxito a obtener; – si se puede establecer alguna medida de satisfacción relativa a los criterios de éxito; – la precisión potencial de dichas mediciones; – las etapas del proyecto en las que se pueden estimar las mediciones; y – las etapas del proyecto en las que se pueden realizar las mediciones. El grado en que es practicable cada requisito de prestaciones se analiza entonces a fin de obtener una lista de los mismos, criterios de éxito y mediciones potenciales. Los principales objetivos son: a) cada requisito de las prestaciones está asociado con al menos una medición; b) siempre que sea posible, se seleccionan mediciones precisas y eficientes que puedan ser utilizadas tan pronto como sea posible en el proceso de desarrollo; c) identificar los requisitos de las prestaciones esenciales y opcionales y sus criterios de éxito; y d) siempre que sea posible, se debe aprovechar la posibilidad de usar una misma medición para más de un requisito de las prestaciones.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 117 -

EN 50128:2011

D.41 Ensayos Probabilísticos Objetivo

Obtener una cifra cuantitativa sobre las propiedades de fiabilidad del software en estudio. Esta cifra puede incluir los niveles relativos de confianza y trascendencia y: a) una probabilidad de fallo por demanda; b) una probabilidad de fallo durante un cierto período de tiempo; y c) una probabilidad de contención de errores. A partir de estas cifras se pueden derivar otros parámetros como: – la probabilidad de ejecución libre de fallos; – la probabilidad de supervivencia; – la disponibilidad; – MTBF (media de tiempos de funcionamiento entre fallos) o la tasa de fallos; y – la probabilidad de ejecución segura. Descripción

Las consideraciones probabilísticas se basan en ensayos probabilísticos o en la experiencia de explotación. Normalmente, el número de casos de ensayo de los casos de explotación observados es muy grande. A fin de facilitar los ensayos, se usan normalmente ayudas automáticas. Su objetivo son los detalles de la provisión de datos de ensayo y la supervisión de los resultados de los ensayos. Los ensayos extensivos se ejecutan en grandes ordenadores con el contexto apropiado de simulación de procesos. Los datos de ensayo se seleccionan tanto desde el punto de vista sistemático como del aleatorio. El primer punto de vista tiene como objetivo el control global de los ensayos, por ejemplo, garantiza un perfil de datos de ensayo. La selección aleatoria considera los casos de ensayo individual en detalle. Los bancos de ensayo, las ejecuciones de ensayo y las supervisiones de ensayo se determinan individualmente a partir de los objetivos de ensayo detallados, como se describió anteriormente. Otras condiciones importantes se obtienen a partir de los prerrequisitos matemáticos que se habrán de satisfacer para permitir la evaluación del ensayo en función del objetivo previsto del ensayo. De la experiencia de explotación se pueden derivar también cifras probabilísticas sobre el comportamiento de cualquier objeto sometido a ensayo. Suponiendo que se cumplan las mismas condiciones, se pueden aplicar las mismas matemáticas que para evaluar los resultados de los ensayos. D.42 Simulación de Procesos Objetivo

Someter a ensayo las funciones de un software, junto con su interfaz con el mundo exterior, sin permitir que ello modifique el mundo real en forma alguna.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 118 -

Descripción

Se pretende crear un sistema, para propósitos de ensayo solamente, que imite el comportamiento del sistema a controlar por el sistema sometido a ensayo. La simulación puede ser únicamente de tipo software o una combinación de software y hardware. La simulación debe: – proporcionar al sistema sometido a ensayo todas las entradas que existirán cuando el sistema sea instalado; – responder a las salidas del sistema de una manera que represente fielmente al equipo controlado; – proporcionar las entradas del operador para tener en cuenta cualquier perturbación que deba gestionar el sistema sometido a ensayo. Cuando se somete el software a ensayo, la simulación puede ser la correspondiente al hardware objetivo con sus entradas y salidas. D.43 Prototipado/Animación Objetivo

Comprobar la viabilidad de implementar el sistema con las restricciones 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, restricciones y requisitos de prestaciones. Se construye un prototipo utilizando herramientas de alto nivel. En esta etapa, no es necesario considerar restricciones tales como el ordenador objetivo, el lenguaje de implementación, el tamaño del programa, la mantenibilidad, la fiabilidad y la disponibilidad. Se evalúa el prototipo teniendo en cuenta los criterios del cliente y a la luz de dicha evaluación pueden modificarse los requisitos del sistema. D.44 Bloque de Recuperación 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 misma 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, se acepta el resultado y pasa a las partes siguientes del sistema. Si falla, se eliminan todos los efectos secundarios de la primera sección y se ejecuta la segunda sección, 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. D.45 Tiempo de Respuesta y Limitaciones de Memoria Objetivo

Garantizar que el sistema cumplirá los requisitos temporales y de memoria.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 119 -

EN 50128:2011

Descripción

La especificación de requisitos del sistema y del software incluye requisitos de memoria y respuesta para funciones específicas, combinados quizá con restricciones en el uso de los recursos totales del sistema. Se realiza un análisis que deberá identificar las demandas de distribución en condiciones medias y en las más desfavorables. 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 del prototipado y evaluación de sistemas críticos en el tiempo. D.46 Mecanismos de Recuperación de Errores por Reintento Objetivo

Intentar la recuperación funcional desde una condición de error detectada mediante mecanismos de reintento. Descripción

Cuando se detecta un error o una condición de error 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 rearranque y reinicio o una pequeña tarea de reorganización y reinicio, después de que se haya agotado el tiempo de espera o por acción de un mecanismo de perro guardián para el software. Las técnicas de reintento se utilizan normalmente en la recuperación de errores o en errores de comunicación, y las condiciones de reintento pueden venir dadas por un error en el protocolo de comunicación (suma de verificación, etc.) o por una indicación de que se ha agotado el tiempo de espera de respuesta. D.47 Bolsa de Seguridad Objetivo

Proteger frente a errores 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 de garantizar que el ordenador principal ejecuta acciones seguras, aunque no necesariamente correctas. La bolsa de seguridad supervisa continuamente al ordenador principal. Mediante el uso de la bolsa de seguridad se 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. D.48 Gestión de la Configuración del Software Objetivo

La Gestión de la Configuración del Software trata de garantizar la coherencia de los grupos de software a entregar en función de las modificaciones en los mismos. La Gestión de la Configuración, en general, se aplica tanto al desarrollo del hardware como al desarrollo del software.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 120 -

Descripción

La Gestión de Configuración del Software es una técnica que se utiliza a lo largo del desarrollo. En esencia, requiere que se registre la producción de las versiones de cada parte 'significativa' a entregar y las relaciones entre las diferentes versiones de las diferentes partes a entregar. Los registros resultantes permiten determinar al diseñador el efecto de una modificación en una versión en otras versiones. En particular, pueden reconstruirse sistemas o subsistemas de forma fiable a partir de conjuntos coherentes de versiones de componentes. D.49 Lenguajes de Programación Fuertemente Tipados Objetivo

Reducir la probabilidad de errores 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 garantizar que se utiliza el tipo correcto. Estas comprobaciones se imponen para todo el programa, incluso si este se construye a partir de unidades compiladas de forma separada. Las comprobaciones garantizan también que el número y tipo de argumentos de los procedimientos concuerden, incluso cuando la referencia se hace desde componentes compilados de forma separada. Los lenguajes fuertemente tipados soportan también otros aspectos de la buena práctica en ingeniería software, tales 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. D.50 Ensayos Basados en la Estructura Objetivo

Aplicar ensayos en 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 someta a ensayo una gran parte de elementos del programa seleccionado. Los elementos de programa sometidos a ensayo pueden variar dependiendo del nivel de rigor requerido: – instrucciones: este es el ensayo menos riguroso ya que es posible ejecutar todas las instrucciones del código sin someter a ensayo a ambas ramas de una sentencia condicional; – ramas: deberían comprobarse los lados de las ramas. Esto puede ser poco práctico para algunos tipos de código defensivo; – Condiciones Compuestas: se somete a ensayo cada condición en una rama condicional compuesta (es decir, enlazada mediante AND/OR); – secuencia de código lineal y salto (LCSAJ, Linear Code Sequence And Jump): una secuencia de código lineal y salto es cualquier secuencia lineal de instrucciones de código, incluyendo saltos condicionales, terminada por un salto. Muchas subrutas potenciales serán impracticables debido a las restricciones impuestas sobre los datos de entrada por la ejecución del código previo;

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 121 -

EN 50128:2011

– flujo de datos: las rutas de ejecución se seleccionan sobre la base de uso de los datos, por ejemplo, una ruta en la que la misma variable es escrita y leída; – grafo de llamadas: un programa se compone de subrutinas que pueden ser invocadas desde otras subrutinas. El grafo 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; – ruta entera: ejecutar todas las rutas posibles a través del código. El ensayo completo es normalmente impracticable debido al gran número de rutas potenciales. D.51 Diagramas de Estructura Objetivo

Mostrar la estructura de un programa en forma de diagrama. Descripción

Los Diagramas de Estructura son una notación que complementa los Diagramas de Flujos 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 como una jerarquía de unidades de programa. Un diagrama 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: a) un rectángulo rotulado con el nombre de la unidad; b) una flecha conectando dichos rectángulos; c) una flecha dentro de un círculo, rotulada con el nombre de los datos pasados a y desde elementos en el diagrama de estructura. Normalmente, la flecha dentro del círculo se dibuja paralela a la flecha que conecta los rectángulos en el diagrama. 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 diagrama 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. D.52 Metodología Estructurada Objetivo

El principal objetivo de las Metodologías Estructuradas es promover la calidad del desarrollo del 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 (asistidos 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 metodologías, como SSADM y LBMS, están diseñadas para el tratamiento de datos tradicional y las funciones de procesamiento de transacciones, mientras que otras (MASCOT, JSD, Yourdon en tiempo real) están más orientadas al control de procesos y a aplicaciones en tiempo real (que tienden a ser más críticas en cuanto a seguridad).

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 122 -

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 pensamiento, dividiendo un gran problema en etapas manejables; – identificación del sistema total, 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. 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 la posibilidad de malentendidos, 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 comprobado intuitivamente por el usuario frente a sus propios conocimientos profundos del tema. D.53 Programación Estructurada Objetivo

Diseñar e implementar el componente software de forma que sea práctico el análisis del mismo. Este análisis debería poder revelar todos los comportamientos significativos del componente. Descripción

El componente software debería contener la mínima complejidad estructural. Deberían evitarse las ramificaciones complicadas. Las restricciones de los bucles y de las ramificaciones deberían estar (en la medida de lo posible) relacionadas de forma simple con los parámetros de entrada. El componente software debería dividirse en módulos adecuadamente pequeños y la interacción entre los mismos debería ser explícita. Deberían utilizarse preferentemente características del lenguaje de programación que favorezcan la aproximación anterior en lugar de otras que son (supuestamente) más eficientes, excepto cuando la eficiencia tiene prioridad absoluta (por ejemplo, algunos sistemas críticos de seguridad). D.54 Lenguajes de Programación Adecuados Objetivo

Satisfacer los requisitos de esta norma europea tanto como sea posible, en particular, la programación defensiva, el fuerte tipado, la programación estructurada y las aserciones. 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 a los problemas más que orientado a la máquina. Se prefieren los lenguajes ampliamente utilizados, o subconjuntos de los mismos, a lenguajes de propósitos específicos.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 123 -

EN 50128:2011

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 en tiempo de ejecución de los tipos y de los límites de las matrices; y – comprobación de parámetros. El lenguaje debería favorecer: – el uso de componentes pequeños y manejables; – la restricción de acceso a datos en componentes definidos; – definición de subrangos de variables; y – cualquier otro tipo de estructura que limite los errores. Es deseable que el lenguaje esté soportado por un traductor adecuado, librerías apropiadas de componentes preexistentes, un depurador y herramientas para el control de versiones y del desarrollo. Algunas características que hacen difícil la verificación y que por tanto deberían evitarse son: – saltos incondicionales, excluyendo las llamadas a subrutinas; – recursión; – punteros, zonas de memoria dinámica (heap) o cualquier tipo de variable u objeto dinámico; – gestión de interrupciones a nivel de código fuente; – entradas o salidas múltiples de bucles, bloques o subprogramas; – inicialización o declaración implícita de variables; – registros variables y equivalencia; y – parámetros de procedimiento. Los lenguajes de bajo nivel, en particular los de tipo ensamblador, presentan problemas debido a que están orientados a la máquina. D.55 Redes de Petri Temporizadas 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 teóricos de grafos que son adecuados para representar el flujo de información y control en sistemas que presentan concurrencia y comportamiento asíncrono.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 124 -

Una red de Petri está formada por lugares y transiciones. Los lugares pueden estar 'marcados' o 'no marcados'. Una transición está 'habilitada' cuando todos los lugares de entrada a la misma están marcados. Una vez habilitada, se permite (pero no se obliga) que se 'dispare'. Si se dispara, se eliminan las marcas de entrada y en su lugar se marca cada lugar de salida de la transición. Los peligros 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. D.56 Revisión del Proyecto Estructurado/Revisión del Diseño Objetivo

Detectar errores en algún producto del proceso de desarrollo tan pronto y tan económicamente como sea posible. Descripción

El Comité Técnico TC 56 de IEC ha publicado una Guía de Revisiones Formales de Diseño, 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 IEC proporciona también pautas generales para la planificación y realización de las revisiones formales de diseño, así como detalles específicos relativos al papel de especialistas independientes dentro de un equipo de revisión de diseño. IEC recomienda que "se debe realizar una revisión formal de diseño 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 de establecer el coste, y otras características que influyan en el producto/proceso final, usuarios o espectadores". La revisión del código consiste en un equipo de revisión que selecciona un pequeño conjunto de casos de ensayo, conjuntos representativos de entradas y las correspondientes salidas esperadas del programa. Se siguen entonces los datos de ensayo manualmente a través de la lógica del programa. D.57 Programación Orientada a Objetos Objetivo

Permitir un prototipado rápido, 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.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 125 -

EN 50128:2011

Clase de Objeto: mediante la especificación de la clase de 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): una clase de 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 clases de objeto. Polimorfismo: La misma operación se puede comportar de forma diferente en diferentes clases de objeto, por ejemplo, la operación de escritura sobre un objeto pantalla escribe caracteres en ese objeto pantalla y la operación de escritura sobre un objeto archivo escribe caracteres en ese archivo. Inconveniente: Los lenguajes de programación orientada a objetos pueden conducir a una necesidad de recursos adicionales con un impacto negativo en las prestaciones del sistema. D.58 Trazabilidad Objetivo

El objetivo de la Trazabilidad es garantizar que se puede demostrar que se han cumplido todos los requisitos de forma adecuada y que no se ha introducido material no trazable. Descripción

La trazabilidad de los requisitos debe ser una de las consideraciones importantes a tener en cuenta para la validación de un sistema y se deben proporcionar los medios que permitan demostrarla durante todas las fases del ciclo de vida. La trazabilidad se debe considerar aplicable tanto a los requisitos funcionales como a los no funcionales y debe considerar en particular: a) la trazabilidad de los requisitos con respecto al diseño u otros objetos que los satisfagan; b) la trazabilidad de los objetos de diseño hasta los objetos de implementación que los instancien; c) la trazabilidad de los requisitos y objetos de diseño hasta los objetos operacionales y de mantenimiento que requieren ser aplicados para un uso adecuado y seguro del sistema; d) la trazabilidad de los objetos de requisitos, de diseño, de implementación, de funcionamiento y de mantenimiento hasta los planes de verificación y de ensayos y hasta las especificaciones que determinen su aceptación; e) la trazabilidad de los planes de verificación y de ensayos y de las especificaciones hasta el ensayo u otros informes que registren los resultados de su aplicación. Cuando los objetos de requisitos, de diseño u otros se instancian como un número de documentos separados, se debe mantener la trazabilidad dentro de la estructura del documento y de forma jerárquica. La salida del proceso de Trazabilidad debe ser el sujeto de la Gestión de Configuración formal. D.59 Metaprogramación Objetivo

La metaprogramación permite a los programadores hacer más cantidad de trabajo en el mismo plazo de tiempo que tardarían en escribir el código de forma manual.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 126 -

Descripción

La metaprogramación consiste en la escritura de programas de ordenador que escriben o manipulan a otros programas (o a ellos mismos) como sus datos o que realizan parte del trabajo durante el tiempo de compilación que de otra forma se haría en tiempo de ejecución. El lenguaje en el que se escribe el metaprograma se conoce como metalenguaje. El lenguaje de los programas manipulados se conoce como lenguaje objeto. La capacidad de un lenguaje de programación para ser su propio metalenguaje se conoce como reflexión o reflexividad. La reflexión es una característica valiosa del lenguaje para facilitar la metaprogramación. Es muy útil tener el lenguaje de programación mismo como un tipo de datos de primera clase (como en Lisp). La programación genérica invoca un medio de metaprogramación dentro de un lenguaje, en los lenguajes que lo soportan. La metaprogramación normalmente funciona de una de las siguientes dos formas. La primera es exponer las partes internas del motor de ejecución al código de programación a través de las interfaces de programación de aplicaciones (las API). El segundo enfoque es la ejecución dinámica de expresiones de cadenas que contienen comandos de programación. Por tanto, "los programas pueden escribir programas". Aunque se pueden utilizar ambos enfoques, la mayoría de los lenguajes tiende a inclinarse por uno o por el otro. D.60 Programación por procedimientos Objetivo

Especificar las etapas que el programa debe seguir para alcanzar su estado deseado. Descripción

La programación por procedimientos se basa en el concepto de la llamada de procedimiento. Los procedimientos, también conocidos como rutinas, subrutinas, métodos, o funciones (similares éstas últimas a las usadas en la programación funcional, no se deben confundir con las funciones matemáticas) contienen simplemente una serie de etapas de cálculos a realizar. Todo procedimiento es susceptible de ser llamado en cualquier momento por otros procedimientos o por sí mismo durante la ejecución de un programa. D.61 Diagramas Secuenciales de Función (SFC, Sequential Function Charts) Objetivo

Describir algoritmos de programa mediante diagramas. Descripción

Los elementos de los SFC permiten la partición de una unidad de algoritmos de aplicación en una serie de etapas y de transiciones interconectadas mediante enlaces orientados. A cada etapa se asocia un conjunto de acciones y a cada transición se asocia una condición de transición. Ya que los elementos de los SFC requieren el almacenamiento de informaciones de estado, las únicas unidades de algoritmos de aplicación que se pueden estructurar usando estos elementos son los bloques funcionales. Véase el apartado 2.6 de la Norma EN 61131-3:2003.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 127 -

EN 50128:2011

D.62 Diagrama Ladder o en Escalera Objetivo

Describir un programa mediante diagramas. Descripción

Véase el apartado 4.2 de la Norma EN 61131-3:2003. D.63 Diagramas de Bloques Funcionales Objetivo

Describir una función entre variables de entrada y variables de salida mediante diagramas. Descripción

Véase el apartado 4.3 de la Norma EN 61131-3:2003. D.64 Diagrama de Estados Objetivo

Describir el comportamiento de un sistema mediante diagramas. Descripción

Los Diagramas de Estado se utilizan para describir el comportamiento de un sistema. Los diagramas de estados pueden describir los posibles estados de un objeto a medida que los eventos se producen. Cada diagrama representa normalmente objetos de una sola clase y sigue los diferentes estados de sus objetos dentro del sistema. El diagrama de estados puede usarse para representar gráficamente máquinas de estados finitos. Fue Taylor Booth quien introdujo esta idea en su libro de 1967 "Sequential Machines and Automata Theory". Otra representación posible es la tabla de Transición de Estados. Una forma clásica de diagrama de estados para una máquina de estados finitos es un grafo orientado. D.65 Modelado de datos Objetivo

Crear un modelo de datos. Descripción

En informática se llama modelado de datos al proceso de creación de un modelo de datos mediante la aplicación de descripciones de modelos de datos formales utilizando las técnicas de modelado de datos. En ingeniería del software, un modelo de datos es un modelo abstracto que describe los modos de representación y acceso a los datos. Los modelos de datos definen formalmente objetos de datos y las relaciones entre los objetos de datos para un ámbito de interés determinado. Algunas aplicaciones típicas de modelos de bases de datos incluyen soportar el desarrollo de bases de datos y permitir el intercambio de datos para un ámbito de interés determinado. Los modelos de datos se especifican en un lenguaje de modelado de datos.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 128 -

D.66 Diagramas de Flujo de Control/Grafo de Flujo de Control Objetivo

Describir el comportamiento de un sistema mediante diagramas Descripción

En informática, un diagrama de flujo de control o un grafo de flujo de control (CFG, Control Flow Graph) representa, utilizando la notación gráfica, todas las rutas que podría recorrer un programa durante su ejecución. Cada nodo en el grafo representa un bloque básico, es decir, un elemento de código lineal sin saltos o sin destinos de salto; los destinos de salto empiezan un bloque, y los saltos terminan un bloque. Se utilizan arcos orientados para representar saltos en el flujo de control. En la mayoría de las presentaciones existen dos bloques especialmente denominados: el bloque de entrada, por medio del cual el control entra en el grafo de flujo y el bloque de salida, por medio del cual salen todos los flujos de control. El CFG es esencial para muchas optimizaciones del compilador y herramientas de análisis estático. La accesibilidad es otra propiedad de los grafos que es útil en la optimización. Si un bloque/subgrafo no está unido al subgrafo que contiene el bloque de entrada, dicho bloque es inaccesible durante cualquier ejecución, y se trata por tanto de código inaccesible; se puede eliminar con total seguridad. Si el bloque de salida es inaccesible desde el bloque de entrada, indica un bucle infinito. De nuevo, los códigos muertos y los lazos infinitos son posibles incluso si el programador no ha codificado explícitamente en ese sentido: las optimizaciones como la propagación de constantes (constant propagation) y la reducción de constantes (constant folding) seguidas de hilados de saltos (jump threading) podrían reunir varios bloques básicos en uno solo, provocar la eliminación de arcos de un CFG, etc., y probablemente desunir partes del grafo. Terminología

Normalmente se utilizan estos términos en las discusiones relativas a los grafos de flujo de control. bloque de entrada bloque a través del cual todos los flujos de control entran al grafo. bloque de salida bloque a través del cual todos los flujos de control salen del grafo. arco de retorno arco que apunta a un antecesor en una transversal de primer nivel (DFS, depth first) del grafo. arco crítico arco que no es ni el único arco que sale de su bloque fuente, ni el único arco que entra en el bloque destino. Estos arcos deberían dividirse (se debería crear un nuevo bloque en medio del arco) para insertar cálculos en el arco. arco anormal arco cuyo destino se desconoce. Estos arcos tienden a impedir la optimización. Los elementos de tratamiento de las excepciones pueden producirlos. arco imposible (también llamado arco falso) arco que se ha añadido al grafo únicamente para preservar la propiedad de que el bloque de salida postdomina sobre todos los bloques. No se puede atravesar nunca. dominador el bloque M domina al bloque N si cada ruta que parte de la entrada que llega al bloque N tiene que pasar por el bloque M. El bloque de entrada domina a todos los bloques.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 129 -

EN 50128:2011

postdominador el bloque M postdomina al bloque N si cada ruta desde N a la salida tiene que pasar por el bloque M. El bloque de salida postdomina a todos los bloques. dominador inmediato el bloque M domina inmediatamente al bloque N si M domina a N y si no interviene ningún bloque P de forma que M domine a P y P domine a N. Dicho de otra manera, M es el último dominador en cualquier ruta desde la entrada hasta N. De tenerlo, cada bloque solo tiene un único dominador inmediato. postdominador inmediato análogo al dominador inmediato. árbol dominador estructura auxiliar de datos que describe las relaciones del dominador. Hay un arco desde el Bloque M al Bloque N si M es dominador inmediato de N. Este grafo es un árbol, ya que cada bloque tiene un único dominador inmediato. Este árbol tiene su raíz en el bloque de entrada. árbol postdominador análogo al árbol dominador. Este árbol tiene su raíz en el bloque de salida. encabezamiento de un bucle también llamado punto de entrada del bucle, es un dominador que es el objetivo de un arco de retorno que forma un bucle. Domina todos los bloques en el cuerpo del bucle. preencabezamiento de un bucle supongamos que el bloque M es un dominador con varios arcos entrantes, siendo algunos de ellos arcos de retorno (así que M es un encabezamiento de bucle). Sería una ventaja para varios pases de optimización romper M en dos bloques Mpre y Mloop. El contenido de M y de los arcos de retorno se desplaza a Mloop, y se desplazan el resto de los arcos para que se dirijan a Mpre, y se inserta un nuevo arco que vaya desde Mpre hasta Mloop (así Mpre es el dominador inmediato de Mloop). Al principio, Mpre estaría vacío, pero los pases como los movimientos de código invariante de bucle pueden llenarlo. A Mpre se le llama preencabezamiento de bucle, y a Mloop encabezamiento de bucle. D.67 Diagrama de secuencia Objetivo

Describir la interacción entre procesos o componentes mediante diagramas. Descripción

Un diagrama de secuencia es un tipo de diagrama de interacción, que muestra cómo funcionan los procesos o los componentes entre ellos y en qué orden. D.68 Métodos de Especificación en Tablas Objetivo

El objetivo es disponer de un medio normalizado y bien estructurado que sirva para definir las funciones de un sistema controlado por datos. Descripción

Las notaciones en tablas, como las tablas de control de la señalización, constituyen un método bien establecido de documentación de los requisitos específicos en una instalación para un sistema de señalización ferroviario.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 130 -

La técnica es adecuada cuando los tipos de relaciones entre los elementos del sistema estén normalizados. Ventaja: El formato de la tabla y las posibles entradas en cada campo pueden servir de lista de comprobación durante la verificación. D.69 Lenguaje específico para la aplicación Objetivo

El objetivo es disponer de un medio que sirva para especificar la funcionalidad de un sistema controlado por datos usando conceptos y terminología que los ingenieros de aplicaciones que no estén familiarizados con los lenguajes de programación convencionales puedan asimilar fácilmente. Descripción

Un lenguaje específico para la aplicación normalmente combina construcciones de control similares a los lenguajes de programación convencionales de alto nivel con operadores que son específicos para el tipo de sistema. La técnica es adecuada cuando sea necesario especificar decisiones booleanas, pero se puede aplicar también en cualquier otro caso. Ventaja: La flexibilidad, ya que permite producir datos para circunstancias no habituales que no se previeron cuando se diseñó el sistema inicialmente. D.70 UML Lenguaje Unificado de Modelado Objetivo

Representar programas de software y elementos relacionados de manera que permita la reducción de la complejidad por medio de la abstracción. Permitiendo el modelado de un diseño existente o previsto en función de una amplia variedad de tipos de diagramas, el lenguaje UML facilita la evaluación de las características clave del diseño en base a las representaciones a los niveles de detalle apropiados. El lenguaje UML se utiliza normalmente en los llamados desarrollos orientados a modelos, soportados por productos comerciales. Este estilo de desarrollo tiene como objeto mejorar la calidad del software y la productividad de los desarrolladores mediante la utilización de lenguajes de modelado de alto nivel. Descripción

El lenguaje UML es un lenguaje de modelado polivalente normalizado, que surgió de la utilización de lenguajes de especificación de software orientados gráficamente y lenguajes de programación orientados a objetos. Apoyándose en esta tradición, el lenguaje UML reutiliza muchos de los conceptos y métodos de sus predecesores. Los modelos se escriben en términos de uno o más tipos de diagramas, clasificados como diagramas de estructura y como diagramas de comportamiento, constando el último además de cuatro tipos de diagramas clasificados como diagramas de interacción. Diagramas de estructura •

Diagrama de paquetes: Muestran los contenidos y las relaciones entre diferentes paquetes, cada uno conteniendo elementos de modelo relacionados.

•

Diagramas de clases: Especifican tipos de objetos con sus diferentes características y sus relaciones con otros tipos de objetos sobre la base de una adaptación de diagramas tradicionales entidad-relación.

•

Diagramas de objetos: Muestran cómo diferentes objetos (instancias de clases) están relacionados entre sí.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

- 131 -

EN 50128:2011

•

Diagramas de estructuras compuestas: Muestran la estructura interna de un clasificador (como una clase o un componente) y sus puntos de interacción con otras partes del sistema.

•

Diagramas de componentes: Muestran los componentes que componen el sistema, sus interrelaciones, interacciones e interfaces externas.

•

Diagramas de despliegue: Especifican cómo se distribuye el software a través de la plataforma de ejecución.

Diagramas de comportamiento •

Diagramas de actividades: Describen comportamientos algorítmicos, usando una adaptación de los diagramas de flujo tradicionales que permiten el modelado de las transferencias de datos y la ejecución concurrente.

•

Diagramas de máquinas de estado: Describen comportamientos dirigidos por eventos por medio de máquinas de estados finitos (diagramas de estados).

•

Diagramas de casos de uso: Modelizan actores que interactúan con el sistema para garantizar casos de uso específicos.

•

Diagramas de interacción (diagramas de comunicación, diagramas globales de interacciones, diagramas de secuencia, diagramas de tiempos): Describen los escenarios que comprenden las actividades realizadas por objetos en comunicación.

Mientras que el lenguaje UML es un lenguaje de modelado genérico, las interpretaciones específicas de dominio son posibles por medio de perfiles. Refinando los conceptos del lenguaje UML normalizado, los perfiles permiten realizar dichas interpretaciones utilizando las extensiones definidas en el perfil. De esta forma, el lenguaje UML se utiliza como base para la definición de lenguajes específicos de dominio. D.71 Lenguajes específicos de dominio Objetivo

Representar programas de software y elementos relacionados en un lenguaje adaptado a un dominio particular. Descripción

Un lenguaje específico de dominio (DSL, Domain Specific Language) es un lenguaje de programación, especificación o modelado creado específicamente para resolver problemas en un dominio de aplicación particular o en un dominio de problemas particular, o con una técnica particular. El lenguaje se basa en conceptos y en características aplicables a este dominio. Los lenguajes específicos de dominio se conocen también como lenguajes de propósito específico, en contraste con los lenguajes de programación de propósito general o con los lenguajes de modelado como el lenguaje Java y el lenguaje LUM. Uno de los beneficios importantes de los lenguajes específicos de dominio es la posibilidad de representar y solucionar problemas dentro de un dominio particular sin necesidad de poseer conocimientos sobre la programación, especificación o modelado general. Como resultado, los programas, especificaciones o modelos pueden producirse a un nivel más alto, como a nivel del usuario final. Al disponer de construcciones adaptadas a este dominio, y probablemente de medios para la generación automática de códigos, normalmente un lenguaje DSL aumenta también la productividad del programador y la calidad del producto resultante. La creación de códigos se implementa normalmente en forma de un generador de aplicación usando el lenguaje DSL como entrada.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

EN 50128:2011

- 132 -

BIBLIOGRAFÍA

EN 50159, Railway applications. Communication, signalling and processing systems. Safety-related communication in transmission systems. EN 61131-3:2003, Programmable controllers. Part 3: Programming languages. (IEC 61131-3:2003). EN 61158-2:2010, Industrial communication networks. Fieldbus specifications. Part 2: Physical layer specification and service definition. (IEC 61158-2:2010).

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

Génova, 6 28004 MADRID-España

[email protected] www.aenor.es

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VOSSLOH ESPAÑA, S.A.

Tel.: 902 102 201 Fax: 913 104 032