TFMS_PWS_6_Feb_13.pdf

PERFORMANCE WORK STATEMENT FOR

SURFACE DEPLOYMENT AND DISTRIBUTION COMMAND (SDDC)

Transportation Financial Management System-Military Traffic Management Command (TFMS-M)

6 February 2013

This page is intentionally left blank

PERFORMANCE WORK STATEMENT (PWS)

SDDC

Transportation Financial Management System-Military

Traffic Management Command (TFMS-M)

Table of Contents

SECTION TITLE PAGE

1 DESCRIPTION OF SERVICES 4

2 DELIVERABLES 18

3 SERVICE DELIVERY SUMMARY 21

4 GOVERNMENT FURNISHED EQUIPMENT AND INFORMATION 22

5 GENERAL INFORMATION 23

6 SECURITY 24

7 CYBER SECURITY 28

8 CONTRACT TRANSITION 29

Appendices

A ACRONYMS

B REFERENCED DOCUMENTS

C NONDISCLOSURE AGREEMENT

D GOVERNMENT FURNISHED EQUIPMENT

PERFORMANCE WORK STATEMENT

Transportation Financial Management System-Military Traffic Management Command (TFMS-M)

1.0 DESCRIPTION OF SERVICES

1.1 Background. The Surface Deployment and Distribution Command (SDDC) mission is to provide global surface deployment and distribution services to meet the nation‟s objectives. SDDC is the Army component of the United States Transportation Command (USTRANSCOM) Transportation Component

Commands (TCCs), which includes Military Sealift Command (MSC), and HQ Air Mobility Command

(AMC).

The Transportation Financial Management System – Military Traffic Management Command (TFMS-M) is the Oracle Financials solution. This Performance Work Statement (PWS) is focused on providing technical and functional support to the TFMS-M Program Manager and users, to ensure timely monthly closures of financial activities within TFMS-M, transition of functional configuration issues to the appropriate staff, and provide development and maintenance of TFMS-M Interfaces, SDDC Reporting requirements and System Change Requirements (SCRs) Support. All tasks shall be performed in accordance with (IAW) all regulations and guidelines as referenced in Appendix B.

1.2 Scope. The purpose of this requirement is to provide technical services and related project management support for contractor technical and functional support for TFMS-M. Specifically, TFMS-

M requires technical engineering services to update and maintain software and enhance automation capabilities, maintain/sustain system operations, analyze system changes, and build capabilities within the application.

The Contractor shall assist the Government in managing cost, schedule, performance, security, and risk for TFMS-M related activities and projects. The Contractor shall coordinate with the Government to ensure all activities are well synchronized and integrated with other SDDC and transportation management efforts.

The Contracting Officer‟s Representative/Alternate Contracting Officer‟s Representative (COR/ACOR) will make all decisions regarding Government requirements and priorities. Unless otherwise specified in this PWS, all days are designated as calendar days. The Contractor shall authorize periodic Government inspections and reviews to assure compliance with DOD requirements throughout the contract performance period. The Contractor shall be responsible for taking corrective action based upon the impact and severity of identified weaknesses.

The PWS includes the following task areas:

Task Area 1: Contract Level and Project Management

Task Area 2: TFMS-M Infrastructure and Technical Sustainment

Task Area 3: TFMS-M Enhancements/New Development (OPTIONAL)

Task Area 4: Configuration Management

1.3 Specific Tasks

1.3.1 Task 1: Contract Level and Project Management

This task consists of the functional activities relating to the administration and management of this effort.

The contractor shall provide project management of all projects and tasks within the scope of this contract. The principal project manager shall have oversight of all projects within scope of this contract and shall provide and prepare documents such as point papers, briefings, and meeting minutes related to the status and performance of projects. This task shall also provide administrative and technical support to the other tasks in preparation of deliverables.

The contractor shall provide the required task leadership necessary for the supervision of all contractor staff and coordinate interaction with Government technical and functional leadership. The contractor‟s task leadership shall allocate resources among the key tasking areas to maintain program schedules and ensure timely product delivery. Task Order management activities include:

Ensuring contractor personnel are are appropriately engaged with Government counterparts on those efforts requiring collaboration.

Systematically reviewing task products to ensure each deliverable meets or exceeds Government standards. All work must be compliant with appropriate DOD-approved architectures, program standards, and guidelines.

Identifying high-risk task activities and developing mitigation strategies to meet emerging or unexpected problems for Government review.

Working with the Government to resolve problems and reduce the potential risks. Mitigation strategies which include recommendations for reprioritizaiton of workload/tasks and other contingency or work-around actions will be coordinated and approved by the COR.

Maintaining an Action-Item Tracking System for TFMS-M area of responsibility within the

SDDC enterprise tool which is currently Serena Business Mashups. This should track suspense dates, actions assigned to specific personnel and successful resolution of problems and issues.

Ensuring contract personnel are proficient in the use of management tools for action item tracking, deliverable production, quality assurance, and financial reporting.

1.3.1.1 Task 1 Subtask 1: Weekly Status Reporting (WSR)

The contractor shall provide a WSR no later than close of business each Monday, or the first duty day after a holiday. The Weekly Status Report shall consist of the following:

An update on the status of the various TFMS-M environments (Staging, Development, Test, Training and Production) to include information pertaining to last date cloned.

A detailed status of all open TSRs to include:

o what TSRs have been closed in the past week o what TSRs are ready for production o what TSRs are awaiting functional validation o what TSRs are awaiting feedback from Oracle o a brief synopsis of status of open TSRs

1.3.1.2 Task 1 Subtask 2: Quarterly Program Management Reviews (PMRs)

The contractor shall conduct quarterly PMRs as scheduled by the COR/ACOR to begin the first month of each quarter; meeting typically lasts no more than an hour. The contractor shall present status, progress, recommendations, and concerns in the development of any tasks or documentation described within this

PWS. The PMR shall reflect resolution to prior PMR actions items, new action items, record discussion activity, decisions made, date, locations, attendees, and a copy of the presentation slides. The contractor shall provide the draft PMR slides to the COR and to the TFMS-M Program Manager (PM) no later than two days prior to the meeting, and minutes of the PMR no later than five (5) business days after the meeting.

1.3.1.3 Task 1 Subtask 3: Employment Status Report

The contractor shall provide an employee status report (listing/spreadsheet) containing names and labor categories of personnel supporting the tasks identified in paragraph 1.3. The report shall be provided within thirty (30) calendar days after contract award and updates to the COR/ACOR no later than 4:00

PM central time the first work day of the following week after contractor staffing levels or personnel are changed.

1.3.1.4 Task 1 Subtask 4: Contractor Management Report (CMR)

The Office of the Assistant Secretary of the Army (Manpower & Reserve Affairs) operates and maintains a secure Army data collection site where the contractor shall report ALL contractor manpower (including subcontractor manpower) required for performance of this contract. The contractor shall completely fill in all the information in the format using the following web address:

https://contractormanpower.army.pentagon.mil. The required information includes:

(1) Contracting Office, Contracting Officer, Contracting Officer's Representative

(2) Task order number

(3) Beginning and ending dates covered by reporting period

(4) Contractor name, address, phone number, e-mail address, identity of contractor employee entering date

(5) Estimated direct labor hours (including sub-contractors)

(6) Estimated direct labor dollars paid this reporting period (including sub-contractor)

(7) Total payments (including subcontractor)

(8) Predominant FSC for each sub-contractor if different

(9) Estimated data collection cost

(10) Organizational title associated with the UIC for the Army Requiring Activity (the Army Requiring

Activity is responsible for providing the contractor with its UIC for the purposes of reporting this information)

(11) Locations where contractor and sub-contractors perform the work (specified by zip code in the

United States and nearest city, country, when in an overseas location, using standardized nomenclature provided on website)

(12) Presence of deployment or contingency contract language

(13) Number of contractor and sub-contractor employees deployed in theater this reporting period (by country).

In addition, the contractor shall submit estimated total cost (if any) incurred to comply with the reporting requirement. Reporting period shall be the period of performance not to exceed 12 months ending 30

September of each Government fiscal year and shall be reported no later than 31 October of each year.

Assistance or questions about the CMR may be directed to the CMR Helpdesk by phone at 703-377-6199 or E-mail contractormanpower@hqda.army.mil

1.3.2 Task 2: TFMS-M Infrastructure and Technical Sustainment

The contractor shall maintain, to include „fixing defects‟, application software, tools, capabilities, servers, interfaces and databases, for the TFMS-M application, and related functionality in support of the TFMS-

M user community and the TFMS-M Program Management Office (PMO). The contractor shall apply agile and iterative development methodologies in order to provide capabilities in a timely manner. The contractor shall continuously maintain and update documentation on the architecture of existing interfaces, data and software.

https://contractormanpower.army.pentagon.mil/ mailto:contractormanpower@hqda.army.mil

The TFMS-M application resides within an n-Tier Enterprise Architecture. The two tiers that apply to

TFMS-M are the Application and Database. TFMS-M production, staging (integrated test), and Disaster

Recovery (DR) hardware and software environments are part of SDDC‟s Common Computing

Environment (CCE). Therefore, the program receives operational System Administrator and Database

Administrator support from the CCE‟s support team, the Enterprise Infrastructure Program (EIP). The contractor shall support the EIP team with any application-specific COTS, configuration, and/or program software requirements within these three (3) environments. The contractor shall maintain the development and test environments, but note the possible transition as described in the Information

Assurance task below. .

The contractor shall work with the Government and Contractor Information Assurance Team as designated within SDDC to provide and share system security data and program information. TFMS-M has been designated Mission Assurance Category (MAC) III for the purposes of applying IA controls.

1.3.2.1. Task 2 Subtask 1: TFMS-M Functional Sustainment

The contractor shall ensure TFMS-M tools and applications continue to support SDDC Resource

Management (G8) Financial Transactions and related business requirements, to include:

Oracle Financials

Data Loader

SQL Developer

Tools for Oracle Application Development (TOAD)

Discoverer Reports

The contractor shall sustain existing TFMS-M application, web, database, and technology.

Oracle Financials Support

- The contractor shall assist the functional community in maintaining the configuration and monitor, coordinate, and execute daily interfaces and concurrent requests. The current TFMS-

M configuration includes the following Oracle 11g modules:

o Purchasing o Accounts Payable o Accounts Receivable o Projects o Fixed Assets o Oracle Time and Labor

- The contractor shall Administer the Oracle Workflow capability and provide assistance in troubleshooting workflow issues.

- The contractor shall troubleshoot issues encountered in using the Oracle Wed ADI tool.

Internal and External interfaces

- Defense Travel System (DTS) 821 Inbound

- DTS 810 Inbound

- DTS 824 Outbound

- Transportation Global Edit Table Transportation Account Code (TAC) Line of Accounting

Inbound

- Cargo and Billing System (CAB) Accounts Payable (AP) Inbound

- CAB Daily Revenue Inbound

- CAB Daily Accounts Payable Inbound

- CAB Revenue Outbound

- CAB Check History Outbound

- Corporate Electronic Funds Transfer (CEFT) Inbound

- CEFT Outbound

- Centralized Disbursing System (CDS) Inbound (Rates)

- CDS Outbound Payment File

- CDS Inbound Treasury Confirmation

- Defense Cash Management System (DCMS) Transactions By Others (TBO) Inbound

- DCMS TBO Posting Results Outbound

- DCMS International Balance of Payments (IBOP) Outbound

- Government Purchase Card Inbound

- Defense Civilian Pay System (DCPS) SDA Outbound

- DCPS Gross Pay Inbound

- DCPS Master Employee Record Inbound

700 custom programs (primarily Procedural language/Structured Query Language (PL/SQL) and

UNIX Scripts)

400,000 lines of custom code

400 custom reports, including:

- Request Sets

- Financial Statement Generator (FSG) reports

- Concurrent Program Reports

- Discoverer Reports

The contractor shall update tools and applications as needed to support changes to the TFMS-M information technology or business environments and related business rules. The contractor shall meet with the COR, the PM and/or the Government‟s Configuration Management (GCM) weekly to discuss current capabilities and prioritize any proposed changes to existing Configuration Control Board (CCB) priorities. These meetings are held in the Functional PM‟s conference area at Scott Air Force Base

(AFB).

1.3.2.1.1 Sustain TFMS-M Capabilities

The contractor shall support the Government by managing the TFMS-M application. Application management and administration activities shall include the following:

TFMS Service Requests (TSRs):

Assist the Subject Matter Experts (SME) in refining requirements for the TSR along with troubleshooting issues

Analyze the TSR to determine the timelines and technical approach

Develop and test code to support the TSR

Implement end-to-end software/code that is sufficiently expansible and scalable to incorporate government-designated select functionality

Identify, manage, administer, and analyze risks associated with the TSR

Recommend appropriate actions to mitigate identified risks

Interface Maintenance:

Maintain end-to-end data transfers along with any code changes, enhancements or bug fixes, and record/table layout changes

Maintain or develop scripts to support secure file transfer protocol (sftp) data transfer with interfacing systems using PL/SQL or Unix Shell scripts

Monitor and review the success/failure of interfaces

Ensure technical knowledge transfer for current and future TFMS-M interfaces

Maintain interface memorandum of agreement documents for all TFMS-M interfaces

Workflow Management:

Monitor Oracle Workflow within TFMS-M, to include monitoring processes and solving problems with processes that have timed out or produced errors

Create and maintain custom workflows for TFMS-M requirements such as Project Budgeting, Purchase Order Notifications, Receipt Notifications, Manual Journal Voucher approval and

Requisition approval

Reporting:

Provide assistance to the SMEs on using Financial Statement Generator (FSG) for General

Ledger, Oracle Web Applications Desktop Integrator (Web ADI), and Oracle Discoverer

Assist the Government in resolving errors in existing reports, customizing and/or developing additional reports as identified by the functional community

Application Security:

Provide proactive administration along with auditing user activity

Manage concurrent application processing

Support application users with application connectivity issues

Review vulnerabilities, develop implementation plan, and install patches as they become available

Ensure Database Administrator (DBA) accounts are not used for non-DBA activities.

Application user accounts provide access to application database objects to perform a particular application function to application user accounts. Privileges granted to application user accounts will follow the principle of least privilege and include only those privileges required to perform the assigned function.

Database administration support:

Perform DBA Space Management for database(s)

Recommend changes to the Government

Implement changes within approved time schedule

Maintain optimal database performance

Keep users informed of issues which impact system performance

Ensure the most cost effective use of system resources

Test and apply Oracle security patches

Coordinate with system administrators and functional community

Analyzing table space usage for extents and input/output (I/O) usage and making recommendations for changes to the Government

Performing database backup and recovery operations; ensuring the integrity of the database

Applying Oracle recommended patches and version upgrades

Planning the database growth and tuning the database

Administering Oracle Discoverer, i.e., creating business areas, work books, and developing reports; maintaining control over users‟ access to data, user privileges, and query performance

Maintaining databases, i.e., create databases and table spaces, monitoring table space sizes, managing indexes, administering user roles, performing Ad Hoc queries, and managing archive logs

Planning, testing and implementing Oracle Financial Applications upgrades:

Support test environments

Ensure programming necessary for update of interfaces to meet API changes

Test all software upgrades to database environments as well as working with system administrators in planning, testing application functionality, and implementing any Operating

System upgrades/patches to ensure no adverse system impact results from server changes.

Unix System Administration:

Maintain development application and Data Base (DB) SUN servers to provide a testing and development environment for TFMS-M which closely mirrors the TFMS-M production environment in order to accommodate testing of operating system, Oracle Financial Applications and DB changes, patches and upgrades required by TFMS-M.

System Administrative services should include but not be limited to: basic administration of systems, applications and databases, Unix installation and upgrades, installation of Unix patches, Unix security assessments, backup and recovery, system monitoring and performance, and custom Unix scripting and programming.

1.3.2.1.2 Sustain Existing Documentation

The contractor shall sustain, review and update system documentation, to include database, system, and software/application documentation. Documentation shall be updated with each quarterly release or reviewed at least annually if no quarterly updates were required. Documents shall be delivered within 30 days of each release.

The contractor shall provide an After Action Report (AAR) within two days to the TFMS-M PMO for every system outage, to indicate start and stop time, reason for outage, and solution. The AAR shall follow standard SDDC procedures. The Enterprise Change Control Tool (CCT) is used to capture and automate system outages. Part of its capabilities is to capture the information for an outage and automate its after-action reporting.

1.3.2.2 Task 2 Subtask 2: Disaster Recovery and Contingency Operations

1.3.2.2.1 Maintain Disaster Recovery Environment. The contractor shall complete all required application configurations to ensure TFMS-M is correctly installed and configured to operate at SDDC‟s

Disaster Recovery (DR) site. The DR site is located at a separate Government facility, within a forty-five minute drive from Scott AFB. To ensure operationally correct software, the contractor shall install and configure application software at the DR site within one (1) day of installing and configuring the same software on the Production site.

1.3.2.2.2 Disaster Recovery Plan. The contractor shall update the TFMS-M plan for disaster recovery and contingency operations in coordination with the enterprise Disaster Recovery Exercise (DRE) solution and SDDC‟s CCE. The plan shall include: crisis emergency management (onsite and offsite)

(technical and functional); disaster recovery; pre and post emergency operations requirements; and fail-over management.

1.3.2.2.3 Exercise Operations. The contractor shall participate in the bi-annual SDDC G6 DRE. The exercises are conducted over a one-week period, during normal business hours, no more than twice a year.

1.3.2.2.4 Contingency Operations. The contractor shall provide support to the Government during contingency or emergency operations IAW approved disaster recovery and contingency operations plans.

The contractor shall ensure resources and key personnel are available throughout an emergency IAW the established plan.

1.3.2.3 Task 2 Subtask 3: System Support

1.3.2.3.1 Software and Hardware Maintenance. The contractor shall provide support for database, Office Information System (OIS), application, and hardware in the production, training, staging, test, and development environments hosted within the CCE for TFMS-M. This includes, but not limited to, tuning and performing backups, database tuning and backups, system patching, and other information assurance compliance. The contractor shall load all applications and COTS software within the test and development environments, and assist the Government‟s system administrators in loading application, and COTS software within the Production, Staging, and DRE servers.

1.3.2.3.2 Operational Support. The contractor shall provide a support role to the EIP team in monitoring server and database performance, ensuring connectivity, and complying with all security and certification and accreditation requirements in the staging and production environments. The contractor shall participate in the enterprise change management processes. The contractor shall identify and document current and planned interface, data, software or technical changes. The contractor shall introduce proposed software, interface and technical changes to the contractor‟s Change management

(CM) for promotion and implementation of those changes in the SDDC environment. Supporting the

TFMS-M hardware environment requires knowledge of the following:

Configuration skills within an n-Tier enterprise architecture and network topology

UNIX based servers running Solaris 10

Network Connectivity via NIPRNET and the SDDC Local Area Network (LAN)

Oracle Application Server 4.0.9

Oracle Database Version 11g (11.2.0.2.0)

Oracle E-Business Suite 11.5.10.2

Microsoft Windows Vista/Windows 7 client workstations

The contractor shall be required to test and troubleshoot TFMS-M after CCE outages/upgrades that typically occur during non-duty hours. The contractor will coordinate with the EIP team if they discover any issues after the outage, and may be required to assist the EIP team to restart some services to bring

TFMS-M back to normal operations. Typical CCE maintenance outages occur on alternating Sundays, usually twice each month.

1.3.2.3.3 Functional User Support. The contractor shall provide routine support to TFMS-M users and

SDDC Resource Management to include analyzing and resolving day-to-day operational issues in the

TFMS-M system. The contractor will assist in providing technical configuration knowledge and facilitate knowledge transfer to the Government SMEs to include performing Oracle research on using Oracle

Metalink, opening and tracking Oracle Technical Assistance Requests (TARs), and assisting with data extraction from TFMS-M.

1.3.2.3.4. Tier II and III Support The contractor shall provide Tier II and III support during agency operating hours as defined in 5.1, and have a designated on-call person available for all non-operating hours. Additionally, the contractor shall support the Government by resolving Tier II and Tier III support questions. The contractor will provide input to assist in the enhancement of Help Desk Tier I procedures and operations and will provide feedback to Tier I regarding solution to all tickets that have been escalated in order to permit population of this information into the Help Desk solution database. Oracle

Siebel is the ticketing software currently being used by Tier I. The contractor will be responsible for monitoring impacts on systems and the user community, and provide advice, assistance, and recommendations related to impacts that arise during design, development, implementation, testing, fielding, maintenance, and support of TFMS-M.

1.3.2.3.5 Program Management Support. The contractor shall provide functional and technical support to the TFMS-M PMO. Specific activities shall include:

Providing short-term advisory and technical services to assist Government SMEs with evaluating potential changes to TFMS-M system features and functionality

Planning for integration of new and existing systems with existing architecture to satisfy interface requirements

Providing expert recommendations on problems or validating the approach to resolving functional or technical issues

Preparing Standard Operating Procedures (SOPs) for TFMS-M

1.3.3 Task 3: TFMS-M Enhancements and New Development (OPTIONAL)

Automated information systems may require enhancements to the existing capabilities or the development of new capabilities as functional requirements and operational needs change. Therefore, the contractor shall develop new solutions for the TFMS-M functional community, to include custom databases, new/updated features within E-Business Suite, and reports, to streamline or supplement SDDC business processes. The contractor PM shall attend weekly meetings, and provide weekly feedback, with the

COR/ACOR and the TFMS-M Technical and Functional PMO to review the status of all ongoing updates, repairs and changes to existing capabilities and discuss and validate new workflow solutions using the CCB priorities to track. The contractor shall also follow normal configuration management

(CM) processes as defined in Task 4.

Enhancements to TFMS-M may include, but are not limited to, additional reports to support functional community and new capabilities based on emerging business needs. Typically, routine (minor) changes include changes to Oracle Financial reports, and the addition of new data elements already available within the existing E-Business Suite. Routine changes within the TFMS-M program average less than

160 man-hours to configure and test.

The contractor shall configure and test more complex changes/projects and release on a quarterly basis.

Complex changes average between 940 hours to 1450 hours to develop and test. The WSR shall reflect expected release dates of routine and complex changes. The contractor shall coordinate delays with the

COR/ACOR; significant delays (greater than 10 business days) shall be documented, to include

COR/ACOR signature.

New Development tasks may include, but are not limited to, implementing Financial Improvement Audit

Readiness (FIAR) requirements to ensure FIAR regulation compliance, installation of E-Business Suite

12, and the design and implementation of additional system interfaces.

1.3.4 Task 4: Configuration Management (CM)

The contractor shall provide CM support for the TFMS-M program. The contractor‟s CM processes must complement the Government‟s CM (GCM) processes. The TFMS-M PMO and Contractor‟s

Configuration Manager (CCM) shall work closely with the Government‟s Enterprise Support Services

(ESS) Configuration Manager.

1.3.4.1 Task 4 Subtask 1: CM Planning

The CCM shall provide input to the TFMS-M‟s Configuration Management Plan (CMP) and utilize processes that are consistent with and complement the GCM processes. The TFMS-M program uses the

CMP that defines the Government‟s current CM processes. The contractor shall provide updates to the

CMP to define their developmental CM processes. The CMP includes the following:

Contactor‟s configuration management processes and procedures

Methods, procedures, and controls

Baselines (versioning)

Change control

Configuration status accounting

CM audits of total configuration to include hardware, software, and firmware

CM Repository (Dimensions will be the delivery repository for source code prior to deployment-

Government will provide network connection)

CM Process

1.3.4.2 Task 4 Subtask 2: Change Control

The contractor shall provide change control for all TFMS-M baselines and configuration items to include documentation, hardware, COTS software, application, source, and executable code. The Government will provide the contractor with web access to the SDDC Enterprise Change Control Tool (CCT), currently supported by Serena Business Management (SBM) software. The Government‟s CCT is a tool shared by the TFMS-M PMO staff and the contractor staff and is programmed to support the TFMS-M configuration management process is hosted within the CCE. The contractor shall comply with all G6

CM standards and processes.

The contractor shall evaluate all Change Requests. The contractor shall provide their evaluation upon request. Evaluations include, but shall not be limited to: requirement clarification, requirements analysis, determination if the requirement is feasible, cost (labor hours) estimation, adherence to standards, training impacts, and the consequences of the proposed change. This information shall be provided to the

Government for evaluation via the CCT and as a separate document depending upon the amount of information required or provided. This evaluation shall help the PMO staff and the contractor to determine how many, and which, change requests shall be rolled into each release, and will help to determine dependencies within the software development cycle.

The contractor shall conduct a physical and functional configuration audit of each code baseline/release delivered to the Government. The Government reserves the right to participate in the audits if desired, and will coordinate Government participation with the contractor.

1.3.4.3 Task 4 Subtask 3: Asset Management

The contractor shall provide updates to the Government on laptops and software inventory (as appropriate), warranties, maintenance support agreements, software licensing, and accountability for equipment purchases and upgrades. The Government will maintain and update the enterprise asset database that identifies all existing infrastructure assets, hardware, and COTS software. The contractor shall provide status of baselines, configuration items, and status of all outstanding enhancements and defects.

1.3.4.4 Task 4 Subtask 4: Configuration Control Board (CCB)

The CCM shall participate in the Government‟s CCB. The CCM shall act as the liaison between the

Government and contractor to provide any additional information that the CCB requires. The contractor shall participate in a weekly Enterprise CCB lasting no more than one (1) hour per meeting. Participation will help ensure contractor activities are focused in the areas the Government deems important, and changes within the Government‟s CCE are properly vetted across all affected programs. The contractor shall submit enterprise CCB documentation no later than 2 hours prior to CCB.

The contractor shall participate in weekly TFMS-M CCB meetings. The contractor shall analyze new requirements prior to the meeting and provide information to the Government team in order to prioritize program level requirements. This analysis shall be captured in the CCT. The TFMS-M PM and the CCB will determine the priority for all changes. The PM usually determines the items to be worked for each release cycle. Multiple capabilities may be addressed in any one release cycle, but periodic, agile, releases may encompass several similar capabilities while working to the final stage of any one particular priority. The contractor shall document the TFMS-M CCB minutes, and shall deliver the minutes to the

TFMS-M PMO staff within five (5) business days of the meeting.

1.3.4.5 Task 4 Subtask 5: Source Code Configuration Control (Versioning)

Configuration control will be utilized for all TFMS-M code changes. The current versioning system will be continued unless otherwise authorized by the PMO.

1.3.4.5.1 Base-lined Source Code. The contractor shall provide installation guidance (guide(s)) to the

TFMS-M PMO for installing base-lined code to the CCE‟s Staging environment. The EIP team will use the installation guide(s) to deploy within Staging and within Production. TFMS-M contractor will stand by to assist the EIP with all releases. The contractor shall store base-lined code within the SDDC‟s enterprise software for versioning control prior to release to Production. Currently, the enterprise uses

Serena Dimensions to store Source Code. The method to identify software versions is documented in the

TFMS-M CMP; all versioning shall be coordinated with the TFMS-M GCM

1.3.5 Task 5: Information Assurance (IA)

The contractor shall work with the Government and Contractor Information Assurance Team as designated within SDDC to provide and share system security data and program information.

1.3.5.1 Information Assurance Training

Contract employees shall attend and complete the following security training as prescribed by DOD and

SDDC instructions and update the Army Training and Certification Tracking System (ATCTS) to reflect the current status. All contractor personnel shall create an account in the ATCTS and complete a profile survey. Based on that survey, the contractor shall complete all appropriate IA training.

Annual Training:

- DOD IA Awareness Training

One-Time Training:

- Army Wide Network Security Focus Training (WNSF)

- SAFE Home Computing

- Personally Identifiable Information (PII)

- Portable Electronic Devices and Removable Storage Media

- Phishing Awareness

Specialized Training, required for privileged access:

-Information Assurance Fundamentals (IASO)

-DOD 8570 Baseline Certification and Computing Environment Certification

1.3.5.2 Accreditation Sustainment

The contractor shall provide program specific input for the development of new application security documentation and the updating of existing application security documentation to facilitate the security accreditation of the ISDDC system, and the EDI and SOA environments IAW the current certification and accreditation guidance (current guidance is DODI 8510.01, Department of Defense Information

Assurance Certification and Accreditation Process (DIACAP) - will be migrating to National Institute of

Standards and Technology (NIST) Risk Management Framework model). The contractor shall sustain the application and its environment in compliance with the Defense Information Agency (DISA) Security

Technical Implementation Guides (STIGs). The results of the DISA STIG documentation must always reflect the status of the system; contractor shall provide monthly updates. The contractor shall be required to provide a number of updates to existing certification and accreditation documentation, such as network diagrams, ports and protocol matrix, application certification package created during release cycle, and other existing documentation. This documentation is required whenever changes are made that may affect the security posture of the application environment. The contractor shall provide a monthly update no later than the last business day of the month, to the PM for the application‟s DIACAP Plan of

Action and Milestones (POA&M). POA&Ms are maintained within the Enterprise Mission Assurance

Support Service (eMASS).

1.3.5.3 Government Application Development Environment

1.3.5.3.1 The Government is in the process of establishing an isolated common development environment and facility for all software development and testing to complement the Government‟s common integration and testing environment. Therefore, as this becomes available, the contractor shall assist the

Government in transferring all software development operations to a virtualized, protected Government facility. The contractor shall assist the Government in transferring all needed materials from the contractor‟s environment to the Government‟s environment once it is made operational. After transition, the contractor shall conduct all software development entirely from within this consolidated Government development environment. The contractor shall access remotely from their facilities through a

Government approved VPN connection, from isolated dedicated development workstations that comply with Government security guidelines. Upon completion of transfer and operational status of the

Government‟s environment, the contractor shall cease development activities within their environment and remove all sensitive Government materials and data, and provide Government material and data to the Government for disposition.

1.3.5.3.2 In the Government development environment, the programs will be provided basic Virtual

Machines (VMs) or Solaris Zones that have been locked down IAW DISA STIGs and fully patched. The contractor shall maintain the servers in a fully patched state.

1.3.5.3.3 Use a dedicated computer. The contractor shall use GFE IAW para 4.1 or a Government compliant dedicated computer for remote access to the development environment. This computer shall not be used for other general purpose computing or non-development activities such as e-mail and web browsing, nor to access any network other than the contractor‟s development environment, including the contractor‟s corporate network and the internet.

1.3.5.3.4 Source code, design artifacts and other materials deemed sensitive by the Government shall be maintained ONLY within the isolated development environment.

1.3.5.3.5 Mitigate unauthorized code access. The contractor shall use a source code control system that authenticates access and logs changes to the software baseline.

1.3.5.3.6 Production systems cannot be directly connected to development and testing. If „live‟ data is required in the development and testing environment, it needs to be cleansed so that no sensitive data (an example would be social security numbers) is put on the development and testing environment.

1.3.5.3.7 Access to outside services shall be granted by CCE as needed, on a temporary basis, and by exception only.

1.3.5.4 Writing Secure Application Software

In coordination with the Government, the Contractor shall design, develop and implement secure applications and configurations through applying applicable DOD STIGs, checklists, contractor security guidance, industry best practices (OWASP.org and SANS.org), and applicable contractor product security patches to the development environment. The Contractor shall leverage, to the maximum extent possible, automated tools to identify and remediate vulnerabilities or weaknesses in the application design and coding. The Government will provide software security vulnerability scanning and testing tools for the life-cycle development process. Fortify is the tool currently used by the enterprise. Weaknesses are described in the Common Weakness Enumeration / Systems Admin, Audit, Network, Security Institute

(CWE/SANS) Top 25 Most Dangerous Programming Errors, and Open Web Application Security Project

(OWASP) Top Ten that could be exploited by unauthorized sources.

The contractor shall use software development industry standards and industry agile best practices for providing the products and services required by the contract in the absence of specific contract requirements.

1.3.5.4.1 Code Scans. SDDC IA policies require base-lined source code to be scanned prior to release to the Staging and Production environments. The tool currently used for these software scans is Fortify. The contractor shall provide Fortify scans prior to release to staging and production.

1.3.5.4.2 Tracking Security Issues. The contractor shall track all security issues uncovered during the entire software lifecycle, whether a requirement, design, implementation, testing, deployment, or operational issue. The risk associated with each security issue shall be evaluated, documented, and reported to Government as soon as possible after discovery and the contractor shall include this risk along with risk mitigation Course Of Actions (COAs) and a recommended COA as part of the WSR referenced in Task 1 Subtask 1.

1.3.5.4.3 Malicious Code Warranty. The contractor represents and warrants that the software shall be free from all computer viruses, worms, time-outs, time bombs, back doors, disabling devices and other harmful or malicious code intended to or which may damage, disrupt, inconvenience or permit access to the software user‟s or another‟s software, hardware, networks, data or information.

1.3.5.5 Delivery of the Secure Application Software

The contractor shall be responsible for the successful installation and implementation of Government-owned software onto the Government-owned CCE staging, production, and DR environments. The

Government will be transitioning to the use of a centralized software installation/implementation team that will perform code scans, builds and installation of the code into the Government-owned environments. As this team is stood up, the contractor will provide assistance to this team during the verification and build process. The contractor shall use a master build process that reliably builds a complete distribution from source. This process shall include a method for verifying the integrity of the software delivered to the Government by using digitally-signed and encrypted media. For all deliveries, the contractor shall provide all source code, installation kits, documentation (including those related to architecture, test design and testing results, and installation procedures), and build procedures and scripts delivered to or maintained for the Government. All executables must be built on a .mil environment.

1.3.5.5.1 Non-Secure Software Delivered to Government.

If the Government determines, after a security audit (e.g. Security Test & Evaluations (ST&E)), that software delivered under this contract is non-secure, the Government will provide written notice to the contractor of each non-conformity. Software will be “non-secure” under this contract if it contains a programming error listed on the current approved version of the CWE/SANS Top 25 (which can be located at http://www.sans.org/top25) or a web application security flaw listed on the current approved version of the OWASP Top Ten (which can be located at http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project). Such notice constitutes revocation of acceptance of any delivered software. If the Government determines that the software is non-secure, and thus non-conforming, the Government may reject the delivery, provide notice of the non-conformance, and document the contractor‟s performance record.

2.0 DELIVERABLES

All deliverables shall be submitted electronically via email or Dimensions in the case of software development source code and associated files. If a delivery is submitted via email and the size or the firewall prevents its delivery, the contractor shall deliver the requirements via compact disk/digital videodisk (CD/DVD). The CD/DVD shall be properly labeled to identify the content to include version number and date. All deliverables shall meet professional standards and meet the requirements set forth in contractual documentation. The contractor shall provide all deliverables electronically in Microsoft

Office (Word, Excel, PowerPoint, Project, etc.) formats pursuant to the following schedule.

IAW DFARS 252.227-7013, DFARS 252.227-7014 and DFARS 252.227-7015, the Government obtains under this contract “unlimited rights” to all non-commercial computer software, software source code, computer software documentation, enhancements, technical data, and similar non-commercial data developed exclusively at Government expense and delivered to the Government under this contract.

Unlimited rights means rights to use, modify, reproduce, release, perform, display, or disclose in whole or in part, in any manner and for any purpose whatsoever, and to have the ability to authorize others to do

so. The contractor agrees that regardless of how contractor provided data/software is developed or modified during contract performance, the contractor will deliver data/software marked IAW requirements in DFARS 252.227-7013, 252.277-7014, or other applicable reference. All documentation provided under this contract is a deliverable to the Government and the Government has unlimited rights to said documentation (per DFARS 252.227-7015 and 7037). For all other non-commercial data delivered under this contract, the Government has the right to use, modify, reproduce, release, display, or disclose, in whole or in part, in any manner and for any purpose whatsoever, and to have or authorize others to do so.

The contractor shall authorize periodic Government inspections and reviews to assure compliance with

DOD requirements throughout the contract performance period. The contractor shall be responsible for taking corrective action based upon the impact and severity of identified weaknesses.

PWS

Para

Deliverable Title Number/Format Delivery Schedule Technical Data

Rights

1.3.1.1 Weekly Status

Reports

No later than the close of business day of each

Monday or first business day after a holiday.

1.3.1.2 PMR Presentation

Materials

Two business days prior to the PMR

1.3.1.2 PMR Minutes NLT five business days

after PMR as requested by the COR

1.3.1.3 Employment Status

Report

Initial – Within thirty calendar days after award

Subsequent – As employment changes occur.

1.3.1.4 Contractor

Management Report

(CMR)

31 Oct of each year

1.3.2.1.1 Installed, executable

Software Releases in support of government approved SCRs

Operational software within the

CCE, supporting approved SCRs to deliver application capabilities

Continual Requirement Unlimited

(DFARS

252.227-7013 and 7014)

1.3.2.1.2 After Action Reports

and System

Documentation

Microsoft Office

Products

Within two days of each quarterly release, or reviewed annually to determine if other changes are required

Unlimited

1.3.2.1.2 Application User

Account Standard

Operating Procedure

(SOP)

Microsoft Office

Products

Within thirty calendar days of a change in procedures, reviewed annually if no changes occur, due by 1 Aug of each reporting period

Unlimited

1.3.2.1.2

Application

Configuration

Guides

Microsoft Office

Products

Within thirty calendar days of a change in procedures, reviewed annually if no changes occur, due by 15 Aug of each contract period

Unlimited

1.3.2.1.2 Systems Operations

Manual

Microsoft Office

Products

Within thirty calendar days of a change in procedures, reviewed annually if no changes occur, due by 30 Aug of each contract period

1.3.2.1.2. Database Design

Specification

Microsoft Office

Products

Within thirty calendar days of a change in procedures, reviewed annually if no changes occur, due by 30 Aug of each contract period

Unlimited

1.3.2.1.2 Data Flow

Documentation

Microsoft Office

Products

Within thirty calendar days of a change in procedures, reviewed annually if no changes occur, due by 15 Sep of each contract period

Unlimited

1.3.2.2.1 Software Install Operational

software within the DRE

Install and configure application software one (1) day after installing and configuring on the

Production site

Unlimited

(DFARS

252.227-7013 and 7014)

1.3.2.2.2. Application

Contingency Plan and Disaster

Recovery Exercise

Results

Microsoft Office

Products

Semi-annually Unlimited

(DFARS

252.227-7013 and 7014)

1.3.4.1 Configuration

Management Plan

Microsoft Office

Products

Updated Quarterly by first Tuesday of the quarter

Unlimited

1.3.4.2 Change Requests Captured in SDDC

Change Control

Tool

1.3.4.4 TFMS-M CCB

Minutes (if applicable)

Microsoft Office

Products

Five (5) business days after meeting.

1.3.4.5.1 Base Line Source

Code

Serena Dimensions Prior to release to the production environment.

Unlimited

1.3.4.5.1 Source Code

Installation Guides

Prior to release to the staging environment Unlimited

(DFARS

252.227-7013 and 7014)

1.3.5.2 Operational/working

software

Operational software within

CCE

Continual requirement Unlimited

(DFARS

252.227-7013 and 7014)

1.3.5.2 Application STIG

Status Reports

Microsoft Office

Products

Monthly Unlimited

1.3.5.2 Ports, Protocols, and

Services (PPS) matrix

To coincide with changes to ports, protocols, and services

1.3.5.2. Program privileged Unlimited

user list

1.3.5.2. Application design

document

Unlimited

1.3.5.2 Additional

documentation as required by the

DIACAP and

DIARMF processes.

Unlimited

1.3.5.2. PO&AM Microsoft products No later than last

business day of each month

Unlimited

1.3.5.4.1. Code Scans Fortify Scans Prior to release in

staging and production Unlimited

(DFARS

252.227-7013 and 7014)

3.0 SERVICE DELIVERY SUMMARY

The Services Delivery Summary (SDS) represents the most important contract objective that, when met, will ensure contract performance is satisfactory. Although not all PWS requirements are listed in the

SDS, the Contractor shall comply with all requirements in the PWS.

PWS

Para

Performance Objective Performance Threshold

1.3.1.1 Status Reports 98% of the time weekly Status Report is timely each week, complete, and accurate

1.3.1.2 PMR Presentation Materials 95% of the time PMR Presentation

Materials are received two business days prior to the PMR, complete, and with no more than 4 errors.

1.3.1.2 PMR Minutes 90% of the time PMR Minutes are

received five business days after PMR, complete and accurate

1.3.1.3 Employment Status Report 95% of the time Employment Status within 30 days after award

1.3.1.4. Contractor Management Report (CMR) 98% of the time CMR is timely, complete, and accurate

1.3.4.1 CMP 98% of the time CMP is timely, complete, and accurate

1.3.4.5.1 Source Code 98% of the time Source Code is timely, complete, and accurate

1.3.4.4…