M67854-16-R-4806_Att_3_TO2_PWS_ECP.docx

Marine Corps Systems Command Program Manager Information Systems & Infrastructure Total Force Information Technology Systems (TFITS) Defense Readiness Reporting System – Marine Corps (DRRS-MC), Engineering Change Proposal (ECP) Performance Work Statement

April 2016

Table of Contents

List of Tables

List of Figures

Defense Readiness Reporting System – Marine Corps Performance Work Statement iii Introduction Purpose and Scope The Total Force Information Technology Systems (TFITS) product office provides acquisition oversight for the portfolio of United States Marine Corps (USMC) systems. DRRS-MC falls under the Warfighting, Planning and Analysis Tier. The purpose of this Performance Work Statement (PWS) is to obtain Systems Integrator (SI) services for the Defense Readiness Reporting System – Marine Corps (DRRS-MC). The contractor shall provide Post Deployment Software Support (PDSS), system maintenance and performance upgrade services, and logistics support for the DRRS-MC as defined in this PWS..

The scope of this PWS covers the full range of PDSS, system maintenance and performance upgrade services. Services include program management; engineering and analysis; software development; configuration management; quality assurance; risk management; help desk; system and database administration; Information Assurance (IA); testing and evaluation; and logistics support.

Background The DRRS-MC is a Mission Assurance Category (MAC)-1 classified system and a Secure Internet Protocol Router (SIPR) only program. The DRRS-MC is the authoritative system for readiness reporting that supports the Service’s U.S. Code Title 10 responsibilities to measure and report the readiness of USMC forces and the supporting infrastructure to meet Service and Department of Defense (DoD) requirements. The DRRS-MC provides capabilities-based, adaptive, near-real-time readiness information used in making Service readiness assessments, and to aid crisis planning, operational decisions, and resource management. DRRS-MC feeds the DRRS Enterprise (DRRS-E) via the DRRS- Strategic (DRRS-S) which is used to satisfy Joint Staff, Office of the Secretary of Defense (OSD), and Combatant Command (COCOM) readiness data requirements. The DRRS-MC reports readiness of forces from lowest capability entity to high-level aggregations culminating at the Marine Forces (MARFOR) level. The DRRS-MC configuration consists of a network of tools, applications, and data working in a net-centric environment. The DRRS-MC is a collection of authoritative databases that provide users access to current data. This data feeds a collection of applications that allow commanders to report resource levels, provide mission assessments, conduct sustainability and risk analyses, and carry out adaptive planning. The DRRS-MC is an existing evolutionary abbreviated acquisition program with initial operational capability delivered in 2010 and the deployed version 2.0 delivered in May 2012. The DRRS-MC Training Environment, Production and Pre-Production systems are hosted by the Marine Air Ground Task Force (MAGTF) Information Technology Support Center (MITSC) located in the Basement Consolidated Server Room in the Pentagon. A DRRS-MC Disaster Recovery/Continuity of Operations site exists to ensure high availability for the MAC -1 classified system. Figure 1 is the DRRS-MC Operational View..

Figure 1: DRRS-MC Operational View The DRRS-MC system consists of a collection of cross platform Java applications, residing in Oracle WebLogic, IBM Cognos, or loosely integrated as Windows Services. Network-enabled Unit Status Report – Marine Corps (NetUSR-MC) and Marine Corps Readiness Analysis Tool (MCRATS) are separate applications that are integrated into a Single Sign-On (SSO) Enterprise Archive (EAR) file within Oracle WebLogic to allow for SSO of the users. Applications reside in WebLogic 11g and pull in the database connections using WebLogic’s Data Sources so that the connections are secure and passwords are not stored within the applications. MCRAT is built using Cognos 10.2. This application has a custom built user information handler to allow users single sign-on from the Splash application to MCRAT. Figure 2 is a Physical Representation of the System Production Architecture.

Figure 2: Physical Representation of the System Production Architecture Total Force Information Technology Systems (TFITS) Management Plans Table 4 identifies the TFITS management plans that provide overarching guidance for TFITS managed projects. These documents form the foundation for the baseline for TFITS common best business practices.

Reserved Contractor Performance The contract shall be performed in accordance with this PWS and the Government’s Quality Assurance Surveillance Plan (QASP). Additionally, the contractor shall perform in accordance with the processes and standards in the Contractor’s PDSS Plan, Software Development Plan (SDP), Project Management Plan (PMP), and Quality Assurance Program Plan (QAPP).

During the performance of the DRRS-MC activities, the Contractor may be required to work cooperatively with program office personnel, functional advocates, and contracted support.

Objectives The PDSS, and system maintenance and performance upgrades shall be performed, managed, and monitored to the Government’s price, schedule, and performance objectives through an integrated and defined set of project processes tailored from Capability Maturity Model Integration (CMMI) Level III equivalent or higher set of standard processes.

The DRRS-MC system shall be available on a 24-hour basis, seven days a week.

Accurate and complete system documentation (configuration baselines, technical documentation, information assurance documentation, user documentation, web-based training, and other system documents) updates and any required certifications/accreditations shall precede the deployment of any capabilities.

Reserved Reserved Software Development All development objectives should be developed and fielded in accordance with the Supplement to Guidebook for Acquisition of Naval Software Intensive Systems: Software Criteria and Guidance for Systems Engineering Technical Reviews, MCSC Technical Review Handbook v1-04, and Program Manager, Total Force Information Technology Systems Interim Policy Letter 1-11, Implementation of Tailored System Engineering Technical Reviews.

Additionally, all Software Development initiatives impact the system baseline and are therefore governed by the Configuration Management (CM) process as defined in the Software Development Plan (SDP) and TFITS Management Plans. The SDP lays out the process required to develop, modify, or upgrade Government software and describes the details of each step along with any considerations that need to be addressed.

Software Development Plan The Contractor shall develop an SDP and execute a project-level system engineering process that addresses and coordinates with the processes, products, functions, and objectives described in the TFITS System Engineering Plan (SEP). The Contractor shall provide an initial SDP and deliver an updated version as required. The Contractor shall continue to update the SDP to maintain alignment with this SEP. This SDP is considered a living document that will be updated as necessary to support evolving requirements and maturing products and processes. The SDP shall be updated with each system maintenance and performance upgrade. At a minimum, an update to the SDP will be reflected for each system maintenance and performance upgrade (classified as either an second octet/major or third octet/minor change) and new capability requirements (classified as a first octet capability change) shall ensure and provide the following in accordance with the specified level of Systems Engineering Technical Review (SETR) tailoring based in the Engineering Change Proposal (ECP) classification level.

Describe how the SDP can produce supporting artifacts that are based on the recommended methodology in the Supplement to Guidebook for Acquisition of Naval Software Intensive Systems: Software Criteria and Guidance for Systems Engineering Technical Reviews; TFITS Management Plans; and the Marine Corps Systems Command Technical Review Handbook, v1.4 dated April 2009.

Describe in the SDP specific Software Development areas where cost savings will be realized through reusability, reliability, and maintainability.

Provide a strategy for integrating CM, Human Systems Integration, Logistics, and Cybersecurity into each stage (4.1.1 – 4.1.5) of the software development process.

At a minimum, the SDP shall provide the Contractor’s approach to:

Provide derived requirements.

Design software.

Develop software.

Test software.

Deploy software.

Data driven Department of Defense Architecture Framework (DoDAF) compliant views (as necessary per Task Order (TO)) SDP Annexes An annex to the overarching SDP shall be developed in response to each software development related TO. At a minimum, the annex for each System Enhancement (classified as either an second octet or major or third octet minor change) and New Capability Requirements (classified as a first octet capability change) TO shall ensure and provide the following in accordance with the specified level of SETR tailoring based on the ECP classification level:

Requirements Analysis Phase The key objective of the Requirements Analysis Phase is to transform the Government’s needs into a technical view of a required product that could deliver those needs. Efforts involve defining user needs and requirements in the context of planned user environments and identified system characteristics to determine requirements for system functions.

At a minimum, the Contractor shall:

Elicit derived requirements.

Perform an iterative process of decomposing requirements into system functional requirements and establishing traceability.

Maintain traceability between the derived and Government-provided requirements.

Align requirements analysis efforts with MCSC acquisition requirements (TFITS Management Plans and SETR process).

Provide documentation needed to support the MCSC SETR process for System Requirements Reviews (SRR) and System Functional Reviews (SFR).

Document the functional baseline.

System Design Phase The objective for the System Design Phase is the on-time delivery of Government-approved documentation that provides the detailed design of each configuration item in the approved product baseline. The System Design phase produces a design that is based on the functional descriptions and products developed during the Requirements Analysis phase. The design is reflected in the products developed and delivered by the Contractor.

At a minimum the Contractor shall:

Provide the Contractor’s design process including the use of design and modeling tools, analyses, and tradeoffs.

Align the Contractor’s process with the TFITS Management Plans and the MCSC SETR process for Preliminary Design Review (PDR)s and Critical Design Review (CDR)s.

Provide documentation needed to support the PDRs/CDRs.

Document the Allocated and Product baselines.

Development Phase The prime objective for the Development Phase is the on-time delivery of a Government-tested and -accepted capability solution.

At a minimum the Contractor shall:

Develop, integrate, assemble, and test capability.

Provide In-Process Review (IPR). The Contractor should propose methods to communicate incremental functional changes to stakeholders during IPRs in an effort to increase awareness of proposed ECP solutions. Appropriate areas to communicate include system design briefs, requirements matrices presentations, and test documentation reviews.

Align the Contractor’s process with the TFITS Management Plans and MCSC SETR process for Test Readiness Review (TRR).

Provide documentation needed to support the DRRS-MC TRR and Production Readiness Review (PRR).

Support GAT, IV&V, code review, and cyber-penetration testing.

Deployment Phase The prime objective for the Deployment Phase is the deployment of the Government-accepted capability into the production environment in accordance with the established performance standards.

At a minimum the Contractor shall:

Document the Contractor’s deployment process.

Validate that all certifications and accreditations are in place prior to deployment.

Prepare the system user community to receive and use capability.

Warranty the software for three months from any defects.

Coordinate and deliver the deployment package within the PDSS Release Management process.

Project Management Reserved Task Management A Task Management Plan (TMP) shall be developed in response to each TO specific to each Task PWS. At a minimum, the Contractor task management efforts shall perform the following Task Management requirements:[footnoteRef:1] [1: System specific needs will be described in the TO.]

ECP Task Initiation.

ECP Resource coordination and management, to include:

TO Roles and responsibilities.

Individual Security Clearances.

The Contractor shall have, and provide evidence to the Program Management Office (PMO) of, individual clearances of team members as appropriate to the work required to perform the TO.

The Contractor shall have, and provide evidence of, current Secret Clearances for all individuals performing on classified aspects of this contract who will be required to access Secret information. Secret access is required in order to attend meetings and perform daily work inside approved areas. Access to Secret data requires unescorted access into Secret spaces and access to Secret information and systems (e.g., SECRET Internet Protocol Router Network (SIPRNET)).

The Contractor shall have, and provide evidence of Top Secret individual clearance for any privileged users or individual with root access for the SIPRNET enclave.

The Contractor shall have, and provide evidence of Cybersecurity certification as appropriate to perform a specific TO.

Evidence of Top Secret Individual Clearance for any privileged users and/or individual with root access for the SIPRNET enclave.

The TCSI shall demonstrate that all individuals performing work on classified aspects of the system have a current Secret Clearance in order to maintain access to Secret Information. Secret access is required in order to attend meetings and perform daily work inside approved areas ECP Task Execution.

At a minimum, the Contractor for Task Execution shall:

Perform quality assurance in accordance with the QAPP.

Identify and manage risks and update the Risk Management Plan, as necessary.

Host and attend, provide agenda, provide meeting minutes, and participate in any ad hoc Working Groups, Integrated Product Teams (IPT), Technical reviews, Technical Interchange meeting, IPR, and any other system specific meetings to support the requirements of Task Orders.

Tools, techniques, and methodologies.

ECP Performance Management.

Provide a Monthly Status Report (MSR) to include, at a minimum: All Priority 1 metrics from the TFITS Performance Measurement Plan, previous month’s activities, updated risk register, upcoming activities, all incidents, summary of service issues, problem trends, progress towards the Performance Standard and Acceptable Quality Levels (AQLs) and anticipated travel (with a justification for the travel).

ECP Task Closeout.

Provide orderly closeout of the task order closeout including final delivery of any remaining Government products, hardware, software and preparation of a final report to include lessons learned and analysis of the task.

Reserved Reserved Reserved Integrated Master Schedule The Contractor shall develop and maintain an overall DRRS-MC Integrated Master Schedule (IMS) throughout the period of performance of the contract. The DRRS-MC IMS shall provide the Government information sufficient to demonstrate how the Contractor intends to manage the proposed effort:

At a minimum, the Contractor shall develop an IMS using Microsoft Project version 2010 compatible or a version otherwise approved by the government.

Table 1: Key Milestones

Performance Standards The Contractor shall be monitored against the following performance standards and AQLs.

Table 2: Performance Standards

SETR results

GAT Scorecard

Applicable Documents and References.

The following tables provide essential programmatic and technical information for contractors to consider while preparing their response.

Table 3: System Documentation

Table 4: TFITS Management Plans

Table 5: Other Guidance & Standards

Deliverables and Schedule.

All Deliverables shall be uploaded to the Government’s electronic repository (SharePoint) with a notification to the KO, COR, and the system Project Manager. The Contractor shall develop and deliver the following:

Table 6: Deliverables

Government Furnished Information and Equipment The Government will provide all of the source code, system documentation, system manuals, and web-based training source code. The Government will provide the shared data environment where all the DRRS-MC Program information resides. The shared data environment includes repositories to support the DRRS-MC Team’s configuration control process, baseline documentation, CITDB, action items, risk management, etc. The Administration and Resources Information (ARI) Systems Branch/ MITSC Headquarters Marine Corps (HQMC) will provide the hosting facility for the DRRS-MC Production, Pre-Production and DR/ COOP systems.

Security Requirements This contract requires the contractor to have a Secret Facility Clearance and will require certain contractors 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 prime contractor and all sub-contractors (through the prime contractor) shall adhere to all aspects of DoDI 5220.22. 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, Pentagon Building access, and/or MCSC Building access.

Common Access Cards The COR will identify and approve those contractor employees performing on this contract that require Common Access Card (CAC)s in order to perform their job function. In accordance with Headquarters, United States Marine Corps issued guidance relative to Homeland Security Presidential Directive – 12 (HSPD-12), all personnel shall 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 authorizing a CAC, the employee’s Joint Personnel Adjudication System (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 retrieved and revoked.

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 associated with the 13 Adjudicative Guidelines/Factors concerning any contractor issued a CAC, regardless of whether a JPAS Incident Report is submitted.

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 e-mail account. 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.

Common Access Card (CAC) 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.

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.

Place of Performance The work work to be performed under this contract shall be performed at the Contractor facility with two positions to be staffed in the Functional Advocate’s location within the Pentagon.

The Contractor shall attend meetings and participate in telephone conferences in the Quantico, Virginia area and at the Pentagon.

1 Period of Performance The period of performance shall be as specified in the task order award.

Travel and Other Direct Cost The Contractor personnel shall be located within 10 miles driving distance of the Quantico Corporate Center located at 1000 Corporate Drive, Stafford, Virginia. The Government shall not pay travel costs for Contractor personnel to commute to work. Any reimbursable travel incurred during the performance of the contract shall not include travel for day-to-day work activities. Travel required for the convenience of the Contractor to facilitate the Contractor’s staffing of the contract shall be the responsibility of the Contractor. Travel for this purpose shall not be reimbursed.

Any travel outside of the National Capital Region requires Government COR approval/authorization. Travel and Other Direct Cost (ODC)s associated with PDSS and software development will be on a cost only reimbursable basis. No fee shall be allowed for travel or ODC. The Contractor shall be authorized travel expenses in accordance with FAR 31.205-46, consistent with the substantive provisions of the Joint Travel Regulation (JTR) and the limitation of funds specified in this contract.

Appendix A. Acronyms

MCOS

MCCAST

Marine Corps Organizational Server Marine Corps Certification & Accreditation Support Tool

Appendix B. Task Orders Table 7. List of ECPs for This Task Order

Description: An output that displays and prints out customized graphical unit readiness information.

Requirements:

- Users must have the ability to select individual units, communities, type units, and/or unit levels (e.g. battalions, squadrons, regiments, etc.) desired to be displayed and printed. Unit information can be displayed hierarchically (i.e. Division – Regiment – battalion), by level (i.e. all Regiments or battalions only, but displayed by structure organization (i.e. 1st Marine Division battalions together, 2nd Marine Division Battalions grouped together, etc.)), or displayed by community regardless of organizational structure (i.e. all VMFA squadrons together, all VMA squadrons together, all VMM squadrons together, etc. or all Infantry Bns together, all LAR battalions together, etc.)

-The display of information must be concise, logical, legible, and hierarchical, if applicable.

-The display must be able to be printed (as displayed) legibly on letter format, but also user selectable to any format size. Similar to Excel, the user can scale the printing as desired depending on the nature of the display. In other words, the user decides by the size of paper selected the size of the display is presented on the paper. The display is scaled and scalable to the size of the paper selected to print.

-Each unit displayed must provide at a minimum the following: 1) the date of the last submitted report, 2) C-level with the associated color, 3) any unit commander’s overrides with corresponding color, 4) the Mission Assessment (YQN), and 5) individual resource levels (P,S,R,T).

-Each displayed unit’s last submitted readiness report can be accessed from this display.

Stakeholders/User Groups: PP&O (POR), all DRRS-MC reporting units

Change Level: 3rd

SETRs Required: Consolidated SFR & SRR (Requirements Review), consolidated PDR & CDR (Design Review), TRR, GAT, PRR, & PIR

Description: The DRRS-MC User WBT is currently loaded in the DRRS-MC Splash page, the WBT needs to be updated to support the current version of DRRS and then posted to MaringNet

- All User WBT must be updated and developed IAW MarineNET standards.

- All audio will be re-recorded

- Estimate 50-75% of graphics will require updates (e.g. removed, changed, and/or added)

- A test must be developed in accordance with MarineNet standards.

- WBT will not exceed 4 hour (is 4 hours the target).

-MARINENET completion will result in an update to a Marine’s training record in the Marine Corps Training Information Management System (MCTIMS).

Stakeholders/User Groups: Stakeholders/User Groups: PP&O POR / Any user

The Policy WBT must be developed to the current MarineNET standards.

Updating a WBT requires multiple steps and reviews; step 1) draft or update story boards with a government review, step 2) develop draft course material with government review, 3) final product development with government review, and 4) posting on the MarineNet staging area and government testing. Each step requires about 12 hour of Government and contractor meetings in order to review the product being prepared.

Description: PLAYBOOK is an IT system on the classified network (SIPRNet) primarily managed and maintained by Marine Corps Forces Command (MFC). PLAYBOOK is a GOTS product initially developed internally by the Marine Corps. It supports internal Service processes providing visibility, accounting, and monitoring of enduring and emergent Combatant Command requirements. PLAYBOOK provides Operating Forces, the Supporting Establishment, and Service Headquarters (HQMC) with a common operating picture of global requirements and their approved and pending sourcing solutions. PLAYBOOK is one of the primary automated tools used to analyze and allocate USMC resources to Combatant Commanders in response to request for forces. A component of PLAYBOOK is the manual input of readiness information from DRRS-MC. This information is used to provide general situational awareness of the current readiness of non-deployed operational units and assist determining readiness impacts as a result of unit sourcing decisions. In order to streamline and reduce manual data input, the desire is to interface DRRS-MC with PLAYBOOK to auto-populate the unit readiness information within PLAYBOOK.

Requirements:

- DRRS-MC must be able to execute a SIPRnet-to-SIPRnet interface with PLAYBOOK.

- Unit readiness information from DRRS-MC must be able to be organized in PLAYBOOK in the following ways:

- Units from DRRS-MC to PLAYBOOK must be able to be filtered by deployment status. In other words, the only units displayed in PLAYBOOK are non-deployed units.

Stakeholders/User Groups: PP&O (POR), MARFORCOM

Change Level: 3rd

SETRs Required: Consolidated SFR & SRR (Requirements Review), consolidated PDR & CDR (Design Review), TRR, GAT, PRR, & PIR

Description: This dashboard will enable POR to build a list of Actionable Issues that would ultimately flow to Service Level discussions.

Requirement: (See attached graphic)

1. Readiness issues are created at the reporting unit level. Must be capable of displaying Readiness Deficiencies on the most current status of each readiness issue/deficiency entered by the unit.

2. These issues are submitted/forwarded to the next Higher Headquarters(HHQ) for appropriate action based on the OPCON of the unit.

- At each level above the reporting unit, the unit’s next higher headquarters (HHQ) would have the option of working the issue (assigned to a POC), accepting risk, or forwarding the issue to the next HHQ. If forwarded to the next HHQ, they would have the same options.

- Improved forecasting capability rather than a single get-well date, units would show the cycle over upcoming months.

3. Create a corresponding dashboard for each HHQ listing the issues assigned to their level of command for action (s) similar to a MCATS dashboard where HHQ manages readiness action(s).

4. Must be capable of viewing another unit by selecting the UIC/unit or entry of UIC/Unit at every unit level.

5. Must be capable of displaying Unit attributes: Major Command, Reporting Org, Subordinate Org, OPCON, ADCON, Core and Assigned Mission Name, Planning, and UTC Breakdown

6. Must be capable of displaying the resources and training levels with comments for Core and Assigned Missions. Levels are color coded.

7. Must be capable of displaying graphic displays of the Resources, and Training, Core and Assigned Mission Levels. Levels are color coded by level.

8. Must be capable of displaying METL Assessments (Y/Q/N) for Core and Assigned Missions. Assessments are color coded by level.

9. Must be capable of displaying each Marine Corps Task (MCT) and MCT Assessment for Core and Assigned Missions. Assessments are color coded by level.

10. Must be capable of displaying Readiness Projections by Core and Assigned Missions including Activity (PTF, Depl, Reset, etc) Projections are color coded.

11. Must be capable of displaying HHQ Core and Assigned Mission Levels on all unit dashboards. Levels are color coded.

Stakeholders/User Groups: Stakeholders/User Groups: PP&O (POR), MARFORs, MEFs / All DRRS-MC users, but focused towards Intermediate units and MARFORs.

Change Level: 3rd

SETRs Required: Consolidated SFR & SRR (Requirements Review), consolidated PDR & CDR (Design Review), TRR, GAT, PRR, & PIR

image1.jpeg image2.png image3.JPG