Forum

Article : L’aveu : le JSF “sur les genoux”...

Pour poster un commentaire, vous devez vous identifier

La situation est-elle si grave que nous voudrions qu'elle soit

Jean-Paul Baquiast

  03/04/2012

Quand je lis ce qu’écrit le Majr Gal Thomson, il y a certes quelques retards, ainsi qu’un énorme challenge. Mais il ne dit pas qu’ils n’y arriveront pas. Ne nous réjouissons nous (?) donc pas trop tôt.Je sais bien qu’entre l’optimisme de commande et la réalité, il y a de grands pas, mais?

Trop d'un coup?

Richard RUTILY

  05/04/2012

J’ai bien noté, grace à ce nouveau post, que le volume de logiciel embarqué était de 10 Millions de lignes et que les 24 millions de lignes sur lesquels je fondait mon raisonnement concernaient en fait l’ensemble du logiciel.

Cela divise par 2,4 le volume de travail nécessaire (250 modules) mais ne change rien aux délais à mon avis car le calculateur tactique reste avec ses 25 modules estimés.

On peut se demander si une grande part des difficultés ne vient pas de la volonté de tout faire tout de suite. Aussi bien le Rafale que l’Eurofighter ont commencer par n’être opérationnel que dans le domaine Air-Air les autres fonctions n’étant introduite ensuite à l’occasion de la livraison de plusieurs standards différents.

Ce processus est long mais il permet une approche par incréments avec intégration de nouvelles fonctions sur une base saine, testée, et validée opérationnellement. Tandis que le JSF essaie de développer simultanément toutes les configurations sur trois avions différents.

On peut aussi se demander si déjà avec le F22, ses 5 millions de lignes de code, la seule fonctionnalité Air-Air et le modèle unique d’avion, les US n’etait pas en limite du faisable. On en parle peu mais le F22 ne semble pas un succès éclatant de ce point de vue aussi.

Dernière chose, je ne sais pas si le logiciel de JSF a été développé from scrach ou si c’est une évolution du logiciel du F22.

Un logiciel totalement incontrôlable

Jean Lemoine

  13/04/2012

En général, un logiciel rend service ou pas. Il fait son travail, ou il plante, ou il fait n’importe quoi.

Lorsque, techniquement, un logiciel fonctionne parfaitement bien mais ne remplit pas la tâche qu’on attend de lui, un informaticien dira ironiquement que le logiciel « works as designed ». Entendre : le logiciel fonctionne bien, c’est le rédacteur du cahier des charges qui s’est trompé.

Mais alors, dire « [...] flight tests demonstrate that the software is working as developed. », ça, j’avoue que je ne m’y attendais pas ! Cette expression dit tout simplement que le logiciel est totalement incontrôlable, puisqu’il fait ce que le programmeur lui a dit de faire (ce qui est l’évidence même), que le résultat soit bon ou mauvais, ou qu’il n’y ait pas de résultat pour cause de bug !