Was die Qualität von Websystemen ausmacht - Teil 7: Änderbarkeit

Entwicklung von Websystemen: Nichts ist so beständig wie der Wandel

Daniel Takai

© iStockphoto.com/Horned_Rat

Schon Heraklit wusste: „Nichts ist so beständig wie der Wandel“. Insbesondere Websysteme haben eine hohe Änderungsrate, da sie sich ständig anpassen müssen. Dabei gilt es, die Wartbarkeit möglichst effizient zu gestalten, damit mehr Geld in Funktionen und Qualität investiert werden kann. Welche Methoden können hier zum Einsatz kommen?

Die Entwicklung von Websystemen ist ein schwieriges Unterfangen, denn Websysteme müssen sich laufend anpassen, um erfolgreich zu bleiben. Anpassungen sind nötig, da sich die Umwelt des Systems verändert. So schreibt in der Europäischen Union das so genannte Cookie Law seit 2011 vor, dass Benutzer klar darüber zu informieren sind, wenn auf dem Terminal eines Besuchers Daten gespeichert werden. Jede Website, die Cookies setzt, muss sich seitdem vom Benutzer bestätigen lassen, dass er einverstanden ist, oder es dürfen keine Daten auf seinem Terminal gespeichert werden. Durch diese Änderung der Umwelt mussten sich die Websites in der Europäischen Union anpassen, egal, ob sie es wollten oder nicht. Das bedeutet im Umkehrschluss, dass ein gewerblich genutztes System laufend anpassbar bleiben muss, um überhaupt überleben zu können, weil sich die Gesetzeslage ändern kann.

Aber auch auf anderen Ebenen findet Veränderung statt. Vom Betriebssystem bis zum Webframework findet eine kontinuierliche Evolution statt, die seit zwanzig Jahren immer mehr Fahrt aufnimmt. Ein Websystem muss sich ständig verjüngen, um anpassbar zu bleiben, denn Fehler in der alten Version des verwendeten Webframeworks werden nun mal nicht mehr behoben.

Als Web Professionals verstehen wir diese Problematik gut und haben gelernt damit umzugehen, dass nichts so bleibt wie es war. Der Besucher unserer Websites versteht dies jedoch nicht, und in vielen Fällen handelt es sich gleichzeitig um den Sponsor, dem die substanziellen Kosten zur Erhaltung der Wartbarkeit in Rechnung gestellt werden müssen. Wie bei allen Qualitätsmerkmalen gilt es also Verständnis herzustellen. Hierfür eignen sich besonders die Qualitätsszenarien, die am Ende des Artikels geschrieben stehen. Zur Erreichung der Änderbarkeit nutzen wir die hier vorgestellten Methoden.

Qualitätsszenarien klassifizieren

Die Änderbarkeit bestimmt, wie leicht sich eine Änderung von der Konzeption bis zum Roll-out vollziehen lässt. Je schneller und effizienter dies geschehen kann, desto besser. Hieraus ergibt sich, dass DevOps in Bezug auf Änderbarkeit eine gewichtige Rolle spielt, da das erklärte Ziel der DevOps-Bewegung das möglichst schnelle und qualitativ hochwertige Ausspielen von Änderungen am System ist [1]. Wesentliche Einflussfaktoren sind die Submerkmale der Wartbarkeit für Websysteme, wie in den vorangegangenen fünf Artikeln dieser Serie beschrieben: Konzeptionelle Integrität, Konsistenz, Testbarkeit, Analysierbarkeit und Prüfbarkeit. Die Änderbarkeit ist nach ISO 25010 auch selbst ein Teil der Wartbarkeit. Die in diesem Artikel rund um die Änderbarkeit diskutierten Konzepte zeigt Abbildung 1. Stefan Toth hat in seinem Buch [2] die Qualitätsszenarien nach Akzeptanzkriterien, Qualitätsgeschichten und allgemeinen Merkern klassifiziert. Die Änderbarkeit erzeugt in erster Linie einen allgemeinen Merker, also dass Änderbarkeit hergestellt werden soll oder nicht. Falls dies der Fall ist, erzeugen Diskussion um die Änderbarkeit im Weiteren dann konkrete Akzeptanzkriterien, und zwar hauptsächlich in der Entwicklung; siehe hierzu die Beispiele für Qualitätsszenarien am Ende des Artikels.

Über Änderbarkeit sollte nur gesprochen werden, wenn der Wunsch nach der Langlebigkeit eines Systems besteht. Sie müssen den Auftraggeber nicht mit einer Investitionsrechnung konfrontieren, wenn von vorne herein klar ist, dass das System nur wenige Wochen laufen soll, wie zum Beispiel ein Special zur Fußball-EM. In den meisten Fällen ist der Wunsch nach Langlebigkeit aber durchaus gegeben, man hat sich darüber aber meistens keine Gedanken gemacht. Die einfache Frage nach der geplanten Lebensdauer des Systems sorgt bisweilen für Überraschungen auf der Gegenseite. Oft besteht diese Gegenseite bei Websystemen aus Kollegen aus dem Marketing, und die sind es gewöhnt, dass das System nach drei Jahren ausgewechselt werden muss – weil es sich nicht mehr ändern lässt. Wer es besser machen möchte, der stimmt den Investitionsfahrplan vorher ab. Besteht Einigkeit, dass es besser wäre, die Investitionen auf fünf, besser zehn Jahre zu verteilen, lassen sich die Maßnahmen zur Erhaltung der Wartbarkeit im Weiteren besser begründen. Nachhaltigkeit in jeder Beziehung ist dann gefragt.

Abb. 1: Konzepte der Änderbarkeit

Abb. 1: Konzepte der Änderbarkeit

Entwicklungsprozesse führen und messen

Engineering Management ist die Führung von Entwicklungsprozessen und ein Wissensgebiet des „Software Engineering Body of Knowledge“ der IEEE Computer Society [3]. Ziel des Engineering Managements ist die systematische, disziplinierte und quantifizierte Entwicklung von Software. Es geht also um die Führung und Messung von Entwicklungsprozessen. Dies ist eine schwierige Aufgabe, da Softwareentwicklung sowohl Kreativität als auch Disziplin benötigt und es die richtige Balance zu finden gilt. Hinzu kommt, dass die Technologieentwicklung rasant ist. Jede Ebene der Entwicklung (Infrastruktur, Frameworks, Methoden etc.) ist stetig im Wandel und erschwert so nachhaltiges Management. Kein Wunder, haben sich in den vergangenen Jahren agile Praktiken etabliert, die diesen Wandel pragmatisch begleiten. Aus der Führungsperspektive ist heute das Enablement von agilen Projektteams wichtiger als einschränkende Prozessvorgaben, um Qualität effizient liefern zu können. Wichtigster Faktor dieses Enablements ist das Bereitstellen von Werkzeugen für die Entwicklung, die in vier verschiedene Kategorien fallen: Development Services, Lokale Werkzeuge, Workflow Tools sowie Werkzeuge zur Dokumentation.

Unbedingt nötig: Development Services

Diese Dienste werden für die Entwicklung benötigt, laufen nicht lokal und sind für die Produktion des Systems unabdingbar. Die Continuous-Integration- und Continous-Delivery-Pipeline gehört hier dazu. In der Java-Entwicklung wird zudem ein Maven Repository benötigt, bei PHP eine Composer-Infrastruktur. Da ohne diese Systeme keine Software geliefert werden kann, gelten hohe Anforderungen an die Verfügbarkeit und Performance. Wenn mehr als ein Projektteam diese Dienste nutzt, benötigt man zudem ein Sicherheitskonzept, das die Arbeiten der Teams voneinander isoliert. Für eine nähere Diskussion von Delivery-Pipelines möchte ich auf die Bücher von Len Bass [1] und Eberhard Wolff [4] verweisen.

Es ist fahrlässig, den Einsatz und Betrieb der für die Arbeit kritischen Dienste nicht sorgfältig zu planen. Abbildung 2 zeigt eine solche Werkzeugkette am Beispiel. Die Anzahl der dabei verwendeten Systeme und ihre Integration ist nicht trivial, d. h. es entstehen signifikante Kosten im Betrieb und der Wartung dieser Systeme, vor allem, wenn man sie selber betreibt, was in vielen Fällen aufgrund von Business-Continuity-Anforderungen nötig ist.

Ein interessanter Take-away ist, dass die Produktionskette Ihres Systems ein Teil Ihres Systems ist und sich die beiden nur schwer voneinander trennen lassen. Sie benötigen zum Beispiel ein Build-System, das Ihr System kompiliert, paketiert und testet. Dieses Build-System hat harte Abhängigkeiten auf Ihre Development-Services, denn es existiert nicht im luftleeren Raum. Die Migration einer solchen Entwicklungsumgebung zwischen zwei Organisationen kann also ein aufwändiges Unterfangen sein. Zudem beeinflusst die Delivery-Pipeline auch die Architektur und Entwicklung des Systems. Denken Sie nur an Konfigurationsparameter von Modulen, die im Dialog mit dem DevOps-Team entstehen und per Chef Cookbook gesetzt werden [1].

Lokale Werkzeuge: Gut oder schlecht?

Oft wird die Vorgabe von lokalen Entwicklungswerkzeugen als Voraussetzung für Synergien im Team genannt. Lassen Sie sich nicht in die Irre führen. Die lokale Entwicklungsumgebung ist das Schloss des Entwicklers, und dort regiert er ganz alleine, und zwar mit Werkzeugen, die er sehr gut kennt. Fragen Sie ihn lieber, ob er ein Budget für Werkzeuge benötigt, anstatt ihm Vorgaben zu machen, die ihn einschränken und die Produktivität senken. Fördern Sie jedoch den Austausch und richten Sie hierfür ein regelmäßiges Entwicklermeeting ein, damit er stattfinden kann.

Workflowtools: Welches Tool und wann?

Workflow Tools wie JIRA, FogBugz, Slack oder Zeplin möchten für Effizienz, Planbarkeit und Kommunikation in den Arbeitsalltag integriert werden. Für jedes Workflowtool sollte es eine Einsatzbeschreibung geben, die erklärt, wie sich das Tool im konkreten Projekt einsetzen lässt (Abb. 2). Es ist nicht notwendig, jeden einzelnen Workflow zu dokumentieren, zumal sich diese häufig ändern, sie sollten jedoch im Team besprochen werden können. Achten Sie auf rechtlich relevante Arbeitsprozesse, beispielsweise bei Festpreisprojekten, bei denen Abläufe im Anforderungs- und Fehlermanagement relevant zur Klärung von Meinungsverschiedenheiten sein können. In einem solchen Fall sollte der Workflow in jedem Fall dokumentiert werden, damit ihn alle nachweislich einhalten können. Neugier und Offenheit in der Einführung und Verwendung von Werkzeugen sind Tugenden, denn pfiffige Features können Ihnen das Leben leichter machen.

Abb. 2: Beispiel einer Werkzeugkette

Abb. 2: Beispiel einer Werkzeugkette

Dokumentation nicht vergessen

Die Dokumentation des Systems ist für die Analysierbarkeit des Systems wesentlich [5]. Sie benötigen Software für die Organisation, Verteilung und Lieferung dieser Dokumentation. Hierzu gehören Textverarbeitung, Bilder, Diagramme, Tabellen, Audio, Video und Präsentationen. Achten Sie besonders darauf, dass Sie das Format vereinbarter Lieferobjekte bedienen können und verhandeln Sie dieses, falls nötig.

Der Kunde benötigt Führung

Beim Engineering Management geht es auch um Führung. Hat man Sie engagiert, ein neues System zu bauen, so ist es nicht unwahrscheinlich, dass Ihr Kunde diese Kompetenz selber nicht hat. Sie sind also der Experte und müssen das Projekt erfolgreich führen. Ich lebe in den Schweizer Alpen und gehe gerne Alpinklettern. Über die Jahre habe ich dabei einige Bergführer kennengelernt. Einer hat mir mal beim Zustieg auf den Piz Badile die drei Grundregeln erklärt, nach denen er beim Führen sein Handeln ausrichtet. Obwohl nicht direkt übertragbar, gibt es doch sinngemäß einige entfernte Parallelen zur Webentwicklung:

  • Der Kunde versucht sich selber zu töten.
  • Der Kunde versucht die anderen Kunden zu töten.
  • Der Kunde versucht mich zu töten.

Gehen Sie also am besten davon aus, dass der Kunde Führung benötigt, damit es nicht zu Unfällen kommt. Nehmen Sie sich Zeit, die Sachverhalte zu erklären und arbeiten Sie so transparent wie möglich. Die Entwicklung von Software ist unsichtbar, gleichzeitig aber kostenintensiv, weswegen sich Unbedarfte übervorteilt vorkommen können. Die ständige Präsentation und Diskussion von Arbeitsergebnissen mit dem Product Owner ist einer der Gründe für den Erfolg der agilen Entwicklung aus genau diesem Grund. Eine weitere gute Methode zur Herstellung von Transparenz ist die Verwendung von Qualitätsszenarien, die helfen, Verständnis zu schaffen. Vor allem benötigt gute Führung aber Vertrauen. Ein Weg, dieses Vertrauen von Anfang an aufzubauen, gelingt durch das Kommunizieren der ethischen Grundwerte unseres Berufsstands. Die Ethikrichtlinien der Schweizer Informatik Gesellschaft helfen mir persönlich in schwierigen Verhandlungen mit dem Fach auch mal Nein sagen zu dürfen, insbesondere der Passus zur Vermeidung unnötiger Komplexität.

Resultate messen

Ein wesentlicher Aspekt des Engineering Managements ist die Messung von Ergebnissen. Im vorangegangenen Artikel über die Prüfbarkeit wurde bereits das Monitoring besprochen, welches das Laufzeitverhalten unseres Systems misst. Im Engineering Management geht es um die Messung des Produktionsfortschritts sowie der funktionalen Qualität eines Systems. Dabei werden Fragen beantwortet, wie: Wie viele Tests gibt es? Wie hoch ist die Testabdeckung? Wie viele Tests schlagen fehl? Handelt es sich um schwere Fehler oder nicht? Den Projektleiter treibt die Frage um, wie viel Prozent der Arbeiten bereits erledigt sind, damit er dies mit seiner Kalkulation abgleichen kann. Für all diese Fragen werden Daten benötigt, die regelmäßig in Berichten zusammengefasst und in der Projektsteuerung auf der Agenda stehen sollten. Das Engineering Management sorgt dafür, dass die Messpunkte auf den eingesetzten Werkzeugen definiert und später gemessen werden.

Messen mit der Funktionspunktanalyse

Maßnahmen zur Erhaltung und Verbesserung der Wartbarkeit wie Refactorings, Stabilisierungssprints, Dokumentation oder die Optimierung der statischen Codequalität kosten viel Zeit und Geld. Ein immer wiederkehrendes Thema ist deswegen die Finanzierung derselben. Schön wäre es, wenn man nachweisen könnte, dass die Maßnahmen wirklich wirksam sind. Eine Option ist die Messung der Aufwände im Change Management über die Jahre. Bleibt dieser Aufwand konstant, ist eine mögliche Schlussfolgerung, dass die Änderbarkeit in Ordnung ist. Es kann aber auch sein, dass weniger Änderungen vorgenommen werden. Eine Methode zur Messung der tatsächlich vorgenommen Änderungen ist die Funktionspunktanalyse, eine Methode aus den späten 70er-Jahren [6]. Es handelt sich um ein abstraktes, technologie-agnostisches Verfahren, bei dem fünf verschiedene, universelle Funktionen gezählt werden:

Logical Files

  • Internal Logical File (ILF): CRUD einer persistenten Entität
  • External Interface File (EIF): CRUD einer Entität in einem anderen Service

Actor Transactions

  • External Input (EI): Eingabe eines Akteurs
  • External Output (EO): Ausgabe von Informationen für einen Akteuer, zum Beispiel auf einer Webseite
  • External Inquiry (EQ): Verarbeitung einer Suchanfrage durch einen Akteur

Ein einfaches Beispiel wie in Abbildung 3 möge dies verdeutlichen. Ein Log-in-Formular benötigt die folgenden Funktionen, unter der Annahme, dass die eigentliche Authentifizierung über ein dediziertes Identity-Management-System läuft:

1. EI: Eingabe E-Mail
2. EI: Eingabe Password
3. EO: Anzeige Fehlermeldung
4. EO: Anzeige des Formulars
5. EIF: Verifikation der Credentials durch ein externes System

Macht summa summarum fünf Funktionspunkte. Diese werden nun im nächsten Schritt mit dem Komplexitätsfaktor der Funktionalität multipliziert. In der Webentwicklung hat man viele Anforderungen, aber sie sind meistens nicht komplex, sodass in der Regel immer der Faktor 1 verwendet werden kann. Hinzu kommen die Aufwände nach Technologie und Kontext als weiterer Faktor. Hierfür benötigen Sie Erfahrungswerte aus vorangegangenen Projekten, um den Faktor bestimmen zu können. Dieser ist subjektiv und gilt nur für den vorliegenden speziellen Kontext. Einflussfaktoren sind die verwendete Programmiersprache, die Erfahrungen der Entwickler mit den verwendeten Technologien, die Maturität ihrer Continuous-Delievery-Pipeline usw. Die Formel für die Aufwände lautet also:

Summe FP x Komplexität x Technologie = Aufwand

Und diese Formel reduziert sich in der Webentwicklung:

Summe FP x Technolgie = Aufwand

Die Genauigkeit Ihrer Schätzung bestimmt sich also über das genaue Auszählen der Punkte und den richtigen Ansatz des Technologiefaktors. Zu Beginn eines Projekts ist das genaue Auszählen nicht möglich, da die gewünschte Funktionalität noch nicht definiert ist. Die einzige Möglichkeit besteht hier darin, Annahmen zu treffen, wie viele Punkte eine bestimmte Funktion haben wird. Verbindlichkeit kann hier durch die Angabe der Annahmen sowie des Verfahrens geschaffen werden. Erweitert sich die gewünschte Funktionalität später in einem Maße, die Ihre Annahmen übertrifft, so haben Sie dann eine schriftliche Referenz, worauf Ihre Schätzung basierte. Bei einem Angebot gilt nämlich der Informationsstand zum Zeitpunkt der Erstellung.

Abb. 3: Beispiel für die Funktionspunktanalyse

Abb. 3: Beispiel für die Funktionspunktanalyse

Die Funktionspunktanalyse hat ihre Ecken und Kanten und Sie müssen sie auf Ihren Arbeitsbereich zuschneiden, aber sie bietet ein strukturiertes, nachvollziehbares und einigermaßen objektives Instrument der Kostenkontrolle, das meiner Erfahrung nach wesentlich bessere Ergebnisse in der Schätzung liefert, als Funktionen über den Daumen zu peilen. Zudem haben Sie so ein Messinstrument über implementierte Funktionalität in der Hand, das Sie verwenden können, um über die Zeit den Nachweis zu bringen, dass Maßnahmen zur Wartbarkeit wirken.

Lehman hat die Wartbarkeit in seinen Gesetzen der Evolution von E-Typ-Systemen (z. B. Websysteme) bewiesen, dass die kontinuierliche Verbesserung der Wartbarkeit eines solchen Systems notwendig ist, da es sonst an Qualität verliert und sich schlechter anpassen lässt [7]. Und je schlechter sich das System anpassen lässt, desto teurer werden die Änderungen. Dies geht so lange, bis Änderungen an einem System nicht mehr in nützlicher Frist und zu vertretbaren Kosten durchgeführt werden können. Sobald dieser Punkt überschritten ist, gilt das System als Legacy und muss durch ein neues ersetzt werden. Abbildung 4 verdeutlicht dies an einer Grafik. Werden keine Maßnahmen zur Erhaltung der Wartbarkeit eingeleitet, steigt die Cost per Change (CPC) kontinuierlich, bis der „Legacy Scare“ erreicht ist.

Abb. 4: Legacy Scare

Abb. 4: Legacy Scare

Mögliche Qualitätsszenarien

Wie bei jedem Artikel dieser Serie zeige ich auch hier Qualitätsszenarien [8] auf, die in der Kommunikation mit dem Fach nützlich sein können. Das erste Beispiel knüpft direkt an die Diskussion der Funktionspunkte an:

Während der Systemevolution kann eine neue Funktion mit demselben Aufwand umgesetzt werden, als wäre sie zu Beginn der Entwicklung eingegeben worden.

Für den Auftraggeber ist es leicht, diesem Szenario zuzustimmen, denn selbstverständlich soll sich die Software immer gleich gut ändern lassen. Es liegt dann an Ihnen, sicherzustellen, dass dies für Ihren Klienten auch transparent nachweisbar ist. Die Funktionspunktanalyse kann eine Methode sein, um dies sicherzustellen. Das Szenario beinhaltet aber implizit noch ganz andere Themen. Zu Beginn der Entwicklung gibt es nämlich noch kein Produktionssystem, sodass Roll-out-Kosten hier kein Thema sind. Eine Diskussion um automatisches Deployment kann sich also nahtlos anschließen, beispielsweise über folgendes Szenario:

Ein Testmanager kann zu jeder Zeit einen der letzten zehn Builds, einen Build von vor einer Woche und von vor einem Monat sowie den aktuell auf Produktion installierten Build auf der Staging und UAT-Umgebung selbstständig ausspielen, und benötigt hierfür nicht länger als 15 Minuten.

Um dieses Szenario verwirklichen zu können, benötigen Sie ein Continuous-Deployment-System und eine vollständige Automatisierung Ihrer Pipeline, sonst ist der Roll-out nicht in 15 Minuten zu schaffen. Die Erwähnung der Testmanagerrolle zieht dann ein Rechtekonzept nach sich, das regelt, wer auf welcher Umgebung Änderungen vornehmen darf.

Die folgenden zwei Szenarien beschäftigen sich mit Traceability und der Notwendigkeit, die Tools zur Sourcecode-Verwaltung, Defect Management und Requirements Engineering miteinander zu verbinden:

Ein Entwickler kann für umgesetzte Anforderungen genau nachvollziehen, welche Stellen im Source hierfür geändert worden sind.

Für jeden qualifizierten Fehler dokumentiert der Entwickler bei der Behebung die Stellen im Source, die für die Behebung geändert worden sind, und es entsteht ihm dadurch kein Mehraufwand.

Fazit

Die Qualitätsszenarien der Änderbarkeit erlauben die Verhandlung einer Vielzahl von Maßnahmen, die für ein erfolgreiches Projekt wesentlich, aber vielen Projektbeteiligten unbekannt sind. Wie bei vielen anderen Qualitätsmerkmalen auch, geht es hierbei nicht um Funktionalität, die ich später auf der Website beobachten kann. Stattdessen geht es um langfristige Maßnahmen mit indirekten Auswirkungen auf unser Softwareprodukt. Die sorgfältige und gewissenhafte Diskussion und Planung der Maßnahmen sollte also genauso wichtig sein, wie, sagen wir, die Aufnahme der Anforderungen. Wer bei langlebigen Webprojekten die richtigen Maßnahmen einleitet, dem winkt ein erfolgreiches System, das sich über den gesamten Lebenszyklus hinweg gut anpassen lässt.

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.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: