Software gemeinsam mit dem Kunden zu entwickeln kann nicht sonderlich schwer sein. Der Kunden schreibt auf, welche Funktionen er benötigt und wenn es möglich ist, schreibt er auch die Ziele dazu, die er mit der Software verfolgt. Der Software-Entwickler plant die Software aus technischer Sicht unter Beachtung der Infrastruktur des Kunden. Die Software wird entwickelt, getestet und in Betrieb genommen und alle sind glücklich.

Leider ist das in dieser Form nicht möglich. Individuelle Software-Entwicklung funktioniert anders. Oft werden die Stimmen laut, dass die Erstellung von IT-Systemen funktionieren muss, wie das Bauen eines Hauses oder das Kaufen eines Autos. Dem ist aber nicht so. Wenn heute ein Autokäufer zu Mercedes geht und ein fünftes Rad an zentraler Stelle wünscht, wird er wieder weggeschickt. Softwareunternehmen bauen im annähernd jedem Projekt ein fünftes Rad.

Um so wichtiger ist es, eine Anwendung gemeinsam mit dem Kunden zu durchdenken und zu konzeptionieren. Dabei ist es wichtig, das Unternehmen, das die Software entwickelt, früh hinzuzuziehen. Ebenso sind die Endanwender in der Konzeptionsphase ein wichtiges Instrument, um zu erkennen, welche Funktionen in welcher Form notwendig sind.

Es gibt eine Handvoll wichtiger Werkzeuge (Aufgaben) mit denen Konzeption betrieben werden kann.

Durchführung von Workshops

Nach der Einarbeitung in das Thema führt ein externer Consultant bei Kunden Workshops durch. Um dies effizient zu gestalten, erarbeitet der Dienstleister einen Fragenkatalog mit den offenen Punkten, die noch zu klären sind. Kann der Fragenkatalog nicht erstellt werden, kann kein Workshop durchgeführt werden.

Erstellung eines Grobkonzeptes

Das Dokument beinhaltet alle Kernfunktionen des zu erstellenden Systems und beschreibt die Ziele, die damit verfolgt werden. Weiterhin gilt es als Sammel-Pool für alle zusätzlichen Anforderungen des Kunden. Ein grobes Konzept beinhaltet keine Use-Cases oder andere normierte Elemente. Es besteht zum Großteil aus Fließtext, Aufzählungen und Skizzen. Aus der technischen Betrachtung heraus sollte das Grobkonzept den technischen Rahmen bereits kennen. Darunter ist sowohl die zukünftige Infrastruktur als auch die Software-Umgebung wie Programmiersprachen, Schnittstellen und andere Dienste gemeint.

Review des Grobkonzeptes

Im Review wird die Vollständigkeit des erstellten Dokuments geprüft. Offene Punkte werden dokumentiert und gegebenenfalls wird eine neue Fassung des Konzeptes erarbeitet.

Feinkonzeption einer Anwendung

Auf der Basis dieser Vorarbeiten, die nicht zwingend aufwendig sind, aber immer durchgeführt werden müssen, kann man (am besten gemeinsam mit dem Kunden) die Feinkonzeption beginnen. Die Consultants sollten dabei immer die erste Fassung schreiben. Dieses Vorgehen hat mehrere Gründe. Erstens hat der Kunde weniger Zeit, aus diesem Grund wurden Externe hinzugezogen. Zweitens ist es ein weiterer Prüfstein. Denn wenn der Consultant das System verstanden hat und hierzu ein Konzept erstellen kann, ist die Wahrscheinlichkeit, dass das die Software-Entwickler können, deutlich höher.

Das Feinkonzept enthält:

  • eine funktionale Beschreibung der Funktionen und Prozesse inklusive der Datenbewegungen und -speicherungen
  • eine Ausarbeitung aller Use-Cases (Anwendungsfälle) für das System, auch wenn Use-Cases nicht alles sind.
  • eine vollständige Beschreibung der Benutzeroberfläche der Applikation, am besten als Wireframe/Mockup, um hier Fehleinschätzungen zu vermeiden.
  • Eine detaillierte Definition und Beschreibung aller eingehenden und ausgehenden Schnittstellen zu Fremdsystemen bzw. zur Infrastruktur
  • einen Gesamtprojektplan mit Meilensteinen und Sollbruchstellen
  • ein Technikkonzept, das den Software-Entwickler in die Lage versetzt, das System zu planen und umzusetzen.

Nach dem Abschluss der Feinkonzeption kann der Kunde erwarten, dass der in den Dokumenten beschriebene Teil in bester Qualität und ohne große Missverständnisse entwickelt werden kann.

Dabei gilt zu beachten, dass die Größe des beschriebenen Systems ein sehr großer Erfolgsfaktor ist. Je kleiner die einzelnen Teilprojekte sind, desto größer ist der direkte Erfolg und desto geringer sind die Nacharbeiten und Change Requests. Die Aufteilung in einzelne funktionale Projekte ist, sofern dies möglich ist, zu empfehlen.