Quality Management Plan (QMP)

Transcription

1 Quality Management Plan for LEMA Family Accountability System Version 3.3 Quality Management Plan (QMP) PROJECT TITLE LEMA FAMILY ACCOUNTABILITY SYSTEM TEAM NO #04 TEAM MEMBERS & ROLES NAME ROLES Teawon Han Project Manager Zhen Huang Feasibility Analyst Ziming Wei Operational Concept Engineer Xiaoli Ma Life Cycle Planner Ying Yang Life Cycle Planner Ian Williams Requirements Engineer Kimberly Krause IIV&V / System Requirements Engineer 12/05/2011 QMP_DCP_F11a_T04_V3.3.doc i Version Date: 12/05/2011

2 Quality Management Plan for LEMA Family Accountability System Version 3.3 Version History Date Author Version Changes made Rationale 10/24/11 Kimberly Krause 2.1 Initial version of QMP Initial version of QMP 11/07/11 Kimberly Krause 3.1 Added Configuration Management section Fixed defects from last release Configuration Management section is now needed for the DCP. 11/21/11 Kimberly Krause 3.2 Minor formatting updates Updated 2.5 TA made comments that needed to be addressed 12/05/11 Kimberly Krause 3.3 Defect adjudication Updating based on IIV&V comments from version 3.2 QMP_DCP_F11a_T04_V3.3.doc ii Version Date: 12/05/2011

3 Quality Management Plan for LEMA Family Accountability System Version 3.3 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 Purpose of the QMP Status of the QMP Quality Management Strategy Defect Prevention Strategies Defect Detection Strategies Defect Removal Tracking Level of Service Achievement Monitoring Process Assurance IIV&V Coordination Configuration Management Product Element Identification Configuration Item and Rationale Configuration Change Management Project Library Management Resources and Personnel Tools QMP_DCP_F11a_T04_V3.3.doc iii Version Date: 12/05/2011

4 Quality Management Plan for LEMA Family Accountability System Version 3.3 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... 2 Table 4: Execution testing strategies for defect detection... 3 Table 5: Level of Service achievement strategy and its responsible person... 4 Table 6: Configuration Item and Rationale... 9 QMP_DCP_F11a_T04_V3.3.doc iv Version Date: 12/05/2011

5 Quality Management Plan for LEMA Family Accountability System Version 3.3 Table of Figures No table of figures entries found. QMP_DCP_F11a_T04_V3.3.doc v Version Date: 12/05/2011

6 1. Purpose 1.1. Purpose of the QMP The Quality Management Plan (QMP) outlines the measures a project will take to ensure that a quality product is produced. This QMP includes the methods for defect prevention, detection, and removal as well as the plans for configuration management of the LEMA family accountability system project Status of the QMP The QMP is currently in version 3.3 which was developed as part of the foundations phase for the Development Commitment Point (DCP). In this version information about a texting prototype was added to section 2.1 and various typos throughout the document were fixed. QMP_DCP_F11a_T04_V3.3.doc 1 Version Date: 12/05/2011

7 2. Quality Management Strategy 2.1. Defect Prevention Strategies Strategy Win-Win Negotiation Prototyping Incremental Commitment Spiral Model Standard Database Standard Table 1: List of defect prevention strategies Description Win-win negotiation is being used to be sure all stakeholders agree and are clear on what will be delivered. This prevents defects when some stakeholders think different things are being done than what is actually happening The UI is being prototyped to ensure that the clients will be satisfied. The reports will also be prototyped to ensure that when the database is designed that all the necessary data to generate those reports are taken into consideration. A prototype of the texting service was also developed to ensure that the Mozeo texting service would work with our application and meet the clients needs. The team is using a standard software engineering process with task lists, artifacts, and templates to ensure that work products conform to best practices. Since both the LEMA Family Accountability System and the LEMA Scheduler System must use a shared database for some features a standard database will be co-designed by the teams to prevent future integration defects Defect Detection Strategies Strategy Syntax and type checking Automated Analysis Table 2: Automated analysis strategy for defect detection Description An Integrated Development Environment (IDE) with PHP and SQL syntax checking will be used to automatically check defects in syntax, typos, variable types, etc People Review Table 3: People review strategies for defect detection QMP_DCP_F11a_T04_V3.3.doc 2 Version Date: 12/05/2011

8 Strategy IIV&V Document Reviews Graded Artifacts Architecture Review Boards Peer Reviews Strategy Unit Testing Integration Testing Acceptance Testing Beta Testing Description All artifacts are reviewed by the teams Integrated Independent Verification And Validation (IIV&V) member for consistency, content, etc. All defects found by this method are entered into our defect tracking process (see section 2.3). All artifacts are submitted for grading by the 577 class Teaching Assistants (TAs). All comments made by the TAs are entered into our defect tracking process (see section 2.3). Architecture Review Boards (ARBs) are held periodically to formally assess the progress of the project with the class instructors, TAs, clients, and the development team. All findings from the ARB are entered into our defect tracking process (see section 2.3). All developed code will be peer reviewed by at least one other project developer. All defects found will be entered into our defect tracking process (see section 2.3) Execution Testing Table 4: Execution testing strategies for defect detection Description Each developer will test their own software methods and modules as they are developed. Defects from this testing will not be added to the defect tracking process since the tester is also the content author. As individual developers methods and modules are integrated to form the main system all interfaces between the existing system and the newly added methods and modules will be tested to ensure the interface is working correctly and that any defects in that module the developer may have missed are found. All defects found will be entered into our defect tracking process (see section 2.3). At each staged delivery the features being delivered to the client will be tested to ensure that they meet the requirements in the project s SSRD. All defects found will be entered into our defect tracking process (see section 2.3). After each delivery the clients and representative users will be asked to test the system. This testing will help to ensure that the system meets the needs of the users. Defects found during this testing will be collected from each user and entered into the defect tracking process (see section 2.3) Defect Removal Tracking Whenever a review or test is done by someone other than the artifact author any defects found will be entered into the team s Bugzilla defect database. Each problem will be categorized by the artifact, defect priority, category, phase detected, review type, and other parameters to make analysis of the defects in the database easier. QMP_DCP_F11a_T04_V3.3.doc 3 Version Date: 12/05/2011

9 When a defect is detected, the reviewer will enter the defect into Bugzilla (Graded artifacts, ARBs, and Beta Testing is an exception to this, in these cases the reviewer is not part of the development team and the IIV&V team member will enter the collected defects at a later time.). Each artifact produced by the team will have owner listed in the database that is responsible for that artifact who will receive an once the defect is submitted. The owner will then check the defect in Bugzilla and assess the problem. The owner will then set the status of the defect to resolved and document the resolution. At this time the person that reported the defect will receive an to verify that the problem has been solved and close the defect. All defects should be resolved or closed before an artifact is submitted for a milestone Level of Service Achievement Monitoring Table 5: Level of Service achievement strategy and its responsible person Role Responsible person Responsibility Feasibility Zhen Huang Analyst Analyze the system architecture to determine if it is sufficient to achieve level of service goals. Research alternative solutions to meet level of service goals. Prototyper Ian Williams Prototype possible solutions to meet level of service goals. IIV&V Kimberly Krause Monitor and track progress towards meeting level of service goals Process Assurance Due to time constraints and the small size of the project no process assurance activities are done by the team. However the process for this project is mandated by the instructors of CS577 and thus the deliverables and activities required for the class mandate that the Incremental Commitment Spiral Model (ICSM) is followed. The team will ensure that process is followed by turning in all artifacts required by the class on time IIV&V Coordination Much of the coordination between IIV&V and other members of the development team is accomplished through the s sent automatically from the team s defect tracking process (see section 2.3). If an artifact owner or the IIV&V team member is unclear about the meaning of a comment made in Bugzilla however further discussions can be held through . If the issue is one that necessitates a team-wide or client discussion a meeting will be scheduled and the IIV&V team member will participate using Skype. QMP_DCP_F11a_T04_V3.3.doc 4 Version Date: 12/05/2011

10 3. Configuration Management 3.1. Product Element Identification The following sections identify each project element and artifact. The name of the element, its owner, priority during each phase of the project, file name convention, and conventions for version numbers is listed for each element. Operational Concept Description OCD Owner: Ziming Wei Evaluation: High Developing operation concept to determine what the system should do and if this would be a worthwhile project. Valuation: High Defining the new operational concept in more detail and using it to drive requirements. Foundation: Medium At this point the operational concept is less important because the SSRD is more mature and can drive design. Development: Low In development phase the SSRD and SSAD drive development. Operations: High New operational concept is put into place and acceptance testing occurs. File name convention: OCD_<milestone>_F11<a/b>_T04_V<version number>.pdf The minor version numbers denote different drafts during a single phase of the document and are incremented for each version of the file that is uploaded on wiki-spaces or the project team site. Life Cycle Plan LCP Owner: Xiaola Ma and Ying Yang Evaluation: High The LCP includes the project plan which is important to maintain all throughout project development. Valuation: High The LCP includes the project plan which is important to maintain all throughout project development. Foundation: High The LCP includes the project plan which is important to maintain all throughout project development. Development: High The LCP includes the project plan which is important to maintain all throughout project development. Operations: Low The main project has come to end so the life cycle plan is not nearly as important. File name convention: LCP_<milestone>_F11<a/b>_T04_V<version number>.pdf QMP_DCP_F11a_T04_V3.3.doc 5 Version Date: 12/05/2011

11 The minor version numbers are incremented for each version of the file that is uploaded on wiki-spaces or the project team site to denote different drafts during a single phase of the document. Feasibility Evidence Description FED Owner: Zhen Huang Evaluation: High The risks outlined in the FED are important to determine if the project is worth pursuing. Valuation: High In addition to the risks the FED also contains the business case analysis to determine the Return on Investment (ROI) for the project. Foundation: High Feasibility evidence is required to determine if the project should continue. Development: High Feasibility evidence is requirement to determine if the project should continue. Operations: Low Now that the project is mostly complete risks and feasibility evince become less important. File name convention: FED_<milestone>_F11<a/b>_T04_V<version number>.pdf The minor version numbers are incremented for each version of the file that is uploaded on wiki-spaces or the project team site to denote different drafts during a single phase of the document. System/Software Requirements Description SSRD Owner: Ian Williams Evaluation: None Not yet developed Valuation: High Requirements are being developed during this phase Foundation: High Requirements are refined and used to determine the system architecture Development: High System is developed according to the requirements Operations: High Systems operation is tested based on the requirements to determine if the system meets its goals. File name convention: SSRD_<milestone>_F11<a/b>_T04_V<version number>.pdf The minor version numbers are incremented for each version of the file that is uploaded on wiki-spaces or the project team site to denote different drafts during a single phase of the document. QMP_DCP_F11a_T04_V3.3.doc 6 Version Date: 12/05/2011

12 System/Software Architecture Document SSAD Owner: Teawon Han Evaluation: Low Not yet developed Valuation: Med Early stages of architecture are being developed Foundation: High Focus of this stage is on the architecture and prototyping Development: High System is being developed as per the architecture Operations: High Architecture documents continue to be very important for maintenance File name convention: SSAD_<milestone>_F11<a/b>_T04_V<version number>.pdf The minor version numbers are incremented for each version of the file that is uploaded on wiki-spaces or the project team site to denote different drafts during a single phase of the document. Prototype Report PRO Owner: Ian Williams Evaluation: None Not yet developed Valuation: Med Low fidelity prototypes are being developed Foundation: High Focus of this stage is on the architecture and prototyping Development: High Prototypes are transformed into pieces of the final system, prototypes are also used for client and user feedback to improve the system. Operations: Low Once development is nearing the end the prototypes are no longer as important. File name convention: PRO_<milestone>_F11<a/b>_T04_V<version number>.pdf The minor version numbers are incremented for each version of the file that is uploaded on wiki-spaces or the project team site to denote different drafts during a single phase of the document. Supporting Information Document SID Owner: Teawon Han Evaluation: None Not yet developed Valuation: Low This document contains supporting information Foundation: Low This document contains supporting information Development: Low This document contains supporting information Operations: Low This document contains supporting information File name convention: SID_<milestone>_F11<a/b>_T04_V<version number>.pdf QMP_DCP_F11a_T04_V3.3.doc 7 Version Date: 12/05/2011

13 The minor version numbers are incremented for each version of the file that is uploaded on wiki-spaces or the project team site to denote different drafts during a single phase of the document. : Quality Management Plan QMP Owner: Kimberly Krause Evaluation: None Not developed until valuation phase Valuation: Medium Needed for project process and organization Foundation: Medium Needed for project process and organization Development: High During development configuration management is needed to ensure that code is not being updated by multiple developers at the same time and overwritten. Operations: High Quality Management is very important during acceptance testing and when the product is first delivered to the customer. File name convention: QMP_<milestone>_F11<a/b>_T04_V<version number>.pdf The minor version numbers are incremented for each version of the file that is uploaded on wiki-spaces or the project team site to denote different drafts during a single phase of the document. Software Modules Owner: All team members Evaluation: None not yet developed Valuation: None not yet developed Foundation: Low, modules are prototypes only at this point Development: Very High main focus of this stage Operations: High main deliverable and will be acceptance tested during this phase. File name convention: TBD Versioning: Whole version numbers (1.0, 2.0) used for major deliverables, minor version numbers (1.1, 1.2) used for smaller updates Configuration Item and Rationale Configuration items are project elements that need to be tracked throughout the project and delivered at the end of the project to be used for further project development and maintenance. Table 6 contains a list of configuration items for the LEMA Family Accountability project. QMP_DCP_F11a_T04_V3.3.doc 8 Version Date: 12/05/2011

14 Config. Item OCD SSRD SSAD Software Modules Table 6: Configuration Item and Rationale Description Rationale Volatility Impact Severity Operational Concept Description System and Software Requirements Description System and Software Architecture Description Software Modules Document describes the operational concept of the new system, is volatile in the evaluation and valuation phase. Contains the prioritized requirements for the system. Requirements that do not make it into this version of the system will be used for further development. Volatile in valuation phase. Contains the architecture of the system which is important to understand for maintenance and further development. Volatile in the valuation and foundations phase. The software modules are the code that will run for the final system, these will be highly volatile early in the development phase and become more stable as development continues. Very high early in project High early in project High early in project High early in developme nt phase 3.3. Configuration Change Management Changes in the OCD will drive changes in the requirements, architecture and software. Changes in the SSRD will drive changes in the architecture and software. Changes in the SSAD will drive software changes. Changes in software can drive changes in other software modules; also all changes will need to be retested. Change Requests (CRs) will be submitted to Bugzilla as enhancements whenever a stakeholder feels a change is desired in the system. That change will be evaluated by the assigned developer to determine feasibility and impact to schedule. For major changes that will have an impact to commitments and project schedule the item will be brought up and prioritized at the next client meeting. If all stakeholders agree that the change should be made the developers will make the change. For more minor changes that would not have an impact to project commitments and schedule the clients will be contacted by to be sure they approve the change, if the clients approve the change will be made. Problem Reports (PRs) will be submitted to Bugzilla as defects whenever a stakeholder finds a defect or problem in the system. The problem will be evaluated by the QMP_DCP_F11a_T04_V3.3.doc 9 Version Date: 12/05/2011

15 assigned developer. If the problem will have an impact on other developers work, the project commitments, or the project schedule the developer will give a recommendation at the next client meeting and the stakeholders will determine the path forward. If the problem can be fixed by the developer without an impact to other developers work, project commitments, and schedule the change will be made and documented in Bugzilla Project Library Management Documents will be stored in two different ways depending on their status. Working versions of documents will be stored on the team s wiki to allow the teams to do peer reviews and co-develop documents when needed. Final versions of documents for commitment review deliverables will be moved to the team site which will be the team s official configuration management repository for documents. A subversion repository will be used to store code under configuration management. Files will be checked out when a developer needs to work on it and then checked in with a new minor version number when complete. When a milestone is reached each file will be given a major version number and submitted Resources and Personnel Configuration Management Teawon Han ensure that all documents and project artifacts follow correct naming conventions and are versioned correctly when they are uploaded to the team site. Team Site Administration Teawon Han set up and maintain the team site which is used as the official configuration management repository. Wiki-spaces Administration Kimberly Krause set up and maintain the team wiki which is used to store and share working copies of documents Tools The development team will use three tools for quality and configuration management. The first, Bugzilla, is used for quality management to record defects, Change Requests (CRs) and Problem Reports (PRs). The second is our team wiki, which is used to share working versions of the teams reports, meeting minutes and other information between team members. Last is the project team site which is used for project deliverables for each phase and acts as our document repository for official configuration management versions. QMP_DCP_F11a_T04_V3.3.doc 10 Version Date: 12/05/2011