Management Quality Plan (QMP)
Version 1.0
Quality Management Plan (QMP)
THAI STUDENT ASSOCIATION (THSA) WEBSITE
TEAM # 12
Poonchana Thitametakul Amrit Pal Singh Ishita Gupta Dhwanit Purohit Niket Ashesh Khushboo Bindlish Kunal Jain Yunsheng Lei
Client Project Manager, Feasibility Analyst Operational Concept Engineer Prototyping Engineer Requirements Engineer Systems Architect Life Cycle Planner, Assistant Shaper IIV & V and SRE
QMP_F07_T12_V1.0
Date : 10/29/2007
Quality Management Plan (QMP)
Version 1.0
Version History
Date 10/29/0 7 Author Kunal Jain & Ishita Gupta Versio n 1.0 Changes made Original template for use with LeanMBASE v1.9 Rationale Initial draft
QMP_F07_T12_V1.0
Date : 10/29/2007
Quality Management Plan (QMP)
Version 1.0
Table of Contents
QUALITY MANAGEMENT PLAN (QMP).........................................................................1 VERSION HISTORY..........................................................................................................2 TABLE OF CONTENTS....................................................................................................3 ..........................................................................................................................................4 TABLE OF TABLES..........................................................................................................4
A.1. Purpose ...................................................................................................................................................................4 A.1.1 Overview........................................................................................................................................................5 A.1.2 References......................................................................................................................................................5 A.2. Quality Management Strategy................................................................................................................................5 A.2.1 Defect Prevention Strategies..........................................................................................................................6 A.2.2 Defect Detection Strategies...........................................................................................................................7 A.2.3 Defect Removal Tracking..............................................................................................................................8 A.2.4 Level of Service Achievement Monitoring...................................................................................................8 A.2.5 Process Assurance..........................................................................................................................................9 A.2.6 IV&V Coordination.....................................................................................................................................10
QMP_F07_T12_V1.0
Date : 10/29/2007
Quality Management Plan (QMP)
Version 1.0
Table of Tables
A.1.
Purpose
QMP_F07_T12_V1.0
Date : 10/29/2007
Quality Management Plan (QMP)
Version 1.0
A.1.1 Overview
This document is the Quality Management Plan version 1.0 for the Thai Student Association Website developed by team 12. The purpose of the Quality Management Plan is to balance the mutual satisfaction along the lines of Win-Win negotiations between the stakeholders. It also helps the developers to develop software efficiently and helps the product to meet the client's expectations.
A.1.2 References
LeanMBASE Guidelines Version 1.9 http://greenbay.usc.edu/csci577/fall2007/site/guidelines/LeanMBASE_Guidelines_V1.9.pdf Operational Concept Description (OCD) Version 1.7 http://greenbay.usc.edu/csci577/fall2007/projects/team12/LCO/OCD_LCO_F07a_T12_V1.7.pdf System and Software Requirements Description (SSRD) Version 1.3 http://greenbay.usc.edu/csci577/fall2007/projects/team12/LCO/SSRD_LCO_F07a_T12_V1.3.pd f System and Software Architecture Description (SSAD) Version 1.1 http://greenbay.usc.edu/csci577/fall2007/projects/team12/LCO/SSAD_LCO_F07a_T12_V1.1.pd f Life Cycle Plan (LCP) Version 1.2 http://greenbay.usc.edu/csci577/fall2007/projects/team12/LCO/LCP_LCO_F07a_T12_V1.2.pdf Feasibility Rationale (FRD) Version 1.2 http://greenbay.usc.edu/csci577/fall2007/projects/team12/LCO/FRD_LCO_F07a_T12_V1.2.pdf Support Information Document (SID) Version 1.3 http://greenbay.usc.edu/csci577/fall2007/projects/team12/LCO/SID_LCO_F07a_T12_V1.3.pdf CS577a Website http://greenbay.usc.edu/csci577/fall2007/site/index.html
A.2.
Quality Management Strategy
QMP_F07_T12_V1.0
Date : 10/29/2007
Quality Management Plan (QMP)
Version 1.0
A.2.1 Defect Prevention Strategies
Primary Defect Prevention Strategies
People practices
Description
Client and developers meeting are held which brings together business area people in a highly focused environment which reduces the likelihood of errors. Through Wiki Win-Win tool negotiations between the developers and clients are held. There will not be major requirement changes after WinWin negotiation agreements. The team will doing development in early phases to catch defects if any. The team will implement the core requirements first and will also adhere to the requirements, design & coding standards. Checklist will be used in order to verify that the team is following the standards and the guidelines. Traceability will help check the mapping between the documents. This will help in identifying the defects in an early stage. Team will be using PHP and MySQL for the development of THSA website. This will help the team in making & testing the site in early stages. Prototype is developed to ensure all the stakeholders have understood the proposed system well. Prototype can serve to avoid misguided development activities by providing a common platform for comprehension of the way the
Priority
High
Standard
Medium
Languages Prototyping
Medium
High
QMP_F07_T12_V1.0
Date : 10/29/2007
Quality Management Plan (QMP) new system will operate; thereby reducing risks and design changes. Dart tool will be used to identify High the major risks. Then plans can be made before hand to mitigate those risks.
Version 1.0
Root Cause Analysis
Table 1: Primary Defect Prevention Strategies
A.2.2 Defect Detection Strategies
Automated Analysis Name Description
Simple Syntax Check Browser will be used for checking the various warning and errors during the development of the code. This will help in mitigating the defects. Checks the consistency between the requirements and the design of the artifacts. This will be done at every phase.
Priority
Nominal
Consistency Checking
High
Table 2: Defect Detection Strategies Automated Analysis
Peer Reviews Name
IIV&V Review
Description
Formal Review done by IIV&V person to check the consistencies and defects in various artifacts. Agile Artifact Review process is implemented by him to report concerns. Review done by the entire team to discuss the various discrepancies between the artifacts using basic checklists. Informal review of artifacts done by the members in pairs aiming towards defect detection.
Priority
High
Team Review
High
Pair Review
Nominal
QMP_F07_T12_V1.0
Date : 10/29/2007
Quality Management Plan (QMP)
Table 3: Defect Detection Strategies Peer Reviews
Version 1.0
Testing Name
Ad hoc testing
Description
Basic test debuggers to remove the defects encountered at the initial stages. First unit testing will be performed on various modules. Then integration testing will be carried out on various integrated modules.
Priority
Low
Basic Test Data management
Nominal
Table 4: Defect Detection Strategies Testing
A.2.3 Defect Removal Tracking
Problem, issue, and defect reporting tracking and are identified by all the developers constantly. Frequent meetings are held to discuss and resolve any of the above. All the stakeholders are encouraged to review the artifacts of the THSA project. Weekly progress reports are uploaded which are easily accessible by every member of the team. The weekly progress report has the following sections: Top Risks- Top risks which were faced by the team and the plans which are made to mitigate those risks. Defects- The number of defects which were made & removed by the team. Effort Charts- Two charts displaying the cumulative project effort and project progress for that particular week. The QFP person is responsible for monitoring and analyzing the defects encountered by the developers. He ensures that all the risks and defects are mitigated and corrected by the assigned person from the team before achieving the milestone. All the issues and concerns should be addressed and discussed by all the members.
A.2.4 Level of Service Achievement Monitoring
In order to achieve the Level of Service goals, every team member should identify the probable risks and work towards mitigating them. The responsibility of each member is as follows: Table 5: Roles and Responsibilities. Role Project Manager Responsibility Regularly arrange meetings between the client and the developers to ensure that the Level of Service goals are Date : 10/29/2007
QMP_F07_T12_V1.0
Quality Management Plan (QMP)
Version 1.0
achieved as per the clients need. Quality Focal Point Person Constantly monitors the project and works towards achieving high quality product. He maintains a high standard of work which ensures minimal defects and a satisfied client. Developers They together work towards achieving the Level of Service goals. They frequently hold meetings to review each others work and aim at mitigating any kind of risks or concerns. IIV&V He provides constant feedback to the developers which aim at achieving the Level of Service goal, and report any problems to Quality Focal Point Person.
A.2.5 Process Assurance
In order to ensure delivery of high quality software product, we use the following process assurance techniques: Project plans - This contains the plan which the team is going the follow the coming week. It has all the tasks done with their dates and duration in it also showing the milestones achieved. The plan is updated every week by the LCP person. Accordingly, roles and responsibilities are assigned to each team member in order to achieve the desired milestones within the assigned time frame. Quality Management Plan The team follows the project plan for achieving the goals of the project. This includes thoroughly checking the artifacts to ensure the goals mentioned in the OCD are attained by developing the prototype which is in compliance with the requirements mentioned in the SSRD document. The architecture diagram developed by the system architect is based on the framework of the prototype approved by the client. Feedback & Reviews The feedback control helps to plan more efficiently. Iterative calculations of project schedule and effort can be done through it. A balance of workload is made among the team members. Team members can split the tasks and responsibilities amongst themselves. The responsibilities are distributed according to the skills and preferences of each member. If problems occur they can be efficiently rescheduled and resolved at an early stage. The Integrated Independent Verification and Validation member (IIV &V) monitors the documents prepared by the developers. This helps the team to get another opinion on the document, the good features in it, its errors and the critical concerns. In addition to the peer reviews, reviews by the staff, TAs and the mentor for our team are highly beneficial in ensuring high quality of the artifacts. This helps the team in understanding and improving the artifacts. LEVEL OF SERVICES QMP_F07_T12_V1.0 Date : 10/29/2007
Quality Management Plan (QMP)
Version 1.0
The various levels of services for our project obtained after the Win-Win negotiation with the client and the roles of team members in achieving them are laid out in the following table:Table 6: Level of Services Levels of Services LOS-1 : Average System Availability Roles and responsibilities System should be developed in accordance with the possible reasons and causes of failures. The developers should take all theses factors into consideration. The testers need to test the system with various test inputs in order to ensure robustness of the system. The system should be supported by IE (v6 and higher) and Firefox (v1.5 and higher). For this, the developers should fo...