Sei11 0118K07

Studienheft
SEI11
Phasenmodelle und Planung von 

Softwareprojekten
0118K07
Das Studienheft und seine Teile sind urheberrechtlich geschützt.
Jede Nutzung in anderen als den gesetzlich zugelassenen Fällen
ist nicht erlaubt und bedarf der vorherigen schriftlichen
Zustimmung des Rechteinhabers. Dies gilt insbesondere für das
öffentliche Zugänglichmachen via Internet, Vervielfältigungen und
Weitergabe. Zulässig ist das Speichern (und Ausdrucken) des
Studienheftes für persönliche Zwecke.
$
SEI11
Phasenmodelle und Planung von

Softwareprojekten
0118K07
Prof. Dr. Peter Zöller-Greer

©
Werden Personenbezeichnungen aus Gründen der besseren Lesbarkeit nur in der männlichen oder
weiblichen Form verwendet, so schließt dies das jeweils andere Geschlecht mit ein.
Falls wir in unseren Studienheften auf Seiten im Internet verweisen, haben wir diese nach sorgfältigen
Erwägungen ausgewählt. Auf die zukünftige Gestaltung und den Inhalt der Seiten haben wir jedoch
keinen Einfluss. Wir distanzieren uns daher ausdrücklich von diesen Seiten, soweit darin rechtswid-
rige, insbesondere jugendgefährdende oder verfassungsfeindliche Inhalte zutage treten sollten.
© HfB, 02.12.20, Berk, Eric (904709)
Phasenmodelle und Planung von Softwareprojekten

SEI11
Inhaltsverzeichnis
0118K07
Vorwort ....................................................................................................................... 1
1 Einleitung .................................................................................................................. 3
1.1 Lebenszyklus einer Softwareentwicklung ................................................ 3
1.2 Methodische Ansätze und grundlegende Definitionen ........................... 5
Zusammenfassung .................................................................................................... 7
Aufgaben zur Selbstüberprüfung ............................................................................ 7
2 Phasenmodelle ......................................................................................................... 8
2.1 Klassisches Wasserfallmodell ..................................................................... 9
2.2 Spiralmodell ................................................................................................. 19
2.3 V-Modell ...................................................................................................... 21
2.4 Diamantmodell ............................................................................................ 24
2.5 Neuere Methoden ........................................................................................ 27
3 Softwareergonomie ................................................................................................. 34
3.1 Definition und Rechtsgrundlagen ............................................................. 34
3.2 Softwareergonomische Dialoggestaltung ................................................. 37
3.3 Praktische Anwendungen .......................................................................... 41
Aufgabe zur Selbstüberprüfung ............................................................................... 45
4 Planung eines Softwareprojekts ............................................................................ 47

4.1 Erste Analyse des Problems ....................................................................... 47
4.2 Verfeinerte Analyse des Problems: Erstellung des Pflichtenhefts .......... 49
4.2.1 Analyse Ist-/Sollzustände ........................................................................... 51
4.2.2 Semantische Datenmodellierung ............................................................... 60
4.2.2.1 Entscheidungstabellen ................................................................................ 60
4.2.2.2 Data Dictionary ........................................................................................... 63
4.2.2.3 Entity Relationship Diagram ..................................................................... 64
4.2.2.4 Objektorientierte Analyse und Design ..................................................... 66
4.2.3 Projektplan ................................................................................................... 80
0118K07
SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Inhaltsverzeichnis
Anhang
A. Lösungen der Aufgaben zur Selbstüberprüfung ....................................... 81
B. Literaturverzeichnis ..................................................................................... 84
C. Abbildungsverzeichnis ................................................................................ 85
D. Sachwortverzeichnis .................................................................................... 87
E. Einsendeaufgabe .......................................................................................... 89
SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Vorwort
SEI11Phasenmodelle und Planung von Softwareprojekten0118K07
Spätestens seit der Softwarekrise der 60er-Jahre ist der Ruf nach besser planbarem, sys-
tematischerem Vorgehen laut geworden. Nach und nach hat sich daraus das heutige
Software Engineering entwickelt. Weitgehend standardisiert, liefert es für alle an der
Entwicklung Beteiligten methodische Ansätze zur effektiven und ökonomischen Soft-
wareerstellung. Obwohl Software in der Regel nur recht kurzlebig ist, haben sich erst in
jüngerer Zeit die Methoden zu ihrer Erzeugung stabilisiert. Noch vor wenigen Jahren
standen viele verschiedene Ansätze in Konkurrenz, doch mit der Einführung der Unified
Modeling Language (UML) hat sich eine Methode etabliert, die alle anderen Konkurren-
ten weit hinter sich gelassen hat. Es besteht daher Aussicht, dass die beschriebenen Me-
thoden und Verfahren für die nächsten Jahre aktuell bleiben, da ihre Akzeptanz und Ver-
breitung sehr groß ist.
Software Engineering ist also eine selbstverständliche Methode zur effizienten Entwick-
lung von Programmen. Im Prinzip kann man zwei Arten Software unterscheiden: An-
wendungsprogramme und Steuerprogramme. Überlappungen sind möglich. Anwen-
dungsprogramme sind Programme, die von Usern benutzt werden können, die keine
tieferen DV-Kenntnisse besitzen. Sie müssen entsprechend benutzerfreundlich sein und
leicht bedienbar. Steuerprogramme dagegen bedürfen in der Regel keines Benutzers in
diesem Sinne, sondern sie laufen „von allein“ und steuern bestimmte (meist physikali-
sche) Systeme, z. B. einen Fahrstuhl.
Relativ unabhängig von dieser Unterscheidung sind die methodischen Ansätze bei der
Softwareentwicklung. Hier werden immer gewisse Entwicklungsphasen durchlaufen, in
denen systematisch Teilschritte realisiert werden, bis schließlich das fertige Produkt vor-
handen ist. Das vorliegende Heft deckt den ersten Teil dieser Entwicklungsphasen ab,
nämlich im Wesentlichen die Planung des Softwareprojekts. Zu diesem Zweck wird
nach einer Einleitung in die Problematik der Softwareentwicklung (Kapitel 1) einiges
über Phasenmodelle gesagt, es werden die wichtigsten dieser Modelle vorgestellt
(Kapitel 2). Kapitel 3 widmet sich den Erfordernissen der Softwareergonomie, und in
Kapitel 4 wird schließlich die Planungsphase eines Softwareprojekts genau durchleuch-
tet und es werden einige methodische Ansätze aus diesem Bereich beschrieben.
Der Planung kommt überhaupt eine grundlegende Bedeutung zu. Viele Softwareprojek-
te scheitern an unzureichender Planung. Es kann gar nicht oft genug darauf hingewiesen
werden, dass eine gute Planung das A und O des erfolgreichen Gelingens einer Syste-
mentwicklung ist. So wie ein Architekt zuerst den „Blueprint“ eines Bauvorhabens er-
stellt und Bauarbeiter nicht einfach drauflosmauern, so muss ein Softwareentwickler ei-
nen „Bauplan“ für das Anwendungsprogramm erstellen. Fehler in den Bauplänen
können sowohl für Hausbauer als auch für Softwareentwickler je nach Schwere glei-
chermaßen katastrophal sein. Deshalb kommt dem Fach Software Engineering eine so
wichtige Bedeutung zu.
Viel Erfolg beim Durcharbeiten dieses Heftes!
SEI11 1
© HfB, 02.12.20, Berk, Eric (904709)
2 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
1 Einleitung
Dieses Kapitel beschäftigt sich mit der Geschichte des Software Engineering so-
wie dessen Grundprinzipien. Sie sollen nach Durcharbeiten dieses Kapitels in der
Lage sein,
• die Probleme der Softwarekrise zu nennen,
• den Lebenszyklus eines Softwareentwicklungsprojekts zu beschreiben,
• methodische Ansätze zur Lösung der Probleme bei der Softwareentwicklung
zu nennen.
Es wird außerdem eine Definition von Software Engineering gegeben sowie
dessen Abdeckungsbereich untersucht.
1.1 Lebenszyklus einer Softwareentwicklung

In den 60er-Jahren des 20. Jahrhunderts verbreiteten sich Computer in vielen
Industrieunternehmen. Dabei steckte jedoch die systematische Entwicklung darauf lau-
fender Software noch in den Anfängen. Software wurde normalerweise in einem zent-
ralen Rechenzentrum für umliegende Fachabteilungen von einem Spezialistenteam ent-
wickelt. Wobei hier der Ausdruck „Team“ nicht unbedingt bedeutet, dass mehrere
Personen am gleichen Projekt zusammenarbeiteten, sondern es war häufig so, dass jeder
Programmierer ein Programm komplett entwickelte oder zumindest einen abgegrenzten
Programmteil, der relativ isoliert war. Hinzu kam die Tatsache, dass solche Programme
nicht in großem Umfang geplant wurden, sondern die Programmierer legten häufig ein-
fach mit der Programmierung los. Und dies zudem noch, bevor genau klar war, was
überhaupt der spätere Benutzer wollte. Dieses relativ unsystematische Vorgehen erzeug-
te natürlich hohen Entwicklungsaufwand und damit auch Unsicherheit hinsichtlich der
Kosten und der Entwicklungsdauer.
Es wurde schon bald die Notwendigkeit einer besseren Planung von Software erkannt
und man begann, sogenannte Pflichtenhefte zu schreiben. Diese enthielten mehr oder
weniger präzise die jeweiligen Anforderungen an die zu entwickelnde Software. Aufbau
und Form solcher Pflichtenhefte unterlagen allerdings keinem bestimmten Standard,
und es war dem jeweiligen Autor überlassen, wie genau das Problem und eventuelle Lö-
sungen beschrieben wurden.
Man ging zu dieser Zeit auch dazu über, die Planung der Software von ihrer Codierung
zu trennen. Sogenannte Systemanalytiker hatten die Aufgabe, das Problem zu analy-
sieren und eine algorithmische Lösung zu entwickeln, die dann einem Programmierer
zum Zweck der Codierung übergeben wurde. Im kommerziell-administrativen Bereich
waren dies auch tatsächlich verschiedene Personen. Im naturwissenschaftlich-techni-
schen Bereich dagegen wurden Systemanalyse und Programmierung häufig von ein und
derselben Person durchgeführt. Dies machte insofern Sinn, als hier die Probleme oft so
komplex waren, dass die Kommunikation zwischen Analytiker und Programmierer sehr
schwierig gewesen wäre.
Obwohl also einige Anstrengungen unternommen wurden, war der gesamte Entwick-
lungszyklus einer Software noch von vielen Unsicherheitsfaktoren begleitet. Abge-
schätzte Entwicklungskosten wurden regelmäßig erheblich überschritten, ebenso wie
die geplanten Entwicklungszeiten. Man fand heraus, dass dies in erster Linie an mangel-
SEI11 3
© HfB, 02.12.20, Berk, Eric (904709)
1 Einleitung
hafter Planung lag. Planungsfehler wurden oft erst sehr spät entdeckt und waren nur mit
erheblichem Aufwand zu korrigieren. Außerdem wiesen die Pflichtenhefte häufig In-
konsistenzen (Widersprüche) auf, die zunächst nicht bemerkt wurden. Diese Situation
bezeichnet man heute als die Softwarekrise der 60er-Jahre.
Es wurden viele Anstrengungen unternommen, um aus dieser Krise herauszukommen.
Es wurde z.B. zunächst versucht, die Planungsphase zu standardisieren, wobei ingeni-
eurwissenschaftliche Methoden als Vorbild dienen sollten. Die Grundidee war, besagte
Planungsphase systematisch zu erarbeiten und methodische Ansätze dafür zu entwi-
ckeln. Man erhoffte sich dadurch weniger Planungsfehler und eine Codierung, die Pro-
gramme lieferte, die die geforderten Spezifikationen so gut wie möglich erfüllten.
Entwicklungs-
aufwand
ideal
real
Zeit
Abb. 1.1: Lebenszyklus einer Softwareentwicklung
Abb. 1.1 stellt den idealen Lebenszyklus einer Softwareentwicklung dem seinerzeit rea-
len gegenüber. Im Idealfall steckt man den meisten Aufwand in die Planungsphase, so-
dass die sich anschließende Codierungsphase ohne großen Aufwand vonstattengeht und
auch keine wesentlichen Korrekturen erforderlich sind. Im Realfall dagegen war die Pla-
nungsphase nicht sonderlich intensiv durchdacht und die Codierung war demzufolge
fehlerhaft und korrekturanfällig. Die wohlbekannten Gesetze von Edward A. Murphy
finden leider auch hier ihre Anwendung.
Murphys Gesetze
• Alles dauert länger, als man denkt.
• Alles ist teurer, als man denkt.
• Alles ist komplizierter, als man denkt.
• Wenn ein Fehler passieren kann, dann passiert er auch.
(Murphy war Optimist.)
4 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Einleitung 1
Diese etwas scherzhafte Formulierung von Murphys Gesetzen weist auf die Pro-bleme
hin, die mit der Entwicklung von Software verbunden sein können.
1.2 Methodische Ansätze und grundlegende Definitionen

Die Softwarekrise der 60er-Jahre führte also zu der Notwendigkeit, Softwareapplikatio-
nen systematisch zu planen und zu entwickeln. Dies führte zu der wissenschaftlichen
Disziplin des Software Engineering. Allerdings ist es vor der genauen Definition dieses
Begriffs erforderlich, eine Abgrenzung der Schnittstellen vorzunehmen, auf die Soft-
wareentwicklung überhaupt bezogen wird.
Software kann immer nur einen Teil der Welt repräsentieren. Ein System ist eine An-
sammlung von Dingen, die genau abgrenzbar sind. Ein Softwaresystem ist demnach
eine genau definierte Ansammlung von Programmen, die durch den Computer von der
Umwelt und innerhalb des Computers von anderen Anwendungen klar abgegrenzt ist.
Ein solches System reagiert naturgemäß auf Eingaben durch Benutzer oder andere Sys-
teme. Und diese Reaktionen müssen vorhergesehen werden.
System mit geplanten Reaktionen

Unter einem System mit geplanten Reaktionen versteht man eine Menge von Regeln
oder Einheiten, die wohldefinierte Aktionen ausführen, auch wenn Ereignisse außerhalb
seines Einflussgebietes auftreten. Diese geplanten Reaktionen sind in einer symboli-
schen/formalen Sprache formulierbar.
Ergebnis Ergebnis
System mit externe
spontane System-
geplanten
Aktivität umgebung
Reaktionen
Reaktionen Reaktionen
Abb. 1.2: System mit geplanten Reaktionen
Ein System mit geplanten Reaktionen fängt also alle Reaktionen seiner Umgebung in
kontrollierter Weise ab. Stellt ein System z. B. ein Anwendungsprogramm auf einem
Rechner dar, also einen Ausschnitt aus der Realität, der DV-technisch mit einem entspre-
chenden Programm abgebildet wird, dann ist insbesondere die I/O-Schnittstelle eine
Quelle möglicher Probleme. Das kann z. B. eine unsinnige Tastenkombination auf der
Tastatur des Computers sein, während das Anwendungsprogramm läuft. Auf keinen
Fall darf es dann zum Absturz des Programms kommen, sondern es muss eine kontrol-
lierte Reaktion des Systems erfolgen.
Dies zu erreichen klingt zunächst einfacher, als es ist, denn meistens ist es schwierig, alle
Eventualitäten „vorherzudenken“. Deswegen ist z. B. auch der Programmieraufwand für
Plausibilitätsüberprüfungen einer Maskeneingabe häufig der aufwendigste Teil der je-
weiligen Maskenprogrammierung. Natürlich sind geplante Reaktionen auch in Rechen-
algorithmen zu berücksichtigen, beispielsweise muss eine mögliche Eingabe, die zur Di-
vision durch die Zahl Null führt, abgefangen werden.
Benutzen wir also zukünftig den Begriff Software, so wird nachfolgend immer davon
ausgegangen, dass es sich dabei um Systeme mit geplanten Reaktionen handelt.
SEI11 5
© HfB, 02.12.20, Berk, Eric (904709)
1 Einleitung
Dies ist allerdings noch lange nicht ausreichend, um effiziente Software zu entwickeln,
denn es sind weitere Probleme damit verbunden, die systematisch gelöst werden müs-
sen. Einige dieser Probleme sind:
• Komplexe Anforderungen sind oft schwer zu verstehen.
• Softwareentwicklung erfordert absolute Präzision, ein hohes Maß an Kreativität, Er-
fahrung im Entwickeln komplexer Programme und echtes Teamwork.
• Unter Stressbedingungen kann die Fehlerrate ansteigen.
• Es ist eine hohe Qualifikation der Mitarbeiter erforderlich.
An einen Entwickler werden zudem noch gewisse spezifische Anforderungen gestellt,
wie z. B. die Fähigkeit, Wichtiges von Unwichtigem zu trennen, oder die richtige Ein-
schätzung der Komplexität einer Anforderung.
Um komplexe und aufwendige Anforderungen einer systematischen Lösung zuführen
zu können, sind drei wichtige Prinzipien einzuhalten:
1. die Modellierung der Realität durch Abstraktion,
2. die Reduktion der Komplexität durch Strukturierung und
3. Fokussierung auf die Lösung von Teilproblemen.
Es gibt computergestützte Hilfsmittel zur Durchführung dieser Aufgaben, die man all-
gemein CASE-Tools nennt (CASE = Computer Aided Software Engineering). Es wird
dringend empfohlen, solche Tools wann immer möglich einzusetzen. Diese Werkzeuge
sind in der Lage, schon bei der Planung und dem Entwurf der Anwendung Inkonsisten-
zen zu entdecken. Dadurch reduziert sich die Fehlerrate beträchtlich. Außerdem können
viele dieser Tools das Planungsergebnis direkt in ein relationales oder objektorientiertes
Datenbankschema umsetzen und erzeugen so z. B. physikalische Tabellenstrukturen.
Nachfolgend soll nun eine allgemeine Definition des Begriffs Software Engineering ge-
geben werden.
Software Engineering
Unter Software Engineering versteht man die Wissenschaft, effiziente Software auf der
Basis ingenieurmäßiger Methoden und ökonomischer Gesichtspunkte zu entwickeln. Sie
umfasst die strukturierte Analyse, den Entwurf und die Realisierung sowie das Testen
und Warten eines Programms mittels methodischer Ansätze.
Bis zu den 80er-Jahren des 20. Jahrhunderts unterteilte man die Entwicklung eines Soft-
waresystems zunächst nur in die zwei Phasen Systemanalyse und Programmierung. Die
Systemanalyse umfasste damals die Problembeschreibung, die Beschreibung des Ist-
und Sollzustandes, die Input-/Output-Beschreibung des gewünschten Systems, einen
Projektplan, ein semantisches Datenmodell, ein logisches Datenmodell, Datenflussdia-
gramme/Programmstruktogramme und ein Lösungskonzept. Die sich daran anschlie-
ßende Programmierung beschäftigte sich mit der eigentlichen Codeerzeugung, ggf. ei-
nem „Tuning“ des Codes sowie schließlich dem Test und der Wartung der Software.
6 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Einleitung 1
Diese beiden Phasen sind heute allerdings nur Teile detaillierterer Phasenmodelle und
umfassen demzufolge auch nicht mehr alle oben genannten Komponenten, sondern die-
se sind ausgelagert und in andere, eigene Entwicklungsphasen integriert.
Gelegentlich wird eine Unterteilung des Software Engineering in zwei Komponenten
vorgeschlagen:
1. Konstruktionssystematik
Darunter versteht man die Ansammlung der benutzten Methoden, Werkzeuge und
Ergebnisse.
2. Produktionssystematik
Diese beschreibt die Entwicklungsschritte, deren Reihenfolge, gesetzte Termine so-
wie die anfallenden Kosten.
Es sei darauf hingewiesen, dass diese zwei Komponenten nichts mit den Phasen des Soft-
ware Engineering zu tun haben! Die Phasen fließen eher in die zweite Komponente ein,
während die erste einfach die Betriebsmittel zu ihrer Durchführung bereitstellt.
Diese Zweiteilung ist allerdings nicht unbedingt erforderlich, da die angewendeten Be-
triebsmittel entweder gewissen Standards entsprechen oder, falls nicht, in den jeweili-
gen Phasen beschrieben werden.
Die Lösung der Probleme der Softwarekrise des letzten Jahrhunderts erhoffte man sich
also durch Phasenkonzepte. Der Entwicklungszyklus einer Anwendung wird in einzelne
Phasen unterteilt und jede Phase enthält genau definierte Eingaben, Ausgaben und Tä-
tigkeiten. Man unterscheidet dabei zwischen linearen und nichtlinearen Phasenmodel-
len. Bei linearen Phasenmodellen muss eine Phase vollständig abgearbeitet sein, bevor
die nächste Phase begonnen werden kann. Bei nichtlinearen Phasenmodellen ist das
nicht so; hier können einzelne Phasen auch mehrmals durchlaufen werden, ohne immer
vollständig abgeschlossen zu sein. Solche Phasenmodelle sind Inhalt des nächsten Kapi-
tels.
Zusammenfassung
In diesem Kapitel wurden grundlegende Definitionen zum Software Engineering ange-

geben und die historische Entwicklung skizziert.
Aufgaben zur Selbstüberprüfung
1.1 Zeigen Sie auf, wo das systematische Vorgehen des Software Engineering seine
Wurzeln hat und welche Parallelen es auf anderen Gebieten, z. B. den Ingenieur-
wissenschaften, hat.
1.2 Es seien zunächst die beiden Unterteilungen des Software Engineering „Planung“
und „Realisierung“ einer Softwareentwicklung betrachtet. Kommentieren Sie da-
mit Abb. 1.1, indem Sie die unterschiedlichen Kurven („ideal“ und „real“) quanti-
tativ den beiden Unterteilungen zuordnen.
SEI11 7
© HfB, 02.12.20, Berk, Eric (904709)
2 Phasenmodelle
In diesem Kapitel werden einige der gängigen Phasenmodelle gezeigt. Es werden
die Vor- und Nachteile dieser Modelle sowie ihr Einsatzbereich erläutert. In der
Praxis sind viele Modelle im Einsatz, sodass wir uns hier nur auf die wichtigsten
beschränken.
Nach Durcharbeiten dieses Kapitels sollen Sie insbesondere folgende Kenntnisse
und Fertigkeiten besitzen:
• den Sinn und Zweck von Phasenmodellen aufzeigen
• die Phasen des klassischen Wasserfallmodells nennen und inhaltlich be-
schreiben
• das Spiralmodell nach Boehm beschreiben und dem Begriff des Prototypings
zuordnen
• das V-Modell beschreiben
• das Diamantmodell erläutern
• agile Methoden nennen
Die große Unsicherheit hinsichtlich Kosten und Entwicklungszeiten komplexer Soft-

ware wurde durch ingenieurmäßige Planung und methodische Ansätze allmählich we-
sentlich reduziert. Natürlich gab es auch früher schon effizient entwickelte Software,
aber dies war häufig von der Erfahrung und der individuellen Planungsfähigkeit der be-
teiligten Entwickler abhängig. Bevor ein Entwickler solche Fähigkeiten erworben hatte,
waren oft längst einige Projekte „in den Sand gesetzt“ worden und hatten sehr hohe Kos-
ten erzeugt.
Damit nun nicht immer wieder die gleiche bittere Erfahrung bei jeder Programm-
entwicklung neu gemacht werden musste, vor allem dann, wenn unerfahrene Program-
mierer ans Werk gingen, ergab sich mehr und mehr die Notwendigkeit einer methodi-
schen Vorgehensweise, gerade und vor allem in der Planungsphase von Software.
Möchte beispielsweise jemand ein Haus bauen, so beauftragt er ja auch nicht direkt ei-
nen Maurer, der dann ohne Plan drauflosmauert und dauernd den Kunden danach fragt,
ob es so oder so gerade recht ist. Gefällt es dem Kunden nicht, müssen halt ein paar Mau-
ern wieder eingerissen und von Neuem gebaut werden. Bis ein Haus schließlich, wenn
überhaupt jemals, den Vorstellungen des Kunden entspräche, wäre sicher viel Zeit und
Geld verbraucht. Aus diesem Grund gibt es Architekten, die zuerst einmal mit dem Kun-
den zusammen eine Planung durchführen. Erst wenn diese zur Zufriedenheit des Kun-
den abgeschlossen ist, wird normalerweise ein Auftrag zum Bau eines Hauses erteilt.
Was aber beim Hausbau selbstverständlich erscheint, setzte sich bei der Softwareent-
wicklung erst langsam durch. Dort war in der Tat in den 60er-Jahren (und auch später
noch) ein mit dem geschilderten „Drauflosmauern“ vergleichbares „Drauflosprogram-
mieren“ nicht unüblich, was die genannten hohen Kosten und Entwicklungszeiten zur
Folge hatte. Deswegen ist – wie beim Hausbau – eine Unterteilung der durchzuführen-
den Aufgaben in überschaubare Phasen notwendig.
8 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Phasenmodelle 2
2.1 Klassisches Wasserfallmodell

Erste methodische Ansätze in einer Unterteilung des Entwicklungsprozesses bestanden
in lediglich zwei Phasen: der Systemanalyse und der Programmierung. Dies entspricht
bei der Errichtung eines Hauses einer groben Einteilung in die zwei Phasen Planung und
Realisierung. Man musste jedoch schon bald feststellen, dass eine subtilere Unterteilung
erforderlich war. Innerhalb dieser beiden groben Phasen traten nämlich noch zu viele
Fehlerquellen auf, die dann aber durch weitere Systematisierung der einzelnen Arbeits-
schritte beseitigt werden konnten. Eine bis heute noch oft erfolgreich anwendbare Sys-
tematisierung ist das klassische Wasserfallmodell. In der Literatur findet man manchmal
Abweichungen hinsichtlich der Anzahl und des Inhalts der einzelnen Phasen, doch im
Prinzip handelt es sich immer um folgende Einteilung:
Initialisierung
DV-Konzept
DV-Entwurf
Rückkopplungen Implementierung
(unerwünscht)
Test
Installation
Wartung
Abb. 2.1: Wasserfallmodell
Das Wasserfallmodell zählt zu den linearen Phasenmodellen. Das heißt, eine Phase kann
erst begonnen werden, wenn die davorliegende vollständig beendet ist. Wir schauen uns
jetzt die einzelnen Phasen genauer an.
Phase 1: Initialisierung
Die Initialisierungsphase startet das geplante Entwicklungsprojekt. In der Regel wird da-
mit begonnen, dass ein Unternehmen das geplante Projekt ausschreibt oder sich direkt
an ein Softwareentwicklungsunternehmen wendet mit der Bitte um eine Angebotser-
stellung. Zur Erstellung eines Angebotes ist es natürlich erforderlich, dass eine erste
Analyse des Problems erfolgen muss, aus dem die notwendige Information für das An-
gebot ableitbar ist. Ein Problem des angebotserstellenden Unternehmens ist dabei, dass
einerseits ein detailliertes Angebot erst erfolgen kann, wenn hinreichende Informatio-
nen über das Projekt vorliegen, und andererseits eine solche erste Problemanalyse be-
SEI11 9
© HfB, 02.12.20, Berk, Eric (904709)
2 Phasenmodelle
reits recht arbeitsaufwendig werden kann, je nachdem, welchen Umfang das geplante
Projekt haben soll. Lehnt der Kunde das Angebot ab, ist die für die erste Analyse inves-
tierte Zeit verloren. Deshalb wird ein Entwickler zunächst eine recht grobe Analyse
beim Kunden vornehmen, die aber trotzdem eine erste Kostenabschätzung sowie eine
erste zeitliche Abschätzung des Projektverlaufs möglich macht.
Eine sich mittlerweile immer mehr verbreitende Variante ist, dass sich ein Softwareent-
wicklungsunternehmen bereits die Angebotserstellung bezahlen lässt. Dies ist insbeson-
dere im Bereich Multimediaprojekte der Fall, z. B. bei der Entwicklung von E-Com-
merce-Anwendungen. Dies liegt u. a. daran, dass in diesem Bereich ein strukturiertes,
methodenbasiertes Vorgehen in Ermangelung geeigneter Modelle kaum zu finden ist.
Deshalb wird schon für eine Angebotserstellung oft eine umfangreiche Detailanalyse er-
forderlich, und dieser Aufwand muss dann auch honoriert werden. Der Kunde hat aber
auch einen Vorteil von dieser Vorgehensweise, denn er hat dann eine ausführliche Ana-
lyse des Entwicklers vorliegen, die er – selbst wenn er das Angebot ablehnt – weiterver-
werten kann (diese kann er z. B. einem anderen Systementwickler zur Verfügung stel-
len).
Die Initialisierungsphase enthält in jedem Fall mindestens folgende Punkte:
• Problembeschreibung, in der Zweck und Rechtfertigung für das geplante
Unterfangen genannt wird
• Projektziele (gewünschtes Ergebnis des Projekts)
• grobe Projektbeschreibung: welche bereits installierte Hard- und Software ist vor-
handen, welche zusätzliche Hard- und Software muss angeschafft werden, sind
Netzwerkkomponenten erforderlich etc.
• grober Projektplan, der eine personale und zeitliche Aufwandsplanung und erste
grobe Projektorganisation enthält
• Kostenabschätzung
• Angebot an den Kunden
Den Kunden interessiert dabei natürlich in erster Linie, was die Durchführung des Pro-
jektes kostet und wie lange die Entwicklungszeiten sind. Diese dürfen also auf gar kei-
nen Fall fehlen.
Eine zuverlässige Aufwands- und Kostenabschätzung birgt jedoch die größte Problema-
tik. Kunden bevorzugen in der Regel Festpreise, aber gerade die setzen eine realistische
Kostenabschätzung voraus und wie beschrieben würde das eine intensive Problemana-
lyse erfordern. Erfahrene Entwickler haben hier deutliche Vorteile, da sie oft ein recht
sicheres Gefühl für Art und Umfang anstehender Entwicklungsaufgaben haben.
Falls Festpreise gewünscht sind, dann ist es in jedem Fall ratsam, einen geeigneten Puffer
für nicht vorhersehbare Fälle (vgl. Murphys Gesetze aus Kapitel 1, Seite 4) einzuplanen.
Manche Entwickler veranschlagen z. B. einen Faktor 2 für die Entwicklungskosten im
Angebot an den Kunden gegenüber dem zunächst tatsächlich abgeschätzten Aufwand,
vor allem dann, wenn viele Unsicherheiten hinsichtlich der Problemanalyse bestehen.
10 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Phasenmodelle 2
Wenn keine Festpreise erforderlich oder wenigstens nicht verbindlich sind, so kann ver-
einbart werden, dass eine genaue Aufwandsschätzung erst nach Abschluss der nächsten
Phase vorgelegt werden muss, also wenn das DV-Konzept vorliegt. In diesem Fall möch-
te der Kunde jedoch häufig wenigstens einen Kostenvoranschlag für die Erstellung des
DV-Konzepts haben, der dann im Angebot angegeben wird.
Eine andere Möglichkeit, die Unsicherheiten bei Festpreisen wenigstens zu mildern, be-
steht darin, dass ein Festpreis mit einer „Unsicherheitsspanne“ vereinbart wird. So kann
beispielsweise ein Festpreis von 25.000 € verhandelt werden, wobei ein Spielraum von
± 15 % möglich ist. Damit besteht ein Spielraum von 3.750 €, der ggf. noch auf den Fest-
preis aufgestockt werden kann. Natürlich wünscht der Kunde in der Regel dann auch
eine genaue Begründung für solche Zusatzkosten.
Die zeitliche Dauer der Initialisierungsphase sollte so gewählt werden, dass für den Soft-
wareentwickler kein zu hohes Risiko für den Fall entsteht, dass der Kunde das Angebot
ablehnt. Da diese Phase der Angebotserstellung dient und normalerweise nicht bezahlt
wird, sollte der Entwickler hier seine Zeit angemessen investieren. So sollten selbst bei
Projekten mit einer finanziellen Größenordnung von beispielsweise 50.000 € höchstens
14 Tage für die Initialisierungsphase investiert werden; ein Dilemma kann dabei sein,
dass man einerseits einen möglichst niedrigen Festpreis ansetzen möchte (um unterhalb
eventueller Konkurrenzangebote zu liegen) und andererseits gerade für eine knappe Kal-
kulation eine ziemlich ausführliche Problemanalyse benötigt, deren Erstellung wieder-
um zeitaufwendig ist. Hier muss der Entwickler ein ausgewogenes Verhältnis finden. So
etwas ist aber oft nur durch einige Erfahrung zu gewinnen.
Ein Ergebnis der Initialisierungsphase ist die Erstellung eines Angebots an den Kunden.
Nachfolgend ist ein Beispiel für ein solches Angebot zu sehen.
SEI11 11
© HfB, 02.12.20, Berk, Eric (904709)
2 Phasenmodelle
Supersoft AG 03.11.2014
Koboldweg 8
60321 Frankfurt am Main
Ventura & Co. KG

Abt. D
Herrn Ernst
Ernst-August-von-Halmackenreuther-Str. 10
43233 Kuhl
Angebot Entwicklung des Programms zur elektronischen Verwaltung von
Druckerzeugnissen
Sehr geehrter Herr Ernst,

Bezugnehmend auf Ihre Anfrage vom 22.10.2014 unterbreite ich Ihnen folgendes
Angebot:
Tätigkeit Aufwand (PT)
Problemanalyse und Erstellung eines Pflichtenhefts zur
Beschreibung der geplanten Anwendungsentwicklung 10
Entwurf der erweiterten Datenstrukturen und
Algorithmen/Funktionen gemäß dem erstellten Pflichtenheft 5
Implementierung der Software inkl. Modultes 5

Der Personentag wird mit 1.000,00 € abgerechnet.
Entwurfs- bzw. Implementierungsfehler, die unsererseits verursacht wurden, werden
innerhalb einer Anwendungstestphase durch Ihre Anwender bis zu vier Wochen nach
Programmübergabe von uns umgehend kostenfrei beseitigt.
Bei Auftragserteilung vor dem 10.11.2014 können die Arbeiten innerhalb von sechs
Wochen erledigt werden.
Ich hoffe, Ihnen mit diesem Angebot gedient zu haben.

Mit freundlichen Grüßen
Alfons Maurer, Geschäftsführer
Phase 2: DV-Konzept (Fachkonzept)

Diese Phase dient u. a. hauptsächlich zur Erstellung des „klassischen“ Pflichtenhefts. Die
in der Initialisierungsphase noch relativ groben Analysen müssen jetzt verfeinert wer-
den, sodass ein detailliertes Konzept entsteht, mittels dessen ein Programmentwickler
später seine Datenmodelle und Programmablaufpläne entwickeln kann.
Die Phase DV-Konzept (auch Fachkonzept oder Grobkonzept genannt) wird zumindest
teilweise von dem Systemanalytiker zusammen mit dem Kunden durchgeführt. Der
Kunde beschreibt dabei die Ausgangsverhältnisse und was das gewünschte Programm
später können soll. Dem Systemanalytiker kommt u. a. die Aufgabe zu, die „richtige“ In-
12 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Phasenmodelle 2
formation aus dem Kunden herauszuholen. Meistens kennt der Systemanalytiker das
Problemfeld des Kunden kaum, während der Kunde normalerweise nicht weiß, welche
Information für die genaue Systemanalyse wichtig ist. DV-Fachmann und Kunde müs-
sen daher einen gemeinsamen Ansatzpunkt finden. Grob unterteilt besteht ein Fachkon-
zept aus zwei Teilen, nämlich der Anforderungsanalyse, in der der Ist- und der Sollzu-
stand von Hard- und Software erarbeitet werden, und der Systemanalyse, in der eine
erste semantische Datenmodellierung vorgenommen wird. Letztere beschreibt, was
die Anwendung leisten soll, wie sie prinzipiell aufgebaut sein muss und wie das erreicht
werden kann. Das Ergebnis ist dann das Papier, das Pflichtenheft (je nach Sicht auch
manchmal Lastenheft) oder allgemein einfach nur Spezifikation genannt wird.
Im DV-Konzept wird damit also im Prinzip der Weg vom Istzustand zum Sollzustand in
einer für Kunde und Analytiker gleichermaßen verständlichen Sprache beschrieben. Da-
her ist das Pflichtenheft überwiegend verbal abgefasst und enthält wenig Abstraktionen.
Dies birgt jedoch die Gefahr, dass hier Inkonsistenzen entstehen können. Das heißt, es
könnte z. B. auf Seite 10 des Pflichtenhefts etwas stehen, was einer Anforderung auf Sei-
te 25 direkt widerspricht. Solche Widersprüche werden u. U. erst sehr spät bemerkt, im
ungünstigsten Fall erst beim Testen der Software. Dies führt dann zu den unerwünsch-
ten Rückkopplungen im Wasserfallmodell, denn es muss im Pflichtenheft eine Korrektur
gemacht werden, die alle nachfolgenden Phasen betreffen kann. So etwas ist dann meis-
tens auch relativ zeit- und kostenaufwendig.
Das Pflichtenheft sollte daher sehr genau und umsichtig entworfen werden. Manchmal
kann es hilfreich sein, hier sogar schon Elemente des DV-Entwurfs (z. B. ER- oder UML-
Diagramme) zu verwenden, sofern der Kunde in der Lage ist, diese zu verstehen.
Eine verbale Beschreibung von Daten und deren Zusammenhängen nennt man auch se-
mantisches Datenmodell.
Im Pflichtenheft sollten enthalten sein:
• (semantische) Modellierung der projektrelevanten Teilausschnitte der Realität
• Beschreibung des Istzustands, ggf. unter Zuhilfenahme von Organigrammen, Funk-
tionsabläufen und/oder bereits vorhandenen Datenmodellen
• Beschreibung des Sollzustands, ggf. unter Zuhilfenahme von Organigrammen,
Funktionsabläufen und/oder bereits vorhandenen Datenmodellen
• Beschreibung der Ein- und Ausgaben des zu entwickelnden Programms
• Beschreibung von Datenstrukturen (Länge und Art der Daten, z. B. Gleit- oder Fest-
kommazahlen, wie lang können maximal die jeweils abzuspeichernden Zeichenket-
ten sein)
• Beschreibung des Datenaufkommens, d. h. der Datenmengen, Datenherkünfte etc.
• Beschreibung des Wegs von der Dateneingabe zur Datenausgabe (macht beispiels-
weise dies im Istzustand bereits jemand „von Hand“, so ist diese Person zu befragen
und der genaue Funktionsablauf zu beschreiben; eventuelle Berechnungsformeln
etc. sind anzugeben)
• Beschreibung der geplanten Datenmanipulationsmöglichkeiten
SEI11 13
© HfB, 02.12.20, Berk, Eric (904709)
2 Phasenmodelle
• Angaben über die voraussichtlichen Zugriffshäufigkeiten und den Benutzerkreis

(wer greift wie oft ggf. mit welchen anderen Benutzern gleichzeitig auf welche Da-
tenbestände zu)
• Angaben zu Sicherheitsaspekten (ist z. B. ein nach Hierarchien abgestufter Zugriff
einzelner Benutzer erforderlich, dürfen manche Benutzer nur bestimmte Daten an-
sehen/ändern, Passwörter, Administratorzugänge etc.)
• Angaben zum Datenschutz (ist z. B. der Betriebsrat mit einzubeziehen)
• Beschreibung von möglichen Validierungsprozeduren (Planung von Validierungs-
tests, wer testet wann was wie lange etc.)
• detaillierter Projektplan (wer macht wann was), z. B. in der Form eines
Balkendiagramms
• Art und Umfang evtl. neu anzuschaffender Hardware/Software/Personal
• Festlegung von Review-Terminen und evtl. Zahlungsbedingungen
• Festlegung von Projektpersonal und Verantwortlichkeiten auf Kundenseite
Im Hinblick auf eine möglichst effiziente Systementwicklung sollte das Pflichtenheft so
ausführlich wie möglich sein. Hier zu sparen wäre ein großer Fehler (wegen der u. U. zu
erwartenden Rückkopplungen). Diese Phase zusammen mit der nächsten Phase (DV-
Entwurf) sollte mind. 70 % der geplanten Entwicklungszeit des gesamten Projekts betra-
gen. Was hier versäumt wird, kann ein Vielfaches an Zeit bei der Implementierung kos-
ten.
Das fertiggestellte Pflichtenheft sollte am besten sowohl vom Kunden als auch vom Sys-
temanalytiker unterschrieben und damit von beiden Seiten als verbindlich anerkannt
werden. Sollte es später zu einem Rechtsstreit vor Gericht kommen, so kann dadurch
eine Beweispflicht (egal von welcher Seite) u. U. erleichtert werden. Außerdem kann da-
mit einer möglichen „Salamitaktik“ des Kunden vorgebeugt werden: Wenn der Kunde
nach und nach immer weitere Wünsche äußert, kann der Systementwickler sich auf das
gemeinsam festgelegte Pflichtenheft berufen und darüber hinausgehende Kundenwün-
sche als zusätzliche Aufwendungen in Rechnung stellen. Der Umfang des Pflichtenhefts
kann bis zu mehreren Hundert Seiten betragen, je nach Projektgröße.
Das Pflichtenheft sollte so gestaltet sein, dass der Softwareentwickler im Prinzip keine
weiteren Angaben vom Kunden benötigt, um das Anwendungsprogramm zu entwerfen
und zu programmieren. In der Praxis kann es natürlich trotzdem sein, dass auch in spä-
teren Phasen bei eventuellen Unklarheiten oder Widersprüchen der Kunde konsultiert
werden muss, um die Probleme beseitigen zu können.
Nachfolgendes Beispiel enthält bereits eine recht detaillierte semantische Datenbe-
schreibung, wie sie manchmal erst in der Nachfolgephase DV-Entwurf zu finden ist.
Häufig verschwimmen die Grenzen zwischen diesen beiden Phasen. Spätestens jedoch
in der Entwurfsphase müssen alle Angaben genau spezifiziert sein, aber je mehr Anga-
ben im Pflichtenheft gemacht werden und je genauer sie sind, desto besser und präziser
kann die Entwurfsphase durchgeführt werden. Hier also ein Beispiel für einen Aus-
schnitt aus einem Pflichtenheft, wobei eine detaillierte verbale Beschreibung eines rela-
tiv komplizierten Sachverhalts vorgenommen wird.
14 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Phasenmodelle 2
… Zunächst werden die Felder mit den Inhalten aus der Tabelle A90UMW ge-
füllt, und zwar alle Datensätze, bei denen die Felder KU_ZE und/oder
KENZZGES gefüllt sind. Dazu die Folgedatensätze, bei denen die Felder TEL
noch gefüllt sind, aber nur bis zum nächsten gefüllten Feld KU_ZE und/oder
zum nächsten Telefoneintrag. Nun wird von der Tabelle BUERO_90 aus gear-
beitet. Alle Datensätze, die in den Feldern BURO_ART, GB_KURZ,
KFZ_KENN und/oder ANSPRECH ein Kurzzeichen enthalten, werden mit den
Feldern KU_ZE und KENZZGES auf Übereinstimmung geprüft, und zwar je-
des Feld, das gefüllt ist. Ist Übereinstimmung vorhanden, muss noch der Ort
überprüft werden. Dazu Feld ORT_ aus Tabelle BUERO_90 mit dem Ortsna-
men im Feld NAMSITZ ab der Zeile mit dem gefundenen Code im Feld KU_ZE
bis zum nächsten Eintrag im Feld KU_ZE und innerhalb derselben Blocknum-
mer prüfen. Wird auch hier Übereinstimmung gefunden, dann werden die
Felder aus BUERO_90 in die Tabelle ANSPRE übernommen, und zwar in die
Zeile, in der der Code steht. Wird zu einem Datensatz in der Tabelle
BUERO_90 keine Übereinstimmung gefunden, wird der Datensatz an das
Ende der Tabelle ANSPRE angehängt, und zwar für jedes ausgefüllte Codefeld
ein Datensatz, hinter jedem hinzugefügten Datensatz werden drei weitere
Zeilen mit dem Firmenkurzzeichen, einer Block- und Zeilennummer gefüllt
und der relevante Ansprechpartnercode wird in das Feld KU_ZE eingetragen.
Nach diesem Abgleich werden alle Datensätze, in denen die Felder KU_ZE
und/oder KENZZGES gefüllt sind, aber denen noch keine Adresse zugeordnet
ist, mit der Adresse der jeweiligen Gesellschaft gefüllt (Straße, PLZ und Ort,
Postfach, PLZ zum Postfach und Ort aus Tabelle gesell). Da es in der Gesell-
schaftstabelle zwei Datensätze geben kann, ist zu prüfen, ob unter NAMSITZ
innerhalb des Blocks ein Ort aufgeführt ist (Feld NAME=1). Ist kein Ort auf-
geführt, dann ist immer die Adresse aus dem Datensatz 1/2 zu nehmen. Ist
ein Ort aufgeführt und er stimmt mit der Adresse von Satz 2/2 überein, dann
ist diese Adresse zu nehmen, sonst wieder die Adresse von Satz 1/2. Nun ist
jedem Datensatz, der mit einer Adresse gefüllt ist, aber noch keinen Eintrag
im A90UMW-Teil der Tabelle hat (außer dem Gesellschaftskurzzeichen), über
die Beziehung zur vertansprech-Tabelle ein Ansprechpartner aus dieser Ta-
belle zuzuordnen. Ist nur ein Ansprechpartner vorhanden, wird dieser ge-
nommen.
Sind mehrere Ansprechpartner vorhanden, wird der Ansprechpartnercode
(Feld abt) in Tabelle vertansprech mit dem Code in KU_ZE verglichen. Bei
Übereinstimmung erfolgt die Übernahme der Inhalte der Felder funktion, an-
sprech, telefon (telefax, funktel, email jeweils in die nächsten Zeilen, die be-
reits angelegt wurden). Ist keine Übereinstimmung vorhanden, wird der Da-
tensatz mit der niedrigsten Zeilennummer genommen, in dem ein Name
eingetragen ist. Ganz zum Schluss müssen noch die Zeilen, die nur Gesell-
schaftskurzzeichen, Block- und Zeilennummern enthalten, gelöscht werden
…
SEI11 15
© HfB, 02.12.20, Berk, Eric (904709)
2 Phasenmodelle
Dieses semantische Datenmodell ist schon recht ausführlich und gibt bereits einige Vor-
schläge zur Implementierung. Das ist allerdings nicht immer so. Oft werden hier nur
Andeutungen gemacht, die dann erst im DV-Entwurf in dieser Detaillierungstiefe aus-
geführt werden. Doch die Faustregel, nämlich: „Je früher ins Detail gegangen wird, umso
besser“, sollte wann immer möglich angewendet werden.
Phase 3: DV-Entwurf
Die eigentliche Entwicklung des Anwendungssystems geschieht hier. Das Ergebnis wird
auch manchmal Feinkonzept genannt. Dabei spielt diese Phase die Rolle, die z. B. beim
Hausbau die Erstellung eines Bauplans, des „Blueprints“, spielt. So wie ein Architekt auf
dem Papier das zukünftige Haus plant (nach den Wünschen des Auftraggebers, bei uns
im Pflichtenheft niedergeschrieben), so plant der Entwickler in der Phase DV-Entwurf
die Einzelheiten der DV-Anwendung. Und ebenso wie beim Architekten ist das Ergebnis
auch in der Datenverarbeitung ein Bauplan im wahrsten Sinn des Wortes, der zum gro-
ßen Teil tatsächlich aus grafischen Elementen auf Papier, man könnte es ein Programm-
Blueprint nennen, besteht. Das Ergebnis dieser Phase ist also eine Programmspezifikati-
on, in der alle Einzelheiten beschrieben sind, die zur eigentlichen Programmierung des
Systems erforderlich sind. Dazu gehört übrigens auch eine detaillierte Planung von Test-
strategien zwecks Verifikation der entwickelten Programme. Diese Phase ist schwer-
punktmäßiger Gegenstand späterer Betrachtungen.
Phase 4: Implementierung
Wenn der Entwurf erfolgreich beendet ist, dann kann die Anwendung programmiert
werden. Diesen Vorgang nennt man Implementierung, da jetzt der Entwurf in codierter
Form auf den Computer gebracht wird. Je nach Anwendungsgebiet kann es sich dabei
um die berühmte „Knochenarbeit“ handeln, wenn z. B. ein Echtzeitsystem in C++ ge-
schrieben werden muss. Es kann aber auch sein, dass gar nicht viel im herkömmlichen
Sinne programmiert werden muss, sondern dass durch den geschickten Einsatz von
Werkzeugen vieles ohne Programmierarbeit erledigt werden kann. Gerade bei Daten-
bankanwendungen z. B. für betriebliche Informationssysteme sind sehr mächtige Tools
vorhanden. Im Idealfall kann der Programmcode sogar automatisch generiert werden.
Dazu ist es natürlich erforderlich, dass der DV-Entwurf hinreichend detailliert und for-
malisiert ist. Werkzeuge, die (fast) keine Programmierung mehr erforderlich machen,
sind ein hochaktuelles Forschungsgebiet des Software Engineering.
Die Vorgehensweise für die Implementierung ist im Allgemeinen „top-down“, d. h., es
werden zuerst die einzelnen Module geplant und diese dann jeweils verfeinert und im-
plementiert. Das Ergebnis der Phase Implementierung ist also ein ausführbares Pro-
gramm mit einer eventuell physikalisch implementierten Datenbasis. Auch diese Phase
wird erst später wieder genauer betrachtet.
16 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Phasenmodelle 2
Phase 5: Test
Der Implementierung des Programms folgt ein ausführlicher Test. Dabei sind zwei Test-
verfahren zu unterscheiden:
1) Programmtest
Hierunter versteht man den Test der einzelnen Programmmodule auf logische Kon-
sistenz und Übereinstimmung mit dem DV-Design. Dieser Test wird i. d. R. vom Pro-
grammierer selbst durchgeführt. Normalerweise beginnen diese Tests nicht erst am
Ende der Implementierungsphase, sondern bereits während der Codierung, d. h.,
während an den entsprechenden Modulen programmiert wird, werden auch gleich
die dazugehörigen Tests gemacht. Selbstverständlich wird nach Abschluss der Im-
plementierung noch einmal ein größerer Gesamttest durchgeführt, um das Zusam-
menspiel der einzelnen Module zu überprüfen und die Konsistenz mit dem DV-De-
sign festzustellen. Für diese Art des Testens gibt es kaum formale Methoden, da die
verschiedenen Möglichkeiten des Programmierstils einfach zu vielfältig sind. Als
Faustregel kann man allenfalls sagen, dass die Module jeweils für sich so weit wie
möglich ausgetestet werden sollten. Ist dies erfolgt, sollten einige zusammengehöri-
ge Module gemeinsam, d. h. deren Zusammenspiel, getestet werden. Man testet also
Gruppen von Modulen, bis schließlich das ganze Programm ausgetestet ist. Handelt
es sich z. B. um wissenschaftliche Anwendungen, so sollte eine verifizierbare Metho-
de im Voraus festgelegt werden. Soll ein Programm z. B. die numerische Lösung ei-
nes Differenzialgleichungssystems ermöglichen und sind dafür numerische Stütz-
stellen für eine Interpolations- oder Approximationsfunktion vorgesehen, so kann
ein sehr effektiver Test dadurch erfolgen, dass man einige der Stützstellen innerhalb
ihres Konvergenzintervalls leicht verschiebt. Damit hat man numerisch gesehen völ-
lig andere Zahlen als Input, aber das Ergebnis der Lösung müsste davon unabhängig
sein. Auch hilft es häufig, Extremfälle zu betrachten, deren Ergebnis im Voraus be-
kannt ist (z. B. triviale Fälle, wo alle Eingaben null sind).
2) Benutzertest
Ist das Programm durch den Programmtest als logisch richtig und fehlerfrei verifi-
ziert, muss ein Test unter Produktionsbedingungen erfolgen. Dieser Test kann zwar
auch vom Programmierer durchgeführt werden, es ist aber besser, wenn hier ausge-
wählte Benutzer testen. Wichtig ist dabei, dass keinesfalls schon echte Produktions-
prozesse gefahren werden, sondern es soll ja nur getestet werden in einer produkti-
onsidentischen Umgebung, aber nicht in der Produktion selbst. Es kann nämlich
hier noch zu folgenreichen Fehlern im Programm kommen, und das darf natürlich
nicht den Produktionsprozess behindern. Auch müssen die Benutzer, die diese Tests
durchführen, wissen, dass es sich hier um einen Test handelt, der u. U. zu unerwar-
teten Ergebnissen führen kann. Die Planung der Art und Weise dieser Tests sowie
der beteiligten Personen sollte bereits im Fachkonzept festgelegt werden.
Phase 6: Installation
Nach Abschluss der Testphase erfolgt die Installation der Anwendung in der Produkti-
onsumgebung. Es sollte dafür ein Zeitpunkt gewählt werden, der unkritisch für die lau-
fende Produktion ist. Das heißt, dass gleichzeitig keine kritischen Anwendungen dabei
laufen dürfen. Auch muss eine Datensicherung des Zielrechners vorhanden sein, sodass
ein Recovery möglich ist.
SEI11 17
© HfB, 02.12.20, Berk, Eric (904709)
2 Phasenmodelle
Mit der Übergabe des Anwendungsprogramms wird normalerweise eine Installations-

routine mitgeliefert, die es einem unbedarften Anwender ermöglicht, das Programm
nach Starten einer Setup-Routine gemäß den Anweisungen auf dem Bildschirm zu ins-
tallieren.
Bei kritischen Produktionsumgebungen oder sehr komplizierten Programmsystemen
kann es sinnvoll sein, einen Installationstest auf einem produktionsidentischen System
zu machen, bevor man auf dem tatsächlichen Zielrechner installiert.
Phase 7: Wartung
Normalerweise ist die Wartungsphase – jedenfalls bei hinreichend getesteten Program-
men – wenig arbeitsintensiv. Manchmal werden Schulungsmaßnahmen (Anwender-
schulungen etc.) vorgenommen, die aber gewöhnlich zeitlich begrenzt sind. Läuft das
Programm erst einmal richtig, so bleibt hier nicht mehr viel zu tun. Manchmal kann es
vorkommen, dass kleinere Fehler erst nach längerer Zeit entdeckt werden oder dass Pro-
grammerweiterungen gewünscht werden. Solche Fälle können als Teil eines Wartungs-
vertrages im Voraus abgedeckt werden. Erfolgt dies nicht, dann muss in diesen Fällen
ein neues Angebot erstellt und das Ganze wie ein neues Projekt behandelt werden.
Rückkopplungen im Wasserfallmodell
Angenommen, beim Benutzertest stellt sich heraus, dass eine Ausgabe nicht das ge-
wünschte Ergebnis liefert. Der Benutzer geht damit dann zum Programmierer. Wenn es
sich nun um keinen Programmierfehler handelt, so wird der Programmierer den „Pla-
ner“, d. h. denjenigen, der den DV-Entwurf erarbeitet hatte, ansprechen. Hat auch dieser
keinen Fehler bei der Planung gemacht, so wird er schließlich im Fachkonzept nach-
schauen und dort den Fehler lokalisieren können. Das Fachkonzept aber wurde zusam-
men mit dem Auftraggeber nach Erstellung „abgesegnet“, d. h. beide, Entwickler und
Auftraggeber, hatten das Fachkonzept als verbindlich abgezeichnet. Jetzt muss also das
Fachkonzept korrigiert werden. Daraufhin müssen die Phasen DV-Entwurf, Implemen-
tierung und Test erneut durchlaufen werden. Dieser Sachverhalt stellt die unerwünsch-
ten Rückkopplungen dar.
Wenn man Pech hat, kann dies alles sogar mehrmals geschehen. Es existiert die Mei-
nung, dass ein Fachkonzept mit mehr als 20 Seiten immer an irgendeiner Stelle wider-
sprüchlich ist. Aus diesem Grund ist es gerade bei umfangreicheren Projekten sinnvoll,
schon frühzeitig computergestützte Werkzeuge einzusetzen. Es gibt bereits hilfreiche
Tools für die Erstellung von Fachkonzepten, die gewisse Inkonsistenzen frühzeitig ent-
decken können. Solche Tools setzen allerdings voraus, dass die Spezifikation sehr genau
durchgeführt wird. Es ist klar, dass bedingt durch den linearen Verlauf der Phasen im
Wasserfallmodell Fehler erst sehr spät entdeckt werden. Zudem bekommt ein Anwen-
der erst zu einem sehr späten Zeitpunkt das erste Mal etwas von dem Anwendungspro-
gramm zu sehen, nämlich frühestens beim Benutzertest. Bis dahin ist aber schon der
Hauptanteil der Entwicklungszeit verbraucht. Bei größeren Entwicklungsprojekten
kann es durchaus sein, dass ein Anwender erst ein Jahr nach Auftragserteilung zum ers-
ten Mal etwas auf seinem Computer zu sehen bekommt. Das ideale Wasserfallmodell
(ohne Rückkopplungen) setzt also etwas voraus, was es eigentlich nicht gibt: ideale Auf-
traggeber, die zum Zeitpunkt der Auftragsvergabe haargenau wissen, was sie wollen
und was das Programm später können soll, und ideale DV-Entwickler, die völlig fehler-
frei arbeiten und ebenfalls alle möglichen Probleme vorausgedacht haben. So etwas gibt
18 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Phasenmodelle 2
es natürlich nicht. Deswegen hat sich nach und nach eine weitere Planungsmethode eta-
bliert, in der die Not des realen (rückgekoppelten) Wasserfallmodells (nämlich dessen re-
ale Nichtlinearität) zur Tugend gemacht wurde: das Spiralmodell. Diese Vorgehensweise
sei als Nächstes näher betrachtet.
2.2 Spiralmodell
Die unerwünschten Rückkopplungen im Wasserfallmodell und die mittlerweile weitver-
breiteten Werkzeuge zur relativ schnellen Gestaltung von Programmoberflächen haben
dazu geführt, dass sich neben dem klassischen Wasserfallmodell noch ein weiteres eta-
bliert hat: das Spiralmodell. Der Grundgedanke ist, dass nicht die einzelnen Phasen je-
weils beendet sein müssen, bevor die nächste Phase begonnen wird, sondern dass die
Phasen in kleinere Teilphasen zerlegt werden und diese zunächst begonnen werden. Es
werden also die großen Phasen immer nur teilweise bearbeitet und danach wird gleich
zur nächsten Phase übergegangen. Das Ergebnis ist ein mehrmaliges, stückweises
Durchlaufen aller Phasen, bis ein gewisser Reifegrad erreicht ist. Betrachtet man z. B.
nur die vier Hauptphasen Analyse, Entwurf, Implementierung und Test, so könnte eine
einfache Version des Spiralmodells wie in Abb. 2.2 skizziert aussehen.
Analyse Entwurf
Test Implementierung
Abb. 2.2: Vereinfachtes Spiralmodell
Boehm hat diese Idee seiner verfeinerten Version des Spiralmodells zugrunde gelegt. Der
Vorteil einer solchen Vorgehensweise liegt auf der Hand: Durch die sukzessive Entwick-
lung des Systems bekommt der Anwender schon relativ früh Teile des zukünftigen Pro-
gramms zu sehen und es können so Fehler auch früher erkannt und damit rechtzeitig
korrigiert werden. Die ersten Programmteile, die durch die ersten, inneren Spiralläufe
im Quadranten der Implementierung repräsentiert werden, nennt man auch Prototy-
pen. Sie stellen eine Art Programmhülle dar, wobei hier hauptsächlich nur die Benutzer-
oberflächen realisiert sind ohne wirkliche Anwendungen oder Funktionen hinter den
Schaltflächen.
SEI11 19
© HfB, 02.12.20, Berk, Eric (904709)
2 Phasenmodelle
kumulierte
Bestimmung von Zielen, Kosten Bewertung von Alternativen
Alternativen, Restriktionen Identifizierung und
Beseitigung von Risiken
Fortschritte Risikoanalyse
Risikoanalyse
Zustimmung
Risikoanalyse betriebs-
fähiger
Prototyp Prototyp
Risikoanalyse
P3
P2
P1
Start
Software- Software- Fein-

Anforderungsplan, Konzept für anforder- produkt- entwurf
Lebenszyklusplan den Betrieb ungsdefi- entwurf
nition
Modul-
codierung
Entwicklungs- Anforderungs-
plan prüfung
Modultest
Integration und Entwicklungs-
Testplan prüfung
Integration
und Test
Verbesserungs- Abnahmetest
plan und Einführung
Planung der nächsten Phase Entwicklung/Prüfung der
nächsten Produktstufe
Abb. 2.3: Spiralmodell nach Boehm
Eine alte Faustregel besagt, dass man für die endgültige Programmierung des Systems
alle Prototypen am besten wegwirft und den Zielzustand neu programmiert. Diese et-
was radikale Methode muss aber nicht immer angewendet werden, denn häufig liefert
das Prototyping recht brauchbare Programmmodule, die zumindest teilweise wieder-
verwendet werden können.
Das Spiralmodell birgt allerdings auch Nachteile. Insbesondere kann es dazu führen,
dass der Gesamtaufwand des Entwicklungsprojekts stark in die Höhe geht. Festpreise
sind bei so einer Vorgehensweise daher sehr gefährlich für den Entwickler. Leicht kann
es z. B. dazu kommen, dass der Anwender, wenn er die ersten Versionen der Prototypen
zu sehen bekommt, in Euphorie ausbricht und etliche Zusatzwünsche äußert, die so zu-
nächst im Budget gar nicht vorgesehen waren. Die Entwicklungsspirale kann so ins Un-
ermessliche wachsen, das Programm kommt nicht in der geplanten Zeit zum Abschluss.
In der Praxis erweist es sich daher häufig als sinnvoll, eine Kombination des klassischen
Wasserfallmodells mit dem Spiralmodell zu praktizieren. Die groben Planungen und das
Gerüst der Entwicklung sollten mit dem Wasserfallmodell gemacht werden, während
die Details dann nach dem Spiralmodell realisiert werden können.
20 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Phasenmodelle 2
2.3 V-Modell
Das V-Modell weist gewisse Ähnlichkeiten mit dem Wasserfallmodell auf. Es besteht
ebenfalls aus 7 Phasen, die linear angeordnet sind. Allerdings sind die Phasen anders ge-
gliedert und statt von oben nach unten sind sie v-förmig angeordnet 
(vgl. Abb. 2.4).
Spezifikation Validierung
Systementwurf Integrationstest
Komponentenentwurf Komponententest
Implementierung
Abb. 2.4: V-Modell
Der Entwicklungsverlauf beginnt links oben, geht dann nach unten und dann wieder
hoch und endet schließlich rechts oben. Dabei befinden sich auf dem absteigenden Ast
konstruktive Tätigkeiten, während auf dem aufsteigenden Ast Arbeitsschritte zur Qua-
litätssicherung vorhanden sind. Wie man sieht, wird zwischen dem Systementwurf und
dem Komponentenentwurf unterschieden. Diese Unterscheidung ist nicht ganz unprob-
lematisch, denn häufig sind die zu entwerfenden Komponenten bereits Teil des Systems.
Die Grenzen können hier also verwischen. Tendenziell kann man aber sagen, dass z. B.
UML-Diagramme eher in den Systementwurf und Funktionsablaufpläne eher in den
Komponentenentwurf gehören.
Es gibt mittlerweile eine Erweiterung des V-Modells, genannt V-XT. Gemäß der offizi-
ellen Dokumentation der Bundesrepublik Deutschland aus dem Jahr 20041 ist das V-Mo-
dell als Leitfaden zum Planen und Durchführen von Entwicklungsprojekten unter Be-
rücksichtigung des gesamten Systemlebenszyklus konzipiert. Die in einem Projekt zu
erstellenden Ergebnisse werden definiert und die konkreten Vorgehensweisen beschrie-
ben, mit denen diese Ergebnisse erarbeitet werden. Zusätzlich legt das V-Modell XT die
Verantwortlichkeiten jedes Projektbeteiligten fest. Es wird daher genau festgesetzt, wer
wann was in einem Projekt zu bewerkstelligen hat. Andere Richtlinien wie ISO-Stan-
dards sind zurzeit in Gebrauch, aber im Vergleich zum V-Modell XT weniger konkret,
da sie beispielsweise keine Produktvorlagen vorgeben.
Mit dem V-XT werden Projekte besser plan- und nachvollziehbar und erzielen zuverläs-
sige Ergebnisse von relativ hoher Qualität.
1. Vgl. https://www.cio.bund.de/Web/DE/Architekturen-und-Standards/V-Modell-XT/vmodell_xt_node.ht-
ml
SEI11 21
© HfB, 02.12.20, Berk, Eric (904709)
2 Phasenmodelle
Selbst kleine und mittelständische Unternehmen profitieren vom V-Modell. Es bietet ih-
nen die Möglichkeit, auf standardisierte und erprobte Vorgaben für Entwicklungs- und
Managementprozesse zurückzugreifen. So können auch kleinere Unternehmen mit
überschaubarem Aufwand ihre eigenen Vorgehensweisen systematisieren und dadurch
zuverlässig hochwertige Entwicklungsergebnisse erzielen. Das V-Modell dient somit als
Vertragsgrundlage, Arbeitsanleitung und Kommunikationsbasis.
Das V-Modell XT besteht vereinfacht betrachtet aus einem Kern und einem Mantel, der
auf den Kern zurückgreift. Im Kern sind die grundlegenden Prinzipien des Modells ent-
halten. Der Mantel umfasst beispielsweise die Vorgehensbausteine, Durchführungsstra-
tegien und Entscheidungspunkte.
Das V-Modell XT beschreibt drei Projekttypen:
• Systementwicklungsprojekt eines Auftraggebers: Es wird im Projektverlauf eine
Ausschreibung erstellt und dann ein Auftragnehmer anhand der Angebote ausge-
wählt. Der Auftragnehmer entwickelt und liefert ein System. Der Auftraggeber muss
das Ganze am Ende abnehmen.
• Systementwicklungsprojekt eines Auftragnehmers: Hier wird im Projektverlauf
ein Angebot erstellt und dann (im Fall eines Vertragsabschlusses) das angebotene
System entwickelt.
• Einführung und Pflege eines organisationsspezifischen Vorgehensmodells: Die-
ser Projekttyp liefert den Rahmen für ein organisationsweites Qualitätsmanagement
von Entwicklungsprojekten. Zuvor müssen ggf. die aktuellen Vorgehensweisen un-
tersucht werden.
Bei jeder Systementwicklung gibt es eigentlich zwei Projekte: eines auf der Auftragge-
berseite, das man als „Systementwicklungsprojekt eines Auftraggebers“ bezeichnen
könnte, und eines auf der Seite des Auftragnehmers mit dem Projekttyp „Systement-
wicklungsprojekt eines Auftragnehmers“. Diese beiden Projekte sind nicht voneinander
losgelöst, sondern über die Auftraggeber-Auftragnehmer-Schnittstelle miteinander ver-
knüpft.
Die Begriffe im V-Modell XT werden durch Konventionsabbildungen mit Begriffen in
(Quasi-)Standards, Normen und Vorschriften in Beziehung gesetzt. Das V-Modell bein-
haltet unter anderem Abbildungen auf die Standards CMMI und ISO 15288.
Der Einsatz des V-Modells XT in Projekten bietet folgende Vorteile:
• Minimierung der Projektrisiken
• Verbesserung und Gewährleistung der Qualität der Entwicklungsergebnisse
• transparente Beherrschung der Gesamtkosten über den gesamten Systemlebenszyk-
lus
• Verbesserung der Kommunikation für alle Beteiligten
22 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Phasenmodelle 2
Abb. 2.5: V-Modell XT (Quelle: http://www.software-kompetenz.de/servlet/is/26381/Abb4_large.jpg)
SEI11 23
© HfB, 02.12.20, Berk, Eric (904709)
2 Phasenmodelle
In Abb. 2.5 ist das V-Modell XT so dargestellt, dass im oberen Bildteil die jeweiligen
Phasen des „Auftraggeber-Projekts“ und im unteren Bildteil die des Auftragnehmer-Pro-
jekts“ sichtbar sind. Im mittleren Teil ist die Schnittstelle zwischen diesen beiden Projek-
ten zu sehen mit ihren Aktivitäten und Dokumenten.
Das V-Modell XT wird überwiegend (wie schon das V-Modell) im öffentlichen Dienst
eingesetzt.
2.4 Diamantmodell
Multimediaanwendungen stellen eine besondere Herausforderung für Entwicklungspla-
ner dar, denn hier sind teilweise künstlerische Elemente mit programmiertechnischen
verbunden. So findet die Integration von Sound (Sprache und Musik) und Bild (im Sinne
von Fotografien, Videoclips und Animationen) zunehmend statt. Die Verbreitung des In-
ternets trägt hier wesentlich bei. Eine Webseite, die nur aus reinem Text besteht, ist so
gut wie gar nicht zu finden. Die Vorteile solcher multimedialen (MME) Anwendungen
liegen auf der Hand: Der Mensch, der bekanntlich mehr Sinne besitzt als nur den Ge-
sichtssinn zum Lesen geschriebener Information, kann so pro Zeiteinheit gleichzeitig
mehr Information aufnehmen, wenn Bilder und Sprache mitgeliefert werden. Gerade im
pädagogischen Bereich (Lernprogramme etc.) ist dies eine große Hilfe.
Unabhängig von Ursachen und Zweck solcher multimedialer Anwendungen sind diese
jedenfalls stark verbreitet und die Tendenz ist rasant steigend. Die Verbreitung solcher
Applikationen geschieht schneller, als Ansätze und Konzepte für die Planung solcher
Systeme hinterherkommen. Dies führt zu ähnlicher Unsicherheit für die Entwickler wie
in den 60er-Jahren: Eine methodische Planung, Aufwandsschätzung und Durchführung
solcher Projekte ist oft nicht gegeben, was vor allem zu einer Kostenunsicherheit seitens
der potenziellen Auftraggeber solcher Multimediasysteme führt. Die Entwickler multi-
medialer Software sind somit an Entwicklungskonzepten interessiert, die in der Praxis
unkompliziert und effizient einsetzbar sind. Es sind Vorgehenskonzepte gewünscht, ähn-
lich wie z. B. beim Wasserfallmodell, die neben den Vorgehensabschnitten auch realisti-
sche Aufwands- und Ressourcenabschätzungen ermöglichen, und das möglichst ohne
das Studium dicker Bücher und das Verständnis darin beschriebener komplizierter Mo-
dellansätze.
Es ergibt sich also die Notwendigkeit, ein möglichst einfaches, in der Praxis einsetzbares
Phasenmodell zu haben, das die Planung des zeitlichen Aufwands, der technischen Res-
sourcen, des für die Entwicklung benötigten Personalaufwands und der Vorgehensweise
bei der Projektentwicklung und Durchführung liefert.
Für multimediale Systeme gibt es hier wenig Ansätze, jedenfalls kaum welche, die für
die industrielle Praxis schnell und leicht umsetzbar wären. Das liegt u. a. daran, dass
multimediale Systeme einfach viel mehr Komponenten besitzen als konventionelle be-
triebliche Informationssysteme. Neben einer Datenbank kommen eben noch die opti-
schen und akustischen Komponenten hinzu, deren Planung nicht so leicht formalisier-
bar ist.
Daher ist das Ziel hier eine Erweiterung bestehender Planungsmodelle um gerade die im
Multimediabereich hinzukommenden Komponenten. Es wird nachfolgend eine Refe-
renzliste erstellt, die dem Planer helfen soll, an alles zu denken und die Aufwände und
Ressourcen hierfür zu planen.
24 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Phasenmodelle 2
Planungs- und Entwicklungsphasen

Um die Möglichkeit zum Ausdruck zu bringen, dass einerseits einige der Multimedia-
komponenten eines zu entwickelnden Programmsystems gleichzeitig und relativ unab-
hängig voneinander entwickelt werden können und andererseits zu Beginn und zum
Abschluss eines solches Projektes i. d. R. nur eine oder wenige Personen beteiligt sind,
wurde für das nachfolgende Phasenkonzept eine 3-dimensionale Diamantform gewählt.
Dieser „Diamant“ ist im Raum mit den Achsen „Zeit“, „Personal“ und „technische Res-
sourcen“ platziert.
Zeit
techn. Ressourcen
Personal
Abb. 2.6: Diamantmodell
Personal-Zeit-Ebene
Nachfolgend werden Projektionen auf zwei Ebenen betrachtet. Es sei dabei ausdrücklich
darauf hingewiesen, dass die Relationen der Komponenten- und Phasengrößen nachfol-
gend nicht in der richtigen Proportion wiedergegeben sind. Die tatsächlichen Größen-
verhältnisse sind natürlich von Art und Umfang des Gesamtprojekts bzw. der einzelnen
Komponenten und Phasen abhängig und variieren daher von Projekt zu Projekt. Die
Darstellung ist also rein qualitativ, nicht quantitativ zu interpretieren.
SEI11 25
© HfB, 02.12.20, Berk, Eric (904709)
2 Phasenmodelle
Zeit
Test &
Handing Over
Composing Components
Screen Layouts
Databases
Animation
Graphics
Photos
Videos
Sound
… …
Basic Planning & Design
Init
Personal
Abb. 2.7: Personal-Zeit-Ebene
Die Zeitachse repräsentiert die Projektphasen, die Personalachse die von den beteilig-
ten Entwicklern zu erstellenden Projektkomponenten. Dabei ist bezüglich der Perso-
nalachse die Breite des Diamanten im Allgemeinen ein Maß für die Menge an Perso-
naleinsatz (z. B. in Personentagen). Grundsätzlich können natürlich auch alle
Komponenten und Phasen von einer einzigen Person durchgeführt werden, was die Pro-
jektdauer entsprechend verlängert. Der Umstand, dass der Diamant „in die Breite“ geht,
soll andeuten, dass in einer breiteren Phase mehr Entwicklungsaufwand nötig ist, der
größtenteils unabhängig (und daher von mehreren Personen gleichzeitig) durchgeführt
werden kann.
Ressourcen-Zeit-Ebene
Für die Entwicklung der jeweiligen MME-Komponenten sind gewisse technische Res-
sourcen erforderlich, die nachfolgend näher beschrieben werden (vgl. Abb. 2.8). Der
Einsatz dieser Ressourcen sei so verstanden, dass als Ergebnis der Verwendung der Res-
sourcen-Komponenten immer eine Datei herauskommt, also ein Datenfile, das in dem
vom MME Composing Tool entsprechend verarbeitbaren Datenformat vorliegt.
26 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Phasenmodelle 2
Zeit
Composing Tool
Database Developer
Screen Design Tool
Animation Tool
Sound Studio
Photo Studio
Video Studio
… Graphic Tool …
Design Tool
techn. Resourcen
Abb. 2.8: Ressourcen-Zeit-Ebene
Eine ausführlichere Beschreibung des Diamantmodells bietet auch die Möglichkeit einer
konkreten Aufwandsabschätzung2.
2.5 Neuere Methoden

In letzter Zeit haben sich zusätzlich zur „klassischen“ Vorgehensweise diverse neuere
Methoden etabliert, von denen wir auf einige überblicksartig kurz eingehen wollen.
Unified Process (UP, RUP)

Die bekannten Autoren und „Erfinder“ der UML, Jacobson, Booch und Rumbaugh,
brachten 1999 ein Buch heraus mit dem Titel „Unified Software Development Process“.
Dieser Titel ist das Äquivalent des verkürzten Begriffes Unified Process. In diesem
Buch stellten verschiedene Autoren ihre Sicht solcher Prozesse dar. Der Begriff Unified
Process deckt alles ab, was man im Rahmen eines iterativen, inkrementellen Soft-
wareentwicklungsprozesses durchführt, z. B. nach dem Spiralmodell. Als Quasi-Stan-
dard hat sich die von Rational Software eingehend dokumentierte Variante behauptet,
die auch Rational Unified Process (RUP) genannt wird. Auf diese soll nun näher einge-
gangen werden.
Der Rational Unified Process (RUP) ist ein adaptives Prozessmodell und beschreibt, wer
was wann und wie in der Durchführung von Softwareprojekten zu tun hat. Der RUP ist
eng mit den eigens für ihn entwickelten Werkzeugen verwoben und wird von Rational
Software zusammen mit seinen Werkzeugen von der Firma IBM vertrieben.
Der RUP ist dadurch gekennzeichnet, dass er
• anwendungsfallgesteuert,
2. Siehe z. B. Zöller-Greer, 2010b
SEI11 27
© HfB, 02.12.20, Berk, Eric (904709)
2 Phasenmodelle
• architekturzentriert (d. h. die Architektur des Produkts in den Vordergrund stellt),

• risikogesteuert und
• iterativ/inkrementell
vorgeht.
Dabei verfolgt der RUP folgende sechs Best Practices, die mit den vier genannten Cha-
rakteristiken einhergehen:
• iterative Entwicklung
• Anforderungsmanagement
• architekturzentrierte Entwicklung
• visuelle Modellierung (z. B. mit UML)
• Qualitätssicherung
• Änderungsmanagement
Diese Best Practices sind die Gestaltungsgrundlage für den RUP und finden sich somit
in den Abläufen wieder.
Abb. 2.9 zeigt einen Überblick über die verwendeten Disziplinen.
Abb. 2.9: Phasen und Tätigkeiten im RUP 

(Quelle: http://www-128.ibm.com/developerworks/rational/library/4721.html)
Der Lebenszyklus des RUP ist prinzipiell in vier Phasen unterteilt:

• Inception (Beginn: Projektumfang festlegen)
• Elaboration (Ausarbeitung: umsetzbare Architektur entwickeln)
• Construction (Konstruktion: Skelett der Architektur mit Funktionalität füllen)
• Transition (Umsetzung: Anwendung in die Nutzerumgebung überführen)
28 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Phasenmodelle 2
Die Disziplinen (auch als Workflows bezeichnet) orientieren sich an speziellen Rollen
innerhalb des Entwicklungsteams, die von bestimmten Personen oder Gruppen wahrge-
nommen werden. Diese Disziplinen sind im Einzelnen:
• Geschäftsprozessmodellierung
• Anforderungen
• Analyse und Design
• Implementierung
• Test
• Überführung in die Einsatzumgebung
• Konfigurations- und Änderungsmanagement
• Projektmanagement
• Projektumfeld
So simpel und einleuchtend die Ausführungen bisher auch sind, einen ersten Einblick in
die Komplexität des RUP gibt Abb. 2.10, wo das Zusammenspiel zwischen Rollen, Akti-
vitäten und Artefakten dargestellt wird.
Abb. 2.10: Zusammenspiel zwischen Rollen, Aktivitäten und Artefakten

(Quelle: http://www-128.ibm.com/developerworks/rational/library/4721.html)
SEI11 29
© HfB, 02.12.20, Berk, Eric (904709)
2 Phasenmodelle
Der RUP versucht für jedes mögliche Projekt eine Vorgehensweise bereitzuhalten und
dies mit der in Abb. 2.10 dargestellten Notation zu beschreiben. Damit werden sehr viele
Abhängigkeiten zwischen den Elementen des RUP erzeugt, die zu der hohen Komplexi-
tät führen. Daher ist auch eine Anpassung („Tailoring“) des RUP an das jeweilige Projekt
unerlässlich.
Agile Softwareentwicklung
Agile Softwareentwicklung ist der Oberbegriff für den Einsatz von Agilität (lat. agilis:
flink; beweglich) in der Softwareentwicklung. Der Begriff unterscheidet – je nach Teil-
bereich der Softwareentwicklung – Agile Modeling, Agile Processing oder Agile Pro-
gramming. Agile Softwareentwicklung versucht mit geringem bürokratischem Auf-
wand und wenigen Regeln auszukommen.
In Abb. 2.11 sehen Sie das mittlerweile „berühmte“ Agility-Poster, das die wichtigsten
Grundsätze dieser Methode zeigt.
Zweck agiler Softwareentwicklung ist es, den Softwareentwicklungsprozess flexibel und
schlank zu machen. Der Fokus liegt dabei mehr auf den zu erreichenden Zielen sowie
auf technischen und sozialen Problemen bei der Softwareentwicklung. Die agile Soft-
wareentwicklung kann als eine Gegenbewegung zu den oft als schwergewichtig und bü-
rokratisch angesehenen traditionellen Softwareentwicklungsprozessen wie dem Ratio-
nal Unified Process oder dem V-Modell angesehen werden.
Erste Ansätze zu agiler Softwareentwicklung finden sich schon Anfang der 1990er- Jah-
re; wirkliche Popularität erreichte die agile Softwareentwicklung erstmals 1999, als Kent
Beck das erste Buch zu Extreme Programming veröffentlichte. Das Interesse an diesem
Thema ebnete den Weg auch für andere agile Prozesse und Methoden. Die Bezeichnung
„agil“ für diese Art der Softwareentwicklung tauchte erstmals im Februar 2001 bei ei-
nem Treffen in Utah auf, als Ersatz für das bis dahin gebräuchliche Wort „leichtgewich-
tig“ (engl. lightweight). Bei diesem Treffen wurde auch das sogenannte Agile Manifest
formuliert. Dieses lautet:
1) Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge. – Zwar
sind wohldefinierte Entwicklungsprozesse und Entwicklungswerkzeuge wichtig,
wesentlicher sind jedoch die Qualifikation der Mitarbeitenden und eine effiziente
Kommunikation zwischen ihnen.
2) Funktionierende Programme sind wichtiger als ausführliche Dokumentation. – Gut
geschriebene und ausführliche Dokumentation kann zwar hilfreich sein, das eigent-
liche Ziel der Entwicklung ist jedoch die fertige Software.
3) Die stetige Abstimmung mit dem Kunden ist wichtiger als die ursprüngliche Leis-
tungsbeschreibung in Verträgen. – Statt sich an ursprünglich formulierten und mitt-
lerweile veralteten Leistungsbeschreibungen in Verträgen festzuhalten, steht viel-
mehr die fortwährende konstruktive und vertrauensvolle Abstimmung mit dem
Kunden im Mittelpunkt.
4) Der Mut und die Offenheit für Änderungen stehen über dem Befolgen eines festge-
legten Plans. – Im Verlauf eines Entwicklungsprojektes ändern sich viele Anforde-
rungen und Randbedingungen ebenso wie das Verständnis des Pro-blemfeldes. Das
Team muss darauf schnell reagieren können.
30 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Phasenmodelle 2
Abb. 2.11: Agile Softwareentwicklung3
Das Agile Manifest weist 17 Autoren und Erstunterzeichner aus, die auf unterschiedli-
chen Gebieten der agilen Softwareentwicklung tätig sind.
Agiles Prinzip
Ein agiles Prinzip ist ein Leitsatz für die agile Arbeit.
Manchmal werden agile Prinzipien auch als Methode bezeichnet.
Beispiele für agile Prinzipien:
• vorhandene Ressourcen mehrfach verwenden
• einfach (KISS-Prinzip)
• zweckmäßig
• kundennah
• gemeinsamer Code-Besitz (Collective Code Ownership)
• Der Übergang zwischen Prinzipien und Methoden ist fließend.
3. Quelle: Wikipedia.de
SEI11 31
© HfB, 02.12.20, Berk, Eric (904709)
2 Phasenmodelle
Agile Methode
Streng genommen bezeichnet der Begriff agile Methode eine an Agilität ausgerichtete
Methode zur Softwareentwicklung. Ein Kennzeichen agiler Methoden ist, dass sie in ei-
nem Prozess dazu dienen können, die Aufwandskurve möglichst gering zu halten. Als
Leitsatz gilt: Je mehr man nach Plan arbeitet, umso mehr bekommt man das, was man
geplant hat, aber nicht das, was man wirklich braucht. Daraus resultieren einige Prinzi-
pien des Agile Modelling und des Extreme Programming. Agile Methoden lassen sich in
zwei Gruppen unterteilen: die tatsächlichen Methoden und die den Methoden zugrunde
liegenden Prinzipien.
Beispiele für agile Methoden:
• Paarprogrammierung
• testgetriebene Entwicklung
• ständige Refaktorisierungen
• Story-Cards
• schnelle Codereviews
Agiler Prozess
Ziel der Vorgehensweise ist es, den Softwareentwicklungsprozess durch Abbau der Bü-
rokratisierung und durch die stärkere Berücksichtigung der menschlichen Aspekte ef-
fektiver zu gestalten. Den meisten agilen Prozessen liegt zugrunde, dass sie versuchen,
die reine Entwurfsphase auf ein Mindestmaß zu reduzieren und im Entwicklungsprozess
so früh wie möglich zu ausführbarer Software zu gelangen, die dann in regelmäßigen,
kurzen Abständen dem Kunden zur gemeinsamen Abstimmung vorgelegt werden kann.
Auf diese Weise soll es jederzeit möglich sein, flexibel auf Kundenwünsche einzugehen,
um so die Kundenzufriedenheit insgesamt zu erhöhen. Sie stellen damit einen Gegensatz
zu den klassischen Vorgehensmodellen wie dem V-Modell oder dem Rational Unified
Process (RUP) dar.
Allen agilen Prozessen ist gemeinsam, dass sie sich zahlreicher Methoden bedienen, die
Aufwandskurve möglichst flach zu halten. Inzwischen gibt es eine Vielzahl von agilen
Prozessen.
Beispiele für agile Prozesse:
• Adaptive Software Development (ASD)
Dies ist ein Softwareentwicklungsprozess, der auf das Rapid Application Develop-
ment zurückgeht; ASD ist eine Umsetzung des Prinzips der kontinuierlichen Anpas-
sung an immer neue Anforderungen (eher der Normalzustand) und ersetzt damit das
verbreitete Wasserfallmodell durch Zyklen von „Spekulieren“, „Zusammenarbeiten“
und „Lernen“.
• Crystal
Dabei handelt es sich um eine Familie von Softwareentwicklungsmethoden, die zu
den agilen Methoden der Softwareentwicklung gerechnet wird. Die Mitglieder die-
ser Familie sind in der Regel mit Farben bezeichnet. Die einfachste Variante heißt
hingegen Crystal Clear („glasklar“).
32 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Phasenmodelle 2
• Extreme Programming (XP)

Extremprogrammierung ist eine Methode, die das Lösen einer Programmieraufgabe
in den Vordergrund der Softwareentwicklung stellt und dabei einem formalisierten
Vorgehen geringere Bedeutung zumisst. Diese Vorgehensweise definiert ein Vorge-
hensmodell der Softwaretechnik, das sich den Anforderungen des Kunden in kleinen
Schritten annähert.
• Feature Driven Development (FDD)
Dies ist eine Sammlung von Arbeitstechniken, Strukturen, Rollen und Methoden für
das Projektmanagement.
Der Rational Unified Process (RUP) wird von vielen Vertretern agiler Methoden als nich-
tagiler, schwergewichtiger Prozess aufgefasst. Das ist allerdings umstritten. Es wurde so-
gar versucht, mit dem Agile Unified Process eine agile Variante von RUP zu entwickeln.
Zusammenfassung
Es wurden die zwei wichtigsten Phasenmodelle, das Wasserfallmodell sowie das Spiral-
modell, ausführlich besprochen. Zusätzlich wurden noch das V-Modell sowie das Dia-
mantmodell erläutert. Außerdem wurden die inhaltlichen Komponenten des Pflichten-
hefts besprochen; dazu gehört insbesondere das semantische Datenmodell als integraler
Bestandteil. Schließlich wurde noch auf neuere Methoden, wie RUP und agile Soft-
wareentwicklung, eingegangen.
2.1 Wozu dienen Phasenmodelle?

2.2 In welcher Phase des Wasserfallmodells sind folgende Sachverhalte angesiedelt:
a) Angebotserstellung
b) Projektplan
c) Semantisches Datenmodell
d) ER-Diagramm
e) Anwendertest
2.3 Was sind Vor- und Nachteile des Spiralmodells gegenüber linearen Modellen?
2.4 Warum ist im Diamantmodell eine 3D-Darstellung gewählt?
2.5 Recherchieren Sie (z. B. im Internet oder in der Online-Bibliothek) und machen Sie
eine Untersuchung für Vorgehensmodelle, indem Sie versuchen herauszufinden,
wann welches Modell (z. B. agil vs. konventionell) bezüglich welcher Projektpara-
meter am geeignetsten erscheint.
SEI11 33
© HfB, 02.12.20, Berk, Eric (904709)
3 Softwareergonomie
In diesem Kapitel besprechen wir die Grundlagen und Anwendungen von Soft-
wareergonomie. Sie sollen nach Durcharbeiten dieses Kapitels in der Lage sein,
• den Zweck von Softwareergonomie zu nennen,
• die Aufgaben eines Usability Engineers zu kennen,
• softwareergonomische Dialoggestaltung zu produzieren.
3.1 Definition und Rechtsgrundlagen

W. Jastrzebowski definierte bereits 1857 in seinem Werk „Grundriss der Ergonomie“ den
Begriff der Ergonomie wie folgt:
„Ergonomie ist ein wissenschaftlicher Ansatz, damit wir aus diesem Leben die besten
Früchte bei der geringsten Anstrengung mit der höchsten Befriedigung für das eigene
und für das allgemeine Wohl ziehen.“
Etwas formaler klingt dagegen die Definition, bezogen auf Software, heutzutage:
Softwareergonomie (von griech. ergon = Arbeit und nomos = Gesetzmäßigkeit) ist die
Wissenschaft, die sich mit der Anpassung von Software an die Stärken und Schwächen
des Menschen befasst4.
Ergonomische Software kann man somit im weitesten Sinn als „gebrauchstaugliche“
Software bezeichnen, die einen Benutzer unterstützt, ohne ihm dabei (noch mehr) Ar-
beitsschritte oder Probleme aufzuhalsen, die durch die Software (und nicht durch die
Arbeitsaufgabe selbst) bedingt sind (vgl. Abb. 3.1).
Für den Betrieb von Bildschirmarbeitsplätzen fordert der Gesetzgeber in der Bild-
schirmarbeitsverordnung, dass gewisse „Grundsätze der Ergonomie“ eingehalten wer-
den müssen. Diese Grundsätze sind durch internationale Normen festgelegt. Seit 1999
gibt es ein offizielles deutsches Prüfverfahren, in dem der Nachweis dieser Grundsätze
(und zur Klärung von Streitfällen) beschrieben wird: das Prüfhandbuch „Gebrauchs-
tauglichkeit“ der Deutschen Akkreditierungsstelle Technik (DATech5).
4. Wir folgen in diesem Abschnitt u. a. den Ausführungen des Deutschen Delegationsleiters im internationalen
Normenausschuss für Softwareergonomie, Wolfgang Redtenbacher (vgl. www.redtenbacher.de) sowie dem
„Handbuch Softwareergonomie“ der Unfallkasse Post und Telekom.
5. www.datech.de
34 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Softwareergonomie 3
Abb. 3.1: Umfeld Softwareergonomie
Die EU-Bildschirmrichtlinie (90/270/EWG) wurde in Deutschland durch die Bild-

schirmarbeitsverordnung vom 20.12.1996 umgesetzt. Die Vorschriften sind seit dem
01.01.2000 für alle typischen Bildschirmarbeitsplätze rechtsverbindlich.
Im Anhang dieser Verordnung wird u. a. das „Zusammenwirken Mensch – Arbeitsmit-
tel“ behandelt. Dort heißt es in Abs. 20:
„Die Grundsätze der Ergonomie sind insbesondere auf die Verarbeitung von Informati-
onen durch den Menschen anzuwenden.“
Einzelheiten dieser „Grundsätze der Ergonomie“ sind in der Verordnung allerdings nur
ansatzweise beschrieben. Genaueres findet sich in der internationalen Normenreihe ISO
9241: „Ergonomische Anforderungen für Bürotätigkeiten mit Bildschirmgeräten“, die in
17 Teilen die verschiedenen Aspekte der menschengerechten (ergonomischen) Gestal-
tung von Bildschirmarbeitsplätzen behandelt. Für alle praktischen Zwecke ist daher die-
se Normenreihe zur Interpretation der Bildschirmarbeitsverordnung zu bevorzugen.
Was wenige wissen: Die Bildschirmarbeitsverordnung ist nur für Arbeitgeber und nicht
für die Hersteller von Software rechtsverbindlich! Deshalb werden Arbeitgeber bei allen
Beschaffungs- und Entwicklungsprojekten im Allgemeinen entsprechende softwareer-
gonomische Anforderungen in den Verträgen mit den jeweiligen Softwareherstellern
einfordern. Am einfachsten geht dies, indem für die Beurteilung der Gebrauchstauglich-
keit der zu beschaffenden Software das Prüfhandbuch „Gebrauchstauglichkeit“ der
Deutschen Akkreditierungsstelle Technik (DATech) vereinbart wird. Eine entsprechen-
de Zusage durch den Lieferanten wird dann natürlich vertraglich verlangt.
Um die Entwicklung eines softwareergonomischen „Aussehens“ der zu entwickelnden
Anwendung kümmern sich entweder der Entwickler selbst und/oder ein sogenannter
Usability Engineer. Erfahrungsgemäß ist es so, dass ein Usability Engineer selten einfa-
che Antworten geben kann, sondern eher Fragen stellt: z. B. warum sind Daten gerade
„so“ gruppiert, welche Daten stehen in einer Auswahlliste zur Verfügung und so weiter.
Von den Antworten auf diese Fragen hängt dann ab, wie die entsprechende Normanwei-
sung konkretisiert wird. Oft wissen die Entwickler auf diese fachlichen Fragen keine
SEI11 35
© HfB, 02.12.20, Berk, Eric (904709)
3 Softwareergonomie
Antworten oder wenn man die „Fachseite“ fragt, bekommt man unterschiedliche Aus-
sagen aus unterschiedlichen Abteilungen. Dies ist der Punkt, an dem sich herausstellt,
dass die Anforderungen nicht ausreichend mit Benutzern abgestimmt sind. Benutzer
können zwar sagen, was sie benötigen, aber nicht, wie sie es technisch realisiert haben
wollen. Dafür ist eine koordinierte Zusammenarbeit der Beteiligten erforderlich.
Abb. 3.2: Usability Engineering
In Abb. 3.2 sehen Sie den vom DIN geforderten Übergang vom Prozess zum Produkt.
Wie man erkennen kann, greifen die angesprochenen Punkte ineinander und besitzen
gewisse Schnittstellen, die vom Usability Engineer erkannt und berücksichtigt werden
müssen.
Zur „Gebrauchstauglichkeit“ einer Software stellt der deutsche Delegationsleiter im in-
ternationalen Normenausschuss für Softwareergonomie, Wolfgang Redtenbacher, fest6:
Die Gebrauchstauglichkeit einer Software wird dadurch bestimmt, in welchem Maße sie
es ermöglicht, Arbeitsziele in einem Nutzungskontext effektiv, effizient und zufrieden-
stellend zu erreichen.
Effektivität bedeutet dabei, ob der Benutzer die vorgesehenen Aufgaben mit der Soft-
ware erledigen kann und die benötigten Ergebnisse korrekt erreicht werden (z. B. dass
ein Textverarbeitungsprogramm einen geschriebenen Brief richtig ausdruckt oder ein
Übersetzungsprogramm den gewünschten Begriff richtig übersetzt).
Die Effizienz der Software wird durch den Aufwand bestimmt, den der Benutzer zur Er-
reichung der Arbeitsziele mit der Software treiben muss. Nützliche Software soll zu ei-
ner Arbeitserleichterung führen, d. h. zu einer Senkung des notwendigen Bedienauf-
wands und ggf. der aufzuwendenden Denkarbeit.
6. Quelle: www.redtenbacher.de
36 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Softwareergonomie 3
Unter der Zufriedenstellung der Benutzer versteht man schließlich das Ausmaß, wie
gern die Benutzer die Arbeitsaufgabe mit der Software als Werkzeug erledigen. Zufrie-
denstellung umfasst den subjektiven Eindruck der Benutzer von der Effizienz und der
Beeinträchtigungsfreiheit (z. B. durch verringerten Stress) bei ihrer Arbeit.
Eine Software ist also dann ergonomisch (gebrauchstauglich), wenn sie für die auszu-
führenden Aufgaben des Benutzers geeignet ist und dabei insbesondere die Hauptaufga-
ben und Benutzereigenschaften unterstützt. Wenn der Benutzer durch fehlende Funkti-
onalität, durch Mehraufwand oder durch fehlerhafte Ergebnisse wesentlich
beeinträchtigt wird, dann ist die Software nicht ergonomisch im Sinne der Bildschirm-
arbeitsverordnung.
Salopp übersetzt ist also „Usability“ (Gebrauchstauglichkeit) die Summe von Effektivi-
tät, Effizienz und Zufriedenstellung.
3.2 Softwareergonomische Dialoggestaltung

Redtenbacher nennt für die ergonomische Gestaltung der Arbeitsschritte einer Software
7 Grundsätze, die in der internationalen Norm ISO 9241-10, „Grundsätze der Dialogge-
staltung“, beschrieben sind7:
1. Aufgabenangemessenheit: Ein Dialog ist aufgabenangemessen, wenn er den Be-
nutzer bei der Erledigung seiner Arbeitsaufgaben unterstützt, ohne ihn durch Eigen-
schaften des Dialogsystems unnötig zu belasten.
Beispiel:
Eine aufgabenangemessene Software zeigt dem Benutzer nur solche Informationen,
die er im Zusammenhang mit der Erledigung seiner Arbeitsaufgabe braucht, und
lenkt ihn nicht durch irrelevante Informationen oder unnötige Dialogschritte ab, die
nichts mit der Arbeitsaufgabe zu tun haben.
2. Selbstbeschreibungsfähigkeit: Ein Dialog ist selbstbeschreibungsfähig, wenn jeder
Dialogschritt entweder unmittelbar verständlich ist oder dem Benutzer auf Anfrage
erklärt wird.
Beispiel:
Eine selbstbeschreibungsfähige Software könnte z. B. die Eingabe des Geburtsda-
tums mit folgendem Hinweis abfragen: „Geben Sie das Geburtsdatum bitte in folgen-
der Form ein: TT.MM.JJ.“ Dadurch erkennt der Benutzer, was er tun muss und wel-
ches Eingabeformat verlangt wird.
3. Erwartungskonformität: Ein Dialog ist erwartungskonform, wenn er einheitlich
aufgebaut (konsistent) ist und den Erwartungen der Benutzer entspricht, die diese
aufgrund ihrer Kenntnisse aus dem Arbeitsgebiet, ihrer Ausbildung sowie allgemein
anerkannter Konventionen hegen.
Beispiel:
Bei einer erwartungskonformen Software erfolgt die Bedienung auf eine einheitliche
Art, und das Programm benutzt die Fachausdrücke, die im Bereich der Arbeitsauf-
gabe des Benutzers tatsächlich verwendet werden.
7. www.redtenbacher.de
SEI11 37
© HfB, 02.12.20, Berk, Eric (904709)
3 Softwareergonomie
4. Lernförderlichkeit: Ein Dialog ist lernförderlich, wenn er den Benutzer in den Lern-
phasen unterstützt.
Beispiel:
Wenn eine Software aufgabenangemessen und selbstbeschreibungsfähig ist und sich
erwartungskonform verhält, ist bereits viel für leichte Erlernbarkeit getan. Eine lern-
förderliche Software würde z. B. zusätzlich ein Learning by Doing ermöglichen, d. h.
das Ausprobieren neuer Funktionen erlauben, ohne den Benutzer für Fehler gleich
durch Datenverlust o. Ä. zu „bestrafen“ und dadurch jede Experimentierfreude im
Keim zu ersticken.
5. Steuerbarkeit: Ein Dialog ist steuerbar, wenn der Benutzer in der Lage ist, den Dia-
logablauf zu starten sowie seine Richtung und Geschwindigkeit zu beeinflussen, bis
das Ziel erreicht ist.
Beispiel:
Wenn eine Software zur Verwaltung von Mietwohnungen auch an Arbeitsplätzen
eingesetzt wird, an denen telefonische Auskünfte erteilt werden, so sollte es dort
möglich sein, ein erst teilweise ausgefülltes Eingabeformular ohne Datenverlust zu
unterbrechen, um die Daten des Anrufers schnell auf den Bildschirm holen zu kön-
nen.
6. Fehlertoleranz: Ein Dialog ist fehlertolerant, wenn das beabsichtigte Arbeitsergeb-
nis trotz erkennbar fehlerhafter Eingaben entweder mit keinem oder mit minimalem
Korrekturaufwand durch den Benutzer erreicht werden kann.
Beispiel:
Wenn in einem Eingabeformular z. B. im PLZ-Feld eine ungültige Eingabe steht, so
würde dies bei einer fehlertoleranten Software nicht zu fehlerhafter Verarbeitung
führen, sondern das Programm würde den Fehler erkennen und den Cursor gleich
zur Korrektur in das betreffende Feld stellen.
7. Individualisierbarkeit: Ein Dialog ist individualisierbar, wenn er an persönliche
Anforderungen und Fähigkeiten des Benutzers angepasst werden kann.
Beispiel:
Bei einer individualisierbaren Software kann z. B. die Schriftgröße für sehbehinderte
Benutzer vergrößert werden oder die Zuordnung der Maustasten kann für Linkshän-
der angepasst werden.
Ähnlich wie es für die ergonomische Gestaltung der dynamischen Dialogabläufe einer
Software die 7 „Grundsätze der Dialoggestaltung“ aus der Norm ISO 9241-10 gibt, so
existieren auch für die statische Informationsdarstellung 7 Grundsätze, die in der inter-
nationalen Norm ISO 9241–12 „Informationsdarstellung“ beschrieben sind:
1) Erkennbarkeit (die Aufmerksamkeit des Benutzers wird zur benötigten Information
gelenkt)
2) Unterscheidbarkeit (die angezeigte Information kann genau von anderen Daten un-
terschieden werden)
3) Lesbarkeit (die Information ist leicht zu lesen)
4) Verständlichkeit (die Bedeutung ist leicht verständlich, eindeutig, vermittelbar und
erkennbar)
38 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Softwareergonomie 3
5) Klarheit (der Informationsgehalt wird schnell und genau vermittelt)

6) Kompaktheit/Prägnanz (den Benutzern wird nur jene Information gegeben, die für
das Erledigen der Aufgabe notwendig ist)
7) Konsistenz (gleiche Information wird innerhalb der Anwendung entsprechend den
Erwartungen des Benutzers stets auf die gleiche Art dargestellt)
Für die meisten praktischen Zwecke können diese Grundsätze zu zwei übergeordneten
Zielen zusammengefasst werden: die Gestaltung handlungsleitender Informationen und
die Minimierung der Augenbelastung.
„Handlungsleitende Informationen“ bedeutet, dass dem Benutzer unmittelbar klar sein
soll, was zu tun ist. Handlungsleitende Informationen dürfen nicht versteckt sein, son-
dern die Aufmerksamkeit des Benutzers sollte auf sie gelenkt werden, damit er erkennt,
wo er sich gerade im Dialog befindet und was sein nächster Schritt sein soll. Insofern
sind handlungsleitende Informationen bei der Informationsdarstellung die Entspre-
chung zum Grundsatz der „Selbstbeschreibungsfähigkeit“ aus der Dialoggestaltung.
Eine Minimierung der Augenbelastung wird hauptsächlich durch geeignete Schrift- und
Zeichengrößen sowie eine günstige Wahl von Farben bzw. Farbkombinationen erreicht.
Die Eignung der wichtigsten Farbtöne als Hintergrund- bzw. Vordergrund-/Schriftfar-
ben kann der deutschen Norm DIN 66234-5 „Bildschirmarbeitsplätze: Codierung von
Information, Farbkombinationen“ entnommen werden:
Vordergrund (Schrift)
Hintergrund schwarz weiß magenta blau zyan grün gelb rot
schwarz n.a. + + - + + + -
weiß + n.a. + + - - - +
magenta + + n.a. - - - - -
blau - + - n.a. + - + -
zyan + - - + n.a. - - -
grün + - - + - n.a. - -
gelb + - + + - - n.a. +
rot - + - - - - + n.a.
Abb. 3.3: Ergonomische Eignung von Farbkombinationen
In Abb. 3.4 sehen wir eine kleine Liste, die diverse Probleme bezüglich der Softwareer-
gonomie darstellt:
SEI11 39
© HfB, 02.12.20, Berk, Eric (904709)
3 Softwareergonomie
Abb. 3.4: Erschwerungen
Wer nun glaubt, Softwareergonomie beziehe sich „nur“ auf das Layout der Bildschirme
und deren Bedienung, der irrt. Obwohl dies natürlich ein entscheidender Faktor ist, ver-
birgt sich hinter ergonomischer Software doch viel mehr, wie man schon aus Abb. 3.4
erahnen kann. In Abb. 3.5 ist dies noch deutlicher zu erkennen.
Abb. 3.5: Einordnung visueller Aspekte der Softwareergonomie
Bereits bei der Modellierung der Daten ist die softwareergonomische Auswirkung er-
heblich; die Eingabe von Daten und deren logische Zusammenhänge werden hier ja vor-
definiert. Sind hier schon Daten so modelliert, dass ein Anwender später umständlich
und evtl. sogar redundant Daten eingeben muss, dann kann die Oberfläche noch so
schön sein, dieser Mangel wird jeden Anwender stören.
40 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Softwareergonomie 3
3.3 Praktische Anwendungen

Durch die zunehmende Bedeutung von Internetanwendungen und die damit einherge-
hende Darstellung in Webbrowsern ergibt sich u. U. das Problem, dass das Design des
Entwicklers in einem Browser nicht so ankommt wie ursprünglich vorgesehen. Insbe-
sondere bei multimedialen Anwendungen kann dies ein ernsthaftes Problem darstellen.
Deswegen sind solche Anwendungen mit allen gängigen Browsern zu testen und ggf.
entsprechende Maßnahmen zu ergreifen.
Bei einer Website kommt es auf drei Aspekte an: Inhalt, Form (Design) und Organisation
(Struktur, Navigation). Nur wenn alle Aspekte miteinander abgestimmt entwickelt wer-
den, kommt es zu einer qualitativ guten Website.
Wie bei konventionellen GUI-Applikationen ist ebenfalls zwischen der Oberflächen-
und der Navigationsgestaltung zu unterscheiden. GUI-Applikationen verwenden oft
Fenster- bzw. Dokumentenansichten zur Darstellung von Informationen. Browsersoft-
ware sorgt jedoch sowohl für die Darstellung der Inhalte als auch für die Navigation
zwischen den einzelnen Seiten.
Kritiker wie Jakob Nielsen (2000) bemängeln dies und sagen einen Untergang der Brow-
ser voraus. Nach Ansicht von Nielsen gibt es keinen Grund, Daten abhängig von deren
Speicherort Festplatte oder Internet unterschiedlich zu behandeln. Aber diese Sichtweise
ist Zukunftsmusik. Für die Oberflächengestaltung von Websoftware existieren inzwi-
schen zahlreiche öffentlich zugängliche Styleguides, an denen man sich orientieren
kann.
Dann ist gerade im Internetbetrieb zwischen der reinen Betrachtung von Inhalten durch
den „normalen“ Surfer und dem redaktionellen Verwalten der Inhalte durch besondere
Webredakteure zu unterscheiden.
Betrachten wir dies am Beispiel:
Die Vermittlungsseiten eines Tierheims werden von Surfern besucht und sollen in an-
sprechender Weise die zu vermittelnden Tiere vorführen. Der Surfer soll schnell das
Wichtigste erkennen und auch leicht zu anderen Seiten navigieren können 
(siehe Abb. 3.6).
SEI11 41
© HfB, 02.12.20, Berk, Eric (904709)
3 Softwareergonomie
Abb. 3.6: Darstellung im Browser für den Surfer
Eine softwareergonomische Version der gleichen Seite stellt sich für einen Redakteur na-
türlich gänzlich anders dar (Abb. 3.7):
Es ist durch die Verbreitung von Entwicklungswerkzeugen in neuerer Zeit glücklicher-
weise häufig so, dass diese Werkzeuge dem Entwickler bei der Entwicklung von GUIs
die wichtigsten softwareergonomischen Gesichtspunkte auf Wunsch schon vorgeben. So
bieten z. B. Entwicklungstools für Webseiten oft vorgefertigte Templates, die sich soft-
wareergonomisch bewährt haben. Der Entwickler ist gut beraten, sich an diesen Design-
mustern zu orientieren.
42 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Softwareergonomie 3
Abb. 3.7: Darstellung im Browser für den Webredakteur
In Abb. 3.7 sieht man, dass hier eine eher datenbezogene, etwas „sterilere“ Darstellung
gewählt wurde, die aber für den Redakteur zweckmäßiger ist. Beim Anklicken des Links
„Ändern“ erscheint dann eine Art „Zoom“ in den betreffenden Datensatz, der schließlich
die redaktionellen Einträge und Anpassungen ermöglicht (Abb. 3.8).
Es gibt natürlich auch Content-Management-Systeme (CMS), die das Layout für den Re-
dakteur so nachbilden, wie es der Surfer sieht. Doch das ist in vielen Fällen eher un-
zweckmäßig, da, wie gesagt, die Zielgruppen völlig verschieden sind.
SEI11 43
© HfB, 02.12.20, Berk, Eric (904709)
3 Softwareergonomie
Abb. 3.8: Änderungen durch den Redakteur
Was die reine Oberflächengestaltung betrifft, so ist dies oft eine Frage des Geschmacks.
Verschiedene Menschen empfinden die gleiche Benutzeroberfläche manchmal als sehr
angenehm, während andere wiederum damit nicht zurechtkommen. Dies sollte beim Er-
stellen eines Pflichtenhefts berücksichtigt werden. So helfen bereits in dieser Phase Skiz-
zen von zukünftigen Bildschirmmasken, die mit den Benutzern abgesprochen werden
sollen. Existiert bereits Software, die von den späteren Benutzern bereits benutzt wird
44 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Softwareergonomie 3
und gut ankommt, dann sollte man sich an diesem Bildschirmlayout orientieren, damit
die Einarbeitung und Benutzung der neu zu schreibenden Anwendung möglichst unpro-
blematisch wird.
Zusammenfassung
In diesem Abschnitt wurden die Grundlagen der Softwareergonomie besprochen. Es

wurden zunächst die rechtlichen Gegebenheiten dargestellt und der Begriff des Usability
Engineering erläutert. Danach wurden wichtige Grundsätze zur Dialoggestaltung auf-
gezeigt und praktische Hinweise dazu gegeben. Schließlich wurden anhand eines Bei-
spiel einige praktische Hinweise gegeben.
Aufgabe zur Selbstüberprüfung
3.1 Für die Wandlung von Video- und Audioformaten gibt es diverse Freeware. Wie
beurteilen Sie folgende beide Benutzeroberflächen unter dem Gesichtspunkt der
Softwareergonomie?
Abb. 3.9: SuperConverter
SEI11 45
© HfB, 02.12.20, Berk, Eric (904709)
3 Softwareergonomie
Abb. 3.10: MediaCoder
46 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
4 Planung eines Softwareprojekts

Hier wird aufgezeigt, wie man ein Softwareprojekt ausgehend von der Initialisie-
rung plant. Dieses Kapitel stellt in gewissem Sinn eine „Verfeinerung“ von
Kapitel 2 dar, wo ein Gesamtüberblick über alle Entwicklungsphasen gegeben
wurde. Es sei allerdings darauf hingewiesen, dass im Rahmen dieses Studienhefts
im vorliegenden Kapitel nur bis zur Phase „Entwurf“ vorgedrungen werden kann,
während das Projekt selbst natürlich alle Phasen des Wasserfallmodells um-
spannt. Weiterführende Entwurfstechniken (z. B. UML) sowie eine Beschreibung
der sich anschließenden Projektphasen finden sich in fortführenden Studienhef-
ten.
Sie sollen nach Durcharbeiten dieses Kapitels in der Lage sein,
• ein Problem zu analysieren,
• ein Pflichtenheft zu erstellen,
• einfache Modellierungsverfahren zu nennen,
• ein semantisches Datenmodell zu entwerfen,
• Szenarien und Zustände zu beschreiben,
• einen einfachen Projektplan zu erstellen.
Es werden hier allerdings keine quantitativen Betrachtungen angestellt, diese
sind Inhalt des Projektmanagements.
4.1 Erste Analyse des Problems

Es sei zunächst folgendes Beispiel betrachtet:
Wir stellen uns vor, dass eine Schallplattenfirma (nachfolgend „Tonträgerhersteller“ ge-
nannt) ihre administrativen Tätigkeiten zukünftig computergestützt durchführen möch-
te. Das mit dieser Entwicklung beauftragte Softwareentwicklungsunternehmen hat na-
turgemäß keine Erfahrung mit den im Verlag anfallenden Aufgabenstellungen. Da
begegnet uns also schon das erste Problem, nämlich die Kommunikation zwischen Auf-
traggeber und Auftragnehmer. Der Auftraggeber würde schon gleich zu Beginn gern
wissen, was die zu entwickelnde Software kosten soll. Dagegen benötigt der Auftragneh-
mer, um dies beurteilen zu können, schon recht detaillierte Angaben. Daher wird der
Auftraggeber dem Auftragnehmer zunächst eine kurze, grobe Problembeschreibung ge-
ben. Diese könnte in unserem konkreten Fall z. B. so aussehen:
Projektbeschreibung (Beispiel)
Es ist eine Software zu entwickeln, die die Abrechnung von Tonträgerherstellern (nach-
folgend „Lizenznehmer“ genannt) mit ihren Lizenzgebern (Künstler oder Produzenten)
ermöglicht. Der Arbeitsablauf gestaltet sich wie folgt:
1) Der Tonträgerhersteller bekommt von einem Künstler oder Produzenten
(Lizenzgeber) ein Tonband oder einen sonstigen Träger des Mastertapes einer Mu-
sikaufnahme zur Verwertung angeboten. Entscheidet sich der Tonträgerhersteller
dazu, die Aufnahme(n) herauszubringen, so wird ein Lizenzvertrag abgeschlossen.
SEI11 47
© HfB, 02.12.20, Berk, Eric (904709)
2) Der Lizenzvertrag enthält Angaben über die Titel des Mastertapes, deren Komponis-
ten, Texter, Bearbeiter, Verwertungsgesellschaft (z. B. GEMA), Musikverlage, Spiel-
dauern, Interpreten, Lizenzgeber, Lizenznehmer, Exklusivität (ja/nein), Vertragsdau-
er, Erstauflage der VHS, ggf. geplante Folgeauflagen, Erstlabelangabe, Länder der
Verwertung, Prozentsatz der Lizenzgeberbeteiligung am Großhandelsverkaufspreis,
Abrechnungsturnus, Vorschuss, Sonstiges. Der Lizenzvertrag muss ausdruckbar
sein.
3) Alle Personen und Verlage sind in einer eigenen Tabelle (Adressverwaltung) nicht-
redundant zu verwalten.
4) Alle Tonträger sind in einer Tabelle zu verwalten, zusammen mit ihren Auflagen. Es
soll ein Zugriff auf die Verkaufszahlen (inkl. Historie) in vorgebbaren Zeiträumen
möglich sein.
5) Es soll möglich sein, Statistiken zu erstellen (auch grafisch), und zwar
• über alle verkauften Tonträger in einem angebbaren Zeitraum,
• über die Verkaufszahlen eines bestimmten Tonträgers in einem angebbaren Zeit-
raum,
• über die Verkaufszahlen aller Produkte auswählbarer Lizenznehmer in einem
angebbaren Zeitraum,
• über den Verkaufsverlauf einzelner Titel (also evtl. über mehrere Tonträger hin-
weg),
• über den Verkaufsverlauf einzelner Komponisten (also evtl. über mehrere Ton-
träger hinweg),
• über den Verkaufsverlauf der Werke einzelner Verlage (also evtl. über mehrere
Tonträger hinweg).
6) Es soll möglich sein, eine Lizenzabrechnung für die Lizenzgeber über einen festleg-
baren Zeitraum durchzuführen (inkl. Historie), die den Zahlbetrag abhängig vom Li-
zenzvertrag und den Verkaufszahlen der beteiligten Tonträger des Lizenzgebers an-
gibt. Eine Aufstellung, welche Tonträger wie oft verkauft wurden, sollte vorhanden
sein.
Diese Angaben sind allerdings noch zu lückenhaft, um daraus schon die fertige Software
entwickeln zu können. Diese Lücken müssen in einer genaueren Analyse durch weitere
intensive Kommunikation zwischen Auftraggeber und Auftragnehmer geschlossen wer-
den. Doch für eine erste grobe Kostenabschätzung sollte diese Problembeschreibung
ausreichend sein, zumindest dann, wenn der Auftragnehmer über hinreichend Erfah-
rung auf diesem Gebiet verfügt. Der nächste Schritt ist dann ein Angebot des Auftrag-
nehmers an den Auftraggeber. Oft wird dabei ein Festpreis angeboten. Es ist aber noch-
mals darauf hinzuweisen, dass so etwas nur gemacht werden sollte, wenn der
Auftragnehmer über hinlänglich Erfahrung und „Gefühl“ für die auf ihn zukommende
Arbeit verfügt.
Ist der Auftraggeber mit dem Angebot einverstanden, wird er eine Auftragsbestätigung
bzw. eine Bestellung an den Auftragnehmer schicken. Damit kommt juristisch ein Ver-
trag zustande, und beide Vertragspartner sind zur Einhaltung der vereinbarten Punkte
verpflichtet.
48 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Planung eines Softwareprojekts 4
Zusammenfassend kann man also sagen: Die erste Problemanalyse dient dem Zweck der
Auftragserstellung. Der Aufwand für diese erste Analyse sollte nicht mehr als 15 % des
voraussichtlichen Gesamtaufwands betragen, da es ja sein kann, dass der Auftraggeber
das Angebot ablehnt und die Zeit für die erste Problemanalyse in der Regel nicht vergü-
tet wird.
Naturgemäß schließt sich an diese erste Problemanalyse mit Auftragsvergabe (im Was-
serfallmodell wurde dies Initialisierung genannt) eine verfeinerte Analyse an, die zur
nächsten Phase des Wasserfallmodells führt: dem Fachkonzept.
4.2 Verfeinerte Analyse des Problems: Erstellung des Pflichtenhefts

Es wurde bereits über die Komponenten eines Pflichtenhefts gesprochen. Das Pflichten-
heft selbst ist dabei ein Ergebnis bzw. wichtiger Bestandteil der Phase „DV-Fachkon-
zept“. Manchmal wird es einfach auch nur „Spezifikation“ genannt. Das ist allerdings et-
was irreführend, da unter diesem Begriff auch häufig das Ergebnis der nächsten Phase,
also des DV-Entwurfs, verstanden wird. Um hier zu unterscheiden, werden manchmal
auch die Begriffe „Grobkonzept“ für das Pflichtenheft und „Feinkonzept“ für den Ent-
wurf benutzt. Aber auch diese Begriffsvergabe ist nicht immer eindeutig so durchgehal-
ten.
Bevor also schon an dieser Stelle Missverständnisse auftreten, sollten Auftraggeber und
Auftragnehmer über die benutzten Begriffe Einigkeit erzielen. Zudem wird auch in der
Fachliteratur nicht immer die gleiche Begriffsdefinition verwendet. Während manchmal
die Begriffe „Fachkonzept“ und „Pflichtenheft“ im Wesentlichen synonym verwendet
werden, machen andere Autoren hier Unterscheidungen. Für die Zwecke des vorliegen-
den Studienhefts werden wir allerdings auch keinen praktischen Unterschied zwischen
einem Fachkonzept und einem Pflichten-heft machen.
Das Pflichtenheft wird von Auftraggeber und Auftragnehmer gemeinsam entwickelt. Es
ist ratsam, dass beide es nach Fertigstellung unterschreiben und damit dessen Inhalt „ab-
segnen“. Dies ist für beide Parteien eine juristische Absicherung, was genau geleistet
werden soll. In diesem Sinne stellt das Pflichtenheft Teil eines juristischen Vertrages dar.
DIN 69901 legt die Standardgliederung eines Pflichtenhefts fest:
1. Unternehmenscharakteristik
1) Name und Adresse des Unternehmens
2) Branche, Produktgruppe, Dienstleistungen
3) Unternehmensstruktur, Zahl der Betriebsstätten, Niederlassungen
4) Unternehmensgröße, Wachstumsrate
5) Organisation und Datenverarbeitung
6) Weitere wesentliche Angaben zum Unternehmen
2. Istzustand der Arbeitsgebiete
1) Überblick und Zusammenhänge; evtl. Strukturorganisation
2) Bisherige Verfahren für die Arbeitsgebiete 1 … n
3) Bisherige Hilfsmittel
4) Vorhandenes Fachwissen, Computerwissen, Organisationsniveau
SEI11 49
© HfB, 02.12.20, Berk, Eric (904709)
5) Unternehmensspezifische Besonderheiten
6) Bewertung des Istzustandes – Aufwand und Nutzen – Stärken und Schwächen
3. Zielsetzungen
1) Erwarteter quantifizierbarer Nutzen
2) Sonstige erwartete Vorteile
4. Anforderungen an die geplante Anwendungssoftware
1) Fachliche Anforderungen
1. Überblick und Zusammenhänge
2. Detaillierte Anforderungen an die Arbeitsgebiete 1 … n
• wesentliche Verfahren
• wesentliche Ein- und Ausgabeinformationen
• Verarbeitungsarten und -häufigkeit
• unternehmensspezifische Besonderheiten
2) Technische Anforderungen
1. Qualitätsanforderungen – Integration
• Dateiorganisation
• Zugriffsberechtigung, Datensicherheit und -rekonstruktion
• Form der Programmauslieferung
2. Dokumentation und Schulung
[Differenzierung in funktional und nichtfunktional]
5. Mengengerüst
1) Kartei/Stammdaten
2) Bestandssätze, Belege/Zahl der Bewegungen
3) sonstige Mengen- und Häufigkeitsangaben
6. Anforderungen an Hardware und Systemsoftware
7. Mitarbeiter für die Umstellung
8. Zeitlicher Rahmen
Um die Punkte eines Pflichtenhefts alle hinreichend zu erfüllen, ist es natürlich erfor-
derlich, dass gewisse Analysen beim Auftraggeber durchgeführt werden.
Es handelt sich bei dieser DIN-Beschreibung um den Maximalfall. Bei kleineren Projek-
ten sind nicht alle Punkte dieser Festlegung zu berücksichtigen.
Wir betrachten nachfolgend einige Methoden, mit denen die genannten Unterpunkte ei-
nes Pflichtenhefts teilweise erstellt werden. Es sind dabei nicht alle diese Methoden in
jedem Projekt erforderlich, das muss man jeweils konkret mit dem Auftraggeber ent-
scheiden. Auch werden, um den Rahmen dieses Studienhefts nicht zu sprengen, nach-
folgend nicht alle vorhandenen Verfahren vorgestellt; wir haben eine Auswahl getroffen,
von der wir glauben, dass sie die meisten Fälle abdecken kann.
50 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
4.2.1 Analyse Ist-/Sollzustände

Ein Pflichtenheft muss Angaben darüber enthalten, wie der momentane Zustand ist und
wie derselbe nach Realisierung des DV-Projekts aussehen soll. Natürlich beschränkt
man sich dabei auf den für das Projekt relevanten Realitätsausschnitt. Betrachten wir
dies wieder anhand unseres Beispiels einer Schallplattenfirma. Dort könnte es folgen-
dermaßen aussehen:
Istzustand
Außer einer verbalen Beschreibung des Istzustandes bedient man sich häufig noch zu-
sätzlich sogenannter Use-Case-Diagramme (manchmal auch nur U-Case-Diagramme
genannt). Diese bestehen lediglich aus kleinen Strichmännchen, die die beteiligten Per-
sonen kennzeichnen, sowie aus beschrifteten Ellipsen, die Vorgänge darstellen sollen. In
unserem Beispiel der Lizenzabrechnung kann ein solches Diagramm wie folgt aussehen:
Authors
Offers Song Publishing Contract
Artists Contract File Song in Database
Publisher/
Producer
Payoff 3 GEMA Reg.
Performer
Song produced Payoff 2 Licence Contract
Release Record
Record Studio
Record Company
Payoff 1
Distributor
Abb. 4.1: U-Case-Diagramm des Istzustandes
SEI11 51
© HfB, 02.12.20, Berk, Eric (904709)
Ein U-Case-Diagramm bedarf immer auch einer verbalen Erläuterung. Diese könnte
z. B. so lauten:
Ein Autor (in Abb. 4.1 Strichmännchen oben) offeriert eine
Komposition (Song) einem Musikverleger oder Produzenten
(Publisher/Producer, Strichmännchen oben Mitte). Gefällt dem
Verleger das Lied, so wird ein Verlagsvertrag gemacht (Publishing
Contract, oben rechts) und die relevanten Daten in einer Kartei
abgelegt (Files Song in Database, oben rechts) sowie eine
Registrierung bei der GEMA durchgeführt. Jetzt beauftragt der
Verleger einen Produzenten (bzw. manchmal sind Verleger und
Produzent identisch) mit der Suche nach einem Interpreten
(Performer/Artist, Strichmännchen Mitte links). Wurde ein solcher
gefunden, so wird mit demselben ein Künstlervertrag abgeschlossen
(Artist Contract). Danach geht der Produzent mit dem Künstler in
ein Tonstudio (Record Studio, Strichmännchen links unten) und
produziert (mind.) einen Song. Das Ergebnis ist ein sogenanntes
Mastertape, also eine Aufnahme des fertig produzierten Liedes. Der
Produzent macht sich jetzt auf die Suche nach einem
Tonträgerhersteller, also der eigentlichen Plattenfirma (Record
Company, Strichmännchen Mitte unten). Hat er diese gefunden, so
wird jetzt zwischen dem Produzenten und dem Tonträgerhersteller
ein weiterer Vertrag abgeschlossen, der sogenannte Lizenzvertrag
(License Contract, Mitte rechts). Die Plattenfirma lässt daraufhin
die Tonträger mit dem Song vervielfältigen und veröffentlicht
diesen (Release Record, rechts unten), indem sie einen Distributor
(Strichmännchen rechts unten) mit dem Vertrieb der Tonträger
beauftragt (der die Tonträger schließlich den Schallplatten-
geschäften verkauft). In regelmäßigem Turnus rechnet der
Distributor mit der Plattenfirma über die verkauften Tonträger ab,
d. h., er zahlt nach Abzug seiner Provision einen bestimmten
Betrag (Payoff 1, ganz unten Mitte) an die Plattenfirma. Diese
wiederum zahlt an den Produzenten die im Lizenzvertrag vereinbarte
Provision (Payoff 2, Bildmitte). Der Produzent schließlich zahlt
daraufhin an den Künstler die im Künstlervertrag vereinbarte
Beteiligung (Payoff 3). Zu beachten ist dabei, dass zwar eine
Abrechnung nach Anzahl verkaufter Tonträger erfolgt, jedoch sind
ggf. nicht alle Songs eines Tonträgers abrechnungsfähig, sondern
nur diejenigen, die dem entsprechenden Lizenzvertrag zugrunde
liegen. Es ist also bei der Lizenzabrechnung nur der tatsächliche
Anteil an Liedern eines Tonträgers zu berücksichtigen. Der Autor
erhält seine Zahlungen entweder direkt von der GEMA (an die
Rundfunkunternehmen ihre Sendetantieme entrichten müssen und der
Tonträgerhersteller für jede gepresste Schallplatte eine
Schutzgebühr zahlen muss) oder, falls er selbst nicht GEMA-
Mitglied ist, vom Musikverlag (gemäß den Vereinbarungen im
Verlagsvertrag), der in der Regel dann GEMA-Mitglied ist und von
dort die entsprechenden Anteile erhält.
Diese Istzustandsbeschreibung ist immer noch relativ ungenau. Sie enthält beispielswei-
se keine genauen Angaben über die Attribute (z. B. welche Daten in den jeweiligen Ver-
trägen in welchem Format erfasst werden) oder in welchen Zeiträumen wie genau die
einzelnen Abrechnungen erfolgen etc.; so etwas kann entweder noch im Pflichtenheft
erfolgen, in dem z. B. ein entsprechendes Entity Relationship Model erzeugt wird (was
am besten wäre), oder dies erfolgt während der DV-Entwurfsphase (wo es spätestens
52 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
vorliegen muss). Des Weiteren wären der Istanalyse noch Beispielexemplare der betei-
ligten Verträge sowie ein Muster der Abrechnungen beizufügen. Diese sind also dem
Auftragnehmer auszuhändigen. Beispiele dafür siehe Abb. 4.2 bis Abb. 4.5.
SEI11 53
© HfB, 02.12.20, Berk, Eric (904709)
Musikverlagsvertrag
zwischen
(Name des Autors)
zurzeit Mitglied/Bezugsberechtigter der Verwertungsgesellschaft/en (z. B. GEMA)

als Urheber des/der Werkes/Werke
(Liedtitel, Komponist/en, Texter)
zugleich für seine/ihre Erben und Rechtsnachfolger, im folgenden URHEBER genannt, und dem Verlag
(Musikverlag)
zurzeit Mitglied der Verwertungsgesellschaft/en (z. B. GEMA)

zugleich für seine Rechtsnachfolger, im folgenden VERLAG genannt.
1. Der/Die URHEBER räumt/räumen dem VERLAG die Nutzungsrechte an seinem/ihrem/ihren Werk/
Werken für alle Nutzungsarten ein soweit und solange diese nicht sowohl für den/die URHEBER als
auch für den VERLAG von einer Verwertungsgesellschaft treuhänderisch wahrgenommen werden. Die
Einräumung der Nutzungsrechte an den VERLAG ist, soweit nicht anders vereinbart, ausschließlich
und räumlich, zeitlich und inhaltlich unbeschränkt erfolgt.
2. Der Verlag ist insbesondere verpflichtet:
a) das/die Werk/Werke innerhalb einer angemessenen Frist nach Erhalt des vervielfältigungsreifen
Manuskriptes mit Nennung des Namens des URHEBERS und/oder MITURHEBER(S) in
handelsüblicher Weise zu vervielfältigen und es zu verbreiten;
b) sich für die Nutzung der ihm nach Ziffer 1. eingeräumten Rechte in handelsüblicher Weise
einzusetzen;
c) dem/den URHEBER/N von zum Verkauf bestimmten Ausgaben ............ Freiexemplare und auf
dessen/deren Verlangen dem/den URHEBER/N Exemplare zum Nettopreis direkt zu liefern. Ihr
Weiterverkauf darf nur zu dem vom Verlag gebundenen jeweiligen Ladenpreis erfolgen. Ausgaben
ohne Ladenpreis erhält/erhalten der/die URHEBER auf Verlangen zum Entstehungspreis des
VERLAGES. Werden Ausgaben vom VERLAG nur leihweise abgegeben, so dürfen sie weder
entgeltlich oder unentgeltlich veräußert noch zu Aufführungen, Aufzeichnungen, Herstellung von
Kopien u. a. benutzt werden.
d) soweit zum Schutz des Urheberrechtes an dem/den Werk/Werken besondere Formalitäten
erforderlich sind, diese in handelsüblicher Weise zu erfüllen. Für den Fall, dass ein Staat den Schutz
des Urheberrechtes oder seine Erneuerung oder Verlängerung von einer Anmeldung oder
Eintragung abhängig macht, so bevollmächtigt/bevollmächtigen der/die URHEBER hiermit den
VERLAG, dieses im eigenen Namen als Copyright-Eigentümer durchzuführen, und
verpflichtet/verpflichten sich der/die URHEBER zugleich für seine/ihre Rechtsnachfolger zur
Abgabe aller Erklärungen, die erforderlich und zweckmäßig sind, um die erforderlichen und
zweckmäßigen Anmeldungen, Erneuerungen, Verlängerungen und/oder Eintragungen
durchzuführen.
3. Der VERLAG ist insbesondere berechtigt:
a) die Höhe der Auflagen, die Art der Ausstattung, den Ladenverkaufspreis zu bestimmen und auch
abzuändern und Lagerbestände des/der Werkes/Werke unter Aufhebung des Ladenpreises
aufzulösen, wenn die Erträgnisse eine Verwaltung und Lagerung nicht mehr rechtfertigen (etwaige
Erlöse aus der Auflösung sind von einer Beteiligung am Notenabsatz ausgenommen). Der
VERLAG muss den/die URHEBER rechtzeitig vor der Auflösung der Lagerbestände
benachrichtigen, um ihm/ihnen Gelegenheit zum Erwerb der Bestände zu geben. Dem VERLAG
steht das Recht zu, die Auswertung des/der Werkes/Werke zu den in diesem Vertrag
Abb. 4.2: Musikverlagsvertrag (Ausschnitt)
54 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Künstlervertrag
zwischen
nachstehend kurz Künstler genannt,

und
nachstehend Tonträgerhersteller genannt.

§ 1 ALLGEMEINES
1. Gegenstand des Vertrages ist das Recht, Schallaufnahmen mit Darbietungen des Künstlers
auszuwerten.
2. Zu diesem Zweck verpflichtet sich der Künstler, wahrend der Vertragsdauer Titel zur
Herstellung von Schallaufnahmen darzubieten.
3. Der Künstler erklärt mit der Unterzeichnung des Vertrages ausdrücklich:
a) nicht und durch keinen irgendwie gearteten Vertrag am Abschluss dieses Vertrages
gehindert zu sein.
b) das Recht am persönlichen Vortrag der unter diesen Vertrag fallenden Aufnahmen
niemandem übertragen zu haben.
§ 2 RECHTSÜBERTRAGUNG
1. Der Künstler überträgt dem Tonträgerhersteller und seinen Lizenznehmern ohne
Einschränkungen und für die ganze Welt seine sämtlichen Leistungsschutzrechte und
-ansprüche sowie alle sonstigen Rechte, die er während der Vertragsdauer an seinen
aufgenommenen Darbietungen erwirbt, soweit diese Rechte übertragbar sind. Er räumt dem
Tonträgerhersteller mithin das ausschließliche und übertragbare Recht ein, seine
aufgenommenen Darbietungen in der ganzen Welt in jeder beliebigen Weise und unter jeder
Marke zu verwerten und/oder verwerten zu lassen.
Zur Sicherung der Exklusivverpflichtung (§ 3) überträgt der Künstler auch alle Rechte und
Ansprüche, die durch seine Darbietungen bei etwaigen Schallaufnahmen und Mitschnitten
Dritter entstehen.
2. Die Rechtsübertragung schließt insbesondere ein: das Recht zur und den Anspruch aus der
öffentlichen Aufführung und Sendung sowie das Recht zur Verwertung durch Film, Funk,
Fernsehen und andere Speicherverfahren.
3. Der Künstler ist jedoch berechtigt, Aufnahmen, die lediglich für Rundfunk- und
Fernsehübertragungen dienen, durchführen zu lassen. Er verpflichtet sich aber, während der
Vertragsdauer und während der in § 3 Pkt. 3 bestimmten Zeit stets zu verbieten, dass seine
Vorträge bei einer Rundfunk- oder Fernsehübertragung von dem Rundfunk- oder
Fernsehsender oder von Dritten zwecks Weiterverarbeitung auf Filmen, Schallplatten oder
sonstigen Wiedergabemitteln irgendwie festgehalten werden. Die Weitergabe einer
Aufnahme durch den aufnehmenden Rundfunk- oder Fernsehsender an einen anderen
Rundfunk- oder Fernsehsender ausschließlich für Sendezwecke ist von dem Verbot der
unzulässigen Weiterverbreitung ausgenommen. Der Künstler bevollmächtigt den
Tonträgerhersteller, Rechte und Verstöße gegen dieses Verbot in seinem Namen geltend zu
machen.
Abb. 4.3: Künstlervertrag (Ausschnitt)
SEI11 55
© HfB, 02.12.20, Berk, Eric (904709)
License Agreement
This agreement entered Into between (“LESSOR”) and (hereinafter called LICENSEE).
WHEREAS LESSOR represents and warrants that it has the exclusive rights for all the recordings
(hereinafter called “The Master Recordings”) and WHEREAS LICENSEE is an a position directly
or indirectly to provide manufacturing and marketing faculties for phonograph records in ( ) only
(hereinafter called “The Licensed Territory”), and warrants a release of such phonograph records.
Now therefore, in consideration of the foregoing and of the mutual promises hereinafter set forth,
it is agreed:
1.) LESSOR grants to LICENSEE the exclusive right and license to use THE MASTER
RECORDINGS for the purpose of manufacturing and selling phonograph records and/or
prerecorded tapes well known as MusiCasettes and/or 8-Track Cartridges therefrom in the
LICENSED TERRITORY.
a) LICENSEE is not authorized to transfer the right and license to use THE MASTER
RECORDINGS to a third party.
2.) LICENSEE agrees to release THE MASTER RECORDINGS under the label as a trademark
and in the form as described in the riders hereto only.
3.) a) In consideration of the rights herein granted, LICENSEE agrees to pay to LESSOR the
royalties stated in the rider A hereto as percentage of the retail list price (exclusive of sales
taxes) for all soundcarriers without any other deduction manufactured from THE
MASTER RECORDINGS leased hereunder and shipped In THE LICENSED
TERRITORY.
b) LICENSEE agrees to inform LESSOR of such retail list price in force in THE
LICENSED TERRITORY within 30 (thirty) days from uk date of countersigning of this
contract and will notify LESSOR of any changes thereof within 14 (fourteen) days of any
such change.
c) LICENSEE, agrees that it will not sell, directly or indirectly THE MASTER
RECORDINGS under the normal retail list price In THE LICENSED TERRITORY
without written permission by LESSOR.
4.) LICENSEE further agrees to pay to LESSOR Fifty (50) percent of all public performance and
broadcasting and tv fees, if any received in respect of all records manufactured, leased and sold
hereunder. provided, however, that whenever such fees are not computed and paid in direct
relation to the public perfomances and broadcasts and tv’s of such records, they shall be
computed for the purpose of the agreement by determining the proportion of any such fee
paid to LICENSEE as the number of records produced hereunder and sold in the area from
which the fee is derived bears to the total number of records sold in that area by LICENSEE.
5.) I. Statements in reasonable detail by LICENSEE to LESSOR of royalties and fees due,
pursuant to paragraph 3a and 4 hereof, shall be made every six month calendar period and
mailed to LESSOR within fourtyfive (45) days following the dose of such a period. Each
statement shall show at least the following;
a) catalogue-number of LICENSEE, title and artist(s) of each such sound-carrier
b) the quantity of sound-carriers distributed on behalf of LICENSEE during that
period
c) the quantity of sound-carrier manufactured from each master throughout the
applicable accounting period
d) the retail list price of each such sound-carrier
e) the royalty rate paid on each such sound-carrier
f ) the total royalties earned by each such sound-carrier
II. Together with the statements the payable royalties have to be received by LESSOR.
6.) In the event that by law any royalty-payment due to LESSOR hereunder cannot be
transmitted from the country in which such royalties are earned, LICENSEE agrees to notify
LESSOR within one week after such period as mentioned in paragraph 5 by registered written
letter and to put such payment at the disposal of LESSOR by depositing same at a bank-
account to be opened by LICENSEE at ist expense but in the name of LESSOR and of which
account LESSOR shall have the power of disposing only.
Abb. 4.4: Lizenzvertrag (Auschnitt)
56 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Abb. 4.5: Lizenzabrechnung (Ausschnitt)
Als Nächstes muss der Sollzustand beschrieben werden. Dieser soll ja später einen be-
stimmten Teil (oder alles) des beschriebenen Istzustands durch ein Anwendungspro-
gramm ersetzen. Es geht dabei gerade darum, dass durch Einsatz einer zu entwickelnden
Software gewisse Abläufe des Istzustands erleichtert bzw. automatisiert werden sollen.
Daher ist es wichtig, dass mit Bezug auf den Istzustand genau beschrieben wird, welche
Teile durch Software abgedeckt werden sollen und welche Inputs und Outputs dabei ge-
nau auftreten. Dies erfolgt durch die Beschreibung des Sollzustands.
SEI11 57
© HfB, 02.12.20, Berk, Eric (904709)
Sollzustand
Eine erste Beschreibung des Sollzustands erfolgte bereits in der ersten Problem-
spezifikation, die (in der Initialisierungsphase) der Angebotserstellung diente. Nun geht
es darum, diese Beschreibung zu verfeinern, sodass daraus (ggf. zusammen mit den
nächsten Kapiteln) später ein DV-Entwurf entwickelt werden kann.
Ist der Istzustand hinreichend beschrieben, dann geht es bei der Sollzustands-
beschreibung eigentlich nur noch darum, welche Teile der Realität wie auf dem Compu-
ter abgebildet werden sollen. Je nachdem, wie das Pflichtenheft strukturiert ist, kann
jetzt bereits eine ausführliche Beschreibung erfolgen, oder, falls dies später im Pflichten-
heft vorgenommen wird, eine grobe, mehr prinzipielle Darstellung. Dies sei in das Er-
messen bzw. die Gepflogenheiten der beteiligten Unternehmen gestellt. Für unsere Zwe-
cke wählen wir den Weg, dass zunächst eine allgemeine Sollbeschreibung vorgenommen
wird. Die nachfolgenden Abschnitte geben dann weitere, detailliertere Informationen.
Eine Sollzustandsbeschreibung bezogen auf unser Beispiel könnte demgemäß z. B. so
aussehen:
Das zu entwickelnde Softwareprogramm soll den Teil des Istzustands
implementieren, der die administrativen Arbeiten bei der
Vertragserstellung der Künstler- und Lizenzverträge abwickelt
sowie die Lizenzabrechnungen automatisch erstellt. Die Arbeiten
der Musikverlagsverwaltung werden dabei ausgekoppelt und evtl. zu
einem späteren Zeitpunkt ebenfalls automatisiert (eigenes
Projekt). Es sollen sowohl (freie) Produzenten als auch
Schallplattenfirmen mit dem Programm arbeiten können. In ersterem
Fall werden Künstlerverträge erstellt und abgerechnet und im
zweiten Fall Schallplattenverträge. Grundlage der Abrechnung ist
in ersterem Fall die Abrechnung des Produzenten mit dem Künstler
und in zweitem Fall die Lizenzabrechnung der Plattenfirma an den
Produzenten. Die elektronisch abzuwickelnden Realitätsausschnitte
sind nachfolgendem U-Case-Diagramm (Abb. 4.6) zu entnehmen. Die
Benutzer des zu entwickelnden Programms werden dort mit User_1
(für den ersten Fall) und User_2 (für den zweiten Fall)
bezeichnet.
58 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Abb. 4.6: U-Case-Diagramm Sollzustand (Abdeckungsbereich der Software)
Als Input für das zu schreibende Programm dienen also zum Zweck der Vertragserstel-
lung alle Angaben aus dem Künstler-/Lizenzvertrag (insbesondere die für die spätere
Abrechnung notwendigen Daten wie Vertragspartner, Vertragsdauer, prozentuale Betei-
ligungen etc.) und für die Abrechnung dann die Daten des Distributors (Payoff 1) und/
oder der Plattenfirma (Payoff 2) (z. B. über Anzahl und Verkaufspreis der verkauften
Tonträger). Der Output des Programms liefert dann die jeweiligen Verträge bzw. Ab-
rechnungen. Damit verbunden ist die Möglichkeit gewisser statistischer Auswertungen
(welcher Künstler hat wie viele Tonträger verkauft etc., siehe Problembeschreibung).
Natürlich müssen alle bereits erfolgten Abrechnungen gespeichert und doppelte Ab-
rechnungen verhindert werden. Außerdem ist eine Adressverwaltung für alle beteiligten
Firmen und Personen zu integrieren wie auch eine Tonträgerverwaltung, da sich in der
Regel auf einem Tonträger mehrere Songs (Mastertapes) befinden, die von verschiede-
nen Interpreten sein können (d. h. sich auf verschiedene Künstler-/Lizenzverträge bezie-
hen). Einzelheiten hierzu sind z. B. dem semantischen Datenmodell (vgl.
Abschnitt 4.2.2) zu entnehmen.
SEI11 59
© HfB, 02.12.20, Berk, Eric (904709)
4.2.2 Semantische Datenmodellierung

Dies ist vielleicht der wichtigste Teil des Pflichtenhefts überhaupt. Der Begriff Semantik
steht für Bedeutung oder Inhalt. Unter einer semantischen Datenmodellierung versteht
man eine Beschreibung der Datenstrukturen, die noch nicht den strengen Kriterien des
DV-Entwurfs entspricht und in einer Form geschieht, die auch vom DV-technisch nicht
geschulten Auftraggeber verstanden werden kann. In Abschnitt 2.1 wurde im Rahmen
des Wasserfallmodells in der Erläuterung der Phase DV-Konzept bereits ein Beispiel für
eine rein verbale Beschreibung als mögliche semantische Datenmodellierung gegeben.
Dies muss aber nicht immer nur rein verbal geschehen, sondern es können bereits Ele-
mente eines ER-Diagramms benutzt werden, wie es z. B. in Abb. 4.7 dargestellt ist.
Wichtig ist aber, dass der Auftraggeber diese Syntax vollständig versteht; ist dies nicht
der Fall, sollte eine rein verbale Beschreibung bevorzugt werden.
Die semantische Datenmodellierung kann in verschiedenen Detaillierungsstufen erfol-
gen. Grundsätzlich gilt: Je ausführlicher, umso besser. Allerdings kann es manchmal
auch so sein, dass durch zu detaillierte Beschreibungen (gerade bei größeren Projekten)
der Überblick verloren geht. Ein erfahrener Systemanalytiker wird hier in der Lage sein,
das Wesentliche vom Unwesentlichen zu trennen, und die Details dann erst im DV-Ent-
wurf modellieren.
4.2.2.1 Entscheidungstabellen
Mithilfe dieser Technik ist es möglich, dynamische Abläufe in kompakter Form zu be-
schreiben. Eine Entscheidungstabelle enthält in den Zeilen die jeweiligen Funktionen
und in den Spalten die Erfüllungsregeln bzw. die Reaktion, wenn ein Kriterium erfüllt
ist oder nicht.
Betrachten wir zur Erläuterung den Fall eines Programms, das zum Verleih von DVDs
in einer Videothek eingesetzt werden soll.
Beispiel 4.1:
Zunächst werden die jeweiligen Regeln („Wenn-dann-Beziehungen“) entworfen:
• Wenn der Kunde im Kundenstamm erfasst und die DVD verfügbar ist, dann soll
die DVD ausgegeben werden.
• Wenn der Kunde nicht im Kundenstamm erfasst ist, dann soll die DVD nicht
ausgegeben werden.
• Wenn der Kunde bereits 5 DVDs ausgeliehen hat, dann soll die DVD nicht aus-
gegeben und der Kunde informiert werden.
• Wenn der Kunde zum aktuellen Zeitpunkt eine oder mehrere DVDs länger als 60
Tage ausgeliehen hat, dann soll bis zur Rückgabe der ausgeliehenen DVDs keine
weitere DVD mehr ausgegeben und der Kunde informiert werden.
• Wenn die DVD nicht verfügbar ist, dann wird die DVD nicht ausgegeben und der
Kunde wird informiert.
• Eine Reservierung von DVDs ist nicht zulässig und soll daher nicht berücksich-
tigt werden.
60 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Aktionen ermitteln:
A1: DVD ausgeben
A2: DVD nicht ausgeben
A3: Kunde informieren „DVD nicht verfügbar“
A4: Kunde informieren „Anzahl überschritten“
A5: Kunde informieren „Leihdauer überschritten“
Bedingungen ermitteln:
B1: Kunde im Kundenstamm
B2: DVD verfügbar
B3: Anzahl ausgeliehener DVDs nicht größer als 5 Stück
B4: Leihdauer nicht größer als 60 Tage
Ausgangssituation:
VHS ausgeben R1 R2 R3 R4 R5 R6 R7 R8 R9
B1 Kunde im Kundenstamm J J J J J J J J N
B2 DVD verfügbar J J J J N N N N –
B3 auszugebende DVDs  5 J J N N J J N N –
B4 Leihdauer  60 Tage J N J N J N J N –
A1 DVD ausgeben 
A2 DVD nicht ausgeben        
A3 Kundeninfo 
   
„DVD nicht verfügbar“
A4 Kundeninfo 
 
„Anzahl überschritten“
A5 Kundeninfo 
 
„Leihdauer überschritten“
Nun ist es häufig so, dass nicht von vornherein die optimale Darstellung gefunden wird.
Es können dann gewisse Optimierungen erforderlich sein. Zum Beispiel liegen bei R5/
R6 und bei R7/R8 jeweils eigentlich die gleichen Aktionen zugrunde. Dies lässt sich so
vereinfachen:
SEI11 61
© HfB, 02.12.20, Berk, Eric (904709)
1. Erste Optimierung
DVD ausgeben R1 R2 R3 R4 R5/R6 R7/R8 R9
B1 Kunde im Kundenstamm J J J J J J N
B2 DVD verfügbar J J J J N N –
B3 auszugebende DVDs  5 J J N N J N –
B4 Leihdauer  60 Tage J N J N – – –
A1 DVD ausgeben 
A2 DVD nicht ausgeben      
A3 Kundeninfo 
 
A4 Kundeninfo 
 
A5 Kundeninfo
 
Auch hier kann offenbar vereinfacht werden:

2. Zweite Optimierung
DVD ausgeben R1 R2 R3 R4 R5/R6/R7/R8 R9
B1 Kunde im Kundenstamm J J J J J N
B2 DVD verfügbar J J J J N –
B3 auszugebende DVDs  5 J J N N – –
B4 Leihdauer 60 Tage J N J N – –
A1 DVD ausgeben 
A2 DVD nicht ausgeben     
A3 Kundeninfo 

A4 Kundeninfo 
 
A5 Kundeninfo 
 
62 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
3. Einfache Entscheidungstabelle nach der Optimierung
DVD ausgeben R1 R2 R3 R4 R5 R6
B1 Kunde im Kundenstamm J J J J J N
B2 DVD verfügbar J J J J N –
B3 auszugebende DVDs  5 J J N N – –
B4 Leihdauer  60 Tage J N J N – –
A1 DVD ausgeben 
A2 DVD nicht ausgeben     
A3 Kundeninfo 

A4 Kundeninfo 
 
A5 Kundeninfo 
 
4.2.2.2 Data Dictionary

Unter einem Data Dictionary versteht man die Auflistung von Datenkomponenten und
ihren Beziehungen in einem Informationssystem. Hier werden sowohl elementare als
auch zusammengesetzte Komponenten erfasst. Die Beschreibung der Daten wird häufig
mit folgender Syntax durchgeführt:
= Komponente wird definiert als
+ Verknüpfung von Komponenten (Sequenz)
(...) wahlfreie Komponente
{...} Wiederholung von Komponenten (Iteration), wobei die Zahl vor den Klammern
die Anzahl der Wiederholungen und die Zahl hinter den Klammern die maximale
Anzahl an Wiederholungen bedeutet und in der Klammer die zu wiederholende
Komponente steht
[...] Auswahl einer Komponente
| Trennung alternativer Komponenten
@ Schlüsselfeld
*...* Kommentare
SEI11 63
© HfB, 02.12.20, Berk, Eric (904709)
Beispiel:
name = anrede + vorname + (mittelname) + familienname
name ist eine Komponente, mittelname ist wahlfrei. Die rechts stehenden Komponenten
müssen aber auch definiert werden. Dies kann z. B. geschehen durch:
anrede = [Herr | Frau | Prof. | Dr.]

vorname = …
…
familienname = 3{Alphazeichen}32
Der Familienname muss also mindestens drei Zeichen und darf höchstens 32 Zeichen
lang sein.
4.2.2.3 Entity Relationship Diagram

Chen entwickelte 1976 das sogenannte Entity Relationship Model (ERM), dessen grafi-
sche Darstellung dann Entity Relationship Diagram (ERD) heißt. Es findet praktische
Anwendung hauptsächlich beim Entwurf von relationalen Datenbanken. Dieses Modell
hat u. a. den Vorteil, dass es sowohl in der Analysephase für das Pflichtenheft sowie in
verfeinerter Form im DV-Entwurf benutzt werden kann. Obwohl die Komponenten des
ERM wie z. B. der Begriff einer Entität, einer Beziehung etc. erst im nächsten Studienheft
exakt definiert werden, soll hier so weit über den Aufbau schon gesprochen werden,
dass wenigstens die grobe Version des ERD, wie sie in Pflichtenheften zur semantischen
Datenmodellierung häufig vorkommt, benutzt werden kann. Dazu betrachten wir fol-
gende Komponenten:
Entity = Objekt der Realität oder Anschauung
Relationship = Beziehung zwischen Entities, z. B. „… ist Mitarbeiter von …“
In relationalen Datenbanken werden Entitäten und Beziehungen in der Regel durch Ta-
bellen dargestellt, wobei die Namen der Spaltenüberschriften auch Attribute genannt
werden. Solche Attribute besitzen einen Wertebereich, engl. Domain, wie z. B. integer
für ganze Zahlen oder Character für Buchstaben. Entities und Relationships fasst man
bei Bedarf auch zu Mengen zusammen:
Entity set = Menge von Objekten, z. B. PERSON, PROJEKT etc.
Relationship set = Menge von Beziehungen
Bei Beziehungen spielt noch der sogenannte Assoziationstyp eine wichtige Rolle. Er
gibt an, in welchem numerischen Verhältnis die Einträge der beteiligten Entitäten ste-
hen. Die wichtigsten Assoziationstypen sind 1 : n (sprich „1 zu n“) und n : m. Beispiels-
weise hat 1 Unternehmen n Abteilungen, während in n Projekten m Mitarbeiter beschäf-
tigt sein können (siehe Abb. 4.7).
64 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Für die grafische Darstellung sind die wichtigsten Symbole:
Entity (Entität)
Relationship (Relation, Beziehung)
Attribut
Verbindungslinie
Nachfolgend sei ein Beispiel angegeben, wie es typischerweise in einem Pflichtenheft

vorkommen könnte.
1 n
Unternehmen hat Abteilung
umfasst
Mitarbeiter
m
betreut
Projekt
Abb. 4.7: Beispiel für ein Entity Relationship Diagram
Die n : m-Beziehung in Abb. 4.7 bedeutet konkret, dass an einem Projekt m Mitarbeiter
beteiligt sein können und dass jeder Mitarbeiter an n Projekten beteiligt sein kann. Zu
betonen wäre noch, dass für die Beschriftungen der Entitäten und Beziehungen der Sin-
gular verwendet wird, während in Datenflussdiagrammen üblicherweise der Plural be-
nutzt wird.
SEI11 65
© HfB, 02.12.20, Berk, Eric (904709)
4.2.2.4 Objektorientierte Analyse und Design
Objekte, Klassen und Instanzen

Es setzen sich objektorientierte Ansätze gegenüber relationalen immer mehr durch. Dies
liegt u. a. daran, dass eine objektorientierte Systemanalyse (OOA) eine bessere Abbil-
dung der Realität ermöglicht, denn dort hat man es ja gerade mit Objekten zu tun. Eine
präzise Definition des Objektbegriffs ist dabei sehr schwer. Zunächst definieren wir den
Objektbegriff ganz allgemein:
Objekt:
Unter einem Objekt versteht man eine Person oder einen Gegenstand (der Realität
oder Anschauung), auf die/den das Denken und Handeln bzw. jemandes Interesse ge-
richtet ist.
Diese Definition ist noch unkonkret, doch man versteht, dass es sich bei einem Objekt
um eine „Sache“ handelt, die wahrgenommen und hinlänglich beschrieben und über die
„nachgedacht“ werden kann. Im Software Engineering interessiert in erster Linie, wie
Objekte aus dem Leben auf den Computer abgebildet werden können. Natürlich gibt es
dabei auch Objekte, die ausschließlich auf einem Computer existieren, man denke z. B.
an eine Schaltfläche oder den Mauszeiger etc.; auch das sind Objekte, denn sie besitzen
unbestreitbar zumindest eine virtuelle Realität und man kann sein Interesse auf sie rich-
ten. Möchte man Objekte auf einem Computer abbilden, so müssen diese in Form von
Daten abgelegt werden. Und Daten auf dem Computer erfordern ein Datenformat, also
eine Datenstruktur. Die Beschreibung von Datenstrukturen und ihren Beziehungen
nennt man auch Datenmodell. Das ist aber noch nicht alles. Auf Daten muss man zu-
greifen können, d. h., man benötigt Zugriffsoperationen wie Edit, Delete, Add usw.; au-
ßerdem fasst man ähnliche Daten häufig zusammen. Es muss also Kriterien geben, die
die Zugehörigkeit (auch Integrität genannt) festlegen. Solche Zugehörigkeitskriterien
nennt man auch Integritätsbedingungen. Grob kann man also sagen, was für ein Objekt
im datentechnischen Sinn gelten muss:
Objekt = Datenstruktur + Operationen + Integritätsbedingungen

Objektmodell = Datenmodell + Operationen + Integritätsbedingungen
Dadurch, dass also auch Operationen zu einem Objekt gehören, sind die Daten eines Ob-
jekts selbst nur über diese Operationen zugänglich. Man redet in diesem Zusammen-
hang von Datenkapselung. Die Operationen werden dabei als Funktionen implementiert
und dann Methoden genannt (vgl. Abb. 4.8). Ein erstelltes Datenmodell wird manchmal
auch Schema genannt.
66 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Zugriff
Methode 1 Methode 2
Methode 3 ...
Daten
... ...
... Methode n
Abb. 4.8: Datenkapselung in einem Objekt
Der Vorteil solch einer Vorgehensweise liegt auf der Hand: Die Methoden zum Zugreifen
auf die Objektdaten basieren in der Regel auf bereits vorhandenen Standardoperationen,
die z. B. von einem Datenbankmanagementsystem zur Verfügung gestellt werden. Diese
muss man also nicht erst selbst programmieren, was die Fehleranfälligkeit eines Pro-
gramms natürlich deutlich reduziert. Natürlich ist es auch möglich, Methoden selbst zu
schreiben, doch diese benutzen dann meistens wieder bereits vorhandene Standardme-
thoden und komponieren daraus die gewünschte Funktionalität.
Objekte, die in irgendeinem Sinne zusammengehörig sind, werden in sogenannte Klas-
sen zusammengefasst. Es muss also ein Kriterium geben, mit dem die Zusammengehö-
rigkeit von Objekten bestimmbar ist. In der 5. Schulklasse einer Grundschule beispiels-
weise sitzen Kinder (Objekte), denen gemeinsam ist, dass sie alle die 4. Klasse hinter sich
gebracht haben, einer bestimmten Altersgruppe angehören, einen bestimmten (Klassen-
)Lehrer haben, in einem bestimmten (Klassen-)Zimmer sitzen, einen bestimmten Stun-
denplan haben usw.; in der Mathematik kennt man u.a. Restklassen. Darunter versteht
man die Zusammenfassung von denjenigen ganzen Zahlen, die bei Division durch eine
festgelegte Zahl den gleichen Rest besitzen. Betrachtet man z. B. die Menge {..., 7, 11, 15,
19...}, so handelt es sich hierbei um die Klasse der ganzen Zahlen, welche bei Division
durch die Zahl 4 alle den gleichen Rest, nämlich 3, besitzen. Dieser Klassenbegriff führt
zur nächsten Definition.
SEI11 67
© HfB, 02.12.20, Berk, Eric (904709)
Klasse:
Unter einer Klasse versteht man eine Menge von zusammengehörigen Objekten. Eine
atomare Klasse ist eine Klasse mit nur einfachen (also nicht zusammengesetzten) Ob-
jekten.
Instanz:
Die Objekte einer Klasse werden auch Instanzen oder Exemplare der Klassen genannt.
Instanzen oder Exemplare einer Klasse können prinzipiell selbst wieder Klassen sein. Es
sei bemerkt, dass sich die Menge der Exemplare einer Klasse mit der Zeit verändern
kann. Daher sind eine Klasse und ihre Exemplarmenge i. A. nicht dasselbe.
UML-Diagramme
In einem Pflichtenheft können bereits grafische Elemente zur Datenmodellierung einge-
setzt werden. Ein Beispiel hatten wir schon gesehen, das Entity-Relationship-Diagramm
(ERD).
Seit geraumer Zeit hat sich allerdings die sogenannte Unified Modeling Language
(UML) etabliert. Dabei handelt es sich um Sammlung von Modellierungstechniken, die
sich durch eine Vielzahl von Diagrammtypen auszeichnet. Diese werden in nachfolgen-
den Studienheften ausführlich beschrieben und sind vor allem für den DV-Entwurf ein-
gesetzt. Allerdings setzen sich mehr und mehr auch im Pflichtenheft einige rudimentäre
UML-Ansätze durch. Wichtig ist dabei immer, dass auch der Kunde des Pflichtenhefts
die Ausführungen verstehen kann. Sollte er dazu nicht in der Lage sein, sollte man diese
Techniken nicht einsetzen und stattdessen die Datenstrukturen und Funktionsabläufe
verbal so präzise wie möglich beschreiben. Allerdings sollten auch die Diagramme,
wenn sie denn verwendet werden, noch einmal durch Text erläutert werden.
Klassendiagramme:
Diese Modellierungstechnik wird zur Beschreibung statischer Sachverhalte benutzt (wie
auch schon das ERD). Im Gegensatz zum Standard-ERD sind bei UML-Klassendiagram-
men weitergehende Sachverhalte darstellbar (z. B. Vererbungen, Aggregationen, siehe
nachfolgend).
Wir hatten definiert, dass Klassen eine Zusammenfassung zusammengehöriger Objekte
darstellen8. Die Zusammengehörigkeit wird dabei über Eigenschaften, sogenannte Inte-
gritätsbedingungen, definiert. Eine Schulklasse einer Grundschule besteht beispielswei-
se aus den Objekten „Schüler“, die alle gemeinsame Eigenschaften besitzen: Sie sind
(meistens) ungefähr gleich alt, gehören zum gleichen Einzugsgebiet einer Stadt, haben
bereits die vorhergehende Klasse erfolgreich absolviert (Versetzung) und so weiter. Von
einer gewissen Abstraktionsstufe aus gesehen sind diese „Objekte“ (bezüglich ihrer In-
tegritätsbedingungen) sogar „ununterscheidbar“. Jedes Objekt stellt dabei einen Reprä-
sentanten der ganzen Klasse dar. Objekte werden auch Instanzen oder Exemplare einer
Klasse genannt.
8. Wir folgen hier teilweise Zöller-Greer, 2010b
68 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Klassen werden in UML durch Rechtecke dargestellt, die wieder in 3 Abteilungen unter-
teilt sind: Oben steht der Klassenname, in der Mitte stehen die Attribute und im unteren
Teil die Methoden, mit denen auf die Objekte der Klasse zugegriffen werden kann. Au-
ßer dem Klassennamen sind alle anderen Einträge optional. Die Beziehungen zwischen
Klassen werden durch Verbindungslinien ausgedrückt, die auch beschriftet werden kön-
nen („Rolle“ der Beziehung).
In Abb. 4.9 sehen wir ein Beispiel für ein solches Klassendiagramm und in Abb. 4.10 für
ein Objektdiagramm. Objektdiagramme sehen ähnlich wie Klassendiagramme aus, je-
doch beziehen sich die Beschriftungen innerhalb der Rechtecke und der Verbindungsli-
nien jetzt auf konkrete Objekte der Klassen (je nach Literatur wird manchmal auch im
Objektnamen zuerst das Objekt, dann der Doppelpunkt und dann der Klassenname ge-
nannt).
An den Verbindungslinien werden bei dem Beziehungstyp „Assoziation“ noch die soge-
nannten Kardinalitätsbeschränkungen mit angegeben. Dabei handelt es sich um die Ma-
ximalzahlen, mit denen ein konkretes Objekt einer Klasse mit Objekten einer weiteren
(oder sogar der gleichen) Klasse eine Beziehung (Link) eingehen kann (siehe auch weiter
unten den Begriff der Rolle). Die wichtigsten sind:
* für kein oder viele
1..* für ein oder viele (auch lesbar als: mindestens 1, maximal viele)
0..1 für kein oder ein (auch lesbar als: mindestens 0, maximal 1)
1 für genau ein (diese 1 kann auch ganz weggelassen werden)
2..4 für numerische Angaben, hier: 2, 3 oder 4.
Abb. 4.9: Klassendiagramm mit Assoziation und Kardinalitätsbeschränkungen
Eine Assoziation wird als eine Gruppe von Links definiert, wobei ein Link eine Verbin-
dung zwischen einander zugeordneten Objekten bezeichnet (bei 2 an einer Assoziation
beteiligten Klassen werden dann auf Instanzenebene jeweils immer genau 2 Objekte ei-
nander zugeordnet). Auf Instanzenebene werden daher im Objektdiagramm die Kardi-
nalitäten aller Links immer genau 1 betragen, und diese 1 wird in der Regel in den Dia-
grammen weggelassen.
Man kann sich eine Klasse häufig als eine Tabelle vorstellen; die Attribute der Klassen
stellen dann die Spalten einer solchen Tabelle dar, die Zeilen der Tabelle entsprechen den
Objekten. Die Assoziationen zwischen den Klassen werden in Tabellen in der Regel so
implementiert, dass man die entsprechenden sogenannten Schlüsselattribute einer Ta-
belle (das sind diejenigen Attribute, die einen Datensatz, d. h. also eine Zeile in der Ta-
belle, eindeutig identifizieren und deren Anzahl minimal ist, z. B. einfach eine fortlau-
fende Nummer, „ID“ für „Identität“) als Spalte in der anderen Tabelle einfügt (bei Eins-
SEI11 69
© HfB, 02.12.20, Berk, Eric (904709)
zu-viele-Beziehungen) oder die Schlüsselattribute aus beiden zueinander in Beziehung

stehenden Tabellen in eine weitere, neue Tabelle schreibt und die gewünschten Daten-
sätze der beiden Tabellen zueinander in Beziehung setzt. In Abb. 4.11 sind z. B. die At-
tribute P_ID und M_ID fortlaufende Nummern, die jedes Projekt und jeden Mitarbeiter
eindeutig identifizieren. Macht man jetzt aus jeder der Klassen Tabellen, so ist die Klasse
M_P eine „Beziehungstabelle“, wo die „passenden“ P_IDs und M_IDs kombiniert wer-
den.
Abb. 4.10: Objektdiagramm mit Links
Manchmal besitzen Assoziationen eigene Attribute. Diese werden dann Linkattribute

genannt und die dazugehörige Klasse als Assoziationsklasse bezeichnet (vgl. Abb. 4.11).
Abb. 4.11: Klassendiagamm mit Assoziationsklasse
70 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Der Grund dafür ist folgender: Es kann Attribute geben, wie z. B. „Tätigkeit“ in
Abb. 4.11, die weder in die Klasse „Mitarbeiter“ aufgenommen werden können (da die
Tätigkeit eines bestimmten Mitarbeiters in verschiedenen Projekten jeweils eine andere
sein kann) noch der Klasse „Projekt“ zugeordnet werden können (da im gleichen Projekt
verschiedene Mitarbeiter verschiedene Tätigkeiten ausüben können). Deswegen bezieht
sich das Attribut „Tätigkeit“ nur auf den konkreten Link. Die Klasse um diese Link-At-
tribute „herum“ ist dann die Assoziationsklasse.
Ich möchte an dieser Stelle einem weitverbreitenden Irrtum entgegentreten, und zwar in
Bezug auf die Beschriftung der Kardinalitäten in Zusammenhang mit den Rollen. Be-
trachten wir zu diesem Zweck folgendes Beispiel: Eine Schallplattenfirma schließt einen
Vertrag mit einem Künstler ab. In der Musikbranche ist es dabei üblich, dass ein Künstler
immer exklusiv an eine (Schall-) Plattenfirma gebunden ist, während eine Plattenfirma
viele Künstler unter Vertrag haben kann. In Abb. 4.12 sehen wir dazu ein mögliches
Klassendiagramm:
Abb. 4.12: Beispiel Plattenfirma, Sicht 1
In dieser Kardinalitätenschreibweise wird folgende Sicht vertreten:
Sicht 1 (Rolle):
Es wird an der Klasse aufgezählt, wie oft ein Exemplar dieser Klasse an einem Link
mit einem Exemplar der gegenüberliegenden Klasse teilnehmen kann.
Nun gibt es aber verwirrenderweise eine zweite Sichtweise, die zwar denselben Sach-
verhalt zum Ausdruck bringt, aber eine andere Sicht auf die Assoziation darstellt
(Abb. 4.13):
Abb. 4.13: Beispiel Plattenfirma, Sicht 2
Wie man sieht, sind jetzt die Kardinalitätsbeschränkungen vertauscht. In dieser Sicht-
weise gilt:
SEI11 71
© HfB, 02.12.20, Berk, Eric (904709)
Sicht 2 (inverse Rolle):

Es wird an der gegenüberliegenden Klasse aufgezählt, wie viele Links ein Exemplar
der aktuellen Klasse mit Exemplaren der gegenüberliegenden Klasse eingehen kann.
Die Sicht der inversen Rolle hat sich interessanterweise mehr verbreitet als die der Rolle.
Um Mehrdeutigkeiten zu vermeiden, kann es nicht schaden, wenn man bei der Erstel-
lung von Klassendiagrammen z. B. mithilfe einer Legende hinschreibt, welche Sicht man
gerade einnimmt.
Während Assoziationen „hat“-Beziehungen zwischen Klassen realisieren, stellen die so-
genannten Spezialisierungen (je nach Sichtweise auch Generalisierungen oder Verer-
bungen genannt) Variationen einer Klasse im Sinne einer „ist-ein“-Beziehung dar.
Abb. 4.14 liefert dazu ein Beispiel: Es gibt eine Klasse „Person“ mit den beiden Variati-
onen „Kunde“ und „Lieferant“. Die Verbindungslinien besitzen einen holen Pfeil am
Ende der Basisklasse (auch Oberklasse genannt); die Variationen werden auch abgelei-
tete Klassen, Subklassen oder Unterklassen genannt. Letztere ererben von der Basisklas-
se eventuelle Attribute, Methoden und Assoziationen. Optional kann in der Nähe des
Pfeils noch in geschweiften Klammern ein Eintrag vorgenommen werden, der Folgendes
bedeutet:
complete heißt, die Basisklasse enthält keine eigenen Instanzen
incomplete heißt, die Basisklasse kann eigene Instanzen haben
overlapping heißt, gleiche Objekte können gleichzeitig in mehreren Unterklassen
vorkommen
disjoint heißt, ein Objekt einer Subklasse kann nicht noch in einer weiteren
Subklasse vorkommen
Abb. 4.14: Generalisierung (Spezialisierung, Vererbung)
72 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Konkret ist es also so, dass man Personen hat, die Kunde, Lieferant, keines von beiden
oder beides sein können. Hätte man statt {incomplete, overlapping} die Vererbungstypen
{complete, overlapping}, so würde das bedeuten, dass jede Person Kunde oder Lieferant
(oder beides) ist, d. h., es gibt keine Person, die nicht mindestens eines von beidem ist. In
diesem Fall nennt man die Basisklasse auch „abstrakt“, weil sie ja keine eigenen Instan-
zen besitzt (diese finden sich erst in den Subklassen). Würde im hinteren Teil statt „over-
lapping“ jetzt „disjoint“ stehen, so würde das bedeuten, dass ein Kunde nicht gleichzeitig
Lieferant sein kann und umgekehrt.
Noch ein Wort zu den drei „fast“ synonymen Begriffen Spezialisierung, Generalisierung
und Vererbung. Das Ergebnis ist in allen drei Fällen das gleiche, z. B. das Diagramm aus
Abb. 4.14. Der Unterschied besteht nur in der Sichtweise bzw. in der praktischen Vorge-
hensweise, also wie man zu dem Diagramm kommt. Beginnt man seine Systemanalyse
damit, dass man zuerst die Klasse Person modelliert und danach feststellt, dass es davon
zwei Variationen, nämlich Mitarbeiter und Lieferanten, gibt, so „spezialisiert“ man diese
Klasse in die beiden genannten Subklassen. Fängt man dagegen so an, dass man zuerst
die Klassen Mitarbeiter und Lieferant erstellt und dann feststellt, dass diese gleichlau-
tende Attribute haben (wie z. B. Name, Ort etc.), dann „zieht“ man diese gemeinsamen
Attribute „nach oben“ in eine eigens dafür neu einzuführende Klasse, die man dann z. B.
Person nennt. Dieser Vorgang wäre die Generalisierung. Betrachtet man jetzt aber, was
welche Klasse anderen Klassen zur Verfügung stellt („vererbt“), wie z. B. die Attribute
aus der Basisklasse den Subklassen, so nennt man den Mechanismus des „Zurverfügung-
stellens“ eine „Vererbung“. Vererbt werden können neben den Attributen auch die Me-
thoden und evtl. Assoziationen an die Basisklasse.
Im Beispiel aus Abb. 4.14 könnte die Klasse Person z. B. die Attribute Name, PLZ, Ort
haben. Diese werden dann an die Subklassen vererbt und werden daher dort nicht noch
einmal genannt (obwohl es sie dort gibt!). In den Subklassen werden nur noch diejenigen
Attribute genannt, die der jeweiligen Subklasse allein zu eigen sind.
Man muss aber aufpassen, wenn man aus solchen Gebilden wie in Abb. 4.14 Tabellen
machen will. Dann macht man zwar – wie üblich – auch aus jeder Klasse zunächst eine
Tabelle, doch die Vererbung muss zuvor in eine Assoziation „umgewandelt“ werden,
was möglich ist (allerdings unter Verlust der Vererbungstypisierung wie complete und
overlapping etc.). Um Vererbungen als Assoziationen darzustellen, muss man zwischen
der Basistabelle und jeder Subtabelle eine 1-zu-0..1-Assoziation herstellen. „Philoso-
phisch“ besteht aber dann ein deutlicher Unterschied: Während z. B. eine Instanz von
„Person“ mit der Variation „Kunde“ ein einziges Objekt liefert, entstehen bei der 1-zu-
0..1-Assoziation 2 Objekte (die über einen Link in Beziehung zueinander stehen). In Ta-
bellenform gibt es dann also keine abstrakten Klassen mehr, denn die Tabelle „Person“
hat dann natürlich konkrete Einträge in ihren Zeilen stehen, auf die in den beiden Sub-
tabellen Mitarbeiter und Lieferant passend referenziert wird.
Im Rahmen der Klassendiagramme spielt noch ein Spezialfall der Assoziation eine große
Rolle: die Aggregation. Aggregationen sind Assoziationen, von denen man weiß, dass
sie zusätzlich eine Gesamtheits-Teil-Beziehung darstellen (vgl. Abb. 4.15).
SEI11 73
© HfB, 02.12.20, Berk, Eric (904709)
Abb. 4.15: Aggregationen
Aggregationen besitzen wieder selbst einen Spezialfall: sogenannte Kompositionen. Dies

sind Aggregationen, die sich auf einen „lebensnotwendigen“ Teil der Gesamtheit bezie-
hen, der also nicht weggelassen werden kann. Bei Kompositionen wird die kleine Raute
dann schwarz ausgefüllt.
Zustandsdiagramme:
Zustandsdiagramme dienen zur Beschreibung dynamischer Sachverhalte. Dazu ist es
häufig hilfreich, wenn der Ablauf der zu automatisierenden Arbeitsgänge durch gewisse
Szenarien ausgedrückt wird. Dadurch werden die zeitlichen Abläufe und Reihenfolgen
gewisser Aktionen deutlich. Dies ist insbesondere manchmal wichtig für gewisse Ab-
hängigkeiten der Daten untereinander. So können z. B. manche Berechnungen erst dann
ausgeführt werden, wenn zeitlich vorher bestimmte Daten eingegeben wurden.
Die Beschreibung solcher Zeitabhängigkeiten kann – wie erwähnt – durch gewöhnliche
verbale Beschreibung der Abfolgen geschehen und/oder durch standardisierte Zu-
standsdiagramme. Letztere beschreiben die zeitliche Abfolge wichtiger Änderungen am
Zustand des Systems. Jede Eingabe, Ausgabe oder sonstige Aktion der Software, wie z. B.
eine Berechnung, verändert den aktuellen Zustand der Software bzw. der Hardware
(z. B. des Bildschirms oder des Druckers oder der Festplatte). Ein Beispiel für eine verbale
Szenenbeschreibung in Verbindung mit einem entsprechenden U-Case-Diagramm fin-
det man in der Ist-/Sollzustandsbeschreibung in Abschnitt 4.2.1.
Ein Zustandsdiagramm beschreibt eine hypothetische Maschine, die sich zu jedem Zeit-
punkt in einer Menge endlicher Zustände befindet. Sie besteht aus:
• einem Anfangszustand
• einer endlichen Menge von Zuständen
• einer endlichen Menge von Ereignissen
• einer endlichen Anzahl von Transaktionen, die den Übergang des Objektes vom ei-
nen zum nächsten Zustand beschreiben
• einem oder mehreren Endzuständen
74 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Abb. 4.16: Notation Zustandsdiagramme
In Zustandsdiagrammen werden Zustände als abgerundete Rechtecke, verbunden durch

Pfeile, auf denen die Transaktionen stehen, dargestellt. Anfangszustand ist ein gefüllter
Kreis, der Endzustand ist ein leerer Kreis mit einem kleinen gefüllten Kreis in der Mitte.
Sequenzdiagramme:
Mittels Sequenzdiagrammen beschreibt man die Interaktionen zwischen den Modellele-
menten. Jedoch steht beim Sequenzdiagramm der zeitliche Verlauf des Nachrichtenaus-
tausches im Vordergrund. Die Zeitlinie verläuft senkrecht von oben nach unten, die Ob-
jekte werden durch senkrechte Lebenslinien beschrieben und die gesendeten
Nachrichten waagerecht entsprechend ihrem zeitlichen Auftreten eingetragen.
SEI11 75
© HfB, 02.12.20, Berk, Eric (904709)
Abb. 4.17: Notation Sequenzdiagramm
Die Objekte werden durch Rechtecke visualisiert. Von ihnen gehen die senkrechten Le-
benslinien aus, dargestellt durch gestrichelte Linien. Die Nachrichten werden durch
waagerechte Pfeile zwischen den Objektlebenslinien beschrieben.
Auf diesen Pfeilen werden die Nachrichtennamen in der Form
nachricht(argumente)
notiert. Nachrichten, die als Antworten deklariert sind, erhalten die Form
antwort: =nachricht(...).
Den Nachrichten können Bedingungen der Form
[bedingung] nachricht(...)
zugewiesen werden.
Iterationen von Nachrichten werden durch ein Sternchen „*“ vor dem Nachrichtenna-
men beschrieben. Objekte, die gerade aktiv an Interaktionen beteiligt sind, werden
durch einen Balken auf ihrer Lebenslinie gekennzeichnet. Objekte können während des
zeitlichen Ablaufs des begrenzten Kontextes erzeugt und gelöscht werden.
Ein Objekt wird erzeugt, indem ein Pfeil mit der Aufschrift neu() auf ein neues Objekt-
symbol trifft.
76 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Abb. 4.18: Beispiel für ein Sequenzdiagramm im CASE-Tool Innovator
Aktivitätsdiagramme:
Aktivitätsdiagramme ähneln den Zustandsdiagrammen. Der Schwerpunkt liegt jedoch
im Verhalten des Systems und beschreibt hauptsächlich die Vernetzung elementarer Ak-
tionen. Dabei sind Kontroll- und Datenflüsse ablesbar. Oft wird damit der Ablauf eines
Anwendungsfalls beschrieben (wie schon bei U-Case-Diagrammen, es können sogar die
Strichmännchen von dort zum Einsatz kommen). Ein Aktivitätsdiagramm kann aber
auch zur Modellierung aller Aktivitäten eines Systems benutzt werden.
Nun gibt es zwei Ausprägungen des Aktivitätsdiagramms: In der aktuellen, neueren
Form von UML (UML 2 genannt) wird die Darstellung sogenannter nebenläufiger Sys-
teme durch die Einbindung von asynchronen Kommunikationsmechanismen (Signal
senden und empfangen, Ausnahmebehandlung) ermöglicht. Ein Aktivitätsdiagramm
spezifiziert also die eigentlichen Aktivitäten. Im Prinzip stellt ein Aktivitätsdiagramm
die objektorientierte Adaption eines Programmablaufplans dar. Ein Beispiel sehen wir
in Abb. 4.19.
SEI11 77
© HfB, 02.12.20, Berk, Eric (904709)
Abb. 4.19: Aktivitätsdiagramm (UML 2)
In Abb. 4.19 sehen wir ein einfaches Aktivitätsdiagramm mit einem Kopf- und einem
Inhaltsbereich. Am rechten und linken Rand sieht man zwei Rechtecke. Diese bezeichnet
man als „Aktivitätsparameterknoten“. Die Aktionen sind die Rechtecke mit abgerunde-
ten Ecken. Dort sind kleine Quadrate an den Rändern zu erkennen. Sie beschreiben die
Ein- und Ausgabe-Pins und deuten an, dass hier ein Objektfluss vorliegt. Der Rest stellt
Kontrollflüsse dar. Der schwarze Kreis ist der Startknoten und gehört damit zu den Kon-
trollknoten.
Aus Gründen der Historie sei noch ein Beispiel für die ältere UML-Variante der Aktivi-
tätsdiagramme (UML 1) angegeben (Abb. 4.20).
78 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Abb. 4.20: Aktivitätsdiagramm (UML 1)
Abgerundete Rechtecke stellen hier allerdings Zustände dar (wie im Zustandsdia-

gramm), während bei UML 2 damit Aktionen gekennzeichnet werden. Die dicken hori-
zontalen Balken werden Parallelisierungs- und Synchronisationsknoten (oder -balken)
genannt und können Transitionen verzweigen oder zusammenführen. Eine Raute wird
ebenfalls dazu benutzt, die Verzweigung einer Transition zu visualisieren; die Verzwei-
gungsbedingungen stehen dann an der jeweiligen Verzweigung.
Ob und welche der genannten Diagrammtypen im Pflichtenheft zum Einsatz kommen,
hängt dann – wie gesagt – von der Art des Projekts ab und davon, ob auch der Kunde
(Auftraggeber) diese Diagramme lesen kann.
SEI11 79
© HfB, 02.12.20, Berk, Eric (904709)
4.2.3 Projektplan
Schließlich muss im Pflichtenheft noch eine Zeitplanung enthalten sein, die eine realis-
tische Entwicklungszeit wiedergibt. Je nach Komplexität des Projekts kann die Darstel-
lung unterschiedlich sein. Reicht eine tabellenförmige Aufstellung nicht aus, können
auch computergestützte Werkzeuge wie z. B. MS Project® benutzt werden. Ein Projekt-
plan muss auf jeden Fall enthalten, welche Personen zu welchem Zeitpunkt welche Tei-
laufgabe lösen. Dabei sollten Meilensteine eingebaut werden, die durch Reviews beim
Auftraggeber mit demselben „abgenommen“ werden. Durch eine solche Bestätigung des
Erreichens von Teilzielen durch den Auftraggeber erhöht sich die Sicherheit, dass die
Programmentwicklung auf dem richtigen Weg ist.
Abb. 4.21: Beispiel für einen einfachen Projektplan
4.1 Welches sind die wichtigsten Daten bei der Planung eines Softwareprojekts?
4.2 Welche Punkte des Pflichtenhefts nach DIN 69901 sind Ihrer Meinung nach bei
kleineren Projekten nicht so wichtig?
4.3 Entwerfen Sie ein semantisches Datenmodell für den in Abb. 4.7 gezeigten Sach-
verhalt. Erfinden Sie einige Attribute zu den Entitäten und geben Sie eine verbale
Version des semantischen Datenmodells an.
80 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
A. Lösungen der Aufgaben zur Selbstüberprüfung

1.1 Bei den Ingenieurwissenschaften ist schon immer selbstverständlich, dass zuerst
ein Bauplan von einem Architekten gemacht wird und anschließend, wenn der
Kunde damit zufrieden ist, das Haus gemauert wird. Im SE war das nicht immer
so. Häufig wurde „drauflosgemauert“, also kein ausreichender Bauplan für die zu
entwickelnde Software entworfen. Ziel des SE ist es in erster Linie, das Entwi-
ckeln eines „Softwarebauplans“ zu ermöglichen. Dazu werden ingenieurwissen-
schaftliche Methoden eingesetzt.
1.2 Der „Realzustand“, der vor allem in den 60er-Jahren des 20. Jahrhunderts vor-
herrschte, hatte eine vorausschauende Planung im Hintergrund. Es wurde daher
häufig sehr viel Zeit für das eigentliche Programmieren und wenig für eine Sys-
temanalyse verwendet. So kam es, dass aufwandsmäßig häufig max. 30 % für die
Planung und 70 % für die Programmierung verwendet wurden. Der Gesamtauf-
wand, der als Flächeninhalt unter der Kurve aufgefasst werden kann, war zudem
sehr hoch. Wird ein softwareengineeringtechnisches Vorgehen nach einem Pha-
senmodell durchgeführt, so kann erwartet werden, dass für die Planungs- und
Analysephasen ca. 70 % und für die reine Programmierung nur noch 30 % auf-
gewendet werden müssen. Außerdem ist die Fläche unter der Kurve, also der Ge-
samtaufwand, deutlich niedriger.
2.1 Phasenmodelle dienen der systematischen Planung eines Softwareprojekts. Da-
mit soll erreicht werden, dass der Gesamtaufwand minimal und ökonomisch
wird.
2.2 a) Initialisierungsphase
b) Fachkonzept
c) Fachkonzept
d) Fachkonzept für semantisches Datenmodell, DV-Entwurf für logisches Da-
tenmodell
e) Planung im Fachkonzept, Durchführung in der Testphase
2.3 Vorteil des Spiralmodells ist seine Flexibilität gegenüber Planungsfehlern. Wäh-
rend z. B. im Wasserfallmodell ein Fehler des Fachkonzepts oft erst in der Test-
phase erkannt wird und damit eine Rückkopplung über mehrere Phasen hinweg
erforderlich ist, so ist dies im Spiralmodell relativ unproblematisch, da immer
„stückweise“ analysiert, entworfen, implementiert und getestet wird. Nachteil
des Spiralmodells ist sein offenes Ende, was zu unkontrolliertem Gesamtauf-
wand führen kann.
2.4 Das Diamantmodell dient zur Erstellung von Multimediaprogrammen. Hierfür
ist wegen der verhältnismäßig teuren Hard- und Softwareressourcen eine eigene
Planung erforderlich. Daher wird in drei Dimensionen geplant: über die Perso-
nal-Zeit-Ebene (was der traditionellen Planung entspricht) sowie über die Res-
sourcen-Zeit-Ebene (wo die Einteilung dafür vorgenommen wird, welche Res-
source zu welchem Zeitpunkt wem zur Verfügung steht).
SEI11 81
© HfB, 02.12.20, Berk, Eric (904709)
A Lösungen der Aufgaben zur Selbstüberprüfung
2.5 Da es sich hier um eine „Kreativ-Aufgabe“ handelt, kann hier keine feste Lösung
angegeben werden. Sie können aber gern Ihre Lösung an den zuständigen Tutor
leiten, dieser wird sie dann gern kommentieren. Jede „wohlbegründete“ Lösung
ist richtig!
3.1 Wie schon erwähnt bleibt die Bedienoberfläche letztlich Geschmackssache; al-
lerdings kann man objektiv feststellen, dass im SuperConverter die wichtigsten
Parameter für eine Formatwandlung auf „einen“ Blick sichtbar sind. Im oberen
Teil wählt man Ziel-Container und Ziel-Formate aus einer vorgegebenen Liste
aus und stellt dann die Parameter per Mausklick in den darunterliegenden Ab-
schnitten ein, die je nach Formatauswahl oben bereits die möglichen Einstellun-
gen angepasst anbieten. Dies ist sehr effektiv und vermeidet vor allem, hier Pa-
rameter auf Werte einzustellen, die das Zielformat gar nicht verarbeiten kann.
Insgesamt ist diese Oberfläche allerdings etwas gewöhnungsbedürftig.
Der MediaCoder hingegen kommt fast „klassisch“ daher: Es finden sich zur Aus-
wahl der Formate die üblichen Tabs, wo man neben den Formaten auch die je-
weiligen Parameter angeben kann. Dies geht aber auf Kosten der Übersicht, wes-
wegen ein eigenes kleines Fenster „Properties“ rechts oben eingeblendet wird,
wo ansatzweise die Parameter sichtbar sind. Allerdings kommt es hier oft zu
„Fehlläufen“, denn erst beim Start wird festgestellt, ob die ausgewählten Parame-
ter zu dem gewünschten Zielformat „passen“, was sehr ärgerlich sein kann. Es
erscheint auch nur der Hinweis, dass die Parameter so nicht zusammenpassen,
es wird aber kein Hinweis gegeben, welche Werte die Parameter annehmen dür-
fen. Dieses Problem stellt sich beim SuperConverter nicht, da hier nach Format-
auswahl nur die zulässigen Möglichkeiten eingeblendet werden.
Im Ergebnis sind beide Oberflächen softwareergonomisch, doch liefert der Su-
perConverter – hat man sich einmal an diese Oberfläche gewöhnt – den schnel-
leren und auch bedienerfreundlicheren Überblick
4.1 Es muss klar sein, welche Funktionen ein Programm ausführen soll. Dazu gehört
insbesondere, dass der Realitätsausschnitt, den das Programm später abdecken
soll, z. B. mit einem U-Case-Diagramm beschrieben wird. Die Entitäten in dem
U-Case-Diagramm sollten inhaltlich über die wichtigsten Attribute beschrieben
sein. Weiterhin sollen die Input-/Output-Inhalte klar sein sowie ein grobes Lö-
sungskonzept existieren, das angibt, wie vom Input zum Output gelangt werden
kann. Eine zumindest grobe Personal-Einsatzplanung darf auch nicht fehlen
(wer macht wann was).
4.2 Die Unternehmenscharakteristik spielt i. d. R. keine besondere Rolle. Auf ein
Mengengerüst kann oft auch verzichtet werden, da heute Datenbanksysteme
oft „von Hause aus“ mit Millionen von Datensätzen problemlos umgehen kön-
nen.
82 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
Lösungen der Aufgaben zur Selbstüberprüfung A
4.3 Ein Unternehmen ist gekennzeichnet durch einen Namen und einen Sitz (Straße,
PLZ, Postfach, PLZ-Ort, Straßen-Ort, Telefon, Fax, E-Mail). Es sollen mehrere
Unternehmen erfasst werden können. Jedes Unternehmen hat mehrere Abtei-
lungen. Jede Abteilung hat einen Namen, ein Abteilungskürzel sowie eine Tätig-
keitsbeschreibung. Jede Abteilung umfasst mehrere Mitarbeiter. Ein Mitarbeiter
ist gekennzeichnet durch seinen Namen und eine Personalnummer, sein Ge-
burtsdatum, seinen Wohnort (Straße, PLZ, Ort, Tel.-Nummer, Fax, E-Mail) sowie
das Datum seines Eintritts in die Firma. Ein oder mehrere Mitarbeiter betreuen
ggf. ein oder mehrere Projekte. Jedes Projekt besitzt einen Namen, ein Projekt-
kürzel, eine Projektbeschreibung, ein Startdatum sowie ein geplantes Enddatum.
SEI11 83
© HfB, 02.12.20, Berk, Eric (904709)
B. Literaturverzeichnis
Allgemein:
Greenfield, J. und Short, K. (2006). Software Factories. 
Heidelberg: Redline GmbH.
König, W. u. a. (1999). Taschenbuch der Wirtschaftsinformatik und Wirtschaftsmathe-
matik. Frankfurt am Main: Harri Deutsch.
Nielsen, J. (2000). Erfolg des Einfachen. Markt+Technik.
Rumbaugh, J. u. a. (1991). Object Oriented Modeling and Design. 
Englewood Cliffs, Prentice Hall Inc.
Zöller-Greer, P. (2002). Softwareengineering für Ingenieure und Informatiker. 
Wiesbaden: Vieweg.
Zöller-Greer, P. (2010). Multi Media Systeme. 
Wächtersbach: Composia.
Zöller-Greer, P. (2010). Software Architekturen-Grundlagen und Anwendungen. 
Wächtersbach: Composia.
Zum Testen:
Meyers, G. J. (1979). The Art of Software Testing. 
New York: John Wiley & Sons.
Realzeitsysteme:
Gomaa, H. (1999). Software Design Methods for Concurrent and Real-Time-Systems.
Addison-Wesley.
Software-Ergonomie:
Herczeg, M. (2009). Theorien, Modelle und Kriterien für gebrauchstaugliche interaktive
Computersysteme. 
Oldenbourg, München.
84 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
C. Abbildungsverzeichnis
SEI11
Sachwortverzeichnis
Abb. 1.1 Lebenszyklus einer Softwareentwicklung ................................................ 4

Abb. 1.2 System mit geplanten Reaktionen ............................................................. 5
Abb. 2.1 Wasserfallmodell ......................................................................................... 9
Abb. 2.2 Vereinfachtes Spiralmodell ......................................................................... 19
Abb. 2.3 Spiralmodell nach Boehm .......................................................................... 20
Abb. 2.4 V-Modell ...................................................................................................... 21
Abb. 2.5 V-Modell XT ................................................................................................ 23
Abb. 2.6 Diamantmodell ............................................................................................ 25
Abb. 2.7 Personal-Zeit-Ebene .................................................................................... 26
Abb. 2.8 Ressourcen-Zeit-Ebene ............................................................................... 27
Abb. 2.9 Phasen und Tätigkeiten im RUP ................................................................ 28
Abb. 2.10 Zusammenspiel zwischen Rollen, Aktivitäten und Artefakten .............. 29
Abb. 2.11 Agile Softwareentwicklung ........................................................................ 31
Abb. 3.1 Umfeld Softwareergonomie ....................................................................... 35
Abb. 3.2 Usability Engineering ................................................................................. 36
Abb. 3.3 Ergonomische Eignung von Farbkombinationen ..................................... 39
Abb. 3.4 Erschwerungen ............................................................................................ 40
Abb. 3.5 Einordnung visueller Aspekte der Softwareergonomie .......................... 40
Abb. 3.6 Darstellung im Browser für den Surfer .................................................... 42
Abb. 3.7 Darstellung im Browser für den Webredakteur ....................................... 43
Abb. 3.8 Änderungen durch den Redakteur ............................................................ 44
Abb. 3.9 SuperConverter .......................................................................................... 45
Abb. 3.10 MediaCoder ................................................................................................ 46
Abb. 4.1 U-Case-Diagramm des Istzustandes .......................................................... 51
Abb. 4.2 Musikverlagsvertrag (Ausschnitt) ............................................................. 54
Abb. 4.3 Künstlervertrag (Ausschnitt) ...................................................................... 55
Abb. 4.4 Lizenzvertrag (Auschnitt) ........................................................................... 56
Abb. 4.5 Lizenzabrechnung (Ausschnitt) ................................................................. 57
Abb. 4.6 U-Case-Diagramm Sollzustand (Abdeckungsbereich der Software) ..... 59
Abb. 4.7 Beispiel für ein Entity Relationship Diagram .......................................... 65
Abb. 4.8 Datenkapselung in einem Objekt .............................................................. 67
Abb. 4.9 Klassendiagramm mit Assoziation und Kardinalitätsbeschränkungen . 69
Abb. 4.10 Objektdiagramm mit Links ........................................................................ 70
Abb. 4.11 Klassendiagamm mit Assoziationsklasse .................................................. 70
SEI11 85
© HfB, 02.12.20, Berk, Eric (904709)
C Abbildungsverzeichnis
Abb. 4.12 Beispiel Plattenfirma, Sicht 1 ..................................................................... 71

Abb. 4.13 Beispiel Plattenfirma, Sicht 2 ..................................................................... 71
Abb. 4.14 Generalisierung (Spezialisierung, Vererbung) .......................................... 72
Abb. 4.15 Aggregationen .............................................................................................. 74
Abb. 4.16 Notation Zustandsdiagramme .................................................................... 75
Abb. 4.17 Notation Sequenzdiagramm ....................................................................... 76
Abb. 4.18 Beispiel für ein Sequenzdiagramm im CASE-Tool InnovatorÒ .............. 77
Abb. 4.19 Aktivitätsdiagramm (UML 2) ..................................................................... 78
Abb. 4.20 Aktivitätsdiagramm (UML 1) ..................................................................... 79
Abb. 4.21 Beispiel für einen einfachen Projektplan ................................................... 80
86 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
D. Sachwortverzeichnis
SEI11
A F
Agile Methode ................................. 32 Fachkonzept ............................... 12, 13
Agile Modeling ................................ 30 Feinkonzept ............................... 16, 49
Agile Processing .............................. 30
Agile Programming ......................... 30 G
Agile Softwareentwicklung .............. 30 Grobkonzept .............................. 13, 49
Agiler Prozess .................................. 32
Agiles Prinzip .................................. 31 I
Anforderungsanalyse ....................... 13 Implementierung ............................. 16
Assoziationstyp ............................... 64 Initialisierung .................................... 9
Attribut ...................................... 64, 65 Ist-/Sollzustände .............................. 51
Istzustand ........................................ 51
B
Benutzertest ..................................... 17 M
Beziehung ........................................ 65 Multimediaprojekt ........................... 10
Murphys Gesetz ................................. 4
C
CASE ................................................ 6 P
CMS ................................................ 43 Pflichtenheft ................................ 3, 49
Content-Management-System .......... 43 Problemanalyse ......................... 10, 47
Programmtest .................................. 17
D Projektplan ...................................... 80
Data Dictionary ............................... 63 Prototyp .......................................... 19
Datenmodell, semantisches .............. 13 Prototyping ...................................... 20
Datenmodellierung, semantische . 13, 60
Dialoggestaltung .............................. 37 R
Domain ........................................... 64 Relation ........................................... 65
DV-Entwurf ..................................... 16 Relationship ..................................... 64
DV-Konzept ..................................... 12 Relationship set ................................ 64
RUP ................................................. 27
E
E-Commerce .................................... 10 S
Entität ............................................. 65 Software Engineering ......................... 6
Entity .............................................. 64 Softwareergonomie .......................... 34
Entity Relationship Diagram ............ 64 System mit geplanter Reaktion ........... 5
Entity set ......................................... 64 Systemanalyse ............................. 6, 13
Entwicklungszyklus ........................... 3 Systemanalytiker ............................... 3
Extreme Programming ..................... 30
SEI11 87
© HfB, 02.12.20, Berk, Eric (904709)
D Sachwortverzeichnis
T
Test .................................................. 17
U
U-Case-Diagramm ........................... 51
Unified Process ................................ 27
UP ................................................... 27
Usability Engineer ........................... 35
Use-Case-Diagramm ........................ 51
V
V-Modell XT .................................... 21
W
Wartung .......................................... 18
Wasserfallmodell ......................... 9, 18
Wertebereich ................................... 64
88 SEI11
© HfB, 02.12.20, Berk, Eric (904709)
E. Einsendeaufgabe
Phasenmodelle und Planung von Softwareprojekten Einsendeaufgabencode:
SEI11-XX2-K07
Name: Vorname: Tutor/-in:
Postleitzahl und Ort: Straße: Datum:
Matrikel-Nr.: Studiengangs-Nr.: Note:
Heftkürzel: Druck-Code: Unterschrift:

SEI11 0118K07
Bitte reichen Sie Ihre Lösungen über StudyOnline ein. Falls Sie uns diese per Post senden
wollen, dann fügen Sie bitte die Aufgabenstellung und den Einsendeaufgabencode hinzu.
1. Ein Konzern hat folgende Hierarchie:

Eine Holding wacht über Geschäftsbereiche. Jeder Geschäftsbereich ist in Hauptab-
teilungen und diese sind jeweils in Abteilungen unterteilt. Jede Abteilung beschäf-
tigt Mitarbeiter, im Außendienst wie im Innendienst. Sowohl im Außen- als auch im
Innendienst gibt es freie und feste Mitarbeiter. Innerhalb der Mitarbeiter gibt es Vor-
gesetzte und Untergebene.
Erstellen Sie als Softwarehersteller ein Angebot für die Entwicklung einer Verwal-
tungssoftware für das Personal des Konzerns, die die obigen Hierarchien berücksich-
tigt.
10 Pkt.
2. Erstellen Sie ein Pflichtenheft für eine geplante Softwareentwicklung Ihrer Wahl (er-
finden Sie geeignete Annahmen) inkl. eines semantischen Datenmodells. Berück-
sichtigen Sie dabei DIN 69901 sowie Erkenntnisse der Softwareergonomie. Der Um-
fang des abzugebenden Pflichtenhefts soll 5–10 Seiten betragen.
70 Pkt.
3. Wählen Sie ein Phasenmodell und geben Sie kurz die jeweiligen Inhalte jeder Phase
bezogen auf Ihr Softwareentwicklungsprojekt aus Aufgabe 2 wieder.
20 Pkt.
SEI11 89
© HfB, 02.12.20, Berk, Eric (904709)

Sei11 0118K07

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Sei11 0118K07

Hochgeladen von

Copyright:

Verfügbare Formate

Studienheft

Phasenmodelle und Planung von 

Phasenmodelle und Planung von

Prof. Dr. Peter Zöller-Greer

Phasenmodelle und Planung von Softwareprojekten

4 Planung eines Softwareprojekts ............................................................................ 47

1.1 Lebenszyklus einer Softwareentwicklung

Abb. 1.1: Lebenszyklus einer Softwareentwicklung

1.2 Methodische Ansätze und grundlegende Definitionen

System mit geplanten Reaktionen

Abb. 1.2: System mit geplanten Reaktionen

In diesem Kapitel wurden grundlegende Definitionen zum Software Engineering ange-

Aufgaben zur Selbstüberprüfung

Die große Unsicherheit hinsichtlich Kosten und Entwicklungszeiten komplexer Soft-

2.1 Klassisches Wasserfallmodell

Abb. 2.1: Wasserfallmodell

Ventura & Co. KG

Sehr geehrter Herr Ernst,

Implementierung der Software inkl. Modultes 5

Ich hoffe, Ihnen mit diesem Angebot gedient zu haben.

Phase 2: DV-Konzept (Fachkonzept)

• Angaben über die voraussichtlichen Zugriffshäufigkeiten und den Benutzerkreis

Mit der Übergabe des Anwendungsprogramms wird normalerweise eine Installations-

Abb. 2.2: Vereinfachtes Spiralmodell

Software- Software- Fein-

Abb. 2.3: Spiralmodell nach Boehm

Abb. 2.4: V-Modell

Abb. 2.5: V-Modell XT (Quelle: http://www.software-kompetenz.de/servlet/is/26381/Abb4_large.jpg)

Planungs- und Entwicklungsphasen

Abb. 2.6: Diamantmodell

Basic Planning & Design

Abb. 2.7: Personal-Zeit-Ebene

Abb. 2.8: Ressourcen-Zeit-Ebene

2.5 Neuere Methoden

Unified Process (UP, RUP)

2. Siehe z. B. Zöller-Greer, 2010b

• architekturzentriert (d. h. die Architektur des Produkts in den Vordergrund stellt),

Abb. 2.9: Phasen und Tätigkeiten im RUP 

Der Lebenszyklus des RUP ist prinzipiell in vier Phasen unterteilt:

Abb. 2.10: Zusammenspiel zwischen Rollen, Aktivitäten und Artefakten

Abb. 2.11: Agile Softwareentwicklung3

• Extreme Programming (XP)

Aufgaben zur Selbstüberprüfung

2.1 Wozu dienen Phasenmodelle?

3.1 Definition und Rechtsgrundlagen

Abb. 3.1: Umfeld Softwareergonomie

Die EU-Bildschirmrichtlinie (90/270/EWG) wurde in Deutschland durch die Bild-

Abb. 3.2: Usability Engineering

3.2 Softwareergonomische Dialoggestaltung

5) Klarheit (der Informationsgehalt wird schnell und genau vermittelt)

Abb. 3.3: Ergonomische Eignung von Farbkombinationen

Abb. 3.4: Erschwerungen

Abb. 3.5: Einordnung visueller Aspekte der Softwareergonomie

3.3 Praktische Anwendungen

Abb. 3.6: Darstellung im Browser für den Surfer

Abb. 3.7: Darstellung im Browser für den Webredakteur

Abb. 3.8: Änderungen durch den Redakteur

In diesem Abschnitt wurden die Grundlagen der Softwareergonomie besprochen. Es

Aufgabe zur Selbstüberprüfung

Abb. 3.9: SuperConverter

Abb. 3.10: MediaCoder

4 Planung eines Softwareprojekts

4.1 Erste Analyse des Problems