La structure des répertoires du produit sert de signet logiquement imbriqué pour tous les produits associés au produit
de la version. Les produits sont générés suite au cycle de vie des processus de développement suivant, pour le
développement de chaque élément d'implémentation constitutif du système global.
La figure suivante montre que le système X est constitué de "N" sous-systèmes et que chaque sous-système est constitué
de "N" composants. La structure des répertoires du produit fournit une marque de réservation commune pour les divers
produits nécessaires au développement de chaque partie de la totalité du système.
Bien qu'un architecte logiciel expérimenté puisse avoir une bonne idée de la composition du système dès le début, la
vue des principaux composants de développement apparaît suite aux activités d'analyse et de conception afin de définir
et de préciser les architectures potentielles.
Le tableau suivant fournit un modèle de structure des répertoires du système produit qui peut être utilisé comme
"Structure des répertoires du produit" dans les phases initiales du développement du projet, alors que les détails
précis des sous-systèmes composites et des couches architecturales restent encore à déterminer.
Une fois les activités d'analyse et de conception en cours, et qu'il y a une meilleure compréhension du nombre et de la
nature des sous-systèmes nécessaires au système global (Activité :
Conception des sous-systèmes), la structure des répertoires du produit doit être étendue pour accueillir chaque
sous-système.
Les informations dans la structure des répertoires du produit de niveau système doivent être visibles pour tous les
sous-systèmes du projet. Ainsi, à part la gestion du produit, les normes et principes relatifs aux exigences et aux
informations de test appartiendront à la structure des répertoires du produit de niveau système. Dans cet exemple, les
outils sont inclus dans la structure des répertoires du produit de niveau système, mais ils pourraient également se
trouver dans un répertoire de niveau supérieur, si un certain nombre de systèmes utilisent le même jeu d'outils.
Les informations qui se trouvent dans la structure des répertoires du produit de niveau sous-système se rapportent
directement au développement de ce sous-système particulier. Le nombre 'd'instanciations' de la structure des
répertoires du produit de niveau sous-système est clairement lié au nombre de sous-systèmes décidé suite aux activités
d'analyse et de conception. Par exemple, un système y peut avoir trois sous-systèmes (sous-système A, sous-système B et
sous-système N). Chaque sous-système comporte les informations nécessaires pour sa conception et éventuellement pour
son implémentation.
Une décomposition généralisée de la structure des répertoires du produit de niveau sous-système
donne ce qui suit :
Le nombre de composants résulte des décisions de conception du sous-système. La structure de répertoires suivante doit
être instanciée pour chaque composant à développer.
L'un des avantages des répertoires imbriqués de la manière indiquée, est que toutes les informations contextuelles
pertinentes sur le développement d'un composant se trouvent disponibles, soit au même niveau, soit au niveau inférieur.
Ce type d'imbrication logique donne lieu à la mise en place d'espaces de travail
de développement et d'intégration qui peuvent être liés à la structure de l'équipe de développement globale.
La convention de dénomination des produits est décrite dans Tâche : Définir des règles CM, Etape : Définir des pratiques
d'identification de la configuration
|