Quality Management Plan (QMP)

Quality Management Plan (QMP) Version 3.0

Quality Management Plan (QMP)

Somatis Web and Data Services

Team 3

Name / Roles
Fall 2012
Fei Qu / Project Manager
Jizhou Lu / Life Cycle Planner, Operational Concept Engineer
Xianan Fan / Prototyper
Dian Peng / Architect, Feasibility Engineer
Qiuyang Liu / Requirements Engineer
Jordan Padams / IIV&V
Spring 2013
Jordan Padams / All

2/11/13

17

QMP_RDCP_S13b_T03_V3.0.doc 2/11/13

Quality Management Plan (QMP) Version 3.0

Version History

Date / Author / Version / Changes made / Rationale /
10/26/12 / JP / 1.0 / ·  Completed sections 1 and 2 of template / ·  Preparations for ARB
11/16/12 / JP / 2.0 / ·  Updated status of document in section 1.2. Completed section 3. / ·  Required completion for DCP
11/29/12 / JP / 2.1 / ·  Updated LOS monitoring to include more explicit responsibilities. / ·  Responsibilities were too vague.
2/11/13 / JP / 3.0 / ·  Updated responsibilities to reflect change in team members / ·  Updates for RDCP

Table of Contents

Quality Management Plan (QMP) i

Version History ii

Table of Contents iii

Table of Tables iv

Table of Figures v

1. Purpose 1

1.1 Purpose of the QMP 1

1.2 Status of the QMP 1

2. Quality Management Strategy 2

2.1 Defect Prevention Strategies 2

2.2 Defect Detection Strategies 2

2.3 Defect Removal Tracking 4

2.4 Level of Service Achievement Monitoring 4

2.5 Process Assurance 5

2.6 IIV&V Coordination 5

3. Configuration Management 7

3.1 Product Element Identification 7

3.2 Configuration Item and Rationale 9

3.3 Configuration Change Management 14

3.4 Project Library Management 16

3.5 Resources and Personnel 17

3.6 Tools 17

17

QMP_RDCP_S13b_T03_V3.0.doc 2/11/13

Quality Management Plan (QMP) Version 2.1

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 3

Table 5: Level of Service achievement strategy and its responsible person 4

Table 6: Product Elements 7

Table 7: Priority of Product Elements in Each Phase 8

Table 8: Configuration Item and Rationale 9

Table 9: Project Libraries 16

Table 10: CM Roles and Responsibilities 17

Table 11: Quality Management Tools 17

17

QMP_RDCP_S13b_T03_V3.0.doc 2/11/13

Quality Management Plan (QMP) Version 2.1

Table of Figures

Figure 1: CM Management Flowchart 15

17

QMP_RDCP_S13b_T03_V3.0.doc 2/11/13

Quality Management Plan (QMP) Version 2.1

1.  Purpose

1.1  Purpose of the QMP

The purpose of this document is to describe the quality control methods used by the team in an attempt to maximize satisfaction of the success critical stakeholders. This includes, but is not limited to, defect prevention, detection and mitigation, level of service monitoring, and configuration management.

1.2  Status of the QMP

This is version 2.0 of this document based from the template found in the USC ICSM EPG tool online at http://greenbay.usc.edu/IICSMSw/practice.mgmt.quality_mgmt.base/guidances/templates/resources/IICSMSw_QMP_Template.doc .

Version 1.0 included completion of sections one and two, detailing defect prevention strategies, defect detection strategies, defect removal tracking, level of service achievement monitoring, process assurance, and IIV&V coordination.

Version 2.0 included the completion of section three, detailing the configuration management plan, such as product element identification, configuration items and rationale, configuration change management, project library management, resources and personnel, and tools.

Version 2.1 included an update to the LOS Monitoring Roles and Responsibilities table in Section 2.4. Previous responsibilities were not explicit enough if describing what the team members would need to do in order to monitor and maintain the LOS requirements.

Version 3.0 includes updates to LOS monitoring based on new NDI and changes in team members and roles.

2.  Quality Management Strategy

This section identifies the defect prevention, defect detection, and defect removal strategies that your team is using/will be used.

2.1  Defect Prevention Strategies

Table 1: List of defect prevention strategies

Strategy / Priority / Description
Win-Win / High / Win-win negotiations will take place using Winbook to ensure all SCSs’ win conditions are met.
Incremental Commitment Model Standard / High / ICM templates and guidelines are used through all stages of the planning and development process. More specifically the ICSM EPG is being used as a guide.
Prototyping / High / Prototypes and prototype mockups will be used throughout the development life cycle in an effort to ensure SCS satisfaction with proposed developments.
Practice Presentation / Medium / Presentation will be practiced before official reviews in an effort to find errors in data and provide feedback to team members.
Code review / High / Review of code will be performed by all members in an attempt to minimize code defects and coding standard flaws.
Stakeholder Involvement / High / Weekly communication and evaluation by SCS will ensure a good product is developed. SCS has also taken ownership to ensure success-critical documents are reviewed by external stakeholders.
Evolutionary Research / Medium / Research of possible evolutionary tools and storage solutions are included as a requirement for the task, and in the process will help the team better tailor current development to include possible future implementations.

2.2  Defect Detection Strategies

2.2.1  Automated Analysis

Table 2: Automated analysis strategy for defect detection

Strategy / Priority / Description
Completeness checking / High / Test whether code is complete and runs successfully
Consistency Checking / High / Check code to requirements and design
Compliance checking to coding standards / High / Ensure code meets basic coding quality standards. Standard TBD.
Dependency traceability / High / Verify all dependencies are traced, documented, and included with software.
Interface pre/post conditions / High / Ensure all internal and external interface are defined correctly and included in documentation.

2.2.2  People Review

Table 3: People review strategies for defect detection

Strategy / Priority / Description
Walk-through Peer Reviews / High / Informal peer reviews that happen on a weekly/bi-weekly basis to ensure code is functioning as expected and meets quality standards.
Architecture Review Board / High / Formal review of all documentation and progress.
SCS Review / High / Meet with SCS and present implementation/prototypes to receive feedback to ensure WinWin success. Informal review involving main functionality to be used by SCS.
Formal Peer Review / High / Formal peer review to determine progress, completeness, reliability, and compare to requirements and expected schedule.

2.2.3  Execution Testing

Table 4: Execution testing strategies for defect detection

Strategy / Priority / Description
Requirements and Design / Medium / Because of a mostly UI based system, it is somewhat important to document and track all requirements and design thoroughly and ensure product meets these.
Unit Testing / Medium / Only certain modules of the task will require backend software where unit testing will be leveraged in an effort to ensure expected internal functionality.
Operational Profile / Medium / Overlapping of tests will occur for the data service to ensure expected results from varying types of data and user expectations.
Usage / High / Usage testing will be critical to the success of the software since a majority of the task is UI based.
Regression / High / Regression testing will be important to have in place for evolutionary implementations of the software as the company expands.
Risk-Based Testing / High / Testing priority will go to those addressing some of the higher risk items, such as security.

2.3  Defect Removal Tracking

Defects for the system are tracked and reported using Bugzilla software at http://greenbay.usc.edu/bugzilla3/ . Bugs can be reported by any team member, and assigned according to component.

All documentation is available on the team website at http://greenbay.usc.edu/csci577/fall2012/projects/team03/ and is monitored and reviewed by the IIV&V Engineer.

Bugzilla reports and metrics will be generated on an as-needed basis by the IIV&V Engineer.

2.4  Level of Service Achievement Monitoring

Table 5: Level of Service achievement strategy and its responsible person

Role / Responsible person / Responsibility
Browser Support LOS Monitor / Jordan Padams / Test all UI features in expected supported browsers. Responsibility follows with website development.
Website downtime LOS Monitor / Jordan Padams / Verify hosting service will be able to meet these LOS requirements. If not, research potential alternatives and present to client. Verify Exosite term and conditions meet LOS requirements.
Database Access LOS Monitor / Jordan Padams / Tests will be developed to have multiple users simultaneously access same data from Exosite Portals interface.
Data Ingest Security LOS Monitor / Jordan Padams / Ensure LOS requirements are included in Exosite terms and conditions when service is purchased. Develop test cases to attempt to breach security.
Data Loss LOS Monitor / Jordan Padams / Ensure LOS requirements are included in Exosite terms and conditions when service is purchased.

2.5  Process Assurance

The IIV&V engineer is responsible for process assurance in the following areas:

·  Auditing project compliance to plans, policies, and procedures;

·  Monitoring performance;

·  Monitoring review and testing procedures;

·  Monitoring corrective actions taken to eliminate quality deficiencies;

·  Ensuring SCS involvement

The USC CSCI-577 staff provides general oversight for process assurance, including the scheduling of deliverables, tasks, and assignment, as well as evaluating the projects status on a regular basis.

2.6  IIV&V Coordination

During Exploration, Valuation, and Foundations phases, on-campus students and the IIV&V Engineer coordinate activities through weekly meetings via teleconference and screen sharing, as needed. There is also a face-to-face meeting approximately once per month.

During Rebaselined Foundations and Development phases, the task lead will plan and coordinate weekly face-to-face meetings with client.

All expected milestones and completion dates are outlined in the via the progress reports found on the team website. All documents can also be found on the team website.

Defects noted by the IIV&V Engineer are tracked using Bugzilla (see Section 2.3).

Any remaining issues, comments, concerns amongst the team and the IIV&V Engineer are discussed at the weekly meetings, or via email/phone.

3.  Configuration Management

3.1  Product Element Identification

Table 6 lists the product elements for the project, including the project deliverables enumerated in Life Cycle plan document, as appropriate, and any other elements that stakeholders may consider important.

Table 6: Product Elements

Product Element / Filename Convention / Responsible Person
Client Interaction Report / CIR_<package-acro>_<semester>_T<team>_V<version>.docx / Project Manager
OCD / OCD_<package-acro>_<semester>_T<team>_V<version>.doc / Operation Concept Engineer
LCP / LCP_<package-acro>_<semester>_T<team>_V<version>.doc / Life Cycle Planner
FED / FED_<package-acro>_<semester>_T<team>_V<version>.doc / Feasibility Analyst
PRO / PRO_<package-acro>_<semester>_T<team>_V<version>.doc / Prototyper
SSAD / SSAD_<package-acro>_<semester>_T<team>_V<version>.doc / System Architect
SID / SID_<package-acro>_<semester>_T<team>_V<version>.doc / Project Manager
QMP / QMP_<package-acro>_<semester>_T<team>_V<version>.doc / IIV&V
Project Effort / N/A – use ER system / All
Project Plan / Week<week >_MPP_<semester>_T<team>.mpp / Project Manager
Progress Report / Week<week >_PR_<semester>_T<team>.xls / Project Manager
Client Meeting Minutes / N/A – Minutes are online at http://greenbay.usc.edu/csci577/fall2012/projects/team03/CMN/index.html / IIV&V
Client Meeting Agenda / N/A – Agendas are online at http://greenbay.usc.edu/csci577/fall2012/projects/team03/CMN/index.html / IIV&V
Dev Team Meeting Minutes / N/A – Minutes are online at http://greenbay.usc.edu/csci577/fall2012/projects/team03/DMN/index.html / IIV&V
Dev Team Meeting Agenda / N/A – Agendas are online at http://greenbay.usc.edu/csci577/fall2012/projects/team03/DMN/index.html / IIV&V
COTIPMO / N/A – Stored online at https://greenbay.usc.edu:9443/cotipmo/web / PM
User Guide To Wordpress / somatis_wordpress_user_guide_v<version>.doc / Website Developer
Hosting and Storage Service Evaluation / somatis_services_evaluation_v<version>.ppt / IIV&V

The following list designates the values to be input for the variables denoted in the Table 6, above:

·  package-acro – the acronym of the package the document will be included in. i.e. VCP, FCP, etc.

·  semester – the semester (F or S), year (YY), and course section (a or b) the document was developed. i.e. Fall 2012 Section A = F12a

·  team – 2 digit team number. i.e. Team 3 = 03

·  version – version number of the document in the form X.X

·  package – similar to package-acro, except the P is spelled out as Package. i.e. VCPackage

Table 7 describes the priority level of each document in each phase in an effort to help the development team identify which document should be more closely monitored during each period. The priority levels are as follows:

·  Very Low (VL) – minimal attention, if any

·  Low (L) – some attention necessary, but not critical in nature

·  Medium (M) – some attention necessary, somewhat critical to success of phase

·  High (H) – close attention needed throughout phase, somewhat critical to success of phase

·  Very High (VH) – close attention needed throughout phase, critical to success of phase

Table 7: Priority of Product Elements in Each Phase

Product Element / Priority
Exploration phase / Valuation phase / Foundations phase / Development phase / Operation phase
Client Interaction Report / M / L / VL / VL / VL
OCD / VH / VH / H / M / VL
LCP / M / VH / M / L / VL
FED / M / VH / H / L / VL
PRO / M / VH / H / M / VL
SSAD / VL / H / VH / H / VL
SID / VL / M / L / L / L
QMP / VL / M / M / M / M
Project Effort / VH / VH / VH / VH / VH
Project Plan / VH / VH / VH / VH / VH
Progress Report / H / H / H / H / H
Client Meeting Minutes / M / M / M / M / M
Client Meeting Agenda / M / M / M / M / M
Dev Team Meeting Minutes / M / M / M / M / M
Dev Team Meeting Agenda / M / M / M / M / M
COTIPMO / VL / H / H / H / H
Wordpress User Guide / VL / M / H / H / H
Hosting and Storage Service Evaluation / M / M / VH / VL / VL

3.2  Configuration Item and Rationale

Table 8 lists the configuration items that are required for continued development and system maintenance, rationale behind the selection of the item, volatility of the item, and the impact this item has on the task.

Table 8: Configuration Item and Rationale

Configuration Item / Description / Rationale / Volatility / Impact Severity /
OCD / Operational Concept Description / Major artifact for vision of overall system among stakeholders. Volatile during Exploration and Valuation phases, but stabilizes for remaining phases. / Very severe / Vision of system has strong effect on integral aspects of project, including reqs, desing, code, etc.
LCP / Life Cycle Plan / Lays out goals, plans, responsibilities, and resources. Most volatile during Valuation phase, but can change as slips in schedule/personnel occur. / Very severe / Incorrect detailing of responsibilities and resources can lead to hiring of incorrect employees and/or incorrect feasibility analysis.