Week 8 [Mon, Oct 7th] - Project

1. Wait for the email notifying you which iPs are allocated for you to evaluate. When the email is sent out, it will also be announced via course announcements.

2. Download the latest JAR file of the first iP by following the link provided.

   FAQ: What if the student has not uploaded a JAR file, or the JAR file doesn't work at all?
   A: When you submit the evaluation (step 8 below), there will be a way to indicate that the JAR was not available, or any other serious issues you faced.

3. Locate the User Guide of the app by following the link provided in that email.

4. Open the Canvas survey (the one named iP Peer Evaluation 1) that you will be using to submit your evaluation and take note of the things you need to evaluate.

5. Run the jar file in the following manner:

   • 5.1
     Put the jar file in an empty folder, to prevent data files created by other jar files you tested earlier from interfering with the current jar file.
   • 5.2
     Open a terminal, and navigate to the folder you put the JAR file in.
   • 5.3
     Run the java -version command to confirm you are using Java 17.
     Mac user, confirm you are using the exact Java distribution we have prescribed here.
   • 5.4
     Run the jar file using the java -jar {file_name} command (rather than double-clicking) in the same terminal.

6. Do a light testing of the app (not more than 10 minutes) to ensure the claimed features actually exist.
   

7. Do a quick examination of the code (~ 5 minutes) by following the provided link.

8. Submit your evaluation using the survey.

9. Repeat the above steps for the 2nd iP allocated to you (use the survey iP Peer Evaluation 2).
   If both iPs crash or fail severely in a similar fashion, the problem may be on your side. Please contact the teaching team to ask how to proceed.

10. Take note of the effort required for a typical iP: After seeing two more iPs, you should now be in a better position to estimate how much you need to do for the tP (reason: the expected implementation effort for the tP is estimated with reference to the implementation effort required for a typical iP).

• Re-confirm MVP feature design. Recall that you decided on features to include in the MVP version of the product. Revisit that design. Ensure the following (you may refine the MVP feature design if necessary).
  • It consists of not only
    the most essential features of the target product, but also,
    the simplest implementation of those features (e.g., when adding a new feature to track birthdays of contacts, the simplest implementation of it could be simply adding a new text field for the contact).
  • It will still be a working product (i.e., it can be used)
    Reason: As we are following the breadth-first iterative approach, each intermediate version should be a working product.
• Divide the features among the team members i.e., who will be implementing which feature.
  • Reminder: We recommend that the work to be divided primarily based on features/enhancements rather than components.

• If you wish to rename AB3 packages/classes to fit your product, this is the best time to do so (i.e., before starting any functionality changes), as such changes cause widespread changes to the codebase, causing many merge conflicts with any other ongoing PRs.
• Renaming packages/classes is optional. It is fine to keep the existing ones. But if you decide to rename them, do it quickly, and remember to follow the workflow you practiced in the previous week.

Steps:

• S1.
  Select a code change to implement, as follows:

  • Consider the feature that you have been assigned to implement for the upcoming MVP version of the product (which will be released by the iteration v1.3, not by the current iteration v1.2).
  • Pick a small code change that you'll need to do to implement that feature. This is a small code change contributing towards the feature, not the entire feature itself. Examples: add parser support for a new command word, add a field to the person class.
• S2.
  Implement that code change while following the workflow that you practiced in the previous week. A summary of the steps:

  • Create an issue for it. Assign it to yourself. Assign it to milestone v1.2.
  • Create a PR from a separate branch in your fork. Assign it to v1.2.
  • Get the PR reviewed.
  • Get the PR merged. Close the corresponding issue.
• S3.
  Continue to implement more code changes (i.e., repeat S1 and S2) to implement more code changes that move you towards your MVP feature(s). You can even create parallel PRs, when implementing code changes with no/low dependency between them.
• S4.
  Wrap up the milestone When the iteration period is over, do the following:

  • Move any pending issues/PRs to the next milestone (i.e., v1.3). As we did not plan to release a product version at the end of this iteration, we can freely move any pending work to the next iteration.
  • Close the milestone.