Software-Prototyping - Wikipedia

Software-Prototyping ist das Erstellen von Prototypen von Softwareanwendungen, d. H. Unvollständigen Versionen des Softwareprogramms, das gerade entwickelt wird. Es ist eine Aktivität, die in der Softwareentwicklung auftreten kann und mit dem Prototyping vergleichbar ist, wie es aus anderen Bereichen, wie dem Maschinenbau oder der Fertigung, bekannt ist.

Ein Prototyp simuliert typischerweise nur einige Aspekte des Endprodukts und kann sich vollständig davon unterscheiden.

Prototyping bietet mehrere Vorteile: Der Softwareentwickler und -implementierer kann früh im Projekt wertvolles Feedback von den Anwendern erhalten. Der Auftraggeber und der Auftragnehmer können vergleichen, ob die erstellte Software der Softwarespezifikation entspricht, nach der das Softwareprogramm erstellt wird. Der Software-Ingenieur kann darüber hinaus Einblick in die Genauigkeit der ursprünglichen Projektschätzungen erhalten und darüber, ob die vorgeschlagenen Termine und Meilensteine ​​erfolgreich eingehalten werden können. Der Vollständigkeitsgrad und die beim Prototyping verwendeten Techniken wurden seit seinem Vorschlag in den frühen 70er Jahren entwickelt und diskutiert. ^[6]

Überblick [ edit

Der Zweck eines Prototyps besteht darin, Benutzern der Software die Möglichkeit geben, die Vorschläge der Entwickler für das Design des Produkts zu prüfen, indem sie sie tatsächlich ausprobieren, anstatt das Design anhand von Beschreibungen interpretieren und bewerten zu müssen. Software-Prototyping vermittelt ein Verständnis für die Funktionen der Software und potenzielle Bedrohungen oder Probleme. ^[1] Prototyping kann auch von Endbenutzern verwendet werden, um Anforderungen zu beschreiben und zu beweisen, die nicht berücksichtigt wurden, und dies kann ein Schlüsselfaktor in der Geschäftsbeziehung zwischen Entwicklern sein und ihre Kunden. ^[2] Insbesondere Interaction Design verwendet Prototyping zu diesem Zweck.

Dieser Prozess steht im Gegensatz zu dem monolithischen Entwicklungszyklus der 1960er und 1970er Jahre, bei dem zunächst das gesamte Programm erstellt und dann Inkonsistenzen zwischen Design und Implementierung ausgearbeitet werden, die zu höheren Softwarekosten und schlechten Zeit- und Kostenschätzungen führen. ^{Zitat benötigt} Der monolithische Ansatz wurde als "Slaying the (software) Dragon" -Technik bezeichnet, da er davon ausgeht, dass der Softwareentwickler und Entwickler ein einzelner Held ist, der den gesamten Drachen töten muss allein. Prototyping kann auch die großen Kosten und Schwierigkeiten des Wechsels eines fertigen Softwareprodukts vermeiden.

Die Praxis des Prototyping ist einer der Punkte, die Frederick P. Brooks in seinem 1975 erschienenen Buch The Mythical Man-Month und seinen 10-jährigen Jubiläumsartikel "No Silver Bullet" vorstellt.

Ein frühes Beispiel für Software-Prototyping in großem Maßstab war die Implementierung des Ada / ED-Übersetzers von NYU für die Ada-Programmiersprache. ^[3] Es wurde in SETL mit der Absicht implementiert, ein ausführbares semantisches Modell für die Ada-Sprache zu erstellen, wobei die Betonung betont wird Klarheit des Designs und der Benutzeroberfläche über Geschwindigkeit und Effizienz. Das Ada / ED-System von NYU war die erste validierte Ada-Implementierung, die am 11. April 1983 zertifiziert wurde. ^[4]

Überblick über den Prototyping-Prozess [ edit ]

Der Prototyping-Prozess umfasst das Folgende Schritte ^{Zitat erforderlich ]}

1. Grundanforderungen identifizieren
   

   Ermitteln Sie die Grundanforderungen einschließlich der gewünschten Eingabe- und Ausgabeinformationen. Details wie die Sicherheit können normalerweise ignoriert werden.



2. Entwickeln Sie einen ersten Prototyp
   

   Der erste Prototyp wird entwickelt, der nur Benutzeroberflächen enthält. (Siehe Horizontaler Prototyp unten)



3. Review
   

   Die Kunden, einschließlich der Endbenutzer, prüfen den Prototyp und geben Feedback zu möglichen Ergänzungen oder Änderungen.



4. Überarbeiten und verbessern Sie den Prototyp
   

   Mit Hilfe des Feedbacks können sowohl die Spezifikationen als auch der Prototyp verbessert werden. Möglicherweise ist eine Verhandlung darüber erforderlich, was im Vertrag / Produkt enthalten ist. Wenn Änderungen eingeführt werden, ist möglicherweise eine Wiederholung der Schritte 3 und 4 erforderlich.

Abmessungen von Prototypen [ edit ]

Nielsen fasst die verschiedenen Abmessungen von Prototypen in seinem Buch zusammen. Usability Engineering :

Horizontaler Prototyp [ edit ]

Ein gebräuchlicher Begriff für einen Benutzeroberflächenprototyp ist der horizontale Prototyp . Sie bietet einen umfassenden Überblick über ein gesamtes System oder Subsystem und konzentriert sich mehr auf die Benutzerinteraktion als auf Systemfunktionen auf niedriger Ebene, z. B. auf den Datenbankzugriff. Horizontale Prototypen sind nützlich für:

• Bestätigung der Benutzeroberflächenanforderungen und des Systemumfangs,


• Demonstrationsversion des Systems, um das Buy-In des Unternehmens zu erhalten,


• Vorläufige Schätzungen der Entwicklungszeit, der Kosten und des Aufwands erstellen.

Vertikaler Prototyp [19659005 edit ]

Ein vertikaler Prototyp ist eine erweiterte vollständige Ausarbeitung eines einzelnen Subsystems oder einer Funktion. Es ist nützlich, um detaillierte Anforderungen für eine bestimmte Funktion mit folgenden Vorteilen zu erhalten:

• Verfeinerungsdatenbankentwurf,


• Informationen über Datenvolumen und Systemschnittstellenanforderungen für die Netzwerkgröße und das Performance-Engineering erhalten


• Komplexe Anforderungen durch Drilldown bis zur tatsächlichen Systemfunktionalität abklären.

Prototyping-Typen edit ]

Software-Prototyping hat viele Varianten. Alle Methoden basieren jedoch in gewisser Weise auf zwei Hauptformen des Prototyping: dem Wegwerfprototyping und dem evolutionären Prototyping.

Throwaway-Prototyping [ edit ]

Wird auch als Prototyping mit geschlossenem Ende bezeichnet. Throwaway oder Rapid Prototyping bezieht sich auf die Erstellung eines Modells, das letztendlich verworfen wird, anstatt Teil der endgültig gelieferten Software zu werden. Nachdem die Erhebung der vorläufigen Anforderungen abgeschlossen ist, wird ein einfaches Arbeitsmodell des Systems erstellt, das den Benutzern visuell zeigt, wie ihre Anforderungen aussehen können, wenn sie in ein fertiges System implementiert werden.
Es ist auch ein schnelles Prototyping.

Beim Rapid Prototyping wird zu einem sehr frühen Zeitpunkt nach einer relativ kurzen Untersuchung ein Arbeitsmodell für verschiedene Teile des Systems erstellt. Die beim Bau verwendete Methode ist in der Regel recht informell. Der wichtigste Faktor ist die Geschwindigkeit, mit der das Modell bereitgestellt wird. Das Modell wird dann zum Ausgangspunkt, an dem Benutzer ihre Erwartungen überprüfen und ihre Anforderungen klarstellen können. Wenn dieses Ziel erreicht ist, wird das Prototypmodell weggeworfen, und das System wird formal auf der Grundlage der identifizierten Anforderungen entwickelt. ^[7]

Der offensichtlichste Grund für die Verwendung von Protokollen zum Wegwerfen ist, dass dies schnell möglich ist. Wenn die Benutzer ein schnelles Feedback zu ihren Anforderungen erhalten, können sie diese möglicherweise früh in der Entwicklung der Software verfeinern. Änderungen im frühen Entwicklungszyklus sind äußerst kosteneffektiv, da zu diesem Zeitpunkt nichts zu wiederholen ist. Wenn ein Projekt geändert wird, nachdem eine beträchtliche Menge an Arbeit erledigt wurde, können kleine Änderungen einen großen Aufwand für die Implementierung erfordern, da Softwaresysteme viele Abhängigkeiten haben. Geschwindigkeit ist für die Implementierung eines Wegwerfprototyps von entscheidender Bedeutung, da mit einem begrenzten Zeit- und Kostenaufwand wenig für einen Prototyp aufgewendet werden kann, der verworfen wird.

Eine weitere Stärke des Wegwerfprototyping ist die Fähigkeit, Schnittstellen zu erstellen, die die Benutzer testen können. Die Benutzeroberfläche ist das, was der Benutzer als das System sieht, und wenn man es vor sich sieht, ist es viel einfacher zu verstehen, wie das System funktioniert.

… Es wird behauptet, dass revolutionäres Rapid Prototyping eine effektivere Methode ist, um auf Benutzeranforderungen bezogene Probleme zu behandeln und somit die Softwareproduktivität insgesamt zu verbessern. Anforderungen können deutlich schneller und kostengünstiger identifiziert, simuliert und getestet werden, wenn Probleme mit der Entwicklungsfähigkeit, Wartbarkeit und Softwarestruktur ignoriert werden. Dies führt wiederum zu einer genauen Spezifikation der Anforderungen und dem anschließenden Aufbau eines gültigen und verwendbaren Systems aus Benutzersicht über herkömmliche Softwareentwicklungsmodelle. ^[8]

Prototypen können nach der Genauigkeit klassifiziert werden, mit der sie dem tatsächlichen Produkt in Bezug auf Aussehen, Interaktion und Timing ähneln. Ein Verfahren zum Erstellen eines Prototyps mit einem Wegwerf-Wegweiser mit geringer Genauigkeit ist das Prototyping von Papier. Der Prototyp wird mit Papier und Bleistift umgesetzt und ahmt damit die Funktion des eigentlichen Produkts nach, sieht aber überhaupt nicht danach aus. Eine weitere Methode zum einfachen Erstellen von High-Fidelity-Wegwerfprototypen besteht in der Verwendung eines GUI-Builders und dem Erstellen eines Klick-Dummy eines Prototyps, der wie das Zielsystem aussieht, jedoch keine Funktionalität bietet.

Die Verwendung von Storyboards, Animatics oder Zeichnungen ist nicht genau dasselbe wie das Wegwerfprototyping, fällt aber durchaus in die gleiche Familie. Dies sind keine funktionalen Implementierungen, zeigen jedoch, wie das System aussehen wird.

Zusammenfassung: Bei diesem Ansatz wird der Prototyp mit der Idee konstruiert, dass er verworfen wird und das endgültige System von Grund auf aufgebaut wird. Die Schritte in diesem Ansatz sind:

1. Vorläufige Anforderungen schreiben


2. Entwurf des Prototyps


3. Benutzererfahrungen / verwendet den Prototyp, legt neue Anforderungen fest


4. Wiederholen Sie den Vorgang ggf.


5. Schreiben Sie die endgültigen Anforderungen

Evolutionäres Prototyping [ edit ]

Evolutionäres Prototyping (auch bekannt als Breadboard-Prototyping) unterscheidet sich stark vom Wegwerfprototyping. Das Hauptziel beim evolutionären Prototyping ist es, einen sehr robusten Prototyp strukturiert aufzubauen und ständig zu verfeinern. Der Grund für diesen Ansatz ist, dass der evolutionäre Prototyp, wenn er gebaut wird, das Herzstück des neuen Systems bildet und die Verbesserungen und weiteren Anforderungen dann erstellt werden.

Bei der Entwicklung eines Systems mit evolutionärem Prototyping wird das System kontinuierlich verfeinert und neu aufgebaut.

"... das evolutionäre Prototyping erkennt an, dass wir nicht alle Anforderungen verstehen und baut nur diejenigen auf, die gut verstanden werden." ^[5]

Mit dieser Technik kann das Entwicklungsteam Funktionen hinzufügen oder Änderungen vornehmen, die während des Projekts nicht möglich waren Anforderungen und Designphase.

Damit ein System nützlich ist, muss es sich durch den Einsatz in der vorgesehenen Betriebsumgebung weiterentwickeln. Ein Produkt ist niemals "fertig"; Es wird immer reifer, wenn sich die Nutzungsumgebung ändert. Wir versuchen oft, ein System anhand unseres bekanntesten Bezugsrahmens zu definieren - wo wir uns gerade befinden. Wir machen Annahmen über die Art und Weise, wie das Geschäft durchgeführt wird, und die technologische Basis, auf der das Geschäft umgesetzt wird. Es wird ein Plan aufgestellt, um die Fähigkeit zu entwickeln, und früher oder später wird etwas geliefert, das dem geplanten System ähnelt. ^[9]

Evolutionäre Prototypen haben einen Vorteil gegenüber Wegwerfprototypen, da sie funktionale Systeme sind. Obwohl sie möglicherweise nicht alle von den Benutzern geplanten Funktionen aufweisen, können sie vorübergehend verwendet werden, bis das endgültige System ausgeliefert wird.

"In einer Prototyping-Umgebung ist es nicht ungewöhnlich, dass der Benutzer einen ersten Prototyp in die Praxis umsetzt, während er auf eine weiterentwickelte Version wartet. Der Benutzer kann entscheiden, dass ein" fehlerhaftes "System besser ist als überhaupt kein System." ^[7]

Beim evolutionären Prototyping können Entwickler sich darauf konzentrieren, Teile des Systems zu entwickeln, die sie verstehen, anstatt an der Entwicklung eines ganzen Systems zu arbeiten.

Um das Risiko zu minimieren, implementiert der Entwickler keine Funktionen, die nur wenig verstanden werden. Das Teilsystem wird an Kundenstandorte gesendet. Wenn Benutzer mit dem System arbeiten, erkennen sie Möglichkeiten für neue Funktionen und stellen Anforderungen an diese Funktionen an Entwickler. Die Entwickler nehmen diese Verbesserungsanforderungen dann zusammen mit ihren eigenen und verwenden solide Konfigurationsmanagementpraktiken, um die Softwareanforderungsspezifikation zu ändern, den Entwurf zu aktualisieren, neu zu codieren und erneut zu testen. ^[10]

Inkrementelles Prototyping [ edit ]

Das Endprodukt wird als separate Prototypen gebaut. Am Ende werden die einzelnen Prototypen zu einem Gesamtdesign zusammengefügt. Durch inkrementelles Prototyping wird die Zeitspanne zwischen Benutzer und Softwareentwickler verringert.

Extreme Prototyping [ edit ]

Extreme Prototyping als Entwicklungsprozess wird insbesondere für die Entwicklung von Webanwendungen verwendet. Grundsätzlich wird die Webentwicklung in drei Phasen unterteilt, von denen jede auf der vorhergehenden basiert. Die erste Phase ist ein statischer Prototyp, der hauptsächlich aus HTML-Seiten besteht. In der zweiten Phase werden die Bildschirme mithilfe einer simulierten Diensteschicht programmiert und sind voll funktionsfähig. In der dritten Phase werden die Dienste implementiert. Der Prozess wird als extremes Prototyping bezeichnet, um auf die zweite Phase des Prozesses aufmerksam zu machen, in der eine voll funktionsfähige Benutzeroberfläche entwickelt wird, die sich nur auf die Dienste bezieht, die nicht ihren Vertrag betreffen.

Vorteile des Prototypens [ edit ]

Die Verwendung von Prototyping in der Softwareentwicklung bietet viele Vorteile - einige sind greifbar, manche abstrakt. ^{[11] [1945657]}

Zeit und Kosten gesenkt : Prototyping kann die Qualität der Anforderungen und Spezifikationen verbessern, die den Entwicklern zur Verfügung gestellt werden. Da Änderungen exponentiell mehr kosten, wenn sie später in der Entwicklung erkannt werden, kann die frühzeitige Bestimmung von was der Benutzer wirklich wünscht zu einer schnelleren und kostengünstigeren Software führen. ^[8] [19659002] Verbesserte und verstärkte Einbindung der Benutzer : Prototyping erfordert die Einbindung der Benutzer und ermöglicht es ihnen, einen Prototyp zu sehen und mit diesem zu interagieren, sodass er besseres und vollständigeres Feedback und Spezifikationen liefern kann. ^[7] Das Vorhandensein des untersuchten Prototyps Der Benutzer verhindert viele Missverständnisse und Missverständnisse, die auftreten, wenn beide Seiten glauben, dass die andere Seite versteht, was sie sagen. Da die Benutzer die Problemdomäne besser kennen als jeder andere im Entwicklungsteam, kann eine verstärkte Interaktion zu einem Endprodukt führen, das eine spürbarere und immaterielle Qualität aufweist. Das Endprodukt befriedigt eher den Wunsch des Benutzers nach Aussehen, Gefühl und Leistung.

Nachteile des Prototypens [ edit ]

Die Verwendung von Prototypen oder deren Missbrauch kann auch Nachteile haben.

Unzureichende Analyse : Der Fokus auf einen begrenzten Prototyp kann Entwickler davon abhalten, das gesamte Projekt ordnungsgemäß zu analysieren. Dies kann dazu führen, dass bessere Lösungen übersehen werden, unvollständige Spezifikationen erstellt oder begrenzte Prototypen in schlecht entwickelte Endprojekte umgewandelt werden, die nur schwer zu warten sind. Da ein Prototyp in seiner Funktionalität begrenzt ist, kann er zudem nicht gut skaliert werden, wenn der Prototyp als Basis für das endgültige Ergebnis verwendet wird. Dies wird möglicherweise nicht bemerkt, wenn sich die Entwickler zu sehr darauf konzentrieren, einen Prototyp als Modell zu erstellen.

Benutzerverwirrung zwischen Prototyp und fertigem System : Benutzer können denken, dass ein Prototyp, der weggeworfen werden soll, tatsächlich ein endgültiges System ist, das lediglich fertiggestellt oder poliert werden muss. (Sie wissen beispielsweise oft nicht, welche Anstrengungen erforderlich sind, um Fehlerüberprüfungs- und Sicherheitsfunktionen hinzuzufügen, die ein Prototyp möglicherweise nicht aufweist.) Dies kann dazu führen, dass der Prototyp die Leistung des endgültigen Systems genau modelliert, wenn dies nicht der Fall ist die Absicht der Entwickler. Benutzer können auch mit Funktionen verknüpft werden, die in einem Prototyp zur Prüfung berücksichtigt wurden, und dann für ein endgültiges System aus der Spezifikation entfernt werden. Wenn die Benutzer verlangen können, dass alle vorgeschlagenen Funktionen in das endgültige System aufgenommen werden, kann dies zu Konflikten führen.

Missverständnis der Entwickler von Benutzerzielen : Entwickler können davon ausgehen, dass Benutzer ihre Ziele teilen (z. B. um die Kernfunktionalität rechtzeitig und innerhalb des Budgets bereitzustellen), ohne umfassendere kommerzielle Probleme zu verstehen. Beispielsweise wurden bei Anwendervertretern, die an Veranstaltungen der Enterprise-Software (z. B. PeopleSoft) teilnahmen, Demonstrationen der "Transaktionsüberwachung" (wo Änderungen protokolliert und in einer Differenzgitteransicht angezeigt werden) gesehen, ohne dass ihnen mitgeteilt wurde, dass diese Funktion zusätzliche Codierung erfordert und häufig mehr Hardware erforderlich ist handhabt zusätzliche Datenbankzugriffe. Benutzer glauben möglicherweise, dass sie eine Prüfung in jedem Bereich verlangen können, während Entwickler der Meinung sind, dass es sich hierbei um ein Feature handelt, da sie Annahmen über den Umfang der Benutzeranforderungen gemacht haben. Wenn der Entwickler die Bereitstellung festgelegt hat, bevor die Benutzeranforderungen überprüft wurden, befinden sich die Entwickler zwischen einem Stein und einem harten Ort, insbesondere wenn die Benutzerverwaltung einen Vorteil aus der Nichtumsetzung der Anforderungen zieht.

Anhang des Entwicklers zum Prototyp: Entwickler können sich auch an Prototypen hängen, die sie mit großem Aufwand produziert haben; Dies kann zu Problemen führen, z. B. der Versuch, einen begrenzten Prototyp in ein endgültiges System umzuwandeln, wenn ihm keine entsprechende zugrunde liegende Architektur zugrunde liegt. (Dies könnte darauf hindeuten, dass das Wegwerf-Prototyping anstelle des evolutionären Prototyping verwendet werden sollte.)

Übermäßige Entwicklungszeit des Prototyps : Eine Schlüsseleigenschaft für das Prototyping ist die Tatsache, dass dies schnell erfolgen soll. Wenn die Entwickler diese Tatsache aus den Augen verlieren, können sie sehr wohl versuchen, einen zu komplexen Prototyp zu entwickeln. Wenn der Prototyp weggeworfen wird, führen die präzise entwickelten Anforderungen möglicherweise nicht zu einer ausreichenden Produktivitätssteigerung, um die Entwicklungszeit des Prototyps auszugleichen. Benutzer können in Debatten über Details des Prototyps stecken bleiben, das Entwicklungsteam aufhalten und das Endprodukt verzögern.

Aufwand für die Implementierung von Prototyping : Die Anlaufkosten für den Aufbau eines auf Prototyping ausgerichteten Entwicklungsteams können hoch sein. Viele Unternehmen verfügen über Entwicklungsmethodiken, deren Änderung mit Umschulung, Umrüsten oder beidem verbunden sein kann. Viele Unternehmen neigen dazu, einfach mit dem Prototyping zu beginnen, ohne sich darum zu bemühen, ihre Mitarbeiter so weit wie möglich umzubilden.

Ein häufiges Problem bei der Einführung von Prototyping-Technologie sind hohe Produktivitätserwartungen bei unzureichendem Aufwand hinter der Lernkurve. Neben der Schulung für den Einsatz einer Prototyping-Technik wird häufig der Bedarf übersehen, firmen- und projektspezifische Grundstrukturen zur Unterstützung der Technologie zu entwickeln. Wenn diese zugrunde liegende Struktur weggelassen wird, kann dies häufig zu einer geringeren Produktivität führen. ^[13]

Beste Projekte zur Verwendung von Prototypen [ edit ]

Es wurde argumentiert, dass Prototyping in irgendeiner Form erfolgen sollte ständig benutzt werden. Prototyping ist jedoch am vorteilhaftesten in Systemen, die viele Interaktionen mit den Benutzern haben.

Es hat sich gezeigt, dass Prototyping bei der Analyse und beim Entwurf von Online-Systemen sehr effektiv ist, insbesondere bei der Transaktionsverarbeitung, bei der die Verwendung von Bildschirmdialogen viel offensichtlicher ist. Je größer die Interaktion zwischen dem Computer und dem Benutzer ist, desto größer ist der Vorteil, dass ein schnelles System aufgebaut werden kann und der Benutzer damit spielen kann. ^[7]

Systeme mit wenig Benutzerinteraktion, wie Stapelverarbeitung oder meistens Systeme Berechnungen nutzen, profitieren Sie wenig vom Prototyping. Manchmal ist die Codierung, die zur Ausführung der Systemfunktionen erforderlich ist, zu intensiv und die potenziellen Vorteile, die Prototyping bieten könnte, sind zu gering. ^[7]

Prototyping eignet sich besonders gut für die Gestaltung guter Mensch-Computer-Schnittstellen. "Eine der produktivsten Anwendungen des Rapid Prototyping war bisher als Werkzeug für das iterative User Requirements Engineering und das Design von Mensch-Computer-Schnittstellen." ^[8]

Dynamische Systementwicklungsmethode [ edit ] 19659033] Dynamische Systementwicklungsmethode (DSDM) ^[18] ist ein Rahmen für Business-Lösungen, der stark auf Prototyping als Kerntechnik basiert und selbst nach ISO 9001 zertifiziert ist. Es erweitert die meisten bekannten Definitionen eines Prototyps. Gemäß DSDM kann der Prototyp ein Diagramm, ein Geschäftsprozess oder sogar ein in der Produktion befindliches System sein. DSDM-Prototypen sollen inkrementell sein und sich von einfachen Formularen zu umfassenderen entwickeln.

DSDM-Prototypen können manchmal wegwerfbar oder evolutionär sein . Evolutionäre Prototypen können horizontal entwickelt werden (Breite dann Tiefe) oder vertikal (jeder Abschnitt ist detailliert aufgebaut, mit zusätzlichen Iterationen, die die nachfolgenden Abschnitte detailliert beschreiben). Evolutionäre Prototypen können sich schließlich zu endgültigen Systemen entwickeln.

Die vier von DSDM empfohlenen Prototypenkategorien sind:

• Business-Prototypen - werden verwendet, um die automatisierten Geschäftsprozesse zu entwerfen und zu demonstrieren.


• Usability-Prototypen - werden verwendet, um die Benutzerfreundlichkeit, die Zugänglichkeit, das Benutzeroberflächen-Design zu definieren, zu verfeinern und zu demonstrieren. Look and Feel.


• Leistungs- und Kapazitätsprototypen - Wird verwendet, um zu definieren, zu demonstrieren und vorherzusagen, wie Systeme unter Lastspitzen arbeiten werden, und um andere nicht funktionale Aspekte des Systems zu demonstrieren und zu bewerten (Transaktion Raten, Datenspeichervolumen, Reaktionszeit usw.)


• Fähigkeits- / Technikprototypen - zur Entwicklung, Demonstration und Bewertung eines Entwurfsansatzes oder -konzepts.

Der DSDM-Lebenszyklus eines Prototyps ist zu:

1. Prototyp identifizieren


2. Mit einem Plan einverstanden


3. Erstellen des Prototyps


4. Überprüfen des Prototyps

Prototyping für den Betrieb

Das operative Prototyping wurde von Alan vorgeschlagen Davis als eine Möglichkeit, wegwerfendes und evolutionäres Prototyping in die herkömmliche Systementwicklung zu integrieren. "Es bietet auf vernünftige Weise das Beste aus den schnellen und schmutzigen und konventionellen Entwicklungswelten. Designer entwickeln nur gut verständliche Merkmale beim Aufbau der evolutionären Basis, während sie das Wegwerf-Prototyping verwenden, um mit den wenig verstandenen Merkmalen zu experimentieren." ^[5]

Davis 'Überzeugung ist, dass der Versuch, die Qualität eines schnellen Prototyps nachzurüsten, nicht die richtige Methode ist, wenn man versucht, die beiden Ansätze zu kombinieren. Seine Idee ist es, sich an einer evolutionären Prototyping-Methodologie zu beteiligen und die Merkmale des Systems nach jeder Evolution schnell zu prototypisieren.

Die spezifische Methodik folgt diesen Schritten: ^[5]

• Ein evolutionärer Prototyp wird konstruiert und unter Verwendung herkömmlicher Entwicklungsstrategien zu einer Grundlinie gemacht, wobei nur die Anforderungen spezifiziert und implementiert werden. [19659035] Kopien der Basislinie werden zusammen mit einem ausgebildeten Prototyper an mehrere Kundenstandorte gesendet.


• An jedem Standort überwacht der Prototyper den Benutzer am System.


• Immer wenn der Benutzer auf ein Problem stößt oder an ein neues Feature oder eine neue Anforderung denkt , protokolliert der prototyper es. Dies befreit den Benutzer davon, das Problem aufzuzeichnen, und erlaubt ihm, weiterzuarbeiten.


• Nachdem die Benutzersitzung beendet ist, erstellt der Prototyper einen Prototyp für das Wegwerfen auf dem Basissystem.


• Der Benutzer verwendet nun das neue Protokoll System und bewertet. Wenn die neuen Änderungen nicht wirksam sind, werden sie vom Prototyper entfernt.


• Wenn der Benutzer die Änderungen mag, schreibt der Prototyper Funktionserweiterungsanforderungen und leitet sie an das Entwicklungsteam weiter.


• Das Entwicklungsteam mit den Änderungsanforderungen Hand an allen Standorten, dann erstellen Sie einen neuen evolutionären Prototyp mit herkömmlichen Methoden.

Offensichtlich besteht ein Schlüssel zu dieser Methode darin, gut geschulte Prototypen zur Verfügung zu haben, die zu den Anwenderseiten führen. Die Methodik für das betriebliche Prototyping bietet viele Vorteile in Systemen, die komplex sind und im Voraus nur wenige bekannte Anforderungen haben.

Evolutionäre Systementwicklung [ edit ]

Evolutionary Systems Development ist eine Klasse von Methoden, die versuchen, evolutionäres Prototyping formal zu implementieren. Ein besonderer Typ, genannt Systemscraft, wird von John Crinnion in seinem Buch Evolutionary Systems Development beschrieben.

Systemscraft wurde als "Prototyp" -Methodik entwickelt, die modifiziert und an die spezifische Umgebung angepasst werden sollte, in der sie implementiert wurde.

Systemscraft wurde nicht als starrer "Kochbuch" -Ansatz für den Entwicklungsprozess konzipiert. Es ist heute allgemein anerkannt [sic]dass eine gute Methodik flexibel genug sein sollte, um an alle Arten von Umgebung und Situation angepasst werden zu können. ^[7]

Die Grundlage von Systemscraft ist, ähnlich wie beim evolutionären Prototyping, die Schaffung eines funktionierenden Systems von Anfang an Anforderungen und bauen in einer Reihe von Überarbeitungen darauf auf. Systemscraft legt großen Wert auf traditionelle Analyse, die während der gesamten Systementwicklung verwendet wird.

Evolutionäre rasante Entwicklung [ edit ]

Evolutionary Rapid Development (ERD) ^[12] wurde vom Software Productivity Consortium, einem Technologieentwicklungs- und Integrationsagent für das Information Technology Office von, entwickelt der Defense Advanced Research Projects Agency (DARPA).

Grundlegend für ERD ist das Konzept des Zusammenstellens von Softwaresystemen, das auf der Wiederverwendung von Komponenten, der Verwendung von Softwarevorlagen und einer Architekturvorlage basiert. Die ständige Weiterentwicklung der Systemfunktionen als schnelle Reaktion auf sich ändernde Benutzeranforderungen und Technologien wird durch die evolvable Architektur hervorgehoben, die eine Klasse von Lösungen darstellt. Der Prozess konzentriert sich auf den Einsatz von kleinen, handwerklichen Teams, die Software- und Systementwicklungsdisziplinen integrieren, wobei mehrere, häufig parallele, Timeboxen mit kurzer Dauer und häufiger Interaktion mit dem Kunden zusammenarbeiten.

Schlüssel zum Erfolg des ERD-basierten Systems Projekte sind parallele explorative Analyse und Entwicklung von Funktionen, Infrastrukturen und Komponenten mit und Übernahme von Spitzentechnologien, die eine schnelle Reaktion auf Änderungen in den Technologien, auf dem Markt oder auf Kundenanforderungen ermöglichen. ^[9]

Kunden- / Benutzereingaben, häufig geplant und Es finden ad hoc / spontane Treffen mit den Stakeholdern statt. Demonstrationen der Systemfähigkeiten werden abgehalten, um Feedback einzuholen, bevor die Entscheidungen über Design / Implementierung gefestigt werden. Häufige Releases (z. B. Betas) werden zur Verfügung gestellt, um Einsicht zu gewinnen, wie das System die Anforderungen von Benutzern und Kunden besser unterstützen kann. Dies stellt sicher, dass sich das System entwickelt, um vorhandene Benutzeranforderungen zu erfüllen.

Das Design-Framework für das System basiert auf der Verwendung vorhandener oder de facto geltender Standards. Das System ist so organisiert, dass eine Reihe von Funktionen entwickelt werden kann, die Überlegungen zu Leistung, Kapazitäten und Funktionalität enthalten. Die Architektur wird in Form abstrakter Schnittstellen definiert, die die Dienste und ihre Implementierung (z. B. COTS-Anwendungen) einkapseln. Die Architektur dient als Vorlage, um die Entwicklung von mehr als einer einzelnen Instanz des Systems zu steuern. Damit können mehrere Anwendungskomponenten zur Implementierung der Dienste verwendet werden. Ein Kernsatz von Funktionen, die sich wahrscheinlich nicht ändern werden, wird ebenfalls identifiziert und festgelegt.

Der ERD-Prozess ist so strukturiert, dass er anstelle von Papierprodukten nachgewiesene Funktionalität verwendet, um den Interessengruppen die Möglichkeit zu geben, ihre Bedürfnisse und Erwartungen zu kommunizieren. Zentral für dieses Ziel der schnellen Lieferung ist die Verwendung der "Timebox" -Methode. Zeitfenster sind feste Zeiträume, in denen bestimmte Aufgaben (z. B. Entwicklung eines Satzes von Funktionen) ausgeführt werden müssen. Anstatt Zeit zu lassen, um einige vage Ziele zu erreichen, wird die Zeit festgelegt (sowohl in Kalenderwochen als auch in Stundenstunden), und es wird eine Reihe von Zielen definiert, die innerhalb dieser Beschränkungen realistisch erreicht werden können. Um zu verhindern, dass sich die Entwicklung in einen zufälligen Gang verwandelt, werden langfristige Pläne definiert, um die Iterationen zu leiten. Diese Pläne bieten eine Vision für das Gesamtsystem und setzen Grenzen (z. B. Einschränkungen) für das Projekt. Jede Iteration innerhalb des Prozesses wird im Kontext dieser langfristigen Pläne durchgeführt.

Sobald eine Architektur eingerichtet ist, wird Software täglich integriert und getestet. Dadurch kann das Team den Fortschritt objektiv bewerten und mögliche Probleme schnell erkennen. Da kleine Mengen des Systems gleichzeitig integriert werden, ist die Diagnose und Beseitigung des Fehlers schnell. Benutzerdemonstrationen können kurzfristig abgehalten werden, da das System im Allgemeinen jederzeit einsatzbereit ist.

Um Prototypen effizient einsetzen zu können, muss ein Unternehmen über die richtigen Werkzeuge verfügen und über ein Personal verfügen, das für die Verwendung dieser Werkzeuge geschult ist. Werkzeuge, die beim Prototyping verwendet werden, können von einzelnen Tools variieren, z. B. von Programmiersprachen der vierten Generation, die für das schnelle Prototyping verwendet werden, bis hin zu komplexen integrierten CASE-Tools. Visuelle Programmiersprachen der vierten Generation wie Visual Basic und ColdFusion werden häufig verwendet, da sie billig, bekannt und relativ einfach und schnell zu bedienen sind. CASE-Tools, die die Anforderungsanalyse unterstützen, wie die Requirements Engineering-Umgebung (siehe unten), werden häufig vom Militär oder von großen Organisationen entwickelt oder ausgewählt. Objektorientierte Werkzeuge werden ebenso wie LYMB aus dem GE Research and Development Center entwickelt. Benutzer können in einer Kalkulationstabelle Elemente einer Anwendung selbst prototypisieren.

Mit der zunehmenden Beliebtheit von webbasierten Anwendungen verfügen auch die Werkzeuge zum Prototyping solcher Anwendungen. Frameworks wie Bootstrap, Foundation und AngularJS stellen die Werkzeuge bereit, um ein Proof-of-Concept schnell zu strukturieren. Diese Frameworks bestehen normalerweise aus einer Reihe von Steuerelementen, Interaktionen und Entwurfsrichtlinien, mit denen Entwickler Webanwendungen schnell prototypisieren können.

Bildschirmgeneratoren, Entwurfswerkzeuge und Softwarefabriken [ edit ]

Auch Bildschirmgenerierungsprogramme werden häufig verwendet und ermöglichen Prototypen das Anzeigen von Benutzersystemen, die nicht funktionieren Die Bildschirme können wie folgt aussehen. ^[5] Die Entwicklung von Human Computer Interfaces kann manchmal der kritische Teil des Entwicklungsaufwands sein, da für die Benutzer die Schnittstelle im Wesentlichen das System ist.

Softwarefabriken können Code erzeugen, indem sie betriebsbereite modulare Komponenten kombinieren. Dies macht sie ideal für Prototyping-Anwendungen, da mit diesem Ansatz Programme mit dem gewünschten Verhalten schnell und mit minimalem manuellen Codieraufwand bereitgestellt werden können.

Application definition or simulation software[edit]

A new class of software called Application definition or simulation software enables users to rapidly build lightweight, animated simulations of another computer program, without writing code. Application simulation software allows both technical and non-technical users to experience, test, collaborate and validate the simulated program, and provides reports such as annotations, screenshot and schematics. As a solution specification technique, Application Simulation falls between low-risk, but limited, text or drawing-based mock-ups (or wireframes) sometimes called paper-based prototypingand time-consuming, high-risk code-based prototypes, allowing software professionals to validate requirements and design choices early on, before development begins. In doing so, the risks and costs associated with software implementations can be dramatically reduced.^[6]

To simulate applications one can also use software that simulates real-world software programs for computer-based training, demonstration, and customer support, such as screencasting software as those areas are closely related. There are also more specialised tools.^[7][8][9]

Requirements Engineering Environment[edit]

"The Requirements Engineering Environment (REE), under development at Rome Laboratory since 1985, provides an integrated toolset for rapidly representing, building, and executing models of critical aspects of complex systems."^[15]

Requirements Engineering Environment is currently used by the United States Air Force to develop systems. It is:

an integrated set of tools that allows systems analysts to rapidly build functional, user interface, and performance prototype models of system components. These modeling activities are performed to gain a greater understanding of complex systems and lessen the impact that inaccurate requirement specifications have on cost and scheduling during the system development process. Models can be constructed easily, and at varying levels of abstraction or granularity, depending on the specific behavioral aspects of the model being exercised.^[15]

REE is composed of three parts. The first, called proto is a CASE tool specifically designed to support rapid prototyping. The second part is called the Rapid Interface Prototyping System or RIP, which is a collection of tools that facilitate the creation of user interfaces. The third part of REE is a user interface to RIP and proto that is graphical and intended to be easy to use.

Rome Laboratory, the developer of REE, intended that to support their internal requirements gathering methodology. Their method has three main parts:

• Elicitation from various sources (users, interfaces to other systems), specification, and consistency checking


• Analysis that the needs of diverse users taken together do not conflict and are technically and economically feasible


• Validation that requirements so derived are an accurate reflection of user needs.^[15]

In 1996, Rome Labs contracted Software Productivity Solutions (SPS) to further enhance REE to create "a commercial quality REE that supports requirements specification, simulation, user interface prototyping, mapping of requirements to hardware architectures, and code generation…"^[16] This system is named the Advanced Requirements Engineering Workstation or AREW.

LYMB[edit]

LYMB^[17] is an object-oriented development environment aimed at developing applications that require combining graphics-based user interfaces, visualization, and rapid prototyping.

Non-relational environments[edit]

Non-relational definition of data (e.g. using Caché or associative models) can help make end-user prototyping more productive by delaying or avoiding the need to normalize data at every iteration of a simulation. This may yield earlier/greater clarity of business requirements, though it does not specifically confirm that requirements are technically and economically feasible in the target production system.

PSDL[edit]

PSDL is a prototype description language to describe real-time software.^[10]
The associated tool set is CAPS (Computer Aided Prototyping System).^[11]
Prototyping software systems with hard real-time requirements is challenging because timing constraints introduce implementation and hardware dependencies.
PSDL addresses these issues by introducing control abstractions that include declarative timing constraints. CAPS uses this information to automatically generate code and associated real-time schedules, monitor timing constraints during prototype execution, and simulate execution in proportional real time relative to a set of parameterized hardware models. It also provides default assumptions that enable execution of incomplete prototype descriptions, integrates prototype construction with a software reuse repository for rapidly realizing efficient implementations, and provides support for rapid evolution of requirements and designs.^[12]

See also[edit]

1. ^ C. Melissa Mcclendon, Larry Regot, Gerri Akers: The Analysis and Prototyping of Effective Graphical User Interfaces. October 1996. [3]


2. ^ D.A. Stacy, professor, University of Guelph. Guelph, Ontario. Lecture notes on Rapid Prototyping. August, 1997. [4]


3. ^ Stephen J. Andriole: Information System Design Principles for the 90s: Getting it Right. AFCEA International Press, Fairfax, Virginia. 1990. Page 13.


4. ^ R. Charette, Software Engineering Risk Analysis and Management. McGraw Hill, New York, 1989.


5. ^ Alan M. Davis: Operational Prototyping: A new Development Approach. IEEE Software, September 1992. Page 71.


6. ^ Todd Grimm: The Human Condition: A Justification for Rapid Prototyping. Time Compression Technologies, vol. 3 nein 3. Accelerated Technologies, Inc. May 1998 . Page 1. [5]


7. ^ John Crinnion: Evolutionary Systems Development, a practical guide to the use of prototyping within a structured systems methodology. Plenum Press, New York, 1991. Page 18.


8. ^ S. P. Overmyer: Revolutionary vs. Evolutionary Rapid Prototyping: Balancing Software Productivity and HCI Design Concerns. Center of Excellence in Command, Control, Communications and Intelligence (C3I), George Mason University, 4400 University Drive, Fairfax, Virginia.


9. ^ Software Productivity Consortium: Evolutionary Rapid Development. SPC document SPC-97057-CMC, version 01.00.04, June 1997. Herndon, Va. Page 6.


10. ^ Davis. Page 72-73. Citing: E. Bersoff and A. Davis, Impacts of Life Cycle Models of Software Configuration Management. Comm. ACM, Aug. 1991, pp. 104–118


11. ^ Adapted from C. Melissa Mcclendon, Larry Regot, Gerri Akers.


12. ^ Adapted from Software Productivity Consortium. PPS 10–13.


13. ^ Joseph E. Urban: Software Prototyping and Requirements Engineering. Rome Laboratory, Rome, NY.


14. ^ Paul W. Parry. Rapid Software Prototyping. Sheffield Hallam University, Sheffield, UK. [6]


15. ^ Dr. Ramon Acosta, Carla Burns, William Rzepka, and James Sidoran. Applying Rapid Prototyping Techniques in the Requirements Engineering Environment. IEEE, 1994. [7]


16. ^ Software Productivity Solutions, Incorporated. Advanced Requirements Engineering Workstation (AREW). 1996. [8]


17. ^ from GE Research and Development. https://web.archive.org/web/20061013220422/http://www.crd.ge.com/esl/cgsp/fact_sheet/objorien/index.html


18. ^ Dynamic Systems Development Method Consortium. https://web.archive.org/web/20060209072841/http://na.dsdm.org/


19. ^ Alan Dix, Janet Finlay, Gregory D. Abowd, Russell Beale; Human-Computer Interaction, Third edition

References[edit]

1. ^ "Software Prototyping - INGSOFTWARE". www.ingsoftware.com. Retrieved 2018-06-27.
   


2. ^ Smith MF Software Prototyping: Adoption, Practice and Management. McGraw-Hill, London (1991).
   


3. ^ Dewar, Robert B. K.; Fisher Jr., Gerald A.; Schonberg, Edmond; Froelich, Robert; Bryant, Stephen; Goss, Clinton F.; Burke, Michael (November 1980). "The NYU Ada Translator and Interpreter". ACM SIGPLAN Notices – Proceedings of the ACM-SIGPLAN Symposium on the Ada Programming Language. 15 (11): 194–201. doi:10.1145/948632.948659. ISBN 0-89791-030-3.
   


4. ^ SofTech Inc., Waltham, MA (1983-04-11). "Ada Compiler Validation Summary Report: NYU Ada/ED, Version 19.7 V-001". Retrieved 2010-12-16.CS1 maint: Multiple names: authors list (link)
   


5. ^ [1] List of common UI prototyping tools
   


6. ^ How Simulation Software Can Streamline Application Development Archived 2012-07-22 at Archive.today
   


7. ^ [2] Archived September 19, 2009, at the Wayback Machine
   


8. ^ Top 10 Simulation Tools for UI Designers, Information Architects and Usability Specialists
   


9. ^ Visio Replacement ? You Be the Judge Archived 2006-12-19 at the Wayback Machine
   


10. ^ Luqi; Berzins, Yeh (October 1988). "A Prototyping Language for Real-Time Software". IEEE Transactions on Software Engineering. 14 (10): 1409–1423. doi:10.1109/32.6186.
    


11. ^ Luqi; Ketabchi (March 1988). "A Computer-Aided Prototyping System". IEEE Software. 5 (2): 66–72. doi:10.1109/52.2013.
    


12. ^ Luqi (May 1989). "Software Evolution through Rapid Prototyping". IEEE Computer. 22 (5): 13–25. doi:10.1109/2.27953.