Estándares

Estándares aeronáuticos

alfabeto radiofónico es un lenguaje de desambiguación alfabética utilizado internacionalmente enradiocomunicaciones de transmisión de voz en la marina y la aviación, tanto por los servicios civiles como militares. Fue establecido por la Organización de Aviación Civil Internacional (OACI, ICAO en inglés), agencia de la ONUcreada en 1944. También es conocido como Interco y como alfabeto fonético OACI.

El alfabeto de deletreo se encuentra regulado por el Apéndice S14 "Cuadro para el deletreo de letras y cifras"¹ delReglamento de radiocomunicaciones de la UIT y en el capitulo 5 "Servicio Móvil Aeronáutico — comunicaciones orales" del volumen II del Anexo 10 a la convención de Chicago sobre Telecomunicaciones aeronáuticas, listado en la figura 5-1 "Alfabeto de deletreo para radiotelefonía".

Es un sistema creado para poder dar mayor certeza a las radiocomunicaciones aeronáuticas. Su empleo es clave para deletrear códigos, como pueden ser el número de identificación de un contenedor de carga, de una aeronave o similares.

Origen

Se utiliza para transmitir por vía oral cualquier tipo de información, pero principalmente cuando se trata de números o términos en los que es vital su correcta escritura y entendimiento, a pesar de ambigüedades o dificultades idiomáticas.

En muchos idiomas existen letras y números homófonos; es el caso del idioma inglés, en donde el número «cero» y la letra «o» suelen denominarse «o» indistintamente, o el caso del español, en donde la letra «c» y «k» pueden tener la misma pronunciación. Otro problema que lleva al uso del alfabeto fonético aeronáutico es la transmisión de nombres o palabras extranjeras, por ejemplo «Tsiolkovsky», o números que, con la interferencia y ruido al que están sujetas las comunicaciones por radio, pueden ser confundidos, como es el caso de «sesenta y siete» y «setenta y siete».

Por medio de un acuerdo internacional entre los países miembros de OACI se decidió crear un alfabeto fonético para uso universal en radiotransmisiones internacionales que está basado en el abecedario inglés (idioma acordado para uso aeronáutico internacional) que tomara el lugar de los alfabetos fonéticos existentes hasta esas fechas. Además de ser utilizado en transmisiones aeronáuticas reguladas por OACI (civiles), se emplea en transmisiones de carácter militar y es el alfabeto estándar de la OTAN y radioaficionados de todo el mundo.

Historia

Es interesante hacer notar que el primer alfabeto fonético reconocido internacionalmente fue adoptado por la Conferencia Radial de la Unión Internacional de Telecomunicaciones (UIT) en 1927 y fue para el uso del servicio móvil marítimo; dicho alfabeto asignaba palabras clave a cada letra del alfabeto (por ejemplo Alfa para la A, Bravo para la B, etc.), de manera que las combinaciones críticas de letras (y números) pudieran ser pronunciadas y entendidas por los que emitían y recibían mensajes de voz por radio o teléfono sin importar cuál fuera su idioma nativo, en especial cuando se ponía en juego la seguridad de las personas. El resultado de esa experiencia resultó en varios cambios hechos en la Conferencia Radial de la UIT de 1932. El alfabeto resultante fue adoptado por la Comisión Internacional de Aeronavegación (ICAN, por sus siglas en inglés), la predecesora de la ICAO, y fue utilizado en la aviación civil hasta la Segunda Guerra Mundial.²

Durante la Segunda Guerra Mundial surgió un nuevo alfabeto para uso de los Aliados que llevó a posteriores confusiones y revisiones sucesivas, hasta que el 1º de marzo de 1956 la ICAO implementó la revisión final que fue luego aceptada por otras organizaciones como la OTAN y la OMI (Organización Marítima Internacional) hasta ser conocido internacionalmente como el «Alfabeto Internacional de Deletreo Radiotelefónico» (International Radiotelephony Spelling Alphabet, en inglés).

Método de uso

Este alfabeto funciona asignando una palabra a cada letra, como se muestra en los ejemplos siguientes:

• N334AA «November Three Three Four Alfa Alfa» para la matrícula de una aeronave.

Cuando se utiliza este sistema en otros idiomas se permite en su uso local traducir los números, con lo que el ejemplo anterior sería:

• «Noviembre, Tres, Tres, Cuatro, Alfa, Alfa».

También se permite, con la finalidad de hacer más breves las transmisiones, indicar que una letra o número se repite, con lo que el ejemplo quedaría así:

• «Noviembre, doble Tres, Cuatro, doble Alfa»

Otro ejemplo: 1700 000123 se trasmitiría como «Uno Siete quíntuple Cero Uno Dos Tres».

El uso de las centenas y de los millares se realizaría del siguiente modo:

• 800, «Eight Hundred» para decir ochocientos.
• 3 000, «Three Thousand» para decir tres mil.
• 4 600, «Four Thousand Six Hundred» para decir cuatro mil seiscientos.
• 12 000, «One Two Thousand» para decir doce mil.

En inglés, el separador decimal es el punto «.» y se lee como «decimal». De este modo, utilizando el alfabeto fonético:

• 118.15: «One One Eight Decimal One Five» para dicha frecuencia de radio (en castellano: Uno Uno Ocho Decimal Uno Cinco).

La asignación de palabras se basó en palabras comunes en inglés (a la fecha en que fueron asignadas) que usaran dichas letras; con los años y el desuso de algunas de estas palabras, se ha vuelto relativamente común la utilización de otras, aun cuando no están reconocidas por OACI.

Lima Quebec en la cola de un planeador.

Caracter	Palabra	Pronunciación en inglés (unos de varios)	Pronunciación aproximada en español
A	Alfa	Al fah	Alfa
B	Bravo	Bra voh	Bravo
C	Charlie	Char li, Shah lee	Chali / Charli
D	Delta	Dell tah	Delta
E	Echo	Eck oh	Eco
F	Foxtrot	Foks trot	Fócstrot / Fácstrat
G	Golf	Golf	Golf
H	Hotel	Hou tell	Joutel
I	India	In di ah	Índia
J	Juliet	Yu li ett	Yuliét
K	Kilo	Ki loh	Kilo
L	Lima	Li mah	Lima
M	Mike	Maik	Maic
N	November	Nou vem ber	Nouvember
Ñ	Ñoño	(no tiene, solo es para el español)	Ñoño
O	Oscar	Oss car	Óscar
P	Papa	Pah pah	Papa
Q	Quebec	Ke beck	Quebéc
R	Romeo	Rou me oh	Rómeo
S	Sierra	Si e rah	Sierra
T	Tango	Tang gou	Tango
U	Uniform	IU ni form	Yúnifom
V	Victor	Vik tor	Victor
W	Whiskey	Wiss key	Uisqui
X	X-ray	Ecks rey	Ecs-rey
Y	Yankee	Yan key	Yanqui
Z	Zulu	Zu lu	Sulu
1	One	Uan	Uan
2	Two	TU	Chu
3	Three	Thri	Zri
4	Four	For	Fóa / For
5	Five	Faiv	Fáif
6	Six	Six	Sics
7	Seven	Seven	Seven
8	Eight	Eit	Eit
9	Nine	Nain	Nain
0	Zero	Zero	Dsero / Dziro
100	Hundred	Hun dred	Jándred
1000	Thousand	Tow sand	Záusand
.	Decimal	Day see mal	Déisimal
.	Stop	Stop	Stop / Stap (NO: "estop", sin pronunciar la e)

ARINC 429 (Aeronautical Radio Inc.¹ ) es un estándar que determina las características que se precisan para llevar a cabo intercambios de datos dentro de muchos sistemas de aviónica de aeronaves comerciales y de transporte. ARINC 429 es el bus de datos predominante en aviónica.² Define las interfaces físicas y eléctricas para una comunicación unidireccional (mediante 2 hilos independientes), además de un protocolo de datos para dar soporte a una red local aviónica en un avión.

Básicamente describe las funciones de los medios de información digitales que se encuentran en las aeronaves.

Descripción técnica

ARINC 429 es una especificación técnica de buses utilizada para definir buses dentro de la aviónica usada en aeronaves. Define un bus unidireccional compuesto por 2 hilos unidireccionales de datos estándar (puertos Tx y Rx). Ese estándar de datos es conocido como DITS (Digital Information Transfer System o sistema de transferencia de información digital Marca 33).

Sus principales características técnicas son:

• La transmisión se realiza en serie, en palabras de 32 bits más un tiempo muerto denominado “gap” y mediante un par de cables trenzados y apantallados en lazo abierto “open loop”.

• La fuente y el destino deben estar conectados mediante un par de cables trenzados y apantallados. El apantallamiento debe conectarse a masa en ambos lados de la conexión y en todos los conectores intermedios del cableado.

• Los mensajes se transmiten de 12,5 a 100 kbit/s³ a otros elementos del sistema de vigilancia que son el bus de mensajes. Las características del mensaje son:
  • La información fluye desde una puerta de transmisión hasta una o varias puertas de recepción.
  • En ningún caso la información puede llegar hasta una puerta destinada a la transmisión.
  • La transmisión entre 2 computadores en ambos sentidos se realiza por buses independientes.

• El transmisor siempre transmite, ya sea 32 bits de datos (palabra) o el estado nulo.

• Un bus (cable de par) se limita a un transmisor y no más de 20 receptores.

• El protocolo permite función auto-reloj en el receptor final, eliminando así la necesidad de transmitir la hora en los datos que existían en anteriores protocolos como ARINC-568 (6 hilos).

• Características de velocidad:
  • Transmisión en alta velocidad 100 Kilobites/s
  • Transmisión en baja velocidad 12 a 14,5 kilobites/s
  • No se pueden utilizar ambas velocidades en el mismo bus.

Formato de Palabras de datos

En ARINC 429 cada palabra está formada por 32 bits y contiene 5 campos:

• El bit 32 es el bit de paridad y se utiliza para verificar que la palabra no fue dañada durante la transmisión o que es ilegible.

• Los bits 30 y 31 forman la matriz de Señal/Estado, o SSM, y con frecuencia indican si la palabra es válida. Los valores posibles son:
  • OP (operacional). Indica que los datos de esta palabra se consideran correctos.
  • TEST. Indica que los datos son proporcionados por una fuente de prueba.
  • FAIL. Indica un error de hardware que ha causado pérdida de datos.
  • NCD (no hay datos computados). Indica que faltan datos o que son inexactos, debido a alguna razón que no está vinculada al hardware. Por ejemplo, los comandos del piloto automático se muestran como NCD cuando el piloto automático no está activado.
  • La SSM puede indicar también el signo (+/-) de los datos (por ejemplo usada en altura) o información relacionada, como la orientación (Norte / Sur / Este / Oeste).

• Los bits del 11 al 29 contendrán los datos. Dichos datos se encuentran codificados en sistema BCD o el BNR. Estas son las codificaciones comunes en ARINC 429. También se pueden utilizar formatos de datos mixtos.

• Los bits 9 y 10 son los Identificadores de Origen/Destino (SDI) e indican a que receptor van dirigidos los datos o, con mayor frecuencia, cual es el subsistema de transmisión de datos.
• Los bits del 1 a 8 contienen una etiqueta, expresada en octal, identificando el tipo de datos.

Etiquetas

Las directrices para crear etiquetas también se proporcionan como parte de la especificación ARINC 429 para diversos tipos de equipo.

Cada aeronave contendrá diferentes sistemas electrónicos, tales como los ordenadores de gestión de vuelo, sistemas de referencia inerciales, las computadoras de datos aéreos, radio altímetros, radios, GPS y sensores. Para cada tipo de equipo se define un conjunto de parámetros estándar que es común a todos los fabricantes y modelos. Por ejemplo, cualquier computadora de datos aéreos proporcionará la altura barométrica de la aeronave según la etiqueta 204. Esto permite cierto grado de intercambiabilidad de piezas, gracias a que las computadoras de datos aéreos se comportan, en su mayor parte, de la misma manera.

Debido a que hay un número limitado de etiquetas, es posible que una misma etiqueta tenga efectos diferentes según su uso. Por ejemplo, la 204 puede ser enviada a un sensor GPS o a otro tipo de sensor. En las aeronaves, incluso hay muchos parámetros comunes que utilizar la misma etiqueta, independientemente de la fuente.

Además de todo esto, como con cualquier especificación, cada fabricante tiene ligeras diferencias a partir de la especificación formal; por ejemplo, proporcionando datos adicionales, más allá de la especificación, dejando de lado algunos datos recomendados por el pliego de condiciones u otros cambios.

Protección contra la interferencia

La prohibición sobre el uso de determinados dispositivos electrónicos en vuelo de aviones comerciales se ha convertido en una cuestión controvertida, ya que, aunque normalmente se justifica como un requisito de seguridad para evitar la interferencia con la aviónica de la aeronave, es criticado por aquellos que argumentan que los teléfonos móviles, WiFi, Bluetooth, y otros sistemas de radiocomunicación digital son capaces de interferir con los protocolos robustos tales como ARINC.

Las distorsiones se pueden producir por:

• Características de los cables.
• Errores eléctricos.
• Ruido de interferencias eléctricas.

ARINC 429 emplea varios métodos protocolizados tanto físicos como eléctricos, para reducir al mínimo las interferencias electromagnéticas causadas a bordo por elementos de radio y por otros cables de transmisión.

El cableado es par trenzado blindado de 78Ω.¹ Las señales ARINC introducen un diferencial de 15V entre dato y dato para transmisión bifásica (por ejemplo 5V para el primer dato y –10V para el siguiente) y la especificación define límites de subidas y bajadas de tensión aceptables.

Los niveles de voltaje del transmisor son: +5V, 0V y ‐5V cada conductor con respecto a tierra; +10V, 0V y ‐10V entre el conductor A y el B.

Para la señal en el receptor se utiliza modulación bipolar RZ (retorno a cero) con 3 estados (“HI”, “NULL” y “LO” entre el cable A y el B), reduciendo aún más las emisiones de ruido EMI producidas por el mismo cable. Esos 3 estados tienen los siguientes rangos de voltaje:

• HI dentro del rango +7,5V a +11V
• NULL dentro del rango +0,5V a ‐0,5V
• LO dentro del rango ‐7,5V a ‐11V

A pesar de todo ello, si uno de los lados de la línea de transmisión se encuentra en circuito abierto o en corto, se debilita la inmunidad contra el ruido, lo que puede producir un fallo intermitente.

El diccionario Aerocriptográfico Aresti es el estándar usado por Federación Aeronáutica Internacional para identificar las figuras acrobáticas en las competiciones de acrobacia aérea. En el catálogo, diseñado por el coronel aviador españolJosé Luis Aresti Aguirre (1919-2003), cada figura está representada por líneas, flechas, formas geométricas y números que representan la forma precisa de una maniobra a volar.

Familias Catálogo CIVA

El catálogo clasifica las maniobras en diferentes familias. Las familias del 1 al 8 representan figuras básicas, tales como giros, rizos y líneas verticales; la familia 9 representa los elementos de rotación que se pueden añadir a las cifras de base para aumentar la dificultad, cambiar la dirección de vuelo o invertir las cargas g sobre la aeronave.

Familia	Descripción
1	Líneas y ángulos – Líneas horizontales, líneas 45 y variaciones de líneas verticales
2	Virajes y ruedas de toneles 90-360 positivo y negativo, con opción de toneles
3	Combinaciones de líneas – más de la familia 1
4	Barrenas (No en uso)
5	Caídas de ala – con 4 posibles variaciones
6	Resbales de cola – con 8 posibles variaciones
7	Loops y Ochos – Loops redondos/cuadrados/octagonales, “S” y 8’s
8	Combinaciones de líneas, ángulos y loops, Humpty bumps, cubanos y variaciones
9	Toneles lentos, 2-puntos, 4-puntos, 8-puntos, rápidos y barrenas

Números del catálogo y coeficientes de dificultad K

Todas las figuras básicas de las Familias del 1 al 8 son definidas de acuerdo a un sistema de tres números. El primer número indica la Familia a la cual la figura pertenece. El segundo número muestra la fila, y el tercer número la columna, en la cual la figura está situada. Los números están separados por puntos.

Cada figura básica y elemento rotatorio en el catálogo tiene asignado un coeficiente de dificultad, factor K. Para las familias 1 al 8, el coeficiente son mostrados dentro de un círculo al lado de la figura. Además, en las figuras de estas familias, la figura se fragmenta en varios tramos asignándole a cada tramo un coeficiente. Para la familia 9 son mostrados de forma tabular.

Cuando una figura básica o uno o más elementos complementarios son combinados para formar una figura compleja, el facotr total K para la figura es la suma de los coeficientes de dificultad de las partes individuales.

Excepto para la Familia 9, todos los valores son divididos por 10 y redondeados si sale un decimal.

La suma total K de las maniobras que existen en un programa acrobático, se le llama K totales de la secuencia. Este valor, indica el grado de dificultad total del programa y es directamente proporcional al número de figuras. Pero, si por ejemplo, dos programas A y B tienen un valor total de K=300 y A tiene un total de 9 figuras y B de 15, esto quiere decir que el programa A tiene maniobras más complejas y por lo tanto más difíciles de realizar que las del programa B.

Como referencia, un programa acrobático para principiantes puede tener escasamente 70k's totales mientras uno de ilimitado puede sobrepasar tranquilamente los 400k.

En el diseño de un programa libre, que lo realiza cada piloto, la normativa establece un máximo número de K’s y de figuras en función de la categoría en la que el piloto vaya a volar, con lo que se procura obtener el valor máximo de K con las máximas figuras posibles para bajar la dificultad del vuelo y así obtener la máxima puntuación.¹

Lista de figuras

A continuación se detallan las principales figuras acrobáticas y su notación Aresti.

Figura	Notación Aresti
Subida a 45º
Subida vertical o trepada
Rizo interior
Rizo exterior
Barrena normal
Tonel rápido
Caída del ala
Ocho cubano
Medio ocho cubano o Imperial tombé
Giro Immelmann
Inversión
Inversión a 45º o Medio ocho cubano inverso
Caída de cola

DO-178B, Software Considerations in Airborne Systems and Equipment Certification (en español: «Reglas para la certificación de software aeronáutico») es un estándar para el desarrollo de software en el sector de seguridad crítica de la aviación. El estándar fue desarrollado por la RTCA. La EUROCAE ha adoptado este estándar de forma íntegra, de forma que en Europa se denomina de forma oficial ED-12B. Las autoridades de aviación FAA y EASA exigen la conformidad con el estándar para el proceso para el desarrollo de software. La prueba se realiza por medio de la documentación y es requisito para la cualificación del software para su uso en el sector aeronáutico. A menudo se habla también de una certificación del software. Sin embargo, la EASA, así como la mayoría de autoridades militares europeas, sólo utilizan el término de la certificación para un avión completo. Por ello no es posible adoptar el software de un modelo en otro de forma automática.

Según la funciones que tiene que cumplir el software, puede poner en peligro la seguridad del avión en mayor o menor medida. La DO-178B establece 5 niveles de seguridad (Design Assurance Level, DAL) de A a E según el daño que puede conllevar un malfuncionamiento del software, desde «catastrófico» hasta «sin consecuencias». Según el nivel que reciba el software, se establecen los métodos permitidos para el desarrollo del software dando lugar a diferentes obligaciones de documentación y revisión. Los cinco niveles de DAL A hasta E se corresponden de forma aproximada con el Safety Integrity Level SIL 4 hasta SIL 0.

Descripción: DO-178B , publicado por RTCA, proporciona directrices para la producción de software de equipos de sistemas de suspensión en el aire. Se utiliza internacionalmente para especificar la seguridad y aeronavegabilidad de software para sistemas de aviónica. En él se describen las técnicas y métodos adecuados para garantizar la integridad y la fiabilidad de este tipo de software. Se ha utilizado para asegurar la aprobación de la FAA de software de computadora digital.

Las directrices para el desarrollo de software y la verificación se describen para cada uno de los seis niveles de software. Nivel A se utiliza cuando el comportamiento anómalo provoca condición de fallo catastrófico. Nivel E se utiliza cuando el comportamiento anómalo no tiene efecto sobre la capacidad operativa. Se proporcionan directrices en las áreas de planificación de software, desarrollo, verificación, gestión de configuración, control de calidad, certificación y mantenimiento. La guía define procesos en los que la seguridad es el foco . Los procesos se imponen por lo que la seguridad está diseñado en un producto. Se requiere un proceso de evaluación de la seguridad del sistema para asociar los niveles de criticidad con los distintos elementos del sistema.

Las directrices imponen criterios sobre los procesos del ciclo de vida de software para asegurarse de que los resultados de desarrollo en un sistema seguro. Los procesos se pueden clasificar como de desarrollo o integral. La siguiente figura muestra los elementos básicos de un modelo de ciclo de vida del software, independientemente de un método de ingeniería de software prescrito. Este modelo refleja las actividades básicas de la captura de los requisitos y realizar el diseño, la implementación y la integración. No se pretende dar a entender el modelo de "cascada" o una metodología de desarrollo en particular. El tamaño relativo de cada actividad no pretende ser representativa de los datos recogidos; que se utiliza estrictamente para ilustrar la naturaleza concurrente de las actividades en el proceso de desarrollo de software. Las actividades de desarrollo de software son las principales actividades orientadas al producto y pueden tener un cierto grado de paralelismo. Los otros procesos integrales (por ejemplo, la verificación, gestión de configuración, control de calidad) proporcionan soporte a los procesos de ingeniería de software que ayuda a garantizar la integridad y calidad de las actividades de desarrollo de software. Un proceso productivo utiliza un enfoque constructivo que satisface los criterios de finalización de los procesos integrales (por ejemplo, pruebas, verificación, etc.) durante las actividades de desarrollo de software.

Las secciones siguientes se enumeran las actividades y entregable asociado que se espera como parte del proceso general.

Planificación

Plan de aspectos del software de Certificación

Plan del proyecto de software

Plan de Verificación de Software

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

Plan de Aseguramiento de Calidad de Software

normas

Normas requisito de software

Estándares de Diseño de Software

Normas de código de software

Estándar de Verificación de Software

Documentación de software estándar

Desarrollo

Requisitos de software (requisitos de alto nivel)

Diseño de Software (requisitos de bajo nivel)

Diseño de Software (arquitectura)

código de software

Requisito de verificación de software

Requisitos de software de alto nivel cumplen con los requisitos del sistema

Requisitos de software de alto nivel de trazabilidad de los requisitos del sistema

Requisitos de software de alto nivel preciso y consistente

Requisitos de software de alto nivel compatibles con el hardware

Requisitos de software de alto nivel son verificables

El software de diseño de Verificación

Requisitos de software de bajo nivel cumplir con los requisitos de software de alto nivel

Requisitos de software de bajo nivel trazables a Requisitos de software de alto nivel

Requisitos de software de bajo nivel preciso y consistente

Requisitos de software de bajo nivel son verificables

Arquitectura de Software cumple con requisitos de software de alto nivel

Arquitectura de Software trazable a Requisitos de software de alto nivel

Arquitectura de Software precisa y consistente

Arquitectura de Software compatible con el hardware

Arquitectura de Software es verificable

Arquitectura de Software cumple con los estándares de software

Código de verificación del software

Código Fuente cumple con requisitos de software de bajo nivel

Código Fuente trazable a Requisitos de software de bajo nivel

Código fuente es compatible con la arquitectura del software

Código Fuente es trazable a la Arquitectura de Software

Código Fuente es precisa y consistente

Código Fuente es verificable

Código fuente cumpla con los estándares de software

Verificación del proceso de integración

Se utilizó la metodología de análisis de garantizar Plan de Verificación de Software

Asegurarse de casos de prueba se desarrolló con precisión para satisfacer las necesidades y la cobertura

Asegúrese de resultados de la verificación son correctos

Código objeto cumple con requisitos de software de alto nivel

Código objeto es robusto con respecto a los requisitos de alto nivel

Código objeto cumple con requisitos de software de bajo nivel

Código objeto es robusto con respecto a los requisitos de bajo nivel

Código objeto es compatible con hardware de destino

Código objeto cumple con la Estructura del software (en su caso)

Verificación del Proceso de Verificación

Procedimientos de prueba son correctos

Los resultados son correctos

El cumplimiento de plan de verificación de software

cobertura de la prueba de requisitos de alto nivel

cobertura de la prueba de los requisitos de bajo nivel

cobertura de la prueba de código objeto

cobertura de la prueba - Modificado condición / decisión

cobertura de la prueba - Decisión

cobertura de la prueba - Declaración

cobertura de la prueba - acoplamiento de Datos y Control de acoplamiento

Gestión de la configuración

Los elementos de configuración se identifican

Se establecen líneas de base y trazabilidad

Informar de un problema, control de cambios, revisión de cambio y el registro del estado de configuración se establecen

Archivo, recuperación y liberación se estableció

se estableció el control de carga de software

Se establece control ambiental del ciclo de vida del software

Aseguramiento de la Calidad del Software (SQA)

Asegurar criterios de transición para el proceso de requisitos de software

Asegurar criterios de transición para el proceso de diseño de software

Asegurar criterios de transición para el proceso de código de software

Asegurar criterios de transición para el proceso de integración de software

herramienta de clasificación

Hay también un requisito para llevar a cabo la cualificación herramienta si se utiliza una herramienta para automatizar los procesos de desarrollo de software que normalmente se llevan a cabo por los seres humanos. Herramienta de requisitos operacionales deben ser proporcionados, y la herramienta deben contrastarse con los requisitos operacionales.

Off-the-shelf-Software

El uso de off-the-shelf, incluyendo off-the-shelf (COTS), se permite que el software; Sin embargo, el software debe ser verificada para proporcionar la garantía de verificación como se ha definido para el nivel de criticidad del sistema.