"Qualität läßt sich in ein Produkt nicht hineinprüfen, sie muß hineinkonstruiert werden" - so die Forderung von Dr. Jürgen Gutmann* an die SW-Entwickler. Sein Fazit: CASE kann man heute genauso wenig kaufen wie CIM.
Wartbarkeit von Anwendungssoftware ist die Konsequenz einzelner Qualitätsmerkmale wie Zugänglichkeit, Lokalität, Gleichförmigkeit, Selbsterklärungsfähigkeit und Dokumentationskonsistenz. Auf diese Kriterien müssen die Konstruktionslehre, der Konstruktionsprozeß, die Konstruktionstechnik und auch die Konstrukteure selbst ausgerichtet sein. In der Sprechweise der Ingenieursdisziplin "Software-Engineering" bedeutet dies eine Ausrichtung des allgemeinen Entwicklungs- und Produktkonzepts der Projekt- und Wartungsorganisation, der Software-Produktionsumgebung (CASE im engeren Sinne) sowie der Kenntnisse, Erfahrungen und Motivation der Softwareingenieure .
Es ist ebenso üblich wie irreführend, unter Wartung alle Aufgaben zusammenzufassen, die anfallen, sobald den Anwendern ein ziemlich stabiles System zur Verfügung steht. In Wahrheit handelt es sich um unterschiedliche Tätigkeiten, die eine ganze Reihe verschiedener Einzelaspekte umfassen. Ein Vergleich zur Automobilbranche bietet sich an: Die Situation in der SW-Wartung sieht ähnlich aus, als würde man den Pannendienst der Automobilclubs, die Fehlerbehebung in einer Reparaturwerkstatt und die Restaurierung eines wertvollen Oldtimers in einen Topf werfen. Im übrigen gibt es bei Software keinen Verschleiß; deshalb ist das Wort "Wartung" in seiner umgangssprachlichen Bedeutung gänzlich unpassend für das, was die DV-Branche unter diesem Begriff versteht:
- Pannennotdienst zum Aufrichten abgestürzter Anwendungen, ferner technische und organisatorische Maßnahmen, die ein erneutes Auftreten der gleichen Panne verhindern sollen;
- Schadensbeseitigung für die durch Systemfehler verursachten Inkonsistenzen in Daten, gegebenenfalls mit Hilfe ausdrücklich für diesen Zweck geschriebener Programme;
- Reparatur von gemeldeten Fehlern, deren Ursachen in der Spezifikation, der Konstruktion oder der programmatischen Umsetzung liegen, mit jeweils verschiedenen Konsequenzen für die Fehlerbehebung;
- Änderungen und Erweiterungen in der Benutzerschnittstelle, zum Beispiel andere Bezeichnungen, andere Anordnung der Informationen, optimierte Abläufe für routinierte Benutzer;
- Modifikationen und Ausbau von Funktionsabläufen (Dialogen und Jobs), ausgelöst zum Beispiel durch Änderungen in der betrieblichen Organisations- und Ablaufstruktur;
- Änderungen und Erweiterungen der logischen Datensichten und der physischen Datenstrukturen für modifizierten oder zusätzlichen Informationsbedarf;
- Hinzufügen gänzlich neuer Funktionen - gegebenenfalls mit neuen Datenbeständen und neuen Algorithmen;
- Anpassung an neue Basissoftware (neue Releases);
- Portierung auf eine andere Basissoftware;
- Sanierung von Altsystemen, um weitere Wartung überhaupt mit vertretbarem Aufwand durchführen zu können;
- Nachziehen von individuellen Modifikationen in neuen Releases der Standard-Anwendungssoftware.
Änderungen und Erweiterungen, die durch schlecht implementierte oder neue Anforderungen ausgelöst werden, kommen überall vor und machen insgesamt etwa zwei Drittel des Wartungsaufwands aus Für beide Bereiche sind im wesentlichen die gleichen Einzeltätigkeiten erforderlich und identische Produktmerkmale relevant. Eine exakte Trennung zwischen Modifikationen und Ausbau ist deshalb nicht unbedingt erforderlich und erweist sich in der Praxis überdies als schwierig.
Wie immer bei der Bewältigung von Problemen tut man gut daran, den Lösungsweg in Arbeitsabschnitte zu zerlegen. Bei der Modifikation von Anwendungssoftware fährt dies zu folgenden fünf Phasen: Aufgabe verstehen; Lösungsvorschlag erarbeiten; Änderung beziehungsweise Erweiterung durchfahren; Ergebnis prüfen; geänderte Komponenten einführen und stabilisieren.
Der Umfang der geplanten Modifikationen bestimmt, ob die Arbeit von einem Mitarbeiter an einem Tag erledigt werden kann, oder ob es sich um die Phasen eines Projekts handelt, an dem mehrere Entwickler über Wochen und Monate hinweg beschäftigt sind. Das ist natürlich ein gravierender Unterschied für die Wahl einer angemessenen Organisationsform, aber bei einer Analyse der Produkt- und SPU-Eigenschaften relativ unerheblich.
Feedback mit der anfordernden Stelle nötig
Anhand der genannten fünf Arbeitsschritte kristallisieren sich elf Merkmale der Produkte heraus, ferner eine Software-Produktionsumgebung (SPU), eine Projekt- und Wartungsorganisation und ein allgemeines Entwicklungs- und Produktkonzept. Die Beachtung dieser Kriterien macht die Wartung und Weiterentwicklung effektiver und sicherer .
Um die Aufgabe zu verstehen (Arbeitsabschnitt 1), ist häufig Rücksprache mit dem Anforderer nötig, immer jedoch das Verständnis des Produkts, Sich hierfür jedesmal durch die fachliche und technische Dokumentation hindurchzuarbeiten, macht wenig Sinn.
Im Normalfall sind Anforderungen mit bestimmten Komponenten des Systems verbunden - eine Bildschirmmaske, in der die Anordnung der Felder ungünstig für die Eingabe ist; ein Dialog, dessen Schrittfolge nicht richtig zu den gewohnten Arbeitsabläufen paßt; ein Menü, das wegen anderer Arbeitsaufteilung weitere Funktionen enthalten sollte; ein Datenobjekt, zu dem in Spezialfallen eine weitere Eigenschaft gespeichert werden muß; ein Algorithmus, der abhängig von einer neuen Ausprägung einer Objekteigenschaft eine Variante enthalten soll.
Es ist sicher günstig, wenn man genau über diese Komponenten in eine Produktinformation einsteigt, sich wie in einem Stücklistenprozessor die Stammeigenschaften eines Bausteins ansieht, und entlang den Beziehungen zu anderen Komponenten in der Produktinformation navigieren kann Benötigt wird dafür eine Produktdatenbank, oft auch Dokumentationssystem, Dictionary, Repository oder Enzyklopädie genannt.
Die Produktionsdatenbank erlaubt es, Produktmodelle (Ergebnis- oder Dokumentationsmodelle) zu definieren, die aus Komponententypen (Dokumenttypen, Membertypen),Eigenschaftstypen (Kapiteltypen, Attributtypen) und Beziehungstypen (Relationstypen, Linktypen, Verweistypen) bestehen. Dieses Informationssystem muß es ermöglichen, alle Komponenten des Produkts typgerecht zu pflegen.
Im zweiten Arbeitsabschnitt, "Lösungsweg erarbeiten", wird festgelegt, welche Komponenten des Produkts zu ändern, zu ersetzen oder neu zu erstellen sind. Ferner gilt es, herauszufinden, wie sich diese Bausteine nach der Änderung gegenüber anderen darstellen. Es geht also letztlich darum, neue Spezifikationen der betroffenen Komponenten zu definieren. Erst aus diesen Pakten kann der für die Änderung erforderliche Aufwand einigermaßen verläßlich abgeschätzt werden.
Bei schlecht strukturierten Produkten und unzuverlässiger Dokumentation ist dieser Arbeitsschritt leicht mit mehr Aufwand verbunden als der gesamte Rest der Änderungsarbeiten. Oft erweist sich diese Phase sogar als so aufwendig, daß ein Try-and-Error-Vorgehen mehr Effizienz bringt. Folgende Produkt- und SPU-Eigenschaften sind gefordert:
- Vollständigkeit und Konsistenz von Beziehungsinformationen;
- Konsistenz von ausführbaren Komponenten mit ihren Beschreibungen;
- Trennung von Zweck, Spezifikation und Konstruktion für Funktionskomponenten;
- automatische Pflege von Redundanzen;
- übersichtliche und einheitliche Produktarchitektur .
Was ist für eine Spezifikation der Änderungen und eine Aufwandschätzung zu tun? Zunächst gilt es, eine Liste der betroffenen Komponenten zusammenzustellen. Als Beispiel kann die Modifikation einer Dispositions- und Einkaufsanwendung in einem Fertigungsunternehmen dienen. Über ein für jedes Teil geführtes Kennzeichen wird die Art der Beschaffung gesteuert.
Produktübergreifendes Dictionary von Vorteil
Für bestimmte Teile soll eine neue Beschaffungsart gelten: Just-in-Time entsprechend dem aktuellen Montagefortschritt in einer mehrstufigen Arbeibgruppenfertigung. Das sieht in der für die Beschaffung zuständigen Fachabteilung ganz einfach aus; die Teile laufen nämlich nicht über die bereits vorhandenen Bedarfsermittlungs- und Bedarfsdeckungsfunktionen, sondern werden an ihnen vorbei durch Zusammenspiel von Werkstattsteuerung und Zulieferer beschafft.
Ausgangspunkt für die Zusammenstellung der Liste mit den betroffenen Komponenten ist hier das Kennzeichen "Beschaffungsart". Hierzu sollte innerhalb der Produktdatenbank - oder besser in einem produktübergreifenden, unternehmensweiten Dictionary - eine Beschreibung dieses Kennzeichens vorhanden sein, die mit allen seinen Verwendungen in Datendeklarationen verknüpft ist: Masken, Listen, Belege, Records, Views, Modulschnittstellen.
Diese Deklarationen wiederum müssen mit allen Modulen verknüpft sein, in denen sie zum Einsatz kommen. Ebenso werden alle Dokumentationsteile - Helptexte, Beschreibung von DV-Funktionen und Algorithmen - benötigt, die einen Bezug zu dem Datenelement "Beschaffungsart" haben. Vielleicht gibt es auch Konsistenzregeln, die dieses Datenelement mit anderen Datenelementen in Beziehung setzen; so könnte beispielsweise die Beschaffungsart Einfluß darauf haben, ob und wo ein Teil gelagert werden darf.
Alle genannten Beziehungsinformationen sind über die gesamte Lebenszeit des Produkts vollständig und konsistent zu halten. Das ist manuell nicht möglich. Die Beziehungen zwischen den einzelnen Bausteinen des Produkts müssen deshalb von geeigneten SPU-Komponenten automatisch gepflegt werden. Hierfür können innerhalb der SPU unterschiedliche Mechanismen implementiert sein:
- Definition von Attributen eines Komponententyps, die Verknüpfungscharakter haben für Datenelemente sind dies beispielsweise die Namen der Module für Eingabeprüfungen oder Ausgabeaufbereitung; das Datenbank-Management-System (DBMS} kennt diese Attribute und baut die Verknüpfungen beim Update auf;
- Aufbau von Verweisen aus beschreibendem Text; zum Beispiel durch Verknüpfungsschlüsselworte, die den Beziehungstyp charakterisieren, und Komponentennamen, die den jeweiligen Partner in einer zweistelligen Beziehung bezeichnen; das DBMS analysiert dabei den Text bei jedem Update;
- Erzeugen von Beziehungsinformationen aus Programmodulen durch Generatoren und Übernahme dieser Informationen in die Produktdatenbank;
- Verwendung von Sprachen und Compilern, die auch Verwendungsinformationen erzeugen und separate Übernahme dieser Informationen in die Produktdatenbank;
- Ermittlung der Verknüpfungsinformation durch Scanner - gegebenenfalls für jeden Komponententyp - und separate Übernahme in die Produktdatenbank.
Homogene Produktionsumgebungen, die sich für gewöhnlich mit dem Attribut "der vierten Generation" schmücken, haben den Vorteil, solche Mechanismen mitzubringen - allerdings nur für die vom Hersteller vorgesehenen Verknüpfungstypen. Erweiterungen sind vom Anwender kaum implementierbar. Dagegen kann man beim individuellen Zusammenbau einer integrierten heterogenen Produktionsumgebung darauf achten, daß die verwendeten Werkzeuge entsprechende Schnittstellen zur Verfügung stellen. Allerdings wird man mit ihnen nur schwer ein Maß an Interaktivität und Gleichförmigkeit für den Benutzer erreichen können, wie man es erwarten darf.
(wird fortgesetzt)
* Dr. Jürgen Gutmann ist Leiter des Bereichs Methoden und Verfahren bei der Heyde + Partner GmbH, Bad Nauheim.
Im ersten Teil seines Beitrags erläutert Jürgen Gutmann den Begriff Software-Wartung und unterteilt ihn in fünf Arbeitsschritte: Aufgabe verstehen; Lösungsvorschlag erarbeiten: Änderung/Erweiterung durchführen: Ergebnis prüfen: geänderte Komponenten einführen und stabilisieren. Während der Autor den ersten Teilbereich bereits im Anschluß an seine allgemeinen Erläuterungen eingehend beleuchtet, wird eine ausführliche, Beschäftigung mit den anderen Schritten im zweiten Teil folgen.