project expectations
Project phases
The project will run in two phases.
- In Phase 1, you will be working individually to develop the foundation of your codebase
- This will give you an opportunity to familiarize with Java programming
- In Phase 2, as a team, you will enhance the project, building on the codebase of Phase 1
The project consists of the following increments:
- Levels: A series of features, meant to be added to Duke in the given order, although some can be skipped. These have been named
Level 1toLevel 10to indicate how the features make the product progressively "level up". - Extensions:
- Category A These are internal/feature enhancements meant to help you practice a specific Java or an SE technique.
- Category B These are enhancements related to task tracking.
- Category C These are enhancements, not specifically related to task tracking.
- Category D Each of these adds the ability to track another type of entities.
Phase 1
Phase 1 comprises Levels 1 to 10 with some Category A and Category B extensions.
Phase 2
In Phase 2, each of you will develop one enhancement each from Category C and Category D.
However, you need to ensure that the overall product is cohesive in nature, which means, as a team, you need to decide on a few things before embarking on developing the enhancements.
The following sections may help you decide on the enhancements.
Project Direction
-
[Direction 1] Optimize the task manager for a more specific target user group:
After Phase 1 of the project, think about optimizing your project to suite a specific target user group when you implement Category C and Category D enhancements.
A task manager:
- for users in a specific profession e.g. doctors, salesmen, teachers, etc.
- based on the nature and scale of application e.g. huge number of tasks (user group admins), highly volatile task list, for users who organize group events etc.
-
[Direction 2] Morph the task manager into a different product:
Given that Duke provides capabilities to manage certain types of elements (i.e., tasks), you can use it as a starting point to create an app that manages something else in Phase 2. Model the Category C and Category D enhancements to cater to the new app that you want to develop.
An app to manage:
- Bookmarks of websites
- Thing to memorize i.e. flash cards, trivia
- Forum posts, news feeds, Social media feeds
- Online projects or issue trackers that the user is interested in
- Emails, possibly from different accounts
- Multiple types of related things e.g. Contacts and Tasks (if Tasks are allocated to Contacts)
This is a high-risk high-reward option because morphing requires extra work but a morphed product may earn more marks than an optimized product of similar complexity.
Target user profile and value proposition
For either direction, you need to define a target user profile and a value proposition:
-
Target user profile: Define a very specific target user profile.
💡 We require you to narrow down the target user profile as opposed to trying to make it as general as possible. Here is an example direction of narrowing down target user: anybody → teachers → university teachers → tech savvy university teachers → CS2113/T instructors.
Be careful not to contradict given project constraints when defining the user profile e.g. the target user should still prefer typing over mouse actions.
It is expected that your product will be optimized for the chosen target users i.e., add features that are especially/only applicable for target users (to make the app especially attractive to them). w.r.t. the example above, there can be features that are applicable to CS2113/T instructors only, such as the ability to navigate to a student's project on GitHub
💡 Your project will be graded based on how well the features match the target user profile and how well the features fit-together.- It is an opportunity to exercise your product design skills because optimizing the product to a very specific target user requires good product design skills.
- It minimizes the overlap between features of different teams which can cause plagiarism issues. Furthermore, higher the number of other teams having the same features, less impressive your work becomes especially if others have done a better job of implementing that feature.
- Value proposition: Define a clear value proposition (what problem does the product solve? how does it make the the user's life easier?) that matches the target user profile.
Individual Expectations
[Individual] Expectations on Features
- You are expected to add at least one feature each from Category C and Category D enhancements to the product.
- At lest one feature should be end-user visible and end-user testable. Reason: If your feature cannot be identified and tested by the testers, we will not be able to give marks for the quality assurance of that feature.
- The features should fit with the rest of the software (and the target user profile) and should have the consent of the team members. You will lose marks if you go 'rogue' and add features that don't fit with the product.
We strongly recommend that you contribute to multiple (preferably, all) aspects of the project e.g. write backend code, frontend code, test code, user documentation, and developer documentation. If you limit yourself to certain aspects only, you will lose marks allocated for the aspects you did not do.
In particular, you are required to divide work based on features rather than components:
- By the
end of this project each team member is expected to have implemented at least one feature end-to-end, doing required changes in almost all components. Reason: to encourage you to learn all components of the software, instead of limiting yourself to just one/few components. - Nevertheless, you are still expected to divide the components of the product among team members so that each team member is in charge of one or more components. While others will be modifying those components as necessary for the features they are implementing, your role as the in charge of a component is to guide others modifying that component (reason: you are supposed to be the most knowledgeable about that component) and protect that component from degrading e.g., you can review others' changes to your component and suggest possible changes.
Here are some examples from the past project (Enhancing an AddressBook application) of different enhancements and the grade the student is likely to earn for the relevant parts of the project grade.
While these examples do not necessarily translate directly to the current project, they should give you an idea of the depth of the feature and the effort required to implement it (including automated tests and documentation).
- Example 1 (Expected grade:
A) : Add support for undo/redo - Example 2 (Expected grade:
B) : Add support for viewing history
[Individual] Expectations on Lines of Code
- Based on past experience, it is possible for a feature consisting of ~300-500 LoC of functional code and ~200-400 LoC of test code to earn full marks provided the feature does well in all grading criteria.
- Note: The lines of code count mentioned above is counted after Phase 1 of the project
[Individual] Expectations on Documentation
- You are expected to write user documentation and developer documentation for your features.
- The objective is to showcase your ability to write the two types of documentation. If the documentation for your features is not enough to meet that objective, or does not reach the following minimal requirement, you can make up the shortfall by documenting 'proposed' features and alternative designs/implementations.
- Contribution to the user guide: 1 page
- Contribution to the developer guide: 3 pages
- You are expected to showcase your ability to use the various UML diagrams (at least 2 types). As mentioned in the previous point, if the documentation of your features doesn't give you enough opportunities to do so e.g., your features only required minor updates to existing diagrams, you are expected to create those opportunities yourself by documenting proposed features or alternative designs. Evaluators will not be able to give you marks unless there is sufficient evidence of your documentation skills.
[Individual] Expectations on Testing
- There is no requirement for a minimum coverage level. Note that in a production environment you are often required to have at least 90% of the code covered by tests. In this project, it can be less. The less coverage you have, the higher the risk of regression bugs, which will cost marks if not fixed before the final submission.
- You must write some tests so that we can evaluate your ability to write tests. (Please refer to Expectations on Lines of Code for LoC requirement).
- How much of each type of testing should you do? We expect you to decide. You learned different types of testing and what they try to achieve. Based on that, you should decide how much of each type is required. Similarly, you can decide to what extent you want to automate tests, depending on the benefits and the effort required.
[Individual] Expectations on Teamwork
-
Team-tasks are the tasks that someone in the team has to do. Marks allocated to team-tasks will be divided among team members based on how much each member contributed to those tasks.
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)
- Necessary general code enhancements e.g.,
[Individual] Roles and responsibilities
-
Roles indicate aspects you are in charge of and responsible for. E.g., if you are in charge of documentation, you are the person who should allocate which parts of the documentation is to be done by who, ensure the document is in right format, ensure consistency etc.
This is a non-exhaustive list; you may define additional roles.
- Team lead: Responsible for overall project coordination.
- Documentation (short for ‘in charge of documentation’): Responsible for the quality of various project documents.
- Testing: Ensures the testing of the project is done properly and on time.
- Code quality: Looks after code quality, ensures adherence to coding standards, etc.
- Deliverables and deadlines: Ensure project deliverables are done on time and in the right format.
- Integration: In charge of versioning of the code, maintaining the code repository, integrating various parts of the software to create a whole.
- Scheduling and tracking: In charge of defining, assigning, and tracking project tasks.
- [Tool ABC] expert: e.g. Intellij expert, Git expert, etc. Helps other team member with matters related to the specific tool.
- In charge of[Component XYZ]: e.g. In charge of
Model,UI,Storage, etc. If you are in charge of a component, you are expected to know that component well, and review changes done to that component in v1.3-v1.4.
Please make sure each of the important roles are assigned to one person in the team. It is OK to have a 'backup' for each role, but for each aspect there should be one person who is unequivocally the person responsible for it.
Team Expectations
- Preserve product integrity: i.e. ensure,
- features fit together to form a cohesive product,
- documentation follows a consistent style and presents a cohesive picture to the reader, and
- final project demo presents a cohesive picture to the audience.
- Maintain product quality: i.e. prevent breaking other parts of the product as it evolves. Note that bugs local to a specific feature will be counted against the author of that feature. However, if a new enhancement breaks the entire product, the whole team will have to share the penalty.
- Manage the project smoothly: i.e. ensure workflow, code maintenance, integration, releases, etc. are done smoothly.