Quality Management Plan for UDM Version 2.0
Quality Management Plan (QMP)
UDMUnited Direct Marketing
Team 09
Chun-Ling Chen – Project manager/ Prototyper
Chun-Pei Su – Lifecycle Planner/ Feasibility Analyst
Shao-yen Cheng – System Architect
Yuan-Chang Chang – Feasibility Analyst
Stewart Allen – IIV&V/ Quality Focal Point/Requirements Engineer
Yen-Kuo Kao – Operational Concept Engineer
Version History
Date / Author / Version / Changes made / Rationale /10/27/12 / Stewart Allen / 1.0 / · Initial version of QMP / · Initial version of QMP
11/18/2012 / Stewart Allen / 2.0 / · Complete all sections, including the configuration management section / · All sections due
Table of Contents
Quality Management Plan (QMP) i
Version History ii
Table of Contents ii
Table of Tables iv
Table of Figures v
1. Purpose 1
1.1. Purpose of the QMP 1
1.2. Status of the QMP 1
2. Quality Management Strategy 2
2.1. Defect Prevention Strategies 2
2.2. Defect Detection Strategies 2
2.3. Defect Removal Tracking 3
2.4. Level of Service Achievement Monitoring 3
2.5. Process Assurance 4
2.6. IIV&V Coordination 4
3. Configuration Management 5
3.1. Product Element Identification 5
3.2. Configuration Item and Rationale 6
3.3. Configuration Change Management 7
3.4. Project Library Management 7
3.5. Resources and Personnel 8
3.6. Tools 8
QMP_FCP_F12a_T09_V2.0.doc 8 Version Date: 11/18/2012
Quality Manage Plan (QMP) Template Version x.x
Table of Tables
Table 1: List of defect prevention strategies 2
Table 2: Automated analysis strategy for defect detection 2
Table 3: People review strategies for defect detection 2
Table 4: Execution testing strategies for defect detection 3
Table 5: Level of Service achievement strategy and its responsible person 3
Table 6: Configuration Item and Rationale 6
QMP_FCP_F12a_T09_V2.0.doc 8 Version Date: 11/18/2012
Quality Manage Plan (QMP) Template Version x.x
Table of Figures
No table of figures entries found.
QMP_FCP_F12a_T09_V2.0.doc 8 Version Date: 11/18/2012
Quality Management Plan for UDM Version 2.0
1. Purpose
1.1. Purpose of the QMP
The Quality Management Plan (QMP) describes the measures that a project will use to ensure a quality product. This includes the methods for defect prevention, detection, and removal, and configuration management.
1.2. Status of the QMP
The QMP has all of the sections completed for the QMP #2 document delivery.
2. Quality Management Strategy
2.1. Defect Prevention Strategies
Table 1: List of defect prevention strategies
Strategy / DescriptionWin-Win (WinBook, Negotiations) / Win negotiations are being held and the Win Conditions tracked in WinBook for this project. This is preventative due to the centralize nature of the requirements management. All stakeholders can review the Win Conditions and understand them as they change.
Prototypes / The primary features of the website are being prototyped. This will help the team ensure that the client and team are fully communicating expectations correctly, and that the team can manage the development of the project.
Incremental Commitment Spiral Model Standard / The development team is using a standard approach to developing the product. This will ensure that quality is designed prior to beginning to develop.
Web Designer / The team and client have decided to incorporate a web designer into the team to help prevent quality and defect issues with the look and feel of the design aspects of the project.
2.2. Defect Detection Strategies
2.2.1. Automated Analysis
Table 2: Automated analysis strategy for defect detection
Strategy / DescriptionIntegrated Development Environment checking / An Integrated Development Environment (IDE) that has auto detect features for coding standards will be used to check the teams’ code for type and syntax.
2.2.2. People Review
Table 3: People review strategies for defect detection
Strategy / Description /Grades / The teams artifacts are graded by the course TAs and instructors. This will help the team continue to prevent errors as the design continues.
IIV&V Reviews / The document artifacts for this project will be reviewed for content and consistency, and accuracy by an independent reviewer. These issues will be tracked in a defect tracking tool call Bugzilla, explained below.
Code Review / The team will be enlisting a code review process for all checked in code. This will ensure that at least one other person has reviewed the code for errors prior to committing to the test team.
Architecture Review Boards / The team will utilize ARBs to formalize the review of artifacts prior to moving on to the next step of the design process. These are held in partnership with the course instructors and TAs.
2.2.3. Execution Testing
Table 4: Execution testing strategies for defect detection
Strategy / DescriptionUnit Tests / The team will develop unit tests for new components of the system as the developer creates the component. These will be tested during regular build tasks. The Unit Tests will also be used by developers to test new code checked into the system as integration verification. Any failures will be added to the defect tracking system.
Acceptance Tests / The features that have been defined for the iteration will be tested against requirements and the test procedures defined for the case. If these fail, a defect will be added to the tracking system.
Beta Tests / The client will be notified of available features after they have been implemented and tested by the team. The client will have time to perform beta tests on the new features and report issues to the team. These will be documented in the tracking system.
2.3. Defect Removal Tracking
All defects will be added to Bugzilla for the team to manage the defect tickets. Tickets may be generated from the review of the documents from the IIV&V, tests that fail during acceptance testing, unit test failures, beta test errors, and many other forms of defect generation. The team will track defects based on the phased detected, priority, artifact with the defect, and other parameters to help clarify the details of the defect. These will help the team understand who can fix the defect, as well how to reproduce it. All defects will be monitored and tracked by the IIV&V team member to verify that they have been adequately addressed prior to any major milestone reviews. It is important to note that documents as well as execution code can be tracked in the system for issues.
2.4. Level of Service Achievement Monitoring
Table 5: Level of Service achievement strategy and its responsible person
Role / Responsible person / ResponsibilityFeasibility Analyst / Yuan-Chang Chang / The team member will analyze the system architecture and determine feasibility of components.
Prototyper / Chun-Ling Chen / The team member may use the prototyping process to analyze features for LOS goals.
IIV&V / Stewart Allen / The team member will monitor the project to make sure LOS are met.
2.5. Process Assurance
The process that is being followed has been defined by the CSCI 577 ab course instructors and TAs. The process is being followed and monitored by the project team as well as the course team in the form of the graders.
2.6. IIV&V Coordination
The coordination of issues is through the use of Bugzilla. All pertinent information about the issues are tracked and monitored through this system. As the IIV&V team member is off campus, and the project client is remote, the team is using a number of tools to collaborate on the issues that may need clarification. These tools include our FaceBook Group page, as well as Skype for verbal communication. If more detailed information is needed the team will occasionally utilize email.
3. Configuration Management
3.1. Product Element Identification
The following is a list of items including documents and development artifacts. This project utilizes an Architected Agile process.
Table 6: Product Elements
Product Element / Filename Convention / Responsible PersonOperational Concept Description (OCD) / OCD_XXX_F12a_T09_VX.X / Yen-Kuo Kao
Life Cycle Plan (LCP) / LCP_XXX_F12a_T09_VX.X / Chun-Pei Su
Feasibility Evidence Description (FED) / FED_XXX_F12a_T09_VX.X / Yuan-Chang Chang
Prototype (PRO) / PRO_XXX_F12a_T09_VX.X / Yen-Kuo Kao
System and Software Architecture Description (SSAD) / SSAD_XXX_F12a_T09_VX.X / Shao-yen Cheng
Win Conditions Prioritization / WinBook / Stewart Allen
Supporting Information Document (SID) / SID_XXX_F12a_T09_VX.X / Chun-Ling Chen
Quality Management Plan / QMP_XXX_F12a_T09_VX.X / Stewart Allen
Test Plan (TP) / TP_XXX_F12a_T09_VX.X / Stewart Allen
Iteration Plan (IP) / IP_XXX_F12a_T09_VX.X / Chun-Ling Chen
Acceptance Test Plan (ATP) / ATP_XXX_F12a_T09_VX.X / Stewart Allen
Software Modules / Whole version numbers for major release. Minor version for updates and patches. / All Team Members
Table 7: Priority of Product Elements in Each Phase
Product Element / PriorityExploration phase / Valuation phase / Foundations phase / Development phase / Operation phase
Operational Concept Description (OCD) / M / H / VH / H / L
Life Cycle Plan (LCP) / VL / H / H / H / VL
Feasibility Evidence Description (FED) / VL / H / VH / H / VL
Prototype (PRO) / VL / H / VH / VH / L
System and Software Architecture Description (SSAD) / VL / H / VH / VH / L
Win Conditions Prioritization / VL / H / VH / VH / VL
Supporting Information Document (SID) / VL / M / M / M / VL
Quality Management Plan / VL / VL / H / H / VL
Test Plan (TP) / VL / VL / M / VH / H
Iteration Plan (IP) / VL / VL / H / H / L
Acceptance Test Plan (ATP) / VL / VL / VL / VH / M
Software Modules / NA / NA / L / VH / H
3.2. Configuration Item and Rationale
The items listed below are elements that need to be tracked from the project inception to delivery and maintenance. The table below lists those elements that the UDM project team plans to track and deliver.
Table 8: Configuration Item and Rationale
Configuration Item / Description / Rationale / Volatility / Impact Severity /Operational Concept Description (OCD) / Concept of operations of the new system defined. / This document describes the operational concept and is volatile early on. / Very High early / Changes here will affect all documents in this table.
System and Software Architecture Description (SSAD) / Architecture of the system / This document is needed to understand the system and make changes in further phases if needed. / High early / Changes here will drive the project changes
Acceptance Test Plan (ATP) / Test plan containing requirement and success of tests. / This document will come into effect at the end, but is important to maintain throughout the project and deliver in the end / High early. / This document is critical to gaining acceptance test
Software Modules / The software / These are the software modules that will run the website. These will be volatile early in development. / High in the development phase / Changes here need to be tested, and affect all aspects of the project
3.3. Configuration Change Management
All Change Requests will be submitted to Bugzilla and assigned as a desired feature. The change request will be discussed by the group and assessed against the project schedule, and the team will determine feasibility. If all stakeholders agree to the change, then the team will assign the feature to the team member in Bugzilla, and the member will make the proposed modification.
All Problem Reports will be entered into Bugzilla as a defect. The team member that is assigned to the defect will review it and report back to the group the impact of the proposed defect and any resolution items that will impact the other project elements. The resolution will be documented following the change and the defect will have its status changed to ready for onsite testing. The build and test team member will be responsible for pushing out the modification to the live system.
3.4. Project Library Management
All documents will be stored on the team’s website, categorized by the project phase. The team members will do peer reviews and independent verification on the documents here. If any defects are determined in the documents, an issue will be documented in Bugzilla. The responsible team member will address the issue and upload a new revision of the document to the team website. The team member will note the modification in the document history.
A GIT repository will be used by the team with a connection to a drop box repository to store all source files for the website. Files will be checked in to the repository, with notes indicating the feature change or defect that resulted in the modification. When a major milestone has been reached a new version of the website will be created.
3.5. Resources and Personnel
Team Website – Team Members – all team members will be responsible for uploading modifications to the documents they “own”. Stewart Allen will be responsible for the independent review of the documents to make sure they reflect issues identified in Bugzilla.
Configuration Management – Stewart Allen – verify that all documents are named according to the defined pattern.
GIT Repository and Dropbox – Stewart Allen and Shao-yen Cheng – setup and configure the source repository for the team. Verify that team members are uploading changes in accordance with the process.
3.6. Tools
The team will utilize a number of tools for the management of quality and configuration management of team artifacts. First, Bugzilla is used to manage defects with documents and source, including problem reports, and change requests. Second the team will utilize a team website to manage the changes made to the project documents. Finally, the team will utilize GIT and Dropbox to manage the source code modifications and source versioning.
QMP_FCP_F12a_T09_V2.0.doc 8 Version Date: 11/18/2012