Project: final version
The goal for this assignment is to bring your application into whatever form you want it to have for the end of the term.
What to do
This list is very similar to the list from the alpha assignment, with "update your tests" added.
If you did a good job on your documentation before, you'll probably be able to just tweak your documents a little or leave them as-is for the final version. The main changes will be features and UI.
- Get your application working and looking good.
- Do what you can via in-app documentation or UI conventions or whatever to make your app's features discoverable. Discoverability means something different for a game or a web app or a command-line app, of course. Do what's natural, conventional, and appropriate to your application.
- If there are missing or broken features, make sure they don't disrupt the functioning of the rest of the application.
- Update your unit tests (and any other kinds of tests you might have)
- Update your coding and running instructions in
doc/development.mdanddoc/running.md. If relevant, please make sure these instructions include guidance on how to deal with your database. I want to be able to launch and test your project as simply as possible. In a
README.mdat the top of your repository, include:- Title of your project
- Short description of your project (you may copy this from other docs I've asked for before)
- Short list of existing features
- Short list of features you didn't complete during the term, for whatever reason
- Credits. If you adapted somebody else's code, got something from an LLM, used automatically generated templates from some dev tool, etc., cite those sources here.
- Anything else you want to add to the readme file
- Tag your repo
final. - Push everything (including the tag).
What am I looking for?
I'll be looking at:
- Correctness. Does your program work as intended? Can I crash it? Does its behavior and data make sense? etc.
- User experience. Is it a pleasure to use? Can I figure out how to use it, and once I know how to use it, is it easy and natural to achieve my goals?
- Code construction. How are the names? Is the code modularized well into functions/classes/files/components, each of which is internally coherent and whose inputs and outputs are well defined and appropriate to the task? Do you adhere to the conventions of the languages and frameworks you're using? Would it be straight-forward to add a feature or find and fix a bug?
- Documentation. Are your file-level and function-level comments appropriate and do they add value that couldn't be quickly gained just by looking at the code? Are your project-level documents helpful to other developers or users (depending on what each documet is for)? Is the writing clear?
- Tests. How easy is it for a developer to run the tests? How thoroughly do your automated tests probe the common operations and the weirder boundaries of your code? If there are tests you would want to run but you couldn't figure out a way to automate them, have you provided a clear script for what manual tests you would want someone to perform before each version release?
- Packaging. Is the project easily deployable by a knowledgeable developer? Can it be installed on a user's computer or phone or a Linux server in such a way that the user doesn't have to do anything other than launch the app or a browser? (In other words, can the user use your application without themselves launching developer tools like Docker or VS Code or Godot?)
- Scope. How ambitious is this project? Does it have at least the features one would expect from a "minimum viable version" of your product? Does it have extra features, extra pizzazz and polish, more than just the minimum?
Your course grade
When I grade a course, I generally use two approaches in succession.
Approach #1: use numbers. This is a traditional approach, and for this course will involve:
- Make the final project submission worth 60 points, which is roughly 50% of the total points for the term. This, I think, is consistent with the idea that most of your work during the term has focused on the planning and execution of the final product, so even if there were stumbles along the way, I want to reward you for where you end up.
- Use a scale like 95% = A, 92% = A-, 86% = B+, 80% = B, etc.
Approach #2: intuitive sanity check. Once I have assigned grades based on Approach #1, I look them over for each student to see whether the numbers agree with my intuitive assessment of the student's progress and achievements. Almost always the answer is yes, but occasionally I will adjust a grade upward a notch if the numbers aren't capturing reality effectively.
Mostly, though, I'm just really excited to see your projects come together. Can't wait to see the final versions.