Teil 2

Qualität von Websystemen fassbar machen: Konzeptionelle Integrität

Daniel Takai, Christoph Huber

© Shutterstock / marekuliasz

Schon Altmeister Brooks diskutierte in seinem berühmten Buch „The Mythical Man Month“ [1] die konzeptionelle Integrität. Er nannte sie als maßgeblich für die Einheitlichkeit des Designs und behauptete, dass ohne Integrität keine Bedienbarkeit möglich sei. Freilich galt ein System damals als bedienbar, wenn es ein Handbuch gab, in dem jeder Kommandozeilenbefehl mit allen Parametern verständlich dokumentiert war. Es waren also andere Zeiten, aber wir finden: Brooks hat heute noch Recht.

Interessanterweise ist der Begriff der konzeptionellen Integrität in der Literatur nicht definiert, er wird aber oft erwähnt. Er taucht interessanterweise auch nicht in den ISO-Normen zur Softwarequalität auf. Wir finden jedoch, dass dieses Qualitätsmerkmal für unsere Systeme sehr wichtig ist, da es viele andere Systemqualitäten beeinflusst. Unter konzeptioneller Integrität verstehen wir den Grad von Kohäsion und Widerspruchsfreiheit von Anforderungen, die ein System in sich vereinen muss. Mit Kohäsion meinen wir, wie eng die Anforderungen der Software zueinander in Beziehung stehen.

In diesem Artikel beschreiben wir verschiedene Szenarien, die helfen können, die Integrität zu gewährleisten, und weisen die Beziehungen zu anderen Qualitätsmerkmalen genauer aus. Dies kann dann zur Kommunikation mit dem Fach genutzt werden, denn es handelt sich bei der Integrität um ein abstraktes Merkmal, das Fachfremden schwierig zu vermitteln ist.

Stefan Toth hat in seinem Buch [2] die Qualitätsmerkmale klassifiziert nach Akzeptanzkriterien, Qualitätsgeschichten und allgemeinen Merkern. Bei der Integrität handelt es sich um einen allgemeinen Merker, der allen Projektbeteiligten präsent sein sollte, aber aus dem sich nur schwer konkrete Qualitätsszenarien oder Taktiken ableiten lassen. Vielmehr leiten wir aus der gewünschten Integrität organisatorische und methodische Maßnahmen ab.

Zu beachten ist, dass in der Literatur der Begriff der Integrität vielfach belegt ist. Wie eingangs erwähnt, nutzt Brooks ihn als Voraussetzung, beispielsweise für Usability, definiert den Begriff an sich aber nicht. In der Qualitätssicherung bezeichnet Integrität die Fehlerrate einer Komponente. In der Informationssicherheit meint Integrität die Unleugbarkeit von Daten. Die unklare Terminologie über die verschiedenen Disziplinen hinweg ist ein bekanntes Problem, aber auch nicht unbedingt eines, das man lösen muss, wenn der Kontext bekannt ist. Sprache ist nun mal mehrdeutig.

Einflussfaktoren

Abbildung 1 zeigt, wie die konzeptionelle Integrität über verschiedene Ebenen eines Projekts beeinflusst wird. Schon die Organisation und Prozesse, in der die Software entsteht, sind entscheidend. Haben Sie beispielsweise eine eigene Abteilung für die Frontend-Entwicklung und ist diese nicht schlüssig in die Gesamtentwicklung integriert, dann wird Ihre Benutzeroberfläche ziemlich statisch werden. Das liegt daran, dass, wenn Frontend und Backend nicht gemeinsam an den Features arbeiten, kein Zusammenspiel entstehen kann. Hier gilt das Gesetz von Conway, das besagt, dass Organisationen Systeme produzieren, die ihre Kommunikationsstrukturen kopieren [3]. Sollten Sie hierunter leiden, führen Sie einfach ein inverses Conway-Manöver aus.

Abb. 1: Einflussfaktoren der Integrität

Abb. 1: Einflussfaktoren der Integrität

Integrität messen

Unsere Definition von widerspruchsfreien Anforderungen mit hoher Kohäsion ist sehr weich und nicht geeignet, um Integrität tatsächlich messen zu können. Wir können also kein Tool schreiben, das eine rote Fahne hisst, wenn unsere Integrität den Bach runter geht. Ein Ausweg wäre, die Abwesenheit von Integrität festzustellen. Wir haben lange gesucht, um hierfür einen guten Namen zu finden: „Wischiwaschi“ war der beste Kandidat. Ein guter Indikator für Wischiwaschi sind unklare, mehrdeutige und widersprüchliche Anforderungen. Dies wären beispielsweise User Stories, die nicht verstanden werden und auch vom Fach nicht gut erklärt werden können. Indikatoren für fehlende Integrität sind also lange Abstimmungsrunden, hohe Änderungsraten und schließlich Projektverzug.

Ein weiterer Indikator für fehlende Integrität ist die Komplexität eines Systems. Wenn nämlich ein System übermäßig komplex erscheint, so kann dies ein deutlicher Hinweis auf eine Schieflage in den Anforderungen sein. Es ist zwar auch möglich, ein komplexes System zu haben, das integer ist, jedoch steigt die Schieflage in den Anforderungen mit ihrer Anzahl, da eine semantische Konsistenzprüfung von einem Menschen durchgeführt werden muss und wir alle wissen: Irren ist menschlich.

Maßnahmen gegen Wischiwaschi

Die erste Maßnahme, um Integrität herzustellen, ist die klare Definition der Geschäftsziele und Epics, die das System unterstützen muss. Wenn diese eine hohe semantische Kohärenz haben, sind Sie auf dem richtigen Weg. Verhandeln Sie diese also mit dem Anforderungsingenieur, den sie hoffentlich an Bord haben. Generell gilt, dass eine User Story stets ein Geschäftsziel oder ein Feature nachvollziehbar unterstützen sollte. Siehe hierzu auch [4].

Um Mehrdeutigkeiten zu verbannen und die Integrität der Anforderungen weiter zu festigen, haben wir gute Erfahrungen mit der Etablierung eines Contentmodells gemacht. Das Contentmodell beschreibt die verschiedenen Inhaltselemente eines Systems und ihre Beziehungen untereinander. Abbildung 2 ist ein einfaches Beispiel für ein Contentmodell: in einem Tabletop-Rollenspiel spielt jeder Spieler eine Charakterklasse und nimmt an Spielabenden teil. Letztere sind Teil eines Abenteuers und in ihnen kommen Monster vor. Die Abbildung zeigt die verschiedenen möglichen Inhalte und ihre Beziehungen zueinander. Dieses sind die Inhalte, die dann redigiert und auf der Website präsentiert werden können.

Abb. 2: Beispiel für ein einfaches Contentmodell

Abb. 2: Beispiel für ein einfaches Contentmodell

Als Informatiker kommt Ihnen solch ein Modell natürlich trivial vor, aber für Redakteure und Kollegen aus dem Marketing ist solch eine präzise Modellierung unter Umständen ein Werkzeug von einem anderen Stern, das ihnen erlaubt, ihrem unstrukturierten Wust an Inhalten eine Struktur zu verleihen. Das hier angegebene Beispiel ist übrigens eine starke Vereinfachung. Ein richtiges Modell sollte vollständig ausmodelliert sein und jedem Konzept Eigenschaften, Multiplizitäten und Metadaten zuweisen.

Sie sollten so beschrieben werden, dass alle Projektbeteiligten sie verstehen können. Alle Anforderungen, Prozessbeschreibungen, Konzepte usw. sollten stets die Begriffe aus dem Contentmodell verwenden, um Eindeutigkeit und damit Integrität herzustellen. In Kombination mit der Prüfung der Unterstützung der Geschäftsziele haben Sie also nun schon zwei starke Indikatoren an der Hand, die helfen, Anforderungen und Änderungen an Anforderungen nachvollziehbar zu prüfen.

Wenn Ihnen ein Contentmodell fehlt, kann es passieren, dass neue Konzepte durch die Hintertür Einzug in ihr System finden, für die es dann keine Repräsentation in der Source gibt, und die dementsprechend aufwändig wird. In unserem Rollenspielbeispiel gibt es kein Konzept für magische Gegenstände, aber selbstverständlich tragen sowohl Monster als auch Spielercharaktere viele von ihnen. Wenn nun die Redaktion diese Gegenstände auf eigenen Seiten beschreiben möchte, muss ein neues Template mit neuem Frontend-Code, neuen Tests usw. her. Abbildung 3 verdeutlicht die Zusammenhänge anhand eines Templates Spielbericht, auf dem verschiedene Inhaltselemente vorkommen.

Abb. 3: Zusammenhang zwischen Template und Contentmodell

Abb. 3: Zusammenhang zwischen Template und Contentmodell

Als Eingabe zur Konstruktion eines Contentmodells haben Ihre Zielorganisationen manchmal bereits Domänenmodelle vorliegen, aus denen sie schöpfen können. Das Contentmodell beinhaltet dann eine Teilmenge des Domänenmodells der Zielorganisation und erweitert dieses um die speziellen Semantiken Ihres Informationssystems. Für uns als Architekten hat solch ein Contentmodell wesentliche Vorteile:

  • Ihre Inhalte haben nun eine Struktur, anhand derer wir beurteilen können, ob sich Anforderungen widerspruchsfrei integrieren lassen. Im obigen Beispiel könnte nämlich ein Spielercharakter niemals ein Monster sein. Sie können diese Anforderung eines Spielers also als ungültig abweisen.
  • Die Inhalte unserer Anwendung sind von ihrer konkreten Repräsentation gelöst und können gegebenenfalls später in einem anderen Kontext wiederverwendet werden (beispielsweise bei einem Redesign der Website).
  • Sie können die Redaktion mit Werkzeugen bei der Arbeit unterstützen, beispielsweise durch Page Tables [5]. Page Tables sind detaillierte Angaben zur Erfassung von Inhalten für Redakteure, die sich aus dem Contentmodell ableiten lassen. Dabei beschreibt eine Page Table den Inhalt einer spezifischen Seite im System, bezieht sich also auf ein Template. In Abbildung 3 gäbe es eine Page Table für das Template Spielbericht.
  • Wir können das Modell in unserem Content-Management-System abbilden und hierauf Templates und Komponenten konstruieren, die die Elemente spiegeln. Es ist eine gute Idee, dieselben Begriffe beispielsweise als Klassennamen zu verwenden (siehe hierzu auch Domain-driven Design).

Contentstrategie

Wenn Sie als Architekt ganz sicher gehen möchten, können Sie noch einen weiteren Schritt gehen und das Modell gegen die Contentstrategie Ihres Auftraggebers validieren. Die Contentstrategie schlägt die Brücke zwischen der Geschäftsstrategie und ihrem Contentmodell. In ihr sollten dann auch die unterschiedlichen Kanäle beschrieben sein, die mit Inhalten bewirtschaftet werden sollen (Web, Mobile, Digital Signage, Apps, E-Books usw.). Ein spannendes Buch zu diesem Thema finden Sie unter [6]. Den Zusammenhang der Konzepte beschreibt Abbildung 4. Ein einfaches Beispiel für eine Contentstrategie könnte ein Reisebüro sein, das Inhalte zu Reisezielen über Web und Mobile anbieten möchte, um seine Geschäftsstrategie zu unterstützen. Daraus ergeben sich dann direkt die ersten Konzepte eines Contentmodells.

Abb. 4: Rolle des Contentmodells im Kontext

Abb. 4: Rolle des Contentmodells im Kontext

Werkzeuge

Um konzeptionelle Integrität zu gewährleisten, müssen Sie es schaffen, dass Ihre Anforderungen möglichst widerspruchsfrei und kohärent aufgenommen werden und auch bei Änderungen so bleiben. Dies ist schon bei Projekten mittlerer Komplexität nicht mehr ohne den Einsatz von entsprechenden Werkzeugen möglich, denn die Masse an Informationen ist zu groß und die Änderungsfrequenz zu hoch.

Es gibt viele verschiedene Application-Lifecycle-Management-(ALM-)Werkzeuge am Markt. Diese unterstützen die strukturierte Ablage sowie Änderungsprozesse alle mehr oder weniger gut. Ein ALM-Werkzeug zu haben, ist schon mal besser als gar keines zu haben (Excel ist übrigens kein ALM-Werkzeug), achten sie jedoch darauf, dass alle Stakeholder Zugriff haben und die Benutzerfreundlichkeit einen Einsatz auch durch fachfremde Personen erlaubt. Relativ populär in diesem Bereich ist nach wie vor Atlassian Jira.

Die Qualität der Anforderungen in ihrem ALM-Tool bestimmt also, ob das System integer wird oder nicht. Sind die Anforderungen unklar beschrieben, gibt es Widersprüche. Oder werden Anforderungen mehrfach aufgelistet, wird sich das später auch in der Architektur oder in der Implementierung wiederholen. Verschiedene Entwickler verstehen eine Anforderung anders oder arbeiten zeitgleich an denselben Anforderungen, ohne es zu bemerken. Anforderungsänderungen sollten also kritisch geprüft werden, bevor sie in die Architektur einfließen. Ihr Prozess sollte die folgenden beiden Punkte zur Prüfung enthalten:

  • Es gibt zwei Anforderungen, die sich widersprechen.
  • Es gibt zwei Anforderungen, welche dasselbe unterschiedlich beschreiben.

Um dies zu gewährleisten, spielen zwei Faktoren eine wichtige Rolle. Zum einen ist die in den Anforderungen verwendete Terminologie wichtig. Wir haben oben schon das Contentmodell besprochen, in dem die wichtigsten Konzepte unseres Systems genau definiert sind. Aber es gibt noch viele andere, die nicht in unserem Modell vorkommen, die aber gleichwohl für das richtige Verständnis sehr wichtig sind. Wir haben es immer wieder erlebt, dass ein diszipliniert geführtes Glossar allen Beteiligten eine große Hilfe ist. Dabei müssen die Begriffe nicht zu eng gefasst werden. Auch Abkürzungen und Akronyme dürfen erklärt werden.

Zum anderen benötigen größere Mengen von Anforderungen eine Taxonomie, die es erlaubt, eine Struktur auf den Anforderungen zu definieren. Über die Taxonomie können Anforderungen dann gruppiert und später aufgespürt werden.

Ein weiterer Gesichtspunkt, der uns bei der Diskussion um die Integrität am Herzen liegt, ist die Informationsmenge, die bei einem Softwareprojekt entsteht, und die leicht unterschätzt wird. Man sollte dies griffig illustrieren, damit es klar wird. Sie können damit rechnen, dass beispielsweise für die Website eines Konzerns weit mehr als 10 000 Seiten Papier an Dokumentation anfallen werden (Anforderungen, Rahmenbedingungen, Lösungsbeschreibungen usw.). Ein Mitarbeiter kann sich nicht zu 100 Prozent in das Projekt einbringen, wenn er diese Informationen nicht absorbiert hat, denn Softwareentwicklung ist wissensintensiv. Es gilt also, dafür Sorge zu tragen, dass jede der 10 000 Seiten richtig und aktuell ist, sodass keine Fehlinformationen entstehen. Es ist also eine wichtige Aufgabe, diese Informationen auf eine besonders gut zugängliche Art und Weise vorzuhalten, sowie unkomplizierte und angemessene Prozesse zur Aktualisierung zu etablieren. Wir haben gute Erfahrungen mit der Pflege von Projektinformationen in einem Wiki gemacht, das in Kombination mit dem ALM-Tool diese Zugänglichkeit leisten kann.

Szenarien für konzeptionelle Integrität

Wie zu jedem Qualitätsmerkmal, das wir in dieser Serie besprechen, möchten wir auch an dieser Stelle Qualitätsszenarien zur konzeptionellen Integrität präsentieren, die Ihnen als Beispiel und Kommunikationstool mit dem Fach dienen können. Im einleitenden Artikel der Serie gab es hierzu eine ausführliche Diskussion. Wenn Sie mehr wissen möchten, empfehlen wir das Buch [7].

  • Mitarbeitern im Team sind nach der Einarbeitung das Contentmodell, die Geschäftsziele und Epics sowie deren Abbildung auf das System bekannt.
  • Ein Redakteur kann nur Inhalte mit dem System produzieren, die einer Klasse des Inhaltsmodells angehören und die den dort definierten Regeln genügen.
  • Produziert ein Redakteur Inhalte, so stehen ihm dabei genaue Definitionen des Inhaltsmodells sowie relevante Kontextinformationen auf einem Page Table zur Verfügung.
  • Im Team soll ein jährlicher Abgleich der Content- mit der Web- und Geschäftsstrategie stattfinden, in dem Änderungen angeglichen werden können, die durch den steten Wandel im Umfeld entstanden sind.
  • Ein Entwickler kann während der Entwicklung im Code eines Templates einen direkten, klaren und dokumentierten Inhaltsbezug zum Contentmodell finden.

Auswirkungen auf andere Qualitätsmerkmale

In der Literatur ist keine Definition von konzeptioneller Integrität zu finden, und sie wird auch nicht als eigenes Qualitätsmerkmal geführt. Wir haben sie dennoch aufgenommen, weil wir finden, dass sie ein wesentliches Qualitätsmerkmal ist und Einfluss auf andere Eigenschaften eines Systems hat. Unserer Meinung nach, beispielsweise die Folgenden:

  • Wartbarkeit/Änderbarkeit: Je konsistenter die Anforderungen und je klarer die Ziele und Epics, desto einfacher ist es, Änderungen an den Anforderungen einzubringen, und die entsprechenden Anpassungen an der Software vorzunehmen. Daraus folgt, dass die Software auch länger in Betrieb gehalten werden kann, da sie sich besser anpassen lässt.
  • Bedienbarkeit/Erlernbarkeit: Je schlüssiger die Funktionen eines Systems für die Benutzer sind, desto einfacher lassen sie sich auch erlernen. Schon Brooks hat dies behauptet, und es ergibt für uns durchaus Sinn.
  • Komplexität: Da Ihr System gut durchdacht ist und eine hohe Kohäsion hat, entsteht keine unnötige Komplexität. Das System kann mit einem optimalen Komplexitätsgrad gebaut werden.
  • Performance: Unnötige Komplexität in der Source kann Auswirkungen auf die Performance haben. Da keine unnötige Komplexität entstehen muss, ist der Grundstein für eine gute Performance gelegt.
  • Planbarkeit: Da die Features und ihre Abbildung auf die Software vom Team gut verstanden werden, sind auch die Aufwandschätzungen gut. Die Planbarkeit nimmt zu.

Fazit

Die Aufwände, die nötig sind, für ein System widerspruchsfreie und kohärente Anforderungen so zugänglich zu dokumentieren, dass das gesamte Team davon profitieren kann, dürfen nicht unterschätzt werden. Wir vermuten, dass die Investitionen in gute Konzeption die Mehraufwände für Umbauten, Revisionen, Bedienbarkeit, Änderbarkeit etc. wettmachen, können es mangels Daten aber nicht beweisen. Wir haben aber im Rahmen unserer Praxis festgestellt, dass als Belohnung dieses Vorgehens ein Lösungsdesign winkt, das ein nachhaltiges System zulässt, mit dem alle Beteiligten zufrieden sein können.

Aufmacherbild: integrity word in vintage via Shutterstock / Urheberrecht: marekuliasz

Geschrieben von
Daniel Takai
Daniel Takai
Daniel Takai ist Enterprise-Architekt, arbeitet in der Schweiz und ist auf die digitale Transformation spezialisiert. Er berichtet regelmäßig im Java Magazin über seine Erfahrungen und Erkenntnisse. Im Frühling 2016 erscheint sein Buch über Methoden der Entwicklung von Cloud-basierten und serviceorientierten Websystemen.
Christoph Huber

Christoph Huber ist bei der mimacom AG in Bern als Java-Entwickler tätig. Er interessiert sich für alle Facetten eines Softwareprojektes, vom Requirements Engineering und der Architektur bis hin zur effizienten Implementation. Er ist auf Twitter unter @huberchrigu erreichbar.

Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: