Attachment_1,_Base_Contract_PWS_v2.docx

Table of Contents

Figure 1. DERT – GADS APPLICATION SUPPORT MODEL 1

ATTACHMENT 1- BASE CONTRACT PERFORMANCE WORK STATEMENT - (COMBINED SYNOPSIS/SOLICITATION NO. 7596019Q00009)

13 | Page

C.1 PURPOSE

The purpose of this procurement is to obtain services related to the Operations, Corrective Maintenance, and Development/Modernization/Enhancement (DME) of National Institute of Environmental Health Sciences (NIEHS) Grants Application Development System (GADS) applications, and other related Information Technology (IT) systems that support the NIEHS Division of Extramural Research and Training (DERT).

The current applications and utilities within scope of this effort include IMPAC II Database Consolidation (IDC), Grants Funding Decision Tool (GFDT), Supplement Operations System (SOS), High Impacts Tracking System (HITS), Travel Management System (“TRIPS”), Partnerships for Environmental Public Health Program Resource Center (PEPHRC), Who We Fund (WWF), Scheduled Tasks, Study Section Calendar (SSC), and Grants Budget Forecasting Tool (“BUDFORE”). For purposes of this document the terms “application”, “service”, and “utility” are used interchangeably.

Consistent with NIEHS and Federal goals of enterprise, shared-solution, and service-based approaches to information technology: services may also be required to develop new application or tools, consolidate and/or integrate applications, develop interfaces with other systems/services, and expand the existing systems to also support other program areas, and, potentially, support data and requirements from other Federal Government agencies and their respective grant processes.

Work outlined in this performance work statement (PWS) is directly related to the following Strategic Goal: The Contractor shall provide innovative, integrated, and cost-effective IT solutions that increase efficiency, reduce data entry, reduce GADS system operations costs, and reduce manual/paper-based administrative burdens for staff and grantees in order to meet DERT objectives and its mission.

C.2 BACKGROUND

The NIEHS is one of 27 Institutes and Centers (ICs) of the National Institutes of Health (NIH), Department of Health and Human Services (HHS). The mission of the NIEHS is to reduce the burden of human illness and disability by understanding how the environment influences the development and progression of human disease.

The NIEHS DERT reviews, awards, and administers a substantial portfolio of research applications and grants in the field of environmental health sciences. Approximately 1,500 grant applications are processed each year, representing approximately $320 million in investment. Investigators in many disciplines at various agencies, universities, and organizations conduct this research. Extramural research activities range from basic mechanistic research, research involving laboratory animal models and systems, to clinical and epidemiologic studies using human subjects. NIEHS‐supported investigators are currently determining how environmental agents cause or exacerbate a variety of human diseases and disorders.

To manage the grant process DERT utilizes an Oracle database, combined with a set of tools, utilities, applications, and business function modules (developed at, and operated by NIH) called the Information for Management, Planning, Analysis, and Coordination (IMPAC II) system. IMPAC II is used to track grant applications from the moment of receipt of application to the end of the grant application life cycle. It is used by all NIH ICs as well as other federal funding organizations. DERT uses IMPAC II to track, manage, and make decisions on current and future grant funding.

In addition to daily use of IMPAC II, NIEHS currently utilizes approximately twenty (20) custom written applications and utilities for managing the NIEHS grant process. These range from small database queries to external facing Web-based applications, which utilize data from IMPAC II tables. Collectively, this combination of applications and utilities define the GADS suite of services. The NIEHS Office of Information Technology (OIT) manages the NIEHS data center that hosts the GADS applications and utilities.

Acquiring past IT services in support of GADS, DERT has utilized two successive task orders under the NITAAC CIO-SP3 Small Business Government-Wide Acquisition Contract (GWAC) (“GADS I” and “GADS II” respectively). Hence, the Government refers to this contract as GADS III (GADS3).

C.3 PROGRAM OBJECTIVES

DERT’s vision for Grants Application Development System (GADS) is to:

· Automate or increase efficiency of grant management and administrative processes.

· Retire manual and/or paper-based processes.

· Reduce reliance on stove-piped, single-purpose solutions.

· Streamline database design to increase performance and reliability.

· Centralize data where feasible (single-source) and share via services.

· Increase accuracy and standardization of data.

· Reduce data entry burden for grantees and staff.

· Better utilize existing data for improved analysis, reporting, and decision-making.

· Improve system design, interface, usability, and user-friendliness.

· Reduce reliance on manual data corrections to reduce overall operational costs.

· Improve quality of system releases to minimize need for corrective maintenance.

· Enable additional NIH grant programs to leverage the GADS systems for cost savings.

· Further enhance systems with stronger financial controls for improved accountability.

· Develop/Enhance public-facing interfaces for improved transparency.

· Utilize innovative web technologies for integrated and cost-effective solutions.

· Rapidly and efficiently respond to legislative, NIH, NIEHS mandates requiring system changes.

· Reduce overall costs to operate/maintain GADS systems.

DERT believes this vision will lead to more rapid award and disbursement of funds to grantees, better execution of grants, more efficient tracking and management of grant applications, and improved transparency of the decision-making process. In times of limited Federal dollars for grant programs, optimizing use of IT systems can directly lead to improved outcomes, i.e., reduced staff time spent on administrative paperwork frees up staff time to directly execute and oversee grant activities.

Additionally, DERT believes that grant programs in other NIH IC program offices could benefit in terms of significant efficiency gains and administrative cost savings if they leveraged DERT’s grants management systems to administer their grants, and abandoned existing stove-piped, legacy, and/or paper-based solutions.

C.4 CURRENT ENVIRONMENT

A list and description of all applications in scope of this contract is provided in Attachment J-4 to this document. The Technology stack, usage, and support requirements for each of the applications, utilities and services are defined in Attachment J-5 to this document. Attachment J-6 outlines the major functional features and capacity for each tool. Attachments J-4, J-5, and J-6 supply the Contractor with information pertaining to aspects of the GADS applications required to effectively respond to this effort.

C.5 SCOPE

This PWS is intended for a single award Indefinite Delivery, Indefinite Quantity (IDIQ) contract for GADS application maintenance and development services. The base task order, to be issued at contract award, will consist of firm fixed-price (FFP) Steady-State Lifecycle Maintenance and Operational Support Services. Additional task orders, to be issued throughout the contract lifecycle, consist of Labor Hour (LO) or FFP task orders specific to Systems Development, Modernization and Enhancement (DME) Services of the GADS applications. The period of performance for the base IDIQ award will be for a five-year ordering period.

The following PWS provides details on the scope of the required Base Work (firm-fixed-price) and standard requirements for all follow-on fixed-price and labor hour services. Task orders with more specific details will be issued as required by NIEHS. Although the Base Work activities are defined and quantified, Indefinite Work will fluctuate depending on priorities, unknown service request work, changes to DERT funding for operations and maintenance, etc. Therefore, DERT seeks innovative approaches to managing a varying workload.

Base Work

1. Task 1

1. Application Steady-State Lifecycle Maintenance Services

2. Application Steady-State Operational Support Services Indefinite Work

2. Task n(n+1)

1. Application Systems Development, Modernization and Enhancement (DME) Services

C.5.1 SERVICE CATALOGUE

Overview of contract services to be provided:

Table 1. SERVICE CATALOGUE

· Answer queries about applications.

· Receive and document bug reports.

· Collect and document requests for changes.

· Provide status of requests.

· Retrieve functionality after abnormal program terminations.

· Complete root cause analysis.

· Fulfill regulatory requirements.

· Enhance run-time efficiency.

· Modify applications based on new releases of hardware or software.

· Provide functional, architectural and process improvements as required for the support and maintenance of the application areas in scope.

· Help to create new applications that meet DERT’s changing business or operating requirements.

C.5.2 TASK ORDER DESCRIPTIONS

The Contractor shall support the following Services:

· Application Steady-State Lifecycle Maintenance Services, including:

· Corrective - application bug fixes, fixes to reports that are inaccurate; correcting business rules that contain bad logic; and assistance in completion of scheduled infrastructure or software upgrades as identified by OIT.

· Adaptive - changes in the hosting or operating environment for the software and applications. Impact to applications due to changes to the operating system, hardware, software dependencies and organizational business rules and policies.

· Preventive - changes made to increase the understanding and maintainability of the applications over their lifecycle. Changes can include, but are not limited to, restructuring, optimizing code, refactoring and updating documentation.

· Minor, Minimally Additive - small incremental changes that add or modify features to existing applications in support of better business operations for users. This category is limited to small individual (1) changes requiring fewer than eight (8) hours of developer time per instance/change. This category will not exceed more than forty (40) developer hours total per calendar month.

· Application Steady-State Operational Support services necessary to continue on-going operations of existing applications. Support will be provided to verify operations, maintain current performance levels, track and resolve incidents, correct database errors, run scripts on the back end and otherwise assure full functionality.

· Application Development, Modernization and Enhancement (DME) services for each of the GADS applications and utilities. DME will include requirements analysis, design, development, testing, and deployment of changes and enhancements to existing applications to engender new or modified functionality in response to regulatory, statutory or DERT-business required changes.

DME may also include development of future application or services, consolidation of applications, integration of applications for improved data sharing, and the expansion of the existing applications to support other grant-making program areas in NIH or potentially from other Federal Government agencies.

C.5.1 C.5.2

C.5.3 CONTRACTOR IMPLEMENTATION PLAN

The Contractor shall develop an Implementation Plan (DEL C.5.3-1) within 30 calendar-days of contract performance start date to specifically address the following contract areas:

1. Help/Service Desk Process Flow.

a. Document via Business Process Modeling (BPM), or equivalent, the proposed process from initial call(incident) through to completion.

2. Help/Service Desk General Setup.

a. Application Function Type

i. Classify, validate information in Table 2, mapping all applications to their proper category: Critical, Important, Supportive.

b. Lifecycle Maintenance Severity Codes

i. Classify and map all potential help desk ticket areas to proper level of severity based on Government and Operational requirements.

C.6 CONTRACT MANAGEMENT

The Contractor shall conduct the technical and functional activities necessary for the management of the PWS and all tasks provided under this PWS. The Contractor shall furnish all the necessary services and qualified personnel as needed to perform the tasks in the PWS. The Contract program manager (PM) shall function as the primary point of contact (POC) with the GADS3 Contracting Officer Representative (COR) on all contract administrative activities and all contract tasks. The Contractor PM shall also function as the primary POC with the Government Technical Manager (GTM), who is responsible for technical monitoring of Contractor activities on behalf of the COR.

The GADS3 program office will measure the success of contract performance by the degree to which the Contractor meets or exceeds service levels as defined in the contract and, as applicable, in subsequent task orders. The COR will ensure the Government conducts, on a continuous basis, quality assurance in order to assess the Contractor’s performance at all times. The Contractor’s performance shall be monitored using the attached Quality Assurance Surveillance Plan (QASP) (Attachment J-9) for the Base Task and any/all subsequent task orders.

The NIEHS Project Management Office (PMO) will assist the GADS3 program office in establishing methods and tools for maintaining data on contractor performance. The PMO will assist the GADS3 program office in ensuring the Government conducts risk management, cost management, schedule management, and oversight of all Government program management and project-related activities in order to ensure the success of the GADS3 program.

C.6.1 CONTRACT MANAGEMENT PLAN

Three weeks after contract performance start date, the Contractor shall provide a Contract Management Plan (DEL C.6.1-1) outlining the activities, processes, and approaches it will use to provide the required services for the Base Task and any subsequent tasks including the specific deliverable documents, analyses, and reports. The Contractor shall submit modifications to the COR as required by changes to any components of the Contract Management Plan. The Contractor shall implement the Contract Management Plan and resultant task activities following the HHS Enterprise Performance Life Cycle (EPLC) methodology. The COR shall provide the Contractor with the HHS EPLC guidance at the Contract Start-Up Meeting. The EPLC Framework can be viewed and downloaded at this publicly available URL: https://www.hhs.gov/sites/default/files/ocio/eplc-lifecycle-framework.pdf.

C C.5 C.5.1

C.6.2 CONTRACT QUARTERLY REVIEW (CQR)

Quarterly, the Contractor shall meet with the GADS3 program office and the Contracting Officer (CO) for a joint review of the Contractor’s performance using the agreed-upon service levels. The Contractor shall include an executive-level summary of major issues, highlights, or accomplishments for the quarterly reporting period. The Contractor shall assist in the review of performance when requested by compiling and providing information, performance data, and performance measure results with supporting documentation. CQRs may also include the performance reporting of specific task orders, depending on how that requirement is stated in the respective task order.

C.6 C.6.1

C.6.3 WEEKLY STATUS MEETINGS

The Contractor shall meet weekly with the COR and GTM to provide a status on contract activities, contract management issues, and any other contract-related information that the Government needs to know in order for the Contractor to successfully perform the requirements of the PWS. The Contractor shall use a PowerPoint briefing deck to deliver the weekly agenda, meeting topics, and any supporting data (Weekly Status Briefing) (DEL C.6.3-1). Briefing decks should be concise and generally consist of five (5) to seven (7) slides. Meetings can take place on-site at the Government facility or via teleconference or web conference. Weekly status meetings may also include the status reporting of individual task orders, depending on how that requirement is stated in the respective task order.

C.6.4 CONTRACTOR QUALITY CONTROL

The Contractor shall provide and follow a Quality Control Plan (QCP) specifying the activities and approaches it will use to ensure that it meets or exceeds the Governments standards as stated in this PWS as well as in any subsequent task orders. The Contractor shall submit the QCP as part of the Quote. The Contractor’s quality control program shall include management and technical reviews and audits to validate the quality of the work performed by the Contractor’s personnel and of the work performed by its subcontractors (as applicable). The QCP shall include a description of how the Contractor shall scale its quality control program to ensure quality performance in additional task orders. The Contractor shall ensure that all employees, at any level, can elevate quality concerns to senior management.

C.6.5 CONTRACTOR START-UP MEETING

Within 10 business days of contract performance start date, the Contractor shall participate in a Contractor Start-Up Meeting and present an Orientation Briefing for the Government. The Orientation Briefing should not be elaborate and significant resources should not be expended in preparation for this briefing. The intent of the briefing is to initiate the communications process between the Government and the Contractor by introducing key task participants and explaining their roles, conducting a high-level review of the proposed contract management approach, reviewing communications ground rules, and assuring a common understanding of contract requirements, deliverables, and service levels. The Orientation Briefing shall be conducted at the Government’s facility, with most key personnel participating face-to-face.

C.6.6 PROGRAM and PROJECT MANAGEMENT The Contractor shall provide overall technical and system support in accordance with industry standards and norms. This support shall also include corporate management support, program management, and oversight for a program the size and complexity of GADS3 (see this PWS and Attachments J-2 and J-3). The Contractor shall provide program and project management resources to deliver full management lifecycle solutions including planning, tracking, deployment, and completion for the Base Task and any/all subsequent task orders. The Contractor shall develop effective plans and minimize changes by setting realistic objectives, facilitating communication issues and consensus building among various project groups, maintaining a focus on customer satisfaction.

The Contractor shall participate in meetings pertinent to this contract and all subsequent task orders that discuss the operations and supporting infrastructure of the applications of this portfolio. These may include conference calls, IMPAC II user group meetings, Integrated Project Team (IPT) meetings, DERT support and management meetings, Configuration Change Management Board (CCMB) meetings, etc., as requested by the COR.

The Contractor shall use NIEHS-provided project management software to track Sub-Task 1and 2 application work activities in a transparent manner to the Government. For example, a preventive activity that aims to optimize a search function might consist of multiple Jira “tickets” that provide the Government the opportunity to stay apprised of plans, activities, and results. As another example, if a new “path” is required for the SOS system, DERT staff would email the GADS help desk email inbox requesting the change; a Jira (or similar) ticket would be created, and the request resolved. NIEHS maintains systems and applications that are available to the Contractor to develop and manage project tracking, ticket tracking, knowledge repositories, and workflows. These currently include:

The Contractor shall not use Internet-based or corporate web sites/portals to fulfill the program and project management requirement. For security reasons, this requirement must be fulfilled using NIEHS network-confined tools or software.

C.6.7 KNOWLEDGE MANAGEMENT PORTAL

Within 30 calendar days of contract performance start date, the Contractor shall update the NIEHS-hosted environment to maintain a GADS3 Knowledge Management Portal (DEL C.6.7-1). The Contractor shall use the portal for posting and sharing documentation such as work requests and prototyped screens as well as to perform the following, as necessary:

C.6.8 COMMUNICATIONS

The Contractor shall perform communications in accordance with the Contract Management Plan to ensure the GADS end user community is adequately informed of any changes to the environment with impacts on end users’ ability to perform work. The Contractor shall ensure end user communications that use plain language, contain proper grammar, and are free of typographical errors.

C.6.9 CHANGE MANAGEMENT

NIEHS’ process management is in line with the IT Infrastructure Library (ITIL) fundamentals, utilizing Change Management, Knowledge Management, Continual Service Improvement, and Configuration Management. The objective of NIEHS’ use of ITIL is to develop effective and efficient methods for the provisioning, delivery, maintenance, and retirement of IT services. Changes to NIEHS IT systems are guided by an established change management process that dictates the steps required to introduce changes into the production environment. The change management processes are related to any change and/or release for NIEHS requiring a code change or modification outside of configuration made by NIEHS system administrators via support requests. The Contractor shall support and facilitate NIEHS IT change management processes for active releases. The Contractor shall also provide updates to the COR on upcoming changes that may impact NIEHS systems.

C.6.10 DOCUMENTATION MANAGEMENT

For all applications under the scope of Section C.7.1, the Contractor shall maintain and update as necessary all existing requirements documentation, architecture, design documentation, technical documentation, and end user manuals. Any documents that are affected by DME activities under Section C.7.2 shall also be maintained.

C.7 TASK ORDER REQUIREMENTS

The purpose of this PWS is to have the Contractor perform services related to the Lifecycle Maintenance Services, Steady State Operational Support services and Development/Modernization/Enhancement (DME) of the GADS applications and other related Information Technology (IT) systems. Due to the complexity of the task, the awardee shall have knowledge of NIH grants management business processes, shall analyze those processes in a holistic and integrated context, and shall recommend viable cost-effective technical and data solutions that improve program operations, reduce costs, and lower administrative burdens for grantees and staff.

The Contractor shall provide support for the tasks as described below.

C.7.1 BASE WORK

The Base Work component of this PWS is expected for one (1) Task Order but will include requirements for two (2) individually defined services: APPLICATION STEADY-STATE LIFECYCLE MAINTENANCE SERVICES and APPLICATION STEADY-STATE OPERATIONAL SUPPORT for all current GADS applications, utilities and services as well as new applications, utilities, and services that are developed in subsequent task orders. In addition, the Base Work component will include core contract management requirements for the Base Work and any/all subsequent task orders.

1.

2.

3.

4.

5.

6.

7.

7.1.

C.7.1.1 SUB-TASK1- APPLICATION STEADY-STATE LIFECYCLE MAINTENANCE SERVICES

Steady-State Lifecycle Maintenance encompasses the four (4) areas as previously identified under the Task Order Description (Section C.5.1).

Area 1. Corrective Maintenance Area 2. Adaptive Maintenance Area 3. Preventive Maintenance Area 4. Minor, Minimally Additive Changes

C.1.

C.2.

C.3.

C.4.

C.5.

C.6.

C.7.

C.7.1.

C.7.1.1.

C.7.1.1.1 STEADY-STATE LIFECYCLE MAINTENANCE SERVICES - CORRECTIVE MAINTENANCE (Area 1) The Contractor shall perform Corrective Maintenance actions that encompass modifications to fix application problems caused by design, logic, coding, development, and infrastructure errors. This type of maintenance will be triggered by an explicit trouble ticket, problem report, or trouble call. The Contractor shall perform all project phases and activities required to build, test, and deploy all Steady-State Corrective Maintenance changes as necessary to fix the application problems.

Steady-State Corrective Maintenance consists of the action(s) taken to restore a failed system to operational status. This usually involves replacing or repairing the software component that is responsible for the failure in the system. Corrective maintenance is performed at unpredictable intervals. The objective of corrective maintenance is to restore the system to satisfactory operation within the shortest possible time.

Code changes or other fixes conducted under a Steady-State Corrective Maintenance work request are of the nature that require a GADS release or application configuration change to implement into Production, e.g., cannot be accomplished via data correction scripts.

Corrective maintenance is also undertaken to ensure continuing operations for software version/platform/infrastructure changes (e.g. operating system upgrades, or Oracle upgrades) when the impacted business application/system would otherwise not work as a direct result of that version/platform/infrastructure change.

For instance, if OIT determines a systematic change is needed and that change requires code changes that cannot be implemented without a GADS release or application configuration changes, then the work is categorized as Corrective Maintenance.

C.7.1.1.2 STEADY-STATE LIFECYCLE MAINTENANCE SERVICES - ADAPTIVE MAINTENANCE (Area 2) The Contractor shall perform Adaptive Maintenance actions that are caused by changes to the hosting environment. For example, NIH’s eRA announced recently that IMPAC II data will be moving to the cloud from the NIH Data Center, with a period of transition. The adaptive maintenance requirement ensures that the applications, utilities, and services are kept usable in such a changed or changing environment. Another example would be regular version updates to underlying resources used, such as Java.

The Contractor shall identify adaptive changes as a result of proactive research and understanding of the GADS applications, utilities and services operating environment before any impact to end-user feature functionality. As a result, the Government expects that minimal adaptive issues will manifest in the GADS operational environment as a corrective problem to the end-user.

C.7.1.1.3 STEADY-STATE LIFECYCLE MAINTENANCE SERVICES - PREVENTIVE MAINTENANCE (Area 3) The Contractor shall perform preventive maintenance services that increase the reliability and maintainability of the GADS applications, utilities, and services, across the lifecycle and reduce total cost of ownership for the Government. Preventive changes are focused on restructuring, refactoring, and optimizing code; updating documentation; or implementing changes to reduce unpredictable effects software can have in the long term and that help it become scalable, stable, understandable and maintainable. The Contractor shall ensure that it completes the following requirements on a monthly maintenance schedule:

· For IDC, a historical partition exists that includes a rolling set of data ranging from 2007 to the year which is five years prior to the current fiscal year. For example, the current historic partition includes data from FY2007 to FY2014. Periodically these historical records are updated in IRDB. To accommodate for these changes, the records in this partition shall be updated quarterly.

· For GFDT and BUDFORE, a fiscal year rollover shall be performed each year.

· For SOS, up to ten additional “paths” shall be added to the backend each fiscal year.

The Program Class Code (PCC) schema documents various aspects of grant management. The schema changes over time to accommodate DERT staff changes scientific code updates, and NIEHS strategic plan priorities. Typically, no more than 10 code changes occur within a year. The Contractor shall perform backend changes to ensure codes are represented properly in the systems. Each month, the Contractor shall designate at least five (5) percent of total available lifecycle maintenance hours to Preventive Maintenance. The Contractor shall deliver a Monthly Preventive Services Report (DEL C.7.1-0) to communicate Preventative Maintenance actions it has accomplished in the previous month.

C.7.1.1.4 STEADY-STATE LIFECYCLE MAINTENANCE SERVICES - MINOR, MINIMALLY ADDITIVE CHANGES (Area 4) The Contractor shall perform minor, minimally additive changes as part of the base lifecycle maintenance component of this PWS. These will be minor changes or very small additions to the application base that do not exceed the cap defined in Section C.5.2.

Minimally adaptive changes could arise, e.g., from a helpdesk ticket requesting one-time reporting need, a prototype for a larger report, a minor enhancement to a scheduled task, or a simple page layout change.

C.7.1.1.5 STEADY-STATE LIFECYCLE MAINTENANCE SERVICES - TESTING

The Contractor shall conduct functional, unit, system and integration, regression, smoke, load and performance, and stability tests as applicable as part of their quality control plan for each system release, regardless of size. Each applicable test will be identified as a milestone in the project plan, or properly articulated in the applicable service ticket. Use of industry-standard automated testing software is strongly encouraged. The Contractor shall ensure that testing procedures handle changes and requirements of any complexity, allow for the recording and playback scripts, and maintain an ongoing test data suite; thus ensuring 100% of the requirements are met and that regression testing will fully test all previous functionality. The amount and type of testing will be commensurate with the size, scope, and risk of the specific release as mutually agreed upon by the Contractor and the DERT GTM.

The Contractor shall assist staff in coordinating User Acceptance Testing (UAT) with impacted stakeholders, as per section C.7.1.1.6 below.

C.7.1.1.6 STEADY-STATE LIFECYCLE MAINTENANCE SERVICES - USER ACCEPTANCE TESTING (UAT)

The Government will perform UAT of the new or modified GADS application code, database changes, or additions, after successful completion of Contractor testing. The Contractor shall prepare or update a UAT plan (DEL C.7.1-1) with test scenarios and scripts for users to follow during the initial structured portion of the UAT (following structured testing the users are encouraged to conduct their own free-form testing). The Contractor shall assist DERT during the preparation and execution of the acceptance test by establishing test data and maintaining the test environment. The Contractor shall correct any errors identified by the UAT team. The Contractor shall document the results of the testing in the Test Report (DEL C.7.1-2).

Upon receipt of the report, the Government will examine the test results and decide as to the readiness of the new or modified GADS systems’ code and/or database changes/additions to be released into the production environment. The Government will certify the planned release under one of the following categories:

· It is virtually error free and should be released into production.

· Errors still exist that should be addressed, however, a decision could be made that either:

· the release can proceed intact and the errors will be corrected and implemented through a subsequent release or,

· the release can proceed but the portions determined defective will be removed from it and errors will be corrected and implemented through a subsequent release.

· It has major shortcomings and should not be released into production at this time. Instead, it should be returned for further development and re-testing.

C.7.1.1.7 STEADY-STATE LIFECYCLE MAINTENANCE SERVICES - RELEASES

Once the Government has performed UAT and final system performance load and stress testing has been completed, the Contractor shall submit the package as a GADS release request to the COR, along with all associated documentation required for the GADS release process.

The Contractor shall prepare and manage Release Notes (DEL C.7.1-3) to document the fixes/changes/enhancements included in each system release and support the release process using standard CM tools.

When the GTM verifies that UAT is successfully complete, the Contractor shall prepare and submit a GADS Release Package (DEL C.7.1-4), which includes the technical release instructions, scripts, schedule, and any other documentation identified as requested by the GTM.

The GTM shall determine if the release is categorized as a “regular” or “emergency” release. The Contractor shall perform all releases within a timeline that corresponds and supports the SLA metrics in Table 4. The Contractor shall be responsible for coordinating release testing with DERT testing resources.

The Contractor shall support the DERT staff, OIT staff, and infrastructure contractors during the installation and configuration of software upgrades and application system releases as required. The Contractor shall also follow-up to provide Verification and Validation of the intended results within two business hours after the release installation has been completed, to verify that the installation was completed correctly.

C.7.1.1.8 STEADY-STATE LIFECYCLE MAINTENANCE SERVICES – PERFORMANCE OBJECTIVES

C.7.1.1.8.1 LIFECYCLE MAINTENANCE APPLICATION FUNCTION TYPES

The Government identifies each GADS application or utility function type as Critical, Important, or Supportive (see Attachment J-5, “Importance” Column). Table 2 below provides a description and examples of function types.

Table 2. LIFECYCLE MAINTENANCE APPLICATION FUNCTION TYPE

2. Inability for staff to access either the GFDT or SOS or any of the IT applications defined as critical.

3. Inability for staff to use key functionality in the GFDT or SOS.

2. Inaccuracies in the data in a scheduled task.

3. Inability for DERT Staff to access any of the IT applications defined as important.

4. Change in structure needed for the HITS reports due to unexpected changes in IMPAC II (an important, but not critical, application).

2. Changes needed to the Human Subjects scheduled tasks report(s).

3. Inability for DERT Staff to access any of the IT applications defined as supportive

C.7.1.1.8.2 LIFECYCLE MAINTENANCE SEVERITY CODES

Service requests for problems received by the help desk will be given a Severity Code from 1 – 4 based on how important responding to the problem is to the primary business of DERT, as well as the availability of workarounds. The Contractor shall assign these Severity Codes, defined in Table 3 below. These codes will be the basis for scheduling work on the backlog and assigning resources to the request. Critical, important, and supportive application functions are defined in Table 2 above, with a complete list of application functions included in this agreement to be completed as part of the Contractor Implementation Plan.

Table 3. LIFECYCLE MAINTENANCE SEVERITY CODES

or A problem has made an important application, function, or utility unusable or unavailable and no workaround exists.

C.7.1.1.8.3 LIFECYCLE MAINTENANCE RESPONSE AND RESOLUTION TIMES

The Contractor shall use Severity Codes from Table 3 to classify and determine required response and resolution times for incidents, as shown in Table 4 below. Response and resolution times are measured, during normal business hours, from the time that the GADS email inbox (GADSHelpDesk@nih.gov) receives notice of the incident via an email submitted by an end user (“help desk ticket”). If the incident is not resolved within the defined timeframe, the Contractor shall apply continuous effort until the incident is resolved.

Table 4. LIFECYCLE MAINTENANCE RESPONSE AND RESOULTION TIMES

Response

· Initial Response is when a help desk ticket is opened and acknowledged by the Contractor.

· Estimation Response is when the user that logged the help desk ticket is informed of an estimated resolution time by the Contractor.

· Subsequent Responses is the frequency with which the user that logged the help desk ticket is updated on the resolution status.

· Resolution is the point at which the incident is resolved, and the application function is returned to a usable and available state.

C.7.1.1.8.4 LIFECYCLE MAINTENANCE RESPONSE AND RESOLUTION SERVICE LEVELS

Table 5. LIFECYCLE MAINTENANCE RESPONSE AND SERVICE LEVELS

C.7.1.1.8.5 LIFECYCLE MAINTENANCE APPLICATION, UTILITY AND SERVICE AVAILABILITY

Availability is defined as the ability of an end user to access and execute any of the included application functions from a functioning workstation and live network connection. For an application to be available, all its supporting systems must also be operational.

Table 6. LIFECYCLE MAINTENANCE APPLICATION, UTILITY AND SERVICE AVAILABILITY

Friday 3:00 pm – 9:00 pm EST

Friday 3:00 pm – 9:00 pm EST

Friday 3:00 pm – 9:00 pm EST

· Any additional outages must be scheduled and approved by the COR at least two weeks in advance unless there is an emergency.

C.7.1.1.8.6 LIFECYCLE MAINTENANCE APPLICATION AVAILABILITY SERVICE LEVELS

Table 7. LIFECYCLE MAINTENANCE APPLICATION AVAILABILITY SERVICE LEVELS

C.7.1.2 SUB-TASK2- APPLICATION STEADY-STATE OPERATIONAL SUPPORT

The objective of Operational Support is to ensure complete, continuous, and successful business operations for all the GADS application, utilities and services. Steady-State Operations means maintenance and operation of current GADS applications, utilities and services at current capability and performance level. Version, platform, and infrastructure changes that can be accommodated without a GADS release or application configuration changes are also considered within scope of Operational Support below. The Contractor shall maintain and support all major functional features and capacities listed in Attachment J-6.

C.7.1.2.1 STEADY-STATE OPERATIONAL SUPPORT OBJECTIVES

C.7.1.2.1.1 OPERATION VERIFICATION and PERFORMANCE The Contractor shall create Operational Verification Checklists (DEL C.7.1-5), or service monitoring scripts, for elements within each application, utility or service that will be verified. The Contractor shall use the Operational Verification Checklists to ensure normal business operations and to provide the relevant operational service level metrics required to satisfy the requirements set forth in Table 6.

The Contractor shall use the Operational Verification Checklists (scripts) to conduct continuous (i.e., automated) checks on all applications covered by this task order to verify that they are operational, and as a basis for their end of month Operational Verification Report (DEL C.7.1-6), delivered to the COR by the first business day of every month. The Contractor shall identify each issue and identify items in which the performance was outside the threshold for acceptable performance, as defined in Table 6.

C.7.1.2.1.2 INCIDENT (TIER 1), TIER 2 AND TIER 3 TRACKING AND RESOLUTION

Within 30 calendar days of contract performance start date, the Contractor shall utilize NIEHS-provided applications and Intranet resources (see C.6.6) to develop and maintain a searchable ticket tracking system (DEL C.7.1-7) that categorizes all application, utility, and service issues by a list of attributes, as discussed and agreed to by both contractor and Government. The Contractor may reuse the configuration of the existing JIRA-based system that is in place, if needed, to ensure timely transition to an effective ticket tracking system. The Contractor shall enable select DERT and OIT staff to access this system to assess the overall status of each system or project, to assess each documented issue, and to prioritize issues for resolution. If, during the contract period of performance, DERT adopts an enterprise-wide ticket tracking system for applications, the Contractor shall adopt within six-months as directed by the COR.

Figure 1. DERT – GADS APPLICATION SUPPORT MODEL

The Contractor shall use the GADS email inbox to monitor issuance of help desk tickets and, enter help desk tickets into the web-based ticket tracking system (Figure 1). The Contractor shall respond to ticket requests which can include, but are not limited to, technical issues, system access problems and application questions (i.e., user cannot enter data into a specific field, screen is not loading, etc.), error messages, permissions, performance issues, batch…