Les connaissances fondamentales en maintenance du logiciel Dans ce chapitre, nous couvrons : Les connaissances fondamentales du domaine ; La représentation SWEBOK de la maintenance ; Les références importantes du domaine.
2 Améliorer la maintenance du logiciel Le développement de logiciels, lorsqu il est mené à terme avec succès, se termine par la livraison d un logiciel qui devrait satisfaire les exigences initiales du client. Par la suite, après sa mise en service, le logiciel devra évoluer pour répondre aux nouveaux besoins d un environnement en constante évolution. De plus, c est pendant l opération du logiciel que l organisation découvrira des anomalies, ainsi que de nouveaux besoins d affaires qui feront surface, et qu il faudra, après un certain nombre d années, en modifier la plate-forme technologique. Enfin, il est bon de souligner que le cycle de vie de la maintenance ne devrait pas débuter lors de la mise en service du logiciel, mais, en réalité, bien avant par une participation active des responsables de la maintenance tout au long du processus de développement, quand c est possible. Jusqu à tout récemment, le thème de la maintenance était peu abordé dans les cursus universitaires d informatique et de génie logiciel, et c était en travaillant dans les organisations elles-mêmes que les ingénieurs logiciels s initiaient aux spécificités de la maintenance et y développaient une expertise spécifique. Ce livre vise à combler un vide important dans l enseignement de la maintenance. La maintenance du logiciel est un des dix grands thèmes de connaissance reconnus comme faisant partie de la discipline de l ingénierie du logiciel, tel que cela a été décrit dans ISO TR 19759, ainsi que dans le guide au corpus des connaissances en génie logiciel [Abr05] (Software Engineering Body of Knowledge SWEBOK). Ces documents confirment ce qui avait déjà été identifié par Victor Basili en 1996 : «La maintenance du logiciel est un domaine spécifique du génie logiciel, et conséquemment, il est donc nécessaire de se pencher sur des processus et les méthodologies qui tiennent compte des caractéristiques spécifiques de la maintenance du logiciel.» [Bas96]. Dans le Guide SWEBOK (disponible au www.swebok.org), l éditeur du chapitre de la maintenance est Thomas Pigoski ; et le coéditeur, Alain April. Il est à noter que M. Pigoski a piloté le développement de la norme internationale ISO 14764 sur la maintenance du logiciel. Il est à noter également que plusieurs des concepts utilisés dans le modèle de la maturité de la maintenance SP3mP (Software Maintenance Maturity Model) ont été incorporés à la version 2005 du Guide SWEBOK. Le modèle de maturité de la maintenance SP3mP s aligne donc, dans toutes ses perspectives, sur l ensemble des connaissances décrites dans le chapitre Maintenance du Guide SWEBOK. Le Guide SWEBOK présente une taxonomie des connaissances nécessaires à l ingénieur logiciel travaillant en maintenance du logiciel (figure 1.1). Cette taxonomie de la maintenance comprend quatre axes : Concepts de base ; Processus de la maintenance ; Préoccupations clés de la maintenance ; Techniques de maintenance.
1 Les connaissances fondamentales en maintenance du logiciel 3 Faites la lecture du Guide SWEBOK pour approfondir vos connaissances en maintenance du logiciel. Figure 1.1 Taxonomie de la maintenance du logiciel selon le Guide SWEBOK [Abr05] La littérature sur la maintenance du logiciel est beaucoup moins abondante que celle sur le développement du logiciel [Pig97, s2]. Les livres les plus récents sont ceux de Khan et Zhang [Khao5], Polo, Piattini et Ruiz [Pol02], de Grubb et Takang [Gru03] et de Seacord et al. [Sea03]. D ailleurs, les publications en maintenance souvent citées dans les articles scientifiques ont été publiées il y a 15 ans, ou parfois même il y a 25 ans (Lientz et Swanson 1980 ; Martin et McClure 1983 ; Arthur 1988). Certains autres livres ne font qu introduire la thématique de la maintenance du logiciel (Boehm [Boe81], Dorfman et Thayer [Dor02], Pfleeger [Pfl01], Pressman [Pre05]).
4 Améliorer la maintenance du logiciel 1.1 LA DÉFINITION DE LA MAINTENANCE DU LOGICIEL Le cycle de vie du logiciel peut être divisé en deux parties distinctes selon Moriguchi [Mor96, s19.1] : 1. Le développement initial du logiciel ; 2. La maintenance et l opération du logiciel. Un survol des définitions proposées pour la maintenance du logiciel est présenté au tableau 1.1 : Tableau 1.1 Les définitions généralement acceptées de la maintenance du logiciel Définition - Interprétation Auteurs des références Année «Les changements qui doivent être effectués à un logiciel après sa livraison à l utilisateur.» «L ensemble des activités requises afin de garder le logiciel en état d opération suite à sa livraison opérationnelle.» «La maintenance couvre le cycle de vie du logiciel à partir de son installation jusqu à sa mise à la retraite.» «La modification d un logiciel, après sa livraison, afin de corriger des défaillances, d améliorer sa performance ou d autres attributs ou de l adapter suite à des changements d environnements.» «Les changements au logiciel et à sa documentation causés par un problème ou le besoin de l améliorer.» «La totalité des activités qui sont requises afin de procurer un support, au meilleur coût possible, d un logiciel. Certaines activités débutent avant la livraison du logiciel, donc pendant sa conception initiale, mais la majorité des activités ont lieu après sa livraison finale (l équipe de développement ayant maintenant terminé son travail et étant affectée à d autres travaux).» Martin et McClure [Mar83] 1983 FIPS [FIP84] 1984 Von Mayrhauser [Von90] 1990 IEEE 610.12 [IEEE90] 1993 ISO12207 [ISO95] 1995 SWEBOK [Abr05, s3.1.1] 2005 Lehman mentionne d autre part que «les changements étant inévitables, ils forcent les logiciels opérationnels à évoluer, sinon ils deviennent progressivement moins utiles et désuets» [Leh80]. Il s ensuit que la maintenance est donc considérée comme inévitable pour les logiciels opérationnels utilisés quotidiennement dans nos organisations. Il est important de préciser que la maintenance du logiciel est nécessaire autant pour les logiciels applicatifs que pour les logiciels d infrastructure (par exemple : de télécommunications, de systèmes d opérations et de gestion des bases de données). Le logiciel applicatif, lui, contient
1 Les connaissances fondamentales en maintenance du logiciel 5 des règles d affaires traduites et insérées dans les fonctionnalités du logiciel. Ce sont ces règles d affaires qui évoluent, changent et disparaissent pour supporter les opérations quotidiennes des organisations. La maintenance du logiciel est définie dans la norme IEEE pour la maintenance du logiciel, IEEE 1219 [IEEE98], comme la modification d un logiciel après la livraison pour corriger les fautes, pour améliorer la performance ou les autres attributs, ou pour adapter le produit à un environnement modifié. La norme couvre aussi les activités d avant la livraison, mais seulement dans un appendice d information de la norme. La norme ISO 12207 pour les processus de cycles de vie décrit essentiellement la maintenance comme l un des processus de cycles de vie primaires et aussi comme le processus d un produit logiciel subissant «une modification du code et de la documentation associée due à un problème ou au besoin d amélioration. L objectif est de modifier le produit logiciel existant tout en préservant son intégrité.» [ISO95]. ISO 12207 décrit aussi «l implémentation de processus». Cette activité établit le plan de maintenance et les procédures qui sont utilisées plus tard, durant le processus de maintenance. ISO 14764 [ISO98], la norme internationale pour la maintenance du logiciel, définit la maintenance du logiciel dans les mêmes termes que l ISO 12207 et met l accent sur les aspects de prélivraison de la maintenance, la planification par exemple. Un mainteneur est définit par l ISO 12207 comme une organisation qui effectue des activités de maintenance [ISO95]. Finalement, ISO 12207 identifie les activités primaires de maintenance du logiciel comme l implémentation de processus, l analyse de problème et de modification, l implémentation de modification, la révision ou l acceptation de maintenance, la migration et la mise à la retraite. Ces activités sont discutées dans une section ci-après. Elles sont définies plus en détail dans la norme ISO 12207. 1.2 LES DIFFÉRENCES ENTRE OPÉRATIONS, DÉVELOPPEMENT ET MAINTENANCE Il est tout d abord nécessaire d établir une distinction claire entre l opération d un logiciel et sa maintenance [ISO98, s1]. Ainsi, il est précisé dans la norme ISO 14764 que les activités d opération (copies de sécurité, recouvrement et administration des ordinateurs) sont effectuées par le personnel d opération des systèmes informatiques et sont exclues de la portée de la norme ISO sur la maintenance des logiciels. Cette distinction de concepts est aussi exprimée dans la littérature qui décrit qu il est peu commun qu un gestionnaire confonde les opérations informatiques et la maintenance des logiciels. Il existe une interface importante entre la maintenance et les opérations qui vise surtout à s assurer que les infrastructures, qui supportent les logiciels applicatifs, soient opérationnelles et efficaces (gestion des changements,
6 Améliorer la maintenance du logiciel appels concernant une défaillance en production, recouvrement du logiciel et des données, et reprise des travaux suite à une panne ou à un désastre, investigation des temps de traitements, copies de sécurité, gestion des systèmes d horaires automatisées, gestion de l espace disque et de bandothèques) [ITi01]. La gestion de cette interface est un rôle unique de mainteneurs. Qu en est-il des différences entre la maintenance et le développement du logiciel? Le développement du logiciel possède, lui aussi, une interface avec la maintenance, mais elle est un peu plus difficile à différencier [Abr05, s3.2.2]. Cette différenciation est encore plus difficile à observer si, dans une organisation, le développeur du logiciel effectue aussi la maintenance de celui-ci. En effet, un certain nombre des activités de la maintenance sont similaires à celles du développement de logiciels (analyse, conception, codage, gestion de la configuration, essais, revues et documentation technique). Ces activités doivent toutefois être adaptées au contexte spécifique de la maintenance, où le travail est souvent effectué par un ou deux programmeurs pour des travaux exécutés à très court terme, et non par une équipe de projet comme dans la majorité des projets de développement. Un employé de la maintenance du logiciel développera donc une partie de son expertise à partir des mêmes sources d enseignement et de formation que ses collègues du développement. Quelques auteurs ont étudié les activités qui sont uniques à la maintenance et qui ne se retrouvent pas dans un cycle de vie de développement de logiciels. Certaines des caractéristiques qui sont propres au domaine de la maintenance du logiciel sont [Abr93] : «les requêtes de modifications (RM) parviennent d une manière plus ou moins aléatoire et ne peuvent pas être planifiées individuellement dans un processus annuel de budgétisation ; les RM sont évaluées et classées par ordre de priorité (par le programmeur ou son patron, ou parfois par un comité de priorités) ; aucune RM ne fait l objet d une autorisation spécifique par un gestionnaire en chef ; la charge de travail de la maintenance n est pas gérée par des techniques de gestion de projet, mais plutôt par l utilisation des techniques de gestion des files d attente, souvent supportées par un logiciel de bureau d aide help desk ; la taille et la complexité des requêtes de la maintenance font en sorte que le travail peut être, généralement, effectué par un ou deux programmeurs ; les travaux sont ordonnés de manière à satisfaire l utilisateur, à court terme, et à s assurer du bon fonctionnement quotidien des logiciels en opérations ; les priorités peuvent changer rapidement, à toute heure du jour, et les rapports de problèmes (RP) nécessitant des corrections de l application de production auront la priorité sur n importe quel autre travail en cours.»
1 Les connaissances fondamentales en maintenance du logiciel 7 L équipe de maintenance doit faire face aux événements et aux requêtes journalières de sa clientèle tout en maintenant un service continu des applications opérationnelles sous sa responsabilité. Figure 1.2 Processus d acceptation ou de refus du travail de la maintenance [Apr01] L organisation des travaux de maintenance doit tenir compte de ces impératifs, et tant les travaux que l équipe de maintenance doivent se structurer pour répondre aux exigences de ce type de travail dont les éléments individuels arrivent de façon aléatoire. Par contraste, un projet de développement est prévu à plus long terme, planifié, typiquement créé avec un échéancier déterminé, puis s achève avec la livraison du logiciel. Pour bien mener à terme un projet, une structure d équipe de projet est créée pour la durée du projet seulement, et c est cette équipe de projet qui développe un plan de ressources qui vise à atteindre des objectifs fixes d une livraison dans les limites du délai planifié de fin du projet. Lorsque l utilisateur fait une requête de modification, il est nécessaire d estimer l effort qui sera requis pour modifier le logiciel existant. L étude de Dorfman et de Thayer [Dor02] indique que les requêtes de modification (RM) passent par une étape d investigation et d impact qui est unique à la maintenance du logiciel. Si l effort estimé est peu élevé et peut être satisfait à l intérieur des ressources et des disponibilités de l équipe de maintenance, la requête est alors placée en ordre
8 Améliorer la maintenance du logiciel de priorité et exécutée à partir du processus de la gestion de la file d attente. Toutefois, si l effort estimé est supérieur à une limite établie, propre à chaque organisation, et à sa marge de manœuvre budgétaire, la requête sera réacheminée à une équipe de développement et traitée comme un petit projet qui devra être autorisé avec son budget spécifique et une allocation précise des ressources requises pour le mener à terme en fonction des nouveaux objectifs fixés. Il y a donc, pour la maintenance du logiciel, un processus unique d acceptation ou de rejet du travail, pour les requêtes de modifications (RM) des logiciels opérationnels. Ce processus tient compte de la taille estimée de la modification et de la capacité à la réaliser à l intérieur des contraintes de coûts et de qualité de fonctionnalité. April [Apr01] présente comme exemple le processus utilisé par une société membre de Cable & Wireless, où l effort maximal d une requête adaptative qu un programmeur de la maintenance accepte est de cinq jours (figure 1.2). On y note que tout rapport de problème (RP), quel que soit l effort estimé, sera pris en charge par l équipe de maintenance en priorité avant les requêtes de modifications. Cette limite de cinq jours d effort est aussi reconnue par l association de la mesure du Royaume- Uni (UKSMA) et le groupe de normalisation de l étalonnage du logiciel (ISBSG) : «On observe dans la pratique la distinction entre l activité de maintenance des améliorations mineures et l activité de développement du logiciel. Les auteurs ont observé que quelques organisations possèdent des activités de maintenance qui comptent jusqu à 80 jours d effort, alors que dans d autres le seuil est de cinq jours. L ISBSG et l UKSMA adoptent, actuellement, la convention qu une amélioration de cinq jours ou moins sera considérée comme une activité de maintenance.» [ISB05]. Ce seuil correspond à de la petite maintenance effectuée par des individus, et non pas par des équipes de projet qui peuvent entreprendre de grands projets. Cette notion de seuil est très importante, car elle dicte le seuil des travaux entre les développeurs et les mainteneurs. Cette limite de cinq jours ne doit pas être utilisée avec dogmatisme. Ce qui est essentiel, c est qu une limite du travail de maintenance soit identifiée clairement dans l organisation, quelle que soit la valeur d effort choisie, et reflète bien le travail d individus, et non pas d équipes de projet. Bennett [Ben00] identifie d autres activités uniques à la maintenance : «l étude des différents types de requêtes de changements supportées par un centre d appel help desk et son logiciel de support, les activités d évaluation d impact d un changement, et la spécialisation en essais et vérification de régression». Zitouni [Zit96] identifie sept processus clés et certains rôles qui sont spécifiques de la maintenance du logiciel : «Gestion des requêtes de changement et de demandes de modifications. Un processus de gestion des problèmes utilisé par les mainteneurs pour établir la priorité, documenter et acheminer les demandes qu ils reçoivent [Ben00] ; Acceptation du logiciel ;
1 Les connaissances fondamentales en maintenance du logiciel 9 Gestion de la transition du développement au groupe de maintenance, qui est une séquence contrôlée et coordonnée d activités durant laquelle le système est progressivement transféré du développeur vers le mainteneur ; Rôle des utilisateurs, des opérations et des employés de la maintenance ; Planification de la maintenance ; Gestion des employés de la maintenance ; Gestion du logiciel (améliorations et performances).» La dernière version du chapitre de la maintenance du Guide SWEBOK identifie aussi un bon nombre de processus spécifiques à la maintenance, soit : Gestion et planification annuelle de la maintenance [Pig94 ; Zit96] ; Ententes de services et contrats spécifiques de la maintenance [Mue94 ; Apr01 ; Bou99 ; Mcb90 ; Mcb96 ; Kar05 ; COB00] ; Interception et surveillance des applications en production (prévention de problèmes) [ITI01] ; Mesure d indicateurs de services spécifiques aux activités du support et de la maintenance [Abr91 ; Abr93 ; Sta94 ; McG01] ; Soutien à la clientèle (système de réponses aux problèmes) concernant une panne, une maintenance préventive et un retour en service après panne [Apr01] ; Études de différents types de requêtes de changements supportées par un centre d appel help desk et son logiciel de support [Ben00] ; Activités d évaluation d impact d un changement [Ben00] ; Spécialisation en essais et en vérifications de régression [Ben00] ; Investigations et réponses aux questions concernant les règles d affaires des systèmes opérationnels [Pre05 ; Apr01] ; Processus unique d acceptation et de rejet du travail, pour les requêtes de modifications (RM) des logiciels opérationnels selon leur taille [Apr01] ; Gestion de l horaire de support aux opérations 24 heures sur 24 et du processus d escalade en cas de problèmes [ITi01 ; Mcb90 ; Mcb96] ; Gestion de l interface et du rôle des opérations portant sur : la gestion du changement, les appels concernant une faute en production, le recouvrement de l environnement et des données suite à un désastre, le recouvrement des données et reprise des travaux, l investigation des temps de traitements, les cédules automatisées, les copies de sécurité, la gestion des systèmes, de l espace disque et de la bandothèque [ITi01] ;
10 Améliorer la maintenance du logiciel Gestion de la sous-traitance, des contrats de services de maintenance, de licences, d entiercement et d impartition [Car94 ; Apr01 ; McC02] ; Obligation de rendre le portefeuille d application plus performant (gestion du logiciel) [Zit96]. La définition du service rendu par la maintenance peut aussi aider à identifier des différences avec les autres activités informatiques. Ainsi, Bouman [Bou99] décrit la maintenance du logiciel comme un service. Les caractéristiques d un service peuvent généralement être reconnues ainsi : «L insistance de la vente directe avec le client ; Un contact fréquent et direct avec le client ; Un service rendu immédiatement plutôt que plusieurs mois après ; Un temps de service court ; Le produit n est pas toujours un bien physique ; Le produit ne peut pas toujours être remisé ou transporté ; Les services sont plus spécialisés et façonnés que les biens physiques.» En résumé, la maintenance du logiciel possède un certain nombre de processus et d activités qui ne sont pas effectués par les groupes de développement du logiciel. La maintenance du logiciel fait aussi appel à des processus et à des activités du développement du logiciel, et ce, plus particulièrement dans l étape d implémentation d une modification au logiciel existant [ISO95, s5.5.3]. 1.3 QUELLE ORGANISATION EFFECTUE LA MAINTENANCE DU LOGICIEL? Les aspects organisationnels décrivent comment identifier quelle organisation ou quelle fonction de l entreprise sera responsable pour la maintenance du logiciel. L équipe qui développe le logiciel n est pas toujours assignée à sa maintenance. Pour décider où la fonction de maintenance sera localisée, les organisations d ingénierie logicielle peuvent, par exemple, demeurer avec le développeur original ou s adresser à une équipe indépendante spécialisée en maintenance. Souvent l option du mainteneur spécialisé est préférée. Il y a beaucoup d arguments pour et contre chacune de ces deux options [Par83 ; Pig97] ; la décision devrait être prise en étudiant chaque cas. L important, c est que la délégation ou l assignation de la responsabilité à un groupe ou à une personne [Pig97], quelle que soit la structure de l organisation, soit claire, planifiée et bien communiquée. Dans l industrie, on peut retrouver deux modèles organisationnels pour la fonction de maintenance du logiciel. Dans un premier modèle organisationnel, c est le développeur, qui a développé ou acquis le logiciel, qui en effectue la maintenance. Dans un second modèle, c est
1 Les connaissances fondamentales en maintenance du logiciel 11 l organisation de la maintenance du logiciel qui effectue la maintenance des logiciels de l organisation, et ce, indépendamment des développeurs. Bennett [Ben00] énonce que le développement logiciel initial est habituellement basé par projet, avec une période de temps et un budget défini. L accent est mis sur la livraison dans les délais et dans le budget pour remplir les besoins de l utilisateur. En contraste, la maintenance de logiciel a souvent comme objectif de s assurer de l adaptabilité du logiciel aux changements nécessaires. La maintenance corrige les pannes et s assure de satisfaire la demande de l utilisateur pour des mises à jour et des améliorations. Le retour sur investissement des activités de la maintenance est souvent difficile à démontrer clairement, donc la vue par les gestionnaires en chef est souvent celle d un centre de coûts consommant de grandes ressources sans grands bénéfices, pour l organisation. Certaines organisations vont opter pour laisser les développeurs maintenir les logiciels. Il est clair que le personnel de développement du logiciel n aime pas faire sa maintenance. La maintenance n est pas souvent vue comme un travail séduisant. Deklava fournit une liste de problèmes liés au personnel basée sur des données de sondage [Dek92]. Le personnel de maintenance est souvent vu comme des citoyens de seconde classe [Lie81], et peu de développeurs aiment ce travail. Pigoski décrit ces deux modèles organisationnels plus en détail, de même que leurs avantages et désavantages respectifs [Pig97]. Par exemple, il y a un certain nombre de désavantages à laisser l équipe de développement maintenir le logiciel à la suite de sa mise en production. Ces désavantages sont : 1. «Les développeurs n aiment pas effectuer la maintenance et sont plus enclins à quitter la société pour du travail plus intéressant ; 2. Les nouveaux employés embauchés dans l équipe de développement seront surpris et insatisfaits de voir qu ils doivent aussi maintenir les logiciels existants ; 3. Les experts développeurs sont souvent réassignés à d autres projets de développement et préfèrent le développement à la maintenance ; 4. Lors du départ de l expert qui a développé le logiciel, les autres employés ne seront probablement pas qualifiés, initialement, pour maintenir le logiciel.» De plus, il y a une perception de manque de transparence dans les organisations de développement qui effectuent leur propre maintenance, avec comme conséquence une perception générale que les logiciels livrés sont de faible qualité et ne sont pas documentés adéquatement, laissant peu de flexibilité pour le transfert des connaissances et la rotation des programmeurs de la maintenance.