Chapitre 6. Génie logiciel

Table des matières
Le cycle de développement du logiciel
Tests détaillés
Le développement des logiciels libres
Conclusions

Le « génie logiciel » couvre un champ plus vaste que « l'écriture de programmes ». Néanmoins, dans de nombreux projets de logiciels libres, les programmes sont tout simplement écrits et diffusés. Il est clair, à partir d'exemples passés, que la réalisation d'un logiciel n'a pas besoin d'être organisée pour qu'il soit utilisé et apprécié. Dans cet essai, nous examinerons quelques éléments généraux du génie logiciel, puis leurs équivalents habituels dans la communauté des logiciels libres, pour finalement voir les implications des différences entre ces deux approches.

Le cycle de développement du logiciel

Les étapes suivantes permettent de décrire, en général, le cycle de développement du logiciel :

Aucune ne doit commencer avant que les précédentes ne soient réellement terminées, et lorsqu'une modification est effectuée sur un élément, tous ceux qui en dépendent doivent être revus en en tenant compte. Il se peut qu'un module donné soit à la fois spécifié et implémenté avant que ceux qui en dépendent soient complètement spécifiés, situation que l'on appelle développement avancé ou recherche.

Il est absolument essentiel que chaque phase du processus liée au génie logiciel subisse plusieurs types de revues : revue des pairs, revue par le responsable projet et par la direction, et revue interdisciplinaire.

Les éléments correspondant au cycle de développement du logiciel (les documentations ou code source) doivent porter des numéros de version et faire l'objet d'un historique. « L'enregistrement » d'une modification dans un élément impose un certain type d'examen dont l'ampleur doit correspondre directement à l'importance des modifications.

Expression des besoins

La première étape du cycle de développement d'un logiciel consiste à produire un document qui décrit les utilisateurs visés et leurs objectifs. Ce document formalise la liste des fonctions à accomplir pour répondre aux besoins des clients. Le « Dossier de Spécification du Logiciel » (DSL) constitue le document de référence dans lequel on trouvera les réponses aux questions « Que doit-on faire et qui utilisera le produit ? ».

Le DSL de nombreux projets qui échouèrent avait été considéré comme constituant les « Tables de la loi » remises par les gens du commercial aux ingénieurs, qui, alors, ronchonnèrent longuement sur les lois de la physique et sur les raisons qu'ils avaient de ne pas pouvoir fabriquer ce produit puisqu'ils n'était pas possible de s'approvisionner en « Kryptonite » ou quoi que ce soit d'autre. Le DSL est le fruit d'un effort conjoint auquel les ingénieurs doivent aussi participer en rédigeant de nombreuses sections, et non en se contentant d'en analyser le termes.

Conception préliminaire

C'est une description de haut niveau du produit, en termes de « modules » (ou quelquefois de « programmes ») et de leurs interactions. Ce document doit en premier lieu asseoir la confiance en la finalité et la faisabilité du produit, et, en second lieu, servir de base pour l'estimation de la quantité de travail à fournir pour le réaliser.

Le « Dossier de Conception Préliminaire » doit également mettre en évidence le plan de test, en termes de besoins de l'utilisateur, et montrer que l'on peut y satisfaire grâce à l'architecture proposée.

Conception détaillée

C'est au niveau de la conception détaillée que chacun des modules énumérés dans le dossier de conception préliminaire est décrit en détail. L'interface (formats de lignes de commande, appels d'API, structures de données visibles de l'extérieur) de chacun des modules doit être complètement définie à ce niveau. Deux choses doivent émerger lors de cette étape : un diagramme de PERT ou de GANTT, montrant comment le travail doit être fait et dans quel ordre, ainsi qu'une estimation plus précise de la charge de travail induite par la réalisation de chacun des modules.

Chaque module doit avoir un plan de test unitaire, qui fournit aux réalisateurs la liste des tests à effectuer ou des types de scénarios de test a créer afin de vérifier que le module répond aux spécifications. Il faut noter qu'il existe des tests unitaires complémentaires, ne concernant pas les fonctionnalités, dont on parlera plus tard.

Implémentation

Chacun des modules décrit dans le document de spécification détaillé doit être réalisé. Cela comprend la petite activité de codage ou de programmation qui constitue le cœur et l'âme du processus de développement du logiciel. Il est malheureux que cette petite activité soit quelquefois l'unique partie du génie logiciel qui soit enseignée (ou étudiée), puisque c'est également la seule partie du génie logiciel qu'un autodidacte peut réellement appréhender.

On peut considérer qu'un module a été réalisé quand il a été créé, testé et utilisé avec succès par un autre module (ou par un processus de test au niveau système). La création d'un module se fait dans le cadre du cycle classique édition-compilation-répétition. Le test des modules comprend les tests au niveau unitaire les tests de non-régression définis lors de la conception détaillée, ainsi que les tests de performances et de charge et l'analyse de couverture du code.

Intégration

Quand tous les modules sont terminés, l'intégration, au niveau du système, peut être réalisée. C'est là que tous les modules sont réunis en un seul ensemble de code source, compilés et liés pour former un paquetage qui constitue le système. L'intégration peut être réalisée de façon incrémentale, en parallèle avec la réalisation de différents modules, mais on ne peut pas décider de manière autoritaire que « c'est fini » tant que tous les modules ne sont pas effectivement terminés.

L'intégration comprend le développement de tests au niveau du système. Si le paquetage réalisé est capable de s'installer lui-même (ce qui signifie simplement le décompactage d'une archive ou la copie de fichiers d'un CD-ROM) il doit alors exister un moyen de le faire automatiquement, soit sur des systèmes spécialisés, soit dans des environnements de simulation.

Parfois, dans le cas des logiciels personnalisés, le paquetage est constitué du simple exécutable résultant de la compilation de l'ensemble des modules, et, dans ce cas, il n'y a pas d'outil d'installation ; les tests seront effectués tels quels.

Le système ayant été installé (s'il doit l'être), le processus de tests au niveau système doit pouvoir lancer toutes les commandes publiques et appeler tous les points d'entrée publics, en utilisant toutes les combinaisons raisonnables d'arguments. Si le système doit pouvoir créer une sorte de base de données, la procédure automatisée de test au niveau système doit en créer une et utiliser des outils extérieurs (écrits séparément) pour vérifier l'intégrité de la base de données. Les tests unitaires peuvent être utilisés pour répondre à certains de ces besoins, et tous les tests unitaires doivent être exécutés en séquence pendant le processus d'intégration, de construction et de réalisation du paquetage.

Essais in situ

Les essais in situ commencent généralement en interne. Ce qui signifie que des employés de l'organisation qui a produit le logiciel vont l'essayer sur leurs propres ordinateurs. Ceci doit inclure tous les systèmes « du niveau production », c'est-à-dire tous les ordinateurs de bureau, les portables et les serveurs. Vous devez pouvoir dire, au moment où vous demanderez à vos clients d'utiliser le nouveau système logiciel (ou une nouvelle version d'un logiciel existant) « nous l'avons nous-même testé ». Les développeurs du logiciel doivent être disponibles lors de l'assistance technique directe assurée pendant la phase de tests in situ interne.

Enfin, il sera nécessaire de faire fonctionner le logiciel à l'extérieur, c'est-à-dire sur les ordinateurs des clients (ou de ceux que l'on espère voir devenir des clients). Il vaut mieux choisir des « clients amicaux » pour ce genre d'exercice, puisqu'ils découvriront peut-être de nombreux défauts, même évidents, tout simplement parce que leur manière de travailler et leurs habitudes sont différentes de celles de vos utilisateurs internes. Les développeurs du logiciel doivent être en première ligne pendant cette phase de test in situ externe.

Les défauts rencontrés pendant la phase de test in situ devront être étudiés par des développeurs confirmés et des ingénieurs commerciaux, pour déterminer ceux qui doivent être corrigés dans la documentation, ceux qui doivent être corrigés avant que cette version du logiciel ne soit diffusée et ceux qui le seront dans la prochaine version (ou jamais).

Maintenance et assistance

Les défauts du logiciel rencontrés soit pendant la phase de test in situ soit après sa diffusion doivent être enregistrés dans un système de suivi. Il faudra affecter un ingénieur logiciel pour la prise en charge de ces défauts, qui proposera de modifier soit la documentation du système, soit la définition d'un module ou la réalisation de ce module. Ces modifications devront entraîner l'ajout de tests unitaires ou au niveau système, sous forme de tests de non-régression pour mettre en évidence le défaut et montrer qu'il a bien été corrigé (et pour éviter de le voir réapparaître plus tard).

Exactement comme le DSL a constitué une entreprise en commun entre les commerciaux et les ingénieurs, la maintenance est une entreprise commune aux ingénieurs et au service client. La liste des bogues, la description de bogues particuliers, le nombre maximum de défauts critiques dans une version diffusée du logiciel,... constituent les pièces maîtresses de cette édifice.