The purpose of the Quality Management Plan (QMP) is to outline the processes and activities that will ensure the activities in this PMP meet quality goals. This plan defines the quality objectives, standards, and methodologies for development, testing, deployment, maintenance, support and training. The QMP also establishes guidelines for maintaining software quality throughout the project lifecycle, ensuring that the product meets user requirements and is delivered with minimal bugs.

Quality Objectives

The quality objectives are:

  • Ensure that the software meets all specified requirements for usability, performance, and security. Software must be compliant with G6 security requirements and STIGs. 
  • Include documentation within the code to allow others to easily step through and understand the code.
  • Reduce bugs and errors in software by developing unit tests for adequate test coverage of code.
  • Provide software application documentation, training material, and support that allows the water management community to effectively use CWMS and WMES tools.

Quality Assurance Activities

Requirements Review

Ensure that all requirements are clear, complete, and testable. Conduct regular requirement reviews with the team to validate understanding and capture any changes.

Design Reviews

When appropriate, HEC teams will conduct design reviews to ensure that the architecture and design of new software enhancements and technology transfer material meet the quality standards and requirements. Involve cross-functional teams to assess the impact of design choices on performance, security, and maintainability. 

Code Reviews

Code reviews play a critical role in ensuring the quality, efficiency, and maintainability of the software. When appropriate, each team will conduct code reviews prior to merging code into the main branch. 

Software Testing Strategy

CWMS testing is an integral part of the development process. Testing starts with automated unit tests that are part of the build process. Changes and modifications to the software are not incorporated if the tests fail. Verification tests are then completed by developers to ensure bug fixes and other changes behave as expected within CWMS. Regression, or benchmark tests, are completed by the development team prior to release. These tests cover a wide range of the CWMS software and ensure each feature performs as expected and computations match previous known results. Field acceptance tests are the final phase of testing, and occur at volunteer district or division offices. The volunteer offices test the CWMS software release candidate by conducting their everyday water management functions using both the current and proposed versions of the CWMS software. Any issues or discrepancies with the release candidate reported by the field are addressed in an updated release candidate and back-checked by the district prior to release.

In FY24, CWMS developers established an automated testing framework to improve the speed and frequency of testing. The automated testing framework allows for benchmark tests to be run systematically as part of the build process, and changes are not incorporated if the tests fail. In FY25, developers will continue to expand the automated testing program, and look to migrate additional manual regression and benchmark tests to the automated environment. In addition, further improvements in the automated testing framework are planned for FY25, including the ability to automatically test the extract of data from a test server for use in a CWMS forecast.

DevOps Principles

Continuous Integration (CI)

Continuous Integration (CI) is a software development practice where developers regularly integrate code changes into a shared repository, followed by automated builds and tests. The primary goal of CI is to detect and address integration issues quickly, ensuring that the codebase remains stable and functional. CI pipelines are set up to automatically build the code, run tests, and generate feedback about the build status. This iterative approach helps to identify bugs early in the development cycle, promotes collaboration among team members, and allows for rapid integration and delivery of code changes. By enabling frequent integration, CI enhances code quality, reduces the risk of conflicts, and facilitates a smoother and more efficient development process.

Continuous Delivery (CD)

Continuous Delivery (CD) is a software development practice that extends Continuous Integration by automating the deployment process to make software releases more reliable, efficient, and frequent. In Continuous Delivery, every code change that passes through the CI pipeline is automatically tested and verified for deployment readiness. The primary objective of CD is to streamline and expedite the release process by automating build, testing, and deployment stages, enabling software to be delivered to production at any time. By implementing CD, teams can ensure that their code is always in a deployable state, which allows for faster feedback, frequent releases, and increased agility in responding to customer needs.

Teams will work to automate deployment processes to reduce manual errors and improve release speed. Ensure every code change passes through rigorous testing stages before it is ready for deployment, and where appropriate implement automated rollback mechanisms in case of failures.

Maintenance and Bug Fixes

CWMS and WMES software will continuously be supported and updated to address any issues identified, for the supported lifetime of the product. Software bugs will be identified through automated monitoring, user reports, or testing. Bugs will be assessed and prioritized based on severity, user impact, and the potential security risk. The team member who logs the bug in Jira will assign the Jira ticket to the appropriate teammate for investigation/resolution. After the bug fix is completed, it will need to be tested to verify the fix was applied appropriately and no other issues were introduced. The new code will be merged into the main branch and included for the next cycle release. 

Continuous Improvement

Lessons learned and best practices should be integrated into future releases, fostering a culture of continuous improvement and instilling a sense of quality ownership across the team.