For a presentation of your designs or a code walk, please proceed as
- Introduce yourself to class (full names, preferred calling name,
status). Act as if the audience consisted of people you do not know in
person and who should recognize your name because of your good work.
- Concisely restate the objective of the product that you are presenting.
- Provide an overview of your solution. For code walks, this should include
In addition, you may have to explain other aspects of the design with
diagrams, pictures, etc.
- a (UML class) diagram of the major components and their
- a (UML interaction) diagram that explains the major interactions
during a program execution.
- Present the components and their functionality in a top-down fashion,
no matter how you designed and implemented them. Refine as requested by
the panel or the class. Be prepared to defend your code organization, why
it matches or doesn't match your design.
In general, you may also be asked to figure out in real time how changes
to your information/data specification should be translated into changes
in your program organization.
When we evaluate the quality of a code walk, we are looking at three
- the presentation order (see above)
- your ability to focus from the context to specific lines of code
- your ability to think through issues that the panel, the class, or the
course staff brings up. If you haven't written the code or if you haven't
written the code as a pair, you will have serious problems with this
As a listener, you will play three different roles:
- a manager, who is the first "reader" (analyst) and who has the
responsibility that the presentation stays on track;
- an assistant reader, who is the second "code reader";
- a secretary, who keeps track of the questions that the readers ask, notes
discoveries of weak spots, and takes notes as needed.
When you are "secretary" you are responsible to get a report on the code
walk to Mr. Takikawa within a day. If the report is acceptable, we will
forward it to the reviewed pair; if not, we will request edits.
When we evaluate the quality of a panel, we are focusing on the two
- OK+ means the reader discovered significant problems and explained
them well to the presenters. This appears to depend on the quality of the
base of artifacts. Because all software artifacts are somewhat flawed,
however, the quality of the presented code doesn't really affect your
ability to get this grade.
- OK means the reader asked pertinent questions and discovered some problems.
- OK- means the reader asks questions, possibly including a pertinent one.
- ZERO means the reader didn't ask any questions or none of the
questions were pertinent to the artifact at hand.
A secretary's grade depends on the quality of his memo; if the secretary
asks pertinent questions, he receives bonus points.
The HTML memo from the secretary to the presenters must include the following
- the presenters
- the panelists
- the title of the project presented
- the date and time
- a bullet list of problems discovered. Use complete sentences to
describe those problems in enough details so that the presenters can
reconstruct them and fix them from the information specified.
- If the panel discussed potential solutions with the presenters,
include these suggestions with the appropriate bullet.
Recall that panels do not usually discuss solutions, however, with the
The evaluation of a memo will take into account the timely delivery of the
first draft, its format, its information content, and basic English
writing (typos, grammar mistakes). The latter will affect your grade in a
serious manner if the mistake allows a misinterpretation of a sentence or
if the mistake makes an interpretation extremely difficult.