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