Skip to content

Proof Of Concept Milestone

Due Date

Due Date: December 6
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

The goal is to have a fully functioning proof-of-concept1 of your final application. That is, you want to prove to yourself that all your chosen libraries and frameworks do work together well and that you can implement and deploy a working app.

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.

Deliverables

To release your code you will:

  1. Create a git tag named v0.1 on the commit that marks the release: git tag v0.1

  2. Push tags to GitHub: git push --tags. Once pushed to GitHub you will find a Release page called v0.1 in your GitHup repo page. You can rename it to Proof of Concept if you like. We will look for either. If you can't get tags to work just create the Release called Proof of concept 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 the last day of Finals.
  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.

  1. Also known as a tracer-bullet implementation, cf. The Pragmatic Programmer, ↩