Picdelamirand-oil

Il est classifié, il n'en existe que des extraits non classifiés et l'origine de ces extraits est universitaire.

Pour moi c'est un rapport parmi d'autres, car il ne fait pas parti des documents officiels du programme. J'admet volontier que les informations de L.M. sont sujette à caution. Mais L'ORD n'est pas un document L.M. c'est un document contractuel qui résulte de l'accord de deux parties, dans le cas du F-35 de 4 parties L.M. en tant que maître d'oeuvre, L'USAF, la Navy et l'USMC. Il ne s'agit pas d'annonces et promesses, mais d'engagement contractuel.

Cela sert à réaliser des bagues d'extrémité de turbo-alternateur. Le diamètre de la bague d'extrémité d'un turbo-alternateur peut être comprise entre 0,5 et 1,6 mètres. L'anneau d'extrémité doit passer des tests rigoureux pour s'assurer qu'il peut fonctionner sans déformation à des vitesses allant de 3 000 à 3 600 révolutions par minute. Un essai de survitesse de 20% est également conduit avant que les bagues d'extrémité ne soient validées pour être utilisées. L'acier inoxydable non magnétique réduit les pertes dans l'anneau qui sont causés par des courants de Foucault et les contraintes thermiques. L'acier possède également un rendement élevé pour éviter les déformations plastiques qui sont dues aux contraintes élevées produites par les forces centrifuges

Tu as peut être l'impression d'avoir démontré cela, mais pour moi tu n'as rien démontré du tout car les perfos actuelles de l'avion ont été réduites plusieurs fois par rapport à l'ORD initial. Pour faire ta demonstration tu te réfère à une étude que tu as trouvée mais qui n'est en aucun cas une expression de besoin officielle. Donc c'est normal qu'on dise que les performances ne sont pas satisfaisantes, ceux qui disent le contraire sont endoctrinés.

Sans ses becs de bord d'attaque?

Pour ce qui est d'ALIS qui est le principal système au sol ayant du développement logiciel le paragraphe est page 51 et la traduction est celle ci: Système d'information logistique autonome Le programme n'a pas réussi à livrer de nouvelles fonctionnalités ALIS en 2016, mais a mis à jour par deux fois le logiciel ALIS 2.0.1, actuellement en place, pour combler les anomalies et les lacunes en matière d'utilisation. Le programme prévoyait de tester et de mettre en production ALIS 2.0.2, y compris l'intégration de la gestion des données de propulsion, au cours de l'été 2016, dans le cadre de la déclaration de la capacité opérationnelle initiale de la Force aérienne; Cependant, les retards dans le développement et l'intégration ont repoussé les tests et le déploiement en 2017. En raison des retards d' ALIS 2.0.2, Lockheed Martin a réaffecté du personnel pour soutenir le développement de ce produit. Cela a causé des retards dans le calendrier de développement d'ALIS 3.0, la dernière version majeure du logiciel SDD. Le programme a reconnu en août 2016 qu'il ne pouvait pas suivre le calendrier ALIS 3.0 et a élaboré des plans pour restructurer cette version d'ALIS et les capacités restantes d'ALIS 3.0 dans plusieurs versions, dont certaines qui seront produites après l'achèvement du SDD. La restructuration du programme ALIS a répartis les capacités prévues et les mises à jour de sécurité pour ALIS dans quatre versions: une version pour SDD (ALIS 3.0), avec ce que le bureau de programme considérait comme nécessaire pour l'IOT&E et trois versions de logiciel supplémentaires destinées à être mises en service à intervalles de 6 mois après la fin de SDD, avec le reste du contenu initialement prévu pour ALIS 3.0. Le programme prévoit de livrer des mises à jour de maintenance de ces logiciels entre chacune de ces quatre versions de logiciel pour corriger les anomalies et les problèmes d'utilisation, mais ces versions ne comprendront pas de nouvelles fonctionnalités. L'Armée de l'Air a terminé son premier déploiement d'avions F-35A en utilisant la version modulaire du matériel de l'escadron ALIS, appelée Standard Operating Unit Version 2 (SOU v2) et la version 2.0.1 à Mountain Home AFB, Idaho en février 2016. Les difficultés pendant l'intégration de la SOU v2 dans le réseau de la base ont créé des interférences avec la connectivité entre les stations de travail de Mountain Home et la SOU v2, mais n'ont pas affecté la connectivité de la SOU v2 avec l'unité logistique autonome principale (ALOU) de Fort Worth au Texas.

Un mec sur la base.

J'ai traduit la partie "test des systèmes de mission" du rapport annuel du DTOE page 47 et 48 car cela concerne essentiellement le logiciel embarqué du programme F-35 et permet d'évaluer où on en est du développement. Test des systèmes de mission Le programme poursuit un plan axé sur les coûts et le planning pour supprimer des points planifiés de test du système de mission en utilisant d'autres données d'essai pour atteindre les objectifs de ces points d'essai afin d'accélérer la fin de la phase de développement. Ce plan, s'il n'est pas correctement exécuté avec les données pertinentes, une rigueur analytique et une confiance statistique suffisante, reporterait des risques importants sur les tests opérationnels, les modernisations ultérieures, et les pilotes au combat Cette approche risquée permet également de rejeter les essais planifiés soigneusement contenus dans le plan directeur d'essai et d'évaluation (TEMP) et le plan d'essai conjoint du bloc 3F (JTP), contenu que la direction de programme a jugé nécessaire lorsque ces documents ont été signés. Le programme envisage de "mettre en quarantaine" les points du JTP, dont les vols sont prévus par les centres de test, et plutôt de sauter à des points de test complexes, de réduction de risque pour l'efficacité des missions, récemment mis au point, pour échantillonner rapidement la performance complète du bloc 3F. Ensuite, si l'une des fonctionnalités du bloc 3F semble fonctionner correctement au cours des points de test complexes, le programme pourra supprimer les points du JTP sous-jacents à ces capacités et les désigner comme "non nécessaires". Toutefois, le programme doit veiller à ce que les données de substitution soient applicables et à ce qu'elles fournissent une validation statistique suffisante pour que les objectifs du point de test aient été atteints avant de supprimer les points de test sous-jacents. Bien que cette approche puisse fournir une évaluation rapide de l'échantillonnage des capacités du bloc 3F, il existe des risques importants. Les versions récentes du logiciel pour le test en vol sont nombreuses et cela peut empêcher le programme d'utiliser des données provenant de ces versions pour valider les suppressions de point de test, car elles peuvent ne plus être représentatives du bloc 3F. La disponibilité limitée et le coût élevé des campagnes de tests au Western Test Range (WTR), combiné à des taux élevés de répétition de vol pour les tests effectués au WTR, rendent difficile pour le programme de conduire efficacement ces tests. Enfin, les capacités les plus complexes du bloc 3F ont seulement récemment atteint un niveau de maturité qui permet de les tester, et ce sont aussi des points de test parmi les plus difficiles à exécuter (c'est-à-dire l'ensemble des capacités du bloc 3F et le domaine de vol). Jusqu'à une date récente, le Bureau du Programme estimait que les essais en vol des systèmes de mission se termineraient en octobre 2017. Il reconnaît maintenant le risque que ces essais s'étendent au début de la CY18. L'estimation d'octobre 2017 était basée sur un taux de réalisation des tests gonflé et sur des taux de correction et de répétition des tests optimistes. L'estimation a également supposé que le bloc 3FR6, livré aux essais en vol en décembre 2016, aurait la maturité nécessaire pour compléter les tests restants et satisfaire aux exigences des spécifications sans exiger des versions supplémentaires de logiciels pour combler des lacunes Cependant, cela est hautement improbable, car plusieurs capacités essentielles - y compris les tirs au canon et l'infrastructure air-air du WTR - n'avaient pas encore fait l'objet d'essais en vol ou ne fonctionnaient pas correctement lorsque le bloc 3FR6 a été fournis. Les Services ont classé 276 anomalies relatives aux performances au combat comme étant "critiques" et devant être corrigées dans le bloc 3F, mais moins de la moitié de ces anomalies ont benéficié de tentatives de correction dans 3FR6.

C'est vrai que les Block 2B; 3F désignent des versions logicielles principalement, mais pas que, parce que c'est devenu des jalons pour les autres modifications aussi dont des modifications matérielles et structurelles. Donc il faudra plus de 155 modifications matérielles et structurelles pour mettre à niveau les F-35 déjà construits,....sinon on parlerait de milliers d'anomalies....

Oui 155... en fait on s'y perd un peu dans les modifications indispensables, parce que il y a de la triche. Par exemple pour assurer l'IOC du F-35B ils avaient repoussés la correction de 800 anomalies à plus tard, dont certaines après le block 3F. Donc elles sont arbitrairement "pas indispensables" et puis ils ont réduit la fréquence des plantages dues à la désynchronisation entre le Radar et le reste du système mais normalement il faudrait trouver une vraie solution à ce problème, mais ils semblent se contenter de la situation actuelle. Et puis ils découvrent 20 nouvelles anomalies par mois et pour que les tests convergent ils décident de ne pas en corriger 61% parce qu'ils savent qu'ils ne pourraient pas tout corriger pour la date prévue de l'IOC de la Navy. Donc combien d'anomalies seront à corriger sur les avions déjà construits?...MYSTERE.

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.

Ils veulent former des pilotes de Rafale et quand ils les auront formés ils nous commanderont 100 Rafale

Le métier d'acheteur chez Dassault http://www.dassault-aviation.tv/acheteur-1483-fr.html

Je suis trop vieux

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.

Où on voit qu'il n'y a pas que le logiciel opérationnel à développer.

En suivant ton lien je tombe sur un poste de métallurgiste??!!!

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!

Sa mère elle était morte, mais enfin si elle avait le pouvoir d'arrêter la vente des Typhoon ça me va.

Il y a plus d'une dizaine d'année (je ne me rappelle plus) la Grèce envisageait d'acheter des Typhoon. J'avais mon copain grec à coté de moi (grande famille, très riche etc...) et on voit ça aux infos. Je lui dis qu'est-ce que c'est que cette histoire, si la Grèce veut des avions il faut qu'elle achète le Rafale. Mon copain me répond: "je téléphone au ministre de la défense et je l'engueule", et je le vois téléphoner devant moi! Il s'ensuit une discussion en Grec, assez animée, mais c'est toujours le cas entre les grecs, ça veut rien dire, et mon copain raccroche et me dit "non, non on achètera pas des Typhoon, on fait semblant, le jour où ce sera sérieux c'est promis on regardera d'abord le Rafale".

C'est pas faux.

Au fait un moineau c'est le même niveau de furtivité qu'un F-22... mais c'est lisse et le Rafale n'a pas de soute.

Il semble que les Indiens ne peuvent pas s'empêcher de faire fuiter de l'information Traduction L'Air Marshal Deo a déclaré que le gouvernement indien est également saisi de l'importance de l'acquisition d'avions de chasse avec des caractéristiques de furtivité et c'est la raison pour laquelle l'avion Rafale acquis depuis la France a quelques caractéristiques de furtivité spéciales. «La RCS de l'avion est nettement plus petite pour un avion de cette taille. Il y a beaucoup d'autres fonctionnalités aussi que je ne voudrais pas divulguer à ce stade ", a t-il dit. http://indianexpress.com/article/india/india-news-india/china-j20-stealth-fighter-rafale-indian-air-force-3737350/

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.

Moi je suis d'accord pour que les Russes les envoie promener.