A Guide to the Forthcoming 2012 Revision of the IEEE Software Quality Assurance Standard

4/11/2012 © David I. Heimann 1

Contents

• Introduction to SQA and IEEE 730
• Process Implementation
• Product Assurance
• Process Assurance
• Annexes and Summary


What is IEEE 730?
• Gives guidance and establishes requirements for
Software Quality Assurance in a software project.
• The very first published software engineering
standard – 1981.
• Forthcoming version of IEEE 730 greatly expands on
existing version of 2002.
• Amplifies Software Quality Assurance tasks in IEEE
12207 -- Software Life Cycle Processes.
• SQA is one of 43 system and software process areas
identified in IEEE 12207 (see next slide for chart).

The 43 System &
Software Process Areas
SQA
Process

Related
Processes


What Is Software Quality Assurance?
• A set of activities that →

– defines and assesses the adequacy of software
processes to →

– provide evidence for a justified statement of
confidence that →

– the software processes will produce software
products that →

– conform to their established requirements.


ꞌꞌEstablished Requirementsꞌꞌ

• The set of requirements that the project has:
– verified as satisfying project-specific criteria
(such as clarity, suitability, and feasibility)
– validated to be faithful reflections of stakeholder
requirements.
• Established requirements are accepted by the
project to form the basis of product development.


SQA Is Not

• Testing

• Reviewing or Auditing

• Done only at the end of development

• Reactive

• A gate or ꞌꞌpoliceꞌꞌ

• An organizational unit (though some units may be
named ꞌꞌSQAꞌꞌ)

Why SQA?
• Fewer defects in the processes used to develop
software.
• Fewer defects in business rules and requirements.
• Fewer defects in the software products.
• Defects are found much earlier in lifecycle and so
cost far less to address.
• Reduce and eliminate waste.
• Generate confidence throughout the lifecycle that
activities will go well.


You Don’t Want This

http://www.amazingonly.com/cartoon/software-bugs-life/

SQA Activity Areas

I. Process Implementation

II. Product Assurance

III. Process Assurance

There are 16 SQA tasks in these 3 activity areas


Process Implementation Tasks

• Establish the SQA Processes

• Coordinate with related software processes

• Plan SQA activities

• Execute the SQA Plan

• Manage SQA records

• Evaluate organizational objectivity


Product & Process Assurance

roduct Assurance
 Software product conforms to established
requirements

rocess Assurance
 Project activities conform to accurate and
effective defined processes

Product Assurance Tasks

• Evaluate plans for conformance

• Evaluate products for conformance

• Evaluate products for acceptability

• Evaluate product lifecycle support for conformance

• Measure products


Process Assurance Tasks

• Evaluate lifecycle processes for conformance

• Evaluate environments for conformance

• Evaluate subcontractor processes for conformance

• Measure processes

• Assess staff skill and knowledge


I. Process Implementation

Dilbert, by Scott Adams, via http://madhusudhan.info/Comics/Dilbert/


Task 1 – Establish the SQA Process

Define an effective SQA process that identifies what to
do and how to:

– Do it well

– Confirm it is done right

– Measure and track it

– Manage and improve it

– Encourage using it to improve quality


Task 2 – Coordinate with Related
Software Process

Enable SQA to integrate activities with other software
processes, such as:
1. Verification, Validation, Review, and Audit
2. Project Planning
3. Technical Processes
4. Implementation Processes
5. Reuse Processes
6. Agreement


Task 3 – Planning the SQA Activities

• Adapt the generic SQA processes to the specific
needs of the project.

• Results are documented in the Software Quality
Assurance Plan (SQAP).

• This is where SQA is adapted to the specific nature
of the project (e.g., Agile, CMMI, embedded, etc.)


Outline for the SQA Plan


Task 4 – Executing the SQA Plan

• Execute the SQAP.

• Revise the SQAP as appropriate.

• Raise non-comformances when products or
processes do not conform to their requirements.

• Create and use SQA records to improve quality.


Task 5 – Manage SQA Records

• Records are created, maintained, and made available
to project personnel and management.

• Records aim to document that project activities:
– Are performed in accordance with project plans.

– Comply with the contract.

– Support the identification and rectification of problems, causes,
and improvements.

– Enable information sharing.


Task 6 – Evaluate Organizational Objectivity

• Those who perform SQA activities must have the
organizational objectivity and authority to make
objective evaluations and verify problem
resolutions.
• Three important aspects of objectivity are:
– Technical Independence: Not involved in the development of the
products being evaluated.

– Managerial Independence: Not reporting to individuals responsible
for product development/project management.

– Financial Independence: Budget not controlled by individuals
responsible for product development/project management.

II. Product Assurance

http://www.amazingonly.com/cartoon/software-bugs-life/

Task 7 – Evaluate Plans for Conformance

• Identify plans required by the contract.

• Raise non-conformances when plans do not
conform to the contract (or when the contractural
requirements are inadequate).

• Raise non-conformances when plans are not
mutually consistent.


Task 8 – Evaluate Products for Conformance

• Identify products/documentation required by the
contract.

• Identify allocated requirements and ensure adequacy.

• Ensure that evaluations of software
products/documentation for conformance against the
requirements are performed.


Task 9 – Evaluate Product for Acceptability

• Determine project’s understanding of conditions for
product acceptance.

• Prior to delivery, evaluate the level of confidence
that the software products and related
documentation will be acceptable to the acquirer.

Note -- Depending on contractual agreements (e.g., Agile
environments), the customers themselves may make
some acceptability determinations prior to delivery.


Task 10 – Evaluate Product Support

• Have acquirer’s expectations for product support
and cooperation been established and documented?

• Have they been met?

• If the SQA process ends at delivery, how is suitable
support ensured?


Task 11 – Measure Products

• Do the project measures accurately and objectively
represent the quality of the software products?

• Are improvements done as a result of the product
measurements effective in improving product
quality?

• Do the measurements of software products satisfy
the measurement requirements and conform to the
measurement plans?


III. Process Assurance

http://softwaretestingandqa.blogspot.com/ (and Calvin &
Hobbes)

Task 12 – Evaluate Life Cycle Processes

• Does the software development life cycle conform to
project plans and fit with contractural requirements?

• Does the execution of project activities conform to
the project plans?

• Does the execution of project activities yield
products that conform to requirements?


Task 13 – Evaluate Environments

• Do the software development environments conform
to project plans?

• Do the software test environments conform to
project plans?


Task 14 – Evaluate Subcontractor Processes

• Do subcontractor processes conform to
requirements passed down?

• Have acquisition needs, goals, product, and service
criteria been identified? Have they been met?


Task 15 – Measure Processes

• Do the project measures support effective
management of the software processes?

• Do the project measures meet the information needs
necessary for managing effective processes?

• Does the executed measurement process satisfy the
measurement requirements and conform to the
measurement plans?


Task 16 – Assess Staff Skill & Knowledge

• Do the staff, including SQA staff, assigned to the
project have the knowledge, skills, and abilities to
perform their assigned roles?

• Have education and training plans been developed?
Are they effective?


Annexes

• Guidance for SQA Plans
• IEEE 730 and IEEE 12207 SQA Outcomes
• IEEE 730 and Agile Software Development
• IEEE 730 and Very Small Enterprises (VSE)
• Software Integrity Levels & Assurance Cases
• Corrective and Preventive Action


Other Informative Material
1. Comparison of old & new SQA Plan outline
2. IEEE 730 and CMMI
3. IEEE 730 and SPICE
4. IEEE 730 and Bodies of Knowledge (BOK)
5. Industry-Specific Guidance
6. Product Support
7. System vs. Software QA
8. Software Tool Validation
9. Tools, Techniques, and Methods

IEEE 730 and Agile
• In Agile, the product backlog plays a role of the ꞌꞌcontractꞌꞌ.
730 shows how to use the product backlog in its role as a
contract.
• The product SQA portion of SQA Plan specifies the Agile
ꞌꞌdoneꞌꞌ criteria.
• Non-conformances are inserted into the backlog and
addressed in the appropriate sprints.
• Evaluation of product for acceptance is a continual process in
Agile, not just at end of project.
• IEEE 730 has an annex on Agile with further details.


IEEE 730 and CMMI

• CMMI has 16 core process areas. The two that relate to quality
are PPQA (Product and Process Quality Assurance) and VER
(Verification).
• Since CMMI does not specify a particular process flow, CMMI-
conforming organizations need to design their own PPQA
process.
• IEEE 730 provides details for this process design.
• VER process area implements product quality assurance
according to the plan in PPQA. 730 covers both product and
process quality assurance.
• 730 has associated materials with maps between 730 and CMMI.


Software Integrity Levels
• A set of discrete values used to represent the level of risk of a
software product.
• The software integrity level of a product or component
determines the level of rigor and quality assurance to be
applied in their development and implementation.
• See sample software integrity description below:

Level Description
4 Catastrophic failure – loss of life, economic/social loss, system loss
3 Serious failure – loss of system, data, usability
2 Moderate failure – must correct and re-run
1 Minor failure – workaround is possible

Summary
• IEEE 730 provides a foundation for Software Quality
Assurance, which in turns provides confidence that
software products will conform to their established
requirements and satisfy the customer.

• IEEE 730 addresses the three areas of SQA: Process
Implementation, Product Assurance, and Process
Assurance.

• IEEE 730 can be used to prove conformance where
SQA conformance is required, and to provide
guidance where SQA conformance is desired.

Available Articles (see sign-up sheet)


A Guide to the Forthcoming 2012 Revision of the IEEE Software Quality Assurance Standard

More Related Content

What's hot

Viewers also liked

Similar to A Guide to the Forthcoming 2012 Revision of the IEEE Software Quality Assurance Standard

A Guide to the Forthcoming 2012 Revision of the IEEE Software Quality Assurance Standard