Quality Management Plan (QMP)

Transcription

1 Quality Management Plan (QMP) UDM United 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 QMP_FCP_F12a_T09_V2.0.doc i Version Date: 11/18/2012

2 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 QMP_FCP_F12a_T09_V2.0.doc ii Version Date: 11/18/2012

3 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 Purpose of the QMP Status of the QMP Quality Management Strategy Defect Prevention Strategies Defect Detection Strategies Defect Removal Tracking Level of Service Achievement Monitoring Process Assurance IIV&V Coordination Configuration Management Product Element Identification Configuration Item and Rationale Configuration Change Management Project Library Management Resources and Personnel Tools... 8 QMP_FCP_F12a_T09_V2.0.doc iii Version Date: 11/18/2012

4 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 iv Version Date: 11/18/2012

5 Table of Figures No table of figures entries found. QMP_FCP_F12a_T09_V2.0.doc v Version Date: 11/18/2012

6 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 Status of the QMP The QMP has all of the sections completed for the QMP #2 document delivery. QMP_FCP_F12a_T09_V2.0.doc 1 Version Date: 11/18/2012

7 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 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. 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 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 Defect Detection Strategies Strategy Integrated Development Environment checking 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 People Review Table 3: People review strategies for defect detection Strategy Grades IIV&V Reviews The teams artifacts are graded by the course TAs and instructors. This will help the team continue to prevent errors as the design continues. 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. QMP_FCP_F12a_T09_V2.0.doc 2 Version Date: 11/18/2012

8 Strategy Code Review Architecture Review Boards Strategy Unit Tests Acceptance Tests Beta Tests 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 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 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 Level of Service Achievement Monitoring Table 5: Level of Service achievement strategy and its responsible person Role Responsible person Responsibility Feasibility Analyst Yuan-Chang Chang The team member will analyze the system architecture and determine feasibility of components. QMP_FCP_F12a_T09_V2.0.doc 3 Version Date: 11/18/2012

9 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 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 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 . QMP_FCP_F12a_T09_V2.0.doc 4 Version Date: 11/18/2012

10 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_F12a_T09_V2.0.doc 5 Version Date: 11/18/2012

11 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 Changes here will affect all documents in this table. High early Changes here will drive the project changes QMP_FCP_F12a_T09_V2.0.doc 6 Version Date: 11/18/2012

12 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 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_F12a_T09_V2.0.doc 7 Version Date: 11/18/2012

13 When a major milestone has been reached a new version of the website will be created 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 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