Le génie logiciel

Le génie logiciel
Cinquième édition d’un ouvrage de Jacques Printz
Martine Otter, Présidente d’ADELI
La collection Que sais-je ? renferme des trésors. Parmi ceux-ci, je ne saurais trop
vous recommander le numéro 2956, « Génie Logiciel » dont une 5ème édition est
parue en avril 2005, soit dix ans après la première édition de 1995. Pour 8 euros,
prix éditeur, vous disposerez d’une synthèse exceptionnelle sur le processus de
développement du logiciel.
Une vision à la fois simple et complexe
L’avant-propos à lui seul justifie les huit euros que
vous aurez déboursés, pour cette recommandation
que je me permets de qualifier d’adélienne : « se
défier des modes qui ne font souvent que passer, et
du jargon qui cache souvent une vacuité de la
pensée ». On ne saurait mieux dire !
Les caractéristiques du logiciel
Avant de rentrer dans le vif du sujet du « génie logiciel », Jacques Printz prend la peine de se pencher
sur le logiciel dans deux chapitres introductifs :
Le premier chapitre, « Données économiques »,
nous explique que le logiciel coûte cher, que sa
production devrait s’industrialiser de plus en plus, et
que par ailleurs l’omniprésence du logiciel dans
notre monde moderne constitue un facteur de
risque énorme qui justifie le renforcement des
opérations de contrôle en tout genre, validations et
vérifications. La complexité croissante des logiciels
entraîne une augmentation de la proportion à
consacrer aux tests et validations.
Le deuxième chapitre « Typologie des logiciels »
présente une classification en trois types, issue des
travaux de Meir Lehman, pour lesquels l’auteur
nous donne des définitions et des exemples. Pour
bien comprendre ces définitions, j’ai dû chercher
des informations complémentaires sur le Net, ce qui
m’a permis de découvrir les travaux de Lehman
ainsi que les « lois de Lehman » souvent citées
dans les travaux d’autres auteurs sur la complexité
du logiciel. J’ai mieux compris la typologie
présentée en découvrant à la signification des 3
lettres :
- S comme Specified,
- P comme Problem-solving,
- et E comme Embedded ou Evolving.
28
Les logiciels complètement spécifiés (S_Type)
correspondent à la programmation d’algorithmes
mathématiques et sont d’une parfaite stabilité, une
fois mis au point. Les logiciels de résolution de
problème (P_Type) traitent généralement des masses de données importantes pour des types d’application comme la prévision météorologique ou la
traduction automatique. Ils évoluent par nécessité
d’optimisation. Le troisième type, celui des logiciels
en interaction avec le monde réel (E-type), est celui
des systèmes d’information.
Un second critère de classement des logiciels est
celui du mode de distribution : progiciel ou « clés en
main ». Notons ici que l’expression « clés en main »
est employé par Jacques Printz pour logiciel spécifique, alors que dans l’esprit de beaucoup d’informaticiens le « clés en main » c’est justement le progiciel,
puisque, comme pour une voiture dont on vous
donne les clés, vous n’êtes plus censé la bricoler.
Le génie logiciel, c’est quoi ?
Jacques Printz définit le génie logiciel comme :
« l’ensemble des moyens techniques, industriels et
humains qu’il faut réunir pour spécifier, construire,
distribuer et maintenir des logiciels qui soient sûrs,
…conviviaux, …évolutifs, …économiques… ». Les
critères cités de « sûreté », « convivialité », « évolutivité » et « maîtrise des coûts » sont hautement
recommandés, mais nous aurions sans doute préféré
que la liste des caractéristiques attendues du logiciel
soit plus ouverte et que l’on se préoccupe de
construire des logiciels qui répondent aux besoins,
exprimés ou implicites de leurs utilisateurs.
Nous le savons, les logiciels contiennent de nombreuses erreurs et leur évolution est difficile. Le
métier de développeur suppose des qualités intellectuelles et humaines assez considérables.
La Lettre d’ADELI n° 61 – Automne 2005
Le génie logiciel est censé apporter des réponses à
ces difficultés.
À partir de cette définition du génie logiciel, l’auteur
développe un ensemble de thèmes décrivant les
pratiques en usage.
Modèle de développement et cycle de vie
Ce chapitre aborde le processus de développement
dont il présente le vocabulaire classique et les
concepts essentiels :
notion de cycle de vie,
principe du cycle en V,
notions de maquette et de prototype,
fonctionnement de la maintenance ;
rétro-ingénierie ;
processus d’intégration ;
outils et ateliers de génie logiciel.
L’auteur insiste très justement sur la nécessité de
différencier les pratiques suivant le type et la taille du
logiciel.
Cinétique, dynamique et régulation du cycle de
développement
Ce chapitre, plus original que le précédent, pose la
question du fractionnement des tâches : « jusqu’où
peut-on fractionner une phase ? » et celle du parallélisme : peut-on démarrer une phase alors que la
précédente n’est pas encore terminée ? Nous savons
bien qu’un certain niveau de parallélisme est
indispensable, afin de ne pas laisser les équipes en
attente d’une validation qui tarde un peu. Nous
connaissons également le risque de retour sur
travaux terminés que ce parallélisme représente. Le
mérite de Jacques Printz est de proposer ici la
théorisation mathématique de ces phénomènes de
fractionnement et de parallélisme.
l’auteur n’ose pas donner d’avis critique sur ce
modèle dont il est beaucoup question, faute de
mieux, dans les ouvrages et synthèses diverses sur
le sujet, mais qui n’est pas plus fiable qu’un « avis
d’expert ». L’organisation des équipes projet est
traitée rapidement, sans information précise sur le
rôle de chacun des acteurs. Nous en retiendrons
simplement qu’il est très compliqué de mettre en
place une organisation adaptée…
Conclusion
L’ouvrage se termine par un bref chapitre sur l’avenir
du génie logiciel, qui conclut à la nécessité d’une plus
grande maîtrise des systèmes d’information, grâce à
des méthodes et outils vraiment efficaces. À la
question : « Que sais-je ? », nous répondrons que
sur un sujet tel que le génie logiciel, nous ne savons
que peu de choses. L’observation des pratiques
passées nous laisse supposer que nous avons
encore beaucoup de progrès à faire.
Nous avons peu de critiques à faire à cet ouvrage,
mis à part le fait que le nombre réduit de pages a
entraîné des choix et quelques impasses. Il en
résulte, par exemple, une place on ne peut plus
modeste accordée à la gestion de configuration, citée
uniquement au titre des outils et pas à celui des
bonnes pratiques méthodologiques. De même, la
qualité n’a été abordée que sous l’angle processus et
pas sous celui de la qualité du produit.
Vous laisser sur votre faim et vous donner envie
d’approfondir des sujets que vous croyiez connaître
et dont certains vous tiennent pour expert, on ne peut
espérer meilleur résultat ! ▲
[email protected]
Le thèmes de l’expression des besoins est rapidement traité. Celui de la conception et de l’architecture
est traité en profondeur et l’on devine sans peine que
le sujet de la « modélisation » est le thème de prédilection de l’auteur : les quelques pages traitant de ce
sujet méritent à elles seules l’investissement d’achat
de l’ouvrage.
Programmation et Tests
La description de ces activités ravira sans doute ceux
dont elles constituent le métier, car elle explique en
détail ce dont il s’agit, en insistant sur la complexité
de ce travail dont certains s’imaginent à tort qu’il est
à la portée de tout un chacun sans trop d’apprentissage préalable.
Management de projets logiciels
La présentation des méthodes d’estimation de charge passe par celle de Cocomo. Regrettons juste que
La Lettre d’ADELI n° 61 – Automne 2005
29