Tag: Méthodologie

  • La fable qui fait rire... jaune ?

    On ne le dira jamais assez : créer un logiciel, c'est avant tout créer une bonne communication avec les utilisateurs. La qualité de l'écoute et des échanges est la condition essentielle sans quoi le logiciel ne satisfera en rien les besoins du "terrain". Le logiciel n'est que le résultat d'une écriture d'ordres donnés à la machine. Le programmeur donne les ordres grâce à l'écriture d'un langage informatique... ET en fonction de ce qu'il a compris des besoins.

    C'est là que le terme "Développeur informatique" prend tout son sens. Le développeur est la personne qui va à la fois descendre sur le terrain pour étudier les besoins et les évolutions possibles d'un logiciel pour ensuite traduire les demandes en un code compréhensible par la machine. La seule solution pour "toucher du doigt" les problèmes du "terrain" est donc de s'insérer dans la structure social pour en comprendre les tenants et les aboutissants.

    Depuis 20 ans, je passe dans des entreprises de différents horizons et je côtoie les personnes qui font "tourner la boutique" ;  il y a presque toujours un moment où un interlocuteur de l'entreprise me chuchote à l'oreille : "Tu sais, ici, tu es tombé dans une organisation très spéciale... qui marche un peu sur la tête". Après constatation des classiques absurdités fonctionnelles, je finissais par faire rire mon interlocuteur en lui racontant la fable du rameur, qui résume avec humour l'origine du mal des entreprises. Cette fable m'a toujours amusé car mon travail consiste justement à collaborer étroitement avec des "rameurs" et je me suis parfois moi-même retrouvé dans la peau de ce pauvre "rameur".

    Le rameur

    Comme la chaleur et l'oisiveté qui nous accompagnent en cette période sont propices à la réflexion, j'ai quitté mes gros livres informatiques pour tomber par hasard sur le livre “La revanche de rameur du Dr Dominique Dupagne. Ce fût une révélation ! J'en profite pour vous inciter à le lire.

    Cet essai passionnant reprend avec humour et perspicacité les dysfonctionnements sociaux et les errances auxquels je suis confronté lors de la mise en place d'un logiciel. Je vous propose de visionner la vidéo ci-dessous où le Docteur Dupagne lui-même présente son livre :

    Ce livre dont le titre est bien sûr issu de la fable, reflète parfaitement mon ressenti sur le "terrain", à savoir que ce n'est pas (toujours) la nature des dirigeants qui cause problème, c'est l'organisation elle même, fondée sur des rapports de domination au sein de hiérarchies héritées de nos ancêtres. La domination et la soumission sont au cœur de la problématique du rameur... et de l'entreprise. En cas de doute sur la soumission humaine à l'autorité, voir l'expérience de Milgram démontrée à nouveau par un faux jeu télévisé qui a défrayé la chronique en 2010.

    Aussi, le terme "stratégie GPS" utilisé par l'auteur est complètement en adéquation avec ma façon d'aborder la création des logiciels depuis de nombreuses années, à savoir : le retour d'information constant permet de modifier l'itinéraire en fonction des aléas du trajet. Cette stratégie qui consiste à planifier au minimum pour s'adapter à tout remet totalement en cause la méthode scolaire qui consiste à élaborer un cahier des charges exhaustif avant de coder la moindre ligne de programmation.

    En effet, le client est souvent incapable de définir avec précision ce qu'il désire sans partir d'une première maquette du logiciel. C'est au fur et à mesure de la mise en place du logiciel que celui-ci perçoit ce qu'il peut demander à l'ordinateur et ce qui n'est pas gérable par une machine. Le développeur informatique doit, comme un GPS, garder le contact avec les utilisateurs pour réagir vite et mettre en place rapidement les modules les plus productifs pour l'utilisateur. Cette méthode, nommée "Agilité" dans le monde informatique, m'est très familière depuis de nombreuses années.

    De la démarche qualité aux aliénations, en passant par la cybernétique et le Web 2.0, ce livre incontournable propose des solutions intéressantes que je vous laisse découvrir. Je ne peux que conclure en vous renvoyant à la vidéo du mois (ci-contre) où ce médecin, génial agitateur d'idées, vous présente toute la richesse des sujets abordés dans son livre.

    Bonne lecture...

    NB : Le site du livre est ici et vous pouvez vous le procurer ici : La revanche du rameur

    NB : Aussi, pour en savoir plus, je ne peux que vous insiter à regarder cet interview du Dr Dominique Dupagne en deux partie sur Excellence Operationnel TV : 1ère partie, 2ème partie

  • La fable du rameur

    Deux entreprises, dont une de notre pays, décident de faire une course d'aviron dans le but de montrer leur savoir-faire dans le domaine de la galvanisation des troupes.  Le doyen de l'université française, décide d'appliquer aux sportifs de son équipe les techniques managériales modernes qui font par ailleurs le succès de son établissement. Il débloque un budget considérable pour ce projet et fait appel au cabinet Delsen fondé par d'anciens élèves. Les deux équipes s'entraînent dur mais l'équipe française bénéficie donc d'une réorganisation mettant en oeuvre une nouvelle méthode.

    AVIRONLors de la première épreuve, les étrangers gagnent avec plus d'un kilomètre d'avance. Les nôtres sont très affectés. Le management se réunit pour chercher la cause de l'échec. Une equipe d'audit constituée de seniors managers est désignée.

    Apres enquête, elle constate que notre équipe, qui est constituée de dix personnes n'a qu'un rameur alors que l'équipe étrangère comporte un barreur et neuf rameurs. La direction décide de faire appel au service de consultants internes.

    Leur avis, entouré de précautions oratoires, semble préconiser l'augmentation du nombre de rameurs. Apres réflexion, la direction décide de procéder à une réorganisation. Il est décidé de mettre en place un manuel qualité, des procédures d'application, des documents de suivis... Une nouvelle stratégie est mise en place, fondée sur une forte synergie. Elle doit améliorer le rendement et la productivité grâce à ces modifications structurelles. On parle même de zéro défaut.

    La nouvelle équipe supervisée par Delsen comprend désormais :

    • 1 directeur général d'aviron
    • 1 directeur adjoint d'aviron
    • 1 manager d'aviron
    • 1 superviseur d'aviron
    • 1 consultant qualité
    • 1 contrôleur de gestion
    • 1 chargé de communication interne
    • 1 coordinateur d'aviron
    • 1 barreur
    • 1 rameur

    La course a lieu et notre équipe a 3 kilomètres de retard. Humiliée, la direction prend des décisions rapides et courageuses : elle licencie le rameur n'ayant pas atteint ses objectifs, vend le bateau et annule tout investissement. Avec l'argent économisé, elle récompense les managers et superviseurs en leur donnant une prime, augmente le salaire des directeurs et s'octroie une indemnité exceptionnelle de fin de mission.

  • Méthodologie de création d’un logiciel

    Partir du haut ou du bas ?

    Le cycle de vie d’un logiciel débute par une phase d’analyse. De cette analyse résulte un document de spécification fonctionnelle, décrivant en détail « ce que doit faire le logiciel ». La conception proprement dite fait suite à l’analyse et consiste à étudier comment concrétiser la spécification fonctionnelle à l’aide des moyens matériels et logiciels dont on dispose. Une fois la conception générale terminée, commence une étape de maquettage, en parallèle avec la conception détaillée.
    Une approche descendante
    La stratégie de développement « descendante » contribue à une bonne maîtrise des projets. Je conduis les projets en dialogue permanent avec les partenaires-utilisateurs. Un projet, c’est maintenant 80% de réflexion et 20% de développement. Devant ces constats, la stratégie de développement de LOGADAP consiste à réaliser très tôt une maquette qui préfigure le logiciel final, sous forme d’un sous-ensemble volontairement réduit. Ce sous-ensemble sera enrichi progressivement pour se rapprocher du logiciel complet.
    En quoi consiste exactement cette maquette ?
    Il s’agit du « squelette » du logiciel, constitué par la matérialisation de son architecture, dans une version dont la majorité des modules sont vides ou simulés empiriquement. Plus précisément, disons que l’ensemble des tâches et des modules de plus haut niveau sont codés réellement afin de rendre vivante cette structure minimale. Les autres modules sont codés de façon très partielle.
    Quel est l’intérêt de cette maquette si elle ne fait rien ou presque ? Premièrement, elle permet de valider l’architecture de l’information, ce qui n’est pas négligeable. Ensuite, elle permet de coder de façon grossière et d’intégrer très vite quelques modules, afin d’expérimenter la faisabilité de certains mécanismes et de démontrer les aspects du logiciel à valider vis-à-vis de l’analyse. Elle constitue également une structure d’accueil pour tester les composants logiciels du commerce utilisés.
    Le codage et l’intégration
    Une fois cette maquette validée et la conception détaillée terminée, le codage systématique des modules peut commencer, dans leur version opérationnelle. Sur la lancée de la maquette, on code les modules les uns après les autres, suivant l’ordre hiérarchique descendant. Ces modules sont codés, testés unitairement, puis intégrés dans la maquette.
    Cette approche permet de construire le logiciel progressivement, la maquette se rapprochant petit à petit du logiciel final. Cela donne une bonne visibilité contrairement à l’approche ascendante avec laquelle il est parfois nécessaire d’attendre les dernières phases d’intégration pour « voir » quelque chose tourner. Le déroulement de l’intégration devient « linéaire et incrémental », ce qui est bon également pour le moral...
    Le succès d’un logiciel adapté est le résultat d’un savant dosage entre une structure conceptuelle solide et un peu rigide et une approche empirique qui permet de bien coller aux besoins sans se diluer dans le particularisme.

    Le cycle de vie d’un logiciel débute par une phase d’analyse. De cette analyse résulte un document de spécification fonctionnelle, décrivant en détail « ce que doit faire le logiciel ». La conception proprement dite fait suite à l’analyse et consiste à étudier comment concrétiser la spécification fonctionnelle à l’aide des moyens matériels et logiciels dont on dispose. Une fois la conception générale terminée, commence une étape de maquettage, en parallèle avec la conception détaillée.

    Une approche descendante

    La stratégie de développement « descendante » contribue à une bonne maîtrise des projets. Je conduis les projets en dialogue permanent avec les partenaires-utilisateurs. Un projet, c’est maintenant 80% de réflexion et 20% de développement. Devant ces constats, la stratégie de développement de LOGADAP consiste à réaliser très tôt une maquette qui préfigure le logiciel final, sous forme d’un sous-ensemble volontairement réduit. Ce sous-ensemble sera enrichi progressivement pour se rapprocher du logiciel complet.

    En quoi consiste exactement cette maquette ?

    Il s’agit du « squelette » du logiciel, constitué par la matérialisation de son architecture, dans une version dont la majorité des modules sont vides ou simulés empiriquement. Plus précisément, disons que l’ensemble des tâches et des modules de plus haut niveau sont codés réellement afin de rendre vivante cette structure minimale. Les autres modules sont codés de façon très partielle.

    Quel est l’intérêt de cette maquette si elle ne fait rien ou presque ? Premièrement, elle permet de valider l’architecture de l’information, ce qui n’est pas négligeable. Ensuite, elle permet de coder de façon grossière et d’intégrer très vite quelques modules, afin d’expérimenter la faisabilité de certains mécanismes et de démontrer les aspects du logiciel à valider vis-à-vis de l’analyse. Elle constitue également une structure d’accueil pour tester les composants logiciels du commerce utilisés.

    Le codage et l’intégration

    Une fois cette maquette validée et la conception détaillée terminée, le codage systématique des modules peut commencer, dans leur version opérationnelle. Sur la lancée de la maquette, on code les modules les uns après les autres, suivant l’ordre hiérarchique descendant. Ces modules sont codés, testés unitairement, puis intégrés dans la maquette.

     

    Cette approche permet de construire le logiciel progressivement, la maquette se rapprochant petit à petit du logiciel final. Cela donne une bonne visibilité contrairement à l’approche ascendante avec laquelle il est parfois nécessaire d’attendre les dernières phases d’intégration pour « voir » quelque chose tourner. Le déroulement de l’intégration devient « linéaire et incrémental », ce qui est bon également pour le moral...

     

    Le succès d’un logiciel adapté est le résultat d’un savant dosage entre une structure conceptuelle solide et un peu rigide et une approche empirique qui permet de bien coller aux besoins sans se diluer dans le particularisme.

     

    Albert Einstein l'a dit autrement et avec humour « La théorie, c'est quand on sait tout et que rien ne fonctionne. La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi. Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi ! »

  • L’analyse et ses méthodes

    Faut-il suivre une méthode bien précise ?
    On a beaucoup dit et beaucoup écrit sur les méthodes informatiques. Il y en a d’excellentes et d’autres qui sont plus complexes à mettre en oeuvre. Toutes ont en commun le défaut d’être lourdes et difficiles à faire fonctionner correctement. Il est vrai que de nombreuses méthodes majorent les coûts et les délais sans contre-partie significative. Et si les méthodes étaient beaucoup plus simples que ne laissaient croire les promoteurs des méthodes. En effet, au lieu de compliquer les choses, il est préférable de chercher à simplifier les choses en allant directement à l’essentiel grâce à une approche pratique et concrète.
    Je me souviens d’une pièce ou quatre policiers sont lancés à la poursuite d’un dangereux malfaiteur. Pour qu’ils puissent le rattraper plus facilement, leur chef met à leur disposition une voiture. Mais avant de les autoriser à prendre le volant, il juge indispensable de leur faire assimiler au préalable la théorie du moteur à explosion.
    Cette scène me revient souvent en mémoire lorsque je lis des exposés sur telle ou telle méthode d’analyse informatique. Car avant d’aborder le sujet, l’auteur se lance neuf fois sur dix dans de longs développements, bourrés de symboles et de locutions ésotériques, sur la modélisation de l’entreprise, les systèmes décisionnels et autres schémas conceptuels. A croire qu’il veut me démontrer à toute force l’universalité de sa méthode.
    "VOUS SAVEZ, MOI, LES METHODES"
    Ce niveau de généralité n’est-il pas bien éloigné de ce que doivent être nos préoccupations de tous les jours ? Je suis un informaticien de terrain et je n’ai que faire de la notion abstraite de système universel. J’opère dans une entreprise précise, souvent même dans une partie seulement de cette entreprise, qui est différente de toutes celles qui l’entourent.
    Une autre caractéristique de ces ouvrages, c’est leur intolérance. On nous prévient généralement dès le départ : hors de la méthode, point de salut ! Si on sort de la théorie pour aller voir sur place comment les choses se passent, la vision est totalement différente. Dans de nombreux cas, les systèmes en fonctionnement semblent avoir été étudiés et réalisés essentiellement au fur et à mesure des demandes, sans méthode précise, au hasard des connaissances et des habitudes des uns et des autres. Lorsqu’on intéroge un analyste, il a tendance à répondre par un discours du genre :
    "Je ne suis dans cette entreprise que depuis quelques mois. Mon chef de service voudrait que j’applique la méthode Merise. Mais dans l’entreprise où j’étais auparavant, on ne jurait que par PacBase. Il est probable que ce sera encore une autre qu’on voudra m’apprendre lorsque j’aurai encore changé d’entreprise. A quoi bon faire des efforts que, compte tenu de mon turn-over, je suis à peu près sûr de ne jamais amortir ?"
    Que penser de tout cela ? En d’autres termes, faut-il avoir ou non une méthode, et dans l’affirmative, laquelle choisir ?
    EN AVOIR OU PAS
    L’application d’une méthode supprime les astuces et les raccourcis. Les études sont plus complètes et plus solides, mais elles durent en général plus longtemps. Il y a aussi l’important travail de documentation. Bien sûr, cette documentation sera utile plus tard, et contribuera à faciliter la maintenance et à prolonger la durée de vie de l’application. Mais, en attendant, il faut la rédiger, et cela prend beaucoup de temps.
    "Des observations portant sur plus d’une centaine de grandes entreprises, aux Etats-Unis et en Europe, montrent malheureusement que le manuel des standards et procédures concernant le logiciel contient environ 500 pages et qu’il retarde en moyenne de plus de trois ans sur l’état de l’art le plus récent."
    Certes, une méthode est indispensable pour arriver au but, de même qu’un certain niveau de documentation. Mais il ne faut pas que méthode et documentation cessent d’être des moyens pour se transformer en buts.
    LA MAQUETTE
    Entre la nécessité d’une méthode et l’impossibilité d’y consacrer trop de temps, la solution consiste-t-elle à faire vite et mal ? Je ne le pense pas, car il me paraît possible de faire vite et bien. Plus exactement, il n’est pas nécessaire d’attendre d’avoir tout étudié dans le détail pour lancer la réalisation. Il y a un minimum de choses à définir avant de commencer à bâtir un système. Mais ce minimum de choses peut s’obtenir très rapidement, car il s’agit en somme de définir l’ossature du système. La suite de l’étude, qui consiste à habiller cette ossature, peut se dérouler en grande partie en même temps que les travaux de contruction.
    IL FAUT ETRE GENTIL AVEC LES UTILISATEURS
    Une fois venu le moment d’aborder la recherche d’une solution. Ici, la culture informatique va servir, à condition de n’en pas faire état auprès des utilisateurs. Si nous voulons vraiment les aider, il nous faut laisser aux charlatans (qui abondent comme on le sait dans la profession des informaticiens) l’usage du jargon. Les mots de tous les jours permettront de mieux se comprendre, et d’entretenir un dialogue sans lequel on risque de manquer la cible.
    Au lieu donc de parler de schéma conceptuel, de règles de gestion, d’ensembles entités-relations, de troisième forme normale, etc. dressons la liste des objets à gérer : des clients, des produits, des commandes... ensuite procurons-nous des spécimens de bons de commandes pour en repérer l’architecture : ont-ils une seule ligne ou plusieurs ? Les produits sont-ils désignés par un simple numéro de code ou par une description plus ou moins longue ? Des codes sont-ils attribués systématiquement à tous les clients ou seulement à quelques-uns ? etc. Acec ce genre de démarche, l’architecture de l’application se dégage rapidement.
    "Ce que l’on conçoit bien ....". Le vers célèbre s’applique parfaitement à l’informatique qui n’était pourtant pas encore inventée du temps de Boileau.
    ALLER A L’ESSENTIEL
    Comme on le voit, la démarche est simple. Il suffit de veiller à avoir quelques idées claires et de chercher à dégager un schéma d’ensemble qui met en évidence l’essentiel. C’est ça la vraie méthode. Tout le reste n’est que littérature et bavardage.
    Nous obtenons ainsi progressivement le schéma de la base de données de l’application. Cependant, nous ne sommes pas encore au bout de nos peines, car il reste à définir la logique des traitements. C’est une opération difficile, surtout si l’on veut respecter les règles de la conception structurée, c’est à dire construire des modules à forte cohésion interne et aussi faiblement couplés que possible entre eux. Mais si on adopte la démarche déscendante, on pourra démarrer la programmation et les essais des modules supérieurs avant d’avoir achevé la mise au point des modules situés plus bas dans la hiérarchie.
    L’important est donc de conduire les travaux d’analyse, de conception et de programmation selon une démarche logique. Peu importe au fond si cette démarche relève de la méthode de Paul ou de celle de Jacques.
    Trop souvent les méthodes informatiques aboutissent à compliquer un problème facile. Il faut en fait avoir la démarche inverse et chercher à rendre moins complexes des choses qui ne sont pas toujours simples.

    Faut-il suivre une méthode bien précise ?

    On a beaucoup dit et beaucoup écrit sur les méthodes informatiques. Il y en a d’excellentes et d’autres qui sont plus complexes à mettre en oeuvre. Toutes ont en commun le défaut d’être lourdes et difficiles à faire fonctionner correctement. Il est vrai que de nombreuses méthodes majorent les coûts et les délais sans contre-partie significative. Et si les méthodes étaient beaucoup plus simples que ne laissaient croire les promoteurs des méthodes. En effet, au lieu de compliquer les choses, il est préférable de chercher à simplifier les choses en allant directement à l’essentiel grâce à une approche pratique et concrète.

    Je me souviens d’une pièce ou quatre policiers sont lancés à la poursuite d’un dangereux malfaiteur. Pour qu’ils puissent le rattraper plus facilement, leur chef met à leur disposition une voiture. Mais avant de les autoriser à prendre le volant, il juge indispensable de leur faire assimiler au préalable la théorie du moteur à explosion.

    Cette scène me revient souvent en mémoire lorsque je lis des exposés sur telle ou telle méthode d’analyse informatique. Car avant d’aborder le sujet, l’auteur se lance neuf fois sur dix dans de longs développements, bourrés de symboles et de locutions ésotériques, sur la modélisation de l’entreprise, les systèmes décisionnels et autres schémas conceptuels. A croire qu’il veut me démontrer à toute force l’universalité de sa méthode.

    "VOUS SAVEZ, MOI, LES METHODES"

    Ce niveau de généralité n’est-il pas bien éloigné de ce que doivent être nos préoccupations de tous les jours ? Je suis un informaticien de terrain et je n’ai que faire de la notion abstraite de système universel. J’opère dans une entreprise précise, souvent même dans une partie seulement de cette entreprise, qui est différente de toutes celles qui l’entourent.

    Une autre caractéristique de ces ouvrages, c’est leur intolérance. On nous prévient généralement dès le départ : hors de la méthode, point de salut ! Si on sort de la théorie pour aller voir sur place comment les choses se passent, la vision est totalement différente. Dans de nombreux cas, les systèmes en fonctionnement semblent avoir été étudiés et réalisés essentiellement au fur et à mesure des demandes, sans méthode précise, au hasard des connaissances et des habitudes des uns et des autres. Lorsqu’on intéroge un analyste, il a tendance à répondre par un discours du genre :

    "Je ne suis dans cette entreprise que depuis quelques mois. Mon chef de service voudrait que j’applique la méthode Merise. Mais dans l’entreprise où j’étais auparavant, on ne jurait que par PacBase. Il est probable que ce sera encore une autre qu’on voudra m’apprendre lorsque j’aurai encore changé d’entreprise. A quoi bon faire des efforts que, compte tenu de mon turn-over, je suis à peu près sûr de ne jamais amortir ?"

    Que penser de tout cela ? En d’autres termes, faut-il avoir ou non une méthode, et dans l’affirmative, laquelle choisir ?

    EN AVOIR OU PAS

    L’application d’une méthode supprime les astuces et les raccourcis. Les études sont plus complètes et plus solides, mais elles durent en général plus longtemps. Il y a aussi l’important travail de documentation. Bien sûr, cette documentation sera utile plus tard, et contribuera à faciliter la maintenance et à prolonger la durée de vie de l’application. Mais, en attendant, il faut la rédiger, et cela prend beaucoup de temps.

    "Des observations portant sur plus d’une centaine de grandes entreprises, aux Etats-Unis et en Europe, montrent malheureusement que le manuel des standards et procédures concernant le logiciel contient environ 500 pages et qu’il retarde en moyenne de plus de trois ans sur l’état de l’art le plus récent."

    Certes, une méthode est indispensable pour arriver au but, de même qu’un certain niveau de documentation. Mais il ne faut pas que méthode et documentation cessent d’être des moyens pour se transformer en buts.

    LA MAQUETTE

    Entre la nécessité d’une méthode et l’impossibilité d’y consacrer trop de temps, la solution consiste-t-elle à faire vite et mal ? Je ne le pense pas, car il me paraît possible de faire vite et bien. Plus exactement, il n’est pas nécessaire d’attendre d’avoir tout étudié dans le détail pour lancer la réalisation. Il y a un minimum de choses à définir avant de commencer à bâtir un système. Mais ce minimum de choses peut s’obtenir très rapidement, car il s’agit en somme de définir l’ossature du système. La suite de l’étude, qui consiste à habiller cette ossature, peut se dérouler en grande partie en même temps que les travaux de contruction.

    IL FAUT ETRE GENTIL AVEC LES UTILISATEURS

    Une fois venu le moment d’aborder la recherche d’une solution. Ici, la culture informatique va servir, à condition de n’en pas faire état auprès des utilisateurs. Si nous voulons vraiment les aider, il nous faut laisser aux charlatans (qui abondent comme on le sait dans la profession des informaticiens) l’usage du jargon. Les mots de tous les jours permettront de mieux se comprendre, et d’entretenir un dialogue sans lequel on risque de manquer la cible.

    Au lieu donc de parler de schéma conceptuel, de règles de gestion, d’ensembles entités-relations, de troisième forme normale, etc. dressons la liste des objets à gérer : des clients, des produits, des commandes... ensuite procurons-nous des spécimens de bons de commandes pour en repérer l’architecture : ont-ils une seule ligne ou plusieurs ? Les produits sont-ils désignés par un simple numéro de code ou par une description plus ou moins longue ? Des codes sont-ils attribués systématiquement à tous les clients ou seulement à quelques-uns ? etc. Acec ce genre de démarche, l’architecture de l’application se dégage rapidement.

    "Ce que l’on conçoit bien ....". Le vers célèbre s’applique parfaitement à l’informatique qui n’était pourtant pas encore inventée du temps de Boileau.

    ALLER A L’ESSENTIEL

    Comme on le voit, la démarche est simple. Il suffit de veiller à avoir quelques idées claires et de chercher à dégager un schéma d’ensemble qui met en évidence l’essentiel. C’est ça la vraie méthode. Tout le reste n’est que littérature et bavardage.

    Nous obtenons ainsi progressivement le schéma de la base de données de l’application. Cependant, nous ne sommes pas encore au bout de nos peines, car il reste à définir la logique des traitements. C’est une opération difficile, surtout si l’on veut respecter les règles de la conception structurée, c’est à dire construire des modules à forte cohésion interne et aussi faiblement couplés que possible entre eux. Mais si on adopte la démarche déscendante, on pourra démarrer la programmation et les essais des modules supérieurs avant d’avoir achevé la mise au point des modules situés plus bas dans la hiérarchie.

    L’important est donc de conduire les travaux d’analyse, de conception et de programmation selon une démarche logique. Peu importe au fond si cette démarche relève de la méthode de Paul ou de celle de Jacques.

    Trop souvent les méthodes informatiques aboutissent à compliquer un problème facile. Il faut en fait avoir la démarche inverse et chercher à rendre moins complexes des choses qui ne sont pas toujours simples.