Concept: Structure des répertoires du produit
Une structure des répertoires du produit contient le répertoire et les sous-répertoires hiérarchiques des dossiers et fichiers utilisés pour stocker des produits associés au produit.
Relations
Description principale

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.

Structure des répertoires de niveau composant Structure des répertoires du produit de niveau sous-système Structure des répertoires du produit système Diagramme décrit dans la légende ci-dessus.

Structure des répertoires du produit 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.

Structure des répertoires du produit de niveau système

Exigences du système

Modèles

Modèle de cas d'utilisation Package de cas d'utilisation
Base de données Attributs d'exigences
Documents Vision
Glossaire
Demandes de partie prenante
Spécifications supplémentaires
Spécifications des exigences logicielles
Storyboards

Rapports

Rapport : Vue d'ensemble du modèle de cas d'utilisation
Rapport : Spécification du cas d'utilisation
Conception et implémentation du système Modèles Modèle d'analyse Réalisation de cas d'utilisation
Modèle de conception Sous-système de conception
Interface
Package de conception
Modèle de données
Document d'analyse de la charge de travail
Prototype d'interface utilisateur
Documents Document d'architecture logicielle
Rapport : Vue d'ensemble du modèle de conception
Carte de navigation
Sous-système 1 Structure des répertoires du sous-système
Sous-système N Structure des répertoires du sous-système
Intégration de système Plans Plan de construction et intégration
Bibliothèques  
Test système Plan de test Suites de tests
Jeu d'essai Scripts de test
Données de test  
Résultats du test  
Déploiement du système Plan de déploiement  
Documents Notes sur l'édition
Manuels Matériel de support de l'utilisateur
Supports de formation
Artefacts d'installation  
Gestion du système Plans Plan de développement logiciel
Plan d'itération Plan de gestion des exigences
Liste des risques Plan de gestion des risques
Plan de développement Plan d'infrastructure
Plan d'acceptation du produit Plan de gestion de configuration
Plan de documentation Plan d'assurance qualité
Plan de résolution des problèmes Plan de gestion des sous-traitants
Plan d'amélioration du processus Plan de mesure
Evaluations Evaluation d'une itération
Evaluation de l'organisation de développement
Evaluation de l'état
Outils Environnement de développement Outils Editeurs
Compilateurs
Outils de gestion de la configuration Rational ClearCase
Outils de gestion des exigences Rational RequisitePro
Outils de modélisation visuelle Rational Rose
Outils de test Rational Test Factory
Détection des défauts Rational ClearQuest
Normes et principes Exigences Attributs d'exigences
Instructions spécifiques au projet
Conception Instructions spécifiques au projet
Implémentation Instructions spécifiques au projet
Documentation Guide de style des manuels

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.

Structure des répertoires du sous-système

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 :

Structure des répertoires du produit de niveau sous-système

Exigences du sous-système N

Modèles Modèle de cas d'utilisation Package de cas d'utilisation
Storyboard
Cas d'utilisation (texte)
Prototype d'interface utilisateur
Base de données Attributs d'exigences
Documents Vision
Glossaire
Demandes de partie prenante
Spécifications supplémentaires
Spécifications des exigences logicielles
Storyboards

Rapports

Rapport : Vue d'ensemble du modèle de cas d'utilisation
Rapport : Spécification du cas d'utilisation
Conception et implémentation du système N Modèles Modèle d'analyse Réalisation de cas d'utilisation
Modèle de conception Packages de conception
Packages d'interfaces
Packages de tests
Modèle d'implémentation
Modèle de données
Modèle de charge de travail
Documents Document d'architecture logicielle
Rapport : Vue d'ensemble du modèle de conception
Carte de navigation

Rapports

Rapport : Réalisation de cas d'utilisation

Composant 1

Répertoire du composant 1

Composant N

Répertoire du composant N
Intégration du sous-système N Plans Plan de construction et intégration
Bibliothèques  
Test du sous-système N Plan de test Suites de tests
Jeu d'essai Scripts de test
Résultats du test  
Données de test  

Structure des répertoires du composant

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