DesignFest Home

DesignFest® Roles and Deliverables


[ Home | Problem Collection | Last Edition | Next Edition | All DesignFests since 1995 | Implementations | Photo Gallery ]

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

to come up with some Deliverables.

Design Team Process Guidelines

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:

The moderator will not:

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:

The recorder will not:

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


Last updated by Torsten Layda, SWX Swiss Exchange, DesignFest® Webmaster.