Difference between revisions of "CSPS Digital Academy Innovation Services - Services d'innovation de l'Académie du numérique de L'ÉFPC/Product Development Cycle"
| (5 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
[[FR:DIS-SIN/Cycle de développement des produits]] | [[FR:DIS-SIN/Cycle de développement des produits]] | ||
| + | {{DISnavbar}} | ||
| + | <br> | ||
<span style="float:right;">__TOC__</span> | <span style="float:right;">__TOC__</span> | ||
| − | The Canada School of Public Service (CSPS) [[DIS-SIN| | + | The Canada School of Public Service (CSPS) [[DIS-SIN|Innovation Services]] (IS) team is always working on new products to support the mandate of the CSPS, the [https://www.csps-efpc.gc.ca/About_us/Business_lines/digitalacademy-eng.aspx Digital Academy] (DA) and the Government of Canada (GC). As IS works on developing new applications, the team is continuously developing, testing and releasing enhancements and fixes throughout the development release cycle. There are four stages of development, testing and release for a new web application: Proof of Concept, Alpha, Beta and Official Release. <br> |
<br> | <br> | ||
| − | During the proof of concept phase, | + | During the proof of concept phase, IS will attempt to demonstrate the feasibility of a concept or product to verify if it has the potential of being used. The team will either test an open-source software to see if it meets the initial requirements or will test a newly developed Minimal Viable Product (MVP). If the concept or product successfully goes through the proof of concept phase, it will then enter the Alpha phase where the majority of the new development and design work for the new product will be completed. Once the initial necessary features are developed and tested in Alpha, the new tool will enter the Beta phase where at least 90% of the application is completed and is released to users as the Minimal Marketable Product (MMP). During the Beta phase, final bug fixes and enhancements required are addressed before the application is officially released. |
{| class="wikitable" | {| class="wikitable" | ||
| Line 26: | Line 28: | ||
==Proof of Concept== | ==Proof of Concept== | ||
| − | A proof of concept (POC) is a way for | + | A proof of concept (POC) is a way for IS to test and demonstrate the feasibility of a concept or product to verify if it has the potential of being used. A proof of concept is usually small and may or may not be complete. The team will either test an existing open-source application to see if it meets the initial requirements or will test a newly developed '''Minimal Viable Product (MVP)''', before the product undergoes more comprehensive development by the IS team. It is a short-term, experimental phase to see how the large-scale service may work in practice and allows to better investigate a set of technologies and how they might work in a specific business culture. |
| − | Before doing a proof of concept, 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 | + | Before doing a proof of concept, 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 IS team will conduct research to determine if an open-source application exists that could meet these requirements. If not, the team will develop a Minimum Viable Product (MVP). 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 that add value to the tool will be developed if the proof of concept proves to be successful. |
| − | '''Open Proof of Concept''' means that the product, or application, is available and open for any users to test. '''Closed Proof of Concept''' means that the product, or application, is only made available to a small set of users, or is only available to the team who is developing the tool. The | + | '''Open Proof of Concept''' means that the product, or application, is available and open for any users to test. '''Closed Proof of Concept''' means that the product, or application, is only made available to a small set of users, or is only available to the team who is developing the tool. The IS team uses both of these testing methods depending on what makes the most sense for the product being developed. When possible, open proof of concept 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 be 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), | + | If the MVP or open-source application being tested is deemed to be 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), IS will determine if there is a need to pivot, abandon or come up with a different solution.<br> |
<br> | <br> | ||
'''The following product is an open proof of concept:''' | '''The following product is an open proof of concept:''' | ||
| Line 40: | Line 42: | ||
Once a product (existing open-source software or new MVP) successfully passes the proof of concept phase, the application will undergo Alpha development and testing. During this phase, the features and design of the application are developed based on the user feedback received during the initial testing. | Once a product (existing open-source software or new MVP) successfully passes the proof of concept phase, the application will undergo Alpha development and testing. During this phase, the features and design of the application are developed based on the user feedback received during the initial testing. | ||
| − | If using an open-source application, | + | If using an open-source application, IS will develop additional features and/or remove features in order to meet users' needs, and align the user interface with the CSPS and Digital Academy look and feel. The main focus is to make the application stable, accessible and usable for the user base. |
| − | 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.<ref>“What Is Alpha Testing? An Early Alarm for Defects.” ''Software Testing Help'', 7 June 2018, www.softwaretestinghelp.com/alpha-testing/.</ref> The | + | 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.<ref>“What Is Alpha Testing? An Early Alarm for Defects.” ''Software Testing Help'', 7 June 2018, www.softwaretestinghelp.com/alpha-testing/.</ref> The IS 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 part of the Minimal Marketable Product (MMP) and the official release. The Alpha phase is complete when all of the necessary features and design are developed and tested, and the tool is ready to be released as the MMP, during the Beta phase, to the entire user base for further testing and feedback.<ref>Christensson, Per. "Alpha Software Definition." ''TechTerms''. Sharpened Productions, 05 April 2013. <<nowiki>https://techterms.com/definition/alpha_software</nowiki>>.</ref> | When in Alpha, the tool is functional but may not include all of the enhancements that will be part of the Minimal Marketable Product (MMP) and the official release. The Alpha phase is complete when all of the necessary features and design are developed and tested, and the tool is ready to be released as the MMP, during the Beta phase, to the entire user base for further testing and feedback.<ref>Christensson, Per. "Alpha Software Definition." ''TechTerms''. Sharpened Productions, 05 April 2013. <<nowiki>https://techterms.com/definition/alpha_software</nowiki>>.</ref> | ||
==Beta== | ==Beta== | ||
| − | After Alpha testing has ended, the application enters the Beta phase of development and testing. When in Beta, the application is at least 90% completed and is release to users as the '''Minimal Marketable Product (MMP)'''. 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 and address minor bugs, as well as bugs that may have been missed in Alpha testing.<ref>“What Is Beta Testing? A Complete Guide.” ''Software Testing Help'', 7 June 2018, www.softwaretestinghelp.com/beta-testing/.</ref> The | + | After Alpha testing has ended, the application enters the Beta phase of development and testing. When in Beta, the application is at least 90% completed and is release to users as the '''Minimal Marketable Product (MMP)'''. 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 and address minor bugs, as well as bugs that may have been missed in Alpha testing.<ref>“What Is Beta Testing? A Complete Guide.” ''Software Testing Help'', 7 June 2018, www.softwaretestinghelp.com/beta-testing/.</ref> The IS team 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 or make any modifications to the user interface design needed in order to release an application that is usable and accessible, offering the best possible user experience. There may be multiple versions of the application released during the Beta phase<ref>“Beta Software.” ''Beta Software Definition'', 5 Apr. 2013, techterms.com/definition/beta_software.</ref>. | Beta development uses the feedback provided by real users to develop any additional enhancements or make any modifications to the user interface design needed in order to release an application that is usable and accessible, offering the best possible user experience. There may be multiple versions of the application released during the Beta phase<ref>“Beta Software.” ''Beta Software Definition'', 5 Apr. 2013, techterms.com/definition/beta_software.</ref>. | ||
| Line 56: | Line 58: | ||
==Official Release== | ==Official Release== | ||
| − | When all necessary features and designs are developed and implemented as part of the new application, it is ready to be officially released. As the | + | When all necessary features and designs are developed and implemented as part of the new application, it is ready to be officially released. As the IS team works in an agile environment, an official release does not mean that development on the application ends. User research is routinely conducted to determine if enhancements are required and how the usability of the tool can be improved. After the official release, IS continues to fix bugs, develop and release new features, enhancements and improvements on a continuous basis throughout the entire life-span of the application. |
==References== | ==References== | ||
<references /> | <references /> | ||
Latest revision as of 15:15, 22 September 2020
| Home | Our Team | Our Product Development Cycle |
How We Work | Contact Us |
The Canada School of Public Service (CSPS) Innovation Services (IS) team is always working on new products to support the mandate of the CSPS, the Digital Academy (DA) and the Government of Canada (GC). As IS works on developing new applications, the team is continuously developing, testing and releasing enhancements and fixes throughout the development release cycle. There are four stages of development, testing and release for a new web application: Proof of Concept, Alpha, Beta and Official Release.
During the proof of concept phase, IS will attempt to demonstrate the feasibility of a concept or product to verify if it has the potential of being used. The team will either test an open-source software to see if it meets the initial requirements or will test a newly developed Minimal Viable Product (MVP). If the concept or product successfully goes through the proof of concept phase, it will then enter the Alpha phase where the majority of the new development and design work for the new product will be completed. Once the initial necessary features are developed and tested in Alpha, the new tool will enter the Beta phase where at least 90% of the application is completed and is released to users as the Minimal Marketable Product (MMP). During the Beta phase, final bug fixes and enhancements required are addressed before the application is officially released.
Minimal Viable Product (MVP) vs. Minimal Marketable Product (MM)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. What is a minimal marketable product?The minimal marketable product (MMP) is a version of a product that includes a small set of features that addresses the needs of the initial users (innovators and early adopters), and that can be released to the market. The main goal of the MMP is to reduce the time-to-market as it can be launched more quickly than a feature-rich product. The MMP helps focuses on what really matters, without all the unnecessary features. In summary: The MVP helps you test your ideas. The MMP enables you to launch your product faster. |
Proof of Concept
A proof of concept (POC) is a way for IS to test and demonstrate the feasibility of a concept or product to verify if it has the potential of being used. A proof of concept is usually small and may or may not be complete. The team will either test an existing open-source application to see if it meets the initial requirements or will test a newly developed Minimal Viable Product (MVP), before the product undergoes more comprehensive development by the IS team. It is a short-term, experimental phase to see how the large-scale service may work in practice and allows to better investigate a set of technologies and how they might work in a specific business culture.
Before doing a proof of concept, 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 IS team will conduct research to determine if an open-source application exists that could meet these requirements. If not, the team will develop a Minimum Viable Product (MVP). 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 that add value to the tool will be developed if the proof of concept proves to be successful.
Open Proof of Concept means that the product, or application, is available and open for any users to test. Closed Proof of Concept means that the product, or application, is only made available to a small set of users, or is only available to the team who is developing the tool. The IS team uses both of these testing methods depending on what makes the most sense for the product being developed. When possible, open proof of concept 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 be 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), IS will determine if there is a need to pivot, abandon or come up with a different solution.
The following product is an open proof of concept:
- Evalhalla
Alpha
Once a product (existing open-source software or new MVP) successfully passes the proof of concept phase, the application will undergo Alpha development and testing. During this phase, the features and design of the application are developed based on the user feedback received during the initial testing.
If using an open-source application, IS will develop additional features and/or remove features in order to meet users' needs, and align the user interface with the CSPS and Digital Academy look and feel. The main focus is to make the application stable, accessible and usable for the user base.
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.[1] The IS 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 part of the Minimal Marketable Product (MMP) and the official release. The Alpha phase is complete when all of the necessary features and design are developed and tested, and the tool is ready to be released as the MMP, during the Beta phase, to the entire user base for further testing and feedback.[2]
Beta
After Alpha testing has ended, the application enters the Beta phase of development and testing. When in Beta, the application is at least 90% completed and is release to users as the Minimal Marketable Product (MMP). 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 and address minor bugs, as well as bugs that may have been missed in Alpha testing.[3] The IS team 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 or make any modifications to the user interface design needed in order to release an application that is usable and accessible, offering the best possible user experience. There may be multiple versions of the application released during the Beta phase[4].
The following tool is in the Beta phase of development:
Official Release
When all necessary features and designs are developed and implemented as part of the new application, it is ready to be officially released. As the IS team works in an agile environment, an official release does not mean that development on the application ends. User research is routinely conducted to determine if enhancements are required and how the usability of the tool can be improved. After the official release, IS continues to fix bugs, develop and release new features, enhancements and improvements on a continuous basis throughout the entire life-span of the application.
References
- ↑ “What Is Alpha Testing? An Early Alarm for Defects.” Software Testing Help, 7 June 2018, www.softwaretestinghelp.com/alpha-testing/.
- ↑ Christensson, Per. "Alpha Software Definition." TechTerms. Sharpened Productions, 05 April 2013. <https://techterms.com/definition/alpha_software>.
- ↑ “What Is Beta Testing? A Complete Guide.” Software Testing Help, 7 June 2018, www.softwaretestinghelp.com/beta-testing/.
- ↑ “Beta Software.” Beta Software Definition, 5 Apr. 2013, techterms.com/definition/beta_software.