Terms & Definitions

The following is a list of open architecture-related terms and definitions. While this list is extensive, it is not all inclusive. For further information on OA- and acquisition-related terms and definitions, please click the following link to consult Subpart 202.1, "Definitions," of the Defense Federal Acquisition Regulations Supplement (DFARS).

Click this link to download an easy-to-print PDF version of the terms & definitions.

Open Architecture Terms & Definitions

Please Note: The definitions of the following terms are included as guidance for the Preparer and were compiled from the sources indicated in brackets and italics following each definition and were provided in this appendix for the user’s convenience.  It is not intended to be authoritative or comprehensive.  For the definitions of additional terms or clarification of these definitions, please refer to the Defense Federal Acquisition Regulation Supplement (DFARS) and other source documents.

“Activity” is set of actions which, taken as a whole, transform inputs into outputs.  [IEEE/EIA Std. 12207/1997]

“APP233/ISO 10303” – APP233 an “Application Protocol” for Systems Engineering that is based on the ISO 10303 Standard.  AP233 is specific to Systems Engineering, but its purpose, like all of the 10303 standards, is to allow data exchange of SE models between tools -- it does not limit what “language” the tools use to represent a system.  Neither is it meant to be a human-readable language, so using it directly for "tool neutrality" is not likely to work.  ISO 10303 “is an International Standard for the computer-interpretable representation and exchange of industrial product data. The objective is to provide a mechanism that is capable of describing product data throughout the life cycle of a product, independent from any particular system. The nature of this description makes it suitable not only for neutral file exchange, but also as a basis for implementing and sharing product databases and archiving.” [Source is Wikipedia].

“Architecture” means the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.  [Institute of Electrical and Electronics Engineers (IEEE) Std 1471-2000]

“Commercial component” means any component that is a commercial item. [FAR §2.101(b)]

“Commercial item” means:

(1) Any item, other than real property, that is of a type customarily used by the general public or by non-governmental entities for purposes other than Governmental purposes, and:

(i) Has been sold, leased, or licensed to the general public; or

(ii) Has been offered for sale, lease, or license to the general public;

(2) Any item that evolved from an item described in paragraph (1) of this definition through advances in technology or performance and that is not yet available in the commercial marketplace, but will be available in the commercial marketplace in time to satisfy the delivery requirements under a Government solicitation;

(3) Any item that would satisfy a criterion expressed in paragraphs (1) or (2) of this definition, but for:

(i) Modifications of a type customarily available in the commercial marketplace; or

(ii) Minor modifications of a type not customarily available in the commercial marketplace made to meet Federal Government requirements.  Minor modifications mean modifications that do not significantly alter the nongovernmental function or essential physical characteristics of an item or component, or change the purpose of a process.  Factors to be considered in determining whether a modification is minor include the value and size of the modification and the comparative value and size of the final product.  Dollar values and percentages may be used as guideposts, but are not conclusive evidence that a modification is minor;

(4) Any combination of items meeting the requirements of paragraphs (1), (2), (3), or (5) of this definition that are of a type customarily combined and sold in combination to the general public;

(5) Installation services, maintenance services, repair services, training services, and other services if:

(i) Such services are procured for support of an item referred to in paragraph (1), (2), (3), or (4) of this definition, regardless of whether such services are provided by the same source or at the same time as the item; and

(ii) The source of such services provides similar services contemporaneously to the general public under terms and conditions similar to those offered to the Federal Government;

(6) Services of a type offered and sold competitively in substantial quantities in the commercial marketplace based on established catalog or market prices for specific tasks performed or specific outcomes to be achieved and under standard commercial terms and conditions. This does not include services that are sold based on hourly rates without an established catalog or market price for a specific service performed or a specific outcome to be achieved. For purposes of these services—

(i) “Catalog price” means a price included in a catalog, price list, schedule, or other form that is regularly maintained by the manufacturer or vendor, is either published or otherwise available for inspection by customers, and states prices at which sales are currently, or were last, made to a significant number of buyers constituting the general public; and

(ii) “Market prices” means current prices that are established in the course of ordinary trade between buyers and sellers free to bargain and that can be substantiated through competition or from sources independent of the Offerors.

(7) Any item, combination of items, or service referred to in paragraphs (1) through (6) of this definition, notwithstanding the fact that the item, combination of items, or service is transferred between or among separate divisions, subsidiaries, or affiliates of a contractor; or

(8) A non-developmental item, if the procuring agency determines the item was developed exclusively at private expense and sold in substantial quantities, on a competitive basis, to multiple State and local governments.  [FAR Part 2.101(b)]

“Commercial Off-the-Shelf (COTS)” or “commercially available off-the-shelf item” means an item that—

(A) is a commercial item (as described in section 403 (12)(A) of this title);

(B) is sold in substantial quantities in the commercial marketplace; and

(C) is offered to the Government, without modification, in the same form in which it is

sold in the commercial marketplace. [FAR Part 2.101(b)]

“Component” is one of the parts that make up a system.  A component may be hardware or software and may be subdivided into other components. [IEEE Std 610.12-1990]

“Community of Interest (COI)” means a collaborative group of users that must exchange information in pursuit of its shared goals, interests, missions, or business processes, and therefore must have shared vocabulary for the information it exchanges.  [DoD 8320-2]

“Design Disclosure” means making data related to the design of a component, sub-system or system available to qualified recipients, with a goal of establishing and maintaining a process that will provide “early and often” design disclosure directly to the Government or to third-party contractors via Government-established access and the ability to download artifacts.  This data is sufficient to allow the third-party to develop and produce a competitive alternative.  Design Disclosure can be enabled through a variety of mechanisms including keeping data, code and design artifacts in a repository either maintained by or overseen by the Government such as the Navy’s SHARE Repository or made available through the Forge.mil Program (http://www.forge.mil/); providing the artifacts electronically upon requests made via the Government; or allowing requesting parties to obtain them directly from the source firm through a process involving review and approval from the Government.  In addition, the Government can require that contractors allow the program to have continuous, real-time visibility and access to the development environment with access and the ability to download artifacts.  Each program has the flexibility to establish the most appropriate mechanism for their specific needs; with a goal of establishing a process that is both cost-effective and responsive to requests.

“Enterprise Architecture” represents the enterprise's key business, information, application, and technology strategies/trends and their impact on business functions and processes.

[Virginia Information Technologies Agency]

“Evolving Architecture” are software development architectures that adopts changing customer needs and rapidly developing technologies. [Carnegie Mellon University]

“Firmware” denote the fixed, usually rather small, programs and/or data structures that internally control various electronic devices.  [Wikipedia]

“Government Purpose Rights” (GPR) means the rights to—

(i) Use, modify, reproduce, release, perform, display, or disclose intellectual and technical data within the Government without restriction; and

(ii) Release or disclose intellectual and technical data outside the Government and authorize persons to whom release or disclosure has been made to use, modify, reproduce, release, perform, display, or disclose that data for United States Government Purposes.

[DFARS §252.227-7013(a)(12)]

“Government Purpose” means any activity in which the United States Government is a party, including cooperative agreements with international or multi-national defense organizations, or sales or transfers by the United States Government to foreign governments or international organizations. Government purposes include competitive procurement, but do not include the rights to use, modify, reproduce, release, perform, display, or disclose IP and technical data for commercial purposes or authorize others to do so.  [DFARS §252.227-7013(a)(11)]

Note: In order for a software/technical data asset to be a viable Reuse Candidate, the Government must have at least Government Purpose Rights in the asset.

“Information Assurance” is information operations that protect and defend information and information systems by ensuring their availability, integrity, authentication, confidentiality, and non-repudiation. This includes providing for the restoration of information systems by incorporating protection, detection, and reaction capabilities.  [CJCSI 3170.01E]  Information Assurance compliance requirements are contained in CJCSI 3170.01E and PEO-specified requirements.

“Integrated Product Team” is a group composed of representatives from appropriate functional disciplines working together to build successful programs, identify and resolve issues, and make sound and timely recommendations to facilitate decision making. There are three types of IPTs:  1) Overarching IPTs (OIPTs) that focus on strategic guidance, program assessment, and issue resolution; 2) Working-level IPTs (WIPTs) that identify and resolve program issues, determine program status, and seek opportunities for acquisition reform; and, 3) Program-level IPTs (PIPTs) that focus on program execution and may include representatives from both Government and after contract award industry. [DAU Glossary of Defense Acquisition Acronyms and Terms, 13th Edition]

“Integrated Architecture” consists of multiple views or perspectives (Operational View (OV), Systems View (SV), Technical Standards View (TV) and All View (AV)) that facilitate integration and promote interoperability across capabilities and among related integrated architectures. [DoDAF]

“Integrated Digital Environment” implies an environment of connected knowledge workers, in which the preferred approach to performing work involves instantaneously accessing the required resources to accomplish the necessary tasks and then outputting the results into an instantaneously accessible form. Information sharing is rewarded, and redundant data development, transmission or storage is frowned upon. The goal of developing an IDE is intended to improve current and future overall operational performance.

DoD policy requires the maximum use of digital operations throughout the system life cycle.  The program IDE is part of the larger DoD IDE.  It should keep pace with evolving automation technologies and provide ready access to anyone with a need-to-know, as determined by the program manager.

Program managers should establish a data management system within the IDE that allows every activity involved with the program to cost-effectively create, store, access, manipulate, and exchange digital data.  This includes, at minimum, the data management needs of the system engineering process, modeling and simulation activities, test and evaluation strategy, support strategy, and other periodic reporting requirements. [https://acc.dau.mil/CommunityBrowser.aspx?id=24420]

“Interoperability” is the ability of systems, units, or forces to provide data, information, materiel, and services to and accept the same from other systems, units, or forces, and to use the data, information, materiel, and services so exchanged to enable them to operate effectively together. [DAU Glossary of Defense Acquisition Acronyms and Terms, 13th Edition]

“Invention” means any invention or discovery which is or may be patentable or otherwise protectable under Title 35 of the United States Code or any novel variety of plant that is or may be protectable under the Plant Variety Protection Act (7 U.S.C. 2321, et seq.). [FAR Section 52.227-13]

“Layered” means a system in which components are grouped, i.e., layered, in a hierarchical arrangement, such that lower layers provide functions and services that support the functions and services of higher layers. Note: Systems of ever-increasing complexity and capability can be built by adding or changing the layers to improve overall system capability while using the components that are still in place.  [The Alliance for Telecommunications Industry Solutions (ATIS) web site, http://www.atis.org.]

“Lead Systems Integrator” has no official definition in the DoD 5000 series or FAR/DFARS.  The generally accepted meaning of systems integrator is:

Systems Integrator – A prime contractor, working with other associates or associate prime contractors on a system, whose function is total responsibility for integrating the products/processes/subsystems/components of the associates or associate prime contractors into the total system.  This contractor may have been awarded a separate contract for the integration effort or it could be part of the contract for its part of the system being acquired. This contractor does not necessarily have to have a separate product/process/ subsystem/component of the system to be the systems integrator. The systems integrator may also be the government.  [Defense Systems Management College]

The Office of the Undersecretary of Defense (Acquisition, Test and Logistics) in a Memorandum entitled “Limitations on contractors Acting as Lead Systems Integrators” dated 18 January 2007 provided the following definitions:

• “Lead system integrator with system responsibility” means a prime contractor for the development or production of a major system if the prime contractor is not expected at the time of award to perform a substantial portion of the work on the system and the major subsystems.
• “Lead system integrator without system responsibility” means a contractor under a contract for the procurement of services whose primary purpose is to perform acquisition functions closely associated with inherently governmental functions with regard to the development or production of a major system.

“Life Cycle Model” in the context of the development, operation, and maintenance of a software product, a life cycle model is a defined set of processes, activities, and tasks, and their sequencing and interrelationships, spanning the life of the system from its definition to the termination of its use. [IEEE/EIA Std. 12207/1997]

“Limited Rights” (LR) means, in part, the right to use, modify, reproduce, release, perform, display, or disclose IP and technical data, in whole or in part, within the Government.  The Government may not, without permission, release or disclose the IP and technical data outside the Government, use the IP and technical data for manufacture, or permit the IP and technical data to be used by another party, except:

• When necessary for emergency repair and overhaul;
• When used for evaluation or informational purposes by foreign governments;
• Subject to prohibitions on further reuse;
• When the contractor asserting the restriction is notified of such use.

[DFARS §252.227.7013(a)(13)]

“Maintainability” is directed toward achieving the reliability inherent in a design through servicing and maintenance, and efficiently restoring the system to operation should failures occur.  [Defense Acquisition University]

“Markings” refers to software and other Intellectual Property Rights (IPRs) legends, distribution statements, security classifications, and appropriate export control statements.  It is important that Program Managers review the markings of all deliverables prior to acceptance to ensure that the Government will obtain the IPRs it has contracted for.

“Method/Technique” – The approach used to accomplish the task.  [IEEE/EIA Std. 12207/1997]

“Module” is a discrete, small-grained unit of functionality, either hardware or software, with a well-defined, open and published interface.  Modules are combined with other modules to create components, services, and packages.

“Modular Contracting” is a contracting approach under which the need for a system is satisfied in successive acquisitions of interoperable increments. Each increment complies with common or commercially acceptable standards applicable to information technology (IT) so that the increments are compatible with the other increments of IT comprising the system. [Glossary of Defense Acquisition Acronyms & Terms, 13^th Edition, Nov. 2009]

“Modular Design” means a design (organization) where functionality is partitioned into discrete, cohesive, and self-contained units with well-defined, open and published interfaces that permit substitution of such units with similar components or products from alternate sources with minimum impact on existing units. [A Modular Open Systems Approach (MOSA) to Acquisition document, (USD(AT&L)) OSJTF]

“Modular Open Systems Approach or MOSA” is the DoD’s implementation of Open Systems.  Within the MOSA context, programs should design their system based on adherence to the following five MOSA principles:

• Establish an   Enabling Environment.
• Employ Modular   Design.
• Designate Key   Interfaces.
• Use Open Standards.
• Certify   Conformance.

[A Modular Open Systems Approach (MOSA) to Acquisition, OSJTF]

“National Security Systems (NSS)” are any telecommunications or information systems operated by DoD and the function, operation, or use of which involves intelligence activities; cryptologic activities related to national security; the command and control of military forces; equipment that is an integral part of a weapons system; or criticality to the direct fulfillment of military or intelligence missions, which does not include procurement of automatic data processing equipment (ADPE) or services to be used for routine administrative and business applications (including payroll, finance, logistics, and personnel management applications). (CJSCI 3170.01G)

“Naval Open Architecture (NOA)” is the confluence of business and technical practices yielding modular, interoperable systems that adhere to open standards with published interfaces. This approach significantly increases opportunities for innovation and competition, enables reuse of components, facilitates rapid technology insertion, and reduces maintenance constraints. NOA delivers increased warfighting capabilities in a shorter time at reduced cost. [RhumbLines, December 12, 2006, Naval Office of Information]

“Open Architecture” means a type of architecture whose specifications are made public by its designers which allows users to make modifications to various components.  [ITtoolbox].

Note: “Openness” can be thought of in degrees, based on the level and scope of the information provided (for example, both internal and external information on interfaces) and its availability to third parties (e.g. either to a select few or to a broad range of potential component providers).

“Open Source Software” is computer software for which the source code and certain other rights normally reserved for copyright holders are provided under a software license that meets the Open Source Definition or that is in the public domain.  This permits users to use, change, and improve the software, and to redistribute it in modified or unmodified forms. [Wikipedia.  Since different organizations define OSS differently, it is strongly suggested that readers to also refer to the more complex definition developed by the Open Source Initiative (http://www.opensource.org) and other organizations such as the Free Software Foundation (http://www.fsf.org)]

“Open Standards” means widely accepted and supported standards set by recognized standards organizations or the marketplace. These standards support interoperability, portability, and scalability and are equally available to the general public at no cost or with a moderate license fee.  [Glossary of Defense Acquisition Acronyms & Terms, 13^th Edition, Nov. 2009]

“Open System” means a system that employs modular design tenets, uses widely supported and consensus based standards for its key interfaces, and is subject to validation and verification tests to ensure the openness of its key interfaces.  [A Modular Open Systems Approach (MOSA) to Acquisition, OSJTF]

“Open Systems Approach” means an integrated business and technical strategy that employs a modular design and, where appropriate, defines key interfaces using widely supported, consensus-based standards that are published and maintained by a recognized industry standards organization. [A Modular Open Systems Approach (MOSA) to Acquisition, OSJTF]

“Open System Architecture” is a system that employs modular design, uses widely supported and consensus based standards for its key interfaces, and has been subjected to successful validation and verification tests to ensure the openness of its key interfaces. [A Modular Open Systems Approach (MOSA) to Acquisition, OSJTF]  An open architecture is defined as a technical architecture that adopts open standards supporting a modular, loosely coupled and highly cohesive system structure that includes publishing of key interfaces within the system and full design disclosure.  The key enabler for open architecture is the adoption of an open business model which requires doing business in a transparent way that leverages the collaborative innovation of numerous participants across the enterprise permitting shared risk, maximized asset reuse and reduced total ownership costs.  The combination of open architecture and an open business model permit the acquisition of Open Systems Architectures that yield modular, interoperable systems allowing components to be added, modified, replaced, removed and/or supported by different vendors throughout the life cycle in order to drive opportunities for enhanced competition and innovation.

The following are the core principles of the Open Systems Architecture approach:

1. Modular designs with loose coupling and high cohesion that allow for independent acquisition of system components, i.e., composability;

2. Continuous design disclosure and appropriate use of data rights allowing greater visibility into an unfolding design and flexibility in acquisition alternatives;

3. Enterprise investment strategies that maximize reuse of system designs and reduce total ownership costs (TOC);

4. Enhanced transparency of system design through Government, academia, and industry peer reviews;

5. Competition and collaboration through development of alternative solutions and sources;

6. Analysis to determine which components will provide the best return on investment (ROI) to OSA, i.e., which components will change most often due to technology upgrades or parts obsolescence and have the highest associated cost over the life cycle.

Achievement of these six principles requires an affirmative answer to a fundamental question:

Can a qualified third-party add, modify, replace, remove, or provide support for a component of a system, based on open standards and published interfaces for the component of that system?

“Peer Review” (as used in connection with Open Systems Architecture) is a refereed, open process used to assess technical approaches proposed by or being used by vendors.  There are two general types of peer reviews.  The first is a Government Peer Review that includes representation from government activities such as System Commands, PEOs and Program offices.  The second type is the contractor Peer Review that includes contractors as participants.  Contractor participants should be drawn from a cross section of the broader community of interest with academia and private sector entities (including large business, small business and non-traditional DoD contractors) such that the membership (taken as a whole) is unbiased and impartial.  An ‘independent peer review’ is one where the membership includes individuals from outside the program being reviewed.  Membership is structured to achieve a balanced perspective in which no one organization is numerically dominant.  Consensus is a goal, but the Peer Review Group’s findings or recommendations to the decision maker normally consist of a majority opinion and a documented dissenting opinion if the minority chooses to formalize its concerns.  This assessment process normally results in findings or recommendations presented to the decision maker with the authority and responsibility to select or make the final course of action or decision..

“Performance-based Logistics” is the preferred sustainment strategy for weapon system product support that employs the purchase of support as an integrated, affordable performance package designed to optimize system readiness.  PBL meets performance goals for a weapon system through a support structure based on long-term performance agreements with clear lines of authority and responsibility.  DoDI 5000.02 introduced the term “Product-Based Life Cycle Product Support” as the latest evolution of Performance-Based Logistics and stated that both terms can be referred to as “PBL.”  [DAU Glossary of Defense Acquisition Acronyms and Terms, 13^th Edition]

“Portability” is a characteristic a software system or program that deals with the ease with which the software can be modified to operate in an execution environment other than that for which it was specifically designed.  Execution environments include operating systems, middleware, hardware, and environmental interfaces.  If minimal changes to the software are required, then the software is considered to be highly portable.  If no changes are required, then the term is not applicable.

“Practical application” means to manufacture in the case of a composition or product, to practice in the case of a process or method, or to operate in the case of a machine or system; and, in each case, under such conditions as to establish that the invention is being utilized and that its benefits are, to the extent permitted by law or Government regulations, available to the public on reasonable terms.  [FAR Section 52.227-13]

“Process” is a set of interrelated activities designed to accomplish a specified goal. IEEE/EIA Std. 12207/1997 Table 1 lists all 12207 processes and their associated activities. For example Development is a process. Within Development there are thirteen activities as shown in Table 1. One of these activities is Software Coding and Testing which has five tasks.  [IEEE/EIA Std. 12207/1997]

“Reliability” is directed toward assuring that a given design attains the longest possible continued operation [i.e., high Mean Time Between Failures (MTBF) and low Mean Time To Repair (MTTR)] and operating life.   (Defense Acquisition University)

“Reconfigurability” means that a system or a service’s state and behavior can be dynamically modified during its operation. [University of Athens, Communications Networks Laboratory]

“Reusability” is the degree to which a software module or other work product can be used in more than one computing program or software system [IEEE]

“Restricted Rights” (RR) applies only to noncommercial software and means, in part, the Government’s rights to use the computer program:

• With one computer at a time;
• To transfer the program to another computer subject to restrictions;
• To make minimum copies for safekeeping, modification or backup;
• To modify the software for the above purposes;
• To permit contractors or subcontractors performing services in support of this or a related contract to use the software to diagnose and correct deficiencies or to respond to urgent tactical situations, subject to subject to non-disclosure and restrictions against reverse engineering and other restrictions.
• To permit contractors or subcontractors performing emergency repairs or overhaul of items or components of items procured under this or a related contract to use the computer software when necessary to perform the repairs or overhaul or to modify the software to reflect the repairs/overhaul, subject to non-disclosure and restrictions against reverse engineering.

[DFARS §252.227-7014(a)(14)]

“Scalability” is the capability of a piece of hardware or software to easily expand to meet future computing needs.  [Microsoft TechNet]

“Small business firms” means a small business concern as defined at section 2 of Pub. L. 85-536 (15 U.S.C. 632) and implementing regulations of the Administrator of the Small Business Administration.  [FAR Section 27.301, 52.227-11, and 52.227-12]

“Software Architecture” of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of these elements, and the relationships among them. [IEEE]

“Software Intensive System” is one in which software represents the largest segment in any one or more of the following criteria:

• System development cost
• System development risk
• System functionality
• Development time

[Defense Acquisition University]

“Software Reuse” is the process of implementing or updating software systems using existing software assets.  [DAU Glossary of Defense Acquisition Acronyms and Terms, 13^th Edition]  The DoD 5000.1 Acquisition Guidebook states that the “program manager should base software systems development on robust systems engineering principles. The following best practice[] for software systems also apply in general to any system. … Identifying and exploiting, where practicable, Government and commercial software reuse opportunities before developing new software.”  Potential software assets include:

1. Computer   Software - Computer programs, procedures, and possibly   associated documentation and data, pertaining to the operation of a   computer system.

2. Software   Development Plan (SDP) – A management plan usually generated by the developer describing   in detail the processes, activities, and tasks to be performed to   accomplish the software development effort.

3. Computer   Software Documentation – Technical Data (TD) information, including computer listings and   printouts, that documents the requirements, design, or details of computer   software, explains the capabilities and limitations of the software, or   provides operation instructions for using or supporting computer software   during the software's operational life.

4. Software   Product Specification – Detailed design and description of Software Items (SIs)   comprising the product baseline. Analogous to the Item Detail   Specification of a hardware Configuration Item (CI) in the product   baseline of a hardware system.

5. Software   Requirement Specification (SRS) – A description of the requirements (behaviors, functions,   performance, design constraints and attributes) allocated to a specific   Software Configuration Item (SCI). Often accompanied by an Interface   Requirements Specification (IRS) for that SCI.

6. Software   Specification Review (SSR) – A life cycle review of the requirements specified for one or more   Software Configuration Items (SCIs) to determine whether they form an   adequate basis for proceeding into preliminary design of the reviewed   item. See Software Requirement Specification (SRS) and Interface   Requirement Specification (IRS).

7. Interface   Requirement Specification (IRS) - A type of Item Performance Specification that   defines the required software interfaces for a given Software Item (SI) in   the allocated baseline, the requirements for which are described by a   Software Requirements Specification (SRS). The IRS is frequently combined   with the SRS.

8. Computer   Software Component (CSC) - Under some software development standards, a   functional or logically distinct part of a Computer Software Configuration   Item (CSCI), or Software Configuration Item (SCI)

9. Software   Item (SI) – An   aggregation of software, such as a computer program or database that   satisfies an end use function and is designated for purposes of   specification, qualification, testing, interfacing, Configuration   Management (CM), or other purposes. An SI is made up of Computer Software   Units (CSUs).

10. Software   Resources Data Report (SRDR) - SRDR is intended to improve the ability of the   DoD to estimate the costs of software intensive programs. SRDR reporting   is required by DoD Instruction 5000.2, Enclosure 3, for major contracts   and sub-contracts (regardless of contract type) associated with high-cost   software elements within Acquisition Category I and Acquisition Category   IA programs. Data collected from applicable contracts include type and   size of the software application(s), schedule, and labor resources needed   for the software development.

11. Analysis   of Alternatives - The evaluation of the performance, operational   effectiveness, operational suitability, and estimated costs of alternative   systems to meet a mission capability. The analysis assesses the advantages   and disadvantages of alternatives being considered to satisfy   capabilities, including the sensitivity of each alternative to possible   changes in key assumptions or variables. The AoA is normally conducted   during the Concept Refinement phase of the Defense Acquisition Framework   and the results of the AoA align with the system concept contained in the   Initial Capabilities Document (ICD) approved prior to Milestone A.

12. Initial   Capabilities Document – Documents the need for a materiel approach, or an approach that   is a combination of materiel and non-materiel, to satisfy specific   capability gap(s). The ICD defines the gap in terms of the functional   area; the relevant range of military operations; desired effects; time and Doctrine, Organization,   Training, Materiel, Leadership and Education, Personnel, and Facilities   (DOTMLPF); and policy implications and constraints. The outcome of an ICD   could be one or more DOTMLPF Change Recommendations (DCRs) or Capability   Development Documents.

13. Systems   Engineering Plan - A   description of the program’s overall technical approach including   processes, resources, metrics, applicable performance incentives, and the   timing, conduct, and success criteria of technical reviews.

14. Test   and Evaluation Master Plan - Documents the overall structure and objectives of the Test and   Evaluation (T&E) program. It provides a framework within which to   generate detailed T&E plans and it documents schedule and resource   implications associated with the T&E program. The TEMP identifies the   necessary Developmental Test and Evaluation (DT&E), Operational Test   and Evaluation (OT&E), and Live Fire Test and Evaluation (LFT&E)   activities. It relates program schedule, test management strategy and   structure, and required resources to: Critical Operational Issues (COIs),   Critical Technical Parameters (CTPs), objectives and thresholds documented   in the Capability Development Document (CDD), evaluation criteria, and   milestone decision points. For multi-service or joint programs, a single integrated   TEMP is required. Component-unique content requirements, particularly   evaluation criteria associated with COIs, can be addressed in a   component-prepared annex to the basic TEMP.

15. Capability   Development Document - A document that captures the information necessary to develop a   proposed program(s), preferably using an evolutionary acquisition   strategy. The CDD outlines an affordable increment of militarily useful,   logistically supportable, and technically mature capability. The CDD   supports a Milestone B decision review.

16. Acquisition   Program Baseline -   Prescribes the key cost, schedule, and performance parameters, each with   an objective and threshold, to which the program will be executed in the   phase succeeding the milestone for which the APB was developed.  The APB constitutes an agreement between   the program manager, resource sponsor, and milestone decision authority,   and the breaching of any one parameter threshold will necessitate a   re-baselining with a new APB agreed to by those three parties.

17. Training   Plan – Outlines the   level of learning required to adequately perform the responsibilities   designated to the function and accomplish the mission assigned to the   system.

[DoD 5000.1 Acquisition Guidebook]

“Subject Invention” means any invention of the contractor conceived or first actually reduced to practice in the performance of work under this contract; provided, that in the case of a variety of plant, the date of determination (as defined in section 41(d) of the Plant Variety Protection Act, 7 U.S.C. 2401(d)) must also occur during the period of contract performance.  [FAR Section 52.227-11]

“System Architecture” is the composite of the design architectures for products and their life cycle processes. [IEEE 1220-1998]

“Tasks” are specific actions performed to accomplish an activity. The way that each task is performed, such as testing, is called the technique or method. [IEEE/EIA Std. 12207/1997]

“Technology Insertion” is increasing a system’s or product’s Warfighting operational capability by integrating new capabilities or upgrading the system’s current capabilities with up-to-date and more capable COTS or custom technologies. [Software Engineering Institute]

“Upgradeability” is the ease with which a system or component can be modified to take advantage of new software or hardware technologies.  [Software Engineering Institute]

“Unlimited rights” (UL) means rights to use, modify, reproduce, perform, display, release, or disclose technical data in whole or in part, in any manner, and for any purpose whatsoever, and to have or authorize others to do so. [DFARs Section 252.227-7013(a)(16)]