Design Document Grading

Team: Yes, No, Maybe So ...

Grade: (50 out of 100)

Document presentation (3 out of 5)

• Organization: OK
• Document author: OK
• use of English: some spelling errors and bad grammar need to be corrected.

It is now clear to me that you will not be implementing positioning into your version of Cyberguide. This is not in accordance with the original project request. There is currently a discrete positioning system available for Cyberguide that provides information as serial input to Cyerbguide and is implemented using a Motorola 68332 hooked up to an IR receiver that interprets remote control signals. I think you should plan a way to incorporate this positioning system into your Cyberguide.

Project Description of Target System (5 out of 5)

Comments:

High-level architecture (20 out of 30)

• static description (box-and-line type diagram, or suitable substitute): There are two components labelled "Interface". That is confusing. Also, I think you are confusing the "serial link" used for communications purposes with the positioning system. The latter already exists and you should be designing with it in consideration. The former is being built currently.
• dynamic description (Can I tell how the system executes over time?): OK
• use of standard or understandable notations: In your key you indicate that no arrows means bidirectional, but in your diagram, you end up drawing arrows both ways. Which is it? There is some confusion in your diagram about which lines get arrows and which don't. I think a lot of the problem would go away for me if the picture was just a bit larger and easier to distinguish. Why are the arrows drawn so clumsily on the diagram?
• completeness: How is the database populated with information? Manually, or is there a way to automatically extract this information from Web pages or some other source? You talk a little bit about this in the Requirements Document.

Design specification (22 out of 30)

• module/class definitions (identified, interfaces provided): methods defined, but no internal state/attributes defined for the various classes. You should provide that as part of your template class definition. Each class/component definition should have a brief description that details what the purpose of that class is.
• following a prescribed method (mainly for OO people): Well, I'm left wondering a bit how you designed the objects in your system. There is no evidence that you went through any sort of process. For example, it would have been better to have shown an entity-relation diagram that defines the data contained in the database. Is the database a flat file or is it a more sophisticated database structure. If I saw a clear description of the database structure, then it would have been sufficient to explain that the TCyberDB component contains methods to get the value of each of the database values.
• use of standard or understandable notations: Not really standard, but I can understand it.
• completeness: What about positioning system?

User Interface (0 out of 30)

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