IEEE Software Engineering Standards

IEEE: Institute of Electrical and Electronics Engineers

A transnational organization founded in 1884, IEEE consists of dozens of specialized societies within
geographical regions throughout the world. Software testing standards are developed within the technical
committees of the IEEE Societies and the Standards Coordinating Committees of the IEEE Standards
Board.
These standards are created through a process of obtaining the consensus of practicing
professionals. This consensus process, which includes careful discussion and debate among members of
the various committees who serve voluntarily, is one of the fundamental themes of the standards process.
Another key theme is to provide standards in a timely manner, from project approval to standard approval
is approximately 3 years.

To obtain the full version of the IEEE Standards:

IEEE
445 Hoes Lane
PO Box 1331
Piscataway, NJ 08855-1331

The following standards are those a tester should be aware of, and include a short abstract about each one:

610.12-1990: IEEE Standard Glossary of Software Engineering Terminology

Topics covered include addressing; assembling, compiling, linking, loading, computer
performance evaluation, configuration management, data types; errors, faults, and failures; evaluation
techniques; instruction types; language types; libraries; microprogramming; operating systems; quality
attributes; software documentation; software and system testing; software architectures; software
development process; software development techniques; and software tools. This standard promotes
clarity and consistency in the vocabulary of software engineering and associated fields.

730-1998: IEEE Standard for Software Quality Assurance Plans

The purpose of this standard is to provide uniform, minimum acceptable requirements for
preparation and content of SQAPs (Software Quality Assurance Plans).
The plan includes the following sections:
Purpose
Defines purpose and scope
Reference Documents
Complete list of documents referenced within SQAP
Management
Describes organization, tasks, responsibilities
Documentation
Identifies the documentation governing development, verification and validation, use, and
maintenance of the software.
Documents include: Software Requirements Specification (SRS), Software Design
Description (SDD), Software Verification and Validation Plan (SVVP), Software Verification and
Validation Report (SVVR), User documentation, Software Configuration Management Plan (SCMP),
Software Development Plan, Standards and procedures manual, software project management plan,
software maintenance manual.
Standards, practices, conventions, and metrics
 Identifies the standards, practices, conventions and metrics to be applied, and states how
compliance with these items is to be monitored and assured.
Reviews and audits
Defines the technical and managerial reviews and audits to be conducted, states how the
reviews and audits are to be accomplished, and states what further actions are required and how they are
to be implemented and verified.
Test
Identifies all the tests not included in the SVVP for the software covered by the SQAP and
states what methods are to be used.
Problem reporting and corrective action
Describes the practices and procedures to be followed for reporting, tracking, and
resolving problems identified in both software items and the software development and maintenance
process
Tools, techniques, and methodologies
Identifies the special software tools, techniques, and methodologies that support SQA,
state their purposes, and describe their use.
Code control
Defines the methods and facilities used to maintain, store, secure, and document controlled
versions of the identified software during all phases of the software life cycle.
Media control
Identifies the media for each computer product and the documentation required to store the
media, including the copy and restore process, and protects the computer program physical media from
unauthorized access or inadvertent damage or degradation during all phases of the software life cycle.
Supplier control
States the provisions for assuring that software provided by suppliers meets established
requirements. Also states the methods that will be used to assure that the software supplier receives
adequate and complete requirements. This section also states the methods to be employed to assure that
the developers comply with the requirements of this standard.
Records collection, maintenance, and retention
Identifies the SQA documentation to be retained; states the methods and facilities to be
used to assemble, safeguard, and maintain this documentation, and designates the retention period.
Training
Identifies the training activities necessary to meet the needs of the SQAP
Risk management
Specifies the methods and procedures employed to identify, assess, monitor, and control
areas of risk arising during the portion of the software life cycle covered by the SQAP.

828-1998: IEEE Standard for Software Configuration Management Plans

This standard establishes the minimum required contents of a software configuration (SCM) plan.
It is supplemented by 1042-1987 (which provides approaches to good software configuration
management planning). This standard applies to the entire life cycle of critical software. The plan
documents what SCM activities are to be done, how they are to be done, who is responsible for doing
specific activities, when they are to happen, and what resources are required.

829-1998: IEEE Standard for Software Test Documentation

This standard describes a set of basic test documents that are associated with the dynamic aspects
of software testing. The standard defines the purpose, outline, and content of each basic document.
Documents included:
ƒ Test Plan
ƒ Test Design Specification
 ƒ Test Case Specification
ƒ Test Procedure Specification
ƒ Test Item Transmittal Report (a document identifying test items)
ƒ Test Log
ƒ Test Incident Report
ƒ Test Summary Report

830-1998: IEEE Recommended Practice for Software Requirements Specifications

This standard describes the recommended approaches for the specification of software
requirements. It describes the content and qualities of a good software requirements specification (SRS),
and includes several sample SRS outlines.

1008-1987 (R1993): IEEE Standard for Software Unit Testing (ANSI)

This standard defines an integrated approach to systematic and documented unit testing. The
approach uses unit design and unit implementation information, in addition to unit requirements, to
determine the completeness of the testing. The standard describes a testing process composed of a
hierarchy of phases, activities, and tasks. Further, it defines a minimum set of tasks for each activity,
although additional tasks may be added to any activity.

1012-1998: IEEE Standard for Software Verification and Validation

The purpose of this standard is to:
1. Establish a common framework for V&V processes, activities, and tasks in support
of all software life cycle processes, including acquisition, supply, development,
operation, and maintenance processes.
2. Define the V&V tasks, required inputs, and required outputs
3. Identify the minimum V&V tasks corresponding to software integrity levels using a
four-level scheme
4. Define the content of a software V&V Plan (SVVP)

1012a-1998: IEEE Standard for Software Verification and Validation (Supplement to 1012-1998 –
Content Map to IEEE 12207.1)
The 2 requirements (1012 and 12207.1) place requirements on plans for verification of software
and validation of software. The purpose of this annex is to explain the relationship between the two sets of
requirements, so that users producing documents intended to comply with both standards may do so.

1016-1998: IEEE Recommended Practice for Software Design Descriptions

This is a recommended practice for describing software designs. It specifies the necessary
information content, and recommended organization for a Software Design Description (SDD). An SDD
is a representation of a software system that is used as a medium for communicating software design
information.

1028-1997: IEEE Standard for Software Reviews

The purpose of this standard is to define systematic reviews applicable to software acquisition,
supply, development, operation, and maintenance. This standard describes how to carry out a review.
Other standards or local management define the context within which a review is performed, and the use
made of the results of the review. Software reviews can be used in support of the objectives of project
management, system engineering, verification and validation, configuration management, and QA.
Different types of reviews reflect differences in the goals of each review type. Systematic reviews are
described by their defined procedures, scope, and objectives.
1044-1993: IEEE Standard Classification for Software Anomalies (ANSI)
(Anomaly: any condition that departs from the expected. The expectation can come from
documentation or someone’s perceptions or experiences). The methodology of this standard is based on a
process (sequence of steps) that pursues a logical progression from the initial recognition of an anomaly
to its final disposition. Each step interrelates with and supports the other steps.

1045-1992: IEEE Standard for Software Productivity Metrics (ANSI)

This standard describes the data collection process and calculations for measuring software
productivity.

1058-1998: IEEE Standard for Software Project Management Plans

This standard prescribes the format and content of Software Project Management Plans (SPMPs).
An SPMP is the controlling document for managing a software project; it defines the technical and
managerial processes necessary to develop software work products that satisfy the product requirements.

1058.1-1987(R1993): IEEE Standard for Software Project Management Plans (ANSI)

Explains the relationship between 1058 standard and 12207.1 standard, so that users producing
documents intended to comply with both standards may do so.

1061-1998: IEEE Standard for Software Quality Metrics Methodology

Scope: Provides a methodology for establishing quality requirements and identifying,
implementing, analyzing, and validating process and product software quality metrics. This methodology
applies to all software at all phases of any software life cycle.

Framework: Software Quality is the degree to which Software possesses a desired combination of
quality attributes. The purpose of Software Metrics is to make assessments throughout the Software Life
cycle as to whether the Software Quality requirements are being met. The use of software metrics reduces
subjectivity in the assessment and control of software quality by providing a quantitative basis for making
decisions about software quality. However the use of Software Metrics does not eliminate the need for
human judgment in Software assessments. The use of software metrics within an organization or project
is expected to have a beneficial effect by making software quality more visible.
 Other External Standards

The use of standards simplifies communication, promotes consistency and uniformity, and eliminates the
need to invent yet another (often different and even incompatible) solution to the same problem.
Standards, whether ‘official’ or merely agreed upon, are especially important when we’re talking to
customers and suppliers, but it’s easy to underestimate their importance when dealing with different
departments and disciplines within an organization. They also provide vital continuity so that we are
within our own organization. They also provide vital continuity so that we are not forever reinventing the
wheel. They are a way of preserving proven practices above and beyond the inevitable staff changes
within organizations.
Some standards are particularly important to the testing practitioner. They can provide a
benchmark for writing documents like requirements, so that testers and others doing verification have a
framework for what they can expect to find. More specifically, standards tell us what to put into key test
documents, such as a test plan.
Standards are not only practical from the development point of view, but they are increasingly the
basis for contracts and therefore also, when things go wrong, for litigation. One of the issues that arise in
litigation is whether the software was developed according to known standards that are prevalent in the
industry today. This means we need to know not only what the standards are, but to also see that they are
applied.

ISO – International Organization for Standards

ISO 9000: addresses the quality management system of an organization.
ISO 9001: the base international standard for quality management
ISO 9000-3: Guidebook on how ISO 9000 applies to software.
TickIt: UK scheme for certifying organizations producing software according to ISO 9001.

SPICE –Software Process Improvement and Capability Determination

WG10: Software Process Assessment working group for the ISO. SPICE was created to develop a suite
of related standards and guidebooks. The purpose is to create a consistent standard for software process
assessment that can be used by different nations and different sectors. The SEI (Software Engineering
Institute) has worked closely with this group, including providing the CMM (Capability Maturity Model)
as input to the effort.

NIST – National Institute of Standards and Technology

A non-regulatory federal agency within the Commerce Department’s Technology Administration. NIST's
mission is to promote economic growth by working with industry to develop and apply technology,
measurements, and standards. NIST carries out its mission through four interwoven programs: NIST
Laboratories, Baldrige National Quality Program, Manufacturing Extension Partnership, and Advanced
Technology Program. NIST programs are helping improve the quality and capabilities of software used
by businesses, research institutions, and consumers. As a result of our programs (described below), many
software packages are more efficient and can exchange data with each other. More info at:
http://www.nist.gov/

DoD – Department of Defense

As the DoD Executive Agent for Information Standards, CFS (Center for Standards) influences, adopts,
develops, promulgates, and maintains standards for OSD, CINCs, Services, Agencies and the
international defense community. CFS leads DoD's IT standards activities, performs interoperability
assessments, and facilitates the interoperability of customer IT systems.
GOALS
ƒ Identify, consolidate, and coordinate requirements for information technology standards.
ƒ Advocate DoD requirements in standards bodies to permit DoD adoption of commercial standards
versus development of military standards.
ƒ Actively pursue forming partnerships with technology providers to promote timely delivery of
products supporting approved standards.
ƒ Develop a framework and provide guidance for applying information technology standards
through updating and publishing the Joint Technical Architecture (JTA).
ƒ Automate processes to the greatest extent possible in all standardization efforts to expedite
development and coordination of standards and guidance.
ƒ Facilitate their use by program managers and engineers.