CS2103T: Do-erList Project Retrospective

Do-erList is a desktop Todo list application. It has a GUI but most of the user interactions happen using a CLI (Command Line Interface). It is a Java sample application intended to meet Jim’s requirements and it is written in OOP fashion.

For testing, it supports for Build Automation using Gradle and for Continuous Integration using Travis CI.

For example, you can add a task to the list with format add /t TITLE [/d DESCRIPTION] [/s START] [/e END] [/c CATEGORY] [/r RECURRING]...

Please refer to the User Guide for more information.

Also developer guide provides deeper understanding of the design.

e.g. How we process the logic command.

Developer Guide

Details about Jim’s requirements:

Project Retrospective

If I were to redo this project again, I could do better in these three aspects: design, testing and project management.

Design

For design part, in our project, we frequently using the approach “design using code” instead of going through the sequence diagram and class diagram to carefully design each component. I think there are two reasons for this. We don’t have enough time to draw each diagram and we always think that we should first implement the features and then draw the diagrams to write developer guide. We think that diagrams are just to help other developers understand our product. However, we are only partially correct. Another important thing that the class diagram and sequence diagram can benefit us is to help us design. As we can apply design principles and try different kinds of design patterns with little cost (because we haven’t implemented the feature yet) when we draw the diagrams, we can produce better design. For example, due to the lack of design process, the implementation “recurring” feature of our product doesn’t follow the Single Responsibility Principle (SRP) and the APIs are a little bit messy. We could do better in this by going through the design phase first before the actual implementation. If we do that, the coupling could be decreased and the cohesion could be improved.

Testing

For testing part, we should have written unit test and applied equivalence partitioning in our product. In our project, we just follow blindly the fork of “AddressBook-level4”’s test cases and add more test cases to “LogicManagerTest” and “GUItest, which are the combination of unit test and integration test and system test respectively. As a result, although the product is deliverable at the end as a whole, there are still some defects existing. For example, we should have validated the start time and end time of a task more carefully. Time is only accurate to minutes in our product but our system compares two times by seconds. Therefore, there exists a situation such that the start and end time are the same in displaying. Although we have a test case for validation of start and end time in “LogicManagerTest”, we haven’t covered such corner case as “LogiManagerTest” is kind of integration test. If we could write unit test for every component and do equivalence partitioning carefully when we implement it, such bug could be quickly found. Another benefit of using unit test and applying equivalence partitioning is to help us ensure the quality of the deliverable of teammates. If one of the teammates is in charge of one component and have written unit test for that component and applied test case design techniques, we only need to examine the unit test and make sure they all pass.

Project Management

For project management, we should have followed the iterative model in SDLC process carefully. Like I mentioned above, we didn’t do very well in design and testing parts in the SDLC process. The reason could be our team don’t even know the SDLC process model at the beginning. I think next time we should introduce the SDLC model at the beginning, make sure that everyone follows the principles in the SDLC process and thus form a productive team.