CONTRACT

GUIDEBOOK

Version 1.1 

25 October 2007 

Prepared by: PEO-IWS 7 

Distribution Statement A: Approved for Public Release; 

Distribution is unlimited. 

NAVAL

OPEN ARCHITECTURE


Table of Contents

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

Chapter A: RECOMMENDATIONS FOR SECTION C LANGUAGE.................. 10 

Chapter B: EXAMPLES OF SECTION H LANGUAGE ......................................... 17 

Chapter C: RECOMMENDATIONS FOR SECTION L LANGUAGE.................. 28 

Chapter D: RECOMMENDATIONS FOR SECTION M LANGUAGE................. 46 

Chapter E: RECOMMENDATIONS FOR INCENTIVIZING CONTRACTORS 49 

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

Appendix 2: 23 DEC 05 OPNAV REQUIREMENT LETTER................................2-1 

Appendix 3: NOA CHECKLIST (short) .................................................................... 3-1 

Appendix 4: NOA CHECKLIST (long)...................................................................... 4-1 

Appendix 5: PEER REVIEWS, ADVANCED CAPABILITY BUILD PROCESS 

AND OA “INS AND OUTS”......................................................................................... 5-1 

Appendix 6: RECOMMENDED DATA LANGUAGE FOR CODE HEADERS...6-1 

Appendix 7: RECOMMENDATIONS FOR SYSTEM SPECIFICATION 

LANGUAGE .................................................................................................................. 7-1 

Appendix 8: OPEN SOURCE SOFTWARE (OSS)................................................... 8-1 

Appendix 9: DOD INFORMATION TECHNOLOGY STANDARDS AND 

PROFILE REGISTRY (DISR)..................................................................................... 9-1 

Appendix 10: GLOSSARY OF TERMS................................................................... 10-1 

Appendix 11: FEEDBACK FORM........................................................................... 11-1 
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

INTRODUCTION 

Purpose: The Naval Open Architecture Contract Guidebook is recommended for 

Program Managers (PMs) who are incorporating Naval Open Architecture (NOA) 

principles 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, including those not considered to be 

“information intensive.” 

This Guidebook contains only 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), the Defense Federal Acquisition Regulation Supplement 

(DFARS). Readers are also advised to review Assistant Secretary of the Navy (Research, 

Development and Acquisition)’s Memorandum on "Software Process Improvement 

Initiative Contract Language," dated November 17, 2006, for additional information on 

Navy's basic software process improvement focus. The Memo provides guidance on 

language to be used in a Request for Proposal (RFP) to “provide confidence to the Navy 

that software integrator and development contractors for Naval software systems have 

well-documented, standardized software processes as well as continuous software process 

improvement practices, equivalent to that articulated by Capability Maturity Model 

Integration (CMMI®) capability level 3. Further, this Memo directs that the language 

contained therein be included in all contracts that contain software development, 

acquisition, and life cycle support beginning with Request for Proposals (RFPs) issued 

after January 1, 2007. This version of the Naval Open Architecture Contract Guidebook

contains this language. 

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 by 

ensuring that all necessary NOA aspects of the procurement are covered. In addition to 

the contract and the Request for Proposal (RFP) and the 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 Specifications should also 

address those areas where future growth is expected, where reuse is envisioned, etc. 

Proper balancing 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. 

1
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

Organization: This document is divided into five chapters containing suggested 

language for Sections C, H, L and M, and Award Fee Plans, respectively, of acquisition 

documents; this material can be tailored for use in the specific phase of the acquisition 

program. It can also be tailored for use in Contract Modifications. Appendix 1 contains 

suggested NOA-related items for use in preparing the Contract Data Requirements List 

(CDRL) and for identifying other contractual deliverables. Appendix 2 includes 

guidelines for conducting an analysis of a program’s intellectual property rights 

requirements. Appendix 3 provides an overview of the Small Business Innovative 

Research (SBIR) program and implications for NOA. Appendix 4 contains the 23 

December 2005 OPNAV Requirements letter that provides Sponsor’s guidance on NOA. 

Appendices 5 and 6 are Checklists that can assist the Program Manager to better 

understand the business and technical aspects of NOA. Appendices 7 through 12 address 

a range of topics related to NOA including Peer Reviews, Data Markings, 

Recommendations for System Specifications and Acquisition Plans, Open Source 

Software, and the DoD Information Technology Standards and Profile Registry (DISR). 

Appendix 13 contains a Glossary of Terms. 

Providing Comments and Feedback: Development and maintenance of this Guidebook

is a spiral process involving a series of “build-test-build” iterations, each on a roughly 

annual release. These releases will incorporate community inputs and address topics that 

emerge from the Naval Enterprise’s experience in NOA. Therefore, PEO IWS 7 is very 

interested in your comments, suggestions, and feedback and has included a Feedback 

Form in Appendix 14. We are also very interested in any “real world” experiences you 

may have in using NOA principles in programs. Comments can be submitted by mail 

using the form provided in this document (as Appendix 14) or (preferred) by 

downloading and submitting the electronic version found in the Policy and Guidance 

section of the Naval OA Special Interest Area at the Acquisition Community Connection 

(https://acc.dau.mil/oa). Freeform emails with “Comments on NOA Contract 

Guidebook” in the subject line can also be sent 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 re-use 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 (hereinafter 

“Government”) ability to acquire at least Government Purpose Rights (GPR) to data and 

intellectual property and to minimize proprietary elements to the lowest component level 

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 and to increase the capabilities of our systems. NOA 

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

systems and enabling re-use of software and related assets. In addition, NOA is an 

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

2
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

 

Warfare in the information age. More importantly, OA will contribute to greater 

competition among system developers through the use of open standards and standard, 

published interfaces. It will also require greater collaboration. Individual Domains (Air, 

Submarines, Surface, C4I, Space and Marine Corps) and PEOs may opt to pursue 

common architectures across their platforms or capabilities; the NOA principles 

highlighted in these materials would apply to these common architectures. 

On June 5, 2007, the Department of the Navy (DON) Chief Information Officer (CIO) 

directed DON commands to treat Open Source Software (OSS) as COTS when it meets 

the definition of a commercial item (see the definition in the Glossary). This will allow 

the 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 general counsel to ensure 

compliance with the OSS license agreement.1

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 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 CDRLs of contracts and Sections L and M of solicitations issued by the Navy 

or Marine Corps for NSS or larger “system of systems” that integrate NSS with platforms 

such as aircraft, submarines, land vehicles 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 United States 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 and/or asset reuse strategy must be considered 

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

1

 DoN Chief Information Officer, Memorandum for Distribution Department of the Navy 

Open Source Software Guidance dated June 5, 2007. 

2

40 U.S.C. § 11103 

3
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

 

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 their relevance to the requirement of the specific 

acquisition being supported. 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 contract language. The Open Architecture Assessment Tool (OAAT)3 

(developed by the Naval Open Architecture Enterprise Team) and the Under Secretary of 

Defense for Acquisition, Technology and Logistics (USD(AT&L)) Open Systems Joint 

Task Force’s (OSJTF’s) MOSA PART4

 are two tools that may help to formulate a good 

OA strategy. Appendices 5 and 6 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, in particular data rights, requirements of their program 

and/or community of interest.5 General guidance for performing an assessment of IPR 

and Data Rights is contained in Appendix 2 of this document. This analysis will help 

Program Managers develop Acquisition Strategies that anticipate potential re-use 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. The attached Section L and M language provides general guidance 

on data rights. Additional details would have to be worked with their specific program 

office. 

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 

3 The OAAT can be found on the Naval OA website at https://acc.dau.mil/oa. 4

MOSA PART (Modular Open System Approach Program Assessment Review Tool). 

5

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

4
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

 

Federal Acquisition Regulations (FAR) and Defense Federal Acquisition Regulation 

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

disadvantaged by not enforcing data rights identified by contractors in their proposals 

and/or not including an effective Contract Data Requirements List (CDRL) and Data 

Information Description (DID) into contracts. The Statement of Work (SOW) tells the 

contractor how he is expected to develop the product/system; 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. These procedures are 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 greater IPR. 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 

of the delivery of: 1) limited rights (LR) data, 2) restricted rights (RR) software, 3) 

standard licenses in Commercial computer software (CS)6, or 4) items covered under 

DFARS 252.227-7015, “Technical Data – Commercial Items,” in technical data related to 

commercial items on the Government's long term costs associated with minimum future 

needs with respect to the system as identified by the Government, e.g., impact of LR in 

data on 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 

6

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

DFARS. 

5
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

 

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 incorporate intellectual property (IP) in asset 

repositories/libraries and use these assets in other systems.7

Award Incentives: 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, technical planning 

and technical 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 

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

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

[General Notes to Preparers: 

7 See also, Appendix 3, "Using SBIRs to Support NOA Goals," for more information on 

how the Small Business Innovation Research program affects what intellectual property 

rights the Government may obtain. 

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

6
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

• The main thrust for the Naval engineering and program manager communities should 

be on the development of appropriate SOW requirements, Data Item Descriptions 

(DIDs), and CDRLs across the enterprise. 

• Although the Guidebook was developed for mixed systems consisting of hardware, 

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

to reflect hardware- or software-only acquisitions. 

• Program Managers should be careful to include testing materials (software, tools, 

instructions, testing results, design artifacts, etc.) in the contract DIDs and CDRLs 

for those items paid for by the Government. The Government should ensure that they 

have appropriate rights and that these items are marked correctly. 

• Program Managers should be careful to prevent contractual restrictions on the 

ability to use software and other components on updated hardware. There have been 

occasions when software licenses preclude or restrict the removal of software 

packages from a specific hardware installation with subsequent reinstallation on 

another platform. 

• The Naval contracting community should focus on training the acquisition workforce 

to include appropriate Section I clauses from DFARS 252.227 “Solicitation Provision 

and Contract Clauses” in the solicitation and contract. In addition, the Naval 

contracting community should consider, as discussed below, developing a “Section H 

Special Provision” that, at a minimum, incorporates the Offeror’s proposal relating 

to an open system management plan into the resultant contracts and requires 

Government concurrence prior to any change in that plan. 

• The Government team needs to conduct a markings review of NOA-compliant 

artifacts prior to Government acceptance. This enforcement must be done during 

execution of the contract by rejection of inappropriately marked deliverables (as 

defined in CDRLs/DIDs). Program Manager review of deliverable markings is 

critical to ensure the Government obtains and can readily exercise the IPR for which 

it has contracted. 

• Offerors should be contractually required to propose and maintain an open system 

management plan, which shall describe—but not be limited to—the Offeror's 

approach to modular, open design; inter-component dependencies; design 

information documentation; technology insertion; life-sustainability; interface design 

and management; treatment of proprietary or vendor-unique elements; reuse of preexisting or common items; and treatment of proprietary elements. Any changes, 

modifications, or alterations to this plan should be incorporated into the contract as 

appropriate.

• 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. Implementing NOA principles includes specifying a finite 

duration for the contracting vehicle and/or a finite number of deliverable units. Short 

duration taskings and small deliverable quantities provide the Program Manager 

with the flexibility to shift to other providers when deemed in the best interest of the 

Government or to obtain better performance or a better product from a different 

vendor competitively selected or programmatically assigned. 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.. 

7
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

• It is incumbent upon the Program Manager and Contracting Officer to fully 

understand the terms of the license including the specific rights and limitations (if 

any) proposed by the Offeror. License agreements should be included in Section J of 

the Contract. 

• Program Managers may want to consider including a requirement to have real-time 

access into 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. 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. Note: While the 

Government will have access to these work products, the Government cannot exercise 

its intellectual property rights until these items are formally delivered to and accepted 

by the Government. 

• To help clearly understand the rights to be provided to the Government, the 

Government recommends that a table listing all the CDRLs be inserted as an 

attachment to the proposal which includes a column wherein the offeror states the 

data rights to be provided with that CDRL when delivered.

• The Program plan and directive documentation shall 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. In addition, the Program shall 

require that the deliverables be provided (or deposited) in the appropriate Domain 

repository (if established). For the Surface Domain, that repository is the Naval Sea 

Systems Command Software/Hardware Asset Reuse Enterprise or “SHARE” 

Repository. Programs must 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.] 

• Definitions of some terms used in this Guidebook are provided as a reference in 

Appendix 9: Glossary of Terms. However, to avoid any uncertainty or ambiguity in 

contracts, these definitions should be included in the actual contract language.]

[Technical Notes to Preparers: 

• PEOs and Program Managers are invited to supplement this language with technical 

requirements appropriate for the element or system being acquired. A goal of NOA is 

that these technical requirements be based, to the extent practicable, on open 

standards. At a minimum, technical standards and related specifications, 

requirements, source code, metadata, interface control documents (ICDs), and any 

other implementation or design artifacts that are necessary for any qualified 

contractor to successfully perform combat system work for the Government will be 

made available to potential vendors. 

• Use of the recommended contract language in this Guidebook does not require 

programs adopt specific technical language; however, it does require contractors to 

explain their use of proprietary or vendor-unique solutions and to propose such use 

at the lowest component or subsystem level. 

8
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

• Not all developments or programs will need to address or emphasize enterprise level 

interoperability. However, those programs required to do so should perform an 

assessment of these enterprise level requirements using the online version of the 

FORCEnet Consolidated Compliance Checklist (FCCC) or its successor. NOTE --

REFERENCE TO BE DETERMINED. Program Managers – working with their 

PEO, Resource Sponsors, and other stakeholders – must evaluate their need and 

ability to interface across the enterprise using the appropriate guidance documents. 

• Software should be delivered in a standalone fashion i.e., not encumbered by any 

particular configuration management tool. Future sites/locations/programs that 

ultimately will use the software or artifacts should have the ability to use whatever 

configuration management tool they desire without any overt or hidden dependencies 

on a given tool.] 

9
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

 

Chapter A: RECOMMENDATIONS FOR SECTION C LANGUAGE 

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

RFP/contract. 

Statement of Work (SOW)9

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

the Navy's 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 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: 

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 (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 must provide this detailed information so the Navy 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, as a 

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

associated with development and qualification. 

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

Memorandum on "Software Process Improvement Initiative Contract Language," dated 

November 17, 2006

10
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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 will 

be required to define, document, and follow an open systems approach for using modular 

design, standards-based 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/Nondevelopment Item (COTS/NDI) components10, 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. 

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. 

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. 

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

layered and modular and uses COTS/NDI hardware, operating systems, and 

middleware that utilize non-proprietary or non-vendor-unique, key Application 

Programming Interfaces (APIs). The Contractor’s design approach shall be 

applied to all subsystems and components. As part of its open 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 (low 

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

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

 

10 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.” 

11
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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 approach shall result in 

modules that are characterized by the singular assignment of identifiable, 

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 GPR 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 

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

12
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

maintain continued access to cutting edge technologies and products from 

multiple suppliers; and 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 the system. 

f. 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 insertion, technology refresh strategies, and other appropriate 

means) and creation of different processes necessary to support MOSA. 

g. 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 or 

UML), 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 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. 

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

i. Life-Cycle Sustainability – The Contractor shall consider use of COTS/NDI and 

open standards to enhance the system’s life-cycle supportability by implementing 

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

through their life cycle. 

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

iv. Identify the interface and data exchange standards between the 

component, module or system and the interconnectivity or underlying 

information exchange medium; 

13
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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 

[Explanation: Appropriate PEO-specified documents will be cited.]; 

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” (See Appendix 7) teams in an 

integrated team approach to effectively identify how individual change(s) 

impact the system’s internal or external interfaces and information 

exchange standards. 

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

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

COTS, Proprietary, Open Source Software 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 reprocurement 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 Open Source Software products 

should be supported by appropriate analysis (e.g. with test results, architectural 

suitability, “best value” assessments, etc.). 

14
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

m. Reuse of Pre-existing or Common Items – The Contractor shall re-use preexisting 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 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. 

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

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

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

15
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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 by adding must be submitted to and approved by the Government 

Program Manager prior to use. 

16
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

Chapter B: EXAMPLES OF SECTION H LANGUAGE 

CLAUSE H - _____: REQUIREMENT FOR AN OPEN SYSTEM MANAGEMENT 

PLAN

The contractor shall submit an Open System Management Plan. 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, consensusbased 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, 

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 in support of peer reviews and the spiral development process. 

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

17
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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

the contractor 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, 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. 

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; 

18
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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

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 proposal, 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 

19
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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 (power and signal wiring), software, 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. 

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 [Explanation: Insert any 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; 

20
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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 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 [Explanation: Insert 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 a 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 

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, 

21
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

capable of achieving the performance requirements of solutions that it 

has proposed to custom build. 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 tradeoffs; 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 intends to evaluate for reuse. At a minimum, 

the Offeror shall describe what artifacts from the [Explanation: Insert 

the specific asset reuse repositories/libraries that will be available to 

Offerors] 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. 

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 designs or allows 

for timely and cost-effective replacement of subsystem elements or 

22
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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. 

23
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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 or other Navy 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. 

Clause H______________: RIGHTS IN COMMERCIAL TD, COMMERCIAL CS, 

AND COMMERCIAL CSD. 

 

i. Prior to incorporation of any commercial or open source software 

documentation ,The contractor shall submit for Government 

approval 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 sub-Offerors 

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; (3) asserted rights category; and (4) 

name of the person asserting restrictions. For any item designated 

as NDI, the contractor shall 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 contractor shall provide a complete description of the 

asserted rights (e.g., a specially negotiated license, 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 

24
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

non-standard or commercial license will be attached for 

Government review. If there is no information to be included in 

the Commercial Restrictions List, the contractor shall submit the 

list and enter "None" as the body of the list. Any approved 

Commercial Restrictions List shall become an attachment to the 

contract. 

ii. The contractor shall submit for Government approval a list, 

entitled “Commercial-Off-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. If there is no information to be included in the 

COTS List, the contractor shall submit the list and enter “None” as 

the body of the list. The COTS List shall become an attachment to 

the contract. 

Clause H - _____________ : SPECIALLY NEGOTIATED LICENSE RIGHTS 

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 

equipment utilizing the [Explanation: 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 

25
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

OF [Explanation: Will be completed 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 [Explanation: Other 

contracts will be added 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 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 [Explanation: Or other specified 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. 

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 an [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 an [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] performs design or development 

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” [Explanation: Applicable revision number will be 

provided by the government] when referring to these versions in order to distinguish 

26
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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. 

27
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

Chapter C: RECOMMENDATIONS FOR SECTION L LANGUAGE 

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. 

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 spiral development process. 

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 [Explanation: The specific 

asset reuse repositories/libraries that the Contractors will review for 

components should be identified] or common components [Explanation:

28
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

These may be specified by the PEO or Program Manager] 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. 

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; 

29
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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

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 

30
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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 and [Explanation: Appropriate 

PEO-specified requirements will be inserted.] 

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: 

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; 

31
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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) and [Explanation: Appropriate PEO-specified requirements will 

be inserted.] 

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

32
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

i. The Offeror 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. 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. 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 IP 

assets, NDI, Open Source Software, and COTS) it intends to evaluate for 

reuse. At a minimum, the Offeror shall describe what artifacts from the 

[Explanation: The specific asset reuse repositories/libraries that will be 

made available to Offerors will be inserted] 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 

33
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

COTS, other reusable NDI, and other components are logistically 

supported throughout the system’s life cycle. 

 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. 

34
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

Factor ( ): System Compliance with Naval OA Guidance

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

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]. A detailed description of 

each of the technical guidance points in Table A is provided in the 

[Explanation: PEO/Community of Interest-specified references and 

Guidance Points should be used in this table. Table A contains examples 

of technical guidance points from the Surface Domain]. 

 

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 

35
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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 

Factor ( ): Management Approach

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 (IPT) 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 

36
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

Naval Sea Systems Command Software/Hardware Asset Reuse Enterprise (SHARE) 

library or other Navy 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 vendorunique rights 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. 

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” (Jun 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” (Jun 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. 

37
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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” (JUN 1995)), 

sets forth a complete description of all such proposed non-standard 

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; (3) asserted rights category; and (4) 

name of the person 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, or the license customarily offered to the public); this 

information may be provided by referencing any proposed nonstandard or commercial license agreement that is attached to the 

38
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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. 

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 

39
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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 

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 [Explantion: describe the type of project here, e.g., 

“submarine combat control”] 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. 

40
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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); 

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

41
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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

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

42
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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” (JUN 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. 

(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 

43
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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. 

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

44
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

 

Software Productivity Improvement Guidance11

The Navy 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 justifies 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. 

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

Memorandum on "Software Process Improvement Initiative Contract Language," dated 

November 17, 2006.

45
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

Chapter D: RECOMMENDATIONS FOR SECTION M LANGUAGE 

[Explanation: This section contains only recommended guidance, and is offered with 

the understanding that individual PEOs and programs can be flexible in selecting and 

weighting those items needed to meet their needs. Programs should not feel that they 

need to address all of the items contained in these recommendations.] 

EVALUATION FACTORS. 

[Explanation: Program Managers are encouraged to prioritize these to meet the 

objectives of their programs.] 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. 

46
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

Software Process Improvement Guidance12

At a minimum, the following three evaluation factors relating to the Offeror's software 

development process shall be included in Section M: 

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. 

 

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

Memorandum on "Software Process Improvement Initiative Contract Language," dated 

November 17, 2006.

47
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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; 

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 

[Explanation: The following are only suggested NOA-specific past performance 

evaluation criteria. Other past performance criteria should be added as appropriate as 

additional subfactors.] 

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 Naval 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 

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 

48
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

Chapter E: RECOMMENDATIONS FOR INCENTIVIZING 

CONTRACTORS 

[Explanation: 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.)] 

 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 and the Office of the Under Secretary of 

Defense (OUSD) for Acquisition, Technology, and Logistics (AT&L) draft “Guide for 

Contracting for Systems Engineering” (V.15, 9/15/2005). 

 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, operating systems, and middleware. 

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

49
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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

Part 2 Award Terms

[Explanation: An award term incentive contract is a relatively new acquisition option 

and while it is not yet described in the Federal Acquisition Regulation (FAR) 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 is 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.] 

50
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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: 

• 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: 

51
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

• 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 

• 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) 

52
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

 

Appendix 1: RECOMMENDED NOA CDRL AND DELIVERABLE 

ITEMS

[Explanation: The following are examples of CDRLs and other deliverable items that 

support NOA and can be incorporated into contracts. This is not a complete list and it 

can be augmented/reduced as appropriate. The frequency and delivery dates of the 

deliverables will 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 ORDERING OF TECHNICAL DATA OR 

COMPUTER SOFTWARE 

In addition to technical data or computer software specified elsewhere in this contract to 

be delivered hereunder, the Government may, at any time during the performance of this 

contract or within a period of three (3) years after acceptance of all items (other than 

technical data or computer software) to be delivered under this contract or the termination 

of this contract, order any technical data or computer software generated in the 

performance of this contract or any subcontract hereunder. When the technical data or 

computer software is ordered, the Contractor shall be compensated for converting the 

data or computer software into the prescribed form, for reproduction and delivery. The 

obligation to deliver the technical data of a subcontractor and pertaining to an item 

obtained from him shall expire three (3) years after the date the Contractor accepts the 

last delivery of that item from that subcontractor under this contract. The Government's 

rights to use said data or computer software shall be pursuant to the "Rights in Technical 

Data and Computer Software" clause of this contract. 

Software Development Process13

The software development process to be used by the winning contractor team is defined 

in their SDP which shall be designated as a CDRL, with initial delivery after contract 

award and periodic updates to be delivered subsequent to process improvement reviews. 

The SDP shall be subject to Government approval. 

The SDP should be modeled after the IEEE/EIA Std. 12207 standard. The Navy should 

not specify a specific format but rather allow Offerors to select their preferred format for 

this document. The content of the SDP, however, needs to meet certain criteria. 

Specifically, the SDP should: 

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

Memorandum on "Software Process Improvement Initiative Contract Language," dated 

November 17, 2006.

1 - 1
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

• 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 (See Appendix 2 to this Guidebook) 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 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 docs, DOORS file or Excel or XML export) 

• Architecture models (e.g., System Architect files, minimum DoDAF views AV1, 

OV2, OV3, OV5, SV1, TV1 in a CADM XML file) 

• 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) 

• 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) 

1 - 2
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

• 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 

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-development 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, MOSA PART, or FITS). 

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. 

1 - 3
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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. 

10. The Offeror shall demonstrate 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. 

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 code and binaries (including the specified programming languages, 

libraries, and tools). 

15. Software version description, including the specified programming languages and 

tools. 

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

17. Environment description. 

18. Ownership / licensing and permission information. 

19. Installation script files in uncompressed segment installer format. 

20. Software test programs and source code, including tools. 

21. Software and system test report(s), test data (if available) and test metrics, including 

“bug reports.” 

1 - 4
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

22. Software Development Plan (SDP): A management plan usually generated by the 

developer outlining the software development effort. [Source: Defense Acquisition 

University]. 

23. Software Requirements Specification (SRS): 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] 

24. 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] 

25. 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. [Pogner; http://www.pogner.demon.co.uk/mil/498/svd-did.htm] 

26. Software Product Specification (SPS): 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] 

27. Software Installation Plan (SIP): is a plan for installing software at user sites, 

including preparations, user training, and conversion from existing systems. 

[Managing Standards, v4.7; http://home.btconnect.com/managingstandard/strdid.htm] 

28. 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. [Pogner; 

http://www.pogner.demon.co.uk/mil/498/svd-did.htm] 

29. Software Test Procedures: The Software Test Procedure describes plans for 

qualification testing of Computer Software Configuration Items (CSCIs) and software 

systems. [Pogner; http://www.pogner.demon.co.uk/mil/498/svd-did.htm] 

1 - 5
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

30. 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. [Managing Standards 

v4.7; http://home.btconnect.com/managingstandard/strdid.htm] 

31. 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] 

32. 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. [Rigby, Ken; http://sparc.airtime.co.uk/users/wysywig/stddid.htm] 

33. Software Design Description: A representation of software created to facilitate 

analysis, planning, implementation, and decision-making. The software design 

description is used as a medium for communicating software design information, and 

may be thought of as a blueprint or model of the system. [IEEE Standards Glossary] 

34. Interface Requirement Specification: Documentation that specifies requirements for 

interfaces between systems or components. These requirements include constraints 

on formats and timing. [IEEE Standards Glossary] 

35. Waveform: A waveform is the representation of a signal as a plot of amplitude 

versus time. [DAU] 

36. 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] 

37. 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] 

1 - 6
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

38. Waveform Port Report 

39. 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] 

40. Software Transition Planning (STRP): The developer shall identify all software 

development resources that will be needed by the support agency to fulfill the support 

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. [Pogner; 

http://www.pogner.demon.co.uk/mil/498/svd-did.htm] 

41. Software Estimation File: the software estimate file contains the estimation of the 

software size, cost, schedule, and critical computer resources is critical to the 

effective planning and tracking of a software-intensive project. 

[http://sepo.spawar.navy.mil/SW_Estimation_Process_Expert_Mode.doc] 

42. Software Security Report 

43. Software Metrics Report: the software metrics report presents guidelines for 

establishing a software measurement process as part of an organization’s overall 

software process. [IT Metrics & Productivity Institute; 

http://www.itmpi.org/default.aspx?pageid=235] 

44. 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] 

45. 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. [Rigby, Ken; 

http://sparc.airtime.co.uk/users/wysywig/stddid.htm] 

Software Interface Design Description: 

46. Software Maintenance Plan (or Software Configuration Management Plan): a 

software configuration management plan enables the controlled and repeatable 

management of information technology (IT) components as they evolve in all stages 

of development and maintenance. Enables the controlled and repeatable management 

of information technology (IT) components as they evolve in all stages of 

1 - 7
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

development and maintenance. [State of Michigan; 

http://www.michigan.gov/documents/techtalk/SEM-0302_Sample_191685_7.pdf] 

47. Computer Software Product End Items 

1 - 8







Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

Appendix 3: 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 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? 


 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; 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? 

3 - 1
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 


 Is the infrastructure of your system open? (Operating System, Data Bases, 

Communications, Interfaces, Tools) 


 Does porting to a new hardware platform require minimal time and resources? 

3 - 2
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

Appendix 4: 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; 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? 

4 - 1
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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?] 

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? 

4 - 2
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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 KPPs? 


 Has the system design considered and does it comply with a higher-level 

architecture to facilitate interoperability? 

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? 


 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 

4 - 3
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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 avoid 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 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? 

 

4 - 4
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

Appendix 5: PEER REVIEWS, ADVANCED CAPABILITY BUILD 

PROCESS AND OA “INS AND OUTS” 

PURPOSE: Provide a Summary of Peer Review features and implementation 

recommendations. 

BACKGROUND: In the late 1990s, the Submarine Community’s Acoustic Rapid COTS 

Insertion (ARCI) program developed a process to address the need to level the playing 

field when evaluating candidate technologies to prevent “fixed competitions.” This 

process features “peer reviews” of alternative solutions. The performance of each 

alternative is measured using actual system data from operational deployments. Both 

“open” data sets (signatures known to the developer prior to user review) and “closed” 

data sets (signatures revealed only during testing) are used in the evaluation process. 

When data from operational deployments is not available, simulation must be relied 

upon. However it is imperative that this simulation faithfully replicate the real world 

environment. 

Peer Review Groups are components of a larger working group, hereinafter referred to as 

the “system working group,” whose focus is typically at the system level. The system 

working group’s primary objectives are: 1) developing and overseeing the 

implementation of a coordinated set of plans and processes aimed at resolving specific 

system performance issues; and 2) identifying system shortfalls, selecting the best 

solutions and establishing the proper feedback processes and tools to enable a data-driven 

build-test-build approach to continuous sub-system performance improvement. A fourstep Advanced Capability Build (ACB) Process is an integral part of the overall 

technology maturation and transition process. The ACB Process ensures adequate 

requirements definition and testing at the advanced development stage. 

DEFINITION: The Naval Open Architecture Contract Guidebook defines a “Peer 

Review” as “a refereed, open process used to assess technical approaches proposed by or 

being used by vendors. Reviewers are normally drawn from a cross section of the 

community of interest with government, academia, and/or private sector entities 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.” The final decision maker is 

ultimately the Navy Program Executive Officer (PEO). 

ATTRIBUTES: In addition to the definition provided above, there are several attributes 

of Peer Review Groups that are key to their success. 

5 - 1
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

Well-run Peer Review Groups build early and interactive bridges between the operational 

Fleet, acquisition communities and technology providers by making transition 

recommendations based on performance, with oversight from the system working group. 

When properly implemented, Peer Review Groups solicit the best ideas available from a 

broad knowledge base. Membership in Peer Review Groups is based on technical 

credentials and their chairpersons are chosen typically by the Navy program sponsor or 

their designated representative for their objectivity and leadership ability. Members have 

equal status within the group and generally are drawn from a diverse set of organizations. 

Because of this diversity, the peer group must develop and use common metrics for 

performance evaluations. Usually, significant up-front time is spent defining relevant 

metrics and ensuring that the definitions are specific enough to enable all organizations to 

compute the metrics in the same manner. 

The Peer Review process works best as a “performance meritocracy.” That is, candidate 

technologies are evaluated with common metrics and common data (open and closed). 

Peer reviews of software or functional capabilities can be conducted in four general steps 

depending on the technology being evaluated. A peer review process should foster 

spirited debate between participants presenting their own views based on their 

organizations and should solicit information from other organizations that are brought in 

via an open process. 

During the open evaluation, it often becomes apparent that the best solution is the result 

of aggregating many inputs. This collaborative development may be difficult to manage 

due to the “pride of ownership” of the parties involved but, in the end results in a better 

product for the Fleet. These contributions should be given with attribution. 

Recommendations should include technologies from inside and outside of the peer 

review membership, keeping in mind that “no one organization has the full story.” 

IMPLEMENTATION: Peer Reviews are an essential part of the overall Advanced 

Capability Build (ACB) Process. The ACB Process represents a fundamental change in 

Navy acquisition strategy by seamlessly coupling advanced development to engineering 

development, leading to significant savings through early technology testing, software 

reuse, and a reduction in lead-time from concept to Fleet introduction. The four basic 

steps required for ACB development include: 1) technology evaluation, 2) technology 

assessment, 3) system real-time implementation, and 4) at-sea testing. Technical reviews 

are conducted between each of these steps. Details of these fours steps are described in 

the next section. 

The Naval Open Architecture (OA) business model requires continuous technical 

competition at the component, sub-system and system levels. A notional model of a 

“system working group” is shown in Figure 1 below. Peer Review Groups address the 

functional and technical issues leading to recommendations for improvements based on 

Fleet inputs. The Peer Review Groups provide recommendations to the system working 

group on research and development priorities, including tasking requests for each funded 

organization, and also provide independent test and evaluation of alternatives. Peer 

5 - 2
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

Review Groups collectively survey, develop and test (or assess) the alternatives, and 

monitor progress through completion of the evaluation process. The program office lead 

of the system working group determines what Peer Review Groups are needed and then 

identifies the chairperson and membership for each group. 

Selecting the leadership and the membership of a peer review organization is critically 

important. Membership selection criteria are based on the talents, experience, and 

capabilities of the individuals rather than on their organizational ties. The goal is to 

collect the “best and brightest” rather than ensuring that every organization has a “seat at 

the table.” Peer Review teams should be formed of experts from government, industry 

(including competing solution providers) and academia. Typically a Peer Review Group 

is composed of ten to twelve members. These experts are drawn from a pool of resources 

that are funded through existing contractual relationships with the government – thus 

their participation doesn’t represent a “new cost.” It is the responsibility of the Program 

Office, working with the Peer Review Group Chair, to ensure that the composition of the 

Group is appropriate and effective. Membership changes can and should be made to 

address Group performance issues. 

Figure 1 -- "Sub-system Working Group" 

Working Group

(Chair) 

Peer

Group 

Peer

Group 

Integrated

Product Team 

Integrated

Product Team

Integrated

Product Team

Peer

Group

“Stakeholders”

- Chaired by “objective” expert

- 10-12 “expert” members

- focused

- “net zero” bias

- multiple alternative solutions

Working Group

(Chair) 

Peer

Group 

Peer

Group 

Integrated

Product Team 

Integrated

Product Team

Integrated

Product Team

Peer

Group

“Stakeholders”

- Chaired by “objective” expert

- 10-12 “expert” members

- focused

- “net zero” bias

- multiple alternative solutions

5 - 3
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

THE FOUR STEPS OF THE ADVANCED CAPABILITY BUILD (ACB) 

PROCESS: 

ACB Step 1 is a survey of promising technologies from the R&D community including 

6.2 and 6.3 Science and Technology Programs (e.g., Office of Naval Research (ONR), 

Defense Advanced Research Projects Agency (DARPA), industry independent research 

and development (IR&D), broad area announcements (BAAs), Small Business 

Innovative Research (SBIR) programs, and other related Navy programs). The goal of 

Step 1 is to consider technology developed by the Navy, other DoD agencies, and 

industry to determine their tactical importance, maturity, expected performance and 

computational resource requirement. 

ACB Step 2 is a test of relatively mature technologies that promise to provide 

performance improvements to the Fleet. These technologies may transition to Step 3 

based on their performance using common data sets and common metrics developed by a 

working group of technical principals in conjunction with developers and Fleet 

representatives. Using real world data sets collected from U.S. Naval exercises and 

provided by the Office of Naval Intelligence (ONI), this testing provides a projection of 

technology performance under real world conditions. Experience has shown that testing 

on synthetic or “developed” data is insufficient for uncovering the problems of many 

technologies in actual Fleet use. 

The ACB Step 2 process is unique in that the developers submit technology for testing 

with the expectation of useful feedback from the testing process. Step 2 is also a risk 

reduction step, affording time to work technology and concept of operations issues 

asynchronously at the technology level before testing in an integrated system under more 

significant time constraints. Technology promotion to ACB Step 3 is based on successful 

performance as determined by the cognizant Peer Review Group. In some cases, 

hardware technologies that are based primarily on commercial-off-the-shelf components 

without extensive modification may satisfy ACB Step 2 requirements through benchmark 

testing. At the discretion of the Peer Review Group and with concurrence of the system 

working group, these technologies may be deemed suitable for integration into the system 

baseline without going through ACB Step 3. 

In ACB Step 3, technology that demonstrates acceptable performance in ACB Step 2 is 

passed to an integration agent for incorporation into the target sub-system. In order for 

this to occur, the sub-system must meet the OA technical principles. This 

implementation constitutes an ACB. The subsequent ACB Step 3 tests are conducted by 

a Test, Evaluation and Assessment Support Group (TEASG) under the “sub-system 

working group.” This provides an opportunity to independently test the ACB for 

compliance with performance requirements as well as fidelity with the ACB Step 2 test 

results. It also serves to introduce Fleet representatives to new features in an end-to-end 

(or “string”) context and provides for Fleet feedback. Similar to ACB Step 2, real-world 

data are used for this testing. Any identified issues resulting from the ACB Step 3 testing 

are then forwarded to the integration agent for resolution prior to at-sea testing in ACB 

5 - 4
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

Step 4. Independent testing of the ACB product is a critical step in the “build-test-build” 

process. It ensures readiness for at-sea testing and provides confidence for the 

community contributors that their ideas have been implemented properly. 

ACB Step 4 is an at-sea test for the ACB and is conducted by the TEASG. This is the 

most important phase of testing prior to inclusion of the technology in the sub-system 

baseline. This test provides the opportunity to verify ACB performance and collect 

calibrated data for future use. The TEASG is also responsible for the evaluation and 

assessment of the test results as well as the interpretation of the component level and the 

sub-system or system level results. The at-sea tests conducted by the TEASG are not 

intended to serve as the system certification. System certification is accomplished by the 

cognizant program office via a separate testing effort following full integration of the 

ACB into the baseline system. However, ACB Step 4 is designed with certification in 

mind so that the program office can use ACB Step 4 performance to ascertain the level of 

certification testing required. In addition, representatives of COMOPTEVFOR 

participate in ACB Step 4 testing as independent observers to facilitate decisions 

regarding future certification testing. At completion of the ACB Step 4 testing, the ACB 

is delivered to the program office for incorporation into the system baseline. 

Subsequent to fielding, performance of system baselines is analyzed based on data 

collected during deployments in actual operational environments as part of an 

Engineering Measurement Program (EMP). The EMP is set up to provide data to support 

future ACB spirals, to establish a new baseline capability to compare to future 

improvements, and to address real-world Fleet issues in operational environments. 

Incorporating Peer Reviews into system acquisition life cycles entails a significant 

change in culture – one that recognizes that no one organization has all the answers and 

that collaborative and competitive processes with free-flowing information are efficient 

for realizing improvements cost effectively. Provisions for conducting Peer Reviews 

should be built into a program’s acquisition strategy, request for proposals, and the 

associated contractual documents. However, Peer Reviews are not intended to be a 

bureaucratic exercise. Rather, Peer Reviews are ad hoc – only put together when the 

program reaches a juncture at which decisions or recommendations must be made among 

technology or business approaches to solve emerging warfighter issues. 

The keys to ACB success are: 1) sharing of information across organizations to create the 

“full story”; 2) data-driven testing (build-test-build); 3) significant Fleet involvement; 4) 

peer review of new developments; 5) verification of technology prior to implementation; 

and 6) continuing assessments and measurements. 

SUMMARY: Well-constructed Peer Group reviews of candidate technologies and 

applications provide for independent and unbiased decision recommendations that 

provide the best options to the Program Manager to meet the urgent needs of the Fleet. 

Ensuring strong, independent leadership and a net-balanced membership of the group is a 

crucial part of an effective Peer Review process, as is the use of real threat data for the 

performance evaluation. The four-step process has been demonstrated by the Submarine 

5 - 5
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

Domain to be both effective and efficient in achieving the desired goals and to be 

extensible. 

5 - 6
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

Appendix 6: 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. 

6 - 1
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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.

6 - 2
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

Government Purpose Rights 

//////////////////////////////////////////////////////////////////////////////// 

/// SECURITY CLASSIFICATION: UNCLASSIFIED 

////////////////////////////////////////////////////////////////////////////////

Copyright (C) (Date & Company) 

Notwithstanding any copyright notice, U.S. Government rights in this work are defined by 

252.227-7013 (f)(2) and 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. 

6 - 3
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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 

252.227-7013 (f)(2) and 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. 

6 - 4
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

Appendix 7: RECOMMENDATIONS FOR SYSTEM 

SPECIFICATION LANGUAGE 

[Explanation: The System Specification is the document that defines the requirements of 

the system to be built and delivered. It is against the system specification that the 

selected contractor will direct its development effort.] 

A System Specification may contain or reference up to six types of information, 

depending on the system and the acquisition plan: 

• System operating environment, to include the missions to be supported as well as 

other systems with which the system will interact. 

• Required capabilities that the system is required to provide. This information 

describes specific way that the system will achieve these capabilities (“the what”) 

through its operational behavior as defined by its behavioral requirements (“the 

how”). 

• Operational scenarios, to include the modes of operation describing how the 

system will achieve its overall goals. 

• Behavioral requirements of the system to be delivered, including functional, 

interface, temporal, capacity, resource utilization, trustworthiness, and usability. 

• Quality requirements, including portability, maintainability, extensibility, 

reusability, and integrity. 

• Implementation requirements, to include restrictions on the product design and 

implementation, as well as restrictions on the processes and development 

approaches to be used to build the system. 

The System Specification does not generally include any programmatic requirements, 

dealing with cost, schedule, and other contractual items. 

The aspects of a system that Naval Open Architecture is concerned with all information 

types listed above, to varying degrees of importance. These are described in this 

Appendix. It is crucial that the desired open system attributes of the system be captured 

in the System Specification, since this document provides the basis for the development 

effort. 

1. Required Capabilities 

When describing the operational capabilities that the system is to provide, the 

Specification needs to also describe existing capabilities that provide the same or similar 

capabilities. This provides an initial basis for searching for systems that may have assets 

that can be re-used. 

7 - 1
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

2. System Operating Environment 

The operating environment will include existing systems with which the system to be 

procured is to interoperate. By describing the environment, the opportunity for 

identifying existing systems or capabilities that already interact with these systems is 

enhanced. Such systems may have assets that can be re-used to facilitate any such 

interactions. 

3. Operational Scenarios 

By describing the expected operational scenarios, there is an opportunity to analyze these 

and determine if any modifications can be made to exploit existing systems that may 

operate in a similar manner. 

4. Behavioral Requirements 

By describing the behavioral requirements, there is an opportunity to analyze identify 

existing systems that provide the same or similar behaviors, and to exploit assets that can 

be re-used. 

5. Quality Requirements 

This type of requirement is especially important for modular, open systems. By 

describing the expectations for portability, extensibility, and reusability, the range of 

potential design solutions is placed into focus. For example, if a System Specification 

describes the required portability in terms of a range of potential operating system 

characteristics while excluding others, then the resulting portability solution is likely to 

be more highly optimized. Likewise, if the desired range of extensibility is clearly 

defined (“function a is a dead-end, function b will be extended by performance 

optimization,” etc.), the design space is more clearly defined, enhancing the opportunity 

of acquiring (or developing) an efficient solution. 

6. Implementation Requirements 

This type of information is particularly relevant for systems to be developed under the 

NOA approach. It is in this section that an open system development approach can be 

required (as well as in the SOW). It is also in this section that specific attributes of 

capabilities are characterized relative to the identification as forming modules. As such, 

this section complements Quality Requirements in that it provides more detail about the 

functional architecture of the system, and identifies the areas that are to be designed with 

flexibility and with an eye to future enhancement. This section also will constrain the 

design approach if there are specific architectural solutions that are required (such as 

existing design frameworks, standard communication solutions, desired operating system 

features, etc.) 

7 - 2
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

Appendix 8: OPEN SOURCE SOFTWARE (OSS) 

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 is applying to modernize its 

Fleet and systems, reduce costs, increase 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.” The following is recommended guidance for 

Navy Program Managers who choose to use open source software in their systems. 

General Information: 

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 

8 - 1
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

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 

Program 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 

8 - 2
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

under its own terms, or not at all. With respect to Naval Open Architecture, the 

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

8 - 3
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

(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: 

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

8 - 4
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

Appendix 9: DOD INFORMATION TECHNOLOGY STANDARDS 

AND PROFILE REGISTRY (DISR)

PURPOSE: Overview describing the DoD Information Technology Standards and 

Profile Registry 

DEFINITION: The DoD IT Standards Registry (DISR), is an online repository of IT 

standards formerly captured in the Joint Technical Architecture (JTA), Version 6.0. 

DISR replaces JTA. DISR online supports the continuing evolution of the DISR and the 

automation of all its processes; it can be accessed at https://disronline.disr.mil. DISR 

online is the repository for information related to DOD IT and National Security Systems 

(NSS) standards. 

BACKGROUND: The objective of the Joint Technical Architecture (JTA) was to 

mandate a set of standards and guidelines for the acquisition of DoD systems that 

produce, use, or exchange information. In 2004, DOD revamped its standard’s 

governance structure and the JTA was replaced by the DISR. DISR should be used by 

anyone involved in the management, development, or acquisition of new or improved 

systems within DoD. 

DISR standards are to be used within DoD as the “building codes” for all new systems. 

The standards are intended to facilitate interoperability and integration of systems within 

the Global Information Grid (GIG). DISR also provides the ability to specify profiles of 

standards that programs will use to deliver net-centric capabilities. At the start of the 

acquisition cycle for new systems, requests for proposals and contract statements of work 

should be reviewed to ensure that DISR IT standards established in Initial Capabilities 

Documents, Capability Development Documents, and Capability Production Documents 

are translated into clear contractual requirements. 

The Defense Information System Agency CIO Executive Board oversees the DISR and 

establishes policies that facilitate IT standards interoperability. The CIO Executive 

Board makes changes, based on recommendations from the IT Standard Oversight Panel 

(ISOP) and is the final approver and adjudicating authority for DISR. The Technical 

Working Group (TWG) under the IT Standards Committee (ITSC) supports the CIO 

Executive Board by identifying new standards to include in the DISR and by retiring 

standards that are no longer deemed to be interoperable. All mandated standards are 

entered into the DODISS database. The DODISS database is the DOD reference for 

military specifications, standards and related publications. It can be accessed at 

http://dodssp.daps.dla.mil/dodiss.htm 

DOD Directive 5101.7 mandates that uniform IT standards be used throughout the 

Department of Defense in a manner that achieves and enhances interoperable and netcentric enabled IT and NSS. The DISR is governed by this policy. 

9 - 1
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

Appendix 10: 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; 

10 - 1
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

(3) Any item that would satisfy a criterion expressed in paragraphs (1) or (2) of this 

definition, but for: 

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

or 

(ii) Minor modifications of a type not customarily available in the commercial 

marketplace made to meet Federal Government requirements. Minor 

modifications mean modifications that do not significantly alter the 

nongovernmental function or essential physical characteristics of an item or 

component, or change the purpose of a process. Factors to be considered in 

determining whether a modification is minor include the value and size of the 

modification and the comparative value and size of the final product. Dollar 

values and percentages may be used as guideposts, but are not conclusive 

evidence that a modification is minor; 

(4) Any combination of items meeting the requirements of paragraphs (1), (2), (3), or (5) 

of this definition that are of a type customarily combined and sold in combination to the 

general public; 

(5) Installation services, maintenance services, repair services, training services, and 

other services if: 

(i) Such services are procured for support of an item referred to in paragraph (1), 

(2), (3), or (4) of this definition, regardless of whether such services are provided 

by the same source or at the same time as the item; and 

(ii) The source of such services provides similar services contemporaneously to 

the general public under terms and conditions similar to those offered to the 

Federal Government; 

(6) Services of a type offered and sold competitively in substantial quantities in the 

commercial marketplace based on established catalog or market prices for specific tasks 

performed or specific outcomes to be achieved and under standard commercial terms and 

conditions. This does not include services that are sold based on hourly rates without an 

established catalog or market price for a specific service performed or a specific outcome 

to be achieved. For purposes of these services— 

(i) “Catalog price” means a price included in a catalog, price list, schedule, or 

other form that is regularly maintained by the manufacturer or vendor, is either 

published or otherwise available for inspection by customers, and states prices at 

which sales are currently, or were last, made to a significant number of buyers 

constituting the general public; and 

(ii) “Market prices” means current prices that are established in the course of 

ordinary trade between buyers and sellers free to bargain and that can be 

substantiated through competition or from sources independent of the Offerors. 

(7) Any item, combination of items, or service referred to in paragraphs (1) through (6) of 

this definition, notwithstanding the fact that the item, combination of items, or service is 

transferred between or among separate divisions, subsidiaries, or affiliates of a 

contractor; or 

10 - 2
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

(8) A non-developmental item, if the procuring agency determines the item was 

developed exclusively at private expense and sold in substantial quantities, on a 

competitive basis, to multiple State and local governments. [FAR Part 2.101(b)] 

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

means an item that - 

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

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

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

sold in the commercial marketplace. [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. 

10 - 3
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

“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] 

“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 Project 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, 12th Edition] 

10 - 4
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

“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 

effectively together. (DoDD 5000.1) 

“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 

10 - 5
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

A” 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: 

purpose is to perform acquisition fictions closely associated with 

inherently governmental functions with regard to the development or 

production of a major system. 

“Life Cycle Model” in the context of the development, operation, and maintenance of a 

software product, a life cycle model is a defined set of processes, activities, and tasks, 

and their sequencing and interrelationships, spanning the life of the system from its 

definition to the termination of its use. [IEEE/EIA Std. 12207/1997] 

“Limited Rights” (LR) means, in part, the right to use, modify, reproduce, release, 

perform, display, or disclose IP and technical data, in whole or in part, within the 

Government. The Government may not, without permission, release or disclose the IP 

and technical data outside the Government, use the IP and technical data for manufacture, 

or permit the IP and technical data to be used by another party, except: 

• When necessary for emergency repair and overhaul; 

• When used for evaluation or informational purposes by foreign governments; 

• Subject to prohibitions on further reuse; 

• When the contractor asserting the restriction is notified of such use. 

[DFARS §252.227.7013(a)(13)] 

“Maintainability” is directed toward achieving the reliability inherent in a design 

through servicing and maintenance, and efficiently restoring the system to operation 

should failures occur. [Defense Acquisition University] 

“Markings” refers to software and other Intellectual Property Rights (IPRs) legends, 

distribution statements, security classifications, and appropriate export control 

statements. It is important that Program Managers review the markings of all 

deliverables prior to acceptance to ensure that the Government will obtain the IPRs it has 

contracted for. 

Method/Technique -- The approach used to accomplish the task. [IEEE/EIA Std. 

12207/1997] 

“Module” is a discrete, small-grained unit of functionality, either hardware or software, 

with a well-defined, open and published interface. Modules are combined with other 

modules to create components, services, and packages. 

“Modular 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 MOS

10 - 6
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

• Use Open Standards. 

 M oach (MOSA) to Acquisition, OSJTF] 

“Naval Open Architecture (NOA)” is the confluence of business and technical 

practices yielding modular, interoperable systems that adhere to open standards with 

pub innovation 

and competition, enables reuse of components, facilitates rapid technology insertion, and 

 a 

rnal 

 of 1954 (26 U.S.C. 501(c)) and exempt from taxation under section 501(a) 

f the Internal Revenue Code (26 U.S.C. 501(a)) or any nonprofit scientific or 

ts. 

Note: “Openness” can be thought of in degrees, based on the level and scope of 

 a 

ange of potential component providers).

“Open

standar

ortabil

ith a moderate license fee. [Defense Acquisition Guidebook] 

 interfaces. [A Modular 

pen Systems Approach (MOSA) to Acquisition, OSJTF] 

dely 

nness of its key interfaces. [A 

odular Open Systems Approach (MOSA) to Acquisition, OSJTF] 

• Establish an Enabling Environment. 

• Employ Modular Design. 

• Designate Key Interfaces. 

• Certify Conformance. 

[A odular Open Systems Appr

lished interfaces. This approach significantly increases opportunities for

reduces maintenance constraints. OA delivers increased warfighting capabilities in

shorter time at reduced cost. [RhumbLines, December 12, 2006, Naval Office of 

Information] 

“Nonprofit Organization” means a domestic university or other institution of higher

education or an organization of the type described in section 501(c)(3) of the Inte

Revenue Code

o

educational organization qualified under a state nonprofit organization statute. 

“Open Architecture” means a type of architecture whose specifications are made public 

by its designers which allows users to make modifications to various componen

[ITtoolbox]. 

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

broad r

 Standards” means widely accepted and supported standards set by recognized 

ds organizations or the marketplace. These standards support interoperability, 

p ity, and scalability and are equally available to the general public at no cost or 

w

“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

O

“Open System Architecture” is a system that employs modular design, uses wi

supported and consensus based standards for its key interfaces, and has been subjected to 

successful validation and verification tests to ensure the ope

M

10 - 7
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

ces using widely 

pported, consensus-based standards that are published and maintained by a recognized 

d, open 

echnical approaches proposed by or being used by vendors. 

eviewers are normally drawn from a cross section of the community of interest with 

he 

goals 

r a weapon system through long-term support arrangements with clear lines of authority 

n 

in which it was created without requiring major 

work. (Techtarget.com) 

ct, 

rocess or method, or to operate in the case of a machine or 

stem; and, in each case, under such conditions as to establish that the invention is being 

oal. 

ctivities. For example Development is a process. Within Development there are thirteen 

e 

Failures (MTBF) and low Mean 

ime To Repair (MTTR)] and operating life. (Defense Acquisition University) 

“Open Systems Approach” means an integrated business and technical strategy that 

employs a modular design and, where appropriate, defines key interfa

su

industry standards organization. [A Modular Open Systems Approach (MOSA) to 

Acquisition, OSJTF] 

 “Peer Review” (as used in connection with Naval Open Architecture) is a referee

process used to assess t

R

government, academia, or private sector entities such that the membership is unbiased 

and impartial. An “independent peer review” is one where the membership includes

individuals from outside of 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 their concerns. This assessment process 

normally results in findings or recommendations presented to the decision maker with t

authority and responsibility to select or make the final course of action or decision. 

“Performance-based Logistics” is the purchase of support as an integrated, affordable, 

performance package designed to optimize system readiness and meet performance 

fo

and responsibility. Application of Performance Based Logistics may be at the system, 

subsystem, or major assembly level depending on program unique circumstances and 

appropriate business case analysis. 

“Portability” is a characteristic attributed to a computer program if it can be used in a

operating system other than the one 

re

“Practical application” means to manufacture in the case of a composition or produ

to practice in the case of a p

sy

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 g

IEEE/EIA Std. 12207/1997 Table 1 lists all 12207 processes and their associated 

a

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 possibl

continued operation [i.e., high Mean Time Between 

T

10 - 8
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

 be 

Restricted Rights” (RR) applies only to noncommercial software and means, in part, 

• To transfer the program to another computer subject to restrictions; 

es; 

ntractors performing services in support of this 

iencies or 

osure 

ther restrictions. 

t to 

[DFARS 2

“Scalabilit

meet future

mall business concern as defined at section 2 of 

 the 

ctures 

s engineering principles. The 

“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

used in more than one computing program or software system [IEEE]

“

the Government’s rights to use the computer program: 

• With one computer at a time; 

• To make minimum copies for safekeeping, modification or backup; 

• To modify the software for the above purpos

• To permit contractors or subco

or a related contract to use the software to diagnose and correct defic

to respond to urgent tactical situations, subject to subject to non-discl

and restrictions against reverse engineering and o

• 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, subjec

non-disclosure and restrictions against reverse engineering. 

 § 52.227-7014(a)(14)] 

y” is the capability of a piece of hardware or software to easily expand to 

 computing needs. [Microsoft TechNet] 

“Small business firms” means a s

Pub. L. 85-536 (15 U.S.C. 632) and implementing regulations of the Administrator of

Small Business Administration. [FAR Section 52.227-12]

“Software Architecture” of a program or computing system is the structure or stru

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, 

12th Edition] The DoD 5000.1 Acquisition Guidebook states that the “program manager 

should base software systems development on robust system

following best practices 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. 

10 - 9
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

2. Software Development Plan (SDP) - A management plan usually generated by 

. Computer Software Documentation - 

the developer outlining the software development effort. 

3 Technical Data (TD) information, 

bilities and limitations 

of the software, or provides operation instructions for using or supporting 

4.

including computer listings and printouts, that documents the requirements, 

design, or details of computer software, explains the capa

computer software during the software's operational life. 

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 type of Item Performance

Specification that documents the essential requirements (functions, performance,

design constraints and attributes) of a given Software Item (SI). Typically 

accompanied by the Interface Requirements Specification (IRS) for that SI. 

I) in 

6.

Analogous to the Item Performance Specification of a Configuration Item (C

the allocated baseline of a hardware system. 

Software Specification Review (SSR) - A life cycle review of the requirem

specified for one or more Software Configuration Items (SCIs) to determine 

whether they form an adequate basis for proc

ents 

eeding into preliminary design of the 

reviewed item. See Software Requirement Specification (SRS) and Interface 

7.

Requirement Specification (IRS). 

Interface Requirement Specification (IRS) - A type of Item Performance 

Specification that defines the required software interfaces for a given Softwar

Item (SI) in the allocated baseline, 

e 

the requirements for which are described by a 

Software Requirements Specification (SRS). The IRS is frequently combined with 

8.

the SRS. 

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 o

database, that satisfies an end use function and is designated for purposes

specification, qualification, testing, interfacing, Configuration Man

r 

 of 

agement (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 t

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 co

he 

ntracts 

and sub-contracts (regardless of contract type) associated with high-cost software 

10 - 10
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

11.

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. 

Analysis of Alternatives - The evaluation of the performance, operational 

effectiveness, operational suitability, and estimated costs of alternativ

meet a mission

e systems to 

 capability. The analysis assesses the advantages and disadvantages 

of alternatives being considered to satisfy capabilities, including the sensitivity of 

oA is 

12.

each alternative to possible changes in key assumptions or variables. The A

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. 

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, 

r 

13.

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) o

Capability Development Documents. 

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 framew

within which to generate detailed T&E plans and it documents schedule and 

ork 

resource implications associated with the T&E program. The TEMP identifies the 

nd 

d 

Is, 

15.

necessary Developmental Test and Evaluation (DT&E), Operational Test a

Evaluation (OT&E), and Live Fire Test and Evaluation (LFT&E) activities. It 

relates program schedule, test management strategy and structure, and require

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 CO

can be addressed in a component-prepared annex to the basic TEMP. 

Capability Development Document - A document that captures the informa

necessary to develop a proposed program(s), preferably using an evolutionary 

acquisition strategy. The CDD outlines an affordable increment of mil

tion 

itarily 

10 - 11
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

16.

useful, logistically supportable, and technically mature capability. The CDD 

supports a Milestone B decision review. 

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 

ram 

ng of 

17.

APB was developed. The APB constitutes an agreement between the prog

manager, OPNAV sponsor, and milestone decision authority, and the breachi

any one parameter threshold will necessitate a re-baselining with a new APB 

agreed to by those three parties. 

Training Plan – Outlines the level of learning required to adequately perform

responsibilities designated to the

 the 

 function and accomplish the mission assigned to 

the system. 

[Do

“Spiral Development” is a process characterized by repeating a set of activities and 

eration. Think of product development (such as 

ourse development) with several iterations of formative evaluation and repeated 

s defined in the Bob Stump Defense Appropriations Bill of 

“(1) The term “spiral development program”, with respect to a research and 

 phases or blocks, each of which will result in the 

ecific performance parameters, 

di

“System h

their life cycle processes. [IEEE 1220-1998]

k under this contract; provided, that in the 

ase of a variety of plant, the date of determination (as defined in section 41(d) of the 

ask 

ue or method. [IEEE/EIA Std. 

2207/1997] 

D 5000.1 Acquisition Guidebook] 

making improvements between each it

c

revisions and improvements. 

[High Performance Center, Training Technology Information Center] 

Spiral Development i

2002, Section 803 as follows: 

development program, means a program that – 

(A) is conducted in discrete

development of fieldable prototypes; and 

(B) will not proceed into acquisition until sp

inclu ng measurable exit criteria, have been met. 

 (2) The term “spiral” means one of the discrete phases or blocks of a spiral 

development program.” 

 Arc itecture” is the composite of the design architectures for products and 

“Subject Invention” means any invention of the Contractor conceived or first actually

reduced to practice in the performance of wor

c

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 t

is performed, such as testing, is called the techniq

1

10 - 12
Distribution Statement A – Approved for Public Release; NOA Contract Guidebook v1.1 

Distribution is unlimited. October 25, 2007 

 

ilities 

e and more capable COTS or custom technologies. [Software Engineering 

stitute] 

Unlimited rights” (UL) means rights to use, modify, reproduce, perform, display, 

lossary of Defense Acquisition Acronyms and Terms, 12 Edition] 

“Technology Insertion” is increasing a system’s or product’s Warfighting operational 

capability by integrating new capabilities or upgrading the system’s current capab

with up-to-dat

In

“Upgradability” is the ease with which a system or component can be modified to take 

advantage of new software or hardware technologies. [Software Engineering Institute] 

“

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

th G

10 - 13
Appendix 11: FEEDBACK FORM

Organization:

Name:

Phone Number: Email:

Page/Paragraph

Issue:

Recommended

Change:

This form may be submitted electronically if accessed at https://acc.dau.mil/oa. If submitting

manually, please mail to PEO-IWS 7.0, attention PEO-IWS 7B1, or fax to (202) 781-4754.

Program Manager, Future Combat Systems Open Architecture (PEO-IWS 7.0 )

1333 Isaac Hull Avenue SE

Washington Navy Yard

Washington, DC 20376-2301

Section/Subsectio
For additional information on the Naval 

Open Architecture Contract Guidebook 

or the Naval Open Architecture (NOA) 

effort, please visit: 

https://acc.dau.mil/oa