Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

Entwickler können auf Fachabteilungen eingehen


27.12.1991 - 

Prototypen gehen bei der Realisierung nicht verloren

Bei der Entwicklung von Qualitätssoftware und ergonomisch ansprechender Masken wird das sogenannte Prototyping immer beliebter. Thorsten Micus* zeigt, warum die Erstellung von Prototypen einerseits den Anwendungsentwicklern die Arbeit erleichtert und andererseits dazu beiträgt, die traditionell vorhandene Lücke zwischen Fachabteilungen und Software-Entwicklern zu schließen.

In letzter Zeit ist im Bereich der Software-Entwicklung immer öfter vom "Prototyping" die Rede. Dabei ist aber meistens nur ein kleiner Ausschnitt dieses Verfahrens gemeint. Um Prototyping sinnvoll einzusetzen, also den vollen Umfang der Möglichkeiten auszunutzen, ist zunächst zu klären, was diese Methode alles unterstützen und verbessern kann. Prototyping kann als Methode bezeichnet werden, mit deren Hilfe die Masken und funktionalen Anforderungen und Abläufe im Bereich der Dialogverarbeitung definiert und abgestimmt werden.

Bei der Betrachtung dieses Themas lassen sich drei Bereiche voneinander trennen. Zuerst möchte ich mich dem Vorgang der Entwicklung selbst zuwenden. Seit der Einführung der phasenorientierten Erstellung von Software besteht das Problem, die Informationen aus der einen in die nächste Phase lückenlos hinüberzuretten. Die größten Schwierigkeiten entstehen beim Übergang vom fachlichen zum DV-technischen Konzept.

Die meisten Informationsverluste entstehen dadurch, daß Fachabteilungen bestimmte fachliche Zusammenhänge einfach voraussetzen - in einer Bank zum Beispiel die Eingrenzung bestimmter Bankgeschäfte auf Kontonummernkreise. Falls die Entwickler noch nicht über dieses Wissen verfügen, können Probleme entstehen.

Ein erster Ansatz war die Einführung von Entscheidungstabellen, von einer formalisierten Form der Darstellung also. Diese wurden von den Fachabteilungen entworfen und von den Entwicklern mittels Generatoren in die Programme übernommen. Da die Erstellung einer Entscheidungstabelle für die Mitarbeiter der Fachabteilungen nicht gerade leicht ist, ist der Einsatz dieser Methode Beschränkungen unterworfen. Das größte Problem bei der Software-Entwicklung liegt also darin, eine gemeinsame, einfache und eindeutige Sprache zwischen Anwender und Entwickler zu finden.

In Dialogsystemen dienen die Masken und die darin festgelegten Abläufe als Basis. Sachverhalte lassen sich anhand der Maske verdeutlichen und diskutieren. Die Art und Anzahl von Feldern auf einer Eingabemaske ist für alle Beteiligten erkennbar. Der Wertevorrat der Felder, das heißt, ob sie numerisch oder alphanumerisch sind, und eventuelle Begrenzungen, zum Beispiel Betragsobergrenzen, sind noch zu spezifizieren.

Bei besonders komplexen Fragen, zum Beispiel bei Berechnungen von Zinsen oder Auslastungen müssen die Algorithmen im Prototyp bis ins Detail realisiert werden. Die erlangte Sicherheit bezüglich der Korrektheit der Informationen rechtfertigt diese Arbeit (siehe Abbildung). Außerdem handelt es sich hier bereits um einen Teil der endgültigen Realisierung: Die Arbeit wird nicht doppelt durchgeführt, sondern nur vorgezogen.

Ein weiterer Vorteil besteht darin, daß auch Mitarbeiter aus Filialen oder anderen bisher bei der Entwicklung unbeteiligten Abteilungen mitreden können. Der Gefahr, daß die Einbeziehung dieser Diskussionsteilnehmer zu einer wesentlichen Verzögerung der Entwurfsphase führen könnte, kann durch die Projektleitung vorgebeugt werden.

Der Aufbau des notwendigen Pseudosystems (Prototypen) ist nicht nur auf PC-Anwendungen begrenzt. Mit Hilfe von Maskengeneratoren und Rumpfprogrammen lassen sich auf Großrechnern die gleichen Effekte erzielen.

Oberflächenkosmetik ist heute Standard

Nicht nur während der einzelnen Phasen bietet das Prototyping Vorteile, auch bei der Abnahme der Ergebnisse erweist es sich als nützlich. Neutrale Beobachter können anhand des Prototypen wesentlich leichter Zusammenhänge verstehen und bewerten. Dies gilt sowohl für die Verfahrenstechnik als auch für die fachliche Überprüfung. Hier sei nochmals betont, daß ein Fehler um so folgenschwerer ist, je später er entdeckt wird.

Ein weiterer Schwerpunkt bei der Betrachtung des Komplexes Prototyping ist die Anwenderfreundlichkeit. Dieser Punkt ist zwar sehr eng mit dem vorhergehenden verknüpft, soll jedoch explizit behandelt werden. Als erstes muß man sich klar machen, was dieses Schlagwort alles beinhaltet. Oft wird mit dem Begriff lediglich eine Oberflächenkosmetik assoziiert.

Daß Bildschirmmasken übersichtlich und einheitlich gestaltet sind, zähle ich nicht mehr zu den Zielen, sondern zu den Standards der heutigen Software-Entwicklung. Dies ist der auffälligste, aber sicher nicht der wichtigste Bereich. Der Computer ist nur ein Werkzeug für den Anwender und sollte sich demnach dem Menschen anpassen und nicht umgekehrt. Dies gilt nicht nur für die Belegung der Funktionstasten etc. - auch ergonomische Gesichtspunkte sind zu beachten.

Falls zum Beispiel ein Anwender ständig zwischen Tastatur und Maus hin und her pendelt, kann die Maske zwar vom Design her hübsch aussehen, doch sie wird wenig brauchbar sein. Es ist also notwendig, die täglichen Abläufe genau zu kennen. Dies setzt die Mitarbeit der Endbenutzer voraus, womit wir wieder bei der gemeinsamen Sprache sind.

Ein weiteres Problem in diesem Zusammenhang ist, daß durch die rasante weitere Entwicklung der heutigen Rechner DV-Laien meinen, technisch sei alles möglich. So sollen auch extrem selten zu bearbeitende Aufgaben in der Maske berücksichtigt werden, was zu einer Erschwernis der täglichen Arbeit führt. Wenn zum Beispiel ein Spediteur, der 95 Prozent seiner Transporte im Inland ausführt, bei der Erfassung der Aufträge immer drei spezielle Auslandsfelder überspringen muß, ist er zu Recht verärgert.

Solche Fälle zu erkennen und zu vermeiden beziehungsweise sinnvoll zu lösen, muß ein Ziel des Prototyping sein. Auf der anderen Seite können dem Endanwender neue Möglichkeiten der Realisierung beziehungsweise der Darstellung nahegebracht werden.

Ein ebenfalls wichtiger Aspekt beim Prototyping betrifft die Software-Entwickler selbst. Diese Mitarbeiter verfügen meistens nicht über das fachliche Detailwissen in den Themenkomplexen, zu denen sie Systeme erstellen sollen. Es hat sich gezeigt, daß ihre Motivation um so größer ist, je mehr die Entwickler in die Fachentscheidungen einbezogen werden. Hierbei ist die gemeinsame Basis, der Prototyp, als Brücke zu sehen.

Strittige Fragen können plastisch dargestellt und nochmals diskutiert werden. Verschiedene Lösungsmöglichkeiten lassen sich skizzieren und zur Entscheidung bringen. Selbstverständlich führt eine größere Motivation und ein umfangreicheres Fachwissen auch zu einer besseren Qualität der Software.

Nun werden viele sagen, daß das oben dargestellte Vorgehen zwar erstrebenswert, aber zur Zeit nicht durchführbar ist. Ich muß diesen Kritikern insofern zustimmen, als eine optimale, weitgehende Nutzung vom Prototyping nur im Rahmen von CASE-Tools möglich ist. Diese Werkzeuge sind aber noch nicht zur vollständigen Zufriedenheit der Anwender auf dem Markt vorhanden.

Die Praxis hat aber gezeigt, daß mit Prototyping-Tools oder auch mit einfachen Mitteln, wie Maskengeneratoren, Rumpfprogrammen etc. einige der oben genannten Aspekte abgedeckt werden konnten. Auch lassen sich die meisten Prototypentwicklungen mit in die Realisierungsphase übernehmen, so daß kein wesentlich höherer Aufwand entsteht. Ziel aller Beteiligten sollte daher sein, Prototyping als festen Bestandteil bei der Entwicklung von Software einzubauen.