Management Quality Plan (QMP)
Theater Script Online Database
Team No 16
Quality Management Plan (QMP)
Version 5.0
Jae Young Bang Gary Lam Young Chan Noh Ka Ho Au Shi Heng Guan Sandeep Mikkilineni Nory Kealii Nishimura John Christopher Reynolds Julie Sanchez
Project Manager Requirements Engineer System Architect Prototyper Planning and Control Engineer Operational Concept Engineer IIV&V / QFP IIV&V/ SRE Client
November 24, 2008
2c2d6620c530eea35471b790b76f5ba9934c3a16.doc
ii
Version Date: 11/24/08
Quality Management Plan (QMP)
Version 5.0
Version History
Date 10/26/0 8 11/17/0 8 11/24/0 8 Author Nory Nishimura Nory Nishimura Nory Nishimura Versio n 1.0 2.0 5.0 Changes made Section 1 and 2 Added Section 3 Tables 3,4,6,7 & 9. Added plans for Peer Review. Added more testing strategies and required levels of documentation. Added configuration management plans for IP,TP and ATPC. Rationale Initial draft of QMP QMP #2, CM Prepare for DCR
2c2d6620c530eea35471b790b76f5ba9934c3a16.doc
iii
Version Date: 11/24/08
Quality Management Plan (QMP)
Version 5.0
Table of Contents
Quality Management Plan (QMP)...............................................................................................................................i Version History............................................................................................................................................................iii Table of Contents.........................................................................................................................................................iv Table of Tables..............................................................................................................................................................v Table of Figures............................................................................................................................................................vi A.1. Purpose ..................................................................................................................................................................1 A.1.1 Purpose of the QMP....................................................................................................................................1 A.1.2 Status of the QMP........................................................................................................................................1 A.2. Quality Management Strategy.............................................................................................................................2 A.2.1 Defect Prevention Strategies.......................................................................................................................2 A.2.2 Defect Detection Strategies.........................................................................................................................3 A.2.3 Defect Removal Tracking............................................................................................................................5 A.2.4 Level of Service Achievement Monitoring.................................................................................................5 A.2.5 Process Assurance........................................................................................................................................6 A.2.6 IIV&V Coordination...................................................................................................................................6 A.3. Configuration Management.................................................................................................................................7 A.3.1 Product Element Identification..................................................................................................................7 A.3.2 Configuration Item and Rationale.............................................................................................................9 A.3.3 Configuration Change Management........................................................................................................12 A.3.4 Project Library Management...................................................................................................................13 A.3.5 Resources and Personnel...........................................................................................................................13 A.3.6 Tools............................................................................................................................................................14
2c2d6620c530eea35471b790b76f5ba9934c3a16.doc
iv
Version Date: 11/24/08
Quality Management Plan (QMP)
Version 5.0
Table of Tables
Table 1: List of defect prevention strategies...............................................................................................................2 Table 2: Automated analysis strategy for defect detection.......................................................................................3 Table 3: People review strategies for defect detection...............................................................................................3 Table 4: Execution testing strategies for defect detection.........................................................................................4 Table 5: Level of Service achievement strategy and its responsible person............................................................5 Table 6: Project artifacts and its responsible person.................................................................................................7 Table 7: Priority of each artifact in each phase.........................................................................................................8 Table 8: File naming convention guidelines...............................................................................................................8 Table 9: Artifacts and its volatility and impact severity...........................................................................................9
2c2d6620c530eea35471b790b76f5ba9934c3a16.doc
v
Version Date: 11/24/08
Quality Management Plan (QMP)
Version 5.0
Table of Figures
Figure 1: Flow of configuration change management.............................................................................................13
2c2d6620c530eea35471b790b76f5ba9934c3a16.doc
vi
Version Date: 11/24/08
Quality Management Plan (QMP)
Version 5.0
A.1.
Purpose
A.1.1 Purpose of the QMP
The purpose of the QMP is to identity and define a strategy for ensuring high quality for the Theater Script Online Database. By having a shared goal of high quality, strategies for preventing, detecting and removal of defects as early in the process are essential. This document describes our team's processes and strategies for ensuring high quality in our artifacts and deliverables. The Quality Focal has the responsibility of ensuring that the processes are acceptable and being utilized to achieve this. The stakeholders of this project are the development team, the client, the maintainers, the users (Actors & Theater Staff) and the teaching staff.
A.1.2 Status of the QMP
The current version of the Quality Management Plan (QMP) contains: Quality Management Strategy (Section 2) Configuration Management Plan (Section 3)
2c2d6620c530eea35471b790b76f5ba9934c3a16.doc
1
Version Date: 11/24/08
Quality Management Plan (QMP)
Version 5.0
A.2.
Quality Management Strategy
The following section describes the quality management strategies for the Theater Script Database project.
A.2.1 Defect Prevention Strategies
This section describes the defect prevention strategies that will be used throughout the Theater Script Database project. They will be used to prevent and reduce the number of defects. Table 1: List of defect prevention strategies Strategy Priority Description The JWikiWinWIn tool will be utilized to manage the win-win negotiations. The purpose of this strategy will be to ensure that all stakeholders have a say and that their win conditions are met. Quality agreements are an important foundation to base the project's requirements and expectations on. The IICM-SW will provide a process where guidance and templates are provided for the artifacts needed in this project. With a standard set of templates, descriptions, and examples, procedural defects will be minimized. Prototyping will help explore solutions and ideas early in the development process. Being a web-based application, the "I'll know it when I see it" (IKIWISI) requirements are a high source of defects. With early prototyping, client's expectations can be assessed early on and design decision can be made to minimize interface defects. Before artifacts are released into revision, quick reviews or inspections will be performed by the development team. The purpose of having another team member review the artifacts before it is officially released is that mistakes can be found before they officially become defects. Regular tag-up meeting will provide all stakeholders an opportunity to bring up issues or ask questions. The purpose is to keep all stakeholders on the same page and have an open forum for discussions. Defects will be reduced by having an opportunity for issues to be discussed before they become defects. Before each ARB, a dry run of the presentation will be performed. The purpose is to reduce presentation defects and improve presentation delivery. Feasibility studies will be conducted to ensure solutions proposed are able to be accomplished. The purpose is to reduce design defects as early as possible. Version Date: 11/24/08
WikiWinWin
High
IICM-SW Process
High
Prototyping
High
Pre-release Reviews
High
Regular Meetings
High
Dry Run
High
Feasibility Studies
High
2c2d6620c530eea35471b790b76f5ba9934c3a16.doc
2
Quality Management Plan (QMP) Risk Assessment (DART) High
Version 5.0 The risk assessment tool will help reduce defects because visibility of problems areas will be addressed before they become project defects. The team will use Java and SQL (MySQL) which they are most familiar with. This will help reduce defects due to inexperience and learn curve issues. The team will utilize the expertise of a mentor (Thomas Tan) throughout the project. The purpose is to take advantage of this person's experience to help us avoid pitfalls and defects.
Languages
Medium
Mentor Program
Low
A.2.2 Defect Detection Strategies
We have three categories of defect detection strategies: Automated Analysis, People Reviews, and Execution Testing.
.2.2.1 Automated Analysis
The following table list the automated ways defects will be detected. Table 2: Automated analysis strategy for defect detection Strategy Document Spelling and Grammar Checking Syntax Checking Priority High High Description Text based document will utilize the automatic word processing tools to check grammar and spelling. This will detect basic grammatical and spelling defects. Java software syntax will be verified by the Java interpreter. This will prevent syntax defects from being released.
.2.2.2 People Review
The following table lists the people-oriented strategies for defect detection. Table 3: People review strategies for defect detection Strategy Agile Artifact Review Priority High Description The IIV&V will perform Agile Artifact Review of the artifacts. This will provide an early opportunity for defects to be identified by an independent party. The earlier a defect is detected, the least costly it will be to fix.
2c2d6620c530eea35471b790b76f5ba9934c3a16.doc
3
Version Date: 11/24/08
Quality Management Plan (QMP)
Version 5.0 With time allowing, informal peer reviews will be conducted on high risk artifacts. Risk will be determined by the artifact owner, project manager or the QFP. No formal peer reviews are planned. Due to time constraints, no formal review documents will be supplied and review results will be communicated mainly through emails and verbal communications. The feedback received from instructional staff during the ARB's will also be a source of defect detection. Although, not formally documented as defects, issues brought up by the instructional staff will be assessed by the QFP and tracked in the Defect Tracking Matrix. The team will perform code reviews on development team software. This will help identify and fix coding defects as early as possible. The QFP will review artifacts to ensure quality processes are being utilized. The QFP will document defects relating to quality procedures found in this document. The feedback/grades received from TA's will also be a source of defect detection. Although, not formally documented as defects in the feedback, the issues and concerns from the TA's will be assessed by the QFP and tracked in the Defect Tracking Matrix.
Agile Informal Review
Medium
Architecture Review Board
High
Code Review
High
Quality Focal Review
High
TA Review Grading
High
.2.2.3 Execution Testing
The following table lists the defect detection strategies used in execution testing. Table 4: Execution testing strategies for defect detection Level of Documentation Informal
Strategy Unit Testing
Priority High
Description Developers will tests their individual software modules against the requirements and according to the test plan for that module.. With each iteration of the cyclic development process, integration of all developed software modules will be tested. Tests will be designed according to the iteration plan and the test plan. Development will not occur on the final system. Tests are needed to verify the deliverable product is compatible and performs as intended on the deployment system. Working with the client, tests will be developed to verify deliverables are acceptable to the client. Defects will be detected that are not up to the client's expectations.
Integration Testing
High
Informal
System Tests
High
Informal
Acceptance Test Cases
High
Formal
2c2d6620c530eea35471b790b76f5ba9934c3a16.doc
4
Version Date: 11/24/08
Quality Management Plan (QMP)
Version 5.0 With an cyclic development process, regression tests will detect defects that new functionality may have injected into the system affecting previously working functionality.
Regression Testing
High
Semi-formal
A.2.3 Defect Removal Tracking
The QMP and IIV&V will be the primary personnel to track the defect removal effort. From the Agile Artifact Reviews, TA Artifact Feedback/Grading, and ARB Feedback, issues will be assess by the QMP and tracked if they are evaluated as defects. Defects will be tracked in a Defect Tracking Matrix. Such information as the defect description, phase of injection and phase of removal will be kept. This matrix will provide visibility to all team members so defects are not lost and fall through the cracks. The cycle time from defect injection through defect fix can be as long as three weeks with the current process. In addition, metrics and progress of all defect removal tasks should be included in the weekly progress reports.
A.2.4 Level of Service Achievement Monitoring
The Quality Focal Point (QFP) will have the primary responsibility for ensuring that progress is being made to satisfy the level of service (LOS) requirements. The team's level of service requirements are documented in the SSRD and the feasibility of each are addressed in the Feasibility Evidence Descriptions (FED). The FED contains the current rational and analysis for each LOS requirement. The following is the breakdown of the roles and responsibilities for satisfying these requirements. Table 5: Level of Service achievement strategy and its responsible person Responsible Person Nory Nishimura Young Chan Noh Nory Nishimura, John Reynolds TBD TBD
Role Quality Focal Point System Architect IIV&V Developer Tester
Responsibility The Quality Focal Point will be responsible for monitoring the development team to ensure the project is progressing to satisfy the LOS requirements. The QFP will also provide support and make recommendations for problem areas. The System Architect will be responsible for designing the system so that the LOS requirements are achievable. The IIV&V will evaluate the artifacts and deliverables at specific phases in the development cycle to ensure that the LOS requirements are being met. The development team will develop the software that satisfies the LOS requirements. testers The will develop tests that specifically test the software for LOS requirement satisfaction.
2c2d6620c530eea35471b790b76f5ba9934c3a16.doc
5
Version Date: 11/24/08
Quality Management Plan (QMP)
Version 5.0
A.2.5 Process Assurance
Process assurance focuses on the processes used during the entire development life cycle. This section describes the plans, standards and activities utilized in process assurance. Plans: Project Plan This is the plan that organizes each team member's tasks. It describes the tasks and responsibilities for each team member. Life Cycle Plan This plan organizes the progress of the project. Quality Management Plan This plan organizes the strategy for ensuring project quality.
Standards: IICM-SW Model This is the software development model being used in the Theater Script Online Database Project UML 2.0 This standard will be used for all UML diagrams in SSAD and other required UML diagrams Web Standards The Web interface shall validate with current standards for HTML and CSS.
Activities by instructional staff: Instructional Staff monitoring - This includes feedback from team assignments and general feedback on team progress. Architecture Review Boards This includes the comments and issues that arise during the ARB's. Project Scheduling The deadlines are scheduled by the instructional staff to ensure the process phases are spaced appropriately. Homework/Assignments The assignments reinforce lecture material and ensure process understanding. Weekly Progress Reports The weekly reports gives visibility to the instructional staff on the progress of the team as well as process adherence. IIV&V & AAR The remote students perform the role independent reviewers and assures process adherence by producing agile artifact reviews.
A.2.6 IIV&V Coordination
The Integrated Independent Verification and Validation (IIV&V) team members are primarily responsible for assuring that the project is progressing as planned and meeting the requirements. The IIV&V uses the Quality Management Plan (QMP) and works closely with the Quality Focal Point to ensure that defects are prevented, detected and fixed. The IIV&V members produce Agile Artifact Reports with issues to be addressed by the development team. Any issues identified as defects are then tracked to completion by the QFP. The QFP also has the responsibility ensuring a timely resolution of the defects. Communication to the IIV&V members are primarily though email, phone, and webex.
2c2d6620c530eea35471b790b76f5ba9934c3a16.doc
6
Version Date: 11/24/08
Quality Management Plan (QMP)
Version 5.0
A.3.
Configuration Management
The following section is the configuration management plan for Team 16.
A.3.1 Product Element Identification
The following table shows the artifacts and their owner(s) for the first semester of the CSCI 577AB series. This covers ICM Phases Exploration, Valuation, and Foundation. Table 6: Project artifacts and its responsible person Artifact Acceptance Test Plan & Cases Agile Artifact Review Client Interaction Report Feasibility Evidence Description Iteration Plan Life Cycle Plan Operational Concept Description Progress Report Project Plan Prototype Quality Management Plan Supporting Information Document System & Software Architecture Description System & Software Requirements Description Transition Plan UML Model Wiki Win Win Report Abbreviation ATPC AAR CIP FED IP LCP OCD PR PP PRO QMP SID SSAD SSRD TP UML WWW Owner John Reynolds Nory Nishimura /John Reynolds Varies Jae Young Bang TBD Shi Heng Guan Sandeep Mikkilineni Jae Young Bang Shi Heng Guan Ka Ho Au Nory Nishimura Varies Young Chan Noh Gary Lam Ka Ho Au Young Chan Noh John Reynolds
2c2d6620c530eea35471b790b76f5ba9934c3a16.doc
7
Version Date: 11/24/08
Quality Management Plan (QMP)
Version 5.0
The following table shows the priority of each of the artifacts in the various phases of the ICM. A priority of 5 indicated a high priority and 1 for a low priority. A 0 indicates that it is not applicable (N//A) in that phase. Table 7: Priority of each artifact in each phase
l op ve De
Fo
n tio ra pl o Ex
ti era Op
n ti o lua Va
un
Artifact
n tio da s
nt me
on
Acceptance Test Plan & Cases Agile Artifact Review Client Interaction Report Feasibility Evidence Description Iteration Plan Life Cycle Plan Operational Concept Description Progress Report Project Plan Prototype Quality Management Plan Supporting Information Document System & Software Architecture Description System & Software Requirements Description Transition Plan UML Model Wiki Win Win Report
0 0 5 5 0 3 5 5 5 3 0 0 0 0 0 0 3
0 5 4 5 0 5 5 5 5 5 1 5 3 5 0 3 5
5 5 3 5 3 4 5 5 5 5 5 5 5 5 3 5 4
5 5 3 4 5 3 3 5 5 3 2 5 5 5 5 5 1
0 0 0 0 0 0 0 0 0 0 0 0 1 0 3 1 0
Table 8: File naming convention guidelines Artifact Abbreviation QMP Milestone Semester Team Version & Year Number Number DCP F08a T16 V2.0 Example: QMP_DCP_F08a_T16_V2.0.doc File Extension doc
The milestones for 577A are the following (bolded mean major milestones) and version numbers: Valuation Commitment Package (VCP) Core Foundation Commitment Package Draft Foundation Commitment Package Foundations Commitment Package (FCP) Draft Development Commitment Package Development Commitment Package (DCP) (Varies but increments used) (Varies but increments used) (Varies but increments used) (Varies but increments used) 5.0 6.0
The milestones for 577B are the following (version numbers may change with minor milestone added):
2c2d6620c530eea35471b790b76f5ba9934c3a16.doc
8
Version Date: 11/24/08
Quality Management Plan (QMP) Rebaselined Development Commitment Review (RDCR) Core Capability Drivethrough (CCD) Transition Readiness Review (TRR) Operation Commitment Review (OCR) Development Commitment Package (DCP) 7.0 8.0 9.0 10.0 11.0
Version 5.0
Each artifact for Team 16 will have a baseline for each milestone. The milestones are in sequential order and the versioning number for each artifact will reflect this. Starting with the Draft Development Commitment Package, versioning numbers will be tagged with 5.0 and increments of 1.0 will be used for each of the following milestones. For versions between package releases, increments of 0.1 or less will be used.
A.3.2 Configuration Item and Rationale
Table 9: Artifacts and its volatility and impact severity Configuration Item Description Rationale Volatility Impact Severity The impact can range from moderate where only the document that was reviewed is impacted or it can be severe if the issue/defect found affects many documents (e.g. OCD)
AAR
Agile Artifact Reviews
These are the documents prepared by the IIV&V members that bring up issues and possible defects.
These document are highly volatile during Valuation, Foundation and Development Phases
ATPC
Acceptance Test Plan & Cases
This document contains plans and tests designed by the SRE and client to determine if the system is acceptable
This document is the most volatile in the Foundations, Rebaselined Foundations and Development Phases. The volatility of this document is high during Exploration, Valuation and Development Phases. Any major change to the project will cause the feasibility to be reassessed.
This document has a high impact on client satisfaction.
FED
Feasibility Evidence Description
A historical reference to historical feasibility rationale is needed to base further evidence on.
Low impact to the system. This document is dependant on other documents(SSAD, SSRD, etc) and is impacted by their volatility.
2c2d6620c530eea35471b790b76f5ba9934c3a16.doc
9
Version Date: 11/24/08
Quality Management Plan (QMP) Configuration Item Description Rationale This plan contains the activities for the two development cycles planned for 577b. It should be configuration managed to preserve historical plans. The changes to the LCP need to be tracked because this document helps monitor and manage the project and its progress. Volatility
Version 5.0 Impact Severity
IP
Iteration Plan
This document will be the most volatile in the Foundation and Rebaselined Foundation Phase. The volatility of this document is highest in the Valuation and Foundation Phases. It may also be volatile in the early Development Phase when the project is rebaselined. This document is highly volatile during the Exploration and Valuation Phases. There may be some changes in the Foundations phase and very little in the Development Phase. These document are highly volatile and change weekly during Exploration, Valuation, Foundation and Development Phases
This document impacts the weekly progress report as well as the planned development activities.
LCP
Life Cycle Plan
There could be high impact to the schedule if the COCOMO II Scale and Cost Drivers change. Other aspects of the document are affected by other documents or team member changes. The impact is severely high because this is the document that glues the vision and goals of Team 16's stakeholders. If the core vision changes, it will impact many other documents.
OCD
Operational Concept Description
This document contains the shared vision for Team 16 and should be configuration controlled to track the changes to the shared vision. These are the weekly project plans that should be configuration controlled to provide historical references to previous plans to identify scheduling issues and problems areas that need more attention.
PP
Project Plan
Low impact to the rest of the system.
2c2d6620c530eea35471b790b76f5ba9934c3a16.doc
10
Version Date: 11/24/08
Quality Management Plan (QMP) Configuration Item Description Rationale These are the weekly progress reports by the Project Manager and should be configuration controlled to provide metrics and historical data The prototypes should be configuration controlled to have ...