J'ai un avis personnel sur la classification "Ariane 501 : Software ou système ?" si je peux appeler ça comme ça. Et je pense qu'une partie peut s'appliquer au cas Boeing.
Si il y a des erreurs logicielles indéniables (pourquoi certaines conversions sont protégées et d'autre non par exemple), pour moi la cause élémentaire est système. C'est le système qui décide de réutiliser des parties, c'est le système qui décide de se passer de certains tests. Normalement, c'est aussi l'analyse système qui doit décider des exigences systèmes qui sont affinées en exigences logicielles, et la revue d'exigences en passant d'une version d'un produit à un autre aurait dû voir ce problème.
Ça ne veut pas dire que les ingénieurs logiciels n'auraient rien dû voir, ou rien dû dire, s'ils en ont eu l'opportunité (le problème, c'est que si je comprends bien l'histoire, le logiciel de l'ordinateur de bord a été changé, mais pas vraiment celui des centrales inertielles, donc c'est à l'interface entre deux logiciels que le problème a lieu, difficile à voir si ce sont des équipes indépendantes. Encore une fois, c'est de l'intégration système.) Mais de façon générale, si un développeur (ou une équipe, ou un intégrateur) voit un problème potentiel, il doit être remonté. La DO-178C/ED-12C (pas applicable pour Ariane 5, déjà elle n'existait pas en 1996, et c'est plutôt un truc d'aéronautique que d'aérospatial) dit par exemple :
2.2.2 Information Flow from Software Processes to System Processes
The software life cycle processes analyze the system requirements allocated to software as part of the software requirements process. If such an analysis identifies any system requirements as inadequate or incorrect, the software life cycle processes should capture the issues and refer them to the system processes for resolution. Furthermore, as the software design and implementation evolves, details are added and modifications made that may affect system safety assessment and system requirements.
C'est le process système qui est responsable de ce niveau là, mais il est de la responsabilité des autres équipes (par exemple logicielles) de faire savoir qu'un problème potentiel peut avoir lieu. Si votre rôle c'est de faire le logiciel, et que l'exigence dit un truc absurde, ou vague, ou étrange, ou qui semble anormal, il faut remonter l'information.
(Et c'est là que si j'ai bien compris, mais à prendre avec précaution, dans l'histoire de l'avion, une partie du logiciel est externalisée, et faite par des gens qui font du logiciel, mais qui n'ont peut-être pas une compréhension du système, et qu'ils ont peut-être moins de poids quand ils remontent ce genre d'information. Le logiciel ne devrait pas juste être là pour implémenter les exigences, il doit/devrait pouvoir les critiquer)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
# Mon avis (insignifiant)
Posté par 2PetitsVerres (Mastodon) . En réponse à la dépêche Bogues de logiciel et bogues de management : 737 Max et autres catastrophes. Évalué à 5.
J'ai un avis personnel sur la classification "Ariane 501 : Software ou système ?" si je peux appeler ça comme ça. Et je pense qu'une partie peut s'appliquer au cas Boeing.
Si il y a des erreurs logicielles indéniables (pourquoi certaines conversions sont protégées et d'autre non par exemple), pour moi la cause élémentaire est système. C'est le système qui décide de réutiliser des parties, c'est le système qui décide de se passer de certains tests. Normalement, c'est aussi l'analyse système qui doit décider des exigences systèmes qui sont affinées en exigences logicielles, et la revue d'exigences en passant d'une version d'un produit à un autre aurait dû voir ce problème.
Ça ne veut pas dire que les ingénieurs logiciels n'auraient rien dû voir, ou rien dû dire, s'ils en ont eu l'opportunité (le problème, c'est que si je comprends bien l'histoire, le logiciel de l'ordinateur de bord a été changé, mais pas vraiment celui des centrales inertielles, donc c'est à l'interface entre deux logiciels que le problème a lieu, difficile à voir si ce sont des équipes indépendantes. Encore une fois, c'est de l'intégration système.) Mais de façon générale, si un développeur (ou une équipe, ou un intégrateur) voit un problème potentiel, il doit être remonté. La DO-178C/ED-12C (pas applicable pour Ariane 5, déjà elle n'existait pas en 1996, et c'est plutôt un truc d'aéronautique que d'aérospatial) dit par exemple :
C'est le process système qui est responsable de ce niveau là, mais il est de la responsabilité des autres équipes (par exemple logicielles) de faire savoir qu'un problème potentiel peut avoir lieu. Si votre rôle c'est de faire le logiciel, et que l'exigence dit un truc absurde, ou vague, ou étrange, ou qui semble anormal, il faut remonter l'information.
(Et c'est là que si j'ai bien compris, mais à prendre avec précaution, dans l'histoire de l'avion, une partie du logiciel est externalisée, et faite par des gens qui font du logiciel, mais qui n'ont peut-être pas une compréhension du système, et qu'ils ont peut-être moins de poids quand ils remontent ce genre d'information. Le logiciel ne devrait pas juste être là pour implémenter les exigences, il doit/devrait pouvoir les critiquer)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.