tP:
In the final iteration (i.e., the one after this), you will be doing a lot of additional things e.g., adding documentation. Hence, it is in your interest to finish implementing all your features you want to include in your final version (i.e., v3.0)final features in this iteration itself so that you can use the final iteration for polishing up the functionalities and adding documentation.
As you did in the previous iteration,
v2.0 and v2.0b.In addition,
Recommended: Divide i.e., work related to the User Guide and the Developer Guidedocumentation work among team members equally; preferably based on enhancements/features each person would be adding e.g., If you are the person planing to add a feature X, you should be the person to describe the feature X in the User Guide and in the Developer Guide.
Reason: In the final project evaluation your documentation skills will be graded based on sections of the User/Developer Guide you have written.
Add the following to the DG, based on your project notes from the previous weeks.
Some examples of these can be found in the AB3 Developer Guide.
The above DG sections should cover the full requirements of the product, some of which might not get implemented by the end of this semester. Furthermore, these sections will be graded at the final project evaluation, and any bugs in the content can cost you marks at that point. The panel below gives some relevant DG bug examples you can lookout for:
Ensure your code is i.e., RepoSense can detect your code as yoursRepoSense-compatible and the code it attributes to you is indeed the code written by you, as explained below:
</> icon against your name and verify that the lines attributed to you (i.e., lines marked as green) reflects your code contribution correctly. This is important because some aspects of your project grade (e.g., code quality) will be graded based on those lines.