Schnell mal eben gebastelt:
Rapid Prototyping in der Softwareentwicklung

(Software-)Prototypen bieten eine gute Möglichkeit Ideen und Lösungsansätze schnell und effizient zu testen. Aber was sollte man dabei zu beachten?

Im Rahmen der (Weiter-)Entwicklung einer Software ist es nichts Neues oder Ungewöhnliches Prototypen einer Anwendung oder der – ggf. zu verbessernden – Teilfunktion(en) zu erstellen. Während in der eher traditionellen Softwareentwicklung häufig sogenannte Minimum Viable Product(s) (MVP) entstehen, kommt dem Rapid Prototyping in der agilen Softwareentwicklung – häufig im Rahmen des sogenannten Design Thinking – eine besondere Bedeutung zu:

Im Unterschied zu einem MVP, das häufig gegen Ende einer Konzept- oder Anforderungsanalysephase und mit teils doch recht hohen Entwicklungsaufwänden ensteht, soll ein Rapid Prototyp mit möglichst geringem Entwicklungsaufwand und auch bereits möglichst frühzeitig erstellt werden. Häufig werden für einzelne Ideen dedizierte Prototypen gebaut oder spezielle Lösungsansätze werden mithilfe von Prototypen validiert – um das so erhaltene Feedback frühestmöglich bei der Projektplanung zu berücksichtigen.

Häufig werden die Prototypen gemeinsam mit Mockups oder Wireframes verwendet um die Gesamtarchitektur einer Lösung zu visualisieren. Im Unterschied dazu, sollen Protypen es Teammitgliedern oder ausgewählten Testnutzern gestatten typische Anwendungsfälle auszuprobieren oder eingesetzte Technologien (z.B. auf Performance) konkret zu bewerten.

Was ist jedoch beim Einsatz von Rapid Prototyping zusätzlich zu beachten?

Keep it simple!

Wie schon erwähnt, soll ein Prototyp meist einen ganz bestimmten Ansatz oder eine Idee abbilden. Schnell passiert es jedoch, dass man sich z.B. aufgrund der verwendeten Technologien – oder aus dem Wunsch heraus einmal investierte Zeit sinnvoll weiterverwenden zu können – im Detail verliert oder unnötig komplizierte Architekturen implementiert. Wenn es die (Gesamt-)Anwendungsarchitektur zulässt modulare Feature-Prototypen zu erstellen, optimal. Falls nicht, bleiben Sie fokussiert und konzentrieren Sie sich auf die eigentliche Grundidee! Was ist der minimale Funktionsumfang der nötig ist um den aktuellen Ansatz testen zu können?

Es sollte darauf geachtet werden, dass die Frage-/ Aufgabenstellung realistisch ist bzw. so weit heruntergebrochen werden kann, dass sie mit einem einfachen Prototypen abgebildet werden kann. Während einfache Datenkonvertierungen und Statusübergänge u.U. noch abbildbar sind, macht es wenig Sinn zu versuchen komplette Workflows in einem einzelnen Prototypen abzubilden.

Low-Code?

Ein Artikel zum Thema Rapid Prototyping aus dem letzten Jahr legt u.a. einen der Schwerpunkte auf Low-Code-Plattformen. Es wird beschrieben, dass die Einsatzmöglichkeit von Low-Coding-Systemen u.a. von Ansatz, Funktionsumfang, Zielgruppe und der Bereitschaft der Mitarbeiter abhängt, sich mit der Erstellung von Applikationen zu beschäftigen.

Grundsätzlich möchte ich dieser Aussage nicht wiederprechen, finde jedoch, dass man an dieser Stelle zwischen „Prototypen zur Gestaltung von (Geschäfts-)Prozessen“ und „echten Anwendungsprototypen“ unterscheiden sollte: Ich glaube durchaus, dass man Prototypen z.B. für die Modellierung von Prozessen innerhalb integrierter Geschäftsanwendungen per Low-Code-Verfahren erstellen kann. Für „native“ Software hängt dies stark von den verwendeten Technologien ab – und führt fast immer dazu, dass zumindest im geringfügigen Umfang Programmierung notwendig ist.

Häufig kann man sich das Leben durch den gezielten und bewussten Einsatz von (Software-)Artefakten, Bibliotheken und Paket-Managern erleichtern. Im .net-Umfeld ist Nuget der wohl populärste Paket-Manager. Der Vorteil: Einmal für regelmäßig auftretende Anforderungen erstellte und standardisierte Bibliotheken können gepackt, über ein zentrales Repository verteilt und in zukünftigen Anwendungen wiederverwendet werden. Nicht wirklich Low-Code, ermöglicht es aber eine starke Vereinfachung und Beschleunigung beim Erstellen von Anwendungsprototypen.

Eine Bibliothek mit häufig in meinen Projekten eingesetzten Basis-Klassen und -Implementierungen sind zu finden bei Nuget mit Beispielcodes gehostet auf Github.

Team und Tools

Es liegt in der Natur der Idee, dass sich in einem agilen und interaktiven Arbeitsprozess (Software-)Versionen und Spezifikationen schnell und regelmäßig ändern. Damit ist es nicht nur wichtig, dass alle Team-Mitglieder Zugang zu den für sie relevanten Informationen erhalten, sondern auch regelmäßig auf den aktuellen Stand gebracht werden. In diesem Zusammenhang ist es meist vorteilhaft eine Person zu benennen, die sich gezielt um die Vorbereitung und Strukturierung der Informationen sowie ggf. die Leitung von Sitzungen und Besprechungen kümmert.

Für externe Anwendungen, Bibliothekten und Tools sollte sichergestellt sein, dass alle Team-Mitglieder – soweit notwendig – ausreichende Kenntnisse besitzen. Falls dies (z.B. aufgrund von Kosten, Zeitplänen oder Qualifikation) nicht möglich ist, macht es häufig auch Sinn externe Spezialisten hinzuzuiehen.

Zeit- und Projektmanagement

Aus technologischer Sicht, erhält man mithilfe des Rapid Prototyping-Ansatzes schnell eine erste Testversion. Man sollte jedoch nicht nur darauf achten sich vorab die notwendige Zeit zu nehmen um konkrete und klare Anforderungen zu entwickeln, sondern:

  • Den Testnutzern – sofern vorhanden – ausreichend Zeit einräumen sich auch mit dem Prototypen auseinanderzusetzen
  • Feedback, z.B. durch Interviews, einholt und strukturiert
  • Regelmäßig eine (Neu-)Bewertung durchführt.

Ein Artikel aus dem Jahr 2018 stellt zudem eine schöne Liste typischer Fallstricke im Rahmen eines Prototyp-basierten Projekts dar.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.