Richard RUTILY
24/03/2012
Je voudrais faire partager, modestement parce que ce n’est pas facile, quelques réflexions et calculs de coin de table pour illustrer la difficulté de produire et de tester un logiciel complexe et temps réel de grande dimension. On fera d’abord l’hypothèse que les techniciens américains ont bien fait leur travail, c’est-à-dire que le désordre dont est victime le programme JSF ne s’est pas propagé jusqu’à leur niveau.
Une première difficulté vient de l’impossibilité d’augmenter indéfiniment la taille des équipes logicielles. Ce point est illustré dans “Les paradoxes de la productivité dans la production des logiciels” de François Horn (http://clerse.univ-lille1.fr/IMG/pdf/pardoxe_productivite_logiciel.pdf) :
“les mois et les hommes ne sont interchangeables que lorsqu’une tâche peut être divisée entre plusieurs travailleurs sans réclamer de communication entre eux”
et
“si n taches doivent être séparément coordonnées avec chaque autre tâche, l’effort augmente en n(n-1)/2 (idem, p. 15). Dans des situations extrêmes ces activités supplémentaires font plus que compenser l’apport de travailleurs supplémentaires”
Pour contourner cette difficulté le même document donne une solution qui consiste à effectuer un important travail préalable au niveau de l’architecture du système pour le décomposer en modules plus petits qui doivent avoir une indépendance maximale. Il va donc falloir faire des hypothèses sur la modularité du logiciel pour tenter d’en estimer la difficulté de réalisation et surtout de test.
Pour ce faire on peut estimer le nombre de calculateurs du système d’arme (c’est un premier niveau de modularité), la taille probable des équipes et la complexité probable du calculateur tactique (ou calculateur de mission c’est-à-dire celui qui coordonne tous les équipements). Pour les estimations on doit utiliser des ratios en lignes de code, bien que ce soit criticable, car c’est la seule donnée d’entrée dont on dispose.
Je pense qu’un tel système d’arme comporte au minimum 100 calculateurs et plus probablement 200. Pour ce qui est de la taille des équipes on peut tabler sur 10 à 20 personnes travaillant pendant 10 ans. Comme on est dans un projet complexe la productivité est réduite à 250 lignes de code par an et par personne en considérant les moyens totaux consacrés en un an au logiciel par le projet, y compris le logiciel abandonné, tous les développements, les tests sur les bancs de tests, les améliorations et toute la maintenance.
Une équipe produit en moyenne un “module” de 40 000 lignes de code. Pour un logiciel d’une taille de 24 millions de lignes cela fait 600 “Modules” soit en moyenne 3 à 6 par calculateurs.
Mais le calculateur tactique doit faire de l’ordre de un million de lignes c’est-à-dire 25 “modules” ces modules sont sans doutes de grandes fonctions comme missiles air-air, missiles air-sol, suivi de terrain, radar, contre mesures, navigation etc
L’intégration des ce type de fonction à un niveau élémentaire peut se faire au banc mais l’intégration finale se fait obligatoirement en vol et là c’est très long car tous les autres modules doivent être présents et à un niveau de mise au point acceptable et qu’il faut tester un grand nombre de configurations différentes (c’est un avion multi rôles) et même le faire sur trois avions différents (versions A, B et C).
Lorsqu’on a 600 modules à réaliser avec chacun un planning de 10 ans et que parmi ces 600 modules 25 dépendent de tous les autres pour leur mise au point, il ne faut pas espérer tenir le planning. Même en supposant que des tests peuvent commencer sans que tout soit disponible, il me semble raisonnable de compter 15 ans pour la disponibilité complète des 600 modules, 5 ans pour les tests au banc et 10 ans pour les essais en vol ce qui fait 30 ans si tout le monde a bien fait son travail.
Pour l’instant les essais en vol qui ont eu lieu ne concernent que l’avion lui-même mais pas le logiciel de mission et j’ai entendu dire que les plans de Lockheed n’étaient de tester que 17% des fonctions logicielles du calculateur de mission en vol.
Jean-Paul Baquiast
24/03/2012
Une nouvelle fois, j’admire que Philippe Grasset ait dès le début été clairvoyant sur le JSF . Les évènements lui ont toujours donné raison. Cela continue.
Combien en France peuvent se vanter de cela? Sans doute parce
que les Français sont encore incapable de sortir de ce que Immarigeon appelle dans son dernier livre la Françamérique
b r
25/03/2012
On parle de plus en plus du JSF un peu partout, que ce passe-t-il pour qu’il sorte ainsi de son anonymat ?
Ici des membres de commission parlementaire qui ne savent pas de quoi l’ordre du jour est fait mais au moins ils sont là...
http://battleland.blogs.time.com/2012/03/23/oversight-oversight/
Le CDI s’y met aussi
http://www.cdi.org/program/document.cfm?DocumentID=4729&from_page=../index.cfm
Merci Richard pour ces quelques réalités du génie lociciel actuel.
Il convient de se rappeler qu’environ un tiers des projets informatiques finissent à la poubelle et ce dans des conditions où les autres industries y mettrait la moitié.
Qui se souvient du projet JASF (il était alors Advanced ...) en 1998 à 22 millions de $ l’appareil?
Aujourd’hui il semblera atteindre au minimum 10 fois le prix du catalogue LM 98 ...
Morbihan
28/03/2012
... Le KC-46 suivrait-il la même pente?
http://www.20minutes.fr/ledirect/905725/risque-retard-tanker-kc-46-boeing
Morbihan
28/03/2012
Pour conforter ce qu’écrit M. Richard RUTILY, on considérait, de mon temps, qu’un développeur pouvait mettre au point (écriture, tests unitaires, intégration a minima) 1 000 lignes de code par mois, ceci alors que le développeur avait une - petite - visibilité sur la finalité de son travail, ce qui n’est plus le cas. Ceci en ne comptant pas les charges de pilotage, de coordination et de tests d’intégration, ces derniers représentant à eux seuls de l’ordre de 40% de la charge totale… et étant souvent bâclés pour “respecter les délais”.
Selon ces abaques, cela représente 24 000 mois/homme pour uniquement développer les lignes de code. Plus le pilotage et l’intégration. Avec les découvertes - les déconvenues - à chaque coin de rue. D’où le choix de faire des impasses. Sans commentaire.
Bon courage au directeur de ce projet…
Richard RUTILY
29/03/2012
Bonjour Morbihan
Mon taux de 250 lignes par an peut sembler un peu faible, mais c’est un taux qui ne compte que le logiciel embarqué, puisque j’imagine que la taille du logiciel dont on parle est celle de celui-ci.
Or pour le mettre au point il faut développer d’autres logiciels : on commence par faire un logiciel qui teste les interfaces, pour cela le calculateur tactique envoie les messages élémentaires relatifs à un équipement et vérifie que les réponses correspondent à ce qui est attendu. Ce programme doit être aussi simple que possible pour que sa mise au point soit facile, il est statique et ne teste que les échanges (en général sur un bus).
Il faut ensuite faire une simulation numérique de chaque équipement (on peut utiliser le programme de test des interfaces pour un premier niveau de mise au point) ces simulations serviront à l’évaluation validation du logiciel tactique. Il faut ensuite faire des programmes de stimulation des équipements : par exemple si on a une centrale à inertie il faut remplacer les accéléromètres et les gyros par des stimulations calculées par le calculateur de simulation, les injecter dans une centrale réelle branchée sur le bus afin de pouvoir tester l’intégration de celle ci au banc.
Il faut enfin faire une simulation générale qui produit des thèmes d’exercice et qui coordonne l’environnement général avec la simulation (ou la stimulation) de tous les équipements du système d’arme.
Sur ce banc les tests d’intégration vont beaucoup plus vite qu’en vol: on peut par exemple pour tester un module faire varier les configurations par software alors qu’en vol chaque configuration représente un vol différent. En plus sur le banc on peut tester les réactions du système d’arme aux différentes pannes des équipements.
Il y aurait encore beaucoup à dire mais cela permet déjà de se rendre compte du volume de travail nécessaire pour mettre au point un “module”.
Richard RUTILY
29/03/2012
En plus il faut faire une ségrégation entre le logiciel “critique” et le logiciel normal car si le module “navigation” plante il n’est pas question que les commandes de vol ne répondent plus.
Il est bien évident que le logiciel critique demande plus de travail et de tests que le logiciel normal.
Olivier_47
31/03/2012
Bonsoir M. Grasset,
Je vous propose, et aussi à la communauté DeDefensa, d’écouter le discours de JL Mélanchon sans lequel il exprime ses positions et sa vision géostratégique du monde :
A ma connaissance, et à ce jour, c’est le seul candidat qui se soit livré à cet exercice. J’ai trouvé ce discours passionnant et en complète phase avec avec ce que vous exposez dans ce blog.
J’en profite pour vous remercier du formidable travail d’éclairage que vous menez, jour après jour, et qui rend cet endroit indispensable à qui veut tenter de comprendre notre - pauvre - monde.
-
Pour poster un commentaire, vous devez vous identifier