La programmation Agile est-elle aussi… ad hoc pour les systèmes critiques pour la sécurité? [fermé]

Question

Par exemple, serait-il incroyablement dangereux de le faire pour un logiciel avionique?

Remarque, je ne comprends pas parfaitement l'agilité.

Answer 1

J'ai travaillé sur des systèmes de contrôle de la circulation aérienne utilisant un processus essentiellement en cascade, et ces projets auraient certainement pu bénéficier de pratiques agiles. Je n'aime pas penser à la quantité de ce code qui a fonctionné "par accident", sans aucun type de test de régression automatisé au niveau de l'unité. Et les exigences préalables sont un peu un casse-tête. Il est vrai que les systèmes aérospatiaux sont probablement aussi proches que possible des exigences d’installation définies au départ, mais vous avez toujours des arguments sur la signification des exigences ambiguës qui ne se manifestent que lorsque le système est en place. censé être en test d'acceptation. Ou bien vous avez des problèmes de débit que personne n'avait encore pris en compte et qui se sont manifestés tard dans le jeu en raison de l'intégration big-bang. Testez d’abord, les solutions de pointe, l’intégration continue, la programmation en paire, je pense que tout cela aurait amélioré les projets sur lesquels j’ai travaillé.

UPDATE: Sans parler de la fréquence à laquelle les " documents de conception " " c’était un paquet de mensonges à la fin du projet, car la conception a nécessairement évolué face à la réalité. Agile reconnaît le fait que la conception est émergente, ce qui est tout aussi réel dans les projets Waterfall que dans d’autres, plutôt que de prétendre que la conception peut être correcte avant même de commencer à écrire du code.

Answer 2

Je travaille dans l'aérospatiale (les satellites en particulier) et nous utilisons une approche hybride, car nous sommes confrontés à deux préoccupations différentes: les exigences du monde réel et les exigences des processus métier.

Nous utilisons une approche cascade pour les besoins des engins spatiaux et des sections critiques, car les modifications apportées au satellite sont lentes et rares, et les erreurs sont graves.

Mais pour les processus commerciaux en constante évolution, nous utilisons une approche agile-ish, car la manière dont ils pilotent l'engin spatial change constamment en raison des demandes des clients. Vouloir là-haut signifie que, dans le pire des cas, l’utilisateur obtiendra des résultats impossibles.

Answer 3

Je n'ai pas assez d'expérience dans ce domaine (à part un utilisateur de systèmes aéronautiques) pour former ma propre opinion réellement indépendante. Cependant, tout ce que je continue de lire sur les systèmes critiques qui ont la meilleure expérience professionnelle me porte à croire que la chute d'eau est en fait le meilleur moyen. C'est possible parce que les gens sont prêts à accepter le gaspillage supplémentaire lié à la congélation afin de promouvoir la sécurité. Les compromis sont un peu différents dans ce cas, je suppose.

Answer 4

Détermination de l'applicabilité des pratiques agiles à la mission et aux systèmes essentiels à la vie

Filtres de compatibilité agile

En bref, il n’existe pas de " Agile " la programmation. Il y a un ensemble de pratiques. Certains se prêtent mieux que d'autres, mais en général, tout projet bénéficiera de certaines pratiques.

La modélisation et l’architecture sont au cœur des préoccupations principales des gens. De nombreuses équipes utilisent des pratiques agiles - par exemple, je connais des membres de la l'équipe Fun3d . avec la NASA - ils utilisent des pratiques agiles et traitent de choses comme le support de la navette spatiale.

Il existe plusieurs groupes consacrés à ce type de travail - c'est donc possible. Il vous suffit de connaître vos risques, comme toute autre méthode.

Answer 5

Agile devrait être un processus discipliné. Quel que soit votre processus, les problèmes de sécurité dans ce cas devraient être abordés dès le départ. Je ne vois pas en quoi le fait de fournir des itérations, d'utiliser un système de construction continu, de calculer les taux de consommation des programmeurs, d'organiser des réunions en stand-up, de faire participer le client, etc. aurait un impact négatif sur la sécurité.

Answer 6

Il y a beaucoup de considérations. Le premier concerne votre criticité en matière de sécurité. Si votre réponse est " A " ou " B " (et vraiment "A"), alors absolument PAS. De toute façon, vous ne ferez pas de choses agiles. Des normes de codage, des normes de documentation et des normes de processus très strictes sont requises pour les logiciels de niveau A (mes antécédents d’environ 15 ans). Cela comprend:

• Traçabilité totale haut / bas.
• Couverture complète des succursales.
• Couverture complète multi-conditionnelle.
• Les documents de base définis par la DO-178B comprennent: SRD, SDD, SCI, SCMP, SDP, TQP, SCI ...

Ainsi, vous devez non seulement certifier votre code, votre conception et vos exigences, mais également vos jeux d’outils, compilateurs, équipement de test automatisé, etc.

.

En bref, ce n’est vraiment pas un mince exploit et cela ne se fera pas avec une petite équipe. De même, les interfaces sont très solides, très spécifiques et statiques. La modification des interfaces nécessite généralement une coordination avec plus de 3 entreprises (fabricants de cellules, Vender 1 parlant à Vender 2).

En toute honnêteté, un changement de code sur 12 lignes peut coûter jusqu'à 170 000 $. Bien sûr, un changement de code de 500 lignes coûtera 190 000 $. En bref, il y a un temps système considérable associé au code de niveau A (beaucoup moins au niveau B, encore moins au code C et très peu au niveau D), ce qui rend les petites itérations très coûteuses; c'est à dire. Il en coûte beaucoup d'argent pour obtenir un 777 entièrement alimenté en carburant et tester un petit changement. Même les laboratoires d’essais des grands avions commerciaux auront un taux de combustion de 10 000 dollars par jour.

Par exemple: Niveau A: HUD, Inverseurs de poussée, Systèmes d'alimentation, FADEC (Contrôle du moteur) Niveau B: logique de commutation secondaire, systèmes de communication vocale. Niveau C: liaisons de données en vol. Niveau D: systèmes de divertissement en vol.

Le niveau D et, peut-être le niveau C, pourraient être candidats à Agile.

Answer 7

Je pense que cela dépend de la manière dont les exigences de sécurité sont intégrées au processus. S'ils constituent une série supplémentaire de tests, rien ne contredit la programmation agile. Je pense que les méthodes agiles peuvent vous aider à produire des logiciels plus sécurisés, car les projets agiles ont tendance à être de meilleure qualité que les projets cascade. L’important sera que l’assurance qualité supplémentaire que vous avez installée soit également utilisée pour les méthodes agiles.

Mais si les exigences de sécurité sont appliquées au processus de construction, cela peut être en contradiction avec les méthodes agiles.

Answer 8

En fait, il existe une variante du modèle en cascade appelée modèle en V, privilégiée par la norme IEC61508, par exemple. C'est une cascade en quelque sorte, mais avec des dispositions pour la réitération du cycle de base du projet. Les réitérations dans cette affaire ont pour objectif principal de traiter les problèmes détectés à différentes étapes du processus. L'idée de base est que plus vous rencontrez un problème, plus tard dans la procédure, vous devez prendre en compte et analyser l'impact de vos modifications.

Ce n'est donc pas vraiment agile, mais ...: -)

Answer 9

Vous pouvez utiliser l’approche agile, mais le premier passage devra inclure vos aspects de sécurité et de sécurité, ou au moins les prévoir, pour que vous ne vous tiriez pas dans le pied et ne réécrivez pas le tout. Mais je suis d'accord avec Brian, vous feriez probablement mieux d'utiliser l'approche Waterfall pour de tels projets.

Answer 10

Lors de la conférence EuroStar 2009, Gittie Ottosen a expliqué à quel point sa société était agile. Ce qui est impressionnant, c’est que cette société Systematic crée un logiciel pour les aéronefs, les forces armées, etc. Elle le fait en conformité avec CMMI 5, ISO 9001 et AQAP 150 & 2110. Je suppose donc que l'agile peut être appliqué à des systèmes soumis à des réglementations strictes. Essayez peut-être de consulter cette présentation et d’obtenir plus d’informations de sa part.