Quality Management Plan (QMP) Leamos

Transcription

1 Quality Management Plan (QMP) Leamos Team 7 Name Address Primary Role Secondary Role Monty Shah montysha@usc.edu Project Manager Life Cycle Planner David Wiggins dgwiggin@usc.edu IIV&V Off-campus Shaper Pragya Singh pragyasi@usc.edu System Architect Prototyper Shantanu Sirsamkar sirsamka@usc.edu Requirements Engineer Feasibility Analyst Suchita Doshi suchitad@usc.edu Prototyper Operational Concept Engineer Swapnil Savdekar savdekar@usc.edu Life Cycle Planner System Architect 11/30/11

2 Version History Date Author Version Changes made Rationale 10/22/11 David Wiggins 1.0 Added initial text for purpose, Initial draft status, and quality management strategy sections. 11/13/11 David Wiggins 2.0 Added initial text for Initial draft for QMP#2 Configuration Management sections. 11/21/11 David Wiggins 3.0 Changed document version Delivery of the DC 11/30/11 David Wiggins 3.1 Added changes requested by the TA TA updates QMP_DCP_F11a_T07_V3.1.doc 11/30/11

3 Quality Management Plan (QMP) Version 3.1 Table of Contents Quality Management Plan (QMP)...i Version History... ii Table of Contents... iii Table of Tables...iv 1. Purpose Purpose of the QMP Status of the QMP Quality Management Strategy Defect Prevention Strategies Defect Detection Strategies Defect Removal Tracking Configuration Management Product Element Identification Configuration Item and Rationale Configuration Change Management Project Library Management Resources and Personnel Tools... 9 iii

4 Table of Tables Table 1: List of defect prevention strategies... 2 Table 2: People review strategies for defect detection... 2 Table 3: Product Element Identification... 5 Table 4: Configuration Item and Rationale... 6 iv

5 1. Purpose 1.1 Purpose of the QMP The QMP is used to document the current state of balance between all success holders mutual satisfaction. It is heavily dependent on win-win negotiations to define this balance. The process of writing and updating the QMP helps the developers to identify and integrate efficient strategies to identify, document, resolve, and prevent defects in their work. It also discusses strategies the team uses to maintain configuration management. 1.2 Status of the QMP This is the first version of the QMP. Initial text for the purpose of the QMP and Quality Management Strategy has been added. This document belongs to the DC. 1

6 2. Quality Management Strategy 2.1 Defect Prevention Strategies Table 1: List of defect prevention strategies Strategy Win-Win ICSM Internal Code Review Prototyping Win-Win negotiations are held to cover high-level requirements so that all stakeholders are satisfied ICSM templates and standards are used to ensure we use good software engineering/design practices. The team reviews each other s code before each milestone. Before official development begins we prototype the core functionality to be developed. 2.2 Defect Detection Strategies Automated Analysis For the coding tasks of the project, we ll be able to use the compiler output as well as error logging to identify and fix bugs People Review Table 2: People review strategies for defect detection Strategy Individual Review Team Review IIV&V Informal Review Team members are expected to conduct an informal review of their own work before they upload it to the website Team members are asked to conduct informal reviews of the work done by teammates IIV&V can be asked to do a brief informal review if deliverables are completed ahead of schedule in order to do a quick scrub of trivial defects such as grammar and punctuation. This is an effort to allow the IIV&V to concentrate more on technical defect detection during 2

7 IIV&V formal Review TA reviews/grades the document Architecture Review Board (ARB) formal review. IIV&V does a formal structured review of the document for technical details and professionalism. Defects found during this review are entered into Bugzilla. The TA does a formal structured review of the document for technical details and professionalism. Defects found during this review are entered into Bugzilla. During the ARB the team presents their work and stakeholders are allowed to review, comment on, and suggest improvements Execution Testing No formal code development has begun. Strategies for defect detection in executable deliverables have yet to be established. The client has asked a third party to set us up with a sandbox environment to develop in. Our finished product will not go public until it has passed all tests and even then the customer may decide to wait until a strategic date for release rather than deploying at the end of the semester. 2.3 Defect Removal Tracking Level of Service Achievement Monitoring No Level of Service requirements have been identified in win-win negotiations with the client Process Assurance The team uses Bugzilla to track all document defects. The IIV&V DEN student reviews documents and enters defects into this tool. The defects are then addressed by the author of that document. Furthermore, we have a weekly tag-up meeting every Saturday to discuss any issues the team is having such as schedule, expectations, and up-coming deliveries we need to prepare for. 3

8 2.3.3 IIV&V Coordination Standard end of week tag up plus one short mid-week tag up using Google+ hangouts Win-win negotiation sessions Bug tracking activities through Bugzilla Audio recordings of interactions with the client Phone calls and texts when necessary 4

9 3. Configuration Management 3.1 Product Element Identification The following table describes the product elements of the project. The priority column is broken into 6 parts for the ICSM phases, E Evaluation phase V Valuation phase F Foundation phase D Development phase T Transition phase O Operational phase The priority ratings for the products are as follows, H high M medium L Low N Not applicable Table 3: Product Element Identification Product Element Owner Priority Versioning File Name Convention E V F D T O Operational Concept Suchita Doshi H H M L L L for each Life Cycle Plan Monty Shah L M H M M L for each Feasibility Evidence Supporting Information Document Monty Shah M H H H L L for each Swapnil Savdekar N N L M L L for each OCD_<_nam e>_f11a_t07_vx.x. doc/pdf LCP_<_nam e>_f11a_t07_vx.x. doc/pdf FED_<_nam e>_f11a_t07_vx.x. doc/pdf SID_<_name >_F11a_T07_VX.X. doc/pdf 5

10 Product Element Owner Priority Versioning File Name Convention E V F D T O System and Software Architectural UML Model Quality Management Plan Pragya Singh N N M H H L for each Swapnil Savdekar David Wiggins N N N N H M N/A N N N H M M for each SSAD_<_na me>_f11a_t07_vx. X.doc/pdf N/A QMP_<_nam e>_f11a_t07_vx.x. doc/pdf Transition Plan Monty Shah N N N N H L N/A N/A Acceptance Test David Wiggins N N N M H H for each ATPC_<_na Plan and Cases me>_f11a_t07_vx. X.doc/pdf Iteration Plan Monty Shah N N N L M L for each IP_<_name> _F11a_T07_VX.X.do c/pdf 3.2 Configuration Item and Rationale Configuration items are described in the following table. The impact severity has three categories, Severe vital to system success Important system success unlikely without Not severe helpful to system success, but system could be built without Table 4: Configuration Item and Rationale Configuration Item Operational Concept Rationale Volatility Impact Severity Describes Centralized place Volatile at first Severe, defines project benefits, for product when project system capabilities, description goals and requirements goals capabilities are still being decided 6

11 Configuration Item Life Cycle Plan Feasibility Evidence Supporting Information Document System and Software Architectural UML Model Quality Management Plan Transition Plan Acceptance Test Plan and Cases Rationale Volatility Impact Severity Defines Keep the project Not volatile Severe, tracks milestones, on track since the class deadlines schedule, issue dictates planning timeframe Provides evidence that the project can be accomplished Links evidence provided between items Diagrams the system architecture and interaction with the system Details of the SSAD Describes the methods for validating the system Requirements for project transition Enumerates test cases for system success The document decides if the project should continue, it answers the question, does this project make sense? Provides traceability of requirements, risk, issues and test cases that could be lost otherwise Basis for development the system with Guides the implementation of the system Processes to follow to ensure the system meets Leamos needs Promotes smooth transition from the old system to the developed product This document says whether or not the product is acceptable Very volatile, when capabilities change or risks present themselves this document can change Very volatile, as new issues are presented this document changes Volatile during design, and when development problems arise, stabilizes after development Volatile if issues arise Stable, system should change to support management plan Stable Stable for the same reasoning as the QMP Severe Not severe Severe, defines system architecture Severe Important Important Important 7

12 Configuration Item Iteration Plan Rationale Volatility Impact Severity Defines what is Guideline of Volatile, can Not severe done in the next tasks for the change with iteration team each iteration 3.3 Configuration Change Management Code based artifacts will be managed in subversion. Periodic builds will be tagged in subversion. Code that is checked in is expected to build successfully. Before each build is tagged, the team will have an internal code review to identify bugs. Bugs will be entered into Bugzilla and tracked to closure by the QFP. 3.4 Project Library Management The team s documents will be kept in on the Leamos team website. The configuration items are stored per phase, and are maintained by the development team. 3.5 Resources and Personnel Subversion will be hosted on a private free account with XP-Dev ( Project Role Name Quality Assurance Roles IIV&V David Wiggins Creation and maintenance of the Quality Management Plan Creation and maintenance of the Assurance Test Plan and Cases Test case development Package reviews Quality Focal Point David Wiggins Execution of test cases Validations of test cases Peer review initiator Create user survey Project Manager Monty Shah Enforcing the Quality Management Plan Client AnaMaria Ruiz, Carlos Gomez Identify pilot users for testing 8

13 3.6 Tools The required quality assurance tools are: Apache Subversion for version control o Subclipse for integrating Eclipse and Subversion o Bugzilla Net based defect tracking system Firebug Firefox plug-in for website debugging o 9