Design Fest Chair: Torsten Layda, firstname.lastname@example.org
Submissions due date: 23 March 2001.
Notification of acceptance or rejection: 8 May 2001.
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 focussed 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 2001.
When submitting a problem description, you should use the following structure as a guide.
This concise presentation of your problem will be the basis for the participants to choose the problem they want to work on.
- 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.
- 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.
- 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.
- Detailed requirements
Because of time limitations these should of course be restricted. An indication of performance and capacity requirements should be given.
- 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.
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.
- 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.
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.
Proposals must be submitted no later than March 23rd, 2001, but earlier is better. Acceptance and rejection notifications will be emailed by May 8th, 2001.
After a problem is accepted and review comments have been exchanged, it is necessary that the authors submit their problem description in HTML format.
For additional information, clarification, or questions please feel free to contact the DesignFest Chair, Torsten Layda, at email@example.com.
Back To Top