Seminar in Advanced Software Engineering, FS 14

Software requires constant evolution due to changing customer needs, bugs that have to be fixed or changes in the environment. Both researchers and practitioners have recognized the importance to study and understand the several aspects of software evloution and how to best support the human therein. A variety of approaches and ideas has been suggested to support the change and developer, ranging from language extension to allow for easier adaption of certain features in the code, approaches to locate concepts in the source code and support developers in the change task management to increase their productivity, all the way to analytics approaches to monitor and evaluate the constant change. This seminar will cover some the most relevant approaches and techniques.

The following list shows possible topics, but is only tentative for now and will be adapted.

• Supporting Crosscutting Concerns
  Selected papers:
  • Aspect-Oriented Programming
  • N degrees of separation: multi-dimensional separation of concerns
  • Concern graphs: finding and describing concerns using structural program dependencies
• Code Recommendation
  Selected papers:
  • Using structural context to recommend source code examples
  • Mining Version Histories to Guide Software Changes
• Concept Location and Code Search
  Selected papers:
  • Feature identification: a novel approach and a case study.
  • Where should the bugs be fixed? More accurate information retreival-based bug localization based on bug reports.
• Tool Support for Tasks/Bugs
  Selected papers:
  • Using Task Context to improve programmer productivity
  • Who should fix this bug?
  • Summarizing Software Artifacts: A Case Study of Bug Reports
• Software Quality Tools
  Selected papers:
  • Tools for Continuously Evaluating Distributed-System Qualities
  • Change Analysis with Evolizer and ChangeDistiller
  • Yesterday my program worked today it does not. Why?
• Refactoring
  Selected papers:
  • A survey of software refactoring
  • How we refactor and how we know it
  • Automated Testing of Refactoring Engines
• Software Architecture
  Selected papers:
  • Using Software Evolution to Focus Architectural Recover
  • ArchJava: connecting software architecture to implementation
  • Software Reflexion Models: bridging the gap between source and high-level models
• APIs
  Selected papers:
  • What Makes APIs Hard to Learn? Answers from Developers
  • How to Design a Good API and Why It Matters
• Developer's Needs and Practices
  Selected papers:
  • Information Needs in Collocated Software Development Teams
  • Maintaining mental models: a study of developer work habits
• Human Aspects in Software Development
  Selected papers:
  • Understanding Source Code with Functional Magnetic Resonance Imaging
  • An Eye-Tracking Methodology for Characterizing Program Comprehension Processes

Starting from the given published research, 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:

• clearly explain the subtopic selected,
• review and summarize the current state of the art,
• critically analyze research articles they present,
• reflect on the impact of the subtopic they studied on the broader topic of the seminar and on software engineering in general,
• elaborate on the application of the techniques and ideas found in the surveyed research to novel cases, topics, etc.,
• reflect on possible future directions.

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 give some useful feedback on the report, which should then be improved and modified accordingly and submitted for the second and final time. At last, the participants will have to present their work on a special presentation day.

For the final grade we will take into account:

• the written report (50% of the grade)
• the presentation of the report(30% of the grade)
• the reviewing of the other participants' work (15% of the grade)
• the active participation in the presentation day (5% of the grade)

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

- the report represents works of an exceptional standard. It is a highly articulate and professional document and includes critical comments with extended justification. The author demonstrates initiative and originality in analysis or interpretation.

- the presentation is comprehensive and highly professional. The discussion is integrated into a logical, coherent whole. It tells a story and leads logically into the research presented.

5.0 - 5.50 : A high quality work

- the report is of a superior standard. It is well written, free of errors and includes coherent critical comments with substantial justification. The author demonstrates complex, deep understanding of the subject.

- the presentation is effective and comprehensive.

4.0 - 5.0 : A good work with just a couple of small weaknesses.

- the report is complete, well structured and well presented. It is written in a clear style that communicates points effectively on first reading. It includes coherent critical comments with justification based on evidence. The author has some tendency to summarize literature then develop an integrativ and logical argument.

- the presentation identifies and defines the main issues in a clear yet somewhat simplistic way.

3.0 - 4.0 : An average work with clear weaknesses.

- the report addresses the main themes but does not integrate or relate key ideas and issues efficiently. It is presented in an organized manner but may have style and expression irregularities that do not intefere with the meaning. It provides some basic critical comments that reflect a basic understanding of key issues. However, the the minimal critical analysis attempted lacks in depth and/or is confused. The author demonstrates the the literature in the field has been checked.

- the presentation is essentially descriptive and features minimal critical analysis. The main themes are presented but not well integrated. The author fails to tell a story.

0 - 3.0 : Insufficient work with many substantial weaknesses.

- the report does not address the main themes, is disorganized, incoherent or reveals evidence of plagiarism. It provides little or no critical comments.

- the presentation is disorganized, incoherent and fails to effectively describe the topic.

At the end of this course, students should be able to:

• explain the selected subtopic and area of research,
• critically analyze research articles (especially on the selected subtopic),
• review and summarize the current state of the art of the selected subtopic,
• reflect on the impact on the broader topic of the seminar and on software engineering in general,
• apply techniques and ideas found in the surveyed research to novel cases,
• reflect on possible future directions,
• provide constructive feedback on a research report.

Written Report

The written report represents the first task of the seminar. It has to be 12-15 pages long (not counting the cover sheet, the table of contents and the word of honor) and in the Lecture Notes in Computer Science format. Both the MS 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.

Please pay attention to the tips in the format template, in particular:

• the correct structure of a scientific research article,
• the right use of figures and tables,
• the correct citation of other works.

Below you can find two very good seminar reports of the past year that you can use as blueprints while writing your report.

Report 1 (PDF, 543 KB)

Report 2 (PDF, 225 KB)

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.

Literature Search Pointers

Each student should investigate and cite at least 7-10 articles in his/her own work (i.e. in addition to the 2 to 3 provided by us).

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:

• International Conference in Software Engineering (ICSE)
• Symposium on the Foundations of Software Engineering (FSE)
• International Conference on Automated Software Engineering (ASE)
• Working Conference on Mining Software Repositories (MSR)
• International Conference on Program Comprehension (ICPC)
• International Conference on Software Maintenance (ICSM)

Review Guidelines

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:

• Technical quality (critical analysis of the topic)
• Logical structure (the structuring of the work)
• Presentation (the use of graphics and tables)
• Style (orthography and typos)
• References (significant selection of relevant literature)

Grade each report on a scale from 0 to 6 (with minimum increments of 0.25):

• 5 - 6: An excellent work.
• 4 - 5: A good work with just a couple of small weaknesses.
• 3 - 4: An average work with clear weaknesses.
• 0 - 3: Insufficient work with many substantial weaknesses.

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.

Delivery

The delivery website (Easy Chair) can be found here.

You will have to create a new user account in EasyChair and then you can easily upload your report with the appropriate menu option. (EasyChair is the standard used for the submission and reviewing process for research conferences.)

Presentation Day

All the participants will present their work on a special presentation day (May 9th, from 09:00, room BIN 1.D.07).

Every presentation consists of a 15 minutes talk followed by a 10 minutes discussion.

All participants need to have the presentation in electronic format (MS Powerpoint, Apple Keynote or slides in PDF/PS). We provide both a beamer and a laptop to be used (in case you don't want to use your own laptop).

Attendance to all the presentations is mandatory. Exceptions are made only if a proper, official excuse (e.g. doctor's excuse note) is given.

Presentation Guidelines

• Make sure that your talk includes enough background material and motivation so that it can be understood by those who are not specialists in what is being presented.
• Design your slides using large text and diagrams such that they can be read by anyone in the room. The person far away in the corner may be the one with central insights to your work, so make sure he/she gets the message, too.
• Do not place text on the slides that you will speak aloud anyway. The audience will read the text faster than you speak, and continuously experience lags. Slides and spoken word should support each other, and not be redundant representations of each other.
• Modern presentation programs can switch the laptop screen in presenter mode, showing the upcoming slides or presenter notes. Make use of these tools to ensure fluid transitions between slides and a smooth information flow.
• Spend at least one slide to clearly motivate your work, explicitly stating the problem you are addressing.
• Spend at least one slide on related work, such that the audience can place your work in a greater context.
• Do not end with a slide saying nothing but "Thank you!" or "Questions?" Instead, on the last slide, summarize your talk (problem, approach, results). Have this slide stay on the screen during the discussion; people will be able to recall your talk and provide insightful questions and comments.
• Presentations are allotted 25 minutes: 15 minutes for talk, 10 minutes for questions & answers. These limits will be strictly enforced.