7 “What” Pathway Experiment: Unsupervised Feature Extraction
7.2 Event-based Unsupervised Feature Extraction
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
10. Uso limitado de Variables Globales D.38 HR HR HR M M
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.
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.
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 10. Lista de Instrucciones D.54 R R R R R 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
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
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.
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.
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
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
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
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
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
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