Overview: Conceptualize product and document it as a user guide(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: [
A. Process:
Evaluates: How well you did in project management related aspects of the project, as an individual and as a team
Based on: Supervisor 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 this aspect, achieve recommended weekly progress in at least 6/10 weeks.
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)
B. Team-based tasks:
Evaluates: How much you contributed to common team-based tasks
Based on: peer evaluations and tutor observations
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
-
Developer Guide: Have a draft of the requirements of your project, as described in mid-v1.0 progress guide.
-
User Guide:
Draft a user guide in a convenient format (e.g., a GoogleDoc) to describe what the product would be like when it is at 2.0. We recommend that you follow the existingAB4 User Guide in terms of structure and format.💡 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 a single pdf file, name it {Your Team ID}.pdf e.g., W09-3.pdf and upload to IVLE.
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). Ideally, each increment should deliver a end-user testable enhancement.
- Document the above two items somewhere e.g., in a Google doc/sheet
Submission: Include in the pdf file you upload to IVLE.