Le F-35

[Klem]

J'ai lu l'article. 250 Lignes par an, c'est pas un peu faible sans vouloir (trop) polémiquer? 

 

Citation:

 

 

 

En Crash prog je fais aisément 3000 lignes par mois. Et je ne suis pas un programmeur.

Oui mais tes lignes ne se retrouvent pas dans un chasseur a 200 M$, si tu te plante les conséquences ne sont pas les mêmes.

Pour une application aéronautique chaque lignes doit être analysée, optimisée et testée avec la plus grande rigueur.

Et je ne parle rmême pas des tests de non régression a chaque modification.

Moi je travail dans le bancaire, gros système et pour 1 ligne de code corrigée tu peux facilement avoir:

1h d'étude pour savoir ou, quoi et comment corriger

2 minute de codage sur le composant impacté

4 h de test unitaire / non régression sur le composant modifié

4h de tests d'intégration pour la chaîne du composant

1 a 2 j de recette sur le système global

Et toute les normes, paperasserie, doc a fournir ... ce qui peux atteindre 1j si il y a des règles strictes a suivre.

C'est un cas extrême, 1 a 20 lignes modifiées pour la même correction c'est presque pareil (le temps de codage est très faible 2-20 minutes), mais ça en dit long sur le décalage entre la productivité en "pissage de code" et la productivité réelle.

[FATac]

Il y a une source vers un standard ou un minimum requierement?  

 

Il y a une vingtaine d'années, l'industrie aérospatiale (américaine et un peu européenne) ne jurait que par le SPICE (Software Process Improvement and Capability dEtermination).

 

Pour les sous-traitant dont j'étais, il était courant d'être SPICE 2, difficile d'atteindre SPICE 3. Il fallait pourtant arriver à atteindre le SPICE 4 pour que notre code soit accepté. A l'époque, seules deux structures avaient atteint le SPICE 5 : l'ESA et la NASA.

 

La NASA a cependant régressé pour n'avoir pas correctement suivi et intégré le code de Lockheed (déjà) sur la mission Mars Climate Orbiter. Une absence de précision sur la définition des interfaces et de contrôle (recette) du délivrable a laissé la mission partir avec cette magnifique confusion entre unités impériales et métriques qui l'a conduit à sa perte. La NASA est retombée SPICE 3, remontée assez vite SPICE 4 et j'ai quitté le domaine depuis donc je ne sais pas s'ils ont récupéré leur niveau d'antan.

[bp8rt]

Toujours sur le sujet du code, si on applique les paradigmes actuels du développement logiciel pour chaque fonction tu dois écrire une batterie de test unitaire te permettant d'affirmer que :

- tout le code a été exécuté (on passe par toutes les alternatives de test et tous les cas d'exception/traitement d'erreur);

- les limites de chaque boucle sont elles aussi testées;

- les plages de valeur significative de chaque paramètre en entrée de la fonction sont essayées ainsi que toute leurs combinaisons (typiquement, 0 est une valeur particulière pour un paramètre numérique soit pour les divisions, soit pour le dimensionnement de tableau).

 

Tu as facilement dix fois plus de lignes de code de test que de code utile. Ce code de test devant être tout aussi fiable (par contre son efficacité est moins importante).

 

Et cela c'est pour le test unitaire des fonctions. Ensuite, il y a les tests d'intégration, les test fonctionnels...

Écrire les cahiers de tests est un projet en soi. Et pas le plus facile !

 

Tous ces tests doivent être exécutés à chaque changement dans le code. Cela implique la mise en œuvre d'automates de test et l'analyse des résultats. De la même façon, la qualité du code sera analysée par des outils dédiés (Sonar, Coverity...). Lesquels mettront en évidence des failles étant passé au travers des étapes précédentes, mais aussi le dépassement de limites issue de bonne pratiques (fonction trop longue, nombre d'alternatives trop importantes...) Et du coup, il faudra refactorer le code pour respecter ces métriques. Et on doit du coup reprendre les test unitaires, d'intégration...

 

Une fois le code réalisé et la version n raisonnablement au point, on fera des tests de métrologie pour vérifier que les perfs attendues sont bien au rendez-vous. Et là, on constatera que la fonction lambda prend dix fois le temps qu'on veut lui accorder, que la consommation mémoire est trop importante... Donc on cherchera des solutions qui passeront par des optimisations du code, des changements d’algorithme... Et on repart pour un tour, codage, test unitaire, test d'intégration, test fonctionnels...

 

Sur le codage proprement dit, chaque variable doit être soigneusement étudiée : quel est le bon type à utiliser, quels sont les plages de valeur possible (avec tous les problèmes de débordement lors des calculs), quelle valeur initiale lui donner...

Les algorithmes doivent être soigneusement étudié aussi. Leur efficacité est elle constante ou dépendante des valeurs à traiter. Un exemple basique, de nombreux algorithme de tri voient leur efficacité compromise si les données sont déjà triées par exemple en ordre inverse. On sera donc amener à choisir l'algo en fonction de la connaissance des données ce qui peut nécessiter des études sur celles ci.

 

Un développement sur ce genre de logiciel va t'amener à gérer de multiples versions logicielles. On rentre dans toute la problématique de gestion de configuration avec les soucis associés.

 

On a une vision faussé de toute cette complexité car sur la plupart des projets informatiques, l'essentiel est d'être prêt pour hier avec quelque chose qui réalise grosso modo le besoin. En cas de plantage, on contournera le problème puis on corrigera pour la version suivante.

Sur un avion, le plantage sera peut être rédhibitoire (idem sur un métro, une fusée, un satellite) : A cause d'un "bug", la fusée est sortie de sa trajectoire et a du être détruit ainsi que sa charge utile... C'est sur que c'est plus grave qu'une commande loupée parce que dans certains cas, le processus d'enregistrement du panier d'achat se gamelle.

 

Donc là, on voit bien que l'écriture de code "utile" est une toute petite partie du problème. Et que ça n'a rien à voir avec le programme réalisé dans une soirée geek avec bière et pizza.

 

J'ai oublié, le client qui invariablement viendra vous voir à peu près au milieu du dév pour dire que "au fait, faudra aussi faire ..." Et vlan, on reprend du début, on cherche comment ne pas tout casser et jeter... (exemple en aéro militaire, les biplaces  d’entraînement qui deviennent biplace de combat et ou le poste arrière passe d'instructeur avec affichage identique au poste avant, à navigateur-bombardier qui a des besoins bien spécifiques).

Donc les 250 lignes par ans, c'est très crédible.

[TomcatViP]

Merci de ces réponses précises. Je pense tout de même qu'un facteur Dix serait plus approprié que les simples 250/an.

 

Mais chaque expérience est différente et dépend de la culture d'entreprise et des outils de contexte. 

Modifié le 18 avril 2015 par TomcatViP

[Picdelamirand-oil]

Merci pour l'éclairage.

[Picdelamirand-oil]

Merci de ces réponses précises. Je pense tout de même qu'un facteur Dix serait plus approprié que les simples 250/an.

 

Mais chaque expérience est différente et dépend de la culture d'entreprise et des outils de contexte. 

 

Pour chaque projet de ce genre, le chef de projet se sent capable d'augmenter la productivité au dela de ce chiffre ridicule de 250 lignes par an. Comme il ne veut quand même pas se mettre la barre trop haut, parce que ce sera à lui de faire des efforts, et qu'il pense comme toi que 2500 lignes sont possibles, il acceptera en général un chiffre du genre 1000 (ça fait quand même une grosse marge). Et il prendra des mesures pour agmenter la productivité: en général c'est quelqu'un d'expérience qui a déjà dirigé des projets et qui se rapelle qu'il y a dans tel projet une bibliothèque de routines déjà testées et qui pourraient être utile et d'autre actions du genre. Cela fait augmenter la productivité un peu: du genre 280-300 et on se retrouve avec le fameux rapport pi entre l'estimation du temps estimé pour le développement et du temps qu'il a été nécessaire d'y consacrer.

 

Le drame du logiciel du F-35 c'est qu'il est deux fois trop gros pour la complexité des fonctions qu'il est censé réaliser. Si on me donnait la direction de ce projet, j'essayerais d'abord de le faire maigrir. Il doit y avoir dedans plein de duplication de la même fonction qu'il faut donc mettre au point plusieurs fois. En gros l'architecture du logiciel est certainement à revoir avec un objectif de réduction de la taille. C'est comme le devis de masse: en aviation personne ne dira jamais "les moteurs sont devenus tellement puissant qu'on a plus besoin de s'occuper du devis de masse". La taille du logiciel c'est l'équivalent du devis de masse et ça montre tout de suite si il est bien ou mal foutu.

Modifié le 18 avril 2015 par Picdelamirand-oil

[Shorr kan]

Merci et bravo les gars. les deux dernières pages sur l'aspect rarement abordé du génie logiciel sont parmi les plus instructives de tout le topic.

 

Sinon, j'aurais une question. Est ce qu'une fusion de données aussi poussée était nécessaire ? Je veux dire, est ce qu'il y a une plus-valu à ce surplus de complexité ; par rapport disons au niveau de fusion de données du Rafale ? Bref, le jeu en vaut-il la chandelle ?

[Picdelamirand-oil]

Merci et bravo les gars. les deux dernières pages sur l'aspect rarement abordé du génie logiciel sont parmi les plus instructives de tout le topic.

 

Sinon, j'aurais une question. Est ce qu'une fusion de données aussi poussée était nécessaire ? Je veux dire, est ce qu'il y a une plus-valu à ce surplus de complexité ; par rapport disons au niveau de fusion de données du Rafale ? Bref, le jeu en vaut-il la chandelle ?

Franchement je ne sais pas comparer le niveau atteind par le F-35 avec celui du Rafale. Celui du Rafale a l'air de donner satisfaction. Celui du F-35... pour être gentil on va attendre qu'il marche pour juger.

 

Pour moi il n'y a pas de "niveau" dans une fusion: on y arrive ou on y arrive pas. Par contre les capteurs qui participent à la fusion induisent des niveaux de complexité différents. Peut-être que la fusion du F-35 est plus difficile de ce fait. J'ai signalé que pour moi la fusion avec des données venant d'une liaison tactique posait des problèmes fondamentaux. Mais je suis sur qu'on saura le programmer, ce qui est difficile dans ce cas c'est de savoir le spécifier. Lorsqu'on rajoutera une liaison du type MADL au Rafale (et j'espère que ce sera un des résultats de Tragedac) sa fusion de données sera comparable à celle du F-35 sauf qu'elle marchera.

[Gallium nitride]

Dans je ne sais plus quelle approche prospective journalistique, il y a quelque années, il me semble avoir lu que seule la transmission lumineuse directe à faisceau étroit (laser?) pouvait convenir à une fusion temps réel d'autant de données mais les choses ont peut-être évolué depuis.

Quoiqu'il en soit, synchroniser des systèmes aussi complexes de détection, de ciblage, d'alerte, etc...cela doit être un sacré challenge. En attendant,la Navy reste fidèle au Growler: http://insidedefense.com/login-redirect-no-cookie?n=168878&destination=node/168878

Le F-35 aura-t-il des capacités de brouillage comme son homologue frenchy?

Modifié le 18 avril 2015 par Gallium nitride

[zx]

Bogdan Praises Norwegian F-35 Weapons

 

http://www.defensenews.com/story/defense/2015/04/17/bogdan-praises-norwegian-f-35-weapons/25944383/

[Boule75]

Et au-delà du traitement de données, ce qu'on a pu appercevoir côté interface pour le F-35 est beaucoup plus ambitieux que ce que ce qu'on voit du Rafale. Sur le premier, des représentations 3D, sur le second, du schématique en 2D sans prétention de représentation "naturelle" de l'altitude. C'est logique pour le F-35 : ça pourrait permettre d'exploiter la capacité du casque à fournir du relief au pilote, l'information produite serait potentiellement de meilleure qualité, ce qui est d'autant plus crucial que l'appareil est strictement monoplace et que certains pilotes auraient en plus à diriger une patrouille jusqu'à 8 avions maintenant le contact entre eux mais pas au-delà (pour le peu que l'on connaisse de la doctrine d'emploi). Bref : les interfaces ont intérêt à être très bonnes.

 

En revanche la complexité du code représentant les données après fusion dans les deux cas est probablement très différente, beaucoup plus compliquée sur le F-35, probablement plus compliqué à mettre au point (algorithmes plus complexes, consommation de calcul et problématique de performance aussi et peut être même absence de certaines libs). Donc s'il n'ont pas d'abord fait des maquettes, des protos fonctionnel pour figer les fonctionnalités sur du code "sale" avant de tout réécrire proprement, ils sont en permamence en grosse tension entre les impératifs de souplesse demandés lors de la mise au point des fonctionnalités et ceux de rigueur pour un code de production.

 

Et en plus, le profil des développeurs qui acceptent de ne pondre que 250 lignes effectives par an ne doit pas être standard, parce qu'en 250 lignes, ben... on ne fait pas grand chose, sauf à faire du concours de concision en perl, ce qui est certainement hors de propos. Bref : ils se trimbalent en plus certainement des développeurs bizares.

Modifié le 18 avril 2015 par Boule75

[Rufus Shinra]

Dans je ne sais plus quelle approche prospective journalistique, il y a quelque années, il me semble avoir lu que seule la transmission lumineuse directe à faisceau étroit (laser?) pouvait convenir à une fusion temps réel d'autant de données mais les choses ont peut-être évolué depuis.

Quoiqu'il en soit, synchroniser des systèmes aussi complexes de détection, de ciblage, d'alerte, etc...cela doit être un sacré challenge. En attendant,la Navy reste fidèle au Growler: http://insidedefense.com/login-redirect-no-cookie?n=168878&destination=node/168878

Le F-35 aura-t-il des capacités de brouillage comme son homologue frenchy?

Du brouillage d'autoprotection? Plus que probablement. De toute façon, son antenne AESA va lui permettre de faire pas mal de saletés en termes de guerre électronique. Pour du brouillage large zone, pas d'idée.

[Picdelamirand-oil]

Et en plus, le profil des développeurs qui acceptent de ne pondre que 250 lignes effectives par an ne doit pas être standard, parce qu'en 250 lignes, ben... on ne fait pas grand chose, sauf à faire du concours de concision en perl, ce qui est certainement hors de propos. Bref : ils se trimbalent en plus certainement des développeurs bizares.

Ils ne font pas que ça, il y a tout le reste à développer, c'est pour ça qu'on ne produit que 250 lignes. Au final ils développent une quantité relativement normale de logiciel.

 Pour du brouillage large zone, pas d'idée.

Le brouillage large zone c'est antinomique avec l'idée de furtivité, ils peuvent laisser ça à d'autres avions.

[Boule75]

Ils ne font pas que ça, il y a tout le reste à développer, c'est pour ça qu'on ne produit que 250 lignes. Au final ils développent une quantité relativement normale de logiciel.

 

Hum... Je dois etre indécrotable en matière de dev. mais programmer des tests, dans le style pas motivant du tout, ça se pose là. J'en comprend bien l'utilité sur du code critique cependant, mais je n'aimerait pas y passer 50% de mon temps !

 

"Tes tests ont montré que ces trois fonctions de Roger était buggée à mort ; merci. Il a tout réécrit, et il faut réécrire tous tes tests ; merci d'avance."

Whaou... Taux de suicide ?

[Claudio Lopez]

Ha je vois que durant ces dernières pages, les informaticiens développeurs ont mis leur grain de sel et c'est bluffant de vous lire.

 

Ca me rappelle une certaine époque ! :)

 

Effectivement, les lignes de codes qui doivent gérer les innombrables exceptions doivent etre particulièrement rigoureuse, et les vérifications de tout les cas de figure possible doivent prendre un temps monstrueux pour éviter que le programme "bug".

 

Contrairement à un PC ou d'une voiture ou d'un bateau, l'ordinateur centrale d'un avion de chasse (ou de ligne) n'a pas le droit de planter car sinon c'est le drame...

En effet, en l'air , il n'y a pas de bande d'arrêt d'urgence auquel on peut s'arreter et attendre la dépaneuse.

 

Déjà dans le cas du Rafale, pour faire une fusion de données aussi performante, les ingénieures de Dassault ont réalisé une grande prouesse.

Mais ici dans le F35, c'est encore 10 fois plus complexe avec leur système de visibilité en 3D et les innombrables autres capteurs à gérer...

 

Comme le disait Edelsteene, il y a quelques années, le F35 n'était qu'à ses "débuts" au niveau des difficultés !

 

En effet, la partie logiciel du systèmes d'armes et de la fusion des données sera la partie la plus complexe à fiabiliser.

 

Les équipes développeurs de LM sont en train de passer de "sacrés moments" inoubliables.

Modifié le 18 avril 2015 par Claudio Lopez

[bp8rt]

Pour le codage, ça ne se passe pas comme ça. Et vu que manifestement ça intéresse certains.

 

Tout d'abord à partir des docs de spécification fonctionnelle tu fais une spécification technique. Grosso modo tu décrit l'organisation de ton module en fonction de haut niveau, puis de moyen niveau... jusqu'à arriver à des fonctions vraiment simple.

Pour chacune de ces fonctions, tu va spécifier ses paramètres et valeurs de retour, les objets auxquelles elle accède, les modifications qu'elle leur fait subir... En bref les interfaces de tous les composants sont explicitées et l'algo de chaque fonction/composant. Les structures de données transverse sont définie...

 

Ensuite, une fois munie de la spécification complète de la petite fonction que tu dois développer, tu va tout d'abord coder les tests. Puis ensuite la fonction. C'est en tout les cas une méthodologie classique. Attention, coder les tests, cela veut dire créer des doublures des objets accédés / modifiés, spécifier comment ils doivent être accédé, dans quel ordre... C'est en soi un vrai développement. Rien à voir avec la sanction du genre "test le code de Robert". Coder du test est souvent plus complexe que coder le produit final. Ça peut tourner au petit défi intellectuel. De toute façon du code développé sans penser aux test unitaires est quasi intestable sauf à tout reprendre (décomposition, modularisation...). Intellectuellement, il y a un aller et retour entre les deux activités.

Pour ma part, je préfère alterner entre codage de quelques lignes (un dizaine à tout casser) et codage des tests de ces lignes nouvelles.

 

Ce qui rend le test ingrat dans le développement de logiciel sans enjeu de fiabilité important, c'est que c'est la dernière roue du carrosse. Si sur ton projet, tu édictes des règles claire dans lesquelles tu valorises l'activité de test, ça peut marcher. Et ça fait gagner tellement de temps ensuite lors de l'intégration !

Ensuite, les outillages permettent de vérifier la couverture de test. Il y a même des outils qui te colorie le code :

- vert : intégralement exécuté lors des tests;

- orange : partiellement testé (cas d'un if complexe ou tu n'as pas eu a exécuté toutes les conditions ; par ex : if (a & b)... Si a est faux, b n'est pas forcément évalué)

- rouge : pas testé.

En info classique avoir une couverture de 60% c'est peu fréquent. 100% ça coûte très cher !

[Claudio Lopez]

Aie aie aie ! Que c'est compliqué tout ça ! :-[  :|

 

J'ai bien fait de ne pas avoir persister dans le développement :)

[Picdelamirand-oil]

Hum... Je dois etre indécrotable en matière de dev. mais programmer des tests, dans le style pas motivant du tout, ça se pose là. J'en comprend bien l'utilité sur du code critique cependant, mais je n'aimerait pas y passer 50% de mon temps !

 

"Tes tests ont montré que ces trois fonctions de Roger était buggée à mort ; merci. Il a tout réécrit, et il faut réécrire tous tes tests ; merci d'avance."

Whaou... Taux de suicide ?

Il faut aussi écrire les simulations....et les tester!

[zx]

Pour le codage, ça ne se passe pas comme ça. Et vu que manifestement ça intéresse certains.

 

Ensuite, les outillages permettent de vérifier la couverture de test. Il y a même des outils qui te colorie le code :

- vert : intégralement exécuté lors des tests;

- orange : partiellement testé (cas d'un if complexe ou tu n'as pas eu a exécuté toutes les conditions ; par ex : if (a & 8)... Si a est faux, b n'est pas forcément évalué)

- rouge : pas testé.

En info classique avoir une couverture de 60% c'est peu fréquent. 100% ça coûte très cher !

toi t'a fait du sonar et de l'integration continue :P et du scrum/agile

Modifié le 18 avril 2015 par zx

[Picdelamirand-oil]

Bon vous croyez vraiment que tous les problèmes logiciels du F-35 vont être réglés d'ici le mois de Juin?

[zx]

Non, parce que des logiciel, pour qu'ils deviennent bons, il faut du temps, de l'argent et beaucoup de travail. plus c'est gros

plus c'est long à faire.  la 1.0 c'est pourri, la 2.0 pas terrible, la 3.0 un peu mieux, 4.0 c'est mieux, 5.0 mauvais, 6.0 c'est bien.

7.0 faut refaire tout avec les nouvelle techno.

 

il suffit de regarder window,  ne jamais se précipiter sur une nouvelle version.  XP bien, Vista bof,  Seven Bien,  Window 8 beruk, W9 ??

, W10 hmmmm!

Modifié le 18 avril 2015 par zx

[Rufus Shinra]

Bon vous croyez vraiment que tous les problèmes logiciels du F-35 vont être réglés d'ici le mois de Juin?

Bah oui ! Et puis le prix du F-35 va tomber à 80 millions de dollars, moteur, pilote, simulateur et pin-up de hangar compris.

 

Quoi, j'ai vu ça dans les Powerpoint de Lockheed-Martin, alors ça doit être vrai ! Et puis ils auront aussi la fusion nucléaire miniaturisée dans deux ans.

[Gallium nitride]

En juin peut-être mais de l'année 2018.

[Rufus Shinra]

En juin peut-être mais de l'année 2018.

C'est beau, l'optimisme.

[bp8rt]

toi t'a fait du sonar et de l'integration continue :P et du scrum/agile

C'est le minimum dans le dév aujourd'hui ! Avec aussi beaucoup de problématique de gestion de configuration.