Software Engineering Group

Open and Running Theses

  Thema Betreuer
  Abschlussarbeiten im Kontext des Open Source Projekts Kieker Monitoring Framework: siehe auch Liste der offenen Themen kieker-logo
Konstruktion und Evaluation eines Code-Generator-Ansatzes mit CoCoME Reiner Jung
Vergleich von Modell-basierten Pointcut-Spezifikationsansätzen Reiner Jung
Entwicklung einer Methode zur Bestimmung der Trace-Funktion eines Code-Generators Reiner Jung
  Dynamic Software Quality Metrics Henning Schnoor
Konzeption und Implementierung eines Systemabhängigkeitsgraphen für C#/C++-Applikationen auf Basis des Quelltextes Christian Wulf
  Transformation von Neo4J-basierten Systemabhängigkeitsgraphen zu C#/C++-Code Christian Wulf
  Improving the Performance of P&F Architectures by Using Stage Meta Data Christian Wulf
open Compare TeeTime with Other Frameworks (Bachelorarbeit)
(with Apache Storm, Apache MapReduce, Apache Spark, ...)
Christian Wulf
  Automatic Field Privatization using PARROT Christian Wulf
open Automatic Annotating Class State Properties using PARROT
(@Cache, @FileAccess, @NetworkAccess, @ReductionVariable, @Immutable)
Christian Wulf
  Pattern Mining in Open Source Apps for Parallelization Christian Wulf
  Metrics for Detecting Parallelism Potential in Source Code
Christian Wulf
  A Hardware-Sensitive Performance-Test Framework for Java
(Assertion for Time Intervals, Hardware-based time interval, automatic Hardware detection, JUnit report file)
Christian Wulf
  Automatic Detection of Design Patterns via Static & Dynamic Analysis
(Observer, Strategy, ...)
Christian Wulf
  Automatic Detection of Performance Anti-Patterns via Static & Dynamic Analysis
(Accessive dynamic allocation [of strings], Memory leaks: less frees than mallocs, ...)
Christian Wulf
open A Java Code Generator for System Dependence Graphs (Bachelorarbeit) Christian Wulf
  Automatic Detection of Parallelizable Arrays using PARROT
(Annotating with do-all/do-across)
Christian Wulf
open Add Support for ASM/Javassist-based Instrumentation to Kieker
(required for record pooling)
Christian Wulf
  Add Performance Testing Support to TeeTime's Continuous Integration Infrastructure
(Benchmarks, performance tests, JMH, Jenkins)
Christian Wulf
open Model-Driven Probe Generation for Kieker
(Reconstruction of Eclipse Plugin Architecture, IRL/IAL, ...)
Christian Wulf
  Adding Java 7 and 8 Support for PARROT
(using ExtendJ, evaluate with several open-source programs)
Christian Wulf
open Integration of Kieker Monitoring in ExplorViz Christian Zirkelbach


Die obige Liste an Themen ist nicht erschöpfend. Für weitere Themen wenden Sie sich bitte direkt an die jeweiligen Mitarbeiter.

Außerdem sind eigene Vorschläge Willkommen!

Running Theses

Thema Betreuer des Themas Bearbeiter
Performance Testing in Continuous Integration Environment
(improve RadarGun, improve Visualization in Jenkins, JUnit report, ...)
Christian Wulf abar
Automatic Refactoring with the Null Object Pattern using PARROT Christian Wulf tnr
(Master's Thesis) Analyse der Microservices eines digitalen Marktplatzes mittels ExplorViz Christian Zirkelbach fei
(Master's Thesis) Eye Tracking Based Experiments in ExplorViz Christian Zirkelbach mak
(Bachelor's Thesis) Kollaboratives Erkunden von Software mithilfe virtueller Realität in ExplorViz Christian Zirkelbach tha
(Bachelor's Thesis) Erkundung von Softwarelandschaften mithilfe von HCI in ExplorViz Christian Zirkelbach mmoeller
(Master's Thesis) Architecture Conformance Checking for Software Landscapes in ExplorViz Christian Zirkelbach thackel

Student Theses

Useful Hints

Hinweise für das wissenschaftliche Schreiben


Vorgehen und Hinweise für Seminararbeiten


Vorgehen und Hinweise für Abschlussarbeiten


Latex-Vorlage (deutsch und englisch) für Proposals, Abschlussarbeiten und Präsentationen

Link zu den Vorlagen


Was hat ein Proposal mit einem Entwicklungsprozess zu tun?

Grundsätzlich spielt der Entwicklungsprozess eine zentrale Rolle in der Softwaretechnik. Daher geben wir hier einige Hinweise zum Entwicklungsprozess bei der Betreuung von Abschlussarbeiten in der Arbeitsgruppe Software Engineering.

Prinzipiell kann das Verhältnis zwischen Arbeitsgruppe und Studentin/Student mit dem Verhältnis zwischen Kunden und Software-Häusern verglichen werden. Daher wird im folgenden die Studentin/der Student als Software-Haus und die Arbeitsgruppe als Kunde bezeichnet.

Zunächst wird eine ca. einseitige Anforderungsbeschreibung durch den Kunden erstellt (entspricht einem Aushang). Dann schreibt das Software-Haus ein Pflichtenheft (entspricht dem Proposal für das Abschlussarbeitsvorhaben). Dieses Pflichtenheft muss vom Kunden abgenommen werden. Nach Ablieferung des Produkts (entspricht der Abgabe der Abschlussarbeit) wird dieses gegen das Pflichtenheft geprüft und beurteilt (entspricht der Note).

Der Vorteil eines expliziten Pflichtenheftes besteht für das Software-Haus darin, dass es klar sein sollte, was genau zu tun ist, damit das Produkt fertig ist. Der Kunde kann dann nicht noch nachträglich weitere Anforderungen stellen. Für den Kunden besteht der Vorteil darin, zu wissen, was von der Arbeit zu erwarten ist.

Bekanntermaßen ist dieses starre Vorgehen natürlich nicht praktikabel, so dass es gelegentlich zu Neuverhandlungen bzgl. der im Pflichtenheft festgelegten Ziele kommen kann.

Guidelines for seminars and student theses

If you have any comments, questions or additions, please contact Willi Hasselbring

Fundamentally, these guidelines apply to any scientific work conducted in the Software Engineering Group (and many hints apply to (scientific) writing in general), whether you write a seminar paper, an individual project / Bachelor thesis, or a Diploma/Master thesis. These differ primarily in the amount of time available, the expected length of the text and of the degree of novelty of the work. In the following, we will refer to any piece of work as a “paper”. These are only general guidelines, in specific seminars or for your specific thesis, additional or different guidelines may be arranged.

Guidelines for writing a paper or thesis


Please follow the following coarse-grain structure:

  1.     Title page containing topic, author, name of university, school, department and group, supervisor(s), date
  2.     Abstract
  3.     Table of contents
  4.     Introduction, making clear motivation and explaining structure of paper
  5.     …
  6.     Conclusion, incl. critical reflection
  7.     Bibliography


Citing URLs

URLs should not be put into the text, but should rather be included as a footnote or in the bibliography. If the cited page is not another kind of document (e.g. a technical report), use the BiBTeX misc entry type. When you use a bibliography style that recognized the BiBTeX url field, put the URL into this field (otherwise the howpublished field of the misc entry type and the note field of other entry types may be used, in these cases put the url into a url{...} command. Please give the date of last access in the note field, or, if your BiBTeX supports it, in a dedicated field (e.g. lastchecked). Please use the DIN/EN 28601 date format YYYY-MM-DD.

Format (technical and layout requirements)

You should write your paper using LaTeX and BiBTeX. It is expected that you deliver the sources (including a BiBTeX .bib file) and a PDF version of your paper. You should not normally try to fiddle around with the layout LaTeX produces.

You can use the latex template provided at for your paper.


For including graphics in your paper, you should use vector graphics (unless, of course, it is a screenshot or photo or the like) in the EPS or PDF format (caution: it is also possible to store bitmap graphics in these formats). Always put graphics into a figure environment, provide a proper caption and let LaTeX place the figure.

Literature search

The literature given by us is only considered as a starting point for your work. It is expected that you search for additional relevant literature on your own. The links given in the references for scientific work may help you.

Spell checking

Before submitting any version of your paper, use a spell checker!

Evaluation criteria

Your paper will be evaluated particularly for the following criteria.

  •     Originality (depending on the type of work)
  •     Understanding (you should make clear that YOU have understood the material presented)
  •     Understandability (it should be possible for others with an appropriate background, i.e. another CS student, to understand what you have written)
  •     Linguistic presentation (clear, systematic, stringent, understandable)
  •     Soundness
  •     Appropriate level of detail and overall length
  •     Grammatical and orthographical correctness
  •     Consistent use of terminology
  •     Technical presentation (layout, carefulness)
  •     Critical analysis of cited sources
  •     Independent work


Guidelines for conducting a presentation

General hints

You can prepare summary notes for yourself, but you are expected to talk freely. You should calcute 2 to 3 minutes time per slide. You should practise your talk in front of someone you know before the actual presentation. In this way, you can check if you know what you want to say for each slide, and your auditor can check if there is a main thread, most importantly, and give general comments on your presentation.


  •         Use the same general layout for all slides. Use a simple, clear layout.
  •         Use landscape orientation.
  •         Font size: at least 18pt
  •         Font family: use a Sans Serif Font (Verdana, Arial, Optima, Computer Modern Sans, …)
  •         Do not show more than 7 items in a list on slide. Do not show entire sentences.
  •         If possible, use graphics rather than text to present your content.



    The structure of the talk should be as follows:

  •         Title slide: Topic, Presenter
  •         Outline
  •         …
  •         Summary

    The talk should end with the summary slide, not with an additional “Questions?” slide, so the audience has time to read your summary while preparing questions. The coarse outline should either be visible on each slide in a small scale, or you should get back to the outline when switching between major parts of your talk, so the audience knows in which phase of your talk you are.

Scientific Work


Please also have a look at the guidelines for seminars and student theses in the Software Engineering Group.


Literature search

  • Citeseer (BiBTeX (must be used with great care), Fulltext, Citation)

  • Web of Science (Citation) (only from licensed IP addresses)

Some advice to pursue a PhD project

  • Advice for Finishing that Damn Ph.D. (PDF) by Daniel M. Berry


Publication venuesty

LaTeX and BiBTeX information

  • LaTeX help web pages, University of Florida (LaTeX and BiBTeX, HTML)


Some hints for (scientific) writing

  • James G. Paradis, Vanessa Zimmerman: “The MIT Guide to Science and Engineering Communication” – 2. edition. – Cambridge: The MIT Press, 2002. ISBN 0-262-66127-6. BIS nat 397 CO 3896,2. (in particular chapters 1, 3-6, 8-9, presentations: particularly ch. 15)

  • Fred D. White: “Communicating Technology: Dynamic Processes and Models for Writers” – Pearson Higher Education, 1996. ISBN 0-06-500508-2. (particularly chapters 6-7, focus on English language: chapters 8-9)


Specific English language information

  •  Michael Swan: “Practical English usage”. – 2. edition. – Oxford [u.a.] : Univ. Press, 1995. ISBN 0-19-431198-8 (hb) 0-19-431197-X (pb). BIS: S ang 201 LR 4083,2,1995,2 and N ang 201 BL 4116,2,1995,2 (hints on English language use, especially for non-native speakers)

Giving a talk/presentation


Reviewing a manuscript

  •     Alan Jay Smith, “The task of the referee,” IEEE Computer, April 1990, pp. 65-71, DOI 10.1109/2.55470 (PDF)


Upcoming Events

Research Projects

  • more...

     ExplorVizLogo160x37[1].png    iobserve-logo-small    CloudMIG Xpress


    Future-Ocean-logo    kieker-logo       PubFlow


    teetime-logo   SpratGeRDI