CTR050724 A1.pdf

CONTRACT AMENDMENT

CONTRACT No.: CTR050724 AMENDMENT No.: 1

ARIZONA DEPARTMENT OF

HEAL TH SERVICES

OFFICE OF PROCUREMENT

150 N. 18th Ave., #530 Phoen�.Arizona85007

PROCUREMENT OFFICER

Nicole Marquez

Effective upon signature of both parties, it is mutually agreed that the Contract referenced is amended as follows:

1. Pursuant to the Uniform Terms and Conditions, Provision Five (5), Contract Changes, Section 5.1 Amendments, the following changes are hereby made under this Amendment One (1):

1.1. The Scope of Work is revised and replaced with the Scope of Work of this Amendment One (1) to reflect the addition of section 3.4.7.7 under the Scope of Work, Provision Three (3), Scope of Work, Section 3.4. WIC Service Desk Operations, Sub-section 3.4.7:

3.4.7.7. Provide ADHS with a toll-free number that WIC participants can call for eWIC transaction assistance.

Phone calls that are received shall adhere to the requirements defined in SOW sections 3.4. 7.1 through 3.4.7.6.

1.2. Additionally, the Contract Price Sheet is revised to include the Price Sheet of this Amendment One (1 ).

--ALL OTHER PROVISIONS SHALL REMAIN IN THEIR ENTIRETY.--

Contractor hereby acknowledges receipt and acceptance of The above referenced Contract Amendment is hereby above amend eAt nd that a signed copy must be filed with the executed this ____ day of ____ , 20_at

Pr ffective dat Phoenix, Arizona.

'i!adr<?!

CURRIER, MCCABE & ASSOCIATES, INC

Procurement Officer Signature

Contractor's Name

4th January 21

SCOPE OF WORK

ARIZONA DEPARTMENT OF

HEAL TH SERVICES

OFFICE OF PROCUREMENT

150 N. 18th Ave., #530 Phoenix, Arizona 85007

PROCUREMENT OFFICER

Nicole Marquez

1. Background

1.1 HANDS Consortium Overview

1.2

The Arizona Department of Health Services (ADHS) Bureau of Nutrition and Physical Activity (BNPA) includes the Arizona Special Supplemental Nutrition Program for Women, Infants and Children (WIC) Program. ADHS BNPA requires a Contractor to provide the Arizona WIC Program and other members of the Health and Nutrition Delivery System (HANDS) Consortium (American Samoa, Commonwealth of the Northern Mariana Islands [CNMI], Guam, and Navajo Nation WIC Programs) with HANDS maintenance and operations support.

More than six hundred fifty (650) State and clinic staff within the HANDS Consortium utilizes the HANDS application to serve more than 150,000 participants on a monthly basis. The information in Table 1 is an estimate of each of the Partner Agencies as of March 2019.

Partner Agency Local Clinics Participants Estimated WIC Agencies Households Vendors

Arizona 20 100 130,000 77,000 550 American 0 6 5,150 3,000 35 Samoa

CNMI 0 3 3,100 1,950 16

Guam 0 5 6,600 3,700 30 Navajo Nation 0 12 6,800 4,200 101 Total 20 126 151,650 732

HANDS Overview

HANDS is the eligibility and data management system for the WIC and the Farmers' Market Nutrition Program. As of October 1, 2019, ADHS does not utilize FMNP or Commodity Supplemental Food Program (CSFP) modules. Guam uses the FMNP module. Each of the Consortium members within the HANDS Consortium will have its own HANDS software application and each HANDS software application will operate on the same version.

ADHS issues WIC food benefits using on line WIC EBT technology with a magnetic stripe card and PIN. ADHS is currently contracting with Custom Data Processing (CDP) to provide the WIG Direct EBT System and provide transaction processing and support services for EBT transactions. HANDS currently interfaces with WIC Direct using the 2014 Universal Interface. The HANDS to WIC Direct interface documentation is accessible at https://azdhs.gov/prevention/azwic/agencies/index.php#hands. ADHS issues FMNP food benefits on coupons. ADHS is currently contracting with Solutran for food coupon processing services.

1.3 Architecture

HANDS is a two-tiered Web Application implemented using the Microsoft MVC framework in conjunction with a Service Oriented Architecture (SOA) and an Oracle database. HANDS is hosted with Microsoft IIS servers on VMWare in a Datacenter in Phoenix, Arizona with backup datacenter in Tucson, Arizona. The technology stack is primarily comprised of Microsoft MVC4 framework, Razor View Engine, JQuery, C#, java script, LINQ, Dev Art Oracle Data Provider, and Oracle 12c. HANDS is designed to operate efficiently with Microsoft Internet Explorer 11.0 or above. HANDS uses Topaz SigPlus software to operate the signature pads, Microsoft Silverlight (v 5.1.5 or higher) and Epson Perfection (V30, V37, and V39) scanner and drivers to operate scanners, and Core lnterop drivers to operate the Verifone VX 805 PIN pads.

CONTRACT No.: CTR050724

1.4 Operational Status

AMENDMENT No.: 1

ARIZONA DEPARTMENT OF

HEAL TH SERVICES

OFFICE OF PROCUREMENT

150 N. 18th Ave., #530

Phoenix, Arizona 85007

PROCUREMENT OFFICER

Nicole Marquez

HANDS is currently fully operational in the five (5) agencies represented by the HANDS Consortium consisting of American Samoa, Arizona, Guam, Navajo Nation, and CNMI. Daily operations and support continue to be managed by ADHS WIC IT team and the Contractor. ADHS and the Contractor provide first level help desk support for any application or clinic operational issues, clarifications, or questions related to HANDS. The Contractor provides second-level technical help desk support for support items routed to the Contractor for Development. Additionally, the Contractor monitors the end-of-day process to ensure that data is processed successfully for the continued operations of HANDS providing mandatory caseload and financial reporting.

1.5 HANDS Features

1.5.1 HANDS include functionality related to the following areas as outlined in Business Requirement Documents (BRO), associated Change Requests, Requirement Clarifications and Detail Functional Design Documents (DFDD):

1.5.1.1

1.5.1.2

1.5.1.3

1.5.1.4

1.5.1.5

1.5.1.6

1.5.1.7

1.5.1.8

1.5.1.9

1.5.1.10

1.5.1.11

1.5.1.12

1.5.1.13

1.5.1.14

1.5.1.15

1.5.1.16

1.5.1.17

1.5.1.18

1.5.1.19

General System Requirements;

Immunization;

Appointment Scheduler;

Breastfeeding;

Certification and Enrollment;

Food Package - Local Agency;

Food Package - State;

Nutrition Education;

Operation Management;

Program Integrity - Clinic;

Program Integrity - Vendor;

System Administration;

Standard Reports;

Vendor Management;

Farmers Market;

Commodity Supplemental Food Program (CSFP)

Local Agency Profile;

Rebates;

Caseload;

ARIZONA DEPARTMENT OF

HEAL TH SERVICES

OFFICE OF PROCUREMENT

150 N. 18th Ave., #530 Phoenix, Arizona 85007

CONTRACT No.: CTR050724 AMENDMENT No.: 1

PROCUREMENT OFFICER

Nicole Marquez

1.5.1.20

1.5.1.21

1.5.1.22

1.5.1.23

1.5.1.24

FNS-798;

Grants and Cash flow;

Data Archive and Reporting Infrastructure (DARI);

Mango Database; and

Vendor Web

1.5.2 All HANDS DFDDs are posted online at

https://azdhs.gov/prevention/azwic/agencies/index.php#hands. HANDS Documentation will be updated regularly and includes, but is not limited to functionality listed in section 1.4.1.

1.5.3 ADHS is in the planning process for the HANDS Client Portal. All future business requirements and DFDDs documenting system functionality will be posted on line at https://azdhs.qov/prevention/azwic/agencies/index.php#hands.

2. Objective

2.1. To ensure the ongoing technical support for management, operations and maintenance of the HANDS system.

3. Scope of Work

The Contractor shall:

3.1. Project Initiation

Convene a project initiation meeting at the ADHS office in Phoenix, Arizona within ten (10) days of Contract award. The Contractor's Project Manager and other key Contractor staff shall attend the meeting, as deemed necessary by the ADHS. The purpose of the meeting is to establish expectations; review the Contractor Project Plan including schedule and deliverables, and discuss the management of the HANDS maintenance and operations;

3.2. HANDS Management

3.2.1. Use the process of custom agile iterative development methodology to provide exemplary service to ADHS. The process includes active requirements management, design sessions using operational scenarios and wireframes, tracking the entire Software Development Life Cycle (SDLC), Source Code Configuration Management and Release Management in Team Foundation Server (TFS), managing test scripts in Test Manager, using defined and matured process to track activities between and among various sub-groups of the Contractor team, and managing written documentation by actively managing he documentation through the critical path of process.

3.2.2. Support the current architecture, upgrade versions, and proactively manage competitive industry trends so that HANDS architecture remains current in the WIC marketplace.

3.2.3. Key Support:

3.2.3.1 Leverage the significant knowledge and expertise gained through its development of the HANDS or other MIS applications to reduce the project team learning curve and improve continuity of information and project direction.

HEAL TH SERVICES

OFFICE OF PROCUREMENT

150 N. 18th Ave., #530 Phoenix, Arizona 85007

CONTRACT No.: CTR050724 AMENDMENT No.: 1

PROCUREMENT OFFICER

Nicole Marquez

3.2.3.2. Ensure team members assigned to this project are highly qualified, dedicated and skilled with experience in WIC, HANDS or similar MIS implementation or maintenance projects, Microsoft .NET, and Oracle database.

3.3. HANDS Operations Management:

3.3.1 Provide the following resources which will be co-located in the ADHS office located in Phoenix, Arizona.

3.3.1.1 These resources shall support the HANDS maintenance and operations as indicated in sections 3.3.2 through 3.3.14.1.4.

3.3.1.1.1. Provide one (1) full time Resource Manager, which will be responsible for the following, but not limited to:

3.3.1.1.1.1. Interact with ADHS Project Manager(s) for the purpose of coordination, status reporting, and budgeting;

3.3.1.1.1.2. Manage the Contractor's risks including HANDS

application technical risks;

3.3.1.1.1.3. Advise ADHS Project Manager(s) on risks and risk mitigation;

3.3.1.1.1.4. Advise ADHS Project Manager(s) of changes in work direction;

3.3.1.1.1.5. Coordinate and plan the Contractor's team activities;

3.3.1.1.1.6. Manage Project Reporting;

3.3.1.1.1. 7. Work with ADHS Project Manager(s) towards planning and strategies;

3.3.1.1.1.8. Communicate with ADHS Project Manager(s) and

designated ADHS personnel;

3.3.1.1.1.9. Plan and conduct project meetings, including

requirements meetings, evaluation sessions, and design and analysis sessions;

3.3.1.1.1.10. Coordinate review and signoff of deliverables;

3.3.1.1.1.11. Act as single point of contact for all Contractor issues;

3.3.1.1.1.12. Review approved business requirements and identifying strategy for technical architecture and requirement evaluation;

3. 3.1.1.1.13. Identify best business practices for best solution models;

3.3.1.1.1.14. Assist project team members;

HEAL TH SERVICES

OFFICE OF PROCUREMENT

150 N. 18th Ave., #530 Phoenix, Arizona 85007

CONTRACT No.: CTR050724 AMENDMENT No.: 1

PROCUREMENT OFFICER

Nicole Marquez

3.3.1.1.1.15. Ensure that the project is adequately staffed to meet expectations;

3.3.1.1.2. Provide three (3) full time developers, which will be responsible for the following, but not limited to:

3.3.1.1.2.1. Conduct user requirement or design sessions as

needed;

3.3.1.1.2.2. Validate requirements, create wireframes, create development journals;

3.3.1.1.2.3. Identify and document re-engineering possibilities;

3.3.1.1.2.4. Suggest business process improvements;

3.3.1.1.2.5. Identify and document data requirements;

3.3.1.1.2.6. Develop technical documentation;

3.3.1.1.2. 7. Ensure programs meet standards and technical specifications;

3.3.1.1.2.8. Code, test, debug, and implement software work

products using Visual Studio (Microsoft. NET and Oracle);

3.3.1.1.2.9. Provide Level II Help Desk support as needed;

3.3.1.1.2.10. Monitor End-of-Day reports for any corrections;

3.3.1.1.2.11. Monitor data processing for rebates, redemptions, caseload, and financial reporting as needed;

3.3.1.1.2.12. ADHS shall interview and approve any resources

provided prior to hire or reassignment

3.3.1.1.3. Provide two (2) full time Quality Assurance Analysts, which will be responsible for the following, but not limited to:

3.3.1.1.3.1. Participate in requirement and analysis and design sessions;

3.3.1.1.3.2. Work with the project team to identify data requirements;

3.3.1.1.3.3. Plan and designs complex test cases for validation of common and exception processing and user scenarios;

3.3.1.1.3.4. Validate the software to verify that requirements are complete and functions as expected;

3.3.1.1.3.5. Test the application for conformance to requirements;

3.3.1.1.3.6. Report test findings in TFS;

HEAL TH SERVICES

OFFICE OF PROCUREMENT

150 N. 18th Ave., #530 Phoenix, Arizona 85007

CONTRACT No.: CTR050724 AMENDMENT No.: 1

PROCUREMENT OFFICER

Nicole Marquez

3.3.1.1.3.7. Provide Level II Help Desk support as needed;

3.3.1.1.3.8. Train users of application or new software releases;

3.3.1.1.3.9. Assist users or trainers during training;

3.3.1.1.4. Provide one (1) Business Analyst, which will be responsible for the following, but not limited to:

3.3.1.1.4.1. Manage the requirement clarification process as defined in the project and agreed by ADHS;

3.3.1.1.4.2. Assist in project management duties as needed;

3.3.1.1.4.3. Publish meeting minutes from sessions;

3.3.1.1 .4.4. Identify risk and suggest plans to mitigate risks;

3.3.1.1.4.5. Project Responsibilities;

3.3.1.1.4.6. Lead, conduct, and facilitates joint application design or user sessions to elicit and confirm requirements;

3.3.1.1.4.7. Gather business requirements through a variety of techniques such as work sessions and interviews;

3.3.1.1.4.8. Communicate these requirements to appropriate

stakeholders, including customers and development staff;

3.3.1.1.4.9. Provide input into developing and modifying systems to meet ADHS needs;

3.3.1.1.4.10. Coordinates and facilitate meetings with ADHS to gather and document requirements and explore potential solutions;

3.3.1.1.4.11. Participate in requirement and analysis and design sessions;

3.3.1.1.4.12. Advise project team on quality assurance and control best practices;

3.3.1.1.4.13. Conduct & participate in design review sessions;

3.3.1.1.4.14. Develop documentation and maintain project

documentation up-to-date based on release notes;

3.3.1.1.4.15. Publish release notes;

3.3.1.1.4.16. Consolidate, document, and publish implementation details that are not documented in the project;

HEAL TH SERVICES

OFFICE OF PROCUREMENT

150 N. 18th Ave., #530 Phoenix, Arizona 85007

CONTRACT No.: CTR050724 AMENDMENT No.: 1

PROCUREMENT OFFICER

Nicole Marquez

3.3.1.2.

3.3.1.3.

3.3.1.4.

3.3.1.1.4.17. Document functional requirements, operational and training manuals;

3.3.1.1.4.18. Participate as a member of the quality assurance team when required by the project team;

3.3.1.1 .4.19. Train users of application or new software releases;

3.3.1.1.4.20. Assist users or trainers during training;

Each resource in section 3.3.1.1 shall provide forty (40) hours of work per week.

Resources in section 3.3.1.1 that are lost due to turnover shall not be vacant for more than thirty (30) days.

All references to developers, business analysts, quality assurance analysts, and resource manager within this SOW are the Contractor's resources unless referenced specifically as ADHS resources.

3.3.2. Provide the application support from a WIC domain expertise and technical support using Microsoft .NET and Oracle tools. Support network, hardware, database, and technical and application software as required for preventive and adaptive maintenance to ensure business continuity. Business continuity refers to the ability to continue key operations without stoppage, regardless of adverse circumstances or events. These may include Windows configuration or components update, builds scripts definition or update, software modifications required to maintain the continuous operations of HANDS, data conversions or data corrections, one-time data loads, run time improvements, performance upgrades through software code fixes, database or SQL tuning, or server or system software configuration.

3.3.3. Provide a monthly status report on the project, system, and staff. The monthly status report shall include, but not limited to the following:

3.3.3.1.

3.3.3.2.

3.3.3.3.

3.3.3.4.

Work completed;

Work to be completed in the following month;

Risks and Mitigation Strategies; and

Issues and Resolutions

3.3.4. Allow ADHS staff to attend Contractor lead meetings such as but not limited to, daily huddles and sprint planning to promote transparency for work that has been completed, to be completed, and issues.

3.3.5. HANDS Maintenance Management:

3.3.5.1.

3.3.5.2.

3.3.5.3.

Provide maintenance management for HANDS by providing all product or software updates which includes new features, bug fixes, and enhancements.

Ensure HANDS maintains its functionality and stays applicable when compared to emerging technology, clinic operational model, or participant services.

Ensure the HANDS architecture and application code are managed to ensure that the application while it is backward compatible, it does not fall behind on technology or

HEAL TH SERVICES

OFFICE OF PROCUREMENT

150 N. 18th Ave., #530

Phoenix, Arizona 85007

CONTRACT No.: CTR050724 AMENDMENT No.: 1

PROCUREMENT OFFICER

Nicole Marquez

3.3.5.4.

3.3.5.5.

functionality that would result in the application's life cycle coming to a premature end.

HANDS Release Management Planning:

3.3.5.4.1. Collaborate with ADHS for software changes, manage changes through TFS, and submit change request for major, complex, and or exceeding forty (40) hours of development effort.

3.3.5.4.2. Collaborate with ADHS to plan release dates based on the number of items to be completed from the product backlog and new planned features. This will enable every directly affected stakeholder to plan for the release, as the release may entail new policy or procedural changes, training, and data preparation.

3.3.5.4.3. Release a minimum of two (2) major versions of HANDS on an annual basis as agreed upon with ADHS. The releases shall include the following features, feature corrections, or enhancements:

3.3.5.4.3.1.

3.3.5.4.3.2.

3.3.5.4.3.3.

3.3.5.4.3.4.

3.3.5.4.3.5.

Requirements Management

Fixes or changes to already implemented features based on production operations;

Fixes to software (User Interface, Business process, and Stored Procedure) for bugs or issues identified in production operations. This also includes current identified issues or bugs as documented in TFS;

Provide minor enhancement activities - system enhancements that include changes to HANDS to accommodate or meet requirement;

Align data and data structures as it is relevant to HANDS operations; and

Complete pending functionality development on Waitlist Management.

3.3.5.5.1. Ensure the development methodology follows the iterative and incremental development approach, each iteration will begin with analysis and design with its own set of approved or agreed requirements.

This is approached with the use of Joint Analysis and Design (JAD) sessions where requirements analysis, story boards, and 'design mock ups' or wireframes are presented to ADHS to document intended functionality of a new feature or enhancement feature. The output of the requirement or design sessions with ADHS will be documented with clear decisions and action items. During each JAD or requirement session, the Contractor shall work with ADHS to gain clarification of requirements, capture input on design and document design decisions through the use of meeting notes. Notes are used to prepare the use cases or BRO or update DFDD which will be used during the iteration development step.

Development and unit testing are based upon the documented requirements. The Contractor shall update documentation at the conclusion of each iteration.

HEAL TH SERVICES

OFFICE OF PROCUREMENT

150 N. 18th Ave., #530 Phoenix, Arizona 85007

CONTRACT No.: CTR050724 AMENDMENT No.: 1

PROCUREMENT OFFICER

Nicole Marquez

3.3.5.6.

3.3.5.5.2. Align the documentation to be solution documentation that is comprised of features, functions, and characteristics of the functionality or feature.

System requirements are written at different levels of detail and are associated with different types of requirements, for example, business, transition, or reports. The solution documentation may be rendered in any number of forms. Some of the forms include:

3.3.5.5.2.1.

3.3.5.5.2.2.

3.3.5.5.2.3.

3.3.5.5.2.4.

BRO,

Use Cases, and

List of product backlog.

Coordinate with ADHS the requirement management process in place for the HANDS development for any clarification on existing HANDS functionality.

3.3.5.5.3. The purpose of BRDs or use cases is to define the new, modified, or enhanced functionality or process with consideration given to WIC regulations, Arizona WIC policy, processing related to Value Enhanced Nutrition Assessment (VENA), Participant Centered Services (PCS), and the most recent USDA requirements. The BRDs and other associated requirements are not meant to include in-depth programming language, code, or queries. In addition, the newly developed BRO, use cases or change request are not meant to document the complete set of requirements for HANDS. Requirements or functionality of HANDS will be maintained in the DFDD.

3.3.5.5.4. The list of product backlog maintained and managed within TFS

Development Phase:

3.3.5.6.1. Review the product backlog, issue list, approved enhancement, ADHS prioritization, and any open change orders to determine the scope and schedule of one (1) or more sprints. Once a sprint plan is finalized, the Contractor shall publish the plan to the development team. During the sprint cycle, the Contractor shall continue its proven customized agile process for development. The Contractor shall provide guidance to the developers related to the creation of journals and wireframes and will initiate the design and development of the feature. Small or medium features and bugs may be started directly by the developer on consultation with his or her technical lead. The complete SDLC process shall be managed in TFS. Technical Leads in consultation with the Managers shall guide the development process. Requirement documents along with the product documentation and product code shall be used during development.

3.3.5.6.2. The Quality Assurance (QA) team shall update existing test scripts or develop new test scripts for the functionality.

3.3.5.6.3. Ensure that developers have completed unit testing and that the feature implemented is complete. Based on the scope and complexity of the feature implemented, a developer may review design with the team and

HEAL TH SERVICES

OFFICE OF PROCUREMENT

150 N. 18th Ave., #530 Phoenix, Arizona 85007

CONTRACT No.: CTR050724 AMENDMENT No.: 1

PROCUREMENT OFFICER

Nicole Marquez

3.3.5.7

3.3.5.8.

demonstrate the completed functionality. The demonstration shall be completed prior to the release of the software to QA. A technical lead or developer will review the code and approve the check-in of code.

3.3.5.6.4. Ensure that the individual status on assigned tasks are monitored by the Resource Manager through direct conversation or in stand-up meetings.

The Contractor's internal process may involve more than one ( 1) release to the QA site prior to the final production release candidate. Such releases are coordinated by the Contractor depending on the number of items to be completed.

3.3.5.6.5. Manage requirements during this period through the established procedures. Any changes to the agreed upon requirements will be documented and provided for acceptance prior to a change in code, screen, functionality, feature, or database process.

Quality Assurance (QA) Testing

3.3.5.7.1 Ensure that after a new version of software is released for QA, QA analysts shall begin targeted and methodical testing. Targeted testing includes testing for new features or enhancements and testing the fixes related to individual TFS items. Methodical testing follows the testing as described in the QA section of this Contract. The QA analysts shall conduct a formal regression testing that validates that major components of the application are still functional and no functionality has degraded.

The QA analysts shall reject a development release if there is any critical functionality degradation. The QA analysts shall also reject bug fixes that do not have the assurance that it has been unit tested and with the explicit note how the fix was implemented. For reports, The QA analysts shall require a sample report with data from development to prove that the issue has been fixed. A minimum of two (2) weeks will be required by the QA analysts to attest that a release is ready for UAT.

3.3.5. 7.1. Ensure that the business analyst creates release documentation associated with any pending production release during QA activities.

3.3.5.7.2. Use TFS to manage system exceptions identified during the QA process and ADHS UAT review process. Exceptions will be checked to ensure that it conforms to the documented requirements when it relates to the scope of the functionality implemented. Any discrepancy related to requirements will be transferred to the requirement management process.

3.3.5.7.3. The Arizona WIC Program shall have the option to manage the two (2) QA Analysts (referenced in section 3.3.1.1.3) and provide direction in daily testing activities.

UAT Release and Support:

3.3.5.8.1. Ensure the Contractor meets with ADHS QA team to review the test results and outstanding issues to determine follow-up release action and mitigation strategies. Following an internal agreement to release the software for UAT, the Contractor shall promote the build for a UAT authorization.

HEAL TH SERVICES

OFFICE OF PROCUREMENT

150 N. 18th Ave., #530 Phoenix, Arizona 85007

CONTRACT No.: CTR050724 AMENDMENT No.: 1

PROCUREMENT OFFICER

Nicole Marquez

3.3.5.9

3.3.5.10

3.3.5.8.2. Prepare the release scripts and validate data scripts between eight (8) and sixteen (16) hours prior to the UAT release to ADHS. ADHS will release the software to the web servers and install any database scripts that change the model, objects, or data. After a release to UAT is completed, the ADHS will validate the release using specific scenarios as listed below to ensure that the release is stable and is ready for UAT.

3.3.5.8.3. Publish metrics on open bugs so that ADHS is aware that there are no critical bugs open that will impede the release.

3.3.5.8.4. Provide a walkthrough of critical updates and new features during an onsite demonstration.

3.3.5.8.5. Provide release notes to ADHS a minimum of one (1) week prior to delivering the software release to the ADHS QA team. The Contractor shall provide a technical version for State level users and a non-technical version for clinic level users.

Pre-production Release:

3.3.5.9.1 Thoroughly test the new version with ADHS in a production like environment so that any unplanned or undocumented risks found are mitigated. The Contractor shall prepare for pre-production release. ADHS will release the software to the web servers and install any database scripts that change the model, objects, or data. The QA and Development staff shall test the application to ensure that newly introduced features do not impact any current functionality.

3.3.5.9.2. Collaborate with ADHS in full-scale production-like regression testing.

3.3.5.9.3. ADHS will provide an environment similar to production with load balancing multiple servers to complete this pre-production testing.

Production Testing

3.3.5.10.1 Prepare the production release after the written authorization from ADHS.

The Contractor will have forty-eight (48) hours to prepare the production release. The Contractor shall provide a single set of release instructions and associated components, assuming that the same set will be applicable to the five (5) state agencies. The Contractor shall assist ADHS during the production release should there be a need to run scripts or install software. ADHS will release the software to production.

3.3.5.10.2 Attend Pre-Release Meeting. ADHS will prepare a pre-release checklist that detail the tasks and responsibility.

3.3.5.10.3 The Contractor shall provide on-call support during the production release if the ADHS team encounters any issues.

3.3.5.10.4 The Contractor shall notify ADHS immediately, if there are any operational issues found in the application. The Contractor shall work with ADHS to identify mitigation strategies and support the Help Desk as needed.

HEAL TH SERVICES

OFFICE OF PROCUREMENT

150 N. 18th Ave., #530 Phoenix, Arizona 85007

CONTRACT No.: CTR050724 AMENDMENT No.: 1

PROCUREMENT OFFICER

Nicole Marquez

3.3.5.11

3.3.5.12

3.3.5.13

3.3.5.14

Production Release Scope:

3.3.5.11.1 Provide release scope that will include modifications that can be completed within the available development hours (of the three (3) full time developers referenced in section 3.3.1.1.2) for a release.

Additionally, the Contractor shall provide system analysis, data analysis, and process investigative support for clinic operations. If there are large scale enhancements or modifications that require additional time and resources, then the Contractor shall estimate and provide guidance on how it can be handled outside the normal release cycle.

3.3.5.11.2 During each release, design, develop (including database and stored procedures), and test software for completeness as documented in TFS or Change Request Details. The Contractor shall update the test scripts as applicable in the TFS Test Manager to ensure that the software is tested to current requirements.

Production Release Documentation

3.3.5.12.1 The Contractor shall provide ADHS with an updated DFDD to include new or updated product features a minimum of one (1) week prior to production release.

3.3.5.12.2 The Contractor shall provide ADHS with updated State/Clinic level User Manuals a minimum of one (1) week prior to production release.

3.3.5.12.3 The Contractor shall update the HANDS "Help" documentation a minimum of one (1) week prior to production release and have it approved by ADHS. The HANDS "Help" documentation provides instructions for each module with screenshots and is contained within the HANDS. The HANDS "Help" screens shall be updated with the release.

Change Management

3.3.5.13.1 The Contractor shall follow the ADHS defined Change Control process for managing all change requests.

3.3.5.13.2 The Contractor shall prepare all HANDS change requests and document the system and stakeholder impacts. The change request shall include total analysis, development, and testing hours estimate and cost.

3.3.5.13.3 Change requests that utilize staff currently included within this contract will be zero (0) cost.

Project Management Coordination:

3.3.5.14.1 Provide timely information to ADHS project management meetings as required by ADHS. The Contractor shall:

3.3.5.14.1.1 Attend bi-weekly project manager's meeting,

3.3.5.14.1.2 Attend quality assurance meetings as requested by

ADHS MISQA,

HEAL TH SERVICES

OFFICE OF PROCUREMENT

150 N. 18th Ave., #530 Phoenix, Arizona 85007

CONTRACT No.: CTR050724 AMENDMENT No.: 1

PROCUREMENT OFFICER

Nicole Marquez

3.3.5.14.1.3 Attend risk management meetings,

3.3.5.14.1.4 Attend requirement or design meetings as requested by ADHS, and

3.3.5.14.1.5 Attend technical status or review meetings.

3.3.6 Software Development Life Cycle (SDLC) Methodology:

3.3.6.1 Development

3.3.6.1.1 Use the agile development methodology with phased releases of HANDS. These releases will be integrated with new functionality, enhancements to existing functionality, and feature corrections. Iterative development is an approach to software development which centers on the idea of moving development cyclically, rather than trying to do entire features at once. Iterations offer a sampling of the key aspects of the problem and provide a solution that is simple enough to understand and implement easily. Incremental development slices the system functionality into processes or features. In each increment, a slice of functionality is delivered through cross-discipline work, from requirements to deployment. Each iteration or sprint will last two (2) - four

(4) weeks. Each iteration or sprint involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and quality assurance testing when a working set of features is completed.

3.3.6.1.2 Each Iteration or Sprint:

3.3.6.1.2.1

3.3.6.1.2.2

3.3.6.1.2.3

3.3.6.1.2.4

3.3.6.1.2.5

3.3.6.1.2.6

3.3.6.1.2.7

3.3.6.1.2.8

Iteration Planning - Perform refinement cycles consistent with an iterative process. Each refinement process will conduct another Iteration Planning meeting to plan the remaining iterations. Iteration planning meetings will address the following:

Review achievements of past iterations, Identify remaining requirements to be completed based on product backlog and TFS items, Review the planned requirements to be addressed in the present iteration, Assign team to perform requirement analysis in preparation for the iteration design, Decide on whether the current plan should change based on past iteration performance, Modify the iteration plan (if applicable), and

Finalization of the modified iteration plan (if applicable).

HEAL TH SERVICES

OFFICE OF PROCUREMENT

150 N. 18th Ave., #530 Phoenix, Arizona 85007

CONTRACT No.: CTR050724 AMENDMENT No.: 1

PROCUREMENT OFFICER

Nicole Marquez

3.3.6.1.2.9 Iteration Kick Off Meeting - Conducted as a launch point into the next iteration or start of an iteration. This meeting will be led by the Resource Manager and the developers.

The meeting will be attended by key resources such as the business analyst, developers, and quality Assurance Analysts. The kick off meeting will:

3.3.6.1.2.9.1 Focus the team on the requirements of

the current iteration,

3.3.6.1.2.9.2 Identify what screens, workflows, or

functions will be modeled by reviewing HANDS, Detail Functional Design Document, and any Supporting Requirement Documents,

3.3.6.1.2.9.3 Review the iteration plan,

3.3.6.1.2.9.4 Remind team of established standards

to be followed,

3.3.6.1.2.9.5 Present the iteration's schedule and

milestones, and

3.3.6.1.2.9.6 Review the estimated time to complete

based on progress of the project and current plan.

3.3.6.1.3 Iteration Execution

3.3.6.1.3.1

3.3.6.1.3.2

3.3.6.1.3.3

Each iteration shall cover identified aspects of multiple modules, establishing a strong foundation, as the HANDS design and development progresses.

During the execution phase, the technical team leads shall conduct daily scrums and as needed design sessions to determine best solution and guide the developers. Additionally, the team leads will meet with the managers to communicate any issues, risks, or challenges during the execution process so that hurdles are mitigated without an extended impact on the project.

The team leads shall have the ownership to complete the features targeted for the iteration. The development process will be completed after the developer attests that he or she has completed the unit testing and checked the code into the TFS.

During the execution phase, the QA team shall test the previous development release and document any discrepancies with documented requirements or system exceptions in TFS. The system exceptions will be prioritized for implementation in subsequent releases.

The QA team shall also update the test scripts based on any decisions made during the scrum or design meetings.

HEAL TH SERVICES

OFFICE OF PROCUREMENT

150 N. 18th Ave., #530 Phoenix, Arizona 85007

CONTRACT No.: CTR050724 AMENDMENT No.: 1

PROCUREMENT OFFICER

Nicole Marquez

3.3.6.2

3.3.6.1.3.4

3.3.6.1.3.5

3.3.6.1.3.6

3.3.6.1.3.7

3.3.6.1.3.8

Quality Assurance

As noted, iteration could be scheduled two (2) - four (4) weeks depending on the scope and schedule of the planned iteration. Each iteration shall have its own design, development, testing, and documentation activities managing to the scope and goals of the pending release. Each iteration's outcome would be a release. A major release will include several iterations grouping output from more than one ( 1) minor release.

Releases to ADHS QA for UAT will be coordinated through the major release schedule cycle.

Analysis and Design are heavier as iterations start and then they tailor down as more of the system is defined and ultimately coded.

Coding only intensifies after an adequate design has been achieved. It continues until it is tailored down for Readiness Testing.

Testing steadily increases all the way to where preparation for ADHS UAT release.

Documentation is a continuous process ending with the update of DFDD and the creation of release notes.

3.3.6.2.1 Follow the agile methods used for development, by adjusting to ADHS needs with full transparency and effective communication among the SDLC teams. The QA team's participation in the process from the beginning allows for full visibility into the HANDS requirements and design assumptions, including the intent of the business requirement and application design. Starting with iteration planning the QA team participates in defining the requirements by providing a user perspective, defining negative, alternative, and exception scenarios, and identifying potential flow exceptions or gaps. Early participation allows for early test plan development ensuring the scope of testing is covered appropriately and completely to cover the extensiveness of the development effort and requirements. Intimate knowledge of the HANDS and participating in the requirements gathering process allows the team to develop test case scenarios early without the need for implementation knowledge. QA team's participation in the scrum meetings provides immediate and real time feedback of the quality of the product for quicker resolution, fewer iterations and a more stable product. The integrated process that allows the QA and development teams to work together improves the quality of the product at a quicker pace, challenging requirement assumptions and eliminating any ambiguity. The results are documented in development journals or meeting minutes providing a record of decisions made. With each sprint the QA team adjusts and develops detailed acceptance testing scripts and provides feedback to ADHS to modify testing to better reflect the true requirements. Once the final build is provided full formal

HEAL TH SERVICES

OFFICE OF PROCUREMENT

150 N. 18th Ave., #530 Phoen�.Arizona85007

CONTRACT No.: CTR050724 AMENDMENT No.: 1

PROCUREMENT OFFICER

Nicole Marquez testing is completed using the test scripts developed throughout the process prior to authorizing a releasing for User Acceptance Testing.

3.3.6.2.2 Quality Control Methodology

3.3.6.2.2.1

3.3.6.2.2.2

3.3.6.2.2.3

3.3.6.2.2.4

3.3.6.2.2.5

Ensure that Quality Control consists of setting standards and testing are being met. When a final build is released into the QA environment, the Contractor shall perform an initial smoke and sanity test. This test is the same test used to validate a successful UAT release and provides quick feedback on the stability of the system. Once a smoke test has passed successfully the Contractor practice uses a variety of methods for testing including black box testing which includes boundary testing, cause/effect testing, fuzz testing, and comparison testing. The white box testing performed includes path testing, loop testing and control structure testing.

Ensure that the following four (4) levels are covered in the QA process:

3.3.6.2.2.2.1 Unit Testing,

3.3.6.2.2.2.2 Integration Testing,

3.3.6.2.2.2.3 Component Interface Testing, and

3.3.6.2.2.2.4 System Testing.

Maintain and utilize repository of test cases that include but are not limited to unit, functional, integration, scenario tests in TFS. These scripts are maintained in a Master Test Plan and updated by the QA staff based on BRDs, requirements updates, enhancements, and design implementations. The updating process is initiated in several manners including a change request, clarification, or a bug.

Once a build has been deemed acceptable for testing based on the smoke test the QA team shall begin their methodological approach to validating and ensuring no degrade in the HANDS product. This process includes creating a new test plan in the Microsoft Test Manager.

All test cases that pertain to the release shall be copied from the master test plan and placed into the new test plan. All test cases will be run and failures shall be documented in TFS as a bug that is sent to development for resolution. After defects have been resolved the test case is run again to ensure completeness.

After the full testing cycle has been completed, the Contractor's team shall review the listing of defects to evaluate the quality of the product using the priority/severity agreement between ADHS and the

HEALTH SERVICES

OFFICE OF PROCUREMENT

150 N. 18th Ave., #530 Phoenix, Arizona 85007

CONTRACT No.: CTR050724 AMENDMENT No.: 1

PROCUREMENT OFFICER

Nicole Marquez

Contractor. A final end to end testing is completed and the QA Manager certifies the build to be released to ADHS QA for UAT.

3.3. 7 Software Configuration Management:

3.3.7.2 Ensure that the software configuration is managed to ADHS requirements. HANDS is designed to operate efficiently with Microsoft Internet Explorer 11.0 or above.

3.3.7.2.1 Source and Code Structure:

3.3.7.2.1.1

3.3.7.2.2 Environments:

3.3.7.2.3

3.3.7.2.2.1

3.3.7.2.2.2

Development:

3.3.7.2.3.1

The source code control and versioning software used for this project is Microsoft's Team Foundation Server 2016 (TFS). Both Source Code and Database structure scripts are stored in TFS with each having its own respective area. ADHS reserves the right to upgrade to newer version of the software in coordination with the Contractor.

Manage the migration of the HANDS application through the various software environments. There are five (5) main software environments. These are Development, QA, User Acceptance (UAT), Training, and Production.

Each of these has its own hardware and software in place such as database servers, web and application servers, etc. along with other individual environmental components.

The HANDS application is migrated through several different stages and environments before going from development to production as shown below. There is a predetermined set of criteria that the system will need to meet before it is migrated from one (1) environment to another. This criteria includes but is not limited to:

3.3.7.2.2.2.1

3.3.7.2.2.2.2

3.3.7.2.2.2.3

New features, Rework/redesign, and

Test case results

Have the Development team use the ADHS provided local PC's and laptops to access the source code repository (TFS) and to edit the code to accomplish new features and bug fixes in accordance with assigned work. Each developer has a development environment locally that can accomplish the full feature set of HANDS.

Code files are automatically checked out of TFS and checked back in as work is complete using Microsoft's Visual Studio 2015 or newer. ADHS reserves the right to upgrade to newer version of the software in coordination

HEAL TH SERVICES

OFFICE OF PROCUREMENT

150 N. 18th Ave., #530 Phoenix, Arizona 85007

CONTRACT No.: CTR050724 AMENDMENT No.: 1

PROCUREMENT OFFICER

Nicole Marquez

3.3.7.2.3.2

3.3.7.2.3.3 with the Contractor.

These checked out files live on each developer's workstations. The Razor View Engine is used to display the HANDS application for unit testing as they go about their work. Any hardware peripherals (scanners, signature pads, printers, etc.) are also used in conjunction with a developer's setup. A development Oracle database is also used. Optionally, developers may also have a local Oracle instance that they used to accomplish software development.

Additionally, a Build Server manages nightly builds to a HANDS development site. This insures that code checked in each day is compatible with the whole code base and no one's code check-in breaks the site.

3.3.8 Planned Maintenance

3.3.8.1

3.3.8.2

Ensure that the following tasks are implemented in order for the HANDS application and its processes (EOD, SMS, etc.) continue to function optimally. These tasks shall be coordinated with ADHS and implemented:

3.3.8.1.1

3.3.8.1.2

Maintain a current or an ADHS and Contractor agreed upon version of the DevArt dotConnect utility for its primary database connections.

Review HANDS architecture and code base for performance improvements. Performance optimization is a continuous process based upon a cycle of observation, identification, and correction.

The Contractor shall update the HANDS interface with the EBT System to meet the ADHS approved version of the WIC Universal MIS to EBT Interface (WUMEI}. All versions of the WUMEI are available at https://www.fns.usda.gov/wic/wic-electronic benefits-transfer-ebt-quidance.

3.3.8.2.1

3.3.8.2.2

3.3.8.2.3

3.3.8.2.4

The Contractor shall provide a gap analysis comparing the current HANDS to the EBT Contractor's interface with the most recent version of the WUMEI.

Update HANDS real time messages and batch file processes to meet the newer WUMEI standards.

Complete full end to end testing.

Provide the revised HANDS Interface Control Document one (1) week prior to production release.

3.3.9 Documentation Management:

The Contractor shall use ADHS SharePoint to manage documentation in the project. The types of documentation include, but not limited to: BRDs, Change Requests, DFDDs, User Manuals.

HEAL TH SERVICES

OFFICE OF PROCUREMENT

150 N. 18th Ave., #530 Phoenix, Arizona 85007

CONTRACT No.: CTR050724 AMENDMENT No.: 1

PROCUREMENT OFFICER

Nicole Marquez

3.3.10 Application Operations Support:

The Contractor shall:

3.3.10.1

3.3.10.2

3.3.10.3

3.3.10.4

3.3.10.5

3.3.10.6

3.3.10.7

Review the Internet Information Services (IIS) logs and HANDS application optimization logs for any performance degradation or application or infrastructure issues. Implement code changes or application or infrastructure settings changes to ensure optimal performance and quality of the application.

Perform an initial investigation, impact assessment, and determine the urgency of the request, code issue, or application behavior concern and report to ADHS to allow for a decision determining the appropriate course of action while a remedial solution or temporary work-around is implemented while a permanent solution is implemented.

Provide adaptive and preventive maintenance activities that are required due to technical changes to system components such as upgrades or patches to application server, operating system, system or infrastructure software or database.

Provide active security management to counter the increasing speed at which new exploits on web-based applications are devised to ensure that the HANDS application architecture is up-to-date with current industry standards on security.

Fix all ADHS designated security issues discovered during annual HANDS security assessment.

Provide ADHS staff members with assistance in reporting data that is not available using the HANDS reports and c ollaborate with ADHS staff member to determine the business requirements and the format required for the ad-hoc reports.

Review the data extracts generated from HANDS; use ad-hoc scripting to load the extract data into a database table; review the validity of the data based on the ADHS, CDC and FNS specifications; and advise ADHS of any changes to these extracts that may be necessary based on any new specifications.

3.3.11 HANDS Database Monitoring Support:

3.3.11.1

3.3.11.2

Ensure Help Desk personnel monitor logs from the previous night as well as the backup jobs running from OEM. Help Desk staff will send out an email prior to noon denoting the backup status of each of the five (5) state agency production databases.

Provide backup status reports in the following format:

3.3.11.2.1 Date;

3.3.11.2.2 Database Name;

3.3.11.2.3 Database Status;

3.3.11.2.4 Up Since;

3.3.11.2.5 Last;

3.3.11.2.6 Backup Status; and

3.3.12

ARIZONA DEPARTMENT OF

HEALTH SERVICES

OFFICE OF PROCUREMENT

150 N. 18th Ave., #530 Phoenix, Arizona 85007

CONTRACT No.: CTR050724 AMENDMENT No.: 1

PROCUREMENT OFFICER

Nicole Marquez

3.3.11.3

3.3.11.4

3.3.11.2.7 Export Date.

Provide backup status reports for the following servers:

3.3.11.3.1 Arizona HANDS production;

3.3.11.3.2 American Samoa HANDS production;

3.3.11.3.3 CNMI HANDS production;

3.3.11.3.4 Guam HANDS production;

3.3.11.3.5 Navajo Nation HANDS production; and

3.3.11.3.6 Arizona Vendor Web production.

Server Name Server Description

HNDAZ Arizona HANDS production central server

HNDCNM CNMI HANDS production database

HNDGU Guam HANDS production database

HNDNAV Navajo Nation HANDS production database

HNDSAM American Samoa HANDS production database

VENDB Arizona Vendor Web database

Monitor the replication of data between Arizona HANDS production database to the Data Warehouse for database or replication errors. The Contractor shall support ADHS in fixing any identified data problems.

Application Performance Operations Support:

The Contractor shall:

3.3.12.1

3.3.12.2

3.3.12.3

3.3.12.4

Provide application performance support which includes but is not limited to the following factors: network efficiency, database efficiency, hardware capacity and application code efficiency.

To the extent performance issues are associated with the application code and data model the Contractor shall address the same as it is critical for the successful operations of HANDS. If the performance issues are due to other factors, the same will be researched and addressed by ADHS. The Contractor shall evaluate performance improvements along with ADHS based on essential, conditional, and optional improvements based on their impact on overall and marginal performance gained through application, browser, bandwidth, and server capacity, functionality degradation due to regression impact, clinic operational requirements, project risk, and cost.

Continuously evaluate the performance focusing on the following: Server, SQL or database, and application performance to ensure WIC clinics that operate the HANDS application are able to accommodate participants without a significant delayed response from the application.

Conduct controlled test set up to simulate the operations environment to collect data.

HEAL TH SERVICES

OFFICE OF PROCUREMENT

150 N. 18th Ave., #530…