CTR050724 A7.pdf

CONTRACT AMENDMENT

ARIZONA DEPARTMENT OF

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024

HANDS Management, Operations and Maintenance

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

1. Pursuant to the Uniform Terms and Conditions, Provision Five (5), Contract Changes, Section 5.1, the Contract is hereby revised with the following:

1.1 The Scope of Work is revised and replaced.

1.2 The Price Sheet is revised and replaced.

ALL CHANGES ARE REFLECTED IN RED

ALL OTHER PROVISIONS SHALL REMAIN IN THEIR ENTIRETY

Contractor hereby acknowledges receipt and acceptance of above amendment and that a signed copy must be filed with the Procurement Office before the effective date

The above referenced Contract Amendment is hereby executed this _____ day of __________ 20______ at Phoenix, Arizona

(To be filled out by Procurement Office)

Contractor Signature

Contractor Signature Date

Authorized Signatory’s Name and Title

Currier, McCabe & Associates, Inc.

Contractor’s Name Procurement Officer Signature

9/8/25

Rachel Harpootlian, CFO

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024

SCOPE OF WORK

1. Background

1.1. HANDS Consortium Overview

1.1.1. 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. WIC is a public health nutrition program administered by the United States Department of Agriculture (USDA) Food and Nutrition Service (FNS). The Arizona WIC Program’s mission is to safeguard the health of low-income women, infants, and children up to age five who are at nutrition risk, by providing nutritious foods to supplement diets, information on healthy eating, and referrals to health care and social services,

1.1.2. The Arizona WIC Program contracts with 22 Local Agencies to provide services approximately 130,000 (monthly) WIC participants in over 100 clinic locations throughout the State of Arizona. These local agencies are comprised of County Health Departments and non-profit Health Centers,

1.1.3. In addition to Local Agency partnerships, the Arizona WIC Program contracts with approximately 550 grocery stores (vendors) for food benefit distribution. These vendors provide participants with nutritious foods, which improve health outcomes for Arizona’s children and mothers, and

1.1.4. The Arizona WIC Program is the lead State Agency in the Health and Nutrition Delivery System (HANDS) Consortium that includes Arizona, American Samoa, Commonwealth of the Northern Mariana Islands (CNMI), District of Columbia (DC) Guam, and Navajo Nation WIC Programs. All HANDS Consortium members use HANDS as the Management Information System (MIS) to provide WIC participants with certification services, nutrition education, risk assessment, breastfeeding services, outreach services, and food benefits via online Electronic Benefits Transfer (EBT), known as eWIC.

1.2. HANDS Overview

1.2.1. HANDS is a highly scalable, multi-tiered web application implemented using the Microsoft Model-View-Controller (MVC) framework in conjunction with a Service Oriented Architecture (SOA) and an Oracle database. The technology stack is primarily comprised of Microsoft ASP.NET MVC framework, Razor View Engine, jQuery, C#, LINQ, DevArt Oracle Data Provider, and Oracle 19c. HANDS interfaces with the eWIC system, called WIC Direct, using the 2014 version of the WIC Universal MIS to EBT Interface (WUMEI). HANDS interfaces with the eWIC system, called WIC Direct, using the 2014 version of the WIC Universal MIS to EBT Interface (WUMEI). The WUMEI is a standard interface developed and agreed upon by the USDA FNS. Each HANDS Consortium member’s HANDS environment uses the

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024 same code base, interface with WIC Direct, and infrastructure. The HANDS Technology is eleven (11) years old and will be end of life in the next few years.

2. Objective

2.1. Implement HANDS 2.0 by upgrading HANDS architecture and technology stack, modernize the User Interface (UI), update the interface to the eWIC System and implementing changes to HANDS functional and business requirements.

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 receiving full executed Amendment Seven (7). 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 the documentation through the critical path of the 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.

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024

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 shall 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.1.1.1 through 3.3.1.1.4.

3.3.1.1.1. Provide one (1) full time Resource Manager, which shall 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;

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024

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;

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 shall 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

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024 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 shall 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;

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 shall be

responsible for the following, but not limited to:

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024

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

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024 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;

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;

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

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

3.3.1.4. 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:

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024

3.3.3.1. Work completed;

3.3.3.2. Work to be completed in the following month;

3.3.3.3. Risks and Mitigation Strategies; and

3.3.3.4. 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. Provide maintenance management for HANDS by providing all product or software updates which includes new features, bug fixes, and enhancements.

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

3.3.5.3. 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 functionality that would result in the application’s life cycle coming to a premature end.

3.3.5.4. 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:

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024

3.3.5.4.3.1. Fixes or changes to already implemented

features based on production operations;

3.3.5.4.3.2. 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;

3.3.5.4.3.3. Provide minor enhancement activities -

system enhancements that include changes to HANDS to accommodate or meet requirement;

3.3.5.4.3.4. Align data and data structures as it is

relevant to HANDS operations; and

3.3.5.4.3.5. Complete pending functionality

development on Waitlist Management,

3.3.5.5. Requirements 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 Business Requirement Documents (BRD) or update the Detailed Functional Design Document (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.

3.3.5.5.2. Align the documentation to be solution documentation that

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024 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. BRD,

3.3.5.5.2.2. Use Cases, and

3.3.5.5.2.3. List of product backlog.

3.3.5.5.2.4. 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 BRD, 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

3.3.5.6. 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

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024 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 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.

3.3.5.7. 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

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024 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.2. Ensure that the business analyst creates release

documentation associated with any pending production release during QA activities.

3.3.5.7.3. 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.4. 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.

3.3.5.8. 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.

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.

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024

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.

3.3.5.9. 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.

3.3.5.10. 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 details the tasks and responsibility.

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024

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.

3.3.5.11. 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.

3.3.5.12. 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

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024

HANDS. The HANDS “Help” screens shall be updated with the release.

3.3.5.13. 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.

3.3.5.14. 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 MIS QA,

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

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024 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. 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:

3.3.6.1.2.2. Review achievements of past iterations,

3.3.6.1.2.3. Identify remaining requirements to be

completed based on product backlog and TFS items,

3.3.6.1.2.4. Review the planned requirements to be

addressed in the present iteration,

3.3.6.1.2.5. Assign team to perform requirement

analysis in preparation for the iteration design,

3.3.6.1.2.6. Decide on whether the current plan should

change based on past iteration performance,

3.3.6.1.2.7. Modify the iteration plan (if applicable), and

3.3.6.1.2.8. Finalization of the modified iteration plan (if

applicable).

3.3.6.1.2.9. Iteration Kick Off Meeting – Conducted as a

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024 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 Each iteration shall cover identified aspects

of multiple modules, establishing a strong foundation, as the HANDS design and development progresses.

3.3.6.1.3.2 During the execution phase, the technical

team leads shall conduct daily scrums and as needed design sessions to determine

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024 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.

3.3.6.1.3.3 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.

3.3.6.1.3.4 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.

3.3.6.1.3.5 Analysis and Design are heavier as

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

3.3.6.1.3.6 Coding only intensifies after an adequate

design has been achieved. It continues until

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024 it is tailored down for Readiness Testing.

3.3.6.1.3.7 Testing steadily increases all the way to

where preparation for ADHS UAT release.

3.3.6.1.3.8 Documentation is a continuous process

ending with the update of DFDD and the creation of release notes.

3.3.6.2 Quality Assurance

3.3.6.1.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 testing is completed using the test scripts developed throughout the process prior to authorizing a releasing for User Acceptance Testing.

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024

3.3.6.1.2 Quality Control Methodology

3.3.6.1.2.1 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.

3.3.6.1.2.2 Ensure that the following four (4) levels are

covered in the QA process:

3.3.6.1.2.2.1 Unit Testing,

3.3.6.1.2.2.2 Integration Testing,

3.3.6.1.2.2.3 Component Interface

Testing, and

3.3.6.1.2.2.4 System Testing.

3.3.6.1.2.3 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.

3.3.6.1.2.4 Once a build has been deemed acceptable

for testing based on the smoke test the QA team shall begin their methodological

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024 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.

3.3.6.1.2.5 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 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.1 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.1.1 Source and Code Structure:

3.3.7.1.1.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.

3.3.7.1.2 Environments:

3.3.7.1.2.1 Manage the migration of the HANDS

application through the various software environments. There are five (5) main

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024 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.

3.3.7.1.2.2 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 criterion includes but is not limited to:

3.3.7.1.2.2.1 New features,

3.3.7.1.2.2.2 Rework/redesign, and

3.3.7.1.2.2.3 Test case results

3.3.7.1.3 Development:

3.3.7.1.3.1 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 with the Contractor.

3.3.7.1.3.2 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

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024

(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.

3.3.7.1.3.3 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 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 Maintain a current or an ADHS and Contractor agreed upon version of the DevArt dotConnect utility for its primary database connections.

3.3.8.1.2 Review HANDS architecture and code base for

performance improvements. Performance optimization is a continuous process based upon a cycle of observation, identification, and correction.

3.3.8.2 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-guidance.

3.3.8.2.1 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.

3.3.8.2.2 Update HANDS real time messages and batch file

processes to meet the newer WUMEI standards.

3.3.8.2.3 Complete full end to end testing.

3.3.8.2.4 Provide the revised HANDS Interface Control Document

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024 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.

3.3.10 Application Operations Support:

The Contractor shall:

3.3.10.1 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.

3.3.10.2 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.

3.3.10.3 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.

3.3.10.4 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.

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

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

3.3.10.7 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

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024

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 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.

3.3.11.2 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.11.2.7 Export Date.

3.3.11.3 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.

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024

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

3.3.11.4 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.

3.3.12 Application Performance Operations Support:

The Contractor shall:

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

3.3.12.2 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.

3.3.12.3 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.

3.3.12.4 Conduct controlled test set up to simulate the operations environment to collect data. The collected data must provide statistics that allow for

HEALTH SERVICES

OFFICE OF PROCUREMENT

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

CONTRACT NO.: CTR050724 AMENDMENT NO.: 7

PROCUREMENT OFFICER:

Kailee Gray

Revised 06.18.2024 system improvements.

3.3.12.5 Review the HANDS performance and optimization appointment logs on a regular basis to determine the best code solution for improvements to the application.

3.3.12.6 Review application code based on controlled tests to allow for improvement in the general performance of the .NET framework.

3.3.13 End-of-Day (EOD) Operations Support:

The Contractor shall:

3.3.13.1 Ensure the Help Desk verifies successful end of day HANDS processing;

3.3.13.2 Ensure the Help Desk monitors the EOD processing daily by reviewing EOD logs from the previous night; and

3.3.13.3 Monitor the EOD logs for the following production installation of HANDS:

3.3.13.3.1 American Samoa,

3.3.13.3.2 Guam,

3.3.13.3.3 Arizona,

3.3.13.3.4 Navajo Nation, and

3…