Difference between revisions of "Key Standards"
| Line 83: | Line 83: | ||
<h3>IEEE Std 730: Software Quality Assurance Plans</h3> | <h3>IEEE Std 730: Software Quality Assurance Plans</h3> | ||
<p>'''Abstract:''' The standard specifies the format and content of software quality-assurance plans. It meets the IEEE/EIA 12207.1 requirements for such plans.</p> | <p>'''Abstract:''' The standard specifies the format and content of software quality-assurance plans. It meets the IEEE/EIA 12207.1 requirements for such plans.</p> | ||
| − | <p>The SQA plan defines the means to ensure that software developed for a specific product satisfies user requirements and is of the highest quality possible within project constraints. To do so, it must first ensure that the quality target is clearly defined and understood. It must consider management, development, and maintenance plans for the software. | + | <p>The SQA plan defines the means to ensure that software developed for a specific product satisfies user requirements and is of the highest quality possible within project constraints. To do so, it must first ensure that the quality target is clearly defined and understood. It must consider management, development, and maintenance plans for the software.</p> |
<h3>IEEE Std 828: Software Configuration Management</h3> | <h3>IEEE Std 828: Software Configuration Management</h3> | ||
<p>'''Abstract:''' This standard explains CM, including identifying and acquiring configuration items, controlling changes, reporting the status of configuration items, as well as software builds and release engineering. It addresses what CM activities are to be done, when they are to happen in the lifecycle, and what planning and resources are required. It also describes the content areas for a CM plan. The standard supports ISO/IEC/IEEE 12207:2008 and ISO/IEC/IEEE 15288:2008 and adheres to the terminology in ISO/IEC/IEEE Std 24765 and the information item requirements of IEEE Std 15939.</p> | <p>'''Abstract:''' This standard explains CM, including identifying and acquiring configuration items, controlling changes, reporting the status of configuration items, as well as software builds and release engineering. It addresses what CM activities are to be done, when they are to happen in the lifecycle, and what planning and resources are required. It also describes the content areas for a CM plan. The standard supports ISO/IEC/IEEE 12207:2008 and ISO/IEC/IEEE 15288:2008 and adheres to the terminology in ISO/IEC/IEEE Std 24765 and the information item requirements of IEEE Std 15939.</p> | ||
| Line 118: | Line 118: | ||
<h2>References</h2> | <h2>References</h2> | ||
<div id="One"></div><p>[1] This set is available from IEEE on the ''Essentials'' CD. </p> | <div id="One"></div><p>[1] This set is available from IEEE on the ''Essentials'' CD. </p> | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Latest revision as of 02:33, 23 December 2017
|
Contents
- 1 Purpose of this Standards Guide
- 2 Short Descriptions of a Sampling of the Standards
- 2.1 IEEE Std 730: Software Quality Assurance Plans
- 2.2 IEEE Std 828: Software Configuration Management
- 2.3 IEEE Std 1012: System and Software Verification and Validation
- 2.4 IEEE Std 1016: Software Design Descriptions
- 2.5 IEEE Std 1028: Software Reviews and Audits
- 2.6 IEEE Std 1044: Classification for Software Anomalies
- 2.7 IEEE Std 1058/ISO/IEC/IEEE 16326: Software Project Management
- 2.8 IEEE Std 1062: Software Acquisition
- 2.9 IEEE Std 1074: Developing a Software Project Life-cycle Process [Inactive]
- 2.10 IEEE Std 12207: Systems and Software Engineering—Software Life-cycle Processes
- 2.11 IEEE Std 14764: Standard for Software Engineering—Software Lifecycle Processes—Maintenance
- 2.12 ISO/IEC/IEEE Std 15288: Systems and Software Engineering—Software Life-cycle Processes
- 2.13 ISO/IEC/IEEE 29148: Systems and software engineering—Lifecycle processes—Requirements engineering
- 2.14 IEEE Software Engineering Body of Knowledge (SWEBOK)
- 3 References
1 Purpose of this Standards Guide
This standards guide is designed for software producers, as well as producers of systems with embedded software. The purpose of this guide is to help informatics practitioners ensure that developed and deployed systems and software have the following characteristics:
- They can be and are verified and validated.
- They meet the purpose for which they are intended.
- They are robust, reliable, and resilient enough to consistently perform to their intended use.
IEEE system and software engineering standards are as critical to industry as they have been to space exploration. This guide introduces you to the core subset of the Software and Systems Engineering Standards Committee (S2ESC) portfolio of standards.
1.1 Value of System and Software Standards to Industry
The aggressive transition to technology-based information is successful only if software and software-intensive systems—which encompass myriad products and processes in complex ways—seamlessly collect, aggregate, share, analyze, and present dynamic information in a timely manner.
For example, the anticipated human and economic benefits from the present rapid transition to health information technologies demand that software and systems developers of medical devices, digital medical records, and administrative, financial, and regulatory systems (e.g., public health, service/healthcare providers, and payers) design, develop, and deliver interoperable products, processes, and services that are safe, secure, reliable, and robust.
The application of IEEE standards helps software producers by simplifying product development processes, avoiding the pitfalls that have overcome many software projects, and thus reduces non-value-adding efforts and costs. Adoption and implementation of the core software and systems engineering standards across companies that produce or tailor information systems and devices increases their development organization's ability to deliver robust software in shorter time frames. Even more important, the consistent use of these IEEE standards lowers the risks of delivering faulty products.
Standards for software and systems engineering encompasses the full software and systems lifecycles, from concept and development to delivery and maintenance, and even the reuse of software components.
1.2 Standards Essential to Informatics Technology Producers
Ensuring that delivered software meets its purpose and consistently performs to its intended use is vital to effective information delivery. As fundamental building blocks for international systems and software development, IEEE software and systems engineering standards helps producers ensure interconnectivity, interoperability, and verification of new informatics products and systems enabling the rapid implementation and trusted use of medical technologies.
The essential set [1] of IEEE standards that are key to the development and delivery of robust software and systems are listed in the table below.
| Number | Official Designation | Name |
|---|---|---|
| 730 | IEEE Std 730 | IEEE Standard for Software Quality Assurance Plans |
| 828 | IEEE Std 828 | IEEE Standard for Software Configuration Management |
| 830 | IEEE Std 830 | IEEE Recommended Practice for Software Requirements Specifications. This standard was contributed to ISO and is now replaced by ISO/IEC/IEEE 29148. |
| 1008 | IEEE Std 1008 | IEEE Standard for Software Unit Testing. This standard was contributed to ISO and is now replaced by ISO/IEC/IEEE 29119-4. |
| 1012 | IEEE Std 1012 | IEEE Standard for System and Software Verification and Validation |
| 1016 | IEEE Std 1016 | IEEE Recommended Practice for Software Design Descriptions |
| 1028 | IEEE Std 1028 | IEEE Standard for Software Reviews and Audits |
| 1058 | IEEE Std 1058 | IEEE Standard for Software Project Management Plans. This standard is inactive, but contributed to ISO/IEC/16326. |
| 1063 | IEEE Std 1063 | IEEE Standard for Software User Documentation. This standard was contributed to ISO and is now superseded by ISO/IEC/IEEE 26514 Systems and Software Engineering—Requirements for designers and developers of user documentation. |
| 1074 | IEEE Std 1074 | IEEE Standard for Developing a Software Project Life-cycle Process. This standard was contributed to ISO. It has not been superseded, but ISO/IEC/IEEE 24774 presents guidelines for the elements used most frequently in describing a process: the title, purpose, outcomes, activities, task and information item |
| 12207 | ISO/IEC/IEEE 12207 | Systems and Software Engineering—life-cycle processes |
| 14764 | IEEE Std 14764 | Software Engineering—System Life-cycle Processes—Maintenance |
| 15288 | ISO/IEC/IEEE 15288 | Systems and Software Engineering—Systems life-cycle processes |
| 12207 | ISO/IEC/IEEE 20000-1 | Information Technology—Service management—Part 1: Service Management System requirements |
Additional important standards are listed in the table below.
| Number | Official Designation | Name |
|---|---|---|
| 829 | IEEE Std 829 | IEEE Standard for Software and System Test Documentation was contributed to ISO and is superseded by ISO/IEC/IEEE 29119-3 |
| 1044 | IEEE Std 1044 | IEEE Standard Classification for Software Anomalies |
| 1062 | IEEE Std 1062 | IEEE Recommended Practice for Software Acquisition |
| 1233 | IEEE Std 1233 | IEEE Guide for Developing System Requirements Specifications was contributed to ISO and is superseded by ISO/IEC/IEEE 29148 |
| 1362 | IEEE Std 1362 | IEEE Guide for Information Technology-System Definition-Concept of Operations (ConOps) Document was contributed to ISO and superseded by ISO/IEC/IEEE 29148 |
| 15939 | ISO/IEC/IEEE Std 15939 | Systems and Software Engineering—Measurement Process |
2 Short Descriptions of a Sampling of the Standards
Note that many EIT-relevant standards can be downloaded for free at http://standards.iso.org/ittf/PubliclyAvailableStandards.
2.1 IEEE Std 730: Software Quality Assurance Plans
Abstract: The standard specifies the format and content of software quality-assurance plans. It meets the IEEE/EIA 12207.1 requirements for such plans.
The SQA plan defines the means to ensure that software developed for a specific product satisfies user requirements and is of the highest quality possible within project constraints. To do so, it must first ensure that the quality target is clearly defined and understood. It must consider management, development, and maintenance plans for the software.
2.2 IEEE Std 828: Software Configuration Management
Abstract: This standard explains CM, including identifying and acquiring configuration items, controlling changes, reporting the status of configuration items, as well as software builds and release engineering. It addresses what CM activities are to be done, when they are to happen in the lifecycle, and what planning and resources are required. It also describes the content areas for a CM plan. The standard supports ISO/IEC/IEEE 12207:2008 and ISO/IEC/IEEE 15288:2008 and adheres to the terminology in ISO/IEC/IEEE Std 24765 and the information item requirements of IEEE Std 15939.
2.3 IEEE Std 1012: System and Software Verification and Validation
Abstract: Software verification and validation (V&V) processes determine whether the development products of a given activity conform to the requirements of that activity and whether the software satisfies its intended use and user needs. Software V&V lifecycle process requirements are specified for different software integrity levels. The scope of V&V processes encompasses software-based systems, computer software, hardware, and interfaces. This standard applies to software being developed, maintained, or reused (legacy, commercial off-the-shelf (COTS), non-developmental items). The term software also includes firmware, microcode, and documentation. Software V&V processes include analysis, evaluation, review, inspection, assessment, and testing of software products.
2.4 IEEE Std 1016: Software Design Descriptions
Abstract: The necessary information content and recommendations for an organization for software design descriptions (SDDs) are described. An SDD is a representation of a software system that is used as a medium for communicating software design information. This recommended practice is applicable to paper documents, automated databases, design description languages, and other means of description.
2.5 IEEE Std 1028: Software Reviews and Audits
Abstract: Five types of software reviews and audits, together with procedures required for the execution of each type, are defined in this standard. This standard is concerned only with the reviews and audits; procedures for determining the necessity of a review or audit are not defined, and the disposition of the results of the review or audit is not specified. Types included are management reviews, technical reviews, inspections, walk-throughs, and audits.
2.6 IEEE Std 1044: Classification for Software Anomalies
Abstract: A uniform approach to the classification of anomalies found in software and its documentation is provided. The processing of anomalies discovered during any software lifecycle phase are described, and comprehensive lists of software anomaly classifications and related data items that are helpful to identify and track anomalies are provided. This standard is not intended to define procedural or format requirements for using the classification scheme. It identifies some classification measures but does not attempt to define all the data supporting the analysis of an anomaly.
2.7 IEEE Std 1058/ISO/IEC/IEEE 16326: Software Project Management
Abstract: This international standard specifies the required content of the project management plan (PMP). It also quotes the extracted purpose and outcome statements from the project processes of ISO/IEC 12207:2008 (IEEE Std 12207-2008) and ISO/IEC 15288:2008 (IEEE Std 15288-2008), and adds detailed guidance for managing projects that use these processes for software products and software-intensive systems.
2.8 IEEE Std 1062: Software Acquisition
Abstract: This standard provides a set of useful quality practices for use during one or more steps in a software acquisition process. This recommended practice can be applied to software that runs on any computer system regardless of the size, complexity, or criticality of the software, but is more suited for use on modified-off-the-shelf software and fully developed software.
2.9 IEEE Std 1074: Developing a Software Project Life-cycle Process [Inactive]
Abstract: This standard provides a process for creating a software project lifecycle process (SPLCP). It is primarily directed at the process architect for a given software project. IEEE Std 1074 is unique in that it specifies, for any activity, what inputs are needed from previous activities, so that activities can be chained together. It also provides activities for ensuring that security is built in throughout the software lifecycle.
This standard requires selection of a user's software project lifecycle model (SPLCM) based on the organization's mission, vision, goals, and resources. It does not impose, define, or imply a particular software lifecycle model or methodology.
This standard may also be used to develop organizational processes to support software development and maintenance or to develop special, single-function processes within a project.
2.10 IEEE Std 12207: Systems and Software Engineering—Software Life-cycle Processes
Abstract: This international standard establishes a common framework for software lifecycle processes, with well-defined terminology, that can be referenced by the software industry. It applies to the acquisition of systems and software products and services, to the supply, development, operation, maintenance, and disposal of software products and the software portion of a system, whether performed internally or externally to an organization. Those aspects of system definition needed to provide the context for software products and services are included. Software includes the software portion of firmware. This revision integrates ISO/IEC 12207 with its two amendments and was coordinated with the parallel revision of ISO/IEC 15288 (system lifecycle processes) to align structure, terms, and corresponding organizational and project processes. This standard may be used stand alone or jointly with ISO/IEC 15288, and supplies a process reference model that supports process capability assessment in accordance with ISO/IEC 15504-2 (process assessment).
2.11 IEEE Std 14764: Standard for Software Engineering—Software Lifecycle Processes—Maintenance
Abstract: The process for managing and executing software maintenance activities is described.
IEEE Std 14764 describes in greater detail the management of the maintenance process described in IEEE Std 12207, including amendments. It also establishes definitions for the various types of maintenance. IEEE Std 14764 provides guidance that applies to planning, execution and control, review and evaluation, and closure of the maintenance process. The scope includes maintenance for multiple software products with the same maintenance resources.
IEEE Std 14764 provides guidance for the maintenance of software. The basis for the maintenance process and its activities comes from the definitions of IEEE Std 12207. It defines the activities and tasks of software maintenance, and provides maintenance planning requirements. It does not address the operation of software and the operational functions, such as backup, recovery, and system administration.
2.12 ISO/IEC/IEEE Std 15288: Systems and Software Engineering—Software Life-cycle Processes
Abstract: This international standard establishes a common process framework for describing the lifecycle of man-made systems. It defines a set of processes and associated terminology for the full lifecycle, including conception, development, production, utilization, support, and retirement. This standard also supports the definition, control, assessment, and improvement of these processes. These processes can be applied concurrently, iteratively, and recursively to a system and its elements throughout the lifecycle of a system.
2.13 ISO/IEC/IEEE 29148: Systems and software engineering—Lifecycle processes—Requirements engineering
Abstract: This standard replaces IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998. ISO/IEC/IEEE 29148:2011 contains provisions for the processes and products related to the engineering of requirements for systems and software products and services throughout the lifecycle. It defines the construct of a good requirement, provides attributes and characteristics of requirements, and discusses the iterative and recursive application of requirements processes throughout the lifecycle.
2.14 IEEE Software Engineering Body of Knowledge (SWEBOK)
In this Guide, the IEEE Computer Society establishes for the first time a baseline for the body of knowledge for the field of software engineering, and the work partially fulfills the society's responsibility to promote the advancement of both theory and practice in this field.
It should be noted that this Guide does not purport to define the body of knowledge, but rather to serve as a compendium and guide to the evolving body of knowledge that continues to develop.
The body of knowledge is subdivided into ten software engineering knowledge areas (KAs) plus an additional chapter providing an overview of the KAs of strongly related disciplines.
3 References
[1] This set is available from IEEE on the Essentials CD.
