Quality Management Plan for UDMVersion 3.1
Quality Management Plan (QMP)
UDMUnited Direct Marketing
Team 09
Fall Semester
Chun-Ling Chen – Project manager/ Prototyper
Chun-Pei Su – Lifecycle Planner
Shao-yen Cheng – System Architect
Yuan-Chang Chang – Feasibility Analyst
Stewart Allen – IIV&V/ Requirements Engineer
Yen-Kuo Kao – Operational Concept Engineer
Spring Semester
Chun-Pei Su – Trainer / Document Maintainer
Shao-yen Cheng – Chief Developer
Stewart Allen – Tester / IIV&V / Quality Focal Point
Kelvin Zhu – Project Manager / Developer
Version History
Date / Author / Version / Changes made / Rationale10/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
12/2/2012 / Stewart Allen / 2.1 /
- Modifications based on grading by course TAs
- Need to incorporate grader modifications
1/27/2012 / Kelvin Zhu / 2.2 /
- Fixed spelling and grammar typos throughout document
- Updated team member list with members from Spring semester
- Correcting typos
- Updating with new team roster
2/19/2013 / Stewart Allen / 3.0 /
- Updating document to reflect new tools being used.
- Get ready for RDCP
3/31/2013 / Stewart Allen / 3.1 /
- Updating for IOC1
- Delivery of IOC1
Table of Contents
Quality Management Plan (QMP)
Version History
Table of Contents
Table of Tables
Table of Figures
1.Purpose
1.1.Purpose of the QMP
1.2.Status of the QMP
2.Quality Management Strategy
2.1.Defect Prevention Strategies
2.2.Defect Detection Strategies
2.3.Defect Removal Tracking
2.4.Level of Service Achievement Monitoring
2.5.Process Assurance
2.6.IIV&V Coordination
3.Configuration Management
3.1.Product Element Identification
3.2.Configuration Item and Rationale
3.3.Configuration Change Management
3.4.Project Library Management
3.5.Resources and Personnel
3.6.Tools
QMP_IOC1_S13b_T09_V3.1.doc1 Version Date: 3/31/2013
Quality Manage Plan (QMP) TemplateVersion x.x
Table of Tables
Table 1: List of defect prevention strategies
Table 2: Automated analysis strategy for defect detection
Table 3: People review strategies for defect detection
Table 4: Execution testing strategies for defect detection
Table 5: Level of Service achievement strategy and its responsible person
Table 6: Configuration Item and Rationale
QMP_IOC1_S13b_T09_V3.1.doc1 Version Date: 3/31/2013
Quality Manage Plan (QMP) TemplateVersion x.x
Table of Figures
No table of figures entries found.
QMP_IOC1_S13b_T09_V3.1.doc1 Version Date: 3/31/2013
Quality Management Plan for UDMVersion 3.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, 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-win negotiations are being held and the Win Conditions tracked in WinBook for this project. This is preventative due to the centralized 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 “outsource” a web designer to help prevent quality and defect issues with the look and feel of the design aspects of the project. By outsource I mean, the person is a secondary member of the team that lives in India but is not a member of CSCI577.
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 / DescriptionGrades / 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 called 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 phase 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 as 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 for support to LOS-1 regarding support for IE, Chrome, and Firefox web browsers, and determine the feasibility of the support.
Prototyper / Chun-Ling Chen / The Prototyper will develop preliminary style sheets that support the different browsers to help with LOS-1.
IIV&V / Stewart Allen / The team member will monitor the project to make sure LOS-1 is met. This will occur during testing, and the review of the FED and PRO documents.
2.5.Process Assurance
The team utilizes a number of activities to ensure that the quality process is implemented and achieved.
The first item is that each team member is personally responsible for their individual artifact creation and management. The team members will follow the ICSM process defined in the CSCI577ab course write-ups. Further, the individual team members are responsible for completing the artifact documents by the milestones defined on the CSCI577ab course website for assignment deliveries.
Next, the IIV&V process is implemented by Stewart Allen. In this process the documents and artifacts are scored and reviewed against correctness, and whether they meet the minimal exit criteria. Further, any issues identified in this process are documented and tracked in Bugzilla. Bugs from a prior review are verified for completion in the subsequent review. In this way, each defect is tracked, fixed, and verified.
Finally, the project manager for the team, Chun-Ling Chen, is responsible for organizing the team members and the client for meetings, and reinforcing the deadlines for the artifacts. This may occur at the team meetings, or frequently occurs on the team’s FaceBook Group site. This helps the team members receive frequent notifications of the deadlines for the process, and reinforcing the need to address defects. Further at team meetings and on the team Group Facebook page, the team members are notified frequently of outstanding issues by the Project manager and the IIV&V member.
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 SeverityOperational 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.
Subversion – 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 Subversion to manage the source code modifications and source versioning.
QMP_IOC1_S13b_T09_V3.1.doc1 Version Date: 3/31/2013