ud904 »

Project 3

TODO List Manager for Android and Web

(We can rebuild it. We have the technology. Better, stronger, faster.)


Anything marked as a Project is required and graded, and is meant to be completed in groups, which we will assign.  To find the due date and see where this fits in the course overall, see the schedule.


The prototype was successful and caught the attention of Initech, which is potentially interested in supporting the development of a full-fledged application with additional functionality. As a first step in this direction, Initech has acquired your prototype, and a team of software engineers has completely revamped and rebuilt the application. Initech has then hired you, put you in a new team, and assigned you and your team the task of taking the revamped application and suitably extending it. Since you will be working for a corporation, you will follow a more structured process—the Unified Software Process.

Important Note

Since this project involves modifying existing code, you cannot start it until after you get access to the repository.  This should be shared with you automatically, but if the start date for the project has already passed and you do not see the repository on GitHub, please let us know!


  • Extend the Android application for managing TODO lists.
  • Get experience with real-world program comprehension (of undocumented, possibly buggy code)
  • Get experience with USP and various new technologies.

Requirements (include and extend the ones for Project 2)

  1. A TODO list consists of tasks that the users need to accomplish. The application must be capable of adding items to, deleting items from, and editing items in a list.
  2. The TODO List Manager consists of two applications that share most of their functionality:
    1. The Mobile TODO List Manager (MTM), which runs on the Android platform.
    2. The Web TODO List Manager (WTM), which runs on any standard web browser.
  3. In both applications, users must be able to add tasks to a list by specifying the tasks' name, priority, and due date.
  4. In both applications, there should be a default value for priority and due date, so that users won't have to necessarily specify them.
  5. In both applications, users must be able to check off items in a list (without deleting them).
  6. In both applications, users must be able to hide or show checked-off items.
  7. MTM must contain a local database (LDB)
  8. WTM relies on a centralized database (CDB)
  9. Information in the LDBs on the local phones is synchronized with the information in the CDB when the application starts and when users perform an explicit synchronization. The synchronization happens in both directions:
    1. TODO items updated on the phone should overwrite the corresponding items on the CDB.
    2. Analogously, items updated on the web (and thus the CDB) should overwrite the corresponding items on the phone.
    3. New items on the phone should be copied to the CDB.
    4. New items on the CDB should be copied on the phone.
    5. Conflicts must be suitably handled.
  10. On MTM, TODO lists must be saved (locally) automatically and immediately after they are modified.
  11. On MTM, lists are also saved on the CDB when the application starts and when users perform an explicit synchronization, as described above.
  12. On WTM, lists are saved (in the CDB) when users perform an explicit save.
  13. Both applications must support multiple users, each one with their own list.
  14. The User Interface (UI) must be intuitive and responsive.


  • You have been given access to a GitHub repository that contains the code of the revamped application.
  • As usual, be realistic in planning. It is OK to list some of the requirements as optional.
  • And as before, feel free to be creative and to extend the functionality of the applications if you think you can afford it. Creativity will be suitable rewarded.
  • Make sure to look at the requirements carefully to identify incompleteness or inconsistency issues.



  • As before, all deliverables must be uploaded to your team’s GitHub repository for the project:
    • Put documents in a subdirectory called "Deliverables" and the code for MTM and WTM in two separate directories:
      • <root>/Deliverables/Deliverable1
      • <root>/Deliverables/Deliverable2
      • <root>/MTM (already in the repository)
      • <root>/WTM (to be created)
  • We strongly recommend the use of the Google Web Toolkit (GWT, http://code.google.com/webtoolkit/) for the web part of the project.
  • We also strongly recommend the use of the Google App Engine (http://code.google.com/appengine/) to deploy the back-end of your web application.
  • Teams are completely free to use other technologies if they so prefer, but we cannot guarantee any support for alternative technologies.
  • Deliverables will be discussed extensively in class.
  • VERY IMPORTANT: After submitting an assignment by pushing your changes to GitHub, the team leader must post here the output of command "git show". We will use this information to identify your submissions in the repositories in case of problems.

Deliverable 1 – Inception

Deliverable 2 – Elaboration

  • Almost complete use-case model
  • Supplementary requirements
  • Software architecture
  • (Partially completed) design model
  • Test cases
  • Executable prototype
  • Revised risk assessment
  • Revised project plan
  • Preliminary user manual
  • Deliverable 2 description
  • Deliverable 2 submission

Deliverable 3 – Construction

  • Traceability information for a couple of use cases
  • Software product
  • Completed system tests results
  • User manual
  • Basically, this deliverable consists of the complete set of artifacts for the project: design, code, test cases...
  • Deliverable 3 description
  • Deliverable 3 submission

Deliverable 4 – Transition

Project 3 FAQ

  1. Can we use our own MTM code developed in Project 2 instead of given starter code? We are more familiar with our own code and really satisfied with what we did in Project 2.

    Sorry, but no, for two reasons. First, we want all the teams to start from the same point. Second, we want to simulate a typical real-world situation, in which you are given existing code that you need to modify and extend.

  2. What constitutes a conflict?

    A conflict is any situation in which you cannot define which one is the latest version of a TODO list. If that happens, it’s up to you how to handle the conflict. Any policy is fine, as long as there is one.

  3. Is WTM required to support explicit synchronization by the user?

    As long as any action performed by the user updates the database, it is fine not to. The phone is the de-synced device here.

  4. Is auto refresh (immediate refresh after new items were added, synchronization was performed, and so on) for WTM required?

    Auto refresh is not required for WTM. If you decide to implement it, though, we will consider that as extended functionality and suitable reward it.

  5. Is having passwords for users required in WTM?

    Users management should match what you have in MTM. If you do not have it in MTM, then you should not have it in WTM.

  6. The given MTM implemented more features than the requirements for Project 2, (e.g.. sort by due date, sort by priority, change password).  Is it required to implement all of MTM's functionality in WTM?

    Not necessarily. You can decide to leave out some features from WTM if you don’t have enough resources to implement them. If you do so, be sure to make it clear in your requirements document.

  7. Is it required to implement WTM with the same style of the given MTM (e.g., with respect to icons, how tasks are displayed)?


  8. What is the minimum set of mandatory requirements? Which requirements can be listed as optional?

    This is up to you. As we say in the project description, just "be realistic in planning."

  9. Should I build a public server and host the application if I use technologies other than Google App Engine? Or should I document how to deploy and how to use my WTM application?

    Either solution would work for us, as long as we have a clearly explained way to run the application.

  10. How many extra points will be given for extended functionality beyond the project requirement?

    It depends on the features you add. Normally, we give a maximum of 10% over the overall project grade for additional features.

  11. Do you have any quick start video or tutorial for GWT and google application engine?

    There are numerous resources online. We also put together a mini-tutorial to get you started, which you can find here. Please note that, although these technologies may sound hard to use, they are actually pretty straightforward when used to build a not-too-complicated system.

  12. Are there any templates for vision document, risk assessment document?

    No. The reason is that we didn’t want to constrain you, as in this case we are just looking for simple documents without a specific format. As long as the content of the document corresponds to what requested, no matter its format, you will be fine. Note that you can find plenty of examples on the web, if you want to see some.

  13. For the use case model, is the graphical model alone sufficient or should we add detailed descriptions, such as interaction steps, for each use case?

    You will need to add descriptions for at least the main use cases.

  14. For software architecture and (partially completed) design model, can we still use the template for design document in p1 and p2 and include both of them in a single document? Is low-level design mapping to design model?

    We would prefer to get two separate documents, but the content would be analogous. The answer to the second question is yes.

  15. Is an executable prototype in deliverable 2 required? If so, how many functions should be supported in this prototype?

    Yes. You will have to decide how extensive you want the prototype to be based on your available resources.

  16. Is it required to provide automated test cases for Deliverables 2 and 3?

    No. Automated test cases are always appreciated, and ultimately more useful for you, but they are not required.