Highley Recommended, Inc.

NAVIGATIONCM PLAN SECTION 3

CM Home
CM Resources
Table of Contents
Introduction
SCM
SCM Activities
CM Milestones
Tools & Training
Support

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.)

Product Items/Subsystem
Modules/Files
Outputs (Object, IMG, EXE, DLL)

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:

%PROJECT%_CHKPNT_%REV#%

Releases to Integration and Verification are of the form:

Vx.yy.zz

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.

  • Required information for Baseline creation:
  • How and when it is created
  • Who authorizes and who verifies it
  • The purpose
  • What goes into it (software and documentation)

3.1.4 Libraries

  • Identification and control mechanisms used
  • Number of libraries and the types
  • Backup and disaster plans and procedures
  • Recovery process for any type of loss
  • Retention policies and procedures
  • What needs to be retained, for who, and for how long
  • How is the information retained (on-line, off-line, media type and format)

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

  • Change reporting documentation
  • Change control flow diagram

3.2.3 Organizations assigned responsibilities for change control

Change Control Board

  • Charter
  • Members
  • Role
  • Procedures
  • Approval mechanisms

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:

  • Progress on projects of interest to Software Engineering
  • Results of audits and other tests
  • All releases and baselines
  • Process and procedural updates
  • Tool upgrades and roll-out plans

Reported Software Metrics:

  • Lines of code
  • Code complexity
  • Code/comment ratios

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:

  • What is in the release
  • Who the release is being provided to and when
  • The media the release is on
  • Any known problems in the release
  • Any known fixes in the release
  • Installation instructions

There are several product release types. The following is an example of some the product release types:

Internal Release This release is only for releasing to internal test organizations such as Validation Engineering or Quality Assurance. This release should not be distributed to the outside vendors, since it may have errors and the functionality of the product is not complete.

Beta Release This release is for testing by internal test organizations as well as for the outside vendors. The purpose of this release is to allow customers to test the product in their environment and help in finding problems which cannot be detected in-house since it is not possible to create every customer's environment.

Release Candidate This release is considered to be a candidate for official product release and all of the known high priority errors have been fixed and the product is near completion. This release is distributed to customers as well as internal test organizations.

Release The official release of the product to customers.

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:

  • Which baseline is it tied to, if applicable
  • Who performs the audit
  • What is audited
  • What is the CM role in the audit, and what are the roles of other organizations in the audit
  • How formal is the audit

The following audits will be performed:

  • Software Build Audit
  • Software Release Audit

3.4.2 All reviews that CM supports; for each provide the following

  • The materials to be reviewed
  • CM responsibility in the review and the responsibilities of other organization

Previous Section          Next Section