|NAVIGATION||CM PLAN SECTION 3|
3. SOFTWARE CONFIGURATION MANAGEMENT ACTIVITIES
3.1 Configuration Identification
3.1.1 Specification Identification
Configuration Item Selection and Definition
Size and scope of each Configuration Item (CI) must take into consideration the impacts of CI interfaces, host/target systems (location), language dependencies, testing issues, documentation concerns, design constraints, life cycle cost and schedule, change control, intended usage, support equipment/software (off the shelf software) and classification, prior to selection. Inappropriate CIs can adversely affect cost, schedule, development, design, test and overall performance.
The goal is to establish practical configuration item identification that can be employed throughout the engineering or development cycle with a high degree of confidence that no significant re-definition will be necessary.
Each project is partitioned into one or more subsystems. Small projects may consist of a single subsystem. Larger projects should be split along natural boundaries. Each product deliverable within a single project is a candidate for being a separate subsystem. Significantly shared subsystems may be best configured as independent projects. To that extent, project(s) consists of several sub-systems, namely: Modem Controller Assembly, Transmitter Receiver Assembly, Indoor Management Processor, Subscriber Unit, and Host Configuration and Control Software. This project will also include Test Software deliverable that will be used by our development, verification, field trial, and service groups, as well as other internally developed software for test or manufacturing purposes.
Subsystems are further divided into modules, and modules consist of individual objects (function, variable and other declarations). A "C" module sometimes has two parts: a ".C" file and the corresponding ".H" file.
This results in the following component hierarchy:
Product (Product A, Product B, etc.)
SCM ignores individual outputs (object files), and normally tracks changes only at the module/file level and above.
Labeling and numbering scheme for documents and files
Files and documents will be labeled upon baseline builds, I&V release and Customer release. Upon I&V and customer release, the object files for that release will be put under configuration control and labeled with the I&V or customer release label.
Individual versions of the files will be tracked automatically by the software configuration management tool (see tools section).
How identification between documents and files relate
Description of identification tracking scheme
Software baselines are labeled with informal labels, generally of the convention:
Releases to Integration and Verification are of the form:
Where "x" is the number of major releases, "yy" is the number of minor releases, and "zz" is the number of bug fix releases.
This identification scheme addresses versions and releases as required.
3.1.2 Change Control Form Identification
Numbering scheme for each of the forms used
ECOs have a numbering scheme assigned by the System Change Analyst which is therefore outside the scope of this document.
3.1.3 Project Baselines
Identify various baselines for the project
Baselines are established to designate significant milestones during the engineering and development cycle, as well as to document CI requirements, design and applicable processes. Multiple baselines are defined to capture the engineering process during critical phases. The files included in a baseline are all of the CIs as earlier described.
3.2 Configuration Control
The Configuration Management tool accounts for all changes (problems or enhancements) to baselined configuration items. The primary objectives of configuration control are to maintain integrity and consistency of each baseline established and prevents unauthorized changes to baselined software.
3.2.1 Procedures for changing baselines
There are three classifications of baselines, informal checkpoints, integration and verification, and release.
For informal baselines the Configuration Manager must notified of the change. The change must be tested and built by the developer, then built by the Configuration Manager to ensure that the build process is not broken by the change. The Configuration Manager then baselines the configuration with a "checkpoint" label.
Integration and verification baselines must be approved by the team leads and the Software Engineering Manager.
3.2.2 Procedures for processing change requests and approvals-change classification scheme
3.2.3 Organizations assigned responsibilities for change control
Change Control Board
3.2.4 Level of control
Software Baselines require the approval of the configuration manager, a description of the change, and a completed successful build that incorporates the change.
Software Release to I&V requires consensus among the Software Development Team leads and the approval of the Software Engineering Manager, as well as detailed descriptions of change, and a complete tested build that incorporates the change.
Software Release to customer requires Change Control Board approval, detailed description of changes and test reports, a review of the integration and compatibility matrix, and completion of required customer documentation.
3.2.5 Handling Document Revisions
Documents in the Software Development team are identified as Configuration Items and are controlled in the same way as source code. If a document is required to be released company-wide, or if the document is a process detail that requires approval from the change control board, the document will be assigned a part number and undergo review and release process (ECO).
3.2.6 Automated tools used to perform change control
The tools used to perform Change Control are "Agile" and "PR Tracker."
3.3 Configuration Status Accounting
3.3.1 Storage, handling and release of project media
The files held in Software Configuration Management will be completely backed up on a weekly basis with incremental backups held more frequently during the week. The ability to recover from backups will be tested on a periodic basis.
Media is released according to the CD Requirements and Procedure (PN xxxx-xxxx-xx) document. "Hard" copies of each software project release CD will be archived and stored for a period of three years.
3.3.2 Report Contents
Reported items to Software Engineering Manager:
Reported Software Metrics:
3.3.3 Reporting Structure
Software Configuration Management is responsible for a weekly status report to the Software Engineering Manager. SCM is also responsible to provide change reports to Integration and Validation with each new I&V release.
Future Implementation: SCM will provide software metrics reports as well as other relevant QA information to company management.
3.3.4 Release process
Software releases will be from the baseline, and released object files will be held in configuration control. All releases from Software Engineering to Integration and Validation must provide Change Notes that contain the following information:
There are several product release types. The following is an example of some the product release types:
3.3.5 Occurrences of Document and Change Management Status Accounting
Document and Change Management status accounting is the responsibility of the Change Control Board and the System Change Management analyst. Software Configuration Management will work closely with the System Change Management Analyst to ensure that reviews of change requests and ECOs are complete and accurate.
3.4 Configuration Auditing
3.4.1 Number of audits to be done and when they will be done
In addition to internal peer review (conducted by Software Developers and Change Control Board) and formal review (conducted by Software Engineering Manager) for all SCM software and documentation, formal audits are conducted by SCM. The main goal of audits is to provide visibility into effectiveness of SCM practices and procedures. For all audits the following information will be provided:
The following audits will be performed:
3.4.2 All reviews that CM supports; for each provide the following