Tab_1C_-_Cargo_Systems_Application_Development_and_OM_Support_DRAFT_SOW.docx

U.S. Department of Homeland Security U.S. Customs and Border Protection Cargo Systems Program Directorate (CSPD)

Statement of Work Cargo Systems Application Development and Operations and Maintenance Support

April 18, 2018

Revision History

Table of Contents

1.0 PURPOSE

The purpose of this contract is to obtain application development and operation and maintenance support services for the Department of Homeland Security (DHS), U.S. Customs and Border Protection (CBP) Cargo Systems Program Directorate (CSPD) to develop and support cargo systems applications.

2.0 OVERVIEW AND BACKGROUND

CBP are modernizing its business processes, information technology systems, and infrastructure to provide the functionality needed to support its mission. The CBP mission is to enforce the laws of more than 40 agencies and to protect the revenue of the United States, while facilitating trade. To accomplish this, CBP clears and processes more than 12 million cargo entries per year, of which 55 percent involve merchandise subject to quota or other trade programs, collects more than $20 billion in revenue, and monitors an average of 10 million annual export shipments. This broad mandate encompasses a wide range of law enforcement activities and responsibilities.

CBP provides security at America’s borders and ports of entry, as well as extending the zone of America’s security beyond physical borders, ensuring that American borders are the last line of defense, not the first. CBP is also responsible for processing all people, vehicles, and cargo entering the United States; apprehending individuals attempting to enter the United States illegally; stemming the flow of illegal drugs and other contraband; protecting our agricultural and economic interests from harmful pests and diseases; regulating and facilitating international trade and travel; protecting American businesses from theft of intellectual property and unfair trade practices; collecting import duties; maintaining export controls; and enforcing United States trade laws. CBP is 1 of 22 DHS federal agencies having more than 65,000 employees throughout the United States and the world.

The Office of Information and Technology (OIT) is responsible for implementation and support of information technology (IT), research and development functions, and developing technological strategies for automation of mission-related business needs. OIT personnel manage all computer and related resources, including all operational aspects of the Computer Security Program; establish requirements for computer interfaces between CBP and the international trade community as well as other Partner Government Agencies (PGA); and manage development and support of automated import processing. Additionally, OIT personnel are responsible for managing all aspects of tactical communications in support of the CBP law enforcement mission, including the 24x7 operations of the National Law Enforcement Communications Center.

Within OIT, CSPD maintains systems supporting cargo processing, such as the Automated Commercial Environment (ACE). The systems enable automation for the Nation’s import workflow and duty collection processes. ACE was developed to support modernized processing of cargo and to replace legacy mainframe based ACS using a mix of Commercial Off-the-Shelf (COTS) software and custom coded software on a multi-tier, web-based platform. CSPD intends to complete development of new features and transition existing legacy applications to a commodity based collective of cargo applications that is compliant with the CBP Enterprise Target Architecture (CBP ETA). This transformation will consolidate the infrastructure requirements, reduce overall Operations and Maintenance costs, and broaden the resource base to handle both new system development and sustainment of transitioned applications.

In order to complete development of ACE functionality on the CBP ETA and accommodate the numerous changes to requirements CSPD has been faced with in the past, CSPD is using Agile software development methodologies to complete development of ACE. Incremental releases and responsiveness to requirements changes that characterize Agile development will benefit system stakeholders and the CBP mission.

3.0 SCOPE

The scope of the support required for this contract shall include but, is not limited to, Collections Features, Cargo Release/SE Features, Post Release Features, ITDS Single Window Features, and Manifest Features. The scope also includes cross-functional support for the Agile Teams. This Statement of Work (SOW) describes the work to be performed, specific timeframes, and required deliverables under a T&M contract vehicle.

The Contractor shall perform the tasks defined in Section 4.0 and produce and provide the Government with the deliverables identified in the individual task orders executed under this contract and work products defined in Section 9.2.

4.0 GENERAL REQUIREMENTS AND TASKS

Contractor resources will be used by the Government to staff multiple Development Teams, and other teams identified by the Government. The Development teams will be composed of developers and testers/analysts with sufficient expertise to fully develop and test working software in an agile environment. These Development Teams will be led and directed by the Government to deliver integrated and tested software in time-boxed Sprints. In addition to the Development Teams, a Support Team will be provided by the Contractor composed of specialists who support all the Development Teams in particular areas of expertise. The sections below provide details on the Development Team and Support Team composition; the number of teams; the schedule to establish the teams; and the team objectives.

Contractor Development Teams

The Contractor shall provide the personnel resources required to staff various Development Teams upon initial award. Each of the Development Teams shall be composed of full time team members including: full time lead agile developer; full time experienced agile developers; and full time experienced agile testers / analysts. The composition of skills on the Development Team may be altered with Government approval if the Contractor can demonstrate the need to alter the skill mix based on the type of work in user stories being addressed in upcoming development. At the optional discretion of the Government, additional Development Teams of the same size and composition outlined above may be added.

The incremental Development Team growth shall be dictated by the pace and success of the ongoing Development Teams and rate at which the features on the product backlog are being developed. The Government may also elect to decrease the number of Development Teams or not exercise its option to increase the number of Development Teams in accordance with the anticipated schedule above.

Contractor Support Team

In addition to the Development Teams, the Contractor shall provide a single Support Team composed of full time equivalents that support all the Development Teams. On the Support Team the Contractor shall provide specialist skills needed to support the Development Teams in areas of expertise such as data architecture; development of data interchange specifications (XML, current CBP EDI specifications, etc.); user interface development; system architecture; etc. The composition of skills on the Support Team may be altered with Government approval if the Contractor can demonstrate the need to alter the skill mix based on the type of work in user stories being addressed in the upcoming development.

At the optional discretion of the Government, additional full time personnel may be added to the Support Team.

The incremental Support Team growth shall be dictated by the pace and success of the ongoing Development Teams and rate at which the features on the product backlog are being developed. The Government may also elect to decrease the number of Support Team personnel or not exercise its option to increase the number of Support Team personnel in accordance with the anticipated schedule above.

The Contractor Development Teams and Support Team shall assist the CBP CSPD in accomplishing the nine objectives, in three areas, described below:

Achieve high stakeholder satisfaction through agile development and delivery of valuable software features, to include:

1. Regular demonstration and delivery of newly developed software functionality at the user story, feature, and release level.

2. Successful implementation of the agile planning, development, testing, communication, and organizational practices described in this document as the means to develop and deliver software.

3. Responsiveness to changes in priorities and requirements.

4. Effective collaboration with business and technical stakeholders.

Optimize cargo systems applications for operational utility and cost efficiency, to include:

1. Delivery of high-quality applications that maximize system maintainability, reliability, availability, and other quality attributes.

2. Problem resolution accuracy and completeness without introduction of application defects or system degradation.

3. Automate test, integration, and deployment Enhance Program decision making at CSPD, by providing:

1. Transparent communication of Contractor progress in building valuable features using agile communications media such as burn down charts, task boards, etc. with agile lifecycle management tools provided to the Contractor (i.e. Atlassian).

2. Advice and recommendations on architectural and technical improvements to the existing and evolving system.

The Contractor shall provide technical and management support services with the associated skills and qualifications which are needed to enable the CSPD transformation objective and to demonstrate the success of that transformation by developing applications to meet specified mission goals.

This SOW consists of seven (7) tasks covering:

· Task 1 – Contractor Transition In

· Task 2 – Contractor Transition Out

· Task 3 – Cargo Systems Application Development

· Task 4 – Dev/Ops Configuration and Release Management

· Task 5 - ACE Business Intelligence Capabilities

· Task 6 – IT System Security Analysis

· Task 7 – Operations and Maintenance

Defined requirements, deliverables and work products will be established in each executed task order.

The following documents are referenced for the performance of this effort:

· Cargo Systems Background Information

· Cargo Systems Executive Overview

· Concept of Operations (CONOPS)

· ACE Development and Deployment Schedule

· CBP Agile Framework

· ACE SELC Tailoring Plan

· ACE Agile Software Development Quick Reference Guide

· DHS Sensitive Systems Policy Directive 4300A

· Agile Roles and Responsibilities

· The Agile Manifesto (see http://agilemanifesto.org)

· The Scrum Guide (see www.scrum.org)

· CBP Enterprise Target Architecture (ETA), version 3.0.1

· CSPD Java Coding Standards

· Data Naming Standards 10012009 (v5 2)

· DHS Section 508 Compliance Test Processes for Applications (v3.3)

· Section 508 Test Steps

4.1 TASK 1: Contractor Transition In

The Contractor transition in period will begin upon receipt and acceptance of the contractor’s Transition Plan by the Government. The transition in period shall cause no disruption in development and especially O&M services. To ensure the necessary continuity of services and to maintain the current level of support, CSPD may retain services of the incumbent Contractor(s) for some, or all of, the transition period, as may be required.

The Contractor shall submit a transition plan and schedule (updated to reflect any agreements made at the Kickoff Meeting) no later than 10 days after the Kickoff Meeting unless otherwise directed by the Government. The Contractor shall account for 3 working days of Government review and approval of the transition backlog prior to executing the transition. The Contractor shall transition all work from existing teams within 90 days of starting the transition effort.

The Transition Plan shall:

· Establish transition roadmap and backlog

· Identify transition risks and risk mitigation

· Define roles and responsibilities

· Define a knowledge transfer approach

· Provide checklist

· Transition milestones

· Schedule of events The transition progress shall be provided in the monthly status report (CDRL XXX) and provide information on all of the activities in the transition plan. The Government reserves the right to call meetings at any time during the transition in period to review all transition activities.

4.2 TASK 2: Contractor Transition Out

At the completion of performance of this contract the Contractor shall fully support the transition of the Contractor’s work that is turned over to another entity, either Government or a successor offeror(s). The Contractor shall assist with transition planning and shall comply with transition milestones and schedules of events.

The Contractor shall be responsible for the implementation of the transition and application cutover activities. The transition shall cause no disruption of services. To ensure the necessary continuity of services and to maintain the current level of support, the Government may retain services of the incumbent Contractor for some, or all of, the transition period, as may be required.

The Contractor shall be responsible for the transition of all technical activities identified in this task order. As part of the transition, the Contractor shall be responsible for:

· Inventory and orderly transfer of all Government Furnished Property (GFP), to include hardware, software, and licenses, Contractor Acquired Government Property, and Government Furnished Information (GFI) to include

· Transfer of documentation currently in process

· Transfer of all software code in process

· Certification that all non-public DHS information has been purged from any Contractor-owned system

· Exchange of accounts to access software and hosted infrastructure components

· Participate in knowledge transfer activities in accordance with the transition plan

· Provide members to and participate in transition management

· Identify transition risks and risk mitigation The Contractor shall submit a Transition Plan. The Transition Plan shall include support activities for all transition efforts for follow-on requirements to minimize disruption of services. The Transition Plan shall:

· Identify equipment, hardware, software, documents and other artifacts that are included in the transition

· Establish roadmap and backlog

· Identify transition risks and risk mitigation

· Define roles and responsibilities

· Define transition approval authorities and lines of communication

· Define a knowledge transfer approach

· Define a property inventory and transition approach

· Create bi-party or tri-party agreements

· Provide checklists

· Transition milestones and schedule of events A Transition Plan shall be delivered 120 days prior to the task order expiration date. The Contractor shall account for a 10 business day Government review process prior to executing the transition. Upon award of a follow-on contract, the incumbent Contractor will work with the new Contractor to provide knowledge transfer and transition support, as required by the Contracting Officer’s Representative (COR) and Program Manager (PM).

4.3 TASK 3: Cargo Systems Application Development

The Contractor shall develop features in accordance with the ACE product backlog, as specifically defined in each incremental development plan deliverable. These features will be incorporated into Potentially Shippable Increments of Software (PSI) and will be developed with Agile development teams. The Contractor shall provide the Agile development teams with proven Agile development expertise and skilled technical development resources, along with automated testing engineers and continuous integration engineers who have working knowledge and understanding of the CBP ETA and development environments. The task shall provide, but not be limited to, the following functions as prioritized by the Government:

· Development of features that will be incorporated into PSIs, using Agile development teams.

· Fully exercise all tools and methodology components for Agile software development, including Agile Lifecycle Management (ALM) tools, continuous integration (CI) tools, automated testing tools, and stakeholder collaboration methods available within the CBP ETA.

· Develop, validate, and tailor a system lifecycle development process and artifacts in conjunction with the Government, and in accordance with DHS and CBP Agile Systems Engineering Lifecycle (SELC) methodologies.

· Mandate test automation

· Mandate compliance with automated standards for test coverage and code quality

· The practice of Extreme Programming (XP) concepts and techniques should be used when developing or maintaining all applications unless specified otherwise.

This should include but not limited to:

· Test Driven Development,

· peer programing,

· adherence to coding, testing, and release standards,

· automated unit, integration, and regression testing,

· automated code builds and deployments,

· small releases, and

· design simplicity.

4.4 TASK 4: Dev/Ops Configuration and Release Management

The Contractor shall provide Dev/Ops Configuration and Release Management support services to perform tasks that include but, not limited to:

· Manage and maintain the release process, to include making any necessary improvements based on policy or technology.

· Support the day to day software release process (Dev/Ops) for CSPD from configuration management to Production release that includes:

· Software and Database configuration management

· Version control

· Release management

· Management of software builds and deployments

· Promotion to all environments

· Implement and maintain scalable build, test, staging and deployment tools, and automation that allows integration with various Continuous Integration (CI) tools, Artifact Repositories and sub systems.

· Coordinate with functional (development/testing, deployment, systems/infrastructure) and development teams to ensure continuous operation for configuration management and release management.

· Maintain the configuration management data base (CMDB).

4.5 TASK 5 ACE Business Intelligence Capabilities

· Establish an Agile plan based on total identified work for BI capabilities and align to the ACE development schedule. Be cognizant of the ultimate goal of consolidating with Enterprise Data Warehouse (EDW). If it makes sense, build a new data mart and reports in EDW.

· Requirements Analysis for each increment covering one or more logical subject area for ACE as identified above.

· Develop consolidated backlog

· Define new user stories and technical stories

· Design by Subject Area, which can include some or all entities identified below:

· Navigation path / User Access

· Existing Reports Change/New Reports

· New data source to be added

· Table design change, i.e. columns to be added

· New data mart/database tables as required

· New ETL code development or change to an existing code

· Reports and dashboard design including mockups

· Consolidate data marts between ACE Data Warehouse (ADW) and EDW

· Provide support for ACE O&M team with design and development of Extract, Transform and Load processes using Informatica in support of database changes being made for ACE development. The areas of focus will be Entry and Entry Summary, AD/CVD, and Air manifest

· Appropriate reports and Universe modifications to reflect data in EDW

4.6 TASK 6: IT System Security Analysis

Contractor shall provide IT system security analysis and current operational procedures to determine compliance gaps; monitors and reports on POAM (Plan of Action and Milestones) and CAP (Corrective Action Plan) resolution status; collect information requested by internal and external auditors; assist in developing narrative to support security documentation; and monitor operational procedure compliance through collection of evidentiary documentation. Contractor shall provide skills in applying analytical techniques to the collection, summary and analysis of information concerning enterprise, program and project issues and applying those skills to developing draft plans and recommendations to enhance project-level security programs for management evaluation.

4.7 TASK 7: Operations and Maintenance

The Contractor will be required to Operations and Maintenance of the systems identified in this SOW and develop continuous integration, automated testing, automated configuration, automated deployment, and capture of automated metrics. These metrics will capture both the health of the deployment infrastructure in terms of its responsiveness to identifying defects early, and in terms of the cycle time to produce potentially deployable code.

(i) Application Development for Enhancements, Refactoring, and Defects

Contractor shall provide integrated Agile development teams for the purpose of responding to specific application development and sustainment requirements the Government identifies (new development, defects, or refactoring of existing code). These development teams will develop both application and infrastructure code. The infrastructure code will enable automated deployment and maintenance, and manage the automated configuration of the deployment pipeline. Team members will work directly on Agile Development teams to support rapid cycles of development, test, deployment and release. Overarching goals of this integration between development and deployment are twofold: 1) to reduce the cycle time from requirements to release; and 2) to increase ownership by development teams of any software defects that may appear through rapid identification of these defects by the automated deployment pipeline before they reach production. In developing and refining the automated deployment pipeline, the Contractor’s work shall conform to the architecture and design provided by the Government Architecture and Design team and CSPD established Agile processes

(ii) Enhancements and Refactoring

The Contractor shall be responsible for development teams performing the full suite of development tasks using Agile methodologies, including, but not limited to:

· Participating in creating user stories for functional and technical requirements

· Participating in defining acceptance criteria

· Estimating the size of stories

· Solution design, development, and testing

Additionally, the Contractor shall:

· Assist in the documentation of user stories, acceptance criteria and tasks to be completed to fulfill the definition of done for a story

· Develop code and other artifacts against the user stories documented in support of all development activities

(iii) Defects

The ultimate goal of automated testing, continuous integration, and automating deployments is to facilitate early identification of defects before they reach production. In cases where defects are released into production, the team responsible for developing a software component where a defect was identified will also fix the defect.

The Contractor shall provide 24x7, on-call remote support to address defects. The Government will notify the Contractor when defects requiring corrective action are received. Corrective action for defects shall be based on the severity and priority assigned. The Government will determine the priority of the Corrective issues and work defects into the development backlog prior to commencing a given development sprint with the following exceptions:

· Severity level 1 (Sev 1) defects shall be resolved within 12 hours from the time the Contractor is notified of the issue unless the Contractor explicitly notifies the Government that the 12 hour time window cannot be met, in which case the issue shall be resolved within 24 hours. Sev 1 defects cover any situations that include an application outage or problem which has an impact on the business operations, critical business processes, or officer safety and no bypass or workaround is available.

· Severity level 2 (Sev 2) defects shall be resolved within 24 hours unless the Contractor explicitly notifies the Government that the 24 hour time window cannot be met, in which case the issue hall be resolved within 72 hours. Sev 2 defects cover situations in which a key component, minor application functionality, or business process is down, degraded or unusable and no acceptable alternative or workaround is available.

For all defects, the Contractor shall provide Monthly Operational Maintenance Activity and Metrics Reports. The report shall include:

· The backlog of open non-Severity 1 or 2 defects

· The number of open/closed/canceled defects for the last month Reports shall be generated from the Agile lifecycle management tool designed by CSPD (e.g. Jira) to track all development and operations activities.

(iv) Continuous Integration (CI)

Contractor shall implement CI tools and processes for development and sustainment activities, integrating developed code to the mainline code base as developers commit code. Continuous integration shall, at a minimum include automated unit, functional, and regression testing, and automated code quality tools.

The Contractor shall also develop the automated infrastructure code needed to support rapid deployment and release. The Contractor shall correct any defects to application or infrastructure code identified by testers, code reviewers, automated tools, or as part of the CI build or Continuous Deployment process.

Contractor’s work shall conform to the architecture and standards provided by the Government and the Agile processes set up by CSPD. This will include providing input to any documentation required to maintain compliance with DHS and CBP standards.

The Contractor’s code shall meet the functional and non-functional requirements, meet database development requirements, and be deployable and fully tested. Upon completion of each development sprint, the Contractor shall provide the Government an updated Deployment Design Document (DDD) that describes the current state of the evolving conceptual, logical, and physical system design including any technical debt that may need to be addressed.

(v) Automated Testing

Contractor shall be responsible for creating test cases and automated test scripts to support test automation activities. In creating test automation, the Contractor shall:

· Collaborate with all team members to write automated tests

· Collaborate with other teams to support automated testing during continuous code integration

· Share test scripts (manual and automated) as needed with other teams and testing entities

· Assist with crafting both automated and manual validation steps (both positive and negative testing) for user acceptance testing on an as needed basis

Contractor shall support operations and sustainment activities to ensure the automatic build and deployment process works effectively across all environments. Deployment and testing in the development/test environment should closely mimic the actions performed for deployment and testing in staging and production. Contractor shall perform development testing before the commit stage in the CI pipeline.

(vi) Automated Deployment

In support of the Agile development teams, the Contractor shall develop, define, and manage the configuration of the automated deployment pipeline. This includes, but is not limited to:

· Participating in the selection and operation of tools used to enable continuous delivery

· Maintaining system configuration files and scripts

· Maintaining a trusted automated testing, build, configuration, and deployment system

· Building, testing, and immediately integrating changes to infrastructure code, including proper configuration control of these changes

· Maintaining configuration control of all changes to developer executable code, configuration, host environments, and data so that as these elements change, the change can be verified, and when needed, rolled back

· Collaborating between development and operations teams; developers, testers, operations personnel, and managers function as a single integrated team working to produce reliable deployable code in short iterations

The Contractor shall use CBP and DHS development and test environments. CSPD’s technical landscape is shifting from a proprietary COTS-based framework to open source. The current cargo systems development architecture has demonstrated success with a stack of predominately open source development and test tools that are currently under consideration for standardization across development teams. The Contractor shall utilize such a standardized development and test suite, with the expectation that the development and test architecture will evolve.

The simplified architecture for cargo systems may be based on Java, Oracle, Spring, JPA/Hibernate, Adobe, Hadoop, and Drools. The COTS and open source tools, languages, utilities, and applications currently used and under consideration for the standardized environment are identified in the table below. The Contractor will have the opportunity to influence the development and test tool suite if sufficient justification is presented. The Contractors shall have expertise in the technologies used in the current CSPD architecture.

Open source tools, languages, utilities, and applications in use and considered for use in CSPD:

Broker Tool Kit

Build Forge

Dimensions

Drools

Kepler Juniper

Erwin

Hadoop

Junit

Unit testing

MQ

MQMon

Rally

Selenium

Browser testing in Firefox

SonarQube

Stash

Subversion

Toad

Urban Code

The Contractor shall develop or enhance a single source code repository and version control system for all source code, tests, database scripts, documentation, libraries, configuration files, and metadata that describes stored data.

The Contractor shall develop or enhance existing automated build systems; Contractor shall write scripts that describe the entire build process to produce packages containing all artifacts necessary to install applications into a package repository.

The Contractor shall develop a continuous delivery process to automatically deploy package repositories from development/test to test, pre-production, and production environments once approved by the Government for release.

In order to keep up with technological advances to automated deployments, the Contractor shall maintain a 3-6 month technology and standards outlook for engineering and software development tools documented in an architectural backlog to support design and automated deployment of the ACE application.

(vii) Performance Monitoring and Support

The Contractor shall develop a framework to continually monitor and measure operational metrics to determine effectiveness of ACE development and sustainment. The Contractor will be primarily evaluated against two overarching measures of success:

· Reduction in time to deploy and successfully integrate any change (e.g. application or infrastructure code) to deployable features; or “cycle time” of the deployment pipeline

· Number of defects that escape into production

Other important measures include, but are not limited to:

· Time to detect defects

· Time to resolve defects

· Time to restore system after outage

· Time to deploy code during outage periods

· Amount of transactions processed on a monthly basis

· Amount of revenue collected on a monthly basis

· Number of trade and CBP users accessing ACE

· Other measures as directed by the Government

(viii) Information System Security Support

The Contractor shall support Information System Security Officer (ISSO) activities for the collection of cargo systems developed by CSPD, including:

· Perform activities to support re-certification and accreditation of cargo systems every three years or when accumulated changes are significant enough to necessitate a re-certification and accreditation.

· Support an annual security self-assessment audit and request and coordinate with Security Operations Center.

· Support cargo systems-related security audits and provide the auditors with relevant answers and artifacts in a timely manner.

· Provide security oversight for implementing new system roles. Validate that any new or updated roles have only the level of access needed to satisfy the requirement per the latest version of the Cargo Systems Security Design document.

· Manage and maintain DHS and commercial signed digital certificates used in production systems for secure communications and code signing.

· When required, create and coordinate Interconnection Security Agreements (ISAs) and support CBP’s development of Memoranda of Understanding (MOUs).

· Participate in the Security Working Group.

· Support reporting any security incident to the CBP Computer Security Incident Response Center (CSIRC) and help with the investigation.

· Provide Transport Layer Security (TLS) and Secure Sockets Layer (SSL) certificate documentation for cargo system environment use and resolve code signing and DHS server digital certificate issues.

· Conduct analysis of security scan results and support follow-up on associated Plan of Action and Milestones (POA&Ms), CR, and PRs.

(ix) Security Engineering

Security engineering practices shall be integrated into the application development and sustainment effort.

The Contractor shall:

· Identify security constraints that affect the confidentiality, integrity, and availability of data and application prior to starting development and sustainment sprints in a security engineering backlog

· Produce design guidelines to address security threats and vulnerabilities

· Collaborate with Government security engineers to develop security threat models to identify the threats and vulnerabilities relevant to cargo systems

· Integrate automated security code inspection tools into the CI pipeline to identify and resolve security vulnerabilities. The Contractor shall identify vulnerabilities found through security code inspections and develop stories to fix vulnerabilities identified through inspection during the development and test

· Use results from threat modeling to continually adjust the scope of security testing activities and to define test plans

· Assess deployment scripts to ensure weak or inappropriate configuration settings do not introduce security vulnerabilities

· Support maintenance and update of the Cargo Systems Security Design Document

(x) System Engineering Support

The Contractor shall collaborate with stakeholders, support Contractors, and third party vendors throughout system integration, performance, security, Section 508, system acceptance, user acceptance, usability, and test and evaluation reporting. Constraints in a given software deployment for ACE are documented in the OIT Automated Governance (OAG) tool.

Vehicles for transparency, such as the agency Agile Application Lifecycle Management (ALM) tool, shall be maintained with data so that reports and charts can be generated as needed, and so that user stories, defects, and tasks and their status are available to stakeholders. Task boards and Sharepoint sites, meetings, and demos can be used to share information and report progress.

The Contractor shall support the ACE Business Office (ABO) Client Representative branch in certification of trade members in using the Electronic Data Interchange (EDI) system to submit electronic manifests and other messages in the ACE Certification environment during pre-production training with the trade.

The Contractor shall prepare National Information Exchange Model Information Exchange Package Documentation (NIEM IEPDs), Interface Control Documents (ICDs), and World Customs Organization (WCO) data model compliant Information Packages in support of data interchanges between the trade and PGA’s transmitting data to and from ACE in support of the International Trade Data System (ITDS).

5.0 ON-DEMAND SERVICES

Based on the nature of the software development and O&M environment, dependent on requirements and available funding, the Government may require an increase in support provided by this contract. This increase is dependent on mission need and priorities. A separate T&M contract line item (CLIN) shall be established to accommodate on-demand surge workloads throughout the period of performance to support limited duration projects, special requirements, as well as other surge efforts relevant to the scope of work. If it is determined a Surge Requirement as previously defined exists, the Government may exercise the surge CLINS as identified in the delivery order which will be separately priced and fully funded individually on the Optional Surge CLINs via modification to the Task Order.

A Surge Requirement is defined as any additional work that can be performed under the scope of this SOW resulting from additional functionality that may be required by ACE to perform. A Surge Requirement can result from either statutory or regulatory mandate as well as new or improved functionality that has been determined is needed in ACE.

ACE functionality and associated funding for Surge Requirements will be reviewed and approved by CSPD leadership and submitted to the contractor for their review and proposal. Work will not commence for On-Demand Services until the Government reviews and accepts a contractor proposal for a specific Surge Requirement and funding placed on the applicable CLIN.

6.0 AGILE SUPPORT REQUIREMENTS

Teams will be guided by Agile values and principles as stated in the Agile Manifesto at www.agilemanifesto.org. Contractor staff assigned to these teams shall have expertise and will be responsible for accomplishing specific tasks derived from accepted Agile practices. These tasks and activities are grouped into five major areas: organization, communications, planning, development and testing.

In regard to organization, the Government will provide a product owner for each team who will act as the voice of the customer and work directly with each Sprint development team. The Contractor shall provide staff operating in dedicated, integrated teams capable of delivering an increment of tested, deployable software for the Sprint in which they are assigned. The Contractor shall keep oversight and governance as lean as possible to empower the teams and push decision-making as close as possible to those doing the work. Contractor Team members shall choose their tasks from the highest priority work available, rather than have it assigned to them by a manager, fostering commitment from team members to the work, and also encouraging team members to venture outside their typical roles to help in whatever way most benefits the team as a whole, in accordance with the Agile development methodology.

Effective team communication is a critical component in the Agile process and to the success of the work products. The Contractor shall be responsible for conducting Sprint Kick-offs which will begin with a kick-off meeting between the development team and the product owner to discuss acceptance criteria and a detailed design for each story. This will align the team on their work for the Sprint. All development work shall take place in team rooms so team members are co-located in a dedicated team space in order to promote frequent face-to-face communication and collaboration. A story/task board shall be used to radiate information about the team’s work and promote at-a-glance visibility and transparency to other team members and stakeholders. In addition, the Contractor shall use a burndown and/or burnup chart to show the team’s daily progress in completing user stories and picture of remaining work and time. The Contractor shall maintain an information repository to ensure all information is stored in a single location providing easy access to all necessary development information (project and process related materials) by all members of the development team. The development team shall hold a process retrospective at least once per Sprint. This will allow the team to reflect on how they are working and discuss potential improvements. The Contractor shall hold daily stand-up meetings to discuss the progress of current stories and tasks, and to expose obstacles to progress and methods for potential improvement. The Contractor shall provide daily Agile status updates. These updates will be used to facilitate transparent communication between the Contractor and the Government of progress and impediments to the production of working software. Examples include backlog reports, burn down rates, velocity statistics, and impediment logs. The development team shall meet with the product owner and other Government stakeholders on the last day of the Sprint to conduct a Sprint Review in order to review completed stories and receive feedback, provide accountability for team members and visibility to the stakeholders.

The Contractor shall provide support to Agile Teams composed of Contractors and Government staff. These teams will be led and directed by the Government to deliver and demonstrate working software in short two week time-boxed iterations, termed Sprints. These teams will follow agile values and principles, and implement specific agile practices.

6.1 Agile Value, Principles and Prescribed Agile Practices

As stated above, CSPD has adopted agile values, principles, and practices to guide program office oversight activities and software development. See the Agile Manifesto for a list of the four values and twelve principles that are guiding the program. CSPD will, and the Contractor shall, also comply with CBP and DHS policy for systems development as described in DHS Directive 102-01 and current CBP policies. Where needed, CSPD will coordinate with DHS and CBP oversight to tailor current DHS and CBP directives and policies to support agile development.

Communities of practice such as Extreme Programming, Scrum, and Lean Software Development have developed many practices to support and enable the agile values and principles. Thirty-one specific agile practices, in five (5) general categories of practice are prescribed for this contract as evidence of agile development. The five general categories of practice are:

· Planning Practices

· Development Practices

· Testing Practices

· Communications Practices

· Organizational Practices The intent of prescribing 31specific practices in these areas is not to preclude the use of other agile practices that are deemed useful in implementing agile values and principles by the Contractor. As agile values embrace the expectation that the development teams will inspect and adapt their development process to provide greater customer value, these specific practices may be modified over time through a regular process of retrospectives that look back and take advantage of lessons learned. However, any additions or deletions to the practices stipulated here will need to be formally agreed to by the Government.

6.2 Planning Practices

The Contractor shall use the following agile planning practices:

1. Time-Boxed Sprints. The program is structured as a series of two-week (or as specified by the Government) Development Sprints, with delivery of working integrated code expected at the end of each Sprint. In addition to the Development Sprints, the Program will have a one-week Planning Sprint, termed Sprint Zero, at the completion of every six Development Sprints where working code is not expected. This practice requires all software development activities to be performed as an integrated whole in small cycles.

2. Frequent Releases. The program is structured as a series of thirteen-week (or as specified by the Government) Releases, that are organized as one one-week Planning Sprint followed by six two-week Development Sprints. Potentially Shippable Increments of working releasable software (i.e., fully functional and tested) are expected at the completion of each of these thirteen-week Release cycles. This practice enforces a regular cadence to provide value to the customer.

3. User Stories. User stories are used as the basic unit of both planning and execution within the Development Sprints. This facilitates conversations between the development team and Government stakeholders and allows planning and tracking of progress to proceed in a meaningful way.

4. Story Points and Agile Estimation. Work is estimated and planned with a unit-less scale reflecting relative levels of effort. This permits deriving time-based predictions from size-based estimates.

5. Team Velocity. A team’s past story point completion data is used to predict the amount of work it can accomplish in future Sprints. This provides a consistent, meaningful metric for planning.

6. Sustainable Pace. The team does not rely on regular overtime to maintain its pace. This practice values steady progress over heroics that are unsustainable in the long run.

7. Definition of Done. A standard “Definition of Done” is agreed to between across the program to provide a common checklist for completeness for user stories. This checklist reminds the development teams about the steps necessary to complete a user story. The items contained in the Definition of Done encompass completeness from the perspective of functionality and quality.

8. Product Backlog. A master prioritized “to do” list of features identified by the product owner and affected stakeholders is maintained for the project by the Product Owner for development teams to work as development sprints are executed. CSPD will consolidate all work efforts into a single consolidated backlog.