Contrôle de configurationreleaserelâchez les menottes !

La nature de plus en plus complexe et globale de toutes les activités dans tous les secteurs et secteurs verticaux, associée à des modèles d’affaires “Temps Internet” à tir rapide, met de nouveau l’accent sur la gestion du changement. La capacité de gérer efficacement le changement apparaît comme une clé de différenciation entre les concurrents – permettant aux organisations de faire évoluer leurs modèles commerciaux et leurs gammes de produits, et de changer de vitesse assez rapidement pour répondre aux opportunités de l’économie actuelle – avant la concurrence.

Alors que les organisations peinent à gérer des projets dans cet environnement, la gestion de la configuration (CM) est devenue un composant de plus en plus critique, offrant un cadre de gestion du changement.

La discipline du CM comprend six domaines d’expertise tels que définis par l’EIA-649 (ANSI, 2004))

• Planification et gestion du CM (CMPM),
• Identification de configuration (CI),
• Gestion des changements de configuration (CCM),
• Comptabilité de l’État de la configuration (CSA),
• Vérification de la configuration & Audits (CVA) et
• CM de Données numériques.

Cependant, ISO 10007 (ISO, 2003) regroupe CM en quatre classifications:

• CI,
• Contrôle de configuration (CC),
• CSA et
• Examens et audits de configuration (R &A).

( CCM et CC sont à toutes fins pratiques identiques, tout comme CVA et R & A.)

Notez que le contrôle de configuration est discuté dans cet article. La gestion des changements de configuration et le contrôle des changements sont également des termes utilisés pour décrire le même processus.

De nombreux chefs de projet perçoivent le contrôle de la configuration comme des systèmes de retenue et de confinement conçus pour freiner le développement de produits et qui ont généralement un impact négatif sur le calendrier du projet. Malheureusement, trop souvent, des processus de CC génériques conçus pour des programmes complexes de grande envergure tels que le développement d’armes ou de systèmes médicaux, sont imposés à d’autres types de projets. Ces processus ne sont pas adaptés pour répondre aux besoins, par exemple, d’un effort de développement Web ou d’un déploiement de nouveau produit. Cela conduit finalement à une frustration intense avec le processus de CC et l’effet “menottant” – où les processus non conçus pour répondre aux besoins du programme ont un impact négatif sur les progrès.

Les chefs de projet implémentent le contrôle de configuration pour contrôler et suivre les modifications. Les processus sont conçus pour s’assurer que le niveau approprié est utilisé pour approuver les changements et que ces changements sont basés sur les meilleures informations disponibles. Les processus fournissent un cadre pour l’examen des changements. Cela permet à l’équipe d’évaluer si la mise en œuvre du changement est acceptable et d’identifier les problèmes potentiels en temps opportun. Ces processus permettent un étalonnage et, si nécessaire, une révision ultérieure.

La vraie question n’est pas de savoir s’il faut implémenter le contrôle de configuration, mais quel niveau de contrôle de configuration implémenter. Une organisation peut exiger un package de contrôle de configuration “standard de l’entreprise” sur tous les projets. Ce type de système est souvent imposé aux équipes de projet en raison d’un historique de manque de contrôle de la configuration, et de l’impact financier qui en résulte. Les gestionnaires de projet, qui reconnaissent qu’une approche ” universelle ” ne fonctionnera pas, doivent démontrer que des contrôles appropriés sont en place pour éviter de répéter les erreurs du passé.

Contrôle de configuration en action

Le projet de développement typique ne nécessite pas de processus de contrôle de configuration au niveau d’un système d’armes majeur. Il est important de donner à l’équipe le niveau de flexibilité approprié tout en veillant à ce qu’un système de freins et contrepoids soit en place. La clé de tout système est l’effort requis pour documenter le processus, ainsi que la documentation requise par le processus. L’exemple de processus CC décrit ci-dessous est conçu pour répondre aux exigences d’un projet de développement d’applications de petite à moyenne taille.

L’équipe de projet doit d’abord analyser le rôle approprié du contrôle de configuration sur le projet. Ceci, au minimum sur un projet de logiciel, impliquerait un thème de documentation de tous les fichiers de code en interne et d’un certain type de documentation externe. D’autres domaines à couvrir incluent les processus d’approbation des modifications et de documentation des modifications. Un simple consensus des participants devrait suffire. Bien sûr, un conseil structuré convoqué régulièrement est préférable.

Passons maintenant aux différents aspects du processus de contrôle de configuration simple.

Documents

Le Plan de gestion de la configuration (CMP) définira le processus CC. Dans certaines applications où le processus CC est assez détaillé, un plan de contrôle de configuration (CCP) est développé. Dans les deux cas, tous les processus et procédures sont couverts pour effectuer le contrôle de la configuration.

La documentation de modification elle-même (détaillée plus loin) doit fournir suffisamment d’informations explicites au point de ne pas exiger d’informations supplémentaires de l’auteur. Cela est nécessaire en raison de la possibilité que l’initiateur ne soit pas disponible au moment de la mise en œuvre du changement.

Processus

Le processus CC est simple (pièce 1). Un individu a une idée ou trouve une erreur dans le système actuel. Cette personne doit documenter ses conclusions sur une demande de modification d’entreprise (ECR), un formulaire utilisé pour consigner tous les bogues, modifications ou améliorations pour le projet donné. La demande de changement est acheminée aux pairs et aux superviseurs pour examen, puis approuvée et mise en œuvre.

Pièce justificative 1 – Processus de contrôle de configuration simple

Documentation des modifications

La documentation des modifications est la partie la plus critique d’un système de contrôle de configuration. Le détail de la documentation n’est pas aussi important que l’information documentée. Cependant, les informations documentées doivent décrire le changement et inclure, au minimum, les informations suivantes. Les exigences minimales pour la documentation sont les suivantes:

Bien sûr, plus la documentation contient d’informations, plus il est facile de recréer, de récupérer, d’analyser et de corriger. De plus, cela facilitera la documentation finale pour la livraison du produit.

Lorsqu’une personne découvre une erreur ou une exigence dans le projet en cours, elle documente la modification requise. Une demande de modification contient des informations sur la demande et décrit le scénario qui a découvert l’erreur, qui l’a découverte, quand elle a été découverte et les correctifs recommandés. La demande doit également identifier les éléments de configuration affectés, si possible, et placer une sorte de code de gravité ou de priorité pour identifier quand cette modification, si elle est approuvée, doit se produire.

Approbation des modifications

L’approbation des modifications doit provenir d’un superviseur de projet désigné ayant une vue d’ensemble de l’impact des modifications. Un examen par les pairs est un moyen très efficace de vérifier toutes les facettes du changement et de s’assurer que tous les domaines touchés par le changement sont abordés. Le fait que le client soit d’accord avec le changement serait bénéfique pour les améliorations. Cependant, dans les petits projets de développement, la plupart des modifications sont de type “correction de bogues” et le client ne verrait pas l’impact du changement.

Collecte de données

La collecte de données est essentielle pour récupérer des informations sur des éléments similaires et découvrir des tendances et des tendances. Ces informations doivent résider électroniquement, ce qui permet de récupérer facilement les données et de les manipuler pour la comptabilité de l’état et les mesures. Les informations peuvent être utilisées pour compiler un rapport sur les “leçons apprises”, qui est distribué dans toute une organisation à des fins d’amélioration technique.

Mise en œuvre du changement.

Une fois toutes les approbations appropriées reçues, la tâche de mise en œuvre commence. Les tests effectués à chaque étape de la mise en œuvre permettent de vérifier que les impacts sur d’autres aspects du programme sont minimes. Tous les tests sont terminés et le changement est implémenté dans l’ensemble du programme.

Processus en boucle fermée

Un processus en boucle fermée dans lequel l’initiateur du changement connaîtra le résultat final du changement avant qu’il n’apparaisse dans le produit final est un élément clé du succès. Cela est vrai pour tous les types d’industries, de la construction à la fabrication en passant par les logiciels.

Ce processus en boucle fermée met en place des tableaux de commande ayant différents rôles dans le processus de changement (pièce 2). Chaque conseil a l’obligation d’examiner un changement dans le contexte complet de sa charte et de prendre une décision définitive pour chaque changement. Bien sûr, le conseil peut avoir besoin de renseignements supplémentaires avant de prendre cette décision, mais cela devrait être minime.

L’Institut pour la gestion de la configuration (ICMHQ) enseigne la méthodologie CMII (CMIIU) pour la gestion de la configuration et a développé cette vue d’un processus de changement en boucle fermée. Ce processus commence et se termine par l’élément final. Notez que l’administration des modifications de configuration apparaît à trois niveaux différents dans la boucle. Chaque domaine est défini différemment et comporte des rôles et des responsabilités spécifiques.

• Examen technique Ensures S’assure que toutes les évaluations détaillées et l’analyse de faisabilité sont complètes.
• Le Comité d’examen des changements (CRB) – Évalue l’impact commercial du changement. Ce changement est-il valable pour notre environnement d’affaires? Répond-elle à l’un de nos objectifs stratégiques ? S’inscrit-il dans notre énoncé de vision? Avec un changement approuvé, le CRB peut ou non indiquer un calendrier pour le changement, en fonction des prévisions concurrentielles et des risques commerciaux.
• Le Conseil de mise en œuvre du changement (CIB) – Alloue le financement requis et détermine les délais de mise en œuvre du changement. Cela inclut également l’attribution de l’effectivité pour le changement, qui spécifie quand le changement est effectif. L’efficacité peut concerner une date, une construction, un numéro de série ou un numéro de lot. Cela dépend de l’élément final.

L’option Fast Track de la boucle est l’endroit où toute la douleur de CC est libérée et où les propriétaires peuvent obtenir une modification approuvée en quelques minutes par rapport aux jours. La clé à cela est bien sûr un arbre de documentation approprié pour chaque produit. Un créateur et un utilisateur doivent être affectés à chaque document. Si les modifications n’affectent que la documentation de bas niveau, la procédure accélérée est en ordre et la modification passe par le processus CC.

Résumé

La clé de tout processus de contrôle de configuration réussi est l’adhésion de toute l’équipe du projet. Il ne faut pas demander aux membres de l’équipe de renoncer à un jugement et à un contrôle judicieux au nom d’une infrastructure de gestion qui n’est pas conçue pour répondre aux exigences du projet en question. Les processus de contrôle de la configuration sont conçus pour réduire le risque de défaillance et garantir que les livrables sont respectés dans les délais et le budget impartis. Si l’équipe de projet participe à l’établissement du cadre de contrôle de la configuration initiale, la participation et l’acceptation au sein de l’équipe de projet sont accélérées et l’infrastructure mise en place soutiendra les objectifs opérationnels.