Umfangreiche Anwendungssysteme werden immer häufiger mit Einsatz von "Prototyping" erstellt. Eine inkonsequente Handhabung führt dabei leicht zum Entwicklungschaos. Sinnvoll eingebettet in den traditionellen Software-Produktionsprozeß oder im Rahmen einer neuen geordneten iterativen Vorgehensweise kann Prototyping jedoch die Produktivität verbessern und die Kosten minimieren.

Die Idee der Herstellung von Prototypen im Rahmen der Software-Produktion ist nicht neu. Stellt doch Prototyping die ursprünglichste Art überhaupt dar, Programme zu schreiben. Der Grund, weshalb dieses Verfahren in der professionellen Softwareentwicklung bisher nicht interessant war, liegt an den Herstellungskosten für Prototypen, die mit Sprachen der dritten Generation fast so hoch sind wie das endgültige Produkt.

Die Gründe, vor der industriellen Serienproduktion Prototypen anzufertigen, sind vielfältiger als bei der Softwareproduktion. In der industriellen Produktion dienen die Prototypen unter anderem auch dazu die Grundlagen für Serienfertigungswerkzeuge zu schaffen. Für die Einzelfertigung bei der Softwareherstellung gelten die Ziele, bei der Handhabung mit dem Prototyp zu lernen, neue Ideen zu entwickeln, Teile weiter zu verfeinern und den Benutzer stärker mit in den Entwicklungsprozeß einzubinden.

"Prototyping" kann definiert werden als die Vorgehensweise, unter Einbeziehung der Benutzer ein System oder Teile eines Systems schnell herstellen, testen, prüfen und verändern zu können, bevor unter großem Aufwand und hohen Kosten das System mit allen Funktionen und Bestandteilen entworfen und implementiert wird. Zu unterscheiden sind vier generelle Prototypingformen, die auch gleichzeitig Komfortstufen darstellen:

- Masken- und Listenentwürfe, die mit dem Benutzer abgestimmt werden können. Masken und Listen werden am Bildschirm entworfen und können gedruckt oder auf Formularen entworfen werden.

- Maskenfolge-Darstellung - Maskenentwurf mit dem Benutzer und Darstellung der Maskenfolge mit eingeschränkten Verknüpfungsmöglichkeiten.

- Entwurfsmodell - Ein Teil des Systems steht mit einigen Funktionen oder den Hauptfunktionen für den weiteren Entwurf zur Verfügung. Daten können ein- und ausgegeben sowie in einer Datenbank gespeichert werden.

- Iterative Softwarentwicklung - Das Anwendungssystem wird iterativ am Modell entwickelt und ersetzt den traditionellen Softwareentwicklungsprozeß. Entwurf und Implementierung können parallel erfolgen.

Die ersten drei Stufen lassen sich in den Entwurfsphasen des traditionellen Softwareentwickungsprozeß einordnen. Die letzte Stufe kann ihn ersetzen.

Der Masken- und Listenentwurf in Zusammenarbeit mit dem Benutzer stellt die einfachste und am weitesten verbreitete Form des Prototypings dar. Sie ist auch Bestandteil der übrigen Formen mit höheren Komfortstufen. Masken und Listen werden am Bildschirm (oder auf Papier) entworfen. Der Entwurf wird dem Benutzer vorgelegt oder am Bildschirm gezeigt. So kann er konstruktive Kritik üben und Veränderungen bewirken oder sich mit dem Layout einverstanden erklären.

Diese Form des Prototypings läßt sich problemlos in den traditionellen Softwareentwicklungsprozeß einbeziehen. Eine gute Werkzeugunterstützung vereinfacht und beschleunigt die Veränderungsprozesse. Hier stehen verschiedene Werkzeugtypen zur Verfügung:

Entwurfsformulare - aufwendiges und ineffizientes Änderungsverfahren.

Texteditoren - Der Aufbau der Maske oder der Liste wird als Text eingegeben und anschließend ausgedruckt oder auf dem Bildschirm angezeigt. Die Änderungsmöglichkeiten werden durch den Komfort des Texteditors bestimmt und sind normalerweise gut. Der Nachteil ist, daß sich die auf diese Weise erzeugten Masken- und Listenentwürfe (Prototypen) nicht für die DV-technische Realisierung verwenden lassen.

Masken- und Listengeneratoren - Über Formatspezifikationen und Positionierungsangaben werden die Felder der Masken sequentiell eingegeben. Ein Generator erzeugt daraus ein Bild, das auf dem Bildschirm gezeigt oder gedruckt werden kann. Änderungen lassen sich nicht am Bild (Prototyp) vornehmen, sondern müssen über die Syntax vollzogen werden. Es handelt sich also um ein aufwendiges Herstellungs- und Änderungsverfahren.

Masken- und Listeneditoren - Sie verbinden die Vorteile der Editoren mit denen der Generatoren. Der Entwurf der Maske oder der Liste wird am Bildschirm vollzogen, indem die Felder optisch sichtbar dort plaziert werden, wo sie in der Maske/Liste positioniert werden sollen. Bildschirmbereiche lassen sich verschieben oder auswechseln. Die auf diese Weise plazierten Felder werden anschließend mit Attributen versehen und es können die erforderlichen DV-technischen Elemente generiert werden.

Dieser Werkzeugtyp ist ideal für das Prototyping, da sich Änderungen aller Art komfortabel und schnell durchführen lassen. Masken und Listen können iterativ am Bildschirm entwickelt werden und über die Generierungsfunktionen DV-technisch weiterverwendet werden.

Bei der Maskenfolge-Darstellung kann die logische Folge der Masken im Ablauf auf dem Bildschirm gezeigt werden. Entweder ist die Reihenfolge starr vorgegeben oder über Funktionstasten oder Benutzereingaben steuerbar. Es ist eine Maskenfolge ohne den vom Benutzer gewünschten funktionalen Hintergrund. Die Maskenfolge läßt sich nicht über die von den Feldinhalten abhängigen Eingaben steuern. Immerhin kann der Benutzer den Inhalt und die Reihenfolge der Masken für bestimmte Arbeitsabläufe beurteilen und konstruktiv kritisieren.

Diese Vorgehensweise läßt sich in den traditionellen Software-Entwicklungsprozeß integrieren. In der Phase, in der die Fachspezifikation hergestellt wird, muß eine Prototyping-Aufgabe vorgesehen werden, und die Vorgehensweise muß zulassen, daß bestimmte Aufgaben mehrfach durchlaufen werden, um die Änderungen, die sich durch geänderte Masken und Maskenfolgen ergeben haben, in die davon betroffenen Funktionsbeschreibungen aufnehmen zu können.

Für diese Form des Prototypings stehen zwei Werkzeugtypen zur Verfügung:

Maskenfolge-Simulator - Mit Prozeduranweisungen, die für die Realisierung des Anwendungssystems nicht weiterverwendbar sind, es werden die Maskenfolge spezifiziert, und werden Benutzereingaben möglich gemacht, die die Folge beeinflussen können. Die oft einfache Handhabung schafft die Möglichkeit, schnell Maskenfolgen zu zeigen. Der Nachteil bei der Verwendung von Maskenfolge-Simulatoren ist, daß in den meisten Fällen "Wegwerf-Prozeduren" geschrieben werden, da diese Prozeduren für die DV-technische Realisierung nicht weiterverwendbar sind.

Dialogprogramm-Generator - Mit Anweisungen (prozedural oder nonprozedural), die für die Realisierung des Anwendungssystems weiterverwendet werden können, wird ein Ablaufrahmen für Masken spezifiziert. Die Handhabung ist etwas aufwendiger als beim Maskenfolge-Simulator. Der Vorteil ist, daß die Ablaufsteuerung komfortabel gestaltet werden kann und ein fließender Übergang zur nächsten Prototyping-Komfortstufe, dem Entwurfsmodell, möglich ist. Ein weiterer Vorteil ist die Weiterverwendung des Prototypings für die Realisierung.

Das Entwurfsmodell dient dazu, den fachlichen Entwurf des Anwendungssystems herzustellen, zu konkretisieren und zu verfeinern. Die Elemente sind:

- Strukturdarstellung des Modells,

- Masken- und Listenentwürfe,

- Prototyp-Transaktionen, die Anweisungen zur Durchführung von fachlichen Funktionen enthalten,

- Logisches (externes) Datenbankschema

Für jede ins Entwurfsmodell aufzunehmende fachliche Funktion wird eine Prototyp-Transaktion eingerichtet. Es werden entweder die Hauptfunktionen oder Gruppen von Detailfunktionen eingerichtet. Dies ist abhängig davon, ob man weiter zergliedern (vertikales Prototyping) oder weitere parallele Funktionen finden will (horizontales Prototyping).

In einer Prototyp-Transaktion werden die Anweisungen (prozedural, nonprozedural) zusammengefaßt, die im Rahmen einer fachlichen Funktion Masken ausgeben, Daten erfassen, Daten aus einer Datenbank lesen, beziehungsweise in sie schreiben sollen. Diese Prototyp-Transaktionen stellen nur auf sehr grobe Weise die fachlichen Funktionen, den Datentransport und die Datenspeicherung für die Prototyping-Szenarien dar. Plausibilitäts- und Integritätsprüfungen, deren Implementation einen erheblichem Aufwand beinhalten, entfallen.

Bevor Prototyping-Transaktionen angefertigt werden können, müssen die fachlichen Funktionen des Anwendungssystem analysiert, definiert und bis zu einen bestimmten Detaillierungsgrad beschrieben worden sein. Diese Beschreibungen dienen dazu, die erste Version der Prototyp-Transaktionen anzufertigen. Im nichtenglischen Sprachraum ist es wohl auch erforderlich, parallel zu den englischen Anweisungen in den Prototyp-Transaktionen eine Dokumentation in der Landessprache des Benutzers herzustellen und mitzuentwickeln.

Parallel müssen auch der Datenbedarf und die erforderlichen Ein- und Ausgaben der fachlichen Funktionen ermittelt und beschrieben werden. Der gesamte Datenbedarf kann dann normalisiert werden und es läßt sich ein logisches (externes) Datenbankschema entwerfen. Das logische (externe) Datenbankschema kann dann als Schema benutzt werden, um im zur Verfügung stehenden Datenbanksystem eine Prototyping-Datenbasis einzurichten.

Auf diese Weise kann ein erstes Entwicklungsmodell hergestellt werden, das dann in mehreren Prototyping-Durchläufen weiter verfeinert und vervollkommnet wird. Das logische (externe) Datenbankschema des Projekts kann danach im Rahmen der DV-technischen Realisierung in das konzeptuelle Datenbankschema des Unternehmens einbezogen werden.

Diese Vorgehensweise läßt sich in den traditionellen Softwareentwicklungsprozeß integrieren. In der Phase, in der die Fachspezifikation hergestellt wird, müssen Prototyping- Aufgaben vorgesehen werden und die Vorgehensweise muß zulassen, daß bestimmte Aufgabengruppen mehrfach durchlaufen werden.

Die Anforderungen an Werkzeuge für die Entwurfsmodell-Form des Prototypings sind sehr hoch:

- Ein komfortabler Masken- und Listeneditor muß zur Verfügung stehen. Die von diesem Editor erzeugten Masken müssen über die Anweisungen der Prototyping-Transaktionen aktivierbar sein.

- Die in den Anweisungen der Prototyping-Transaktionen verwendete Sprache muß für den Benutzer verständlich und als Dokumentationssprache im Rahmen der Fachspezifikation akzeptierbar sein. Ist dies nicht der Fall, muß parallel eine Benutzerdokumentation mitentwickelt werden.

- Die Prototyping-Transaktionen sollten interpretativ ausführbar sein, damit lange Umwandlungszeiten während der Prototyping-Szenarien vermieden werden.

- Es muß möglich sein, die Datenstrukturen des logischen (externen) Datenbankschemas in einer Form zu entwerfen, die dem Benutzerverständnis weitgehend entspricht. Der einfache Aufbau von relationalen Datenbanksystemen und Tabellen, die miteinander verknüpft sind, entspricht dieser Forderung.

- Ein Datendiktionär-System wird benötigt. Dieser Datendiktionär muß in der Lage sein, das Drei-Schema-System für den Datenbankentwurf zu verwalten, nämlich das logische (externe), das konzeptuelle und das physische Schema. Das Datendiktionär-System muß darüber hinaus in der Lage sein, die Struktur des Entwicklungsmodells aufzunehmen und pflegbar zu machen.

- Ein Dokumentationssystem ist erforderlich, mit dem parallel die Benutzerdokumentation entwickelt und gepflegt werden kann.

Alle Elemente des Entwurfsmodells sollten bei der DV-technischen Realisierung weiterverwendbar sein. Sei es, daß sie direkt in der Zielsprache (Sprache der vierten Generation) geschrieben wurden oder daß Bauteile in die Zielsprache rechnergestützt umgesetzt werden können. Wenn dies nicht möglich ist, sollte zumindest die Forderung erfüllt sein, daß die Elemente des Entwurfsmodells einer für den Benutzer verständlichen fachlichen Dokumentation entsprechen.

Die iterative Softwareentwicklung ersetzt den traditionellen Softwareentwicklungsprozeß. In der reinen Form dieser Art des Prototypings werden parallel die Anforderungen des Benutzers definiert, im Prototyp implementiert und verifiziert. Dieser Zyklus wird so lange wiederholt, bis der Prototyp den Anforderungen des Benutzers entspricht. Im Endzustand stellt der Prototyp das Anwendungssystem dar. Es werden nicht Teile des Anwendungssystems, sondern das gesamte Anwendungssystem in diesem Zyklus hergestellt.

Dieses "Ein-Zyklus-Prototyping " würde in der praktischen Anwendung bei der Entwicklung von komplexen Anwendungssystemen nur schwer planbar sein. Um überschaubare, planbare und kontrollierbare Einheiten zu erhalten, könnten drei Arten von Zyklen definiert werden, die jeweils einzeln in mehreren Durchläufen bis zur Erreichung eines definierten Zwischenergebnisses ablaufbar sind:

(1) Anforderungsdefinition mit Ergebnis Anforderungsmodell

(2) Entwurf mit Ergebnis Entwurfsmodell

(3) Implementierung mit Ergebnis Anwendungsmodell (-system)

Die einzelnen Ergebnisse werden mit Prototyping-Vorgehensweisen an einem Modell in mehreren Durchläufen erarbeitet. Aufgrund des Ergebnisses eines Zyklus werden die darauffolgenden Zyklen planbar.

Das Anforderungs-, das Entwurfs- und das Anwendungsmodell sind im Sinne des Prototypings lauffähig, prüfbar und veränderbar. Ein Modell baut auf dem anderen auf und ersetzt das Vormodell. Jedes Modell ist die sowohl horizontal als auch vertikal erweiterte Version des Vorgängers. Aufgrund der Größe und Ausprägung eines Modells läßt sich der Aufwand für die Herstellung des nächsten abschätzen.

Bei der Verwendung des Drei-Schema-Datenbankmodells muß berücksichtigt werden, daß die Datenstrukturen des logischen Schemas, das im Entwurfsmodell enthalten ist, später in das konzeptuelle Schema des Unternehmens überführt werden müssen. Bis zur Fertigstellung des Entwurfsmodells kann mit den Datenstrukturen des logischen Schemas gearbeitet werden. Das Anwendungsmodell jedoch muß Datenstrukturen verwenden, die auch im konzeptuellen Schema aufgenommen wurden.

Bevor die Herstellung des Anwendungsmodells begonnen wird, muß die Voraussetzung erfüllt sein, daß das logische Schema des Unternehmens überführt wird.

Dadurch ergibt sich eine weitere Zyklusart, die nach dem Entwurfszyklus eingeordnet werden muß. Die Prototyping-Zyklen werden in der Abbildung gezeigt und einem traditionellen Phasenmodell gegenübergestellt.

Im Prototyping-Zyklus 1 "Anforderungsmodell herstellen" werden die funktionalen Anforderungen und die Datenanforderungen bis zu einer bestimmten Detaillierungsebene definiert und beschrieben und in Form von groben Entwürfen die erforderlichen Masken und Listen spezifiziert. Für jede fachliche Funktion wird eine Prototyping-Transaktion eingerichtet (siehe Entwurfsmodell). Das Anforderungsmodell stellt die erste Version des Entwurfsmodells dar. Die bereits erwähnten Werkzeuge finden Verwendung (Tabelle).

Aufgrund des Umfangs und der Ausprägung des Anforderungsmodells kann eine Aufwandsschätzung für die nachfolgenden Zyklen durchgeführt werden. Für diese Schätzung sind allerdings Erfahrungswerte aus anderen Prototyping-Projekten erforderlich.

Auf der Grundlage des Anforderungsmodells läßt sich der zweite Prototyping-Zyklus "Entwurfsmodell herstellen" durchführen. In mehreren Durchläufen wird das Entwurfsmodell sowohl vertikal als auch horizontal weiter verfeinert und spezifiziert. Es wird eine Prototyping-Datenbasis eingerichtet, nachdem ein logisches (externes) Datenbankschema modelliert wurde. Das detaillierte Entwurfsmodell besteht aus Masken und Listen, Prototyping-Transaktionen (für jede fachliche Funktion), dem logischen (externen) Datenbankschema und der Prototyping-Datenbasis. Es werden die gleichen Werkzeuge verwendet wie im ersten Zyklus.

Der dritte Zyklus "Konzeptueller Datenbankentwurf" dient dazu, das logische (externe) Datenbankschema des Anwendungssystems in das konzeptuelle Datenbankschema des Unternehmens zu überführen. Außerdem wird das physische Datenbankschema des Unternehmens überarbeitet.

Auch diese Aufgaben können iterativ am Datenbankmodell durchgeführt werden. Voraussetzung ist ein Datendiktionär, mit dem das Drei-Schema-System modelliert und verwaltet werden kann.

Im vierten Zyklus "Anwendungsmodell herstellen" werden die Prototyp-Transaktionen zu Anwendungs-Transaktionen umgearbeitet:

- Die Transaktionen werden weiter verfeinert.

- Es wird eine Verbindung zum konzeptuellen Datenbankschema hergestellt.

- Plausibilitäts- und Integritätsprüfungen werden implementiert.

- Die Transaktionen werden unter Performance-Gesichtspunkten verifiziert und überarbeitet.

- Komplexe Transaktionen können bei Verwendung einer nonprozeduralen Sprache unübersichtlich werden. Um die Wartbarkeit sicherzustellen, müssen einige Transaktionen in eine prozeduralen Sprache umgeschrieben werden.

- Datenschutz-, Datensicherheits- und Zugriffsberechtigungs-Anforderungen werden eingearbeitet.

Für jede Transaktion, Maske und Liste wird eine für den Benutzer verständliche Dokumentation hergestellt, die über eine Help-Funktion zur Verfügung gestellt oder ausgedruckt werden kann. Auch eine allgemeine Anwendungsdokumentation ist parallel mitzuentwickeln. Diese Dokumentation wird genauso wie das DV-System in mehreren Durchläufen am Modell entwickelt. Die Dokumentation wird bei der Arbeit am Anwendungsmodell mitverwendet, um auch dafür Erfahrungen und Ideen zu entwickeln.

Auch der vierte Zyklus wird mehrfach durchlaufen, unter Beteiligung der Benutzer. Erst wenn sie mit dem Anwendungssystem zufrieden sind, sollte der Zyklus abgeschlossen werden. Aus Kostengründen ist die Anzahl der Durchläufe natürlich zu begrenzen.

Wenn eine Sprache der vierten Generation verwendet wird, muß sehr sorgfältig geprüft werden, ob sie wirklich in allen Fällen Verwendung finden kann. Es besteht die Möglichkeit, daß Performanceprobleme entstehen. Komplexe Prozeduren können unübersichtlich werden (bei nonprozeduralen Sprachen) und dadurch schwer wartbar sein.

Der fünfte Zyklus "Einführung" beinhaltet alle Aufgaben, die erforderlich sind, um das System in die Benutzerumgebung zu integrieren.

*Georg Barkow ist Fachgebietsleiter Verfahrenstechnik der GMO Gesellschaft für moderne Organisationsverfahren mbH, Hamburg.

Vorteile des Prototypings

Die Vorteile und der Nutzen des Prototypings sind abhängig von der Form des Prototypings. Alle Formen fördern die partizipative Mitarbeit des Benutzers bei der Entwicklung des Anwendungssystems. Höhere Prototyping-Komfortstufen erlauben dem User, frühzeitig Teile des Systems zu sehen. Er kann Funktionen praktisch erproben. Er hat dabei Ideen und kann unter Nutzung des Modells die für ihn wichtigen Funktionen finden. Dabei darf der Benutzer Fehler machen oder kann seine Meinung revidieren, ohne daß dadurch ein großer Änderungsaufwand entsteht - ein Beitrag zur Humanisierung der Arbeit.

Durch die praktische Beschäftigung mit dem Modell ergibt sich ein außerordentlicher Schulungseffekt. Der spätere Schulungsaufwand wird dadurch minimiert. Durch die praktische Arbeit am Prototyp wird der Benutzer motiviert und setzt sich im Team und im Fachbereich positiv für die Weiterentwicklung des Anwendungssystems ein.

Kritik an der traditionellen Softwareentwicklung

- Der Prozeß ist zu bürokratisch und zu langsam.

- Die fachlichen Anforderungen lassen sich nicht ohne praktisches Modell bis zu den letzten Details definieren und spezifizieren.

- Der Benutzer sieht in der Zeit, in der der DV-Entwurf und die Programmierung durchgeführt werden, nichts vom System. Er muß darauf vertrauen, daß die Softwareentwickler die Fachspezifikationen in seinem Sinne DV-technisch umsetzen. Es besteht die Gefahr, daß er zur Zeit der Integration und Erprobung sein System "nicht wiedererkennt".

- Die Entwicklung des Entwurfs dauert zu lange.

- Wenn die Fachspezifikationen endlich fertig ist, haben sich die fachlichen Anforderungen inzwischen geändert.

- Der Benutzer weiß oft nicht genau, was er will, wenn er kein praktisches Modell hat, an dem er sich orientieren kann.

- Entwurfsänderungen sind oft aufwendig.

- Der Lernprozeß wird nur unzureichend unterstützt.

- Eine partizipative Beteiligung der Benutzer ist nicht immer ausreichend gewährleistet.

Risiken des Prototypings

- Prototyping ohne geregelten Aufgabenzyklus innerhalb eines traditionellen Softwareentwicklungs-Prozesses oder im Rahmen einer iterativen Softwareentwicklung birgt das Risiko in sich, daß Software entwickelt wird, die nicht "zu Ende gedacht" und fehlerhaft ist (quick and dirty), und daß wichtige Qualitätsmerkmale, wie Wartbarkeit, Effizienz, Funktionserfüllung oder Sicherheit nicht beachtet werden.

- Ohne anfängliche Definition und Spezifikation der Benutzeranforderungen bis zu einem bestimmten Grad und bis zu einer bestimmten Detaillierung, ist es nicht sinnvoll, einen ersten Prototyp einzurichten. Je weniger konkret ein Prototyp ist, desto schwieriger wird es, an ihm zu arbeiten. Das Risiko besteht, daß die anfänglichen Änderungen sehr umfangreich sind, so daß die Benutzer die Lust verlieren, Prototyping durchzuführen.

- Je weiter der Prototyp von dem vom Benutzer gewünschten Modell entfernt ist, desto größer ist der Aufwand, das Ziel zu erreichen. Die Benutzer können das Vertrauen verlieren, daß das Anwendungssystem jemals fertig wird, speziell bei großen und komplexen Systemen. Prototyping erfordert eine Aufteilung von großen Projekten in kleine, überschaubare Einheiten.

- Aus der Sicht der Benutzer kann es so aussehen, daß der Prototyp schon das fertige Anwendungssystem darstellt. Wichtige Fehler- und Konsistenzprüfungen fehlen aber noch. Genauso ist es möglich, daß die Datenbankschemata überarbeitet werden müssen. Wie die Praxis zeigt, kosten diese Dinge viel Zeit. Die Benutzer könnten ungeduldig werden, da sonst ja immer alles so schnell möglich war, und könnten Druck auf das Entwicklungsteam ausüben.

- Beim Prototyping wird das System der Benutzer entwickelt, die am häufigsten und intensivsten am Prototyping beteiligt sind. Wichtige Funktionen, die von unbeteiligten Benutzern benötigt werden, werden nicht berücksichtigt.

- Besteht ein System aus einer großen Vielzahl von Elementen, steigt die Verknüpfung untereinander meist überproportional. Änderungen am Prototyp sind nicht mehr so einfach und schnell möglich oder sie werden nicht mit allen Konsequenzen durchgeführt. Bei konsequenter Durchführung werden die Prototyping-Szenarien ineffektiv.

- Wenn die Benutzer nicht in der Lage sind, ihren wichtigen Beitrag zum Prototyping zu leisten (Tagesgeschäft), wird Prototyping ineffektiv.

- Wenn das Projektteam von der Prototyping-Vorgehensweise nicht überzeugt ist, kann es sehr leicht nachweisen, daß diese Art von Softwareentwicklung nicht funktioniert.

- Es müssen Werkzeuge zur Verfügung stehen, die den Prototyping-Prozeß unterstützen, wie eine Sprache der vierten Generation, Masken- und Listen-Editoren, ein Datendiktionär, der das Drei-Schema-System für den Datenbankentwurf unterstützt und die Systemelemente und deren Verknüpfungen verwaltet, oder ein Dokumentationssystem. Ohne diese Werkzeuge ist der hohe und schnell erforderliche Änderungs- und Verwaltungsaufwand beim Prototyping nicht zu realisieren.

- Im nichtenglischen Sprachraum muß parallel eine Systemdokumentation durchgeführt werden, um zu vermeiden, daß die Benutzer bei komplexeren englischen Spezifikationen in der Anwendungssprache "aussteigen".