CS 130: Software Engineering, Spring 2009: Project Assignment 3

Project Name

For the purposes of this assignment, we number the projects as follows:

List updated according to Chuong's list.

Assignments: Project i reviews the project i+1 (mod 8)

Design Review for Name of Project You are Reviewing

??/??/??, Version major.minor

Instructions

This is a design review template for CS130. Each team must submit a copy of this completed document by 11:59 am on 05/04. Your group has been assigned to review the design and planning document for one of the other projects. You will receive an email containing the design document to be reviewed, along with the requirements document that you should use to understand the problem to be solved. For this class, the design review serves two purposes. First, it is the last check that projects are addressing a clearly understood problem in a coherent and practical manner. While the course staff will also review the design and provide feedback to groups, there is great benefit to having more people read and comment on designs before a lot of work is invested in coding. Second, you will be the quality assurance organization for this same project in a later assignment; we will expect you test that group's code. This assignment will familiarize you with the other project, and give you an opportunity to have input into their design prior to testing. One important aspect of the process is a non-disclosure agreement you may have to sign in order to see the requirements and design documents for the other project. I will let each groups come up with a specific NDA document: for the purposes of this course, the NDA can be a short agreement that would say that the reviewing team will not disclose the contents of the requirements/design documents to a third party or on a public forum such as a web site. (In practice, these documents contain a lot more legalese.) (As far as I know there are 2 groups that require an NDA and they can use a more comprehensive NDA.) Please take NDA requirements seriously! These are both ethical requirements for your profession and legally binding agreements. Please note that reviews should be written with a professional tone, and suggestions, technical or otherwise, are most welcome. By writing a review for another team, you are contributing to their project by becoming collaborators. You essentially become part of their team. Although you do not contribute to development, your insights are very valuable.

Summary

Here you should give a summary of your design review. This section, which should be relatively short, focuses on the recommendations you consider to be the most important.

Questions

At the end of the design document template, there were a number of questions that you should use to guide your review. Please organize your comments as answers to the following questions (which summarize the questions from the design template). Your answers may be of any length, but should be justified by reference to specific parts of the design document (and specification, if appropriate).
  1. Are there any inconsistencies in the design? That is, does the document contradict itself?
  2. Are there omissions in the design? That is, are there elements that are mentioned but never discussed, or obvious pieces that are missing?
  3. Are any parts of the design unclear? The standard should be that given the design document, a competent programmer can code the project. Note that ``clear'' does not mean that the document must be very detailed. We assume that a decent computer scientist can fill in missing details, provided the overall document is clear enough.
  4. Are there technical errors in the design? Is there any statement of fact that you know is false?
  5. Has thought been given to testing? How would you test this design? What, if anything, could be done to make the design easier to test?
  6. Does the design make realistic assumptions about the environment? That is, will the team have trouble getting access to important external components (e.g., specialized hardware or software) and are the systems the project needs to interact with suited to the purpose?
  7. Does the plan seem realistic? Are tasks at a reasonable level of granularity and is it clear what each task means? Do the time estimates seem appropriate? Do any parts of the plan seem risky in the sense that they are likely to become a bottleneck to further progress?
  8. Any other comments?