Concept: Product Directory Structure |
A product directory structure contains the hierarchical directory and subdirectories of folders and files used to store product-related work products.
Relationships
Related Elements | Configuration Manager
Main Description
The Product Directory Structure serves as a logically nested placeholder for all versionable product-related work products. Work products are produced as result of the following development process lifecycle and for the development of each constituent Implementation Element of the overall system. The following figure shows that System-X consists of "N" subsystems and each subsystem consists of "N" components. The Product Directory Structure provides a common placeholder for the various work products that are required for the development of each part of the overall system. ### System Product Directory Structure Although an experienced software architect may have a good idea of system composition at the outset, the view of major developmental components emerges as a result of Analysis & Design-related activities to define and refine candidate architectures. The following table provides a Product System Directory Structure pattern that could be used as a "Product Directory Structure" in the initial phases of project development whereas the precise details of composite subsystems and architectural layering has yet to be determined.
System Level Product Directory Structure
System Requirements | Models | Use-Case Model | Use-Case Package
Database | Requirements Attributes
Documents | Vision
Glossary
Stakeholder Requests
Supplementary Specifications
Software Requirement Specs
Storyboards
Reports | Report: Use-Case Model Survey
Report: Use-Case Specification
System Design and Implementation | Models | Analysis Model | Use-Case Realization
Design Model | Design Subsystem
Interface
Design Package
Data Model
Workload Analysis Document
User-Interface Prototype
Documents | Software Architecture Document
Report: Design-Model Survey
Navigation Map
Subsystem-1 | Subsystem Directory Structure
Subsystem-N | Subsystem Directory Structure
System Integration | Plans | Integration Build Plan
Libraries |
System Test | Test Plan | Test Suites
Test Cases | Test Scripts
Test Data |
Test Results |
System Deployment | Deployment Plan |
Documents | Release Notes
Manuals | User Support Material
Training Materials
Installation Artifacts |
System Management | Plans | Software Development Plan
Iteration Plan | Requirements Management Plan
Risk List | Risk Management Plan
Development Case | Infrastructure Plan
Product Acceptance Plan | Configuration Management Plan
Documentation Plan | QA Plan
Problem Resolution Plan | Subcontractor Management Plan
Process Improvement Plan | Measurement Plan
Assessments | Iteration Assessment
Development Organization Assessment
Status Assessment
Tools | Development Environment Tools | Editors
Compilers
Configuration Management Tools | Rational ClearCase
Requirements Management Tools | Rational RequisitePro
Visual Modeling Tools | Rational Rose
Test Tools | Rational Test Factory
Defect Tracking | Rational ClearQuest
Standards and Guidelines | Requirements | Requirements Attributes
Project-Specific Guidelines
Design | Project-Specific Guidelines
Implementation | Project-Specific Guidelines
Documentation | Manual Styleguide
Once Analysis & Design activities are underway, and there is an improved understanding about the number and nature of subsystems required in the overall system (Task: Subsystem Design), the Product Directory Structure needs to be expanded to accommodate each subsystem. The information in the System Product Directory Structure needs to be visible to all subsystems across the project. So apart from the product management, requirements and test information Standards and Guidelines would belong in the System Product Directory Structure. In this instance, Tools are included in the System Product Directory Structure, however, they could be in a higher level directory where a number of Systems could be using the same toolset. ### Subsystem Directory Structure The information in the Product Subsystem Directory Structure relates directly to the development of that particular subsystem. The number of 'instantiations' of the Subsystems Product Directory Structure is clearly related to number of subsystems decided upon as a result of the Analysis&Design activities. For instance, System-y may have three subsystems (Subsystem-A, Subsystem-B and Subsystem-N). Each subsystem has the necessary information for its design and, eventual, implementation. A generalized breakdown of the Subsystem Product Directory Structure is as follows:
Subsystem Level Product Directory Structure
Subsystem-N Requirements | Models | Use-Case Model | Use-Case Package
Storyboard
Use-Case (text)
User-Interface Prototype
Database | Requirements Attributes
Documents | Vision
Glossary
Stakeholder Requests
Supplementary Specifications
Software Requirement Specs
Storyboards
Reports | Report: Use-Case Model Survey
Report: Use-Case Specification
Subsystem-N Design and Implementation | Models | Analysis Model | Use-Case Realization
Design Model | Design Packages
Interface Packages
Test Packages
Implementation Model
Data Model
Workload Model
Documents | Software Architecture Document
Report: Design-Model Survey
Navigation Map
Reports | Report: Use-Case Realization
Component-1 | Component-1 Directory
Component-N | Component-N Directory
Subsystem-N Integration | Plans | Integration Build Plan
Libraries |
Subsystem-N Test | Test Plan | Test Suites
Test Cases | Test Scripts
Test Results |
Test Data |
### Component Directory Structure The number of components is a result of subsystem design decisions. The following directory structure needs to be instantiated for each component to be developed.
Component Level Directory Structure
Component | Source Code
Object (Executable) Code
Interfaces
Test Code
Executable Test Scripts
Test Data
Test Results
One benefit of nesting directories in the prescribed manner is that all relevant contextual information on the development of a component is available, either at the same level, or the level above. This type of logical nesting gives rise to the setting up of development and integration Workspaces that can linked to the overall development team structure. The naming convention for work products is described in Task: Establish CM Policies, Step: Define Configuration Identification Practices
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.