MCTIMS_Re-compete_FINAL_PWS_Sources_Sought.docx

Marine Corps Systems Command Program Manager Information Systems & Infrastructure

Program Manager, Applications (PM APPS) Marine Corps Training Information Management Systems (MCTIMS) Indefinite Delivery/Indefinite Quantity Performance Work Statement

M67854-19-R-4836 June 2019

DRAFT

Table of Contents

List of Figures Figure 1: MCTIMS Modules 5 List of Tables

Table 7: Contract Performance Locations Table 8: FSR Potential Travel Locations for MCTIMS Training 1 Introduction

1.1 Purpose and Scope

This Performance Work Statement (PWS) identifies the requirements and performance standards for Post Deployment Software Support (PDSS) for the Marine Corps Training Information Management System (MCTIMS) program. The scope of this PWS outlines the range and scope of the PDSS, which the vendor shall provide as defined in this PWS. Services include, but are not limited to:

1.2 Background

The Program Manager, Applications (PM APPS) provides management and acquisition oversight for a portfolio of United States Marine Corps (USMC) systems. MCTIMS falls under the PM APPS Headquarters, Sustainment, and Training (HQST) Tier.

MCTIMS is an automated, Common Access Card (CAC) enabled, web-based system consisting of 17 modules supporting individual and unit training, training standards, training development, curriculum management, training delivery, training management, training tracking, and recording of training completions for schools within Training and Education Command (TECOM). MCTIMS integrated management system supports end users throughout the Marine Corps by chronicling training for individual Marines and Marine Units against training standards identified in the Training and Readiness Manuals, Military Occupation Specialty Manual, and Formal School Program of Instruction. MARADMIN 085/16 dated 18 February 2016, Service Direction for Utilization and Standardization of the MCTIMS Unit Training Management and Individual Marine Management Modules Across the Total Force directs and outlines the fielding and utilization of the MCTIMS UTM and IMM modules across the total force.

MCTIMS supports 57 formal learning centers and training detachments and interfaces with 14 Marine Corps systems, other Branch Services systems, and Department of Defense (DoD) systems to provide capabilities for all formal school management functions. Additionally, MCTIMS provides objective training data to inform readiness assessments for units and for individual Marines executing doctrinal Unit Training Management processes throughout the total force. Figure 1 outlines data received into the MCTIMS database application through manual inputs, external interfaces, third party software, manual interfaces, and within the MCTIMS modules.

The MCTIMS application is currently hosted in the Marine Corps Enterprise Information Technology Services (MCEITS) data center facility in Kansas City, MO. MCEITS provides the hosting facility for the MCTIMS Production, Beta and Training instances in a Virtual Machine (VM) environment.

Figure 1: MCTIMS Modules

1.3 Program Manager, Applications Management Plans

The PM APPS management plans, which are the overarching guidance for PM APPS managed projects, are outlined in Section 9, Table 4. These documents form the foundation for the baseline for PM APPS common best business practices.

1.4 Government Approach to Contract Management

The overall contract shall be managed through the Indefinite Delivery/Indefinite Quality (ID/IQ) PWS, Quality Assurance Surveillance Plan (QASP), and Contractor Management Plans (with task order specific annexes). The Contractor’s management plans shall establish the overarching strategy and plan to manage all aspects of the consolidated contract.

The Contractor may be required to coordinate certain efforts with contracted Program Management Office (PMO) support personnel during the contract performance.

1.5 Task Orders

Task Orders (TOs) will be issued based on Government needs. Contractor responses shall include a Task Management Plan (TMP) (annex to the Project Management Plan), Integrated Master Schedule (IMS), and appropriate annexes to other related management plans. Each TO may contain the following aspects and parameters that are specifically tailored to the system requirements:

· Key Task Milestones

· Performance Standards

· Applicable Documents/References

· Deliverables and Schedule

· Government Furnished Equipment (GFE) and Government Furnished Information (GFI)

· Period of Performance (PoP)

· Place of Performance

· Travel and Other Direct Costs (ODCs)

1.6 Contractor Performance

The contract shall be performed in accordance with this PWS and the Government’s QASP. Additionally, the contract shall be performed in accordance with the processes and standards outlined in the Government’s (PM APPS) System Engineering Plan (SEP), Software Development Plan (SDP), Configuration Management Plan (CMP), and Project Management Plan (PMP).

1.7 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 a higher set of standard project processes.

The MCTIMS shall be available on a 24-hour basis, 7 days a week.

Accurate and complete system documentation (configuration baselines, technical documentation, information assurance documentation, user documentation, etc.) updates and any required certifications/accreditations shall precede the deployment of any capabilities where available in the Government provided tool.

2 Transition To minimize any decrease in system operational availability and to prevent possible negative impacts on PDSS services, the Government will require a transition period where the incumbent and new Contractor shall transition knowledge and understanding of MCTIMS PDSS efforts and processes. The incumbent shall deliver to the Government a complete backup of the database application and data. The incumbent shall deliver to the Government all source code data and system administration and software development documentation.

The transition in period will occur at the beginning of the base year and a transition out period will occur at the end of the last option year. The new Contractor shall accept turnover of all system documentation. During the transition period, the new Contractor shall become familiar with all PDSS efforts and processes in order to commence full performance of services at the end of the Transition period. The transition period shall begin upon the award of the contract, be at least 30 days in length but no longer than 60 days after award of the contract.

2.1 Objectives of the Transition

The objectives of the transition period are to ensure the Contractor is equipped with the knowledge and resources necessary to perform PDSS. The Contractor has a complete understanding of the system to be managed. The Contractor has instantiated the necessary system environments to facilitate the development and testing of required patches and changes. Finally, the Contractor is ready to perform the critical PDSS activities.

2.1.1 System Knowledge Transfer

The Contractor shall have a complete and comprehensive understanding of the system.

At a minimum, the Contractor shall demonstrate an understanding of the following at the Transition Readiness Review (TRR):

· Existing Engineering and Technical Documentation

· Existing User and Training Documentation

2.1.2 Contractor System Instantiation

The USMC intends to offer a Government owned and operated Enterprise Development Test Hosting Environment (EDTE) that will provide IT system and application hosting services to support developmental and test activities. The estimated time for the completion of the EDTE environment is unknown. Until this capability is available, the Contractor shall have the capability to conduct defect management which includes the ability to replicate system failures, test software patches prior to production release, and test system development efforts in a non-production environment. At a minimum, the Contractor System Instantiation includes:

2.1.2.1 Production System Software

A current copy of the production system software, including source code, will be provided as part of the transition process to support PDSS activities and instantiation of a production representative system in the Contractor’s Environment Development and Contractor Test Hosting Environment.

The Contractor shall provide the development and Contractor test hosting environment for the production representative system instantiation to include software installation and application configuration. The Contractor’s hosting environment shall be representative of the constraints and limitations of the production environment.

2.1.2.2 Test and Evaluation

The Contractor shall have complete understanding (activities, notional timeline) of what is required to be tested and validated and will have a complete functioning replication of the production system.

2.1.3 Critical PDSS Activities

The Contractor shall provide a detailed and executable Transition Plan (TrP) to transfer on-going service support and service delivery activities from the incumbent Systems Integrator. At a minimum, this includes:

2.1.3.1 Database Administration

2.1.3.2 System Administration

2.1.3.3 Cyber Security

2.1.3.4 System Interfaces

2.1.3.5 Help Desk

2.1.3.6 Web-based Training (WBT) modules, training, and training materials

2.2 Transition-In Period.

2.2.1 Transition Activity with the Government and Contractor Incumbent

The Contractor shall, at the start of the PoP, engage in the following activities throughout the transition period defined in the applicable TO:

2.2.1.1 Obtain administrative access from the current Contractor to the system as well as system interfaces.

2.2.1.2 Obtain Points of Contact (POCs) from the current Contractor to include telephone numbers and email addresses for the system, Functional Advocates, programmatic, and technical POCs for interfacing system, and POCs for current hardware and software maintenance agreements.

2.2.1.3 Schedule and attend up to five days of observing the current Contractor during conduct of system maintenance and administration during regular business hours. Days can be, but are not required to be consecutive. One day is equivalent to a minimum of eight hours, not including lunch.

2.2.1.4 Schedule and attend up to five days of conducting system maintenance and administration while the current Contractor observes during regular business hours. Days can be, but are not required to be, consecutive. One day is equivalent to a minimum of eight hours, not including lunch.

2.2.1.5 Schedule, plan, provide agenda and minutes, and participate in up to five day-long working group sessions and meetings to facilitate knowledge transfer on system functionality. Days can be, but are not required to be, consecutive. One day is equivalent to a minimum of eight hours, not including lunch.

2.2.1.6 Conduct a Transition Readiness Review to formally establish the Contractor’s readiness to fully transition the subject system.

2.3 Transition-out Period

2.3.1 Transition Activity with the Government and the Incoming Contractor The Contractor shall, at the completion of the PoP, engage in the following transition activities with the incoming Contractor throughout the transition period defined in the applicable TO:

2.3.1.1 The incumbent Contractor shall baseline the system and system documentation.

2.3.1.2 Baseline activities shall, at a minimum, consist of the following:

2.3.1.2.1 Physical Configuration Audit (PCA) or Validation of the PCA deltas.

2.3.1.2.2 The incumbent Contractor shall support the Government PCA in accordance with the PM APPS CMP.

2.3.1.2.3 Closure of all critical Action Items or critical Requests for Action (RFA).

2.3.1.3 Baseline documentation shall, at a minimum, consist of the following:

2.3.1.3.1 Configuration Item Technical Database (CITDB).

2.3.1.3.2 All deliverables as identified in the system(s) CITDB, system(s) contract, and PWS.

2.3.1.3.3 Software Source Code or Software Source Code location for future delivery

2.3.1.3.4 Regression test driver codes and test scripts, test data and benchmark results matched to software release version number.

2.3.1.3.5 Government data in Contractor licensed tools.

2.3.1.4 The incumbent Contractor shall transfer to the Government ownership of all hardware and software items that were purchased by the incumbent Contractor on behalf of the Government. The transfer process shall include re-registering all hardware and software components as MCSC/PfM SES (PM APPS).

2.3.1.5 The incumbent Contractor shall assist the incoming Contractor in implementing all applicable Information Assurance Vulnerability Alert (IAVA) patches, as well as Government funded Engineering Change Proposal (ECP). Open IAVA patches and ECPs designated in the Transition Readiness Review will be the responsibility of the incoming Contractor.

2.3.1.6 Assist incoming Contractor with getting required access to support MCTIMS; for example, administrator user identifications (IDs) and passwords, database user IDs and passwords, and all system(s) interfaces.

2.3.1.7 Provide incoming Contractor with all established and current POCs and stakeholders, to include phone number and email address for the MCTIMS Functional Advocate(s), programmatic and technical POCs for interfacing system(s); and POCs for current hardware and software maintenance agreements.

2.3.1.8 Provide up to five days of allowing incoming Contractor to observe the incumbent Contractor during the conduct of system maintenance and administration during regular business hours, i.e. 0800 - 1700. Days can be, but are not required to be consecutive. One day is equivalent to a minimum of eight hours, not including lunch.

2.3.1.9 Provide up to five days of incumbent Contractor observing the incoming Contractor during the conduct of system maintenance and administration during regular business operations, i.e. 0800 - 1700. Days can be, but are not required to be consecutive. One day is equivalent to a minimum of eight hours, not including lunch.

2.3.1.10 Attend up to five days of working sessions, meeting or both with the incoming Contractor to facilitate knowledge transfer on system functionality, to include existing automated and manual interfaces. Days can be, but are not required to be consecutive. One day is equivalent to a minimum of eight hours, not including lunch.

2.3.1.11 Allow incoming Contractor access to all system hardware and software within the Authority to Operate (ATO) boundary or Government owned for inspection and audit. The incumbent Contractor shall clarify any discrepancies in hardware and software assets.

2.3.1.12 Participate in Transition Readiness Review (TRR).

3 PDSS

The Contractor shall provide a PDSS Plan that describes the Contractor’s approach towards providing PDSS support in the areas of Service Support, Service Delivery and Sustainment Logistics. At a minimum, the plan shall address the support approach to accomplishing the tasks outlined in Section 3 of the PWS and Appendix B (Ref.: Table 6: Deliverable 023) The Contractor shall provide a PDSS Support Schedule that shows the anticipated activities the Contractor plans to perform in executing PDSS.

3.1 Service Support

3.1.1 Development and Contractor Test Hosting Environment

3.1.1.1 The Contractor shall maintain a development and testing environment that functionally reflects the system production environment at MCEITS.

3.1.1.2 Establish and maintain a development and test environment so that these environments are synchronized with production and staging environments at MCEITS.

3.1.1.3 Development and test environments shall include all hardware and software required to perform development and integration testing. The Government will provide as GFE the Hewlett Packard (HP) Fortify Tool or provided an alternative application for system code reviews.

3.1.1.3.1 Government Acceptance Testing (GAT) will be conducted in using the MCTIMS BETA instance in the MCEITS hosted environment. The BETA instance is one of the three instances hosted in the MCEITS environment. The other instances are Training and Production. Access to the BETA and Training instances shall be made available to the System Integrator team.

3.1.2 Help Desk

The Government furnished tool is BMC Remedy. The Contractor shall use BMC Remedy to provide Help Desk support.

The Help Desk is the single user point of focus for support and the reporting of incidents. The Help Desk processes include tracking and escalation procedures. In addition, the Help Desk is responsible for disseminating information regarding planned outages and/or implementation of changes impacting production services.

The Contractor’s Help Desk shall provide technical support and application assistance to users. Specific Help Desk coverage hours shall be addressed by each new TO requiring Help Desk support. The Help Desk shall be operated from the location defined in each TO requiring Help Desk support. The Contractor shall observe commercial best practices, such as Information Technology Infrastructure Library (ITIL) version 4 with the objective to receive, track, communicate (status to the user), and resolve user calls.

At a minimum, the Help Desk shall provide and consist of the following:

3.1.2.1 Respond to, complete, and close Help Desk requests.

3.1.2.1.1 Capture, track, investigate, escalate, resolve, close, and report user help requests.

3.1.2.1.2 The Contractor shall use the existing Government provided tool. Data includes: the caller’s name, work location, time of receipt of the call, nature of the call, time of resolution, and a brief statement of how the problem was resolved to record each user help request/trouble call. The Contractor has the ability to add data it feels is needed to improve its ability to manage help requests.

3.1.2.2 Resolve system access issues and assist system users in basic system functions (Tier 1). Provide the number of calls made to the Help Desk that are resolved during the first call.

3.1.2.3 Escalate requests beyond the capability of the Help Desk to resolve to more advanced support personnel. Ensure voice mail messages are responded to no later than the next business day.

3.1.2.4 Escalate Help Desk requests to IM to resolve system failures. Resolve system access issues and restore basic system functions, route tickets, determine a solution and/or the need to submit and ECP, provide resolution to the end user and enter ECP into the ECP List located in the PM APPS SharePoint portal.

3.1.3 Incident Management

The primary focus of Incident Management (IM) is the restoration of services following an incident. IM is primarily a reactive process; its processes provide guidance on diagnostic and escalation procedures required to quickly restore services. IM processes are closely integrated with Help Desk, problem management and Change Management (ChM) processes.

The Government requires an Incident Management Model (IMM) with predefined steps/processes that will provide diagnostic and escalation procedures to ensure quick restoration of services within MCEITS for Production, Beta and Training environments.

At a minimum, the Contractor’s IM shall consist of and/or provide the following:

3.1.3.1 Detect and record incident details.

3.1.3.1.1 Perform incident management including performance monitoring, incident identification, diagnosis/isolating, containment, eradication, recovery and lessons learned.

3.1.3.1.2 Track incidents reported from the system users, the host site, and external interfacing systems.

3.1.3.1.3 Communicate the incident(s) within one (1) hour to Stakeholders (i.e., Government Project Manager, TECOM Advocates, and the MCTIMS user community).

3.1.3.1.4 Identify and report functions and files affected.

3.1.3.1.5 Resolve incidents to support system operational availability.

At a minimum, the Contractor shall:

3.1.3.1.6 Resolve incidents including performing diagnostics, fault isolation, containment, eradication, recovery, and lessons learned.

3.1.3.1.7 Restore existing system and data.

3.1.3.1.8 Restore system to full operational capability.

3.1.3.1.9 Prioritize incidents in terms of impact and urgency with the objective to minimize user impact.

At a minimum, the Contractor shall:

3.1.3.1.10 Assess type and severity (e.g., number of users effected) of incident.

3.1.3.1.11 Assess impact to data integrity.

3.1.3.1.12 Reduce unplanned downtime hours.

3.1.3.1.13 Identify incident impact to the Government.

3.1.3.1.14 Recommend ratings for the priority and the urgency of each incident.

3.1.3.1.15 Inform the Government of the restoration of services and effects of the incident to the user community.

3.1.3.2 Immediately escalate incidents that require expertise not available in the currently assigned Tier.

3.1.3.3 Provide Help Desk verification that the incident is closed, and the system user is satisfied with the solution.

3.1.4 Problem Management

The primary focus of Problem Management is to identify the causes of service issues and conduct corrective work to prevent recurrences. Problem Management processes are reactive in responding to events/problems and proactive in identifying and preventing future incidents. The Contractor’s processes are closely integrated with IM, ChM, and Availability Management. Although Availability Management performs the lead role in component failure and system outage analyses, Problem Management performs an important role in obtaining data and analyzing data in support of the analyses. The Problem Management process and analyses shall be included as a part of the Monthly Status Report (MSR) (Ref.: Table 6: Deliverable 013).

At a minimum, the Contractor shall:

3.1.4.1 Analyze historical data to support predictive analysis to eliminate potential incidents before they occur and to identify work-arounds.

3.1.4.2 Maintain historical data in a BMC Remedy for all service problems.

3.1.4.3 Use a trouble ticket log to develop an analysis of trends to identify potential problems.

3.1.4.4 Provide the Government the results of problem management processes in the MSR.

3.1.4.5 Diagnose root cause and eliminate recurrences.

3.1.4.6 Provide the Government the potential causes of problems in its historical data.

3.1.4.7 Using historical data, provide the Government the Contractor’s approach for preventing problems from recurring.

3.1.4.8 Prioritize problems, in terms of impact and urgency, to minimize system user impact.

At a minimum, the Contractor shall:

3.1.4.8.1 Assess and provide type and severity (e.g., number of users affected) of problem.

3.1.4.8.2 Assess and provide impact to data integrity.

3.1.4.8.3 Reduce unplanned downtime hours.

3.1.4.8.4 Identify problem impacts to the Government.

3.1.4.8.5 Recommend the priority and the urgency to be assigned to each problem.

3.1.4.8.6 Inform the Government of the restoration of services and effects of the incident to the user community.

3.1.4.9 Develop workarounds or other solutions to incidents.

At a minimum, the Contractor shall:

3.1.4.9.1 Identify potential problems from the analysis of historical data.

3.1.4.9.2 Develop innovative workarounds and solutions to problems.

3.1.4.9.3 Present workarounds to the Government for consideration and approval for implementing an ECP.

3.1.4.10 Identify, develop and submit ECPs to Change Management to eliminate known problems.

3.1.5 Configuration Management

Configuration Management (CM) processes guide the collecting, archiving and reporting of individual infrastructure component specifications. The CITDB is the single repository of configuration information for the enterprise. In addition to configuration information, the database contains information regarding the relationships and dependencies among infrastructure components. CM databases are also used by Capacity Management, Availability Management, and IT Service Continuity Management processes to accurately perform their work.

The Government seeks a CM environment that will ensure the baselines are maintained and that only controlled changes are implemented. The Contractor shall implement a CM program that will ensure the implementation of changes is documented and has no adverse effect on current system functionality. The Contractor shall provide a CMP that provides the basis for performing and managing CM activities for MCTIMS and aligns with the PM APPS CMP. (Ref.: Table 6: Deliverable 024) At a minimum, the Contractor shall:

3.1.5.1 Maintain the CITDB utilizing the approved PM APPS CITDB format.

3.1.5.2 Identify new Configuration Items (CIs) and enter them into the CITDB.

3.1.5.3 Collect, record and maintain accurate information about CIs.

3.1.5.4 Establish and implement configuration control and approval processes required to change a CI’s attributes and re-baseline the CIs.

3.1.6 Change Management

Change Management assesses risks of individual changes, uses configuration information to identify dependencies and other impacted applications and systems, and after analyzing the information, authorizes or denies change requests. The goal of Change Management is to identify application code, functional and performance defects and intercept them before Users are impacted.

The Production, Beta (Testing) and Training virtual instances of the MCTIMS program are all hosted in the MCEITS enterprise environment located in Kansas City, MO. Assessment of changes to the infrastructure requires coordination between the host site, the user community, MCSC, and the Contractor.

3.1.6.1 The Contractor shall prepare written system change approaches, estimated costs, and schedules for the Configuration Control Board (CCB). The authoritative source of all system ECPs is the Government’s ECP Tracker System. The Contractor may propose changes but must receive approval from the CCB to execute ECPs.

3.1.6.2 The Contractor shall ensure and provide that its change management processes align with the PM APPS Management Plans listed in Table 4.

3.1.6.3 Contribute and record decisions and updates to any relevant products in tailored System Engineering Technical Review (SETR) events, Functional Review Boards (FRBs), Engineering Review Boards (ERBs) and CCBs. (Ref.: Table 6: Deliverable 018)

3.1.6.4 Perform ECP assessments for risk and potential user benefits prior to FRB, ERB and CCB meetings for complexity, and potential user benefits.

3.1.6.5 Maintain and update Contractor specific data elements of the Government’s ECP Tracker System. (Note: Requires a CAC)

3.1.6.6 Provide a level of effort to include the lifecycle hours for ECPs at the ERB. Provide a rough order of magnitude detailed lifecycle estimate for those ECPs approved by the CCB.

3.1.6.7 Identify application code defects as well as functional and performance defects, and submit ECPs as appropriate.

3.1.7 Release Management

Release Management is closely integrated with Change Management. Release Management manages changes to the environment such as installing vulnerability patches and software changes and/or refreshing technology.

At a minimum, the Contractor shall:

3.1.7.1 Perform all technical and non-technical aspects of a release, including the update and maintenance of system baselines, system documentation, user documentation, training documentation, and supply support material.

3.1.7.2 Plan and support the successful roll-out of software to include the required Contractor test and evaluation and Government Acceptance Test (GAT) processes. (Ref.: Table 6: Deliverables 006 & 007)

3.1.7.3 Design, implement and support efficient procedures for the distribution, installation and verification of changes including the client application.

3.1.7.4 Coordinate and prepare the Advocate and system user community for new release capabilities.

3.1.7.5 Ensure implementations are traceable, secure, and that only correct, authorized and tested versions are installed.

3.1.7.6 Coordinate and plan releases with Change Management.

3.1.7.7 Provide master copies of all software and update the CITDB. (Ref.: Table 6: Deliverable 012)

3.1.7.8 Document release plans in a Deployment Plan that at a minimum contains anticipated changes to be deployed (e.g., vulnerability patches, software upgrades, defect patches), program of action and milestones (POA&M) leading up to deployment, configuration items that need to be updated (e.g., technical documentation, System Maintenance and System Administration Manual, CITDB, User Manual, Training Material), and a contingency plan. (Ref.: Table 6: Deliverables 005, 009 & 010)

3.1.7.9 Support the Government Post Implementation Review (PIR) in accordance with PM APPS Management Plans.

3.1.8 Cybersecurity Management

Marine Corps Order (MCO) 5239.2A establishes an information systems lifecycle management approach to protect critical Marine Corps information and intelligence. The Contractor shall support the requirements of the current MCO 5239.2A (or latest version as identified in the Task Order as applicable) by establishing and implementing proactive protection, detection, reaction, disaster recovery and restoration capabilities to include the detection and reporting of unauthorized activities. The Contractor shall be capable of supporting the MCTIMS Risk Management Framework (RMF), DoD Instruction 8510.01 and be familiar with CNSSI 1253. The level of protection is aligned with the Mission Assurance Category of (MAC) III Sensitive.

The Contractor shall have knowledge of, and support all, certification and accreditation activities throughout the system lifecycle in accordance with the latest releases or revisions of the following policies located at:

http://www.dtic.mil/whs/directives/index.html/ http://csrc.nist.gov/publications/PubsSPs.html At a minimum, the Contractor shall:

3.1.8.1 Maintain the system’s ATO, review and update documentation (including but not limited to the Systems Information Profile, RMF (Implementation Plan, and Cyber Engineering Plan), and fulfill all annual cybersecurity requirements for a MAC III Sensitive program.

3.1.8.2 Ensure that all DoD information system Cybersecurity-related documentation utilized by the MCTIMS program is kept current and accessible to authorized program personnel during the PoP of the contract.

3.1.8.3 Provide awareness and prevention through assessment and implementation of best practices (code reviews, system scans, vulnerability alerts, vendor notifications, Security Technical Implementation Guides (STIG)).

3.1.8.4 Facilitate and participate in Annual Security Reviews, Annual Security Control testing, Annual Contingency Plan testing, and quarterly update and submissions of quarterly POA&M updates in compliance with the Federal Information Security Management Act (FISMA).

3.1.8.5 Use the Government’s IA tool, Marine Corps Certification and Accreditation Support Tool (MCCAST), to submit, maintain, and review certification and accreditation documentation and workflow. The Government will assist in gaining access to the tool, as well as training for the tool.

3.1.8.6 Work with the Government engineering team to register any software implemented on the systems for Marine Corps use in Department of the Navy Application and Database Management System (DADMS) prior to any system upgrade. The Contractor shall assist the MCTIMS PO and ISSM in completing and submitting the DADMS questionnaire as required.

3.1.8.7 Facilitate the protection of US Government unclassified/sensitive unclassified information by working closely with the Government Information Systems Security Manager, Information Systems Security Officer and staff.

3.1.8.8 Implement vulnerability assessment remediation and tracking per IAVAs, Information Assurance Vulnerability Bulletins, Information Assurance Vulnerability Management, and Operational Directives (OPDIRS).

3.1.8.8.1 Monitor and comply with all MCTIMS applicable notifications and advisories, including but not limited to: Information Assurance Vulnerability Alerts (IAVA), Information Assurance Vulnerability Bulletins (IAVB), Information Assurance Vulnerability Technical Advisories (IAVT), MARADMINs, DISA Security Technical Implementation Guides (STIGs) through the PM APPS SETR Processes/Events.

3.1.8.9 Confirm compliance of annual cybersecurity awareness training status with Contractor Program Manager to verify that all personnel are current in their cybersecurity training.

3.1.8.10 Review weekly vulnerability assessment scans, provide technical guidance on remediation (including the use of STIGS), and develop POA&M. (Ref.: Table 6: Deliverable 018)

3.1.8.11 At least once within the ordering period, as directed by the Government, review documentation, support pre-assessment, review vulnerability scans, test result evaluation, and review POA&M for Independent Verification and Validation (IV&V) test events.

3.1.8.12 Review documentation, support pre-assessment, review vulnerability scans, evaluate test results, and review POA&M for Command Cyber Readiness Inspection events.

3.1.9 Enterprise Development and Test Hosting Environment

The USMC intends to offer a Government owned and operated Enterprise Development and Test Hosting Environment (EDTE) providing IT system and application hosting services to support developmental and test activities. The Government does not have an estimated date of completion at this time. This capability will mitigate the requirement for the Government to contract external agencies and Contractors to provide a hosting environment to conduct development and test functions. In support of the transition to the USMC EDTE:

3.1.9.1 The Contractor shall support the instantiation of a production representative system, to include migration planning meetings, software installation, and application configuration, in order to conduct future development and test activities in the EDTE cloud environment.

3.1.9.2 The Contractor shall be responsible for maintaining source code; application software and server configurations; and software updates to ensure total system functionality reflects the production environment. Remote access to the EDTE to manage and sustain the system development and test instances will be provided by the Government.

3.1.9.3 The Contractor shall be responsible for coordinating system patches and maintenance activities with the EDTE service provider when such activities impact Contractor developmental and/or test efforts.

3.2 Service Delivery

Service Delivery processes assist in the identification of delivered or provided services, tailoring of services, and the timely provision of services, resources, capabilities, and capacities to meet MCTIMS’ needs.

3.2.1 Service Level Management

Service Level Management (SLM) processes provide a framework by which services are defined, levels of service required to support business processes agreed upon, and Service Level Agreements (SLA) developed to satisfy the agreements. SLM processes will clearly define IT and business roles and responsibilities and establish clear goals for service delivery so success factors can be established, measured, and reported.

At a minimum, the Contractor shall:

3.2.1.1 Manage and provide system performance in support of SLAs, Interface Control Documents (ICD), and System Interface Agreements (SIA). (Ref: Table 6: Deliverable 018)

3.2.1.2 Assist in the development and maintenance of an SLA, ICD, and SIA for existing and new interfaces.

3.2.1.3 Plan for changes to SLA, ICDs, and SIAs when there is a change to the system or external interfacing systems. Ensure data transfers are executed according to existing SLA, ICDs, and SIAs in a timely manner with accurate data.

3.2.1.4 Manage and provide performance of system interfaces including web services. (Ref.: Table 6: Deliverable 018)

3.2.1.5 Measure performance based upon agreed to parameters set in the SLA, ICD, and SIA. Results are due in a Software Core metrics that are reported at each SETR Event. (Ref.: Table 6: Deliverable 020)

3.2.1.6 Perform the Contractor roles and responsibilities per approved SLAs and participate in the update of SLAs.

3.2.1.7 Authoritative Data Source (ADS) Reporting

The MCTIMS program capability relies on high quality data from the Training and Education Command (TECOM) ADS. Issues with the data such as missing data, incorrect data, etc., can degrade the performance of the MCTIMS system. The Contractor’s priority shall be to notify the TECOM ADS POCs of the data problems and assist the TECOM ADS POCs in determining the courses of action to resolve the data problems. The Contractor shall document the ADS data issue in its trouble ticketing system to include information describing the ADS data issue, when and how it was identified, and when and how it was resolved. This information shall be reported in the MSR. (Ref.: Table 6: Deliverable 013)

3.2.2 Continuity Management

IT Service Continuity Management (ITSCM) provides a framework for developing IT infrastructure recovery plans in support of business continuity management. The Contingency Plan outlines the roles, responsibilities and processes to be enacted in the case of circumstances preventing the continuity of the system. MAC III Sensitive systems have an expectation of being available to its users within a certain timeframe following a downing event. MCTIMS shall maintain Continuity of Operations and Confidentiality in accordance with DOD instruction 8500.2 for a MAC Level III Sensitive system.

3.2.2.1 The Contractor shall implement a system recovery plan that meets with Government approval in accordance with DODI 8500.2.

3.2.2.2 Conduct risk assessment of IT services to identify the assets, threats, vulnerabilities and countermeasures for each service.

3.2.2.3 Evaluate the options for recovery.

3.2.2.4 Test, review, and revise the continuity section within the System Maintenance and System Administration Manual as needed.

3.2.3 Capacity Management

Capacity Management is responsible for ensuring that IT infrastructure resources are in place or available to satisfy planned needs and that those infrastructure assets are effectively used. Capacity Management is responsible for identifying anticipated growth demands. Activities in this area are proactive rather than reactive and focus on finding application and infrastructure bottlenecks at current and future demands so that corrective actions can occur before service issues are experienced by MCTIMS users.

At a minimum, the Contractor shall:

3.2.3.1 Monitor the performance and throughput of the system.

3.2.3.2 Perform analysis of measurement data, including analysis of the impact of new releases on capacity and system performance.

3.2.3.3 Manage the demands on the service and future plans for growth (or shrinkage).

3.2.3.4 Respond when performance falls below acceptable performance levels.

3.2.3.5 Influence demand for computing resources.

3.2.3.6 Conduct risk assessment of infrastructure and planned capacity needs to be integrated into the Contractor’s overall risk management process.

3.2.4 Availability Management

Availability Management is responsible for ensuring application systems are up and available. The process ensures Government system availability requirements are being achieved and ensures the most cost-effective contingency plans are put in place and tested on a regular basis to ensure Government availability needs are met.

The Contractor shall ensure that the Production, Beta, and Training Environment instances are operational and properly configured when needed to support a particular event.

At a minimum, the Contractor shall:

3.2.4.1 Provide service (system) availability meets System users’ expectations.

3.2.4.2 Maintain system operational availability as defined in the applicable TO.

3.2.4.3 After award, within the Systems Maintenance Plan and Administrative Manual, prepare and provide for planned outages and restoration after an unplanned outage. (Ref.: Table 6: Deliverable 009)

3.2.4.4 Identify potential service availability issues.

3.2.4.5 Provide input to the Failure Reporting and Corrective Action System (FRACAS): the examination of past outages to identify related CIs, the CI’s impact on availability, and future corrective action(s). (Ref.: Table 6: Deliverable 014)

3.2.4.6 Provide Obsolescence Management to integrate processes, methods, and procedures to ensure that products can be supported over their complete life time.

3.2.4.7 Conduct system maintenance in accordance with the System Maintenance and System Administration Manual. (Ref.: Table 6: Deliverable 009)

3.2.4.8 Support the maintenance of all software and hardware required for the system. This includes all technology refreshes, software upgrades, patch releases, and maintenance releases as defined in the PM APPS CMP 3rd and 4th octet changes.

3.2.4.9 Maintain and update MCTIMS Production, Training, and Beta sites in accordance with System Maintenance and System Administration Manual. (Ref.: Table 6: Deliverable 009)

3.2.4.10 Conduct failover tests to the Disaster Recovery / Continuity of Operations site as required by DoD Instruction (DoDI) 8500.2.

3.2.4.11 Host facility service issues: the MCTIMS hosting facility (MCEITS) provides critical services required for the MCTIMS system to achieve its high availability. The Contractor’s priority shall be to notify the hosting facility POCs (as documented in the MCTIMS SLA) of issues including outages and other system anomalies. The Contractor shall document the service issue in the trouble ticketing system to include information describing the service issue, when and how it was identified and subsequently resolved. These service issues will be reportable in the MSR. (Ref.: Table 6: Deliverable 013)

3.3 Sustainment Logistics

Sustainment logistics focuses on lifecycle supportability. At a minimum, the Contractor shall:

3.3.1 Provide Asset Management support by identifying expiring Government-furnished or third-party software licenses and warranties a year in advance for the

Government to replace or renew the license or warranty to prevent loss of service.

3.3.2 Provide End User Training and maintenance of WBT. Sustainment training is required to maintain the minimum acceptable level of proficiency or capability required for the System User to accomplish the mission objectives. (Ref.: Table 6: Deliverable 010) At a minimum, the Contractor shall:

3.3.2.1 Keep all system user training materials up to date.

3.3.2.2 Maintain and update all WBT tools so that the modules accurately reflect the latest deployed production system and current policies.

3.3.2.3 Develop tests to demonstrate the users’ understanding and proficiency of the subject and material covered at the end of a training course.

3.3.2.4 Provide Field Service Representatives (FSR) to provide end User Training and on-site trainer led courses to Marines and user personnel. The FSR should be available to travel to both within the Continental United States (CONUS) and Outside the Continental United States (OCONUS) locations outlined in the applicable TO. The anticipated travel locations are listed in the travel section. (Ref.: Table 8) The “home bases” for the FSRs are Camp Lejeune, NC and Camp Pendleton, CA. Note that Camp Lejeune and Camp Pendleton have dedicated Government provided facilities available for conducting classes.

4 Software Development All software development initiatives that impact the system baseline are governed by the CM process as defined in the SDP and PM APPS 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.

4.1 Software Development Plan (Ref.: Table 6: Deliverable 025) 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 PM APPS 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 SETR tailoring based in the 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 and PM APPS Management Plans.

· 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 (HSI), logistics, and cybersecurity into each stage of the software development process.

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

4.1.1 Provide derived requirements, update Requirements Traceability Matrix (RTM). (Ref.: Table 6: Deliverable 001)

4.1.2 Design software, detailed in the System/Subsystem Design Description (SSDD). (Ref.: Table 6: Deliverable 002)

4.1.3 Develop software, detailed in the Software Build Plan. (Ref.: Table 6: Deliverable 003)

4.1.4 Test software, detailed in a Software Test Plan. (Ref. Table 6: Deliverable 004)

4.1.5 Deploy Software. (Ref.: Table 6: Deliverable 005)

4.1.6 Data driven Department of Defense Architecture Framework (DoDAF) compliance views (as necessary per TO).

4.2 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 is classified as either a second (2nd) octet or major or third (3rd) octet minor change. For all New Capability Requirements (classified as a first (1st) octet capability change), the TO shall ensure and provide the following in accordance with the specified level of SETR tailoring based on the ECP classification level:

4.2.1 Requirements Analysis Phase

The key objective of the Requirements Analysis Phase (RAP) 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 use environments and identified system characteristics to determine requirements for system functions.

At a minimum, the Contractor shall:

4.2.1.1 Elicit derived requirements.

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

4.2.1.3 Maintain traceability between the derived and Government-provided requirements.

4.2.1.4 Align requirements analysis efforts with MCSC acquisition requirements (PM APPS Management Plans and SETR process).

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

4.2.1.6 Document the functional baseline. System Source Code will be documented in the CITDB.

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

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

4.2.2.2 Align the Contractor’s process with the PM APPS Management Plans and the MCSC SETR process for Preliminary Design Reviews (PDR) and Critical Design Reviews (CDR).

4.2.2.3 Provide documentation needed to support the PDRs/CDRs.

4.2.2.4 Document the Allocated and Product Baselines.

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

4.2.3.1…