-
Notifications
You must be signed in to change notification settings - Fork 39
Phase 1: Vision und Konzept
- Gruppengröße: mindestens 3 Personen
In dieser Phase wird die Basis für ein Produkt/ Service/ Dienst entwickelt oder weiterentwickelt, eine Recherche des Marktes sowie des Standes von Wissenschaft und Technik durchgeführt, und ein Konzept soweit definiert und dokumentiert, dass in einem nachfolgenden Projekt ein Entwicklerteam in der Lage ist, ein MVP zu realisieren oder zu erweitern.
Eine hilfreiche Leitfrage ist hier: was braucht das Entwicklerteam, um möglichst effizient und zielführend arbeiten zu können?
Am Ende der Phase sollten die wesentlichen W-Fragen möglichst umfassend beantwortet werden. Die Dokumentation sollte idealerweise in einem offenen Format vorliegen, damit das nachfolgende Team an dieser Stelle die Dokumentation fortführen kann. Dies gilt auch für die erstellten Artefakte. Alle Dokumente müssen am Ende der Phase abgegeben werden, entweder via sciebo, oder noch besser in einem Git Repository.
Hier ein paar exemplarische Leitfragen für die erste Phase. Diese Liste ist sicher nicht vollständig, bzw. für verschiedene Vorhaben könnte diese Liste unterschiedlich aussehen.
Was ist das übergeordnete Ziel des Vorhabens und wie macht das Produkt/ der Service die Welt besser? Dies sollte im Vision Statement in maximal fünf Sätzen kurz und prägnant erläutert werden.
Wer ist in das Vorhaben involviert und warum? Wer ist Nutzer? Wer ist Betreiber? Welche Rollen gibt es?
Gibt es Vorgängerprojekte? Gibt es ähnliche/vergleichbare Projekte? Fusst das Projekt auf einer neuen Entwicklung oder Strömung? Was gibt es an Literatur, konzeptionellen Bausteinen, technischen Ansätzen, Frameworks, Services, etc. die kennen sollte, wenn man sich mit dem Vorhaben beschäftigt oder die auf das Vorhaben einzahlen.
Welche konkreten Anforderungen müssen erfüllt werden und wie sind diese priorisiert? Welche Abläufe und Strukturen muss das spätere System abbilden und warum?
In der nächsten Phase soll ein Minimal Viable Product entwickelt werden. Was muss dieses MVP abbilden, damit es lebensfähig ist. Welche weiteren Ausbaustufen wären sinnvoll und wie differenzieren sich dieses Ausbaustufen?
Wie sind die wesentlichen Abläufe gestaltet? Auf welchen Geräten soll das System laufen und warum? Wie soll die Architektur ausgestaltet sein? Wie könnten alternative Architekturen und Abläufe aussehen? Falls es eine Benutzerschnittstelle gibt, wie ist diese gestaltet?
Wie muss ein Team aussehen, dass in der Lage ist, das MVP zu realisieren? Welche Rollen und Kompetenzen sind erforderlich? Welche Kapazitäten werden benötigt? Welche, über Manpower hinaus gehenden, Ressourcen werden benötigt?
Gibt es eine Organisations- oder Arbeitsstruktur für die nächste Phase? Welche Arbeitspakete gibt es? Falls eine agile Vorgehensweise geplant ist, welche User-Stories, Epics und Themes gibt es?
Wie sehen Betriebs- und Finanzierungsmodelle für das spätere System aus? Was ist überhaupt nötig, um das System nachhaltig betreiben zu können? Gibt es ein kritische Masse von Nutzern, die erreicht werden muss?
Art und Umfang der Artefakte können von Projekt zu Projekt stark variieren. Anbei ein paar typische Artefakte mit den dahinter stehenden Fragen. Bitte denken Sie daran, dass die Artefakte auch als offene Dateien abgegeben werden, damit diese weiterentwickelt werden können.
Das Konzeptpapier enthält alle relevanten Informationen zum Projekt und dem aktuellen Stand: was ist die Idee? Wer ist die Zielgruppe? Welches Problem löst das Produkt/ der Service? In welchen Kontext wird das Produkt/ der Service entwickelt? Welchen Aufgaben müssen bearbeitet und welche Probleme gelöst werden?
Die Modellierungen helfen dem Entwicklerteam bestimmte Sachverhalte, Abläufe und Eigenschaften des Systems in einer übersichtlichen, abstrahierten und häufig standardisierten Form zu verstehen: wie sehen die Stakeholder aus? Welche Abläufe soll das System abbilden? Wie ist die Architektur des Systems geplant? Wie sieht ein etwaiges Daten- oder Contentmodell aus? Aus welchen Komponenten besteht das System? Welche 3rd-Party Dienste oder Services werden benötigt und wie sind diese mit dem eigenen System verbunden?
Das Design Mockup zeigt, wie eine etwaige Benutzerschnittstelle ausgestaltet ist.
Die Machbarkeitsstudie beweist, dass es sich hier um ein realistisches Vorhaben handelt. Die notwendigen Ressourcen werden quantifiziert, etwaige technische Fragestellungen werden exemplarisch gelöst, der Entwicklungs- und Betriebsaufwand wird realistisch geschätzt.
Die Kurzpräsentation sollte auf maximal neun Slides das Vorhaben prägnant und verständlich darlegen. Die Slides müssen nicht selbsterklärend sein. Die Präsentationszeit sollte maximal fünf Minuten sein.
Mit Hilfe der Langpräsentation sollte das Vorhaben möglichst präzise und umfassend dargestellt werden können. Die Präsentation sollte maximal 20 Minuten in Anspruch nehmen.
Die Prozessdokumentation dokumentiert auf maximal zehn Seiten das Vorgehen und die Entwicklungsschritte der ersten Projektphase. Das Dokument muss nicht in einem offenen Format vorliegen.
Die Schwerpunktperspektive dokumentiert auf maximal zwei Seiten die besonderen Herausforderungen des Vorhabens bezogen auf den eigenen Schwerpunkt. Sollten mehrere Studierende eines Schwerpunkts am Vorhaben mitwirken, sollten sie eine gemeinschaftliche Schwerpunktperspektive vorlegen.
Über die persönliche Rolle wird auf maximal einer Seite, die jeweilige Rolle des einzelnen Studierenden und sein/ihr Einfluss auf das Vorhaben dokumentiert.