Prototype Directions

Due 11:59 pm, Monday 11/8. 

The prototype is the summative deliverable that follows the formative proof of concept. It is your first graded deliverable requiring functional code that is deployed in some meaningful way. Minimal features should be implemented that are sufficient to demonstrate that your final technical goals are plausible; such an implementation is often termed a minimum viable product or MVP. It should be deployed as a simple web, mobile, or desktop application (depending on your project) that can be demoed to a user or target audience for feedback.

Changes from the Proof of Concept

The directions for the prototype are generally the same as for the proof of concept deliverable. The only change is the addition to the testing plan directions that you explicitly address security and accessibility; see directions below. You are welcome to start with the text from your proof of concept and edit/update from there.

General Directions

There are three high level requirements.

1. 1. Tag the specific commit on your master branch that represents your functional proof of concept (a.k.a. minimum viable product) with “Prototype“.
   2. Include a 4-6 minute video demo of you using your prototype and provide a voice over on the video to describe what is happening in the code.
   3. Draft a Prototype Report in your team Gitlab project repository as a Wiki (written in Markdown). Once you have completed it, create a pdf (by simply printing the Wiki page) and submit the pdf on Gradescope (accessible via Sakai) under the assignment labeled “Prototype Report”. We will use Gradescope to provide feedback. Be sure to include your names and NetIDs and use the group submission feature on Gradescope to include all team members.   

Report Directions

Your report should include the following sections.

Executive Summary

This is the same prompt as in the proposal and re-proposal. As always you can start with what you wrote before, but you should update your executive summary to reflect the evolving project and provide a concise introduction. Provide a name for your project (it can be the same as that used for the pitch, but you can change it as well). If you want your computational/software artifact (our general term for an app, model, algorithm, etc.) to have a separate name, provide that as well. Briefly introduce your project and describe the goal of the project. Specifically, what problem(s) are you trying to solve, and what do you hope the final deliverable(s) of the project will be? 

Prototype Features and Value

Describe the functional features in your Prototype / MVP implementation. Also explain why you selected these particular features to prioritize for your proof of concept implementation. Explain what value these features bring toward addressing the goals of the project.

System Design Justification

Explain why your team has designed the software the way you have such that anyone familiar with the project and with a technical background can read to understand the project’s organization. Describe the high-level architecture and goals of your design (rather than low-level code specific implementation decisions). Additionally, justify significant decisions your team has made in relation to the project’s design goals (whether it was code you wrote or a library or framework you used instead of writing it yourself). For each such decision, address the following in your justification:

1. 1. Issue needing a decision
   2. Choice that was made (if already made)
   3. Justification of choice
   4. Alternative choices considered and trade-offs
   5. Dependencies related to other issues

Testing and Feedback Plan

Describe how the team intends to verify the project’s quality such that anyone familiar with the project can read to understand how features will be tested and feedback will be acquired. For each major feature and functionality, address the following.

1. 1. Provide details about how it might be affected by security and accessibility concerns, also think about how you might test these concerns.
   2. Test scenarios. These are different aspects of a given features that may need to be tested. See these examples. List as many test scenarios as you can think of for each feature.
   3. Definition of Done. How will you verify features are complete and working in a replicable manner? Note, strategies may differ across features (e.g., some may be automated using different tools, but some may need to be manual)?
   4. Resources. What do you need to support your tests (i.e., data files, scripts, mock databases, etc.)?

Release Management Plan

Describe how the team will manage the project’s software release such that anyone familiar with the project can read to understand how the stable release will be distinguished from the current development version as well as how the project’s deployment dependencies (technology, libraries, resources, etc.) are managed. This serves the purpose of clarifying the packaging and delivery of the elements of a product. Address the following.

1. 1. Release Environments. List all the places you expect the app to be deployed (e.g., app and server, app on multiple platforms, web or mobile app, etc.) and your ideal production environment for each (note, include in your planning the minimal version of the software you can use, i.e., deploying only to the latest version of iOS or Android limits your app to only those users that have upgraded recently). How do you plan to separate the production environment(s) from the test environment(s) (i.e., there should always be a current stable version of your app available to demo)?
   2. Release Packaging. List the current and expected project dependencies. How do you plan to make them known and easily gettable for future maintainers (e.g., Docker container, maven or package-info file or other dependency manager, VM, etc.)?
   3. Release Build Management. What is your pipeline (i.e., process and tools) used for building a development versus a production release? How are these integrated with your GIT workflow (i.e., the branches you merge and pull from and the tags you use)?
   4. Release Deployment. How do you plan to deploy to each release environment? What parts of the process can be automated and what cannot?
   5. Defect Tracking. How do you plan to track project bugs from open to close? We are not suggesting learning true bug-tracking software, but you should at least make bugs into actual Gitlab issues, using this template, that are fixed in separate commits with separate tests (ideally made before the bug is fixed to better verify the bug and the fix).
   6. Software Configuration/Change Management (SCM). How will the team collectively determine if a feature is ready to be released or a change (e.g., a bug or security fix or a feature update) should (or should not) be added to the current production release? What is the overall process for managing which features are in which releases, tracking which changes have been applied to which releases, verifying a change works in the current production release, and determining when the current release should be replaced by a new release?

Updated Milestones and Timeline 

You identified weekly milestones in your proposal and re-proposal. Milestones change over the course of an evolving project. Discuss whether you accomplished your milestones up to the prototype. For any milestones you did not achieve, discuss what prevented you from succeeding and how you will achieve them in the future or how you have reimagined those milestones. Finally, provide an updated schedule of milestones for the remainder of the semester. As always you can start with your previous schedule, but update it to match the evolving project.