Requirements
Flexible design. Demonstrate flexibility by:
Implementing at least two different versions for one or a set of features. The variation needs to be behavioural, not parametric. For example, writing a game where the user drives a car and the bitmap image of the car can be changed, or changing the probability of an event happening, will not be considered a variation that fulfills this requirement.
Showing that adding versions to the set of features is achieved by adding new code rather than by modifying existing code.
Reliable code. Demonstrate reliability by:
Arguing that a significant set of features have corresponding test cases.
You demo a relatively stable version of your project and no errors occur during the demo.
You have an effective resource management policy. For example, you can use “valgrind” to check and show evidence of the effectiveness of your memory management scheme, or you can use smart pointers, if applicable.
Reasonable scope. Show that your project is not trivial:
Describe the features of your project by describing use case stories (an example is in your textbook), or listing the features that you implemented (you can include your test lists annotated with explanations so that the test list makes sense to an outside reader).
Provide code statistics. Tools for this purpose exist. For example, you can look at: CCCC (C and C++ Code Counter, http://sourceforge.net/projects/cccc/ ).
Implementation:
Source code commented using doxygen.
Source code naming and formatting conventions are consistent.
Building from sources is clearly explained and appropriately managed.
Use of a version control system is absolutely necessary. Show evidence that every team member has contributed code to the project. Bitbucket, for example, has the ability to show the users who have pushed commits to the remote repository. Every member should have at least one commit used in the project.
FINAL PROJECT REPORT (grading scheme)
Provide evidence that you fulfill each of the four requirements above (10% allocated for each requirement, total 40%). Please note that claims of the type “our implementation used shared_ptr classes” or “we have written a lot of code” are only claims. They need to be followed by evidence such as reference to the source code or doxygen documentation, or code statistics. Your report need not fill many pages, but it should be to the point. Please avoid double space lines and verbose formulations.