¿Es la programación ágil también & # 8230; ad hoc para sistemas críticos de seguridad? [cerrado]

Question

Por ejemplo, ¿sería increíblemente peligroso hacerlo para el software de aviónica?

Nota, no entiendo completamente Agile.

Answer 1

He trabajado en sistemas de control de tráfico aéreo utilizando un proceso esencialmente de cascada, y esos proyectos definitivamente podrían haberse beneficiado de prácticas ágiles. No me gusta pensar cuánto de ese código funcionó "por accidente" sin ningún tipo de prueba de regresión automatizada a nivel de unidad. Y lo que se exige por adelantado es algo así como un arenque rojo. Si bien es cierto que los sistemas aeroespaciales probablemente estén lo más cerca posible de tener requisitos iniciales, usted aún tiene argumentos sobre el significado de requisitos ambiguos que solo aparecen cuando el sistema está Se supone que está en pruebas de aceptación. O bien, tiene problemas de rendimiento que nadie había considerado que aparecen al final del juego debido a la integración del Big Bang. Primero en probar, soluciones de picos, integración continua, programación en pares: creo que todos estos habrían mejorado los proyectos en los que trabajé.

ACTUALIZACIÓN: sin mencionar con qué frecuencia los "documentos de diseño" Un paquete de mentiras al final del proyecto, porque el diseño necesariamente evolucionó frente a la realidad. Agile reconoce el hecho del diseño emergente, que es tan real en los proyectos de Waterfall como en cualquier otro, en lugar de pretender que puede obtener el diseño justo antes de comenzar a escribir código.

Answer 2

Trabajo en el sector aeroespacial (satélites específicamente) y utilizamos un enfoque híbrido porque enfrentamos dos preocupaciones diferentes: requisitos del mundo real y requisitos de procesos comerciales.

Utilizamos un enfoque de cascada para los requisitos de las naves espaciales y las secciones críticas porque los cambios en el satélite son lentos y raros, y arruinarlo es malo.

Pero para los procesos comerciales siempre cambiantes, utilizamos un enfoque ágil porque cómo vuelan la nave espacial cambia constantemente debido a las demandas de los clientes. Al arruinar, significa que, en el peor de los casos, el usuario obtiene resultados no tan agradables.

Answer 3

No tengo suficiente experiencia en ese campo (que no sea un usuario de sistemas de aviación) para formar mi propia opinión verdaderamente independiente. Sin embargo, todas las cosas que sigo leyendo sobre los sistemas críticos que tienen el mejor historial me llevan a creer que la cascada es en realidad la mejor manera. Es posible porque las personas están dispuestas a permitir el desperdicio adicional de los requisitos de congelación para promover la seguridad. Las concesiones son un poco diferentes en ese caso, supongo.

Answer 4

Cómo determinar la aplicabilidad de las prácticas ágiles a la misión y los sistemas vitales

Filtros de aptitud ágil

En resumen, no hay " Ágil " programación. Hay un conjunto de prácticas. Algunos se prestan mejor que otros, pero en general, cualquier proyecto se beneficiará de algunas de las prácticas.

El área más grande que suele preocupar a la gente es el modelado y la arquitectura. Hay muchos equipos que utilizan prácticas ágiles; por ejemplo, conozco a miembros del equipo Fun3d con la NASA: utilizan prácticas ágiles y se ocupan de cosas como el soporte del Transbordador espacial.

Hay varios grupos por ahí dedicados a este tipo de trabajo, por lo que es posible. Solo debe conocer sus riesgos, como cualquier otra metodología.

Answer 5

Agile debería ser un proceso disciplinado. Cualquiera sea su proceso, los problemas de seguridad en este caso deben abordarse por adelantado. No veo cómo la entrega en iteraciones, el uso de un sistema de compilación continua, el cálculo de las tasas de quema del programador, la celebración de reuniones, la participación activa del cliente, etc. podrían tener un impacto negativo en la seguridad.

Answer 6

Hay muchas consideraciones. El primero es cuál es su criticidad de seguridad. Si su respuesta es " A " o "B" (y realmente " A ") entonces absolutamente NO. No se saldrá con la suya haciendo ágil en cualquier forma o forma. Hay estándares de codificación muy estrictos, estándares de documentación y estándares de proceso requeridos del software de Nivel A (mi experiencia de aproximadamente 15 años). Esto incluye:

• Trazabilidad completa arriba / abajo.
• Cobertura completa de sucursales.
• Cobertura multicondicional completa.
• Los documentos básicos detallados por DO-178B incluyen: SRD, SDD, SCI, SCMP, SDP, TQP, SCI ...

No solo tiene que certificar su código, diseño y requisitos, sino que también debe certificar conjuntos de herramientas, compiladores, equipos de prueba automatizados, etc.

En resumen, no es una hazaña pequeña y no se hará con un equipo pequeño. Del mismo modo, las interfaces son realmente sólidas y muy específicas, así como estáticas. Por lo general, cambiar las interfaces requiere coordinación con más de 3 compañías (Airframe manufacturing, Vender 1 hablando con Vender 2).

Honestamente, un cambio de código de 12 líneas puede costar más de $ 170,000. Por supuesto, un cambio de código de 500 líneas será de $ 190,000. En resumen, hay una gran sobrecarga de procesos asociada con el código del Nivel A (mucho menos con el Nivel B, incluso menos con C y muy poco con el Nivel D), lo que hace que las pequeñas iteraciones sean muy costosas; es decir. cuesta mucho dinero obtener un 777 totalmente alimentado y volador para probar un pequeño cambio. Incluso los laboratorios de prueba del sistema de aviones comerciales grandes tendrán una tasa de quemado de $ 10,000 / día.

Por ejemplo: Nivel A: HUD, inversores de empuje, sistemas de potencia, FADEC (control del motor) Nivel B: lógica de conmutación secundaria, sistemas de comunicación vocal. Nivel C: Enlaces de datos en vuelo. Nivel D: sistemas de entretenimiento en vuelo.

El nivel D y, quizás, el nivel C, podrían ser candidatos para Agile.

Answer 7

Creo que eso depende de cómo se integran las demandas de seguridad en el proceso. Si son un conjunto adicional de pruebas, eso no es nada que esté en contradicción con la programación ágil. Creo que los métodos ágiles pueden ayudarlo a producir un software más seguro, porque los proyectos ágiles tienden a ser de mayor calidad que los proyectos en cascada. Será importante que la garantía de calidad adicional que ha instalado también se esté utilizando para los métodos ágiles.

Pero si las demandas de seguridad se aplican al proceso de construcción, eso puede estar en contradicción con los métodos ágiles.

Answer 8

En realidad, existe una variación del modelo de cascada denominado modelo V, que está favorecido por IEC61508, por ejemplo. Es una especie de cascada, pero con disposiciones para la repetición (es) del ciclo básico del proyecto. El propósito principal de las repeticiones en este caso es tratar los problemas detectados en varias etapas del proceso. La idea básica es que cuanto más tarde en el camino encuentre un problema, más atrás en su proceso tendrá que ir para cuidar y revisar el impacto de sus cambios.

Entonces no es realmente ágil, pero ... :-)

Answer 9

Podría usar el enfoque ágil, pero el primer pase tendría que incluir sus aspectos de seguridad, o al menos preverlos, para que no se dispare en el pie y termine reescribiendo todo. Pero estoy de acuerdo con Brian, probablemente sea mejor que uses el enfoque Waterfall para tales proyectos.

Answer 10

En la conferencia EuroStar 2009, Gittie Ottosen habló sobre cómo son ágiles en su empresa. Lo impresionante es que esta compañía Systematic está creando software para aviones, militares, etc. Lo hacen cumpliendo con CMMI 5, ISO 9001 y AQAP 150 & amp; 2110. Así que supongo que Agile se puede aplicar a sistemas con altas regulaciones. Tal vez intente buscar esa presentación e intente obtener más información de él.