Conceptualize product and document it as a user guide (UG)(draft), draft a rough project plan.
v1.0 Summary of Milestone
Here is a summary of items you need to deliver to reach v1.0 individual () and team () milestones. See sections below for more details of each item.
| Milestone | Minimum acceptable performance to consider as 'reached' |
|---|---|
| requirements documented | a draft of v2.0 requirements in some form |
| [optional] product survey documented | none |
| v2.0 conceptualized | a draft of v2.0 user guide in some form |
| feature releases planned | a rough feature release plan |
Reaching individual and team milestones are considered for grading the project management component of your project grade (expand the panel below for more info).
The deadline for reaching a milestone is the midnight before your tutorial e.g., if your tutorial is on Wednesday, you need to reach the milestone by Tuesday midnight.
Relevant: [
5A. Process:
Evaluates: How well you did in project management related aspects of the project, as an individual and as a team
Based on: tutor/bot observations of project milestones and GitHub data
Milestones need to be reached the midnight before of the tutorial for it to be counted as achieved. To get a good grade for this aspect, achieve at least 60% of the recommended milestone progress.
Other criteria:
- Good use of GitHub milestones
- Good use of GitHub release mechanism
- Good version control, based on the repo
- Reasonable attempt to use the forking workflow
- Good task definition, assignment and tracking, based on the issue tracker
- Good use of buffers (opposite: everything at the last minute)
- Project done iteratively and incrementally (opposite: doing most of the work in one big burst)
5B. Team-tasks:
Evaluates: How much you contributed to team-tasks
Based on: peer evaluations, tutor observations
To earn full marks, you should have done a fair share of the team tasks. You can earn bonus marks by doing more than your fair share.
Relevant: [
Here is a non-exhaustive list of team-tasks:
- Necessary general code enhancements e.g.,
- Work related to renaming the product
- Work related to changing the product icon
- Morphing the product into a different product
- Setting up the GitHub, Travis, AppVeyor, etc.
- Maintaining the issue tracker
- Release management
- Updating user/developer docs that are not specific to a feature e.g. documenting the target user profile
- Incorporating more useful tools/libraries/frameworks into the product or the project workflow (e.g. automate more aspects of the project workflow using a GitHub plugin)
v1.0 Documentation
-
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. Only one PDF per team should be uploaded.
v1.0 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.