QMP Draft Part 2 - Configuration Management - Team 19 by dblock21

VIEWS: 14 PAGES: 24

									   Quality Management Plan

An Eclipse Plug-in for Use Case Authoring




                      Team 19

   Abhinav Guru (Project Manager, LCP, Developer)
              Jeet Poonater (Developer)
       Christopher Higginbotham (V&V, QFP)
  Joseph Haule (V&V, Webmaster, CVS, SSRD, OCD)
      Gaurav Sharma (V&V, SSAD, Developer)




                                               Version Date: 11/6/2009
Quality Management Plan                                                                    Version 3.2



Version History
Date         Author            Version   Changes made                  Rationale

09/23/2006   Gaurav Sharma,    1.0                                     QMP Draft Part 1 (Lean MBASE
             Lilibeth Gangas                                           Guidelines V1.7 Sections 1,2)

11/06/2006   Gaurav Sharma,    2.0       Added Section 3               QMP Draft Part II (Lean MBASE
             Lilibeth Gangas                                           Guidelines V1.7 Section 3)

02/04/2007   Christopher       3.0       Added information regarding   Modified for RLCO Phase
             Higginbotham                the Peer and Test Plans.
                                         Updated baselined
                                         information for future
                                         iterations.

02/14/2007   Christopher       3.1       Updated section: 3.3          Made changes due to
             Higginbotham                                              recommendations made during
                                         Replaced all references to
                                                                       RLCO ARB.
                                         IV&V as V&V

03/03/2007   Christopher       3.2       Updated names of project      RLCO V&V Evaluation.
             Higginbotham                people. Added baseline for
                                         RLCO documents




8d727a89-51a0-4ebb-b738-672c14abe350.doc ii                                    Version Date: 11/6/2009
Quality Management Plan                                                                                                         Version 3.2




Table of Contents

Version History .............................................................................................................................. iii
Table of Contents ........................................................................................................................... iii
Table of Tables .............................................................................................................................. iv
Table of Figures ............................................................................................................................. iv
1. Purpose.................................................................................................................................... 1
  1.1 Overview ............................................................................................................................... 1
  1.2 References ............................................................................................................................. 1
2. Quality Management Strategy ................................................................................................ 1
  2.1 Defect Prevention Strategies ................................................................................................. 1
  2.2 Defect Detection Strategies................................................................................................... 3
  2.3 Defect Removal Tracking ..................................................................................................... 4
  2.4 Level of Service Achievement Monitoring........................................................................... 5
  2.5 Process Assurance ................................................................................................................. 5
  2.6 V&V Coordination................................................................................................................ 6
3. Configuration Management .................................................................................................... 6
  3.1 Product Element Identification ............................................................................................. 6
  3.2 Configuration Items and Rationale ..................................................................................... 13
  3.3 Configuration Change Management ................................................................................... 15
  3.4 Project Library Management .............................................................................................. 18
  3.5 Configuration Status Management ..................................................................................... 19
  3.6 Resources and Personnel..................................................................................................... 20
  3.7 Tools ................................................................................................................................... 20




8d727a89-51a0-4ebb-b738-672c14abe350.doc iii                                                                 Version Date: 11/6/2009
Quality Management Plan                                   Version 3.2


Table of Tables

Table of Figures




8d727a89-51a0-4ebb-b738-672c14abe350.doc iv   Version Date: 11/6/2009
Quality Management Plan                                                                   Version 3.2



1. Purpose
1.1 Overview
This document meets the exit criteria set forth by the LeanMBASE v1.7 Draft of Quality
Management (QM) Plan Section 1, 2, and 3 by stating the details of the Quality and
Configuration Management Strategies to be followed by Team 19. Particular emphasis is given
on outlining strategies for defect prevention, defect detection and defect removal. The goal of the
plan is to minimize the defect occurrence and its impact and to provide artifact consistency and
traceability by employing effective configuration management techniques.
The development team will be able to use and implement the strategies laid out by the document
to reduce defects and meet the customer’s expectations. The ultimate goal is to eliminate the
defects with an aim to exceed the customer’s expectations.

1.2 References
Provide usable citations to significant prior and current related work and artifacts, documents,
meetings and external tools referenced or used in the preparation of this document.

Agile Review Forms
http://greenbay.usc.edu/csci577/fall2006/site/tools/AgileReviewForms.zip

LeanMBASE Value Based Review Descriptions
http://greenbay.usc.edu/csci577/fall2006/site/guidelines/LeanMBASE_VBR.zip

LeanMBASE Value Based Review Checklists
http://greenbay.usc.edu/csci577/fall2006/site/guidelines/LeanMBASE_VBR_Checklists_v3.3.zip

Concurrent Versions System (CVS)
http://www.nongnu.org/cvs/

JUnit
http://www.junit.org/index.htm


2. Quality Management Strategy
2.1 Defect Prevention Strategies
This section describes identifies and prioritizes the defect prevention strategy for this project.
There are several mechanisms that we can employ during this project to prevent defects from
occurring. The following table indicates the defect prevention strategy, its rationale, and
priority.
                               Table 1 – Defect Prevention Strategies
        Strategy                          Rationale                        Priority
Easy WinWin Negotiation         Used to minimize the                        High
                                number of requirements
                                defects that can enter the


8d727a89-51a0-4ebb-b738-672c14abe350.doc 1                                  Version Date: 11/6/2009
Quality Management Plan                                                Version 3.2


                           project.
Document Version History Provides simple way of            Medium
                           monitoring evolution of
                           each document. This will
                           prevent users from
                           mistakenly updating
                           documents.
LeanMBASE Guidelines       Provides all information         High
                           pertaining to each document
                           created. Prevents users
                           from entering incorrect
                           information into the various
                           documents.
LeanMBASE Document         Template provides all           Medium
Templates                  sections of each document.
                           This prevents the loss of a
                           particular section in the
                           generated document.
Value Based Reviews using Value Based Checklists are        High
Agile Independent Reviews, provided for OCD, SSAD,
Peer Reviews, and Fagan’s and SSRD. These provide
Inspections                validation on the applicable
                           document. They should
                           also be used as exit criteria
                           by the document author to
                           prevent concerns produced
                           by the V&V team.
Prototype                  The prototype helps              High
                           alleviating risks on the
                           various aspects of the
                           system.
Code Repository            The CVS code repository          High
                           will be employed to make
                           sure that each developer is
                           using the latest version of
                           the software.
JUnit                      The developers must create       High
                           JUnit tests for unit testing
                           each module in the system.
                           This unit testing will help
                           automate and prevent
                           defects from escaping into
                           the system.
ARB                        This milestone review of         High
                           the project will flush out
                           any high-level issues from


8d727a89-51a0-4ebb-b738-672c14abe350.doc 2                 Version Date: 11/6/2009
Quality Management Plan                                                               Version 3.2


                               the success critical
                               stakeholders involved in the
                               project.
Requirements Traceability      Used to validate that all                 High
Matrix                         project details trace back to
                               project requirements.


2.2 Defect Detection Strategies
There are several defect detections strategies being employed for this project, depending on the
particular development phase. For Inception and Elaboration, the primary strategies for
detecting defects within the project documents are:
     Peer Reviews
     V&V Review

During the Elaboration and Construction phases, an agile continuous integration plan will be
adopted. We will use the following defect detection strategy within each iteration of the
Construction phase:
    Design & Code Reviews
    Automated Testing
    Validation and System Test Plans

Peer Reviews

During the peer reviews, members of the team, other then the author, evaluate the artifact. The
peer reviewers log areas of concern using the Agile Internal Review Form.

These issues become logged as errors to be fixed in the next revision of the document. If some
of the issues are not defects, then the author provides the rationale on why there is no problem
and closes out the issue. Each of the peer reviewers must validate that each of their logged
problems were fixed in the document and must come to agreement on the rationale for any issues
that were not deemed defects by the author.

For additional information regarding the Peer Review process, refer to the Peer Review Section
of the Lean MBASE Guidelines document.

V&V Reviews

Similar to the peer review, the V&V team members perform a value-based review of the
document through the use of a value-based checklist. The following value-based checklists are
used on the applicable LCO and LCA package artifacts:
    Operation Concept Description (OCD) Value-Based Checklist
    System Software Requirements Description (SSRD) Value-Based Checklist
    System and Software Architecture Description (SSAD) Value-Based Checklist

Documents are initially evaluated using the checklist items. Anytime a concern is discovered
through the use of the checklist, a subsequent concern is documented in the Agile Independent
Review Form, using the priority and criticality indicated on the checklist.


8d727a89-51a0-4ebb-b738-672c14abe350.doc 3                               Version Date: 11/6/2009
Quality Management Plan                                                               Version 3.2


Design and Code Reviews

During the Elaboration and Construction phase, design and code reviews will be used to validate
the design and code artifacts. Each design and code review will follow the same pattern as the
Peer Review and the V&V reviews. Value-Based checklists will either be provided or generated
for the purpose of these reviews.

Automated Testing

During the Construction phase, each test plan will have an associated automated test set for
performing the validation. The automated tests will be executed on a periodic basis, following a
complete checkout and build of the current version of the project.

Validation and System Test Plans

The validation and system test plans will provide the documentation for the automated tests. The
Quality Focal Point will use this document to validate that the automated tests match their
documented test plan and align with the system requirements identified in the projects SSRD and
Requirements Traceability Matrix. The Quality Focal Point in conjunction with the clients will
generate a set of validation and system tests to validate the core functionality of the system.

2.3 Defect Removal Tracking
This section states the methods used for Problem, Issue and Defect reporting and tracking for this
project.

Peer Review Defect Removal Tracking

Once a Peer Review has occurred on a particular document and an Agile Internal Review Form
has been submitted back to the author, the author must use the form to identify which concerns
are defects and those that can be justified as not being a defect. All submitted Peer Review
concerns must be resolved in the next iteration of the document. That way the original reviewer
can validate that this issue was resolved during the subsequent review. If the latest revision of
the document does not appear to be resolved, based on the resolution provided in the Agile
Internal Review form, then the issue should be reopened in the new Agile Internal Review form,
indicating why the issue is not resolved.

V&V Defect Removal Tracking

Just as in the Peer Review, the V&V team will track the defect removals within their Agile
Independent Review form. The author will provide resolution to all concerns to the V&V team
within the applicable sections of the Agile Independent Review form. All submitted V&V
review concerns must be resolved in the next iteration of the document. That way the V&V team
can validate that this issue was resolved during the subsequent review. If the latest revision of
the document does not appear to be resolved, based on the resolution provided in the Agile
Independent Review form, then the issue should be reopened in the new Agile Independent
Review form, indicating why the issue is not resolved.



8d727a89-51a0-4ebb-b738-672c14abe350.doc 4                               Version Date: 11/6/2009
Quality Management Plan                                                                Version 3.2


Construction Defect Removal Tracking

During the Construction phase, the Peer Review and V&V team will use their applicable Agile
Review forms to post and track defects found during reviews and testing of the software.

Defect Removal Tracking Storage Delivery

Once a Peer or V&V review has occurred for a particular artifact, it should be posted to the
website. The owner of the reviewed artifact must be notified when the review has been posted so
that appropriate actions can take place to get the concerns resolved.

Quality Management Information System

The Quality Focal Point will be responsible for collecting the projects defect data. The defect
data will be consolidated from the Fagan inspections, Agile Internal Reviews, Agile Independent
Reviews, V&V evaluations, testing reports, and customer feedback. This data will then be
submitted on a weekly basis into the QMIS system. A summary report will be also be generated
by the Quality Focal Point based on this data and posted to the team website for review by the
entire team.

2.4 Level of Service Achievement Monitoring
For the Use Case Authoring Plug-in, to achieve the desired Level of Service Goals negotiated
with the client, the following activities need to be performed:
LOS-1 GUI Response Time for User Interaction
   1. At the end of first development iteration of the project, calibrate and maintain data of the
      system response time to user interactions.
   2. Calculate and map the average system response time for the different user interactions.
   3. Compare and chart the product’s response time with the desired level of service.
   4. Determine the positive/negative deviation and perform risk assessment/re-prioritization.
   5. Discuss with all the Success Critical Stakeholders the Level of Service results from the
      current iteration. Inform the customer of the deviations and risk mitigation strategy.
   6. Depending on the outcome of Step 4, re-prioritize requirements/goals for the second
      iteration. Perform risk assessment, requirements analysis for the third iteration.
   7. Repeat Step 1 at the end of the next iteration.

LOS-2 WHAT Syntax Validation & Feedback Response Time

   1. User adds detail to use case via the Eclipse Authoring Tool
   2. After user reaches end of line of statement, the syntax entered by user will be checked
      against the WHAT syntax via the Eclipse syntax supported compiler.
   3. If the user entered syntax does not match those set by the WHAT language, an error will
      be displayed on the Eclipse workshop explaining user why input syntax is incorrect.
   4. Repeat steps 1-7 of LOS-1 described above.

2.5 Process Assurance
For the project, the following process assurance initiatives have been put in place:


8d727a89-51a0-4ebb-b738-672c14abe350.doc 5                                Version Date: 11/6/2009
Quality Management Plan                                                                   Version 3.2


   1. Provision of deadlines for project deliverables by the CS577 staff members.
   2. Project Manager will monitor artifact submission before the artifact submission
      deadlines.
   3. Quality Focal Point will monitor reviews/test results and resulting corrective actions
      taken in order to improve quality. Quality Focal Point will track quality through QMIS
      tool.

2.6 V&V Coordination
The V&V members’ and the team’s coordination is critical for improving and ensuring the
quality of the project. Following are the roles and responsibilities to facilitate the coordination:
   1. Informal Submission of the reviewable artifact to the V&V in the form of email
      communication from the artifact creator. An alternative approach could be uploading the
      artifact to the team website and a formal notification to this effect be sent to the V&V
      members.
   2. Formal concern log discussion/issue-clarification, if required, between the artifact creator
      and the V&V members initiated by the artifact author. The mode of operation for this
      activity can be email, online chat, or phone communication.
   3. A formal weekly meeting of the project management and the V&V members to assess the
      progress of quality improvement and to discuss new initiatives and analyze recent defect
      trends.
   4. Informal regular communication between both the V&V members regarding updates to
      shared artifacts like the Quality Management Plan, Configuration Management Plan, and
      project progress discussion from the Quality Management perspective.

3. Configuration Management
This section identifies which items will be baselined for this project according to milestone
schedule and how outstanding reports will be tracked. The custodian of the master baselined
versions will be the Configuration Manager who will preserve the integrity and recoverability of
master versions. The CM Manager will be the Quality Focal Point (LCP) and he/she will ensure
that version control is maintained.

3.1 Product Element Identification

This section contains the guidelines for the various product artifacts that are generated in this
project. The artifact baselines are also provided in this section. The baselined artifacts are those
items that must undergo the configuration change management guidelines when revised.

The file naming convention will adhere to:
[Artifact]_[Milestone]_[Semester][Year]_[Team#]_[Version].


Team Website

http://greenbay.usc.edu/csci577/spring2007/projects/team19/index.html




8d727a89-51a0-4ebb-b738-672c14abe350.doc 6                                  Version Date: 11/6/2009
Quality Management Plan                                                                Version 3.2


Data Archiving Guidelines

The following guidelines are to be followed for the team website and data archiving guidelines:

http://greenbay.usc.edu/csci577/fall2006/site/guidelines/structureA.html

LCO Baselined Artifacts

The following table contains the document artifacts and their versions that will be baselined at
the completion of the LCO Package.
                                  Table 1 - LCO Baselined Artifacts
    Baselined         Document                        Filename                      Artifact
    Document           Version                                                      Owner
    Operation            1.7             OCD_LCO_F06a_T19_V1.7.pdf                 Sumanth
     Concept                             OCD_LCO_F06a_T19_V1.7.doc                 Shanbhag
   Description
      (OCD)
   System and             1.6            SSRD_LCO_F06a_T19_V1.6.pdf              Joseph Haule
     Software                            SSRD_LCO_F06a_T19_V1.6.doc
  Requirements
   Description
     (SSRD)
 Life Cycle Plan          1.2             LCP_LCO_F06a_T19_V1.2.pdf                Abhinav
      (LCP)                               LCP_LCO_F06a_T19_V1.2.doc                 Guru
    Feasibility           1.1             FRD_LCO_F06a_T19_V1.1.pdf                Stephen
    Rationale                             FRD_LCO_F06a_T19_V1.1.doc                 Oketta
   Description
      (FRD)
   System and             1.1            SSAD_LCO_F06a_T19_V1.2.pdf               Diana Chu
     Software                            SSAD_LCO_F06a_T19_V1.2.doc
  Architecture
   Description
     (SSAD)
     Support              1.1             SID_LCO_F06a_T19_V1.1.pdf                Shyamal
   Information                            SID_LCO_F06a_T19_V1.1.doc                 Patel
Documents (SID)
      Quality             1.0            QMP_LCO_F06a_T19_V1.0.pdf                  Gaurav
  Management                             QMP_LCO_F06a_T19_V1.0.doc                Sharma &
   Plan (QMP)                                                                      Lilibeth
                                                                                   Gangas
 UML Modeling             1.2         RSAModel_LCO_F06a_T19_V2.1.zip                Gaurav
                                                                                   Sharma
    Prototype             1.4          Prototype_LCA_F06a_T19_V2.1.pdf             Shyamal
                                                                                     Patel

The LCO Package and its associated artifacts can be found in the following location:


8d727a89-51a0-4ebb-b738-672c14abe350.doc 7                                 Version Date: 11/6/2009
Quality Management Plan                                                                Version 3.2


http://greenbay.usc.edu/csci577/spring2007/projects/team19/LCO/index.html


LCA Baselined Artifacts

The following table contains the document artifacts and their versions that will be baselined at
the completion of the LCA Package.
                                  Table 2 - LCA Baselined Artifacts
    Baselined         Document                        Filename                     Artifact
    Document           Version                                                     Owner
    Operation            2.1              OCD_LCA_F06a_T19_V2.1.pdf               Sumanth
     Concept                                                                      Shanbhag
   Description
      (OCD)
   System and             2.1            SSRD_LCA_F06a_T19_V2.1.doc              Joseph Haule
     Software
  Requirements
   Description
     (SSRD)
 Life Cycle Plan          2.1             LCP_LCA_F06a_T19_V2.1.doc                Abhinav
      (LCP)                                                                         Guru
    Feasibility           2.2             FRD_LCA_F06a_T19_V2.2.doc                Stephen
    Rationale                                                                       Oketta
   Description
      (FRD)
   System and             2.3            SSAD_LCA_F06a_T19_V2.3.doc               Diana Chu
     Software
  Architecture
   Description
     (SSAD)
     Support              2.1             SID_LCA_F06a_T19_V2.1.doc                Shyamal
   Information                                                                      Patel
Documents (SID)
      Quality             2.0            QMP_LCA_F06a_T19_V2.0.doc                  Gaurav
  Management                                                                      Sharma &
   Plan (QMP)                                                                      Lilibeth
                                                                                   Gangas
 UML Modeling             2.1         RSAModel_LCA_F06a_T19_V2.1.zip                Gaurav
                                                                                   Sharma
    Prototype             2.1          Prototype_LCA_F06a_T19_V2.1.pdf             Shyamal
                                                                                     Patel

The LCA Package and its associated artifacts can be found in the following location:

http://greenbay.usc.edu/csci577/spring2007/projects/team19/LCA/index.html


8d727a89-51a0-4ebb-b738-672c14abe350.doc 8                                Version Date: 11/6/2009
Quality Management Plan                                                                Version 3.2



RLCO Baselined Artifacts

The following table contains the document artifacts and their versions that will be baselined at
the completion of the RLCO Package.
                                 Table 4 - RLCO Baselined Artifacts
    Baselined         Document                        Filename                     Artifact
    Document           Version                                                      Owner
    Operation            2.3            OCD_RLCO_S07b_T19_V2.3.doc               Joseph Haule
     Concept
   Description
      (OCD)
   System and             2.3           SSRD_RLCO_S07b_T19_V2.3.pdf              Joseph Haule
     Software
  Requirements
   Description
     (SSRD)
 Life Cycle Plan          2.3           LCP_RLCO_ S07b _T19_V2.3.doc            Abhinav Guru
      (LCP)
    Feasibility           NA                             NA                            NA
    Rationale
   Description
      (FRD)
   System and             3.1          SSAD_RLCO_ S07b _T19_V3.1.pdf                Gaurav
     Software                                                                       Sharma
  Architecture
   Description
     (SSAD)
     Support              NA                             NA                            NA
   Information
Documents (SID)
      Quality             3.1          QMP_RLCO_ S07b _T19_V3.1.doc              Christopher
  Management                                                                    Higginbotham
   Plan (QMP)
UML Modeling              2.3                RSAModel_RLCO_ S07b                    Gaurav
                                                _T19_V2.3.zip                       Sharma
    Prototype             NA                         NA                               NA

The LCA Package and its associated artifacts can be found in the following location:

http://greenbay.usc.edu/csci577/spring2007/projects/team19/RLCO/index.html

RLCA Iteration 1 Baselined Artifacts

The following table contains the document artifacts and their versions that will be baselined at
the completion of the RLCA Iteration 1 Package.


8d727a89-51a0-4ebb-b738-672c14abe350.doc 9                                Version Date: 11/6/2009
Quality Management Plan                                                                Version 3.2


                          Table 5 - RLCA Iteration 1 Baselined Artifacts
    Baselined      Document                          Filename                      Artifact
    Document        Version                                                         Owner
    Operation        TBD             OCD_RLCA_I1_F06a_T19_VX.X.pdf               Joseph Haule
     Concept
   Description
      (OCD)
   System and         TBD                        SSRD_                           Joseph Haule
     Software                           RLCA_I1_F06a_T19_VX.X.pdf
  Requirements
   Description
     (SSRD)
 Life Cycle Plan      TBD            LCP_ RLCA_I1_F06a_T19_VX.X.pdf Abhinav Guru
      (LCP)
    Feasibility       TBD                         FRD_                           Abhinav Guru
    Rationale                           RLCA_I1_F06a_T19_VX.X.pdf
   Description
      (FRD)
   System and         TBD                        SSAD_                              Gaurav
     Software                           RLCA_I1_F06a_T19_VX.X.pdf                   Sharma
  Architecture
   Description
     (SSAD)
     Support          TBD              SID_RLCO_F06a_T19_VX.X.doc                Abhinav Guru
   Information
Documents (SID)
      Quality         TBD                        QMP_                             Christopher
  Management                            RLCA_I1_F06a_T19_VX.X.doc                Higginbotham
   Plan (QMP)
UML Modeling          TBD                      RSAModel_               Gaurav
                                        RLCA_I1_F06a_T19_VX.X.zip      Sharma
   Prototype          TBD                       Prototype_             Gaurav
                                        RLCA_I1_F06a_T19_VX.X.pdf      Sharma
 Iteration Plan       TBD             IP_ RLCA_I1_F06a_T19_VX.X.pdf  Christopher
                                                                    Higginbotham
Peer Review Plan      TBD            PRP_ RLCA_I1_F06a_T19_VX.X.pdf Christopher
                                                                    Higginbotham
   Test Plan          TBD             TP_ RLCA_I1_F06a_T19_VX.X.pdf  Christopher
                                                                    Higginbotham
    Iteration         TBD            IAR_ RLCA_I1_F06a_T19_VX.X.pdf  Christopher
  Assessment                                                        Higginbotham
     Report
  Peer Review         TBD                         PRR_                            Christopher
     Report                             RLCA_I1_F06a_T19_VX.X.pdf                Higginbotham
  Test Report         TBD             TR_ RLCA_I1_F06a_T19_VX.X.pdf               Christopher


8d727a89-51a0-4ebb-b738-672c14abe350.doc 10                                Version Date: 11/6/2009
Quality Management Plan                                                                  Version 3.2


                                                                                   Higginbotham

The LCA Package and its associated artifacts can be found in the following location:

http://greenbay.usc.edu/csci577/spring2007/projects/team19/RLCA/index.html

RLCA Iteration 2 Baselined Artifacts

The following table contains the document artifacts and their versions that will be baselined at
the completion of the RLCA Iteration 2 Package.
                            Table 6 - RLCA Iteration 2 Baselined Artifacts
    Baselined         Document                         Filename                      Artifact
    Document           Version                                                        Owner
    Operation           TBD                        OCD_                            Joseph Haule
     Concept                              RLCA_I2_F06a_T19_VX.X.pdf
   Description
      (OCD)
   System and            TBD                       SSRD_                           Joseph Haule
     Software                             RLCA_I2_F06a_T19_VX.X.pdf
  Requirements
   Description
     (SSRD)
 Life Cycle Plan         TBD                        LCP_                           Abhinav Guru
      (LCP)                               RLCA_I2_F06a_T19_VX.X.pdf
    Feasibility          TBD                        FRD_                           Abhinav Guru
    Rationale                             RLCA_I2_F06a_T19_VX.X.pdf
   Description
      (FRD)
   System and            TBD                       SSAD_                              Gaurav
     Software                             RLCA_I2_F06a_T19_VX.X.pdf                   Sharma
  Architecture
   Description
     (SSAD)
     Support             TBD           SID_ RLCA_I2_F06a_T19_VX.X.doc Abhinav Guru
   Information
Documents (SID)
      Quality            TBD                       QMP_                             Christopher
  Management                              RLCA_I2_F06a_T19_VX.X.doc                Higginbotham
   Plan (QMP)
UML Modeling             TBD                     RSAModel_                            Gaurav
                                          RLCA_I2_F06a_T19_VX.X.zip                   Sharma
    Prototype            TBD                      Prototype_                          Gaurav
                                          RLCA_I2_F06a_T19_VX.X.pdf                   Sharma
  Iteration Plan         TBD            IP_ RLCA_I2_F06a_T19_VX.X.pdf               Christopher
                                                                                   Higginbotham
Peer Review Plan         TBD                             PRP_                       Christopher


8d727a89-51a0-4ebb-b738-672c14abe350.doc 11                                  Version Date: 11/6/2009
Quality Management Plan                                                                  Version 3.2


                                          RLCA_I2_F06a_T19_VX.X.pdf   Higginbotham
    Test Plan            TBD            TP_ RLCA_I2_F06a_T19_VX.X.pdf  Christopher
                                                                      Higginbotham
    Iteration            TBD           IAR_ RLCA_I2_F06a_T19_VX.X.pdf Christopher
  Assessment                                                          Higginbotham
     Report
  Peer Review            TBD                       PRR_                             Christopher
     Report                              RLCA_I2_F06a_T19_VX.X.pdf                 Higginbotham
  Test Report            TBD           TR_ RLCA_I2_F06a_T19_VX.X.pdf                Christopher
                                                                                   Higginbotham

The LCA Package and its associated artifacts can be found in the following location:

http://greenbay.usc.edu/csci577/spring2007/projects/team19/RLCA/index.html

RLCA Iteration 3 Baselined Artifacts

The following table contains the document artifacts and their versions that will be baselined at
the completion of the RLCA Iteration 3 Package.
                            Table 7 - RLCA Iteration 3 Baselined Artifacts
    Baselined         Document                         Filename                      Artifact
    Document           Version                                                        Owner
    Operation           TBD                        OCD_                            Joseph Haule
     Concept                              RLCA_I3_F06a_T19_VX.X.pdf
   Description
      (OCD)
   System and            TBD                       SSRD_                           Joseph Haule
     Software                             RLCA_I3_F06a_T19_VX.X.pdf
  Requirements
   Description
     (SSRD)
 Life Cycle Plan         TBD                        LCP_                           Abhinav Guru
      (LCP)                               RLCA_I3_F06a_T19_VX.X.pdf
    Feasibility          TBD                        FRD_                           Abhinav Guru
    Rationale                             RLCA_I3_F06a_T19_VX.X.pdf
   Description
      (FRD)
   System and            TBD                       SSAD_                              Gaurav
     Software                             RLCA_I3_F06a_T19_VX.X.pdf                   Sharma
  Architecture
   Description
     (SSAD)
     Support             TBD           SID_ RLCA_I3_F06a_T19_VX.X.doc Abhinav Guru
   Information
Documents (SID)
      Quality            TBD                             QMP_                       Christopher


8d727a89-51a0-4ebb-b738-672c14abe350.doc 12                                  Version Date: 11/6/2009
Quality Management Plan                                                                 Version 3.2


  Management                              RLCA_I3_F06a_T19_VX.X.doc              Higginbotham
  Plan (QMP)
 UML Modeling             TBD                    RSAModel_               Gaurav
                                          RLCA_I3_F06a_T19_VX.X.zip      Sharma
    Prototype             TBD                     Prototype_             Gaurav
                                          RLCA_I3_F06a_T19_VX.X.pdf      Sharma
  Iteration Plan          TBD           IP_ RLCA_I3_F06a_T19_VX.X.pdf  Christopher
                                                                      Higginbotham
Peer Review Plan          TBD                       PRP_               Christopher
                                          RLCA_I3_F06a_T19_VX.X.pdf   Higginbotham
    Test Plan             TBD           TP_ RLCA_I3_F06a_T19_VX.X.pdf  Christopher
                                                                      Higginbotham
    Iteration             TBD          IAR_ RLCA_I3_F06a_T19_VX.X.pdf Christopher
  Assessment                                                          Higginbotham
     Report
  Peer Review             TBD                      PRR_                           Christopher
     Report                              RLCA_I3_F06a_T19_VX.X.pdf               Higginbotham
  Test Report             TBD          TR_ RLCA_I3_F06a_T19_VX.X.pdf              Christopher
                                                                                 Higginbotham

The LCA Package and its associated artifacts can be found in the following location:

http://greenbay.usc.edu/csci577/spring2007/projects/team19/RLCA/index.html

3.2 Configuration Items and Rationale

The following is a list of configuration item that includes both documents (package elements,
plans) and software (source code, installation scripts, etc). The Volatility of the items are ranked
from High (H), Medium (M), to Low (L), where H denotes those items will be updated
frequently thus becoming most volatile. The Severity of the items has also been ranked in the
same manner as Volatility where H denotes the items that can have the most severe impact on
project due to changes.

                             Table 8 – Configuration Items and Rationale
Artifact                          Volatility       Severity      Rationale
                                  (H, M, L)        (H, M, L)
Package Elements
OCD                                     L          H                Operational vision of our project
                                                                     that should not be changed much
                                                                     after LCA
                                                                    Basis for SSRD and SSAD
SSRD                                    L          H                Needed for requirements
                                                                     traceability
                                                                    Client expects requirements
                                                                     captured in this document to be
                                                                     satisfied by tool


8d727a89-51a0-4ebb-b738-672c14abe350.doc 13                                Version Date: 11/6/2009
Quality Management Plan                                              Version 3.2


SSAD                            M        H       A stable and feasible architecture
                                                  should be achieved before
                                                  construction so changes to
                                                  SSAD will have costlier rework
                                                  done at later phases (i.e.
                                                  construction)
LCP                             M        L       It is expected for LCP to be
                                                  updated several times to update
                                                  schedule, update
                                                  tasks/responsibilities of team,
                                                  and update artifact specific
                                                  information during all phases
                                                 Needed for Feasibility Analysis,
                                                  so major changes to LCP can
                                                  impact FRD
FRD                              L       M       Feasibility of project needs to be
                                                  updated upon major changes of
                                                  artifacts of high/medium severity
                                                 Needed to show consistency
                                                  between SSAD, SSRD,
                                                  Prototype, and LCP
Prototype                       H        H       Needed for feasibility analysis
                                                 Require input from client, so
                                                  updates to it are expected
                                                 Main deliverable of this project
Easy WinWin Report               L       H       Captures contract agreements
                                                  between Client and teams
Plans
Quality Management Plan         M        M       QM Strategy and plan need to be
                                                  followed by project
Peer Review Plan                H        H       Since the peer review plan is
                                                  used frequently, changes. to
                                                  procedures can affect project’s
                                                  quality
Transition Plan                 M        H       Necessary to ensure successful
                                                  transition to customer
Iteration Plan                  M        H       Needed to ensure successful
                                                  completion of exit criteria of
                                                  each iteration
Test Plan                       H        H       Needed for running tests,
                                                  references (acceptance
                                                  tests)procedures, details test
                                                  cases
                                                 Changes to this plan may affect
                                                  how testing is done and thus


8d727a89-51a0-4ebb-b738-672c14abe350.doc 14             Version Date: 11/6/2009
Quality Management Plan                                                                Version 3.2


                                                                    costly re-testing might result
Transition Package
Plug-in Source Code                    H          H                Changes to sources code must be
                                                                    compiled into project
                                                                   Needed for debugging and
                                                                    maintenance of tool
UML Extension                          M          M                Changes to sources code must be
                                                                    compiled into project
                                                                   Needed for debugging and
                                                                    maintenance of tool
Client-Side Deliverables
User Manual                            M          M                Required so that end user of tool
                                                                    can learn how to use the tool and
                                                                    all of it features
                                                                   Must be maintained to reflect
                                                                    latest version of source code
                                                                    (updated with each version of
                                                                    source code so that all
                                                                    functionalities are captured
                                                                    accurately).


3.3 Configuration Change Management

This section describes the sequence of tasks and decisions regarding maintenance of the software
baseline items. The following flowchart shows how to submit, analyze, approve, and implement
proposed changes to the baseline items.

                      Figure 1: Flowchart for Configuration Change Management




8d727a89-51a0-4ebb-b738-672c14abe350.doc 15                               Version Date: 11/6/2009
Quality Management Plan                                                                             Version 3.2



         Start                                                                               Start
    Version Editing                                                                        Milestone
                                                                                            Editing




                                             CM Repository                              Check out the latest
   Author checks out
                                                                                           versions for
    the latest artifact
                                                                                            milestone
   version for editing
                                                                                           submission



                                     Check out              Check in

                                                                                         Review Milestone
                                                                                           Deliverables
  Author edits artifact,
     checks back in,
   submits for review



                                                                  Author edits     No
                                                                artifact, checks           Pass Review ?
        Review                                                  back in, submits
     necessitates a          Yes                                   for review
      new artifact
       version?
                                                        CM Focal Point                     Yes
                                                       checks in, creates
                                                         new baseline
                No



          End                                                 End




The following are change control forms and procedures:
                                   Table 9: Change Control Form Table Headings
Artifact Item             Change Request         Affected              Review Method         Approved by
                          Rationale              Sections




8d727a89-51a0-4ebb-b738-672c14abe350.doc 16                                        Version Date: 11/6/2009
Quality Management Plan                                                                                     Version 3.2




                                     Figure 2: Flow from Change Level Perspective




                                                                                   Baseline updated
                                                                                   with updated item

                                                                                   Upload updated Item
                                                 Perform                            on Team Website
                                                 Informal
                                                Peer Review
                                                                                              YES
                                               NO

                                                                     Author           Resolutions
                     Author submits                              Resolve Defects      Accepted by
                     Product item to               Major            Identified         Reviewers
                                                                                      (Item Updated)
               to team along with change          Change
              request identifying changes

                                               YES

                                                                                                NO

                                                Review with
                                               Team and Client




Procedures for Artifact Changes
   1. Author request baseline change by submitting artifact item to be approved along with the
      change control form filled out with applicable sections to all team members.
   2. If a major change is agreed by team after reviewing change control form, then meeting
      with the client is required before proceeding. If no major change is seen as needed, then
      author can request an informal peer review based on the value-driven basis. Otherwise
      the author can just make the minor changes and submit for evaluation of the next
      baselined phase.
   3. Author will resolved all defects/issues and submit updated item to reviewers who will
      either accept resolutions. If resolutions are not accepted, item will be resubmitted for
      change request with an updated change control form.
   4. If resolutions are accepted by reviewers, then baseline will be updated with this new
      version of item.
   5. Item will be uploaded onto team website.



The following is a chart indicating level of managements responsible for approving proposed
changes.


8d727a89-51a0-4ebb-b738-672c14abe350.doc 17                                                     Version Date: 11/6/2009
Quality Management Plan                                                               Version 3.2


                       Table 10: Level of Management Change Approval Table
                     Level of Change           Authority to Approve
                     Minor                     Developers, Project
                                               Manager, Quality Focal
                                               Point
                     Major                     Project Manager, Client,
                                               Quality Focal Point

3.4 Project Library Management

The project library resides at the following site:
http://greenbay.usc.edu/csci577/spring2007/projects/team19/index.html


(a) Organizational responsibilities
     The website manager is the responsible team member for organizing the webpage
       contents into sections such as LCO, LCA, IVV, Client Meeting Notes,

(b) Library contents
     Project Description
     Team Names, Roles, and Emails
     Project Information (Academic Period, Client, Project Domain, Team Number, Project
        Name, Number of Developers, Project Type, COTS used)
     Progress Reports
     LCO – Includes are the artifacts such as
           o OCD, SSRD, SSAD, FRD, LCP, UML Model, Easy Win Win Report, SID,
               Quality Reports, Architecture Review Board Presentation, Prototype
     LCA – Includes are the artifacts such as
           o OCD, SSRD, SSAD, FRD, LCP, UML Model, Easy Win Win Report, SID,
               Quality Reports, Architecture Review Board Presentation, Prototype
     Client Meeting Notes
     V&V Artifacts,
     Final Deliverables Includes are the artifacts such as
           o OCD, SSRD, SSAD, FRD, LCP, UML Model , Easy Win Win Report, SID,
               Quality Reports, Architecture Review Board Presentation, Prototype

(c) Services provided
     Open documents as read-only via web browser
     Download artifacts to local workstation for read/write rights
     Project-related resources and links

(d) Operational procedures for general usage, storage and release of master copies, security,
backup and recovery
     The team website manager is the only one who uploads documents.
     Each artifact item author is responsible for storage and release of master copies.


8d727a89-51a0-4ebb-b738-672c14abe350.doc 18                               Version Date: 11/6/2009
Quality Management Plan                                                                Version 3.2


      The Website Manager and the Quality Focal Point are responsible for backing up
       documents so that recovery is feasible.
      The Team Group Document Repository serves as a backup store for the project artifacts.
      Network security is provided by USC ISD
      Data Security can be increased by password-protecting team’s deliverables before
       uploading to the team website

(e) Library facilities and support services
     USC provides the team with library facilities (server, workstations, internet access) and
        support services (ftp uploading services, network security)
     ISD is the official entity responsible for security of webpages allocated by USC.

(f) Staffing and resource requirements
     Project Manager assesses staffing needs of the project and assigns resources per the need
     Team Website Manager – Joseph Haule
            o Manually uploads/removes items on webpage
            o Resource requirement – Workstation, FTP Application, Internet Access

(g) Source code repository
     The team will have a CVS repository for source code
     CVS Manager – Joseph Haule
           o Responsible for setting up the CVS repository.
           o Responsible for providing instructions on how to configure Eclipse to work with
              this CVS repository.


3.5 Configuration Status Management
This section identifies the “responsibilities, schedules, and procedures involved in performing
audits of integrity of the product elements”.

The responsibilities needed to perform audits of integrity are as follows:
    Author (Owner of Artifact) is to ensure that document being submitted is the one agreed
       according to Configuration Change Management (See Figure 1 for details of process).
       Author should ensure that artifact is properly being backed up on Team Group Document
       Repository by Website Manager. In addition, author should have properly store the
       master file.
    Website Manager will ensure that uploaded artifact’s file format has not been corrupted
       upon uploading to team website. Website Manager will add security password to each
       artifact uploaded to the team website that are considered strong baselines.
    Project Manager will assist Auditor in all parts of audit as needed.
    Auditor (V&V) will check that the artifact has been properly secured with password. In
       addition, auditor will ensure that file format has not been corrupted and he/she has
       reading rights. Lastly, the auditor will check that artifact uploaded is the correct version
       of artifact agreed upon Configuration Change Management Request by reviewing the




8d727a89-51a0-4ebb-b738-672c14abe350.doc 19                               Version Date: 11/6/2009
Quality Management Plan                                                                 Version 3.2


       Change Control Form against specific artifact being audited. Once these responsibilities
       have been fulfilled, auditor will follow audit procedures described below.

Audit procedures for Integrity Monitoring of Baselined Artifacts:
  1. Running unit tests for the baselined code
  2. Diff’ing the last baseline versions with the newly submitted artifacts
  3. Using CVS built-in tools to perform advanced comparisons and version tree lookups

Schedule of Audits of Integrity will be referenced according to schedule maintained in LCP
located at:
http://greenbay.usc.edu/csci577/spring2007/projects/team19/FD/index.html


3.6 Resources and Personnel
The software and human resources required to perform configuration management (CM)
functions are identified below:
                                 Table 11: Resources and Personnel
                 Human                 Role/Task               SW Resource
                 Resource
                 Joseph Haule          Website Manager          FTP
                                       (library archivist)
                 Artifact Author       Change Requester        MS Word
                 Client                Reviewer, Approver      MS Word, RSA
                                       Major Changes
                 Abhinav Guru          Project Manager         MS Word, RSA
                 Developers            Reviewer, Approver      MS Word, RSA
                                       of Minor Changes

3.7 Tools
Each of the tasks mentioned above may necessitate the use of tools for efficiency and
effectiveness.

                                        Table 3: CM Tools
                   Task                       Tool
                   Version Control                    CVS
                   Version Control                    Eclipse CVS
                   Integration                         Integration
                   Library Archivist                  FTP,
                                                      Access to network
                   Change Requester                   MSWord
                   Reviewer                           MSWord, RSA
                   Unit Testing                       JUnit




8d727a89-51a0-4ebb-b738-672c14abe350.doc 20                                Version Date: 11/6/2009

								
To top