Quality Management Plan (QMP) Version 2.1
Quality Management Plan (QMP)
Student Scheduling System
TEAM #06
Douglass Kinnes: Project Manager, Quality Focal Point, Implementation Team member
Alexey Tregubov: System Architect, UML Modeler, Implementation Team member
Mihir Daptardar: Operational Concept Engineer, Quality Focal Point, Tester
Ihsan Tolga: Life Cycle Planner, Feasibility Analyst, Implementation Team member
Zheng Lu: NDI/NCS Evaluator, NDI/NCS Acquirer, Prototyper, Implementation Team member
Simone Lojeck: IV&V, Quality Focal Point, Shaper
11/25/2012
13
QMP_DCP_F12a_T06_V2.1.doc Version Date: 11/25/2012
Quality Management Plan (QMP) Version 2.1
Version History
Date / Author / Version / Changes made / Rationale /10/26/2012 / SL / 1.0 / · Created original file from template / · Initial draft in support of the Foundations Commitment Review (FCR)
10/27/2012 / SL / 1.1 / · Changed File name from “DCP” to “FCP” / · Corrected file name to correctly reflect next milestone.
11/19/2012 / SL / 2.0 / · Changed File name from “FCP” to “DCP”
· Updated Version #, dates, section 1.2 for new document.
· Updated Table 5 to address TA comments.
· Updated data in Section 3. / · Updated Document for QMP#2 submission during Foundations Phase.
11/25/2012 / SL / 2.1 / · Updated Version #, dates, section 1.2 for new document.
· Added cross-references for tables & figures and caption for table 11
· Updated minor wording changes throughout, / · Updated Document for Draft DC submission.
Table of Contents
Quality Management Plan (QMP) i
Version History ii
Table of Contents iii
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 3
2.3 Defect Removal Tracking 4
2.4 Level of Service Achievement Monitoring 5
2.5 Process Assurance 5
2.6 IIV&V Coordination 6
3. Configuration Management 7
3.1 Product Element Identification 7
3.2 Configuration Item and Rationale 8
3.3 Configuration Change Management 10
3.4 Project Library Management 12
3.5 Resources and Personnel 13
3.6 Tools 13
13
QMP_DCP_F12a_T06_V2.1.doc Version Date: 11/25/2012
Quality Management Plan (QMP) Version 2.1
Table of Tables
Table 1: List of defect prevention strategies 2
Table 2: Automated analysis strategy for defect detection 3
Table 3: People review strategies for defect detection 3
Table 4: Execution testing strategies for defect detection 4
Table 5: Level of Service achievement strategy and its responsible person 5
Table 6: Product Elements 7
Table 7: Priority of Product Elements in Each Phase 8
Table 8: Configuration Item and Rationale 9
Table 9: Change Configuration Levels 11
Table 10: Configuration Management Roles & Responsibilities 13
Table 11: Configuration Management Tools 13
13
QMP_DCP_F12a_T06_V2.1.doc Version Date: 11/25/2012
Quality Management Plan (QMP) Version 2.1
Table of Figures
Figure 1: Configuration Change Management Process Flow 11
13
QMP_DCP_F12a_T06_V2.1.doc Version Date: 11/25/2012
Quality Management Plan (QMP) Version 2.1
1. Purpose
1.1 Purpose of the QMP
The purpose of this Quality Management Plan (QMP) is to document the tasks and activities that will ensure satisfaction of the Team 06 stakeholders, i.e. a high degree of quality, for the Team 06 Project during the Fall 2012 semester.
1.2 Status of the QMP
This is an updated version of the Quality Management Plan in support of the Draft Development Commitment Package. Changes from the previous version (2.0) consist of minor wording changes throughout the document. All Sections have data provided based on the current status of the project.
2. Quality Management Strategy
This section contains the defect prevention, defect detection, defect removal strategies, and other quality management monitoring and coordination factors that will be employed during the Team 06 project.
2.1 Defect Prevention Strategies
The defect prevention strategies used for the Team 06 project to minimize and prevent defects are detailed in Table 1.
Table 1: List of defect prevention strategies
Strategy / Priority / DescriptionWin-Win / High / The WinBook tool will be used to facilitate the Win-Win methodology, which allows for stakeholders’ win conditions to be captured and tracked through implementation and delivery.
Incremental Commitment Model Standard / High / The Incremental Commitment Spiral Model process (maintained and taught by USC’s CCSE) will be used by Team 06 throughout the project. Templates and Guidelines for this process will be facilitated throughout the project to ensure artifacts are complete and correct.
Prototyping / High / Prototyping will be utilized in cycles to obtain stakeholder buy-in prior to committing decisions into code. Frequent reviews will ensure team and client buy-in.
Dry Run / High / Prior to each major presentation the team will conduct a run through of the material to be presented to ensure consistency, completeness, and cohesion.
Code Review / High / Team reviews of the code will be conducted regularly to address promptly any issues related to the code.
Project Reviews / High / Team reviews of the project status will be conducted regularly with and without the client to promptly address any issues related to the project status, process, or artifacts.
2.2 Defect Detection Strategies
This section details the strategies to be implemented by Team 06 in efforts to detect defects.
2.2.1 Automated Analysis
The Automated Analysis defect detection strategy is detailed in Table 2 with the associated priority.
Table 2: Automated analysis strategy for defect detection
Strategy / Priority / DescriptionDocument Correctness via automated artifact checking / High / For each artifact prepared for the team project, the word processor Spelling and Grammar checks will be executed.
Code syntactic and functional checks. / High / For each unit of code designed, either the compiler or design environment automated checks will be conducted regularly to ensure correctness of the code prior to testing.
Real-Time Code check / Very High / For those units of code designed within an environment that can check code formatting and syntax as the code is entered, these checks will be enabled so that defects can be address while the code is being generated.
2.2.2 People Review
The peer review defect detection strategy is detailed in Table 3 with the associated priority.
Table 3: People review strategies for defect detection
Strategy / Priority / DescriptionTeam Artifact process reviews / High / Regularly scheduled meetings are held with the team to review any pending issues that have arisen. These issues can cover artifact or code defects.
IIV&V Reviews / High / The team contains one member identified as the IIV&V role. This member has the responsibility of reviewing and verifying all products and artifacts.
Auxiliary Reviews / Normal / Ad hoc meetings will be conducted as needed to target special issues with products or artifacts. Defects noted/identified would be tracked to resolution as normal.
2.2.3 Execution Testing
The execution testing defect detection strategy is detailed in Table 4 with the associated priority and description. The execution testing techniques and documentation levels that will be used by Team 06 are noted.
Table 4: Execution testing strategies for defect detection
Strategy / Priority / DescriptionDefined test plan/procedures / High / Testing for this project will be conducted as per preconceived test plans/procedures tailored to the unit being tested and to the Win-Win conditions.
Value Based Document Review / High / Beginning with Foundations Commitment Review packages the artifacts for each milestone will be reviewed using the Value Based Review process.
Requirements based testing / High / Tests for the system will be designed to fulfill project requirements as captured in the Win-Win conditions. Results will be verified to trace back to satisfying a requirement.
2.3 Defect Removal Tracking
During the lifecycle of this project Team 06 will utilize a streamlined, online form of problem, issue and defect reporting and tracking. Bugzilla, maintained and provided for the team’s use by USC CSSE department, is a defect reporting and tracking tool with the capability of discerning between products, reviewers, as well as many other traits.
Bugzilla will be used by the Team to capture all defects for artifacts and products. After each review, whether by the IIV&V team member, Teacher’s Assistant, or multi-team member peer review, defects will be added to the system by the IIV&V member or peer review coordinator. Reports (in graphical or text/spreadsheet formats) can be generated from the system by any member, but primarily will be done by the IIV&V team member for publishing onto the team website. This provides universal viewing by all team members or other interested parties. Additional analysis on data from Bugzilla can also be performed in COTS plotting applications, such as Microsoft Excel, also for uploading to the website.
These uploaded reports/graphs will be renewed after each package review. In addition to the artifact based updates, results from continued tracking and verifying of the defects will be uploaded to the website on a weekly basis.
2.4 Level of Service Achievement Monitoring
The strategies employed by Team 06 in achieving Level of Service (LOS) requirements goals are shown in Table 5. These strategies are in support of the Level of Service requirements identified in the Feasibility Evidence Description document.
Table 5: Level of Service achievement strategy and its responsible person
Role / Responsible person / ResponsibilitySystem Architect / Alexey Tregubov / The architect will have primary responsibility to design the connections necessary to ensure LOS-1, Returned Results, where the database integrates with the user interface. Likewise, LOS-2 will require architecture that provides a 2 minute or less result.
Feasibility Analyst / Ihsan Tolga / The feasibility analyst will monitor the feasibility related artifacts to ensure Level of Service is achieved. For LOS-1 Returned Results, this would include primarily the documents confirming the data from the system, such as the Test Report and associated results. For LOS-2, this would include primarily the architecture defining and testing documents.
Quality Focal Point / Simone Lojeck / The QFP will monitor the status of the project with respect to stakeholder satisfaction. Level of Service requirements tracking will be among those items tracked. This will be done through the review and tracking of the results and architecture defining documents. LOS-1 Returned Results, will be monitored through the OCD, PRO, and Testing documents (Plan, Results). For LOS-2 this would include the primarily the SSAD, PRO and Test Results.
2.5 Process Assurance
Quality assurance in a software project following the Incremental Commitment process model is equated with ensuring successfully satisfying stakeholder win-win conditions. Each member of Team 06 has a specified role, but will also be working towards the goal of a high quality product.
The goal of the project is to provide services that allow students to generate a study plan, based on the requirements maintained by the advisors. Various formal/informal reviews of the artifacts and products are conducted by all team members to ensure the service requirements are met.
· Product Auditing: During the generation of the products, information reviews are conducted within the team. Issues are discussed and addressed with respect to the project requirements.
· Product Auditing: After the products are posted to the website, a formal review is conducted by the IIV&V/QFP role with respect to process adherence and requirements satisfaction. Defects at this stage are tracked/maintained formally within the defect tracking tool.
· Test/Review Monitoring: Once the products have been realized, the products will be put under various tests by the Tester to ensure satisfaction of the requirements. The team will assist and monitor as necessary. IIV&V role has the primary responsibility for verification and validation.
· Addressing Defects: During the life cycle of the project, defects for artifacts and products will be tracked and maintained. Each team member may assist in defect identification and/or resolution. The artifact/product author has the primary responsibility for addressing the defect. The IIV&V has the primary responsibility for defect tracking.
2.6 IIV&V Coordination
During the product life cycle, coordination between the team and the IIV&V role will be primarily conducted through electronic mediums. This includes Email and Skype instant messages. Below are some of the more comment methods:
· Team Meetings/reviews & Client Meetings are conducted on Skype.
· Products for the class are submitted via publishing onto the team website. Because this method is also visible by the IIV&V role, this is the method also used for submission for IIV&V review.
· Defects are tracked in the defect tracking tool Bugzilla, where communication is performed primarily through comments posted to each defect. Limited notification of defect changes within Bugzilla as well as auxiliary communication between team members are conducted via email.
3. Configuration Management
Configuration management (CM) of the products involved contributes greatly to the success of a project. CM is conducted not only on the project’s documents, but also (and more importantly) the project’s products through development, testing and operations. This section identifies the characteristics of the CM process for this project.
3.1 Product Element Identification
During the product life cycle, various artifacts will be generated and updated to capture project characteristics vital to project success. The current products are listed below in Table 6 and are prioritized in Table 7.
Table 6: Product Elements
Product Element / Filename Convention / Responsible PersonClient Interaction Report / CIR_VCP_F12a_T06_VX.X / Project Manager (Douglass Kinnes)
Operational Concept Description (OCD) / OCD_@CP_F12a_T06_VX.X / System Architect (Alexey Tregubov)
Life Cycle Plan (LCP) / LCP_@CP_F12a_T06_VX.X / Life Cycle Planner (Ihsan Tolga)
Feasibility Evidence Description (FED) / FED_@CP_F12a_T06_VX.X / Feasibility Analyst (Ihsan Tolga)
Effort Report / N/A – Online system, submitted weekly / Each Team Member provides a report
Project Plan / Week##_MPP_F12a_T06 / Project Manager (Douglass Kinnes)
Progress Report / Week##_PR_F12a_T06 / Project Manager (Douglass Kinnes)
Prototype Report (PRO) / PRO_@CP_F12a_T06_VX.X / Prototyper (Zheng Lu)
Client Meeting Notes / CIR_VCP_F12a_T06_VX.X / Project Manager (Douglass Kinnes)
System and Software Architecture Description (SSAD) / SSAD_@CP_F12a_T06_VX.X / System Architect (Alexey Tregubov)
Supporting Information Document (SID) / SID_@CP_F12a_T06_VX.X / Project Manager (Douglass Kinnes)
COTIPMO Report / N/A – Online system, submitted weekly / Life Cycle Planner (Ihsan Tolga) coordinates; Each team member takes survey
Quality Management Plan (QMP) / QMP_@CP_F12a_T06_VX.X / Quality Focal Point (Simone Lojeck)
Table 7: Priority of Product Elements in Each Phase