Quality Management Plan (QMP) Version 4.0
Quality Management Plan (QMP)
CRCD Management System
Team 11
Muzzammil Imam – Project Manager, Implementer
Jason Loewy - Implementer
Fan Xu – Trainer, Tester, Implementer
Adarsh Khare – Trainer, Tester, Implementer
Kathleen Barrera – IIV&V, Quality Focal Point
2/15/12
11
QMP_IOC1_S12b_T11_V4.0 Version Date: 3/26/12
Quality Management Plan (QMP) Version 4.0
Version History
Date / Author / Version / Changes made / Rationale /10/24/11 / Team / 1.0 / · Adding Purpose and Quality Management Strategy / · Initial draft for DCP
11/14/11 / DG / 2.0 / · Completed Remaining Sections / · Completing document
11/17/11 / Erik / 2.1 / · Footer filename updated, FCP to DCP / · Perfectionist
12/08/11 / Erik / 2.2 / · Elaborated User acceptance testing / · Daniela Feedback
2/6/12 / Kathleen / 3.0 / · Added SVN, updated group members / · Spring 2012 Draft Rebaseline
2/15/12 / Kathleen / 3.1 / · Update document to final RDCP / · RDCP
3/26/12 / Kathleen / 4.0 / · Update document for Initial Operational Capability (IOC#1) / · IOC
Table of Contents
Quality Management Plan (QMP) i
Version History ii
Table of Contents iii
Table of Tables iv
Table of Figures 1
1. Purpose 2
1.1 Purpose of the QMP 2
1.2 Status of the QMP 2
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 4
2.5 Process Assurance 5
2.6 IIV&V Coordination 6
3. Configuration Management 6
3.1 Product Element Identification 6
3.2 Configuration Item and Rationale 7
3.3 Configuration Change Management 9
3.4 Project Library Management 11
3.5 Resources and Personnel 11
3.6 Tools 12
11
QMP_IOC1_S12b_T11_V4.0 Version Date: 3/26/12
Quality Manage Plan (QMP) Version 4.0
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 4
Table 6: Product Element Identification 6
Table 7: Configuration Item and Rationale 7
Table 8: Resources and Personnel 11
Table 9: Quality Management Tools 12
11
QMP_IOC1_S12b_T11_V4.0 Version Date: 3/26/12
Quality Manage Plan (QMP) Version 4.0
Table of Figures
Figure 1: Configuration Management Process 9
1. Purpose
1.1 Purpose of the QMP
The Quality Management Plan will document the planning and testing of the CRCD system. To ensure that the system is built to meet requirements there will be thorough testing of NDI functionality and integration. In order to make sure that bugs are found and removed there will be test cases developed. The QMP will record all plans for Process and Product assurance during the development of the CRCD Management System.
1.2 Status of the QMP
The QMP has been updated for the Initial Operational Capability package.
2. Quality Management Strategy
2.1 Defect Prevention Strategies
Table 1: List of defect prevention strategies
Strategy / DescriptionWin-Win Negotiations / Identified the priorities, relative penalties, and estimated effort of the Win Conditions for all the stakeholders.
Incremental Commitment Spiral Model / A method of development that specifies roles, responsibilities, workflow, and deliverables for each stages of the project. Emphasis on heavy planning and documentation for traceability and accountability.
Functional Prototyping / By building prototypes using the chosen NDIs, the prototyping effort can carry over to the final product.
Feasibility Evidence / Gathering evidence of the business case and identifying risks is a necessary step of the Incremental Commitment Spiral Model to ensure that at each step there is not excessive risk introduced to prevent moving to the next step. This ensures the correct quality stakeholders validate the evidence and risk as well as deliverables created thus far.
Valuation Package / Creating UML modeling and flowcharts will allow the client to validate the workflows to ensure their needs are accurately captured and represented before development commences.
Bug/Defect Tracking Process / Reviewing each artifact and identifying and prioritizing defects and enhancements to the system allows all team members to be aware of potential problems or alternate implementations.
Test Case Driven Development / Formulating test cases will ensure to categorize both happy and alternate flows will build confidence in the system and test functionality. Test cases will be valued and executed, and all test cases will map specifically to Win conditions from the client.
2.2 Defect Detection Strategies
2.2.1 Automated Analysis
Table 2: Automated analysis strategy for defect detection
Strategy / DescriptionPHP Syntax Checking / Check PHP files for any syntax errors on the development server or use the following website: http://www.meandeviation.com/tutorials/learnphp/php-syntax-check/v4/syntax-check.php
Form Validation / Dreamweaver cs5/codeigniter 2.0 automated checking tools.
Test Case Analysis / Executing test cases will provide a good idea of whether important criteria are met to pass the application. Defects will be identified and tracked through a bug-tracking software known as Bugzilla.
2.2.2 People Review
Table 3: People review strategies for defect detection
Strategy / DescriptionPeer Review / Each component will have two team members assigned to review the functionality and integration with connected components.
Usability Testing / Client will test the system to provide usability data.
Code Review / Glue code will be reviewed by the DEN student, the Project Manager, and one other member of the development team to ensure correctness.
Test Case Review / Test cases will be reviewed for completeness and to ensure that all win conditions are met. Any inconsistencies or ambiguity in test case writing will be corrected before the test cases are executed
Ad-hoc/User Acceptance Testing / Users will use version of the software to ensure the workflows make sense and all interactions function correctly. This will also build confidence in the application with the customer.
2.2.3 Execution Testing
Table 4: Execution testing strategies for defect detection
Strategy / DescriptionUnit Testing / Each NDI being developed (Handpunch Manager, Timetrex, and Inventory Management) will be tested independently to ensure that they are functioning as needed. Each of their functions will also be tested on benchmark data to test the each individual unit of the software.
Integration Testing / The interface between Handpunch Manager and Timetrex needs extensive testing. Also, the sharing of data between Timetrex and Inventory Management needs to be verified.
User Acceptance Testing / Shannon and Jerry from CRCD will step through the Use Cases during the Core Capability Drivethrough to make sure the system works as promised and is easy enough for them to operate.
2.3 Defect Removal Tracking
The team will be using Bugzilla for defect tracking. The workflow will be as follows:
1. A report for a defect will be entered into Bugzilla. Usually this will be done by IIV&V, but for peer reviews this could be performed by a team member. This will specify the build in which the issue was reported
2. Bugzilla will send an e-mail to the owner of the defect.
3. The owner will work out a resolution to the defect and update bugzilla.
4. IIV&V will either verify the resolution as adequate and close the bug, or inform the owner that more work is needed.
5. If not resolved, the process will repeat again.
On the last week of each iteration, new development will halt to give the team time to resolve outstanding defects before moving on to the next iteration. Any functionality not completed in the current iteration will have to carry over to the next iteration.
2.4 Level of Service Achievement Monitoring
Table 5: Level of Service achievement strategy and its responsible person
Level of Service / Role / Responsible person / ResponsibilityLOS-1 Response time preferably within 10 seconds, but not more than one minute. / System Architect / Muzzammil / Proposing a software architecture style that can handle this kind of response time, even if it means adding some replicated components and connectors.
Developer / Team / Remain faithful to the proposed software architecture and should try to optimize the code as much as possible.
LOS-2 Scalability: The system should be able to handle 100 employees. / System Architect / Muzzammil / The proposed software architecture should be flexible enough to support any future growth in the number of users.
Prototyper / Jason / Load test 100 dummy users of different roles
LOS-3 The system should be available during working hours from 8am to 6pm (PST) under normal conditions of operation (no power failure, no server crashes, etc.) / System Architect / Muzzammil / The system architect should make sure that there are some components in place to handle exceptions. Also, it would be his responsibility to propose a backup plan for the system in case of failure.
Developer / Team / Remain faithful to the proposed software architecture and should implement error handling in most of the cases.
2.5 Process Assurance
Because the ICSM is a mature and robust process, the team will be following the ICSM Electronic Process Guide (EPG). By following the guide, the team will assure that our documents and deliverables arrive on time and with defects markedly reduced.
All work products and documentation will be reviewed by the teaching staff and the IIV&V to catch any errors and omissions. After each document review, the team will address the feedback to ensure quality before moving on to the next phase of the ICSM.
All bugs and defects will be tracked with Bugzilla and the team will be using X for source control. With each iteration the team will develop new code, integrate, and then resolve outstanding bugs before proceeding to the next iteration.
2.6 IIV&V Coordination
The IIV&V student will communicate with the On-Campus development team regarding expected product deliverables, referencing the Project Plan, evaluating packages from each iteration. Any time the IIV&V student needs to discuss matters with development, they will use the forums of email or phone, depending on the priority of the defect. When evaluating packages formally, they will submit bugs or defects to the Bugzilla bug tracking system. These bugs will be addressed by the team who will investigate and update the status. The IIV&V is responsible for reporting the overall status of the quality management based on the bugs detected and will contact the team members to make necessary revisions. The IIV&V is responsible for updating the Bugzilla portal as issues become addressed on a regular basis and communicating back and forth with team members for issues that are still outstanding. As all defects are addressed, they will verify their closure and submit reports.
3. Configuration Management
3.1 Product Element Identification
Table 6: Product Element Identification
Product Element / Description / Naming Convention / MilestonesFED / Feasibility Evidence Description / FED_[Milestone]_F11a_T11_VX.Y.doc / VCR, FCR, DCR
LCP / Life Cycle Plan / LCP_[Milestone]_F11a_T11_VX.Y.doc / VCR, FCR, DCR
OCD / Operational Concept Description / OCD_[Milestone]_F11a_T11_VX.Y.doc / VCR, FCR, DCR
PRO / Prototype / PRO_[Milestone]_F11a_T11_VX.Y.doc / FCR, DCR
QMP / Quality Management Plan / PRO_[Milestone]_F11a_T11_VX.Y.doc / FCR, DCR
SID / Supporting Information Document / PRO_[Milestone]_F11a_T11_VX.Y.doc / FCR, DCR
SSAD / System Software Architecture Definition / PRO_[Milestone]_F11a_T11_VX.Y.doc / FCR, DCR
SSRD / System Software Requirements Definition / PRO_[Milestone]_F11a_T11_VX.Y.doc / FCR, DCR
UML / Unified Modeling Language Diagrams / PRO_[Milestone]_F11a_T11_VX.Y.doc / DCR
3.2 Configuration Item and Rationale
Table 7: Configuration Item and Rationale
Configuration Item / Description / Rationale / Volatility / Impact Severity /FED / Feasibility Evidence Description / This artifact reports overall how feasible the project is when factoring all risks and benefits. This rationale is supported by evidence. / Moderate / Moderate
LCP / Life Cycle Plan / This artifact defines the logistics of why the project is being developed, what will be accomplished, when artifacts will be delivered and who is responsible for them, as well as methods employed for development and review. / Low / High
OCD / Operational Concept Description / This artifact is the description of how the stakeholders envision the product and may change over multiple iterations / Low / High
PRO / Prototype / This artifact gives the stakeholders a working model of the future system and is revised as the client gives feedback. / High / High
QMP / Quality Management Plan / This artifact specifies how defects are reported and addressed to make this process as efficient as possible. / Low / Low
SID / Supporting Information Document / This artifact provides supplemental information about the project in general, also specifies terminology. / Low / Low
SSAD / System Software Architecture Definition / This artifact is a reference document for how the system architecture is created and identifies all the different objects involved. / High / High
WWPT / WinWin Prioritization / This artifact contains the requirements for the system based on the win conditions created by the stakeholders. / High / High
UML / Unified Modeling Language Diagrams / This artifact presents the system architecture in a graphical format. As the SSAD is updated, so is this document. / Moderate / High
3.3 Configuration Change Management
Figure 1: Configuration Management Process
If a change is needed, with the product, the following steps will be executed. A change can be requested based on a defect, changed requirement by stakeholder, or needs of the developers. The user who is reporting the defect will input the issue into an issue tracking program and the project team collectively through email/in-person meetings will decide the priority of the change and whether it can be deferred or needs to be addressed in the next build.
The Project Manager will assign the owner of that particular component to the fix. Once the code is updated, the changes will be checked into a document control system. This will go through a review process via another developer, as well as the IIV&V team member. If the new build is satisfactory, the changes will be considered baselined. If not, the reviewer will communicate via a meeting/email or other written communication the outstanding defect, and the assigned developer will complete the re-work and repeat the aforementioned process steps.