project expectations
Outcomes
The high-level learning outcome of the team project (tP):
Can contribute production quality SE work to a small/medium brownfield software project
Accordingly, the tP is structured to resemble 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(taken for granted, not focused on specifically)- 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.
The final product is to be targeted at users who can type fast, and prefer typing over mouse/voice commands. Therefore, typed user commands are the primary mode of input.
Direction 1: Evolve Evolve 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
- Make existing features really strong, worthy of a real product e.g., make the commands more natural, make the search feature more powerful, tweak the GUI to be more useful, ...
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.
Direction 2: Morph Morph AB3 in 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.
cons: more changes to the existing code at the start while you are still not very familiar with the code base, morphing is less common in real projects (compared to direction 1).
Weigh the pros/cons and choose the one that suits you. Note that creating a novel/unique/interesting product will NOT earn you extra marks in this course. While those qualities are important in real world projects, and we do allow you room to go in those directions in this course, they are not the focus of this course (there are other courses such as CS3216, CS3217 that focus on those aspects). Focus your energy on creating a solid product at a high quality level, which actually take a lot more energy than you might realize at first. Go for novelty/uniqueness/interesting etc. only if you have energy to spare and can do so without compromising the quality. For example, a bland feature/product implemented well will score more marks than a novel product that is buggy, even if the novel features were harder to implement.
Our recommendation: Go with direction 1 unless you have a strong inclination to create a different product. Direction 1 fits both weak and strong programmers, smoother at the start, has a lower risk of schedule overruns (because it can be done in smaller increments all the way, while morphing requires some big changes at the start), and gives you a better chance of reaching a product that is worthy of actual users (as you will not be slowed down by the morphing).
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 of progressively 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.
- 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 likely to meet 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 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. Try to avoid adding more features than necessary, unless you are doing it out of interest. As mentioned elsewhere, a functionality just the right size and of high quality will earn more marks than a functionality that is bigger (or more difficult, or more interesting/novel) but of lower quality.
In the most recent semester, more than 80% of the students did significantly more work than what was needed to earn full marks for effort. Many of them were likely under the wrong impression that doing more features will earn them more marks. Try to avoid doing the same mistake yourself.
If you wish to add the following features to your app, we recommend (but not require) you to follow similar features in AB4 (not AB3) in order to reduce the effort required.
Team Expectations
- Expectation Produce a cohesive product: 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.
- Expectation Maintain product integrity/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 properly.
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.
In other words, we recommend that the work to be divided primarily based on features/enhancements rather than components. The latter has the risk of a team member becoming a single point of failure and you becoming too reliant on other team members e.g., what if the person assigned to an important component doesn't deliver on time?.
- 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. As you learn different types of testing and what they try to achieve, you should decide how much of each type is worth having. 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 test coverage level. Note that in a high-end 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.
- 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.
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.