© Excellent backgrounds/Shutterstock.com
Teil 5: Analysierbarkeit

Fundierte Entscheidungen treffen können


Stefan Zörner hat mir einmal gesagt, seine Lieblingsdefinition von Softwarearchitektur sei eine Kette von Entscheidungen, die man nur noch schwer rückgängig machen könnte. Es gibt noch andere gute Definitionen, und das Software Engineering Institute (SEI) hat hiervon Hunderte gesammelt [1], aber das Fällen von Entscheidungen ist zweifelsohne ein sehr wichtiger Aspekt. Die Analysierbarkeit bestimmt dabei, wie gut sich die Auswirkungen unserer Entscheidungen auf das System vorhersagen lassen.

Die Analysierbarkeit wird als Whitebox-Eigenschaft während der Entwicklungszeit eines Systems definiert. Sie bestimmt dabei unter anderem, wie das System zur Laufzeit als Blackbox geprüft werden kann. Das Qualitätsmerkmal der Prüfbarkeit behandeln wir erst im kommenden Artikel. An dieser Stelle geht es also um das Innenleben eines Systems. Hierzu gehören Codequalität, Tests, Dokumentation usw.

Nur analysierbare Software lässt sich diszipliniert und quantifiziert verändern. Das Qualitätsmerkmal der Analysierbarkeit bestimmt dabei, wie gut sich Auswirkungen einer Änderung an einem System vorhersagen lassen. Wenn sich ein System schwer analysieren lässt, sind Prognosen über zu erwartende Kosten oder Durchlaufzeit riskant. Unter Umständen entsteht Volatilität in der Planung, die sich negativ auf das Team und die Kundenbeziehung auswirken kann. Die Analysierbarkeit wird insbesondere wichtig, wenn Personen ein System noch nicht genau kennen, aber Entscheidungen über das System treffen müssen, beispielsweise beim Umsetzen einer Änderung. Die Analysierbarkeit ist also für die Einarbeitung neuer Entwickler, aber auch im Projektmanagement und am Service-Desk von tragender Bedeutung: Bug oder Feature, das ist hier die Frage!

Klassifikation

Die Analysierbarkeit gehört nach ISO/IEC 25010 [2] zur Wartbarkeit. Stefan Toth hat in seinem Buch [3] die Qualitätsmerkmale klassifiziert nach Akzeptanzkriterien, Qualitätsgeschichten und allgemeinen Merkern. Die Analysierbarkeit ist ein allgemeiner Merker, der während der ganzen Entwicklung präsent sein sollte und regelmäßig Arbeitspakete auslöst. Die Einordnung in das Qualitätsmodell für Websysteme zeigt Abbildung 1.

takai_analysierbarkeit_1.tif_fmt1.jpgAbb. 1: Qualitätsmodell der Wartbarkeit

Um zu verdeutlichen, in welchen Bereichen die Analysierbarkeit wesentlich ist, lohnt es sich, die unterschiedlichen Typen von Wartung zu klassifizieren. Die Klassifikation von Lientz und Swanson [4] kann als Bemessungsgrundlage für Wartungsverträge genutzt werden:

  • Corrective Maintenance beinhaltet die Behebung von bekannten Fehlern des Systems. Hierzu gehören in erster Linie Bugfixes, es können aber auch nicht funktionale Korrekturen sein, zum Beispiel Maßnahmen zur Verbesserung der Performance, wenn das System zu langsam ist.

  • Adaptive Maintenance beschreibt die Anpassung der Software an sich verändernde Rahmenbedingungen. Fällt beispielsweise eine veraltete Java-Version aus dem Support, so muss das System aktualisiert werden. Die adaptive Wartung kann sehr umfangreich werden, beispielsweise wenn Frameworks oder proprietäre Software aktualisiert werden müssen und keine API-Kompatibilität gegeben ist.

  • Zur Perfective Maintenance gehören Änderungen, die das System in Bezug auf seinen Einsatzzweck verbessern. In der Regel sind dies Change- und Feature-Requests vom Fach, die dann umgesetzt werden. Seltener gibt es Änderungswünsche an die Systemqualitäten, wie zum Beispiel die Sicherheit oder die Skalierbarkeit. Das liegt auch daran, dass diese Änderungen oft schwierig und damit sehr kostspielig sind.

  • Preventive Maintenance: Das häufigste Diskussionsthema in Bezug auf die Systemqualität sind Maßnahmen zur Verbesserung der Wartbarkeit, um die Kosten für funktionale Änderungen konstant halten zu können. Diese werden als Preventive Maintenance bezeichnet.

Fehlertypen

Ähnlich wie die Wartung lassen sich auch unterschiedliche Typen von Fehlern kategorisieren:

  • Infrastrukturfehler: Netzwerkversagen, volle Festplatten oder superluminare Tachyonen im Prozessorkern sind durch uns während der Entwicklung leider nicht kontrollierbar, weswegen wir sie auch nicht im Detail spezifizieren. Wir möchten solche Fehler aber beobachten können und setzen dafür das Monitoring auf Infrastrukturebene auf. Mehr dazu im kommenden Artikel über die Prüfbarkeit.

  • Funktionsfehler: Irren ist menschlich, also gibt es funktionale Fehler. Neben den weit verbreiteten UI-Gremlins, die sich gut beobachten lassen, treten funktionale Fehler immer dann auf, wenn Kombinationen von Zuständen eintreten, an die man während der Entwicklung nicht gedacht hat. Dies tritt häufig bei der Integration von verschiedenen Systemen ein, die man nicht selbst kontrollieren kann. Eine falsche Antwort führt hier schnell zu unbeliebten Nebenwirkungen. Diese Fehler wollen wir mit guter Analysierbarkeit schneller bekämpfen.

  • Qualifizierte Fehler: Diese Fehler sind vorprogrammierte Antworten des Systems auf Eingaben, bei Websystemen in der Regel vom Benutzer. So möchte dieser beispielsweise einen Garantiefall eingeben, aber die Seriennummer des Geräts ist nicht korrekt. Im Rahmen der Geschäftsprozessanalyse werden die Prozesse dokumentiert. Die dabei erkannten möglichen Fehler sollten in einem Fehlerkatalog festgehalten werden. Dieser Katalog dient den Upstream­entwicklern als Referenz, damit korrekt reagiert werden kann. Nehmen...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang