- 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 counted for participation
- Do a trial JAR release
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. You will not be allowed to add features in the following iteration (i.e., v1.4). That iteration (which is shorter than usual) is reserved for bug fixing and documentation work only.
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).
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
- 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 counted for participation
- This activity is compulsory and counts for
3
participation points. Please do it before the weekly deadline.
Some background: As you know, our i.e., Practical ExamPE 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 CAT stands for Crowd-sourced Anonymous TestingCATcher 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 run in your computer.
6 Do a trial JAR release
- Do a resulting in a jar file on GitHub that can be downloaded by potential usersproduct release 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.