project expectations
Functionality Expectations
The expected level of functionality is what you could achieve if each member puts in about 50% of the implementation effort they put into the iP (reason for setting it much less than 100%: even after adding the extra overhead of doing the project as a team and working with an existing codebase, we don't want the tP to take more effort than the iP). This is the primary measure we will use when grading your tP implementation effort.
Furthermore, we estimate that this bar is roughly equivalent to writing about 300-400 lines of functional code (excluding testing and documentation) per person. This is a secondary ballpark measure you can keep an eye on, alongside the primary measure mentioned above.
There are no extra marks for exceeding the implementation effort bar stated above. Hence, effort is graded mostly on an S/U basis -- it is the quality of the code that really determines the marks for the implementation component (more info here). Try to avoid adding more features than necessary, unless you are doing it out of interest; you are better off spending more effort on improving other aspects of the project instead. As mentioned elsewhere, a feature that is just the right size and of high quality will earn more marks than a feature that is bigger (or more difficult, or more interesting/novel) but of lower quality.
If you wish to add the following features to your app, we recommend (but do not require) that you use similar features in AB4 (not AB3) as models to reduce the effort required.
Team Expectations
- Expectation Produce a cohesive product: i.e., ensure:
- features fit together to form a cohesive product,
- documentation follows a consistent style and presents a cohesive picture to the reader
- Expectation Maintain product integrity/quality: i.e., prevent breaking other parts of the product as it evolves.
- Expectation Manage the project: i.e., ensure workflow, code maintenance, integration, releases, etc. are done properly.
Individual Expectations
Individual Expectations on Implementation
- Expectation Contribute to the functional code of the product.
- User-visible features are preferred, but not strictly required.
- The enhancement(s) should fit with the rest of the software (and the target user profile) and should have the consent of the team members. You will lose marks if you go 'rogue' and add things that don't fit with the product.
Recommended: Contribute to all aspects of the project. For example, write back-end code, front-end code, test code, user documentation, and developer documentation. Reason: If you limit yourself to certain aspects only, you could lose marks allocated for the aspects you did not do. In addition, the final exam assumes that you are familiar with all aspects of the project.
Recommended: Do all the work related to your enhancement yourself. Reason: If there is no clear division of who did which enhancement, it will be difficult to divide project credit (or assign responsibility for bugs detected by testers) later.
In other words, we recommend that the work be divided primarily based on features/enhancements rather than components. The latter has problems such as the following:
(a) Higher risk of a team member becoming a single point of failure e.g., what if the person assigned to an important component doesn't deliver on time?
(b) You become too reliant on other team members e.g., a feature can't be delivered until all members have done their part
(c) Hard to keep tests passing i.e., tests break when one component is updated but not the others
(d) Integration becomes harder/riskier i.e., moving from continuous integration (safer) toward big-bang integration (riskier)
(e) Not aligned with the breadth-first iterative approach i.e., evolving components separately moves you toward a depth-first iterative approach instead
- Recommended: Divide the components of the product among team members. Notwithstanding the above, we still recommend that each team member be in charge of one or more components. While others will be modifying those components to fit their features, your role as the person in charge of a component is to guide others who modify that component (reason: you are supposed to be the most knowledgeable about that component) and protect that component from degrading e.g., you can review others' changes to your component and suggest possible changes.
Individual Expectations on Documentation
- Objective: showcase your ability to write both user-facing and developer-facing documentation.
- Expectation Update the User Guide (UG) and the Developer Guide (DG) parts that are related to the enhancements you added.
- Optional: If the UG/DG updates for your enhancements are not enough to meet the above requirements, you can make up the shortfall by documenting 'proposed' features and alternative designs/implementations.
Individual Expectations on Testing
- Expectation Write some automated tests so that there is evidence that you can write automated tests.
🤔 How much testing is enough? We expect you to decide. As you learn different types of testing and what each type tries to achieve, you should decide how much of each type is worth having. Similarly, you can decide to what extent you want to automate tests, depending on the benefits and the effort required.
There is no minimum test coverage requirement. Note that in a high-end production environment you might be required to have high levels of test coverage (e.g., 90%). In this project, it can be less. Caveat: The weaker your tests are, the higher the risk of undetected bugs/regressions, which will cost you marks if not detected/fixed before the final submission.
Individual Expectations on Teamwork
- Expectation Do a non-trivial share of the team-tasks.
Team-tasks are the tasks that someone in the team has to do.
- Expectation Carry a non-trivial share of project roles and responsibilities.
Roles indicate aspects you are in charge of and responsible for. E.g., if you are in charge of documentation, you are the person who should decide which parts of the documentation are to be done by whom, ensure the document is in the right format, ensure consistency, etc.
Ensure each of the important roles is assigned to one person in the team. It is OK to have a 'backup' for each role, but for each aspect there should be one person who is unequivocally responsible for it. Reason: when everyone is responsible for everything, no one is.
- Expectation Review each other's work. Reason: developing review skills is a learning outcome, and it is mutually beneficial.