Rollout Strategy

Introduction

The Wildfire Visualization application that we are creating will be used by the scientists to analyze the spread of wildfires using data from past wildfire events. There is the possibility that our stakeholder will want this application built on in the future to further expand its potential for wildfire analysis. This means it is imperative that we create well structured, thought out, and efficient code. The best way to achieve this is by having a good rollout strategy so that the team can know what is expected of them and the time frame they have in which to do it. We have structured our rollout strategy according to the structure of the Capstone project that this application is being created for. There will be a total of 3 releases. The code deliverables for these releases are as follows:

• Release 1: Full Project Setup/Documentation and UI Implementation
• Release 2: Majority of Backend Implementation and Dynamic Loading of Data on Frontend
• Release 3: Full Backend Implementation and Deployment of Fully Tested System

Release 1

For release 1, the full project will be setup in terms of repository, CI/CD, boiler plate code, etc. Implementing all of the setup straight away will make the rest of the releases more focused on implementing quality and readable code. This is the most important step of release 1, as a bad setup will lead to many problems down the line. This is also the release where most of the documentation for the system as a whole will be generated.

Following the full setup and documentation, this release is involved with brainstorming, mocking and finally implementing the UI for the application. The reason we don't start the backend in this release is that the document that we have received for the project has had a few iterations with modifications to what needs to be done. Along with this, it took until the first week of November for us to receive an example document of what the structure of the data we will be working with looks like. So, due to the slightly volatile document at the start of the project and missing the data structure required in order to properly setup the backend functionality, the team decided to then focus on the aspects of the project that will not change until the document and data are finalized. Thus, we decided that strictly focusing on the UI was the best idea as we can fully implement it in this release, leaving only the backend functionality and testing for the later releases.

Release 2

For release 2, the goal is to have the majority (and most important) endpoints for the backend setup so we have a prototype of the working system with a frontend able to receive data from the backend. Should the backend still be missing some smaller parts, this can carry over to the third release since release 3 will be focused on quality assurance (testing, refactoring, increasing coverage, etc.) and deployment. The backend will be a REST API, so some of the endpoints that must absolutely be finalized in this release are the endpoints that deal with fetching and parsing the data so that we have something to display to the user.

Release 3

For release 3, we will start by finishing up anything left over from the backend (and the frontend if we missed anything). This should not take more than a week, as the later weeks will involve thoroughly testing the system for any bugs, as well as refactoring code to create a more readable codebase. The quality assurance done in these weeks will heavily rely on the testing suites for both the frontend and backend, as well as SonarQube for ensuring high code coverage and well written code. After the system has been rigorously tested, we will start the deploying process so that our stakeholder can have full access to the application.