Projekt FLOW

Projekt FLOW

Das Forschungsprojekt FLOW beschäftigt sich mit Eigenschaften, Modellierung, Analyse und Optimierung von Informationsflüssen in der Softwareentwicklung. Eine wesentliche Eigenschaft von FLOW ist die explizite Modellierung von flüssigen und festen Informationsflüssen.

Projektname Informationsflussoptimierung für Softwareprojekte, kurz InfoFLOW
Projektdauer 3 Jahre, Nov. 2008 bis März 2012
Förderer Deutsche Forschungsgemeinschaft (DFG), Grundlagenforschungsprojekt
Projektleiter Kai Stapel
Ansprechpartner Kurt Schneider

Das FLOW Video

FLOW Goal CubeFLOW HistoryFLOW State of InformationFLOW ContextProject MinotaurusFLOW ModelingFLOW Coffee MugFLOW Summary
Auf der englischen FLOW-Seite This site in English erklärt ein Video zentrale Aspekte des Projekts und zeigt, wie FLOW zur Verbesserung der Kommunikation in global verteilten Softwareprojekten angewandt werden kann.

1. Motivation

Bei der Softwareentwicklung gibt es trotz reifer Prozesse nach wie vor Probleme. Projekte verspäten sich oder schlagen ganz fehl. Vorgeschriebene Dokumente werden wegen hohem Zeitrdruck nicht erstellt. Der vorgegebene Prozess wird nicht eingehalten. Die vielversprechenden agilen Methoden lassen sich nicht oder nur kaum mit den schwergewichtigen Prozessen vereinbaren. Was kann man tun, um die Vorteile beider Seiten (Prozess und agil) zu nutzen?

Information ist die Basis aller Entwicklungsaktivitäten. Denn egal wie entickelt wird, ob mit einem dokumentenzentrierten Prozess oder agil mit eXtreme Programming, die Informationen, die der Kunde in Form von Anforderungen im Kopf hat, müssen möglichst vollständig und möglichst schnell in das Endprodukt Software gelangen. Daher sind Informationen und deren Fluss im Softwareentwicklungsprojekt Ausgangspunkt für Forschung und Verbesserungen im Projekt FLOW.

2. Ziele

Das Forschungsprojekt FLOW wurde 2004 mit Gründung des Fachgebiet Software Enginneering an der Leibniz Universität Hannover initiiert.

Definition: FLOW
FLOW ist die systematische Auseinandersetzung mit Informationsflüssen in der Softwareentwicklung.

FLOW beschäftigt sich mit Eigenschaften, Modellierung, Analyse und Optimierung von Informationsflüssen. Folgende Ziele werden im Einzelnen verfolgt:

Erkenntnisgewinn Optimieren von Entwicklungsaktivitäten Ziele von FLOW

Hinweis: Die Inhalte zu den Zielen Softwareprozessverbesserung (SPI) und Projektübergreifende Verbesserung befinden sich momentan noch in der Entstehung und werden demnächst auf dieser Seite publiziert.

3. Grundlegende Konzepte

Die FLOW-Forschung basiert auf wenigen Grundannahmen, die sich aus den Zielen abgeleitet und in der industriellen Praxis als sinnvoll herausgestellt haben:

3.1. Metapher der Aggregatzustände

Eine wesentliche Eigenschaft von FLOW ist die Unterscheidung von festen und flüssigen Informationen und abgeleiteten Flüssen. Die Metapher ist darauf ausgerichtet schnell zwischen wesentlichen Eigenschaften von Informationslfüssen in verschiedene Medien unterscheiden zu können.

Definition: Fest
Informationen sind fest, wenn sie (1) langfristig abrufbar, (2) wiederholt abrufbar und (3) für Dritte* verständlich sind.

* Dritte müssen nicht beliebige Personen sein, sondern können z. B. auch aus der selben Domäne oder dem selben Projekt stammen.

Definition: Flüssig
Informationen sind flüssig, wenn sie nicht fest sind.

Das heißt, Informationen sind flüssig, wenn eine der Eigenschaften fester Informationen nicht erfüllt ist.

Die folgende Tabelle listet die Eigenschaften der Aggregatzustände fest und flüssig mit einigen typischen Beispielen auf.

AggregatzustandEigenschaftenBeispiele
Fest
  • Speicherung kostet Zeit und Aufwand
  • Abruf kostet Zeit und Aufwand
  • Wiederholt abrufbar**
  • Langfristig zugänglich**
  • Dritte können etwas damit anfangen**
  • Information "versickert" nicht
  • Kontext kann - bis zu einem gewissen Grad - mitgeliefert werden
  • Dokumente (Papier und elektronisch)
  • Audio-/Video-Aufnahmen
  • Screencasts
  • Quellcode
Flüssig
"Was jemand im Kopf hat."

Flüssige Information ist immer an das (Vor-) Wissen, den so genannten Kontext, einer Person gebunden. Ohne den richtigen Kontext kann eine Information nicht richtig interpretiert und damit auch nicht verstanden werden.
  • Gehen leicht verloren (Kontext wird vergessen), werden vergessen (Information selbst), sie "versickern".
  • Nicht objektiv reproduzierbar, der richtige Kontext ist zur Interpretation notwendig
  • Effiziente und schnelle Inforamtionsweitergabe möglich
  • Personen
  • informelle E-Mails
  • Chat-Protokolle
  • Notizzettel
  • Whiteboard-Notizen

** Leitet sich direkt aus der Definition von fest ab.

3.2. Definitionen

Bevor die FLOW-Modelle vorgestellt werden können sind zunächst einige Definitionen zentraler Begiffe notwendig. Eine detailliertere Herleitung der Begriffe findet sich in Kapitel 3 der Masteratbeit von Kai Stapel [1].

Grundbegriffe

Definition: Information
Information ist ein relationaler Begriff, der die komplexen Beziehungen zwischen Daten und Wissen abstrahiert [1].
Auf Basis von Daten: Information = Daten + Bedeutung
Auf Basis von Wissen: Potentielles, nicht personengebundenes Wissen.

Definition: Wissen
Gesamtheit der Kenntnisse und Fähigkeiten, die Individuen zur Problemlösung einsetzen können.

Definition: Daten
Daten = Zeichen + Syntax

Definition: Erfahrung
Erfahrung ist eine speziell strukturierte Art von Information. Sie besteht aus einer Beobachtung, einer Emotion und einer Schlussfolgerung.

Definition: Kontext
Zur Interpretation von Information notwendiges Wissen. Interpretation ist das Zuweisen von Bedeutung (zu Daten).

Kontexte können zum Beispiel sein:

Informationsspeicher

Definition: Informationsspeicher
Informationsspeicher sind Daten oder Wissen. Speicher können damit sowohl Dokumente (fest) als auch Personen (flüssig, "was jemand im Kopf hat") sein.

Definition: Dokument
Ein Dokument ist ein Daten-Container.

Informationsflüsse

Definition: Informationsfluss (auch Transformation, Aggregatzustandsübergang)
Informationsfluss ist das Kopieren von Information in einen anderen Informationsspeicher.

Definition: Kommunikation
Kommunikation ist der Informationsfluss zwischen Personen (inklusive Umweg über Dokumente).

Definition: Dokumentation
Dokumentation ist das Verfestigen von Information (auch Externalisierung).

Aktivitäten

Definition: Aktivität
Eine Aktivität in FLOW fasst Informationsspeicher zusammen. Sie kann damit zur Strukturierung und Hierarchisierung von FLOW-Modellen eingesetzt werden.

3.3. Notation

Ausgehend von den Grundkonzepten und der Metapher der Aggregatzustände wurde eine Notation entwicklet, die es erlaubt, die wesentlichen Eigenschaften von FLOW-Modellen, nämlich die explizite Unterscheidung von festen und flüssigen Informationsflüssen, intuitiv darstellen zu können. Im Wesentlichen gibt es je ein Symbol für feste und flüssige Informationsspeicher und entsprechend je einen Pfeiltyp für Informationsflüsse. Ergänzt wird das Ganze durch die Möglichkeit über das Aktivitäten-Symbol FLOW-Modelle an bestehende Prozess-Notationen, wie EPKs oder UML-Aktivitätsdiagramme, zu koppeln.

AggregatzustandSpeicherInformationsflussAktivität
 12..nProjektinfosErfahrungen 
Fest Dokumentsymbol
<Dokument>
Dokumentensymbol
<Dokumenttyp>
fester Informationsfluss
<Informationsart>
(optional)
fester Erfahrungsfluss
<Erfahrung>
(optional)
Aktivität
Flüssig Personensymbol
<Person>
Gruppensymbol
<Gruppe>
flüssiger Informationsfluss
<Informationsart>
(optional)
flüssiger Erfahrungsfluss
<Erfahrung>
(optinoal)

Fest

Das Symbol für einen festen Informationsspeicher ist das Dokument. Es wurde gewählt, weil es der typischste Vertreter von festen Informationen in der Softwareentwicklung ist. Möchte man als Informationsspeicher mehrere Dokumente eines Typs modellieren, so stellt man das mit dem 3-fach hinterlegten Dokumentensymbol dar. Alle Informationsflüsse, die aus einem festen Speicher hervorgehen, sind wiederum fest. Sie werden mit einem Pfeil mit durchgehender Linie dargestellt.

Flüssig

Das Symbol für einen flüssigen Informationsspeicher ist ein Smiley. Es wurde gewählt, weil flüssige Informationen immer an Personen gebunden sind. Eine Gruppe von Personen wird mit dem 3-fachen Smiley dargestellt. Falls die Unterscheidung zwischen Rollen und Individuen bei Personen erforderlich ist, kann man dies durch verschiedene Bezeichner darstellen. So kann zum Beispiel durch Unterstreichen des Namens verdeutlicht werden, dass es sich um eine Rolle handelt (z. B.: "Müller" im Vergleich zu "Analyst"). Informationsflüsse, die von einem flüssigen Speicher ausgehen, sind flüssig. Sie werden mit einem Pfeil mit gestrichelter Linie dargestellt.

Erfahrung

Da Erfahrung eine in der Softwareentwicklung besonders wertvolle Art von Information ist, kann man sie in FLOW explizit darstellen. Dies geschieht durch eine andere Farbe der Speicher und Flüsse. Meist wird Grau als Kontrast zu den sonst schwarzen Symbolen und Bezeichnern verwendet, so dass eine Unterscheidung auch noch auf Schwarz-Weiß-Ausdrucken möglich ist.

Aktivität

In FLOW-Modellen hat das Aktivitäts-Symbol zwei Aufgaben:

  1. Es fasst Informationsspeicher (und ggf. andere Aktivitäten) zusammen und verbirgt sie. Damit ermöglicht es eine hierarchische Strukturierung der Modelle. Die eingehenden und ausgehenden Flüsse einer Aktivität, das so genannte FLOW-Interface [3], müssen konsistent mit den ein- und ausgehenden Flüssen im darunter liegenden Detailmodell sein.
  2. Es dient als Verbindung zu bestehenden Prozessnotationen. Aspekte von Informationsflüssen, insbesondere die Unterscheidung zwischen fest und flüssig, können so in bestehende Prozessdarstellungen integriert werden.

Aktivität mit steuernden und inhaltlichen Informationsflüssen Um den Unterschied von Informationsflüssen, die einmal steuernd und einmal inhaltlich an einer Aktivität beteiligt sind, darstellen zu können, gibt es die Möglichkeit diese an unterschiedlichen Stellen mit dem Aktivitätssymbols zu verbinden. Informationen, die steuernd an einer Aktivität mitwirken, werden von oben oder unten an das Symbol gezeichnet. Steuernde Informationen sind meist Erfahrungen. Informationen, die inhaltlich von der Aktivität verarbeitet werden, werden von links oder rechts an das Symbol gezeichnet.

Alternativ kann das Aktivitäten-Symbol auch in Anlehnung an IDEF0 benutzt werden. Es gibt dann 4 Verbindungspunkte für Flüsse:

Aktivität Informationsflüssen nach IDEF0
  1. Auf der linken Seite werden alle eingehenden Flüsse angehängt, die in der Aktivität verarbeitet werden.
  2. Auf der rechten Seite werden alle ausgehenden Flüsse markiert. Ausgehende Flüsse aus Aktivitäten werden standardmäßig mit durchgehender Linie gezeichnet. Wenn bekannt ist, dass ein ausgehender Fluss flüssig ist, kann dies auch explizit mit einem gestrichelten Pfeil dargestellt werden.
  3. Auf der Unterseite werden Mechanismen zur Unterstützung der Ausführung einer Aktivität angetragen. Das können zum Beispiel bestimmte Tools sein, oder Personen, die eine Aktivität ausführen.
  4. Auf der Oberseite werden steuernde und kontrollierende Informationsquellen angeführt. Das können zum Beispiel Erfahrungen in Form von Checklisten oder spezielle Kenntnisse einer Person sein. Daher werden die Kontrollflüsse in eine Aktivität meist grau dargestellt.

3.4. ProFLOW

ProFLOW ist das grafische Modellierungswerkzeug für FLOW. Es ermöglicht das Erstellen und Bearbeiten von FLOW-Modellen und von Prozessen, um FLOW-Elemente ergänzt. ProFLOW wurde als einfach erweiterbares Modellierungs-Framework entwickelt, damit möglichst leicht neue Notationen ausprobiert werden können. Dabei ist es möglich in jeder neuen Notation auch FLOW-Elemente zu verwenden. Im Moment werden als zusätzliche Notationen Ereignisgesteuerte Prozessketten (EPK) und UML-Aktivitätsdiagramme unterstützt. Auf der ProFLOW-Webseite finden Sie weitere Informationen. Dort kann ProFLOW auch heruntergeladen und ausprobiert werden.

ProFLOW Webseite: http://www.se.uni-hannover.de/pages/de:projekte_flow_proflow

ProFLOW Entwicklerseite: https://trac.se.uni-hannover.de/trac/proflow

ProFLOW Updatesite: http://www.se.uni-hannover.de/pub/File/projekte/flow/proflow/

4. Erkenntnisgewinn

Software-Engineering-Phänomene besser verstehen

Ein Ziel von FLOW ist der Erkenntnisgewinn. Aktivitäten der Softwareentwicklung sollen durch den anderen Blickwinkel der Informationsflüsse besser verstanden und besser analysiert werden können. Ein geeignetes Mittel dafür sind Simulationen. Grundlage der Simulationen in FLOW ist die Metapher der Software Quanten.

4.1. Software Quanten Metapher

Die Software Quanten Metapher ist ein deskriptives Modell der Softwareentwicklung. Sie dient dazu Ist-Projektsituationen darzustellen, sodass man sowohl die Stärken als auch die Schwächen eines realen Prozesses sehen kann. Software Quanten ermöglichen qualitative und quantitative Aussagen. Das Modell wurde für folgende Modellierungszwecke gebildet:

Software Quanten sind atomare Projektinformationseinheiten. Sie haben ungefähr ein zehntel der Größe eines Function Points [2].

Software Quanten Metapher

Die Metapher bildet alle Anforderungen zu Beginn eines Projekts auf eine Menge von Kugeln ab. Die Kugeln und deren Anordnung stellen die Visualiserung der Software Quanten dar. Die Quanten im Kopf des Kunden sind alle in der gleichen Farbe dargestellt (grüne Kugeln), da sie echte legitime Anforderungen sind. Die Anforderungen des Kunden bilden die Referenz. Wenn ein Analyst den Kunden interviewt, greift er sich eine (Unter-)Menge von Software Quanten aus der Menge der Quanten des Kunden und fügt sie seiner eigenen Menge hinzu. Dort vermischen sie sich mit schon vorhandenen Software Quanten, die eventuell aus vorherigen Projekten im gleichen Kontext stammen. Durch Missverständnisse können Quanten weggelassen oder hinzugefügt werden. Je länger solch ein Interview dauert, desto mehr Quanten können transferiert werden. Dabei ist es sehr wahrscheinlich, dass Anforderungen wiederholt übertragen werden. Die Anzahl der Quanten des Analysten erhöht sich dann nicht weiter. Richtig übertragene Quanten werden in der selben Farbe, wie die des Kunden, dargestellt (grün), falsche Quanten in einer anderen Farbe (blau). Dabei bestimmt sich die Korrektheit eines Quants immer in Bezug auf die Quanten des Kunden. Daher kann es zum Beispiel passieren, dass der Programmierer den Entwurf falsch versteht und etwas anderes als beschrieben programmiert, damit aber eine tatsächliche Anforderung des Kunden erfüllt, die auf dem Weg bis zum Entwurf schon vergessen war.

Mathematisch ist die Übertragung von Software Quanten eine zufällige Auswahl aus einer Menge von unterscheidbaren Objekten ohne Beachtung der Reihenfolge mit Zurücklegen (Repetition, der Kunde vergisst seine Anforderungen für gewöhnlich nicht). Quanten sind individuell. In der Visualisierung werden gleiche Quanten durch die gleiche Position dargestellt.

4.2. Simulation

Die Software Quanten Metapher wurde als Basis für verschiedene Simulationen benutzt: Karsten Möckel hat in seiner Bachelorarbeit [2] eine Simulationskomponente für das ProFLOW-Framework entwickelt.

Simulationskomponente von ProFLOW

Im Softwareprojekt 2007/2008 haben Studenten ein Software Quanten Spiel implementiert, das die Wichtigkeit von Requirements Engineering in der Softwareentwicklung spielerisch veranschaulichen soll. Mehr dazu findet sich in [17].

Software Quanten Spiel

4.3. Awareness

Hinweis: Die Inhalte zum Thema Awareness befinden sich momentan noch in der Entstehung und werden demnächst auf dieser Seite publiziert.

Prinzipiell läßt sich sagen, dass allein schon die Beschäftigung mit Informationsflüssen in der Softwareentwicklung die Awareness steigert (vgl. [16]).

5. Optimieren von Entwicklungsaktivitäten

Techniken und Werkzeuge zur Flussverbesserung

5.1. FLOW-Faustregel

Die FLOW-Fausregel ist eine sehr einfache Regel, die bei der Entscheidung, ob Informationen besser fest oder flüssig weitergegeben oder gespeichert werden sollen, unterstützt. Sie leitet sich direkt aus den typischen Eigenschaften von fest und flüssig ab.

5.2. LIDs - Leichtgewichtige Erfahrungsdokumentation

LIDs steht für Light-Weight Documentation of Experiences - die leichtgewichtige Dokumentation von Erfahrungen [1]. Sie beschreibt eine Technik, mit der man ohne großen Aufwand die vielen am Ende eines Projekts vorhandenen flüssigen Erfahrungen verfestigen kann, sodass sie in späteren gleichartigen Projekten wiederverwendet werden können.

Grundlage der Methode ist ein LID-Template, dass durch seine Struktur die Erfahrungserhebung anleitet. Am Ende eines Projekts kommen alle beteiligten Mitarbeiter in einer LID-Sitzung zusammen und lassen das Projekt nochmal Revue passieren, um sich an wichtige Projektsituationen zu erinnern und Erfahrungen dazu festzuhalten. Ein Moderator führt anhand der Struktur und der Anweisungen im LID-Template die Diskussion und schreibt die Erfahrungen der Mitarbeiter in das Dokument. Eine LID-Sitzung dauert zwischen 1,5 und 2 Stunden und ist damit eine einfache und ressourcenschonende Methode zur Erfahrungserhebung.

5.3. FOCUS

FOCUS ist eine Methode - unterstützt durch ein gleichnamiges Werkzeug - die es erlaubt, flüssige Code-Walkthroughs zu verfestigen. In einer FOCUS-Sitzung erklärt der Autor einer Software einem anderen Entwickler seinen Quellcode. Das FOCUS-Werkzeug zeichnet dabei sowohl den Bildschirminhalt und das Gespräch selbst auf, als auch die aktuellen Positionen im Quellcode. Das erleichtert einem dritten Entwickler, der sich später mit Hilfe der FOCUS-Aufzeichnung in den Quellcode einarbeiten möchte, den relevanten Quelltext des gerade in der Wiedergabe erläuterten Programmteils zu finden.

6. Softwareprozessverbesserung (SPI)

Eines der Hauptziele von FLOW ist die Softwareprozessverbesserung. Durch Analyse und Optimierung von Informationsflüssen sollen Softwareentwicklungsprozesse verbessert werden. Dies kann sowohl vor Beginn, bei der Planung eines Projekts, als auch im Laufe des Projekts geschehen. Ersteres wird wie auch andere Anpassungen von Softwareentwicklungsprozessen als Tailoring bezeichnet. Letzteres ist das reaktive Justieren.

6.1. Proaktives Tailoring

Proaktives Tailoring bezeichnet das systematische Zuschneiden und Anpassen der Informationsflüsse eines anstehenden Entwicklungsprojekts in der Planungsphase. Es soll die Anpassung an individuelle Projektprioritäten ermöglichen, zum Beispiel für eine angemessene Dokumentation oder verbesserte Kommunikation [14]. Proaktives Tailoring ist damit ein wichtiger Schritt auf dem Weg zum Software Engineering nach Maß [9].

Anwendungsbeispiele

In einem internen global verteilten Softwareprojekt, das wir zusammen mit der Petrosavodsk State University in Russland und dem VTT in Finnland durchgeführt haben, haben wir Informationsflüsse beobachtet und damit die Informationsflussanalyse im Global Software Engineering erprobt. Das folgende Video gibt einen kurzen Eindruck dieses global verteilten Projekts.

Dieses Video gibt es auch als MPEG2 zum Download: Projekt Minotaurus (47 MB)

Demnächst werden an dieser Stelle weitere Anwendungsbeispiele von FLOW veröffentlicht.

Veröffentlichungen zu FLOW

  • 2000
  • [1] Schneider, Kurt: LIDs: A Light-Weight Approach to Experience Elicitation and Reuse, In Frank Bomarius and Markku Oivo, Product Focused Software Process Improvement, volume 1840/2000 of Lecture Notes in Computer Science, pages 407-424. Springer Berlin / Heidelberg, 2000, Bibtex. Abstract. PDF herunterladen Link
  • 2004
  • [2] Kurt Schneider: A Descriptive Model of Software Development to Guide Process Improvement, In Conquest, Nürnberg, Germany. ASQF, 2004, Bibtex. PDF herunterladen
  • 2005
  • [3] Kurt Schneider, Daniel Lübke: Systematic Tailoring of Quality Techniques, In World Congress of Software Quality 2005, 2005, Bibtex.
  • [4] Kurt Schneider, Daniel Lübke, Thomas Flohr: Softwareentwicklung zwischen Disziplin und Schnelligkeit, In TeleKommunikationAktuell, volume 59, pages 1-21, 2005, Bibtex.
  • [5] Kurt Schneider: Vier Formen der Erfahrungsvermittlung im Studium, In Software Engineering im Unterricht der Hochschulen (SEUH 2005), 2005, Bibtex.
  • [6] Kurt Schneider: Software Process Improvement from a FLOW Perspective, In Learning Software Organizations Workshop, 2005, Bibtex.
  • 2006
  • [7] Eric Knauss, Daniel Lübke, Thomas Flohr: Learning to Tailor Documentation of Software Requirements, In Journal of Universal Knowledge Management, volume 1, pages 103-111, 2006, Bibtex. Abstract. Link
  • [8] Kurt Schneider: Rationale as a By-Product, A. H. M. Dutoit and I. Mistrík and Barbara Paech: Rationale Management in Software Engineering. Springer, Berlin, Heidelberg, 91-109, 2006, Bibtex.
  • [9] Kurt Schneider: Software-Engineering nach Maß mit FLOW, In SQMcongress 2006, Düsseldorf, Germany. SQS, 2006, Bibtex.
  • [10] Schneider, Kurt: Aggregatzustände von Anforderungen erkennen und nutzen, In GI Softwaretechnik-Trends, 2006, Bibtex.
  • 2007
  • [11] Kurt Schneider: Generating Fast Feedback in Requirements Elicitation, In Pete Sawyer and Barbara Paech and Patrick Heymans, Requirements Engineering: Foundation for Software Quality (REFSQ 2007), volume 4542 of LNCS, pages 160 - 174, Trondheim, Norway. Springer, 2007, Bibtex.
  • [12] Kai Stapel, Kurt Schneider, Daniel Lübke, Thomas Flohr: Improving an Industrial Reference Process by Information Flow Analysis: A Case Study, In Proceedings of PROFES 2007, volume 4589 of LNCS, pages 147-159, Riga, Latvia. Springer-Verlag Berlin Heidelberg, 2007, Bibtex. Abstract. PDF herunterladen
  • [13] Kurt Schneider, Kai Stapel: Informationsflussanalyse für angemessene Dokumentation und verbesserte Kommunikation, In Proceedings of Software Engineering 2007 (SE 2007), Hamburg, Germany, 2007, Bibtex. Abstract. PDF herunterladen
  • [14] Kurt Schneider, Thao Nguyen: FastFeedback: Schnelle Anforderungserhebung mit höherer Ausbeute, In SQM 2007: 12th International Software and Systems Quality Conferences, 2007, Bibtex.
  • 2008
  • [15] Kai Stapel, Eric Knauss, Christian Allmann: Lightweight Process Documentation: Just Enough Structure in Automotive Pre-Development, In Rory V. O'Connor and Nathan Baddoo and Kari Smolander and Richard Messnarz, Proceedings of the 15th European Conference (EuroSPI '08), pages 142-151, Dublin, Ireland. Springer, 2008, Bibtex. Abstract. PDF herunterladen
  • [16] Kurt Schneider, Kai Stapel, Eric Knauss: Beyond Documents: Visualizing Informal Communication, In Proceedings of Third International Workshop on Requirements Engineering Visualization (REV '08), Barcelona, Spain, 2008, Bibtex. Abstract. PDF herunterladen
  • [17] Eric Knauss, Kurt Schneider, Kai Stapel: A Game for Taking Requirements Engineering More Seriously, In Proceedings of Third International Workshop on Multimedia and Enjoyable Requirements Engineering (MERE '08), Barcelona, Spain, 2008, Bibtex. Abstract. PDF herunterladen
  • 2009
  • [18] Kai Stapel, Eric Knauss, Kurt Schneider: Using FLOW to Improve Communication of Requirements in Globally Distributed Software Projects, In Workshop on Collaboration and Intercultural Issues on Requirements: Communication, Understanding and Softskills (CIRCUS '09), Atlanta, USA, 2009, Bibtex. Abstract. PDF herunterladen
  • 2010
  • [19] Kai Stapel, Eric Knauss, Kurt Schneider, Matthias Becker: Towards Understanding Communication Structure in Pair Programming, In Alberto Sillitti, Proceedings of the 11th International Conference on Agile Software Development (XP '10), volume 48 of LNBIP, pages 117-131, Trondheim, Norway. Springer, 2010, Bibtex. PDF herunterladen
  • 2011
  • [20] Kai Stapel, Eric Knauss, Kurt Schneider, Nico Zazworka: FLOW Mapping: Planning and Managing Communication in Distributed Teams, In Proceedings of 6th IEEE International Conference on Global Software Engineering (ICGSE '11), pages 190-199, Helsinki, Finland, 2011, Bibtex. Abstract. PDF herunterladen
  • 2012
  • [21] Kai Stapel, Kurt Schneider: FLOW-Methode - Methodenbeschreibung zur Anwendung von FLOW, Technical report, Fachgebiet Software Engineering, Leibniz Universität Hannover, http://arxiv.org/abs/1202.5919, 2012, Bibtex. PDF herunterladen Link

Weitere Referenzen zu FLOW

  1. Kai Stapel, Informationsflussoptimierung eines Softwareentwicklungsprozesses aus der Bankenbranche (PDF − 1,1MB), Masterarbeit, Leibniz Universität Hannover, 2006
  2. Karsten Möckel, Simulationskomponente für Informationsflüsse in einem Prozessmodellierungs-Framework (PDF − 1,1MB), Bachelorarbeit, Leibniz Universität Hannover, 2007
  3. Workshop: 1. FLOW Workshop, im September 2007, Leibniz Universität Hannover, Hannover, Deutschland
  4. Xiaoxuan Ge, FLOW Patterns: Beschreibung und Diskussion von Informationsflussmustern in der Softwareentwicklung (PDF − 2,2MB), Masterarbeit, Leibniz Universität Hannover, 2008
  5. Xiaoxuan Ge, FLOW-Patterns-Katalog (PDF − 2,7MB), aus Masterarbeit (PDF − 2,2MB), Leibniz Universität Hannover, 2008
  6. Seminar "Informationsfluss: Dokumentation und Kommunikation im Unternehmen", WS 2008/2009
  7. Tutorial: Modeling the Flow of Requirements: Improved Communication and Documentation in Software Projects, September 2009, Halbtagestutorial zu FLOW auf der RE 09 in Atlanta, Georgia, USA.
  8. Tutorial: InfoFLOW 2009: Informationsflussanalyse: Verbesserte Kommunikation und Dokumentation in Softwareprojekten, Oktober 2009, Tutorial zu FLOW auf der Informatik 2009 in Lübeck