SMS_CMS_PWS_FY14-18_-_9_May_13_(DRAFT).pdf

UNCLASSIFIED

PERFORMANCE WORK STATEMENT

FOR

SINGLE MOBILITY SYSTEM (SMS)

and

COALITION MOBILITY SYSTEM (CMS)

Prepared by

USTRANSCOM

PROGRAM MANAGEMENT OFFICE

8 May 2013 ii

Table of Contents

1.0 DESCRIPTION OF SERVICES

1.1 Background

1.2 Scope

1.2.1 SMS

1.2.2 CMS/CTL

1.3 Applicable Documents

1.4 Requirements

1.4.1 Task Area 1: Contract Level and Task Order Management

1.4.2 Task Area 2: Software Development, Sustainment, and Testing

1.4.3 Task Area 3: Operations Support and Training

1.4.4 Task Area 4: SMS/CMS/CTL Help Desk Support

1.4.5 Task Area 5: Sustainment of the Air Force Reserve Command (AFRC) SMS module

(Optional Task): (LH CLIN)

1.4.6 Task Area 6: CMS/CTL Hosting Environment

1.4.7 Task Area 7: SMS Migration to a virtual environment supporting

Infrastructure, Platform, and/or Software as a Service.– OPTIONAL TASK

1.4.8 Task Area 8: Security Engineering and Cyber Security Requirements

1.4.9 Task Area 9: Configuration Management

1.5. Deliverables

1.5.1 Delivery Process

1.5.2 Warranty

1.5.3 Inspection

1.5.4 Final Acceptance

2.0 SERVICE DELIVERY SUMMARY

2.1 SMS Service Delivery Summary

2.2 CMS Service Delivery Summary

3.0 GOVERNMENT-FURNISHED PROPERTY AND SERVICES

3.1 Government Furnished Equipment

3.2 SMS/CMS Government Furnished Information

3.3 Military Network Connectivity

4.0 GENERAL INFORMATION

iii

4.1 Place of Performance

4.2 Travel and Other Direct Costs

4.2.1 Travel

4.2.2 ODC Requirements

4.3 Period of Performance

4.4 Contract Manager

4.5 Contractor Employees

4.6 Quality Assurance

4.7 Requirements Affecting Contractor Personnel Performing Mission Essential Services

4.8 Handling of Non-Public Information

4.9 Acquisition Streamlining

4.10 Standards

5.0 SECURITY (PHYSICAL, PERSONNEL, INFORMATION,

ANTITERRORISM / FORCE PROTECTION AND INDUSTRIAL

SECURITY)

5.1 General Security Information

5.2 Personnel Security Requirements

5.3 Facilities Clearance Level

5.4 Personnel and Facilities Clearance Validation

5.5 CAC Issuance Procedures

5.6 Scott Air Force Base/USTRANSCOM Physical Access

5.7 Visits to USTRANSCOM Buildings

5.8 Security Training

5.9 Additional Security Conditions

5.10 Derogatory Information

5.11 Accessing NATO Information

5.12 Security Debriefing

5.13 Cyber Security Requirements

6.0 CONTRACTOR TRANSITION

6.1 Exit Requirements

6.2 Ramp Up Time

iv

APPENDIX A: 5-Year Forecast

APPENDIX B: NONDISCLOSURE AGREEMENT & AGREEMENT TO

DISCLOSE POTENTIAL CONFLICTS OF INTEREST

APPENDIX C: DD FORM 254

APPENDIX D: IAWIP CERTIFICATION REQUIREMENTS

APPENDIX E: CONTRACT DATA REQUIREMENTS LIST

APPENDIX F: ACRONYMS

1.0 DESCRIPTION OF SERVICES

1.1 Background

The United States Transportation Command (USTRANSCOM) provides global air, land, and sea transportation for the Department of Defense (DoD), both in times of peace and war through its

Transportation Component Commands (TCCs): Air Mobility Command (AMC); Surface

Deployment and Distribution Command (SDDC); and Military Sealift Command (MSC).

USTRANSCOM provides synchronized transportation, distribution, and sustainment, which makes possible projecting and maintaining national power where needed with the greatest speed and agility, the highest efficiency and most reliable level of trust and accuracy.

The SMS is the primary system used to view requirements, plan missions, and track execution.

It provides the user with information from systems such as: the Air Mobility Command (AMC)

Global Decision Support System (GDSS) and Consolidated Air Mobility Planning System

(CAMPS); the Air National Guard (ANG) Management Utility (ANGMU); the Integrated Data

Environment (IDE) / Global Transportation Network (GTN) Convergence (IGC); the Joint

Operations Planning and Execution System (JOPES); and numerous other feeder systems.

USTRANSCOM requires Contractor-provided Information Technology (IT) services and related support to sustain SMS operations.

The SMS provides USTRANSCOM's C2 capability and augments the multi-system environment currently used for assigning mobility missions. Utilizing its automated C2 system interfaces, SMS significantly reduces the amount of offline interface required between C2 agencies and broadens the range of information available to them as decision makers. SMS improves the flow of mobility mission information from the TCCs to USTRANSCOM, aiding in the decision making process.

USTRANSCOM, United States Pacific Command (USPACOM), and the Office of the Secretary of Defense sponsored and funded the development of CMS as a Joint Capability Technology

Demonstration (JCTD). CMS resides inside the Coalition Theater Logistics (CTL) portal and provides for rapid coordination of Coalition movement planning and execution by providing the capability to observe data for aircraft, ship, road and rail movements (military and commercial) in support of coalition operations. One of the recurring lessons learned from Operation Iraqi

Freedom and Operation Enduring Freedom (OIF/OEF) is the persistent need for visibility regarding logistics movements for the Coalition war-fighter. The CTL provides permissions, administrative controls and user access to CMS and the Humanitarian Expeditionary Logistics

Program (HELP).

SMS and CMS share data via an interface. SMS sends US data to CMS while also picking up coalition data for display to US SMS users. While CMS only exists in the unclassified environment, the data it sends to SMS is automatically pushed to the high side by SMS.

While CMS is designed to download mobility data from foreign national systems via the transfer of XML files, it currently has no active interfaces with any system other than SMS. CMS does play a role in DOD’s Unclassified Information Sharing strategic plan and interaction with the All

Partners Network (APAN) and other multinational and interagency systems is expected. The number of users is increasing as CMS becomes better known in the international and interagency community.

The primary CMS customer base will be Foreign National (FN) personnel assigned to coalitions supported by the United States. Other customers include U.S. Government and Non-

Government Organization (NGO) personnel within and outside the DOD. The Federal

Emergency Management Agency (FEMA), the American Red Cross, and state and local police agencies are examples of targeted CMS users.

1.2 Scope

The purpose of this contract is to provide specialized systems engineering and technical services in support of SMS and CMS/CTL. While this effort is one contract, tasks between SMS and

CMS/CTL are funded separately, and therefore work shall be allocated separately towards each program. SMS and CMS/CTL are expected to function as currently designed with only functional and technical enhancements being included in this performance work statement

(PWS). The Contractor shall plan for all tasks identified in this PWS and gather all pertinent information. Contractor estimates and timelines shall be determined based on the deliverable due dates specified in Section 1.5. The Contractor shall coordinate with the Government to ensure that all activities are well synchronized and integrated with other USTRANSCOM and distribution management efforts. All reports, studies, or policies identified in the PWS shall be prepared and submitted for Government approval or acceptance. All functions and activities shall be task driven and work performed shall be in accordance with (IAW) all applicable regulations and guidelines.

1.2.1 SMS

This effort will include sustainment of the current system and development of Emergent

Requirements (EmR). SMS has reached Full Operational Capability (FOC). The program is in sustainment with only limited enhancements to its current capability. In addition, support is necessary to build and maintain user accounts, train customers, and build or modify SMS data filters and reports.

1.2.2 CMS/CTL

CMS/CTL currently resides in a DIACAP certified commercial cloud environment. The

Contractor shall manage CMS/CTL in this environment or propose migration to another cloud environment that is DIACAP certified. This effort will also include support necessary to build and maintain user accounts, train customers, and build or modify CMS/CTL data filters and reports. The Contractor shall not be responsible for the development or maintenance of other applications within the CTL unless specified in this PWS. Work requires integrating current or future applications and maintaining that integration into the CTL shall be required.

1.3 Applicable Documents

The following documents are applicable to this PWS and are current as of the date of production.

The Contractor is responsible for all changes and updates to these references:

CJCSI 6510.01F, INFORMATION ASSURANCE (IA) AND COMPUTER NETWORK

DEFENSE (CND), Feb 9, 2011

DODI 8570.01-M, Change-2, Information Assurance Training, Certification and

Workforce Management, Jan 24, 2012

DOD MIL-HDBK-881C, Work Breakdown Structures for Defense Materiel Items, July

30, 2005

DODI 3020.37, Continuation of Essential DOD Contractor Services During Crises, January 26, 1996

DODI 8520.2, Public Key Infrastructure and Public Key Enabling, May 24, 2011

DODI 8551.1, Ports, Protocols, and Services Management, August 13, 2004

DODI 8510.01, DOD Information Assurance Certification and Accreditation Process, November 28, 2007

DODI 8582.01, , Security of Unclassified DOD Information on Non-DOD Information

Systems, June 6, 2012, National Institute of Standards and Technology (NIST) Special Publication 800-53, Revision 3, Recommended Security Controls for Federal Information Systems and

Organizations, May 1, 2010

Security Regulation Guidance:

DOD:

DODD 2000.12, DOD Antiterrorism Program, March 1, 2012

DODD 8500.01E, Information Assurance, April 23, 2007

DODI 2000.16, December 8, 2006 (DOD Antiterrorism Standards)

DODI 5200.08-R, Change-1, DOD Physical Security Program, May 19, 2010

DODM 5200.01,volumes 1-4, DOD Information Security Program, February 24, 2012

DODD 5200.2, , Personnel Security Program, April 9, 1999

DODI 5220.22, National Industrial Security Program, March 18, 2011

DODI 8500.2, Information Assurance Implementation, February 6, 2003

USTRANSCOM:

USTC 31-2 (Security Classification Guide)

USTC 31-11 (USTRANSCOM Security Program)

Scott Air Force Base (SAFB): SAFB Instruction 31-101 (Installation Security

Instruction)

Forms: DD 254, DOD, Contract Security Classification Specification

DOD publications, directives, and instructions listed above are available at:

http://www.dtic.mil/whs/directives/corres/pub1.html

CJCS 6510.01F is available at:

http://www.dtic.mil/cjcs_directives/index.htm

NIST 800-53 is available at:

http://csrc.nist.gov/publications/PubsSPs.html http://www.dtic.mil/whs/directives/corres/pub1.html

1.4 Requirements

1.4.1 Task Area 1: Contract Level and Task Order Management

This task consists of the functional activities relating to the administration and management of this effort. The Contractor shall provide program management for all Contractor tasks, personnel resources and costs and ensure all deliverables meet schedule and budget constraints under this PWS. The Contractor shall designate a principal point of contact for technical/engineering issues. The Contractor shall provide support in the specific areas outlined below:

a. The Contractor shall provide a centralized program management capability at the Contractor site. This function shall encompass administrative, clerical, documentation, and related functions that provide general support for the program.

b. The Contractor shall provide support by preparing documents such as required briefings, point papers and meeting minutes related to status of the performance of this PWS.

c. The Contractor shall provide support in the specific areas outlined below in this PWS. The

Contractor shall work with the SMS and CMS/CTL Program Office, process owners/ stakeholders, Federal and DOD Government representatives, and other Contractors to accomplish required tasks.

d. All decisions regarding Government requirements or Government actions will be made by

Government personnel and the Contractor’s representative will submit required evaluations and recommendations to the Contracting Officer’s Representative (COR) and/or Contracting Officer

(CO) for further action.

e. The contractor shall report ALL contractor labor hours (including subcontractor labor hours) required for performance of services provided under this contract for US Transportation

Command via a secure data collection site. The contractor is required to completely fill-in all required data fields at http://www.ecmra.mil. Reporting inputs will be for the labor executed during the period of performance for each Government fiscal year (FY), which runs 1 October through 30 September. While inputs may be reported any time during the FY, all data shall be reported no later than 31 October of each calendar year. Contractors may direct questions to the

CMRA help desk.

1.4.1.1 SMS and CMS/CTL Task Order Management Plan and Software Development

Plan

The Contractor shall prepare an integrated (i.e., Government and Contractor) Task Order

Management Plan (TOMP) to include a Work Breakdown Structure (WBS) that defines tasks, resources, and dependencies. Guidance and acceptable formats for the WBS is contained in

DOD Handbook MIL-HBK-881C, Chapters 2, 3 and Appendix B. The TOMP shall also describe the technical approach, organizational resources, and management controls employed to meet the cost, performance, and schedule requirements throughout contract execution. The

Contractor shall prepare a Software Development Plan (SDP) that contains the technical details of the development requirements of this PWS as well as the configuration management controls essential to proper software development control. The Contractor shall deliver the TOMP and the SDP 20 business days after contract award. After the initial submission the Contractor shall provide the updated TOMP and SDP 20 business days after start of each contract period.

Deliverables:

1.4.1.1.a SMS TOMP w/ WBS/timelines and risk assessment http://www.ecmra.mil/

1.4.1.1.b SMS SDP

1.4.1.1.c CMS TOMP w/ WBS/timelines and risk assessment

1.4.1.1.d CMS SDP

1.4.1.2 SMS and CMS/CTL Monthly Status Report (MSR)

The Contractor shall provide a Monthly Status Report, which will include information on both

SMS and CMS. The MSR shall outline the status of the task order to date. The MSR shall list, by each active task area, the accomplishments of the reporting period. The report shall list issues, problem areas, and items that require Government action. The MSR shall also contain a report of the costs incurred to date and whether they comply with the contract delivery schedule and burn plan. The MSR format will be agreed upon by the COR and the Contractor and shall contain, but is not limited to, the following information:

• Activities conducted and results

• Deliverables

• Trip report to include name of traveler, trip location and purpose, estimated and actual travel costs, and dates of travel

• Meetings attended with a summary of relevant items discussed

• Proposed activities

• Risk assessment and mitigation recommendations

• Open issues

• Actual and projected cost expenditures

• Labor hours/costs by task and labor category (for LH CLINS only)

• Key personnel changes

• SMS and CMS system availability and outages

• Security summary analysis and assessment results

• Training statistics and evaluations

• Account management statistics

• Help desk metrics to include the number of trouble calls, fixes, open items, analysis, and trends

The Contractor shall deliver the MSR by the 10 th calendar day of the month.

Deliverables:

1.4.1.2.a SMS Monthly Status Report

1.4.1.2.b CMS Monthly Status Report

1.4.1.3 SMS and CMS/CTL Integrated Product Team (IPT) Meetings The Contractor shall participate in IPT meetings at the Government site or via telephone conference as required by the Government (once a week). Meeting topics include updates on work in progress, requirements management, metrics (monthly), Integrated Master Schedule

(IMS) (monthly), upcoming calendar events, help desk issues, and other pertinent issues. The

Contractor shall deliver IPT minutes within five (5) business days upon completion of the IPT.

At a minimum, the IPT minutes shall reflect a record of discussion activity, decisions made, date, locations, and attendees.

1.4.1.3.a SMS IPT Attendance & Minutes

1.4.1.3.b CMS IPT Attendance & Minutes

1.4.1.4 SMS and CMS/CTL Technical Interchange Meeting Support

The Contractor shall participate in TIMs and project working groups when called; develop agendas and prepare minutes for each meeting. The Contractor shall develop draft Engineering

Change Proposals (ECP) for requirements being considered by the Configuration Control Board

(CCB). The ECP shall provide a description of the requirement and proposed technical solution, along with the proposed cost and schedule. TIMs shall be scheduled as needed. At the

Government’s discretion, the TIM and IPT may be combined. The Contractor shall deliver TIM minutes within five (5) business days upon completion of the TIM.

Deliverable:

1.4.1.4.a SMS TIM Attendance & Minutes (LH CLIN)

1.4.1.4.b CMS TIM Attendance & Minutes (LH CLIN)

1.4.1.5 SMS and CMS/CTL Trip Reports

The Contractor shall submit a trip report to include the following details: purpose, location and length of trip, travelers, and individuals contacted during trip, synopsis of all discussions, future actions identified, decisions made, or issues of concern arising during trip. This trip report should be an appendix to the MSR. If no travel was conducted during the period, the Contractor shall identify that no travel occurred.

1.4.1.6 Requirements Management

The Contractor shall be responsible for facilitation and administration of the SMS and CMS/CTL requirements management process. The Contractor shall comply with paragraphs a through c below.

a. When available, the Contractor shall utilize the Government’s Requirement Management Tool

(RMT) to input, track, trace, and manage requirements and supporting documentation. The

Government’s RMTs are composed of IBM’s Rational RequisitePro, ClearQuest, and ClearCase.

The Government shall provide the Contractor access to these tools and the Contractor employees shall be familiar with use of these tools. The Government will not provide IBM Rational

RequisitePro, ClearQuest, and ClearCase training to the Contractor. The Government will maintain and utilize these tools to monitor the requirements management process.

b. In the case where the Government’s RMTs are not available at the beginning of the period of performance, the Contractor shall follow a Contractor-provided internal requirements management process and use tools that can transition to the Government’s RMTs to input, track, trace, and manage requirements and supporting documentation. Upon the availability of the

Government-provided tools, the Contractor shall have thirty (30) business days to transition to the Government-sponsored environment. The end state will have all open and historical baselines and requirements loaded into the RMTs. The Contractor shall load the current baseline and any open requirements within the first 30-business day transition period. The Contractor shall have one hundred and twenty (120) business days to transition all historical baselines and requirements into the RMTs.

c. The Contractor shall manage the activities necessary to receive, verify, analyze, refine, and confirm requirements provided by the SMS and CMS/CTL Program Manager (PM). The

Contractor shall also manage the activities necessary to maintain the SMS and CMS/CTL requirements baseline, track requirements status, maintain requirements versions, maintain requirements attributes, control requirement quality and consistency, perform change impact analysis, and provide reports.

The Contractor shall provide a requirements impact assessment to include an analysis of level of effort, impacts to program costs and program schedule. The Contractor shall deliver the impact assessments five days prior to the Change Working Group (CWG) or as required for emergent requirements.

Deliverables:

1.4.1.6.a SMS Requirements Management and Impact Assessments

1.4.1.6.b CMS Requirements Management and Impact Assessments

1.4.1.7 Project Tracking

The Contractor shall develop a project-tracking plan to include percent complete for each SMS and CMS/CTL project/release identified by the USTRANSCOM program manager. The

Contractor shall provide estimated cost and estimated hours for each ticket in the associated release. The Contractor shall work with USTRANSCOM program and Functional Managers to identify milestones that may affect a given project plan. The Contractor shall deliver the project tracking plan 15 business days after identification of the project and/or release.

Deliverables:

1.4.1.7.a SMS Project-tracking Plan

1.4.1.7.b CMS Project-tracking Plan

1.4.2 Task Area 2: Software Development, Sustainment, and Testing

1.4.2.1 SMS Software Maintenance

The Contractor shall modify the existing SMS software to fix software errors identified and documented by incident reports. The Contractor shall modify the existing SMS software to implement system enhancements prioritized by the Government as identified in the configuration control board (CCB). The Contractor shall ensure the SMS software maintains compatibility and interoperability with architecture standards, security requirements, and current operating system, web server, and database versions. Additionally, the Contractor shall perform any required maintenance on all inbound and outbound interfaces. Contingency software maintenance shall incorporate out-of-cycle software releases on an as-required basis as required by the SMS CCB.

A major release is defined as any release requiring the program to seek a new Authority to

Operate (ATO) from the Designated Accrediting Authority (DAA) or an expiration of ATO.

Examples of this would include new or changed security software, new interfaces, version updates to major system software components (Operating System and Database) or new application capabilities. A minor release is any release that is an update to an existing ATO (e.g.

updates to existing software). A major or minor release can occur in a planned or unplanned release.

1.4.2.1.1 SMS System Releases

a. The Contractor shall field up to two (2) scheduled SMS software releases and one (1) out-of-cycle release per year. The Contractor shall also field occasional patches as required. The

Contractor shall modify the existing SMS exercise software to maintain compatibility and interoperability with the exercise environment with each scheduled or out-of-cycle release or patch. The SMS CCB plans the scheduled releases or patch as needed and prioritizes the release or patch contents.

Scheduled releases will be limited to:

Emergent requirements (functional or technical enhancements only)

Fixes driven by embedded COTS including operating systems and data base changes

Security patches

Externally driven interface changes (Including SMS design modifications to accommodate feeder/receiver system changes)

Out-of-cycle releases can account for system maintenance, emergent requirements, unplanned software changes (Oracle patches, etc) or failures. The Government may substitute an equivalent scheduled release to replace an unused out-of-cycle release as determined by the CCB.

Patches are short notice small scale fix actions that require changes to application code to support maintenance, minor software changes, outages or failures in the application. The

Government does not consider this type of change a release. The Contractor shall deliver a description of the software change NLT 5 business days before install. The software change description can be delivered via email.

For a major release, the Contractor shall deliver the draft scan results, source code, interface documentation, and release notes 90 calendar days prior to release. For a minor release, the

Contactor shall deliver the draft scan results, source code, interface documentation, and release notes 60 calendar days prior to release. For both major and minor releases, the Contractor shall deliver the final scan results, source code, interface documentation, and release notes 30 calendar days prior to release.

In the event of a contingency that requires an out-of-cycle release without enough time to meet the schedule listed in the deliverable table identified in Para 1.5.1-1, through the mutual agreement of both parties, the Government and the Contractor will draft a deliverable schedule specific to that release.

b. SMS Interface documentation

1) The Contractor shall develop all applicable interface documentation for any new interfaces with external systems, or update existing documentation for existing interfaces. The Contractor shall develop or update Memorandum of Agreements (MOA) with external partners, Interface

Requirements Definition Documents (IRDD), Web Service Definition Language (WSDL) and

XML Schema Documents (XSD) as necessary to support new and updated interfaces

1.4.2.1.1.a Engineering Hours for Software Maintenance (LH CLIN)

Deliverables: 1.4.2.1.1.b Version Description Document (VDD)

1.4.2.1.1.c Scan Results

1.4.2.1.1.d Source Code

1.4.2.1.1.e Interface Documentation

1.4.2.1.1.f Release Notes

Deliverables, Scheduled: A Version Description Document (VDD), draft scan results, repaired and cleaned scan results, complete source code, interface documentation, and release notes shall be delivered for each scheduled release.

Deliverables, Out-of-Cycle: VDD, draft scan results, repaired and cleaned scan results, complete source code, interface documentation, installation instructions, and release notes shall be delivered for each Out-of-Cycle release.

1.4.2.1.1.1 SMS Emergent Requirements (EmR) (LH CLIN)

The Contractor shall develop software solutions for SMS emergent requirements (EmR) as determined by the Government and in accordance with the current SMS Software Development

Document. In this contract, EmRs are defined as operational enhancement added to the application due to critical user needs. In the past, these tasks have included situational visualization displays and analytical processes (modification of metrics). The intent is for EmRs to be few in number and may not be included in every release. The SMS CCB determines EmR priorities and software release schedules. The Government will be solely responsible for determining or approving Government requirements.

1.4.2.1.1.2 SMS Interoperability and Supportability

The Contractor shall ensure all documentation deliverables provide support certification of SMS as interoperable by the Joint Interoperability Test Command (JITC) process, as defined in

Chairman of Joint Chief of Staff Instruction (CJCSI) 6212.01F and CJCSI 3170.01E. All documentation delivered must meet recommendations and guidelines defined in DOD Instruction

8330 (draft as of Oct 2012) as well as CJCSI 6212.01F and CJCSI 3170.01E. The Contractor shall comply with the most current version of each reference.

The Contractor shall review the SMS JITC documents (architecture diagrams and ISP/TISP) a minimum of once per year. Required updates or creation of JITC documents shall be delivered

60 calendar days prior to a major release . If no updates are required for a specific release, the

Contractor shall notify the COR. Documents shall be in accordance with instructions listed in the above paragraph. All documentation created or updated is to be compliant to DoDAF 2.0 format or most current version of this reference. The Contractor shall be responsible for creation of all Net-Ready Key Performance Parameters (NR-KPP) for use during JITC testing and documentation.

SMS will be required to undergo JITC testing for all interfaces and web services between late

FY14 and early FY15.

1.4.2.1.1.2.b Labor hours for JITC testing (LH CLIN)

Deliverable:

1.4.2.1.1.2.a Updated SMS ISP/TISP and associated architecture documents

1.4.2.1.1.3 SMS Users’ Manual

The Contractor shall update the current SMS users’ manual to reflect any pertinent changes made to the system during each scheduled (2) and each out-of-cycle release (1) per year. Pertinent changes are all changes that affect how the user operates or interfaces with the system.

Administrative and non-pertinent changes shall be tracked and implemented during the next update including pertinent changes. The SMS users’ manual shall be uploaded to the SMS website as an available download for all users. The SMS users’ manual will be updated at a minimum of once a year. When pertinent changes are required, the Contractor shall deliver the users’ manual on the day of the release. In the event of a contingency release, the Contractor shall deliver the users’ manual five days after the release.

Deliverable: Updated SMS Users’ Manual

1.4.2.1.1.4 SMS System Administrator’s Manual (SAM)

The Contractor shall update the current SAM to reflect any pertinent changes made to the system during each of the two (2) scheduled or one (1) out-of-cycle releases. Pertinent changes are all changes that affect how the system administrator operates or interfaces with the system. The

Contractor shall deliver the draft SAM 15 calendar days prior to the release. The Contractor shall deliver the final SAM shall be delivered on the day of the release. In the event of a contingency release, the Contractor shall deliver the SAM on the day of release.

The SAM is a living document and should be updated to reflect the most timely and effective procedures. The SAM shall include information on topics such as:

Installation procedures and configuration options and associated definitions

System maintenance, updates, and upgrade policies, operating procedures, error recovery and schedules

Database schema, network topology, and flowcharts used to illustrate items such as system designs, data communications, program logic, and the relationships between network nodes

Instructions for opening/closing and starting/stopping applications, devices, and services under various conditions

Frequently asked questions and troubleshooting techniques for common issues

Roles, responsibilities, and contact information for key personnel and support staff

Other miscellaneous and/or relevant items

Deliverable: Updated SMS SAM

1.4.2.1.1.5 SMS Availability/System Performance

Availability for the SMS system excludes all measures of failure rates for the commercial

Internet, Defense Automatic Addressing Service (DAAS), customer e-mail systems, and DISA’s and USTRANSCOM hosting infrastructure. Availability based on customer access to SMS information and measured by Operational Availability (A0), which is the ratio of time information is available to the customer to total time. Calculate A0 as follows:

A0 = MTBDE/(MTBDE + MDT)

MTBDE is the Mean Time Between Downing Events. A downing event is any software failure that prevents user access to any of the SMS minimum operational performance requirements.

The SMS system shall meet system performance of A0 >99.4% (an average of 4.5 hours per month).

Maximum Down Time (MDT) should not exceed a total of 8 hours in any single month.

1.4.2.1.1.6 Exposure of Web Services – (LH CLIN)

The Contractor shall enhance the capability of exposing system data through web services such that the data is accessible, discoverable, and usable. The application layer will serve as a point of discovery for the services as well as making the services a truly services oriented architecture

(SOA) and universal to any system looking to utilize SMS data. Consideration shall be given to the Government’s need to extract the requested data in a variety of formats and will utilize the

SMS WS02 service bus. The Contractor shall develop terms and conditions that define the extract formats for use by consumers and publish this information in a WSDL / XSD for each web service.

In exposing web services, the Contractor shall utilize enterprise standards and specifications to include standardized vocabularies. In addition, the services shall be built at the highest level of need to know to allow for multiple users, and if needed, easily extended to capture new data requirements. The Contractor shall also create the user interface (UI) for each web service. This

UI shall be similar in nature to that of the existing SMS interface, and be exportable to external systems requiring the services via Iframes. Interfaces and web services will minimize or eliminate the use of mobile code as much as possible. Additional functionality beyond SMS current capabilities is not required; the UI must only replicate existing capabilities.

The prioritized list of potential SMS functionality to make available as web services Each description listed below equates to existing functionality within SMS. The services for each function will replicate and make available via Iframe to a USTC portal framework and will make data available to external consumers who do not required the UI. Additional detail on the requirement for each service will be provided as part of the SMS CCB process.

Description Network

JALIS/OSA Mission Filter NIPR/SIPR

Air Cost Calculator NIPR/SIPR

DV Mission Board NIPR

Mission Summary- Pax Cargo Info NIPR/SIPR

Station Monitor NIPR/SIPR

IC3 Scheduling and reporting SIPR

Major Movement Group Report SIPR

SMS Tracker SIPR

ULN Closure SIPR

Port Workload SIPR

ULN Status SIPR

Air Sustainment Summary Report NIPR

SAAM Workload NIPR

TPFDD Analysis SIPR

Opportune Airlift Search NIPR

SITREP/SPOTREP/FORCEREP NIPR

Sealift Tracker SIPR

Transportation Wizard NIPR

Leading Indicators Report SIPR

Port Cargo Projection Report SIPR

IGC Container Status NIPR/SIPR

CONUS AA&E Movement Filter NIPR

Denton NIPR

BOG Report SIPR

The Contractor shall field these web services in conjunction with the normally scheduled and/or out-of-cycle SMS releases per this PWS. Release contents and dates will be determined by the

SMS CCB.

1.4.2.1.1.7 Situational Awareness and Collaboration (SA&C) (LH CLIN)

SA&C project implements next generation web-based collaboration technologies (Web 2.0) to improve organizational ability to harness the staff’s thinking and reasoning and expose this as shareable knowledge to a wider audience. This is a crucial process to develop situational awareness and understanding for all levels of the organization and ultimately will support the command’s strategic decision making processes. The SA&C suite of tools is user configurable and accessed within the enterprise portal. SA&C provides tabular and geospatial displays of critical information, auto-alerting to individuals and groups based on user defined filters, dashboards for enterprise metrics, and business social-networking functions to connect people to enhance collaboration and knowledge generation.

a. Event and Task Management - provide for the automated capture of significant events from diverse data sources and the manual entry of critical events affecting USTRANSCOM and its components. Additionally, provide for the automated reporting of these events to leadership within USTRANSCOM, its components, combatant commands, services, defense agencies, Joint

Staff, Chairman Joint Chiefs of Staff, and the Office of the Secretary of Defense, interagency and nongovernmental agency partners, and commercial entities. Capability will support access via various platforms, supporting Distribute.mil, various instances of Sharepoint/.net, Joint

Command and Control Common User Interface (JC2CUI) [Global Command and Control

System – Joint (GCCS-J) and Global Combat Service Support System – Joint (GCSS-J)] ozone widgets, other application marketplaces on other platforms, or via messaging formats (micro-messaging, feeds, email, or service calls) in an inclusive, user-configurable knowledge management environment. Expect to develop MOAs, MOUs, and other interoperability documentation, as required, with applicable servicing systems.

b. Social Networking – Provides information and services within the context of individual experiences, attributes, and communities of interest and practice. Uses information from profiles established within various applications in the knowledge management environment, and, when necessary, maintains profile and preference information provided by users or inferred from their histories and other users’ inputs.

c. Geospatial Information System - Provide the ability to view all data with a geospatial component on a map, either by organic capability, or via layers published to other platforms

(JC2CUI, IRRIS, Google Earth, etc.). GIS capabilities will allow drill-down and drill-through from map interfaces to other views of event, assessment, task, collaboration data, and knowledge.

d. Metrics and Alerts - provides immediate notification to users of event changes via the web portal or e-mail updates, and provides for the study of historical data for predictive analysis and business intelligence. Establish a capability where information can be pushed to and pulled by customers by category, topics of interest, utilizing semantic tagging. Enable subscriptions, notifications, and alerts based on attributes of individuals, processes, data, and/or knowledge across the Joint Deployment and Distribution Environment and wider customer enterprise.

RDT&E funding has been allocated for FY14 and FY15 with an expected transition of this capability into SMS and availability to other Enterprise Portals (i.e. Distribute.mil, GCCS-J, etc.). The project requires an interoperable platform to gather automated population of movements, situations/conditions, and assessment data. The Contractor shall further develop capabilities within FusionNet, a portal within distribute.mil, currently housing Event and Task

Management operations, and shall integrate SMS data within FusionNet. The Contractor has the option of developing FusionNet and other SA&C capabilities within the USTRANSCOM

Common Development Environment or the Contractor may integrate this capability into their own development environment and start the integration into SMS early on in the project to ensure a smooth transition at the end of the RDT&E project. Additionally, the Contractor shall research and develop a capability to retrieve key data and information from E-mail and specific

DoD social media applications via semantic technologies. The Contractor shall evaluate and utilize existing software and programs within DoD to improve the cost effectiveness and speed to delivery for this project.

Two (2) FTEs will be provided by the Government to support the SA&C project. These personnel are subject matter experts in the areas of USTRANSCOM operations, knowledge management and business intelligence.

The projected level of effort for this task is 11,520 hours with skill sets in Java, SharePoint, Ozone Widget Framework and Geographic Information Systems.

1.4.2.2 CMS/CTL Software Maintenance

The Contractor shall modify the existing CMS/CTL software to fix software errors identified and documented by incident reports. The Contractor shall modify the existing CMS/CTL software to implement system enhancements prioritized by the Government as identified in the configuration control board (CCB). The Contractor shall ensure the CMS/CTL software maintains compatibility and interoperability with architecture standards, security requirements, and current operating system, web server, and database versions. Out-of-cycle software releases shall incorporate contingency software maintenance on an as-required basis as required by the

CMS/CTL CCB.

A major release is defined as any release requiring the program to seek a new Authority to

Operate from the Designated Accrediting Authority (DAA) or an expiration of the existing ATO.

Examples of this would include new or changed security software, new interfaces, version updates to major system software components (Operating System and Database) or new application capabilities. A minor release is any release that is an update to an existing ATO with examples to include updates to existing software. A major or minor release can occur in a planned or unplanned release.

1.4.2.2.1 CMS/CTL System Releases

The Contractor shall field up to two (2) scheduled CMS software releases and one (1) out-of-cycle release per year. The Contractor shall also field occasional patches as required. The CMS

CCB will plan and prioritize release contents for the scheduled releases and patches.

Scheduled releases will be limited to:

Emergent requirements (Functional or technical enhancements only)

Fixes driven by embedded COTS including operating systems and data base changes

Security patches

Continued technical support needed to facilitate a proper interface / technical relationship between the CTL and CMS, and other applications that may reside in the CTL portal.

Externally driven interface changes (Including CMS/CTL design modifications to accommodate possible current and future system changes required by systems/applications within the CTL).

Out-of-cycle releases may account for system maintenance, emergent requirements, unplanned software changes (Oracle patches, etc) or failures. The Government may substitute an equivalent scheduled release to replace an unused out-of-cycle release as determined by the CCB.

Patches are short notice small scale fix actions that require changes to application code to support maintenance, minor software changes, outages or failures in the application. The

Government does not consider this type of change a release. The Contractor shall deliver a software change description NLT 5 business days before install. The software change description can be delivered via email.

For a major release, the Contractor shall deliver the draft scan results, source code, interface documentation, and release notes 90 calendar days prior to release. For a minor release, the

Contactor shall deliver the draft scan results, source code, interface documentation, and release notes 60 calendar days prior to release. For both major and minor releases, the Contractor shall deliver the final scan results, source code, interface documentation, and release notes 30 calendar days prior to release.

In the event of a contingency that requires an out-of-cycle release without enough time to meet the schedule listed in the deliverable table identified in Para 1.5.1-1, through the mutual agreement of both parties, the Government and the Contractor will draft a deliverable schedule specific to that release.

CMS/CTL Interface documentation

1) The Contractor shall develop all applicable Interface documentation for any new interfaces with external systems, or update existing documentation for existing interfaces. The Contractor shall develop or update Memorandum of Agreements (MOA) with external partners, Interface

Requirements Definition Documents (IRDD), Web Service Definition Language (WSDL) and

XML Schema Documents (XSD) as necessary to support new and updated interfaces

1.4.2.2.1.a Engineering Hours for Software Maintenance (LH CLIN)

1.4.2.2.1.b Version Description Document (VDD)

1.4.2.2.1.c Scan Results

1.4.2.2.1.d Source Code

1.4.2.2.1.e Interface Documentation

1.4.2.2.1.f Release Notes

Deliverables, Standard: A Version Description Document (VDD), draft scan results, repaired and cleaned scan results, complete source code, interface documentation and release notes shall be delivered for each scheduled release.

Deliverables, Out-of-Cycle: A VDD, draft scan results, repaired and cleaned scan results, complete source code, interface documentation, installation instructions and release notes shall be delivered for each Out-of-Cycle release.

1.4.2.2.1.1 CMS/CTL Emergent Requirements (EmR) (LH CLIN)

The Contractor shall develop software solutions for CMS/CTL emergent requirements (EmR) as determined by the Government and in accordance with the current CMS Software Development

Document. In this contract, EmRs are defined as operational enhancements added to the application due to critical user needs. These tasks should include situational visualization displays and analytical processes (modification of metrics). EmRs are intended to be few in number and may not be included in every release. The CMS/CTL CCB determines EmR

1.4.2.2.1.2 Interoperability and Supportability

The Contractor shall ensure all documentation deliverables provide support certification of CMS as interoperable by the Joint Interoperability Test Command (JITC) process, as defined in

Chairman of Joint Chief of Staff Instruction (CJCSI) 6212.01F and CJCSI 3170.01E. All documentation delivered must meet recommendations and guidelines defined in DOD Instruction

8330 (draft as of Oct 2012) as well as CJCSI 6212.01F and CJCSI 3170.01E. The Contractor shall comply with the most current version of the reference.

The Contractor shall review the CMS JITC documents (architecture diagrams and ISP/TISP) a minimum of once per year. Required updates or creation of JITC documents shall be delivered

60 calendar days prior to a major release. If no updates are required for a specific release, the

Contractor shall notify the COR. Documents shall be in accordance with instructions listed in the above paragraph. All documentation created or updated is to be compliant to DoDAF 2.0 format or most current version of this reference. The Contractor shall be responsible for creation of all Net-Ready Key Performance Parameters (NR-KPP) for use during JITC testing and documentation.

CMS will be required to undergo JITC testing for all interfaces and web services between late

FY14 and early FY15.

1.4.2.2.1.2.b Labor hours for JITC testing (LH CLIN)

1.4.2.2.1.2.a Updated CMS ISP/TISP and associated architecture documents

1.4.2.2.1.3 CMS/CTL Users’ Manual

The Contractor shall update the current CMS users’ manual to reflect any pertinent changes made to the system during each scheduled (2) and each out-of-cycle release (1) per year.

Pertinent changes are all changes that affect how the user operates or interfaces with the system.

Administrative and non-pertinent changes shall be tracked and implemented during the next update including pertinent changes. The CMS users’ manual shall be uploaded to the CMS website as an available download for all users. The CMS users’ manual shall be updated at a minimum of once a year. When pertinent changes are required, the Contractor shall deliver the users’ manual on the day of the release. In the event of a contingency release, the Contractor shall deliver the users’ manual five days after the release.

Deliverable: Updated CMS Users’ Manual

1.4.2.2.1.4 CMS/CTL Operation and Maintenance (O&M) Manual

The Contractor shall update the current O&M manual to reflect any pertinent changes made to the system during each of the two (2) scheduled and one (1) out-of-cycle releases per year.

Pertinent changes are all changes that affect how the system administrator operates or interfaces with the system. The Contractor shall deliver the draft O&M manual 15 calendar days prior to a release. The Contractor shall deliver the final O&M manual on the day of the release. In the event of a contingency release, the Contractor shall deliver the O&M manual on the day of the release.

O&M Manuals are living documents and should be updated to reflect the most timely and effective procedures. O&M Manuals shall include information on topics such as:

Installation procedures and configuration options and associated definitions

System maintenance, updates, and upgrade policies, operating procedures, error recovery and schedules

Proper and improper handling and maintenance of different types of equipment

Database schema, network topology, and flowcharts used to illustrate items such as system designs, data communications, program logic, and the relationships between network nodes

Instructions for opening/closing and starting/stopping applications, devices, and services under various conditions

Procedures and sequences describing backup routines, media type, storage locations, and schedules

Security controls for staff, facilities, infrastructure, and emergency response procedures

Frequently asked questions and troubleshooting techniques for common issues

Roles, responsibilities, and contact information for key personnel and support staff

Other miscellaneous and/or relevant items

Deliverable: Updated Operation and Maintenance (O&M) Manual

1.4.2.2.1.5 CMS/CTL Availability/System Performance (on .com)

Availability for the CMS system excludes all measures of failure rates for the commercial

Internet and customer e-mail systems. Availability based on customer access to CMS information and measured by Operational Availability (A0), which is the ratio of time information is available to the customer to total time. Calculate A0 as follows:

A0 = MTBDE/(MTBDE + MDT)

MTBDE is the Mean Time Between Downing Events. A downing event is any software, hardware, or preventive maintenance failure that prevents user access to any of the CMS minimum operational performance requirements. The CMS system shall meet system performance of 97.7% (an average of 17 hours per month).

Maximum Down Time (MDT) should not exceed 20 hours in any individual month with no more than 8 hours in any individual week.

b. The Contractor shall provide a monthly report in the MSR that includes basic performance statistics for the CMS web and database server. Required statistics include Average CPU utilization, Storage Capacity in use, Disk I/O percentage, Network I/O percentage, and average memory utilization. Report format is at the discretion of the Contractor and may include additional data points. Additionally the Contractor shall provide a report showing usage statistics such as logins (organized by day), URLs of all pages that lead to CMS homepage, page hits total, page hits per day, Unique IP’s, average bandwidth per day, and any page failures.

Deliverable: Appendix to MSR with Performance Statistics

1.4.2.3 Contractor Requirement for Achieving Government Specifications at Software

Release

The Contractor shall meet all Government specifications for each requirement at each release.

The PM will make the final decision whether or not to accept all software. Deficiencies will be documented, prioritized, tracked, and may result in non-acceptance of the software release by the

Government. Software must…