|
MODULE No 03 |
|
Titre : Brève histoire du GL |
|
But : Voir, en suivant les changements dans le GL, l’évolution (si évolution existe) des problèmes de l’« automatisation » à l’aide du logiciel. |
|
Antécédents : Module 1. |
|
Corps : 1 Années cinquante
Dans les années cinquante,
l’excitation pour la nouveauté et la flexibilité qui permet de faire faire
n’importe quoi — ou presque — à un
ordinateur, donne aux mathématiciens et aux ingénieurs l’illusion que
l’automatisation du monde sera un jeu d’enfant. Mais mathématiciens et
ingénieurs sont très mal placés pour comprendre les problèmes qu’engendrera
cette machine qui semble se contenter d’ingurgiter des 0 et des 1. Ils sont
mal placés parce que les mathématiciens se sentent très peu concernés par les
applications pratiques et les ingénieurs sont intéressés surtout par le
fonctionnement de C’est dans les années cinquante que naissent les
premières langues de programmation de haut niveau : plus ou moins
orientées vers les sciences et la technique (Fortran) ou les affaires
(Cobol) : elles auraient dû augmenter énormément Quelque chose de pourri commence à poindre au
royaume de l’ordinateur. 2 Années soixante
Dans les années soixante, le plus grand
consommateur de logiciel (le ministère de la guerre américain, DoD) décide
qu’il faut aborder plus systématiquement la production du logiciel employé
dans ses machines. Il faut être systématique dans la production pour obtenir
un produit de qualité à des coûts raisonnables, il faut du… génie. Le génie
logiciel naît parce qu’on a besoin d’une certaine assurance que, quand on
achète un produit – si on a la
chance de le recevoir ! –, il
s’agit d’un produit de qualité qui exécute les fonctions demandées comme dans
l’ingénierie « normale ». Le génie logiciel naît donc comme un
mécanisme pour rassurer les acheteurs. Ce qui n’est pas un mal en soi mais cela
a eu, parfois, des effets pervers dus à un excès de bureaucratisation dans la
production : c’est-à-dire que certains producteurs se sont mis à générer
des quantités effarantes de papier pour justifier une qualité qui, parfois,
n’en était pas une, sauf sur papier20.
Entre « pas de papier » et « trop de papier », il n’était
pas facile de choisir surtout que les raisons justifiant ou non l’usage du
papier étaient elles aussi sur papier ! Dès qu’il naît, étant donnés les enjeux
économiques pour les producteurs, le génie logiciel occupe, de la manière la
plus naturelle, tout l’espace qu’il trouve devant lui. Veut-on un programme
pour contrôler un radar ? Il faut définir ce dont on a besoin, il faut
que les développeurs comprennent ce que le client veut, il faut définir une
structure de manière à ce que le logiciel se tienne, il faut bien sûr écrire
le code, etc. Ce qu’on appellera le cycle
de vie classique du logiciel est né. Y a-t-il d’autres
possibilités ? Pratiquement pas. On construit un logiciel par analogie
avec la construction d’une maison, d’un avion, d’une voiture, selon les
approches des industries qui ont au moins quelques dizaines d’années
d’avance. On considère le logiciel comme n’importe quel
produit doté d’un cycle de vie allant de l’idée initiale au retrait. Le cycle
est divisé en phases pour mieux contrôler la progression des travaux et les
phases sont définies avec beaucoup de bon sens en s’inspirant des autres
branches du génie : 1- Analyse : compréhension et description du
problème. 2- Conception : création d’une structure pour le
logiciel. 3- Codage : écriture du code. 4- Test : vérification des résultats par
rapport aux attentes. 5- Maintenance : modifications du logiciel pour
l’adapter aux changements. On représente souvent le cycle de vie classique comme dans la figure
suivante :
C’est une représentation très schématique qui présuppose qu’avant de
commencer une étape il faut avoir complètement terminé Une première modification pour rendre l’approche plus réaliste consiste à
introduire une rétroaction entre les phases.
Parmi ces rétroactions, celle entre Test et Codage est la plus
« naturelle » : si en faisant des test on trouve des erreurs
(ce qui est fort normal dans toute application le moindrement complexe) il
faut corriger le code. Mais seulement le code ? Et si l’erreur est au
niveau de la conception ? Et s’il est au niveau de l’analyse ? Dans
une approche d’ingénierie il faut modifier la conception et l’analyse. Dans
ce que l’on appelle, faute de meilleur terme (et pour justifier son
incapacité à maîtrise les processus), « la vraie vie » souvent on
ne modifie que le code, ce qui empêche, par la suite, de faire la maintenance
à des coûts acceptables ! « L’invention » de ce domaine et sa
division représentent ce qu’il y a de plus normal pour un acheteur de
logiciel. Et semble constituer la solution idéale du point de vue économique
pour le producteur aussi. Dans les prochains cours on verra des approches
plus « agiles ». 3 Années soixante-dix
Les années soixante-dix sont les « grandes
années » de la programmation structurée qui a ses fondations théoriques
dans le théorème de Jacopini, théorème qui établit qu’il suffit de trois
types d’énoncés (séquence, sélection, itération) pour construire n’importe quel programme. C’est à
partir de là que prend origine la célèbre « querelle » entre
Dijkstra et Knuth à propos des GOTO : querelle qui oppose deux approches
qu’on pourrait taxer de « purisme » (Dijkstra) et de
« lisibilisme » (Knuth). Une trentaine d’années après cette
controverse et après tant d’articles pour ou contre les formalismes, pour ou
contre la « pureté », on peut retenir ce qui est commun aux deux
approches : un grand souci de « maintenabilité » (facilité de
maintenance), qui était formulée surtout en termes de lisibilité et facilité
de modification. Mais, la maintenabilité –
puisqu’on peut faire faire n’importe quoi au logiciel et puisqu’il semble ne pas
pouvoir vieillir[1] – n’est-ce pas la qualité la plus importante si on veut
systématiser les interventions sur les produits ? Au fond, Dijkstra et
Knuth, ces deux « théoriciens » de l’informatique, étaient en train
de montrer qu’il fallait transformer l’informatique en génie. Quel
génie ? C’est ça qui est difficile à définir. En partant de ces éléments
historiques, on peut dire que : La
maintenabilité est l’exigence de qualité principale pour toute approche
d’ingénierie au développement du logiciel. Il faut souligner que, dans les autres branches
du génie, la maintenabilité est moins importante, car ces dernières ne sont
concernées pratiquement que par la maintenance corrective. Dans le génie logiciel, la maintenance corrective,
dans des produits avec un degré acceptable de qualité, est souvent bien moins
importante (du point de vue des coûts) que la maintenance perfective ou adaptative. Élargir ainsi la maintenance rend réaliste le fait de
considérer même le premier développement comme une maintenance caractérisée
par moins de contraintes fixées par des développements antérieurs. Tout est maintenance ? Sans doute. Dans les années soixante-dix, les interactions
entre l’informatique et le génie logiciel sont très intenses et leurs
frontières sont floues et mouvantes, surtout parce qu’on est en train de
fixer leurs frontières à une époque où la « technique liée aux
ordinateurs » est encore dans les langes. Et, comme dans toute fixation
de frontières, c’est rarement la raison qui l’emporte ! 4 Années quatre-vingt
Avec la programmation structurée, on a commencé
à aborder la programmation comme une activité qui n’est pas la simple
écriture d’une suite d’instructions : on demande au programmeur de
penser une structure, de… concevoir. Mais on s’aperçoit que le passage de la
programmation « anarchique » à la programmation structurée cache un
très grave danger pour des systèmes un tant soit peu complexes : le
danger de se faire « guider » par l’algorithme (la façon de faire) et
de favoriser ainsi la création de modules qui contiennent des éléments pas
assez fortement liés entre eux. On dit que leur « cohésion » est
faible. Mais une cohésion faible implique des difficultés d’entretien, ce qui
est catastrophique si la maintenabilité est si importante. On met
alors au centre les données et non plus l’algorithme : pour ce faire on
introduit lr flux (le mouvement) des données dans l’analyse. La chanson
« les données sont plus stables que les fonctions » a un succès
énorme et mérité. Le passage des « données » aux
« concepts » est presque automatique surtout que, dans la
programmation, on a introduit des langages qui traitent des
« objets » en tant qu’instances d’un concept (ou classe). Il y a de
quoi se réjouir : on a trouvé comment décrire le problème et la solution
avec le même langage. En ayant des objets pour l’analyste (dans le domaine),
des objets pour le concepteur et des objets pour le programmeur (dans le
système), il est imaginable qu’au moins la tâche de communication entre les
différents intervenants soit simplifiée et puisqu’un des problèmes centraux
que le génie logiciel a détecté est la difficulté
de communication entre les personnes, il est normal de penser qu’on est
proche de la solution idéale. À un certain moment, tout doit donc être
« objet » (comme, dans les années soixante-dix, tout était
modulaire) et l’héritage devient la clef pour augmenter la productivité, la
fiabilité, pour faciliter les tests, etc. Mais on ne tarde pas à s’apercevoir
que ce n’est pas parce qu’on parle d’objets du début à la fin du cycle qu’on
règle les problèmes. Souvent les problèmes empirent, car les
« objets » de l’analyse rendent le système excessivement lourd et
coûteux. On s’aperçoit que la difficulté principale, après l’analyse, est de
savoir comment choisir les objets et quelles transformations opérer lors de
la conception et de la programmation : les objets du domaine et ceux de
la solution ne doivent pas être nécessairement les mêmes. Ce constat, d’une
part, montre pour une énième fois qu’il n’y pas de solutions miracle et, de l’autre, que même si l’on emploie la
même langue dans l’analyse et dans la conception, les « objets » de
la conception sont « déformés » pour les adapter à la technologie
informatique. Ce que nous venons de dire ne devrait pas être
considéré comme une prise de position contre l’approche objet mais comme une
simple réflexion sur le fait que la complexité de l’informatisation ne peut
être réduite au-delà d’un certain seuil, quoiqu’on fasse. Ni les approches,
ni les paradigmes, ni les processus ne peuvent rendre la tâche de décrire un
domaine « banal » quand on veut aller au-delà de ce qui est déjà
informatisé (ou mécanisé). Voici un mauvais mythe que l’approche objet a
aidé à solidifier : l’analyse est
un processus qui permet de passer des objets réels du monde aux objets du
modèle informatique. Cette affirmation est fausse, car elle ne tient pas
compte du fait que le « monde » est, pour les humains, déjà
« modélisé » par le langage. Par le langage qui est notre plus
grande richesse sans laquelle aucune informatisation n’est possible, mais
qui, en même temps, est notre plus grande source d’« erreurs », car
non seulement le nombre de modèles langagiers pour un monde donné est infini
mais il est aussi clairement impossible de trouver un algorithme pour choisir
le meilleur modèle. Note Il est
clair que les capacités des individus sont si variées que, surtout dans le
cas de systèmes complexes, en changeant une personne, on peut facilement
passer d’une situation de « infaisable à des coûts finis » à
« faisable à des coûts raisonnables » Fin de la note. 5 Années quatre-vingt-dix
Si les années soixante et les années
soixante-dix ont été des années importantes pour la réflexion sur le génie
logiciel d’un point de vue mathématique, les années quatre-vingt-dix sont
caractérisées par une réflexion plus pratique. Il est pratiquement impossible
de donner une description linéaire de l’évolution du génie logiciel pendant
cette période. Nous préférons présenter une liste de mots clefs et de lieux
communs qui nous semblent très importants même si parfois ils sont un simple
support à une pensée magique. Thèmes 1- Les processus (définis comme ensemble
structuré d’activités) ont une importance centrale et l’amélioration de la
qualité passe surtout par leur définition et par leur amélioration. 2- Les phases « classiques » du cycle
de vie (analyse, conception, codage et test) restent les phases centrales du
processus de développement même si elles se situent dans une spirale plutôt
qu’en cascade. 3- Les activités concernant les
exigences et les interfaces personne-machine ont droit au statut spécial de
« génie » dans le génie logiciel (ingénierie des exigences et de la
facilité d’utilisation). Les domaines d’application sont absorbés de manière
plus ou moins explicite dans l’ingénierie des exigences tandis que le cycle
de vie de la facilité d’utilisation est introduit pour systématiser les
interactions entre le développeur et les clients/utilisateurs. 4- La sûreté de fonctionnement regroupe
des éléments de qualité auparavant séparés (comme sécurité et disponibilité,
par exemple). 5- Les exigences non fonctionnelles (ou
de qualité) sont toujours plus au centre du développement, ce qui a comme
corollaire la mise en valeur des développements fondés sur l’architecture. 6- L’importance accrue de la
maintenabilité rend nécessaires des environnements avec possibilité de
« traçage ». Éléments technologiques 1- Patrons de conception et cadres
deviennent deux piliers de la conception. 2- La réutilisation force à repenser la
programmation comme composition. 3- L’accès aux données à distance via Internet a
des impacts énormes sur l’architecture. 4- La réingénierie devient toujours plus
répandue. 56- La compatibilité au niveau du
« binaire » devient toujours plus importante (DCOM et CORBA). 6 Aujourd’hui
On approfondit et on améliore les méthodes et les pratiques des années
1990. On introduit (ou on rend plus populaire) de approches, des techniques…
7 Aujourd’hui (SWEBOK)
Sur internet à
l’adresse suivante : http://www,swebok.org/
est disponible SWEBOK : « un guide pour le corpus de connaissances
qui existe dans la littérature et qui s’est formé dans les derniers trente
ans ». Son but est de « fournir une caractérisation validée par
consensus des limites de la discipline de l’ingénierie du logiciel ». Les disciplines qui entourent le génie logiciel et qui, de façon plus ou
moins approfondie, doivent faire partie des connaissances de l’ingénieur du
logiciel sont : 1- l’informatique (computer science) ; 2- les mathématiques ; 3- la gestion de projet ; 4- l’ingénierie des ordinateurs ; 5- l’ingénierie de systèmes ; 6- les sciences de la gestion ; 7- les sciences cognitives et les facteurs humains. Dans la figure suivante, nous représentons le contexte de manière
graphique.
Puisque, dans SWEBOK, les
domaines d’application ne sont pas considérés explicitement, nous les
considérons comme l’arrière-plan de base. Nous mettons les mathématiques
comme deuxième arrière-plan pour indiquer que seulement dans le cas où les
domaines sont mathématisés (dotés de règles plus ou moins formelles), on peut
y appliquer les techniques du génie logiciel avec l’aide des disciplines
connexes. Voici la liste des secteurs tels que définis dans la version 1.0 de
SWEBOK avec des questions auxquelles les activités du secteur devraient
répondre : 1- Exigences : quels sont les concepts du
domaine et les fonctions à automatiser ? 2- Conception : comment créer une
structure qui permet de rendre le code plus solide et résistant aux
changements ? 3- Construction : Comment organiser
le code et le livrer avec une bonne qualité ? 4- Test : Comment s’assurer que le
programme fait ce qu’il est censé faire ? 5- Maintenance : Quelles sont les
activités nécessaires pour faire évoluer le logiciel ? 6- Gestion de la configuration :
Comment identifier les artefacts de manière telle que l’on puisse facilement
les trouver et les intégrer ? 7- Gestion : Comment structurer les
équipes et comment faire travailler les personnes ensemble ? 8- Méthodes et outils du génie logiciel :
Quelles sont les règles qu’il faut respecter et quels outils employer ? 9- Processus du génie logiciel :
Comment définir les processus et les activités pour améliorer la productivité
et la qualité ? 10- Qualité : qu’est-ce que fait
qu’un logiciel est meilleur qu’un autre tout en ayant les mêmes
fonctions ? |
|
Conséquents :
· Être conscients que le GL tel qu’il est aujourd’hui est le fruit d’une évolution rapide pilotée par des exigences de maintenabilité |
|
Note
01 : ·
Maintenance corrective : Il s’agit de
l’ensemble des activités nécessaires pour corriger les erreurs dans le
logiciel (souvent, mais pas seulement, les erreurs de codage). ·
Maintenance perfective : Il s’agit de
l’ensemble des activités nécessaires pour améliorer les fonctionnalités et la
qualité du logiciel. ·
Maintenance adaptative : Il s’agit de
l’ensemble des activités nécessaires pour adapter le logiciel à un nouvel
environnement. |
