Zurück zu RAD-Tools
Hauptseite Weiter zum Anhang

Vorgehen: Ein beispielhafter Prototyp

  1. Zieldefinition

    Ein sinnvoller erster Schritt ist die Klärung, was genau erreicht werden soll:
  2. Grobdesign

    Ein Prototyp ist ein einfacheres Programm ist als ein Endprodukt; Das Risiko, dass Design-Fehler schwere Folgen in der ganzen weiteren Entwicklung haben werden, wird dadurch abgemindert, dass es nach dem Prototyp zu einem Redesign kommen kann. Trotzdem empfiehlt es sich, auch beim Design des Prototypen sorgfältig vorzugehen. Eine sorgfältige Planung erspart später Mehraufwand. In dieser Phase sind zwei Fragen zu klären:
    1. Was soll das Programm tun / können?

      Niemand erwartet von einem Prototyp die volle Funktionalität des Endprodukts. An dieser Stelle sollte man sich also eine Vorführung (entweder durch ein Mitglied des Teams oder ein "Ausprobieren" des Benutzers selbst) vorstellen und überlegen, welche Teilfunktionalitäten vorgestellt werden sollen. Es gilt hier ein gutes Verhältnis von Nutzen zu Aufwand zu erzielen.

    2. Wie soll das Programm aussehen?

      Allgemein geht es hier um eine grobe Skizzierung von Bildschirm-Inhalten bzw. Form-Strukturen. Es ist zweckmäßig, hier nicht gleich mit einem Tool loszulegen, sondern erste Skizzen mit dem Bleistift auf Papier vorzunehmen. In diesem Stadium ist kein Tool so effektiv wie das Freihandzeichnen!

  3. Auswahl des/der Entwicklungs-Tools

    Auch hier gilt: Die Entscheidung gilt vielleicht nicht für das gesamte Projekt, aber es wäre auch nicht verkehrt, wenn das mit den gewählten Werkzeugen gewonnene Know-how sowie das Coding auch für das Endprodukt weiterverwendet werden könnten. An dieser Stelle sollte man also mit offenen Augen und fast zwanglos "shopping" gehen, dabei allerdings die Aufgabe im Hinterkopf behaltend.

    Die Hersteller machen es einem mit der bestehenden Vielfalt von Produkten nicht unbedingt leicht. Es gilt, viele Aussagen zu prüfen und verhießene Qualitäten gegeneinander abzuwägen. Eine sinnvolle Vorgehensweise ist folgender Drei-Stufen-Plan:

    1. Erstellung einer Liste mit möglichen Kandidaten. Der Markt ist in ständiger Bewegung; zwei gute Ideenquellen sind Kollegen mit Expertenwissen sowie das Internet.
    2. Eliminierung der Unzweckmäßigen. Es gibt einige Faktoren, die bei der Auswahl der "Abschusskandidaten" dienen:
      • "Exoten-Umgebungen" (z.B. Lisp, Prolog, Clarion), für die auch noch kein Know-how zur Verfügung steht, stellen einen Risikofaktor dar.
      • Produkte mit Preisen jenseits von Gut und Böse (auch im Hinblick auf die durch den Kunden zu finanzierende End-Version) sollten fallen gelassen werden, ehe man sich falsche Hoffnungen macht.
      • Produkte, die interpretiert laufen (z.B. die Sprache Perl), können Performance-Probleme mit sich bringen; außerdem muss hier in vielen Fällen der Quellcode ausgeliefert werden. Solche Produkte eignen sich vielleicht durchaus für den Prototyp, man muss sich aber rechtzeitig Gedanken machen, wie das Endprodukt den Anforderungen entsprechend zu implementieren sein wird.
      • Produkte, die nicht in der Ziel-Umgebung laufen (z.B. Unix-/Linux-basierte Tools, wenn der Kunde mit Windows arbeitet) sind mögliche Kandidaten für einen Prototyp, doch danach müsste wieder eine geeignete Alternative gesucht werden.
      • Produkte, denen wichtige Features fehlen. Ein GUI-Design-Tool ohne Datenbankschnittstelle wird für ein Datenbankprojekt wohl nicht in Frage kommen.
    3. Eingrenzung der verbleibenden Auswahl. Falls jetzt immer noch mehrere Alternativen zur Verfügung stehen, kann man sich für diejenige entscheiden, für die es am meisten Know-how gibt bzw. die die meisten Features oder die größte Flexibilität aufweist. Vielleicht gilt es hier auch eine Entscheidung nach finanziellen Gesichtspunkten zu treffen.
  4. Zielgerichtetes Einlernen in die Entwicklungsumgebung

    Sofern die Team-Mitarbeiter nicht gerade am Fließband Prototypen in der gleichen Umgebung herstellen, werden sie sich in das Produkt einarbeiten müssen. Heutzutage bieten viele Entwickler-Produkte eine verwirrende Vielzahl von Features; daher ist es sinnvoll, sich beim Kennenlernen des Tools auf die Aspekte (z.B. GUI, Datenbank) zu konzentrieren, die für den Prototyp oder vielleicht später für das Endprodukt gebraucht werden, nicht aber für die vielen netten Beigaben, die die Feature-Liste aufblähen (z.B. Web-Interface, SAP-Anbindung, ...)

    Unter Umständen zeigt sich erst hier, bei näherer Betrachtung, eine entscheidende Schwachstelle eines Produkts. Das ist nicht schlimm, denn noch ist Zeit, zu Punkt 3 zurückzukehren!

  5. Source Code Control

    Es sollte möglichst früh schon bei der Erstellung des Prototyps dafür gesorgt werden, dass der Quellcode sicher, nachvollziehbar und rückversionierbar ist. Das heißt, jeder Entwickler sollte in der Lage sein, auf Knopfdruck

    Das Vorhandensein einer verlässlichen Möglichkeit, Code zu sichern und wieder herzustellen ist enorm wichtig: Es macht den Unterschied zwischen einem ängstlichen Arbeiten in Unwissenheit der Versionsgeschichte und in Sorge um den Quellcode und einer lockeren, experimentierfreudigen Arbeitsweise mit Schwerpunkt auf produktiven Tätigkeiten.

    Es gibt eine ganze Reihe von Produkten, die als Source Code Control System geeignet sind. Hier eine unvollständige Auswahl:

  6. Dokumentation

    Die Dokumentation gehört nicht an das Ende eines Entwicklungsprozesses, sondern an deren Anfang. Es sollte schon vor, spätestens parallel zum Entwicklungsanfang eine übersichtliche Struktur für Dokumente zu einzelnen Modulen und Funktionalitäten aufgebaut werden. Vor der Entwicklung dient die Dokumentation als Spezifikation für die Entwickler, währenddessen hält der Entwickler in ihr seine Entscheidungen zu technischem Design und Implementierung fest, und gegen Ende kann ein Dokumentations-Team daraus ein Benutzerhandbuch erstellen.

    Einige wichtige Grundsätze:

  7. Stufenweiser Aufbau des Prototyps

    Jetzt werden Schritt für Schritt Aussehen und Funktionalität gemäß Schritt 2 erstellt. Vielleicht fängt man mit einer Bildschirmmaske an, baut ein einfaches Rahmenprogramm, in dem die Maske angezeigt werden kann, und verleiht dann der Maske noch ein funktionierendes Daten-Interface.

    Die Optik sollte einen Eindruck der Zielvorstellung vermitteln, sollte aber nicht bis ins Detail ausgefeilt werden. Meistens ergeben sich im Gespräch mit dem Kunden gravierende Änderungen, und es wäre schade um die Fleißarbeit.

    Die Funktionalität kann eine Untermenge der Fähigkeiten des Endprodukts darstellen, muss aber nicht. Es geht viel mehr darum, dem Endbenutzer etwas zu zeigen, als dem Programm echtes Leben einzuhauchen. Die Arbeit mit "echten" Daten und Vorgängen ist also nur dann zu empfehlen, wenn sie weniger Arbeit macht, als eine hinreichende Attrappe zu zimmern. Niemand erwartet, dass ein Prototyp fertig ist. Anders als bei Beta-Versionen des Endprodukts ist es hier ratsam, lieber viele Funktionen zu bauen, die teilweise vorführbar sind als einige wenige, die perfekt ausgearbeitet sind.

    In diesem Sinne kann man eine Tabelle z.B. statt über Datenbankzugriffe auch durch "Hartcodierung" einiger Werte im Programm aufbauen. Eine noch "leichtere" Variante kann mit hilfe von Screenshots und einem Grafik-Tool erzielt werden: Teile einer Maske könnten als Bitmaps z.B. aus Word, Excel oder PowerPoint "herausphotographiert" werden.

    Wenn der Prototyp später zum Endprodukt ausgebaut werden soll, ist es wichtig, diese "eingesparten Funktionalitäten" sorgfältig durch programm-interne Dokumentation (= Kommentare) zu kennzeichnen, nach dem Motto:

    // Hier muss später eine databaseAwareTable mit Zugriff auf DataTab1 hin!
    showExcelBitmap("Tabelle1.BMP");
  8. Testen

    Ähnlich wie die Dokumentation sollte auch das Testen die Entwicklung begleiten. Bei einem Prototyp ist sicher nicht so intensives Testen angesagt wie bei einem Endprodukt; es gibt weniger Funktionalität und der Kunde ist eher bereit, Schwachstellen in einem Prototyp zu übersehen. Trotzdem sollte schon in der Prototyp-Phase ein lockerer Testplan eingeführt werden, der in der Endprodukt-Phase dann detailliert und formalisiert werden kann.

    Für einen Prototyp, der überwiegend "fürs Auge" produziert wird, kann anhand einer Checkliste, die grob den Ablauf der geplanten Vorführung wiederspiegelt, manuell getestet werden. In der Endprodukt-Phase sollte das Schwergewicht auf automatisierbare White Box- und Unit-Tests verlagert werden.

  9. Automatisiertes Deployment

    Eine Projektphase, in der sich auch Profis oft stümperhaft anstellen, ist das Deployment, also die Produktion einer "Kundenfähigen" Endversion. Dies gilt auch für den Prototyp! Diese Phase besteht oft in einer hektischen Kopier-Orgie, in der die zum Betrieb beim Kunden nötigen Dateien aus verschiedenen Quellen zusammengeklaubt und hastig miteinander verknüpft werden. Hier entstehen oft Reibungsverluste, weil die Arbeitsumgebung des Entwicklers sich meistens stark von der des Kunden oder auch des Vorführgeräts unterscheidet. Es sollte also zeitig schon vor Abschluss des Prototyps dafür gesorgt werden, dass eine vorführ- und auslieferbare Version des Programms möglichst auf Knopfdruck und mindestens überwiegend direkt aus dem SCCS (s.o.) erzeugt werden kann. Jedes andere Vorgehen führt zu den "beliebten" Fragen:

  10. Aufräumen und Verschönerung

    Falls dank umsichtiger Planung und erfolgreichen Einsatzes von RAD-Techniken am Ende des Prototyps noch Zeit ist, kann damit begonnen werden, stellenweise die Attrappen durch echte Funktionalität zu ersetzen. Gleichzeitig sollte ein Teil des Teams die Tests nach Schwachstellen im Prototyp intensivieren, die vor der Präsentation noch "runder" gemacht werden können.

    Normalerweise wäre davon abzuraten, noch kurz vor "D-Day" an einem Programm zu feilen; aber wenn man sich einiger Änderungen nicht ganz sicher ist, kann man die betroffenen Module ja dank SCSS mühelos auf den letzten, im Test erfolgreichen Stand "zurückdrehen".

  11. Präsentation

    Zur Präsentation eines Programm-Prototyps sollte man einen Beamer haben, aber zur Not reicht auch ein möglichst großer Bildschirm. Wenn das Produkt stabil genug ist, sollte man auch zeitweise dem Kunden die Tastatur in die Hand geben. Graphische Elemente im Programm (z.B. auf einem Splash Screen) helfen, Programm und Präsentation ansprechender zu machen; bewegte Graphiken sind in dieser Hinsicht das Non plus ultra. Je nach Publikum und Programm könnten sogar Multimedia-Effekte (also Geräusche bzw. Musik) geeignet sein.


Zurück zu RAD-Tools
Hauptseite Weiter zum Anhang