Eine Software-Entwicklung ist dann gelungen, wenn sie Programme hervorbringt, die den Anforderungen entsprechen. Technische Zutaten, wie eine klare Architektur oder sprechender Code, sind notwendig, aber nicht hinreichend für den Erfolg. Der Prozess der Software-Entwicklung muss sicherstellen, dass auch die gewünschte Software hergestellt wird.

Abb. 1: Phasen der Software-Entwicklung.

Tipp 1: Ist ein Vorgehensmodell vorgeschrieben oder wird es üblicherweise verwendet, so nutzen Sie es. Gibt es keine Vorgaben, vereinbaren Sie zu Beginn der Entwicklung ein Vorgehensmodell. Tipp 2: Beziehen Sie die Fachabteilung in den Entwicklungsprozess durch regelmäßige Status-Meetings ein. Kommunizieren Sie die bislang gewonnenen Ergebnisse. Stellen Sie alle Informationen in Beziehung zu den Anforderungen. Tipp 3: Obwohl die entscheidenden Informationen von der Fachabteilung beigesteuert werden, ist die Unterstützung von technischer Seite in einer möglichst frühen Projektphase sinnvoll, damit auch technisch relevante Informationen erarbeitet werden. Tipp 4: Verwenden Sie möglichst Standardkomponenten. Durch Erfahrungswerte ist es möglich, im Voraus zu beurteilen, ob die Anforderungen erfüllbar sind. Tipp 5: Wenn ein Entwicklungsprojekt aus technischen Gründen abgebrochen werden muss, so ist der Abschluss der Machbarkeitsstudie der geeignete Zeitpunkt. Tipp 6: Verwenden Sie zur Beschreibung der Datenverarbeitung UML-Diagramme. Sie sind leicht verständlich und stellen eine hervorragende Diskussionsgrundlage dar. Tipp 7: Mit Ausnahme der Implementierungs-Vorschrift sollte auch das technische Konzept allgemein verständlich sein. Insbesondere sollte der Auftraggeber in der Lage sein, das technische Konzept gegen die Anforderungen zu prüfen. Abb. 2: Tipps zur Software-Entwicklung.

Teil I: Java-Objekte in der Identitätskrise Teil II: Konfiguration der IDE Teil III: Typisch Ant Teil IV: Ausnahmen sind die Regel Teil V: Das kleine 1x1 der Software-Entwicklung

Phasen der Software-Entwicklung

Die Erstellung einer Software beginnt mit der Idee und endet mit der Lieferung des Produkts. Dieser Prozess kann in mehrere Phasen aufgeteilt werden. So genannte Vorgehensmodelle definieren die Aufgaben und Reihenfolgen solcher Phasen. Abbildung 1 zeigt ein schlankes Vorgehensmodell. Siehe hierzu auch Tipp 1 in Abbildung 2.

Bei diesem Vorgehensmodell handelt es sich um ein klassisches Wasserfall-Modell: Nachdem eine Phase wie beispielsweise das Grobkonzept abgeschlossen ist, fängt die nächste Phase, hier die Machbarkeitsstudie an. In der Realität gibt es Wechselwirkungen zwischen den Phasen, die durch rückwärtsgerichtete Pfeile dargestellt sind (siehe Abbildung 1). Erkenntnisse, die in einer Phase gewonnen werden, können sich auf Aspekte einer Vorgängerphase auswirken.

Wird beispielsweise in der Machbarkeitsstudie herausgefunden, dass eine komplexe Datenverarbeitung bei der geforderten Transaktionsrate nicht realisierbar ist, so ist zu prüfen, ob diese Art der Verarbeitung für die Software unabdingbar ist.

Wechselwirkungen dieser Art müssen die Ausnahme bleiben. Veränderungen an den Ergebnissen der vorangegangenen Phasen stellen die Grundlagen für die Folgephasen in Frage! Siehe hierzu auch Tipp 2 in Abbildung 2.

Grobkonzept

Im Grobkonzept wird die Zielsetzung der Software definiert. Beachten Sie hierzu auch Tipp 3 (siehe Abbildung 2).

Folgende Fragen sind in dieser Phase zu beantworten:

• Was sind die wesentlichen, was die weniger wichtigen Ziele der Software?
• Welche Anwendungsfälle werden von der Software unterstützt?
• Welche Schnittstellen gibt es zu Partnersystemen?
• Wie wird die Software bedient? Wer muss sie benutzen?

Darüber hinaus wird es weitere Fragestellungen geben, die von der Art der Software abhängen. Für eine Server-Anwendung sind oftmals folgende Fragen zu klären:

• Welcher Datendurchsatz muss von der Software verarbeitet werden?
• Welche Datenmengen sind von der Software zu verwalten?

Das Ergebnis dieser Phase ist ein Dokument, das von Anforderungs- und Entwicklungsseite akzeptiert werden muss.

Machbarkeitsstudie

Die zentralen Fragen der Machbarkeitsstudie sind: Mit welchen technischen Mitteln und Methoden ist die Software zu erstellen? Gibt es Zweifel, ob die Anforderungen erfüllbar sind?

Beispiel: Bei einer Client-Server-Anwendung werden Bilder übermittelt. Der Benutzer soll in der Lage sein, ein Bild pro Sekunde auszuwählen. Es wird mit bis zu 50 gleichzeitigen Benutzern gerechnet. Nun stellt sich die Frage, ob beide Anforderungen erfüllt werden können.

Die Machbarkeitsstudie identifiziert technisch kritische Anforderungen und prüft, ob diese mit vertretbarem Aufwand erfüllbar sind. Für Server-Systeme sind für diese Bewertung beispielsweise folgende Informationen wichtig:

• In welcher Form werden die Schnittstellen zu Partnersystemen angebunden? Als Web-Service, mit Hilfe einer Message Queue oder über Remote-Method-Invocation?
• Wie groß ist der zu erwartende Datenstrom über die Schnittstellen?
• Wie viele Transaktionen pro Sekunde werden von der Anwendung gefordert?
• Wie viele parallele Anfragen gibt es an das System?
• Welche Antwortzeiten sind gefordert?

Diesen technischen Anforderungen ist ein technisches Architekturkonzept gegenüberzustellen. Bestehen Zweifel an der Erfüllbarkeit von technischen Forderungen, muss ein Prototyp implementiert werden, um die Frage zu klären. Siehe Tipp 4 in Abbildung 2.

Neben der technischen Realisierbarkeit dürfen folgende Fragen nicht vernachlässigt werden (Siehe hierzu auch Tipp 5 in Abbildung 2):

• Wie hoch sind die zu erwartenden Realisierungskosten und -zeiten?
• Welche Hardware-Kosten entstehen?
• Welche Risiken können durch den Prototypen nicht behoben werden?

Fachkonzeption

Das Fachkonzept beinhaltet alle fachlichen Informationen, die für den Prozess der Datenverarbeitung erforderlich sind. Dieses Konzept wird – genauso wie die spätere Entwicklung – durch Anwendungsfälle strukturiert. Beschrieben wird, welcher Vorgang durch die Software wie unterstützt wird. Das Buchen einer Reiseveranstaltung könnte so ein Anwendungsfall sein. Das Drucken der Rechnung ein zweiter, das Stornieren ein dritter usw. Anwendungsfälle können in Textform beschrieben werden (Siehe hierzu auch Tipp 6 in Abbildung 2).

• Wer löst den Anwendungsfall aus?
• Welche Voraussetzungen gibt es?
• Welche Daten werden wie verarbeitet?
• Welcher Zustand ist nach dem Anwendungsfall erreicht?

Außer den Anwendungsfällen ist Folgendes zusätzlich zu erarbeiten:

• Spezifikation der Systemschnittstellen
• Ein Domain-Modell, das die fachlichen Objekte (Kunde, Auftrag, Bestellung) mit ihren Attributen identifiziert
• Ein fachliches Datenmodell

Die Datenmenge, die in den Phasen der Fachkonzeption und der DV-Konzeption gesammelt werden, ist enorm. Die Strukturierung dieser Informationen stellt eine Herausforderung dar. Bei kleineren Projekten wird es ausreichen, ein UML-Werkzeug einzusetzen, um die Anwendungsfälle aufzunehmen und die zugehörigen Aktivitäts- und Zustandsdiagramme unterzuordnen. In das Textdokument werden die Diagramme eingebettet und beschrieben.

Definition der Software-Architektur

Die Definition der Software-Architektur ist an dieser Stelle sinnvoll, um eine Arbeitshypothese für die DV-Konzeption zu haben. Es sind in dieser Phase bereits die wesentlichen Komponenten zu definieren und ihr Gebrauch durch technische Konzepte festzuhalten. Durch diese Vorgaben ist erst eine sinnvolle Beschreibung im DV-Konzept möglich. Ein typisches Beispiel ist der interne Anwendungsfall, dass ein Domain-Objekt in der Datenbank abzulegen ist. Wenn im technischen Konzept geklärt ist, auf welche Weise Domain-Objekte abgelegt werden, so reduziert sich die Beschreibung dieses Vorgangs im DV-Konzept darauf: "Das Objekt XYZ ist, wie im technischen Konzept Persistenz beschrieben, zu speichern".

Das Ziel muss es sein, für alle technischen Vorgänge technische Konzepte zu entwickeln, wie die Übernahme der Daten aus der Schnittstelle, Art der Validierung, Objekte laden, ändern und speichern. Diese beschreiben den Gebrauch der zugrunde liegenden Komponenten an zentraler Stelle und stellen so eine Funktionalität zur Verfügung, die im Fachkonzept bereits verwendet wird. Die Beschreibung der technischen Konzepte hat zwei Seiten: Eine Anleitung für die Implementierung und eine Beschreibung der Vorgänge, die mit Hilfe dieses Konzepts ausgeführt werden können. Siehe hierzu auch Tipp 7 in Abbildung 2.

Während der DV-Konzeptionsphase werden gewiss Ergänzungen zur Software-Architektur notwendig sein, so dass diese beiden Phasen nicht einfach zu trennen sind.

DV-Konzeption

Die DV-Konzeption überführt die fachlichen Anwendungsfälle in technische Anwendungsfälle. Dabei lassen sich äußere und interne Anwendungsfälle unterscheiden. Äußere Anwendungsfälle sind einem fachlichen Anwendungsfall zugeordnet. Diese Zuordnung stellt eine wichtige Information in der Dokumentation dar. Die Beschreibung des äußeren Anwendungsfalls muss bereits alle technischen Aspekte berücksichtigen.

Beispiel: Äußerer Anwendungsfall "Reservierung bestätigen". Voraussetzung für diesen Anwendungsfall ist, dass ein Reservierungsdatensatz in der Datenbank abgelegt ist. Dieses wiederum setzt den Datenabgleich des Reservierungssystems mit dem Buchungssystem voraus.

Interne Anwendungsfälle erfüllen eine abgeschlossene Aufgabe. Durch ihre Parametrisierung sind sie oft in mehreren äußeren Anwendungsfällen zu verwenden. Sie verwenden die Funktionalitäten der technischen Konzepte, um ihre Aufgabe zu erfüllen. Vorsicht! Technische Konzepte haben ihre Grenzen. Beispielsweise sind Massendaten nicht sinnvoll mit einem objekt-relationalen-Mapping zu verarbeiten: Hier helfen SQL-Statements oder DB-Prozeduren aus der Performance-Klemme. Die Beurteilung, welches technische Konzept sinnvoll in einem Anwendungsfall eingesetzt werden kann, erfordert technische und fachliche Kenntnisse.

Die Beschreibung des DV-Konzepts muss vollständig sein: Einerseits stellt es die (manchmal einzige) Informationsquelle der Entwicklung dar. Andererseits verhindert die Vollständigkeit, dass der Anwendungsfall "und hier passiert ein Wunder" von den Entwicklern umzusetzen ist. Neben der technischen Spezifikation der Anwendungsfälle gibt es weitere Ergebnisse dieser Phase. Bei einer Server-Entwicklung müssen beispielsweise eine technische Datenbankmodellierung sowie die technische Spezifikation der Domain-Objekte entwickelt werden.

Entwicklung

In dieser Phase werden die technischen Konzepte und die Anwendungsfälle umgesetzt. Folgende Regeln können nützlich sein:

• Die Arbeitspakete sollten anhand der Anwendungsfälle ausgeführt werden: So kann der Fertigstellungsgrad der Software über die Anzahl der realisierten Anwendungsfälle angegeben werden.
• Risikoreiche Anwendungsfälle sollten als erstes realisiert werden.
• Es sollte kein Code entwickelt werden, der noch nicht gebraucht wird: Häufig wird der Code nämlich überhaupt nicht gebraucht.
• Verweise in der Programmdokumentation auf das DV-Konzept und die technischen Konzepte sollten nicht fehlen.
• Modultests sind für selbstentwickelte Komponenten und für die implementierte Geschäftslogik zu erstellen. Auf einen kombinierten Test kann i. A. verzichtet werden.
• Was nicht auf Modulebene getestet werden kann, sollte nicht implementiert werden: Fehler, die erst beim Systemtest zu Tage treten, sind sehr aufwändig zu konfigurieren.

Test

Die Testphase besteht aus der Testkonzeption und der Durchführung dieser Tests. Getestet wird die Gesamtfunktionalität, es handelt sich also um Systemtests. Die Testkonzeption kann und sollte parallel zur Entwicklung ausgeführt werden. Durch das Fachkonzept liegen die fachlichen Informationen vor, was getestet werden soll. Aus dem DV-Konzept ist direkt ersichtlich, über welche Schnittstellen der Test möglich ist. Hilfreich ist die Synchronisierung von Entwicklung und Tests. Sind Anwendungsfälle implementiert, so sollten diese zeitnah systemgetestet werden. Fehler werden so schneller gefunden, Folgefehler werden vermieden. Optimal ist es, wenn auch die Systemtests automatisiert werden. So kann der Zustand der Software auf Knopfdruck überprüft werden.

Abnahme

Die Abnahme ist eine Aktivität des Kunden. Oftmals wird vereinbart, dass die Entwicklung diese Phase unterstützen soll. Die enge Kooperation hilft beim Umgang (Installation, Konfiguration) mit der neuen Software. Eigenschaften der Software lassen sich von Fehlern unterscheiden, auftretende Fehler gemeinsam klassifizieren und deren Behebung vereinbaren.

Und danach?

Nach der erfolgreichen Abnahme ist die Entwicklung häufig noch nicht abgeschlossen. Es schließen sich oft Phasen der Fehlerbehebung sowie der Wartung (Concession Clearing) oder einer Weiterentwicklung an. Für die Fehlerbehebung und die Wartung ist ein Trouble-Ticket-System sinnvoll, damit Fehler oder Anforderungen nicht vergessen werden. Eine Weiterentwicklung sollte erneut in den dargestellten Phasen durchgeführt werden.

Fazit

Das vorgestellte Prozessmodell hilft, die fachlichen Anforderungen der Software nicht aus den Augen zu verlieren. Darüber hinaus wird es damit möglich, den Projektfortschritt einfacher zu beurteilen. Gemäß unserem Leitmotiv "Best-Practice" unterstützen wir Sie gern in allen Phasen Ihres Projekts.

Dr. Stefan Koch (info@ordix.de).