Picdelamirand-oil

Ça dépend aussi du modèle de l'avion https://warisboring.com/how-much-does-an-f-35-actually-cost-21f95d239398#.y6vzdupcc

Pour du "Restricted" les règles de gestion de l'information sont beaucoup moins contraignantes que pour des niveaux plus élevés de classification. Par exemple on a pas besoin d'une habilitation, mais juste le besoin d'en connaître. De même on a le droit de copier ces informations sur un media crypté et protégé par un mot de passe avec une sécurité sérieuse. On peut même installer ces données sur le serveur d'un partenaire qui a signé un Non Disclosure Agreement. Ensuite si le partenaire diffuse cette information on lui fait un procès. Je pense que c'est ce que DCNS est en train de faire.

Le prix baisse de 3 à 4% à chaque nouveau LRIP. L'objectif affiché est $ 85 Millions Fly away en 2019. Pour y arriver L.M. avait imaginé un "Block buy" qui permettait de commander plus d'avion en même temps et donc de baisser les coûts du fait de la production massive. Les investissements pour être capable de cettte production de masse ont été fait par L.M. en avance de phase sur fond propre. Dans le même temps ils essayaient d'avoir la commande des LRIP 9 et 10 en même temps et un an en avance. Problèmes: les LRIP 9 et 10 n'ont pas été commandés et ont plutôt un an de retard déjà au lieu d'un an d'avance. L.M. s'est donc trouvé à court de cash et a bénéficié d'une avance de 1 milliard de $. On comprend que les US hésitent à commander en masse un avion dont les tests ne sont pas finis. Les rumeurs disent qu'il n'y aura plus de commande tant que le Block 3F n'aura pas été validé.

Je rapelle que Pete Collins s'est adressé à nous depuis la maison de Prof où il était reçu, le 21 septembre 2013 (page 769 de ce sujet), C'est bien triste pour tout le monde.

un peu plus que 7%

Je tente une réponse: Les avions militaires, comme les Mirage et le Rafale, ne sont pas un marché, sauf peut être pour les américains. Par contre c'est une activité stratégique, au sens militaire du terme et au sens économique. Une étude a été faite sur les technologies que devait maîtriser la France pour assurer son avenir, et sur les 22 technologies nécessaires il y en avait 17 que le programme Rafale permettait de développer. A partir de là l'activité militaire de Dassault est entièrement financée par l'état. Celui ci contrôle même que Dassault ne fait pas trop de bénéfice sur son dos et autorise une marge de 7/93. Ceci est complètement différent de l'activité Falcon où Dassault est bien sur un marché et finance lui même les développements. La dessus il s'est trouvé que les spécifications Françaises du Rafale étaient un peu minimaliste pour l rendre attrayant à l'export, un accord a été trouvé avec l'état, pour rendre le Rafale plus ambitieux, sachant que Dassault, Thales, et Safran payaient 25% des développements. L'idée c'est que ces trois sociétés se rembourseraient ces 25% de développement sur les ventes exports puisque c'était pour l'export que l'on avait bousté les specs du Rafale. Mais c'est difficile à mettre en oeuvre quand il n'y a pas trop d'export ou quand un client tel l'Inde exige de payer le même prix que l'armée de l'air française! D'ou assez souvent la question de savoir qui doit payer.

C'est des roquettes "quantique" qui peuvent passer à travers la soute.

Oui mais le PAK FA n'a peut être pas encore son cockpit définitif

Oui, on peut aussi dire que cela fait un Rafale. Et puis c'est peut -être vexant de considerer que la signature de l'Inde présente un risque qu'il faut assurer.

Si € 134 Millions font 2% du contrat, c'est que celui ci fait € 6.7 Milliards

Tu vois tu arrive à faire des comparaisons entre le Rafale et le F-35 et même à en déduire quel programme doit être le plus gros.

Là tu fais ton Dany 40 pour l'A 400.

Pour ceux qui veulent se faire une idée de l'état du système F-35 un document intéressant: STATEMENT BY J. MICHAEL GILMORE DIRECTOR, OPERATIONAL TEST AND EVALUATION OFFICE OF THE SECRETARY OF DEFENSE BEFORE THE SENATE ARMED SERVICES COMMITTEE NOT FOR PUBLIC RELEASE http://www.armed-services.senate.gov/imo/media/doc/Gilmore_04-26-16.pdf Et un extrait intéressant car c'est une synthèse: Et je tente une traduction: Le programme continue de supporter la lourde charge que représente la dette technique du fait des lacunes ouvertes et non résolus. À la fin de Mars 2016, le programme a eu 1165 carences documentées et ouvertes, dont 151 étaient de catégorie 1, définis comme des déficiences qui peuvent entraîner la mort, des blessures graves, ou une maladie grave; qui peuvent entraîner une perte ou des dommages importants à un système d'arme ou restreindre gravement les capacités de l'aide à la préparation au combat de l'utilisateur; ou entraîner un arrêt de la ligne de production. Sur les 151 déficiences de Catégorie 1, 128 ont été associés avec l'avion et les 23 autres ont été associés à ALIS ou a un équipement de soutien. En outre, parmi les 151 déficiences ouvertes de Catégorie 1, 95 ont été classées «haute gravité» par le programme ou les services.

Moi je ne parle que du logiciel embarqué dans le F-35. Cela signifie que la partie la plus simple de ce logiciel est beaucoup plus compliquée que ton deuxième exemple. Une mesure grossière de cette complexité est donnée par le taux de production considéré comme normal: 250 lignes par an. Tu dis des trucs qui sont basic dans de tels logiciels (des thread pas à moi qui passent dans mon code n'importe quand, (soft) temps-réel, optimisé à mort, très interactif) et tu signale que tu as du écrire un programme pour valider la faisabilité. Dans mon article je cite un logiciel qui teste les interfaces, une simulation numérique de chaque équipement en cause et des programmes de stimulation des équipements. Chacun de ces programmes est sans doute plus complexe que celui que tu as écrit et il y en a bien d'autre mais qui dépendent du module dont tu es en charge. Bien sûr que le premier problème est la complexité, mais je suis dans un référentiel où la complexité est là de base, parce que j'ai programmé moi même les fonctions acoustique, navigation et armement de l'ATL2 et que je sais évaluer l'effort qu'il faut faire, du point de vue du logiciel quand on liste les grandes fonctions incluses dans le Block 2B du F-35 ou celles du Block 3F, et même je sais dire à peu près la taille que cela doit avoir. Ton exemple d'avion de 10 t trop lourd est complètement idiot, on sait très bien ce que fait un Rafale et on sait évaluer que par rapport à la concurrence il est plus d'une tonne plus léger que les autres ce qui est un exploit. De même on sait ce que fait le système d'arme du F-35 et on sait que par rapport à la concurrence il est 4 fois trop gros, donc demander une diminution dans un rapport au moins 2 n'est pas un scandale.

Je trouve tes avis un peu tranchés: définir les contours des modules que tu vas développer, pour toi, ce n'est pas un problème d'architecture?

Je l'explique un peu: Mais pour aller plus loin je vais me citer: http://www.45enord.ca/2014/05/le-logiciel-du-f-35/ Je pense que ce travail visant à maximiser l'indépendance des modules que l'on crée n'a pas été fait correctement sur le programme F-35 et que cela explique ses déboires: besoin de coordination important ===> raz le bol des équipes qui trouvent qu'on fait de la réunionite au lieu d'avancer ===> réaction d'isolement de certains et duplication du codage de fonctions.

Tu pense qu'on en sait rien et que l'on a pas assez de documentation sur le système pour évaluer sa "taille", et pourtant ,je sais que je peux faire une telle évaluation avec les éléments dont je dispose. Cela ne me pose pas de problèmes si tu ne le crois pas. J'ai seulement dit que les phénomènes que je décrivais commençait à partir du moment où on avait une équipe dont la taille dépassait 1000 développeurs. Il ne faut pas confondre 100 avec 1000 et avec le F-35: quand Bogdan est arrivé, L.M. a ouvert 500 postes de développeurs 24/24 et 7/7. En France il faudrait embaucher 2500 développeurs pour garnir ces postes, aux US peut-être que 2000 suffisent, mais c'était en plus de l'équipe déjà existante. Oui tu utilise des termes plus précis qui correspondent à l'état de l'art du moment, moi je pense qu'on est dans un forum généraliste et que c'est équivalent parce que si ce nombre de fonctionnalités est trop important cela se traduira par une augmentation de la taille du logiciel de toute façon. Après ce que je dénonce n'est pas tout à fait cela. Je dénonce, en fait, un problème d'architecture et de gestion de configuration, c'est à dire l'incapacité où l'on est, à cause du comportement des équipes, à reconnaître qu'on a programmé plusieurs fois la même fonction. Et si on a pas fait de cette fonction un composant géré en configuration, on aura beau avoir la meilleure gestion du monde, le phénomène que je dénonce restera.

Une OPA c'est pas très efficace quand un seul actionnaire a la majorité absolue

Mais quand est-ce que j'ai dit que je voulais forcer les informaticiens à réduire le nombre de lignes? J'ai dit que le logiciel était trop gros: c'est un diagnostique, j'ai repéré un défaut, il faut le corriger. Quand un logiciel est trop gros et qu'il a été produit par une équipe très nombreuse, c'est à dire plus de 1000 développeurs, il est vraisemblable que la même fonction a été programmé plusieurs fois par plusieurs développeurs. Cela peut paraître bizarre mais c'est ce que j'ai constaté. Cela s'explique par le raz le bol des développeurs de passer beaucoup plus de temps à se coordonner qu'à produire. Alors ils essaient d'isoler un morceau de programme où il n'y a pas trop d'interaction avec les autres et pour ce morceau là ils codent tout même si ça crée des duplications. Après en test si un défaut apparaît tu cherche où le corriger, tu trouve, tu fais la correction, tu teste le cas qui avait produit le défaut, ça marche, tu es content, et 2 mois après le défaut réapparaît parce que quelqu'un d'autre avait dupliqué la fonction et a fait la même erreur. Quand c'est une fois de temps en temps ça va, mais quand c'est tout le temps et que tu as l'impression que tu ne va jamais en sortir de cette putain d’erreur qui réapparaît toujours, c'est minant. Alors quand c'est pas une erreur qui a ce comportement mais 100, 200, 300.... c'est l'enfer.

Ecoute tous tes arguments sont bon et valables, et c'est ce que ferait tout bon chef de projet, c'est ce qui est écrit dans les livres et donc c'est sans doute abracadabrandesque de préconiser ce que je préconise. Mais on me demande ce que je ferais moi pour remettre sur pied le programme F-35. On est pas dans un cas classique car il s'agit de moi, et on est pas dans un cas classique car il s'agit du F-35. Alors je dis que son logiciel est trop gros et que c'est par ce bout là que je prendrais le problème.

Tu dis toi même que l'IOC du F-35 est une vaste blague: Alors pourquoi les exercices auxquels le F-35 participe ne seraient-ils pas également une vaste blague? Par exemple ce genre de remarque: ça n'indique pas un souci en terme de capacité opérationnelle? Le rapport DOT&E FY2015 Annual Report peut être téléchargé là: http://www.dote.osd.mil/pub/reports/FY2015/ et ma citation se trouve page 44 à propos de la soute qui doit être ouverte de temps en temps. Mais il y en a bien d'autre si tu veux je peux en mettre 3 pages. (facile à trouver dans un doc de plus de 472 pages. Non ce que fait ce gus ne m'intéresse pas. C'est la taille globale du logiciel qui m'intéresse, je ne peux donner un objectif qu'au chef de projet. Celui ci sait qu'il doit tout ré-écrire et qu'il doit faire attention à la taille du logiciel. C'est un peu comme le devis de masse d'un avion: on lutte sans arrêt pour tenir le devis de masse et ça devient un état d'esprit. Et la taille à considérer n'est pas la taille en ligne de code mais la taille de l'assembleur généré.

Tu crois quand même pas que je vais laisser faire les mecs sans contrôler ce qu'ils font?

ça va prendre combien de temps de le mettre au point? La taille du programme je m'en fiche, mais je suis sûr qu'il est trop gros. En mettant un objectif de taille j'oblige à une modification profonde et j'espère que j'aurais une amélioration de l'architecture en sus.

Moi je pense que je garderais le F-35 B qui améliore quand même les performances du Harrier, et je ferais une sorte de J-31 avec 2 F-414 pour remplacer les F-35 A et F-35 C. Pour le système j'essayerais de finir celui du F-35 en faisant un audit du logiciel et en demandant une ré écriture complète avec pour objectif de diminuer la taille de celui ci dans un rapport au moins 2. La recherche de la diminution de la taille devrait normalement améliorer l'architecture de ce logiciel.

Pour moi tu es un suppôt de Lockhed Martin au sens où tu te laisse facilement avoir par sa propagande. Par exemple tu dis: J'ai déjà parlé de la mise à jour logicielle qui nécessite des changements hardware, mais dire la fusion de donnée aura été optimisé sous entend qu'elle est déjà pas mal et qu'il y a juste quelques paramètres à régler. C'est très important pour ton "concept" de F-35 qu'il y ait une bonne fusion de données capable d'intégrer les mesures diverses et variées de plusieurs capteurs sur plusieurs plate-formes. Or pour l'instant la fusion de données est limité à deux plate-formes, ce qui n'est pas très différent d'une, d'un point de vue système car même sur une plate-forme tu dois intégrer quelques capteurs, et le quelque est à peine augmenté quand tu passe à deux. Par contre si tu peux passer à 5 plate-formes dont un AWACS les choses changent un peu et tu as à résoudre des problèmes d'ambiguïté plus complexes. Le F-35 en est au b-a ba de la fusion, il est vraisemblable que la fusion du Rafale marche mieux que la sienne et on en est au même point, essayant de mettre au point une fusion plus ambitieuse au titre du PEA Tragedac. Par contre L.M. communique sur la fusion du F-35 de manière indécente, comme si c'était déjà au point et comme si c'était une révolution accessible seulement au avion de 5eme génération. Entre parenthèse la fusion de données du Gripen marche et elle est multi-plateformes! Voilà ça ne t'effleure même pas l'esprit que les américains peuvent se planter techniquement. Tout ce que tu peux imaginer c'est qu'ils se soit trompé dans la définition de leur système en faisant des hypothèses sur la guerre du futur qui se révèlent fausses. Or tous les problèmes qu'on nous rapporte sont des plantages techniques. Par exemple pour la maniabilité ses spécifications n'étaient pas ambitieuses, si elles ne l'étaient pas assez ils se sont planté dans la définition du système, mais le problème n'est pas cela, le problème c'est qu'il n'atteint pas les performances déjà peu ambitieuses que l'on s'était fixé. Quand, au vu de cette situation, on décide de changer les spécifications pour faciliter l'acceptation du produit, on a entériné un plantage technique. Et il y a plein de domaine où il y a eu des plantages techniques qui ne sont toujours pas résolus.