Cmm Configuration Management - DOC by wnm97593

VIEWS: 16 PAGES: 28

More Info
									Carnegie Mellon University             CMU-MSE-CHARLATANS-CMP–V 0.1
School of Computer Science                                 Fall 2002
Master of Software Engineering




                                   The Charlatans Team

                         Configuration Management Plan
                                                   Version 0.1
                                                   Nov 5, 2002



                                                    April Navarro
                                                       Dawei Gu
                                           Lalit Mohansingh Jina
                                                       Matt Bass
                                                      Wei Zhang
Document Information

Title                Configuration Management Plan
Author(s)            Wei Zhang
Reviewer(s)          All Team Members
Team name            The Charlatans
Team members         April Navarro, Dawei Gu, Lalit Mohansingh Jina, Matt Bass, Wei Zhang
Project mentors      Cliff Huff, Grace Lewis
Type of report       Process
Software used        MS Word 2002
Templates used       Charlatans CMP Document Template
Style guide          Software Engineering Institute Style Guide




Charlatans  CMP version 0.1                                                                1
Document Revisions

Rev.   Date         Author(s)   Comment
0.1    11/05/2002   Wei Zhang   Initial draft.




Charlatans  CMP version 0.1                     2
Document Approvals
The following signatures are required for approval of this document. Note, however, that since the MSE
Studio role assignments will roll over during the course of the project, the respective names should be
updated as needed.




___________________________________________                            ______________________
April Navarro, CMU MSE Program                                         Date
Development Manager (Fall 2002)


___________________________________________                            ______________________
Dawei Gu, CMU MSE Program                                              Date
Planning Manager (Fall 2002)


___________________________________________                            ______________________
Lalit Mohansingh Jina, CMU MSE Program                                 Date
Process and QA Manager (Fall 2002)


___________________________________________                            ______________________
Matt Bass, CMU MSE Program                                             Date
Team Lead (Fall 2002)


___________________________________________                            ______________________
Wei Zhang, CMU MSE Program                                             Date
Contact and Support Manager (Fall 2002)


___________________________________________                            ______________________
Cliff Huff, SEI Technical Staff                                        Date
Studio Mentor


___________________________________________                            ______________________
Grace Lewis, SEI Technical Staff                                       Date
Studio Mentor




Charlatans  CMP version 0.1                                                                              3
Table of Contents

Document Information .................................................................................................. 1
Document Revisions ..................................................................................................... 2
Document Approvals .................................................................................................... 3
Table of Contents .......................................................................................................... 4
List of Scripts ................................................................................................................ 5
Acronyms and Terms .................................................................................................... 6
1         Purpose ................................................................................................................ 7
2         Objectives............................................................................................................. 8
3      Roles and Definitions .......................................................................................... 9
    3.1 The Role of the Support Manager ...................................................................... 10
    3.2 The Role of the Change Control Board .............................................................. 10
       3.2.1 Membership ...................................................................................................................10
       3.2.2 Voting ............................................................................................................................11
4         Process Control ................................................................................................. 12
5      Tools ................................................................................................................... 13
    5.1 Visual SourceSafe 6.0 ....................................................................................... 13
    5.2 Change Control Database in Microsoft Excel ..................................................... 13
    5.3 Backup and Recovery........................................................................................ 13
6         Configuration Items ........................................................................................... 15
7         Schedule for Baselining Configuration Items .................................................. 16
8         Change Control Processes ............................................................................... 18
    8.1    Identifying a Configuration Item ......................................................................... 18
    8.2    Viewing a Configuration Item ............................................................................. 19
    8.3    Getting a Local Copy Configuration Item ........................................................... 19
    8.4    Checking Out a File ........................................................................................... 20
    8.5    Checking In a File .............................................................................................. 21
    8.6    Canceling Changes to a Checked Out Configuration Item ................................. 22
    8.7    Requesting a Change ........................................................................................ 22
9         Conclusion ......................................................................................................... 24
10        References ......................................................................................................... 25
Appendix A – Sample of Version Control Information in CCB ................................. 26
Appendix B – Sample of Request Change Status Information in CCB .................... 27




Charlatans  CMP version 0.1                                                                                                                         4
List of Scripts
Script 8-1   Identifying a Configuration Item .................................................................... 18
Script 8-2   Viewing a Configuration Item........................................................................ 19
Script 8-3   Getting a Local Copy Configuration Item ...................................................... 20
Script 8-4   Checking Out a File ...................................................................................... 20
Script 8-5   Checking In a File ........................................................................................ 21
Script 8-6   Canceling Changes to a Checked Out Configuration Item ............................ 22
Script 8-7   Requesting a Change................................................................................... 23




Charlatans  CMP version 0.1                                                                                                  5
Acronyms and Terms

          CCB             Change Control Board
          CM              Configuration Management
          CMM             Capability Maturity Model
          CMP             Configuration Management Plan
          CMU             Carnegie Mellon University
          MSE             Master in Software Engineering
          QA              Quality Assurance
          SCM             Software Configuration Management
          SDS             Software Design Specification
          SEI             Software Engineering Institute
          SOW             Statement of Work
          SPMP            Software Project Management Plan
          SRS             Software Requirements Specification
          VSS             Microsoft Visual SourceSafe
          WCCA            Wrist Camera Companion Application




Charlatans  CMP version 0.1                                    6
1      Purpose

In order to ensure that change is well managed by the Charlatans team in the process of
developing its studio project, a plan has been drafted in accordance with the MSE Studio
Configuration Management Policy, Configuration Management Plans from previous
MSE teams [CHARLATANS] [FRED], the Capability Maturity Model (CMM)
Configuration Management Key Practice Area [CMM], and other CM plans that are
publicly available.

This document is intended to describe the plan and to serve as a reference for team
members in the execution of the change management process. It outlines the objectives of
the Configuration Management Plan, defines the roles and responsibilities, describes
what tools are used to accomplish CM activities, details what work products are to be
placed under change control, and describes the processes by which work products are
controlled.




Charlatans  CMP version 0.1                                                               7
2       Objectives

The objectives [CMM] of the Charlatans Configuration Management Plan are:

       To ensure that software configuration management activities are planned.
       To ensure that selected software work products are identified, controlled, and
        available.
       To ensure that changes to identified software work products are controlled.
       To ensure that affected groups and individuals are informed of status and content
        of software baseline.




Charlatans  CMP version 0.1                                                                8
3      Roles and Definitions

The following roles are involved in the change management process:

          Role                                             Definition
    Support Manager         The individual responsible for managing the Change Management
                            activities of the Charlatans team.
    Change Control          A group responsible for reviewing change requests for approval or
    Board (CCB)             disapproval. For Charlatans it is the whole team, and necessary
                            changes are discussed during the weekly team meetings.
    Client                  The agent representing the client's interests in a particular
                            configuration item.
    Originator              The individual with whom a change request originates and the person
                            informed when the change request is closed-out or deferred to the
                            Change Control Board.
    Quality Assurance       The individual who oversees the inspection of configuration items
    Specialist              and reviews change requests.


The following definitions introduce terminology used throughout this document:

            Work product – a document or other object that is produced as a result of
             work done for the Studio project.

            Configuration item – a work product that requires configuration control. A
             configuration item may be a single piece of work or a group of files that
             together form the basis for a single software program or document. There is a
             one-to-one correspondence between configuration items and modules in the
             archive. A question to ask when determining whether files should be grouped
             into a single configuration item is whether or not they should eventually be
             baselined together.

            Version – a unique number automatically assigned to each revision of a
             configuration item when it is placed under Configuration Management.

            Baseline – a revision of a configuration item that is considered complete with
             respect to a certain set of requirements. A baseline is a version for which any
             proposed change must managed.

            Tag – a character string that may be associated with a particular revision of a
             configuration item. A tag is usually applied to a configuration item to mark it
             as having a particular property such as having been identified to be ready for
             Quality Assurance review. A tag should consist of the username of the person
             applying the tag followed by the date that the tag is attached.


Charlatans  CMP version 0.1                                                                   9
              Label – is a specific form of a tag that is used to identify the revisions of a
               configuration item that represent a baseline. The label should include a
               sequential number based on the last label of module.

              Academic week – a week in which university classes are in session.



3.1       The Role of the Support Manager

The Support Manager is responsible for defining and managing the Configuration
Management Plan. This includes managing the repositories that store items under
configuration control and the tools that support the processes associated with change
management. The emphasis of the Support Manager's role is on protecting the integrity of
important versions of studio artifacts in an efficient and effective manner.

The responsibilities of the Support Manager are itemized to include:

          Ownership of the Charlatans Change Control Plan.
          Leadership of the Charlatans Change Control Board.
          Liaison to the Studio Process and Support Specialists.

The Support Manager shall provide mechanisms for the Charlatans team to control
changes to its configuration items by performing the following activities:

          Providing each member with a copy of the Studio Configuration Management
           Policy and the Charlatans Configuration Management Plan.
          Acting as a resource for access to change management related references.
          Ensuring that each Studio member has access to the necessary repositories by
           working with the Studio Support Specialist.



3.2       The Role of the Change Control Board

Once a work product has been has been basedlines, it must be monitored to avoid
unauthorized modification. The Change Control Board is formed of all members of the
Charlatans team. Its mission is to govern post-baseline changes of the team’s
configuration items.



3.2.1 Membership




Charlatans  CMP version 0.1                                                                     10
The Support Manager shall chair the Charlatans team Change Control Board. All
members of the Charlatans team are members of CCB.

In addition to the team members, the team mentors will be invited to sit on meetings to
advise the team regarding issues of change management.



3.2.2 Voting

In order to approve any change, all members of the Change Control Board must be
present. After discussion, each of the members shall vote on the change being
considered. A majority (defined as 3 or more) is required for a change to be approved.
Members may abstain if they feel that they have a conflict of interest. In the event that a
tie occurs, the Support Manager will cast the tie-breaking vote.




Charlatans  CMP version 0.1                                                                  11
4       Process Control

In order to monitor the effectiveness of the Charlatans Change Control Plan, the Support
Manager is responsible for keeping track of CM related problems. Any causes for
concern should be brought to the team meeting where the team will identify changes to
the process that will eliminate current or potential problems.

According to the experience of past Studio teams, the following are the most common
CM failures that apply to the Charlatans project:

1. Visual SourceSafe database corruption. The Visual SourceSafe (VSS) database
   becomes corrupted very easily.

2. Branch management. After a product is released, usually the organization keeps
   working on the next release and therefore a branch is created for the ongoing work.
   The failure is that bugs are fixed and checked in the latest release, which is right
   because it is the release that the customer is using, but the fix is never made in the
   new branch. Therefore, the new release has a bug that had already been found and
   fixed in the previous release.

3. Version Control. Two or more people should not be making modifications to a
   configuration item at the same time. The tool allows only one person to check out a
   configuration item and that same person has to check it in. Two recommendations
   stem from this point:

           A person checks out a configuration item, modifies it, creates a new release,
            and does not inform the Support Manager or team members of this change.

           A person obtains the latest version of a configuration item for viewing. The
            author of that configuration item checks it out, makes changes, and checks it
            back in. The person that obtained the configuration item for viewing is now
            working with an outdated item.

4. Failure to recover a past version of a configuration item. There are several reasons for
   this:

       A change to a configuration item is not considered a new release and later on,
        when something from that "past" release is needed, it cannot be found.

       An item that should have been identified as a configuration item was never put
        under configuration management.

       A configuration item was checked out and never checked back in.




Charlatans  CMP version 0.1                                                                  12
5      Tools

Change management will require the use of an online tool for version control. The
following section describes the tool to be used, the technical support required, and the
physical resources needed to maintain the configuration management environment.



5.1   Visual SourceSafe 6.0

In accordance with the MSE Studio guidelines, the Charlatans project will use Microsoft
Visual SourceSafe 6.0 for configuration management of all configuration items. This
software is available from \\dogbert.mse.cs.cmu.edu, the MSE server. Each team member
should have the client software, Microsoft Visual SourceSafe Explorer, installed on
his/her machine with the database set to \\Dogbert\SourceSafe. Information on installing
and setting up Visual SourceSafe Explorer is available from the Studio Support
Specialist. All Charlatans team members should password protect their SourceSafe
accounts and should be sure they have Read/Add/Delete access to the Charlatans project
directory. Access problems should be directed to the Studio Support Specialist.



5.2   Change Control Database in Microsoft Excel

In addition to SourceSafe, a change control database will be maintained in Microsoft
Excel. It will contain the information listed in Appendix A and Appendix B.

The change control database is to be maintained by the Support Manager and should be
accessible to all team members as a reference.



5.3   Backup and Recovery

Because the Visual SourceSafe and the Change Control database reside on the Dogbert
server, they are backed up each time Dogbert is backed up. The Charlatans team will take
no additional backup measures at this time. Recovery will be done according to the
recovery procedures defined by the Studio Policy.

As a final safeguard against information loss, a hard copy should be generated of each
baseline of a configuration item. All hardcopies will be kept in a binder, which will be
stored in the team’s library. The Support Manager will be responsible for maintaining
the binder and ensuring that team members keep it consistent with respect to the contents
of the SourceSafe database.



Charlatans  CMP version 0.1                                                                13
For the source code, the Development Manager will be responsible for keeping a copy of
every baselined build.




Charlatans  CMP version 0.1                                                             14
6       Configuration Items

Having established where configuration items will reside, it is now necessary to outline
which of the Charlatans team’s work products should be configuration items. Work
products that require change control include, but are not limited to, the following:

       Wrist Camera Companion Application RFP
       Team Process Scripts
       Checklists
       Development Strategy
       Statement of Work (SOW)
       Software Requirements Specification (SRS)
       Use case document (UCD)
       Risk Management Plan
       Configuration Management Plan
       Software Project Management Plan (SPMP)
       Design Standard
       Software Design Specification (SDS)
       Coding Standard
       Source Code
       Quality Assurance Plan
       Test Reports
       Document Templates

In addition to these configuration items, other items may be placed under change control
at the discretion of the team. If changes to a work product have the potential to impact
the development schedule or plan, that work product must be placed under change
control. Also, any work product that is to be edited by more than one member of the
team must be placed under change control to ensure that team members are aware of each
other’s work. Examples of work products that do not fall under change control are team
meeting agendas, minutes, and correspondence.




Charlatans  CMP version 0.1                                                               15
7      Schedule for Baselining Configuration Items

A software baseline is a set of software items formally designated and fixed at a specific
time during the software life cycle. The term is also used to refer to a particular version of
a software item that has been agreed upon. Baselining an item provides a checkpoint to
which development can be backed out in the event that something unexpected occurs
with the current version of the item.

Commonly used baselines are the functional, allocated, developmental, and product
baselines. The functional baseline corresponds to the reviewed system requirements. The
allocated baseline corresponds to the reviewed software requirements specification and
software interface requirements specification. The developmental baseline represents the
evolving software configuration at selected times during the software life cycle. The
product baseline corresponds to the completed software product delivered for system
integration. The baselines to be used for a given project, along with their associated levels
of authority needed for change approval, are typically identified in the SCMP.

Configuration items are to be baselined according to the following schedule.


          Configuration item                        Baseline Schedule
          Wrist Camera Companion                    After agreement of both client
          Application RFP                           and team
          Team Process Scripts                      After team acceptance
          Checklists                                After team acceptance
          Development Strategy                      After team acceptance
          Statement of Work (SOW)                   After client acceptance
          Software Requirements Specification       After inspection and update
          (SRS)
          Use case document (UCD)                   After inspection and update
          Risk Management Plan                      After inspection and update
          Configuration Management Plan             After inspection and update
          Software Project Management Plan          After team acceptance
          (SPMP)
          Design Standard                           After team acceptance
          Software Design Specification (SDS)       After inspection and update
          Coding Standard                           After team acceptance
          Source Code                               After inspection and unit test
          Quality Assurance Plan                    After inspection and update
          Test Reports                              After test has been completed
          Document Templates                        After team acceptance

In general, an internal configuration item should be baselined after it has successfully
completed the Quality Assurance process as defined for the particular item. Successful


Charlatans  CMP version 0.1                                                                     16
completion of Quality Assurance occurs when the team Quality Assurance Manager
approves the item. Externally deliverable items should be baselined after Quality
Assurance completion and again after the client has approved the current version.




Charlatans  CMP version 0.1                                                        17
8          Change Control Processes

This section provides process scripts that outline the entry criteria, inputs, activities, and
outputs of each of the processes that implement the Charlatans team change control plan.
It is a tailored process with focus on software configuration identification and software
configuration control. It is expected that these scripts will be used by all team members in
executing the change control process.



8.1       Identifying a Configuration Item

Identifying a configuration item results in the placement of that item into the SourceSafe
project folder and the addition of an entry in the database. The module may exist for an
unlimited period of time and have multiple revisions before it is baselined. In fact, it may
never be baselined.

Script 8-1 Identifying a Configuration Item

 Entry Criteria

 None

 Inputs

 The owner of the proposed configuration item must provide an Identification Request via e-
 mail, with the following information, to the Support Manager.

           Name of work product owner
           Role of work product owner
           Proposed name for the configuration item
           Description of the proposed configuration item, including changes with respect to the
            previous version.

 Activities

 1. The owner submits the Identification Request to the Support Manager.
 2. If there is no doubt about the need for change control on the item, approval is sent to the
    owner.
 3. Otherwise, the team is notified of the request and a discussion item is added to the next
    team meeting agenda.
 4. A vote is taken at the next team meeting based on the discussion.
 5. If approval is granted, the Support Manager adds the item, under the name given, to the
    SourceSafe project folder and creates a new entry in the Change Control database. When
    adding the item to the SourceSafe project, the following rules should be followed:

           If the item is a document, the name for the document should follow the convention
            Charlatans <ItemID> #-#. If it is a draft document, the name should be Charlatans
            <ItemID> #-# (Draft #).
           If the item is source code, a folder should be created in the Source project with the



Charlatans  CMP version 0.1                                                                        18
          name WCCA #.#.#, and all the files that form part of that version should be included in
          the folder.

 Outputs

 Identified configuration items.

 Exit Criteria

 A module for the new configuration item has been created. The change control database has
 been updated with information about the item, including the data, description, and owner.




8.2    Viewing a Configuration Item

Viewing a configuration item is used to obtain the latest version of a configuration item
without making any changes.

Script 8-2 Viewing a Configuration Item

 Entry Criteria

 None.

 Inputs

 None.

 Activities

 1.   Open Visual SourceSafe Explorer.
 2.   Find the file in the Charlatans project structure and click on that file to select it.
 3.   Right click on the selected item and choose View from the menu.
 4.   When finished viewing the item, exit the application used to view the item or close the file
      within that application.

 Outputs

 None.

 Exit Criteria

 The file has been closed.




8.3    Getting a Local Copy Configuration Item

The following defines the process for getting a local copy of a configuration item without
checking the item out.



Charlatans  CMP version 0.1                                                                         19
Script 8-3 Getting a Local Copy Configuration Item

 Entry Criteria

 None.

 Inputs

 None.

 Activities

 1. Open Visual SourceSafe Explorer.
 2. Find the file in the Charlatans project structure and click on that file to select it.
 3. Right click on the selected item and choose Get Latest Version from the menu.

 Outputs

 None.

 Exit Criteria

 A read-only copy of the latest version of the file exists on the user’s local machine.




8.4   Checking Out a File

Editing a file that has been baselined in Visual SourceSafe constitutes changing a
baselined item. This is not to be done without authorization, which can only be granted
by the Charlatans Change Control Board.

Editing a file stored in Visual SourceSafe is done using a Check Out / Check In scheme.
Checking Out a file places a copy of that file in the working directory on the user’s
machine. Other team members cannot access the file being edited while it is checked out
to prevent accidental overwriting of changes. Other team members can see who has the
file checked out by looking at the working directory field in the Visual SourceSafe
Explorer file list. The working directory of the person who checked the file out will
appear here. While a file is checked out from SourceSafe, all changes are made to the
copy of the file that is stored locally. Changes are only committed when the file is
checked back in to SourceSafe. Checking In a changed file is described in process 8.5.

Script 8-4 Checking Out a File

 Entry Criteria

 If the change to be made is non-trivial, the Change Control Board must approve a Change
 Request.

 Inputs




Charlatans  CMP version 0.1                                                                 20
 A description of the change to be made, including an impact analysis of the change.

 Activities

 1.   Make sure that a working directory is defined.
 2.   Open Visual SourceSafe Explorer.
 3.   Find the file in the Charlatans project structure and click on that file to select it.
 4.   From the SourceSafe menu, select Check Out, or right click on the selected item and
      choose Check Out from the menu.

 Outputs

 A local copy of the file on the user’s machine.

 Exit Criteria

 The file is checked out in SourceSafe, meaning that no other team member may access that
 file until it is checked back in.




8.5    Checking In a File

Checking In a file creates a new version of that file in the SourceSafe database. It is
equivalent to committing the changes you have made to the item. The version that
existed before the changes were made remains accessible through the file history, but the
latest version is changed to the most recently checked in.

Script 8-5 Checking In a File

 Entry Criteria

 A Checked Out copy of the file exists and the user is the one who checked it out originally.

 Inputs

 A description of the changes that have been made to the item.

 Activities

 1. Close the application used to edit the item.
 2. Make sure that the working directory is defined.
 3. Open Visual SourceSafe Explorer.
 4. Find the file in the Charlatans project structure and click on that file to select it.
 5. From the SourceSafe menu, select Check In, or right click on the item and choose Check
    In from the menu.
 6. Create a Change Description in the Change Control database to describe the change.
 7. Notify all team members that the change has been completed and direct them to the
    Change Description in the database for more information.

 Outputs

 A Change Description in the Change Control database.



Charlatans  CMP version 0.1                                                                    21
 Exit Criteria

 The file is properly checked in to SourceSafe and the Change Description is complete.




8.6    Canceling Changes to a Checked Out Configuration Item

The following defines the process for canceling the changes you have made to a
configuration item.

Script 8-6 Canceling Changes to a Checked Out Configuration Item

 Entry Criteria

 A Checked Out copy of the file exists and the user is the one who checked it out originally.

 Inputs

 None.

 Activities

 1.   Close the application used to edit the item.
 2.   Make sure that the working directory is defined.
 3.   Open Visual SourceSafe Explorer.
 4.   Find the file in the Charlatans project structure and click on that file to select it.
 5.   From the SourceSafe menu, select Undo Check Out, or right click on the item and choose
      Undo Check Out from the menu.

 Outputs

 None.

 Exit Criteria

 The file is no longer checked out of SourceSafe and no changes were committed.



8.7    Requesting a Change

When a change to a baselined product is thought to be necessary, a Change Request must
be filed with the Change Control Board. The following defines the procedure to be
executed in order to make such a request. This procedure is intended to allow timely
processing of change requests while allowing each member of the team to voice an
opinion on the proposal. The originator of the change should attend the Change Control
Board meeting to discuss the proposed change.




Charlatans  CMP version 0.1                                                                    22
Script 8-7 Requesting a Change

 Entry Criteria

 A change has been identified as needed by some member of the team and the originator of the
 change has performed an impact analysis to evaluate the impact of the change.

 Inputs

 A Change Request, including the following information [INEEL GIS]:
     Name and version of the configuration item with the problem
     Originator's name, phone number, and organization
     Date of request
     Indication of urgency
     Need for the change
     Description of the change

 Activities

 1. The owner of the product item e-mails the Change Request to the Support Manager.
 2. If the Support Manager deems the change trivial, he/she notifies the team members of the
     request via e-mail and authorizes the change.
 3. If the Support Manager deems the change non-trivial, he/she notifies the team members of
     the request via e-mail so they can provide their input on the proposed change.
 4. The Support Manager works with the Change Control Board members and the change
     owner to set a time for a Change Control Board meeting (within one academic week of
     receiving the request).
 5. All Change Control Board members read the discussion before the Change Control Board
     meeting.
 6. The Change Control Board members meet and review the request to determine its
     importance and impact.
 7. A decision is made about authorizing the change.
 8. The Support Manager documents the outcome of the meeting as part of the minutes.
 9. The Support Manager notifies the client, if necessary, of the Change Control Board’s
     decision.
 10. If approved, the requester may begin making the requested change.
 11. The Planning Manager, based on the impact identified in the Change Control Board
     meeting updates the plan and schedule as necessary.

 Outputs

 A completed outcome of the Change Request in the meeting minutes.

 Exit Criteria

 The change has been deemed trivial, non-trivial and approved, or non-trivial and disapproved.
 The team members have been notified of the outcome and the necessary documentation has
 been entered into the Change Control database.




Charlatans  CMP version 0.1                                                                     23
9      Conclusion

This document outlines the configuration management plan to be used by the Charlatans
team as part of its 2002-2003 MSE Studio project. The team members, in order to
manage post-baseline change and avoid costly schedule slips, must follow all policies and
processes detailed here. The CMP is intended to be a living document and can be
modified, with the approval of the team, if the current strategy proves ineffective.
Questions or concerns about this document, or about change management in general,
should be directed to the current Support Manager.




Charlatans  CMP version 0.1                                                                24
10    References

[SEITR93]     Nadine M. Bounds, Susan A. Dart, "Configuration Management (CM)
              Plans: The Beginning to Your CM Solution", SEI Technical Report,
              1993.
[CMM]         Capability and Maturity Model, Configuration Management Key Process
              Area, SEI.
[TSPi]        Watts S. Humphrey, “Introduction to the Team Software Process”, 1999.
[PUMA]        MSE Studio – PUMA Configuration Management Plan, 2001.
[FRED]        MSE Studio – FRED Configuration Management Plan, 2001.
[MSEPH]       MSE Studio Process Handbook, version 2002.3.0.
[SQA]         “Software Quality Assurance” Chapter 31 – Software Configuration
              Management.




Charlatans  CMP version 0.1                                                          25
     Appendix A – Sample of Version Control Information in CCB

Item Versio Draft Draft  Date        Owner Description of Change Item Name                Source Safe
     n            Number                                                                  Location
SOW 0-1     Y           1 10/10/2001 VG    Draft given to team         Charlatans SOW 0-1 DOC\Manageme
                                           members for initial review. (Draft 1)          nt\SOW




     Charlatans  CMP version 0.1                                                                    26
    Appendix B – Sample of Request Change Status Information in
    CCB

Item Version Date       Requested Priority Need for       Description of           Status
                        by                 Change         Change
SPMP       1 11/16/2001 DG        Low      Typo in last   His last name is         Change approved
                                           name           mispelled in the cover   without the
                                                          page                     intervantion of the
                                                                                   CMB for it is trivial.
                                                                                   Will be changed in
                                                                                   the next release.




    Charlatans  CMP version 0.1                                                                        27

								
To top