quality management plan (qmp)
TRANSCRIPT
Quality Management Plan (QMP)
The Virtual Assistant Living and Education Program
Team # 14
Team Members:
Name RoleSwetha Suryanarayanan Project ManagerNikita Valechha Requirements EngineerKartik Sethi Plan and Control
Engineer
QMP_DCP_F08a_T14_V1.5 Version Date: 11/17/2008
Quality Management Plan (QMP) Version 1.5
Shobana Govindan System ArchitectBharat Mehndiratta PrototyperPriyanka Nambiar Operation Concept
EngineerNaveen Joy Shaper & IIV&VMark Shehata QFP & IIV&VPamela Clay Client
Date: 11/17/2008
QMP_DCP_F08a_T14_V1.5 Version Date: 11/17/2008ii
Quality Management Plan (QMP) Version 1.5
Version HistoryDate Author Version Changes made Rationale
10/26/08 Mark Shehata 1.0 Original template including Section
1 , 2 Part 1 of QMP at the end of
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 Version Date: 11/17/2008iii
Quality Management Plan (QMP) Version 1.5
Table of ContentsQuality Management Plan (QMP)...............................................................................................................................iVersion History.............................................................................................................................................................iiTable of Contents.........................................................................................................................................................iiiTable of Tables.............................................................................................................................................................ivTable of Figures.............................................................................................................................................................v
1. Purpose.......................................................................................................................................................................6
1.1 Purpose of the QMP..................................................................................................................................6
1.2 Status of the QMP.....................................................................................................................................6
1.3 References..................................................................................................................................................6
2. Quality Management Strategy.........................................................................................................................7
2.1 Defect Prevention Strategies....................................................................................................................7
2.2 Defect Removal Tracking.........................................................................................................................9
2.3 Level of Service Achievement Monitoring..............................................................................................9
2.4 Process Assurance...................................................................................................................................10
2.5 IIV&V Coordination..............................................................................................................................11
3. Configuration Management...........................................................................................................................11
3.1 Product Element Identification....................................................................................................................11
3.2 Configuration Item and Rationale........................................................................................................15
3.3 Configuration Change Management.....................................................................................................19
3.4 Project Library Management................................................................................................................20
3.5 Resources and Personnel........................................................................................................................21
3.6 Tools.........................................................................................................................................................21
QMP_DCP_F08a_T14_V1.5 iv Version Date: 11/17/2008
Quality Management Plan (QMP) Version 1.5
Table of TablesTable 1: List of defect prevention strategies...................................................................................................................7
Table 2: Automated analysis strategy for defect detection.............................................................................................8
Table 3: People review strategies for defect detection...................................................................................................8
Table 4: Execution testing strategies for defect detection..............................................................................................8
Table 5: Level of Service achievement strategy and its responsible person...................................................................9
Table 6: Project artifacts and its responsible person...................................................................................................12
Table 7: Priority of each artifact in each phase...........................................................................................................13
Table 8: File naming convention guidelines.................................................................................................................14
Table 9: Artifacts and its volatility and impact severity...............................................................................................15
QMP_DCP_F08a_T14_V1.5 v Version Date: 11/17/2008
Quality Management Plan (QMP) Version 1.5
Table of FiguresFigure 1: Flow of configuration change management..................................................................................................20
QMP_DCP_F08a_T14_V1.5 vi Version Date: 11/17/2008
Quality Management Plan (QMP) Version 1.5
1. Purpose
1.1 Purpose 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.
1.2 Status 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.
1.3 References
- 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
Quality Management Plan (QMP) Version 1.5
2. Quality Management Strategy
2.1 Defect Prevention Strategies
Table 1: List of defect prevention strategies
Strategy Priority Description
People Practices (Win-Win)
High The win-win Model is used to ensure that all stakeholders' win conditions are met with the final implementation. The wiki win win tool is used in this strategy.
People Practices (Dry run)
High We did/will do dry run before each presentation in order to double check it.
People Practices (Mentor )
Low Team’s mentor provides some suggestions/comments and he could help in preventing some defect.
People Practices (Lectures & Lectures Notes)
Medium The information and experience we got from the professors and TAs through the lectures and lectures notes help in preventing some defects that could happen due to lack of experience.
People Practices (Feasibility Study/Analysis)
High The Feasibility Analyst did a good analysis to ensure that the system is feasible to be developed and implemented.
People Practices (Drafting)
High Using drafting for the critical artifacts and having been reviewed by the team members and TAs is a very helpful strategy to prevent defects in final versions.
Weekly team meeting/call
Low The discussion that the team had in every meeting / call help in preventing some minor and common defects.
Standard (Incremental Commitment
High By using the Incremental Commitment Model templates and guidelines, the artifacts produced should have the correct format and substance. This helps in avoiding common and
QMP_DCP_F08a_T14_V1.5 Version Date: 11/17/20088
Quality Management Plan (QMP) Version 1.5
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.
Defect Detection Strategies
2.1.1 Automated Analysis
Table 2: Automated analysis strategy for defect detection
Strategy Priority Description
Traceability checking
High Visual Studio.Net will help the developers in tracing errors and defects.
Pre-condition, Post-condition, Views Interface, behavior
High During the development of the system, the developers will check the behavior by doing some automated module tests.
2.1.2 People Review
Table 3: People review strategies for defect detection
Strategy Priority Description
Independent review
High The IIV&V team reviews the artifact using agile artifact review document and identify any defects in the concern log.
Architecture Review Board (ARB)
High The Instructional staff and the client review all the major points in the project and detect any defect.
QMP_DCP_F08a_T14_V1.5 Version Date: 11/17/20089
Quality Management Plan (QMP) Version 1.5
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 HighEvery 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.
2.2 Defect 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.
2.3 Level 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.
QMP_DCP_F08a_T14_V1.5 Version Date: 11/17/200810
Quality Management Plan (QMP) Version 1.5
Table 5: Level of Service achievement strategy and its responsible person
Role Responsible person Responsibility
Quality Focal Point
Mark Shehata Monitor progress/quality towards achieving such requirements and write test cases and acceptance test directly with the client.
IIV&V Mark Shehata , Naveen Joy
Feedback the team with any suggestions or comments regarding the design or the code.
Developers Bharat Mehndiratta , Kartik Sethi
Research on how the product can achieve these 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 Architect
Shobana Govindan Research on how the product can achieve these requirements and design the architecture that support level of service requirements.
2.4 Process 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:
QMP_DCP_F08a_T14_V1.5 Version Date: 11/17/200811
Quality Management Plan (QMP) Version 1.5
- 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.
- 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.
QMP_DCP_F08a_T14_V1.5 Version Date: 11/17/200812
Quality Management Plan (QMP) Version 1.5
2.5 IIV&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.
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
Table 6: Project artifacts and its responsible person
Artifact Abbreviation Owner
Operational Concept Description OCDShobana GovindanPriyanka Nambiar
Wiki Win-Win Report WWW Naveen Joy
QMP_DCP_F08a_T14_V1.5 Version Date: 11/17/200813
Quality Management Plan (QMP) Version 1.5
Nikita Valechha
Prototype PROBharat Mehndiratta
Kartik Sethi
System and Software Requirements Description
SSRD Nikita Valechha
System and Software Architecture Description
SSAD Shobana Govindan
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
Iteration Plan IPKartick Sethi
Nikita Valechha
Acceptance Test Plan and Cases ATPCNaveen Joy
Mark Shehata
Transition Plan TPKartick Sethi
Nikita Valechha
Progress Report PR Swetha Suryanarayanan
Project Plan PP Swetha Suryanarayanan
Agile Artifact Reviews AARNaveen Joy
Mark Shehata
Agile Internal/Informal Reviews AIRNaveen Joy
Mark Shehata
Client Meeting Notes CMN Swetha Suryanarayanan
QMP_DCP_F08a_T14_V1.5 Version Date: 11/17/200814
Quality Management Plan (QMP) Version 1.5
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.
Table 7: Priority of each artifact in each phase
Artifact
Exp
lora
tion
Val
uat
ion
Fou
nd
atio
ns
Dev
elop
men
t
Op
erat
ion
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
QMP_DCP_F08a_T14_V1.5 Version Date: 11/17/200815
Quality Management Plan (QMP) Version 1.5
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.
Table 8: File naming convention guidelines
Artifact Abbreviation
MilestoneSemester and Year
Team Number
Version Number
Document Extension
OCD VCR F08a T14 1.0 Doc
OCD_ VCR_F08a_T14_v1.0.doc
QMP_DCP_F08a_T14_V1.5 Version Date: 11/17/200816
Quality Management Plan (QMP) Version 1.5
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 Version Date: 11/17/200817
Quality Management Plan (QMP) Version 1.5
3.2 Configuration Item and Rationale
Table 9: Artifacts and its volatility and impact severity
Configuration Item
Description Rationale Volatility Impact Severity
OCD Operational Concept Description
Major artifact for overall system's shared vision among stakeholders.
Volatile during Exploration and Valuation, but should become stable during Foundations, development and operation.
Very severe - if the overall system's vision changes then the requirements, design, code, etc. could all be incorrect.
WinWin Report
The WinWin Report that is created during the WinWin Negotiations and updated regularly if anything changes.
This report is what all the system's requirements are derived from. This report involves input from all stakeholders of the system.
Volatile during the Exploration and Valuation phases. Should be less volatile during Foundations. Should be stable during development and operation.
Very severe - Severely impacts the rest of the system as it has the win conditions of the stakeholders So if it changes, OCD, SSRD… should be updated.
SSRD System and Software Requirements Definition
Major artifact which contains the requirements for the system.
Volatile during Valuation. Should be less volatile during Foundations. Should become more stable during Development.
Very severe. This document tells the developers and architects what to design and build. If this document changes it has impact to the SSAD, code, tests, etc.
QMP_DCP_F08a_T14_V1.5 Version Date: 11/17/200818
Quality Management Plan (QMP) Version 1.5
Configuration Item
Description Rationale Volatility Impact Severity
SSAD System and Software Architecture Description
Important artifact which describes the architecture and design of the system.
Initial version is created during the Valuation stage; however less volatile during Foundations. Should become stable in Development.
Severely impacts the actual implementation (code) and test plans and tests for the implementation.
SID Supporting Information Document
This document is the common source of support information for all the artifacts.
Low volatility throughout the phases.
Low impact to other documents. This artifact is impacted by other artifacts changing.
LCP Life Cycle Plan The LCP serves as the basis of monitoring and control and answers the most common questions about a project: WWWWWHHM
The most volatile in the Valuation and Foundation. However, due to personnel changes could be volatile in the Development phase as well.
Could have a severe impact to the schedule.
QMP_DCP_F08a_T14_V1.5 Version Date: 11/17/200819
Quality Management Plan (QMP) Version 1.5
Configuration Item
Description Rationale Volatility Impact Severity
FED Feasibility Evidence Description
The FED shows evidence that the project and all its details are feasible.
This document will be volatile during the Exploration and less volatile during Valuation then will be more stable but continue to be volatile when any major change occurs to the artifacts.
Low impact to other documents. This artifact is impacted by other artifacts changing.
UML Models
UML models and diagrams
The UML models and diagrams show actually how the system is architected and designed.
Volatile during the Valuation and Foundations. Should become stable in Development.
Severely impacts the SSAD and possibly impacts the FED.
QMP Quality Management Plan
The QMP explains what quality process and configuration management process will be used.
This document will be volatile until the first iteration of Development phase.
Low impact to other documents but major impact to process.
QMP_DCP_F08a_T14_V1.5 Version Date: 11/17/200820
Quality Management Plan (QMP) Version 1.5
Configuration Item
Description Rationale Volatility Impact Severity
IP Iteration Plan The IP will be used to show what development activities will be done for each iteration.
This document will be volatile until the Rebaselined Development Commitment Package is complete. When the construction phase starts this document will become stable.
This document impacts what development activities will be done when. Based on client meetings and task prioritization this document will get impacted which will then in turn impact development activities.
ATPC Acceptance Test Plan and Cases
The Test Plan and Cases document 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.
This document will be volatile throughout the development phase.
This file is impacted by the SSRD, SSAD, OCD, etc. This document impacts what testing will occur.
TP Transition Plan The Transition Plan document describes how the transition to an operational system will occur.
This document will be volatile during the Development phase and should become baselined at the transition stage of development phase.
Impacts how the transition is carried out. This could affect code, executables, artifacts, manuals, etc.
QMP_DCP_F08a_T14_V1.5 Version Date: 11/17/200821
Quality Management Plan (QMP) Version 1.5
Configuration Item
Description Rationale Volatility Impact Severity
AAR Agile Artifact Reviews
IIV&V team fill this documents with any defects found in the project artifacts.
Always Volatile because each time the document reviewed some defects may be added or removed.
Impact the concerned artifact (the artifact that has been reviewed).
AIR Agile Internal/Informal Reviews
The team members or part of the team fill this form when they are doing Peer Review
Always Volatile because each time the document reviewed some defects may be added or removed.
Impact the concerned artifact (the artifact that has been reviewed).
CMN Client Meeting Notes
The notes that were taken during the client’s meetings or calls.
Always Volatile Severely impacts all other documents because it reflects what the client wants 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 Version Date: 11/17/200822
Quality Management Plan (QMP) Version 1.5
Configuration Item
Description Rationale Volatility Impact Severity
Prototype Results
This document has the screen shots of the prototypes and the results from prototyping.
Prototyping helps in identifying defects and risks and letting the user have the feel of the new system
Volatile at Valuation and less volatile at Foundations and should be stable at development.
Severely impacts the SSRD and FED.
Project Plans
These are the project plans that are produced weekly by the project manager.
These track what we have done and where we are going. From these could possibly identify areas of weaknesses on the project.
Volatile on a weekly basis in all phases until operation.
No impact to any other part of the system.
PR Project Progress - These are the progress reports that are produced weekly by the project manager.
These track what we have done and where we are going. From these could possibly identify areas of weaknesses on the project.
Volatile on a weekly basis in all phases until operation.
No impact to any other part of the system.
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.
QMP_DCP_F08a_T14_V1.5 Version Date: 11/17/200823
Quality Management Plan (QMP) Version 1.5
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.
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
QMP_DCP_F08a_T14_V1.5 Version Date: 11/17/2008
Figure 1: Flow of configuration change management
Receive suggested changes
Asses the changes
Significant Change?
Reject the change NO
YES
Determine the effects of the
change
Apply the change
24
Quality Management Plan (QMP) Version 1.5
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.
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 Version Date: 11/17/200825