(Pre-Solic) 20161128 - Draft Solicitation.pdf

N65236-16-R-0001

Section B - Supplies or Services and Prices

ITEM

NO

SUPPLIES/SERVICES

EST

QUANTITY

UNIT

UNIT PRICE TOTAL AMOUNT

0001 1 Each

Advanced Analytics Technical Solution -

Delivery of Advanced Analytics Technical Solution (AATS) Software in accordance with the Performance Work Statement

FFP

0002 1 Each

Delivery of AATS Software Documentation/Technical Data Package in accordance with Performance Work Statement

0003 1 Each

Delivery of AATS Systems Approach Training (SAT) Materials in accordance with Performance Work Statement

CPFF

Original Equipment Manufacturer (OEM)/Subject Matter Expert

(SME) Support Services for AATS Integration, Configuration, System

Administration, Test, and IA in accordance with the Performance

Work Statement

Note – RFP pricing model (RFP Attachments 4A and 4B) allows the offeror propose different labor rates/cost estimates by contract year

Total CLIN 0004 Cost Estimate

ESTIMATED COST

FIXED FEE

TOTAL ESTIMATED COST

PLUS FIXED FEE

0005 1 Each

Advanced Analytics Technical Solution

Contract Year 2 - AATS Annual Software Sustainment, including Annual

License Renewals, Software Updates, and Security Updates in accordance with the Performance Work Statement

0006 1 Each

Contract Year 3 - AATS Annual Software Sustainment, including Annual

CPFF

Contract Year 3 - AATS Pre-Planned Product Improvements –

Increment #1 in accordance with the Performance Work Statement

0008 1 Each

Contract Year 4 - AATS Annual Software Sustainment, including Annual

0009 1 Each

Contract Year 5 - AATS Annual Software Sustainment, including Annual

CPFF

AATS Pre-Planned Product Improvements – Increment #2 in accordance with the Performance Work Statement

0011 1 Each

CDRLs

Contract Data Requirements List (CDRLs) in accordance with

Performance Work Statement

CLAUSES INCORPORATED BY FULL TEXT

5252.216-9205 FEE DETERMINATION AND PAYMENT (INDEFINITE DELIVERY TYPE

CONTRACTS) (APR 2000) (VARIATION)

(a) Types of Delivery or Task Orders.

Both level-of-effort and completion type orders may be issued under this contract. The Request for Quotation issued for each delivery or task order will set forth the type of order deemed appropriate by the Government. If the

Contractor disagrees with the Government’s assessment, the Ordering Officer and the contractor shall attempt to resolve the matter through the negotiation process. Failing this, the matter will be referred to the Contracting

Officer. If necessary, a final decision shall be made in accordance with the FAR 52.233-1 “Disputes” clause. The

Contracting Officer’s determination will govern the type of order, pending an appeal pursuant to the “Disputes” clause. The contractor will use his best efforts to work on the order until the dispute is resolved.

(b) Fixed Fee Pool.

The fixed fee pool consists of the total fixed fee of the contract AND includes the total fee to be paid to the prime contractor and all subcontractors. SUBCONTRACTOR FEE WILL NOT BE BILLED AS A SEPARATE DIRECT

COST ON THE VOUCHER SUBMITTED BY THE CONTRACTOR TO THE GOVERNMENT, BUT WILL BE

PAID TO THE SUBCONTRACTOR BY THE PRIME CONTRACTOR FROM THE FEE BILLED FROM THE

FIXED FEE POOL.

(c) Computation of Fee.

The percentage of the fee applicable to orders will be the same as the percentage of the fee established in the contract. However the total fee paid under the contract for a year of performance will not exceed the total fixed fee amount for the current year of performance.

(d) Fee on Modifications to Term Type (Level-of-Effort) Delivery or Task Orders.

If the hours for a particular delivery or task order are insufficient to complete performance under the order, the government may elect to increase the hours by written modification. This increase in cost associated with the increase in hours will be fee bearing at the same percentage of fee established in the basic contract. If the hours prove to be in excess of that necessary to complete performance under this order, the government shall decrease the hours by written modification. The fee associated with the decrease in hours will be reduced by the percentage of fee established in the basic contract. Estimated cost will be increased/decreased as applicable.

(e) Fee on Modifications to Completion Type Delivery or Task Orders.

If the task(s) required under a particular delivery or task order cannot be completed within the negotiated estimated cost (an overrun situation), the government may elect to increase the estimated cost to complete the effort with no additional fee allocation.

If the task(s) required under the order is completed and the cost is less than that negotiated (underrun), the contractor shall be entitled to full payment of the fixed fee specified in the order. Excess costs shall be deobligated by modification to the delivery order prior to contract closeout.

(f) Modifications to the Basic Contract.

If the contracting officer determines, for any reason, to adjust the contract amount or the estimated total hours, such adjustments shall be made by contract modification. Any increase will be fee bearing, except cost overruns on completion type orders, at the percentage of fee established in the basic contract.

The estimated cost of the contract may be increased by written modification, if required, due to cost overruns. This increase in cost is not fee bearing and no additional hours will be added to the total estimated hours under the contract.

(g) Payment of Fee.

The Government shall pay fixed fee to the contractor on each delivery order at the percentage rate of fee established in the basic contract subject to the contract’s “Fixed Fee” clause, provided that the total of all such payments shall not exceed eighty-five percent (85%) of the fixed fee specified under each applicable delivery order, unless waived.

In accordance with the provisions of paragraphs (d) and (e) of this clause, any balance of fixed fee shall be paid to the contractor, or any overpayment of fixed fee shall be repaid by the contractor, at the time of final payment.

(h) Closeout.

Delivery or task orders will be closed out on an individual basis, upon agreement of final indirect rates for the period of performance of the applicable delivery or task order. The contractor shall forward the final voucher directly to the cognizant DCAA for final audit. DCAA will forward the voucher and the final audit to the cognizant ACO (see block 6 of the basic contract), who will process it for final payment and submit it to the paying office.

(End of clause)

5252.216-9218 MINIMUM AND MAXIMUM QUANTITIES (JUL 1989)

As referred to in paragraph (b) of the “Indefinite Quantity” clause of this contract, the contract minimum quantity is a total of $25,000 worth of orders at the contract unit price(s). The maximum quantity is the total estimated amount of the contract. The maximum quantity is not to be exceeded without prior approval of the Procuring Contracting

Officer.

5252.232-9210 LIMITATION OF LIABILITY--INCREMENTAL FUNDING (JAN 1992)

This task order is incrementally funded and the amount currently available for payment hereunder is limited to $ * inclusive of fee. It is estimated that these funds will cover the cost of performance through * . Subject to the provisions of the FAR 52.232-22 “Limitation of Funds” clause of this contract, no legal liability on the part of the

Government for payment in excess of $ * shall arise unless additional funds are made available and are incorporated as modifications to this contract.

* As indicated in individual task orders.

Section C - Descriptions and Specifications

SECTION C – DESCRIPTION/SPECS/WORK STATEMENT

SPECIFICATIONS/STATEMENT OF WORK/PERFORMANCE WORK STATEMENT

Work under this performance-based contract shall be performed in accordance with the following description/ specifications/ statement of work (SOW) which herein shall be referred to as Performance Work Statement (PWS):

1.0 PURPOSE

1.1 BACKGROUND

The Space and Naval Warfare Systems Center (SPAWARSYSCEN) Atlantic, Expeditionary Intelligence Solutions

(EIS) Portfolio, Distributed Common Ground Surface/System (DCGS) Marine Corps Integrated Product Team, Intelligence Analysis System (IAS) program supports the United States Marine Corps (USMC) all-source intelligence analyst (Military Occupational Specialty (MOS) 0231) in the processing, exploitation, analysis, interpretation, and presentation of all-source intelligence data. The IAS Family of Systems (IAS FoS) provides support to multiple echelons, from the Marine Expeditionary Force (MEF) to the Company level, through the employment of intelligence servers and workstations. The intelligence servers are comprised of the Intelligence

Server-Windows (IS-W) and the Intelligence Server-Unix (IS-U). The IS-W is a physical server with VMWare

ESXi hypervisor installed, and hosts multiple virtual machines that provide collaboration, track management, and common operational picture (COP) services for the intelligence analyst. The IS-U is a Solaris server that provides access to Global Command and Control System – Joint (GCCS-J) and GCCS- Integrated Intelligence and Imagery

(GCCS-I3) services. Both the IS-W and the IS-U are deployed at all levels of the Marine Air Ground Task Force

(MAGTF) down to the regimental echelon and Marine Expeditionary Units (MEU). Intelligence Workstations (IW) are present at all echelons of the MAGTF down to the Company level, can utilize services on the IS-W and the IS-U

(Modernized Integrated Database (MIDB), COP, chat, etc.), and can also operate in standalone mode.

Advancements in the technology fields of knowledge management and data science present opportunities to introduce efficiencies in the intelligence cycle (Marine Corps Doctrinal Publication (MCDP 2-1) through utilization of ontologies to structure data from disparate sources as well as integration of predictive analytics, natural language processing, and related technologies; and the use of emerging and non-traditional database technologies and architectures to support the efficient search and retrieval of information. Therefore, the IAS program has initiated an

Advanced Analytics Technical Solution (AATS) project to identify and acquire an enterprise-capable software solution that supports the activities and intent of each phase of the intelligence cycle, reduces manual effort through application of advanced analytics technologies, and functions in both connected and disconnected modes of operation. “Enterprise-capable” software solution means the software must provide capability that scales to the available computing resources at each echelon. “Connected and disconnected modes of operation” primarily refers to the ability of the IW to communicate with the IS-W over the network. It can also refer to the connectivity of the

IW and the IS-W to the Marine Corps Enterprise Network (MCEN).

1.2 SCOPE

The scope of this PWS includes the procurement of a commercial item (CI) or non-developmental item (NDI) advanced analytics software product to assist with the processing, exploitation, analysis, interpretation, and presentation of all-source intelligence data (see Federal Acquisition Regulation 2.101 for the definition of commercial item and non-developmental item); and will include a robust, open application programming interface

(API) that provides extensive support for integration of Government-developed and commercially-developed application plugins and integration between AATS data storage and external data sources. The software will minimize total ownership costs, and will accommodate the characteristics of the user population that will operate, maintain, and support the software without support from Field Service Representatives (FSRs) and the key missions, operations, and decisions that the software must support.

The scope also includes the services required to support SPAWARSYSCEN Atlantic personnel in the engineering, integration, information assurance, testing, and training activities required for the program to deploy the software to the MEF within the IAS architecture; and to ensure that SPAWARSYSCEN Atlantic personnel can maintain the software on the IAS baseline without additional vendor support. The Program Sponsor is the Marine Corps Systems

Command (MARCORSYSCOM).

NOTE: Work will not be performed in Afghanistan.

2.0 APPLICABLE DOCUMENTS (AND DEFINITIONS)

2.1 REQUIRED DOCUMENTS

The following instructional documents are mandatory for use. Unless otherwise specified, the document’s effective date of issue is the date on the request for proposal. Additional applicable documents may be included in specific task orders.

Document Number Title

a. DoD 5200.2-R DoD Regulation – Personnel Security Program, dtd Jan 87

b. DoDM 5200.01 DoD Manual – Information Security Program Manual, dtd

24 Feb 12 c.

DoDD 5205.02E DoD Directive – Operations Security (OPSEC) Program, dtd 20 Jun 12

d. DoD 5205.02-M DoD Manual – Operations Security (OPSEC) Program

Manual, dtd 3 Nov 08

e. DoD 5220.22-M DoD Manual – National Industrial Security Program

Operating Manual (NISPOM), dtd 28 Feb 06

f. DoDI 5220.22 DoD Instruction – National Industrial Security Program, dtd

18 Mar 11

g. DoDI 6205.4 Department of Defense Instruction, Immunization of Other

Than U.S. Forces (OTUSF) for Biological Warfare

Defense, dtd 14 Apr 00

h. DoDI 8500.01 DoD Instruction – Cybersecurity, dtd 14 Mar 14

i. DoDI 8510.01

DoD Instruction – Risk Management Framework (RMF) for DoD Information Technology (IT), dtd 12 Mar 14

j. DoD 8570.01-M

Information Assurance Workforce Improvement Program, dtd 19 Dec 05 with Change 3, dtd 24 Jan 12

k. DoDD 8570.01 DoD Directive – Information Assurance Training, Certification, and Workforce Management, dtd 15 Aug 04

l. SECNAV M-5239.2 DON Information Assurance Workforce Management

Manual, dtd May 2009

m. SECNAV M-5510.30 Secretary of the Navy Manual – DoN Personnel Security

Program, dtd Jun 2006

n. SECNAVINST 5239.3B DoN Information Assurance Policy, dtd 17 Jun 09

o. SECNAVINST 5510.30B DoN Regulation – Personnel Security Program, dtd

6 Oct 06

p. SPAWARINST 3432.1 SPAWAR Instruction – Operations Security (OPSEC)

Policy, dtd 2 Feb 05

q. SPAWARINST 5721.1B SPAWAR Section 508 Implementation Policy, dtd 17 Nov

r. SPAWARSYSCENLANTINS

T 12910.1A

Space and Naval Warfare Systems Center Atlantic

Instruction – Deployment of Personnel and Contractor

Employees to Specific Mission Destinations, dtd 28 Dec 09

2.2 GUIDANCE DOCUMENTS

The following documents are to be used as guidance. Unless otherwise specified, the document’s effective date of issue is the date on the request for proposal. Additional applicable documents may be included in specific task orders.

Document Number Title

a. MIL-STD-1916 DoD Test Method Standard – DoD Preferred Methods for

Acceptance Of Product, dtd 01 Apr 96

b. DoDI 3020.41 DoD Instruction – Operational Contract Support (OCS), dtd

20 Dec 10

c. DoDD 5000.01 DoD Directive – The Defense Acquisition System, dtd 20

Nov 07

d. DoDI 5000.02 DoD Instruction – Operation of the Defense Acquisition

System, dtd 07 Jan 15

e. ISO/IEC 12207 International Organization for Standardization/

International Electrotechnical Commission: Systems and

Software Engineering – Software Life Cycle Processes

f. ISO/IEC 15288 International Organization for Standardization/

International Electrotechnical Commission: Systems and

Software Engineering – System Life Cycle Processes

g. HSPD-12 Homeland Security Presidential Directive – Policy for a

Common Identification Standard for Federal Employees and Contractors, dtd 27 Aug 04

h. DoDM-1000.13-M-V1 DoD Manual – DoD Identification Cards: ID card Life-

Cycle, dtd 23 Jan 14

i. FIPS PUB 201-2 Federal Information Processing Standards Publication 201-

2 – Personal Identity Verification (PIV) of Federal

Employees and Contractors, dtd Aug 2013

j. Form I-9, OMB No. 115-0136 US Department of Justice, Immigration and Naturalization

Services, Form I-9, OMB No. 115-0136 – Employment

Eligibility Verification

i. N/A SPAWARSYSCEN Atlantic Contractor Check-in portal – https://wiki.spawar.navy.mil/confluence/display/SSCACO

G/Contractor+Checkin

j. N/A SPAWARSYSCEN Atlantic OCONUS Travel Guide portal https://wiki.spawar.navy.mil/confluence/display/SSCACO

G/OCONUS+Travel+Guide

k. NAVMC 1553.1 Systems Approach to Training User’s Guide, dtd 27 Oct 10

l. [N/A] Marine Corps Systems Approach to Training Manual

m. [N/A] Defense Information Systems Agency (DISA) Security

Requirements Guide (SRG)

n. [N/A] DISA Security Technical Implementation Guides (STIGs)

o. [N/A] OWL Web Ontology Language Document Overview

p. [N/A[ OWL 2 Web Ontology Language XML Serialization

(Second Edition) – W3C Recommendation, dtd 11 Dec 12

q. IEEE Std 12207-2008 Systems and Software Engineering – Software Life Cycle

Processes https://wiki.spawar.navy.mil/confluence/display/SSCACOG/Contractor+Checkin https://wiki.spawar.navy.mil/confluence/display/SSCACOG/Contractor+Checkin https://wiki.spawar.navy.mil/confluence/display/SSCACOG/OCONUS+Travel+Guide https://wiki.spawar.navy.mil/confluence/display/SSCACOG/OCONUS+Travel+Guide

2.3 SOURCE OF DOCUMENTS

The contractor shall obtain all applicable documents. Many documents are available from online sources.

Specifications and commercial/industrial documents may be obtained from the following sources:

Copies of Federal Specifications may be obtained from General Services Administration Offices in Washington, DC, Seattle, San Francisco, Denver, Kansas City, MO., Chicago, Atlanta, New York, Boston, Dallas and Los Angeles.

Copies of military specifications may be obtained from the Commanding Officer, Naval Supply Depot, 3801 Tabor

Avenue, Philadelphia, PA 19120-5099. Application for copies of other Military Documents should be addressed to

Commanding Officer, Naval Publications and Forms Center, 5801 Tabor Ave., Philadelphia, PA 19120-5099.

All other commercial and industrial documents can be obtained through the respective organization’s website.

3.0 PERFORMANCE REQUIREMENTS

The following paragraphs list all products and services that shall be required throughout the contract life. The contractor shall provide necessary resources and knowledge to support the listed supply and services requirements.

Specific objectives will be dependent on the basic contract and the delivery/task order (TO) written against the basic contract. The contractor shall complete all required deliveries/tasks while controlling and tracking performance and goals in terms of costs, schedules, and resources.

Note: In compliance with SPAWARINST 4720.1A – SPAWAR Modernization and Installation Policy, all contract installation work performed aboard Navy ships and Navy shore sites is under Installation Management Office (IMO) supervision; otherwise, a formal exemption request has been approved. In accordance with the Fleet Readiness

Directorate Standard Operating Procedure (FRD SOP), COMSPAWARSYSCOM letter Ser FRD/235 dated 24 Apr

12, the contractor shall ensure proper notification and status updates of installation work performed outside of

SPAWARSYSCEN Atlantic respective Areas of Responsibilities (AORs) are provided to the SPAWAR Officer in

Charge (OIC) or applicable Geographic Lead.

3.1 Open Systems Approach

The Government intends to procure commercial item or non-developmental item (NDI) software having an Open

System Architecture and corresponding components. As part of this contract, the contractor shall define, document, and follow an open systems approach for using modular design, standards-based interfaces, and widely-supported consensus-based standards. The contractor shall develop, maintain, and use an Open System Management Plan

(CDRL A002) to support this approach and shall demonstrate compliance with that plan during all design reviews.

In addition, the contractor shall provide the Government (and/or Government support contractors) electronic access to its integrated digital (or development) environment (IDE) and the ability to download artifacts throughout the term of the contract. The Government reserves the right to witness all Contractor efforts to accomplish the PWS requirements and maintains the right to comment on processes.

The contractor shall provide the Government (and/or Government support contractors) real-time access to the contractor’s (and any associated sub-contractor’s) software development environment, providing the Government with continuous online access to and the ability to download work products under development commencing at the time of delivery order award.

In satisfying the Government’s requirements, the following system architecture approach characteristics shall be utilized:

3.1.1 Open Architecture

The contractor shall develop and maintain an architecture that incorporates appropriate considerations for re-configurability, portability, maintainability, technology insertion, vendor independence, reusability, scalability, interoperability, upgradeability, and long-term supportability.

Ensure that external information exchange requirements are implemented in a standard and open manner as part of this effort. These actions shall include planning that identifies the contractor’s specific approach to ensuring software and interface data is well-defined, available to all programs, and uses a standards-based tool for definition within the context of DoD and Service upgrade programs.

The contractor shall develop software upgrades, software capabilities, and business rules that ensure that:

Data will be posted to shared spaces for users to access and download except when limited by security, policy, or regulations;

Data shall provide for interoperability with many-to-many exchanges of data, and verified trust and integrity of users and applications; and

Data shall be transmitted through well and openly defined interfaces.

The contractor shall ensure that its projects, at the architectural and operational level, continue to promote the use of an open architecture as well as adoption of other standards and requirements, tailored to meet its specific Service and Joint requirements.

3.1.2 Modular, Open Design

The contractor shall provide an architecture that is layered and modular and uses standards-based COTS/NDI software, operating systems, and middleware that all utilize either non-proprietary or non-vendor-unique key module or component interfaces where available. The contractor’s design approach shall be consistent throughout all subsystems and components.

Module Coupling – The contractor’s design approach shall result in modules that have minimal dependencies on other modules (loose coupling), as evidenced by simple, well- defined interfaces and by the absence of implicit data sharing. The purpose is to ensure that any changes to one module will not necessitate extensive changes to other modules, and hence facilitate module replacement and system enhancement.

Module Cohesion – The contractor’s design shall result in modules that are characterized by the singular assignment of identifiable and discrete functionality (high cohesion). The purpose is to ensure that any changes to system behavioral requirements can be accomplished by changing a minimum number of modules within the system.

System Requirements Accountability – The contractor shall ensure that all software requirements in this PWS 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.

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 the technical data describing the interface shall be available to the Government with at least Government Purpose Rights. The software architecture shall minimize inter-component dependencies to allow components to be decoupled and reused, where appropriate, across various DoD or Service programs and platforms.

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

The contractor’s rationale shall explicitly address any tradeoffs performed, particularly those that compromise the modular and open nature of the system.

3.1.4 Design Information Documentation

The contractor shall document and model the system or component (e.g., software, hardware, middleware) design information using industry standard formats (e.g., Unified Modeling Language). It shall also document and model how it will use tools that are capable of exporting model information in a standard format (e.g., Extensible Markup

Language Metadata Interchange (XMI) and AP233/ISO 10303). The contractor shall identify the proposed standards and formats to be used. The contractor shall maintain the design information, including any models used, so that the design information and models are current with the as-built system.

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

3.1.6 Life Cycle Sustainability

The contractor shall consider use of COTS/NDI and open standards to enhance the system’s life cycle sustainability by implementing performance-based logistics (PBL) arrangements to sustain the components through their life cycle.

3.1.7 Interface Design and Management

The contractor shall:

Clearly define and describe all component and system interfaces;

Define and document all subsystem and configuration item (CI) level interfaces to provide full functional, logical, and physical specifications;

Identify processes for specifying the lowest level (i.e., subsystem or component) at and below which it intends to control and define interfaces by proprietary or vendor-unique standards and the impact of that upon its proposed logistics approach. Interfaces described shall include, but not be limited to, mechanical, electrical (power and signal wiring), software, firmware, and hardware interfaces;

Identify the interface and data exchange standards between the component, module or system and the interconnectivity or underlying information exchange medium;

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;

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 and facilitate the insertion of alternative or reusable modular system elements.

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

3.1.9 As Built Configuration List Identification of Modification Items and Funding Source

The contractor shall prepare and deliver a comprehensive list of items (to include parts, components, sub-assemblies, assemblies, SRUs and LRUs) that during or in connection with the performance of the contract are new or have been redesigned, modified, or otherwise changed. Such list shall be specific as to description, nomenclature, part number, higher order subassembly or assembly, and the nature of the redesign, modification or other change.

(DI-CMAN-81516/T, As Built Configuration (ABCL) – Modified Item and Funding Source, A001; DID: DI-

CMAN-81516). In addition, and as specific and discrete task requirements of this contract, the contractor shall further identify in the ABCL, with respect to each such listed new, redesigned, modified, or changed item, the purpose of the redesign, modification or other change and the source of both the requirement and the funding for such redesign, modification, or other change. In identifying the funding source, the contractor shall, in the case of each redesign, modification, or other change funded in whole or in part with Government funding, specifically identify the contract, line item, and ACRN which funded or partially funded the redesign, modification, or other change.

3.1.10 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 (OSS), and other reusable NDIs 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: reliability consistent with the environment described in this PWS; maintainability; subsystem performance trade-offs; open system architecture break out compatibility;

cost; manufacturer’s quality assurance provisions; market acceptability; obsolescence; adequacy of available technical and intellectual property data and re-procurement data rights on the product; and merits of the software supported by the product. Decisions leading to the selection of specific COTS, NDI, proprietary or OSS products should be supported by appropriate analysis (e.g., with test results, architectural suitability, “best value” assessments, etc.).

3.1.11 Reuse of Pre-existing or Common Items

The contractor shall reuse pre-existing or common items unless a determination is made to not reuse. Exceptions to reuse of pre-existing items must be accompanied by justification, such as cost (both of adoption and life cycle support), schedule, functional and non-functional performance, etc. The general objective of these efforts shall be the development of a common system and/or common elements or components which meet the performance requirements of the various DoD or Service platform missions, where commonality offers the greatest technical and cost benefits.

3.1.12 Third-Party Development

The contractor shall address how it will provide the Government with 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.

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

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

Standards developed by international or national industry standards bodies that have been widely adopted by industry. Examples of widely adopted standards are:

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)

HTML for presentation layer (e.g., XML 1.0 www.webstandards.org)

XML for data transfer

Web services for remote system calls

Standards adopted by industry consensus-based standard bodies and widely adopted in the market place.

De facto standards (those widely adopted and supported in the market place).

Note: Standards that are not specified within this contract or that are modified must be submitted to and approved by the Government Program Manager prior to use.

3.2. SOFTWARE PERFORMANCE SPECIFICATION

3.2.1 Technical Maturity

The AATS software shall support the capabilities defined in this specification and its attachments, either out of the box or with configuration changes, with no changes to the core software product.

http://www.webstandards.org/

The components and modules of the proposed AATS software shall have been previously integrated and deployed together in a similar production environment as defined in this specification.

3.2.2 Software Compatibility

Background

The Government will install and integrate all AATS software components into the IAS system baseline. The

Government does not intend to introduce additional hardware into the IAS system baseline to support the system requirements of the AATS software. Therefore, the AATS software must function within the hardware and software constraints of the IAS system baseline.

Requirements

3.2.2.1 Vendor-specified system requirements for AATS software components installed on the IW shall not exceed the IW hardware and software specification (Solicitation Attachment 6).

3.2.2.2 Vendor-specified system requirements for AATS software components installed on the IS-W shall not exceed the IS-W hardware and software specification (Solicitation Attachment 6).

3.2.2.3 AATS software components installed on the IS-W shall be capable of operating in Virtual Machines

(VMs) managed by VMWare ESXi hypervisor software.

3.2.2.4 AATS software components installed on the IS-W shall be compatible with Microsoft Server 2012

Operating System or Red Hat Linux 6.

3.2.2.5 AATS software components installed on the IW shall be compatible with Microsoft Windows 10

Operating System.

3.2.2.6 AATS software components that require the use of a web browser shall be fully compatible with the web browser software versions listed in the IS-W and IW software specification (Solicitation Attachment 6).

Updates to the AATS software components shall be provided to maintain compatibility with updates to the web browser software on the IS-W and IW software baselines.

3.2.3 Information Assurance

The AATS software package shall be compliant with all applicable Defense Information Systems Agency (DISA) information assurance requirements as provided in DISA Security Requirement Guides (SRGs) and Security

Technical Implementation Guides (STIGs).

3.2.4 Supportability

3.2.4.1 Once fielded as part of the IAS software baseline to the end users, the AATS software package and all functionality provided by the AATS software package shall be capable of being maintained without on-site contractor support.

3.2.4.2 The contractor shall provide any and all AATS software package version upgrades as they are released and no less than semiannually.

3.2.4.3 Upon notification of a security vulnerability in the AATS software package or its dependencies, the contractor shall provide a fix or mitigation strategy according to the following timetable:

Severity Timeline for Response

Category I 72 hours

Category II 5 days

Category III 10 days

3.2.4.4 All AATS software package version upgrades shall support non-destructive updates of the IAS software baseline. Software requirements that support non-destructive updates include, but are not limited to:

All software package version upgrades shall support silent installation (installation with no user interaction required).

All software package version upgrades shall support scripted installation, where all installation parameters are accessible at the command line.

3.2.5 Functional Requirements

3.2.5.1 Database and Ontology

In order to promote data consistency and interoperability between organizationally and/or geographically disparate

USMC intelligence teams, and to provide a framework for the development of advanced analytical capabilities, the

AATS software will conform all processed data to a Government-provided AATS ontology. “Processed data” means structured, semi-structured, and unstructured data from external sources that has been mapped to objects, relationships, and properties defined by the ontology. The standard form of the Government-provided ontology will be the XML/RDF serialization defined by the W3C OWL 2 Web Ontology Language XML Serialization (Second

Edition).

The following definitions will be used for the AATS software requirements:

An Object Type is an abstract concept; for example, “Person”, “Equipment”, “Event”, and “Facility”.

An Object is an instance of an Object Type. Using the “Person” Object Type example, the user may create Objects from the “Person” Object Type that represent specific people (e.g. “John Doe”).

A Relationship Type is an abstract relation where the domain and range are Object Types. For example:

Relationship Type ID: “is-located-at”

Domain: “Person”, “Equipment”

Range: “Facility”

A Relationship is an instance of a Relationship Type (in the same way that an Object is an instance of an Object

Type). Continuing the “is-located-at” Relationship Type example, the following are examples of valid

Relationships:

“John Doe” (Person Object) “is-located-at” (Relationship) “Building XYZ” (Facility Object)

A Property Type is a specification of an attribute and its range of valid values. Some examples:

Height: positive integer

Body Style: “Sedan”, “Coupe”, “Truck”

Name: Unicode string

Property Types will be incorporated into the specification of one or more Object Types and Relationship Types. As part of the specification, Object Types and Relationship Types will identify additional constraints such as cardinality, required/not required, etc. For example:

Object Type: Person

Property Type: “Name”

ID: “First Name”

Cardinality: 1

Required: True

Property Type: “Name”

ID: “Last name”

Cardinality: 1

Required: True

Property Type: “Name”

ID: “Alias”

Cardinality: Unbounded

Required: False

A Property is an instance of a Property Type in an Object or Relationship. Using the “Person” Object Type specification above, a valid Object could be:

Object ID: “John Doe”

Property ID: “First Name”

Value: “John”

Property ID: “Last Name”

Value: “Doe”

Property ID: “Alias”

Value: “Jack Deer”

3.2.5.1.1 The software shall include a database that supports the storage, management, and retrieval of

Objects, Relationships, and Properties as defined by the Government-provided AATS ontology.

3.2.5.1.2 The software shall import and export the Government-provided AATS ontology in Web Ontology

Language (OWL) 2 compliant RDF/XML format.

The contractor shall provide the Government with all ontology implementation requirements necessary to provide the capability defined in this specification.

The ontology implementation requirements shall not restrict the ability of the Government to define direct subclasses of the OWL 2 Class “owl:Thing”.

If the contractor requires that the Government-provided AATS ontology include or import XML schemas or ontologies, the contractor shall provide an electronic copy of the required documents.

3.2.5.1.3 The software shall provide the capability to create new ontologies.

3.2.5.1.4 The software shall allow the combination of multiple ontologies so as to construct the overall ontology.

3.2.5.1.5 The software shall provide the capability to update the ontology, both via the software user interface and via the import of an updated Government-provided AATS ontology.

3.2.5.1.6 Prior to committing ontology changes, the software shall provide the capability to map existing data to the new ontology without data loss.

If the software is unable to map existing data to the new ontology without data loss, the software shall provide a report that identifies the data that will be lost as a result of the ontology update.

3.2.5.1.7 Prior to committing ontology changes, the software shall provide the capability to update mappings between data sources and data element mappings (see Section 3.2.5.2.3.3)

3.2.5.1.8 The software shall provide the capability to deploy the ontology to other instances of the AATS database.

3.2.5.1.9 The software shall provide the capability to visualize the ontology.

3.2.5.1.10 The software shall ensure that all data stored in the database is validated against the ontology.

The software shall support the use of Relationship Properties as defined in the Government-provided

AATS ontology.

The software shall support the use of required Properties for Objects and Relationships as defined in the Government-provided AATS ontology.

3.2.5.1.11 The software shall support the Object Type taxonomy defined in the Government-provided AATS ontology.

3.2.5.1.12 The software shall support the Relationship Type taxonomy defined in the Government-provided

AATS ontology.

3.2.5.2 Data Entry

The processing and exploitation phase of the intelligence cycle involves the conversion of structured, semi-structured, and unstructured data into information that is suitable for the production of intelligence to satisfy intelligence requirements. The AATS software will provide manual, assisted, and automated data entry capabilities to support this phase of the intelligence cycle.

The software shall support the processing of structured, semi-structured, and unstructured data into Objects, Relationships, and Properties conformant with the Government-provided AATS ontology.

3.2.5.2.1 Manual Data Entry

3.2.5.2.1.1 The software shall allow the user to create and update Objects.

3.2.5.2.1.2 The software shall allow the user to set and update Property values for an Object.

3.2.5.2.1.3 When Property values for an Object are updated, the software shall preserve the history and attribution of changes to the Property value.

3.2.5.2.1.4 The software shall allow the user to create and update Relationships between Objects.

3.2.5.2.1.5 The software shall allow the user to archive Relationships between Objects.

3.2.5.2.1.6 The software shall allow the user to set and update Property values for a Relationship.

3.2.5.2.1.7 When Property values for a Relationship are updated, the software shall maintain the history and attribution of changes to the Property value.

3.2.5.2.1.8 The software shall allow the user to attach files to an Object.

3.2.5.2.1.9 The software shall allow the user to link an attachment to a specific Property.

3.2.5.2.1.10 The software shall allow the user to define a default image per Object Type.

3.2.5.2.1.11 The software shall allow the user to set a custom image per Object.

3.2.5.2.1.12 The software shall allow the user to define a default MIL-STD-2525C symbol for an Object Type.

3.2.5.2.1.13 The software shall allow the user to set the MIL-STD-2525C symbol for an Object.

3.2.5.2.1.14 The software shall allow the user to archive Objects.

The archive operation shall archive the Relationships, Properties, and attachments for each archived

Object.

3.2.5.2.1.15 The software shall allow the user to restore archived Objects.

3.2.5.2.1.16 The software shall exclude archived data from user searches unless the user specifies that archived data should be included in the search results.

3.2.5.2.1.17 The software shall exclude archived data from replication unless the user requests the inclusion of archived data.

3.2.5.2.1.18 The software shall allow the user to merge Objects.

3.2.5.2.1.19 The software shall allow the user to merge Relationships.

3.2.5.2.1.20 The software shall allow the user to assign a confidence value for the Object and the Properties for the Object.

3.2.5.2.1.21 The software shall allow the user to update the confidence value for the Object and the Properties for the Object.

3.2.5.2.1.22 The software shall allow the user to assign a confidence value for a Relationship and the Properties for the Relationship.

3.2.5.2.1.23 The software shall allow the user to update the confidence value for a Relationship and the Properties for the Relationship.

3.2.5.2.1.24 All Objects shall be labeled in accordance with (IAW) Intelligence Community Information Security

Markings Metadata (ICISM) standards

3.2.5.2.1.25 All Relationships shall be labeled IAW ICISM standards.

3.2.5.2.1.26 All Property values shall be labeled IAW ICISM standards.

3.2.5.2.1.27 The classification for the Object should be equal to the highest Property value classification for the

Object.

3.2.5.2.2 Tagging

The tagging capability assists the user in creating structured data from unstructured or semi-structured documents.

The user is able to identify and select Objects and Relationships in a document, and the AATS software identifies potential matches to those Objects in the AATS database. Via the tagging process, the user is able to associate the selected Object or Relationship to the AATS-identified match, or is able to create a new Object or Relationship from the selection that will be stored in the AATS database.

3.2.5.2.2.1 The software shall allow the user to tag Objects in documents.

3.2.5.2.2.2 The software shall allow the user to tag Relationships in documents.

3.2.5.2.2.3 The software shall identify to the user potential matches between tagged items and existing

Objects and Relationships in the database.

The software shall allow the user to view and edit matches to tagged items.

3.2.5.2.2.4 The software shall allow the user to create Objects or Relationships from tagged items.

3.2.5.2.3 Automated Ingest

The automated ingest capability provides for unattended conversion of intelligence data and information into

Objects and Relationships. Data sources for the automated ingest capability include local and networked file storage, external databases, and web services. Data formats include documents, spreadsheets, and presentations, geospatial data files, USMTF messages, and other domain-specific formats. Objects and Relationships that are created by the software as a result of automated ingest will identify the source of the data, a reference to the data source (typically a Uniform Resource Indicator), and will maintain a copy of the data that was used to create the

Object or Relationship. File content will be fully indexed to enable searching within documents via the search/query user interface.

3.2.5.2.3.1 The software shall provide the capability to ingest structured and semi-structured data from local and networked file storage, external databases, and web services.

3.2.5.2.3.2 The software shall provide the capability to map data elements from structured and semi-structured data sources to Objects, Relationships, and Properties.

3.2.5.2.3.3 The software shall provide the capability to associate data element mappings with specific data sources.

3.2.5.2.3.4 The software shall provide the capability to configure and execute a schedule for ingest of structured and semi-structured data.

3.2.5.2.3.5 The software shall allow the user to specify a local file source for automated ingest.

3.2.5.2.3.6 The software shall monitor specified file sources and automatically ingest new and modified files.

3.2.5.2.3.7 The software shall process all ingested files for Object and Relationship extraction.

The software shall identify Objects and Object Properties in processed files.

The software shall identify Relationships and Relationship Properties in processed files.

3.2.5.2.3.8 All ingested data shall retain the reference to the source of the data.

3.2.5.2.3.9 The software shall retain a source copy of the ingested data.

3.2.5.2.3.10 The software shall provide a capability to ingest data from the following file types:

Keyhole Markup Language (KML)

Shape files

Microsoft Office 2003 and later documents

Microsoft Office 2003 and later spreadsheets

Microsoft Office 2003 and later presentations

Portable Document Format (PDF)

Text files

Rich Text files (RTF)

Comma separated value (CSV)

National Imagery Transmission Format (NITF)

Tagged Image File Format (TIFF)

Geospatial Tagged Image File Format (GEOTIFF)

Joint Photographic Experts Group (JPEG)

JPEG 2000 (JP2) files

Portable Network Graphics (PNG)

Windows Metafile (WMF)

Compressed Image Base (CIB)

North American Treaty Organization (NATO) Secondary Imagery Formats (NISF)

3.2.5.2.3.11 The software shall prevent duplicate files from being ingested.

3.2.5.2.3.12 The software shall automatically transform invalid Property values entries into allowable values.

3.2.5.2.3.13 The software shall…