Software Development Terms

Testdog.com

A Quality Assurance Information Site.

		Skills \| Templates & Checklists \| Terminology Web Links \| Papers & Presentations \| Books \| Periodicals

Testdog.com - - 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 clarity.

Bugs, Defects, Etc. Development Terms Engineering Terms Testing Terms SDLC Terms

"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."

[ A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | 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 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:
the essential physical and functional characteristics of the specific System;
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 components.
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 codification requirements.
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 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:
identify and document the functional and physical characteristics of CIs;
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 approved changes.
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:
a listing of the approved configuration identification;
the status of proposed changes, deviations, and waivers to the configuration;
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 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:
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 requirements.
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.
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
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:
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 cost.
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:
the major system elements of a prime contractor's contractual responsibility;
other equipment, computer software, facilities, and procedural data furnished by the acquirer;
other program participants, shall be co-ordinated, established and maintained (MIL-STD-483A).
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 the document;
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 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:
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 the purchaser.
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 manufacturing;
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 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:
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 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:
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 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 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 administration.
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.
See Discussion on design reviews for more information.
(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 user.
Technique. A method of performing an analysis.
Traceability. The evidence of an association between items, such as between process outputs, between an output and its originating process, or between a requirement and its implementation.
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 been met.
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 management information.
Test requirement. The 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.
Work 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 product.