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 ! »

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.