The CM plan presented here specifies the CM environment and the directory structure to be followed in the ACIC project. (The CM plan for a different case study is given in my earlier book.5) The ACIC CM plan clarifies that under the project area is a directory structure, controlled through the Visual Source Safe (VSS) tool, where all documents that need to be controlled are kept. Source code files are controlled through the Visual Age for Java (VAJ) tool. Within the VSS directory, the various directories are specified; the names clearly indicate what goes in these directories. The user area, which is uncontrolled, is also specified; there is a directory for each user, and each team member is supposed to follow the directory guidelines in his area. Similarly, the area for reviews is specified; this is the directory where items to be reviewed are kept.

Then the plan lists the configuration items, their names, and their storage locations. Only the controlled configuration items are mentioned here. Items that are not controlled for example, testing results, review results, messages, templates, standards, and so on are omitted; they are stored in their respective directories in the uncontrolled area. For each item, the area where it should be kept when it is being developed is given in the work area. If the item is to be reviewed, the plan states where it should be moved to for review, as well as the baseline area under VSS where it goes after it is approved. In other words, the plan outlines the storage areas for these items as they evolve.

Next, the plan describes how a document moves through these different areas that is, the configuration control process for documents. It is quite straightforward: The user works on the document in the work area. When the document is ready for review, it is moved to its specified review area. If the review does not require any further rework, the document is baselined. The plan does not specify a similar process for code because the methods of VAJ are used.

Access rights for the various areas and VSS are then specified. Because this project had a small team, a relatively liberal access scheme is followed, with all the team members having check-in and check-out access to the controlled area.

Next, the change control process is specified. First, the plan specifies who is responsible for logging change requests, who reviews, and so on. It then gives the change implementation process.

Reconciliation is a major issue in many projects. As mentioned earlier, the need for reconciliation arises when multiple people make changes to a configuration item in parallel. For documents, there is no such need for reconciliation because parallel changes are not envisaged, and VSS has formal check-in and check-out procedures that disallow parallel changes. Reconciliation of source code, however, may be needed. At a class level, the responsibility for reconciliation rests with the owner of the class, who uses VAJ features for this. (If multiple people have made changes to a class, VAJ highlights the differences in the class and methods in the different versions.) At each milestone, or whenever needed, all reconciliation is done for all sources.

Reconciliation may also be needed if some changes are made in parallel at the development site (offshore) as well as the deployment site (onsite). If this happens, again VAJ is used; the differences are identified, and then the changes are merged.

If multiple projects are using some common source code, reconciliation across projects might also be needed. Typically, all projects send their VAJ files to a central coordinator, who reconciles the files and returns them. These reconciled files then become the baseline for each project.

Next, the CM plan specifies the release area and the backup procedures. The release area for source code is the VAJ repository, and source is released at the end of construction milestones. ("Release" here means that reconciliation is finished and that a baseline, which may also be released to the customer, is created.) The high-level design (HLD) is released from the VSS area at the end of the relevant milestone. For backup, the area and frequency are specified. Then the nature and frequency of configuration audits are mentioned, along with the roles and responsibilities of the configuration controller. In this project, the CC is responsible for maintaining the tool, making backups, conducting audits, and helping the team to follow the CM procedures. (The complete CM plan has some additional elements that are omitted here.)

The Configuration Management Plan of the ACIC Project




         Operating system: Windows NT on servers, Windows 98 on PCs

         Other software/tools: MS Project 4.0, Rational Rose, Requisite Pro

         CM Tools: Visual Source Safe (VSS) for documents, and Visual Age for Java (VAJ) for source files


Project area: Itlkec02/ACIC. All directories will be under this.

Controlled Storage Area for Documents: Itlkec02/ACIC/vss. In this controlled area, there are directories such as HLD, ProgSpecs, ProjectDocs, ProjectMgmt, Requirements, Scope, TestPlans, etc.

Source Code: InfosysKEC/C://ivj.dat (file where VAJ keeps the source files).

Uncontrolled Project Area: In addition to the controlled directory for VSS, there are separate directories such as ChangeRequest, ImpacAnalysis, Issues, MilestoneReports, ReviewReports, StandardsAndChecklists, StatusReports, Templates, etc. These directories are uncontrolled.

User Area: Areas for different users will be ACIC/Users/<UserId>. Each user will follow the structure of the controlled area.

Review Area: ACIC/Review. Under this are separate directories such as ProjectDocs, ChangeRequest, TestPlans, etc.


Only the items that are in controlled areas are mentioned. Standard Infosys naming conventions will be used for naming all document and source files.

Configuration Item


Work Area

Review/Test Area

Baseline/Release Area

Project scope document





Use case catalog










BAR document





Project plan





CM plan

CM Plan.doc




Project schedule





High-level design document





Program specifications





Unit test plans





Sequence diagrams



/Reviews/ ProjectDocs


Class diagrams





Activity diagrams





Source code


VAJ Repository

VAJ Repository

VAJ Repository

Integration test plan





Test plans





Closure report






For Software Source Files: The program source files have an automated versioning mechanism. The scratch edition will be 1.0. Any major change in source will be assigned version 1.1, 1.2, etc., and minor changes will have versioning 1.1.1, 1.1.2, etc.

For Documents: The original version will be numbered 0.0a. Subsequent revisions will be numbered 0.0b, 0.0c, etc. The baseline version will be 1.0. Documents may be changed as a result of redesign or customer change requests. New versions created are numbered 1.1, 1.2, etc.


Configuration control process for documents:


Configuration control process for source code: The code is reviewed in VAJ. If any changes are to be made, they are made in the open edition in which the user is working.

Access Rights

User Area: Each user has R/W access to his or her area. The project leader has R/W access to all.

Review Area: All have R/W access.

VSS Area: All have check-in and check-out rights.

Change Control

Where is the change request logged?


Who logs the change request?

Any team members

Who reviews the change request?

Project leader

Who approves the change request?

Project leader or business manager

Workflow for Change Request


Reconciliation Documents

All documents are stored in VSS. Only one check-out at a time is allowed.

Source Code

Onsite/Offshore Reconciliation: Refer to the approach paper on VAJ Setup & Reconciliation.

Interproject Reconciliation: Interproject reconciliation will be undertaken as soon as there is a release.

Intraproject Reconciliation: The class-level reconciliation will be the responsibility of the class owner. Reconciliation dates will be decided in weekly project meetings. VAJ guidelines for reconciliation will be used.


Configuration Item

Release Area

Responsibility for Building the Release and Releasing

When Released

Source Code

VAJ Repository

Workspace Owner

At the end of the milestone analysis




At the end of high-level design phase


Storage Area to Be Backed Up

Backup Media

Numbering Scheme







Itlkec15 /


As per Infosys stds.


System administrator

VAJ repository (ivj.dat of server)

ITLKEC02\\\\ ProjectBackup


Twice a week


VAJ.icx and.ide files

ITLKEC02\\\\Users \\<Username> \\General

mmddyyyy.ide and mmmddyyyy.ic x



Archival Procedure

Archiving will be done by Infosys systems manager using standard procedures.

Configuration Audit

Type of Audit


CC audit

Every two weeks

Baseline audit

Once a month

Work product completion

At the end of a milestone


Before release

Surprise audit

Any time

Responsibilities of Configuration Controller

         CM orientation for project team

         CM tool deployment if applicable

         Configuration item status tracking

         Ensuring backups and archival

         Conducting CM audits as planned

         Generating CM audit reports

         Tracking CM audit discrepancies to closure


Software Project Management in Practice
Linux Annoyances for Geeks: Getting the Most Flexible System in the World Just the Way You Want It
ISBN: 0596008015
EAN: 2147483647
Year: 2005
Pages: 83
Authors: Michael Jang © 2008-2017.
If you may any questions please contact us: