Paper Reviews

In this course you are expected to perform two ''studies'' in the area of software engineering and to report on these. Contrary to the practical assignments you should perform these by yourself.

Reviews

General

Generally speaking the tasks are similar: we expect you to show your understanding of the reading material by explaining what you are about to do in your paper, answer any concrete questions as fully as possible, perform concrete tasks proposed by us below, and try to contribute original thought.

Use your own words! Copy and paste without citation (even small parts) is plagiarism and therefore punishable. Start by reading my presentation, Cite, Clone And Copy on the subject. If you have still have questions, talk to me or send me an e-mail. Even if you do put citations with everything you copied and paste, make sure you do not cite too much: you will not obtain a passing grade if all you did was selecting the right parts of another paper. We use a plagiarism detection tool to make sure no text was copied from other sources.

Note that some of the papers are available from the ACM digital library or other libraries for which access needs to be paid for; these papers can be downloaded from a computer at the University or through VPN.

Note that this is a master course, and therefore everything you hand in must be written in English.

If you are not convinced of your quality as a writer, make sure others read your work before submitting. In return, you can help them correct their work. Use a spell checker to get rid of blatant typos. Failing to do so, may be severly punished.

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

Grading

For each review you obtain a single grade which is determined

• the quality of the content and your understanding (40 percent). Depending on the particular assignment, content and understanding can be your description and comparison of tools, or the answers to the questions that we pose.
• the quality and quantity of original thought and contribution (20 percent)
• how well the piece is written, e.g., structure, style, spelling and grammar, bibliographical details (40 percent)

If the paper is too short or too long, points can be subtracted.

The first task: a tool review

In this task, you are expected to read one or two papers, manuals, forums about a particular tool, to install and obtain practical experience in using the tool, and to describe your findings.

Length: between 1750 and 3500 words.
Deadline: Fri 24 Sep 2010, 23:59.
Submit code: tool review.

You are not allowed to evaluate the following tools: SVN, Darcs, Valgrind, make, Ant, CVS, Mock Objects, AspectJ, JUnit.

A sample tool review from last year can be found here. Note that this review is somewhat shorter and therefore less comprehensive than what I expect from you, because last year the lower and upper bound in number of words as lower.

The best way to approach the task is to assume you were given this task by a manager, and to explain your findings to your fellow programmers in the virtual team you are working in. Your work should also contain a recommendation to that manager, preferably in a language that he might understand. Be explicit as to who should read what. Including comparisons to tools with a similar goal can serve well to distinguish yourself from other sources on the web. In your evaluation it should show that you have played with the tool. For that reason you may want to include snapshots that you made yourself to illustrate how the tool can be used. So first make sure that you can indeed play with a tool, before investigating it. Not being able to try a tool for whatever reason can never be an excuse for failing to tell us about your experiences with the tool.

Consider the tool according to the following list of criteria.

• suitability for the project in question - how well is it suited for the particular task at hand?
• stability and maturity - how complete and stable is the tool?
• expressiveness, power - what does the tool allow you to do?
• steepness of learning curve - how much time does it take to obtain reasonable results?
• usability - how easy to use is it?
• extensiveness of support and quality of documentation - is there off-line or on-line support (for sale)? What about paper documentation?
• cost - how much does it cost, if anything?
• license restrictions - what kind of licensing restrictions exist?
• performance - can we expect it to deal sufficiently well

Some suggestions for tools can be found below, but I prefer that you find other tools to consider. If you are unsure about whether a tool is suitable, contact me.

• Code analysis:
  • gprof
  • lint
  • FindBugs
  • SemmleCode
• Testing:
  • QuickCheck
• Refactoring:
  • Hare
• Abstractions
  • Hibernate
  • Linq

Second paper review: what where they thinking?

Length: between 1000 and 1500 words.
Deadline: Fri 29 Oct 2010, 23:59.
Submit code: second review.

Research is known to take about 30 years to mature before companies and the like start to take advantage of them. Consider the manager who recently heard through the grapevine that someone or other wrote article that showed that adding people to a late project makes it later. Now, instead of simply going back to that article, it may be wiser to find out what people (currently) think of that particular paper.

The topic of the second assignment is to take a ``classic'' paper that is at least a few decades old, and to find at least two, but preferrably three peer-reviewed papers (the more recent the better) that discuss this paper in an essential way. These papers might contradict, generalize or make more precise/concrete what was written down in the classic paper (and it would be great if you can find examples of all three). Your task is then to summarise the essentials of the classic paper (if necessary, restricting yourself to the part that the papers you found refer to), and describe the relation with the other three papers in the remaining. You may use between 1000 and 1500 words. It is essential that you include a url that links to the (pdfs of) the articles that you use in your comparison, as visible in for example Google Scholar, Citeseer or ACM Portal.

Below is a list of classic papers, chronologically ordered, to select from. You may not choose your own classic paper.

• The next 700 programming languages by Peter Landin. Commun. ACM 9, 3, 157-166, 1966.
• Go To Statement Considered Harmful by Edsger W. Dijkstra. Communications of the ACM, 11(3):147–148, March 1968
• On Understanding Laws, Evolution, and Conservation in the Large-Program Life Cycle by Meir M. Lehman, Journal of Systems and Software 1: 213–221, 1980.
• No Silver Bullet: Essence and Accidents of Software Engineering by Fred J. Brooks, Jr. Computer, 20(4):10–19, April 1987

Hierarchical Program Structures

• Hierarchical Program Structures by Ole-Johan Dahl, C. A. R. Hoare, pp. 15-220 of Dahl, Dijkstra and Hoare (eds.), Structured Programming, Academic Press, London and New York, 1972.