Le F-35

[TarpTent]

Il y a 3 heures, Henri K. a dit :

Les choses simples ne sont pas forcément les meilleures. Les info à la source sont souvent plus précises et plus complètes.

Après c'est juste une question si on est intéressé ou pas. On est intéressé, alors on cherche, on traduit, et on trouve. Tu crois que je fais comment pour les trucs en russe ou en japonais ?

Je n'aime pas qu'on me sert des info sur un plateau, notamment celles en dehors de l'Europe, parce que à coup sûr l'info est déjà interprété donc probablement "faussée" et "diluée". Les journalistes dans le monde entier ne font que ça.

C'est pour ça je ne regarde pas quand les journalistes chinois parlent de l'Europe ou ailleurs qu'en Chine, tout comme je ne crois pas un mot de ce que disent les journalistes occidentaux sur la Chine ou sur d'autres pays qui ne sont pas les leurs.

Quel problème d'architecture as-tu repéré Pic ? Là suis très curieux de savoir ce que tu pourras me répondre.

Henri K.

Dorf, Henri K. , à aucun moment je ne parle d'informations en anglais sur les appareils russes et chinois, là.

Si vous regardiez à quelle phrase de Pascal je réponds, ça vous aurait évité de comprendre de travers et de réagir ainsi.

(et puis soit dit en passant, je ne sais pas qui aujourd'hui Google Translate performant, mais c'est juste une plaie, encore plus pour les informations techniques. Alors cet argument là est loin d'être recevable).

 

Et accessoirement, je fais comme je le souhaite, vous faites comme vous le souhaitez, vous gardez vos leçons pour vous et tout le monde est content 

(par contre, si vous me trouvez l'équivalent du rapport 2015 du DoD sur le F35 pour le PAK FA, je serai ravi d'essayer la traduction via google.)

Modifié le 14 août 2016 par TarpTent

[Dany40]

Il y a 9 heures, Kal a dit :

... et qui en plus n'avaient aucune raison de défendre leur emploi et l'avenir de leur famille dans la région. C'est vrai que les consignes données à des personnels militaires, c'est un phénomène rare, cela ne peut sûrement pas arriver. Pour info, un exercice, ce n'est pas une vraie confrontation et souvent les acteurs eux-mêmes ne savent pas exactement quelle est l'issue de la confrontation avant le mass debriefing.

Si le F-35 a montré quelques qualités, c'est heureux pour ses acheteurs, mais tu omets volontairement, comme toujours, toutes les infos beaucoup moins sympathiques qui ont également transpirées précédemment.

Par ailleurs, on ne sait rien du rôle exact qui avait été confié à ces avions, ni même des tactiques employées. Personne n'est en mesure d'affirmer si le résultat aurait été différent avec un autre avion.

En revanche, il est tout à fait du domaine du possible, qu'afin de sauver son programme de plus en plus contesté, LM ait obtenu la participation de son oisillon à de tels exercices, afin de lui redonner de la crédibilité, avec un rôle taillé sur mesure pour lui. Un peu à la manière d'une certaine mission (unique) de bombardement des Raptor il y  a quelques temps, pour faire taire les critiques qui disaient que cet avion était devenu totalement inutile dans le contexte actuel. Toi qui insiste régulièrement sur l'enjeu de ce programme pour les USA, tu devrais pouvoir envisager qu'on puisse se livrer à quelques "promotions" de ce genre afin d'en assurer la continuité.

Bref, tout ça est loin de faire du F-35 un avion "Combat proven".

Enfin, je ne crois pas me  tromper en affirmant ici que nous sommes tous conscients que le F-35 devrait finir tôt ou tard par remplir des missions de frappes aériennes, intégré dans un dispositif complet, face à une menace limitée, avec des résultats positifs, surtout si des milliards continuent à être déversés dans ce programme. Cela fera-t-il de lui pour autant un bon avion ? Non. Il en faudra beaucoup plus, eu égard à l'évolution des menaces, ainsi qu'aux coûts farimineux engendrés par le programme et au nombre très limité que beaucoup de pays pourront s'offrir. La question de la disponibilité par exemple, sera au moins aussi importante que ses capacités en conditions réelles.

 

Je suis globalement d'accord avec tout ça ... Je combat juste l'idée qu'il est de façon certaine une catastrophe opérationnelle et technique annoncée ...

J'insiste sur les "qualités" qui ressortent des exercices militaires car on parle étrangement très peu de ce qui semble fonctionner sur cet avion ... Mais je ne nie absolument pas les problèmes restant à régler sur le F-35, si je ne les cite pas c'est uniquement parce qu'ils sont déjà massivement cités et rabâchés par d'autres ...

Concernant la fiabilité des retours de ces exercices ... Je comprends qu'on puisse émettre des doutes. Mais autant il est très possible de gommer des soucis en adaptant un exercice pour l'avion , autant il est plus difficile de fournir des éléments falacieux attestant de points qui fonctionnent bien si ce n'est absolument pas le cas ... 

[Henri K.]

il y a une heure, TarpTent a dit :

Dorf, Henri K. , à aucun moment je ne parle d'informations en anglais sur les appareils russes et chinois, là.

Si vous regardiez à quelle phrase de Pascal je réponds, ça vous aurait évité de comprendre de travers et de réagir ainsi.

(et puis soit dit en passant, je ne sais pas qui aujourd'hui Google Translate performant, mais c'est juste une plaie, encore plus pour les informations techniques. Alors cet argument là est loin d'être recevable).

Et accessoirement, je fais comme je le souhaite, vous faites comme vous le souhaitez, vous gardez vos leçons pour vous et tout le monde est content 

(par contre, si vous me trouvez l'équivalent du rapport 2015 du DoD sur le F35 pour le PAK FA, je serai ravi d'essayer la traduction via google.)

Je ne donne jamais de leçon, mais si tu le considères comme tel je n'y suis pour rien.

Je donne un avis sur une pratique personnelle, ce que font les autres n'est pas trop mon souci. Je dis simplement que si on veut réellement, malgré la barrière de la langue on y arrive.

Exemple 1 : Un mec du forum NSF américain squatte régulièrement un forum aérospatial chinois pour récupérer des info de première main, il ne pige pas un mot en chinois, pourtant il récolte des tonnes d'info et il en est content.

Exemple 2 : Une fois j'ai passé toute la nuit à chercher les info sur le train d'atterrissage version catapulte de T-10K / Su-33, je ne parle pas un mot en russe, pourtant après 6h de recherche et des dizaines de forums et de sites russes parcourus, j'ai trouvé ce que j'ai voulu. Et, tu crois que je comprend tout sur tous les documents R&D chinois ? J'y suis arrivé comment ? L'huile de coude, c'est tout.

Dorf et moi disons juste une chose, quand on veut, on peut. Quand on a essayé mais on n'a vraiment rien trouvé, il y a toujours des gens qui sont contents d'aider, ici ou ailleurs.

Et si on revient au F-35 ?

Henri K.

[Dany40]

Il y a 10 heures, g4lly a dit :

 

 

En quelques sortes les F35s sont nés 10 ans trop tôt ... résultat des course ils servent de lièvre

Pour moi c'est exactement cela le fond du problème ... Lorsque le programme JSF est lancé les technologies fondamentales de son concept n'existent même pas encore ... Rien n'est mature ... Et le contexte opérationnel pour lequel il est prévu (les flottes de 5ème Gen chinois et russes pour simplifier ...) est encore très très loin d'être une réalité ... 

Rien que le défi de concevoir un type nouveau de revêtement furtif permettant un niveau de furtivité important mais pour des coûts d'achat et d'entretien massivement réduit par rapport au F-22 et au B-2 .... Sachant que s'appuyer sur les acquis du F-22 leur était semble t'il interdit ... C'est en soit d'une ambition délirante ...

En terme de besoins pour l'armée américaine le programme JSF dans son concept est mis en route bien trop tôt ... C'est l'incarnation d'une volonté de creuser l'écart technologique à tout prix et quelque soit le coût .... 

[Invité Dorfmeister]

il y a une heure, TarpTent a dit :

Et accessoirement, je fais comme je le souhaite, vous faites comme vous le souhaitez, vous gardez vos leçons pour vous et tout le monde est content 

(par contre, si vous me trouvez l'équivalent du rapport 2015 du DoD sur le F35 pour le PAK FA, je serai ravi d'essayer la traduction via google.)

Je ne vis pas dans un mode de pensée dictatoriale qui impose de faire/penser/agir comme moi pas plus que je n'ai l'âme d'un donneur de leçons (ça ne paie pas par conséquent ça n'a aucun intérêt). Donc libre à chacun de faire comme bon lui semble. 

Cependant, il est un fait certain que nous disposons en 2016 d'outils très pratiques (comparativement à il y a 20 ans) qui permettent d'accéder à un plus grand nombre de sources. Libre à chacun de les employer ou non. C'était la teneur de mon propos précédent. Ni plus ni moins. 

Bien évidemment, vu que "tu fais ce que tu veux" et que je respecte ta position à 2.000% je te laisse chercher ton rapport sur le PAK FA par toi-même, "œuf corse"  (ouais avec un petit smiley ça passe toujours mieux)

[rogue0]

Il y a 7 heures, zx a dit :

 

un peu de IR dans un ciel de brutes

F-35 Thermal Scan Highlights New Stealth Features

edit: avec le lien c'est mieux.

http://defense-update.com/20160812_f35_thermal.html

Merci pour l'article ! (ça change, un peu de factuel après 20 pages de HS )

On voit au moins que les sacrifices qui ont mené aux problèmes de surchauffe actuels servent à quelque chose.
ça va aider pour réduire la portée de détection des IRST en frontal, mais ça aidera beaucoup moins en latéral

Je n'ai pas vu de gain / échelle dans la vidéo du JSF.
Sur la vidéo similaire du Raptor, est-ce que les graduations mobiles à gauche représentent le gain ou la direction de pointage de la caméra ?

 

[Bon Plan]

Le ‎13‎/‎08‎/‎2016 à 21:40, Henri K. a dit :

L'info j'en ai, je sais même exactement quelle boîte française DA a choisi au détriment de DS pour la maintenance et la maintenance évolutive d'une partie de truc, où le plateau se situe (pas à Paris)...etc.

Mais non, il y a des choses je les garde pour moi, c'est comme ça.

Tu sais, tu ne m'apprend rien sur le PLM chez Airbus, j'ai participé au moins à une partie de la mise en place de celui de l'A350 (l'architecture PLM chez bubus est par programme), et je ne parle pas des autres programmes. Le bureau de DDS à Ramassiers c'était une 3ème maison pour moi à une époque.

Oui ils sont bons, pour certains trucs. Ils sont tellement bons que le PDM de l'A350 c'est PTC qui a été choisi, le VPM a été utilisé, pour faire simple, en tant que vault DMU, parce que Monsieur DS a tapé les pieds par terre.

Ils sont tellement bons que leur merde de 3DVia les qualiticiens Airbus ont failli dire FUCK.

Ils sont tellement bons qu'il n'y avait que XXX utilisateurs concurrents pour DELMIA et on se demande toujours pourquoi on paie une fortune pour quelques cacahuètes qui l'utilisent et qui ne sont pas non plus super heureux.

Ils sont tellement bons que la V6 est banni pour le moment, un certain Hollandais a dit FUCK à tous les budgets associés. Bon OK il y a une raison pas forcément technique derrière donc je ne remet pas la cause principale sur les produits.

Oui ils sont bons, pour certains trucs... Et je le dis sincèrement et sans ironie (tout sauf leur putain de R&D à Paris qui plug en Inde...). PTC est en train de déconner avec leur digital twin, Siemens à Toulouse c'est une rigolade (sur le compte Airbus), quand tu appelles le commercial c'est à croire que tu lui fasses chier...

Quand j'ai vu des vidéos en interne qu'ils disent que 3DExperience est utilisé par l'A350, j'ai failli pisser dans mon froc tellement j'ai rigolé (d'ailleurs je n'étais pas le seul...).

La réalité est, le F-35 est tellement une merde que nos voisins préfèrent quant même de l'acheter. Qu'ils se font avoir ou se font entuber par les Américains, ça reste quant même un fait. On peut s'en préoccuper, on peut espérer un jour peut-être qu'ils achèteront notre Rafale, mais non vieux, c'est comme ça. Basher c'est cool, taper sur un clavier même un naze comme moi sait le faire.

Nouveau trucs ? Comme ça je vois une nouvelle façon d'intégrer et d'interopérer avec le "tout", une nouvelle méthode pour forcer tout le monde à se rassembler autour de l'Oncle Sam, un nouveau type d'architecture avionique, un p'tain de gros cul derrière...

Henri K.

Pouah... Pas facile a suivre.  Tu étais enervé quand tu as écrit ca?

[Picdelamirand-oil]

Il y a 9 heures, Henri K. a dit :

Quel problème d'architecture as-tu repéré Pic ? Là suis très curieux de savoir ce que tu pourras me répondre.

Henri K.

Je l'explique un peu:

Citation

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.

Mais pour aller plus loin je vais me citer:

Citation

 

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.

 

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.

[Henri K.]

Il y a 2 heures, Picdelamirand-oil a dit :

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 confonds dans ce cas la gestion du programme et l'architecture, les deux n'ont rien à voir.

Henri K.

[zack]

Il y a 8 heures, Henri K. a dit :

Exemple 2 : Une fois j'ai passé toute la nuit à chercher les info sur le train d'atterrissage version catapulte de T-10K / Su-33, je ne parle pas un mot en russe, pourtant après 6h de recherche et des dizaines de forums et de sites russes parcourus, j'ai trouvé ce que j'ai voulu. Et, tu crois que je comprend tout sur tous les documents R&D chinois ? J'y suis arrivé comment ? L'huile de coude, c'est tout.

 

Il y a 8 heures, Dorfmeister a dit :

Cependant, il est un fait certain que nous disposons en 2016 d'outils très pratiques (comparativement à il y a 20 ans) qui permettent d'accéder à un plus grand nombre de sources. Libre à chacun de les employer ou non. C'était la teneur de mon propos précédent. Ni plus ni moins.

Je rejoin Dorf et Henri sur ce point Internet est un outils extraordinaire avec google trad et Yandex on fait des merveilles. Aujourd’hui après des semaines de recherches (par intermittence) j'ai finalement réussie a mettre la mains sur l'ouvrage que je cherchais.  "Russia's Arms and Technologies. The XXI Century Encyclopedia. Vol. 10 – Aircraft armament and avionics (in Russian) – Оружие и технологии России: энциклопедия XXI век [Oruzhie i Tekhnologii]"

http://forum.guns.ru/forummessage/18/574938.html

Le volume 10 est une mine d'or pour tout ceux qui s'intéresse à l'armement et avionique soviétique/russe. Si certain d'entre vous ont le reste de la collection je suis preneur :p. 

[Picdelamirand-oil]

Il y a 6 heures, Henri K. a dit :

Tu confonds dans ce cas la gestion du programme et l'architecture, les deux n'ont rien à voir.

Henri K.

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?

[Henri K.]

Il y a 2 heures, Picdelamirand-oil a dit :

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?

Il y a souvent 3 niveaux d'architecture dans un logiciel - architecture "Business", architecture système et architecte technique.

Ce que tu appelles par contour des modules est probablement la partie technique.

Dire que la répartition de travail dans cette partie est "mauvaise " donc toute l'architecture est mauvaise, ca c'est un avis tranché un peu vite.

Tout ça pour revenir au point initial - un logiciel "gros" n'est pas un problème en soi.

Henri K.

[g4lly]

52 minutes ago, Henri K. said:

Tout ça pour revenir au point initial - un logiciel "gros" n'est pas un problème en soi.

C'est souvent synonyme de complexité, et de plus grande difficulté a maintenir ... rapport a une programmation plus "simple".

Après ça dépend du niveau de programme dont on parle ... entre les drivers qui pilote nativement du matériel, et une surcouche d'une surcouche complétement abstraite ... la problématique n'est pas du tout la même.

Je suppose d'ailleurs que les systeme qui tiennent l'avion en l'air ne sont pas développé ded la meme maniere que les "goodies" peu critique.

[web123]

Le 14/08/2016 à 10:34, Picdelamirand-oil a dit :

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.

Ce n'est pas ce que j'ai dit. Je n'ai jamais discuté de la taille qui est donnée du logiciel. Parfois on lit 5 millions de ligne, parfois 6, des fois 10, peut-être plus, j'y prête à peine attention car ce n'est pas pertinent.

Je dis qu'on en sait rien si le programme est trop gros.

Un avion de 11x15m qui fait 10 t à vide, c'est lourd, très lourd. Trop lourd ? Ça dépend de ce qu'il fait. Si c'est un chasseur, même s'il ne transporte que 2 personnes, ce n'est pas forcément trop lourd. Un Falcon 900, c'est 11 t pour 20x21m, il y a 3 réacteurs et il transporte jusqu'à 14 personnes. Mon Dieu, le Rafale est trop lourd ! (oui c'est ridicule) Et je ne vais pas parler du prix...

C'est pareil pour les logiciels. x millions de ligne c'est beaucoup, mais ce n'est pas forcément trop, tout dépend de ce que fait le logiciel. Sais-tu ce que fait le logiciel ? Moi non ou que vaguement. À part les doublons de code, qui en général ne vont pas chercher loin, un logiciel fait la bonne taille pour ce qui lui est demandé. On lui en demande peut-être trop ? Effectivement la question se pose.  Mais si on lui en demande trop, ce n'est pas avec un objectif de réduction de ligne de code qu'on règle le problème. S'il faut virer des fonctionnalités car on en demande trop et que l'objectif est de virer des lignes, ce qui va être viré est ce qui prend le plus de ligne, ça sera le choix (évident) de l'informaticien. Mais ce n'est pas à lui de faire ces choix ! Peut-être que ce qui prend le plus de ligne est crucial, ce n'est pas à lui de le savoir. Est-on face à un problème de logiciel, d'une équipe logicielle qui n'a pas été bonne, ou face à un client qui a fait des demandes "intenables" ? Je penche vers la deuxième option, j'ai rien pour le prouver. Quoique...

Je ne suis pas en détail l'évolution du F-35, mais un fait m'a marqué. Ils se sont rendu compte tardivement que le hardware n'était pas assez performant ! Donc en gros ils sont allés à tâtons, ils n'ont pas vraiment validé avant de faire. C'est un gros problème ça. S'il faut optimiser pour tenir les performances, ça ajoute beaucoup de complexité.

Citation

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.

T'es sûr de ça ou tu fais une supposition ?

Des mêmes fonctions programmées plusieurs fois, oui ça arrive. De là à être un problème critique, c'est quand même rare.

Il y a 15 heures, Picdelamirand-oil a dit :

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.

Dans ton article tu ne parles pas vraiment du nombre de ligne de code, mais surtout de complexité. Pour moi là on est sur un critère pertinent.

J'ai déjà fait 20 000 lignes de code en un mois. Réception de la demande, livraison au client satisfait, un mois (je suis repassé un an après, c'était toujours le même programme sans la moindre modification). Ce n'est pas exploit, ce n'était pas compliqué. Je devais transférer des mesures d'un système à un autre sous un autre format. J'avais la doc du format d'origine et la doc du format de destination. Quasiment pas d'interaction, pas de contrainte de performance, pas de paramètre, le flux du programme n'a qu'un chemin, du début à la fin.

Un autre projet. Un module DirectShow qui utilisait Direct3D pour utilise la puissance du GPU de la carte graphique, 13 000 lignes de code (avec beaucoup de commentaire car compliqué), 12 mois. J'ai été 20 fois plus lent par ligne de code parce que c'était horriblement compliqué (contexte multi-thread, en plus des thread pas à moi qui passent dans mon code n'importe quand, (soft) temps-réel, optimisé à mort, très interactif). Un très mauvais souvenir tellement j'en ai chié. Et avant ce module, j'ai fait un programmes pour valider la faisabilité...

Le premier problème est la complexité, pas le nombre de ligne. Est-ce que tout le code du F-35 est compliqué ou est-ce que 10 % ? Je n'en sais rien.

 

Modifié le 15 août 2016 par web123

[zx]

La complexité et un critère, mais si il est sous la responsabilité de plusieurs tiers, ca devient absolument infernal en terme de support et de reunionite. surtout quand cela tourne au jeu de ping pong pour éviter de prendre en charge, un vrai régal.

 

Modifié le 15 août 2016 par zx

[web123]

il y a 4 minutes, zx a dit :

La complexité et un critère, mais si il est sous la responsabilité de plusieurs tiers, ca devient absolument infernal en terme de support et de reunionite. surtout quand cela tourne au jeu de ping pong pour éviter de prendre en charge, un vrai régal.

 

Ouaip.

Et faut pas oublier le contexte LM. Ce n'est pas LM qui paye, plus on lui en demande et plus LM est content ; même quand ça va droit dans le mur en klaxonnant. Donc ça dit "oui" à toutes les demandes chez les décideurs et c'est ceux qui réalisent, et à qui on n'a pas demandé l'avis, qui doivent se démerder.

[Picdelamirand-oil]

Il y a 6 heures, web123 a dit :

Ce n'est pas ce que j'ai dit. Je n'ai jamais discuté de la taille qui est donnée du logiciel. Parfois on lit 5 millions de ligne, parfois 6, des fois 10, peut-être plus, j'y prête à peine attention car ce n'est pas pertinent.

Je dis qu'on en sait rien si le programme est trop gros.

Un avion de 11x15m qui fait 10 t à vide, c'est lourd, très lourd. Trop lourd ? Ça dépend de ce qu'il fait. Si c'est un chasseur, même s'il ne transporte que 2 personnes, ce n'est pas forcément trop lourd. Un Falcon 900, c'est 11 t pour 20x21m, il y a 3 réacteurs et il transporte jusqu'à 14 personnes. Mon Dieu, le Rafale est trop lourd ! (oui c'est ridicule) Et je ne vais pas parler du prix...

C'est pareil pour les logiciels. x millions de ligne c'est beaucoup, mais ce n'est pas forcément trop, tout dépend de ce que fait le logiciel. Sais-tu ce que fait le logiciel ? Moi non ou que vaguement. À part les doublons de code, qui en général ne vont pas chercher loin, un logiciel fait la bonne taille pour ce qui lui est demandé. On lui en demande peut-être trop ? Effectivement la question se pose.  Mais si on lui en demande trop, ce n'est pas avec un objectif de réduction de ligne de code qu'on règle le problème. S'il faut virer des fonctionnalités car on en demande trop et que l'objectif est de virer des lignes, ce qui va être viré est ce qui prend le plus de ligne, ça sera le choix (évident) de l'informaticien. Mais ce n'est pas à lui de faire ces choix ! Peut-être que ce qui prend le plus de ligne est crucial, ce n'est pas à lui de le savoir. Est-on face à un problème de logiciel, d'une équipe logicielle qui n'a pas été bonne, ou face à un client qui a fait des demandes "intenables" ? Je penche vers la deuxième option, j'ai rien pour le prouver. Quoique...

Je ne suis pas en détail l'évolution du F-35, mais un fait m'a marqué. Ils se sont rendu compte tardivement que le hardware n'était pas assez performant ! Donc en gros ils sont allés à tâtons, ils n'ont pas vraiment validé avant de faire. C'est un gros problème ça. S'il faut optimiser pour tenir les performances, ça ajoute beaucoup de complexité.

T'es sûr de ça ou tu fais une supposition ?

Des mêmes fonctions programmées plusieurs fois, oui ça arrive. De là à être un problème critique, c'est quand même rare.

Dans ton article tu ne parles pas vraiment du nombre de ligne de code, mais surtout de complexité. Pour moi là on est sur un critère pertinent.

J'ai déjà fait 20 000 lignes de code en un mois. Réception de la demande, livraison au client satisfait, un mois (je suis repassé un an après, c'était toujours le même programme sans la moindre modification). Ce n'est pas exploit, ce n'était pas compliqué. Je devais transférer des mesures d'un système à un autre sous un autre format. J'avais la doc du format d'origine et la doc du format de destination. Quasiment pas d'interaction, pas de contrainte de performance, pas de paramètre, le flux du programme n'a qu'un chemin, du début à la fin.

Un autre projet. Un module DirectShow qui utilisait Direct3D pour utilise la puissance du GPU de la carte graphique, 13 000 lignes de code (avec beaucoup de commentaire car compliqué), 12 mois. J'ai été 20 fois plus lent par ligne de code parce que c'était horriblement compliqué (contexte multi-thread, en plus des thread pas à moi qui passent dans mon code n'importe quand, (soft) temps-réel, optimisé à mort, très interactif). Un très mauvais souvenir tellement j'en ai chié. Et avant ce module, j'ai fait un programmes pour valider la faisabilité...

Le premier problème est la complexité, pas le nombre de ligne. Est-ce que tout le code du F-35 est compliqué ou est-ce que 10 % ? Je n'en sais rien.

 

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.

[Picdelamirand-oil]

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:

Citation

The program continues to carry a heavy load of technical debt in open and unresolved deficiencies. As of the end of March 2016, the program had 1,165 open, documented deficiencies, 151 of which were Category 1, defined as deficiencies which may cause death, severe injury, or severe illness; may cause loss of or major damage to a weapon system; critically restricts the combat readiness capabilities of the using organization; or result in a production line stoppage. Of the 151 Category 1 deficiencies, 128 were associated with the air vehicle and the remaining 23 were associated with the ALIS or support equipment. Furthermore, 95 of the 151 open Category 1 deficiencies were categorized as “high severity” by the program or Services.

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.

[web123]

Le 15/08/2016 à 20:05, Picdelamirand-oil a dit :

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.

Est-ce que tu peux éviter de me prendre pour un gros jambon ? Au moins fait le avec finesse que je puisse garder l'espoir que les autres ne le remarque pas. Cette délicatesse serait appréciée, merci.

À un moment j'ai cru que tu faisais exprès de ne pas comprendre, mais finalement il me semble que non. Essaie de retenir ce que je dis et pas ce que tu imagines que je dis.

Dans les exemples que j'ai donné, nul part je dis que c'est l'équivalent de programmer pour le F-35 (comme avant nul part j'avais remis en cause le nombre de ligne de code du F-35 que tu ou d'autres avançais). Mon propos est que le nombre de ligne est un indicateur faible. J'ai donné 2 exemples, c'est la même personne, le même soucis de qualité (je n'aime pas revenir débugger les programmes j'ai livré), et bien dans un cas je fais 20 fois moins de ligne de code et là où il y a le moins de ligne c'est le plus compliqué. Pour toi la complexité se mesure principalement par le nombre de ligne et c'est compliqué que si on ne dépasse pas 250 lignes par année-homme, et ça ne mérite d'être sur un avion de chasse que si on ne peut pas en faire plus de 250 ligne par ans, sinon c'est de la merde.

Oui mon exemple du poids du Rafale peut être vu comme idiot, mais comme il est idiot de croire que la complexité d'un logiciel se mesure principalement à son nombre de ligne. Comme il est idiot de croire qu'il y a un bon nombre de ligne de code pour un chasseur. Quand j'ai commencé l'informatique, la bonne quantité de mémoire pour les programmes qui avaient le bon nombre de ligne de code, était de 640 ko. Aujourd'hui c'est 8 ou 16 Go, ma machine perso en a 32 Go, mon téléphone portable a 2 Go de mémoire vive.

Sais-tu ce que font les logiciels du F-35 ? Tu sembles affirmer que oui et des développeurs ont pondu 4 fois plus de code que nécessaire (selon toi) pour on ne sait quelle raison. Les développeurs n'ont pas fait ce code pour rien (je me répète, je l'ai déjà dit). Les raisons ne sont peut-être pas bonnes, mais ce ne sont pas eu les responsables.

Tu dis que t'as développé. As-tu déjà fait un programme trop gros ? Je veux dire, tu termines ton programme et tu te dis "j'ai fait le programme qu'on m'a demande, et pas plus car je n'ai pas que ça foutre, mais j'ai quatre fois trop de ligne de code, donc il faut que j'en enlève, j'ai dû ajouter du code qui sert à rien". Tu t'es déjà dit un truc ça ? Moi jamais. D'autres ici ont connu ça ?

Un programme trop gros pour la mémoire disponible ou pour le CPU qui n'a pas le temps de tout faire dans le temps demandé, je comprend. Un programme trop gros alors que le développeur a fait ce qui est demandé, je ne comprend pas.

Tu pars sur un nombre de ligne "idéal" qui doit être autour de 2 millions puisque pour le F-35 tu dis que c'est 4 fois trop gros. Pourquoi ? Ça me laisse penser que le Rafale doit avoir grosso-modo 2 millions de ligne de code. Peut-être que le Typhoon ou un autre appareil en a 500 000 et ils disent que le code du Rafale est 4 fois trop gros et qu'une diminution dans un rapport au moins 2 n'est pas un scandale. Et comment Dassault va-t-il faire ? Pour le Rafale tu vas peut-être dire que ce n'est pas possible, que ce n'est pas bon, mais on peut dire la même chose pour le F-35. Le code dans le Rafale n'est pas là pour rien, pour le F-35 c'est pareil (à tort ou à raison). En passant, j'aimerais bien connaitre l'évolution du nombre de ligne de code du Rafale depuis le F1. Je pense que ça a augmenté de façon assez vertigineuse. Supposons que le Rafale F3 a le bon nombre de ligne de code. Et si le F3R a en bien plus, il faut en penser quoi ? Que c'est pas bien ? Ou alors le Rafale MLU.

On en revient toujours à la même chose, sais-tu vraiment ce que fait le logiciel du F-35 ? (je précise que moi pas, ou que très peu)

Connais-tu le nombre de ligne de code des CDVE du F-35 ? C'est plus ou moins que le Rafale ? Rassure nous en nous disant que le Rafale à le bon nombre de ligne de code. Sinon on va falloir en enlever ou à ajouter...

Je n'en connais pas le détail, mais il y a des choses que le F-35 a et que le Rafale n'a pas (la réciproque doit être vrai). La vision 360° (et à travers la carlingue), tu sais combien de ligne ça prend ? C'est peut-être inutile, mais ça a été demandé aux développeurs, donc ils l'ont fait. Tu l'aurais fait avec 4 fois moins de code ? La communication directionnel du F-35, MADL, t'en sais des choses sur le nombre de ligne ? Un truc que le F-35 a et que le Rafale n'a pas, ou beaucoup moins, ce sont les informations sur les écrans et la possibilité de les gérer. Une vidéo que j'ai trouvé :

Ça parait plus rudimentaire sur le Rafale. C'est peut-être suffisant pour le Rafale, j'ai pas les compétence pour en juger (je suis pas ergonome ni pilote). Mais il me semble qu'on a un affichage beaucoup plus dynamique, plus paramétrable sur le F-35. Tout ça n'est pas compliqué faire, mais pas aussi compliqué et délicate que de faire le "micro-logiciel" de guidage d'un ASMP-A. Tu crois que c'est du code qui se fait à 250 lignes par année-homme et pas plus ? Ce n'est pas particulièrement compliqué à faire, mais ça doit faire son pesant de ligne de code (et il faut peut-être que d'autres modules intègrent ces possibilités d'affichage). Je crois que le F-35 utilise beaucoup plus la reconnaissance vocale que le Rafale. Le Rafale c'est pour des actions bien précises. Je répète, ça sert peut-être à rien, je ne peux pas en juger, mais ça a été demandé, par des gens qui peuvent prétendre en juger, ça a été codé.

Autre chose qu'a le F-35 et pas, ou peu, le Rafale, la préparation et le suivi des missions. Le Rafale en a si peu que les pilotes partent en mission avec une tablette pour cette fonction. Encore une fois, c'est peut-être satisfaisant comme le fait le Rafale (en plus ils peuvent faire comme ça pour le Mirage 2000 et d'autres appareils ; et je crois qu'ils le font au-delà de l'armée de l'air), je n'en sais strictement rien, mais ce n'est pas ce qu'a choisi le F-35. Personnellement je trouve l'idée de la tablette excellente.

Dans sa philosophie, ce que j'en perçois du moins, le Rafale se concentre surtout les informations nécessaires et pas plus pour ne pas polluer le pilote. Le F-35, également car il veut être un maillon du réseau d'information et pas qu'une extrémité, essaye d'être plus exhaustif et plus à jour sur les informations, il est info-centré, il doit potentiellement également être un "centre de commandement" (quand j'essaie de comprendre la com LM). Ça peut faire un gros paquet de ligne de code en plus.

Encore une différence importante, en tout cas qui retient mon attention. Il ne peut pas y avoir de NOSA pour le F-35. Soit un NOSA ne sert rien et dans ce cas c'est "bon débarra", soit il faut plus ou moins compenser et ça se fera principalement par le logiciel embarqué. Là encore ça peut faire un bon paquet de ligne de code.

Dans quelques années et avec du recul on va peut-être se dire que les USA ont eu la folie des grandeurs avec leur logiciel et que c'est terrible fiasco. Mais je ne vais pas jeter ce qui est fait pour le F-35 sans savoir l'objectif qui est suivi et s'il est, ou va être, tenu. Encore moins sous prétexte que le logiciel ne respecte pas le standard, venu d'on ne sait où, du bon nombre de ligne.

Dis nous les fonctionnalités à virer du F-35.

 

Ça me fait penser à MySQL. Il y a longtemps j'avais besoin d'un SGBD, c'était pour un petit projet, j'entends parler de MySQL, je l'utilise et je suis content. De temps en temps j'entends parler de PostgreSQL et je me dis : c'est trop gros, MySQL suffit. Un jour je me documente sur PostgreSQL. C'est plus gros, mais c'est bien utile et je n'utilise plus MySQL depuis. Il y a peut-être des choses dans le F-35 qu'on ignore aujourd'hui, sauf que c'est gros, qu'on dénigre par méconnaissance (et car c'est gros, ça ne fait pas affuté), mais que plus tard on va peut-être apprécier (et copier). Y a peut-être aussi des choses qui finiront dans les oubliettes.

Édit : J'ai bien écho des difficultés qu'à LM pour le logiciel. Cette terrible de voir comme ça a été mal géré/évalué. Mais attention, ce n'est pas parce qu'un programme a beaucoup de bug, qu'on en découvrir plus qu'on en corrige, que ça sera ainsi éternellement. C'est quelque chose de déjà vu avec les gros projets. Mais il y a un moment où la bascule s’opère, les choses rentrent dans l'ordre.

Modifié le 17 août 2016 par web123

[Picdelamirand-oil]

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. 

[Henri K.]

il y a 54 minutes, Picdelamirand-oil a dit :

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. 

Si un logiciel est plus gros que l'autre, à supposer que ceux qui le conçoivent ont le même niveau de compétence, c'est qu'il y a une raison.

Win10 est plus "gros" que XP, et ce N'EST PAS un problème puisqu'ils ne font pas la même chose.

Arrêtes maintenant de te fixer sur des points comme ça et écoutes un peu ce qu'on te dit.

Henri K.

[Gallium nitride]

Donc quand LM communique fièrement sur les 20 millions de lignes de code (ALIS + ensemble avionique/système d'arme), c'est absurde?

[TarpTent]

Le 14 août 2016 à 19:15, Dorfmeister a dit :

Bien évidemment, vu que "tu fais ce que tu veux" et que je respecte ta position à 2.000% je te laisse chercher ton rapport sur le PAK FA par toi-même, "œuf corse"  (ouais avec un petit smiley ça passe toujours mieux)

Ce qui revient précisément au cas que j'abordais concernant le F35 : s'il existait l'équivalent des rapports officiels pour le PAK FA que l'on a pour le F35, ainsi que des retours des think tank et autres articles, ils seraient tout autant commenté et débattu ici.

Parce que ces rapports-là, s'ils existaient, vous les auriez vous même indiqué ici.

Il n'y a là nulle indulgence de notre part concernant les appareils russes et chinois, juste que la littérature officielle est nettement plus abondante et détaille bien plus les aléas du Programme F35 par les américains eux-mêmes qu'on en a sur les 2 autres appareils.

C'était précisément là le sens de ma réponse à Pascal. Je maintiens ce que je disais.

il y a 23 minutes, Gallium nitride a dit :

Donc quand LM communique fièrement sur les 20 millions de lignes de code (ALIS + ensemble avionique/système d'arme), c'est absurde?

Ca dépend auprès de qui il communique. N'importe quel décideur ou parlementaire, s'il a la connaissance que j'ai de ce que doit être un logiciel embarqué - c'est à dire quasi-nulle - sera impressionné.

Si le but est de démontrer à des néophytes, des investisseurs financiers et/ou à l'américain moyen qu'il doit faire montre d'un peu d'indulgence parce que l'appareil est particulièrement riche en codes - ce qui démontre sans aucun doute sa haute technicité - et qu'à ce titre il est normal qu'il puisse y avoir une période significative de mise au point avec son cortège de bugs, ils y arrivent nécessairement en diffusant ce type d'informations.

Maintenant, auprès des vrais sachants, il semble que la perception ne soit pas du tout la même, ce que nous explique et nous montre Pic, notamment. Mais comme ils ne sont doute pas les principales cibles de cette communication, LM peut tout à fait et sans aucune absurdité continuer à communiquer en ce sens.

[Henri K.]

il y a une heure, Gallium nitride a dit :

Donc quand LM communique fièrement sur les 20 millions de lignes de code (ALIS + ensemble avionique/système d'arme), c'est absurde?

Il n'y a rien à en être fier et il n'y a pas d'absurdité non plus. Le nombre de ligne est juste l'un des indicateurs parmi tant d'autres pour illustrer la complexité des softs.

Et encore... On peut faire 20 millions de ligne de commentaire + 3 lignes qui se compilent pour afficher "Hello World"...

Il ne faut pas nous acharner là dessus.

Henri K.

[zx]

Je suis un peu hs

Normalement, les compteurs des lignes de commentaires et le code sont séparés. les commentaires sont normalisés pour produire la javadoc (java) ou par doxgyen(c/c++), c'est la documentation qu'on doit livrer avec le code à chaque release.

exemple d'un écran d'un utilitaire free de couverture de code  bien connu dans le monde java, y en a plein d'autres, selon ce qu'on souhaite avoir comme stat.

20 millions de ligne de code, c'est sans commentaire. maintenant si il y a du code produit par des générateurs, ca fait grossir.

 

 

 

 

Modifié le 18 août 2016 par zx