Fragenkultur – Wie man vermeidet den Fokus zu verlieren

Fokus nicht zu verlieren und produktiver Arbeiten im Team. Wer will dass nicht. Die Wirklichkeit sieht dagegen meist anders aus.

Man nimmt an einem Team-Meeting teil, und es wird viel diskutiert. Es geht irgendwie nicht weiter und man dreht sich immer im Kreis.

Man arbeitet an einem Thema und scheint sich in Details zu verlieren oder ist überwältig von der Informationsflut.

Die Ursache liegt meist dann daran, dass man den Fokus verloren hat. Den Fokus verlieren bedeutet in diesem Zusammenhang, dass man den Ausgangspunkt aus dem Blickwinkel verliert.

Um diesem zu entgegnen, habe ich für mich eine einfache Methodik entwickelt.

Die Methodik nenne ich gerne #piat@feedback

Im Mittelpunkt der Methodik #piat@feedback, steht das Stellen von essentiellen Fragen (näheres zu Fragen, siehe mein vorheriger Beitrag zur Fragenkultur.

Definiere den Fokus

Zunächst gilt es zu definieren, was alles ein Haupt-Fokus sein kann.
Die 5 wichtigsten Perspektiven sind herbei:

  1. Betrachte ich ein Problem, um die Ursachen zu verstehen
  2. Suche ich nach einer Idee für die Lösung eines Problems
  3. Möchte ich eine Lösungsidee weiter ausarbeiten und die Lösung dann umsetzen
    4.Bin ich gerade dabei etwas zu validieren oder zu verifizieren
  4. Oder geht es darum, Feedback einzuholen

Abbildung: Den Fokus im Fokus haben

Was beinhalten die verschieden Perspektiven?

Perspektive – Problem verstehen

Bei der Problem-Perspektive stehen alle Fragen im Vordergrund, um einen tieferes Verständnis und Wissen über ein Problem und deren Ursache zu erhalten. Typische Fragen sind zum Beispiel:

  1. Was ist das Problem?
  2. Warum stellt sich das Problem?
  3. Wie wichtig / relevant ist das Problem?
  4. Was sind die Auswirkungen und Risiken, wenn wir uns nicht um das Problem kümmern?
  5. Betrachten wir denn das richtige Problem?

Die Erwartung dabei ist, dass die Antworten auf die Fragen uns ein tieferes Wissen über das Problem vermittelt. Denn erst wenn wir ein Problem genau verstanden haben, können wir eine angemessene Lösung finden und entwickeln.

Das Problem im Fokus
Abbildung: Das Problem im Fokus haben

Perspektive – Ideen entwickeln

Bei der Idee-Perspektive geht es um das Finden einer angemessenen Lösung für ein wohldefiniertes Problem. Voraussetzung ist somit, daß ein angemessenes Verständnis des Problem vorhanden und definiert ist.
Hierbei stehen alle Fragen im Vordergrund, die dazu beitragen Ideen zu finden und zu entwicklen (Ideen-Findungsphase) . Typische Fragen sind zum Beispiel.

  1. Welche Lösungen gibt es?
  2. Wie könnte eine Lösung aussehen?
  3. Wie sollte eine Lösung sein, das Problem auf keinen Fall löst?
  4. Welche funktionalen Anforderungen muss eine Lösung erfüllen?
  5. Welche Eigenschaften muss eine Lösung haben?
  6. Wie gut muss die Lösung die Eigenschaften erfüllen?
Die Idee im Fokus haben
Abbildung: Die Idee im Fokus haben

Perspektive -Lösung ausarbeiten

Bei der Ausarbeitungs-Perspektive geht es darum, eine Lösung im Detail zu beschreiben. Hierbei gilt es zu hinterfragen, wie die Lösungen aussehen sollen und ob diese Lösung angemessen und handhabbar ist. Typische Fragen hierbei sind:

  1. Welche Komponenten werden benötigt?
  2. Wie sehen die Schnittstellen aus?
  3. Welche Technologien sollen zum Einsatz kommen?
  4. Wie könnte der Workflow aussehen?
  5. Welche organisatorischen Maßnahmen sind notwendig?
  6. Welche Ressourcen werden benötigt?
  7. Welche administrativen Aufgaben sind damit verbunden?
  8. Wie sieht die Lösung im Detail aus?

Um verschiedene Optionen nicht vorzeitig zu verwerfen, haben sich Was, wäre wenn wir …. Fragen bewährt. Solche Fragen sind hypothetisch und bauen Barrieren ab, über eine Option nachzudenken.

Unter Komponenten werden hier alle Elemente wie Software, Hardware, Ressourcen, Systeme, Berechtigungen, Abläufe usw. verstanden, die zur Lösung des Problem benötigt werden.

Ausarbeiten im Fokus
Abbildung: Das Ausarbeiten im Fokus haben

Perspektive – Lösung testen, alles kommt auf den Prüfstand

Bei der Test-Perspektive geht es darum, wie die erarbeiteten Ergebnisse überprüft werden können, das Ergebnis somit belastbar ist.

Typische Fragen hierbei sind:

  1. Was sind die Erfolgs-Kriterien?
  2. Wie kann ich die Kriterien prüfen?
  3. Welche quantitativen Kriterien können angewendet werden?
  4. Welche Skala ist anzuwenden?
  5. Wie sind die Kriterien zu gewichten?
  6. Welche Risiken gibt es?
  7. Wie sind diese Risiken zu bewerten?
Testen im Fokus
Figure:Testen im Fokus haben

Perspektive – www.feedback – wie denken andere

Bei der Feedback-Perspektive geht es darum, sich Meinungen anderer einzuholen und deren Einschätzung zu bewerten. Dies ist notwendig, um Sachverhalte besser bewerten zu können.

Hierbei ist es wichtig, das Feedback von der richtigen Zielgruppe einzuholen. Die richtige Zielgruppe ist die Personengruppe, die mindesten eine der folgenden Fähigkeiten besitzt:

  • Fachliche Vorkenntnisse besitzen
  • Technologisches Kenntnisse besitzen
  • Methodische Kenntnisse besitzen
  • alle, die direkt oder indirekt von der Umsetzung betroffen sind

Aus dieser kleinen Auflistung wird ersichtlich, dass es nicht nur eine Zielgruppe gibt. Vielmehr ist die Auswahl der Zielgruppe für das Einholen von Feedback, abhängig von der jeweiligen Perspektive und deren Ergebnisse.

Feedback im Fokus
Figure:Feedback im Fokus haben

Wie wendet man dies in der Praxis an?

Für das Betrachten der unterschiedlichen Perspektiven bieten sich in der Praxis folgende Optionen an

  1. Es werden unterschiedliche Personen benannt, die sich am besten in den verschiedenen Perspektiven auskennen. Sogenannte Subject-Matter-Experts oder kurz SMEs.
  2. Ein und der selbe Personenkreis versucht sich mental in getrennten Sitzungen in die verschiedenen Perspektiven hineinzuversetzen. Ähnlich der Walt-Disney-Methode

Da es Menschen im allgemeinen schwerfällt, sich mental in eine Perspektive dauerhaft hinein zu versetzten, bietet es sich an, für die einzelnen Perspektiven eine separate räumliche Umgebung zu schaffen. Dies erfolgt am einfachsten, in dem man getrennte Räume schafft, in die man sich begibt und entsprechend der Perspektive eingerichtet sind. Am besten ist es somit, wenn man sich auch physikalisch in einem solchen Raum befindet.

Die nachfolgende Abbildung zeigt, einen Grundriss mit verschiedenen Räumen. Jeder Raum steht für einen Fokus bzw. Perspektive. Wenn man sich in einem der Räume befindet, liegt der Fokus auf dem Fokus des Raumes.

denken in Räumen
Abbildung: Das Denken in Fokus-Räumen

Wie werden die Räume genutzt

Bei der Nutzung des Räume geht darum, mit dem Problem-Raum zu beginnen und anschliessend in andere Räume zu wechseln. Wichtig ist dabei, das jeder Raumwechsel über den Feedback-Flur erfolgt. Sofern notwendig, kann man aus dem Feedback-Flur wieder in den Ausgangsraum zurück gehen, sofern dies notwendig erscheint.

Nachfolgende Abbildung stellt ein solches Szenario bildlich dar.

Abbildung :  Ein Szenario 

Sowohl der mentale als auch der physikalische Wechsel in einen eigenen Raum ist ungemein hilfreich den Fokus zu behalten.

Die Ausgestaltung der physikalischen Räume sollte so erfolgen, daß der jeweilige Raum mit technischen Hilfsmittel und dem entsprechenden Ambiente den jeweiligen Fokus des Raumes unterstreicht.

Ein Szenario nach dem klassischen Wasserfall  Model  würde sich wie folgt beschreiben lassen.

Szene Wasserfall

Abbildung: Szenario – Wasserfall

Ich hoffe, der Beitrag hat Sie dazu inspiriert, dies selbst auszuprobieren. Hierbei wünsche ich Ihnen viel Erfolg, und ich hoffe Sie haben auch Spaß dabei.

Katgeorie:Methodik, VisualPedia | Kommentare deaktiviert für Fragenkultur – Wie man vermeidet den Fokus zu verlieren

Fragenkultur – Grundlage für eine erfolgreiche Softwareentwicklung

 

Der Hauptfokus bei der Softwareentwicklung liegt in den meisten Fällen auf der Lösungsdiskussion.
In diesem Beitrag versuche ich zu erklären, warum es notwendig ist eine Fragenkultur zu entwickeln, um bessere Lösungen zu finden.

Wer kennt nicht das nachfolgende Phänomen? Es werden Anforderungen gesammelt, eine Projektplanung aufgesetzt und Teams eingeteilt. Bei Agilen-Projekten, werden User Stories erstellt und herunter gebrochen auf Basis des INVEST-Prinzips.
Man hat scheinbar alles „richtig“ gemacht. Und trotzdem gibt es sowohl bei der Erstellung der System-Architektur als auch bei der Implementierungsphase Diskussionen darüber, was das Ziel der Software ist .
Diesem Phänomen will ich in diesem Beitrag nachgehen.
Hierbei geht es weniger um die Frage nach den Ursachen und den Methodiken. Hier geht es vielmehr um die Frage nach der „Kommunikationskultur“ und wie man das oben beschriebene Dilemma verhindern oder zumindest mildern kann.

Die richtigen Fragen Stellen?

Was soll ich fragen
Abbildung: Was soll ich fragen

Als meine Kinder in die Schule kamen, haben sie sich richtig auf das Lernen gefreut. Jedoch nach 3-4 Wochen war es mit der Freude vorbei.
Wenn ich in einem Meeting bin oder wenn ich eine Präsentation halte, dann stelle ich fest, dass die Anzahl der Fragen nahezu Null ist.

Eine Erklärung für beide Phänomene habe ich in dem Buch von Warren Bergen gefunden mit dem Titel

Die Kunst des klugen Fragens.

Beim Lesen des Buches wurde mir bewusst, dass unsere Lern- und Kommunikations-Kultur auf Antworten fokussiert ist. Lösungen werden in den Mittelpunkt stellt. In der Schule, bei der Ausbildung und auch im Berufsleben liegt der Fokus auf dem Finden von Antworten. Hierbei wird vergessen zu beachten, ob es sich um die richtige Fragestellung handelt.
Viel wichtiger ist zunächst zu hinterfragen, was das Problem ist. Fragen helfen dabei, Dinge besser zu verstehen. Wer Dinge und Probleme besser versteht, kommt zu besseren Lösungen.

 

Wichtigkeit von Fragen

 

Abbildung: Wichtigkeit des Fragens

Aufgrund dieser Erkenntnis bin ich dazu übergegangen in Meetings und Präsentationen, mich auf Fragen zu konzentrieren. Dabei habe ich festgestellt, dass meine Präsentation einen höheren Mehrwert für die Zielgruppe bietet und Meetings einen viel konstruktiveren Verlauf nehmen, wenn sichergestellt ist, das die Fokus-Frage ist.

Offene Fragen sind hierbei wichtig, da man dadurch die Kontrolle abgibt und viel mehr Informationen von dem Kommunikationspartner erhält als bei geschlossenen Fragen.

Geschlossene Fragen

 

Abbildung: Geschlossene Fragen
Offene Fragen

 

Abbildung: Offene Fragen

Was bedeutet dies für die Erstellung einer System-Architektur?
Dies möchte ich nachfolgend näher ausführen.

Hierzu ist es zunächst notwendig, zu klären, was sind denn die richtigen Fragen.

Was sind die richtigen Fragen?

Richtige Fragen gibt es nicht. Dies würde implizieren, dass es auch falsche Fragen gibt.
Somit ist die Überschrift für diesen Abschnitt irreführend und ist eher provokativ gemeint.

Viel besser ist es die Fragen nach geschickt oder ungeschickt zu unterscheiden. Das Unterscheidungsmerkmal ist hier bei sehr einfach.

Wenn wir eine Frage haben und erwarten, dass wir aus der Antwort konkrete Hinweise erhalten, die uns weiterbringen, dann ist dies eine wichtige Frage und es ist sinnvoll dieser Frage weiter auf den Grund zu gehen.

Handelt es sich jedoch um eine Frage, von deren Antwort wir keine oder wenig Hinweise erwarten, die uns weiterhelfen, dann ist dies eine Frage, die eher ungeschickt ist und deren Beantwortung zunächst zurückgestellt werden oder ggf. verworfen werden sollte. Solche Fragen gehören eher in den Bereich der Philosophie.

Fragen geschickt stellen

 

Abbildung: Gute Frage

Nach diesem Prinzip lassen sich alle Fragen entsprechend priorisieren. Dies bedeutet, wir legen fest, welche Fragen am wichtigsten ist und deren Antwort zunächst geklärt werden sollte, bevor andere Fragen zu klären sind.
Priorisieren ist ein sehr wichtiger Schritt, um zu vermeiden, dass man zu früh in eine Detaildiskussion eintritt.

In der Software-Entwicklung bedeutet dies, dass zunächst die Fragen nach fachlichen Anforderungen zu klären sind, bevor Fragen nach Technologien zu klären sind.

Wie finde ich den Einstieg in die Fragen.

Ausgangspunkt bei jeder Produktentwicklung sind die sogenannten zentralen Fokus-Fragen.
Die zentralen Fokus-Fragen lassen sich einem Fragen-Quadrat für die W-Fragen verdeutlichen.
Betrachten wir hierzu die nachfolgende Abbildung.


 

Abbildung: Das Fragen-Quadrat

Block A. Entwickle ich das RICHTIGE Produkt?

Hier geht es um die Fragen

  • Was ist das Problem?
  • Warum stellt sich das Problem?
  • Wie wichtig ist die Lösung für den Anwender?
  • Wie sieht der Problem-Kontext aus?
  • Wer hat diese Problem?
  • Wie häufig stellt sich das Problem?
  • Welche Randbedingungen sind bei der Umsetzungen der fachlichen Anforderungen zu beachten?

Die Antworten liefern einen Hinweis, über das Ziel und die Bedeutung des Produktes/System für einen Kunden.

Diese Art von Fokus-Fragen sind wichtig, wenn es um

  • das Finden einer Business Strategie
  • die Definition eines Produkt-Portfolios
  • die Festlegung der Anforderungen an ein Software Produkt oder einer Dienstleistung

Bei der agilen Softwareentwicklung sind dies die entscheidenen Fragen, die sich jeder Produkt-Owner stellen muss.

Block B. Entwickle ich das Produkt RICHTIG?

Hier geht es darum, zu hinterfragen, wie fachliche Anforderungen umzusetzen sind. Voraussetzung hierfür ist, dass die fachlichen Anforderungen verstanden und verschriftlicht wurden.

Fragen hierzu sind:

  • Wie sehen die fachlichen Anforderungen aus?
  • Wie sind die fachlichen Anforderungen umzusetzen?
  • In wie weit bestehen technologische Randbedingungen?
  • Welche Schnittstellen sind zu definieren und wie sind diese zu definieren?
  • Wie sieht der Lösungs-Kontext aus?

Für die Lösungsdiskussion bieten sich hier folgende Fragetypen an:

  • navigierende Fragen
  • schliessende Frage

Navigierende Fragen sind „Was wäre wenn,..“

Fragen. Sie haben fiktiven Charakter und fördern die Kreativität. Es lädt ein über eine mögliches Umsetzungsszenario offen nach zudenken. Dies ist wichtig, da speziellen in der Entwicklung bei eventuellen Lösungsvorschlägen sofort an die Machbarkeit und den Aufwand der Implementierung gedacht wird und im Vorfeld Lösungsansätze verworfen werden, da der Aufwand zu hoch oder zu schwierig eingeschätzt wird.

Schliessende Fragen sind „Wie machen wir es genau….“.

Sie helfen, Design-Entscheidungen herbeizuführen, die als Grundlage für weitere Design-Entscheidungen notwendig sind.

Block C. Entwickle ich das RICHTIGE Produkt* zur RICHTIGEN Zeit?

Mit diesem Bereich beschäftigt sich das Projekt Management.
Die Fragen wie:

  • Wann ist das Produkt / die Dienstleistung verfügbar?
  • Was ist in dem Produkt enthalten?
  • Was wird das Produkt kosten?

und viele mehr, ergeben sich aus dem angestrebten Business heraus.

Schnittpunkt zur Erstellung der System-Architektur besteht bei der agilen Softwareentwicklung darin, sich bzgl. der Sprint-Planung abzustimmen. Das Ergebnis eines Sprints ist ja verhandelbar.

Wie wende ich dies in der Praxis an?

Die Fokus-Fragen aus dem Fragenquadrat haben sich bei der Vorbereitung auf folgende Themengebiete bewährt. Dort habe ich sie als erstes ausprobiert.

  • Vorbereitung auf ein Kick Off Meeting zum Projektstart
  • Bei der Erstellung der Präsentation oder einem Vortag
  • Vorbereitung auf eine Besprechung
  • Beim Erlernen einer neuen Technologie
  • Anwendung innerhalb einer Besprechung, um den Fokus nicht zu verlieren

Hierzu habe ich folgendes Vorgehen für mich entwickelt, welches mir hilft effektiver zu arbeiten und zu lernen, den Fokus während einer Besprechung nicht zu verlieren und hilft bei der Anforderungsanalyse effektiver zu sein.


Vorgehen bei der Entwicklung von Fragen

Figure: Workflow
  1. Ich starte zunächst mit einer leeren Seite Papier bzw. leerem Editor Fenster.
  2. Ich wende Brainstorming an, um die wichtigsten W-Fragen zu dem Thema aufzuschreiben. Hierbei hilft das Fragen-Quadrat. Ich schreibe alles auf und nehme keine Bewertung vor.
  3. Danach gruppiere ich die Fragen. Hierbei packe ich alle Fragen, die in die gleiche Richtung zielen in eine Gruppe.
  4. Danach lege ich für die einzelnen Gruppen fest, welche Antworten ich als erstes benötige, um dann ggf. weitere Fragen zu stellen.
  5. Abschliessend prüfe ich, in wie weit es sinnvoll ist, Fragen zu präzisieren oder weiter herunter zu brechen.
  6. Stoße ich bei dem Brainstorming oder bei der Vorbereitung auf Aussagesätze, dann formuliere ich eine Aussage in ein offene Frage um. Dies fördert zusätzlich meine Kreativität.

Mein Tip für den Alltag

Einfach bei dem nächsten Meeting, sich mitten in einer Detail-Diskussion melden, um eine grundlegende Frage zu stellen. Siehe nachfolgende Abbildung.

Tipp für die Praxis

 

Figure: Praxis-Tipp

Persönlich Anmerkung:

Über Feedback und konstruktive Kritik würde ich mich freuen.

Katgeorie:Methodik, Produktivität | Kommentare deaktiviert für Fragenkultur – Grundlage für eine erfolgreiche Softwareentwicklung

Systemarchitektur und Cohesion

Um was geht es hier?

In diesem Beitrag möchte ich kurz eine Entwurfsrichtlinie mit dem Namen ‚Bindung‘ (Cohesion) vorstellen.

Hintergrund hierbei ist folgende Frage?

Worauf muss ich bei der Erstellung einer System-Architektur achten, damit die angestrebte Lösung die Eigenschaften besitzt, wie:

  • Wartbarkeit
  • Änderbarkeit
  • Verständlichkeit
  • Austauschbarkeit

Die Antwort hierauf lautet:

„Achte auf den Grad der Bindung zwischen den Elementen die zu einer Komponente gehören!“

Was hierunter zu verstehen ist und auf was man in der Praxis achten muss, möchte ich nachfolgend kurz vorstellen.

Was bedeutet Bindung?

Bindung ist ein Maß, wie eng die Elemente zusammenhängen, die zu einer Komponente gehören.

Cohesion-Intro
Figure:Bindung

Somit beschreibt die Bindung den Grad der Zusammengehörigkeit der Elemente einer Komponente.

Es ist anzustreben, dass die Bindung möglichst hoch ist (im Sinne von starker Bindung). Alle Elemente sollen zu der Lösung einer Aufgabe bzw. der Verantwortlichkeit einer Komponente Beitragen.

Warum soll die Bindung stark sein?

Besitzen alle Elemente einer Komponente eine starke Bindung, dann ist die Komponente:

  • Einfacher auszutauschen
  • Einfacher wiederzuverwenden
  • Einfacher zu testen
  • Einfacher zu verstehen
  • Einfacher zu ändern

Stellt sich nun die Frage:
Wie erkenne ich den Grad der Bindung der einzelnen Elementen?

Wie erkenne ich den Grad der Bindung einer Komponente?

Um den Grad der Bindung zu erkennen stellt sich zunächst die Frage:

Frage 1: Hat die Komponente genau eine Verantwortlichkeit/Aufgabe?

Ob eine Komponente genau eine Verantwortlichkeit hat kann man an dem Namen der Komponente erkennen.

Besteht der Name einer Komponente aus einem Substantiv, welches die Verantwortlichkeit exakt beschreibt, dann ist dies ein Indiz dafür, dass der Grad der Bindung zwischen den Elementen hoch ist.
Positiv Beispiele:
* DeviceListe
* Zugangskontrolle

Negativ Beispiel:
* SearchAndVerifyUpdateBook

Frage 2: In wie weit tragen alle Elemente einer Komponente zur Erbringung der Verantwortlichkeit bei?

Die nachfolgende Abbildung visualisiert, wie man sich eine hohe Bindung vorstellen kann

Cohesion-Hohe Bindung
Figure: Hohe Bindung

Bei einer hohen Bindung gibt es einen guten Grund, warum die Elemente innerhalb dieser Komponente zu finden sind.

Im Gegensatz hierzu zeigt die nachfolgende Abbildung eine Visualisierung, wie man sich eine geringe Bindung vorstellen kann.

Cohesion-Niedrige Bindung
Figure: Geringe Bindung

Eine geringe Bindung der Elemente einer Komponente zeigt sich unter anderem an dem Namen einer Komponente. Allgemeine Namen wie „Utilities“ oder „Control“ deuten darauf hin, dass die Element wenig oder nichts miteinander zu tun haben.

Um den Grad der Bindung besser versehen zu können, schauen sind nachfolgend einige Beispiele aufgeführt.

Bindung am Namen erkennen

In der nachfolgende Abbildung sind 3 Java Klassen mit ihren Methoden aufgeführt.
An den Namen der Methoden kann man erkennen, dass der Grund, warum die Methoden in dieser Klasse angesiedelt sind, auf der Funktion READ oder WRITE basiert. Dies ist ein schwacher Grund. Änderungen in einer Methode zieht sehr wahrscheinlich Änderungen in einer anderen Klasse nach sich. Ein Kapseln nach Datenstrukturen würde hier das Design verbessern.

Cohesion-Java-Sample
Figure: Java Beispiel- geringe Bindung

Dieses einfache Beispiel zeigt, dass sich die Bindung der Methoden einer Klassen an dem Namen erkennen lassen.

Bindung an der Beziehung erkennen

Die Art der Beziehung, warum einzelne Elemente zusammen gefasst werden, liefert ein Aussage, über den Grad der Bindung.
Hierbei spielt es keine Rolle, von welcher Art die Elemente sind.
Bei den Elementen kann es sich um:

  • Anweisungen in einer Funktion oder Methode handeln
  • Methoden, die in einer Klasse angesiedelt sind
  • Klassen, die in einem Package zu finden sind
  • Funktionen, die in einer Library (.a,.so,*.dll) zu finden sind
  • Komponenten, die gemeinsam installiert werden
  • Komponenten die Zusammen einen Dienst erbringen

In der nachfolgenden Tabelle habe ich die wichtigsten Gründe aufgeführt und den Grad der Bindung klassifiziert.

Grund Grad der Bindung
Alle Elemente tragen zur Lösung einer Funktionalen Anforderung bei sehr hohe Bindung
Die Element müssen in einer vorgegebenen Reihenfolge ausgeführt werden, die sich aus der Aufgabenstellung heraus ergibt hohe Bindung
Die Element müssen immer in dieser Reihenfolgen ausgeführt werden, aufgrund des gewählten Designs schwache Bindung
Es gibt einen besonderen Grund. Die Elemente müssen irgendwo abgelegt werden sehr schwache Bindung

In der Praxis wird man aber selten eine klare Abgrenzung finden. Oft findet man ein Mischform vor und mehrere Gründe treffen zu.

Zur Vertiefung

Zur Vertiefung möchte ich das Buch

Meilir Pages Johns, Structured Design

In diesem Buch wir sehr gut und ausführlich auf Coupling und Cohesion eingegangen. Die vielen Beispielen aus der Praxis, helfen das Wissen über Kopplung (Coupling) und Bindung (Cohesion) zu vertiefen.

Katgeorie:Methodik | Kommentare deaktiviert für Systemarchitektur und Cohesion

Systemarchitektur und Coupling

Um was geht es hier?

In diesem Beitrag möchte ich kurz eine Entwurfsrichtlinie mit dem Namen Kopplung(engl.Coupling) vorstellen.

Hintergrund hierbei ist folgende Frage?

Worauf muss ich bei der Erstellung einer System-Architektur achten, damit die angestrebte Lösung die Eigenschaften besitzt wie:

  • Wartbarkeit
  • Änderbarkeit
  • Verständlichkeit
  • Austauschbarkeit

System-Design und Wartung

Die Antwort hierauf lautet:

„Achte auf den Grad der Kopplung zwischen den Komponenten!“

Was hierunter zu verstehen ist und was in der Praxis beachten ist, möchte ich in diesem Beitrag kurz vorstellen.

Zunächst stellt sich aber die Frage: Was bedeutet Kopplung?

Was bedeutet Kopplung?

Kopplung ist ein Maß, wie eng oder lose zwei Komponenten miteinander gekoppelt sind.

Coupling-Intro
Figure: Kopplung zweier Komponenten

Somit beschreibt die Kopplung den Grad der Abhängigkeit einer Komponente nach außen hin.

Es ist anzustreben, dass die Kopplung zwischen allen Komponenten eines Systems lose ist (im Sinne von gering).

Warum soll die Kopplung lose sein?

Ist eine Komponente mit einer losen / geringen Kopplung zu anderen Elementen, dann ist diese Komponente:

  • Einfacher auszutauschen
  • Einfacher wiederzuverwenden
  • Einfacher zu testen
  • Einfacher zu verstehen
  • Einfacher zu ändern
Coupling und Maintenace
Figure: Kopplung und Eigenschaften

Stellt sich nun die Frage:
Wie erkenne ich den Grad der Kopplung einer Komponente?

Wie erkenne ich den Grad der Kopplung einer Komponente?

Kopplung ist ein Maß für die Unabhängigkeit von Softwarekomponenten. Der Grad der Kopplung ist somit eine skalare Größe.
Hierbei unterscheiden man zwischen direkten oder indirekten Abhängigkeiten.

Direkte Abhängigkeiten sind:

  • Alle Kenntnisse darüber, wie ich eine andere Komponente ansteuern muss um sie zu verwenden
  • Alle Annahmen darüber, die ich über die andere Komponente mache

Indirekt Abhängigkeiten sind:

  • alle Elemente, die die andere Komponente benötigt um ihre Funktion zu erbringen.

Schauen wir uns als nächstes ein paar Beispiele an, um den Grad der Kopplung besser zu verstehen.

Beispiel bei der Verwendung einer JAVA Klasse / Apis

Nachfolgend ein Beispiel aus der Java-Welt.

Coupling und Java API
Figure: Beispiel Java

Beispiel bei der Verwendung eines RESTful APis

RESTFUL API siehe Restfulapi.net

Coupling und Restful API
Figure: Beispiel RESTFul API

Mögliche weitere Coupling-Aspekte können sein:

  • Annahmen über Zeitzone des Kommunikationspartners
  • Annahmen über Zeichenkodierungen (nicht UNICODE Standards)
  • Annahmen über Datenformate wie Datumsangaben, Nummernformate uns.
  • Annahmen über das Format von Textnachrichten (i.e. Sprache)

Beispiel bei der Verwendung von MQTT

MQTT siehe mqtt.org

Wie nachfolgender Abbildung zu entnehmen ist, besteht bei der Verwendung von MQTT zusätzlich zu dem verwendeten API die Abhängigkeit zu dem Topic Schema und dem Paylod einer Nachricht.

Couplimg und MQTT
Figure: Beispiel MQTT

Tip für die Praxis

Indikator Grad der Kopplung
Ich kenne von der anderen Komponente nur die Schnittstelle und die Daten geringe Kopplung
Die Methoden der anderen Komponente muss man in einer vordefinierten Reihenfolge aufrufen mittlere bis hohe Kopplung
Ich weiß, wie die andere Komponente funktioniert und welche Zustände sie annehmen kann hohe Kopplung
Coupling in der Praxis
Figure: Kopplung in der Praxis
Katgeorie:Methodik | Kommentare deaktiviert für Systemarchitektur und Coupling

System Architekturen erstellen (Part 2)

Um was geht es hier?

Jeder der in einer Situation war, eine Systemarchitektur definieren zu müssen, ist auf folgende Herausforderungen gestoßen.

  • Wie komme ich zu einer System Architektur.
  • Wie kann ich meine System-Architektur dokumentieren?

Auf die erste Frage, bin ich in meinem vorherigen Eintrag eingegangen. In diesem Beitrag möchte ich auf die zweite Frage eingehen.

Wie finde ich einen ersten Entwurf einer System-Architektur

Hierfür bieten sich folgende Ansätze an:

Ausgangspunkt Vorgehen
Ein ähnliches System wurde in der Vergangenheit bereits erstellt Man startet mit der bereits verwendeten System-Architektur und passt diese an das Projekt an
Referenz-Architektur Man startet mit einer Referenzarchitektu,r für die zu unterstützende Platform. Zum Beispiel JAVA2EE
Architektur Pattern Man startet mit einem Architektur-Pattern. Ggf werden mehrere Pattern angewendet, die sich ergänzen.

Wie kann ich die System-Architektur beschreiben

Fachliche Anforderungen sind im Allgemeinen stabiler als technische Anforderungen. Stabil bedeutet, dass diese weniger volatil sind bzw. sich ändern.

Oder mit anderen Worten:
„Technologien ändern sich schneller als die fachlichen Anforderungen“

Für die System-Architektur bedeutet dies, das wir uns auf das High-Level Design beschränken.

Intermediate und Low-Level Design ersparen wir uns bei der Dokumentation.

Für die Definition und Beschreibung der wichtigsten Informationen im High-Level Design haben sich in der Praxis folgende Notation/Visualisierungen bewährt.

Die Fokus-Frage Notation
Was gehört zum System? Kontext-Diagramm
Wie trenne ich fachliche und technische Dienste? DDD Hexagon Diagramm
Wie beschreibe ich, wie die Daten verarbeitet werden? Datenfluss-Diagramm
Wie beschreibe ich, aus welchen Teilen/Komponenten mein System besteht? Struktur / Blockdiagramme
Welche Daten werden gespeicherte Datenmodelle

Für die weitere Vertiefung zur Erstellung von System-Modellen empfehle ich die Seite:
Blockdiagramme

Katgeorie:Methodik | Kommentare deaktiviert für System Architekturen erstellen (Part 2)

System-Architekturen erstellen (Part 1)

Um was geht es hier?

Jeder, der schon einmal in einer Situation war, eine Systemarchitektur definieren zu müssen, ist auf folgende Herausforderungen gestoßen.

  • Wie komme ich zu einer System Architektur?
  • Wie kann ich meine System-Architektur dokumentieren?

Auf die erste Frage möchte ich in diesem Beitrag eingehen und einen Leitfaden vorstellen, der den Einstieg in die Welt der System-Architekturen erleichtern soll. Auf die zweite Fragen werde ich in einem nachfolgenden Beitrag eingehen.

Big Architecture – Front up

Dies ist der  klassische Ansatz.

  • Sammeln aller Anforderungen
  • Definiere anschliessend eine System Architektur, die alle Anforderungen erfüllt.

Big-Bag Vorgehen
Abb.: Big Architecture Front – Up

In der Praxis stellen sich hierbei folgende Nachteile heraus:

  • Das Sammeln der Anforderungen erfordert zum Teil viel Zeitaufwand
  • Feedback und Beurteilung der gewählten System-Architektur erst möglich, nachdem alles umgesetzt ist.

Bessere und schnellere Erfolge erziehlt man daher mit einem agilen Ansatz.

Der agile Ansatz

Beim agilen Ansatz lautet das Prinzip:

YAGNI -> You aren’t gonna need it

Vergleiche: Dzone yagni-a-quick-introduction

Dies bedeutet, dass in der Architektur nur dann Komponenten und Subsystem eingeführt werden, wenn diese auch wirklich benötigt werden.

System-Modell schrittweise entwerfen

Abb.: Agiler Ansatz

Das Vorgehen ist hierbei wie folgt:

Schritt Tätigkeit
1 Bestimme die minimalste Menge von Features, die im ersten Schritt umgesetzt werden müssen
2 Definiere eine dazugehörige System-Architektur
3 Implementiere die System-Architektur
4 Prüfen, ob die System-Architektur die gewünschten Funktionen und Eigenschaften besitzt (Erfahrung sammeln)
5 ggf. Re-Factoring der System-Architektur
6 Definiere und bestimme die Menge der Features, die im nächsten Schritt unterstützt werden sollen/müssen.
7 Wiederhole Schritt 2 bis Schritt 6 so lange, bis alle Anforderungen/Features umgesetzt sind.

In der Praxis bedeutet dies, dass in Schritt 2 die System-Architektur ggf. erweitert oder geändert werden muss (Re-Factoring) um die jeweiligen Features zu implementieren.

Aus dem Vorgehen wird ersichtlich, dass

  • man sehr schnell zu einem lauffähigen System kommt
  • frühzeitig Erfahrung machen kann um das System-Model  zu verifizieren
  • Das System-Modell wächst mit der Zeit  und deckt genau die Anforderungen ab,  die benötigt werden.
  • Ein Over-Engineering  wird vermieden

Katgeorie:Methodik | Kommentare deaktiviert für System-Architekturen erstellen (Part 1)

TDD – Test Driven Development

Die nachfolgende Abbildung habe ich auf  auch Pinterest veröffentlicht. Es zeigt die wichtigsten Aspekte zum Thema Test-Drive-Development.  Es soll motivieren sich mit dem Thema  näher zu beschäftigen oder einfach auch nur als Gedankenstütze für alle, die sich schon mit TDD beschäftigt haben.

Die Abbildung visualisiert die Antworten  auf die zentralen Fragen zum Thema TDD:

  • Was ist TDD?
  • Warum ist TDD sinnvoll?
  • Wie funktioniert TDD ?

TDD im Überblick
Abbildung: TDD im Überblick

Katgeorie:Methodik | Kommentare deaktiviert für TDD – Test Driven Development

Testcase Design != Testcase Design

Tescase Design is not equal Testcase design
Testcase Design ist nicht gleich Testcase Design

In meinem letzen Beitrag habe ich dargestellt, dass die Definition einer Software Architektur auf unterschiedlichen Abstraktions-Ebenen stattfindet und auf jeder Ebene unterschiedliche Ziele, Arbeitsweisen und Fähigkeiten gefordert werden. Ähnlich ist es auch bei der Spezifikation von Testfällen.

Die Abbildung spiegelt die Testfallerstellung anhand der unterschiedlichen Architektur-Ebenen wider. Hierbei sieht man sehr deutlich, dass die Zielsetzung der Testfall-Spezifikation sehr unterschiedlich sein kann.
Auf der Komponenten-Ebene geht es eher um Entwickler-Tests (z.B. mit JUnit) und um entwicklungsbegleitendes Testen.
Auf der Service-Ebene geht es eher um das Testen von Szenarien und Workflow Sequenzen und um Integrationstests.

Darüber hinaus ist auch zu sehen, dass ein Test-Design, Controlling und Test-Automatisierung auf jeder Ebene notwendig ist.

Katgeorie:Methodik | Kommentare deaktiviert für Testcase Design != Testcase Design

Software Architektur != SW Architektur

Die Abbildung in diesem Beitrag entstand  bei der Frage:  „Was macht eigentlich ein Software Architekt „?. Hieraus ergab sich dann die Frage: „Was ist eine Software Architektur überhaupt“?.

SW arch != SW Arch
Software Architektur ist nicht gleich Software Architektur

Nun die Abbildung zeigt in vereinfachter Darstellung, dass es  die „Software Architektur“ und den „Software Architekten“ so gar nicht gibt.

Die unterschiedlichen Aufgabenfelder verlangen nach Personen mit unterschiedlichen Talenten und Kenntnissen wie

  • Algorithmen-Designer
  • Database Designer
  • User Interface Designer
  • Product-Architekt
  • Service Architekt
  • Enterprise Architekt

Auf der untersten Ebene der Komponenten Ebene (Component Level) werden im wesentlichen die „neuen“ Dinge erschaffen. In den höheren Ebenen steht  mehr das „Integration Engineering“ im Vordergrund.

Für mich stellt sich dabei natürlich auch die Frage: „Berücksichtigt  die IT Ausbildung  diese verschiedenen Ebenen und geforderten Talente in gebührender Weise“?  Ich denke, da gehen die Antworten  bestimmt weit auseinander. 🙂  Ist aber auch ein ganz anderes Thema. Aber vielleicht trägt meine Abbildung zur Klärung dieser Frage etwas bei.

 

 

Katgeorie:Methodik, Technologie | Kommentare deaktiviert für Software Architektur != SW Architektur

5 Skills die ein SW-Architekt haben sollte

 

skills SW arch must have
5 Skills die ein Software Architekt haben sollte ..

In diesem Beitrag möchte ich der Frage nachgehen, welches die 5 wichtigsten Fähigkeiten sind, die ein Software-Architekt haben sollte.  Wobei natürlich die Frage im Raum steht, „Was ist überhaupt ein Software-Architekt?“. Dies Frage stelle ich zunächst einmal zurück. Ich denke ich werde meine Sicht in einem der nächsten Beträge näher darstellen.

Wie aus der Darstellung ersichtlich ist, stehen im Mittelpunkt  die Fähigkeiten  verstehen, visualisieren, erklären und Handlungsoptionen erkennen.

Katgeorie:Methodik, Technologie | Kommentare deaktiviert für 5 Skills die ein SW-Architekt haben sollte