Picdelamirand-oil

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

Le logiciel du F-35 C'est un sujet que j'ai déjà abordé et je voudrais en faire une synthèse dans une série de posts. Je commencerais avec l'introduction de l'article que j'ai publié dans 45enord.ca/ http://www.45enord.ca/2014/05/le-logiciel-du-f-35/ Un logiciel embarqué est, normalement, beaucoup plus léger, en taille, et beaucoup plus complexe à mettre au point qu'un logiciel de gestion classique. De plus il faut faire une ségrégation entre le logiciel "critique" et le logiciel normal car si, par exemple, le module "navigation" a une erreur fatale, il n’est pas envisageable que les commandes de vol ne répondent plus. Et il est bien évident que le logiciel critique demande plus de travail et de tests que le logiciel normal. 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: "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. 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 de façon à limiter les activités supplémentaires de coordination entraîné par la décomposition. Cette introduction est là pour faire sentir que lorsqu'on a affaire à de gros logiciel complexes, on n'est pas libre du point de vue du planning, et on ne peut pas forcément diminuer le temps de développement en augmentant les ressources. A propos du logiciel du F-35 on n'a qu'une information : sa taille, pour évaluer le temps de développement il existe des modèles assez sophistiqués, mais qu'on ne pourra pas utiliser par manque d'information. Avec seulement la taille on ne pourra utiliser que le modèle COCOMO. Mais vous verrez que c'est mieux que rien!

Oui bien sur! J'avais donné le vrai prix du LRIP 9

Ils ont du tout regrouper l'AASM évolution est un nouveau standard matériel qui permet de réduire le coût de 30% et le domaine de largage étendu sera celui que l'on devra valider sur ce nouveau standard. On a donc un nouveau matériel plus agile que l'ancien, même si l'ancien aurait été capable de la même agilité. les gars du marketing sont content. Je pense aussi que c'est nouveau.

Oui mais maintenant c'est sérieux alors qu'avant ça ne l'était pas:

Voila, c'est une foultitude de contrats comme celui là qui ensuite ne sont pas comptés avec le contrat qui viendra later! C'est quand même le prix de 10 Rafale.

C'est parce que vous avez votre propre idée et vous ne voulez pas la modifier avec ce qu'on vous dit. Le problème est que la liaison a sa propre logique qui est antagoniste de la logique qui sous tend la fusion. La logique de la liaison est de prendre la meilleure piste et de supprimer toutes les autres. La meilleure piste pour la liaison c'est celle qui a la meilleure TQ (Track quality). Il y a des raisons fondamentales pour lesquelles toutes les liaisons qui font intervenir plus de 2 participants se comportent comme cela. La logique de la fusion c'est de prendre dans chacune des pistes (quand on est au niveau système) ou chacune des mesures (quand on est au niveau capteur comme SPECTRA) les informations les meilleures. Pour la direction de la piste, par exemple, une mesure optique peut être meilleure qu'une mesure Radar, alors que pour la distance on gardera la mesure Radar et pour la vitesse radiale de la piste, peut être que l'ESM sera plus précis que le radar. Donc d'un coté il y a une logique d'exclusion et de l'autre une logique qui consiste à exploiter tout ce qu'on peut. Lorsqu'on le fait avec des pistes locales il n'y a pas cet antagonisme puisque on n'utilise pas la liaison. Même si tous les avions utilisent les mêmes mesures de capteur étendu, le fait que chacun va créer une piste locale lui permettra ensuite de l'utiliser dans une fusion locale, avant d’émettre le résultat en tant que piste soumise à la gestion de la liaison. Tu comprend pourquoi les Américains n'y arrivent pas

Je l'ai expliqué 25 fois mais c'est comme si on pissait dans un violon. Je reprend avec une explication un peu différente. Le fonctionnement actuel du Rafale vis à vis de SPECTRA c'est que SPECTRA fait une première fusion des mesures (pas des pistes) de l'ensemble de ses capteurs (ESM ou RWR, OSF, DDM) et crée une piste qu'il transmet au système. Si bien que pour le système SPECTRA est un capteur et non pas un ensemble de capteur. Ensuite le système fait la fusion des pistes de la plate forme : Radar SPECTRA, Liaison 16. De la même façon avec tragedac on peut traiter un premier niveau de fusion dans SPECTRA ou par capteur en créant une piste à partir de mesure fusionnées. Je ne sais pas ce qui marchera le mieux mais supposons que l'on crée une piste ESM pour chaque mobile à partir de toutes les mesures ESM de la plate forme et de celles avec qui on communique. L'ensemble de ESM qui communiquent sera vu comme un seul capteur (je l'appelle capteur étendu) au lieu d'être un relèvement la piste qui est fournie sera le résultat d'une triangulation réalisée avec les "mesures relèvement" c'est à dire une position, qui sera même affectée d'une route et d'une vitesse si la triangulation est faite par un filtre de Kalman. Le système pourra ensuite faire la fusion des pistes comme il le fait actuellement. La piste du capteur étendu est une piste locale à la plate forme car elle dépend des mesures que la plate forme a reçu et de celles qu'elle a choisi de traiter. Sauf que le pilote dit qu'il n'est pas content.

Non le pilote n'est pas dans la boucle. On lui présente un résultat parfait et il dit partout qu'il est très content.

Mais avec la nouvelle liaison de données on ne va pas essayer de fusionner des pistes, on va échanger des mesures et créer des pistes dans chaque plateforme qui seront échangées sur la liaison en respectant les concepts de la liaison. SPECTRA fait déjà cela en interne du Rafale il fusionne les différents capteurs de SPECTRA à partir des mesures et présente une seule piste au système qui lui fait la fusion des pistes d'une même plate forme. On a déjà deux niveau de fusion dans le Rafale ce sera facile de les utiliser pour résoudre les difficultés de la liaison.

Mais nous on n'a pas d'erreur conceptuelle. Nous on fait des trucs qui marchent, on essaye pas de faire des trucs qui marchent pas. Des pistes venant d'une même plate forme on peut les fusionner, si elles viennent de deux plate formes différentes il faut faire attention à cause des concepts introduits par la liaison et la façon dont celle ci les gère.

Si ma mémoire est bonne, l'exemple des Danois qui se sont vu refuser d'utiliser leur tactique, et qui n'ont eu droit qu'à des missiles à portée plus limitée que dans la réalité, montre que les américains interdisent que le F-35 perde contre des legacy fighter. Par défaut le F-35 gagne forcément.

Que voulez vous voir exactement à l'arrière de cet avion? Là je ne vois rien de spécial donc il faudrait préciser l'angle de prise de vue souhaité, et peut-être faut-il que la photo soit récente? Il y a aussi celle là?

Je ne veux pas jouer à qui a la plus grosse, j'ai passé l'age.

Et tu ne supportes pas qu'on dise qu'un logiciel est trop gros

C'est pas parce que les américains font une erreur conceptuelle que nous on fait une erreur conceptuelle, on fait des trucs moins ambitieux mais qui marchent, comme des capteurs étendus ou comme créer de nouvelles pistes à partir de mesures échangées (et non pas à partir de plusieurs pistes venant de partout)

Je l'avais expliqué là:

Grillé (2 pages avant)

Oui mais les trolls sont une catégorie à part ce ne sont pas seulement des contributeurs donnant des avis non sourcés: