DesignFest® Roles and Deliverables
Problem Collection |
Last Edition |
Next Edition |
All DesignFests since 1995 |
Participants usually take over one or more of the following roles:
to come up with some Deliverables.
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
- 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
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
- 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 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
no later than November.
The recorder will not:
- Steer the session.
- Emphasize his own opinions in the report.
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.
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,