Analyse d’impact du changement

L‘analyse d‘impact décrit comment mener, à un coût efficace, une analyse complète d‘impact d‘un changement dans un logiciel existant. Les mainteneurs doivent posséder une connaissance intime de la structure et du contenu du logiciel. Ils utilisent ce savoir pour faire l‘analyse d‘impact, qui identifie tous les produits des systèmes et des logiciels affectés par une demande de modification de logiciel et établir une estimation des ressources nécessaires pour accomplir le changement. De plus, le risque à faire le changement est déterminé. La demande de changement, parfois appelée demande de modification (MR) et aussi appelée rapport de problème (PR), doit d‘abords être analysée et traduite en termes logiciels. Elle est faite après qu‘une demande de modification soit entrée dans le processus de gestion de configuration.

Les objectifs d‘analyse de l‘impact sont : 
• Détermination de la portée d‘un changement pour établir un plan et implanter le travail;
• Développement d‘estimations justes des ressources nécessaire pour effectuer le travail;
• L‘analyse de coûts/bénéfices du changement demandé;

La sévérité d‘un problème est aussi souvent utilisé pour décider comment et quand un problème sera corrigé. Le mainteneur identifie ensuite les composants affectés. Plusieurs solutions potentielles sont fournies et alors une recommandation est faite sur la meilleure voie d‘action. Les logiciels conçus avec la maintenabilité à l‘esprit facilitent grandement le processus d‘analyse d‘impact.

L‘analyse d‘impact du changement est effectuée principalement lors de la maintenance des programmes, en vue d‘évaluer les effets du changement sur le reste du système et de réduire le risque de s‘embarquer dans des dépenses coûteuses. Cette évaluation englobe l‘estimation des ressources humaines, financières, temps, effort et plannings nécessaires pour accomplir le changement.

Processus du changement

Une méthode formelle pour gérer le changement est essentielle pour deux raisons. Elle fournit (i) un canal de communication commun entre le personnel de maintenance, les utilisateurs, le chef de projet et les opérateurs, (ii) un annuaire des changements du système, pour la gestion de projet, l‘audit et le contrôle de qualité[7].

Madhavji définit les étapes du processus de changement comme suit :
• Identifier le besoin d‘apporter le changement à un élément (item) de l‘environnement;
• Acquérir le changement adéquat relatif à l‘élément;
• Évaluer ou estimer l‘impact du changement sur les autres éléments de l‘environnement;
• Sélectionner ou construire une méthode pour le processus de changement;
• Faire les changements nécessaires pour tous les éléments, et résoudre les interdépendances de manière satisfaisante;
• Enregistrer les détails des changements pour de futures références;
• Remettre l‘élément changé de nouveau dans l‘environnement.

Pour bien mener les changements dans un environnement, il est nécessaire de connaître tous les facteurs affectant le changement en question et les conséquences de ce changement.

Bohner décrit un processus plus en détail de changement du logiciel qui incorpore l‘analyse d‘impact [8]. Ce modèle illustre où les impacts du changement peuvent être détectés durant la plupart des activités de changement du logiciel.

Ces étapes se présentent comme suit :

1. Gérer le changement logiciel : au cours de laquelle les objectifs de qualité sont établis, les risques des changements sont déterminés et le suivi de la progression du changement, de l‘attribution des ressources et de la planification du release sont faites;

2. Comprendre le changement et déterminer l‘impact : permet d‘identifier les impacts du changement, de clarifier la requête du changement, d‘enregistrer les impacts du changement et de déterminer la stabilité du logiciel. L‘identification de l‘impact représente l‘activité centrale qui supporte la plupart des activités du processus de changement. Cette étape a pour objectif de déterminer les impacts du changement du logiciel, de classifier les changements et d‘explorer les changements similaires. De plus, elle permet d‘identifier les impacts des exigences et de conception, d‘analyser les impacts du code source et de déterminer les tests de régression candidats;

3. Spécifier et concevoir les changements : au cours de laquelle se fait l‘analyse des exigences du changement, l‘examen des changements de l‘architecture du logiciel, la dérivation des exigences du changement et la conception du programme de changement;

4. Implémenter les changements : c‘est une activité itérative qui englobe la détermination des modules à changer, l‘identification des expressions du programme à changer, l‘application des changements au programme et le test unitaire du logiciel modifié;

5. Retester le logiciel affecté : consiste à générer les cas de tests pour les nouvelles fonctionnalités ou celles modifiées, à mettre à jour la suite de tests, à effectuer les tests d‘intégration, à mener le test du système et à réaliser les tests d‘acceptation. Elle a pour objectif d‘assurer que les modifications effectuées répondent aux nouveaux besoins, et tout le système satisfait les besoins existants.

D‘une façon générale, une bonne méthodologie et une parfaite compréhension du système et du changement contribuent largement dans la réduction du temps entre la proposition du changement, son analyse, son implémentation et sa délivrance. Par conséquent, moins d‘effort requis pour effectuer le changement. L‘implémentation des modifications doit se faire de manière organisée et par priorité. D‘une part, les changements qui chevauchent doivent être rassemblés de même que les changements similaires afin d‘éviter la duplication du travail et l‘augmentation de la complexité. D‘autre part, dans le but de cerner les effets de bord du changement et son effet de propagation, un seul changement doit être traité à la fois sinon on risque de rendre le système indisponible.

Avantages de l’analyse d’impact 

Quand on est en face d‘une nécessité de modification dans un système, il est nécessaire de savoir l‘impact ou les effets secondaires qui peuvent résulter de cette modification sur le reste du système. Sans une bonne analyse d‘impact du changement, les ingénieurs peuvent faire de petits changements qui peuvent involontairement causer des problèmes majeurs ou avoir des répercussions sur tout le système.

En génie logiciel, cerner les spécifications et les objectifs du projet avant son développement diminue le risque de refaire le travail, de retarder les plannings et de dépasser le budget. Le même principe se présente en analyse d‘impact du changement. L‘identification des impacts du changement, la planification du changement et l‘estimation des ressources requises avant d‘implémenter le changement, permettent de diminuer le risque de s‘embarquer dans des dépenses coûteuses, inutiles ou imprévisibles.

Lorsqu‘un changement se présente, plusieurs solutions sont envisageables pour résoudre le même problème. L‘analyse d‘impact du changement permet aux gestionnaires de qualifier leurs choix à base d‘informations recueillies par l‘équipe de maintenance sur la faisabilité technique du changement. L‘analyse d‘impact est donc un outil d‘aide à la décision. En effet, si un changement peut affecter un ensemble de sections disjointes du programme, les gestionnaires peuvent choisir de ne pas l‘implémenter ou de l‘examiner une autre fois pour une implémentation alternative plus sûre. L‘analyse d‘impact du changement permet de diriger les tests de régression. Ces derniers jouent un rôle intégral dans la maintenance du logiciel. Les tests de régression appliqués au logiciel modifié, permettent d‘avoir l‘assurance que le code modifié continue à satisfaire les spécifications actuelles et qu‘il ne compromet pas le comportement du code non modifié.

Suite à une modification, il faut retester toutes les parties du code qui ont été affectées directement ou indirectement par ce changement. Pour cela, il faut recenser toutes les classes qui doivent être retestées pour que le système ne perde pas ses caractéristiques initiales et continues à satisfaire les besoins des utilisateurs actuels et futurs. Sans ce recensement, on doit retester tout le logiciel, ce qui est très coûteux et très long. Ne pas tester suffisamment peut avoir une influence sur la qualité du logiciel.