rapport de projet personnel - publications list
TRANSCRIPT
ÉCOLE DE TECHNOLOGIE SUPÉRIEURE
UNIVERSITÉ DU QUÉBEC
RAPPORT DE PROJET PERSONNEL CMMI ET LA MAINTENANCE LOGICIEL
Faites une comparaison des activités contenues dans le CMMI et celles trouvées dans l’exercice2. Le CMMI stipule qu’il couvre la maintenance du logiciel. Expliquez le point de vue du CMMI envers la
maintenance du logiciel et ce qui manque pour une couverture plus complète.
PAR
MUKAYISENGA BEN DEDALE STELLA
PRÉSENTÉ À : Alain April
MGL804 – Réalisation et maintenance de logiciels
MONTRÉAL, LE 20/05/2016
1
TABLE DES MATIÈRES Résumé ........................................................................................................................................... 2
I. Introduction ............................................................................................................................ 3
1. Le contexte de la maintenance du logiciel ....................................................................... 3
1.1 Définition de la Maintenance du logiciel ..................................................................... 3
1.2 Processus de la Maintenance du logiciel ...................................................................... 4
1.3 Les activités de la maintenance du logiciel .................................................................. 5
II. Vue d’ensemble de modèle de maturité en génie logiciel ................................................... 6
2. Présentation de modèle de maturité ................................................................................. 6
2.1 CMMI comme modèle de maturité .............................................................................. 7
2.2 Niveaux de maturité du CMMI .................................................................................... 7
3. CMMI et la maintenance du logiciel ................................................................................ 8
3.1 Identification des domaines de processus ..................................................................... 8
3.2 Activité de la maintenance selon CMMI ...................................................................... 9
3.3 Récapitulatif des pratiques de la maintenance et les observations ............................. 15
3.4 Comparaison des activités de la maintenance et celles du CMMI ............................. 18
III. Recommandation ................................................................................................................. 19
IV. Conclusion ............................................................................................................................ 21
V. Références ............................................................................................................................. 21
Listes des tableaux
Tableau 1 : Les activités uniques à la maintenance…….................................................................5
Tableau 2 : Niveau de maturité……................................................................................................7
Tableau 3 : Les domaines de processus selon CMMI……..............................................................9
Tableau 4 : Observation de pratique de la CMMI……………….................................................15
Tableau 5 : Comparaison des activités de la maintenance et celles du CMMI…..........................18
2
Résumé Au fil du développement logiciel et de la concurrence qui entraîne la recherche de la qualité totale
pour un coût le plus réduit possible, la maintenance est devenue une des fonctions stratégiques de
l’entreprise. Les activités de la maintenance, qui garantissent le bon fonctionnement des outils de
production, ont ainsi pris une importance non négligeable dans la bonne marche des entreprises.
Cependant des questions se laissent poser comme : faut-il se fier à ces activités sans donc un
référentiel ou un modèle de bonnes pratiques ? Est-ce que ce modèle de référentiel couvre-t-il
toutes les activités de la maintenance ?
Ainsi, dans une première partie, nous commencerons par définir le concept de maintenance, puis
nous passerons en revue aux différentes activités de maintenance, nous ressortirons les activités
uniques de cette dernière. Nous verrons alors que la maintenance est devenue un des facteurs
majeurs de la maîtrise des produits logiciel et qu’elle a désormais un rôle préventif dans le maintien
de l’état de bon fonctionnement d’un système logiciel. Pour assurer ce rôle, il est évident de
disposer d’informations sur comment évaluer des différentes bonnes pratiques de la maintenance.
C’est pourquoi la seconde partie sera consacrée à la modélisation. Une vue d’ensemble de modèle
de maturité sera traitée dans cette partie, nous verrons le CMMI, son origine et ses niveaux de
maturité. Nous allons vérifier si vraiment le CMMI traite adéquatement les activités de la
maintenance du logiciel.
Pour finir, nous sensibiliserons le lecteur à tenir compte des recommandations ressorties de la
seconde partie de ce travail de session avant de choisir le CMMI comme une couverture totale qui
traite les activités spécifiques à la maintenance.
3
I. Introduction
Dans un contexte économique en constante évolution, la concurrence oblige l’industriel à
améliorer le rendement de ses installations de production pour répondre aux besoins de ses clients.
De par son action directe sur les équipements de production, la maintenance est devenue un levier
de performance incontournable qui conditionne les résultats d’une organisation. Même si les coûts
des actions de maintenance ne sont pas négligeables, ceux liés aux arrêts de production ont un
impact encore plus fort sur la production, les produits ou services proposés par l’entreprise et donc
sur les clients. Pour satisfaire la demande en qualité et en quantité, tout en respectant les délais de
livraison et les coûts, l’entreprise doit disposer d’un outil de production fiable, et donc d’une
stratégie des bonnes pratiques de maintenance adaptée.
Dans le secteur d’activité informatique, le CMMI stipule qu’il couvre les bonnes pratiques de
maintenance du logiciel, d’où l’objectif de ce travail est d’affirmer ce fait, en faisant une
comparaison des activités contenues dans le CMMI et celles qui sont spécifiques à la maintenance
du logiciel. Et finalement fournir une recommandation s’il y’a celles qui manquent à CMMI pour
une couverture plus complète de maintenance du logiciel.
1. Le contexte de la maintenance du logiciel
1.1 Définition de la Maintenance du logiciel
Vu que plusieurs définitions de maintenance ont été acceptées et présentées, notre travail va
couvrir que deux d’entre eux qui sont :
Définition selon FIPS [1]:
« Activités requises pour garder un système logiciel opérationnel après son acceptation
et sa mise en production »
Définition selon SWEBOK [2]:
“software maintenance is defined as the totality of activities required to provide cost-
effective support to software. Activities are performed during the predelivery stage as
well as during the post-delivery stage.”
Ces deux définitions ont été choisies, car elles coïncident avec la portée de ce travail qui consiste
à montrer les activités requises pour garder un système en état fonctionnel après son acceptation.
Et si nécessaire apporter une amélioration à partir de modèle de bonnes pratiques.
4
1.2 Processus de la Maintenance du logiciel
Comme vu ci-dessus dans la définition, les activités requises pour garder un système en état
fonctionnel après son acceptation ont eu les impacts épouvantables pouvant découler de leur
mauvais fonctionnement dans certaines situations critiques. Ces impacts épouvantables ont permis
l’évolution rapide des processus à suivre. Dans le domaine de la maintenance, ces processus sont
mentionnés dans » IEEE Standard for Software Maintenance » [10] et contient l’ensemble des
procédures pour la gestion et l’exécution des activités de la maintenance logiciel. Bien que ces
standards existent, nombreuses sont les entreprises qui ne travaillent pas encore avec un processus
de gestion de maintenance bien défini [3]. Et pourtant un mainteneur ou un ingénieur logiciel est
complètement responsable d’appliquer ces pratiques saines lors de l’élaboration, de la gestion et
de la maintenance des projets à petite échelle aussi bien que dans des projets à grande échelle où
la sécurité du public est d’une importance primordiale. Ces pratiques (processus) sont au nombre
de six entre autres :
L’implémentation ;
L’analyse et la résolution de problèmes ;
La modification du logiciel ;
L’acceptation de la modification par le demandeur ;
La migration ;
Et finalement, la mise à la retraite.
Chacun de ces processus comprend un ensemble des activités qui peuvent être elles-mêmes
regroupées en quatre grandes catégories qui sont :
La maintenance corrective : un système logiciel peut ne pas répondre correctement aux
spécifications demandées en générant des erreurs dues à la mauvaise fonctionnalité du
système. C’est dans cette catégorie où nous trouverons l’effort et les activités de
maintenance nécessaire à la fixation des erreurs d’un système logiciel.
La maintenance adaptative : Contrairement à la maintenance corrective, la maintenance
adaptative regroupe les activités et l’effort fourni pour fixer les changements de
l’environnement dans lequel un système logiciel doit fonctionner. Cela peut être dû à
l’évolution de nouvelles technologies et le design des nouveaux formats ;
La maintenance perfective : quant à elle, est toute modification subit par un système
logiciel afin de lui apporter une amélioration. Toutes les activités (changements)
5
incluses dans cette catégorie dépendent du degré d’efficacité par lequel un utilisateur
veut satisfaire ses besoins.
Maintenance préventive : Cette quatrième catégorie a été ajoutée récemment en 2000
parts [4], car il était important de prévenir une défaillance avant de générer une rupture
complète du système. Dans la maintenance préventive, nous trouverons donc toutes les
activités et efforts nécessaires effectués après livraison pour en détecter et corriger les
défauts latents avant qu’ils ne se manifestent.
1.3 Les activités de la maintenance du logiciel
Malgré que ces activités soient regroupées dans les quatre grandes catégories citez ci-haut, ils ne
sont pas tous uniques à la maintenance. Certaines d’entre elles appartiennent au processus de
développement d’un logiciel. Dans cette partie nous allons montrer que les activités uniques à la
maintenance. [5]
Tableau 1 : Les activités uniques à la maintenance
Catégories Activités uniques à la maintenance
Corrective Faire une étude de différents types de
requêtes de changement supporté par un
centre d’appel help desk et son logiciel
de support ;
Faire la gestion des priorités de demande
de modifications ;
Faire la gestion des requêtes de
changements et de demandes de
modifications ;
Faire le test de régression
Adaptative Gestion de l’interface et du rôle portant
sur la gestion du changement ;
Préventive Faire une mise en entente de service
(SLA) ;
Faire une interception et surveillance des
applications en production afin de
prévenir les problèmes ;
Faire un contrôle des applications en
production ;
Fournir une mesure d’indicateur de
service spécifique aux activités du
support de la maintenance ;
Faire la gestion de la sous-traitance des
contrats de maintenance ;
6
Faire la gestion de la transition du
développement au groupe de
maintenance ;
Faire une analyse d’impact d’un
changement ;
Perfective Activités d’évaluation d’impact d’un
changement
Processus unique d’acceptation et de
rejet du travail pour les requêtes de
modification des logiciels opérationnels
selon leur talle
Rendre le portefeuille d’application plus
performant (gestion du logiciel)
Support opérationnel Apporter un soutien à la clientèle
concernant une panne, une maintenance
préventive et un retour en service après
panne ;
Faire la gestion des employés de la
maintenance ;
Faire la gestion et le plan annuel de la
maintenance
Investigations et réponses aux questions
concernant les règles d’affaires des
systèmes opérationnels
Bien que ces activités soient uniques à la maintenance et classées dans des catégories
différentes, nous pouvons trouver une activité qui peut réapparaître dans plus qu’une catégorie.
Par exemple, un mainteneur peut faire l’activité d’évaluation d’impact d’un changement dans
le but de perfectionner son système, ou pour corriger les erreurs qui peuvent subvenir après
changement.
II. Vue d’ensemble de modèle de maturité en génie logiciel
2. Présentation de modèle de maturité
Les activités montrées ci-haut doivent être mises en pratique dans l’industrie du génie logiciel et
en particulier dans la maintenance logicielle. Or dans ce secteur d’activité, nous faisons face aux
situations où les mêmes pratiques sont exécutées pour améliorer la qualité, mais tous n’obtiennent
pas nécessairement les mêmes résultats.
7
Pour pallier le problème les organismes de normalisation invitent à ces secteurs de s’améliorer en
se référant au modèle de bonnes pratiques (modèle de maturité) ou en créant leurs propres modèles.
Cependant il existe ainsi de très nombreux modèles dérivés de [2], mais peu, sont entièrement
consacrés à la maintenance logicielle.
2.1 CMMI comme modèle de maturité
Présenté par le SEI (Software Engineering Institute) dans les années 80, le CMMI est une extension
du modèle CMM (Capability Maturity Model). Celui-ci, à la demande du ministère américain de
la Défense (DOD), il a été élaboré comme un référentiel d’évaluation de la capacité à gérer et
terminer un projet correctement bien sûr de la part du fournisseur. Il propose un bon nombre de
bonnes pratiques liées au développement et à la maintenance des produits qui s’articule autour de
domaines de processus cibles [9]. Par contre le CMMI s’applique mal aux activités continues de
type de production, exploitation et même les activités d’opérations à moins que ces dernières
aient :
Une date de début et date de fin cible ;
Un budget ;
Une équipe pour la durée du projet gérée par un chef de projet ;
Un projet ciblé sur la livraison d’un produit ;
Un client cible duquel partent les exigences à respecter pour le produit à livrer ;
Un cycle de vie avec des phases établies pour toute la durée du développement.
2.2 Niveaux de maturité du CMMI
Les bonnes pratiques du CMMI sont rassemblées en 22 domaines de processus eux-mêmes
regroupés en 5 niveaux de maturité [6] :
Tableau 2 : Niveau de maturité
Niveaux Description
1 : initial Pas de corrélation entre les données de projet attendues et les données de
projet réelles ;
Pas de formalisation des processus et pas de partage ;
Seule la capacité des personnes clés dans l’organisation fait la différence.
2 : Reproductible Les données réelles ne concordent pas forcément avec les données
attendues, mais il existe une certaine prédictibilité, car il y’a une définition
de la gestion des projets élémentaire pour assurer le suivi des coûts, des
délais et de la fonctionnalité du projet.
Domaines de processus :
• Planification du projet
• Suivi et contrôle de projet
• Gestion des ententes avec les fournisseurs
• Gestion de configuration
8
• Mesure et analyse
• Assurance qualité processus et produit
3 : Défini Le processus logiciel standard de l’organisation s’attend à ce que le
processus logiciel des activités de gestion et d’ingénierie soit documenté,
normalisé et intégré.
Domaines de processus :
• Focalisation processus organisationnels
• Définition processus organisationnels
• Formation organisationnelle
• Gestion de projet intégrée
• Gestion du risque
• Développement des exigences
• Solution technique
• Intégration des produits
• Vérification
• Validation
• Analyse et prise de décision
4 : Maîtrisé (Géré
quantitativement)
Le processus logiciel est compris et contrôlé quantitativement. La gestion
quantitative permet de rendre les projets totalement prédictifs.
Domaines de processus
• Performance processus.
• Gestion de projet quantitative
5 : Optimisation Le processus de développement de l’organisation fonctionne de façon
anticipée donnant la possibilité de se concentrer sur son amélioration
permanente.
Domaines de processus
• Innovation et déploiement organisationnels
• Analyse causale et résolution
3. CMMI et la maintenance du logiciel
3.1 Identification des domaines de processus
Pour interpréter les bonnes pratiques, il importe de considérer le contexte global dans lequel elles
seront employées et de déterminer dans quelle mesure elles satisferont aux objectifs voulus. Dans
notre contexte, CMMI propose une série de bonnes pratiques pour couvrir ou améliorer la séquence
des activités liées à la maintenance, le tableau ci-dessous nous montre les classements des
processus selon CMMI et leur niveau de maturité. Nous avons ainsi catégorisé par couleur ces
processus en quatre domaines entre autres : Gestion de processus, Gestion de projet, Ingénierie et
Support pour pouvoir identifier les domaines qui couvre les bonnes pratiques de la maintenance.
9
Tableau 3 : Les domaines de processus selon CMMI
Les domaines de processus selon CMMI Niveaux de
maturité
Analyse causale et résolution 5
Gestion de configuration 2
Analyse et prise de décision 3
Gestion de projet intégrée 3
Mesure et analyse 2
Innovation et déploiement organisationnels 5
Définition du processus organisationnel 3
Focalisation sur le processus organisationnel 3
Performance du processus organisationnel 4
Formation organisationnelle 3
Intégration de produit 3
Surveillance et contrôle de projet 2
Planification de projet 2
Assurance-qualité processus et produits 2
Gestion de projet quantitative 4
Développement des exigences 3
Gestion des exigences 2
Gestion des risques 3
Gestion des accords avec les fournisseurs 2
Solution technique 3
Validation 3
Vérification 3
3.2 Activité de la maintenance selon CMMI
Selon [7], les domaines de processus suivants traitent explicitement la maintenance des logiciels :
La gestion de configuration,
La gestion de projet intégrée,
L’innovation et le déploiement organisationnel,
L’intégration du produit,
La gestion des exigences,
Le développement des exigences,
La gestion des risques,
La gestion des accords avec le fournisseur,
Solution technique,
La validation,
10
Et la vérification.
3.2.1 La gestion de configuration
« Le domaine de processus Gestion de configuration comprend les activités suivantes :
Identifier les éléments critiques comme un baseline de configuration dans un temps
donné
Contrôler les modifications des éléments de configuration ;
Informer les membres du comité de contrôle des règles à suivre afin de construire des
produits à partir du système de gestion de configuration ;
Maintenir l’intégrité des référentiels (baseline) ;
Faire la mise à jour du plan de gestion de configuration et le fournir aux développeurs,
aux utilisateurs finaux et aux clients. »
Les pratiques de la maintenance dans la gestion de la configuration impliquent ce qui suit :
« P1. Maintenir l’intégrité des baseline »
« La gestion de configuration devrait capter suffisamment d’informations pour identifier et
maintenir les éléments de configuration même après que les développeurs l’ayant mise en place
ne sont plus. » (Chrissis et al. 2007, P.191)
« P2. Base de données des demandes de changement »
« Les demandes de modification concernent non seulement les besoins nouveaux ou modifiés,
mais aussi les défaillances et les défauts des produits. Les demandes de modification sont
analysées, stockées et contrôlées afin de déterminer l’impact que le changement aura sur le
produit, travaux connexes, budget et calendrier. » (Chrissis et al. 2007, P.198)
3.2.2 La gestion de projet intégrée
« Gestion de projet intégré comprend les activités suivantes :
L’établissement défini de processus de projet au démarrage du projet ;
Gestion du projet à l’aide de processus de projet défini ;
Établir l’environnement de travail pour le projet en se basant sur les normes
d’environnement de travail ;
Établir des équipes qui sont chargées d’accomplir les objectifs du projet ;
Permettre aux parties prenantes à être identifiés, considéré, et, lorsque cela est approprié,
adressée au cours du projet ;
11
Veiller à ce que les parties prenantes concernées (1) accomplissent leur tâche d’une
manière coordonnée et au moment opportun ; (2) adresse les exigences du projet, plans,
objectifs, problèmes et risques ; (3) remplissent leurs engagements ; et (4) identifient,
suivent et résous les problèmes de coordination. »
Les pratiques de la maintenance dans la gestion de projet intégré impliquent ce qui suit :
« P1. Recruter des personnes pour la maintenance et le support.
P2. Former des personnes à la maintenance et au support.
P3. Sous-traiter la maintenance et le support
P4. Former des utilisateurs experts dans les outils sélectionnés »
« Le processus de projets définis doit comprendre tous les processus d’ensemble de
l’organisation nécessaires pour acquérir ou développer et maintenir le produit. Le produit lié aux
processus du cycle de vie, tel que les procédés de fabrication et de soutien sont développés
simultanément avec le produit. » (Chrissis et al., 2007, P. 224)
3.2.3 L’innovation et le déploiement organisationnel
Ce domaine de processus a les objectifs des processus de performance parmi ceux :
« Le développement ou la production plus courte pour ajouter, modifier de nouvelles
fonctionnalités ou s’adapter à de nouvelles technologies » (Chrissis et al. 2007, P.273)
« Réduire le temps de s’adapter aux nouvelles technologies et aux besoins d’affaires » (Chrissis
et al. 2007, P.273)
3.2.4 L’intégration du produit
« La gestion des interfaces comprend la maintenance de la cohérence des interfaces tout au long
de la vie du produit, la résolution des conflits, la non-conformité et les enjeux liés au
changement. » (Chrissis et al. 2007, P.375)
« Les pratiques de la maintenance dans l’intégration du produit impliquent ce qui suit :
P1. S’assurer de la compatibilité des interfaces tout au long de la vie du produit.
P2. Résoudre les problèmes de conflits, de non-conformités et de changements.
P3. Maintenir un référentiel afin que les données d’interface soient accessibles à ceux qui
participent au projet. » (Chrissis et al. 2007, P.377)
12
3.2.5 La gestion des exigences
« Dans le cas d’un projet qui se concentre sur les activités de maintenance, les mêmes
déclarations dans ce domaine de processus sont comme celles du développement des exigences.
(Chrissis et al 2007, P.488 »
objectif spécifique 1 :
« Le projet maintient un ensemble d’exigences actuel et approuvé pendant la durée du projet
en faisant :
• Gestion des changements aux exigences,
• Entretenir les relations entre les exigences, les plans de projet, les produits concernés,
• Identifier les incohérences entre les exigences, les plans de projet et les produits concernés,
• Prendre des mesures correctives » (Chrissis et al. 2007, P.492)
Pratique spécifique à la maintenance :
« Maintenir la traçabilité bidirectionnelle entre les exigences et les produits concernés ».
(Chrissis et al. 2007, P.492)
3.2.6 Le développement des exigences
« Dans le cas d’un projet qui se concentre sur les activités de maintenance, les modifications du
produit ou les composants produits sont basés sur les modifications des exigences existantes, la
conception et la mise en œuvre. Les changements d’exigences, le cas échéant, pourraient figurer
dans les demandes de changement du client ou des utilisateurs ou il peut prendre la forme de
nouvelles exigences provenant du processus de développement d’exigences. Indépendamment
du leur, source ou la forme, les activités de maintenance qui sont entraînées par des changements
aux exigences sont gérées en conséquence. » (Chrissis et al. 2007, P.465)
Pratique spécifique à la maintenance :
« Établir et maintenir le produit et les exigences d’un composant du produit, qui sont basés sur
les exigences des clients. » (Chrissis et al. 2007, P.471)
« La modification des exigences due aux changements des exigences approuvés est couverte par
la maintenance de cette pratique spécifique ; considérant que, l’administration des changements
de besoins est couverte par le processus de gestion des exigences ». (Chrissis et al. 2007, P.472)
13
3.2.7 La gestion des risques
« La préparation est réalisée en établissant et en maintenant une stratégie pour identifier,
analyser et atténuer les risques. » (Chrissis et al. 2007, P.500)
Pratique spécifique à la maintenance :
« Identifier des sources de risques, catégoriser les risques, et fournir les paramètres
servant à délimiter, à évaluer et à contrôler les risques pour pouvoir les gérer
efficacement. »
3.2.8 La gestion des accords avec le fournisseur
« Le domaine de processus de gestion de l’entente fournisseur implique ce qui suit :
• Établir et maintenir des ententes avec des fournisseurs » (Chrissis et al. 2007, s.519)
« Pour réduire les risques pour le projet, ce domaine peut aussi porter sur l’acquisition
d’importantes des produits et des composants du produit non livré au client, mais utilisé pour
développer et maintenir le produit ou le service ». (Chrissis et al. 2007, P.520)
Pratique spécifique à la maintenance :
« Établir et maintenir des accords officiels avec le fournisseur. » (Chrissis et al. 2007, P.524)
« Identifier les responsabilités du fournisseur pour la maintenance et le support des produits
acquis. » (Chrissis et al. 2007, P.525)
3.2.9 Solution technique.
« Pour un projet de maintien ou de soutien logistique, les exigences qui ont besoin de travaux
de maintenance ou de conception peuvent être dictées par les besoins des utilisateurs ou des
défauts cachés dans les composants des produits. Les nouvelles exigences pourraient découler
du changement dans l’environnement d’exploitation. Ces exigences peuvent être découvertes
lors de la vérification du produit (s) où les performances réelles peuvent être comparées contre
les performances spécifiées et inacceptables et delà la dégradation peuvent être identifiées. Les
pratiques associées à ce domaine de processus “Solution technique” doivent être utilisées pour
effectuer des efforts de conception, de la maintenance ou du soutien logistique ». (Chrissis et al.
2007, P.538)
Pratique spécifique à la maintenance :
14
« Considérations pour des solutions alternatives et les critères de sélection comprend les
éléments suivants :
• Le coût de développement, la fabrication, approvisionnement, maintenance et soutien »
(Chrissis et al.2007, P.541)
« Le produit ou la conception des composants des produits doit fournir le contenu approprié
non seulement pour la mise en œuvre, mais aussi pour les autres phases du cycle de vie telle
que la modification, le réapprovisionnement, la maintenance, soutien logistique et
l’installation. » (Chrissis et al. 2007, P.544)
« Établir et maintenir un paquet de données techniques » (Chrissis et al. 2007, P.548)
« Ce paquet de données techniques est maintenu tout au long de la vie du produit pour
enregistrer les détails essentiels de la conception du produit. » (Chrissis et al. 2007,
P.549)
« Déterminer si les composants du produit doivent être développés, achetés ou réutilisés basés
sur les critères établis ». (Chrissis et al. 2007, S.552)
« Développer et maintenir la documentation qui sera utilisée pour installer, exploiter, et
réparer le produit. »
Manuel de maintenance
Sous-pratiques
1. Examiner les exigences, la conception, le produit et tester les résultats pour s’assurer que les
questions touchant l’installation, l’exploitation et la documentation de maintenance sont
identifiées et résolues.
2.Utiliser des méthodes efficaces pour développer l’installation, l’exploitation et la
documentation de maintenance.
4. Développer des versions préliminaires de la documentation d’installation, de fonctionnement
et de maintenance tôt dans le cycle de vie projet qui seront examiné par les parties intéressées.
5. Procéder à des examens par les pairs de l’installation, exploitation et documentation de
maintenance.
6.Réviser la documentation d’installation, exploitation et de maintenance si nécessaire »
(Chrissis et al., 2007, P.557-558).
15
3.2.10 La validation
« Les activités de validation peuvent être appliquées à tous les aspects du produit dans l’un de
ses environnements prévus, comme l’opération, la formation, la fabrication, la maintenance et
le service de soutien. » (Chrissis et al. 2007, P.565)
Pratique spécifique à la maintenance :
« Les méthodes de validation couvrent le développement, la maintenance, le support et la
formation pour le produit ou les composants du produit » (Chrissis et al. 2007, P.568)
« Un exemple d’évaluation de concepts de maintenance de l’environnement opérationnel est une
manifestation de fonctionnent des outils de maintenance avec le produit réel » (Chrissis et al.
2007, P.569)
3.2.11 La vérification
Pratique spécifique à la maintenance :
« Le travail à faire sur les produits est choisi en fonction de leur contribution aux objectifs de la
réunion du projet, aux exigences, et dans le but de faire face aux risques du projet. »
« Les produits de travail devant être vérifié peuvent inclure ceux qui sont associés à la
maintenance, la formation et le soutien servis ». (Chrissis et al. 2007, P.581)
3.3 Récapitulatif des pratiques de la maintenance et les observations
Tableau 4 : Observation de pratique de la CMMI
Domaine de
processus
Pratiques de la maintenance
dans le développement
logiciel couvert par CMMI
[7]
Équivalent de ces
pratiques [5] dans la
Maintenance
applicatif
Observations
La gestion de
configuration
Établir la baseline
Identifier les éléments de
Configuration
Mettre en place un système
de gestion de configuration
Créer des lignes de base
Établir l’intégrité
Effectuer des audits de
Configuration
Constituer des documents
de gestion de configuration
Gestion des
requêtes de
changement et de
demande de
modification
Planification de la
maintenance
(gestion de version
et mise à niveau)
Suivi et supervision
des requêtes de la
maintenance
Manque de
gestion des
priorités
Manque d’un
plan du retour à
la normale
16
Pister et contrôler les
changements
Contrôler les éléments de
Configuration
Faire le suivi du contrôle
des modifications
La gestion de
projet intégrée
L’établissement défini de
processus de projet au
démarrage du projet ;
Gestion du projet à l’aide de
processus de projet défini ;
Établir l’environnement de
travail pour le projet de
maintenance en se basant sur
les normes d’environnement
de travail ;
Établir des équipes qui sont
chargées d’accomplir les
objectifs du projet ;
Définition de
processus/service
de maintenance
logiciel
Formation
organisationnelle
de la maintenance
du logiciel
Pas de gestion
de
responsabilité
des employés
et
communication
Pas de
performance
des processus
de la
maintenance
L’innovation et
le déploiement
organisationnel
Ajouter, modifier de
nouvelles fonctionnalités ou
s’adapter à de nouvelles
technologies pour la
production plus courte
Innovation et
déploiement
Pas de mesure
des bénéfices de
l’amélioration
L’intégration du
produit
Se préparer à l’intégration des
produits
Assurer la compatibilité
de l’interface
Assembler les
composants du produit et
livrer le produit
Migration du
logiciel
Pas de
coordination
avant la livraison
et transition du
logiciel vers la
maintenance
Pas
Rajeunissement,
retraite de
portefeuilles
d’application
La gestion des
exigences
Gérer les changements des
exigences
Acquérir une
compréhension des
besoins
Identifier les
incohérences entre les
travaux du projet et les
exigences
Obtenir l’engagement
aux exigences
Gestion de versions
et de la
configuration
Assurance qualité
des services des
processus et des
produits
17
Maintenir une ligne
bidirectionnelle des
exigences
Faire la traçabilité des
exigences
Faire le suivi des
exigences système ou la
matrice de traçabilité
Le
développement
des exigences
Mettre en place des Concepts
opérationnels & scénarios
Analyser les besoins
Établir une définition des
fonctionnalités requises
Analyser les exigences
Valider les exigences
Valider les exigences avec
des méthodes
compréhensives
La gestion des
risques
Se préparer à la gestion des
risques
Déterminer les sources de
risque et catégories
Définir les paramètres de
risque
Mettre en place une
stratégie de gestion des
risques
Identifier et analyser les
risques
Identifier les risques
Évaluer, classer et
hiérarchiser les risques
Atténuer les risques
Mise en œuvre de Plans
d’atténuation des risques
Élaborer des Plans
d’atténuation des risques
Services de support
opérationnel
Analyse causale et
résolution de
problèmes
La gestion des
accords avec le
fournisseur
Établir des ententes avec le
fournisseur
Déterminer le type
d’Acquisition
Sélectionner des
fournisseurs
Établir les accords avec le
fournisseur
Gestion d’entente
des services et de
sous-traitance
18
Satisfaire les ententes
fournisseurs
Revue du coût des
produits
Signer le contrat de
fournisseur
Accepter le produit acquis
Produits de transition
Solution
technique,
Développement des exigences
Sélectionnez les solutions
techniques des composants de
produit qui serviront dans la
phase de maintenance
Élaborer la conception
Faire le détail de la
conception et le documenter
pour maintenir le produit.
Mettre en œuvre la
conception du produit
Développer le produit
Service d’évolution et
correction du logiciel
La validation Se préparer à la Validation
Valider le produit ou ses
composants
— Conformité
— Défauts
Vérification et
validation
La vérification Se préparer pour la
vérification
Définition des outils de
support
Effectuer des examens par
les pairs
Vérifier les produits
sélectionnés par les outils
de support
Vérification et
validation
3.4 Comparaison des activités de la maintenance et celles du CMMI
Tableau 5 : Comparaison des activités de la maintenance et celles du CMMI
Des activités uniques de la maintenance Des activités de la maintenance vis-à-vis du
CMMI
Gestion et planification annuelle de la
maintenance
19
Ententes de Service et contrats spécifiques
(SLA) de la maintenance
La gestion des accords avec le fournisseur
Gestion de requête de changement et de
demande de modification
La gestion de configuration
Gestion des employés de la Maintenance La gestion de projet intégrée
Rôle des utilisateurs, des opérations et des
employés de la maintenance
Gestion de la transition du développement au
groupe de la maintenance
Solution technique
Interception et surveillance des applications
en production
La gestion des risques
Gestion du logiciel (Acceptation, amélioration
et performance)
Innovation et déploiement
Mesure d’indicateur des services spécifique
aux activités du support et de la maintenance
Apporter un soutien à la clientèle concernant
une panne, une maintenance préventive et un
retour en service après panne
Solution technique
Donner le feed-back sur l’acceptation ou le
rejet du travail pour les requêtes de
modification des logiciels opérationnels selon
leur taille ;
Vérification et validation
Faire la gestion de l’horaire de support aux
opérations 24 heures/24 et escalade en cas de
problème
Faire une investigation et réponse aux
questions concernant les règles d’affaires des
systèmes opérationnels ;
Étude de différents types de requêtes de
changements supportées par un centre d’appel
help desk et son logiciel de support
Activités d’évaluation d’impact d’un
changement
La gestion de configuration
Spécialisation en essais et en vérification de
régression
Vérification et validation
Gestion de l’interface et du rôle portant sur la
gestion du changement
Intégration des produits
Gestion de la sous traitance des contrats de
service de Maintenance
Rendre le portefeuille d’application plus
performant
III. Recommandation L’amélioration des pratiques de la maintenance comme nous venons de le voir dépend dans quel
contexte nous voulons l’utiliser. Les pratiques de la maintenance dans le processus de
20
développement logiciel diffèrent des pratiques de maintenance applicatif. Cependant, de nos jours
la plupart des organisations ont tendance à faire les processus de maintenance un objet inapproprié
d’évaluations de maturité. Avec son objectif principal, gestion de projets, CMMI n’aborde pas
explicitement les questions propres aux activités uniques de maintenance logicielle. Selon [8], dans
ces recherches il nous montre que les projets qui profitent des meilleures pratiques du CMMI
peuvent se concentrer sur la maintenance, le développement ou les deux. [8] nous parle que : « The
term Maintenance appears in the CMMI 70 times », [8] continue en disant que « Les activités de
gestion de demande de modification est fait dans le processus de gestion de contrôle de changement et que
les autres activités peuvent se trouver faites dans les autres processus de développement par le
développeur et que ce dernier est interprété comme un mainteneur» et pourtant 80 % de ces activités
appartiennent à la maintenance dans le processus de développement de grand projet de
maintenance. Même si les demandes de changement sont faites dans ce processus de
développement cela n’empêche pas que CMMI manque des pratiques comme :
La gestion de priorité de demande de changement de requête n’est pas reconnue ;
Il y’a l’insuffisance des pratiques d’intégration de maintenance spécifiques comme
processus mécanismes d’amélioration ;
Les plans de rajeunissement, la migration de logiciel, retraite réingénierie et l’ingénierie
inverse ne sont pas satisfaisante ;
La gestion de responsabilité des employés et communication est absente ;
La gestion de la sous traitance des contrats de service de maintenance n’est pas adressé ;
Etc.
Ces pratiques uniques à la maintenance sont encore absentes dans la nouvelle version du CMMI,
car le CMMI maintient la vue du développeur dans le projet de développement logiciel. Nous
suggérons donc aux organisations avant de prendre CMMI comme modèle d’évaluation des
pratiques, de savoir dans quel contexte spécifique ils sont, le modèle CMMI actuel est approprié à
être utiliser pour le développement de systèmes et produits d’ingénierie logiciel ainsi que pour les
systèmes de services. Tandis que dans le contexte autre que le processus de développement, par
exemple dans la maintenance applicative qui n’utilise pas de gestion de projet, il est nécessaire de
prendre de modèles de maturité, mieux adaptés à leurs caractéristiques. Afin que le modèle CMMI
puisse être adapté aux maintenances applicatif, ce dernier devrait couvrir la gestion des services
axés sur la performance, la gestion de demandes de modification (gestion des priorités, la
21
documentation et l’acheminement de la demande de changement), la gestion de mesure indicatrice
des bénéfices de l’amélioration, la gestion d’acceptance et de refus du travail de la maintenance
selon la taille des requêtes, la gestion des employés de la maintenance (la gestion des rôles et
communications), la gestion de la transition, la gestion des tickets et au final la gestion de support
d’ingénierie d’évolution (réingénierie et l’ingénierie inverse).
IV. Conclusion
Dans ce travail nous avons vu le concept de la maintenance en mettant le point sur les activités
spécifique à la maintenance après la mise en production du logiciel (maintenance applicatif), leurs
catégories, ainsi que le processus auquel elles appartiennent. Nous avons vu aussi comment le
CMMI a également le potentiel d’améliorer les processus de la maintenance au cours du cycle de
développement d’un logiciel, ce qui pourraient résulter une bonne documentation et bien un
système plus facile à maintenir. Cependant au-delà d’une bonne documentation, d’autres pratiques
sont indispensables au CMMI afin que ce dernier puisse être tenu en compte dans l’amélioration
des pratiques de maintenance applicatif.
V. Références
[1] FIPS PUB 106-1984. Guideline on software maintenance, July, 1984.
[2] Abran, A., Moore J.W., Bourque P. et Dupuis R., 2004. Guide to the software body of
knowledge (SWEBOK). Ironman version. IEEE Computer Society Press: Los Alamitos
CA, 2004.
[3] Schneidewind, N.F., The state of software maintenance, IEEE Transactions on Software
Engineering, 1987.
[4] ISO/IEC 14764. Software Engineering-Software Maintenance, JTC1/SC7, Geneva
International Organization for Standardization, 1998
[5] April, A. et Abran, A., 2006. Améliorer la maintenance du logiciel.
[6] Basque, R., 2006. CMMI-2ème édition : Un itinéraire fléché vers le Capability Maturity
Model Intégration-Version 1.2. Dunod.
[7] Chrissis, M., Konrad, M. et Shrum, S., 2007. CMMI® Guidelines for Process Integration
and Product Development.
[8] Paul, R. C. Strategies for Applying the CMMI to Software Maintenance, PPT, November,
2003.
22
[9] CMMI® pour le developpement, Version 1.3
[10] Mamone, S., 1994. The IEEE standard for software maintenance. “ACM SIGSOFT Software
Engineering Notes”, 1994.