Each major project (not including project 0) will have three phases.
- Specification - approximately 30%
- Prototype - approximately 30%
- Implementation - approximately 40%
Each phase will be given approximately one week of time and will be checked off by your T.A.'s. See the grade sheet for numerical details. You will be graded at each phase on roughly the same metrics.
- Correctness
- Does your specification describe a program that will have all of the necessary features? Will your design operate correctly, even on malformed or unusual inputs? The same questions apply to your implementation for the prototype and final deadlines.
- Completeness
- Did you do everything required of you by the project assignment? Do your unit tests exercise all the different features of your program? Do you have a reasonable implementation plan, for how you will incrementally finish your project?
- Efficiency
- Does your program run efficiently in both time and space? Does your program scale to handle larger volumes of input than you might have normally expected?
- Elegance
- Did you partition your program into meaningful modules that might be reusable in future projects? Did you use abstractions (object-oriented or otherwise) in a fashion that is well-suited to the problem at hand, helping you avoid the need for substantially similar code repeated in multiple places? Can your program be easily extended to support requirements beyond the original assignment? Where critical data structures and algorithms are used, are they easily replaced with other data structures and/or algorithms if, for example, performance became a concern?
- Clarity
- Can a reader look at your javadoc or your interfaces and quickly understand how they fit together? Did you use consistent class and variable naming? Do you have helpful comments to explain how complex portions of the code operate?
- Specification
- Is your implementation consistent with your specification? Did you update the spec to stay consistent with your implementation? Does your spec provide enough detail that another Comp314 student could reimplement your project without having any significant unanswered questions?
Mechanics of submissions
You and your partner will be assigned two staff members as your project mentor/liaisons. Your liaisons will look for the files that you submit via the turnin script. However, since that script occasionally has problems, you should also leave separate copies of your files in your owlnet directory with descriptive names (e.g., /home/student/comp314/proj1/final/...).
Documentation
The README has several purposes:
- Information on how to compile/install the program.
- What files or links contain the user documentation and the code-architecture information.
- Any applicable late-penalty calculation.
- Any other information to communicate with the labby. E.g., "Everything but feature ZZZ is implemented, and someFile.java isn't really late, I just cleaned up the javadoc."
- Don't just say "This program doesn't work"; please give information like "This program doesn't compile", or "This program compiles but crashes on input ZZZ", or "This program produces incorrect output for test cases involving ZZZ".
Late Policy
The late policy, as determined by the timestamps when you turnin your code, is:
- If less than 3hrs late, then -2pts for each hour late, up to 3hrs.
- If more than 3hrs late, then -10pts for each day late, up to 4days.
This has the following technicalities:
- In your README, note how late your assignment is, and what the published deduction is (-1 if labbies have to re-calc this).
- Except for a 2 minute grace period, timestamps will be strictly interpreted.
- Of course, fractional hours/days are rounded up.
- The count of hours/days late includes weekends.
- Documentation should be an on going process as you code, therefore, documentation is due at the same time as the project.
Finally, if you discover small bugs later, which don't warrant re-submitting, send them to your liaisons, and if they're nice they won't invoke the late penalty. This leniency is meant for shallow one-line bugs like "I just found why my boldface doesn't turn off: my code was looking for close-italics, oops". It is not for things like "After a day of looking, I realize that adding the following method will prevent those crashes on reading the first input."