Der Entwicklungsprozess bei FORMFAKTEN

Konzeption. Idealerweise beraten wir die Kunden bereits in dieser Konzeptphase. Wir extrahieren aus diesen Informationen ein erstes Dokument, das Vorläufige Requirements-Dokument, das bis zu diesem Zeitpunkt bekannte Anforderungen enthält.

In der Analysephase setzen wir uns mit dem Kunden zusammen und besprechen die wichtigsten Nutzungsszenarien des Produkts. Diese nennen sich auch User Stories. Daraus entsteht eine Reihe von Dokumenten, die wir im Folgenden skizzieren wollen:

Wir erstellen aus der Niederschrift dieser Szenarien sogenannte Use Case Dokumente. Das sind formalisierte Dokumente, die die gesamte Funktionalität des Produkts umfassen.

Auf Basis dieser Dokumente wird aus dem vorläufigen Requirements Dokument das Requirements Dokument.

Test. Das Requirements Dokument gibt Klarheit darüber, was das Produkt können soll. Aber wie lässt sich feststellen, ob das Produkt tatsächlich kann, was vereinbart worden ist? Darüber gibt der Testplan Auskunft. Das Produkt gilt als entwickelt wie bestellt, wenn der Testplan erfolgreich durchlaufen wurde. Daher wird der Testplan noch einmal mit dem Kunden besprochen. Neben automatisierbaren Tests (Unit Tests), die die Entwickler laufend schreiben und erweitern, werden auf Basis des Testplans Integrationstests durchgeführt. Diese Testszenarien entsprechen weitgehend den Nutzungsszenarien.

Risikoanalyse. Ebenfalls in der Analysephase entsteht ein Dokument über die möglichen technischen Risiken eines Projekts. Die darin genannten Punkte müssen in der Entwicklung zuerst geklärt werden, da sie erfahrungsgemäß die meiste Zeit in Anspruch nehmen.

Machbarkeit. In der Feasibility Phase wird die Machbarkeit der Anforderungen überprüft. Die in der Risikoanalyse festgestellten Risiken werden hier genauer betrachtet. Darüber hinaus entsteht in dieser Phase die Architektur des Produkts. Es wird festgelegt, welche Technologien letztlich verwendet werden.

Prototyping. In der Prototypen-Phase entstehen ein oder mehrere Prototypen (MockUps). Prototypen sind geeignet, die Nutzung des Systems zu demonstrieren und einen ersten Eindruck vom Look-and-Feel der Anwendung zu bekommen. Je nach Anforderung arbeiten wir mit Wireframes, die zur Veranschaulichung des Bedienungsflusses der Applikation dienen. Hier kann auch eine vereinfachte Realisierung bestimmte Use Cases demonstrieren. In dieser Phase werden viele Entscheidungen getroffen, die das Design der Software bestimmen. Damit nachvollziehbar ist, wie die Software funktioniert, werden in dieser Phase nach Bedarf Designdokumente erstellt.

In der Implementierungsphase wird am konkreten Code  der Anwendung gearbeitet. Der Code wird mit einem Versionsmanagement-System verwaltet, so dass jederzeit alle Zwischenstände des Codes abgerufen werden können. Codeänderungen werden mit Task-Ids versehen, so dass eine lückenlose Verfolgbarkeit von Anforderungen in den Code entsteht. Es können mehrere Implementierungsschritte geplant werden. Dies ist dann sinnvoll, wenn das Projekt sehr umfangreich ist.

Änderungen. Im laufenden Prozess ergeben sich unserer Erfahrung nach stets Änderungen, sei es, dass manche Anforderungen erst klar werden, wenn Teile der Software bereits entwickelt wurden oder manche Programmteile die Prozesse nicht akurat abbilden. Nachträgliche Änderungen können auch durch unvorhergesehene technische Probleme entstehen. Das kann zum Beispiel dann passieren, wenn eine Leistung, die von Dritten zur Verfügung gestellt wird, nicht so funktioniert, wie sie funktionieren sollte. Je kleiner die Schritte eines einzelnen Releases sind, desto schneller können solche Entwicklungen aufgefangen werden. Änderungen der Anforderungen sind ein selbtsverständlicher Bestandteil der Softwareentwicklung, haben aber Einfluss auf Budget und Zeitplan.

Entscheidungsmatrix. Projekte haben einen Zeitplan und ein Budget, das in der Anfangsphase des Projekts festgelegt wird. Bei unvorhergesehenen Änderungen im Ablauf des Projekts müssen Entscheidungen über den Termin, das Budget und die Ressourcen getroffen werden. Es hat sich als sinnvoll erwiesen, die Tendenz solcher Entscheidungen für einige typische Szenarien bereits bei Projektbeginn zu vereinbaren.

Nachvollziehbarkeit. Um sicherzustellen, dass ein Produkt genau das tut, was beabsichtigt war, gibt es das Konzept der Traceability. Das heißt, dass alles, was in einem Projekt passiert, auf eine dokumentierte Anforderung zurückführbar ist. Im Entwicklungsprozess komplexer Projekte können Fehler passieren. Leider. Diese Fehler werden im Zuge der Integrationstests über ein Ticketsystem erfasst. Auf diese Weise bleibt kein Fehler unbearbeitet. Die Fehlerbehebung führt zu Änderungen im Code und in den Tests. Diese Änderungen können auf das Fehlerticket zurückgeführt werden.

Die Entwicklung selbst wird dokumentiert. Jeder Softwareteil erhält neben dem Code auch die Dokumentation, um jederzeit nachvollziehen zu können, welche Anforderungen implementiert wurde. Wie viel dokumentiert wird, hängt vom konkreten Projekt ab. Die Dokumentation kann vom Kunden in unterschiedlichem Umfang bestellt werden.