 |
Important Dates
Practitioner report submission:
October 11, 2002 (23:59 GMT)
Notification of acceptance: December 09,
2002
Practitioner feedback track: March 19 - 21,
2003 |
|
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
o
How was it staged and approached?
o
What surprises were there?
o
How readily did the team pick up the concepts?
o
How successful were you?
o
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
o
What did you do?
o
How big was the project?
o
Which AOSD techniques did you use and why?
o
How were your software engineering processes affected, if at all?
o
What were the results - can you quantify the benefits (or drawbacks) from the
use of AOSD?
o
What are the next steps?
• Best (or "better") practices in the use
of AOSD
o
From your experience, what works and what doesn't work when building AOSD
applications?
o
What are some of the design trade-offs, and how do we make them?
o
What conventions are you adopting? |
|
Submission
Guidelines |
Practitioner reports should be submitted to
practitioners@aosd.net to arrive no later than October 11, 2002. A practitioner
feedback committee (separate from the program committee, including Adrian Colyer
and Gregor Kiczales) 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.
Submissions should be made in PDF format to practitioners@aosd.net to arrive no
later than October 11th, 2002.
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
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
2003 Industrial Track Chair: Adrian Colyer (practitioners@aosd.net). |
|
|
|
