¿Por qué las guías DO no tienen ejemplos?

Según DO-178 C, sección 6.2 Descripción general de la actividad de verificación del software

b. Cuando no sea posible verificar los requisitos específicos del software ejerciendo el software en un entorno de prueba realista, se deben proporcionar otros medios y su justificación para satisfacer los objetivos del proceso de software definidos en el Plan de Verificación del Software o los Resultados de la Verificación del Software.

Después de leer esto, la mayoría de los ingenieros de verificación lo entenderían como otros métodos de verificación como análisis, inspección, etc.

Según la discusión y los argumentos "La intención real de este objetivo es cómo verificamos el software cuando el hardware no está disponible", como usar un simulador para verificar que el software debe documentarse bajo SVP para la satisfacción de este objetivo.

La pregunta es, DO (Orden del documento) como se evaluó de la versión A, B a C ahora y todavía tiene ambigüedades y interpretaciones diferentes. ¿Por qué la FAA/JAA no puede presentar ejemplos o explicaciones en lenguaje sencillo para cada objetivo?

Supongo que porque inflaría el documento.
@ratchetfreak pero con la intención de crear una nueva versión para resolver las ambigüedades y los diferentes entendimientos para diferentes personas.
En el momento en que comience a enumerar ejemplos, algunos los tomarán como normativos. Puede que esta no sea la razón, pero ciertamente es una razón por la cual agregar ejemplos a la legislación (o documentos equivalentes a la legislación) suele ser una mala idea.
Las normas no están dirigidas a los legos, están dirigidas a los ingenieros y deben generar un pensamiento diversificado e independiente. Proporcionar ejemplos incentivará a los guerreros de copiar-pasta de solución única, que es una propuesta peligrosa en la seguridad del software.
@DeerHunter cuando mencioné a laico significaba un lenguaje simple. La discusión actual fue solo entre ingenieros calificados.
@MichaelKjörling tiene un gran punto: dedique un tiempo a StackOverflow y descubrirá rápidamente cuántos desarrolladores de software 'profesionales' simplemente copian y pegan el código a ciegas de la documentación u otras fuentes sin siquiera entenderlo. Para los sistemas críticos, no desea un "lenguaje profano", desea especificaciones precisas e inequívocas . En casos extremos, la especificación puede incluso convertirse en una especie de pseudocódigo, pero ese es el precio que hay que pagar.
La pregunta suena como una queja (o una sugerencia) por la ambigüedad de los ingenieros/desarrolladores sin experiencia. Creo que cualquier elaboración a fondo del tema daría lugar a la comprensión correcta. No solo HACER, sino también otras guías (incluso los estándares) la mayoría de las veces dejan la puerta abierta para que "si no puede hacer algo de la manera adecuada, (trate de) hacer algo que sea lo suficientemente bueno y planifíquelo". ). Si no dejan esta puerta abierta, solicitará pruebas fuera de este planeta (¡prueba todo en hardware real!).
"¿Por qué las guías DO no tienen ejemplos?". Por supuesto, nadie puede saber las razones, pero es habitual que las firmas consultoras discutan en profundidad los estándares con los autores y luego brinden apoyo a los clientes que deben usar estos estándares. No digo que sea el mejor enfoque, solo que es común ver esta intermediación rentable.
'Según la discusión...' ¿Qué discusión?

Respuestas (2)

Los documentos RTCA no son documentos de la FAA, aunque la FAA suele ser miembro del Comité Especial que crea los documentos. Si se va a agregar un ejemplo, es decisión del SC, no de la FAA.

La razón por la que no se dan ejemplos es que la recomendación es clara en sí misma. Un buen ingeniero de V&V leerá esta recomendación y utilizará su habilidad, experiencia y creatividad para encontrar otros medios aceptables para validar los requisitos de software que no se pueden validar en un entorno realista. Este medio alternativo se documenta luego en el SVP.

Dar un ejemplo no ayuda en absoluto, ya que la solución dependerá completamente del software bajo prueba y la naturaleza de los requisitos.

Si el hardware no está disponible, un emulador puede ser la solución.

En otros casos, se deben generar entradas de prueba artificiales, porque fallar una prueba en un entorno realista puede resultar catastrófico.

La FAA interpreta una limitación a su autoridad (que se deriva de FAR 25.1309 para aeronaves de transporte, por ejemplo): No se supone que diga que se requiere nada para demostrar el cumplimiento (para un módulo de software o un sistema de hardware) y ser aprobado. en el contexto de una aeronave certificada. Puede (y lo hace) especificar ciertos pasos que constituyen medios aceptables de cumplimiento.

Los documentos en la "cadena de autoridad", no solo DO-178C y DO-254, sino también AC 20-152, siempre tienen cuidado de decir que los medios alternativos de cumplimiento pueden ser aceptables.

La cuestión práctica, sin embargo, es que si DO-178C es plausiblemente apropiado para un módulo de software, y si el hardware que se está desarrollando está dentro del alcance de DO-254, es probable que el DER insista en que se sigan esos estándares. Y la FAA ciertamente se siente cómoda con esa postura. Entonces, aunque estos documentos no son normativos, son tan importantes como si fueran normativos.

Si las normas incluyeran ejemplos de medios alternativos de cumplimiento, ocurriría una de dos cosas. O bien estos ejemplos se tomarían bajo la misma luz seminormativa que se toma el resto de la norma, en cuyo caso la aprobación (cuando corresponda) basada en algún otro medio de cumplimiento sería mucho menos probable que se aceptara, o la existencia de los ejemplos alentaría demasiado a los desarrolladores a luchar por la aceptación de sus propios medios de cumplimiento, en los casos en que DO-178C es perfectamente aplicable. Este último seguramente generaría “más calor que luz”.

¿Por qué las guías DO no tienen ejemplos?
RespuestasAquíPolítica de privacidad1y, 0v