Schlagwort-Archive: Funktionen

Wie nützlich sind Wirkungsnetzwerke im systemischen Kontext?

In der System Dynamics Community wird schon lange die Nützlichkeit von Causal Loop Diagrams (CLD) – zu Deutsch etwa „Wirkungsnetzwerke“ – diskutiert. Hier fragt Tom Fiddaman Are causal loop diagrams useful?  Dabei geht es nicht darum, die Methode der Causal Loop Diagrams anzuzweifeln, sondern darum, gleich einen Schritt weiterzugehen und von Anfang an Stock-Flow-Modelle zu bauen. Dagegen spricht jedoch, dass Stock-Flow-Modelle ungleich schwieriger und aufwändiger sind als CLD. Diese sind dafür handlich und schnell entwickelt.

Pfeile sind Funktionen!

Gerade das ist der Kritikpunkt. Weil CLD sofort einleuchten – Parameter, die sich beeinflussen, sind mit einem Pfeil verbunden – meint schnell einer, er könne drauflos zeichnen. Das führt dann dazu, dass in der Literatur wirre CLD auftauchen, die die Kritik geradezu herausfordern.

Auf der anderen Seite betrachten auch die Kritker CLD nicht als das, was sie wirklich sind: verkettete reellwertige monotone Funktionen. Den Kritikern – das sind meist die ganz grossen der Szene, wie eben Tom Fiddaman, Kim Warren, George P. Richardson – ist dann jedes Argument recht, wenn es gilt, CLD zu umgehen, um gleich von Anfang an Stock-Flow-Modelle zu entwickeln. Nur: das ist nicht praxisgerecht! Gerade KMU haben kein Budget zur Entwicklung aufwändiger Stock-Flow-Diagramme.

Fiddaman bezieht sich in seinem Artikel auf Problems in Causal Loop Diagrams Revisited von George P. Richardson. Richardson macht dort das Beispiel eines Epidemiemodells, in dem ein Pfeil positiver Polarität „Infection rate –> sick population“ vorkommt. Dazu schreibt er:

[This arrow is false]. The link from the Infection rate to the Sick population has a similar problem:
when the infection rate decreases, the sick population does not decrease (move in the same direction) as the “S” label suggests — it would continue to increase. We know very well the reason for these behaviors: the infection rate always subtracts from the susceptible population and adds to the sick population. The populations are stocks, and the infection rate drains one stock and pours into the other

Richardson ist als Professor of Public Administration and Policy vermutlich kein Mathematiker. Er beachtet deshalb nicht, dass hier der funktionale Zusammenhang nicht von der Zeit abhängt. Zwar nimmt zeitlich die Grösse der infizierten Bevölkerung auf jeden Fall zu, auch wenn die Infektionsrate sinkt, da hat er recht. Aber das ist hier nicht die Frage. Es geht hier nicht um einen funktionalen Zusammenhang mit der Zeit, sondern mit der Infektionsrate. Wenn die Infektionsrate sinkt, sinkt selbstverständlich auch die Grösse der infzierten Bevölkerung.

Ein Pfeil ist meist keine Funktion der Zeit

Um das einzusehen, schauen wir die Welt zunächst durch Richardsons Augen an. Er hat recht, dass die infizierte Bevölkerung ein Bestand ist und die Infektionsrate angibt, wie viel Prozent der „ansteckbaren“ Bevölkerung krank werden. Das hat ungefähr dieselbe Dynamik, wie ein Zinsmodell. Sind i1 < i2 < i3 drei verschiedene Infektionsraten, dann sieht die Dynamik der infizierten Bevölkerung so aus:

In der Tat nimmt jede dieser Funktionen zu, auch wenn die Infektionrate sinkt, z.B. i2 nach i1: die infizierte Bevölkerung wächst auch bei i1. Aber das ist hier gar nicht die Frage!
Der Pfeil „Infection rate –> sick population“ ist eine monoton steigende Funktion der Infektionsrate, die einem Wert der Infektionsrate eine Anzahl infizierte Menschen zuordnet.

Wir müssen also in der obigen Grafik einen bestimmten Zeitpunkt t0 festhalten und schauen, wie sich die infizierte Bevölkerung in Abhängigkeit der Infektionsrate verhält.

 

Wir sehen, dass das eine monoton steigende Funktion ist, d.h. wenn die Infektionsrate von i2 auf i1 sinkt, dann sinkt auch die dazu gehörende Anzahl infizierter Menschen.

CLD können weitgehende Einsichten vermitteln. Voraussetzung ist, dass sie sauber und präzise eingesetzt werden. Auch ein CLD ist bereits ein Modell! Es hilft bei der Kommunikation eines Sachverhalts und bei der Einschätzung von Fern- und Nebenwirkungen.

Loops machen die Essenz eines CLD aus!

Im Allgemeinen sind CLD zu umfangreich und die Bezeichnungen der Parameter sind suggestiv. Anfänger würden den Pfeil „Infection rate –> sick population“ in Richardsons CLD vielleicht so bezeichnen:

aggressive Infection –> epidemic increasing sick population

in der Meinung, plakative Bezeichnungen würden die Verantwortlichen eher zum Handeln bringen. Aber die Infektionsrate könnte auch niedrig und die Zunahme der infizierten Bevölkerung moderat sein. Deshalb sind neutrale Bezeichnung Voraussetzung brauchbarer CLD.

Wichtig sind die Loops in den CLD. Diese müssten deutlich sichtbar gemacht werden, denn nur sie tragen zur Dynamik bei. Im eingangs erwähnten Artikel stellt Tom Fiddaman ein CLD zur Verfügung, das er zusammen mit Ron Suiter über CO2-Emmissionen entwickelte.

Da die beiden Profis sind, ist das CLD bereits auf einem hohen Niveau. Ich versuchte, ein wirklich wirres CLD zu finden, scheiterte aber an Copyrights. Das Vorgehen, um das es mir hier geht, kann auch am Fiddaman-CLD gezeigt werden. Nicht alle Loops sind direkt ersichtlich (und wenn, dann nehmen wir an, dass nicht). Ich habe das CLD zuerst in insightmaker.com möglichst so übernommen, wie es im Artikel steht. Die drei terminalen Grössen „Out-of-state Cobenefits“, „Out-of-cap California Cobenefits“ und „In-cap California Cobenefits“ habe ich weggelassen, denn sie tragen nichts zum System bei und sind bloss Ablesegrössen, wie ein Stromzähler. Wie üblich, haben blaue Pfeile positive Polarität und rote negative. Wenn Sie auf das Bild klicken, gelangen Sie gleich in den insightmaker.

(https://insightmaker.com/insight/97633/emissions-original)

Dann habe ich mit Hilfe der Funktion „Identify loops“ die Kreise ausgemacht und sie in den Fokus des Diagramms geholt:

(https://insightmaker.com/insight/97711/emissions-kreise)

Erst in dieser Darstellung kommt die Nützlichkeit eines CLD zum Ausdruck: man sieht sogleich, dass der Kreis oben rechts vom übrigen System völlig isoliert ist. Wenn man sich nicht gerade für die drei Grössen, die diesen Kreis bilden – „Reductions Elsewhere“, „Real Emissions Reductions“ und „Control Elsewhere“ – interessiert, könnte man den Kreis sowie alle Pfeile, die zum Kreis hin führen, weglassen. Die Grössen, auf dem Weg zum Kreis, wie z.B. „Real Additional Verifiable Enforceable“ und „Real Offset-driven Reductions“ sind ebenfalls unnütz und reine Massumwandler.

Das CLD reduziert sich auf das System der sechs Kreise in der Mitte des Diagramms. Es sind vier reinforcing Loops und zwei balanced Loops. Meine Erfahrung zeigte, dass sich Kreise ähnlich wie Pfeile verhalten, wenn man die Zuordnung

reinforcing loop –> postivie Polarität
balanced loop –> negative Polarität

macht. Ein Kreis, in welchem eine gerade Anzahl Pfeile negativer Polarität vorkommt, ist reinforcing. Ein Kreissystem in welchem es eine gerade Anzahl balanced Kreise gibt, wäre demnach vermutlich im Gesamten reinforcing. Stimmt diese Vermutung, dann wird sich das Fiddaman-CLD gesamthaft aufschaukeln (oder kollabieren). Um diese Vermutung zu festigen, ist weitere Forschungsarbeit nötig.

Die Analyse der Kreisstruktur eines CLD macht dieses zu einem sehr nützlichen Werkzeug, aller Unkenrufe der Community zum Trotz.

Ein Anforderungsmodell in Migrations- und Integrationsprojekten

Wenn wir Bedürfnisse als „inhaltliches Verständnis der Funktionen“ begreifen, dann können wir in Migrations- und Integrationsprojekten einen kooperativen Prozess des Bewusstwerdens der Anforderungen beobachten, der drei Dimensionen hat:

  • Inhaltsdimension: u(pi,fj) ist der Grad des inhaltlichen Verständnisses für die Funktion fj bei dem Stakeholder pi. u ist ein Skalarfeld.
  • Dokumentationsdimension: d ist der Grad der Dokumentation aller Funktionen fj, für die u(p,fj)>0 für mindestens einen Stakeholder p.
  • Dimension der Tests: C ist die Anzahl der Testfälle, die nicht erfolgreich durchgeführt werden konnten („conditional passed“ oder „failed“), also (Total durchgeführte Testfälle Ctot – erfolgreich durchgeführte Testfälle Cpassed).

Ein Testfall ist ein Run eines Programmteils, welcher eine Funktion vermittelt. Im produktiven Betrieb sind Runs Endkunden- oder Operatorinterventionen. Ein Run kann mit einem Fehler terminieren. Je mehr Testfälle, desto höher der Grad inhaltlichen Verständnisses, aber desto höher die Zahl manifester Fehler.

Ein mögliches Modell dieser Zusammenhänge könnte so aussehen (klicken Sie zum Vergrössern auf die Grafik):

Schon 1993 identifizierte Klaus Pohl drei Dimensionen1, das inhaltliche Verständnis der Funktionen, Grad der Dokumentation und der Grad der Übereinstimmung aller am Prozess beteiligten Stakeholder. Diese Sicht kann aber zu Verwirrungen führen. Die inhaltliche Dimension hängt natürlich vom einzelnen Stakeholder und von der in Frage stehenden Funktion ab. Vielleicht könnte man über alle Stakeholder einen Durchschnitt bilden, aber mindestens betreffend der einzelnen Funktion ist die Inhaltsdimension zu indizieren. Wie wir in Bye, bye Requirements Engineering gesehen haben, sind uns die meisten Funktionen gar nicht bewusst, so dass ein inhaltliches Verständnis von Funktion zu Funktion sehr unterschiedlich aussehen mag. Für einige Funktionen wird es gar nie ein Verständnis geben und braucht es auch gar nicht zu geben. Dadurch fällt die Übereinstimmung als Dimension weg, denn der Übereinstimmungsgrad der Funktion j ist gegeben durch den Wert u(p,j) über alle p.

1Klaus Pohl: The Three Dimensions of Requirements Engineering. CASE 1993: 275-292

Bye, bye Requirements Engineering

Im Zusammenhang mit Anforderungen sind die Funktionen eines Systems zentral. Auch blosse Eigenschaften können Funktionen sein. In Zertifiziert für das Unmögliche: Anforderungen formulieren habe ich gesagt, dass in Migrations- und Integrationsprojekten meistens Standardsysteme zum Einsatz kommen, die allenfalls customized werden. Solche Projekte können nicht vollständig spezifiziert werden, weil niemand in der Lage ist, alle Funktionen eines (Standard-)systems zu kennen. Denken Sie z.B. an ein Automobil, genauer gesagt, einen Personenwagen (PW). Glauben Sie, sie könnten die Funktionen eines PW aufzählen? Wahrscheinlich sind Sie nicht einmal in der Lage, auch nur 10% aller Funktionen eines PW aufzuzählen, und dies nicht nur wegen des Problems unterspezifizierter Initialkonditionen, von dem Fischhoff et al. berichten1. Es gibt immer auch hidden functions. Klaus Pohl berichtet, dass allein die Steuerung einer PW-Elektronik 2’500 Funktionen umfasst2. Jede dieser Funktion ist auch eine Funktion des PW. Natürlich interessieren Sie sich allenfalls für ein halbes Dutzend dieser Elektronikfunktionen, der Rest sind eben hidden functions, mit denen Sie sich gar nicht erst auseinandersetzen wollen. Aber können Sie sicher sein, dass sich nicht eine dieser 2’500 Funktionen für Sie negativ manifestieren wird? Es könnte doch sein, dass sich eine dieser unzähligen Funktionen mit der Zeit für Sie als lästig bemerkbar machen wird. In vollständigen Anforderungen an das System PW hätten Sie diese Funktion ausdrücklich untersagt, wenn Sie sie im Voraus gekannt hätten. Hidden Functions von IT-Systemen, die in komplexe Umgebungen eines informationsintensiven Unternehmens integriert werden müssen, stören oft andere Systeme, weil die Entwickler nicht alle Umgebungen kennen konnten, in welchen ihr System jemals in Einsatz gelangt.

Im übrigen gibt es Funktionen, die eigentlich Funktionenkomplexe sind. Beispielsweise ist doch die wichtigste Funktion eines PW, dass er fahren möge. Meinen Sie „fahren“ oder „transportieren“? In jedem Fall verbirgen sich hinter beiden Funktionenkomplexen viele Einzelfunktionen, wie z.B. vorwärts fahren, rückwärts fahren, im Schritttempo vorwärts fahren, sehr schnell vorwärts fahren. Meinten Sie „transportieren“, so sind Einzelfunktionen eine Person transportieren, mehr als eine Person transportieren, im Rahmen des Strassenverkehrsgesetz transportieren, Waren transportieren, mehr als einen Kubikmeter Waren transportieren, usw. Die Unterteilung eines Funktionenkomplexes ist sehr willkürlich. Wann haben Sie hinreichend unterteilt? Wann haben Sie zu sehr fragmentiert? Was ist überhaupt noch eine Funktion? Schliesslich gibt es Sekundärfunktionen. Z.B. kann ein PW auch die Funktion haben, Ihnen gesellschaftliches Ansehen zu verleihen, oder zumindest Ihnen den Eindruck zu geben, dass Sie wegen Ihres PW zu mehr gesellschaftlichem Ansehen gelangen.

Ein System kann auch implizite Funktionen haben. Das sind solche, die niemand spezifiziert und entwickelt hat. Alle die 2500 Funktionen der Elektroniksteuerung mussten einzeln spezifiziert und implementiert werden. Auch die Funktion, gesellschaftliches Ansehen zu verleihen, wurde zumindest teilweise explizit spezifiziert, z.B. durch ein schnittiges Design oder durch entsprechendes Marketing. Ein Porsche kostet nicht nur so viel, weil er wirklich so gut ist, sondern auch, um eben den Namen Porsche als Nobelmarke zu platzieren. Aber ein PW kann auch Funktionen haben, die nicht spezifiziert worden sind.

Wie wir sehen ist es nie möglich, abschliessend zu sagen, wieviele Funktionen ein System hat oder haben kann. Bye, bye Requirements Engineering!

1B. Fischhoff, P. Slovic & S. Lichtenstein. Fault Trees: Sensitivity of estimated failure probabilitiesto problem representation. Journal of experimental psychology: Human Perceptions and Perfomance. 4/1978, 330-334

2Klaus Pohl. Leitfaden für modellbasiertes Requirements Engineering und Requirements Management softwareintensiver Eingebetteter Systeme
gefördert durch das BMBF im Rahmen der Forschungsoffensive „Software Engineering 2006“