Open Until August 31
Lightning Talks



Chair: Daan Hoogland, Snow B.V., designfest@oopsla.org


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.

DesignFest® will need problem descriptions once again in 2005. These can differ in style and applicability. The commitee is looking for people that will write problems, let them be reviewed and be prepared to rewrite them. Preferably the authors will be present as "client" at the DesignFest® session, and are willing to rewrite their problem after the DesignFest® for future feasts and for the academia to use in their efforts to raise the next generation of developers.


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.

Preferably problem descriptions should be focused toward design, i.e. include as much analysis results as possible. An alternative is to submit a more preliminary "statement of needs" that can be analyzed, rather than designed, during the session. These submissions however require an author to be physically present to assist the team from time to time as they firm up the problem specification.

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 2005.

Important Dates

  • Submission due date: March 18, 2005
  • Acceptance and rejection notifications emailed: May 31, 2005.
  • Complete problem descriptions due: July 26, 2005

Submission Process

Electronic submission of proposals is required through the OOPSLA submission system. Other submissions will not be accepted.

You will receive confirmation by email that your problem has been received and is complete. Problems may be modified up until the submission deadline.


The Problems descriptions shall, in general, include:

  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.

    This part is used in the subscription process for attendandees. It is therefore not an optional part.

  2. Description of the domain. A description of the contextual organisation that the solution solving the problem is to be deployed in, or the system that needs improving. 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. The problem that needs solving or the improvements required. This could be a 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, could 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.

  9. The expected deliverables. This is not a strict requirement, but if the author wishes to see his or her problem adressed in a particular setting or proces method this can be indicated in this way. Asking for a static and dynamic model will be a fair indication that a classical design is wanted. Asking for a domain specific language is a clear indication that Model Driven Architecture (MDA) is prefered. If the intent is to do detailed analysis rather than design, that should also be stated, and items 4-6 can be significantly less detailed.

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 if at all possible.

For More Information

For additional information, clarification, or questions please feel free to contact the DesignFest Chair, Daan Hoogland, at designfest@oopsla.org .