Paper Reviews

Swe0607
Experience is a good way to understand the issues involved in software engineering. However, to better tackle the problems you encounter, you should get an overview of software engineering theory as well. In this course you are expected to read one paper every two weeks and submit it for grading. Contrary to the lab assignments, a student writes each paper review by himself.

Reviews

Structure

For each of the papers below, write a short review which

  • summarizes the paper (a few paragraphs)
  • positions the topic of the paper within software engineering (one paragraph). In other words, what is the goal of the paper and what kind of role does it play within the field of software engineering.
  • answers the auxiliary question that accompanies the paper (if present)
  • states your opinion about the paper and the method it proposes (one or two paragraphs)
  • In total your paper should be not less than 1.5 and not more than 2 pages A4.

In the above the number of paragraphs is an indication only.

The main goal of a review is to show to us that you have understood the paper, and that you have developed some of your own thoughts on the subject. In some cases, some of the above points do not really apply to a paper.

Format

  • Write the review in English
  • Use your own words! Copy and paste is plagiarism
  • Submit the paper by handing in a printed paper copy before the deadline (see below).

Grading

Grades are determined based on the following points

  • Adequate summary of paper and lecture
  • Good understanding of position in software engineering
  • Quality of writing (spelling, grammar, style, vocabulary, structure)
  • The amount of original thought added
  • Handling of the auxiliary questions

Submission

Papers ought to be submitted using the Submit system. The only two forms opf submission we accept are a PDF file (with extension pdf) or plain text (.txt extension). Make sure the text contains your name and student number.

Papers to be reviewed

(Note that some of the papers are available from the ACM digital library; these papers can be downloaded from a computer at the University or via VPN.)

The list of papers below is the definitive one for 2006.

  • H. Boehm. A view of 20th and 21st century software engineering. In ICSE '06: Proceeding of the 28th international conference on Software engineering, New York, Usa, pp. 12-29, 2006. Deadline: 25 Sep 2006, right before the lecture in the lecture room
    Question for this paper: consider the plusses and minuses (listed in Section 4.1) and choose one that you think has had an influence on (some) programming languages and describe this influence. Grades Review 1

  • K. Czarnecki. Overview of Generative Software Development. In J.-P. Banātre et al. (Eds.): Unconventional Programming Paradigms (UPP) 2004, Mont Saint-Michel, France, LNCS 3566, pp. 313-328, 2005. Deadline: 9 Oct 2006, 23:59, Submit code: paper review 2
    Question for this paper: implementation of DSLs takes two forms according to the paper: on top of a language and within a language. Compare these two by discussing advantages of the one over the other (and vice versa). Which form would you choose, and why?

  • E. Dolstra, M. de Jonge and E. Visser. Nix: A Safe and Policy-Free System for Software Deployment. In L. Damon, editor, 18th Large Installation System Administration Conference (LISA '04), Atlanta, Georgia, USA, November 2004. USENIX. Deadline: 23 Oct 2006, 23:59, Submit code: paper review 3
    Question for this paper: The LISA paper doesn't explicitly say it, but the way things are built in Nix is purely functional: the result of a build action only depends on its explicitly declared inputs, and build results do not change after they have been built. Given what you know about purely functional languages such as Haskell, can you think of some advantages and disadvantages of such an approach?

  • D. Hovemeyer and W. Pugh. Finding Bugs is Easy, ACM SIGPLAN Notices, December 2004. Deadline: 6 Nov 2006, 23:59, Submit code: paper review 4
    Question for this paper: FindBugs? is tailored to Java. Consider a different programming language you happen to know and 1. indicate two categories of bugs that apply to that language as well, and 2. give two new kinds of bugs for that programming language (in other words, they do not apply to Java).

Some examples for inspiration

Elmar Keij handed in a paper review for the first of the four papers, that obtained a perfect score of 10. (this does not mean that his work is totally without mistakes and cannot be improved upon!) He has kindly allowed us to put his work on the site to serve as a source of inspiration. Download Elmar Keij's paper review