Zum Teil 1 des Artikels

Im ersten Teil des Artikels habe ich einige Qualitätkriterien für DOORS-DXL-Programme benannt. Erläutert wurde, warum aus meiner Sicht diese  Kriterien selten erfüllt werden und welchen Herausforderungen man sich dabei stellen muss. In diesem zweiten Teil will ich einige der Herausforderungen aufgreifen und mögliche, in der Praxis bewährte Lösungen skizzieren.

DXL-Entwicklung als Hochsprache – (k)ein Widerspruch?

DOORS^® DXL ist eine Sprache mit Programmiereigenheiten, die einem Entwickler das Leben teilweise extrem schwer machen.

Wegen dieser Eigenheiten ist es  aber erst recht sinnvoll und notwendig, auf Mindeststandards bei der Entwicklung zu bestehen bzw. Standards festzulegen und auf deren Einhaltung zu achten. Die verfügbare DXL-Dokumentation für die SW-Entwicklung bietet aber wenig Anhaltspunkte für Standardisierung.

Großkunden lassen sich häufig von unterschiedlichen Dienstleistern DXL-Erweiterungen realisieren. Sofern also nicht der Kunde selbst gewisse Standards definiert, blüht der Wildwuchs. Falls überhaupt Standards genutzt werden, programmiert jeder Dienstleister mit seinen eigenen Standards, die auf den gerade vorhandenen, eigenen technologischen Erfahrungen basieren. Die Praxis zeigt, dass dies weder für den Dienstleister noch für den Auftraggeber Vorteile bringt. Denn einerseits ist der Auftraggeber praktisch nicht in der Lage, neuen Dienstleistern entsprechende Vorgaben zu machen. Andererseits stellt der Lösungsentwickler oft erst sehr spät fest, dass er sich an ungenügend dokumentierte, durch die Historie begründete Vorgaben halten muss.

Dies führt früher oder später immer dazu, dass für Refactoring, Reparaturen, zusätzliche Integrationen oder Erweiterungen zusätzliche Kosten entstehen, von zeitlichen Verzögerungen mal ganz abgesehen. Und wenn dieser Fall eintritt – und er tritt fast immer ein -, dann führt das in der Regel auf beiden Seiten zu Unannehmlichkeiten – bezüglich inkonsistenter Datenstände, umständlicher Bedienabläufe, unzufriedener Anwender und Administratoren.

Diese Unannehmlichkeiten müssen aber nicht mehr sein, sie lassen sich durch die geschickte Festlegung von Standards weitgehend vermeiden

Der Liefergegenstand

Wie ist bei einer DXL-Entwicklung  eigentlich zu liefern? Tasten wir uns heran:

1. DXL-Skripte, die direkt über Einträge im DOORS-Menü erreichbar sind (der "Core")

Die Strukturen der Entwicklungsumgebung und der Laufzeitumgebung sind normalerweise unterschiedlich. Während für die Entwicklungsumgebung Fragen der Entwicklungsorganisation entscheidend sind, ist die Laufzeitumgebung eher durch die Benutzerführung oder durch technische Notwendigkeiten definiert, z.B. die DOORS-Verzeichnisstruktur.

2. DXL-Skripte, die eingebunden werden (die "Includes")

Hier gilt es zu unterscheiden zwischen den Skripten, die nur für die aktuelle Applikation relevant sind, und den Progammteilen, die als Bibliothek dienen und für mehrere Applikationen genutzt werden. Denn Bibliotheken müssen mit der für die Applikationsversion  korrekten Bibliohek-Version eingebunden werden. Das Stichwort ist hier Konsistenz beim Versionsmanagent.

3. Die Anwenderhilfe

Übersteigt eine DXL-Erweiterung einen gewissen Grad an möglichen Funktionen oder bietet sie Entscheidungspfade, sollte dem Anwender eine (Online-)Hilfe bereitgestellt werden. Unter „Hilfe“ erwartet heute aber kein Anwender mehr ein seitenlanges Dokument, in dem er Hinweise auf sein Problem finden und lesen muss. Vielmehr sollte die Hilfe mindestens den unter Windows üblichen Standards entsprechen.

Darüber hinaus unterstützen DXL-Applikationen aber fast immer einen Prozessschritt in der Produktentwicklung und stellen daher für bestimmte Prozessaktivitäten eine konkrete Lösung bereit. Wegen dieses Prozessbezugs sollte die Hilfe durch die Vernetzung von Applikations- und Prozessinformationen dem Nutzer ein hohes Maß an Nutzen und Qualität bieten.

4. Die Administratoren-Dokumentation

Bei der Dokumentation einer DXL-Applikation ist auch der DOORS-Administrator ein Anwender oder Kunde. Es genügt einfach nicht, nur die Installation oder Wartung der Applikation zu beschreiben. Vielmehr muss systematisch deutlich gemacht werden, welche Schnittstellen zu anderen Applikationen vorhanden sind, welche Attribute lesend oder schreibend genutzt werden, oder welche Veränderungen am Gesamtsystem durch die Applikation vorgenommen werden. Deshalb ist von der Dokumentation eine Qualität gefordert, die den Administrator dazu befähigt, das System tatsächlich langfristig warten und betreiben zu können.

Nur mit einem in sich schlüssigen und über die Versionen hinweg konsistenten Satz an Informationen wird der DOORS-Administrator in die Lage versetzt, bei Aktualisierungen Auswirkungen auf andere Applikationen einzuschätzen und im Umkehrschluss auch im Vorfeld von Erweiterungen auf die Vermeidung von Kompatibilitätsprobleme hinzuwirken.

5. Die Source-Code-Dokumentation

Aus unterschiedlichsten Gründen ist die personelle Fluktuation gerade in der DOORS-Software-Entwicklung recht hoch. Ohne definierte Standards bedeutet ein personeller Wechsel daher immer den Verlust von kollektivem Wissen und individueller Programmier- und Toolkompetenz.

In der Praxis beweisen aber gerade die "auf die Schnelle" entwickelten DXL-Lösungen einen extrem großen Überlebenswillen, auch wenn der Mitarbeiter, der die Applikation entwickelt hat, unter Umständen das Unternehmen schon lange verlassen hat.

Die systematische Dokumentation des Source-Codes selbst ist hier eine absolut notwendige Maßnahme, um die Wartbarkeit des Codes sicherzustellen und aufwendige, sich wiederholende Code-Analysen zu vermeiden.

6. Die Entwicklungsumgebung und die Laufzeitumgebung

Für die Entwicklung von DXL-Code wird oft nur deshalb ein simpler Editor verwendet, weil nichts anderes verfübar ist und weil die Erweiterung „jetzt gleich“ benötigt wird. Inzwischen gibt es aber eine Reihe von Werkzeugen, die eine klare Trennung zwischen Entwicklungs- und Laufzeitumgebung ermöglichen und bestimmte Arbeitsschritte hochgradig zu automatisieren helfen.

Die Verwaltung des Quellcodes und von dessen Versionen und Konfigurationen  wird damit auch für DXL selbstverständlich. Entwicklungs- und Lieferstände werden eindeutig gekennzeichnet, werden unterscheidbar und reproduzierbar.

Auch die Lieferung in unterschiedliche Zielumgebungen muß berücksichtigt werden. In der Tat genügt die Unterscheidung zwischen Entwicklungs- und Laufzeitumgebung schon lange nicht mehr. Im Rahmen eines systematischen Entwicklungsprozesses sind eine Vielzahl von Zielumgebungen möglich und sinnvoll:

• Die lokale Umgebung für die Bearbeitung des Quellcodes.
• Die Umgebung für die lokale Bereitstellung und Entwicklungstests.
• Eine (meist im Netz liegende) Umgebung, die für die Abstimmung mit Interessensvertretern genutzt wird.
• Eine Umgebung, die der Pilotierung mit einer breiteren Basis an Schlüsselnutzern dient.
• Eine Umgebung, die für Freigabe- und Integrationstests genutzt wird.
• Und schließlich die Produktivumgebung.

Jede dieser Umgebungen stellt unterschiedliche Anforderungen an die Art der Lieferung. Beispielsweise mag ein Menüeintrag zur Ausführung von Tests in den frühen Stufen notwendig, in der Produktivumgebung aber unerwünscht sein. Diese Unterschiede lassen sich manuell nicht sinnvoll verwalten und werden daher ohne eine entsprechend aufgesetzte Entwicklungsumgebung auch nicht gepflegt.

Vor allem hier unterstützt eine Automatisierung den Entwickler massiv, dessen Interesse es ja ist, bereits entwickelte Software(-teile) in unterschiedlichen Projekten wiederzuverwenden, um effizient zu sein.

7. Testumgebung

Keine Software-Auslieferung ohne Tests! Die vorstehende Aufzählung zeigt, dass im Laufe der Entwicklung viele unterschiedliche Testperspektiven existieren, die ebenso unterschiedliche Anforderungen an das Testvorgehen stellen. Die Arbeitsumgebung muss selbstverständlich auch die Testplanung und –durchführung unterstützen.

Leider zeigt sich bei DOORS eine gewisse Resistenz gegenüber Testautomatisierungen. Dennoch ist eine Testautomatisierung in weiten Teilen möglich und sollte daher auch eingesetzt werden, um die Funktionsfähigkeit vor allem von Bibliotheksfunktionen sicherzustellen. Dies abzusichern sollte daher auch Ziel festzulegender Standards sein.

Zusammenfassung

Die Anforderungen an die Entwicklung mit DXL unterscheiden sich sehr wenig von denen für die Entwicklung in anderen Sprachen – die Praxis der Entwicklung aber sehr wohl.

Die Ansprüche an die Qualität des Liefergegenstands sind im Grunde dieselben und auch der DOORS-Anwender leidet, wenn die Software nicht die Erwartungen erfüllt.

Ungenügende Qualität bei der Implementierung, der Dokumentation und bei Tests können dazu führen, dass der Anwender bei den zu etablierenden Prozessen und Methoden zu wenig unterstützt wird und dadurch der Erfolg der zugrundeliegenden Veränderungsprozesse gefährdet wird.

Im Unterschied zu anderen Hochsprachen ist die Unterstützung des Programmierers mit einer modernen Entwicklungsumgebung eher dürftig. Aber: Eine solche Entwicklungsumgebung kann – auch kostengünstig – aufgebaut werden, sie lässt sich sehr effizient nutzen, bringt sehr hohen Nutzen und unterstützt deutlich die Qualitätsanforderungen von Großkunden an die Software-Entwicklung.

Nur die technische Basis zu betrachten, greift aber zu kurz. Ergänzt werden muss sie durch Standards, welche die Qualität des Liefergegenstands jederzeit sicherstellen.

Die Aufgabe der Standards ist es, verständliche und vor allem überprüfbare Kriterien zu definieren, anhand derer entschieden werden kann, ob der konkrete Liefergegenstand akzeptiert wird.

Die Standards dienen folglich dazu, die Entwicklung von DXL-Erweiterungen zumindest innerhalb eines Produktivsystems zu harmonisieren und durch klare Regeln den Fokus auf die Funktionsentwicklung und die Benutzerfreundlichkeit zu fokussieren.

Da die Entwicklung von DOORS-Erweiterungen immer im Zusammenhang mit Veränderungsprozessen steht, wird dadurch auch der Erfolg dieser Veränderungsprozesse gefördert.

Gelingt dies, sind am Ende alle Beteiligten mit dem Ergebnis zufrieden, denn die Anforderungen an die Qualität der Prozesse und ihrer Ergebnisse werden erfüllt. Denn die Erfüllung der Anforderungen bedeutet: Erfolgreich sein.

(c) 2011 innoreq GmbH - All rights reserved.