Configuration Management and Software Engineering Standards Reference

OVERVIEW

Software engineering (i.e., development) consists of many components : definitions, documentation, testing, quality assurance, metrics, and configuration management (CM). Standards bodies have crafted standards for many of these.

Standards enable software developers to develop quality-oriented, cost-effective , and maintainable software in an efficient, cost-productive manner. The goal of each standard is to provide the software developer with a set of benchmarks, enabling him or her to complete the task and be assured that it meets at least a minimum level of quality. Indeed, the dictionary definition of standard is " an acknowledged measure of comparison for quantitative or qualitative value; a criterion. " Thus, standards provide the developer with the criteria necessary to build a system.

The Software Engineering Institute's (http://www.sei.cmu.edu/cmm/cmms/cmms.html) Capability Maturity Model (CMM), although not usually considered a standard in the strict definition of the word, is still a valid benchmark that organizations use to ensure that they are adhering to a robust quality software engineering set of processes. Configuration management (CM) is very much a factor in the CMM.

Paulk et al. [1995] have correlated CM and CMM. From a CMM perspective, software configuration management (SCM) should consist of the following goals, commitments, abilities , activities, measurements, and verifications:

  1. SCM activities are planned.

  2. Selected software work products are identified, controlled, and available.

  3. Changes to identified software work products are controlled.

  4. Affected groups and individuals are informed of the status and content of software baselines.

The commitment is that the project follows a written organizational policy for implementing SCM. The abilities consist of:

  1. A board having the authority for managing the project's software baselines exists or is established.

  2. A group that is responsible for coordinating and implementing SCM for the project exists.

  3. Adequate resources and funding are provided for performing the SCM activities.

  4. Members of the SCM group are trained in the objectives, procedures, and methods for performing their SCM activities.

The activities include:

  1. An SCM plan is prepared for each software project according to a documented procedure.

  2. A documented and approved SCM plan is used as the basis for performing the SCM activities.

  3. A configuration management library system is established as a repository for the software baselines.

  4. The software work products to be placed under configuration management are identified.

  5. Change requests and problem reports for all configuration items/units are initiated, recorded, reviewed, approved, and tracked according to a documented procedure.

  6. Changes to baselines are controlled according to a documented procedure.

  7. Products from the software baseline library are created, and their release is controlled according to a documented procedure.

  8. The status of configuration items/units is recorded according to a documented procedure.

  9. Standard reports documenting the SCM activities and the contents of the software baseline are developed and made available to affected groups and individuals.

  10. Software baseline audits are conducted according to a documented procedure.

Measurements are made and used to determine the status of the SCM activities. The verifications include:

  1. SCM activities are reviewed with senior management on a periodic basis.

  2. SCM activities are reviewed with the project manager on both a periodic and event-driven basis.

  3. The SCM group periodically audits software baselines to verify that they conform to the documentation that defines them.

  4. The software quality assurance group reviews and/or audits the activities and work products for SCM and reports the results.

THE STANDARDS BODIES

The three most significant industry standards bodies are ANSI, IEEE, and ISO. The EIA (Electronic Industries Alliance) has also played a significant role by creating EIA-649, the National Consensus Standard for Configuration Management. Most recently, EIA-836 has come to the forefront of CM standards. Essentially , EIA-836 is an extension of EIA-649. It provides a fundamental reference vocabulary for the access, sharing, and exchange of CM data (including product configuration information), and for developing, mapping, and using CM-enabled tools, systems, and databases using XML (eXtensible Markup Language). Figure 12.1 shows the relationship between these two standards.

Figure 12.1: XML

As one can see, the primary focus of EIA-836 is on data element definitions, relationships, and business objects for information exchange. The body of EIA-836 essentially consists of CM Business Objects, the CM Data Dictionary, and CM Reference Schemas. The Business Objects and Reference Schemas are annotated with data element definitions. Annexes to the standard contain user guidance and several informative crossreference tables.

The EIA-836 standard (version 1.0) is comprised of six parts , each contained in a Zip file:

  1. EIA836-1.0 Standard Body Zip file

  2. EIA836-1.0 Data Dictionary Zip file

  3. EIA836-1.0 Reference Schema Zip file

  4. EIA836-1.0 Live DTD Zip file

  5. EIA836-1.0 Schema Diagrams Zip file

  6. EIA836-1.0 User Views Zip file

and can be downloaded from http://www.dcnicn.com/cm/index.cfm.

MIL-STD-2549, Configuration Management Data Interface (http://wwwedms.redstone.army.mil/edrd/ms2549.pdf), might also be of interest to the reader.

A SUMMARY OF THE EIA STANDARD (EIA 649)

EIA-649 [EIA 1998] was developed in 1994 and rapidly became the pivotal standard around which most other standards bodies rallied. EAI-649 is addressed more comprehensively in other sections of this book; however, its principles are summarized here:

Configuration Management Planning and Management

  1. Plan CM processes for the context and environment in which they are to be preformed and manage in accordance with the planning: assign responsibilities, train personnel, measure performance, and assess measurements/trends to effect process improvements.

  2. To determine the specific CM value-adding functions and levels of emphasis for a particular product, identify the context and environment in which to implement CM.

  3. A configuration management plan describes how CM is accomplished and how consistency between the product definition, the product's configuration, and the configuration management records is achieved and maintained throughout the applicable phases of the product's life cycle.

  4. Prepare procedures to define how each configuration management process will be accomplished.

  5. Conduct training so that all responsible individuals understand their roles and responsibilities as well as the procedures for implementing configuration management processes.

  6. Assess the effectiveness of CM plan implementation and performance of the configuration management discipline with defined metrics (performance indicators).

  7. Performing configuration management includes responsibility for the configuration management subordinate activities (e.g., subcontractors , suppliers).

Configuration Identification

  1. Configuration identification is the basis on which the configuration of products are defined and verified ; products and documents are labeled; changes are managed; and accountability is maintained.

  2. Configuration documentation defines the functional, performance, and physical attributes of a product. Other product information is derived from configuration documentation.

  3. The product composition (i.e., relationship and quantity of parts that comprise the product) is determined from its configuration documentation.

  4. All products are assigned unique identifiers so that one product can be distinguished from other products; one configuration of a product can be distinguished from other; the source of a product can be determined; and the correct product information can be retrieved.

  5. Individual units of a product are assigned unique product identifiers when there is a need to distinguish one unit of a product from another unit of the product.

  6. When a product is modified, it retains its original product unit identifier although its part identifying number is altered to reflect a new configuration.

  7. A series of like units of a product is assigned a unique product group identifier when it is unnecessary or impractical to identify individual units but nonetheless necessary to correlate units to a process, date, event, or test.

  8. All documents reflecting product performance, functional, or physical requirements and other product information are uniquely identified so that they can be correctly associated with the applicable configuration of the product.

  9. A baseline identifies an agreed-to description of the attributes of a product at a point in time and provides a known configuration to which changes are addressed.

  10. Baselines are established by agreeing to the stated definition of a product's attributes.

  11. The configuration of any product, or any document, plus the approved changes to be incorporated constitute the current baseline.

  12. Maintaining product information is important because time-consuming and expensive recovery may be necessary if records of operational units of a product do not match the actual units (as reported by maintenance activities) or such records do not exist.

  13. For product interfaces external to the enterprise, establish an interface agreement and mutually agreed-to documentation of common attributes.

  14. Changes to a product are accomplished using a systematic, measurable change process.

Configuration Change Management

  1. Each change is uniquely identified.

  2. Changes represent opportunities for improvement.

  3. Classify requested changes to aid in determining the appropriate levels of review and approval.

  4. Change requests must be clearly documented.

  5. Consider the technical, support, schedule, and cost impacts of a requested change before making a judgment as to whether the change should be approved for implementation and incorporation in the product and its documentation.

  6. Determine all potential effects of a change and coordinate potential impacts with the impacted areas of responsibility.

  7. Change documentation delineates which unit(s) of the product are to be changed. Change effectivity includes both production break-in and retrofit/recall, as applicable.

  8. A changed product should not be distributed until support and service areas are able to support it.

  9. The decision maker is aware of all cost factors in making the decision.

  10. Change approval decisions are made by an appropriate authority who can commit resources to implement the change.

  11. Implement an approved change in accordance with documented direction approved by the appropriate level of authority.

  12. Verify implementation of a change to ensure consistency between the product, its documentation, and its support elements.

  13. If it is considered necessary to temporarily depart from specified baseline requirements, a variance is documented and authorized by the appropriate level of authority.

Configuration Status Accounting

  1. An accurate, timely information base concerning a product and its associated product information is important throughout the product life cycle.

  2. Configuration information, appropriate to the product, is systematically recorded, safeguarded, validated , and disseminated.

  3. Configuration information content evolves and is captured over the product life cycle as tasks occur.

  4. Data collection and information processing system requirements are determined by the need for configuration information.

Configuration Verification and Audit

  1. Verification that a product's requirement attributes have been met and that the product design meeting those attributes has been accurately documented are required to baseline the product configuration.

  2. Verification that a design achieves its goals is accomplished by a systematic comparison of requirements with the results of tests, analyses, or inspections.

  3. Documentation of a product's definition must be complete and accurate enough to permit reproduction of the product without further design effort.

  4. Where necessary, verification is accomplished by configuration audit.

  5. Periodic reviews verify continued achievement of requirements, identify and document changes in performance, and ensure consistency with documentation.

Management of Digital Data

  1. Apply configuration management principles to ensure the integrity of digital representations of product information and other data.

  2. Apply digital data identification rules to maintain document, document representation, and file version relationships.

  3. Apply business rules using data status levels for access, change management, and archiving of digital data documents.

  4. Maintain relationships between digital data, data requirements, and the related product configuration to ensure accurate data access.

  5. Apply disciplined version control to manage document review electronically .

  6. Ensure that a transmitted digital data product is usable.

  7. Effective digital data access fulfills requirements, preserves rights, and provides users with data they are entitled to in the correct version

ANSI

The American National Standards Institute (ANSI; http://www.ansi.org), founded in 1918, is one of the oldest and most prestigious of standards bodies. ANSI is the final arbiter of national standards within the United States and is also a key member of international standards bodies such as the ISO. For the most part, ANSI focuses on standards used by the software and hardware vendors that make the products that the software engineer uses. These standards pertain to programming languages, tele-communications, and even the physical properties of devices such as diskettes, cartridges, and magnetic tapes. ANSI will often work in conjunction with cooperating standards bodies such as the IEEE. In effect, ANSI will "join forces" with another standards body to endorse a particular standard.

The acronym "ANSI" is quite familiar to most software developers, even if they know nothing about standards. The ANSI character set is used by programmers everywhere. It consists of 256 characters , the first 128 of which are ASCII ( A merican S tandard C ode for I nformation I nterchange). The remaining 128 characters are math and foreign language symbols.

IEEE

The IEEE (Institute of Electrical and Electronics Engineers; http://www.ieee.org) is a professional trade organization with close to 400,000 members in over 150 countries . More than a few computer science students join this organization for its publications , meetings, and networking opportunities. One branch of the IEEE is its standards governing body (http://standards.ieee.org/index.html).

Currently, the IEEE has more than 900 active standards, with hundreds more in development. Many of these are related to software development.

IEEE Software Engineering Standards Summary

The standards listed in Table 12.1, which include configuration standards, are outlined. Boldfaced titles indicate applicability to configuration management.

Table 12.1: IEEE Software Engineering Standards Summary

ANSI/IEEE STD 1002 “1987

IEEE Standard Taxonomy for Software Engineering Standards

ANSI/IEEE STD 1008 “1987

IEEE Standard for Software Unit Testing

IEEE STD 1012 “1986

IEEE Standard for Software Verification and Validation Plans

IEEE STD 1016 “1987

IEEE Recommended Practice for Software Design Descriptions

IEEE STD 1016.1-1993

IEEE Guide to Software Design Descriptions

IEEE STD 1028 “1988

IEEE Standard for Software Reviews and Audits

ANSI/IEEE STD 1042 “1987

IEEE Guide to Software Configuration Management

IEEE STD 1044 “1993

IEEE Standard Classification for Software Anomalies

IEEE STD 1045 “1992

IEEE Standard for Software Productivity Metrics

IEEE STD 1058.1-1987

IEEE Standard for Software Project Management Plans

IEEE STD 1059 “1993

IEEE Guide for Software Verification and Validation Plans

IEEE STD 1061 “1992

IEEE Standard for a Software Quality Metrics Methodology

IEEE STD 1062 “1993

IEEE Recommended Practice for Software Acquisition

IEEE STD 1063 “1987

IEEE Standard for Software User Documentation

IEEE STD 1074 “1991

IEEE Standard for Developing Software Life-Cycle Processes

IEEE STD 1074.1-1995

IEEE Guide for Developing Software Life-Cycle Processes

IEEE STD 1175 “1992

IEEE Trial-Use Standard Reference Model for Computing System Tool Interconnections

IEEE STD 1220 “1994

IEEE Trial-Use Standard for Application and Management of the Systems Engineering Process

IEEE/EIA 12207.0-1996

Industry Implementation of International Standard ISO/IEC: ISO/IEC12207 Standard for Information Technology Software Life-Cycle Processes

IEEE STD 1228 “1994

IEEE Standard for Software Safety Plans

IEEE STD 1298 “1992

Software Quality Management System Part 1: Requirements

IEEE STD 1362 “1998

IEEE Guide for Information Technology ” System Definition ” Concept of Operations (ConOps) Document

IEEE STD 610.12-1990

IEEE Standard Glossary of Software Engineering Terminology

IEEE STD 730 “1989

IEEE Standard for Software Quality Assurance Plans

IEEE STD 828 “1990

IEEE Standard for Software Configuration Management Plans

ANSI/IEEE STD 829 “1983

IEEE Standard for Software Test Documentation

IEEE STD 830 “1993

IEEE Recommended Practice for Software Requirements Specifications

IEEE STD 982.1-1988

IEEE Standard Dictionary of Measures to Produce Reliable Software

IEEE STD 982.2-1988

IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable Software

IEEE STD 990 “1987

IEEE Recommended Practice for Ada as a Program Design Language

J-STD-016-1995 30 September 1995

Trial Use Standard Standard for Information Technology Software Life-Cycle Processes Software Development Acquirer-Supplier Agreement

ANSI/IEEE STD 1002 “1987 IEEE Standard Taxonomy for Software Engineering Standards

Contents

  1. Introduction

    • 1.1 Scope

    • 1.2 Terminology

    • 1.3 References

  2. Definitions

  3. Taxonomy of Software Engineering Standards

    • 3.1 Standards Partition

    • 3.2 Software Engineering Partition

    • 3.3 Taxonomy Framework

ANSI/IEEE STD 1008 “1987 IEEE Standard for Software Unit Testing

Contents

  1. Scope and References

    • 1.1 Inside the Scope

    • 1.2 Outside the Scope

    • 1.3 References

  2. Definitions

  3. Unit Testing Activities

    • 3.1 Plan the General Approach, Resources, and Schedule

    • 3.2 Determine Features to Be Tested

    • 3.3 Refine the General Plan

    • 3.4 Design the Set of Tests

    • 3.5 Implement the Refined Plan and Design

    • 3.6 Execute the Test Procedures

    • 3.7 Check for Termination

    • 3.8 Evaluate the Test Effort and Unit

IEEE STD 1012 “1986 IEEE Standard for Software Verification and Validation Plans

Contents

  1. Scope and References

    • 1.1 Scope

    • 1.2 References

  2. Conventions, Definitions, and Acronyms

    • 2.1 Conventions

    • 2.2 Definitions

  3. Software Verification and Validation Plan

    • 3.1 Purpose.

    • 3.2 Referenced Documents

    • 3.3 Definitions

    • 3.4 Verification and Validation Overview

    • 3.5 Life-Cycle Verification and Validation

    • 3.6 Software Verification and Validation Reporting

    • 3.7 Verification and Validation Administrative Procedures

IEEE STD 1016 “1987 IEEE Recommended Practice for Software Design Descriptions

Contents

  1. Scope

  2. References

  3. Definitions

  4. Considerations for Producing a Software Design Description (SDD)

    • 4.1 Software Life Cycle

    • 4.2 Software Design Description (SDD) within the Life Cycle

    • 4.3 Purpose of a Software Design Description (SDD)

  5. Design Description Information Content

    • 5.1 Introduction

    • 5.2 Design Entities

    • 5.3 Design Entity Attributes

  6. Design Description Organization

    • 6.1 Introduction

    • 6.2 Design Views

IEEE STD 1016.1-1993 IEEE Guide to Software Design Descriptions

Abstract: The application of design methods and design documentation recommended in IEEE STD 1016 “1987 is described. Several common design methods are used to illustrate the application of IEEE STD 1016 “1987, thus making the concepts of that standard more concrete. The information in this guide may be applied to commercial, scientific, or military software that runs on any computer. Applicability is not restricted by the size , complexity, or criticality of the software.

Keywords: design entity, design method, design view, software design process

Contents

  1. Overview

    • 1.1 Purpose

    • 1.2 Scope

  2. References

  3. Definitions

  4. Description of IEEE STD 1016 “1987

  5. Design Description Organization

    • 5.1 Design Views

    • 5.2 Recommended Design Views

    • 5.3 Design Description Media

  6. Considerations

    • 6.1 Selecting Representative Design Methods

    • 6.2 Representative Design Method Descriptions

    • 6.3 Design Document Sections

    • 6.4 Method-Oriented Design Documents

  7. Design Methods

    • 7.1 Function-Oriented Design Methods

    • 7.2 Data-Oriented Design Methods

    • 7.3 Real-Time Control-Oriented Design Methods

    • 7.4 Object-Oriented Design Methods

    • 7.5 Formal Language-Oriented Design Methods

  8. Bibliography

IEEE STD 1028 “1988 ” Revision of Corrected Edition June 30, 1989, IEEE Standard for Software Reviews and Audits

Contents

  1. Scope and References

    • 1.1 Scope

    • 1.2 References

  2. Definitions

  3. Introduction

    • 3.1 Review Process Prerequisites

    • 3.2 Audit Process Prerequisites

    • 3.3 Procedural Description Template

  4. The Management Review Process

    • 4.1 Objective

    • 4.2 Abstract

    • 4.3 Special Responsibilities

    • 4.4 Input

    • 4.5 Entry Criteria

    • 4.6 Procedures

    • 4.7 Exit Criteria

    • 4.8 Output

    • 4.9 Auditability

  5. The Technical Review Process

    • 5.1 Objective

    • 5.2 Abstract

    • 5.3 Special Responsibilities

    • 5.4 Input

    • 5.5 Entry Criteria

    • 5.6 Procedures

    • 5.7 Exit Criteria

    • 5.8 Output

    • 5.9 Auditability

  6. The Software Inspection Process

    • 6.1 Objective

    • 6.2 Abstract

    • 6.3 Special Responsibilities

    • 6.4 Input

    • 6.5 Entry Criteria

    • 6.6 Procedures

    • 6.7 Exit Criteria

    • 6.8 Output

    • 6.9 Auditability

    • 6.10 Data Collection Requirements

  7. The Walk-Through Process

    • 7.1 Objective

    • 7.2 Abstract

    • 7.3 Special Responsibilities

    • 7.4 Input

    • 7.5 Entry Criteria

    • 7.6 Procedures

    • 7.7 Exit Criteria

    • 7.8 Output

    • 7.9 Auditability

  8. The Audit Process

    • 8.1 Objective

    • 8.2 Abstract

    • 8.3 Special Responsibilities

    • 8.4 Input

    • 8.5 Entry Criteria

    • 8.6 Procedures

    • 8.7 Exit Criteria

    • 8.8 Output

    • 8.9 Auditability

ANSI/IEEE STD 1042 “1987 IEEE Guide to Software Configuration Management

Contents

  1. Introduction

    • 1.1 Scope

    • 1.2 References

    • 1.3 Mnemonics

    • 1.4 Terms

  2. SCM Disciplines in Software Management

    • 2.1 The Context of SCM

    • 2.2 The Process of SCM

    • 2.3 The Implementation of SCM

    • 2.4 The Tools of SCM

    • 2.5 The Planning of SCM

  3. Software Configuration Management Plans

    • 3.1 Introduction

    • 3.2 Management

    • 3.3 SCM Activities

    • 3.4 Tools, Techniques, and Methodologies

    • 3.5 Supplier Control

    • 3.6 Records Collection and Retention

IEEE STD 1044 “1993 IEEE Standard 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 but does not attempt to define all the data supporting the analysis of an anomaly.

Keywords: anomaly, category, classification, classification process, supporting data item

Contents

  1. Overview

    • 1.1 Background

    • 1.2 Scope

  2. References

  3. Definitions

  4. Classification Standard

    • 4.1 Classification Process

    • 4.2 Standard Classification Scheme

IEEE STD 1045 “1992 IEEE Standard for Software Productivity Metrics

Abstract: A consistent way to measure the elements that go into computing software productivity is defined. Software productivity metrics and terminology are given to ensure an understanding of measurement data for both source code and document production. Although this standard prescribes measurements to characterize the software process, it neither establishes software productivity norms, nor does it recommend productivity measurements as a method to evaluate software projects or software developers. This standard does not measure the quality of software. This standard does not claim to improve productivity, only to measure it. The goal of this standard is to provide a better understanding of the software process, which may lend insight to improving it.

Keywords: attribute, primitive, productivity ratio, source statement, staff- hour

Contents

  1. Overview

    • 1.1 Scope

    • 1.2 Terminology

    • 1.3 Audience

  2. References

  3. Definitions

  4. Software Productivity Metrics

  5. Output Primitives

    • 5.1 Source Statement Output Primitives

    • 5.2 Function Point Output Primitive

    • 5.3 Document Output Primitives

  6. Input Primitive

    • 6.1 Staff-Hour Input Primitive

    • 6.2 Staff-Hour Attribute

    • 6.3 Activities

  7. Relationships

    • 7.1 Productivity Ratios

    • 7.2 Output-to-Output Ratios

    • 7.3 Input-to-Input Ratios

  8. Characteristics

    • 8.1 Project Characteristics

    • 8.2 Management Characteristics

    • 8.3 Product Characteristics

IEEE STD 1058.1-1987 IEEE Standard for Software Project Management Plans

Contents

  1. Scope and References

    • 1.1 Scope

    • 1.2 References

  2. Definitions

  3. Software Project Management Plans

    • 3.1 Introduction (Section 1 of the SPMP)

    • 3.2 Project Organization (Section 2 of the SPMP)

    • 3.3 Managerial Process (Section 3 of the SPMP)

    • 3.4 Technical Process (Section 4 of the SPMP)

    • 3.5 Work Packages, Schedule, and Budget (Section 5 of the SPMP)

    • 3.6 Additional Components

IEEE STD 1059 “1993 IEEE Guide for Software Verification and Validation Plans

Abstract: Guidance in preparing Software Verification and Validation Plans (SVVPs) that comply with IEEE STD 1012 “1986 are provided. IEEE STD 1012 “1986 specifies the required content for an SVVP. This guide recommends approaches to Verification and Validation (V&V) planning. This guide does not present requirements beyond those stated in IEEE STD 1012 “1986.

Keywords: baseline change assessment, life-cycle phases, master schedule, V&V tasks

Contents

  1. Overview

    • 1.1 Scope

  2. References

  3. Conventions, Definitions, and Acronyms and Abbreviations

    • 3.1 Conventions

    • 3.2 Definitions

    • 3.3 Acronyms and Abbreviations

  4. Software Verification and Validation

    • 4.1 Software V&V Planning Guidance

    • 4.2 Integrating and Continuing V&V Tasks

  5. SVVP Guidance

    • 5.1 Purpose

    • 5.2 Referenced Documents

    • 5.3 Definitions

    • 5.4 Verification and Validation Overview

    • 5.5 Life-Cycle Verification and Validation

    • 5.6 Reporting

    • 5.7 Verification and Validation Administrative Procedures

IEEE STD 1061 “1992 IEEE Standard for a Software Quality Metrics Methodology

Abstract: A methodology for establishing quality requirements and identifying, implementing, analyzing, and validating the process and product of software quality metrics is defined. The methodology spans the entire software life cycle. Although this standard includes examples of metrics, it does not prescribe specific metrics.

Keywords: direct metric, factor, metrics framework, software quality metric, subfactor

Contents

  1. Overview

    • 1.1 Scope

    • 1.2 Audience

  2. Definitions

  3. Purpose of Software Quality Metrics

  4. Software Quality Metrics Framework

  5. The Software Quality Metrics Methodology

    • 5.1 Establish Software Quality Requirements

    • 5.2 Identify Software Quality Metrics

    • 5.3 Implement the Software Quality Metrics

    • 5.4 Analyze the Software Metrics Results

    • 5.5 Validate the Software Quality Metrics

IEEE STD 1062 “1993 IEEE Recommended Practice for Software Acquisition

Abstract: A set of useful quality practices that can be selected and applied during one or more steps in a software acquisition process is described. 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.

Keywords: acquirer, modified-off-the-shelf software, software acquisition life cycle, software acquisition process, supplier

Contents

  1. Overview

    • 1.1 Scope

    • 1.2 Terminology

  2. References

  3. Definitions

  4. Introducing the Software Acquisition Process

    • 4.1 Software Acquisition Life Cycle

    • 4.2 Nine Steps in Acquiring Quality Software

  5. Software Acquisition Process

    • 5.1 Planning Organizational Strategy

    • 5.2 Implementing Organization's Process

    • 5.3 Defining the Software Requirements

    • 5.4 Identifying Potential Suppliers

    • 5.5 Preparing Contract Requirements

    • 5.6 Evaluating Proposals and Selecting Supplier

    • 5.7 Managing for Supplier Performance

    • 5.8 Accepting the Software

    • 5.9 Using the Software

  6. Summary

IEEE STD 1063 “1987 IEEE Standard for Software User Documentation

Contents

  1. Scope

    • 1.1 Applicability

    • 1.2 Organization

  2. Definitions

  3. Identifying Required User Documents

    • 3.1 Identifying the Software

    • 3.2 Determining the Document Audience

    • 3.3 Determining the Document Set

    • 3.4 Determining Document Usage Modes

  4. User Document Inclusion Requirements

  5. User Document Content Requirements

    • 5.1 Title Page

    • 5.2 Restrictions

    • 5.3 Warranties and Contractual Obligations

    • 5.4 Table of Contents

    • 5.5 List of Illustrations

    • 5.6 Introduction

    • 5.7 Body of Document

    • 5.8 Error Messages, Known Problems, and Error Recovery

    • 5.9 Appendices

    • 5.10 Bibliography

    • 5.11 Glossary

    • 5.12 Index

  6. User Document Presentation Requirements

    • 6.1 Highlighting

    • 6.2 Consistency

    • 6.3 Terminology

    • 6.4 Referencing Related Material

  7. Bibliography

IEEE STD 1074 “1991 IEEE Standard for Developing Software Life-Cycle Processes

Abstract: The set of activities that constitute the processes that are mandatory for the development and maintenance of software, whether stand-alone or part of a system, is set forth. The management and support processes that continue throughout the entire life cycle, as well as all aspects of the software life cycle from concept exploration through retirement, are covered. Associated input and output information is also provided. Utilization of the processes and their component activities maximizes the benefits to the user when the use of this standard is initiated early in the software life cycle. This standard requires definition of a user's software life cycle and shows its mapping into typical software life cycles; it is not intended to define or imply a software life cycle of its own.

Keywords: project management processed , project monitoring and control process, software development process, software implementation process, software installation process, software life cycle, software life-cycle model process, software life-cycle process, software maintenance process, software operation and support process, software post-development process, software pre-development process, software quality management process, software requirements process, software retirement process, software system allocation process

Contents

  1. Introduction

    • 1.1 Scope

    • 1.2 References

    • 1.3 Definitions and Acronyms

    • 1.4 Organization of This Document

    • 1.5 Use of This Standard

  2. Software Life-Cycle Model Process

    • 2.1 Overview

    • 2.2 Activities List

    • 2.3 Identify Candidate Software Life-Cycle Models

    • 2.4 Select Project Model

  3. Project Management Processes

    • 3.1 Project Initiation Process

    • 3.2 Project Monitoring and Control Process

    • 3.3 Software Quality Management Process

  4. Pre-Development Process

    • 4.1 Concept Exploration Process

    • 4.2 System Allocation Process

  5. Development Processes

    • 5.1 Requirements Process

    • 5.2 Design Process

    • 5.3 Implementation Process

  6. Post-Development Processes

    • 6.1 Installation Process

    • 6.2 Operation and Support Process

    • 6.3 Maintenance Process

    • 6.4 Retirement Process

  7. Integral Processes

    • 7.1 Verification and Validation Process

    • 7.2 Software Configuration Management Process

    • 7.3 Documentation Development Process

    • 7.4 Training Process

  8. Bibliography

IEEE STD 1074.1-1995 IEEE Guide for Developing Software Life-Cycle Processes

Abstract: Selected topics covered in IEEE STD 1074 “1995, IEEE Standard for Developing Software Life-Cycle Processes, are addressed in this guide. The guide provides assistance with Software Life-Cycle Model (SLCM) selection, activity mapping, and management of a software life cycle (SLC).

Keywords: software life cycle, processes, software life-cycle model, software life-cycle process, activities, mapping

Contents

  1. Overview

    • 1.1 Scope

    • 1.2 Purpose

    • 1.3 Prerequisites

    • 1.4 References

    • 1.5 Definitions and Acronyms

  2. General Concepts of the Standard

    • 2.1 Process Standard

    • 2.2 Compliance

      • 2.2.1 Upward Adaptation

      • 2.2.2 Downward Adaptation

    • 2.3 Applicability

    • 2.4 Intended Audience

    • 2.5 How to Start Using the Standard

      • 2.5.1 SLCM

      • 2.5.2 Project Type

    • 2.6 SLC, SLCM, and Methodology

    • 2.7 Organizational Concerns

  3. Mapping Guidelines

    • 3.1 An Approach to Mapping

    • 3.2 SLCM + Activities = SLC

    • 3.3 Information Tracing

    • 3.4 Hidden Information and Tasks

    • 3.5 Information Mapping

    • 3.6 Mapping Constraints

  4. Concepts of the Standard Used in Mapping

    • 4.1 Time Ordering

    • 4.2 Iterations and Instances

    • 4.3 Ownership

    • 4.4 Integral Processes

    • 4.5 Management Processes

    • 4.6 Risk Management

    • 4.7 Maintenance

    • 4.8 Retirement

    • 4.9 Reuse and the SLC

IEEE STD 1175 “1992 IEEE Trial-Use Standard Reference Model for Computing System Tool Interconnections

Abstract: Reference models for tool-to-organization interconnections, tool-to-platform interconnections, and information transfer among tools are provided. The purpose is to establish agreements for information transfer among tools in the contexts of human organization, a computer system platform, and a software development application. To make the transfer of semantic information among tools easier, a semantic transfer language (STL) is also provided. Interconnections that must be considered when buying, building, testing, or using computing system tools for specifying behavioral descriptions or requirements of system and software products are described.

Keywords: information transfer, reference model, semantic transfer language (STL), tool-to-organization interconnections, tool-to-platform interconnections

Contents

  • Part 1 Description of this Standard

  1. Introduction

    • 1.1 Purpose

    • 1.2 Scope

    • 1.3 Audience

    • 1.4 Organization of this Document

    • 1.5 Definitions

    • 1.6 Conformance

  • Part 2 Context for Tool Interconnections

  1. Reference Model for Tool-to-Organization Interconnections

    • 2.1 Organizational Context for Tools

    • 2.2 Role or Job Function View of a Tool

    • 2.3 Life-Cycle View of a Tool

    • 2.4 Support View of a Tool

    • 2.5 Tool-to-Organization Interconnection Standard Profile

  2. Reference Model for Tool-to-Platform Interconnections

    • 3.1 Hardware-Software Platform Context for Tools

    • 3.2 Platforms

    • 3.3 Hardware Platforms

    • 3.4 Software Platforms

    • 3.5 Tool-to-Platform Interconnection Standard Profile

  3. Reference Model for Information Transfer among Tools

    • 4.1 Information Transfer Context

    • 4.2 Mechanisms for Information Transfer among Tools

    • 4.3 Processes of Information Transfer: Services for Information Transfer

    • 4.4 Descriptions of Information Being Transferred

    • 4.5 Information Transferred

    • 4.6 Tool Interconnection Standard Profile

  • Part 3 Interconnection Language

  1. Semantic Transfer Language (STL) Overview and Syntax

    • 5.1 STL Goals

    • 5.2 STL Sentence Form

    • 5.3 STL Notation

    • 5.4 STL Information Packet

    • 5.5 STL Sentences

    • 5.6 STL Language Elements

    • 5.7 Language Integrity

    • 5.8 STL Syntax Summary

  2. STL Concepts and Meanings

    • 6.1 STL Concept Organization

    • 6.2 Concept Definition Conventions

    • 6.3 Concept Definition Sentence Templates

    • 6.4 STL Summary

  3. STL Conformance and Extensibility

    • 7.1 STL Interconnection Profile

    • 7.2 STL Extensibility

  4. Bibliography

IEEE STD 1220 “1994 IEEE Trial-Use Standard for Application and Management of the Systems Engineering Process

Abstract: The interdisciplinary tasks that are required throughout a system's life cycle to transform customer needs, requirements, and constraints into a system solution are defined. This standard applies to a performing activity within an enterprise that is responsible for developing a product design and establishing the life-cycle infrastructure needed to provide for life-cycle sustainment. It specifies the requirements for the systems engineering process and its application throughout the product life cycle. The requirements of this standard are applicable to new products as well as incremental enhancements to existing products.

Keywords: enterprise, Systems Engineering Detailed Schedule (SEDS), Systems Engineering Management Plan (SEMP), Systems Engineering Master Schedule (SEMS), systems engineering process

Contents

  1. Overview

    • 1.1 Scope

    • 1.2 Purpose

    • 1.3 Understanding This Standard

    • 1.4 Organization of This Standard

  2. References

  3. Definitions and Acronyms

    • 3.1 Definitions

  4. General Requirements

    • 4.1 Systems Engineering Process

    • 4.2 Policies and Procedures for Systems Engineering

    • 4.3 Planning the Technical Effort

    • 4.4 Evolutionary Development Strategies

    • 4.5 Modeling and Prototyping

    • 4.6 Integrated Database

    • 4.7 Product and Process Data Package

    • 4.8 Specification Tree

    • 4.9 Drawing Tree

    • 4.10 System Breakdown Structure (SBS)

    • 4.11 Integration of the Systems Engineering Effort

    • 4.12 Technical Reviews

    • 4.13 Quality Management

    • 4.14 Continuing Product and Process Improvement

  5. Application of Systems Engineering throughout the System Life Cycle

    • 5.1 System Definition Stage

    • 5.2 Preliminary Design Stage

    • 5.3 Detailed Design Stage

    • 5.4 Fabrication, Assembly, Integration, and Test (FAIT) Stage

    • 5.5 Production and Customer Support Stages

    • 5.6 Simultaneous Engineering of Products and Services of Life Cycle Processes

  6. The Systems Engineering Process

    • 6.1 Requirements Analysis

    • 6.2 Requirements Validation

    • 6.3 Functional Analysis

    • 6.4 Functional Verification

    • 6.5 Synthesis

    • 6.6 Physical Verification

    • 6.7 Systems Analysis

    • 6.8 Control

IEEE/EIA 12207.0-1996 Industry Implementation of International Standard ISO/IEC: ISO/IEC12207 Standard for Information Technology Software Life-Cycle Processes

Abstract: ISO/IEC 12207 provides a common framework for developing and managing software. IEEE/EIA 12207.0 consists of the clarifications, additions, and changes accepted by the Institute of Electrical and Electronics Engineers (IEEE) and the Electronic Industries Association (EIA) formulated by a joint project of the two organizations. IEEE/EIA 12207.0 contains concepts and guidelines to foster a better understanding and application of the standard. Thus, this standard provides industry with a basis for software practices that would be usable for both national and international business.

IEEE STD 1228 “1994 IEEE Standard for Software Safety Plans

Abstract: The minimum acceptable requirements for the content of a software safety plan are established. This standard applies to the software safety plan used for the development, procurement, maintenance, and retirement of safety-critical software. This standard requires that the plan be prepared within the context of the system safety program. Only the safety aspects of the software are included. This standard does not contain special provisions required for software used in distributed systems or in parallel processors.

Keywords: safety-critical software, software safety plan, software safety program, safety requirements

Contents

  1. Overview

    • 1.1 Purpose

    • 1.2 Scope

    • 1.3 Application

    • 1.4 Disclaimer

  2. References

  3. Definitions and Abbreviations

    • 3.1 Definitions

    • 3.2 Abbreviations

  4. Contents of a Software Safety Plan

    • 4.1 Purpose (Section 1 of the Plan)

    • 4.2 Definitions, Acronyms and Abbreviations, and References (Section 2 of the

    • Plan)

    • 4.3 Software Safety Management (Section 3 of the Plan)

    • 4.4 Software Safety Analyses (Section 4 of the Plan)

    • 4.5 Post Development (Section 5 of the Plan)

    • 4.6 Plan Approval (Section 6 of the Plan)

IEEE STD 1298 “1992 Software Quality Management System Part 1: Requirements

Abstract: Requirements for a software developer's quality management system are established. Each of the elements of a quality management system to be designed, developed, and maintained by the developer are identified, with the objective of ensuring that the software will meet the requirements of a contract, purchase order, or other agreement (collectively referred to as a "contract").

Keywords: software development, software quality, software quality management

Contents

  1. Scope and Field of Application

    • 1.1 Scope

    • 1.2 Application

  2. Referenced Documents

  3. Definitions

  4. Quality System Requirements

    • 4.1 Management Responsibility

    • 4.2 Quality System

    • 4.3 Contract Review, Planning, and Requirements Control

    • 4.4 Design, Programming, and User Documentation Control

    • 4.5 Quality System Document Control

    • 4.6 Purchasing

    • 4.7 Customer-Supplied Information and Material

    • 4.8 Configuration Management (including product identification and traceability)

    • 4.9 Process Control

    • 4.10 Inspection and Testing

    • 4.11 Inspection, Measuring, and Test Equipment

    • 4.12 Inspection and Test Status

    • 4.13 Control of Non-Conforming Product

    • 4.14 Corrective Action

    • 4.15 Handling, Storage, Packaging, and Delivery

    • 4.16 Quality Records

    • 4.17 Internal Quality Audits

    • 4.18 Training

    • 4.19 Software Maintenance

    • 4.20 Statistical techniques

    • 4.21 Control of Development Environment

IEEE STD 1362 “1998 (Incorporates IEEE STD 1362a-1998) IEEE Guide for 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 organization(s), mission(s), and organizational objectives from an integrated systems point of view.

Keywords: buyer, characteristics, concept of operation, concepts of operations document, ConOps, developer, operational requirements, scenario, software- intensive system, software system, system, user, user requirements, viewpoint

Contents

  1. Scope

  2. References

  3. Definitions

  4. Elements of a ConOps Document

    • 4.1 Scope (Clause 1 of the ConOps document)

    • 4.2 Referenced Documents (Clause 2 of the ConOps document)

    • 4.3 Current System or Situation (Clause 3 of the ConOps document)

    • 4.4 Justification for and Nature of Changes (Clause 4 of the ConOps document)

    • 4.5 Concepts for the Proposed System (Clause 5 of the ConOps document)

    • 4.6 Operational Scenarios (Clause 6 of the ConOps document)

    • 4.7 Summary of Impacts (Clause 7 of the ConOps document)

    • 4.8 Analysis of the Proposed System (Clause 8 of the ConOps document)

    • 4.9 Notes (Clause 9 of the ConOps document)

    • 4.10 Appendices (Appendices of the ConOps document)

    • 4.11 Glossary (Glossary of the ConOps document)

      • Annex A IEEE: EIA 12207.1-1997 Compliance Statement

IEEE STD 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology

Abstract: IEEE STD 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology, identifies terms currently in use in the field of software engineering. Standard definitions for those terms are established.

Keywords: software engineering, glossary, terminology, definitions, dictionary

Contents

  1. Scope

  2. Glossary Structure

  3. Definitions for Software Engineering Terms

  4. Bibliography

IEEE STD 730 “1989 IEEE Standard for Software Quality Assurance Plans

Contents

  1. Scope and References

    • 1.1 Scope

    • 1.2 References

  2. Definitions and Acronyms

    • 2.1 Definitions

  3. Software Quality Assurance Plan

    • 3.1 Purpose (Section 1 of the SQAP)

    • 3.2 Reference Documents (Section 2 of the SQAP)

    • 3.3 Management (Section 3 of the SQAP)

    • 3.4 Documentation (Section 4 of the SQAP)

    • 3.5 Standards, Practices, Conventions, and Metrics (Section 5 of the SQAP)

    • 3.6 Reviews and Audits (Section 6 of the SQAP)

    • 3.7 Test (Section 7 of the SQAP)

    • 3.8 Problem Reporting and Corrective Action (Section 8 of the SQAP)

    • 3.9 Tools, Techniques, and Methodologies (Section 9 of the SQAP)

    • 3.10 Code Control (Section 10 of the SQAP)

    • 3.11 Media Control (Section 11 of the SQAP)

    • 3.12 Supplier Control (Section 12 of the SQAP)

    • 3.13 Records Collection, Maintenance, and Retention (Section 13 of the SQAP)

    • 3.14 Training (Section 14 of the SQAP)

    • 3.15 Risk Management (Section 15 of the SQAP)

IEEE STD 828 “1990 IEEE Standard for Software Configuration Management Plans

Abstract: IEEE STD 828 “1990, IEEE Standard for Software Configuration Management Plans, establishes the minimum required contents of a Software Configuration Management Plan and defines the specific activities to be addressed and their requirements for any portion of a software product's life cycle.

Keywords: configuration control board, configuration items, software configuration management, software configuration management activities

Contents

  1. Introduction to the Standard

    • 1.1 Scope

    • 1.2 References

    • 1.3 Definitions and Acronyms

  2. The Software Configuration Management Plan

    • 2.1 Introduction

    • 2.2 SCM Management

    • 2.3 SCM Activities

    • 2.4 SCM Schedules

    • 2.5 SCM Resources

    • 2.6 SCM Plan Maintenance

  3. Tailoring of the Plan

    • 3.1 Upward Tailoring

    • 3.2 Downward Tailoring

    • 3.3 Format

  4. Conformance to the Standard

    • 4.1 Minimum Information

    • 4.2 Presentation Format

    • 4.3 Consistency Criteria

    • 4.4 Conformance Declaration

ANSI/IEEE STD 829 “1983 IEEE Standard for Software Test Documentation

Contents

  1. Scope

  2. Definitions

  3. Test Plan

    • 3.1 Purpose

    • 3.2 Outline

  4. Test-Design Specification

    • 4.1 Purpose

    • 4.2 Outline

  5. Test-Case Specification

    • 5.1 Purpose

    • 5.2 Outline

  6. Test-Procedure Specification

    • 6.1 Purpose

    • 6.2 Outline

  7. Test-Item Transmittal Report

    • 7.1 Purpose

    • 7.2 Outline

  8. Test Log

    • 8.1 Purpose

    • 8.2 Outline

  9. Test-Incident Report

    • 9.1 Purpose

    • 9.2 Outline

  10. Test-Summary Report

    • 10.1 Purpose

    • 10.2 Outline

IEEE STD 830 “1993 IEEE Recommended Practice for 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.

Keywords: contract, customer, prototyping, software requirements specification, supplier, system requirements specifications

Contents

  1. Overview

    • 1.1 Scope

  2. References

  3. Definitions

  4. Considerations for Producing a Good SRS

    • 4.1 Nature of the SRS

    • 4.2 Environment of the SRS

    • 4.3 Characteristics of a Good SRS

    • 4.4 Joint Preparation of the SRS

    • 4.5 SRS Evolution

    • 4.6 Prototyping

    • 4.7 Embedding Design in the SRS

    • 4.8 Embedding Project Requirements in the SRS

  5. The Parts of an SRS

    • 5.1 Introduction (Section 1 of the SRS)

    • 5.2 Overall Description (Section 2 of the SRS)

    • 5.3 Specific Requirements (Section 3 of the SRS)

    • 5.4 Supporting Information

IEEE STD 982.1-1988 IEEE Standard Dictionary of Measures to Produce Reliable Software

Contents

  1. Introduction

    • 1.1 Scope

    • 1.2 References

  2. Definitions

  3. Functional Classification of Measures

    • 3.1 Product Measures

    • 3.2 Process Measures

  4. Measures for Reliable Software

    • 4.1 Fault Density

    • 4.2 Defect Density

    • 4.3 Cumulative Failure Profile

    • 4.4 Fault-Days Number

    • 4.5 Functional or Modular Test Coverage

    • 4.6 Cause and Effect Graphing

    • 4.7 Requirements Traceability

    • 4.8 Defect Indices

    • 4.9 Error Distribution(s)

    • 4.10 Software Maturity Index

    • 4.11 Man-Hhours per Major Defect Detected

    • 4.12 Number of Conflicting Requirements

    • 4.13 Number of Entries and Exits per Module

    • 4.14 Software Science Measures

    • 4.15 Graph-Theoretic Complexity for Architecture

    • 4.16 Cyclomatic Complexity

    • 4.17 Minimal Unit Test Case Determination

    • 4.18 Run Reliability

    • 4.19 Design Structure

    • 4.20 Mean Time to Discover the Next K Faults

    • 4.21 Software Purity Level

    • 4.22 Estimated Number of Faults Remaining (by Seeding)

    • 4.23 Requirements Compliance

    • 4.24 Test Coverage

    • 4.25 Data or Information Flow Complexity

    • 4.26 Reliability Growth Function

    • 4.27 Residual Fault Count

    • 4.28 Failure Analysis Using Elapsed Time

    • 4.29 Testing Sufficiency

    • 4.30 Mean-Time-to-Failure

    • 4.31 Failure Rate

    • 4.32 Software Documentation and Source Listings

    • 4.33 RELY (Required Software Reliability)

    • 4.34 Software Release Readiness

    • 4.35 Completeness

    • 4.36 Test Accuracy

    • 4.37 System Performance Reliability

    • 4.38 Independent Process Reliability

    • 4.39 Combined Hardware and Software (System) Operational Availability

IEEE STD 982.2-1988 IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable Software

Contents

  1. Scope and References

    • 1.1 Scope

    • 1.2 References

  2. Definitions

  3. Measures to Produce Reliable Software

    • 3.1 Constructive Approach to Reliable Software

    • 3.2 Measurement Environment

    • 3.3 Measurement Selection Criteria

  4. Measure Organization and Classification

    • 4.1 Functional Classification

    • 4.2 Life-Cycle Classification

    • 4.3 Indicators and Predictors

  5. Framework for Measures

    • 5.1 Measurement Process

    • 5.2 Stages of a Measurement Process

  6. Errors, Faults, and Failure Analysis for Reliability Improvement

    • 6.1 Dynamics of Errors, Faults, and Failures

    • 6.2 Analysis of Error, Fault, Failure Events

    • 6.3 Minimizing Failure Events

    • 6.4 Summary

IEEE STD 990 “1987 IEEE Recommended Practice for Ada as a Program Design Language

Contents

  1. Introduction

    • 1.1 Scope

    • 1.2 Scope Restrictions

    • 1.3 Terminology

    • 1.4 Cautions

    • 1.5 Examples

  2. Definitions and References

    • 2.1 Definitions

    • 2.2 References

  3. Characteristics

    • 3.1 General Methodology Support

    • 3.2 Specific Design Support

    • 3.3 Other Support

    • 3.4 Ada Relationships

J-STD-016-1995 30 September 1995 Trial Use Standard for Information Technology Software Life-Cycle Processes Software Development Acquirer-Supplier Agreement

Keywords: builds/incremental development, database, joint technical/management reviews, operational concept, reusable software, risk management, security/privacy protection, software, software configuration management, software development, software documentation, software implementation, software management indicators, software product evaluation, software quality assurance, software requirements definition, software safety, software maintenance, software testing, software unit, tailoring

Contents

  1. Scope

    • 1.1 Purpose

    • 1.2 Application

  2. Referenced Documents

  3. Definitions

    • 3.1 Terms

    • 3.2 Abbreviations and Acronyms

  4. General Requirements

    • 4.1 Software Development Process

    • 4.2 General Requirements for Software Development

  5. Detailed Requirements

    • 5.1 Project Planning and Oversight

    • 5.2 Establishing a Software Development Environment

    • 5.3 System Requirements Definition

    • 5.4 System Design

    • 5.5 Software Requirements Definition

    • 5.6 Software Design

    • 5.7 Software Implementation and Unit Testing

    • 5.8 Unit Integration and Testing

    • 5.9 Software Item Qualification Testing

    • 5.10 Software/Hardware Item Integration and Testing

    • 5.11 System Qualification Testing

    • 5.12 Preparing for Software Use

    • 5.13 Preparing for Software Transition

    • 5.14 Software Configuration Management

    • 5.15 Software Product Evaluation

    • 5.16 Software Quality Assurance

    • 5.17 Corrective Action

    • 5.18 Joint Technical and Management Reviews

    • 5.19 Risk Management

    • 5.20 Software Management Indicators

    • 5.21 Administrative Security and Privacy Protection

    • 5.22 Managing Subcontractors

    • 5.23 Interfacing with Software IV&V Agents

    • 5.24 Coordinating with Associate Developers

    • 5.25 Project Process Improvement

  6. Notes

    • 6.1 Cross Reference of Standard Subclauses to Annex Subclauses

    • 6.2 Delivery of Tool Contents

ISO

In 1946, the International Organization for Standardization (ISO; www.iso.ch) was founded in Geneva, Switzerland. More than 75 countries , including the United States through ANSI, have member organizations. The ISO has over 160 technical committees and 2300 sub- committees working on a variety of standards. Indeed, the ISO has developed more than 13,000 standards in such esoteric disciplines as clothing, road vehicles, railway engineering, and information technology.

ISO 9000 is the most recognizable of ISO standards. It defines the criteria for quality in the manufacturing and service industries. It was first popularized in Europe but its popularity has spread worldwide as more and more companies deem "ISO certification" to be a competitive advantage.

ISO 9000 is actually a "family" of standards (see Table 12.2).

Table 12.2: ISO 9000 Family of Standards
  1. ISO 9000 ” is the actual standard. ISO 9001, ISO 9002, and ISO 9003 are the three quality assurance models against which organizations can be certified.

  2. ISO 9001 ” is the standard of interest for companies that perform the entire range of activities, from design and development to testing. ISO 9001 is of most interest to the software developer. It is this standard that provides the all-important checklist of quality initiatives such as:

    1. Develop your quality management system:

      1. Identify the processes that make up your quality system.

      2. Describe your quality management processes.

    2. Implement your quality management system:

      1. Use quality system processes.

      2. Manage process performance

    3. Improve your quality management system:

      1. Monitor process performance.

      2. Improve process performance

    ISO 9001 is directly applicable to configuration management as it specifies that change requests be maintained and tracked.

  3. ISO 9002 ” is the standard for companies that do not engage in design and development. This standard focuses on production, installation, and service.

  4. ISO 9003 ” is the appropriate standard for companies whose business processes do not include design control, process control, purchasing, or servicing . This standard focuses on testing and inspection.

ISO Software Engineering Standards Summary

The ISO standards listed in Table 12.3, including configuration management standards, are summarized. Boldfaced titles indicate applicability to configuration management.

Table 12.3: ISO Software Engineering Standards Summary

ISO/IEC 2382-20:1990

Information technology ” vocabulary ” Part 20: System development

ISO 3535:1977

Forms DESIGN SHEET and LAYOUT CHART

ISO 5806:1984

Information processing ” specification of single-hit decision tables

ISO 5807:1985

Information processing ” documentation symbols and conventions for data, program, and system flowcharts, program network charts, and system resources charts

ISO/IEC 6592:2000

Information technology ” guidelines for the documentation of computer-based application systems. No abstract.

ISO 6593:1985

Information processing ” program flow for processing sequential files in terms of record groups

ISO/IEC 8211:1994

Information technology ” specification for a data descriptive file for information interchange

ISO/IEC 8631:1989

Information technology ” program constructs and conventions for their representation

ISO 8790:1987

Information processing systems ” computer system configuration diagram symbols and conventions

ISO 9000-3:1997

Quality management and quality assurance standards ” Part 3: Guidelines for the application of ISO 9001:1994 to the development, supply, installation, and maintenance of computer software. No abstract.

ISO/IEC 9126-1:2001

Software engineering ” product quality ” Part 1: Quality model. No abstract.

ISO 9127:1988

Information processing systems ” user documentation and cover information for consumer software packages

ISO/IEC TR 9294:1990

Information technology ” guidelines for the management of software documentation

ISO 10007:2003

Quality management systems ” guidelines for configuration management

ISO/IEC 10746-1:1998

Information technology ” Open Distributed Processing ” Reference Model: Overview. No abstract.

ISO/IEC 10746-2:1996

Information technology ” Open Distributed Processing ” Reference Model: Foundations

ISO/IEC 10746-3:1996

Information technology ” Open Distributed Processing ” Reference Model: Architecture

ISO/IEC 10746-4:1998

Information technology ” Open Distributed Processing ” Reference Model: Architectural semantics. No abstract.

ISO/IEC 10746-4:1998/Amd 1:2001

Computational formalization. No abstract.

ISO/IEC 11411:1995

Information technology ” representation for human communication of state transition of software

ISO/IEC 12119:1994

Information technology ” Software packages ” quality requirements and testing

ISO/IEC TR 12182:1998

Information technology ” Categorization of software. No abstract.

ISO/IEC 12207:1995

Information technology ” Software life-cycle processes

ISO/IEC 12207:1995/Amd 1:2002

  

ISO/IEC 13235-1:1998

Information technology ” Open Distributed Processing ” Trading function: Specification. No abstract.

ISO/IEC 13235-3:1998

Information technology ” Open Distributed Processing ” Trading Function ” Part 3: Provision of Trading Function using OSI Directory Service. No abstract.

ISO/IEC 13244:1998

Information technology ” Open Distributed Management Architecture. No abstract.

ISO/IEC 13244:1998/Amd 1:1999

Support using Common Object Request Broker Architecture (CORBA). No abstract.

ISO/IEC 13800:1996

Information technology ” procedure for the registration of identifiers and attributes for volume and file structure. No abstract.

ISO/IEC 14102:1995

Information technology ” guideline for the evaluation and selection of CASE tools. No abstract.

ISO/IEC 14143-1:1998

Information technology ” Software measurement ” functional size measurement ” Part 1: Definition of concepts

ISO/IEC 14143-2:2002

Information technology ” Software measurement ” functional size measurement ” Part 2: Conformity evaluation of software size measurement methods to ISO/IEC 14143-1:1998. No abstract.

ISO/IEC TR 14143-3:2003

Information technology ” Software measurement ” functional size measurement ” Part 3: Verification of functional size measurement methods

ISO/IEC TR 14143-4:2002

Information technology ” Software measurement ” functional size measurement ” Part 4: Reference model. No abstract.

ISO/IEC TR 14471:1999

Information technology ” Software engineering ” guidelines for the adoption of CASE tools. No abstract.

ISO/IEC 14598-1:1999

Information technology ” Software product evaluation ” Part 1: General overview. No abstract.

ISO/IEC 14598-2:2000

Software engineering ” Product evaluation ” Part 2: Planning and management. No abstract.

ISO/IEC 14598-3:2000

Software engineering ” Product evaluation ” Part 3: Process for developers. No abstract.

ISO/IEC 14598-4:1999

Software engineering ” Product evaluation ” Part 4: Process for acquirers . No abstract.

ISO/IEC 14598-5:1998

Information technology ” Software product evaluation ” Part 5: Process for evaluators . No abstract.

ISO/IEC 14598-6:2001

Software engineering ” Product evaluation ” Part 6: Documentation of evaluation modules. No abstract.

ISO/IEC 14750:1999

Information technology ” Open Distributed Processing ” Interface Definition Language. No abstract.

ISO/IEC 14752:2000

Information technology ” Open Distributed Processing ” protocol support for computational interactions. No abstract.

ISO/IEC 14753:1999

Information technology ” Open Distributed Processing ” interface references and binding. No abstract.

ISO/IEC 14756:1999

Information technology ” measurement and rating of performance of computer-based software systems. No abstract.

ISO/IEC TR 14759:1999

Software engineering ” Mock-up and prototype ” a categorization of software mock-up and prototype models and their use. No abstract.

ISO/IEC 14764:1999

Information technology ” Software maintenance. No abstract.

ISO/IEC 14769:2001

Information technology ” Open Distributed Processing ” Type Repository Function. No abstract.

ISO/IEC 14771:1999

Information technology ” Open Distributed Processing ” naming framework. No abstract.

ISO/IEC 14834:1996

Information technology ” Distributed Transaction Processing ” the XA Specification

ISO/IEC 14863:1996

Information technology ” System-Independent Data Format (SIDF). No abstract.

ISO/IEC 15026:1998

Information technology ” System and software integrity levels. No abstract.

ISO/IEC TR 15271:1998

Information technology ” Guide for ISO/IEC 12207 (Software Life-Cycle Processes). No abstract.

ISO/IEC 15288:2002

Systems engineering ” System life-cycle processes. No abstract.

ISO/IEC 15414:2002

Information technology ” Open distributed processing ” Reference model ” Enterprise language. No abstract.

ISO/IEC 15437:2001

Information technology ” Enhancements to LOTOS (E-LOTOS). No abstract.

ISO/IEC 15474-1:2002

Information technology ” CDIF framework ” Part 1: Overview. No abstract.

ISO/IEC 15474-2:2002

Information technology ” CDIF framework ” Part 2: Modeling and extensibility. No abstract.

ISO/IEC 15475-1:2002

Information technology ” CDIF transfer format ” Part 1: General rules for syntaxes and encodings. No abstract.

ISO/IEC 15475-2:2002

Information technology ” CDIF transfer format ” Part 2: Syntax SYNTAX.1. No abstract.

ISO/IEC 15475-3:2002

Information technology ” CDIF transfer format ” Part 3: Encoding ENCODING.1. No abstract.

ISO/IEC 15476-1:2002

Information technology ” CDIF semantic metamodel ” Part 1: Foundation. No abstract.

ISO/IEC 15476-2:2002

Information technology ” CDIF semantic metamodel ” Part 2: Common. No abstract.

ISO/IEC TR 15504-1:1998

Information technology ” Software process assessment ” Part 1: Concepts and introductory guide. No abstract.

ISO/IEC TR 15504-2:1998

Information technology ” Software process assessment ” Part 2: A reference model for processes and process capability. No abstract.

ISO/IEC TR 15504-3:1998

Information technology ” Software process assessment ” Part 3: Performing an assessment. No abstract.

ISO/IEC TR 15504-4:1998

Information technology ” Software process assessment ” Part 4: Guide to performing assessments. No abstract.

ISO/IEC TR 15504-5:1999

Information technology ” Software process assessment ” Part 5: An assessment model and indicator guidance. No abstract.

ISO/IEC TR 15504-6:1998

Information technology ” Software process assessment ” Part 6: Guide to competency of assessors. No abstract.

ISO/IEC TR 15504-7:1998

Information technology ” Software process assessment ” Part 7: Guide for use in process improvement. No abstract.

ISO/IEC TR 15504-8:1998

Information technology ” Software process assessment ” Part 8: Guide for use in determining supplier process capability. No abstract.

ISO/IEC TR 15504-9:1998

Information technology ” Software process assessment ” Part 9: Vocabulary. No abstract.

ISO/IEC TR 15846:1998

Information technology ” Software life-cycle processes ” Configuration Management. No abstract.

ISO/IEC 15910:1999

Information technology ” Software user documentation process. No abstract.

ISO/IEC 15939:2002

Software engineering ” Software measurement process. No abstract.

ISO/IEC TR 16326:1999

Software engineering ” Guide for the application of ISO/IEC 12207 to project management. No abstract.

ISO/IEC 19500-2:2003

Information technology ” Open Distributed Processing ” Part 2: General Inter-ORB Protocol (GIOP)/Internet Inter-ORB Protocol (IIOP)

ISO/IEC 19761:2003

Software engineering ” COSMIC-FFP ” a functional size measurement method

ISO/IEC 20968:2002

Software engineering ” Mk II Function Point Analysis ” counting practices manual

ISO/IEC 2382-20:1990 Information technology ” Vocabulary ” Part 20: System development

Serves to facilitate international communication in information processing. Presents English and French terms and definitions of selected concepts as regards the field of information processing and defines relationships between the entries. The provided concepts concern a system life cycle ranging from the requirements analysis to the implementation, including system design and quality assurance.

ISO 3535:1977 Forms design sheet and layout chart

Abstract: Lays down the basic principles for the design of forms, whether discrete forms or continuous forms, and establishes a forms design sheet and a layout chart based on these principles. Applies to the design of forms for administrative, commercial, and technical use, whether for completion in handwriting or by mechanical means such as typewriters and automatic printers.

ISO 5806:1984 Information processing ” Specification of single-hit decision tables

Abstract: The basic format of single-hit decision tables and relevant definitions are described, together with recommended conventions for preparation and use. Is concerned with the use of decision tables in the context of documentation of computer-based information systems.

ISO 5807:1985 Information processing ” Documentation symbols and conventions for data, program, and system flowcharts; program network charts; and system resources charts

Abstract: Defines symbols to be used in information processing documentation and gives guidance on conventions for their use in data flowcharts, program flowcharts, system flowcharts, program network charts, and system resources charts. Applicable in conjunction with ISO 2382/1.

ISO 6593:1985 Information processing ” Program flow for processing sequential files in terms of record groups

Abstract: Describes two alternative general procedures for any program for processing sequential files logically organized in groups of records: Method A ” checking of control head conditions after termination of appropriate level; Method B ” checking of control head conditions before initiation of appropriate level.

ISO/IEC 8211:1994 Information technology ” Specification for a data descriptive file for information interchange

Abstract: Cancels and replaces the first edition (1985). Specifies an interchange format to facilitate the moving of files or parts of files containing data records between computer systems. Specifies: media-independent file and data record descriptions for information interchange; the description of data elements, vectors, arrays, and hierarchies containing character strings, bit strings, and numeric forms; a data descriptive file; a data descriptive record; three levels of complexity of file and record structure; FTAM unstructured and structured document types.

ISO/IEC 8631:1989 Information technology ” Program constructs and conventions for their representation

Abstract: Is concerned with the expression of procedure-oriented algorithms. Defines: (1) the nature of program constructs; (2) the manner in which constructs can be combined; (3) specifications for a set of constructs; a variety of subsets of the defined constructs.

ISO 8790:1987 Information processing systems ” Computer system configuration diagram symbols and conventions

Abstract: Defines graphical symbols and their conventions for use in configuration diagrams for computer systems, including automatic data processing systems.

ISO 9127:1988 Information processing systems ” User documentation and cover information for consumer software packages

Abstract: Describes user documentation and cover information supplied with software packages. Is applicable to software packages sold off-the-shelf to consumers for business, scientific, educational, and home use. References: ISO 6592; ISO 7185.

ISO/IEC TR 9294:1990 Information technology ” Guidelines for the management of software documentation

Abstract: Addresses the policies, standards, procedures, resources, and plans to produce effective software. Applicable to all types of software, from the simplest program to the most complex software system and to all stages of the software life cycle. Detailed advice on the content and layout of software documentation is not provided. Annex A contains checklists of the policies, standards, procedures, and project planning on the software production.

ISO 10007:2003 Quality management systems ” Guidelines for configuration management

Abstract: ISO 10007:2003 gives guidance on the use of configuration management within an organization. It is applicable to the support of products from concept to disposal.

It first outlines the responsibilities and authorities before describing the configuration management process that includes configuration management planning, configuration identification, change control, configuration status accounting, and configuration audit.

Since ISO 10007:2003 is a guidance document, it is not intended to be used for certification/registration purposes.

ISO/IEC 10746-2:1996 Information technology ” Open Distributed Processing ” Reference Model: Foundations

Abstract: Contains the concepts needed to perform the modeling of ODP systems, and the principles of conformance to ODP systems.

ISO/IEC 10746-3:1996 Information technology ” Open Distributed Processing ” Reference Model: Architecture

Abstract: Defines how ODP systems are specified, making use of concepts in ITU-T Recommendation X.902 (ISO/IEC 10746-2); identifies the characteristics that qualify systems as ODP systems.

ISO/IEC 11411:1995 Information technology ” Representation for human communication of state transition of software

Abstract: Defines diagrams and symbols for representing software functions and transitions, and in improving human communication. Covers development, communication, and review of software requirement analysis and design. Effective in interactive software, data communication software, and language/command.

ISO/IEC 12119:1994 Information technology ” Software packages ” quality requirements and testing

Abstract: Applicable to software packages. Establishes requirements for software packages and instructions on how to test a software package against these requirements. Deals only with software packages as offered and delivered; does not deal with their production process. The quality system of a supplier is outside the scope of this standard.

ISO/IEC 12207:1995 Information technology ” Software life-cycle processes

Abstract: Establishes a system for software life-cycle processes with well-defined terminology. Contains processes, activities, and tasks that are to be applied during the acquisition of a system that contains software, a stand-alone software product, and software services.

ISO/IEC TR 14143-3:2003 Information technology ” Software measurement ” functional size measurement ” Part 3: Verification of functional size measurement methods

Abstract: ISO/IEC TR 14143-3:2003 establishes a framework for verifying the statements of an FSM method and/or for conducting tests requested by the verification sponsor, relative to the following performance properties:

  1. Repeatability and reproducibility

  2. Accuracy

  3. Convertibility

  4. Discrimination threshold

  5. Applicability to functional domains
  Note  

Statements and test requests relative to other performance properties are outside the scope of ISO/IEC TR 14143-3:2003.

ISO/IEC TR 14143-3:2003 aims to ensure that the output from the verification is objective, impartial, consistent, and repeatable.

The verification report, produced as a result of applying ISO/IEC TR 14143-3:2003, will enable prospective users to select the FSM method that best meets their needs.

ISO/IEC 14834:1996 Information technology ” Distributed Transaction Processing ” the XA specification

Abstract: Specifies the bi-directional interface between a transaction manager and a resource manager (the XA interface) in an X/Open Distributed Transaction Processing (DTP) environment. Technically identical to X/Open CAE specification. Also contains the text of the X/Open DTP Reference Model Version 3.

ISO/IEC 19500-2:2003 Information technology ” Open Distributed Processing ” Part 2: General Inter-ORB Protocol (GIOP)/Internet Inter-ORB Protocol (IIOP)

Abstract: ISO/IEC 19500-2:2003 specifies the General Inter-ORB Protocol (GIOP) for Object Request Broker (ORB) interoperability. GIOP can be mapped onto any connection-oriented transport protocol that meets a minimal set of assumptions defined by this standard.

ISO/IEC 19761:2003 Software engineering ” COSMIC-FFP ” a functional size measurement method

Abstract: ISO/IEC 19761:2003 specifies the set of definitions, conventions, and activities of the COSMIC-FFP Functional Size Measurement Method. It is applicable to software from the following functional domains:

  1. Application software that is needed to support business administration

  2. Real-time software, the task of which is to keep up with or control events happening in the real world

  3. Hybrids of the above

ISO/IEC 19761:2003 has not been designed to measure the functional size of a piece of software, or its parts, which:

  1. Are characterized by complex mathematical algorithms or other specialized and complex rules, such as may be found in expert systems, simulation software, self-learning software, and weather forecasting systems, or

  2. Process continuous variables such as audio sounds or video images, such as may be found, for example, in computer game software, musical instruments, and the like.

However, within the local environment of an organization using the COSMIC-FFP Functional Size Measurement Method, it might be possible to measure these FUR (Functional User Requirement) in a way that is meaningful as a local standard. ISO/IEC 19761:2003 contains provision for the local customization of the method for this purpose.

ISO/IEC 20968:2002 Software engineering ” Mk II Function Point Analysis ” Counting Practices Manual

Abstract: ISO/IEC 20968:2002 specifies the set of definitions, conventions, and activities of the MkII FPA Functional Size Measurement Method.

The method can be used to measure the functional size of any software application that can be described in terms of logical transactions, each comprising an input, process, and output component. The sizing rules were designed to apply to application software from the domain of business information systems, where the processing component of each transaction tends to be dominated by considerations of the storage or retrieval of data.

The method may be applicable to software from other domains, but the user should note that the sizing rules do not take into account contributions to size such as from complex algorithms as typically found in scientific and engineering software, nor do the rules specifically take into account real-time requirements.

Mk II FPA is independent of the project management method to be used and of the development method employed. It is a measure of the logical business requirements, but is independent of how they are implemented.

SUMMARY

This chapter provides a reference listing of the pertinent industry CM standards.

REFERENCES

[EIA 1998] Electronic Industries Alliance, EIA Standard: National Consensus Standard for Configuration Management, EIA-649, Arlington, VA, August 1998 .

[Paulk et al. 1995] Paulk, Mark C., Charles V. Weber, Bill Curtis, and Mary Beth Chrissis, The Capability Maturity Model: Guidelines for Improving the Software Process , Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, October 1995 .

Related

Категории