Tâche: Création de règles de gestion de configuration
Cette tâche explique comment développer des règles de gestion de configuration, qui comprennent les pratiques d'identification de configuration, de référencement, d'archivage et des exigences de génération de rapports de configuration.
Disciplines: Gestion de la configuration et des changements
Objet

L'objectif de cette tâche est d'établir des règles de gestion de configuration de projet à utiliser pour surveiller et protéger les actifs du projet, ainsi que pour mettre en vigueur les pratiques de développement de logiciels. Les règles définies pour un projet visent également à faciliter la communication entre les membres des équipes et à réduire les problèmes d'intégration. 

Relations
Etapes
Définir des pratiques d'identification de la configuration
Objectif :  Identifier et stocker des produits dans un référentiel sécurisé 
Guides d'utilisation de l'outil : Création de références avec Rational ClearCase 

L'identification de la configuration est une étape essentielle de la gestion de la configuration et est définie par l'IEEE comme "un élément de la gestion de la configuration, qui consiste à choisir les éléments de configuration pour un système et à enregistrer leurs caractéristiques fonctionnelles et physiques dans une documentation technique". Du point de vue de la gestion de la configuration logicielle, l'identification de la configuration décrit la capacité à localiser et identifier facilement et rapidement la version appropriée de n'importe quel produit du projet. Un système d'identification de la configuration inefficace entraîne des pertes de temps et un niveau de qualité insuffisant.

Des étiquettes identifient les versions spécifiques des produits. L'ensemble des produits qui constituent une version d'un sous-système sont identifiables collectivement et individuellement par le biais d'un numéro de version et d'une étiquette. Les étiquettes facilitent donc la réutilisation ou le référencement des ensembles de produits d'origine.

Vous trouverez ci-dessous un exemple de convention d'étiquetage des produits qui peut être utilisée pour identifier les chemins et les produits au sein de la structure de répertoires du produit.

<SYSTEME>[<A>]_[<SOUS-SYSTEME>]_[<A>]_[R|A|B]<X>[.<Y>.<Z>][.BL<#>]

<SYSTEME> Identifie le système

<A> Représente le code à trois lettres (TLA!). Il est utilisé pour les différents types de produits utilisés dans la création du système. Par exemple :

PLN  Plans de projet 
REQ  Fichiers d'exigences 
USC  Cas d'utilisation 
MOD  Fichiers de modèles 
SRC  Fichiers de code source 
INT  Interfaces publiques 
TST  Scripts et résultats de test 
DOC  Documentation (utilisateur, notes d'édition) 
BIN  Exécutables 

<SOUS-SYSTEME> Identifie chaque sous-système

<A> Représente le code à trois lettres pour les différentes types de produits utilisés dans la création du sous-système. Conforme au tableau ci-dessous.

R|A|B  Correspond à version, alpha ou bêta 
<X>  Entier, correspond à une version importante (par ex. 1) 
<Y>  Entier (facultatif), correspond à une version mineure 
<Z>  Entier (facultatif), correspond à une version alternative (correctifs, portages, etc.) 
BL  Correspond à niveau de base (une version interne) 
Entier, pour les versions internes 

Exemples :

T2K_R1.0  Version 1 du système Thorn 2000 
T2K_GUI_R2.0.BL5  Version interne du système d'interface graphique qui sera intégré à la version 2 
T2K_B1.1  Version bêta 1.1 du système Thorn 2000 
T2K_R2.0.BL16  Référence système interne n°16 de thorn 2000 qui sera utilisée pour créer la version 2 
T2K_R1.0.5  Version de maintenance de Thorn 2000 
Définir les pratiques de référencement

Une référence fournit un point stable et une image instantanée des produits du projet. Concept : Référencement définit quand il convient de créer des références au cours du cycle de vie du projet. Cette étape fournit des conseils supplémentaires sur cette pratique.

Les références identifient des ensembles de fichiers et de répertoires bien définis et sont créées à des moments clés du projet. Vous pouvez créer des références pour un sous-système ou pour le système entier. Les références doivent être identifiées conformément au modèle décrit à l'étape précédente (Définir la convention d'étiquetage des produits).

Lors de la création d'une référence, il est important d'indiquer s'il s'agit d'une :

  • 'Référence sous-système', avec TOUTES les versions des fichiers et répertoires qui ont fait l'objet de modifications dans le système ou dans les sous-systèmes.
  • 'Référence système', avec une SEULE version des fichiers et répertoires de tous les sous-systèmes.

En général, pour une meilleure gestion des versions, il est recommandé de créer des références système pour chaque étape majeure ou mineure du projet, et des références sous-système selon les besoins ou de façon plus fréquente. On considère qu'il convient de générer une référence dès lors qu'au moins 30 % des éléments d'un sous-système ont été modifiés.

Définir des pratiques d'archivage

L'objet de cette étape est de s'assurer que les logiciels du projet et les actifs associés (documents originaux) sont sauvegardés, catalogués et transférés vers les sites de stockage prévus. Les archives sont des ressources précieuses en cas de réutilisation de composants ou de récupération après sinistre. Il convient donc d'effectuer des sauvegardes régulières, et à chaque étape majeure et mineure.

Les instructions d'étiquetage décrites précédemment à l'étape 'Définir la convention d'étiquetage des produits' peuvent être utilisées pour créer des étiquettes d'archivage. Toutefois, il peut s'avérer nécessaire de fournir des informations supplémentaires sur le lieu où le support physique sera stocké. Par exemple :

NUMERO DE SERIE  123456789 
VOLUME  1 sur 3 
COFFRE  B5 
DATE DE STOCKAGE  21 juin 1999 

Toutes les informations liées au produit doivent être consignées dans une base de données, afin de faciliter la diffusion et la réutilisation.

Définir des exigences de génération de rapports sur l'état de la configuration
Objet Les activités de changement constituent un bon indicateur de l'état d'avancement et des tendances pour un projet. Dans le cadre de cette étape, le responsable de projet devra définir les données de changement qui devront figurer dans les rapports, qui devra les consigner et à quelle fréquence. 
Sous-étapes :  
Guides d'utilisation de l'outil :  

Génération de rapports sur l'état de la configuration , si elle est utilisée, elle décrit les différentes sources permettant de créer des rapports sur l'état de la configuration.

Sélectionner des rapports liés aux demandes de changement Haut de la page

Vous devez sélectionner des rapports qui peuvent être dérivés des demandes de changement soumises pour le projet. Il existe un certain nombre de rapports utiles liés aux demandes de changement.

Dans la catégorie 'chronologie', des rapports peuvent être demandés en termes de nombre dedemandes de changement sur un laps de temps donné (une semaine ou un mois), en respectant les critères suivants :

  • Envoyé
  • Affecté
  • Résolu
  • Priorité

En classant les incidents par état, vous pouvez évaluer l'état d'avancement du projet. Par exemple, si la plupart des incidents sont résolus, la fin du projet est plus proche que si la plupart des projets étaient simplement soumis.

Dans la catégorie 'distribution', des rapports peuvent être demandés pour répondre aux questions suivantes :

  • Qui a détecté quels types de défauts, et à quel stade du projet ?
  • A qui les incidents sont-ils affectés ?
  • Combien d'incidents sont ouverts pour un ingénieur donné ?
  • Les défauts identifiés sont-ils graves ?
  • A quel niveau du processus se situe la cause de l'incident (cause profonde) ?
  • Quand les incidents seront-ils résolus ?
  • Combien de défauts y a-t-il ?
  • Quel est le degré de gravité de ces défauts ?

Ces mesures peuvent contribuer à déterminer la charge de travail, qui travaille sur les principaux incidents et à quelle vitesse ils sont résolus.

Dans la catégorie 'tendance', des rapports peuvent être demandés pour répondre aux questions suivantes :

  • Combien de défauts sont ouverts pour ce jour, cette semaine ou ce mois ?
  • Combien de défauts ont été fermés ce jour, cette semaine ou ce mois ?

Ces données sont utiles pour évaluer la vitesse de résolution et peuvent fournir des informations sur l'efficacité des ingénieurs.

Définir la fréquence de génération de rapports Haut de la page

La fréquence des rapports doit être suffisante pour assurer la pertinence des informations fournies et des prises de décisions appropriées. La fréquence choisie peut être la suivante :

  • Quotidienne - il est peu probable qu'une fréquence aussi importante soit nécessaire
  • Hebdomadaire - rapports de tendances, distribution, dénombrement et rapports de construction
  • Mensuelle - rapports de tendances, distribution, dénombrement et rapports de construction
  • Par itération - rapports de tendances, distribution, dénombrement, rapports de construction et descriptions de versions
  • Par phase - rapports de tendances, distribution, dénombrement, rapports de construction et descriptions de versions
  • A la fin du projet - rapports de tendances, distribution, dénombrement, rapports de construction et descriptions de versions


Plus d'informations