Home
Education Page
Contact
Description
Literature
Course Schedule
Assignments
Paper Reviews
Exam
Paper Reviews

Swe
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_.

%TOC%

----++ 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 [[%ATTACHURL%/citecloneandcopy.pdf][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 [[http://www.cs.uu.nl/docs/submit][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: an experiment in Chain Automation.

In this task, you are expected to read material written by prof. J. Grijpink on the subject of _chain automation_ (ketenautomatisering).
Use [[http://www.cs.uu.nl/docs/submit/][Submit]] to hand in your review as opgave *Chain automation*. The deadline for this assignment is *5 Oct 2009, 23:59*.
Specific details on this task can be found [[ChainAutomationPaperReview][here]].
-->

----+++ 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.<br/>
Deadline: *Fri 24 Sep 2010, 23:59*.<br/>
[[http://www.cs.uu.nl/docs/submit/][Submit code]]: *tool review*.<br/>

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 [[http://www.cs.uu.nl/docs/vakken/swe/quickcheck-anon.pdf][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][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.<br/>
Deadline: *Fri 29 Oct 2010, 23:59*.<br/>
[[http://www.cs.uu.nl/docs/submit/][Submit code]]: *second review*.<br/>

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&#8211;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&#8211;221, 1980.
   * _No Silver Bullet: Essence and Accidents of Software Engineering_ by Fred J. Brooks, Jr. Computer, 20(4):10&#8211;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.


<!--
   * _The Cathedral and the Bazaar_ by E.S. Raymond, First Monday, 3, 3, Marck 1998.

-->