Tribune Libre
Ténors de l'Informatique Libre
Copyright © 1999 par Éditions O'Reilly
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.
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 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.
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).
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.
|