Konzept eines Qualitätssicherungs- und Dokumentationsprozesses zur Realisierung einer Software

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1 Einleitung

2 Grundlagen der Softwareentwicklung
2.1 Vorgehensmodelle in der Softwareentwicklung
2.1.1 Das Phasenmodell
2.1.2 Das Wasserfallmodell
2.1.3 Das V-Modell
2.1.4 Das Spiralmodell
2.1.5 Der Unified Software Development Process
2.2 Methoden der Qualitätssicherung
2.3 Dokumentationsweisen

3 Das Produkt Stiftungsmanager
3.1 Stiftungsmanager der Kreissparkasse Bautzen
3.2 Historisches - Entstehungsgeschichte
3.3 Rückwirkende Betrachtung
3.4 Die Software im Detail
3.4.1 Module
3.4.1.1 Administration
3.4.1.2 Kunden
3.4.1.3 Projekte
3.4.2 Prozesskette Stiftungsarbeit
3.4.3 Anwendungsfallbeschreibung
3.5 Schwachstellen des bisherigen Entwicklungsprozesses

4 Situation heute
4.1 Aktueller Stand in Bautzen
4.2 Stiftungsmanager 2.0
4.3 Gewonnene Erkentnisse

5 Konzeption des neuen Prozesses
5.1 Prozess im Detail
5.2 Prototyping
5.3 Einführung des Prozesses
5.4 Das Freigabeverfahren nach OPDV

6 Fazit
6.1 Bewertung der Arbeitsergebnisse
6.2 Ausblick

A Das Unternehmen

Glossar

Literaturverzeichnis

Abbildungsverzeichnis

2.1 Phasenmodell
2.2 Wasserfallmodell
2.3 V-Modell
2.4 Zusammenwirken der Submodelle
2.5 Spiralmodell
2.6 Unified Process

3.1 Menüführung
3.2 Ansicht Projekte
3.3 Vorgangskettendiagramm Kernfunktionen

5.1 Risikoorientiertes Programmeinsatzverfahren

Tabellenverzeichnis

2.1 Rollen im V-Modell

3.1 Elemente einer erweiterten EPK

1 Einleitung

Die vorliegende Abschlussarbeit zeigt einen Prozess auf, der bei der Realisierung einer Software qualitäts- und dokumentationssichernde Eigenschaften aufweist. Das Unter- nehmen NEW VOICE entwickelte als Branchenlösung für den Bereich Stiftungen den Stiftungsmanager. Derzeit exisitiert dieser in der ersten Version und findet unter an- derem Anwendung in der Sparkassen-Stiftung für den Landkreis Bautzen, welche hier als Beispiel dienen soll.

Zunächst werden grundlegende Vorgehensmodelle in der Softwareentwicklung aufgezeigt. Nach Betrachtung der Methoden in der Qualitätssicherung werden Dokumentationsweisen erläutert. Im Anschluss wird auf die Funktionalität des bestehenden Stiftungsmanagers eingegangen. Nach einer retrograden Bewertung des Entstandenen wird die gegenwärtige Situation verdeutlicht, vor der die Entwicklung heute steht. Ein Weg zur Etablierung des enstandenen Prozesses wird zum Schluss der Konzeption aufgezeigt. Die Arbeit schließt mit einem Fazit, welches eine wertende Zusammenfassung der Arbeit darstellt und einen Ausblick für die Zukunft eröffnet.

Die Thematik dieser Abschlussarbeit entstand aus der Erkenntnis der Notwendigkeit einer strukturierten Vorgehensweise bei der Erstellung von Software heraus. Diese erhöht letztendlich die Akzeptanz und Effizienz der Software.

2 Grundlagen der Softwareentwicklung

Eine Software zu entwickeln, bedeutet für die Beteiligten eine konkrete Vorgehensweise kontinuierlich zu verfolgen. Die Informatik deckt mit dem Software Engineering dieses Gebiet ab. Der Begriff wurde während einer NATO Konferenz im Jahre 1968 geprägt und ist im deutschen Sprachraum als Softwaretechnik bekannt (vgl. [Zus04], S.23).

In ihrer knapp vierzigjährigen Geschichte sind viele Vorgehensweisen entstanden, die im zeitlichen Verlauf Verbesserungen erfuhren. Die Entwicklung jedoch ist und bleibt ein Zusammenspiel von Projektmanagement und technischer Umsetzung. Zwei wesentli- che Aspekte in der Softwareerstellung sind die Qualitätssicherung und Dokumentation (vgl. [Zus04], S.49). Dieses Kapitel widmet sich zunächst der Darstellung von Vor- gehensmodellen und zeigt im Anschluss bekannte Qualitätssicherungsmethoden und Dokumentationsweisen auf.

Die Qualitätssicherung

Unbedingt zu beachten ist, dass die Begriffe Qualität und Qualitätssicherung nicht gleichwertig sind. Eine Unterscheidung muss getroffen werden. Die Qualität einer Software bezieht sich auf die Erfüllung der zuvor gestellten Anforderungen. Diese sind in den Qualitätsmerkmalen festgeschrieben.

Die Qualitätssicherung hingegen hat zum Ziel, die Produktqualität über den ganzen Entwicklungsprozess zu sichern. Sie bezieht sich auf die Projektziele, die organisatori- schen Abläufe, das Zusammenwirken der Ressourcen, die Arbeitsweise und die hierzu erforderlichen Mittel. Da Vorgehensmodelle phasenorientiert sind ist zu beachten, dass in den Phasen maximal die Qualität der vorausgehenden Phasen erreicht werden kann (vgl. [May01], S.97). Diese Aussage impliziert die Notwendigkeit der Qualitätssiche- rung schon zu Beginn eines Softwareprojektes. Ihre Hauptaufgaben lassen sich in drei Bereiche unterteilen. Umrissen werden die Qualitätsplanung, die Qualitätsprüfung und die Qualitätslenkung, wie in ([Zus04], S.142) geschildert.

Die Dokumentation

Bei der Dokumentation von Softwareprojekten sind drei Ausprägungen zu unterscheiden. Es gibt verschiedene Zielgruppen, für die dokumentiert wird.

(i) Die Produktdokumentation

Es wird eine Produktdokumentation erstellt, die das Projektergebnis beschreibt. Sie soll dem Anwender erklären, was das System leistet und wie es bedient wird. Bei größeren Projekten wird diese Art der Dokumentation nicht von den Programmierern übernom- men, sondern von eigens dafür eingesetzten Teams. Diese Aufgabenteilung bietet sich aus zwei Gründen an. Erstens sind die meisten guten Entwickler nicht unbedingt gute Autoren und zweitens sind die Online-Hilfe und das Handbuch oft der erste Kontakt des Anwenders mit dem neuen Produkt. Die Güte dieser Dokumentation trägt erheb- lich dazu bei, ob die Software vom Kunden angenommen wird oder nicht (vgl.[BO01], S.214). Professionelle Hilfe zur Erstellung der Anwenderdokumentation in Anspruch zu nehmen, stellt somit kein Hindernis dar.

(ii) Die Managementdokumentation

Die zweite Art der Dokumentation ist die Managementdokumentation. Sie dient der Steuerung des Projektverlaufs. Dokumente, welche die Durchführung des Projektes unterstützen, gehören in diese Kategorie. Ein wichtiger Inhaltspunkt der Management- dokumentation ist der Entwicklungsplan. Er beschreibt wie das Produkt entwickelt wer- den soll und hat grundsätzliche Entscheidungen zum Inhalt. An dieser Stelle werden auch verbindliche Aussagen zur Qualitätssicherung getroffen, wie in ([BO01], S.216) angemerkt. Pläne aus dieser Dokumentationsstufe lassen sich für eine nachträgliche Analyse des Projektverlaufs nutzen. So können positive Eindrücke, aber auch aufgetre- tene Schwachstellen, für zukünftige Projekte berücksichtigt werden.

(iii) Die Entwicklungsdokumentation

Bestandteile der Entwicklungsdokumentation sind technische Dokumente, die zur Er- stellung, Wartung und Weiterentwicklung des Systems benötigt werden. Sie ist notwen- dig um die Systemstruktur, sowie das Systemverhalten zu verstehen. Sie enthält Details und Zusammenhänge, die nicht aus der Software ersichtlich sind. Diese Dokumentation ordnet die verfügbaren Informationen und bringt sie in Zusammenhang. Sie beinhaltet die Zusammenhänge der Architektur mit allen relevanten Designentscheidungen und Alternativen (vgl.[BO01], S.217). Für die Entwicklungsdokumentation hat sich in der Realität eine Struktur bewährt, die darauf aufbaut zunächst ein Anforderungsdoku- ment zu erstellen und dann in einem umfassenden Softwarearchitekturdokument die Systemstruktur detailliert darzustellen. Die Verfasser der Dokumentation sollten dar- auf achten, dass Informationen nicht redundant gehalten werden (vgl.[BO01], S.220).

2.1 Vorgehensmodelle in der Softwareentwicklung

In der Praxis gibt es sehr viele Vorgehensmodelle. Mit zunehmender Komplexität der entstandenen Anwendungen ist erkannt worden, dass die Entwicklung von Software den Charakter einer Ingenieurdisziplin aufweisen muss (vgl. [May01], S.29). Seitdem erkannt wurde, dass ein planmäßiges Vorgehen bei der Erstellung von Software notwendig ist, wurden immer wieder neue Vorgehensmodelle entwickelt und in Projekten eingesetzt. Der Treiber für die jeweilige Neuentwicklung ist das Erkennen von suboptimalen Eigenschaften des Vorgängermodells.

Ein neues Modell entsteht somit, indem durchdachte Verbesserungen eingebettet werden. Im tatsächlich erfolgenden Gebrauch stellt sich dann heraus, inwiefern die neuen Ansätze von Nutzen sind. Änderungen die dann notwendig erscheinen, resultieren wiederum in einem neuen Modell. Im Folgenden werden aus der Menge von bekannten Vorgehensmodellen die Wichtigsten aufgezeigt. Anhand des zeitlichen Ursprungs ist zu erkennen, in welche Richtung sich die Modelle entwickelt haben.

2.1.1 Das Phasenmodell

In diesem Modell werden die unterschiedlichen Entwicklungsaktivitäten in Phasen un- terteilt. Diese sind zeitlich nacheinander angeordnet und werden der Reihe nach abge- arbeitet. Ergebnisse einer Phase fließen in die darauf folgende ein. Ursprünglich wurde das Modell entwickelt, um hauptsächlich Projekte der öffentlichen Hand nach einheitli- chen Maßstäben abwickeln zu können. Das Modell wurde 1956 von Herbert D. Bening- ton vorgestellt (vgl.[Bal98], S.99). Die Vorgangsweise ist streng sequentiell. Zu Anfang werden die Anforderungen der Anwender ermittelt und festgehalten. Diese Leistungs-beschreibung bildet die Grundlage des ganzen Prozesses. Für jede Phase werden im Vorfeld die zu erzielenden Ergebnisse definiert. Eine neue Phase kann erst begonnen werden, wenn die vorhergegangene vollständig abgearbeitet ist.

Dieser Schritt besteht zum einen aus der Verifikation (Bauen wir das Produkt richtig?) sowie der Validierung (Bauen wir das richtige Produkt?) des Phasenergebnisses. Sind diese Ergebnisse akzeptiert, kann die neue Phase beginnen. Die Abbildung 2.1 zeigt die Anordnung der Phasen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Phasenmodell

Von der Anwendung dieser streng sequentiellen Vorgehensweise versprach man sich zunächst eine bessere Koordination der Projekte bezüglich Planung, Organisation und Kontrolle. Die Realität zeigte jedoch, dass die rein sequentielle Vorgehensweise in den wenigsten Fällen durchführbar ist. Das Phasenmodell impliziert, dass alle Anforde- rungen der Anwender bekannt und statisch sind. Nach diesen Vorgaben werden die darauf folgenden Phasen aufgebaut. Das zu erstellende System, hätte sich demnach nach diesen statischen Werten zu richten. Steht dieses Grundgerüst, wird mit der tech-nischen Umsetzung begonnen. Erst zum jetzigen Zeitpunkt stehen Teile des Systems zur Verfügung, die dem Endabnehmer vorgelegt werden können. Treten an dieser Stelle Unstimmigkeiten auf, so sind Maßnahmen zur Änderung immer mit sehr hohem Auf- wand verbunden (vgl.[May01], S.71). Die Erfahrungen, die mit diesem Modell gemacht wurden, führten zu Varianten, welche die streng sequentielle Vorgehensweise auflocker- ten.

2.1.2 Das Wasserfallmodell

Bei diesem Vorgehensmodell handelt es sich um eine Weiterentwicklung des Phasen- modells. Es wurde 1970 von Winston Royce vorgestellt [Roy]. Es erweitert das vorher- gehende Phasenmodell um Rückkopplungsschleifen zwischen den Stufen (vgl.[Bal98], S.99). Diese beschränken sich auf die benachbarte Stufe, um teure Überarbeitungen über mehrere Stufen hinweg zu vermeiden. Ergebnisse der einen Phase fallen in die nächste. Das hier beschriebene Modell weist die folgenden Eigenschaften auf. Aktivitä-

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Wasserfallmodell

ten in den einzelnen Phasen sind in richtiger Reihenfolge und vollständig durchzufüh- ren. Ergebnis einer Aktivität ist ein fertiges Dokument. Das Wasserfallmodell ist somit dokumentengetrieben. Wie auch beim zuvor erläuterten Phasenmodell, handelt es sich bei dem Wasserfallmodell um eine sequentielle Vorgehensweise. Das bedeutet, jede Ak- tivität muss beendet sein, bevor mit einer neuen begonnen werden kann. Das Vorgehen selbst ist top-down orientiert und definiert somit zunächst grob die Anforderungen. Diese werden dann immer mehr verfeinert. Gleiches gilt für die restlichen Phasen die- ses Modells. Das Wasserfallmodell benötigt wenig Führungsaufwand, ist einfach und verständlich. Die Benutzerbeteiligung ist lediglich in den Anfangsphasen vorgesehen. Der Entwurf und die Implementierung erfolgen ohne Beteiligung des Auftraggebers.

Die hier aufgeführten Eigenschaften haben dem Wasserfallmodell zu weiter Verbreitung geholfen. Nachteilig bewertet wird das Modell durch die Erkenntnis das es nicht immer sinnvoll ist, alle Entwicklungsschritte in voller Breite und Vollständigkeit durchzuführen. Das gilt ebenso für die sequentielle Vorgehensweise. Im Hinterkopf ist immer zu behalten, dass die Gefahr besteht, die Dokumentation im Gegensatz zum eigentlichen System, in den Vordergrund zu treiben. Der zu Anfang festgelegte statische Weg kann, bei sich schnell ändernden Rahmenbedingungen, entstehende Risikofaktoren nicht berücksichtigen, da der Weg streng vorgegeben ist.

2.1.3 Das V-Modell

Das V-Modell stellt eine Erweiterung des Wasserfallmodells dar (vgl.[Bal98], S.101). Im Gegensatz zum Wasserfallmodell integriert es Qualitätssicherung und gliedert den Entwicklungsprozess in miteinander korrelierende Phasen. Das Vorgehensmodell ist sequentiell. Die Idee des V-förmigen Vorgehens stammt von Barry Boehm und wurde 1979 erstmalig vorgestellt.

Auch bei diesem Modell wird davon ausgegangen, dass am Ende einer Phase ein vor- handenes Produkt steht. Das Produkt ist nicht gleichzusetzen mit einer fertigen Anwen- dung, sondern kann vielmehr auch ein Dokument sein, welches in den Phasen erarbeitet wurde und in die nächste mit einfließt. Die symmetrische Anordnung der zusätzlichen Phasen, in denen die Ergebnisse der gegenüberliegenden Phasen bewertet werden, führt zu einer V-förmigen Darstellung, wie die Abbildung 2.3 zeigt. Auf diesem Modell auf- bauend, wurde 1992 ein generischer Entwicklungsprozess vorgestellt, der zunächst einen Softwareentwicklungsstandard der Bundeswehr darstellte. Seit diesem Zeitpunkt wur-

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: V-Modell

den die im praktischen Einsatz gewonnenen Erkenntnisse gesammelt, so das diese in eine neuere Version eingearbeitet werden konnten. Somit entstand das V-Modell ´97. Es wurde zu einer verbindlichen Regelung für alle Ministerien, Behörden und Firmen, die Projekte für diese Institutionen durchführen. Aus dem Bereich der öffentlichen Hand kommend, hat sich das V-Modell auch als ein Standard in der freien Wirtschaft etabliert (vgl.[BO01], S.41). Es bietet einen gut organisierten Entwicklungsprozess, der den Beteiligten Hilfestellung leistet. Das V-Modell unterstützt die Steuerung der Tätig- keiten des Entwicklerteams, legt fest welche Produkte als Folge welcher Tätigkeiten zu liefern sind und unterstützt die Erreichung eines projektbezogenen Qualitätsstandards.

Zu erkennen ist, dass das V-Modell sich nicht lediglich auf die Systemerstellung bezieht, sondern vielmehr versucht alle Bereiche im Entwicklungsprozess zu berücksichtigen. Daher trifft man im V-Modell auf die Submodelle Projektmanagement, Systemerstel- lung, Qualitätssicherung und Konfigurationsmanagement. In der Abbildung 2.4 wird ihr Zusammenwirken illustriert. Sie werden durch Personen geleitet die unterschiedliche Rollen einnehmen. Eine Rolle umfasst die notwendigen Erfahrungen, Kenntnisse und Fähigkeiten die erforderlich sind um Aktivitäten durchzuführen. In jedem Submodell gibt es

- einen Manager, der die oberste Entscheidungsinstanz ist und die Rahmenlinien für die Aktivitäten des Submodells festlegt,
- einen Verantwortlichen, der die Aufgaben des Submodells entwirft, plant und kontrolliert,
- einen oder mehrere Durchführende, die die Aufgaben umsetzen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.4: Zusammenwirken der Submodelle

Das Modell definiert insgesamt 25 Rollen denen Tätigkeiten zugewiesen werden kön- nen. Das V-Modell soll für verschiedene Produktentwicklungen anwendbar sein. Es erhebt den Anspruch auf Allgemeingültigkeit. Eine Anpassung des Modells an ein kon- kretes Projekt erfolgt durch Veränderungen an den Produkten und Aktivitäten. Diese

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.1: Rollen im V-Modell

Handlung nennt man im Kontext des V-Modells Tailoring. Das Anpassen geschieht in zwei Stufen. Zum einen werden die Aktivitäten und Produkte vor Entwicklungsbeginn festgelegt. In diesem Zusammenhang spricht man von ausschreibungsrelevantem Tailoring. Andererseits besteht die Möglichkeit im Verlauf der Entwicklung situationsabhängige Aktivitäten und Produktinhalte bei jeder Hauptaktivität festzulegen. Hier kommt der Begriff des technischen Tailorings zum Ausdruck. Die Entwicklung dieses Modells mündete 2005 in der neuesten Version, so dass heute das V-Modell XT als verbindlicher Standard gilt. Der Namenszusatz XT steht hierbei für „extreme Tailoring“ und verdeutlicht die hohe Anpassungsfähigkeit des Modells an die unterschiedlichen Anforderungsprofile der Projekte und Organisationen.

2.1.4 Das Spiralmodell

Das von Barry Boehm 1988 vorgestellte Spiralmodell ist eine Vorgehensweise, die sich durch einen zyklischen Entwicklungsablauf auszeichnet (vgl. [May01], S.72). Jede Um-drehung der Spirale entspricht einer Iteration. Für jedes zu erstellende Teilprodukt eines Projektes sind vier Schritte zu durchlaufen. Die Schritte entsprechen den Qua- dranten in der grafischen Darstellung des Modells (aus [May01], S.73). Im oberen linken Quadranten beginnend, wird im Uhrzeigersinn fortgefahren. Der Zyklus beginnt mit

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.5: Spiralmodell

dem Festlegen der Ziele des Teilprodukts. Festzuhalten sind Aussagen über Leistung, Funktionalität und Anpassbarkeit. Alternativen, die sich für die Realisierung des Teilprodukts ergeben, sind aufzuzeigen. Diese können aus mehreren Entwürfen bestehen, als auch aus der Möglichkeit, die sich durch Zukauf einer Lösung ergibt. Ebenso sind Nebenbedingungen und Einschränkungen auszuarbeiten.

Der nächste Schritt besteht aus einer Bewertung der Lösungsalternativen bezogen auf die Projektziele und Nebenbedingungen. Das Hauptaugenmerk liegt hier auf dem Auf- decken möglicher Risiken, welche die Alternative birgt. Werden solche erkannt, sind Maßnahmen und Strategien zu entwickeln, um die Risikoquellen selbst beziehungs- weise deren mögliche Auswirkungen einzugrenzen. Hilfestellung können hier erstellte Prototypen, Simulationen oder auch Benutzerbefragungen sein. Unter Beachtung der verbleibenden Risiken wird im dritten Schritt entschieden nach welchem Vorgehensmo- dell die Entwicklung in der Iteration weiter gehen soll. Eine Kombination verschiedener Modelle ist zulässig, wenn dadurch das Risiko weiter minimiert werden kann. In jedem Zyklus kann in Abhängigkeit von den Risiken das Prozessmodell gewählt werden.

Der letzte Schritt besteht aus der Planung des nächsten Zyklus und einer Überprüfung der vorangegangen Schritte der Spirale. Im letzteren Fall spricht man von einem Re- view. Sollte sich in der Bewertung des Produkts herausstellen, dass eine Aufteilung in Komponenten sinnvoll erscheint, so kann diese vorgenommen und die Einzelteile für sich weiter entwickelt werden. Diese Komponenten durchlaufen wieder die vier Schritte bis sie erstellt sind. Das primäre Ziel des letzten Schrittes ist Einigung bei allen Betei- ligten über das bisher Erreichte, aber auch im nächsten Zyklus Geplante, zu erzielen. Das Herstellen dieses Einverständnisses wird als Commitment bezeichnet.

Das Spiralmodell weist die folgenden Eigenschaften auf. Es ist ein risikogetriebenes Modell, in dem die Minimierung des Risikos das oberste Ziel ist. Das Durchschreiten aller Quadranten entspricht einer Iteration, somit ist jede Spirale ein iterativer Zyklus mit gleichen Schritten. Die Ziele für jeden Zyklus leiten sich aus den Ergebnissen des vorhergehenden Durchlaufs ab. Es wird in regelmäßigen Intervallen überprüft, ob der Prozessablauf an den Risiken ausgerichtet ist. Ein bestehendes Prozessmodell ist nicht für die gesamte Entwicklung zwingend festgelegt. Das Modell ist somit flexibel und kann andere Prozessmodelle in der Entwicklungsstufe implementieren. Ein weiterer Punkt ist die frühzeitige Eliminierung von Fehlern und ungeeigneten Alternativen. Durch die periodisch erfolgende Überprüfung der Ziele und Planung des nächsten Zyklus lässt sich die Entwicklung leichter umlenken als bei sequentiellen Vorgehensweisen, in denen zu spät erkannte Anwenderanforderungen erhebliche Kosten verursachen können.

Andererseits ist der hohe Managementaufwand, den das Modell erfordert, nachteilig zu bewerten (vgl. [Bal98], S.129 ff.), jedoch überwiegt mit der laufenden Überprüfung und Anpassung des Prozessablaufs die Einbettung von Qualitätssicherungsmaßnahmen (vgl. [May01], S.74).

2.1.5 Der Unified Software Development Process

Bei dem Unified Software Develpoment Process (auch Unified Process abgekürzt) han- delt es sich um eine iterativ - inkrementelle Vorgehensweise. Sie ist Anfang 1999 von den drei Spezialisten James Rumbaugh, Grady Booch und Ivar Jacobson vorgestellt worden (vgl. [Zus04], S.79). Der Prozess ist neben dem iterativ - inkrementellen An- satz auch anwendungsfallorientiert und architekturzentriert. Er wird beschrieben durch Phasen und Iterationen, Prozesse (Workflows) und Aktivitäten, Rollen (Worker ) so- wie Modelle und Produkte (Artifacts). Die Abbildung 2.6 (angelehnt an [Zus04], S.86) bietet einen Überblick der Phasen und Prozesse. Die Verteilung der Schwerpunkte in den einzelnen Aktivitäten, ist ebenfalls der Abbildung zu entnehmen. Der Unified Pro-

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.6: Unified Process

zess ist durch Anwendungsfälle gesteuert (vgl. [Zus04], S.81). Noch bevor ein System entworfen werden kann, gilt es die Anforderungen genau zu spezifizieren. Diesbezüglich muss der Kreis zukünftiger Benutzer eingeschränkt werden, um deren Anforderungen genau zu ermitteln. Bei den Benutzern muss es sich nicht zwingend um Personen han-deln. Ermittelt werden gegebenenfalls auch die Anforderungen von Systemen, die über Schnittstellen kommunizieren. Die Modelle des Entwurfs sind an den Anwendungs- fällen ausgerichtet. In dem Arbeitsschritt Implementierung ist auf die Erfüllung der Anwendungsfälle zu achten. Gleiches gilt für die Aufstellung des Testplans. Da die An- wendungsfälle den Umgang mit der Software im Realen gedanklich vorweg nehmen, werden sie in der dann existierenden Umgebung unter Echtzeitbedingungen geprüft. Die Berücksichtigung der Anwendungsfälle zieht sich somit durch alle Arbeitsschritte.

Der Unified Process setzt voraus, dass die Erstellung eines Systems nicht mit einem ein- maligen Durchlauf der Arbeitsschritte zu bewerkstelligen ist. Vielmehr ist es notwendig, die Arbeitsschritte in mehreren Iterationen zu durchlaufen. Während dieser Durchlauf- zeit werden das Spektrum und die Qualität der Produkte schrittweise verbessert. In einer Iteration sollten möglichst viele Produkte gleichzeitg entwickelt werden. Das Pro- jekt verzeichnet somit ein inkrementelles Wachstum. Die Anzahl der Iterationen die hierfür erforderlich sind variiert je nach Produkt. Ist die gewünschte Qualität erreicht, kann das System ausgeliefert werden. Die iterativ und inkrementelle Vorgehensweise verhindert spätere Rückschläge, da mit der Erstellung der einzelnen Produkte frühzeitig begonnen wird. So können Rückschritte die hierbei ebenfalls vorgesehen sind mit gerin- gerem Ausmaß pro Iteration getätigt werden. Zeiteinbußen sind nahezu auszuschließen, so dass ein Projekt früher abgeschlossen werden kann. Der iterativ / inkrementelle Cha- rakter dieser Entwicklungsart berücksichtigt die Erkenntnis, dass zu Beginn nicht alle Anforderungen an das System bekannt sind.

Mit der Aufstellung der Anwendungsfälle einhergehend werden die ersten Architektur- bedingungen formuliert. Die Architektur bildet die Grundlage des Gesamtsystems und ist Vorraussetzung für seine erfolgreiche Aufstellung. Zunächst werden die Teile der Ar- chitektur berücksichtigt, die unabhängig von den Anwendungsfällen sind. Im Anschluss wird die Architektur erstellt, welche die Anwendungsfälle in Teilsystemen wiedergibt. Da im Projektverlauf ein iterativ inkrementeller Zuwachs vorhanden ist, nimmt der De- taillierungsgrad der Architektur im zeitlichen Verlauf zu. Der Unified Prozess besteht aus den vier Modellierungselementen, die im Folgenden erläutert werden.

(i) Rollen

Die Rolle ist der zentrale Bestandteil des Unified Process. Sie beschreibt das Verhalten und die Verantwortlichkeiten, die ein Mitarbeiter oder auch ein Team aufweisen muss.

Das Verhalten kommt innerhalb der Aktivitäten zum Ausdruck. Der Bezug zum Verhal- ten einer Rolle ergibt sich aus der Assoziation der Aktivitäten zu den Rollen. Artefakte, die es zu erstellen gilt, sind ebenfalls bestimmten Rollen zuzuordnen. Der Gegenstand der Rolle selbst ist nicht personengebunden. Eine Person kann auch mehrere Rollen wahrnehmen.

(ii) Aktivitäten

Die Aktivitäten sind den Rollen zugeordnet. Sie sind als ein Maß von Arbeitsschritten zu sehen, die der einzelne Mitarbeiter erledigen kann. Jede Aktivität muss ein bestimm- tes Ziel und einen Zweck aufweisen. So ist das Bearbeiten einer Systemkomponente oder auch das Erstellen eines Artefaktes als Aktivität zu sehen. Der zeitliche Umfang richtet sich nach der Anzahl der zu erstellenden Artefakte. Die einzelne Aktivität sollte mit einer überschaubaren Menge von Artefakten verbunden sein. Sie kann grundsätzlich mehrmals durchgeführt werden, vor allem wenn dieses in einer neuen Iteration gefor- dert ist. Als Beispiel für eine Aktivität sei hier die Planung einer Iteration oder das Erstellen eines Anwendungsfalls genannt.

(iii) Artefakte

Artefakte sind Produkte, die im Verlauf des Prozesses benötigt und erstellt werden. Die Aktivitäten besitzen Eingangs- und Ausgangsartefakte. Ein Artefakt trägt Informatio- nen, die in den Prozess einfließen, ihn verändern und von ihm genutzt werden. Da der Prozess ein inkrementelles Wachstum aufweist, haben die ihn begleitenden Artefakte unterschiedliche Ausprägungen. Innerhalb der Iterationen werden sie in den einzelnen Phasen bearbeitet und sukzessiv vollendet. Als Beispiele seien hier der Quellcode und Modelle genannt.

(iv) Vorgehen

Die drei zuvor genannten Modellierungselemente werden in einem Vorgehensmodell zusammengefasst. Somit entsteht durch geschicktes Aneinanderfügen der Aktivitäten ein geordneter Prozess.

Funktionsweise des Unified Process

Wie in der Abbildung 2.6 dargestellt, beinhaltet der Unified Process fünf Arbeits- schritte (vgl. [Zus04], S.84). In einer Iteration werden sie je einmal abgearbeitet. Jeder Arbeitsschritt erzeugt ein Artefakt, welches in die nächste Iteration mit einfließt und gegebenenfalls phasenübergreifend zur Bearbeitung vorhanden ist. Zu Beginn des Pro- zesses werden die Anforderungen gesammelt und zum größten Teil fertig gestellt. Auf dieser Grundlage wird eine Analyse erstellt und ein Entwurf begonnen. Zeitgleich er- folgen der Entwurf und die Implementierung des Architekturkerns. Das System wird in der Konstruktionsphase fertig gestellt und getestet. In der Übergangsphase werden die abschließenden Aktivitäten durchgeführt, mit denen das System installiert und in Betrieb genommen wird.

Die Iterationen schließen mit einem formellen Review. Die Produkte, die in der Ite- ration erstellt wurden, werden bezüglich ihres Reifegrades für den Start in eine neue Iteration überprüft. Sie sollten keine ausschlaggebenden Mängel aufweisen, damit sie in der folgenden Iteration verwendbar bleiben. Optimierungen sind hier von kurzer Dauer, da Verzögerungen bei parallel verlaufenden Tätigkeiten vermieden werden sol- len. Daher sind Verbesserungen in einer weiteren Iteration besser aufgehoben. In dem formellen Review werden Aussagen über die technische Qualität und das weitere Vor- gehen getroffen. Am Ende einer Phase steht ein Status Review. Hier wird festgestellt, ob der bisherige Projektverlauf den zuvor erstellten Plänen und Standards entspricht. Die aufgetretenen Abweichungen werden zusammen mit der Risikobewertung festge- halten. Vom Projektmanagement sind Maßnahmen zu deren Beseitigung einzuleiten. Die nächste Phase kann beginnen, sobald der Projektverlauf mit den Plänen überein- stimmt.

2.2 Methoden der Qualitätssicherung

Wie zu Beginn des zweiten Kapitels beschrieben, orientiert sich die Qualitätssiche- rung an den zu erreichenden Zielen. Die Produktqualität soll hierbei über den ganzen Entwicklungsprozess gesichert werden. Grundsätzlich ist festzuhalten, dass es eines Qualitätsmanagements bedarf, wenn die Anforderungen an eine Software erfüllt wer- den sollen (vgl. [Bal98], S.299). Die Aufgaben der Qualitätssicherung lassen sich in drei Bereiche gliedern, die jeweils als Aktivität mit greifbaren Ergebnissen verstanden werden.

(i) Qualitätsplanung

In diesem Teilbereich werden die Qualitätsmerkmale festgelegt, die einer Bewertung zu unterziehen sind. Weiterhin ist zu entscheiden, wie die Qualität überprüft werden kann. Einerseits kann auf quantitativ messbare Vorgaben, wie beispielsweise die maxi- male Ausfallzeit pro Jahr, zugegriffen werden. Es ist andererseits auch möglich, qua- litative Vorgaben festzulegen. Als Beispiel sei hier die Benennung einer Zielplattform aufgeführt.

(ii) Qualitätsprüfung

Die Grundlage einer qualtitativ hohen Projektentwicklung sind fehlerfreie und vollständige Unterlagen. Die Qualitätsprüfung erfasst die Ist-Werte der in Punkt (i) genannten Planung und überprüft, ob die konstruktiven (siehe iii) Qualitätsmanagement Maßnahmen umgesetzt wurden.

(iii) Qualitätslenkung

Die gewünschten Qualitätsanforderungen werden durch konstruktive, organisatorische und analytische Qualitätsmanagement Maßnahmen erreicht. Die konstruktiven Maß- nahmen beinhalten die durchgehende Anwendung von technischen Methoden und Werk- zeugen in allen Phasen der Softwareentwicklung. So müssen die Entwickler nicht für jedes Projekt einen neuen Prozess erstellen. Da nicht alle Projekte die gleichen Rah- menbedingungen haben, ist die Anpassung bestehender Methoden notwendig. Erfolgt diese Adaptierung nicht, so kann es durch Einsatz ungeeigneter Methoden zu übermäßi- gem Aufwand kommen. Dieses hätte auf die Mitarbeiter eine demotivierende Wirkung und führt zu einer Qualitätsminderung. Ein weiterer Punkt ist die konsequente Auf- zeichnung der Entwicklungsdokumentation, in Verbindung mit der Berichterstellung für das Management. So stehen Informationen über den Projektverlauf aus Sicht der Qualitätssicherung zur Verfügung.

Unter organisatorischen Maßnahmen wird hauptsächlich der Einsatz eines Vorgehensmodells verstanden. Das Modell gibt zum größten Teil den Prozess vor. Dieses Modell wird an die Unternehmensstruktur und das Projekt angepasst. Des Weiteren wird die kontinuierliche Weiterbildung der Entwickler als organisatorische Maßnahme gewertet. Ein Unternehmen ist grundsätzlich an Qualitätssicherung durch Akkumulation von Wissen und Erfahrung interessiert. Um dieses Ziel zu erreichen, ist es sinnvoll, den Mitarbeitern durch Aufstiegsmöglichkeiten Anreize zu signalisieren.

Zu den analytischen Maßnahmen gehört die Überprüfung der internen Abläufe und der lokalen Vereinbarungen. Neben der Aufstellung der internen Arbeitsweise wird ihre korrekte Einhaltung überprüft. Sollten sich bei den Mitarbeitern diesbezüglich Defizite einstellen, so sind diese durch Schulungsmaßnahmen zu beseitigen. Gemessen werden in diesem Zusammenhang die Daten der Technik und des Managements. Anhand von zuvor aufgestellten Merkmalen wird die Grundlage für die Beurteilung des Entwicklungsprozesses geschaffen. Der Entwicklungsprozess kann mit einem Audit einer Bewertung unterzogen werden. Hierunter wird die Beurteilung des Prozesses durch externe Prüfer verstanden. Im Hinblick auf eine Zertifizierung des Unternehmens kann so die Einhaltung der Vorgabe eines Qualitätsstandards bewertet werden. Mögliche Standards sind die Normen der ISO 9000 Gruppe, Spice und CMMI.

Feststellungsmethoden

In der Qualitätssicherung sind Tests, Reviews und Audits vorhanden. Sie sind Me- thoden mit denen Aussagen über den Zustand der Qualität getroffen werden können (vgl. [Zus04], S.154). Sie finden im ganzen Projektverlauf Anwendung und sind nicht auf einen bestimmten Abschnitt beschränkt. Mit ihnen sollen Fortschritte im Projekt bewertet werden.

Bei den Tests handelt es sich um Methoden, die hauptsächlich bei der Überprüfung von Quellcode Anwendung finden. Hierzu ist die Beschreibung von Testfällen erforderlich, die in einem Funktionsbereich eintreten können. Festzuhalten ist in diesen Fällen auch das gewünschte Verhalten nach einer Eingabe oder einer Aktion. So kann eine Abwei- chung vom zu erwartenden Ergebnis der näheren Betrachtung unterzogen werden. Der Quellcode ist anschließend so anzupassen, dass das Ergebnis dem gewünschten Verhal- ten entspricht.

Reviews stellen Methoden dar, mit denen die Qualität von Prozessen aber auch Pro- dukten verbessert werden kann. Reviews werden dann vorgenommen, wenn die Güte mit Hilfe von Tests nicht beurteilt werden kann. Es bietet sich an ein Review Team aufzustellen. So können die einzelnen Mitglieder in einem festgelegten Ablauf notwen- dige Rollen übernehmen. Das Review wird von einem Moderator geleitet. Dieser wacht über die Kommunikationsdisziplin und den Fortschritt im Gespräch. Der verantwortli- che Urheber des Artefaktes über das gesprochen wird, ist ebenfalls anwesend und steht für Fragen zur Verfügung. Anregungen die das Produkt verbessern können, werden von ihm aufgenommen. Diese gilt es im Anschluss einzubringen und den Beteiligten zu einer erneuten Prüfung zur Verfügung zu stellen. Es gilt konstruktive Vorschläge einzuarbeiten, um die Güte der Qualität zu steigern.

[...]