AOSD 2004: Call For Practitioner Reports

Important Dates

Practitioner report submission:	October 22, 2003
Notification of acceptance:	To be announced
Practitioner feedback track:	To be announced

Overview

We invite insightful contributions from practitioners in commercial and noncommercial organizations adopting and using AOSD techniques. Submissions addressing the following topics are of particular interest:

• Lessons learned introducing AOSD into the development process
  
  
  • How was it staged and approached?
  • What surprises were there?
  • How readily did the team pick up the concepts?
  • How successful were you?
  • What lessons can you pass on to others thinking of following in your footsteps?
  
  
• Case studies of completed or in-progress projects employing AOSD techniques



• What did you do?
• How big was the project?
• Which AOSD techniques did you use and why?
• How were your software engineering processes affected, if at all?
• What were the results - can you quantify the benefits (or drawbacks) from the use of AOSD?
• What are the next steps?


• Best (or "better") practices in the use of AOSD
  
  
  • From your experience, what works and what doesn't work when building AOSD applications?
  • What are some of the design trade-offs, and how do we make them?
  • What conventions are you adopting?

Submission Guidelines

Practitioner reports should be submitted to practitioners@aosd.net to arrive no later than October 22, 2003. A practitioner feedback committee (separate from the program committee) will evaluate the submissions. The accepted submissions will be presented at the conference and posted on aosd.net.

Practitioner reports should be 5-10 pages in length, including an abstract not to exceed 300 words. The authors names, affiliations and e-mail addresses must be clearly stated on the first page. A references section should list all publications that have been referenced in the report, and references should be complete and consistent in style. It is not a requirement to follow the technical paper submission guidelines, though you may do so if convenient. A single column layout is acceptable if this better suits your material.

The ICSE 2003 conference site provides quality criteria and guidelines for experience reports which you may find helpful in preparing your submission. With thanks to the ICSE 2003 Experience Reports Committee, a subset of those guidelines are reproduced here for convenience:

Write with your intended audience in mind. Your paper must contain a take-home-message for your readers; something they can learn and apply to their own work. Avoid plain "how we did it" reports.

Structure and content of report

The structure and content of a good experience report is characterized as follows.

• The introduction
  
  
  • presents the background and the context of the contribution
  • makes clear which roles the authors of the contribution play in the work that is being reported
  • summarizes results and insight in a few sentences
  • gives an overview of the structure of the paper
  
  
• The main sections
  
  
  • of a "classic" experience report describe the approach and its results in terms of the methods, techniques, languages, tools, processes, prerequisites, problems, and people involved, as appropriate
  • of a case study describe a product and give rationale for the key decisions shaping the product
  
  
• The conclusion
  
  
  • evaluates the results and derives experience and insight that is valuable for the intended audience of the paper
  • reports both positive and negative observations (nothing is perfect!)
  discusses limitations and the range of applicability
  • refers to related experience by others and discusses it (if such experience exists and if this has not been discussed in the introduction)
  • summarizes the state of work and sketches future work (if applicable)
  
  
• The references
  
  
  • list all publications that have been referenced in the paper are complete and consistent in style
  
  

Evaluation and presentation of results

Frequently, authors of experience reports fail to present background, motivation, and evaluation of results; describing only the practical application of a method, process or language. Such a "how we did it" report has no value for most readers because they can't derive any insight or directions for their own work from it. Avoid this FMM (frequently made mistake).

Experience reports should provide lessons that can be drawn from what you did. However, reporting only positive experience is another FMM. An experience report is no sales brochure, so include all interesting observations, whether positive, negative or inconclusive.

Ideally, results are evaluated quantitatively. If you do not have quantitative results, give at least a qualitative discussion of results. For example, if you report on the application of process xxx, tell the audience what different stakeholders in the process think about the success/failure of xxx and what they expected, give your (the authors') observations and insights and compare them with those of the stakeholders, etc.

Contact

For additional information, clarifications, or questions please contact the AOSD 2004 Industrial Track Chair: Ron Bodkin (practitioners@aosd.net).