Die Qualitätssicherung sollte ein integraler Bestandteil jedes Softwareentwicklungsprozesses sein. Neben dem Testen funktionaler und nichtfunktionaler Aspekte sollten dabei auch die Softwarearchitektur und die entwickelten Artefakte analysiert werden.

Eine solche Analyse zielt darauf ab, die Evolvierbarkeit der Software langfristig sicherzustellen und getätigte Investitionen zu schützen. Während für die klassische Softwareentwicklung leistungsfähige Werkzeuge zur statischen Quellcode-Analyse zur Verfügung stehen, ist bei der Entwicklung auf Basis moderner Service-Plattformen etwas mehr Handarbeit nötig.

Interne und externe Qualität

Hohe Qualität ist eine wesentliche Grundlage für den langfristigen Erfolg einer Software. Dabei kann man zwischen zwei Arten von Qualität unterscheiden: externe Qualität und interne Qualität.

Die externe Qualität bezieht sich auf äusserlich erleb- und testbare Aspekte wie Funktionsumfang, Bedienbarkeit, Performanz und Sicherheit. Die interne Qualität dagegen bezieht sich auf die technische Realisierung der Software, im Wesentlichen also auf die Codebasis und die durch sie manifestierte Architektur.

Blick unter die Haube

Die Evolvierbarkeit, also die kosten- und zeiteffiziente Weiterentwicklung einer Software wird massgeblich durch ihre interne Qualität bestimmt. Schlechte interne Qualität erschwert das Testen und macht Änderungen aufwändig, fehleranfällig und kostspielig. Wird die interne Qualität nicht kontinuierlich gepflegt, verringert sie sich im Laufe der Weiterentwicklung. Dies wiederum verlangsamt die Weiterentwicklung selbst, was die Gesamtkosten der Software erhöht.

Zwar kann eine verringerte interne Qualität kurzfristig bewusst in Kauf genommen werden, um ein Feature schneller fertigstellen zu können. Man spricht dann von „technischen Schulden“, die man aufnimmt. Langfristig wirkt sich eine schlechte interne Qualität aber auch negativ auf die externe Qualität aus. Denn die Entwicklung schreitet bei zunehmend schlechter interner Qualität langsamer voran und wird fehleranfällig, bis zu einem Punkt, an dem neue Features kaum noch wirtschaftlich integriert werden können.

Interne Qualitätsziele werden üblicherweise in Form von Zielarchitekturen und Entwicklungsrichtlinien definiert. Dort finden sich z. B. Namenskonventionen, Vorgaben bzgl. Grösse und Komplexität von Entwicklungsartefakten, zulässige Abhängigkeiten oder Vorgaben für die einheitliche Behandlung bestimmter Aspekte. Beispiele für solche Aspekte sind Fehlerfälle, Kommunikation mit externen Systemen, Konfiguration, Logging und Monitoring.

Wird deren Einhaltung nicht automatisiert überprüft, steigt die Gefahr, dass die Codebasis mit der Zeit immer mehr von den Vorgaben abweicht und so „erodiert“. In der klassischen Softwareentwicklung ist diese Gefahr besonders hoch. Hier entsteht die Software durch das manuelle Schreiben von Quellcode in einer „General Purpose Language“ wie z. B. Java oder C#. Sämtliche Aspekte der Software werden mit der gleichen Sprache umgesetzt: Datenstrukturen, Transformationen, Geschäftsregeln, Benutzerschnittstellen, Anbindung an Umsysteme usw. Solche logisch sehr unterschiedlichen Aspekte sind also über technisch sehr ähnliche Artefakte verteilt (z. B. Klassen). Diese Tatsache in Kombination mit der Sprachmächtigkeit machen wissentliche und versehentliche Verstösse gegen Zielarchitekturen und Entwicklungsrichtlinien sehr einfach, und damit leider auch wahrscheinlich.

Erkenntnisse durch statische Analyse

Diese Einsicht führte zur Entwicklung von Werkzeugen zur statischen Codeanalyse. Solche Werkzeuge können Verstösse gegen Konventionen aufdecken und somit dem Entwickler helfen, sie rechtzeitig zu beseitigen.

Ein Trend der modernen Softwareentwicklung im Unternehmensbereich ist der Einsatz von Service-Entwicklungs- und Integrationsplattformen. Diese können den Wiederverwendungsgrad bestehender „Software Assets“ erhöhen und den Programmieraufwand senken. Sie werden über problemangepasste Sprachen konfiguriert. Dabei werden die unterschiedlichen Aspekte einer Software (auch „Concerns“ genannt) in spezialisierten Sprachen definiert, was häufig auch durch grafische Editoren unterstützt wird.

Beispiele dafür sind Sprachen für Geschäftsregeln, Prozessabläufe, Schnittstellen, Datenformate, Transformationen oder Routingregeln. Durch ihre Spezialisierung wird es unwahrscheinlicher, dass in einem Entwicklungsartefakt unterschiedliche Aspekte vermischt und Architekturrichtlinien verletzt werden. Bei der Umsetzung einer Zielarchitektur stehen überdies ausdrucksstärkere Strukturierungs- und Spezifikationskonzepte zur Verfügung als nur Klassen, Interfaces, Packages und Namespaces. Trotzdem ist es nicht gänzlich ausgeschlossen, dass Namenskonventionen nicht eingehalten werden, Abhängigkeiten nicht der Zielarchitektur entsprechen oder Implementierungsdetails gegen Richtlinien verstossen.

Vorgefertigte Werkzeuge zur statischen Analyse sind in diesem Bereich leider nicht verfügbar. Die spezialisierten Sprachen werden jedoch in den allermeisten Fällen in XML serialisiert, so dass sie prinzipiell gut für eine automatische Analyse geeignet sind.

Statische Analyse in der XML-Welt

Um die Qualität von XML-Artefakten sicherzustellen, die auf Basis von Service-Plattformen wie der Oracle SOA Suite und dem Oracle Service Bus entwickelt werden, habe ich zwei Ansätze entwickelt.

Mit einem Schematron-basierten semantischen Analysewerkzeug können Entwicklungsrichtlinien in Form von Regeln formalisiert und automatisch überprüft werden. So kann ihre Einhaltung für sämtliche Entwicklungsartefakte gewährleistet werden. Beispielsweise kann geprüft werden:

  • dass in jedem BPEL-Prozess ein Fault Handler vorhanden ist
  • dass der Name jeder Rethrow-Aktivität den Namen der gefangenen Faults enthält
  • dass der Name jedes Complex Types in einem XML-Schema mit einem Grossbuchstaben beginnt und auf „Type“ endet
  • dass der Name jedes SCA-Composites entweder auf „_abcs“ oder „_ebs“ endet

Weiterhin können Artefakte auf Konfigurationsfehler wie die falsche Verknüpfung zwischen Systemen oder fehlende Sicherheitseinstellungen überprüft werden.

Mit dem SOA Artifact Dependency Viewer können Abhängigkeiten zwischen verschiedenen XML-Artefakten ermittelt, visualisiert und validiert werden. Dadurch kann die Einhaltung der Zielarchitektur sichergestellt werden. So kann beispielsweise erkannt werden, wenn ein Adapter-Service unerlaubterweise direkt auf einen anderen Adapter-Service zugreift.

Die Einbindung derartiger Analyseschritte in den Buildprozess und die Darstellung der Analyseergebnisse über ein Webinterface geben Entwicklern, Architekten und anderen Beteiligten eine schnelle Rückmeldung über die aktuelle interne Qualität der entwickelten Software.

Fazit

Die interne Qualität einer Software bestimmt langfristig ihre Evolvierbarkeit und damit ihre Gesamtkosten.

Die „asset-basierte“ Softwareentwicklung und der Einsatz von Service-Plattformen verringern durch die Verwendung Aspekt-spezifischer Sprachen das Risiko der Erosion der internen Qualität.

Durch die automatische Analyse der entwickelten XML-Artefakte kann darüber hinaus sichergestellt werden, dass vorhandene Architektur- und Entwicklungsrichtlinien eingehalten werden. So werden die Investitionen, die für die Erstellung dieser Richtlinien und für die bisherige Entwicklung aufgewendet wurden, auch langfristig geschützt.

Wollen Sie mehr über die Möglichkeiten der Qualitätssicherung in Ihrem IT-Projekt erfahren? Sprechen Sie mich an!