Design Document Grading

Team: Scooby2bedue

Grade: (89 out of 100)

Document presentation (5 out of 5)

• Organization: OK
• Document author: OK
• use of English: OK

Project Description of Target System (4 out of 5)

Comments: Your first paragraph suggests that the functionality of your to-do list manager exceeds that of other products. I don't think that is an accurate portrayal. Most of the features you describe are available on any to-do list manager that I have used.

High-level architecture (25 out of 30)

• static description (box-and-line type diagram, or suitable substitute): OK, this gives a reasonably good overview of how subsystems fit together. But isn't it more accurate to have a single server and a single client? The client in this case is the WWW client and inside of it resides the Java Virtual Machine and the To-Do applet and its parts.
• dynamic description (Can I tell how the system executes over time?) good job
• use of standard or understandable notations: reasonable enough, though it's not entirely clear to me what you mean by control and data here. All connections between a client and a server are data only. The connections within the applet are message (or method), because that is all that is allowed in Java. And a message contains data and control information.
• completeness: OK

Design specification (25 out of 30)

• module/class definitions (identified, interfaces provided)
• following a prescribed method (mainly for OO people): not clear. You used Coad/Nicola notation, but no evidence of an OO method being used here (as taught in 2390). I think it would make the whole document a lot clearer if you would separate out the domain model from the interface model in your Figure 2. There is also some redundancy in your static model. For instance, you show the part-whole relationships graphically and also include attributes in the object descriptions that represent those containment relationships. In Coad/Nicola book, they suggest marking the attributes with a "(d)" to indicate that they exist only to manifest the static model relationships. And then other relationships are not drawn. For example, an item is associated with a group, so that should be depicted with an association arc, not just an attribute in item. Also, it is not clear why you chose to isolate out objects to implement the linked lists here.
• use of standard or understandable notations: OK
• completeness: just need to work on making it clearer, not more complete.

User Interface (30 out of 30)

• where relevant, is the human interface well-defined? yes
• evidence of UI design (screens, drawings, etc.) yes