Quality Management Plan (QMP)

A.  Description

1.  Purpose

In value-based software engineering (VBSE) and LeanICM, “quality” is defined as the degree of success –critical stakeholders’ satisfaction. As these are generally several project stakeholders, the purpose of quality management (QM) involves balancing their mutual satisfaction along the lines negotiable by the stakeholders in their win-win negotiations.

One aspect of quality that is important to developers and clients is development efficiency. This implies that QM functions also need to be lean in avoiding excess overhead work in processing QM traffic. Thus, generating many low-impact concerns that need to be processed about such things as low-impact concerns that need to be processed about such things as English grammar usage to readers, it is better to package as English usage markup of an artifact as a single quality concern, and net to require developers to respond to each marked-up item.

A seeming exception to this is the need to turn in the results of quality activities, as these appear not to enhance product value around stakeholder satisfaction. However, analysis of quality data can often lead to significant value-adding project improvements. And, since the faculty is success-critical stakeholders who need the data to make future course improvements, it needs to be done (but not overdone).

2.  Quality Focal Point

As with everything else VBSE and LeanICM, QM involves balancing multiple conflicting objectives and strategies. One such conflict involves balancing two conflicting QM-related principles:

QM-1: Quality is everyone’s business.

QM-2: If you want something to happen, make somebody specifically responsible for it.

In principle, QM-1 should be sufficient. But on complex projects being done by people with additional responsibilities, it is all too easy for aspects of quality to get below people’s action thresholds. Since quality (stakeholders’ satisfaction) is important, QM-2 ensures that at least one project member is continually monitoring quality and reminding people to bring it back above their action threshold when necessary. Thus, although everyone remains responsible for the quality of their work, the Quality focal Point function has the responsibility of keeping all aspects of stakeholder satisfaction above people’s action thresholds. This should be considered as a constructive stakeholder-advocate function and not as bureaucratic, adversarial “find the guilty” function.

Particularly important responsibilities of the Quality focal Point person are defect prevention, detection, and removal; levels of service achievability; thoroughness of plan execution; coordination of changes with affected stakeholders; and coordination of developers and IIV&Ver activities. An additional compatible function is that of being project’s Learning Coordinator.

3.  Additional Information

577b Guidelines:

For CS 577b, this document should help the members of the project team understand each person’s contribution to quality. Each team has the flexibility to choose their own standards for quality management and should take the initiative in defining additional quality mechanisms as dictated by project requirements. For instance it should include the related trade offs as the degree of testing decreases and reviews increases, the methodology used to control injection and removal of defects etc. It should be clear from the plan that is primarily responsible for the implementation of the various parts of the plan.

4.  High-Level Dependencies

The Quality Management Plan has high dependencies with System and Software Requirements Definition (SSRD) and Life Cycle Plan (LCP)

B.  Sections of the QMP document

The followings are the sections for a typical Quality Management Plan document. It can be tailored to fit with your project. If you tailored the structure of this document by adding or removing a section or sub section, you should note in your Supporting Information Document (SID) about the tailoring. The objective of this QMP document is to encourage the team to ensure the quality of the project. Since, we have a very small team, so your quality management plan should not be too big, but plan only what you can do.

1.  Purpose

1.1  Purpose of the document

Summarize the purpose and contents of this document with respect to the particular project and stakeholders involved.

1.2  Status of the document

Summarize the major changes of project that affects the quality management approach. For example, discontinuation of team member, introducing a new quality-related management tool to the project, and etc.

2.  Quality Management Strategy

This document should focus on the projects’ strategic decisions on quality management. There will be separate documents that cover detailed test plans and procedures and peer reviews.

The projects’ quality management strategy should follow the Software Quality Opportunity Tree as shown below. A value/risk-based quality “defect” is any product characteristic that reduces the value of the product to its stakeholders. Defects can include missing requirements, poor COTS choices, inconsistent architecture and design specifications, inadequate handing of off-nominal requirements and exceptions, shortfalls in achieving level of service requirements, and lack of traceability among requirements, architecture, design, code and test artifacts.

A value-based software quality strategy will reflect the relative priorities of product capabilities and levels of service. It will also reflect the fact that early defect detection and removal is usually much more cost effective than late defect detection and removal

Figure 10: Software Quality Opportunity Tree

For CS577, projects should focus on strategies for defect prevention, detection and removal and value-risk based defect impact reduction. Working with clients on operational practices for input screening, manual back up, and rapid recovery from failures is also recommended. It is also valuable for the Quality Focal Point to determine root causes of defects and work out improved quality management practices.

2.1  Defect Prevention Strategies

This section should identify the defect prevention strategies that your team is using. This section will help Quality Focal Point person plan and identify the strategy and approach that will prevent possible defect, hence ensure the project’s quality. Candidate strategies include:

·  People practices

·  IPT, JAD, win-win , etc

·  PSP, Cleanroom, Dual development, etc

·  Manual execution, scenarios, etc

·  Staffing for dependability

·  Standard

·  Requirements, design, code, etc

·  Interfaces, traceability, etc

·  Checklists

·  Languages

·  Prototyping

·  Modeling and Simulation

·  Reuse

·  Root cause analysis

Below is examples of defect prevention strategies, you can use this as a reference and tailor to fit with your project.

Table 1: Defect Prevention Strategies

Strategy / Priority / Description
Win-Win / High / The win-win methodology will be used to ensure that all stakeholders' win conditions are met with the final implementation.
Incremental Commitment Model Standard / High / By using the Incremental Commitment Model templates and guidelines, the artifacts produced should have the correct format and substance.
Prototyping / High / Iterative cycles of prototyping will help make sure the client’s user interface expectations are understood early on and incorporated. We will meet with the client regularly to provide demos as features are implemented.
Dry run / High / We will do dry run before every presentation in order to double check the project and to sharpen up the presentation.
Code Review / High / It will be used to enforce standard and to avoid most defect.
Database Standard / High / Since we have to use the same database with Team 1 and 2, to define Database standard is a very important strategy to prevent future defect.
2.2  Defect Detection Strategies

Identify the project’s primary defect detection strategies and priorities. The following tables illustrate candidate levels of application of defect detection tools, reviewing, and testing. Particular consideration should be given to the agile quality practices of test-first, pair programming, and continuous integration.

Table 2: Defect Removal Profiles

Rating / Automated Analysis / Peer Reviews / Execution Testing and Tools
Very Low / -  Simple complier syntax checking. / -  No peer review. / -  No testing.
Low / -  Basic compiler capabilities for static module-level code analysis, syntax, type-checking. / -  Ad-hoc informal walk-throughs
-  Minimal preparation, no follow-up / -  Ad-hoc testing and debugging.
-  Basic text-based debugger.
Nominal / -  Some compilers extensions for static module and inter-module level code analysis, syntax, type-checking.
-  Basic requirements and design consistency, traceability checking. / -  Well-defined sequence of preparation, review, minimal follow-up.
-  Informal review roles and procedures. / -  Basic unit test, integration test, system test process.
-  Basic test data management, problem tracking support.
-  Test criteria based on checklists.
High / -  Intermediate-level module and inter-module code syntax and semantic analysis.
-  Simple requirements/ design view consistency checking. / -  Formal review roles with all participants well-trained and procedures applied to all products using basic checklist, follow up. / -  Well-defined test sequence tailored to organization (acceptance/ alpha/ beta/ flight/ etc.) test.
-  Basic test coverage tools, test support system.
-  Basic test process management.
Very High / -  More elaborate requirements/ design view consistency checking.
-  Basic distributed-processing and temporal analysis, model checking, symbolic execution / -  Formal review roles with all participants well-trained and procedures applied to all product artifacts and changes (formal change control boards).
-  Basic review checklists, root cause analysis.
-  Formal follow-up.
-  Use of historical data on inspection rate, preparation rate, fault density. / -  More advanced test tools, test data preparation, basic test oracles support, distributed monitoring and analysis, assertion checking.
-  Metrics-based test process management.
Extra High / -  Formalized* specification and verification.
-  Advanced distributed processing and temporal analysis, model checking. Symbolic execution.
-  Consistency-checkable pre-condition and post-conditions, but not mathematical theorems / -  Formal review roles and procedures for fixes, change control.
-  Extensive review checklists, root cause analysis.
-  Continuous review process improvement.
-  User/Customer involvement, Statistical Process Control / -  Highly advanced tools for test oracles, distributed monitoring and analysis, assertion checking
-  Integration of automated analysis and test tools.
-  Model-based test process management.

Table 3: Software Defect Detection

Automated Analysis / Reviewing / Testing
-  Completeness checking
-  Consistency checking
-  Views, interface, behavior, pre/post conditions
-  Traceability checking
-  Compliance checking- Models, assertions, standards. / -  Peer review, inspections
-  Architecture Review board
-  Pair programming / -  Requirements and design
-  Structure
-  Operational profile
-  Usage (Alpha/ Beta)
-  Regression
-  Value/ risk – based
-  Test automation
2.2.1  Automated Analysis

In this section, describe which kinds of automated analysis technique that your team uses in defect detection, priority level of each technique and how do you use it. You can use the techniques described in the table above and tailor to fit with your team.

2.2.2  People Review

In this section, describe which kinds of people review technique that your team uses in defect detection, priority level of each technique and how do you use it. You can use the techniques described in the table above and tailor to fit with your team.

2.2.3  Execution Testing

In this section, describe which kinds of execution testing technique that your team uses in defect detection, priority level of each technique and how do you use it. You can use the techniques described in the table above and tailor to fit with your team.

2.3  Defect Removal Tracking

This section should state the methods to be used for Problem, Issue and Defect reporting and tracking.

·  Identify the system for receiving reports from the team or IIV&Vers or quality focal point personnel.

·  Identify how the reports will be monitored and by whom, including frequency of analysis, and weekly summary report generation.

2.4  Level of Service Achievement Monitoring

The Quality Focal Point or his/her designate needs to monitor progress towards slowing architectural achievability of level of service requirements in Feasibility Evidence Description (FEP), and progress towards actual achievability of level of service requirements in integration and testing. Identify roles, responsibilities, and processes for these functions.

2.5  Process Assurance

The objective of software quality management is to ensure the delivery of a high-quality software product. This section should elaborate on Level of Services, and roles & responsibilities of team members in achieving them.

Traditional quality assurance functions listed below can be used and tailored as per project.

·  Auditing the project's compliance with its plans, policies, and procedures;

·  Monitoring the performance of reviews and tests;

·  Monitoring corrective actions taken to eliminate reported quality related deficiencies

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

2.6  IIV&V Coordination

Identify roles, responsibilities, and processes for timely delivery of drafts and artifacts to IIV&Vers, and rapid response to IIV&Vers concerns.

3.  Configuration and Change 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.

577 Guidelines:

Up to Development Commitment Review time, it will be sufficient to identify:

·  Which items will be baselined when

·  How changes to the baseline will be coordinated with the client (e.g., meeting for major changes, email for moderate changes, none for trivial changes)

·  How outstanding problem reports will be tracked

·  Who will be the custodian of the master baselined versions, and how he/she will preserve the integrity and recoverability of the master versions

·  Who will be the Configuration Manager and how will he/she ensure that a version control is maintained.

3.1  Product Element Identification

The product elements to be identified should include the project deliverables enumerated in Life Cycle plan document, as appropriate, and any other elements that stakeholders may consider important (e.g. operational procedures, project critiques). Each product element should have an owner and a unique identifier. Each individual sub element of the OCD, SSRD, SSAD, and delivered software package should have a unique identifier, enabling traceability relations to be established among these sub elements.