Changes

A proof of concept (POC) is a way for DE 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. DIS 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 DIS 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.   

A proof of concept (POC) is a way for DE 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. DIS 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 DIS 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 DE-D team will conduct research to determine if an open source application exist that could meet these requirements. If not, DE-D 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.   

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 DIS team will conduct research to determine if an open-source application exists that could meet these requirements. If not, DIS 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 DE-D 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.

'''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 DE-D 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), DE-D will determine if there is a need to pivot, abandon or come up with a different solution.  

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), DIS will determine if there is a need to pivot, abandon or come up with a different solution.  

==Alpha==

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

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, DE will develop additional features and/or remove features in order to meet users' needs, and align the user interface to use the [[Aurora|Aurora design system]]. The main focus is to make the application stable, accessible and usable for the user base.   

If using an open-source application, DE will develop additional features and/or remove features in order to meet users' needs, and align the user interface to use the [[Aurora|Aurora design system]]. 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 DE-D team also focuses on accessibility testing during this stage.

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