Skip to content

Latest commit

 

History

History
63 lines (48 loc) · 4.79 KB

W16_lab05.md

File metadata and controls

63 lines (48 loc) · 4.79 KB
Raw

Radhika Khatod rkhatod7

William Stevenson wjstevenson95

a) brief description of project 1-2 sentences Their application allows users to create a todo list that can be sorted by name, date or completion

b) a set of user stories (as a X I can Y so that Z) that describe what the current software in its current state can do. As a user I can create a task. As a user I can "complete" a task. As a user I can sort my tasks. As a user I can delete all my completed tasks. As a user I can delete an uncompleted task. As a user I can edit an already created task.

c) a brief assessment of whether the software runs or not. If it runs, briefly describe what it does, The software runs. The ToDo list window pops up and the user can start adding and sorting tasks.

d) a set of user stories (at least 2, but you are encouraged to write up to 4 or more if you can, as many as you think is reasonable)about features that COULD be added to the software to make it more useful, fun, better, etc As a user I can group lists so that I can see tasks relating to a specific topic. As a user I can set an alert so that I know when a due date for a task is approaching. As a user I can color code my tasks so that its easier to visually group them. As a user I can see all my tasks on a calender so that I can better visualize them.

e) An assessment of the current quality of the README.md. What information could be added to make it easier for the next generation of folks maintaining this code to use the software, and/or maintain the software?

  • The README.md file could be more informative about how each class connects with one another as opposed to just stating that the Task class is the main class.
    • This can be fixed by adding a description of each class and its overall purpose.
  • The README says that you can create subtasks but that feature hasn't been completely implemented yet.

f) An assessment of the current state of the build.xml file. Are there targets that need descriptions? Is there old legacy JWS stuff that needs to be removed? (More on this below).

  • All ant targets in the build.xml file have appropriate descriptions/comments.

g) A list of additional issues that you may have added, if any. For each, a link to the issue is good enough.

  • Implement calendar view so that user can see tasks on a monthly basis.
  • Implement alarm capabilities for tasks. User can specify which tasks should produce an alarm once the Due Date is up.
  • Implement notification or alert when Due Date for a task is getting closer.
  • There isn't any test coverage for the Todo List, so JUnit tests should be added.

h) Most important: an assessment of the actual code. Write a bit about how the code is organized.

  • The code is organized into 3 classes which define individual tasks, a task list, and the GUI components to show both on a window, respectfully.
  • The code is grouped appropriately and has comments describing important or confusing sections of code. Are the purposes of the classes, and their methods clear?
  • The purpose of the classes is made clear through the class descriptions, however, many of the methods in Task.java lack descriptional comments that say why the method is needed and what the method does. Is it obvious how the classes relate to one another?
  • It is obvious how the classes relate to one another, however, the README.md could include more information about that. Is the code easy to read and understand?
  • The code is very easy to read, however some of the method implementations for Task.java are unclear. If you had to give someone else that was going to work on the code just "one screenful of text" to help that programmer get up to speed quickly, what information would you convey?
  • I would add specific information about how the 3 classes are connected with each other as well as individual class descriptions with information about the purpose of the class and some of the more important methods.

i) Related to code quality, but factored out into a separate issue because it is so important: how is the test coverage? Are there JUnit tests at all? If so, how much of the project is covered by testing? Are there opportunities to expand test coverage, and if so, how would you go about it?

  • At the moment, it doesn't seem as though there are any JUnit tests created for this project at all. So none of the project is covered by testing and there are many opportunities to expand test coverage.
  • We think adding Java test files for this Todo List would be extremely beneficial. The tests would cover methods or capabilities specific to individual classes, as well as different combinations of actions to do once the TodoList GUI is loaded.
  • There are many different buttons and other capabilities to test at different times once the window is up. This provides for many different Todo List scenarios to cover and test.