CS2103/T - Admin: tP week 4: Set direction

Start weekly project meetings
Start a collaborative doc to take project notes before the tutorial
Decide on an overall project direction (user profile, problem addressed) before the tutorial

1 Start weekly project meetings

We recommend you start weekly project meetings now. You can use the meeting to do tP tasks, but also help each other do iP tasks. On a related note, it is also acceptable to discuss weekly post-lecture quiz (if any) together with team members as you do the quiz i.e., discuss and decide the answer collectively, but you should not give away your answers to someone who was not part of that discussion.

2 Start a collaborative doc to take project notes before the tutorial

Keep project notes in easy-to-use collaborative docs (Recommended: use a GoogleDoc). This document will be checked by the tutor at various points.
Remember to choose a tool that allow public view access (not write access) e.g., GoogleDoc can be shared via a public link so that the document can be viewed by others. You'll be asked to submit this link to us in the next week.
Make sure all you current and future project notes (if split into in multiple documents) are reachable via links given in this document and are viewable by the public.

3 Decide on an overall project direction (user profile, problem addressed) before the tutorial

Decide project direction, target user profile, and problem addressed: Use your first project meeting to discuss with your team members and decide your project direction, target user profile, and the value proposition of the product, as described in the panels below:

As we are still at the early stages of identifying a problem to solve, do not think of the product (i.e., the solution) yet. That is, do not discuss the product features, UI, command format, and implementation details, etc. unless they are pertinent to the decision of the project direction.

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 intermediate stage of a non-trivial real-life brownfield software project in which you will,

conceptualize and implement enhancements to a given 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

The tP uses a generic application called AddressBook-Level3 (AB3) (from https://se-education.org) as the starting point.

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. The GUI is used primarily 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.

Direction 1: Evolve AddressBook-Level3AB3 into a more powerful or more optimized contact management app.
- Some examples:
  - Manage more entity types related to contacts e.g. Tasks allocated to contacts
  - Contact managing optimized for a specific type of user e.g. a sales person managing client contacts

pros: less changes to existing code at the start of the project (i.e., progress will be smoother at the start), can result in a more mature product with deeper features as the product functionality will be moving forward from the start
cons: less flexibility in product design, less differentiation with other team's projects

Direction 2: Morph AB3 any direction you wish.
- For example, an app to manage one of these:
  - 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)
  - ...

pros: more flexibility in the project direction, more room to differentiate from other teams' projects
cons: more changes to the existing code at the start while you are still not very familiar with the code base

Weigh the pros/cons and choose the one that suits you.

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 → CS2103/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 CS2103/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 to be added by a 5-person team is roughly the equivalent effort taken to create AB3 functionality. Furthermore, we expect a team to reach that level if each member puts in an effort equivalent to the effort they put into the iP. Some examples meeting that criterion:

Example 1: A fictional contact management app optimized for a specific target user group:
- Existing AB3 features are optimized to the new target user group.
- Person objects are enhanced to contain more details.
- There are a 4-5 new functionality that are specific to the target user group.
Example 2: a FooBar app that keeps track of two different types of entities Foo entities and Bar entities.
- Foo and Bar entities are tightly-connected e.g., a Foo entity can contain Bar entities. Each type is similar to AB3 Person objects in terms of complexity.
- In addition to Creat Read Update DeleteCRUD for Foo and Bar entities, there are a 4-5 FooBar-specific functionality, some of which involves both Foo and Bar entities e.g., link a Foo entity to a Bar entity.

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.

If you wish to add the following features to your app, we recommend (but not require) you to follow similar features in AB4 in order to reduce the effort required.

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.

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.

Some examples:

Add a new feature e.g. add the ability to view statistics
Enhance an existing features in a major way e.g. make the command syntax more user friendly and closer to natural language
A redesign of the GUI e.g. make it work like a chat application (note: chat is a form of CLI)
A redesign of the code e.g. Improve the design to improve the code quality.

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.

Tip: Divide the components of the product among team members. Notwithstanding the above, you are still recommended 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 to fit their features, 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.

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 e.g.,
1. Work related to renaming the product
2. Work related to changing the product icon
3. Morphing the product into a different product
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[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.

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.

Your project should comply with the following constraints. Reason: to increase comparability among projects and to maximize applicability of module learning outcomes in the project.

Constraint-Brownfield

The final product should be a result of evolving/enhancing/morphing the given code base. However, you are allowed to replace all existing code with new code, as long as it is done incrementally. e.g. done in small steps, each producing a working product
Reason: To simulate a brownfield project.

Constraint-Typing-Preferred

Constraint-Single-User

The product should be for a single user i.e. (not a multi-user product).
Reason: multi-user systems are hard to test, which is unfair for peer testers who will be graded based on the number of bugs they find.

Constraint-Incremental

The product needs to be developed in a breadth-first incremental manner over the project duration. While it is fine to do less in some weeks and more in other weeks, a reasonably consistent delivery rate is expected. For example, it is not acceptable to do the entire project over the recess week and do almost nothing for the remainder of the semester.
Reasons: 1. To simulate a real project where you have to work on a code base over a long period, possibly with breaks in the middle. 2. To learn how to deliver big features in small increments.

Constraint-Human-Editable-File

The data should be stored locally and should be in a human editable text file.
Reason: To allow advanced users to manipulate the data by editing the data file.

Constraint-No-DBMS

Do not use a Database Management System e.g., MySQLDBMS to store data.
Reason: Using a DBMS to store data will reduce the room to apply OOP techniques to manage data. It is true that most real world systems use a DBMS, but given the small size of this project, we need to optimize it for CS2103/T module learning outcomes; covering DBMS-related topics will have to be left to database modules or level 3 project modules.

Constraint-OO

The software should follow the Object-oriented paradigm primarily (but you are allowed to mix in a bit other styles when justifiable).
Reason: For you to practice using OOP in a non-trivial project.

Constraint-Platform-Independent

The software should work on the Windows, Linux, and OS-X platforms. Even if you are unable to manually test the app on all three platforms, deliberately avoid using OS-dependent libraries and OS-specific features.
Reason: Peer testers should be able to use any of these platforms.

Constraint-Java-Version

The software should work on a computer that has version 11 of Java i.e., no other Java version installed.

Constraint-Portable

The software should work without requiring an installer.
Reason: Testers may not want to install your product on their computer.

Constraint-No-Remote-Server

The software should not depend on your own remote server.
Reason: Anyone should be able to use/test your app any time, even after the semester is over.

Constraint-External-Software

The use of third-party frameworks/libraries is allowed but only if they,

are free, open-source, and have permissive license terms (E.g., trial version of libraries that require purchase after N days are not allowed).
do not require any installation by the user of your software.
do not violate other constraints.

and is subjected to prior approval by the teaching team.
Reason: We will not allow third-party software that can interfere with the learning objectives of the module.

Please post in the forum your request to use a third-party libraries before you start using the library. Once a specific library has been approved for one team, other teams may use it without requesting permission again.
Reason: The whole class should know which external software are used by others so that they can do the same if they wish to.

Constraint-File-Size

The file sizes of the deliverables should not exceed the limits given below.

Reason: It is hard to download big files during the practical exam due to limited WiFi bandwidth at the venue:

JAR file: 100MB (Some third-party software -- e.g., Stanford NLP library, certain graphics libraries -- can cause you to exceed this limit)
PDF files: 15MB/file (Not following the recommended method of converting to PDF format can cause big PDF files. Another cause is using unnecessarily high resolution images for screenshots).

In addition, you are strongly encouraged to follow these recommendations as they can help increase your project score.

Recommendation-Minimal-Network

It is OK to use a reliable public API e.g., Google search but we recommend that you have a fallback mechanism (e.g., able to load data using a data file if the network is down).
Reason: During the mass peer-testing session, the network access can be intermittent due to high load. If your feature cannot be tested due to lack of Internet, that will have to be counted as a major bug, to be fair to those whose app is being tested and bugs found being penalized.
If you use NUS data (e.g., scrape data from an NUS website), please work with NUS IT directly to get their approval first. Even well-intentioned use of NUS data without approval can get you into serious trouble (has happened before). The teaching team will not be able to get approval for you as the use of NUS data is not a module requirement.

Recommendation-Testability

Avoid implementing hard-to-test (both for manual testing as well as automated testing) features or features that make your product hard-to-test.
Reason: testability is a grading criterion. If you choose to implement such a feature, you will need to spend an extra effort to reach an acceptable level of testability. Here are some examples of features that are hard-to-test:

Features that depend heavily on remote APIs: Those APIs can block your access if they mistake your automated tests as a bot attack. Some remote APIs require setting up accounts, keys, login etc, that will irritate the testers of your product and give a low rating to the testability of your work.
Audio-related features: The peer testing of your product is done under exam conditions where it is not appropriate to play audio.
Features that require creating user accounts, login, logout etc.

Recommendation-CLI-First

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.

If you are not sure if your product complies with a certain constraint/recommendation, please seek clarification by posting in the forum (preferred) or emailing the supervisor.

1. Project Grading: Product Design [ 5 marks]

Evaluates: how well your features fit together to form a cohesive product (not how many features or how big the features are) and how well does it match the target user

Evaluated by:

tutors (based on product demo and user guide)
peers from other teams (based on peer testing and user guide)

Q Quality of the product design,
Evaluate based on the User Guide and the actual product behavior.

Criterion	Unable to judge	Low	Medium	High
`target user`	Not specified			Clearly specified and narrowed down appropriately
`value proposition`	Not specified	The value to target user is low. App is not worth using	Some small group of target users might find the app worth using	Most of the target users are likely to find the app worth using
`optimized for target user`		Not enough focus for CLI users	Mostly CLI-based, but cumbersome to use most of the time	Feels like a fast typist can be more productive with the app, compared to an equivalent GUI app without a CLI
`feature-fit`		Many of the features don't fit with others	Most features fit together but a few may be possible misfits	All features fit together to for a cohesive whole

In addition, feature flaws reported in the PE will be considered when grading this aspect.

These are considered feature flaws:
The feature does not solve the stated problem of the intended user i.e., the feature is 'incomplete'
Hard-to-test features
Features that don't fit well with the product
Features that are not optimized enough for fast-typists or target users

Submission: Submit your product name, target user profile, the value proposition, and the public link to your collaborative project notes via TEAMMATES. You'll receive an email from TEAMMATES with the submission link. Only one member needs to submit on behalf of the team. All members can view/update the submission.
Submission link will be sent to you by Mon, Aug 31st (reason: we need a few days to set up the submission system after teams have been finalized).