Quality Management Plan (QMP)

1,440 views
1,323 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,440
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
34
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Quality Management Plan (QMP)

  1. 1. Quality Management Plan (QMP) The Virtual Assistant Living and Education Program Team # 14 Team Members: Name Role Swetha Suryanarayanan Project Manager Nikita Valechha Requirements Engineer Kartik Sethi Plan and Control Engineer Shobana Govindan System Architect Bharat Mehndiratta Prototyper QMP_DCP_F08a_T14_V1.5 Version Date: 11/17/2008
  2. 2. Quality Management Plan (QMP) Version 1.5 Priyanka Nambiar Operation Concept Engineer Naveen Joy Shaper & IIV&V Mark Shehata QFP & IIV&V Pamela Clay Client Date: 11/17/2008 QMP_DCP_F08a_T14_V1.5 ii Version Date: 11/17/2008
  3. 3. Quality Management Plan (QMP) Version 1.5 Version History Date Author Version Changes made Rationale 10/26/08 Mark Shehata 1.0 • Original template including • Part 1 of QMP at the end of Section 1 , 2 Valuation phase. 11/11/08 Mark Shehata 1.1 • Updated Section1. • To reflect the new status of the QMP. 11/14/08 Mark Shehata 1.2 • Added Section 3 • Part 2 of QMP. 11/16/08 Mark Shehata 1.3 • Updated Section 2 • To reflect what the team really did and what is going to do. 11/16/08 Mark Shehata 1.4 • Updated section 3 • To reflect what the team really did and what is going to do. 11/17/08 Mark Shehata 1.5 • Updated some errors • Some errors were detected by PM QMP_DCP_F08a_T14_V1.5 iii Version Date: 11/17/2008
  4. 4. Quality Management Plan (QMP) Version 1.5 Table of Contents Quality Management Plan (QMP)...............................................................................................................................i Version History............................................................................................................................................................iii Table of Contents.........................................................................................................................................................iv Table of Tables..............................................................................................................................................................v Table of Figures............................................................................................................................................................vi 1. Purpose .....................................................................................................................................................................7 A.1.1 Purpose of the QMP....................................................................................................................................7 A.1.2 Status of the QMP........................................................................................................................................7 A.1.3 References.....................................................................................................................................................7 A.2. Quality Management Strategy 8 A.2.1 Defect Prevention Strategies.......................................................................................................................8 A.2.2 Defect Removal Tracking..........................................................................................................................10 A.2.3 Level of Service Achievement Monitoring...............................................................................................10 A.2.4 Process Assurance......................................................................................................................................11 A.2.5 IIV&V Coordination.................................................................................................................................12 A.3. Configuration Management...............................................................................................................................12 3.1 Product Element Identification...................................................................................................................12 3.2 Configuration Item and Rationale...............................................................................................................16 3.3 Configuration Change Management............................................................................................................20 3.4 Project Library Management.......................................................................................................................21 3.5 Resources and Personnel...............................................................................................................................22 3.6 Tools................................................................................................................................................................22 QMP_DCP_F08a_T14_V1.5 iv Version Date: 11/17/2008
  5. 5. Quality Management Plan (QMP) Version 1.5 Table of Tables Table 1: List of defect prevention strategies...............................................................................................................8 Table 2: Automated analysis strategy for defect detection.......................................................................................9 Table 3: People review strategies for defect detection...............................................................................................9 Table 4: Execution testing strategies for defect detection.........................................................................................9 Table 5: Level of Service achievement strategy and its responsible person..........................................................10 Table 6: Project artifacts and its responsible person...............................................................................................13 Table 7: Priority of each artifact in each phase.......................................................................................................14 Table 8: File naming convention guidelines.............................................................................................................15 Table 9: Artifacts and its volatility and impact severity.........................................................................................16 QMP_DCP_F08a_T14_V1.5 v Version Date: 11/17/2008
  6. 6. Quality Management Plan (QMP) Version 1.5 Table of Figures Figure 1: Flow of configuration change management.............................................................................................21 QMP_DCP_F08a_T14_V1.5 vi Version Date: 11/17/2008
  7. 7. Quality Management Plan (QMP) Version 1.5 1. Purpose A.1.1Purpose of the QMP The purpose of quality management (QM) is to balance stakeholders’ mutual satisfaction along the lines negotiable by the stakeholders in their win-win negotiations. So, the major purpose of this document is to identify the strategies and plans for ensuring quality (stakeholders’ satisfaction) for the living advantage Inc.’s content management system. By applying these strategies, we can minimize and remove the defects and maximize the quality of the product. A.1.2Status of the QMP This is the version 1.5. It includes section one, two and three. As the project is at Foundations phase, the QMP document should include defect prevention strategies, defect detection strategies and defect removal tracking .It should illustrate how to achieve level of service requirements defined in SSRD and explain how to use plan, standard and software development process to ensure the quality of development project and how to coordinate between development team and IIV&V team. Section three discusses configuration management, why and how. A.1.3References - Instructional ICM-Sw Electronic Process Guidelines: ICM EPG - Software Engineering, Edition 8, Ian Sommerville. - Team Website setup Guidelines. - Feasibility Evidence Description document version 2.5. - Team 14 Website. QMP_DCP_F08a_T14_V1.5 7 Version Date: 11/17/2008
  8. 8. Quality Management Plan (QMP) Version 1.5 A.2.Quality Management Strategy A.2.1Defect Prevention Strategies Table 1: List of defect prevention strategies Strategy Priority Description People Practices High The win-win Model is used to ensure that all stakeholders' win (Win-Win) conditions are met with the final implementation. The wiki win win tool is used in this strategy. People Practices High We did/will do dry run before each presentation in order to (Dry run) double check it. People Practices Low Team’s mentor provides some suggestions/comments and he (Mentor ) could help in preventing some defect. People Practices Medium The information and experience we got from the professors (Lectures & and TAs through the lectures and lectures notes help in Lectures Notes) preventing some defects that could happen due to lack of experience. People Practices High The Feasibility Analyst did a good analysis to ensure that the (Feasibility Study/ system is feasible to be developed and implemented. Analysis) People Practices High Using drafting for the critical artifacts and having been (Drafting) reviewed by the team members and TAs is a very helpful strategy to prevent defects in final versions. Weekly team Low The discussion that the team had in every meeting / call help in meeting/call preventing some minor and common defects. Standard High By using the Incremental Commitment Model templates and (Incremental guidelines, the artifacts produced should have the correct Commitment format and substance. This helps in avoiding common and Model for SW) repeating defects. Prototyping High Prototypes help the team in identifying some defects about user interface and other features (how the client will use them.) Languages Medium Our team will use MySQL and VB.NET in which the team has experience with them. QMP_DCP_F08a_T14_V1.5 8 Version Date: 11/17/2008
  9. 9. Quality Management Plan (QMP) Version 1.5 Defect Detection Strategies .2.1.1 Automated Analysis Table 2: Automated analysis strategy for defect detection Strategy Priority Description Traceability High Visual Studio.Net will help the developers in tracing errors and checking defects. Pre-condition, High During the development of the system, the developers will Post-condition, check the behavior by doing some automated module tests. Views Interface, behavior .2.1.2 People Review Table 3: People review strategies for defect detection Strategy Priority Description Independent High The IIV&V team reviews the artifact using agile artifact review review document and identify any defects in the concern log. Architecture High The Instructional staff and the client review all the major Review Board points in the project and detect any defect. (ARB) Peer reviews Medium The team did peer reviews for FED, UML and SSAD as these documents are very critical for the project especially SSAD and based on these reviews many defects were identified. .2.1.3 Execution Testing Table 4: Execution testing strategies for defect detection Strategy Priority Description Regression High Every time the code of any module has been changed due to improvement or bugs, all the test cases should be tested again. Test automation High Basic unit tests, integration test and acceptance test should be done to detect any defects. QMP_DCP_F08a_T14_V1.5 9 Version Date: 11/17/2008
  10. 10. Quality Management Plan (QMP) Version 1.5 A.2.2Defect Removal Tracking The defects are recorded in the agile artifact review document. The author / owner will be notified and responsible for removing the defects, and if the author / owner has any questions, The IIV&V will be available to answer them by email or phone. Also during the weekly meeting/call, if any defect or issue has been identified by graders or team members it will be removed or solved. Weekly reports help in determining how many defects we have and if our techniques and the way we use it are good enough or we need to improve the strategies to reflect on the quality. A.2.3Level of Service Achievement Monitoring The Quality Focal Point and IIV&V team are responsible for monitoring progress towards showing architectural achievability of level of service requirements (refer to Feasibility Evidence Description Document for more details) and progress towards actual achievability of level of service requirements in integration and testing. The following table identifies roles, responsible persons and responsibilities towards this strategy. Table 5: Level of Service achievement strategy and its responsible person Role Responsible person Responsibility Quality Focal Mark Shehata Monitor progress/quality towards achieving such Point requirements and write test cases and acceptance test directly with the client. IIV&V Mark Shehata , Feedback the team with any suggestions or Naveen Joy comments regarding the design or the code. Developers Bharat Mehndiratta , Research on how the product can achieve these Kartik Sethi requirements and develop the product that satisfies the level of service requirements. Testers Priyanka Nambiar Test the test cases, analyze the results and write the feedback to the QFP and IIV&V team. System Shobana Govindan Research on how the product can achieve these Architect requirements and design the architecture that support level of service requirements. QMP_DCP_F08a_T14_V1.5 10 Version Date: 11/17/2008
  11. 11. Quality Management Plan (QMP) Version 1.5 A.2.4Process Assurance In order to deliver a product with a high quality, process assurance focuses on the process of product development which includes plans, standards used, and other process assurance activities. The process checks the project deliverables to ensure that they are consistent with standards. Till now we have the following plans: - Project Plan: This is a plan for detailed project activities and the responsible person using MS project. - Life Cycle Plan: This identifies activities occurring in each phase. - Quality Management Plan: This describes strategies, processes, and resources that will be used in assuring project’s quality. We are going to have the following plans in the development commitment package: - Iteration Plan, which describes development module plan in each iteration in high level for CS577a and should be completed in CS577b. - Transition Plan, which describes a plan in project installation and project environmental set up in high level for CS577a and should be completed in CS577b. - Acceptance test plan and cases: describes all the testing that will be done, who will do the testing, what test cases will be done, what test data will be used, the environment for testing, etc. It will be done in high level for CS577a and should be completed in CS577b. Regarding the standard, the team is using the following standards in the project development - Incremental Commitment Model for SW: This provides information about software development process with templates and examples. - UML 2.0 Standard: for modeling software and system architecture Due to the significant schedule constraints, no explicit process assurance related activities are done by the teams. The instructional staff does provide some process assurance in terms of scheduling deliverables, tasks and assignments but there are some implicit activities that help in process assurance: - Instructional staff monitoring: includes feedback from course instructors, TAs and mentor. - Architecture Review Board: The Instructional staff and the client review all the major points in the project. - Schedule: using Schedule as Independent Variable (SAIV) and COCOMO II, the development team will be able to determine the project size that is feasible in the limited time frame. QMP_DCP_F08a_T14_V1.5 11 Version Date: 11/17/2008
  12. 12. Quality Management Plan (QMP) Version 1.5 - Weekly progress report: risk report ensures that the development team aware of the progress and risk of the project. - Home works & assignments: allow all students to practice the techniques that will be used in the development project. - Weekly Team Meeting/Call: keeps the team members updated and determine the progress of the project and any major changes are required. - IIV&V team: acts as an independent (directly with the client) but integrated (for the team) reviewers of the team work and artifacts. A.2.5IIV&V Coordination To ensure the quality, the team uses UCS email system, team website and phone bridge to organize the communication and the coordination between the on-campus team and the IIV&V team which includes 2 DEN students. The on-campus team uploads the artifacts documents on the team website, the IIV&V team downloads the documents and reviews them and if something is unclear or repeated concern (from previous versions of the artifacts) the IIV&V team uses the email or phone to contact the author and asks for clarification. If something needs more clarification or need the other members of the team to be involved like an open issue, all the team members have a phone conference to discuss and close this issue. A.3.Configuration Management During the project various versions of documents and software product are created. In order to avoid costly re-work, hidden defects, and deliver a software system consistent with the stage of development and traceable to the needs of the customer, configuration management is needed. 3.1 Product Element Identification In the Incremental Commitment Model (ICM), we have 5 phases as follows: - Exploration Phase. - Valuation Phase. - Foundations Phase. - Development Phase which includes Construction and transition iterations. - Operation Phase. Major project deliverables are as follows QMP_DCP_F08a_T14_V1.5 12 Version Date: 11/17/2008
  13. 13. Quality Management Plan (QMP) Version 1.5 Table 6: Project artifacts and its responsible person Artifact Abbreviation Owner Shobana Govindan Operational Concept Description OCD Priyanka Nambiar Naveen Joy Wiki Win-Win Report WWW Nikita Valechha Bharat Mehndiratta Prototype PRO Kartik Sethi System and Software Requirements SSRD Nikita Valechha Description System and Software Architecture SSAD Shobana Govindan Description UML Model UML Shobana Govindan Life Cycle Plan LCP Kartick Sethi Feasibility Evidence Description FED Swetha Suryanarayanan Supporting Information Document SID Bharat Mehndiratta Quality Management Plan QMP Mark Shehata Kartick Sethi Iteration Plan IP Nikita Valechha Naveen Joy Acceptance Test Plan and Cases ATPC Mark Shehata Kartick Sethi Transition Plan TP Nikita Valechha Progress Report PR Swetha Suryanarayanan Project Plan PP Swetha Suryanarayanan Naveen Joy Agile Artifact Reviews AAR Mark Shehata Naveen Joy Agile Internal/Informal Reviews AIR Mark Shehata Client Meeting Notes CMN Swetha Suryanarayanan The following table shows the priority of the artifact in each phase. A priority of 5 represents a greater emphasis, a 1 represents a lower emphasis, and a value of 0 is N/A in that phase. QMP_DCP_F08a_T14_V1.5 13 Version Date: 11/17/2008
  14. 14. Quality Management Plan (QMP) Version 1.5 Table 7: Priority of each artifact in each phase Foundations Development Exploration Valuation Operation Artifact Operational Concept Description 5 5 4 1 0 Wiki Win-Win Report 0 5 4 1 0 Prototype Results 1 5 5 2 0 System and Software Requirements Description 0 5 4 3 0 System and Software Architecture Description 0 4 5 5 1 UML Model 0 4 5 5 1 Life Cycle Planning 3 5 5 4 0 Feasibility Evidence Description 3 5 5 3 0 Supporting Information Document 0 5 5 5 0 Quality Management Plan 0 2 5 4 0 Iteration Plan 0 2 4 5 0 Acceptance Test Plan and Cases 0 0 4 5 0 Transition Plan 0 0 4 5 4 Progress Report 5 5 5 5 0 Project Plan 5 5 5 5 0 Agile Artifact Reviews 5 5 5 5 0 Agile Internal/Informal Reviews 0 0 5 5 0 Client Meeting Notes 5 5 3 1 0 The team is using the following file naming convention for all project artifacts. QMP_DCP_F08a_T14_V1.5 14 Version Date: 11/17/2008
  15. 15. Quality Management Plan (QMP) Version 1.5 Table 8: File naming convention guidelines Artifact Semester Team Version Document Milestone Abbreviation and Year Number Number Extension OCD VCR F08a T14 1.0 Doc OCD_ VCR_F08a_T14_v1.0.doc Milestones in CSCI577ab include • Valuation Commitment Package (VCP) • Foundations Commitment Package (FCP) • Development Commitment Package (DCP) • Re-base lined Development Commitment Package (RDCP) • Operation Commitment Package to (OCP) The elements for this project include all the phases that artifacts must go through in order to be considered complete. The number system should be base lined in the following way. • Core Foundations Commitment Package 1.0 • Draft Foundations Commitment Package 2.0 • Foundations Commitment Package 3.0 • Draft Development Commitment Package 4.0 • Development Commitment Package 5.0 • Rebaselined Development Commitment Package 6.0 • Operations Commitment Package 7.0 • Final Deliverables 8.0 QMP_DCP_F08a_T14_V1.5 15 Version Date: 11/17/2008
  16. 16. Quality Management Plan (QMP) Version 1.5 3.2 Configuration Item and Rationale Table 9: Artifacts and its volatility and impact severity Configurat Description Rationale Volatility Impact Severity ion Item OCD Operational Major artifact Volatile during Very severe - if the Concept for overall Exploration and overall system's Description system's shared Valuation, but vision changes then vision among should become the requirements, stakeholders. stable during design, code, etc. Foundations, could all be incorrect. development and operation. WinWin The WinWin This report is Volatile during Very severe - Report Report that is what all the the Exploration Severely impacts the created during the system's and Valuation rest of the system as WinWin requirements are phases. Should it has the win Negotiations and derived from. be less volatile conditions of the updated regularly This report during stakeholders So if it if anything involves input Foundations. changes, OCD, changes. from all Should be stable SSRD… should be stakeholders of during updated. the system. development and operation. SSRD System and Major artifact Volatile during Very severe. This Software which contains Valuation. document tells the Requirements the requirements Should be less developers and Definition for the system. volatile during architects what to Foundations. design and build. If Should become this document more stable changes it has impact during to the SSAD, code, Development. tests, etc. SSAD System and Important Initial version is Severely impacts the Software artifact which created during actual Architecture describes the the Valuation implementation Description architecture and stage; however (code) and test plans design of the less volatile and tests for the system. during implementation. Foundations. Should become stable in Development. QMP_DCP_F08a_T14_V1.5 16 Version Date: 11/17/2008
  17. 17. Quality Management Plan (QMP) Version 1.5 Configurat Description Rationale Volatility Impact Severity ion Item SID Supporting This document Low volatility Low impact to other Information is the common throughout the documents. This Document source of phases. artifact is impacted support by other artifacts information for changing. all the artifacts. LCP Life Cycle Plan The LCP serves The most volatile Could have a severe as the basis of in the Valuation impact to the monitoring and and Foundation. schedule. control and However, due to answers the personnel most common changes could be questions about volatile in the a project: Development WWWWWHH phase as well. M FED Feasibility The FED shows This document Low impact to other Evidence evidence that the will be volatile documents. This Description project and all during the artifact is impacted its details are Exploration and by other artifacts feasible. less volatile changing. during Valuation then will be more stable but continue to be volatile when any major change occurs to the artifacts. UML UML models and The UML Volatile during Severely impacts the Models diagrams models and the Valuation and SSAD and possibly diagrams show Foundations. impacts the FED. actually how the Should become system is stable in architected and Development. designed. QMP_DCP_F08a_T14_V1.5 17 Version Date: 11/17/2008
  18. 18. Quality Management Plan (QMP) Version 1.5 Configurat Description Rationale Volatility Impact Severity ion Item QMP Quality The QMP This document Low impact to other Management Plan explains what will be volatile documents but major quality process until the first impact to process. and iteration of configuration Development management phase. process will be used. IP Iteration Plan The IP will be This document This document used to show will be volatile impacts what what until the development development Rebaselined activities will be done activities will be Development when. Based on done for each Commitment client meetings and iteration. Package is task prioritization this complete. When document will get the construction impacted which will phase starts this then in turn impact document will development become stable. activities. ATPC Acceptance Test The Test Plan This document This file is impacted Plan and Cases and Cases will be volatile by the SSRD, SSAD, document throughout the OCD, etc. This describes all the development document impacts testing that will phase. what testing will be done, who occur. will do the testing, what test cases will be done, what test data will be used, the environment for testing, etc. QMP_DCP_F08a_T14_V1.5 18 Version Date: 11/17/2008
  19. 19. Quality Management Plan (QMP) Version 1.5 Configurat Description Rationale Volatility Impact Severity ion Item TP Transition Plan The Transition This document Impacts how the Plan document will be volatile transition is carried describes how during the out. This could affect the transition to Development code, executables, an operational phase and should artifacts, manuals, system will become etc. occur. baselined at the transition stage of development phase. AAR Agile Artifact IIV&V team fill Always Volatile Impact the concerned Reviews this documents because each artifact (the artifact with any defects time the that has been found in the document reviewed). project artifacts. reviewed some defects may be added or removed. AIR Agile The team Always Volatile Impact the concerned Internal/Informal members or part because each artifact (the artifact Reviews of the team fill time the that has been this form when document reviewed). they are doing reviewed some Peer Review defects may be added or removed. CMN Client Meeting The notes that Always Volatile Severely impacts all Notes were taken other documents during the because it reflects client’s meetings what the client wants or calls. to have in his/her product. By Negotiations with the client the specifications of the project are fixed and this document becomes only notes or suggestions from the client. QMP_DCP_F08a_T14_V1.5 19 Version Date: 11/17/2008
  20. 20. Quality Management Plan (QMP) Version 1.5 Configurat Description Rationale Volatility Impact Severity ion Item This document Prototyping Volatile at Severely impacts the has the screen helps in Valuation and SSRD and FED. shots of the identifying less volatile at Prototype prototypes and defects and risks Foundations and Results the results from and letting the should be stable prototyping. user have the at development. feel of the new system Project These are the These track what Volatile on a No impact to any Plans project plans that we have done weekly basis in other part of the are produced and where we all phases until system. weekly by the are going. From operation. project manager. these could possibly identify areas of weaknesses on the project. PR Project Progress - These track what Volatile on a No impact to any These are the we have done weekly basis in other part of the progress reports and where we all phases until system. that are produced are going. From operation. weekly by the these could project manager. possibly identify areas of weaknesses on the project. 3.3 Configuration Change Management Because the size f the project and the team are small, it will be convenient to do configuration change management in informal way. Changes come from various sources such as client requests, Peer reviews, reviews done by IIV&Ver, TA grading, and mainly from ARB sessions. After the development team receives the suggested changes, the team has to asses the commented elements, reprioritize or modify the elements. If the suggested changes yield a significant change, the team will record the change in the appropriate artifact. QMP_DCP_F08a_T14_V1.5 20 Version Date: 11/17/2008
  21. 21. Quality Management Plan (QMP) Version 1.5 Figure 1: Flow of configuration change management Receive suggested changes Asses the changes Reject the change NO Significant Change? YES Determine the effects of the change Apply the change 3.4 Project Library Management The project team site will serve as the Project Library. It will be used to store and allow access to baselined documents such as the VCR package, the DCR package, and final deliverables. The structure of the team website has been designed based on the guidelines from the class. The link to the Project Library is as follows: http://greenbay.usc.edu/csci577/fall2008/projects/team14/index.html Kartick Sethi is the site maintainer and a member of the development team. He is responsible for uploading the documents and marinating the site. The team members send Kartick the documents and he uploads the documents and sends email to inform the member that his/her documents have been uploaded, the member should test the links and inform Kartick if anything goes wrong. QMP_DCP_F08a_T14_V1.5 21 Version Date: 11/17/2008
  22. 22. Quality Management Plan (QMP) Version 1.5 Finally at the end of the semester, the project artifacts will be archived as follows. 3.5 Resources and Personnel The Quality Focal Point, Mark Shehata, will be currently responsible to ensure that all configuration management (CM) functions are performed. However, the Quality Focal Point, with prior approval from the project manager, Swetha Suryanarayanan, has the option to assign responsibilities of configuration management to other members of the project team. The project librarian is one in the same with the team site maintainer, who is Kartick Sethi. He will be responsible to manage the archiving of project elements within the project library. 3.6 Tools A configuration management tool is needed to efficiently and effectively monitor and track versions and updates for project elements. The CM tool is Subversion version 1.5. Since Subversion is open-source software, it will not require any budget or additional license costs. Subversion will allow developers to track change history, develop off branches or local versions of software, avoid re-work while taking advantage of re-use, and encourage team development among other benefits. QMP_DCP_F08a_T14_V1.5 22 Version Date: 11/17/2008

×