Discussion :

[CaféFort]

Non. La démarche agile part du constat que la demande peut changer tardivement. Partant de ce constat, elle met en place des méthodologies qui acceptent l'évolution.

Ok, mais quoi concrètement ? Tu connais bien la signification de méthodologie ? (mettre des post'it sur un tableau n'est pas une méthodologie)

Non, mais tu as travaillé sur autre chose que des pages blanches? Parceque tout ça, ça me parait bien naif et théorique.

des pages blanches , naîf, théorique ...

Certainement 300 000 à 400 000 lignes de code (juste pour moi) en mode MDE (Model Driven Engineering), l'utilisation des design pattern ... etc. Des applications utilisées partout dans le monde et sans bug (et forcément qui évoluent), l'informatique normale quoi .
L'avantage, c'est que la doc n'est pas faite à la main, mais toujours sous la main et synchronisée avec le code. Les exigences du projets (specs) sont reliées à la conception, une vraie méthodologie .

De plus, on conçoit avec le modèle et on génère le code, mais on peut aussi modifier le code et on synchronise le modèle. La liberté ! Pas de surcharge de travail pour faire de la doc, et le tout ... up to date !

Je passe tous les autres avantages et ils sont nombreux. Ça ne fait pas de bruit, mais ça marche ... à condition d'être un peu organisé, c'est à dire avoir une vraie méthodologie.

Cela fait bientôt 10 ans qu'on travaille comme cela et en réseau étendu.

[Laurent 1973]

Certainement 300 000 à 400 000 lignes de code (juste pour moi) en mode MDE (Model Driven Engineering), l'utilisation des design pattern ... etc. Des applications utilisées partout dans le monde et sans bug (et forcément qui évoluent), l'informatique normale quoi .
L'avantage, c'est que la doc n'est pas faite à la main, mais toujours sous la main et synchronisée avec le code. Les exigences du projets (specs) sont reliées à la conception, une vraie méthodologie .

De plus, on conçoit avec le modèle et on génère le code, mais on peut aussi modifier le code et on synchronise le modèle. La liberté ! Pas de surcharge de travail pour faire de la doc, et le tout ... up to date !

Je passe tous les autres avantages et ils sont nombreux. Ça ne fait pas de bruit, mais ça marche ... à condition d'être un peu organisé, c'est à dire avoir une vraie méthodologie.

Cela fait bientôt 10 ans qu'on travaille comme cela et en réseau étendu.

Génial, vous avez une super organisation alors pourquoi changer?
Si votre travail est de qualité et que tout le monde s’épanouit dans votre organisation, gardez là.

Tu n'as en effet nullement besoin de changer de façon de travailler, vous n'avez que succès sur succès.
Oublie les méthodes truc ou machin, vous avez trouver la bonne façon de travailler qui vous correspond.

[CaféFort]

Génial, vous avez une super organisation alors pourquoi changer?
Si votre travail est de qualité et que tout le monde s’épanouit dans votre organisation, gardez là.

Tu n'as en effet nullement besoin de changer de façon de travailler, vous n'avez que succès sur succès.
Oublie les méthodes truc ou machin, vous avez trouver la bonne façon de travailler qui vous correspond.

Merci pour ton aide, je n'y avais pas pensé .

Un forum est fait pour échanger des points de vue. Je sollicite donc des points de vue, mais c'est bien difficile ... C'est vrai qu'avec ta réponse, j'imagine que tu ne changes pas souvent grand chose.
Rien n'est aussi radical que ce que tu écris. Je ne prétends pas avoir l'organisation parfaite non plus. En détaillant notre organisation, j'ai juste répondu à une remarque à la fois fausse et pas très sympa.

[Luckyluke34]

Aie ! Si ça l'était, on aurait des projets toujours livrés à l'heure sans dépassement de budget

Et si j'ai mon parapluie, c'est qu'il pleut ? Erreur de logique (modus ponens) !!

Tu confonds (ou as fait exprès d'amalgamer) modus ponens et non sequitur. Ton exemple sur le parapluie est un non sequitur donc invalide, mon cheminement logique est un modus ponens (ou tollens, plutôt) donc valide.

Non sequitur

S'il pleut, alors je sors mon parapluie
Je sors mon parapluie
Donc il pleut

Si A alors B
B
Donc A <==== incorrect

Modus tollens

Si la conduite de projets était une science exacte, alors on aurait des projets toujours livrés à l'heure sans dépassement de budget
Les projets ne sont pas toujours livrés à l'heure ou sans dépassement de budget
Donc la conduite de projets n'est pas une science exacte

Si A alors B
B est faux
Donc A est faux <==== correct

Mon raisonnement est parfaitement valable en termes de logique. Maintenant tu peux contester la prémisse (Si la conduite de projets était une science exacte, alors on aurait des projets toujours livrés à l'heure sans dépassement de budget) mais ça n'a rien à voir avec un non sequitur.

[CaféFort]

Je cherchais des avis mais je perds largement mon temps. A chaque question que je pose, tes réponses bifurquent sur d’autres sujets. Maintenant tu embrayes sur la qualification de l’erreur de raisonnement que tu as faite il y a une semaine. C’est inintéressant au possible, bien loin du titre de la discussion et ce comportement est clairement nuisible au forum.

Je reprends une dernière fois tes propos :

1/ Quand je dis que ce n'est pas une science exacte, je ne parle pas du développement mais de la rédaction de specs et de la conduite de projets. Si ça l'était, on aurait des projets toujours livrés à l'heure sans dépassement de budget et qui satisfont pleinement les utilisateurs de la même manière qu'on a des avions qui volent à tous les coups grâce à la science. Or, ce n'est pas le cas.

Donc je résume, tu dis : « si c’était une science exacte, on aurait des projets toujours livrés à l’heure ». (lol)

Tu voulais démontrer que les projets ne reposent pas sur la base d’une science exacte et donc selon toi : « les projets ne sont pas toujours livrés à l’heure, donc ce n’est pas une science exacte ».

Je vais prendre la même construction de phrase que la tienne : « Comme les erreurs de calcul existent, les maths ne sont pas une science exacte. »

Et là, tu fais une erreur de logique. Les erreurs de calcul existent, alors que les maths sont bien une science exacte.

Forcément tes réponses nous éloignent sans cesse de la discussion. La remise en question des méthodes agiles semblent te déranger fortement et c'est dommage.

C’est comme un de tes messages précédents, lorsque tu émets la même erreur de raisonnement (et que j’ai laissé passer) quand tu dis que « la méthode est beaucoup utilisée dans le monde », donc « c’est qu’elle est valable ». Bah non, cela ne prouve rien : Il y a beaucoup de guerres dans le monde, mais personnellement je ne considère pas la guerre comme une bonne chose.

C’est le raisonnement avec les outils logiques et la remise en question qui m’amènent à avoir un avis. Nous sommes nombreux ainsi. Cela ne semble visiblement pas être ton cas.

[CaféFort]

@Laurent 1973 : Je reprends ici tes éléments, tu t'étais trompé de discussion .

Je disais que les méthodes agiles, c'est un peu comme :

- Je pars de Paris et je veux aller à Marseille
- On me donne une carte pour les 500 premiers kilomètres (et encore, 500 c’est bcp)
- Je demanderai tous les 50 km s’il faut que j’aille à droite, à gauche ou tout droit.

C'est Agile ou c'est guimauve ? Ce principe semble valable uniquement dans des cas bien particuliers, alors qu'Agile en fait une généralité.

et tu répondais :

Et ton analogie n'est pas du tout la bonne en plus.

Je prendrais plutôt celle du bateau qui va de Brest à New-York: il ne bloque pas sa barre du début à la fin "plein ouest" suivant sa spécification précise, il regarde régulièrement son GPS pour voir s'il ne dérive pas.
Par contre, il prépare bien sa route avant: regarde la carte, la météo, les trafic maritime, ... mais il va adapter sa route tout le long par ce qu'il sait que sa route ne peux pas être totalement déterministe suivant les vents, les courants ou tout avarie ou anomalie qu'il peux rencontrer.

Concernant la métaphore. C'est plutôt la tienne qui me semble assez irréelle. N'oublions pas que la finalité est de créer un produit logiciel qui sera stable. Alors autant amener cette stabilité le plus tôt possible, puisque de toute façon, stabilité il y aura (je ne pense pas que ton code s'auto-modifie). Et ce n'est pas du tout contradictoire avec le fait que l'application devra pouvoir évoluer ensuite, mais pas à 100%, ni à 50%, ni à 30 %, ni à ... etc.

Si tu veux poursuivre dans ton sens, il faudrait déjà remettre ton message dans la bonne discussion (c'est fait !) et que tu énumères les causes de dérives auxquelles tu penses parce que j'aimerais vraiment en savoir plus sur "les vents, les courants ou tout avarie ou anomalie" que tu énonces dans le cadre du développement d'un produit qui au final, sera stable (à moins que tu adores les modifications en exploitation avec changement de structure de la base de données, conversions de formats, ... et qui coûtent extrêmement cher !! Qui peut se permettre cela ?).


J'espère que tu me répondras au lieu de disliker, ce qui ne sert à rien du tout .

[souviron34]

Ca fait un moment que j'étais pas repassé dans cette section, et je vois qu'il y a toujours le même style de questions, et avec la même attitude...

J'espère que tu me répondras au lieu de disliker, ce qui ne sert à rien du tout .

Quand tu apprendras à considérer que les gens qui te répondent sur ce forum ne sont pas des idiots, et que tu ne détiens pas La Vérité, peut-être que tu pourras obtenir une discussion intéressante...

Là tu poses des questions mais chaque fois qu'on y répond en posant des arguments tu dénigres les arguments... et les personnes... Donc en fait tu poses des questions juste pour affirmer ce que tu crois vrai....

Ca ne fait pas de toi quelqu'un de très intéressant avec qui discuter...

Mais un logiciel à maintenir, c'est mieux avec un "plan". Car c'est simple, tous les intervenants vont devoir explorer le code. C'est en général plus long d'explorer que de faire quelques schémas. La galère est pour ceux qui récupèrent l'ensemble.

« pas mal de ressources en l’air pour rien » : pourtant tout le monde sait qu’une modification tardive coûte 10 à 100 fois plus cher. C’est une bonne raison pour fignoler les specs, non ?
« que le programmeur doit adapter lui-même » : ça, justement, c’est exactement la cause de la majorité des échecs des projets. Le programmeur invente ce qui n’a pas été décrit ! Surtout ne jamais faire cela !!!
....
Pourtant la majorité des processus de développement sont itératifs.
...
Je connais des projets de plusieurs centaines de milliers de lignes qui sont super bien foutu et totalement bugfree, mais si on n'a que le code source, bonjour l’investissement en temps pour comprendre le fonctionnement.
Même dans un projet simple, la documentation fait gagner beaucoup de temps. C’est assez naturel non ?

Je crois juste que :

• tu ne sais pas de quoi tu parles réellement dans le développement de projets..
• tu as des idées fausses et sur le développement en V et sur l'approche Agile

J'AI TOUJOURS travaillé depuis plus de 30 ans sur des projets au minimum de 200 à 300 000 lignes, mais aussi au moins 4 d'au moins 2 millions de lignes...

Déjà, dans un développement traditionnel en V, la documentation d'une part est faite AVANT le développement, du global au détail le plus poussé, mais surtout il y a des dizaines de documents différents, faits par plusieurs personnes, et qui sont des références immuables.... (spec système, dictionnaire système, spec logicielle, dictionnaire logiciel, analyse logicielle, conception préliminaire, conception détaillée, tests unitaires, tests fonctionnels, tests systèmes...)

Ce qui signifie que si quelque chose doit être modifié plus tard, par une impossibilité technique, une évolution technologique, une évolution de la demande du client, ou tout simplement une mauvaise analyse, il faudrait normalement faire remonter ces différences dans les centaines de documents y référant, y compris les plus anciens comme l'analyse système ou la spécification fonctionnelle initiale..

Or, en dehors de la taille, il y a la durée.... De tels projets durent en général au moins 10, sinon 15 30 ou 40 ans.... Avec des équipes de 30, 40, 60, 100 personnes... Qui bien entendu ne restent pas "statiques".. Des gens démissionnent, partent à la retraite, etc etc..

• Donc primo la base c'est que la documentation n'est JAMAIS à jour...
  
  
• Secondo, comme les documentations sont faites a priori, avant le développement, il peut y avoir des écueuils, que ce soit techniques ou de faiblesse ou inadéquations des demandes des clients (par exemple parce que pendant la durée mise pour faire les docs puis le logiciel la technologie a evoluée et les clients, dans une autre partie de leur travail, ont utilisé cette nouvelle techno et veulent la voir integrée dans le logiciel en question) , etc etc.. Comme dit plus haut, ces modifications peuvent entraîner éventuellement jusqu'à la re-structuration de l'architecture globale, et donc les documents de plus haut niveau...
  
  
• Tertio, au vu du point précédent, les documents peuvent facilement remplir une pièce complète, des dizaines de milliers de pages... Qu'il faudrait que chacun lise absolument avant de penser à faire une ligne de code... (résultat : pour ta remarque, c'est souvent beaucoup plus simple et rapide d'explorer le code que la doc )
  
  
• Quarto, compte-tenu des points précédents, sans même changer tout, il peut y avoir un changement de langage de programmation, qui peut impliquer une refonte totale de la documentation (par exemple une spec faite sur un langage impératif, et à un moment donné on décide de passer à un langage objet, ou l'inverse)...
  
  
• Quinto, le découpage taylorien des cycles en V/cascade dans les équipes produit des erreurs ("téléphone arabe") qui se propagent au cours du temps, et produisent de plus des structures décisionnelles innapropriées en temps et en actions (faire un document préparatoire à présenter au chef d'équipe, qui doit prévoir une réunion des chefs d'équipes, qui doivent discuter sur un nouveau document préparé par le chef d'équipe pour eux, qui vont le modifier, puis qui va être retranscris, etc etc), ce qui fait que pour changer une chose il peut falloir jusqu'à un an avant d'avoir la réponse, si le projet et l'équipe sont gros... et de 4 à 6 retranscriptions...
  
  
• Sexto, justement dans des gros projets, en général donc tu n'as plus la documentation, ou alors elle n'est de loin plus à jour..
  
  
• Et enfin, comme je l'ai déjà dit plusieurs fois, l'Agilité n'est pas une méthodologie, mais une approche... Que moi je préfère appeler "Centrée utlisateur" (User-centered design).. Elle ne dit pas d'enlever la documentation, mais de ne pas en faire ni une fin en soi (ce qui est le cas du cycle traditionnel: à faire avant la moindre ligne codée), ni une bible (c'est a dire que même si c'est marqué, mais qu'il y a un inconvénient ou une meilleure solution, on ne prend pas, alors qu'en traditionnel il faut justement réunir tous les responsables au plus haut niveau, architectes logiciels et organiques, directeur de projet, chef de projet, comités d'utilisateurs, etc etc, et ça va prendre des mois parce que ça remet tout en cause), ni une contrainte exhaustive (on choisit en fonction du projet et des intervenants ce qu'on doit avoir comme documentation... et non pas comme en traditionnel a priori pour tous les types de projets avoir toute la documentation, de A à Z, dans l'ordre..).. Mais enfin et surtout cela repose sur l'évolution d'un projet, et une souplesse par rapport à la taille et aux intervenants.. Et tout ceci a pour conséquence que et l'équipe de dev et les utilisateurs sentent qu'ils avancent et sont motivés et soutiens et réactifs.... vis-à-vis de tout changement.. d'un côté comme de l'autre...

En gros, le Manifeste Agile est parfaitement sérieux, mais il pré-suppose des gens ayant suffisamment d'expérience dans le développement "traditionnel" pour savoir quoi éliminer à quels stades, et se faire confiance mutuellement pour éliminer les besoins de hiérarchie "traditionnels" et contraintes y afférent..


Pour ma part je préconise une tête de projet bi-céphale, avec un utilisateur-expert (expert ET reconnu par ses pairs) en permanence, associé à un chef de projet informaticien généraliste, et une équipe travaillant ensemble dans le même local... avec l'utilisateur-expert







** et petite note : l'itérativité d'un développement en V/cascade se fait une fois que les clients ont vu la première version.. Si il y a une itération, c'est qu'ils ne sont pas satisfaits . : ils ont payé, on leur a assuré qu'ils auraient le logiciel qui ferait ce qu'ils désiraient au bout de tant de mois/années, parce qu'ils avaient affaire à des pros, et pouffff ... tout ça pour ça .. D'où tout un tas de problèmes : méfiance accrue de eux envers l'informatique, frustation voire colère de l'informatique envers eux ("ils savent pas ce qu'ils veulent"), délais raccourcis pour la nouvelle version, contraintes financières, en bref insatisfaction de part et d'autre, etc.... Pourquoi faire compliqué et mauvais en termes humains et financiers (voire en image de marque) alors qu'on peut faire mieux, pour moins cher, et plus relax ??

[CaféFort]

Merci souviron34 pour ta réponse.

Quand tu apprendras à considérer que les gens qui te répondent sur ce forum ne sont pas des idiots, et que tu ne détiens pas La Vérité, peut-être que tu pourras obtenir une discussion intéressante...

Là tu poses des questions mais chaque fois qu'on y répond en posant des arguments tu dénigres les arguments... et les personnes... Donc en fait tu poses des questions juste pour affirmer ce que tu crois vrai....

Ca ne fait pas de toi quelqu'un de très intéressant avec qui discuter...

C’est surprenant de s’exprimer ainsi. Tu aurais dû ajouter d'autres extraits si tu en trouves car celui-ci, que tu as cordialement copié démontre justement l’inverse ! J’espère que tu vas me répondras sur ce point car jusqu’à maintenant vous semblez être plusieurs à penser cela mais personne ne donne d’exemple extrait de mes propos. C’est dommage, ça fait perdre du temps à tout le monde. Moi, je commence à m'y faire .

Je crois juste que :

• tu ne sais pas de quoi tu parles réellement dans le développement de projets..
• tu as des idées fausses et sur le développement en V et sur l'approche Agile

Bah, c’est pas super gentil d’écrire cela, surtout que tu ne me connais pas et tu ne connais pas mon expérience non plus. Là aussi, c’est dommage car tu aurais dû dire ce qui ne te convient pas « techniquement » dans mes propos. Ça donne uniquement l'impression que mes questions dérangent et que personne n'a d'argument valables.

J'AI TOUJOURS travaillé depuis plus de 30 ans sur des projets au minimum de 200 à 300 000 lignes, mais aussi au moins 4 d'au moins 2 millions de lignes...

Oui, et donc ?? Que veux-tu dire ?

Déjà, dans un développement traditionnel en V, la documentation d'une part est faite AVANT le développement, du global au détail le plus poussé, mais surtout il y a des dizaines de documents différents, faits par plusieurs personnes, et qui sont des références immuables.... (spec système, dictionnaire système, spec logicielle, dictionnaire logiciel, analyse logicielle, conception préliminaire, conception détaillée, tests unitaires, tests fonctionnels, tests systèmes...)

Ce qui signifie que si quelque chose doit être modifié plus tard, par une impossibilité technique, une évolution technologique, une évolution de la demande du client, ou tout simplement une mauvaise analyse, il faudrait normalement faire remonter ces différences dans les centaines de documents y référant, y compris les plus anciens comme l'analyse système ou la spécification fonctionnelle initiale..

Or, en dehors de la taille, il y a la durée.... De tels projets durent en général au moins 10, sinon 15 30 ou 40 ans.... Avec des équipes de 30, 40, 60, 100 personnes... Qui bien entendu ne restent pas "statiques".. Des gens démissionnent, partent à la retraite, etc etc..

« une impossibilité technique » : ha ! ça ressemble à une grosse erreur qui aurait dû être levée en tout début de projet.

« une évolution technologique » : ça ressemble à un mauvais choix en tout début de projet aussi.

« une mauvais analyse » : on a compris ce que j’allais écrire.

« un projet qui dure depuis 40 ans » ha oui, ils ont commencé tôt … j’espère que ce sera bientôt terminé. C'est une cathédrale peut-être ? Heu, non car ils avaient un plan. Tu veux peut-être parler d’année-homme, non ? Parce que là, j’ai du mal à comprendre. A moins que tu parles d’un projet qui a été créé il y a bien longtemps et qui est toujours en exploitation et toujours sans documentation. Maintenant est-ce que c’est bien et est-ce que tout le monde est satisfait de cette situation ? C’est juste ça ma question .

[LIST][*]Donc primo la base c'est que la documentation n'est JAMAIS à jour...

Mais si c’était possible, ce serait bien selon toi ? (parce qu’il y a bcp de sociétés où c’est possible, après c’est une question de choix).

[*]Secondo, comme les documentations sont faites a priori, avant le développement, il peut y avoir des écueuils, que ce soit techniques ou de faiblesse ou inadéquations des demandes des clients (par exemple parce que pendant la durée mise pour faire les docs puis le logiciel la technologie a evoluée et les clients, dans une autre partie de leur travail, ont utilisé cette nouvelle techno et veulent la voir integrée dans le logiciel en question) , etc etc.. Comme dit plus haut, ces modifications peuvent entraîner éventuellement jusqu'à la re-structuration de l'architecture globale, et donc les documents de plus haut niveau...

Tu crois que dans les autres secteurs industriels, on ne revoit pas l’architecture ?

[*]Tertio, au vu du point précédent, les documents peuvent facilement remplir une pièce complète, des dizaines de milliers de pages... Qu'il faudrait que chacun lise absolument avant de penser à faire une ligne de code... (résultat : pour ta remarque, c'est souvent beaucoup plus simple et rapide d'explorer le code que la doc )

remplir une pièce !!! Sinon, il existe des outils informatiques (des logiciels) qui évitent de remplir les pièces avec des listings. En plus cela permet de les organiser facilement. Il existe beaucoup de moyens pour cela avec les technos d’aujourd’hui. Est-ce que tu peux m’expliquer comment tu fais avec tes projets de 2 000 000 de lignes de code. Je ne demande qu’à apprendre. On dirait du « application-mining » manuel en parcourant des pages et des pages de listings.

[*]Quarto, compte-tenu des points précédents, sans même changer tout, il peut y avoir un changement de langage de programmation, qui peut impliquer une refonte totale de la documentation (par exemple une spec faite sur un langage impératif, et à un moment donné on décide de passer à un langage objet, ou l'inverse)...

Un changement de langage qui implique une refonte totale de la doc. Donc tu veux dire qu’il vaut mieux ne pas faire de doc ... puisqu'elle sera périmée. Je comprend. Mais est-ce une bonne chose ? Ne faudrait-il pas envisager de travailler autrement ?
Pour info, les langages objet sont (les plus connus) des langages impératifs et les deux notions ne sont pas exclusives l'une de l'autre. Tu voulais certainement dire "passer d’un langage procédural à un langage orienté objet" qui sont des caractéristiques exclusives l'une de l'autre.

[*]Et enfin, comme je l'ai déjà dit plusieurs fois, l'Agilité n'est pas une méthodologie, mais une approche...

l’informatique serait donc une exception industrielle qui devrait être ainsi pour toutes les raisons que tu évoques. Et tu crois que tous les logiciels sont conçus de cette manière ?

En gros, le Manifeste Agile est parfaitement sérieux, mais il pré-suppose des gens ayant suffisamment d'expérience dans le développement "traditionnel" pour savoir quoi éliminer à quels stades, et se faire confiance mutuellement pour éliminer les besoins de hiérarchie "traditionnels" et contraintes y afférent..

Quoique, le jour de la paye, la hiérarchie traditionnelle on en a un peu besoin quand même .

Pour ma part je préconise une tête de projet bi-céphale, avec un utilisateur-expert (expert ET reconnu par ses pairs) en permanence, associé à un chef de projet informaticien généraliste, et une équipe travaillant ensemble dans le même local... avec l'utilisateur-expert

Sur ce point, je suis entièrement d’accord. Mais est ce que c’est un principe agile cela ?

alors qu'on peut faire mieux, pour moins cher, et plus relax ??

Bah c’est presque magique. C'était pourtant simple.


J’aimerais avoir quelques précisions sur ton bas de page et j’espère que tu me répondras.

« architecture complexe » : c’est quoi pour toi une architecture complexe ?

« Grosses applications critiques » : c’est quoi « critique » pour toi ? Et comment gères-tu la criticité ?

« C, Fortran … » : Effectivement avec des langages procéduraux, le problème de documentation n’est pas le même qu’avec les langages orientés objets.

[souviron34]

C’est surprenant de s’exprimer ainsi. Tu aurais dû ajouter d'autres extraits si tu en trouves car celui-ci, que tu as cordialement copié démontre justement l’inverse ! J’espère que tu vas me répondras sur ce point car jusqu’à maintenant vous semblez être plusieurs à penser cela mais personne ne donne d’exemple extrait de mes propos. C’est dommage, ça fait perdre du temps à tout le monde. Moi, je commence à m'y faire .

Au hasard, dans quasi chacun de tes posts :

la doc technique est par nature toujours synchronisée et cela, sans travail ! La prise de connaissance d’un projet s’en trouve facilitée d’autant et le travail des développeurs aussi.
....
Pourtant, c’est ce qui existe dans les autres domaines. Les normes n’ont jamais empêché la créativité.

C’est un décret ? Bien sûr, cette phrase ne prouve rien. Moi il me faut du concret, du raisonnement.
...
« pas mal de ressources en l’air pour rien » : pourtant tout le monde sait qu’une modification tardive coûte 10 à 100 fois plus cher. C’est une bonne raison pour fignoler les specs, non ?
...
Pourtant la majorité des processus de développement sont itératifs.
...
Je connais des projets de plusieurs centaines de milliers de lignes qui sont super bien foutu et totalement bugfree, mais si on n'a que le code source, bonjour l’investissement en temps pour comprendre le fonctionnement.

C’est donc que la spec a été mal faite. Malheureusement c’est souvent le cas et c’est d’ailleurs une activité qui peut se révéler très difficile.

Bah non. On prend juste un type qui a une démarche structurée et qui ne se laisse pas embobiner ni par les utilisateurs, ni par ses supérieurs . C'est vrai que c'est rare.
...
Faux !! Justement, le développement est une science exacte. La démarche existe. On n'est pas en biologie !! Et les méthodes Agiles nous feraient croire qu'on ne serait pas dans une science exacte !!

C'est sûr que moins on détaille, moins on risque de se tromper.
...
Pourtant on finit bien par y arriver, d'une manière ou d'une autre à ces specs parfaites. C'est donc humain.

Ok, mais quoi concrètement ? Tu connais bien la signification de méthodologie ? (mettre des post'it sur un tableau n'est pas une méthodologie)
...
des pages blanches , naîf, théorique ...
...
Des applications utilisées partout dans le monde et sans bug .... Les exigences du projets (specs) sont reliées à la conception, une vraie méthodologie .
...
Je passe tous les autres avantages et ils sont nombreux. Ça ne fait pas de bruit, mais ça marche ... à condition d'être un peu organisé, c'est à dire avoir une vraie méthodologie.

Merci pour ton aide, je n'y avais pas pensé .
....
Rien n'est aussi radical que ce que tu écris. Je ne prétends pas avoir l'organisation parfaite non plus. En détaillant notre organisation, j'ai juste répondu à une remarque à la fois fausse et pas très sympa.

C'est plutôt la tienne qui me semble assez irréelle. N'oublions pas que la finalité est de créer un produit logiciel qui sera stable. Alors autant amener cette stabilité le plus tôt possible, puisque de toute façon, stabilité il y aura (je ne pense pas que ton code s'auto-modifie). Et ce n'est pas du tout contradictoire avec le fait que l'application devra pouvoir évoluer ensuite, mais pas à 100%, ni à 50%, ni à 30 %, ni à ... etc.
....
J'espère que tu me répondras au lieu de disliker, ce qui ne sert à rien du tout .

Tous ces extraits démontrent et une très haute opinion de ce que tu fais et un dénigrement des autres et de leurs arguments et expériences, et, en passant, une méconnaissance totale du vrai monde...




Une stabilité ? Une application "bug-free" ? Un lien direct entre doc et code ? Des specs parfaites ? Un développement une science exacte ???



Dans quel monde vis-tu ??

Autant d'absurdités et d'affirmations que tout un chacun ayant un tant soit peu de bouteille sait pertinement fausses affirmées avec un aplomb relèguant tous les autres participants au rang d'idiots ou de ne connaissant pas le métier n'est pas vraiment un bon signe... ni une preuve de bonne foi ou d'ouverture sur les réponses à tes questions...

Bah, c’est pas super gentil d’écrire cela, surtout que tu ne me connais pas et tu ne connais pas mon expérience non plus. Là aussi, c’est dommage car tu aurais dû dire ce qui ne te convient pas « techniquement » dans mes propos. Ça donne uniquement l'impression que mes questions dérangent et que personne n'a d'argument valables.

On te répond, au dessus, et tout ce que tu trouves à dire c'est que c'est faux, toi tu sais, vous vous avez la méthode parfaite, et tout une série d'affirmations comme celles citées ci-dessus, qui visiblement sont le fait de quelqu'un qui n'a pas beaucoup d'expérience de gros projets industriels, mais qui pense qu'il détient le Graal et veut donner des leçons à tous, , c'est tout...

Oui, et donc ?? Que veux-tu dire ?

Ce que j'explicite dans le premier paragraphe...

Je n'ai strictement jamais vu de ma vie un environnement dans lequel la doc était à jour, les specs parfaites, le développement une science exacte, et un outil pouvait tranquillement générer une synchronicité entre code et doc...Et encore moins dans un cycle en V/cascade qu'ailleurs...

« une impossibilité technique » : ha ! ça ressemble à une grosse erreur qui aurait dû être levée en tout début de projet.

Ah oui ?? Etrange, hein ..

Tu définis une API pour une fonction d'interfaçage avec une machine (écran ou autre). Tu fais une conception detaillée en suivant la logique de la construction de cette machine ou écran... (par exemple que le faisceau balaiera l'écran du haut en bas et de droite à gauche, et que donc l'adressage des pixels sera dans cet ordre)

Puis au moment de coder/tester, comme tu viens de recevoir justement le matériel, tu t'aperçois que, pour une raison X ou Y, le constructeur a pas pris cette logique mais une logique inverse...

Impossible à lever en début de projet, tu le sais pas, tu dépends d'un autre constructeur.... Et pourtant alors il te faudra réviser ta conception détaillée....

Autre exemple : tu fais un logiciel qui va récupérer des données dans une BD mise à jour par un satellite... D'après les specs initiales, le satellite devrait avoir un débit de XX... Tu te bases dessus.... Mais, une fois le satellite lancé, le constructeur s'aperçoit qu'avec ça il capte trop de signal (nombres ou types d'événements imprévus mais utiles).... ta base recoit XX * 100 en débit... que tu veux garder... ne correspond pas a la spec initiale (impossibilité réelle de connaître le vrai nombre d'évènements avant la mise en service)

« une évolution technologique » : ça ressemble à un mauvais choix en tout début de projet aussi.

Si ton projet dure 10 ans ou plus, il y a de bonnes chances que tu n'aies pas pu prévoir où s'en allait la technique... Et comme il te fallait un plan, tu fais tes specs avec ce que tu as de plus en pointe...

En 1998, les smartphones n'existaient pas, il y avait juste des "pagets" sur lesquels tu avais un message texte de 10 lettres (ou numéro de tel à rappeller). En 2004 il y avait des portables...

En 1989 les écrans tactiles nécessitaient le doigt.. En 1993 on avait inventé le stylet...

En 2009 les tablettes n'existaient pas...

« une mauvais analyse » : on a compris ce que j’allais écrire.

Sauf que tu n'as peut-être pas été exhaustif, et que tu n'as pas vu qu'il y avait d'autres "intrants" (une nouvelle loi, de nouvelles pratiques, des liens avec quelque chose qui n'était pas informatisé du temps où tu as fait l'analyse, un mauvais questionnement des utilisateurs au début (il y a beaucoup de choses qu'ils font inconsciemment), etc etc)

« un projet qui dure depuis 40 ans » ha oui, ils ont commencé tôt … j’espère que ce sera bientôt terminé. C'est une cathédrale peut-être ? Heu, non car ils avaient un plan. Tu veux peut-être parler d’année-homme, non ? Parce que là, j’ai du mal à comprendre. A moins que tu parles d’un projet qui a été créé il y a bien longtemps et qui est toujours en exploitation et toujours sans documentation. Maintenant est-ce que c’est bien et est-ce que tout le monde est satisfait de cette situation ? C’est juste ça ma question .

Non, je parle de projets sur 15 ou 20 ans, avec 60 à 100 personnes travaillant à temps plein, et des budgets de quelques dizaines de millions à quelques milliards....

1 000 à 80 000 voire 150 000 ou 500 000 jour-homme... ou 1000 année-homme (mais c'est vrai aussi dès que c'est supérieur à 4 ou 5 année-homme)

Mais si c’était possible, ce serait bien selon toi ? (parce qu’il y a bcp de sociétés où c’est possible, après c’est une question de choix)

Peut-être, peut-être pas...

Comme je te dis, quand tu as des centaines de milliers de pages (mais même quelques dizaines de milliers, voire quelques milliers seulement **), à moins que tu sois le nouveau chef (et même là car on te demande d'être opérationnel assez vite), il y a peu de chances que tu préfères les lire plutôt que de plonger directement dans le code et les répertoires...

Mais de toutes façons ça n'est pas possible : encore une fois je n'ai jamais vu une doc à jour. pour un gros projet..


** Tu fais une doc juste d'installation d'un soft qui fait plus qu'une page, il y a de bonnes chances que même le responsable de l'installation au sein de l'équipe info ne la lise pas...

*** on t'envoie analyste-programmeur sur un projet, il y a bien peu de chance que tu ailles lire la spec système, et ce que le logiciel est censé faire en totalité, à part lire la doc qu'on te donne... restreinte à ta partie...

Tu crois que dans les autres secteurs industriels, on ne revoit pas l’architecture ?

Il y a peu de chance que quand un bâtiment est fini on décide de le raser pour un reconstruire un autre à sa place parce que des clients se plaignent... On va trouver les clients à qui ça convient...

Et même quand des clients se plaignent (Palais de Justice de Bordeaux ou de Marseille), on ne détruit pas le bâtiment.. Ils n'ont qu'à faire avec...

remplir une pièce !!!

Absolument... 500 000 à 10 millions de pages de docs... de 100 à 1000 classeurs...

Et encore ce sont des projets "normaux", réguliers dans l'industrie ou les grands projets nationaux.


Un projet comme le logiciel de la station spatiale ISS c'est 50 ans de durée de vie, 35 ans de programmation dans 88 pays, dont 15 ans à 20 ans à préparer la doc... et induire des modifications dans presque tous les langages (c'est l'origine du vrai calcul matriciel en Fortran, par exemple. Ecrire "A = B * C" où A, B, et C sont des matrices vient de ces specs).

Donc la quantité de doc est absolument impressionante...

Mais j'ai vu des pièces entières pour un projet de 2 millions de lignes, 60 personnes, 15 ans, et 80 millions, et dont l'architecte (qui était le même depuis le début du projet) n'avait plus aucune connaissance des documents de départ, ne savait même plus où ils étaient, et se fiait à sa structure de BD qui prenait tout un mur devant son bureau...

Est-ce que tu peux m’expliquer comment tu fais avec tes projets de 2 000 000 de lignes de code. Je ne demande qu’à apprendre. On dirait du « application-mining » manuel en parcourant des pages et des pages de listings.

Si tu es curieux, et que ton emploi t'en donne le loisir, tu fouilles... Sinon tu suis bêtement ce qu'on te donne à faire..

Pour info, les langages objet sont (les plus connus) des langages impératifs et les deux notions ne sont pas exclusives l'une de l'autre. Tu voulais certainement dire "passer d’un langage procédural à un langage orienté objet" qui sont des caractéristiques exclusives l'une de l'autre.

Oui..

l’informatique serait donc une exception industrielle qui devrait être ainsi pour toutes les raisons que tu évoques. Et tu crois que tous les logiciels sont conçus de cette manière ?

C'est une exception industrielle par rapport à une chaîne de production.
Ca n'en est pas une si on pense aux Bureaux D'Etudes...

Mais les cycles en V/cascade ont copié les chaînes, et pas le bureau d'étude... (or la reproduction, qui est le lot des chaînes de production, se passe instantanément en informatique... Dans le bureau d'études, les divers intervenants interagissent ensemble, plus les interventions du Directeur Marketing, SAV, retours de pubs ou de salons, etc)

Il y a une erreur de fond dans la méthode en V/cascade : l'équipe de dev est comme le bureau d'études, et non pas comme la chaîne de production... Et dans le bureau d'études, les gens se parlent, interagissent, et modifient "en temps réel" : le Directeur Marketing arrive d'un salon où il a vu la voiture d'un concurrent avec une "feature" qui lui plaît, il dit au bureau "il me faut ça dans le prototype pour le prochain salon"... Exemple voiture hybride. Toute l'équipe travaille sur le prochain prototype, qui est quasi-fini. Le gars qui s'occupe du réservoir/ de l'énergie en déduit qu'il lui faudra tant de place de plus, le gars qui avait préparé la roue de secours ne peut plus la mettre là, celui qui avait prévu les boulons pour accrocher les sièges ne peut plus non plus, il faut modifier l'aile, les emplacements voire la taille des boulons, peut-être même une partie du plancher pour déplacer la roue de secours, accorder un nouveau réservoir, prévoir des mélanges de carburant, peut-être 2 nouveaux carburateurs, donc il faut de la place dans le moteur etc etc...

La chaîne de production ne fait que recopier le prototype, en séparant et en ordonnant chaque élément...
Mais le prototype, lui, est le résultat du bureau d'études..

En développement logiciel, on fabrique le prototype...le vrai, celui du Salon...
La reproduction est instantanée et ne demande rien.

Quoique, le jour de la paye, la hiérarchie traditionnelle on en a un peu besoin quand même .

Pourquoi ??

Sur ce point, je suis entièrement d’accord. Mais est ce que c’est un principe agile cela ?

Relis le Manifeste.. et relis la composition d'une équipe en V, sa structure, et son lien avec les utilisateurs (il n'y en a que 3 : établissement du Cahier des Charges (soit par interview d'un représentant des utilisateurs par des informaticiens, soit en répondant à un vrai CdC), établissement des analyses (par interview des utilisateurs par des informaticiens), et en phase finale des tests systèmes)


Et quand il y a des "Comités de pilotage", il faut un consensus, ce qui peut prendre des mois (voire plus d'un an), mais aussi ne pas arriver à la bonne solution (un compromis à 10 ou 20 n'est pas forcément la meilleure solution générale, entre les egos / priorités / hiérarchie des différents types d'utilisateurs et les hiérarchies / priorités de la vraie vie et de la fonctionalité attendue réellement).

Bah c’est presque magique. C'était pourtant simple.

Ce serait simple si on avait axé sur les Bureaux d'Etudes et pas sur les chaînes de production industrielles..

« architecture complexe » : c’est quoi pour toi une architecture complexe ?

• Types de données variés et pas forcément complètement tous définis
• Multitude de clients
• Durée de vie prévue au moins 15 ans
• Dizaines de fonctionalités utilisateurs
• Centaines de milliers de lignes de code
• ....

Logiciels pour la météo nationale, pour les hôpitaux, pour les centraux urgence équivalents 112, pour l'entraînement des aiguilleurs du ciel, pour des machines d'IRM, de radio, etc etc... (mais pas l'aéronautique)

« Grosses applications critiques » : c’est quoi « critique » pour toi ? Et comment gères-tu la criticité ?

La définition standard : vie des gens en danger

Evacuation d'usines, de personnel, fermetures d'aéoroports, logiciels médicaux utilisés en urgence, logiciels de formation des aiguilleurs du ciel, etc etc... 24h/24, 7j/7...

La gestion ?? Je rigole quand tu parles de "preuves"...

Tester, tester, tester.. Mais dans la réalité.... opérationnelle.... Voire aléatoirement...

Debug direct (et du coup, la "remontée" dans la doc, ben...ça dépend des applis et des contextes.. Les utilisateurs peuvent vouloir être hors-la-loi (par exemple les médecins aux urgences), ou s'en foutre (un anesthésiste qui est parti manger et qu'on rappelle d'urgence)...).. Correction d'un élément dont le responsable est seul (expert sur un sujet, responsable de l'outil : la doc est dans le code, pour lui ou son suivant)


Un petit exemple pas de moi : un constructeur info (équivalent IBM, dans les anneés 80) : DEC. Clients du style Renault, General Motors, des boîtes à 100 000 ou 200 000 postes de travail, dont environ 10 000 de recherche et le reste en postes opérationnels... Ce constructeur a un OS (VMS) et un outil de backup... (du temps où les DD de térabytes c'était du domaine de la science fiction, où on avait des bandes magnétiques 1600 bpi ou le début des cassettes). Cet outil de backup, bien entendu, sert partout dans le monde, chez tous les clients... Et pour la plupart, c'est vital... Un jour, chez Renault, ça plante... Impossible de recréer le bug : chez tous les autres clients ça a eu l'air d'avoir marché, mais pas chez eux.. la quantité de données impliquées n'existe pas chez le constructeur... Finalement, le responsable OS pour la France décide, un weekend, de relier tous les ordis de DEC en France, et de tester le backup... Ca plante.... Le lundi matin, et dans la journée, aucun magasin / comptoir / usine de ce fabricant ne tourne en France.... Tout est arrêté, je ne sais pas si tu te rends compte de ce que ça produit comme chaos.... MAIS... vers 14h il trouve la raison.... Trouve la réparation.. Envoie le patch binaire de l'OS au siège central, aux USA. Et envoie à tous les clients ce patch instantanément... Aucune analyse, aucune doc avant d'envoyer aux clients (bien évidemment doc envoyée au siège tout de suite après mais pas avant, de toute façons elle n'était pas faite, c'était juste du "quick and dirty").. impossibilité de refaire un test...


Ca c'est la vraie vie....


Autre exemple, de moi : un logiciel pour la météo, qui interprète les messages d'avion (METAR) avant de balancer les données dans la BD. Un jour, l'Organisation Mondiale de l'Aviation change un type de message, à minuit/0h. Le responsable a preparé la modif, documentée, testée, etc etc... A minuit 10, en surveillant la BD, on voit des données pas correctes du tout.... qui font crasher le système, et tous les systèmes de la météo dans le pays... Entre minuit 15 et minuit 45, le gars cherche.... A minuit 45 il a trouvé : le pilote ou copilote s'est mélangé les doigts et a fait une faute de frappe imprévue (il y en avait déjà 16 prévues par blocs de 4 lettres !!!)... Le responsable du soft corrige, tant qu'à faire ajoute d'autres erreurs potentielles du même style (celles auxquelles il pense en voyant ça) , teste 10 minutes sur divers messages, et hop !! réinstalle sur toutes les machines opérationnelles du pays...

(et la doc est dans le code, à cet endroit-là tu as "pour éviter les erreurs de frappe telles que....")





Autre exemple de moi aussi : une machine d'IRM doit etre approuvée par la Sécu et l'Assistance Publique. Un ingénieur biomédical est envoyé pour faire l'évaluation du logiciel de la machine.. La première journée, il ne regarde pas l'écran, mais tape n'importe où sur le clavier, la souris, etc.... A la fin de la journée, il me dit : "bon, vous avez passé la première et la plus importante des étapes.. 3 crashes seulement !!" (qu'on a corrigé bien évidemment)... Ca m'a appris, et c'est ce que je fais systématiquement depuis.... Pas vraiment descriptible sous forme de test bien carré, hein ?? Et faire "la preuve" d'un comportement aléatoire des touches du clavier ou de la souris ou de toute combinaison improbable..... ben...

« C, Fortran … » : Effectivement avec des langages procéduraux, le problème de documentation n’est pas le même qu’avec les langages orientés objets.

Exactement les mêmes besoins...

[el_slapper]

Bon, ça ne surprendra personne, je suis d'accord avec Souviron34. en détail sur certains points :

Une stabilité ? Une application "bug-free" ? Un lien direct entre doc et code ? Des specs parfaites ? Un développement une science exacte ???

Moi non plus. Et j'ai trainé mes guêtres dans des domaines très différends de Souviron : banque, assurances, gestion hospitalière, gestion de business, courses de chevaux, telecoms.

Quand j'ai quitté un assureur ou j'avais fait un projet d'un an, j'ai laissé 2 pages de docs. Et je ne suis même pas sur qu'elles aient servi.....

Je n'ai strictement jamais vu de ma vie un environnement dans lequel la doc était à jour, les specs parfaites, le développement une science exacte, et un outil pouvait tranquillement générer une synchronicité entre code et doc...Et encore moins dans un cycle en V/cascade qu'ailleurs...

Idem

Autre exemple : tu fais un logiciel qui va récupérer des données dans une BD mise à jour par un satellite... D'après les specs initiales, le satellite devrait avoir un débit de XX... Tu te bases dessus.... Mais, une fois le satellite lancé, le constructeur s'aperçoit qu'avec ça il capte trop de signal (nombres ou types d'événements imprévus mais utiles).... ta base recoit XX * 100 en débit... que tu veux garder... ne correspond pas a la spec initiale (impossibilité réelle de connaître le vrai nombre d'évènements avant la mise en service)

Le cas qui me fait souffrir le plus, c'est "la loi change à partir du premier Janvier 2016. On est le 11 Février 2016. La nouvelle réglementation est parue au journal officiel hier soir. Nos clients nous demandent une mise à jour immédiate, avec effet rétroactif. La développeuse spécialisée sur le domaine est en vacances au Costa Rica pour 15 jours. Sans téléphone."

Sauf que tu n'as peut-être pas été exhaustif, et que tu n'as pas vu qu'il y avait d'autres "intrants" (une nouvelle loi, de nouvelles pratiques, des liens avec quelque chose qui n'était pas informatisé du temps où tu as fait l'analyse, un mauvais questionnement des utilisateurs au début (il y a beaucoup de choses qu'ils font inconsciemment), etc etc)

L'inconscient. Le savoir faire des gens. C'est juste énorme. Ils croient tout dire, mais ils ne disent pas grand chose, parceque c'est tellement naturel, qu'ils ne le voient pas.

Un projet comme le logiciel de la station spatiale ISIS c'est 50 ans de durée de vie, 35 ans de programmation dans 88 pays, dont 15 ans à 20 ans à préparer la doc... et induire des modifications dans presque tous les langages (c'est l'origine du vrai calcul matriciel en Fortran, par exemple. Ecrire "A = B * C" où A, B, et C sont des matrices vient de ces specs).

une grande banque Française en 2002 : 170 000 programmes cobol, dépassant les mille lignes pour la plupart. Plus les JCL(les cripts de lancement), les définitions de données, et autres livrables. Et ça, c'est juste la partie centrale. Et depuis, ça a du bien grossir, encore.

Si tu es curieux, et que ton emploi t'en donne le loisir, tu fouilles... Sinon tu suis bêtement ce qu'on te donne à faire..

Voilà. Mon métier, en bancaire, c'était archéologue logiciel. Ce n'était pas le titre officiel(ingénieur maintenance), mais c'est bien le vrai contenu de ce que je faisais. Et ils sont toujours des milliers et des milliers, à faire ce travail indispensable.

C'est une exception industrielle par rapport à une chaîne de production.
Ca n'en est pas une si on pense aux Bureaux D'Etudes...

Mais les cycles en V/cascade ont copié les chaînes, et pas le bureau d'étude... (or la reproduction, qui est le lot des chaînes de production, se passe instantanément en informatique... Dans le bureau d'études, les divers intervenants interagissent ensemble, plus les interventions du Directeur Marketing, SAV, retours de pubs ou de salons, etc)

Il y a une erreur de fond dans la méthode en V/cascade : l'équipe de dev est comme le bureau d'études, et non pas comme la chaîne de production... Et dans le bureau d'études, les gens se parlent, interagissent, et modifient "en temps réel" : le Directeur Marketing arrive d'un salon où il a vu la voiture d'un concurrent avec une "feature" qui lui plaît, il dit au bureau "il me faut ça dans le prototype pour le prochain salon"... Exemple voiture hybride. Toute l'équipe travaille sur le prochain prototype, qui est quasi-fini. Le gars qui s'occupe du réservoir/ de l'énergie en déduit qu'il lui faudra tant de place de plus, le gars qui avait préparé la roue de secours ne peut plus la mettre là, celui qui avait prévu les boulons pour accrocher les sièges ne peut plus non plus, il faut modifier l'aile, les emplacements voire la taille des boulons, peut-être même une partie du plancher pour déplacer la roue de secours, accorder un nouveau réservoir, prévoir des mélanges de carburant, peut-être 2 nouveaux carburateurs, donc il faut de la place dans le moteur etc etc...

La chaîne de production ne fait que recopier le prototype, en séparant et en ordonnant chaque élément...
Mais le prototype, lui, est le résultat du bureau d'études..

En développement logiciel, on fabrique le prototype...le vrai, celui du Salon...
La reproduction est instantanée et ne demande rien.

Ce serait simple si on avait axé sur les Bureaux d'Etudes et pas sur les chaînes de production industrielles..

Il y a de la littérature là-dessus. Le code, c'est de la conception. La fabrication, ça commence à la mise en prod. D'ailleurs, c'est loin d'être évident, hein, l'exploitation, c'est un métier. Industriel, qui correspond bien à ce qu'on trouve en chaine de fabrication.

Autre exemple de moi aussi : une machine d'IRM doit etre approuvée par la Sécu et l'Assistance Publique. Un ingénieur biomédical est envoyé pour faire l'évaluation du logiciel de la machine.. La première journée, il ne regarde pas l'écran, mais tape n'importe où sur le clavier, la souris, etc.... A la fin de la journée, il me dit : "bon, vous avez passé la première et la plus importante des étapes.. 3 crashes seulement !!" (qu'on a corrigé bien évidemment)... Ca m'a appris, et c'est ce que je fais systématiquement depuis.... Pas vraiment descriptible sous forme de test bien carré, hein ?? Et faire "la preuve" d'un comportement aléatoire des touches du clavier ou de la souris ou de toute combinaison improbable..... ben...

Encore plus brutal : le chaos monkey. Bon, ça n'a de sens que sur les applis hautement réseau. Soit 90% des applis modernes... Extrait :

One of the first systems our engineers built in AWS is called the Chaos Monkey. The Chaos Monkey’s job is to randomly kill instances and services within our architecture. If we aren’t constantly testing our ability to succeed despite failure, then it isn’t likely to work when it matters most – in the event of an unexpected outage.

[el_slapper]

Exactement les mêmes besoins...

Sur ce point là, je ne pense pas que c'est ce qu'il a voulu dire : si les besoins sont communs, la structure ne peut pas être la même. En procédural, il est préférable de séparer la donnée de l'action. En objet, les deux sont indissociables. Donc je ne lui donne pas tort, c'est une manière de travailler différente, même si le besoin est le même(à savoir ls strict minimum, et là, je pense qu'il ne sera pas d'accord avec moi.....)

[souviron34]

Sur ce point là, je ne pense pas que c'est ce qu'il a voulu dire : si les besoins sont communs, la structure ne peut pas être la même. En procédural, il est préférable de séparer la donnée de l'action. En objet, les deux sont indissociables. Donc je ne lui donne pas tort, c'est une manière de travailler différente, même si le besoin est le même(

Ah mais c'est justement ce que je dis

Je dis que le fait de changer le langage nécessite de refaire (presque) toute la doc..

Mais cette doc est codifiée dans le cycle en V/Cascade, peu importe le langage.. Les besoins de doc et ce que doivent contenir les différents documents sont codifiés et indépendants des langages... Que les documents de conception détaillée n'aient pas la même structure, oui, tout à fait... Mais je vois pas de différence sur le besoin... Et personne ne va jamais modifier la doc d'origine (ne serait-ce que pour garder l'historique).. On aura donc au moins 2 versions (et aucune ne sera complète)...

[souviron34]

Encore plus brutal : le chaos monkey. Bon, ça n'a de sens que sur les applis hautement réseau. Soit 90% des applis modernes...

Tout à fait..

Dans l'appli météo sur laquelle je travaillais, des BD réparties dans tout le pays, redondantes, des applis connectées via protocoles à des grappes de serveurs capables de switcher automatique si une machine tombait, la communication était faite à base de sockets (synchrones ET asynchrones )...

Normalement, les fonctions de lecture/écriture dans les 2 modes ont des signaux associés si une erreur survient.... MAIS.. il arrive des cas où aucune erreur n'est signalée ("frozen socket") et pourtant la liaison n'est plus fonctionnelle.... Après avoir cherché des mois, une accumulation de patchs (tentative de "poll", plus erreurs et/ou sommes d'erreurs) à faire systématiquement avant chaque écriture ou lecture, plus entre pour vérifier le "live", ont permis de fonctionner 24/24..

Du coup, quand on lit le code, c'est un peu lourd : avant chaque opération, ce test.... (car sinon l'appli crashe).. Et quand on lit le test, ben.... c'est pas "straightforward"....

Et ce test est toujours nécessaire aujourd'hui, dans tout logiciel qui veut s'occuper de sockets en mode failsafe...(sans jamais crasher)

[CaféFort]

Sur ce point là, je ne pense pas que c'est ce qu'il a voulu dire : si les besoins sont communs, la structure ne peut pas être la même. En procédural, il est préférable de séparer la donnée de l'action. En objet, les deux sont indissociables. Donc je ne lui donne pas tort, c'est une manière de travailler différente, même si le besoin est le même(à savoir ls strict minimum, et là, je pense qu'il ne sera pas d'accord avec moi.....)

Exactement !

Avec un projet en langage procédural, il est quasiment impossible de s'outiller pour gérer la documentation technique du projet. Schématiquement, on est face à des milliers de lignes de code "séquentiels" (même s'il y a des procédures et des if, des while, ...)

Par contre, avec un langage objet, le projet est par nature modulaire. Une classe est un module (au sens large). Un composant contenant des classes qui sont liées par une même problématique l'est aussi.
Ceci rend l'outillage de la documentation technique très facile en langage objet contrairement aux langages procéduraux. Après, il faut quand même s'organiser pour que cette documentation technique soit toujours "up to date".

[CaféFort]

Pourquoi établir une priorité entre avec un logiciel qui marche et avoir la documentation de ce logiciel en priorisant le logiciel qui marche ? C’est ce que dit le manifeste.

J’illustre avec un autre cas dans le domaine électrique/électronique.

Je dois acheter une armoire téléphonique. J’ai le choix entre deux produits :

- une armoire A qui contient plein de fils dans tous les sens, qui se croisent, des soudures sauvages. La peinture de l’armoire est nickel. Par contre on voit l’énorme sac de nœuds (spaghettis) quand on l’ouvre. Le point positif, c’est qu’elle marche. Je n’ai rien de plus que cette armoire, pas de documentation technique. Je sais par ailleurs qu'il est impossible de tester tous les cas de figures.

- Une armoire B qui visiblement ne fonctionne pas dans certains cas. Par contre, elle est structurée et cette structure est parfaitement documentée : les fils sont numérotés, assemblés … On comprend très vite comment fonctionne cette armoire et le contenu est complet.


Le montant est très élevé et vous devez investir pour au moins 5 ans. Le fonctionnement de votre entreprise en dépend et dans les deux cas, vous n'avez pas pu tout tester.
Vous choisissez laquelle ? La A ou la B (il n'y a pas d'autre alternative) ?

[souviron34]

Quand tu arrêteras de caricaturer, on pourra éventuellement discuter....

Avec un projet en langage procédural, il est quasiment impossible de s'outiller pour gérer la documentation technique du projet. Schématiquement, on est face à des milliers de lignes de code "séquentiels" (même s'il y a des procédures et des if, des while, ...)

- une armoire A qui contient plein de fils dans tous les sens, qui se croisent, des soudures sauvages. La peinture de l’armoire est nickel. Par contre on voit l’énorme sac de nœuds (spaghettis) quand on l’ouvre. Le point positif, c’est qu’elle marche. Je n’ai rien de plus que cette armoire, pas de documentation technique. Je sais par ailleurs qu'il est impossible de tester tous les cas de figures.
Vous choisissez laquelle ? La A ou la B (il n'y a pas d'autre alternative) ?

Comme dis plus haut, tu ne dois pas connaitre du tout ni le dev en langage procédural, ni ce que dit le Manifeste..

Tu refuses de comprendre, donc toute discussion est impossible..

Tu as entendu parler de "conception orientée objet" ???

A part sans doute dans des projets d'école, je n'ai jamais vu un projet procédural en sphagetti, ni avec pleins de fils dans tous les sens... Mais des projets propres, modulaires, avec des "classes" d'objets et des "méthodes" associées... Même en Fortran ou en assembleur... Personne n'a attendu les langages objets pour "penser" objet... J'ai fait des programmes de traitement d'images en Fortran et assembleur en 1984 qui étaient "OO"... Simplement au lieu d'être "Image.trace" la fonction s'appelait "Trace_image", et au lieu d'avoir "this" tu avais le pointeur sur le tableau de l'image.. Wouahaha !!! Quelle différence !!!


(d'ailleurs, C++ est écrit en C )


Tu me fais l'effet d'un étudiant qui a mal digéré ses cours, et qui pense que les langages objets sont les seuls "propres", et que le V est la seule métholologie "propre".... parce qu'il l'a appris, et que ce qu'on apprend c'est La Vérité...

T'as ptet' eu des mauvais profs, hein ?


Il n'y a pas plus de "spaghetti" en procédural qu'en objet (tu me listeras toutes les "exceptions" dans un programme consequent), et des modules il y en a autant..

Et ils sont en général découpés par classes d'objets, mais aussi par fonctionalité, car la différence repose là-dessus...

Mais je ne sais même pas pourquoi j'essaye de discuter....

Tiens, juste un p'tit exemple dans mon appli de météo, 2 répertoires :

DataHandling.c
InitEnvMeteo.c
Meteo_Thermo.c
Meteo_Utils.c

MCoreAlarms.c
MCoreBogus.c
MCoreCalc.c
MCoreContour.c
MCoreCplxTypes.c
MCoreData.c
MCoreDBase.c
MCoreDirs.c
MCoreExpir.c
MCoreExtSymb.c
MCoreFcts.c
MCoreFiles.c
MCoreForecst.c
MCoreGenUtil.c
MCoreGeo.c
MCoreGeoFile.c
MCoreMaths.c
MCoreMesFile.c
MCoreMetFcts.c
MCoreMixFile.c
MCorePrinter.c
MCoreResFile.c
MCoreSignal.c
MCoreTriang.c

Quant à la doc, visiblement tu ne comprends pas le sens des mots (y compris alors que tu les cites toi-même ) :

Pourquoi établir une priorité entre avec un logiciel qui marche et avoir la documentation de ce logiciel en priorisant le logiciel qui marche ? C’est ce que dit le manifeste.

et quelques lignes plus bas :

Je n’ai rien de plus que cette armoire, pas de documentation technique.

Comprends-tu le terme "prioriser ???
Qui n'est pas synonyme de "éliminer" ??

[CaféFort]

Tout d’abord, ce serait bien souviron34, que tu t’exprimes de manière moins virulante.
L'ensemble gagnerait en clarté et s’exclamer sans cesse que je ne connais rien (selon toi) n’est en rien une démonstration.

je n'ai jamais vu un projet procédural en sphagetti

Déjà, je n’ai jamais écrit de lien entre code procédural et spaghetti.
Et c’est toi qui parle de « code spaghetti » et non moi.
Mais tu as beaucoup de chance si tu n’en as jamais vu. J’ai juste transposé la problématique à un autre domaine. Il se trouve qu’il y avait des fils dans ce domaine (la téléphonie). C’est tout.
De plus, un mauvais code peut être dans absolument tous les langages sans exception.

Même en Fortran ou en assembleur... Personne n'a attendu les langages objets pour "penser" objet... J'ai fait des programmes de traitement d'images en Fortran et assembleur en 1984 qui étaient "OO"... Simplement au lieu d'être "Image.trace" la fonction s'appelait "Trace_image", et au lieu d'avoir "this" tu avais le pointeur sur le tableau de l'image.. Wouahaha !!! Quelle différence !!!

Excuses moi, mais la conception objet est plus que cela.

(d'ailleurs, C++ est écrit en C )

Et donc ?? Ça prouve quoi ?
et finalement ils sont tous exécutés en assembleur !! Qui n’est ni objet, ni procédural !!

Tu me fais l'effet d'un étudiant qui a mal digéré ses cours, et qui pense que les langages objets sont les seuls "propres", et que le V est la seule métholologie "propre".... parce qu'il l'a appris, et que ce qu'on apprend c'est La Vérité...

T'as ptet' eu des mauvais profs, hein ?

Bah, il ne faut pas m’en vouloir si j’ai fait quelques études.
J’ai eu des professeurs, oui, chercheurs de renommée mondiale pour certains. J’ai aussi embauché des personnes qui venaient de centres de recherches. Tu aurais quelque chose contre tout cela ?
Et ce n'est pas parce que je suis nouvellement inscrit que je suis débutant (et puis même ? j'adore l'esprit vif des jeunes diplômés).
Et j'ai mis développeur C#, car bien qu'ayant d'autres fonctions, je me considère toujours développeur et C# car c'est le langage que j'utilise le plus, parmi beaucoup d'autres que je pratique aussi, voire que j'ai créé parfois. Tu as certainement compris que je parle de sujets que je connais bien et je ne me base que sur des démonstrations. Malheureusement tu n'en émets aucune.

Mais je ne sais même pas pourquoi j'essaye de discuter....

Non, je n’appelle pas ce que tu fais "discuter".
Ensuite, c’est dommage que tu ais mélangé mes propos à ta façon.
J’ai effectivement écrit « pas de documentation technique », car une documentation technique périmée est équivalent à aucune documentation exploitable.

On peut se demander si tu ne t'amuses pas à bloquer toute discussion qui pourrait être constructive. C'est bien dommage.

[souviron34]

Tout d’abord, ce serait bien souviron34, que tu t’exprimes de manière moins virulante.
....
On peut se demander si tu ne t'amuses pas à bloquer toute discussion qui pourrait être constructive. C'est bien dommage.

Je te retourne le compliment...


Il y a eu plusieurs intervenants sur plusieurs discussions, et tu réussis à tous te les mettre à dos en à peine 1 mois..

Donc nous sommes tous des abrutis/non constructifs/trop virulents sauf toi, ou bien ce serait l'autre solution ??? C'est quand même bizarre, non ??


Paille, poutre... tu as quand même une notion très étrange du terme "constructif"....

(ce qui fait que ça ne m'étonne guère que tu trouves la démarche Agile stupide, c'est sûr, faut estimer le point de vue des autres et ses interlocuteurs, alors... )

[CaféFort]

C'est quand même bizarre, non ??

Je constate que tu parles d’une pièce remplie de listings (et les PDF tu connais ?). Tu nous as fait la démonstration que tu ne connais pas du tout la conception orientée objet. On peut se demander pourquoi tu prends autant de place dans cette discussion. Ton avis est intéressant, certes, mais tu nous éloignes beaucoup de la problématique de la discussion.

Je n’attends que des démonstrations. Nous sommes dans un domaine scientifique et non religieux. Par ailleurs suivre l’avis de la majorité n’est ni un faire valoir, ni une démarche scientifique. Beaucoup de gens peuvent avoir un avis différent, c’est normal … mais si on ne peut pas démontrer pour prouver, on est alors dans le religieux. Il faut toujours démontrer !! Cela évite beaucoup de problèmes.

Par exemple, quand on compare un projet agile avec une traversée en mer. Je ne suis pas d’accord. Dans un projet, l’avancée ne dépend que d’éléments et de choix humains : choix techno, fonctionnalités à développer, priorités, … uniquement des choix humains qui portent chacun une responsabilité humaine. Au contraire, la traversé en mer ne dépend que d’éléments totalement extérieurs non humains : météo, avaries, … C’est très différent. Il est important d’identifier les responsabilités et faire la différence entre ce que l’on subit forcément (météo) et ce qui est le choix d’une personne (spécifications, analyse, priorités, …).

Je redonne ma question (je l’ai un peu modifiée) :

Pourquoi établir une priorité entre "avoir un logiciel qui marche" et "avoir la documentation de ce logiciel" en priorisant le logiciel qui marche ? C’est ce que dit le manifeste.

J’illustre avec un autre cas dans le domaine électrique/électronique.

Je dois acheter une armoire téléphonique. J’ai le choix entre deux produits :

- une armoire A qui contient plein de fils dans tous les sens, qui se croisent, des soudures sauvages. La peinture de l’armoire est nickel. Par contre on voit l’énorme sac de nœuds (spaghettis) quand on l’ouvre. Le point positif, c’est que ce qui a été testé fonctionne. Je n’ai rien de plus que cette armoire et une documentation technique de l’armoire mais elle ne contient pas toutes les soudures ajoutées et les fils sont difficiles à suivre. Je sais par ailleurs qu'il est impossible de tester tous les cas de figures.

- Une armoire B qui visiblement ne fonctionne pas dans certains cas. Par contre, elle est structurée et cette structure est parfaitement documentée : les fils sont numérotés, assemblés … On comprend très vite comment fonctionne cette armoire et le contenu est complet.


Le montant est très élevé et vous devez investir pour au moins 5 ans. Le fonctionnement de votre entreprise en dépend. Dans les deux cas, vous n'avez pas pu tout tester.

Vous choisissez laquelle ? La A ou la B (il n'y a pas d'autre alternative) ?

[el_slapper]

Je constate que tu parles d’une pièce remplie de listings (et les PDF tu connais ?). Tu nous as fait la démonstration que tu ne connais pas du tout la conception orientée objet. On peut se demander pourquoi tu prends autant de place dans cette discussion. Ton avis est intéressant, certes, mais tu nous éloignes beaucoup de la problématique de la discussion.

Et toi, tu ne comprends rien au procédural. Qui peut parfaitement être modulaire, aussi.

Exemple dans mes scripts de tests automatiques actuels : J'ai un module chapeau, qui va lire le paramétrage. En fonction de ce qui est lu dans le paramétrage, on va invoquer les modules qui vont faire le boulot. Beaucoup eux-même appellent des sous-modules. Donc, quand je veux vérifier que tel patient est bien sélectionne, j'appelle toujours le même code.

En objet, ça serait monpatient.CheckSelection

En procédural, c'est Call CheckSelection(monPatient)

C'est juste une autre manière d'organiser le code. Mais les potentialités sont les mêmes, on peut faire du très propre et du très crade dans les deux cas.

Je n’attends que des démonstrations. Nous sommes dans un domaine scientifique et non religieux. Par ailleurs suivre l’avis de la majorité n’est ni un faire valoir, ni une démarche scientifique. Beaucoup de gens peuvent avoir un avis différent, c’est normal … mais si on ne peut pas démontrer pour prouver, on est alors dans le religieux. Il faut toujours démontrer !! Cela évite beaucoup de problèmes.

On t'en a balancé un paquet. Tu ne les a même pas lues.

Et, de toutes façon, Il y a une part de création dans notre métier. Il faut de la rigueur, beaucoup, même, mais quand on vient te dire "on avait prévu 10 jours pour faire ce programme. Mais on a fait une connerie dans le planning, donc tu en as deux. C'est non négociable". Tu crois que la chose à faire, c'était de suivre le petit manuel?

Plus généralement, tu pars sur des postulats qui sont faux. On ne peut rien te démontrer, parceque tu raisonnes sur de l'imaginaire. Dans le monde réel, le cas du dessus, il arrive tout le temps(sauf qu'en général, la hiérarchie n'ose pas avouer qu'elle a fait une connerie). Dans le monde réel, les composants deviennent obsolètes, les lois changent, les concurrents offrent des services non anticipés, et il faut réagir à tout ça.

Et c'est pour ça qu'un excès de documentation est néfaste : parcequ'il ralentit les changements de direction quand il faut en faire.

Par exemple, quand on compare un projet agile avec une traversée en mer. Je ne suis pas d’accord. Dans un projet, l’avancée ne dépend que d’éléments et de choix humains : choix techno, fonctionnalités à développer, priorités, … uniquement des choix humains qui portent chacun une responsabilité humaine. Au contraire, la traversé en mer ne dépend que d’éléments totalement extérieurs non humains : météo, avaries, … C’est très différent. Il est important d’identifier les responsabilités et faire la différence entre ce que l’on subit forcément (météo) et ce qui est le choix d’une personne (spécifications, analyse, priorités, …).

Très juste, mais tu ne vas pas au bout de ton raisonnement : les choix humains, ils sont faits dans un contexte donné, et le contexte peut changer. (ça va de "on fait fausse route" à "la loi a changé")

Pourquoi établir une priorité entre "avoir un logiciel qui marche" et "avoir la documentation de ce logiciel" en priorisant le logiciel qui marche ? C’est ce que dit le manifeste.

Parceque c'est la seule solution raisonnable. Surtout, le contexte du manifeste(le contexte est toujours important), ce sont les immenses boites américaines qui font des projets gigantesques... dont la plupart ne voient jamais le jour, écrasés sous leur propre poids. Et je peux te dire qu'en France, dans les grandes banques ou j'ai pas mal trainé mes guêtres, j'ai constaté les mêmes soucis.

Surtout, Quel que soit l'effort, on constate que la doc finit toujours par disparaitre. Ou au moins par être obsolète. Parceque l'effort à faire pour la garder systématiquement à jour est trop grand.

- une armoire A qui contient plein de fils dans tous les sens, qui se croisent, des soudures sauvages. La peinture de l’armoire est nickel. Par contre on voit l’énorme sac de nœuds (spaghettis) quand on l’ouvre. Le point positif, c’est que ce qui a été testé fonctionne. Je n’ai rien de plus que cette armoire et une documentation technique de l’armoire mais elle ne contient pas toutes les soudures ajoutées et les fils sont difficiles à suivre. Je sais par ailleurs qu'il est impossible de tester tous les cas de figures.

Non, tu ne sais pas que c'est impossible, parceque c'est tout à fait possible. Quand tu fais un projet correct, tu as une forme ou une autre de tests automatiques. Idéalement, liés aux sources du projet, comme ça, ça reste toujours avec. Ca ne se perd pas comme la doc. Et ça sert de documentation sur "voilà comment ça doit marcher". Si tous les niveaux sont couverts, du module unitaire à l'interface graphique, tu as une couverture complète de tests, que tu n'as plus qu'à faire évoluer en même temps que les composants.

D'ailleurs, c'est mon métier. Les programmeurs programment, et moi je rajoute en fonction de leurs demandes des tests automatiques pour garder la mémoire du projet, et trouver les régressions.

- Une armoire B qui visiblement ne fonctionne pas dans certains cas. Par contre, elle est structurée et cette structure est parfaitement documentée : les fils sont numérotés, assemblés … On comprend très vite comment fonctionne cette armoire et le contenu est complet.

Illusion. Qui te dis que l'armoire correspond vraiment aux spécifications détaillées?