Le logiciel du F-35

[Picdelamirand-oil]

Il y a 8 heures, prof.566 a dit :

En fait, les premiers 3F plantaient tellement qu'ils en sont revenus à une 3i pour la stabiliser (et au passage corriger des bugs du 2B). Puis ils sont repartis sur le 3F. Ils en sont aux tests du 3FR06, qui est normalement le release qui sera testé par leOT&E.... Enfin quand les avions instrumentés test auront subi 155 modifications.... Et que le pod de restitution existera (il n'est pas encore commandé... Ca va être ric rac pour le mois d'Aout). De toutes facons pour les tests, dans les dataloads ca va être dur. Et comme pour aller plus vite ils skippent des tests en assurant que ceux effectués précedemment sur d'autres bloks restent valables etc.................

Oui la méthodologie est une approche, fondée sur l'expérience, pour faire un développement qui optimise les délais et les coûts. Quand un projet est en retard il devrait donc augmenter la rigueur de l'approche méthodologique. Mais en général c'est là qu'on fait des impasses "pour aller plus vite" . L.M. voudrait faire le travail de 5 ans en un an . 

Est-ce qu'un modérateur pourrait pas transférer ce fil sous armée de l'air/Amérique? Je me suis trompé à la création. @pascal

[Picdelamirand-oil]

L'exposant 0.31

Hé oui c'est là qu'est la triche! en effet dans le modèle intermédiaire, en fonction de la nature du projet l'estimation de l’effort est le suivant:

• Simple : TDEV = 2.5(HM)^0.38
• Modéré : TDEV = 2.5(HM)^0.35  
• Complexe : TDEV = 2.5(HM)^0.32

si on prolonge la tendance on devrait avoir;

• Très complexe : TDEV = 2.5(HM)^0.29

Que donnerais l'application de cette formule?

TDEV = 2.5(7 599 657)^0.29 = 247 mois soit 20 ans et 7 mois ce qui met la fin du développement en Mai 2022. Voila qui va paraître plus raisonnable au F-35 Fan club.

Mais si j'ai présenté les choses ainsi c'est pour montrer l'extrême sensibilité du modèle à la valeur des exposants que l'on trouve dans les formules qui permettent d'évaluer l'effort et la durée. Cette sensibilité est exacerbée pour les très gros projets et je vous propose d'examiner ce que signifie ces exposants et comment on peut agir dessus pour les rendre plus favorables.

Modifié le 11 février 2017 par Picdelamirand-oil

[Picdelamirand-oil]

Merci pour le transfert aux Modérateurs

[prof.566]

Après, le choix des coefficients est arbitraire,  non.?

[Picdelamirand-oil]

il y a 6 minutes, prof.566 a dit :

Après, le choix des coefficients est arbitraire,  non.?

Non il est fondé sur l'expérience, et on peut le calculer en tenant compte des caractéristiques du projet. Par exemple on a "calculé" le coefficient M dans le post présentation du modèle COCOMO (suite). Pour calculer l'exposant il faudrait passer du modèle intermédiaire au modèle détaillé, c'est un peu ce qu'on va faire dans la discussion que j'ai annoncé.

[Picdelamirand-oil]

Les exposants du modèle COCOMO

Pour l'instant on a estimé l'effort par la formule:

Très Complexe : HM = 2.6*M*(KLOC) 1.26 et pour le délai: TDEV = 2.5(HM)0.31

En fait j'ai aussi triché pour le calcul de M. C'est normal je voulais justifier ma prévision de 2031, donc j'ai pris des coefficients défavorables pour tous les critères permettant de calculer M. Mais on va rester comme cela pour voir ce que ça donne et on calculera un M plus réaliste après.

On a vu que l'exposant 1.26 reflétait l’augmentation non linéaire des coûts en fonction de la taille  du projet. Cette non linéarité vient du fait que si n taches doivent être séparément coordonnées avec chaque autre tâche, l’effort augmente en n*(n-1)/2.

On se propose d'illustrer ce phénomène. On fait l'hypothèse que dans une équipe de trois personnes on arrive à se coordonner "naturellement" c'est-à-dire sans procédures particulières normalisées en consommant chacune 3% de son temps, ce qui fait 9% du temps d'une personne pour l'équipe.

Or n*(n-1)/2 est égal à 3 pour n=3.

Pour n=33 l'effort de coordination supplémentaire qui est impliqué par l'introduction d'un nouvel employé contrebalance les ressources que cet employé apporte.

En effet 33*34/2=561 et 33*32/2= 528 donc la charge de coordination augmente de 33 et comme 3 de charge correspond à 9% d'une personne à temps plein, 33 de charge correspond à 99%.

Alors comment fait-on pour avoir des équipes importantes? On fait deux sous projets, on fixe l'interface entre les deux sous projets qui prendront cette définition comme une contrainte et cela réduit la charge de coordination car on passe de n à deux fois n/2. Malgré tout plus le projet est grand et plus la charge de coordination représente une part importante de la charge totale.

Les valeurs que j'ai prises n'ont aucune importances c'est juste pour montrer qu'on ne peut pas faire grandir les équipes indéfiniment sans prendre des mesures pour organiser la communication et que même ainsi le temps passé à se coordonner explose avec la taille de l'équipe.

Il faut dire qu'on parle de grandes équipes l'effort est de 7 599 657 mois homme et la durée de 340 mois, cela fait une taille moyenne de l'équipe de 22352 personnes!

Et là on se dit qu'il faut faire quelque chose pour réduire la taille de l'équipe et notre seule possibilité c'est de réduire M.

[ARPA]

Il y a 2 heures, Picdelamirand-oil a dit :

Et là on se dit qu'il faut faire quelque chose pour réduire la taille de l'équipe et notre seule possibilité c'est de réduire M.

Et là, on se dit qu'on ne peut pas tout mettre en équation.

Il y a quelques temps, j'avais aussi trouvé une formule sur le sur coût associé à une coopération en fonction du nombre de participants. Donc en appliquant cette formule, avec 9 pays partenaires (ou 13 forces aériennes partenaires ? ou encore plus ?), le F35 coûtera 3 ou 4 fois plus cher à développer que s'il n'y avait eu qu'un seul partenaire. Si on rajoute qu'il y a 3 variantes vraiment différentes, on peut encore multiplier le coût de développement.

Le programme F35 accumule les sources de complications. Entre le nombre de versions, le nombre de pays participants, l'usage de technologies non maitrisés, la volonté de faire dans l'extrême (le plus puissant réacteur occidental) un cahier des charges relativement contradictoire (avion de masse, mais aussi avion plus performant que la concurrence) on arrive "logiquement" à un avion presque impossible à développer.

[Picdelamirand-oil]

C'est pas faux.

[Teenytoon]

Sans blagues, vous savez pas ce que ça veut dire savoureux ?

 

 

 

-----> [ ]

Modifié le 13 février 2017 par Teenytoon

[Invité Dorfmeister]

il y a 56 minutes, Teenytoon a dit :

Sans blagues, vous savez pas ce que ça veut dire savoureux ?

 

 

 

-----> [ ]

[Henri K.]

Il y a 5 heures, ARPA a dit :

un avion presque impossible à développer.

Pourtant, il est là, le zinc vole, plus de 200 construits, les usines étrangers s'ouvrent l'une après l'autre, ça fait chier beaucoup de monde, moi je le regarde avec une dose d'admiration, une dose de réticence, et une dose d'amertume.

Henri K.

[prof.566]

Sincèrement @Henri K. , lis le passage du rapport de Gilmore sur les software blocks, c'est -à mon avis- un cas d'école... Mais je ne suis pas spécialiste. Si tu peux m'en faire une brève abalyse pour un article, je prends. (Un article sur le J-20 aussi tiens).

[bubzy]

Il y a 13 heures, ARPA a dit :

Et là, on se dit qu'on ne peut pas tout mettre en équation.

Il y a quelques temps, j'avais aussi trouvé une formule sur le sur coût associé à une coopération en fonction du nombre de participants. Donc en appliquant cette formule, avec 9 pays partenaires (ou 13 forces aériennes partenaires ? ou encore plus ?), le F35 coûtera 3 ou 4 fois plus cher à développer que s'il n'y avait eu qu'un seul partenaire. Si on rajoute qu'il y a 3 variantes vraiment différentes, on peut encore multiplier le coût de développement.

Le programme F35 accumule les sources de complications. Entre le nombre de versions, le nombre de pays participants, l'usage de technologies non maitrisés, la volonté de faire dans l'extrême (le plus puissant réacteur occidental) un cahier des charges relativement contradictoire (avion de masse, mais aussi avion plus performant que la concurrence) on arrive "logiquement" à un avion presque impossible à développer.

Il ne me semble pas que les pays partenaires soient en charge du développement de l'avion. De systèmes périphériques oui, qu'ils ont obtenu comme compensation, mais qui sont toujours attendu. Seuls les british ont en charge une partie du développement du moteur. 

Pour tout ce qui est software, c'est uniquement US pour l'instant. Et pourquoi pas israélien puis qu'ils auraient la main sur la partie guerre électronique.

[Invité Dorfmeister]

il y a une heure, prof.566 a dit :

 @Henri K. (Un article sur le J-20 aussi tiens).

(Et sur le J-16 aussi)

[rendbo]

Il y a 3 heures, bubzy a dit :

Seuls les british ont en charge une partie du développement du moteur.

Ils ont eu des parties du moteur en plus du moteur alternatif R&R qui a été annulé ? Peut être que tu devrais me répondre sur le fil F35 pour qu'on ne parte pas en HS sur celui ci ?

Modifié le 13 février 2017 par rendbo

[bubzy]

la partie qui concerne le décollage vertical du F-35B principalement, et une part sur le reste du moteur.

https://en.wikipedia.org/wiki/Rolls-Royce_LiftSystem

Sinon, @Picdelamirand-oil peut certainement confirmer le fait que personne d'autre que les américains ne travaillent sur le logiciel embarqué du F-35 (en dehors des israéliens peut être)

[Picdelamirand-oil]

il y a 42 minutes, bubzy a dit :

la partie qui concerne le décollage vertical du F-35B principalement, et une part sur le reste du moteur.

https://en.wikipedia.org/wiki/Rolls-Royce_LiftSystem

Sinon, @Picdelamirand-oil peut certainement confirmer le fait que personne d'autre que les américains ne travaillent sur le logiciel embarqué du F-35 (en dehors des israéliens peut être)

Les British (BAE) développe le sous système de guerre électronique.

Le Tuning du modèle

Cette valeur de plus de 20000 personnes montre que l'on a dépassé le domaine de validité du modèle COCOMO, et qu'en fait il n'existe pas de projet de 24000 KLOCS. Bien sur on peut produire 24000 KLOCS mais c'est plusieurs projets.

Dans notre cas relatif au F-35 on a 8000 ou 10000 KLOCS embarqués dans l'avion et 14000 KLOCS pour des programmes qui restent au sol dont la fameux système de maintenance intégré ALIS. Ces deux valeurs, pour le système embarqué, sont simplement dues à l'évolution de la taille du logiciel avec le temps. On prendra donc 10000 KLOCS qui est la valeur la plus récente.

Pour moi cela fait au moins deux projets, qui n'ont pas forcément commencé au même instant et qui peuvent avoir des caractéristiques de complexité différentes.

Par exemple les essais du système embarqué seront beaucoup plus long, je l'ai déjà dit et COCOMO n'est pas adapté pour évaluer la durée de test de ce type de système. COCOMO donnera la durée pour avoir un système qui tourne de façon satisfaisante au banc d'essai, car jusqu'à ce point le système embarqué ressemble à un système informatique classique, complexe mais classique.

Mais il faut rajouter les essais en vol, c'est-à-dire soumettre le matériel à des contraintes supplémentaires et vérifier qu'il marche encore et que quand il ne marche plus qu'il ne se passe rien de catastrophique.

L'expérience montre que les essais en vol sont très lent et très coûteux car chaque essais nécessite un vol (parfois plusieurs lorsqu'il faut tester des configurations différentes). Il faut compter que pour les essais en vol il faut rajouter le même temps que les essais d'intégration évalués par COCOMO.

Maintenant on va recalculer M de façon plus réaliste: dans les modèles simplifiés M vaut 1 et mon choix de caractéristique nous a amené à des coefficients dont la multiplication donne 8.854. Il y a donc matière à réduire cette valeur. Mais il y a des caractéristiques auxquelles on ne peut rien, si le projet est complexe, on ne peut pas dire on va faire un avion plus simple (peut-être qu'on devrait mais c'est hors sujet) par contre il y a des caractéristiques sur lesquelles on a une certaine latitude, ce sont:

Personnel

o   ECAP: Aptitude de l'équipe

o   AEXP: Expérience du domaine

o   VEXP: Expérience de la machine virtuelle

o   LEXP: Maîtrise du langage

Projet

o   MODP: Pratique de développement évoluées

o   TOOL: Utilisation d'outils logiciels

On va remettre ces coefficients à 1 mais cela veut dire que le chef de projet devra être attentif à ne pas avoir de dérive sur les qualités correspondantes de son projet, même si ça coûte cher.

On trouve alors M = 5.50 qui multiplié par 2.6 donne 14.3. L'effort pour le système embarqué est alors 1561964 mois homme et la durée 208 mois mais comme il faut rajouter les essais en vol soit à peu près un tiers de la durée totale du projet cela fait une durée totale de 300 mois ce qui donne une équipe moyenne de 5200 personnes.

Bodgan nous a appris qu'ils travaillaient en 3 X 8 donc cela correspond à 1250 postes de travail utilisés en 3 X 8.

Avec ce réglage le développement dure 25 ans et se termine en 2026. La productivité est de 184 lignes de code par an seulement alors que dans mon article cité au début du sujet je proposais 250 lignes (à l'intuition). Mais j'avais peut-être raison car le développement envisagé dans cet article était plutôt une combinaison de projets correspondants aux gros modules que j'avais définis qu'un seul grand projet.

Les logiciels non embarqués sont plus volumineux, mais moins complexes, et doivent pouvoir être partagés en plusieurs projets, et donc ils ne sont normalement pas sur le chemin critique. Toutefois pour ALIS il semble que le JPO se soit fait surprendre.

En ce qui concerne l'exposant 0.31, mon intention initiale était de montrer qu'on pouvait le calculer et tenter de le ramener à 0.29. Mais cela raccourcirait la durée du projet et donc cela augmenterait la taille de l'équipe, je ne pense pas que ce soit pertinent. Cette contrainte de taille de l'équipe est peut-être une explication plausible du fait que j'estime que le projet se terminera en 2031 en effet si l'on rajoute 60 mois à la durée du projet la taille moyenne de l'équipe devient 4340 au lieu de 5200 et c'est toujours ça de gagné. Et si on dit que l'on a organisé le travail de façon à avoir une productivité de 250 lignes par an au lieu de 184, en scindant le projet en modules, la taille de l'équipe tombe à 3190.

C'est beaucoup mais c'est mieux que 22000!

[rendbo]

il y a 18 minutes, Picdelamirand-oil a dit :

Mais il faut rajouter les essais en vol, c'est-à-dire soumettre le matériel à des contraintes supplémentaires et vérifier qu'il marche encore et que quand il ne marche plus qu'il ne se passe rien de catastrophique.

Je ne comprends pas ce point : le hardware est soumis aux contraintes, pas le code (qui ne fera pas tomber par inadvertance quelques bits par ci par là à 9g ).

Tester du hard ne peut il pas se faire sur un banc dynamique à part, et le test du code lui se ferait en simulateur ? Ensuite seulement on valide le modèle par un essai en vol "simple"...

[Picdelamirand-oil]

à l’instant, rendbo a dit :

Je ne comprends pas ce point : le hardware est soumis aux contraintes, pas le code (qui ne fera pas tomber par inadvertance quelques bits par ci par là à 9g ).

Tester du hard ne peut il pas se faire sur un banc dynamique à part, et le test du code lui se ferait en simulateur ? Ensuite seulement on valide le modèle par un essai en vol "simple"...

Dans des essais au banc il y a beaucoup de simulations et de stimulation pour faire croire au logiciel opérationnel qu'on vole, de même l'environnement est simulé aussi. Les dynamiques de la simulation ressemble beaucoup à celle d'un vrai vol mais ne sont pas tout à fait identique. Il est possible qu'en vol l'ordre de traitement des tâches ne soit pas le même à cause de ces différences de dynamique et qu'un bug qui était "dormant" au banc devienne "actif" de ce fait. Ce n'est qu'un exemple.

[bubzy]

Il y a 21 heures, Picdelamirand-oil a dit :

Les British (BAE) développe le sous système de guerre électronique.

 

Si je ne me trompe pas, c'est BAE Systems Inc. la filliale américaine de BAE qui s'occupe de ça. Autrement dit même s'il y a "british" dans le nom et qu'une partie des capitaux appartiennent aux anglais, c'est une entreprise américaine qui développe ça. ça n'est pas du boulot pour les britanniques assimilable à une forme de retour sur investissement.

[Picdelamirand-oil]

La taille du logiciel

Quelles leçons tirer de cette présentation de COCOMO?

D'abord que ce modèle n'est pas adapté pour traiter les logiciels d'un projet tel que le F-35. Ou plutôt qu'il nous faut des précisions supplémentaires pour pouvoir le traiter, précisions permettant de considérer plusieurs sous projets ayant des caractéristiques différentes et permettant de considérer un ordonnancement entre ces sous projets afin de pouvoir estimer une durée totale réaliste.

Mais l'exercice nous a quand même permis de sentir que plus le projet était de grande taille et plus l'expérience de l'équipe et l'utilisation d'outil logiciel et de méthodes avancées avait de l'importance pour réduire l'effort et la durée. Ce sont en effet ces facteurs qui nous ont permis de réduire le coefficient M.

Quelqu’un de très compétent écrira souvent moins de lignes de code qu’un autre car il emploiera des méthodes de designs créées pour en réduire la quantité ce qui augmente la lisibilité et la maintenabilité. De plus, il exploitera beaucoup mieux les fonctionnalités proposées par les outils utilisés. En effet, beaucoup de programmeurs, qui ne connaissent pas suffisamment ces outils, réécrivent des fonctionnalités existantes, ce qui augmente le nombre de lignes de code.

Lorsque je préconise de limiter la taille du logiciel, il ne s'agit donc pas de donner des consignes individuelles et d'en faire un indicateur pour évaluer les performances des employés. Il s'agit de créer un état d'esprit pour que chacun dans l'équipe partage des bonnes pratiques avec les autres dans le but de réduire la taille du logiciel. Ce n'est pas la taille du logiciel en soit qui compte (quoi que) mais les bons comportements qui sont induits par sa considération.

[TarpTent]

Le 13/02/2017 à 10:14, bubzy a dit :

Il ne me semble pas que les pays partenaires soient en charge du développement de l'avion. De systèmes périphériques oui, qu'ils ont obtenu comme compensation, mais qui sont toujours attendu. Seuls les british ont en charge une partie du développement du moteur. 

Pour tout ce qui est software, c'est uniquement US pour l'instant. Et pourquoi pas israélien puis qu'ils auraient la main sur la partie guerre électronique.

Certes, ils ne développent pas, mais Chris Bogdan notamment lors d'une intervention devant le congrès mi-2015 de mémoire, indiquait clairement que les USA s'étaient engagés à intégrer certains vecteurs indigènes, ainsi que d'autres demandes spécifiques des pays partie-prenante du Programme (et lors de cette interview, il précisait justement qu'il convenait de revoir un peu cette liste à la Prévert, certaines demandes étant farfelues ou peu raisonnables).

 

Quoi qu'il en soit, c'est bien l'intégration d'une partie de ces demandes spécifiques, donc non standard, en parallèle du développement normal de l'appareil et du débuggage de son logiciel qui rajoute forcément une surcouche de complexité et de source de dysfonctionnements, et qui pèse nécessairement aussi sur l'ensemble du Programme.

[Hilariovespasio]

Le genre de topic que beaucoup vont lire que peu vont comprendre... mais qui à la fin je suis sur va tous nous mettre d'accord.

Je lis avec un mélange d'ignorance, et d'énorme vide sidéral entre mes deux oreilles. Mais je savoure et j'admire la connaissance technique de certains d'entre nous.

[TarpTent]

@Picdelamirand-oil , merci beaucoup en tout cas d'avoir pris le temps de faire ces nombreux posts, très éclairants, sur la méthode Cocomo et cet exercice d'application au projet F35.

Je ne peux m'empêcher de me demander quel aurait également été l'impact notamment sur ECAP, AEXP, VEXP et LEXP si c'étaient les équipes en charge du F22 qui avaient pris le sujet F35. (Je me doute que la réflexion est pour partie foireuse, puisqu'entre autres les langages et les archi retenues ne sont pas les mêmes).

 

Bref, dans tous les cas, ils ne sont pas sortis de l'auberge, et les fils de discussion sur le F35 ne sont pas près de se tarir 

[prof.566]

1 hour ago, TarpTent said:

Certes, ils ne développent pas, mais Chris Bogdan notamment lors d'une intervention devant le congrès mi-2015 de mémoire, indiquait clairement que les USA s'étaient engagés à intégrer certains vecteurs indigènes, ainsi que d'autres demandes spécifiques des pays partie-prenante du Programme (et lors de cette interview, il précisait justement qu'il convenait de revoir un peu cette liste à la Prévert, certaines demandes étant farfelues ou peu raisonnables).

 

Quoi qu'il en soit, c'est bien l'intégration d'une partie de ces demandes spécifiques, donc non standard, en parallèle du développement normal de l'appareil et du débuggage de son logiciel qui rajoute forcément une surcouche de complexité et de source de dysfonctionnements, et qui pèse nécessairement aussi sur l'ensemble du Programme.

D'un autre coté ils peuvent aider. Lez "mission data loads" US ne seront jamais prêts dans les temps pour l'évaluation test. Qui risque du coup de se dérouler avec des données destinées à des pays clients.... Enfin ca c'est le cas optimiste ou le pod de restitution serait mis au point/commandé d'ici le mois d'aout et ou les avions appareillés pour les tests auront subis 155 modifications indispensables pour représenter un avion de production...