CS2113/T - Admin: tP (team project): Expectations

project expectations

Outcomes

The high-level learning outcome of the team project (tP):

Can contribute production quality SE work to a small/medium software project

Accordingly, the tP is structured to resemble an early stage of a small software project in which you will,

conceptualize and implement a product, and,
have it ready to be continued by future developers

The focus of the tP is to learn the following aspects:

~~coding~~
working in a team
process/workflow
documentation
scheduling and tracking project progress, meeting delivery deadline
quality assurance

Direction

You may develop any product provided it is meant for users who can type fast, and prefer typing over mouse/voice commands. Therefore, Command Line Interface (CLI) is the primary mode of input.

Constraint-Typing-Preferred

The product should be targeting users who can type fast and prefer typing over other means of input.
Reason: to increase comparability of products, and to make feature evaluation easier for peer evaluators.

Recommendation-CLI-First

Following from the Constraint-Typing-Preferred, if the app is optimized for the target user (graded under the product design criterion), a user who can type fast should be able to accomplish most tasks faster via CLI, compared to a hypothetical GUI-only version of the app. For example, adding a new entity via the CLI should be faster than entering the same data through a GUI form.
Therefore, the input to the app needs to be primarily CLI. If you do implement a GUI, that GUI should primarily be used to give visual feedback to the user. While we don't prohibit non-CLI inputs, note that such inputs will reduce the suitability of the product to target users. Therefore, give CLI alternatives to mouse/GUI inputs, if applicable.
Also keep in mind:

Regular typing is usually faster than using key combinations.
typing the full command and hitting ENTER will complete the taskOne-shot commands are faster over prompting the user to input one parameter at a timemulti-step commands. If you provide a multi-step command to help new users, you can also provide a one-shot equivalent for regular/expert users.

For example, an app to manage one of these:
- Contact details
- Bookmarks of websites
- Tasks/Schedule
- Location info
- 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)
- ...

You are strongly discouraged from developing a GUI application as it can increase the workload unnecessarily.

Recommendation-No-GUI

Creating a good Java GUI takes a lot of extra effort, which can easily push the tP effort beyond the expected range. In addition, good GUI design is not a learning outcome of this module. Therefore, you are strongly discouraged from creating a GUI application. Choose the GUI path only if you are willing to take the extra workload on top of the module's normal load.

Target User & Value Proposition

You are expected to:

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 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.

The size of the target market is not a grading criterion. You can make it as narrow as you want. Even a single user target market is fine as long as you can define that single user in a way others can understand (reason: project evaluators need to evaluate the project from the point of view of the target users).

Define a clear value proposition that matches the target user profile i.e., what problem does the product solve? how does it make the user's life easier?
You should also define the scope clearly i.e., boundary beyond which the app will not help e.g., the app will help to manage tasks within a single project only (no support for multiple projects).
Optimize the product to the chosen target users i.e., add features that are especially/only applicable for target users (to make the app especially attractive to them).
- Example 1: If the product targets CS2113/T instructors, there can be features that are applicable to them only, such as the ability to see a link to a student's project on GitHub
- Example 2: If your app manages contacts, you can optimize its features based on,
  - the profession of the target user e.g. doctors, salesmen, teachers, etc.
  - the nature/scale of contacts e.g. huge number of contacts (for HR admins, user group admins), mostly incomplete contacts, highly volatile contact details, contacts become inactive after a specific period (e.g. contract employees)
  - what users do with the contacts e.g. organize group events, share info, do business, do analytics
  Your project will be graded based on how well the features match the target user profile and how well the features fit-together.

Functionality Expectations

The expected level of functionality from a team is roughly what you can achieve if each member contributes about the same amount of functional code as required by a i.e., if all requirements were met at the minimal level specifiedtypical iP.

You will get full marks for implementation effort if you meet the expectation stated above. There are no extra marks for exceeding that bar. You are better off spending that effort in improving other aspects of the project.

One semester ago, we reduced the tP functionality expectations by about 40-50% compared to the previous semesters, in order to reduce your workload. Keep that in mind in case you receive advice about project from seniors who did this module more than one semester ago.

In fact, here is the grading criterion for the individual project effort:

Q [For each member] The functional code contributed by the person is,
Consider implementation work only (i.e., exclude testing, documentation, project management etc.)
The typical iP refers to an iP where all the requirements are met at the minimal expectations given.
Use the person's PPP and RepoSense page to evaluate the effort.

Unable to judge
Significantly less than a typical iP
Slightly less than a typical iP
At least as much as a typical iP

Team Expectations

Expectation Preserve product integrity i.e. ensure,
1. features fit together to form a cohesive product,
2. documentation follows a consistent style and presents a cohesive picture to the reader, and
3. final project demo presents a cohesive picture to the audience.
Expectation 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.
Expectation Manage the project i.e. ensure workflow, code maintenance, integration, releases, etc. are done smoothly.

Individual Expectations

Individual Expectations on Implementation

Expectation Contribute to the functional code of the product.
- User-visible features are preferred, but it is not a strict requirement.:
- The enhancement(s) 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 things that don't fit with the product.

Tip: Contribute to all aspects of the project e.g. write backend code, frontend code, test code, user documentation, and developer documentation. Reason: If you limit yourself to certain aspects only, you could lose marks allocated for the aspects you did not do. In addition, the final exam assumes that you are familiar with all aspects of the project.
Tip: Do all the work related to your enhancement yourself. Reason: If there is no clear division of who did which enhancement, it will be difficult to divide project credit (or assign responsibility for bugs detected by testers) later.

Individual Expectations on Documentation

Objective: showcase your ability to write both user-facing documentation and developer-facing documentation.
Expectation Update the User Guide (UG) and the Developer Guide (DG) parts that are related to the enhancements you added. The minimum requirement is given below. (Reason: Evaluators will not be able to give you marks unless there is sufficient evidence of your documentation skills.)
- UG: 1 or more pages
- DG: 3 or more pages
Tip: If the UG/DG updates for your enhancements are not enough to reach the above requirements, you can make up the shortfall by documenting 'proposed' features and alternative designs/implementations.
Expectation Use at least 2 types of UML diagrams in your DG updates i.e., diagrams you added yourself or those you modified significantly.

Individual Expectations on Testing

Expectation Write some automated tests so that we can evaluate your ability to write tests.

🤔 How much testings is enough? 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.
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 weaker your tests are, the higher the risk of bugs, which will cost marks if not fixed before the final submission.

Individual Expectations on Teamwork

Expectation Do an equal share of the team-tasks.

Team-tasks are the tasks that someone in the team has to do.

Here is a non-exhaustive list of team-tasks:

Setting up the GitHub team org/repo
Necessary general code enhancements
Setting up tools e.g., GitHub, Gradle
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)

Expectation Carry an equal share of project 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[Area XYZ] of the code: e.g. In charge of the code that deals with storage, etc. If you are in charge of an area, you are expected to know that area well, and review changes done to that code.

Ensure 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. Reason: when everyone is responsible for everything, no one is.

Expectation Review each others work. Reason: reviewing skills is a learning outcome, and it is mutually beneficial.