- - Development Terms
This is probably one of the most under observed process in
software. But one that can cause confusion, misguidance, and
misunderstandings with in all phases of the life cycle. I hope these
definitions will help your teams understand each other with a bit more
"Terminology is a key factor in
ensuring a common understanding of the engineering effort to be accomplished.
Terms used throughout the prepared documentation shall have the same meaning as
the terms used in this glossary."
| Z ]
- Acceptance. An action by an authorized
representative of the acquirer by which the acquirer assumes ownership of
products as a partial or complete performance of contract.
- Acceptance criteria. The criteria a product
must meet to successfully complete a test phase or meet delivery requirements.
- Acceptance test. Formal
testing conducted to determine whether or not a system satisfies its acceptance
criteria and to enable the acquirer to determine whether or not to accept the
- Access. A users
ability to communicate with a system.
- Acquirer. An organization that
procures products for itself or another organization.
A directed, funded effort
designed to provide a new, improved, or continuing system in response to a
validated operational need.
- Approval. Written notification by
an authorized representative of the acquirer that the developers 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.
- Approved data. That issue
or version of data which has been identified by the developer/supplier as being
the master issue or version of data subject to configuration management which has
been submitted for acquirer approval, and which has been approved by the
Architecture. The organizational structure of a
system HWCI, or CSCI, identifying its components, their interfaces, and a
concept of execution among them.
- Article. The Prime system or
equipment being acquired under a contract.
- Assembly. A number of parts or
subassemblies or any combination thereof joined together to perform a specific
function and capable of disassembly (for example: fan assembly.
- ATLAS Test Specification. An ATLAS test
specification is dedicated to defining the test requirements for the
Unit-Under-Test in a manner which is independent of the test equipment used for
its implementation. It is derived from the System/Subsystem Specification or
CIDS/PIDS and shall contain the absolute values of the functional design
performance parameters. The actual implementation may use manual test
equipment, automatic test equipment, or a combination of both. The
Acceptance Test Procedure
shall be derived from this specification suitably
adjusted to remove the uncertainties of the target test equipment being used.
- Audit. An independent
examination of a work product/process or set of work products/processes to
assess compliance with specifications, standards, contractual agreements, or
- Authentication. The
procedure (essentially approval) used by the approval authority in verifying
that specification content is acceptable. Authentication does not imply
acceptance or responsibility for the specified item to perform successfully.
- Baseline. A Baseline is a
Configuration Identification formally designated and applicable at a specific
point in an items life cycle. Baselines, plus approved changes from those
baselines, constitute the current configuration identification. A Configuration
identification document or a set of such documents formally designated by the
acquirer (Customer) at a specific time during a CI life cycle.
Baseline (DRB). The DRB defines the
essential program design requirements for technical System, and is contained in
the System Specification, etc.
Baseline (DCB). The DCB defines the
Functional, Physical and Interface characteristics of the component items of an
assembly or system. It shall be applied throughout the design and development
phase and consist of Project definition Drawings and the Development
Specifications relating to Hardware, and Software.
(PBBS). The PBBS defines the physical
and functional characteristics of the production technical System. The
identification documentation includes definition of:
the essential physical and functional characteristics of the
approved tests for product acceptance (PAS).
parts list, MRI identified by codification requirements (usually
referred to as the Build Standard).
- Baselines (System, CSCI and HWCI).
Functional baseline. The
initial approved functional configuration identification (documentation)
for each CSCI and HWCI which describe a system or items functional
characteristics and the verification required to demonstrate the
achievement of those specified functional characteristics, for example,
System specifications, Prime or critical item specifications,.
Allocated baseline. The
initial approved allocated configuration identification (documentation)
for each CSCI and HWCI functional and interface characteristics allocated
from those of a higher level CI, and interface requirements with
interfacing configuration items, additional design constraints and the
verification required to demonstrate the achievement of those specified
functional and interface characteristics.
Product baseline. The
initial approved product configuration identification (documentation) for
each CSCI and HWCI. The documentation shall describe all of the necessary
functional and physical characteristics of the CI, any required joint and
combined operations, interoperability characteristics of a CI and the
selected functional and physical characteristics designated for production
acceptance testing and tests necessary for support of the CI.
- 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
- Build and Design Standards.
Baseline Build Standard. Part
of the Production Baseline, defining the manufacture drawing issues and
equipment part numbers, including Hardware and Software identified by
Functional Design/Build Standard. A system to define and retrieve information in
respect of the functional characteristics of a system/item and its
influence on other systems/items when it is changed.
Design Standard. The
definition of what is to be built, as defined by approved drawings, etc.,
and subsequent approved changes.
Build Standard. The
incorporated Hardware/Software standards (product baseline) of the
specific System, as confirmed by Quality Assurance.
Design Build Standard. Incorporating
both the Design and the build Standards, records the design requirements
and the embodiment status.
- Build. (1) A
version of software that meets a specified subset of the requirements that the
completed software will meet. (2) The period of time during which such a
version is developed.
Note: The relationship to the terms 'build' and 'version' is basically up to
the developer; for example, it may take several versions to reach a build, a
build may be released in several parallel versions (such as different sites),
or the terms may be used as synonyms.
- build strategy. see
Capability. A group of related requirements; the word capability may be
replaced with 'function', 'subject', 'object' or other term useful for
presenting the requirements.
- Capability Maturity Model (CMM) - A description of the stages through which software
organizations evolve as they define, implement, measure, control and improve
their software processes. The model is a guide for selecting the process
improvement strategies by facilitating the determination of current process
capabilities and identification of the issues most critical to software quality
and process improvement. [SEI/CMU-93-TR-25]
- Certification. A process,
which may be incremental, by which a contractor provides evidence to the
acquirer that a product meets contractual or otherwise specified requirements.
- Change proposal. The formal
documentation that is prepared for a proposed change in accordance with the CMP
- Change request. The formal
documentation that is prepared for a request to change a specification in
accordance with the CMP Change Procedure.
- Commercial off-the-shelf (COTS)
software. Commercially available applications sold by Vendors
through public catalogue listings, COTS software is not intended to be
customerised or enhanced. Contract-negotiated software developed for a specific
application is not COTS software.
- Components. Components
are the named "pieces" of design and/or actual entities (subsystems,
HWCIs, CSCIs, software units) of the system/subsystem/CSCI. In system/subsystem
architectures, components consist of subsystems (or other variations), HWCIs,
CSCIs, and manual operations.
- Components/equipment. Reparable assemblies
which currently require repair parts support or will require it when introduced
into an inventory.
- Computer database.
see database .
- 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.
- Computer program. A
combination of computer instructions and data definitions that enable computer
hardware to perform computational or control functions.
- Computer software.
See software .
- Computer software component (CSC). A
functionally or logically distinct part of a computer software configuration
item. Computer software components may be top-level or low-level.
(DOD-STD-2167A) - now referred to as software units by MIL-STD-498.
- Computer software
configuration item (CSCI). A software item which is identified for
configuration management. (MIL-STD-973) or, An aggregation of software that
satisfies an end use function and designated for separate configuration
- Concept of execution. Represents
the dynamic relationships of the components. It can include such descriptions
as flow of execution control, data flow, dynamically controlled sequencing,
state transition diagrams, timing diagrams, priorities among units, handling of
- Configuration. The
functional and/or physical characteristics of hardware/software as set forth in
technical documentation and achieved in a product. (MIL-STD-973)
- Configuration control. The
systematic evaluation, co-ordination, approval or disapproval and dissemination
of proposed changes and implementation of all approved changes in the
configuration of any item after formal establishment of its configuration
- Configuration control board. A board
composed of technical and administrative representatives who approve or
disapprove proposed engineering changes to an approved baseline.
- Configuration documentation. Configuration
documentation is the sum of all the documents that define the physical and
functional characteristics of a System, subsystem, CSCI, HWCI or designated
equipment, for example, specifications, design documents, engineering drawings,
source code listings.
- Configuration elements. Specifications,
drawings, source code, etc., that define the configuration of a CSCI.
- Configuration identification. The
current approved or conditionally approved technical documentation for a configuration
item as set forth in specifications, drawings, and associated lists, and
documents referenced therein. (MIL-STD-973)
- Configuration item (CI). A configuration item is
an aggregation of hardware or software that satisfies an
end use function
and is designated by the acquirer for separate
configuration management. (MIL-STD-973)
- Configuration management (CM). A
discipline applying technical and administrative direction and surveillance to:
identify and document the functional and physical characteristics
audit the CIs to verify conformance to specifications, interface
control documents and other contract requirements;
control changes to CIs and their related documentation; and
record and report information needed to manage CIs effectively,
including the status of proposed changes and the implementation status of
- Configuration management plan. The
configuration management plan defines the implementation (including policies and
methods) of configuration Management on a particular program/project. To be
known as the Configuration Management Plan (CMP).
- Configuration status accounting. The
recording and reporting of information needed to manage configuration
a listing of the approved configuration identification;
the status of proposed changes, deviations, and waivers to the
the implementation status of approved changes, and;
the configuration all units of the CI in the operational inventory.
- Contract. A mutually
binding legal relationship obligating the seller to furnish the supplies or
services (including construction) and the buyer to pay for them. It includes
all types of commitments that obligate the acquirer to an expenditure of appropriate
funds and that, except otherwise authorized, are in writing. In addition to
bilateral agreements, contracts include, but are not limited to, awards and
notices of awards; job orders or task letter issued under purchase orders,
under which the contract becomes effective by written acceptance or
performance; and bilateral modifications.
- Contract Data Requirements List. That
portion of a contract that identifies deliverable data products
- Contractor. An
individual, partnership, company, corporation, association or other service,
having a contract with an acquirer for the design, development, manufacture,
maintenance, modification, or supply of items under the terms of a contract.
- Covers. .A product
"covers" a given set of items if every item in the set has been dealt
with in the specific product. The set could comprise of system, subsystem,
hardware, or software items or a combination. For example, a plan covers the
SOW if every provision in the SOW is dealt with in the 'Systems Engineering
Management Plan' and supporting specialty plans; a design covers a set of
requirements of every requirement has been dealt with in the design; a test
plan covers a set of requirements if every requirement is the subject of one or
"Covers" corresponds to the downward traceability (for example, from
requirements to design) in the requirement, design, and test
planning/description example model texts.
- Customers. Users and
suppliers of systems and end-items.
- Data. Recorded information,
regardless of medium or characteristics, of any nature, including
administrative, managerial, financial, and technical.
- Data Item Description. (DID) A completed document
that defines the data required of a supplier (contractor). The document
specifically defines the data content, format, and intended use. Note: DIDs can
be known as "Model Texts", "Proformas", etc. by other
organizations. See MIL-STD-963B for preparation details.
- Data Product. Information
which is inherently generated as the result of work tasks cited in a Statement
of Work (SOW) or in a Source Document invoked in the contract. Such information
is as a separate entity (for example, drawing, specification, manual, report,
records, and parts list).
- 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.
- 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.
- Data Recorded Information. regardless
of medium or characteristics, of any nature, including administrative,
managerial, financial, and technical.
- Deficiencies. Deficiencies
consist of two types:
conditions or characteristics in any hardware or software which
are not in compliance with the specified configuration identification; or
inadequate (or erroneous) configuration identification which has
resulted, or may result, in CIs that do not fulfil approved operational
- Deficiencies are corrected by Class II
methods of change control or revisions with "change bars".
- Design. Those
characteristics of a system or CSCI that are selected by the developer in
response to the requirements, such as definitions of all error messages, others
will be implementation related, such as decisions about what software units and
logic to use to satisfy the requirements.
For a more detailed discussion
Definition of Design
- Design authority. An
organization responsible for the detailed design of materiel to approved
specifications and authorized to sign certificates of design or certified
sealed drawings in accordance with procedures identified in the Program
‘Configuration Management Plan’.
- Design completeness. The design
shall be complete from a total system element viewpoint (hardware, facilities,
personnel, computer software, procedural data).
- Design records. Design
records refers to all technical documentation necessary to define the design,
manufacture, packaging, testing, installation, and maintenance of the system
and its comprising elements.
- Design review.
see Technical reviews.
- Design simplicity. The concept
of design simplicity and standardization shall be evident.
- Developer. An organization that
develops products ("develops" may include new development,
modification, reuse, reengineering, maintenance, or any other activity that
results in products) for itself or another organization.
- Developmental configuration. The
contractor's design and associated technical documentation that defines the
evolving configuration of a configuration item under development. It is under the
developing contractor's configuration control and describes the design
definition and implementation. The developmental configuration for a
configuration item consists of the contractors released hardware and software
designs and associated technical engineering documentation until establishment
of the formal product baseline. (MIL-STD-973)
specifications. Development specifications are generally required to
define the allocated (HWCI and CSCI) requirements.
Prime and Critical Items will be developed from PI/CI development
specifications. The CSCI requirements contained in a 'Software Requirements
Specification' when necessary. (see 'documentation standard' for an example.
- Development strategy. There are three basic
development strategies and a generic 'other' which defines the variations,
combinations of the other three.
Grand design - is essentially a right-first-time approach;
Incremental - identifies user needs, defines system requirements
and performs the remaining software development in a sequence of builds.
The first build contains part of the planned capabilities and so on until
the system is complete.
Evolutionary - Development in builds but differs from incremental
in that the system requirements need not be defined up front, but refined
in each succeeding build.
- Deviations. A specific written
authorization, granted prior to the manufacture of a Configuration Item, to
depart from a particular performance or design requirement of a specification,
drawing or other document for a specific number of units or a specific period
of time. A deviation differs from an engineering change in that an approved
change requires a corresponding revision of the documentation defining, the
affected item, whereas a deviation does not contemplate revision of the
applicable specification or drawing.
- Distribution statement. A
statement used in marking a technical document to denote the extent of its
availability for distribution release, and disclosure without the need for
additional approvals and authorizations from the controlling agency.
- Documentation. The concept of minimum
documentation shall be evident. Where possible stipulated plans, reports, and
other data items shall be used to record the engineering outputs. The
repository of this accumulated data shall be defined. Engineering data shall be
the sole source of performance requirements used in the design and production
of the system. Documentation may reside on electronic media.
- Documented procedure. A written
description of a course of action to be taken to perform a given task.
- Domain. The part
of the external world, including users and inmates of the system that effects
and is affected by the system.
- Drawings. A drawing
is the means of conveying information and in this context includes all item
lists, drawing lists, etc., in connection with a drawing or group of drawings.
types of drawings
management. The management of the engineering and technical effort
to transform a conceptual requirement into an operational system. It includes
the system performance parameters and preferred system configuration to satisfy
the requirement, the planning and control of technical program tasks,
integration of the engineering specialties, and the management of a totally
integrated effort of design engineering, computer software engineering, test
engineering, safety engineering, security engineering, logistics engineering,
production engineering, and specialty engineering (EMC, environmental, etc.,)
to meet cost, technical performance and schedule objectives.
- Note: 'Engineering Management' is sometimes
identified by various institutions and organizations as; 'Program(me)
management', 'Quality Management', 'Quality Plan', 'Quality system', 'Project
Management', 'Quality assurance', or any combination of the above terms. These
are to be considered synonymous with the term 'Engineering Management'.
- Engineering specialty
integration. The timely and appropriate intermeshing of
engineering efforts and disciplines such as reliability, maintainability,
logistics engineering, human factors, safety, value engineering, computer
software, standardization, transportability, etc., to insure their influence on
- End-item. A deliverable item
which is formally accepted by the acquirer in accordance with requirements of a
- Engineering decision traceability. Significant
engineering decisions shall be traceable to the system engineering process
activities on which they were based.
- Evaluation. The
process of determining whether an item or activity meets specified criteria.
- Firmware. The combination
of hardware device and computer instructions and/or computer data that resides
as read-only software on the hardware device.
- Fit. The
ability of an item to physically interface or interconnect with or become an
integral part of another item.
- Form. The
defined configuration of an item including the geometrically measured
configuration, density, and weight or other visual parameters which uniquely
characterize an item, component or assembly. For software, form denotes the
language, language level and media.
- Format. Documents
shall be prepared on A4 (210 x 297 mm) 80 gsm copier paper (hard copy) and/or
the form of electronic media specified in the requirements. Each page of a
document shall be numbered in Arabic numerals consecutively from Section 1 to
the appendices. Documents may be printed on one or both sides of each page
(single sided or double sided). On single sided documents the document control
number shall be on the top right hand side. For double sided all even pages
shall have document control numbers on the top left hand side and on odd pages
on the top right hand side. Each page prior to Section 1 shall be numbered in
lower-case roman numerals.
- Formal testing. The
process of conducting testing activities and reporting results in accordance
with an approved test plan making provision for customer involvement.
- Formal review. see
- Function. The action
or actions which an item is designed to perform.
- Functional area. A distinct
group of system performance requirements which, together with all other such
groupings forms the next lower-level breakdown of the system on the basis of
- Hardware. Articles
made of material, such as aircraft, ships, tools, computers, vehicles,
fittings, and their components (mechanical, electrical, electronic, hydraulic, pneumatic).
Computer software and technical documentation are excluded.
- Hardware configuration
item (HWCI). An aggregation of hardware that satisfies
an end use function and is designated for separate configuration management by
- Integrated logistics
support (ILS). A disciplined, unified and iterative
approach to management and technical activities necessary to:
integrate support considerations into system and equipment design;
develop support requirements that are related consistently to design,
readiness objectives and to each other;
acquire required support; and
provide required support during the operational phase at minimum
- Interface. The functional and
physical characteristics required to exist at a common boundary. In development,
a relationship among two or more entities (such as CSCI-CSCI, CSCI-HWCI,
HWCI-HWCI, HWCI-User, CSCI-User, or software unit to software unit) in which
the entities share, provide, or exchange data. An interface is not a CSCI,
HWCI, software unit, or other system component; it is a relationship among
- Interface control. Interface
control comprises the delineation of the procedures and documentation, both
administrative and technical, contractually necessary for identification of
functional and physical characteristics between two or more configuration items
which are provided by different contractors/acquiring agencies, and the
resolution of the problems thereto.
- Interface design compatibility. Intra-system
and intersystem design compatibility of engineering interfaces shall be
delineated as interface requirements in appropriate specifications. Interface
control requirements and drawings related to:
the major system elements of a prime contractor's contractual
other equipment, computer software, facilities, and procedural
data furnished by the acquirer;
other program participants, shall be co-ordinated, established and
- Clear lines of communication and timely dissemination
of changes to these documents shall be maintained.
- Internal consistency.
No two statements contradict one another;
Any term, acronym, or abbreviation shall mean the same throughout
An item or concept is referred to by the same name or description
throughout the document.
- Item. A
non-specific term used to denote any product, including systems, subsystems,
assemblies, subassemblies, units, sets, accessories, computer programs,
computer software or parts.
- Joint review. See Technical
- Life cycle. A generic
term covering all phases of acquisition, operation, and logistics support of an
item, beginning with concept definition and continuing through disposal of the
- Limited rights. Rights to
use, duplicate, or disclose technical data, in whole or in part, by or for the
acquirer, with the express limitation that such data shall not without written
permission of the party asserting limited rights, be: released or disclosed.
- Lowest Replaceable Item. The lowest
level component at which maintenance will be performed or discrete
configuration control enforced. Note: Sometimes lowest is known as the
"smallest" or "Line" and "Item" was termed
- Major review. - A formal
demonstration and confirmation across the system that supports or constitutes a
program milestone event.
- Materiel. A generic term
covering systems, equipment, stores, supplies and spares, including related
documentation, manuals, computer hardware and software.
- Memorandum of agreement.
The document which
specifies agreements between involved parties relative to a specific
interface. The MOA delineates responsibilities of each organization and
identifies formats and data elements required for a successful interface.
- Metrics. - Measures
used to indicate progress or achievement.
- Milestone - A scheduled event for which some individual is
accountable and that is used to measure progress. [SEI/CMU-93-TR-25]
- Multidisciplinary teamwork. - The
timely and cooperative application of all appropriate disciplines in an
open-communication, shared-information environment to effect people functioning
as a team to achieve optimum solutions (people, product, and process) satisfy
customer needs, objectives, and requirements.
Note: does not imply physically together.
- Module. A self-contained part
of a hardware item designed as a single replaceable unit, with a specific
integral electronic function. It should require no installation other than
mechanical mounting and completion of electrical connectors.
- Non-conformance. The
failure of a unit or product to conform to specified requirements.
- Non-developmental item. Non-developmental
item is a broad generic term that covers material available from a wide variety
of sources with little or no developmental effort by the purchaser.
Items obtained from a domestic or commercial marketplace;
Items already developed and in use by users;
Items already developed to other standards and in agreement with
- Organization. A unit
within a company or other entity (e.g., Government agency or branch of service)
within which many projects are managed as a whole. All projects within an
organization share a common top-level manager and common policies.
- Original. The
current design activity document or digital data file(s) of a record.
- Part. One piece, or two or
more pieces joined together which are not normally subjected to disassembly
without destruction or impairment of designed use (examples: gear, screws,
transistors, capacitors, integrated circuits.
- Part or Identifying Number. (PIN) Part
or Identifying Number is an alpha-numeric designator which identifies parts,
items, or bulk materials that are covered by a specification.
- Performance. - A
quantitative measure characterizing a physical or functional attribute relating
to the execution of a mission/operation or function.
- Policy. A guiding principle,
typically established by senior management, which is adopted by an organization
or project to influence and determine decisions.
- Product. A product is a given
set of items. The set could comprise of system, subsystem, hardware, or
software items and their documentation.
Procedure. A series
of activities carried out to accomplish a task or operation.
- Process. An
organized set of activities.
- Program. .An undertaking
requiring concerted effort, which is focused on developing and/or maintaining a
specific product. The product may include hardware, software, and other
components. Typically a project has its own funding cost accounting, and delivery
schedule with the acquirer (Customer). (‘Programme’ is used the UK for
this definition; to distinguish between a computer program)
- Program manager. The role
at a high enough level in an organization that the primary focus is the
long-term vitality of the organization, rather than the short-term project and
contractual concerns and pressures. In general, a senior manager for
engineering would have responsibility for multiple projects.
- Qualification testing. Testing
performed to demonstrate to the acquirer that a CSCI, HWCI, system or subsystem
meets its specified requirements.
- Quality assurance. A planned
and systematic pattern of all actions necessary to provide adequate confidence
that management and technical planning and controls are adequate to:
Establish correct technical requirements for design and
Manage and design activity standards, drawings, specifications, or
other documents referenced on drawings, lists, or technical documents.
- Record. Throughout
the PMS, the requirements to "record" information are interpreted to
mean "set down in a manner that can be retrieved and viewed." The
result can take many forms including, but not limited to, hand-written notes,
hard-copy, or electronic documents, and data recorded in computer-aided
software engineering (CASE) and project management tools.
- 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), recommendation (analyzing a system and producing user and support
documentation), forward engineering (using software products derived from an
existing system, together with new requirements, to produce a new system), and
translation (transforming source code from one language to another or from one
version of a language to another).
- Referenced documents. Management and design
activity standards, drawings, specifications, or other documents referenced on
drawings, or lists, or other technical documents.
- Requirement. (1) A
characteristic that a system, HWCI or CSCI must possess in order to be acceptable
to the acquirer. (2) A mandatory statement in a standard or another portion of
- Requirements. Characteristics
that identify the accomplishment levels needed to achieve specific objectives
for a given set of conditions
- Responsiveness to change. Changes to
system and program requirements in response to directed changes by the
procuring activity, or problem solutions identified shall be evaluated for
total program impact with respect to performance, cost, and schedules.
- Risk management. An organized process
to identify what can go wrong, to quantify and access associated risks, and to
implement/control the appropriate approach for preventing or handling each risk
- Safety. The
expectation that a system does not, under defined conditions lead to a state in
which human life is endangered. (Scope of safety can be expanded for specific
program in the "System Safety Program Plan".
- Section. Section shall be
interpreted as meaning the top paragraph and all its subparagraphs.
- Software. Computer programs and
computer databases. Note: Although some definitions of software include
documentation, it is now limited to the definition of computer programs and
- Software development. A set of
activities that results in software products. Software development may include
new development, modification, reuse, re-engineering, maintenance, or any other
activities that result in software products.
development plan. A description of the planned tasks and activities to be used by
the subcontractor/developer to implement the required CSCI development
programme. This description includes
organizational responsibilities, resources, methods of accomplishment,
milestones, depth of effort, and integration with other programme engineering
and management activities and related systems.
safety program plan. A description of the planned tasks and activities to be used by
the subcontractor/developer to implement the required software (CSCI) safety
programme. This description includes
organizational responsibilities, resources, methods of accomplishment,
milestones, depth of effort, and integration with other project engineering and
management activities and related subsystems and components.
Software Product - The complete set, or any of the individual items of
the set, of computer programs, procedures, and associated documentation and
data designated for delivery to a customer or end user. [IEEE-STD-610] (See
software work product for contrast.)
process. An organized set of activities performed to translate
user needs into software products.
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.
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
management group. A group of specialists who establish, maintain, and
improve the software management process used during software development.
Manager - The role with total
responsibility for all the software activities for a project (CSCI). The
Software Project Manager is the individual the Program Manager deals with in
terms of software commitments and who controls all the software resources for a
project. The Software Project Manager may have the responsibility for multiple
Software system. A system consisting
solely of software and possibly the computer equipment on which the software
technical authority. The part of the developing contractors organization
which is responsible for the design and development of computer software configuration
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. (MIL-STD-498)
- Source Document. A document that is
applied in a solicitation or contract and establishes a data requirement which
requires a DID to define the format, content, and intended use.
- Specification. A document
intended primarily for use in procurement, which describes the essential
technical requirements for items, materiels or services including the
procedures for determining whether or not the requirements have been met.
- Standard - Mandatory requirements employed and enforced to
prescribe a disciplined uniform approach to software development, that is,
mandatory conventions and practices are in fact standards. [IEEE-STD-610]
- Statement of Work (SOW). A document primarily
for use in procurement, which specifies the work requirements for a project or
program. It is used in conjunction with specifications and standards as a basis
for a contract. The
SOW will be used to determine
whether the contractor meets stated performance requirements.
- Status accounting. The process of
documenting the correct, approved status of the system, including a historical
record of the development of CIs and all approved changes.
- Style. Term used
to denote differences in design or appearance.
- Subcontractor. an individual,
partnership, corporation, or an association that contracts with an organization
(i.e., the prime contractor) to design, develop, and/or manufacture one or more
- Suppliers. . the term 'suppliers'
includes contractors, sub-contractors, vendors, developers, sellers or any
other term used to identify the source from which products or services are
- Synthesis. The
translation of input requirements (including performance, function, and
interface) into possible solutions (resources and techniques) satisfying those
inputs. Defines a physical architecture of people, product and process
solutions for logical groupings of requirements (performance, functions, and
interface) and their designs for those solutions.
Subsystem. An element of a system that, in itself may
constitute a system.
- System. .A composite of
equipment, skills, and techniques capable of performing or supporting an
operational role or both. A complete system includes all equipment, related
facilities, material, software, services and personnel required for its
operation and support to the degree that it can be considered a self-sufficient
item in its intended operational environment.
- The term "system" as used by the
Project Management System" (PMS) may mean:
a hardware-software system (for example, a technical system or
comprising subsystem consisting of hardware (HWCI) and software (CSCI)
e.g., Replaceable units, prime items, etc., );
a software system (for example a database);
a hardware system (does not contain a software element).
- System - A combination of the hardware, software, and
- System design authority. .The part of the
developing contractors organization which is responsible for the overall design
of the CIs under development.
- System elements. - A system
element is a balanced solution to a functional requirement or a set of
functional requirements and must satisfy the performance requirements of the
associated item. A system element is part of the system (hardware, software,
facilities, personnel, data, material, services, and techniques) that,
individually or in combination, satisfies a function (task) the system must
perform. Systems engineering. .Systems engineering is
the application of scientific and engineering effort to:
Transform an operational need into a description of system
performance parameters and a system configuration through the use of an
iterative process; for example, definition, syntheses, analysis, design,
test and evaluation, etc.;
Integrate related technical parameters and assure compatibility of
all physical, functional, and program interfaces in a manner which
optimizes the total system definition and design, and;
Integrate reliability, maintainability, safety, human, and other
such factors into the total engineering effort.
- Systems engineering group. The
collection of departments, managers, and staff who have responsibility for
specifying the system requirements allocating the system requirements to the
hardware and software components specifying the interfaces between the hardware
and software components, and monitoring the design and development of these
components to ensure conformance with their specifications.
- Systems engineering management process. A logical
sequence of activities and decisions transforming an operational need into a
description of system performance parameters and a preferred system
- Systems engineering
management process group. A group of specialists who facilitate the definition,
maintenance, and improvement of the systems engineering process used by the
organization. In the key practices, this group is generically referred to as
"the group responsible for the organization's systems and software
engineering process activities".
- Systems security
engineering. An element of system engineering that applies
scientific and engineering principles to identify security vulnerabilities and
minimize or contain risks associated with these vulnerabilities. It uses
mathematical, physical, and related scientific disciplines, and principles and
methods of engineering design and analysis to specify, predict, and evaluate
the vulnerability of the system to security threats.
- Subcontractor. An individual
partnership, corporation. or an association that contracts with an organization
(i.e., the prime contractor) to design, develop and/or manufacture one or more
- System Requirement - A condition or capability that must be met or
possessed by a system or system component to satisfy a condition or capability needed
by a user to solve a problem. [IEEE-STD-610]
- Systems specification. A system level
requirements specification. A system specification may be a System/subsystem
Item Development Specification, or a
Critical Item Development
- Tailoring. The tailoring of
requirements is the responsibility of the acquirer (customer), suggested
tailoring may be provided by prospective and selected developers (prior to
- Target standard. The target
design standards for prototype Systems, toward which work during the
development phase is directed in regard to prototypes.
- Task - (1) A sequence of instructions treated as a basic
unit of work. [IEEE-STD-610] (2) A well-defined unit of work in the software
process that provides management with a visible checkpoint into the status of
the project. Tasks have readiness criteria (preconditions) and completion
criteria (postconditions). (See activity for contrast.) [SEI/CMU-93-TR-25]
- Team - A collection of people, often drawn from diverse
but related groups, assigned to perform a well-defined function for an
organization or a project. Team members may be part-time participants of the
team and have other primary responsibilities. [SEI/CMU-93-TR-25]
- Technical data. Recorded
information, regardless of medium or characteristics, of a scientific or
technical nature. It may, for example document research, experimental,
developmental, or engineering work; or be usable or used to define a design or
process or to acquire, support, maintain, or operate materiel. Technical data
does not include computer software or financial, administrative, cost and
pricing, and management data, or other information incidental to contract
- Technical data package. A
collection of product related engineering data comprised of the Engineering
Drawing Package (EDP) and non-EDP data related to the design and manufacture of
the item or system. The EDP contains all the descriptive documentation needed
to ensure the competitive re-procurement of an item or system. The non-EDP
consists of data such as system and development specifications, product
specifications, concurrent repair list packaging data sheets, special
production tool data, acceptance inspection, equipment data, project standards,
repair manuals, supplementary quality assurance provisions, preparation for
delivery requirements and other data as required.
- Technical effort. - A
technical effort is any activity that influences system performance by
defining, designing, or executing a task, requirement, or procedure. All the
activities required to implement and execute the systems engineering process
are technical efforts.
- Technical (Formal) reviews. A series of system
engineering activities by which the technical progress on a project is assessed
relative to its technical or contractual requirements. The formal reviews are
conducted at logical transition points in the development effort to identify
and correct problems resulting from the work completed thus far before the
problem can disrupt or delay the technical progress. The reviews provide a
method for the contractor and procuring activity to determine that the
development of a CI and its identification have met contract requirements.
on design reviews for more
(Specific details regarding the review process are contained in MIL-STD-1521B).
- Now usually referred to as ‘Joint Technical
and Management Reviews’ as defined by MIL-STD-498; see “Joint Technical and
Management Reviews Process” document for a standardized approach.
- Technical objectives. Technical
objectives shall be established for each program so that meaningful
relationships among need, urgency, risks, and worth can be established.
- Technology. Specification
requirements shall be delineated in light of acceptable technological risks
defined by risk assessment.
- Technical performance
measurement. The continuing prediction and demonstration of the
degree of anticipated or actual achievement of selected technical objectives.
It includes an analysis of any differences among the "achievement to
date", "current estimate", and the specification requirement.
"Achievement to date" is the value of a technical parameter estimated
or measured in a particular test and/or analysis. "Current Estimate"
is the value of a technical parameter predicted to be achieved at the end of
the contract within existing resources.
- Technical program planning and control. The management
of those design, development, test, and evaluation tasks required to progress
from an operational need to the deployment and operation of the system by the
- Technique. A method
of performing an analysis.
evidence of an association between items, such as between process outputs,
between an output and its originating process, or between a requirement and its
- Trade-off Study. An
objective evaluation of alternative requirements, architectures, design
approaches, or solutions using identical ground rules and criteria.
- Testable. A
requirement or set of requirements is considered to be testable if an objective
and feasible test can be designed to determine whether each requirement has
- Test data. Recorded
information, regardless of the form or method of the recording, of a scientific
or technical nature. The term includes computer software or data incidental to
contractual administration, and usually does not include financial and/or
stimulus, measurement, power, loads and any special test equipment or procedure
essential to validate proper operation of a device or some predetermined design
control or product specification definition.
- Unclassified. Not attracting a
security classification but control may be required for other reasons.
Therefore official information of a unclassified nature should not be disclosed
without formal departmental/program approval.
- Under ministry control (UK). The point when the responsibility
for authorizing changes to a design, defined as modifications, is transferred
to a government controlled committee.
- User. the
organization(s) or persons within those organization(s) who will operate and/or
use the system for its intended purpose.
- Validation. The process of
determining that the requirements are the correct requirements and that they
are complete. The system life cycle process may use requirements that are
derived requirements in system validation.
- Vendor. A
manufacturer or supplier of an item.
- Verification. The process of
determining whether or not the products of a given phase of the system/software
life cycle fulfils the requirements established during the preceding phase.
- Verification function. Tasks,
actions, and activities to be performed to evaluate progress and effectiveness
of the evolving system (people, product, and process) solutions and to measure
compliance with requirements. Analysis, (including simulation) demonstration,
test, and inspection are verification approaches used to evaluate; risk;
people, product, and process capabilities, compliance with requirements; and
proof of concept.
- Version. An identified and
documented body of software. Modifications to a version of software (resulting
in a new version) require configuration management actions by the supplier,
acquirer or his agent, or both.
- Waiver. A written authorization
to accept a configuration item, which during production of after having been
submitted for inspection, is found to depart from specified requirements, but
nevertheless is considered suitable for use "as is" or after re-work
by an approved method.
breakdown structure. (WBS) A product-oriented listing, in family tree
order, of the hardware, software, services and other work tasks which
completely defines a product or program. The listing results from project
engineering during the development and production of a materiel item. A WBS
relates the elements of work to be accomplished to each other and to the end