Élagage du génie logiciel

Pour en finir…

Élagage du génie logicielpar Ivan Maffezzini, Alice Premiana et Bernardo Ventimiglia

de l’institut Trempet de l’UQAM

Avec le temps, le plaisir d’avoir raison tout seul devient moisi.Dijkstra E. W., On the Role of Scientific Thought

1 Introduction1

Dans cet article, ambitieux et sans fausses humilités, nous nousefforcerons de montrer que les tentatives de donner desfondements solides à ce qu’actuellement on appelle génie logiciel (GL)sont vouées à la faillite si le domaine n’est pas élagué. Nouspensons qu’il est essentiel de lui enlever un certain nombre departies, celles qu’il a englobées à cause des vicissitudeshistoriques de l’informatique et qui appartiennent au génie commeles chats aux canidés. Cet élagage permettra, à notre avis, deconserver tout ce qui est effectivement abordable avec lesméthodes du génie.

Nous n’avons pas la naïveté de croire que l’on puisse démontrerquoi que ce soit à ce propos mais nous avons la prétention demontrer que c’est seulement si le GL renonce à beaucoup de sessous-domaines qu’on pourra établir des méthodes, des mesures etdes conceptualisations dignes, sinon d’une science, au moinsd’une technique. On pourrait bien sûr nous répliquer que ce n’estpas parce qu’on décide, d’un manière très volontariste, quecertains processus ne font plus partie du génie logiciel ou dechanger le nom d’un ensemble d’activités que cela amélioreraglobalement l’informatisation. Cette critique sous-évalue1 Le style de notre article ne sera pas nécessairement lourd, ce qui n’impliquepas manque de rigueur. Le choix du style a été fait d’une part en oppositionau fait que trop souvent un article mal écrit et ennuyeux acquiert une aura deprofondeur et de l’autre parce que nous croyons que le style est fondamentaldans le génie logiciel et, en particulier, en programmation. À propos dustyle, entre autres, nous devons remercier Dijkstra : il a ouvert àl’informatique une approche riche et solide (malheureusement ce qu’on appelleGL ne l’a pratiquement pas exploité).22-10-25 Fondements 1

Pour en finir…

l’importance des noms et semble ignorer que le changement decontenant donne souvent une nouvelle saveur au contenu.

Une critique, psychologiquement bien plus forte, pourraits’énoncer ainsi : « Comment pouvez-vous penser que votre approcheest la meilleure quand 99,99 % des gens qui travaillent ou fontde la recherche en informatique pensent d’une autre manière ? » Àcela on peut répondre facilement : « La démocratie fonctionne,peut-être, en politique mais certainement pas dans la science etdans la technique, donc, si le génie logiciel se situe quelquepart du côté de la technique, le nombre d’individus qui pensentd’une certaine manière n’est pas nécessairement un élément quirend une position plus digne de confiance2. » Telle ne sera pasnotre réponse, mais nous ajouterons que des signes d’une nouvellemanière de penser commencent à surgir (nous pensons surtout auxtravaux de M. Jackson) mais, surtout, nous croyons que lestravaux de [SW07] et de [SEI1], en nous présentant de manièretrès approfondie l’état du domaine, nous permettent de démarrerune réflexion sur des bases très solides (solides dans le sensqu’elles sont acceptées par la majorité mais pas nécessairementsolides en soi, comme nous essayerons de le montrer).

Avant d’entrer dans le cœur du sujet nous présentons deuxprincipes qui sont à la base de nos considérations et que nousappellerons les principes fondamentaux de l’automatisation3. Cesprrincipes découlent de la définition de domaine comme un point devue partiel sur le monde :

Tout domaine contient au moins une partie qui est automatisable. (P01).

Et

Un domaine est complètement automatisable si et seulement si ses« frontières » sont formalisables. (P02).

2 Nous croyons qu’en situation de crise (et les tenants du génie logiciel nousparlent de crise depuis trente ans) c’est exactement l’inverse qui est vrai !3 Nous employons « automatisation » dans l’acception la plus large de « Emploi de machines pour exécuter des activité dans des processus de transformation quelconque du monde.22-10-25 Fondements 2

Pour en finir…

Ces deux principes ont des grandes conséquences dans la façon devoir, de décrire et éventuellement de contrôler l’évolution del’informatisation, car en disant que « Tout domaine… » (P01) onouvre la porte à l’informatisation de n’importe quelle partie dela réalité mais en ajoutant que l’automatisation peut êtrecomplète seulement si « ses frontières sont formalisables »(P02)» on souligne le fait que seulement si la réalité du domaineà été réduite à des expressions formelles on peut toutinformatiser. Le deuxième principe ets un garde-fou pour lesexperts du domaine qui pourraient nourrir de trop grands espoirspar rapport à l’informatisation. Les ingénieurs du logiciel ontdonc, parmi bien d’autres, aussi la tâche de rendre « réalistes »les attentes des gens qui ne maîtrisent pas la techniqueinformatique — ce qui est bien normal, même si actuellement c’estsouvent le contraire qui arrive ! Nous proposons un corollaire auprincipe P02 pour souligner qu’en théorie, quand on formalise leslimites d’un domaine ou d’une de ses parties, on peut automatisermême la production de programmes :

Les programmes pour un domaine complètement automatisable peuvent êtregénérés automatiquement (C-P02)

Avant de terminer cette introduction, une brève note à propos desréférences. Il est clair qu’un texte qui se veut une réflexion enprofondeur sur le génie logiciel doit tout à tous ceux qui ontécrit ou produit dans le domaine et qu’on a plus ou moinsvirtuellement côtoyé. Pour ne pas alourdir le textes avec unnombre trop élevé de références et de citations, nous assumonspersonnellement tout ce que nous affirmons et nous ne citeronsque les normes qui sont à la base de l’article et quelques livrespour des éléments très ponctuels. Dans la bibliographie, parcontre, nous présentons les livres qui nous semblentsignificatifs par rapport à notre propos : que ce soit pour (trèsrares) ou contre (très nombreux).

22-10-25 Fondements 3

Pour en finir…

2 Génie logiciel : une synthèse

3 Aperçu historiqueCe bref aperçu historique nous permet d’introduire trois autresprincipes avant de faire une présentation concise du GL tel queperçu par les théoriciens et les praticiens aujourd’hui.

4 Années cinquanteDans les années cinquante, l’excitation pour la nouveauté et laflexibilité qui permet de faire faire n’importe quoi, ou presque,à un ordinateur donne aux mathématiciens et aux ingénieursl’illusion que l’informatisation du monde sera un jeu d’enfant.Mais, mathématiciens et informaticiens sont très mal placés pourcomprendre les problèmes qu’engendrera cette machine qui semblese contenter d’ingurgiter des 0 et des 1. Ils sont mal placésparce que les mathématiciens ne sont pas fort concernés par lesapplications pratiques et les ingénieurs sont intéressés surtoutpar le fonctionnement de la machine. Ils sont surtout mal placésparce qu’en étant dedans ils ne voient pas la forêt. Par contre,les militaires, les banques et les gouvernements voient très bienla forêt et comprennent assez vite les potentialités de lanouvelle machine. Ils s’engagent donc, eux aussi, avec grandenthousiasme. Mais, hélas, pour le logiciel, la réalité est plusdure que prévu. Dès qu’on veut bâtir des produits pour des usagesautres que la recherche en laboratoire, les douleurs commencent :fonctions mal exécutées, coûts excessifs, retards, faibledisponibilité, etc., toutes les maladies qu’on n’a pas encoreréussi à éliminer, qu’on n’éliminera jamais totalement et,surtout, que les approches actuelles risquent d’aggraver.

5 Années soixanteDans les années soixante, le plus grand consommateur de logiciel(le ministère de la guerre américain DoD) décide qu’il fautaborder plus systématiquement la production du logiciel employédans ses machines. Il faut être systématique dans la productionpour obtenir un produit de qualité à des coûts raisonnables, il22-10-25 Fondements 4

Pour en finir…

faut du… génie. Le GL naît parce qu’on a besoin d’une certaineassurance que, quand on achète un produit, — si on a la chance dele recevoir ! —, c’est un produit de qualité qui exécute lesfonctions demandées comme dans l’ingénierie « normale ». Le GLnaît donc comme un mécanisme pour rassurer les acheteurs. Ce quin’est pas un mal en soi mais a eu parfois des effets pervers dusà un excès de bureaucratisation dans la production : c’est-à-direque certians producteurs se sont mis à générer des quantitéseffarantes de papier pour justifier une qualité qui, parfois,n’en était pas une, sauf sur papier4. Entre « pas de papier » et« trop de papier », il n’était pas facile de choisir surtout queles raisons justifiant ou non l’usage du papier étaient ellesaussi sur papier !

Dès qu’il naît, étant donnés les enjeux économiques pour lesproducteurs, le génie logiciel occupe, de la manière la plusnaturelle, tout l’espace qu’il trouve devant lui. Veut-on unprogramme pour contrôler un radar ? Il faut définir ce dont on abesoin, il faut que les développeurs comprennent ce que le clientveut, il faut définir une structure de manière à ce que lelogiciel se tienne, il faut bien sûr écrire le code, etc. Cequ’on appellera le cycle de vie classique du logiciel est né. Ya-t-il d’autres possibilités ? Pratiquement pas. On construit unlogiciel par analogie avec la construction d’une maison, d’unavion, d’une voiture, selon les approches des industries qui ontau moins quelques dizaines d’années d’avance.

On considère le logiciel comme n’importe quel produit qui estdoté d’un cycle de vie allant de l’idée initiale au retrait. Lecycle estdivisé en phases pour mieux contrôler la progression destravaux et les phases sont définies avec beaucoup de bon sens ens’inspirant des autres génies :

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.

4 Le logiciel aussi peut être « sur papier ».22-10-25 Fondements 5

Pour en finir…

5. Maintenance : modifications du logiciel pour l’adapter aux changements.

« L’invention » de ce domaine et sa division représentent cequ’il y a de plus normal pour un acheteur de logiciel. Et sembleconstituer la solution idéale du point de vue économique pour leproducteur aussi. Mais, selon nous, cette origine, pilotée parles acheteurs et fondée sur l’analogie avec les autres génies,est une des causes des difficultés du GL. Sans doute même laprincipale. À ce propos nous énonçons le troisième principe :

Le génie logiciel ne peut pas être considéré un génie comme les autres enraison du nombre pratiquement infini de domaines pour lesquels on peutproduire des logiciels et de l’extrême facilité à générer des copies desexécutables (P03)5.

Ce principe découle de P01 et a comme corollaire :

Toute analogie fondée sur les génies traditionnels crée des modèleserronés et de faux espoirs (C-P03).

D’autres auteurs commencent à souligner la différence radicaleentre génie logiciel et les autres génies. Dans la tentative deles différencier il y a même ceux qui arrivent à proférer desconsidérations à notre avis inacceptables comme la suivante quenous commentons en détail dans l’annexe G : « Dans le GLl’approche est inversée [par rapport au génie traditionnel]. Onva du concret vers l’abstrait. Le produit logiciel final est lavirtualisation (le code) et la transposition invisible d’uneconception originelle qui exprime un problème du monde réel6. »

5 Il ne faut pas confondre ce principe avec un lieu commun dangereux quiaffirme que la spécificité du logiciel c’est qu’il est « immatériel » !Contrairement à ce qui se passe dans le génie mécanique ou civil, par exemple,le processus de production de copies des exécutables et de la documentationest simple et complètement automatisable (produire des « copies » de voituresou de maisons n’est pas complètement automatisable).6 Wang Y., King G, Software Engineering Processes, CRC, 2000.22-10-25 Fondements 6

Pour en finir…

6 Années soixante-dixLes années soixante-dix sont les « grandes années » de laprogrammation structurée qui a ses fondations théoriques dans lethéorème de Jacopini, théorème qui établit qu’il suffit de troistypes d’énoncés (séquence, sélection, itération) pour construiren’importe quel programme. C’est à partir de là que prend originela célèbre « querelle » entre Dijkstra et Knuth à propos desGOTO : querelle qui oppose deux approches qu’on pourrait taxer de« purisme » (Dijkstra) et de « lisibilisme » (Knuth). Unetrentaine d’années après cette controverse et après tantd’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é »7 (facilité de maintenance).Mais, la maintenabilité — puisqu’on peut faire faire n’importequoi au logiciel et puisqu’il ne peut pas vieillir8 — n’est-ce pasla qualité la plus importante si on veut systématiser lesinterventions sur les produits ? Au fond Dijkstra et Knuth, cesdeux « théoriciens » de l’informatique, étaient en train demontrer qu’il fallait transformer l’informatique en génie. Quelgénie ? C’est ça qui est difficile à définir9.

En partant de ces éléments historiques, on peut donc énoncer unquatrième principe :

La maintenabilité est la qualité intrinsèque principale pour touteapproche d’ingénierie au développement du logiciel. (P04)

qui a comme corollaire :

7 Même s’il était formulé surtout en terme de lisibilité et facilité demodification.8 Vieillissement ni en terme de fonctionnalités ni par rapport à l’évolutiondes logiciels de base, bien sûr. Mais c’est sans doute aussi à cause du faitque le logiciel, à la différence du matériel, ne vieillit pas qu’on le faitvieillir artificiellement en sortant de nouvelles versions à tout bout dechamps pour renfluer les caisses des sociétés informatiques.9 Vue la grande difficulté de la définition, on pourrait penser, comme certainsle font, qu’il est préférable d’abandonner la métaphore du génie. Nous croyonsque ce n’est jamais une bonne idée que de jeter le bébé avec l’eau sale !22-10-25 Fondements 7

Pour en finir…

Là où la maintenabilité n’est pas importante, on a affaire à de larecherche ou du prototypage10.(C-P04)

Le principe P04, au lieu que le dériver de considérationshistorique peut être déduit d’une des caractéristiquesprincipales du logiciel :

Le logiciel à cause de la facilité relative de modification peut êtreadapté à des situations très différentes

Cette affirmation ne doit pas être considéré équivalente àl’affirmation que l’ordinateur est une machine universelle, caron pourrait imaginer une machine universelle dont les« programmes » sont difficilement modifiables11.

Il faut souligner que dans les autres génies la maintenabilitéest moins importante car ils sont concerné pratiquement seulementavec la maintenance corrective. Dans le GL la maintenancecorrective, dans des produits avec un degré acceptable dequalité, est souvent bien moins importante (au point de vue descoûts) que celle perfective ou adaptative12. Le fait d’élargir ainsi lamaintenance rend réaliste de considérer même le premierdéveloppement comme une maintenance caractérisée par moins decontraintes fixées par des développement antérieurs13.

10 Voilà un autre des « gros » problèmes du logiciel : souvent les informaticiens sont en train de faire un prototype et ils ne le savent pas.11 Il suffit de penser à ce propos au théorème d’équivalence de Tannenbaum : « Tout ce qui est faisable par du matériel est faisable par du logiciel et vice versa ».12 On voit ici, comme dans le cas du syntagme GL, l’importance des noms. Lamaintenance a été introduite par analogie avec les autres génies commemaintenance corrective et ensuite, à cause aussi de l’organisation desdépartements d’informatique, elle s’est élargie pour englober tout genre dechangement. Le fait qu’on a continué à garder le terme maintenance, rendpratiquement inutilisable l’analogie avec les autres génie. Notre principe P04vaut bien sûr seulement dans l’acception large du mot maintenance.13 Penser en terme de réutilisation, va dans cette même direction.22-10-25 Fondements 8

Pour en finir…

Dans les années soixante-dix, les interactions entrel’informatique et le génie logiciel sont très intenses14 et leursfrontières sont floues et mouvantes, surtout parce qu’on est entrain de fixer leurs frontières à une époque où la « techniqueliée aux ordinateurs » est encore dans les langes. Et, comme danstoute fixation de frontières, c’est rarement la raison quigagne !

7 Années quatre-vingtAvec la programmation structurée, on a commencé à aborder laprogrammation comme une activité qui n’est pas la simple écritured’une suite d’instructions : on demande au programmeur de penserune structure, de… concevoir. Mais on s’aperçoit que le passagede la programmation « anarchique » à la programmation structuréecache un très grave danger pour des systèmes un tant soit peucomplexes : le danger de se faire « guider » par l’algorithme etde favoriser ainsi la création d’une cohésion de typeprocédurale15. On met alors au centre les données en introduisantleur flux dans l’analyse. La chanson « les données sont plusstables que les fonctions » a un succès phénoménal.

La passage des « données » aux « concepts » 16 est presqueautomatique surtout que, dans la programmation, on a introduitdes langages qui traitent des « objets » en tant qu’instancesd’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 objetspour le concepteur et des objets pour le programmeur (dans lesystème), il est imaginable qu’au moins la tâche de communicationentre les différents intervenants soit simplifiée et puisque un14 Il suffit de penser avec quelle verve un praticien comme Yourdon reprit la querelle des GOTO !15 Il existe aussi une « difficulté » dans la conception des algorithmes quenous ne considérons pas ici, car nous la considérons comme faisant partie del’informatique (computer science). Les querelles entre informaticiens etingénieurs du logiciel naissent souvent sur la frontière algorithmique !16 On devint souvent aristotélicien sans le savoir et on comprit l’importancede la classification pour maîtriser le monde. À ce propos, il faut citer undes livres les plus courageux de cette période : Conceptual Structures de J.F.Sowa.22-10-25 Fondements 9

Pour en finir…

des problèmes centraux que le GL a détecté est la difficulté decommunication entre les personnes, il est normal de penser qu’onest proche de la solution idéale.

À un certain moment, tout doit donc être « objet » (comme, dansles années soixante-dix, tout est modulaire) et l’héritagedevient la clef pour augmenter la productivité, la fiabilité,pour faciliter les tests, etc. On ne tarde pas à s’apercevoir quece n’est pas parce qu’on parle d’objets du début à la fin ducycle qu’on règle les problèmes. Souvent les problèmes empirentcar les « objets » de l’analyse rendent le système excessivementlourd et coûteux. On s’aperçoit que la difficulté principale,après l’analyse, est de savoir comment choisir les objets etquelles transformations opérer lors de la conception et de laprogrammation : les objets du domaine et ceux de la solution nedoivent pas être nécessairement les mêmes. Ce constat d’une partmontre pour une énième fois qu’il n’y pas de Silver bullets et del’autre que même si on emploie le même langage dans l’analyse etdans la conception, les « objets » de la conception peuvent être« déformés17 » pour les adapter à la technologie informatique.

Ce que nous venons de dire ne devrait pas être considéré commeune prise de position contre l’approche objet mais comme unesimple réflexion sur le fait que la complexité del’informatisation ne peut être réduite au delà d’un certainseuil, quoiqu’on fasse. Ni les approches, ni les paradigmes, niles processus ne peuvent rendre « banale » la tâche de décrire undomaine quand on veut aller au delà de ce qui est déjàinformatisé (ou mécanisé). Ceci nous permet d’introduire notretroisième principe :

Les coûts d’informatisation d’un problème complexe sont toujours élevés,quelle que soit la simplicité de la solution. (P05).

Comme corollaire de ce principe, nous avons que :

17 Pour anticiper sur nos considération, c’est cette capacité de« déformation » qui nous aidera à situer les ingénieurs du logiciel parrapport aux experts du domaine.22-10-25 Fondements 10

Pour en finir…

Une solution simple à un problème complexe n’implique pasnécessairement un coût global faible car la solution est souvent élaboréeà partir d’un travail énorme sur le problème. (C-P05)

Ce principe et ce corollaire considèrent des projets réalisésavec des individus ayant à peu près les mêmes capacités et lesmêmes connaissances18 dans un environnement de même niveau dematurité.

Avant de passer à la description du GL actuel, nous faisons unemise en garde contre un mauvais mythe que l’approche objet a aidéà solidifier et que nous pourrions synthétiser ainsi : l’analyse estun processus qui permet de passer des objets réels du monde aux objets du modèleinformatique. Cette affirmation est fausse car elle ne tient pascompte du fait que le « monde » est, pour les humains, déjà« modélisé » par le langage. Par le langage qui est notre plusgrande richesse et sans laquelle aucune informatisation n’estpossible19, mais qui, en même temps, est notre plus grande sourced’« erreurs » car non seulement le nombre de modèles langagierspour un monde donné sont infinis mais il est aussi clairementimpossible de trouver un algorithme pour choisir le modèle lemeilleur20.

8 Le génie logiciel aujourd’huiPour caractériser l’état actuel du GL nous avons choisi, à causede leur généralité et de leur assez grande acceptation, troisnormes (ISO12207, IEEE 12207.1, ISO 9126) parmi les dizainesexistantes et deux guides pour la définitions du corpus des

18 Il est clair que les capacités des individus sont si variées que, surtoutdans le cas de systèmes complexes, en changeant une personne ou deux, on peutfacilement passer d’une situation de « infaisable à des coûts finis » à« faisable à des coûts raisonnables ».19 Si des logiciels un jours seront capables de produire de nouvellesinformatisations ce sera parce que à l’aide du langage les humains auront bâtiun meta-programme. Les animaux, par contre, n’ayant pas de langage« logique », n’informatiseront jamais quoi que ce soit.20 De plus, très souvent « meilleur » n’a aucun sens.22-10-25 Fondements 11

Pour en finir…

connaissances, un publié par SEI (SWE-BOK) et l’autre d’IEEE etACM (SWEBOK) :

ISO 12027 : Cette norme a pour but d’« établir un cadre pourles processus du cycle de vie du logiciel avec uneterminologie bien définie à laquelle l’industrie du logicielpeut faire référence ».

IEEE 12207.1 Cette norme décrit les données du cycle de vie(CV) (la documentation et le code) dont on a besoin dans uneentreprise qui respecte la norme ISO 12207.

ISO 9126 : Cette norme « définit six caractéristiques quidécrivent, avec le minimum de recouvrement, la qualité dulogiciel ». Les six caractéristiques étant : la capacitéfonctionnelle, la fiabilité, la facilité d’utilisation, larendement, la maintenabilité et la portabilité

SWE-BOK21 : En avril 1999, SEI a publié la version 1.022 deson corpus de connaissances pour le GL. Ce rapport « est uneffort pour organiser et cataloguer un corpus deconnaissances de l’ingénierie des logiciels et pour fournirune description systématique, concise et complète de ladiscipline du GL23. »

SWEBOK24. SWEBOK est un projet du Software Engineering CoordinatingCommitee (IEEE et ACM) et est « un guide pour le corpus deconnaissances qui existe dans la littérature et qui s’estformé dans les derniers trente ans » et il a pour but de« fournir une caractérisation validée par consensus deslimites25 de la discipline de l’ingénierie du logiciel ».

21 Il est malheureux que les noms des deux documents se différencient seulementpar un « - », surtout que leur contenu est assez différent.22 Technical Report CMU/SEI -99-TR-00423 CMU/SEI -99-TR-004, p. 2.24 SWEBOK, A Stone Man Version (Version 0.7). http://www.swebok.org/index2.html25 Ou bornes. Ce que nous appelons frontières.22-10-25 Fondements 12

Pour en finir…

Les annexes B, C, D et F présentent ces cinq documents plus en détail et les accompagnent de quelques comparaisons.

9DéfinitionsConsidérons la définition de génie logiciel donnée en [IE01] :L’application d’une approche systématique, maîtrisée, quantifiable au développement, àl’exploitation et à la maintenance du logiciel : c’est-à-dire l’application de l’ingénierie aulogiciel. Dans cette définition le « c’est-à-dire » nous donneimplicitement une définition de l’ingénierie (comme une approchesystématique, fondée sur des mesures et qui permet de maîtriserles processus) et caractérise le logiciel du point de vue de cesphases (développement, exploitation et maintenance). Pour quecette définition soit d’une utilité quelconque, il faut définirle logiciel. Dans la norme que l’on vient de citer, le logicielest défini comme : les programmes, les procédures et la documentationassociée et les données qui concernent le fonctionnement d’un système informatique.Donc, si on unit les deux définitions, on obtient que le génielogiciel est l’application de l’ingénierie aux programmes, aux procédures, à ladocumentation et aux données qui permettent de réaliser un système informatique et del’entretenir tout au long de sa vie utile. Il serait très naïf de notre partde penser que l’on puisse avoir une définition qui définisseparfaitement le génie logiciel (il suffit de considérer letravail énorme de SWEBOK pour essayer de définir un guide aucorpus de connaissances) mais cette définition nous semble uneamorce suffisante.

10 ContextePuisque le GL, depuis une trentaine d’années, essaye de trouversa place dans le cadre de l’automatisationdu monde à l’aide desordinateurs, il est important d’en définir le contexte : c’est-à-dire de tracer ses frontière. Nous montrerons le contexte selonles normes d’IEEE, selon SWEBOK et SWE-BOK.

Selon les normes IEEEPour être cohérents avec les définitions, nous reprenons ladéfinition du contexte qu’IEEE présente dans la préface à sesnormes. Nous avons légèrement changé la figure originale en


Pour en finir…

supprimant la boîte Safety et en la considérant comme une descomposantes de la Dependability26 (la confiance).

Fig x.x : Le contexte du génie logiciel

Le GL est délimité par cinq disciplines et les domainesd’application (chaque domaine d’application étant plus ou moinscaractérisé par une discipline) :

1. la gestion de projet27

2. l’ingénierie des systèmes3. la gestion de la qualité4. l’informatique et la technologie5. la confiance (dependability)6. les domaines d’application

Cette figure peut être lue comme une description du GL comme ladiscipline qui, dans les domaines d’application, en s’appuyant26 Le fait que la dependability englobe la safety est plus cohérent avec les définitions courantes de dependability comme étant une caractéristique d’un système constituée de availability, reliability, safety et security.27 Pour laquelle IEEE a défini un guide au corpus de connaissances : A Guide to theProject Management Body of Knowledge.22-10-25 Fondements 14

GénieLogicie

l

Gestion de projet

Ingénierie système

Gestion de la qualité

Domaines d’application

Informatique et technologie

Confiance

Pour en finir…

sur des disciplines déjà éprouvées dans des milieux industrielspermet de réaliser de manière contrôlée des produits logiciels.Ces disciplines, tout en étant non homogènes, ont bien d’élémentsen commun. Par exemple, les frontières entre informatique et GLsont difficiles à tracer28 ou, encore, pourquoi la confiance nefait-elle pas partie de la qualité ? Nous proposons uneréorganisation de la figure qui nous semble d’une part mieuxreprésenter le contexte et de l’autre nous permettre de mieuxappuyer nos critiques :

Fig x.x : Le génie logiciel et ses frontières

La qualité et la confiance29 sont l’arrière plan où le GL et lesautres disciplines sont insérées. Cela nous permet de soulignerune fois pour toutes que la qualité et la confiance sont desconditions sine qua non de toute production de logiciel et, plusgénéralement, de toute production technique.

28 C’est aussi à cause de la difficulté de définir ces frontières que le GL a, dans certains milieux, des difficultés à être accepté.29 Pour ne pas trop nous éloigner de la figure d’IEEE, nous avons gardéséparées les discipline de la qualité et de la confiance, même si, parcohérence avec la définition même de qualité des normes ISO et IEEE, laconfiance devrait fare partie de la qualité.22-10-25 Fondements 15

Qualité et confiance

GLInforma-tique et techn.

Domaine d’application

Gestion de projet

Ing des systèmes

Pour en finir…

Le GL s’appuie sur l’ingénierie des systèmes et est confiné entredeux colonnes (l’informatique et le domaine d’application). Lagestion de projet, comme il se doit, couvre le tout.

Selon SWEBOKLes disciplines qui entourent le GL 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ématiques3. la gestion de projet4. l’ingénierie des ordinateurs5. l’ingénierie des systèmes6. les sciences de la gestion7. Les sciences cognitives et facteurs humains

Dans la figure suivante nous représentons de manière graphique comme nous l’avons fait pour IEEE le contexte.

Figure x.x le contexte selon SWEBOK


Domaines d’application

Mathématiques

GL Scien. Cognitives.

Informatique

Science de la gestion

Ing. des systèmes

Gestion de projet

Ing. des ordinateurs

Pour en finir…

Puisque, dans SWEBOK, les domaines d’application ne sont pasconsidérés explicitement, nous les considérons comme un premierarrière-plan. Nous mettons les mathématiques comme deuxièmearrière plan pour indiquer que seulement quand les domaines sontmathématisés (dotés de règles plus ou moins formelles), on peut yappliquer les techniques du GL avec l’aide des disciplinesconnexes.

Selon SWE-BOKSWE-BOK ne définit pas explicitement le contexte. Ce manque dedéfinition montre, si on en avait encore besoin, que ladélimitation du GL est assez problématique.

11 CorpusSelon SWEBOKVoici la listes des secteurs tels que définis dans la version 0.7 :

1. Exigences2. Conception3. Construction4. Test5. Maintenance6. Gestion de la configuration7. Gestion8. Méthodes et outils du GL9. Processus du GL10. Qualité

Comme il fallait y s’attendre, à cause de la méthode employée, iln’y a pratiquement pas de surprises dans la classification mêmesi les secteurs ne sont pas homogènes. Certains secteurs sont desprocessus30 (de 1 à 7), un secteur est une description deprocessus (9), un autre concerne l’environnement de production(8) et un dernier la qualité. La seul surprise est, selon nous,

30 On emploie ici le terme processus comme dans la norme IEEE 1074. DansISO 12207, par exemple, on appelle activités ce que nous, en suivant la normeIEEE 1074, appelons processus. Mais, pour notre réflexion, cela n’a aucuneimportance.22-10-25 Fondements 17

Pour en finir…

la description du secteur Construction du logiciel (Voir l’annexe E pourune critique de la présentation de ce secteur dans SEWBOK).

Selon SWE-BOKSWE-BOK est constitué de 4 catégories divisées en 21 secteurs :1. Fondements informatiques : algorithmes et structures de données,

architecture des ordinateurs. Fondements mathématiques, systèmes d’exploitation etlangages de programmation.

2. Ingénierie du produit logiciel : ingénierie des exigences, conception,codage, test, fonctionnement du système et maintenance.

3. Gestion du logiciel : gestion des projets, gestion des risques, gestion de laqualité, gestion de la configuration, gestion des processus, et acquisition.

4. Domaines du logiciel : intelligence artificielle, bases de données, interactionspersonne-machine, calcul symbolique et numérique, simulation, systèmes en tempsréel)31.

12 La documentation

La documentation a toujours eu une place spéciale dans le GL, auxdébuts de l’informatique parce qu’elle était pratiquement absente(on32 écrivait du code et, quand ça commençait à fonctionner, ondisait que c’était fini !), ensuite parce que, dans certainesorganisations, elle a pris une importance excessive. Mais,qu’est-ce que la documentation ? Nous proposons une définitionassez générale qui ne devrait pas créer trop de problèmesd’acceptation : toute information produite dans le cadre des projets et qui n’estpas le code. La documentation étant « produite » dans le cadre dudéveloppement d’un produit, elle est étroitement liée auxprocessus dans le sens qu’elle est le résultat des activités quiconstituent les dites processus.

31 À ne pas confondre avec les domaines que le logiciel est censé automatiser, tel que représentés dans la figure x.x.32 Ce « on » n’englobe pas des gens comme Dijkstra, Hoara et beaucoup d’autresuniversitaires qui avaient besoin de la documentation pour enseigner et pourexpliquer leurs travaux de recherche. Ce « on » fait référence à la majoritéde ceux qui travaillaient dans les industries qui commençaient à naître et quise lançaient avec une naïveté redoutable dans le nouveau « business ». Avecnaïveté et, bien souvent, avec ignorance.22-10-25 Fondements 18

Pour en finir…

Dans la norme IEEE 12207.1, la documentation fait partie desdonnées du cycle de vie qui sont organisées en sept catégories pour untotale de quatre-vingt-quatre type d’artefacts, divisés en :descriptions, spécifications (une seule), fiches, plans,procédures, requêtes et rapports. Par rapport aux catégories on ala distribution suivante :1. Exigences : quatre types d’artefacts.2. Conception : cinq.3. Test : cinq.4. Configuration : six5. Utilisateur : cinq6. Gestion : Vingt-neuf7. Qualité : trente-deux

La Gestion et la Qualité contiennent, à elles seules, le 75 % destypes d’artefacts, ce qui n’est pas étonnant puisque ladocumentation est introduite comme un mécanisme de contrôle de laqualité de la production. Puisque la majorité des documents degestion et de la qualité sont des documents assez faciles àproduire, les coûts de la production de la documentation ne sontdonc pas proportionnels au nombre de type d’artefacts. Parexemple, le noyau dur du GL contient seulement 14 types dedocuments (ce qui équivaut au 16 %) mais ces artefacts coûtenttrès souvent bien plus chers que 16 % des coûts de documentation.

Dans l’annexe C, nous présentons en détail et organisés parcatégories les différents artefacts exigés par la normeIEEE 12207.1

13 ConclusionNous terminons ce chapitre en résumant dans trois listes quelqueséléments qui nous semblent caractériser l’état actuel du GL. Ceséléments sont aussi les amorces pour les critiques et lespropositions des chapitres suivants. Dans la première liste nousprésentons quelques uns des thèmes les plus récurrents dans leGL, dans la deuxième nous présentons quelques considérations sur


Pour en finir…

SWEBOK et SWE-BOK et la troisième concerne plus directement lestechnologies.

Quelques thèmes du GL :1. Les processus33 ont une importance centrale et

l’amélioration de la qualité passe surtout par leurdéfinition et par leur amélioration.

2. Les phases « classiques » du cycle de vie (analyse,conception, codage et test) restent les processus centrauxdu développement.

3. Les activités concernant les exigences et les interfacespersonne-machine ont droit au statut spécial de « génie »dans le GL (ingénierie des exigences et de la facilitéd’utilisation). Les domaines d’application sont absorbés demanière plus ou moins explicite dans l’ingénierie desexigences tandis que le cycle de vie de la facilitéd’utilisation est introduit pour systématiser lesinteractions entre le développeur et lesclients/utilisateurs

4. La confiance regroupe des éléments de qualité auparavantséparés (comme sécurité et disponibilité par exemple).

5. Les exigences non fonctionnelles sont toujours plus aucentre du développement, ce qui a comme corollaire la miseen valeur des développements fondés sur l’architecture.

6. L’importance accrue de la maintenabilité rend nécessairedes environnements avec possibilité de « traçage ».

SWEBOK et SWE-BOK1. Les contextes tels que décrits dans SWEBOK, IEEE et SWE-BOK

ont des différences significatives. En particulier seul IEEEparle explicitement des domaines d’applications

2. SWEBOK est essentiellement orienté processus, tandis queSWE-BOK considère aussi des sous-domaines du logiciel(systèmes d’exploitation, bases de données, etc.) comme dessecteurs.

33 Dans la littérature autour du GL, Software Engineering Process de Wang Y. et G.King (CRC 2000) est un des exemples les plus clairs non seulement del’importance des processus mais de la nécessité de fonder la discipline du GLautour d’une formalisation des processus.22-10-25 Fondements 20

Pour en finir…

3. Contrairement à SWEBOK, SWE-BOK emploie le terme« interface » dans une acception très large. La conceptiondes interfaces avec les utilisateurs est correctementconsidérée comme ne faisant pas partie de la conception desinterfaces dans SWEBOK mais malheureusement elle est situédans une discipline qui devrait en être encore plusétrangère : l’informatique. Le remède nous semble pire quele mal.

4. L’informatique telle que présentée dans l’annexe B de SWEBOKest organisée comme une discipline « fourre-tout ».

5. La partie que SWE-BOK met dans la catégorie « ingénierie duproduit logiciel » est selon nous le noyau dur du GL. Àquelques petites différences terminologiques près, danscette catégorie, SWEBOK et SWE-BOK décrivent les mêmessecteurs.

6. Aucune séparation entre le domaine du problème et celui dela solution n’est clairement présentée34.

7. SWE-BOK considère que l’informatique fait partie du GL,tandis que SWEBOK la considère à l’extérieur.

8. Dans les deux guides la maintenance est considérée unsecteur du GL

É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.5. Des bases de données objet commerciales sont disponibles.6. La compatibilité au niveau du « binaire » devient toujours

plus importante (DCOM et CORBA, par exemple).

34 Même si M. Jackson depuis des années non seulement insiste sur l’importancede la séparation mais propose des méthodes qui en tiennent compte.22-10-25 Fondements 21

Pour en finir…

14 Les frontières entre les disciplinesDans ce chapitre nous décrivons les frontières entre le GL,l’informatique et le domaine pour préparer le terrain àl’élagage du GL.

La figure que nous avons présentée en 2.2 et que nous reprenonsici montre le contexte du GL tel que défini dans l’introductiondes normes IEEE :

Figure 3.1 : Le contexte du GL selon IEEE

Cette figure ne montre pas les poids relatifs des différentesdisciplines car ils sont fonction de l’application, de lagrosseur du projet, des exigences en terme de qualité, de latechnologie employée etc. Pour essayer de mieux situer le GL,nous considérons trois cas limites concernant l’importancerelative du GL, de l’informatique et du domaine d’application :

1. seulement le domaine d’application ;2. seulement l’informatique ;3. seulement le GL.

15 Seulement le domaine d’applicationSeul le domaine d’application existe. Il s’agit de la situationidéale pour les clients et les utilisateurs car, une foisdéfinies les règles qui caractérisent le domaine, ils bâtissent22-10-25 Fondements 22


GLInforma-tique et techn.


Gestion de projet

Ing des systèmes

Pour en finir…

eux-mêmes leur application sans passer par des intermédiaires quipourraient « déformer » les besoins. Cette situation est possiblequand l’écart entre les outils informatiques disponibles et ladéfinition de l’application dans le langage du domaine est« petit ». Dans ce cas le GL et l’informatique ont fait untravail préalable qui les a « dissous » dans les outils. On peutconsidérer les trois cas suivants comme exemplaires pour cettecatégorie :

1. Une application avec très peu de traitement où l’utilisateuremploie un gestionnaire de base de données pour accéder demanière simple à ses données qui ont été conceptualisées parun expert du domaine.

2. Une application riche en traitement pour laquelle un langageproche de l’application a été développé par des ingénieursdu logiciel.

3. Une application faite sur mesure à l’aide d’un simpleparamétrage

Figure 3.2 : Seulement le domaine d’application

Il est à noter que le fait qu’informatique et GL soientdisparus n’implique pas la même disparition pour les autresdisciplines. Il est très facile d’imaginer des projets où lesexperts du domaine doivent s’appuyer sur de solides




Gestion de projet

Ingénierie des systèmes

Pour en finir…

connaissances en ingénierie des systèmes35 ou des cas où lagestion de projet est centrale pour la réussite même si leprojet est réalisé seulement par des experts du domaine.

16 Seulement l’informatiqueIl s’agit de la situation contraire à la précédente36 danslaquelle se sont seulement les bases informatiques quicomptent. À ce propos il est important de souligner que sil’informatique n’a pas intégré certaines méthodes dedocumentation propres au GL, il sera difficile sinon impossiblede faire travailler plusieurs personnes sur le même problème.

Exemples :1. Conception d’un nouvel algorithme.2. Amélioration des performances d’un algorithme déjà codé.3. Conception d’un mécanisme de synchronisation de tâches.

Figure 3.3 : Seulement l’informatique

17 Seulement le GLCette situation, quand elle n’est pas due à unebureaucratisation de la production du logiciel, indique que le

35 Comme c’est souvent le cas dans l’automatisation des procédés dans le domaine électrique.36 Ce cas pourrait aussi être considéré comme un cas particulier du précédent avec l’informatique comme domaine d’application.22-10-25 Fondements 24


Informatique

Gestion de projet

Ingénierie des systèmes

Pour en finir…

domaine est bien décrit et qu’il n’y a pratiquement pas dedéfis informatiques. Elle est aussi celle que certainsextrémistes du GL aimeraient normaliser. Voici quelquesexemples :

1. Ingéniériser un système dont il existe un prototypefonctionnel.

2. Porter une application dans un autre environnement.3. Faire des modifications mineures sur un gros système déjà

déployé.

Figure 3.4 : Seulement le GL

Nous croyons que non seulement on ne peut pas avoir des méthodesuniformes dans les trois cas mais qu’on peut même se poser laquestion si des méthodes spécifiques (ou caractéristiques) danschaque cas existent.



GL

Gestion de projet

Ing. des systèmes

Pour en finir…

18 Les rapports entre le GL et l’nformatique37

Les rapports entre informatique et GL sont ambigus et difficilesà tracer non seulement parce que les deux disciplines separtagent un domaine jeune et en ébullition mais aussi parce queles échanges entre les deux sont continuels et vitaux. La figuresuivante schématise les échanges tels que vus « classiquement » :

Figure 3.5 : Échanges entre informatique et GL

Cette figure peut aussi être interprétée comme le lien entrerecherche et pratique : dans la discipline informatique on faitde la recherche qui engendre une théorie qui permet au GL decréer des outils qui favorisent la recherche et ainsi de suite…Cette vision est sans doute un peu simple, sinon simpliste, et cede deux points de vue :

1. Les liens avec la théorie et les outils sontbidirectionnels (l’informatique peut créer des outils etle GL de la théorie)

mais surtout :2. les mêmes personnes devraient travailler dans les deux

disciplines pour ne pas créer des clivages38 trop grands.

37 En anglais la division est au point de vu terminologique plus claire :d’une part on parle de Computer science et de l’autre de S/W engineering(d’une part la science de l’autre la technique).38 Ce point à lui tout seul mériterait un très long article.22-10-25 Fondements 26

Informatique GL

Théorie

Outils

Pour en finir…

Il n’est sans doute pas anodin de mettre en évidence, à cetteétape de notre présentation, que l’informatique aussi est undomaine pour le GL. La « spécialité » du domaine del’informatique du point de vu du GL réside dans le fait que le GLd’une part fournit à l’informatique des connaissances pourconsolider la documentation et de l’autre il lui présente denouveaux problèmes pratiques (ce rapport peut faire penser àcelui entre physique et mathématique ou sociologie etmétaphysique, pour ne prendre que deux exemples).

Cette difficulté à créer une frontière entre le GL etl’informatique est secondaire par rapport à notre proposprincipal, c’est pour cela que quand nous n’aurons pas besoin desouligner les différences entre GL et informatique nous parleronsde GLI (GL et Informatique).

19 Les rapports entre le GL et le domaineSi les rapports entre le GL et l’informatique sont ambigus, ceuxentre le GL et les domaines sont problématiques, et ce au sensfort du terme : ils sont le centre des problèmes du GL.

Rappelons à ce propos notre premier principe :

Tout domaine contient au moins une partie qui est automatisable.

Le fait que l’on puisse automatiser « n’importe quoi » impliqueque le nombre des domaines est pratiquement infini. On pourraitmême ajouter qu’étant donné que les domaines peuvent naître,mourir, se diviser en sous-domaines, se grouper, etc. on pourraitpenser que le GL devrait être fondé surtout sur la capacité des’adapter. Mais il suffit d’y réfléchir un peu pour voir quecette vision ne tient pas. Quand on dit que le GL doit s’adapteron veut surtout dire que se sont les ingénieurs du logiciel quidoivent s’adapter (adapter leur langage, leurs façons detravailler, de communiquer…) aux différents domaines. Mais, mêmesi les humains sont les êtres les plus adaptables qui soient, il


Pour en finir…

est sinon impossible du moins hautement improductif39 d’adapterdes personnes dont les connaissances « professionnelles » sont enlogiciel à la variété des connaissances du domaine. N’est-il pasbeaucoup plus facile d’adapter les experts du domaine àl’automatisation ? Non seulement cela est plus facile mais c’estaussi, à notre avis, la seule façon rationnelle40 d’agir. Maisqu’est-ce que cela veut dire d’adapter les experts du domaine àl’automatisation ? Une chose très simple que souvent les vraisexperts font déjà sans besoin de la carotte du logiciel : définirles concepts du domaine de la manière la plus claire et la moinsambiguë possible. L’ingénieur du logiciel interviendra enpartant41 de ces concepts clairs pour les transformer en élémentsstructurels dans ses programmes. Cette vision implique que desactivités comme élicitations des exigences et l’analyse des exigences devraientêtre des activités en dehors du GL. Est-ce que cela impliquequ’un « génie des exigences » est nécessaire ? Peut-être pour unepériode transitoire, mais certainement pas comme une nouvellediscipline pour tous les domaines car, dans ce cas, on ne feraitque changer le mal de place : des ingénieurs du logiciel auxingénieurs des exigences. Et les ingénieurs des exigences seraitencore pris avec l’infinité des domaines.

La figure suivante montre les interactions entre un GL élagué etles domaines :

39 Et Dieu sait si la productivité est importante en GL !40 Même si dans notre société on demande au gens d’être tout autre querationnels, on peut espérer que la « raison » continue à avoir au moins unefonction de support dans la technique.41 Il est clair que nous simplifions. L’ingénieur du logiciel peut très bienintervenir avant que les concepts soient clairs, mais pas tellement pour lesdécrire à sa manière mais pour pousser les experts du domaine à les clarifier.22-10-25 Fondements 28

GLDomaineDomaineDomaineDomaineDomaine

ConceptualitionConceptualitionConceptuali

tionConceptualitionConceptualition

Pour en finir…

Figure 3.6 : Échanges entre domaine et GL

Nous croyons que cette position est d’une part proche de celle deceux qui, comme M. Jackson, croient, dans la nécessité d’une spécialisation dans le GL de l’autre est assez éloignée car :

1. Il est à notre avis très important de mettre en évidence que la conceptualisation n’est pas une activité d’ingénierie.

2. La spécialisation dans le GL est orthogonale pas rapport aux domaines. On pourrait avoir des ingénieurs du logicielexperts dans le contrôle des procédés, des systèmes distribués, etc.


Pour en finir…

20 InterfacesDans ce chapitre nous avons comme but de montrer que lapréparation des spécifications des interfaces dépend du domaineet du type d’interface et que, lorsque les interfaces sontexternes, leur description ne relève pas du GL. Nous considérons les interfaces selon la première acception duterme « interface » tel que défini dans la norme IEEE Std 610 :« une frontière (limite) partagée à travers laquelle transitentles informations ». Dans le but de mieux cerner les impacts desinterfaces sur le domaine du GL nous proposons la classificationsuivante dans laquelle nous avons mis dans une boîte au contourplus marqué le seul type d’interface qui concerne en premier lieule GL :

Figure 4.1 Classification des interfaces

Une machine42 peut être un ordinateur avec ses programmes, unobjet mécanique non programmée, un programme ou même un simplemodule. Nous avons choisi l’attribut de « vivant » commel’attribut qui pilote la classification. Cet attribut même si onenvisage des machines toujours plus « intelligentes » ou des42 Le fait que nous nous refusons de parler de système à cette étape-ci est un choix très important.22-10-25 Fondements 30

Interfaces

Externes

Internes

Machine-

Être vivant-

Personne-

Animal-Machine

Être vivant-

Pour en finir…

humains toujours plus « stupides » reste, selon nous43, au moinsdu point de vue éthique, politique et opératoire, fondatrice44.

Au premier niveau on a donc trois types d’interfaces. :

Machine-Machine; Être vivant-Machine; Être vivant-Être vivant. Dans ce cas on considérera

seulement les interfaces personne-personne carl’introduction d’une interface animal-animal ou personne-animal serait, dans notre contexte, un simple exerciceacadémique et complexifierait inutilement notre propos.

La catégorisation d’interface internes et externes s’appliqueseulement aux interfaces machine-machine car nous considérons queles autres sont toujours externes45.

Avant d’analyser plus en détail les interfaces, nous introduisonsun principe que nous appellerons le principe fondamental desinterfaces du logiciel qui, tout étant, d’une extrême simplicité,est trop souvent oublié :

Un logiciel pour échanger des données a besoin d’un support matériel (P0x)

Ce principe à un corollaire à l’allure paradoxale :

Une personne46 ne peut pas échanger des données avec un logiciel.

Nous discuterons ce corollaire dans la section des interfacespersonne-machine.43 Cette croyance fait partie de nos paradigmes cachés, comme on dit avec un syntagme assez galvaudé (plus ou moins caché !).44 Que cette différence puisse, du point de vue philosophique, être considérée secondaires est toute autre histoire. 45 Nous sommes conscients de trop simplifier et qu’on pourrait considérer, selon des théories psychanalytiques, que souvent ce sont les inconscients des personnes qui « se parlent » mais au niveau auquel nous nous situons nous croyons que la simplification est acceptable.46 On considérera seulement les être humains même si cela s’applique aussi aux animaux.22-10-25 Fondements 31

Pour en finir…

21 Interfaces personne-personneCe type d’interface, tout étant une interface externe, n’est pashomogène avec les autres deus types : tandis que les interfacesmachine-machine externes et les interfaces être vivant-machineconcerne la dynamique du système les interfaces personne-personnesont des interfaces « Statique » qui ne concerne pas lefonctionnement mais la structure. Les interfaces personne-personne dynamiques dans le cas qui nous concerne peuvent êtreréduite au schéma suivant :

Figure 4.2 Interface personne-personne

Dans un contexte de production de logiciel, les interfacespersonne-personne sont fondamentales car elles conditionnenténormément les projets. On pourrait même risquer de dire que leGL naît pour faciliter les échanges entre les personnes :documenter un module, commenter le code… en un mot ladocumentation, elle sert à quoi sinon à faciliter les échangesentre les personnes. La documentation est importante même dans unprojet avec une seule personne, non seulement parce qu’un jourquelqu’un d’autre pourrait prendre la relève mais parce qu’unemême personne peut jouer plusieurs rôles dans un projet et chaqueéchange entre des rôles implique des interfaces les plus clairespossibles (et pas nécessairement formelle).

Voici un principe concernant les interfaces personne-personne :Le but principal et pratiquement unique des documents du CV est de faciliter leséchanges entre les différents rôles d’une personne ou entre des personnesdifférentes


Personne 1

Machine Personne 2

Pour en finir…

Nous n’en dirons pas plus sur ce type d’interface car cesinterfaces sont considérées de manière indirecte dans d’autressections du document

22 Les interfaces machine-machine47

Les interfaces entre machines sont des interfaces rigides etdéterministes48 et elles peuvent donc être (ou devraient être)décrites de la manière la plus formelle possible. Considérons lesdeux cas qui peuvent se présenter lors de la conception desinterfaces :1. Concevoir une machine afin qu’elle s’adapte au comportement

d’une machine préexistante et qu’on considère en premièreapproximation immuable.

2. les deux machines doivent être conçues

Une machine existe déjàOn suppose qu’il existe une documentation qui décrit lecomportement externe de la machine et que si elle n’existe pas onpeut la construire. La tâche du concepteur de la nouvelle machinesera de respecter les contraintes49 que la première machine apréalablement fixées. Tout est comme si l’interface étaitintégrée à la première machine :

Figure 4.2 Interface « intégrée » à une machine

Pour pouvoir réaliser la nouvelle machine en minimisant à descoûts minimaux et en maximisant la qualité il faut que ladéfinition de l’interface de la première machine soit non47 On considère seulement le cas d’interfaces entre deux machines. Le cas des interfaces entre plusieurs peut toujours se réduire de manière plus ou moins complexe à des interfaces entre deux machines.48 De cette manière on crée une équivalence entre rigide et déterministe et machine et flexible et être vivant.49 Dans ce cas il est préférable parler de contraintes plutôt que d’exigences.22-10-25 Fondements 33

Nouvelle

Machine existante

interface

Pour en finir…

ambiguë, et compréhensible pour le concepteur de la deuxièmemachine. Il faudra donc décrire les échanges permis parl’interface dans un langage le plus formel possible mais qu’enmême temps soit compréhensible par l’expert50 de la premièremachine et le concepteur de la deuxième. Dans quel langagefaudra-t-il décrire l’interface ? Probablement dans le langage dudomaine de la première machine. Par qui ? Par un expert dudomaine de la machine. Considérons à ce propos deux cas :interfaces interne à la machine qu’on doit construire etinterfaces externes.

Interfaces externesSupposons de vouloir interfacer la machine à un alternateur, parexemple. Ce sera un ingénieur électrique qui décrira lesinterfaces en termes de types d’entrées et sorties, de séquences,de temporisations, etc. Cette description sera un intrant pourl’ingénieur du logiciel équivalent à une spécification desexigences51 pour le système. Dans quel langage ? Pratiquement dansn’import quel langage un tant soit peu formel, car un supposeque l’ingénieur du logiciel puisse apprendre facilement unlangage. Bien plus facilement qu’apprendre les concepts et lesdécrire dans un langage à lui.

On peut donc affirmer que dans le cas des interfaces externesl’échange principal lors de la réalisations de la machine est lesuivant :

Figure 4.3 Échange ingénieur du logiciel expert du domaine

Voici un principe à propos des interfaces externes machine-machine :

50 Qui n’est pas nécessairement le concepteur.51 Plus précisément on pourrait l’appeler Spécification des Exigences des Interfaces.22-10-25 Fondements 34

Expert du

Ingénieur du Spécific

Pour en finir…

Pour spécifier une interface externe on n’a pas besoin d’avoir des connaissancesen GL.

Interfaces internesDans ce cas les deux machines sont des modules52 logiciels(classes, procédures, tâches…) et les interfaces seront décritesdans un langage commun aux deux ingénieurs du logiciel dans cequ’on appelle un langage de conception53.

Dans le cas des interfaces externes étant donné le principe xxque nous avons présenté au début du chapitre il faudra que lemodule que l’on conçoit puisse parler à du matériel (directementou à l’aide d’un module du système d’exploitation par exemple.

23 Les deux machines doivent être conçuesCe cas est une généralisation du cas précédent et est caractérisépar un plus grand degré de liberté dans la définition desinterfaces. Comme dans la section précédentes on considère deuxcas : interfaces externes et interfaces internes .

Interfaces externesIl faudra que la spécification des interfaces tienne compte :

du domaine dans lequel les deux machines doivent dialoguer; des contraintes matérielles, de coûts, d’échéancier

(ingénierie des systèmes) des contraintes logicielles.

+++ continuerInterfaces internesSi les deux machines ne sont pas des modules logiciels mais des« vrais » des sous-systèmes (matériel plus logiciel)…. Comme52 Au cas où il s’agit de deux sous-systèmes on peut les considérer comme des interfaces externes dont celle d’un sous0système dont définies.53 À ce niveau on parle de conception même si pour le deuxième module il s’agitd’exigences ou contraintes à cause du fait que le module fait probablement partie d’une structure plus vaste. Dans le cas d’une conception en fonction dela réutilisation on pourrait parler d’exigences même à ce propos.22-10-25 Fondements 35

Pour en finir…

dans la section précédentes on considère deux cas : interfacesexternes et interfaces internes .Si les deux machines doiventêtre conçues,

Dans ce cas les interfaces découleront de la structure dulogiciel

+++ continuerConsidérons encore le cas d’un protocole. Théoriquement je peuxpenser un nombre infini de protocoles différents. Pratiquement enfonction de contrainte d’ordre plus générale que celle dictéespar les interfaces on pourrait limiter les protocoles possibles(par exemple, à fenêtre coulissantes avec xxxx). Mais le choix dela famille, la spécification du protocole ne dépend absolumentpas du logiciel…. ++ continuer++++

Attention aux sous-systèmes

24 Les interfaces personne-machinesLes interfaces personne-machine sont considéré presqueunanimement comme faisant partie du génie de la facilitéd’utilisation+++ montre comment elles ne peuvent pas relever du domaine du GL

Introduire le génie de exigences


Pour en finir…

25 Le génie des exigencesThéoriquement il faudrait saluer comme une des plus grandesinnovations le fait qu’on a introduit le génie des exigences maispas tellement parce que de telle manière on a reconnu que lesexigences ont droit à un statut spécial et, en particulier, unstatut dans le cadre du génie mais parce que c’est le moyen defaire sortir les exigences du génie logiciel. Ce qui estintéressant c’est que dans le cadre du SWEBOK dans le secteur desexigences on dit clairement que « le qualificatif logiciel n’estplus associé à ingénierie des exigences » parce que l’ingénieriedes exigences est « une activité de l’ingénierie des systèmes ».Cette considération devrait suffire à elle seule…

*****À souligner que ce n’est pas un hasard si on dit conception dulogiciel ou construction du logiciel mais qu’il est trèsincorrect de dire Exigence du logiciel (il s’agit d’exigencespour le logiciel) comme quoi la langue naturelle est parfois bienplus exigeante qu’on ne le pense !!!++++=

Principe : L’analyse d’un problème est interminable. Ce principe a commecorollaire que pour construire un produite il faut décider quandarrêter l’analyse en se fondant sur les éléments externes auproblèmes. Ces éléments externes peuvent être les idiosyncrasiesdes individus, les règles de l’entreprise,… Parfois on a besoind’une solution partielle pour comprendre le problème…

++++ parler de l’ambiguïté de « exigences logicielle » ousystème… le temps…

26 Un exemple : protocole de communicationPour appuyer notre démarche de critique du GL, nous avons choisi un exempletiré du domaine des protocoles de communication. Nous avons choisi ce domainequi, par certaines personnes, pourrait même être considéré comme faisantpartie intégrante de l’informatique, pour montrer que même dans un domaine22-10-25 Fondements 37

Pour en finir…

aussi « spécial » et proche de l’informatique, il est préférable d’élaguer leGL.

Mise en contexteConsidérons une entreprise qui opère dans le contrôle des procédés et quiconstruit des sous-systèmes ayant des fonctions primaires très spécifiques etqui doivent communiquer avec d’autres sous systèmes. Supposons que lesmachines dans lesquelles le protocole s’exécute ne peuvent pas fonctionneravec des protocoles synchrones (style HDLC) à cause des contraintesmatérielles. Supposons aussi que l’entreprise a dernièrement engagé desinformaticiens, même si son noyau dur est composé d’ingénieurs qui ont apprisl’informatique de manière pas tout à fait systématique54 et qu’une équiperesponsable du protocole est créée.

Pour être un peu plus concrets nous supposons que la protocole qui seradéveloppé est la couche liaison de données DNP55.

Nous présentons une liste d’activités assez réaliste (et non seulement pour ily a trente ans56).

Suite des activités1. Fixation des contraintes de coût et d’échéancier.2. Première version des besoins fonctionnels et non fonctionnels.3. Études des protocoles existants et des normes.4. Étude de faisabilité (le choix résultant de l’étude étant de définir un

nouveau protocole en partant de la norme IEC 870-5-1 et IEC 870-5-2).5. Définition du protocole

o Mode de fonctionnement (fully balanced).o Format du LPDU.o Définition des codes de fonction.o Définition des méthodes de récupération.o Définition abstraite des SAP et LSDU.o ...

6. Prototype pour valider les idées et tester en gros les fonctionnalités.7. Finalisation de la spécification.8. « Ingéniérisation » du produit.9. Tests d’acceptation.10. Maintenance57 (améliorations , corrections etc.).

54 C’est clairement le cas pour un très grand nombre d’entreprises qui sont passées de la « logique câblée » au logiciel à cette époque.55 Distributed Network Protocol .56 Pour une mise en correspondance plus générale des activités décrites dans lanorme ISO 12207 et les connaissances du GL, voir l’annexe B.57 Nous considérons improprement la maintenance comme une activité.22-10-25 Fondements 38

Pour en finir…

Dans la suite on analyse chaque activité présentée ci-dessus en faisant desconsidérations par rapport aux connaissances nécessaires pour compléterl’activité de manière optimale.

Approche classiqueToutes les activités font partie du GL.

Notre approche Établissement des contraintes de coût et d’échéancierCette activité est un choix global de l’entreprise et tout étantfondamentale elle ne dépend pas des connaissances en GL, sinon commecapacité d’analyser les intrants des équipes de GL.

Première version des besoins fonctionnels et non fonctionnelsCette activité est plus technique que la précédente, mais les types deconnaissances qu’elle demande sont seulement dans le domaine desprotocoles. Aucune connaissance en GL est requise.

Études des protocoles existants et des normesExactement comme au point précédent.

Étude de faisabilitéCette partie demande des connaissances plus variées et il faut lacontribution d’au moins un ingénieur du GL pour la faisabilité techniqueet économique.

Spécification du protocoleActivité qui demande seulement des experts du domaine. Les expertschoisirons le langage de description qu’ils croient le plus apte àdécrire le protocole. Mais la spécification ne demande aucuneconnaissance en GL. À ce propos, il est clair que dans n’importe queldomaine la tendance doit être de donner des outils de si haut niveau queles experts du domaine ne doivent pas connaître l’informatique58..

PrototypeCette activité ne demande pas de connaissances en GL mais simplement unecapacité à aligner une instruction après l’autre comme… au bon vieuxtemps. Il s’agira sans doute d’un prototype jetable.

Finalisation de la spécificationComplètement pris en charge par des experts du domaine

58 Une connaissance superficielle est bien sûr utile. Mais comme on ne demande pas à tous ceux qui plantent un clou d’être des charpentiers ou, pire encore, des concepteurs de marteaux !22-10-25 Fondements 39

Pour en finir…

« Ingéniérisation » du produitC’est ici que le GL devient important. On pourrait dire que c’est unepétition de principe car si on parle d’ingénierie après avoir développéune partie du produit il est clair que cette ingénierie sera le… GL. Nouscroyons qu’il ne s’agit pas d’une pétition de principe, car les activitésqui précèdent ce que nous appelons ingénierie ne sont pas des activités« non scientifiques » ou « non techniques » ou « floues », mais ellessont des activités systématiques au même titre que le GL mais, si onveut, dans un autre génie59 : celui des protocoles. Pour nous,« ingéniérisation du produit » signifie application des connaissances du GL pourconstruire un produit logiciel de manière maîtrisée et de manière à cequ’il soit maintenable avec des coût raisonnables.

Test d’acceptationAucune connaissance en GL.

Documentation utilisateurAucune connaissance en GL.

MaintenanceToute la maintenance demande une connaissance très grande du GL avec biensûr des connaissances du domaine des protocoles (pas nécessairementexercés par les mêmes personnes).

Exemples de choix faits en se fondant sur les connaissances du domaine Délimitation des trames. Adressage. Structure des octets définissant les codes de

fonction. Type de contrôle d’erreur Nombre de retransmissions Synchronisation entre trames Deadlocks (pour le protocole) …

Exemples de choix faits en se fondant sur les connaissances du GL59 Le fait de caractériser comme de l’ingénierie tout ce qui est systématique(comme ingénierie des exigences, par exemple), nous semble excessivementréducteur. Nous croyons que non seulement des philosophes comme Kant ou Hegelont été très systématiques mais même des poètes comme Valéry auraient beaucoupde choses à enseigner à des ingénieurs en ce qui concerne la systématicité, lalogique, la maîtrise, etc. Comme me l’a fait noter le professeur L. Martin,l’ingénierie est en train de faire ce que la philosophie faisait au moyen âgefaisait la philosophie. Cette considération est une transposition trèsappropriée des idées d’Heidegger sur la technique comme fin de lamétaphysique.22-10-25 Fondements 40

Pour en finir…

Nombre de thread (fils d’exécution) Type de dialogue entre la couche trois et la deux

(synchrone ou asynchrone) Synchronisation entre les threads. Deadlocks (pour le threads) Paramétrage de configuration …

ConclusionsLa séparation entre les connaissances des deux domaines nous semble trèsclaire. Pratiquement seulement deux « activités » concernent des connaissancesdu GL (Ingéniérisation et maintenance). Il est intéressant de considérer que deséléments comme Deadlock et synchronisation apparaissent dans les deux domaines, cequi nous semble indiquer que, même quand deux domaines60 sont concernés par les« mêmes concepts », la façon de les traiter est différente. En effet, on peutparler de synchronisation dans bien des domaines sans que cela veuille direqu’il s’agit de GL ou de protocoles.

60 Le fait de mettre les deadlocks dans un secteur de l’informatique comme propose SWEBOK ne fait que renforcer notre position !22-10-25 Fondements 41

Pour en finir…

27 La qualitéDans la qualité la confusion règne souveraine et cette confusionest due au fait que l’on ne différencie pas les qualités« intrinsèques » (celles qui concernent le génie logiciel) et lesqualités extrinsèques (celles qui concernent la machine dans soninteraction avec l’environnement).

Considérons par exemple la norme ISO 9126. Voici les élémentsconstituant la qualité (I pour intrinsèques et E pourextrinsèques) :

Français Anglais I ECapacité fonctionnelles X

Aptitude Suitability XExactitude Accuracy XConformité réglementaire

Compliance X

Sécurité61 Security XFiabilité

Maturité Maturity XTolérance aux fautes

Fault tolerance

X

Possibilité derécupération

Recoverability

X

Facilité d’utilisation (usability)

Facilité de compréhension

Understandability

X

Facilité d’apprentissage

Learnability X

Facilité d’exploitation

Operability X

61 Dans la norme ISO la sécurité est placée dans les capacités fonctionnelle. Dans d’autres classification elle est mise dans la confiance avec entre autre la fiabilité.22-10-25 Fondements 42

Pour en finir…

Français Anglais I EMaintenabilité

Facilité d’analyse

Analysability X

Facilité de modification

Changeability X

Stabilité Stability XFacilité de test

Testability X

PortabilitéFacilité d’adaptation

Adaptability X

Facilité d’installation

Installability

X

Conformité auxrègles de portabilité

Conformance X

Intercheangeabilité

Replaceability

X

Parler éventuellement de la confiance (dependability)

Aborder la différence entre Vérification (interne) et Validation(surtout externe)

Si on prend un classique publié en 2001 [SO01] on voit que laqualité est complètement mélangée (page 13).

Prendre aussi les key points de page 68 de [SO01[

Page 90 [SO01] il y était presque : « S/W management is distinct(…) in intangible » non ce n’ets pas pour cela … c’est pour lavariété…

… voir les key points… annexe ????


Pour en finir…

28 Qualité intrinsèque

29 Qualité extrinsèque


Pour en finir…

30 Les tests


Pour en finir…

31 Conceptualisation du fonctionnement (Concepts of operation)62

+++ à mettre dans génie des exigences

Dans la norme IEEE Std 1362-1198, on souligne qu’idéalement laconceptualisation du fonctionnement doit être écrit par « lacommunauté des utilisateurs » mais qu’en pratique elle est écritepar d’autres gens mais que, indépendamment, de qui l’écrit, elledoit être écrite dans la « terminologie de l’utilisateur ». Cequi implique forcement des utilisateurs. Le problème avec celac’est que si les utilisateurs principaux sont des machines… quellangage employer pour les machines….

On peut faire référence à des études de faisabilité (page 6)…

Clause sur la classe des utilisateurs dans laquelle on liste tousles utilisateurs

62 Nous ne sommes pas très contents de la traduction du syntagme anglais, mais nous n’avons pas pu faire mieux.22-10-25 Fondements 46

Pour en finir…

32 Propositions constructivesCertaines de ces propositions découlent directement descritiques, d’autres ont des origines moins précises et d’autressont des simples « indications pour des indications » pour desrecherches futures. Mais toutes ces propositions trouvent leurbase dans la synthèse opérée par SWEBOK qui nous espérons sera ledéclencheur d’ une vraie réflexion sur le GL et les disciplinesconnexes,

33 partie analytique

34 Le génie des exigencesNous conservons le syntagme « Génie des exigences » mais si nousne sommes pas tout à fait convaincus que se soit la bonneterminologie. Nos convictions découlent de notre premierprincipe : étant donné le nombre infini de domaines on ne peutpas parler de « génie » à propos de tous. Ce qui est importantc’est que dans le cadre de l’analyse du

35 Conceptualisation du fonctionnement

36 Spécification des exigences

37 Analyse versus conception du systèmexxxx

38 Conception des interfaces

39 La qualité

40 Les tests

41 La formation


Pour en finir…

42 Synthèse

43 GL comme discipline qui intègre l’informatique

44 GL comme discipline fondé sur l’informatique

45 GL comme réseau de disciplines

46 ConclusionsNotre première conclusion est, comme on pourrait s’attendre, l’abandon du syntagme « Génie du logiciel » pour Génie de l’informatique. Dans ce cas la langue française a un avantage clair dur l’anglais qui aurait des difficultés avec Computer Science Emgineering.

47 Principes

Nom Principe CommentaireP01 Tout domaine contient au moins une

partie qui est automatisableP02 Un domaine est complètement

automatisable si et seulement si ses« frontières » sont formalisables

Les programmes pour un domainecomplètement automatisable peuventêtre générés automatiquement

P03 Le génie logiciel ne peut pas êtreconsidéré un génie comme les autresen raison du nombre pratiquementinfini de domaines pour lesquels onpeut produire des logiciels et del’extrême facilité à générer des copiesdes exécutables

Toute analogie fondée sur les géniestraditionnels crée des modèles erronéset de faux espoirs

P04 La maintenabilité est la qualitéintrinsèque principale pour touteapproche d’ingénierie audéveloppement du logiciel

Là où la maintenabilité n’est pasimportante, on a affaire à de larecherche ou du prototypage


Pour en finir…

Nom Principe CommentaireP05 Les coûts d’informatisation de la

solution d’un problème complexe sontélevés, quelle que soit la simplicité dela solution.

Corollaire. Une solution simple àun problème complexe n’implique pasnécessairement un coût global faiblecar la solution est souvent élaborée àpartir d’un travail énorme sur leproblème (analyse).

P06 Une personne ne peut pas échangerdes données avec un logiciel.

P07 L’analyse d’un problème estinterminable.

C’est à cause de ce principeque souvent il faut s’engagerdans la solution aventd’avoir terminé. La solutionaide à comprendre certainefacette du problème. L’enversde la médaille c’est qu’onrisque d’oublier des détaildu problème qqqui peuvent seretourner contre al solution.

P08 Plus une méthode est générale etmoins elle est efficace

Ce principe a commecorollaire qu’une méthodeuniverselle ne peut pasexister, à moins d’êtred’aucune utilité pratique

P09 La technique est fondée surl’importance du détail.

P10 La machine entre dans un monde quilui pré-existe

Elle doit donc s’adapter mêmeen même temps, avec saprésence, elle change lemonde qui s’adapte à elle quià son tour…

P11 L’effet de l’informatique est pervers :en rendant « moue » la machine aendurci les règles du monde réel.

Surtout à cause du fait quedes lieux qu’on n’auraitjamais pensé de mécaniser lesont.


Pour en finir…

48 Pourquoi pasLe tableau suivant résume les motivations qui nous font opter pour le retrait d’un certain nombre de document du génie logiciel. Ceci ne veut pas dire qu’il ne doivent pas être écrits mais cela veut dire qu’il doivent être écrits par des personnes qui ne sont pas des ingénieurs du logiciel..

Document Justification du retrait du génie logicielConceptualisation du fonctionnement

Il s’agit d’un document où les connaissances en logiciel sont d’une importance minime. Ce qui est important ce sont la compréhension dela stratégie de l’entreprise, une diplomatie…

Spécification des exigences du logiciel

…

Guide de l’utilisateur

…

Cahier des essais d’acceptation

…

Il s’agit comme on peut le voir de très gros morceaux de documentation, Dans cette approche la documentation se réduit pratiquement à : documents de conception, commentaires du code etdocuments pour les essais des composants ou d’intégration.

49 Prière

Recherches ultérieures.

50 Bibliographie

BO94 Booch G. OO Analysis and Design Benjamin 1994GA95 Gamma E. Design Patterns Addison-

Wesley 1995IE01 IEEE/ANSI Std 610 Standard Glossary of

S/W Engineering TerminologyIEEE


Pour en finir…

JA92 Jacobson Ivar OO S/W Engineering Addison-Wesley 1992

JM01 Jackson Michael

Problem frames ACM 2001

JT79 Jensen R,, Tonies C.

S/W Engineering Prentice Hall1979

ME88 Meyer B. OO S/W construction Prentice Hall1988

PR92 Pressman R.S. S/W Engineering a practitionner’s approach

MC Graw Hill 1992

RU91 Rumbaugh J. OO Modeling and design Prentice Hall1991

SEI1 CMU/SEI A S/W engineering body of knowledge

April 1999

SO01 Sommerville Ian

S/W engineering Addison-Wesley 2001

SW07 SECC SWEBOK A stone man version April 2000YE77 Yeh R.T.

editorCurrent trends in programming methodologies

Prentice Hall1977

YO79 Yourdon E. Structured Design Yourdon Press1979


Élagage du génie logiciel

Documents