Home    Program    Housing & Transportation    Registration    Submissions    Wiki    Maps

DesignFest®

Chair: Rob van den Berg, Siemens VDO Automotive, designfest@oopsla.org

• Overview
• Important Dates
• Submission Process
• DesignFest Problems
• Suitability of Problems
• For More Information

Overview

The DesignFest® was created to give attendees the opportunity to learn more about design by actually working through the design process rather than just reading about it. The DesignFest is not about passively sitting and listening to experts talk about design—it is about sharpening your analysis and design skills by rolling up your sleeves and working on a real problem with others in the field. The DesignFest is neither a design class nor a tutorial; it is an opportunity for designers to enhance and measure their skills by interacting with their peers.

This call-for-participation is for design problems, not participants. Problems should be sufficiently large, so that they present an interesting challenge, and yet sufficiently small, so that the participants can complete a design in a single day. Problem descriptions should be focused toward design, i.e. include as much analysis results as possible.

We invite you to submit problem proposals, especially ones extracted from real-world projects.

People wishing to participate in solving these problems (rather than submitting problems) should simply sign up for DesignFest when registering for OOPSLA 2004.

Important Dates

Submission due date: March 19, 2004
Acceptance and rejection notifications emailed: May 7, 2004.
Complete problem descriptions due: June 14, 2004

Submission Process

Go to the DesignFest submission system.

• Electronic submission of problems is required. Paper and fax submissions will not be accepted.
• Please use the OOPSLA submission system to submit DesignFest problems.
• You will receive confirmation by email that your problem has been received and is complete.

Problems may be modified up until the submission deadline.

DesignFest Problems

When submitting a problem description, you should use the following structure as a guide.

1. Abstract
   This concise presentation of your problem will be the basis for the participants to choose the problem they want to work on. Please keep this to under 200 words.
2. Description of a domain
   This description can be accompanied by pictures, images, text or whatever. The purpose of this description is to explain the context in which the problem is placed. The text should define any terminology and should be understandable by laymen. All abbreviations must be explained, if possible in a glossary.
3. Description of the program that is wanted
   This should include the goals of the program and the required functions. It should state what the program should achieve without enforcing any solutions.
4. Analysis diagrams
   A class diagram of the problem domain's object model, or any other type of diagram which may serve as a basis for the design, should be included here.
5. Detailed requirements
   Because of time limitations these should of course be restricted. An indication of performance and capacity requirements should be given.
6. Use cases
   A handful of use cases should be provided. They are well suited to provide hints for the design process, as design teams tend to work on them first.
7. Interfaces
   Descriptions of interfaces to other systems. This could be header files or file formats. This is of course optional when no interfaces to other systems are necessary.
8. References for further study
   These are references to articles, other similar systems or implementations.

Suitability of Problems

In an effort to improve the suitability of problems, the DesignFest review committee may ask the problem author to make clarifications if the problem requirements are not clearly specified. In particular all requirements must be clearly stated such that participants can easily understand them without further elaboration during the DesignFest sessions. Preference is given to authors that are experienced in the problem domain.

Problem descriptions from past designfests are available on the designfest web site (http://designfest.acm.org). You may want to review some descriptions to get a sense of suitability and complexity.

In addition, in order to clarify the problem domain and the requirements, it is likely that the authors will be asked to be present during the opening of each of the sessions.

For More Information

For additional information, clarification, or questions please feel free to contact the DesignFest Chair, Rob van den Berg, designfest@oopsla.org.