IEEE 730

Tor StålhaneIDI / NTNU

Contents • Purpose• Reference documents• Management• Documentation• Standards, practices

and metrics• Reviews and audits• Test• Problem reporting

• Tools, techniques and methodologies

• Code control• Media control• Supplier control• Records collection,

maintenance and retention

• Training• Risk management

Quality plan

The quality plan shall contain the sections shown in the content slide. The standard describes the contents of each section – including subsections

If one or more of these sections are irrelevant for the current project, the section shall still be included but with the statement “Not relevant” or an other term to this effect.

Purpose

• The purpose of the QA plan• Which software components – e.g.

subsystems – are covered by the plan• For each component we need to describe

– The component’s name– The purpose of the component– Which parts of the life cycle that is covered by

the plan

Reference documents

Contains a list of all documents that are referenced in the QA plan, e.g.

• Test plan• Documentation standard• Problem reports• IEEE standard for software terms

Management

This section has three subsections• Organization• Tasks, split up into

– Which parts of the life cycle are covered– Tasks to be done– Couplings between tasks and important

project milestones • Who is responsible for what

Documentation - 1 This part has three subsections• Purpose, where we describe

– The documents that must be produces. We must cover the whole life cycle specified

– How will the documents be controlled• Our minimum requirements for documentation,

which must include this standard’s minimum requirements

• Miscellaneous – other things that we want to include

Documentation - 2

This standard’s minimum requirements for documentation:

• SRS – Software Requirements Specifications• SDD – Software Design Description• SVVR Software Verification and Validation

Report • Use documentation• SCMP – Software Configuration Managment

Plan

Standards, practices and metrics - 1

Purpose • Identify standards, practices, conventions

and metrics that will be used in the project• Describe how we will control that the

identified practices, conventions and metrics are used

Standards, practices and metrics - 2

The contents of this section must, as a minimum, contain standards for

• Documentation• How to describe the logical structure of the

software• Coding• Comments inserted into the code• Testing• Selected software and project metrics

Standards, practices and metrics - 3

Examples of useful metrics include measurements for

• The number of decisions• The number of error messages• Implemented requirements• Project plan deviations

Reviews and audits – 1

As a minimum we need to describe how we will perform the following reviews:

• SRR – Software Requirements Review• PDR – Preliminary Design Review• CDR – Critical Design Review• SVVPR – Software Validation and

Verification Plan Review

Reviews and audits – 2

More reviews:• Functions review – is all functionality

implemented?• Physical review – are all software and all

documents consistent?• Reviews performed during the

development process• Management periodical audits

Reviews and audits – 3

• Audits during the development process– Code vs. design documentation– Control of all interfaces– Design vs. functional requirements– Functional requirements vs. test case

descriptions • SCMPR – Software Configuration

Management Plan Review

Reviews and audits – 4

• Post Mortem Review – what can we learn form this project?

• Other reviews, e.g. UDR – User Documentation Review

Test

This section shall include all tests that are not already included in SVVP

This includes descriptions of test methods to be used.

Problem reporting

We need to describe • Procedures used when reporting, tracing

and solving problems. This goes for problems pertaining to– Software development – Maintenance – Development process

• Who is responsible for controlling that the procedures are used

Tools, techniques and methodologies

All tools, techniques and methods used shall have a short description where we describe:

• The tool, method or technique itself• How and for what purpose it should be

used• Why did we chose this tool, technique or

method

Code control

For all code that is under version control, we need to describe how we shall

• Perform maintenance• Store the code – e.g. on what type of

media• Keep the code safe from virus, theft and

so on• Document it

Media control

For all media used, we need to describe• The software needed to read from and

write to the media• How we will protect the media against

– Unauthorized access– Destruction or harm due to accidents

Supplier control –1

How will we control that software supplied by a third party satisfy our quality requirements?

We need to consider two types of third party software, i.e. software that

• Is already developed – components off the shelf, reuse or customer made

• Will be developed for this project

Supplier control – 2

Software that is already developed – components off the shelf (COTS), reuse or customer made

For this case we need to describe how we will verify and validate this software with respect to its quality

Supplier control - 3

Software that will be developed for this project.

For this case we need to describe how we will control that the development company uses a quality assurance standard that is acceptable for our project

Records collection, maintenance and retention

Here we need to describe• Which project documents shall be retained• How shall we maintain these documents• How shall we keep the documents safe

from unauthorized access

Training

Here we need to describe the training needed for developers and management in order to satisfy the requirements in this QA plan.

Risk management

Here we need to describe the methods and procedures used to handle risk in the project. This includes methods for

• Risk identification – what are the most important project risks

• Risk assessment – probability / frequency and consequences

• Risk surveillance – will it happen• Risk control – possible actions