http://www.oopsla.org/2006/2006/index.php?option=com_content&task=view&id=31&Itemid=56

program registration submissions committee lodging portland

CFP: DesignFest®

Chair: Ralph Johnson, University of Illinois at Urbana-Champaign,

Important Dates
    Submission deadline (firm)
  • June 30, 2006
    Notifications
  • July 24, 2006

Overview

DesignFest® is looking for new problems (see http://designfest.acm.org for details). Problem descriptions should define the problem clearly, and ideally are different from past problems. For a complete list of past problems, see http://designfest.acm.org/Problems/Welcome.htm.

If you would like to participate in solving a DesignFest® problem, you do not have to submit a proposal--simply sign up when you fill out your registration form!

Content

DesignFest® problem descriptions should, in general, include:

  • 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. The abstract is used in the subscription process for attendandees. It is therefore required in all proposals.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • References for further study. These are references to articles, other similar systems or implementations.
  • 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.

Problem descriptions from past DesignFests® are available on the DesignFest® web site. You may want to review some descriptions to get a sense of suitability and complexity.

Submission Process

Electronic submission of proposals is required through the OOPSLA submission system.

Expect that your problem will be revised several times before it is accepted. The sooner you submit, the more help with revision you are likely to receive.

For more information

For additional information, clarification, or questions, please contact the track chair.

 

While Space Available
Search
program registration submissions committee lodging portland
For comments and questions about the web site
please contact us at support@oopsla.org
© 2005 OOPSLA