IEEE Software Engineering Standards
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.
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.
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
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.
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.
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)
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.
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.
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.
(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.
This standard describes the data collection process and calculations for measuring software productivity.
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.
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.
Other External Standards
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 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.
