In einer Zeit, in der die Anwendungsentwicklung immer teurer wird, gleichzeitig aber auch der prozentuale Anteil der Wartungskosten am Gesamt-DV-Budget auf einem (extrem) hohen Niveau zu stagnieren scheint, ist die Qualität und Lebensdauer jeder Neuanwendung von überragender Bedeutung. Um dieses Ziel zu erreichen, müssen neue Prioritäten gesetzt werden. Die Priorität "Zeit" (schnelle Realisierung) muß endgültig der Priorität Analyse und Design unter starker Einbeziehung des Endbenutzers weichen. Nur so kann sichergestellt werden, daß latent vorhandene Anforderungen, auch zum Zeitpunkt des Projektes und nicht häppchenweise in der Wartungsphase realisiert werden (maintenance by patching). Einen deutlichen Hinweis auf solche Verhältnisse gibt eine im letzten Jahr veröffentlichte DoD-(Department of Defense) Studie, die den Aufwand für die Projektdurchführung mit 40 Prozent und den für die Wartung mit 60 Prozent, gemessen am Gesamtaufwand während der Lebensdauer seiner Anwendung, angibt.

Die Frage nach Möglichkeiten zur Qualitätssteigerung und damit nach Möglichkeit zur Verlängerung des Lebenszyklus von komplexen Anwendungen ist nicht eben neu. Sie scheint vielmehr in den letzten Jahren zum Dauerbrenner geworden zu sein.

Schon vor einigen Jahren wurde die Bedeutung der Einbindung der Fachabteilung in das Projekt erkannt. Bis dato hat sie allerdings noch nicht überall den Stellenwert erreicht, den man ihr vorderhand, aufgrund der positiven Erfahrungen der letzten Jahre, zubilligen würde. An dieser Stelle sei auch auf entsprechende positive Erfahrungen aus dem Bereich des "industrial engineerings" - wie zum Beispiel aus dem Schiffsbau - verwiesen, wo ein anders geartetes Verhalten, das heißt ein Projekt ohne die Beteiligung des Kunden (=Endbenutzer) de facto undenkbar ist.

Seit nunmehr einem Jahr werden von Beratungs- oder Schulungsunternehmen in zunehmendem Umfang endbenutzerorientierte Kurse und Seminare angeboten. Ziel dieser Kurse und Seminare ist es, dem Mitarbeiter aus der Fachabteilung, das nötige Rüstzeug für ein Projekt zu vermitteln.

Die Spannweite der angebotenen Kurse und der - allerdings etwas spärliche - Veröffentlichungen zu diesem Thema, reicht von der "Einführung in die Datenverarbeitung", über Einführungsseminare in die Analyse und Designproblematik, bis hin zu Schulungen in der Vortrags- und Präsentationstechnik.

Dieses Bemühungen sind durchaus als Schritt in die richtige Richtung zu werten, bleiben jedoch zwangsläufig Stückwerk, wenn es von Seiten der Analytiker und Systementwickler an einem geeigneten Medium zur Kommunikation mangelt. Gerade auch dazu bietet sich das Prototyping an, dessen Prinzip ebenfalls dem "industrial engineering" entlehnt ist.

Das Prototyping bietet darüberhinaus die Chance, aus dem "Betroffenen" (dem Mitarbeiter aus der Fachabteilung) einen Beteiligten, ja sogar einen Partner und Gefährten auf dem Weg zu einer (und unter gegebenen Umständen) optimalen Lösung zu machen.

Der Projektmitarbeiter aus der Fachabteilung ist aus der Sicht der Anwendungsentwicklung, der Repräsentation der sogenannten "Endbenutzer" (æenduser') oder schlicht "Benutzer" ('user') Für "ihn" wird die Anwendung in der Regel in Einzelfertigung (das heißt nach Maß) gebaut und er muß letztlich mit ihr leben. Von Projekten, bei denen die entstehende Anwendung anschließend zum Beispiel als branchenspezifische Standardsoftware verkauft werden soll, sei hier abgesehen, obwohl dafür das nachfolgend Gesagte sinngemäß ebenso gilt. Hier ist in hohem Maße die konstruktive Mitarbeit des 'users' an den wesentlichen Stellen im Projektzyklus notwendig.

In Abb. 1 (Einflußmöglichkeiten des Endbenutzers im Projekt) ist schematisch dargestellt, (ohne das im nachfolgenden auf jede dieser Möglichkeiten detailliert eingegangen wird) wo solche Stellen und wo die Grenzen seiner Einflußnahme zu sehen sind. Beide muß der Endbenutzer kennen, um rechtzeitig Einfluß auf das Geschehen im Projekt zu nehmen und sich zeitliche Verzögerungen in der Realisierung oder Verlagerung von Wünschen/Anforderungen in die Wartungsphase, nicht wunschgemäßer Realisierung, sowie den damit verbundenen Ärger zu ersparen.

Ein EDV-Projekt besteht genaugenommen aus zwei Komponenten (s. Abb. 2: Einbettung des Projekts in das Unternehmen):

a) der Komponente der Fachabteilung und

b) der Komponente der Anwendungsentwicklung.

Der wesentlichste Unterschied ist der, daß in der einen Komponente der Fachabteilung die Mitteleinsatzplanung und in der Anwendungsentwicklung, die Planung der Kosten und die Bestimmung des Nutzens der zu schaffenden Anwendung, stattfindet.

Darüberhinaus befindet sich das von ihnen gebildete Projekt nicht im luftleeren Raum, sondern ist den unternehmensweit geltenden Möglichkeiten und Restriktionen, die die Systembedingungen (zum Beispiel Rechnerkapazitäten, interne Revision, unternehmensspezifisches Vorgehensmodell) des Subsystemes darstellen, unterworfen. Das Unternehmen seinerseits ist in die Umwelt (Supersystem) eingebettet und unterliegt deren Einflüssen (externe Revision, Gesetzgeber).

Die Schnittstelle der beiden Projekte ist ein Vertragsverhältnis, das sich aus den gesetzlichen Vorschriften (HGB °°38 - 44, AO °°140 - 147 und den EStR Abschn. 29 - 31),

sowie der herrschenden Meinung ableiten läßt. Es entsteht somit ein, unter Umständen nicht schriftlich fixierter Dienstleistungsvertrag, über den sich beide Seiten einig sein müssen. Bei der Abstimmung des Vertragsinhaltes, also der Beschreibung der gewünschten Lösung (Pflichtenheft), stieß man in der Vergangenheit bei zunehmender Detaillierung auf Schwierigkeiten mit der Folge, daß das Projektdesign, aufgrund mangelnder Genauigkeit oder Vollständigkeit, häufig korrigiert werden mußte. Ein hoher Wartungsaufwand, bedingt durch ständig notwendig werdende Änderungen und Nachbesserungsarbeiten, war quasi vorprogrammiert. Gerade auch hier hat sich das Prototyping bewährt, um vor dem Eintritt in die Realisierung (frozen zone), die notwendige Klarheit herbeizuführen.

Die Stellung des Mitarbeiters aus der Fachabteilung im Projekt ergibt sich aus den Prinzipien der Projektorganisation. Fachlich ist er dem Projektleiter unterstellt und disziplinarisch bleibt er weiterhin bei seinem bisherigen Disziplinarvorgesetzten. Damit ist er zugleich offizielles Mitglied in zwei Gruppen (von informellen Gruppenzugehörigkeiten wird hier abgesehen). Diese Konstellation läßt sich als "Likert'scher Gruppenaufbau" (Ausschnitt siehe Abb. 3: Likert'scher Gruppenaufbau im Projekt) bezeichnen. Er wirkt für das Projekt als Kollektor von Fachwissen, Anforderungen und Meinungen. Für seine Kollegen in der Fachabteilung, deren Meinung er mit vertritt, wirkt er als Informationsvermittler, indem er gezielt Informationen aus dem Projekt an sie weitergibt (feedback). Sowohl in der einen, als auch in der anderen Richtung erfüllt er daher eine gewisse Kanalisierungs- und Filterfunktion.

Aufgrund der gerade dargestellten Funktionen und Aufgaben des Projektmitarbeiters aus der Fachabteilung, sind an seine Person hohe fachliche und psychische Anforderungen zu stellen, da es sonst leicht zu Überforderungen kommen kann, die im Extremfall das ganze partizipative Vorgehen in Frage stellen können.

Ähnliches tritt auf, wenn dieser Mitarbeiter von seinem bisherigen Vorgesetzten, der ja weiterhin Disziplinargewalt hat, unter Druck gesetzt wird, um weniger Zeit für das Projekt, dafür aber mehr für seine "eigentliche" (frühere) Aufgabe zu verwenden.

Durch den Einsatz des 'endusers' im Projekt und speziell durch dessen Mitarbeit beim Prototyping, soll vermieden werden, daß:

- Programme am Tag der Einführung durch neue Fragenkomplexe überholt sind, die eventuell schon latent vorhanden waren oder

- richtig abgenommene Programme als fehlerhaft bezeichnet werden, weil sich die Spezifikationen geädert haben, oder weil sie jetzt anders ausgelegt werden.

Erreicht werden soll hingegen ein benutzerfreundliches Design (siehe Abb. 4: Aspekte der Benutzerfreundlikeit ), das nicht nach der Projektübergabe dauernd modifiziert werden muß, weil dies oder jenes vergessen wurde.

"Prototyping ist partizipative Systemanalyse und partizipatives Systemdesign mit, durch und für den Endbenutzer"

Obwohl damit schon sehr viel gesagt ist, läßt sich diese Definition hinsichtlich der Art und des Umfang; der Durchführung des Prototypings, erhebliche Interpretationsmöglichkeiten zu. Demzufolge wird in der Praxis auf der Aufwandsseite, das heißt beim Umfang der Durchführung zum Teil mit zu geringem Einsatz, also halbherzig, gearbeitet, was dann leicht zu Enttäuschungen hinsichtlich des prognostizierten Nutzens, bei dem gerade auch Wartungsaspekte berücksichtigt werden müssen, führen kann. Der - zugegebenermaßen - relativ langfristige Wartungsaspekt wird leider allzuoft nicht in die Nachkalkulation miteinbezogen. Das wiederum hat zur Folge, daß Projekte als rentabel erscheinen, obwohl es sich dabei, aufgrund ständig erforderlicher Nachbesserungsarbeiten,

um Resourcenfesser im wahrsten Sinne des Wortes handelt.

Der Nutzen des Prototypings (Ausnutzung der möglichen Funktionen) ist jedoch abhängig von der jeweils angewandten Form, dem Umfang und der Art der Werkzeugunterstützung. Daher erfolgt nun nach der Beschreibung des schematischen Ablaufes und der Prototypingformen, die Darstellung der Funktionen des Prototypings.

In der Anfangsphase sollte ein Teilproblem wissen Entwickler und 'useræ festgelegt werden, das für den zuletztgenannten von hohem Interesse ist.

In dieser Phase wird der Prototyp entwickelt und dem Benutzer zur Verfügung gestellt, wobei Teile daraus für spätere Programme übernommen beziehungsweise generiert werden können (zum Beispiel die Masken an sich, E-/A-Bereiche und ähnliches). Hier muß, wie bei herkömmlicher Projektdurchführung auch, darauf wachtet weren, daß die durch den Prototyp abzubildenden Vorgänge triggergesteuert und vor allem personenunabhängig sind.

Der Prototyp durchläuft kurze, inkrementelle Entwicklungszyklen die jeweils die Phasen Systemanalyse, Detailkonzeption, Gestaltung und Validierung des Modells durchlaufen.

Das Verhalten des Prototyps wird sowohl hinsichtlich seiner Akzeptanz durch den Endbenutzer, als auch hinsichtlich der Funktionen des Bassisystems überprüft. Beobachtung ist ein Kontrollmechanismus, um den Prototyp ständig zu verbessern. Modelle an sich sind daher oft - im Gegensatz zu ihrem Basissystems - von kurzer Lebensdauer.

Beim Prototyping findet der sogenannte modifizierte Top-down-approach Anwendung, wie er schematisch in Abb. 6 dargestellt ist. Dieser bietet sich schon deshalb, an weil bei ihm immer nur (Teil-) Aspekte des späteren Systems zu einem bestimmten Zeitpunkt von Interesse sind. Davon abgesehen, findet dieses Vorhaben auch zunehmend in die herkömmliche Design- und Programmiervorgehensweise Eingang.

Die Modifikation gegenüber dem herkömmlichen 'top-down-Vorgehen' besteht darin, daß nicht eine Hierarchieebene im System realisiert werden muß, bevor die darunter liegende realisiert werden kann. Im Gegenteil: Es wird auf der übergeordneten Hierarchiestufe im steuernden Teil immer nur derjenige Teil realisiert und getestet, der für den ersten Baustein der nachgelagerten Stufe nötig ist. Dann wird dieser Baustein realisiert und zusammen mit dem übergeordneten getestet. Ist dieser Teil abgeschlossen, testet man das übergeordnete System für das zweite nachgelagerte, realisiert den nächsten Baustein usw.

Hinter diesem Vorgehen steckt eine starke Testphilosophie, die auf das "Ceteris-paribus-Prinzip" aufbaut. Das heißt, eine neue Funktion wird erst hinzugenommen, wenn die "alte (-n)" Funktion (-en) bereits ausgetestet ist (sind). Damit findet eine Iteration zwischen Top-down und Bottom-up statt, die zu einer sehr hohen Qualität des Endproduktes führt. In der Praxis bestehen hinsichtlich des Vorgehens beim, beziehungsweise der Form des Prototypings zum Teil unterschiedliche Auffassungen. Gewöhnlich wird der Begriff "Prototyping" mit den beiden unten zuerstgenannten Formen in an sich unzulässiger Weise gleichgesetzt.

Beim Maskendesign mit dem Endbenutzer handelt es sich um die einfachste, am weitesten verbreitete, aber zugleich auch um die mit dem geringsten Nutzen verbundene Form. Sie ist auch Bestandteil beziehungsweise Ausgangspunkt der anderen beiden Formen.

Im Prinzip wird dabei dem Endbenutzer eine Maske gezeigt, an der er dann - hinsichtlich des Layouts - konstruktive Kritik über oder sich mit ihr einverstanden erklären kann. Letzteres wird dann auch, von leicht realisierbaren Wünschen, wie "weiter nach links ..." oder ähnliches abgesehen, schnell der Fall sein kann. Systemübergreifende Zusammenhänge können hierbei kaum vermittelt werden.

Das "Maskendesign mit dem Endbenutzer" kann genaugenommen - wie auch früher generell üblich - ohne Bildschirm, mit den bekannten "grünen Blättern" (Bildschirmentwurfsformulare) und Bleistift, also quasi .,zu Fuß" vorgenommen werden. Dies ist jedoch nicht nur sehr aufwendig, sondern auch ineffizient, mit anderen Worten also teuer.

Zusammenfassend lassen sich daher folgende drei negative Kritikpunkte an dieser Form feststellen: erstens dauert es ohne entsprechend gute Werkzeugunterstützung zu lange, zweitens ist der Endbenutzer in der Regel in seiner Vorstellungskraft hinsichtlich des späteren Dialogs überfordert und drittens können Systemzusammenhänge und Wirkungsweisen im Vergleich zu anderen Formen nur unzureichend angedeutet werden.

Der Umfang der gerade angesprochenen Werkzeugunterstützung ist hier sehr unterschiedlich. Die Palette reicht von weniger komfortablen Werkzeugen, die noch umfangreiche Formatspezifikationen erfordern und wo die Maske, um sichtbar gemacht werden zu können, erst noch umgewandelt werden muß, über Zusatzfunktionen zu Editoren (wie zum Beispiel der MODEL-Command im ISPF), bis hin zu integrierten Maskengeneratoren, wie sie zum Beispiel im TOM von Siemens oder im OPUS von IBM enthalten sind. In diesem Zusammenhang kann zum Beispiel auch der - zu unrecht unbekannte - Maskengenerator SWT04, von der Firma SWT in Bonn genannt werden.

Bei der zweiten Form des "Films" werden dem Endbenutzer zwar auch , "nur" praktisch funktionslose Masken, allerdings schon in verketteter Form, zur Verfügung gestellt. Somit gibt man ihm immerhin schon die Möglichkeit, den Inhalt und die Reihenfolge der Masken, die zum Beispiel zur Bearbeitung eines bestimmten Vorganges nötig sind, zu beurteilen.

Die Reihenfolge der Masken kann hierbei wahlfrei (durch PF-Key-Steuerung oder Eingabe von Transaktionsschlüsseln) oder starr vorgegeben sein. Der Einsatz der einen oder anderen Möglichkeit der Gestaltung der Reihenfolge ist zum einen von den jeweiligen Geschäftsvofall und zum anderen von der spezifischen Werkzeugunterstützung abhängig. Eine generelle Empfehlung kann daher hier nicht gegeben werden.

Zudem besteht bei dieser "Form-2" die sinnvolle Möglichkeit, dem Endbenutzer "seinen" Prototyp einige Zeit zum Spielen zu überlassen. Diese Möglichkeit besteht zwar prinzipiell bei der ".Form- 1" auch, ist jedoch vom Nutzen und der Bedeutung als; eher gering anzusehen. Auch hier (bei der Form-2) wird die Vorstellungskraft des Endbenutzers noch einigermaßen strapaziert, da der Prototyp ja noch nicht richtig arbeitet, das heißt nichts verarbeitet und somit kein Dialog geführt werden kann. Trotzdem kann zumindest die Reihenfolge der Masken festgelegt und auf dieser Grundlage auch über entsprechend erforderliche Ein- und Ausgaben eine Aussage getroffen werden.

Bei der Simulation bekommt der Enduser einen Prototyp, der in der Endausbaustufe schon alle Funktionen der späteren Anwendung (Sinne eines vorläufigen Modelles) enthalten kann, mit dem dann Erfahrungen bezüglich des Entwurfes gesammelt werden können. Zumindest sollten aber schon die wesentlichsten Aspekte durch ein sogenanntes 'trival-function-set' bezüglich Benutzeroberfläche (Masken), Algorithmen und Antwortzeitverhalten abgedeckt sein. Somit ist für ihn zum Teil kein Unterschied zur späteren "echten" Anwendung gegeben.

An dieser Stelle sei auch gleich auf die Gefahren dieser Fom hingewiesen. Zum einen muß dem æenduseræ klar gemacht werden, daß dies noch nicht die endgültige, sondern eine Vorabversion darstellt, die im Regelfall nicht zur Verarbeitung großer Datenmengen geeignet ist. Zum anderen muß ihm gesagt werden, daß aufgrund des im Vergleich zu den Originalbeständen mengenmäßig kleinem Testbestand, sowie aufgrund der unter Umständen besseren Performance der Testmaschine, beim Prototyping Antwortzeiten geboten werden können, die die spätere Anwendung möglicherweise nie und nimmer wird bieten können. Letzteres hat alte Prototypinghasen dazu veranlaßt, die Antwortzeiten durch den Einbau entsprechender Schleifen künstlich zu verlängern, um den Benutzer Enttäuschungen zu ersparen.

Die Simulation stellt allerdings hohe Ansprüche an die Werkzeugunterstützung. Außer einem komfortablen Maskengenerator muß hier auch eine dialogorientierte Sprache angeboten werden, die es dem Entwickler gestattet, den Prototyp schnell auf Maschine zu bringen, das heißt es herrscht hier der als 'quick and dirty' bekannte Programmstil vor. Hier bieten sich dialog- und benutzerorientierte Sprachen, wie etwa das APL an, die auch entsprechende modulare Programme (zum Beispiel APE oder OMDE) aufnehmen können und damit das Prototyping und das damit verbundene Handling von Masken, Code, Grafiken und Dateien sehr komfortabel gestalten.

Bei allen genannten Formen ist der Einsatz von vorgefertigten Prototypteilen (Masken- und Codeteile) möglich. Durch ein solches Prinzip wird der Aufwand beim Prototyping - unabhängig von der jeweiligen Werkzeugunterstützung - wesentlich verringert.

In Analogie zum Terminus Datenbank spricht man bei der Gesamtheit dieser Teile von einer Prototyp-Methodenbank, ähnlich der Bausteinbibliothek oder Methodenbank bei der "normalen" Programmierung. Insbesondere für Statistikzwecke und Management-Informations-Systeme sind hier erfolgreiche Methodendatenbanken bekannt.

Prototyping ist aufgrund der unten aufgeführten und beschriebenen Funktionen von großer Bedeutung für das Projekt:

- Feinstanalyse

(Gewinnung des "Validated statement of need")

- Testdatenerstellung (Gewinnung von "black-box"-Testdaten)

- Benutzerschulung

- Identifikation des Endbenutzers mit dem System

Bei der Feinstanalyse bekommt der Endbenutzer einen Prototyp vorgestellt, der einen (Teil-)Aspek des späteren Systems zeigt. Hierbei ist es sehr wichtig ihm diesen mehrere Tagie - ohne Aufsicht und Anleitung - zu überlassen, damit er sich in Ruhe ein Urteil bilden und konstruktive Kritik üben kann.

Das ist die feinste Stufe der Systemanalyse, der aus Benutzersicht ("locgical user view" LUV) die noch fehlenden Anforderungen ("requirements") aufgedeckt beziehungsweise bekannte Anforderungen des Pflichtenheftes ("specifications") im, notwendigen Umfang konkretisiert werden können. Die so gewonnenen Erkenntnisse ("validated statement of need") werden im Folgeschritt als Designgrundlage herangezogen.

Durch das Arbeiten mit dem Prototyp (speziell bei der Form der Simulation) tritt ein nicht zu vernachlässigender Schulungsaffekt ein, der dem Projekt in der Einführungsphase zugute kommt. Außerdem können hierbei die eingebenen Daten abgespeichert und zu Testzwecken weiterverwendet werden. Sie dienen unter anderem der Prüfung, ob das System auch mit atypischen Eingaben zurecht kommt.

Es ist unmittelbar einleuchtend daß sich jemand mit einer Sache, an der er selbst mitgearbeitet hat und in die seine persönlichen Vorstellungen miteingegangen sind, leichter und schneller identifiziert und sie nach außen hin vertritt, als das in der umgekehrten Situation der Fall wäre.

Daher wird auch speziell der Projektmitarbeiter aus der Fachabteilung, der mit Masse im Projekt vertreten ist, die Rolle des Fachpromotors bei der Einführung der Anwendung übernehmen können. Das heißt allerdings nicht, daß nicht auch Vorstellungen seiner Kollegen berücksichtigt worden wären. Jedoch ist die Wahrscheinlichkeit, daß mehr von seinen Vorstellungen Verwendung gefunden haben, eben sehr groß. Im Rahmen der Einführung ist insbesondere auch darauf zu achten, daß die jeweiligen Stellvertreter (besonders bei Führungskräften) in die Schulung miteinbezogen werden.

Darüber hinaus steht der Fachabteilungsmitarbeiter nach der Systemübergabe als Ansprechpartner der und Kontaktperson zur Anwendungsentwicklung aufgrund seiner hohen Systemkenntnisse zur Verfügung.

Der Einsatz von Sprachen der 4. Generation (sogenannte nicht-prozedurale Sprachen) widerspricht dem Gedanken des Prototyping nicht nur nicht. sondern, fordert geradezu nach dieser Vorgehensweise, Der Unterschied zu Projekten, bei denen vom Prototyp abweichende zielsprachen (zum Beispiel Sprachen der 3. Generation, wie PL/1) verwendet werden, ist jedoch der, daß der fertige Prototyp zugleich das Endprodukt ist und damit sofort (ohne Umsetzung) in Produktion gehen kann, wie das bei reinen APL-Systemen ebenfalls möglich ist.

Aus dem gerade Gesagten ergibt sich allerdings auch die Einschränkung, daß die Durchführung der Prototypingform Simulation, ohne ein entsprechendes Environment unter Aufwandsgesichtspunkten, uninteressant werden kann. In so einem Fall sollte jedoch zumindest die Form des "Filmes" angewandt werden, deren Ansprüche an die Software-Umgebung sich häufig aus der bereits vorhandenen Werkzeugkiste abdecken lassen.

Unter "entsprechendem Environment" sind hier Produkte wie Mantis, oder auch das BEAT von UNA-DAT sowie Partnerprogramme des APL von IBM, wie das APE (Application Prototyping Environment) oder das dem APE sehr ähnliche OMDE (Online Maskendefinition) - je nach Ziel-DC-System - zu verstehen.

Ist jedoch, wie oben bereits angedeutet, die Umsetzung des - unter welchem Environment auch immer - entwickelten Prototyps in einer Sprache der 3. Generation erforderlich, so ergibt sich damit immer die Problematik einer zwei- bis mehrsprachigen Anwendungsentwicklung.

Aspekte einer mehrsprachigen Anwendungsentwicklung sind:

- Der Anwendungsentwickler muß über entsprechende Kenntnisse in diesen Sprachen verfügen, das bedeutet unter Umständen zusätzlichen Schulungsaufwand; auch wenn beispielsweise der für APL und ähnliche Sprachen erfahrungsgemäß als gering anzusetzen ist.

- Zum Teil ist doppelter Codieraufwand (Entwicklungs- und Zielsprache) erforderlich.

- Die Umsetzung von Sprache A in Sprache B läßt wahrscheinlich Interpretationssmöglichkeiten zu und bietet damit potentielle Fehlerquellen.

Damit scheint das Konzept. des Prototypings einer angemessenen schnellen Realisierung qualitativ hochwertiger, komplexer Systeme entgegenzustehen. Das ist jedoch nur scheinbar so. Der hier getriebene Aufwand zahlt sich nämlich schon während der Realisierung durch abgesicherte und vor allem vollständige Vorgaben, zum Teil sogar in Form von ausgetesteter Logik aus dem Prototyp der Simulation, aus.

Abgesehen davon bietet nur das Prototyping die bestmögliche Einbeziehung des Endbenutzers und die damit verbundene Abstimmung mit der Fachabteilung. Der Gewinn liegt hierbei in einer tatsächlich erheblichen Reduzierung des Wartungsaufwandes durch ein abgestimmtes und vollständiges Pfichtenheft und Design. Diese Voraussetzungen lassen eine sehr hohe Qualität des Endproduktes, verbunden mit einer entsprechend hohen Akzeptanz in der Fachabteilung, erwarten.

Zukünftige Systeme, wie sie unter anderem derzeit vom amerikanischen Verteidigungsministerium (DoD) entwickelt werden, werden dazu führen, daß der Prototyp nach Abschluß der Arbeiten durch entsprechende Generatoren in eine maschinennahe Anwendung umgesetzt wird (einsprachige Anwendungsentwicklung). Der Prototyp wird nach der Umsetzung beziehungsweise der Einführung daher auch nicht weggeworfen, sondern - quasi als Source-Code - weitergepflegt. Etwaige Änderungen werden dann auch an ihm vorgenommen. Anschließend ist lediglich eine erneute "Umwandlung" des Prototyps erforderlich. (3)

Da diese Entwicklung noch einige Zeit in Anspruch nehmen wird, wird man bis zu deren Abschluß noch mit oben beschriebenen Verhältnissen - sicherlich jedoch nicht schlecht - leben können und auch müssen, um auf dem Weg zur Qualitätssteigerung und Verlängerung des Lebenszyklus von komplexen Anwendungssystemen ein Stück vorwärts zu kommen.

Literaturnachweis:

(1) J.R. Dunham, E. Kruesi, "The Measurement Task Area"

(2) H.O. Lubbes, "The Projekt Management Task Area"

(3) R. Balzer, T.E.Cheatham, C. Green, "Software Technology in the 1990s - Using a New Paradigm"

in:

COMPUTER, Hrsg.: IEEE Computer Society, Heft Nov. 1983 mit dem Titel "The DoD STARS Program (Software Technology for Adaptable, Reliable Systems")

* Theodor Meffert ist Unternehmensberater bei der PU Partnerschaftlichen Unternehmensberatung GmbH in Hamburg.

Aspekte der Benutzerfreundlichkeit (Human Factors) eines Systems 1)

- Benutzbarkeit der Einzelfunktionen und Bildschirmmasken eines Produktes (Layout, Intelligente Defaults u.ä.)

- Benutzbarkeit der Abläufe (Quersprungmöglichkeit, Fastpath-Technik usw.)

- Angemessenheit der Funktion in bezug auf die Arbeitsumgebung des Benutzers (Streamlining, flexibles Parsing u.ä.)

1) Anmerkung: Die Bezeichnung System bezieht sich sowol auf den Prototyp, als auch insbesondere auf die spätere Anwendung.