Définir des pratiques d'identification de la configuration
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.
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.
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
|
|