Navigation auf uzh.ch
Software requires constant evolution due to changing customer needs, bugs that have to be fixed or changes in the environment. This has been formulated in Lehman’s first law of software evolution, which states that a software system must be continuously adapted, or it becomes less and less useful. This constant change poses many challenges, for instance, on the reliability of the software as well as on the software developers that continuously have adapt. Both researchers and practitioners have recognized the importance to study and support software evolution and the humans involved in the process. In this seminar, we will cover some the most relevant studies, approaches and techniques that researchers have looked at in this context.
This course will be a combination of the traditional writing and presenting of a report on a chosen topic, as well as three sessions in the beginning of the term to discuss some research undertaken on each of the seminar topics. The three sessions will already cover research articles that can be used in the seminar report as well and should provide you a good start for writing the report. Short response papers for each of these sessions will also be required by each student to ensure the papers were read and stimulate an interesting discussion in class.
Last update: 15.05.2017 (updated presentation guidelines)
Lecturer: | Prof. Dr. Thomas Fritz |
Assistant: | André Meyer |
Time and Place: | Kick-off meeting: February 20, 2017, 12:15h, Room 1.D.29 |
Language: | English |
AP (ECTS): | 3 points |
Target Audience: | BSc Informatics and MSc Informatics Students |
Prerequisites: | Software Engineering |
Registration: | Registration for a topic at and after the kick-off meeting & Modulbuchung |
All dates of attendance and deadlines are mandatory.
Date and Time | Topic / Deliverable | |
---|---|---|
February 20, 2017, 12:15 - 13.45, room 1.D.29 | Kick-off meeting | |
February 23, 2017 (at the latest by midnight) | E-mail with 3 topic preferences for the report | |
February 24, 2017 | Topic assignment for the report | |
Part 1: Group discussions of topic 1-6 | ||
February 27, 2017, 12:15h - 13.45h, room 1.D.29 |
Mandatory class discussion of topic 1 and 2 |
|
March 6, 2017 | no class | |
March 13, 2017, 12:15h - 13.45h, room 1.D.29 | Mandatory class discussion of topic 3 and 4 (response paper due by email to André, the latest at midnight March 12) |
|
March 20, 2017, 12:15h - 13.45h, room 1.D.29 | Mandatory class discussion of topic 5 and 6 (response paper due by email to André, the latest at midnight March 19) |
|
Part 2: Report on one of the topics, reviews and presentation of final report | ||
April 6, 2017 (at the latest by midnight) | Submit a list of selected research articles for the report and a rough outline/structure | |
April 10 or 12, 2017 | Mandatory meeting for early feedback on selected research articles and report structure | |
May 1, 2017 (at the latest by midnight) | Submit report for review submission site |
|
May 3, 2017 | Reviews start review site |
|
May 10, 2017 (at midnight) | Reviews end | |
May 11, 2017 | Notification | |
May 22, 2017 (at the latest by midnight) | Corrected report submission submission site |
|
May 29, 2017, from 9:30h - approx. 13.00h (depends on number of students), room 1.D.29 | Mandatory presentation Day |
For the final grade we will take the following aspects into account:
This seminar has two components, a set of three paper discussions in class and a written report:
For the first three Mondays after the kick-off, we will have a class to discuss two topics per week. For each week, students have to read the main paper of each topic (i.e. two papers for the two topics per class) and find a third paper that is related to the topics. Students will have to read the papers and write a short and concise response paper on the three papers (less than a page long!). In class, we will then discuss the research, opinions and reflections on the topics. This will provide students a good introduction to their selected topic and help to understand what is important in a paper, what others think about the papers, and how to find relevant related work.
Starting from the listed published research articles and the ones discussed in class, the students have to undertake a critical review of the topic assigned and write a report on it. The structure and content of this report is left open-ended, however the students, need to make sure they:
The report has then to be submitted for reviewing through the seminar Easy Chair page (for more information please refer to the `Delivery' subsection of this page). The report will then go through a first review phase (blind review), done by the teaching assistant and 2-3 other students. Every participant has to review two to three other participants' reports. The goal of this first review is to provide and gather some useful feedback on the report, which should then be used to improve and modify the report accordingly and submit it for the second and final time. At the end, the participants will have to present their work on the presentation day.
At the end of this course, students should be able to:
Topic (discussion date) | Title | Main Paper | Additional Paper (*) |
---|---|---|---|
1 (Feb. 27) | Productivity/Efficiency | Developer's Perceptions of Productivity, Meyer et al., FSE'14. (Link) | Using a defined and measured Personal Software Process Humphrey, W.S. IEEE Software. (Link) |
2 (Feb. 27) | Interruptions, Flow and Fragmentation | A diary study of task switching and interruptions, Czerwinski et al. (Link) | No Task Left Behind? Examining the Nature of Fragmented Work; Mark et al. (Link) |
3 (Mar. 13) | Code Quality | Use of relative code churn measures to predict system defect density. Nagappan and Ball; ICSE'05. (Link) | Risky files: an approach to focus quality improvement effort; Mockus, Hackbarth, Palframan; ICSE'13. (Link) |
4 (Mar. 13) | Testing | Coverage is not strongly correlated with test suite effectiveness; Inozemtseva and Holmes; ICSE'14. (Link) | The art of testing less without sacrificing quality; Herzig et al; ICSE'15. (Link) |
5 (Mar. 20) | Code Summarization | Towards automatically generating summary comments for Java methods; Sridhara et al. ASE'10. (Link) | Improving automated source code summarization via an eye-tracking study of programmers; Rodeghero et al; ICSE'14. (Link) |
6 (Mar. 20) | Socialness of Software Development | Embodied Social Proxy: Mediating Interpersonal Connection in Hub-and-Satellite Teams; Venolia et al. (Link) | Software Engineering at the Speed of Light: How Developers Stay Current using Twitter. Singer et al.; ICSE'14. (Link) |
7 (**) | Biometrics in Software Engineering | Understanding Understanding Source Code with Functional Magnetic Resonance Imaging, Siegmund et al., 2014. (Link) | Using psycho-physiological measures to assess task difficulty in software development. Fritz et al.; ICSE'14. (Link) |
(*) The additional paper is listed to give you some context. Don't take one of these as the additional paper for the response papers.
(**) These papers are not covered in the discussions and response papers in the first three weeks. But you can chose these topics for your report if you want.
Hint: To access the papers which are hosted on ACM or IEEE, you need a subscription, which is provided by the university. Download the papers when you are connected to the university Wi-Fi (UZH, eduroam doesn't work) or via VPN.
Each student writes three response papers, one for each week of part 1. The response paper is a short and concise (no more than 1 page) reflection of the main paper for each topic and one additional paper, which fits the given context of research. This additional paper can be identified from related work (an introduction into how students can find related work will be given in the kick-off and a summary can be found below).
On the 27.2., we will discuss topic 1 and 2, on the 13.3. we will discuss topic 3 and 4, and on the 20.3., we will discuss topic 5 and 6. The response paper in PDF-form should be delivered via email to Thomas Fritz and André Meyer at midnight the day before the in-class discussion of each topic.
Below you can find very good response papers from the previous years:
Response Paper 1 (PDF, 152 KB)
Response Paper 2 (PDF, 184 KB)
The written report represents the second part of the seminar. It has to be 9-11 pages long (not counting the cover sheet, the table of contents, the reference list and the word of honor) and in the Lecture Notes in Computer Science format. Both the Microsoft Word ("word.zip") and LaTeX format ("llncs2e.zip") are available here for downloading, even though we strongly suggest anyone to use the LaTeX format. Eventually the report will have to be delivered as PDF on the submission site.
Each student should investigate and cite at least 7-11 papers from related work in the report in addition to the 2 papers provided by us.
Please pay attention to the tips in the format template, in particular:
Below you can find two very good reports from a previous seminar that you can use as blueprints while writing your report:
Do not forget the word of honor, declaring that you worked independently and did not plagiarize.
For any other question or doubt please contact Thomas Fritz.
This section describes how students can find useful related work on popular libraries. The following links are useful for finding the additional paper for your three response papers in part 1, as well as finding relevant papers for part 2:
The ACM Digital Library, IEEE Digital Library, Citeseer and GoogleScholar are very good online catalogues for technical literature search. Both the ACM and the IEEE publications can be downloaded for free from within the Uni Zürich domain.
Another good starting point are the proceedings of major conferences, such as:
Finally, the provided papers often cite relevant related work in the references section.
The report of each student goes through a first review phase, done by 2-3 other students. The goal of this first reviews is to give some useful feedback on the report, which should then be improved and modified accordingly.
The reviews take the following criteria into account:
Grade each report according to one of the following options:
Every participant has to review two to three other participants' reports. The whole reviewing process (the reports and their subsequent reviews submission) will be done through the EasyChair online platform. An email with all the necessary instructions will be sent after the seminar kick-off.
Below you can find some examples of good reviews from previous years:
The following are grading criteria/guidelines for the final report and the presentation (this is not a complete list, rather a list of hints):
5.50 - 6.0 : An excellent work
5.0 - 5.50 : A high quality work
4.0 - 5.0 : A good work with just a couple of small weaknesses
3.0 - 4.0 : An average work with clear weaknesses
0 - 3.0 : Insufficient work with many substantial weaknesses