OSI


home



Tribune Libre
Ténors de l'Informatique Libre

Copyright © 1999 par Éditions O'Reilly

< Chapitre 5 Sommaire Chapitre 7 >

Chapitre 6. Génie logiciel

Paul Vixie
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 :

  • L'expression des besoins du produit,

  • La conception préliminaire, au niveau système,

  • La conception détaillée,

  • L'implémentation, ou phase de codage,

  • L'intégration,

  • Les essais in situ,

  • La maintenance et assistance.

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.

Tests détaillés

Tests de couverture

Le test de couverture du code commence avec l'introduction d'instructions spéciales dans le code du programme, quelquefois par un préprocesseur, quelquefois par un modificateur de code objet, quelquefois en utilisant un mode spécial du compilateur ou de l'éditeur de liens, pour suivre tous les chemins possible dans un bloc de code source et d'enregistrer, pendant leur exécution, tous ceux qui ont été parcourus.

Examinons l'extrait de code C, tout à fait typique, suivant :

1.   if (read(s, buf, sizeof buf) == -1)
2.   error++; 
3.   else
4.   error = 0; 

Ce code présente un défaut si la variable « error » n'a pas été initialisée, et si la ligne 2 est exécutée les résultats seront imprévisibles. La probabilité d'apparition d'une erreur dans une instruction « read » (et d'obtenir une valeur de retour égale à -1) lors de tests normaux est assez faible. La manière d'éviter la maintenance coûteuse de ce genre de bogue consiste à s'assurer que les tests unitaires traitent tous les chemins possibles dans le code et que les résultats sont corrects dans tous les cas.

Mais il y a mieux : les chemins possibles dans le code se combinent. Dans notre exemple ci-dessus, la variable d'erreur peut avoir été initialisée avant, disons par un morceau de code similaire dont le prédicat (« échec de l'appel système ») était faux (signifiant l'apparition de l'erreur). L'exemple suivant, dont le code est manifestement incorrect et qui n'aurait pas surmonté un examen, montre la facilité avec laquelle des choses simples peuvent devenir compliquées :

1.   if (connect(s, &sa, &sa_len) == -1)
2.   error++;
3.   else
4.   error = 0;
5.   if (read(s, buf, sizeof buf) == -1)
6.   error++;
7.   else
8.   error = 0;

Il existe maintenant quatre chemins à tester dans le code :

  • lignes 1-2-5-6

  • lignes 1-2-5-8

  • lignes 1-4-5-6

  • lignes 1-4-5-8

Il est en général impossible de tester tous les chemins possibles dans le code, il peut y en avoir des centaines, même dans une petite fonction de quelques dizaines de lignes. Et d'un autre côté, il n'est pas suffisant de s'assurer uniquement que les tests unitaires sont capables (éventuellement en plusieurs fois) de mettre à l'épreuve toutes les lignes de code. Ce type d'analyse de couverture ne fait pas partie de la trousse à outils de tous les ingénieurs logiciel sur le terrain, c'est pourquoi l'assurance qualité (AQ) en fait sa spécialité.

Tests de non-régression

Corriger une erreur n'est pas suffisant. L'expression « évident à l'examen » constitue souvent une réponse destinée à cacher celle, plus insidieuse, affirmant « il serait difficile d'écrire un test qui pète le feu ». Bon, oui, de nombreux bogues sautent aux yeux lors d'un examen, comme la division par la constante zéro. Mais pour savoir quoi corriger, il faut examiner le code environnant pour comprendre les intentions de l'auteur. Ce genre d'analyse doit être documenté dans la correction ou dans les commentaires accompagnant le code source.

Dans le cas le plus fréquent, le bogue n'est pas évident à l'examen et la correction se trouve à un endroit différent, dans le code source, de celui où le programme provoque une erreur fatale ou a un comportement inadéquat. Dans ces circonstances, il faut écrire un nouveau test qui met à l'épreuve la partie de code défaillant (ou qui met le programme dans un état incorrect ou autre) puis il faut tester la correction avec ce nouveau test unitaire. Après revue et enregistrement, le nouveau test unitaire doit également être enregistré de façon à ce que si le même bogue est réintroduit plus tard comme effet secondaire de quelque autre modification, l'AQ ait quelque espoir de le trouver avant les clients.

Le développement des logiciels libres

Un projet de logiciel libre peut inclure n'importe lequel des éléments décrits ci-dessus, et pour être honnête, c'est le cas de quelques uns d'entre eux. Les versions commerciales de BSD, Bind et Sendmail sont des exemples d'un processus de développement logiciel standard, mais ils n'ont pas débuté de cette façon. Un véritable processus de développement logiciel nécessite énormément de ressources, et en lancer un représente, en général, un investissement que seul un retour peut justifier.

Le cas, de loin le plus fréquent, de développement d'un logiciel libre est celui où les gens concernés se régalent dans ce qu'ils font et veulent que leur travail soit aussi utile que possible. Et, pour ce faire, ils le diffusent sans rétribution et quelquefois sans restrictions sur sa distribution. Ces gars-là peuvent ne pas avoir accès à ce que l'on appelle des outils de « qualité commerciale » (tels que des analyseurs de code, des vérificateurs de limites et des contrôleurs de l'intégrité mémoire). Ils paraissent trouver la programmation, la réalisation de paquetage, et le prosélytisme particulièrement amusants, et pas l'AQ (Assurance Qualité), les DSL (Dossier de Spécification du Logiciel) et ils ne sont pas habituellement des champions des délais de réalisation courts.

Reprenons chacune des étapes du processus de développement d'un logiciel et voyons comment elles s'articulent dans un projet de logiciel libre, non financé, d'un travail de passionné.

Expression des besoins

Les développeurs de logiciel libre ont tendance à réaliser les outils dont ils ont besoin ou dont ils ont envie. Il arrive quelquefois que cela coïncide avec ce qu'ils font au travail et souvent ce sont ceux dont la tâche première est l'administration plutôt que le développement de logiciel. Si, après plusieurs versions, un système logiciel atteint la masse critique et devient autonome, il sera distribué sous forme de fichier archive via l'Internet et les utilisateurs pourront commencer, soit à demander l'ajout de fonctionnalités, soit à se mettre à en ajouter et à en faire profiter la communauté.

La constitution d'un « DSLL » (Dossier de Spécification d'un logiciel libre) s'effectue généralement grâce à une liste de diffusion ou à un groupe de discussion où utilisateurs et développeurs discutent directement. Le consensus se fait sur ce que les développeurs ont retenu de la discussion ou sur ce avec quoi ils sont d'accord. Si un consensus suffisant ne peut être obtenu, il va en résulter un « embranchement dans le code » où d'autres développeurs se mettront à diffuser leurs propres versions. L'équivalent du DSL dans le cas du logiciel libre peut être très enrichissant mais peut créer des conflits aigus dont la résolution n'est pas possible (ou pas tentée).

Conception préliminaire, au niveau système

Il n'y a pas, en général, d'étape de conception préliminaire dans un projet de développement d'un logiciel libre non financé. Cette étape est soit implicite, jaillissant toute entière et d'un seul coup de la cuisse de Jupiter, soit elle évolue avec le temps (comme le logiciel lui-même). Habituellement, avec les versions 2 ou 3 d'un logiciel libre, on voit apparaître une réelle architecture du système, même si celle-ci n'a pas été formalisée quelque part.

C'est ici, plutôt que n'importe où ailleurs que, par rapport aux règles normales du développement des logiciels, les logiciels libres ont gagné leur réputation d'être quelque peu farfelus. On peut compenser une absence de DSL ou même de démarche d'assurance qualité en ayant de très bons programmeurs (ou des utilisateurs particulièrement amicaux), mais, s'il n'y a pas eu de conception au niveau du système (même si c'est seulement dans la tête de quelqu'un), la qualité du projet résultant sera limitée.

Conception détaillée

Le DCD (Dossier de Conception Détaillée) constitue une autre victime de l'absence de rétribution et de la volonté de se faire plaisir des gens qui développent des logiciels libres. Certains aiment travailler sur un DCD mais, en général, prennent tout leur plaisir lorsqu'ils le font dans leur travail journalier. La conception détaillée devient un effet de bord du développement : « Je sais que j'ai besoin d'un analyseur, donc, je vais en écrire un ». La documentation des interfaces de programmation des applications (API) sous la forme de symboles externes, dans des fichiers d'en-tête ou dans des pages de man est optionnelle et peut devenir inexistante si cette interface n'est pas destinée à être publiée ou utilisée en dehors du projet.

C'est vraiment regrettable car cela rend inaccessible pas mal de très bons codes qui, autrement, pourraient être réutilisables. Même les modules qui ne sont pas réutilisables ou étroitement liés au projet pour lequel ils ont été créés, et dont les interfaces de programmation ne font pas partie des éléments à délivrer, devraient vraiment avoir des pages de man pour expliquer ce qu'ils font et comment les appeler. C'est extrêmement utile pour ceux qui veulent améliorer le code, puisqu'ils doivent commencer par le lire et le comprendre.

Implémentation

C'est la partie amusante. L'implémentation est la partie que les programmeurs préfèrent ; c'est ce qui les fait veiller alors qu'ils devraient dormir. L'occasion d'écrire du code constitue la motivation première de pratiquement tous les efforts de développement de logiciel libre qui ont eu lieu. Si l'on se concentre sur cet aspect du développement logiciel à l'exclusion des autres, il apporte une très grande liberté d'expression.

C'est dans le développement de logiciels libres que la plupart des programmeurs expérimentent de nouveaux styles, que ce soit un style d'indentation, une manière de donner un nom aux variables ou « un essai d'économie d'utilisation de la mémoire » ou « un essai d'économie de cycles CPU » ou ce que vous voulez. Et il y a quelques extraits d'une grande beauté qui attendent dans des archives un peu partout, où un programmeur a essayé avec succès un nouveau style.

Un effort pour un logiciel libre non financé peut avoir autant de rigueur et de qualité qu'on le veut. Les utilisateurs exploitent le code s'il est fonctionnel et la plupart des gens ne font pas attention au fait que le développeur a changé de style trois fois pendant la phase de réalisation. Les développeurs y font en général attention, ou apprennent à le faire après un certain temps. Devant une telle situation, les commentaires de Larry Wall, selon qui la programmation est un art, prennent toute leur signification.

La principale différence dans une réalisation de logiciel libre non financé vient de ce que la revue du code est informelle. Il n'y a généralement pas de supérieur ou de pair pour regarder le code avant qu'il ne soit diffusé. Il n'y a habituellement pas de test unitaire, de non-régression ou quoi que ce soit d'autre.

Intégration

L'intégration, dans un projet logiciel libre, consiste habituellement à écrire quelques pages de man, à s'assurer que le logiciel se construit sur tous les systèmes auxquels le développeur a accès, à nettoyer le fichier « Makefile » pour le débarrasser de toutes les commandes superflues qui se sont accumulées pendant la phase d'implémentation, à écrire un LISEZMOI, à faire une archive, à la télécharger sur un site ftp anonyme quelque part et à poster une annonce dans la liste de diffusion ou le forum de discussion des utilisateurs concernés.

Notons que le groupe de discussion comp.sources.unix a été ranimé en 1998 par Rob Braun et qu'il constitue l'endroit idéal pour poster des annonces concernant de nouveaux paquetages de logiciels libres ou des mises à jour de logiciels existants. Il fonctionne également comme archive de dépôt.

Il n'y a pas, habituellement, de plan de test au niveau du système et pas de tests unitaires. En fait, pour ce qui est des logiciels libres, les efforts consentis pour les tests en général sont très limités (des exceptions existent, telles que Perl et PostgreSQL). Cependant, comme nous allons le voir, ce manque des tests avant diffusion n'est pas une faiblesse.

Tests in situ

Le logiciel libre non financé bénéficie des meilleurs tests au niveau système, sauf si nous y incluons les tests de la NASA sur les robots destinés à aller dans l'espace. Cela vient simplement du fait que les utilisateurs ont tendance à être beaucoup plus amicaux lorsqu'ils n'ont rien à payer, et les utilisateurs faisant autorité (souvent eux-mêmes développeurs) sont souvent plus serviables lorsqu'ils peuvent lire et corriger le code source de quelque chose qu'ils emploient.

Le manque de rigueur constitue l'essence des tests de terrain. Le génie logiciel impose aux utilisateurs qui réalisent les tests d'essayer des cas d'utilisation intrinsèquement imprévisibles au moment où le système a été conçu et réalisé ; en d'autres termes, des expériences réelles d'utilisateurs réels. Les projets de logiciels libres non financés sont proprement imbattables dans ce domaine.

La « revue des pairs » de dizaines ou de centaines d'autres programmeurs traquant les bogues en lisant le code source plutôt qu'en utilisant simplement des paquetages exécutables constitue un autre avantage dont profitent les projets de logiciels libres. Quelques uns des lecteurs rechercheront les failles de sécurité et certaines de celles qui seront découvertes ne seront pas signalées (en dehors du cercle des pirates), mais ce risque est faible par rapport à l'avantage de voir un nombre incalculable d'étrangers lire le code source. Ces étrangers peuvent réellement faire travailler le développeur plus tard le soir qu'aucun patron ou aucun chef ne pourrait ou ne voudrait l'imposer.

Maintenance et assistance

« Oh là là, désolé », voilà ce que l'on répond habituellement à un utilisateur qui découvre un bogue, ou, « Oh là là, désolé, et merci ! » si celui-ci ajoute la correction du bogue. Les développeurs de logiciels libres font le tri des bogues à la réception des messages « Hé, ça marche chez moi ». Cela vous paraît chaotique, ça l'est. Le manque d'assistance peut empêcher certains utilisateurs de vouloir (ou de pouvoir) utiliser les programmes issus du monde des logiciels libres non financés, mais cela peut également créer des occasions pour des cabinets de conseil ou des distributeurs de logiciels de vendre des contrats d'assistance et/ou de vente de versions améliorées et/ou de vente de versions commerciales.

Lorsque la communauté des éditeurs d'Unix s'est trouvée confrontée à la demande pressante, de la part de ses utilisateurs, de fournir des logiciels libres pré-intégrés dans leurs systèmes de base, leur première réaction a été de dire « Eh bien, d'accord, mais nous n'en assurerons pas l'assistance ». Le succès d'entreprises comme Cygnus™ a été dû à son ré-examen rapide de cette position, mais le fossé entre les cultures est vraiment très profond. Les éditeurs de logiciels traditionnels, y compris les éditeurs d'Unix, ne peuvent tout simplement pas planifier la fourniture de contrats d'assistance si de nombreuses personnes inconnues modifient librement les logiciels.

Quelquefois, la réponse consiste à reprendre le logiciel en interne, en le faisant entrer dans le cycle normal de l'assurance qualité avec les tests unitaires et les tests au niveau du système, l'analyse de couverture du code et tout le reste. Cela peut entraîner une ingénierie inverse du DSL et du DCD pour fournir une référence à l'assurance qualité (i.e., quelles fonctionnalités doivent être testées). D'autres fois, la réponse consiste à réécrire les termes du contrat d'assistance en remplaçant « résultats garantis » par « meilleurs efforts ». Finalement, le marché de l'assistance sera occupé par ceux qui pourront fédérer tous cette foule d'étrangers, dans la mesure ou parmi eux il y a des gens bien, nombreux, qui écrivent du logiciel de qualité, et que la « culture logiciel libre » est, dans de nombreux cas, la plus efficace pour fournir le niveau de fonctionnalité que les utilisateurs désirent réellement (comme en témoigne Linux par rapport à MS-Windows).

Conclusions

L'ingénierie est un domaine ancien et, que l'on réalise un logiciel, un matériel ou un pont de chemin de fer, les étapes du processus sont essentiellement les mêmes :

  • Identification d'un besoin, et des demandeurs,

  • Conception d'une solution qui réponde à ce besoin,

  • Division du projet en modules, planification de la réalisation,

  • Réalisation, tests, fourniture et suivi.

Certains domaines privilégient certaines phases. Par exemple, les constructeurs de ponts de chemin de fer n'ont pas trop à réfléchir sur le document récapitulant les besoins du marché (le DSL, pour le logiciel), le processus de réalisation, ou le suivi, mais il doivent faire très attention au dossier de spécification détaillé, au dossier de conception détaillé et, bien évidemment à l'assurance qualité (AQ).

Le moment déterminant de la conversion d'un « programmeur » en « ingénieur logiciel » se situe lorsqu'il réalise que le génie logiciel est un domaine dans lequel il peut entrer mais que, pour cela, il lui faut une approche intellectuelle radicalement différente, et pas mal de travail. Il se passe souvent des années avant que la différence entre programmation et génie logiciel ne saute aux yeux des développeurs de logiciels libres, simplement parce qu'il faut plus de temps pour que les projets de logiciels libres souffrent du manque de rigueur dans leur développement.

Ce chapitre décrit le génie logiciel de façon superficielle afin de le présenter au développeur de logiciel libre, et de susciter son intérêt. Le futur, ne l'oublions pas, est toujours constitué du meilleur du passé et du présent. Le génie logiciel n'est pas une sorte de règle à calcul ou de calculatrice de poche mais un mode de réalisation de systèmes de haute qualité, riche de techniques nombreuses et éprouvées, particulièrement efficace dans le cas de projets non réalisables dans le cadre de l'approche par un « unique programmeur de génie » commune à de nombreux développements de logiciels libres.


< Chapitre 5 Sommaire Chapitre 7 >