Proof Of Concept Release¶

Due Date¶

Due Date: December 4
Grading: Team

Description¶

This is the big Release milestone for this semester. You will develop a vertical proof of concept implementation. That is, your app will need to

1. use all the libraries that will be needed for this project in a significant way, that means more than just 'Hello world'
2. exercise all the external APIs you plan to use, that means writing/reading from a file if you plan to use files, pinging the GPS if you plan to use GPS, sending a tweet if you plan to use Twitter, read/writing to the database if you plan to use a database, etc.
3. deploy, meaning that if it is a webapp it should be running on the Web, if it is an android app it should be running on an android device, etc.
4. implement at least 10% of the final functionality making sure that we as users can verify that you did implement that functionality.

For example, if your project is to build a 2D-platform game (Super Mario Bros) then the proof of concept will have very simple 2D environment where the user can move (you got the keyboard/gamepad working) the main character around (you got animations working), maybe implement one other game mechanic (you got on tricky animation working), the background scrolls, there is at least one sound generated when the appropriate action happens (ex. a jump), and there is at least one Non-Player Character animated.

Build Many Apps, Only One Survives¶

Nowadays, vibe-coding lets us much more easily create multiple POC apps so we can better determine which technology/design/framework/form-factor/etc works best.

So, you can optionally vibe-code multiple apps and compare them. The team can then decide which one is the best one to continue working on for next semester.

If you do, you can include them in your demo video if you want. But, only one app should be in the Release. The Chosen One.

Facilitate Testing¶

You are required to make it easy for us to test your app. This means that:

1. Your Release Notes must have all the information we need to test your app: usernames, passwords, input data files, etc.
2. Your app must be pre-populated with realistic data, user accounts, etc. if this is needed to test the app. For example, if your app is a social media app, you should have some pre-populated user accounts with posts and followers.
3. Do not hardcode inputs. For example, if you claim to have implemented the ability to "draw line charts" then your app must let the user enter the data that will be in the line chart. In some cases this might require adding a "test mode" to your app.
4. Your game must have a "test mode" that we can use to test the game mechanics without having to play through the game.
5. If your app requires deep domain knowledge that we don't have (ex. a medical app) you should provide us with a tutorial that teaches us how to use the app. You can add it to your repo wiki.

Deliverables¶

Your Deliverable is the GitHub Release. You will:

1. Create a git tag on the commit that marks the release. For example: git tag v0.1 for the Proof of Concept Release, git tag v0.5 for the Beta Release, and so on.
2. Push tags to GitHub: git push --tags. Once pushed to GitHub you will find a Release page with the tag name you used in your GitHup repo page. You can rename it there if you like. If you can't get tags to work just create the Release with GitHub.

If you have an Android mobile or desktop app you will:

1. Upload your binary (.apk .exe, etc.) to that Release. To do this on GitHub you just click on the Release, then click "Edit Tag", then click where it says "Attach binaries by dropping them here or selecting them".

If you have an iOS app you will:

1. Send me and the TAs an invite to your TestFlight release.

If you have a webapp you will:

1. Publish your webapp on the Internet.
2. Put the URL of your deployed app in the description textbox for that Release (click on the Release, then click on "Edit Tag" to edit the description). Also, if I need a username/password to access your site make sure you write those down in the textbox, and attach any other files or binaries I might need to test your app (ex, things to upload).
3. The webapp must be accessible until you received the grade for this Milestone.
4. Do not update the deployed webapp until after you get the grade for this Milestone.

Grading Rubric¶

We will be checking all your GitHub Issues associated with this Milestone.

F A failed project does not work, or does not use most of the required libraries or API, or implements only the minimal functionality.

A C-level project uses most of the required APIs or libraries and implements basic core functionality.

A B-level project uses all the required APIs and libraries and implements basic functionality.

An A-level project project uses all the required APIs and libraries in a non-trivial way, and implements the core 10% of the final project functionality.