Tag: Programmation

  • 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.