RFP_-_Att_A__-_CSPO_OTE_SOW.pdf

Department of Homeland Security

(DHS)

U.S. Customs and Border Protection

(CBP)

Office of Information and Technology (OIT)

Cargo Systems Program Office (CSPO)

Operational Test and Evaluation Support

Statement of Work (SOW)

March 1, 2013

Contents

1 PURPOSE

2 BACKGROUND

2.1 Mission and Systems

2.2 CSPO Agile Development Environment

3 SCOPE

4 APPLICABLE DOCUMENTS

5 PERFORMANCE OBJECTIVES

6 OT&E SUPPORT TASKS

6.1 Project Management

6.2 Attendance at Project Meetings

6.3 OT&E Planning

6.3.1 Document Review and OT&E Strategy Comments

6.3.2 OT&E Test Plan Development

6.3.3 TEMP Update

6.4 OT&E Events

6.4.1 Sprint Observations

6.4.2 Release Test Criteria

6.4.3 ACE Operational Test Readiness Review

6.5 OT&E Test Execution and Reporting Guidance

6.5.1 Test Requirements

6.5.2 Reporting Requirements

7 DELIVERABLES

8 PERIOD OF PERFORMANCE

9 AGILE PRACTICES

9.1 Agile Values, Principles, and Prescribed Agile Practices

9.1.1 Planning Practices

9.1.2 Development Practices

9.1.3 Testing Practices

9.1.4 Communications Practices

9.1.5 Organizational Practices

Sprint Architectural Reviews

Release Architectural Review

Change Control

Status Reporting

Project Management and Development Tools

Code Quality Metrics

10 GOVERNMENT FURNISHED EQUIPMENT

11 ACCESS TO GOVERNMENT PROPERTY AND FACILITIES/PLACE OF

PERFORMANCE

12 SUPPORT REQUIREMENTS AND INFORMATION

12.1 Holidays and Leave

12.2 Contractor Resources

12.2.1 Key Personnel

12.3 Government Resources

12.4 Security Clearances: Personnel Security Background Data

12.5 Government Furnished Information and Contractor Non-Disclosures

12.6 Work Hours

12.7 Overtime

12.8 Identification Badges

12.9 Contractor Identification

12.10 Mandatory and Other Training

12.10.1 Security Awareness and Records Management Training

12.10.2 Other Training

12.11 Government Project Leadership Contacts

13 TRAVEL AND OTHER DIRECT COSTS

14 ACCESSIBLITY REQUIREMENTS (SECTION 508)

14.1 Section 508 Applicable EIT Accessibility Standards

14.2 Section 508 Applicable Exceptions

14.3 Section 508 Compliance Requirements

15 INTERCONNECTION SECURITY AGREEMENTS

16 SECURITY REQUIREMENTS FOR UNCLASSIFIED INFORMATION

TECHNOLOGY RESOURCES

17 CONTRACTOR EMPLOYEE DATA ACCESS

18 SECURITY CERTIFICATION/ACCREDITATION

19 INFORMATION SECURITY

19.1 Encryption Compliance:

19.2 Security Authorization

19.3 Security Review and Reporting

19.4 Access to Unclassified Facilities, Information Technology Resources, and

Sensitive Information

19.5 OMB-M-07-18 FDCC/Common Security Configuration

1 PURPOSE

The purpose of this contract is to obtain Operational Test and Evaluation (OT&E) support services for the Cargo Systems Program Office (CSPO) to operationally test and evaluate cargo systems applications, as they are developed iteratively using agile development practices.

2 BACKGROUND

2.1 Mission and Systems

CBP is one of the largest and most complex components within DHS, with a priority mission of keeping terrorists and their weapons out of the U.S. CBP also has a responsibility for securing and facilitating trade and travel while enforcing hundreds of U.S. regulations, including immigration and drug laws. Within CBP, CSPO is responsible for the development and maintenance of systems and interfaces that support CBP, other Government agencies, and the trade community for import, export, and control of merchandise shipments.

CBP is the second largest revenue collector for the U.S. Government, second only to the Internal

Revenue Service (IRS). The Information Technology (IT) processing systems related to this

Statement of Work (SOW) provide the capabilities to support this revenue collection and the information exchange with the trade community, other government agencies and foreign governments.

To support trade, CSPO manages the Automated Commercial Environment (ACE), the

Automated Cargo System (ACS) and the Automated Export System (AES) on behalf of various stakeholders within CBP, other Government agencies, and industry. These systems also interface with the Automated Targeting System (ATS) to support trade. The need to sustain, develop, enhance, and migrate the functionality of CSPO production applications on these systems is critical to CBP’s mission.

2.2 CSPO Agile Development Environment

CSPO will follow agile values and principles, and implement specific agile practices, as described Section 9. The CSPO ACE Agile Software Development Lifecycle will be used to guide systems development on this contract. This lifecycle encompasses five phases: Solution

Engineering; Release Planning; Development Sprints; Hardening / Integration; and Operations and Maintenance, and is further described by the Agile Software Development Quick Reference

Guide. The Agile Practices, the Agile Software Development Quick Reference Guide and ACE

Systems Engineering Life Cycle (SELC) Tailoring Plan provide context on the environment under which OT&E must operate.

3 SCOPE

This contract entails a full range of OT&E services for cargo systems applications. For the purposes of this contract, cargo systems includes the following:

ACE.

ACS.

AES.

Interfacing Systems: These systems include cargo processing capabilities developed in

ATS and the CBP Enterprise Target Architecture. Also included are any other software subsystems that interface with external systems to the extent that these subsystems perform or support cargo processing.

For the purposes of this contract, OT&E services include the following:

OT&E Planning. This planning will account for the iterative nature of agile development, including allowance for operational testing and evaluation that is responsive to the short operational feedback cycles that are the result of agile two week iterations, hereafter referred to as Sprints.

OT&E Execution. This includes scheduling, coordination, briefing, participation in, and debriefing operational test events that correspond to the two-week Sprint, and thirteen-week Release cadences being used for agile development on this program. The government anticipates a formal Operational Test event to occur no more than once every

26 weeks during the course of the program.

OT&E Reporting. This includes drafting necessary correspondence and reports that support operational testing and evaluation in concert with the Sprint (i.e., 2 week) and

Release cadences (i.e., 13 week) used on the program. It also includes any aggregation of

Sprint and Release operational test and evaluation information and reporting needed to support Acquisition Event(s) (i.e., CBP Agile SELC milestone 3) for deployment to operations and maintenance.

4 APPLICABLE DOCUMENTS

Cargo Systems Executive Overview, Version 1.0, January 31, 2013

ACE Operational Requirements Document (ORD), Version 3.3, February 19, 2013 –

Draft Version

ACE Program Concept of Operations (CONOPS), Version 7.5, December 5, 2012 –

Draft Version

ACE Capability Development Roadmap – Draft Version

Mission Needs Statement for the Automated Commercial Environment (ACE), December 1, 2003

ACE Agile Framework, Version 0.01, February 28, 2013

ACE SELC Tailoring Plan – Draft Version

ACE Agile Software Development Quick Reference Guide, February 12, 2013

CSPO Software Development Metrics Guidelines, Version 0.2, May 18, 2012 – Draft

Version

CBP Enterprise Technical Architecture (CBP ETA), Version 1.0, December 2007

CBP Technical Reference Models (TRM)

DHS Service Oriented Architecture - Technical Framework, Version 1.0, February 12, CBP Naming Standards and Modelling Guidelines, Version 5.4, July 20, 2012

National Information Exchange Model (NIEM) Naming and Design Rules, Version 1.3, October 31, 2008 (see www.niem.gov)

Appendix B, DHS Systems Engineering Life Cycle (SELC), Version 2.0 (Interim), September, 2010

DHS Management Directive 102-01, Acquisition Management Directive, Revision

Number 01, January 20, 2010, and Revision Number 02, February 21, 2013

DHS Management Directive 026-06, Test and Evaluation, Revision Number 00, May 22, DHS 4300A Sensitive Systems Handbook, Version 7.2.1.1, January 19, 2011

5 PERFORMANCE OBJECTIVES

The performance objectives of this acquisition are met through the deliverables associated with the tasks in Section 5, and seven specific performance objectives, in two areas, described below.

Achieve high stakeholder satisfaction through operational testing and evaluation in an agile development and test environment, to include:

1. Operational testing and evaluation of newly developed software functionality at the user story and feature levels. At the sprint level, contract support will focus on reviewing and validating acceptance criteria of user stores with team capability owner(s) and with the product owner(s).

2. Successful implementation of an approach to operational test and evaluation that accounts for the agile planning, development, testing, communication, and organizational practices being used by developers and testers on this Program.

3. Responsiveness to changes in priorities and requirements as application developers respond to re-prioritization of the Program Backlog by the Product

Owner at Sprint and Release Boundaries.

4. Collaboration with CSPO Test and Evaluation group, the Operational Test Agent, application developers, and testers in designing operational test and evaluation test events and reporting that support agile development.

Optimize operational test and evaluation of cargo systems applications in an agile environment, to include:

5. Delivery of high-quality operational test events, and reporting, to incrementally confirm system Suitability requirements established in the Operational

Requirements Document (e.g., maintainability, reliability, availability, and other quality attributes) established at Release planning boundaries and documented in the Definition of Done or in acceptance criteria of a user story.

file:///C:/Data/CBP_ACE/Working%20Documents/www.niem.gov

6. Delivery of high-quality operational test events, and reporting, to incrementally confirm Operational Effectiveness requirements established in the Operational

Requirements Document and the Definition of Done, as well as functional requirements established in user story acceptance test criteria established in development Sprints.

7. Development of an operational test and evaluation approach that supports incremental confirmation of Measures of Effectiveness (MOEs) and Measures of

Performance (MOPs) identified in the ORD, and Critical Operational Issues

(COIs) identified in the Test and Evaluation Master Plan (TEMP) when using iterative development, and agile practices to accomplish application and system development.

6 OT&E SUPPORT TASKS

The Contractor shall provide operational test and evaluation support to Agile Teams composed of OT&E, development contractors and government staff. These teams will be led and directed by the government to deliver, demonstrate, and test, and evaluate working software in short two week time-boxed Sprints.

The OT&E contractor shall be assigned specific tasks in support of OT&E for CSPO. The contractor shall serve as a component of the OTA and will report all findings to the ACE

Program Manager and the ACE Operational Test Agent (OTA).The major tasks for this acquisition are described below.

6.1 Project Management

The contractor shall:

Provide the COTR and OTA with updates every two weeks including the progress of work on operational test and evaluation of the previous Sprint, and the expenditure of funds and labor hours during the Sprint.

Provide support in conducting liaison with developing agencies, laboratories, other U.S.

Government agencies, and hardware / software contractors to ensure that OT&E requirements are adequately addressed to permit timely and effective testing.

Associated deliverable: Bi-Weekly Status Report

6.2 Attendance at Project Meetings

The contractor shall:

Participate in Sprint Planning meetings to plan operational test and evaluation activities in support of the development teams, including advising the Product Owner on test and acceptance criteria for user stories.

Attend other meetings as required during the period of performance in various locations for the purposes of gathering information and providing technical expertise.

Participate in a Test and Evaluation Working Integrated Product Team (WIPT) in support of the OTA.

Generate a trip report no later than 3 business days after participating in an off-site meeting.

Associated deliverables: User Story Acceptance Test Criteria Advice to the Product Owner; Trip

Report(s)

6.3 OT&E Planning

6.3.1 Document Review and OT&E Strategy Comments

The contractor shall:

Review the Program Mission Needs Statement (MNS), Concept of Operation

(CONOPS), Operational Requirements Document (ORD), Test and Evaluation Master

Plan (TEMP), Agile Practices and SELC used on the Program, and other documents to understand the Cargo System program context and agile development environment.

Assist the government with development of the CSPO Operational Test and Evaluation strategy.

Provide documented comments on any issues relevant to operational test resulting from the review of documentation and the agile development approach being used on the

Program as an OT&E Strategy input comments. Documentation of comments may take the form of draft letters, presentations, or spreadsheets and shall be submitted to the

OTA, Program Manager, and CSPO T&E Director no later than 3 business days after completing review of the documentation.

Associated deliverable: OT&E Strategy Comments.

6.3.2 OT&E Test Plan Development

The contractor shall:

Become familiar in detail with the operational and technical characteristics of the ACE functionality to be tested and all relevant program documentation.

At the government’s direction, draft an Operational Test and Evaluation (OT&E) Plan for

ACE.

Conduct test planning, including test logistics and resource management planning, in accordance with appropriate OTA instructions and ensure that planning is thorough and complete in accordance with DHS Management Directive 026-06.

Conduct background research and provide analytical support and recommendations for the development of data collection plans for testing the operational effectiveness and suitability during each operational test event.

Develop test matrices and procedures and operational measures to satisfy testing objectives.

Compile data necessary to draft the tests for each operational test event.

Associated Deliverable: ACE OT&E Plan

6.3.3 TEMP Update.

The contractor shall:

Assist in the development or modification of test documentation for the conduct of

OT&E.

Assist the OTA in ensuring test events will support the resolution of Critical Operational

Issues (COI).

Formulate TEMP inputs related to OT&E.

Associated deliverables: ACE TEMP Update

6.4 OT&E Events

6.4.1 Sprint Observations

The contractor shall:

Provide advice and assistance to the Product Owner during Sprint Planning on OT&E as it relates to user story acceptance test criteria.

Review Developmental Test and Evaluation events and artifacts and participate in demonstrations of functional capabilities at the completion of development Sprints.

Associated deliverable: Sprint OT&E observations will be included in the Bi-Weekly Status

Report.

6.4.2 Release Test Criteria

Every 13 weeks, a Potentially Shippable Increment (PSI) shall be ready for Release. The contractor shall:

At the government’s direction, prepare and participate in development of Operational

Test Criteria for the PSI just developed.

At the government’s direction, conduct an Operational Test Readiness Review (OTRR) for the ACE Releases in production. At OTRR the readiness of the system will be briefed and the OTA will demonstrate that the OT plan is complete and in place and that all resources and systems are ready for OT.

Associated deliverable: PSI Operational Test Criteria

6.4.3 ACE Operational Test Readiness Review.

At the conclusion of the Program, prior to Acquisition Event Milestone 3, the contractor shall:

Conduct an Operational Test Readiness Review (OTRR) for the ACE Program. At

OTRR the readiness of the system will be briefed and the OTA will demonstrate that the

OT plan is complete and in place and that all resources and systems are ready for OT.

6.5 OT&E Test Execution and Reporting Guidance

6.5.1 Test Requirements

At the government’s direction of an Operational Test event, the contractor shall:

Conduct Operational Testing in an environment that is representative of the entire ACE production environment.

Schedule Operational Test events and coordinate Operational Test resources. The contractor, in consultation with the OTA, schedules test personnel and any other elements required for the successful execution of test events prescribed in the test plan.

Act as test coordinator during test events.

Assist the OTA in ensuring incremental test events will support the resolution of Critical

Operational Issues (COI) as relevant features supporting a given COI are developed and deployed.

Arrange for collection of all required data from each scheduled test event, to include the distribution of all data collection materials, configuration of all instrumentation prior to

Operational Test events, and recovery of all data during and after the scheduled test events.

Oversee the actual collection of data, review the data to ensure it is complete and free of corruption, and perform analysis on the data.

Analyze quantitative and qualitative test data using appropriate analysis techniques

Prepare appropriate data tables, graphs, and charts for inclusion into the test event report.

Throughout the test, track and monitor the amount of data captured and compare with the data required to address test objectives, measure actual test progress versus planned test progress, and monitor actual resources expended versus planned resources expended.

Adapt to changing test conditions.

Immediately advise the OTA of any gaps or data collection problems that could prevent achievement of Operational Test objectives.

Alert the OTA to potential deficiencies.

Determine the effect of deferred Problem Reports from the test event and document any unexpected impact on field operations.

Brief test personnel prior to Operational events as arranged with the OTA emphasizing the objectives of the test event and specific data-gathering requirements for each participant.

Debrief test personnel after each test event as arranged with the OTA.

Observe demonstrations/test events as appropriate with the OTA.

Provide technical reports.

Conduct OT&E activities at identified ports upon government direction.

6.5.2 Reporting Requirements

In preparing test reports, the contractor shall:

Analyze and summarize all test data, capture results and deficiencies, assist the OTA to determine deficiency levels, establish COI (Critical Operational Issues) resolution, make conclusions on operational effectiveness and suitability, make recommendations, and prepare draft OT&E reports for the test events described in the ACE OT&E test strategy in continuous consultation with the OTA.

Present the draft OT&E reports to the Test and Evaluation WIPT for review and the OTA for approval and signature. The report will be submitted to DHS Science and

Technology department of Test and Evaluation for concurrence and approval.

Deliver final OT&E reports within 30 business days of conclusion of test event

Deliver the draft OT&E reports within 20 business days of conclusion of test event.

Be available to the OTA during review of the draft reports and confer with the development contractor (if needed) regarding questions, comments, or revisions.

Review the OT&E Findings Summary for ACE with the Test and Evaluation WIPT no later than 15 business days after test execution.

7 DELIVERABLES

All deliverables shall be provided in electronic MS Office format and submitted to the OTA and

COTR unless otherwise indicated. The Government has 15 business days to accept the deliverable, or return it with comments for modification, after which the contractor has 10 business days to incorporate government comments and resubmit for acceptance.

Deliverable Description Due Date

OT&E Strategy

Comments

The OT&E Strategy must account for the iterative and agile development approach used by the Program. The contractor will provide suggestions and comments to accommodate

OT&E to agile development, while remaining cognizant of requirements stated in the MNS, ORD, and TEMP.

As required

ACE OT&E Plan The OT&E Plan is the primary document for identifying adequate

OT&E and defines the OT&E objectives, entry requirements, limitations, the specific test requirements for resolution of each

COI, and the minimum OT&E test requirements. Draft is provided for

OTA approval and signature.

Draft: Within 30 days

Final: Within 45 days

ACE TEMP Update Updates to the TEMP for OT&E As required

User Story During Sprint execution, the On-going within

Deliverable Description Due Date

Acceptance Test

Criteria Advice to the Product Owner contractor will provide the Product

Owner regular suggestions and advice on User Story Acceptance Criteria to ensure increments of development captured by User Stories can be tested and evaluated.

Sprints as User

Story acceptance criteria are created for each User Story.

Bi-Weekly Status

Report

Following each development Sprint, the contractor will report on their activities supporting testing and evaluation of the user stories in the

Sprint.

Within 1 day of the completion of each development Sprint

PSI Operational Test

Criteria

Following each Release, OT&E will develop suggested operational test criteria to be used for OT&E at the

Drop.

Within 1 week of the completion of each Release.

Drop OTRR Complete an Operational Test

Readiness Review

Prior to any

Operational Test directed by the government

Program OTRR Complete an Operational Test

Readiness Review

Prior to the Program

Operational Test event

OT&E Findings

Summary

Following each Operational Test event, the contractor will prepare an

OT&E Findings summary and present it to the T&E WIPT in advance of the final report

Within 15 business days of the conclusion of the

Operational Test

Event

Operational Test and

Evaluation Report

Following each Operational Test event, the contractor will prepare an

OT&E report

Draft: Within 20 business days of the conclusion of the

Operational Test

Event

Final: Within 30 business days of the

Operational Test

Event

Trip Report(s) A trip report delineating key items of discussion from the meeting attending.

As required, within

3 days of meeting completion.

8 PERIOD OF PERFORMANCE

The period of performance (PoP) for this scope is November 1, 2013 to October 31, 2014 with the option of two additional years.

9 AGILE PRACTICES

In the CSPO Agile Lifecycle, the Development Contractor, working in partnership with the government, is responsible for the activities and artifacts described by the Lifecycle for the

Release Planning, Development Sprints, and Hardening/Integration phases of the lifecyle. The

ACE Agile Software Development Quick Reference Guide provides specifics as to the activities and artifacts that will be used on the program.

In addition to responsibilities in the Release Planning, Development Sprints, and Hardening /

Integration phases of the Lifecycle, the Development Contractor will also assist in the Operations and Maintenance phase of the Lifecycle. Specifically, the Contractor will assist by successfully transitioning Releases to Operations. The Contractor will also assist with examination of maintenance issues for possible enhancements to the system that can be added to the Backlog as user stories that enhance system functionality.

9.1 Agile Values, Principles, and Prescribed Agile Practices

CSPO is adopting agile values, principles, and practices to guide program office oversight activities and software development. See the Agile Manifesto at www.agilemanifesto.org for a list of the four values and twelve principles that are guiding the program. CSPO 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, CSPO 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 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 file:///C:/Users/mmolloy/AppData/Local/Microsoft/Windows/Temporary%20Internet%20Files/Content.Outlook/E8E8ECKE/www.Agilemanifesto.org advantage of lessons learned. However, any additions or deletions to the practices stipulated here will need to be formally agreed to by the government.

9.1.1 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. CSPO will consolidate all work efforts into a single consolidated backlog. The effort to develop features identified in the product backlog will include development of new capabilities, re-factoring of existing systems and O&M of existing and new systems supporting cargo processing.

9. Release Planning. The development teams, in collaboration with the Product Owner, conduct on-going planning for each release, updating the plan at least once per Sprint.

This maintains the focus on maximizing customer value.

9.1.2 Development Practices

The Contractor shall use the following agile development practices:

10. Automated Builds. The process of building the system for a given environment (e.g., compiling, assembling, and deploying) is completely automated. This allows for quick and error-free migration of changes.

11. Continuous Integration. Each team member integrates their code with the mainline codebase at least daily, with each integration verified by an automated build. This provides rapid feedback on integration issues.

12. Refactoring. Continuous design improvement is part of the development cycle at both the micro and macro levels. This allows design work do be on-going as development proceeds, keeping the code maintainable.

13. Version Control. All system artifacts are maintained together in a version control system selected by the government. This enables rolling back to a previous consistent version and is an enabling practice for continuous integration and automated builds.

14. Coding Standards. All of the code looks as though a single competent programmer wrote it. This promotes easier understanding and editing of the code across the team.

Contractor coding standards will be approved by the government.

9.1.3 Testing Practices

The Contractor shall use the following agile testing practices:

15. Acceptance Criteria/Story Tests. The team collaborates with the Product Owner to establish detailed acceptance criteria for each user story. These acceptance criteria are outlined during Sprint Kick-Off and refined during the Sprint to constitute the acceptance tests for each story. This unifies the team on the specific functionality to be built and the tests to be run to verify that functionality.

16. Automated Unit Tests. Developers write unit tests for all new and changed code. All tests are kept passing at 100%. This prevents new or regression defects where individual sections of code do not behave as the developer intends.

17. Automated Functional Tests. Automated tests that exercise the system from the user interface are written for each user story. These are automated versions of the story tests.

This creates a set of tests that provides coverage of functionality sufficient for regression testing.

18. Continuous Testing. Developers, testers, and business operations experts work together to test each story as it is developed during the Sprint. This provides rapid feedback and shared understanding of progress and value.

19. Exploratory/Regression Testing. Exploratory and regression testing are performed daily. This ensures that new work does not break existing functionality, and provides quick feedback when such a situation does occur.

9.1.4 Communications Practices

The Contractor shall use the following agile communications practices:

20. Sprint Kick-Off. Sprints begin with a kick-off meeting between the development team and the product owner to discuss acceptance criteria and detailed design for each story.

This aligns the team on their work for the Sprint.

21. Sprint Review. The development team meets with product owner and other government stakeholders on the last day of the Sprint to review completed stories and receive feedback. This provides accountability for team and visibility to stakeholders.

22. Retrospectives. The development team holds a process retrospective at least once per

Sprint. This allows the team to reflect on how they are working and discuss potential improvements.

23. Daily Stand-Up Meeting. The development team meets daily to discuss the progress of current stories and tasks, and to expose obstacles to progress. This allows the team to reflect on how they are working and discuss potential improvements.

24. Team Room. Development team members are physically co-located in a dedicated team space. This promotes frequent face-to-face communication and collaboration.

25. Story/ Task Board. The development team uses a story and task board to radiate information about the current status of the team’s work. This allows at-a-glance visibility and transparency to team members and other stakeholders.

26. Burndown / Burnup Chart. The development team uses either a burndown chart or burnup chart or both to show the team’s daily progress in completing user stories. This provides a picture of the remaining work and time.

27. Information Repository. The development team has a single location where they store project and process related materials. This provides easy access to information.

9.1.5 Organizational Practices

The Contractor shall use the following agile organizational practices:

28. Lean Governance. The Contractor will keep oversight and governance as lean as possible to empower the teams. This pushes decision-making as close as possible to those doing the work.

29. Product Owner. The government will provide a product owner for each team who will act as the voice of the customer and the business for each Contractor development team.

This promotes business people and developers working together closely on a day-by-day basis.

30. Dedicated, Integrated Team. The Contractor development team will consist of dedicated people, collectively possessing all of the skills needed to deliver an increment of tested, deployable software. Whenever possible, once a person is assigned as a team member to a Sprint, he or she should be dedicated full time to that Sprint and that Team.

This fosters teamwork and shared accountability.

31. Task Sign-Up. Contractor Team members choose their tasks from the highest priority work available, rather than have it assigned to them by a manager. This practice fosters commitment from team members to the work, and also encourages team members to venture outside their typical roles to help in whatever way most benefits the team as a whole.

Sprint Architectural Reviews

During Sprint planning, user stories selected to be addressed during the Sprint are analysed by the agile team for architectural implications, and any technical stories assigned to the Sprint are coordinated with the Contractor Technical Lead for architectural constraints or guidance relevant to achieving the acceptance criteria of the story. Architectural issues that surface during the

Sprint are identified by the Agile Team Lead and the Contractor Technical Lead for consideration by the government Program Systems Engineer and presented to a dedicated government Architecture Team led by the Program Systems Engineer for resolution and/or inclusion in the Product Backlog as technical stories.

At the completion of each Development Sprint, the Contractor shall provide the government an updated System Design Document (SDD) that describes the current state of the evolving conceptual, logical, and physical system design including any technical debt that may need to be addressed. The government Architecture Team will expand the SDD to include the following content: HLS EA, business architecture, and OCIO portfolio alignment; service re-use planning;

and other system design documentation as required by DHS. The Contractor shall be responsive to any queries from the government Architecture Team to establish these necessary expansions on the SDD to satisfy DHS documentation requirements.

Release Architectural Review

The SDD provided at the final Release Sprint is used by the government Program Systems

Engineer, in consultation with the Contractor, to assess the state of the architecture and various systemic quality attributes such as performance; interoperability; security; reliability;

availability; scalability; reusability; maintainability; and configurability. The SDD is analysed for opportunities for refactoring and for any modifications needed to the architecture. The

Program Systems Engineer, Agile Team Lead, Contractor Technical Lead, and Product Owner coordinate appropriate architectural activities (e.g. addition of an architecture-focused sprint) to ensure systematic evolution of the architecture and management of technical debt.

Based on these regular recurring reviews, any evolving risks to the architecture will be addressed by adding technical stories to the backlog, or through dedicated architectural Sprints if needed.

The Product Owner in consultation with the government Program Systems Engineer prioritizes these technical stories in the backlog, and determines the need for Architectural Sprints.

Change Control

Changes will be managed by the Product Owner through prioritization and grooming of user stories contained in the product backlog. No changes shall be made to stories being developed within a current Sprint once Sprint planning is complete and the Agile Team has committed to the user story and the associated Definition of Done.

Any changes impacting user stories already delivered and accepted by the government will be considered as new user stories.

Status Reporting

Status reporting will be achieved using the agile communications practices outlined in this document. Specifically, status reporting will be achieved through Sprint kick-offs, reviews, and retrospectives; daily stand-up meetings and use of a team room; story task boards and burn-down and burn up charts; and use of an information repository. All these practices are established to achieve transparent communication among agile team members, and between the government and the Contractor. Other communications practices may be established as the program proceeds based on communications lesson learned identified during retrospectives.

Project Management and Development Tools

The Agile Teams will use tools for project and configuration management, issue tracking, document management, source control and other development support functions. The tools will be selected to by the government, in consultation with the Contractor.

Code Quality Metrics

At the completion of each development Sprint, the Agile Teams will produce quality software that meets or exceeds quality metrics. The metrics will be established using the CSPO Software

Development Metrics Guidelines as a reference and agreed to by the Agile Teams and the government as part of the Definition of Done.

10 GOVERNMENT FURNISHED EQUIPMENT

The Government will provide personnel with work areas equipped with a workstation, and have access to a laser printer, telephones, and general office supplies at the DHS CBP primary work location. Some work may be performed at other DHS CBP office locations throughout the

Washington DC Metro area.

11 ACCESS TO GOVERNMENT PROPERTY AND FACILITIES/PLACE

OF PERFORMANCE

The Government will provide access to appropriate resources within the DHS CBP facilities, including, but not limited to: related employees/ vendors/ developers/ consultants, appropriate work space, hardware, software, network connections, test and live data. Support of this task may also require travel to various CBP locations throughout the Washington DC Metro area, such as to conduct pilots. The primary location for work is:

US Customs and Border Protection

1801 N. Beauregard Boulevard

Alexandria, VA 22311

12 SUPPORT REQUIREMENTS AND INFORMATION

12.1 Holidays and Leave

DHS/CBP personnel observe the following days as holidays:

New Year’s Day Labor Day

Martin Luther King’s Birthday Columbus Day

Presidents’ Day Veterans’ Day

Memorial Day Thanksgiving Day

Independence Day Christmas Day

Any other days are designated by Federal statute, by Executive Order, or by the President’s proclamations. When any such day falls on a Saturday, the following Monday is observed.

Observance of such days by government personnel shall not be cause for an extension to the delivery schedule or Period of Performance, or adjustment to the price of this contract, except as set forth in the terms and conditions of the contract.

Without written consent from the COR, the Contractor may not be able to perform work in CBP facilities when they are closed. The Contractor will not charge any holiday as a direct or indirect cost. In the event that the Contractor’s personnel work during a holiday other than those above, no form of holiday or other premium compensation will be reimbursed as either a direct or indirect cost.

In the event DHS/CBP grants administrative leave to its government employees, Contractor personnel working in the DHS/CBP facilities shall also be dismissed if the facilities are being closed. In each instance when the facility is closed to Contractor personnel because of inclement weather, potentially hazardous conditions, explosions or other special circumstances, the

Contractor shall direct its staff as necessary to take actions, such as reporting to its own facilities or taking appropriate leave consistent with its internal company policies.

Tasks related to this contract are to stop at close of business on the last day of the PoP unless contacted by a CO, or unless terminated at an earlier date.

12.2 Contractor Resources

12.2.1 Key Personnel

The Contractor shall not make any personnel changes of key personnel unless an individual’s sudden illness, death or termination of employment necessitates such substitutions. In case of these occurrences, the Contractor shall notify the CO promptly and submit documentation pertaining to the proposed substitution in writing at least thirty calendar days in advance of the proposed substitution.

The Contractor shall provide a detailed explanation of the circumstances causing the proposed substitution. All résumés submitted for each proposed substitution must have qualifications that are equal to or superior to the qualifications of the person being substituted to perform the work under this contract.

The CO and COR shall evaluate the résumé of each request to verify the qualifications of every new employee being assigned to this contract.

12.3 Government Resources

The government and the Contractor understand and agree that the professional support services delivered by the Contractor to the government are non-personal services. The parties also recognize and agree that no employer-employee relationship exists or will exist between the government and the Contractor. The Contractor and the Contractor’s employees are not employees of the Federal government and are not eligible for entitlement and benefits given

Federal employees.

Contractor personnel under this contract shall not (1) be placed in a position where there is an appearance that they are employed by a government official, or are under the direct supervision, direction, or evaluation of a government official, or (2) be placed in a position of command, supervision, administration, or control over government personnel.

12.4 Security Clearances: Personnel Security Background Data

All personnel employed by the Contractor and/or responsibility to Contractor for work performed hereunder shall either currently possess or be able to favorably pass a full field five

(5) year Background Investigation (BI) required by CBP policies and procedures for employment. This policy further applies to any new personnel hired as replacement(s) during the term of this contract.

The Contractor shall submit within ten (10) working days after award of this contract a list containing the full name, social security number, and date of birth of those people who claim to have successfully passed a BI by CBP, or submit such information and documentation as may be required by the government to have a BI performed for all personnel. The information must be correct and reviewed by the designated CBP Security Official for completeness. Normally, information requested for a BI consists of SF-85P, “Questionnaire For Public Trust Positions,” or

SF-86, “Questionnaire for Sensitive Positions (For National Security)” TDF 67-32.5, “U.S.

USCS Authorization for release of Information,” FD-258, “Fingerprint Chart,” and a financial statement. Failure of any contract personnel to successfully pass a BI shall be cause for the candidate’s dismissal from the project and replacement by a similar and equally qualified candidate as determined and approved by the CO and the COR. This policy also applies to any personnel hired as replacements during the term of the contract.

The Contractor shall immediately notify the CO and the COR of any personnel changes. Written approval and confirmation is required for phone notification. This includes, but is not limited to, resignations, terminations, and reassignment.

In accordance with Customs Directive No. 51715-006, “Separation Procedures for Contractor

Employees (CF-242),” the Contractor is responsible for ensuring that contract employees separating from the agency complete the relevant portions of the CF-242. This requirement covers all contract employees who depart while the contract is still active including resignations, terminations, etc., or upon final completion of the work effort. Failure of a Contractor to properly comply with these requirements shall be documented and considered when completing

Contractor Performance Reports.

The Contractor shall notify the COR and CBP OIT Security and Technology Policy Branch

(EDME Division) of any changes in access requirements for its personnel no later than one day after any personnel changes occur. This includes name changes, resignations, terminations, and transfers to another contract. The Contractor Manager is responsible for the completion and timely submission to the COR of the CF-242 for all departing contract personnel. Contractor shall provide OIT/Information Systems Security Branch (ISSB) the following information on behalf of their personnel to telephone number (703) 921-6116 or fax the below information to

(703) 921-6570:

Full Name

Social Security Number

Effective Date

Reason for Change

The government may, at its sole discretion, direct the Contractor to remove any contract employee from CBP facilities for misconduct or security reasons. Removal does not relieve the

Contractor of the responsibility to continue providing the services required under any TO awarded under this contract without delay. The CO will provide the Contractor with a written explanation to support any request to remove an employee. Additionally, the Contractor shall not employ any person who is an employee of the United States government if that employment would, or would appear to, cause a conflict of interest

12.5 Government Furnished Information and Contractor Non-Disclosures

Any information made available to the Contractor by the government shall be used only for the purpose of carrying out the provisions of this contract and shall not be divulged or made known in any manner to any persons except as may be necessary in the performance of the contract.

Each contract resource hired under this contract will be requested to sign non-disclosure agreement.

12.6 Work Hours

The Contractor shall provide support, as directed, during core working hours, excluding government holidays, Monday through Friday (9:00 a.m.–3:00 p.m.).

Contractor employees shall typically work eight hours a day, five days a week, but may be required to work beyond this typical schedule. Contractor personnel shall work a consistent tour of duty of 40 hours per week, Monday through Friday, as well as work coverage on the weekends as required.

12.7 Overtime

The effort under this contract is subject to the Services Contract Act of 1965. Contractor personnel may not work more than forty (40) hours a week without prior written approval of the

COR. Approved overtime hours shall be invoiced at the normal hourly rate for this effort.

12.8 Identification Badges

Contractor employees shall be required to wear CBP identification badges at all times when working in government facilities.

12.9 Contractor Identification

The Contractor shall ensure that its employees identify themselves as employees of their respective company while working on DHS/CBP contracts. For example, Contractor personnel shall introduce themselves and sign attendance logs as employees of their company, not as

DHS/CBP employees. The Contractor shall ensure that their personnel use the following format signature on all official e-mails generated by DHS/CBP computers:

Name

Position or Professional Title

Company Name

Supporting the XXX Division/Office

U.S. Customs and Border Protection

Phone

Fax

Other contact information as desired

12.10 Mandatory and Other Training

12.10.1 Security Awareness and Records Management Training

Security Awareness and Records Management training for all agency personnel, Contractors, and other users about risks to agency information and information systems and their obligations in complying with agency information security policies and procedures is required.

A key objective of an effective IT security training program is to ensure that each employee understands his or her roles and responsibilities and is adequately trained to perform them. DHS cannot protect the confidentiality, integrity, and availability of its IT systems and the information they contain without the knowledge and active participation of its employees in the implementation of sound security principles.

The Contractor shall be responsible for ensuring that its personnel received and completed the requisite security training depending upon individual work effort and/or roles and responsibilities. Contractor personnel shall be required to complete one or more levels of DHS security training: 1) initial training in IT security concepts and procedures; 2) annual refresher training (if the effort duration is greater than 12 months); and 3) role-based training. Role-based training may be required for Contractor personnel who are involved in IT efforts and who are required to perform any IT security responsibilities.

DHS policy requires Contractors/Subcontractors receive security training commensurate with their responsibilities for performing work under the terms and conditions of their contracted agreements.