- Do a postmortem of the previous iteration
- Adjust process rigor if necessary
- Start the next iteration
- Update the DG with design details
- Smoke-test CATcher COMPULSORY
- Do a trial JAR release
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:
- For the team: an effort equivalent to the effort required to develop AB3 from scratch
- For an individual: an effort equivalent to the effort the iP required
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.
1 Do a postmortem of the previous iteration
- Discuss with the team how the iteration went (i.e., what worked well, what didn't), and your plans to improve the process (not the product) in the next iteration.
- Keep notes about the discussion in your project notes document so that the tutor can check them.
2 Adjust process rigor if necessary
- Adjust process rigor, as explained in the panel below:
3 Start the next iteration
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,
- Plan the next iteration (steps are given below as a reminder):
- Decide which enhancements will be added to the product in this iteration, assuming this is the last iteration.
- If possible, split that into two incremental versions
v1.3
andv1.3b
. - Divide the work among team members.
- Reflect the above plan in the issue tracker.
- Start implementing the features as per the plan made above.
- Track the progress using GitHub issue tracker, milestones, labels, etc.
In addition,
- Maintain the defensiveness of the code: Remember to use assertions, exceptions, and logging in your code, as well as other defensive programming measures when appropriate.
Remember to enable assertions in your IDEA run configurations and in the gradle file. - Recommend: Each PR should also update the relevant parts of documentation and tests. That way, your documentation/testing work will not pile up towards the end.
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.
4 Update the DG with design details
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.
- Update the Developer Guide as follows:
- Each member should describe the implementation of at least one enhancement she has added (or planning to add).
Expected length: 1+ page per person - The description can contain things such as,
- How the feature is implemented (or is going to be implemented).
- Why it is implemented that way.
- Alternatives considered.
- Each member should describe the implementation of at least one enhancement she has added (or planning to add).
5 Smoke-test CATcher COMPULSORY
- This activity is compulsory and counts for
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.
6 Do a trial JAR release
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.
- Do a as described in the Developer Guide. You can name it something like
v1.2.1
(orv1.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. - If you want to smoke-test your JAR file on an OS that is not available within your team, you can post a request in the forum to see if anyone else in the class can help you smoke-test it on that OS.