Quality Management Plan (QMP)

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


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


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


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


Table of FiguresFigure 1: Flow of configuration change management..................................................................................................20

QMP_DCP_F08a_T14_V1.5 vi Version Date: 11/17/2008


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

http://greenbay.usc.edu/csci577/fall2008/projects/team14/index.html

http://greenbay.usc.edu/csci577/fall2008/projects/team14/Valuation/FED_FCP_F08a_T14_V2.5.pdf

http://greenbay.usc.edu/csci577/fall2008/site/guidelines/ProjectWebSiteGuidelineFall08v3.pdf

http://greenbay.usc.edu/IICMSw/index.htm


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



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


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


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.



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


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.



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:



- 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.



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



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



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



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



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



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.



Configuration Item


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.



Configuration Item


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.



Configuration Item


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.



Configuration Item


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.



Configuration Item


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.



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


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


structure of the team website has been designed based on the guidelines from the class. The link to the Project Library is as follows:


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.



http://greenbay.usc.edu/csci577/fall2008/site/guidelines/ProjectWebSiteGuidelineFall08v3.pdf

Documents

Quality Management Plan (QMP)