Docstoc

Carnegie Mellon University

Document Sample
Carnegie Mellon University Powered By Docstoc
					                                 MSE studio 2003-2004



Carnegie Mellon University                              CMU-MSE-Team C3PO-SCMP
School of Computer Science                                            Spring 2004
Master of Software Engineering




                                                         Team C3PO

   Software Configuration Management Plan V0.9
                                                              June 08, 2004




                                                               Kanat Abirov
                                                               Denise Varga
                                                          Minori Micha Ikeda
                                                            Hisashi Yoshida
                                   MSE studio 2003-2004



Document Revisions

 Revision     Date             Author(s)                            Comments
0.1         02/27/04   Kanat Abirov               Document creation
0.9         05/25/04   Denise Varga               Update per peer review
0.9         06/08/04   Denise Varga               Final updates for version 1.0, but still need to
                                                  update flowcharts when Visio is available and
                                                  need information on package names.
                                                      MSE studio 2003-2004



                                                 Table of Contents


1      Introduction ................................................................................................................. 5
    1.1      Purpose................................................................................................................ 5
    1.2      Scope ................................................................................................................... 5
    1.3      Applicable Documents ........................................................................................ 5
       1.3.1      Reference Documents ................................................................................. 5
       1.3.2      Parent Document ......................................................................................... 5
2      SCM Organization ...................................................................................................... 6
    2.1      SCM Manager ..................................................................................................... 6
    2.2      Team Lead .......................................................................................................... 6
    2.3      Process Manager ................................................................................................. 6
    2.4      Development Manager ........................................................................................ 7
3      Configuration Management Tools .............................................................................. 8
    3.1      Software .............................................................................................................. 8
    3.2      Hardware and Operating System ........................................................................ 8
4      Software Configuration Management Activities ........................................................ 9
    4.1      Configuration Identification................................................................................ 9
       4.1.1      Project Documentation Identification ......................................................... 9
       4.1.2      Code Identification.................................................................................... 10
       4.1.3      Support Software Identification ................................................................ 10
    4.2      Baselines ........................................................................................................... 10
       4.2.1      Requirements Baseline.............................................................................. 10
       4.2.2      Architecture Baseline (informal) .............................................................. 11
       4.2.3      Increment 1 Baseline................................................................................. 11
       4.2.4      Final Baseline............................................................................................ 11
    4.3      Configuration Control Process .......................................................................... 12
       4.3.1      Configuration Development Process ........................................................ 12
       4.3.2      Change Request Process ........................................................................... 14
       4.3.3      Configuration Status Accounting.............................................................. 16
    4.4      Audits and Reviews .......................................................................................... 16
       4.4.1      Functional Configuration Audit (FCA) .................................................... 16
       4.4.2      Physical Configuration Audit (PCA) ........................................................ 16
       4.4.3      Reviews ..................................................................................................... 16
    4.5      Release Process ................................................................................................. 17
5      Web Update Policy ................................................................................................... 18
    5.1      Purpose of the Website ..................................................................................... 18
    5.2      Updates ............................................................................................................. 18
       5.2.1      Weekly Updates ........................................................................................ 18
       5.2.2      Updates on Demand .................................................................................. 18
    5.3      Update Notifications ......................................................................................... 19
    5.4      File Name Conventions..................................................................................... 19
6      GLOSSARY ............................................................................................................. 20
    6.1      Acronym List .................................................................................................... 20
    6.2      Definition of Terms........................................................................................... 20
MSE studio 2003-2004
                                    MSE studio 2003-2004




1 Introduction
This Software Configuration Management Plan (SCMP) describes the software
configuration management (SCM) activities to be performed in support of the Non-
Intrusive Rationale Capture (NIRC) system being developed by team C3PO. Refer to the
C3PO Software Project Management Plan for a complete project description.

1.1 Purpose
Defined herein are the software configuration management requirements and procedures
necessary to support the C3PO activity. The plan describes the methodology for
establishing configuration identification, change control, status accounting, and
performing configuration audits during the development of the software configuration
items.

1.2 Scope
The SCMP applies to all C3PO software and associated documentation including, but not
limited to: plans, requirements and design specifications, user scenarios, diagrams, source
code, test reports, user guides, and support software. Configuration management shall
apply to all phases of the product life cycle.

1.3 Applicable Documents
1.3.1 Reference Documents
The standards and documents listed here will be considered when applying this plan. The
latest revisions apply to the following:
 ANSI/IEEE Std 729-1983, IEEE Standard Glossary of Software Engineering
    Terminology
 ANSI/IEEE Std 828-1983, IEEE Standard for Software Configuration Management
    Plan
 ANSI/IEEE Std 1042-1987, IEEE Guide to Software Configuration Management

1.3.2 Parent Document
C3PO Software Project Management Plan (C3PO_SPMP)
                                   MSE studio 2003-2004




2 SCM Organization
Configuration management is the responsibility of all team C3PO members. The SCM
Manager facilitates the interaction among team members to coordinate change processes
and controls in a timely and comprehensive manner.

2.1 SCM Manager
The SCM manager's primary responsibility is the development, implementation, and
maintenance of this SCMP. These responsibilities include:
 Establish methodology for configuration identification, configuration control and
   status accounting
 Participate in reviews and audits
 Manage the change control process
 Install the SCM tool
 Maintain and customize the SCM tool
 Execute standard software backup procedures
 Provide user/client set-up and assistance
 Distribute C3PO products
 Produce status accounting reports
 Assist team lead in generating releases
 Generate Version Description Documents (VDD)
 Generate software system builds
 Maintain and update C3PO website

2.2 Team Lead
SCM responsibilities for Team Lead include:
 Approve base-lining of development products (defined in section 3.3.2)
 Review appropriate change request (CR) dispositions (defined in section 3.3.2)
 Develop and release project work products in accordance with the CM requirements
  of this plan
 Assign CR assessment/resolution to appropriate team member(s)
 Assess CR impacts and provide recommended actions
 Generate releases
 Define project specific CM implementation details in the Software Project
  Management Plan
 Participate in reviews and audits
 Provide copies of the Mentor Meeting Agenda and Mentor Meeting Minutes to the
  SCM manager
 Make sure the client liaison provides copies of the Client Meeting Agenda and Client
  Meeting minutes to the SCM manager

2.3 Process Manager
SCM responsibilities for Process Manager include:
 Manage configuration audits
                                    MSE studio 2003-2004



   Ensure projects adhere to requirements of this plan
   Participate in reviews and audits

2.4 Development Manager
SCM responsibilities for Development Manager include:
 Adhere to procedures defined in this plan for controlling, changing, and developing
  software artifacts
 Prepare and submit change requests
 Evaluate change requests
 Implement changes
 Participate in reviews and audits
                                   MSE studio 2003-2004




3 Configuration Management Tools
The following configuration of software and hardware will be used to implement
configuration management for team C3PO.


3.1 Software
We will use Tortoise CVS version 1.6.2 software for tracking documents and source
code. This is built with CVS version: Concurrent Versions System (CVSNT) 2.0.11
(client/server). A server version of the software will run on a PC in the Cave. Each team
member will install the client version of the software on their PCs and configure it to
work with the CVS server. The following configuration options must be set:

CVSROOT = :sspi:userid@msepc10.sp.cs.cmu.edu:e:/cvsrepo/test
Protocol: Windows authentication (:sppi:)
Server: msepc10.sp.cs.cmu.edu
Repository Folder: e:/cvsrepo/test
User name: userid


3.2 Hardware and Operating System
Tortoise CVS will be run on one of the PCs in the Cave in the C3PO work area. This is a
standard Windows PC. The operating system under which it will be run is Windows XP
Professional Edition. We chose to install CVS under the Windows operating system
since our target development system is a Windows PC. This should provide maximum
compatibility between file formats and hopefully avoid operating system
incompatibilities.
                                    MSE studio 2003-2004




4 Software Configuration Management Activities
4.1 Configuration Identification
All products produced during the software life cycle such as documents, system
architecture, test procedures and results, change requests, analysis results, and code shall
be configuration controlled. All software entities, the software and associated
documentation, shall be uniquely identified by the combination of the full pathname and
filename (Filename standards are defined in Section 5.4). In addition, a history of
baselines, revisions, and build status will be maintained for each software entity. All
components of a baseline shall contain a label identifying the baseline and release to
which the component belongs.

4.1.1 Project Documentation Identification
4.1.1.1   Document Name
Each document will be assigned a unique name by its owner. The naming scheme will
consist of the team name and an underscore (_) followed by the initials that identify the
document. For example, the Software Requirements Specification of team C3PO would
have the document name C3PO_SRS. Documents that have historically been identified
with initials such as the Software Project Management Plan (SPMP) will retain those
initials; for example, C3PO_SPMP. This name will appear in the header on the
document’s title page with the underscore (_) replaced by a dash (-) (for consistency with
existing documents).

When a team member makes changes to a document, they must first check the document
out of CVS. After changes have been made to the document, the team member checks
the document back into CVS. If someone else has updated the document since that team
member checked it out, CVS will attempt to merge the new document with the previous
changes. CVS retains all previous versions of the document, so one can compare changes
from one version to another, or revert to an earlier version if need be.

For additional information on change process refer to 4.3.

4.1.1.2 Revision Numbers
A revision number identifies changes that have been made to the document since its
initial release and may correspond to changes for a particular software build or release.
The initial release of a document will be identified as V1.0. Numbers will be used to
track revisions, beginning with 1 and proceeding through 9, and if necessary, continue
from 1.0 through 9.9. The revision number will go on the cover page as well as in the
header, under the document number. The revision date will also go under the revision
number.

Since CVS maintains revision numbers for its document files, the filenames in CVS for
documents will not contain revision information. This will be stored in the CVS records
and can be accessed via the CVS command: cvs history filename
                                    MSE studio 2003-2004



4.1.2 Code Identification
All developed code will be organized into Java “packages”. The Java package name will
begin with “edu.cmu.c3po.nirc.XXX”, where “XXX” is the programmer-defined name of
the specific code module or “package”. This is consistent with standard Eclipse plug-in
conventions (see www.eclipse.org ). Code will be checked into CVS upon initial creation
and CVS will maintain version and history information.

The following directory structure will be used for storing software artifacts:
 e:\cvsrepo\test                             (cvs repository)
       C3POProduction                        (cvs module)
              src                            (source directory)
                edu.cmu.c3po.nirc.XXX (Eclipse project)
              bin                            (binary code)
              lib                            (library directory, includes speechkit.jar)
              test                           (unit test source code directory, JUnit)
              icons                          (icons and images)
              build.properties               (Eclipse file)
              plugin.xml                     (Eclipse file)
              build.xml                      (ANT build file)

4.1.3 Support Software Identification
All support software used in the software development, such as operating systems,
compilers, documentation tool, software configuration management tool, object modeling
tool, etc., are identified by the combination of the name and version number of the
product.

4.2 Baselines
Each phase of the life cycle establishes a baseline. Table 1, Mapping of C3PO Life Cycle
Phases to Baselines, illustrates the example products, life cycle phase, and product status
values for the project.

The collection of products in a baseline defines a measurable milestone. The Team Lead,
Process Manager, and the SCM Manager determine the baselines and products associated
with each. Formal change control procedures must be followed to make any change to a
baseline. The current configuration identification is the current baseline plus approved
changes applied to the baseline. Refer to the C3PO SPMP and C3PO SRE for the
specification of the products and reviews needed for each phase. The following baselines
will be produced by team C3PO. Note that the Architecture baseline is an informal
baseline and will not be under formal configuration management.

4.2.1 Requirements Baseline
The requirements baseline is identified by the review and approval of the C3PO Software
Requirements Specification. Part of this approval is sign-off by the customer, mentors,
and team members. After this baseline is established, any changes to the requirements
must be done by formal review of requirements changes and revision to the SRS. At this
time, the SRS is under formal configuration control.
                                                 MSE studio 2003-2004



4.2.2 Architecture Baseline (informal)
This baseline will contain the results of architecture and early design activities. It will
also contain the Test Plan. None of these documents will be signed off, and the
architecture and design will continue to be refined as a result of early development
activities. For this reason, this is considered an informal baseline.

4.2.3 Increment 1 Baseline
The increment 1 baseline is identified by the review and approval of the following:
source code, test procedures and reports, version description documentation, and user's
guide. This is the baseline that will be used to perform usability testing.

4.2.4 Final Baseline
The C3PO deliverable software and associated documentation are promoted to the
production baseline after successful completion of the final acceptance reviews and
configuration audits. This baseline will include changes as a result of usability testing,
but fixes from system and performance testing, and the final features that were not
included in increment 1.


Table 1. Mapping of C3PO Life Cycle Phases and Baselines



       Example Configurable Items                   Life Cycle Phase                            Baseline

Documentation - Software Requirements            Requirements Definition   Requirements Analysis (established at successful
Specification, Operations Concept Document,      & Analysis                completion of Software Requirements Review)
Statement of Work and Software Project
Management Plan


Documentation – Software Requirements            Design and Architecture   Architecture (informal)
Specification, Operations Concept Document,
Software Architecture Document, Software Test
Plan


Documentation - Updates to previous documents,   Development and Test      Increment 1
Usability Test Plan , User Guide, Programmer's   (Phase 1)
Guide, Version Description Document

Software - Source & Object Code, Eclipse plug-
ins


Documentation - Updates to previous documents,   Development and Test      Final Increment
Usability Report, User Guide, Programmer's       (Phase 2)
Guide, Version Description Document

Software - Source & Object Code, Eclipse plug-
ins
                                    MSE studio 2003-2004




4.3 Configuration Control Process
Configuration control and change control are applied to all software entities, the software
and associated documentation. As software is imported or generated within the confines
of the software configuration management tool, control becomes a more formalized
process, eventually requiring change requests.

4.3.1 Configuration Development Process
Managing a software entity as it evolves through the entire life cycle involves: creating
and refining the configurable item by progressing through the various development steps,
updating the status, implementing changes, establishing baselines, promoting to the next
life cycle phase, and generating a release of the product. The configuration development
process defines the overall sequence of steps taken when establishing baselines that result
in the final deliverable.

Once software entities have been released, an approved change request is required before
any changes can be made to the entity. The document configuration control steps are
shown in Figure 1.
                                      MSE studio 2003-2004




     Team member works in own work area




                                                                         Tech Writer
         Team member checks out her
                                                              makes changes to the document and
                document
                                                                checks it into CVS repository



     Team member modifies her document                       Tech Writer notifies CM manager of a
          with “TrackChanges” on                                 new version of the document




     Team member saves the document with
               new filename                                  CM manager updates the document to
                                                                   the project web site



          Team approves the changes




No             Is the document
                  approved ?


                       Yes


      Team member sends the document to
               Tech Writer




      Team member approves last minute
                changes




                 Figure 1. Document Configuration Control Steps
                                      MSE studio 2003-2004




4.3.2 Change Request Process
Change requests (CRs) are submitted by team members, test subjects, or client via email
for consideration. A change request is used to summarize a change, problem,
enhancement, or improvement to the software, hardware, process, or documentation. A
log of CRs will be maintained and reviewed for tracking and closure. The general change
request process is shown in Figure 2. Specific details of how the process is implemented
are documented in C3PO SPMP.

The SCM manager ensures that the change request form has been reviewed and
implemented in a manner consistent with this plan. The change request number and
description of the change shall be documented in the CVS check-in comment when the
change has been implemented. Changes to documentation shall be documented on a
change page history for each document. Change bars may used to mark the location of
the change in the document. The SCM manager shall track change requests and relative
dispositions.

Approval authority for the initial baseline or changes to the baseline of development
products varies as described below.

4.3.2.1 Items Requiring Approval of C3PO team
Items requiring the approval of C3PO team members are those that are internal to C3PO.
They would include the following:
 Release(s) schedule and content (e.g., a software version)
 C3PO SRS
 C3PO System Concept Document
 C3PO SPMP
 C3PO SCMP
 C3PO Risk Management Plan
 Design/Architecture Document
 Test Documentation
 Code Changes

The team consists of the C3PO Studio members. Others will be consulted on an as-
needed basis.

A typical procedure would be similar to the following one:
 The person initiating a change to a product contacts the Team Lead via email.
 The team reviews the change request.
 Decisions are captured in the summary section of the change request and/or any
    tracking tool the project may be using.

A document approval page will be included at the front of the document for the Team
Lead to sign.
                                        MSE studio 2003-2004




Team member initiating a change to an
    artifact contacts Team Lead




    Team Lead evaluates the CR




           Requires Team            Yes
                                                    Team member presents the CR to team
             approval?



               No
                                                           Team prioritizes the CR




 Team Lead allows team member to                                                          No
        implement the CR                                       CR approved ?



                                                                 Yes




                         Team member implements the CR




                        SCM manager captures the decisions
                             made in a tracking tool




                            SCM manager closes the CR


                        Figure 2. C3PO Change Request Process
                                    MSE studio 2003-2004




4.3.3 Configuration Status Accounting
The SCM manager provides or makes available the necessary reports to team members
upon establishment of a new baseline or per request basis. Typical reports are intended to
enhance visibility by providing a summary of data elements, identifiers, labels and
attributes. The collection of this information can be used to monitor and report on change
implementation, review progress, and release status.

4.4 Audits and Reviews
Audits and reviews are conducted at appropriate life cycle phases to verify and validate
that the C3PO software and documentation completely and successfully fulfill the
requirements. The SCM Manager and the Team Lead will conduct the audit. A C3PO
production release to the customer is generated by the SCM Manager and Team Lead
after the Software Acceptance Review and final configuration audits are conducted, and
the product is approved to be promoted to the final baseline.

4.4.1 Functional Configuration Audit (FCA)
The objective of the functional configuration audit is to verify that a product's actual
performance agrees with its software requirements documentation.

The FCA encompasses the following two functions: verify that all tests specified in the
test plan have been completed, and verify that the software meets requirements based on
verification results.

When the FCA is conducted, the following documents may be used to provide a means
for recording and verifying performance: Software Requirements Specification, Version
Description Document, and System Test Documents. In addition, the team may witness a
subset of the system testing.

4.4.2 Physical Configuration Audit (PCA)
The objective of the physical configuration audit is to verify the adequacy, completeness,
and accuracy of the documentation that represents the correct release version/revision of
the software in the production baseline.

The PCA is accomplished by establishing the compatibility of the product to the
following released documentation: requirements documentation, test documentation,
version description documentation, and change control documentation.

4.4.3 Reviews
Formal code reviews are held at the request of a team member and as outlined in the
C3PO Inspection Process Document. Specific review elements, content and procedures
are more fully addressed in the C3PO Software Project Management Plan. The moderator
for the review distributes products for review. The SCM manager tracks review issues
and resolutions. The SCM manager distributes documentation for review and signature.
                                     MSE studio 2003-2004



4.5 Release Process
After a baseline has been established, the SCM Manager, with the Team Lead, generates
the official release package. At a minimum, the following documentation will be
released: User Guide, Programmer's Guide and a Version Description Document (VDD).
The SCM Manager generates an electronic VDD, which identifies the as-built
configuration status of the release. It identifies the release number, purpose of the release,
list of release media, list of operation or support documentation and software, list of all of
the software files in the release, any changes to the product since a previous release, list
of any anomalies, waivers or deviations, and any data files.

Releases will be distributed on CDs. CDs will be labeled with a date, CD number
(chronological), company made for, and release version number. CDs will be scanned for
viruses before shipping. A Readme file will be included in the release that defines
distribution information, support software information, and installation/update guidelines.
The SCM manager will assign a configuration control number to each deliverable item in
the release. A revision to a release will reflect the current revision level of the product
(i.e., a product at revision level C will be labeled C upon release to the customer). This
will maintain the configuration history of the product.
                                   MSE studio 2003-2004




5 Web Update Policy
This section describes how the C3PO website will be updated and maintained through the
life of the project. It will be the responsibility of the SCM to perform these updates.

5.1 Purpose of the Website
The team website provides a means to:
 Communicate with customer (more formally than Wiki or teleconference).
 Communicate with other project stakeholders.
 Log records of project related documents.
 Represent the project to the world.

5.2 Updates
5.2.1         Weekly Updates
SCM manager shall update the web site at least once a week. The documents that need to
be uploaded to the web site weekly are:
 Client meeting agenda
 Client meeting minutes
 Mentor meeting agenda
 Mentor meeting minutes
 Action item tracking sheet
 Team work-session summary

SCM manager shall follow the following procedure:
 Upload meeting agendas and minutes within 48 hours after receiving them from the
  team lead and client liaison.
 Summarize the updates on the top page of the website under “What’s New!” (the top
  page’s file name is toc.html).
 Log updates on “What’s Old?” page of the web site (the page’s file name is old.html).
 Notify project stakeholders of the update (Refer to 5.3 for additional information).

5.2.2         Updates on Demand
5.2.2.1   Content Update
SCM manager shall update the content of the team web site with the following
information:
 References to academic and industry web sources that contain information important
    to the project.
 Links to development tools that the team is using.
 Additional information that becomes available throughout the project.

SCM manager shall update the content of the web site according to the following
procedure:
 The team discusses and approves the content.
                                   MSE studio 2003-2004



   SCM manager puts a link to the content on the web site.
   SCM manager creates a new page as necessary depending on the importance and size
    of the content.

5.2.2.2   Document Update
SCM manager shall keep the lasted document versions on the website. As each new
document version is checked into CVS, the SCM manager shall follow the following
procedure:
 Retrieve the latest document version from CVS and copy it to the web site.
 Create links to the documents as necessary.
 Summarize the update on the top page of the website under “What’s New!” (the top
   page’s file name is toc.html).
 Notify project stakeholders of the update (Refer to 5.3 for additional information).

5.3 Update Notifications
SCM manager shall make update notifications whenever the website is updated. SCM
manager shall send these updates to the following stakeholders:
   - Team members.
   - Customer, Sidney Bailin.
   - Team mentors.
   - Other stakeholders as needed.

5.4 File Name Conventions
The following documents that require naming conventions are: client meeting agenda,
client meeting minutes, mentor meeting agenda, mentor meeting minutes, action item
tracking and team work-session summary.

Team members shall name the documents according to the naming conventions outlined
in Table 2.

Document                Person Responsible File name convention
                        for a document
Client meeting          Client Liaison     yyyy_mm_dd-CustomerAgenda.doc
agenda
Client meeting          Scribe (assigned by     yyyy_mm_dd-CustomerMinutes.doc
minutes                 the client liaison)
Mentor meeting          Team Lead               yyyy_mm_dd-TeamAgenda.doc
agenda
Mentor meeting          Scribe (assigned by     yyyy_mm_dd-TeamMinutes.doc
minutes                 the team lead)
Action Item tracking    Team Lead               C3PO-AtionItem.xls
sheet
Team work-session       Team Lead or          (name specific to topic)
summary                 designee
                           Table 2. File Naming Conventions.
                                    MSE studio 2003-2004




6 GLOSSARY
6.1 Acronym List
The following acronyms are used within this document:

  Acronym       Meaning
  SCM           Software Configuration Management
  CR            Change Request
  FCA           Functional Configuration Audit
  SCMP          Software Configuration Management Plan
  SDR           Software Design Review
  SPMP          Software Project Management Plan
  SRR           Software Requirements Review
  SRS           Software Requirements Specification
  SSPS          Software Standards and Procedures
                Specification
  VDD           Version Description Document



6.2 Definition of Terms
The definitions used in this plan conform to the definitions found in the ANSI/IEEE Std
729-1983, IEEE Standard Glossary of Software Engineering Terminology. See
specifically: configuration management, configuration identification, configuration
control, configuration status accounting, configuration audit, configuration control board,
baseline, promotion, release, version, and revision.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:8
posted:11/14/2011
language:English
pages:20