Transcript IEEE 730-eng

IEEE 730
Tor Stålhane
IDI / 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