Difference between revisions of "Key Standards"

Revision as of 00:31, 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 the Standards

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 829: Software and System Test Documentation

Abstract: Test processes determine whether the development products of a given activity conform to the requirements of that activity and whether the system and software satisfies its intended use and user needs. Testing process tasks are specified for different integrity levels. These process tasks determine the appropriate breadth and depth of test documentation. The documentation elements for each type of test documentation can then be selected. The scope of testing encompasses software-based systems, computer software, hardware, and their interfaces. This standard applies to software-based systems being developed, maintained, or reused (legacy, commercial off-the-shelf, non-developmental items). The term “software” also includes firmware, microcode, and documentation. Test processes can include inspection, analysis, demonstration, verification, and validation of software and software-based system products.

2.4 IEEE Std 830: Software Requirements Specifications

Abstract: The content and qualities of a good software requirements specification (SRS) are described and several sample SRS outlines are presented. This recommended practice is aimed at specifying requirements of software to be developed but also can be applied to assist in the selection of in-house and commercial software products. It is very useful for development teams to use as a checklist to remember all the different types of requirements (functional, derived, operational, quality, etc.) that must be provided to the development team.

2.5 IEEE Std 1008: Software Unit Testing

Unit testing verifies the functioning in isolation of software pieces that are separately testable. Depending on the context, these could be the individual subprograms or a larger component made of tightly related units. A test unit is defined more precisely in the IEEE Standard for Software Unit Testing (IEEE1008-87), which also describes an integrated approach to systematic and documented unit testing. Typically, unit testing occurs with access to the code being tested and with the support of debugging tools, and might involve the programmers who wrote the code. [3] Test cases should be under the control of software configuration management and include the expected results for each test. [4]

Key aspects of test planning include coordination of personnel, management of available test facilities and equipment (which may include magnetic media, test plans, and procedures), and planning for possible undesirable outcomes. If more than one baseline of the software is being maintained, then a major planning consideration is the time and effort needed to ensure that the test environment is set to the proper configuration. [5]

2.6 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.7 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.8 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.9 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.10 IEEE Std 1058: Software Project Management Plans

Abstract: The format and contents of software project management plans, applicable to any type or size of software project, are described. The elements that should appear in all software project management plans are identified. This standard has recently been merged into ISO/IEC 16326.

2.11 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.12 IEEE Std 1063: Software User Documentation

Abstract: This standard provides the minimum requirements for the structure, information content, and format of user documentation, including both printed and electronic documents used in the work environment by users of systems containing software.

2.13 IEEE Std 1074: Developing a Software Project Life-cycle Process

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 provides activities for ensuring building in security throughout the software life cycle.

IEEE Std 1074 is a standard for establishing the process to be used in a software development, maintenance, or other type of software project, including disposal/withdrawal of the product. This standard requires selection of a user’s software project life-cycle model (SPLCM) based on the organization’s mission, vision, goals, and resources. EIT does not impose, define, or imply a particular software life-cycle model or methodology. This standard describes the individual activities that are to be used within the selected model and provides examples of mapping them onto typical SPLCMs.

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.14 IEEE Std 1233: Developing System Requirements Specifications

Abstract: This standard provides guidance for the development of the set of requirements, system requirements specification (SyRS), to satisfy an expressed need. Developing an SyRS includes the identification, organization, presentation, and modification of the requirements. Also addressed are the conditions for incorporating operational concepts, design constraints, and design configuration requirements into the specification. This guide also covers the necessary characteristics and qualities of individual requirements and the set of all requirements.

2.15 IEEE Std 1362: Information Technology — System Definition — Concept of Operations (ConOps) Document

Abstract: The format and contents of a concept of operations (ConOps) document are described. A ConOps is a user-oriented document that describes system characteristics for a proposed system from the users’ viewpoint. The ConOps document is used to communicate overall quantitative and qualitative system characteristics to the user, buyer, developer, and other organizational elements (for example, training, facilities, staffing, and maintenance). It is used to describe the user organizations, missions, and organizational objectives from an integrated systems point of view.

2.16 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). An annex provides support for IEEE users and describes relationships of this international standard to IEEE standards.

2.17 IEEE Std 14143.1: Information technology — software measurement — functional size measurement. Part 1: definition of concepts

Abstract: This standard defines the concepts of functional size measurement (FSM). The concepts of FSM are designed to overcome the limitations of earlier methods of sizing software by shifting the focus away from measuring how the software is implemented to measuring size in terms of the functions required by the user.

2.18 IEEE Std 14764: Software Engineering — System 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. In IEEE Std 14764, maintenance means software maintenance unless otherwise stated.

IEEE Std 14764 provides the framework within which generic and specific software maintenance plans may be executed, evaluated, and tailored to the maintenance scope and magnitude of given software products. It provides the framework, precise terminology, and processes to allow the consistent application of technology (tools, techniques, and methods) to software maintenance.

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, which are normally performed by those who operate the software.

IEEE Std 14764 is written primarily for maintainers of software and additionally for those responsible for development and quality assurance. It may also be used by acquirers and users of systems containing software who may provide inputs to the maintenance plan.

2.19 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.20 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. In so doing, the Society has been guided by the experience of disciplines with longer histories but was not bound either by their problems or their solutions.

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 body of knowledge that has been developing and evolving over the past four decades. Furthermore, this body of knowledge is not static. The guide must, necessarily, develop and evolve as software engineering matures. Nevertheless, it constitutes a valuable element of the software engineering infrastructure. [6]

The purpose of the Guide to the Software Engineering Body of Knowledge is to provide a consensually validated characterization of the bounds of the software engineering discipline and to provide a topical access to the body of knowledge supporting that discipline. 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. The descriptions of the KAs are designed to discriminate among the various important concepts, permitting readers to find their way quickly to subjects of interest. Upon finding a subject, readers are referred to key papers or book chapters selected because they succinctly present the knowledge.

This guide is oriented toward a variety of audiences, all over the world. It serves public and private organizations in need of a consistent view of software engineering for defining education and training requirements, classifying jobs, developing performance evaluation policies, or specifying software development tasks. It also addresses practicing, or managing, software engineers and the officials responsible for making public policy regarding licensing and professional guidelines. In addition, professional societies and educators defining the certification rules, accreditation policies for university curricula, and guidelines for professional practice benefit from SWEBOK, as well as the students learning the software engineering profession and educators and trainers engaged in defining curricula and course content. [7]

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.