Nicht mit Erfindungen, sondern mit Verbesserungen macht man Vermögen.
– Henry Ford

10 Software-Engineering

Unter dem Oberbegriff Software-Engineering (auf Deutsch manchmal auch Softwaretechnik genannt) werden sämtliche Arbeitsschritte der professionellen Softwareentwicklung zusammengefasst. Die in den beiden vorigen Kapiteln behandelte Programmierung ist dabei nur eine Teilaufgabe (wenn auch die wichtigste).

Softwareentwicklung als Ingenieurskunst?

Die Bezeichnung »Engineering« legt nahe, dass hier die in über hundert Jahren gesammelte Erfahrung der Ingenieurswissenschaften auf die Erstellung von Software angewendet werden soll. In gewisser Weise arbeitet ein Softwareentwickler tatsächlich wie ein Produktingenieur: Anders als der Hacker oder Geek, für den der Rechner und die Programme Selbstzweck sind, muss er Anwendungen schreiben, die Gegenstände und Sachverhalte aus der realen Welt abbilden und verarbeiten; diese werden in der Regel von Benutzern eingesetzt, die keine IT-Profis sind.

Der heutige Stand des Software-Engineerings ist eine langfristige Konsequenz aus Überlegungen zur Überwindung der sogenannten Softwarekrise: Mitte der 60er-Jahre des vorigen Jahrhunderts überstiegen die Entwicklungskosten für Software immer häufiger die Anschaffungskosten der Hardware (obwohl Letztere gigantisch waren). Als Grund wurde vor allem erkannt, dass die Methoden der Programmierung nicht mit der exponentiellen Weiterentwicklung der Hardware Schritt halten konnten. Auf den Punkt gebracht wurde dies 1972 von Edsger Dijkstra: »As long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now that we have gigantic computers, programming has become an equally gigantic problem.« [Übersetzung: »Als es noch keine Maschinen gab, war Programmierung überhaupt kein Problem; als wir ein paar schwache Computer hatten, wurde die Programmierung zu einem kleinen Problem, und nun, da wir gigantische Computer haben, ist die Programmierung zu einem ebenso gigantischen Problem geworden.« ]

Objektorientierung

Als Ausweg aus diesen eher pessimistischen Überlegungen wurden vor allem die seit den 1970er-Jahren entwickelten Verfahren der Objektorientierung gesehen. Letztlich entstammen die meisten modernen Entwicklungsmodelle dem Denkansatz der Objektorientierung, die hier nicht nur auf die reine Programmierung, sondern auf den gesamten Entwicklungsprozess angewendet wird: Ein beliebtes Softwareentwicklungsverfahren besteht etwa aus Objektorientierter Analyse (OOA), Objektorientiertem Design (OOD) und schließlich Objektorientierter Programmierung (OOP). Viele Entwickler, die das moderne Software-Engineering geprägt haben, stammen aus dem Umfeld der ersten objektorientierten Sprache Smalltalk.

Gerade für praxistaugliche Anwendungssoftware liegt der objektorientierte Ansatz nahe, weil sich Elemente der realen Welt auf diese Weise besonders »naturgetreu« in Computerprogrammen darstellen lassen (Näheres dazu in den Java- und Ruby-Abschnitten von Kapitel 8, Grundlagen der Programmierung).

In diesem Kapitel werden die Grundzüge des Software-Engineerings erläutert. Es besteht aus zwei Teilen:

Der Abschnitt Überblick stellt die verschiedenen Phasen des Entwicklungsprozesses vor. Außerdem erhalten Sie einen kurzen Überblick über zwei beliebte – und ziemlich unterschiedliche – Modelle der Softwareentwicklung: den Unified Process und Extreme Programming (XP).

Im Abschnitt Werkzeuge werden wichtige Helfer für das Software-Engineering beschrieben: die Diagrammspezifikation UML (Unified Modeling Language), der Einsatz von Entwurfsmustern und die Testautomatisierung durch Unit-Tests.

Wenn Sie die Ausbildung zum Fachinformatiker absolvieren – in welcher der beiden Fachrichtungen, spielt keine Rolle – sind die Informationen in diesem Kapitel auch von praktischem Interesse für Sie: Ihre Abschlussprojektarbeit ist so umfangreich, dass Sie sich keinesfalls mit der (in der Praxis leider verbreiteten) Methode »Erst Code runterhacken, dann Konzept und Dokumentation daraus entwickeln« abplagen sollten! Abgesehen davon müssen Sie bereits vor Projektbeginn eine Vorstufe des Konzepts bei der IHK einreichen und genehmigen lassen – insofern ist zumindest der Beginn der hier vorgestellten Reihenfolge ohnehin bindend für Sie.

10.1 Überblick

Im Folgenden wird zunächst der Gesamtablauf des Entwicklungsprozesses beschrieben, anschließend werden die einzelnen Phasen näher beleuchtet. Soweit möglich, geschieht dies ohne Beschränkung auf ein bestimmtes Entwicklungsmodell. Hier geht es eher darum, die allgemeinen Anforderungen des Entwicklungsprozesses darzustellen; konkrete Lösungen durch bestimmte Modelle lernen Sie weiter unten kennen.

10.1.1 Der Entwicklungszyklus

Bis zu einem gewissen Grad funktioniert die Entwicklung von Software immer gleich. Es spielt keine Rolle, ob einer oder hundert Programmierer daran arbeiten und ob es sich um ein Zehn-Zeilen-Skript oder ein umfassendes Anwendungspaket handelt: Immer besteht der Prozess mindestens aus den Schritten Entwurf – Implementierung – Test. Sie bestimmen also zuerst die Aufgaben des Programms und wie sie erfüllt werden sollen, fassen diese in Anweisungen und Ausdrücke der Sprache Ihrer Wahl und überprüfen zum Schluss, ob das Programm wie erwartet funktioniert.

Projektphasen

In größeren Projekten, an denen mehrere Entwickler arbeiten, lassen sich die folgenden Projektphasen unterscheiden:

Planung. Klärung der Projektvorgaben und Zusammenfassung in einem Lasten- beziehungsweise Pflichtenheft. An dieser Stelle beginnt auch die Arbeit des Projektmanagements, die über den gesamten Projektverlauf weitergeführt werden muss.

Analyse. Genaue Untersuchung des Projektgegenstandes. Die Geschäftsprozesse, Elemente und Daten, für die die geplante Software zuständig sein soll, müssen möglichst genau definiert und verstanden werden.

Entwurf. Entwicklung eines Modells für die gewünschte Implementierung. Dies ist die unmittelbare Arbeitsvorlage für die Programmierer, weil auf diese Weise auch einheitliche Schnittstellen und andere gemeinsame Konventionen definiert werden.

Implementierung. Schreiben des eigentlichen Programmcodes

Test. Überprüfung auf technische Korrektheit, auf Erfüllung der Vorgaben sowie auf Benutzbarkeit durch die Zielgruppe. Je nachdem, welches Ziel wie stark verfehlt wurde, erfolgt der Rücksprung in eine frühere Entwicklungsphase.

Dokumentation. Erstellung von Informationen oder Handbüchern für Entwickler (zur Weiterentwicklung der Software), Administratoren (für die Installation, Konfiguration und Anpassung) sowie Endanwender (Erläuterung der Programmfunktionen).

Es gibt zwei grundlegende Möglichkeiten, diese Phasen zu durchlaufen: linear oder iterativ. Bei der linearen Entwicklungsreihenfolge – beispielsweise dem klassischen Wasserfallmodell – ist die Idealvorstellung, jeden der Schritte nacheinander in sich abzuschließen, um am Ende ein fertiges Produkt zu besitzen. Bei den moderneren iterativen Entwicklungsverfahren werden diese Phasen dagegen mehrfach durchlaufen. Jeder Durchlauf erweitert und vervollständigt das Produkt – man spricht auch von einem Spiralmodell. Die sogenannten agilen Entwicklungsverfahren wie etwa Extreme Programming (siehe unten) versuchen, die einzelnen Durchläufe so kurz wie möglich zu halten. Auf diese Weise wird häufig ein »fertiges« Produkt veröffentlicht, und Änderungswünsche lassen sich beinahe jederzeit berücksichtigen.

Beachten Sie, dass sich Projekte in der Praxis oft nicht an die klare zeitliche Abfolge der genannten Phasen halten können. Einige Aufgaben werden von unterschiedlichen Teammitgliedern ausgeführt, andere sollten den gesamten Entwicklungsprozess umfassen und begleiten. Beispielsweise ist es weltfremd und gefährlich, erst nach Fertigstellung eines ganzen Programmpakets oder -bestandteils mit dem Testen zu beginnen: Wenn Sie erst in dieser späten Phase merken, dass ein elementares Projektziel verfehlt wurde, gefährden (oder zerstören) Sie das gesamte Projekt. Den extremsten Schluss aus diesem Problem zieht das Test-Driven Development (testgetriebene Entwicklung): Hier wird zuerst ein Test geschrieben und erst danach der Programmcode, der diesen Test erfüllt.

10.1.2 Planung und Analyse

In der Planungsphase stellt der Entwickler oder Projektverantwortliche sich zunächst die Frage, welchen Zweck die zu entwickelnde Software erfüllen soll. Bei Auftragsarbeiten natürlich in Zusammenarbeit mit dem (potenziellen) Kunden. Diese Grundanforderung wird zu einem Katalog von Leistungen ausgearbeitet, die die künftige Software erbringen soll. Durch das Hinzufügen von Details geht die Planung fließend in die wesentlich exaktere Analyse über.

Kleine Projekte

Bei kleinen Skripten erfolgen Planung und Analyse oft während des »Hackens«. Bereits ab etwa 100 Zeilen Programmcode sollten Sie den Plan aber in irgendeiner Form schriftlich fixieren. Bei überschaubaren Kleinprojekten genügt eine einfache Textdatei mit Notizen, die Sie später durch Kopieren und Einfügen als Kommentare in Ihr Programm aufnehmen können.

Sobald auch nur eine weitere Person an dem Projekt mitarbeitet, wird diese Empfehlung zur Pflicht. Die Fehleranfälligkeit durch mangelnde Absprachen ist beträchtlich und wächst exponentiell mit der Teamgröße. Der Mindeststandard für die Zusammenarbeit sind daher Absprachen über einen bestimmten Kommentarstil.

Bedenken Sie, dass die schriftliche Fixierung aller Informationen ab dem Projektbeginn unter anderem die Grundlage für eine benutzbare Dokumentation ist.

Projektmanagement

Bereits zu Beginn der Planungsphase sollte die wichtige Tätigkeit des Projektmanagements aufgenommen werden. Diese Koordinations- und Kontrollaufgabe muss während des gesamten Projektablaufs kontinuierlich durchgeführt werden, um Projektziele, Zeit und Ressourcen im Griff zu behalten und gegebenenfalls rechtzeitig gegenzusteuern, bevor es zu Problemen kommt.

Projektmanagement (PM) ist natürlich nicht auf Softwareprojekte beschränkt, sondern wirkt im Grunde überall, wo Menschen gemeinsam Aufgaben lösen. Es handelt sich um einen Sammelbegriff für alle organisatorischen Maßnahmen, die ein Projekt zum Erfolg führen sollen. Laut DIN-Norm 69901 ist Projektmanagement die »Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die Abwicklung eines Projektes«.

Wissensfelder des Projektmanagements

Die Aufgaben des Projektmanagements lassen sich in neun sogenannte Wissensfelder unterteilen, Tabelle 10.1 zeigt eine Übersicht.

**Tabelle 10.1** Die neun Wissensfelder des Projektmanagements
Integrationsmanagement	Umfangsmanagement	Zeitmanagement
Kostenmanagement	Qualitätsmanagement	Personalmanagement
Kommunikationsmanagement	Risikomanagement	Beschaffungsmanagement

Im Einzelnen lassen sich die Aufgaben der verschiedenen Wissensfelder etwa folgendermaßen zusammenfassen:

Das Integrationsmanagement kümmert sich um die Koordination der verschiedenen Projektbestandteile und -beteiligten.

Beim Umfangsmanagement (Scope Management) geht es um die Überwachung des Projektzustands in Bezug auf die Ziele und Vorgaben. Gelegentlich wird auch erst während des Projektablaufs die Notwendigkeit einer Zieländerung erkannt.

Das Zeitmanagement achtet auf die Einhaltung des Projektzeitplans. Eine praktische Technik, um Aufgaben in eine zeitliche Beziehung zueinander zu setzen, ist beispielsweise der weiter unten angesprochene Netzplan.

Das Kostenmanagement muss durch ständige Kontrolle und eventuell geeignete Kostendämpfungsmaßnahmen dafür sorgen, dass sich die Projektkosten im Rahmen des Budgets halten.

Durch Qualitätsmanagement soll sichergestellt werden, dass alle Elemente und Teilergebnisse des Projekts einem bestimmten Standard genügen. Dazu wird unter anderem die ausführliche Dokumentation aller Projektphasen benötigt.

Das Ressourcenmanagement verteilt die vorhandenen Arbeitsmittel und Teammitglieder möglichst effizient auf die verschiedenen Projektteile und -phasen.

Ohne ein funktionierendes Kommunikationsmanagement kann ein Projekt leicht scheitern. Es ist immer zu bedenken, dass Projekte über Abteilungs- und Hierarchiegrenzen hinweg bearbeitet werden. Wer bei der Kommunikation im Projektteam starre Dienstwege einhalten möchte, gefährdet das Projekt, weil es auf diese Weise gar kein »Team« gibt. Auch die Kommunikationsmittel und -standards selbst sollten bereits in der Planungsphase festgelegt werden, um spätere Missverständnisse auszuschließen.

Das Risikomanagement umfasst einerseits eine möglichst weitsichtige Notfallplanung, andererseits muss beim konkreten Ausfall von Arbeitsmitteln oder Teammitgliedern flexibel reagiert werden.

Das Beschaffungsmanagement muss Kapazitäten, Nachbestellungen und Lieferzeiten von Arbeitsmitteln so koordinieren, dass möglichst keine Verzögerungen durch das Warten auf Nachschub entstehen.

Beispiel Netzplan

Ein gutes Beispiel für die Tätigkeit des Projektmanagements ist das Erstellen von Netzplänen, die der Zeitplanung und -koordination dienen. Im Netzplan kann übersichtlich dargestellt werden, in welcher Reihenfolge die einzelnen Schritte eines Projekts durchgeführt werden und welche von ihnen einander bedingen.

Als Beispiel zur Erstellung eines Netzplans soll die folgende kurze Liste dienen, die einige Tätigkeiten zur Erstellung einer kleinen, statischen Firmen-Website mit Zeitangaben in Tagen auflistet. Die optionalen Angaben A und B beziehen sich auf die beiden Mitglieder eines Zweierteams mit unterschiedlichen Kernkompetenzen; bei Aufgaben, die jeder der beiden ausführen könnte, wurden sie weggelassen:

Inhaltliche Planung (1 Tag)

A, B: Entwurf (1 Tag)

A: Schreiben der Textinhalte (2 Tage)

B: Erstellen von Grafiken und Bildern (3 Tage)

A: Erstellen des HTML-Codes (2 Tage)

Test und Fehlerkorrekturen (1 Tag)

Buchung von Webspace mit Domain bei einem Hoster (3 Tage) – da der Namenswunsch sich erst aus dem Konzept ergibt, kann dies frühestens nach Abschluss des Entwurfs stattfinden.

Veröffentlichung (1 Tag)

Hier klicken, um das Bild zu vergrößern

Abbildung 10.1 Netzplandarstellung eines kleinen Website-Projekts

Abbildung 10.1 zeigt den Netzplan für dieses Projekt. Vorgänge wurden soweit wie möglich parallelisiert, um die Projektdauer kurz zu halten. Jeder Vorgang wird auf einer »Karte« [Es kann praktisch sein, die einzelnen Vorgänge tatsächlich auf kleine Karten zu schreiben. So können Sie sie zunächst frei verschieben, um verschiedene Optionen zu testen. ] nach folgendem Schema notiert:

+------------------------+ 
|  Vorgangsname/-nummer  | 
+---+----------------+---+ 
|FAZ|     Dauer      |FEZ| 
+---+      des       +---+ 
|SAZ|    Vorgangs    |SEZ| 
+---+----------------+---+

Oben steht der Name und praktischerweise auch eine eindeutige Nummer des jeweiligen Vorgangs. In der Mitte wird die Dauer des Vorgangs in einer für alle Karten identischen Zeiteinheit notiert – je nach Projektumfang zum Beispiel in Stunden, Tagen oder Monaten. Die vier Felder links und rechts neben der Dauer werden erst ausgefüllt, wenn die Reihenfolge feststeht. Hier werden (relativ zum Projektstart 0) die folgenden Zeitpunkte eingetragen: frühester Anfangszeitpunkt (FAZ), spätester Anfangszeitpunkt (SAZ), frühester Endzeitpunkt (FEZ) sowie spätester Endzeitpunkt (SEZ).

Vorgänge, bei denen FAZ und SAZ sowie FEZ und SEZ jeweils identisch sind, liegen auf dem sogenannten kritischen Pfad (Critical Path). Eine Verzögerung dieses Vorgangs hat unweigerlich zur Folge, dass auch das Gesamtprojekt länger dauert. In der Abbildung wurde der kritische Pfad durch dickere Pfeillinien markiert.

Die Hauptkritik am Netzplan ist, dass die tatsächliche Dauer der Abläufe nicht grafisch dargestellt wird. Für Fälle, in denen dies erforderlich ist, gibt es aber noch zahlreiche andere Darstellungsformen für zeitliche Abläufe. Ein Beispiel ist das Gantt-Diagramm, das die einzelnen Abläufe durch Balken symbolisiert, deren Länge ihre Dauer kennzeichnen.

Analyseverfahren

Um einen detaillierten Plan über Umfang, Voraussetzungen, Dauer und Kosten eines Projekts erstellen zu können, muss zunächst genau untersucht werden, welches Problem das Projekt lösen soll, auf welche Weise dies geschehen soll und welche Mittel dazu erforderlich sind. Solche Untersuchungen werden mit dem Oberbegriff Analyse bezeichnet. Die wichtigsten Formen der Analyse sind die folgenden:

Die Systemanalyse untersucht ein System mithilfe eines Modells. In der Softwareentwicklung sollte dieses Modell beschreiben, wie sich das System – also das geplante Softwareprodukt – aus der Sicht der künftigen Benutzer verhält. Dies geschieht durch die Definition von Anwendungsfällen (Use Cases) oder beim Extreme Programming durch User-Stories. Das Modell sollte möglichst keine Implementierungsentscheidungen vorwegnehmen.

Die Datenanalyse dient der systematischen Auswertung umfangreicher Informationssammlungen. Diese können neu erstellt werden – zum Beispiel durch Messungen oder auch durch Kundenbefragungen – oder aber bereits vorliegen.

Bei der Prozessanalyse wird der Ablauf von Prozessen untersucht. Dabei kann es sich um beliebige Geschäftsvorfälle, Kommunikationsabläufe, Verwaltungs- oder Verarbeitungstätigkeiten handeln. Ziel der Prozessanalyse ist es, die beobachteten Prozesse zu optimieren. In der Softwareentwicklung geht es besonders um diejenigen Vorgänge, die durch die neue Software erledigt oder vereinfacht werden sollen.

Analyse- verfahren

Es gibt unterschiedliche Analysemethoden für Softwareprojekte; einige sind Teil spezieller Entwicklungsmethoden, die weiter unten vorgestellt werden. Hier nur kurz zwei Beispiele:

Die Strukturierte Analyse, bereits in den 1960er-Jahren von Tom De Marco entwickelt, entspricht dem Denkmodell der imperativen Programmiersprachen jener Zeit. Kern dieser Methode sind die bekannten Flussdiagramme und Programmablaufpläne. Einfache Beispiele für Flussdiagramme finden Sie in Kapitel 9, Konzepte der Programmierung.

Die Objektorientierte Analyse (OOA) folgt dagegen dem Paradigma der Objektorientierung und ist somit Bestandteil der meisten modernen Softwareentwicklungsprozesse. Ein wichtiges, weit verbreitetes Hilfsmittel der OOA ist die weiter unten vorgestellte Unified Modeling Language (UML), deren diverse Diagrammtypen übrigens alle Phasen des Entwicklungsprozesses begleiten können.

Offenes Konzept

In der Analysephase werden möglichst noch keine Implementierungsdetails festgelegt. Entscheidungen über die Hard- und Softwarebasis sowie die einzusetzende Programmiersprache sollten offen bleiben, um zu Beginn der Entwurfsphase die richtige Entscheidung zu treffen. Allerdings kann es natürlich sein, dass externe Vorgaben einzuhalten sind: Möglicherweise existiert beim Kunden bereits eine bestimmte Infrastruktur, mit der Ihr Produkt zusammenarbeiten muss. Ähnliches gilt, wenn es sich bei dem Projekt um die Erweiterung oder Anpassung vorhandener Software handelt.

Lasten- und Pflichtenheft

Die Zwischenergebnisse der Projektplanungsphase werden in einem sogenannten Lastenheft (Statement of Work) festgeschrieben. Bei Auftragsarbeiten wird es vom Kunden oder in Zusammenarbeit mit ihm erstellt. Gemäß DIN 69905 beschreibt es die »Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers«. Das Heft ist natürlich keineswegs nur auf Softwareprojekte beschränkt. Im Wesentlichen enthält es folgende Punkte:

Definition des Projektziels

Anforderungen an den Einsatz des Produkts

Allgemeine Informationen zum Produkt

Beschreibung der Funktionen des Produkts

Bestimmung der Leistungen, die der Auftragnehmer zu erbringen hat

Qualitätsstandards, denen das Produkt genügen soll – unter anderem hinsichtlich seiner Zuverlässigkeit, Benutzbarkeit, Effizienz und Änderbarkeit

Weitere Informationen oder Anmerkungen

Pflichtenheft

Auf der Basis des Lastenhefts entwickelt der Auftragnehmer das wesentlich präzisere Pflichtenheft (Proposal). Es beschreibt die technischen Eigenschaften des zu erstellenden Produkts. Je nach Art des Projekts gibt es viele Gliederungsmöglichkeiten für das Pflichtenheft. Hier nur ein Beispiel: [Es handelt sich um die leicht abgewandelte Form eines Industriebeispiels. Eine Übersicht über verschiedene Gliederungsmöglichkeiten finden Sie auf der folgenden Website zu einer Software-Engineering-Vorlesung an der FH Augsburg: http://www.fh-augsburg.de/informatik/vorlesungen/se1t/script/definition/pfheft.html. ]

Projektziele

Projektvorgaben

Hardwarebasis

Softwarevoraussetzungen

Einzusetzende Arbeitsmittel

Nebenbedingungen

Projektanforderungen

Aufgaben und Funktionen des Produkts

Benutzerschnittstelle

Lieferumfang

Kompatibilität und Portierbarkeit

Erweiterbarkeit und Änderbarkeit

Weitere Leistungen

Geplante Testreihen

Qualitätssicherung

Supportvereinbarungen

Kostenkalkulation

Literatur

10.1.3 Entwurf

Nach Abschluss der Analyse wird der Entwurf (Design) des Systems angefertigt. Er bildet die unmittelbare Implementierungsvorlage und sollte umso konkreter und exakter sein, je größer Team und Projektumfang sind. [Wichtige Ausnahme: Populäre Open-Source-Projekte haben besonders viele Mitarbeiter, müssen aber aufgrund der verteilten und asynchronen Teamzusammensetzung ohne Entwurf auskommen. Neue Features werden oft ad hoc eingebaut und dann durch Votings angenommen oder abgelehnt. ] In der Entwurfsphase muss unter anderem eine Entscheidung bezüglich der einzusetzenden Technologien (Hardware, Betriebssystem, Programmiersprache und Softwareumgebung) getroffen werden, sofern diese nicht von vornherein durch die weiter oben diskutierten Vorgaben festgelegt sind.

Extreme Programming und andere agile Entwicklungsprozesse verzichten übrigens fast vollständig auf einen expliziten Entwurf. Sie begeben sich mit den Analyseergebnissen unmittelbar an die Implementierungsarbeit; ihre Projektkoordination erfolgt vornehmlich über gut strukturierten und kommentierten Quellcode.

Der Entwurf kümmert sich im Wesentlichen um die Architektur des Produkts. Diese beschreibt den Aufbau und das Zusammenwirken der beteiligten Hard- und Softwarekomponenten. Im Wesentlichen muss die Architekturbeschreibung folgende Fragen beantworten:

1.	Welche Elemente gehören zum System selbst und welche stehen außerhalb?

2.	Über welche Ein- und Ausgabeschnittstellen kommuniziert das System mit seiner Umgebung?

3.	Über welche Schnittstellen kommunizieren die verschiedenen Komponenten des Systems miteinander?

4.	Welche Aufgaben muss das System selbst erfüllen und für welche greift es auf vorhandene Komponenten zurück?

5.	Wird das System auf einem einzelnen Rechner ausgeführt (Stand-Alone-System) oder kooperieren verschiedene Teile über ein Netzwerk (verteiltes System)?

Stand-Alone- vs. verteilte Systeme

Gerade der letzte Punkt bedingt zahlreiche weitergehende Architekturentscheidungen: Das Stand-Alone-System kann relativ frei gestaltet werden; eventuelle Einschränkungen existieren ausschließlich aufgrund der Hard- und Softwarebasis des Zielsystems. Verteilte Systeme sind dagegen erheblich komplexer – gerade dann, wenn sie in heterogenen Hardware-, Betriebssystem- und Netzwerkinfrastrukturen funktionieren sollen. Diese Interoperabilität wird immer häufiger verlangt. Es gibt unterschiedliche Arten verteilter Systeme. Zum Beispiel lassen sich die beiden folgenden grundlegenden Arten von Systemen unterscheiden:

Bei der Client-Server-Architektur erbringt die Server-Anwendung eine zentrale Dienstleistung, während die Client-Anwendungen darauf zugreifen und etwa Benutzeroberflächen bereitstellen. Beispiele sind etwa ein Datenbankserver, auf den mehrere Anwendungen und Benutzer zugreifen, oder ein Print-Server, der einer ganzen Abteilung einen hochwertigen Drucker zur Verfügung stellt.

Eine Peer-to-Peer-Architektur besteht aus gleichartigen Anwendungen, die miteinander kooperieren. Beispiele sind etwa die einfachen Dateifreigaben der meisten modernen Betriebssysteme oder auch Netzwerkspiele.

Definierte Schnittstellen

Bei der Softwareentwicklung in Teams ist die Schnittstellendefinition ein besonders wichtiger Faktor. Andernfalls ergeht es dem Team wie zwei Gruppen, die von den beiden Seiten eines Berges aus mit dem Graben eines Tunnels beginnen und erst viel zu spät feststellen, dass sie sich nicht in der Mitte treffen, sondern aneinander vorbeigebuddelt haben. [Das ist keineswegs ein akademisches Konstrukt; in der Eisenbahngeschichte ist es durchaus schon vorgekommen. ]

Das Endprodukt der Entwurfsphase ist, wie bei der Analyse, ein Modell des Systems. Auch hier kann beispielsweise die UML eingesetzt werden, um es darzustellen. Allerdings ist das Entwicklungsmodell erheblich konkreter und detailreicher als das Analysemodell.

Die verschiedenen Entwicklungsverfahren stellen diverse Methoden und Darstellungsarten für den Entwurf zur Verfügung; einige Beispiele lernen Sie weiter unten im Rahmen der einzelnen Modelle kennen.

10.1.4 Implementierung und Test

Die Implementierung, das heißt die eigentliche Programmerstellung, braucht hier im Grunde nicht mehr näher betrachtet zu werden. Schließlich war sie Thema der beiden vorangegangenen Kapitel. Dennoch ist es wichtig, sich für größere Projekte – besonders im Team – an einige Regeln zu halten:

Konsistenz. Halten Sie sich durchgehend an einmal festgelegte Konventionen für Bezeichner, Schnittstellen, Reihenfolgen, Codestruktur und Kommentare. Zumindest bei Teamprojekten gehört die Definition dieser Konventionen (der Coding Style) bereits zum Entwurf.

Modularisierung. Sorgen Sie für Überschaubarkeit: Eine Klasse darf keine eierlegende Wollmilchsau sein, sondern sollte genau eine Aufgabe erfüllen und mit anderen Klassen zusammenarbeiten. Dies verbessert die Wiederverwendbarkeit der einzelnen Klassen, ermöglicht häufiger den Abschluss definierter Arbeitsschritte und trägt so zu einer höheren Codequalität bei.

Versionsverwaltung. Es ist ungemein wichtig, über alle Änderungen im Code Buch zu führen, damit mögliche Nebeneffekte auf andere Programmteile erkannt werden und damit die Änderungen sich in Problemfällen auch wieder rückgängig machen lassen. Die praktischste Möglichkeit ist der Einsatz einer automatischen Versionsverwaltung wie CVS oder Subversion. Änderungen durch unterschiedliche Teammitglieder werden automatisch verzeichnet; verschiedene Versionen lassen sich vergleichen, zusammenführen und notfalls auf einen früheren Stand zurücksetzen.

Kommentare. Es ist zeitraubend und unbequem, Code nach mehreren Wochen oder gar Monaten zu lesen und herausfinden zu müssen, welche Aufgabe er erfüllt. Schon dies ist ein guter Grund für Kommentare. Diese sollten weder zu ausführlich (jeden trivialen Schritt erklärend) noch zu spärlich sein. Das im vorigen Kapitel erwähnte Javadoc generiert unmittelbar aus speziell formatierten Kommentaren die Dokumentation. Für viele andere Sprachen sind ähnliche Lösungen verfügbar. Wer im Hinblick darauf noch immer nicht kommentiert und die Dokumentation mühevoll nachträglich erstellt, ist selber schuld.

Software-Tests

In vielen modernen Entwicklungsprozessen – insbesondere den agilen – gehen die Tests unmittelbar mit der Implementierung einher. Im Wesentlichen sind in dieser Phase zwei Arten von Tests wichtig:

Unit-Tests (oder Klassentests) sind automatisierte, programmgesteuerte Tests, die die ordnungsgemäße Funktionalität von Klassen und ihren Bestandteilen überprüfen. Zu diesem Zweck stehen für viele Programmiersprachen »xUnit«-Frameworks zur Verfügung; das prominenteste Beispiel – JUnit für Java – wird weiter unten vorgestellt. Das »Test-first«-Verfahren des Extreme Programmings oder das Test-Driven Development gehen so weit, dass der Unit-Test noch vor der eigentlichen Klasse geschrieben wird; erst dann wird der Code implementiert, der diesen Test (hoffentlich) erfüllt.

Eine weitere beliebte Testmethode sind Code-Reviews: Die Programmierer eines Teams lesen ihren Code gegenseitig und stellen so dessen Qualität sicher; gleichzeitig wird die Kompatibilität der Schnittstellen verbessert. In agilen Prozessen ist der Code-Review ein integrierter Bestandteil der Implementierung. Beim Extreme Programming wird beispielsweise grundsätzlich in wechselnden Paaren programmiert, sodass immer zwei Programmierer für jeden Codeteil verantwortlich sind.

Natürlich gibt es auch Testarten, die erst nach Abschluss des Projekts oder eines einzelnen Moduls ausgeführt werden können. Dazu gehören besonders die Lasttests, die die Stabilität und Performance der Software unter realistischer Arbeitsbelastung testen.

10.1.5 Dokumentation

Die Dokumentation wird in der Regel als der letzte Schritt eines Entwicklungsprozesses bezeichnet. Dieses Denken ist gefährlich, weil es dazu verführt, tatsächlich erst am Ende damit zu beginnen. Durch den entstehenden Zeitdruck werden manche Aspekte des Projekts dann schlampig, falsch oder gar nicht dokumentiert. Wie bereits erwähnt, gibt es heute praktische Werkzeuge, die die Dokumentation aus Kommentaren extrahieren. Da Sie aus Ihrem ersten oder spätestens zweiten längeren Programm (womöglich schmerzlich) lernen beziehungsweise schon gelernt haben, dass Kommentare sich lohnen, können Sie diese auch gleich konform zu einem solchen Dokumentationsstandard anlegen. Moderne Entwicklungsumgebungen wie Eclipse erleichtern dies zusätzlich.

Dokumentationsarten

Beachten Sie, dass es mehrere Arten beziehungsweise Stufen der Dokumentation gibt:

Die Entwicklerdokumentation dient zunächst der Arbeit des Projektteams selbst. Sie beschreibt Klassen, Module, Schnittstellen und Erweiterungsmöglichkeiten der Software und bildet damit die Arbeitsgrundlage für Änderungen und Erweiterungen. Dieser Teil der Dokumentation ist die Hauptaufgabe von Dokumentationsgeneratoren wie Javadoc. Letztendlich sollte auch der Kunde die Entwicklerdokumentation erhalten, da oft nur der Einblick in innere Zusammenhänge die genaue Funktionsweise von Programmen offenbart. Besonders wichtig ist diese Ebene der Dokumentation bei Open-Source-Projekten: Der Quellcode mit den entsprechenden Kommentaren ist das Hauptkommunikationsmittel zwischen den verteilt arbeitenden Mitgliedern der Gruppe.

Eine Administratorendokumentation ist für technisches Fachpersonal vorgesehen, das die neue Software installieren und in Betrieb nehmen soll. Bei Einzelplatzanwendungen ist diese Person oft mit dem Endanwender identisch, sodass die Installations- und Konfigurationsanleitung hier besonders ausführlich und allgemein verständlich sein muss. Verteilte Systeme werden dagegen häufiger von IT-Fachleuten eingerichtet; diese benötigen zwar nicht unbedingt Grundlageninformationen, aber dafür besonders tiefgehende Auskunft über mögliche Spezialfälle.

Die Anwenderdokumentation schließlich beschreibt den Einsatz der Software, das heißt ihre Aufgaben und die Verwendung der Benutzeroberfläche. Sie ist mit der Bedienungsanleitung technischer Geräte vergleichbar: Der Endanwender braucht nicht alle Informationen, besonders nicht über Details, die »unter der Haube« liegen, muss sich aber genau auf die Anwendungsbeschreibung verlassen können. Deshalb sollte die Anwenderdokumentation besonders verständlich geschrieben werden und sich sehr genau an der Arbeitsweise von Benutzern orientieren. Beachten Sie aber, dass auch die beste Dokumentation kein Ersatz für eine schlecht gestaltete, das heißt unergonomische oder umständliche Benutzeroberfläche sein kann.

10.1.6 Konkrete Entwicklungsverfahren

Damit Sie eine Vorstellung davon erhalten, wie Entwicklerteams in der Praxis arbeiten könnten, werden hier kurz zwei bekannte Softwareentwicklungsprozesse vorgestellt: der Unified Process und Extreme Programming.

Der Unified Process

Der Unified Software Development Process wurde von den Entwicklern der weiter unten beschriebenen UML definiert und verwendet deren Mittel zur Darstellung von Anwendungsfällen, Abläufen und Entwürfen. Eine konkrete Implementierung des Verfahrens ist der Rational Unified Process (RUP), der Tools der Firma Rational Software einsetzt. Die Arbeitsweise des Unified Process wird vor allem durch drei Merkmale gekennzeichnet:

Anwendungsfälle (Use Cases). Die Analyse stützt sich beim Unified Process vor allem auf die Bedürfnisse der künftigen Benutzer des Systems. Diese werden durch sogenannte Anwendungsfälle dargestellt. Sie setzen die Benutzer (Akteure) in Beziehung zu verschiedenen Vorgängen und Geschäftsvorfällen. Aufgrund der Anwendungsfälle werden die Aufgaben der Software modelliert. Beachten Sie, dass der Begriff »Benutzer« nicht unbedingt Menschen bezeichnen muss; es kann auch um interagierende Geräte oder Programme gehen. Falls Sie beispielsweise die Anwendungsfälle eines Webservers darstellen würden, wäre sein »Gesprächspartner« ein Browser. Weiter unten erfahren Sie, wie Anwendungsfälle durch UML-Diagramme dargestellt werden.

Iterativer Prozess. Der Unified Process gehört zu den oben angesprochenen iterativen oder inkrementellen Softwareprozessen: Der Entwicklungszyklus wird mehrfach durchlaufen, wobei das Produkt schrittweise erweitert und verbessert wird.

Architekturzentriert. Neben den Anwendungsfällen konzentriert sich der Unified Process vor allem auf die Beschreibung der Architektur des geplanten Systems. Zunächst werden anwendungsfallunabhängige Teile modelliert, beispielsweise die Schnittstellen zur Zielplattform. Anschließend werden auch die erarbeiteten Anwendungsfälle in eine Architektur umgesetzt. Auch für die Beschreibung der Architektur werden verschiedene UML-Diagrammtypen verwendet.

Um die Tätigkeiten der Teammitglieder zu beschreiben, verwendet der Unified Process vier Begriffe:

Rollen (wer?). Aufgaben und Zuständigkeitsbereiche von Gruppen und ihren Mitgliedern werden durch Rollen beschrieben.

Aktivitäten (wie?). Jede Rolle besteht aus einer Abfolge von Aktivitäten, also von Handlungen, die ein bestimmtes Teilziel erreichen sollen.

Artefakte (was?). Die durch Aktivitäten verarbeiteten Projektteile werden als Artefakte bezeichnet; der Startpunkt eines Verarbeitungsschrittes wird Eingangsartefakt genannt, der Abschluss Endartefakt. Im Verlauf der Iterationsschritte werden manche Artefakte immer wieder weiterentwickelt.

Vorgehen (wann?): Die zeitliche Abfolge der Aktivitäten wird durch ein Vorgehensmodell beschrieben.

Phasen des UP

Die einzelnen (durch die Iteration mehrmals durchlaufenen) Phasen des Unified Process ähneln denjenigen, die weiter oben allgemein für die Softwareentwicklung erarbeitet wurden:

Konzeptionsphase. Entspricht im Wesentlichen der Planungs- und Analysephase des allgemeinen Software-Engineerings: Die Anwendungsfälle werden gesammelt, geordnet und ausgewertet; hier fällt einer Vorentscheidung über den Projektfokus und -umfang. Auch mit dem Entwurf der Architektur wird bereits in dieser Phase begonnen.

Entwurfsphase. In dieser zweiten Phase wird der Architekturentwurf fertig gestellt. Wichtige Kernkomponenten werden bereits implementiert, um mögliche Schwierigkeiten frühzeitig abschätzen zu können. Die Teilergebnisse werden eingehend mit dem Kunden besprochen, damit Zielkorrekturen durchgeführt werden können. Auch Tests und Dokumentation werden bereits begonnen.

Konstruktionsphase. Alle Teile des Systems werden fertig implementiert, ausgiebig getestet und dokumentiert. Schließlich müssen die einzelnen Bestandteile zum Gesamtsystem verknüpft werden.

Übergangsphase. Das System wird zu einem veröffentlichungsfähigen Paket zusammengestellt und beim Kunden installiert. Die Endanwender müssen in die Benutzung des Systems eingewiesen, bei komplexen Produkten sogar ausführlich geschult werden. Erst nach der Inbetriebnahme zeigt sich letztendlich, ob das System die geplanten Aufgaben in der Praxis erfüllt. Nun sind alle Anwender und Administratoren aufgefordert, noch vorhandene Fehler zu beschreiben und erst aus der Praxis ersichtliche Funktionsverbesserungen für die nächste Version zusammenzutragen.

Extreme Programming

Extreme Programming (XP) wurde vor allem von Kent Beck entwickelt, der aus dem Smalltalk-Umfeld stammt und auch zahlreiche Publikationen zu diesem Thema (und anderen Aspekten der Softwareentwicklung) verfasst hat. Die Bezeichnung Extreme Programming erklärt sich daher, dass sich dieser Softwareentwicklungsprozess insbesondere auf die eigentliche Programmierung konzentriert; Planung, Analyse und Entwurf werden kürzer gefasst. XP wird häufiger für kleinere Teams und für kleine bis mittlere Projekte eingesetzt. Dort kann es durch den erheblich geringeren Verwaltungsaufwand dieses Verfahrens zu einem entscheidenden Produktivitätsgewinn kommen. Allerdings wurden auch Großprojekte bereits erfolgreich nach diesem Verfahren durchgeführt.

Agile Entwicklungsprozesse

XP gehört zu den sogenannten agilen oder leichtgewichtigen Entwicklungsprozessen: Es existieren nur wenige feste Vorgaben; das Projekt befindet sich permanent im Fluss und kann jederzeit Änderungen der Vorgaben und Anforderungen verkraften.

Die Beschreibung von Extreme Programming erfolgt am besten über seine wichtigsten Prinzipien:

Kurze Release-Zyklen. XP erstellt keine großen, monolithischen Projekte, sondern definiert jeweils naheliegende, innerhalb weniger Tage oder höchstens Wochen erreichbare Iterationsziele. Dies bringt häufiger Erfolgserlebnisse und vor allem mehr Dynamik – auf jeder Stufe können Ziele geändert werden. Dafür kann Extreme Programming auf starre Kundenvorgaben verzichten.

Häufige Integration. Mit den kurzen Zyklen geht die häufige Zusammenfügung der einzelnen Komponenten zu einem (möglichst) lauffähigen Gesamtsystem einher; das »Aneinandervorbeibuddeln« wird so nahezu ausgeschlossen.

Einbeziehung des Kunden. Der Kunde wird nicht nur als Auftraggeber wahrgenommen, der einen einmal festgelegten Anforderungskatalog vorgelegt hat. Stattdessen wird jeder einzelne Entwicklungsschritt mit dem Kunden zusammen getestet; anschließend wird das weitere Vorgehen mit ihm abgestimmt.

Programmierung in Paaren. Die Programmierer sitzen stets zu zweit an einer Aufgabe – einer tippt, beide überlegen. Da die Paare möglichst mit jeder Einzelaufgabe wechseln, erhöht dies die Teambindung, verbessert das Zusammenwirken der Programmteile und integriert Code-Reviews in den unmittelbaren Arbeitsablauf.

Test-first-Verfahren. Es wird stets zuerst ein automatisierter Test (Unit-Test) geschrieben und ausgeführt. Nur wenn er scheitert, wird neuer Code hinzugefügt. Näheres erfahren Sie weiter unten im Unterabschnitt Unit-Tests.

Integriertes Refactoring. Durch das Test-first-Verfahren und die häufigen Releases ergibt sich beinahe von selbst, dass der Code regelmäßig aufgeräumt und an die neuen Gegebenheiten angepasst wird. So wird »Zombie-Code« vermieden, der Programme verlangsamt sowie die Lesbarkeit und Wartbarkeit verschlechtert.

40-Stunden-Woche. Das Ziel soll ohne Überstunden erreicht werden, da es sich sonst negativ auf Konzentrationsfähigkeit und Zufriedenheit des Teams auswirkt – dies verursacht auf lange Sicht Mehrkosten.

Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.