Shell Method™ Software Engineering Process Repository
The identification process takes different approaches based on the class of the configuration item. Evolving items are assigned specific identifiers as described below. Source items are generally handled by the development toolset. Support items are recorded in a special project support items log, while archive items are stored by file type in a specific location.
Evolving items fall into two classes: Documents, and software executables / support files.
Document evolving items are assigned unique identifiers that identify the project and (if applicable) component with which they are associated, along with the current revision level. The identifier consists of one to three parts separated by hyphens in the format ACRONYM, ACRONYM-CLASS or ACRONYM-COMPONENT-CLASS.
Evolving items that are “umbrella” items (not specific to a single project), such as policies, process descriptions, and guidance are identified with a single acronym, generally derived from the title and/or class of the item. An example is the identifier for the SCMP.
Evolving items that are project-specific, but not associated with a project component use a two-part identifier composed of the project acronym and an acronym derived from the title and/or class of the item. For example, the SPMP for a project named Basic Order Tracking System (BOTS) would carry an identifier of BOTS-SPMP.
Evolving items that are project-specific and associated with a project component use a three-part identifier composed of the project acronym, the component acronym, and an acronym derived from the title and/or class of the item. For example the requirements document for the BOTS customer component would carry an identifier of BOTS-CUST-SRD.
The version level of each item is maintained as a separate identifier. This allows the primary identifier to be used as part of a file name or URL for access to the most current version without requiring changes to all referencing items. The version level is maintained as a numeric identifier with two components:
Version number, which appears to the left of the decimal, and
Revision number, which appears to the right of the decimal.
The version number changes only when the core architecture of the item changes, as when an item is completely overhauled, with substantial internal changes. In this case, version 1.1 would become version 2.0.
The revision number changes when existing content is changed, but the overall structure and flow of the item remains the same. The normal sequence of revision is 1.0, 1.1, 1.2, and so on.
Software executables and support files are generally identified by name and version number, such as “Main DB v1.1a.” The naming convention for each software evolving item is defined by the development team. The version numbering scheme consists of three components:
Version number, which appears to the left of the decimal,
Revision number, which appears to the right of the decimal, and
Update level, consisting of a single trailing character.
The version number changes only when the core architecture of the software item changes, as when moving from one level of the development tool to another, when an application is completely overhauled, or the user interface changes fundamentally. In this case, version 1.1a would become version 2.0.
The revision number is updated when new features, functionality, or other content are added or significantly changed. In the normal case, the core architecture or user interface have been extended or limited in some manner. The most common reason for changing the revision number is when adding a new module or other functionality to the software item. The normal sequence of revision is 1.0, 1.1, 1.2 and so on.
The update character is appended or incremented when the only change to the software item is to correct one or more defects, without the addition of any new functionality. Version 1.1 of the software would become v1.1a, 1.1b, and so on. This updating is over-ridden when a combination revision, involving bug fixes and new feature additions, is performed. In such a case, the software revision number is incremented and any update indicator is dropped, as in v1.1b to v1.2.
As described in previously, source item identification is managed by the selected configuration management tool for this project, which is identified in the project SPMP. Source item CM tools are vendor supplied software; refer to the vendor documentation for a description of source item identification and management.
Support items are identified by common product name and the version number range necessary to support successful development or production operations. For example, a text editor may be upgraded during the course of the project from version 2.1 to version 2.2a; the version range for this configuration item would show 2.1 - 2.2a. This is important for after-the-fact retrieval of archived project information; documentation and source items are best handled with known compatible versions of their parent applications.
Archive items are generally miscellaneous support documents and records of communication that are stored for later reference. These items are stored as described in the project SPMP. Each item is identified by file name and modification date as returned by the operating system. In the event an identically named item is already present in a target subdirectory, the new document file name will be appended with a sequential number to prevent naming conflicts.