Picdelamirand-oil

Non c'était sur l'autre fil mais c'est déjà fait, merci.

Sur les lignes de code je peux pas tricher, on n'a qu'une seule information je suis bien obligé de l'utiliser.

Le Tejas mk2 est déjà mort.

KLOC c'est kilo ligne of code, et comme on a 24000000 de lignes de code pour le F-35 ça fait 24000 kilo. Bon bien sur j'ai triché pour trouver le résultat qui m'arrangeait, je vous laisse trouver où j'ai triché et lorsque je donnerais la solution cela permettra de mieux discuter de COCOMO, de sa Validité, du programme F-35 et de l'importance de la taille du logiciel pour satisfaire un besoin donné!

J'ai posté ça Et je voudrais un commentaire au moins pour pouvoir poster un autre commentaire qui ne soit pas fusionné avec celui-ci

Application du modèle COCOMO intermédiaire (étendu) au projet F-35 Je n'ai pas présenté ce modèle juste pour le plaisir, je propose donc de l'appliquer au projet F-35, brutalement bien que pour moi il ne soit pas satisfaisant du fait des contraintes que posent les essais en vol et qu'on ne trouve pas sur les systèmes informatiques plus classiques. Mais j'aborderais ces problèmes plus tard. Calcul de l'effort et de la durée On a vu que pour l'effort c'était PM =23*(KLOC) 1.26 = 7 599 657 en prenant KLOC = 24000 Pour la durée c'est donc TDEV = 2.5(7 599 657)0.31 = 340 mois soit 28 ans et 4 mois Le projet F-35 a été signé en Octobre 2001 ce qui implique une fin du développement au début de 2030 pas très différente de mes autres estimations qui pointent sur 2031.

Corrigé merci.

A l'issue de la manip tout sera rentré dans l'ordre prévu. Et je trouve que c'est bien qu'on ait pensé à utiliser les Rafale M pendant l'Iper, d'ailleurs si on ne les utilise pas plus c'est peut être que eux aussi ont été bien utilisés.

Je ne crois pas que les Rafale soient globalement sur-utilisés, ceux qui sont en opération sont sur-utilisés, cela veut dire (par exemple) qu'ils consomment leur quota annuel en deux mois, mais après ils sont remplacés et ils se "reposent" à Chateaudun. On peut penser que pour les pilotes c'est pareil, il doit y avoir des rotations qui permettent de répartir les périodes d'activités intenses de façon à lisser les heures de vol annuelles. Il y a certainement des cas particuliers mais que cela ait un impact statistique majeur, je ne le crois pas.

L'information que j'avais concernait l'export exclusivement. La France gère ses propres besoins pour la gestion d'obsolescence et là la seule information que j'ai c'est "plus ou moins bien". Mais pour l'export ce sont les industriels qui gèrent et là j'ai eu l'exemple d'un système majeur où les stocks ne pouvaient couvrir que 200 exportations. Mais il peut y avoir d'autre systèmes majeurs où les stocks sont encore plus réduit que 200. En plus certaines obsolescences ne sont pas traitées en faisant des stocks mais en trouvant des composants de nouvelle technologie permettant de construire des équipements compatibles avec les anciens. Donc c'est complexe comme situation et la seule conclusion que j'en avait tiré c'est que si vraiment les exportations explosaient alors on serait peut être obligé d'avancer la MLU....mais c'est un problème de riche!

Il y a des graphiques là: http://tpe-rafale.e-monsite.com/pages/rafale-remise-en-cause-du-programme/face-a-ses-concurrents/

Ah oui, le truc que les Brésiliens doivent faire

Et puis Dassault a 49% de la JV et certains systèmes seront produit exclusivement en France.

oui

Oui je l'ai amené sur un plateau

Chaque chose en son temps.

Quelques extraits d'une discussion (Parikrama). Un bon ami m'a dit que lorsque la ligne de Dassault Reliance Aerospace Ltd (DRAL) sera en place, GOI va commander directement à cette ligne.. Ce seront des achats de tranche directe et ce ne sera pas soumis à de nouvelles offres .. et cela devrait se produire seulement après un audit indépendant de la mise en place correcte des offsets. Aussi, il a été clairement dit que l'ambiance dans le camp de Dassault est optimiste. Il semble que Dassault Aviation pourrait obtenir deux ou plusieurs commandes surprises longtemps attendues avec l'approvisionnement de systèmes majeurs produits depuis Dassault Reliance Aerospace Ltd (DRAL). Les pays en question sont courtisé par le Premier ministre NaMo lui-même. (Je crois que cela indique sûrement des contacts avec les Émirats Arabes Unis et peut être la Malaisie ou un autre pays). Quand je me suis renseigné sur le calendrier probable pour voir tout cela sortir, il a dit comme le bon vin français certaines choses prennent du temps. Il y a beaucoup de travail à faire pour mettre en place la ligne. Donc, de façon réaliste à son avis, ces ordres directs devraient être n'importe où près de 2019 ou 2020. Peut-être juste à temps pour coïncider avec la dernière livraison de jet de Mérignac, ça pourrait être planifié immédiatement après ou 6 mois max après que nous ayons reçus un Rafale De la ligne indienne Dassault Reliance Aerospace Ltd (DRAL). Alors en 2021 ou 2022 des Rafales devrait être produits par Dassault Reliance Aerospace Ltd (DRAL) .... http://indiandefence.com/threads/rafale-deal-signed.56201/page-133#post-525682

Dans ce cas ils devraient acheter des Rafale

On attend qu'elle sorte pour voir.

Présentation du modèle COCOMO (suite) Dans la formule PM = 2.6*M*(KLOC) 1.26 il ne reste que M à déterminer. PM c'est des People Months ou des Mois*Hommes et le facteur 2.6 est redondant avec M mais c'est parce que dans les modèles simplifiés M vaut 1. Le modèle intermédiaire lui permet de calculer M en tenant compte des caractéristiques du projet. Le modèle intermédiaire introduit 13 facteurs de productivité. Les 13 facteurs sont multipliés entre eux pour donner un facteur d'ajustement qui vient modifier l'estimation donnée par la formule de base. Facteurs de productivité Logiciel RELY: Fiabilité requise DATA: Volume des données manipulées CPLX: Complexité du produit Matériel TIME: Contraintes de temps d'exécution STOR: Contraintes de taille mémoire VIRT: Instabilité de la mémoire Personnel ECAP: Aptitude de l'équipe AEXP: Expérience du domaine VEXP: Expérience de la machine virtuelle LEXP: Maîtrise du langage Projet MODP: Pratique de développement évoluées TOOL: Utilisation d'outils logiciels SCED: Contraintes de délais Il existe dans la littérature des tableaux donnant les valeurs de ces paramètres, dans ce post je vais donner seulement les valeurs qui me semblent pertinentes, pour des raisons pratiques! (je ne sais pas comment faire un tableau). Je n'ai pas pris les valeurs extrêmes soit "extrêmement élevé" et "très basse" parce que sur un projet grandiose comme le F-35 il est statistiquement impossible que l'on atteigne ces valeurs. Ensuite j'ai pris les valeurs qui rendent maximum M pour être en accord avec les dérives constatées des coûts et des délais. On a donc RELY: 1.4 DATA: 1.16 CPLX: 1.3 TIME: 1.3 STOR: 1.21 VIRT: 1.3 ECAP: 1.18 AEXP: 1.13 VEXP: 1.1 LEXP: 1.07 MODP: 1.1 TOOL: 1.1 SCED: 1.08 La multiplication de tous ces coefficients donne 8.854 qui multiplié par 2.6 donne 23. COCOMO permet d'évaluer aussi la durée du projet et la répartition de l'effort par phase. 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 Pour un projet très complexe on prendra TDEV = 2.5(HM)0.31 où HM est le résultat du calcul précédent en Homme mois. On peut ensuite calculer la distribution de l'effort par phases (en %) RPD (Requirements and Preliminary Design): Conception globale et Plan d'intégration DD (Detail Design) : Conception détaillée CUT (Code and Unit Test) : Programmation et Tests unitaires IT (Integration and Test) : Intégration On a les valeurs suivantes que j'ai extrapolées compte tenue de mon expèrience et parce que je n'ai pas trouvé dans la littérature des valeurs pour des projets aussi gros que le F-35. RPD : 19% DD : 25% CUT: 19% IT : 37% Enfin on peut répartir la durée entre les phases: RPD : 38% DD et CUT: 30% IT : 32%

Même les Nazi n'ont pas osé envahir la Suisse... L'arme de dissuasion absolue c'est la publication des comptes bancaires des dirigeants.

C'est Tragedac qui le dira. Mais ça peut être simple, tu peux par exemple "donner" dix pistes à chaque unité participante qu'elle peut désigner pour demander les mesures.

Le Stanag en général définit comment on doit calculer la TQ. Pour chaque type de liaison il y a en général un contrôleur de réseau qui donne la parole aux différentes unités participantes, chacun son tour. Mais ce n'est pas un homme, c'est technique.

Si tu ne dis pas ce que tu n'as pas compris, c'est assez difficile de te répondre. Mais d'après les réactions, il me semble que les participants ne comprennent pas l'intérêt de l'introduction du concept de "mesure" en plus du concept de "piste". Une piste est un objet système qui est régie par des règles, pour la France ces règles sont des règles OTAN écrites dans un document appelé STANAG. Il y a un STANAG pour chaque type de liaison. On ne peut pas laisser tout le monde diffuser toutes ses pistes, la liaison serait surchargée et la situation confuse. Si par exemple on faisait partie d'une force avec 20 participants, chaque piste serait représenté entre 15 et 20 fois. Le STANAG dit quels sont les règles pour savoir qui a le droit de diffuser sa piste, et très souvent c'est la piste qui a la meilleure TQ (Track Quality) qui est diffusée. Les mesures sont en général un concept local, ce qui veut dire qu'en général elles ne sont pas diffusées. Elles servent à créer les pistes locales qui sont ensuite éventuellement diffusées si elles sont de bonne qualité. Pour créer une piste on peut avoir à utiliser plusieurs mesures. De la même façon que pour les pistes on ne peut pas diffuser toutes les mesures, par exemple sur l'ATL2 le système était capable de gérer 800 pistes, si la force amie comporte 20 participants cela ferait 16000 mesures à une fréquence d'une à trois secondes à peu près. Mais si Tragedac crée une nouvelle liaison, on peut inventer. On peut par exemple avoir une action qui demande aux amis de diffuser leurs mesures pour la piste qu'on vient de désigner. Ce qui veut dire que pour quelques pistes on pourrait avoir des traitements particuliers comme les capteurs étendus dont j'ai parlé ou même des mesures multi-statiques. Pour finir pourquoi ne pas le faire avec des pistes. Je vais vous décrire un cas particulier qui je l'espère éclairera la problématique. Supposons que l'on fasse de la fusion avec des pistes externes. Un Rafale en mode passif est proche d'un cible ennemie. Il a une détection avec son OSF. Il reçoit la piste correspondante par liaison 16. Comme la direction de la piste mesurée par l'OSF est précise, il peut améliorer la TQ de la piste en prenant en compte la mesure de l'OSF, mais il faut pour cela qu'il garde quand même l'information de distance qui lui vient de la piste externe. Donc il va faire la fusion de la piste externe et de la piste OSF, et il aura une nouvelle piste qu'il va proposer à la diffusion. Comme cette piste à une meilleure TQ elle va être choisie et la piste externe qui servait à mettre à jour l'information de distance va être supprimée ....La TQ de la piste va chuter rapidement et on est repartis pour un tour. Si par contre on a désigné la piste en question afin d'obtenir les mesures correspondantes et que l'on a fait de la fusion au niveau des mesures avant de diffuser la piste résultante, il n'y aura pas de raisons d'arrêter les mesures lorsque l'unité diffusant la piste changera.

Présentation du modèle COCOMO C'est un modèle qui permet d'estimer l'effort et la durée d'un projet en fonction de la taille du logiciel. La formule qui permet le calcul de l'effort a la forme suivante: Effort = A x TailleB x M où A est une constante qui dépend du type de logiciel et de l'organisation, Taille est la taille du logiciel qui peut être estimée en ligne de code ou par d'autres métriques pour les versions récentes de COCOMO, B est compris entre 1 et 1.5 et il reflète l’augmentation non linéaire des coûts en fonction de la taille du projet, M est un multiplicateur. Toute la difficulté est de trouver les bonnes valeurs pour les coefficients. COCOMO donne des valeurs typiques et il existe différents niveaux de COCOMO qui permettent de calculer des valeurs plus précises si on a plus d'informations sur le projet. Initialement il y avait 3 niveaux: de base, intermédiaire et détaillé. Puis il y a eu COCOMO II qui lui-même avait plusieurs niveau. Mais on n'a pas assez d'informations pour utiliser des modèles trop sophistiqués. Dans le modèle intermédiaire, en fonction de la nature du projet l'estimation de l’effort est le suivant: Simple : PM = 3.2*M*(KLOC) 1.05 Modéré : PM = 3.0*M*(KLOC) 1.12 Complexe : PM = 2.8*M*(KLOC) 1.20 Il n'y a pas de formule pour les projets très complexes, car pour ces projets il faudrait calculer les coefficients avec le modèle détaillé. Mais l'examen de l'ensemble des modèles COCOMO disponibles montre que la valeur maximale de B est autour de 1.26 donc on peut prendre une approximation pour ces projets et je propose : Très Complexe : PM = 2.6*M*(KLOC) 1.26