Experience Reports


The technical program will include a track on Experience Reports. This track will provide accounts of the application of software engineering techniques, tools, and processes to a specific domain or the development of a significant software system.


We welcome both "classic" experience reports and case studies. Classic experience reports give an account of a significant project accompanied by a critical review of the experience and a discussion of some general lessons to be drawn from the experience. Case studies describe a product (a piece of software, a software process, a software quality management system...) and give rationale for the key decisions made during the development of the product.

Experience reports should be described and organized such that they are useful for study and insight and such that the key ideas and results can be reused by practitioners.

Important Dates

Paper submission:                October 4, 2002  (Closed)
Notification of acceptance:    December 2, 2002
Camera-ready copy:              TBA

Quality Criteria for Papers

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.

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.

Review Process

The Experience Reports Committee will review each contribution and will select quality contributions that fit the criteria mentioned above.

How to Submit

Submission is closed as of October 4, 2002.

If you are having problems submitting a paper electronically over the Internet, please see the If You Have Submission Problems page.

Submitted (and accepted) papers must conform to the ICSE 2003 paper format and should not exceed six pages, including all text, references, appendices, and figures.

For case studies, it can be a problem to provide enough depth and detail within a limit of six pages. In this case, include the context, an overview, some typical examples and the evaluation in your paper. Assemble all the details into a technical report and make it available on the Web. Provide a reference and the URL of this technical report in your paper.

We'll expect submissions to be in Adobe Portable Document (PDF) Format; however, if submitting in PDF presents a hardship for you, contact the chairpersons.

Acceptance Notification

The authors of accepted contributions will be notified by December 2, 2002 (tentative date).

All accepted contributions will be published in the conference proceedings. Papers must conform to the ICSE proceedings publication format. There will be a page limit of six pages per paper.