CS2103/T Aug '18
  • Nested (current format)
  •     Flat
    •
  • Schedule
  • Textbook
  • Admin Info
  • Report Bugs
  • Slack
  • Forum
  • Instructors
  • Announcements
  • File Submissions
  • Tutorial Schedule
  • Team IDs
  • Java Coding Standard
  • samplerepo-things
  • Addressbook-level1
  • Addressbook-level2
  • Addressbook-level3
  • Addressbook-level4
  • Projects List
  • config.json templates for Reposense
  • Project Code Dashboard (BETA)
    •

    • Project: The productProject: Constraints


    Project: Scope

    project expectations

    In general, each team is expected to take one of these two directions:

    • [Direction 1] Optimize AddressBook for a more specific target user group:

      An AddressBook,

      • for users in a specific profession  e.g. doctors, salesmen, teachers, etc.
      • based on 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)
      • based on what users do with the contacts  e.g. organize group events, share info, do business, do analytics

    • [Direction 2] Morph AddressBook into a different product: Given that AddressBook is a generic app that manages a type of elements (i.e. contacts), you can use it as a starting point to create an app that manages something else.
      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.

      An app to manage,

      • 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)

    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 → 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 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 CS2103/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.

    Individually, each student is expected to,

    1. Contribute one enhancement to the product
      Each enhancement should be stand-alone but,

      • it should be end-user visible and end-user testable.
      • should fit with the rest of the software (and the target user profile),
      • and should have the consent of the team members.
      1. Add a new feature
      2. Enhance an existing features in a major way e.g. make the command syntax more user friendly and closer to natural language
      3. A major redesign of the GUI e.g. make it work like a chat application (note: chat is a form of CLI)
      4. Integrate with online services e.g. Google contacts, Facebook, GitHub, etc.

      Here are some examples of different major enhancements and the grade the student is likely to earn for the relevant parts of the project grade.

      In the initial stages of the project you are recommended to add minor enhancements in order to get familiar with the project. These minor enhancements are unlikely to earn marks. You are advised not to spend a lot of effort on minor enhancements.

      Here is a non-exhaustive list of minor enhancements:

      1. Support different themes for the Look & Feel  dark, light, etc.
      2. Support more fields  e.g. Birthday
      3. Load a different page instead of the default Google search page  e.g. Google Maps page or Twitter page
      4. Sort items
      5. Multiple panels  e.g. an additional panel to show recently accessed items
      6. Marking some items as favorites
      7. Ability to search by labels
      8. Ability to specify colors for labels

    2. Recommended: contribute to 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 an enhancement 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.

    3. Do a share of team-tasks: These 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:

      1. 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
      2. Setting up the GitHub, Travis, AppVeyor, etc.
      3. Maintaining the issue tracker
      4. Release management
      5. Updating user/developer docs that are not specific to a feature  e.g. documenting the target user profile
      6. 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)

    4. Share roles and responsibilities of the project.

      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.

    5. Write ~300-500 LoC of code, on average.

    Relevant: [Admin Project Asessement → Expectation 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.
    • 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.
    • Applying TDD is optional. If you plan to test something, it is better to apply TDD because TDD ensures that you write functional code in a testable way. If you do it the normal way, you often find that it is hard to test the functional code because the code has low testability.

    As a team, you are expected to work together to,

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

    Project: The productProject: Constraints