Discussion :

[souviron34]

On va se répéter, et ça va finir pas nous énerver

Le client ne serait il pas plus content d'avoir un logiciel modulable, adaptable et faible en cout de maintenance ?

Encore une fois, il s'en fiche éperdument.. A part le coût (et encore, ça se négocie en fonction du nombre et du poids : si c'est ton seul client, (même très très gros) c'est toi qui porteras le plus le poids du coût).

Parler de logiciels préhistoriques datant de plus de 10 ans alors que depuis les langages, les méthodes et l'informatique en général ont beaucoup évolué, j'en vois pas trop l'utilité.

D'une part 10 ans c'est pas préhistorique... Alors sauf pour un soft qui a mis 2 mois à faire, mais la plupart de softs industriels mettent de 2 à 10 ans à s'écrire... Alors 10 ans d'age c'est juste la maturité... par la vieillesse, et encore moins la préhistoire..

(pour mémoire, la norme C99 (10 ans) n'est pas encore ni entièrement reconnue ni entièrement implantée, y compris dans les compilateurs M$)

Mais justement, à cause du coût de développement, crois-tu qu'on ait envie de repayer tous les 3 ans pour quelque chose qui est exactement la même chose que 3 ans avant ? Juste parce qu'une nouvelle technologie est sortie ????

Ce qui m'importe c'est comment réussir à créer un logiciel utilisable et maintenable avec les outils, langages et méthodes actuelles.

Relis le thread depuis le début, et le résumé qu'en a fait elitost.


Si déjà tu suis ça, tu auras bien avancé...

[B.AF]

C'est vrai qu'un logiciel a une durée de conception de minimum 2 ans, voir plus et que la plupart des softs "référents" dans toutes les industries sont ce que tu appelles des "dinosaures".

Il ne font pas confondre un produit développé une fois pour un client, d'un soft qui représente le produit distribué à n clients par une société.

Le mieux est toujours l'ennemie du bien.

[el_slapper]

Je fais sans doute partie des "vieux".....mais en même temps je bosse sur une chaine qui a 25 ans d'âge, et que l'on va remplacer. C'est un bien, parceque la chaine fait plein d'erreurs, et fait aussi plein de trucs inutiles. Surtout, elle présente des limites techniques telles que les évolutions, même simples, ne sont plus possibles.

Nous allons toutefois garder quelques morceaux, ceux qui marchent bien, et ceux auxquels nous ne comprenons rien

[B.AF]

25 ans, ça commence à faire effectivement...

[ZeRevo]

el_slapper et vous allez utiliser un nouveau langage, une nouvelle plateforme de nouveaux outils / méthodes de travail ?

[B.AF]

honnêtement faire une révolution de 25 années de pratiques...

changer la techno, la méthodes et les outils, ca demandera probablement 5 à 6 ans à faire. Et encore, même le changement de technologie n'est pas une chose simple parce que souvent c'est aussi un changement d'architecture.

je veux pas répondre à sa place, mais ca reléve du suicide...tant financier que "produit"....

[el_slapper]

Non, on reste sur la même plateforme "COBOL - MVS". A l'époque, y'avait pas grand chose d'autre, de toutes façons, et vu nôtre volumétrie et les performances de nos outils JAVA, nous en sommes restés loin. Evidemment, si ils avaient investi dans du CPU, il aurait peut-être été possible de passer à Java, mais en l'occurence, non.

Ca limite la casse, évidemment, parcequ'on peut choisir ce que l'on change et ce que l'on garde. En fait, on met à la poubelle toute la chaine d'édition des courriers clients, que l'on arrive plus à modifier correctement. Mais la partie extraction de données et mise à jour, elle, reste inchangée(en fait, c'est tout petit, genre 20000 lignes, mais personne n'a réussi à comprendre ce que ça faisait, et comme ça determine ce que l'on facture au client, on ne touche pas).

Donc, une fois que les montants sont calculés, la nouvelle architecture prend la main, génére un nouveau format de données vers un nouvel outil d'édition. Si en plus il avait fallu redeterminer les montants à facturer, alors oui, ça aurait été du suicide. Là, c'est juste acrobatique.....mais faisable.

[B.AF]

Remarque tant que tu y es ....Cobol .NET

[chaplin]

Le Crédit Agricole est passé sur Cobol.NET

[ZeRevo]

personne n'est parfait

[B.AF]

Le Crédit Agricole est passé sur Cobol.NET

Je sais justement!!!!!

Et c'est là que les leçons sont à tirer : plutôt que de faire la révolution, ils passent par une solution intermédiaire, et une migration en douceur.

Je trouve ça un bon compromis. Déjà tirer parti du framework .NET, ca dépoussiére un peu, et ça laisse la techno sur le langage.
Ca permet aux histoirques de rester une techno qu'ils maitrisent et aux nouveaux d'utiliser une techno d'actualité.

Ca se discute, mais vu la tailel de la structure, ca prouve aussi que la solution n'est une fois de plus pas dans les livres, et que explorer d'autres pistes peut être intéressant.

[Garulfo]

Non il parle de projet pas de software, c'est pas la même chose. Le projet est tout les actions entreprises avant de fournir le software (en production).

C'est Souviron qui a raison. C'est vrai que le logiciel n'est qu'une partie de tout un système. Mais je parlais de projet qui avait pour but de fournir un logiciel.

Si je me focaliserai uniquement sur le besoin du client je ferai de la merde...

Non tu ferais ce qu'on te demande. Sais-tu que c'est la raison principal d'échec des projets ? Sais-tu que les développeurs qui font le mauvais produit coûtent plusieurs centaines de millions de dollars chaque année pour les projets « communs » — je ne parle pas des échecs grandiose ? En génie logiciel, il y a deux questions (enfin si on prend un raccourci): fait-on le produit correctement ? fait-on le bon produit ? Cette dernière question est plus importante que la première. Car si ton client refuse ton produit parce qu'il ne remplit pas les besoins, alors il peut te poursuivre pour bris de contrat. Il n'en a rien à foutre que tu te sois amusé. Il ne te paye pas pour ça. Je ne dis pas que c'est sympa comme vision. Moi-même ça ne me tente pas et c'est pour ça que je ne suis pas dans ce système. Je me contente de l'étudier.

Si tu connais les modèles de génie logiciel, tu sais qu'en haut de la pyramide des tests il y a les tests de validation qui sont les tests ultimes: ceux fait par le client qui juge de sa satisfaction. Si tu échoues ces tests, tu échoues tout ton projet. Avec une grande chance, ton produit pourra quand même être revendu ailleurs. Mais en général tu as un produit bon pour la poubelle.

La phase d'analyse des besoins est probablement la plus importante pour la réussite d'un projet en terme d'impact. C'est pourtant souvent la plus dénigrée par les informaticiens. Je le conçois bien puisque je n'aime pas ça et pourtant j'enseigne comment faire. C'est une phase qui est plus proche du commercial que du technologique, mais c'est ainsi. Comme dans toute ingénierie, il faut passer par là. L'industrie informatique est loin d'être aussi rodée dans cette phase. Et c'est la raison numéro 1 des nombreuses merdes qui sont sur le marché.

Un informaticien qui développe pour lui seulement est peut-être un excellent informaticien dans sa chambre, mais est une plaie pour une entreprise.

[kromartien]

Un informaticien qui développe pour lui seulement est peut-être un excellent informaticien dans sa chambre, mais est une plaie pour une entreprise.

Bonjour, je suis d'accord que faire une bonne étude du besoin pour tel ou tel programme est primordial, parce que ça permet de faire un gabarit. C'est un peu comme faire un costume sur mesure, si les mesures sont fausses, le costume peut être trop grand ou trop petit, il ne sera en tous cas pas à la bonne taille.

Par contre, concernant le programme en lui même, je crois que d'avoir un code bien documenté et bien conçu est important, ne serait ce que pour la relecture et la recherche de bug, qui est une phase ô combien critique et importante dans les projets informatiques.

Donc, au final, je crois que d'écrire correctement un programme, avec les outils (langage) qui vont bien doit être l'objectif secondaire, après l'objectif ultime et principal, qui est faire le logiciel pour le client en temps et en heure, et fonctionnel, la pierre angulaire de tout développement de logiciel commercial.

[Garulfo]

Bonjour, je suis d'accord que faire une bonne étude du besoin pour tel ou tel programme est primordial, parce que ça permet de faire un gabarit. C'est un peu comme faire un costume sur mesure, si les mesures sont fausses, le costume peut être trop grand ou trop petit, il ne sera en tous cas pas à la bonne taille.

En fait, le gabarit est la conception. L'analyse des besoins est préliminaire. C'est une phase qui a souvent été négligé car les développeurs se disaient : « Bin voyons je sais bien moi ce qu'il veut le client. Pas besoin de passer des heures à discuter avec lui. » Ce qui se passe alors c'est que l'informaticien fait le produit qu'il croit être correct et non celui qui l'est vraiment. Tu obtiens parfois des véritables catastrophes comme le London Stock Exchange project TAURUS qui a couté plus de 500 millions de livres sterling et qui a échoué car on a pas réussi à résoudre les conflits dans les besoins. Conclusion: le projet a été purement et simplement mis à la poubelle. Mais ce projet a été implémenté. Sauf que ça ne pouvait pas donner un système correct vu que les besoins n'étaient pas clairs.

Par contre, concernant le programme en lui même, je crois que d'avoir un code bien documenté et bien conçu est important, ne serait ce que pour la relecture et la recherche de bug, qui est une phase ô combien critique et importante dans les projets informatiques.

Ce n'est pas négligeable. Je n'ai pas dit le contraire. Mais un code bien documenté, parfaitement bien architecturé, sans une seule erreur humaine dans sa conception ne servira à rien si ce n'est pas le bon produit.

Va voir ton tailleur, pour reprendre ton analogie, dis lui que tu veux un costume pour ton mariage. Il travaille et fait le plus beau costume de scène qu'on ait jamais fait avec les meilleurs matériaux. Vas-tu lui acheter ? Penseras-tu qu'il a fait correctement son travail ?

Donc, au final, je crois que d'écrire correctement un programme, avec les outils (langage) qui vont bien doit être l'objectif secondaire, après l'objectif ultime et principal, qui est faire le logiciel pour le client en temps et en heure, et fonctionnel, la pierre angulaire de tout développement de logiciel commercial.

On est d'accord. De plus, les clients font de plus en plus part de besoins non fonctionnel portant sur la maintenance par exemple. Dans ce cadre, on rejoint au final le bon produit avec le produit bien fait. Et le travail obscur de l'informaticien (documentation, méthodologie etc) s'en trouve valorisé. Mais même sans ça, il serait idiot de nier qu'un projet sans aucune méthodologie est voué à l'échec. Donc, la manière de faire est en général en corrélation avec la réussite du projet car il serait étonnant qu'en faisant n'importe quoi on finisse par avoir le bon produit. Mais en supposant que ce soit le cas et que le client en soit heureux, alors ce serait une réussite.

[chaplin]

il serait idiot de nier qu'un projet sans aucune méthodologie est voué à l'échec. Donc, la manière de faire est en général en corrélation avec la réussite du projet

Oui, mais il y a un facteur subjectif qui est le facteur humain. S'il n'y a pas de bonne communication dans l'équipe, c'est raté à 50%, avec un comportement de ce genre:

Un informaticien qui développe pour lui seulement est peut-être un excellent informaticien dans sa chambre, mais est une plaie pour une entreprise.

c'est la catastrophe, mais il ne faut pas pour autant négliger l'avis des développeurs parce que tous ne se comportent pas de cette manière. C'est un peu comme à l'armé, il suffit qu'un merde et tout le monde trinque.

Si le chef de projet n'écoute pas des conseils judicieux de ses développeurs, il ne doit pas leur donner la faute lorsque le projet plante. C'est là que le débat, adapter l'outil au besoin prend toute son ampleur.

Comme les projets vont induirent des hierarchies, chef de projet vs développeurs, c'est un facteur aussi bien de réussite que d'échec.

Et puis si quelqu'un décide de saboter le projet, quelques soient les compétences ou technologies, méthodologies engagées, c'est voué à l'echec.

Ce genre de comportement existe aussi.

[ZeRevo]

Si le chef de projet n'écoute pas des conseils judicieux de ses développeurs, il ne doit pas leur donné la faute lorsque le projet plante. C'est là que le débat, adapter l'outil au besoin prend toute son ampleur.

L'image de l'informaticien seul dans son garage est terminée. Aujourd'hui un projet est développé par une équipe. Les décisions ne sont pas prises par une seul personne, c'est l'équipe qui décide. Un développeur est un acteur dans l'équipe, s'il ne veut pas faire avancer les choses, ca devient compliqué mais c'est à tout le monde de se prendre en main pour avancer (c'est pas simple...)

J'ai eu la chance de travailler sur 2 types de projet bien distincts. D'un côté en SSII, un gros projet au forfait avec des délais trop serrés et un manque de moyen. Le projet était standard : chef de projet, architecte, devs. Les propositions des développeurs n'étaient jamais prises en compte, il fallait se soumettre à l'architecture de l'architecte et les spécifications étaient faites "à la rache" c'est à dire qu'il en manquait la moitié. On travaillait sans test unitaire, il y a juste le chef de projet qui testait à la fin. La boite a vendu l'application sans bug bloquant, après 6 mois de recette et correction des petits bugs, les 2 applications sont en production.
Ces 2 projets ont été un succès car on a du s'impliquer à fond dans notre travail et c'était pas facile à tenir le rythme. Le client a été très content du résultat, moi de mon côté j'ai jamais vu le client, ses besoins je les connaissait à peine sur ma partie, je trouvait des écrans mal conçus mais j'avais aucun pouvoir ni de temps de m'en occuper. Le seul temps libre que j'avais je l'utilisais pour mes relations sociales et pour me former (recherche sur le net...). Je faisais pas d'heures supp. faut pas déconner non plus.
A la fin du projet, j'ai appris beaucoup de chose, je travaillais sans filer, c'était bien sans être bien.

Aujourd'hui, je travaille sur un projet alliant Scrum et XP, avec des sprints de 15 jours. L'équipe (client, scrum master, développeur) travaille ensemble, on a pas d'architecte, chaque développeur est au même niveau, on peut tous faire évoluer l'architecture, on sélectionne nous même les outils et langages qu'on souhaite utiliser. Tout le développement comporte des tests unitaires, l'utilisation de la javadoc est au bon vouloir des développeurs, on a un wiki d'entreprise difficile à maintenir. On fait également du binômage afin que toute l'équipe maitrise toute l'application et soit pas experte sur une partie.
A la fin du sprint on doit être capable de fournir un livrable qui fonctionne.

C'est 2 méthodes de travail bien différentes, elles ne sont pas parfaite loin de là mais je trouve de plus en plus que les méthodes agiles ne sont pas si mauvaises surtout dans le cadre de gros projets. Il faut une équipe motivée car le refactoring peut être très long et complexe mais indispensable. On évite les commentaires car souvent durant le refactoring, on oublie de modifier les commentaires et le code doit être assez parlant (je suis pas partisant de cette idée).

Voilà pour mon expérience. Maintenant pourquoi je dis qu'il ne faut pas se focaliser sur les besoins du client, c'est parce ce qu'avec scrum+xp, ses besoins sont flexibles. Il peut décider de changer radicalement ses besoins d'un sprint à l'autre et notre soucis en tant que développeur est de fournir un livrable qui respecte ses besoins tout en étant facilement maintenable car la maintenance se fait quotidiennement, on fait évoluer les projets au fil de l'eau et on est pas dans une optique stricte de spécifications fixent.

Mais ce projet a été implémenté. Sauf que ça ne pouvait pas donner un système correct vu que les besoins n'étaient pas clairs.

Besoins pas clairs => les développeurs ne peuvent pas penser à la place du client. On ne peut pas non plus faire de miracles.

La phase d'analyse des besoins est probablement la plus importante pour la réussite d'un projet en terme d'impact. C'est pourtant souvent la plus dénigrée par les informaticiens. Je le conçois bien puisque je n'aime pas ça et pourtant j'enseigne comment faire. C'est une phase qui est plus proche du commercial que du technologique, mais c'est ainsi. Comme dans toute ingénierie, il faut passer par là. L'industrie informatique est loin d'être aussi rodée dans cette phase. Et c'est la raison numéro 1 des nombreuses merdes qui sont sur le marché.

En entreprise, c'est souvent un manque de temps qui fait défaut à ce niveau là. Le client ne gagne pas d'argent avec une analyse, lui ce qu'il veut c'est un logiciel en production le plus vite oossible.
Quand je vois scrum/xp, je trouve qu'intégrer l'analyse des besoins tout au long du process de création du logiciel est peutetre la meilleure solution.

Je ne suis pas partisant de scrum/xp, c'est des méthodes jeunes et elles ne répondent pas à tout. Toutefois, elles apportent des idées fraiches qui font évoluer l'informatique et c'est pas plus mal.


Pour en terminer parce ce qu'il se fait faim, si je dis qu'on doit prendre du plaisir dans notre travail c'est parce qu'avec scrum/xp on a moins de pression, on travaille sous forme d'équipe et comme on fait évoluer le projet quotidiennement, on doit être assez mature pour se créer un cadre de travail plaisant. On est moins attaché au projet vu qu'on touche un peu à tout et que le système est fait pour que personne ne soit experte d'une partie d'un programme.

[souviron34]

Je ne réagirais qu'à une petite partie, le reste on en a déjà parlé, et de plus il semble que l'on commence à te faire voir qu'une certaine pondération commence à voir le jour chez toi par rapport à tes dires du début..

..Besoins pas clairs => les développeurs ne peuvent pas penser à la place du client. On ne peut pas non plus faire de miracles.

Non, c'est vrai, mais c'est au chef de projet et à l'équipe "interfaçage client" avec laquelle il travaille de le faire..

C'est bien pour ça, comme on le dit avec Garulfo, qu'il faut soit des ergonomes, soit du marketing (en général ce sont des gens qui viennent du mileu des utilisateurs), soit de très bon généralistes (ce qu'ici maintenant on affuble du doux nom de MOA), ou des utilisateurs à temps plein dans l'équipe de développement, et qui ont le dernier mot. quant à l'implantation d'une fonctionalité

Car, comme pour un programmeur par rapport à un outil de programmation, il faut en général une aide extérieure pour faire cracher à l'utilisateur TOUT ce dont il a besoin, dans le bon ordre, en éclairant toutes les parties cachées (calculs mentaux faits par habitude, par exemple, raccorucis dûs aux connaissances acquises, auc formations spécifiques, etc etc), que le logiciel (et le cahier des charges) doit impérativement satisfaire.

MAIS encore une fois c'est l'utilisateur qui a le dernier mot (sauf pour quelques exemples d'utilisateurs "captifs" : voir la SNCF et son système SOCRATE : les guichetiers, bien que râlant, n'avaient pas le choix d'utliser le soft). Mais c'est par exemple la cause de l'échec de la plupart des logiciels faits pour les hôpitaux : le premier besoin (et ce qu'on leur demande, ainsi que leur responsabilité pénale) des médecins est de soigner, pas d'utiliser un système informatique. Si donc le système informatique ne les aide pas, ou ne fait pas correctement quelque chose, c'est très simple : ils s'en passent !!!!! Même si l'Etat, les lois, etc... les y obligent...
De même pour le pilote qui s'est posé hier sur l'Hudson. Je suis certain (100%) qu'il a "bypassé" (pris le contrôle sur) le pilote automatique ou les logiciels de son avion... Et qu'il a été aux limites physiques de l'appareil, et non pas à ce qui était considéré comme limites "raisonnables"....

[Garulfo]

[...]
Besoins pas clairs => les développeurs ne peuvent pas penser à la place du client. On ne peut pas non plus faire de miracles.
[....]

Sauf que parfois c'est plus vicieux que juste « c'est pas clair ». C'est plutôt « ça semble clair ». Je ne sais pas ce que tu as fait comme étude ni ce que tu as eu comme cours sur l'analyse des besoins. Mais c'est extrêmement facile de planter des étudiants avec des petits pièges sémantiques, des incohérences dissimulées, des comportements trompeurs — ce qui est odieux bien sûr et qui ne se fait pas . C'est comme un bug. Si celui-ci fait exploser ton ordinateur à tous les coups, je suis convaincu que tu le verras et le corrigera. Mais si c'est un bug qui n'apparaît qu'une fois toutes les 100 000 exécutions statistiquement parlant, le verras-tu ? Probablement pas. Même un excellent plan de test pourrait te le faire échouer, et encore faudrait-il que celui-ci puisse le faire apparaitre simplement.

En tout cas, c'est souvent un facteur endémique qui est négligé par de nombreux développeurs qui croient dans le tout-technique.

[Garulfo]

[...]C'est un peu comme à l'armé, il suffit qu'un merde et tout le monde trinque.[...]

Hummm mauvais exemple On sait que pendant la seconde guerre mondiale environ 75% des soldats étaient paralysés de peur et ne tiraient pas, restant terré dans leur coin, ou tiraient au hasard dans une direction approximative. En fait, la décision revient souvent à ceux qui ont le moins de ce genre de soldats. Mais on sait qu'il y en a toujours une bonne proportion. D'où le fait que maintenant on envoie souvent des troupes surentrainées qui font 90% du travail et les autres ne font que du support.

Il est faux que dans une équipe de développement si un merde toute l'équipe trinque. C'est vrai pour de petit projet, mais dans un projet qui embauche 100 informaticiens (à tous les niveaux), deux-trois qui merdent ne font que reporter du travail sur les autres sans pour autant mettre le projet à mal. En fait, ils sont prévus dans les bons modèles. C'est pourquoi il est important qu'il y ait des vérifications en cascade.

[chaplin]

Pas tout à fait, car c'est la réaction "inespérée" que j'attendais pour contre argumenter mes dires, au sens où je retiens :

• 75% des soldats étaient paralysés de peur et ne tiraient pas
• C'est vrai pour de petit projet, je corrige en disant petite équipe mais
  projet important pour l'entreprise.

C'est un cas très rare, mais quand ces conditions sont réunies
Je répondrais que pour ce genre de situation, la réponse au problème ne relève plus du domaine informatique.

Et cette citation est criante de vérité:

War does not decide who's right, but who's left

Je suis vraiment tomber sur la bonne personne pour mon illustration