Teilspezifikationen werden wie ein Puzzle zusammengesetzt, aber:

Viele Tools ignorieren die Workstation-Rolle

12.07.1985

Werkzeuge zur Software-Entwicklung sind in doppelter Hinsicht betroffen, wenn es um Benutzerfreundlichkeit geht. Einmal müssen Tools in der Sprache des Anwenders Aufgaben erfassen, um sie dann formal umzusetzen. Zum anderen sind sie selber Software. die "freundlich " zu Anwendern sein soll. Beide Eigenschaften sind für ein Software-Werkzeug erforderlich, meint Jürgen Schmitz, Vertriebsleiter für solche Tools im Aachener Systemhaus GEI.

Am Anfang aller Software-Entwicklung gibt es in den Köpfen der Anwender eine Vorstellung über das, was die neuen Programme aus führen sollen. Aufgabe des Users kann es in aller Regel nur sein, diese Ziele in seiner Sprache zu beschreiben und im Interview dem Systementwickler weitere Auskünfte zu speziellen Aspekten der Anwendung zu geben.

Ziel des Systementwicklers ist es nun, diese Beschreibung in eine streng formale Spezifikation umzusetzen. Dazu müssen die Tools, die ihm dabei helfen, formalen Spielregeln unterworfen sein. Der Grad ihrer Formalisierung ist zugleich eines ihrer wichtigsten Unterscheidungskriterien. Die beiden Extreme: reine Textverarbeitung auf der nicht formalen Seite, die lediglich hilft, die nicht strukturierte Aufgabenstellung zu dokumentieren, und auf der anderen Seite die algebraische Spezifikation.

Ergonomie heißt nicht nur, daß sich der Rechner der Sprache des Menschen anpassen muß. Er muß auch seinen Arbeitsgewohnheiten folgen. Viele Rückfragen und Fehler lassen sich sparen, wenn man das Ist-Konzept für eine Aufgabenstellung vor Ort beim Anwender aufnehmen kann. Unmittelbar beim Interviewpartner muß der Teil des Systems darstellbar sein, den der Partner überblickt und verantwortet.

Rein technisch ist es keine Frage mehr, so etwas zu lösen: dennoch ignorieren viele Tools immer noch das Workstation-Konzept. Für gute Tools ist es inzwischen kein Problem mehr, solche direkt beim jeweiligen Anwender entstandenen Teilspezifikationen wie ein Puzzle zusammenzufügen. Analysatoren, wie sie beispielsweise in der Methode "Structured Analysis" benutzt werden, prüfen das komplette System auf Konsistenz und legen die globalen Begriffe fest.

Auch hier zeigt sich, daß Grafik als Verständigungsmittel ein tragfähiger Kompromiß ist. Denn sie ist formal genug, um die Prüfungen zu erlauben, die in der ersten Phase des Software Life Cycles notwendig sind. Intelligente Werkzeuge vermögen aus solchen Grafiken schrittweise die formalen Spezifikationen zu abstrahieren.

Die bildliche Darstellung verbindet also die beiden Aspekte Verständlichkeit und Formalisierung, wobei die Formalisierung für den DV-Laien versteckt bleibt - nämlich hinter der Grafik.

Fehlt noch der Aspekt der Benutzerfreundlichkeit der Tools selbst. Wesentlich ist hier, daß die Werkzeuge im Dialog arbeiten. Nur bei interaktiven Hilfen bleibt der Anwender von umständlichen Prüfläufen verschont.

Nur so kann der Rechner seine Vorteile ausspielen, pedantisch und schnell die Einhaltung semantischer und syntaktischer Regeln abzuprüfen. Erfährt der Systementwickler von seinen Regelverstößen erst nach einem Batch-Lauf, so wird er bald darauf verzichten und lieber gleich kompilieren und binden.

Interaktive Unterstützung hilft bei einigen Tools auch über die Klippen unvollständiger oder fehlerhafter Spezifikationen. In solchen Fällen wartet ein gutes Tool schon beim Editieren mit Korrekturvorsehlägen auf. Durch ein wechselseitiges Frage- und Antwortspiel ist bei solchen Systemen dafür gesorgt, daß der Anwender direkt korrigieren kann und nicht auf zeitlich versetzte Auswertungen warten muß.

Drei Grundregeln bestimmen die Tool-Ergonomie

- Je formaler ein Tool ,um so größer die Unterstützung für den kundigen Systemanalytiker. Die Betonung liegt auf "kundig": Mit dem Formalisierungsgrad steigen die Anforderungen an denjenigen ,der das Werkzeug handhabt ,und zugleich wachsen die Komunikationshürden zum Anwerder .Beispielsweise generiert man mittels algebraischer Spezifikation verifizierten Code ,muß aber sehr früh im Life Cycle der Software so formal arbeiten , daß man keine Möglichkeit mehr hat, den Anwender die Ergebnisse der Analise- oder Entwurfsarbeit überprüfen zu lassen.

- Vorteilhafter ist es in jedem Fall ,den Rechner an die natürliche Arbeitsweise des Menschen anzupassen. Möglichst intensiv soll die Sprache und das grafische Vortstellungsvermögen des Menschen genutzt, möglichst spät im Produktionsprozeß erst die unumgängliche Formalisierung intensiviert werden . Für die Tools bedeutet dies, daß sie Software mittels einer Ausdrucksweise spezifizieren sollen, die dem menschlichen Verständnis und der menschlichen Denkweise angepaßt ist. Insbesondere in einer Phase ,in der DV-Laien involviert sind, in der aus den Köpfen der Anwerder noch Wissen geholt werden muß, sind Gesichtspunkte besonders gravierend.

- Ein ideales Verständigungmittel zwischen Anwender , Entwickler und Rechner ist die Grafik. Grafische Darstellungen simulieren menschliche Denkstrukturen besonders gut. Neue Ideen finden ihren Niederschlag zuerst in Skizzen. Komplexe Zusammenhänge bleiben oft unverständlich - trotz guter verbaler Beschreibungen.

Klein Kunde sich mehr in Dateien. Zugriffstrukturen und Programmhierarchien vertiefen . Es wird aber sofort verstehen ,daß ein ausgehandelter Rabattsatz von der Kundenkartei in das Angebot "einfließt" , und ihm wird ergänzend , daß es ja auch noch Mengenrabatte gibt, die man von der Preisliste ebenfalls in das Angebot "bringen" muß. Den zugehörigen Pfeil wird er von selbst und völlig richtig in das SA-Diagramm einzeichnen ,ohne je etwas von "Structured Analysis" gehört zu haben.