Difference between revisions of "Key Standards"

Revision as of 01:16, 10 June 2016

Note: This wiki is a work in progress, and may contain missing content, errors, or duplication.

1 Purpose of This Standards Guide

This 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 S2ESC’s portfolio of standards.

1.1 The 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 S2ESC systems and software 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 encompass the full software and systems life cycles, 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 help 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 System and Software Standards that are key to the development and delivery of robust software and systems are listed in the table below.

Table 1. Essential Standards

Table 2. Additional Important Standards

2 Short Descriptions of a Sampling of the Standards

Please 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 the user’s 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.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 life cycle, 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 life-cycle 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, or 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 life-cycle 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 does identify some classification measures and 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 life-cycle 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 life cycle.

This standard requires selection of a user’s software project life-cycle model (SPLCM) based on the organization’s mission, vision, goals, and resources. It does not impose, define, or imply a particular software life-cycle 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 life-cycle 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 life-cycle 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 Life Cycle Processes — Maintenance

Abstract: The process for managing and executing software maintenance activities is described.

IEEE Std 14764 describes in greater detail 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 life cycle of man-made systems. It defines a set of processes and associated terminology for the full life cycle, 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 life cycle of a system.

2.13 ISO/IEC/IEEE 29148: Systems and software engineering — Life cycle 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 life cycle. 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 life cycle.

2.14 The 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.

[2] Guide to SWEBOK 2004. 2.1.

[3] Guide to SWEBOK 2004. 2.1.1.

[4] Guide to SWEBOK 2004. 5.2.2.

[5] Guide to SWEBOK 2004. 5.2.1.

[6] Guide to SWEBOK 2004. Foreword.

[7] Guide to SWEBOK 2004. Preface.