Configuration Management Plan

From ZenWiki

Jump to: navigation, search

Contents

REVISION HISTORY

Date Author(s) Changes Version
04/22/07 Session Initial draft creation 1.0


REVIEW AND APPROVAL

Reviewer Version Reviewed Approval Date


INTRODUCTION

Purpose

The purpose of this configuration management plan (CMP) is to provide an overview of the development team, its activities, and overall tasks that will ensure that:

  1. all work products received or generated by the project are adequately documented, stored and managed;
  2. changes to those work products are controlled;
  3. change processing and implementation status are recorded and reported;
  4. compliance with specific requirements is verified.


Scope

This document describes the CMP approach for management of the requirements, development process, and testing baselines of the ZEN Tool:

  • Changes to the requirements are reflected in the SRS after undergoing a Change Management Process, and the baseline is the responsibility of the Customer Relations Manager.
  • Changes to the development process are reflected in the Zen Development Method and the baseline is the responsibility of the Team Lead.
  • Changes to the testing baseline is reflected in the Quality Assurance Plan and the baseline is the responsibility of the Quality Assurance Manager.


Acronyms

Accronym Representation
CM Configuration Management
CMP Configuration Management Plan
MSIT Master of Science in Information Technology
QA Quality Attribute
QAP Quality Assurance Plan
QAW Quality Attribute Workshop
SCM Software Configuration Management
SRS Software Requirements Specification
ZEN specialiZed Engagement Navigation


Definitions

Baseline: A formal, approved document or product serving as a departure point for future releases.

References

Purpose Link
Outline of a CMP http://www.sei.cmu.edu/legacy/scm/papers/CM_Plans/CMPlans.AppendixB.html
Sample CMP http://www.osd.noaa.gov/class/docs/1001_Config_Management_Plan.doc
CMP best practices guide http://www.bestpractices.cahwnet.gov/ProjectOfficeFunctions.aspx?fid=4&pid=3


Tailoring

The CMP is open to tailoring by the ZEN Team, that will consult and agree on changes on a majority vote basis.

SOFTWARE CONFIGURATION MANAGEMENT

SCM organization

The ZEN Tool Project is sponsored by the Integration of Software Intensive Systems (ISIS) initiative at the Software Engineering Institute (SEI). The intention of the project is to automate a portion of the Service-Oriented Migration and Reuse Technique (SMART) that helps organizations analyze legacy systems to determine whether their functionality, or subsets of it, can be reasonably exposed as services in a Service-Oriented Architecture (SOA). The portion that needs to be automated is the data collection process guided by the Service Migration Interview Guide (SMIG). The process is currently manual and time-consuming. With the tool support, SEI expects to see some fundamental improvement on efficiency and quality when they conduct SMART engagements.

The primary client from the SEI is Grace A. Lewis, and the secondary client (also from the SEI) is Felix Bachmann.

The ZEN Tool is being developed by the ZEN Team which is composed of the following members:


The project has assigned to it two mentors from the SEI:



SCM responsibilities

The ZEN Team, on a majority rule basis, will have the following responsibilities:

  • Review all CM changes proposed and determine which to implement.
  • Perform document and code reviews to verify compliance with the CM Plan.


The following responsibilities are added to the ZEN Team roles:

  • Team Lead:
    • Assign ownership of CM changes, with an implementation date, to team members.
    • Ensure action is taken on CM change in a timely fashion.


In addition to ZEN Team roles, the following responsibilities are particularly pertinent to the ZEN Team's SCM, and will be added to team roles at the discretion of the Team Lead:

  • Software Configuration Manager: responsible for tracking software components, and building and promoting software releases.


Additional responsibilities may be added as the team sees fit.

SOFTWARE CONFIGURATION MANAGEMENT ACTIVITIES

Configuration Identification

Specification Identification

Labeling and numbering scheme for documents and files
Documents: Documents are stored either in the SVN repository tool or directly on the wiki. The labeling and naming conventions that will be used are described in the Version Control Guidelines.

Code: Code files are stored in the SVN repository tool. The labeling and naming conventions that will be used are described in the Coding Standards.

Relating code files to documents
The code files, which implement classes that are part of a module, are related to the Architecture document according to the detailed architecture design for each module component described in the architecture.

Entering Controlled Status
All code files, as part of the code base, immediately enter controlled status upon creation, and their modification is ruled by the development process described in the Quality Assurance Plan.
Documents enter controlled status if the ZEN Team, by majority voting, decides to have the modification process of these documents controlled.

Change Control Form Identification

Project Baselines

The following table describes the current project baselines:

Baseline Purpose Requirements Create by Created on Must Verify Verified on
SOW Defines the approach the scope of the project, and the approach that the ZEN Team will employ to meet that scope. It serves as a contract between the ZEN Team and the client. Online SOW guideline and sample SOW's from previous MSE teams. Lung-San (Allen) Hsu 11/09/06 ZEN Team, mentors, and client 12/15/06
SRS Details all of the requirements of the system, and ranks their relative importance. QAW Marc Novakouski Fall 2006 ZEN Team, mentors, and client TBD
Operations Proposal Proposes the processes to be followed by the ZEN Team during the development of the system. Samples from previous MSE teams. Session Mwamufiya 11/02/06 ZEN Team, mentors 12/15/06
Problem Definition Proposal Describes the requirement elicitation methods employed by the ZEN Team on the project. Samples from previous MSE teams. Marc Novakouski 10/31/06 ZEN Team, mentors 12/15/06
Planning Proposal Details the methods and techniques which will be used by the ZEN Team to plan for the project. Samples from previous MSE teams. Somakala Jagannathan 10/12/06 ZEN Team, mentors 12/15/06
Design Proposal Outlines the design approached used by the ZEN Team to ensure that the architecture satisfies the main architectural drivers. Samples from previous MSE teams. Sajjad Mustehsan 11/09/06 ZEN Team, mentors TBD
Implementation Proposal Describes the implementation approaches used by the ZEN Team to ensure the source code quality with constant verification, and increase productivity with a highly automated development environment. Samples from previous MSE teams. Lung-San (Allen) Hsu 10/10/06 ZEN Team, mentors TBD
Code base Implements the functionality of the system. Eclipse, SVN, Ant, PMD, and other software packages described in more detail in the Quality Assurance Plan. ZEN Team TBD ZEN Team, client (for system version releases) TBD


Library

The two libraries/repositories used are the wiki and SVN.

Identification and control mechanisms
Both repositories authenticate the user before any changes can be made, and thus provide a measure of traceability for each modification of a document or file. The wiki is accessible online with the proper authentication, and SVN, that is hosted on the ZEN Team virtual development server, keeps logs of user activities.

Backup
In addition to identifying users, both repositories maintain all previous versions of the documents and files for comparison. The wiki data is administered by the SCS, which frequently backs up their server data on remote drives, so the system can be brought back online from these backups in case of a crash. The data on SVN will be backed up daily to a file on the virtual development server, before the project undergoes a build and PMD check. We will backup the SVN data onto 2 external hard drives in order to improve our ability to recover from a virtual server crash.

Disaster recovery
In case of a disaster in which all wiki data is lost, the Support Engineer will contact administrators of the wiki to have our data brought back online from their backup resources.
In case of a disaster in which all SVN data is lost, the Support Engineer will rebuild the data from the latest backup file that has been created. And if the backup is also corrupted, then the Support Engineer will coordinate a team effort to rebuild the code base with the files that each member has maintained on their own development platforms.
In case of a disaster in which the virtual server crashes, the Support Engineer will research the cause of the failure, and work with SCS technical admins in order to bring the system back up in a timely manner.

Retention policies and procedures
All baseline documents and files will be retained throughout the development of the system. At the end of the development period, the code base will also be handed over when the system is migrated to the client's environment. By the end of the Fall 2007 semester, control of the wiki and its contents will be handed over to the MSE program, and the ZEN Team will determine what to do with the SVN data around that time.

Configuration Control

Procedures for changing baselines

For all baselines except the code base, the following procedure will be followed:

  • A team member identifies or is made aware of an issue that requires a change in a baseline (process, definition change, architectural modification,...).
  • The team member makes the rest of the team aware of the issue.
  • The issue is debated (via email or in person if a meeting is called) to determine its relevance and impact to the project.
  • A decision is made on a majority basis on whether to proceed with changing the affected baseline.
  • If the decision is to proceed, then the person responsible for maintaining that baseline makes the appropriate changes, and reports it to the Team Lead.
  • The Team Lead verifies that the requested changes were made, and makes sure that they are done in a timely manner (per his/her discretion).

For the code base, the following procedure will be followed:

  • A team member develops code that he wants to check into SVN.
  • The team member builds the code to make sure that it compiles without any errors and pertinent warnings.
  • The team member runs PMD on his local code and fixes any pertinent violations described by the rulesets that we have chosen to use for our static analysis.
  • The team member checks in the code and merges his changes into SVN. The team member is responsible of merging his changes with the latest version of the code file in SVN, and of undergoing this merger when SVN warns that the code had been changed since the last check out.


Tracking change requests

The Configuration Manager will keep track of all change requests to baselines other than the code base. He will track the following (on the wiki) for each change request:

  • Description
  • Source
  • Request Date
  • Iteration Date (i.e. I4.W3 for week 3 of iteration 4)
  • Decision (Yes/No)
  • Comments
  • Change Owner
  • Implementation Date


Document revisions

Both document and code file repositories track change histories, but in addition to this, every wiki baseline document shall have a revision history section at the top of the document.

Configuration Status Accounting

Storage, handling and release of project media

All project media will be maintained on the wiki or SVN, and any material release to outside parties will require the ZEN Team's approval on a majority vote basis.

Types of information to be reported

The Team Lead will keep track of the project's progress with the use of a variety of metrics; these are defined in the Planning Proposal. The raw information will be maintained on the Team Lead's development computer (at his/her discretion), and the reports generated from this data will be made available on the wiki for the ZEN Team and mentors to access.

The Chief Scientist will own and maintain the following:

  • bug repository
  • release content:
    • modules
    • issues
    • fixes
  • TBD

This data will be maintained on the wiki (except for the bug data that will be maintained in the bug repository), and available to the ZEN Team.

Reports to be produced

Team progress report: This report will track the progress of the ZEN Team. It is described in the Planning Proposal. The Team Lead will own and compile these reports on a weekly basis for the ZEN Team and the mentors as the primary audience.

Release report: This report will be created for each release of the software to the client. The Chief Scientist will own and compile this report for each release, and the client will be the main audience. The report will include:

  • the modules that are included in the release
  • the known issues with the release (if applicable)
  • the fixes from previous releases (if applicable)



Release process

Incremental software releases to the client will be undertaken in the following manner:

  • At the beginning of a release cycle, the Chief Scientist will work with the Team Lead to compile a list of modules that should be included in the given release.
  • During the course of the release cycle, the Chief Scientist will monitor the progress of the modules, and advise whether the original module estimation should be revised.
  • At the end of the release cycle, the Chief Scientist will include the list of modules that have been completed (along with the known issues and fixes) as part of his release report.
  • The Support Engineer will provide a compilation of the software in digital format (zip file or CD, to be determined by the client) with clear installation instructions to the Customer Relations Manager, who will in turn provide it to the client.

The release schedule is described in the milestones section.

Change management status accounting

The Configuration Manager will keep track of all changes to the baseline documents other than code, and will information about the contents of and issues in each product release. This information will be maintained on the wiki for easy access by the ZEN Team and the mentors.

Configuration Auditing (Reviews)

The following reviews will be conducted:

Review Name Item Reviewed Description Owner(s) Related Milestone Deadline
Baseline SOW SOW The SOW will be reviewed to make sure that:
  • All relevant scope changes are reflected in the document.
  • Mentors have reviewed all changes.
  • The customer has signed the latest version.
Customer Relations Manager, TBD Baseline May 21st, 2007
Baseline SRS SRS The SRS will be reviewed to make sure that:
  • All approved customer requests are reflected in the document.
  • All "must-have" requirements have been included in the scope of the project.
  • There are no duplicate requirements.
  • All requirement clarification requests have been presented to the client.
  • All client requirement clarifications have been updated in the document.
Customer Relations Manager, TBD Baseline May 21st, 2007
Baseline Operations Proposal Operations Proposal The Operations Proposal will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • All roles are current and relevant to the team. (View the ZDM roles)
  • The mentors have reviewed and approved any changes made.
TBD Baseline May 21st, 2007
Baseline Problem Definition Proposal Problem Definition Proposal The Problem Definition Proposal will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • The mentors have reviewed and approved any changes made.
TBD Baseline May 21st, 2007
Baseline Planning Proposal Planning Proposal The Planning Proposal will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • The mentors have reviewed and approved any changes made.
TBD Baseline May 21st, 2007
Baseline Design Proposal Design Proposal The Design Proposal will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • The mentors have reviewed and approved any changes made.
TBD Baseline May 21st, 2007
Baseline Implementation Proposal Implementation Proposal The Implementation Proposal will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • The mentors have reviewed and approved any changes made.
TBD Baseline May 21st, 2007
Baseline QA Plan Quality Assurance Plan The QA Plan will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • The mentors have reviewed and approved any changes made.
Quality Assurance Manager Baseline May 21st, 2007
Baseline CM Plan Configuration Management Plan The CM Plan will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • The mentors have reviewed and approved any changes made.
Configuration Manager Baseline May 21st, 2007
First Review SOW SOW The SOW will be reviewed to make sure that:
  • All relevant scope changes are reflected in the document.
  • Mentors have reviewed all changes.
  • The customer has signed the latest version.
Customer Relations Manager, TBD First Review June 15th, 2007
First Review SRS SRS The SRS will be reviewed to make sure that:
  • All approved customer requests are reflected in the document.
  • All "must-have" requirements have been included in the scope of the project.
  • There are no duplicate requirements.
  • All requirement clarification requests have been presented to the client.
  • All client requirement clarifications have been updated in the document.
Customer Relations Manager, TBD First Review June 15th, 2007
First Review Operations Proposal Operations Proposal The Operations Proposal will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • All roles are current and relevant to the team. (View the ZDM roles)
  • The mentors have reviewed and approved any changes made.
TBD First Review June 15th, 2007
First Review Problem Definition Proposal Problem Definition Proposal The Problem Definition Proposal will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • The mentors have reviewed and approved any changes made.
TBD First Review June 15th, 2007
First Review Planning Proposal Planning Proposal The Planning Proposal will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • The mentors have reviewed and approved any changes made.
TBD First Review June 15th, 2007
First Review Design Proposal Design Proposal The Design Proposal will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • The mentors have reviewed and approved any changes made.
TBD First Review June 15th, 2007
First Review Implementation Proposal Implementation Proposal The Implementation Proposal will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • The mentors have reviewed and approved any changes made.
TBD First Review June 15th, 2007
First Review QA Plan Quality Assurance Plan The QA Plan will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • The mentors have reviewed and approved any changes made.
Quality Assurance Manager First Review June 15th, 2007
First Review CM Plan Configuration Management Plan The CM Plan will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • The mentors have reviewed and approved any changes made.
Configuration Manager First Review June 15th, 2007
Second Review SOW SOW The SOW will be reviewed to make sure that:
  • All relevant scope changes are reflected in the document.
  • Mentors have reviewed all changes.
  • The customer has signed the latest version.
Customer Relations Manager, TBD Second Review July 13th, 2007
Second Review SRS SRS The SRS will be reviewed to make sure that:
  • All approved customer requests are reflected in the document.
  • All "must-have" requirements have been included in the scope of the project.
  • There are no duplicate requirements.
  • All requirement clarification requests have been presented to the client.
  • All client requirement clarifications have been updated in the document.
Customer Relations Manager, TBD Second Review July 13th, 2007
Second Review Operations Proposal Operations Proposal The Operations Proposal will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • All roles are current and relevant to the team. (View the ZDM roles)
  • The mentors have reviewed and approved any changes made.
TBD Second Review July 13th, 2007
Second Review Problem Definition Proposal Problem Definition Proposal The Problem Definition Proposal will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • The mentors have reviewed and approved any changes made.
TBD Second Review July 13th, 2007
Second Review Planning Proposal Planning Proposal The Planning Proposal will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • The mentors have reviewed and approved any changes made.
TBD Second Review July 13th, 2007
Second Review Design Proposal Design Proposal The Design Proposal will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • The mentors have reviewed and approved any changes made.
TBD Second Review July 13th, 2007
Second Review Implementation Proposal Implementation Proposal The Implementation Proposal will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • The mentors have reviewed and approved any changes made.
TBD Second Review July 13th, 2007
Second Review QA Plan Quality Assurance Plan The QA Plan will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • The mentors have reviewed and approved any changes made.
Quality Assurance Manager Second Review July 13th, 2007
Second Review CM Plan Configuration Management Plan The CM Plan will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • The mentors have reviewed and approved any changes made.
Configuration Manager Second Review July 13th, 2007
Final Review SOW SOW The SOW will be reviewed to make sure that:
  • All relevant scope changes are reflected in the document.
  • Mentors have reviewed all changes.
  • The customer has signed the latest version.
Customer Relations Manager, TBD Final Review August 3rd, 2007
Final Review SRS SRS The SRS will be reviewed to make sure that:
  • All approved customer requests are reflected in the document.
  • All "must-have" requirements have been included in the scope of the project.
  • There are no duplicate requirements.
  • All requirement clarification requests have been presented to the client.
  • All client requirement clarifications have been updated in the document.
Customer Relations Manager, TBD Final Review August 3rd, 2007
Final Review Operations Proposal Operations Proposal The Operations Proposal will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • All roles are current and relevant to the team. (View the ZDM roles)
  • The mentors have reviewed and approved any changes made.
TBD Final Review August 3rd, 2007
Final Review Problem Definition Proposal Problem Definition Proposal The Problem Definition Proposal will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • The mentors have reviewed and approved any changes made.
TBD Final Review August 3rd, 2007
Final Review Planning Proposal Planning Proposal The Planning Proposal will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • The mentors have reviewed and approved any changes made.
TBD Final Review August 3rd, 2007
Final Review Design Proposal Design Proposal The Design Proposal will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • The mentors have reviewed and approved any changes made.
TBD Final Review August 3rd, 2007
Final Review Implementation Proposal Implementation Proposal The Implementation Proposal will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • The mentors have reviewed and approved any changes made.
TBD Final Review August 3rd, 2007
Final Review QA Plan Quality Assurance Plan The QA Plan will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • The mentors have reviewed and approved any changes made.
Quality Assurance Manager Final Review August 3rd, 2007
Final Review CM Plan Configuration Management Plan The CM Plan will be reviewed to make sure that:
  • All processes are current and relevant to the team.
  • The mentors have reviewed and approved any changes made.
Configuration Manager Final Review August 3rd, 2007


Build Management

The build process and the tools required are defined in the Quality Assurance Plan

CM MILESTONES

All project milestones, including CM milestones are maintained in the ZEN Team's Project Plan.

TRAINING

Training has already been performed for the following technologies:

  • Eclipse RCP
  • JBoss

Additional training needs will be determined during a thorough scoping exercise at the beginning of the Summer 2007 term. Any required additional training will follow the training process defined in the Operations Proposal.

SUBCONTRACTOR/VENDOR SUPPORT

A subcontracting proposal to develop report templates was presented to MSIT students during Fall 2006, but there were no volunteers to take on the project.

REFERENCES

Retrieved from "http://msesrv1d.mse.cs.cmu.edu/wiki/index.php/Configuration_Management_Plan"
Personal tools