DRAFT PWS version 1.2.docx

APPS

Appian Platform and Product Support ITS SPS Performance Work Statement for Appian Platform and Product Support Version 1.2 ITS Supervision & Platform Support (SPS)

BPAS

Business Process Automation Systems ITS SPS

Document Control

Table of Contents

List of Figures Figure 1 43 List of Tables

APPS

Appian Platform and Product Support ITS SPS iii Version 1.2 Introduction Scope of Work The scope of work includes, but will not be limited to, support for the Appian platform, including the following existing products (see section 3 for an explanation of each of these products).

Appian Infrastructure Assignment Management System (AMS) Central Application Tracking System (CATS) Community Reinvestment Act–Qualifying Activities (CRA) Common Case Management (CCM) Cybersecurity Supervision System (CSS) Ethics Management System (EMS) Invitational Travel Reimbursements (ITR) National Risk Issue System (NRISK) Personnel Administration and Security (PASS) Product Search Portal (PSP) Quick Wins Security Assessment and Accountability System (SAAS) Strategy Tracker (Tracker) Supervisory Product Review Tool (SPRT) Web Tracking and Tracking Application (WTTA)

This PWS establishes a framework for the planning, analysis, architecture, design, development, testing, implementation, and operation & maintenance of products or tools developed on the Appian platform. This includes integrations with, or the deployment of, associated software such as Appian or third-party plug-ins, artificial intelligence modules, and other software components necessary to meet business needs. The Contractor must provide support for a gambit of small and simple projects as well as major and complex projects, and everything in between. It is OCC’s intent to use this contract as its primary method for all Appian work at OCC. As OCC’s needs evolve, we anticipate the continuous addition of new products using the Appian platform and possible decommissioning of others. The only known new product at this time is Examiner Portal (ExPo) which will be a major complex project. The Contractor is tasked with building Appian solutions tailored to OCC’s requirements, implementing these solutions, as well as ensuring their smooth operation, ongoing maintenance, and phase-out/decommissioning of the solution as required. This involves routine updates, addressing software defects, and implementing any essential enhancements to ensure the product's performance, security, and applicability. This will require the contractor to work closely with both government staff and other contractors to ensure the successful implementation of new products, especially larger enterprise-wide systems (e.g., ExPo). By harnessing the strengths of the Appian platform, OCC’s goal is to realize efficient, enduring, and adaptable software solutions in line with its organizational goals.

Overview of Services Included in this PWS The primary objective of this PWS is to ensure continuous, effective support of the OCC’s Appian platform. This includes operations and maintenance of existing products as well as the development of future products built on the platform. An additional intent is to enhance the quality-of-service delivery while increasing customer satisfaction levels. Work under this contract will be conducted in alignment with these overarching objectives and will be laid out in more granular detail during the iteration planning and sprint planning meetings held at regular intervals throughout the contract period. Work under this PWS spans operations, compliance, and business investment activities—in that order of priority.

This PWS has references to existing OCC platforms (e.g., eDocs, Rational JAZZ), products, services, and technologies that integrate with or are used by the Appian platform. The OCC may choose to replace these platforms, products, services, and technologies during the period of performance; the Contractor must continue to support integrations with the replacement tools.

Accelerators and Software Licenses The Contractor must use OCC’s existing Appian platform licenses to build and maintain products under this PWS. There may be situations in which supplemental software needs to be purchased by the Contractor from the Appian App Market which provides Solutions, Plug-Ins, and other software components that streamline development, enhance interoperability, and provide a comprehensive environment for Appian product development and deployment. Any materials purchased by the Contractor must be turned over to the OCC since they will remain as government property. The categories of software licenses that could be purchased include:

· Solutions: Pre-built application structures designed to speed up the development process. They come with reusable elements such as forms, process workflows, and dashboards that can be configured to meet specific product requirements.

· Plug-In: Appian provides a wide range of connectors that facilitate seamless integration with other systems, both on-premises and in the cloud.

· Other Third Party-Software: Additional software tools (e.g., shell scripts) specifically built for Appian integrations. Some, but not all, of these tools are available in the Appian App market.

One category of license that would be excluded are Appian base product licenses (e.g., Appian named user licenses, Appian robotic process automation licenses, Appian process automation licenses).

The OCC will download and make available to the Contractor all needed non-cost solutions / accelerators, plug-ins, and third-party software.

The contract can be utilized by the OCC for the procurement of Appian's software components, including but not limited to accelerators, connectors, and other related software. The contract will require the Contractor to buy varying quantities and types of software components over the contract's ordering period, aligned with evolving project requirements and technical needs. This will be billed to a time and materials (T&M) contract line-item number (CLIN) with this express purpose.

The Contractor must only provide the OCC with Appian software components that come with a perpetual-use license; all licenses must be registered to, and become property of, the OCC. In uncommon circumstances, the CO, and only the CO, may approve the Contractor to provide OCC with licenses that are not perpetual-use licenses. The Contractor must receive CO approval of subscription or term licenses when needed. This ensures:

· Full Control: The Government has full control over the software, allowing for unlimited use within the bounds of the contract and the underlying commercial supplier agreement (i.e., software license), without recurring licensing fees.

· Transferability: The Government retains the right to transfer these licenses across different departments or projects (within the terms of the commercial supplier agreement), ensuring maximum utility and flexibility.

The Contractor must coordinate all software purchases with both the COR and the CO and must follow OCC processes and procedures for any software purchased through this contract. This includes, but is not limited to, ensuring that all software licenses purchased are compliant with OCC's procurement policies, legal requirements, and contract language stipulations (e.g., terms & conditions). The Contractor must include the necessary contract language specified by OCC when procuring software licenses, ensuring that all terms, conditions, and deliverables align with OCC standards and policies; the COR will provide specific language to be incorporated and/or any flow down of clauses from this OCC contract to the Contractor after consultation with the CO. The CO must review and approve any final language for incorporation into any subcontract for software purchases prior to the Contractor finalizing any software purchase for the OCC under this contract.

Place of Performance The OCC may require that the Contractor have employees (some, all, or none) work at the Government site (OCC Headquarters) or at the Contractor site. The OCC may require a mixed arrangement with some, all, or no work required to be performed at the OCC Headquarters or Contractor’s site. Further details on place of performance and any telework will be detailed in each task order. If a task order does not explicitly address telework (due to omission or otherwise), the CO may allow telework under the task order upon request, and solely at the CO’s discretion upon consultation with OCC ITS. The Contractor must ensure contract coverage, whether virtual or on site, during OCC core hours of operation between 9:00 a.m. to 5:00 p.m. ET (Eastern Time).

ICT Accessibility Requirements Section 508 of the Rehabilitation Act, as amended by the Workforce Investment Act of 1998 (P.L. 105-220) requires that when Federal agencies develop, procure, maintain, or use information and communication technology (ICT), it shall be accessible to people with disabilities. Federal employees and members of the public who have disabilities must have access to, and use of, information and data that is comparable to people without disabilities. As such, the following requirements apply to this solicitation:

1. Products, platforms, and services delivered as part of this work statement that are ICT, or contain ICT, must conform to the Revised 508 Standards, which are located at 36 C.F.R. § 1194.1 & Apps. A, C & D, and available at https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines

1. E102 / 702.10 – Web Content Accessibility Guidelines (WCAG) success criteria level A & AA are incorporated as a requirement. The referenced WCAG criteria is available at http://www.w3.org/TR/WCAG20/

1. A completed Accessibility Conformance Report (ACR) found at https://www.itic.org/policy/accessibility/vpat, using Voluntary Product Accessibility Template (VPAT) Revised Section 508 Edition, Version 2.4, is required to assist the Government in determining that the ICT products or services support Section 508 accessibility standards.

1. E202 – No General Exceptions Authorized by OCC The following items are identified as containing ICT: Appian Platform and Product Support (documents, reports, etc.)

· Software Applications & Operating Systems

· Web-based Intranet and Internet Information and Applications

· Information, Documentation, and Support

Applicable Functional Performance Criteria: All functional performance criteria apply when using an alternative design or technology that achieves substantially equivalent or greater accessibility and usability by individuals with disabilities than would be provided by conformance to one or more of the requirements in Chapters 4-6 of the Revised 508 Standards, or when Chapters 4-6 do not address one or more functions of ICT.

Applicable requirements for software and Web products:

· E207 – WCAG Level A & AA Success Criteria

· E302 – Functional Performance Criteria

· E502 – Interoperability with Assistive Technology

· E503 – Application

· E504 – Authoring Tool*

· E501 – Web-based applications, independent of platform services Applicable requirements for electronic documents and/or support services:

· E205 – WCAG Level A & AA Success Criteria

· E302 – Functional Performance Criteria

· E602 – Support Documentation

· E603 – Support Services

Tasks and Deliverables This section defines the type of tasks that may be performed and the work products and deliverables that may be created/maintained by the Contractor. Given the agile development approach described later in this document, the specific tasks and deliverables are defined in each task order and elaborated on at the start of each sprint or release. Appendix A provides an estimated percentage of time expected to be allocated to the tasks identified in this section. All deliverables are due to the COR unless explicitly stated otherwise.

Project Management Tasks The performance of the Contractor’s project management activities must be accomplished consistent with the requirements set forth in this PWS.

Project and Contract Management The Contractor must perform some or all of the types of work described in Table 2–1, as necessary.

Table 2–1 Project and Contract Management Tasks

· Activities by technical/functional area

· Updates to the Integrated Master Schedule (IMS)

· Status of deliverables (submitted, late, or planned)

· Key risks and mitigation plans

· Key issues and action items

· Staff changes

· Performance metrics.

The Contractor must:

· Deliver a weekly status report, in a format agreed upon by the COR and Contractor, by the end of the first business day following the week for which status is being reported;

· Work with the OCC’s project managers and assist with inputting data into the status report or systems used to collect status report data; and

· Confirm with the COR prior to dissemination of the first report, the recipients of the weekly status (any additions to or deletions from the recipient list must be approved by the COR).

After award, the COR will provide the Contractor the mandated template for producing this report. The COR may change this template with reasonable notice given to the Contractor.

· Reiterate and confirm by providing a narrative demonstrating understanding of the project goals, needs, and objectives;

· Propose high-level technical approaches and alternatives for currently undefined, labor-hours tasks;

· Propose high-level milestones for currently undefined tasks whose level of effort is not reflected in the project schedule;

· Coordinate and collaborate with other contractors and OCC staff on planning activities; and

· Conduct project management activities across all projects included in the PWS (e.g., resource planning/constraints and coordinating, training compliance, onboarding/offboarding including timeframes, space planning support, long term integrated planning, communications channels, office location).

· Maintain release plans within the OCC-approved application lifecycle management (ALM) software (currently Jazz, but referred to as ALM through the remainder of this document)

· Determine release plans in quarterly meetings with the OCC ITS project team and the relevant OCC business unit stakeholders

· Schedule quarter release planning meetings, no less than three weeks prior to the planned release date.

· Calculate the estimated cost of the release, iteration, and sprint using the initial release budget, release backlog, estimated velocity. Continuously review actual release/sprint cost against the estimates and adjust future cost predictions.

The planning meeting will include activities such as backlog grooming, allocating/reallocating items to a release/sprint, discussion of story points, velocity, and resource capacity. Attendance at release/sprint planning meetings by the development team members should be included in the development tasks for each system in scope.

Implementation Plan that consists of the final implementation readiness checklist and detailed deployment checklist

· Enclosure13_Appian_Shared_Platform_Deployment_Instructions_IntSep2020

· Enclosure14_Sept2020_ExtProd_Appian_Shared_Platform_Deployment_Instructions

These updates must include percentage of total work completed, actual effort expended on an activity in labor hours, dependency changes, resource changes, milestone changes, etc. Detailed tasks will be stored in ALM, so the project schedules will contain activities not in the ALM (e.g., document updates & reviews) and sprint/release timelines.

The Contractor is required to submit a COR Review Package by noon on the third Wednesday of each month. The version submitted by this time must be signed by the Contractor’s program manager. The COR will complete the review within a reasonable amount of time to complete their review and acceptance of the COR Review Package.

The contractor must do the following:

· Configure and update ALM dashboards as software development is performed.

· Present these required reports in monthly KPI meetings that occur on the third Wednesday of every month. If the Contractor demonstrates full adoption of SPS’s Agile methodology as reflected on the SPS Agile Heat Map, for a specific product, then it will have the opportunity to reduce the frequency of presentations to a quarterly basis for that product. The Contractor must request approval of the change of frequency to quarterly from the COR.

For Appian products with active development work, monthly ALM Reports for the KPIs (see Appendix D) must be configured no later than the third Wednesday of every month. This applies to all product development teams, regardless of the frequency of presentation meetings. For product development teams authorized to present quarterly, during the months they are not presenting, they are required to send a deliverable completion email no later than the third Wednesday of every month. The purpose of this email is to provide notification to the ITS PM, Call COR, Program COR, and the Agile SLPM Group that the team has completed its monthly report configuration updates for all development projects it supports. This email should include a link to the team’s completed ALM dashboard.

Monthly Contractor Invoice (By CLIN and product-level OCC IT project codes)

Contract and Product Transition Planning and Management After award, the Contractor must collaborate with ITS and the incumbent Contractor to refine and expand the initial plan into a complete transition plan that will successfully transition all applicable products, business systems, and tools from the existing project team (which will include incumbent contractors and/or OCC employees). The Contractor must perform all the types of work, as necessary, described in Table 2–2.[footnoteRef:2] [2: Task IDs within Table 2-2 map to Appendix A and the Deliverables table later in the PWS. The Task ID typically follows the same structure as the section heading, but any deviations (e.g., sequence gaps) are intentional. ]

Table 2–2 Transition Planning and Management Tasks

· Transition scope and approach

· OCC resources required to support the transition

· Requirements for support from resources other than the Contractor’s team or OCC’s employees (e.g., support from third-party vendors)

· Risks and issues (e.g., schedule, cost)

· Milestone schedule must reflect completion of transition activities within 60 days.

· A list of key information items that need to be communicated to other teams or business units to support the transition effectively

· Knowledge-transfer requirements

· Transfer of OCC-specific project information in the incumbent’s knowledge bases/repositories to an OCC-approved repository on OCC’s network

· Government-required training (e.g., annual ITS Security & Privacy training)

· Transfer of hardware warranties and software licenses (if applicable)

· Transfer of all existing business and/or technical documentation

· Transfer of compiled and uncompiled source code, to include all versions, baselines, maintenance updates, and patches (if applicable)

· List of desired OCC-led briefings that will serve to orient the Contractor’s new project

· The approach that the Contractor will use to document informally communicated in-formation by the incumbent that the Contractor will need to effectively maintain and operate the OCC systems

· The approach that the Contractor will use to ensure that ownership of and access to the existing project SharePoint sites are effectively transferred to the Contractor’s team

· Source-code control procedures.

The Contractor must adequately staff its transition plan to perform the full scope of work.

Final Transition Plan (This final version will be created from the draft Transition Plan that the Contractor shall include in its proposal for evaluation. And must include all products and platforms to be transitioned)

1) Review platform and product documentation, including:

· Interface Control Document

· Environment architecture diagrams

· System Administrator Guide

· Build instructions

· Information System Contingency Plan (ISCP)

1. Review outstanding change request (CR) and defect request (DR) backlog for all products and the platform in ALM

1. Review and understand Appian development best practices, procedures, tips & tricks (which includes product specific development procedures) which is documented in the Appian Center of Excellence application (access is provided post award).

1. Review the previous two monthly audit reports for all OCC products on the Appian platform.

1. Review last three months of helpdesk incidents and ServiceNow requests for all OCC products on the Appian platform

1. Enter Privilege Access Requests (PARs)for access to all CATS, PASS, shared internal, and shared external environments

1. Complete Information System Contingency Planning (ISCP) training for key personnel. This training is provided by OCC staff.

The contractor shall complete the following:

· Disseminate the Weekly Transition Status Report no later than the close of the business day (COB) prior to the Weekly Transition Status Meeting

· When possible, communicate issues, risks, and delays in advance of the Weekly Transition Status Meeting to the COR.

· Elicit a list of individuals to be included in the Weekly Transition Status Meeting from the COR

· Add or remove individuals from the invite list for the Weekly Transition Status Meeting only with the approval of the COR

The Contractor must provide a draft of the Transition Completion Briefing to the COR no less than two (2) business days prior to the scheduled briefing

Transition Completion Briefing Presentation (must include all products and platforms within the agreed level of effort.

· All system documentation in progress or complete, including maintenance and operational processes and procedures

· Source code (both completed and in progress) stored in the OCC ALM repository and source control procedures to include any metadata necessary to reorganize all of the aforementioned code and information in a meaningful and useable way.

· Code/configurations baselines

· System logs and system notification methods

· Access to the change management system and instructions for its use

· Change-management processes and procedures

· Risk and issue logs, as well as risk-management process descriptions

· Configuration management processes and procedures

· System backup processes and procedures

· Disaster recovery plans, processes, and procedures

· Instructions for how to access and navigate the project-level collaboration sites

· Descriptions of the development, testing, staging, and production environments and an explanation of how to migrate code between these environments

· Descriptions of the roles and responsibilities of the existing Contractor team as they relate to required operations and maintenance activities.

The Contractor must provide an End-of-Performance Period checklist to the OCC that summarizes all the documentation and code to be transitioned to the replacement contractor.

Quality Control (QC) Management The Contractor must participate in ITS-sponsored quality performance improvement initiatives related to software development activities. These initiatives may include, but are not limited to, collaborative activities designed to develop software standards and conventions, protocols for naming software objects and classes, specific design approaches for error handling and system interfaces, and integration with third-party tools for automated testing as a part of continuous development and deployment (e.g., piloting of tools like Jenkins, Jira, Git). Support for OCC quality initiatives may also include the implementation of structured code reviews. The Contractor must perform some or all the types of work, as necessary, described in Table 2–3.

Table 2–3 Quality Control Tasks

Software Development Tasks The Contractor must provide support for operations, compliance debt, technical debt, and new enhancements for the products and platforms covered by this PWS. See section 1.1 for scope of work planned for maintenance of existing products and new development work.

Operations, Compliance, and Business Investment Unless explicitly excluded, the Contractor is responsible for all aspects of operations, compliance debt, technical debt, and new enhancements activities. These activities include the following:

· creating and maintaining platform and product architectural roadmap

· monitoring and documenting product tool version levels

· creating and maintaining SDLC documentation for OCC products

· analyzing and resolving software defects reported

· modifying existing software to resolve reported system problems

· managing the configuration of new and modified system software

· designing, testing, and deploying new system software (including inbound and outbound interfaces)

· repairing and recovering data for OCC systems

· managing OCC data in transit until it is received by its destination system

· implementing process improvements associated with specific maintenance activities.

The Contractor must ensure that maintenance system changes continue to meet the OCC’s functional requirements, are interoperable with other enterprise products, are consistent with the approved enterprise architecture, and meet operational expectations for system monitoring and disaster recovery. The Contractor must also proactively identify opportunities, within specific software releases or sprints, for combining software enhancements and/or code fixes in a manner that increases efficiency and/or reduces costs.

The Contractor is responsible for ensuring the acceptability of the software and associated documentation quality that it delivers, as defined in the Quality Control Plan. Sufficient unit and system testing of new and modified software, changes to configuration settings, and changes to database schemas is required to ensure the successful operation of OCC systems prior to User Acceptance Testing (UAT) or deployment into production (for changes not subjected to UAT). In the performance of its software maintenance activities, the Contractor’s team must adhere to the OCC’s processes for event, incident, problem, and change management, as well as to the OCC’s processes, policies, and procedures for security management (including the Security Assessment & Accreditation [SA&A]). The Contractor must perform some or all the types of work, as necessary, described in Table 2‑4.

Table 2‑4 Operations, Compliance, and Business Investment Tasks

The Contractor must:

· Follow Agile practices. The Contractor’s Appian development staff must perform the full range of software development activities (e.g., requirements, design, development, testing, QA, and documentation tasks).

· Perform release planning for each quarterly and monthly release, based on customer assigned priority. The Contractor must manage all product-specific change requests and defect fixes within the OCC's enterprise configuration management tool. There is a maximum of five (5) defects and a minimum of two (2) changes requests in each quarterly release for each product. There is a maximum of one (1) defect in a monthly release for each product.

· Use agile development principals to manage product-specific work items, including relative estimation (story points) for unapproved change request.

· Convene a biweekly sprint planning meeting to obtain:

1. clarification on outstanding requirements

2. signoff on acceptance criteria from the Business Unit on all defect fixes and change requests included in the sprint. Development on said defect fixes and change requests may not begin until BU approval is obtained on the acceptance criteria.

· Deliver a sprint planning slide deck. The slide deck should cover the following information (at a minimum) for each item being presented:

-ID

-Description/Summary -Acceptance Criteria -High-Level Design Plan -Found By -Priority

· All functional requirements are met

· All audit requirements are met

· Designs are consistent with the OCC’s architectural standards

· Designs meet the OCC’s disaster-recovery standards

· Designs minimize data loss and downtime

· Designs are sufficiently documented and traceable to one or more requirements

· Designs are testable

· Designs are flexible and extendable for future needs

· Designs are flexible and extendable to support data migration from legacy systems The Contractor must do the following:

· Design Product specific changes requests and defect fixes according to OCC defined best practices and standards

· Design specifications meet the acceptance criteria agreed upon with the Business Unit

· Coordinate significant change requests/integrations with the Appian Platform and Enterprise Architecture teams (e.g., integration with a new system inside or outside of the OCC)

· Document the design and implementation of any new functionality which takes more than 40 hours to implement, in a requirements/design document. Examples of new functionality may include implementing a new component or workflow, design a new integration (e.g., OCR, Interface with GetITHelp)

· Apply Appian and OCC UI/UX customer/user centered design concepts and best practices for Appian development

· Evaluate the overall digital experience of Appian products (new and existing) across desktop and other relevant screen sizes

· Gather qualitative data to build an understanding of user needs through user interviews or contextual observation

· Identify trends and patterns across the information collected during UI/UX research.

· Identify areas of UX improvement and provide recommendations for a path forward

· Develop and maintain UX & UI recommendations and best practices to improve the user experience across the Appian platform

· Design detailed mockups and designs that can be used directly by developers to build custom software or interfaces

· Deliver User Experience (UX) flows, wireframes, high fidelity mockups, interactive prototypes, design specifications, and final components

· Translate user needs and requirements into elegant solutions, concepts and interaction models that scale and fit within larger established systems and patterns

· Develop personas and use cases

· Configure/build development, prototyping, and test environments to support the development and testing of modified or new software

· Coordinate with the Infrastructure and Operations (I&O) team to implement required technology environment changes

· Develop software to support the implementation of new or revised system requirements

· Develop software/programs/scripts to support data migration from legacy systems

· Configure COTS software to support the implementation of new or revised system requirements

· Design, create, and/or maintain (if already existing) the product architecture

· Design, create, and/or maintain (if already existing) the product business databases

· Identify any necessary database changes to be conveyed to the Database Administrator for implementation

· Coordinate the scheduling of database maintenance with the database-administration team

· Leverage the OCC’s existing development tools and recommend new third-party tools to improve developer productivity, code stability, and code reusability.

The Contractor must do the following:

· Develop Product specific change requests and defects using OCC defined best practices for Appian development.

· Perform technical code reviews on all work items developed as part of a quarterly or monthly release. The code reviews must be performed by a technical lead, who is familiar with the OCC defined best practices for Appian development and has an Appian Lead Developer Certification.

· Design and develop all Product specific change requests and defect fixes using Appian out of the box configurations and code as much as possible.

· Demonstrate release-worthy functionality for each sprint within a quarterly release.

· Create and maintain product-specific test plans, test scripts and test cases that utilize the appropriate SDLC document templates.

· Create and maintain requirements traceability matrices (RTMs).

· Utilizing OCC approved automated test and performance test tools, create, and maintain automated test scripts that can be reliably executed in a repeatable fashion.

· Conduct regression, functional, integration, and system testing in a dedicated test environment that is isolated from Production.

· Conduct installation testing in a dedicated staging environment that is isolated from Production.

· Create and maintain product-specific test results that utilize the appropriate SDLC document templates. These test results should represent the output of executing the test cases identified in the relevant test plan.

· Perform security testing of new, modified, and reconfigured software

· Create and maintain simulation data for development, testing, and training purposes. To the extent possible, these data sets should be created and maintained so that they can be re-used for testing across multiple products. This task will include the following:

· Work with business-unit and IT stakeholders to identify confidential data that requires protection

· Create and maintain a process for creating simulated data, including a process for redaction

· In situations where simulated data cannot be used for testing, secure the testing data to ensure that no Personally Identifiable Information (PII) is compromised during testing.

· Adapt the testing instance of a product, where necessary, to protect PII during testing

· Consult with the appropriate DBA team to implement database-level protection strategies

· Conduct weekly tests of the products to ensure that the implementation of Microsoft security patches has not negatively impacted the products

· Create and maintain disaster recovery test plans and conduct annual disaster recovery tests.

The Contractor must do the following:

· Write test scripts using approved OCC Enterprise tools for automated (e.g., Selenium) and manual testing (e.g., Rational Functional Tester) for all defect fixes and change requests.

· Use the OCC's approved enterprise performance testing tool (currently Rational Performance Tester) to perform performance testing for a Product release on an as-needed basis.

· Support OCC Security team on performing continuous security testing on any of the Products on the Appian Platform and related components (e.g., IIS web server, JBoss application server, SQL relational database)

· Support User Acceptance Testing for each major release for each Product.

· Use OCC's approved accessibility technology tool to perform 508 testing for each major release for each Product.

· Perform integration testing for all major and minor releases for each Product. This effort is estimated to take a minimum of 40 hours per month.

Test Plans, Test Scripts, and Test Cases (Create and/or update scripts for product. The method of delivery is to place in the OCC’s ALM.)

Variable

Electronic Deliverable

As part of product monthly or quarterly releases, as needed

Requirements Traceability Matrices (RTMs) (Create and/or update scripts for product)

Variable

Sprint Test Results stored in ALM

See Enclosure11_NRISK_2021.1_Test_Analysis_Report

The Contractor must do the following:

· Generate release notes using the acceptance criteria defined in the OCC's enterprise configuration management tool for each major and minor release for each product. The release notes must be created at a minimum of 5 days before the release deployment.

· Maintain the user guides and any other communication/training material for each product.

The Contractor must do the following:

· Present changes to the design of the system at both the Enterprise Review Group (ERG) and Enterprise Change Control Board (CCB) as part of the release management process to ensure that other OCC applications are not impacted by the upcoming system release

· Perform integration, regression, and end-to-end testing for all major releases of a product on the platform. The testing must include validation of product-specific interfaces (e.g., EIR, AEM, BankNet)

The Contractor must do the following:

· Submit requests for all developer and testers for the install of OCC Enterprise Configuration Management tools (currently Rational tools) immediately after adding the resource to the project team

· Submit requests for access to the appropriate ALM project area(s) immediately after adding the resource to the project team

· Ensure its employees are fully trained in the use of the ALM application prior to being added to the project team

The Contractor must do the following:

· Review and maintain the Appian Platform and product-specific best practices, procedures,…