Software Configuration Management Plan
Revision: 1.4
Date: 2006/05/10 15:00:00

Contents

1  Introduction

1.1  Revision History

1.2  Acronyms

SCMP

Software Configuration Management Plan. This document.

IEEE

Institute of Electrical and Electronics Engineers.

CVS

Concurrent Versioning System.

CI

Configuration Item.

CL

Configuration Leader.

CM

Configuration Management.

PM

Project Manager.

STD

Software Test Document.

SPMP

Software Project Management Plan.

SQAP

Software Quality Assurance Plan.

1.3  Terms

Artifact:

A final or interim product of the project.

Repository:

Directory tree where all CI's that are under CVS control are kept. Normally, the repository is never accessed directly, but only through cvs commands. Using e.g.

cvs co ProjectName

a user can build a local working copy of the repository version.

Project Leader:

Synonym for Project Manager in this project (see [Smi01]).

2  SCM Management

2.1  Organization

2.2  SCM Responsibilities

Configuration Leader

Organizing and managing CM, in collaboration with the PM and the rest of the team.

1. Maintain the SCMP (this document).
2. Ensure uninterrupted availability of CM tool.
3. Ensure availability of repository, subject to the policies and procedures of section 2.3, 3.2 and 3.3.
4. Further responsibilities can be found in section 2.3 and 3.2.

Project Leader

 

1. Backup for CL.
2. CI identification (see section 3.1).
3. Approving CI changes (section 3.2).

Engineers

abide by the published CM rules (section 2.3, 3.2).

2.3  Policies, procedures

1. CVS will be used as the sole CM tool.
2. Every engineer will only use cvs commands from within his own login on the server, so that all changes on CI's can be attributed.
3. Every engineer will maintain a complete version of the project repository in his home directory.

3  SCM activities

3.1  Configuration Identification

3.1.1  CIs Identification

1. The PM decides on all CIs. Engineers wishing to propose a new CI shall secure her agreement by email. If no reply is received within 24hrs, the CL shall have the authority to accept or reject the item.
2. Only files that cannot be easily and automatically reconstructed can be CIs. E.g. .tex files are usually CIs while .dvi or .ps files are not.
3. The repository will be kept in wilma:/home/se0/cvsroot/xyz

3.1.2  Naming CIs

The structure of the repository is shown below.

xyz/

The root directory. Autotools files such as configure.in, libtool etc. are kept in this directory.

plans/

CIs pertaining to the SCMP, SPMP, SQAP.

timesheets/

CIs pertaining to time sheets, one per engineer.

minutes/

Minutes of meetings. These files have a name of the form yyyy-mm-dd.txt.

requirements/

CIs pertaining to requirements, e.g. SRS.

doc/

All documents, possibly automatically generated, pertaining to the design (except for .h files which are stored in the code base.

xyz/

Code base, including unit test source code and data. Further structure to be decided. Note that the use of autotools strongly suggests the name of this directory.

test/

All documents pertaining to testing, except unit testing, e.g. STD.

In addition, each directory contains

1. A Makefile.am whose default target rebuilds all derived items in the subtree of that directory.
2. A README file that briefly describes the content of the directory.

The conventions to be used to name different types of CIs are listed in table 1.

TODO:Naming conventions for test CIs

3.1.3  Acquiring CIs

Engineers shall use the following commands to

• Initially install their copy of the repository:

  export CVSROOT=:ext:/home/se1/cvsrooot cvs co xyz

  export CVS_RSH=ssh

  cvs co xyz

• Update their copy of the repository:

  cvs update -d

3.2  Configuration Control

TODO:This should probably be refined. Perhaps the notion of an ``owner'' of CI should be introduced.

3.2.1  Requesting Changes

• If an engineer wants to change a CI, he shall seek permission from the PM. The codebase CIs that correspond to his own task form an exception:
  • For interface (.h) files, he must obtain agreement (by email) from all engineers that are responsible for code that uses the interface.
  • For implementation (.C) files, he does not need permission. He will however send email to all users of the code, describing the effect of the changes (e.g. ``bug #10 fixed'').
• En engineer who intends to modify an item shall use the ``cvs edit'' command.
• The CL shall configure cvs (using ``cvs watch'') such that all team members received email notification of cvs edit events. requesting changes approving changes implementing changes

3.2.2  Implementing Changes

No change to the codebase may be done without a successful (regression) unit test of the relevant units.

3.3  Configuration Status

• The status of any configuration item is available to all engineers using the cvs status command.
• Every week, a ``weekly build'' will be performed by the CL. This will be accomplished by executing the ``make check'' command in the root directory of the project. If the build succeeds, the CL will tag the state of all CIs. Tags are strings of the form ``I_N'' where I is the number of the iteration and N is a sequence number within the iteration. All team members will receive email with the status of the build and an indication where it failed, if appropriate.

3.4  Configuration Audit & Review

• The CL will promptly report on any changes in CM policies and procedures.
• At each meeting, the CL will report on the status of the CM system.
• At the end of the first iteration (see [Smi01]), there will be a session devoted to CM process improvement.

3.5  Interface Control

TODO:Describe in some detail.

4  SCM Schedules

5  SCM Resources

• learning cvs
• learning viewcvs
• writing this document
• setting up the repository

• regular updates/reviews and status reports,
• advice to engineers, and
• problem solving.

References

[Smi01]

John Smith. Xyz software project management plan. july 2001.