Digital Enablement Development Release Cycle

The Digital Enablement Development (DE-D) Division continuously develops, tests and releases enhancements and fixes for its applications throughout their life cycle. There are four stages of development, testing and release for a new web application: Pilot, Alpha, Beta and Official release.

Before entering the development process, DE-D will determine if an existing open source software exists that meet the business, technical and user requirements for the application. If none meet the requirements, DE-D will look into developing the new application, starting with an minimal viable product (MVP) where they will continue to iterate on the application to add additional features and functionalities.

For the pilot phase, DE-D will either test the selected open source software to decide if it meets the initial requirements, or will test the newly developed product MVP and/or future releases, based on product requirements. The new tool will then enter the Alpha stage where the majority of the new development and design work for the new tool is completed. After all the initial necessary features are developed and tested in Alpha, the new tool will enter the Beta stage for any final bug fixes and enhancements required before the official release.

What is a minimal viable product? In agile product development, the minimum viable product (MVP) is a bare-bones version of a new product that contains a minimum amount of features (usually 1 or 2) and that allows a team to get initial feedback from a small group of users with the least effort. As the main goal of the MVP is to facilitate validated learning, it can take the form of paper prototypes and clickable prototypes that generate qualitative data (as opposed to quantitative data), as long as it helps to test the idea and to acquire the relevant knowledge.

Pilot

DE may test multiple open-source applications to develop a particular tool. When a tool is in the Pilot phase, it means that an open-source application or an MVP is being tested to see if it can meet the user needs, and business and technical requirements, before the tool undergoes more comprehensive development by the DE-D team. It is a short-term, experimental phase to see how the large-scale service may work in practice. A Pilot is sometimes referred to as Pre-Alpha.

Before launching a pilot application. the scope of the project is developed, including user, business and technical requirements. User requirements are determined through research, testing and analysis of the user base. From the project scope, the DE-D team defines a Minimum Viable Product (MVP) to be developed and launched as a pilot. The MVP will not include all the features planned for the application, only the minimum amount of features required to get initial feedback from users. Further features and enhancements which add value to the tool will be developed if the application successfully passes the pilot phase.

Open Pilot testing means that the application is available for real users to test. Closed Pilot testing means that the potential application is only available internally to the team who will be developing the tool. The DE-D team uses both of these Pilot testing methods depending on what makes the most sense for the tool being developed. When possible, open Pilot testing is preferred as it includes the user at the earliest stage of development and provides for more in-dept user feedback.

If the MVP or open-source application being tested is deemed to successful, the application will go on to the next phase of development. If it is deemed to be unsuitable (e.g. does not meet user and/or business requirements), DE-D will determine if there is a need to pivot, abandon or come up with a different solution.

The following tools are in Pilot phase:

• Message
• Etherpad

Alpha

Once it is determined if DE will use a certain open-source application or develop a new application, the tool undergoes Alpha development and testing. During this phase, the features and design of the tool are developed based on the user needs determined in Pilot testing.

If using an open-source application, DE will remove features that do not meet our users' needs, and change the design to align with the Aurora design system. Features may be added to the open-source application if necessary, but the main focus is to make the application stable for the user base. If creating an entirely new application, features are developed by the DE team.

Alpha testing is done by select users to test the usability and user experience of the tool in development, as well as to find major bugs that affect the functionality of the tool. The DE team also focuses on accessibility testing during this stage.

When in Alpha, the tool is functional but may not include all of the enhancements that will be in the Official release. Alpha is complete when all of the necessary features and design are developed and tested, and the tool is ready to be released to the entire user base for testing and feedback.

The following tools are in Alpha phase:

• Directory

Beta

After Alpha testing has ended, the tool enters the Beta stage of development and testing. When in Beta, the tool is at least 90% completed for the official release. During Beta testing users are asked to provide feedback on the design, functionality, and usability of the tool. Beta testing is also done to find minor bugs, as well as bugs which may have been missed in Alpha testing. The DE uses open Beta testing to test its tools, meaning that the tool can be used and tested by every user who wishes to participate in testing in a real environment.

Beta development uses the feedback provided by real users to develop any additional enhancements to the features or design needed to release a tool which is usable with a positive user experience. Bug fixes are also applied during this stage. There may be multiple versions released during the Beta stage.

The following tools are in Beta phase:

• Aurora design system

Official Release

When all necessary features and design are developed and implemented to the new tool, it is officially released. As the DE works in an Agile environment an official release does not mean that development on the tool ends. User research is routinely conducted to see which new features will enhance the tool and how the usability of the tool can be improved. After Official release DE continues to develop and apply these features, enhancements and improvements. Additionally support is provided, and bug fixes are applied throughout the entire life of a tool.

The following tools have been Officially released:

• Account

• GCWiki

• GCcollab (legacy)
• GCconnex (legacy)
• GCpedia (legacy)