THE ACIC CONFIGURATION MANAGEMENT PLAN

9.3 THE ACIC CONFIGURATION MANAGEMENT PLAN

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

1. INTRODUCTION

Omitted

2. CM ENVIRONMENT

         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

3. DIRECTORY STRUCTURE

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.

4. CONFIGURATION ITEMS, NAMING, AND STORAGE

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	Name	Work Area	Review/Test Area	Baseline/Release Area
Project scope document	ScopeDocument.doc			/vss/Scope
Use case catalog	UseCaseCatalog			/vss/Requirements
Screens	Screens			/vss/Requirements
BAR document	BAR			/vss/Requirements
Project plan	ProjectPlan.doc	/Users/<UserName>/ProjectDocs	/Reviews/ProjectDocs	/vss/ProjectMgmt
CM plan	CM Plan.doc	/Users/<UserName>/ProjectDocs/	/Reviews/ProjectDocs	/vss/ProjectDocs
Project schedule	ProjectSchedule.mpp	/Users/<UserName>/ProjectDocs	/Reviews/ProjectDocs	/vss/ProjectMgmt
High-level design document	TAD3.0.doc	/Users/<UserName>/ProjectDocs	/Reviews/ProjectDocs	/vss/HLD
Program specifications	ProgSpec#<n>	/Users/<UserName>/ProgSpecs/	/Reviews/ProgSpecs	/vss/ProgSpecs
Unit test plans	UnitTestPlan#<n>.doc	/Users/<UserName>/TestPlans/	/Reviews/TestPlans/	/vss/TestPlans
Sequence diagrams	<Description>SeqDiag	/Users/<UserName>/ProjectDocs/	/Reviews/ ProjectDocs	/VSS/RoseElements/SequenceDiagrams
Class diagrams	<Description>ClassDiag	/Users/<UserName>/ProjectDocs/	/Reviews/ProjectDocs	/VSS/RoseElements/ClassDiagrams
Activity diagrams	<Description>ActDiag	/users/<UserName>/ProjectDocs/	/Reviews/ProjectDocs	/VSS/RoseElements/ActivityDiagrams
Source code	PackageName.Classname	VAJ Repository	VAJ Repository	VAJ Repository
Integration test plan	IntegrationTestPlan	/Users/ProjectDocs/TestPlans	/Reviews/TestPlans	/vss/TestPlans
Test plans	/UseCase#.tst	/Users/<UserName>/TestPlans/	/Reviews/TestPlans	/vss/TestPlans
Closure report	ClosureReport.doc	/Users/UserName/ProjectDocs/	/Reviews/ProjectDocs	/vss/ProjectDocs

5. VERSION/REVISION NUMBERING

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.

6. MOVEMENT OF CONFIGURATION ITEMS THROUGH THEIR STORAGE AREAS

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?	ChangeRequest.xls
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.

Release

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
HLD	vss/HLD	PL	At the end of high-level design phase

Backup

Storage Area to Be Backed Up	Backup Media	Numbering Scheme	Backup
			Frequency	Responsibility
Itlkec15 /	Tape	As per Infosys stds.	Weekly	System administrator
VAJ repository (ivj.dat of server)	ITLKEC02\\\\ ProjectBackup	mmmddyyyy.dat	Twice a week	CC
VAJ.icx and.ide files	ITLKEC02\\\\Users \\<Username> \\General	mmddyyyy.ide and mmmddyyyy.ic x	Daily	Users

Archival Procedure

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

Configuration Audit

Type of Audit	Frequency
CC audit	Every two weeks
Baseline audit	Once a month
Work product completion	At the end of a milestone
Release	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