tP week 7: Do a practice iteration → v1.1

• Tasks 2, 3, and 4 (given in subsequent sections) are the documentation updates to be done in this iteration.
• Don't forget to 'wrap up' the milestone (as explained in the panel above), after the work is done.

A: Update the following pages in your project repo:

• AboutUs page: This page (in the /docs folder) is used for course admin purposes. Please follow the format closely or else our scripts will not be able to give credit for your work.
  • Add your own details. Include a suitable photo as described here.
  • There is no need to mention the tutor/lecturer, but OK to do so too.
  • The filename of the profile photo should be docs/images/github_username_in_lower_case.png
    Note the need for lower case () e.g. JohnDoe123 -> docs/images/johndoe123.png not docs/images/JohnDoe123.png.
    If your photo is in jpg format, name the file as .png anyway.
  • Indicate the different roles played and responsibilities held by each team member. You can reassign these roles and responsibilities (as explained in Admin Project Scope) later in the project, if necessary.

• README page: Update it to match your project.

  • Add a UI mockup of your intended final product. Note that the image of the UI should be docs/images/Ui.png so that it can be downloaded by our scripts. Limit the file to contain one screenshot/mockup only and ensure the new image is roughly the same height x width proportions as the original one. Reason: when we compile these images from all teams into one page (example), yours should not look out of place.
    The UI mock up can be a hand-drawn sketch or created using a tool such as PowerPoint, PlantUML, Figma, etc.
    Can the AB3 screenshot used for this? Only in the unlikely case that your v1.2 UI looks exactly the same as AB3.

  • Update all contents to match your own project.

  • Update the link of the GitHub Actions build status badge () so that it reflects the build status of your team repo.

  • Acknowledge the original source of the code e.g.,
    This project is based on the AddressBook-Level3 project created by the [SE-EDU initiative](https://se-education.org).

B: Also update site-wide settings, as necessary:

• You need to update the AB-3 in the top navigation bar of your project website (it's in docs\_config.yml and docs/_sass/minima/_base.scss if using Jekyll; in docs\_markbind\layouts\default.md if using MarkBind).
  

• More info on updating site-wide settings such as the above:

  • If using Jekyll: follow the Jekyll Guide @SE-EDU/guides.
    
  • If using MarkBind: follow the MarkBind Guide @SE-EDU/guides.
    

• Update the UG in your tP repo. While you can reuse some content from the feature specification that you did earlier, note that UG is intended for end users, and hence the format, level of details, pitching etc. need to match that audience. For example, the UG should not contain all the nitty-gritty details that is in the feature spec.

• You can use the current AB3 UG for guidance on the format/flow/tone/level-of-details etc.

• As mentioned before, while it is more convenient for one person to update the entire UG, we strongly recommend that each person updates their own part of the docs so that we can easily track the contribution of each member using RepoSense.

• The scope of this update can be v1.2 i.e., only update features that you plan to have in that version.
  Furthermore, as you haven't implemented v1.2 yet, this update will be somewhat speculative. The content may need to be tweaked later if the actual implementation of the feature deviated from the current plan.

• Add the following to the DG, based on your project notes from the previous weeks. No need to update other sections, for now.
  Some examples of these can be found in the AB3 Developer Guide.

  • Target user profile, value proposition, and user stories: Update the target user profile and value proposition to match the project direction you have selected. Give a list of the user stories (and update/delete existing ones, if applicable), including priorities. This can include user stories considered but will not be included in the final product.
  • Use cases: Give use cases (textual form) for a few representative user stories that need multiple steps to complete. e.g. Adding a tag to a person (assume the user needs to find the person first)
  • Non-functional requirements: Note: Many of the given project constraints can be considered NFRs. You can add more. e.g. performance requirements, usability requirements, scalability requirements, etc.
  • Glossary: Define terms that are worth recording.

• Plan the next iteration. As you know, you should follow the breadth-first iterative process. Therefore, first you must decide what functionalities should be in the product if you had only two weeks to implement it. You have done that already when you chose user stories for v1.2, translated that to features, and even drafted the UG based on those features. You can tweak that plan further at this point if you wish, given that you now have some idea of how fast the team can work when using the prescribed workflow.
  • Aim to produce a working MVP at the end of this iteration even if the functionalities are not polished (polishing can be done in a later iteration).
  • Avoid depth-first implementations: "I'll do the back-end part of feature X in this iteration" is not acceptable as that is not in the spirit of breadth-first iterative process. Remember, we are pretending this to be the last iteration; why would you implement the back-end part of a feature in the last iteration?
    It is OK to add simpler versions of bigger features, but not OK to add partial features that can't be used yet.
  • [Recommended, Optional] Break the iteration into two mini iterations as follows:

• Divide the work among the team members i.e., the work required for the current iteration.
• Reflect the above plan in the issue tracker by assigning the corresponding issues (create new issues if necessary) to yourself and to the corresponding milestone. For example, the user story pertaining to the increment show a placeholder for photo, showing a generic default image should be assigned to Jake and to milestone v1.2

• If you have time, start implementing v1.2.