3. DEFINITIONS

Note: In addition to the definitions provided here, Section 1 describes MIL-STD-498's interpretation or special usage of the following terms: acquirer, contract, Contract Data Requirements List, define, develop, developer, establish, identify, participate, record, software development, Statement of Work, subcontractor, subsystem, and system.

3.1 Acceptance.

An action by an authorized representative of the acquirer by which the acquirer assumes ownership of software products as partial or complete performance of a contract.

3.2 Acquirer.

An organization that procures software products for itself or another organization.

3.3 Approval.

Written notification by an authorized representative of the acquirer that a developer's plans, design, or other aspects of the project appear to be sound and can be used as the basis for further work. Such approval does not shift responsibility from the developer to meet contractual requirements.

3.4 Architecture.

The organizational structure of a system or CSCI, identifying its components, their interfaces, and a concept of execution among them.

3.5 Associate developer.

An organization that is neither prime contractor nor subcontractor to the developer, but who has a development role on the same or related system or project.

3.6 Behavioral design.

The design of how an overall system or CSCI will behave, from a user's point of view, in meeting its requirements, ignoring the internal implementation of the system or CSCI. This design contrasts with architectural design, which identifies the internal components of the system or CSCI, and with the detailed design of those components.

3.7 Build.

3.8 Computer database.

See database.

3.9 Computer hardware.

Devices capable of accepting and storing computer data, executing a systematic sequence of operations on computer data, or producing control outputs. Such devices can perform substantial interpretation, computation, communication, control, or other logical functions.

3.10 Computer program.

A combination of computer instructions and data definitions that enable computer hardware to perform computational or control functions.

3.11 Computer software.

See software.

3.12 Computer Software Configuration Item (CSCI).

An aggregation of software that satisfies an end use function and is designated for separate configuration management by the acquirer. CSCIs are selected based on tradeoffs among software function, size, host or target computers, developer, support concept, plans for reuse, criticality, interface considerations, need to be separately documented and controlled, and other factors.

3.13 Configuration Item.

An aggregation of hardware, software, or both that satisfies an end use function and is designated for separate configuration management by the acquirer.

3.14 Database.

A collection of related data stored in one or more computerized files in a manner that can be accessed by users or computer programs via a database management system.

3.15 Database management system.

An integrated set of computer programs that provide the capabilities needed to establish, modify, make available, and maintain the integrity of a database.

3.16 Deliverable software product.

A software product that is required by the contract to be delivered to the acquirer or other designated recipient.

3.17 Design.

Those characteristics of a system or CSCI that are selected by the developer in response to the requirements. Some will match the requirements; others will be elaborations of requirements, such as definitions of all error messages in response to a requirement to display error messages; others will be implementation related, such as decisions about what software units and logic to use to satisfy the requirements.

3.18 Developer.

An organization that develops software products ("develops" may include new development, modification, reuse, reengineering, maintenance, or any other activity that results in software products). The developer may be a contractor or a Government agency.

3.19 Document/documentation.

A collection of data, regardless of the medium on which it is recorded, that generally has permanence and can be read by humans or machines.

3.20 Evaluation.

The process of determining whether an item or activity meets specified criteria.

3.21 Firmware.

The combination of a hardware device and computer instructions and/or computer data that reside as readonly software on the hardware device.

3.22 Hardware Configuration Item (HWCI).

An aggregation of hardware that satisfies an end use function and is designated for separate configuration management by the acquirer.

3.23 Independent verification and validation (IV&V).

Systematic evaluation of software products and activities by an agency that is not responsible for developing the product or performing the activity being evaluated. IV&V is not within the scope of this standard.

3.24 Interface.

In software development, a relationship among two or more entities (such as CSCI-CSCI, CSCI-HWCI, CSCI-user, or software unit-software unit) in which the entities share, provide, or exchange data. An interface is not a CSCI, software unit, or other system component; it is a relationship among them.

3.25 Joint review.

A process or meeting involving representatives of both the acquirer and the developer, during which project status, software products, and/or project issues are examined and discussed.

3.26 Non-deliverable software product.

A software product that is not required by the contract to be delivered to the acquirer or other designated recipient.

3.27 Process.

An organized set of activities performed for a given purpose; for example, the software development process.

3.28 Qualification testing.

Testing performed to demonstrate to the acquirer that a CSCI or a system meets its specified requirements.

3.29 Reengineering.

The process of examining and altering an existing system to reconstitute it in a new form. May include reverse engineering (analyzing a system and producing a representation at a higher level of abstraction, such as design from code), restructuring (transforming a system from one representation to another at the same level of abstraction), redocumentation (analyzing a system and producing user or support documentation), forward engineering (using software products derived from an existing system, together with new requirements, to produce a new system), retargeting (transforming a system to install it on a different target system), and translation (transforming source code from one language to another or from one version of a language to another).

3.30 Requirement.

3.31 Reusable software product.

A software product developed for one use but having other uses, or one developed specifically to be usable on multiple projects or in multiple roles on one project. Examples include, but are not limited to, commercial off-the-shelf software products, acquirer-furnished software products, software products in reuse libraries, and pre-existing developer software products. Each use may include all or part of the software product and may involve its modification. This term can be applied to any software product (for example, requirements, architectures, etc.), not just to software itself.

3.32 Software.

Computer programs and computer databases. Note: Although some definitions of software include documentation, MIL-STD-498 limits the definition to computer programs and computer databases in accordance with Defense Federal Acquisition Regulation Supplement 227.401.

3.33 Software development.

A set of activities that results in software products. Software development may include new development, modification, reuse, reengineering, maintenance, or any other activities that result in software products.

3.34 Software development file (SDF).

A repository for material pertinent to the development of a particular body of software. Contents typically include (either directly or by reference) considerations, rationale, and constraints related to requirements analysis, design, and implementation; developer-internal test information; and schedule and status information.

3.35 Software development library (SDL).

A controlled collection of software, documentation, other intermediate and final software products, and associated tools and procedures used to facilitate the orderly development and subsequent support of software.

3.36 Software development process.

An organized set of activities performed to translate user needs into software products.

3.37 Software engineering.

In general usage, a synonym for software development. As used in this standard, a subset of software development consisting of all activities except qualification testing. The standard makes this distinction for the sole purpose of giving separate names to the software engineering and software test environments.

3.38 Software engineering environment.

The facilities, hardware, software, firmware, procedures, and documentation needed to perform software engineering. Elements may include but are not limited to computer-aided software engineering (CASE) tools, compilers, assemblers, linkers, loaders, operating systems, debuggers, simulators, emulators, documentation tools, and database management systems.

3.39 Software product.

Software or associated information created, modified, or incorporated to satisfy a contract. Examples include plans, requirements, design, code, databases, test information, and manuals.

3.40 Software quality.

The ability of software to satisfy its specified requirements.

3.41 Software support.

The set of activities that takes place to ensure that software installed for operational use continues to perform as intended and fulfill its intended role in system operation. Software support includes software maintenance, aid to users, and related activities.

3.42 Software system.

A system consisting solely of software and possibly the computer equipment on which the software operates.

3.43 Software test environment.

The facilities, hardware, software, firmware, procedures, and documentation needed to perform qualification, and possibly other, testing of software. Elements may include but are not limited to simulators, code analyzers, test case generators, and path analyzers, and may also include elements used in the software engineering environment.

3.44 Software transition.

The set of activities that enables responsibility for software development to pass from one organization, usually the organization that performs initial software development, to another, usually the organization that will perform software support.

3.45 Software unit.

An element in the design of a CSCI; for example, a major subdivision of a CSCI, a component of that subdivision, a class, object, module, function, routine, or database. Software units may occur at different levels of a hierarchy and may consist of other software units. Software units in the design may or may not have a one-to-one relationship with the code and data entities (routines, procedures, databases, data files, etc.) that implement them or with the computer files containing those entities.

3.46 Support (of software).

See software support.

3.47 Transition (of software).

See software transition.

3.48 Definitions of acronyms used in this standard.

See Appendix A.


Translator: Simon Wright simon@pogner.demon.co.uk
Last updated: 22.iii.99