Quality Management Plan (QMP) UDM United 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 QMP_FCP_S13b_T09_V2.2.doc i Version Date: 1/27/2013
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 12/2/2012 Stewart Allen 2.1 Modifications based on grading by course TAs 1/27/2012 Kelvin Zhu 2.2 Fixed spelling and grammar typos throughout document Updated team member list with members from Spring semester All sections due Need to incorporate grader modifications Correcting typos Updating with new team roster QMP_FCP_S13b_T09_V2.2.doc ii Version Date: 1/27/2013
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... 4 2.5. Process Assurance... 4 2.6. IIV&V Coordination... 5 3. Configuration Management... 6 3.1. Product Element Identification... 6 3.2. Configuration Item and Rationale... 7 3.3. Configuration Change Management... 8 3.4. Project Library Management... 8 3.5. Resources and Personnel... 9 3.6. Tools... 9 QMP_FCP_S13b_T09_V2.2.doc iii Version Date: 1/27/2013
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... 4 Table 6: Configuration Item and Rationale... 7 QMP_FCP_S13b_T09_V2.2.doc iv Version Date: 1/27/2013
Table of Figures No table of figures entries found. QMP_FCP_S13b_T09_V2.2.doc v Version Date: 1/27/2013
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. QMP_FCP_S13b_T09_V2.2.doc 1 Version Date: 1/27/2013
2. Quality Management Strategy 2.1. Defect Prevention Strategies Strategy Win-Win (WinBook, Negotiations) Prototypes Incremental Commitment Spiral Model Standard Web Designer Table 1: List of defect prevention strategies 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. 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. The development team is using a standard approach to developing the product. This will ensure that quality is designed prior to beginning to develop. 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 Strategy Integrated Development Environment checking 2.2.1. Automated Analysis Table 2: Automated analysis strategy for defect detection 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 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. QMP_FCP_S13b_T09_V2.2.doc 2 Version Date: 1/27/2013
Strategy IIV&V Reviews Code Review Architecture Review Boards Strategy Unit Tests Acceptance Tests Beta Tests 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. 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. 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 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. 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. 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. QMP_FCP_S13b_T09_V2.2.doc 3 Version Date: 1/27/2013
2.4. Level of Service Achievement Monitoring Table 5: Level of Service achievement strategy and its responsible person Role Responsible person Responsibility Feasibility Yuan-Chang Chang Analyst 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 CSCI577a course write-ups. Further, the individual team members are responsible for completing the artifact documents by the milestones defined on the CSCI577a 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. QMP_FCP_S13b_T09_V2.2.doc 4 Version Date: 1/27/2013
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. QMP_FCP_S13b_T09_V2.2.doc 5 Version Date: 1/27/2013
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 Person Operational Concept OCD_XXX_F12a_T09_VX.X Yen-Kuo Kao (OCD) Life Cycle Plan (LCP) LCP_XXX_F12a_T09_VX.X Chun-Pei Su Feasibility Evidence FED_XXX_F12a_T09_VX.X Yuan-Chang Chang (FED) Prototype (PRO) PRO_XXX_F12a_T09_VX.X Yen-Kuo Kao System and Software SSAD_XXX_F12a_T09_VX.X Shao-yen Cheng Architecture (SSAD) Win Conditions WinBook Stewart Allen Prioritization Supporting Information SID_XXX_F12a_T09_VX.X Chun-Ling Chen Document (SID) 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_XXX_F12a_T09_VX.X Stewart Allen (ATP) 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 Operational Concept (OCD) Life Cycle Plan (LCP) Explo ration phase Valuation phase Priority Foundations phase Development phase M H VH H L VL H H H VL Operation phase QMP_FCP_S13b_T09_V2.2.doc 6 Version Date: 1/27/2013
Feasibility VL H VH H VL Evidence (FED) Prototype (PRO) VL H VH VH L System and VL H VH VH L Software Architecture (SSAD) Win Conditions VL H VH VH VL Prioritization Supporting VL M M M VL Information Document (SID) Quality VL VL H H VL Management Plan Test Plan (TP) VL VL M VH H Iteration Plan (IP) VL VL H H L Acceptance Test VL VL VL VH M Plan (ATP) 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 Operational Concept (OCD) System and Software Architecture (SSAD) Rationale Volatility Impact Severity Concept of operations of the new system defined. Architecture of the system This document describes the operational concept and is volatile early on. This document is needed to understand the system and make changes in further phases if needed. Very High early High early Changes here will affect all documents in this table. Changes here will drive the project changes QMP_FCP_S13b_T09_V2.2.doc 7 Version Date: 1/27/2013
Configuration Item Acceptance Test Plan (ATP) Software Modules Rationale Volatility Impact Severity Test plan containing requirement and success of tests. The software This document will come into effect at the end, but is important to maintain throughout the project and deliver in the end These are the software modules that will run the website. These will be volatile early in development. High early. High in the development phase This document is critical to gaining acceptance test 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. QMP_FCP_S13b_T09_V2.2.doc 8 Version Date: 1/27/2013
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_S13b_T09_V2.2.doc 9 Version Date: 1/27/2013