AGC Loop

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.

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.

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.

7.3.4.15 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.

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,

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

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;

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

In document A digital neuromorphic auditory pathway (Page 45-51)