Agilité

L'évolution contrdlée du logiciel 1 L'évolution contrdlée et I'agilité
© Edition Smart, Montréal, 30 aout 2023
info@editionsmart.com
Table des matiéres
ISBN 978-2-9821954-3-1
1 L’évolution contrélée et I'agilité. 8
11 Introduction
12 Modéle de cycle de vie agile 9 9 JIL I
1.3 Quelle organisation effectue I'évolution contrdlée du logiciel ?.. Tous droits réservés. Aucune partie de cette publication ne peut étre reproduite,
14 Le modéle agile du DevOps et I'évolution contrdlée .. stockée dans un systéme de récupération ou transmis, sous quelque forme ou par
15 L'évolution du logiciel dans un cadre agile...
quelque moyen que ce soit, électronique, mécanique, photocopie, enregistrement ou
autre, sauf dans la mesure permise par la loi. Pour obtenir la permission de réutiliser
2 Les en du 40 le matériel de ce titre, contactez info@editionsmart.com.
21 Introduction 41
Limite de responsabilité/Exclusion de garantie. Bien que Iéditeur/les auteurs ait fait
22 La définition d' lion du logiciel de leur mieux pour préparer ce livre, ils ne font aucune représentation ou garantie
23 Les différences entre opérations, développement et maintenance. quant a exactitude et a lexhaustivité du contenu de ce livre et déclinent
spécifiquement toute garantie, y compris, sans limitation, toute garantie implicite de
24 Les normes d'évolution du logiciel 48 qualité marchande ou d’adéquation de son contenu dans un but particulier. Aucune
25 L'activité d'évolution du logiciel 51 garantie ne peut étre générée ou étendue par la vente de ce livre. Le fait qu'une
organisation, un site Web ou un produit soit mentionné dans ce livre, par exemple
3 Les pi i d i inue du par une citation et/ou une référence a une source potentielle dinformations
31 Les problémes d'évolution continue du logiciel ..... supplémentaires ne signifie pas que l'éditeur et les auteurs approuvent les
32 Le modéle de mesure
informations ou les services de ces organisations, site Web ou des produits ou des
recommandations quils peuvent faire ou fournir. Ce livre est vendu étant entendu
33 La mesure du processus d'évolution d'un logiciel .... que l'éditeur n'est pas engagé dans une prestation de services professionnel. Les
34 La mesure du code source . conseils et stratégies contenus dans ce livre peuvent ne pas convenir a votre situation.
Vous devriez consulter un spécialiste le cas échéant. De plus, les lecteurs doivent étre
3.5 Lamesure du service 81 conscients que les sites Web répertoriés dans cet ouvrage peuvent avoir changé ou
4La pi d'un disparu entre le moment ou ce livre a été écrit et celui ou il a été lut. Ni léditeur ni
les auteurs ne seront responsables de toute perte ou profit ou de tout autre dommage
41 Introduction commercial, y compris, mais sans sy limiter, les dommages spéciaux, accessoires,
42 Les objectifs de la compréhension du logiciel consécutifs ou autres.
4.3 Le mainteneur et ses besoins d'i De plus, le Code de la propriété intellectuelle n’autorise, que les « analyses et les
44 Les modéles de compréhension du logiciel courts extraits/citations dans un but d’exemple ou dillustration ». De plus, ces
45 Le modéle mental extraits doivent étre « partiels, justifiés et clairement attribués a l'auteur ».
46 Les stratégies de compréhension de logiciels......... Utilisations interdites de la version électronique du livre. Quand vous achetez une
47 Les techniques de lecture du logiciel licence de version électronique du lire (sur YUPUB a
48 Les facteurs qui ont un impact sur la compréhension
https://editionsmart.yupub.dev), pour une période limitée, vous, le Licencié doit
s'assurer qu'il est le seul utilisateur autorisé et ne doit pas :
5 La réingénierie d'un logiciel exi - partager son identifiant et mot de passe avec une autre personne ;
- ouvrir plus d'une session sur différents ordinateurs ;
5.1 Introduction - supprimer ou modifier les noms des auteurs ou les avis de droit d'auteur de Iéditeur
5.2 Les niveaux d'abstraction du logiciel ou d'autres moyens d'identification ou de non-responsabilité tels qu'ils apparaissent
53 Le but et les objectifs de la réingénierie du logiciel .
dans les éléments sous licence ;
- imprimer ou faire systématiquement des copies électroniques de plusieurs extraits
54 Les techniques de réingénierie du logiciel... des éléments sous licence, y compris des livres électroniques complets, a quelque fin
A1 Bibl
que ce soit ;
©2023 Edition Smart, 2023 - Tous droits réservés 3

L'évolution contrdlée du logiciel Avant-propos
- télécharger ou distribuer toute partie du matériel sous licence ou fournir des

identifiants d’accés ou des informations de connexion permettant Paccés au matériel AVANT —PROPOS
sous licence par toute personne non autorisée sur tout réseau électronique, y
compris, sans sy limiter, Internet et le Web, autrement que via le réseau sécurisé tel Ce livre i it les de I'évolution continue et de la
quautorisé par ie présent accord ; oa du logiciel. Ce livre sinscrit dans le cadre dune problématique globale portant sur
- tenter de décompiler, désassembler, en faire la rétro-ingénierie ou autrement réduire i ité des processus d'évolution du logiciel dans un contexte agile
a une forme perceptible par 'humain tout ou une partie du matériel sous licence ingénicurs logiciels sont déchirés entre les taches de développement,
et/ou des services en ligne. dentretien/support et de réingénierie constantes des produits logiciels en production.
Avec ce livre, nous tentons de rapprocher les praticiens, les étudiants et les chercheurs
Le Licencié doit faire en sorte qu’aucune autre personne n’ait accés aux Matériels en offrant les connaissances a maitriser dans le travail quotidien.
sous Licence et/ou aux Services en Ligne sans l'accord écrit préalable de Iéditeur et
doit s’assurer de ne pas : QUALIFICATIONS PREALABLES
- utiliser tout ou partie du matériel sous licence pour un usage commercial ; Nous supposons que le lecteur posséde des connaissances de base en génie logiciel et en
- distribuer systématiquement ou autrement mettre a disposition tout ou partie des développement logiciel agile. Plus d'une ine d'années d'expérience en entrepri
Matériels sous licence a toute personne autre que les Utilisateurs autorisés ; nous ont convaincus de limportance d’appuyer la présentation des concepts avec des
- copier, dupliquer, publier, créer des ceuvres dérivées a partir de, recadrer, refléter, références et des exemples pratiques.
republier, télécharger, afficher, transmettre, distribuer ou mettre a disposition tout
ou partie des éléments sous licence (le cas échéant), du matériel basé sur les éléments CONTEXTE DE LA MAINTENANCE DES LOGICIELS
sous licence ou des ceuvres qui combinent les Matériels sous licence avec tout autre
matériel, sous quelque forme ou support que ce soit ou par quelque moyen que ce Dans le nouveau contexte compétitif global, les entreprises subissent de grandes
soit, autre que celui autorisé ; oil pressions de la part de leurs clients. Ces derniers sont de plus en plus exigeants et
- altérer, abréger, adapter ou modifier les Matériels sous licence. Pour éviter tout demandent, entre autres, des services de trés bonne qualité, 4 moindre cout et suivis d'un
doute, aucune modification des mots contenus dans les Matériels sous licence ou service aprés-vente défiant toute concurrence. Pour satisfaire la quantité, la qualité et les
leur commande n'est autorisée. délais, lentreprise doit disposer de logiciels de support pour ses activités fiables, et ceux-
ci doivent donc étre bien entretenus.
Finalement, le Licencié reconnait et accepte que léditeur et/ou ses concédants Effectuer et gérer lévoluti inue des logiciels opé de lentreprise n'est pas
détiennent tous les Droits de propriété intellectuelle sur les Services en ligne et les une tache facile. Bien que les normes de la maintenance définissent des fagons de faire
Contenus sous licence. L'achat en ligne ne transfére pas la propriété ni n'accorde au pour maximiser la les gesti es et les és sont pri
Licencié de droits supplémentaires sur les Droits de propriété intellectuelle incorporés laissés a émes pour décider améliorer la ion. Ils font face a
dans les Services en ligne ou les Contenus sous licence. problémes, tels que :
+ Lintroduction de I'agilité qui force le développement et I'entretien/support et
réingénierie tout en méme temps,
«les couts croissants des services de dé logiciel,
«la sous-traitance et I'impartition des logiciels,
« la perception de la lenteur de service,
«les problémes techniques.
De plus, les organisations n'ont actuellement accés qua trés peu d'outils d’évaluation de
la meilleure stratégie a mettre en ceuvre pour l'amélioration des activités spécifiques de
leurs équipes de logiciel. Clest & cette problématique d’'amélioration en industrie des
pratiques d’évolution continue et de maintenance que nous proposons des solutions dans
ce livre.
Voici -unes des i ées dans ce livre et nous
des éléments de réponse :
«+ Quels sont les processus, les pratiques et les activités d%évolution continue
du logiciel et de 'amélioration du logiciel ?
«Est-ce que les normes et les modéles actuels de l'amélioration du logiciel
tiennent suffisamment compte des spécificités uniques a Iévolution continue
des logiciels dans les projets agiles?
. Cc t répondre aux gestionnaires et leurs és lors de la mise en
ceuvre d'un programme d’amélioration du processus logiciel ?
© 2023 Edition Smart, 2023 - Tous droits réservés 5

L'évolution contrélée du logiciel Avant-propos
une des i de la réingénierie du logiciel peut étre utile pour extraire

des représentations des données, de la conception et de l'architecture d'un logiciel
ORGANISATION DU LIVRE existant. Ce chapitre décrit le but et les objectifs de: lingénieric inverse, la
Le livre est découpé en cinq chapitres afin d’en faciliter I'enseignement en une mi-session on, le r de on et des exi etde la restr i
de six séances de cours. De plus, ce livre denseignement tente de couvrir lensemble des du code source. Une courte ése du i des outils d'é dela
de 'évolution du logiciel identfés dans la nouvelle version qualité du code source est aussi présentée.
du guide SWEBOK |. ineering Body of Knowledy
Chapitre 1: Lévolution controlée du logiciel

Ce chapitre traite de la question de I'agilité en maintenance logicielle. Parfois nommée la
maintenance agile ce n'est pas tout a fait le cas ici, car ce sont pluto des développements
itératifs qui des activités de mai lors du dé et parfois
des itérations entiéres consacrées a effectuer de la réingénierie du logiciel. Dans ce
chapitre nous allons introduire les concepts d’agilité et de DevOps et discuter un peu plus
en détail de lorganisation du travail et de I'évolution du logiciel dans un cadre agile.
Chapitre 2 : Les connaissances fondamentales en évolution du logiciel

Ce chapitre présente une vue d' des ires pour I
logiciel spécialisé en maintenance du logiciel. C'est a partir de cette vue d’ensemble que
Je livre élabore chaque aspect et cite les références importantes afin d’approfondir chaque
sujet spécil Lil y est dé un des processus et des
pratiques de I'évolution continue du logiciel que tout ingénieur logiciel doit maitriser. Ce
chapitre présente aussi les normes principales d’évolution/maintenance ainsi que les
processus clés, et présente les catégories de travail
Chapitre 3 : Les problématiques d’évolution continue du logiciel

Ce chapitre pré une vue d des émes vécus par les clients, les
es ainsi que les és de la mai du logiciel. On y traite de la
perception de la lenteur du service et des couts élevés des services de la maintenance. Ce
chapitre présente aussi la perception interne (de la part des employés et des gestionnaires
de groupe de la maintenance du logiciel) concernant les situations quils vivent
quotidiennement. Une section du texte introduit la mesure (processus, produit et services)
de la maintenance. Ce chapitre présente également lentente de service, les contrats,
Iimpartition ainsi que les différentes approches d'étalonnages de ces services offerts par
des fournisseurs externes.
Chapitre 4 : La compréhension d'un logiciel existant

Ce chapitre décrit le role, les objectifs, les modeles et stratégies afin de comprendre un
logiciel. Aborder un logiciel, pour la premiére fois, peut étre difficile et le mainteneur a
hss besoins afin de Tappuyer dans cette tache. Les techniques et les outils de
de aident le mai lors de cet apprenti On y traite
des effets de chaque stratégie sur les activités de maintenance ainsi que des facteurs qui
ont un impact sur la compréhension d'un logiciel. Ce chapitre se termine par un survol
des outils, techniques et méthodes disponibles.
Chapitre 5 : La réingénierie d'un logiciel existant

Comme nous avons abordé dans le chapitre précédent, une grande partie de leffort
devolution dun logiciel une bonne de celui. I est
souvent nécessaire d'extraire la i dir du code source. La rétro-
6 © 2023 Edition Smart, 2023 - Tous droits réservés 7

L'évolution contrdlée du logiciel 1 L'évolution contrblée et I'agilité
1.1 INTRODUCTION
Ce chapitre traite de la question de 'agilité en maintenance logicielle. Parfois nommée la
maintenance agile ce n'est pas tout a fait le cas ici, car ce sont plutot des développements
itératifs qui comportent des activités de maintenances lors du développement et parfois
des itérations entiéres consacrées a effectuer de la rétro-ingénierie du logiciel. Dans ce
chapitre nous allons discuter un peu plus en détail de cette tendance actuelle qui est
populaire, en agile.
1.2 MODELE DE CYCLE DE VIE AGILE

L’évolution contrdlée et Bien qu'il y ait plusieurs modéles de cycle de vie itératifs et incrémentaux, nous allons
nous concentrer sur les deux plus récents et populaires: SCRUM et Kanban qui sont
Pagilité deux cycles de vie dits évolutifs. Le terme « évolutif » dans un processus de cycle de vie
de fait a Vévolution des , de la
conception et du code. Un modéle évolutif est appropri¢ dans les cas ou les exigences
et larchitecture logiciel e ne sont pas clai écifiées a 'avance ou dans les cas
ou elles risquent de subir des changements importants au cours du projet. Un modéle
évolutif peut convenir aux phases initiales d'un nouveau type de projet pour lequel il
Dans ce chapitre, nous couvrons : n'existe pas d'historique. La figure 1.1 illustre un processus de développement évolutif
~ Le modéle de cycle de vie agile SCRUM, générique. Comme lillustre cette figure, chaque itération d'un processus évolutif est
une mini cascade d’activités impliquant :
~ Le modele agile du DevOps,
~ Lamaintenance dans un cadre agile. ~ Evoluer les exigences opérationnelles et logiciels,
~ Concevoir le logiciel pour cette itération,
~ Obtenir et intégrer les composants,
~ Verifier et valider le logiciel résultant, et
~ Evaluer le résultat et le rendre disponible en production.
Etant donné que lapproche agile est fondée sur lapproche Lean, oui on cherchera a
identifier et éliminer les diverses formes de gaspillage dans les facons de faire, il n'est donc
pas recommandé de démarrer en paralléle le développement d'un trop grand nombre
d'éléments au caret de produit. Ce carnet de produit posséde toujours des items clest
pour cela quiil est aussi appelé camet de commandes (de l'anglais « backlog » qui est
souvent une liste de récits sans fin). En supposant que les membres d'une équipe agile
puissent travailler en binome ou en trio ou en petits sous-groupes a lintérieur de cette
équipe, on exercera le cycle logiciel pour chacun de ces sous-groupes, afin de faciliter la
collaboration et permettre a I'équipe de garder I'accent sur la livraison rapide de récits.

“Faire évoluer” exemple : « nous poursuivrons une approche évolutive pendant au plus trois semaines;
une réévaluation majeure sera si les etla ion ne sont pas
stables d'ici la. »
Vérifier 1.2.1 LES APPROCHES AGILES

~ Faire évoluer le logiciel
les Le développement agile est le mieux adapté aux projets d’applications réalisés en
opérationelles Intégrer les présence d'un client/utilisateur averti et bien informé des besoins a satisfaire par le
composants au systéme en cours de construction. Il existe plusieurs variantes du théme agile, mais la
produit plupart des modéles de processus agile insistent sur les aspects suivants :
Besoins et Attentes Démontration Impliquer en permanence un client/utilisateur représentatif,
des clients/utilisateurs |dulogiciel 2. Développer des cas de test et des scénarios de test avant de mettre en ceuvre la
prochaine version du produit,
Figure 1.1 — Modéle de cycle de vie itératif générique 3. Implémenter et tester la version résultante,
1I ne faut surtout pas que chaque développeur parte seul dans son coin avec un récit, 4. Démontrer chaque version du produit en évolution au client,
car cela augmente les risques d’avoir la forme de gaspillage, Clest-a-dire un certain 5. Obtenir la ou les prochaines exigences du client (c.-a-d. les récits), et
nombre de travaux commencés, mais non terminés la fin de ltération. Chaque cycle 6. Livrer péri dans l'envir opér
dun processus de développement évolutif doit étre limité dans le temps pour éviter que
la mini cascade ne devienne une maxicascade sur toute la durée d'une itération. A la
fin de chaque cycle d'itération, voire au fur et & mesure de la complétion des récits du Ecouter les
carnet de produit, une évaluation du résultat, basée sur la vérification, la validation et
histoires du
la démonstration, révélera l'une des prochaines étapes possibles du projet: Specifier
1. L'approche choisie pour cette itération est satisfaisante et fournit des informations les exigences
utiles pour la conduite du prochain cycle d'analyse, de conception, de mise en
ceuvre et d’évaluation,
2. Le résultat de analyse, de la conception et de la mise en ceuvre de cette itération
n'est pas satisfaisant et une approche alternative doit étre tentée,
3. Des i ont été ise sur cette i et les
précédentes) pour specifier les exigences restantes, achever la conception, la
partitionner et terminer le projet en utilisant une approche de construction Démontrer
incrémentielle, ou les résultats
4. Ce projet devrait étre annulé, peut-étre parce que l'état des connaissances ou de ev
la technologie ne peut pas supporter le concept de systéme. retravailler
Létape de validation doit nécessairement impliquer le client, qui participe a la Figure 1.2 — Un modéle de cycle de vie agile générique
détermination du résultat obtenu. Lévaluation peut entrainer des révisions du concept
de litération et des exigences opér Un objectif I de tous les
modéles de développement itératifs est de fournir des démonstrations fréquentes du Le role du client est de fournir le « scénario/la vision du produit » qui détermine les
progrés (ou de leur absence) et de prévenir rapidement le client sil y a des exigences, de constater les capacités démontrées et de spécifier le contenu du camet
problématiques. Conformément a cet object, la durée d'un cycle évolutif (c.-a-d. une deproduit pour la prochaine itération. Un modéle générique de processus itératif pour
itération) ne devrait pas dépasser une certaine limite de temps. Quelques semaines le développement agile est illustré a la figure 1.2. Des « cartes de récit d'utilisateur »
pour une itération évolutive peuvent étre nécessaires pour développer une partie plus (user story) sont utilisées pour enregistrer/documenter les exigences. Elles peuvent
complexe du logiciel; dans de nombreux cas, des cycles d'une a deux semaines sont étre triées par le propriétaire du produit afin de refléter les priorités; des estimations
appropriés. Dans tous les cas, vous ne voulez pas attendre 3 mois, 6 mois ou 12 mois de I'effort peuvent étre écrites dessus, et effort réel peut étre enregistré et comparé
pour vous rendre compte que la conception et la mise en ceuvre ne répondent pas aux aux estimations tout au long du projet. Quest-ce qu'un bon récit d'une exigence ? Il y
exigences et aux besoins des utilisateurs, ou que les exi ont été mal énoncé a des critéres pour rédiger des exigences de qualité. Une exigence est dite de bonne
ou quelles ne sont pas réalisables. qualité si elle rencontre les caractéristiques individuelles suivantes (IS029148, 2018)
Vous savez que l'utilisation d'un processus de développement évolutif est une approche
qui comporte aussi des risques; la planification doit procéder de maniére évolutive, car ~ Nécessaire : L'exigence définit une capacité essentielle, une caractéristique, une
toutes ou partie des exigences peuvent étre instables et méme inconnues. Létape contrainte et/ou un facteur de qualité. Sil n'est pas inclus dans lensemble des.
dévaluation de chaque cycle évolutif détermine donc ce qu'il faut faire pour la exigences, il existera un défaut qui ne pourra pas étre satisfait par la mise en ceuvre
prochaine itération. Une contrainte de temps peut étre imposée a l'équipe, par autres exigences,
10 ©2023 Edition Smart, 2023 - Tous droits réservés 11

L'évolution contrdlée du logiciel 1 L'évolution contrdlée et I'agilité
~ Appropriée : Lintention spécifique et le niveau de détail de Iexigence sont appropriés étre minimisé si les développeurs de logiciels partagent une métaphore de conception
au niveau de lentité a laquelle elle se réfere (niveau d’abstraction approprié au commune ainsi que des pratiques de codage et de documentation de code commun.
niveau de lentité). Cela inclut d'éviter les contraintes inutiles sur architecture ou la
conception tout en permettant une indépendance de mise en ceuvre dans la mesure Le développement agile semble étre le mieux adapté aux petits projets développant des
du possible, logiciels applicatifs non critiques. Dans les petits projets de sites Web, par exemple, il
~ Non ambigile : Lexigence est énoncée de telle maniére quelle ne peut étre interprétée n'y a pas dallocation dex aux sous-systémes ni de partiti d'une
que d'une seule fagon. Lexigence est énoncée si etest facilea ; conception a priori, ce qui est nécessaire pour que les membres d’équipes de projet de
grande taille travai i é Mais des ions a la mé ont été
~ Complete: Lexigence décrit suffisamment la capacité, la caractéristique, la faites pour les grands projets (par exemple l'utilisation de SaFe) et aussi pour les
contrainte ou le facteur de qualité nécessaire pour répondre au besoin de lentité projets demandant une sureté élevée.
sans avoir besoin d'autres ions pour Texi
~ Unique : L'exigence énonce une capacité, une caractéristique, une contrainte ou un Les processus agiles conviennent a tous les types de projets logiciels, Les récits
facteur de qualité uniques, dutilisateur fournis par le client et les métaphores de conception utilisées par les
- i (réaliste, posible) : L peut étre réalisée dans le cadre des développeurs conviennent aux développements de logiciel en continu. Comme pour
contraintes du systéme (par exemple, le cout, le calendrier, technique) avec un risque tous les modéles itératifs, planifier un projet agile implique la construction d'un carnet
acceptable, de produit en collaboration avec le client utilisateur pour développer la_visiondu
~ Verifiable : Lexigence est structurée et formulée de telle sorte que sa réalisation produit, planifier la fré des itérations et planifier la fré de fourniture des
puisse étre prouvée (vérifiée) a la satisfaction du client au niveau oul les exigences fonctionnalités évolutives aux utilisateurs. Contrairement aux autres modéles de
existent. La vérifiabilité est renforcée lorsque lexigence est mesurable, développement, les développeurs doivent établir une métaphore de conception et la
version particuliére du processus agile a utiliser doit étre examinée et acceptée par les
~ Correcte : Lexigence est une représentation précise du besoin de I'entité a partir de parties prenantes du projet. Lors de Iexécution du projet, il est particuliérement
laquelle elle a été transformée, et important d’examiner chaque semaine avec les clients, les développeurs et les autres
~ Conforme : Les éléments individuels sont conformes a un modéle et a un style parties prenantes des facteurs tels que l'état actuel du produit en évolution, les
pour les exi der le cas échéant. versions planifiées, la vision du produit et la métaphore de conception, les facteurs de
qualité et les plans. Pour les deux ou trois prochains mois (ou jusqu’a la fin prévue du
Comme indiqué a la figure 1.2, il ny a pas d%étape explicite de conception ni de projet si moins de deux ou trois mois). Les différences entre Iétat actuel et prévu de la
documentation « prescrite » dans un processus de développement agile. Il est attendu if ion doivent étre é ées et ré iliées de maniére i
que chaque équipe agile soit créative et disciplinée afin de documenter ce qui a de la En résumé, les processus de développement agiles conviennent aux projets qui
valeur en étant les diverses formes de gaspillage d’effort (c.-a-d. appliquer les principes développent des logiciels d iten moins de 10 dé , ont un
de approche Lean). Le faible volume de documentation est compensé par une client sur le site (repr des utili des
« métaphore » de conception partagée par les développeurs. Cette métaphore de la hautement qualifiés qui partagent une métaphore de conception commune, assurent
conception pourrait étre basée sur un style architectural; par exemple, le systéme peut
étre basé sur un style en couches (par exemple, une architecture & 3 niveaux) ou une la continuité du personnel de et pour un produit qui fera lobjet de
ar e avec sé des préc (ou séparation des responsabilités). lancements fréquents et de livrai ériodiques dans I'envi opérati
Labsence d’étape « explicite » de exige qu'une partie des développeurs soient Les instructions suivantes sont utiles lors de la planification et de la réalisation d'un
ualifiés. Sinon, le dé continu en agile peut devenir une excuse projet de développement itératif:
pour la mise en ceuvre de mauvaises pratiques ou tout est fait rapidement et sans
qualité. ~ Le plan de projet initial doit spécifier le type de model ratif a utiliser, il doit étre
adapté aux besoins du projet,
11 a été observé que certains gestionnaires retiennent seulement les aspects rapides et
simples a mettre en ceuvre dans l'agilité au détriment des pratiques qui nécessitent ~ La durée de chaque itération doit étre spécifiée dans le plan de projet initial,
une certaine discipline. Cest une tentation assez grande qui peut détourner le ~ Les principales activités et les principales étapes du projet doivent étre identifiées et
processus agile de sa mission de livrer des logiciels de qualité. Dans de nombreuses incluses dans le plan de projet initial,
versions du processus agile, les dé 5 de logiciels produisent une prochai ~ A mesure que le produit évolue, les plans sont révisés et élaborés dans le respect des
version d'un systéme en cours d'évolution dans des délais ne dépassant pas quelques contraintes générales du projet,
jours ouvrables. Lexpérience acquise avec cette approche de développement en ~ Plusieurs roles sont joués par les ingénieurs logiciels simultanément (c.-a-d. analyste
continu indique que les r sont comme pr un d'affaires, concepteur, développeur, testeur ... et il faut les préciser,
faible nombre de i joutées et une grande satisfaction des utili s.
Co , la i i des utili dépend i de I i ~ Le controle de version automatisé est essentiel pour établir et gérer les versions de
dun utilisateur expérimenté pour ré aux ions de I'équipe. Certains divers artéfacts a différentes étapes du développement,
critiques ont exprimé la crainte qu'un processus agile puisse aboutir a un prototype ~ Les tests sont réalisés au début, les revues de code et les démonstrations sont
dépourvu de documentation de conception, rendant ainsi le systéme difficile 2 modifier fréquentes et nécessaires,
4 lavenir et nécessitant beaucoup de retravail a chaque itération. Ce probleme peut ~ Lalerte précoce des problémes doit étre traitée dés que détectée, et

~ Les raisons dun refactoring (voir rétro-ingénierie au chapitre 5) excessif du code / d'interface utili , ingéni systéme et infrastructure. Une
doivent étre ident et des améliorations apportées dés que possible. équipe peut comprendre jusqu'a 10 spécialistes du ine du logiciel. Les étapes du
é nt sont (de anglais « Sprints »), qui se qui durent
1.2.2 LE MODELE DE CYCLE DE VIE SCRUM généralement entre 2 a 4 semaines et qui ont un objectif (de l'anglais « Sprint goal »).
Pendant ces itérations, il se peut que vous livriez un incrément qui est un travail
Le modéle SCRUM (la mélée) est un cadre pour la planification et la réalisation de projets terminé qui est fait et qui est utilisable par l'utilisateur (voir aussi une autre vidéo sur
logiciels reposant sur les principes du développement agile (le terme SCRUM provient du les i Une i résulte en un de ités pouvant étre
rugby). fournies aux utilisateurs, si elles sont a ité. Les fonctionnalités a
dans une itération sont déterminées lors d'une réunion de planification de ltération;
les fonctionnalités a inclure sont dérivées du carnet de produit et discutées dans une
mélée quotidienne (de Tanglais « daily standup meeting », soit éves réunion:
tous les membres de Iéquipe sont debout pendant environ un maximum de 15 minutes
et discutent de I'objectif de l'itération. Ces réunions sont organisées chaque jour pour
examiner le travail accompli la veille et planifier le travail d’aujourd’hui. Il faut faire
attention que ces rencontres ne deviennent un automatisme sans valeur ajoutée.
1.2.4 LE DEMARRAGE D'UN NOUVEAU PROJET (LTERATION ZERO)

Figure 1.3 — Le modeéle de cycle de vie agile SCRUM, selon Mountain Goat Software © Lors de cette étape, les exigences sont converties en récits utilisables et ordonnés selon
un premier ordonnancement. Le principe étant de discuter, en premier, des exigences
1.2.3 LES TROIS ROLES EN SCRUM qui apportent le plus de valeur ajoutée (ou retour sur investissement (ROI) au
propriétaire du produit. II sagit donc de faire remonter les exigences fonctionnelles qui
Il y a trois roles principaux prescrits par cette méthodologie de gestion de projets ont la plus haute valeur ajoutée (oa donc le ROI est le plus élevé) en haut de la liste.
logiciels qui incluent la maintenance: Cette liste est appelée le carnet de produit/commande. II servira & alimenter le travail
de Téquipe de développement et pourra évoluer tout au long du projet. Le changement
~ Le Scrum Master ; est non seulement autorisé, mais encouragé afin de pouvoir éliminer les idées de départ
~ Le propriétairedu produit (le représentant du client qui travaille au niveau des qui s'avéreront mauvaises et de prendre en compte les nouvelles idées qui arriveront
récits), en cours de route. Bien que ce carnet soit la premiere du r
~ Léquipe de développement. de produit, activité de construction d'un carnet de produit est collaborative, car elle
implique tous les membres de I'équipe de développement et le Scrum Master, et ce dés
le démarrage du projet.
Le coordonnateur de projet est appelé un « Scrum Master ». Celui-ci devra cependant
au style de « et controler » pour adopter un mode Vous pouvez alors déterminer ensemble (c.-a-d. l'équipe de développement, le
de management participatif. Le Scrum Master doit maitriser la méthodologie Scrum et responsable de produit et le Scrum Master) la durée des itérations (par exemple 2
s'assurer qu'elle est correctement appliquée. II joue donc un role de coach 4 la fois semaines). Cette durée devra étre la méme pour l'ensemble des itérations afin de
auprés du propriétaire de produit et auprés de léquipe de développement. II doit donc ‘maintenir un rythme régulier propice aux automatismes et pouvoir construire des
faire preuve de pédagogie. Il est également chargé de sassurer que l'équipe de indicateurs de controle de projet fiables. Ensuite on peut effectuer tous les travaux
développement est pleinement productive. préparatoires du projet (ex. : établissement du carnet d'itération /commande, rédaction
d'un document de vision du produit, préparation des environnements, mise en place
Le propriétaire du produit (c.-a-d. le client ou le représentant de l'utilisateur) qui porte de Tinté de Tarchitecture générale du logiciel..).
la vision du produit réaliser et travaille en i ion avec équipe de Exceptionnellement, la durée de litération 0 va différer de la durée fixée
1l s'agit généralement d'un expert du domaine métier du projet. Le propriétaire de précédemment. Elle prend souvent 2 a 3 fois la durée d'une itération en cours de
produit écrit les histoires (de l'anglais « stories »), les hiérarchise et les place dans le « Sprint. Litération 0 se termine quand I'équipe se sent préte a développer les premiers
carnet de produit » (de l'anglais « product backlog ») et va les débattre avec '‘équipe. récits priorisés du carnet d'itération, notamment parce I'analyse détaillée aura été
Souvent le propriétaire du produit va tenter de produire une « roadmap » du produit suffisamment avancée pour étre a laise avec Iestimation.
sur plusieurs mois pour satisfaire les besoins de la direction. Cette approche est
souvent critiquée, car elle tente de prédire les livrables 4 long terme ce qui n'est pas Clest aussi pendant litération 0 que I'équipe détermine, en accord avec le responsable
facile. Elle peut étre utile, mais on doit se souvenir quelle n'est pas un plan précis de de produit, la définition de ce quest qu'un récit/livrable qui est « termi
ce qui va se passer. Avec les développeurs du logiciel, qui jouent le réle de « I‘équipe de of done »), soit le résumé du plan d’assurance qualité comprenant les activités au terme
développement ». Cette équipe est chargée de transformer les besoins priorisés par le desquelles on pourra livrer en production des fonctionnalités de qualité (c.-a-d. que le
propriétaire du produit en i i Léquipe de est produit logiciel est terminé pour cette étape). Ensuite, quand I'équipe est préte, il est
pluridisciplinaire et peut donc encapsuler d'autres roles tels que: développeur, temps de lancer les itérations de développement.
architecte logiciel, analyste de bases de données, analyste fonctionnel,

En somme, cette étape de planification consiste a formaliser la vision du produit

(logiciel) que l'on souhaite réaliser. A la sortie de cette étape de démarrage, il est donc
utile d’avoir un tableau
de Vision de produit effectué a l'aide d'un atelier
de démarrage
(denviron % journée) pour que Iéquipe puisse : 1) établir une vision de produit
2) le (de l'anglais « user story mapping») du
produit; et 3) de en quoi va les ifs des premiers Sprints.
Chaque récit pourra ensuite étre estimé par l'équipe de
pour voir ce qui pourrait permettre de démarrer le projet.
1.2.5LA REUNION DE PLANIFICATION D'ITERATION
Les itérations de développement démarrent apres I' itération zéro ». Quand les travaux
sont lancés, il y a une réunion de planification de litération qui parle du Quoi, du
Comment et du Combien. Le propriétaire du produit synthétise alors la vision du
produit (ce qui va donner de la valeur), le plan de livraison (c.-a-d. les jalons et dates
cibles) et Iobjectif de I'itération de son point de vue. L'équipe de développement vérifie
les estimations, confirme qu'elles sont exactes et liste, & l'aide d'une « story map » (de
set Paton) (Paton, 2015) les récits du carnet de produit et place en haut du camet de
les plus prioritaires qu'elle se sent capable de convertir en
soticusanivs utilisables d'ici la fin de cette itération (c.-a-d. il agit dune prévision
et non pas d'un +, bien qu'un la
définition de terminé » soit requis). Chaque membre s'identifie red a une/des
taches qu'il prend en charge. Pour gérer et rendre visible l'avancement des travaux, un
tableau SCRUM est utilisé (voir Iexemple d'un tableau simple 4 l'aide de I'outil Trello
d'une équipe de projet a la figure 1.4).
Figure 1.4 - Exemple d'un tableau des taches Kanban d'un projet (a l'aide de I'outil Trello)
Léquipe de dé fait ensuite I ire des taches qui ont de
convertir les i en fonnali ili ici la fin de
Titération : I'équipe détermine une liste de taches estimables en heures-personnes et Elle doit cependant aller suffisamment loin dans l'effort de conception pour pouvoir
dont la plus grosse tache n'excédera pas Iquivalent de 2 jours de travail afin d%éviter verifier /valider sa révision. Ainsi il est important de se fixer un critére de ce qui est
des taches trop grosses et floues dont estimation serait trop incertaine. Toutes les assez bien défini pour nous (ce qui est prét « notion of ready »). Avec un récit qui
n'ont pas né besoin détre découpées en taches, rencontre la définition de ce qui est prét alors on se fixe alors un objectif ditération qui
si lexigence est ré en 2 jours ou moins. En cas de manque de consiste a identifier ce qui doit étre fait au minimum advenant que tout aille mal. C'est
temps, Péquipe de dé peut se de dé celles qui seront un peu le plancher, le niveau minimal de livraison. Avec ces informations, il est
réalisées au cours des premiers jours de I (elle en cours d possible de avec le propri du produit la liste des récits
les autres exigences). sélectionnée. La liste des récits devient alors les taches de développement, qu'on
appelle le « caret d'itération » (de Uanglais Sprint backlog) et elles sont centralisées et
ajoutées au tableau des taches en préparation du dé de litération (elles sont
toujours visibles et accessibles a tous sur le tableau Scrum). Afin de respecter le
principe de « travail », Téquipe de ne pas s' au-dela de
70% ou 80% de sa é de lité (ex. 5 pour des itéraons de 2
ines, a 35 heures/semaine = 350 heures de ité deffort, a 70% = 245 heures
pour I pour lui pe de faire face aux risques et aux
imprévus, sans avoir a faire du temps supplémentaire. L'équipe peut utiliser lavélocité
historique (si vous avez un historique) pour aider avec cette tache. La réalisation de
cet eagagement est importante pour que chaque membre de I'équipe puisse avoir un
en find ce qui leur meilleur moteur
de motivation pour le reste du projet.
1.2.6 L'ITERATION
Une itération est lancée. Au cours de litération, l'équipe se concentre sur

Paccomplissement des taches engagées. En cas de retard, des récits ou taches peuvent
étre retirés en cours de route en essayant de préserver U'objectif de litération (pour

cela, il est conseillé de toujours d'ordonnancer les récits au sein du carnet ditération). productive. La mélée soliton se déroule 4 lieu et heure fixes (devant le tableau des
Et inversement, si Iéquipe avance plus vite que prévu, des exigences ou taches peuvent taches physique de p par I'équipe de Au début le
étre ajoutées. Toutefois, il faut faire attention a ne pas ruiner Tobjectif de litération en Scrum Master peut avoir a rappeler qu'il est Pheure de la mélée et animer cette derniére
modifiant trop le carnet ditération, car le i a’ n'y serait pas en rappelant les 3 questions et évitant instruction des problémes ou obstacles en
ni la moti qui en it. Les dé se font verti et non séance afin de ne pas dépasser les 15 minutes imparties. L'objectif du Scrum Master
pas horizontalement par couche. Le but est de développer les fonctionnalités de bout consiste cependant a viser appropriation de la mélée par léquipe de développement.
en bout (de la conception aux tests) au fil du progres de ltération. Autrement dit
d’éviter un mini cycle en V au sein de litération, voire de se retrouver avec une 1.2.8LA REVUE D'ITERATION
surcharge deffort de test en fin d'itération. Les développeurs doivent donc éviter de
trop paralléliser les exigences et encore moins les taches de développement. Pour cela, L'objectif de la revue d'itération est d’inspecter l'incrément (ou les incréments) prét au
Tapproche de programmation & deux (en binome) peut se révéler utile ainsi que la cours de litération écoulée, faire un point sur 'avancement de la prochaine mise en
dune limite ae au sein d'une colonne du tableau des production et adapter au besoin le plan et du carnet de produit.
taches (nous allons voir plus tard cette notion de limites des travaux en cours avec la
méthode Kanban). Liéquipe de développement présente 4 tout acteur projet intéressé (au minimum au
propriétaire re de produit idé éd finaux) les
Le tableau des taches de la figure 1.4 rempli de taches est indispensable. II permet nouvelles fonctionnalités développées au cours de litération. Les clients donnent une
avoir une vision claire du travail 4 accomplir, en cours et terminé. Il peut également rétroaction a Iéquipe de ils ou refusent les
S'avérer précieux lors des méles quotidiennes. Avec SCRUM ce sont les développeurs présentées.
qui « tirent + les ches et non pas le Scrum Masterqui pousse le travail constamment.
Pendant I'itération, léquipe de dé le pr de produit dans Liéquipe ne présente que les éléments (incréments) « terminés » au responsable du
ses activités d'affinage du carnet de produit (c.-a-d. la colonne a faire du tableau des produit pour validation. Les é non alac de terminé » ne
taches). Cette assistance peut consister en des ateliers de conception anticipés, de doivent pas étre présentés. Le responsable de produit doit alors «accepter » ou
priorisation ou d’estimation. Il faut compter environ 5% & 10% de la capacité a faire de « rejeter » chacun des éléments présentés du carnet de produit. Typiquement, ce serait
V'équipe de développement pour ces activités, selon le niveau d'optimisation de son le responsable du produit qui exécuterait les tests d’acception définis en début de cycle,
processus. soit en méme temps que analyse détaillée. Ces tests d’acception peuvent étre
automatisés ou manuels. Bien que SCRUM stipule que la revue ditération doive avoir
1.2.7 LES MELEES QUOTIDIENNES été faite en fin ditération, rien nempéche Iéquipe de faire cette revue au fur et a
mesure que les éléments du carnet sont « terminés », ce qui rend le processus plus
Les réunions quoti aussi mélée quotidien e, d'une durée maximum efficace et efficient quand le responsable de produit travaille au sein de Iéquipe
de 15 minutes, permettent au Scrum Master de déterminer le taux d'achévement des quotidiennement.
taches et d’anticiper les problémes potentiels avant qu'ils ne deviennent des problémes
réels (c.-a-d. gérer les facteurs de risque). Cette réunion qui se fait debout (ca évite de Un élément terminé et accepté peut alors étre déployé, soit dans l'environnement de
s'éterniser) est trés importante. Elle permet quotidiennement aux membres de léquipe pré production ou celui de production, selon quiun sous-ensemble cohérent et
de se sy de les rencontrés, de coordonner lentraide, et fonctionnel puisse étre déja utilisé ou pas. Léquipe de développement calcule sa
de vérifier 1 du sprint. Elle contribu 4 faire naitre lesprit vélocité en les points de aux
déquipe. A condition bien entendu de ne pas transformer cette réunion de « Une fonct é parti terminée, C'est-a-dire qu'elle n'est pas conforme & la
synchronisation » en réunion de « reporting » vers le Scrum Master. Il y a quelques définition de « terminé », ne rapportera aucun point, car une telle fonctionnalité n'est
astuces pour qu'elles soient efficaces. Dans une approche classique, chaque personne pas utilisable. La vélocité ainsi calculée va permettre de mettre a jour le graphique
répond a 3 questions, en lien avec les éléments du tableau des taches : de livraison et de vérifier I’ de cette derniére. Cest l'occasion
is vérifier que le nombre de « Sprints » de cette livraison demeure adéquat ou non. Le
Quai-je fait hier qui a aidé I'équipe de développement a atteindre objectif Sprint ? controle de l'avancement d'une itération est effectué a l'aide de graphes d’avancement
Que vais-je faire aujourd'hui pour aider I'équipe de développement a atteindre diitération (de l'anglais « Burndown Chart ») qui sont des graphiques permettant de
suivre la progression du développement d'un produit, au niveau d'une itération, d'une
»
Tobjectif Sprint ?
Véquipe de épopée ou d'un projet entier. L'abscisse du graphique représente le temps, voir figure
3. Y a-t-il des de m’e é ou d'e
1.5, utilise une unité comme la journée, mais celle-ci peut s'adapter a la temporalité
développement d’atteindre l'objectifdu Sprint ? du projet. En ordonnée, on représente un indicateur du travail complété ou un
indicateur du reste du travail a faire. Cet indicateur peut consister en un nombre de
Cette approche, si elle est répétée continuellement, devient monotone. Pour changer récits, de points d’effort ou encore en fonctionnalité livre.
un peu les idées prenez plutot approche de faire le tour du tableau des taches et d’en
parler ensemble et de se poser des questions : comment faire pour avancer?
Lors de la mélée quotidienne, le Scrum Master est ainsi immédiatement au courant
des obstacles rencontrés, il doit impérativement les prioriser, les suivre et bien sar
sefforcer de les lever au plus tot afin de garder Iéquipe pleinement concentrée et

Il est trés important que les actions de rétrospectives soient bel et bien mises en place
sinon les rétrospectives ne serviront 4 rien. Un indicateur doit étre suivi. Combien
d’actions ont été et ont étéi Pre moins, mais
faites-le.
1.3 QUELLE ORGANISATION EFFECTUE L EVOLUTION CONTROLEE DU

Travail
restant LOGICIEL ?
Les aspects organisati éci identifier quelle isation ou quelle

Temps fonction sera responsable pour la maintenance du logiciel. En agile, par défaut,
Vequipe fait autant le développement que la maintenance du logiciel pendant
ération. Mais dans certain ions I'équipe qui développe le logiciel n'est pas
Figure 1.5 — Un exemple de graphe d'avancement d'itération « bumdown chart» ii affectée aussi a sa maintenance. Historiquement tous les acteurs du logiciel
(figure de praxisframework
org) étaient dans des organisations séparées (voir figure 1.6) ce qui ralentissait beaucoup
le travail.
En mode Scrum il est courant d’effectuer la mesure de certains indicateurs a la fin
d'un Sprint. La base d'une planification de projet utilisant les « user story points » :
= Mesurer lavélocité de I'équipe a chaque fin de sprint afin d’adapter la planification a
la réalité tout au long du projet,
~ Visualiser la quantité de travail 4 faire en comparaison de la vélocité a l'aide d'un «
Burn Down/Up Chart » afin de projeter l'équipe sur une date de fin de projet
raisonnable. La mise a jour réguliére de ce graphique, a chaque fin de Sprint,
permettra de réagir au plus vite si les choses dérapent, et
~ A partir du graphe d’avancement, si on constate que la date de livraison espérée
initialement apparait intenable, on pourra agir et réduire le périmétre de la livraison
pour conserver la date ou bien décaler la date, ce qui devrait augmenter également
les couts.
Figure 1.6 — a séparation en silos des spécialistes en logiciel crée des inefficacités
1.2.9 LA REUNION DE RETROSPECTIVE
Depuis quelque temps, l'agilité a rapproché tous ces acteurs pour les colocaliser de
Chaque itération est suivie d'une réunion nommée la rétrospective de litération au maniére & tenter d'obtenir plus d'efficacité (voir figure 1.7). Pour décider od la fonction
cours de laquelle I'équipe les résultats de I et détermine de sera locaisée, les or a iciel e peuvent, par
elle peut améliorer ses processus de travail lors de futures itérations. Liobjectif de la exemple, demeurer avec le développeur original ou siadresser a une équipe
rét est de faire 1% ntinue des de I'équipe. en Souvent, loption du mainteneur spécialisé
Typiquement, équipe devrait répondre a la question « Si cette itération était a refaire, est préférée. Il y a beaucoup d’arguments pour et contre chacune de ces deux options ;
que ferions-nous différemment? ». Une rétrospective se déroule en plusieurs étapes, la décision devrait étre prise en étudiant chaque cas.
d'une durée totale autour de 2 heures :
Limportant, c'est que la délégation ou lassignation de la ilité a un groupe
Identifier ce qui a bien été (pour en prendre conscience), ce qui a été irritant (des ou a une personne, quelle que soit la structure de organisation, soit claire, planifiée
du faciles a améliorer) et ce qui a mal été (et qui devrait étre et bien communiqué. Dans lindustrie, on peut retrouver ces deux modéles
systématiquement amélioré), organisationnels pour la fonction de maintenance du logiciel. Dans un premier modéle
~ Léquipe met ces éléments en commun et les trie en ordre d'importance, cst le dé , qui a développé ou acquis le logiciel, qui en
~ Les 2a 3 éléments les plus prioritaires 4 améliorer sont pris en charge par léquipe effectue la maintenance. Dans un second modéle, clest lorganisation de la
qui se distribue la tache de trouver des solutions a mettre en ceuvre dés la prochaine maintenance du logiciel qui effectue la mai des logiciels de l'organisation, et
journée de travail, souvent en binéme ou en trio, et ce, indépendamment des développeurs.
- Les i entre eux les solutins congues et apportent les ajustements
nécessaires pour obtenir le consensus.

11 a été observé que le développement logiciel initial est habituellement basé par projet,
avec une période et un budget défini. L'accent est mis sur la livraison dans les délais De plus, il y a une perception de manque de transparence dans les organisations de
et dans le budget pour remplir les besoins de l'utilisateur. at qui leurpropre mais avec comme conséquence une
perception générale que les logiciels livrés sont de faible qualité et ne sont pas documentés
POURQUOI SEPARER L'ACTIVITE DE DEVELOPPEMENT ET DE MAINTENANCE DU LOGICIEL adéquatement, laissant peu de flexibilité pour le transfert des connaissances et la rotation
| des programmeurs de la maintenance.
" waoN
| Ll]
1
Les travaux de du ine de la logicielle
avantages suivants pour les organisations qui ont créé une unité organisationnelle
distincte pour effectuer la maintenance du logiciel : une meilleure documentation des
i if les
logiciels, un processus plus formel et controle de transition du logiciel développé, une

Developpeurs/Mainceneurs Mancencurs plus grande du p de une gestion des
= Moins d'indépendance
- tend créer des + Permet de progressivement
intégrer un requétes de modifications et une plus grande satisfaction des employés. Ces auteurs n'ont
logiciels moins maintenables nouveau programmeur graduellement toutefois pas identifi de seuil a partir duquel il devient souhaitable de passer au modéle
«Plus difficile d'embaucher des développeurs * Specialise le personnel ce qui permet de les ionel od la mai du logiciel est indé du groupe responsable
quand doivent aussi maintenir les systimes wiliser pour faire Assurance Qualité lors du développement des logiciels.
existants d'un nouveau développement 1 est possible que vous vouliez sous-contracter ou méme impartir lactivité de
« Créeun de perte de . une positive entre ‘maintenance de vos logiciels. Seybold et Keller, (Seybold, 2008) ont présenté les
quand ily a un départ Dev et Maint et une rotation (plan de problématiques et défis concernant lexpérience dimpartition de la maintenance, en Inde,
arriére)
des logiciels d'une grande société allemande d'hydroélectricité. Voici un résumé de leur
présentation. Dés le début de la relation, des difficultés reliées : 1) au produit; 2) aux
Figure 1.7 — Développeur et Mainteneur ou séparer les fonctions — un choix difficile processus; et 3) aux ressources humaines sont apparues :
- les eles ées par l'équipe
En contraste, la maintenance de logiciel a souvent comme objectif de sassurer de i ne r int pas les exi qualité. Des problemes de
é du logiciel aux La corrige les communications étaient évidents et les exigences étaient mal comprises, ce qui
pannes et s'assure de satisfaire la demande de l'utilisateur pour des mises a jour et menait a des changements inutilisables par le client et qui nécessitaient
des améliorations. Le retour sur investissement des activités de la maintenance est constamment du retravail. »,
souvent difficile & démontrer clairement, donc la vue par les gestionnaires en chef est - Testsinadé et de priorités : « Les essais étaient effectués
souvent celle d'un centre de couts consommant de grandes ressources sans grands int et ce dans un local. Les effets ires sur les
pour l'organisation. Certaines organisations vont opter pour laisser les non modifiés étaient pas considérés. Les résultats n'étaient pas reproductibles, car
développeurs maintenir les logiciels. aucun des tests n'était écrit ou enregistré. Lors de modifications, aucun concept de
génie logiciel, tel que des notions d'architecture, de patrons et de bonnes pratiques
Il est clair que le personnel de développement du logiciel n‘aime pas faire sa de programmations n'étaient utilisées. Il semblait plus important, pour ces équipes,
maintenance. La maintenance n'est pas souvent vue comme un travail séduisant. Le de produire rapidement plutt que de produire du code de qualité. Les priorités
professeur Dekleva, fournit une liste de problémes liés au personnel basé sur des étaient pas respectées. Cela a conduit a du code non maintenable qui exigeait des
données de sondage. Le personnel de maintenance est souvent vu comme des citoyens efforts supplémentaires pour le retravailler. Retourner un élément pour une reprise
de seconde classe, et peu de développeurs aiment ce travail. a toujours comporté un effort de communication assez éleve. »,
~ Dautres problématiques reliées au produit logiciel : « Le logiciel maintenu s'est vite
Tom Pigoski, qui est Iexpert américain qui a rédigé la norme internationale de la retrouvé dans un état lamentable et sa qualité déclinait. Le logiciel comportait des
maintenance (c.-a-d. la 1SO14764, 2022) décrit ces deux modéles organisationnels
défauts et était devenu instable. Le personnel informatique allemand devait
plus en détail, de méme que leurs et dé r ifs. Par 1 maintenant simpliquer pour aider les clients avec ces problématiques et les calmer.
il y a un certain nombre de désavantages a laisser I'équipe de développement maintenir Avant Ia transition du logiciel vers Inde, le logiciel était assez bien concu, testé et
le logiciel 4 la suite de sa mise en production. Ces désavantages sont (voir figure 1.7): document. Le code source et sa documentation étaient disponibles dans un outil de
gestion des versions. Il y avait méme une compilation quotidienne effectuée a partir
~ «Les développeurs n'aiment pas effectuer la maintenance et sont plus enclins & de scripts et de « cron jobs ». progressivement les librairies de tests,
quitter la société pour du travail plus intéressant quand il y a trop de maintenance & les environnements et les compilations n'étaient plus a jour ni utilisés.
faire,
ucture i ique du groupe de mail est devenue
~ Les és embauchés dans Iéquipe de dé seront surpris obsoléte. Cela souligne clairement la précarité de Iétat de ces logiciels, et ce sur une
et insatisfaits de voir qu'ils doivent aussi maintenir les logiciels existants, période de seulement une 4 une année et demie, 4 la suite de Iimpartition. »,
~ Les experts développeurs sont souvent réaflectés a d’autres projets de développement ~ Statut ambigu du travail : « Aprés avoir envoyé un ensemble de modifications, il ny
et le dé ala is et avait pas de retour/communication jusqu’a la livraison finale, qui était généralement
= lon dis tkpact de Vexpert ql @ développt le loge, on autres employs ne sercrt trois semaines plus tard. Pendant ce temps, il n'était pas possible de savoir combien
pas qu ‘pour maintenir le logiciel ». de temps il faudra attendre et dans quelle mesure ce travail progresse. Ces longs

cycles, entre deux ré i ient la planification presque i ible. Cela a de conflits iels lorsque deux il sur le méme bout
également affecté les « check-in » dans l'outil de gestion des versions, car ils n'étaient de code,
faits qua la livraison finale. Chaque livraison prenait une demi-journée, en raison de © Cet outil facilite aussi la communication quand plus d'une personne travaille
la taille du paquet de travail et de la vitesse de la connexion avec Iétranger. », a régler un probleme. Loutil divise le flux continu des changements de code
~ Dates cibles manquées : « Aucun processus destimation nexistait d'une part ou dune maniére transparent et indépendant, fourni des numéros pour chaque
autre ce qui posait un probléme. Done une des pierres angulaires de la planification compilation. et chaque version peut facilement étre référée. Ce processus et
des mises en production était absente. Les objectifs étaient basés sur les souhaits du outil a réduit les CH
client et culturellement le personnel, en Inde, ne négociaient jamais et disaient ~ Initier des communications informelles a l'aide de Toption de clavardage (chaf de
toujours oui sans pouvoir atteindre les objectifs. Le client qui criait le plus fort Skype : cela a eu plusieurs effets positifs :
obtenait son travail plus rapidement indépendamment de la teneur ou de effort réel © « La barriére de icati a été ide: réduite en
requis. De toute évidence, les clients n’étaient pas contents et essayaient daugmenter comparaison aux appels téléphoniques étant donné que les communications.
la pression sur le fournisseur. » ;
pouvaient maintenant avoir lieu d'une maniére semi-synchrone,
~ Dautres mes liés au 1 Des ions de procédue ont é o étant donné que la présence de chaque membre de Iéquipe est toujours
affecté les clients. La maintenance ne suivait pas un processus particulier. Le travail visible, les deux localisations sont devenues beaucoup plus proches de l'une
était effectué d'une maniére ad hoc et les mises en production aussi. Aucun
‘mécanisme de controle n'existait pour évaluer si le travail était bien ou mal fait. », et l'autre,
~ Les ématiques reliées aux : «1 y avait un manque © Au niveau technique, léchange dexemple de code et de données était
dappartenance, de perspective et de contexte des deux cotés. Une des premiéres simplifié. »
choses que nous avons remarquées, est que, Iappartenance et la conscience de la ~ Clarifier les mots utilisés pour décrire les exigences : Les exigences doivent étre
réalité quotidienne du client étaient absentes a cause de la distance. Surtout dans traduites/réécrites en inde et soumises au client pour assurer une compréhension
les situations, oi un changement avait mal tourné et pouvait avoir été causé par le profonde avant le début du travail,
fournisseur. Le soutien de I'équipe indienne était difficile a cause : 1) des différences ~ Placer une personne allemande en Inde et un représentant indien en Allemagne :
horaires et 2) de la petite taille de I'équipe. Léquipe travaillait de loin et était assez cette initiative permet d’améliorer les communications,
isolée. », ~ Mise en place d'un systéme de tests de régression lancés automatiquement lors de la
~ Connai insuffisante des tests : « En ce qui la ion, les compilation journaliére du logiciel, et
collegues en Inde étaient tous trés bien formés. Cependant, la plupart dentre eux ~ Mise en place d'un processus destimation aux deux endroits : Lestimation des
étaient débutants et avaient que peu de connaissances dans le domaine des tests. requétes est falte en Allemagne et par la suite une estimation est faite en inde. Ces
Leurs connaissances se limitaient aux tests unitaires. », deux sont ées avant d'autoriser le travail. »
~ Dautres émes_de : « Une autre ique, lite aux deux En ion ce genre d' isation de la mai; souffre des dif és du second
éce concerne les n de personnel. Au cours d'une ‘modéle ou cest une organisation séparée de la maintenance du logiciel qui effectue la
période de seize mois, trois des cing membres de I'équipe ont démissionné et ont été maintenance des logiciels de organisation. Mais elle comporte des difficultés
remplacés par de nouveaux mainteneurs. Cela pourrait étre lié au manque additionnelles : une communication plus difficile, des ressources débutantes, des départs
dappartenance ou a lexpérience acquise qui leur permettait de se trouver un meilleur fréquents et des problématiques de coordination plus importantes. La prochaine section
travail ? I est clair que chaque iquait une perte de i décrit les normes de la maintenance du logiciel. Ces normes peuvent aider avec
importante. Recherche de nouveaux membres et l'initiation au projet a pris un temps Tunif ion des termes employés par tous les i lors de la
considérable. Un déménagement des bureaux du fournisseur, de Bangalore &
Mysore, a aussi été une cause de départs. Il a toujours été difficile d'obtenir des
membres expérimentés en inde. » 1.4 LE MODELE AGILE DU DEVOPS ET L’EVOLUTION CONTROLEE
Les auteurs présentent par la suite les solutions mises en place, par ordre d'importance,
pour tenter de remédier a ces problémes : Les cycles de vie de modernes ont alivrer un logiciel
~ «Erablissement d'un processus dintégrati inue et mise en sur la plateforme des développeurs ou de tests. Cette itération du logiciel est présentée
L'équipe d’/ ail é l'outil d'inté i « CruiseControl » aux clients et s'il est accepté, il doit passer au travers des étapes de mise en production
© Cet outil a permis de définir une maniére commune de compiler et déployer ce qui peut étre assez complexe et lent dans les grandes entreprises. Nous avons vu
le logiciel, indépendamment des paramétres individuels des membres de que l'utilisation de Scrum permet de rendre plus légére la mise en production de
Téquipe de maintenance en inde. Les différences entre les versions pouvaient fonctionnalités, car ce sont de plus petits incréments livrables qui arrivent 4 léquipe
ainsi étre éliminées, de production/infrastructure d'une maniére réguliére.
© Les i les dans le logiciel, sont
distribuées plus rapidement, car chaque résultat de compilation est envoyé Ce que DevOps tente de faire est d'éliminer/accélérer/améliorer ces livraisons, des
4 chaque membre de léquipe par courriel. Cela a réduit la nécessité de équipes de développement et maintenance, vers léquipe de
les et la détection précoce des défauts a permis production /d’infrastructure. Le DevOps n'est pas un processus de cycle de vie, mais
un plutst une mise en place doutillage du processus agile des développeurs afin
d'instaurer la notion de continu, d'i , de tests

de déploi continu et de surveillan inue des ap lications en 1.4.1 UNE VUE D’ENSEMBLE DES PRATIQUES DE GESTION DEVOPS
production. DevOps pousse a I'automatisation des cycles de vies agiles de maniére &
livrer continuellement des fonctionnalités en production plus rapidement. Par exemple, Cette section présente les perspectives DevOps des pratiques de gestion de projet et
dans le cas de Scrum, quand un récit est ét il passe en pr. comment elles different des pratiques actuelles:
Prenons l'exemple ou une fonctionnalité placée dans l'arriéré du produit passe 4 la
production en 6 jours alors Téquipe mettra en production continuellement fs Les gestionnaires de projet doivent adopter I'approche du Produit Minimal Viable (PMV!
fonctionnalités a ce rythme. Ce terme DevOps a été inventé par
Belgique en 2009 qui a nommeé sa conférence « DevOps Days » (DevOps, 2021). oe Le succes de la gestion de projets logiciels dans la culture DevOps nécessite d'étre un
nous des apportés par les approches peu moins focalisé sur un produit final complet et parfait. Les plans de projet n'auront
émergentes comme le DevOps, nous avons a nous r sur plus nécessairement de dates de fin, et le travail d’évolution rapide du nouveau produit
roles: les développeurs, les personnes fournissant l'infrastructure et la prise en charge ne sera jamais vraiment terminé. C'est donc que le DevOps opére dans un monde
en production, ainsi que les personnes testant et effectuant 'AQL. Cependant, & di (IC) et continu (DC). Il faut donc gérer les projets
mesure que la culture du DevOps se répand, son impact sur d'autres secteurs de de maniére encore plus agile ce qui permet de corriger les imperfections de maniére
l'organisation se fait sentir. Ces tendances vont s’accélérer avec ascension, dans réguliére, sans grand effort de gestion du changement ou la création d'un autre projet.
Tentreprise, de la génération des milléniums. Llorganisation et ses gestionnaires de projets doivent donc adopter la perspective PMV :
ce qui est fait rapidement et fonctionne est mieux que ce qui est parfait, mais va
prendre beaucoup d'effort.
Prenons la gestion de projet, le DevOps change fondamentalement la fagon dont les
équipes informati les projets, les cycles de vies plus Les chefs de projet, I'équipe de développement et I'équipe d'infrastructure doivent
classiques et poussant les approches agiles pour obtenir plus de rapidité et d’agilité en utiliser les mémes outils pour s’assurer d’avoir la visibilité du progrés en temps réel
faisant tomber encore plus les silos entre groupes TI qui existent dans les entreprises
daujourd’hui. La seule version du temps qui fonctionne dans Iapproche DevOps est le temps réel,
car la valeur et la validité des informations concernant le projet expirent rapidement -
des pour les de projet, les et le font souvent - en quelques heures (ou parfois quelques minutes). Les programmes
SCRUM/ Kanban master. Mais ne vous y trompez pas, ces roles peuvent toujours étre de collaboration, tels que Discord, Slack et Mattermost, ont toujours caractérisé la vie
utiles méme & Iére du DevOps. Ce besoin continuel d'améliorer la rapidité et la qualité sociale de la génération du millénarial. Il n'est donc pas surprenant que les systémes
de livraison 4 aide de technologies et processus 4 la pointe de la technologie ne de une place de choix dans leurs communications.
remplace pas le besoin de savoir ce que vous allez en développer et de controler le At vous 4 ce que les ires de projet de cette génération (dont les plus
travail des équipes. Une solide pratique de gestion de projet est nécessaire pour que vieux ont 37 ans en 2019) fassent davantage appel aux outils ad hoc quaux
les projets avancent comme prévu, en mettant clairement accent sur les dépendances. programmes de gestion de projet traditionnels. S'assurer que tous les membres de
Mais les pratiques et processus de gestion de projet actuels doivent évoluer a l'ére du I'équipe ont accés a des informations fiables et en temps réel fait la différence entre la
DevOps, tout comme les dé , les dopé et d'infrastructure, clarté du projet et le chaos. Une solution de collaboration de travail exceptionnelle
les professionnels de la sécurité et bien ‘autres doivent abandonner certaines vieilles basée sur linfonuagique (c.-a-d. Azure, Amazon et Google Cloud) est essentielle ici.
au profit d’ plus ées a ere érique poussée par la
génération des milléniums. Nous avons vu, dans le chapitre précédent, que les Les gestionnaires de projets doivent utiliser les mémes outils qui aident les équipes a
approches agiles ont déja fait un grand pas pour dynamiser les anciens modéles de gérer tout leur travail, pas seulement le travail de gestion et de suivi de projet. Nous
cycles de vie de développement logiciel et sont de plus en plus utilisés pour gérer le avons vu au chapitre précédent que les développeurs de logiciels utilisent des
besoin d’évolution continu des logiciels long terme. La principale caractéristique du approches agiles déja depuis des années. Dans un monde DevOps, cela signifie que
mouvement DevOps est de plaider en faveur de 'automatisation et de la surveillance & tout le travail passe par un méme systéme de suivi du travail, autant les taches du
toutes les étapes de la construction de logiciels, depuis I'intégration, les tests, la projet informatique que Ia gestion des incidents sur le logiciel. Ainsi les chefs de projet,
publication, le déploiement et la gestion de Infrastructure. Le DevOps vise des cycles dans un envir DevOps, jent étre de répondre a la
de développement plus courts, une fréquence de déploiement accrue et des versions Est-ce déja fait? Et quand est-ce que cette fonction sera-t-il terminée? Vous ne faites
plus fiables, en phase avec les objectifs de I'entreprise. pas du DevOps si vous devez demander la réponse a quelqu'un, car cela signifi que la
fonction de gestion de projet n'est pas correctement intégrée aux mémes outils et
mécanismes de suivi du reste de Iéquipe. Nous savons qu'un des défis de la gestion de
Produit minimum viable (PMV): est un logiciel avec juste assez de fonctionnalités pour projet est de controler si les taches ind a temps. La mesure du
satisfaire les premiers clients et donner une rétroaction pour le développement futur du logiciel. Sprint agile, la vélocité et d'autres paramétres devraient vous donner cette information.
L'approche ou ot souvent moins couteuse que de développer un produit avec plus de II ne suffit pas de demander aux équipes de dé et de test si elles r
les couts et les risques en cas d'échec du produit, par exemple
en raison d' hypothéses incorrectes. les délais; La gestion de projet consiste a visualiser ces mesures pour vous-méme dans
un outil tel que Slack qui I'extrait de JIRA. La méme chose vaut pour l'état d'un livrable.
Il ne suffit pas de regarder un ticket pour vérifier son statut. Les chefs de projet
devraient rechercher les équipes de DevOps pour leur fournir des tableaux de bord sur
Ia progression de la publication. ”

Les plans de projets doivent évoluer plus i le client et les granulaires, a l'avenir les projets logiciels seront également scindés en taches
opérations/infrastructures doivent étre aussi dans la boucle beaucoup plus petites et interdépendantes
A Iére de DevOps, les gestionnaires de projets doivent planifier différemment. Un 1.4.2 LA DIFFERENCE
EN AGILE ET DEVOPS
malentendu courant consiste & ne s'ajuster qua la fin d'un Sprint, par exemple,
planifier simplement un jalon la fin de chaque Sprint de deux semaines. L'approche Ce qui change le plus avec le DevOps c'est I'élimination des silos qui existent encore
DevOps est tellement intégrée et itérative que présenter des produits finis (ou presque avec l'approche agile. Voyons les trois silos classiques de la plupart des modéles de
finis) aux clients a chaque fin de Sprint ne fonctionne pas. Le risque est trop élevé que cycles de vies avant 'agile
les clients veuillent ou aient besoin d'autres choses, y compris des besoins quils Chont water Développeurs Om nten
navaient pas envisages lors de I'élaboration des histoires, qui, si elles ont été mises en
ceuvre, ne déclencheraient pas simplement une correction de cap: elles nécessiteraient
une refonte. Pour éviter cette difficulté, les chefs de projet doivent migrer vers le =Srsapmm
Kanban et tenir les clients informés des mises a jour plus fréquentes, a l'aide d'outils
de communication modernes, de maniére a augmenter la vitesse de la
dati tion inue des ificati ? importantes Figure 1.8 — Les trois silos classiques du développement logiciel
demandées. Les plans de projets classiques doivent donc évoluer pour: Avec IAgile, le premier silo a été éliminé, car le client a été rapproché de Iéquipe :
~ trouvez des moyens de diviser des projets volumineux en morceaux permettant a Lr— Developpeurs Ops/infra
Tentreprise d'obtenir de la valeur rapidement. Il sagit ici d'adopter une approche =,
microservices la gestion de projets (la microplanification des projets), avec la
dimension supplémentaire de mesurer la valeur pour lorganisation de chaque
livraison rapide. Tout comme l'architecture de microservices divise I'application
‘monolithique pour entreprises en services plus granulaires, les projets peuvent n l L |
également étre scindés en taches plus petites et i Ce n'est Solution
pas nécessairement une nouvelle pratique de gestion de projet. Cependant approche Agi
DevOps propose de nouvelles mé comme I ion d'indi le
fonctionnalité pour déployer une fonctionnalité vers un sous-ensemble d'utilisateurs Figure 1.9 — Les deux silos du développement logiciel agile
~ assurez-vous que les activités de tests, lintégration et les déploi sont

Le DevOps vise a éliminer le dernier silo qui reste, celui avec les opérations et
infrastructures :
dans envir trés similaire a la ion et que les sont utilisés Chent utilsateur Développeurs
pour la nouvelle planification. Il est donc nécessaire d'ajouter et/ou de supprimer
fréquemment des éléments de la portée de la prochaine itération en fonction de ces
nouvelles informations ;
~ créez des plans légers qui prennent en compte du travail non planifié. Cela signifie
créer des zones tampons de projet, qui sinspire des performances passées, pour n
slassurer dleffectuer des travaux pour les incidents et les défauts qui peuvent Solution Solution
survenir. Agile Devops
Les SCRUM Master/I'équipe Kanban doivent étre des experts en dépendances Figure 1.10 — L'élimination des silos avec le DevOps
Lapproche microservices de la gestion de projet comprend un autre corolaire: tout Done, dans le tableau suivant (le tableau 1.1) on peut voir les différences entre l'agile
comme il existe de nombreux avantages potentiels a isoler les services de la méme et le DevOps:
maniére, il est é important de ps ces élé plus petits
fonctionnent les uns avec les autres. Ici, les gestionnaires de projet DevOps doivent
jouer un role important. A mesure que la vitesse de livraison augmente, il est de plus
en plus important de mettre accent sur les dépendances dans les logiciels existants.
Il y a maintenant moins de temps entre les déploiements pour intégrer quelque chose
d'une équipe en amont ou moins de temps pour obtenir les conditions requises par un
intervenant externe au projet. Il est essentiel de maitriser les méthodologies agiles pour
décomposer le travail en unités atomiques appropriées, ou leurs dépendances sont
bien établies. Des outils tels que les tableaux Kanban peuvent permettre une vue
immédiate des dépendances caduques et du travail bloqué qui en résulte. Tout comme
une architecture microservices divise un logiciel monolithique en petites parties plus

Tableau 1.1- Les grandes différences entre I'agile et le DevOps
Agile DevOp:
progressive de nouvelles fonctionalités 3 valeur et dopération du logiciel
ajoutée
Elimine Fécart entre les client utilisateurs et Eiimine lécart entre Iéquipe de
Féquipe de pour accélérer les et réquipe &
rétroactions concernant les exigences et opérations pour accélérer Ia transition
vers la mise en production
Est centré sur les exigences Est centré sur la ope ors
‘non-fonctionnelles de mises en production répétées et
assurer de Iétat de préparation du logiciel
prét a utiliser par les utilisateurs
Met beaucoup d'emphase sur 1a formation des DevOps divise les taches 3 des spécialistes.
membres d'équipe permettant, dans le cas de. mais s'assure d'une constante Infrastructure Agile
probleme, que n'i | membre puisse grace outils Liviaison Continue
aider 3 solutionner les problémes intégrés
ar; , qui est ps vi livrables selon Figure 1.11 — La convergence qualité qui a mené au DevOps (DevOps, 2021)
nt Ia livraison de fonctionnalités 3 la valeur pour la clientéle
chaque (mois, deux semaine...)
Le DevOps vise, entre autres, un alignement plus étroit et une collaboration continue Comprendre le DevOps n'est pas possible sans connaitre son impact sur cycle de vie
entre des roles qui étaient anci isonnés. Ceci nécessite l'utilisation d'un
doutils Par exemple I'équipe de dé pourra el
OC
préparer son infrastructure sur le nuage, installer ses outils, développer, mettre en
production et supporter leur produit logiciel. Pour ce faire, la gestion de projet doit étre
étroitement intégrée du point de vue de la pratique et des outils.
La montée en puissance de DevOps a généré toute une série d’avantages techniques,
en termes de main-d’ceuvre et d'affaires, de déplois des
délais d'exécution plus courts, des temps de récupération plus courts, des taux d’échec
de la modification moins importants, moins de modifications non planifiées et moins
optimistes, et des personnes encore plus heureuses. En effet, comme I'a noté le Figure 1.12 — L'influence du DevOps sur le cycle de vie agile (DevOps, 2021)
fabricant d'outils de configuration du logiciel libre, Puppet, les entreprises qui
améliorent les grace aux mé jes DevOps bénéficient d'une plus
grande fidélité des employés. Voici une bréve description de cet impact sur votre méthodologie agile ainsi que
certains outils qui font partie de cet écosystéme (certains liens peuvent étre brisés et
1.4.3 LE MODELE
DE CYCLE DE VIE DEVOPS cela nest pas sur notre controle. Nous les ajusterons pour la prochaine version):
Le DevOps est une convergence d'un app! qualité (voir Figure 1.11) Planification (plan): établissez votre tableau Scrum/Kanban en incluant la
pour améliorer la performance des équipes de livraison TL. 1 tire les lecons de mise en production continuelle,
T'approche « Lean » qui tente d’éliminer les étapes qui napportent pas de valeur ajoutée
en conjonction avec avenue des notions de livraison continue du logiciel. La figure 2. Développement (code) : dans cette étape de DevOps, le développement du
suivante décrit les influences de approche « Lean », du manifeste agile, de approche logiciel a lieu sur un environnement scripté de conteneurs du style
qualité de Toyota, du mouvement d'infrastructure agile et de la livraison continue. Kubernetes/Docker. Il est caractérisé par l'utilisation avancée d'outils (par
exemple : Git et Copilot) et il y a une tendance a architecturer les logiciels en
microservices de maniére que les petits composants soient tous indépendants
les uns des autres,
3. Construction de lexécutable (build): A cette étape, un nouvel exécutable est
assemblé et livré pour Iétape des essais. De nouvelles fonctionnalités sont
intégrées au code en vigueur constamment. Le développement continu n'est
possible quen raison de l'intégration continue (par exemple : Maven, Gradle,
Ant),

Test: Qui dit intégration continue signifie intégration de composants ~ Etudier les outils (ils ont choisi GitHub actions) et étudier ses « workflows ».
rd
complétement testés sinon ils seront retournés au développeur.

L'environnement de tests est aussi créé de conteneurs scriptés et chaque
développeur a créé ses scripts de tests et les scripts de l'environnement de test
s'assurent de lancer automatiquement les tests a la suite d'une construction Podcast sur Azure DevOps
d'un exécutable d'un nouveau composant. Des outils sont lancés
automatiquement pour identifier des problémes dans ce nouveau code. (par
le : JUnit, Jest, Cucumber jum, TestNG.); Finalement, le site https://hamess.io (Figure 1.13) présente un écosystéme
complexe d'outils qui sont & considérer pour passer vers une approche DevOps dans
Livraison (release) et déploiement (deploy): Les outils de versionnement Votre organisation.
"
(gestion de la configuration logicielle) et de déploiement de logiciels améliorent

les services de mise a jour existants, automatisent les taches de déploiement,
mettent en place les meilleures pratiques de sécurité et surveillent activité
DevOps Lifecycle Mesh
des 's et le foncti des icati Sans ces outils, les
équipes informatiques passent des heures & déployer et a suivre manuellement
les déploiements. Cela prend du temps et des ressources loin d'autres taches
importantes. Dans cette phase, le processus de déploiement a lieu en continu.
11 est effectué de telle sorte que toute modification apportée a tout moment
dans le code ne devrait pas affecter son fonctionnement en production
puisqu’il a été développé/testé dans un environnement trés similaire. Létape
de déplojement prend la derniére livraison et siassure quelle est placée en
HE
et pour par les utilisateurs.
(Brightsid Hleawictlos, Digital.ai Deploy, Kubernetes, Capistrano, Puppetet
I
Chef, Ansible, Engine, SaltStack, VSTS, AWS code deploy,
ae Actions/Bamboo))
Opération et Surveillance: Au cours de cette phase, Iéquipe exploitation
T
o
sc de surveiller le comportemen ié du logiciel et des sous-
I]
systemes/ infrastructures soutenants la production. (Zabbix, PRTG, centreon,
Solarwinds, AppDynamics, Dynatrace, Nagios, OpManager de ManageEngine,
Raygun, ...).
Figure 1.13 — L'accent sur les outils d'intégration continue du DevOps (figure hamess
io blogue)
1.4.4 L'IMPORTANCE DES OUTILS DE DEPLOIEMENT CONTINU POUR L EVOLUTION CONTROLEE EN
MODE DEVOPS
1.5 L’EVOLUTION DU LOGICIEL DANS UN CADRE AGILE
Vous pensez aller vers le DevOps alors préparez-vous a un changement culturel
important pour vos équipes de développement. Il sera nécessaire de vous préparer a
vos actuelles vers 1 ion. Clest ce qu'a fait Iéquipe
Dans cette section, comme le montre la figure 1.14, lintersection des activités de
d’étudiants du projet de sous-marin autonome Sonia, de 'ETS en 2021, en débutant
avec la refonte des conteneurs et de l'architecture logicielle en préparation au DevOps. agile et de ont été étudiées dans une grande
11 a donc été nécessaire de préalablement évaluer et expérimenter avec des outils avant banque Canadienne. De cet exercice nous avons soulevé les conclusions des adaptations
de formaliser la nouvelle approche. Léquipe de travail Sonia a da planifier ce projet et a faire aux groupes de maintenance pour qu'ils deviennent plus agiles.
prendre le temps de :
~ décrire le pipeline (workflo) de développement actuel (a l'aide de LucidChart) ;
~ revoir et documenter larchitecture logicielle de Sonia ;
~ se donner un objectif pour les déploiements en laboratoire et dans la piscine (deux
casd ion de dé iffe
~ étudier les « repos » Github actuels et les dépendances actuelles et Iimpact du
passage a Docker/Singulatity ;
~ Concevoir/formaliser Iapproche de branches de GitFlow (dev, master, fix..) &
normaliser ;

la confiance, ce qui finalement améliore le moral de équipe ». Un autre développeur a

déclaré que « l'utilisation du tableau des taches aide Iquipe a voir dans quelle mesure
le travail a été fait. Et quand quelque chose représente visuellement la progression de
différentes taches, alors a partir de la progression des taches terminées, la
reconnaissance de 'équipe peut étre vue ».
La seconde pratique qui a été améliorée par l'utilisation de i agiles

est la productivité des équipes adoptant I'agilité lors de la maintenance. De ce point
de vue, les Scrum master interviewés ont déclarés que « adoption de pratiques agile
a aidé a améliorer la productivité de léquipe. Certaines pratique agiles, en particulier
Figure 1.14 — La maintenance agile les pratiques liées aux tests, telles que le BDD et les tests automatisés, ont amélioré
la productivité des équipes pendant la maintenance. De plus, répondre aux questions
lors des réuni idi a aidé les de équipe & résoudr
Ce projet d’amélioration visait & utiliser diverses pratiques agiles qui ont été adoptées par obstacles, ce qui a finalement réduit le temps nécessaire pour solutionner des
les praticiens de la maintenance logicielle d'une équipe de la banque pour voir sil y avait problémes ». L'un des développeurs a exprimé son point de vue sur la productivité, «
des avantages, par exemple l'tération de planification, ltération de 2 semaines, le tableau comme toute 'équipe est responsable du code, alors tout probléme sera résolu en
Scrum/Kanban et ses histoires, les livraisons en petites versions, la réingénierie, la prenant une responsabilité collective ». En dehors de ces deux points de vue, un chef
programmation en binome, la propriété collective du code source, l'intégration continue, de projet a ajouté que « la hiérarchisation des taches en fonction des dépendances a
le développement piloté par les tests (TDD) et les réunions quotidiennes. Une liste amélioré la productivité et réduit les reprises de travail. En outre, le jeu d’estimation
davantages a été identifiée lors de la mise en ceuvre de ces pratiques dans I'équipe de lors de la planification aide a estimer l'effort pour les récits, en particulier pour les
maintenance (qui travaillaient relativement seuls dans leur coin avant ce changement) : éléments de arriéré de produit et la notion de « valeur ».
~ Amélioration du moral de Iéquipe,
~ Amélioration de la productivité, et La troisiéme pratique rapportée comme améliorant beaucoup la situation est la
~ satisfaction de la clientéle. satisfaction du client qui était calculée a l'aide d'un indicateur, 4 savoir I'indice de
satisfaction client (ISC). Cet indice est calculé en effectuant un sondage auprés des
Certaines autres prati se sont améliorées, mais moi , elles sont :
clients qui prend en compte divers facteurs concernant la satisfaction des services de
maintenance logicielle. La mesure est calculée pour chaque version d'un logiciel
~ Etablissement des priorités, ‘maintenu/supporté en production. adoption de I'agilité lors de la maintenance a eu
~ Formation (partage de connaissances), un effet positif sur cet indice de satisfaction. Un responsable a déclaré « en tant que
~ Correction des défaillances en production, gestionnaire de compte, mon objectif est d’améliorer cette mesure aprés chaque mise
~ Amélioration de la qualité du code, en pr Une au de cet i de nous que
les clients sont satisfaits et lorsque les clients sont satisfaits, les affaires vont mieux.
~ Amélioration des tests, Mais pour soul éci les prati agiles qui ont influencé cette
~ Estimés, situation, il y a le jeu d’estimation lors de la planification, le test d ion et la
~ Tindice de maintenabilité (IM), et démonstration fréquente. Au cours de la planification d'itération, les priorités pour une
~ la stabilité de la conception.
version sont identifies clairement. Permettre au client de participer a la décision
concernant les priorités de développement et de maintenance donne toujours aux
clients le sentiment qu'ils ont un intérét dans le travail. De la méme maniére, les
Les sections qui suivent décrivent en plus de détail chacune de ces pratiques. é aident a mieux iquer et prendre en compter leur avis et &
signaler quelques corrections ou aj ibles lors d'une
1.5.1 LES PRATIQUES DEVOLUTION QUI ONT LE PLUS PROFITE DE L’AGILITE gestion de ces révisions et corrections dans la méme version leur donne plus de
confiance dans notre processus ».
La premiére pratique qui a profité de utilisation de i agiles (par
exemple : les user stories, les petites itérations et le tableau des taches) a été 1.5.2 LES PRATIQUES QUI ONT MOINS PROFITE DE L’AGILITE
Pamélioration du moral de I'équipe. Dans ce contexte, les différents praticiens de
I'équipe de maintenance adoptant des pratiques agiles, pergoivent quils ont beaucoup Le comité de controle des modifications (CCM) qui agit en tant que propriétaire du
plus confiance dans le travail qu'ils font. Un développeur donne son point de vue en produit logiciel aide 4 les taches lors du dé et de la mai
déclarant que « des itérations courtes lors de la gestion de différentes taches d'évolution logicielle. Ce comité est typi de repr de tous les
controlée de mai aident toujrs nos équipes a obtenir les départements impliqués et choisit les priorités futures. L'un des Scrum master déclare
é plus rapi Les itérations courtes nous aident a nous concentrer sur que « l'obtention des exigences sous la forme de récits nous aide a hiérarchiser les
quelques taches, fournissant ainsi des solutions qui sont trés vérifiées et validées taches trés faci Comme les exi sont énoncées du point de vue de
lorsque nos solutions sont vérifiées et validées dans une large mesure, cela apporte de Tutilisateur ». Un gestionnaire déclare que « nous collectons ou traitons les récits a

Taide de JIRA, celui-ci collecte en fait toutes les informations sur un récit, telles que l'amélioration de la qualité du code pour améliorer surtout sa compréhensibilité. Nous
sa description et sa priorité. Nous utilisons cette approche pour l'arriéré du produit. avons vu dans un chapitre précédent que lorsque la compréhensibilité du code
Utiliser le méme outil par tous, aide également a fournir des informations sur Iétat s'améliore, cela améliore la productivité de l'équipe. Un SCRUM master rapporte « jai
des taches/ billets. De cette maniére, le comité CCM peut prendre une décision efficace rencontré des problémes lorsque je faisais travailler des membres de Iéquipe sur
sur les taches a accomplir lors de litération a venir ». certains modules. Les développeurs rapportent avoir des problémes pour comprendre
le style du code de certains composants. Mais lorsque les pratiques agiles de norme de
Une deuxiéme pratique qui a un peu profité d’utiliser 'approche agile est le partage codage, revue du code et travail en binomes sont utilisées, on observe que tout le
de la connaissance. Tous les projets de la banque qui ont participé a cet essai qui a monde dans léquipe comprenait mieux. Cela a conduit a une meilleure
impliqué de nombreuses plates-formes, de pre et compréhensibilité du code ». Un architecte déclare que « nous pratiquons les mises en
entre les diffe des . Lenvir est comme dans production quotidiennes. Cela se fait généralement a la fin de la journée. Et nous avons
toutes les grandes banques. Avant d’adopter lagile dans le groupe de maintenance prédéfini un ensemble de contraintes qui aide a vérifier notre version, comme une
nouvelle version est effectuée si le nombre des avertissements est inférieur a 100 et si
logicielle, chaque systéme était maintenu par un sénior (c.-4-d. un expert). Ce faisant, 70% de ces avertissements sont mineurs. Si ces contraintes ne sont pas satisfaites, je
les gestionnaires ont remarqué quil y avait moins de problémes de productivité vérifie immédiatement ou exactement le probléme survient et si le probléme provient
lorsqu'un sénior quitte le projet. Pour arriver a cette situation, il a fallu plusieurs mois,
car il est difficile de gérer la dette technique parmi les membres d'une équipe. Dans d'un certain développeur/mainteneur de Iéquipe, je lui demande de vérifier son code
cette optique, I'un des développeurs a déclaré que « l'utilisation de pratiques telles que afin de résoudre les problémes ». De cette maniére, différentes pratiques agiles aident
Péquipe a améliorer la qualité du code.
la programmation en binéme a joué un role majeur dans le transfert des connaissances
entre les membres de Iéquipe. Pour taches, nous j des personnes
qui travaillent sur différents systémes, ce qui non seulement nous aide a connaitre les Une suite de tests est une collection de cas de test (c’est-a-dire des cas de test unitaire,
autres systémes, mais nous aide é a répartir équi les des cas de test d’acceptation, des cas de test d’intégration, etc.) qui vise a tester le
entre les autres membres de Iéquipe ». Avant, chaque systéme avait un responsable logiciel & différents niveaux (cest-a-dire une unité, un composant ou un systéme).
technique sénior, qui était responsable des révisions de code et de la priorisation des Nous observons I'amélioration des tests grace a une approche de TDD (créer les
taches pour I'équipe. L'un des séniors a rapporté que « nous utilisons une approche tests avant de programmer) permet d’avoir de bonnes suites de tests et donne a I'équipe
automatisée de « pull requests » avec une liste de vérification pour les révisions de code. beaucoup de confiance, améliorant ainsi le moral de I'équipe et identifiant les erreurs
Cette approche aide le réviseur a réviser le code en prenant en compte différents dans le systéme tot. Un testeur déclare que « différentes pratiques agiles ont fait en
facteurs tels que les conventions de nommage. En utilisant cette approche agile, je sorte que nos suites de tests soient trés efficaces pour trouver des défauts dans le
peux réviser le code d'autres équipes travaillant sur des modules différents. De cette systéme. Différentes pratiques telles que les témoignages d'utilisateurs, la priorisation
facon, les développeurs/mainteneurs sont initiés a d'autres modules et apprennent des taches et la réingénierie ont toujours simplifié notre suite de tests. et efficaces. Les
également a connaitre leur foncti +. Un autre dé a déclaré que « user stories et la priorisation des taches définissent a lavance la portée du
dans notre projet, chaque module est développé en utilisant différents langages. Dans développement et définissent les attentes, ce qui nous aide finalement a savoir
ces situations, associer les développeurs de différentes équipes n’aide pas beaucoup. exactement ce qu'il faut tester. De méme, la ré vise a réduire la
Mais maintenant que des normes de codage spécifiques sont définies pour chaque du systéme, donc quand la complexité diminue le nombre de lignes a vérifier est
langage, cela aide a partager la connaissance. Ayant une certaine connaissance également diminué, donc les cas de test sont également rendus trés simples ».
autres technologies et aidé par des normes de codage, tout membre d'autres équipes
peut simpliquer dans diffé Et le foncti du module peut étre Dans tout envir de mai (cest-a-di rrective, perfective,
trés bien compris quand les équipes de travail sont petites ».
ive ou préventive), il est difficile d’estimer les taches. Etant donné
que de nombreux facteurs interviennent dans l'estimation de ces taches, il est en
Une autre pratique de mai la des en particulier toujours difficile pour les praticiens d'estimer le temps nécessaire a
identifiée comme une tache de mai orrective a profité légé de Panalyse de impact de lexécution de ces taches. Dans de telles situations, l'un des
techniques agiles. Tous les participants 4 cette étude effectuaient ce type de responsables de la qualité déclare que « estimation des taches de maintenance est
Ala suite de l'uti de pratiques agiles, un mai a trés difficile. Souvent, nous surestimons ou sous-estimons ces taches. Dans de telles
signalé que mai « chaque dé peut étre assignée a différents situations, il est toujours difficile pour nous de connaitre le nombre de taches dans
de équipe maintenant que tous font du développement et de la maintenance. Chacun une itération. Donc, pour gérer de telles situations, nous mesurons principalement
doit investiguer le probleme et tenter de le solutionner. L'équipe sintéresse plus aux notre vélocité, C'est-a-dire que nous calculons le pourcentage de taches attendues
tests automatisés pour vérifier si une solution au probleme va passer avec succés les terminées et de taches réelles terminées dans un sprint. Cela nous aidera a savoir
tests a l'avenir. Ainsi, les défaillances sont résolues rapidement, nous assurant de exactement quel serait le nombre de taches lors de la prochaine itération ». De la méme
vérifier notre solution” et cela en équipe ». Un autre développeur a signalé que maniére, I'un des développeurs a partagé son expérience « obtenir les exigences sous
« lintégration continue nous aide é a la forme d'histoires d'utilisateurs n'aide pas plus qu'avant a estimer le travail »
en production, prenant ainsi moins de temps pour traiter une deéfaillance ».
Lindice de maintenabilité (IM) est l'une des mesures utilisées pour savoir dans
La prochaine pratique qui a profité un peu de l'agilité concerne 'amélioration de la quelle mesure le logiciel est maintenable en termes d’analysabilité, de facilité de
qualité du code. Bien que tous les projets se sont toujours concentrés sur changement, de stabilité et de testabilité. Il est calculé par une formule qui est souvent

automatisée a l'aide d'un outil comme SONAQUBE. Différents projets utilisent

différentes versions de cet indice. L'équipe interne d'assurance qualité tente de
normalise cette mesure, mais ce n'est pas si facile en pratique et selon les technologies
utilisées. L'un des analyses de la qualité cite « en tant qu'analyste de la qualité, l'une
de mes responsabilités est de fournir des informations mesurables de la qualité du
logiciel a Iéquipe. Au cours de quelques versions majeures, j'ai observé que notre
mesure ne s'améliorait pas vraiment méme dans les équipes agiles ». De plus, I'un des
chefs de projet a ajouté son point de vue en déclarant que « nos planifications
ditération dépendent de quelques facteurs dont la complexité du systéme est un des
facteurs majeurs. Ainsi, 4 chaque itération, nous vérifions toujours, mais la complexité
du systéme reste complexe ».
Concernant la stabilité de la Parfois, la mai devient

incontournable et il faut faire une ou plusieurs itérations de réingénierie, comme nous Figure 1.15 — Graphe de mesure SPI : www. il .com / metrics /#T1
T'avons vu dans le chapitre précé clest-a-dire la modification de larchi edu
systéme sans affecter sa fonctionnalité. Elle est initiée lorsque larchitecture du
systéme subit une dégradation. Dans de telles situations, les différentes équipes Fi voici b ions pour mettre en place l'agilité dans votre
impliquées dans les projets de réingénierie pensent toujours de maniére proactive, groupe de maintenance. Premiérement, créez un arriéré de produit séparé pour vos
Clest-a-dire en évitant le systéme des problémes auxquels ils ont été initialement versions de maintenance. Ensuite, priorisez cet arriéré en mettant les priorités de
confrontés lors de la désintégration du logiciel. Dans ce contexte, l'un des architectes support de la production, Dans chaque carte de maintenance faites référence a cas
présente son point de vue en déclarant que « l'utilisation de I'agilité crée ce probleme dutilisation client de maniére que I'équipe puisse faire le lien entre le probleme et le
de conception rapide qui doit étre constamment revu.» Dans de telles situations, cas d'utilisation. Ensuite, assurez-vous de créer un gabarit de récit pour chaque
Tagilité crée cette problématique et dans certains cas cest pire qu'avec une approche catégorie de maintenance. Cela permet de soulever leurs différences de travail.
en cascade. Bien sir clest plus long, mais la conception est pensée 4 'avance ce qui
nécessite mois de retravail constamment.
Ensuite essayez de placer des récits de maintenance dans tous les sprints également
pour habituer I'équipe a faire des réingénieries et corrections mais pas
En conclusion, la prochaine section présente certains principes agiles qui sont utiles trop.
aux développeurs/mainteneurs des équipes agiles modernes.
1.5.3 PRINCIPES DE MAINTENANCE AGILE
En terminant, faites un suivi de la dette technique du logiciel et n’hésitez pas a faire
de la réingénierie quand nécessaire. Assurez-vous de garder une trace des heures de
versus mai séparée et cla r
Un certain nombre de principes agiles peuvent ainsi profiter aux taches de
maintenance dans les projets agiles. Ainsi il faut toujours garder a el que ce sont les
clients qui définissent notre succés et la maintenance du logiciel fais partie de cette
évaluation. Nous devons toujours effectuer des évaluations rapides et donner une
réponse rapide 4 un probléme. Les tests automatisés et l'intégration continue sont des
atouts pour les mainteneurs. De plus garder état des branches dans un état qui
permet de toujours pouvoir créer une version rapidement est un principe agile utile.
Finalement gardez la complexité d'une version le plus petit possible va contribuer aussi
a l'agilité de Iéquipe de maintenance. Voici un certain nombre de mesures qui peuvent
contribuer a 'agilité de votre groupe de maintenance :
~ Couverture d’automatisation CI - Couverture CI de Iensemble de tests de base
obligatoire pour les versions logicielles en %,
~ Profondeur de I'automatisation des tests - couverture de I'automatisation des tests de
toutes les exigences du produit SW en %,
~ Délai de cloture d'un probléme client - Délai moyen entre la création du probléme
client et sa cloture,
~ Indice de performance de la planification (SP) - Nombre dhistoires d'utilisateurs
exécutées ou panées dans un sprint (voir exemple a la figure 1.14),
~ Temps du cycle de probléme client - Temps moyen entre le travail du client identifié
dans une carte en progrés et son passage a terminer.

L'évolution contrdlée du logiciel 3 Les problématiques d'évolution continue du logiciel
2.1 INTRODUCTION
Le développement de logiciels, lorsquil est mené a 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 lopération
du logiciel que lorganisation découvrira des anomalies, ainsi que de nouveaux besoins
d'affaires qui feront surface, et quil faudra, aprés un certain nombre d’années, en
modifier la plateforme 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 par ion active des r dela
Les connaissances tout au long du processus de développement, quand c'est possible.
Jusqu’a tout récemment, le théme de la maintenance était peu abordé dans les cursus
fondamentales en évolution universitaires d'informatique et de génie logiciel, et c’était en travaillant dans les
or 1l que les logiciels s'i aux dela
i ety dé ent une expertise spéci Ce livre vise a combler un
du logiciel vide important dans I'ensei de la mai iciel e pour la i
La maintenance du logiciel est un des quinze grands thémes de connaissance reconnus
comme faisant partie de la discipline de Ingénierie du logiciel, tel que cela est décrit
dans la version 3 du guide au corpus des connaissances en génie logiciel (Software
Engineering Body of Knowledge - SWEBOK). Ce document confirme ce qui avait déja
Dans ce chapitre, nous couvrons : été identifié par Victor Basili en 1996 : « La maintenance du logiciel est un domaine
~ Les connaissances fondamentales du domaine, spécifique du génie logiciel, et conséquemment, il est donc nécessaire de se pencher
~ Lareprésentation SWEBOK de Iévolution du logiciel, sur des processus et les méthodologies qui tiennent compte des caractéristiques
spécifiques de la maintenance du logiciel. ».
~ Ladifférence entre opérations, développement et évolution continue (c.-4-d. maintenance),
~ Les qui de la maintenance/évolution du logiciel, Dans cette derniére version du Guide SWEBOK I'éditeur du chapitre de la maintenance
— Les normes et les processus de maintenance/évolution. est le professeur Ali Ouni, professeur a I'Ecole de technologie supérieure de Montréal ;
et le coéditeur professeur Alain April de I’Ecole de technologie supérieure de Montréal.
La version originale du chapitre de la maintenance, du SWEBOK, avait été produite
par Tom Pigoski et Alain April qui avait aussi piloté le développement de la norme
internationale ISO 14764 de la maintenance du logiciel. Il est a noter également que
plusieurs des concepts utilisés dans le modéle de la maturité de la maintenance : Le
Software Maintenance Maturity Model (April, 2016) a aussi été incorporé a la version
2022 du Guide SWEBOK. Le modéle de maturité de la maintenance S3m s'aligne donc,
dans toutes ses perspectives, sur ensemble des connaissances décrites dans le
chapitre Maintenance de la version 4 du Guide SWEBOK.
Le Guide SWEBOK présente une ie des i é a
Vingénieur logiciel travaillant en maintenance du logiciel (figure 2.1). Cette taxonomic
de la maintenance comprend cing axes :
Concepts de base,
~ Préoccupations clés,
Processus maintenance,
~ Techniques, et
Outils.
Faites la lecture du Guide SWEBOK pour approfondir vos
en maintenance du logiciel.

L'évolution contrélée du logiciel 3 Les problématiques d'évolution continue du logiciel
2.2 LA DEFINITION D’EVOLUTION DU LOGICIEL

‘Maintenance
dalogiciel Le cycle de vie du logiciel peut étre divisé en deux parties distinctes :
r t T \ 1. Le développement initial du logiciel,
concent | 1 | Techniques | outils | 2. L%évolution (anci appelée la mai et l'opération du logiciel.
de base clés | [maintenance Un survol des definitions proposées pour la du logiciel est présenté au
| | | tableau 2.1:
Définitions et Préoccupations - Processus de la Comprehension
nice | [Ee Nears unite Tableau 2.1 — Les définitions généralement acceptées
mh,” || sem Shim PT r— P— —
re «Les changements qui doivent tre effectués a un logiciel Martin et McClure: 1983
aprés sa livraison a ['utilisateur. »
fom «L'ensemble des activités requises afin de garder le logiciel | FIPS 1984
en état a la suite de sa livraison »
Figure 2.1 ~ Taxonomie de la maintenance du logiciel selon le Guide SWEBOK «La maintenance coue le cyce de vie du logiciel & parr de. | Von Mayrhauser 1990
son ir jusqu'asa mise a la retraite. »
1I convient de noter que ce guide ne prétend pas définir le corpus lui-méme des «La modification d'un logiciel, aprés sa livraison, afin de IEEE 610.12 1993
connaissances, mais servir plutdt d’abréger et de guide au corpus des connaissances ‘cortiger des défailances, d'améiorer sa performance ou
qui s'est développé et a évolué pendant les quatre derniéres décennies. En outre, ce autres attributs ou de adapter la suite de changements
corpus des connaissances n'est pas statique. Ce guide doit, nécessairement, se
développer et évoluer a mesure que le génie logiciel murit. II constitue néanmoins un
élément valable de Infrastructure du génie logiciel. «Le but du processus de la maintenance du logiciel est de | ISO12207 (1012207, 2019) Gadd
foumir un support efficace et rentable au logiciel opérationnel.
La litté e concernant la mai du logiciel est moins Les activités
de prélivraison incluent : la planification de mise en
que celle du développement logiciel. Les livres les plus récents sont ceux de Varga service, Ia prise en charge opérationnelle et Ia maintenabiits.
(Varga, 2017), Tripathy et Naik (Tripathy, 2014) voir leurs acétates ici, et Reifer (Reifer, Les activités daprés livraison (cad. suite & la transition)
Dailleurs, les publications en maintenance souvent citées dans les articles comprennent : l'opération et la modification du logiciel, le
2011).
scientifiques ont été publiées il y a déja 15 années, ou parfois méme 25 ans (Lientz et support opérationnel quotidien, telle que la formation aux
Swanson 1980 ; Martin et McClure 1983 ; Arthur 1988). Certains autres livres ne font employés du bureau d'aide (c.-4-d. help desk).»
qu'introduire la thématique de la maintenance du logiciel, comme Maxim et Pressman « La totalité des activités qui sont requises afin de procurer un | 1SO14764 2022
(Maxim, 2019). support. au meilleur cout possible, d'un logiciel opérationnel.
Certaines activités débutent avant la fivraison du logiciel, la
prélivraison, donc pendant sa conception initiale, mais la
majorite des activités ont lieu apres sa liaison finale. »
Professeur Lehman précise que «les changements étant inévitables, ils forcent les
logiciels opérationnels a évoluer, sinon ils deviennent progressivement moins utiles et
désuets » (Lehman 1980). 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.
11 est important de préciser que la maintenance du logiciel est nécessaire autant pour
les logiciels applicatifs que pour les logiciels dinfrastructure (par exemple : de
élé ications, de systémes d'opérations et de gestion des bases de données). Le
logiciel applicatif, lui, contient 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 rapidement,
changent et disparaissent pour supporter les opérations quotidiennes des
organisations pour qu'elles demeurent compétitives.

La norme ISO 12207 (ISO12207, 2019), décrivant les processus de cycles de vie du a trés court terme, et non par une équipe de projet comme dans la majorité des projets.
logiciel, présente I'activité de maintenance essentiellement comme l'un des processus de . Un employé de la du logiciel dé donc une
de cycles de vie et aussi comme le processus d'un produit logiciel subissant « une partie de son expertise a partir des mémes sources d’enseignement et de formation que
ion du code et de sa doct due a un probléme ou a un ses collegues du développement.
besoin d’amélioration. L'objectif est de modifier le produit logiciel existant tout en
préservant son intégrité. ». ISO 12207 décrit aussi « I'implémentation de processus ». Quelques auteurs ont étudié les activités qui sont uniques a la maintenance et qui ne
Cette activité de démarrage nécessite que lingénieur logiciel s'installe correctement se retrouvent pas dans un cycle de vie de dé de logiciels plus i
avant de modifier un logiciel. II établit les procédures et environnements/outils qui Certaines des caractéristiques qui sont propres au domaine de la maintenance du
sont utilisés plus tard, durant le processus de maintenance. logiciel sont :
~ +les requétes de modifications (RM) parviennent d'une maniére plus ou moins
ISO 14764 (ISO14764, 2022), la norme internationale pour la maintenance du logiciel, aléatoire et ne peuvent pas étre dans un annuel
définit la maintenance du logiciel dans les mémes termes que 150 12207 et met de budgétisation,
Facoent enue les activités de prélivraison (s-d-d. diavant fersiton) de 1a ~ les RM sont évaluées et classées par ordre de priorité (par le programmeur ou son
par Un est défini, par 11SO 12207, comme « une patron, ou parfois par le responsable du produit) ; aucune RM ne fait l'objet d'une
organisation qui effectue ee activités de maintenance ». autorisation spécifique par un gestionnaire en chef,
Finalement, ISO 12207 identifi les activités primaires de maintenance du logiciel. Ces ~ la charge de travail de la maintenance n'est pas gérée par des techniques de gestion
activités sont présentées, en détail, a la section 1.5. de projet, mais plutdt par l'utilisation des techniques de gestion des files d’attente
(dans un tableau SCRUM/Kanban),
2.3 LES DIFFERENCES ENTRE OPERATIONS, DEVELOPPEMENTET ~ 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 développeurs,
MAINTENANCE ~ les travaux sont ordonnés de maniere a satisfaire Tutilisateur, & court terme, et &
du bon iden des logiciels en opérati
11 est tout d'abord nécessaire d'établir une distinction claire entre l'opération d'un ~ les priorités peuvent changer rapidement, a toute heure du jour, et les rapports de
logiciel et sa maintenance. Ainsi, il est précisé dans la norme ISO 14764 que les problémes (RP) nécessitant des corrections de l'application de production auront la
activités d'opération (c.-a-d. copies de sécurité, télécommunications, gestion des priorité sur nimporte quel autre travail en cours. »
postes de travail, recouvrement et administration des serveurs, et bien d’autres) sont
effectuées par le a ion des iques et sont exclues de Léquipe de projet doit faire face aux événements et aux requétes journaliéres de sa
Ia portée de la norme. Cette distinction de concepts est aussi exprimée dans la clientéle tout en maintenant un service continu des applications opérationnelles sous
littérature qui décrit qu'il est peu qu'un i les sa responsabi
informatiques et la maintenance des logiciels.
11 existe une interface importante entre la maintenance et les opérations qui visent
surtout 4 s'assurer que les infrastructures, qui supportent les logiciels applicatifs, riven
soient opérationnelles et efficaces (c.-a-d. gestion des changements, appels concernant [—
in, ron
une en pr , recouvrement du logiciel et des données, et reprise des
travaux suite 4 une panne ou a un désastre, i des temps de trai
copies de sécurité, gestion des systémes d’horaires automatisés, gestion de I'espace
disque et de bandothéques). La gestion de cette interface est un role unique de
mainteneurs.
Quen est-il des é entre la i et le dé du logiciel ? Le

pr
développement du logiciel posséde, lui aussi, une interface avec la maintenance, mais
elle est un peu plus difficile a différencier. Cette différenciation est encore plus difficile
a observer si, dans une organisation, le développeur du logiciel effectue aussi la
maintenance de celui-ci. Dans une organisation qui utilise une approche Agile le
personnel effectue les deux roles.
En effet, un certain nombre des activités de la maintenance sont similaires a celles du

développement de logiciels (c.-a-d. analyse, conception, codage, gestion de la
configuration, essais, revues, mise en prediction et documentation technique). Ces Figure 2.2 - Processus d'acceptation ou de refus du travail d'un billet de maintenance quand
activités doivent étre au dela ou le développement et la maintenance sont séparés
le travail est souvent effectué par un ou deux ‘mainteneurs pour des travaux exécutés

Lorganisation des travaux de Iéquipe doit tenir compte de ces impératifs, et tant les 1. «Gestion des requétes de et de de modifications. Un
travaux de maintenance doivent se structurer pour répondre aux exigences de ce type processus de gestion des problémes utilisé pour établir la priorité, documenter et
de travail dont les éléments individuels arrivent de facon aléatoire. Par contraste, un les de quils 3
projet classique de développement est prévu a plus long terme, planifié, posséde un 2. Gestion de la transit on du dé au groupe de mai (quand il y a
échéancier déterminé, puis s'achéve avec la livraison du logiciel. Pour bien mener a des entités sépare), qui est une dlée et ée d'activités durant
terme ce genre de projet, une structure d’équipe de projet est créée pour la durée du laquelle le systéme est ér du dé vers le mai ar,
projet seulement, et clest cette équipe de projet qui développe un plan de ressources
La derniére version du chapitre de la maintenance du Guide SWEBOK, identifie aussi un
qui vise & atteindre des objectifs fixes d'une livraison dans les limites du délai et du bon nombre de a la mais en voici une
budget établi.
~ Gestion et planification annuelle de evolution du logiciel,
Du c6té de Iévolution et maintenance quotidienne du logiciel, lorsque l'utilisateur fait ~ Ententes de services et contrats spécifiques de support et maintenance avec les
une requéte de modification (RM), le mainteneur fera le nécessaire afin d’estimer effort clients,
qui sera requis pour modifier le logiciel existant. Si effort estimé est peu élevé et peut ~ Outilsde surveil des applications en pr ion (prévention de
étre satisfait a lintérieur des ressources et des disponibilités de léquipe de ~ Mesure dindicateurs de services spécifiques aux activités du support et de la
maintenance, la requéte est alors placée en ordre de priorité et exécutée & partir du maintenance,
processus de la gestion de la file d’attente. Toutefois, si effort estimé est supérieur a
une limite établie, propre a chaque organisation, et 4 sa marge de manceuvre ~ Etudes de différents types de requétes de changements supportées par un centre
budgétaire, la requéte sera réacheminée a une équipe de développement et traitée d'appel et son logiciel de support,
comme un petit projet qui devra étre autorisé avec son budget spécifique et une ~ Activités d'évaluation d'impact d'un changement,
allocation précise des ressources requises pour le mener 4 terme en fonction des - i en essais et en véri de régression,
nouveaux objectifs fixés.
~ In et réponses aux posées par les nouveaux développeurs et
Il'y a donc, pour la maintenance du logiciel, un processus unique d’acceptation ou de clients concernant les régles d'affaires des systémes opérationnels,
rejet du travail, pour les RM's des logiciels opérationnels. Ce processus tient compte ~ Processus unique dacceptation et de rejet du travail, pour les requétes de
de la taille estimée de la modification et de la capacité 4 la réaliser 4 l'intérieur des (RM) des logiciels opérati selon leur taille (quand il y a des entités
contraintes de couts et de qualité de fonctionnalité. séparées),
~ Gestion de Ihoraire de support aux opérations 24 heures sur 24 et du processus
Le professeur April présente, & titre d'exemple, le processus utilisé par lindustric des X en cas d' et de pi
ffort d'une requéte adaptative qu'un mainteneur ~ Gestion de l'nterface et du role des opérations (DevOps) portant sur : la gestion du
accepte est de cing jours (voir figure 2.2). On y note que seul un rapport de probléme changement, les appels concernant une faute en production, le recouvrement de
(RP), quel que soit I'effort estimé, sera pris en charge par léquipe de maintenance en Tenvironnement et des données a la suite d'un désastre, le recouvrement des données
priorité. Les RM’s seront placées dans des files d’attente et traitées par priorité. Cette et reprise des travaux, linvestigation des temps de traitements, les cédules
limite de cing jours deffort est aussi reconnue par le groupe de normalisation de automatisées, les copies de sécurité, la gestion des systémes, de lespace disque et de
Tétalonnage du logiciel (le ISBSG) : « On observe dans la pratique la distinction entre la bandothéque, et
Vactivité de maintenance des améliorations mineures et Iactivité de développement du ~ Gestion de la sous-traitance, des contrats de service de maintenance, de licences,
logiciel. Les auteurs ont observé que le seuil typique est de cing jours. L1SBSG adopte dentiercement et dimpartition.
aussi, la ntion quiune ion de cing jours ou moins sera
classée comme une activité de petite maintenance lors d'une itération agile. ». La définition du service rendu par la maintenance peut aussi aider a identifier des
Ce seuil correspond a de la petite maintenance effectuée par des individus, et non pas différences avec les autres activités informatiques. Ainsi, le professeur Bouman
par des équipes de projet qui peuvent entreprendre de grands projets de réingénierie. (Bouman, 1999), de I’école Polytechnique de Montréal, décrit la maintenance du logiciel
Cette notion de seuil est trés importante, car elle dicte le seul des travaux entre les comme un service. Les caractéristiques d'un service peuvent généralement étre
développeurs et les mainteneurs. Cette limite de cing jours ne doit pas étre utilisée reconnues ainsi
avec dogmatisme. Ce qui est essentiel, c'est qu'une limite du travail de maintenance ~ «Linsistance de la vente directe avec le client,
soit identifiée clairement dans lorganisation, quelle que soit la valeur d’effort choisie, ~ Un contact fréquent et direct avec le client,
et refléte bien le travail d'individus, et non pas d’équipes de projet. D'autres chercheurs ~ Un service rendu i plutét que plusier i apres,
ont identifié d'autres activités uniques 4 la maintenance : « l'étude des différents types ~ Un temps de service court,
de requétes de changements supportées par un centre d'appel (relp desk) et son logiciel
de support, les activités d’é dlimpact d'un en ~ Le produit n'est pas toujours un bien physique il peut étre un service ou une
essais et vérification de régression ». information.
Des processus clés et certains roles qui sont spécifiques 4 la maintenance du En résumé, la maintenance du logiciel posséde un certain nombre de processus et
logiciel ont été répertoriés: activités qui ne sont pas effectués par les groupes de développement du logiciel. La
maintenance du logiciel fait aussi appel a des processus et a des activités du

développement du logiciel, et ce, plus particuliérement dans Iétape d’analyse et le de vie logic:
diimplémentation d'une modification un logiciel existant.
Processus Processus Processus
s Fy i hni
2.4 LES NORMES D’EVOLUTION DU LOGICIEL Processus 4 Analyse
ot do 1a Mission)
Au cours des vingt derniéres années, deux grandes organisations internationales, ISO
et VIEEE ont développé des normes spécif repré les sur les Processus de services Processus d'Analyse des
Besoins et Ex: igences
pratiques exemplaires dans le domaine du logiciel. La norme ISO 12207 est utilisée, a
la téte de cette représentation, afin de séparer immédiatement les normes spécifiques Processus de Définition
de la maintenance des normes qui supportent l'ensemble des activités du logiciel, des spéci
Organisationels
requises autant par le développement et la maintenance que par les opérations de
informatiques. La figure 2.3 montre le processus technique de la maintenance, le Frocsssas de Gestion du Risque | Logicielle
processus 6.4.13 dans iS012207. Cycles de Vie -
= revo
reoces do Gestion |
Selon ISO 12207, la maintenance du logiciel est Tun des quatorze processus
techniques (technical process) du cycle de vie du logiciel. Les processus techniques de a
ITSO 12207 contiennent les activités de affaires, dex systéme, de Processus de Gestion de 1’information
conception architecturale, de mise en ceuvre, d'activités dlintégration, d'essais
systéme, d'installation du logiciel, d’essais de réception, de processus opérationnels, rrr — | Ir | Processus
a tmprimensation
de processus maintenance et de processus de mise a la retraite. Nous ne traiterons
pas, ici, des autres catégories de processus, car le texte s'tirerait en longueur. Vous
voudrez bien consulter la norme. La norme ISO 12207 précise que les détails a
[con de || fie” | a Tacegeation
pertinents a la maintenance du logiciel se trouvent dans une autre norme, la norme
ISO 14764. EEryrye—— pe—
rorvroeted
On précise, dans la norme ISO 14764 de la maintenance du logiciel, que lors de Processus do
l'utilisation des normes du développement, celles-ci doivent étre adaptées pour Transition
répondre aux exi él de la mai 11 est important de noter que Processus de
les normes ISO et IEEE sont développées sur la base des consensus internationaux validation
des pratiques utilisées par tous dans l'industrie. Ces normes ne comprennent pas
écessail les normes, jes et app industrielles récentes. Il existe,
bien entendu, d'autres pratiques reliées a la maintenance et qui n'ont pas encore
atteint le stade de la normalisation internationale, comme le les activités de support &
la clientele, la transition, les ententes internes de services (Service Level Agreements)
et les de mai émes. 1 est iel dutiliser les
recommandations de I1SO 14764 dans les organisations de maintenance du logiciel. pro
Mise A la Retraite
Pour ce faire, il sera nécessaire de mettre en ceuvre un projet d’amélioration des
processus. Figure 2.3 — Les processus de génie logiciel et de maintenance (15012207, 2017)
Limplémentation d'une norme dans une organisation représente nécessairement un
changement a des pratiques courantes, et tout changement doit étre géré avec soin
pour réussir. Schmidt (Schmidt, 2000) indique quil n'est pas réaliste d'essayer
diimplanter simultanément toutes les normes, car cela représente des changements
i és trop considé pour une isation. Une implé ion progressi
des normes est plutot suggérée, et Schmidt propose d’établir une relation directe entre
la maturité d'une organisation et son utilisation des normes. Schmidt propose donc
une pyramide qui décrit l'utilisation progressive de normes IEEE, basée sur quatre
facteurs :
1. Le niveau de criticité du logiciel,
2. La taille des équipes,
3. La maturité actuelle des processus, et
a8 ©2023 Edition Smart, 2023 - Tous droits réservés 49

4. Les réglements et obligations externes. Le modéle propose qu’au niveau 2, l'utilisation du Guide SWEBOK identifie le corpus
de la connaissance qui devrait étre connu par le personnel de maintenance du logiciel
Lorsque le niveau de criticité du logiciel les de et pour aider & identifier toutes les références qui sont 4 sa disposition. L'éveil d'une
de maintenance exigent de plus en plus de rigueur. De méme, quand la taille des de la ible est marqué par l'utilisation des normes
équipes augmente, il devient nécessaire d'utiliser de plus en plus de normes afin de principales de la maintenance du logiciel (ISO 14764 et ISO 12207). Cette étape est
les pr les ications et les interrelations entre les importante, car elle permet au T'adoption de la terminologie et des processus
participants. clés du domaine. Ces normes établissent aussi les caractéristiques des entrées et des
sorties de chaque étape des processus clés.
A la figure 2.4, nous avons utilisé approche de Schmidt pour créer un modéle de
maturité simple de normes applicables a la maintenance du logiciel. Dans cette Le niveau 3 est caractérisé par plus de rigueur dans les procédures de travail avec
pyramide, le niveau 0 décrit seulement la présence de normes individuelles T'utilisation des normes pour la documentation, la gestion de la documentation ainsi
par le p . Ces normes se caractérisent par absence que utilisation d'une approche systématique des revues. Les notions de l'assurance
dutilisation de normes nati oui de du logiciel. Il est qualité se concrétisent et apparaissent autant dans les processus que dans les logiciels
possible de se situer a ce niveau sil ny a pas dobligati , que le maintenus. Le personnel de la maintenance documente comment adapter ces normes
logiciel est d'un niveau de criticité faible et que la clientéle ne requiert aucune norme 4 ses besoins spécifiques.
de travail.
Le niveau 4 ajoute a cette liste un processus de mesure du logiciel et de la mesure de
La maturité d'une isati aussi une i sur le nombre de normes la taille fonctionnelle. La mesure de la taille fonctionnelle est faite pour toutes les
qui peuvent étre i aux processus i des requétes de modifications qui encourront un changement au logiciel maintenu. Les
sans faire l'objet de rejet. Finalement, l'environnement externe peut aussi créer des recueillies i a lorganisation d’établir un entrepot
obligations d'utilisation de certaines normes, sinon les produits de sortie pourraient de données contenant Ihistorique des travaux de maintenance, On y propose
ne pas étre aux re d'une i ie particuliére ou d'un également l'utilisation des normes d’exigences, de la mesure de fiabilité, de la
client : ire, médical et aér documentation des essais unitaires, de la gestion de la configuration, de la
des ies ainsi que des de qualité du logiciel. Le niveau 5
Le niveau 1 est connu pour étre le niveau initial de maturité des processus en matiére propose l'utilisation de toutes les normes applicables de la maintenance du logiciel.
de génie logiciel. La description des processus se fait 4 un niveau trés élevé et est
caractérisée par I'absence de processus détaillés. A ce niveau, Iorganisation du travail Ce modéle de ité d'une pyramide des normes apli en mai (figure
peut néanmoins étre décrite en utilisant le cadre de référence de la maintenance du 2.4) a été proposé pour illustrer une stratégie dimplémentation des normes
logiciel de la norme ISO 12207 qui présente un modéle général des activités de la internationales pour la maintenance des logiciels. Ce modéle est une proposition
maintenance du logiciel. théorique de idt. Une expéri ion en industrie it de Iévaluer et dy
suggérer des améliorations.
En résumé, il y a déja plus de 200 normes en génie logiciel. Une de ces normes est
centrale pour la maintenance du logiciel : ISO 14764. Le domaine de la maintenance
fait référence aux normes spécifiques du développement du logiciel et de deux de ses
processus de support. Il faut donc utiliser les normes du développement du logiciel en
prenant soin de les adapter au contexte spécifique de la maintenance. A ces normes,
il faut ajouter les nouvelles pratiques en émergence qui, tout en étant prometteuses,
Fable Tres 1 foci) Fable n'ont pas encore fait l'objet de de la part des
peties 1SOEC 12200
1220 Ld nombre de normalisation.
2 Schmidt est d’avis que le modéle des processus de la maintenance, décrits dans 1SO
Modérée Petites. ISONEC 14764,
IEEE 1219 Processus Nombre
ete Guide SWEBOK gérés modéré 14764, correspond approximativement aux pratiques de niveau 2 du modéle du Sei.
Enfin, une ion pour le ine de la mais du modéle de idt est
Impotante ~~ / Moyennes SOIC 001, 9125, 6254 15504 Processus. Nombre présentée pour illustrer comment on pourrait introduire les normes selon une
IEEE 1028, 828, 829, 1012, 1062, 9294 \ _ déployés important corre au niveau de é des
4
Elevée Grandes ISO/IEC15839, 19761 Processus. Nombre
IEEE 830, 062.1, 1008, 1042, 1044, 1061 matures deve 2.5 L’ACTIVITE D’EVOLUTION DU LOGICIEL
Critique Tres [] Tres Nombre
Grandes ‘Toutes les normes pertinentesdu génie logiciel matures eleve 11 a été observé que plusieurs organisations n'ont pas de processus clair pour les
activités de la maintenance du logiciel. La vue traditionnelle du cycle de vie du
développement du logiciel a fait un grand tort au domaine de la maintenance en le
Figure 2.4 — Pyramide de normes applicables — un modele de maturité simple représentant comme une seule étape la fin du cycle. Encore aujourd'hui, beaucoup

de mé jes du dé ne é méme pas létape de la Processus de Maintenance Logicielle

maintenance du logiciel, incluant l'agile. Il y a bien entendu une explication historique Retraite
a cet état de fait : au tout début de l'industrie du logiciel, il n'y avait pas de différence
entre le développement et la maintenance du logiciel. Ce n'est que dans les années 70 Se préparer a
que les premiers modéles de cycle de vie spécifiques au processus de la maintenance maintenir
sont apparus. En général, ces premiers modéles du cycle de vie de la maintenance du
logiciel sont découpés en trois étapes :
1. Compréhension,
2. Modification,
3. Validation du changement au logiciel.
Transition
Les années 80, elles, ont apporté des modéles orientés sur le processus de la
maintenance. La maintenance du logiciel ny est plus représentée comme la derniére
étape du cycle de dé . Cette de modeles pré les
activités spécifiques de la maintenance et introduit une préséance pour chaque Figure 2.5 — Modéle du métaprocessus d'ISO 14764
activité. Certains consultants définissent également leurs propres modéles offrant une
variante d’activités spécifiques a la maintenance. La figure 2.5 présente les quatre processus plus opérationnels d1SO 14764 :
+ Le processus de préparation a maintenir un logiciel : ce processus vise a définir la
Clest ensuite dans les années 90 que se sont développés les premiers consensus stratégie de maintenance, établir les priorités, identifier les techniques et
internationaux tant sur la terminologie que sur les cadres de référence pertinents a la méthodes & utiliser, effectuer des revues périodiques de larchitecture/design du
: les normes (ISO 12207 et ISO 14764), lesquelles sont
logiciel, établir les procédures d’accés aux données sensibles et les connaissances
encore utilisées aujourd’hui. Ainsi, la norme centrale ISO 12207 représente la
requises qui seront nécessaires,
maintenance comme si elle recoupait plusieurs autres étapes du cycle de vie du © Effectuer des maintenances : consiste a effectuer I'analyse des modifications et des
logiciel, Clest-a-dire que sa réalisation peut nécessiter de parcourir, partiellement ou
totalement, la plus grande partie du cycle de vie du logiciel. problémes a effectuer. L'équipe doit faire Ianalyse de chaque requéte (c’est-a-dire
la requéte de modification ou un rapport de probleme), la classer dans une
Pour bien situer et encadrer la maintenance du logiciel, nous présentons maintenant,
de travail, (en la et vérifier que la
ala figure 2.5, un diagramme général (Cest-a-dire un métaprocessus) du cycle de vie requéte est valide, enquéter et fiaboees! une solution, documenter la requéte et la
de la maintenance du logiciel. Les processus et activités de la maintenance du logiciel proposition de solution, et, obtenir les au pour
sont documentés, en détail, dans la nouvelle version de la norme internationale ISO
effectuer les modifications. Les activités de ce processus sont :
14764 de 2022. o Effectuer Ianalyse initiale,
© Verifier le probleme ou I'amélioration,
Bien str, chaque organisation et chaque fournisseur peuvent développer leur propre © Développer des options pour l'implémentation d'une modification,
proposition qui, dans l'ensemble, devrait contenir l'ensemble des processus de cette
norme internationale. Les quatre processus clés (par exemple: effectuer la © Documenter les résultats,
maintenance) de la figure 2.5 qui sont plus opérationnels sont au centre de la tache © Obtenir I'approbation d'une option de modification,
le maintenance d'un membre de Iéquipe agile. Pour la norme ISI14764, le processus Développer, coder et tester la modification,
°
de développement (qui se situe a l'extérieur) est percu comme un autre type de travail. Mener les revues,
Quand le mainteneur travaille en mode de maintenance, il ne fait pas tout a fait les
mémes travaux (par exemple i de la pr ion, entente de © Migrer en production.
service, etc.). Il pourra se dédier a la perspective de la maintenance continue, i fera la + Le processus de support logistique (de plateformes, par exemple) nécessite de
planification et la création du plan de la maintenance, la préparation de la gestion des s'assurer que la capacité des infrastructures sont adéquates. S'assurer d'obtenir
problemes identifiés durant le développement, le suivi de la gestion de la configuration les ressources et faire le suivi de ces mises & niveaux,
des produits de sortie, etc. «Le processus de gestion des résultats de la maintenance et de la logistique. Ce
processus est actif quand le logiciel est en production :
© Faire le suivi quotidien du rendement (niveau de service) de application
en production,
© Enregistrer tous les incidents et les problémes,
© Publier des indicateurs de tendances des incidents et problémes et leurs
causes,
© Sassurer de la tragabilité des artéfacts du logiciel qui évolue,

© Bien gérer les versions des artéfacts du logiciel qui évolue, et I1SO 14764. 1SO 14764 fournit des lignes directrices pour créer un plan de
© Mesurer la satisfaction de la clientéle. maintenance.
Finalement, au plus haut niveau, organisation de maintenance devra réaliser des

En plus des processus identifiés dans les normes internationales, il faut noter que les activités de i d'affaires et
mainteneurs effectuent aussi des activités de soutien/support, telles que la planification comme toutes les autres divisions de la compagnie. Dans ce but, les connaissances
de la maintenance, la gestion de la configuration de logiciel, la vérification et la validation, requises peuvent étre trouvées dans les disciplines de gestion.
T'assurance qualité, les revues et les audits, et la formation des utilisateurs. Certaines de
ces activités de soutien ont retenu attention des chercheurs, par exemple la formation Une autre activité de soutien importante en maintenance consiste a s'assurer d'une
le de la et les activités particuliéres de bonne gestion de la configuration du logiciel (GCL). La norme 1SO 14764 pour la
planification de la maintenance. maintenance du logiciel décrit la gestion de la configuration comme une activité
Une activité importante de la mai du logiciel est la planification. Les critique de soutien pour le mainteneur.
édent quatre perspectives de planification qu'ils doivent :
1. La planification d'affaires (niveau organisationnel), Les procédures de gestion de ient traiter de la ion, de la
2. Le plan de maintenance (niveau d'un nouveau logiciel qui fera objet de transition), validation et de audit de chaque version du logiciel requise pour identifier, autoriser,
implanter et mettre en production le produit logiciel. La prochaine section décrit plus
3. La planification des mises en ion et versions égie), et en détail I'activité de gestion des versions d'un logiciel maintenu.
4. Le suivi des RPs et des RMs (niveau individuel de chaque billet).
a niveau de la demande individuelle, la planification est faite durant Ianalyse d'impact. 2.5.1 LES CATEGORIES DE TRAVAUXDE LA MAINTENANCE
DU LOGICIEL
ion des misesen ion et versions nécessite que le mai ar:
— Collecte les dates ou seront disponibles les demandes individuelles, Lientz et Swanson ont été les premiers a publier une liste d’activités quotidiennes
~ Se mettent d’accord avec les utilisateurs sur le contenu des prochaines mises en
dévolution et maintenance du logiciel en trois catégories : corrective, adaptative et
perfective. Ont suivi les travaux de normalisation 4150 (15014764, 2022) catégorisant
production et versions, les activités de la i en six Les ies de travail de la
~ Identifie les conflits potentiels et développe des alternatives, maintenance définies par ISO sont :
~ Etudie le risque d'une mise en production donnée et développe un plan de secours = ir ‘la ion (ou réparation) réactive d'un logiciel exécuté
au cas 0 un probléme surviendrait, et apres Ia mise en production dun logiciel pour corriger des problémes découverts par
~ Informe toutes les parties prenantes. sa clientele,
i préventive : la modification d'un logiciel aprés sa mise en production
Meéme si une nouvelle version mise en production peut contenir des éléments autres pour détecter et corriger les défauts latents avant quiils ne deviennent des défaillances,
que des modifications logicielles, le centre d'intérét et la responsabilité du mainteneur ~ Maintenance adaptative : la modification d'un logiciel exécuté aprés sa mise en
de logiciel sont limités au logiciel. production et qui vise 4 maintenir le logiciel utili dans un
technique modifié ou changé ou en cours d’évolution. Par exemple lorsque le systéme
La ou les dé peuvent durer typi de mois & exploitation est mis a niveau,
années, la phase de is dure habitu de années. Faire
une estimation des ressources est un élément clé de la planification de la maintenance.
~ Maintenance additive : la modification dun logiciel aprés sa mise en production pour
Ces ressources devraient étre incluses dans la planification du projet du développeur. ajouter des foncti pour améli i du logiciel,
~ Maintenance perfective : la modification d'un logiciel aprés sa mise en production pour
La planification de la mai devrait avec la décision de développer sa son (par exemple sa performance) ou sa
un nouveau systéme et devrait s'intéresser a des objectifs de qualité. Un document de (par exemple sa mai ilité) ou d'autres attributs qualité, et
concept devrait étre développé, suivi par un plan de maintenance. - i durgence : ification non planifiée ée pour
i un logiciel opérati en deeffectuer une
Le document de concept pour la maintenance devrait traiter de : corrective par la suite.
~ La portée de la maintenance,
Ladaptation du processus de © maintenance, La norme i ionale ISO 14764 considére les travaux de
- Li ion de organi de et additive et perfective comme des améliorations au logiciel existant. Cette norme
regroupe également les catégories corrective et préventive dans une catégorie nommeée
~ Llestimation des couts de maintenance. correction, tel qu'elle est représentée a la figure 2.9.
Létape sui est de dé un plan de mai Le plan de Aujourdhui, le consensus international tant, sur les titres de ces catégories de travail
devrait étre préparé durant les itérations de développement du logiciel et devrait de maintenance que sur leurs définitions, est codifié dans la norme ISO 14764. Il est
spécifier les utili nt des modifications et rapporteront les a noter que deux critéres ont été utilisés pour cette catégorisation :
problémes en production. La planification de la mai est discutée dans

Critére 1 : le travail consiste soit en une correction, soit en une amélioration au logiciel, Prometheus. Une alerte critique serait, par exemple : le nombre de serveurs actuellement
Critére 2 : le travail est soit proactif, soit réactif. disponibles et chutant rapidement (c.-a-d. qui sont en défaillance), ou encore un manque
espace disque sur les bases de données de I'application, ou encore un temps réponse
plus lente que la normale (c.-a-d. du seuil établi) pour une transaction.
Voici un exemple d'un processus de réponse aux incidents d'une équipe agile d'une
entreprise de 85 employés en informatique:
1. Le responsable de l'incident, qui est souvent la personne en support qui réagit en

premier & lalerte, se charge de créer un canal Slack dédié 4 incident afin que les
[ounce différents acteurs puissent communiquer efficacement concernant cet incident. II vérifie
dans la base de données des incidents si la solution existe déja. De plus, le responsable
de lincident doit sassurer de pouvoir communiquer avec le reste de lentreprise
concernant le statut d’avancement de la résolution de cet incident (c.-a-d. escalade en cas
de défaillance prolongée ~ tel que décrit dans lentente de service),
Corrective Préventive Adaptative 2. Le responsable de l'incident (c.-a-d. le dé i attribue les
roles aux personnes pré dans le but d'i if le pr é le
Figure 2.9 Catégories de maintenance logicielle (ISO14764, 2022) possible (c.-4-d. est-ce un probléme dinfrastructure, de données ou d'application elle-
méme),
Diautres modéles de processus font leur apparition, réguliérement dans les 3. Les diffé des opé impliquées ont is
pour décrire les de la mai du la permission de modifier l'infrastructure afin de résoudre le probléme si celui-ci provient
logiciel. Quelques chercheurs ont également proposé des versions initiales d'une de infrastructure sous-jacente a I'application. Si c’est le cas, ils doivent modifier I'état du
de la mai une repré une vision d'un domaine billet en conséquence et avertir les intervenants internes du statut,
d'une maniére plus précise. Mais approche actuelle qui est utilisée en industrie est
agile (c.-a-d. Scrum/DevOps). Dans cette approche l'équipe doit décider si la
maintenance fera partie des taches quotidiennes de tous ou bien si quelques membres 4. Les autres aider 4 la résolution de incident, en particulier les
de I'équipe devront s'y concentrer ?
développeurs/mainteneurs qui sont experts concernant fonctionnalité touchée par
Vincident aident a trouver la cause et peuvent proposer une solution au probleme si celui-
2.5.2LA REPONSE
AUX DEFAILLANCES ET INCIDENTS EN PRODUCTION
ci provient de la base de données ou bien de application elle-méme,
Un incident d'urgence peut étre déclaré durant les heures de travail. Dans ce cas il est 5. Le chargé de la communication externe, souvent un membre de léquipe de
développement/support, propose un message a communiquer aux clients touchés par
partagé par toute léquipe des avec l'aide des dé» ars, si Incident, et met a jour la page de statut du billet d'incident,
besoin. Cependant, un incident peut aussi se déclarer en dehors des heures de travail
alors il faut sassurer d’avoir du personnel de garde. Dans ce cas, la responsabilité est 6. Quand la défai est solutionnée, le de lincident organise une réunion
assurée par la personne qui est en support avec une rotation hebdomadaire. La stratégie de post-mortem avec les différents membres ayant participé a la résolution de lincident,
a des incidents notifie tous les intervenants dans le cas on la personne chargée
de répondre a lincident ne peut pas répondre ou ne sait pas comment résoudre 7. Le responsable de l'incident remplit les informations de résolution billet (Post-Mortem)
incident.
avant la prochaine réunion, en particulier en décrivant Incident et les différentes étapes
Un incident est déclaré si un probléme posséde une de ces propriétés : ‘menant a sa résolution, avec une liste d’activités chronologiques dans la base de données
des incidents.
~ Une erreur ématique de 1’ icati plus de deux
Une erreur systématique de application affectant plus de deux RM's déja ouvertes (c.- Ainsi, vous pouvez voir quil est souhaitable que vous mettiez en place une base de
a-d. requétes liées), données de connaissance (c.-a-d. une base de données des incidents) qui inclut les
Une erreur empéchant un utilisateur de réaliser une tache critique ou limitée dans le incidents et la recette pour les régler. De cette maniére si un incident réapparait alors la
temps. recette de la solution sera disponible plus rapidement. Plusieurs outils sont disponibles
a cet effet = gine, Jira Service SolarWinds, Nagios et bien
Ces incidents sont identifiés dans des billets qui portent la bonne catégorie de d'autres.
maintenance (tel que vu a la section précédente). Avec l'avénement des outils de

surveillance des logiciels, les incidents peuvent aussi étre déclarés automatiquement, par
exemple avec loutil PagerDuty a partir de différentes alertes programmées
automatiquement dans le logiciel de surveillance des opérations, un autre exemple

2.5.3 LA GESTION DES VERSIONS DU LOGICIEL EN EVOLUTION/MAINTENANCE CONTINUE
11 n'est pas suffisant de seulement faire le suivi des demandes de modification ou des
rapports de probleme d'un logiciel en évolution/maintenance continue. Le produit
logiciel et tout changement qui lui est fait doivent étre controlés. Ce controle est établi
par létablissement et le maintien d'un processus approuvé de gestion de la
configuration (GCL), qui est un des processus de gestion identifiés a la figure 2.3. La
norme 1SO12207 fournit des détails a propos de la GCL et présente le processus par
lequel sont soumises, évaluées et approuvées les demandes de changement a un
logiciel. De plus en plus on observe qu'en mode agile, il y a beaucoup de petits
changements qui doivent étre controlés dans un systéme opérationnel. Un processus
de gestion des versions du code source doit nécessairement étre implanté et souvent
automatisé en développant et en suivant un plan de gestion de configuration et des
procédures d'opération. Figure 2.6 — Un mauvais choix de stratégie de branche
Ainsi I'équipe et les développeurs/mainteneurs doivent décider des éléments (c.-a-d.

les artéfacts) qui seront controlés et gérés pour un logiciel applicatif en opération. Ca Branches, paquet de service, hotfix et fusion
peut étre de la documentation, du code source et tout autre artéfact important qui
changent souvent d'état. Ces artéfacts sont appelés des Eléments sous Configuration Branco : nit dieceion do zones de travail dar laquelle on peut ravaler sur un problime,
Logicielle (ECL) quand ils sont gérés dans le systéme de gestion des versions. Une ns affecter les autres zones de travail.
dECL est une ion controlée d’ECLs congue pour faciliter le pi nche de _dével ent : Iendroit oli I'équipe de développement travaille 4 faire des
T ion et la mai de ces ECL lors de Iévolution changements pour une prochaing version du logic.
continuelle du logiciel. La GCL est essentielle et incontournable aux activités de gestion Branche de livraison : Iendroit oi I'équipe de développement travaille & régler des problémes.
des versions et des activités de livraison d'un projet ou d'une modification au logiciel. avant la livraison nae dune nouvelle version.
Plusieurs types de bibliothéques peuvent étre employés. Par exemple, on peut utiliser branche qui contient le logiciel courant de production (version utiisée par
trois (3) types de bibliothéques : les clients ee vam et stable. Cette branche peut étre rendue accessible aux équipes de
tests et équipes extemnes.
Bibliotheque privée qui est utilisée par le développeur pour réaliser ou modifier les
éléments de configuration ou faire la mise au point et les tests unitaires, K) : et i qui
S'adressent a une version d'un logiciel livré et utilisé par la clientele. Un paquet de service
~ Bibliothéque de projet qui est commun a tous les membres d'un projet, qui contient contient plusieurs éléments et est livré sous forme d'un seul paquet qui est installé en une seule
les éléments susceptibles d'étre utilisés par d'autres personnes que leurs auteurs. opération.
Cest la source officielle de toutes les informations concernant le projet. Son accés est Hotfix : Correction de défaut ou petite fr fonctionnele dun logico, disso par una
controle, maison d'édition (terme ir et destinée a ua
~ Bibliothéque publique qui offre des composants communs & plusieurs projets. modifier au moins un lément de 1a version acueliement utlisée par fo lot,
Fusion vers avant : une fusion des branches parents vers les enfants.
Bien sur le code source est ECL qui sera le plus sollicité et changé au travers des Fusion vers l'arriére : une fusion des enfants vers les parents.
années. Lors de la configuration de la bibliothéque de GCL un certain nombre de
décisions doivent étre prises par Iéquipe. Concernant la gestion du code source du Nous aimerions remercier Etienne Tremblay, qui passe souvent au Visual Studio Talk
logiciel, un plan de GCL devrait suggérer une stratégie de branches qui sera Show de Montréal qui a fait un Podcast ), en Francais, a ce sujet (note : le sujet démarre
appropriée pour le projet/logiciel spécifique. 411 minutes du début de son Podcast). Ce Podcast est accompagné d'une présentation
de vulgarisation efficace dont nous nous sommes inspirés pour présenter le texte qui
Pourquoi on fait une branche de code source pour aller travailler dessus? Eh bien c'est suit. Merci Etienne. Avant de commencer la description des différentes stratégies de
pour s'isoler afin daller travailler sur un changement. De cette maniére mon travail branches de code source, dites-vous que chaque branche a un cout, alors assurez-
n'a pas d'impact sur la version de travail d'une autre personne. Dans les logiciels vous d’en créer le mini écessaire pour votre projet spécifique. Le cout réel d'une
denvergures il y a souvent sept ou huit développeurs dans une équipe et alors sans nouvelle branche est un cout adi iel lors de l'intégration et des tests.
slisoler pour travailler cela va causer tout de sorte de mots de téte. Avant de créer Nous présentons ici quatre (4) stratégies populaires (c.-a-d. des patrons de GCL) pour
toutes sortes de branches et en créer trop (ou pas assez), il y a des stratégies de vos branches :
branches, pour le code source, qui sont proposées par des experts, dont Microsoft qui
publie son guide « adopt a Git branching strategy » Vous trouverez aussi de 1. Simple : 2 a 5 développeurs qui travaillent ensemble sur un méme projet qui évolue
linformation proposée par Martin Fowler dans son guide « Patterns for Managing tout en méme temps,
Source Code Branches ». La section qui suit fait un sommaire des stratégies de base
pour les branches de code source typiques utilisées lors de projets de I'évolution d'un 2. Typique :5dé s et plus qui ilent sur un projet qui évolue
logiciel. résultant en plusieurs versions & conserver (release 1, release2, ..),

3. Avancée : 5 développeurs et plus qui travaillent sur un projet qui évolue résultant La stratégie typique de : Cette stratégie répond aux besoins de plus de 80%
en plusieurs versions nécessitant des « hotfix » et des paquets de services, des projets logiciels. Cette straé ite de créer trois (voir figure 2.8):
4. Fonctionnelle : 5 dé urs et plus qui travaillent sur des fonctions spécifiques n la branche principale, 2) la branche de développement et 3) la branche de version
d'un projet qui évolue résultant en plusieurs versions. Qui peut aussi étre utile des Dans cette stratégie nous ne travilons pas dans la branche principale.
équipes dans différentes villes/pays. La ‘branche principale sert & lintégration. Cette égie propose que I'équipe de
développement travaille dans la branche de développement dés le départ du projet.
C'est dans la branche de développement qu'il y aura le plus de changement. Les
Les éléments de ces stratégies sont itératifs donc il est possible de débuter avec une développeurs doivent conserver un controle de son contenu (un principe de base est
stratégie simple et d’évoluer prog; nt vers une et ensuite qu'une branche devrait toujours compiler), mais on s'attend qu'il y ait beaucoup de
avancée. La raison la plus rapportée pour l'utilisation de stratégies avancées est sur cette branche. La branche subira moins dactivité, car elle
l'utilisation des paquets de services et de « hotfix » ou d'équipes multiples dans des recevra, de temps a autre, des fusions provenant de la branche de développement.
endroits différents. Lactivité dépendra de la fréquence de la fusion du développement vers la branche
principale : journaliére, aux deux jours, aux trois jours ou hebdomadaire. Finalement,
Dés quil y a plus d'une personne qui travaille sur un logiciel, il y a nécessité de s'isoler pour la branche de version subira encore beaucoup moins de changements parce qu'elle
travailler indépendamment des autres. La branche principale doit toujours servir de point de représente la version déployée 4 la clientéle. Cette branche posséde la version en
départ et de retour d'une branche. Clest-a-dire que vous créez des branches pour vous isoler production et servira a faire le support des clients au jour le jour. Cette stratégie sera
a partir de la branche principale et ensuite vous ramenez les changements (c.--d. faire une valable dans les conditions suivantes :
fusion) vers la branche principale Evitez de créer des branches & partir de branches, car ce
patron nest pas une et va créer de la ion. Seule la branche de ~ Vous livre une version majeure unique aux clients,
sauvegarde peut utiiser cette approche. —~ Votre modéle de maintenance est de livrer une nouvelle version a intervalle fixe,
La stratégie simple de : Cette stratégie est valable pour des cas simples, par ~ Toute nouvelle version livrée a partir de la branche de version inclura toutes les
exemple le développement d'un site Web. Cette stratégie nécessite de créer deux types ‘modifications précédentes de cette branche.
de branches (voir figure 2.7) : 1) la branche principale, et 2) la branche des versions.
Cette stratégie propose que la branche principale serve aux développeurs du logiciel.
Ceci implique que la branche principale soit stable en tout temps. Dés que le logiciel
est assez avancé, et que I'équipe désire livrer une version au client, on crée une branche
de version (par exemple 1.0.1) qui contiendra une version des artéfacts complete de la
version en production. Sur la branche principale, on peut continuer a travailler a faire Branche princi y >
évoluer le logiciel. Avec le temps I'équipe de développement sera préte a livrer une
version subséquente et créera une autre branche de version (par exemple 1.1.3) et cette
branche deviendra la version de production. La branche précédente servira
d'historique et pourra étre archivée, car elle n’aura plus d'utilité. Cette stratégie sera Version >
valable dans les conditions suivantes :
~ Vous avez une trés petite équipe qui cohabite afin de facilement communiquer, Figure 2.8 - La stratégie typique de branche de développement et de production
~ Les corrections au logiciel de production se font en faisant une fusion la branche
principale. II faut controler ces fusions, car elles se font directement dans le Finalement, les activités de soutien pour la qualité de la maintenance sont aussi
développement, présentes en maintenance du logiciel. Aussi, il n'est pas suffisant de simplement
~ Toute nouvelle version livrée a partir de la branche principale inclura toutes les espérer qu'une quali éliorée résulterait de la mai du logiciel. Elle doit
modifications précédentes de cette branche. étre plan dans les pour soutenir le processus de
‘maintenance. ol activités et les techniques pour : lassurance qualité du logiciel
(AQL) ; la vérification et la validation (V&V) ; les revues et les audits doivent étre
Branche > planifiés en fonction de la criticité des activités de maintenance et du niveau de qualité
désiré. Il est aussi recommandé que le mainteneur adapte les processus et techniques
de dé par exemple la doct ion des tests et des résultats des tests.
Branc
Identifiez une personne dans votre équipe qui va jouer le réle de libraire pour : 1)
Version identifier avec l'équipe la stratégie de branches pour le projet et 2) mettre en
place/surveiller et communiquer avec les personnes qui sont impliquées pour que son
utilisation soit respectée.
Version Finalement vous pouvez aussi mettre les documents et méme les scripts de production
dans la librairie. Il existe deux (2) types dinfrastructures:
Figure 2.7 - La stratégie la plus simple des branches par versions

L'évolution contrélée du logiciel 3 Les problématiques d'évolution continue du logiciel
1. Infrastructure mutable, historiquement la plus commune. Cette approche de gestion

de linfrastructure est basée sur des ressources mises a jour réguliérement, que ce soit
‘manuellement ou par un outil de gestion de la configuration tel qu'Ansible,
2. Infrastructure immuable. Avec cette approche les ressources sont supprimées pour
laisser la place 4 de nouvelles ressources plutot que de modifier les infrastructures
actuelles lors d'une mise a jour. La mise a jour des ressources par remplacement se fait
dans ce cas programmatiquement en utilisant un outil d’« Infrastructure-as-Code (aC) »,
tel que Terraform ou Pulumi. L'approche DevOps recommande la migration vers ce type
dinfrastructure.
Les outils d1aC permettent de déclarer Infrastructure sous la forme de code, ce qui a de
nombreux avantages :
~ Lautomatisation évite les erreurs humaines et rend le processus de déploiement Les problématiques
déterministe,
~ Linfrastructure suit le méme processus de version et de revue (c.-a-d. + pull request
») que le reste du code source applicatif, ce qui rend particuliérement simple le d’évolution continue du
processus de retour en arriére « roll-back »,
~ Lobservabilité de Infrastructure est grandement améliorée puisquil est possible de logiciel
retracer I'historique des modifications a partir de la suite de « commit ».
Dans ce chapitre, nous couvrons les problémes suivants de la maintenance des logiciels
— Les perceptions extemes des utilisateurs : couts élevés et lenteur du service de maintenance,
- Les ions interes des de la : logiciels congus sous pression,
testés partiellement et avec peu de documentation,
— La mesure de la maintenance : processus, produits et services.

3.1 LES PROBLEMES D’EVOLUTION CONTINUE DU LOGICIEL base sur une modularisation poussée des composants ne créant pas deffets secondaires
lors d'une maintenance. Léquipement électronique et informatique posséde aussi
souvent un processus dessai ct de diagnostic des composants, disponible a la poussée
En 1987, Colter fait le constat suivant : « le plus grand probleme de la maintenance du d'un bouton. De plus, de logiciels a en sont souvent
logiciel n'est pas technique, mais plutot de management +. Un nombre important vieux de dizaines d’années et n'ont pas bénéficié des avances technologiques des outils et
dauteurs les reliés au des ressources, des processus des techniques de conception plus modernes. Certains auteurs expliquent que la
et de Toutillage de la maintenance du logiciel. Les problémes documentés dans la complexité de ces logiciels est un facteur qui influence aussi le cout de leur maintenance.
littérature varient selon le point de référence (point de vue) de auteur qui exprime et décrit Mais les perceptions des utilisateurs donnent-elles un portrait juste de la charge de travail
le probléme. On peut classer selon deux points de vue les problémes de la maintenance etdela des équipes de mai ? Lientz et ont été les
décrits dans la littérature :
a souligner, sur la base d'un sondage auprés de 487 groupes de maintenance du logiciel,
1. Perception externe de la clientéle (c’est-a-dire les utilisateurs), que 55% des requétes dirigées vers les groupes de maintenance étaient en fait de
2. Perception interne des employés et ires de la mai du logiciel. E et non des Daautres études deffort par catégories
Du point de vue externe de la clientéle de la maintenance, les problémes de la activités de maintenance de Abran (Abran 1993), basé sur des mesures recueillies sur
maintenance sont, selon Pigoski : « le cout, la lenteur du service et le traitement des quelques années, apportent des précisions sur ces répartitions de travail dans des
priorités internes versus celles de l'utilisateur ». équipes de maintenance. Cette étude corrobore les propos de Lientz et de Swanson (Lienz,
Du point de vue interne et les ésdela du logiciel 1980). Le personnel de maintenance ne passe pas entre 50 % et 80 % de leurs efforts a
une situation de travail basée sur des logiciels mal concus, mal programme et avec peu corriger des problémes, mais plutot 4 faire évoluer le systeme (évolutions des logiciels et
de documentation. plateforme), a ajouter de la fonctionnalité requise par les utili et a rép: a
toutes sortes de questions concernant les régles affaires des logiciels opérationnels.
3.1.1 PERCEPTION EXTERNE : COUTS ELEVES ET SERVICE LENT Malheureusement, ces répartitions des travaux de maintenance ne sont pas bien
communiquées & la clientele. Une partie de la perception d'un cout élevé de la
La grande majorité des couts dans le cycle de vie des logiciels seraient reliés a la maintenance provient donc dune du dela par
‘maintenance du logiciel : 40 4 90 % selon Foster et Mun, 75 % selon Hall, 50 4 80 % selon les de la la ré ion efficace de tous les travaux
Scott, et plus de 60 % selon Hanna. Boehm affirme que pour chaque dollar dépensé en de i és pour la clientéle. En effet, certains cadres de maintenance
il faudra en deux en et précise que les couts de regroupent les travaux d’améliorations et de corrections dans leurs statistiques, leurs
maintenance peuvent étre exprimés comme une fonction du nombre d’instructions du budgets et leurs rapport. Il s'ensuit une distorsion des couts, des budgets et des rapports
code source du logiciel. de management qui perpétuent la confusion de la clientéle concernant les différents types
D’autre part, les utili: sont particulié ibles aux irritants, qui, pour eux,
de services de la maintenance du logiciel.
ont des impacts négatifs parfois considérables soit sur la qualité de leurs services, soit 1 y a done, dans la perception du client, une interprétation incorrecte des types de travaux
par les couts dus, par exemple, aux pannes de logiciel en production, aux erreurs de et peu di ibles sur la durée typique d'une activité.
calculs et de données, ou, dans certains cas, 4 la longue attente, ou encore aux couts Pigoski indique également que la maintenance du logiciel est un travail laborieux et que
élevés d's ion de aux ités du logiciel. la majorité des couts proviennent des salaires des programmeurs. Cest actuellement le
Les problémes, les défaillances, de méme que les multiples requétes de changements cout des experts pr (par exemple ; 116,000 $ américains par année pour un
présentées par les utilisateurs, arrivent de facon aléatoire : quand il ny a pas en place ar ci en ion SWIFT en 2023) qui est le plus
des mécanismes négociés et formellement décrits de gestion de file dattente, les élevé. Pour améliorer la perception du client, il vaudrait donc mieux expliquer les activités
utilisateurs ont de la difficulté 4 influencer les priorités pour la résolution de ces des programmeurs de la maintenance.
demandes. Il y a donc, souvent, une de ise gestion de la Quien est-il du management de la file d’attente des billets dans I'arriéré de projet du
du logiciel. Cette perception peut découler de plusieurs situations : soit les utilisateurs ne tableau Kanban, qui est, elle, sous son controle direct ? Le développeur/mainteneur se
précisent pas initialement leurs priorités; soit ils les changent eux-mémes, ce qui crée doit de bien informer les utilisateurs qu'il y a aussi trois autres sources de requétes de
des conflits dans les travaux en cours ; soit ces priorités sont interrompues en cas de changements : 1.les opérations, 2.les autres projets en cours et 3.les activités
de logiciels en pr (travaux de mai Bennett constantes de réingénierie du logiciel. Aussi, il doit bien expliquer le fait qu'il devrait y
décrit le fait que certains utilisateurs deviennent parfois frustrés de la lenteur du service, avoir un processus publié, négocié et approuvé pour gérer les priorités auprés de tous les
jusqu'au point d’envisager de développer des solutions locales pour régler leurs problémes nants qui font des de (Dorfman, 2002).
ou méme de donner a l'externe la sous-traitance ou d'impartir la maintenance.
Schneidewind est d'avis que l'utilisateur ne posséde pas une idée claire des activités de la 3.1.2 PERCEPTION INTERNE DES PROBLEMES DE LA MAINTENANCE DU LOGICIEL
maintenance du logiciel. Il a émis Lopinion que la perception de l'utilisateur, face & la
lenteur du service de la est parti basée sur une i Lehman, le créateur des régles de Iévolution logicielle, indique que la structure des
de la diffe entre la mai du matériel électronique et logiciels qui font l'objet d%évolution continuelle devient de plus en plus complexe a la suite
informatique et celle d'un logiciel. II décrit la réparation d'une des modifications. Bien que le matériel électronique et mécanique se détériore quand il
brisée d'un équ électronique et i lique repose princi sur une ny a pas de maintenance, le logiciel, de son coté, se détériore a la suite de multiples
activité de remplacement modulaire assez simple. Il note aussi que la conception de maintenances qui ne sont pas controlées (Glass, 1992). Ainsi, un nombre de plus en plus
Téquipement électronique est bien plus mature que la conception du logiciel et quelle se élevé de ressources peut étre requis pour maintenir un logiciel qui croit en complexité

avec le temps (par exemple : les logiciels patrimoniaux des banques québécoises qui entretien/support applicatif expriment aussi le fait que leur statut professionnel est
ajoutent constamment des technologies autour de leur logiciel bancaire, sans jamais inférieur a celui des développeurs et quiils doivent souvent accepter, avec résignation, le
enlever les vieilles technologies). On note parfois aussi une croissance considérable du prochain logiciel développé et implanté, peu importe son niveau de qualité. Du point de
nombre de lignes de codes pendant les trois premiéres années d'un logiciel en production vue de ces spécialistes en support, le logiciel est mis en production de plus en plus
(Gibbs, 1994). Osborne et Chikofsky (Osborne, 1990) soulignent aussi que lage moyen rapidement avec un bon nombre de problémes qui ne devraient pas étre réglés dans le
des logiciels en opération se situe entre 10 et 15 années dans les grandes entreprises. Ces cadre des activités quotidiennes. Ils disent aussi étre peu outillés, peu supportés et peu
logicicls ont done une structure ancienne/plus complexe, du code non normalisé compris par leur gestionnaire. Ils se sentent seuls responsable, 24 heures sur 24, du
(comportant de et une faible dod une difficulté bon fonctionnement et de la gestion des logiciels en opération, et, plus important encore,
accrue pour le programmeur qui doit en faire Iévolution continuelle. du support de tous les problémes de la clientele.
Selon Bennett (Bennett, 2000), on peut classer les problémes d’évolution du logiciel selon Un deuxiéme groupe important de problémes, listés au tableau 3.1, prennent sources
trois catégories : 1. alignement avec les objectifs organisationnels, 2. problémes de dans les étapes mémes du cycle agile de développement du logiciel (2,4, 6, 10, 11, 12 et
processus et 3. problémes techniques. 13). identifie des / qui prennent
Le processus d’évolution doit constamment s'assurer que les logiciels opérationnels sont source lors des itérations rapides de frit méme du logiciel :
disponibles et offrent un bon niveau de service. Les intervenants doivent réagir 1. Il est difficile de retracer le ou les processus et les produits de sortie qui ont créé le
rapidement aux pannes et s'assurer que le service est restauré le plus rapidement logiciel,
possible. Le processus d'évolution controlée doit aussi sassurer de Iatteinte des niveaux Les ne sont que
de services établis et conserver la confiance de la clientéle quant a la compétence de son 1 est difficile de suivre et de gérer les changements,
ol
[LE
équipe fournir un service de qualité dans les limites du budget attribué (Abran, 1993).
Un sondage effectué en consultant des spécialistcs dévolution du logiciel a permis 1 a des cfets secanduiren lorqur lon effecte um changement un logiciel,
détablir une liste ée de 19 du ine : voir tableau 3.1 qui suit. Les if de ne if que trés la des
nouveaux qui en font le support.
Les processus de développement de logiciels sont 4 la source d'un certain nombre de
Tableau 3.1 Sondage interne des de de la problémes du produit final (le logiciel) déployé chez la clientéle ct maintenu par le
(Dekleva, 1992) pr de la mai Un de mature, qui capture
i les exi et les spécifications dans une ion claire et qui fait l'objet
Rang Problémes de la assurance qualité, engendre de plus faibles couts de maintenance.
1 Gestion des priorités changeantes (M) Bennett indique que, lorsque les ressources financiéres sont limitées, les étapes
2 Techniques dessais i @ danalyses, de conception et dassurance qualité, lors du développement, sont mises sous
3 Difficutés & mesurer la (0) pression et ne sont que parti faites. Ces omissions auront plus
4 D absente (T)
tard des es pour la du logiciel.
5 Ada des organisations diutiisateurs
Pour corriger partiellement ces effets défavorables, Pigoski recommande dimplanter un
processus (c.-a-d. une itération) de transit on du logiciel. Ce prend en compte
6 Nombre important de requétesde en attente (M) les considérations de qualité pour sa mai durant le dé du logiciel
7 Difficuté & mesurer et & démontrer la de 'équipe de ™) afin d’en améliorer la transition et d'éliminer certains problémes a la source. Sans cet
8 Moral bas di au manque de de respect de la ™) important processus de transition, qui est, en pratique, assurance de la qualité, il peut
9 Peu de du domaine et encore moins avec ™) s'ensuivre des contrats de maintenance trés onéreux pour les utilisateurs (et tres lucratifs
pour les sous-traitants de maintenance).
10 Peu de standards, de etdoutis de
les etles requétes de la clientéle (voir
1 Le code source des logiciels existants est complexe et non structuré (T) tableau 3.1, problémes 1, 5 et 6) sont aussi identifiés comme une source de probléme. La
12 et des systémes existants (T) rapidité avec laquelle le monde des affaires et celui de la technologie changent a comme
13 Les employés de la ont peu de formation disponible (M) conséquence directe une rapidité de demandes de changements aux logiciels et aux
14 Pas de plans la mair M) équipements qui les supportent. Enfin, la difficulté & comprendre et a répondre aux
attentes changeantes de la clientéle vient en quinziéme place.
15 Difficuté & les attentes des utisateurs et dy répondre (M)
16 Mangue de ion et de support de la part des ires de |i ™)
Déautres travaux indiquent que les facteurs premiers qui contribuent aux couts élevés de
la maintenance du logiciel sont : le nombre et I'expérience des programmeurs, la qualité
17 Les logiciels de la sur des systémes et des technologies désuets (T) de la i et de la , les outils qui
18 Peu de volonté et de support pour rénover les existantes(M) supportent les employés de la maintenance, la structure et la « maintenabilté! » du
19 Perte diexpertise quand les employés quittent Iéquipe (M) logiciel et, les qui gous t la du
(M) : Probleme de (T) : Probléme technique logiciel. D'autre part, leffet de lenvironnement de travail sur la productivité des
programmeurs a été étudié et il a été constaté que lenvironnement physique (bruit et
Le plus grand nombre des problémes identifiés par ce sondage sont associés au
d dévolution/mai des logiciels. Les spécialistes en ‘Terme utilisé par les normes intemationales ISO/CEI pour déerire la facilité & maintenir le logiciel.

interruptions) nuit a la pe e des ars. 11 est aussi mentionné dans la Leestimation des ressources (c.-a-d. leffort, nombre d’employés et budget annuel) est faite
littérature que la maintenance du logiciel n'est pas enseignée dans nos écoles comme elle par les ingénieurs logiciels selon deux approches. La plus répandue des deux approches
est vécue dans les isations. II en ré it un manque de i et de est celle établie sur lexpérience, cest-a-dire qu'elle est basée sur lexpérience d'experts
dans le de la mai pour les candi iels des emplois pour déterminer les exigences annuelles en évolution, et évaluer les impacts a prévoir et
en maintenance du logiciel. en prévoir les couts.
Y aurait-il aussi un élément culturel qui expliquerait que la maintenance n'est pas plus Lexpérience, sous la forme de jugement d'experts (c.-a-d. en utilisant une technique
« populaire » en génie logiciel ? Bennett décrit dans une étude effectuée au Japon, en Delphi par exemple), les analogies et une structure de décomposition de la tache sont
1993, que la perception des gestionnaires de ces isations japonaises est plus plusieurs approches qui devraient étre utilisées pour enrichir les données provenant des
favorable & la maintenance, car ils considérent que lamélioration du logiciel augmente estimés. Lexpérience est souvent utilisée comme base d'estimation en génie logiciel en
quotidiennement la satisfaction de la clientéle. Sans ce service essentiel, I'organisation T'absence de données historiques de bonne qualité.
perdrait rapidement des parts de marché. La culture de la qualité étant trés importante
Une autre approche, encore expérimentale, consiste a utiliser des modéles paramétriques
au Japon, les activités de maintenance y bénéficient de plus de visibilité et d'une meilleure
perception. Bennett observe aussi que le moral des travailleurs de la maintenance est tels que le modéle COCOMO-maintenance (Boehm, 1987), mais c'est une théorie
élevé au Japon et que la gestion de la maintenance y fait l'objet de plus de visibilité tant inutilisée et i dans 11 ie québécoise. I est important de noter que les
auprés des gestionnaires que de la clientéle. données historiques de taille, d'effort et de qualité des requétes passés sont nécessaires
pour utiliser ces modeles. Abran (Abran, 2015) discute des défis de estimation des couts,
En résumé, comme sources i de la ion négative des p é de la incluant I'estimation de la taille et de leffort, et présente un chapitre complet sur
maintenance, on note : Testimation dans un contexte de maintenance. Un petit nombre de chercheurs proposent
+ Une ison dé de la mai du logiciel par rapport a la aussi des modéles spécialisés d'estimation spéci de la mai du logiciel.
maintenance du matériel électronique et informatique, Les experts s'entendent pour suggérer que la meilleure approche, pour lestimation de la
«Une perception de couts élevés et de service lent de la maintenance du logiciel, i est de iner des modéles étriques et lexpérience. Les données
«Des problémes de gestion, des couts élevés de la main-d’ceuvre spécialisée, une historiques devraient étre fournies comme résultantes d'un programme de mesures de la
mauvaise compréhension de la nature et des aspects techniques du logiciel et, ‘maintenance.
des p lies al de trav Les sections qui suivent présentent donc les types de mesures de la maintenance
+ Un manque d'outils automatiques d’essais et de diagnostics a la suite d'une pour iner des données historiques afin de construire des modéles
modification, et d’estimation de la maintenance efficaces.
+ Un manque de formation spécialisée dans nos écoles.
3.3 LA MESURE DU PROCESSUS DEVOLUTION D’UN LOGICIEL
3.2 LE MODELE DE MESURE
1l'y a plusieurs facteurs a considérer avant de mettre en ceuvre la mesure de I'évolution
Les travaux de Deming nous enseignent « qu'un processus est stable si sa performance d'un logiciel. Les mesures doivent étre bien définies afin de caractériser au mieux le
future est prévisible dans des limites établies d'une maniére statistique ». L'objectif de la logiciel, les services ainsi que les processus d’évolution.
mesure continue du logiciel est donc den connaitre plus sur le comportement des « Les organisations qui possédent un faible niveau de maturité font souvent la collecte
ressources, du processus et du logiciel et sur leurs relations de cause a effet (voir des mesures justes pour présenter des données. Elles sont rarement utilisées en
figure 3.1). pratique. » (Ebert, 2004)
Card et Glass que les isations utilisent trop les i
qualitatives pour évaluer la qualité du logiciel et qu'elles devraient utiliser beaucoup plus
de méthodes quantitatives (Card, 1990). Mais quelles méthodes quantitatives utiliser ?
T Documentation Un processus est une séquence dactivités faites avec un objectif donné. La figure 3.2
Outs ‘Gestion de probleme source montre la portée de la norme ISO 15939 de la mesure des processus logiciels. Portée que
Gestion des SLA Entente de service nous avons modifiée pour I'adapter au point de vue des maintencurs. Car, tout comme le
Acts processus Correction Bases de données
Forma Suneilance Dossiers de tests guide du PSM (Practical Software Measurement), cette norme porte sur la mesure dans
dexemples
un contexte de projet de développement du logiciel. Le guide du PSM est un processus de
la mesure d'un projet de développement du logiciel. Le PSM est le document qui a le plus
influencé la norme ISO 15939. Le guide de mesure PSM fournit des détails additionnels
sur les activités et des taches présentées dans la norme ISO 15939, et fournit des étapes
Figure 3.1 - Perspectives pour la mesure du logiciel détaillées du processus de la mesure. Dés 1995, ce guide est mis en application dans les
Les développeurs/mainteneurs doivent comprendre les différentes catégories de projets de logiciels de la Défense américaine. En outre, le PSM explique comment effectuer
maintenance, discutées ci-dessus, pour pouvoir traiter la question de lestimation des la mesure et prodigue des conseils pratiques tels que : des de des
couts de maintenance. Dans un but de planification, Iestimation des couts est un aspect lecons apprises, des études de cas et des conseils d’exécution des processus de mesure.
important de la maintenance continue du logiciel. Le PSM sapplique-t-il a la maintenance du logiciel ? « La réponse est non, car les

préoccupations et les mesures associées a la gestion de la file d’attente et des demandes publication confirme que la mesure doit étre basée sur un processus logiciel mature et
de changements sont différentes de celles d'un projet de développement du logiciel. » bien d té. Les auteurs soul quiun qui n'est pas est
Lobjectif du cadre de la mai est de mettre les ps clés de difficile, si ce n'est impossible, a mesurer. Le programme de mesures de Hewlett Packard
sous controle, et la prise de mesures a un role important a jouer en aidant le cadre a présenté par Grady et Caswell est basé sur un processus du logiciel mature (environ au
atteindre cet objectif. niveau 3 de maturité du modéle du CMMi) et bien documenté. Grady a établi un
Parce que le mainteneur a peu de controle sur le développement d'un logiciel, le programme de mesures du logiciel a échelle de la société. Il décrit la collection de données
doit inciter les a mesurer leurs et leurs produits. Le spécifiques a la maintenance du logiciel. Il décrit aussi la modification des formulaires de
peut les situés le plus tot possible dans le cycle de vie Hewlett Packard, en aout 1984, afin de sadresser 4 la mesure de la maintenance du
du développement, qui influencent les caractéristiques de maintenabilité du nouveau logiciel. Grady ajoute les a prendre en considération pour le désign
logiciel en construction. Malheureusement, il n'a pas souvent lautorité d‘imposer la prise d'un programme de mesures pour la maintenance du logiciel :
de mesures lors du développement. ~ De quelle maniére devrons-nous planifier les ressources humaines pour les activités
d'évolution continue du logiciel d'une gamme de produits ?
ire es | Mantteris ~ A quel moment pouvons-nous dire qu'un logiciel est stable ?
Kare buts Eb, ste Introduire
~ Est-ce que le « temps moyen entre deux défaillances » est une mesure valable pour
rnponc-h ot we rid
de amelioration les mesures et lanalyse représenter la qualité d'un logiciel ?
~ A quelle étape du développement logiciel devrons-nous investir dans des outils et de
la formation pour réduire les défaillances ?
C3 «— INTERNET «— ~ Quel effet a la qualité de la documentation du logiciel sur sa facilité a I'évoluer ?
ey Processus, procs, ctroqutis, | Bas do domées ~ Combien de défaillances peut-on prévoir selon la taille du logiciel livré au client ?
‘employés, uisatours ef cients,
T Toumisseurs ef mpart
~ Quelle est la relation entre les défauts trouvés avant la livraison et les défaillances
observées par nos clients, en production, aprés la livraison ?
tiiser ~ Quelle est la relation entre la taille d'un logiciel et le temps moyen nécessaire pour
Ge{ored
mesure iot extraire
—y assed o Les actions réparer une défaillance ?
~ Quel est le temps moyen nécessaire pour réparer une défaillance ?
~ Combien defforts, en tests /essais, sont nécessaires pour s'assurer qu'une correction
est adéquate (c.-4-d. ne créera pas d'autres défaillances)?
Figure 3.2 - Processus de mesure de I'évolution d'un logiciel - adapté de ISO 15939 ~ Combien de défauts, en pourcentage, sont introduits par des corrections ? par des
Inciter la prise de mesures durant la prélivraison ou la transition peut étre la stratégie & améliorations /évolutions ?
utiliser pour évaluer la qualité du logiciel et évaluer a quel point le logiciel est prét a étre Grady précise qu'aprés plusieurs mois de mise en place, il constate quaucune mesure
accepté en maintenance. Pour atteindre cet objectif, il faut mettre en place un programme n'est encore rapportée et que les ingénieurs logiciels ne sont pas aussi enthousiastes que
de mesures des logiciels en opération/évolution continue et le relier, si possible, aux les développeurs initiaux pour effectuer la collecte de ces données. Il émet alors l'opinion
mesures prises lors de son développement initial. Par exemple, si Iéquipe de projet peut quil semble encore plus difficile deeflectuer la mesure dans le contexte de 'évolution
définir tot certains objectifs de maintenabilité pour le nouveau logiciel, ce logiciel pourrait continue du logiciel. D'autres auteurs confirment aussi qu'un programme de mesures
étre mesuré tout au long de son développement (durant la prélivraison) afin de faire le spécifiques a lévolution continue de logiciels doit étre planifié séparément de celui des du
suivi de cet objectifet de permettre une meilleure prise de décision lors de la transition bureau de projets, car elles reflétent beaucoup plus un point de vue DevOps que celle
finale vers Topération/maintenance. d'un projet de dé Les exi; étant diffé les mesures de I'évolution
De nombreux facteurs doivent étre pris en compte afin de mettre en ceuvre la mesure d'un continue de logiciels sont plutot centrées sur la résolution continuelle des problémes en
processus d%évolution de logiciels. Une bonne stratégie est d'identifier les activités clés production (clest-a-dire les RP) et sur la gestion des requétes de modifications (c'est-&-
dun processus donné et détablir leurs objectifs. Ces activités clés, 4 leur tour, ont de dire les RM’s) continuelles.
nombreuses éristiques qui peuvent étre ées. Ceci implque que lorgani
a défini ses processus et posséde une certaine maturité.
Dés 1981, la société Hitachi présente ses mesures de maintenance logicielle. La société
mesure le cout de la maintenabilité de ses logiciels : cout d'un changement a un logiciel
aprés son développement (en utilisant le rapport entre le nombre de défaillances en
relation et le cout du projet initial de dé Hitachi présente les de
cout de changement de plusieurs logiciels et tente d'identifier les logiciels qui ont une
meilleure maintenabilité en production.
En 1987, Hewlett Packard a établi un de mesures du dé logiciel
et fait un essai de mesure de la maintenance de logiciel. Le programme de mesures chez
Hewlett Packard est présenté dans le livre de Grady et Caswell (Grady, 1987 p. 247). Cette

Appli (Avant)
Tableau 3.2 Les pratiques de génie logiciel et leur niveau - proposées par le Sei (Sei, 2018)
Taile fonctionnelle
Lignes de code Niveau de
pmo Représentation continuelle des niveaux
de capacité.
Caractéristiquesde
Tenvironnement
1 Initial : imprévisible et réactif. Les travaux sont terminés, mais sont souvent retardés et
Requétes. M Application (Aprés)

dépassent le budget
de maintenance Taille fonctionnelle 2 Géré : Géré au niveau du projet. Les projets sont planifiés, exécutés, mesurés et controlés
Nombre | ~ «| Lignes de code source
Catégorie Caractéistiques de Ienvironnement 3 Proacti plutdt que réact. od rv lio 8 orphan men dd
Processus de sur les projets, les
maintenance 4 Gestion quantitative. Géré a aidede mesures quanitatives) mesuré
et controlé.
Effort Requétes complétées L'organisation est axée sur les données avec des objectifs quantitatifs d'amélioration de la
wien | - ~ Cat performance qui sont prévisibles et alignés pour répondre aux besoins des parties prenantes
Taile fonctionnelle internes et extemes
7 Lignes de code source 5 En : stable
et souple. L' tion est axée sur é continue
et est
Personnes/jours comptabilisés
congue pour pivoter et répondre aux opportunites el aux changements. La stabilté de
Services administratits fournit une. pour lagilté et innovation.
Lors d'un sondage sur la mesure de la mai 75 % des indi quiils

Figure 3.3 - Exemple de caractéristiques sélectionnées pour la mesure d'un processus de rapportent seulement : le nombre de défaillances en analyse la cause; et documentent la
maintenance (Desharnais, 1997) source de chaque défaillance. lls proposent une seule mesure de ratio simple : Temps
Dés 1993, au Québec, Abran et Nguyenkim (Abran, 1993) publient une analyse de l'effort moyen d'un changement (représentant le temps moyen pour effectuer un changement a
consacré a chacune des catégories de la maintenance du logiciel chez une institution un logiciel aprés son développement). Avec seulement cette mesure, il serait déja possible
financiére canadienne (le Montréal Trust). Cette étude décrit les spécificités de la mesure détudier si les logiciels, qui ont un temps moyen de changement plus court, ont
de I'évolution continuelle des logiciels et permet d'observer les tendances pour chacune flectivement une mei i ilité
des catégories de services de maintenance. Ces travaux remportent un prix d’excellence Fi Cest le groupe d'utili i ional de I' du logiciel ('SBSG)
décerné par le Software Engineering institute (Sei), aux Etats-Unis, cette méme année. qui simpose progressivement comme la nore de facto de la mesure du logiciel (ISBSG,
En 1994, la NASA (Stark, 1994) propose des mesures pour les catégories correctives et 2010). Cette ion fournit le questionnaire de colleete de données, ce qui permet
adaptatives de la maintenance du logiciel : taille du logiciel, nombre d’employés, nombre identifier les données nécessaires pour mesurer Iévolution du logiciel. Le
de requétes, utilisation de ressource ordinateur parlogiciel, densité des deéfauts, volatilité, qui en est 4 sa deuxiéme version, est accompagné d'un glossaire de termes. Les mesures
durée de fermeture d'un rapport de éme, rappos Te, fiabilite, de I1SBSG tentent de répondre aux questions suivantes :
complexité d'un changement et distribution par type os défaillance. Nos services d’évolution continue coutent-ils trop cher ?
Une autre initiative de mesure de la maintenance par Desharnais et Paré de travaux Répondons-nous assez rapidement a nos clients ?
innovateurs et présentent un exemple de cing caractéristiques qu'ils ont choisies pour Nos processus sont-ils efficaces et efficients ?
mesurer la maintenance du logiciel 4 la Régie des rentes du gouvernement du Québec Nos clients sont-ils satisfaits de nos services ?
(voir figure 3.3). Ils ont recommandé que les mesures soient bien définies et vérifiées pour Nous améliorons-nous d'année en année ?
Sassurer queelles caractérisent correctement le logiciel, les services et les processus de Pour obtenir des réponses a ces questions, vous devrez participer a la collecte de données
maintenance. dans votre organisation et recueillir les données suivantes :
A la suite dune demande de mesure de la productivité dans une entreprise de «Effort pour chaque catégorie de service d’évolution/maintenance et le total pour votre
le ar April décrit les pre ires avant de pouvoir organisation,
effectuer la mesure de la productivité de la maintenance. Ces préalables présentent + Effort total et détaillé de vos activités de correctif (activités sans changement au
Timportance des définitions communes des catégories de travail, de limplémentation d'un logiciel) :
logiciel de gestion des requétes, de la classification de I'effort des billets dans une charte o Effort dinvestigation de problemes,
de compte comptable d’activités (facturables/non facturables), de la nécessité du logiciel o Effort d'aide et de conseils 4 la clientéle,
de gestion des activités (par exemple : feuilles de temps dans Jira), de la vérification des © Effort pour les requétes ad hoc.
données et de la mesure de la taille fonctionnelle des requétes de modifications. Pour ce Nombre de défai par catégorie de criticité (extrém, majeure et
faire organisation doit avoir atteint le niveau 4 de la maturité (du tableau 3.2) ce qui est Nombre total d’appels de service,
assez rare pour une entreprise québécoise encore en 2023. Nombre total de clients supportés,
Pourcentage d'ingénieurs logiciels qui ont quitté leur fonction sans avertissement,
Une indication si vous avez un sondage de sati ala clientéle et un
de gestion de la configuration logicielle (GCL) pour votre logiciel en production,
«Liste des langages avec lesquels le logiciel est programmé (en ordre d'importance),

+ Une description détaillée du logiciel maintenu : 2. La proportion deffort consacré a la maintenance versus le support (en général et par
© Son nom, sa description, son type, logiciel),
o Sa taille fonctionnelle, 3. La proportion d'améliorations mineures (en général et par logiciel),
o La date de mise en service (début de la production), 4. La capacité de ressources de maintenance, qui décrit les efforts dédiés a d'autres
© Sa criticité sur une échelle de cing valeurs.
«Le total de effort de maintenance et de support pour chaque logiciel : activités que la maintenance (en général et par logiciel),
o Effort de maintenance pour chaque catégorie de service de la maintenance, 5. La densité des défauts. Quand cet indicateur est élevé, l'eflort (et le cout) de la
© Nombre total d’appels de service par catégorie de criticité (extréme, majeure maintenance est élevé,
et mineure). 6. Le taux des appels de service. Une organisation de la maintenance qui regoit
+ Dautres mesures pour chaque logiciel maintenu : beaucoup d’appels doit mettre plus deffort (et aura des couts plus élevés),
© Nombre d'ingénieurs logiciels dans Iéquipe dévolution/maintenance, Leffort moyen pour corriger un défaut est un indicateur du cout de la maintenance,
~N
o Evaluation de la connaissance du logiciel par ’équipe pour quatre aspects
(application, technologie, domaine d'affaires et langage de programmation), 8. La proportion des langages de programmation dans les logiciels maintenus,
Flexibilité allouée au personnel dans le portfolio de logiciels maintenus, 9. La proportion des données, qui a été étudiée et exercerait une influence sur le cout
é dun envir devolution séparé de la de la maintenance,
oo
production, 10. effort de mai par endrot, i ion et utili Cette mesure indique
Disponibilité d'un environnement d'essais sépare, Teffort moyen de maintenance et donne une indication des endroits ott il y a plus de
Outils d'essais, demandes,
©000000
Présence d'une entente de service, 11. Leffort de maintenance par heure de disponibilité du logiciel, qui décrit le cout moyen
Nombre de versions produites (par an), dévoué a la maintenance pour chaque heure de disponibilité, et
Nombre de logiciels apli en i pportés/ 12. effort par changement, qui mesure le cout moyen des changements au logiciel.
Nombre de bases de données supportées,
Présence ct liste des progiciels inclus dans le logiciel et sils sont sous votre Ces propositions de mesures du logiciel en évolution constante ont Iavantage détre
responsabilité ou la responsabilité du fournisseur, proposées par un groupe d'utilisateurs international et pas un fournisseur. On peut done
Liste du matériel sur lequel fonctionne le logiciel, consulter le document de collecte des données de 11SBSG, le détail de la méthode de
Liste des langages avec lesquels le logiciel est programmé (en ordre ‘mesure pour chaque mesure proposée et faire partie d'un groupe d'intérét qui se pose ces
oo
importance), et la taille en milliers de lignes de code, memes questions et obtiens des réponses. Clest surement la meilleure approche de la
Nombre de défai par je de criticité (extrém, majeure et mesure de d'un logiciel opé qui est disponi en 2023 et seul
Vingénieur logiciel posséde la formation pour adresser ces questions.
°
‘mineure),
Temps moyen de remise en service suite 4 une défaillance,
Nombre d'incidents et d’appels de service (par mois/an), 3.4 LA MESURE DU CODE SOURCE
0co0o0o0
Expérience des utilisateurs sur une échelle de quatre valeurs,

Indication de la structure du code source du logiciel sur une échelle de cing Relativement peu de matériel est actuellement disponible spécifiquement pour la mesure
valeurs, des produits de sortie d'un logiciel qui évolue constamment, quoiqu'un bon nombre lest
Indication de la structure de la logique du code source sur une échelle de en ce qui concerne la mesure du code source du logiciel (voir la figure 3.4). C'est en 1968
o
trois valeurs, que Rubey et Hartwick publient un article intitulé « Ianalyse quantitative de la qualité
© Une indication des exigences de la clientéle face a la performance et a la d'un programme ». C'est le début des publications de la recherche en mesure de la qualité
fréquence d’exécution du logiciel sur une échelle de trois valeurs, du produit logiciel. La méme année, Dijkstra publie que I'énoncé de programmation GOTO
© Taille de la base de données, ne devrait plus étre utilisé, car il brise la structure naturelle des langages de
o Nombre dinterfaces, programmation et crée des maux de téte aux programmeurs qui désirent effectuer des
© Présence de on qui stipule les obligations interfaces ( changements.
agreement),
© Nombre d'installations, d’endroits ou le logiciel est utilisé, d'utilisateurs
En 1971, Allan Albrecht, chez [BM, crée la technique de calcul des points de fonction, qui
concurrents et supportés, permet une mesure de la taille du langage de
o Détail
de la doct isponible aux mai s, utilisé. C'est une ré i ire qui attire et qui, encore
© Pourcentage de couverture de la documentation, aujourd'hui, posséde un groupe dintérét important, le regroupement international des
utilisateurs des points de fonction (IFPUG). Il y a aujourd'hui différentes méthodes pour
© Heures de disponibilité du logiciel cité dans l'entente de service,
© Nombre et taille des changements effectués. compter des points de fonction et méme une norme internationale : la norme ISO 19761.
Bien sr, on peut procéder de maniére progressive et commencer avec les mesures de Baker, en 1972, publie que la taille idéale d'un module de code source devrait avoir des
base, tel que décrit dans I'article de April et Al-Shurougi (April, 2000). Les mesures que limites inférieures et supérieures (de 50-200 lignes de code) pour permettre l'amélioration
11SBSG va publier pour les organisations de la maintenance sont : du degré d'analyse par le programmeur. En 1975, Hecht présente la technique de
1. La productivité, qui mesure lefficacité de la maintenance (en général et par logiciel). Panalyse du flux de données a l'aide de graphes. McCabe, en 1976, utilise ce concept et
Plus cet indicateur est bas, et plus les couts de maintenance sont élevés, crée la notion de nombre cyclomatique qui évalue le nombre indépendant de chemins (c.-

a-d. de décisions) dans un programme. Il émet L'opinion qu'une valeur cyclomatique de En 1991, Azuma, qui a été longtemps le responsable de la mesure de la qualité chez
10 et moins permet une meilleure maintenabilité d'un logiciel. 1SO/SC7 JTC1 WG6, présente la contribution du Japon pour la création d'un modele de
Halstead, en 1977, décrit les pr tes comme un Ia qualité d'un produit logiciel. Ces travaux sinspirent des travaux de McCall et culminent
opérateurs/opérandes. Il décrit la mesure de complexité du code source qui portera son dans la publication de la norme ISO 9126 qui est maintenant la norme ISO 25010. Depuis
nom. La méme année, McCall présente son modele des facteurs de la qualité du logiciel. lannée 2000, on continue de voir lapparition de mesures du logiciel qui tentent de
Ryder, en 1979, publie pour la premiére fois comment construire un graphe d’appel. mesurer les aspects aux de ion objet.
Schneidewind, la méme année décrit la notion d'accessibilité d'un neeud (représentant Lors des travaux de conception du modéle de référence ISO 25010, les notions de qualité
une décision) et le nombre minimal de chemins et nombres uniques de chemins pour externe et interne d'un logiciel sont utilisées pour refléter la méme expérience quavec
rejoindre un naeud spécifique. Ces études aident dans la détermination de la notion de nimporte quel produit de consommation (voir Figure 3.5). Prenons lexemple d'une
complexité a code source. et en 1981, présentent le calcul de réparation de votre voiture. Vous n'étes pas expert en réparation d’automobile alors vous
des appels de Weiser, en 1984, présente la ne savez pas précisément les détails du travail a faire pour réparer votre voiture quand il
technique a « slicing + (qui permet un ensemble de variables et un énoncé). y a un pépin, ce qui veut dire que vous avez seulement une perspective externe de ce
travail. Seulement quelques attributs externes sont mesurés par une perception externe
+ 1) le temps d’attente, 2) le cout de la réparation, et 3) la qualité de cette réparation (c.-&-
Azuma Singh d. que ca ne retombe pas en panne pour les mémes raisons dans les jours suivants).
SCOPE
mersmeres
meare
incirecte:
Figure 3.5 — Relations et mesures de la qualité externe et interne d'un logiciel
Pour conti avec cette i i pré la ive de qualité

interne de la réparation de cette méme voiture. C'est la perspective du mécanicien vis-
avis le travail 4 faire pour effectuer cette méme réparation. Par exemple si la
Figure 3.4 Sommaire de I'historique de la mesure du produit logiciel (1968 a 2000) conception de la voiture n'est pas trop bonne, il va devoir travailler plus longtemps et
peut-étre remplacer plus de pieces. Alternativement, une trés bonne conception de la
Par la suite apparait le modéle de la fiabilité décrit dans la norme CE sa01). Ce modéle voiture va surement étre plus facile et moins couteuse. Conséquemment la qualité
offre une i de la terminologie des facteurs
qui i ibilité du interne de la voiture, si elle est moins bonne, va nécessairement influer sur la durée
logiciel. Ferrante, en 1987, présente la notion de graphe de dé we de la réparation et son cout. Ainsi, on peut constater qu'il y a une certaine relation
permet de définir des arcs de controle et de dépendances. Ces arcs servent dans la entre les caractéristiques internes et externes d'un produit = mieux il est concu alors
conception de mesures de complexité du code source. Daniel Rocacher, en 1988, publie moins il sera long/couteux de le réparer.
plusieurs mesures pour le code source Smalltalk. Cest de 1990 & 1995 que les travaux La figure 3.5 représente ces relations. On peut voir qu'il est possible de mesurer
nips du code source avec loutil Datrix et de Ificole polytechnique de Montréal, ainsi directement la qualité vue avec un attribut externe (c.-4-d. combien de temps a pris la
i sur ce sujet. Ces r tentent
réparation et combien elle a couté). On peut voit aussi que le mécanicien peut mesurer
ddentiter les modules qui posent le plus grand risque dans un logiciel existant. En 1990, la qualité interne directement (c.-a-d. la qualité de conception et Ia facilité & faire une
Horwitz présente aussi la notion d’analyse inter procédurale. Cette technique utilise une réparation du moteur). Les fleches pointillées elles des
combinaison de slicing et des graphes de dépendances pour illustrer et mesurer les plus subtiles. Un exemple de relation entre un attribut interne et externe est la
entre les dun systéme
logiciel. suivante : pour changer les bougies d'une Honda Fit, le moteur étant incliné vers la
cabine, il faut retirer les bras d’essuie-glaces et le capot juste pour les atteindre. En
Enfin, en 1990, le projet Scope, piloté par Robert
P. et A. Roan, introduit ct public une conséquence le temps est plus élevé et le cout de I'opération aussi.
pour I ion de la qualité d'un produit logiciel chez Verilog,
PSTI Evaluation et ie Ces travaux décrivent comment effectuer une évaluation Reprenons maintenant avec leffet indirect sur les attributs externes (percues par les
indépendante d'un produit logiciel qui est rép ible, impartialeet objecti utilisateurs) et la qualité interne d'un attribut logiciel (voir Figure 3.6). Plus la
IL ull des outils commercians déasiuaton de la qualité du code source font leur complexité d'un algorithme tel que mesuré par la mesure de la complexité cyclomatique
ion sur le marché (que nous verrons plus tard dans ce livre) est grande et plus effort pour trouver la

cause d'une défaillance d'un logiciel (qui influe sur le temps et le cout de la réparation
du défaut du logiciel) est grand.
1 |!
ne
| T |T
=|| [a[me | fe
[me |=
fe. (FEE
Figure 3.7 ISO 25010 ~ Modéle de la qualité d'un produit logiciel

attribut
rs : Nambre de chemins du graphe de contrdle
11 faut noter ici que les rapports techniques qui accompagnent la norme ISO 25010
Caractéristique: Maintenabibté proposent un éventail de mesures pour les aspects de la maintenabilité : taille (exemple :
nombre de lignes de codes modifiées), temps (interne d'exécution du logiciel et externe tel
Figure 3.6 — Exemple d'un attribut interne d'un logiciel qui influe sur un attribut externe que percu par le client), effort (individuel ou dune tache), unités (exemple : nombre de
en nombre de pour corriger une défaillance en
On constate assez rapidement qu'un projet logiciel ne pourra pas mesurer tous les producti é de ou ratios de plusieurs
attributs internes d'un logiciel et tenter de les relier a ses attributs externes. Cela ou de types de Par exemple, la corrélation entre la complexité
du logiciel et T'effort des essais lors d'une modification du logiciel.
deviendrait une tache complexe qui ne serait pas trés utile.
La norme IEEE 1061 donne aussi des exemples de mesures sans formellement prescrire
11 faut done décider de restreindre ces mesures de qualité interne de maniére & pouvoir des mesures spécifiques. En adoptant le point de vue que la fiabilité est une importante
Sen servir pratiquement dans nos projets avec nos clients. Cest ainsi que le modéle de la caractéristique de qualité d'un logiciel, le guide explicatif IEEE 982.1 propose un
qualité du logiciel a été développé et normalisé. La qualité du logiciel en tant que produit dictionnaire de mesures. Cette norme identifie, entre autres, six différentes mesures de la
est particuliérement importante pour les équipes de logiciel autant lors du développement complexité du code source.
que de son évolution. La norme ISO 25010 identifie huit caractéristiques de la qualité
dun logiciel, dont a maintenabilité (fgure 3.7). Les mesures de la complexité de la structure du logiciel sont habituellement extraites du
code source au moyen d'observations sur les caractéristiques du graphe? associé aux
La Al par cing istiques : la
classes, aux mé aux pr et aux du code source des
modularité, la rlisabiltt la facilité d’analyse lors dun probleme, la facilité de programmes. Les études des graphes permettent d'obtenir des indications sur la
modification et la facilité de test. Deux différentes perspectives de la maintenabilité du complexité du logiciel. Ces études sinspirent des travaux initiaux des années 70 de
logiciel sont souvent présentées dans les publications de génie logiciel (Lagtie, 1996). McCabe, de Halstead et de Curtis.
Approchée du point de vue extern, la maintenabilité tente de mesurer : 1) Teffort On trouve, aujourd'hui, un grand nombre de progiciels commerciaux, et progiciels libres,
pour un ouun 2) analyser limpact d'un
et 3) effectuer une modification a un logiciel spéci tel que Design Structure Matrix, et sonarlint, Stine Cobertura, Codecov pour
n'en nommer que les prétes pour
Du point de vue interne, on parle plutot de mesurer les atiributs du logiciel qui l'utilisation, et permettent aussi aNos nes den concevoir a nouvelles selon leurs
cet effort de ion telle que la é du logiciel, sa structure exigences spécifiques. Boloix indique que c'est linterprétation de ces mesures qui est
interne et sa ion. La mesure de la mai ité interne n'est pas une mesure difficile, car elles sont trés pointues, et il n'y a pas beaucoup de mécanismes pour
directe, c'est-a-dire quil ny a pas qu'une seule mesure interne d'un logiciel, et on se doit synthétiser linformation pour la prise de décision : les mainteneurs se retrouvent souvent
de mesurer plusieurs indicateurs afin den tirer quelques conclusions sur sa avec des trés sans de valeur ajoutée communicable
maintenabilité. directement a l'utilisateur du logiciel.
Le professeur April utilise ces techniques ches Cable & Wireless avec quatre progiciels
commerciaux de mesure du logiciel losses * Logismpe, Codecheck et Datrix de
de et de la
peuvent étre quantifiées & partir de la mesurere in code source du logiciel. Ainsi, un logiciel
bien concu sera construit avec des composantes indépendantes, modulaires et bien
qui des claires ayant des interfaces normalisées.
2 On associe & un programme un graphe avec une entrée et une sortie, chaque sommet correspondant & un ensemble:
instructions séquenticlles.

En utilisant le principe de la dissimulation de I ion pendant la ion du + Des progiciels sont isponibles pour mesurer différents attributs qui
logiciel, on obtiendra les plus grands bénéfices quand des modifications seront influencent la maintenabilité du logiciel. Un logiciel libre des plus utilisé en classe
nécessaires durant les essais ou aprés la mise en production. Cette technique a lavantage actuellement est SonarQube,
aussi de protéger les autres parties de application quand une modification est © Linterprétation des mesures du code source est difficile, car ces mesures sont trés
nécessaire. On réduira donc les effets secondaires d'une modification. pointues, et il ny a pas de isme pour synthétiser l'information
Plusieurs outils commerciaux d'évaluation de la qualité du code source ont fait leur quant a la prise de décision, et
apparition sur le marché et méme des outils en logiciel libre comme SonarQube. Regardez + Les organisations ayant une plus grande maturité en génie logiciel proposent des
quelques travaux d%étudiants de 'ETS qui ont évalué le code source a partir des concepts mesures précises et évaluent la qualité du code source.
de I1S0 25010 ©
~ Rapport #1 : utilise ReShaper, Metrix et Visual Studio pour évaluer la qualité d'un 3.5 LA MESURE DU SERVICE
logiciel en C# de 45,000 lignes de code,
~ Rapport #2 : utilise SonarQube et le modéle qualité SQALE pour évaluer un logiciel La mesure du service de la maintenance peut se faire selon deux perspectives :
client-serveur en Java de 172,000 lignes de code,
1. Lentente de service (entente interne, contrat de service et contrat d'impartition),
~ Rapport #3 : utilise SonaQube, le « plug-in » SIGMM qui simplifie la comparaison de
deux versions d'un gros logiciel pour en évaluer 'amélioration progressive dune 2. Le (du terme anglais ing) de la mai du logiciel.
application Java (14,604 lignes de code) qui comporte des algorithmes complexes et
une application Java (22,110 lignes de code) de production de rapport développée en 3.5.1 L’ENTENTE DE SERVICE
‘mode preuve de concept,
~ Rapport #4 : utilise Logiscope, Checkstyle, PMD sur 3 logiciels de différentes tailles Lentente de service interne
Afin de clarifier les spécificités du niveau de service, une entente est développée entre
l'utilisateur et le groupe de la maintenance. Cette entente peut étre interne a
Les mesures de couplage des routines, elles, aident a déterminer si les composantes du l'organisation. Lentente de service interne (Service Level Agreement) porte sur
logiciel sont i ou non, Clest spéci cette mesure qui aide a identifier Identification des services de la maintenance, la poursuite dobjectifs mesurables et les
si des effets secondaires peuvent apparaitre en modifiant le code source. résultats obtenus. Les ententes de services internes sont apparues a lorigine dans les
Une mesure de la documentation interne d'un logiciel peut aussi étre effectuée grands centres d'opérations informatiques durant les années 50.
automatiquement a l'aide de ces outils. La documentation interne d'un logiciel aide le Progressivement, l'entente de service interne contribuera a lamélioration de la
programmeur de la maintenance, 4 un niveau détaillé, a comprendre la signification des satisfaction de la clientéle dans un environnement compétitif. Peu d’auteurs ont abordé
variables et de la logique de groupes dinstructions. Certaines mesures font ressortir la directement l'entente de service pour la maintenance du logiciel.
nécessité d'utiliser un style simple pour programmer et permettent d'évaluer si les normes
de pr ont été r par les
CobiT, qui décrit les pratiques qui doivent étre mises en place pour rencontrer les
des ve identifiela définition et la gestion
du niveau de
April étudie aussi la mesure de la structure du code source afin dévaluer impact sur la service comme une pratique essenticlle ayant pour objectif la mesure du service
é. « Une partie el des couts de la mai est dévouée aux informatique. CobiT décrit cing niveaux de maturité pour I'entente de service (inexistant,
qui devi ires face aux requis par ad hoc, qui se répéte, défini, géré et mesuré, et optimisé). CobiT couvre aussi d'autres
les utilisateurs. A la suite de nos observations et a nos données, nous observons aussi processus du génie logiciel qui touchent directement la maintenance du logiciel.
qu'un logiciel bien structuré permet deffectuer ces changements plus facilement qu'avec
un logiciel mal structuré. » April décrit en détail I'entente de service interne du groupe de la maintenance du logiciel
chez Cable & Wireless. Cette entente fait ressortir les sujets plus spécifiques de la
La technique de programmation structurée est basée sur la décomposition d'un probleme ‘maintenance (April 2001) :
complexe en partie plus simple et force chaque composante a posséder une seule entrée . ilités du client de la
et une seule sortie.
Les mesures les plus répandues évaluent la ité et la taille, et contribue a se former . ilités du groupe de la
une opinion sur le nombre de jeux dessais requis et la complexité des décisions dans le «Description des services de la maintenance :
code source. «Le plan de test unitaire idéal est celui qui exécute, d'une maniére ~ Gestion du programme de maintenance,
exhaustive, tous les chemins du flot de controle d'un programme. En réalité, ce n'est pas ~ Gestion des requetes, des piorités ct du logiciel de gestion des requétes,
pratique et souvent presque impossible parce que le nombre de chemins possibles est - corrective, pré ive et perfective é 150
infiniment grand. » (Humphrey 1990)
14764),
En résumé : ~ Planification et gestion des versions (releases),
+ La mesure du produit logiciel est un sé, et, comme le ~ Gestion de la configuration,
ISO de mesures reliées 4 la norme ISO 25010 n'est que peu connu, il n'y a encore
que peu d'organisations qui ont pu lutiliser pour faire leur collecte de données en ~ Gestion des licences, entiercement et contrats avec des tiers,
utilisant les normes internationales, ~ Récupération aprés désastres,
~ Support a la clientele,

~ Exclusions, ~ Services de la maintenance et services optionnels,

~ Liste détaillée des logiciels supportés, par priorités, ~ Limites (out of scope),
~ Frais de service, ~ Termes généraux du contrat,
~ Heures de service, ~ Obligations du client et de son personnel,
~ Escalade en cas de probleme, - Confidentialité,
~ Mesures et performance, et ~ Reproduction de la documentation et du code, et
~ Revueset mécanismes de résolutin de dé et de ~ Limitesder ilité, force majeure, asi ion, survie, lois.
April met en pratique les ions des écialisés des ententes de Vous pouvez trouver des exemples types de contrats de service de la maintenance dans
services : une définition claire du service, des mesures et des objectifs et un inventaire le livre de Marzouk et Parry (Marzouk, 1994) ainsi que sur Internet. Cest, en général,
détaillé des applications maintenues. La diversité des logiciels qui font l'objet de dans les annexes que nous retrouverons les consensus des deux parties concernant : la
maintenance exige une description détaillée de chaque logiciel. Pour chaque logiciel, on classification des erreurs, les taux et les procédures qui devront étre utilisés par les deux
décrira sa clientéle et les ilités particuliéres, les la couverture des parties pour rapporter un Dans ces les catégories de la
heures de support, les volumes historiques de travail, la localisation des équi et la requéte de changement, la sévérité des problémes, les temps de réponse et l'escalade
de la clientele, les objectifs de disponibilité, les paramétres des services de recouvrement sont typiquement définis.
en cas de désastres, les contrats avec des tiers et, finalement, les programmeurs qui Voici quelques observations faites a partir de lanalyse des contenus des contrats de
sloccupent de ce logiciel. service
Bouman (Bouman, 1999) observe que approche courante de Industrie dans la rédaction (de 1988 & 2003) de la maintenance du logiciel :
des ententes de service interne comporte néanmoins certaines faiblesses : ~ Les fournisseurs définissent le temps de rappel (qui est le temps entre lapel de
~ Pour le client qui désire se concentrer sur ses affaires et s'attend a un service service du client et la confirmation de réception de l'appel chez le sous-traitant), et
de son isation de support i ique, les détails ques des non le temps de résolution d'un probléme,
services et des logiciels ont une importance secondaire pour lui, ~ Les fournisseurs donnent des objectifs de résolution d'un probléme, mais n'offrent
~ La description des ré de la mai nest pas représentée du que des rapports pré leur passée,
point de vue du client ; elle est plutot complexe et souvent trop technique pour le ~ Les catégories de travail et les mesures de la maintenance proposées par 11SO et
client, TISBSG ne sont pas encore utilisées,
~ lly a une confusion dans le transfert des responsabilités entre le groupe de - Les une liste et Ihistorique des problémes soumis par le
développement et celui de la maintenance. La notion de garantie initiale du logiciel processus documenté dans lentente contractuelle,
est souvent difficile a établir dans ce contexte, ~ Les fournisseurs ne parlent pas de l'entiercement d'une maniére volontaire,
~ Les récompenses et pénalités de service ne font généralement pas partie de lentente ~ La durée des ententes de service est habituellement d'une année.
de service.
D'autre part, Marzouk et Parry identifient les risques spécifiques des contrats de la
3.5.2 LE CONTRAT
DE SERVICE AVEC UN TIERS ‘maintenance comme suit :
~ Le fournisseur propose des solutions temporaires aux problémes plutot que des
Le deuxiéme type d’entente est un contrat de service avec un tiers d'une durée souvent solutions définitives,
annuelle. Lindustrie du logiciel fait une distinction entre une licence d'utilisation d'un ~ Le fournisseur tentera de traiter la licence, lentiercement, le développement et la
progiciel (SAP/R3, Peoplesoft, Microsoft Dynamics, Oracle/HR, ... et les frais annuels de maintenance séparément afin d'obtenir plus de revenus,
support et de mai du progiciel. Un contrat de type inclura des ~ Les suppléments ne sont pas précisés, et
services de mise 4 jour des progicicls et offrira des activités de support en cas de
problémes. La licence de contrat de service de maintenance permet son utilisation et ~ Les essais de lentiercement sont rarement effectués ou inclus dans les frais.
décrit les termes de utilisation du progiciel. D'aprés le groupe GARTNER, les couts de la 1l faudra donc sinformer sur la meilleure approche d’entiercement pour votre entreprise.
maintenance sont entre 20 - 30 % du cout d'achat du logiciel, et ce pourcentage est en Il'y a actuellement une tendance & traiter ce contrat de service a partir de la stratégie de
croissance (Fontana, 2005). Une bonne approche est de tenter de regrouper les la gestion de la propriété intellectuelle de organisation.
entreprises qui achétent le logiciel pour obtenir le meilleur prix pour lachat initial des 11 est aussi sage d’augmenter la durée des contrats de service de la maintenance a trois
logiciels. II faut donc travailler avec les acheteurs pour trouver le plus d’arguments pour ans pour s'assurer de la stabilité des taux. On recommande aussi d'ajouter une clause
obtenir le meilleur prix. qui limite les augmentations, au moment du renouvélement, & un certain pourcentage.
Des observations effectuées en industrie sur des propositions de contrats de service d'un Lapproche qui a donné les meilleurs résultats chez Cable & Wireless a été de négocier la
tiers avec les acheteurs et cadres informatiques nous ont permis d'établir le profil d'un is avant la sign du contrat d’ siti ou de dé dun
contrat de service type de la maintenance : logiciel.
~ Définitions, La gestion des contrats de service de maintenance du logiciel est un domaine spécialisé.
~ Obligations du fournisseur,
Les acheteurs ont la responsabilité de négocier une réduction de prix. Pour ce faire, le
mainteneur devra suivre les démarches dacquisition du logiciel (Marzouk, 1994). Les

ententes sont souvent concues pour avantager les fournisseurs et n'utilisent que internationales) ni le niveau de services envisagé (avec des rapports et des mesures
la terminologie des normes i i du logiciel. Il faudra donc réviser précises).
chaque clause pour voir comment elle protege lacheteur, et non le fournisseur. Dans ce
cas, il est important de se préparer d'avance, de sinformer, de se former et de se référer 3.5.4 L’ETALONNAGE (BENCHMARKING) DES ACTIVITES DEVOLUTION CONTINUE
a des experts pour réviser les ébauches de contrats qui vous sont proposés.
Une définition souvent citée de I'étalonnage provient de Kearns, CEO de Xerox:
3.5.3 L’ENTENTE D'IMPARTITION « Létalonnage est le processus continu de la mesure comparative des logiciels, des
services et des pratiques de la société avec ses plus importants compétiteurs ou avec les
Le troisiéme type d’entente est une entente d'impartition de la maintenance avec un tiers, chefs de file de l'industrie. »
dune durée allant de cing a dix années. Limpartition des activités de la maintenance est Trois types d'étalonnage sont proposés par Xerox. Le premier consiste en un étalonnage
de plus en plus populaire. Elle est souvent une entente globale entre un fournisseur interne qui vise la comparaison entre les différents secteurs de organisation. Pour la
concernant l'informatique ou des grands secteurs de linformatique. Lentente maintenance du logiciel, on peut faire des de I' des tant
dimpartition typique est de longue durée, et organisation se départit tant de ses que a linterne de organisation et en tirer des
employés que de ses logiciels. Dans ce type d'entente, l'impartiteur prendra en charge les conclusions pour Yamélioration (Abran, 1993a). Le second type d'étalonnage, dit
employes et proposera des clauses de contrat de service au client. Les principales raisons itif, requiert la cueilt d ion des compétiteurs directs. Cette approche
citées pour impartir la maintenance sont (Carey, 1994) : est rendue difficile par les problémes dacces a I ion des autres on
~ Réduction des couts, peut donc se ces dansle ine. La derniére
~ Accés a lexpertise des employés de limpartiteur, proposée est I'¢ i qui consiste a trouver des organisations
~ Passer dune structure avec des couts fixes (croissants) 4 une structure avec des qui excellent dans le méme domaine fonctionnel, mais dans d'autres industries. Par
couts variables (décroissants), xemple, pour la mai générale de equi matériel, on pourra aller voir
la NASA, les éaires et l'aviation la et on
~ Obtenir un revenu de la vente des actifs, en tirera des informations utiles.
~ La maintenance n'est pas un élément stratégique de la société, et Quien estl du domaine du logiciel ? Le préalable a Iétalonnage est d’avoir une
Transfert des détails techniques et des problémes a limpartiteur. compréhension claire des processus internes. Il n'est toutefois pas nécessaire d’avoir un
Limpartition, incluant des taches spécifiques de la maintenance, a été réalisée dans programme de mesure trés élaboré, mais il faut cependant avoir des données en main.
grandes i et éres a travers le monde. Le contrat typique de Lindustrie et méme Wall Street décrivent qu'il est essentiel de considérer cette option et
I'impartition de la maintenance est différent d'un contrat de service. Voici quelques que si une grande société ne posséde pas cette compréhension et une certain quantité
observations provenant de Iétude de ces ententes d’impartition : dimpartition elle ne profite pas vraiment d'occasions d'optimiser ses couts.
~ Limpartiteur inclut les logiciels pris en charge avec leur code source et traite Deux approches sont plus es concernant I du logiciel. L'approche que
différemment les progiciels (Sap R/3, Oracle RH, etc.) de Ientente générale, nous avons observée le plus souvent consiste en un étalonnage compétitif en ayant
~ Limpartiteur offre habituellement une garantie de 90 jours suite a une correction
recours a une firme de isée dans I'é des services
informatiques. Par exemple, des firmes de consultation et d’avocats (comme le Gartner
erreur spécifique, Group, KPMG, Accenture, McCarthy-Thétreault, Boston Consulting Group, Bain &
~ Limpartiteur demande au client d'établir les priorités des travaux de la maintenance, Company, McKinsey & Company et plusieurs autres) utilisent leur propre approche
~ Limpartiteur tient une liste et Ihistorique des problémes soumis par un logiciel du commerciale pour la collecte et lanalyse de linformation, sur la base de leurs
bureau d'aide (« help desk »), pour la les firmes qui utilisent cette
~ Les catégories et les mesures de la maintenance présentées dans les normes ISO ne approche présentent, a la fin de lexercice, des variantes des mesures suivantes :
sont pas encore utilisées ; on parle plutot de classification unique a chaque contrat, ~ Points de fonction supportés par personne (développement maison),
du type : corrections, préventives, réglementaires, controle de version, rapports ad ~ Points de fonction supportés par é maison + progiciel),
hod,
~ Cot par point de fonction supporté,
~ Une référence 4 la création d'une entente de service interne et de mesure est faite, ~ Moyenne de Ige (en années) des logiciels applicatis (actuellement en production),
‘mais rarement un rapport ou un processus de revue n'est propose, et
~ Groupes dage (en par ité) des logiciels
~ La durée de l'entente d'impartition est généralement de cing ans. (actuellement en production),
Serge St-Pierre de Air Canada (St-Pierre, 1993) décrit « Notre intention est d'impartir, si
toutefois nous pouvons trouver une maniére d'exercer un controle stratégique. » Il est ~ Nombre de langages de programmation supportés,
donc difficile, dans ce domaine, d’obtenir des mesures de controle bien définies. Clest ~ Structures de données supportées (séquentieles, indexées, elationnelles, autres)
aussi connu que 50 % des sociétés acceptent ce genre de contrats sans avoir d’entente de - de type de p
service précise. St-Pierre cite également un rapport du Gartner Group, qui fait monter ce applications),
pourcentage a 85 %. ~ Support - index de la complexité de lenvironnement (basé sur le nombre
En résumé, les ententes d'impartition précisent des objectifs financiers, mais sans dutilisateurs, la taille des données, le nombre de plateformes et leur puissance),
clairement définir les services impartis d'une maniére mesurable (selon les normes

~ Support - diversité ique (nombre de pr de de pas diidenti i les lecons d’amélioration des sociétés comparées. Des activités
darchivage des données, d'outils et de systémes d'opération), détalonnage avec des groupes d'utili sont posible avec l'aide dun
~ Support - utilisation de Foutil CASE, spécialiste interne. Certaines sociétés publient des résultats intéressants découlant de
- de stabi des és (taux de 1! t),
I'utilisation de cette approche.
~ Durée de service des employes (en années),
~ Niveau des du total des de la
compagnic),
- Salaires,
~ Effort de formation (nombre de jours de formation par personne par année),
~ Taux des défauts en production (par niveau de criticité : critique, majeur, mineur ou
cosmétique) par 1000 points de fonction supportés,
~ Taux de défauts en ion (par ie de cause :
environnement ou autre) par 1000 points de fonction supportés.
Un certain nombre de faiblesses ont été notées a cette approche :
~ Exercice court (limité 4 environ un a deux mois) et cueillette des données non validées
(souvent, les données ne sont pas disponibles, et ont da étre estimé ou
inventées),
~ Données comparatives cachées (on ne sait pas avec qui on se compare),
~ Problémes de qualité des données (exemple : qualité du calcul des lignes de code),
~ Crédibilité de la ligne de code comme base de la convertibilité pour établir la quantité
de points de fonction,
~ Quantité de di (40 aspects
~ Linterprétation des résultats ne tient pas compte de faits spécifiques, mais plutot de
généralités difficiles a contredire et a valider, et
~ Impossible dobtenir le détail des meilleurs performant et ce quiils font exactement
pour obtenir cette performance.
En résumé, un nombre important de mesures sont présentées organisation, mais il ny
a pas moyen de savoir si ces mesures sont valides ni de connaitre les pratiques des
sociétés qui semblent plus performantes.
Une deuxiéme approche consiste & effectuer un étalonnage (benchmarking) avec un
groupe dutilisateurs. Le plus connu est: |
St Group - (ISBSG). Cette isation a I’ d'ouvrir la base de données
a ses membres et de permettre de partager leurs expériences. La participation a ce genre
activités est spécialisée et ne comprend pas lachat d'un service « prét-a-porter ». Clest
donc un faible nombre d'organisations qui vont participer & ces groupes diintéréts, car
cela requiert un spécialiste a Interne qui se dédie a cette tache pendant plusieurs années
consécutives. Nous avons toutefois observé que, dans les référentiels de ces organisations,
ily a encore peu de données sur la maintenance du logiciel, mais un grand nombre pour
les projets de développement de logiciel.
Enfin, Jones propose une demitre forme dtalonnage quil nomme I¥talonnage
idére comme un examen médical du
groupe pire afin détablir un dlagesc sur ce qui va bien et ce qui ne va pas en
utilisant un guide des meilleures pratiques de lindustrie. Le modéle du Software
engineering institute (Sei) (Sei, 2018) est le plus connu et le plus utilisé pour ce type
deétalonnage. Dans l'industrie du logiciel, cet exercice n'est pas souvent percu comme un
exercice d’étalonnage, mais plutét comme un exercice d'amélioration des processus.
En résumé, Iétalonnage du logiciel fait par les fires spécialisées ne permet pas
des car les données ne sont pas vérifiables. Ces
exercices d’étalonnage sont souvent faits rap et les ne

L'évolution contrdlée du logiciel 4 La compréhension d'un logiciel existant
4.1 INTRODUCTION
Nous avons présenté les types de é di a un logiciel.
Nous avons aussi présenté le métaprocessus de I'évolution continue du logiciel de SO
14764 (voir la figure 2.5). Toutefois, nous n'avons pas abordé, et c'est incontournable
pour étre efficace lors de I'analyse, comment acquérir des connaissances sur un loi
que Ton doit maintenir. Avant méme deffectuer un changement, il est essentiel d'acquérir
une bonne compréhension de ensemble du logiciel et des interrelations entre les
programmes, méthodes, classes et des données. Il est donc nécessaire, avant de permettre
a une personne de modifier le logiciel :
~ De posséder une connaissance générale de ce que le logiciel fait et comment il est
La compréhension d’un utilisé par organisation,
~ Deétre en mesure de localiser et justifier Iendroit oti les changements seraient
effectués, et
logiciel existant ~ démontrer comment chaque composant qui sera modifié se comportera et effet du
changement sur l'ensemble du logiciel et de ses données.
Lactivité de compréhension du logiciel consomme une proportion importance du budget

d'une itération surtout quand de nouveaux employés sont insérés dans les équipes. Par
Dans ce chapitre, nous couvrons : exemple, Hewlett Packard a estimé que l'activité de lecture de code source, qui est
Le rdle de la compréhension d'un logiciel en maintenance, incontournable pour comprendre un logiciel, coute prés de deux-cent-millions de dollars
chaque année (HP 1993). Vous pouvez trouver aussi d'autres publications qui proposent
Les objects de la compréhension du logiciel, que preés de la moitié de leffort d‘évolution continue d'un logiciel soit attribué aux activités
Les besoins de compréhension du mainteneur, reliées a sa compréhension. Cette proportion a a dans les si
Les modéles de compréhension et leur utilisation, suivantes : un nouvel employé arrive dans Iéquipe, le mainteneur n'est pas celui qui a
Les straégie de éhension et leurs diffé : initi ¢ é le logiciel, la ion est inexacte ou absente, la structure
du logiciel a été dégradée par des années d'évolution incontrolée. Malheureusement,
Les effets de chaque stratégie sur les activités de maintenance, Vingénieur logiciel connait bien ces problématiques quiils rencontrent lors de ses stages
Les facteurs qui ont un impact sur la compréhension du logiciel, en industrie, car il doit comprendre le logiciel en place. Ce chapitre traitera de ces
Un survol des outis, techniques et méthodes pour appuyer la compréhension du logiciel problématiques.
4.2 LES OBJECTIFS DE LA COMPREHENSION DU LOGICIEL

Etre en mesure de comprendre le domaine d'affaire d'un logiciel est incontournable pour
le mainteneur. II se doit d’acquérir une perspective d'utilisateur afin de bien comprendre
le contexte et les raisons d'un changement. Dans les logiciels de grande envergure, par
exemple dans le domaine de la santé, des télécommunications et de la finance, les
fonctionnalités clés du logiciel sont typi parti et ées dans des
composants précis. Une bonne i de la spéciali de chaque
d'un logiciel s'avére d'une grande importance pour le mainteneur qui cherche a choisir
une stratégie pour effectuer un choisir un algorithme adapté a la situation,
poursuive l'utilisation du patron de ion (c.-a-d. la mé du chapitre 1) qui
harmonise bien et utiliser des structures de données bien adaptées. Ainsi, la
compréhension du logiciel posséde sa terminologie propre. En voici quelques définitions :
Processus et structure cognitive
~ «Lastructure cognitive décrit la maniére d'enregistrer des informations. Le processus
cognitif représente la maniére dont la connaissance est manipulée par le cerveau
humain lors de la création et de l'utilisation d'un modéle mental. »
- «le cognitif décrit le mé i de 1% i de la
dans le cerveau humain. »

Modéle mental : du général vers le détail, et ce d'une maniére structurée. Cette approche (top down) vise
~ «Une é i if de simuler le les 2 et lignes de codes impactées par la
d'un phénoméne pour anticiper les résultats d'une action. » modification demandéc. Par exemple, la modification d'un compilateur de logiciel requiert
et que le mai . qui désire faire le comprenne ce domaine spécifique ou
ily a: un analyseur le, un géne de code et un . Ainsi, avec
~ «Lapproche ascendante oi l'on part du détail, des énoncés de code source, cest-a- cette connaissance, il sera en meilleure position pour efficacement réaliser son étude
dire le composant le plus fin, pour consolider progressivement et opérer une synthése dimpact et d'en évaluer leffort requis.
de la vue d’ensemble. » Bien cerner le ine de la problématique lui i de cerner les
~ + Lapproche descendante ou, partant de l'ensemble, on décompose Information en moyens qu'il doit mettre en ceuvre (c.-a-d. les algorithmes, patrons et structures de
toujours plus détaillés, pour cor la raison des composants données) pour ce travail. Il est donc important, pour le responsable du produit de choisir
détaillés. » des mainteneurs avec le bon niveau d'expertise et de connaissances des différents
Analyse syntaxique : domaines pour effectuer un travail de qualité. Le nouveau personnel pourra obtenir
~ «Lecture du code source d'un logiciel afin d’en identifier les constituants d'un énoncé. ces i a Taide de: la ion du logiciel, les contacts
Typiquement, cette analyse permet de regrouper des énoncés logiquement afin de fréquents avec les utili s et leurs colé la ion générale dans le domaine
comprendre leur but. » ainsi quala lecture du code source.
4.2.2 LEFFET
DE L EXECUTION
Pour comprendre un logiciel, il faudra lire le code source (et la documentation si elle existe
et refléte ce qui se passe actuellement sans le code source). L'objectif ultime de la lecture Au plus haut niveau d’abstraction, lingénieur logiciel a besoin de savoir quels résultats
du code source et de la compréhension du logiciel est d’acquérir les connaissances pour sont obtenus lors de Iexécution du logiciel, par exemple a la suite de la saisie de donnée
efficacement effectuer un changement & un logiciel, et ce sans créer de dégradation de la spécifique dans linterface utilisateur, sans pour autant connaitre tous les programmes
qualité ni deflets secondaires non désirés. Ceci nécessite lobtention, de la part du qui ont été interpelés pour produire ce résultat. Au niveau d’abstraction plus détaillée, il
, di r ives (voir tableau 4.1): 1) le domaine est nécessaire de connaitre ce que chaque méthode effectue en détail sur les données.
de la problématique & résoudre, 2) Veter de Texécution, 3) la relation cause a effet, 4) la Une bonne connaissance du flux de traitement et de données ainsi que des algorithmes
relation entre le logiciel et son envir technique, et 5) les utilisés par le logiciel facilitera grandement la tache d'un mainteneur.
fonctionnalités de support a la décision.
4.2.3 LA RELATION CAUSE A EFFET
Tableau 4.1 Perspectives des connaissances et leurs importances pour la compréhension
Connaissances Importance Dans un grand logiciel complexe, comprendre les causes a effets est important pour
1- Domaine de la problématique - appuyer le processus destimation plusieurs raisons :
- guider le choix d'aigorithme, de méthode, ~ Cela permet au personnel qui fait Iévolution continue de prédire la portée d'un
dloutil et du personnel approprié changement et les effets secondaires qui peuvent découler de la modification prévue,
2- Effet de 'exécution - Confirmer que le changement refléte bel et Lingénieur logiciel peut les entre les dife du
bien i désiré logiciel,
3-La relation cause 4 effet - Préciser la portéedu changement, prédire des ~ La relation cause a effet peut étre utilisée afin de suivre le flux de l'information au
effets secondaires possibleset représenter les travers des composants.
graphes de cause a effet, de flux de controle et
le flux de données (que nous verront dans lest Par exemple, un logiciel enregistre des informations dans une table A afin de s'en servir
tests logiciels) plus tard. Ces données sont par la suite lues de la table A par une autre méthode qui
4-La relation logiciel - environnement - Evaluer comment le changement peut s’attend de trouver les données dans un certain ordre. Si les données ont été changées
impacter son comportement et sa qualité ordre, a la suite d'une modification maladroite qui n'a pas pris en compte cette subtilité,
Ia cause du probléme tapie dans lordre des données de la table A sans que le code source
5- Le support 4 la décision - Appuyer les processus techniques et de ne soit affecté.
gestion de support aux décisions
4.2.4 LA RELATION ENTRE LE LOGICIEL ET SON ENVIRONNEMENT
4.2.1 LA CONNAISSANCE DU DOMAINE
Un logiciel i sur un envi opérati (c.-a-d. matériel, systéme
Etre en mesure de comprendre le domaine d'un logiciel est considérer un des facteurs dopération, systéme de gestion de base de données, logiciel de poste de travail) et est
clés de lefficacité de son évolution continue. Les grands logiciels patrimoniaux complexes aussi influencé par des facteurs externes (par exemple : les régles d'affaires changeantes
des domaines de la santé, des télé ications et de la finance requiérent que et les lois et ré gouver qui é 11 est incontournable, pour le
Tapproche initiale d'analyse d'une modification soit approchée, d'une maniére générale, de la mai EE ces relations et leurs i sur son

évolution. Cette i guiderale mai dans ses prédictions d'impact d'une du code du logiciel, mais plutot de son fonctionnement d'un point de vue de transactions
modification. d'affaires.
4.2.5 LE SUPPORT A LA DECISION 4.3.3 LES CONCEPTEURS
Les attributs de qualité, décrits au chapitre 2, tels que la complexité et la maintenabilité, La conception du logiciel se situe a deux niveaux : architecture et la conception détaillée.
sont deux exemples de facteurs qui guident le personnel de la maintenance lors de leurs Larchitecture logicielle se préoccupe de créer des composants fonctionnels, des
décisions technique pour guider le choix des options d'analyse, destimation, et structures de données conceptuelles et de s'assurer d'une interconnexion efficace et
da up pour un au logiciel. Par exemple, la mesure de la des La ion détaillée vise a choisir judicieusement les
complexité cyclomatique (McCabe 1976) peut servir lors de la décision de modifier le code algorithmes, les structures de données et les interfaces entre composants logiciels. Lors
source. de la maintenance d'un logiciel, le concepteur se doit de :
~ Comprendre la et le peut
Les techniques de rétro-ingénierie peuvent aussi servir pour appuyer les décisions de siinsérer, sans dégrader, et peut-étre méme améliorer, la conception existante,
maintenance. 1l y a plusieurs facteurs qui impactent Iétendue de acquisition de Investiguer, a partir du code source existant, pour obtenir des données concernant :
connaissances d'un systéme. Les plus importants font partie des catégories suivantes : la taille du changement, les endroits visés par le changement et les connaissances qui
les de é la du ine, la qualité de la seront requises pour effectuer ce changement.
ion, la pré ion et organisation et la iton du code source, les
normes de nomenclature, les questions de mise en ceuvre, les mécanismes de La pré et lutilisation de repré iques de la i ées ala
décomposition et les outils qui seront abordés dans ce chapitre. section 2.4, tel que le masquage, la décomposition modulaire (c.-a-d. le couplage et la
cohésion), I'abstraction des données et Ihéritage peuvent aider le concepteur a obtenir
4.3 LE MAINTENEUR ET SES BESOINS D’INFORMATION rapidement une bonne compréhension du logiciel avant d'effectuer une modification.
Il west pas essentiel que chaque membre de Iéquipe de maintenance connaisse, en détail, 4.3.4 LES PROGRAMMEURS
toutes les parties du logiciel faisant objet de maintenance. Le processus de
compréhension du logiciel est utilisé au moment précis ot il est nécessaire de faire une Le de mai a besoin de itre l'effet de Iexécution d'un logiciel
modification ou une correction. Chaque membre de I'équipe possédera donc une a plusieurs niveaux d’ ion. Particulié il est intéressé par la relation de cause
compréhension différente du logiciel et cela est fondé sur : ses connaissances du domaine a effet et de Penvironnement opérationnel. D'un point de vue conceptuel plus élevé (c.-a-
et techniques, son expérience passée de travail sur des logiciels semblables. Chaque d. au niveau du syte le pr ur de la mai doit ser le
membre de léquipe apporte une perspective différente. comportement fonctionnel de chaque composant du logiciel et leurs interrelations. A un
niveau conceptuel plus bas (c.-a-d. niveau procédural et des méthodes), la préoccupation
4.3.1 LE GESTIONNAIRE DE LA MAINTENANCE est de comprendre la d’ et de des données (c.-a-d.
entrées, traitements et sorties) et le but de chaque composant du logiciel impliqué dans
La gestionnaire, comme nous l'avons vu au chapitre 1 et 2 doit prendre des décisions la modification. Une maitrise de ces informations permet au programmeur de :
quotidiennement pour s’assurer du bon fonctionnement du logiciel maintenu. Le niveau ~ Décider si le code source doit étre restructuré ou réécrit,
de connaissance quil posséde dépend donc de Importance des décisions a prendre. Par ~ Prédire les effets secondaires que le changement proposé va causer aux autres
exemple pour donner une estimation concernant une modification importante, il lui sera composants du logiciel,
utile de itre la taille i du (par exemple en points de ~ Se former une hypothése sur la cause d'une défaillance ou d'un défaut, et
fonction). Avec cette information, il pourra utiliser des données historiques de
maintenance pour valider l'estimation qui lui est fournie par son personnel. Le — Fvaluerla faisabilitt d'un changement proposé afin de documenter les options
fonnaire de la mai n'a pas nécessai besoin de connaitre la conception possibles dans son document d’analyse d’impact.
détaillée et les détails du comportement de chaque programme, mais il doit avoir une
bonne vue d'ensemble. Lutilisation d'outils logiciels spécialisés, tels que Ianalyseur statique, I’ effets
secondaires, le référenceur croisé et la tranche (de l'anglais « slice ) peuvent aider a
4.3.2 LES ANALYSTES effectuer ce travail plus rapidement. Méme si nous avons présenté plusieurs catégories
de personnel de la maintenance, en pratique ce n'est pas si simple que cela. La présence
Lanalyste est souvent un bon spécialiste du domaine d'affaires, des régles affaires, des de ces différentes responsabilités va dépendre de la structure organisationnelle choisie.
et non i et de la relation entre le logiciel et son Nous avons vu, 4 la section 1.3, qu'un individu pourra jouer l'ensemble de ces roles dans
environnement. Lors de la maintenance, analyte est bien placé pour évaluer limpact de trés petites organisations. Dans de plus grandes entreprises, qui comportent plus de
potentiel d'une modification sur le systéme actuel, C'est Ianalyste qui a la vue d'ensemble 100 rs et dé urs, parfois dé dans pays, on y
du logiciel et bien les i entre chaque é. Au méme titre retrouvera ces roles qui visent a mieux diviser, controler et gérer le travail quotidien.
que le gestionnaire, lanalyste n'a pas besoin de connaitre les détails de implantation et

4.4 LES MODELES DE COMPREHENSION DU LOGICIEL ‘modéle mental qui vous permet de prédire son comportement quand elle est ouverte ou
fermée. A Taide de ce modéle, vous pouvez tenter d'expliquer pourquoi limage est
embrouillée aujourd’hui. Aujourdhui il a neigé et mon récepteur satellite ne fonctionne
Les programmeurs de la maintenance ont tous une maniére différente de raisonner, pas aussi bien quand il est enneigé. Pour faire cette déduction, vous n'avez pas eu besoin
résoudre un probleme et d'utiliser les outils de maintenance mis a leur disposition. De de itre le ique de l'appareil. Un technicien cependant
‘maniére générale il y a trois principales actions impliquées lors de la compréhension d'un pourrait vous expliquer ce qui se passe vraiment dans le phénomene physique des ondes
logiciel : 1) lire a son sujet, 2) lire le code source et 3) étudier effet de son exécution. pour ce cas précis. Comme nous avons vu a la section précédente, chaque mainteneur
1) Lire au sujet du logiciel : Cette premiere étape nécessite de retrouver la documentation posséde des modéles mentaux différents et précis a différents niveaux selon leur role de
concernant le systéme, ses ses sa ion et son maintenance.
des données. Ces i si pré doivent étre & ées afin
den connaitre l'exactitude. Rien de pire qu'une documentation qui ne refléte pas
I'exécution actuelle du logiciel en production, Le contenu et la création d'un modéle mental reposent sur les structures et les processus
cognitifs de Ihumain. Ce modéle se forme 4 la suite d'observations, interactions et
2) Lire le code source : pendant cette étape, une vue d’ensemble accompagnée d'une vue inferences avec un systéme sous étude. Il change et évolue constamment. I a été
détaillée peut étre obtenue du logiciel. Des outils peuvent étre utilisés pour aider a que sa précision et est i par les deux
représenter la structure d’appel et d'accés aux données. Etant donné que la facteurs suivants : lexpérience avec des syté imilaires et les
documentation peut étre erronée, cette activité est incontournable et la plus fiable techniques. Bien que le modéle ne soit jamais parfait, il doit, au minimum, référer aux
afin de connaitre le comportement détaillé d'un logiciel existant, clés concernant le systéme référencé. Par exemple si C'est un systéme
3) Exécuter le logiciel : L'objectif de cette étape est d’étudier le comportement dynamique logiciel, le modéle doit décrire la fonctionnalité offerte. Les résultats des recherches
du logiciel. Il est possible de suivre lexécution, instruction par instruction, du logiciel concernant le comportement cognitif des mainteneurs, lors de lapprentissage d'un
et de voir l'affectation de chaque variable tout au long d'une transaction d'affaires. Le nouveau logiciel, suggérent qu'il y a plusieurs stratégies de compréhension (c.-a-d. de
bénéfice de cette étape est de voir I ion de chaque création d'un modeéle mental) du logiciel. Cest-a-dire que les structures cognitives et les
par rapport a le faire statiquement en effectuant la lecture du code source. processus cognitifs varient.
De maniére pratique, le processus de compréhension d'un nouveau logiciel ne se fait pas

en suivant ces étapes séquentiellement. Il y a des itérations entre les trois étapes qui 4.6 LES STRATEGIES DE COMPREHENSION DE LOGICIELS
nécessitent des retours en arriére entre la documentation, la lecture du code source et
son exécution. Chaque cycle souléve de nouveaux questionnements et des doutes qui Une stratégie de compréhension du logiciel est une technique qui est utilisée par un
requiérent de plus en plus dinvestigation. Il a été observé, que le mainteneur qui itére ‘mainteneur afin de se former un modéle mental d'un logiciel. Ce modéle est construit en
dans ces trois étapes, va graduellement se former un modéle mental du logiciel. Ce modéle combinant Information du code source, des données impliquées et de sa documentation
mental, une fois acquis, devient un atout important pour le mainteneur pour lequel la avec Laide des connaissances déja acquises, par le mainteneur, sur des logiciels similaires
confiance grandit. La prochaine section discute de ce phénoméne cogniti, initialement de technologie similaire.
découvert par Kenneth Cralk, en 1943, qui est au centre de la construction dian systeme
de référence cognitif organisé a , de Tableau 4.2 Les différentes stratégies de compréhension de logiciels
concernant un systéme.
Caractéristiques
Modale Principe du modéle | Processus cognitif Structure cognitive
Approche | C: entre du | -Conna du
4.5 LEMODELE MENTAL descendante | ce que les domaine de connaissance et des | probléme et du domaine
fonctionnalités font et |
interrelations ~Connaissances
ce que les <Fondée sur ls créeton intermédiaires
Les modéles mentausx sont nécessaires pour faire face des problémes et des situations et -Plusieurs niveaux de
exécutent artaement progressif connaissances du
nouvelles. Ils accélérent le raisonnement correct, mais plus important encore, ils domaine
fournissent la capacité de prédire ce qui pourrait arriver sur la base de certaines actions. Approche | Reconnaissance de | Agrégation de patrons identifies | - Correspondance entre
Pour aller plus loin et avec succés appliquer ou utiliser les connaissances dune maniére ascendante | patrons récurrents dans le détail des programmes les domaines de
érente, il faut les et les relations fondamentaux entre les dans le code source | afin de créer des représentations | connaissances
mentales des structures - Structure hiérarchique,
connaissances pertinentes afin de formaliser des actions possibles et d’en prévoir les ‘sémantiques les gouvernant a plusieurs niveau, de
résultats. Ainsi, pour que les mai puissent ré un problem et app: de patrons
a faire fonctionner les systémes complexes, ils doivent posséder une connaissance Approche | Combinaison de Pour chaque item étudié, une Similaire aux deux
opportuniste | approche alterance étude d éléments autres stratégies
structurelle précise de ce systéme et de son domaine d'affaires. descendante et information du systéme et du
Les modéles mentaux sont mal définis inexacts et incomplets. Ils sont en constante ascendante code source
évolution et quand le acquiert de les infor ils les comparent
celles qui stockées dans leur modéle, puis le font évoluer en conséquence. Par
exemple si vous savez comment une télévision fonctionne alors vous en possédez un

Un certain nombre de modéles décrivent comment le mainteneur sy prend pour

comprendre le logiciel. Le tableau 4.2 décrit les trois modéles principaux: ascendants, Linformation requise afin de générer une hypothése de départ se nomme une balise. Une
descendants et opportunistes. balise sert d'indicateur de la présence d'une opération ou d'une structure pertinente pour
résoudre le probleme étudié. On peut faire un paralléle avec activité de lire des bouts
4.6.1 L’APPROCHE DESCENDANTE dun article de journal afin de sen faire une idée générale. Quand notre intérét est satisfait
et que nous ne perdrons pas notre temps a lire cet article, nous procédons alors a le lire
Le principe de ce modéle est que le mainteneur débute ses activités de compréhension du début a la fin.
avec les éléments de haut niveau décrivant le logiciel, tels que : ce qu'il fait quand il
exécute une requéte, et graduellement tente de comprendre des détails tels que : les types Tableau 4.3 Balises d'un logiciel
de données, le flux de traitement et les lectures/écritures a la base de données. La Eléments intemes du texte du programme Eléments externes au programme
structure cognitive et le processus cognitif du modéle mental résultant de l'utilisation du
processus descendant peuvent étre imagés par la métaphore de conception suivante : La Commentaires dentéte, de variables et de données | Manuel d utiisateur
maintenance du logiciel, dans son ensemble, peut-étre vue comme une activité de Nom de variable, structure, procédure et étiquette Manuel d'e»
conception qui posséde deux processus tla et la Déclarations Manuel d'architecture et de conception
Commentaires dans le code source Représentations graphiques (flux de
i la production d'une nouvelle conception Indentation du code source traitement, digrammes de classe)
tandis que la compréhension est la maitrise des connaissances propres a cette Appels interes entre composants Imprimés de références croisées
conception. Enoncés d'entrées/sorties. Algorithmes de références
Processus
4.6.2 L’APPROCHE ASCENDANTE
c A l'aide de cette stratégie, le mainteneur reconnait progressivement des patrons dans les
Cc 0 programmes. A chaque itération, ils sont regroupés de maniére a former un modéle de
o M
“ Pp plus haut niveau et d’en reconnaitre les structures. Ces structures de plus haut niveau
4 R sont regroupées et forment de plus grandes structures de maniére a comprendre tout le
o E programme. La figure 4.2 décrit le modéle ascendant.
s H
! E
T N 11 a été observé que le processus de regroupement est plus rapide chez le mainteneur
! s experience. Par exemple I'énoncé suivant serait interprété, en regroupant les lignes de
4) 1 code :
N 0
N
Valeur_Maximale = Table [1]
For Index = 2 to 100 DO
Figure 4.1 Domaines de connaissances interpelés durant la compréhension If Table [Index] > Valeur_Maximale Then
aleur_Maximale = Table[Index]
End;
La ition nécessite d’ ié ce que le pr fait, dans le ine, a End.
comment un ensemble dinstruction de code source, du domaine de la programmation,
utilise un langage de programmation spécifique. Lors du regroupement final, I'énoncé : ‘trouver élément maximal du tableau’, qui est un
énoncé sémantique de plus haut niveau, représente bien Intention de ces six lignes de
code.
La compréhension est l'inverse de la Clest une tr ion du
dela ion vers le ine du pi a régler. La compréhension né
la reconstruction des connaissances de ces domaines et des interrelations entre eux. Ce
processus se préoccupe de créer, confirmer et dune maniére itérative, raffiner les
hypothéses du mainteneur. Le processus débute avec une idée vague accompagnée d'une
hypothése de haut niveau nommée hypothése initiale. Cette hypothése est ensuite
ée et raffinée p i 4 la suite de acquisition de du
systéme. Lhypothése initiale est générée dés que le mainteneur trouve un indice de
ée (c. pertinente pour une modification demandée
ou une correction urgente) dans un programme, une méthode ou une classe. La création
d'un modéle mental du programme débute alors.

~ Rassemblez des données au moyen dexpériences reproductibles,

~ Formez une hypothése qui tienne compte des données recueillies,
~ Identifiez une balise qui porte sur les données recueilies,
~ Prouvez ou disqualifiez votre hypothése a laide dune des stratégies de
zo-wzmzmavzoo
compréhension présentée, et
~ Répétez ce cycle autant de fois qu'il le faudra pour résoudre le probléme.
4.7 LES TECHNIQUES DE LECTURE DU LOGICIEL
Les techniques de lecture du code source précisent au mainteneur comment lire et quoi
chercher dans le code source. La lecture est une étape incontournable pour comprendre
et ensuite modifier un gc Des expériences ont été réalisées afin détablir comment
et la ion lors de la lecture du code source. Cependant
de bas niveau avant de lire le code il est nécessaire de se fixer un but précis, Ce but est il de trouver un
défaut, identifier lendroit pour y faire une amélioration fonctionnelle ou d’analyser
certaines caractéristiques du logiciel pour en améliorer sa performance ? Les expériences
Figure 4.2 Le processus de compréhension ascendant prouvent que si la technique de lecture est adaptée au but elle sera plus efficace.
La fail incipale des approch et se résumea:
~ La faiblesse reliée au manque dinclusion, dans ces approches, d'outils ; et Par exemple, siie veux de localiser une fonction spécifique pour y faire une amelioration
~ Le fait quen réalité ce mest pas si clair que la théorie propose. au début du code source et je parcours les
appels de phe qui sont liées. Pour comprendre la totalité d'un nouveau logiciel, je
débute la lecture par de petits composants (c.-a-d. procédures et objets) et je prends des
La prochaine section pré un dernier théorique de éhension du notes mentales quant a leur signification. A la lecture de plus en plus de code, qui utilise
logiciel qui modélise, d'une maniére plus réaliste, ce qui se passe en réalité lors de cette ces petits composants, limage mentale de la structure du programme se forme. Souvent,
activité. Le ps ar de mai tire lors de sa lecture d'un logiciel, il sera nécessaire de faire des retours en arriére et de relire ce qui n'était pas compris
de toutes sortes d'indices ici et la. Cette approche se nomme I'approche opportuniste. auparavant, parce quon en apprend de plus en plus sur la signification du code. Il est
important de remarquer les noms des méthodes et les valeurs de retour. Dans cette
4.6.3 L’APPROCHE OPPORTUNISTE approche il faut reprendre a un niveau élevé du code et ensuite revenir vers les détails.
Une fois qu'un modéle mental s'est développé, concernant toutes les méthodes d'une
Lors de l'utilisation de ce processus de compréhension, le mainteneur utilise autant le classe, par exemple, alors il est possible de commencer a lire comment elles sont mises
que Cette s'appuie sur trois concepts inter en ceuvre.
relié : une base de connaissances, un modéle mental et un processus d’assimilation :
~ La base de connaissances : représente expertise et les connaissances déja acquises Sile nombre de lignes de code est trop grand, il faudra alors varier la technique de lecture.
par le mainteneur et qui sont disponibles, Dans ce cas, vous pouvez commencer par identifier les composants logiques du
~ Le modéle mental : est lexpression de la compréhension actuelle concernant le programme, a un haut niveau d'abstraction. Le but est d’associer les types (c.-a-d.
programme visé parun changement, et classes) dans le code source de ces composants, puis identifier le role que chaque classe
- Le da fon © décris le utilisé afin dobtenir des joue dans cette composante. Il y aura des classes utilisées en interne dans un composant
informations, a partir de sources variées, tells que du code source et de la et des classes utilisés pour communiquer avec autres composants ou des cadriciels (c.-
documentation. a-d. Framework). Dans ce cas la technique « diviser pour régner » est utile lors de la lecture
du code source. Divisez d’abord les classes dans des groupes liés, puis concentrez-vous
Quand un mainteneur a besoin de comprendre une partie du logiciel ou un programme, sur un groupe et tentez de comprendre comment ces piéces s'emboitent entre elles. Pour
le processus d'assimilation lui permet d'obtenir de linformation spécifique. Cette vous aider dans cette tache, vous pouvez utiliser la structure du code source a titre de
information déclenche des itinéraires dans le modéle mental pour compléter sa guide. Une autre technique vise 4 lire le code des tests unitaires, sils existent, qui
documentent ce que le code source est censé faire.
compréhension pour la tache visée.
4.6.4 MOT DE LAFIN Au début de la lecture du code source d'un logiciel inconnu, il peut étre utile de prendre
des notes et méme de faire des dessins lors de lecture du code. La création d'un dessin
Afin de comprendre la source d'un probléme dans un logiciel ou Iendroit ot y faire une de larbre d'appel et de Phéritage peut aider la compréhension. Vous pouvez utiliser
et que vous ne le isez pas beaucoup, voici une recette pratique que n'importe quel outil que vous avez a portée de main, méme un tableau blanc.
jutilise : Hi les petits p et sont assez faciles a comprendre et

chaque unité fonctionne, mais il se peut qu'il soit difficile

dobtenir la vue d' pour des logiciels Effectuez une premiére lecture, Comp: ion
en diagonale, du code source, a la de patrons nventions de du logiciel
nomenclature, et styles de code. Cette technique permet d’avoir un apercu du style de
programmation des programmeurs originaux. En se déplacant dans la hiérarchie du code, 1
il est utile de noter les objets utilisés. Une autre approche utile est de trouver un point
deentrée, du point de vue de l'utilisateur du logiciel, en suivant Iexécution du point de vue Présentation | Outils |
interface utilisateur. Parcourir ou exécuter les entrées/sorties d'une interface utilisateur
et suivre le traitement, pas 4 pas, a travers le code et laccés aux bases de données est ~ Decomposition, ldentation
une activité utile pour sinitier. Probleme. Modularité Espacements
Patrons
Statiques
Dynamiques
Application Dissimulation
Systeme de information Terminologie
Dans le cas de la recherche d'un endroit pour corriger un défaut, il n'est pas nécessaire
de commencer la lecture au début du logiciel. En fait, il est trés rare qu'un mainteneur et nomenclature
prenne la peine de comprendre toute larchitecture et la ion du logiciel pour des identifiants
trouver un défaut. La premiére étape est de reproduire le défaut. Si il est possible de le
reproduire alors Insertion de traces (c.-a-d. insérer du code qui va imprimer des valeurs Figure 4.3 Taxonomie des facteurs qui influencent la compréhension d'un logiciel
de variables et des données) est souvent utile pour isoler le défaut. Une autre technique
utile de lecture ressemble plus a la lecture d'un manuel de référence. Avec ce but précis, 4.8.1 L'EXPERTISE
DU DOMAINE
il faut chercher et repérer, dans quelques endroits, une balise lice a ce défaut. II est
possible de commencer la lecture au hasard de la navigation, et au fil du temps il sera Le mainteneur devient progressivement un expert d'un logiciel et d'un domaine particulier
vite possible de devenir assez familier avec la structure et le fonctionnement du code. Si 4 la suite années de travail. Son répertoire expertise et de connaissances provient de
le défaut touche a un algorithme ou a une base de données alors le but est de comprendre son éducation et de son expérience de travail. Il a été prouvé, dans maintes expériences,
complétement ce qu'il fait & un niveau conceptuel et les données impliquées. que les experts sont plus performants que les novices. Plus un mainteneur est
expérimenté dans un domaine d’application particulier ou sur un systéme sur lequel il a
Une fois que l'endroit du défaut est identifié il est important de ne pas conclure trop vite travaillé et plus vite il effectuera une modification de qualité.
une solution sans prendre le temps de
~ Bien comprendre le probléme avant de le corriger, 4.8.2 LES QUESTIONS DE MISE EN GBUVRE DE LA PROGRAMMATION
~ Obtenir une vue d' du p et non de lendroit du défaut,
~ Confirmer le diagnostic du défaut, 1l'y a un certain nombre de problématiques de mise en eeuvre qui ont un impact sur la
comprehension du logiciel. La complexité du probleme initial qui devait étre résolu par le
~ Ne modifiez qu'une chose & la fois et ajoutez son test unitaire, et logiciel est un premier facteur. Au niveau du programme un certain nombre de questions
- Ge en des défautssi de mises en ceuvre ont un impact important sur leflicacité de la compréhension d'un
logiciel : les conventions de nom, les commentaires, la gestion de la complexité, la
Cette section a présenté les et mixtes de lecture documentation, lorganisation et la mise en page des programmes et les outils daident a
du code source. Leffcacité de ces approches dépend d'un grand nombre de facteurs de la compréhension. Les sections suivantes abordent chacune de ces problématiques.
qualité interne du code source qui seront présentés dans la prochaine section. 4.8.3 LES CONVENTIONS DE NOM
4.8 LES FACTEURS QUI ONT UN IMPACT SUR LA COMPREHENSION La pui des noms de varibles et des choisie par le développeur initial
dun logiciel est souvent négligée. La considération la plus importante dans le choix des
Un certain nombre de facteurs ont un impact sur la rapidité 4 se former un modéle mental noms de variable et de constante est que le nom décrive précisément et complétement
dun logiciel et surtout un modéle exact et complet. Ces facteurs incluent (voir la figure Tentité représentée par la variable. Ces noms doivent étre aussi spécifiques que possible.
43): Des noms comme x, temp ou i sont assez généraux pour étre employés, mais peu
~ Lexpertise du domaine, informatifs et sont & éviter. La longueur optimale pour un nom est entre dix et sei
~ Les questions de mise en ceuvre de la programmation, caractéres. Certaines méthodes de raccourci de nom sont mei que
d'autres, par exemple :
~ La documentation, ~ Utilisez des abréviations connues de tous (par exemple ceux du dictionnaire),
~ Lorganisation et la présentation du code source, et ~ Supprimez toutes les voyelles non initiales, les articles, suffixes et prépositions,
~ Les outils mis 4 la disposition des mainteneurs. ~ Utilisezla pr ou -unes des premiéres lettres de chaque mot,
~ Conserver les mots significatifs du nom, la premiere et la derniére lettre de chaque
mot, et

— Euvitez les synonymes, les noms qui contiennent des chiffres, qui sont difficiles a lire Finalement, la mise en page des commentaires est importante pour la lisibilité du code.
ou qui utilisent plus d'une langue. Evitez les abréviations dans vos commentaires. Il est important dindenter les
avec le code corr de maniére a ne pas interférer avec la
Voici quelques régles utiles de conventions de noms pour aider et accélérer la compréhension de la logique. Une autre recommandation est disoler chague
maintenance :
commentaire par une ligne vide, ce qui de de lire les
de haut en bas si on ne veut pas lire le code et seulement avoir une vue d'ensemble.
~ Lutilisation de i jet k est fréquemment utilisée pour des indices de boucles. Si une Parfois il sera plus sage de penser a restructurer du code difficile a comprendre plutét
de ces variables est utilisée a l'extérieur de la boucle, il faudra lui donner un nom que de le commenter.
plus significatif,
~ Les variables d¥états devraient étre significatives. Plutot de dire if flag = 0 dites if 4.8.5 LA GESTION DE LA COMPLEXITE
PONCTUATION = ©,
~ Les noms de variables es comme tempet x devraint étre és par des Nous avons tous une appréciation personnelle de ce qui rend un logiciel plus ou moins
noms plus descriptifs comme somme ou total, complexe. Nous avons vu que, plus le nombre d'objets mentaux que nous devons garder
~ Les noms de variables booléennes devraient signifier Iétat. Par exemple le nom a esprit simultanément pour comprendre un logiciel est grand et plus la complexité de
terminé mis a faux au début et a vrai 4 la fin d'un traitement. Un autre exemple est la tache augmente. Cette jonglerie mentale est l'un des aspects les plus difficiles de la
le nom erreur mise & vrai quand une erreur est détectée. Tentez d'utiliser des noms maintenance d'un logiciel. C'est pour cette raison que les mainteneurs n'aiment pas les
positifs d'une maniére constante dans le logiciel, interruptions brutales, car ils étaient profondément concentrés au moment de
~ Les noms de types énumérés peuvent profiter d'un préfixe pour un groupe de Vinterruption. Cela implique qu'il y a une limite a la complexité qui peut étre maitrisée.
variables. Par exemple couleur rouge, couleur bleue ; La formule de complexité de Tom McCabe effectue une évaluation en comptant les points
de décision dans un programme. Bien sir il y a aussi autres mesures telles que : le
volume de données, les niveaux d‘imbrications, le nombre de lignes de codes, la distance
Certains des ions de noms spéci Par exemple les noms entre deux références a une méme variable et bien d'autres. Ce qui est important clest
de variables et de méthodes sont en minuscules pour le premier mot, la premiére lettre avoir une stratégie pour réduire la complexité le plus possible. Au niveau de
de chacun des mots suivants étant en majuscule. Dans certains cas l'utilisation de Parchitecture logicielle, la complexité traite de la division du systéme en sous-systémes.
préfixes (c.-a-d. ch: caractére, doc: document, scr: région d'écran, sel: sélection...) Plus les sous-systémes sont indépendants et plus cela sera facile, en toute sécurité, de
permet de normaliser le type de données d'un objet ou de variable. Cette approche modifier un seul élément du logiciel 4 la fois. Des objets soigneusement définis permettent
améliore la précision dans plusieurs aspects du choix des noms. Un autre avantage de diviser les difficultés, afin que vous puissiez traiter dune seule chose Ia fois.
dutiliser les préfixes et quil devient plus facile de vérifier les types avec précision quand
on utilise des types abstraits. La décomposition est une technique qui permet de découper un logiciel en composants.
Ces composants doivent atteindre un certain nombre d'objectifs et il faudra donc faire un
4.8.4 LES COMMENTAIRES certain nombre de concessions entre les objectifs concurrents :
~ De complexité minimale : qui sont simples et faciles a comprendre,
Aujourd'hui il est utile de mettre a profit les utilitaires de documentation du code comme ~ De facilité de maintenance : qui permet de reproduire, identifier, de changer et de
Javadoc. La plupart des pi i la valeur des tester facilement un changement & un logiciel exstant,
de Les ires peuvent te classés en catégories : - De modéré : qui ise les i ions entre les classes et les
~ De répétition de code : qui redit ce que fait le code, mais avec des mots différents, méthodes a Taide de lutlisation judicicuse de principes dabstraction,
— Dexplication de code : qui explique des parties complexes, X ion et de des i
~ De marquage de code : des commentaires qui servent de repéres pour faciliter la ~ Dlextensibilité : qui permet de modifier une partie du logiciel sans affecter d'autres
recherche, parties,
~ De résumé de code : qui synthétise un certain nombre de lignes de code en une ou ~ De portabilité et réutilisabilité : qui permet d'adapter le logiciel a un autre
deux phrases pour expliquer les raisons d'un bloc de code, environnement et de réutiliser ses éléments facilement, et
— De description de l'intention de code : qui explique le probleme résolu par un bloc de ~ Du nombre d'appels : qui utilise judicieusement (c.-4-d. haut niveau de « fan-in » et
code, et faible niveau de « fan-out +) les appels entre les classes du logiciel.
~ Dinformations générales : qui documente les copyrights. Ia confidentialité, les notes Tlest donc et nécessaire de réduire la ité du logiciel a chaque occasion
de ion et les références aux de modification. Référez au livre de Steve McConnell (McConnell 2004) pour avoir plus
d'information sur la notion de conquéte de la complexité.
Pour savoir quel est le nombre optimal de commentaires, il faut se reporter 4 la littérature
qui propose qu'un commentaire doive figurer pour chaque dix instructions. Il est
é dannoter les dé de donné les de code 4.8.6 LA DOCUMENTATION
en fonction du i plutot que du les structures de controles,
les sous-| et des efforts de ion au code lui-méme. Durant la phase de maintenance d'un logiciel, il est fort possible que plusieurs éléments
de documentation aient été rédigés et soient disponibles pour les mainteneurs.
Cependant, il est probable que cette documentation ne soit pas a jour, de mauvaise

qualité, superflue, difficile d’accés ou non-standard, comme mentionné dans le point structures dans le code source des programmes. On pourra donc utiliser les mots-clés
précédent. Bien sar, dans un monde idéal, il serait recommandé de combler toutes ces des langages, par exemple « begin » et « end » (ou les accolades) pour établir les frontiéres
lacunes. Cependant, en réalité, il est concevable que ceci ne soit pas faisable da a un de blocs logiques de code source. Les lignes vides sont aussi utiles pour lier ou séparer
manque de temps, de budget, de ressources, etc. Il faudra donc corriger ces éléments ces blocs et les énoncés qui y sont regroupés. Il est donc recommandé d'insérer des lignes
selon une priorité basée sur la valeur du type de documentation. vides entre les paragraphes.
Les espaces sont aussi utilisés pour améliorer la clarté et la lisibilité des instructions. Une
‘Tel que présenté aux sections précédentes, avant d'effectuer une activité de maintenance, instruction est la plus petite unité de code source. Utilisez les espaces pour rendre les
le mainteneur devrait avoir accés au plus grand nombre dinformations concernant le logiques, les réfé de et les arguments de sous-programmes
logiciel en question. La documentation du logiciel peut étre une source importante les plus lisibles possibles.
obligations légales ; 2) appuyer les développeurs lors de leurs activités de création du La disposition des structures de contréles exige un certain souci du détail. Lindentation,
logiciel ; et, 3) communiquer les détails de la mise en ceuvre du logiciel pour Iéquipe de de son cbté, permet de faire ressortir la structure logique du code source. Cependant,
maintenance future. essayez décrire une seule instruction sur chaque ligne. Les arguments en faveur de ce
principe sont :
Lors dune enquéte auprés de soixante-seize maintencurs, effectuée en 2006, on cherchait Faire ressortir plus faci la ité du
a savoir quelle doct est plus i pour les et ce surtout ~ Facilement retrouver une erreur et dutiliser un outil de tracage et dexéution du
avec lavenue des méthodologies de développement agile (de Souza 2006). Voici les code,
résultats de cette étude, en ordre d'importance :
~ Permettre de modifier, effacer ou mettre en commentaire plus facilement, et
1) Le code source,
~ Améliorer la lisibilité, car le code peut-étre lut de bas en haut et ne nécessite pas de
2) Les cas de tests unitaires, lire gauche droite au cas ou il y aurait une ligne qui comporte plus d'une instruction.
3) Les commentaires,
4) Le document d'exigences, Finalement, la mise en page des instructions est aussi importante. Les programmeurs
5) Le document de plan de test au niveau systéme, dexpérience vous diront qu'une instruction ne devrait pas dépasser 80 4 90 caractéres.
6) Le modéle logique de données, Pourquoi ? Utiliser plus de caractéres rend plus diffcies la lecture et la compréhension.
7) Les spécifications des composants, et De plus cette limite décourage les i des structures
plus, de trop longues instructions apparaissent mal a lécran et sur les imprimés. D'autres
8) Le modéle de données physique. arguments militent en faveur de la rédaction d'une seule instruction par ligne, car :
On peut donc constater Importance de la qualité du code source, de la documentation ~ lest plus facile de repérer une erreur de syntaxe,
des tests, des ires et davoir de I ion sur le ine qui est traduit en ~ Test plus élégant lors de lexécution du code par un analyseur statique qui sarréte
exigences. La qualité de ces est d'autant plus i dans le cas ou le 4 une instruction lors des tests boite blanche.
développeur original n'est plus avec organisation. Nous savons tous quil y a une rotation
assez importante du personnel dans le domaine du logiciel et nous savons aussi que les
ars veulent gravir les & et exercer plus de ilités avec le temps.
Parfois cette documentation n'est pas tenue a jour et est méme absente. Dans ce cas, il 4.8.8 LES OUTILS MIS A LA DISPOSITION DES DEVELOPPEURS ET MAINTENEURS
faut s'en tenir a la lecture des commentaires et du code source.
Tous ces facteurs qui influencent la comprehension d'un logiciel peuvent étre remaniés a
4.8.7 L’ORGANISATION
ET LA MISE EN PAGE DES PROGRAMMES Taide d'un nombre croi d'outils rendus di: aux lly en ade
plusieurs types :
Lorganisation et la mise en page influencent aussi la facilité avec laquelle le code peut ~ Diaide a la construction et a la conception de logiciel,
étre compris, remanié et révisé. Elles affectent aussi la facilité de lecture, de ~ Danalyse de logiciel existant,
compréhension et de ion par les . Une bonne mise en place visuelle ~ De recherche et de débogage de logiciel existant,
doit démontrer la structure logique d'un logiciel dés le départ. Une bonne organisation
permet une communication efficace avec les lecteurs humains. Les objectifs d'une bonne ~ De documentation,
mise en page sont : ~ De réaménagement et restructuration de logiciel existant,
— De repré avec précision, et de maniére la structure logique du code, ~ De conversion a un autre langage.
~ Daméliorer sa lisibilité, et
— De préserver ces caractéristiques méme a la suite de modifications. Ces nombreux outils, qui sont de plus en plus intégrés aux environnements de
développement, peuvent analyser la qualité du code source, embelli, le documenter et
Les chapitres, paragraphes, phrases, espaces et tabulations font toutes parties de la méme proposer des ré et restr pour réduire la
complexité et augmenter sa lisibilité. Certains outils sont my amend poe
importants lors.
structure des textes que nous lisons depuis notre jeunesse. Raison de plus d'utiliser ces

L'évolution contrélée du logiciel 4 La compréhension d'un logiciel existant
de la maintenance des logiciels. Voici des exemples d'outils utiles pour l'aide a la
compréhension du logiciel :
~ De recherche et de débogage de logiciel, nthesizing
(Duplicates
~ De documentation,
~ Deextraction de tranches (de l'anglais « slices 4 de programme, qui sélectionnent
uniquement les instructions d'un programme affectées par un changement potentiel,
— D'analyses statiques, qui permettent la visualisation générale et des résumés d'un
contenu de programme,
~ Déanalyses dynamiques, qui permettent au mainteneur de suivre, pas a pas, le
chemin dexécution d'une variable dans les programmes,
~ Déanalyse de flux de données, qui permettent au mainteneur de suivre tous les
changements daffectations de valeurs possibles d'une variable dintérét dans un
programme sur un chemin d'exécution,
~ De références croisées, qui générent des indices de composantes du programme,
~ Dianalyse de dépendance, qui aide les mainteneurs a analyser et comprendre les
interrelations entre les éléments d'un programme,
—~ De réaménagement et de restructuration de logiciel existant, et Figure 4.4 — Exemple de proposition dalgorithmes a réutiliser avec Copilot
~ De conversion 4 un autre langage de programmation.
Voici un autre exemple. J'aimerais avoir une fonction qui me donne la date de la journée
Depuis quelques années, des outils d'aide a la programmation peuvent aider a ne pas dhier : je tape le commentaire te function tc este
insérer des problématiques dans le logiciel ce qui est bien plus intéressant que de propose tion ge rerda
chercher a redresser la situation aprés pendant la maintenance.
Ces nouveaux outils, assistés de [llntelligence Artificielle (IA), tel que
https://copilot.github.com, permettent dlassister intelligemment le
développeur/mainteneur. Lalgorithme dA utilisé dans ces outils a été entrainé sur du
code source libre provenant des référentiels de Github pour assister lors de la
programmation. Ainsi plutét que d’aller sur « stack overflow » et copier-coller un exemple
de code a réutiliser, assistant est ouvert dans IDE et propose du code 4 insérer Si je tape sur «TAB» alors ce code est inséré automatiquement.
automatiquement : voir la vidéo GitHub Copilot First Look sur i
Avec ce genre das: tant,il est aussi possible de générer des données : // create ar a
Supposons que j'aimerais concevoir une fonction qui génére un nombre aléatoire. Bien number, et las: ant me propose : const nu > 1
sir cette fonction existe déja et je pourrais la réutiliser. Putt que de chercher cette
fonction ailleurs, il est possible de rédiger le commentaire suivant dans mon IDE Si jai besoin d'un vecteur de noms : // create ary of 5 names, et lassistant me propose :
es a random er et le systéme intelligent me propose : const nat hn’, Mary’, ‘Ja Robert’, ‘Michael’. Si jai besoin d'un vecteur de
Math.floor(Math.random() * (max ) noms: // ¢ r f je wi r ! ©, et l'assistant me propose :
, si je tape sur «TAB» alors ce code est inséré automatiquement. Mais si j'aimerais
avoir d'autres exemples d’alternatives de fonctions similaires alors clest possible en
cliquant sur « Open Copilot » et il Iassistant va proposer 10 autres solutions possibles
(voir figure 4.4).
Avec des assistants intelligents, la réutilisation de composants de qualité sera rendue plus
facile. Ainsi il sera possible de prévenir les erreurs et augmenter la qualité du code.
Avec ce genre d'assistant il est aussi possible de travailler sur les données: // or
people by age et lassistant me propose :

L'évolution contrélée du logiciel 4 La compréhension d'un logiciel existant
si je tape sur «TAB» il insert cette fonction et lexécute. Pour voir le résultat je commentaire : te a basic on port 50 et le systéme me propose
tape : console.log(orderedPeople), et constate que le résultat est ordonné par age, un ensemble de lignes de code qui vont pouvoir s'exécuter. On peut voir que ce simple
11 est aussi possible de demander d'utiliser une spécification d’API JSON externe soit commentaire propose le code nécessaire.
utilisé. Par exemple si je désire insérer la spec de API Todo qui est utilisé pour une liste
de Todo, je tape le commentaire
rl for jsonpplaceh 5s et le systéme me propose: va
) > ) il ne reste qu’a lui dire
et le systéme me propose des options : la premiére option proposée irait chercher
les 10 premiers records,
Figure 4.7 — la proposition du code pour I'utilisation de express, sur un port particulier,
alaide seulement d'un commentaire
En somme les outils intelligents, comme Copilot de Github, vont étre nombreux a lavenir
pour assister les développeurs et augmenter la productivité et la qualité de leur code.
Figure 4.5 — une premiére proposition de solution Nous verrons, au chapitre 4, que les techniques et outils d'ingénierie inverse et de
réingénierie de logiciels peuvent aider le processus de travailler a rebours a partir d'un
La deuxiéme option, quand on clique sur loption Previous de Copilot offre une autre produit existant pour obtenir la documentation d’artéfacts automatiquement tels que la
option qui va aller chercher toutes les données et va les mettre dans un objet qui cation et la conception d'un logiciel e
contiens tous les champs
Figure 4.6 — une seconde proposition de solution
Donc je n'ai rien eu & programmer ici et j'ai une fonction pour obtenir les Todo's que
je pourrais ajuster un peu selon mes besoins.
~ Un dernier exemple dassistance intelligente est la demande création d'un serveur

express (pour une interface REST) sur un port particuliera laide dun seul

L'évolution contrdlée du logiciel 5 La réingénierie d'un logiciel existant
INTRODUCTION
Comme présenté au chapitre précédent, la compréhension du logiciel est nécessaire avant
deeffectuer une modification. Nous avons vu que cette étape consomme une large partie
de effort de maintenance, car souvent : il n'y a pas de documentation ou celle qui existe
est incorrecte et désuéte ; le mainteneur ne connait pas le domaine d'application du
logiciel ; et la complexité du logiciel est trés grande et sa qualité s'est grandement
détériorée au cours des années.
Une maniére d'aider a résoudre cette problématique progressivement et 4 chaque jour est
deflectuer des petites activités de réingénierie du logiciel lors de chaque requéte de
modification. Ces multitudes de petites amé internes vont gr éli
La réingénierie d’un logiciel la qualité du logiciel 4 moyen terme. Certaines techniques de réingénierie du logiciel
permettent d’appuyer le mainteneur dans cette démarche qualité.
existant 5.1.1 DES DEFINITIONS UTILES
La réingénierie du logiciel posséde sa terminologie propre. En voici quelques définitions :

Abstraction :
~ Un modéle qui fait la synthése des informations concernant un sujet a l'étude,
Dans ce chapitre, nous couvrons : Réingénierie du logiciel :
~ Les niveaux d'abstractions du logiciel, ~ Laréfection des logiciels afin de les rendre plus efficaces et économiques sans changer
~ Les buts et les objectifs de la réingénierie du logiciel, son comportement.
~ Les techniques de la réingénierie du logiciel, Rétro-ingénierie du logiciel ;
~ Lastratégie de mise en ceuvre et ses bénéfices escomptés. ~ Analyse d'un logiciel avec l'objectifde comprendre ses données, sa conception et ses
specifications ;
~ Créer des représentations d'un logiciel dans une autre forme un plus haut niveau
abstraction.
Restructurer :
~ La transformation interne d'un logiciel de sa forme initiale a une forme plus efficace.
5.2 LES NIVEAUX D’ABSTRACTION DU LOGICIEL
Une abstraction est obtenue en mettant en relief les traits importants d'un logiciel étudié.
Il y a trois types d ions princi qui inté les mai la
fonctionnalité, les données et le processus.
5.2.1 L’ABSTRACTION DES FONCTIONNALITES
Cette premiére perspective est souvent aussi nommée l'abstraction procédurale qui
signifie de préciser les fonctions d'un logiciel. Ces fonctions opérent sur les données et
ont un comportement systémique, ce qui veut dire qu'elles prennent une valeur a lentrée,
effectuent un traitement et produisent des données a la sortie. Pendant le processus
abstraction des fonctis du logiciel, le mai est intéressé par ce qui est réalisé
et la mise en ceuvre de la fonction d'un point de vue d'utilisateur.
5.2.2 L’ABSTRACTION DES DONNEES
Cette deuxiéme perspective vise les données et les objets. Le mainteneur cherche &
séparer la mise en ceuvre des objets dans des structures de données et les opérations

quelles subissent. Les données sont souvent représentées a trois niveaux d’abstractions :
conceptuel ; logique ; et, physique.
5.2.3 L’ABSTRACTION DES PROCESSUS
Cette derniére ive vise la sé exacte dexécution du logiciel. Il y a deux

classes de processus qui peuvent faire l'objet abstraction : 1) les processus concurrents
qui communiquent entre eux a l'aide d'un espace mémoire réservé ; et 2) les processus
distribués qui communiquent entre eux a laide de messages. pr —
implémentation | mooder | implémentation
5.3 LE BUTET LES OBJECTIFS DE LA REINGENIERIE DU LOGICIEL
En voulant définir la réingénierie logicielle ou rétro-ingénierie logicielle, il Savére évident

de remonter le temps pour mieux comprendre ce concept et son utilisation dans
l'industrie informatique de développement logiciel. Un des premiers cas d'utilisation Figure 5.1 Les différents niveaux d'abstractions du logiciel
pertinents de la pratique de la réingénierie remonte au 19e siécle, durant la révolution
industrielle, en Belgique, ot les entreprises ont procédé a la réingénierie de machineries Le but de la réingénierie est donc de faciliter les changements en permettant la
fabriquées en Angleterre avec I'objectif d’en fabriquer de plus performantes. Entre autres, compréhension du logiciel. L'objectif principal est de recouvrir de linformation utile & sa
Clst ce qui a permis & la Belgique, au cours du 19e siécle, de devenir la deuxiéme comprehension, obtenir mettre a jour et enrichir la documentation existante, réaménager
puissance d'Europe industrielle derriére Angleterre. Un autre exemple, en 1778, est celui la structure interne pour la rendre plus lisible et moins complexe. Voici les objectifs visés
de Samuel Slater qui a été documenté. Il travaillait dans une usine de coton, en par les techniques de réingénierie :
Angleterre. Aprés avoir passé vingt-et-une années a travailler avec les machineries de ~ Recouvrir des informations : Avec le temps le logiciel a subi des changements. La
Tépoque, il devient expert et l'unique personne qui maitrise les connaissances de la documentation n'a pas suivi ou est absente. Cela rend le code source Iunique source
technologie utilisée par ces derniéres. Il posséde un modéle mental précis des plans de d'information fiable. Les outils de rétro-ingénierie permettent de récupérer les
ces machines et, en 1789,
l'industrie du textile américaine.
s'envole vers New York ou il a révolutionné, par la suite,
informations autant pour les trois niveaux d’abstractions : fonctionnalités, données
et exécution,
~ Faciliter la conversion vers une autre plateforme : Avec le vieillissement du logiciel,
En plus du ine de la mécanique, la réingénierie devient un concept trés répandu les technologies prennent de lage et il serait souhaitable de conserver la
dans tous les autres domaines, par exemple les circuits électroniques et les circuits fonctionnalité offerte, mais sur une technologie moderne. L'utilisation d'outils de
intégrés, etc. Au tout début de Iére des ordinateurs personnels et des logiciels, la rétro-ingénierie peut aider a effectuer cette conversion
/ migration du logiciel,
réingénierie a aussi été utilisée par plusieurs entreprises afin de comprendre I'équipement ~ Améliorer et produire de la ion : Les outils de rétro-ingénierie permettent
et le logiciel développé par d'autres, d’en extraire les connaissances de sa conception et de produire de la documentation de toute sorte : des documents daide pour les
de son fonctionnement avec l'objectif de les concurrencer et de prendre une part de ces
nouveaux marchés.
rs et des pour les mai rs,
Lutilisation de la rétro-ingénierie dans le ine dulogiciel ibue a des
- fier la duplication de code : La présenc de code dupliqué est presque toujours
technologiques révolutionnaires pour les compétiteurs des grandes entreprises
due a une dela ion dés le départ. Il oblige & effectuer
des modifications paralléles,
technologiques comme IBM. Dans les années 70 a 80 et plus prés de nous, en 1990,
certains états des Etats-Unis ont méme interdit formellement la pratique de la rétro- - des ématiques dans le but de réduire leur complexité et
énierie afin d’empécher le clonage des iques de 1 des les effets secondaires quiils causent: Certaines structures causent des problémes de
semi-conducteurs. Les lois ont aussi abordé le sujet dempécher la décompilation des maintenance, par exemple: des boucles trop longues ou imbriquées trop
logiciels. profondément ; des classes qui manquent de cohésion ; une interface qui ne fournit
On peut voir, a la figure 5.1 qu'un logiciel est produit par les activités décrites par le pas un niveau d'abstraction cohérent ; un nombre trop élevé de paramétres ; des
versant droit de la figure. Ce sont les activités du cycle de vie de développement du logiciel classes, hiérarchies d'héritage, instructions ou données qui doivent étre modifiés
composé d’étapes successives : concept, besoins, conception et implémentation. Bien que parallélement et bien d'autres. Les outils de restructuration (aussi parfois nommeés «
la rétro-ingénierie (représentée par le versant gauche de la figure) puisse démarrer a + qui signifie réamé viennent a laide du mainteneur pour ces
aspects,
niimporte lequel des quatre niveaux d'abstractions, le niveau le plus populaire est
limplémentation du code source, car il représente, sans conteste, la réalité. ~ Optimiser le logiciel : Avec le temps, il est possible que le logiciel ait été modifié de
maniére 4 le rendre moins . Bien que loptimisation de la per ne
soit pas une ique de réingénierie pr dite, le mai se doit de
revoir les aspects de compilation, de matériel, doptimisation du code et de ses
structures de données réguli Les outils de restructuration et
de conversion peuvent aider avec cette problématique,

L'évolution contrélée du logiciel 5 La réingénierie d'un logiciel existant
- ifer des éutili : Nous sommes tous conscients que la 5.4.1 LES FONDEMENTS DE LA REINGENIERIE ET DE SES OUTILS
dun déja 2? et testé apporte une meilleure
Lidentification de ces est une des activités de la Avant de débuter cette section, assurez-vous d’avoir revu la section 2.4, au chapitre 2,
réingénierie, et concernant la mesure du produit logiciel. Cette revue vous permettra de rafraichir votre
— Réduire leflort de mai et la qualité du service : Cet objectifest le mémoire concernant les fondements théoriques de la mesure du produit logiciel (c.-a-d.
but ultime des r du ine de la énierie. Etant donné le code source). Les outils de réingénierie du logiciel proviennent de l'industrie des
qu'une partie importante de leffort des mainteneurs est consacré a effectuer des compilateurs et utilisent la méme approche. C'est dans ce domaine que les propositions
changements les techniques et outils de réingénierie ont un potentiel grandissant 'amé 1s d’algorit sont les plus. ées. Ce sont donc les mémes techniques
pour appuyer le mainteneur dans ses taches quotidiennes. qui sont mises en ceuvre dans un outil de réingénierie du logiciel, mais avec une finalité
Une ése des objectifs des iques de réingénierie du logiciel est présentée au différente de celle d'une compilation du code source. La figure 5.2 présente la séquence
tableau 5.1. typique d'une activité de réingénieri ée par un mai . La premiére étape est
d'avoir, de la part du mainteneur, une intention claire pour l'aider a résoudre son
probleme spécifique. Tl soumet donc le code source concerné a loutil de réingénierie qui
va, dans une premiére étape, générer un arbre syntaxique abstrait (ASA) de ce code
Tableau 5.1 Principaux objectifs des différentes techniques de réingénierie source. Clest & partir de 'ASA que le logiciel de réingénierie va créer des représentations
Objectifs intermédiaires, c'est-a-dire : des graphes et matrices de dépendances, des graphes de flux
1._Récupérer des i utiles dela de controle, des graphes de flux de données, des modéles de données et bien d'autres qui
seront raffinés, itérati en des activités de calibration et en
2. Faciliter la vers une autre Ce des couts les régles pour en arriver & des résultats satisfaisants et utiles.
3. Améloreret produire de i dela d
4. Identifierla de code de la lors
5. Identifierdes é ion de la ivité lors
et de la qualité (réduction des défauts) S—
6. Optimiserle log Satisfaction de la clientele. a existant
7. Identifier des i dela
8. Reduire leffortde et la | Compétitivité des coutset dela ciientéle
qualité de service
Flux
de contrdle (Flux
de données ) Madele
de données
Les demandes de modification et les défauts a corriger représentent donc une
opportunité de procéder a :
~ La récupération di ions de ion, d et de régles d'affaires sur ag
le logiciel,
~ La redocumentation du logiciel,
~ La restructuration du logiciel, et
~ Loptimisation du logiciel. qualité du
LHERES
calibration
-
et ‘documentation
code source objectifs de

1ly a donc ici toujours une opportunité deffectuer une petite amélioration interne qui réingénierie code.
ne devrait pas trop impacter l'effort associé a traiter une requéte individuelle. II est Source
donc souhaitable d'identifier des activités de réingénierie constamment, car des amélioré
milliers de petites améliorations peuvent faire un grand impact sur la qualité du logiciel
a plus long terme. Figure 5.2 Le fonctionnement des outils de réingénierie du logiciel
5.4 LES TECHNIQUES DE REINGENIERIE DU LOGICIEL Clest donc a partir de la littérature du domaine de la « qualité du code source » que le
i identifier des endroits problématiques et nécessiter des activités de
Nous avons vu que les techniques de réingénierie du logiciel visent a effectuer des Tr rétro-ingénierie et restr ion. Voici de types de
représentations ou transformations qui n'ont pas I'objectif de changer le comportement ‘mesure de la qualité du code source utile au mainteneur :
du logiciel, mais d'en améliorer sa maintenance. La prochaine section présente les ~ Mesures de flux de controle : Ici des mesures de bris de structure, de complexité
des iques de réingénierie du logiciel et qui sont mises en ceuvre dans cyclomatique, d'index de maintenabilité et de couverture de test sont disponibles et
les nombreux outils disponibles aujourd'hui. tirées du graphe de flux de controle d'un composant,
~ Mesures de dé : une dé e logique entre deux ou plusieurs
composants existe si elles doivent étre é é lors dun

au logiciel. Un grand nombre de mesures de dépendances sont disponibles pour : La section suivante pré plus de détails trois iques de
Tanalyse dimpact (préalable au changement), la prediction des défauts, ainsi que la la redocumentation, la rétro-ingénierie et la restructuration qui sont les plus utilisées par
mesure de la cohésin et du des du logiciel. Les informations les mainteneurs.
concernant les appels et les dépendances peuvent étre obtenues a l'aide d'outils
analyse statique du code source. Pas exemple en analysant les appels de méthode, 5.4.2 LA REDOCUMENTATION
les références de type, la structure d'héritage, les relations lors de Importation, et
des t Des peuvent aussi étre identifiées par Nous avons vu, 4 la section 3.8, les facteurs qui ont un impact sur la compréhension du
des outils danalyse dynamique qui anclysent Texécution du logiciel. Les dépendances logiciel. Un de ces facteurs est la qualité de la documentation externe et interne du logiciel.
logiques peuvent aussi étre par le mais Des recommandations concernant les conventions de nom, les commentaires, la
consultant historique des modifications du Jogicel et par analyse de Pévolution des documentation, organisation et la mise en page y ont déja été faits. Vous voudrez bien
autres artéfacts du logiciel maintenu, vous y reporter avant de continuer la lecture de cette section. Ce sont ces
~ Mesure déléments des données: il y a un grand nombre de mesures qui indiquent recommandations qui doivent étre mises en ceuvre a la suite de la découverte de
qu'il sera né e de restructurer I'utili: des et des autres types de problématiques a ce sujet.
données. Ces mesures inciteront le mainteneur a remplacer, déplacer, introduire, La red ion, aussi nommée générati ique de doct ion, vise &
convertir et méme avoir recours & encapsulation quand il y a un probleme, obtenir des repre i i mais plus riches, au
Par exemple, la manipulation répétitive d'un méme ensemble de données est candidat comportement du logiciel recherché. Il y a trois buts recherchés par la redocumentation :
au déplacement dans une classe. Certains types primitifs peuvent aussi étre 1) premiérement, créer des vues différentes du logiciel afin d’améliorer sa comprehension,
surchargés et représenter quelque chose qui devrait pluto étre restructuré en classe. par exemple en créant un graphe de flux de controle qui représente graphiquement les
Les outils peuvent aussi vous les données qui sont « différents chemins dexécution du code source; 2) deuxiémement, améliorer sa
et l'utilisation d’attributs « privés » et « publics » ou ce n'est pas souhaitable, documentation existante (interne et extern); et 3) troisiemement créer de la
Les logiciels de réi le modéle de donnée, de documentation a la suite de la modification du logiciel dans le but de faciliter la
suive pas 4 pas les les endroits de son ‘maintenance future du logiciel. Ces outils sont de deux types : 1) ils peuvent créer de la
utilisation, d’évaluer la complexité des mots utilisés pour la définir, et voir si i y a des documentation externe nouvelle, par exemple des matrices de dépendances ; et 2) ils
commentaires associés. Parfois le mainteneur devra faire sortir la longueur des peuvent améliorer la documentation interne du code source, par exemple ajouter des
variables et intervenir lui-méme pour rendre plus significatif le nom d'une variable, entétes et des commentaires commentés dans le code source. Voici quelques logiciels
car les outils ne sont pas utiles pour reconnaitre ce probleme, que jutilise per pour la red , pour n'en nommer que
~ Mesure des expressions/instructions : les outils de réingénierie mesurent la quelques-uns :
complexité d'une expression, peuvent la retravailler pour la simplifier ou la rendre ~ Javadoc : outil de génération de documentation et des gabarits de commentaires
plus performante. lls mesurent aussi sa disposition visuelle, en blocs, et propose, au (shift-alt-J dans Eclipse) pour le langage Java,
ar, des restr une lisibilité. Des logiciels spécialisés ~ SandCastle : outil de génération de documentation pourle langage C#, et
aussi de dé , déplacer, der, r des items au niveau Sphynx: outil de génération de documentation pour le langage Python.
des instructions,
Consultez la page Wikipédia : « C of + pour voir le
~ Mesures de Ia documentation : Les mesures offertes par les logiciels de réingénierie nombre isant d'outils proposés de ion du logiciel.
se concentrent sur le nombre de ires, la longueur des
Tendroit oa sont placés les commentaires, indice de brouillard (de Fanglais « FOG 5.4.3 LA RETRO-INGENIERIE (RECOUVREMENT DE LA CONCEPTION ET DES SPECIFICATIONS)
Index ») qui évalue la complexité des mots utilisés dans les commentaires et la
présence d'une indentation adéquate du code source, et La rétro-ingénierie vise & créer de la documentation, mais A un niveau plus élevé
~ Mesures de méthodes et de classes : Des mesures de cohésion de classes sont abstractions que le niveau du code source. Par exemple, obtenir un diagramme de
disponibles dans les outils. L'objectif de loutil est de rapporter au mainteneur le séquence a partir du code source d'un logiciel. Cette activité, semi-automatique, peut
nombre d'exécutions de fonctions et la relation entre elles. Si c'est un bric-a-brac, la participation active du mai ar pour ajouter des informations qui ne se
est une indication qu'elle dot tre divisée en plusieurs classes, chacune regroupant retrouvent pas & partir de analyse du code source seulement, par exemple: la
un de Le méme problem apparait quand une classe conception, la compréhension personnelle et les connaissances du domaine.
joue plusieurs roles. Les outils vous font ressortir aussi les sous-classes qui peuvent Récupération de la conception : Il est clair que la récupération d'une conception, par un
poser un probléme. outil, ne peut étre qu'une des nombreuses possibilités de la conception originale créée par
Pour les méthodes, la maintenabilité devient difficile lorsquune méthode est trop longue le développeur. Les outils peuvent proposer des représentations graphiques
ou a beaucoup de variables, étres ou Ces sont difficiles a de architecture du logiciel, de sa base de données, de ses interactions
comprendre et a réutiliser. Les outils de restructuration peuvent proposer d'extraire cette utilisateurs/logiciel et de sa conception. Certains outils peuvent enrichir la sémantique
méthode, de la remplacer par une requéte, introduire un objet paramere, préserver objet présente dans le code source, a laide de liens, dans le but d'expliquer les décisions qui
en entier, de la a Taide de condi et méme de r cette ont été prises lors de la conception originale. Certains autres outils utilisent leurs
méthode par la méthode objet. du dx pour inérer des décisions qui sont populaires
et ées pour des précis d’application (par exemple la éet

ses régles comptables). Voici quelques exemples de logiciels populaires que jutilise de ionnalités. La dé ion de la structure originale du logiciel apparait
personnellement pour effectuer la rétro-ingénierie, pour n'en nommer que quelques-uns : 4 la suite nombreuses modifications incontrolées faites au cours des années.
~ Shemaspy : pour récupérer le diagramme des données logiques & partir des bases de Manuellement, restructurer le code source dun logiciel complexe peut étre long et
données physiques ; couteux et peut méme introduire des changements indésirables ainsi que difficilement
—- Visual ligm, Eclipse Luna et StarUML: pour obtenir un diagramme de classe, un
détectables dans le comportement du systéme. Il est aussi trés difficile d’assurer que la
diagramme de séquence a partir du code source. restructuration manuelle conservera la fonctionnalité et la performance actuelle d'un
logiciel.
Récupération de spécifications Il peut étre utile de tenter de recouvrir les spécifications
a partir du code source d'un logiciel existant. Ici aussi il n'y a pas assez dinformation
dans le code source alors il va falloir recourir aux services du mainteneur pour enrichir Les émati de la restr ion du logiciel :
les informations requises a l'aide d'outils pour effectuer ce travail. Des techniques La restructuration automatique de logiciel est un souhait de l'industrie depuis longtemps,
spécialisées de logique inductive et de génération de dictionnaire de données permettent mais qui n'a pas encore de solution éprouvée qui a révolutionné le travail des
de repérer les régles daffaires qui ont été placées dans les instructions et les mainteneurs. En fait, la plupart des mainteneurs n'ont jamais utilisé un outil de
conditionnelles d'un logiciel Ce propositions peuvent ensuite étre enrichies et restructuration dans leur travail quotidien. Pourquoi ce domaine a-t-il si peu de succes ?
par un mai qui connait bien ce logiciel. Les raisons sont autant d'ordre technique, social quéconomique :
lest a i es y a des pour que la rétro-ingénierie soit = La restructuration d'un programme dépend du langage utilisé. Un outil de
bénéfique et que certaines informations d'un logiciel sont plus pertinentes que d'autres. restructuration pour un Java ne pas pour un
Lor dune étude de cas de réingénierie de lentreprise canadienne Cascades, Serge Briére Ruby. Bien que certains outils de restructuration aient une représentation
en fait Texpérience. Serge a fait la réingénierie d'un logiciel de cartes de temps utilisé par indépendante du langage de programmation et peut gérer plusieurs langues
les employés de Iusine de papier. Il a procédé en trois étapes: 1) regrouper toute différentes cela ajoute souvent a la complexité et au cout de Ioutil. Comme les langues
linformation du systéme actuel; 2) effectuer la rétro-ingénierie du code source et des changent continuellement, les outils doivent s'adapter, et cela ajoute au probleme.
bases de données du logiciel existant, et; 3) redévelopper le logiciel sur une nouvelle En outre, de nombreux logiciels comportent plus d'un langage, ce qui rend plus
plateforme moderne en utilisant ces connaissances. Afin de recouvrir la conception de ce difficile pour eux de trouver des outils de restructuration utiles et pratiques,
logiciel, qui foncti sur un envi IBM-AS400, il avait : ~ Pour étre utiles au mainteneur, les fonctions de restructuration du programme
~ Acces au code source et a la structure des fichiers, doivent étre intégrées dans son i de dé (c.-a- -d. son IDE).
~ Une connaissance du processus de pointage des cartes de temps par les employés, La restr fon étant de maniére i ive lors dune il
~ Une connaissance de lentreprise et un réseau de contacts dans l'entreprise. devient difficile utiliser des outils spécialisés pour chaque occasion. Pour étre
ps le ar veut voir les résultats d'une transformation et
Il n'avait pas acces a: étre en mesure d’annuler cette modification si elle ne permet pas une amélioration
~ La documentation externe du logiciel, nette 4 la situation. Actuellement, comme nous allons le voir a la prochaine section,
~ Un dictionnaire de données, les és de restr ibles sont tres limitées,
~ Les procédures que les utili s utilisaient pour faire foncti le logiciel, et ~ Les mainteneurs n'ont pas d'incitatif ou de formation concernant la restructuration
- Aux deorigine ni a un mai du logiciel (c.-a-d. qui n%était plus de logiciel. Ils sont souvent és sur leur ivité et évitent la restr
‘maintenu depuis plusieurs années). a cause de la pression quotidienne a résoudre un probléme ou effectuer une
modification rapidement,
Serge a donc effectué la rétro-ingénierie d'une maniére semi se (c.-a-d. avec ~ Tiny a pas beaucoup dincitation non plus du coté des développeurs d'outils. Il est
Taide doutils et en le de tous les assez difficile de faire des profits dans ce marché, car les expertises requises pour
écrans et rapports. Il a par la suite utilisé un outil pour créer des diagrammes de concevoir ces outils sont rares. Les utilisateurs s’attendent aussi que ces outils soient
séquences et des modéles de données a partir du code source et de la base de données gratuits, et
physique existante. Sa conclusion est que 48% de ses efforts ont été investis dans Iétape
de rétro-ingénierie. Il conclut en statuant que les outils ont été utiles, mais que 1) recenser ~ en dépit de la longue tradition de restructuration de logiciel dans certaines
tout le code source du systéme existant n'avait pas été trés utile ; 2) la lecture de tous les conférences académiques, il ny a encore trop peu de chercheurs intéressés par ce
rapports existants n'avait pas ét utile non plus ; et, finalement que 3) Tout de rétro- domaine. La plupart des outils de restructuration de logiciel restent propriétaires et
ingénierie des données, qu'il avait choisi, n’avait pas permis de trouver automatiquement couteux. Il ny a peu de conférences (c.-a-d. ICSM et WCRE) oul les constructeurs
toutes les relations réelles entre les données utilisées par les programmes. On peut donc outils peuvent partager les uns avec les autres et rencontrer des utilisateurs. Il ny
voir que ce domaine est encore jeune et que la rétro-ingénierie automatique n'est pas a pas vraiment de communauté de restructuration de logiciel.
encore chose facile. Les limites de la restn
Actuellement, sans avoir recours a des outils couteux et complexes (exemples) il y a dans
5.4.4 LA RESTRUCTURATION les IDE populaires (par exemple : eipse et Visual Studio sous la fonction « refactor » et
des outils sur leur marketplace) I é de faire des microrestr ions d'une
La restructuration de logiciel est une forme de maintenance perfective qui modifie la maniére automatique. Au moment d¥citre ces lignes, la version de Eclipse était la jdk8.
structure du code source d'un sans altérer sa fonctionnalité. Son objectif est Ces 3 types de trai au 11) et bouger
d'améliorer la maintenabilité afin de faciliter les activités de maintenance, telles que I'ajout une classe ; 2) restructurer le niveau d'une classe (c.-a-d. remonter on redescendre le

niveau) ; et 3) extraire des mé et les é le mai veut procédera donc a modifier un code correct pour le faire fonctionner plus efficacement a
restructurer automatiquement et obtenir : chaque occasion. Ces centaines d’améliorations, a petite échelle, ont un grand potentiel
~ Des cas de tests pour ce code source, d'amélioration de la performance du logiciel a long terme.
~ Des changements a une variable - effectuer un changement pour cacher l'accés direct
seulement avec des méthodes « getter et setter », Le principe de Pareto :
~ De la généralisation d'un type - créer des types plus généraux pour permettre un plus Dans son livre « tout sur le code » McConnell décrit que ce principe du 20-80 s'applique
grand partage de code, bien a optimisation du code. II faut donc identifier les endroits du code (et parfois de
~ Le remplacement de la vérification de code type, qui a un impact sur le comportement Tenvironnement) qui consomment le plus de ressource et créent des délais d'exécution.
dune classe, par un état dobjet,
- Le dune conditi parle pol Les optimisations a l'aidedu :
~ De briser le code en morceaux plus logiques, par exemple : Certaines légendes urbaines d'optimisation du code persitn aujourd'hui, telles
que : la
© Découper le code en unités sémantiques réutilisables qui présentent des réduction de lignes de code est une optimisation assurée. Il est souvent plus utile de se
interfaces claires, bien définies et simples a utiliser, pencher sur les options d'optimisation de compilation pour obtenir des gains de
© Extraire d'une classe existante une partie de son code et le déplacer dans performance. Par exemple certaines machines virtuelles Java sont meilleures que
d'autres.
une nouvelle classe, et
© Extraire d'une méthode existante une partie du code et le déplacer dans une
nouvelle méthode. Les sources les plus communes d'inefficacité :
— Une amélioration des noms et de I'emplacement du code : ‘Quand vous avez obtenu des efficacités avec les options du compilateur, il est maintenant
temps d'identifier le 20% d'endroits ou le code pourrait contenir des inefficacités pour
© Deéplacer une méthode ou un champ - passer a un fichier de classe ou d'une obtenir 80% des résultats escomptés. Ou alors chercher ? Les sources les plus communes
source plus appropriée, dinefficacités se trouvent, selon McConnel, dans :
© Renommez méthode ou renommer Champ - de changer le nom en une — Les opérations d'entrées/sorties et au niveau des données (optimiser les requétes
nouvelle qui révéle mieux son but, et SQL),
© Remonter ou redescendre une classe dans la hiérarchie. ~ Les opérations qui forcent une pagination interne de la mémoire par le systéme
d itati imisation de mémoire pour Java)
Les outils de restructuration : ~ Pour certains cas d'utilisation, les langages interprétés peuvent étre plus lents
Les problémes liés a la restructuration peuvent étre traités en utilisant un outil de (discussion Stackoverflow),
restr ion pour apli i certaines de ces transformations. La ~ Des algori incluant des ions réguliéres et de la récusion, et
majorité des outils de restr i i des transformations en manij des ~ Certains opérateurs, par exemple le + et iterator() en Java (discussion Stackoverflow).
représentations abstraites du logiciel telles que présentées a la figure 5.2. Un outil de
restructuration permet donc de transformer un code qui est devenu difficile a maintenir.
McConnel rapporte que ces outils peuvent aider a améliorer la productivité des Les techniqus d'optimisation rapides pour le ;
mainteneurs de 25%. Il est suggéré d'utiliser Ioutil de maniére générale, mais d'effectuer Llobjectif d'un changement au code n'étant souvent pas loptimisation, le mainteneur
des changements manuellement pour les cas difficiles de logique trés dégradée. Une autre voudra effectuer des optimisations localisées et rapides pour ne pas trop générer de travail
approche est de passer tout le code dans l'outil et ensuite le retravailler manuellement. supplémentaire pour sa requéte. Voici une liste de modifications efficaces :
Voici gi que jutilise per pour la redisposition et ~ Mettez les données en cache des données les plus utilisées (pratiques exemplaires de
la restructuration : AWS),
~ Eclipse et Visual Studio é des i ités de restr ion (sous - les i i par des r dans des
Toption » refactor » ; inimisez les réfé aux et us d' des aune
~ Featureous : pour restructurer le code source Java existant d'un logiciel et ReSharper seule dimension,
pour restructurer du code source c#. ~ Remplacer les longues recherches par des recherches justes a temps qui vont
~ Freeformatter et Code Beautify: pour redisposer et embellir la présentation du code. seulement chercher linformation requise quand ils en ont besoin. Ceci se traduit
aussi par calculez les résultats 4 I'avance,
~ Déplacez les tests a Iextérieur des boucles quand il n'est pas modifié,
5.4.5 L’'OPTIMISATION ~ Fusionnez, déroulez et économisez le travail des boucles qui travaillent sur le méme
élément de donnée,
Cette section présente les activités opportunités d'optimisation des performances du ~ Employez le type correct de constante, des entiers a la place des réels et initialisez-
logiciel lors d'une modification. Bien sur ces activités seront limitées afin de ne pas trop les 4 la compilation, et
impacter Teffort estimé pour traiter une requéte individuelle de maintenance. On ~ Verifiez bien que les appels aux fonctions systéme sont efficaces.

L'évolution contrdlée du logiciel A1 Bibliographie
En conclusion loptimisation opportuniste que le mainteneur peut effectuer rapidement

nécessite une bonne expérience préalable, varie largement en fonction des langages, des
compilateurs et des environnements. C'est quand méme une activité intéressante et peut
A1
devenir un jeu et une compétition intéressante dans une petite équipe qui cherche un
moyen de samuser tout en travaillant. Certaines entreprises donnent un prix mensuel
assigné a loptimisation la plus ingénieuse du mois. Cétait souvent un sujet de discussion
animé a la cafété
Les és de l'utilisation de i de réingénierie, a chaque requéte,

sont multiples :
Lamélioration de la qualité de fait constamment, a chaque requéte faite par les
mainteneurs,
Bibliographie
Le plan de redressement du code source est continuel, propose une approche simple
de 20%-80 et ne dérange pas les clients, ni la direction des Technologies de
VInformation, (Abran 1993) Abran, A., Nguyenkim, H. Measurement of the Maintenance Work
Cette approche comporte peu de risques, car elle ne tente pas de faire de grands Categories Through Measurement, Journal of Software Maintenance:
projets de réaménagent complexes, Research and Practice, vol. 5, no.2, 1993:63-90.
On peut présenter les valeurs successives de dette technique pour chacune des (Abran 1993a) Abran, A. Maintenance Productivity and Quality Studies: Industry
applications maintenues autant a notre direction qu’a notre clientéle d'une maniére Feedback n Benchmarking, Proceedings of the International Software
simple et structurée,
Maintenance Conference (ICSM93), Montréal, September 27-30, 1993,
p. 370.
Les mainteneurs agissent et , i la de (Abran, 2015) Abran, A. Software project estimation: The fundamentals for providing
détérioration de la qualité interne des logiciels. high quality information to decision makers, Wiley-IEEE Computer
Society, April, 6 2015, 288 pages.
(April 2000) April, A., Al-Shurougi, D. Software Product Measurement for Supplier
Evaluation. Madrid Spain, FESMA-AEMES2000 conference, October 18-
20 2000.
http://s3.amazonaws.com/publicationslist.org/data/a.april /ref-
222/583.pdf [Consulté le 24 Avril 2022].
(April 2001) April, A., Bouman, J., Abran, A., Al-Shurougi, D. Software Maintenance
in a Service Level Agreement: controlling the customer expectations,
Fourth European Conference (FESMA), Heidelberg Germany, May 2001.
(April 2002) April, A., Al-Shurougi, D. Software Maintenance Productivity, ICB/ASAY,
The role of Quality Maintenance in Cost Minimisation Conference,
Manama Bahrain, May 27-28, 2002.
(April 2016) April, A. et Abran, A., Améliorer la maintenance logicielle, 2¢ édition,
Loze-Dion,
(Bennett 2000) Bennett, K.H.: Software Maintenance: A Tutorial. Software Engineering,
Dorfman and Thayer, IEEE Computer Society Press, Los Alamitos USA,
2000, pp. 289-303.
(Boehm 1987) Boehm, B.H. Industrial Software Metrics Top 10 List, IEEE Software
Journal, IEEE Computer Society Press, Los Alamitos, CA, USA, 4(5),
September 1987:84-85.
(Boloix 1995) Boloix, G., Robillard, P. A Software System Evaluation Framework,
Computer Magazine, December 1995, p. 17-26.
(Bouman 1999) Bouman, J., Trienekens, J., Van der Zwan, M. Specification of Service
Level Agreements, Clarifying Concepts on the Basis of Practical
Research, Proceeding of the Software Technology and Engineering
Conference (STEP99), 1999.
(Card 1990) Card, D., Glass, R. Measuring Software Design Quality, Prentice Hall,
1990.

L'évolution contrdlée du logiciel Abréviations et Glossaire
PM&A - Process Measurement & Analysis/Analyse et mesure de processus GLOSSAIRE

PR - Peer Review/Revue par les pairs
PROM - Programmable Read-Only Memory/Mémoire morte programmable
DEFINITIONS
QAI - Quality Assurance Institute/Institut d'assurance de la qualité
Les définitions et les termes que l'on trouve dans ce livre ont fondé sur une terminologie
QC - Quality Control /Controle de la qualité acceptée a léchelle de toute lindustrie. Lorsqu'une définition ne peut étre trouvée dans
QE - Quality Engineering/Ingénierie de la qualité les documents précédents, d'autres sources sont utilisées. Ce n'est quen I'absence d'une
QPM - Quantitative Process Gestion itative de processus définition qu'une nouvelle définition est établie.
RM - Requéte de Modification /Modification Request
RP — Rapport de probléme;/ Problem Report des bases de + Exécution des foncti istan a définir,
SA/SD - Structured Analysis & Structured Design/ Analyse structurée & Conception organiser, gérer, controler et protéger les données dans une base de données.
structurée \ ire des es deI ion, Associati ien de sat
SE - Systéme d’exploitation/OS - Operating System Age d'un probléme : Nombre de jours entre le moment ou le billet de probleme est
enregistré a ce jour, sil est encore ouvert, ou au moment oi le billet de probleme a été
Sei - Software engineering institute/Institut de génie logiciel fermé.
SCM - Cc i /Gestion de ion de logiciel Aide et conseil 4 l'utilisateur : Une des activités de support a l'utilisateur (voir support
SDL - Specification Design L Langage de spécifications de la de deuxiéme niveau) effectué par l'unité organisati dela a
SIG - Systéme di ion de gestion /MIS - ion System aider 4 sa compréhension eta l'utilisation d'un logiciel {Isbsg2010].
SPE - Software Product Engineering/ Ingénierie du logiciel + Est une i i dun logiciel
SPP - Software Project Planning/Planification des projets logiciels Clest-a-dire est synonyme d'une requéte perfective dans ISO14764.
SPT&O - Software Project Tracking & Oversight/Suivi et surveillance des projets logiciels Amélioration mineure : (de l'anglais Minor 3 ir ou ré
une petite portion d'un logiciel applicatif existant. La ion ou le dé de
SQA - Software Quality Assurance/Assurance qualité du logiciel petits articles de logiciel diinterfaces qui exige une reconception du logiciel applicatif
SQM - Software Quality Management /Gestion de la qualité du logiciel existant. Petite (moins de 5 jours d'effort) modification 4 la documentation, au code source
SSM - Software Subcontract Management /Gestion de la sous-traitance du logiciel ou la structure des données d'un logiciel applicatif existant. S'applique aux requétes de
S/W - Software /Logiciel la maintenance qui modifie le logiciel applicatif : a) adaptives ; b) perfectives ; et c)
préventives.
SWEBOK - Engineering Body of Ki public (www.swebok
org )
Analyse d’arborescence de défaillances : Analyse permettant de déterminer les modes
TCM - Te Change ‘Gestion des
de défaillance des articles et sous-articles des événements externes ou de leurs
TI - Technologie de Information
/IT - Information Technology inaisons pouvant entrai un mode de défail stipulé de l'article présenté sous
TP - Training Program / Programme de formation la forme d'un arbre de défaillance.
V&V - Veérification et validation/ Verification & Validation Appel de service : Demande de support et de maintenance initiée en dehors de heures
normales de service. Le billet devra indiquer cette caractéristique.
Application : Voir logiciel applicatif.
Article : Piece, élément, di itil é unité i équipement ou
systéme qui peut étre pris en compte individuellement. Un article peut comprendre du
‘matériel, du logiciel ou les deux et peut aussi, dans des cas particuliers, comprendre des
personnes.
Article de configuration : Entité au sein d'une configuration satisfaisant une fonction
dutilisation finale et qui peut étre identifiée de facon unique, a un point de référence
donné (ISO/CEI JTC1/SC7 vocabulaire).
de produit : Caractéristiques non foncti du produit (par exemple :
fiabilité, portabilité, ergonomic).
Billet : de l'anglais «Ticket fait référence a : a) : une demande de support opérationnel ;
b) un rapport/requéte de modifications (RM’s) ; et ¢) un rapport/requéte de problémes
(RP's) créés dans le systéme de gestion des requétes concernant un composant des
Technologies de l'information qui est supportée par une entente de services. Une entrée
spécifique, avec un numéro unique, dans le systéme de gestion des requétes.
Cadre d’évolution : Description du chemin évolutif nécessaire pour atteindre la maturité
progressivement.

Caté : dun éme ou d'une défai Ceest-a-dire matériel d'ordinateur électronique, matériel mécanique, silicium, logiciel, documentation de l'utilisateur,
personnel, logiciel d'ordinateur personnel, matériel central, télécommunications, logiciel documentation de formation, etc.
applicatif, procédure ou régle d'affaires, acces, défaillance externe d'un édifice, mauvaise Controler : Vérifier, superviser, observer, ou enregistrer le progrés d'une activité, action
gestion de la ion, essais i au matériel ou a la ou systéme sur une base réguliére afin d'en identifier les changements d'état.
éseautique, récentau logiciel ap licatif, etc. Composant : Une des parties constituant une application, un systéme ou l'infrastructure
Ci : Ajout, retrait, i ion, r ou mise a niveau d'un article. d'un systéme. Un composant peut étre du matériel ou du logiciel et peut étre subdivisé
Capacité d'un processus : La gamme des résultats attendus pouvant étre atteints en en d'autres composants (IEEE-610.12).
utilisant un processus spécifique. Critére d’acceptation : Les critéres qu'un logiciel systéme, un composant, un produit ou
Cause : La cause (l'origine) d'un pr & ou d'une défail . C ée suite a une un produit i aire doivent sati pour étre ac eptés par un util , un
analyse. client, ou une autre entité autorisée. [L1EEE STD-610].
Caractéristiques de la maintenance du logiciel : [Abran1993) Critére de performance : Est lobjectif de temps réponse assignée a une activité, un
+ Les requétes de modifications (RM) parviennent d'une maniére plus ou moins service. Pour un logiciel applicatif, on parle plutot de temps /réponse.
aléatoire et ne peuvent étre planifiées dans un processus annuel de budgétisation ; Cout du cycle de vie : Cout global d'un produit depuis le moment ou celui-ci a été congu
«Les RM's sont évaluées et placées par ordre de priorité, par le programmeur (ou son jusquau moment ou il west plus disponible pour Itilisation.
patron), et ne font pas l'objet d’autorisation par un gestionnaire sénior ; Défaut cosmétique : Un défaut, dans un logiciel applicatif en production, pouvant étre
«La charge de travail de la maintenance n'est pas gérée par des techniques de gestion ou étant relié a la présentation des données, mais qui mest pas le résultat dune
de projets, mais plutot par l'utilisation de files d’attente supportées par un logiciel du corruption de données et qui ne présente pas une mauvaise valeur a l'utilisateur [sb03).
bureau d'aide help desk ; Par exemple : les étiquettes, les entétes ou les couleurs manquent ou ne sont pas
+ Latailleetla ité des de la mai font en sorte que le travail présentés correctement. Méme si cette situation peut étre considérée comme
de logiciel, le logiciel est complétement utilisable. Il ny a pas dimpact notable sur la
un défaut
peut généralement étre effectué par un ou deux programmers ; é de I C les 's peuvent se sentir ennuyés et
«Les travaux sont és de maniére a satisfaire lutil , a court terme, et & frustrés par le logiciel, ce qui peut causer des inefficacités [Isbsg2010-UKSMA].
sassurer du bon fonctionnement quotidien des logiciels en opération ; Défaut mineur : Un défaut ayant pour résultat une faible incidence d'interruption de son
Les priorités changent rapidement toute heure du jour. Les rapports de problémes (RP's) opération, causant par exemple, des inefficacités pour l'utilisateur. Le logiciel soufire d'un
nécessitant des corrections a lapplication de production auront la priorité sur nimporte probleme, mais est toujours opérable. Par exemple : a) les valeurs des données peuvent
quel autre travail en cours. étre mauvaises ou corrompues d'une maniére supportable, pour unere période limitée ; ou
Caractéristique qualité du logiciel : La norme 1SO25010 décrit les caractéristiques de b) quelques aspects mineurs de ité ne sont pas di du
la qualité d'un logiciel. logiciel peut avec cette petite dé ion de service fms
c a : Sapplique a la catégorisation des rapports dinci lors de Défaillance : Etat d'un article caractérisé par son incapacité a exécuter une fonction
essai d'acceptation finale effectué par les représentants de la clientele. Par exemple : requise, al dei é pendant la ou due a d'autres
Catégorie 1) Une ou une systéme qui empéche de poursuivre les mesures planifiées. Synonyme d' interruption de services ». Dans le contexte restreint de
essais d'acceptation jusqu’a ce quelle soit résolue (showstopper). Catégorie 2) Un défaut ce modéle, est le type le plus sévére de faute/panne/probléme d'un logiciel applicatif du
mineur empéchant le logiciel d'étre opérationnel, mais d'autres essais d'acceptation point de vue de la clientéle (major defect [Isbsg2010], out of service). Synonyme de
peuvent continuer. Catégorie 3) Une solution temporaire ayant été appliquée a un incident dérangement.
qui serait autrement dans la catégorie 1 ou 2. Catégorie 4) Une défaillance cosmétique Défaillance systéme : Arrét de fonctionnement d'un article ne fournissant pas son
n'empéchant pas le logiciel d’étre opérationnel, mais les utilisateurs sont ennuyés. service nécessaire complet. Une défai est un éve dans le temps. Une
5 Nouvelle exigence, une exigence manquante, une clarification d’exigence ou de régle défaillance est un état du systéme. Une défaillance peut étre due a une défaillance
affaires. physique dun élément de matériel, a la mise en eeuvre dune défaillance latente de
c: de incipaux services de la maintenance du logiciel ou d'une défail externe. Aprés une défail un article peut recouvrer
(maintenance adaptive, corrective, préventive et perfective) faisant l'objet de planification, son état et reprendre le service nécessaire aprés une interruption, recommencer a
de suivi, de controle et de mesure individuels. Cette catégorisation est régie par la norme fonctionner partiellement et continuer a fournir une partie de ses fonctions nécessaires
1SO14764 et sert de dela des services de la du (défaillance dégradée), ou il peut rester en panne (défaillance compléte) jusqu’a ce que
logiciel. Cette normalisation aide dans lexercice d’étalonnage externe des organisations celle-ci soit solutionnée.
de la maintenance du logiciel. de : Une documentée de lutil et qui posséde une
Catégorie de processus : est un regroupement dans un ensemble de pratiques clés priorité. Une améli ou une modification au logiciel aplictf qui est
sadressant au méme domaine général d'activités. Est synonyme de : a) domaine de sur un billet et est créée par un employé de la maintenance, 4 la suite d'un appel ou
processus ; b) itinéraires des processus ; et ¢) ‘secteurs-clés dans les modeles [5098 part9, acheminée a la maintenance du logiciel via le bureau d'aide. Une demande formelle de
Sei2018] changement & quelque aspect d'un article en production. [IBM]
Co-ingénierie : Activités, techniques et processus d'ingénierie et de gestion facilitant le Déploiement : Etape finale du cycle de vie du développement ou de lacquisition de
codéveloppement de sous-systémes de différentes natures, par exemple matériel logiciels. Est réalisée de maniére controlée et fait la promotion du logiciel, d'un état de
a un état de pr ion. Le logiciel est opérationnel a la suite du

Le de ion d'un vers lenvi de Environnement de production : La copie du logiciel applicatif opérationnel, le matériel
production. utilisé par la clientéle quotidiennement et sous controle des changements. On parle ici de
Dérangement : voir défaillance. Tenvironnement controlé oti on ne peut pas modifier, sans controle, par crainte de générer
Développement : Toutes les activités exécutées pour créer, tester et mettre en production un impact immédiat sur la clientéle.
un logiciel. Il est effectué par un développeur. Essai fonctionnel : L'essai fonctionnel de chacune des caractéristiques de systéme est
Développeur : Employé de l'unité organisationnelle du développement ou d'un sous- fait a Faide d’au moins une spécification de test. Le test a pour objectif d'effectuer la
traitant, qui développe ou procure un logiciel applicatif daprés les besoins des vérification du caractére fonctionnel du systéme.
utilisateurs. Le développeur peut étre interne ou externe a lorganisation. Dans le cas ou Essais de réception : synonyme d'essai d'acceptation utilisateur. Essais formels, surtout
le développeur maintient aussi le logiciel, il pourra étre la méme personne. fonctionnels, effectués pour déterminer si un logiciel/systéme satisfait ou non les critéres
d’acceptation et pour permettre au client de déterminer sil accepte ou non le
Disponibilité : Le ratio du nombre de défai par heure d'une ap lication qui logiciel /systéme (IEEE 610). A la suite du succés de cet essai, le logiciel est prét a étre
apparait a lentente de services. Exprimée en pourcentage mensuel par exemple : ‘mis en production.
Disposition : Action entreprise pour ré un éme ou une Essai d’ : Lessai di ion est le test ique final d'un logiciel avant
«Availability: The percentage of down times of a system/sub system. It sa mise en production. Cet essai est effectué a la suite de la mise en production finale du
is calculated accourding to the below formula:
logiciel et s'assure du bon foncti érati auprés des utilisateurs,
No of days in the month * 24 hrs - Total Outage Times 100% Essais d’inté : Lessai d'intégration est le test ique final d'un logiciel avant
No of days in the month * 24 hrs Vessai de réception par Tilisateur. Le but est d'efectuer les essais complets du nouveau
Documentation : Signifie que les renseignements sont enregistrés sur un support logiciel /systéme, y compris les interfa les données converties, les
matériel ou électronique. Ils sont organisés, structurés et gardés a jour, de telle sorte données et les utilisateurs interfacés documentation. Ceci est un test compréhensif de
quiils sont utilisables et facilement accessibles au public ou aux utilisateurs prévus dans tous les élé dans envi de ion, avec les cycles de tests qui suivent
le cadre de la gestion de configuration [Camélia). des transactions fonctionnelles a travers tout le logiciel /systéme. A la suite du succes de
cet essai, I'étape suivante est lessai de réception.
Effort : (en heures) le nombre dheures consacrées une tache. Essai de la performance : Cet essai vise a vérifier et valider la capacité et le temps
Equivalent Plein Temps (EPT): (de l'anglais Full Time Equivalent (FTE). Est la réponse des transactions fonctionnelles, du matériel, du réseau de télécommunication et
représentation de la taille d'une équipe en fonction de l'effort. Est un calcul du nombre des acces aux bases de données. On utilise des volumes de transactions, la complexité,
de ressources impliquées, et ol les ressources ont participé a temps partiel, ils sont la fréquence et les traitements par lots qui ressemblent aux volumes de production qui
seulement comptés pour la partie oti ont travaillé. Par exemple trois ressources a temps seront subis par les utilisateurs. Le test dexécution confirme que le matériel et le logiciel
plein (3) plus une ressource qui a travaillé deux jours dans une semaine de cing jours (4) peuvent controler suffisamment les volumes de production et les traitements par lots qui
donne un EPT de 3+.4 = 3.4 (Isbsg2010]. seront exigés en Les aux du matériel,
Elément : Une des parties constituant un systéme. Un élément peut étre du matériel ou des réseaux ou de la base de données seront identifiés dans cet essai.
du logiciel et peut étre réparti en d'autres éléments (IEEE-610). Synonyme de composant. Essai de Lessai de ion vérifie la fonctionnalité de Iappli ala
Entente de service : de l'anglais Service Level Agreement est un document approuvé par suite d'un changement identifié par un rapport dincident ou de changement. Ce test doit
la clientéle oi les services, niveaux de services et détails de lentente de la maintenance étre exécuté a la suite d'une petite amélioration ou une corr 1, pour que
du logiciel applicatif sont décrits. ces) n'a pas deffet i On vérifie, par exemple, qu'on
Environnement de développement : Ensemble doutils automatisés, de dispositifs na pas : a) introduit un probléme au flux deta logique et du controle des fonctions
+ et du matériel né pour ir Veffort initial de du existantes ; b) introduit une erreur computationnelle ; ¢) introduit une erreur a la
logiciel 1 est & noter que les outils automatisés ne sont pas limités aux compilateurs, présentation ou la navigation.
liens, s de Essai de systéme: Le but de lessai de systéme est de sassurer que toutes les
émulateurs, outils de test, outils de documentation et systémes de gestion des bases de conversions de données, les interfaces et la fonctionnalité sintégrent ensemble et
données [Sel01). On parle ici d'un endroit oi on peut créer des données et effectuer des fonctionnent tel que spécifiées. Lobjectif est de s'assurer que le systeme fait ce que le
jeux dlessais sans affecter qui que ce soit. Cest l'environnement, sur la plateforme de client veut qu'il fasse. L'accent de cet essai est de découvrir des défauts et des défaillances
développement, réservé et géré par le développeur, pour effectuer son travail. et de les réparer rapidement. Cet essai comprend l'essai fonctionnel (incluant toutes les
de : Ensemble doutils isés, de interfaces), l'essai de la performance, Iessai de réception et d'installation. Certains essais
dispositifs « firmware » et du matériel nécessaire pour ir Veffort de modification et sont effectués dans l'environnement de développement, avec des jeux de données limités
dévolution d'un logiciel opérationnel. Cet environnement permet de copier des (créés pour cet essai) et autres, dans lenvironnement de production avec les données
programmes et des données de l'environnement de production afin de simuler un réelles, pour évaluer la ité avec les spéci et
probléme ou simuler Impact d'un changement. Cet environnement permet de simuler (a succés de cet essai (comportant plusieurs facettes) méne a un logiciel opérationnel. [IEEE
moins grande échelle) tout le comportement de l'environnement de production. On parle STD 610.12].
ici dun endroit indépendant de celui du développeur et des opérations. Cest Evaluation de la capacité : Processus de comparaison de la capacité d'une entreprise avec
Tenvironnement réservé et géré par le mainteneur pour effectuer son travail. un ensemble de critéres pour déterminer, analyser et quantifier les points forts, les points
faibles et, en particulier, les risques. L'évaluation de la capacité est principalement utilisée

en approvisionnement dans la sélection des fournisseurs, mais elle est aussi d'usage Groupe de formation : Ensemble de dela ination et de
interne au sein d'un organisation (ISO/CEI JTC1 SC7 N944R) Torganisation (quelquefois d'approvisionner les fonds) des activités de formation dans un
Evaluation de processus : Examen discipliné des processus et procédés utilisés par une organisation. En général, cette unité organisationnelle, prépare et dispense la plupart des
organisation pour déterminer la capacité de ces processus a fonctionner dans les objectifs cours de et l'utilisation d'autres outils de ion (Sei2018].
de qualité, couts et temps. Son but est de caractériser les pratiques courantes, de Heures de service : Le nombre d'heures, dans un mois, qu'un article ou un composant
déterminer les points forts et les points faibles et la capacité du processus a controler ou le logiciel ap licatif) doit étre opération el et satisfait les critéres de performance
a éviter les causes importantes de piétres performances de qualité, de cout et d’échéancier identifiés a 'entente de services.
(ISO/CEI JTC1 SC7 N944R). Incident : Est le nom donné a une défaillance ou un défaut pendant les essais dun
Evaluation de produit: Examen d'un produit, produit intermédiaire ou logiciel logiciel en développement. Un incident n'a pas dimpact sur l'utilisateur, car le logiciel est
permettant d’établir son statut en fonction d'une norme ou d'un objectif établi, connu et encore en développement.
accepté. Par exemple [Isbsg2010] pour la documentation, on décrit trois catégories de Indicateur/Mesure : Valeur numérique assignée 4 un attribut.
une é ion de la ion : bas : ne fournit pas Information exigée, Infrastructure : Fais référence au matériel et logiciels utilisés par toute la communauté
moyen : fournit la plupart de l'information exigée, haut : fournit facilement l'information des utilisateurs. Peut-étre aussi décrite comme les salles d'ordinateurs contenant tous les
exigée sans difficulté.
équipements, leurs logiciels, cables et équipements de télécommunications, incluant les
Evénement : Un événement, sil nest pas résolu, conduira le mainteneur a léchec de ordinateurs et imprimantes.
Tatteinte de ses objectifs de niveau de service et, possiblement, causera des plaintes sur : Infrastructure liée aux processus: (de l'anglais Process Assets) Des composants
a) la lenteur a traiter une requéte spécifique ou ; b) la dégradation d'une caractéristique dinfrastructure supportant les processus de la maintenance du logiciel. Par exemple : a)
qualité du logiciel en production. des directives; b) mesures; descriptions; d) gabarits;
: Condition el devant étre satisfaite par un syseme (150 2382- e) produits et produits intermédiaires exemplaires ; f) critéres de personnalisation des
20:1991). Synonyme de besoins de uti qui sont les atri éet processus ; g) base de données des processus de la maintenance ; h) outils de support
de produits nécessaires a l'utilisateur du logiciel. Dans ce cas, ce sont les attributs de aux processus et i) bibliothe de sur les Infrastructure pouvant
fonctionnalité et de produits que l'utilisateur a documentés. étre développée ou achetée afin d'aider les employés de la maintenance a atteindre leurs
Facteur de compression dessai : Rapport du temps dexécution nécessaire a la phase objectifs opérationnels [Sei2018].
sur le temps d’exécuti ire a la phase d'essai pour couvrir tous Infrastructure et exploitation : Toutes les activités exécutées pour opérer l'ensemble
les états d'entrée possibles d'un programme. des produits informatiques dans l'environnement prévu et lui permettre d’accomplir les
Faute : Défaillance dans le matériel ou dans tout autre composant : par exemple, un fonctions prévues (IEEE std 610.12).
court-circuit ou un fil brisé. Une étape du JCL incorrecte, un processus, ou une donnée Immature : Une organisation est dite immature si ses méthodes/routines sont
incorrecte dans un logiciel. [[EEE STD 610.12]. généralement improvisées par son personnel et sa direction. Les organisations de ce type
FMECA : Méthode qualitative d’analyse de fiabilité mettant en jeu des modes de sont réactives et gérent les situations au moment présent. Il y a donc des surprises qui
défaillance et une analyse des effets, ainsi que la considération de la probabilité de leur ‘menacent les délais de production ou la qualité du produit. Ces organisations reposent
occurrence et d'un classement de la gravité des défaillances. souvent sur des efforts individuels qui concentrent et limitent les connaissances
+ Activité ou d’activités ayant un but Une fonction nécessaires pour effectuer ou gérer les travaux. «Lorsque la production repose sur la
peut étre réalisée par une personne ou plusieurs personnes, ou elle peut faire partie de disponibilité de personnes spécifiques, organisation n'établit aucun fondement
la tache compléte dune personne. permettant 'amélioration généralisée a long terme de la productivité et de la qualité
[Sei2018]s.
Formation : La formation est donnée pour rendre une personne compétente au moyen
de cours spécialisés et d'expériences pratiques. Cette formation peut inclure la fois des /Co : Les activités, techniques et processus
moyens formels et informels, permettant le transfert des compétences aux membres de dingénierie et de gestion minimisant le tempsde dé et éché (temps de
Torganisation [CMMi]. cycle) d'un produit. Ceci est réalisé par optimisation de la simultanéité dans la
Gestion des : Exécution des i i a spécifier, acquérir, fournir performance des taches de développement de produit (par exemple : specifications,
conception, code, etc), la minimisation de la communication
poet maintenirSi lesast
données d'une bereisation. (D'aprés
deo le ire des ies de interorganisationnelle/fonctionnelle a aide d'équipes 4 fonctions multiples, etc.
Gestion de la configuration : Est un processus de gestion du domaine du génie logicicl de et processus dingénierie et
ayant pour objet didentifier les logiciels a controler, leur de gestion optimisant la capacité d'utilisation d'un produit (par exemple : minimisation
configuration tout au long du cycle de vie du logiciel (15012207 et ISO10007). de la ion de lutili 2 isation des erreurs posible de l'opé 3
optimisation de la durée nécessaire pour exécuter la plupart des fonctions utilisées).
Gestion de la qualité : Toutes les activités de la fonction de gestion globale qui dapprovi externe des biens matériels ou des services
déterminent la politique, les objectifs et les responsabilités de qualité, qui les mettent en au lieu de les assurer par les propres moyens de organisation.
ceuvre par des moyens tels que la planification de la qualité, le controle de la qualité,
I: de la qualité et l'amélioration de la qualité, au sein du systéme qualité. La Logiciel : (dans le contexte de ce modéle, seule la perspective du logiciel applicatif est
gestion de la qualité est du domaine de responsabilité de tous les niveaux de gestion, mais utilisée) Un de de données, de procédés, de regles, de
elle doit étre motivée par la haute direction. Sa mise en ceuvre nécessite la participation documentation et de matériaux le I
de tous les membres de lentreprise. et d'un systéme i ique (CSA Q396).

Maintenance : Toutes les activités exécutées pour corriger un produit, I'améliorer, Milliers de lignes de code (KSLOC) : Afin de faire le calcul du nombre de lignes de code
Vadapter et supporter son utlisation (15012207). source, le code source du logiciel est défini comme suit : toute instruction de programme
: Une des caté i des services offerts lors de dlordinateur créée par une ressource, ou des procédés, dans un format lisible a la
Tévolution_continue dun logiciel aprés sa mise en production pour ajouter des ‘machine. Ce code source sera utilisé avec les préprocesseurs, les compilateurs et les
pour lutilisation du logiciel (IS014764). assembleurs. Ce calcul exclut les instructions de commentaire et le code source créé par
Maintenance évolution continue (du logiciel) : « La totalité des activités requises pour un logiciel utilitaire (automatique et non modifié). Le calcul inclut les déclarations de
procurer un support, au meilleur cout possible, d'un logiciel. Certaines activités débutent controle, les déclarations de format et les déclarations de données.
avant la livraison en production du logiciel, donc pendant sa conception initiale, mais la Modéle de la maturité des processus du logiciel : Une représentation des attributs clés
majorité des activités ont lieu aprés sa livraison finale » (léquipe de développement ayant dunités organisationnelles choisies, ayant un effet sur leur progression vers la pleine
terminé son travail et étant souvent affecté a d’autres travaux)” SWEBOK. Té de leur et de leur
: Une des catégories principales des services offerts par Iunité Objectif : Réfere 4 une mesure de processus ou d'un logiciel applicatif. La valeur
de la mai La modification (ou répation) réactive d'un logiciel numérique associée a un but.
exécuté aprés la mise en production d'un logiciel pour corriger des problémes découverts tion : Ministére, compagnie, société, firme, entreprise ou institution ou partie
par sa clientéle, de celle-ci, a responsabilité limitée ou d'un autre statut, de droit public ou privé, ayant sa
propre structure fonctionnelle et administrative (ISO8402).
+ Une des caté ipales des services offerts par Iunité Panne : Défaillance complete.
de la mai La modification d'un logiciel exécutée aprés sa mise Patch: C a un logiciel opérati effectué sans suivre le processus
en production et qui vise 4 maintenir le logiciel utilisable dans un environnement normalisé de lingénierie d'évolution. Ce changement est effectué rapidement, en
technique modifié ou changé ou en cours d%évolution. Par exemple lorsque le systéme contournant les procédures en place, en vue de rétablir le service rapidement. On fait ce
exploitation est mis A niveau, type de changement avec l'ntention de revenir plus tard, effectuer le travail correctement.
Maintenance d'urgence : Unc modification non planifiée effectuée pour maintenir Souvent, a cause de la nature du travail et des priorités, les employés ny reviennent pas
un logiciel en dleffectuer une maintenance et le logiciel devient : a) de moins en moins documenté ; b) de plus en plus complexe et )
corrective par la suite. de moins en moins structure.
: Une des caté inci des services offerts lors de Performance d'un processus : Les résultats observables de l'utilisation d'un processus
Vévolution continuelle dun logiciel. La modification d'un logiciel, aprés sa mise en spécifique.
pour sa son (par exemple sa Plateforme : La combinaison du matériel électronique, logiciel technique (systéme
performance) ou sa maintenance (par exemple sa maintenabilité) ou d'autres attributs dlopérations, systéme de gestion des bases de données, logiciels de télécommunication,
qualité. middleware) et des logiciels applicatifs requis pour offrir la fonctionnalité requise par la
: Une des caté principales des services offerts lors de clientéle. Une plateforme opére plus d'un logiciel applicatif.
Tévolution continuelle d'un logiciel. La modification d'un logiciel aprés sa mise en Point de référence : (traduction du terme « baselines] Niveau de départ de la performance
production pour détecter et corriger les défauts latents avant quils ne deviennent des et de la qualité d'un processus ou dun produit ayant fait Lobjet dune revue formelle et
défaillances d'un accord, qui sert de base a I'é du et a son dé
Mainteneur: Employé de léquipe de développement agile ou de lunité complémentaire et qui ne peut étre modifié que par des procédures formelles de controle
deentretien/maintenance/support qui s'assure que le logiciel applicatif fonctionne bien, des modifications (IEEE 610). Est le résultat d'un échantillonnage du comportement d'un
effectue la résolution de problémes en production et satisfait les besoins d’évolution et de processus ou d'un logiciel pendant une période fixe. Il permet la collecte de données
ques et des utili Dans le cas ou le dé fait aussi représentatives de son comportement normal a un temps donné. On cherche a trouver
évolution continue du logiciel, il pourra étre la méme personne. les données des points minimums, maximums, moyenne et écart type qui sont
Mature : Une organisation est dite « mature » quand les méthodes/routines sont bien représentatifs. Pour étre valide, le point de référence doit étre accepté par les intervenants
définies et communiquées aux employés. On dira donc que les routines mises en place comme étant représentatif de la réalité.
sont opérationnelles. Pratiques clés : «Les activités qui contribuent le plus dans un processus» [Sei2018].
Maturité d'un processus: Létendue a laquelle un processus spécifique est défini Primordial : Est dit d'une ressource. Tout logiciel opérationnel est maintenu et supporté
explicitement géré, mesuré, controlé et efficace. par une équipe d’au moins deux és. Un des deux est primordial et l'autre
Méthode : Un ensemble de régles et d*étapes de travail permettant de réaliser une tache fait la reléve. La resource primordiale est considérée comme Iexperte de la maintenance
du logiciel applicatif. Elle supervise la ressource de reléve et est ultimement responsable
répétitive, en gardant le méme niveau de performance et de qualité. Synonyme du terme du bon opérationnel du logiciel if en production.
routine, modéles de comportement prévisibles, observables dans les sociétés. Allant des
procédures techniques bien définies a des politiques et des stratégies d'affaires plus Priorité : Le rang donné 4 un probléme ou une requéte (de modification ou de support
générales. opérationnel) qui détermine & quel moment elle sera assignée a une ressource. Sapplique
Méthode de mesure de la taille d'un logiciel : Technique utilisée pour déterminer la aussi aux incidents : le rang donné a un rapport dincident, pendant les essais
taille d'un logiciel (par exemple : points de fonctions {IFPUG, NESMA, MKII, COSMIC}, dacceptation du logiciel, par exemple : Priorité 1 : A serious problem that makes further
Feature Points, nombre de lignes de code exprimées en KSLOC) [Isbsg2010]. testing / work impossible until it is resolved (showstopper). Priorité 2 : A significant error
prevents the system from being operational but other tests / work can continue. Priorité

3 :A workaround has been provided for a problem that would otherwise be in category 1 or déduction ou la logique floue sont ajoutées aux observations sur lapplication pour
2. Priorité 4 : A minor issue that does not prevent the system from being operational but identifier des abstractions descriptives de haut niveau au-dela de celles obtenues
may inconvenience users. dir en exami ication elle-mé
ouvert : Requéte/Rapport de défai ou de probléme qui n'est pas encore La ion est la création ou la révision d'une
solutionné. Le billet du bureau d'aide est «ouverts tant qu'une solution n'est pas trouvée. i tout en demeurant au méme niveau
Procédure : Une description écrite des actions, étape par étape, pour effectuer une tache a ‘abstraction. La représentation en résultant est considérée comme des vues alternatives
spécifique [IEEE-STD-610]. destinées a une personne. Lobjectif est de récupérer la documentation existante d'une
Processus : Ensemble de moyens, dactivités, de taches liés qui transforment des application ou qui aurait di exister. Les outils généralement utilisés pour réaliser la
redocumentation sont : des logiciels de représentation (qui impriment les informations
éléments entrants en éléments sortants. Ces moyens peuvent inclure les personnes, les d'une maniére logique), les de et les de listes a
les é les et les mé (ISO 8402). Une séquence références croisées.
d'activités effectuées dans un but établi. Suite d’activités, de méthodes et de pratiques
utilisées pour produire quelque chose, pour atteindre un but ou un objectif spécifique. Réingénierie : Les articles sont I'examen et la modification d'une application pour la
logiciel : Un dactivités, iques clés et reconstituer sous une nouvelle forme et limplantation subséquente de cette nouvelle
utilisées par les individus pour développer et maintenir le logiciel et les produits dérivés forme. Larticle comprend généralement une certaine forme de rétro-ingénierie (pour
de sa fabrication. obtenir une description plus abstraite) suivie d'une certaine forme dingénierie ou de
restructuration. Ceci peut comprendre des modifications par rapport 4 de
Processus organisationnels : eux sont offerts l'ensemble de lentreprise. Il est question besoins non satisfaits par application originale.
ici des activités de formation générale, infrastructure, d'amélioration des processus et Reléve : Est dit d'une Tout logiciel ionel est mai et supporté par
de la gestion [IS012207]. une équipe d’au moins deux employés. Un des deux employés est primordial (le
Processus primaires : Les processus primaires contiennent les activités d’acquisition, de responsable de la maintenance du logiciel) et l'autre fait la reléve. Cette approche assure
développement et d'opération du logiciel [[s012207]. quien cas de non-disponibilité il y a toujours une ressource compétente et informée qui
Processus de support : portent sur la documentation, la gestion de la configuration, peut prendre la reléve.
I: e qualité, la verification et la vali la revue, laudit et, finalement, la utilisateur : é dul final. Un échantillon choisi
résolution de problémes du logiciel. [5012207] util s finaux repé la ion totale d'util s finaux.
Produit : Résultat d'activités ou de processus. Le terme produit inclut le service, le Requéte : synonyme dintervention [Isbsg2010]. Demande de service de toutes sores,
matériel, les produits issus de processus continus ou une combinaison de ceux-ci (ISO alunite dela du logiciel.
8402)
de : (Rm) de rapport de modi estune
Produit intermédiaire : Un bien livrable qui est produit pendant une des phases du de service, provenant d'un utili de type if ot le logiciel applicatif devra subir
de déy oude i du produit, i un intrant d'une une i pour réps ala Est ée une priorité.
phase ultérieure, mais qui n'est pas fourni a l'utilisateur. Comme exemple de produit Requéte de probléme : (Rp) synonyme de rapport de problémes. Est une demande de
intermédiaire, citons la des la de le service de type correctif possédant la priorité la plus élevée. Les employés de la
rapport d'essai, etc.
‘maintenance vont interrompre le travail en cours et Sattaquer aux problémes en priorité.
: Un probléme en production (dé apparait lorsque quelque chose ne Requéte de support utilisateur : Est une demande de service provenant d'un utilisateur
fonctionne pas comme spécifié (ou tel qu'il fonctionne habituellement) et entendu avec la
clientéle. Lorsqu'un service ou un composant n'offre pas le niveau de service couramment ou dun groupe interface (développeurs, bureau d'aide, sous-traitant, infrastructure et
observé ou spécifiquement entendu dans lentente de services. de type i if out le logiciel aplictf ne devra pas subir de modification
pour répondre a la demande.
Probléme fermé : Un probleme solutionné, ayant fait lobjet de confirmation par la Requéte de support de : Est une de service é des
personne qui a soulevé le probléme. Le probléme est fermé lorsque le billet de probléme développeurs ou des sous-traitants concernant une nouvelle application, qui parviendra
est fermé dans le systéme de gestion des requétes. 4 l'unité organisationnelle de la maintenance dans le futur.
de ila qui est act re du bon Responsable de D'évolution/maintenance d'un logiciel : Est lemployé de lunité
et de Iévolution d'un logiciel if opérati organisationnelle de la maintenance du logiciel responsable des activités de la
d'un : la dans l'unité organisationnelle de la ‘maintenance d'un logiciel spécifique. Cette ressource s'assure que le travail effectué par
‘maintenance, responsable denquéter ou de solutionner un probléme documenté sur un les employés ne met pas en péril la qualité ou le niveau de service d'une application. Cette
billet de probleme encore ouvert. ressource est senior et a le dernier mot sur les modifications planifiées au logiciel sous sa
Rapport d'incident: Un document décrivant un incident. Ce rapport identifie responsabilité.
uniquement incident. Pendant lexécution du test d'acceptation, les résultats de Iessai Restructuration : La restructuration est la ion d'une forme de
sont rapportés dans un outil de suivi des problémes (comme Jira). L'objectif de cette tache a une autre, tout en demeurant au méme niveau u relatif d'abstraction et tout en préservant
est de produire un dossier complet des défauts et défaillances, de leur cause, des solutions le comportement externe de I’
et impacts dans le code source, des régles d'affaires, des données et de la documentation.
Rétro-ingénierie : C'est Ie processus d'analyse d'une application existante pour identifier
de la © Le reco nt de la i est un sous- ses et leurs interrelations et créer des de I ion sous
de la rétro-ingénierie on la i du ine, I externe, la une autre forme ou a un niveau plus élevé d’abstraction. On peut appliquer la rétro-

ingénierie a partir de nimporte quel niveau d’abstraction ou de nimporte quelle étape du : Une des catégories princi de services offerts par lunité
cycle de vie. La rétro-ingénierie, a elle seule, ne permet pas de changer lapplication organisationnelle de la maintenance. Certaines requétes ne nécessitent pas de
existante ou d’en créer une nouvelle. C'est un processus d'examen, non un processus de ‘modifications au logiciel. Dans ce modele, on appelle le «support opérationnels celui qui
ou de copie. Deux ines de la rétro-ingénierie qui sont trés souvent consiste a répondre & des questions, fournir des informations et conscils, assister la
cités sont la ion et le r dela i clientéle pour mieux le logiciel, une ion ou la.
Solution : Dans ce texte, solution est synonyme de résolution. Référe a la résolution d'un Systéme : Un ensemble de composants organisé pour réaliser une fonction particuliére
pr ou d'une défai Laction ou le é afin de corriger ouun de fonctis (IEEE 610). Un intégré consiste en un ou plusieurs
ou prévenir un probléme ou une défaillance. Une fois la solution approuvée et effectuée, processus, matériels, logiciels, i é i ives et personnes
le probleme ou la défaillance sont résolus et le logiciel applicatif est opérationnel a fournissant une capacité a satisfaire un besoin prévu ou un objectif (IS012207).
nouveau. Systéme de gestion des requétes : Il s'agit du logiciel qui sert de dépot de données
Solution de premier niveau : Une solution 4 un probleme déja identifié et qui posséde enregistre ct controle les rapports de modifications (RM's) et les rapports de problémes
une solution documentée et éprouvee. Ces solutions sont trés efficaces pour les groupes (RP) traités par lunité i de la mai du logiciel. La du
de support en premiére ligne, car ces i peuvent client est traduite sous forme de billet qui peut facilement étre acheminé aux différents
S'adresser & tout client qui rapporte un probleme spécifique. intervenants du support des Technologies de linformation. Ce sont des logiciels
Spécification : Un document qui spécifie, d'une facon compléte, précise et vérifiable, les commerciaux (par exemple: Vantive, IncidentMonitor, c-Support, ServiceWise,
exigences, la conception, le comportement ou les autres caractéristiques d'un systéme ou Revelation, Ibehelpdesk, Heat, TrakIT, HelpTrack, Harmony, TechExcel et beaucoup
de composants et souvent les procédés pour déterminer si ces dispositions ont été autres) et ils sont opérés par I'unité organisationnelle du bureau d'aide et des groupes
respectées (IEEE 610). infrastructure et opérations.
a : Di ion décrivant l'accord et le comportement d'une Tableau de commande de la configuration : traduit de anglais « Configuration Control
interface entre deux logiciels ifs. Ce ique définit les condits et Board » est un comité, initié par le mainteneur, qui supervise le processus du changement
les conséquences de cet interface [Isbsg2010]. d'un logiciel opérationnel. Ce groupe de travail traitera les défaillances de la maniére
suivante, par exemple :
Statut d'un probléme : Etape, du cycle de vie d'un probleme spécifique a un moment
donné. Par exemple : Ouvert - pas assigné, ouvert ~ assigné, mais non étudié, ouvert — Tache : est une activité, un ensemble dactivités ou pratiques clés faisant partie d'un
assigné et étudié, ferme. processus.
Super utilisateur : Est le nom donné a la personne d'une unité organisationnelle de la Taille d'un logiciel : voir : Méthode de mesure de la taille d'un logiciel
clientele assignée au support dun logiciel applicatif. Aussi appelé « support méthodes » Temps dinterruption (en heures) Le nombre dheures observées du point de vue de la
ou « processus d'affaires ». lientéle, ot ap lication n'est pas disponible (voirDi e1
de pr iveau : L'unité organisati qui regoit I'appel, le rapport de Temps réponse : (en secondes) Est le temps que prend une transaction de processus
modification (RMS), le rapport de problémes (RP's) initiale d'un utilisateur de logiciel d'affaires (ou un panneau d'information affiché sur écran cathodique) afin de rafraichir
applicatif. Le bureau d'aide et le « Super utilisateur » font partie de ce type d'organisation T'information a la suite de la requéte de l'utilisateur. Le temps réponse est associé a une
de support. Dans certaines organisations, le gestionnaire de programme ou un employé application spécifique et a son infrastructure. Le temps réponse doit étre évalué du point
de la maintenance est directement contacté. A ce titre il devient le support de premier de vue de la clientele. Un mauvais temps réponse est confirmé quand on peut le
niveau pour cette communication avec lutilisateur. A Ia suite de son examen, le premier reproduire dans une période de temps. Un mauvais temps réponse sera plus bas que la
niveau de support fait la ou le billet de pr limite inférieure identifiée par le critére de performance d'une application spécifique de
Support de deuxiéme niveau : Quand l'organisation posséde une organisation en aval Tentente de services.
de la maintenance du logiciel, on dira que le deuxiéme niveau de support a la cliente est ‘Tracabilité : Capacité de retracer | i 1% lication ou Ie d'une entité
T'unité organisationnelle de la maintenance du logiciel. Les services de support sont : a) (par exemple: produit, activité, processus, organisation, personne) au moyen
Taide et le conseil a l'utilisateur; b) les réponses aux questions uniques (one time) des identifications enregistrées. Voir Gestion de la configuration
utilisateurs, développeurs ou infrastructure et opérations et c) les services rapides tels Transition de logiciel : Séquence dictions controlées et coordonnées ol le
que les extractions uniques (one time query or extrac). On différencie le support des autres développement de logiciel passe de Tor le initial
activités, car il ne requiert pas la if du logiciel du logiciel vers I Topération/mai du logiciel [Sel01].
[Isbsg2010]. Validation : Processus d'évaluation d'un systéme ou de ses éléments pendant le
Support de troisiéme niveau : Dans ce modele, il représente les groupes d'assistance processus de développement, de la maintenance, ou 4 la fin de celui-ci pour déterminer
technique aux infrastructures des Technologies de l'information (station de travail, sil respecte Ieles exigences spécifiées (IEEE 610).
cablage, logiciels de base de données et de déterminer si oui ou non le produit d'une phase
dexploitation). donnée du cycle de développement du logiciel respecte les exigences établies pendant la
Support externe : de l'anglais « Third-Party Support». Sous-traitant possédant une phase antérieure (IEEE 610).
entente de services sur loffre expertise, le support et la maintenance d'un logicicl Version : Une nouvelle version d'un logiciel applicatif. Une version posséde un ou
Lunité de linfrastructure et des opérations fait
aussi appel a ce genre de support souvent spécifique a chaque fournisseur. plusieurs requétes (ou changements) perceptibles ou non par la clientéle.

Agilité

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Agilité

Transféré par

Droits d'auteur :

Formats disponibles

L'évolution contrdlée du logiciel 1 L'évolution contrdlée et I'agilité

© Edition Smart, Montréal, 30 aout 2023

©2023 Edition Smart, 2023 - Tous droits réservés 3

- télécharger ou distribuer toute partie du matériel sous licence ou fournir des

© 2023 Edition Smart, 2023 - Tous droits réservés 5

une des i de la réingénierie du logiciel peut étre utile pour extraire

Chapitre 1: Lévolution controlée du logiciel

Chapitre 2 : Les connaissances fondamentales en évolution du logiciel

Chapitre 3 : Les problématiques d’évolution continue du logiciel

Chapitre 4 : La compréhension d'un logiciel existant

Chapitre 5 : La réingénierie d'un logiciel existant

6 © 2023 Edition Smart, 2023 - Tous droits réservés 7

1.2 MODELE DE CYCLE DE VIE AGILE

© 2023 Edition Smart, 2023 - Tous droits réservés 9

Vérifier 1.2.1 LES APPROCHES AGILES

10 ©2023 Edition Smart, 2023 - Tous droits réservés 11

©2023 Edition Smart, 2023 - Tous droits réservés 13

1.2.4 LE DEMARRAGE D'UN NOUVEAU PROJET (LTERATION ZERO)

©2023 Edition Smart, 2023 - Tous droits réservés 15

En somme, cette étape de planification consiste a formaliser la vision du produit

1.2.5LA REUNION DE PLANIFICATION D'ITERATION

Une itération est lancée. Au cours de litération, l'équipe se concentre sur

16 ©2023 Edition Smart, 2023 - Tous droits réservés 17

©2023 Edition Smart, 2023 - Tous droits réservés 19

1.3 QUELLE ORGANISATION EFFECTUE L EVOLUTION CONTROLEE DU

Les aspects organisati éci identifier quelle isation ou quelle

20 ©2023 Edition Smart, 2023 - Tous droits réservés 21

logiciels, un processus plus formel et controle de transition du logiciel développé, une

22 ©2023 Edition Smart, 2023 - Tous droits réservés 23

24 ©2023 Edition Smart, 2023 - Tous droits réservés 25

26 ©2023 Edition Smart, 2023 - Tous droits réservés 27

~ assurez-vous que les activités de tests, lintégration et les déploi sont

28 ©2023 Edition Smart, 2023 - Tous droits réservés 29

Tableau 1.1- Les grandes différences entre I'agile et le DevOps

30 © 2023 Edition Smart, 2023 - Tous droits réservés 31

complétement testés sinon ils seront retournés au développeur.

(gestion de la configuration logicielle) et de déploiement de logiciels améliorent

sc de surveiller le comportemen ié du logiciel et des sous-

32 © 2023 Edition Smart, 2023 - Tous droits réservés 33

la confiance, ce qui finalement améliore le moral de équipe ». Un autre développeur a

La seconde pratique qui a été améliorée par l'utilisation de i agiles

34 © 2023 Edition Smart, 2023 - Tous droits réservés 35

36 ©2023 Edition Smart, 2023 - Tous droits réservés 37

automatisée a l'aide d'un outil comme SONAQUBE. Différents projets utilisent

Concernant la stabilité de la Parfois, la mai devient

38 © 2023 Edition Smart, 2023 - Tous droits réservés 39

40 © 2023 Edition Smart, 2023 - Tous droits réservés 41

2.2 LA DEFINITION D’EVOLUTION DU LOGICIEL

42 ©2023 Edition Smart, 2023 - Tous droits réservés 43

Quen est-il des é entre la i et le dé du logiciel ? Le

En effet, un certain nombre des activités de la maintenance sont similaires a celles du

44 ©2023 Edition Smart, 2023 - Tous droits réservés 45

6 ©2023 Edition Smart, 2023 - Tous droits réservés 47

a8 ©2023 Edition Smart, 2023 - Tous droits réservés 49

50 © 2023 Edition Smart, 2023 - Tous droits réservés 51

de mé jes du dé ne é méme pas létape de la Processus de Maintenance Logicielle

52 © 2023 Edition Smart, 2023 - Tous droits réservés 53

Finalement, au plus haut niveau, organisation de maintenance devra réaliser des

54 © 2023 Edition Smart, 2023 - Tous droits réservés 55

1. Le responsable de l'incident, qui est souvent la personne en support qui réagit en

maintenance (tel que vu a la section précédente). Avec l'avénement des outils de

56 ©2023 Edition Smart, 2023 - Tous droits réservés 57

2.5.3 LA GESTION DES VERSIONS DU LOGICIEL EN EVOLUTION/MAINTENANCE CONTINUE

Ainsi I'équipe et les développeurs/mainteneurs doivent décider des éléments (c.-a-d.