The
definitions and general criteria contain their source; if a modification has
been necessary it is indicated. If no source is given this is a new definition
for this project.
The following definitions are taken from accepted and identified sources to
help in the understanding of terms used in the prepared documentation. A
thorough understanding of their meaning will facilitate the use of the Project
Management System.
"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."
VIRTUAL
REAL WORLDS Defines a new way of
perceiving the world.
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 system.
Access. A users ability to
communicate with a system.
Acquirer. An organization that procures products for itself or another
organization.
Acquisition programme.
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 acquirer..
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 other criteria.
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.
Project baselines:
1. Design Requirements
Baseline (DRB). The DRB defines the essential program design requirements for technical
System, and is contained in the System Specification, etc.
2. Development
Component 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.
3. Production Baseline
(PBBS). The PBBS defines the physical and functional characteristics of the
production technical System. The identification documentation includes
definition of:
Baselines
(System, CSCI and HWCI).
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.
Build
and Design Standards.
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 development strategy.
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 Procedure.
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 management. (MIL-STD-498)
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 interrupts, etc.
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
Baseline.
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:
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 effectively, including:
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 more tests.
"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:
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)
Development 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.
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
Engineering 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 system design.
End-item. A deliverable item which is formally accepted by the acquirer in
accordance with requirements of a detail specification.
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 Technical review.
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 function.
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 the acquirer.
Integrated logistics support
(ILS). A disciplined, unified and
iterative approach to management and technical activities necessary to:
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 them.
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:
Clear
lines of communication and timely dissemination of changes to these documents
shall be maintained.
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 review.
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 item.
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 "Unit" previously.
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.
NDIs include:
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:
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 the contract.
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 identified.
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 computer databases.
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.
Software 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.
Software 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.)
Software development process. An organized set of
activities performed to translate user needs into software products.
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.
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.
Software management group. A group of
specialists who establish, maintain, and improve the software management
process used during software development.
Software Project 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 projects.
Software system. A system consisting solely of
software and possibly the computer equipment on which the software operates.
Software technical authority. The part of the
developing contractors organization which is responsible for the design and
development of computer software configuration items.
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
products.
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 obtained.
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:
System - A combination of
the hardware, software, and firmware.
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:
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 configuration.
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 products.
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 specification, Prime Item Development Specification, or a Critical Item Development Specification.
Tailoring. The tailoring of requirements is the responsibility of the acquirer
(customer), suggested tailoring may be provided by prospective and selected
developers (prior to contract agreement).
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