1.0 Release Milestone¶
Due Date¶
Monday, April 22
Grading: Team
Description¶
It will have all the features implemented and have fixed all the bugs in your issues list.
Grading Rubric¶
F A failed project has show-stopper bugs, or fails to implement the app's *core functionality, or is very hard to use for the intended audience. A *show-stopper bug is one that makes the program unusable in practice.
A C-level project implements the app's core features and has no show-stopper bugs. It can have small bugs. It can be missing some small required features. It looks OK.
A B-level project does everything as above but does not have any bugs. The UI looks good. Has unit/behavioral tests. The code is commented. The project implements all the required features, but no more.
An A-level project is a professional-quality fully-featured app, as found in the top-10 list in the app stores. It does everything as above and goes beyond the core functionality by implementing extra features. It is a pleasure to use and to look at. Has good test coverage. The code has comments that explain what each file does as what each major method does.
We will be checking all your approved GitHub Issues associated with this Milestone, as well as your Requirements document.
Prioritizing Issues¶
Sometimes you don't have time to do everything. Which things should you work on? The recommendations below are roughly in order of importance:
- First make it work, then make it look good. Functionality comes first. Of course, both are required for an A-level project.
- Include all expected functionality. For example, users expect that if they can login to an app they can also logout and login with a different account, or that if they can create a Post they can also edit and delete said Post. Hopefully you anticipated all these features in your Requirements, but that is very rare. Many expected features only become obvious after you have a running prototype.
- Do not include broken parts. Never crash. If you decide to drop a feature , make sure you also delete the button/whatever that activates it. The final app should be a complete app: everything in it works, even if it does not include everything it should.
- Ensure usability. Let others (QA milestone, users, friends) use it and listen to what they say. If you have to explain "ahh, you do that by ..." then the app could be made easier to use. Think of ways to keep users from asking you how to use your app.
- Aesthetics are important. For example, bad color palette can make people assume your app is buggy from the moment they open it. Make it look professional. If in doubt, copy the style of popular apps.
Deliverables¶
To release your code you will:
- Create a git tag
named v1.0 on the commit that marks the release:
git tag v1.0 - Push tags to GitHub:
git push --tags. Once pushed to GitHub you will find a Release called v1.0 in your repo. If you can't get tags to work just create the Release called v1.0 with GitHub.
If you have a mobile/desktop app you will:
- Upload your binary (.apk .exe, etc.) to the Release.
If you have a webapp you will:
- Publish it on the Internet.
- Put the URL of your deployed app in the description textbox for that release. 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).
- The webapp must be accessible so we can test it.
- Do not update the deployed webapp until after you get the grade for this Milestone.