tP:
How much is enough to get full marks? Not surprisingly, a common question tutors receive around this time of the project is "can you look at our project and tell us if we have done enough to get full marks?". Here's the answer to that question:
The tP effort is graded primarily based on peer judgements (tutor judgements are used too). That means you will be judging the effort of another team later, which also means you should be able to make a similar judgement for your own project now. Granted effort estimating is hard for software projects, but it is an essential SE skill, and we must practice it when we can.
The expected minimum bar to get full marks for effort:
If you surpass the above bars (in your own estimation), you should be in a good position to receive full marks for the effort. But keep in mind that there are many other components in the tP grading, not just the effort.
This iteration is your last chance to add features as a feature-freeze will be enforced in the next iteration (i.e., v1.4). That iteration (which is shorter than usual) is reserved for bug fixing and documentation work only. Any non-compliance with that restriction will be penalized. In other words, in terms of product design, treat this iteration as creating the final version of the product.
The version you deliver in this iteration (i.e., v1.3) will be subjected a peer testing (aka PE Dry Run) and you will be informed of the bugs they find (no penalty for those bugs). The same peer testers will be asked to check if you have changed features during the v1.4 later.
Given that you'll have to make important feature decisions in this iteration, it may be useful to know what kind of feature flaws that can cost you marks (you will not be allowed to fix feature flaws while a feature-freeze is in force). The panel below contains some excerpts from the guidelines your peers will use to determine feature flaws of your product after the final submission.
The panel below gives some details on the feature-freeze that will be imposed in v1.4, to prepare you in advance:
As you did in the previous iteration,
v1.3
and v1.3b
.In addition,
Improve upon AB3, design, code, test etc. While not very 'buggy', AB3 is not 'perfect' either (it is not meant to be a 'model solution'). Feel free to improve it in any way you see fit. In particular, find and fix any bugs it has. If you are not sure if something is a bug or an intended behavior, you can post in the forum to check.
While we are on the topic, also note that the architecture of AB3 doesn't suite every kind of application either. As you gain more experience in other application domains, you will learn different types of architectures that you can add to the collection of different architectures that you can consider for future projects. The same goes for the tool chain and the tech stack of AB3. Therefore, do not be tempted to apply AB3 as a template for every other application you come across in the future.
This task is time-sensitive. If done later than the deadline, it will not be counted as 'done' (i.e., no grace period). Reason: This is 'an early draft'; if done late, it is the 'final version' already.
You are discouraged from moving sections currently in DeveloperGuide.md
to additional markdown files. Reasons: 1. You need to submit the DG as a single PDF file at the end of the semester. 2. When checking DG-related tP increments, we only check your contributions to that file.
A similar requirement applies to the UserGuide.md
too.
3
participation points. Please do it before the weekly deadline.Some background: As you know, our includes peer-testing tP products under exam conditions. In the past, we used GitHub as the platform for that -- which was not optimal (e.g., it was hard to ensure the compulsory labels have been applied). As a remedy, some ex-students have been developing an app called that we'll be using for the PE this semester.
This week, we would like you to smoke-test the CATcher app to ensure it can work with your OS, Browser, GitHub account, by following the steps given in the panel below.
This task is time-sensitive. If done later than the deadline, it will not be counted as 'done' (i.e., no grace period). Reason: This is 'an early draft'; if done late, it is the 'final version' already.
v1.2.1
(or v1.3.trial
). Ensure that the jar file works as expected in an empty folder and using Java 11, by doing some manual testing. Reason: You are required to do a proper product release for v1.3. Doing a trial at this point will help you iron out any problems in advance. It may take additional effort to get the jar working especially if you use third party libraries or additional assets such as images.