Naval Open Architecture 

Contract Guidebook 

For Program Managers 

Version 2.0 

30 June 2010 

Greater Value, Innovative Solutions 

For the Warfighter 

Prepared by: Naval Open Architecture Enterprise Team 

Distribution Statement A: Approved for Public Release; distribution is unlimited
Report Documentation Page Form Approved

OMB No. 0704-0188

Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and

maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,

including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington

VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it

does not display a currently valid OMB control number.

1. REPORT DATE

30 JUN 2010 2. REPORT TYPE

3. DATES COVERED

 00-00-2010 to 00-00-2010 

4. TITLE AND SUBTITLE

Naval Open Architecture Contract Guidebook For Program Managers

5a. CONTRACT NUMBER

5b. GRANT NUMBER

5c. PROGRAM ELEMENT NUMBER

6. AUTHOR(S) 5d. PROJECT NUMBER

5e. TASK NUMBER

5f. WORK UNIT NUMBER

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)

Department of Navy,Program Executive Office, Integrated Warfare

Systems,1333 Isaac Hull Ave. SE,Washington,DC,20376

8. PERFORMING ORGANIZATION

REPORT NUMBER

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)

11. SPONSOR/MONITOR’S REPORT 

NUMBER(S)

12. DISTRIBUTION/AVAILABILITY STATEMENT

Approved for public release; distribution unlimited

13. SUPPLEMENTARY NOTES

14. ABSTRACT

15. SUBJECT TERMS

16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF 

ABSTRACT

Same as

Report (SAR)

18. NUMBER

OF PAGES

94

19a. NAME OF

RESPONSIBLE PERSON

a. REPORT

unclassified

b. ABSTRACT

unclassified

c. THIS PAGE

unclassified

Standard Form 298 (Rev. 8-98)

Prescribed by ANSI Std Z39-18 
Ref : (a) OA Contract Guidebook, Ver 2.0 , April 2010 

Encl : (1) Improvements in version 2 . 0 

(2) Acknowledgments OA Contract Guidebook Use 

1. Purpose . To update direction to PEO IWS Program Managers 

(PMs) and Contracting Officers on the use of reference (a). 

2. Information . 

a. In April 2010 , Version 2 . 0 of the Open Architecture (OA) 

Contract Guidebook was signed. The Government- only version of 

this guide .contains information and recommended contract language 

to assi st PMs and Contracting Officers in drafting requests and 

contracts that ensure t h e products delivered meet the Navy' s 

standards for OA development. 

b. A ' Statement A" version of the OA Contract Guidebook is 

accessible at the OA website (https : //acc . dau .mil/NOAGuidebook ) 

to allow potential solicitations insight into the Navy' s OA principles and goals, without the sensitive portions contained in 

the government- only version. 

c . The language in this gui debook has been used successfully in several PEO IWS contracts including Undersea Systems, SEWIP Block 2 , and Platform Systems Engineering Agent (PSEA) as well as 

in many contracts throughout the Naval Enterprise . 

3 . Action. 

a . All PEO IWS PMs and Contracting Officers are directed to 

become familiar with reference (a) and employ its principles in 

all future contractual program development . This includes, but 

is not limited to , using its recommended contract language in 

requests for information, requests for proposal , and all 

contracts . The Milestone Decision Authority (MDA) will use the 

PEO and PM questions contained in Appendices 2 and 3 of the 

Guidebook to determine OA-compliance at major milestones . 
Distribution: 

PEO IWS 1. 0 

PEO IWS 2.0 

PEO IWS 3.0 

PEO IWS 4.0 

PEO IWS 5.0 

PEO IWS 6.0 

PEO IWS 7.0 

PEO IWS 8.0 

PEO IWS 9.0 

PEO IWS 10.0 

PEO IWS 11.0 

PEO IWS 12.0 

PEO IWS 14.0 

CHRIS DEEGAN 

Acting 

2 
Table of Contents

INTRODUCTION............................................................................................................. 1 

Chapter A: RECOMMENDATIONS FOR SECTION C (STATEMENT OF 

WORK) LANGUAGE...................................................................................................... 8 

Chapter B: EXAMPLES OF SECTION H (SPECIAL CONTRACT 

REQUIREMENTS) LANGUAGE ................................................................................ 19 

Chapter C: RECOMMENDATIONS FOR SECTION L (INSTRUCTIONS TO 

OFFERORS) LANGUAGE ........................................................................................... 29 

Chapter D: RECOMMENDATIONS FOR SECTION M (EVALUATION 

CRITERIA) LANGUAGE............................................................................................. 46 

Chapter E: RECOMMENDATIONS FOR INCENTIVIZING CONTRACTORS 49 

Appendix 1: RECOMMENDED NOA CDRL AND DELIVERABLE ITEMS....... 54 

Appendix 2: NOA CHECKLIST (short) ..................................................................... 64 

Appendix 3: NOA CHECKLIST (long)....................................................................... 65 

Appendix 4: RECOMMENDED DATA LANGUAGE FOR CODE HEADERS.... 68 

Appendix 5: OPEN SOURCE SOFTWARE............................................................... 72 

Appendix 6: GLOSSARY OF TERMS........................................................................ 77 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

1 

INTRODUCTION 

Purpose: The Naval Open Architecture Contract Guidebook for Program Managers is 

to be used by Program Managers (PMs) who are incorporating Naval Open Architecture 

(NOA) principles (see NOA Requirements Letter, available on the NOA website at 

https://acc.dau.mil/oa) into National Security System (NSS) acquisition programs as 

defined by 40 U.S.C § 11101 et seq. These same principles, described later in this 

document, can be tailored to apply to the acquisition of any system or service, including 

those not considered to be “information intensive.” 

This Guidebook contains recommendations and is offered with the understanding that 

individual Program Executive Offices (PEOs) and programs must have the flexibility to 

adapt its principles and guidance to meet their needs. This document is intended to 

augment, rather than replace, existing contractual source materials such as the Federal 

Acquisition Regulations (FAR) and the Defense Federal Acquisition Regulation 

Supplement (DFARS). 

There are a variety of tools, devices and resources available to the PM when planning for 

and conducting the acquisition of a NSS or other system using NOA guidelines such as 

those contained in this Guidebook. The proper use of these resources is an important 

element of the acquisition process and will reduce the overall risk to the Navy and 

Marine Corps by ensuring that all necessary NOA aspects of the procurement are 

covered. In addition to the contract, Request for Proposal (RFP), and Statement of Work 

(SOW) elements that are discussed in this Guidebook, the System Specification and other 

system architecture and design materials are important. Because the System 

Specification defines the attributes of the overall system to be developed, it must describe 

how the technical system characteristics will contribute to its openness (such as its 

modularity and how open standards will be incorporated). The System Specification 

should also address those areas where future growth is expected, where reuse is 

envisioned, etc. Proper balance and coordination among these elements is important to 

both the technical design and the overall lifecycle support of the system. Additional 

information on these topics is included in the appendices of this document. 

Organization: This document is divided into five chapters containing suggested 

language for RFP Sections C, H, L and M, and Award Fee Plans. This material can be 

tailored for use in the specific phase of an acquisition program. It can also be tailored for 

use in Contract Modifications. Appendix 1 contains suggested NOA-related Data Item 

Descriptions (DIDs) for use in preparing the Contract Data Requirements List (CDRL) 

and for identifying other contractual deliverables. Appendices 2 and 3 are checklists to 

assist the Program Manager to better understand the business and technical aspects of 

NOA. Appendices 4 and 5 address Data Markings and Open Source Software (OSS). 

Appendix 6 contains a Glossary of Terms. 

Providing Comments and Feedback: Development and maintenance of this Guidebook

is an interactive process involving the “build-test-build” method, each on a roughly 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

2 

biennial release. These releases will incorporate community inputs and address topics 

that emerge from the Naval Enterprise’s experience from implementing NOA. 

Therefore, PEO Integrated Warfare Systems (IWS) 7 is very interested in comments, 

suggestions, and feedback. We are also very interested in any “real world” experiences 

you may have in using NOA principles in programs. Comments can be submitted via 

email, with “Comments on NOA Contract Guidebook” in the subject line, to 

NavalOA@navy.mil. 

 

Background: 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. The U.S. Government’s (“Government”) 

ability to acquire at least Government Purpose Rights (GPR) in technical data and 

computer software and to obtain rights in other intellectual property is critical to this 

effort. 

The Navy and Marine Corps have adopted OA as a way to reduce the rising cost of Naval 

warfare systems and platforms while continuing to increase capability delivery on 

shortened demand timelines. 

NOA is the Naval implementation of the Office of the Secretary of Defense’s Open 

Systems Joint Task Force’s (OSJTF) Modular Open System Approach (MOSA) that was 

first introduced in 2004. While MOSA and NOA each have five principles, there is a 

synergy between them. Each Naval Domain may choose to implement them in a 

different manner. 

NOA allows for incorporating more commercial-off-the-shelf (COTS) technology in 

warfare systems and enabling reuse of software and related assets. In addition, NOA is 

an enabler of FORCEnet, the operational construct and architectural framework for Naval 

Warfare in the information age (see http://www.forcenet.navy.mil). More importantly, 

OA increases competition among system developers through the use of open standards 

and standard, published interfaces. It also facilitates greater collaboration within and 

across Naval Domains. Individual Domains (Air, Submarines, Surface, C4I, Space and 

Marine Corps) and PEOs may opt to pursue common architectures or capabilities across 

platforms; the NOA principles highlighted in these materials would apply to these 

common architectures. 

On October 16, 2009, acting Assistant Secretary of Defense (Networks & Information 

Integration) / DoD Chief Information Officer (CIO) David M. Wennergren promulgated a 

memorandum clarifying guidance on Open Source Software (OSS). The memo stated 

that in “almost all cases, OSS meets the definition of ‘commercial computer software’ ” 

and, therefore, should be given similar consideration as more traditional commercial 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

3 

computer software when a program is looking to acquire such software. 1 This will allow 

the Department of Navy (DON) to utilize OSS throughout the enterprise when acquiring 

capabilities to meet DON business and warfighter requirements. As with any COTS 

solution, the use of OSS must adhere to all Federal, DoD, and DON policies and be based 

on open standards to support the DoD’s goals of net-centricity and interoperability. In 

addition, DON commands must work with their intellectual property counsel to ensure 

compliance with OSS license agreements. 

This contract language guidance is designed to assist PEOs, Program Managers, legal, 

and contracting officials in addressing the technical and business aspects of OA in the 

solicitation and award of Navy and Marine Corps contracts. The language represents a 

long-term view and incorporates many of the principles of open systems mandated by the 

Department of Defense (DoD) Open Systems Joint Task Force (OSJTF) and the Office of 

the Secretary of Defense (OSD)/Networks & Information Integration (NII). 

Discussion: This Guidebook contains recommended language for Section C and 

associated Contract Data Requirements Lists (CDRLs) of contracts and Sections L and M 

of solicitations issued by the Navy or Marine Corps for NSS or larger “systems of 

systems” that integrate NSS with platforms such as aircraft, submarines, land vehicles, 

satellites or ships. There are also recommendations for language that can be incorporated 

in Section H of solicitations, including those that are directed at existing programs. The 

term “NSS” refers to any telecommunications or information system operated by the 

Government, the function, operation, or use of which (1) involves intelligence activities; 

(2) involves cryptologic activities related to national security; (3) involves command and 

control of military forces; (4) involves equipment that is an integral part of a weapon or 

weapons system; or (5) is critical to the direct fulfillment of military or intelligence 

missions, but excluding any system that is to be used for administrative and business 

application purposes (including payroll, finance, logistics, and personnel management 

applications).2

 

Sections L and M are pre-award documents not incorporated into the actual contract but 

are key to ensuring contractor understanding of and compliance with OA principles. 

Execution of an effective NOA strategy including strategic asset reuse must be 

considered from both a Pre-Award and Post-Award perspective. The language contained 

in this document should be tailored to reflect the program’s phase and the goals of the 

intended procurement action. 

Program Managers are advised to use this recommended language and other appropriate 

technical documents after determining the specific acquisition relevance to the 

requirement. Prior to tailoring this language to the specific needs of the acquisition 

program, Program Managers should have a clear understanding of NOA principles. 

Acquisition Programs should have a strategy and supporting plan that addresses an 

appropriate (business and technical) OA end state and acts as a framework for structuring 

 

1

 DoD Memorandum Clarifying Guidance Regarding Open Source Software (OSS), 

October 16, 2009. 

2

 40 U.S.C. §11103. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

4 

contract language that is consistent with DoD guidance for interoperability, such as that 

included in PEO C4I’s Net-Centric Enterprise Solutions for Interoperability (NESI) 

V3.1.0 (available at http://nesipublic.spawar.navy.mil/). The Open Architecture 

Assessment Tool (OAAT)3

 (developed by the Naval Open Architecture Enterprise 

Team), which incorporates the Under Secretary of Defense for Acquisition, Technology 

and Logistics (USD(AT&L)) Open Systems Joint Task Force’s (OSJTF’s) MOSA 

PART4

 tool, should be used to formulate an OA strategy. Additionally, the Naval Air 

Systems Command (NAVAIR) Key Open Sub Systems (KOSS) tool can be used to 

identify the components of a modular architecture that are going to be evolving the most 

over time and, therefore, should receive extra OA emphasis.5

 Appendices 2 and 3 consist 

of two checklists that will also be helpful in preparing acquisition materials. 

The goal of maximizing program flexibility to enable competition and programmatic 

course changes must be balanced against providing the contractor enough incentive to 

agree to the contract. Short duration tasks and small deliverable quantities provide the 

Program Manager with the flexibility to shift to other providers to obtain better 

performance, introduce different products and technologies, or when otherwise deemed in 

the best interest of the Government. Such mechanisms are not a substitute for effective 

project and contract management practices by the Program, but can provide additional 

leverage to support these practices. 

Intellectual Property Rights (IPR) and Data Rights: Program Managers are strongly 

encouraged to assess the IPR and data rights requirements of their program and/or 

community of interest.6

 Navy and Marine Corps Program Managers responsible for 

ACAT I and II programs are further advised to immediately take steps to incorporate the 

requirements of DoD Instruction 5000.02 dated December 2, 2008 and Under Secretary 

of Defense (Acquisition, Technology and Logistics) Memorandum on Data Management 

and Technical Data Rights dated July 19, 2007 as directed by the Assistant Secretary of 

the Navy (Research, Development and Acquisition).7 This analysis will help Program 

Managers develop Acquisition Strategies that anticipate potential reuse in other programs 

and thus guide decisions related to IPR and data rights. These decisions include: (1) 

whether these rights will be procured, (2) whether it will be considered as part of the 

technical evaluation, and/or (3) a combination of both. The alternative selected by the 

Program Manager will drive different solutions in the construct of Sections C, L and M. 

 

3 The OAAT can be found in the “Tools” section of the Naval OA website at 

https://acc.dau.mil/oa. 

4

Modular Open System Approach Program Assessment Review Tool. 

5

 The KOSS tool can be found in the “Tools” section of the Naval OA website at 

https://acc.dau.mil/oa. 6

 A “community of interest” or COI is a group of organizations or entities having similar 

interests and goals. For example, Navy COIs can be along warfare requirements (anti-air 

warfare or littoral defense), families of system or components (radars or displays), or 

functions (acquisition or test and evaluation). 7 Assistant Secretary of the Navy (Research, Development and Acquisition) 

Memorandum on Data Management and Technical Data Rights dated September 11, 

2007.
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

5 

The attached Section L and M language provides general guidance on data rights while 

specifics must be tailored to specific programs. 

Program Managers (in coordination with their PEOs and Resource Sponsor) should 

develop a post-award strategy to ensure they are exercising their IPR as defined by the 

Federal Acquisition Regulations (FAR) and Defense Federal Acquisition Regulation 

Supplement (DFARS). Historically, the Navy and Marine Corps have not effectively 

exercised or enforced the intellectual property rights (IPR) procured by the Government 

or identified by contractors in their proposals by not including effective Contract Data 

Requirements Lists (CDRLs) and Data Item Descriptions (DIDs) in contracts. The 

Statement of Work (SOW) establishes the product/system development expectations; the 

CDRL orders the delivery of the data according to the SOW, and the DID describes the 

format and content of the data ordered by the CDRL as articulated in the FAR and 

DFARS. It is incumbent upon the Government, in general, and the Program Manager 

and Contracting Officer’s Representative (COR) specifically, to review each deliverable 

and report unjustified/nonconforming or other inappropriate markings on delivered data 

to the Contracting Officer in order to ensure the PEO is able to take full advantage of the 

Government’s rights. The Contracting Officer, with the assistance of counsel, is 

responsible for enforcement of the DFARS provisions. 

An overarching concern is reconciling 10 U.S.C. § 2320 section (a)(2)(F) “Rights in 

Technical Data” requirements with the proposed evaluation factors. Although the 

Government cannot condition award or responsiveness on relinquishing rights, under 10 

U.S.C. § 2320(a)(2)(G)(i) and (iii), the Government can negotiate for additional rights or, 

if necessary, the development of alternative sources of supply and manufacture. Also, 

under DFARS 227.7103-2(b)(2) “Acquisition of Technical Data” and DFARS 227.7203-

2(b)(2) “Acquisition of Noncommercial Computer Software and Computer Software 

Documentation” the Government can and must balance the original assessment of the 

Government’s data needs with data prices contained in the offer. Furthermore, 10 U.S.C. 

§ 2305(d)(4)(B) “Contracts: Planning, Solicitation, Evaluation, and Award Procedures” 

states: “[i]n considering offers in response to a solicitation requiring proposals described 

in paragraph (1)(B) or (2)(B), the head of an agency shall base any evaluation of items 

developed exclusively at private expense on an analysis of the total value, in terms of 

innovative design, life-cycle costs, and other pertinent factors, of incorporating such 

items in the system.” Such factors may include the IPR specified in an offer. 

As part of a best value analysis, the Government may consider an Offeror’s willingness 

to provide the Government with the equivalent of GPR. The evaluation criteria must 

make clear that the Government will be evaluating the costs associated with an Offeror’s 

restrictions on data and software-related assets that would be delivered under the 

contract. The Government will assess the impact on costs of the delivery of: 1) limited 

rights (LR) data, 2) restricted rights (RR) software, 3) standard licenses in Commercial 

computer software (CS)8

, or 4) items covered under DFARS 252.227-7015, “Technical 

Data – Commercial Items.” For example, the Government will examine the impact of LR 

 

8

 “Firmware” is considered to be a category of “Computer Software” as defined in the 

DFARS. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

6 

in data on system life cycle costs (when making cost assessment keep in mind 

alternatives like use of form, fit, function, etc., as assessment must be “reasonable”). To 

avoid an unstated evaluation criteria problem, the criteria must at least specify the relative 

importance of costs associated with needs set forth in the “Data Rights and Patent Rights” 

portion of the solicitation, e.g., life cycle costs for system. Finally, the data rights and 

associated markings of intellectual property – including releasability statements – will 

impact the Government’s ability to deposit intellectual property (IP) in asset 

repositories/libraries and be able to use these assets in other systems. 

Award Incentives: Contract type is determined based on risk of on-time completion of 

the work to be performed. For firm fixed-price contracts (regardless of dollar 

value), program managers must receive Milestone Decision Authority (MDA) approval, 

which must be based on a business case analysis. 

Incentivizing technical excellence in the program is an important aspect of the program 

acquisition strategy and is usually applied with award fees or award terms. The same 

approach should be used in encouraging appropriate NOA business and technical 

practices. Award Fee earnings are briefed to the highest levels within corporate 

management and thus have the added benefit of reinforcing the importance of the 

Government’s emphasis on technical leadership, planning and execution with this group 

of senior leaders. Award fee criteria that support NOA principles are an important 

mechanism for encouraging appropriate behavior. 

The incentive arrangement should be designed to motivate contractor performance that 

might not otherwise be emphasized – such as adoption and adherence to NOA business 

and technical principles. Award incentives may be applied when it is not possible to 

establish a predetermined target to measure desired performance and are earned by a 

contractor through an evaluation process described in the Award Fee Plan. The 

application of award fee incentives are generally associated with cost contracts and 

performance is evaluated periodically in accordance with the Award Fee Plan. This 

incentive approach allows the Government to motivate exceptional contractor 

performance considering the conditions under which it was achieved, normally in such 

areas as adherence to NOA technical tenets, business practices, and cooperative behavior 

with other vendors as well as the more usual quality, timeliness, technical progress, 

technical ingenuity, and cost-effective management requirements. The award fee or term 

criteria must be based on the requirements described in the contract. The most effective 

criteria are objective in nature. When possible, criteria should be expressed in 

quantifiable terms. Some NOA technical criteria are inherently mixed with and 

supportive of NOA business criteria. 

The “DoD Guide for Integrating Systems Engineering into DoD Acquisition Contracts 

Version 1.0” promulgated by the Office of the Under Secretary of Defense (OUSD) for 

Acquisition, Technology and Logistics (AT&L) includes recommendations for including 

language regarding interface design, consideration of Modularity and Open Systems 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

7 

Standards as part of Evaluation Criteria and proposal content for System Performance 

Specifications that could be considered when developing technical award fee criteria.9 

 

9 “DoD Guide for Integrating Systems Engineering into DoD Acquisition Contracts 

Version 1.0,” dated December 11, 2006, page 20, Tables 3-4 and 3-5. This document is 

located at: https://acc.dau.mil/CommunityBrowser.aspx?id=127987. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

8 

Chapter A: RECOMMENDATIONS FOR SECTION C 

(STATEMENT OF WORK) LANGUAGE 

Section C of the Request for Proposal (RFP) and the resulting contract contains the 

detailed description of the products to be delivered or the work to be performed under the 

contract. Section C typically includes a Statement of Objectives/Statement of Work 

(SOO/SOW) for the RFP/contract. The SOO is a clear and concise statement that 

delineates the program objectives and the overall program approach, including the 

outcome desired. The SOO, along with the preliminary system performance specification 

(covering the technical performance requirements), provides Offerors guidance for 

proposing a solution to meet the user’s needs. An additional helpful reference is the 

Department of Defense Handbook for Preparation of Statement of Work (SOW).10

Although the Guidebook was developed for mixed systems comprised of hardware, 

middleware and software elements, the recommended language can be easily tailored to 

reflect hardware- or software-only acquisitions. 

The following contains recommended language for the SOW included in Section C of the 

RFP/contract. 

1. Open Systems Approach and Goals

The Government intends to procure system(s) having an Open System Architecture and 

corresponding components. As part of this contract, the contractor shall define, 

document, and follow an open systems approach for using modular design, standardsbased interfaces, and widely-supported consensus-based standards. The contractor shall 

develop, maintain, and use an open system management plan to support this approach 

and will be required to demonstrate compliance with that plan during all design reviews. 

As part of an open system management plan, the contractor will be required to identify to 

the Government all Commercial-Off-the-Shelf/Non-development Item (COTS/NDI) 

components11, their functionality and proposed use in the system, and provide copies of 

license agreements related to the use of these components for Government approval prior 

to use. The proposed open system management plan will be incorporated into the 

contract with any changes, alterations, and/or modifications requiring Government 

approval. 

 

10 The DoD Handbook for Preparation of Statement of Work (SOW) is available on the 

web at https://www.acqsolinc.com/mockups/7steps/library/DODhandbook.pdf. 11 The appropriate definition should be included in Section C. In this case, we define 

“component” consistent with the Institute of Electrical and Electronics Engineers (IEEE) 

definition from IEEE Std 610.12-1990, “one of the parts that make up a system. A 

component may be hardware or software and may be subdivided into other components.” 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

9 

In addition, the contractor shall provide the Government (and/or Government support 

contractors) electronic access to its integrated development environment throughout the 

term of the contract. 

Program Managers should consider including a requirement to have real-time access to 

the Offeror’s (or an associated sub-contractor’s) software development environment, 

providing the government with continuous on-line access to work products under 

development commencing at the start of work. See section titled “Data Management and 

Integrated Development Environment (IDE)” below. Collaborative tools to support this 

access must be adopted, tailored, and applied by the program in a manner consistent with 

its specific requirements and circumstances. 

 In satisfying the Government’s requirements, the following system architecture 

approach characteristics shall be utilized: 

a. Open Architecture – The contractor shall develop and maintain an architecture 

that incorporates appropriate considerations for reconfigurability, portability, 

maintainability, technology insertion, vendor independence, reusability, 

scalability, interoperability, upgradeability, and long-term supportability as 

required by the 23 DEC 2005 Office of the Chief of Naval Operations (OPNAV 

N6/7) requirements letter. (This letter is available at https://acc.dau.mil/oa.) 

i. Ensure that external information exchange requirements are implemented in a 

standard and open manner as part of this effort. These actions shall include 

planning that identifies the contractor’s specific approach to ensuring system 

and interface data is well-defined, available to all programs, and uses a 

standards-based tool for definition within the context of the Navy and Marine 

Corps upgrade programs. The contractor shall develop system upgrades that 

ensure that 1) data will be posted to shared spaces for users to access except 

when limited by security, policy, or regulations; 2) data shall provide for 

interoperability with many-to-many exchanges of data, and verified trust and 

integrity of users and applications; and 3) data shall be transmitted through 

well and openly defined interfaces. 

ii. The contractor shall ensure that their projects, at the architectural and 

operational level, continue to promote the use of an open architecture as well 

as adoption of Net Centric Enterprise Services (NCES) concepts. The 

contractor shall assist in the continuing pursuit of Net-Centric/FORCEnet 

compliance. Contractor plans must comply with the appropriate and 

applicable standards. The contractor shall ensure that the program is capable 

of interacting with the Joint Environment and DoD Global Information Grid 

when developing applications that share data via external communications. 

b. Modular, Open Design – The contractor shall develop an architecture that is 

layered and modular and uses standards-based COTS/NDI hardware, operating 

systems, and middleware that all utilize either non-proprietary or non-vendorunique key Application Programming Interfaces (APIs). The contractor’s design 

approach shall be applied to all subsystems and components. As part of its open 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

10 

system management plan, the contractor will be required, at a minimum, to 

describe how the proposed system architecture meets these goals, including the 

steps taken to use non-proprietary or non-vendor unique COTS or reusable NDI 

components wherever practicable. 

• Module Coupling – The contractor’s design approach shall result in 

modules that have minimal dependencies on other modules (loose 

coupling), as evidenced by simple, well-defined interfaces and by the 

absence of implicit data sharing. The purpose is to ensure that any 

changes to one module will not necessitate extensive changes to other 

modules, and hence facilitate module replacement and system 

enhancement. The approach used to determine the level of coupling and 

the design trade-off approach shall be described. 

• Module Cohesion – The contractor’s design shall result in modules that 

are characterized by the singular assignment of identifiable and discrete 

functionality (high cohesion). The purpose is to ensure that any changes to 

system behavioral requirements can be accomplished by changing a 

minimum number of modules within the system. The approach used to 

determine the level of cohesion and the design trade-off approach shall be 

described. 

c. System Requirements Accountability – The contractor will be required to ensure 

that all system requirements (including those contained in the Initial Capabilities 

Document, Capabilities Development Document, Capabilities Production 

Document, and in this Section C) are accounted for through a demonstrated 

ability to trace each requirement to one or more modules that consist of 

components that are self-contained elements with well-defined, open and 

published interfaces implemented using open standards. 

d. Inter-component Dependencies – The contractor’s design approach shall result in 

a layered system design, maximizing software independence from the hardware, 

thereby facilitating technology refresh. The design shall be optimized at the 

lowest component level to minimize inter-component dependencies. The layered 

design shall also isolate the application software layers from the infrastructure 

software (such as the operating system) to enhance portability and to facilitate 

technology refresh. The design shall be able to survive a change to the computing 

infrastructure with minimal or no changes required to the application logic. The 

interfaces between the layers shall be built to open standards or available to the 

Government with at least Government Purpose Rights. The system architecture 

shall minimize inter-component dependencies to allow components to be 

decoupled and re-used, where appropriate, across various Naval programs and 

platforms. 

e. Modular Open Systems Approach (MOSA) – The contractor shall describe its 

rationale for the modularization choices made to generate the design. The 

contractor’s design approach shall produce a system that consists of hierarchical 

collections of software and hardware configuration items (components). These 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

11 

components shall be of a size that supports competitive acquisition as well as 

reuse. The contractor’s design approach shall emphasize the selection of 

components that are available commercially or within the DoD, to avoid the need 

to redevelop products that already exist and that can be re-used. The contractor’s 

rationale must explicitly address any tradeoffs performed, particularly those that 

compromise the modular and open nature of the system. 

f. MOSA Objectives – The contractor shall specify how it plans to use MOSA to 

enable the system to adapt to evolving requirements and threats; accelerate 

transition from science and technology into technology and deployment; facilitate 

systems reconfiguration and integration; reduce the development cycle time and 

total life cycle cost; maintain continued access to cutting edge technologies and 

products from multiple suppliers; and mitigate the risks associated with: (1) 

technology obsolescence, (2) being locked into proprietary or vendor-unique 

technology, and (3) reliance on a single source of supply over the life of the 

system. 

g. MOSA Support Plan – The contractor shall provide a plan for supporting the 

proposed Modular Open System Approach, including, but not limited to, plans for 

integrating the systems under development both internally and externally, a 

strategy for maintaining the currency of the technology (through COTS and other 

reusable NDI insertions, technology refresh strategies, and other appropriate 

means) and creation of different processes necessary to support MOSA (more 

information on MOSA is available from the Open Systems Joint Taskforce 

(OSJTF) at http://www.acq.osd.mil/osjtf/index.html). 

h. Design Information Documentation – The contractor shall document and model 

the system or component (e.g., software, hardware, middleware) design 

information using industry standard formats, (e.g., Unified Modeling Language). 

It shall also document and model how it will use tools that are capable of 

exporting model information in a standard format (e.g., Extensible Markup 

Language Metadata Interchange (XMI) and AP233/ISO 10303). The contractor 

shall identify the proposed standards and formats to be used. The contractor shall 

maintain the design information, including any models used, so that it is current 

with the as-built system. 

i. Technology Insertion – The contractor’s architectural approach shall support the 

rapid and affordable insertion and refreshment of technology through modular 

design, the use of open standards and open interfaces. The contractor shall define 

the functional partitioning and the physical modularity of the system to facilitate 

future replacement of specific subsystems and components without impacting 

other parts of the system and to encourage third-party vendor’s participation. 

j. Life-Cycle Sustainability – The contractor shall consider use of COTS/NDI and 

open standards to enhance the system’s life-cycle sustainability by implementing 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

12 

performance-based logistics (PBL) arrangements to sustain the components 

through their life cycle. 

k. Interface Design and Management – The contractor shall: 

i. Clearly define and describe all component and system interfaces; 

ii. Define and document all subsystem and configuration item (CI) level 

interfaces to provide full functional, logical, and physical specifications; 

iii. Identify processes for specifying the lowest level (i.e. subsystem or 

component) at and below which it intends to control and define interfaces 

by proprietary or vendor-unique standards and the impact of that upon its 

proposed logistics approach. Interfaces described shall include, but not be 

limited to, mechanical, electrical (power and signal wiring), software, 

firmware, and hardware interfaces; 

iv. Identify the interface and data exchange standards between the 

component, module or system and the interconnectivity or underlying 

information exchange medium; 

v. Consider using these interfaces to support an overall information 

assurance strategy that implements Information Assurance (IA) Processes 

in accordance with DoD Instruction 8500.2 (dated February 6, 2003) and 

[Insert any PEO-specified documents]; 

vi. If applicable, select external interfaces from existing open or Government 

standards with an emphasis on enterprise-level interoperability. The 

contractor shall describe how its selection of interfaces will maximize the 

ability of the system to easily accommodate technology insertion (both 

hardware and software) and facilitate the insertion of alternative or 

reusable modular system elements; 

vii. Describe the extent that the change or configuration management process 

proposed will use “community of interest” teams in an integrated team 

approach to effectively identify how individual changes impact the 

system’s internal or external interfaces and information exchange 

standards.

l. Treatment of Proprietary or Vendor-Unique Elements – The contractor shall 

explain the use of proprietary, vendor-unique or closed components or interfaces. 

If applicable, the contractor will define its process for identifying and justifying 

proprietary, vendor-unique or closed interfaces, code modules, hardware, 

firmware, or software to be used. When interfaces, hardware, firmware, or 

modules that are proprietary or vendor-unique are required, the contractor shall 

demonstrate to the Government that those proprietary elements do not preclude or 

hinder other component or module developers from interfacing with or otherwise 

developing, replacing, or upgrading open parts of the system. 

m. Open Business Practices – The contractor shall demonstrate that the modularity of 

the system design promotes the identification of multiple sources of supply and/or 

repair, and supports flexible business strategies that enhance subcontractor 

competition. The contractor shall conduct a market survey to identify candidate 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

13 

COTS, proprietary, open source software (OSS) and other reusable NDI capable 

of achieving the performance requirements of solutions that it proposes to custom 

build. The survey results shall be provided to support each major review. COTS 

and other reusable NDI selection criteria shall address the following factors, at a 

minimum: Electrostatic Sensitive Device (ESD) immunity; Electromagnetic 

Interference/Electromagnetic Compatibility (EMI/EMC); Integrated Logistics 

Support requirements; safety; reliability consistent with the environment 

described in the System Specification; maintainability; subsystem performance 

trade-offs; power, cooling, and physical form factors; open system architecture 

break out compatibility; cost; manufacturer’s quality assurance provisions; market 

acceptability; obsolescence; adequacy of available technical and intellectual 

property data and re-procurement data rights on the product; and merits of the 

software supported by the product. Decisions leading to the selection of specific 

COTS, NDI, proprietary or OSS products should be supported by appropriate 

analysis (e.g. with test results, architectural suitability, “best value” assessments, 

etc.). 

n. Reuse of Pre-existing or Common Items – The contractor shall re-use pre-existing 

or common items unless a determination is made to not re-use. Exceptions to 

reuse of pre-existing items must be accompanied by justification, such as cost 

(both of adoption and life cycle support), schedule, functional and non-functional 

performance, etc. The general objective of these efforts shall be the development 

of a common system and/or common elements or components which meet the 

performance requirements of the various U.S. Navy or Marine Corps platform 

missions, where commonality offers the greatest technical and cost benefits. 

o. Third Party Development – The contractor shall address how it will provide to the 

Government information needed to support third-party development and delivery 

of competitive alternatives of designs for software or other components or 

modules on an ongoing basis. The contractor shall provide a list of those 

proprietary, vendor-unique elements that it requests be exempt from this review. 

p. Life Cycle Management and Open Systems – The contractor’s architecture shall 

provide for insertion of COTS into the system and demonstrate that COTS, 

reusable NDI, and other components are logistically supported throughout the life 

cycle. The contractor shall describe and demonstrate the strategy for reducing 

product or system and associated supportability costs through insertion of COTS 

and other reusable COTS or NDI products. The contractor shall establish a 

process to logistically support COTS or NDI products. The contractor shall 

describe the availability of commercial repair parts and repair services, facilities, 

and manpower required for life cycle support and demonstrate they are adequate 

to ensure long term support for COTS or NDI products. The contractor shall 

provide the proposed methodology for pass through of COTS warranties to the 

Government. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

14 

q. Use of Standards – In designing the system(s), the contractor shall use the 

following standards in descending order of importance: 

• Standards as specified within the contract 

• Commercial standards 

o Standards developed by international or national industry standards 

bodies that have been widely adopted by industry. Examples of widely 

adopted standards are: 

1. SQL for databases (e.g., SQL for databases ANSI 

ISO/IEC 9075-1, ISO/IEC 9075-2, ISO/IEC 9075-3, 

ISO/IEC 9075-4, ISO/IEC 9075-5) 

2. HTML for presentation layer (e.g., XML 1.0 

www.webstandards.org) 

3. XML for data transfer 

4. Web Services for remote system calls 

o Standards adopted by industry consensus-based standard bodies and 

widely adopted in the market place. 

o De facto standards (those widely adopted and supported in the market 

place). 

Note: Standards that are not specified within this contract or that are 

modified must be submitted to and approved by the Government Program 

Manager prior to use. 

There is additional guidance to Naval acquisition managers intended to provide improved 

visibility into Offeror’s and contractor’s software development processes to ensure there 

are well-documented, effective software processes and continuous process improvement 

practices in place during contract performance. This guidance and requirements are 

contained in the Software Process Improvement Initiative (SPII) Policy. Mandatory and 

discretionary elements of the SPII Policy are described in the policy document. The SPII 

Policy and accompanying documents are available on NOA website at 

https://acc.dau.mil/CommunityBrowser.aspx?id=180966&lang=en-US. 

Statement of Work (SOW)12

Within the SOW there shall be a “Technical Approach” section. This section describes 

the Navy and Marine Corps' expectations regarding the technical approach to be taken by 

the Offerors. It is recommended that these expectations be based on the characteristics of 

the system to be developed and not mandate any specific approach, but rather define the 

criteria with which proposed approaches will be evaluated. In some cases, however, 

specific approaches may be required based on Navy and Marine Corps needs and the 

system to be acquired. Within the “Technical Approach” section, there shall be a 

subsection titled “Software Engineering Approach,” containing at a minimum the 

following language: 

 

12 Assistant Secretary of the Navy (Research, Development and Acquisition)’s 

Memorandum on “Software Process Improvement Initiative Contract Language,” dated 

November 17, 2006.
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

15 

Software Engineering: The contractor shall define a software development approach 

appropriate for the computer software effort to be performed under this solicitation. This 

approach shall be documented in a Software Development Plan (SDP) (CDRL AOOx). 

The contractor shall follow this SDP for all computer software to be developed or 

maintained under this effort. 

The SDP shall define the Offeror's proposed life cycle model and the processes used as a 

part of that model. In this context, the term “life cycle model” is as defined in IEEE/EIA 

Std. 12207.0. The SDP shall describe the overall life cycle and shall include primary, 

supporting, and organizational processes based on the work content of this solicitation. 

In accordance with the framework defined in IEEE/EIA Std. 12207.0, the SDP shall 

define the processes, the activities to be performed as a part of the processes, the tasks 

which support the activities, and the techniques and tools to be used to perform the tasks. 

Because IEEE/EIA Std. 12207 does not prescribe how to accomplish this task, the 

Offeror shall provide this detailed information so the Navy and Marine Corps can assess 

whether the Offeror’s approach is viable. 

The SDP shall contain the information defined by IEEE/EIA Std. 12207.1, section 5.2.1 

(generic content) and the Plans or Procedures in Table 1 of IEEE/EIA Std. 12207.1. In 

all cases, the level of detail shall be sufficient to define all software development 

processes, activities, and tasks to be conducted. Information provided must include—at 

a minimum--specific standards, methods, tools, actions, strategies, and responsibilities 

associated with development and qualification. 

Software Code Walkthroughs: In addition, another step in the software development 

management process that supports OA and can be included in Section C of the contract is 

the requirement to hold Software Code Walkthroughs. As an example, this requirement 

may look like this: 

“The contractor shall conduct periodic code walkthroughs during the development 

Phase, as specified by the Statement of Work (SOWW) or by Technical 

Instruction (TI). Senior technical personnel from the development team will 

review the code and unit test plans that have been developed for a Technical 

Design Specification (TDS). The purpose of the review is to identify that the code 

adheres to the program’s development standards, is technically sound, meets the 

design articulated in the related TDS, and that the unit test plan for the code under 

review is documented in accordance with QA/Test standards as defined. The 

Navy reserves the right to have one or more representatives, on a not-to-interfere 

basis, observe any and all code walkthroughs and create a detailed report.” 

Code walkthroughs will not be conducted until the code has appropriate markings with 

respect to intellectual property rights. These walkthroughs help support the OA principle 

of design disclosure. 

Data Management and the Integrated Development Environment (IDE): The IDE is 

an integral tool for facilitating data management and design disclosure, including a 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

16 

requirement to maintain an IDE as part of contract performance is important to the 

Government’s interests. The following is sample contract language for this requirement: 

“The contractor shall establish and maintain a secure Integrated Data 

Environment (IDE) for hosting all data used on or produced in support of this 

contract, including cost, schedule, and technical data and deliverables. 

This purpose of the IDE is to create a seamless, collaborative data environment 

for the contractor and government team which contains all pertinent data about 

the project throughout its development and delivery. This data management 

program, including IDE structure, format, processes, and procedures, shall be 

documented as part of the contract Program Management Plan. 

The contractor shall provide the Government team access to all data listed in the 

Data Accession List (DAL) by actively using the IDE. The DAL shall contain the 

list of all data generated in support of this contract. Deliveries of data in addition 

to the IDE shall be as indicated in the CDRL attachment. 

Data shall be protected in accordance with (IAW) the appropriate Program 

Protection Plans and Information Assurance guidelines. The Government reserves 

the right to witness all contractor efforts to accomplish the Statement of Work 

(SOW) requirements and maintains the right to comment on processes. 

All products and data developed under this Contract shall be delivered with 

unlimited usage rights, as defined in Section H, DFARS clause 252.227.7013, 

7014, and 7017. 

Product Reuse Demonstration: As part of system acceptance, the contractor shall 

demonstrate the steps necessary to give third parties, as directed by the Government, the 

ability to rebuild the software for operational use in compatible processing hardware. 

This effort shall be comprehensive and require the contractor to perform the following 

activities: 

1. Inventory: A detailed inventory of all code files in the product baseline shall be 

conducted. This inventory shall extend to all third-party software not delivered 

within the terms of the contract but used in the system to form the working 

product. Third-party product descriptions and version information shall be 

required for all operating systems, applications, middleware, and device drivers. 

2. Inspection: File headers and any other company markings found in the source 

code shall be inspected to ensure clear indication that the Government has GPR to 

use the software delivered in the contract. 

3. Build Procedure Development: A build procedure shall be developed in sufficient 

detail to allow a third party to recreate the operational system on a compatible 

processing platform. This build procedure shall address the results of the code 

inventory and inspection to account for software that is not deliverable due to 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

17 

proprietary rights limitations such that the user can complete the installation 

process. 

4. Conduct Demonstration: The contractor shall conduct a formal demonstration of 

the build process using the product baseline software and approved procedures to 

show the software can be successfully ported to other third-party compatible open 

architecture processing systems. 

Technical Development Reviews: In some cases, the Government may want to require 

the contractor to perform Technical Development Reviews. The purpose of these 

reviews includes, but is not limited to, observing that the design documentation is 

complete, complies with the established design approach, is technically sound and will 

satisfy the functional requirements. The following is sample contract language for this 

requirement: 

Perform Technical Development Reviews 

The contractor shall conduct formal technical reviews as well as periodic 

Technical Development Reviews for major capability upgrades. The contractor, 

in concert with the Government, shall develop a Design Review Plan for the 

conduct of formal reviews, using agreed upon tailoring of the Technical Review 

Manual (TRM) (Attachment J-9) and/or the SEMP. The purpose of these reviews 

is to observe that the design documentation is complete, complies with the 

established design approach, is technically sound and will satisfy the functional 

requirements as defined in the approved Functional Design Specification 

documents. Senior technical personnel from the development team will review 

each design approach and Technical Design Specification as it is completed to 

ensure it has been properly documented as defined in the CDRL. The Navy will 

establish entry/exit criteria and acceptance/rejection criteria for each formal 

review and will document these criteria in a Technical Instruction (TI). These 

Technical Reviews, both formal and informal, are to be scheduled in the Program 

Master Schedule so they are visible to the Navy. 

Technical Review Objectives:

a. Assess the development maturity based on technical development goals, systems 

engineering events and accomplishments, and empirical test data supporting 

progress to date. 

b. Ensure operational, functional, performance, information assurance, cost, 

schedule requirements and objectives, designs, implementations, technical 

performance measurements, and technical plans are being tracked, are on 

schedule, and are achievable within existing programmatic constraints. 

c. Assess the system requirements and allocations to ensure that requirements are 

unambiguous, consistent, complete, feasible, verifiable, and traceable to top-level 

requirements. 

d. Demonstrate that the relationships, interactions, interdependencies, and interfaces 

between required items and externally interfacing items, system functions, 

subsystems, and system elements (including operators and maintainers), as 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

18 

appropriate, have been addressed. 

e. Assess the degree of openness of the emerging system, its degree of Naval 

Enterprise reuse, and critique any tradeoff decisions made. 

OA Approach to Developing to a Technical Review: 

General and specific OA objectives shall be developed to evaluate the degree of system 

openness as defined in the Open Architecture Assessment Tool (OAAT) and activities 

defined in the Open Systems Management Plan (OSMP). 

1. Define OA objectives for each technical review as defined in the System 

Engineering Technical Review (SETR) manual 

2. Tailor the OA objectives to what can be accomplished by the time of the review 

and for which there is supporting technical information 

3. Map OA objectives to specific metrics from the OAAT and the results of 

activities defined in the OSMP 

4. Record the OA objectives and the results of the metrics and activities as an input 

to the technical review 

Example OA Technical Review Objectives: 

1. The OA emphasis for Alternative Systems Review (ASR) is on innovation and 

competition. A specific focus will be to evaluate the degree to which functionality 

and solutions are drawn from a diversified range of large and small businesses 

and maximize affordable use of COTS/NDI. 

2. The OA emphasis for System Requirements Review (SRR) is on collaboration 

and the accessibility and availability of data. A specific focus will be to evaluate 

the consistency between the system requirements and open system design 

considerations, ensuring that the preferred system solution does not contain 

design specific solutions. 

3. The OA emphasis for System Functional Review (SFR) is on enterprise 

architectures, strategic reuse, and the potential for small business participation 

throughout the program lifecycle. A specific focus will be to evaluate whether the 

system functional definition follows modular design tenets and well-defined 

interfaces to effectively manage risks of obsolescence and dependence upon a 

sole source of supply. 

4. The emphasis of the OA objectives for Preliminary Design Review (PDR) is on 

the requirements tradeoffs to meet performance. A specific focus will be to 

evaluate the degree to which inter-component dependencies preclude affordable 

and lower-risk future open system capability insertion, which will drive cycletime for capability improvements. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

19 

Chapter B: EXAMPLES OF SECTION H (SPECIAL CONTRACT 

REQUIREMENTS) LANGUAGE 

Section H of the Request for Proposal (RFP) and the resulting contract contains special 

clauses that can be incorporated into contracts as appropriate. The following are 

examples taken from contracts that may be useful to Programs. An additional helpful 

reference is the Department of Defense Handbook for Preparation of Statement of Work 

(SOW).13

This section contains only recommended guidance, and is offered with the understanding 

that individual PEOs and programs can be flexible in selecting those items needed to 

meet their needs. Programs should not feel that they need to address all of the items 

contained in these recommendations. 

There is additional guidance to Naval acquisition managers intended to provide improved 

visibility into Offeror’s and contractor’s software development processes to ensure there 

are well-documented, effective software processes and continuous process improvement 

practices in place during contract performance. This guidance and requirements are 

contained in the Software Process Improvement Initiative (SPII) Policy. Mandatory and 

discretionary elements of the SPII Policy are described in the policy document, which is 

available on NOA website at: 

https://acc.dau.mil/CommunityBrowser.aspx?id=180966&lang=en-US. 

CLAUSE H - _____: REQUIREMENT FOR AN OPEN SYSTEM MANAGEMENT 

PLAN 

The contractor shall submit to the Government an Open System Management Plan as set 

for the in the Contract Data Requirements List (CDRL). At a minimum, the plan shall 

address: 

Technical Approach and Processes

Open Systems Approach and Goals. The contractor shall prepare and submit for 

Government approval its Open System Management Plan which shall include its 

approach for using modular design, standards-based interfaces, and widely-supported, 

consensus-based standards to achieve the following goals. At a minimum, the plan shall 

include: 

a. OPNAV OA Requirements – A detailed description of the contractor’s 

approach for addressing a system architecture that incorporates 

appropriate considerations for reconfigurability, portability, 

 

13 The DoD Handbook for Preparation of Statement of Work (SOW) is available on the 

web at https://www.acqsolinc.com/mockups/7steps/library/DODhandbook.pdf. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

20 

maintainability, technology insertion, vendor independence, reusability, 

scalability, interoperability, upgradeability, and long-term supportability 

as defined by the Naval Enterprise in the 23 Dec 2005 Office of the Chief 

of Naval Operations (OPNAV) requirement letter. 

b. Design Disclosure – Within the constraints of contractual data rights, a 

detailed description of the contractor’s approach to facilitate the sharing of 

system or component (e.g., software, hardware, middleware) design 

information. The contractor shall describe how its design will be 

documented and modeled using industry standard formats (e.g., Unified 

Modeling Language), and how it will use tools that are capable of 

exporting model information in a standard format (e.g., Extensible Markup 

Language Metadata Interchange (XMI) and AP233/ISO 10303). The 

Offeror shall identify the proposed standards and formats to be used. 

c. Technology Insertion and Refresh – A detailed description of how the 

contractor’s proposed system will allow for rapid and affordable 

technology insertion and refresh. At a minimum, the contractor shall 

describe how the proposed system will allow incremental systems 

improvement through upgrades of individual hardware or software 

modules with newer modular components. At a minimum, the description 

shall address how the contractor’s architectural approach will support this 

requirement including how components from third-party providers and 

reuse sources shall be included. 

d. Asset Reuse – A detailed description of the steps taken to reduce 

acquisition of duplicative system components where possible. At a 

minimum, the contractor shall describe what artifacts from the ________ 

or common components it intends to use within its proposed solution. 

e. Modular Open Systems Approach (MOSA) – A detailed description of 

the contractor’s modular, open systems approach. At a minimum, the 

contractor shall address: 

i. Plans for integrating the systems both internally and with 

external systems; 

ii. The means for ensuring conformance to open standards and 

profiles throughout the development process, as discussed in 

Section C; 

iii. A description of how the technical approach ensures having 

access to mature as well as the latest technologies by 

establishing a robust, modular, and evolving architecture based 

on open standards; 

iv. A description of the strategy for maintaining the currency of 

technology (e.g., through COTS or reusable NDI insertion, 

technology refresh strategies, and other appropriate means); 

and 

v. Identification of processes for: 

(1) Isolating functionality through the use of modular 

design; 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

21 

(2) Evaluating modular open system baseline 

standards, defining and updating profiles, and 

evaluating and justifying new or vendor-unique 

profiles; 

(3) Validating implementation conformance to 

selected profiles; 

(4) Managing application conformance to selected 

profiles; and 

(5) Training in use of profiles. 

f. MOSA as an Enabler of OA Objectives – A detailed description of how 

the contractor intends to use a modular open systems approach as an 

enabler to achieve the following objectives: 

i. Adapt to evolving requirements and threats as identified by the 

Government; 

ii. Enhance interoperability and the ability to integrate new 

capabilities without redesign of entire systems or large portions 

thereof; 

iii. Accelerate transition from science and technology into acquisition 

and deployment; 

iv. Facilitate systems reconfiguration and integration; 

v. Reduce the development cycle time and total life-cycle cost; 

vi. Maintain continued access to cutting edge technologies and 

products from multiple suppliers; and 

vii. Mitigate the risks associated with reliance on a single source of 

supply over the life of the system, to include, but not be limited to, 

technology obsolescence and dependence on proprietary or 

vendor-unique technology. 

g. Life-Cycle Supportability – A detailed description of how the contractor 

intends to enhance life-cycle supportability by implementing performancebased logistics arrangements to sustain the components through their life 

cycle. 

h. Employ a Layered, Modular Architecture – A detailed description on 

how the proposed system architecture is layered, modular, and makes 

maximum use of Commercial-Off-the-Shelf/Non-developmental Item 

(COTS/NDI) hardware, operating systems, and middleware that utilize 

non-proprietary key Application Programming Interfaces (APIs) whenever 

practicable. 

i. Traceability of System Requirements – A detailed description of the 

contractor’s approach for ensuring that all system requirements (including 

those contained in the Initial Capabilities Document, Capabilities 

Development Document, and in Section C) are accounted for through a 

demonstrated ability to trace each requirement to one or more modules. 

Modules consist of components (one of the parts that make up a system 

and may be hardware and/or software) which are self-contained elements 

with well-defined, standards-based and published interfaces. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

22 

j. Minimize Inter-Component Dependencies – A detailed description of 

the contractor’s approach for designing a system that, to the maximum 

extent practicable, minimizes inter-component dependencies and allows 

components to be decoupled and re-used, where appropriate, across 

various Naval programs or replaced by competitive alternatives. 

k. Rationale for Modularization Choices – A detailed description of the 

contractor’s rationale for the modularization choices made to generate the 

design. At a minimum, the rationale shall explicitly address any tradeoffs 

performed, particularly those that compromise the modular and open 

nature of the system. 

l. Future System Upgrades – A detailed description of how a modular 

design strategy will be demonstrated in all aspects of future system 

upgrades. 

i. In addressing the specified requirements, the plan, at a minimum, 

must demonstrate how the modular design strategy applies, and the 

effect it will have on future systems upgrades. 

ii. The contractor shall describe an orderly planned process to address 

migration of proprietary, vendor-unique, or closed system 

equipment or interfaces to a modular open systems design when 

technological advances are available or when operational 

capability is upgraded. The proprietary, vendor-unique or closed 

systems implementation shall also be reflected in the contractor’s 

system level life cycle cost estimates. 

iii. The modular design approach shall either mitigate or partition – at 

the lowest subsystem or component level – proprietary, vendorunique or closed system implementation to avoid out-year 

supportability issues and diminished manufacturing and repair 

sources. 

Interface Design and Management. The contractor shall describe how it will clearly 

define component and system interfaces. At a minimum, the contractor shall address the 

following: 

a. The contractor shall describe how it will define and document all 

subsystem and configuration item (CI) level interfaces to provide fully 

functional, physical and electrical specifications. 

i. The contractor shall identify processes for specifying the lowest 

level (i.e. subsystem or component) at and below which it intends 

to control and define interfaces by proprietary, vendor-unique 

standards, as well as the impact of those standards upon the 

proposed modularity and logistics approach. 

ii. Interfaces described shall include, but not be limited to, 

mechanical, electrical (e.g., power and signal wiring), software 

(e.g., API), firmware, and hardware. 

iii. The contractor shall address the interface and data exchange 

standards between the component, module or system and the 

interconnecting or underlying information exchange medium. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

23 

iv. The contractor shall state how these interfaces support an overall 

Information Assurance strategy that provides a defense in depth in 

accordance with CJCSI 3170.01E and [Add appropriate PEOspecified requirements]. 

b. The contractor shall describe how interfaces will be selected from existing 

open or Government standards with emphasis on system-level or 

enterprise-level (where applicable) interoperability. The contractor shall 

describe how its selection of interfaces will maximize the ability of the 

system to readily accommodate technology insertion (both hardware and 

software) and facilitate the insertion of alternative or reusable modular 

system elements. 

c. The contractor shall describe how its system will allow for: 

i. Quickly interconnecting, reconfiguring, and assembling existing 

systems, subsystems, and components; 

ii. Interchanging and using information, services and/or physical 

items among components within a system; 

iii. Interchanging and using information, services and/or physical 

items among systems within an integrated architecture, platform, 

PEO, Community of Interest, or a DoD component; 

iv. Supporting reuse of software and the common use of components 

across various product lines; and 

v. Transferring a system, component, or data, from one hardware or 

software environment to another. 

d. The contractor shall describe the degree to which the defined interfaces 

will support an Information Assurance (IA) strategy that implements IA 

Processes in accordance with DoD Instruction 8500.2 (dated February 6, 

2003) and [Add appropriate PEO-specified requirements]. 

e. The contractor shall describe the degree to which proposed interfaces use 

defined commercial or Government standards as called for in Section C. 

Treatment of Proprietary or Vendor-Unique Elements. The contractor shall justify 

any use of proprietary, vendor-unique, or closed components, including but not limited 

to COTS, and interfaces in current or future designs. The contractor shall define its 

process for identifying and justifying proprietary, vendor-unique or closed interfaces, 

code modules, hardware, firmware, or software to be used. 

a. The contractor shall describe how it will employ hardware and/or 

software partitioning or other design techniques to isolate all proprietary, 

vendor-unique portions of interfaces, hardware, firmware and modules – 

at the lowest subsystem or component level. 

b. The contractor shall include documentation to support the rationale for a 

decision to integrate proprietary, vendor-unique or closed system 

hardware and/or software functions within the proposed system. 

c. The contractor shall describe how the integration of closed or 

proprietary, vendor-unique equipment, interfaces, data systems or 

functions due to a unique or specific system requirement will not 

preclude or hinder other component or module developers from 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

24 

interfacing with or otherwise developing, replacing, or upgrading open 

parts of the system. 

d. The contractor shall identify and take steps to prevent the open elements 

of the system from intertwining with proprietary or vendor-unique 

elements in a manner that restricts or limits the ability to replace or 

upgrade the open elements using an open competitive selection process. 

e. The contractor shall describe and demonstrate that the modularity of the 

system design promotes identification of multiple sources of supply 

and/or repair, and supports flexible business strategies that enhance subcontractor competition. 

i. The contractor shall conduct a market survey to identify candidate 

COTS and other reusable NDI, including Government IP assets, 

capable of achieving the performance requirements of solutions 

that it has proposed to custom build. Sound “market research” 

will help to identify opportunities to use COTS or re-use existing 

components and is called for by the OSJTF. The COTS and other 

NDI selection criteria shall, at a minimum, address the following 

factors: Electrostatic Sensitive Device (ESD) immunity; 

Electromagnetic Interference/Electromagnetic Compatibility 

(EMI/EMC); Integrated Logistics Support requirements; Safety; 

Reliability (to include the hardware’s designed-in ability to 

accommodate such stresses as electrical power fluctuation 

(voltage, current, frequency)), temperature, shock, vibration, 

operating time (duration), changes in atmospheric pressure, and 

humidity consistent with the environment described in the System 

Specification; Maintainability; Subsystem performance trade-offs; 

Power, cooling, and physical form factors; Open system 

architecture break out compatibility; Cost; Manufacturer’s quality 

assurance provisions; Market acceptability; Obsolescence; 

Adequacy of available technical and intellectual property data and 

reprocurement data rights on the product; and Merits of the 

software supported by the product. 

ii. The Offeror shall identify those pre-existing items (Government IP 

assets, NDI, and COTS) it will evaluate for reuse. At a minimum, 

the Offeror shall describe what artifacts from the ____________ it 

intends to use within its proposed solution. Exceptions to reuse of 

pre-existing items must be accompanied by justification, such as 

cost (both of adoption and life cycle support), schedule, functional 

and non-functional performance, etc. 

f. The contractor shall address how it will provide information needed to 

support third-party development and delivery of competitive alternatives 

or designs for software or other components or modules on an ongoing 

basis. This information may be used as part of peer review processes, to 

support Integrated Product Teams (IPTs), and to facilitate competition for 

component suppliers. The Offeror will provide a list of those proprietary 

or vendor-unique elements that it requests be exempt from this review. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

25 

Life Cycle Management and Open Systems. The contractor shall describe and 

demonstrate the strategy for reducing product or system and associated supportability 

costs through insertion of COTS or reusable NDI products. 

a. The contractor shall identify and demonstrate a strategy to insert COTS 

technologies and other reusable NDI into the system and demonstrate that 

COTS, other reusable NDI, and other components are logistically 

supported throughout the system’s life cycle. 

i. The contractor shall identify specific hardware and software 

elements of the subsystem designs that are planned for COTS and 

other reusable NDI replacement and the supportability plans for 

those elements. 

ii. The contractor shall demonstrate how the subsystem design allows 

for timely and cost-effective replacement of subsystem elements or 

modules. The COTS/NDI selection processes shall be specifically 

addressed, including validation of those processes. 

b. The contractor shall provide a description of processes that will be 

established and demonstrate that COTS and other reusable NDI products 

are logistically supported. 

c. The contractor shall describe the availability of commercial repair parts 

and repair services, facilities and manpower required for life cycle support 

and demonstrate that they are adequate to ensure long term support for 

COTS and other reusable NDI products. The Offeror shall provide the 

proposed methodology for pass through of COTS warranties to the 

Government. 

Clause H -________ : EARLY AND OFTEN TECHNICAL DISCLOSURE 

The contractor shall submit a detailed plan for making design and interface information 

available as soon as possible after it is defined or established. The contractor shall 

establish and maintain a process that will provide “early and often” design disclosure 

directly to the Government or to third-party contractors via Government-established 

access (e.g., the Naval Sea Systems Command Software/Hardware Asset Reuse 

Enterprise (SHARE) library, its successor, or other Navy and Marine Corps 

repository/library resources) to in-process design documentation and computer software. 

Access to this information shall be supported using industry standards and at minimal 

cost to the Government. The exchange of information shall be structured so as to protect 

the Offeror's and third-party developers' proprietary or vendor-unique rights in the 

information. The plan shall address how comments from the Government and third-party 

contractors are resolved. The plan shall describe a schedule of when non-proprietary 

licenses, source code, drawings, repair and engineering documentation will be provided 

to the Government and third-party contractors at specified key events or at defined 

intervals. 

[Note: Firmware is considered to be a category of Computer Software (CS), as defined 

in the DFARS.] 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

26 

Identification of Open Source Software (OSS) in contractor Deliverable Items

The following H Clauses present two alternatives for addressing the identification of OSS 

in items delivered to the Government by contractors. The first clause has been in use for 

several years and served as our original attempt to help programs understand the OSS 

they may be acquiring in their contractor-delivered items. The second clause is a recent 

update that we believe improves upon the original. 

Clause H - _________ : Identification of Commercial Technical Data/Computer 

Software (Including Open Source Software) Use and Modifications 

Commercial 

Technical 

Data/Computer 

Software Title and 

Version # 

* 

If Open 

Source 

Software, 

Open Source 

License and 

Version # 

** 

Name of 

contractor 

Delivering 

Commercial 

Software 

*** 

Technical Use/ 

Implementing 

Approach 

  

If OSS, Was 

OSS modified 

by contractor? 

** *** 

If OSS and OSS 

was Modified, was 

OSS modified by 

incorporation into a 

third party’s 

software? 

****** 

 

* The complete title and version number of the Commercial Software should be listed. If 

the line item is Open Source Software that was downloaded from a website, the website 

address should also be provided. 

** The Open Source Software license and version number should be listed. If a version 

number is not available, the contractor should state no version number. 

\*** Corporation, individual, or other person as appropriate. 

  The contractor should describe the functionality of the Commercial (Open Source) 

Software, and where it is being used within the larger computer software deliverable (if 

applicable). 

** *** If the contractor is delivering OSS, the contractor should state whether it has 

modified the Open Source Software. 

****** If the contractor is delivering OSS that it has modified, the contractor should 

state whether the Open Source Software was modified by combining with another party’s 

non-open source software. If the other party is a third party, the third party’s non-open 

source computer software may be licensed with distribution restrictions which would not 

allow the Government to accept delivery of the software combination. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

27 

Clause H - _____________ : IDENTIFICATION AND ASSERTION OF 

RESTRICTIONS ON TECHNICAL DATA –COMMERCIAL ITEM AND 

COMMERCIAL COMPUTER SOFTWARE, INCLUDING OPEN SOURCE 

SOFTWARE 

THIS CLAUSE IS UNDERGOING ADDITIONAL REVIEW and will be posted when 

the review is complete 

Clause H - _____________ : SPECIALLY NEGOTIATED LICENSE RIGHTS

[Fill in based on the Section B Data Rights Table.] 

1. The United States Government has Special License Rights in the Data. Special 

License Rights means the right to: 

(i) Use, modify, reproduce, perform, display, or disclose the Data within the 

Government without restriction; and 

(ii) Release or disclose the Data outside the Government and authorize 

persons to whom the release or disclosure has been made to use, modify, 

release, perform, display, or disclose that Data for United Sates 

Government Purposes. 

2. Data, as used in this clause, means all the information delivered to the 

Government as required by CDRL. 

3. United States Government Purposes, as used in this clause, has the same 

definition as Government Purpose found at DFARS 252.227-7013 and DFARS 252.227-

7014, except 

(i) It does not include foreign military sales (FMS) and Foreign Military 

Funded (FMF), and 

(ii) It does not include allowing states and/or local governments to directly 

procure equipments utilizing the [Complete based on the program 

specifics.] for any purpose or to authorize parties other than the Federal 

Government to do so. 

Clause H – _____________ : SPECIAL PROVISIONS FOR THE PURPOSE OF 

CONFIGURATION CONTROL; REGARDING RELEASE AND DISCLOSURE 

OF [Complete based on program specifics.] SOFTWARE AND SOFTWARE 

DOCUMENTATION

It is specifically agreed that software and software documentation delivered by 

[contractor] to the Government as required by this contract or [Add other contracts as 

appropriate.] shall not be released or disclosed in whole or in part by [contractor], or by 

any subcontractor or entity acting on its behalf, to any entity, for U.S. Department of 

Defense purposes, other than to the U.S. Government entity described in section(s) H to 

this contract without first providing written notification to the contracting officer unless 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

28 

such notification would result in a violation of third-party agreements existing on the date 

of award of this contract, in which case no notification is required. Such disclosure 

restrictions shall remain in effect for the term of this contract and for six (6) months [or 

other period.] thereafter. 

Except as otherwise provided for above, nothing contained in this clause shall be 

construed to limit any intellectual property rights owned by, controlled by, or licensed to 

[contractor] and used in the performance of this contract. 

Clause H – __________: SPECIAL DEVELOPMENT LIMITATION PROVISIONS 

a) While the Government understands that the initial software development of [the 

specific program version X] will be performed on [platform], [contractor] specifically 

agrees that the completion of the [the specific program version X] software shall be 

successfully tested on a(n) [specific platform] product prior to delivery, unless otherwise 

approved by the Contracting Officer. 

b) [contractor] specifically agrees that the [the specific program version X] developed 

under this contract shall be developed on a(n) [specific platform] product, unless 

otherwise approved by the Contracting Officer. 

c) Notwithstanding the foregoing, [contractor] shall not be prohibited under this contract 

from performing design and development on, or making modification or enhancements to 

the software or documentation provided under this contract if such effort is performed 

outside of this contract. To the extent that [contractor] designs or develops or makes 

modification to such software or software documentation that is not prohibited by this 

clause, [contractor] shall only use the name or term [program name] when followed by 

“[contractor] Rev XX” [For “XX” insert applicable revision number] when referring to 

these versions in order to distinguish these versions of the software from the [program 

name] versions delivered under this contract and being maintained by the Government. 

The purpose of these restrictions in use of the name or term [program name] is to assure 

that the Government maintains configuration control of the [program artifacts] resulting 

from this contract. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

29 

Chapter C: RECOMMENDATIONS FOR SECTION L 

(INSTRUCTIONS TO OFFERORS) LANGUAGE 

Although the Guidebook was developed for mixed systems comprised of hardware, 

middleware and software elements, the recommended language can be easily tailored to 

reflect hardware- or software-only acquisitions. 

There is additional guidance to Naval acquisition managers intended to provide improved 

visibility into Offeror’s and contractor’s software development processes to ensure there 

are well-documented, effective software processes and continuous process improvement 

practices in place during contract performance. The guidance and requirements are 

contained in the Software Process Improvement Initiative (SPII) Policy. Mandatory and 

discretionary elements of the SPII Policy are described in the policy document, which is 

available along with other SPII documents on the NOA website at: 

https://acc.dau.mil/CommunityBrowser.aspx?id=180966&lang=en-US. 

Naval Open Architecture Guidance

Factor ( ): Technical Approach and Processes

The Offeror shall describe its proposed Naval Open Architecture (NOA) technical 

approach and processes to be employed in performing this contract. At a minimum, the 

Offeror shall describe its OA technical approach and processes in the following areas: 

Subfactor 1. Open Systems Approach and Goals. The Offeror shall describe its open 

systems approach for using modular design, standards-based interfaces, and widelysupported, consensus-based standards to achieve the following goals. At a minimum, the 

Offeror shall provide the following as part of its proposal: 

a. Address OPNAV OA Requirements – A detailed description of the 

Offeror’s approach for addressing a system architecture that incorporates 

appropriate considerations for reconfigurability, portability, maintainability, 

technology insertion, vendor independence, reusability, scalability, 

interoperability, upgradeability, and long-term supportability as called for 

by the 23 Dec 2005 Office of the Chief of Naval Operations (OPNAV) 

requirement letter, which is available at https://acc.dau.mil/oa. 

b. Design Disclosure – Within the constraints of contractual data rights, a 

detailed description of the Offeror’s approach to facilitate the sharing of 

system or component (e.g., software, hardware, middleware) design 

information in support of peer reviews and the incremental development 

process. [“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 

Surface Domain’s SHARE); 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. Each program has the flexibility to 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

30 

establish the most appropriate mechanism for its specific needs; with a goal 

of establishing a process that is both cost-effective and responsive to 

requests.] The Offeror shall describe how its design will be documented 

and modeled using industry standard formats (e.g., Unified Modeling 

Language), and how it will use tools that are capable of exporting model 

information in a standard format (e.g., Extensible Markup Language 

Metadata Interchange (XMI) and AP233/ISO 10303). The Offeror shall 

identify the proposed standards and formats to be used. 

c. Technology Insertion and Refresh – A detailed description of how the 

Offeror’s proposed system will allow for rapid and affordable technology 

insertion and refresh. For example, the Offeror should describe how the 

proposed system will allow incremental systems improvement through 

upgrades of individual hardware or software modules with newer modular 

components. At a minimum, the description shall address how the Offeror’s 

architectural approach will support this requirement including how 

components from third-party providers and reuse sources shall be included. 

d. Asset Reuse – A detailed description of the steps taken to reduce acquisition 

of duplicative system components where possible. At a minimum, the 

Offeror shall describe what artifacts from the ____________ or common 

components it intends to use within its proposed solution. 

e. Modular Open Systems Approach (MOSA) – A detailed description of 

the Offeror’s modular open systems approach. At a minimum, the Offeror 

shall address: 

i. Plans for integrating the systems both internally and with external 

systems; 

ii. The means for ensuring conformance to open standards and 

profiles, as discussed in Section C, throughout the development 

process; 

iii. A description of how the technical approach ensures having access 

to mature as well as the latest technologies by establishing a 

robust, modular, and evolving architecture based on open 

standards; 

iv. A description of the strategy for maintaining the currency of 

technology (e.g., through COTS or reusable NDI insertion, 

technology refresh strategies, and other appropriate means); and 

v. Identification of processes for: 

(1) Isolating functionality through the use of modular 

design; 

(2) Evaluating modular open system baseline standards, 

defining and updating profiles, and evaluating and 

justifying new or vendor-unique profiles; 

(3) Validating implementation conformance to selected 

profiles; 

(4) Managing application conformance to selected 

profiles; and 

(5) Training in use of profiles. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

31 

f. MOSA as an Enabler of OA Objectives – A detailed description of how 

the Offeror intends to use a modular open systems approach as an enabler to 

achieve the following objectives: 

i. Adapt to evolving requirements and threats as identified by the 

Government; 

ii. Enhance interoperability and the ability to integrate new 

capabilities without redesign of entire systems or large portions 

thereof; 

iii. Accelerate transition from science and technology into acquisition 

and deployment; 

iv. Facilitate systems reconfiguration and integration; 

v. Reduce the development cycle time and total life-cycle cost; 

vi. Maintain continued access to cutting edge technologies and 

products from multiple suppliers; and 

vii. Mitigate the risks associated with reliance on a single source of 

supply over the life of the system, to include, but be not limited to, 

technology obsolescence and dependence on proprietary or 

vendor-unique technology. 

g. Life-cycle Supportability – A detailed description of how the Offeror 

intends to enhance life-cycle supportability by implementing performancebased logistics arrangements to sustain the components through their life 

cycle. 

h. Employ a Layered Modular Architecture – A detailed description on how 

the proposed system architecture is layered, modular, and makes maximum 

use of Commercial-Off-the-Shelf/Non-Developmental Item (COTS/NDI) 

hardware, operating systems, and middleware that utilize non-proprietary 

key Application Programming Interfaces (APIs) whenever practicable. 

i. Traceability of System Requirements – A detailed description of the 

Offeror’s approach for ensuring that all system requirements (including 

those contained in the Initial Capabilities Document, Capabilities 

Development Document, and in Section C of this Solicitation) are accounted 

for through a demonstrated ability to trace each requirement to one or more 

modules. Modules consist of components (one of the parts that make up a 

system and may be hardware and/or software) which are self-contained 

elements with well-defined, standards-based and published interfaces. 

j. Minimize Inter-Component Dependencies – A detailed description of the 

Offeror’s approach for designing a system that, to the maximum extent 

practicable, minimizes inter-component dependencies and allows 

components to be decoupled and re-used, where appropriate, across various 

Naval programs or replaced by competitive alternatives. 

k. Rationale for Modularization Choices – A detailed description of the 

Offeror’s rationale for the modularization choices made to generate the 

design. At a minimum, the rationale shall explicitly address any tradeoffs 

performed, particularly those that compromise the modular and open nature 

of the system. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

32 

l. Future System Upgrades – A detailed description of how a modular design 

strategy will be demonstrated in all aspects of future system upgrades. 

i. In addressing the specified requirements, the proposal, at a 

minimum, must demonstrate how the modular design strategy 

applies, and the effect it will have on future systems upgrades. 

ii. The proposal shall describe an orderly planned process to address 

migration of proprietary, vendor-unique, or closed system 

equipment or interfaces to a modular open systems design when 

technological advances are available or when operational 

capability is upgraded. The proprietary, vendor-unique or closed 

systems implementation shall also be reflected in the Offeror’s 

system level life cycle cost estimates. 

iii. The modular design approach shall either mitigate or partition – at 

the lowest subsystem or component level – proprietary, vendorunique or closed system implementation to avoid out-year 

supportability issues and diminished manufacturing and repair 

sources. 

Subfactor 2. Interface Design and Management. The Offeror shall describe how it 

will clearly define component and system interfaces. At a minimum, the Offeror shall 

address the following: 

a. The Offeror shall describe how it will define and document all 

subsystem and configuration item (CI) level interfaces to provide fully 

functional, physical and electrical specifications. 

i. The Offeror shall identify processes for specifying the lowest level 

(i.e. subsystem or component) at and below which it intends to control 

and define interfaces by proprietary, vendor-unique standards, as well 

as the impact of those standards upon the proposed modularity and 

logistics approach. 

ii. Interfaces described shall include, but not be limited to, 

mechanical, electrical (power and signal wiring), software, firmware, 

and hardware. 

iii. The Offeror shall address the interface and data exchange 

standards between the component, module or system and the 

interconnecting or underlying information exchange medium. 

iv. The Offeror shall state how these interfaces support an overall 

Information Assurance strategy that provides a defense in depth in 

accordance with CJCSI 3170.01E. 

b. The Offeror shall describe how interfaces will be selected from existing 

open or Government standards with emphasis on system-level or 

enterprise-level (where applicable) interoperability. The Offeror shall 

describe how its selection of interfaces will maximize the ability of the 

system to readily accommodate technology insertion (both hardware and 

software) and facilitate the insertion of alternative or reusable modular 

system elements. 

c. The Offeror shall describe how its system will allow for: 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

33 

i. Quickly interconnecting, reconfiguring, and assembling existing 

systems, subsystems, and components; 

ii. Interchanging and using information, services and/or physical 

items among components within a system; 

iii. Interchanging and using information, services and/or physical 

items among systems within an integrated architecture, platform, 

PEO, Community of Interest, or a DoD component; 

iv. Supporting reuse of software and the common use of components 

across various product lines; 

v. Transferring a system, component, or data, from one hardware or 

software environment to another. 

d. The Offeror shall describe the degree to which the defined interfaces will 

support an Information Assurance (IA) strategy that implements IA 

Processes in accordance with DoD Instruction 8500.2 (dated February 6, 

2003). 

e. The Offeror shall describe the degree to which proposed interfaces use 

defined commercial or Government standards as called for in Section C. 

Subfactor 3. Treatment of Proprietary or Vendor-Unique Elements. The Offeror 

shall justify any use of proprietary, vendor-unique, or closed components, including but 

not limited to COTS, and interfaces in current or future designs. This justification shall 

include documentation of the decision leading to the selection of specific COTS 

products (e.g., with test results, architectural suitability, “best value” assessments, etc.). 

The Offeror shall define its process for identifying and justifying proprietary, vendorunique or closed interfaces, code modules, hardware, firmware, or software to be used. 

a. The Offeror shall describe how it will employ hardware and/or software 

partitioning or other design techniques to isolate all proprietary, vendorunique portions of interfaces, hardware, firmware and modules – at the 

lowest subsystem or component level. 

b. The proposal shall include documentation to support the rationale for a 

decision to integrate proprietary, vendor-unique or closed system 

hardware and/or software functions within the proposed system. 

c. The Offeror shall describe how the integration of closed or proprietary, 

vendor-unique equipment, interfaces, data systems or functions due to a 

unique or specific system requirement will not preclude or hinder other 

component or module developers from interfacing with or otherwise 

developing, replacing, or upgrading open parts of the system. 

d. The Offeror shall identify and take steps to prevent the open elements of 

the system from intertwining with proprietary or vendor-unique elements 

in a manner that restricts or limits the ability to replace or upgrade the 

open elements using an open competitive selection process. 

e. The Offeror shall describe and demonstrate that the modularity of the 

system design promotes identification of multiple sources of supply 

and/or repair, and supports flexible business strategies that enhance subcontractor competition. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

34 

i. The Offeror shall conduct a market survey to identify candidate COTS 

and other reusable NDI, including Government-owned assets, capable of 

achieving the performance requirements of solutions that it has proposed 

to custom build. [Sound “market research” will help identify 

opportunities to use COTS or re-use existing components and is called for 

by the OSJTF.] COTS and other NDI selection criteria shall, at a 

minimum, address the following factors: Electrostatic Sensitive Device 

(ESD) immunity; Electromagnetic Interference/Electromagnetic 

Compatibility (EMI/EMC); integrated logistics support requirements; 

safety; reliability (to include the hardware’s designed-in ability to 

accommodate such stresses as electrical power fluctuation (voltage, 

current, frequency)), temperature, shock, vibration, operating time 

(duration), changes in atmospheric pressure, and humidity consistent with 

the environment described in the System Specification; maintainability; 

subsystem performance trade-offs; power, cooling, and physical form 

factors; open system architecture break out compatibility; cost; 

manufacturer’s quality assurance provisions; market acceptability; 

obsolescence; adequacy of available technical and computer software data 

rights and reprocurement intellectual property rights in the product; and 

merits of the software supported by the product. The Offeror shall provide 

documentation of the decision leading to the selection of specific COTS 

products (e.g., test results, architectural suitability, “best value” 

assessments, etc.). 

ii. The Offeror shall identify those pre-existing items (Government 

intellectual property assets, NDI, open source software, and COTS) it 

intends to evaluate for reuse. At a minimum, the Offeror shall describe 

what artifacts from the ____________ it intends to use within its proposed 

solution. Exceptions regarding reuse of pre-existing items must be 

accompanied by justification, such as cost (both of adoption and life cycle 

support), schedule, functional and non-functional performance, etc. 

f. The Offeror shall address how it will provide information needed to 

support third-party development and delivery of competitive alternatives 

or designs for software or other components or modules on an ongoing 

basis. This information may be used as part of peer review processes, to 

support Integrated Product Teams (IPTs), and to facilitate competition for 

component suppliers. The Offeror will provide a list of those proprietary 

or vendor-unique elements that it requests be exempt from this review. 

 

Subfactor 4. Life Cycle Management and Open Systems. The Offeror shall describe 

and demonstrate the strategy for reducing product or system and associated supportability 

costs through insertion of COTS or reusable NDI products. 

a. The Offeror shall identify and demonstrate a strategy to insert COTS 

technologies and other reusable NDI into the system and demonstrate that 

COTS, other reusable NDI, and other components are logistically 

supported throughout the system’s life cycle. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

35 

 i. The proposal shall identify specific hardware and software elements of 

the subsystem designs that are planned for COTS, open source software, 

proprietary and other reusable NDI replacement and the supportability 

plans for those elements. 

 ii. The Offeror shall demonstrate how the subsystem is designed to allow 

for timely and cost-effective replacement of subsystem elements or 

modules. The COTS selection processes shall be specifically addressed, 

including validation of those processes, and shall be supported by 

documentation of the decision leading to the selection of specific COTS 

products (e.g., with test results, architectural suitability, “best value” 

assessments, etc.). 

 

b. The Offeror shall provide a description of processes that will be 

established and demonstrate that COTS and other reusable NDI products 

are logistically supported. 

c. The Offeror shall describe the availability of commercial repair parts and 

repair services, facilities and manpower required for life cycle support and 

demonstrate that they are adequate to ensure long-term support for COTS 

and other reusable NDI products. The Offeror shall provide the proposed 

methodology for pass through of COTS warranties to the Government. 

Factor ( ): System Compliance with Naval OA Guidance

The language used in this section will be specified by the Community of Interest or PEO. 

For example, PEO C4I may use language from Netcentric Enterprise Solutions for 

Interoperability (NESI). The material that follows should be tailored by each 

PEO/Community of Interest to meet its specific technical requirements, when enterprisewide Naval requirements do not exist. The language should also be tailored to address 

different types of contracts, levels of systems acquisition, and phases in the acquisition 

life cycle. 

Each Offeror shall provide a narrative to the Government entitled “Naval Open 

Architecture Technical Guidance Narrative” (hereinafter referenced to as the 

“Narrative”). In preparation for drafting the Narrative, Offerors are requested to 

thoroughly review the [PEO-specified] technical guidance points provided in Table A 

below. The technical guidance points represent the critical technical characteristics 

required to implement the NOA design for deliverables under the contract awarded 

pursuant to this RFP. 

1. Each Offeror shall provide a Narrative explaining how each technical 

guidance point in Table A is addressed in the proposal. For those 

technical guidance points in Table A that the Offeror asserts are not 

applicable or not relevant to deliverables under the contract, the Offeror 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

36 

shall, in the Narrative, explain its basis for asserting non-applicability or 

non-relevance. 

2. The NOA Compliance subfactor is directed to each of the technical 

guidance points in Table A below, and the Offeror’s ability to provide a 

Narrative explaining how its proposal meets each technical guidance point 

as defined by the [insert relevant reference]. 

 

Table A 

[PEO-specified] Technical 

Guidance Points

[PEO-specified] Reference Document Citation 

Component design 

Portability 

Location transparency 

Client server 

Data distribution 

State data coherency 

Computational flow 

Fault tolerance 

Scalability 

Real-time performance 

Process, thread & memory 

management 

Data brokers 

Cabling and Cabinets 

Information Transfer 

Computing Resources 

Peripherals 

Operating Systems 

Adaptation Middleware 

Distribution Middleware 

Frameworks 

Dynamic Resource Management 

Instrumentation 

Failure Management 

Information Assurance 

Time Service 

Programming Language Facilities 

Displays 

System Test and Certification 

Selection of Standards 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

37 

Factor ( ): Management Approach

The first paragraph below is standard contract language with some modification to reflect 

the objective of facilitating competition at appropriate system or sub-system levels. 

While the number of contractors or subcontractors working on a contract is not 

necessarily a guaranty of openness, effective competition at the component-level is 

facilitated by NOA. The second paragraph articulates the view that true competition 

cannot be measured by the percentage of work awarded but rather the significance of 

their contributions. 

The Offeror shall describe its approach to managing the efforts required for this contract. 

Of particular interest to the Government is the Offeror’s approach for facilitating 

competition at various levels (tiers) of the logical or modular subdivisions or tasks and 

for awarding significant portions of the overall system to third-party sources. 

The Offeror shall describe its approach for using Integrated Product Teams (IPTs) to 

improve processes, proactively manage risk and increase efficiency. The Offeror shall 

describe steps it shall take to educate IPT members and others involved in the project on 

the importance and principles of NOA. 

Factor ( ) Data Rights and Patent Rights

The Offeror shall propose the extent to which the rights in technical data (TD), computer 

software (CS), computer software documentation (CSD), and inventions/patents offered 

to the Government ensure unimpeded, innovative, and cost effective production, 

operation, maintenance, and upgrade of the [SYSTEM NAME] throughout its life cycle; 

allow for open and competitive procurement of [SYSTEM NAME] enhancements; and 

permit the transfer of the [SYSTEM NAME] non-proprietary object code and source code 

to other contractors for use on other systems or platforms. 

The Offeror shall describe its plan for making design and interface information available 

as soon as possible after it is defined or established. The Offeror shall establish and 

maintain a process that will provide “early and often” design disclosure directly to the 

Government or to third-party contractors via Government-established access (e.g., the 

Naval Sea Systems Command Software/Hardware Asset Reuse Enterprise (SHARE) 

library or other Navy and Marine Corps repository/library resources) to in-process design 

documentation and computer software. Access to this information shall be supported 

using industry standards and at minimal cost to the Government. The exchange of 

information shall be structured so as to protect the Offeror’s and third-party developers’ 

proprietary in the information. The Offeror shall address how it intends to resolve any 

comments from the Government and third-party contractors. The Offeror shall describe 

how it intends to provide all non-proprietary licenses, source code, drawings, repair and 

engineering documentation to the Government and third-party contractors at specified 

key events or at defined intervals. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

38 

The Data Rights and Patent Rights offered shall be provided as attachments to the 

proposal. The Offeror shall cite specific examples of the Government's IPR that illustrate 

the tenets of the offer, including an overview of the information provided in the following 

required attachments, as well as a discussion of how the information contained in the 

attachments impacts or illustrates the tenets of the proposal: 

2. The Offeror shall provide the following information as attachments to its offer: 

a. Rights in Noncommercial TD, Noncommercial CS, and 

Noncommercial CSD. 

i. The 7017 List. The Offeror shall attach to its offer a list 

identifying all noncommercial TD, CS, and CSD that it asserts 

should be delivered with other than unlimited rights. Specific 

instructions and requirements concerning this list are set forth in 

the DFARS 252.227-7017 “Identification and Assertion of Use, 

Release, or Disclosure Restrictions” (June 1995) provision 

incorporated at Section K of this solicitation. If the Offeror is 

awarded a contract, the 7017 List shall be attached to the contract. 

ii. The 7028 List. The Offeror shall attach to its offer a list 

identifying all noncommercial TD, CS, and CSD that it intends to 

deliver with other than unlimited rights and that are identical or 

substantially similar to TD, CS, or CSD that the Offeror has 

delivered to, or is obligated to deliver to, the Government under 

any contract or subcontract. Specific instructions and requirements 

concerning this list are set forth in the DFARS 252.227-7028 

“Technical Data or Computer Software Previously Delivered to the 

Government” (June 1995) provision incorporated at Section K of 

this solicitation. Additionally, if there is no data or software to be 

identified in the 7028 list, the Offeror shall submit the list and 

enter “None” as the body of the list. If the Offeror is awarded a 

contract, the 7028 List shall be attached to the contract. 

iii. Supplemental Information. The Offeror shall attach to its offer a 

statement, entitled “Supplemental Information—Noncommercial 

Technical Data, Noncommercial Computer Software, 

Noncommercial Computer Software Documentation” (the 

statement) that, for each item of noncommercial TD, CS, or CSD 

that the Offeror asserts should be delivered with specifically 

negotiated license rights or other non-standard rights (as discussed 

at DFARS 252.227-7013 “Rights in Technical Data – 

Noncommercial Items” (Nov 1995) and/or DFARS 252.227-7014 

“Rights in Noncommercial Computer Software and 

Noncommercial Computer Software Documentation” (June 1995)), 

sets forth a complete description of all such proposed non-standard 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

39 

restrictions on the Government’s ability to use, modify, release, 

perform, display, or disclose such TD, CS, or CSD. This 

information may be provided by referencing any proposed nonstandard license agreement that is attached to the statement. The 

Offeror shall submit the statement as an attachment to its offer, 

dated and signed by an official authorized to contractually obligate 

the Offeror. If there is no information to be included in the 

statement, the Offeror need not submit the statement. If the 

Offeror is awarded a contract, any statement provided will be 

attached to the contract. 

b. Rights in Commercial TD, Commercial CS, and Commercial CSD. 

 

i. The Offeror shall attach to its offer a list, entitled “Commercial 

Technical Data, Commercial Computer Software, and Commercial 

Computer Software Documentation-Government Use Restrictions” 

(the Commercial Restrictions List), that provides the following 

information regarding all commercial TD, CS, and CSD that the 

Offeror (including its sub-Offerors or suppliers, or potential subOfferors or suppliers, at any tier) intends to deliver with other than 

unlimited rights: (1) identification of the data or software; (2) 

basis for asserting restrictions, such as licensed products including 

open source; (3) asserted rights category (e.g. GPR or restricted 

rights); and (4) name of the entity asserting restrictions. For any 

item designated as NDI, the Offeror is requested to provide details 

of the Agency and level therein that paid for development and the 

contract number(s) and dates wherein payments were received. 

For each entry in the list citing an asserted rights category other 

than the standard license rights applicable to commercial TD as set 

forth in the DFARS 252.227-7015 “Technical Data – Commercial 

Items” (Nov 1995) clause, the Offeror shall provide a complete 

description of the asserted rights (e.g., a specially negotiated 

license, open source, or the license customarily offered to the 

public); this information may be provided by referencing any 

proposed non-standard or commercial license agreement that is 

attached to the list, but in all cases, the non-standard or commercial 

license will be attached for Government review. The Offeror shall 

submit the Commercial Restrictions List as an attachment to its 

offer, dated and signed by an official authorized to contractually 

obligate the Offeror. If there is no information to be included in 

the Commercial Restrictions List, the Offeror shall submit the list 

and enter “None” as the body of the list. If the Offeror is awarded 

a contract, the Commercial Restrictions List shall be attached to 

the contract. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

40 

ii. The Offeror shall attach to its offer a list, entitled “CommercialOff-the-Shelf (COTS) Licenses – Identification and Licensing” 

(the COTS List), providing information concerning all COTS 

licenses for which it intends to pay license fees and the amount of 

the fees in order to perform under the contract. The Offeror shall 

submit the COTS List as an attachment to its offer, dated and 

signed by an official authorized to contractually obligate the 

Offeror. The Offeror’s COTS list shall also include a statement 

explaining how the COTS will be used in the system. If there is no 

information to be included in the COTS List, the Offeror shall 

submit the list and enter “None” as the body of the list. If the 

Offeror is awarded a contract, the COTS List shall be attached to 

the contract. 

c. Rights in Background Inventions. 

i. The Offeror shall attach to its offer a list, entitled “Background 

Inventions—Identification and Licensing” (the BIIL List), 

providing information concerning all background inventions. A 

“background invention” is any invention, other than a subject 

invention, that is covered by any patent or pending patent 

application in which the Offeror (including its sub-Offerors or 

suppliers, or potential sub-Offerors or suppliers, at any tier) (1) has 

any right, title, or interest; and (2) proposes to incorporate into any 

items, components, or processes (ICP) to be developed or 

delivered, or that will be described or disclosed in any TD, CS, or 

CSD to be developed or delivered, under the resulting contract. 

For each background invention, the BIIL List shall identify (1) the 

invention, by serial number, title, and date of the patent application 

or issued patent; (2) the ICP, TD, CS, and CSD that will 

incorporate or disclose the invention; (3) the nature of the Offeror's 

right, title, or interest in the invention; and (4) whether the Offeror 

is willing to sell to the Government a license to practice the 

invention, and if so, a complete description of the terms of such 

proposed license. The Offeror shall submit the BIIL List as an 

attachment to its offer, dated and signed by an official authorized 

to contractually obligate the Offeror. If there is no information to 

be included in the BIIL List, the Offeror shall submit the list and 

enter “None” as the body of the list. If the Offeror is awarded a 

contract, the BIIL List shall be attached to the contract. 

ii. The Offeror shall attach to its offer a list, entitled “Third Party 

Patent Rights – Identification and Licensing” (the 3PRIL List), 

providing information concerning all third party patent rights for 

which it intends to pay royalties and the amount of the royalties in 

order to perform under the contract. The Offeror shall submit the 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

41 

3PRIL List as an attachment to its offer, dated and signed by an 

official authorized to contractually obligate the Offeror. If there is 

no information to be included in the 3PRIL List, the Offeror shall 

submit the list and enter “None” as the body of the list. If the 

Offeror is awarded a contract, the 3PRIL List shall be attached to 

the contract. 

Evaluation Subfactor ( ): OA Past Performance

The Offeror shall demonstrate, through its use of previously developed similar 

technologies, the Offeror’s ability to meet the design, development, testing, and 

production requirements of this solicitation, in particular its approach to a modular open 

system design, in the quantities and schedules specified. The Offeror shall provide a list 

of all relevant contracts and subcontracts of similar work scope or technical complexity 

to the efforts described herein within the last five (5) years. In addition to contracts and 

subcontracts performed by the Offeror, relevant contracts and subcontracts of an acquired 

company, division, or subsidiary shall be identified. The Offeror shall place particular 

emphasis on DoD or Government contracts and subcontracts, especially those that 

involved a modular open systems approach. 

If the Offeror did not perform similar projects during the last five years, the Offeror may 

discuss other related projects that demonstrate the Offeror’s capabilities to perform work 

of similar nature and magnitude. Note, if the Offeror omits projects or contracts of which 

the Government evaluation team is aware or becomes aware, then customer assessments 

may be sought from the relevant program and technical support offices. Offerors are 

advised that (1) the Government may contact any or all references listed in the proposal 

and other third parties, unreferenced customers, agencies, Offerors, consumer protection 

organizations, etc., for performance information, or use any other data available (such as 

contractor Performance Assessment Reporting System (CPARS)); (2) the Government 

reserves the right to use any such information received as part of its evaluation of the 

Offeror’s past performance; and (3) if the Offeror omits projects of which the 

Government evaluation team is aware or becomes aware, customer assessments may be 

sought from the relevant organizations. 

For each listed contract, the Offeror shall prepare a synopsis that includes a narrative selfassessment of the contract and specific details describing why the contract was, or was 

not, successful. Each synopsis shall be in the following format: 

(1) Contract number; 

(2) Customer’s name, address, telephone number, and a point of contact 

(whether Government or Commercial), and whether the Offeror was the 

prime Offeror or a sub-Offeror; 

(3) Contract type; 

(4) Cost information; 

(5) Brief product description, including quantities, hours, and state of 

acquisition (i.e., development or production); 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

42 

(6) Self-Assessment. The Offeror shall provide a self assessment of its 

performance under each contract identified above. The self assessment 

shall address (a) the degree to which the Offeror demonstrated its design 

approach, plans for technology insertion, and sustainment strategy were 

consistent with the modular open systems requirements, (b) the degree to 

which the Offeror managed the impact of changing requirements and 

evolving technology on the system’s ability to continue to satisfy 

improved capabilities over time, (c) the degree to which the Offeror’s test 

and evaluation planning contained the means for testing the conformance 

to open standards to ensure the openness of key interfaces throughout the 

system life cycle, and (d) the degree to which the Offeror’s approach 

contains capabilities to easily and quickly update, revise, and change the 

system as threats (warfighting and information assurance threats) or 

technologies (COTS or reusable) evolve. Cost growth, material problems, 

manufacturing problems, quality problems, labor problems, facility 

problems, and delivery delays shall be disclosed and fully explained. The 

Offeror shall demonstrate how it was able to resolve (or why it could not 

resolve) special or unexplained problems as well as difficulties in meeting 

delivery schedule, performance, or cost parameters. Emphasis shall be 

placed on the Offeror’s ability to solve problems associated with critical 

testing, quality control, and production. Furthermore, the Offeror shall 

indicate any quality awards or recognition received. 

(7) Customer References. The Offeror shall request Customer questionnaires 

to be submitted directly to the Procurement Contracting Officer’s (PCO’s) 

representative and/or copies submitted with the Offeror’s proposal and 

provide the following information for each described contract: 

• The Procuring Contracting Officer’s name, address, and telephone 

number. 

• The Administrative Contracting Officer’s name, address, and 

telephone number. 

• The Government and Offeror’s Program Managers’ names, addresses, 

and telephone numbers. 

• The names, addresses, and telephone numbers of other individuals 

having knowledge of the Offeror’s performance under each contract. 

At a minimum, the Government’s questionnaire for assessing an Offeror’s OA past 

performance must address: 

• The degree to which the Offeror demonstrated its design approach, plans 

for technology insertion, and sustainment strategy were consistent with the 

modular open systems requirements. 

• The degree to which the Offeror managed the impact of changing 

requirements and evolving technology on the system’s ability to continue 

to satisfy improved capabilities over time. 

• The degree to which the Offeror’s test and evaluation planning contained 

the means for testing the conformance to open standards to ensure the 

openness of key interfaces throughout the system life cycle. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

43 

• The degree to which the Offeror’s approach contains capabilities to easily 

and quickly update, revise, and change the system as threats (warfighting 

and information assurance threats) or technologies (COTS or reusable) 

evolve. 

COST PROPOSAL (NOA RELATED)

Section ( ) Supplemental Information Concerning Cost/Price of Noncommercial 

Technical Data (TD), Noncommercial Computer Software (CS), and 

Noncommercial Computer Software Documentation (CSD)

(a) Cost/Price Information. In addition to the submission requirement of DFARS 

252.227-7017, the Offeror shall provide a list entitled “Supplemental Information 

Concerning Cost/Price of Noncommercial Technical Data (TD), Noncommercial 

Computer Software (CS), and Noncommercial Computer Software Documentation 

(CSD)” (hereinafter the Supplemental 7017 Cost/Price List). This list shall be provided 

as an attachment to proposal. This list shall provide supplemental information 

concerning the noncommercial TD, CS, or CSD identified in the DFARS 252.227-7017 

“Identification and Assertion of Use, Release, or Disclosure Restriction” list (hereinafter 

7017 List), as follows: 

(1) License Option Price Information. For each item of noncommercial TD, CS, 

and/or CSD that the Offeror asserts should be delivered with less than Government 

Purpose Rights (GPR) (as defined in (DFARS 252.227-7013 “Rights in Technical Data – 

Noncommercial Items” (Nov 1995) and/or DFARS 252.227-7014 “Rights in 

Noncommercial Computer Software and Noncommercial Computer Software 

Documentation” (June 1995)), and for which the Offeror is willing to sell to the 

Government greater rights than those identified in the 7017 List, the Offeror shall identify 

those greater rights, provide an option price at which the Government may purchase such 

greater rights, and identify the period of time during which the option is available for the 

Government to exercise. 

(2) Government Preferences. The Offeror may state any license option price as a 

firm fixed price, a percentage royalty rate (or use fee), or any other comparable 

compensation scheme, provided that the Government can reasonably calculate a sumcertain price for the license option using the price information and terms and conditions 

information the Offeror provided. The Government prefers that any license option prices 

the Offeror provides in the Supplemental 7017 Cost/Price List cover all noncommercial 

CS, noncommercial CSD, and noncommercial TD included in any affected software and 

that the Offeror state them on a price-per-system basis. 

(b) Duty to Submit Negative List. If there is no supplemental information to be 

submitted in the Supplemental 7017 Cost/Price List the Offeror shall submit the list and 

enter “None” as the body of the list. Failure to provide a list may render the Offeror 

ineligible for award. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

44 

(c) Use During Source Selection. Information provided in the Supplemental 7017 

Cost/Price List, as well as the information provided in the 7017 List, may be used in the 

source selection process as part of the Government’s best value analysis to evaluate the 

impact on the Government’s ability to use, re-use, or disclose the TD, CS, and/or CSD 

for government purposes. 

Section ( ) Supplemental Information Concerning Cost/Price of Commercial 

Computer Software (CS), and Commercial Computer Software Documentation 

(CSD) and Commercial Technical Data (TD)

(a) Cost/Price Information. The Offeror shall provide a list to the Government, entitled 

“Commercial Restrictions List – Cost/Price Information” (hereinafter the CRLCPI List). 

This list shall be provided as an attachment to proposal. The CRLCPI List shall state a 

license option price for all commercial CS, commercial CSD, and commercial TD on the 

CRL List for which the Offeror is willing to sell the Government a license. If the Offeror 

is willing to provide a license option, the Offeror shall identify the specific rights it is 

willing to grant, and the period of time during which the option is available for the 

Government to exercise. 

(b) License Option Pricing: Government Preferences. The Offeror may state any 

license option price as a firm fixed price, a percentage royalty rate (or use rate), or any 

other comparable compensation scheme, provided that the Government can reasonably 

calculate a sum-certain price for the license option using the price information the 

Offeror provided. The Government prefers that any license option prices the Offeror 

provides in the CRLCPI List cover all commercial CS, commercial CSD, and commercial 

TD included in any affected software and that the Offeror state them on a price-persystem basis. 

(c) Duty to Submit Negative List. If the Offeror has no Option License Pricing to 

provide in the CRLCPI List, the Offeror shall still submit the CRLCPI List and enter 

“None” in the body of the List. Failure to provide a list may render the Offeror ineligible 

for award. 

Section ( ) Supplemental Information Concerning Cost/Price of Background 

Inventions

(a) License Option Pricing: Government Preferences. The Offeror may state any 

license option price as a firm fixed price, a percentage royalty rate (or use rate), or any 

other comparable compensation scheme, provided the Government can reasonably 

calculate a sum-certain price for the license using the price information provided by the 

Offeror. The Government prefers that any license option prices stated by the Offeror in 

the Background Inventions List – Cost/Price Information (BICPI List) cover all 

background inventions included in any affected software, and the Offeror states them on 

a price-per-system basis. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

45 

(b) Duty to Submit Negative List. If the Offeror has no Option License Pricing to 

provide in the BICPI List, the Offeror shall still submit the BICPI List and enter “None” 

in the body of the list. Failure to provide a list may render the Offeror ineligible for 

award. 

Software Process Improvement Initiative Guidance14

The Navy and Marine Corps shall request that Offerors submit a draft version of their 

Software Development Plan (SDP) as a part of their proposal package as well as a 

rationale for how the Navy justify their process selection. 

“As a part of the proposal, Offerors shall submit a draft version of their SDP in 

accordance with the content defined in the SOW. The SDP may be formatted as 

desired by the Offeror but must contain the information described by the SDP DID. 

The SDP is not page limited. An SDP, if it is to-the-point and appropriate, may be 

preferable to a SDP that is excessively wordy and contains non-essential material. 

“Offerors shall also submit, as a part of their proposal, an SDP Rationale which 

describes why their specific approach is appropriate for the system to be procured and 

how their proposed processes are equivalent to those articulated by CMMI®

capability level 3. 

“Offerors shall submit a description of previous experience in developing software of 

the same nature as this solicitation. As a part of this description, the Offerors shall 

describe the extent to which personnel who contributed to these previous efforts will 

be supporting this solicitation. 

“Offerors shall submit a description of previous experience in developing software 

using the same or similar processes and approaches as proposed for this solicitation. 

Offerors shall describe the extent to which personnel who contributed to these 

previous efforts will be supporting this solicitation. Offerors shall also describe any 

previous CMMI or equivalent model-based process maturity appraisals performed. 

As a part of this description, Offerors shall identify the organizational entity and 

location where the appraisal was performed, the type of evaluation, the organization 

performing the evaluation, and the level earned.” 

 

14 Assistant Secretary of the Navy (Research, Development and Acquisition)’s 

Memorandum on “Software Process Improvement Initiative Contract Language,” dated 

November 17, 2006.
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

46 

Chapter D: RECOMMENDATIONS FOR SECTION M 

(EVALUATION CRITERIA) LANGUAGE 

Although the Guidebook was developed for mixed systems comprised of hardware, 

middleware and software elements, the recommended language can be easily tailored to 

reflect hardware- or software-only acquisitions. 

EVALUATION FACTORS 

The Government will evaluate the Offeror’s proposal in accordance with the factors and 

subfactors set forth below: 

Naval Open Architecture Guidance 

Factor ( ): Technical Approach and Processes 

In evaluating the OA Technical Approach and Processes, the Government will use 

information provided in the proposal to assess the Offeror’s ability to execute: 

 Subfactor 1. Open Systems Approach and Goals 

 Subfactor 2. Interface Design and Management 

 Subfactor 3. Treatment of Proprietary or Vendor-Unique Elements 

 

 Subfactor 4. Life Cycle Management and Open Systems 

Factor ( ): System Compliance with Naval OA Guidance 

In evaluating the System Compliance with Naval OA Guidance, the Government will use 

information in the proposal to assess the degree to which the Offeror’s approach complies 

with PEO-specified (or Naval Enterprise) Technical Guidance Points as identified in 

Table A of Section L. 

Factor ( ): Management Approach 

In evaluating the Management Approach, the Government will use information in the 

proposal to assess the degree to which the Offeror’s approach facilitates competition at 

various levels (tiers) of the offered modular system, awards significant portions of the 

overall system to third party sources, and uses Integrated Product Teams (IPT) to 

improve processes, manage risk, and increase efficiency. 

Factor ( ): Data Rights, Computer Software Rights and Patent Rights 

In evaluating the Data Rights and Patent Rights, the Government will use information in 

the proposal to assess the extent to which the rights in technical data (TD), computer 

software (CS), computer software documentation (CSD), and inventions/patents offered 

to the Government ensure unimpeded, innovative, and cost effective production, 

operation, maintenance, and upgrade of the [SYSTEM NAME] throughout its life cycle; 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

47 

allow for open and competitive procurement of [SYSTEM NAME] enhancements; and 

permit the transfer of the [SYSTEM NAME] non-proprietary object code and source code 

to other contractors for use on other systems or platforms. 

Factor ( ): Past Performance 

Subfactor 1. Offeror’s OA Past Performance Submissions 

In assessing the Offeror’s past performance submissions on similar contracts, the 

Government will consider how well the Offeror implemented Open 

Architecture principles and used a modular open system approach, including: 

• The degree to which the Offeror demonstrated that its design approach, 

plans for technology insertion, and sustainment strategy were consistent 

with the modular open systems requirements. 

• The degree to which the Offeror managed the impact of changing 

requirements and evolving technology on the system’s ability to continue 

to satisfy improved capabilities over time. 

• The degree to which the Offeror’s test and evaluation planning contained 

the means for testing the conformance to open standards to ensure the 

openness of key interfaces throughout the system life cycle. 

• The degree to which the Offeror’s approach contains capabilities to easily 

and quickly update, revise, and change the system as threats (warfighting 

and information assurance threats) or technologies (COTS or reusable) 

evolve. 

Factor ( ): Cost Proposal (NOA Related) 

The Government will evaluate the following costs with respect to how they further Naval 

Open Architecture goals: 

• Supplemental Information Concerning Cost/Price of Noncommercial Technical 

Data (TD), Noncommercial Computer Software (CS), and Noncommercial 

Computer Software Documentation (CSD) 

• Supplemental Information Concerning Cost/Price of Commercial Computer 

Software (CS), and Commercial Computer Software Documentation (CSD) and 

Commercial Technical Data (TD) 

• Supplemental Information Concerning Cost/Price of Background Inventions 

Software Process Improvement Guidance15

At a minimum, the following three evaluation factors relating to the Offeror's software 

development process shall be included in Section M: 

 

15 Assistant Secretary of the Navy (Research, Development and Acquisition)’s 

Memorandum on “Software Process Improvement Initiative Contract Language,” dated 

November 17, 2006.
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

48 

a) Factor x – Software development approach 

Description: The Government will evaluate the Offeror’s proposed software 

development approach to ensure it is appropriate for the system to be developed and 

meets standard levels of completeness and process quality. For this evaluation, the 

Government will rely primarily on the draft SDP and the SDP Rationale. 

Criteria: IEEE/EIA Std. 12207.1, Section 4.2.3, H.3 - Characteristics of Life Cycle Data 

b) Factor x – Software development experience 

Description: The Government will evaluate the Offeror’s previous experience in 

developing software of the same nature as that being acquired with this solicitation. 

Factor x - Software development process experience 

Description: The Government will evaluate the Offeror's previous experience in 

developing software using the same or similar approach as proposed for this solicitation. 

The results of any standard model-based process maturity appraisals performed within 24 

months prior to proposal submission, and the number of proposed staff experienced in 

using these processes will be part of the evaluation criteria. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

49 

Chapter E: RECOMMENDATIONS FOR INCENTIVIZING 

CONTRACTORS 

In response to a December 2005 report and recommendations by the Government 

Accountability Office, “DEFENSE ACQUISITIONS: DoD Has Paid Billions in Award 

and Incentive Fees Regardless of Acquisition Outcomes,” the Defense Department on 

March 29, 2006, issued a Memorandum on Award Fee Contracts (FAR 16, DFARS 215, 

DFARS 216). We recommend that this memorandum be consulted when preparing an 

Award Fee Plan. (It is available on the Office of the Secretary of Defenses website at 

http://www.acq.osd.mil/dpap/policy/policyvault/2006-0334-DPAP.pdf.) 

Subsequently, the Government Accountability Office (GAO) in May 2009 issued a 

follow-up report on award fee practices, “Federal Contracting: Guidance on Award Fees 

Has Led to Better Practices but Is Not Consistently Applied” (GAO-09-630, available at 

http://www.gao.gov/new.items/d09630.pdf). The report reviewed the award fee practices 

of five government agencies, including the Department of Defense—that accounted for 

over 95 percent of dollars spent on award fee contracts in 2008. This GAO review was 

conducted in light of Office of Management and Budget (OMB) December 2007 

guidance on the “Appropriate Use of Incentive Contracts” (available at 

http://www.whitehouse.gov/omb/assets/omb/procurement/memo/incentive_contracts_120

407.pdf ). 

The OMB memo espoused principles for applying award fees such as (1) limiting the 

opportunities for earning unearned fees in subsequent periods (fee rollover); (2) linking 

award fees to acquisition outcomes; (3) designing evaluation criteria to motivate 

excellent performance; and (4) not paying for unsatisfactory performance. GAO found 

that DoD’s updated guidance largely reflects these principles and that it now prohibits 

payment of award fees for unsatisfactory performance. In addition, it found that DoD 

will save more than $450 million by not routinely offering contractors a second chance at 

unearned fees and $68 million by using more clearly defined evaluation criteria. 

In addition, the report cites other important guidance, such as the Federal Acquisition 

Regulations (FAR), which advise that “an award fee should be used when the work to be 

performed is such that it is neither feasible nor effective to devise predetermined 

objective incentive targets applicable to cost, technical performance, or schedule.” It also 

reiterates the OMB guidance that “it is imperative that award fees are linked to desired 

outcomes such as discrete events or milestones. Such milestones include design reviews 

and system demonstrations for weapons systems.” 

In April 2007, DoD provided additional guidance on contracting incentives, 

“[r]ecognizing that most DOD contracts contain objective criteria, the guidance clarified 

that in instances where objective criteria exist and the Contracting Officer and Program 

Manager wish to also evaluate and incentivize subjective elements of performance, the 

most appropriate contract type would be a multiple incentive type contract containing 

both incentive and award fee criteria.” 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

50 

As part of the Naval OA effort, we recommend the OMB and DoD guidance cited in this 

GAO report be followed to help programs reap the benefits of properly motivating 

contractors. The Office of Management and Budget’s Office of Federal Procurement 

Policy Incentive Contract Checklist is available from the OMB website at 

http://www.whitehouse.gov/omb/assets/omb/procurement/memo/incentive_contracts_120

407.pdf

Although the Guidebook was developed for mixed systems comprised of hardware, 

middleware and software elements, the recommended language can be easily tailored to 

reflect hardware- or software-only acquisitions. 

For additional guidance, refer to Office of the Under Secretary of Defense (Acquisition, 

Testing, and Logistics (OUSD(AT&L)/DPAP) policy memo dealing with “Proper use of 

Award Fee Contracts and Award Fee provisions” available at: 

http://www.acq.osd.mil/dpap/policy/policyvault/2007-0197-DPAP.pdf. 

The following is guidance for developing a contract Incentive Plan for a program seeking 

to implement Naval Open Architecture principles. Additional information is found in the 

Department of Defense’s Open Systems Joint Task Force (OSJTF) Modular Open 

Systems Approach (MOSA) to acquisition. 

This chapter is intended to serve as a guide for those programs seeking to incentivize 

their contractors to implement Naval Open Architecture business and technical principles 

in both development and production contracts. The award fee criteria are drawn from the 

business and technical principles embodied in the MOSA principles and OUSD 

(AT&L)’s draft guide. The Award Term recommendations are based on contracting 

practices that have been used in the Army, Air Force, SPAWAR and NAVSEA (on the 

Seaport contract vehicle and Submarine Warfare Federated Tactical System contract). 

Award Terms are particularly appropriate for service and support contracts but are worth 

considering for other types of contracts for such functions as integration, test, and 

installation. 

Part 1 Award Fees 

For “Performance and Schedule” portion of the Award Fee Plan, the Government shall 

apply the following OA-related award fee criteria: 

• Incorporation of considerations for reconfigurability, portability, 

maintainability, technology insertion, vendor independence, reusability, 

scalability, interoperability, upgradeability, and long-term supportability as 

defined by Naval Open Architecture. 

• Implementation of a layered and modular system that makes maximum use of 

non-proprietary Commercial-Off-the-Shelf / Non-developmental Item 

(COTS/reusable NDI) hardware, software, operating systems, and 

middleware. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

51 

• Minimization of inter-component dependencies and ability to allow 

components to be decoupled and re-used, where appropriate. 

• Early and often disclosure of data related to the design of designated 

components or subcomponents. 

• Adaptability to evolving requirements and threats. 

• Modularity of products. 

• Use of open, standards-based interfaces. 

• Interoperability with joint warfighting applications and secure information 

exchange. 

• Reduction of development cycle time and total life-cycle cost. 

• Commonality and reuse of components within the system. Emphasis should 

be placed on reuse of components (software, middleware, applications 

software, algorithms, etc.) from the pertinent Navy and Marine Corps 

community of interest as a means of facilitating maintenance and upgrades. 

• Identification of potential candidates for reuse from outside the contractor’s 

own organization for inclusion in selection of design alternatives. 

• Enabling rapid technology insertion. 

For “Work Relations” portion of the Award Fee Plan, the Government shall apply the 

following OA-related criteria: 

• Collaboration with the Government, contractors and Vendors to develop a 

highly performing system. 

• Working with the Government, contractors and Vendors to incorporate 

revised schedules and meet changing Government requirements. 

• Identification of and working with contractors and Vendors to improve 

PROGRAM X performance. 

• Identification and incorporation of innovative methods with contractors and 

Vendors to provide development assets without procuring unique assets. 

• Identification of and working with contractors and Vendors who possess 

innovative technologies and methods. 

• Working with contractors and Vendors to identify new technology and 

functionality. 

• Working with contractors and Vendors to identify innovative ways to 

incorporate new technology that improves performance. 

• Working with contractors and Vendors to mitigate the risks associated with 

technology obsolescence, being locked into proprietary or vendor-unique 

technology, and reliance on a single source of supply over the life of a system. 

Alternatively, a Program Manager may want to structure award fees around four different 

categories: (1) Cost, (2) Schedule, (3) Management, and (4) Technical attributes. This 

provides a different kind of flexibility where each category can be given a different 

emphasis by giving it a percentage weight of the award fee total. For example, 10%, 

20%, 30%, and 40%, respectively, would hold technical attributes as the most important 

and cost as the least important. Additionally, from an OA perspective, a PM will want to 

include the following language under “Technical”: 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

52 

The contractors will be evaluated on whether the technical data rights submitted with 

the deliverable support the Naval Open Architecture (OA) principles, including 

minimizing proprietary elements, without unjustified or inappropriate limitations on 

rights or use by the Government. 

Part 2 Award Terms

An award term incentive contract is a relatively new acquisition option and while it is not 

yet described in the Federal Acquisition Regulation (FAR) or Defense Federal 

Acquisition Regulation Supplement (DFARS) it is modeled after the award fee incentive 

described in FAR 16.405-2 and DFARS 216.405-2. Being that award term incentives 

relate closely with those of award fee, the guidance described in Chapter D of this 

Guidebook are directly applicable and will not be restated in this chapter. Rather, an 

explanation of the award term contract and recommendations for establishing an Award 

Term Plan is provided. Program Managers should weigh the benefits of using award 

terms against the value of frequent competitions to encourage innovation and exceptional 

performance. 

Contract Premise: Instead of rewarding the contractor with additional fee for 

exceptional performance the award term contract rewards the contractor by extending the 

contract period of performance in the form of additional term periods added on to the 

basic contract. Under an award term incentive the Government monitors and evaluates 

the contractor’s performance, and if it is decided that the contractor’s performance was 

excellent, then the contractor earns an extension. During subsequent evaluations if the 

contractor maintains excellent performance additional terms are awarded. If the 

contractor’s performance decreases, the possibility of the contractor not being awarded an 

additional term or even having terms previously awarded taken away is the incentive for 

the contractor to perform at an exceptional level. The additional terms are not option 

periods but extensions to the contract. This distinguishes the award term contract from 

other incentive type contracts in that if the contractor meets the award term criteria 

outlined in the contract, and if all other stipulated conditions such as continuing need and 

availability of funds are met, then the Government must either extend the contract or 

terminate it for convenience or default. 

Example of an Award Term Contract Timeline. A competitive contract is awarded 

consisting of a base year plus four (4) one-year options. During the base year the 

contractor’s performance is evaluated and, depending on how the Award Term Plan is 

structured, the initial evaluation can either be for informational purposes only or it can be 

a formal evaluation in which contractor performance determines the awarding of an 

award term (at this point no award terms can be lost since the contractor has yet to earn 

one). Since the basic contract is for five years (where an evaluation is conducted for each 

of those years) the contractor could be rewarded with up to five additional year long 

extensions to the basic contract for a total of 10 years maximum. 

Considerations: 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

53 

• It is highly recommended that mid-year reviews be conducted that will provide 

informational feedback to the contractor on performance. 

• The structure of the contract period of performance is flexible within the boundaries 

established by the FAR/DFARS. For example, Award Term Review Board (ATRB) 

reviews could be conducted annually or semiannually; base and option years, number 

of award terms, etc., are at the discretion of the contracting office. 

• Evaluation criteria are at the discretion of the contracting officer and program office 

administering the contract and could include evaluations for cost, schedule, technical 

performance, customer satisfaction, etc. It is the policy of the Department of Defense 

that objective criteria be utilized, whenever possible, to measure contract 

performance. 

• Within the evaluation criteria it is recommended that the government’s expectation of 

how the contractor will be evaluated in implementing Naval Open Architecture be 

clearly defined (using the same considerations as those identified in Chapter D for 

award fee contracts). 

Award Term Plan Structure: There is no mandated format for an award term plan. It 

is recommended that the structure, however, include the following components: 

• A cover sheet that identifies the Award Term Plan (ATP) as an attachment to the 

formal contract with signature blocks included for the Procuring Contracting Officer 

(PCO) and the Term Determining Official (TDO); 

• Table of Contents; 

• An Introduction section that describes the overall objectives of the ATP and how it 

relates to the requirements in the Statement of Work (SOW); 

• A section that describes the organization (Award Term Review Board (ATRB), TDO, 

etc.) and responsibilities of the board and its members; 

• A description of the award term process; 

• A description of how changes to the ATP will be addressed; and 

• Annexes to the ATP should include: 

o Members of the ATRB (by government code – not by name) 

o A time line for award term evaluation periods 

o Evaluation Criteria 

o Example of the assessment form(s). 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

54 

Appendix 1: RECOMMENDED NOA CDRL AND DELIVERABLE 

ITEMS

The following are examples of Contract Data Requirements Lists (CDRLs) and 

deliverable items that support NOA and can be incorporated into contracts. This is not 

intended to be an exhaustive list of all potential deliverable items, but is an attempt to list 

only those deliverables we believe significantly support Naval Open Architecture, and 

can be augmented/reduced as the Program Manager believes is appropriate. The 

frequency and delivery dates of the deliverables must be specified, along with a list of 

deliverable recipients. 

Deferred Ordering of Technical Data or Computer Software (Including Design and 

Development Artifacts) 

DFARS 227.7103-8(b) DEFERRED DELIVERY AND DEFERRED ORDERING 

OF TECHNICAL DATA 

(b) Deferred Ordering. Use the clause at 252.227-7027, Deferred Ordering of Technical 

Data or Computer Software, when a firm requirement for a particular data item(s) has not 

been established prior to contract award but there is a potential need for the data. Under 

this clause, the contracting officer may order any data that has been generated in the 

performance of the contract or any subcontract thereunder at any time until three years 

after acceptance of all items (other than technical data or computer software) under the 

contract or contract termination, whichever is later. The obligation of subcontractors to 

deliver such data expires three years after the date the contractor accepts the last item 

under the subcontract. When the data are ordered, the delivery dates shall be negotiated 

and the contractor compensated only for converting the data into the prescribed form, 

reproduction costs, and delivery costs. 

Software Development Process16

The software development process to be used by the winning contractor team is to be 

defined and documented in the developer’s SDP which shall be designated as a CDRL. 

Contractor teams are to submit an initial delivery of the SDP with the proposal. After 

contract award, an updated version is to be delivered based on discussion and 

negotiations with the Government regarding approval of SDP content. 

In accord with DoN policy, the SDP is to conform to the framework established in 

IEEE.EIA 12207, with the content as required in ASN(RD&A) Memo Nov. 17, 2006 

titled, “Software Process Improvement Initiative Contract Language,” and ASN(RD&A) 

 

16 Assistant Secretary of the Navy (Research, Development and Acquisition)’s 

Memorandum on “Software Process Improvement Initiative Contract Language,” dated 

November 17, 2006.
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

55 

Memo July 13, 2007 titled, “Software Process Improvement Initiative (SPII) Guidance 

for Use of Software Process Improvement Contract Language.” The format of the SDP 

can be contractor-selected, but can be required to follow the format as defined in 

Appendix L of the SPII Guidebook. 

Specifically, the SDP should: 

• Document all processes applicable to the system to be acquired, including the 

Primary, Supporting, and Organizational life cycle processes as defined by 

IEEE/EIA Std. 12207 as appropriate. 

• Contain the content defined by all information items listed in Table 1 of 

IEEE/EIA Std. 12207.1, as appropriate for the system and be consistent with the 

processes proposed by the developers. If any information item is not relevant to 

either the system or to the proposed process, that item need not be required. 

• Adhere to the characteristics defined in section 4.2.3 of IEEE/EIA Std. 12207, as 

appropriate. 

• Contain information at a detail sufficient to allow the use of the SDP as the full 

guidance for the developers. In accordance with section 6.5.3a of IEEE/EIA Std. 

12207.1, it should contain, “specific standards, methods, tools, actions, reuse 

strategy, and responsibility associated with the development and qualification of 

all requirements, including safety and security.” 

Naval Open Architecture Products 

It is recommended that the Program Office perform an assessment of its Intellectual 

Property Rights needs and craft its CDRL and Deliverable requirements accordingly. If 

the Program Office, PEO, Domain or Sponsor believes that the program deliverables 

would be of such interest that they warrant inclusion in the appropriate repository (such 

as Surface’s SHARE or PEO C4I’s NESI) then the CDRL and deliverables should 

include those design, developmental, or diagnostic items needed to reproduce or recreate 

the asset. 

The ideal asset would have artifacts in most or all of the following categories. The key to 

obtaining these artifacts is to require that they be delivered as part of the terms of the 

contract. These deliverables must be delivered with Government Purpose Rights (GPR) 

if they are to be added to a Government repository. In order to facilitate reuse, the asset 

should bundle the following or their equivalent: 

• Requirements (e.g., Word documents, DOORS file or Excel or XML export) 

• Architecture models (e.g., System Architect files, including DoDAF views where 

required) 

• Functional models (e.g., CORE file in native format or XML export) Software 

models (e.g., Rose/Rhapsody/iUML (Unified Modeling Language)/Artisan 

models in native or XMI format; minimum diagrams Class and State or 

Interaction/Sequence) 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

56 

• Hardware models (e.g., CAD DXF, IEGS files) 

• Human systems engineering models (e.g., IPME or Envision Ergo files) 

• Cost models (e.g., PRICE, SEER, COMET, VAMOSC, Excel files) 

• Modeling and Simulation data (e.g., NETWARS/OPNET, NSS, GCAM -

scenarios, environmental, platforms, tactics, MOEs, MOPs in XMI format 

following JC3IEDM or XMSF standards) 

• Test plans and results (e.g., QA Run, Quality Center files or Word or Excel 

export) 

• Logistics data (e.g., COMPASS, CASA, PowerLOG in native or XML/CSV 

format) 

Recommended NOA CDRL and Deliverable Items 

The following recommended deliverables for open architecture systems have official 

Deliverable Item Descriptions (DIDs) accepted by the Department of Defense’s Defense 

Standardization Program. The official DIDs are available from the Document 

Automation and Production Service (DAPS) Acquisition Streamlining and 

Standardization Information System (ASSIST) database at http://assist.daps.dla.mil. To 

obtain these DIDs simply search the database using either the DID’s title or its ID 

number listed below in the brief descriptions. 

1. Software Development Plan (SDP): The SDP describes a developer’s plans for 

conducting a software development effort. The term “software development” is 

meant to include new development, modification, reuse, reengineering, maintenance, 

and all other activities resulting in software products. [DID ID: DI-IPSC-81427A] 

2. Software Requirements Specification (SRS): The SRS specifies the requirements for 

a Computer Software Configuration Item (CSCI) and the methods to be used to 

ensure that each requirement has been met. Requirements pertaining to the CSCI’s 

external interfaces may be presented in the SRS or in one or more Interface 

Requirements Specifications (IRSs) (DI-IPSC-81434A) referenced from the SRS. 

[DID ID: DI-IPSC-81433A] It has also been defined as a complete description of the 

behavior of the software to be developed. It includes a set of use cases that describe 

all of the interactions that the users will have with the software. It also contains 

functional requirements, which define the internal workings of the software: that is, 

the calculations, technical details, data manipulation and processing, and other 

specific functionality that shows how the use cases are to be satisfied. It also contains 

nonfunctional requirements, which impose constraints on the design or 

implementation (such as performance requirements, quality standards or design 

constraints). [Stellman & Greene Consulting; http://www.stellman-greene.com] 

3. Software Version Description (SVD): The Software Version Description (SVD) 

identifies and describes a software version consisting of one or more Computer 

Software Configuration Items (CSCIs). It is used to release, track, and control 

software versions. [DID ID: DI-IPSC-81442A] 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

57 

4. Software Product Specification (SPS): The SPS contains or references the executable 

software, source files, and software support information, including “as built” design 

information and compilation, build, and modification procedures, for a Computer 

Software Configuration Item (CSCI). [DID ID: DI-IPSC-81441A] It is the 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. [Defense Acquisition University] 

5. Software Installation Plan (SIP): The SIP is a plan for installing software at user 

sites, including preparations, user training, and conversion from existing systems. 

[DID ID: DI-IPSC81428A] 

6. Software Test Plan (STP): The Software Test Plan (STP) describes plans for 

qualification testing of Computer Software Configuration Items (CSCIs) and software 

systems. It describes the software test environment to be used for the testing, 

identifies the tests to be performed, and provides schedules for test activities. There 

is usually a single STP for a project. The STP enables the acquirer to assess the 

adequacy of planning for CSCI and, if applicable, software system qualification 

testing. [DID ID: DI-IPSC-81438A] 

7. Software Test Report (STR): The Software Test Report (STR) is a record of the 

qualification testing performed on a Computer Software Configuration Item (CSCI), a 

software system or subsystem, or other software-related item. The STR enables the 

acquirer to assess the testing and its results. [DID ID: DI-IPSC-81440A] 

8. Software Test Description: The Software Test Description (STD) describes the test 

preparations, test cases, and test procedures to be used to perform qualification testing 

of a Computer Software Configuration Item (CSCI) or a software system or 

subsystem. [DID ID: DI-IPSC-81439A] 

9. Software Design Description: The Software Design Description (SDD) describes the 

design of a Computer Software Configuration Item (CSCI). It describes the CSCIwide design decisions, the CSCI architectural design, and the detailed design needed 

to implement the software. The SDD may be supplemented by the Interface Design 

Descriptions (IDDs) and Database Design Descriptions (DBDDs). [DID ID: DIIPSC-81435A] 

10. Interface Requirements Specification: The Interface Requirements Specification 

(IRS) specifies the requirements imposed on one or more systems, subsystems, 

Hardware Configuration Items (HWCIs), Software Configuration Items (SWCIs), 

manual operations, or other system components to achieve on or more interfaces 

among these entities. [DID ID: DI-IPSC-81434A] 

 

11. Software Transition Plan (STrP): The developer shall identify all software 

development resources that will be needed by the support agency to fulfill the support 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

58 

concept specified in the contract. The developer shall develop and record plans 

identifying these resources and describing the approach to be followed for 

transitioning deliverable items to the support agency. [DID ID: DI-IPSC-81429A] 

12. Interface Design Description: An Interface Design Description (IDD) describes the 

interface characteristics of one or more systems, subsystems, hardware configuration 

items (HWCIs), computer software configuration items (CSCIs), manual operations, 

or other system components. [DID ID: DI-IPSC-81436A] 

13. Data Accession List (DAL): The purpose of the DAL is to provide a medium for 

identifying contractor internal data which has been generated by the contractor in 

compliance with the work effort described in the Statement of Work (SOW). The 

DAL is an index of the generated data that is made available upon request. [DID ID: 

DI-MGMT-81453A] 

14. Computer Software Product End Items: Provides data formatted for review or 

maintenance to ensure significant milestones are met. Data produced under this 

requirement will be used during the life cycle for development, operation and 

maintenance. [DID ID: DI-MCCR-80700] 

15. Product Drawings/Models and Associated Lists: These data items provide 

engineering data to support competitive procurement and maintenance for items 

interchangeable with the original items. This data represents the highest level of 

design disclosure. [DID ID: DI-SESS-81000C] 

16. Commercial Drawings/Models and Associated Lists: These data items define 

commercial items acquired by the Department of Defense. [DID ID: DI-SESS81003C] 

17. Drawing Number Assignment Report: This data item provides the information 

necessary to maintain the Government’s drawing number usage records. [DID ID: 

DI-SESS-81011C] 

18. Proposed Critical Manufacturing Process Description (PCMPD): The PCMPD 

identifies processes which are proposed for inclusion in the technical data package 

(TDP) as mandatory to meet the engineering requirements of the item or component 

part thereof for which the TDP is being prepared. [DID ID: DI-81012C] 

19. Special Inspection Equipment (SIE) Drawings/Models and Associated Lists: These 

data items provide the data required for the limited production of SIE which 

duplicates the physical and performance characteristics of the original SIE. [DID ID: 

DI-SESS-81004C] 

20. Special Tooling (ST) Drawings/Models and Associated Lists: These data items 

provided the data required for the limited production of ST which duplicates the 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

59 

physical and performance characteristics of the original ST. [DID ID: DI-SESS81008C] 

21. Source Control Drawing Approval Request: This data item provides the Government 

with a means for approving and disapproving the use of source control drawings for 

specific items selected for use in the equipment. [DID ID: DI-SESS-81010C] 

22. Detail Specification Documents: A detail specification will be used to specify design 

requirements for items used in multiple programs or applications, in terms of 

materials to be used, how a requirement is to be achieved or how an item is to be 

fabricated or constructed. Detail specification documents are intended for reference 

in acquisition contracts. [DID ID: ID-SDMP-81464A] 

23. Program-Unique Specification Documents: A program-unique specification will be 

used to specify functional and performance requirements and, where applicable, 

design solutions for systems, items, software, processes, and materials developed and 

manufactured for use with a single system, product, or application. Requirements are 

stated, as applicable, in terms of required results, the environment in which it must 

operate, interface, and interchange characteristics; materials to be used; how the item 

is to be fabricated or constructed; and criteria for verifying compliance. Programunique specification documents are intended for reference in contracts. [DID ID: IDSDMP-81493] 

24. Integrated Master Schedule (IMS): The IMS is an integrated schedule containing the 

networked, detailed tasks necessary to ensure successful program execution. The IMS 

is vertically traceable to the Integrated Master Plan (IMP) (if applicable), the Contract 

Work Breakdown Structure (CWBS), and the Statement of Work (SOW). The IMS 

shall be used to verify attainability of contract objectives, to evaluate progress toward 

meeting program objectives, and to integrate the program schedule activities with all 

related components. This DID is applicable to development, major modification, and 

low rate initial production efforts; it is not typically applied to full rate production 

efforts. [DID ID: DI-MGMT-81650] 

25. Reuse Management Report (ReMR): The Reuse Management Report (ReMR) 

provides information about existing software products intended to be re-used as-is or 

modified as part of the delivered operational software. The report also provides the 

acquirer insight into the current status of the activities associated with the reuse of 

these products as compared to the planned activities, and alternative approaches. 

[DID ID: DI-SESS-81771] 

The following recommended deliverables for open architecture systems do not have 

official Data Item Descriptions (DIDs) maintained by DoD. However, we have listed 

them and provided brief descriptions to help programs understand the additional types of 

data they should acquire during system acquisition: 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

60 

1. An Open System Management Plan addressing architecture openness that describes, 

but is not limited to: the Offeror’s approach to open system architecture, modular, 

open design; inter-component dependencies; design information documentation; 

technology insertion; life-cycle sustainability; interface design and management; 

treatment of proprietary or vendor-unique elements; and, reuse of pre-existing items 

including all Commercial-Off-the-Shelf/Non-developmental Item (COTS/NDI) 

components, their functionality and proposed function in the system, and copies of 

license agreements related to the use of these components for Government approval. 

The open system management plan shall also include a statement explaining why 

each COTS/NDI was selected for use. The initial plan shall be submitted with the 

CDRL. 

2. Results of [periodic or milestone-based] NOA assessments using Governmentspecified tools and methodologies (e.g., OAAT or MOSA PART). 

3. Results of [periodic or milestone-based] market surveys conducted to identify 

candidate Government IP assets, COTS and other reusable NDI capable of achieving 

the performance requirements of solutions that it has proposed to custom build. 

4. [Semi-annual, annual, etc.] Naval Open Architecture-related updates to the System 

Management Plan. 

5. Results of regular [semi-annual, annual, etc.] reviews of the contractor’s plan for 

addressing exceptions to reuse. 

6. Results of regular [semi-annual, annual, etc.] reviews of the contractor’s plan for 

addressing (and minimizing the use of) proprietary or vendor-unique elements. 

7. Documented results of product demonstrations that exhibit the OA aspects of the 

system or component. 

8. Regular [semi-annual, annual, etc.] review and update of the contractor’s rationale 

for the modularization choices made to generate the design. These updates shall 

explicitly address any tradeoffs performed, particularly those that compromise the 

modular and open nature of the system. 

9. Documents that provide a detailed tracing of all system requirements (including those 

contained in the Initial Capabilities Document, Capabilities Development Document, 

and in Section C of this Solicitation) to one or more design modules. [See Section L, 

Paragraph 1, subparagraph c.] 

10. The Offeror shall provide documentation demonstrating that their system design 

meets MOSA and other requirements identified in Section C/SOW and can facilitate 

component reuse by conducting a series of demonstrations. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

61 

11. The Offeror shall deliver a notional test plan, test protocol, test design, testing 

software, testing tools, etc., necessary to support the independent Government testing 

and assessment of the ___________ components and demonstration of the 

interoperability of the components. 

12. The Offeror shall deliver to the Government, specifically the activity ____________ a 

copy of the ____________software application(s) including all testing devices, 

testing software, results and materials, along with all supporting documentation, for 

the Government to use for testing. 

13. The Offeror will develop and maintain a Common Data Model for the system and 

will provide the Government with updates at [monthly, quarterly, etc.] intervals. 

14. Executable source code and binaries (including the specified programming languages, 

libraries, and tools). 

15. Package description: makefiles. “Makefiles” is a set of software code that performs a 

set of actions in a sequence. Normally a “makefile” is a (plain text) script file that a 

compiler uses to compile and link files to make an executable. The file lets the 

compiler know the order to compile. Specifically, “make” is a command to use the 

makefile to compile a C++ file. For example, Java uses a program called Ant 

(http://ant.apache.org/) which uses an XML file to do the same thing. 

16. Environment description. 

17. Ownership / licensing and permission information. 

18. Installation script files in uncompressed segment installer format. 

19. Software test programs and source code, including tools. 

20. Software and system test report(s), test data (if available) and test metrics, including 

“bug reports.” 

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

[http://sepo.spawar.navy.mil/SDF.doc] 

22. Software Test Procedures: The Software Test Procedure describes plans for 

qualification testing of Computer Software Configuration Items (CSCIs) and software 

systems. [Pogner] 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

62 

23. Software Users Manual (SUM): The Software User Manual (SUM) tells a hands-on 

software user how to install and use a Computer Software Configuration Item (CSCI), 

a group of related CSCIs, or a software system or subsystem. [University of 

Massachusetts; http://www2.umassd.edu/SWPI/DOD/MIL-STD-498/SUMDID.PDF] 

24. Waveform: A waveform is the representation of a signal as a plot of amplitude 

versus time. [DAU] 

25. Design Specification: A design specification provides detailed description of the 

design. It uses data flow diagrams or other data representations developed during 

requirements analysis and refined during design to derive software structure. 

[University of Southern California; 

http://sunset.usc.edu/classes/cs577b_97/projdocs/team1/design.html] 

26. Porting Plan: A porting plan lists the main tasks of the port and some of the 

associated information for each task (start date, end date, elapsed time, dependencies, 

who is assigned, etc.). [IBM; 

http://www.ibm.com/developerworks/db2/zones/porting/planning.html] In 

programming, to “port” (verb) is to move an application program from an operating 

system environment in which it was developed to another operating system 

environment so it can be run there. Porting implies some work, but not nearly as 

much as redeveloping the program in the new environment. open standard 

programming interface (such as those specified in X/Open's 1170 C language 

specification and Sun Microsystem’s Java programming language) minimize or 

eliminate the work required to port a program. [SearchNetworking.com; 

http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci212807,00.html] 

27. Waveform Port Report 

28. Waveform Description Document 

29. Security Engine: A security engine is a software resource that enforces security 

policies designed to help ensure that a vulnerability of an application or operating 

system cannot be exploited. [Free Patents Online; 

http://www.freepatentsonline.com/20060021002.html] 

30. Software Estimation File: The software estimate file contains the estimation of the 

software size, cost, schedule, and critical computer resources critical to the effective 

planning and tracking of a software-intensive project. 

[http://sepo.spawar.navy.mil/SW_Estimation_Process_Expert_Mode.doc] 

31. Software Security Report 

32. Software Metrics Report: The software metrics report presents guidelines for 

establishing a software measurement process as part of an organization’s overall 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

63 

software process. [IT Metrics & Productivity Institute; 

http://www.itmpi.org/default.aspx?pageid=235] 

33. Interface Control Document: An interface control document describes the 

relationship between two components of a system in terms of data items and 

messages passed, protocols observed and timing and sequencing of events. [Chamber 

of Commerce; http://www.chambers.com.au/glossary/icd.htm] 

34. Software Maintenance Plan (or Software Configuration Management Plan): A 

software configuration management plan enables the controlled and repeatable 

management of information technology components as they evolve in all stages of 

development and maintenance. Enables the controlled and repeatable management of 

information technology components as they evolve in all stages of development and 

maintenance. [State of Michigan] 

35. Product Reuse Demonstration Inventory List: A detailed list of all code files in the 

product baseline, including all third-party software (operating systems, middleware, 

applications, and device drivers) not delivered within the terms of the contract but 

used in the system to form the working product. 

36. Product Reuse Demonstration Inspection Report: A detailed list of all company 

markings found in the source code to ensure the Government has GPR to use the 

software delivered in the contract. 

37. Product Reuse Demonstration Build Procedure Development Report: A report 

containing a build procedure in sufficient detail to allow a third party to recreate the 

operational system on a compatible processing platform. It shall address the results 

of the code inventory and inspection to account for software that is not deliverable 

due to proprietary rights limitations such that the user can complete the installation 

process. 

38. Product Reuse Demonstration Report: A report detailing the results of the formal 

demonstration of the build process using the product baseline software and approved 

procedures showing the software can be successfully ported to other third-party 

compatible open architecture processing systems. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

64 

Appendix 2: NOA CHECKLIST (short) 

The items below are intended to be a quick check on a system’s programmatics that, 

when properly applied, will yield the benefits of an open system. 


 For components which are expected to evolve to meet new or unforeseen 

performance requirements, does the Government have at least Government 

Purpose Rights (GPR) in any software or documentation being developed or used 

to build the system? 


 Are proprietary components well-defined, limited in scope, and designed so that 

others are not precluded from interfacing with the component or other parts of the 

system or from developing and providing components with comparable or 

improved performance and form, fit and function? 


 Are your program’s design artifacts disclosed “early and often” and freely 

available for reuse by another program or third parties? 


 Is design disclosure enabled by keeping data, code and design artifacts in a 

repository either maintained by or overseen by the Government, such as the 

Surface Domain’s SHARE Repository or the C4I Domain’s NESI Collaboration 

site; providing the artifacts electronically upon requests made via the 

Government; allowing requesting parties to obtain them directly from the source 

firm through a process involving review and approval from the Government; or 

requiring that contractors allow the program to have continuous, real-time access 

to the development environment with access to artifacts? 


 Does the program use widely-accepted and supported standards to define interface 

definitions or key interfaces that are published and maintained by recognized 

organizations? 


 Does your program encourage continuous competition for components, modules, 

and tasks? Is it easy for your follow on contract to go to anyone other than the 

incumbent? 


 Does your program utilize commodity products (i.e. COTS products with a large 

user base)? Can the decision leading to the selection of specific COTS products 

be supported (e.g., with test results, architectural suitability, “best value” 

assessments, etc.)? 


 Does your program use modules or components that are also being used by other 

programs with different product vendors? 


 Does the Program plan and directive documentation specify that anything the 

government paid to develop is available for delivery to the Government with all 

of the developmental artifacts and unlimited usage rights? 


 Does your program use an integrated team approach to identify how changes 

affect the system? 


 Is the infrastructure of your system open? (Operating System, Databases, 

Communications, Interfaces, Tools) 


 Does porting to a new hardware platform require minimal time and resources? 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

65 

Appendix 3: NOA CHECKLIST (long) 

OPNAV has established five principles of Naval Open Architecture (NOA) that form the 

basis for system design and program management of weapons systems. The items below 

are intended to be a quick check on a system’s programmatics that, when properly 

applied, will yield the benefits of an open system. 

Modular Design and Design Disclosure


 Has the system design separated hardware from operating system from 

middleware from applications? 


 Are the system’s applications functionally segregated to provide separability and 

the ability to function as independent entities? 


 Can the computing plant be upgraded without the necessity to change operating 

system, middleware or applications? 


 Are the functional components of the system well defined with clearly specified 

functions and interfaces? 


 Are the system/subsystem/component/application specifications and design data 

available to a broad cross section of potential providers? 


 Is design disclosure accomplished on a frequent basis throughout the development 

process? 


 Is design disclosure enabled by keeping data, code and design artifacts in a 

repository either maintained by or overseen by the Government such as the 

Surface Domain’s SHARE Repository or the C4I Domain’s NESI Collaboration 

Site; providing the artifacts electronically upon requests made via the 

Government; allowing requesting parties to obtain them directly from the source 

firm through a process involving review and approval from the Government; or 

requiring that contractors allow the program to have continuous, real-time access 

to the development environment with access to artifacts? 


 Does the Program plan and directive documentation specify that anything the 

government paid to develop is available for delivery to the Government with all 

of the developmental artifacts and unlimited usage rights? 

Reusable Application Software

Reuse practices by the program: 


 Has the program investigated potential reuse components from other programs? 


 Has the contract/RFP required the prospective integrator to conduct market 

research to identify potential reuse candidates from a broad spectrum of 

providers? 


 Does the program participate in Domain/Community of Interest asset reuse 

repository/library capabilities? 


 Can Programs ensure that potential Offerors who do not have access to reuse 

repositories/libraries because they lack a current contractual vehicle are informed 

of the contents of the repositories and allowed access to artifacts as appropriate? 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

66 

Creating assets suitable for potential reuse: 


 Are applications created with well-defined and documented interfaces? 


 Have widely-accepted standards been used in application design? 


 Are the application functional requirements clearly defined and well documented? 


 Have the test cases for each application been documented and made available? 


 Is the development environment for each application an industry standard, openly 

available product? 


 Have the appropriate data rights been obtained with each application (normally 

Government Purpose Rights)? 


 If a product contains proprietary elements, are the license requirements for use 

clearly documented, and those proprietary elements segregated with well-defined 

interfaces such that modification of another component will not require 

modification of the proprietary product? 


 Does the RFP/Contract require that the vendor provide deliverables that are 

structured to provide for discovery and potential reuse of the asset? 


 Have the asset packages (i.e., the deliverable) been reviewed prior to Government 

acceptance to ensure that they contain only the agreed upon license and data 

rights markings? 

Interoperable joint warfighting applications and secure information exchange


 Have the functions of the application been well defined to facilitate commonality 

with other service programs? 


 Has the application/system been designed to conform to a community of 

interest/joint warfighting data/information model? 


 Does the application/system comply with current information assurance standards 

and requirements? 


 Is the application/system designed to function in a net-centric environment 

according to well-defined, net-ready Key Performance Parameters (KPPs)? 


 Has the system design considered and does it comply with a higher-level 

architecture to facilitate interoperability? 


 Is there continual, data-driven assessment of deployed operational performance 

incorporating end-user feedback and explicit data gathered from real world 

operations? 

Life Cycle Affordability


 Has the system/program leveraged common development and maintenance of 

applications with another system/program to reduce life cycle software 

maintenance costs? 


 Has the program executed Performance Based Logistics (PBL) agreements for life 

cycle support that leverage the advantages of COTS hardware? 


 Do PBL agreements employ distance support techniques to reduce down time and 

reduce cost? 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

67 


 Is operator and maintenance training optimized to support shortened cycle times 

and leverage commercial training? 


 Are training systems designed to leverage the COTS nature of open system 

architecture systems to provide better fidelity to operational systems and reduce 

cost? 


 Has the program built in incentive structures to reward reduction in total 

ownership cost over the life cycle? 


 Has the system design reduced life cycle cost by leveraging modularity to reduce 

the effort and cycle time of system modernization? 


 Has the program made use of commodity COTS computing and networking 

hardware to reduce procurement and maintenance cost? Can the decision leading 

to the selection of specific COTS products be supported (e.g., with test results, 

architectural suitability, “best value” assessments, etc.)? 


 Has system modularity been leveraged to provide a hardware modernization and 

obsolescence mitigation path? 


 Have proprietary products been avoided to prevent vendor lock-in and sole source 

environments? 

Encouraging Competition and Collaboration


 Has the acquisition plan separated functions (e.g., architect, integrator, application 

provider) to permit separate contracts for components of the system? 


 Has a transparent peer group process been established to provide for independent 

evaluation of alternative components and selection of best of breed components 

for the system? 


 Has a collaborative environment been established to promote cooperation and 

collaboration among government and industry partners in the system 

development? 


 Are logical points in the development cycle established at which competitive 

processes can be leveraged to expand the vendor base where advantageous to the 

Government? 


 Can a different vendor be chosen to provide any component of the system if 

advantageous to the Government? 


 Have incentive structures been built into the program plan and contracts to reward 

cooperation and collaboration among the architect, integrator, and component 

providers? 


 Has the program leveraged the Science and Technology (S&T) program to 

identify innovative concepts and new participants? 


 Is there a SBIR and technology transition plan in place to encourage participation 

by qualified small businesses? 


 Has the program sought opportunities for joint development or component reuse 

with other Naval and Joint programs? 


 Is the end user included in the system design and upgrade process as well as the 

training definition? 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

68 

Appendix 4: RECOMMENDED DATA LANGUAGE FOR CODE 

HEADERS

Deliverable artifacts should include embedded data or language in code headers or in 

other locations that provides key information for those seeking to use these items in the 

future. The following are suggestions that can be used as appropriate for artifacts 

delivered under Unlimited, GPR, and Specially Negotiated License Rights. 

Recommended Language Regarding Restrictive Rights 

 The Government must be vigilant in identifying and challenging any restrictive 

markings on deliverables that are inconsistent with the rights the Government has 

acquired under the contract. For example, if the Government has contracted for GPR in a 

particular deliverable, the contractor shall not mark that deliverable with any legend that 

would limit or contradict that GPR license. 

 To protect against this occurrence, if an individual supporting the [specific] 

program identifies any restrictive markings on a deliverable, that individual shall 

immediately notify the cognizant Program Manager and Contracting Officer to ensure 

that any such restrictive markings are consistent with the terms of the contract. If those 

markings are not consistent with the terms of the contract, the Government shall not 

accept the deliverables, the Program Manager shall promptly notify the [PEO], and the 

Contracting Officer shall promptly follow the procedures in DFARS 252.227-7013 and 

DFARS 252.227-7014 for handling nonconforming markings and the procedures in 

DFARS 252.227-7019 and DFARS 252.227-7037 for handling unjustified markings. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

69 

Unlimited

//////////////////////////////////////////////////////////////////////////////// 

/// SECURITY CLASSIFICATION: UNCLASSIFIED 

////////////////////////////////////////////////////////////////////////////////

Copyright (C) (Date & Company) 

Notwithstanding any copyright notice, U.S. Government rights in this work are defined by DFARS 

252.227-7013 or DFARS 252.227-7014 as detailed below. Use of this work other than as 

specifically authorized by the U.S. Government may violate any copyrights that exist in this work.

 

/// UNLIMITED RIGHTS 

/// DFARS Clause reference: 252.227-7013 (a)(15) and 252.227-7014 (a)(15)

/// Unlimited Rights. The Government has the right to use, modify, reproduce, perform,

/// display, release or disclose this (technical data or computer software) in whole or in part, in 

/// any manner, and for any purpose whatsoever, and to have or authorize others to do so.

///

/// Distribution Statement D. Distribution authorized to the Department of Defense and 

/// U.S. DoD contractors only in support of US DoD efforts. Other requests shall be 

/// referred to [PEO]. 

/// 

/// Warning: - This document contains data whose export is restricted by the Arms Export 

/// Control Act (Title 22, U.S.C., Sec 2751, et seq.) as amended, or the Export Administration 

/// Act (Title 50, U.S.C., App 2401 et seq.) as amended. Violations of these export laws 

/// are subject to severe criminal and civil penalties. Disseminate in accordance with 

/// provisions of DoD Directive 5230.25.
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

70 

Government Purpose Rights 

//////////////////////////////////////////////////////////////////////////////// 

/// SECURITY CLASSIFICATION: UNCLASSIFIED 

////////////////////////////////////////////////////////////////////////////////

Copyright (C) (Date & Company) 

Notwithstanding any copyright notice, U.S. Government rights in this work are defined by DFARS 

252.227-7013 (f)(2) and DFARS 252.227-7014 (f)(2) as detailed below. Use of this work other 

than as specifically authorized by the U.S. Government may violate any copyrights that exist in 

this work.

 

/// GOVERNMENT PURPOSE RIGHTS

///Rights in Technical Data, computer software & documentation in non-commercial items 

///DFARS Clause: 252.227-7013 (f)(2) and 252.227-7014 (f)(2) 

Government Purpose Rights. The Government's rights to use, modify, reproduce, release, 

perform, display, or disclose these technical data are restricted by paragraph (b)(2) of the Rights 

in Technical Data-Noncommercial Items clause contained in the below identified contract. No 

restrictions apply after the expiration date shown below. Any reproduction of technical data or 

portions thereof marked with this legend must also reproduce the markings. 

 Contract No. 

 contractor Name 

 contractor Address 

Expiration Data 

/// 

/// Distribution Statement D. Distribution authorized to the Department of Defense and 

/// U.S. DoD contractors only in support of US DoD efforts. Other requests shall be 

/// referred to [PEO].

/// 

/// Warning: - This document contains data whose export is restricted by the Arms Export 

/// Control Act (Title 22, U.S.C., Sec 2751, et seq.) as amended, or the Export Administration 

/// Act (Title 50, U.S.C., App 2401 et seq.) as amended. Violations of these export laws 

/// are subject to severe criminal and civil penalties. Disseminate in accordance with 

/// provisions of DoD Directive 5230.25.
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

71 

Specially Negotiated License Rights

//////////////////////////////////////////////////////////////////////////////// 

/// SECURITY CLASSIFICATION: UNCLASSIFIED 

////////////////////////////////////////////////////////////////////////////////

Copyright (C) (Date & Company) 

Notwithstanding any copyright notice, U.S. Government rights in this work are defined by DFARS 

252.227-7013 (f)(2) and DFARS 252.227-7014 (f)(2) as detailed below. Use of this work other 

than as specifically authorized by the U.S. Government may violate any copyrights that exist in 

this work.

/// Specially Negotiated License Rights (Special GPR)

///Rights in Technical Data, computer software & documentation in non-commercial items 

///DFARS Clause: 252.227-7013 (f)(2) and 252.227-7014 (f)(2) 

The Government's rights to use, modify, reproduce, release, perform, display, or disclose these 

technical data and computer software are restricted by the specially negotiated Government 

Purpose Rights license contained in the below identified agreement at clause H- . Any 

reproduction of technical data or portions thereof marked with this legend must also reproduce 

the markings. 

 Contract No. 

 contractor Name: 

 contractor Address: 

Expiration Data: 

/// 

/// Distribution Statement D. Distribution authorized to the Department of Defense and 

/// U.S. DoD contractors only in support of US DoD efforts. Other requests shall be 

/// referred to JPEO JTRS. 

/// 

/// Warning: - This document contains data whose export is restricted by the Arms Export 

/// Control Act (Title 22, U.S.C., Sec 2751, et seq.) as amended, or the Export 

/// Administration Act (Title 50, U.S.C., App 2401 et seq.) as amended. Violations of 

/// these export laws are subject to severe criminal and civil penalties. Disseminate in 

/// accordance with provisions of DoD Directive 5230.25. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

72 

 Appendix 5: OPEN SOURCE SOFTWARE 

Open Source Software (OSS) is a valuable resource for the development of modern 

National Security Systems (NSS). Many OSS products are robust and can be integrated 

with low technical risk and provide a high degree of design disclosure. However, there 

are certain programmatic issues or risks that must be evaluated when selecting OSS 

products. The terms “open source” and “open architecture” are often confused and at 

times even used interchangeably. However, these terms are distinct. “Naval Open 

Architecture” (NOA) refers to business and technical principles the Navy and Marine 

Corps are applying to modernize its Fleet and systems, reduce costs, decrease time to 

field, and facilitate rapid technology insertion (and is defined in the Glossary). “Open 

architecture” is a type of architecture (or design) whose specifications are made public by 

its designers which allows users to make modifications to various components. It should 

be noted that “openness” can be thought of in degrees, based on the level and scope of the 

information provided and its availability to third parties. OSJTF defines “open system 

architecture” as 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. 

Open source software is a good resource for assisting in the implementation of the 

technical aspects of open architecture but its use is not sufficient for a system to be 

“open.” According to the Open Source Initiative, “open source doesn’t just mean access 

to the source code.” The distribution terms of the open-source software must also comply 

with 10 criteria, several of which include: (1) free distribution; (2) include the source 

code; (3) allow modifications and derived works; and (4) distribution of the license.17 

The following is recommended guidance for Navy and Marine Corps Program Managers 

who choose to use open source software in their systems. 

General Information: 

DoD Memorandum Clarifying Guidance Regarding Open Source Software (OSS)

On October 16, 2009, acting Assistant Secretary of Defense (Networks & Information 

Integration) / DoD Chief Information Officer (CIO) David M. Wennergren promulgated a 

Memorandum for Secretaries of the Military Departments on Clarifying Guidance 

Regarding Open Source Software (OSS). In the memo, Wennergren noted that “there 

have been misconceptions and misinterpretations of the existing laws, policies and 

regulations that deal with software and apply to OSS, that have hampered effective DoD 

use and development of OSS.” 

The DoD guidance acknowledges that in “almost all cases, OSS meets the definition of 

‘commercial computer software’.” It also details some “positive aspects” of OSS to be 

considered when conducting market research into commercial computer software: 

 

17 A more complete definition of open source, including all 10 open source criteria, is 

available from the Open Source Initiative’s website at http://www.opensource.org. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

73 

• Continuous and broad peer-review supports software reliability efforts; 

• Unrestricted ability to modify source code enables rapid responses to changing 

situations; 

• Reduced reliance on a particular software developer or vendor; 

• Lack of restrictions on who can use the software and in what fields of endeavor it 

can be used, thus enabling a net-centric licensing model; 

• A cost advantage due to its typical lack of a per-seat licensing cost; 

• Reduced total ownership cost due to shared maintenance responsibility; and 

• Suitability for rapid prototyping and experimentation due to the ability to “test 

drive” the software with minimal costs and delays. 

Additionally, the guidance highlights the common “misconception that the Government 

is always obligated to distribute the source code of any modified OSS to the public, and 

therefore that OSS should not be integrated or modified for use in classified or other 

sensitive DoD systems. In contrast, many open source licenses permit the user to modify 

OSS for internal use without being obligated to distribute source code to the public.” 

More information on the DoD’s policies with respect to OSS is available at 

http://www.defenselink.mil/cio-nii/sites/oss/index.shtml. The October 16 memo is 

available at http://www.defenselink.mil/cio-nii/sites/oss/2009OSS.pdf. 

As the DoD guidance states, open source software is generally regarded as commercial 

computer software for which the source code is publicly available to all users under 

specific licensing terms and conditions that provide a user the right to use, modify, and 

redistribute the modified open source software to the public. Some open source software 

licenses require that, if further distributed, the modified open source software be 

distributed under the terms and conditions of the original license. 

To accept open source software, the Government must be prepared to accept delivery of 

open source software under the terms of the open source software license, and with the 

knowledge that Government will not be able to negotiate the open source software 

license terms. At the same time, the Government must also comply with the licensing 

and operational security requirements of non-open source software. Government cannot 

modify open source software by merging open source software with computer software 

that is classified or otherwise not releasable to the public because of licensing or data 

rights restrictions. 

Thus, to accept delivery of open source software while complying with all computer 

software licensing requirements, the Government must have a very good understanding 

of: 

1. What the open source software is and the licensing constraints for the open source 

software; 

2. How the open source software will be used within the system being procured; 

3. Whether it is likely the open source software will need to be modified and/or 

distributed over the lifecycle of the system; and 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

74 

4. The impacts on non-open source computer software, both commercial and noncommercial, if distribution under the open source software license is required when the 

open source software is modified. 

Issues to Consider When Using Open Source Software 

Since open source software is really a particular type of commercial computer software, 

open source software is almost always treated as commercial computer software under 

the Defense Federal Acquisition Regulations Supplement (DFARS). As such, the same 

DFARS policies that apply to procurement of commercial computer software would also 

apply to open source software. That is, the Government shall have only the rights 

specified in the license under which the commercial computer software was obtained. If 

the Government has a need for rights not normally conveyed to the public, then the 

Government must negotiate with the commercial computer software vendor. See DFARS 

227.7202-3, “Rights in Commercial Computer Software or Commercial Computer 

Software Documentation.” But for open source software, this presents special problems 

as detailed below. 

 a) Inability to Negotiate 

The owner(s) of the intellectual property rights in the open source software generally are 

not available for negotiating lesser or greater rights than those rights provided by the 

license that governs the open source software. Accordingly, the Government must accept 

open source software under the terms and conditions dictated by the open source software 

license with the knowledge that the Government will not be able to negotiate the open 

source software license terms. 

 b) “Viral” Licenses 

Open source software delivered or used to perform work under government contracts 

may be unmodified or modified. If modified, “viral’ open source software licenses 

require that the modified open source software, if further distributed, be distributed under 

the terms and conditions of the license covering the original unmodified open source 

software. Accordingly, the Government cannot modify open source software that is 

governed by viral licenses by merging open source software with computer software that 

is classified or otherwise not releasable to the public due to proprietary restrictions (for 

commercial computer software) or data rights restrictions (for non-commercial computer 

software). This is because the Government may want to distribute the 

classified/restricted software on its own terms, or not at all. If there is a need to further 

distribute the open source software that is accepted for delivery, the Government must be 

aware of whether the open source software has a viral license and whether the open 

source software has been modified, and how. In some cases, a well-defined Application 

Programming Interface (API) may be provided to serve as a buffer between the open 

source software and the other non-open source software, which Government desires to 

distribute under its own terms, or not at all. With respect to Naval Open Architecture, the 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

75 

Government prefers to distribute software under the Software-Hardware Asset 

Repository Enterprise (SHARE) license. 

(c) Authorization and Consent. Open source software may be covered by a 

patent of the United States, or by copyright under the Copyright Act (Title 17, U.S. 

Code). When the Government “authorizes and consents” to patent or copyright 

infringement under 28 U.S.C. §1498, the Government may be sued for money damages 

for the infringement but not enjoined from using the open source software. However, 

where the Government does not “authorize or consent,” the contractor may be sued for 

money damages and may be enjoined from further use of the open source software. 

(i) As a general rule, the Government should not insert an authorization 

and consent clause in contracts involving open source software deliverables, or 

where open source software is used to develop a non-commercial computer 

software deliverable. However, the Government may give authorization and 

consent to ensure that work under a Government contract is not enjoined in 

certain cases, such as when the quality of the open source software justifies 

acceptance despite the licensing constraints, where there are no acceptable 

substitutes, where time constraints for delivery do not allow for substitutes, etc. 

(ii) As discussed above, open source software is automatically licensed to 

a user on nonnegotiable terms. Accordingly, a contractor may accept the open 

source software license subjecting them to possible infringement liability; license 

or develop alternative software; obtain an authorization and consent clause to shift 

the infringement liability to the Government; or rely on the doctrine of implied 

authorization and consent. If it is appropriate for the Government to authorize 

and consent to patent and copyright infringement for open source software, the 

Contract Officer may grant the authorization 

Program Managers and Data Managers Actions 

Program Managers and data managers should know and understand what open source 

software is proposed for delivery or performance of work under the contract, what 

licenses govern the open source software, where the open source software is to be used 

and whether the open source software has been or will be modified. With this knowledge 

and understanding, Program Managers and data managers should evaluate use of the 

open source software in light of the issues discussed above. Some open source software 

licenses are fairly innocuous (i.e. attribution, promise not-to-sue, etc.), but others are not. 

If the license is “viral,” the program has to understand what it will be using the open 

source software for and whether it will be used in conjunction with assets obtained from 

the SHARE library or assets contributed to the SHARE library (see the SHARE license). 

(1) To record the due diligence described above, and to facilitate acceptance of 

open source software delivery, use a list which becomes an Attachment to Section J of 

the Contract. A suggested format for the Attachment is as follows: 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

76 

Identification of Open Source Software Use and Modifications 

Open Source 

Software Title 

and Version # 

License and 

Version # 

Name of 

contractor 

Asserting 

Restrictions

Was Open Source 

Software modified 

by contractor? 

If Modified, was Open 

Source Software 

modified by 

incorporation into a 

third party’s software? 

Use of OSS in Performing Under a Contract But Not for Delivery 

In cases where the contractor proposes to use open source software while performing 

under a contract, but not to deliver open source software, program managers and data 

managers should take care that such use does not create Government obligations under 

the open source software licensing scheme. The following language is suggested for 

incorporation into procurement actions. 

“Open source software... is often licensed under terms that require the user to make the 

user's modifications to the open source software or any software that the user 'combines' 

with the open source software freely available in source code form.” If the contractor 

uses open source software in the performance of a Government contract, it must ensure 

that the use thereof does not: (i) create, or purport to create, any Government distribution 

obligations with respect to the computer software deliverables; or (ii) grant, or purport to 

grant, to any third party any rights to or immunities under Government intellectual 

property or Government data rights to the Government computer software deliverables. 

For example, the contractor may not develop a computer software deliverable using a 

open source program (including without limitation libraries) and non-commercial 

computer software program where such use results in a program file(s) that contains code 

from both the non-commercial computer software and open source software if the open 

source software is licensed under a license that requires any ‘modifications’ be made 

freely available. Additionally, the contractor may not combine any non-commercial 

computer software deliverable with open source software licensed under the General 

Public License (GPL) or the Lesser General Public License (LGPL) in any manner where 

such use would cause, or could be interpreted or asserted to cause, the non-commercial 

computer software deliverable or any modifications thereto to become subject to the 

terms of the GPL or LGPL.” 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

77 

Appendix 6: GLOSSARY OF TERMS

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: 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

78 

(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— 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

79 

(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. [Title 41, Chapter 7, Section 431] 

“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, subsystem 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. 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 Surface Domain’s SHARE Repository; 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 access to the development environment 

with access to 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 costeffective and responsive to requests. 

“Domain” represents an administrative structure based on a common sphere of activities. 

In relations to NOA, the Naval Enterprise is divided into six Domains: Surface, 

Subsurface, Air, C4I, Space, and Marine Corps. As specified in the 5 August 2004 ASN 

(RDA) memorandum, the Domain Leads are PEO IWS (Ships), PEO Subs (Subsurface), 

PEO T (Air), PEO C4I (C4I) and PEO (Space). PEO IWS will act in collaboration with 

PEO Ships, PEO Carriers, and PEO LMW. PEO T will collaborate with the other Air 

PEOs and COMNAVAIR. 

“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] 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

80 

“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/intellectual property/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] 

“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 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

81 

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-12] 

“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 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

82 

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, 13th 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. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

83 

[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, we strongly 

urge 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, 13th

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] 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

84 

“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] 

“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] 

“Peer Review” (as used in connection with Naval Open 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 PerformanceBased Logistics and stated that both terms can be referred to as “PBL.” [DAU Glossary 

of Defense Acquisition Acronyms and Terms, 13th 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. 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

85 

“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-12] 

“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 52.227-12]
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

86 

“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 Reuse” is the process of implementing or updating software systems using 

existing software assets. [DAU Glossary of Defense Acquisition Acronyms and Terms, 

13th 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 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

87 

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 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

88 

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 multiservice or joint programs, a single integrated TEMP is required. Componentunique 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, OPNAV 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] 

“System Architecture” is the composite of the design architectures for products and 

their life cycle processes. [IEEE 1220-1998]

“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-12] 

“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 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v.2.0 

Distribution is unlimited. June 30, 2010 

 

89 

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 intellectual property and technical data in whole or in part, in any 

manner, and for any purpose whatsoever, and to have or authorize others to do so. [DAU 

Glossary of Defense Acquisition Acronyms and Terms, 13th Edition] 
For additional information on the Naval 

Open Architecture Contract Guidebook 

or the Naval Open Architecture (NOA) 

effort, please visit: 

https://acc.dau.mil/oa