Maj : 17 Octobre 1996
|
Se connaître pour s'améliorer...
ou disparaître ! Maj : 17 Octobre 1996 |
| Articles |
Emmanuel Lazinier
Délégation générale pour l'armement -
Ingénierie du Logiciel
Reproduit avec l'aimable autorisation de la revue GENIE LOGICIEL
Apparus à une date encore récente, les logiciels n'en tiennent pas moins dans les économies des pays développés une place d'ores et déjà considérable. On les trouve désormais à peu près partout. Rares en effet sont aujourd'hui les produits grand public qui n'en contiennent pas peu ou prou : il y en a jusque dans les rasoirs électriques, les machines à coudre, les jouets... Et dans les systèmes sophistiqués ils ont pris une importance que le public, même averti, ne soupçonne pas. Ce qui faisait dire récemment à un amiral de l'US Navy, à propos d'un de ses nouveaux aéronefs : " Cela ressemble à un avion, mais en réalité ce n'est que du logiciel qui vole ! "
Une des premières caractéristiques des logiciels est donc qu'ils s'insinuent partout. Une deuxième, de plus en plus évidente, est qu'ils sont porteurs de gros risques. Ces risques sont de deux ordres. D'abord les risques liés aux produits, dont les défectuosités peuvent causer de graves dommages aux biens et aux personnes. Ensuite les risques liés à l'absence de maîtrise des processus de développement. Ces derniers risques étant la cause principale des premiers, et se traduisant en outre par de graves dérives de coûts et de délais, quand ce n'est pas par un abandon pur et simple. A titre d'illustration les firmes américaines, qui dépensent chaque année quelque 250 milliards de $ en logiciel, avouent un taux d'échec de l'ordre de 50 %. Or les Américains sont quand même les champions du logiciel, détenant aujourd'hui 50 % du marché mondial des progiciels (et, soit dit en passant, 40 % du marché européen) !
Et un autre péril se profile à l'horizon : pour certains pays en voie de développement industriel, ou développés mais peu présents sur les marchés internationaux, le logiciel représente une occasion favorable intéressante de par les faibles investissements matériels et d'infrastructure qu'il nécessite. Ceci explique les efforts considérables consentis par ces pays en matière de formation et de soutien aux entreprises du secteur.
Les pays développés sont donc confrontés en matière de logiciel à une double menace :
C'est ce qui faisait récemment pousser à une haute autorité du Department of Defense des Etats-Unis ce cri d'alarme :
si nous ne prenons pas des mesures énergiques, notre industrie du logiciel va tomber aux mains de la concurrence étrangère tout aussi sûrement que par le passé l'automobile, l'acier et l'électronique grand public.
Il nous faut aujourd'hui penser globalement. Il nous faut reconnaître que, à moins de nous mobiliser à l'échelle de la nation, non pas à l'échelle de l'Air Force, non pas à celle du DoD, mais à l'échelle de la nation, nous n'arriverons pas à maîtriser à temps ce problème de management technologique.
Parmi nos partenaires les plus proches et les plus importants, deux pays au moins paraissent avoir pris toute la mesure de ces enjeux et entrepris des actions énergiques pour la promotion et la survie de leur industrie du logiciel : le Royaume-Uni et les États-Unis. Et dans ces deux pays c'est le ministère de la défense qui paraît avoir pris l'initiative (et, par voie de conséquence, jouer le rôle de chef de file) du combat pour la survie d'une industrie nationale du logiciel.
Que le rôle de chef de file ait été pris dans ces deux pays par la Défense se comprend assez bien. La Défense est un grand acheteur de logiciel. Elle est tout particulièrement sensible aux risques, tant en matière de coûts/délais qu'en ce qui concerne la sécurité des logiciels qu'elle commande. Enfin, c'est un secteur qui, même dans les pays les plus libéraux, ne peut que rester étatique et donc animé d'un esprit de service de la collectivité tout entière.
C'est ainsi que nous voyons le Department of Defense des États-Unis financer entièrement un institut d'ingénierie du logiciel fort de deux cents personnes et de renommée mondiale - le SEI (Software Engineering Institute) de l'Université Carnegie-Mellon de Pittsburgh (Pennsylvanie) , fameux entre autres choses pour son Modèle d'évolution des capacités logiciel, le SW-CMM - et prendre en 1993 l'initiative de la création d'un conseil national du logiciel (le National Software Council) chargé de fédérer les efforts des industries et administrations en vue de la survie de l'industrie américaine du logiciel.
C'est ainsi également que nous avons vu le Ministry of Defence du Royaume-Uni investir très lourdement dans la méthodologie TickIT d'évaluation tierce partie des industriels, et plus récemment dans le projet ISO/SPICE basé sur l'auto-évaluation/auto-amélioration des développeurs de logiciel.
Les hommes de logiciel ont la fâcheuse réputation de toujours vouloir faire bande à part, et tout particulièrement en matière de qualité. La technologie du logiciel est-elle si différente du reste du monde pour mériter qu'on lui applique un traitement particulier ? La question est délicate et vaut bien qu'on s'y arrête quelques instants.
Qu'est-ce qui caractérise le logiciel ? Il est immatériel, il est de l'information et rien d'autre. En conséquence, il ne se fabrique pas : le produit qui sort du bureau d'étude est, à très peu de chose près, le produit final.
Mais à y regarder de près cette caractéristique ne fait pas du logiciel quelque chose de complètement à part. Car un matériel, avant d'être fabriqué, lorsqu'il sort du bureau d'étude sous forme de dossier de définition et de fabrication - parfois appelé " produit virtuel " - est lui aussi quelque chose d'entièrement immatériel. En quelque sorte c'est un logiciel.
Si l'on adopte ce point de vue, la dichotomie logiciel/matériel se dissout entièrement. Un matériel n'est pas autre chose qu'un logiciel qu'il faut matérialiser - " traduire " sous forme mécanique ou électronique - pour qu'il devienne opérationnel, alors qu'un logiciel au sens strict est directement opérationnel, sans traduction/fabrication.
Cette petite théorie peut paraître bien abstraite et oiseuse. Elle n'en a pas moins, si on l'admet, des conséquences importantes. En effet, si tout matériel passe au cours de son développement par une phase où il n'est que logiciel, alors, toutes les méthodologies proprement logicielles doivent pouvoir s'appliquer peu ou prou aussi aux matériels, dans leur phase étude. Par contre, toute méthodologie conçue pour s'appliquer aux matériels dans la phase fabrication de leur développement sera très difficilement applicable aux logiciels.
Or n'est-ce pas précisément ce que nous constatons aujourd'hui ?
Je n'ai pas l'intention d'entrer ici dans la polémique concernant l'applicabilité au domaine des logiciels de la norme ISO 9001. Beaucoup de points de vue ont déjà été publiés sur ce sujet et je vous y renvoie. Mais je pense qu'on peut, sans grand risque d'être contredit, avancer que ce qui crée des difficultés pour l'application de cette norme au logiciel est qu'elle reste largement prisonnière, même lorsqu'elle traite des activités d'étude, d'une mentalité très orientée fabrication.
Inversement nous assistons de plus en plus à des tentatives qui visent à transplanter dans le monde des matériels et des systèmes des concepts et des méthodologies apparues initialement dans le monde du logiciel.
Un premier exemple : le SEI travaille aujourd'hui, avec de grands industriels américains, à la transposition au niveau système de son fameux SW-CMM. Et l'on notera au passage que ces travaux utilisent très largement les avancées théoriques du projet SPICE
Deuxième exemple : le sous-comité SC7 " Software Engineering " de l'ISO/IEC JTC1 se propose de transposer au niveau système la norme ISO/IEC 12207.
Troisième exemple en date : nous assistons ces derniers temps à des tentatives - à priori prometteuses - de transposition au niveau de l'ingénierie système des techniques d'analyse et de conception orientées objet !
Il y a bien longtemps que l'on répète que, pour avoir l'assurance de la qualité d'un logiciel, il ne suffit pas de s'intéresser au produit lui-même (c'est-à-dire bien le spécifier, bien le tester...), mais qu'il convient aussi et surtout de regarder la manière dont ce logiciel est produit, autrement dit les processus en place chez l'industriel chargé du développement. Mais les approches pour atteindre ce but ont beaucoup varié.
L'approche contractuelle " dure ". Elle consiste pour le client à imposer à l'industriel, jusque dans le détail, la manière dont il doit s'y prendre pour réaliser le logiciel objet d'un contrat. C'est l'approche, dite " méthodologique " de la DOD-STD-2167A et de la GAM-T17 (V2). Cette approche a deux inconvénients. Le premier est qu'un industriel possède en général (et c'est heureux !) sa propre façon de travailler et qu'il peut difficilement en changer au gré des contrats. Le deuxième est qu'il n'existe pas, semble-t-il, de méthodologie universelle, valable pour tous les types de logiciel et compatible avec toutes les techniques de développement, présentes et à venir. Ainsi le cycle de vie en " cascade " ou en " V " des deux normes précitées s'est révélé peu compatible avec les nouvelles méthodes de développement orientées objet...
L'approche par évaluation seconde ou tierce partie. Elle consiste à auditer les fournisseurs potentiels de logiciel pour tenter de s'assurer qu'ils ont la capacité requise pour développer des logiciels de qualité sans dérives de coût ni de délai. Cette approche présente un défaut intrinsèque et deux autres défauts plus conjoncturels. Le défaut intrinsèque est que cette approche instaure ipso facto entre auditeur et audité un climat de défiance mutuelle qui n'est pas très favorable à une appréciation parfaitement réaliste et sereine des capacités réelles d'un développeur de logiciel. Les deux défauts plus conjoncturels viennent du fait que ce type d'évaluations a été fait jusqu'ici essentiellement par rapport à des référentiels (ISO 9001 et 9000-3, AQAP-13...) extrêmement succincts. D'où une marge d'interprétation très grande pour les auditeurs, qui permet de douter très sérieusement de l'homogénéité de telles évaluations. D'où le caractère purement binaire (pass/fail) de ces évaluations qui, quelle que soit leur issue, ne donnent à l'audité ni description précise de son état actuel (ce qu'on appelle aujourd'hui son niveau de maturité), ni carte détaillée des mesures à prendre pour progresser.
L'approche contractuelle " souple ". C'est essentiellement celle des normes de la série ISO 12207 et de la norme militaire US MIL-STD-498 qui a pris la suite de la DOD-STD-2167A et qui se veut fondée sur la 12207. L'objet de ces normes est essentiellement de fournir aux clients et aux fournisseurs un langage commun, sous la forme d'une " carte du terrain " aussi précise que possible - mais sans imposer au développeur sa façon de travailler (en particulier, sans prescrire un modèle spécifique de cycle de vie). On échappe ainsi aux deux inconvénients relevés plus haut à propos de l'approche contractuelle " dure ", et le client doit pouvoir ainsi disposer d'une très grande visibilité sur son fournisseur. Cette approche a néanmoins l'inconvénient d'être formelle et par là-même statique. En effet, il lui manque une dimension " évolutive ". Elle ne tient pas compte du niveau réel de maturité d'un industriel à un moment donné et de la nécessité qu'il peut y avoir pour lui à s'améliorer, progressivement et de façon méthodique.
Les approches " à niveaux de maturité " : les modèles CMM et SPICE. Ces approches conservent l'acquis (en termes de description fine des processus) de l'approche précédente, auquel elles ont le grand mérite d'ajouter une dimension dynamique, " évolutionnaire ", très réaliste. Elles partent du principe que si un industriel, à un moment donné, se trouve à un niveau de maturité n , il n'est pas raisonnable d'espérer qu'en quelques mois il pourra se hisser au niveau n + 2. Elles permettent à un développeur de logiciel non seulement de se connaître de manière très précise, mais encore de déterminer finement quelles actions d'amélioration il peut raisonnablement entreprendre, et dans quel ordre, s'il souhaite élever son niveau de capacité. Il n'est donc pas étonnant que ces approches, suscitées au départ par les clients, aient été très vite " récupérées " par les fournisseurs, qui ont compris qu'ils tenaient là des outils irremplaçables pour (1) se connaître, (2) s'améliorer, et (3) survivre ! D'où la très nette l'orientation vers l'auto-évaluation qui a été prise par ces approches au fil du temps (sans pour autant qu'elles excluent les évaluations seconde ou tierce partie).
Depuis septembre 1987, date à laquelle le SEI publiait la première ébauche de ce qui allait devenir le CMM (Capability Maturity Model), on peut dire que l'approche par modèles de maturité (qui n'a au demeurant pas été inventée par le SEI) a connu un étonnant succès.
Succès du Software-CMM, qui a été très largement utilisé, surtout aux États-Unis et au Japon, qui a bénéficié, en huit ans d'existence, d'un retour d'expérience considérable, et qui a servi de base aux travaux très prometteurs du projet SPICE. Longtemps méconnu en France, le SW-CMM paraît, depuis quelque temps, y faire une entrée en force, poussé par les exigences de plus en plus précises des grands donneurs d'ordres internationaux (par exemple Boeing) et par son adoption officielle par de grands groupes (Thomson-CSF, Alcatel, Bull, Schneider Electric, TRT, Matra Ericsson Telecom...). La récente initiative franco-québecoise detraduction française (officialisée par le SEI) des principaux documents du SW-CMM est un signe parmi d'autres d'une prise de conscience française en la matière.
Mais, à côté de l'éclatant succès du SW-CMM, il n'est pas moins remarquable de constater à quel point il est en train de " faire des petits ". J'ai déjà mentionné les travaux en cours pour son extension vers le haut, sous la forme d'un " Systems Engineering-CMM " et d'un " Integrated Product Development-CMM ". Non moins remarquable, me semble-t-il, est la tentative (apparemment des plus prometteuses) qui a été faite ces derniers temps par Watts Humphrey de le décliner vers le bas, au niveau du développeur individuel, sous la dénomination de Personal Software Process. Il faut mentionner aussi l'existence d'un " People Capability Maturity Model (P-CMM) " et d'un " Software Acquisition Maturity Model ". Sont également en cours de développement un " CALS Capability Model " et un " Data Management Maturity Model "
Si les Etats-Unis eux-mêmes, comme on l'a vu plus haut, s'inquiètent de la survie de leur industrie du logiciel, la France n'a-t-elle pas dans ce domaine quelques soucis à se faire ? La réponse est bien évidemment oui.
Le logiciel est devenu une affaire planétaire. Sur le plan des techniques et des outils, bien sûr. Sur le plan des marchés, évidemment. Mais aussi sur celui des méthodes de management et de maîtrise de son développement - j'espère que ce qui a été évoqué plus haut aura dissipé les derniers doutes à ce sujet, s'il en subsistait.
Participons-nous suffisamment aux travaux internationaux qui visent à recueillir et à codifier l'état de l'art dans ce domaine - et en particulier au travaux si importants du sous-comité 7 " Software Engineering " de l'ISO/IEC JTC1 ? Il semble bien que non, et que la plupart du temps nous nous contentions d'y jouer un rôle d'observateurs, ce qui est bien insuffisant pour un pays tel que le nôtre. Il est vrai que, grâce essentiellement aux efforts de l'AFNOR, la substance de ces travaux est assez bien diffusée à l'intérieur du tissu industriel français. Mais il ne suffit pas d'être au courant. Nous devons en tirer toutes les conséquences qui s'imposent pour le maintien de la compétitivité internationale de nos industriels et la meilleure satisfaction de nos donneurs d'ordre.
Une coordination entre tous (donneurs d'ordres et industriels grands et petits) est certainement indispensable. Il est sans doute regrettable que n'existe pas en France de point focal analogue à ce que peuvent être aux États-Unis le SEI et au Canada le Centre de Génie Logiciel Appliqué de Montréal. La récente création à Bilbao d'un European Software Institute se propose à l'évidence de constituer un tel point focal à l'échelon européen. Mais l'existence d'un relais français, si modeste fût-il, paraît nécessaire, ne serait-ce que pour servir d'" interface culturelle " et coordonner une politique systématique de traduction en français des textes les plus essentiels. Puisque - c'est un fait - la communauté logicielle internationale parle anglais et que - c'est un autre fait - les entreprises françaises (tout au moins celles qui n'ont pas une vocation internationale très prononcée) ont en général des difficultés à travailler directement sur les originaux.
Le rôle de l'enseignement supérieur est aussi à souligner. Dans les pays anglo-saxons (et dans ceux qui ont fait du logiciel une de leurs priorités) il joue un rôle majeur dans l'entretien et la diffusion d'une culture logiciellesolide. En France il paraît, tout au moins dans le domaine qui nous occupe ici du management et de la maîtrise du développement logiciel, jouer un rôle par trop discret.
C'est donc un triple partenariat entre donneurs d'ordres, industriels et enseignement supérieur, autour probablement d'un pôle institutionnel à créer, qu'il nous faut travailler à constituer au plus vite, si nous ne voulons pas qu'on puisse dire bientôt, pour parodier le mot fameux de madame du Barry : La France, ton logiciel f... le camp !
J'espère avoir, par cet exposé, fait partager au lecteur une double conviction : (1) qu'il n'est pas encore trop tard pour agir, et (2) qu'il est néanmoins urgent d'agir. Les Chinois ont pour caractériser ce genre de situation une formule qui m'enchante et que vous me permettrez de citer en guise de conclusion :
Quand une brebis est perdue, il n'est pas trop tard pour réparer l'enclos.
D'après Daniel M. Roy (Software Engineering Institute) Ingénierie logicielle. Une vue depuis les USA, présentation faite au groupe SPIN-France, le 21 mars 1995
Chiffres de 1993. D'après Jones, Capers, Software Productivity and Quality Today: The Worldwide Perspective, Information Systems management Group, 1994
Lloyd K. Mosemann, deputy assistant secretary of the Air Force, "Predictability", CrossTalk, The Journal of Defense Software Engineering, août 1994. Le magazine CrossTalk est consultable sur le serveur Internet du Software Technology Support Center de l'Air Force. Sur ce même serveur on pourra aussi trouver l'énorme document Guidelines for the Successful Acquisition of Software Intensive Systems: Weapon Systems, Command and Control Systems, Management Information Systems ( 2 vol.), destiné à l'Air Force et à ses fournisseurs et, au-delà, à l'ensemble de l'industrie américaine du logiciel.
Crée en 1984 par le DoD, le SEI dispose d'un budget annuel de l'ordre de 35 millions de $, fournis pour l'essentiel par le DoD. Les quatre zones d'"impact technique" qui lui ont été assignées par le DoD sont les suivantes :
Liste annotée des publications du SEI
Obtenir des copies papier des documents SEI
Dès 1987, suite à une commande de l'Air Force, le SEI publiait A Method for Assessing the Software Engineering Capability of Contractors. La méthode comportait un questionnaire et un classement en cinq niveaux dits de maturité, mais le modèle sous-jacent n'était pas encore explicité. En 1991 paraissaient les documents-clé
où le modèle était décrit en grand détail. Le modèle a connu une première révision en 1993 et une seconde est prévue.
Lancé en juin 93 sous l'égide de l'ISO/IEC JTC1/WG10, le projet international SPICE s'est donné pour tâche de perfectionner le modèle SW-CMM et d'en faire une norme internationale. Il a remis à l'ISO/IEC en juin 1995, pour mise à l'enquête, un ensemble de neuf documents couvrant tous les aspects de l'évaluation et de l'amélioration des processus de développement logiciel. En janvier 1995 le projet SPICE est entré en phase d'expérimentation sur le terrain des documents qu'il a produit. Une refonte est actuellement en cours pour rendre le modèle plus compatible avec l'ISO 12207, et pour établir un pont avec les modèles précédemment utilisés (SW-CMM, Trillium, Bootstrap...).
Voir par exemple : Canadian National Body, Analysis of Implementation Difficulties with ISO 9001 and ISO 9000-3 Standards for Software Engineering, ISO/IEC JTC1/SC7 N1108, 29 juin 1993
Voir SEI, A Systems Engineering Capability Maturity Model, Version 1.1, Pittsburgh, Carnegie Mellon University, 1995 ; A Description of the Systems Engineering Capability Maturity Model Appraisal Method, Version1.1, Pittsburgh, CMU, 1995 ; Relationships Between the Systems Engineering Capability Maturity Model and Other Products, Version 1.0, Pittsburgh, CMU, 1994. Tous ces documents sont disponibles sur le serveur Internet du SEI (sei.cmu.edu). Le SEI travaillerait également à un Integrated Product Development CMM (IPD-CMM), lui aussi fondé sur les concepts SPICE.
Voir ISO/IEC JTC1/SC7, Project Requirement Document. Standard for System Life-Cycle Processes, 8 juin 1995. Cette décision fait suite aux conclusions d'un groupe de travail ad hoc présidé par le Dr Raghu Singh du DoD, le " père " de la 12207. (Voir ISO/IEC JTC1/SC7, Report of the JTC1/SC7 Ad Hoc Study Group on Software-System Relationships, 3 mars 1995.)
Voir en particulier Philippe Larvet, L'Analyse orientée-objet des systèmes complexes, Nanterre, Arche SQL SA, 1994.
Voir :
Ces deux normes ont été annulées et remplacées par la MIL-STD-498
ISO/IEC 12207, Technologies de l'information -Processus du cycle de vie des logiciels, 1re édition, août 1995. Cette norme décrit, à haut niveau, l'ensemble des processus qui concourent à la réalisation d'un logiciel. D'autres normes à paraître dans la même série décriront de façon plus détaillée certains de ces processus : gestion de configuration, gestion de projet, assurance qualité, vérifications et validations, revues formelles et audits, maintenance...
Compte tenu de la politique actuelle du DoD d'abandon progressif, dans la mesure du possible, des normes purement militaires, la MIL-STD-498 Software Development and Documentation, n'a été adoptée officiellement par le DoD, en décembre 1994, que pour une période transitoire de deux ans. Entretemps, en octobre 1994, un groupe de travail a été consititué dans le but d'en faire une norme civile aux États-Unis, harmonisée avec l'ISO 12207, sous la désignation IEEE-1498/EIA-640. Dans un troisième temps cette norme sera ramenée à une simple " surcouche " de l'ISO 12207 : elle prendra alors la dénomination ANSI 12207/IEEE 1498/EIA 640
Sur chaque site évalué le SEI a d'ailleurs suscité la création d'un SEPG (Software Engineering Progress Group). Les SEPG tiennent congrès chaque année et sont en relation permanente par l'intermédiaire du réseau SPIN (Software Process Improvement Network).
Pour une évaluation chiffrée des " retombées ", voir Herbsleb et al.,Benefits of CMM-Based Software Improvement: Initial Results, Pittsburgh, SEI, août 1994 (CMU/SEI-94-TR-13).
En septembre 1995, avaient été rapportées au SEI 515 évaluations (dont 63 réévaluations) portant sur un total de 440 organisations (dont 16 % hors USA) appartenant à 114 compagnies. Ces organisations se situaient comme suit : niveau 1 : 70,2 % ; niveau 2 : 18,4 % ; niveau 3 : 10,2% ; niveau 4 : 1 % ; niveau 5 : 0,2 %. Ces chiffres ne tiennent pas compte des très nombreuses auto-évaluations dont le SEI n'a pas eu connaissance.
Un groupe SPIN France est déjà en activité (principaux participants : Alcatel, Bull, Cegelec, Dassault, Schneider, Snecma, Thomson-CSF...)
Initiative dont le CGLA (Centre de Génie Logiciel Appliqué) de Montréal, homologue et partenaire officiel du SEI au Canada, a assuré avec beaucoup d'efficacité la maîtrise d'oeuvre. Voir :
Ces traductions sont disponibles sur le serveur Internet du CGLA
Voir Watts Humphrey,
Développé également par le SEI, mais à ma connaissance non encore paru.
Voir EDI World Institute, CALS Capability Model. Draft Proposal, Montréal, février 1995
Développé par MITRE Corp.
Lors de la dernière réunion plénière (26-31 mai 1996, à Prague, Rép. tchèque) du SC7 la France était représentée par 11 personnes, soit 7 % du nombre total de délégués. A titre de comparaison les chiffres de participation des autres nations étaient les suivants : États-Unis : 32 ; Australie : 15 ; Royaume-Uni : 17 ; Japon : 14 ; Canada : 19...
(A noter toutefois que ces chiffres marquent un net progrès par rapport à la réunion précédente, où la France ne représentait que 3 % des participants
Saluons néanmoins la récente création, au sein du CNAM, du Centre d'études pour l'Ingénierie et de Management du Logiciel (CIML)
Wang yang bu lao
Voir Situ Tan, Best Chinese Idioms, Hong Kong, Hai Feng Publishing Co, 1984, p. 13)