DesignFest® Roles and Deliverables

Participants usually take over one or more of the following roles:

• Designer as part of the Design Team
• Moderator
• Recorder

Design Team Process Guidelines

• Introduction of the participants
• Reading of the documents
• List of discussion subjects (each member can add questions/points to the list).
• Planning of discussion. This includes planning of the domain expert. List unclear requirements, open questions, proposals, design drawing notation.
• Discussion. This discussion should try to follow the planning.
• Sketch of object design models. Sketch the models using a common design technique (such as OMT) and highlight patterns. Allow multiple models to develop in parallel.
• Visit other group(s).
• List fudge areas — the areas where there is a disagreement or where choices are made without a solid basis.
• Try to evaluate design models on their strengths and weaknesses.

The Moderator

The moderator is helping the group of designers to make progress. She or he will guide the group in the process, but definitely not in content. The moderator's primary responsibility is to prevent the group from wasting time. For this reason, she will follow a program of milestones (milepebbles?) to prevent the group from getting stuck in a certain phase.

The moderator will:

• Assure a fair chance for all participants to say their opinion.
• Reduce the influence of single persons.
• Indicate progress or absence of this to the group.
• Summarize what the group has done so far to get to a common understanding.
• Ask questions to make the group aware of missed areas.
• Solve clashes between personalities by clearly stating the difference and leaving it at that.
• Plan a time to see the results of other groups.

The moderator will not:

• Steer the group into a certain direction.
• Give "expert" advice.
• Show bias.

The Recorder

The recorder is responsible for a report about the session's results for the ice-cream social (on the last day of the conference) and for the web. This responsibility does not imply that the recorder must do all the work. Other people can gather documentation (e.g., someone else could be the one at the board drawing object diagrams).

The recorder will:

• Truly, accurately record the spirit of the session, not unbalanced by the recorder's view.
• Ask for clarifications when things are not clear.
• Join the discussions if they wish.
• Assist the moderator in summarizing
• Submit a report, preferably in html, to the DesignFest Webmaster, no later than November.

The recorder will not:

• Steer the session.
• Emphasize his own opinions in the report.

Suggested Deliverables

Assumptions

list of any assumptions made during the session, including and especially assumptions about scope, architecture, existance of other modules or services, implementation environment, and implementation language.

Class Model

list of classes and diagram of relationships; should show at a minimum inheritance relationships, aggregation relationships, and uses relationships. Anything more starts to delve into specific methodologies and languages, so make sure they are mentionned in the Assumptions.

Class Interactions

describe the methods used when classes interact, some examples are: via parameters, common data area (e.g. persistent database), import/export file, or XML stream. In many cases the class interactions can be described with some sort of interaction diagram. A really detailed design will identify formats, acceptable values and their meaning.

Interfaces

describe how does the system just designed interacts with the outside world (this may already be in the problem description)

Lessons learned

describe what you learned about requirements, about analysis, about design, about evaluating designs, about patterns, about software development processes, about yourself, about teamwork, or anything else you learned and care to share.

Component Model (optional)

if applicable, provide a description of each component, its purpose and its interfaces

Persistent Data Model (optional)

identify which classes need to be persistent, if any.

Error handling (optional)

for the ambitious team, describe how the system will gracefully handle errors, such as bad input, or system failures (network, db, etc). This may require additional descriptions in the other deliverables.

Class Details (optional)

describe each class including name, purpose, role in a pattern (if applicable), attributes, states (if complex), method names, interesting algorithms for methods