Personal tools

Tipps zum Schreiben von Konferenzpapieren

From Wissensbasis

Jump to: navigation, search

Die folgende Seite enthält Hinweise zum erfolgreichen Schreiben von wissenschaftlichen Artikeln, die bei Konferenzen oder Journals eingereicht werden sollen. Diese Auflistung erhebt weder Anspruch auf Vollständigkeit noch auf Allgemeingültigkeit. Diese Tipps basieren auf Erfahrungswerten und haben sich für die Mitarbeiter unseres Lehrstuhls als sinnvoll herausgestellt. Sie dienen dazu, den internen Begutachtungsprozess von Konferenzpapieren innerhalb unserer Gruppe zu optimieren.

Hinweise zu Aufbau und Stil (mit einem Fokus auf Diplomarbeiten) finden sich in dem kurzen und prägnanten Buch Studien-Arbeiten, das in der Uni-Bibliothek verfügbar ist.

Weitere Links:

Zum Schreiben von Artikeln

See English Language Corner for tips and pages related to English grammar and style for non-native (especially German) speakers.

Contents

Aufbau

  • Prinzip der Pyramide: Der Aufbau eines Konferenzpapiers sollte idealerweise dem Prinzip der Pyramide folgen. Das bedeutet, dass der Artikel einen hierarchischen Aufbau verfolgen sollte. Der eigentliche Inhalt des Papiers (Motivation, Inhalt, Ergebnisse) wird in mehreren Iterationen wiedergegeben (z.B. 3), wobei der Abstraktionsgrad bei jeder Iteration sinkt. In hochwertigen Publikationen (z.B. Papieren in IEEE TSE) ist dieses Prinzip deutlich zu erkennen. Dieses Prinzip wird bereits durch Abstract/Introduction induziert und sollte auch im Rest des Papiers weitergeführt werden. Der Vorteil ist, dass es das Verständnis eines komplexen Sachverhalts mit vielen Details wesentlich erleichtert, weil man die Struktur des Vorgestellten besser nachvollziehen kann. Der Leser kann die Details eines Lösungsansatzes besser einordnen, wenn er das Ziel der Argumentation bereits kennt. Auf diese Weise wird auch verhindert, dass ein Konferenzpapier einen Krimi erzählt, bei dem erst am Schluss klar wird, worauf die Autoren hinaus wollten und was das eigentliche Ergebnis der Arbeit war.
  • Abstract: "Abstract", "Introduction" und "Conclusions" gehören zu den meist gelesenen Abschnitten eines Konferenzpapiers und sollten daher mit besonderer Sorgfalt geschrieben werden. Idealerweise enthält ein Abstract die folgenden 5 Punkte. In einem kurzen Abstract sollte zu jedem dieser Punkte genau ein Satz geschrieben werden, mehr nicht. Bei Publikationsformen mit längeren Abstracts können auch zwei Sätze zu jedem Punkt geschrieben werden.
  1. Eingrenzung des Forschungsbereichs (In welchem Themengebiet ist die Arbeit angesiedelt? Wie ist das Verhältnis zum Thema der Konferenz/des Journals?)
  2. Beschreibung des Problems, das in dieser Arbeit gelöst werden soll (Was ist das Problem und warum ist es wichtig dies zu lösen?)
  3. Mängel an existierenden Arbeiten bzgl. des Problems (Warum ist es ein Problem, obwohl sich schon andere mit dem gleichen Thema beschäftigt haben?)
  4. Eigener Lösungsansatz (Welcher Ansatz wurde in dieser Arbeit verwendet, um das Problem zu lösen? Was ist der Beitrag dieses Artikels?)
  5. Art der Validierung + Ergebnisse (Wie wurde nachgewiesen, dass die Arbeit die versprochenen Verbesserung wirklich vollbringt (Fallstudie, Experiment, o.ä.); Was waren die Ergebnisse der Validierung (idealerweise Prozentsatz der Verbesserung)?)
  • Introduction: Die Einleitung dient dazu, den Leser an die eigene Arbeit heranzuführen. Sie sollte sich von allgemeinen Aussagen zum eigentlichen Thema heranarbeiten (hineinzoomen). Die Einleitung sollte so geschrieben werden, dass jeder Informatiker (auch aus anderen Teilbereichen der Informatik) verstehen kann wozu die Arbeit dient. Idealerweise folgt die Einleitung dem gleichen Aufbau (5 Punkte) wie der Abstract, jedoch wird jetzt für jeden der Punkte ein ganzer Abschnitt geschrieben. Der vorletzte Absatz der Einleitung (also nach Abhandlung der 5 Punkte) sollte mit "The contribution of this paper is..." beginnen und die eigentlichen neuen Beiträge der Arbeit (meist 2-3 Punkte) nochmals deutlich herausstellen. Das erleichtert es Gutachtern, im Wust von Motivation, verwandten Arbeiten, Grundlagen usw. das Inkrement bzw. den wissenschaftlichen Beitrag der Arbeit zu erfassen. Der letzte Abschnitt der Einleitung sollte einen Überblick über das Papier geben und jeden Abschnitt des Papiers mit einem Satz beschreiben.
  • Related Work: Eine Auflistung verwandter Arbeiten ist essentiell für jeden wissenschaftlichen Artikel.
    • Position: Bereits in der Einleitung sollte auf die Unzulänglichkeiten verwandter Arbeiten eingegangen werden, um die eigenen Arbeit zu motivieren. In kürzeren Papieren (ca. 8 Seiten) kann man die verwandten Arbeiten schon komplett in der Einleitung abhandeln um Platz zu sparen, in längeren Papieren (ab ca. 15 Seiten) sollte jedoch ein eigener Abschnitt "Related Work" geschrieben werden. Dieser eigene Abschnitt kann entweder vor den eigentlichen Beitrag gestellt werden (also Abschnitt 2 nach der Einleitung), um die Verbesserungen der Arbeit ggü. anderen Arbeiten zu betonen. Alternativ kann dieser Abschnitt auch erst am Ende eines Papier vor den Conclusions auftauchen (z.B. wenn man einen recht neuen Ansatz entwickelt hat, der sich nur schwierig mit anderen Arbeiten vergleichen lässt).
    • Inhalt: In den Abschnitt "Related Work" gehört idealerweise zunächst ein bekannter Überblicks-Artikel zum Themengebiet (z.B. Peformance=Balsamo2004; Reliability=Goseva2001) bzw. ein standard-referenziertes Buch (z.B. SPE=Smith2002, CBSE=Szyperski2002). Damit könn(t)en sich interessierte Forscher einen eigenen Überblick zu verwandten Arbeiten in diesem Themengebiet schaffen, sofern dieser noch nicht vorhanden ist. Es folgt die Auflistung ähnlicher bzw. verwandter Arbeiten. Diese Arbeiten sollten dabei nicht einfach beschrieben werden, sondern immer in Bezug zur eigenen Arbeit gesetzt werden. Idealerweise sollten die Kernverbesserungen der eigenen Arbeit im Verhältnis zu jeder verwandten Arbeit hier herausgearbeitet werden. Auf keinen Fall sollten verwandte Arbeiten unreflektiert aufgelistet werden.
  • Assumptions/Limitations: Es hat sich als positiv herausgestellt die Annahmen und Grenzen des eigenen Lösungsansatzes explizit in einem eigenen Abschnitt zu disktuieren. Dies nimmt 1) den kritischen Gutachtern, die nach Unzulänglichkeiten des Ansatzes suchen, den Wind aus den Segeln. 2) wird die Aufrichtigkeit ggü. den eigenen Schwächen von den meisten Gutachtern eher positiv denn negativ beurteilt und demonstriert eine gewisse Selbstsicherheit des Autors.
  • Conclusions: Die Schlussfolgerungen beenden den Artikel und erhöhen den Abstraktionsgrad der Beschreibung wieder (hinauszoomen), genauso wie die Einleitung diesen gesenkt hat (hineinzoomen). Meist sind "Conclusions" nicht sehr sorgfältig geschrieben, weil sie unter Termindruck entstanden sind und als nicht wichtig erachtet werden. Dieser Praxis sollte nicht gefolgt werden, da viele Gutachter nach "Abstract" und "Introduction" zunächst die "Conclusions" lesen und dann beurteilen, ob sie den ganzen Artikel lesen. Idealerweise bestehen die "Conclusions" aus folgenden 3 Punkte, für die jeweils ein Abschnitt spendiert werden sollte:
  1. Zusammenfassung: Was wurde in dieser Arbeit gemacht? Was waren die Schlüsselergebnisse? Diesmal jedoch zusammengefasst nochmals für einen Leser, der die vorherigen Seiten mit allen Details bereits gelesen hat.
  2. Adressaten der Verbesserung: Wem nützen die Verbesserungen/Beiträge der Arbeit? Inwieweit wird die Software-Technik durch die Arbeit verbessert?
  3. Aufbauende/Zukünftige Arbeiten: Welche nächsten Schritte sind geplant (erst kurzfristige, dann längerfristige)? Welche möglichen Lösungsansätze für noch bestehende Probleme sind denkbar? Wie könnten Folgearbeiten aussehen?

Stil

Sowohl ein angemessener wissenschaftlicher Stil als auch gutes Englisch sind für ein Papier sehr wichtig.

  • Definition von Begriffen: Begriffe, die zentral für den eigenen Forschungsansatz sind, müssen vor ihrer Verwendung definiert werden, wenn man nicht sicher sein kann ob sie jedem Informatiker/Gutachter geläufig sind. Da die Autoren von Konferenzpapieren "ihre" Begriffe alltäglich verwenden, fällt es ihnen oft schwer ein Gefühl dafür zu entwickeln, dass bei Informatikern anderer Fachrichtungen diese Begriffen anders belegt sein können. Typische Beispiele sind die Begriffe "Performance" und "Komponente". Auch wenn in unserer Gruppe der Begriff "Performance" meist mit "Antwortzeit" gleichgesetzt wird, ist dies nicht allgemeingültig. Andere Forscher verstehen unter "Performance" nur "Ressourcenauslastung" oder "Skalierbarkeit". Wieder andere reden von der "Performance" von Aktien oder erachten ein System als "performant" wenn es genügend korrekte Antworten liefert. Der Begriff "Komponente" wiederum ist wahrscheinlich einer der überladensten Begriffe in der Software-Technik. In unserem Kontext sollte daher immer klar gemacht werden, dass wir der Definition von Szyperski folgen und z.B. eine J2EE-SessionBean als Komponente ansehen.
  • Bilder anstatt Text: Abbildungen erhöhen den Verständnisgrad von komplexen Sachverhalten oft entscheidend. Bei langen Textpassagen, sollte man daher überlegen, ob man diesen nicht anschaulich in ein Diagramm fassen kann.
  • Konkrete Formulierungen anstatt abstrakter: Oft sind abstrakte Formulierungen wenig hilfreich für den Leser. Wo möglich sollten immer konkrete Beschreibungen verwenden werden. Beispiele:
    • Nicht: "Our prediction is able to increase the performance of software systems."
    • Sondern: "With our model-based performance prediction method we are able to increase the response times of component-based software architectures during runtime by 10%."
  • Ich/Wir/Man/Passiv: Die Frage in welcher Person ein Konferenzpapier geschrieben werden sollte, ist diskutierbar. Die "Passiv"-Form verschleiert den Handelnden, ist im Englischen eher unbeliebt und sollte in wissenschaftlichen Arbeiten vermieden werden. Die Verwendung von "man" verleitet zu sehr zur Pauschalisierung. Die "Ich"-Form passt nicht zu Konferenzpapieren, die von mehreren Autoren geschrieben wurden. Bleibt die "Wir"-Form, um die Einbettung des Autors in eine Gruppe zu betonen. Aber Achtung: das "wir" sollte im Englischen nur benutzt werden, wenn der Autor tatsächlich das Subjekt des Satzes ist. Oft wird es von faulen Autoren verwendet, die sich nicht über das richtige Subjekt klar sind. Beispiele:
    • Nicht: "In this paper, we show blabla", sondern "This paper shows blabla".
    • Nicht: "We use Petri-Nets to model bla", sondern "Our approach uses Petri-Nets to bla".
    • Richtig: "We have implemented tools to blabla". (Betont, dass die Autoren das tatsächlich eigenhändig gemacht haben)
  • Abgeschlossenheit: Papiere sollten "self-contained" sein, d.h. alle wichtigen Informationen müssen aus dem Artikel gezogen werden, ohne dass andere Artikel hinzugezogen werden müssen.
  • Keine starken Aussagen/Superlative: Autoren von Konferenzpapieren sollten vorsichtig mit zu stark formulierten Aussagen bzw. überhöhten Formulierungen sein. Diese werden selten positiv von Gutachter aufgenommen, sondern erreichen meist das Gegenteil, denn sie provozieren Gutachter nach Argumenten gegen diese Aussagen zu suchen. Negativbeispiele:
    • "This approach is very challenging...": Warum muss das herausgestellt werden? Wenn der Ansatz nicht herausfordernd wäre, würde man sich doch nicht damit beschäftigen.
    • "Model-based predictions show the best results...": Nur weil man selbst keine Erfahrung mit messbasierten Verfahren hat, sollte man nicht denken, dass der eigenen Forschungsansatz in allen Fällen der beste ist.
    • "Our approach increases predicitions by a wide margin": Diese Aussage gilt nur unter den dem Ansatz unterliegenden Annahmen (was oft eine ganze Menge sind) und ist nicht so allgemeingültig wie sie formuliert wurde.
  • Keine langen Sätze: Während im Deutschen oft in langen Sätzen formuliert wird, sind im Englischen eher kürzere Sätze üblich. Gerade in wissenschaftlichen Texten sind kürzere Sätze bei der Erklärung komplexer Sachverhalte oft sehr hilfreich. Bei Sätzen die über mehr als zwei Zeilen gehen, sollte man sich daher überlegen, ob eine Zerlegung die erhoffte Aussage nicht besser vermittelt.
  • Keine schwammigen Aussagen, die nicht falsifizierbar sind: Dieser Hinweis steht in einem gewissen Kontrast zur obigen Hinweis, Aussagen eher abszuschwächen, als zu stark zu formulieren. Man sollte bei der Abschwächung auf jedem Fall beachten, dass eine Aussage über die reale Welt falsifizierbar bleibt. (Aussagen über mathematische Sachverhalte müssen bewiesen sein oder prinzipiell beweisbar sein, daher gilt hier die Anforderung der prinzipiellen Falsifikation nicht.)
    • "The approach may be helpful for task sounso." Das kann keiner nachprüfen. Aber "The approach improves productivity of task sounso by 13 per cent" ist nachprüfbar.
  • Keine Füllwörter: Wörter wie "clearly", "obviously", "actually" usw. streichen! Wenn etwas klar oder offensichtlich ist, dann muss man keinen Text darauf verschwenden.
  • Verbindender Text zwischen Abschnitten: Wenn zwei Abschnitte abrupt ohne Überleitung aufeinander folgen, ist dies für den Leser unangenehm. Daher sollte man nach Möglichkeit zwischen zwei unterschiedlichen Abschnitten etwas "Glue-Text" spendieren. Weiterhin sollten lange Abschnitte (mehrere Seiten) am Anfang ein paar Sätze mit Überblick über den gesamten Abschnitt enthalten.
  • 7 Sünden unerfahrener Schreiber: Auslassung, Inkonsistenz, Unangemessenheit, Mehrdeutigkeit, unkontrollierte Redundanz, Vorwärtsreferenzen, Reue (Quelle)
  • Literatur zu englischem Stil
    • Hilfreiche Hinweise für amerikanischen Stil, sollte jeder mal gelesen haben oder besitzen: "Elements of Style" by Strunk and White.
    • For British English, "A Dictionary of Modern English Usage" by Fowler or later revised versions could be of interest.
    • Maybe "Practical English Usage" by Swan is interesting, as it targets foreign speakers.
    • Collection of further advice in this wiki in the English Language Corner.

Begutachtung

  • Interne Begutachtung (von Mitarbeitern der Gruppe): All papers must be internally reviewed as follows before being submitted to workshops, conferences, journals etc.
    • Reviewer: Ask colleagues who can likely give good feedback because they are familiar with your paper's topic. For conferences with a broader topic range (e.g. ICSE) or a topic range that does not fit your paper well, also ask colleagues who are less familiar with your paper, because they can give better feedback on the understandability.
    • Paper State: Das Papier sollte zur internen begutachtung fertiggestellt und von den Autoren selbst gründlich gelesen und korrigiert sein. Zur Not kann ein Papier zu diesem Zeitpunkt auch noch unvollständig sein. Fehlende oder noch nicht finale Teile sollten dann entsprechend markiert sein, um den Gutachtern Arbeit zu ersparen.
    • Frühe Abgabe: Einen Papier-Entwurf erst 2 Tage vor Abgabetermin der Konferenz zur Begutachtung vorgelegt zu bekommen, ist einerseits nicht höflich gegenüber den Kollegen, die selbst genug anderes zu tun haben und sich nicht kurzfristig Zeit freischaufeln können. Andererseits kann man in einem solchen Fall weder qualifizierte Kommentare erwarten noch sinnvoll die dann doch gemachten Kommentare einarbeiten und das Papier verbessern. Daher sollte Konferenzpapiere mindestens 2 Wochen vor Abgabetermin der Konferenz zur internen Begutachtung vorgelegt werden. Dann haben die Mitarbeiter eine Woche Zeit zur Begutachtung und dem Autor bleibt eine Woche zur Überarbeitung des Papiers anhand der Kommentare der Gutachter.
    • Umgang mit Kommentaren: Erstmal sollte man sich klar machen, ob man den Kommentar verstanden hat, ansonsten nochmal nachfragen. Man muss nicht jeden Kommentar unkritisch übernehmen, jedoch sollte man sich auch klar machen, dass die Kommentare nicht nur (ignorierbare) Nörgeleien der Gutachter sind, sondern auf Probleme hinweisen. Es ist besser, diese Probleme im internen Begutachtungsprozess auszuräumen, als bei einer Konferenz abgelehnt zu werden. Widersprechen sich Kommentare von verschiedenen Gutachtern oder sind deren Kommentare nur schwierig in Einklang zu bringen, sollte man dies mit den Gutachtern diskutieren.
    • Stand der Reviewfassung: Meist sollten nur fast fertige Versionen ins interne Review gegeben werden, um den Kollegen unnötigen Aufwand zu ersparen. Paper-Ideen sollten eher in Forschungstreffen o.ä. diskutiert werden, anstatt unfertige Paper-Skelette ins Review zu geben. Ein unfertiges Paper zum Review zu geben macht höchstens Sinn, wenn man zu fertigen Abschnitten konkrete Fragestellungen an die Kollegen hat.
  • Externe Begutachtung (vom Programmkommittee der Konferenz)
    • Kein Debuggen durch Gutachter: Man sollte keinesfalls die Gutachter als Fehlerkorrekturinstanz missbrauchen und ein unfertiges oder mit Rechtschreib- oder Grammatikfehlern versehenes Papier einreichen. Daher vor der Einreichung gründlichen die formalen Aspekte des Papiers überprüfen.
    • Umgang mit Kommentaren: Grundsätzlich sollten die Kommentare von externen Gutachter sehr ernst genommen werden und in der Gruppe diskutiert werden. Bei Kommentaren von anonymen Gutachtern kann man natürlich keine Verständnisfragen stellen, jedoch sollte man unklare Kommentare zumindest in der Gruppe der Mitarbeiter besprechen.

Folien für den Konferenzvortrag

  • Prinzip der Pyramide: Auch für den Vortrag gilt wie für das Papier das Prinzip der Pyramide (s.o.). Es sollte schon nach max. 2-3 Folien klar sein, was Problem, Lösungansatz, und Ergebnis der Forschungsarbeit war. Die Details können auf späteren Folien ausgeführt werden. Auf keinen Fall sollte man das Ergebnis der Forschungsarbeit bis zu den letzten Folien verschweigen. Den Zuhörern muss von vornherein klar sein, worauf der Vortrag hinaus möchte. Dann können die Zuhörer auch besser folgen und stellen sich nicht so viele Fragen.
  • Übergewicht der Motivation: Bei Vorträgen auf Konferenzen sollte man mehr Gewicht auf die Motivation des eigenen Forschungsansatzes legen als im Papier. Das Papier wurde von fachkompetenten Gutachtern gelesen, denen die Motivation meist klar ist. Auf der Konferenz hingegen sitzen viele Leute im Publikum, deren Themen nur entfernt verwandt sind. Damit diese Leute von dem Vortrag etwas mitnehmen, sollte man der Präsentation des eigenen Ansatzes eine ausführliche Motivation des Problems und der Lösung voranstellen.
  • Abstraktion von der eigenen Arbeit: Im Vortrag sollte auf keinen Fall versucht werden alle Ergebnisse und Neuerung des Ansatzes im Detail zu beschreiben. Der Vortrag ist mehr als ein "Appetizer" zu sehen, der die Zuhörer motivieren soll das Papier komplett zu lesen. Daher sollte man sich im Vortrag auf die wichtigsten Punkte der eigenen Arbeit konzentrieren und Details nur an wenigen Stellen gezielt vortragen.

Siehe auch die allgemeinen Hinweise auf Vortragshinweise.

Qualitätssicherung Konferenz-/Workshop-Vorträge

Für jeden Vortrag aus unserer Gruppe muss vorher am Lehrstuhl ein Probevortrag gemacht werden.

  • Für Probevortrag 1,5 Stunden einplanen (auch wenn Vortrag nur 20 Min).
  • Mindestens zwei Zuhörer.
  • Ggf. Kollegen die Folien vorher schon mal zeigen und erläutern.
  • Wenn mehrere Kollegen eine Konferenz besuchen, bietet es sich an, einen gemeinsamen Termin zu machen

Referenzen

PhD Thesis

Writing papers

KIT – Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft