Overview
In this activity, the software configuration management (SCM) manager determines the project’s naming and numbering standards. The SCM manager also determines the directory structures (and the associated read and write privileges) to be used during the project to protect completed software products, and to aid in the development of new software products.
Roles and Responsibilities
The SCM manager determines the naming and numbering scheme to be used, directory structure, and the associated read and write privileges.
The system administrator performs the actual setup of the directory structure.
The software engineering manager reviews the directory structure and the naming and numbering scheme to ensure adequacy for the project’s development needs.
Controls
The software engineering environment of the project (e.g., development platform and compilers) documented in the Establishing a Software Development Environment section of the Software Development Plan (SDP) (see Appendix E).
The SCM tools which have been selected for the project and documented in the Tools section of the SCM Plan (SCMP) (see Appendix E).
Inputs
The completed software product list in the SCM section of the SDP, which documents the products that must be placed under SCM.
Procedures
Note: The following is a general discussion only. The characteristics of the naming and numbering scheme and the directory structure will be greatly impacted by the SCM tools selected and by the software engineering environment.
1) The SCM manager reviews the software product list to gain an understanding of the software products that must be controlled.
2) The SCM manager develops a naming and numbering scheme that indicates the project, product name, and version or revision of each product on the software product list.
3) The SCM manager assigns a unique name and number to each software product. Example 1 describes the naming and numbering of a software product, explaining the information that is conveyed by the name and number.
Example 1:
The Software Requirements Specification (SRS) for the XYZ project may be assigned the name XYZ_SRS_A0, where XYZ indicates the project, SRS indicates that this is the Software Requirements Specification, A indicates that this is the first version of this document, and 0 indicates that there have been no revisions. If the SRS is modified later by an approved Software Change Request (SCR) (see Appendix C), the new file will have the name, XYZ_SRS_A1, indicating that this is the first revision of the document. If developers create a new version of this document during another cycle, it may be named XYZ_SRS_B0, to indicate that it is a new version containing a new set of requirements.
Code units may be handled similarly. However, some SCM tools (e.g., Polytron Version Control Systemä (PVCSä )) keep track of versions and revisions internally, making it unnecessary to specify the version or revision number in the file name. The SCM manager simply assigns a name to each code unit (e.g., temp_sensor.ada).
Note: Individual code units cannot be identified prior to detailed design. Thus, the SCM manager must update the naming and numbering scheme when the code units are defined.
4) The software engineering manager reviews the sample directory structure described in Example 2 and, using the software product list, tailors the structure to meet the project’s needs.
Example 2: Sample Directory Structure
The directory structure for the XYZ project is based on the Microsoft Disk Operating System (MS-DOS) directory structure. Ada is the assumed programming language.
The system administrator creates a separate volume on the disk of the file server, called "XYZ," to store all XYZ project-related source and object code. A volume is much like a partition on a hard drive in MS-DOS, except it is created using the Novellä network software. The XYZ volume stores the Ada source and object files needed to build the entire software system. In addition, it stores all commercial off-the-shelf (COTS) tools, including MS Word for Windowsä , PVCSä , Alsysä compiler, and associated tools. It is important to note that the Alsysä compiler must be in this same volume. The following descriptions and directory-hierarchy diagrams illustrate this sample directory structure. The directories shown represent the minimum created on any project.
In the XYZ project, the system administrator creates a directory structure for each computer software configuration item (CSCI). Examples include directories called "XYZ: FLIGHT (CSCI L)" and "XYZ: GROUND (CSCI M)." The system administrator creates numerous subdirectories within each of these to isolate the development processes for different software development items. The directory structure indicates where documents, compilation units, and source code are kept, along with what is under development, what is under integration, and what is baselined.
- project: VOLUME. The system administrator creates a separate volume for each project (a partition on a hard drive). The volume, at a minimum, has a SHARED directory and a directory for each CSCI within the project.
- project: SHARED. The SHARED directory has a REUSE subdirectory for components that can be used on any CSCI and a DOCUMENT subdirectory for documents related to the project as a whole.
- project:CSCI. The CSCI directory is labeled with the CSCI’s name. The CSCI directory has a CONFIG subdirectory and a DEVELOP subdirectory. The contents of the CONFIG subdirectory are under the control of SCM, whereas, the contents of the DEVELOP subdirectory are under the control of the individual developers.
- project:CSCI\DEVELOP. The DEVELOP subdirectory is used for actual software development. This subdirectory has one user subdirectory for each team member.
- project:CSCI\DEVELOP\user. The user subdirectory is renamed with the team member's name. This subdirectory has the following subdirectories:
- LIBRARY (contains the compiled and executable code);
- SOURCE (contains all source code for the Ada units);
- DOCUMENT (contains all documents that the developer writes); and
- TEST (contains PLANS, PROCEDURES, DRIVERS, RESULTS, and REPORTS subdirectories).
These subdirectories together make up the user’s Software Development File (SDF).
Overall Directory Structure
- project: CSCI\CONFIG. The CONFIG subdirectory is under SCM and contains the software products for the CSCI that are baselined, under development (but needed by other users), or awaiting management approval.
- project: CSCI\CONFIG\INTEGRATION. The products in the INTEGRATION subdirectory are under SCM but have not been baselined. Software products in this subdirectory are often still under development but are complete enough to be useful to other developers, or else are awaiting management approval. The INTEGRATION directory has the following subdirectories:
- LIBRARY (contains the compiled and executable code);
- SOURCE (contains all source code for the Ada units);
- DOCUMENT (contains CONCEPT, REQUIRE, DESIGN, MANUALS, and USERGUIDE subdirectories); and
- TEST (contains PLANS, PROCEDURES, DRIVERS, RESULTS, and REPORTS subdirectories).
CSCI\CONFIG\INTEGRATION DIRECTORY (1.1)
- project: CSCI\CONFIG\BASELINE. The products under the BASELINE subdirectory have been baselined and are subject to the formal change-control process. The BASELINE subdirectory has the following subdirectories:
- LIBRARY (contains the compiled and executable code);
- SOURCE (contains all source code for the Ada units);
- DOCUMENT (contains CONCEPT, REQUIRE, DESIGN, MANUALS, and USERGUIDE subdirectories); and
- TEST (contains PLANS, PROCEDURES, DRIVERS, RESULTS, and REPORTS subdirectories).
Note: Each subdirectory may contain a subdirectory for each version of the software product.
CSCI\CONFIG\BASELINE DIRECTORY (1.2)
- SHARED\REUSE. The REUSE subdirectory contains reusable software products that are to be used in more than one CSCI.
- project: SHARED\REUSE\INTEGRATION. The REUSE\INTEGRATION subdirectory contains items that are still under development but are complete enough to be useful to other developers, or else are awaiting management approval. The REUSE\INTEGRATION directory has the following subdirectories:
- LIBRARY (contains the compiled and executable code);
- SOURCE (contains all source code for the code units);
- DOCUMENT (contains a subdirectory for each reusable document); and
- TEST (contains PLANS, PROCEDURES, DRIVERS, RESULTS, and REPORTS subdirectories).
Note: Each subdirectory may contain a subdirectory for each version of the software product.
SHARED\REUSE\INTEGRATION DIRECTORY (1.3)
- project: SHARED\REUSE\BASELINE. The REUSE\BASELINE subdirectory contains software and documentation that has been baselined and is subject to the formal change-control process. The REUSE\BASELINE subdirectory has the following subdirectories:
- LIBRARY (contains the compiled and executable code);
- SOURCE (contains all source code for the code units);
- DOCUMENT (contains a subdirectory for each reusable document); and
- TEST (contains PLANS, PROCEDURES, DRIVERS, RESULTS, and REPORTS subdirectories).
Note: Each subdirectory may contain a subdirectory for each version of the software product.
SHARED\REUSE\BASELINE DIRECTORY (1.4)
- project:SHARED\DOCUMENT. The DOCUMENT subdirectory contains those documents that apply to all CSCIs or to the project as a whole. Examples of these are the Software Quality Assurance (SQA) plan and integration plans.
- project: SHARED\DOCUMENT\INTEGRATION. The DOCUMENT\INTEGRATION subdirectory contains documents that are under configuration control but have not been baselined. This usually includes products that are waiting for management approval or that are partially complete and needed by other project-group members. The INTEGRATION subdirectory has the following subdirectories:
PLANS (contains management plans and reports that apply to the project as a whole, such as the SQA plan);
GUIDES (contains all guides or manuals that may apply to more than one CSCI;
INTERFACES (contains Interface Requirements Specifications and any other documents that pertain to interfaces between CSCIs); and
TEST (contains PLANS, PROCEDURES, DRIVERS, RESULTS, and REPORTS subdirectories; these contain tests used during the integration of CSCIs or qualification tests for the software system as a whole).
Note: Each subdirectory may contain a subdirectory for each version of the software product.
SHARED\DOCUMENT\INTEGRATION DIRECTORY (1.5)
- project: SHARED\DOCUMENT\BASELINE. The DOCUMENT\BASELINE subdirectory contains documents that have been baselined and are subject to the formal change-control process. The DOCUMENT\BASELINE subdirectory has the following subdirectories:
PLANS (contains management plans and reports that apply to the project as a whole, such as the SQA plan);
GUIDES (contains all guides or manuals which may apply to more than one CSCI;
INTERFACES (contains Interface Requirement Specifications and any other documents that pertain to interfaces between CSCIs); and
TEST (contains PLANS, PROCEDURES, DRIVERS, RESULTS, and REPORTS subdirectories; these contain tests used during the integration of CSCIs or qualification tests for the software system as a whole).
Note: Each subdirectory may contain a subdirectory for each version of the software.
5) At least one software engineering manager reviews the directory structure and the naming and numbering scheme to ensure adequacy in meeting the project’s development needs.
6) The SCM manager documents the completed directory structure, placing it in the Configuration Identification section of the SCMP.
7) For each directory, the SCM manager determines who should have read, write, and other applicable privileges. Normally, the project software manager, SCM manager, and system administrator have full read and write privileges to all files in all directories. The software developers normally have only full read and write privileges to their own CSCI\DEVELOP\user directories; however, the developers may have read access to all the directories. The SCM manager documents these access privileges in the Configuration Identification section of the SCMP.
8) The system administrator, under the supervision of the SCM manager, sets up the directory structure and access restrictions, as documented in the SCMP.
Outputs
The project’s naming and numbering standards, directory structure, and directory-access restrictions, as documented in the Configuration Identification section of the SCMP.
The project’s directory structure, with proper access restrictions in place.