DRAFT_M67854-16-R-4805_PDSS_PWS.DOCX
DOCX document 326 KB Posted
- Solicitation number
- M67854-16-R-4805
- Issued by
-
United States Marine Corps
About this file
MCTIMS DRAFT PDSS PWS
View the file
Other files
| File | Type | Posted |
|---|---|---|
| DRAFT_Exhibit_2_-_Past_Performance_Questionnaire.docx | DOCX document | |
| DRAFT_Exhibit_1_-_Past_Performance_Statement.docx | DOCX document | |
| DRAFT_M67854-16-R-4805_ECP_PWS.DOCX | DOCX document | |
| MCTIMS_DRAFT_Solicitation_M67854-16-R-4805.pdf | ||
| DRAFT_M67854-16-R-4805_IDIQ_PWS.DOCX | DOCX document | |
| DRAFT_M67854-16-R-4805_Att_5_-_Pricing_Workbook_20160505_ctc_-_Protected.xlsx | XLSX spreadsheet | |
| DRAFT_M67854-16-R-4805_QASP.DOCX | DOCX document |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Marine Corps Systems Command Program Manager Information Systems & Infrastructure
Total Force Information Technology Systems (TFITS) Marine Corps Training Information Management Systems (MCTIMS) Post Deployment Software Support (PDSS) Performance Work Statement
May 2016
Table of Contents
| 1 | Introduction | 4 |
| 1.1 | Purpose and Scope | 4 |
| 1.2 | Background | 4 |
| 1.3 | TFITS Management Plans | 5 |
| 1.4 | Reserved | 5 |
| 1.5 | Reserved | 5 |
| 1.6 | Contractor Performance | 5 |
| 1.7 | Objectives | 5 |
| 2 | Transition | 6 |
| 2.1 | Objectives of the Transition | 6 |
| 2.2 | Transition-In Period | 7 |
| 2.3 | Transition-out Period | 8 |
| 3 | Post Deployment Software Support (PDSS) | 10 |
| 3.1 | Service Support | 10 |
| 3.2 | Service Delivery | 19 |
| 3.3 | Sustainment Logistics | 25 |
| 4 | Software Development (Reserved) | 26 |
| 5 | Project Management | 26 |
| 5.1 | Project Management | 26 |
| 5.2 | Task Management | 29 |
| 5.3 | Performance Management | 31 |
| 5.4 | Contract Closeout | 31 |
| 6 | Configuration Management Plan | 31 |
| 7 | Integrated Master Schedule. | 31 |
| 8 | Performance Standards. | 31 |
| 9 | Applicable Documents and References. | 33 |
| 10 | Deliverables and Schedule. | 35 |
| 11 | Government Furnished Information and Equipment | 37 |
| 12 | Security Requirements | 37 |
| 13 | Common Access Cards | 37 |
| 14 | Place of Performance | 38 |
| 15 | Period of Performance | 38 |
| 16 | Travel and Other Direct Costs (ODC) | 38 |
| 17 | Appendix A. Acronyms | 42 |
List of Figures Figure 1: MCTIMS Modules 5
List of Tables
| Table 1: MCTIMS Program Attributes | 20 |
| Table 2: Data Transfer | 21 |
| Table 3: Meeting Requirements | 28 |
| Table 4: Key Milestones | 31 |
| Table 5: Performance Standards | 32 |
| Table 6: Program Documentation | 33 |
| Table 7: System Documentation | 33 |
| Table 8: TFITS Management Plans | 34 |
| Table 9: Other Guidance and Standards | 34 |
| Table 10: PDSS Deliverables | 36 |
| Table 11: Potential Travel Locations for MCTIMS Training | 39 |
Marine Corps Training Information Management Systems PDSS Performance Work Statement
Introduction Purpose and Scope The Production Manager (PdM) Total Force Information Technology Systems Product Office (TFITS) provides acquisition oversight for a portfolio of USMC systems and has a requirement for Post Deployment Systems Support (PDSS) and limited Software Development for the Marine Corps Training Information Management System (MCTIMS) program. MCTIMS falls under the TFITS Headquarters, Sustainment, and Training (HST) Tier. The vendor shall provide PDSS, system maintenance and performance upgrade services and logistics support for MCTIMS as defined in this PWS.
The scope of this PWS covers the full range of PDSS and 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 MCTIMS is an automated, Common-Access-Card (CAC) enabled, web-based system consisting of individual 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 recording training for individual Marines and units against training standards identified in the Training and Readiness Manuals, Military Occupation Specialty (MOS) Manual and Formal School Program of Instruction. MARADMIN 085/17 dated 18 February 2016, directs the utilization and standardization of the MCTIMS Unit Training/Individual Marine Management module across the total force.
MCTIMS supports 57 formal learning centers and training detachments and interfaces with other IT systems within the Marine Corps and with other services across the Department of Defense (DoD) 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 (UTM) processes throughout the total force. MCTIMS must interface with the Defense Readiness Reporting System-Marine Corps (DRRS-MC), the Pre-deployment Training Program (PTP) Toolkit, and the Marine Corps Total Force System (MCTFS).
The MCTIMS application is currently hosted in the Marine Corps Information Technology Center (MCITC) in Kansas City, MO.
Figure 1: MCTIMS Modules TFITS Management Plans Table 8 on page 34 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 Reserved Contractor Performance The contract shall be performed in accordance with this PWS and the Government’s Quality Assurance Surveillance Plan (QASP). Additionally, the contract 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).
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 MCTIMS system 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, web-based training, etc.) updates, and any required certifications/accreditations shall precede the deployment of any capabilities where available in the government provided tool.
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 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 no later than 30 days after contract award.
Objectives of the Transition The objective of the transition period is to ensure the Contractor is equipped with the knowledge and resources necessary to perform PDSS. This means 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 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:
Existing engineering and technical documentation.
The Contractor shall acquire the required level of system knowledge through the assimilation of information available in existing engineering and technical documentation.
The Contractor shall identify and mitigate any engineering and technical knowledge gaps.
Existing user documentation.
The Contractor shall acquire the required level of system functional expertise through the assimilation of information available in existing user documentation.
The Contractor shall identify and mitigate any user documentation knowledge gaps.
Contractor System Instantiation 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, Contractor System Instantiation includes:
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 hardware installation and configuration, software installation, and application configuration. The Contractor’s hosting environment shall be representative of the constraints and limitations of the production environment.
Test & 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.
Critical PDSS Activities The Contractor shall provide a detailed and executable plan to transfer on-going service support and service delivery activities from the incumbent Contractor.
At a minimum, this includes:
Database administration;
System administration;
Cybersecurity;
System interfaces;
Help desk;
Web-based Training (WBT) modules, training, and training materials Transition-In Period Transition Activity with the Government and Contractor Incumbent The Contractor shall, at the start of the period of performance, engage in the following activities throughout a 30-day transition period:
Obtain administrative access, from the current Contractor, to the system as well as system interfaces.
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.
Schedule and attend up to five days of observing the current Contractor during the 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.
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.
Schedule, plan, provide agenda and minutes, and participate in up to three 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.
Conduct a Transition Readiness Review to formally establish the Contractor’s readiness to fully transition the subject system.
Transition-out Period Transition Activity with the Government and the Incoming Contractor The contractor shall, at the completion of the period of performance, engage in the following transition activities with the incoming contractor throughout a 30 day transition period:
The incumbent contractor shall baseline the system and system documentation.
Baseline activities shall, at a minimum, consist of the following:
Physical Configuration Audit (PCA) or Validation of the PCA deltas.
The incumbent contractor shall support the Government PCA in accordance with Marine Corps System Command (MCSC) Technical Review Handbook v1-04, and all TFITS Management Plans in Table 8.
Closure of all critical Action Items or critical Requests for Action Baseline documentation shall, at a minimum, consist of the following:
Configuration Item Technical Database (CITDB).
All deliverables as identified in the system(s) CITDB, system(s) contract, and PWS.
Software Source Code or Software Source Code location for future delivery Regression test driver codes and test scripts, test data and benchmark results matched to software release version number.
Government data in Contractor licensed tools.
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/PMM (Information Systems and Infrastructure (IS&I)/PdM TFITS).
The incumbent contractor shall implement all applicable Information Assurance Vulnerability Alert (IAVA) patches, as well as Government funded Engineering Change Proposal (ECPs). Open IAVA patches and ECPs designated in the Transition Readiness Review will be the responsibility of the incoming contractor.
Assist incoming contractor with getting required access to support MCTIMS; for example, administrator user Identification (IDs) and passwords, database user IDs and passwords, and all system(s) interfaces.
Provide incoming contractor with all established and current points of contact (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.
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.
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.
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.
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.
Participate in Transition Readiness Review.
Post Deployment Software Support (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.
The Contractor shall provide a PDSS Support Schedule that shows the anticipated activities the Contractor plans to perform in executing PDSS.
Service Support Development and Contractor Test Hosting Environment The Contractor shall create and maintain a development and test hosting environment that functionally reflects the system production environment.
The Contractor provided environment shall include all hardware and software necessary for the development and integration testing necessary to support MCTIMS. The Government will provide as GFE the HP Fortify Tool, or Government provided alternative, for system code reviews. Government Acceptance Testing (GAT) will be conducted in MCEITS Zone A environment.
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 for 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. The Contractor shall observe industry “best practices,” such as Information Technology Infrastructure Library (ITIL) v3 with the objective to receive, track, communicate (status to the user) and resolve user calls.
The Contractor shall assess its current help desk approach and provide a report with recommendations on migrating current help desk support to the Government’s BMC Remedy tool. At contract closeout, the Contractor shall provide a migration plan for any open help desk tickets not contained within the Government provided tool.
At a minimum, the Help Desk shall provide and consist of the following:
Respond to, complete, and close help desk requests.
Capture, track, investigate, escalate, resolve, close and report user help requests.
The Contractor shall use the existing government provided tool. Data includes: the caller’s name; work location; time of receipt of the call; the nature of the call, the time of resolution; and a brief statement of how the problem was resolved to record each user’s help request/trouble call. The Contractor has the ability to add data it feels is necessary to improve its ability to manage the help request.
Elevate help requests that cannot be resolved within four hours.
The help desk shall be available 0730 –1700 Eastern, Monday through Friday, excluding Federal Holidays.
The Contractor shall provide a help desk phone number, voicemail and email address. Currently, the help desk can be reached by email at MCSC_MCTIMS_Support@usmc.mil.
Resolve system access issues and assist system users in basic system functions.
Escalate requests beyond the capability of the help desk to resolve to more advanced support personnel.
Incident Management The primary focus of Incident Management is the restoration of services following an incident. Incident Management is primarily a reactive process; its processes provide guidance on diagnostic and escalation procedures required to quickly restore services. Incident Management processes are closely integrated with help desk, problem management, and change management processes.
At a minimum, Incident Management shall:
Detect and record incident details.
Perform incident management including proactive performance monitoring, incident identification, diagnosis, isolating, containment, eradication, recovery, and lessons learned.
Track incidents reported from the system users, the host site, and external interfacing systems.
Identify and report functions and files affected.
All availability issues shall be communicated to the Government Project Manager , TECOM Advocates, and the MCTIMS user community within one hour of discovery.
Resolve incidents to support system operational availability.
Restore existing system and data Restore system to full operational capability.
Prioritize incidents in terms of impact and urgency with the objective to minimize user impact.
Assess type and severity (e.g., number of users affected) of incident.
Assess impact to data integrity.
Reduce unplanned downtime hours.
Identify incident impact to the Government.
Recommend ratings for the priority and the urgency of each incident.
Inform the Government of the restoration of services and effects of the incident to the user community.
Immediately escalate incidents that require expertise not available in the currently assigned Tier.
Provide Help Desk verification that the incident is closed and the system user is satisfied with solution.
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 incidents and proactive in identifying and preventing future incidents. The Contractor’s processes are closely integrated with Incident Management, Change Management, 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.
At a minimum, the Contractor shall:
Analyze historical data to support predictive analysis to eliminate potential incidents before they occur and to identify work-arounds.
Maintain historical data in BMC Remedy for all service problems.
Use a trouble ticket log to develop an analysis of trends to identify potential problems.
Provide the Government the results of problem trends in the Monthly Status Report (MSR).
Diagnose root cause and eliminate recurrences.
Provide the Government the potential causes of problems in its historical data.
Using historical data, provide the Government the Contractor’s approach for preventing problems from recurring.
Prioritize problems, in terms of impact and urgency, to minimize system user impact.
At a minimum, the Contractor shall:
Assess and provide type and severity (e.g., number of users affected) of problem.
Assess and provide impact to data integrity.
Reduce unplanned downtime hours.
Identify problem impacts to the Government.
Recommend the priority and the urgency to be assigned to each problem.
Inform the Government of the restoration of services and effects of the incident to the user community.
Develop workarounds or other solutions to incidents.
At a minimum, the Contractor shall:
Identify potential problems from the analysis of historical data.
Develop innovative workarounds and solutions to problems.
Present workarounds to the government for consideration and approval for implementing an ECP.
Identify, develop and submit ECPs to Change Management to eliminate known problems.
Configuration Management (CM) Configuration Management (CM) processes guide the collecting, archiving and reporting of individual infrastructure component specifications. The Configuration Item Tracking Database (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 for MCTIMS 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 TFITS CMP.
At a minimum, the Contractor shall:
Maintain the CITDB utilizing the approved TFITS CITDB format.
The Contractor shall maintain the current data base containing the details of each system component. Configuration Items (CI) contained within the CITDB include Hardware, Software, Interfaces, Tracelinks and Documentation. (Note: A Common Access Card (CAC) is required to access the CITDB).
Provide a method for controlling changes to the CITDB.
Identify new CIs and enter them into the CITDB.
At a minimum, the Contractor shall:
Provide identification, collection, tracking and maintenance of each unique CI comprising the system and sub-systems.
Perform change control processes that enable definition of the functional and physical characteristics of CIs in sufficient detail that they may be categorized.
Enable and implement the identification of the system items, components and related work products that will be placed under CM.
Track and maintain Government submitted CIs in the CITDB.
Propose CIs which the Contractor deems necessary or offer significant benefit to the Government.
Collect, record and maintain accurate information about CIs.
At a minimum, the Contractor shall:
Track and record the status of CIs.
Respond to government questions about system change approaches, estimated costs and schedules, as well as technical questions related to the program.
Establish and implement configuration control and approval processes required to change a CI’s attributes and re-baseline the CIs.
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 hosted in the MCITC Data Center located in Kansas City, MO. Assessment of changes to the infrastructure requires coordination between the host site, the user community, Marine Corps Systems Command (MCSC), and the Contractor.
The Contractor may propose changes but must receive approval from the Government to execute ECPs.
The Contractor shall ensure and provide that its change management processes align with the TFITS management plans.
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 Configuration Control Boards (CCBs).
Perform ECP assessments for risk, complexity, and potential user benefits prior to CCB meetings so they can be prioritized for submission into the next major release.
Maintain and update Contractor specific data elements of the Government’s ECP Tracker System. (Note: Requires a CAC).
Provide a level of effort (LOE) to include the lifecycle hours for ECPs at the ERB. Provide a rough order of magnitude (ROM) detailed lifecycle estimate for those ECPs approved by the CCB.
At a minimum, the Contractor shall:
Identify, research, develop and classify ECPs.
Provide a lifecycle LOE estimate for hours and effort required to complete ECPs.
Provide ROM detailed lifecycle estimate for ECPs approved by the CCB.
Identify application code defects as well as functional and performance defects, and submit ECPs as appropriate.
At a minimum, the Contractor shall:
Identify and resolve the defect and ensuring the system is working as designed.
Use quality assurance processes to reduce software defects.
Utilize software development processes to reduce software defects.
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:
Provide all technical and non-technical aspects of a release, including the update and maintenance of system baselines, system documentation, user documentation, and training documentation.
At a minimum, the Contractor shall:
Provide technical aspects such as: regression testing; testing documentation; remediation of identified defects; the update of system documentation, configuration status, accounting data; and information assurance system scanning.
Provide non-technical aspects such as: coordinating system changes with the host facility; identifying the needed training; updating user documentation including training documentation; and preparing release notes and version description document.
Plan and support the successful roll-out of software and related hardware including the required Contractor test and evaluation, and Government acceptance processes.
At a minimum, the Contractor shall:
Provide a repeatable training, test, and deployment strategy and schedule for planned enhancements and upgrades.
Create and deliver Test Plans and Test Scripts that are traceable to requirements.
Monitor Government Acceptance Tests (GAT) and collect Test Incident Reports (TIRs).
Submit GAT Scorecards reflecting all completed test scripts, remaining test scripts, number passed, number failed, and status of failed tests.
Resolve all Severity 1 (Showstopper) and 2 (High) TIRs and other critical issues and update system documentation prior to test completion.
Manage, integrate, and deploy upgrades upon Government acceptance (including production environment regression testing).
Schedule releases in coordination with the Program Office to determine optimal release window to minimize impact to end users.
Design, implement, and support efficient procedures for the distribution, installation, and verification of changes including the client application.
Coordinate and prepare the Advocate and system user community for new release capabilities.
At a minimum, the Contractor shall:
Provide user training documentation, technical documentation, and other user support material within sufficient time prior to deploying a software upgrade.
Provide a system notification to all system users prior to implementing any release.
Ensure implementations are traceable, secure, and that only correct, authorized, and tested versions are installed.
Coordinate and plan releases with Change Management.
Provide master copies of all software and update the CITDB.
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), plan of action and milestones leading up to monthly 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.
Support the Government Post Implementation Review (PIR) in accordance with TFITS Management Plans.
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 MCO 5239.2A (or latest version as identified in the Task Order) 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 support the transition to the Risk Management Framework, DoD Instruction 8510.01. The level of protection will be aligned with Mission Assurance Category (MAC) III Sensitive.
At a minimum, the Contractor shall:
Maintain the MCTIMS ATO, review and update all related documentation (including, but not limited to, the Systems Information Profile, DIACAP Implementation Plan, Cyber Engineering Plan), and fulfill all annual cybersecurity requirements for a MAC III Sensitive program.
Provide all DoD information system Cybersecurity-related documentation is current and accessible to properly authorized individuals.
Provide awareness and prevention through assessment and implementation of best practices (system scans, vulnerability alerts, vendor notifications, and STIGs).
At a minimum, the Contractor shall:
Implement cybersecurity best practices to increase the security of the system and eliminate vulnerability threats to include code reviews, system scans, vulnerability alerts, vendor notifications, and STIGs.
Provide all security updates and patches are tested and applied to software and operating systems.
Provide all vulnerabilities identified by the Hosting Facility’s vulnerability scans are incorporated and mitigated.
Conduct code software quality, software code assurance and code reviews with automated tool(s) provided by the Government.
Provide Cybersecurity risk analysis to include identification and mitigation of cybersecurity risks to GOTS software.
Facilitate, participate in, and provide timely completion of Annual Security Reviews, Annual Security Control testing, Annual Contingency Plan testing, and quarterly update and submission of Plan of Action & Milestones (POA&M) updates in compliance with the Federal Information Security Modernization Act (FISMA).
Use the Government’s Information Assurance tool, Marine Corps Certification and Accreditation Support Tool (MCCAST), to submit, maintain, and review C&A/A&A documentation and workflow. The Government will assist in gaining access to the tool as well as training for the tool.
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 complete and submit DADMS questionnaires as required.
Facilitate the protection of U.S. Government sensitive, unclassified, and classified information by working closely with the Government Information Systems Security Manager, Information Systems Security Officer, and staff.
Implement vulnerability assessment remediation and tracking per Information Assurance Vulnerability Alerts (IAVA), Information Assurance Vulnerability Bulletins, Information Assurance Vulnerability Management, and Operational Directives.
Confirm compliance of annual IA awareness training.
Review vulnerability assessment scans provided and provide technical guidance on remediation (including use of STIGS), and develop POA&M.
At a minimum, the Contractor shall:
Provide monthly identification of vulnerabilities and remediations in accordance with Communications Tasking Order (CTO) 08-005 Scanning and Remediation and DoDI 8510.01.
Request and maintain an MCCAST account (requires a CAC and .mil email account) and ensuring all documentation is uploaded and up to date.
Review documentation, support pre-assessment, review vulnerability scans, test result evaluation, and review POA&M for Independent Verification and Validation test events as necessary.
Review documentation, support pre-assessment, review vulnerability scans, evaluate test results, and review POA&M for Command Cyber Readiness Inspection events.
Enterprise Development and Test Hosting Environment (Reserved) Service Delivery Service Delivery processes assist in the identification of delivered or provided services, tailoring of services, the timely provision of services, resources, capabilities, and capacities to meet MCTIMS’s needs.
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 (SLAs) 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:
Manage and provide system performance in support of SLAs, Interface Control Documents (ICDs), and System Interface Agreements (SIAs).
Assist in the development and maintenance of an SLA, ICD, and SIA for existing and new interfaces.
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.
Manage and provide performance of system interfaces including web services.
Measure performance based upon the parameters set in the SLA, ICD, and SIA, report results.
At a minimum, the Contractor shall:
Report results of performance metrics to the Government as defined in the TFITS management plans and QASP.
Link performance metrics to risk assessments.
Provide mitigation strategies for risk and issues affecting performance
1.1.1.1 Authoritative Data Source (ADS) Reporting
The MCTIMS program capability relies on high quality data from the 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 determine 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.
MCTIMS Program Attributes The following table provides information on the attributes of the MCTIMS program.
Table 1: MCTIMS Program Attributes
| Attribute |
| Description |
| Operating Environment |
| MCTIMS is a web-based system with a centralized database. |
| Web Server |
| The operating system for the MCTIMS application web servers is Windows 2008 Server. The Web Server uses Microsoft Internet Information Services (IIS). The Web application, which runs on the server, is programmed in .Net that utilizes C#, ASP.Net, Java Script, HTML, XML and XSLT. The web code is compiled into DLLs |
| Application Server |
| The operating system for the MCTIMS application web servers is Windows 2008 Server. The application code is in .NET which utilizes C#, ASP. Net, Java Script, HTML, XML and XSLT. The application code is compiled into DLLs |
| Database Server |
| The operating system for the application database servers is Red Hat Linux v 5.X. The database is Oracle 11g (11.2.0.4). Database level application code is contained in stored procedures, packages, functions, views, and triggers written in PL/SQL |
| Reporting Server |
| The operating system for the MCTIMS application reporting server is a Windows 2008 Server. The reporting database is Oracle 11g. Database level application code is contained in stored procedures and views written in PL/SQL. The Reporting Server utilizes Cognos ReportNet 10.2.1, a COTS product, to produce customer reports for MCTIMS users |
Data Interfaces, Transfers and Exchanges MCTIMS planning and execution functions are designed to interface with external data sources (shown below in Table 2) to either obtain data, publish data, or a combination of both, as needed to perform the necessary job function. The adapters used for the current environment reflect the identification of external systems requiring both input and output interfaces with MCTIMS and the need to be able to import and export data from other sources that cannot be accessed directly. The SIAs are established for each application interface to define the automated interface and the specific data and data formats to be exchanged. Interfaces will be maintained in the Government owned CITDB and presented in the System/Subsystem Design Description as defined in the Marine Corps System Engineering Technical Review Handbook.
Table 2: Data Transfer
MCTIMS DATA INTERFACE EXCHANGE
Data Source/ Interface Partner
| Periodicity |
| Inbound/ |
Outbound Type of Info Exchanged/ Transferred
| Advance Skills Management (ASM) |
| Weekly |
| Outbound |
| ASM pulls Formal school completion data |
| Army Training Requirements and Resources System (ATRRS) |
| Daily |
| Inbound/ Outbound |
| MCTIMS sends Marine registrations; ATRRS sends course/class schedule, quota and completions |
| Corporate Enterprise Training Activity Resource System (CeTARS) |
| Daily |
| Inbound/ Outbound |
| MCTIMS sends Marine registrations; CeTARS sends course/class schedule, quota, and completions |
| MarineNet |
| Daily |
| Inbound |
| MarineNet sends course completion |
| Defense Manpower Data Center (DMDC) |
| Monthly |
| Outbound |
| MCTIMS sends school, course, and class schedules |
| Defense Readiness Reporting System (DRRS) |
| Weekly |
| Outbound |
| MCTIMS sends USMC Task List |
| Marine Corps Recruiting Information Support System (MCRISS) |
| Daily |
| Inbound |
| MCRISS sends new recruit personnel information |
| Marine Corps Total Force System (MCTFS) |
| Daily |
| Outbound |
| MCTIMS sends course completions on MCTFS cycle days and PFT, CFT, Rifle, Pistol, Swim, MCMAP, Height Weight Body Fat, Local Schools, Weight Control, Off-Duty Education daily |
| Military Personnel Data System (MilPDS/AFIPPS) |
| Daily |
| Inbound |
| MilPDS sends course/class schedule |
| Operational Data Store Enterprise (ODSE) |
| Daily |
| Inbound |
| MCTIMS pulls personnel information to support schools |
| Manpower Models (MODELS) |
| Daily |
| Inbound/ Outbound |
| RDM and MOSTAS pull course/class schedules and seat availability; RDM provides entry level registrations |
| Sailor/Marine American Council on Education Registry Transcript (SMART) |
| Monthly |
| Outbound |
| MCTIMS sends course completions |
| Training and Education Command (TECOM) Website |
| Inactive |
| Outbound |
| MCTIMS sends PDFs of updated MOS Roadmaps |
| Total Force Structure Management System (TFSMS) |
| Twice per year |
| Inbound |
| MCTIMS pulls Force Structure Data |
| Marine Corps Range and Training Area Management System (MCRTAMS) |
| Inactive |
| Outbound |
| MCRTAMS pulls T&R information as it relates to ranges |
| Total Force Data Warehouse (TFDW) |
| Monthly |
| Outbound |
| TFDW pulls school seat and student reservation data |
Continuity Management IT Service Continuity Management (ITSCM) provides a framework for developing IT infrastructure recovery plans in support of business continuity management. MCTIMS shall maintain Continuity of Operations and Confidentiality in accordance with DOD instruction 8500.2 for a MAC Level III Sensitive system. The instruction outlines the roles, responsibilities, and processes to be enacted in the case of circumstances preventing the continuity of the system. Information regarding system recovery plans is found in the Continuity Plan for MCTIMS. The Contractor shall implement a system recovery plan that meets with Government approval. The Contractor shall ensure that, in accordance with DoD Directive 5230.25, all personnel having access to the system will have appropriate security clearance.
The Contractor shall implement a system recovery plan that meets with Government approval in accordance with DODI 8500.2.
The Contractor shall ensure that, in accordance with DoD Directive 5230.25, all personnel having access to the system will have appropriate security clearances.
Conduct risk assessment of IT services to identify the assets, threats, vulnerabilities and countermeasures for each service.
At a minimum, the Contractor shall:
Conduct risk assessments in conjunction with Cybersecurity Management on a scheduled basis.
Identify and provide threats and vulnerabilities upon completion of the risk assessments.
Provide the Government with risk mitigation strategies for identified program risks as well as the monitoring process to evaluate the impact of mitigation efforts.
Test, review, and revise the continuity section within the System Maintenance and System Administration Manual as needed.
At a minimum, the Contractor shall:
Utilize the results of the government approved test in Cybersecurity as required by the DoDI 8500.2 and provide corrective actions for analysis to the government.
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 MCTIMS users experience service issues. This task will require the MCTIMS Contractor to coordinate with the MCEITS team to ensure that capacity issues are being measured using the same tools.
At a minimum, the Contractor shall:
Monitor the performance throughput of the system.
At a minimum, the Contractor shall:
Monitor and collect available system infrastructure metrics identified by the Government.
Provide metric reporting to the Government in the MSR.
Perform analysis of measurement data, including analysis of the impact of new releases on capacity and system performance.
At a minimum, the Contractor shall:
Conduct data analyses Integrate risk management into its assessment process Project future capacity needs and how those projections are incorporated into its capacity management process Manage the demands on the Service and future plans for growth (or shrinkage).
Respond when performance falls below acceptable performance.
At a minimum, the Contractor shall (in conjunction with MCEITS):
Prevent system performance from dropping below acceptable performance levels.
Provide appropriately skilled personnel with the technical expertise to analyze system performance and remediate.
Influence demand for computing resources.
At a minimum, the Contractor shall:
Identify changes in system and user needs for changes in system computing resources.
Prevent the demand for computing resources to exceed deployed system capacities and capabilities.
Conduct risk assessment of infrastructure and planned capacity needs to be integrated into the Contractor’s overall risk management process.
At a minimum, the Contractor shall:
Integrate Capacity Management information within the Contractor risk processes.
Provide the Government with results of risk assessments in the MSR.
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:
Provide service (system) availability meets System Users’ expectations.
Maintain system operational availability at a minimum 95%.
After award, within the System Maintenance Plan and Administration Manual, prepare and provide for planned outages and restoration after an unplanned outage.
Identify potential service availability issues.
At a minimum, the Contractor shall:
Integrate information from other areas of the PWS effort to create a higher-level of understanding of potential availability issues.
Provide recommended resolutions to the Government.
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 actions.
At a minimum, the Contractor shall:
Use personnel with the required technical expertise to collect outage data, rank the outages, determine causes, and provide resolutions to either eliminate or reduce outage frequency.
Escalate problematic CIs and recommended resolutions to the Government.
Provide Obsolescence Management. Comprehensive obsolescence management should integrate processes, methods, and procedures to ensure that products can be supported over their complete lifetime.
Conduct system maintenance in accordance with the System Maintenance and System Administration Manual.
At a minimum, the Contractor shall:
Maintain the System Maintenance Plan. The System Maintenance Plan shall identify and ensure system software is maintained in accordance with manufacturer specifications. If manufacturer specifications do not exist, contractor shall perform maintenance in accordance with industry best practices.
Support the technical requirements of the System Maintenance and System Administration Manual during the life cycle of the system.
Conduct failover tests to the Disaster Recovery/Continuity of Operations site as required by DODI 8500.2.
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 Service Level Agreement) 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.
Sustainment Logistics Sustainment logistics focus on lifecycle supportability.
At a minimum, the Contractor shall:
Provide Asset Management support by identifying expiring Government-furnished 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.
Provide End User Training and maintenance of WBT. The Contractor shall provide sustainment training as required to maintain the minimum acceptable level of proficiency or capability required for the System User to accomplish the mission objectives.
At a minimum, the Contractor shall:
Keep system user training materials up to date.
Maintaining and updating all WBT tools so that the modules accurately reflect the latest deployed production system and current policies. MCTIMS currently has two WBT courses; the End user training WBT is loaded to the MCTIMS website.
Demonstrate user proficiency post conduct of training.
Provide Field Service Representatives (FSRs) to provide end User Training and on-site trainer led courses to Marines and user personnel. FSRs should be available to travel to both CONUS and OCONUS locations. The anticipated travel locations are listed in the travel section. 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.
Software Development (Reserved) Project Management Project Management The Contractor shall prepare a Project Management Plan (PMP). The Government-approved PMP serves as the common understanding between the Government and the Contractor on how the Contract will be managed. The Government fully realizes that the Contractor shall need to periodically revisit and update the PMP to ensure that it accurately reflects the dynamics of managing a Contract of this magnitude. At a minimum, the PMP shall be updated annually and resubmitted to the Government for approval. Other than this annual submission, the Contractor has the latitude to build upon the document content to ensure all aspects of the Contractor’s collaborative project management process are addressed. All additional updates will require approval from the Government.
At a minimum, the PMP shall define and describe the Contractor’s:
Processes Planning: Contract planning,…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .