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.

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.

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