Attachment_1_PWS_FINAL_10.28.16v2__.pdf

Performance Work Statement For

Marine Air Ground Task Force (MAGTF) Command and Control

Systems & Applications (MC2SA) Software Maintenance Support and Software Technical and

Development Support jodie.shifflett Typewritten Text

Attachment 1 Performance Work Statement

For Marine Air Ground Task Force (MAGTF) Command and Control

Systems & Applications (MC2SA) Software Maintenance Support and Software Technical and Development Support

1. Introduction The activities identified in this Performance Work Statement (PWS) encompass Software Maintenance Support, Software Technical and Development Support for Connectors, Applications, and Application Extensions. The indefinite delivery/indefinite quantity (ID/IQ) contract form allows the Government to order some or all of the activities identified in the PWS, singly or jointly, any number of times throughout the contract’s 5-year ordering period.

Individual task orders (TOs) will include Firm Fixed Price (FFP) and Cost Plus Fixed-Fee (CPFF) Contract Line Items (CLINs), as appropriate, for the defined work efforts in support of the MAGTF C2 Systems and Applications (MC2SA) Portfolio of Systems.

2. Scope This PWS addresses the efforts required to provide Software Maintenance Support and Software Technical and Development support to the Marine Corps Systems Command for a portfolio of Marine Air Ground Task Forces (MAGTF) Command and Control systems (MC2S) within the MAGTF Command, Control, and Computers (MC3) program management office. Specific activities outlined in this PWS are in support of the MC2SA Integrated Product Teams (IPT), and include the family-of-systems for the Command and Control Personal Computer (C2PC), and the Tactical Service Oriented Architecture (TSOA) system. This PWS addresses those activities related to software maintenance, technical support, and the development of Connectors/ Extensions, Applications, system enhancements and new capabilities for these MC2SA systems.

(Note: Within the PWS, the term MC2SA will refer to both C2PC and TSOA unless otherwise stated).

As identified in Section B of the Request for Proposal (RFP), there are multiple CLINs that consist of FFP and CPFF requirements. TOs will be issued using two methods. The first method will be for requirements that are firm fixed-priced (CLINs 1001 through 1011 and associated Ordering Period Years CLINs) and the scope and price of the TOs are negotiated under the contract’s terms. The second method will be for requirements that will require the release of a scope specific PWS and RFP and require the awardee of this ID/IQ contract to propose (CLINs 1012 through 1019).

3. Background

MC2SA provides a suite of systems and applications that enable systems interoperability and commonality between MC3 programs that interface with Command, Control, Communication, Computer, Intelligence, Surveillance and Reconnaissance (C4ISR) systems. These interfaces, along with other MAGTF C2 systems, provide an integrated Common Tactical Picture/Common Operational Picture (CTP/COP) to aid in decision making for the Warfighter.

3.1. Command and Control Personal Computer (C2PC)

3.1.1. The Marine Corps utilizes the Joint Tactical Common Operational Picture Workstation (JTCW) as the framework for enhanced systems interoperability and commonality between MAGTF systems. JTCW, as a Windows®-based workstation, provides a suite of applications designed to facilitate military C2 functions. C2PC is the primary, Government owned, software component of the JTCW. JTCW consists of a number of Application Extensions (AEs) which directly interface with C2PC as injectors that enable JTCW to meet operational requirements.

3.1.2. C2PC consists of the C2PC Client, C2PC Web Services, and C2PC Gateway and C2 Compact Edition (C2CE). C2PC, as a whole, includes a significant number of modules, injectors, folders and interfaces, and is based on a Microsoft Component Object Model (COM) and Net frameworks. C2PC is written in C, C++, C#, and JAVA languages. The Government owns and has unlimited or Government Purpose Rights to the C2PC source code and technical data package.

3.1.2.1 C2PC Client: The C2PC Client provides Application Program Interfaces (APIs) for the AEs to interact with the map and other features of the Client. The Client provides the Marines with a disconnected network capability. C2PC Client is the primary data entry point for the COP where users are able to view map data, view and update track data, develop and distribute overlays, exchange general message traffic, plan and distribute route information, and conduct general C2 planning.

3.1.2.2 C2PC Web Services: The C2PC Web Application, interfaced with the Client, allows multiple operators to obtain and interact with COP data via a web browser. This capability significantly expands the use of the COP for warfighters without having to operate the C2PC client on each workstation.

3.1.2.3 C2PC Gateway: The C2PC Gateway maintains a COP on all C2PC Clients. The C2PC Gateway exchanges data with the Global Command and Control System (GCCS) server or another C2PC Gateway. The C2PC Gateway must be running for the C2PC client to receive updates.

3.1.2.4 C2CE: The C2CE complements C2PC by providing a portable situational awareness application to be used on handheld devices such as tablets and smartphones. C2CE automatically transmits Global Position System (GPS) derived position reports which are injected into the COP via a wireless connection with a C2PC gateway. C2CE allows for the display of digital maps produced by the National Geospatial-Intelligence Agency

(NGA), and display of the user’s position. When connected to a combat net radio, an operator can utilize C2CE to create, transmit and receive Variable Message Format (VMF) messages such as free text and position updates to display tracks/positions of other users.

3.2. TSOA

3.2.1. TSOA is a modular suite of software comprised of licensed Commercial Off-The- Shelf (COTS), and Government Off-The-Shelf (GOTS) software that, when integrated, meets the Operational Forces need for the sharing of tactical data across the disparate MAGTF and Service based Tactical Data Systems (TDS). The Government owns and has Government purpose rights to all TSOA GOTS software interface definitions, and technical data packages. TSOA provides the ability for authorized users to discover, subscribe to, shape, filter, modify, and visualize data (Net-centric operations) from Authoritative Data Sources in a way that aids their assessment of a situation. The program office is also running agile development pilots, and utilizing the Department of Defense (DoD) “IT” Box governance process, which allows for yearly updates to user based priorities

3.2.2. The TSOA system consists of four capabilities that comprise the TSOA Framework: Infrastructure and Services (I&S), Agile Application Development (A2D), Modular Software Architecture (MSA), and The Marine Corps Software Resource Center (MCSRC). The current Source Code of TSOA is a combination of Java, and XML. The program will update every two years to current industry standard web platforms, such as Angular JS, BootStrap, and finally to a set of technologies based upon Haadoop, NOSQL, and JSON technologies. These capabilities are being matured via the Office of Naval Research (ONR) and will be incorporated into the future Service Oriented Infrastructure (SOI), codenamed SOI GEN II.

3.2.2.1 Infrastructure and Services (I&S): The I&S Component is the Service Oriented Architecture, specifically the Service Oriented Infrastructure (SOI). This component provides the reuse of data from Authoritative Data Sources provided by various TDS, thereby reducing duplicative and redundant data. The ability to ingest and publish the various data feeds is accomplished utilizing a TSOA information object and the communication protocol via a piece of software called a connector. The requirements for each connector can range from being extremely simple to complex, (e.g. a generic connector could range from providing Position/Location all the way to interfacing with Navy tactical systems or Army Fire Systems).

These connectors are configured by Marine operators to ingest and distribute the information to the appropriate MAGTF Echelon, thereby supporting the commanders in their need to make decisions in-context. The SOI also provides a Software Development Kit (SDK) in order to facilitate the development of user driven applications, and utilization of data from various TDS.

3.2.2.2 Agile Application Development (A2D): The TSOA project utilizes an A2D software process, which in turn results in the development of light-weight applications in conjunction with Fleet-User feedback. A light-weight application is defined by the developer’s ability to rapidly develop User Interfaces, which are dependent upon the reuse, mediation, and search capabilities of data provided via the SOI.

3.2.2.3 MSA: TSOA is an open architecture based solution. In practice, this has meant the utilization of Open Software Source (OSS) products that are approved in the Department of Navy (DoN) Application and Database Management System (DADMS), in order to contain costs, and the usage of container technologies such as VMWARE, Dockers, Ozone Web Framework (OWF), and Ozone Platform (OZP) to maintain modularity.

3.2.2.4 Marine Corps Software Resource Center (MCSRC): The MCSRC is the Enterprise Store Front in ensuring applications development from the various Program Teams can be deployed rapidly. The MCSRC is currently operational within the Marine Corps Enterprise Information Technology Services (MCEITS) environment. This storefront is where Marines can go and view new applications, upgraded applications, software patches, or other artifacts (i.e., Technical Manual Updates).

3.3. MC2SA Vision

Over the next five years, JTCW and TSOA will transform and unify the capabilities of the existing systems, with each year showing a more unified architecture via the consolidation/retirement of duplicative connectors or application extensions in order to provide the United States Marine Corps (USMC) with a common software command and control baseline. This will require adoption and vision utilizing the Commandant’s Expeditionary Force (EF) 21 goals, and ensuring the Office of the Secretary of Defense based Joint Information Environment is used as overarching guidance for the development of the material solutions. The common solution envisioned includes standardizing user interfaces, algorithm development, and the goal is to provide the Marine a seamless view of common C2 applications. This fusion will be a blend of existing services, data, and applications in order to provide a dynamic mission application load configured for the planned mission. The TSOA will continue through the IT Box requirements process of using Requirements Definition Packages, and Capability Drops to gather Authoritative Data Sources (ADS) from multiple communities, with a current planned focus upon Operations /Logistics /Intelligence, and incorporation/reuse compliance with Naval solutions being developed to support the EF 21 tenet of returning the USMC to its Naval roots.

Multiple clients are envisioned that will support specific functions such as planning, execution and assessment as well software components residing on various hand held devices, all the way to the ability to request and reuse Cloud information from Navy, Army, and Defense Information Systems Agency (DISA) secure clouds.

4. Requirements

The contractor is responsible for identifying and managing C2PC and TSOA software maintenance activities, to include correcting software defects, maintaining the Cyber Security posture and developing new or enhanced C2PC and TSOA software. The contractor will develop subsequent releases by implementing these requirements.

Management activities are a key aspect of these requirements and are considered core activities under CLIN 1001 and its corresponding ordering year CLINs. Technical assistance and root cause analysis of trouble reports is a critical function under CLIN 1002 and 1003 and it’s corresponding ordering CLINS. Once the root-cause of a defect is identified via the services provided under CLIN 1002 and 1003, the Government will create a prioritized list and execute a task order to have them corrected, based on urgency and available funding. As software components become obsolete or new capabilities are desired, development tasks will be executed to correct, modify, or enhance the capabilities of C2PC and TSOA software. Cybersecurity is a vital function and encompasses all aspects of these requirements. The Government will execute a task to have Cybersecurity updates released based on the needs of the programs. Correction of software defects and Cybersecurity updates will be applied to the fielded baseline and baseline in development.

Comprehensive Software Engineering best practices and procedures are crucial to effectively execute the tasks defined in the PWS. As such, the Contractor shall be certified via the Capability Maturity Model (CMMI) Institute at CMMI Level 3, Dev.

Qualified personnel to fill Key Personnel positions are fundamental to the execution of the tasks required under this RFP, as are proper teaming arrangements and a thorough staffing plan.

4.1 Program Management

4.1.1. Management. The contractor shall establish and maintain program management practices throughout the period of performance. Program management practices shall provide visibility into the contractor’s organization and techniques used in managing the program, specifically subcontractor and data management. Documentation identified in this PWS shall be readily available to Government representatives during planned visits.

4.1.2. Sub-Contractor Management. The contractor is responsible for performance of requirements delineated in this PWS, and shall institute appropriate management actions relative to subcontractor performance. Requirements that are contractually specified shall apply to subcontractor performance; however, the contractor shall be accountable for compliance of subcontractors and is responsible for ensuring all deliverable products comply with the contract requirements.

4.1.3. Key Personnel Requirements. The key personnel positions are the Program Manager, Lead Systems Engineer, and Technical Subject Matter Expert(s) (SMEs). Key personnel are defined as those individuals who were proposed in the Contractor’s technical submission and will be listed in the resulting contract. No substitutions of key personnel shall be made except in accordance with this paragraph. Substitution requests must be submitted to the Contracting Officer in writing, at least fifteen (15) days [thirty (30) days if a security clearance is to be obtained] in advance of the proposed substitutions. All requests for substitutions must provide a detailed explanation of the circumstances necessitating the proposed substitution, and any other information requested by the Contracting Officer. All proposed substitutes shall have qualifications that are equal to or higher than the qualifications required of the person to be replaced. The Contracting Officer or his/her authorized representative will evaluate such requests and promptly notify the contractor of his/her approval or disapproval thereof. The following provides a description of the minimum expected performance for designated key personnel.

4.1.3.1 Program Manager. The contractor shall designate a Program Manager (PM) who shall possess sufficient corporate authority to manage, direct, execute and control all elements of the contractor’s performance. The PM shall serve as the primary point of contact between the contractor and the Government, and be responsible for the coordination of all contractor activities related to the work performed for this contract.

4.1.3.2 Lead Systems Engineer. The contractor shall designate a Lead Systems Engineer (SE) to support MC2SA. This Lead SE shall possess sufficient authority and system knowledge to manage, direct, execute and control all engineering elements of the work performed for this contract.

4.1.3.3 Technical Subject Matter Expert(s). The contractor shall designate one or more SMEs to provide technical support for C2PC and for TSOA. The Engineer(s) shall possess sufficient knowledge of the C2 environment and SOA platforms, and possess the qualifications necessary to provide technical assistance for the efforts defined in this PWS.

4.1.4. Staff Experience and Training. The contractor shall possess substantiated experience with software management, software application extensions, Cybersecurity, service oriented architectures, and open architecture functionality based capabilities.

4.1.4.1 Due to the complex nature of MC2S systems, the contractor shall possess experience with Marine Corps MAGTF C2 capabilities, systems, programs/products, technologies and methods by which they are extended, integrated and enhanced across the operating force elements, or equivalent experience with similar systems, programs/products, technologies and methods. This includes integration and implementation of MAGTF C2 capabilities across various platforms.

4.1.4.2 The contractor shall also possess experience with DoD, Department of the Navy (DoN) and USMC acquisition policies and procedures to include program management processes, system engineering and configuration management practices, a thorough understanding of Software Lifecycle Management, and experience using the Agile software process in previous development efforts.

4.1.5. Contractor Work Breakdown Structure (CWBS). The contractor shall at a minimum develop and manage a Level – 3 CWBS and dictionary as the basis for all contract work to scope planning, scheduling, contract cost estimating, resource allocations, performance measurements, and status reporting.

4.1.6. Schedule Management. The contractor shall develop and maintain an accurate schedule that includes program events, task timeframes, resource allocation and delivery dates to support all tasks associated with maintenance and developmental work defined in this PWS.

4.1.7. The contractor shall use Microsoft Project 2010 as their overarching scheduling and planning tool.

4.1.7.1 The contractor shall develop and maintain an Integrated Master Plan (IMP) and an Integrated Master Schedule (IMS) that can be vertically traced to the IMP. The contractor shall align the IMS with the CWBS.

4.1.7.2 The IMP shall describe plans for producing software components, controlling and accomplishing the work described in the PWS, and shall also be traceable to a Contract Performance Report (CPR).

4.1.7.3 The IMP shall also define and describe the integration of the events, accomplishments and associated criteria and shall include, but not be limited to, the following areas: program and technical management, supportability, configuration and data management, reliability, quality assurance, verification, safety, delivery schedule, and training.

CDRLA001 DI-MGMT-81650 Integrated Master Schedule

CDRLA001 DI-MGMT-81334D Contract Work Breakdown Structure

CDRLA001 DI-MGMT-81466A Contractor Performance Report

4.1.8. The contractor shall notify the Government in writing of any anticipated or projected work stoppages or delays that will impact C2PC or TSOA schedules by more than 10 working days.

4.1.9. Configuration Management. The contractor shall maintain configuration management (CM) for the control of all hardware and software configuration documentation, media and parts. The principles contained in EIA-649 and MIL-HDBK-61A may be used for guidance. The contractor's CM process shall consist of configuration identification, configuration control, configuration status accounting, and configuration audits. Consideration for interfacing with other acquisition requirements, such as design review, assurance, and other program related disciplines, shall be addressed. The contractor’s CM process shall align with the MC2S CM Plan.

4.1.10. Data Management. The contractor shall utilize a single, centralized system for management of all data required under this contract.

4.1.10.1 The contractor shall ensure all data within their centralized system is accessible by the Government.

4.1.10.2 At a minimum, specific data management functions shall include a schedule for deliverables, maintenance of deliverables, and distribution and delivery of data products.

4.1.11. Risk Management. The contractor shall identify, assess, monitor and control risk during performance of the contract. Risks shall be reported in the monthly status report.

4.1.12. Quality Management. The contractor shall implement and maintain a quality assurance program. The contractor’s established internal quality assurance control and inspection procedures shall be made available for Government review.

4.1.13. Integrated Product Teams (IPTs). The contractor shall be an integral part of the Government’s IPTs, and provide the right resources for IPT participation via phone or in-person (as required).

4.1.14. Meetings and Management Reviews will occur throughout the contract period of performance. Exact dates and locations will be defined by the Government, or as defined below.

4.1.14.1 Weekly Status Meetings. The contractor shall host a weekly status meeting to brief the program office on current activities via telecom. The Government anticipates these meetings lasting no more than one hour. Informal read-ahead packages (Contractor format) shall be provided 24 hours prior to the scheduled meeting,

4.1.14.2 Status Reports. The contractor shall provide written monthly status reports that address, at a minimum, current status activities, to include work status summary, risk summary, identification of technical issues, updated IMS, and cost updates.

4.1.14.3 In-Process Review (IPR): Throughout the life-cycle of this contract, the contractor shall conduct and host a quarterly IPR conference at the contractor’s facility. The Government anticipates any such meeting to potentially last up to 5 days. The contractor shall provide an agenda to the Government 2 weeks prior to the IPR. Topics to be addressed include, but are not limited to:

4.1.14.3.1. Key milestones and IMS

4.1.14.3.2. Contractor team readiness status

4.1.14.3.3. Identification of Risk and Risk Mitigation

4.1.14.3.4. Task Management Issues

4.1.14.3.5. Progress to Plan Updates

4.1.14.3.6. STR Tracker Updates

4.1.14.4 Agenda. The contractor shall deliver an agenda for major meeting events and conference events to the Government two weeks prior to the event, whether the meeting is requested by the Government or the meeting is to meet the contractual responsibility of the contractor.

4.1.14.5 Minutes: The contractor shall deliver to the Government minutes and action items generated from meeting and conference activities. Minutes shall be provided within 5 days of meeting completion.

CDRL A002 DI-MGMT-80368A Status Report

CDRL A003 DI-ADMN-81429B Conference Agenda

CDRL A004 DI-ADMN-81250B Conference Minutes

CDRL A005 DI-ADMN-81505 Report, Record of Meeting/Minutes

4.1.15. Software Development Plan (SDP). The contractor shall deliver a SDP defining the process and procedures to be used to execute this PWS.

4.1.15.1 The contractor’s SDP shall adhere to Software Management Best Business Practices and be aligned to MC2SA Systems Engineering Processes.

4.1.15.2 The contractor’s Software Development Strategy shall seek to reduce life cycle cost through economies of scale, resource optimization, and family-of-systems and services optimization. This effort shall include a reduction in capability redundancies, and recommendations for potential functional realignment between the MC2S systems.

CDRL A006 DI-IPSC-81427A Software Development Plan

4.1.16. Software Host Environment. The contractor shall maintain a Software Development and Test Hosting Environment for currently fielded C2PC and TSOA and their development baselines. The contractor shall utilize this environment in support of efforts identified in this PWS.

4.1.17. Software Delivery. Software deliveries are required for all activities where software code has been modified.

4.1.17.1 With each software delivery the contractor shall ensure no software deliveries contain any Priority 1 or Priority 2 errors.

4.1.17.2 With each software delivery the contractor shall deliver a tailored Technical Data Package (TDP) that includes data products related to the design, test, operations, and administration of the particular effort. The details of the TDP tailored list are identified in Appendix A-2: Tailored TDP Requirements Contract Data Requirements List (CDRL) Tracker.

4.1.17.3 With each software delivery the contractor shall provide a Data Accession List (DAL) that identifies internally generated data and computer software used by the contractor to develop, test, and manage the program. The list shall include the identification number, title which shall describe content, security classification, and identification of Government Rights to the Data.

CDRL A007 Contractor Format Software Delivery

CDRL A008 DI –SESS-80776A Technical Data Package

CDRL A009 DI-MGMT-81453A Data Accession List

4.1.18. Software Test Plans and Reports. The contractor shall develop test plans and prepare and deliver reports to support all testing activities.

CDRL A0010 DI-MGMT - IPSC-81438A Software Test Plan

CDRL A0011 DI-MGMT-IPSC-81440A Software Test Report

4.2. Technical Assistance and Root Cause Analysis

4.2.1. The contractor shall ensure the requested Technical SME(s) who are Key Personnel possess the experience and skill sets required to support the Technical tasks defined in this section.

4.2.2. The contractor shall provide technical assistance to the Government labs, MCTSSA Help Desk, and external developers, as directed by the program office. Technical assistance encompasses providing subject matter expertise for both the technical and operational aspects of C2PC and TSOA. This support is required during software development efforts, as well as during post-delivery support to the operating forces. This support is estimated at a not to exceed 4800 hours during a particular yearly task period. This support will be provided during standard business hours (0800-1700) within the offeror’s time zone.

4.2.3. The Contractor shall perform root cause analysis of trouble reports. The analyses shall include fault isolation and recommended solutions to correct the error. Minor corrections to ensure the operator remains up and running, shall be performed with approval of the Government program office. More complex changes that require change to code will be reported to the Government program office who will determine if a separate Task Order should be issued to address the problem. .

4.2.3.1 Root cause analysis may require establishing a development environment in a live operational environment when issues are not reproducible in a lab environment.

4.2.3.2 Software fixes made in the development environment, to isolate the root cause, shall be delivered to the Government for incorporation into the software baseline, as directed by the Government.

4.2.3.3 Root cause analysis may be in the form of phone support; however, travel may be required, as directed by the Government. Travel expectations are defined in Section 7 of this PWS.

4.2.4. The contractor shall record all unresolved issues in their software defect tracking system and report them to the Government via weekly IPTs and monthly status reports.

4.2.5. The contractor shall provide engineering, software engineering, integration and testing support. The support shall include technical analysis, technical interchange meetings, collaborative engineering and development of test and analysis tools. This support shall be in the form of phone support; however, travel may be required, as requested by the Government.

Travel expectations are defined in Section 7 of this PWS.

4.2.6. The contractor shall participate in Government IPT meetings and various working groups. These IPTs and working groups have scheduled meeting times and participation is normally provided via phone; however, participation may require travel, as directed by the Government. Travel expectations are defined in Section 7 of this PWS.

4.2.7. The contractor shall conduct Technical Studies and deliver Technical Reports when directed by the Government. These reports shall define the changes necessary to improve operational functionality or reduce life cycle costs.

CDRL A0012 DI-MISC-80508B Technical Report-Study/Services

4.3. Cybersecurity Compliance

4.3.1. The contractor shall perform Cybersecurity updates and deliver software updates every 30 or 90 days, as tasked by the Government. Cybersecurity updates will be applied to the fielded baseline.

4.3.2. The contractor shall perform Cybersecurity tasks in accordance with the latest releases or revisions of the following policies:

• MCO 5239.2B, Marine Corps Cybersecurity Program, dated 05 Nov 2015

• DOD Instruction (DODI) 8500.01, Cybersecurity, dated 14 Mar 2014

• SECNAVINST 5239.3B, DoN Information Assurance (IA) Policy, dated 17 Jun 2009

• USMC Enterprise IA Directive; dated 02 Sep 2008

• MCSC SIAT Risk Management Framework (RMF) Process Guide, dated 25 May 2016

4.3.3. The contractor shall use the Government defined Source Code Analysis tool (currently Fortify) in all software development activities and correct discrepancies identified in the tool report. Fortify licenses will be distributed to the contractor, and managed by the Government.

4.3.4. The contractor shall use the DISA Security Technical Implementation Guides (STIG) in all software development activities and modify software to function in the STIG environment.

4.3.5. The contractor shall use the DISA Assured Compliance Assessment Solution (ACAS) and Security Content Automation Protocol (SCAP) content and tools as their primary vulnerability scanning, and configuration assessment tool.

4.3.6. The contractor shall update C2PC and TSOA third party applications to conform to Cybersecurity requirements. Updates to third party applications may require modification to C2PC or TSOA software to prevent loss of functionality.

4.4. Software Trouble Reports

4.4.1. STR corrections are ordered by Task Order against the appropriate contract CLIN.

The Government categorizes STRs by their level of difficulty, based on a Level 1: Low; Level 2:

Medium; and Level 3: High rating.

4.4.2. The contractor shall correct software problems documented in existing and new Software Trouble Reports (STR) for C2PC and TSOA. STRs are identified by the operational forces and during test events. Once an STR is identified, it is anticipated that the Government will categorize it (as described below), and issue a FFP Task Order against the appropriate CLIN. Due to the uncertainty of the complexity and scope of STR Level 3 fixes the Government will negotiate FFP or CPFF Task Orders, as appropriate, during contract execution. The Government is not obligated to issue a STR Task Order.

4.4.3. The contractor shall assist the IPT with their classification categories for each STR based on the defined categories below:

4.4.3.1 Level 1 STR: Low Difficulty - Level 1 STRs are limited in scope and the impacts are isolated to a small area, typically involving the user interface and/or changes to a single project. User interface corrections can include changing the labeling on a window, re-arranging window elements, or re-sizing a window. Changes to one project can include updating the logic to correct a deficiency or adding a new capability. Low difficulty actions usually require minor changes to program documentation, and testing is limited to verification that corrective action resolves the STR. Low difficulty corrective actions are expected to require from 1-24 work hours for completion.

4.4.3.2 Level 2 STR: Medium Difficulty - Level 2 STRs primarily involve changes to multiple projects, one or more API, or extensions typically involving updating a COM interface, changing the way data is exchanged between processes, changing multiple projects, and adding a new user interface element (dialogs and windows). Changes can include adding new functions, adding new files and changing data exchanged between unrelated processes. Medium difficulty actions usually require updates to multiple supporting documents (e.g. Software Version Descriptions, Software Administrator’s manuals, Software User’s Manuals, and software test procedures). Testing for medium difficulty STRs is also more involved as testing is required for one or more specific areas (e.g. Alerts, Communication, and Address Books). Medium difficulty corrective actions are expected to require from 25-48 work hours for completion.

4.4.3.3 Level 3 STR: High Difficulty - Level 3 STR’s are similar to Level 2;

however, they require significant time to correct the defect. High Difficulty corrective actions are expected to exceed 48 work hours for completion.

4.5. Software Development

4.5.1. The contractor shall conduct software development to create or update C2PC software components in accordance with the requirements detailed in task orders. C2PC software development primarily consists of updating components to conform to military standards, maintain interoperability with external systems, and to enhance capabilities for the C2PC Client, C2PC Web, C2PC Gateway, and C2CE.

4.5.2. The contractor shall conduct software development to create or update TSOA software components in accordance with the requirements detailed in this PWS and specific Task Orders. The TSOA software development consists of creating and updating the service oriented infrastructure, applets, applications, and connectors.

4.5.3. The contractor shall analyze each Task Order RFP provided by the Government and determine courses of actions for implementing the requested change.

4.5.4. The contractor shall provide a proposal that identifies, at a minimum, the recommended change, system components affected, system interfaces affected, risks, timeline, and cost. The proposal will be in a format agreed upon by the Government and Contractor.

5. Government Furnished Property (GFP)

5.1. Accountability & Storage

5.1.1. The contractor shall provide for accountability, security, and storage for the GFP provided.

5.1.2. The contractor shall inspect and inventory all GFP received and identify and report any discrepancies/deficiencies.

5.1.3. The contractor shall report the status of GFP via the DoD Procurement Toolbox website.

5.2. Government Furnished Equipment (GFE)

5.2.1. The Government does not expect to provide any GFE in support of this work effort.

5.3. Government Furnished Information (GFI)

5.3.1. The Government will provide the contractor with C2PC and TSOA source code.

6. Contract Administration

6.1. Partnering Agreements

To effectively carry out the requirements of this contract, particularly for support efforts with C2PC, the contractor shall be required to establish partnering agreements through Associate Contracting Agreements (ACAs) or Memoranda of Agreement (MOAs) (as appropriate) with other Contractors and Government agencies that contribute to the full functionality of C2PC and/or TSOA. The contractor should anticipate an agreement with:

6.1.1. Defense Information Systems Agency (DISA) Integrated Command, Control, Communications, Computers, and Intelligence (C4I) Systems Framework (ICSF) software.

6.1.2. Real-Time Innovations, Inc. for Data Distribution Service (DDS) software.

6.1.3. Analytical Graphics, Inc. (AGI) for Cesium and STK Terrain Server.

6.1.4. National Geospatial-Intelligence Agency (NGA) for Commercial Joint Mapping Toolkit (CJMTK) software.

6.2. Facility Security Requirements

This contract requires the contractor to have a Secret Facility Clearance and requires certain contractor personnel to obtain and maintain classified access eligibility. The contractor shall have a valid Secret Facility Clearance and a Secret Document Safeguarding Level prior to classified performance at the contractor’s facility. The contractor shall secure the necessary clearances in sufficient time to avoid any delay in contract performance. The prime contractor and all sub-contractors (through the prime contractor) shall adhere to all aspects of DoD Directive 5220.22-M. All personnel identified to perform on this contract shall maintain compliance with Department of Defense, Department of the Navy, and Marine Corps Information and Personnel Security Policy to include completed background investigations (as required) prior to classified performance. This contract shall include a DoD Contract Security Classification Specification (DD Form 254) as an attachment. The contractor shall notify the Government (written notice) within twenty-four hours of any contractor personnel added or removed from the contract that have been granted classified access, issued a Common Access Card and/or MARCORSYSCOM Building access.

6.2.1. The contractor shall have a secure physical storage facility.

6.2.2. The contractor shall have Secret Internet Protocol Router Network (SIPRNET) capability.

6.2.3. The contractor shall have a Secure Terminal Equipment (STE) Phone Line.

6.2.4. The contractor shall have the ability to store classified documentation up to the Secret classification level.

6.3. Common Access Card (CAC) Requirement

The contractor shall identify and request to the Contracting Officer’s Representative (COR) for approval those contractor employees performing on this contract that require Common Access Cards (CACs) in order to perform their job function. Full justification for issuance of a CAC is required for each individual. In accordance with Headquarters, United States Marine Corps issued guidance relative to Homeland Security Presidential Directive – 12 (HSPD-12), all personnel must meet eligibility criteria to be issued a CAC. In order to meet the eligibility criteria, contractor employees requiring a CAC, must obtain and maintain a favorably adjudicated Personnel Security Investigation (PSI.) Prior to being authorized a CAC, the employee’s JPAS record must indicate a completed and favorably adjudicated PSI or (at a minimum) that a PSI has been submitted and accepted (opened). The minimum acceptable investigation is a National Agency Check with Written Inquiries (NACI). If a contractor employee’s open investigation closes and is not favorably adjudicated, the CAC must be immediately revoked and retrieved.

6.3.1. The contractor’s Facility Security Officers (FSOs) are responsible for notifying the MCSC Security Director if any contractor performing on this contract receives an unfavorable adjudication after being issued a CAC. The FSO must also notify the MCSC Security Director of any adverse/derogatory information that arises or becomes known to the contractor and is associated with the 13 Adjudicative Guidelines/Factors concerning any contractor issued a CAC, regardless of whether a JPAS Incident Report is submitted.

6.3.2. Each CAC is issued with a “ctr.usmc.mil” e-mail account that the individual contractor is responsible to keep active by logging in on a regular basis (at least twice a month), sending an e-mail and clearing any unneeded e-mails. Contractors are prohibited from “auto-forwarding” their .mil e-mail account to their .com or any other e-mail account that is not .mil. If the ctr.usmc.mil e-mail account is not kept active, the G-6 will deactivate the account and CAC will lose its functionality.

6.3.3. CACs will only be issued to those contractors supporting this contract that have been authorized by the COR. The COR will only authorize CACs for those contractors that meet current Homeland Security Presidential Directive – 12 (HSPD-12) criteria and have a definitive requirement.

6.3.4. If a contractor loses their eligibility for a CAC due to an adverse adjudicative decision, they have also lost their eligibility to perform on MCSC contracts. CACs are not issued for convenience.

6.4. Contractor Personnel Requirements

All contractor employees shall identify themselves as contractor personnel by introducing themselves, or being introduced, as contractor personnel and by displaying distinguishing badges or other visible identification for meetings with Government personnel.

6.4.1. Contractor personnel shall appropriately identify themselves as contractor employees in telephone conversations and in formal and informal written correspondence.

6.4.2. All email correspondence shall contain a signature line to include full name, company, program supported, telephone number and company.

6.4.3. The Prime contractor and all sub-contractors (through the prime contractor) shall adhere to all aspects of DoD Directive 5220.22, National Industrial Security Program (NISP), and dated September 27, 2004.

6.4.4. Key personnel supporting this contract shall comply with the Marine Corps Information and Personnel Security Policy that requires a Secret clearance.

6.4.4.1 This Secret clearance shall be complete prior to the performance of any classified work efforts.

6.4.4.2 The contractor shall provide written notice to the Government within 24 hours if any personnel (key or otherwise) added or removed from the contract have previously been granted classified access, issued a Common Access Card or issued a Marine Corps Systems Command (MARCORSYSCOM) building access card.

6.5. Non-Disclosure Agreements (NDA)

It is the Contractor's responsibility to complete all Contractor-to-Contractor Non-Disclosure Agreements (NDA) necessary to interface with other Contractors to accomplish all tasks in support of this PWS. Copies of the NDA’s shall be provided to the COR for inclusion in contract files.

6.6. Post Award Orientation (Kick Off) Meeting.

The contractor shall host a post award orientation within 2 weeks after award at the contractor’s facility. The Government anticipates this meeting to potentially span up to 5 days. The Contractor shall deliver an agenda to the Government 1 week prior to the meeting. The Contractor shall provide, at minimum, information that addresses all sections of this PWS, as well as the following:

6.6.1. An overview of their CMMI Level 3 DEV processes and practices for Software Development,

6.6.2. An understanding of all security requirements,

6.6.3. An understanding of monthly metric reporting,

6.6.4. An understanding of inspection, acceptance, and invoicing procedures,

6.6.5. An understanding of the authority, responsibilities, and limitations of the Government COR,

6.6.6. Government personnel access requirements,

6.6.7. Data Item Deliverable Requirements,

6.6.8. Test Hosting Environment Management, and

6.6.9. Contractor to Government Communication Methods.

6.7. Contract Close-Out

It is the Contractor’s responsibility to provide a closeout of the contractual tasks. Closeout shall be part of the final delivery and shall identify any remaining Government products, hardware, software and a delivered final report to include lessons learned and analysis of the task.

6.8. Enterprise-Wide Contractor Manpower Reporting Application (ECMRA)

6.8.1. The contractor shall report contractor labor hours (including subcontractor labor hours) required for performance of services provided under this contract for the MC2SA Software Support effort via a secure data collection site. Contracted services excluded from reporting are based on Product Service Codes (PSCs). The excluded PSCs are:

6.8.1.1 W, Lease/Rental of Equipment;

6.8.1.2 X, Lease/Rental of Facilities;

6.8.1.3 Y, Construction of Structures and Facilities;

6.8.1.4 S, Utilities ONLY;

6.8.1.5 V, Freight and Shipping ONLY.

6.8.2. The contractor is required to completely fill in all required data fields using the following web address https://doncmra.nmci.navy.mil.

6.8.3. Reporting inputs will be for the labor executed during the period of performance during each Government fiscal year (FY), which runs October 1 through September 30. While inputs may be reported any time during the FY, all data shall be reported no later than October 31 of each calendar year.

6.8.4. Contractors may direct questions to the help desk, linked at https://doncmra.nmci.navy.mil.

7. Facilities, Other Direct Costs (ODCs), and Travel Requirements

7.1. Facilities

Work efforts in support of this contract will be accomplished at the contractor’s facilities except as specifically mentioned elsewhere in this PWS. This contract will require the contractor to provide a suitable infrastructure to manage program requirements (e.g., document library, databases, web site) throughout the course of performance to support the scope of activities.

Such facilities are not reimbursed as ODCs. Laptops, cellular equipment/services, and other items of convenience are not reimbursable as ODCs. All Government printing requirements MUST be done by or through the local Document Automation and Production Service (DAPS, now called DLA Document Services) http://www.daps.dla.mil/dapsonline.html.

7.2. Travel

7.2.1. Travel may be required under this contract and future task orders. Travel to other Government facilities, field activities, and Marine operating forces (U.S. and overseas) or other contractor facilities may be required and will be reimbursable under the Travel and ODC CLIN.

Travel requirements (including plans, agenda, itinerary and dates) for travel outside the local area shall be pre-approved by the Government COR on a strictly cost reimbursable basis. The https://doncmra.nmci.navy.mil/ http://www.daps.dla.mil/dapsonline.html contractor shall make necessary travel arrangements for its employees, after written approval from the Government COR is secured.

7.2.2. When sufficient lead time allows, travel requests shall be submitted at least 10 working days in advance of the travel date. The request will include the total cost and a break out of costs to include airfare, rental vehicle, per diem, mileage, parking, fuel and tolls. Travel requests will identify the purpose of trip and explain why VTC or phone conversations would not meet the business requirement.

7.2.3. Travel costs will be invoiced under the appropriate reimbursable CLIN. Costs must be in accordance with FAR 31.205-46, and invoices should include all information required by FAR 31.205-46(a) (7). Travel costs will be limited to reimbursement of direct costs only.

Travel costs which include cost elements exceeding that permitted for Government employees under the Joint Travel Regulation must be pre-approved in writing by the COR or they will be deemed unallowable. Notwithstanding any pre-approvals, the total of all reimbursable contractor costs for travel and other ODCs are limited to the NTE amount obligated against the associated Travel and Other Direct Costs contract line item number. The contractor shall retain receipts and other contemporaneous documentation to substantiate claimed travel costs and such documentation shall be made available to the Government upon request. All per diem shall be in accordance with http://www.defensetravel.dod.mil/site/perdiemCalc.cfm.

7.2.4. If more than one traveler is traveling, sharing of rental vehicles is required.

Differing arrival and departure times will not justify separate rental vehicles. For rental cars carrying three or more travelers, larger vehicles may be authorized in advance. The Government will reimburse economy lot parking. The Government will not reimburse valet or short term parking.

7.2.5. The following table provides an estimated number of trips and locations that may be required under this contract.

Table 2: Projected Travel

SSC-P

San Diego, CA

SSC-A

Charleston, SC

MCSC

Quantico, VA

I MEF

Camp Pendleton, CA

II MEF

Camp Lejeune, NC

III MEF

Okinawa Japan/Oahu, HI

C2PC 4 2 1 1

TSOA 2 2 2 1 1 1

http://www.defensetravel.dod.mil/site/perdiemCalc.cfm

7.2.6 Traveling Outside the Continental United States (OCONUS) requires adherence to both the Synchronized Pre-deployment and Operational Tacker (SPOT) system as well as MCSC MC3 Overseas travel requirements, as defined below:

7.2.6.1 Deployment Package: Requires a 90 day period for approval. Traveler shall coordinate with the COR on specific instructions and requirements for overseas travel.

Appendix A-1: CDRL Tracker

CDRL Document Title Frequency Delivery Cyber Update STR Development

A001 Integrated Master Plan

DI-MGMT-81650; DI-MGMT-

81334D and DI-MGMT-81466A

Monthly

Initial 10 days after Contract Award

X X X

A002 Status Report

DI-MGMT-80368A

Monthly

30 Days after

Contract Award

X X X

A003 Conference Agenda

DI-ADMN-81429B

AS REQ

10 week days prior to each event

X NA NA

A004 Conference Minutes

DI-ADMN-81250B

AS REQ

10 week days after each event

X NA NA

A005 Report, Record of Meeting/ Minutes

DI-ADMN-81505

AS REQ

10 week days after each event

X NA NA

A006 Software Development Plan

DI-IPSC-81427

AS REQ

14 week days after Contract Award

X X X

CDRL Document Title Frequency Delivery Cyber Update STR Development

A007 Software Delivery AS REQ SW Delivery X X X

A008 Technical Data Package (Tailored)*

DI-SESS-80766A

AS REQ SW Delivery X X X

A009 Data Accession List AS REQ SW Delivery X X X

A0010 Software Test Plan (STP)

DI-IPSC-81438A

AS REQ Per event X X X

A0011 Software Test Report (STR)

DI-IPSC-81440A

AS REQ Per event X X X

A012 Technical Report-Study/Services

DI-MISC-80408A

AS REQ When

Necessary X NA NA

*Tailored TDP Requirement on A-2

Appendix A-2: Tailored TDP Requirements

System Document Title Frequency Cyber Update STR Development

C2PC ACAS Scans AS REQ X X X

C2PC Fortify HP Report AS REQ X X X

C2PC DISA Secure Content Automation Protocol (SCAP) Report AS REQ X X X

C2PC Interface Control Document (ICD) AS REQ NA NA X

C2PC Interface Design Description (IDD) AS REQ NA NA X

C2PC Interface Requirements Specification (IRS) AS REQ NA NA X

C2PC Software Design Description (SDD) AS REQ NA NA X

C2PC Software Development Kit (SDK) AS REQ NA NA X

C2PC Software Product Specification (SPS) AS REQ NA NA X

C2PC Software Programmers Guide and Reference (PGR) AS REQ NA NA X

C2PC Software Requirements Specification (SRS) AS REQ NA NA X

C2PC Software User’ Manual (SUM) Client AS REQ NA NA X

C2PC Software User’ Manual (SUM) Web App AS REQ NA NA…