Project FLOW is concerned with the characterisitics, modelling, analysis, and optimization of information flows in software development. A fundamental feature of FLOW is the distinction between fluid and solid information stores and flows.


The FLOW Project

Name Information Flow Optimization for Software Projects, short InfoFLOW
Duration 3 years, Nov. 2008 to Oct. 2011
Sponsor Deutsche Forschungsgemeinschaft (DFG), Fundamental Research Project
Project Manager Kai Stapel
Contact Kurt Schneider and Kai Stapel

1. Motivation

Software development can be problematic despite of mature processes. Projects are delayed or even fail entirely. Required documents are not created due to time pressure. The specified process is not being followed. The promising agile methods cannot or can hardly be combined with the heavy-weight processes. What can be done to facilitate the strengths of both sides?

Information is the basis for all development activities. Because, no matter what the development style is, whether it is a document centric process or an agile method like eXtreme Programming, information has to be transferred from the customer to the final software product. Hence, information and their flow in software development projects are the basis of our research in project FLOW.

2. Basic Concepts

FLOW concentrates on characteristics, modelling, analysis, and optimization of information flows.

Definition: FLOW
FLOW is the systematic research on information flows in software development.

FLOW research is based on a few fundamental assumptions, that were derived from industrial experience:


2.1. Metaphor of the State of Information

An essential concept of FLOW is the distinction between solid and fluid information and the respective flows. The metaphor is used so the main characteristics of information flows can be discerned.

Definition: Solid
Information is solid when it is (1) long term accessible, (2) repeatable, and (3) comprehensible by third parties*.

* Third parties do not have to be arbitrary persons, but can be e. g. from the same domain or project.

Definition: Fluid
Information is fluid when it is not solid.

That means that information is fluid whenever one of the solid characteristics is not met.

The following table lists characteristics of solid and fluid information along with typical examples of information stores.

State of Information Characteristic Example Store
  • Storage costs time and effort
  • Access costs time and effort
  • Access is repeatable**
  • Long-term accessible**
  • Third parties can understand it**
  • Information can not be lost or forgotton
  • Context for interpretataion can be attached, at least to a certain level.
  • Document (paper based and electronic)
  • Audio-/Video recordings
  • Screencasts
  • Source code
"What someone has in mind."

Fluid information is bound to peoples (previdous) knowledge, the so called context. Information cannot be interpreted correctly without the appropriate context, thus, it cannot be understood.
  • Can be lost (forgotten context) or forgotten
  • Cannot be obtained or reproduced by third parties. The right contet for interpretation is needed.
  • Fast, efficient transfer of information possible
  • People
  • Informal e-mails
  • Text chat protocols
  • Memos, note sheets
  • Notes on whiteboards

** Directly derived from the definition of solid.

2.2. Graphical Notation

The FLOW notation was developed based on the basic concepts and the information state metaphor. It allows to intuitively illustrate the fundamental aspects of FLOW, in particular the distinction between solid and fluid. Essentially, there are symbols for solid and fluid informations stores and corresponding arrow types for information flows. A symbol for activities complements the notation. It allows to incorporate FLOW models with existing process models like EPCs or UML activity diagrams.

State of Information Store Flow Activity
  1 2..n Project infos Experiences  
Solid Document symbol
Documents symbol
<Type of Document>
Solid information flow
<Type of Information>
Fluid information flow
Fluid Personensymbol
flüssiger Informationsfluss
<Type of Information>
flüssiger Erfahrungsfluss


The document symbol represents a solid information store. It was chosen because a document is the most prominent representative of solid information stores in software development. A set of documents (of the same type) is depicted by a triple document. Information flows originating from a solid store are themselves solid. They are depicted by an arrow with a solid line.


A smiley symbol represents a fluid information store. It was chosen because fluid information is always bound to people. A group of persons is depicted by a triple smiley. If it is necessary to distinguish between roles and individuals different caption styles can be used, i. e. an underlined caption for roles and a regular one for individuals (for example: "Johnson" as opposed to "Analyst"). Information flows originating from a fluid store are themselves fluid. They are depicted by an arrow with a dashed line.


In software development experience is an extraordinary valuable type of information. Therefore, FLOW has an explicit means to depict it. Usually a different color for stores and flows is used. For black and white printouts the "color" gray should be used.


In FLOW models the activity symbol has two functions:

  1. It subsumes information stores and other activities and hides them. Hence, it facilitates hierarchical structured FLOW models. Incoming and outgoing flows, the so called FLOW interface [3], have to be consistent with the underlying detailed (subsumed) model.
  2. It is used to connect FLOW models to process notations. By this aspects of information flows can be integrated in existing process models.

Activity with controlling and project relevant infotmation flows. To depict the difference of information flows that are involved in an activity with regards to content and controlling flows, the flows can be attached to the activity symbol from different sides. Information that controls an activity is connected on top or bottom of the activity symbol. Information that controls something usually is experience. Information that is being or was altered and tranformed in the activity is connected from left or right.

Alternatively, the activity symbol can be used according to IDEF0. There are four connecting points for flows then:

Activity with information flows according to IDEF0
  1. From left all information that is being processed in the activity is attached.
  2. Outgoing flows are attached to the right. By default outgoing flows have a solid line. If it is known that an outgoing flow is fluid it can also be depicted with a dashed line.
  3. From bottom mechanisms that support the execution of an activity are attached. For example this can be a person that performs the activity or a tool like a word processor.
  4. Controoling flows are attached on top of the activity. Examples of controlling flows are experiences in form of checklists or specialized knowledge of a person. Therefore, control flows in activities are usually depicted in gray.

2.3. ProFLOW

ProFLOW (German) is the graphical modelling tool for FLOW. It facilitates creation and editing of FLOW models and process models supplemented by FLOW elements. ProFLOW was designed to be an easily extensible modelling framework, so new notations can be tried out with low effort. All new notations can be enriched with FLOW aspects. At the moment EPCs and UML Activity Diagrams are supported. You can download ProFLOW and give it a try on the ProFLOW Website (German in German).

ProFLOW Website: /pages/de:projekte_flow_proflow (German in German)

ProFLOW Development Site: https://trac.se.uni-hannover.de/trac/proflow (German in German)

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

2.4. Simulation of Information Flows

In the software project course of 2007/2008 students built a simulation game for software development using the software quantum metaphor to simulate and visualize information flow [17]. Are you a good project manager? Then play the game and enter the highscore.

3. The FLOW Method

A description of the FLOW method will be published here soon.


  • 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