You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Draft a user guide in a convenient medium (e.g., a GoogleDoc) to describe what the product would be like when it is at v2.0.
We recommend that you follow the existing AB4 User Guide in terms of structure and format.
As this is a very rough draft and the final version will be in a different format altogether (i.e., in asciidoc format), don't waste time in formatting, copy editing etc. It is fine as long as the tutor can get a rough idea of the features from this draft. You can also do just the 'Features' section and omit the other parts.
Do try to come up with concrete command syntax for feature that you would implement (at least for those that you will implement by v1.4).
Consider including some UI mock-ups too (they can be hand-drawn or created using a tool such as PowerPoint or Balsamiq).
💡 It is highly recommended that you divide documentation work (in the User Guide and the Developer Guide) among team members based on enhancements/features each person would be adding e.g., If you are the person planing to add a feature X, you should be the person to describe the feature X in the User Guide and in the Developer Guide. For features that are not planned to be implemented by v1.4, you can divide them based on who will be implementing them if the project were to continue until v2.0 (hypothetically).
Reason: In the final project evaluation your documentation skills will be graded based on sections of the User/Developer Guide you have written.
Suggested length: Follow the existing user guide and developer guides in terms of the level of details.
Submission: Save your draft as a single pdf file, name it {Your Team ID}.pdf e.g., W09-3.pdf and upload to LumiNUS.
Project Management:
After the v2.0 is conceptualized, decide which features each member will do by v1.4.
We realize that it will be hard for you to estimate the effort required for each feature as you are not familiar with the code base. Nevertheless, come up with a project plan as per your best estimate; this plan can be revised at later stages. It is better to start with some plan rather than no plan at all. If in doubt, choose to do less than more; we don't expect you to deliver a lot of big features.
Divide each of those features into three increments, to be released at v1.1, v1.2, v1.3 (v1.4 omitted deliberately as a buffer). Each increment should deliver a end-user visible enhancement.
Document the above two items somewhere e.g., in a Google doc/sheet. An example is given below:
Jake Woo: Profile photo feature
v1.1: show a place holder for photo, showing a generic default image
v1.2: can specify photo location if it is in local hard disk,
show photo from local hard disk
v1.3: auto-copy the photo to app folder, support using online photo
as profile pic, stylize photo e.g., round frame
Submission: Include in the pdf file you upload to LumiNUS.
The text was updated successfully, but these errors were encountered:
Deliverables:
User Guide:
Draft a user guide in a convenient medium (e.g., a GoogleDoc) to describe what the product would be like when it is at v2.0.
We recommend that you follow the existing AB4 User Guide in terms of structure and format.
As this is a very rough draft and the final version will be in a different format altogether (i.e., in asciidoc format), don't waste time in formatting, copy editing etc. It is fine as long as the tutor can get a rough idea of the features from this draft. You can also do just the 'Features' section and omit the other parts.
Do try to come up with concrete command syntax for feature that you would implement (at least for those that you will implement by v1.4).
Consider including some UI mock-ups too (they can be hand-drawn or created using a tool such as PowerPoint or Balsamiq).
💡 It is highly recommended that you divide documentation work (in the User Guide and the Developer Guide) among team members based on enhancements/features each person would be adding e.g., If you are the person planing to add a feature X, you should be the person to describe the feature X in the User Guide and in the Developer Guide. For features that are not planned to be implemented by v1.4, you can divide them based on who will be implementing them if the project were to continue until v2.0 (hypothetically).
Reason: In the final project evaluation your documentation skills will be graded based on sections of the User/Developer Guide you have written.
Suggested length: Follow the existing user guide and developer guides in terms of the level of details.
Submission: Save your draft as a single pdf file, name it {Your Team ID}.pdf e.g., W09-3.pdf and upload to LumiNUS.
Project Management:
After the v2.0 is conceptualized, decide which features each member will do by v1.4.
We realize that it will be hard for you to estimate the effort required for each feature as you are not familiar with the code base. Nevertheless, come up with a project plan as per your best estimate; this plan can be revised at later stages. It is better to start with some plan rather than no plan at all. If in doubt, choose to do less than more; we don't expect you to deliver a lot of big features.
Divide each of those features into three increments, to be released at v1.1, v1.2, v1.3 (v1.4 omitted deliberately as a buffer). Each increment should deliver a end-user visible enhancement.
Document the above two items somewhere e.g., in a Google doc/sheet. An example is given below:
show photo from local hard disk
as profile pic, stylize photo e.g., round frame
Submission: Include in the pdf file you upload to LumiNUS.
The text was updated successfully, but these errors were encountered: