NIST Special Publication 500-223Computer Systems Technology
U.S. DEPARTMENT OF COMMERCE
Technology Administration
National Institute of Standards and Technology
NIST Special Publication 500-223
Laura M. Ippolito
December 1994
The purpose of this document is to recommend a framework for the development and assurance of high integrity software. The framework addresses the fact that these processes must take into account properties and requirements of a high integrity system and the processes and standards used in developing other system components. This framework provides guidance to developers, assurers, and buyers of software, researchers for high integrity software systems, and vendors of Computer Aided Software Engineering tools and integrated environments.
KEYWORDS
High integrity software, project management, software assurance, software configuration management, software development, software hazard analysis, software quality assurance, software verification and validation.
NIST acknowledges the contributions by SoHaR, Incorporated to section 5 of this report.
The National Institute of Standards and Technology (NIST) has been working for several years on providing information to government, industry, and academia regarding high integrity software. Efforts in this area have included development of guidance on software verification, validation and testing [e.g., NIST165], hosting a workshop on high integrity software (proceedings are documented in [NIST190]), and conducting studies on high integrity standards and guidelines, software quality assurance documentation and reviews, and software error analysis (results of these studies are documented in [NIST204], [NIST4909], and [NIST209], respectively). NIST recognized the need to develop a single document which would address developing and assuring high integrity software. This document provides a technology independent framework to assist government, industry, and academia in addressing the issues of providing software for high integrity software systems. This framework proposes the activities that comprise software development and software assurance processes, independent of the technology used to perform them. Users of the framework may implement these activities with methods which are most appropriate to the software application domain.
This framework is also a starting point on which to initiate the activities supporting the Center for High Integrity Software Systems Assurance (CHISSA) established by NIST. CHISSA will foster and coordinate activities relating to high integrity software technology. It will help guide research in development, analysis, and testing techniques, conduct assessments on software system technology, and provide transfer of those technologies deemed useful to the industrial sector. CHISSA will work in cooperation with other Federal agencies, industry, and the research community to develop standards and guidelines for high integrity software. CHISSA will also address issues concerning the link between software assurance and the systems in which that software is embedded.
This document provides an initial framework for the development and assurance of high integrity software for use by CHISSA and developers, assurers and buyers of software for high integrity software systems, and by Computer Aided Software Engineering (CASE) vendors. This framework addresses two primary and concurrent processes, software development and software assurance, which each consist of several processes. In this document the software development processes are described separately from the software assurance processes although many activities may be occurring concurrently, and perhaps are performed by the same people. The software development processes build the software, while the software assurance processes provide the activities to plan, monitor and assess the software. This separation of processes in this framework is only for the purpose of identifying the actual activities of each process; all processes contribute to the quality of the software.
This framework proposes the major objective(s) and a detailed list of activities for each software development and software assurance process. The processes and activities occur regardless of the life cycle or methodologies. Different life cycle approaches (e.g., iteration; incremental development) may affect the choice of methods for performing the processes. The choice of technology (e.g., object-oriented) may affect how the requirement and design processes and activities are performed. In both cases, the processes and activities of this framework are applicable and form the basis for specific methods. The software development processes include the software requirements process, software design process, code process, software integration process, software installation process, and software operation and maintenance process.
The software assurance processes include the project management process, software quality assurance process, software verification and validation process, software configuration management process, and software hazard analysis process. The software verification and validation process includes independent verification and validation, software requirements verification and validation process, software design verification and validation process, code verification and validation process, unit test process, software integration test process, software system test process, software installation test process, and software operation and maintenance verification and validation process. Complete system validation is outside the scope of this document.
This document provides an initial set of topics for functionality of software that should be considered when specifying software for use in a software-intensive system, especially where high integrity attributes are important. This framework discusses software engineering practices that aid in the development and assurance of high integrity software. It provides a basis from which to identify strengths and weaknesses in current software engineering techniques relative to high integrity software and to indicate where further research is needed.
This framework does not address procurement issues directly, that is, it does not describe processes for the acquirer of software. Its focus is deliberately on the technical engineering processes that are used to build software-intensive systems, and includes those processes for assuring the quality of the resulting system. The framework is a composite of many standards, draft standards, technical reports, journal articles and experience. The terminology in these documents is not consistent; for example, the terms developer and producer are often used to refer to those who provide software. A later version of this framework may include a mapping of principal software life cycle terminology to the most common usages found in other related documents.
As an initial document for CHISSA, on which CHISSA may base some of its activities, this framework will undergo substantive change and expansion. Future work in expanding this framework includes, but is not limited to, the following tasks:
Accuracy. A qualitative assessment of correctness, or freedom from error [IEEE610].
CASE (Computer Aided Software Engineering) tools. Software tools that assist with software design, requirements traceability, code generation, testing and other software engineering activities [IEEE610].
Completeness. The degree to which all of the software's required functions and design constraints are present and fully developed in the software requirements, software design, and code [SOFTENG].
Component. One of the parts that make up a system, some of which may be broken down into more components or units; it may be personnel (e.g., operator, user), procedures, materials, tools, equipment (hardware), facilities, and software [IEEE610, MIL882B].
Consistency. The degree of uniformity, standardization, and freedom from contradiction among the documents or parts of a system or component [IEEE610].
Correctness. The degree to which software or its components is free from faults and/or meets specified requirements and/or user needs [IEEE610].
Criticality. The severity of the failure mode.
Debug. To detect, locate, and correct faults in a computer program [IEEE610].
High integrity software. Software that can and must be trusted to work dependably in some critical function, and whose failure to do so may have catastrophic results, such as serious injury, loss of life or property, business failure or breach of security. Some examples include software used in safety systems of nuclear power plants, transportation systems, medical devices, electronic banking, automatic manufacturing, and military systems [NIST204].
Quality attributes. Requirements that software must meet such as usability, efficiency, reliability, maintainability, and portability [NIST4909].
Redundancy. The presence of backup components that perform the same or similar functions as other components [IEEE610].
Risk. A measure derived from the probability of failure occurring and the severity of failure modes.
Software configuration item. An aggregation of software that is treated as a single entity in the software configuration management process [IEEE610].
Software quality assurance. The planned systematic pattern of all actions necessary to provide adequate confidence that the product, or process by which the product is developed, conforms to established requirements [NIST204].
Software verification and validation. See verification and validation.
System. A composite, at any level of complexity, of personnel, procedures, materials, tools, equipment, facilities, and software. The elements of this composite entity are used together in the intended operational or support environment to perform a given task or achieve a specific production, support, or mission requirement [MIL882B].
Testability. The degree to which software or a software component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met [IEEE610].
Test case. A set of test inputs, execution conditions, and expected results developed for a particular objective, e.g., to exercise a particular program path [IEEE610].
Test coverage. The extent to which the test cases test the software requirements [ISO12207].
Test design. The test approach and associated tests [IEEE610].
Test procedure. Detailed instructions for the set-up, execution, and evaluation of results for a given test case [IEEE610].
Understandability. The extent to which the meaning of the software requirements, software design, and code are clear to the reader [SOFTENG].
Unit. A separately compilable piece of code [ISO12207].
Validation. The process of evaluating a system or component (including software) during or at the end of the development process to determine whether it satisfies specified requirements [IEEE610].
Verification. The process of evaluating a system or component (including software) to determine whether the products of a given development process satisfy the requirements imposed at the start of that process [IEEE610].
Verification and validation. The process of determining whether the requirements for a system or component (including software) are complete and correct, the products of each development process fulfill the requirements or conditions imposed by the previous process, and the final system or component (including software) complies with specified requirements [IEEE610].
CASE Computer Aided Software Engineering
CHISSA Center for High Integrity Software Systems Assurance
CI Configuration Item
CSHA Code-level Software Hazard Analysis
DBDD Database Design Description
IV&V Independent Verification and Validation
NRC U.S. Nuclear Regulatory Commission
PM Project Management
PMP Project Management Plan
SCM Software Configuration Management
SCMP Software Configuration Management Plan
SDD Software Design Description
SDHA Software Design Hazard Analysis
SQA Software Quality Assurance
SQAP Software Quality Assurance Plan
SRHA Software Requirements Hazard Analysis
SRS Software Requirements Specification
SV&V Software Verification and Validation
SVVP Software Verification and Validation Plan
SVVR Software Verification and Validation Report
Table of Contents
2.1 Software Requirements Process
2.4 Software Integration Process
2.6 Software Operation and Maintenance Process
2.7 Software Development Process Inputs and Outputs
3.1 Project Management Process
3.2 Software Quality Assurance Process
3.3 Software Verification and Validation Process
3.3.1 Independent Verification
3.3.2 Software Requirements Verification and Validation Process
3.3.3 Software Design Verification and Validation Process
3.3.4 Verification and Validation Process
3.3.6 Software Integration Test Process
3.3.7 Software System Test Process
3.3.8 Software Installation Test Process
3.3.9 Software Operation and Maintenance Verification and Validation Process
3.4 Software Configuration Management Process
3.5 Software Hazard Analysis Process
3.6 Software Assurance Process Inputs and Outputs
4 SOFTWARE ENGINEERING PRACTICES
5.1 Definition of System Service
5.2 Failure Modes, Error Detection and Fault Tolerance
5.2.2 Surveillance of Other System Components
APPENDIX A. BIBLIOGRAPHY OF HIGH INTEGRITY SOFTWARE DOCUMENTS
Tables
Table 2-1. Software Development Process Inputs and Outputs
Table 3-1. Major Processes of SV&V
Table 3-2. Software Assurance Process Inputs and Outputs
Figures
Figure 1-1. Software Development as a Part of System Development
Figure 1-2. Software Assurance Relationship to Software Development
High integrity software (e.g., software which must and can be trusted
to work dependably and whose failure would have catastrophic results
[NIST190]) is a critical factor in all aspects of modern society.
It controls a wide range of essential activities including banking and
commerce, manufacturing, education, transportation, health care, and
entertainment. Currently, the body of knowledge required to build high
integrity software is distributed among standards, guidelines,
technical reports, conference presentations, and information proprietary
to organizations [NIST204]. The National Institute of Standards and
Technology (NIST) has been working for several years on providing
information to government, industry, and academia regarding high
integrity software. Efforts in this area have included development of
guidance on software verification, validation and testing
[e.g., NIST165], hosting a workshop on high integrity software
(proceedings are documented in [NIST190]), and conducting studies on
high integrity standards and guidelines, software quality assurance
documentation and reviews, and software error analysis (results of
these studies are documented in [NIST204], [NIST4909], and [NIST209],
respectively).
NIST recognized the need to develop a single document which
would address developing and assuring high integrity software. This
document provides an initial framework to assist government, industry,
and academia in addressing the issues of providing software for high
integrity software systems. NIST has built a database of standards,
guidelines, technical articles, and books that were used to provide a
basis for the software development and software assurance activities
described in this framework.
This technology independent framework can be used as:
This framework is also an initial starting point on which to initiate
the activities supporting the Center for High Integrity Software
Systems Assurance (CHISSA) established by NIST. CHISSA will foster
and coordinate activities relating to high integrity software
technology. It will help guide research in development, analysis, and
testing techniques, conduct assessments on software system technology,
and provide transfer of those technologies deemed useful to the
industrial sector. CHISSA will work in cooperation with other Federal
agencies, industry, and the research community to develop standards
and guidelines for high integrity software. Issues concerning
the link between software assurance and the systems in which that
software is embedded will be addressed as well.
CHISSA will promote research, development, analysis, testing, and
transition of software system technology which will improve the
development, maintenance, and operation of software based systems.
CHISSA will coordinate activities for:
This framework identifies processes for the primary and concurrent
processes of development and assurance of high integrity software.
The processes and activities occur regardless of the life cycle or
methodologies. Different life cycle approaches (e.g., iteration;
incremental development) may affect the choice of methods for
performing the processes. The choice of technology (e.g.,
object-oriented) may affect how the requirement and design processes
and activities are performed. In both cases, the processes and
activities of this framework are applicable and form the basis for
specific methods. Software development processes are those processes
that are used to construct the software, that is, define the software,
design it, implement the design into software code, and integrate the
software into the system. Their purpose is to build the software,
and make corrections as needed. Each software development process
produces outputs which ultimately lead to the final software product
which is integrated with other system components and is executed in
the installed system.
Software assurance processes are those processes that are used to plan
and manage the software development processes, and some, like the
project management and software quality assurance processes, also
oversee other software assurance processes. Their purpose is to
provide assurance that the software will meet its requirements and
consequently support the system requirements. Software assurance
processes check and analyze the decisions regarding the software and
its relationship to the system, the plans and their implementations,
and they analyze and test the software outputs. Software assurance
processes are an integral part of software development, that is, their
execution occurs concurrently with development processes.
In some instances, software development and assurance processes appear
to be intertwined, (e.g., depending on project organization,
programming and unit test may appear to occur almost simultaneously.)
Yet, the purpose of programming is to build, and the purpose of unit
test is to provide checking. The software assurance processes verify
step by step that each evolving software output is consistent with its
predecessor, and hence meets system requirements. Software assurance
processes provide controls to ensure that verified outputs are not
replaced by other versions. Other processes (e.g., test) are used to
validate that the software meets its requirements. Total validation
against the system requirements must be performed as part of system
development.
This framework treats the software development and software assurance
processes separately to enable better planning and implementation of
the activities supporting these processes. This separation of
processes in this framework is only for the purpose of identifying the
actual activities of each process; all processes contribute to the
quality of the software and may be performed by more than one
organization.
This framework identifies key information about the software and its
relationship to other system components. The equivalent information
for establishing requirements, designing, building, and validating a
system are outside the scope of this document and should be contained
in another, similar document. However, the software development and
software assurance processes must take into account properties and
requirements of the system. Figure 1-1, based on
the system framework of [FUJII1, FUJII2], shows the relationship
between the system and software development processes.
Figure 1-2 shows the
relationship between the software development and software assurance
processes.
The software development and software assurance processes are
iterative. They may also be used to build the resulting system
incrementally, that is, portions of the software are developed
in an evolutionary manner, with each addition increasing the system
capability. These figures accommodate every life cycle methodology;
no matter how software is developed all these processes must be
achieved for high integrity software assurance. Even with rapid
prototyping (where someone defines what is wanted, designs how
to build it, builds some part of it or a skeleton of it, and checks
that things are going as planned), which may take only an hour, all
these processes will have been performed.
The activities of the software development and software assurance
processes are implemented with the methods most appropriate to the
software application domain. Software quality assurance monitors the
usage of methods selected, and all software assurance processes monitor
software outputs for appropriate results.
This framework does not specify which processes are performed by which
organizations or whether or not they must be performed by separate
development and assurance organizations. Definitions for independent
verification and validation (technical, managerial, and financial
independence between the software verification and validation team and
the software development team) are provided.
This framework does not address documentation of the software
development and assurance activities as a separate process. Instead,
each software process addresses recording its activities in documents
such as a software requirements specification or software design
document. [NIST4909] provides more information on what should be
included in each process's document(s). Exactly how documentation
should be provided, for specific application domains, with the use of
modern technology and new development paradigms is itself a major
research topic and hence outside the scope of this framework.
This framework discusses software engineering practices that aid in
the development and assurance of high integrity software. It is not
intended to be a complete representation of accepted software
engineering practices but is a basis for such a representation. It
can be used to identify strengths and weaknesses in current software
engineering techniques relative to high integrity software, and
indicates where further research or improvement is needed.
This framework was originally produced to address activities for
developing software systems where safety is the predominant
issue, which is why the term "hazard" is used. For security
the more fitting term is "threat." A later version of this document
will expand upon computer security activities. One purpose of CHISSA
is to identify technology issues between the software and its system.
This document provides an initial set of topics for functionality of
software that should be considered when specifying software for use in a
software-intensive system, especially where high integrity attributes
are important.
This framework does not address procurement issues directly, that is,
it does not describe processes for the acquirer of software. Its focus
is deliberately on the technical engineering processes that are used to
build software-intensive systems, and includes those processes for
assuring the quality of the resulting system. The framework is a
composite of many standards, draft standards, technical reports,
journal articles and experience. The terminology in these
documents is not consistent; for example, the terms developer
and producer are often used to refer to those who provide
software. A later version of this framework may include a mapping of
principal software life cycle terminology to the most common usages
found in other related documents.
Sections 2 and 3 describe the software development and software
assurance processes, respectively. Section 4 addresses software
engineering practices. Section 5 discusses software functionality for
high integrity software systems. Section 6 provides a summary of this
framework and a recommendation for further research. Section 7
contains references. Appendix A contains a bibliography of the
documents that provided a basis for the processes and activities of
this framework.
The development of high integrity software includes the software
requirements process, software design process, code process, software
integration process, software installation process, and software
operation and maintenance process. These processes inherently include
some software assurance activities (e.g., some analysis, some test),
but the software assurance processes themselves are described in
section 3. This framework does not specify who performs any of
the processes, only what needs to be accomplished.
The software development processes are independent of any specific
life cycle model, and the concepts described in this section can be
applied regardless of life cycle management style. Each process is
not necessarily completed before the next process is started. For
example, the software may be developed incrementally, i.e., a group of
requirements are specified, designed, coded, and tested, and then
another group follows the same pattern. The software development
processes are also iterative. Software requirements may be added,
deleted or altered any time during software development. For example,
a new software requirement may be found to be necessary during the
software design process or after software hazard analysis has been
performed. (Changes in the software requirements or software design may
also necessitate a re-classification of the software criticality level.)
Modifications to the software requirements in turn affect all
subsequent processes. Software assurance processes should be invoked
according to the development processes.
For each software development process, this framework provides inputs
and outputs (see Table 2-1 at the end of this
section for a summary),
the major objective(s) of the process, and activities within the
process. The following documents were used in compiling this section:
[ANS7432], [ANSP7432], [FIPS101], [IEC880], [MIL498], [NIST4909],
[NIST204], [RTCA178B], and [SOFTENG].
The outputs of the software development processes can be represented
in a variety of ways. For example, a software design description may
be a paper document or a graphical representation stored in a computer
aided software engineering (CASE) tool or some combination of text and
graphics, in paper form or CASE tool repository. A user's manual may
actually be part of the software, accessed online using windows and/or
menus. This section does not describe the medium used to represent the
outputs of a software development process, and will hereafter refer
to the representation of the outputs as documentation. This section
only includes the relationship of the documentation to each software
development process.
2.1 Software Requirements Process
The major objectives of the software requirements process are to
fulfill the system and software objectives, develop software
requirements based on, and traceable back to, the system requirements,
and to provide complete, consistent, correct, testable, and
understandable information from which the software may be designed.
This process uses the system requirements (e.g., hardware, mechanical,
user interfaces to software) and system design (including the system
safety assessment (contains system hazard analysis) and the
safety-related and security-related requirements), the initial project
management plan (PMP), and software requirements standards identified
in the software quality assurance plan (SQAP), to develop the
requirements for software. The software requirements encompass
functional, performance, interface, safety, security, and quality
requirements [NIST180]. The software requirements process ends when
its objectives and the objectives of any software assurance processes
performed concurrently with it are met. The software requirements
process produces a software requirements specification (SRS). A
user's manual is also started, but not completed, during this process.
Depending on the PMP, this process and other development and assurance
processes may produce several outputs before completion of a process,
resulting in a final product.
The following are activities of the software requirements process
(software assurance activities listed in section 3 are performed
concurrently with these activities):
The major objectives of the software design process are to develop the
software design based on, and traceable back to, the software
requirements, and to provide complete, consistent, correct, testable,
and understandable information from which the software code may be
generated. This process uses the SRS, the initial PMP, and software
design standards identified in the SQAP to develop the software design.
System documentation is available for reference. The software
design process ends when its objectives and the objectives of any
software assurance processes performed concurrently with it are met.
The software design process produces a software design description
(SDD), a database design description (DBDD), and possibly a revised
SRS and/or updated PMP.
The following are activities of the software design process (software
assurance activities listed in section 3 are performed concurrently
with these activities):
The major objective of the code process is to develop the source code
based on, and traceable back to, the software design and software
requirements. This process uses the SRS, SDD, DBDD, the PMP, and code
standards identified in the SQAP, to develop the code. The code
process ends when its objectives and the objectives of any software
assurance processes performed concurrently with it are met. The code
process produces the source code, a source code manual, and supporting
documentation for source code. While the code process and unit
test process are often associated with each other, the unit test
process is a software assurance process and is described in section
3.3.5.
The following are activities of the code process (software assurance
activities listed in section 3 are performed concurrently with these
activities):
report on any outstanding problems with the source code back to the
software design process
2.4 Software Integration Process
The major objectives of the software integration process are to
produce executable code, and to integrate the executable code into
other software or other system components. This process uses the
source code to integrate software components with other software
components and with the hardware in preparation for installation into
the system. The software integration process ends when its objectives
and the objectives of any software assurance processes performed
concurrently with it are met. The software integration process
produces the executable code and a software installation plan. A
software maintenance manual is started, and a user's manual is
completed during this process. The software integration process
occurs also in accordance with the overall system integration and test
plan which may mean several iterations of this software
integration process until all software components have been integrated
with other system components.
The integration process described in this section pertains to software
and must be coordinated with system integration.
The following are activities of the software integration process
(software assurance activities (especially software integration test
execution) listed in section 3 are performed concurrently with
these activities):
2.5 Software Installation Process
The major objective of the software installation process is to install
the software at each site, and to determine whether the software will
perform as required at all the sites in which it will operate. The
software installation process ends when its objectives and the
objectives of any software assurance processes performed concurrently
with it are met. The software installation process produces a
software installation report, and a software maintenance manual is
completed.
The installation procedures described in this section pertain only to
software and may need to be coordinated with system installation
procedures.
The following are activities of the software installation process
(software assurance activities listed in section 3 are performed
concurrently with these activities):
2.6 Software Operation and Maintenance
Process
The major objective of the software operation and maintenance process
is to ensure that the software meets its requirements throughout its
operation and when modifications are made to it. This process uses the
integrated software, software documentation, and software operation and
maintenance standards to monitor the software throughout its operation,
and modify the software as necessary (e.g., for error correction,
enhancements, changes to operating environment) for every site at which
the software is installed. Essentially, this process will repeat groups
of the preceding processes. The activities below refer to the software
installed at each different site. The software operation and maintenance
process ends when its objectives and the objectives of any software
assurance processes performed concurrently with it are met. The
software operation and maintenance process produces a software
operational procedures manual (if additional information is needed
beyond the user's manual), and supporting documentation for
modifications of the software (e.g., anomaly reports, modification
feasibility reports).
The following are activities of the software operation and maintenance
process (software assurance activities listed in section 3 are performed
concurrently with these activities):
2.7 Software Development Process Inputs and
Outputs
Table 2-1 lists inputs and outputs for each
software development
process. The inputs may be from the system development process,
system assurance process, software development process,
and/or software assurance process. Inputs from each previous process
should be available for use by the current process. The outputs are
only from the software development process. The table
also lists what software development outputs (created during a
preceding software development process) may be modified,
and what software assurance outputs (created during a
preceding software assurance process) may be impacted by
the particular software development process (this mainly includes
changes to software assurance plans; creation of any
software assurance reports is listed in table 2-1). This table is not
intended to show who creates or modifies documentation (e.g., those
personnel performing software development processes may
produce some software assurance documentation).
The software development processes described in section 2 are
accompanied by processes that assure the quality of the software
produced from those processes. These software assurance
processes include project management, software quality assurance,
software verification and validation (includes test), software
configuration management, and software hazard analysis.
Software assurance processes locate problems in the software
development process and their outputs, and provide evidence that the
software complies with its specifications [NIST204].
These processes are separate from but performed concurrently with,
and have a direct impact on, the software development processes. This
framework does not specify who performs the software
assurance processes, only what needs to be accomplished. An
explanation of "independence" is provided in section 3.3.1.
Software assurance processes are separate from, but performed
concurrently with, software development (see fig. 1-1), and can cause
an iteration (see sec. 2) of the software development
processes (which may in turn cause a change in the system requirements
or system design).
Several of the software assurance processes overlap (e.g., some project
management information
may also be addressed in the software quality assurance process),
however, this does not alleviate
the need for all of these software assurance processes. Part of
assurance is monitoring that all the processes are planned and
implemented.
For each software assurance process, this framework provides inputs
and outputs (see Table 3-2 at the end of this
section for a summary),
the major objective(s) of the process, and activities within the
process. The following documents were used in compiling this section:
[ANS7432], [ANSP7432], [BERLACK], [DUNN], [ESA], [FIPS101], [FIPS132],
[FUJII3], [IEEE610], [IEEE1042], [IEEEP1059], [NIST209], [NIST4909],
[NIST204], [NUREG6018], [RTCA178B], [IEC880], [SOFTENG], [THAYER], and
[WALLACE].
3.1 Project Management Process
The major objective of the (software) project management (PM) process
is to establish the organizational structure of the project and assign
responsibilities. This process uses the system requirements
documentation and information about the purpose of the software,
criticality of the software, required deliverables, and available time
and resources, to plan and manage the software development and software
assurance processes. The PM process begins before software
development starts and ends when its objectives have been met. The PM
process overlaps and often reiterates other software assurance
processes. It establishes or approves standards, monitoring and
reporting practices, high-level policy for quality (process improvement
and output quality), and cites regulations. The PM process produces a
project management plan (PMP) which includes references to all other
software assurance documentation.
It is outside the scope of this document to specify who is responsible
for completing each software assurance process. However, one of the
most important functions of the project management process is to ensure
that all software development and software assurance
processes are performed and monitored. This framework does not address
the differences in project management for each type of manager (e.g.,
customer oversight, system project manager, IV&V manager, software
project manager). Instead, this document addresses the
responsibilities of the software project manager; if there is only a
system manager, then the system manager must address the issues for
software project management. Regardless of project organization, the
manager responsible for the software must ensure that all software
processes in development and assurance have been addressed.
The following are activities of the PM process:
Planning
Organizing
Staffing
Leading
Controlling
3.2 Software Quality Assurance Process
The major objectives of the software quality assurance (SQA) process
are to ensure that the software development and software assurance
processes comply with software assurance plans and standards, and to
recommend process improvement. This process uses the system
requirements, and information about the purpose and criticality of the
software to evaluate the outputs of the software development and
software assurance processes. It begins before the
software requirements process and ends when its objectives have been
met. A software quality
assurance plan (SQAP) and review and audit reports are produced during
the SQA process.
The following are activities of the SQA process:
3.3 Software Verification and Validation
Process
The major objective of the software verification and validation (SV&V)
process is to comprehensively analyze and test the software
concurrently with processes of software development and software
maintenance to determine that the software performs its intended
functions correctly, ensure that it performs no unintended functions,
and measure its quality and reliability [NIST165]. SV&V is a detailed
engineering assessment for evaluating how well
the software is meeting its technical requirements, and in particular
its safety, security and reliability objectives and for ensuring that
software requirements are not in conflict with any
standards or requirements applicable to other system components.
There are SV&V
activities to analyze, review, demonstrate or test the outputs of
every software development and maintenance process; these SV&V
activities may directly impact software development processes.
In this framework, the terms software verification and software
validation are used together, i.e., software verification and
validation. Software is verified at the end of each
software development process (or increment of the process) to determine
if the outputs of that software development process meet the
requirements established at the beginning of that software
development process. Validating (or "evaluating," in this framework)
that the software correctly
implements the system requirements for which the software is
responsible is conducted
concurrently with and at the end of all the software development
processes. The SV&V planning and analysis processes are conducted
against system requirements at the highest level
of planning, and then at the software requirements, which may be
traced to the system requirements. Many SV&V processes, such as
planning for software system test, require activities during processes
generally associated with early development. Often, staff who perform
verification of the requirements may be staff who prepare preliminary
plans for software system tests; the development of the test plans and
designs may lead to discovery of requirements errors.
Planning and managing an entire SV&V process requires understanding of
interrelationships among the SV&V activities and the advantage of
applying knowledge from one activity to another. While in some
instances this framework separates out software verification processes
from software validation processes, these may be performed concurrently.
The final, and ultimate, system validation must be planned in
conjunction with test of all system components.
In the recently approved standard for digital computers in safety
systems for nuclear power generating stations [IEEE7432], figure E1
shows the relationship of SV&V activities to other
development activities and describes SV&V in Appendix E. SV&V in this
framework expands on those V&V activities, for detailed software
V&V processes. The SV&V process includes testing but is much more
thorough than testing alone. The intention of the SV&V process is to
ensure the absence of errors and measuring the quality and
reliability of the system, which testing alone does not accomplish
[RTCA178B]. The final goal of the SV&V process is that system
objectives have been attained. This is evident only once system
validation is completed (see fig. 1-1).
Table 3-1 provides a summary of the major
processes of SV&V, as defined
in [FIPS132] and expanded in [WALLACE]. SV&V analyzes the data from
the SV&V processes to assess
the quality and reliability of the software [WALLACE]; many techniques
for performing these analyses are described in [NIST209]. Other
guidance for assessing the reliability of the system
may be found in [MUSA1, MUSA2, BUTLER]. According to [FIPS132] and
[WALLACE], SV&V has some responsibilities during early system processes,
as indicated also by figure E1 in [IEEE7432]. SV&V addresses
verification of the initial project documentation, sometimes
referred to as concept documentation (i.e., system concept, system
requirements, and system design documentation). Activities supporting
this SV&V activity are included for simplicity
in the requirements verification process.
The SV&V process produces a software verification and validation plan
(SVVP), individual plans and reports for activities, summary reports,
anomaly reports, and a final software verification and validation
report (SVVR). Some of the test documentation is prepared in
advance of the test execution. For example, the system test plan for
the software is developed concurrently with the software requirements
process. Different management and technical staff
may be responsible for different types of test (see sec. 3.3.1.).
The major objective of the SV&V process is stated at the beginning
of this section. The activities unique to each sub-process of SV&V are
identified in subsections of section 3, which are based primarily on
[BEIZER], [ESA], [FIPS132], [FUJII3], [IEC880], [IEEEP1059],
[NUREG6018], and [WALLACE]. Details on test documentation are
provided by [FIPS132] and [IEEE829].
3.3.1 Independent Verification and
Validation
Some SV&V processes may be performed by two different groups (or
different individuals within a group) whose objectives and activities
for the process will have some differences, resulting in different
evaluation strategies to demonstrate the objectives. While three
types of independence are described in this framework, assignment of
the processes is a management activity, which may be influenced by
regulation and contract, and is outside the scope of this framework.
The use of a different organization for SV&V is called independent
verification and validation (IV&V). The revision of [IEEE1012] may
include the explanation of IV&V from the chapter on IV&V in [WILEY]
for managerial, technical, and financial independence, as shown in the
remainder of this section.
Technical independence requires that members of the IV&V team
(organization or group) may not be personnel involved in the
development of the software. This team must have some knowledge about
the system design or have related experience and engineering background
enabling them to understand the system. The IV&;V team must not be
influenced by the development team when the IV&V team is learning about
the system, problems encountered, and proposed solutions for building
the system. This technical independence is crucial in the
team's ability to detect the subtle software requirements, software
design and coding errors that escape detection by development testing
and quality assurance reviews.
The technical IV&V team may need to share tools from the computer
support environment (e.g., compilers, assemblers, utilities) but should
execute qualification tests on these tools to ensure that the common
tools themselves do not contain errors which may mask errors in the
software being analyzed and tested. The IV&V team uses or develops its
own set of test and analysis tools separate from the developer's tools
whenever possible.
Managerial independence means the responsibility for IV&V
belongs to an organization outside the contractor and program
organizations that develop the software. While
assurance objectives may be decided by regulations and project
requirements, the IV&V team independently decides the areas of the
software/system to analyze and test, techniques to
conduct the IV&V, schedule of activities (within the framework of the
system schedules), and technical issues to act upon. The IV&V team
provides its findings in a timely fashion
simultaneously to both the development team and the systems management
who acts upon the reported discrepancy and findings.
Financial independence means that control of the IV&V budget is
retained in an organization outside the contractor and program
organization that develop the software. This
independence protects against diversion of funds or adverse financial
pressures or influences that may cause delay or stopping of IV&V
analysis and test activities and timely reporting of
results.
The extent that each of these parameters is vested in the IV&V team's
responsibilities defines the degree of independence achieved. Based on
the definitions of IV&V and how much IV&V a specific project requires,
some SV&V processes may be conducted by both the developer and another
organization. An example may be unit test. Unit test by one
organization may focus on demonstrating that specific objectives have
been met (e.g., safety objectives), which may differ from the objectives
of the developer (e.g., logic structure, test coverage) [IEEEP1059].
3.3.2 Software Requirements Verification and
Validation Process
Verification of the software requirements may also include an
examination of documentation produced earlier in the system life cycle
(e.g., initial feasibility studies, concepts on which the
system has been designed). Inputs to the software requirements
verification and validation process may be documents written in
natural languages, formal mathematical languages, graphics
and charts. When formal mathematical languages are used, other forms
of representations may be provided to different users of the
specifications. In this case, requirements verification must
ensure fidelity between the forms of representation.
The following are activities of the software requirements verification
and validation process:
3.3.3 Software Design Verification and Validation
Process
Software design verification occurs after the software requirements
have undergone the verification process. By verifying that the
software design meets its software requirements, the
software design verification and validation process also supports
validation that the software design meets system requirements, which
was an objective of software requirements verification
and validation. There may be several instantiations of the software
requirements and software design verification before all of the system
is verified.
The following are activities of the software design verification and
validation process:
3.3.4 Code Verification and Validation
Process
Many of the activities to verify correct implementation of software
design into code require tedious checking of details within the code;
automation provides protection against human error
in gathering the code information for analysis and also can speed the
process. Code verification is the last opportunity to find and remove
errors that could cause unnecessary costs and delays
from advancing poor code into any of the test processes.
Code validation is accomplished through unit test which is described in
section 3.3.5.
The following are activities of the code verification process:
Unit test is the test of the software elements at the lowest level of
development. Units may be aggregates of software elements. Planning
for unit test should occur concurrently with the software design
process.
The following are activities of the unit test process:
3.3.6 Software Integration Test Process
Software integration test is performed to examine how units interface
and interact with each other with the assumption that the units and the
objects (e.g., data) they manipulate have all passed
their unit tests [BEIZER]. Software integration tests check how the
units interact with other software (e.g., libraries) and hardware.
The software integration test schedule depends upon the
development and integration schedules for software units, hardware, and
other components. For large systems, software integration test
planning may require intense communication among all
system personnel to ensure that the overall test objectives can be
achieved by the selected test strategy. For each major integration
that has passed interface and interaction tests, functional
tests may be developed and executed [BEIZER]. When all system
components have been integrated and have successfully passed software
integration tests, then the system moves into system test for testing
of the system through the complete system process.
The following are activities of the software integration test process:
3.3.7 Software System Test Process
Software system test, in the context of SV&V, involves the conduct of
tests to execute the completely integrated system. Software system
test is the validation that the software meets its requirements.
Validation of the complete system may involve many tests involving all
system components. The software system tests exercise only those
system functions that invoke software. The perspective is on the
software aspects of the system, and whether the software
behaves as intended relative to complete system performance. These
tests must be conducted in such a manner as to stress and break the
system based on software responses to system inputs
(e.g., from sensors, operators, databases). Tests and data collected
from the tests are designed to provide an operational profile of the
system which support a statistical analysis of the system
reliability [MUSA1, MUSA2, BUTLER]. This section of the framework
addresses only the tests that validate that the software implements the
system requirements; other tests for other components and perspectives
are necessary for complete system validation.
While software system tests are conducted once the system has been
built, it is imperative that planning for these tests is conducted
concurrently with the software requirements process
because:
The following are activities of the software system test process:
3.3.8 Software Installation Test Process
Software installation test is the final step before launching full
customer acceptance testing. The intent of software installation test
is not system validation nor acceptance testing. The purpose
of installation test is only to demonstrate that the correct software
has been delivered and that the software interfaces are correct relative
to any interfaces at the installation site. Acceptance testing, which
involves the user/customer, is outside the scope of this document.
The following are activities of the software installation test process:
3.3.9 Software Operation and Maintenance
Verification and Validation Process
The operation of computer software requires periodic checks that the
integrity of the system has been maintained, that any changes to the
system which affect its operation have been documented and operators
have received training in new or changed procedures.
SV&V of the maintenance of software, (e.g., adaptive, corrective,
perfective [FIPS106]), requires planning for SV&V based on the extent
of the maintenance and hence a revisit of all the software development
processes to identify to what extent each SV&V processes must be
performed.
The following are activities of the software operation and maintenance
verification and validation process:
3.4 Software Configuration Management
Process
The major objectives of the software configuration management (SCM)
process are to track the different versions of the software, and
ensure that each version of the software contains the exact
software outputs generated and approved for that version. It must be
established before software development starts and continues throughout
the software development processes. SCM is responsible for ensuring
that any changes to any software outputs during the development
processes are made in a controlled and complete manner.
The SCM process produces a software configuration management plan
(SCMP). When the software is integrated with system components,
system configuration management begins. However, any changes to the
software necessitates that SCM be invoked.
The following are activities of the SCM process:
Software configuration identification
Problem reporting, tracking and corrective action
Change control
Change review
Traceability analysis
Configuration control
Configuration status accounting
Configuration audits and reviews
Archive, retrieval and release
3.5 Software Hazard Analysis Process
The overall objective of the software hazard analysis process is to
ensure that software hazards and hazards related to interfaces between
the software and the system have either been eliminated
or their risk has been mitigated. This process uses the system
requirements, preliminary hazard list, preliminary hazard analysis,
system hazard analysis, SRS, SDD, DBDD, and safety-related
history of similar systems to identify software hazards and evaluate
the risk of software hazards, and then eliminates or reduces the risk
of the hazards. It begins before the software requirements
process and ends when its objectives have been met. The software
hazard analysis process
produces a software safety plan and documents that report on the
results of the different software hazard analyses (i.e., software
requirements hazard analysis report, software design hazard
analysis report, code-level software hazard analysis report, software
safety testing report, software/user interface analysis report,
software change hazard analysis report).
The following are activities of the software hazard analysis process:
3.6 Software Assurance Process Inputs and
Outputs
Table 3-2 lists inputs and outputs for each
software assurance process.
The inputs may be from the system development process, system assurance
process, software development process, and/or software assurance
process. The outputs are only from the software assurance process.
The table also lists what software assurance outputs (created during a
preceding software assurance process) may be modified, and
what software development outputs (created during a preceding software
development process) may be impacted by the particular
software assurance process. This table is not intended to show who
creates or modifies documentation.
4 SOFTWARE ENGINEERING PRACTICES
Software engineering practices are those techniques recommended either
to prevent errors from being entered into the software during
development, or are properties to be built into high integrity software
[NIST204]. The following is a summary of some software engineering
practices that may enhance the quality of the software.
Formal methods may be used to specify/model the requirements
mathematically. A recent study supports the concept that formal
methods may eliminate ambiguity in the requirements but cannot
ensure completeness. The report suggests that better methods of
technology transfer and better automated support are needed before
formal methods can be widely used [NIST626]. [FUJII]
includes a methodology for describing software specifications in
English. The use of either formal methods or the [FUJII] approach
requires analyzing the completeness and meaning of each requirement.
However, one example in [FUJII] demonstrates that neither method can
eliminate all ambiguity nor prove the completeness of the total set of
requirements. Formal methods can also be used for verifying the
requirements and for design proof of correctness.
Prototyping, simulation, and modeling can be used in developing
software requirements, and in the software design process. The
software requirements process may use simulation and modeling to
determine if it is feasible to build a product to the requirements
[NIST213]. The software design process can use simulation and
modeling to determine the effectiveness of alternative designs
[NIST213]. Rapid prototyping and simulation analysis are useful in the
verification and validation of the software requirements, software
design, and code. The project management process may use simulation
and modeling to perform tradeoff studies of alternative strategies
[NIST213].
The way in which the software is designed contributes greatly to its
quality. Component isolation separates safety critical components
from other components, making analysis of, and changes to, these
components easier to accomplish. Modularity ensures that changes to one
component minimally affect other components. Information hiding
prevents components' actions from interfering with other components.
Redundancy is used to prevent or recover from failures. Interaction
with the operator or user of the software system during the design of
the software/human interface can also be helpful.
Using a software design methodology that is well suited to the software
application is important. Today, new technology is forcing a second
look at design methods, specifically object-oriented design (OOD).
NIST conducted a study of the attributes of OOD relative to
safety-critical software for the United States Nuclear Regulatory
Commission (NRC). The purpose was to describe attributes of OOD
(e.g., classes, encapsulation, inheritance) relative to their capability
for supporting features desired in software for safety systems
(e.g., modularity, functional diversity, traceability, and
non-ambiguity). The results were presented at the NRC/NIST
workshop in September 1993 and published in the workshop proceedings
[NIST216].
The use of high-level languages has also been recommended for quality
software [NIST204]. Using high level, standard languages and their
standards lessens programming errors. Eliminating programming practices
that have been demonstrated to be problematic (e.g., floating point
arithmetic, use of interrupts) simplifies analyzing system behavior.
It is also important to use a language with a thoroughly tested
compiler.
Reverse engineering can aid in developing software requirements,
recreating documentation for preexisting software, and providing a
basis for reusability of software. Re-engineering can be
used to change software design when software requirements change
[NIST213].
There are also software engineering practices that apply to the
software assurance processes. Use of cost-modeling and risk assessment
techniques can aid the project management process. The use of selected
software hazard analysis techniques (e.g., software fault tree analysis,
petri nets) can aid in software assurance by identifying the critical
parts of the software. Inspections, reviews, and audits can be applied
to all software processes under the software quality assurance
process. Software error, measurement, statistical, algorithm, database,
technical, control and data flow, and timing and sizing analysis
techniques are useful in the software verification and
validation process. Test strategies such as equivalence partitioning,
cause-effect, boundary value, stress, event directed, data flow, logic
flow, performance, timing, sizing, random, top-down,
bottom-up, sandwich, statistical testing, functional testing, and
performance testing, when applied appropriately, contribute to the
quality of the software.
While this framework does not address development of the entire system,
information about the system must be provided to the software
development and software assurance teams. This section of the framework
is not complete and is intended only as an overview of aspects about
high integrity software systems that these teams should be provided.
This section was developed in cooperation with SoHaR, Inc.
The software activities are dependent on the system engineering
functions to define requirements in at least the following areas:
For each of the above items both the system requirements and the
specific subset to be implemented in software must be identified.
Other information that must be provided to the software developers
includes description of the external system interfaces, user procedures,
user and maintainer skill levels, safety and security requirements and
any functions designed to mitigate or check for problems during system
operation.
5.1 Definition of System Service
The definition of system service enables the software designer to
provide required software functions. The following are specific items
that apply to high integrity software:
In some high integrity software systems, hardware installation may
provide for redundant channels for specific functions relative to
attributes like safety or security. Software may be required to
validate operational channels, identify faulty channels to the
operators, perform automatic switching between channels to maintain the
system operation after a fault has been diagnosed, and to initiate
alerts when the system is no longer fully functional. These activities
are collectively referred to as surveillance. Sensors are substantial
contributors to the system failure probability, and frequently sensors
have a higher degree of redundancy than other hardware components.
Sensor surveillance is therefore discussed in a separate subsection
below.
Sensors operate under more severe environmental conditions than other
parts of the system. Their output normally contains a noise component--
it can drift, and it is frequently affected by
variations in the power supply. In addition, the sensor can
experience transient or permanent
failure. In analog systems sensor surveillance is a labor intensive
activity that is usually automated (i.e., implemented in software) in
digital systems. The sensor surveillance software typically analyzes
a time series of sensor outputs, extracts a current estimate of the
true value of the sensed quantity from the noisy raw measurements, and
must make decisions about the validity
of the current estimate (i.e., whether the sensor has failed). If a
failure has been identified there
may be further decisions required about the value of the affected
variable that is utilized in the
system, e.g., to minimize sensor switching for transient failures it
can be temporarily held at the
last valid level and the affected sensor sampled again during the next
interval. The design of sensor surveillance software requires
identification of sensor and power supply redundancies, the
preferred sensor configurations, and the following data:
Sensor surveillance normally includes the wiring to the control
components; i.e., a failure in the connection will be treated as a
sensor failure. Where separate surveillance of the wiring is
desired, the software designer will need data that permit a
differentiation between sensor and wiring failures.
5.2.2 Surveillance of Other System
Components
Other system components typically include the computer and output
devices, such as a relay network. In some cases the output interface
includes actuation of control rods or pumps. Surveillance of computer
operation includes at least a self-health check, but it can also include
monitoring of computers in other channels, of analog-to-digital
interfaces, and of intra- and inter-channel communications.
The surveillance of the output devices involves comparison of the
commanded state (as generated within the computer) with the actual
state and reported by an independent measurement. For
relay networks this measurement is usually provided by an auxiliary
contact that operates in synchronism with the main contacts; rod
position can be determined from dedicated sensors, and
pump operation from centrifugal switches or tachometers.
The software designer needs the following data to support required
functionality:
Actions to be avoided fall into two broad categories:
The first category includes actions that may result from failures
outside the computer, such as an erroneous sensor measurement or
inappropriate operator actions (mode changes). Examples are:
Examples of the second category are:
In addition to these requirements that are derived from the system
specification certain actions to be avoided may be established on the
basis of software considerations, e.g., prohibition of certain calling
sequences.
Although some systems are frequently intended to serve functions in
which the human response may be too slow or uncertain, they are not
insulated from interfaces with operators and maintainers. Under
failure-free conditions of these systems the operator initiates mode
changes and monitors plant and system status indications furnished by
the automated system. Under exceptional states of these systems, such
as recovery from a hardware failure, the operator is
responsible for taking corrective action, such as initiating
maintenance. And once the system is
in a maintenance mode, human skill and judgment is required to bring it
back to operation. These essential human interfaces demand that the
software developer be aware of:
To facilitate system test it is frequently desirable to (a) disable or
modify certain software controlled functions, (b) add temporarily
functions normally supplied by the system environment,
and (c) provide indications and records of test progress. If these
requirements are realized at the
outset, patching or other irregular software structures can be avoided.
Requirements for the following functionality should be provided,
associated with the test phases for which they will be activated:
System level attribute requirements must be propagated and interpreted
for the software development. The primary attribute requirements arise
from quality assurance, configuration management, reliability and
availability. Security and portability (ability to operate on multiple
computer types) requirements may also be invoked. In most cases these
requirements must be interpreted for software development, and this
interpretation is a joint system engineering and software engineering
responsibility.
The most stringent requirements are usually intended only for the code
associated with the
activation of a particular safety function (e.g., in a nuclear power
plant, a reactor shut-down). But the extent of that software segment
and the attribute requirements for other segments must be
identified by joint system engineering and software engineering
analysis techniques. Typical topics are:
This framework proposes the activities that comprise software
development and software assurance processes, independent of the
technology used to perform them. Users of the framework may implement
these activities with methods which are most appropriate to the
software application domain.
This document is an initiating activity in support of the Center for
High Integrity Software Systems Assurance (CHISSA), whose purpose is
to foster and coordinate activities relating to
high integrity software technology. High integrity software needs to
be developed and assured in a planned and systematic manner.
Development of this software includes processes for the
software requirements, software design, code, integration of the code,
installation of the software, and the continuing operation and
maintenance of the software.
The development of the software is controlled and monitored by
assurance processes which encompass managing the entire software
project, assuring the quality of the software, verifying
and validating the software against its requirements, managing the
different configurations of the software, and eliminating or mitigating
software hazards.
The processes of software development and assurance are not stand-alone
tasks; information about the system must be provided to the software
team throughout the software development and assurance processes.
Information specific to systems is crucial in developing and assuring
high integrity software; this framework identifies some information for
the system that affects software functionality. This framework does
not address software documentation in detail because the issues of
documentation should be addressed in a separate research project.
This framework will undergo substantive change and expansion. Future
work in expanding this framework includes, but is not limited to, the
following tasks:
[ANS501]
ANSI/ANS-50.1, "(DRAFT #6) Nuclear Safety Design Criteria for Light
Water Reactors," American Nuclear Society, January 1993.
[ANS7432]
ANSI/IEEE-ANS-7-4.3.2-1982, "Application Criteria for Programmable
Digital Computer Systems in Safety Systems of Nuclear Power Generating
Stations," American Nuclear Society, 1982.
[ANSP7432]
P-7-4.3.2, draft 7, "American National Standard - Standard Criteria for
Digital Computers in Safety Systems of Nuclear Power Generating
Stations," Sponsor: Nuclear Power Engineering Committee of the IEEE
Power Engineering Society.
[BEIZER]
Beizer, Boris, Software Testing Techniques, Van Nostrand
Reinhold, New York, 1990.
[BELTRACCHI]
Beltracchi, Leo, "NRC Research Activities," NIST Special Publication
500-216, Proceedings of the Digital Systems Reliability and Nuclear
Safety Workshop (NUREG/CP-0136), U.S. Department of
Commerce/National Institute of Standards and Technology, March 1994.
[BERLACK]
Berlack, Ronald H., "Configuration Management," Encyclopedia of
Software Engineering, Volume 1, John Wiley & Sons, Inc., 1994.
[BUTLER]
Butler, R. and G. Finelli, "The Infeasibility of Experimental
Quantified Life-Critical Software Reliability," Proceedings of
SIGSOFT'91: Software for Critical Systems, Association for
Computing Machinery, December 1991.
[DUNN]
Dunn, Robert H., "Quality Assurance," Encyclopedia of Software
Engineering, Volume 2, John Wiley & Sons, Inc., 1994.
[ESA]
ESA PSS-05-10 Issue 1, "Guide to Software Verification and Validation,"
European Space Agency, February 1994.
[FIPS101]
FIPS 101, "Guideline for Lifecycle Validation, Verification, and
Testing of Computer Software," U.S. Department of Commerce/National
Bureau of Standards (U.S.), 1983 June 6.
[FIPS106]
FIPS 106, "Guideline on Software Maintenance," U. S. Department of
Commerce/National Bureau of Standards (U.S.), 1984 June 15.
[FIPS132]
FIPS 132, "Guideline for Software Verification and Validation Plans,"
U.S. Department of Commerce/National Bureau of Standards (U.S.), 1987
November 19.
[FUJII1]
Fujii, Roger U., "Software Engineering For Instrumentation and Control,"
American Nuclear Society, Nuclear Plan Instrumentation, Control, and
Man-Machine Interface Technologies, Oak Ridge, TN, April 1993.
[FUJII2]
Fujii, Roger U., "How Much Software Verification and Validation is
Adequate for Nuclear Safety?" NIST Special Publication 500-216,
Proceedings of the Digital Systems Reliability and Nuclear Safety
Workshop (NUREG/CP-0136), U.S. Department of Commerce/National
Institute of Standards and Technology, March 1994.
[FUJII3]
Fujii, Roger U., "Independent Verification and Validation,"
Encyclopedia of Software Engineering, Volume 1, John Wiley &
Sons, Inc., 1994.
[IEC880]
IEC 880, "Software for Computers in the Safety Systems of Nuclear Power
Stations," International Electrotechnical Commission, 1986.
[IEEE603]
IEEE Std 603-1980, "IEEE Standard Criteria for Safety Systems for
Nuclear Power Generating Stations," The Institute of Electrical and
Electronics Engineers, Inc., November 24, 1980.
[IEEE610]
ANSI/IEEE Std 610.12-1990, "Glossary of Software Engineering
Terminology," The Institute of Electrical and Electronics Engineers,
Inc., 1990.
[IEEE1012]
ANSI/IEEE Std 1012-1986, "IEEE Standard for Software Verification and
Validation Plans," The Institute of Electrical and Electronics
Engineers, Inc., February 10, 1987.
[IEEE1042]
ANSI/IEEE Std 1042-1987, "IEEE Guide to Software Configuration
Management," The Institute of Electrical and Electronics Engineers,
Inc., March 10, 1988.
[IEEE7432]
ANSI/IEEE Std 7432-1993, "Standard Criteria for Digital Computers in
Safety Systems of Nuclear Power Generating Stations," The Institute of
Electrical and Electronics Engineers, Inc., 1993.
[IEEEP1059]
IEEE Std P1059-1994, "(DRAFT 7.1) IEEE Guide for Software Verification
and Validation Plans," Institute of Electrical and Electronics
Engineers, Inc., May 24, 1993.
[IEEEP1228-H]
P1228, "(DRAFT H) Standard for Software Safety Plans," Institute of
Electrical and Electronics Engineers, Inc., 4/27/92.
[ISO12207]
ISO/IEC DIS 12207-1, "(DRAFT) Information Technology--Software--Part 1:
Software Life Cycle Process," International Electrotechnical Commission,
1994.
[MIL498]
MIL-STD-498, "Software Development and Documentation," Department of
Defense, 30 November 1994.
[MIL882B]
MIL-STD-882B, "System Safety Program Requirements," Department of
Defense, 30 March 1984.
[MUSA1]
Musa, J.D., A. Iannino, and K. Okumoto, Software Reliability,
Measurement, Prediction, Application, McGraw-Hill, New York, 1987.
[MUSA2]
Musa, J.D., and A.F. Ackerman, "Quantifying Software Validation: When
to Stop Testing?" IEEE Software, May 1989.
[NIST165]
NIST Special Publication 500-165, "Software Verification and
Validation: Its Role in Computer Assurance and Its Relationship with
Software Project Management Standards," U.S. Department of
Commerce/National Institute of Standards and Technology, September 1989.
[NIST190]
NIST Special Publication 500-190, "Proceedings of the Workshop on
High Integrity Software; Gaithersburg, MD; Jan. 22-23, 1991,"
U.S. Department of Commerce/National Institute of Standards and
Technology, August 1991.
[NIST204]
NIST Special Publication 500-204, "High Integrity Software Standards
and Guidelines," U.S. Department of Commerce/National Institute of
Standards and Technology, September 1992.
[NIST209]
NIST Special Publication 500-209, "Software Error Analysis," U.S.
Department of Commerce/National Institute of Standards and
Technology, April 1993.
[NIST213]
NIST Special Publication 500-213, "Next Generation Computer Resources: Reference
Model for Project Support Environments (Version 2.0)," U.S. Department of
Commerce/National Institute of Standards and Technology, November 1993.
[NIST216]
NIST Special Publication 500-216, "Proceedings of the Digital Systems
Reliability and Nuclear Safety Workshop (NUREG/CP 0136)," U.S. Department of Commerce/National
Institute of Standards and Technology, March 1994.
[NIST626]
NIST GCR 93/626, "An International Survey of Industrial Applications
of Formal Methods Volume 1 Purpose, Approach, Analysis, and
Conclusions," U.S. Department of Commerce/National Institute of
Standards and Technology, March 1993.
[NIST4909]
NISTIR 4909, "Software Quality Assurance: Documentation and Reviews,"
U.S. Department of Commerce/National Institute of Standards and
Technology, September 1992.
[NUREG6018]
NUREG/CR-6018, "Survey and Assessment of Conventional Software
Verification and Validation Methods," U.S. Nuclear Regulatory Commission, April 1993.
[RTCA178B]
RTCA/DO-178B, "Software Considerations in Airborne Systems and
Equipment Certification," RTCA, Inc., December 16, 1992.
[SOFTENG]
"Standard for Software Engineering of Safety Critical Software," Draft,
Rev. 0, Ontario Hydro, December 1990.
[THAYER]
Thayer, Richard H. and Richard Fairley, "Project Management,"
Encyclopedia of Software Engineering, Volume 2, John Wiley &
Sons, Inc., 1994.
[WALLACE]
Wallace, Dolores R., "Verification and Validation," Encyclopedia of
Software Engineering, Volume 2, John Wiley & Sons, Inc., 1994.
[WILEY]
Encyclopedia of Software Engineering, John Wiley & Sons,
Inc., 1994.
APPENDIX A. BIBLIOGRAPHY OF HIGH INTEGRITY
SOFTWARE DOCUMENTS
1 INTRODUCTION
5.2 Failure Modes, Error Detection and Fault
Tolerance Requirements
6 SUMMARY
AF800-5
AFSC/AFLCP 800-5, "(DRAFT) Software Independent Verification and Validation (IV&V)," Air Force Systems Command and Air Force Logistics Command, 1988.
AF800-45
AF PAMPHLET 800-45, "Software Independent Verification and Validation (IV&V)," Department of the Air Force, 1 May 1991.
AFISC
AFISC SSH 1-1, "Software System Safety," Headquarters Air Force Inspection and Safety Center, 5 September 1985.
ANS103
ANSI/ANS-10.3-199x, (DRAFT 5), "Documentation of Computer Software," American Nuclear Society, 3/7/92.
ANS104
ANSI/ANS-10.4-1987, "Guidelines for the Verification and Validation of Scientific and Engineering Computer Programs for the Nuclear Industry," American Nuclear Society, May 13, 1987.
ANS501
ANSI/ANS-50.1, "(DRAFT #6) Nuclear Safety Design Criteria for Light Water Reactors," American Nuclear Society, January 1993.
ANS7432
ANSI/IEEE-ANS-7-4.3.2-1982, "Application Criteria for Programmable Digital Computer Systems in Safety Systems of Nuclear Power Generating Stations," American Nuclear Society, 1982. AND ANSI/IEEE-ANS-7-4.3.2-19XX, Draft 2, as of November, 1991.
ANSP7432
P-7-4.3.2, draft 7, "American National Standard - Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations," Sponsor: Nuclear Power Engineering Committee of the IEEE Power Engineering Society.
ANSIX99
ANSI X9.9-1986, "Financial Institution Message Authentication (Wholesale)," X9 Secretariat, American Bankers Association, August 15, 1986.
ANSIX917
ANSI X9.17-1985, "Financial Institution Key Management (Wholesale)," X9 Secretariat, American Bankers Association, April 4, 1985.
AQAP13
AQAP-13, "NATO Software Quality Control System Requirements," NATO, August 1991.
ASMENQA1
ASME NQA-1-1989, "Quality Assurance Program Requirements for Nuclear Facilities," The American Society of Mechanical Engineers, September 15, 1989.
ASMENQA2
ASME NQA-2a-1990, "Quality Assurance Requirements for Nuclear Facility Applications," The American Society of Mechanical Engineers, November 1990.
ASMENQA3
ASME NQA-3-1989, "Quality Assurance Program Requirements for the Collection of Scientific and Technical Information for Site Characterization of High-Level Nuclear Waste Repositories," The American Society of Mechanical Engineers, March 23, 1990.
ASMESUPP
Supplement 17S-1, ASME NQA-1-1989, "Supplementary Requirements for Quality Assurance Records," The American Society of Mechanical Engineers.
ASQCA3
ANSI/ASQC A3-1987, "Quality Systems Terminology," American Society or Quality Control, 1987.
BOEING
"(DRAFT) BA&E (Boeing Aerospace and Electronics) System Safety Instruction - System Safety Engineering in Software Development," The Boeing Company, 11/11/89.
BSI89
"89/97714-Guide to the Assessment of Reliability of Systems Containing Software," British Standards Institution, 12 September 1989.
CATEGORY
"Guideline for the Categorization of Software in Ontario Hydro's Nuclear Facilities with respect to Nuclear Safety," Revision 0, Nuclear Safety Department, June 1991.
CENSUS
"Programming Standards and Guidelines Manual," Bureau of the Census, March 27, 1991.
CSA89
CAN/CSA-Q396.1.2-89, "Quality Assurance Program for Previous Developed Software Used in Critical Applications," Canadian Standards Association, January 1989.
CSC003
CSC-STD-003-85, "Computer Security Requirements--Guidance for Applying the Department of Defense Trusted Computer System Evaluation Criteria in Specific Environments," Department of Defense, 25 June 1985.
DLP880
DLP880, "(DRAFT) Proposed Standard for Software for Computers in the Safety Systems of Nuclear Power Stations (based on IEC Standard 880)," David L. Parnas, Queen's University, Kingston, Ontario, March, 1991.
DOD2167A
DOD-STD-2167A, "Defense System Software Development," Department of Defense, 29 February 1988.
DOT86
"Criteria and Procedures for Testing, Evaluating, and Certifying Message Authentication Devices for Federal E.F.T. Use," United States Department of the Treasury, September 1, 1986.
ESA
ESA PSS-05-10, Issue 1, "Guide to Software Verification and Validation," European Space Agency, February 1994. with ESA Guide to the Software Engineering Standards
FAA026
FAA-STD-026, "National Airspace System (NAS) Software Development," U.S. Department of Transportation, Federal Aviation Administration, March 31, 1989.
FDA89
"(DRAFT) Reviewer Guidance for Computer-Controlled Devices," Medical Device Industry Computer Software Committee, January 1989.
FDA91
"Reviewer Guidance for Computer-Controlled Medical Devices Undergoing 510(k) Review," Office of Device Evaluation, Center for Devices and Radiological Health, Food and Drug Administration.
FIPS74
FIPS PUB 74, "Guidelines for Implementing and Using the NBS Data Encryption Standard," U.S. Department of Commerce/National Bureau of Standards (U.S.), 1981 April 1.
FIPS81
FIPS PUB 81, "DES Modes of Operation," U.S. Department of Commerce/National Bureau of Standards (U.S.), 1980 December 2.
FIPS101
FIPS PUB 101, "Guideline for Lifecycle Validation, Verification, and Testing of Computer Software," U.S. Department of Commerce/National Bureau of Standards (U.S.), 1983 June 6.
FIPS106
FIPS 106, "Guideline on Software Maintenance," U. S. Department of Commerce/National Bureau of Standards (U.S.), 1984 June 15.
FIPS132
FIPS PUB 132, "Guideline for Software Verification and Validation Plans," U.S. Department of Commerce/National Bureau of Standards (U.S.), 1987 November 19.
FIPS140
FIPS PUB 140 FS 1027, "General Security Requirements for Equipment Using the Data Encryption Standard," General Services Administration, April 14, 1982.
FIPS461
FIPS 46-1, "Data Encryption Standard," U.S. Department of Commerce/National Bureau of Standards (U.S.), 1988 January 22.
FIPS1401
FIPS 140-1, "Security Requirements for Cryptographic Modules," U.S. Department of Commerce/National Institute of Standards and Technology, 1990 May 2.
IEC880
IEC 880, "Software for Computers in the Safety Systems of Nuclear Power Stations," International Electrotechnical Commission, 1986.
IEC9126
ISO/IEC 9126, "Information Technology--Software Product Evaluation--Quality Characteristics and Guidelines for their Use," International Electrotechnical Commission, 1991-12-15.
IECSUPP
45A/WG-A3(Secretary)42, "(DRAFT) Software for Computers Important to Safety for Nuclear Power Plants as a Supplement to IEC Publication 880," International Electrotechnical Commission Technical Committee: Nuclear Instrumentation, Sub-Committee 45A: Reactor Instrumentation, Working Group A3: Data Transmission and Processing Systems, May 1991.
IECSUPP-94
45A/WG-A3(Secretary)48, "(DRAFT) Nuclear Power Plants - Instrumentation and Control Systems Important to Safety - First Supplement to IEC Publication IEC 880," IEC SC45A, May 1994.
IECTC56
IEC/TC56, "89/97714 - (DRAFT) Guide to the Assessment of Reliability of Systems Containing Software," British Standards Institution, 12 September 1989.
IECWG9'89
