Your final project is due at 5:00PM Monday, June 8.
What to hand in
Code repository. Add and push a tag named "final" to your
repository. Don't forget that "git push" does not push tags. See
this explanation of tagging
to remind yourself how to create and push tags.
I will assume that your repository URL is unchanged. So you don't need to hand
in your repository directly to me. Just make sure it's up-to-date and properly tagged.
What needs to be in your repository?
- All the code, data files, resource files, and project files
required to build and run the software using Xcode or Android Studio.
The only exceptions here are: (1) external libraries used by your project, whose
installation you will describe in your readme file, and (2) account key information
such as your Google Maps API key. In the case of (2), please submit your key to me
via email; I promise to delete all copies of it after I'm done grading.
- A readme file at the top level of your repository. Its contents are
described below.
- A license.txt file at the top level of your repository. Its contents are
described below.
Your readme file (either readme.txt or readme.md), should be located at the
top level of your repository, and should contain:
- The name of your project.
- The name(s) of your client(s).
- The names of your team members.
- A short (1-paragraph max) description of your project.
- Instructions, if any, on how to build your project. For most projects, this won't be
required. But if, for example, your app requires a Google Maps API key, then your readme
should link to instructions on how to get one, and then where to place it once you have it.
- Instructions for how to install any external libraries required by your
project. (You may provide instructions via a sentence saying the library is
required, and then linking to installation instructions provided by the library's authors.)
- A list of instructions to future developers on what they need to change to get the app
ready for deployment. This may include brief descriptions of incomplete features, or the
required attributes of a server, and anything else you think will show mercy to the
people who handle your code in the future.
license.txt. This file should contain a license of your choosing.
I strongly urge you to use the MIT License,
which will enable your clients to push your projects forward to deployment without your involvement.
But you can check here for more options.
Email to client. This email, sent by the due date and copied to Jeff, should include:
- Appropriate expressions of gratitude.
- A reminder of where the code lives (on bitbucket, github, or wherever) and how to get it.
If you're planning to delete the repository any time soon, you might provide them a zipped copy of
the repository.
- Either some notes on how you think they ought to proceed to get from here to deployment, or better,
a pointer to your detailed notes on that subject in the readme.
- The readme file from your repository as an attachment.
Project feedback. Each person should send an email to Jeff with subject
"team feedback", answering the following questions.
- For each member of your team (including yourself), give a brief description
of what they contributed to the project. You may copy this from your earlier peer evaluation
if it's still valid.
- Assume that the default grade for "contribution to the team" would go to any person
who did a fair share of the work in design, implementation, status reports, and client interactions.
For each member of the team (including yourself), please say whether you think they should get a
contribution grade of Default, ++Default, --Default, or something else. For non-Default grade
recommendations, include a brief explanation of why.
- Of what aspect of your project are you most proud?
- What should I change or keep the same next time I teach the course?
Rubric
I will grade the project using this rubric.
Correctness
1 -- Major features don't work properly.
2 -- Main features work, but significant bugs in the app as a whole.
3 -- Only minor bugs found.
4 -- All documented features work properly based on moderate testing. (This score is available only if the feature scope receives a score of at least 3. Otherwise, the highest score in this category is 3.)
Feature scope
1 -- Minimal implemented features.
2 -- Navigation is pretty much complete, and a couple major features are working.
3 -- Most of the app's essential functionality is in place, but possibly missing some important features.
4 -- Ambitious goals set and achieved.
Design and Usability
1 -- Features can be used, but navigation difficulties, ugly presentation, etc. make it a difficult or unpleasant experience.
2 -- There are some barriers to smooth use, but getting the app to do its thing is straight-forward if uninspiring.
3 -- An easy-to-learn experience that does not interfere with a person's experience of the app's functionality. In an app like this, you can forget about the mechanics of the app and focus on the app's content.
4 -- Unusually natural interactions and high-quality visual design make the app a genuine pleasure to use and to look at.
Code construction
1 -- Poor organization, naming, style, etc. Programs in this category typically have minimal modularity and are quite hard to extend.
2 -- Some attention to modularity / separation of concerns, but many stylistic and organizational problems. Programs in this category usually have a couple functions that do several jobs apiece, a large amount of straight-line code, lots of hard-coded data, and poor name choices, and are normally difficult to read and understand.
3 -- Mostly good modularity (with functions and/or classes well suited to the project), attention to descriptive naming, etc. Programs in this category can usually benefit from a rethinking of the storage of key data types or a reorganization of the flow of control, but they are also quite easy to understand and reasonably easy to extend.
4 -- Excellent organization and naming, clean separation of key data types into suitable classes (or well-used language features), very clear opportunities for extension to new features.
Documentation
1 -- Minimal or no comments describing functions and methods; inattention to top-of-source-file boiler plate (author names and brief description); readme absent or incomplete.
2 -- Some attempt to provide comments and required documentation, but poorly written or missing significant portions.
3 -- Documents and comments provide clear guidance to programmers who need to repair or modify your code.
4 -- Documents and comments provide an unusual level of clarity for programmer/readers.
Intermediate assignments (mockups, UML + status report, code reviews, etc.)
1 -- Did some, didn't do others
2 -- Did the work, but pretty lackluster
3 -- Solid
4 -- Great
Interaction with clients and team
1 -- Minimal or ineffective interaction, poor attendance, etc.
2 -- Showed up and participated, mostly.
3 -- Good attendance, positive interactions, good contributions to conversations, fair share of contribution to the project itself.
4 -- Unusually strong leadership in working with clients to develop a high-quality plan, and in creating the project itself.
Presentation
1 -- Sloppy or unclear
2 -- Basic elements of the expected presentation included, but not much to get excited about
3 -- Good motivation, clear explanation of key features, nicely presented demo
4 -- Like #3, but extra-awesome
Project feedback
2 -- Did it, but didn't answer all the questions.
4 -- Did it fully. (Thanks!)
Total score:
3 * correctness
+ 2 * scope
+ 4 * design and usability
+ 4 * construction
+ 2 * documentation
+ 3 * intermediate assignments
+ 5 * client and team interaction
+ 1 * in-class presentation
+ 1 * project feedback
(max score = 24 * 4 = 96)
Rough gradelines:
81-96: A-, A
60-80: B-, B, B+
48-59: C-, C, C+