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.

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.

Je crois que c'est les deux. Le fond du problème, si ça n'a pas changé, car je ne le suis que de loin en loin, c'est que le T-50 n'a pas encore son moteur définitif, il utilise pour l'instant celui du SU-30. Pour les Russes il y a bien assez à faire pour mettre au point le T-50 tel qu'il est donc ils ne sont pas spécialement pressé de passer au moteur définitif surtout que les Indiens ont contribué assez peu au programme et prennent tous les prétextes pour continuer comme cela. Quand le nerf de la guerre manque, ça va moins vite.

Lune de miel...Cela va être dur de rester le prince charmant... on risque de se transformer en prince marchant. http://indiandefence.com/threads/kaveri-engine-program-news-and-updates.1277/page-31#post-526446 http://indiandefence.com/threads/kaveri-engine-program-news-and-updates.1277/page-31#post-526750 Bon c'est l'enthousiasme.

Traduction Comme je l'ai dit précédemment, les efforts de Safran avec le Kaveri seront le plus grand stimulant imaginables pour les chances du Rafale en Inde. 1)Cela détruit presque complètement la nécessité d'un rival au Rafale (F-16 / Gripen) 2) Cela améliore les obligations de compensation et plait à l'administration, tout en sapant tout autre rival potentiel. D'une pierre deux coups. Lorsque le LCA s'envole avec le Kaveri (grâce à Safran / Rafale) et les améliorations qui en découlent (comme indiqué ci-dessus), je ne vois pas comment même les médias qui se font payer pourraient pousser ouvertement le F-16 / Gripen / F-18. Le Rafale et les Français seront les chouchous de tous les médias indiens! http://indiandefence.com/threads/rafale-deal-signed.56201/page-137#post-526436

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é.

1 milliard de dollars c'est à peu près le prix du standard F3 R ou le prix de 10 Rafale.

Merci pour le transfert aux Modérateurs

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.

Les US sont habitués à ce que rien ne leur résiste. Lorsque le F-16 et le F-18 ont été éliminés de la compétition MMRCA, aux US cela a été la stupeur complète. Cela a tellement été considéré comme un échec que l'ambassadeur des US en Inde a fait ses valises (définitivement). Ce qui montre que l’échec est avant tout considéré comme politique.

Oui si il vend à perte.

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