Quality Management Plan (QMP) LEMA Pilot School Integrated Scheduling System. Team number 12 Name Primary Role Secondary Role David Wiggins Project Manager Developer Aakash Shah Prototyper Developer Kushalpreet Kaur Developer Developer Thammanoon Kawinfruangfukul Tester Developer Eunyoung Hwang Architect Developer Louis Demaria IIV&V Developer Mark Villanueva QFP Developer Sangik Park Developer Developer 3/23/2012
Quality Management Plan (QMP) Version 4.4 Version History Date Author Version Changes made Rationale 10/23/11 LD 1.0 Completed sections 1 and 2 of the Quality Management Plan (QMP) 11/14/11 LD 2.0 Completed all sections of the document 11/22/11 LD 3.0 Corrections based on feedback from TA 2/4/12 MV 4.0 - Status of the QMP - Tables 1,3,4,5 - Defect Removal Tracking - IIV&V Coordination - Product Element Identification - Resources and Personnel - Configuration Change Management - Project Library Management - Resources and Personnel - Configuration Item and Rationale Initial checkin of the Quality Management Plan (QMP) While additional changes to the document are expected in the future all sections are complete. Fixing errors found in the document. Updates for Draft RDCP Package submission - Tools 2/15/12 TK 4.0 - Status of the QMP Updates for RDCP Package submission 3/23/12 MV 4.2 - Team table on Cover page - Table of contents - Various Tables Updates for bug fixes ii
Table of Contents Quality Management Plan (QMP)...i Version History...ii Table of Contents...iii Table of Tables...iv Table of Figures... v Purpose... 1 Purpose of the QMP... 1 Status of the QMP... 1 Quality Management Strategy... 2 Defect Prevention Strategies... 2 Defect Detection Strategies... 2 Automated Analysis...2 People Review...3 Execution Testing...3 Defect Removal Tracking... 3 Level of Service Achievement Monitoring... 4 Process Assurance... 4 IIV&V Coordination... 4 Configuration Management... 6 Product Element Identification... 6 Configuration Item and Rationale... 7 Configuration Change Management... 8 Project Library Management... 9 Resources and Personnel... 10 Tools... 10 QMP_RDCP_S12b_T12_V4.2.doc ii Version Date: 03/23/12 i
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... 3 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_RDCP_S12b_T12_V4.2.doc i Version Date: 03/23/12 v
Table of Figures v
Purpose Purpose of the QMP The purpose of the Quality Management Plan (QMP) is to document balancing of the desires of success critical stakeholders along the lines identified in the win-win negotiations. Each stakeholder may have a different idea of what quality means to them. Each stakeholder also expects to be delivered a product that they consider to be a quality product. A plan must be created to ensure that all success critical stakeholders are delivered a quality product. This document outlines this plan. Status of the QMP This is version 4.1 of the QMP document. This iteration of the document is part of the Rebaselined Development Commitment Package and reflects changes to multiple sections based on new team members, new scope, and modifications to the overall quality process. All sections remain intact and complete. 1
Quality Management Strategy In order to ensure that a quality product is delivered to the customer several defect prevention, defect detection, and defect removal strategies will be used. Defect Prevention Strategies Table 1: List of defect prevention strategies Strategy Win-Win Incremental Commitment Spiral Model Standard Dry run Status Meetings Rapid Prototyping Buddy Checks Code inspection The win-win methodology will be used to ensure that all stakeholders' win conditions are met when the final product is delivered. By using the Incremental Commitment Spiral Model templates and guidelines, the artifacts produced will have the correct format and substance. A dry run will be performed before every presentation in order to ensure that all presenters are properly prepared and ready to present. Hold at least one weekly meeting where all team members are present to discuss the current state of the project Quickly standing up functional prototypes that address the stakeholders functional needs and user interface requirements. Distribute draft versions of the artifacts to all team members for review prior to the official submission Static analysis of code will be used to identify defects. Defect Detection Strategies Automated Analysis Table 2: Automated analysis strategy for defect detection Strategy Compiler Checking Unit testing The code that requires compilation in our system will be automatically checked at compile time for syntax errors. Unit testing will be performed on new pieces before these individual 2
People Review pieces are added to the system. Table 3: People review strategies for defect detection Strategy Peer Review Architecture Review Board Code Review The person responsible for IIV&V is responsible for reviewing documentation that is presented in order to ensure that there are no errors contained in the delivered document. An Architecture Review Board is used in order to ensure that the customers as well as all other stakeholders are in agreement with the manner in which the project is moving forward. Distribute source code to IIV&V and developers. Reviewers will flag potential issues and provide comments to the authors. Execution Testing Strategy Unit Testing Acceptance Testing User Group Survey Table 4: Execution testing strategies for defect detection Unit testing will be performed on new pieces as they are added to the overall project Acceptance testing of the system will be performed before the system is delivered to the customer to ensure that the customer receives a system that meets their needs. Hold at least one Test Group activity with the website s intended user base to gather opinions and comments which can later be rolled into the system Regression Test Informal test of known functionality that may have changed as a result of adding new code or modifying existing source. Defect Removal Tracking The team will utilize the online Bugzilla tool for defect reporting, tracking, and subsequent removal. As Testers and IIV&V discover bugs, they will be added to Bugzilla, with notification being automatically sent to the author/implementer of the artifact/module. The QFP personnel will monitor the bug list and ensure it is resolved correctly and in a timely fashion. The QFP will also communicate with the responsible parties outside of Bugzilla in order to expedite the process. Finally, the QFP will generate a weekly report of existing bugs and required dates for closure. 3
Level of Service Achievement Monitoring The strategy for achieving level of service is described in the table below Table 5: Level of Service achievement strategy and its responsible person Role Responsible person Responsibility Feasibility Analyst David Wiggins Feasibility Evidence Tester, IIV&V, Focus Group Developers Louis DeMaria, Thammanoon Kawinfruangfukul David Wiggins, Aakash Shah, Kushalpreet Kaur, Thammanoon Kawinfruangfukul, Eunyoung Hwang, Louis Demaria, Sangik Park, Mark Villanueva Regarding LOS-1, the tester and IIV&V will assess the prototypes and provide feedback for improvement. We will also need to hold at least one focus group activity with of the intended users of the site. Regarding LOS-1, developers need to design the web pages using modern layout patterns that are easy to understand and use. Process Assurance Process Life Cycle Plan The Life Cycle Plan identifies deliverables and dates that said deliverables are due. This document is used to ensure adherence to a schedule and process. IIV&V Coordination The on-campus team members will communicate and coordinate with the remote IIV&Vers through remote means depending on the communication needs. For meetings that both the IIV&Vers and developers must attend, Skype will be used. For every day communication such as bug reporting and correcting as well as questions that do not 4
require a meeting, email and phone will be used. For notices sent out to the group as a whole email, a message to the Team 12 Google Group will send the message to everyone on the team. 5
Configuration Management Product Element Identification Versioning system Increment to X.0 (e.g. 1.0 to 2.0) for next phase transition, increment 0.1 for major revision within phase Item Life Cycle Plan Operation Concept System and Software Architecture System and Software Requirements Definition Feasibility Evidence Quality Management Plan Supporting Information Document Test Plan and Cases Transition Plan Filename Convention LCP_<package OCD_<package SSAD_<package SSRD_<package FED_<package QMP_<package SID_<package TPC_<package TP_<package Responsible Party Thammanoon Kawinfruangfu kul Eunyoung Hwang Eunyoung Hwang Thammanoon Kawinfruangfu kul Exploration Phase Priority Valuation Phase Priority Foundation Phase Priority High ium High High ium High High ium ium David Wiggins ium High ium Mark Villanueva Mark Villanueva ium Louis Demaria High Louis Demaria High 6
Configuration Item and Rationale Table 6: Configuration Item and Rationale Item Rationale Volatility Impact Severity Life Cycle Plan Operation Concept System and Software Architecture System and Software Requirements Definition Feasibility Evidence Quality Management Plan Supporting Information Document Test Plan and Cases Gives a general overview of the plan for system life. Establishes the shared visions, requirements, and objectives of the project. Document the analysis and design of the system being developed. Document the requirements of the project derived from negotiation. Needed to document the feasibility of the current project. Plan to ensure stakeholders are delivered a quality product. Needed to make a connection between all the documentation Test steps to verify the functionality of the system Used to plan the life cycle of the system from the beginning phases to system end of life. Ensures that all success critical stakeholders are on the same page during the project. Used to describe how the system is designed and how all the pieces fit and work together. Needed to outline a formal requirements agreement between all partied involved in the project. The feasibility of the project must be determined and recorded at each stage of the project. Used to ensure that all success critical stakeholders are delivered a quality product. All of the documentation that is created for the project needs to be consistent and correct. Vital artifact to verify that the system operations as intended and without critical bugs/faults ium High 7
Item Rationale Volatility Impact Severity Source code Baselined code The code baseline is source from which the system is built Very High Depending on the change and its dependency to other components, the impact could range from low to very high. Training and User manuals Training and reference materials Important document that will be used by Maintainers and operators of the new system Changes to the manuals should not affect the rest of the system Defect Report Created by QFP to track and detail defects in the system An important metric that can provide trend information: defect injection phases, affected modules, etc. Depending on where the defect is injected and how to remove it, the impact could range from low to very high. Configuration Change Management In the early stages of development document versions have been maintained by reviewing and revising documents and placing these documents on the project website. This has worked well for now as there are only a small number of documents to maintain. As the project moves forward into the development phase documents as well as source code will be maintained through a version control system using subversion. We will begin baselining documents upon delivery of the Draft RDC Package. Because of time and resource limitations, configuration change management needs to be a quick and workable process. If major changes needs to be made to the baseline, the person requesting the change should contact the entire team of the proposed change or discuss it during a group meeting, whichever method is more convenient. The software architect or project manager will then approve or reject the change. Before awaiting approval though, the individual developer is encouraged to implement the change to his own development area and unit test in his own sandbox. For recording purposes, the QFP will keep a record of the change requests. We will baseline the code after each teration, after substantial code changes, and at the end of the each phase. 8
Project Library Management Source code artifacts will be stored in the Subversion repository on greenbay: svn://greenbay.usc.edu Moreover, all versions of document artifacts will be saved there. The development repository houses test code artifacts. It is stored on a Google Project hosting site for the team.: http://code.google.com/p/csci577-lema Final drafts and class deliverables will be uploaded to the class project website: http://greenbay.usc.edu/csci577/spring2012/projects/team12 9
Resources and Personnel Louis DeMaria and Mark Villanueva will both be responsible for reviewing, quality and configuration management of the project. The allocation of the specific duties will be determined soon. Tools The team will be using the following tools for quality and configuration management related activities: Name Bugzilla Winbook Google code project Google groups Subversion Firebug Defect tracking and reporting Win conditions repository; used for raising issues, options, and agreements Online repository for code and artifact document versioning Online message board for collaboration amongst team members Software used for versioning and revision control of files Browser plugin for debugging HTML, CSS, Javascript, and other web development languages QMP_RDCP_S12b_T12_V4.2.doc 1 Version Date: 03/23/12 0