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

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:

graphics/09fig01.gif

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

graphics/09fig02.gif

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

 



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

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net