Atch_1_IDIQ_SOW.pdf

Food and Drug Administration

Food and Drug Administration

Office of Regulatory Affairs (ORA)

ORA Criminal Investigations, Imports, and Systems for Inspection, Recalls Compliance, and Enforcement (SIRCE)

Attachment 1: IDIQ SOW

Table of Contents

1. INTRODUCTION

1.1. BACKGROUND

1.1.1. Business Background

1.1.2. Technical Background

1.2. OBJECTIVES

1.2.1. O&M OBJECTIVES

1.2.2. DME OBJECTIVES

2. PROGRAM SCOPE

2.1. SCOPE OVERVIEW

2.2. TRANSITION

2.3. PROGRAM MANAGEMENT AND INTEGRATION

2.4. OPERATIONS AND MAINTENANCE

2.4.1. BACKGROUND

2.4.2. OPERATIONS SUPPORT

2.4.3. USER SUPPORT

2.4.4. RELEASE DEVELOPMENT AND MANAGEMENT

2.4.5. DATABASE ADMINISTRATION SUPPORT

2.4.6. COTS, GOTS, LIBRARIES, AND TOOL ADMINISTRATION SUPPORT

2.4.7. SECURITY RELATED SUPPORT

2.4.8. SYSTEM AND DATA DISPOSITION

2.4.9. USER EDUCATION AND TRAINING

2.4.10. MAINTENANCE OF PREDICT SCREENING RULES

2.5. DEVELOPMENT, MAINTENANCE, AND ENHANCEMENT (DME)

2.5.1. SOFTWARE DEVELOPMENT REQUIREMENTS

2.5.2. INFRASTRUCTURE SUPPORT

2.5.3. SECURITY SUPPORT

2.5.4. TRAINING SUPPORT

2.5.5. TRANSITION SUPPORT

2.5.6. MANAGEMENT ACTIVITIES

3. MANAGEMENT AND INTEGRATION

3.1. PROGRAM AND TASK ORDER MANAGEMENT

3.2. RESOURCE MANAGEMENT

3.2.1. STAFFING

3.2.2. ORGANIZATION

3.3. MEETINGS

3.4. REPORTING

3.5. INTEGRATION

3.6. TECHNICAL AND PROCESS IMPROVEMENT SUPPORT

4. GENERAL REQUIREMENTS

4.1. EARNED VALUE MANAGEMENT (EVM)

4.2. FDA ENTERPRISE PERFORMANCE LIFE CYCLE (EPLC)

4.3. ENTERPRISE AND SOFTWARE ARCHITECTURE

5. APPENDICES

1. Introduction

1.1. Background

1.1.1. Business Background

The U.S. Food and Drug Administration’s Office of Regulatory Affairs (ORA) is the lead office for all agency field activities. Amongst other regulatory activities, ORA inspects regulated products and manufacturers, conducts sample analyses of regulated products, and reviews imported products offered for entry into the United States. In pursuit of its mission, ORA also enters into contracts and cooperative agreements with its state, local, tribal, territorial and foreign counterparts as well as third parties. The FDA Office of Information Management and Technology (OIMT) supports ORA through the design, development, and application of information technologies to facilitate ORA operations and provide capabilities to meet ORA’s mission to safeguard the foods, drug, devices, biologics, veterinary, and tobacco products that the Agency regulates. The field users of the ORA systems work in 20 district offices, more than 150 resident posts and border stations, 13 laboratories, and several international offices. Other system users work in ORA headquarters organizations and in the compliance offices of every FDA Center. The daily work of these users includes field work, import operations, compliance and enforcement actions, and laboratory operations, as well as overarching needs to plan and manage their workload and to manage the shared information about the firms and products that FDA regulates. Users external to the FDA also use certain ORA systems, to support collaboration and communication between federal, state, and industry participants to achieve FDA’s public health mission. ORA systems are amongst FDA’s most heavily used, with over 6,000 total users and as many as 600+ concurrently.

In March 1992, the Commissioner of FDA established the Office of Criminal Investigations (OCI), with the urging of Congress, in response to concerns of increased criminal violations of the Federal Food, Drug, and Cosmetic Act (FDCA) and related acts. The mission of the OCI is to investigate suspected criminal violations of the FDCA; the Federal Anti-Tampering Act (FATA);

and other statutes including applicable Title 18 violations; and to collect evidence to support successful prosecution actions through the federal or state court systems, as appropriate. OCI’s role and responsibilities for the FDA is to identify and prosecute violators who import counterfeit, misbranded and/or adulterated FDA-regulated products that threaten the health and safety of the American public.

The Mission Accomplishment and Regulatory Compliance Services (MARCS) Investment was initiated to upgrade and replace many of ORA’s legacy systems. In 2016, MARCS was divided into the two current investments: 1) Imports and 2) Systems for Inspections, Recalls, Compliance, and Enforcement (SIRCE), to better manage ongoing efforts to modernize, maintain and enhance the 30+ applications and components within ORA’s portfolio of transactional systems managed by these two investments. Together, these systems support the operational work of ORA in the Agency’s imports and domestic regulatory responsibilities. The imports program staff require applications to support import entry review including support of the risk targeting process, Prior Notice review, fieldwork assignment, and compliance decision making for the millions of import entry lines that are received each year. The ORA systems also support business processes for planning and conducting inspections, federal/state partnerships, workload management, investigative operations, laboratory analysis, compliance work, and other mission-critical activities.

ORA supports four additional IT investments:

1) Criminal Investigations

2) Regulatory Business Information Systems (RBIS)

3) Automated Laboratory Management (ALM)

4) an Administrative Systems investment.

The Criminal Investigations Investment manages and maintains systems to support management of the mission of OCI. RBIS develops and maintains systems to enable and enhance analysis and reporting on ORA data, including a data warehouse, and is responsible for master data management (MDM) and data quality services. ALM develops and maintains systems used for ORA’s laboratories, including an integrated Laboratory Information Management System (LIMS). Many RBIS and ALM systems interface with the systems developed and managed within the Imports and SIRCE investments. Systems in the Administrative investment are not currently interfaced with Imports and SIRCE, but future collaboration may be expected. The systems under the Criminal Investigations Investment do not interface with systems managed under the Imports and SIRCE Investments.

1.1.2. Technical Background

The Imports and SIRCE investments currently manage the enhancement, and the operations and maintenance of over 30 applications and components (see Appendix A for a description of the current applications and components), including legacy applications and new services and components introduced to modernize and enhance the IT capabilities needed by ORA. Some of these functions are mission critical and must be operational 24 hours/day by 7 days/week. FDA (and various contractors) developed these systems over the last 15+ years using a variety of technologies. The environment is comprised of inter‐connected heterogeneous systems including Oracle 11g Web Forms and Reports applications, Java EE and Cold Fusion (CF) applications, Web services, as well as integration with various external systems. ORA is also developing and expanding the use of mobile systems for field operations, currently deployed using .NET on a Windows platform with plans to utilize technologies for implementation on Android and IOS based devices. Technologies used include web-based processing using tiered application architecture, load‐balanced application servers, single‐sign‐on authentication and firewall enabled security environment, multiple databases and database links, and FDA Intranet and Extranet topologies. Systems are deployed on Linux, Windows, and Oracle Exalogic servers and access Oracle 12c databases. Interfaces with mobile systems also utilize Windows servers and Sybase/Afaria products.

Imports and SIRCE systems interface with many other systems within FDA and ORA, as well as systems external to FDA, to access and to share data. The majority of the interfaces utilize direct database links and some utilize various other methods. For example, some data is extracted using Informatica to the ORA Reporting Analysis Decision Support System (ORADSS), which is used for most reporting and is part of ORA’s RBIS Investment. Appendix A “ORA Imports and SIRCE Systems and Components” provides an overview of the current systems and components to be addressed in this effort. Additional information on the interfaces is provided in Appendix B “ORA Imports and SIRCE Interfaces Overview”.

Like most FDA applications and databases, ORA applications and databases are deployed to, operated, and maintained in the standard System Development Lifecycle (SDLC) environments (Development, Testing, Training, Practice, Pre‐Production, and Production) in the FDA White Oak Data Center (WODC) in White Oak, Maryland, and in the Ashburn Data Center (ADC) in Ashburn, Virginia. The data centers are operated and maintained by a vendor under a separate contract. Data center contractors are responsible for operation and maintenance of the servers, network, and related infrastructure equipment and for provisioning of operating system and similar components of the environment. The infrastructure and security teams monitor the systems and infrastructure using a variety of tools, including AppDynamics and Solar Winds. In addition, FDA provides contractor support to perform Oracle database, middle-tier infrastructure and application server administration, and software upgrade support services work for ORA’s systems and environments, as well as to provide O&M support for the environments. The application Contractor provides application-specific detailed instructions for release installation, configuration, and implementation sequence steps. The application Contractor is responsible for application verification after system changes including OS and product patches, upgrades and server migrations.

To fulfill the mission as the law enforcement arm of the FDA, OCI requires a web-based electronic system to preserve the collection and management of criminal investigative case information and administrative functions. The availability of timely access to current and historical data for analysis and forecasting of trends involving FDA regulated products that threaten public health is critical to the mission. The current Automated Investigative Management System (AIMS) system is used by OCI to manage many of its administrative and investigative functions. The system utilizes an Oracle database as its relational database. The user interface has been developed using Oracle Forms. The reporting engine used is Oracle Reports. FDA/OCI anticipates that the new system will also be Oracle based. All data from the existing AIMS system will be migrated to the new system, including all investigative and administrative data, user information, role assignments, office assignments, attachments, history information and lookup values. Systems developed and maintained under the OCI Investment are managed in their own data center.

The contractor responsible for Imports, SIRCE, and OCI systems development and O&M must collaborate with the FDA and contractor staff responsible for the data centers as well as other contractors selected to develop operational and reporting systems outside the scope of the contract. The services procured in this contract will include responsibility for specification of system architecture, hardware, and component design. The contractor shall provide guidance on configuration of COTS products used by the application software, and assist in troubleshooting operational issues from the application perspective. Although none of the systems currently managed within the Administrative Investment have been developed or maintained by the incumbent, ORA may choose to develop a system managed under another investment under this contract.

None of the systems within the scope of this contract are currently deployed into a commercial cloud environment; however, migration to cloud-based hosting or implementation of a cloud solution is possible during the period of performance of this contract. FDA may consider the full range of cloud services dependent on the security requirements and business needs, including infrastructure as a service, platform as a service, and software as a service. Contracts are available with several FEDRAMP approved providers including Amazon, Salesforce, and Appian. Other providers will likely be added during the contract period, and only approved providers will be allowed.

1.2. Objectives

The objective of this contract is to continue the efforts to modernize and enhance the IT capabilities of ORA while maintaining a reliable, stable and secure operating environment aligned with the HHS and FDA Enterprise Performance Life Cycle (EPLC) processes (Appendix C) with the goal of driving down developmental and operating costs. The contracted effort will include both development, modernization, and enhancement (DME) and software applications operations and maintenance (O&M) for the Imports, SIRCE and Criminal Investigations investments. Overall objectives include:

• Achieving a high level of user satisfaction with ORA IT solutions.

• Providing reliable IT solutions that enable ORA to meet business needs.

• Deployment of high-quality code that accurately meets the requirements.

• Successful releases without introduction of unexpected problems.

• Minimal need for emergency/corrective maintenance.

• Minimal need to fix the same issue multiple times.

• Maximum value out of limited IT budget resources.

1.2.1. O&M Objectives

• Ensure that ORA applications are available and operate effectively to meet business needs on a 24x7 basis.

• Collaborate with data center and other contractor staff to maintain system operations for all environments through prompt troubleshooting and resolution of issues.

• Respond rapidly to tickets initiated by system users, through a Tier 3 Help Desk, to promote a high level of customer satisfaction and meet the expectations established in a Service Level Agreement (SLA).

• Complete system modifications that fix application problems caused by design, logic, or coding errors.

• Reduce the cost of O&M tasks through improved processes and the resolution of software and environmental issues.

• Recommend and implement improvements to minimize the need for system outages during maintenance (planned) and the occurrence of unplanned outages, and to reduce the time needed to recovery after such outages.

• Assess operational systems to provide recommendations for upgrades to maintain compatibility with current versions of COTS in use and to improve performance, maintainability and reliability.

• Resolve all system related security issues in accordance with the Plan of Action and Milestones (POAM) and Security Assessment Report (SAR).

1.2.2. DME Objectives

• Improve software quality, process efficiency and repeatability, and code reusability by adopting proven, new, and innovative software development methodologies and quality control processes that work within the constraints of the FDA environment.

• Replace specific modules or entire ORA legacy systems with software that aligns with the ORA Reference Architecture (Appendix J), supports a more intuitive workflow, and reduces the amount of time required for users to complete their business tasks.

• Increase integration amongst systems while reducing the reliance on stove-piped single-purpose systems.

• Reduce the cost of Operations and Maintenance by replacing problematic systems with software that utilizes modern architecture and design principles, including improved error handling and logging.

• Rapidly and efficiently respond to legislative mandates requiring system changes to implement updates by the required dates.

• Reduce the cost of future enhancements by using software designs that can be efficiently configured, upgraded, and improved.

• Provide systems and components meeting FDA Enterprise Architecture standards and 24x7 availability objectives.

• Maximize the use of re‐usable components and establish a repository of re‐usable components.

• Maximize flexibility for connecting to third party (commercial products, Center databases, other Agencies) data stores via native configuration.

• Support ongoing technology enhancement and deliver an improved user experience, including improved mobility and the use of multiple devices and operating systems, where approved by FDA.

• Ensure that system performance is maintained at or improved over response time relative to the existing system performance level.

• Streamline database design to increase performance and reliability while increasing the standardization and accuracy of data.

• Minimize data duplication across operational systems by centralizing data.

• Ensure system security by developing and enhancing systems to meet current National

Institute of Standards and Technology (NIST) guidelines and all applicable security requirements.

2. Program Scope

2.1. Scope Overview

The scope of this multi-year IDIQ includes maintenance of existing and new systems and modernization and enhancement. Overall tasks encompass system development, integration, operation and maintenance including legacy systems. Several components, services, and systems are developed and integrated into a larger system to support a complete business operation.

Some of the legacy systems will be phased out gradually or integrated into the modernization and enhancement efforts.

The Contract shall issue tasks for operations and maintenance for systems maintained under the Imports and SIRCE Investments as well as new software development activities for systems within the ORA Imports, SIRCE, and Criminal Investigations investments. The Contractor shall provide technical services and O&M support for both legacy and newly integrated systems and services. The support includes activities to maintain the systems in a fully functional state, and to implement software changes to address defects and minor enhancements. For new development, the Contractor shall perform full system development lifecycle activities to implement enhancements and new functionality within existing systems as well as develop new modules, components, services, and systems to meet the evolving ORA business requirements.

The Government anticipates awarding tasks that include, but not limited to:

• Transition, for a period of overlap with the existing contractor, leading to the new contractor assuming the responsibility for all O&M and DME activities and support duties from the current contractor. The government anticipates a transition-in task at the start of the contract, for the new contractor to prepare to assume responsibility from the incumbent, and a transition out task at the end to transfer knowledge to a follow-on contractor.

• Program Management and Integration, including all activities to:

o Manage cost, schedule, and quality.

o Manage risks and issues.

o Communicate with the government and other stakeholders.

o Provide quality staff to conduct the work.

o Ensure the overall program is integrated and meets the objectives.

o Provide high-level guidance and coordination to the development and O&M teams to identify and address interdependencies.

o Establish and enforce standards and processes, such as coding and architectural standards, that ensure FDA and ORA guidance are followed.

o Perform Systems Integration, to ensure the work of multiple efforts, which may be conducted by different contractors, is conducted in a manner that results in an optimal system meeting the business need. The Contractor shall provide recommendations to the government on an ongoing basis regarding programmatic and technical issues and support the efficient collaboration across the different tasks impacting the overall system. FDA leads a governance process to ensure compliance with FDA and ORA architecture goals.

Management activities at both the Program and Project level are further elaborated in Section 3.0.

• Operations and Maintenance o Software Maintenance includes:

1) the development and implementation of bug fixes and minor enhancements

2) support to ensure upgrades to operating systems, databases, and interfacing systems. Minor enhancements are typically less than 200 hour of effort each.

o Operations support includes:

1) monitoring of applications to ensure they are functional

2) providing Tier 3 support to respond to and resolve issues identified by system users.

• Development, Modernization, and Enhancement (DME) includes introduction of new or modified functionality or scope that requires the re-engineering and/or enhancement of an existing system, the re-platforming of a system to a new technical architecture, or the development of a new system. DME tasks may also include projects such as major COTS upgrades that require significant modifications to current systems and extensive testing. DME tasks frequently impact multiple systems and support several ORA initiatives within a single task. Due to the complex nature of the ORA systems, some tasks may be issued for specific phases of the life cycle, such as feasibility studies or the gathering of high-level requirements and/or the development of a concept of operations prior to the commencement of a full software development process.

In addition, certain DME tasks may be conducted through other contracts, for example, where specific skills and experience are needed that are not available through this IDIQ. Examples include projects underway prior to award of this contract and customization of COTS where the expertise of a vendor (or partner) is needed. Software developed in those efforts may be transitioned to this Operations and Maintenance task following successful implementation and will become part of the scope of the task. The Imports and SIRCE systems also have many interfaces to systems developed and maintained under different contracts. The Scope for each of these types of tasks is described in more detail below. Statements of Work will be issued for each task, detailing the specific scope of the task to be issued.

2.2. Transition

The purpose of the Transition tasks is to provide an orderly transition from the incumbent Contractor to the successor Contractor and to ensure the incoming Contractor has sufficient knowledge of the Imports and SIRCE systems to maintain and enhance the software. It is the responsibility of both the incumbent and the successor Contractors to ensure a smooth transfer of knowledge. The successor Contractor shall work toward the Government’s goal of ensuring minimal disruption to services and support for users. The government anticipates task orders will be issued to ensure a successful transition at both the start and end of the contract.

Working with the Contracting Officer’s Representative (COR) and other government staff, the Contractor teams shall develop and agree to a plan to prepare the successor to take over on‐going work from the incumbent Contractor. The government anticipates that the transition periods (including planning) shall require both contractors to perform transition activities for a period of up to six months starting at the task order award. During this time, the incumbent Contractor shall be responsible for ensuring transition‐Out activities are completed to provide for a successful and complete knowledge transfer. The outgoing Contractor will be responsible for providing system and process documentation and the teams shall hold knowledge transfer sessions based on a schedule established in the transition plan.

The successor Contractor shall perform tasks that include, but not limited to:

• Propose a viable approach to transfer knowledge from the incumbent as the basis for a formal joint transition plan.

• Conduct and coordinate all on‐boarding activities with the Government and obtain secure badging for team personnel.

• Complete actions necessary to obtain access to the systems and operating environments.

• Familiarize themselves with ORA business objectives, processes, and requirements as related to the systems being supported.

• Review and understand the available system and process documentation.

• Collaborate with the incumbent contractor to gain a thorough understanding of the technical and procedural knowledge necessary to take over O&M.

• Conduct an operations readiness review to demonstrate that the successor team is prepared to assume responsibility for O&M.

2.3. Program Management and Integration

The Contractor shall perform management activities for the overall Program and for all systems and projects that are awarded. The Contractor shall manage cost, schedule, and quality on a day‐ to‐day basis, following program and project management best practices. The Contractor will develop and implement a Program Management Plan addressing all phases of the project life cycle to ensure project and overall program goals are met. This will include activities to ensure overall coordination and integration of the O&M and DME tasking such that the teams conducting the work do so with common vision, objectives, and processes.

Specific Program Management and Integration requirements are addressed in Section 3.0.

2.4. Operations and Maintenance

2.4.1. Background

Imports and SIRCE Systems Operations and Maintenance (O&M) activities focus on routine operations and maintenance support necessary to maintain the availability, reliability, and security of ORA Systems. The Contractor shall provide the full range of typical O&M support services including:

• Issue identification, tracking, analysis, and resolution.

• Code generation, testing, and documentation.

• Release Management.

• Configuration Management.

• Change Management.

• Maintenance of tools, custom code, system, software, and database configurations, customizations, and process automation such as scripts, templates, and workflows.

• Performance tuning and monitoring.

• System administration.

• User account administration.

The O&M activities follow the FDA EPLC processes for system development lifecycle activities.

O&M is closely integrated with ongoing enhancements and requires the Contractor to work closely with OIMT and ORA as well as other contractor teams. Software releases for most systems may contain both O&M and DME content (e.g., bug fixes and enhancements may be included in a single release). The O&M Contractor shall be responsible for successfully planning and completing all work necessary to support the O&M objectives included the areas below.

2.4.2. Operations Support

The Production instances of the ORA Imports systems and SIRCE systems are currently housed in a contractor-managed FDA data center. The data center is designed to provide high availability needed to support ORA business operations that are in use around the clock 365 days/year to support public health and international trade. The Contractor shall support these systems during both normal business hours (8 am to 9 pm Eastern Time, Monday‐Friday) and at night and on weekends for those systems in use outside of normal business hours. The major ORA Imports and SIRCE systems are expected to be available on a 24x7 basis other than scheduled maintenance, which is typically conducted at night on the weekend. The Contractor shall verify the functioning of the systems after patching and other scheduled maintenance, typically via smoke tests. The Contractor shall collaborate with the data center and other FDA contractors and government staff in taking the necessary steps to monitor the systems and restore full service after any outages, planned or unplanned. Historical data on unplanned outages is provided in Appendix D. To meet the FDA objective of supporting both internal and external users, the Contractor will need to undertake a proactive effort to identify potential weaknesses or gaps in the applications and the overall system, and work with FDA to address those potential issues.

Note that the OCI systems are currently hosted in a separate FDA-managed data center.

Contractor staff do not access the OCI Production systems, but the Contractor may be asked to provide infrequent consultation to support troubleshooting.

2.4.3. User Support

The Contractor shall provide technical support for the ORA Imports and SIRCE applications to triage, troubleshoot, and respond to user calls about the supported systems, and to resolve issues identified. ORA maintains a Help Desk (the “Apps Desk”) that serves as the initial point of contact for FDA users as well as external support staff that are contacted by users external to FDA. FDA uses a ticket tracking system (currently Service Now) to enter and track tickets for the issues reported by users. The Apps Desk provides “Tier 1/2” support for many routine user issues, such as account issues, user instruction on procedures and workarounds (based on a knowledge base), and minor data corrections. The Contractor shall maintain a “Tier 3” Helpdesk to respond to user issues requiring a deeper understanding of the applications and environment.

This requirement overlaps with the Operations Support effort (Section 2.4.2) and an SLA will be established to address expectations for responding and resolving calls from for User or Operations support. The Contractor shall propose an approach to meet the SLA providing support 24x7 in the most cost effective manner. A summary of the historical data on Tier 3 Help Desk Tickets is provided in Appendix E.

2.4.4. Release Development and Management

O&M includes the development of software releases for the supported systems. The FDA categorizes releases as Initial, Major, Minor, or Emergency/Patch. These release types are defined as:

• Initial Release: Scheduled first release of a new system.

• Major Release: Scheduled release to include defect corrections, technology upgrades, major enhancements, and/or redesigns.

• Minor Release: Scheduled release to include defect corrections and/or minor enhancements, including software changes necessary to support system or COTS patches.

• Emergency Release: Release to correct one or more problems with a system that is negatively impacting ORA and requires prompt resolution. Emergency Releases are added to the project schedule as needed upon approval by the CCB.

The scope of the O&M effort in this contract is limited to Minor and Emergency/Patch Releases.

However, to improve efficiency, O&M releases are frequently combined with DME releases.

O&M content (for example, bug fixes) may be implemented as part of a Major Release, as the DME and O&M contents are packaged into a single release. These releases are for both legacy and newer systems whenever bug fixes or minor updates are needed to support business processes or data quality. To ensure the O&M team has access to the code and information necessary to support the systems in Production, the O&M contractor will be responsible for all release management for those systems considered in O&M scope. FDA is implementing Dev/Ops processes, including automated deployments, currently using Puppet. The Contractor will support the development of scripts to support automation where possible throughout the build and deployment process.

2.4.5. Database Administration Support

The build, configuration, and routine maintenance of databases for the ORA systems is performed under a separate contract; see Section 1.1.2 for additional details. As part of this task, the Contractor works with the database and data center contractors and government team to provide expertise in database administration support specific to the ORA systems. These activities support O&M and DME releases, resolution of issues attributed to the database or data, and database upgrades. Many tasks require collaborative effort across teams with access privileges assigned to meet security requirements.

2.4.6. COTS, GOTS, Libraries, and Tool Administration Support ORA systems use a set of approved commercial off‐the‐shelf (COTS), government off‐the‐shelf (GOTS), software libraries, and tools. The current technologies used by these systems are identified in Appendix F. The Government supplies all software to be used under this contract and the Contractor shall only use the Government approved software. Note that any additional tools recommended by the contractor, including those tools used in the software development or O&M processes, must comply with the policies and procedures around the FDA Master Approved Technology List (MAT) and the FDA’s approved architecture, and receive FDA approval before implementation in any environment or on any laptop or workstation. The Contractor shall provide technical input for the installation and configuration of any software used in the ORA Imports and SIRCE applications.

2.4.7. Security Related Support

ORA Imports and SIRCE systems are required to meet all applicable security standards to comply with Office of Management and Budget (OMB), Federal Information Security Management Act (FISMA), Federal Risk and Authorization Management Program (FedRAMP), Department of Health and Human Services (HHS), and other federal government security requirements, see Section 4.3. FDA requires and Authorization to Operate (ATO) for all systems, with a renewal every three years and when major changes are implemented. These security reviews require updates to documentation and participation in meetings and system demonstrations, which can occur at various times throughout the cycle. In addition, security aspects of annual operations review and contingency planning require contractor input.

2.4.8. System and Data Disposition

The final stage in the EPLC is system disposition, when the system is no longer in use. As ORA completes the replacement of older systems, the current software will be retired. The lifecycle process may involve the retirement of an entire system, or select modules in cases where the replacement occurs in stages or pieces of code are no longer needed. System disposition requires careful planning to communicate the upcoming changes to the stakeholders and remove user access once the replacement system is in use. Activities also include archiving of application software and data and completion of final documentation. Approximately 6 systems or components have been retired in the past 5 years.

2.4.9. User Education and Training

The ORA Office of Training Education and Development (OTED) is responsible for formal user training. ORA’s Office of Information Systems Management (OISM) staff and business owners also provide guidance and technical assistance to users on how to use the systems. The Contractor shall support ORA by maintaining environments with functioning systems to be used for developing training, conducting training classes, and for practice by students and other users.

The Contractor shall prepare data for training courses. In addition, the Contractor shall provide training support including providing updates on system changes and assisting in creating and updating training materials and communicating changes to users.

2.4.10. Maintenance of PREDICT Screening Rules

In addition to support for the PREDICT and the Rules Studio software, O&M support to Imports includes the development of new screening rules using the coding language native to the rules engine(s). The rules are built to operate using a proprietary rules engine licensed from NTELX (http://www.ntelx.com/case‐studies/fda/) based on information known about each FDA‐regulated line offered for import. Typical factors in these rules include the firms involved in the shipment, the types of products, prior history of testing, and other factors indicative of the risk associated with that import. Approximately 500-1000 rules are currently in use for admissibility screening (801 (a)), and the contractor adds or updates approximately 2 rules/week. The rules are used to screen approximately 30 million entry lines/year, a volume that continues to increase each year.

ORA staff have the capability to create and manage PREDICT rules using templates; however, certain rules require manual coding due to the complexity of the rules and limitations in the available templates. The maintenance of the PREDICT system also necessitates ongoing troubleshooting to assess the functioning of the rules through investigation into cases where rules have fired unexpectedly, have failed to fire for lines that are expected to meet the conditions, or other unexpected results.

The PREDICT Dynamic Targeting (PDT) system runs a version of the NTELX nxAnalyzer software which is based on the Drools Business Rule Engine. Maintenance and support of PDT includes ongoing support of the Drools-based NTELX nxAnalyzer, and minor updates to the business rules which are evaluated by the nxAnalyzer software.

2.5. Development, Maintenance, and Enhancement (DME)

ORA has an ongoing need for enhancements to its portfolio of systems. These enhancements do not include minor changes to an existing ORA System (those performed under O&M Section

2.4.4 above). DME projects will add functionality to existing ORA Systems to address new legislative or regulatory mandates, emerging health concerns, and shifting FDA priorities.

Enhancements are needed for both legacy and newer systems to meet evolving business needs.

Changes to existing systems are frequently required when new systems, services, or components are introduced, due to the many interfaces between systems. DME typically includes requirements analysis, design, development, testing, and deployment of changes and enhancements to existing systems to engender new or modified. DME may also include development of future systems, consolidation of systems, integration of systems for improved data sharing, and/or the expansion of the existing systems to support other program areas in the Agency or potentially from other Federal Government and/or State agencies. All of these services will include coordination with the infrastructure support vendor(s) and vendors from other systems that interface with the ORA Imports and SIRCE systems.

The Contractor shall perform DME activities in support of the ORA Imports, SIRCE, and Criminal Investigation needs as well as support integration efforts with systems managed outside the scope of this contract. In addition, these system enhancements can include technical upgrades, such as migration to a new data center or to “the cloud”. The level of effort required for these enhancements varies widely, as does the lead time between identification of the need and the required implementation date. ORA determines the number, frequency, and complexity of these enhancements based on the number and type of outstanding change requests (CRs), anticipated regulatory/legislative mandates, urgency of the need and funds availability.

2.5.1. Software Development Requirements

To ensure software enhancements and new systems function as needed and integrate with existing systems and new work conducted by other development teams, the Contractor is expected to follow a standard process for all development work. The Contractor shall establish a Software Development Plan (see Section 3.3) and shall meet the following requirements for all release development efforts, whether performed as part of DME or O&M task orders.

The Contractor shall follow the FDA EPLC for all software development efforts (see Section 4.2). The EPLC specifies the documentation to be provided for each software release. In addition to the formal deliverables required by the EPLC, for certain releases, the Contractor shall provide informal documentation and presentations to support Requirements, Design, and Conformance reviews. These reviews are intended to provide technical input and guidance during the development process. All work will be conducted using FDA-provided environments, equipment, and software. ORA Imports and SIRCE projects have been using an agile development methodology. However, the draft Software Development Plan in response to this RFTOP may propose alternate methodologies for some, or all, tasks. The Contractor shall follow an internal code review process and document the process as part of the Software Development Plan. The Contractor shall provide the code, when requested, for independent code review and/or review of the contractor code review results by OIMT and ORA staff. The Contractor shall store all software code (e.g., forms, reports, JAR files, configuration files, scripts, etc.) in the FDA configuration management tool. The Contractor shall develop all software in accordance with FDA’s Enterprise Architectural standards (Section 4.5).

The Contractor shall document, track, and trace requirements using FDA/ORA established tools throughout the lifecycle of the system. The Contractor shall analyze requirements gathered to ensure alignment with the following:

• FDA/ORA business processes.

• Existing database structures.

• Existing system designs.

• Data quality and interfaces with existing internal and external systems.

• Data Standards and guidelines.

• FDA technology standards and policies.

• FDA Enterprise Architecture and ORA Reference Architecture standards.

• Required security models and standards.

In addition to functional requirements, the contractor shall establish a set of architecturally significant requirements driven by business and IT needs and goals. These requirements shall be focused on non-functional concerns relevant to the project such as performance, security, maintainability, portability, interoperability, and reliability. To the extent possible, these requirements shall be measurable so as to serve as a concrete benchmark for design reviews. A requirements review shall be conducted to ensure these architecturally-significant requirements are adequately specified and agreed upon by business and IT.

Architecturally-significant requirements determined by the business and IT as important, shall be given priority during release planning alongside other high priority functional requirements. It is expected that these requirements be captured in the product backlog and tracked to ensure they are designed and implemented. It is also expected that the Contractor shall use the architecturally-significant requirements to drive design decisions. The same applies to proof-of-concept and pilot projects.

The Contractor shall conduct design reviews to ensure that proposed designs are well-thought through and relevant quality attribute concerns are addressed. During the initial design review a baseline set of design artifacts shall be established (e.g., architecturally significant requirements, component view, deployment view). If architecturally significant requirements or other functional requirements will be implemented incrementally, then it is expected that incremental design reviews shall be conducted to flesh out the designs for that increment. During design reviews, contractors are expected to provide evidence that they have considered the architecturally significant requirements in the design.

Contractors shall perform conformance reviews to ensure that the implementation conforms with the design defined during design reviews. It is expected that any discrepancies between design will be corrected to ensure conformance.

The Contractor shall be responsible for the application of the approved design standard to the applicable ORA systems while performing programming activities and using languages consistent with FDA standards and technologies. Existing systems may not fully conform with the current FDA technology standards, the FDA Enterprise Architecture, or the ORA Reference Architecture. While any new systems, components, or services will be expected to conform, the Government will consider the level of effort in assessing the need for conformance when existing systems are being enhanced or upgraded. The Request for Task Order Proposal will specify the standards and requirements for each development effort. The Contractor shall be responsible for delivering application software that is fully functional, meets requirements, and can be implemented in the FDA environment. When agile development is used, the Contractor shall deliver the agreed upon work products at the completion of each sprint. The work product shall include source code and executable code. The Contractor shall support and work with OIMT, other vendors, and various offices within ORA throughout the whole EPLC to ensure successful implementations of releases.

The Contractor shall coordinate and perform test activities for ORA, including the following:

• Unit Testing

• System Testing

• Integration Testing

• Performance and Load Testing

• Regression Testing

• 508 (Accessibility) Testing

• User Acceptance Testing

• Smoke Testing

The Contractor shall identify each applicable test as a milestone in the task schedule. The amount and type of testing shall be commensurate with the size, scope, and risk of the specific release as mutually agreed upon by the Contractor and documented in a Master Test Plan and Release Test Plan (where applicable). The Contractor shall utilize automated testing where possible and cost effective. The testing shall be conducted using approved test tools provided by FDA, such as Cucumber, Selenium, HP ALM, and Load Runner.

The Contractor shall modify and retest code to resolve errors found during unit, system, integration, regression and 508 compliance testing and confirm that code is ready for user acceptance testing. Code deployed for User Acceptance Testing (UAT) should be free of any defects that will prevent users from completing planned tests or interfere with completing the expected usage of the software. UAT is the critical step for identifying whether a product is ready to be deployed. The Contractor shall prepare a UAT plan for each release, in conjunction with OIMT and ORA, to identify the users, applicable test procedures and data, and an approach to ensure testing reflects how the software is used across the user community. In many cases, the Contractor will hold a UAT kickoff to provide an overview of the release content. The Contractor shall investigate issues identified during UAT and resolve defects as needed.

The Contractor shall document all changes in the approved change control tool, provided by FDA (currently Subversion or Git for source code management, JIRA for defect tracking). The Contractor shall provide updated documentation for each release, including EPLC documents and release documents following the processes identified in Appendix C, and shall support resolution or mitigation of issues and risks identified throughout the process.

The Contractor shall coordinate with OIMT for performance testing to ensure that all standards and requirements are being addressed. Prior performance test results will be provided as a baseline where available. However, the Contractor shall conduct performance testing as needed to establish a current baseline prior to testing a new release. The Contractor shall allow for independent review of test results by OIMT and ORA staff.

2.5.2. Infrastructure Support

The Contractor shall coordinate with OIMT and the data center teams to ensure infrastructure is ready for each stage of the software development life cycle. This shall include the preparation of requests for any hardware needed for each environment, the preparation of needed documentation (to include Target State Diagrams and Version Description Documents), and the preparation of installation scripts. The Contractor shall also provide technical input, configuration recommendations, and support for testing to support the implementation of firewall rules and other aspects of infrastructure set-up.

2.5.3. Security Support

The Contractor shall develop software that will be fully compliant with all aspects of FDA security requirements (see Section 4.3). This includes the preparation of required documentation, testing during development, support for independent penetration and other security testing, and steps to resolve any issues identified. Security issues originating in the FDA infrastructure will be addressed by the data center teams; however, the Contractor shall conduct testing and development activities as needed to ensure the systems function as expected following any infrastructure changes. Each Production system is required to be addressed in an Authorization to Operate (ATO) and the Contractor shall support activities needed to obtain, update, and maintain the ATO.

2.5.4. Training Support

During release planning activities, the requirements for training activities will be identified, defined, and documented in the system training plan.

The Contractor shall perform the following training support activities:

• Confer with ORA’s OTED and/or OISM to determine the approach for training, the specific needs for training materials, and support and how much time will be needed to provide training to the field before and after production deployment of all Major Releases.

• Provide FDA staff with information for all new functionalities and changes for each new release.

• Provide the release notes, screen shots and other documentation, and provide system demonstrations at FDA’s request. FDA will assess the changes and determine the need for user training or modification to existing training materials.

• Assist in preparing or modifying training materials as requested by FDA.

• Verify and validate the information in training materials produced by the Contractor and

ORA.

• Prepare environments that will be used for training ensuring all functionality is up-to-date and working as expected and providing data needed for training.

• Provide demonstrations and presentations using live or recorded video, or in person.

Note that any specific requirements to lead training will be specified in a task order when needed. In most cases, FDA staff will lead training activities. Any travel to FDA sites to support training will also be included in the task order specifications.

2.5.5. Transition Support

The Contractor shall support the transfer of knowledge to transition DME releases to the teams responsible for support of Operations and Maintenance.