Software-Projekt ¨Uberblick I - Informatik - Universität Bremen

Überblick I 

1 Vorbemerkungen 

2 Softwaretechnik 

3 Planung 

4 Anforderungsanalyse 

5 Objektorientierte Modellierung 

6 Reviews 

Software-Projekt 

Prof. Dr. Rainer Koschke 

Fachbereich Mathematik und Informatik 

Arbeitsgruppe Softwaretechnik 

Universität Bremen 

Wintersemester 2008/09 

7 Entwurf von Benutzungsschnittstellen

Überblick II 

8 Software-Architektur 

9 Architekturstile und Entwurfsmuster 

10 Software-Test 

11 Implementierung 

12 Benutzerdokumentation 

13 Antworten auf gesammelte Fragen im Wiki 

14 Das SWP-Lied 

Vorbemerkungen 


1 Vorbemerkungen 

Ziele und Inhalt 

Angestrebte Resultate 

Aktivitäten der Software-Entwicklung 

Ablauf 

Zeitplan 

Anmeldung 

Scheinbedingungen 

Projektplan 

Vorstellung der Aufgabe 

Kontaktdaten 

Ressourcen 

Lehrbücher 

Eigenschaften von Software 

Software-Lebenszyklus 

Software-Evolution 

Entstehung der Softwaretechnik 

RainerMerkmale Koschke (Uni Bremen) der Softwaretechnik Software-Projekt Wintersemester 2008/09 4 / 634


Anmerkungen zu diesem Skriptum 

Einige dieser Folien basieren inhaltlich auf Skripten von. . . 

Prof. Dr. Jochen Ludewig (2003), Universität Stuttgart 

Prof. Dr. Susanne Maaß (2001), Universität Bremen 

Prof. Dr. Karl-Heinz Rödiger (2004), Universität Bremen 

Dr. Andreas Winter (2003), Universität Koblenz 

Ich danke für deren freundliche Genehmigung. 

Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 5 / 634 


Ziele der Vorlesung 

Primäre Ziele: 

Rüstzeug für die erfolgreiche Durchführung Ihres Software-Projekts 

vermitteln 

Modell für zukünftige ähnliche Projekte bieten 

→ Praktikum und Vorlesung bilden eine Einheit 

Primäre Ziele sind nicht: 

Vollständige Darstellung aller Themengebiete der Softwaretechnik 1 

Vermittlung von spezifischen Kenntnissen für die Entwicklung des 

Anwendungssystems X 

1 Wird im Hauptstudium nachgereicht. 

Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 6 / 634



Szenario: 

Erstellung eines großen Softwaresystems 

hier: mehrere Mitarbeiter über einen langen Zeitraum 

hier nicht: ein ” Freizeit“-Programmierer 

für einen Auftraggeber 

hier: Individualsoftware 

hier nicht: Standardsoftware 

im Rahmen eines Projekts 

hier: einmalige Zielverfolgung 

hier (eher) nicht: Weiterentwicklung existierender Software 

(aber: die Software wird von uns später weiterentwickelt; Wartbarkeit 

ist erklärtes Ziel) 




Softwaretechnik ist nicht nur Programmieren. 

Softwaretechnik ist auch Programmieren. 

Software-Entwicklung produziert Dokumente. 

Der Quellcode ist ein Dokument unter vielen. 

Sie sollen nicht nur ein richtiges System bauen. 

Sie sollen ein System auch richtig bauen. 



Aktivitäten bei der Softwareentwicklung 

Projekt− 

management 

Inbetrieb− 

nahme 

Test 

Analyse 

Entwurf 

Imple− 

men− 

tierung 

Konfigurations− 

management 

Qualitäts− 

management 



Infrastruktur einrichten 

Initiale Projektplanung 

Ist-Analyse 

Soll-Analyse 

Usability-Prototyp 

Anforderungsspezifikation 

Review der Anforderungsspezifikation 

Handbuch 

schreiben 

Architekturentwurf 

Technisches 

Prototyping 

Architekturreview 

beeinflusst/startet 

prüft 

Testplan u. Unit-Test-Entw. 

Implementierung 

Übergabe 

Akzeptanztest 

(Präsentation) 

Testprotokoll 

Systemtests 

Code-Inspektion 

Unit-/Integrationstests 


2009-02-09 



Ablauf 

Infrastruktur einrichten 

Initiale Projektplanung 

Ist-Analyse 

Soll-Analyse 

Usability-Prototyp 

beeinflusst/startet 

prüft 


Review der Anforderungsspezifikation 

Handbuch 

schreiben 

Architekturentwurf 

Technisches 

Prototyping 

Architekturreview 

Testplan u. Unit-Test-Entw. 


Aktivitäten in schwarzer Schrift sind konstruktiv; Aktivitäten in blauer Schrift dienen der analytischen 

Qualitätssicherung. Das Symbol kennzeichnet abzugebende Dokumente, die Produkt einer Aktivität sind. 


Zeitplan 

24.11.2008 Initialer Projektplan 

12.1.2009 Anforderungsspezifikation mit Angebot 

12.-30.1.2009 Review der Anforderungsspezifikation 

vorauss. 9-13.2.2009 Vorlesung Datenbankgrundlagen 

vorauss. 9-20.3.2009 Prüfung zur Vorlesung 

16.3.2009 Architekturentwurf 

6.-13.4.2009 Walkthrough des Architekturentwurfs 

20.4.2009 Testplan mit Unit-Tests 

Mai/Juni 2009 Code-Inspektion 

10.7.2009 Endabgabe 2 

15-17.7.2009 Abschlusspräsentationen 

Vorläufige Teilergebnisse müssen Sie evtl. in den Tutorien vorher abgeben. 

2 Implementierung (Source+lauffähig), Dokumentation, Whiteboxtests, Testprotokoll, 

Dokumentation der Abweichungen von Spezifikation und Architektur 

Übergabe 

Akzeptanztest 

(Präsentation) 

Testprotokoll 

Systemtests 

Code-Inspektion 

Unit-/Integrationstests 



Anmeldung 

Tutorienwahl ab sofort bis zum bis 30.10., 23.59 Uhr 3 

(erstes Tutorium am 3.11.) 

Web-Seite zur Anmeldung: 

http://www.informatik.uni-bremen.de/st/mems/courses.php?lng=en 

gruppenweise anmelden 

Gruppengröße 6 Personen 

Gruppennamen sorgfältig auswählen 

ausländische Studierende integrieren 

3 Ortszeit Bremen 




http://www.informatik.uni-bremen.de/st/Lehre/swp/ 

scheinbedingungen.html 



Abgabe des Projektplans 

abzugebender initialer Projektplan umfasst Aufgaben, Teilnehmer, 

Rollen, Verantwortlichkeiten, Pflichten, Risiken und deren Behandlung 

danach: inkrementelle Fortführung 

kann abgegeben werden für Feedback vom Tutor, muss aber nicht 

raten wir aber dringend an 

Verantwortlicher ist z.B. Phasenleiter für die zu planende Phase 

erste Woche jeder Phase dient Einarbeitung und Planung 

Granularität der Arbeitspakete: Arbeitsumfang von 1-2 Personen mit 

max. 1-2 Zeitwochen 

gerade in Krisenzeiten (Implementierungsphase) braucht man einen 

Plan (was wäre die Feuerwehr ohne Plan?) 

Fertigstellung (Ist) wird dokumentiert durch individuelle Zeiterfassung 

aufgeschlüsselt in Aktivitäten (Anette). 



Anette: Aufgaben-Management 



Anette: Zeiterfassung 



Die Aufgabe 

Aktuelle Probleme bei der Durchführung von Arbeitssitzungen im SWP 

und anderswo: 

Terminfindung ist ein langwieriger Prozess 

keine Möglichkeit zur Vorbereitung, da keine Agenda 

schlechte Zeitausnutzung 

wichtige Dinge bleiben unbesprochen 

die Inhalte der Arbeitssitzungen gehen verloren 

Festlegungen in Arbeitssitzungen bleiben unverbindlich 

Aufgaben werden nicht erledigt 

Aufgabe: Meeting Assistant 

Erstellung eines Systems zur Unterstützung von Arbeitssitzungen 

z.B. im SWP 



Durchführung von Arbeitssitzungen 

Rollen: Moderator, Protokollant, sonstige Teilnehmer 

Vorbereitung: 

1 Terminfindung 

2 Aufstellung der Agenda mit Priorisierung und Zeitplan 

3 Versenden der Einladung mit Agenda 




Durchführung: 

1 Feststellung der Anwesenheit 

2 ggf. Anpassung der Agenda 

3 Abfragen der offenen Aufgaben des letzten Treffens 

4 Abarbeitung der Agenda: 

entlang der Priorisierung 

Einhaltung des Zeitplans 

Protokollierung aller wesentlichen Punkte 

5 Festlegung von Aufgaben mit Verantwortlichen und Erledigungsdatum 




Nachbearbeitung: 

1 Versenden des Protokolls 

2 ggf. Anpassung des Protokolls 

3 Auswertungen von Statistiken, um Arbeitssitzungen kontinuierlich zu 

verbessern 



Erforderliche Funktionalität 

Meeting Assistant soll den gesamten Prozess unterstützen: 

Zeitfindung unter den Teammitglieder 

Vorbereitung der Agenda und Verteilung im Vorfeld 

Protokollerstellung während der Besprechung und Verteilung im 

Anschluss 

Überprüfen der offenen Punkte vom letzten Protokoll 

Integration mit Anette wäre vorteilhaft, ist aber nicht verbindlich. 

Quellcode von Anette kann erweitert werden. 



Erforderliche Funktionalität 

Randbedingungen: 

Implementierung in Java 5 oder höher 

Swing-GUI, keine Webanwendung 

Mehrbenutzerbetrieb 

hoher Anspruch an Datenschutz und -sicherheit 

hoher Anspruch an Benutzbarkeit/Ergonomie 

Client/Server Anwendung 

Verwendung von MySQL für den Server 

Verwendung von SQL-Abfragen 

keine ” große“ Datenbank auf dem Clienten (eingebettete sind OK) 



Vorlesungsbegleitender Technikkurs 

Themen: 

Swing 

Sockets (TCP) 

RMI 

SSL 

Serialisierung 

Datenbankanbindung 

OR-Mapping 

XML Parser 

Multithreading 

. . . 

jeweils Einführung + betreute Übung 

optionales Angebot, Teilnahme freiwillig 

etwa 4–5 Termine 

Termin: im Januar/Februar? 



Die Beteiligten 

Tel. E-Mail Ort 

Rainer Koschke 9671 koschke OAS 3016 

Raimar Falke 2576 rfalke OAS 3012 

Markus Eich 64105 eich DFKI 212 

Hendrik Iben 2447 hiben TAB 1.91 

Hui Shi 64260 shi Cartesium 1.053 

Xin Xing 3035 xing TAB 1.77 

. . . und natürlich Sie! 



Ressourcen 

Web-Seite zur Vorlesung: 

http://www.informatik.uni-bremen.de/st/Lehre/swp/ 

Folien mit Kommentaren: 

http://www.informatik.uni-bremen.de/st/lehredetails. 

php?id=&lehre_id=46 

Folien mit Annotationen aus der Vorlesung bei Stud.IP: 

http://elearning.uni-bremen.de/ 

Video-Aufzeichnung vom letzten Jahr: 

http://mlecture.uni-bremen.de 

Newsgroup fb3.lv.swp 



Lehrbücher zur Softwaretechnik I 

Allgemeine Literatur zur Softwaretechnik: 

Balzert (1998): Umfassendes deutsches Lehrbuch vmtl. der Bestseller 

in Deutschland; leider nicht mehr im Buchhandel verfügbar, wird neu 

aufgelegt 

Ludewig und Lichter (2006): Umfassendes Lehrbuch, das aus 

Ludewigs Vorlesungen rund um Softwaretechnik entstanden ist. Diese 

Vorlesung basiert in großen Teilen auf dem Skript von Ludewigs 

Vorlesung. 

Sommerville (2004): Ein Standardlehrbuch, sowohl in deutscher als 

auch englischer Sprache verfügbar. Im Umfang vergleichbar mit dem 

Buch von Pressman (2003). 

Pressman (2003): Ein umfassendes englisches Lehrbuch, das man fast 

schon als Enzyklopädie bezeichnen könnte. Behandelt auch 

nicht-objektorientierte Konzepte. 



Lehrbücher zur Softwaretechnik II 

Brügge und Dutoit (2004): Eine Einführung in Deutsch mit 

Schwerpunkt Objektorientierung und UML. 

Zuser u. a. (2004): Eine Einführung in Deutsch mit Schwerpunkt 

Objektorientierung und dem Rational Unified Process. Weniger 

umfassend als das Buch von Brügge und Dutoit (2004). 

Spezialthemen: 

Störrle (2005): Eine kurze Einführung in die Konzepte der UML 2.0 in 

deutscher Sprache. 


Allgemeines zur Softwaretechnik 





Ablauf 

Zeitplan 

Anmeldung 




Kontaktdaten 

Ressourcen 

Lehrbücher 

2 Softwaretechnik 





Merkmale der Softwaretechnik 


Projekt 


Was ist Software? 

Vorgehen 

Inhalt 

Zeitplan 

Planung und Aufwand im SWP 05/06 

Risiken 

Risiko-Management 

Erfahrungen aus dem SWP 05/06 

Definition 

Allgemeine Risiken in einem Software-Projekt 

Software: Computer programs, procedures, and possibly associated 

Wiederholungsfragen 

documentation and data pertaining to the operation of a computer system. 

IEEE Std 610.12-1990 (1990) 

Lernziele 

Herausforderungen 

Aktivitäten 

Ist-Analyse 

Erhebungstechniken 

Befragung 

Beobachtung 

Soll-Analyse: Prototyping 

Zusammenfassung der Techniken 


Bedeutung 


2009-02-09 


Softwaretechnik 




Definition 

Software: Computer programs, procedures, and possibly associated 

documentation and data pertaining to the operation of a computer system. 

IEEE Std 610.12-1990 (1990) 

Software umfasst also nach IEEE Std 610.12 Programme, Abläufe, Regeln, auch Dokumentation und Daten, die 

mit dem Betrieb eines Rechnersystems zu tun haben. 


Ein Produkt wie jedes andere? 

Software 

ist ein technisches Produkt, 

weist aber einige einmalige Merkmale auf. 

→ Sie sollten beim Umgang mit Software beachtet werden. 


2009-02-09 







ist ein technisches Produkt, 

weist aber einige einmalige Merkmale auf. 

→ Sie sollten beim Umgang mit Software beachtet werden. 

Generell kann und sollte Software als technisches Produkt betrachtet werden, das wie andere Produkte von 

Ingenieuren systematisch entwickelt werden kann und durch feststellbare Eigenschaften (Funktionalität, Qualität) 

gekennzeichnet ist. Software ist sogar frei von allen Unwägbarkeiten, die anderen technischen Produkten anhaften. 

Sie ist in diesem Sinne das ideale technische Produkt. Als Software-Leute sollten wir darum keine spezielle 

Nachsicht erwarten. Software weist aber (wie viele andere Produkttypen) einige besondere und wenigstens in dieser 

Kombination einmalige Merkmale auf: Sie müssen beim Umgang mit Software beachtet werden. 



Software ist immateriell: 

Software kann nicht ohne Weiteres betrachtet werden. 

Kopie und Original sind völlig gleich. 

Software wird nicht gefertigt, sondern nur entwickelt. 

Software verschleißt nicht. 

Software ” altert“ in dem Maße, in dem sich ihre Umwelt ändert. 


2009-02-09 






Software ist immateriell: 

Software kann nicht ohne Weiteres betrachtet werden. 

Kopie und Original sind völlig gleich. 

Software wird nicht gefertigt, sondern nur entwickelt. 

Software verschleißt nicht. 

Software ” altert“ in dem Maße, in dem sich ihre Umwelt ändert. 

Was wir als natürlich empfinden, ist an materielle Eigenschaften geknüpft. An Software ist nichts natürlich. 

Erfahrungen aus der natürlichen Welt sind nicht übertragbar (werden dennoch ständig übertragen, siehe z.B. 

Wartung). Kopie und Original sind völlig gleich. Software wird nicht gefertigt, sondern nur entwickelt. Software 

verschleißt nicht; die Wartung stellt nicht den alten Zustand wieder her, sondern einen neuen. Wiederverwendung 

ist bei Software extrem lukrativ, wenn der Aufwand für Anpassungen relativ gering ist. Programmierer 

unterschätzen meist das Problem (. . . oder überschätzen sich selbst!) 



Software hat keine natürliche Lokalität. 

Ihre Werkstoffe sind amorph und universell. 

Strukturen müssen aktiv geschaffen werden. 

Ein Programm realisiert keine stetige Funktion. 

Korrektheit ist durch Test nicht prüfbar. 


2009-02-09 






Software hat keine natürliche Lokalität. 

Ihre Werkstoffe sind amorph und universell. 

Strukturen müssen aktiv geschaffen werden. 

Ein Programm realisiert keine stetige Funktion. 

Korrektheit ist durch Test nicht prüfbar. 

Natürliche Lokalität gibt es bei Software nicht. Im Speicher eines Rechners gibt es keine schützende Distanz. Die 

Werkstoffe der Software sind amorph und universell. Werkstoffe sind die eingesetzten Sprachen, meist nur die 

natürliche Sprache und die Programmiersprache, evtl. noch andere, z.B. graphische Notationen. 

Ein Programm realisiert keine stetige Funktion. Der Zusammenhang zwischen Eingabe und Ausgabe lässt sich nicht 

durch eine kontinuierliche Funktion beschreiben. 



Software-Systeme sind sehr komplex: 

→ Entwicklungskosten sind unvermeidlich hoch. 

→ Korrekte Konstruktion ist extrem schwierig. 

Software spiegelt (in vielen Fällen) die Realität wider. 

“This complexity is compounded by the necessity to conform to 

an external environment that is arbitrary, unadaptable, and 

everchanging.” 

–F.P. Brooks, 1987 


2009-02-09 






Software-Systeme sind sehr komplex: 

→ Entwicklungskosten sind unvermeidlich hoch. 

→ Korrekte Konstruktion ist extrem schwierig. 

Software spiegelt (in vielen Fällen) die Realität wider. 

“This complexity is compounded by the necessity to conform to 

an external environment that is arbitrary, unadaptable, and 

everchanging.” 

Software-Systeme sind sehr komplex (nach Zahl der relevanten Entscheidungen darin), vergleichbar mit anderen 

sehr komplexen Systemen. Es ist extrem schwer, sie trotzdem so zu konstruieren, dass sie automatisch und korrekt 

arbeiten. 



Software gilt als flexibel (d.h. leicht änderbar) 4 : 

Sie verbindet Hardware und Umgebung. 

Details der Aufgabenstellung werden in aller Regel durch Software 

realisiert. 

→ Änderungen schlagen sich entsprechend primär in der Software nieder. 

4 Software ist nur in dem Maße flexibel, in dem die Flexibilität explizit eingebaut ist. 

–F.P. Brooks, 1987 


2009-02-09 






Software gilt als flexibel (d.h. leicht änderbar) 4 : 

Sie verbindet Hardware und Umgebung. 

Details der Aufgabenstellung werden in aller Regel durch Software 

realisiert. 

→ Änderungen schlagen sich entsprechend primär in der Software nieder. 

4 Software ist nur in dem Maße flexibel, in dem die Flexibilität explizit eingebaut ist. 

Software ist nur in dem Maße flexibel, in dem die Flexibilität explizit eingebaut ist: Es ist leicht einen Parameter zu 

verändern, aber nur wenn dieser Parameter in der Software vorhanden ist. 



Analyse 

Entwurf 

Implemen− 

tierung 

Test 

Wartung 

& Evolution 


2009-02-09 






Wie jeder komplexe Engineering-Prozess, so verläuft auch die Software-Entwicklung in mehreren Phasen. Die 

Software wird spezifiziert, eine Lösung wird entworfen und implementiert und schließlich getestet. Nach der 

Auslieferung wird sie gewartet. Das heißt, Fehler werden korrigiert sowie Erweiterungen und Anpassungen 

vorgenommen. 

Diese Darstellung suggeriert, dass alle Teilphasen mehr oder minder gleich lang sind. Dies stimmt jedoch nicht. 


Aufwand in den Phasen nach McKee (1984) 

Analyse 

Entwurf 

Implemen− 

tierung 

Test 

Analyse 

Entwurf 

Implemen− 

tierung 

Test 

Wartung 

& Evolution 


Wartung 

& Evolution

2009-02-09 






Hier sehen Sie eine Darstellung des Entwicklungsprozesses, in der die einzelnen Phasen entsprechend ihrer Dauer 

gezeichnet sind. 

Empirische Untersuchungen zeigen, dass bis zu 80% der Kosten erst nach der Auslieferung entstehen. Das heißt, in 

der Wartungs- und Evolutionsphase. 

Diese Phase unterscheidet sich von den anderen Phasen darin, dass man sich mit einem existierenden System 

auseinander setzen muss. 

Diese Verteilung sagt übrigens auch aus, dass unsere Studenten zu 80prozentiger Wahrscheinlichkeit es in ihrem 

späteren Berufsleben mit der Wartung zu tun haben werden. Nur an wenigen Universitäten werden sie hierauf 

ausreichend vorbereitet. 


Evolutionsphase nach Fjeldstadt und Hamlen (1984) 

Analyse 

Entwurf 

Implemen− 

tierung 

Test 

Verstehen 

Änderung und Test 

Analyse 

Entwurf 

Implemen− 

tierung 

Test 

Wartung 

& Evolution 


Wartung 

& Evolution

2009-02-09 






Weitere Studien zeigen, dass Wartungsprogrammierer etwa die Hälfte ihrer Zeit allein mit der Analyse der Software 

verbringen, ehe sie ihre Änderungen vornehmen und testen. Bei der Korrektur von Fehlern liegt der Aufwand eher 

bei 60%. 

Dieser hohe Aufwand liegt an der unzureichenden Information, die den Wartungsprogrammierern zur Verfügung 

steht. Die Programmierer müssen die Informationen mühsam von Hand herleiten, weil ihnen die dazu notwendigen 

Werkzeuge fehlen. 

Wer Kosten bei der Software-Entwicklung sparen möchte, muss hier ansetzen. 


Lehman und Beladys ” Gesetze“ (1985) 

Gesetz vom fortwährenden Wandel 

Software löst ein Problem der realen Welt, 

die reale Welt ändert sich, 

Software muss sich anpassen, 

bis sie abgelöst wird. 

Analyse 

Entwurf 

Implemen− 

tierung 

Test 

Verstehen 

Änderung und Test 


Wartung 

& Evolution

2009-02-09 





Warum muss Software überhaupt angepasst werden? Die Begründung fällt leicht. . . . 



Gesetz der zunehmenden 

Komplexität 

die Komplexität der 

Software erhöht sich 

beim Wandel, 

wenn keine 

Gegenmaßnahmen 

ergriffen werden 


Gesetz vom fortwährenden Wandel 

Software löst ein Problem der realen Welt, 

die reale Welt ändert sich, 

Software muss sich anpassen, 

bis sie abgelöst wird. 


2009-02-09 






Gesetz der zunehmenden 

Komplexität 

die Komplexität der 

Software erhöht sich 

beim Wandel, 

wenn keine 

Gegenmaßnahmen 

ergriffen werden 

Leider geht mit dem Zwang zur Änderung der Anstieg der Komplexität der Software einher. Hier sehen Sie eine 

Grafik von Many Lehman, der sich als einer der ersten mit dem Phänomen der Software-Evolution empirisch 

auseinander gesetzt hat. 

Sie sehen hier den Umfang eines Systems, gemessen in der Anzahl seiner Module, über die Zeit. Die Messpunkte 

sind die verschiedenen Releases der Software. 

Sie bemerken das Wachstum. Aber auch gleichzeitig die Verlangsamung des Wachstums. Die Dauer zwischen 

Releases nimmt zu. 

Um diesem Trend entgegen zu wirken, müssen Sie Maßnahmen ergreifen, um die Komplexität einzudämmen. 



Konsequenzen: 

Änderbarkeit ist eine Schlüsselqualität 

Änderbarkeit muss frühzeitig angestrebt werden 

sie lässt sich nicht nachträglich überstülpen 

wer sie vernachlässigt, nimmt einen Kredit auf, den er teuer abzahlen 

wird 



Wo liegen die Probleme in der Softwaretechnik? 

In den späten 60er Jahren: 

2009-02-09 

Manche Software-Projekte sind selbst mit gigantischem Aufwand 

nicht zu schaffen. 

In vielen anderen Fällen wird der Abschluss nur mit unbefriedigenden 

Resultaten, viel zu spät und/oder mit extremen 

Kostenüberschreitungen erreicht. 

Andererseits erzielt die Hardware-Entwicklung atemberaubende 

Fortschritte. 

“The whole trouble comes from the fact that there is so much 

tinkering with software. It is not made in a clean fabrication 

process, which it should be. What we need is software 

engineering.” 

–F.L. Bauer, 1968 







In den späten 60er Jahren: 

Manche Software-Projekte sind selbst mit gigantischem Aufwand 

nicht zu schaffen. 

In vielen anderen Fällen wird der Abschluss nur mit unbefriedigenden 

Resultaten, viel zu spät und/oder mit extremen 

Kostenüberschreitungen erreicht. 

Andererseits erzielt die Hardware-Entwicklung atemberaubende 

Fortschritte. 

“The whole trouble comes from the fact that there is so much 

tinkering with software. It is not made in a clean fabrication 

process, which it should be. What we need is software 

engineering.” 

Kurz: Es ist nicht alles machbar, was prinzipiell möglich sein müsste. Für diese Probleme kam das Schlagwort 

Software Crisis in Mode. Die Software-Krise war Anlass für viele Diskussionen und Tagungen. Auf der 

NATO-Konferenz in Garmisch (1968) prägte F.L. Bauer das Wort Software Engineering als Provokation (siehe dazu 

Bauer, 1993). 

–F.L. Bauer, 1968


Wie viel hat sich bis heute daran geändert? 

Beispiel 

Fehler: 

vollständiger Batterieausfall in Fahrzeugen eines deutschen 

Automobil-Herstellers 

Ursache: 

Fehler in der software-gesteuerten Innenbeleuchtung 

Folge: 

Rückrufaktion mit einem (geschätzten) Schaden von mehreren 

Millionen DEM 

Partsch (1998) 




Beispiel 

Fehler: 

Bei der rechnergestützten Auswertung der OB-Wahl in Neu-Ulm 1994 

wurde zunächst eine Wahlbeteiligung von 104% festgestellt. 

Ursache: 

In der Auswertungssoftware hatte sich ein mysteriöser Faktor 2 

eingeschlichen. 

Folge: 

Neuauszählung 

Partsch (1998) 




Beispiel 

Fehler: 

USS Yorktown treibt während eines Manövers im September 1997 

manövrierunfähig bei Cape Charles, VA. 

Ursache: 

Fehler in einer Routine zum Abfangen einer Division durch Null in einer 

Windows NT Applikation. Die ” Null“ wurde als manuelle Eingabe einer 

enormen Datenmenge interpretiert. 

Folge: 

“Atlantic Fleet officials said the ship was dead in water for about 2 

hours and 45 minutes.” 

Neumann (1999) 



Produktgarantie? 

Disclaimer of Warranty: 

This car is provided under this license on an “as is” basis, without 

warranty of any kind, either expressed or implied, including, 

without limitation, warranties that the car is free of defects, 

merchantable, fit for a particular purpose or non-infringing. The 

entire risk as to the quality and performance of the car is with you. 

Should any car prove defective in any respect, you (not the initial 

developer or any other contributor) assume the cost of any necessary 

servicing, repair or correction. 



Garantien über Software? 


2009-02-09 

This software is provided under this license on an “as is” basis, 

without warranty of any kind, either expressed or implied, 

including, without limitation, warranties that the software is free 

of defects, merchantable, fit for a particular purpose or 

non-infringing. The entire risk as to the quality and performance of 

the software is with you. Should any software prove defective in 

any respect, you (not the initial developer or any other contributor) 

assume the cost of any necessary servicing, repair or correction. 








This software is provided under this license on an “as is” basis, 

without warranty of any kind, either expressed or implied, 

including, without limitation, warranties that the software is free 

of defects, merchantable, fit for a particular purpose or 

non-infringing. The entire risk as to the quality and performance of 

the software is with you. Should any software prove defective in 

any respect, you (not the initial developer or any other contributor) 

assume the cost of any necessary servicing, repair or correction. 

An solche Disclaimer haben wir uns schon lange gewöhnt. Stellen Sie sich vor, sie lesen einen solchen in der 

Betriebsanleitung Ihres Autos. Sie würden das Auto sofort zurückgeben. 

Übrigens: Solche Disclaimer sind nach deutschem Recht hinfällig. Stellen Sie jemandem auf dem Netz ein 

Programm zur Verfügung, sind Sie automatisch in der Haftung. Grobe Fahrlässigkeit und Vorsatz lassen sich in 

Deutschland nicht ausschließen. 

Spezifizieren Sie nicht den Zweck Ihres Programms, so wird zu Grunde gelegt, was man üblicherweise von einem 

Programm dieser Art erwartet.


Ingenieursdisziplin (Shaw und Garlan 1996) 

Kunst 

Produktion 

Geübte Arbeiter 

• etabliertes Vorgehen 

• pragmatische Verfeinerungen 

• Ausbildung in der Ausführung 

• ökonomische Betrachtung 

der Materialien 

• Herstellung für den Verkauf 

Talentierte Amateure 

• gelegentliche 

• verschwenderische Verwendung 

• Herstellung für die Verwendung, 

Übermittlung 

• intuitiv und ad hoc 

• wahlloser Fortschritt 

verfügbaren Materials 

weniger für den Verkauf 

Wissenschaft 

Handwerk 

Ingenieursdisziplin 

Ausgebildete Personen 

• Analyse und Theorie 

• Fortschritt basiert auf 

Wissenschaft 

• Einführung neuer 

Anwendungen durch Analyse 

• Marktsegmentierung durch 

Produktvielfalt 



Definition 

Softwaretechnik: 

Entdeckung und Anwendung solider Ingenieur-Prinzipien mit dem 

Ziel, auf wirtschaftliche Art Software zu bekommen, die zuverlässig ist 

und auf realen Rechnern läuft. 

–F.L. Bauer 

Herstellung und Anwendung einer Software, wobei mehrere Personen 

beteiligt sind oder mehrere Versionen entstehen. 

–D.L. Parnas 

(1) The application of a systematic, disciplined, quantifiable approach 

to the development, operation, and maintenance of software; that is, 

the application of engineering to software. (2) The study of 

approaches as in (1). IEEE Std 610.12-1990 (1990) 


2009-02-09 




Definition 

Softwaretechnik: 

Entdeckung und Anwendung solider Ingenieur-Prinzipien mit dem 

Ziel, auf wirtschaftliche Art Software zu bekommen, die zuverlässig ist 

und auf realen Rechnern läuft. 

–F.L. Bauer 

Herstellung und Anwendung einer Software, wobei mehrere Personen 

beteiligt sind oder mehrere Versionen entstehen. 

–D.L. Parnas 

(1) The application of a systematic, disciplined, quantifiable approach 

to the development, operation, and maintenance of software; that is, 

the application of engineering to software. (2) The study of 

approaches as in (1). IEEE Std 610.12-1990 (1990) 

Software Engineering wurde oft definiert. Drei wichtige Definitionen sind hier angegeben. 

Die IEEE-Definition ist problematisch, wenn nicht falsch, weil sie wertet und fordert, also ein Ideal beschreibt, und 

einen anderen undefinierten Begriff zu Grunde legt. 


Abschrift aus dem Vorwort zum Vorlesungsskript Werkstoffe der 

Elektrotechnik (Prof. Fischer, Uni-Dortmund, 1977) 



Merkmale der alten Ingenieurdisziplinen 

2009-02-09 

Kostendenken als Grundlage von Bewertungen 

praktischer Erfolg als einziger zulässiger Beweis 

Qualitätsbewusstsein als Denkprinzip 

Einführung und Beachtung von Normen (Schnittstellen, Verfahren, 

Begriffe) 

Denken in Baugruppen 







Definition und Anwendung von Methoden, Bereitstellung und Verwendung von Werkzeugen sind allgemein 

bewährte Ansätze, also nicht typisch für Ingenieure. Ingenieur-spezifisch sind dagegen: 

Kostendenken als Grundlage von Bewertungen 

praktischer Erfolg als einziger zulässiger Beweis 

Qualitätsbewusstsein als Denkprinzip 

Einführung und Beachtung von Normen (Schnittstellen, Verfahren, 

Begriffe) 

Denken in Baugruppen 

• Kostendenken als Grundlage von Bewertungen (Achtung, es geht hier um die Gesamtkosten, nicht nur um Geld!) 

• praktischer Erfolg als einziger zulässiger Beweis: nur was gezählt oder gemessen wurde, ist ein akzeptables Argument; 

• Qualitätsbewusstsein: hohe Qualität ist ein Prinzip der unspezifischen Kostensenkung; kommt aus der handwerklichen 

Tradition, die die Ingenieure übernommen haben; 

• Normen (vgl. Norm für Passstifte); Merke: Eine Norm wird immer beachtet! 

• Baugruppen: Durch Normen entsteht die Möglichkeit, Baugruppen zu verwenden, also die Lösung der Teilprobleme 

auszuklammern.



Was sind die besonderen Eigenschaften von Software? 

Was folgt aus diesen Eigenschaften für die Softwareentwicklung? 

Aus welchen Phasen besteht der Software-Lebenszyklus? 

Was ist die Besonderheit der Wartungsphase und was folgt daraus für 

die Softwareentwicklung? 

Warum muss Software überhaupt angepasst werden? Welche Folgen 

können diese Änderungen haben? 

Welche Einsichten führten zur Entstehung der Softwaretechnik? Mit 

welchen Problemen ist die Softwaretechnik nach wie vor konfrontiert? 

Was ist Softwaretechnik? Welche Ziele verfolgt sie? 

Was sind die Kennzeichen einer Ingenieursdisziplin und wie entsteht 

sie? 


Planung eines Software-Projekts 





Ablauf 

Zeitplan 

Anmeldung 




Kontaktdaten 

Ressourcen 

Lehrbücher 






3 Rainer Planung Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 53 / 634



Definition 

Projekt: eine für begrenzte Zeit mit bestimmtem Ziel bestehende 

Organisation mit all ihren Bestandteilen, Beziehungen im Innern und nach 

außen. 



Planung 

Planung 

am Anfang: 

Gliederung in Phasen, Aktivitäten, Arbeitspakete, 

zeitlicher Ablauf (Meilensteine), 

Arbeitsorganisation, 

Aufbau der Dokumentation. 

während des Projekts: 

Controlling (d.h. die Überwachung des Projektfortschritts), 

Reaktion auf Abweichung (Anpassung des Plans). 


2009-02-09 


Planung 


Planung 

Planung 

Planung 

am Anfang: 

Gliederung in Phasen, Aktivitäten, Arbeitspakete, 

zeitlicher Ablauf (Meilensteine), 

Arbeitsorganisation, 

Aufbau der Dokumentation. 

während des Projekts: 

Controlling (d.h. die Überwachung des Projektfortschritts), 

Reaktion auf Abweichung (Anpassung des Plans). 

Planung hat im Software-Projekt zwei verschiedene Bedeutungen: Zu Beginn des Projekts müssen Pläne aufgestellt 

werden für die Gliederung in Phasen, den für die Arbeitsorganisation, den für den Aufbau der Dokumentation, und 

den für die Prüfungen. Die Existenz und die Qualität dieser Pläne hat zentrale Bedeutung für den Erfolg des 

Projekts. 

Während des Projekts bleibt die Planung eine Daueraufgabe, weil sich die Realität meist nicht an unsere Planungen 

hält. Notwendig ist ein Kompromiss zwischen der starrsinnigen Verteidigung von Plänen, die offenkundig nicht 

einzuhalten sind, und der laufenden Anpassung der Pläne an den realen Stand. Eine gewisse Spannung zwischen 

Plan und Realität ist normal. Planung und Planverfolgung sind die wichtigsten Aufgaben der Projektleitung. Eng 

damit verbunden sind Controlling (d.h. die Überwachung der Ausgaben in einem Projekt) und Qualitätssicherung 

(d.h. die Prüfung aller Teilresultate und Resultate). 


Elemente eines Projekts 

Ist−Analyse 

Soll−Analyse 

Ist−Beschreibung 

Prototyp 

erstellen 

Spezifikation 

der Anforderungen 

Abnahme 

durch Kunden 

Soll−Beschreibung 

Prototyp 

Analysephase 

Anforderungs− 

spezifikation 

abgenommene 



2009-02-09 


Planung 




Ist−Analyse 



Prototyp 

erstellen 


Prototyp 

Spezifikation 


Analysephase 


spezifikation 

Abnahme 

durch Kunden 

abgenommene 


Für das Verständnis von Projekten sind einige Grundbegriffe notwendig. Keiner dieser Begriffe ist spezifisch für ein 

Software-Projekt. Insgesamt kann angemerkt werden, dass allgemeine Aussagen zu Projekten (jedweder Form) in 

aller Regel auch für Software-Projekte gelten. Die Natur der Software, die in einem Software-Projekt entwickelt 

werden soll, kommt vielmehr in den Inhalten der Arbeitspakete zum Tragen. 



Ist−Analyse 



Prototyp 

erstellen 

Spezifikation 


Abnahme 

durch Kunden 


Prototyp 

Analysephase 


spezifikation 

abgenommene 


Definition 

Aktivität: Arbeitseinheit mit 

präzisem Anfangs und -enddatum 

enthält Aufgaben 

benötigt Ressourcen 

produziert Arbeitsprodukt 




Ist−Analyse 



Prototyp 

erstellen 

Spezifikation 


Abnahme 

durch Kunden 


Prototyp 

Analysephase 


spezifikation 

abgenommene 


Definition 

Projektfunktion: Aktivität, die die 

gesamte Projektlaufzeit überspannt. 

Beispiele: 

Projektmanagement 

Konfigurationsmanagement 

Qualitätssicherung. 




Ist−Analyse 



Prototyp 

erstellen 

Spezifikation 


Abnahme 

durch Kunden 


Prototyp 


spezifikation 

abgenommene 


Analysephase 

Definition 

Arbeitspaket: Spezifikation für eine 

zu erledigende Arbeit. Definiert 

Arbeitsprodukt, 

Personalbedürfnisse, 

erwartete Entwicklungsdauer, 

verwendete Ressourcen, 

Akzeptanzkriterien, 

Namen des 

Hauptverantwortlichen 

und sonstige relevante Aspekte 

der Arbeit. 




Ist−Analyse 



Prototyp 

erstellen 

Spezifikation 


Abnahme 

durch Kunden 


Prototyp 


spezifikation 

abgenommene 


Analysephase 

Definition 

Arbeitsprodukt ein konkretes 

Ergebnis einer Projektfunktion oder 

-aktivität. Beispiele: 

Anforderungsspezifikation, 

Projektplan, 

funktionale Spezifikation, 

Entwurfsdokumente, 

Benutzerhandbuch, 

Testplan 

oder Protokolle von Reviews 

oder Meetings. 




Ist−Analyse 



Prototyp 

erstellen 

Spezifikation 


Abnahme 

durch Kunden 


Prototyp 

Analysephase 


spezifikation 

abgenommene 


Definition 

Meilenstein: 

Menge von Kriterien 

und vorgesehener Zeitpunkt 

und erreichter Zeitpunkt 

für die Abnahme eines 

(Zwischen-)Resultats 




Ist−Analyse 



Prototyp 

erstellen 

Spezifikation 


Abnahme 

durch Kunden 


Prototyp 

Analysephase 


spezifikation 

abgenommene 


Definition 

Baseline: Arbeitsprodukt, 

formal begutachtet und 

akzeptiert, 

nur durch formalen 

kontrollierten Änderungsprozess 

änderbar; 

bildet Basis für nachfolgende 

Arbeitsaktivitäten. 



Vorgehen zur Planung 

1 Auswahl eines geeigneten Prozesses (oder Prozessmodells) 

2 Grobe Abschätzung des Gesamtumfangs und des Gesamtaufwands 

3 Aufstellen eines Zeitplans 

4 Aufstellen eines Dokumentationsplans 

5 Aufstellen eines Prüfplans 

6 Aufstellen eines Organisationsplans 

7 Definition der Meilensteine (1-6) 

und natürlich: Iteration dieser Schritte, bis die Resultate zusammenpassen. 



Vorgehen zur Planung 

Wo es definierte Prozessmodelle gibt, kann (und muss) die Projektleiterin 

die Vorlagen für die Pläne aus der Schublade (d.h. aus dem Intranet) 

nehmen. 

Der Projektplan sollte sorgfältig geprüft werden! 

Der Projektplan entsteht mit dem Projekt und wird im Verlauf des 

Projekts fortgeschrieben, aber nicht laufend geändert. 

Der Projektplan ist Gegenstand der Änderungskontrolle. 



Inhalt des Projektplans 

Plan macht prinzipiell Aussagen zu den folgenden W-Punkten: 

warum 

was getan wird, 

für wieviel Geld, 

von wem, 

wann und 

womit, d.h. unter Einsatz welcher Hilfsmittel und Techniken. 



Aufbau eines Projektplans nach IEEE-Std-1058 (1987) 

Übersicht 

0. Version und Änderungsgeschichte 

1. Einleitung 

2. Projektorganisation 

3. Managementprozess 

4. Technischer Prozess 

5. Arbeitspakete, Zeitplan und Budget 

6. Zusätzliche Elemente 

7. Index 

8. Anhang 

2009-02-09 



Planung 

Inhalt 



Übersicht 

0. Version und Änderungsgeschichte 

1. Einleitung 

2. Projektorganisation 

3. Managementprozess 

4. Technischer Prozess 

5. Arbeitspakete, Zeitplan und Budget 

6. Zusätzliche Elemente 

7. Index 

8. Anhang 

Der Projektplan, wie jedes andere Dokument auch, erhält eine Versionsnummer. Änderungen des Projektplans sind 

unausweichlich (er wird schrittweise verfeinert und angepasst). Die Änderungen müssen dokumentiert und 

nachvollziehbar sein. Der Abschnitt “Version und Änderungsgeschichte” enthält diese Information. 

Die Einleitung gibt einen Überblick über das Projekt und das Produkt, die Liste der auszuliefernden Dinge, der Plan 

für die Entwicklung und die Fortführung des Projektplans, Referenzmaterial sowie Definitionen und Akronyme. 

Der Abschnitt “Projektorganisation” spezifiziert das Prozessmodell des Projekts, die Organisationsstruktur, die 

Grenzen und Schnittstellen der Organisation und die individuellen Verantwortlichkeiten. 

Der Abschnitt “Managementprozess” spezifiziert die Managementziele und -prioritäten, Annahmen und 

Einschränkungen, Risiken und deren Behandlung sowie Kontrollmechanismen und den Personalplan. 

Der Abschnitt “Technischer Prozess” spezifiziert die technischen Methoden, Werkzeuge und Techniken, die im 

Projekt benutzt werden sollen. Außerdem wird der Dokumentationsplan und die Pläne für die Projektfunktionen 

spezifiziert, wie etwa die Qualitätssicherung und das Konfigurationsmanagement. 

Der Abschnitt “Arbeitspakete” spezifiziert die Arbeitspakete, ihre Abhängigkeiten und Beziehungen, die benötigten 

Ressourcen, Zuteilung des Budgets und Ressourcen auf Arbeitspakete sowie den Zeitplan. 

Der Abschnitt “Zusätzliche Elemente” enthält Pläne für zusätzliche Komponenten.



Einleitung 

1.1 Projektübersicht 

Zusammenfassung der Ziele, Resultate, Hauptarbeitsaktivitäten und 

-produkte, Hauptmeilensteine, benötigte Ressourcen, grober Zeitplan 

und Budget; Kontaktdaten des Kunden 

1.2 Auszuliefernde Produkte 

alle an den Kunden auszuliefernde Produkte mit Auslieferungsdatum 

und -ort sowie deren Anzahl 6 

1.3 Evolution des Plans 

Plan für vorausgesehene und nicht vorausgesehene Aktualisierung des 

Projektplans und deren Bekanntmachung 

1.4 Referenzen 

1.5 Definitionen und Akronyme 

2009-02-09 

6 Die Anforderungsspezifikation ist ein separates Dokument! 



Planung 

Inhalt 



Einleitung 

1.1 Projektübersicht 

Zusammenfassung der Ziele, Resultate, Hauptarbeitsaktivitäten und 

-produkte, Hauptmeilensteine, benötigte Ressourcen, grober Zeitplan 

und Budget; Kontaktdaten des Kunden 

1.2 Auszuliefernde Produkte 

alle an den Kunden auszuliefernde Produkte mit Auslieferungsdatum 

und -ort sowie deren Anzahl 6 

1.3 Evolution des Plans 

Plan für vorausgesehene und nicht vorausgesehene Aktualisierung des 

Projektplans und deren Bekanntmachung 


1.5 Definitionen und Akronyme 

6 Die Anforderungsspezifikation ist ein separates Dokument! 

Die Referenzen enthalten Verweise auf alle Dokumente und andere Informationsquellen, die im Projektplan 

referenziert werden. Hierfür gelten die üblichen Zitierregeln. 

Der Abschnitt “Definitionen und Akronyme” beschreibt alle Begriffe, die für das Verständnis des Projektplans 

notwendig sind, auch in Form von Verweisen auf entsprechende Dokumente mit deren Definition. 

Es handelt sich hier nicht um das Glossar der Anforderungsspezifikation, von dem später noch die Rede sein wird. 

Der Projektplan kann aber auf dieses Glossar verweisen.



Projektorganisation 

2.1 Prozessmodell 

Beziehungen zwischen den Projektfunktionen und -aktivitäten mit 

Hauptmeilensteinen, Baselines, Reviews, Produkte (interne und 

auszuliefernde) und Abschlüsse 

2.2 Organisationsstruktur 

interne Managementstruktur (z.B. durch Organigramme): 

Weisungsbefugnis, Verantwortlichkeit und Kommunikation im Projekt 7 

2.3 Organisationsgrenzen und -schnittstellen 

zwischen übergeordneter Organisation, Kundenorganisation und 

Untervertragsnehmer 

2.4 Verantwortlichkeiten 

Auflistung aller Projektfunktionen und -aktivitäten unter Nennung der 

Verantwortlichen 

7 Kontaktdaten aller Beteiligter nicht vergessen! 




Managementprozess 

3.1 Managementziele und -prioritäten 

Beispiele: Häufigkeit und Mechanismen der Berichterstattung; relative 

Prioritäten zwischen Anforderungen, Zeitplan und Budget; Absicht zur 

Wiederverwendung existierender Software 

3.2 Annahmen, Abhängigkeiten und Einschränkungen 

Annahmen, auf denen das Projekt beruht; externe Ereignisse, von 

denen es abhängt; Beschränkungen, unter denen das Projekt 

durchgeführt wird 

3.3 Risikomanagement 

Identifikation und Bewertung von Risiken; Mechanismen für Verfolgung 

der Risikofaktoren; Notfallpläne; 

Beispiele: Risiken mit Verträgen, technologische Risiken, Größe und 

Komplexität der Aufgabe, Personal, Akzeptanz des Kunden etc. 




Managementprozess (Fortsetzung) 

3.4 Projektüberwachung 

Berichtswesen, Formate für Berichte, Informationsflüsse, Reviews und 

Audits; auf der Ebene von Arbeitspaketen; Beziehung zu 

Projektfunktionen (bspw. Qualitätssicherung, 

Konfigurationsmanagement) 

3.5 Mitarbeiter 

Anzahl und Typen der notwendigen Mitarbeiter; erforderliche 

Fähigkeiten, Beginn und Dauer der Mitarbeit; Methoden zur 

Anwerbung, Ausbildung, Bindung und Ausgliederung von Mitarbeitern 




Technische Prozesse 

4.1 Methoden, Werkzeuge und Techniken 

Entwicklungsplattform, Entwicklungsmethode, Programmiersprache 

sowie andere Notationen, Techniken und Methoden, um das System 

und andere auszuliefernde Produkte zu spezifizieren, entwerfen, 

konstruieren, testen, integrieren, dokumentieren, modifizieren oder 

pflegen; 

technische Standards, Richtlinien, Zertifizierungskriterien 

4.2 Dokumentationsplan 

Anforderungen an die Dokumentation, Meilensteine, Baselines, Reviews 

und Abnahme der Software-Dokumentation; 

Style-Guide, Namenskonventionen, Dokumentationsformate 

4.3 Unterstützende Projektfunktionen 

z.B. Konfigurationsmanagement und Qualitätssicherung 

mit Verantwortlichkeiten, Ressourcen, Zeitplänen und Budget 




Arbeitspakete, Zeitplan und Budget 

5.1 Arbeitspakete 

eindeutig identifizierbar (z.B. mit Nummer); 

Zerlegung der Arbeitspakete 

5.2 Abhängigkeiten 

Abhängigkeiten zwischen Arbeitspaketen und zu externen Elementen; 

Reihenfolge der Abarbeitung 

5.3 Ressourcenanforderung 

Dauer und Ressourcen; 

Beispiele: Anzahl und Qualifikation des Personals, Hardware, 

unterstützende Software, Büro- und Laborräume, Reisekosten, 

Wartungskosten 

5.4 Zuteilung des Budgets und der Ressourcen auf Projektfunktionen und 

Aktivitäten 

5.5 Zeitplan 




Beispiele für zusätzliche Elemente: 

Managementpläne für Unterauftragsnehmer 

Ausbildungspläne 

Beschaffungspläne für Hardware 

Raumpläne 

Installationspläne 

Pläne für die Konvertierung von Daten 

Pläne für die 

Übergabe des Systems (intern, extern) 

Pläne für die Wartung und Evolution 



Zeitplan: Aktivitäten und Dauer (Gantt-Diagramme) 

2009-02-09 



Planung 

Zeitplan 



Die Gantt-Notation ist nach ihrem Erfinder, Henry L. Gantt (1917), benannt. Sie beschreibt kausale 

Abhängigkeiten einzelner Aktivitäten sowie deren zeitlichen Verlauf. 

Das Projekt wird zunächst in einzelne Aktivitäten gegliedert. Deren Aufwand wird geschätzt. Mögliche Aktivitäten 

behandeln wir in späteren Kapiteln. 

Die Granularität der Aktivitäten muss angemessen sein. Die in diesem Beispiel gewählte ist es sicher nicht. Je 

detaillierter die Angabe desto leichter fällt die Schätzung (und desto aufwändiger die Planung; was sich jedoch in 

der Regel auszahlt). “Anfängern” ist eine möglichst feingranulare Darstellung zu empfehlen, da ihre Schätzung 

dadurch zuverlässiger wird.


Zeitplan: Meilensteine 

2009-02-09 



Planung 

Zeitplan 



An verschiedenen Zeitpunkten des Projekts werden Meilensteine gesetzt. 

Ein Meilenstein ist ein Zeitpunkt, zu dem ein prüfbares Ergebnis vorliegen muss. 

Meilensteine erlauben die Beobachtung des Projektfortschritts. Die Projektverfolgung und die Qualitätssicherung 

werden interne Meilensteine setzen, also solche die nur dem Projekt bekannt sind, wie zum Beispiel das Review des 

Entwurfs. Zumindest bei jeder Übergabe eines Zwischenprodukts (Entwurfsdokument, Quellcode etc.) sollte ein 

Meilenstein definiert werden, der die Übergebenden und Empfänger des Zwischenprodukts einbezieht. Der 

Meilenstein legt die Kriterien für eine erfolgreiche Übergabe fest. 

Externe Meilensteine involvieren den Kunden, z.B. die Abnahme der Spezifikation und der Akzeptanztest.


Zeitplan: Abhängigkeiten 

2009-02-09 



Planung 

Zeitplan 



Zwischen den Aktivitäten existieren kausale Abhängigkeiten, die festgelegt werden müssen. Beispielsweise kann nur 

getestet werden, wenn der Quellcode existiert. 

Die kausalen Abhängigkeiten führen zu einer partiellen Sequenzialisierung der Aktivitäten.


Zeitplan: Verfeinerung 

2009-02-09 



Planung 

Zeitplan 



Grobgranulare Aktivitäten sollten verfeinert werden (siehe oben). Die Verfeinerung erlaubt auch eine getreuere 

Darstellung der Abhängigkeiten zwischen den Aktivitäten. So können zum Beispiel Testfälle für den Black-Box-Test 

(siehe das spätere Kapitel über Tests) bereits beim Vorliegen der Spezifikation vorbereitet werden. 

Dadurch kann die Möglichkeit zur Parallelisierung der Aktivitäten erhöht werden.


Zeitplan: Ressourcen 

2009-02-09 



Planung 

Zeitplan 



Ressourcen im Software-Projekt sind in der Regel menschliche Wesen. Bei der Entwicklung eingebetteter Systeme 

ist z.B. auch die Zielhardware eine Ressource, die eingeplant werden muss. In vielen Fällen wird sie parallel zur 

Software entwickelt. 

Der Kunde ist eine wichtige Ressource, die eingeplant werden muss, und selten verfügbar ist. 

Der Begriff “Ressource” auf Menschen angewandt klingt sehr technokratisch. Das ist hier nicht so gemeint.


Zeitplan: Einplanung der Ressourcen 

2009-02-09 



Planung 

Zeitplan 



Schließlich werden die Ressourcen den Aktivitäten zugewiesen. Dadurch kann sich die Dauer von Aktivitäten 

verlängern oder verkürzen. Sie verlängern sich zum Beispiel, weil ein Entwickler auch für quasi-zeitgleiche 

Aktivitäten eingeplant wurde und selbstverständlich eine begrenzte wöchentliche Arbeitszeit hat. Sie verkürzt sich, 

wenn mehrere Entwickler einer Aktivität zugeordnet werden. Aber Achtung! Im Gegensatz zu anderen Projekten 

gilt im Software-Projekt nicht: 

Dauer = 

Aufwand 

Anzahl Personen 

Je mehr Personen an einer Aktivität beteiligt sind desto höher ist der Aufwand für Kommunikation und 

Abstimmung. Statt dessen gilt der Rat: Weniger und bessere Leute nehmen! 

Ein noch häufiger Irrglaube ist, dass man durch späte Hinzunahme zusätzlicher Leute einen in Schieflage geratenen 

Plan noch einhalten kann. Der Aufwand erhöht sich dann nicht nur durch erhöhte Kommunikation, sondern auch 

durch die Einarbeitung der Neuen.


Kritischer Pfad 

Definition 

Kritischer Pfad: die von der Dauer her längste Kette von Aktivitäten. 

bestimmt die Dauer des Projekts; 

Verspätungen in dieser Kette schlagen sich auf die Dauer des Projekts 

nieder; 

muss während des Projektverlaufs stets im Auge behalten werden. 



Geschriebene Codezeilen im SWP 05/06 

27500 

25000 

22500 

20000 

17500 

15000 

12500 

10000 

7500 

5000 

2500 

0 

LOC pro Gruppe 


Test 

Code


Aufwandsverteilung im SWP 05/06 

Aufwand/h 

1300 

1200 

1100 

1000 

900 

800 

700 

600 

500 

400 

300 

200 

100 

0 

Aufwand nach Phasen 

Plan Spez. Arch. Impl. Test Doku Bespr. Sonst. 



Note versus Aufwand 

Aufwand/h 

3500 

3000 

2500 

2000 

1500 

1000 

500 

Aufwand zu Note 

0 

1 1,5 2 2,5 3 3,5 4 

Note 



Planung: Soll und Ist 

tatsächliche Stunden 

6000 

5000 

4000 

3000 

2000 

1000 

Plan zu IstStunden 

0 

0 1000 2000 3000 4000 5000 6000 

geplante Stunden 



Arbeitsstunden pro Tag 

Gesamtstunden 

1100 

1000 

900 

800 

700 

600 

500 

400 

300 

200 

100 

0 

Stunden nach Tag 

Tag der Projektlaufzeit 



Risiken 

If you do not actively attack the risks in your project, they will 

actively attack you. 

– Gilb (1988) 

Definition 

Ein Risiko ist ein Ereignis, dessen Eintreten den Erfolg des Projekts 

entscheidend behindern kann. 

Quantifizierte Risikohöhe = Eintrittswahrscheinlichkeit × max. 

Schadenshöhe 

Risikomanagement kümmert sich um Risiken, bevor sie auftreten. 

Krisenmanagement kümmert sich um aufgetretene Risiken. 




Risikoanalyse 

Identifizierung der Risiken 

Einschätzung der Eintrittswahrscheinlichkeit 

Einschätzung des potentiellen Schadens 

Risikomaßnahmen: Planung von Gegenmaßnahmen 

Vermeidung: Unterlassung der Aktivität 

Verminderung/Begrenzung auf akzeptables Maß, z.B. Streuung oder 

Haftung bis zu einem Limit 

Abwälzung: z.B. Unterauftragnehmer 

Akzeptanz, wenn Kosten/Nutzen im Verhältnis stehen 

Risiko-Controlling: Monitoring während des Projekts 



Risiken identifizieren 

Produktimmanent 

Produkt 

Technologie 

z.B. ungenaue Anforderungen 

z.B. instabile Anforderungen 

Projektimmanent 

Mensch 

Vorgehen 

Management/Organisation 

Infrastruktur 

z.B. Ressourcenprobleme 

z.B. mangelnde Motivation 

Umfeldabhängig 

Organisatorische Einbettung 

Politik 

Recht 

Kultur 

→ Historie: aus abgeschlossenen Projekten lernen 

2009-02-09 

z.B. Verschiebung von 

Prioritäten 

z.B. Abhängigkeit zu anderen 

Projekten 



Planung 


Risiken im Software-Projekt 

Zu Risiken und Nebenwirkungen fragen Sie Ihren 

Risiken identifizieren 

Produktimmanent 

Produkt 

Technologie 

z.B. ungenaue Anforderungen 

z.B. instabile Anforderungen 

Projektimmanent 

Mensch 

Vorgehen 

Management/Organisation 

Infrastruktur 

z.B. Ressourcenprobleme 

z.B. mangelnde Motivation 

. . . gesunden Menschenverstand, erfahrene Software-Entwickler, die Tageszeitung, die Literatur über 

Softwaretechnik . . . 

→ Historie: aus abgeschlossenen Projekten lernen 

Umfeldabhängig 

Organisatorische Einbettung 

Politik 

Recht 

Kultur 

z.B. Verschiebung von 

Prioritäten 

z.B. Abhängigkeit zu anderen 

Projekten


Personalausfall 

Häufigkeit 

40% 

35% 

30% 

25% 

20% 

15% 

10% 

5% 

0% 

Personalausfall 

0 1 2 3 4 5 split 

Ausfälle 



Note versus Personalausfall 

Durchschnittsnote 

Note nach Personalausfall 

4 

3,5 

3 

2,5 

2 

1,5 

1 

0 1 2 3 4 5 split 

Ausfälle 



Projektabbruch 

31% aller Software-Projekte werden vor Abschluss abgebrochen; weitere 

53% sprengen den Zeit- oder Kostenrahmen oder liefern nicht die volle 

Funktionalität (Standish Group 1994) 8 

Gilt: Abbruch = Misserfolg wegen mangelhaftem Management? 

8 Dieser Bericht ist nicht unumstritten. Es gibt eine Reihe anderer Untersuchungen 

mit unterschiedlichen Ergebnissen Buschermöhle u. a. (2006); Sauer und Cuthbertson 

(2003); Standish Group (2004) 

2009-02-09 



Planung 




31% aller Software-Projekte werden vor Abschluss abgebrochen; weitere 

53% sprengen den Zeit- oder Kostenrahmen oder liefern nicht die volle 

Funktionalität (Standish Group 1994) 8 

Gilt: Abbruch = Misserfolg wegen mangelhaftem Management? 

8 Dieser Bericht ist nicht unumstritten. Es gibt eine Reihe anderer Untersuchungen 

mit unterschiedlichen Ergebnissen Buschermöhle u. a. (2006); Sauer und Cuthbertson 

(2003); Standish Group (2004) 

Die Statistik über den Abbruch von Projekten legt die Folgerung nahe, dass die Projekte abgebrochen wurden, weil 

sie schlecht geführt wurden. Diese Implikation ist falsch und gefährlich. Sie ist falsch, weil viele gut geführte 

Projekte abgebrochen werden, weil sich ihre ursprünglichen Annahmen geändert haben. Sie werden aus 

vertretbarem Grund beendet. Dies ist vor allem in Feldern mit schnellem Wandel häufig anzutreffen. 

Die Implikation ist gefährlich, weil Projektmanager sich der Verführung konfrontiert sehen, ein eigentlich obsoletes 

Projekt weiterzuführen, um nicht als Versager dazustehen. Es gibt oft gute, vertretbare Gründe, ein Projekt 

abzubrechen. Der Abbruch ist dann weiser als die Fortführung.


Gründe für Projektabbruch nach Boehm (2000) 

Unvollständige Anforderungen (13 % 9 ): 

Ursache bei 

schlecht geführtem Projekt gut geführtem Projekt 

meistens häufig 

Projekt startet ohne klare Idee der 

Bedürfnisse und Prioritäten der 

Stakeholder. 

2009-02-09 

9 relativ zu den abgebrochenen Projekten 

Stakeholder können sich nicht auf 

Anforderungen einigen. 



Planung 




Unvollständige Anforderungen (13 % 9 ): 

Ursache bei 



Projekt startet ohne klare Idee der 

Bedürfnisse und Prioritäten der 

Stakeholder. 

9 relativ zu den abgebrochenen Projekten 

Die angegebenen Zahlen hat Barry Boehm anhand von Projekten ermittelt, bei denen er selbst involviert war (5-6 

Projekte für digitale Bibliotheken pro Jahr, Begutachtung von ungefähr 20 Berichten über abgebrochene 

Industrieprojekte, die unter Beteiligung von den 30 Angehörigen des Center for Software Engineering, das er leitet. 

Andere Autoren berichten von Abbruchraten mit 40% und 50%, insbesondere für Gebiete, in denen neue Produkte 

eingeführt werden Hayes (1997). 

Die meisten hier genannten Ursachen für Abbrüche stellen handfeste Risiken für Ihr Software-Projekt dar, denen Sie 

sich bewusst sein sollten. Die Fehler, die bei schlecht geführten Projekten gemacht werden, sollten Sie meiden. 

Für Sie folgt hier: Machen Sie die Anforderungen und Prioritäten Ihres Kunden fest, bevor Sie anfangen zu 

entwerfen und zu implementieren. 

Stakeholder können sich nicht auf 

Anforderungen einigen.



Mangelhafte Einbeziehung der Benutzer (12 %): 

Ursache bei 


Projekt kommuniziert nicht mit 

Benutzer. 

2009-02-09 

gleich häufig 

Benutzer kommuniziert nicht mit 

Projekt. 



Planung 




Mangelhafte Einbeziehung der Benutzer (12 %): 

Ursache bei 



Projekt kommuniziert nicht mit 

Benutzer. 

Für Sie folgt hier: Suchen Sie Ihren Kunden auf. Beziehen Sie ihn bei der Anforderungsanalyse ein. Machen Sie eine 

anständige und umfassende Ist-Analyse. Lassen Sie den Kunden das Pflichtenheft prüfen (verwenden Sie dabei eine 

ihm passende Terminologie; definieren Sie ein Begriffslexikon). Entwickeln Sie Prototypen, die Sie dem Kunden 

vorführen. Halten Sie Kontakt mit dem Kunden auch während der Implementierungsphase. Prüfen Sie periodisch, 

ob sich seine Prioritäten und Anforderungen geändert haben. 

Benutzer kommuniziert nicht mit 

Projekt.



Mangel an Ressourcen (11 %): 

Ursache bei 


gleich häufig; schlecht geführte Projekte haben jedoch niedrigeren 

Geschäftswert und sind tendenziell eher betroffen 

Projekt hat wenig Geschäftswert. 

Budgeteinschnitte, Verkleinerungen, Repriorisierungen. 

2009-02-09 



Planung 




Mangel an Ressourcen (11 %): 

Ursache bei 


gleich häufig; schlecht geführte Projekte haben jedoch niedrigeren 

Geschäftswert und sind tendenziell eher betroffen 

Projekt hat wenig Geschäftswert. 

Budgeteinschnitte, Verkleinerungen, Repriorisierungen. 

Für Sie folgt hier: Ihre Ressource ist im Wesentlichen die Zeit; insbesondere auch die Zeit Ihrer Mitstreiter im 

Projekt. Deren Prioritäten sind nicht immer die Ihrigen. Manche Projektteilnehmer werden es an Einsatz vermissen 

lassen. 

Weitere potenziell mangelnde Ressourcen sind Rechner, Netzwerke und Software-Werkzeuge, die Sie für Ihr Projekt 

benötigen.



Unrealistische Erwartungen (10 %): 

Ursache bei 



Machbarkeit wurde nicht geprüft. Machbarkeitsprüfung fiel negativ 

aus. 

2009-02-09 



Planung 




Unrealistische Erwartungen (10 %): 

Ursache bei 



Machbarkeit wurde nicht geprüft. Machbarkeitsprüfung fiel negativ 

aus. 

Unrealistische Erwartungen des Benutzers liegen in dessen Natur. Er kennt selten technische Randbedingungen und 

Grenzen der Berechenbarkeit. Software gilt als beliebig flexibel: “Ich dachte, da müssen Sie nur ein Bit umkippen.”. 

Und selbstverständlich will er stets noch einmal über den Preis reden. 

Die Tutoren werden versuchen, den Benutzer realistisch zu simulieren. 

Aber auch Sie selbst könnten zu unrealistischen Erwartungen neigen. Sie sind möglicherweise nicht mit dem 

Anwendungsbereich vertraut genug oder unterschätzen den Aufwand an Kommunikation, den ein 

Mehrpersonenprojekt mit sich bringt, und den Aufwand für die Analyse, den Entwurf und den Test. 

Letztlich steht Ihnen circa ein Tag pro Woche für das Projekt zur Verfügung, und diese Projekttage sind 

unterbrochen von vielen anderen Aktivitäten. 

Für Sie folgt hier: Klopfen Sie frühzeitig die Anforderungen des Kunden auf Machbarkeit ab. Erstellen Sie 

Prototypen, um die Machbarkeit kritischer Anforderungen zu überprüfen. Planen Sie realistisch. Geben sie nicht in 

allen Punkten dem Kunden nach, wenn dieser seine Wünsche äußert. Es gilt “quid pro quo”: etwas für etwas. Will 

er X, muss er sich bei Y beschränken. Verlangen Sie ihm Prioritäten ab.



Mangelnde Unterstützung bei der Ausführung (9 %): 

Ursache bei 



Manager machen unverifizierte 

Annahmen über Unterstützung (z.B. 

verlassen sich darauf, dass andere 

Initiativen repriorisiert werden, um 

Projekt zu unterstützen). 

2009-02-09 

Unterstützung wird entzogen 

(z.B. Verantwortliche werden 

ausgetauscht; neue 

Verantwortliche haben andere 

Prioritäten und Agenda). 



Planung 




Mangelnde Unterstützung bei der Ausführung (9 %): 

Ursache bei 



Manager machen unverifizierte 

Annahmen über Unterstützung (z.B. 

verlassen sich darauf, dass andere 

Initiativen repriorisiert werden, um 

Projekt zu unterstützen). 

Sie müssen sich mit Mitgliedern Ihrer Gruppe und auch mit anderen Gruppen auseinander setzen. Der Betreuer/die 

Betreuerin betreut mehrere Gruppen und hat noch viele andere Pflichten. Teilnehmer wie Betreuer sind 

möglicherweise zeitweise oder auch dauerhaft nicht verfügbar. 

Für Sie folgt hier: Seien Sie explizit darüber, was Sie von anderen erwarten und auch bis wann Sie etwas erwarten. 

Kommunizieren Sie! 

Unterstützung wird entzogen 

(z.B. Verantwortliche werden 

ausgetauscht; neue 

Verantwortliche haben andere 

Prioritäten und Agenda).



Anforderungen ändern sich (9%): 

Ursache bei 


meistens nicht selten 

Änderungen werden akzeptiert, ohne 

dass Budget und Projektplan 

angepasst werden. 

2009-02-09 

Folgekosten der Änderung 

überwiegen den Nutzen des 

Projekts. 



Planung 




Anforderungen ändern sich (9%): 

Ursache bei 


meistens nicht selten 

Änderungen werden akzeptiert, ohne 

dass Budget und Projektplan 

angepasst werden. 

Die Anforderungen sind am Anfang nicht klar verstanden. Der Kunde selbst wird sich im Laufe des Projekt klarer 

darüber, was er eigentlich will. Rahmenbedingungen ändern sich. 

Die Anforderungen sind selten als stabil zu betrachten. 

Für Sie folgt hier: Halten Sie vertraglich fest, wie Sie und der Kunde mit Änderungen umgehen wollen. Antizipieren 

Sie mögliche Änderungen. Überlegen Sie sich gut, welche Änderung Sie akzeptieren. Seien Sie sich über die 

Konsequenzen einer Änderung im Klaren. 

Folgekosten der Änderung 

überwiegen den Nutzen des 

Projekts.



Mangelhafte Planung (8%): 

Ursache bei 


immer — 

Projektmanager haben keine 

Ahnung, wo sie sich befinden und 

wann das Projekt fertig wird. 

2009-02-09 



Planung 




Mangelhafte Planung (8%): 

Ursache bei 


immer — 

Projektmanager haben keine 

Ahnung, wo sie sich befinden und 

wann das Projekt fertig wird. 

Sie sind weder mit dem Anwendungsbereich noch mit einem Projekt dieser Art vertraut. Sie werden es besonders 

schwer haben. 

Für Sie folgt: Seien Sie nicht zu optimistisch. Unterschätzen Sie nicht das Problem, insbesondere in seinen Details, 

und überschätzen Sie nicht sich selbst. 

Planen Sie und seien Sie sich zu jedem Zeitpunkt darüber im Klaren, wo sie sich tatsächlich befinden und was Ihr 

Planziel war. Seien Sie vorsichtig in dem Glauben “Das holen wir später wieder ein”. 

Wenn Soll und Ist zu weit auseinander klaffen, reagieren Sie. Sprechen Sie frühzeitig mit Ihrem Kunden über 

mögliche Einschränkungen bei der Leistung. Der Kunde ist sehr wahrscheinlich besser bedient, wenn er wenigsten 

etwas bekommt, und nicht gar nichts. Das Vertrauensverhältnis wäre auf immer zerrüttet, wenn Sie ihm erst am 

Tag der Auslieferung über den wahren Zustand Ihres Projekts aufklären. 

Denken Sie an die Manager von TollCollect, die noch einen Monat vor der geplanten Einführung behauptet haben, 

sie würden den Termin halten.



Kein Nutzen (8%): 

Ursache bei 


gleich häufig in Feldern mit schnellem Wandel 

Gute Projektmanager verfolgen 

Trends und erkennen 

nachlassenden Nutzen früher; sie 

reagieren frühzeitiger mit 

Abbruch. 




Mangelndes IT-Management (6%): 

Ursache bei 


immer — 

Offensichtlich mangelhaftes Management. 


2009-02-09 


Planung 




Mangelndes IT-Management (6%): 

Ursache bei 


immer — 

Offensichtlich mangelhaftes Management. 

Gehen Sie in die Vorlesung. Die Vorlesung möchte Sie genau hiervor bewahren. Kommen Sie nicht allein weiter, 

holen sich den Rat eines externen Consultants, sprich Ihres Tutors, ein. 

Sollten Sie nicht selbst der Projektmanager sein, dann sprechen Sie mit ihm offen über das Problem. Ein 

Projektleiter ist kein General, sondern ein Dienstleister für die Projektmitglieder. Er soll die Übersicht wahren und 

das Projekt zusammenhalten. Schafft er dies nicht, obwohl Sie mit ihm darüber geredet haben, wechseln Sie Ihn aus. 



Mangelndes Verständnis der Technologie (4%): 

Ursache bei 


allermeistens — 

Fehlende Kenntnisse der Entwickler 

und Manager; Projekte, die niemals 

hätten begonnen werden sollen. 


2009-02-09 


Planung 




Mangelndes Verständnis der Technologie (4%): 

Ursache bei 


allermeistens — 

Fehlende Kenntnisse der Entwickler 

und Manager; Projekte, die niemals 

hätten begonnen werden sollen. 

Bilden Sie Experten, die sich mit spezifischen technischen Problemen gezielt auseinander setzen. Bauen Sie 

Prototypen in einer Technologie, die Sie noch nicht beherrschen. Drehen Sie nicht gleichzeitig an zu vielen 

Schrauben: Nicht allen Technologien gleichzeitig hinterherlaufen, sondern eine nach der anderen inkrementell 

einführen. Betrachten Sie das Problem unbekannter Technologien frühzeitig in ihrem Projektplan (räumen Sie 

zusätzliche Zeit hierfür ein). Bedenken Sie, dass es nicht ausreicht, mehrere Technologien isoliert zu beherrschen. 

Sie könnten Ihr blaues Wunder erleben, wenn Sie versuchen, diese Technologien miteinander zu integrieren. 


Menschliche Wahrnehmung von Risiken 

Selbstgewählte Gefahren erscheinen geringer als aufgezwungene. 

Prinzipiell kontrollierbare Risiken sind akzeptabler als solche, auf die 

wir scheinbar keinen Einfluss haben. 

Natürliche Risiken werden eher hingenommen als von Menschen 

geschaffene. 

Katastrophen alarmieren uns mehr als der alltägliche Wahnsinn. 

Risiken, die von schwer fassbaren Techniken ausgehen, werden eher 

wahrgenommen als die von vertrauten Techniken. 

Schlechte Nachrichten werden eher geglaubt als positive. 


2009-02-09 


Allgemein: 

Planung 




Selbstgewählte Gefahren erscheinen geringer als aufgezwungene. 

Prinzipiell kontrollierbare Risiken sind akzeptabler als solche, auf die 

wir scheinbar keinen Einfluss haben. 

Natürliche Risiken werden eher hingenommen als von Menschen 

geschaffene. 

Katastrophen alarmieren uns mehr als der alltägliche Wahnsinn. 

Risiken, die von schwer fassbaren Techniken ausgehen, werden eher 

wahrgenommen als die von vertrauten Techniken. 

Schlechte Nachrichten werden eher geglaubt als positive. 

• Die Risiken bestimmter Sportarten wie Skifahren oder Reiten gehen wir bewusst ein. Dagegen wehren wir uns gegen 

Konservierungsstoffe in der Nahrung. 

• Fettes, nährstoffarmes Essen ist beliebt, während Leitungswasser auch dann gemieden wird, wenn die Trinkqualität 

garantiert ist. 

• In der Erde vorkommendes Radon erscheint uns harmlos im Vergleich zur selben Strahlungsintensität aus künstlichen 

Quellen. 

• Werden nach einem Schiffsunglück Giftbeutel oder Ölklumpen an die Strände geschwemmt, ist die Aufregung groß, 

während die schleichende Vergiftung der Meere kaum zur Kenntnis genommen wird. 

• Eine Müllverbrennungsanlage mit relativ geringen Emissionen wird bekämpft, der Autoverkehr hingegen verteidigt. 

• Stürme und Überschwemmungen gelten als Beweis für den Treibhauseffekt, doch die geringer gewordene Verschmutzung 

des Rheins halten viele für Propaganda der Industrie. 

In der Software-Entwicklung: 

• Eine vom Kunden gewollte fremde Technologie erscheint uns riskanter als eine selbst gewollte fremde Technologie. 

• Wie scheuen uns eine Software-Bibliothek zu verwenden und implementieren unsere Hash-Tabelle lieber selbst. 

• Rutschige Straßenverhältnisse erscheinen uns harmlos im Vergleich zu Fehlern in der Software des Bremssystems im 

Auto. 

• Der Projektabbruch alarmiert uns mehr als die schleichende Verschlechterung der Qualität, die wir ausliefern. 

• Die Einführung der Cleanroom-Development-Methode erscheint uns riskanter als die Code-and-Fix-Methode. 

• Das Gerücht, dass das Projekt in Schieflage geraten ist, macht hellhörig; eine Aussage, die Deadline werde eingehalten, 

glauben wir gerne. 


Wiederholungsfragen I 

Erstellen Sie einen Projektplan für ein Software-Projekt. 

Was sind die Elemente eines Projekts? Insbesondere was ist ein 

Meilenstein und eine Baseline? 

Wann wird geplant? 

Wie geht man beim Planen vor? 

Was ist der Inhalt eines Projektplans? 

Was ist ein Gantt-Diagramm? 

Was ist ein kritischer Pfad? Welche Bedeutung hat er? 

Was sind die Ressourcen eines Software-Projekts? Was sind deren 

Besonderheiten? 

Was sind typische Risiken in einem Software-Projekt? Wie geht man 

mit ihnen um? 

Was sind die Besonderheiten eines Software-Projekts? 



Wiederholungsfragen II 

Welche Risiken sind typisch für Software-Projekte? Wie ist mit ihnen 

umzugehen? 

Erläutern Sie Risiko-Management. 


Anforderungsanalyse 





Ablauf 

Zeitplan 

Anmeldung 




Kontaktdaten 

Ressourcen 

Lehrbücher 






RainerProjekt Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 106 / 634


Lernziele 

2009-02-09 

Ist- und Soll-Zustand ermitteln können 

Anforderungsspezifikation schreiben können 

Anforderungsspezifikation begutachten können 




Lernziele 

Lernziele 

Lernziele 

Ist- und Soll-Zustand ermitteln können 

Anforderungsspezifikation schreiben können 

Anforderungsspezifikation begutachten können 

Bevor ein System implementiert werden kann, müssen die Anforderungen an das System erhoben werden. Dieser 

Aufgabe widmet sich die Anforderungsanalyse. Ihr Ziel ist es, einen möglichst genauen und vollständigen Katalog 

von Anforderungen an ein System zu erfassen und zu beschreiben. Die Anforderungen beschreiben ein 

Soll-Konzept, das Verbesserung für ein Problem des Kunden schaffen soll. Damit dieses Konzept auch wirklich hilft, 

ist es notwendig, zuerst einmal zu verstehen, was das Problem des Kunden ist. Insofern ist die Analyse des 

Ist-Zustands und seiner Probleme Teil einer Anforderungsanalyse. 

Das Ergebnis der Anforderungsanalyse ist der Katalog der Anforderungen. In welcher Form dieser Katalog 

beschrieben ist, hängt vom Vorgehensmodell ab. Bei dokumentengetriebenen Vorgehensmodellen – wie dem 

Wasserfallmodell – werden die Anforderungen in Form einer Anforderungsspezifikation schriftlich festgehalten. In 

vielen agilen Vorgehensmodellen erfolgt die Anforderungsspezifikation als Zuruf des Kunden. 

Wann und wie oft die Anforderungsanalyse durchgeführt wird, hängt ebenso stark vom Vorgehensmodell zur 

Softwareentwicklung ab. Beim Wasserfallmodell wird die Anforderungsanalyse nur einmal und ganz zu Anfang 

durchgeführt. Beim inkrementellen Vorgehen, bei dem die Entwicklung in kleinen abgeschlossenen Inkrementen des 

zu entwickelnden Systems erfolgt, wird sie jedes Mal wieder vor der Entwicklung jedes Inkrements durchgeführt. 

Beim Extreme-Programming hat man durch die Präsenz eines Kundenvertreters vor Ort eine fast kontinuierlich 

stattfindende Anforderungsanalyse. 

In diesem Modul geht es um die Durchführung der Anforderungsanalyse. Wir streben hier die schriftliche 

Dokumentation der Anforderungen in Form einer Anforderungsspezifikation an, da dies in den meisten Fällen eine 

Reihe von Problemen vermeidet. Der Inhalt dieses Abschnitts ist jedoch auch für agiles Vorgehen ohne schriftliche 

Spezifikation der Anforderungen relevant, weil auch orale Überlieferung zu allen Aspekten der 

Anforderungsspezifikation Stellung nehmen muss. 

Übersicht: 

Zunächst widmen wir uns der Frage, warum die Anforderungsanalyse so wichtig aber leider auch schwierig ist. 

Dann lernen wir die grundsätzlichen Schritte der Anforderungsanalyse kennen. Dazu gehören die Erfassung des 

Ist-Zustands und seiner Probleme durch die Ist-Analyse, die angestrebte Verbesserung durch ein Soll-Konzept durch 

die Soll-Analyse und die genaue und vollständige Beschreibung der Anforderungen in Form einer 

Anforderungsspezifikation. Wir vertiefen alle Schritte und lernen Techniken für diese einzelnen Schritte kennen.


Wegweiser 


Warum sind die Anforderungen so kritisch? 

Warum ist ihre Erhebung so schwer? 



Kosten für Änderungen 

Kosten für Änderung 

1 x 

1,5 − 6 x 

Definition Entwicklung 

60 − 100 x 

nach Auslieferung 

Zeit 

Pressman (2003) 


2009-02-09 






Kosten für Änderung 

1 x 

1,5 − 6 x 

60 − 100 x 

Zeit 

Definition Entwicklung nach Auslieferung 

Die Anforderunganalyse ist von zentraler Bedeutung für den Erfolg eines Projektes. Passieren hier Fehler, entsteht 

ein System, was an den Bedürfnissen des Kunden vorbei entwickelt und damit unbrauchbar wird. Fehler in der 

Anforderungsanalyse können zwar oft noch in späteren Phasen entdeckt und dann korrigiert werden, die Korrektur 

dieser Fehler ist jedoch meist mit einem erheblichen Mehraufwand verbunden. Pressman (2003) berichtet von den 

relativen Kosten für Korrekturen von Fehlern in der Anforderungsanalyse in Abhängigkeit vom Zeitpunkt, zu dem 

diese Fehler bekannt werden. Findet man einen Fehler der Anforderungsspezifikation in späteren Aktivitäten der 

Entwicklung, also beim Entwurf, der Implementierung oder dem Test noch vor Auslieferung, dann können die 

Kosten um einen Faktor 1,5 bis 6 höher sein als die Korrekturkosten, die entstanden wären, hätte man den Fehler 

noch während der Anforderungsanalyse gefunden. Wird der Fehler noch später gefunden, also nach der Auslieferung 

der Software, kann er gar um einen Faktor 60 bis 100 höher sein. Es entstehen dann nicht nur zusätzliche Kosten 

für die Nachbesserung von Anforderungsspezifikation und Entwurf, Fehlerkorrektur und Restrukturierung der 

Implementierung sowie Wiederholung des Tests. Es entstehen darüber hinaus auch Kosten für die Beseitigung von 

Auswirkungen des Fehlers. Hat eine eingebettete Software in einem Automobil beispielsweise einen Fehler, so 

müssen alle Fahrzeuge in der Werkstatt überholt werden. Dadurch entstehen hohe direkte Kosten, aber auch noch 

indirekte Kosten durch den Imageverlust des Automobilherstellers, wenn sich der Imageverlust auf die 

Verkaufszahlen auswirkt. 


Warum die Anforderungsanalyse so schwer ist 

Kunden wissen häufig nicht, was sie genau wollen, bzw. können es 

nicht genau äußern 

Kunden sprechen ihre Sprache, die von Entwicklern nicht verstanden 

wird 

unterschiedliche Kundengruppen haben unterschiedliche 

Anforderungen, die sich mitunter widersprechen 

politische Entscheidungen können Anforderungen beeinflussen 

die Welt ändert sich, die Anforderungen an die Software auch; auch 

während der Entwicklung 

Pressman (2003) 

– Sommerville (2004) 


2009-02-09 






Kunden wissen häufig nicht, was sie genau wollen, bzw. können es 

nicht genau äußern 

Kunden sprechen ihre Sprache, die von Entwicklern nicht verstanden 

wird 

unterschiedliche Kundengruppen haben unterschiedliche 

Anforderungen, die sich mitunter widersprechen 

politische Entscheidungen können Anforderungen beeinflussen 

die Welt ändert sich, die Anforderungen an die Software auch; auch 

während der Entwicklung 

Die Anforderungsanalyse ist schwierig, so dass die Wahrscheinlichkeit, dass wir Fehler machen, recht hoch ist. 

Sommerville (2004) nennt hierfür eine Reihe von Gründen: 

• Die Kunden wissen häufig nicht genau, was sie genau wollen, beziehungsweise können es nicht genau äußern. 

– Sommerville (2004) 

• Kunden sind Experten in ihrem Anwendungsbereich, haben jedoch in der Regel wenig Kenntnisse in der Informatik. Bei 

den Informatikern verhält es sich meist umgekehrt. Es treffen also Menschen aufeinander, die erst zu einer gemeinsamen 

Sprache und einem gemeinsamen Verständnis finden müssen. 

• Es gibt meist nicht den Kunden oder Benutzer, sondern sehr viele mit recht unterschiedlichen Anforderungen, die sich 

nicht selten widersprechen. Bei der Anforderungsanalyse müssen also Konflikte aufgedeckt und Kompromisse 

geschlossen werden. 

• Die Anforderungen werden nicht selten durch politische Entscheidungen beeinflusst. Das aus organisatorischer und 

technischer Sicht bestmögliche Soll-Konzept kann dann immer noch aus rein politischen Gründen scheitern. 

Beispielsweise sieht der Abteilungsleiter durch eine Änderung im Arbeitsfluss dank softwaretechnischer Unterstützung 

plötzlich seinen Einfluss gefährdet und boykottiert die angestrebte Lösung. 

• Die Welt ist einem ständigen Wandel unterworfen. Weil sich die Welt ändert, ändern sich notwendigerweise auch die 

Anforderungen an die Software, die einen Arbeitsfluss dieser Welt automatisiert. Das geschieht sicherlich in der Zeit 

nach Auslieferung der Software in der so genannten Wartungsphase, d.h. während ihres Einsatzes, aber nicht selten auch 

schon während der Entwicklung. Mit der Anforderungsanalyse ist man also selten fertig. Man sollte deshalb idealerweise 

wahrscheinliche zukünftige Änderungen vorwegsehen und schon in der initialen Entwicklung berücksichtigen. 


Bewusstseinsebenen 

bewusstes Wissen (20-30%) 

Wissen, über das man sich im Klaren ist oder das in seiner vollen 

Bedeutung klar erkannt wird 

unbewusstes Wissen (≤40%) 

Wissen, das sich dem Bewusstsein im Moment nicht darbietet, aber 

dennoch handlungsbestimmend ist, und potenziell aufgerufen werden 

kann 

unterbewusstes Wissen 

unbekannte Wünsche, die erst von außen herangetragen werden 

müssen, um als Anforderungen erkannt zu werden 


2009-02-09 

2009-02-09 












kann 




Dass Benutzer oft nicht genau wissen, was sie wollen beziehungsweise es nicht sagen, liegt meist nicht an einem 

Mangel an Kenntnis, Vorstellungsvermögen oder Kooperationsbereitschaft, sondern an der Gestalt menschlichen 

Wissens. Menschliches Wissen lässt sich unterteilen in drei ungefähr gleich große Bereiche. 

Das bewusste Wissen ist solches Wissen, über das man sich im Klaren ist oder das in seiner vollen Bedeutung klar 

erkannt wird. Fragt man einen Radfahrer danach, wie man mit einem Fahrrad eine Kurve fährt, so wird er einem 

sicherlich antworten, dass man hierfür den Lenker einschlagen muss. Das bewusste Wissen ist durch direkte Fragen 

unmittelbar zugänglich. 

Das unbewusste Wissen ist solches Wissen, das sich dem Bewusstsein im Moment nicht darbietet, aber dennoch 

handlungsbestimmend ist und potenziell aufgerufen werden kann. Wird man denselben Radfahrer darauf 

aufmerksam machen, dass man beobachtet habe, dass er seinen Körper neigt, bevor er den Lenker zur Kurve 

einschlägt, wird er die maßgebende Rolle des Körpergewichtes bestätigen. An das unbewusste Wissen vermag man 

durch Beobachtung und Nachfragen zu kommen. 

Während sowohl das bewusste als auch das unbewusste Wissen wenigstens indirekt erschlossen werden kann, 

kommt man an die dritte Gestalt menschlichen Wissens kaum oder nur sehr schwer heran. Ein Drittel des 

menschlichen Wissens ist dem Wissenden selbst nämlich gar nicht bewusst. Das unterbewusste Wissen besteht aus 

dem uns nicht bekannten Wissen, das dennoch für unsere Handlungen maßgebend ist. Oft sind es Ängste, 

unbewusste Wünsche oder Triebe, die für uns handlungsbestimmend sind. Warum der Radfahrer in bestimmten 

Situationen es scheut, eine Kurve schneller zu nehmen, hat vielleicht damit zu tun, dass er sich einmal kräftig durch 

einen Sturz blamiert hat, als er einst versuchte, eine Kurve besonders schnittig zu nehmen, um seinen Freunden zu 

imponieren. Unbewusste Anforderungen müssen erst von außen an uns herangetragen werden, um als 

Anforderungen erkannt zu werden. 












kann 




Folgt für den Informatiker, der eine Anforderungsanalyse durchführt, nun daraus, dass er besser eine Ausbildung als 

Psychoanalytiker absolvieren sollte? Wenngleich das sicherlich helfen könnte, so ist es für unsere Zwecke meist 

ausreichend, sich über diese Formen des Wissens im Klaren zu sein und passende Techniken anzuwenden, um an 

möglichst viel Wissen und Anforderungen zu kommen. Mit reinen Fragetechniken wird man zum überwiegenden Teil 

allein das bewusste Wissen erschließen können. Mit Beobachtungen und Nachfragen kann man noch den Bereich 

des unbewussten Wissens erfassen. Bei der Einschätzung der Aussagen eines Benutzers sollte man sich aber auch 

Gedanken machen, warum er eine Antwort in einer bestimmten Weise geben könnte oder warum er sich auf eine 

bestimme Art und Weise verhält. Es könnten zum Beispiel Ängste vor der Umstellung durch die softwaretechnische 

Lösung sein, die einen Menschen unbewusst umtreiben – seien es berechtigte Ängste um den möglichen Verlust des 

Arbeitsplatzes oder einfach nur die allgemeine Angst, durch die Neuerungen überfordert zu werden.


Basisfaktoren 

Minimalanforderungen 

→ Mangel führt zu massiver 

Unzufriedenheit 

→ mehr als Zufriedenheit ist nicht möglich 

Leistungsfaktoren 

bewusst verlangte Sonderausstattung 

→ bei Erfüllung: Kundenzufriedenheit 

→ sonst: Unzufriedenheit 

Begeisternde Faktoren 

unbewusste Wünsche, 

nützliche/angenehme Überraschungen 

→ steigern Zufriedenheit überproportional 

2009-02-09 

Kano-Modell 

Kunde sehr zufrieden, 

begeistert Begeisternde Faktoren 

Erwartungen 

nicht erfüllt 


Erfüllungsgrad 

Basisfaktoren 

Kunde unzufrieden 

enttäuscht 





Basisfaktoren 













Eine gute Anforderungsanalyse ist der Grundstock für den Erfolg. Dazu muss es uns gelingen, den Kunden mit 

unserem Produkt zu begeistern, indem wir auf alle seine Anforderungen eingehen und diese später auch umsetzen. 

Der Zusammenhang zwischen dem Erfüllungsgrad der Anforderungen und der Begeisterung, die wir damit beim 

Kunden wecken können, wird durch das Kano-Modell (Kano 1984) beschrieben. Generell gilt offensichtlich, dass 

wir mit einem höheren Erfüllungsgrad der Anforderungen auch eine höhere Zufriedenheit erreichen können. Ob eine 

erfüllte Anforderung den Kunden zur Begeisterung treibt oder ob es für ihn vielmehr eine Selbstverständlichkeit 

darstellt, hängt jedoch ab von der Art der Anforderung. 

Die erste Kategorie von Anforderungen sind die Basisfaktoren der Software. Diese Anforderungen stellen 

Mindestanforderungen dar, die die Software erfüllen muss, damit sie eingesetzt werden kann, Werden sie nicht 

erfüllt, ist die Software unbrauchbar. Dies führt zu massiver Unzufriedenheit. Da es sich um Mindestanforderungen 

handelt, werden wir den Kunden selbst mit einer hundertprozentigen Erfüllung allenfalls zufrieden, aber nicht 

begeistern können. 

Die Gesamtheit der Leistungsfaktoren ist die bewusst verlangte Sonderausstattung. Werden diese Anforderungen 

erfüllt, können wir den Kunden mehr als nur zufrieden stellen. Werden sie nicht erfüllt, ist der Kunde enttäuscht – 

er hatte sich diese Leistungsfaktoren ja explizit gewünscht. Es droht dann Unzufriedenheit. 

Den Kunden begeistern können wir, indem wir ihn überraschen. Die begeisternde Faktoren erfüllen ihm unbewusste 

Wünsche oder stellen nützliche und angenehme Überraschungen dar. Mit diesen Faktoren können wir die 

Zufriedenheit überproportional steigern, aber bei Nichterfüllen niemals enttäuschen, weil der Kunde diese 

Anforderungen nicht explizit verlangt hat. 

Kano-Modell 



Erwartungen 




Basisfaktoren 


enttäuscht

2009-02-09 




Basisfaktoren 













Daraus folgt nun nicht, dass wir eigene Anforderungen hinzu erfinden sollten, von denen wir glauben, dass sie den 

Kunden vom Hocker reißen werden. Schließlich müssen wir die Anforderungen implementieren und wenn sie vom 

Kunden nicht bestellt sind, müssen wir dafür bezahlen. Wenn es uns aber gelingt, solche Anforderungen in der 

Anforderungsanalyse zu identifizieren und dem Kunden vorzuschlagen, so können sie zum Vertragsgegenstand 

werden, für die er gerne Geld ausgibt. Allerdings werden sie so dann schnell zu Leistungsfaktoren, die bei 

Nichterfüllung Unzufriedenheit hervor rufen. Aber zumindest kann es für den Kunden den Ausschlag geben, sich für 

unsere Dienste und nicht für die unserer Mitbewerber zu entscheiden. 


Wegweiser 

Erhebung der Anforderungen 

Kano-Modell 



Erwartungen 




Basisfaktoren 


enttäuscht 

Was sind die wesentlichen Schritte zur Erhebung der 

Anforderungen? 


2009-02-09 



Aktivitäten 

Wegweiser 

Wegweiser 

Erhebung der Anforderungen 

Was sind die wesentlichen Schritte zur Erhebung der 

Anforderungen? 

In diesem Abschnitt wenden wir uns den einzelnen Aktivitäten der Anforderungsanalyse zu. Dazu gehören die 

Ist-Analyse, die Soll-Analyse und das Festhalten der Anforderungen in Form einer Anforderungsspezifikation. Diese 

Aktivitäten haben eine natürlichen Abfolge, weil sie voneinander kausal abhängen. Allerdings werden sie in der 

Praxis meist wiederholt. 


Schritte der Anforderungsanalyse: Ist-Analyse 

Ist−Analyse 

Ist−Zustand 

Glossar 

Ziel: Verständnis der Welt, für die 

Softwarelösung angestrebt wird. 

Häufige Fehler: 

Entwickler sieht nicht, dass Kunde 

primär keine Veränderung, sondern 

Verbesserung anstrebt. 

Kunde beschreibt selten, was sich nicht 

ändern soll (weil es gut genug ist). 

Kunde = Endbenutzer; weiß nicht, was 

dieser braucht. 

Folgen von Mängeln: Eigentliches Problem 

wird ignoriert. 

Erforderlich: Beobachtungsgabe, 

Einfühlungsvermögen, 

Kommunikationsfähigkeit. 


2009-02-09 



Aktivitäten 



Die Aktivität Ist-Analyse zielt darauf ab, den Ausschnitt der Welt zu verstehen, für den eine softwaretechnische 

Lösung angestrebt wird. Das heißt, wir streben an, den Ist-Zustand genau zu verstehen und zu analysieren. Über 

die Beschreibung des Ist-Zustands hinaus, entsteht in dieser Phase ein Glossar (Begriffslexikon), in dem wir die 

Begriffe aus der Anwendungsdomäne definieren, die der Kunde verwendet. Das Begriffslexikon ist notwendig, um 

Unklarheiten und Missverständnisse auszuschließen. In der Regel sind Softwareentwickler mit den Begriffen der 

Anwendungsdomäne nicht vertraut genug oder haben eine etwas falsche Vorstellung. Besonders problematisch sind 

die Fälle, in denen wir meinen zu wissen, was vermeintlich gemeint ist, aber leider daneben liegen, ohne es zu 

merken. Dieses Glossar wird vom Kunden gelesen und verifiziert. Es wird über die Projektdauer gepflegt und 

angepasst. 

Ist−Analyse 

Ist−Zustand 

Glossar 

Ziel: Verständnis der Welt, für die 

Softwarelösung angestrebt wird. 


Entwickler sieht nicht, dass Kunde 

primär keine Veränderung, sondern 

Verbesserung anstrebt. 

Kunde beschreibt selten, was sich nicht 

ändern soll (weil es gut genug ist). 

Kunde = Endbenutzer; weiß nicht, was 

dieser braucht. 

Folgen von Mängeln: Eigentliches Problem 

wird ignoriert. 

Erforderlich: Beobachtungsgabe, 

Einfühlungsvermögen, 


Ein häufiger Fehler bei der Ist-Analyse ist es, dass wir uns nicht bewusst werden, dass der Kunde primär keine 

Veränderung, sondern eine Verbesserung anstrebt. Das bedeutet, dass der Kunde mit vielen Dingen so wie sie sind 

bereits zufrieden ist und die auch weiterhin so bleiben sollen. Der Kunde beschreibt aber selten, was sich nicht 

ändern soll, weil es gut genug ist. Er konzentriert sich vielmehr darauf, was sich ändern soll. Nichtsdestotrotz 

müssen wir auch die Anforderungen kennen, die übernommen werden sollen. Wenn es darum geht, ein existierendes 

Softwaresystem abzulösen, bietet sich uns eine große Chance vom existierenden System zu lernen. Viele 

Informatiker machen jedoch den Fehler, das existierende Systeme allerhöchstens oberflächlich zu untersuchen. 

Dabei könnten wir den Kunden gezielt danach fragen, was wir vom existierenden System übernehmen 

beziehungsweise verbessern sollten. 

Erfolgt die Ist-Analyse mangelhaft, droht die Gefahr, dass wir das eigentliche Problem ignorieren. Für eine 

erfolgreiche Durchführung der Ist-Analyse benötigen wir Beobachtungsgabe, Einfühlungsvermögen und 



Schritte der Anforderungsanalyse: Soll-Analyse 

Ist−Analyse 


Ist−Zustand 

Glossar 

Lastenheft 

Ziel: Aufdeckung und Verbesserung 

bisheriger Schwächen durch Softwarelösung. 

Antizipation von Änderungen. 


Entwickler gleiten in technische Details 

ab. 

Kunde hat keine klare Vorstellung bzw. 

kann sie nicht vermitteln. 

Folgen von Mängeln: falsche Lösung wird 

spezifiziert. 

Erforderlich: Analytische Fähigkeiten 

kombiniert mit Wissen über Machbarkeit von 

Softwarelösungen. 


2009-02-09 



Aktivitäten 



Ist−Analyse 

Ist−Zustand 

Glossar 

Ziel: Aufdeckung und Verbesserung 

bisheriger Schwächen durch Softwarelösung. 

Antizipation von 


Lastenheft 

Änderungen. 


Entwickler gleiten in technische Details 

ab. 

Kunde hat keine klare Vorstellung bzw. 

kann sie nicht vermitteln. 

Folgen von Mängeln: falsche Lösung wird 

spezifiziert. 

Erforderlich: Analytische Fähigkeiten 

kombiniert mit Wissen über Machbarkeit von 

Softwarelösungen. 

Auf Basis der Ergebnisse der Ist-Analyse identifiziert die Soll-Analyse die bisherigen Schwächen und erarbeitet 

Verbesserungsmaßnahmen. Dabei interessieren uns nicht nur die unmittelbar anstehenden Anforderungen sondern 

auch jene, die in absehbarer Zukunft relevant werden können. Wahrscheinliche zusätzliche Anforderungen an das 

System, die in der Zukunft eintreffen werden, sollen beschrieben werden, damit die Softwarelösung so strukturiert 

werden kann, dass diese Änderungen später einfach zu realisieren sind. 

Das Ergebnis der Soll-Analyse ist das Lastenheft, in dem wir aus Sicht des Kunden beschreiben, was die Probleme 

der bisherigen Situation sind und was die neue Software verbessern soll. 

Häufig wird in der Soll-Analyse der Fehler gemacht, dass wir in technische Details der Lösung abgleiten, obwohl es 

doch zunächst um grobe Konzepte zur Verbesserung geht. Wir stoßen auch auf das oben bereits angeführte 

Problem, dass der Kunde nicht notwendigerweise eine klare Vorstellung von der möglichen softwaretechnischen 

Verbesserung hat beziehungsweise sie nicht vermitteln kann. 

Mängel in der Soll-Analyse führen dazu, dass eine falsche Lösung spezifiziert wird. Am Ende entsteht ein 

Softwaresystem, das nicht die relevanten Probleme beseitigt und damit unnütz ist. Um eine gute Soll-Analyse 

machen zu können, brauchen wir neben analytischen Fähigkeiten bei der Problemsuche auch softwaretechnisches 

Wissen, um abzuschätzen ob und mit welchem Aufwand, anvisierte softwaretechnische Lösungen machbar sind. 


Schritte der Anforderungsanalyse: Spezifikation 

Ist−Analyse 

Abnahme 

durch Kunden 


Spezifikation 


Ist−Zustand 

Glossar 

Lastenheft 


spezifikation 

abgenommene 


spezifikation 

(Pflichtenheft) 

Ziel: Anforderungen genau beschreiben. 


Anforderungen bleiben vage 

Implementierungsdetails statt 

Anforderungen 

Folgen von Mängeln: 

Vertragsstreitigkeiten am Projektende. 

Erforderlich: Kommunikationsfähigkeit. 


2009-02-09 

2009-02-09 



Aktivitäten 



Ist−Zustand 



Ist−Analyse 

Glossar Anforderungen bleiben vage 


Lastenheft Anforderungen 


Spezifikation 




spezifikation Vertragsstreitigkeiten am Projektende. 


Abnahme 

durch Kunden 

abgenommene 


spezifikation 


Die Ist-Analyse untersucht die Anwendungsdomäne, für die eine softwaretechnische Lösung angestrebt wird. Diese 

Analyse ist rein deskriptiv. Die Soll-Analyse untersucht die Schwächen des Ist-Zustands und formuliert daraus 

Anforderungen an eine softwaretechnische Lösung, die diese Schwächen ausgleichen sollen. Die Soll-Analyse muss 

Prioritäten setzen (nicht alle Anforderungen sind gleich wichtig) und mögliche Konflikte auflösen (Anforderungen 

können sich widersprechen; z.B. Performanz versus Sicherheit). Bei der Soll-Analyse müssen eventuell auch Folgen 

von softwaretechnischen Lösungen abgeschätzt werden. Diese Abschätzung könnte dazu führen, eine andere 

softwaretechnische Lösung zu finden beziehungsweise – im Extremfall – eine softwaretechnische Lösung ganz 

auszuschließen. 

Mit Lösung ist hier nicht die Implementierung gemeint, sondern lediglich der Anforderungskatalog an die 

Implementierung. Es geht hier noch nicht darum, sich zu überlegen, wie die Anforderungen implementiert werden. 

Das Lastenheft beschreibt die Wünsche des Kunden aus dessen Sicht. Es ist häufig noch unscharf oder unstimmig. 

Erst die Anforderungsspezifikation (auch Pflichtenheft) beschreibt genau, was zu implementieren ist. 

Obwohl die Anforderungsspezifikation nur beschreiben soll, was implementiert und nicht wie implementiert werden 

soll, sind Überlegungen zu der generellen Machbarkeit notwendig. Eine Anforderungsspezifikation muss auch 

realisierbar sein. Dennoch sollten diese Überlegungen lediglich dazu führen, möglicherweise die Anforderungen 

abzuändern. Mögliche Wege, die Anforderungen zu implementieren, gehören in ein Entwurfsdokument und nicht in 

die Anforderungsspezifikation. 

Die Anforderungsspezifikation stellt den Vertrag zwischen Kunde und Entwickler dar und muss entsprechend genau 

geprüft werden. Meist geschieht dies durch ein Review mit dem Kunden. 



Aktivitäten 



Ist−Zustand 



Ist−Analyse 

Glossar Anforderungen bleiben vage 


Lastenheft Anforderungen 


Spezifikation 




spezifikation Vertragsstreitigkeiten am Projektende. 


Abnahme 

durch Kunden 

abgenommene 


spezifikation 


Typische Fehler bei der Anforderungsspezifikation sind vage Anforderungen (z.B. dass die Software 

benutzerfreundlich sein soll) und dass sie Implementierungsdetails beschreibt statt Anforderungen aus Kundensicht. 

Weil die Anforderungsspezikation den Vertragsgegenstand festlegt, führen Mängel nicht selten zu 

Vertragsstreitigkeiten am Ende des Projekts. Wenn die Anforderungen nicht genau definiert wurden, ist eine 

gerichtliche Auseinandersetzung sehr mühselig. In jedem Falle ist ein solcher Streit für alle Parteien zum eigenen 

Schaden. Der Kunde hat nicht bekommen, was er wollte; wir bekommen möglicherweise unser Geld nicht. Ein 

enttäuschter Kunde schadet uns, denn Enttäuschung spricht sich schnell herum. 

Wir werden uns also große Mühen bei der Anforderungsspezifikation geben. In den folgenden Abschnitten werden 

wir hierzu verschiedene Techniken kennen lernen, die uns bei richtiger Ausführung vor Schaden bewahren können. 

Es sei auch hier nochmal darauf hingewiesen, dass die genannten Schritte der Ist- und Soll-Analyse sowie das 

Festhalten der Anforderungen hochgradig iterativ sind und keineswegs so sequentiell, wie durch den Datenfluss im 

Diagramm suggeriert. Das muss bei der Planung beachtet werden.


Wegweiser 

Ist-Analyse 

Was ist das Ziel und der Gegenstand der 

Ist-Analyse? 



Soziotechnisches System 

Definition 

Soziotechnisches System: organisierte Menge von Menschen und 

Technologien, die in einer bestimmten Weise strukturiert sind, um eine 

Aufgabe zu erfüllen. 

Umgebung 

Eingabe 

Aufgaben 

Menschen 

Technisches 

Soziales 

Technologien 

Rolle/Struktur 

Ausgabe 

– Emery, Thorsrud & Trist 1964 



Ist-Zustand: Was? 

Verständnis von: 

Struktur 

Aufgaben 

Kommunikation 

Dokumenten 

Daten 

Schwachstellen 

. . . aus allen 

relevanten 

Blickwinkeln. 

2009-02-09 




Ist-Analyse 




Struktur 

Aufgaben 

Kommunikation 

Dokumenten 

Daten 


. . . aus allen 

relevanten 

Blickwinkeln. 

In diesem Abschnitt lernen wir Analysetechniken für die Ist-Analyse kennen. Zunächst untersuchen wir, was wir bei 

der Ist-Analyse überhaupt analysieren sollen. 

Durch die Ist-Analyse streben wir ein Verständnis folgender Aspekte des Ist-Zustands aus allen relevanten 

Blickwinkeln an: 

• Struktur: das organisatorische Gefüge des Systems, für das die Softwarelösung angestrebt wird. 

• Aufgaben: der Umfang und die Art der anfallenden Aufgaben (Operationen) und Besonderheiten im Ablauf 

• Kommunikation: die Vorrichtungen und Gelegenheiten zur Kommunikation und ihr Ablauf 

• Dokumenten: schriftliche oder elektronische Dokumente, die verwendet und produziert werden 

• Daten: Umfang und Art der verarbeiteten Daten in den Dokumenten und über sie hinaus 

• Schwachstellen: die bestehenden Mängel, Unvollständigkeiten und Redundanzen des Ist-Zustands 

Wie werden diese Aspekte nun vertiefen und benutzen als illustrierendes Beispiel eine Verkaufssituation in einem 

Fahrradladen, für die wir eine softwaretechnische Unterstützung entwickeln sollen.




Struktur 

2009-02-09 

Aufgaben 

Kommunikation 

Dokumenten 

Daten 


Bestandteile 

organisatorisches Gefüge des Systems, für das 

Softwarelösung angestrebt wird 

relevante Akteure 

Systemgrenzen 

Art und Umfang der Verbindungen innerhalb 

und nach außen 

Großhändler 

Ladenbesitzer 

Verkäufer 1 

Verkäufer 2 

Kunde 1 

Kunde 2 




Ist-Analyse 




Struktur 

Aufgaben 

Kommunikation 

Dokumenten 

Daten 


Bei der Analyse der Struktur identifizieren wir zunächst alle relevanten Akteure (Benutzer und andere 

Softwaresysteme, die miteinander interagieren. Im Fahrradladen sind das Kunden und Verkäufer sowie der 

Ladenbesitzer und seine Lieferanten. 

Bestandteile 

organisatorisches Gefüge des Systems, für das 

Softwarelösung angestrebt wird 

relevante Akteure 

Systemgrenzen 

Art und Umfang der Verbindungen innerhalb 

und nach außen 

Großhändler Verkäufer 2 

Dann legen wir die Systemgrenzen fest. Mit System ist hier weder das Softwaresystem gemeint, das wir 

implementieren sollen (wir kennen ja die Anforderungen dafür noch gar nicht) noch etwa ein möglicherweise bereits 

existierendes Softwaresystem, das wir ablösen sollen. Vielmehr meinen wir damit den Ausschnitt der Welt, für den 

wir die softwaretechnische Verbesserung anstreben sollen. Diesen Ausschnitt fassen wir als ein System miteinander 

agierender Akteure auf. 

Wenn wir die Systemgrenzen festlegen, bestimmen wir also, was alles zu dem Ausschnitt der Welt gehört, der für 

uns relevant ist. Bsp.: Nehmen wir an, wir sind beauftragt, das Verkaufsgespräch zwischen Käufer und Verkäufer zu 

optimieren, dann gehören diese beiden Personengruppen zu unserem untersuchten System. Ihr Zusammenspiel 

sollen wir optimieren. Ladenbesitzer und Lieferanten hingegen sind außerhalb unseres Systems, aber dennoch 

relevant für unsere Aufgabenstellung, weil der Verkäufer den Ladenbesitzer bei bestimmten Entscheidungen zu Rate 

ziehen und Lieferanten zu Lieferzeiten befragen muss. 

Haben wir die Systemgrenzen gezogen, untersuchen wir die Art und den Umfang der Verbindungen innerhalb des 

Systems und nach außen. Wir bestimmen, wer innerhalb des System miteinander und welche unserer inneren 

Akteure mit welchen externen Akteuren interagiert. Die Interaktion zwischen externen Akteuren können wir in der 

Regel vernachlässigen. 

Das Ergebnis lässt sich als Graph repräsentieren, dessen Knoten die Akteure und dessen Kanten die Interaktionen 

darstellen. 

Ladenbesitzer 

Verkäufer 1 Kunde 1 

Kunde 2


Ist-Zustand: relevante Akteure 

Grundsatz: Kenne deinen Benutzer! 

Aber: Der Benutzer bzw. die Benutzerin ist eine Illusion. Es sind 

individuelle Menschen, um die es geht. 

Andererseits: Wir können nicht jeden betrachten und müssen 

zusammenfassen. 

2009-02-09 




Ist-Analyse 



Grundsatz: Kenne deinen Benutzer! 

Aber: Der Benutzer bzw. die Benutzerin ist eine Illusion. Es sind 

individuelle Menschen, um die es geht. 

Andererseits: Wir können nicht jeden betrachten und müssen 

zusammenfassen. 

Nachdem wir alle Akteure bestimmt haben, untersuchen wir die menschlichen Akteure weiter im Detail. Dies sind 

die potentiellen Benutzer unseres zukünftigen Softwaresystems. Zum Teil erscheinen sie uns bisher noch recht 

abstrakt, etwa der Verkäufer und der Käufer. Diese Rollen definieren bestimmte Klassen von Benutzern mit 

unterschiedlichen Aufgaben und Zielen in unserem Systemgefüge. Diese Rollen abstrahieren aber von den 

Eigenschaften konkreter Benutzer. So können wir sicherlich ganz unterschiedliche Käufer in unserem Fahrradladen 

ausmachen, die sich in Erfahrungen, Vorlieben, Wünschen, Alter, Geschlecht und Finanzkraft unterscheiden. Alle 

wollen ein Fahrrad oder ein Fahrradbestandteil kaufen, aber ihre Auswahl und ihre Interaktion mit dem Käufer wird 

wesentlich durch ihre persönlichen Eigenschaften bestimmt. Es reicht also nicht aus, nur funktionale Rollen zu 

identifizieren. Da das Softwaresystem von konkreten Menschen benutzt werden wird, müssen wir deren Eigenheiten 

genau kennen, damit wir ein nützliches Softwaresystem für sie entwickeln können. 

Andererseits können wir auch nicht jedes mögliche Individium einzeln betrachten, da die Anzahl der Benutzer meist 

sehr hoch ist und uns nicht alle Benutzer bekannt sind. Aus ökonomischen Gründen müssen wir also mehrere 

Individuen mit ähnlichen Eigenschaften zu Klassen zusammenfassen.



Persona 

(in archetypischer Psychologie) die Maske oder Erscheinung, die man der 

Welt präsentiert. 

(in der Softwareergonomie) erzählerische Beschreibung charakterischer 

Eigenschaften und Verhalten eines Benutzers oder Kunden, die spezifische 

Details nennt, statt Verallgemeinerungen. 

2009-02-09 




Ist-Analyse 



Persona 

(in archetypischer Psychologie) die Maske oder Erscheinung, die man der 

Welt präsentiert. 

(in der Softwareergonomie) erzählerische Beschreibung charakterischer 

Eigenschaften und Verhalten eines Benutzers oder Kunden, die spezifische 

Details nennt, statt Verallgemeinerungen. 

Es ist die Aufgabe des Analysten, eine angemessene Menge von Benutzerklassen zu finden, die die richtige Balance 

zwischen abstrakten Rollen und individuellen Benutzern wahrt. Zur Beschreibung dieser Benutzerklassen kann man 

sich der so genannten Personas bedienen. Die Persona ist ursprünglich eine im griechischen Theater von den 

Schauspielern verwendete Maske, die die Rolle typisierte und als Schallverstärker benutzt wurde. In der 

archetypischen Psychologie ist es die Maske oder Erscheinung, die man der Welt präsentiert. 

In der Anforderungsanalyse der Softwaretechnik steht eine Persona für eine Benutzerklasse. Sie beschreibt deren 

gemeinsamen Eigenschaften, gibt ihnen aber ein konkretes Bild. Sie ist in der Softwareergonomie eine erzählerische 

Beschreibung charakterischer Eigenschaften und Verhalten eines Benutzers oder Kunden, die spezifische Details 

nennt, statt nur Verallgemeinerungen. 

Neben der Konkretisierung statt Verallgemeinerung geben uns die Personas etwas Spielerisches im 

Entwicklungsprozess, das unsere Kreativität stimulieren kann. Wir können große Poster unserer Personas aufhängen 

und sie betrachten, während wir an der Anforderungsspezfikation schreiben. Wir leben damit die Idee, für und mit 

dem Benutzer zu entwickeln.


2009-02-09 

Persona-Poster: 

Bild (fiktiv) 

Name (fiktiv), 

Beruf, Motto 

Rolle, Ziele, 

Aufgaben, Ideen, 

Wünsche, 

Vorlieben, 

persönliche 

Details 




Ist-Analyse 

Die ursprüngliche Idee der Personas für die Anforderungsaanalyse stammt von Cooper. Zur Beschreibung einer 

Persona gehören ein fiktives Bild und ein fiktiver Name sowie weitere persönliche Eigenschaften, wie den Beruf oder 

ein charakterisierendes Motto. Statt von der abstrakten Benutzerklasse Verkäufer sprechen wir also von Herrn 

Schmidt, dem Verkäufer. Dann werden die gemeinsamen Eigenschaften der Benutzer, die sich hinter der Persona 

verbergen, aufgeführt. Dazu gehören die Rolle, die Herr Schmidt ausfüllt, die Ziele, die Herr Schmidt verfolgt, seine 

Ideen, Wünsche, Vorlieben und weitere persönliche Details, soweit sie von Relevanz für die Analyse sind. 

Quelle für das Bild: 

http://www.research.microsoft.com/research/coet/Grudin/Personas/Pruitt-Grudin.doc. Der Artikel 

erläutert auch wesentliche Ideen. 

Persona-Poster: 

Bild (fiktiv) 

Name (fiktiv), 

Beruf, Motto 

Rolle, Ziele, 

Aufgaben, Ideen, 

Wünsche, 

Vorlieben, 

persönliche 

Details


Bedeutung von Personas 

2009-02-09 

archetypische Benutzerbeschreibungen 

typisch für Zielgruppen 

decken deren Anforderungen, Bedürfnisse und Ziele ab 

stehen im Designprozess stellvertretend für die realen Benutzer (statt 

der relativ anonymen und pauschalen Größe “Benutzer”) 

können bei Design und beim Usability-Test der Benutzerinteraktion 

verwendet werden 

können beim Handbuchschreiben und -prüfen sowie Akzeptanztest 


– Astrid Beck, FHT Esslingen 




Ist-Analyse 



archetypische Benutzerbeschreibungen 

typisch für Zielgruppen 

decken deren Anforderungen, Bedürfnisse und Ziele ab 

stehen im Designprozess stellvertretend für die realen Benutzer (statt 

der relativ anonymen und pauschalen Größe “Benutzer”) 

können bei Design und beim Usability-Test der Benutzerinteraktion 


können beim Handbuchschreiben und -prüfen sowie Akzeptanztest 


Astrid Beck, von der Fachhochschule für Technik in Esslingen, fasst die Bedeutung von Personas in der 

Softwaretechnik wie folgt zusammen. Personas sind archetypische Benutzerbeschreibungen und beschreiben 

typische Zielgruppen durch deren gemeinsame Eigenschaften. Die Gesamtheit der Anforderungen aller Personas 

deckt die Anforderungen, Bedürfnisse und Ziele aller Benutzer ab. Wie viele Personas man benötigt, hängt stark 

vom Projekt ab. In der Regel wird man mit zwischen 5 und 15 verschiedene Personas auskommen. 

Die Personas stehen im Designprozess stellvertretend für die realen Benutzer und bilden eine kreative und konkrete 

Alternative zu der relativ anonymen und pauschalen Größe ” Benutzer“. Die Anforderungsspezifikation muss die 

Anforderungen für jede Persona beinhalten. Sie können aber nicht nur während der Anforderungsanalyse der 

funktionalen Anforderungen an die Software verwendet werden. Die Personas helfen uns auch beim Design der 

Mensch-Maschine-Kommunikation und beim Usability-Test der Benutzerinteraktion. Hier muss die 

Benutzerinteraktion so gestaltet sein, dass alle Personas ihr Anwendungsproblem mit dem Softwaresystem effektiv 

und effizient lösen können. Aus den Personas lassen sich für den Usability-Test, der dies überprüfen soll, 

unmittelbar entsprechende Test-Benutzer ableiten, die das Profil der Personas erfüllen. Schließlich können die 

Personas beim Handbuchschreiben und -prüfen sowie beim Akzeptanztest verwendet werden. Auch hier helfen sie, 

sicher zu stellen, dass die Anforderungen zutreffend und vollständig sind, indem das Handbuch und System aus 

allen relevanten Blickwinkeln der Benutzersicht untersucht wird. 

– Astrid Beck, FHT Esslingen




Struktur 

Aufgaben 

Kommunikation 

Dokumenten 

Daten 


Bestandteile 

Umfang und Art der anfallenden Aufgaben 

(Operationen) und Besonderheiten im Ablauf. 

Was wird gemacht? 

→ Kundenberatung 

Wer oder was führt Operation aus? 

→ Kunde + Verkäufer 

Wann und wie häufig? 

→ werktags: 50 Mal/Tag; samstags: 80 

Mal/Tag 





Struktur 

Aufgaben 

Kommunikation 

Dokumenten 

Daten 


Bestandteile (Forts.) 

Zu welchem Zweck? 

→ Kauf eines Artikels 

Nach welchen Regeln wirken Operationen 

zusammen? 

→ Beratung vor Kauf-Operation, aber optional 

Was benutzt/produziert Operation? 

→ Zeit und Wissen des Verkäufers/Auswahl 

des Käufers 


2009-02-09 

2009-02-09 



Ist-Analyse 




Struktur 

Aufgaben 

Kommunikation 

Dokumenten 

Daten 



Nachdem wir uns durch die Personas einen Überblick verschafft haben, welche Benutzerklassen zu beachten sind, 

untersuchen wir als nächstes die Aufgaben der einzelnen Akteure, die im untersuchten System vorkommen. Die 

Aufgaben können wir als Operationen der Akteure auffassen. Hier interessiert uns, was eine Operation macht, wer 

sie ausführt, wann und wie häufig die Operation ausgeführt wird, zu welchem Zweck sie durchgeführt wird, welche 

Regeln der Ausführung der Operation selbst und welche dem Zusammenwirken der Operationen zu Grunde liegen 

sowie was eine Operation benutzt und produziert. 



Ist-Analyse 




Struktur 

Aufgaben 

Kommunikation 

Dokumenten 

Daten 





zusammen? 




des Käufers 


Betrachten wir diese Fragen zu den Aufgaben an unserem Beispiel des Fahrradladens. Wir untersuchen hier die 

besondere Aufgabe des Einkaufes. Dies ist eine Operation unter vielen in einem Fahrradladen. Die Reparatur oder 

der Umtausch sind weitere Beispiele für Operationen in einem Fahrradladen. 




zusammen? 




des Käufers 

Bsp.: Der Einkauf folgt im Wesentlichen dem folgenden Ablauf: 

1. Der Kunde betritt den Laden und äußert seinen Wunsch gegenüber dem Verkäufer. 

2. Der Verkäufer fragt nach den Details und berät den Kunden. 

3. Der Kunde wählt aus dem Angebot aus, kauft und bezahlt, wenn er etwas Passendes gefunden hat. 

4. Der Verkäufer übergibt den Artikel und den Kassenzettel, sobald der Betrag durch den Kunden beglichen wurde. 

• Wer oder was führt Operation aus? 

→ Die Ausführenden sind Kunde und Verkäufer in den oben beschriebenen Rollen. 

• Wann und wie häufig? 

→ Werktags findet diese Operation ca. 50 Mal am Tag statt; samstags ca. 80 Mal/Tag. Abends findet sie tendenziell 

häufiger statt als morgens. 

• Zu welchem Zweck? 

→ Der Käufer benötigt einen Fahrradartikel. Der Verkäufer möchte Umsatz erzielen. 

• Nach welchen Regeln wirken Operationen zusammen? 

→ Wenn der Kunde nichts Passendes findet oder der Verkäufer ihn unzureichend berät, geht der Kunde ohne zu kaufen. 

Wenn der Kunde nicht komplett bezahlen kann, schreibt der Verkäufer an, wenn er den Kunden gut genug kennt. 

Ansonsten übergibt ihm der Verkäufer den Artikel nicht. Ein Umtausch ist nur möglich, wenn ein Artikel vorher gekauft 

wurde. Käufer und Verkäufer verhalten sich kooperativ, das heißt, der Verkäufer berät nach bestem Wissen und 

Gewissen und der Kunde liefert ihm hierfür notwendige Hintergrundinformationen zu seinen bereits gekauften Artikeln 

und seinen Wünschen. 

• Was benutzt/produziert Operation? 

→ Die Operation überführt den Artikel aus dem Besitz des Ladens in den Besitz des Käufers. Sie überführt den Geldbetrag, 

der zu entrichten ist, vom Kunden in die Kasse des Verkäufers.




2009-02-09 

Struktur 

Aufgaben 

Kommunikation 

Dokumenten 

Daten 


Bestandteile 

Welche Vorrichtungen und Gelegenheiten zur 

Kommunikation gibt es (im Rahmen welcher 

Aufgaben)? 

→ Laden, Telefon 

Wie läuft Kommunikation ab? 

→ initiiert vom Kunden 




Ist-Analyse 




Struktur 

Aufgaben 

Kommunikation 

Dokumenten 

Daten 


Bestandteile 

Welche Vorrichtungen und Gelegenheiten zur 

Kommunikation gibt es (im Rahmen welcher 

Aufgaben)? 

→ Laden, Telefon 

Wie läuft Kommunikation ab? 

→ initiiert vom Kunden 

Wenn wir die Kommunikation untersuchen, interessieren wir uns für die Vorrichtungen für die Kommunikation, die 

Gelegenheit, zu der die Kommunikation stattfindet, sowie den Ablauf der Kommunikation. 

Bsp.: Beim Verkaufsgespräch, wie oben dargestellt, verwenden die Akteure im Laden schlicht die menschliche 

Stimme, wenn das Gespräch im Laden stattfindet. Alternativ kann der Kunde sich aber auch über das Telefon vom 

Verkäufer beraten lassen und erst später den Laden betreten, um den passenden Artikel zu besorgen. 

Die Kommunikation findet während der Ladenöffnungszeiten statt und wird vom Kunden initiiert. Wenn der 

Verkäufer frei ist, spricht er jedoch auch Kunden an, wenn er den Eindruck hat, dass sie seine Hilfe benötigen.




2009-02-09 

Struktur 

Aufgaben 

Kommunikation 

Dokumenten 

Daten 


klara: Kundin 

volker : Verkäufer 

gib−artikel() 

gib−detail() 

Detail 

wähle−aus() 

Auswahl 

gib−geld() 

Geld 

Artikel 




Ist-Analyse 




Struktur 

Aufgaben 

Kommunikation 

Dokumenten 

Daten 


Den Ablauf der Kommunikation kann man verbal beschreiben oder zu etwas formaleren Notationen greifen. Hierfür 

eignen sich insbesondere die UML-Sequenzdiagramme, die für solche Zwecke entworfen wurden. 

Wichtig ist bei allen gewählten Notationen, dass sie einerseits präzise genug sind – was für stark formalisierte 

Notationen spricht – und dass sie auch vom Kunden verstanden werden – was meist gegen stark formalisierte 

Notationen spricht. Sequenzdiagramme sind jedoch ein recht einfach zu erläuterndes Mittel, das nach kurzen 

Erläuterungen auch Nichtinformatikern verständlich sein kann. Für zustandsbasierte Kommunikation eignen sich 

auch Zustandsdiagramme. Ebenso kann man mit Aktivitätsdiagrammen komplexere Abläufe gut beschreiben. 

Bsp.: Das Diagramm hier beschreibt die Kommunikation als eine Abfolge von Nachrichten, die sich die Akteure 

gegenseitig zuschicken. Einige davon, wie z.B. gib-detail(), erhalten eine Antwort. Es bescheibt dieselbe Abfolge wie 

der natürlichsprachliche Text weiter oben. Das Sequenzdiagramm muss aber hierfür noch ergänzt werden um die 

Bedeutung der Nachrichten. 

klara: Kundin 

volker : Verkäufer 

gib−artikel() 

gib−detail() 

Detail 

wähle−aus() 

Auswahl 

gib−geld() 

Geld 

Artikel




Struktur 

Aufgaben 

Kommunikation 

Dokumenten 

Daten 


Bestandteile 

Dokumente, die verwendet und produziert werden 

Bezeichnung 

→ Kassenzettel 

Inhalt 

→ gekaufte Ware, Preis, MWST, Datum, 

Verkäufer 

Grad der Formalisierung, Aufbau 

→ genügt Gesetz 

Verteiler 

→ Kunde und Laden 





Struktur 

Aufgaben 

Kommunikation 

Dokumenten 

Daten 


Bestandteile (Fortsetzung) 

Archivierung 

→ als Papier beim Kunden, elektronisch in der 

Ladenkasse 

von wem produziert/verwendet? 

→ produziert von Kasse/Verkäufer 

→ verwendet von Kunde beim Umtausch, 

Steuererklärung 


2009-02-09 



Ist-Analyse 




Struktur 

Aufgaben 

Kommunikation 

Dokumenten 

Daten 



Eine wichtige Informationsquelle bei der Ist-Analyse liefern existierende Dokumente, die verwendet und produziert 

werden. Meist müssen sie bei einer softwaretechnischen Lösung im Rechner nachgebildet werden. Dokumente 

können eher formalisiert sein, wie z.B. der Kassenbons im Fahrradladen, oder eher informell sein, wie z.B. der 

Notizzettel des Käufers, auf dem er sich aufgeschrieben hat, was er einkaufen möchte und zu welchem Fahrrad in 

seinem Besitz der neue Artikel passen soll. 

Archivierung 

→ als Papier beim Kunden, elektronisch in der 

Ladenkasse 

von wem produziert/verwendet? 

→ produziert von Kasse/Verkäufer 

→ verwendet von Kunde beim Umtausch, 

Steuererklärung 

Bei diesen Dokumenten interessieren uns die Bezeichnung, der Inhalt, der Grad der Formalisierung, der Aufbau, der 

Verteiler (d.h. wer das Dokument erhält), die Archivierung des Dokuments sowie die Produzenten und 

Konsumenten des Dokuments. 

Bsp.: Im Fahrradladen gibt es beispielsweise den Kassenzettel. Sein Inhalt ist die gekaufte Warte, der Preis, die 

anrechenbare Mehrwertsteuer, das Kaufdatum sowie der Verkäufer. Der Kassenzettel muss dem Gesetz genügen 

und ist darum recht formalisiert. Den Kassenzettel erhält der Kunde, ein Durchschlag bleibt in der Kasse des 

Ladens. Sowohl der Kunde als auch der Laden archivieren den Kassenzettel – der Kunde um gegebenenfalls seine 

Garantieansprüche durchzusetzen, der Laden für das Finanzamt. Produziert wird der Kassenzettel von der Kasse 

des Ladens durch den Verkäufer und verwendet wird er vom Kunden im Falle eines Umtausches beziehungsweise 

vom Ladenbesitzer für die Steuererklärung. 




Struktur 

Aufgaben 

Kommunikation 

Dokumenten 

Daten 


Bestandteile 

Umfang und Art der verarbeiteten Daten 

Volumen und Wachstum 

→ 41 Flaschenhalter 

Wertebereiche 

→ Radius Halterung, Abstand Schrauben, 

versch. Farben etc. 

Datenträger 

→ Katalog in Papierform, Online-Katalog in 

HTML 

Ordnungsstrukturen 

→ Name, Hersteller, Typ 

Verarbeitungshäufigkeit 

→ wird alle drei Tage einmal verkauft 





2009-02-09 

Struktur 

Aufgaben 

Kommunikation 

Dokumenten 

Daten 



Art und Erfordernisse der Datensicherung 

→ Speicherung verkaufter Waren und des 

Inventars 

Abhängigkeiten zwischen den Daten 

→ passt nur an bestimmte Rahmen 




Ist-Analyse 




Struktur 

Aufgaben 

Kommunikation 

Dokumenten 

Daten 





Inventars 



Wir untersuchen die Dokumente, um die Daten zu ermitteln, die für die Ist-Analyse relevant sind. Oft sind es 

verschiedene Daten, die in den Dokumenten aufgeführt und verknüpft werden. Allerdings sind nicht alle relevanten 

Daten auf Dokumenten wiedergegeben. Im nächsten Schritt untersuchen wir weitere Daten, die möglicherweise nur 

mündlich ausgetauscht werden. 

Um die Daten präzise und vollständig zu modellieren, wird hierzu oft ein Datenmodell aufgestellt. Das 

Datenmodell beschreibt die wesentlichen Daten, ihre Eigenschaften, ihren Umfang und ihre Beziehungen. Zur 

Repräsentation eignen sich für eine Reihe der relevanten Aspekte beispielsweise UML-Klassendiagramme. Das 

Datenmodell beschreibt das Volumen und zukünftig erwartete Wachstum der Daten. Dies wird häufig als das 

Mengengerüst bezeichnet. Es ist unerlässlich für die Abschätzung des Speicherbedarfs und der Anforderungen an 

die Performanz der Algorithmen. Mit der Betrachtung des zukünftigen Wachstums stellen wir sicher, dass unser 

System skaliert und auch in einigen Jahren noch die notwendige Performanz zur Verfügung stellen wird. Die Daten 

haben einen Typ, für den wir den Wertebereich angeben. Sie werden in vielen Fällen dauerhaft gespeichert auf 

Datenträgern, die aber nicht notwendigerweise unmittelbar elektronisch verarbeitbar sind, z.B. weil sie von Hand 

auf Papier geschrieben werden. Viele Daten können sortiert werden, d.h. verfügen über ein oder mehrere 

Ordnungskriterien. Unsere Programme müssen sie meist nach diesen Ordnungskriterien sortieren können. Die 

Häufigkeit ihrer Verarbeitung ist für uns wichtig, weil wir damit die Zugriffe entsprechend organisieren müssen. 

Häufig verarbeitete Daten müssen schnell verfügbar sein. Schließlich interessieren uns die Art und Erfordernisse der 

Datensicherung sowie die Abhängigkeiten zwischen den Daten. Häufige solche Abhängigkeiten sind die 

Teil-Von-Beziehung in Form der Aggregation und Komposition. Andere Beziehungen werden in 

UML-Klassendiagrammen mit allgemeinen Assoziationen modelliert.

2009-02-09 



Ist-Analyse 




Struktur 

Aufgaben 

Kommunikation 

Dokumenten 

Daten 





Inventars 



Bsp.: In unserem Fahrradladen gibt es beispielsweise 41 Flaschenhalter in fünf verschiedenen Typen von drei 

verschiedenen Herstellern. Ein Flaschenhalter wird beschrieben durch die Attribute Radius der Halterung 

gemessen in Zentimetern, der Abstand der Schrauben gemessen in Zentimetern, die Farben in rot, grün, gelb, blau 

sowie der Preis im Bereich von 5 bis 25 Euro. Die Datenträger zu den Flaschenhaltern sind die Herstellerkataloge in 

Papierform als auch als Online-Kataloge in HTML. Name, Hersteller, Typ und Preis bilden die Ordnungsstrukturen. 

Von den Flaschenhaltern wird im Durchschnitt alle drei Tage einer verkauft. Dies bildet die Verarbeitungshäufigkeit. 

Die verkauften und im Lager befindlichen Flaschenhalter werden in einer Datenbank des Ladenbesitzers gespeichert. 

Die Flaschenhalter passen nur an bestimmte Rahmen; dies hängt vom Schraubenabstand und dem Radius ab. Eine 

weitere ” weiche“ Abhängigkeit ist die Farbe des Rahmens, zu der der Flaschenhalter passen soll. 




Struktur 

Aufgaben 

Kommunikation 

Dokumenten 

Daten 


Bestandteile 

Untersuchung auf: 

Mängel 

Unvollständigkeiten 

Redundanzen 


2009-02-09 



Ist-Analyse 




Struktur 

Aufgaben 

Kommunikation 

Dokumenten 

Daten 


Bestandteile 

Untersuchung auf: 

Mängel 

Unvollständigkeiten 

Redundanzen 

Nachdem wir die oben genannten relevanten Aspekte des Ist-Zustands erfasst haben, analysieren wir sie auf 

Schwachstellen und Probleme. Dazu gehören Mängel, Unvollständigkeiten oder Redundanzen. Auf die 

Schwachstellen werden wir sowohl durch eigene Analyse und Beobachtung der erhobenen Aspekte als auch durch 

Befragung und Beobachtung der Akteure selbst aufmerksam. Zu entsprechenden Techniken der Befragung und 

Beobachtung kommen wir weiter unten. 




Struktur 

Aufgaben 

Kommunikation 

Dokumenten 

Daten 


Beispielschwachstellen 

Abhängigkeiten und wechselseitige Ausschlüsse 

von Teilen sind nirgendwo dokumentiert 

Verkäufer kennt nicht alle Einschränkungen 

Kunde kennt seine Konfiguration nicht 

Verkäufer kennt Sortiment nicht vollständig 

verschiedene überlappende Teilekataloge 

Inventarlisten sind obsolet 


2009-02-09 



Ist-Analyse 




Struktur 

Aufgaben 

Kommunikation 

Dokumenten 

Daten 


Bsp.: In unserem Fahrradladen können wir beispielsweise durch unsere Analyse der erhobenen Aspekte und durch 

Beobachtung im Laden folgende Schwachstellen identifizieren: 


Wegweiser 

Beispielschwachstellen 

Abhängigkeiten und wechselseitige Ausschlüsse 

von Teilen sind nirgendwo dokumentiert 

Verkäufer kennt nicht alle Einschränkungen 

Kunde kennt seine Konfiguration nicht 

Verkäufer kennt Sortiment nicht vollständig 

verschiedene überlappende Teilekataloge 

Inventarlisten sind obsolet 

• Die Abhängigkeiten und wechselseitige Ausschlüsse der Bestandteile eines Fahrrads sind nirgendwo dokumentiert. Ein 

Verkäufer kann sie nicht nachschlagen und muss sie alle kennen, um einen Kunden zu beraten. 

• Nicht alle Verkäufer kennen aber alle Einschränkungen. Dies führt dazu, dass weniger erfahrene Verkäufer Rücksprache 

halten müssen mit erfahreneren Verkäufern oder gar Lieferanten und dass Kunden verärgert ihre falschen Artikel 

umtauschen müssen, wenn sie falsch beraten wurden. 

• Die Verkäufer können die Kunden nicht ausreichend beraten, weil der Kunde die bereits gekauften Fahrradbestandteile 

nicht genau kennt, zu denen der neu zu kaufende Artikel passen soll. Der Kunde muss in solchen Fällen unverrichteter 

Dinge den Laden wieder verlassen und die Information besorgen. 

• Verkäufer kennen das Sortiment nicht vollständig und wissen nicht genau, was im Laden selbst oder im Lager noch 

verfügbar ist. 

• Die Fahrradartikel sind in verschiedenen teilweise überlappenden Teilekatalogen beschrieben. Dies führt zu unnötigen 

Redundanzen. 

• Die Inventarlisten sind obsolet. Der Ladenbesitzer weiß nicht genau, welche Ware noch vorrätig, verkauft oder gar 

gestohlen ist. 

Ist-Analyse 

Welchen Techniken können wir in der Ist-Analyse 

nutzen? 



Ist-Zustand: Wie? 


2009-02-09 

Auswertung vorhandener Dokumente 

Befragung 

schriftlicher Fragebogen 

Interview 

Beobachtung 

anekdotisch ↔ systematisch 

teilnehmend ↔ nicht-teilnehmend 

offen ↔ verdeckt 

selbst ↔ fremd 

Feld ↔ Labor 




Ist-Analyse 





Befragung 


Interview 

Beobachtung 






Wir wissen nun, was wir erheben sollen, aber leider noch nicht, wie wir das tun können. In diesem Abschnitt lernen 

wir hierfür verschiedene Erhebungstechniken kennen. Die Auswertung der vorhandenen Dokumente ist eine erste 

offensichtliche Technik. Darüber hinaus können wir jedoch auch die Akteure fragen oder beobachten. 

Um Akteure zu befragen, können wir sie selbst interviewen oder ihnen aber einen schriftlichen Fragebogen 

zuschicken. Beim Interview kann man auch mit einem vorher gründlich ausgearbeiteten Fragebogen arbeiten oder 

aber nur eine grobe Skizze der Fragen haben, um dann die Fragen an die Situation spontan anzupassen. Ganz zu 

Anfang, wenn man sich ein Gebiet erschließen möchte, ist man oft gar nicht in der Lage, präzise Fragen 

auszuarbeiten. Das Interview hat gegenüber der Befragung durch einen schriftlichen Fragebogen, den der Befragte 

ohne unser Beisein ausfüllt, den Vorteil, dass wir auch Gestik und Mimik des Befragten sehen, seine Gegenfragen 

direkt klären können und individuell auf die Situation reagieren können. Allerdings kann die Anwesenheit eines 

Fragenden die Antworten des Befragten beeinflussen. Zum einen lässt sich die Anonymität hier nicht sicher stellen, 

zum anderen fallen die Antworten oft auch abhängig davon aus, inwieweit der Fragende dem Befragten 

sympathisch ist. Außerdem ist das individuelle Interview erheblich zeitaufwändiger und teurer. Bei den schriftlichen 

Fragebögen verhält es sich gerade umgekehrt. Aus diesem Grunde werden wir meistens sowohl Interviews als auch 

schriftliche Fragebögen anwenden, weil sie sich bestens ergänzen. Wir werden meist zu Anfang eine kleinere Zahl 

von Interviews führen. Später können wir auf Basis dieser Interviews präzise Fragebögen aufstellen, um eine größere 

Datenbasis zu schaffen.

2009-02-09 



Ist-Analyse 





Befragung 


Interview 

Beobachtung 






Statt zu fragen können wir auch beobachten. Beobachtungen haben aber viele Facetten, aus denen wir die 

geeignete Beobachtungsart zusammen stellen müssen. Hier müssen wir zunächst entscheiden, ob wir systematisch 

oder eher anekdotisch vorgehen wollen. Wenn wir z.B. ganz einfach einmal den Fahrradladen betreten und dort eine 

Stunde verbringen, liefert das eher anekdotisches Wissen. Bei einem systematischen Vorgehen würden wir vorher 

ermitteln, wie sich die Kundenbesuche über die Ladenöffnungszeiten verteilen. Dann würden wir zu qualitativ 

unterschiedlichen Zeiten den Laden betreten, z.B. Montag morgens, wenn nicht viel los ist, Mittwoch abends, wenn 

mehr los ist, und Samstag vormittags, wenn der Laden meist voll ist. Außerdem müssen wir entscheiden, ob wir bei 

der Beobachtung teilnehmen. Wir könnten uns also einerseits nur einfach in den Laden stellen und beobachten, 

oder aber könnten wir selbst Kunde spielen und uns beraten lassen. Die Beobachtung kann offen oder verdeckt 

erfolgen. Erfolgt sie offen, kann das den Beobachtungsgegenstand beeinflussen. Ein Verkäufer wird sich in einer 

solchen Situation zum Beispiel eher freundlich verhalten, als wenn er sich unbeobachtet fühlt. Andererseits werfen 

verdeckte Beobachtungen ethische Fragen auf und sind möglicherweise schlicht verboten. Dann müssen wir uns 

entscheiden, ob wir selbst beobachten oder die Beobachtung Dritten überlassen. Wenn wir selbst beobachten, 

haben wir ein unmittelbareres Bild. Andererseits sind wir möglicherweise ungeübt, und ausgebildete und erfahrene 

dritte Beobachter sehen mehr als wir. Schließlich müssen wir uns zwischen einer Feld- oder Laborbeobachtung 

entscheiden. Im Labor können wir viel stärker beeinflussende Faktoren kontrollieren, um so spezielle Situationen 

und den Einfluss der Faktoren durch deren Variation genauer zu studieren. So könnten wir z.B. eine stressige 

Ladensituation im Labor nachbilden, indem wir sehr viele Menschen unzufriedene Kunden schauspielern lassen. Das 

natürlichere Bild ergibt sich aber durch die Feldbeobachtung. Hier lassen sich aber keine Situationen nachstellen. 

Auch hier gilt wieder, dass man Für und Wider anhand der konkreten Ausgangslage und des Ziels abwägen muss. 

Eine Feldbeobachtung ist jedoch immer vernünftig. Im Labor kann man dann bestimmte Situationen nachstellen 

und näher untersuchen. 


Befragung 

Fragen zu Fragen: 

Wird die Frage verstanden? 

Bezugsrahmen der Befragten? 

Informationsstand der Befragten? 

Art der Frage? 

Anordnung der Fragen? 

Erhebungssituation (Interviewereinfluss)? 

Gründe für die Antwort der Befragten? 


2009-02-09 

2009-02-09 



Ist-Analyse 

Befragung 

Befragung 









Die Antwort auf eine Frage hängt nicht nur vom Inhalt der Frage selbst, sondern auch vom Kontext und von der 

Art und Weise ab, wie man die Frage stellt. Aus diesem Grunde sollte man sich bei der Gestaltung eines 

Fragebogens die Fragen und die Art der Frage sorgfältig überlegen und sich über den Einfluss des Kontextes im 

Klaren werden. Die Sozialwissenschaften haben hierzu umfangreiche Lehrbücher entwickelt. 

Zu unseren Fragen müssen wir uns selbst folgende Fragen stellen: 

• Wird die Frage überhaupt richtig verstanden? Benutzen wir Begriffe, zu denen der Befragte die gleichen Vorstellungen 

hat wie der Fragende? Bsp.: Wenn wir Softwaretechniker von Server sprechen und damit einen Prozess meinen, dann 

versteht der Befragte darunter möglicherweise den Rechner, auf dem seine Applikation laufen, wenn er etwas 

Hintergrund in Computer-Hardware hat, oder gar lediglich Diener, wenn er Computer-Laie ist. 

• Was ist der Bezugsrahmen der Befragten? Was ist seine Rolle, was kann er wissen, was sind seine Ziele sowohl 

beruflicher als auch persönlicher Art? Bsp.: Es hat keinen Sinn den Besitzer unseres Fahrradladens zum üblichen Ablauf 

von Verkaufsgesprächen zu fragen, wenn er selbst seit langer Zeit das Verkaufen nicht mehr selbst praktiziert hat und 

lediglich Managementaufgaben wahrnimmt. 

• Informationsstand der Befragten? Was kann der Befragte überhaupt wissen? Fragen wir ihn zu Dingen, die er nicht 

wissen kann, wird er keine Antwort abgeben können oder schlimmer noch, eine Antwort erfinden. 

• Art der Frage? Ist eine offene, geschlossene oder hybride Frage angebracht (siehe unten)? 

• Anordnung der Fragen? Die Reihenfolge der Fragen kann das Ergebnis beeinflussen. Über jede Frage denkt der Befragte 

nach. Die Assoziationen können einen Kontext herstellen, der die Antwort auf die nächste Frage beeinflusst. Bsp.: Um 

ein krasses Beispiel zu nennen: Wenn wir den Verkäufer in unserem Fahrradladen als erstes fragen würden, ob er sich 

durch den geplanten Einsatz unseres Softwaresystems unnütz fühlen würde, wird das vermutlich Einfluss auf den Verlauf 

der weiteren Befragung nehmen. 



Ist-Analyse 

Befragung 

Befragung 









• Was ist der mögliche Einfluss der Situation, in der der Fragebogen erhoben wird? Was ist insbesondere der Einfluss des 

Interviewers, falls die Fragen in einem Interview gestellt werden? Bsp.: Fragt man Menschen, die eben aus einem 

Kinofilm zu einer Naturkatastrophe – wie z.B. einer Flutwelle – kommen, zum Thema Naturschutz, sind andere 

Antworten zu erwarten, wie wenn wir die selben Menschen bei einem Transatlantikflug zu ihrem Urlaubsort fragen. 

Auch der Fragende hat einen möglichen Einfluss auf die Antworten. Ob uns jemand sympathisch oder unsympathisch ist, 

beeinflusst, wie kooperativ wir in einem Interview sind. Fatal wäre es, wenn der Befragte vor dem Fragenden etwas zu 

befürchten hätte. Bsp.: So wäre der Ladenbesitzer eher ungeeignet, Fragen zum Thema Auslastung und Schwächen der 

Verkäufer zu stellen, wenn sie zu befürchten haben, dass ihnen aus ehrlichen Antworten negative Konsequenzen 

erwachsen könnten. 

• Was sind die möglichen Gründe für die Antwort der Befragten? Der Befragte könnte uns einen Gefallen tun wollen oder 

will uns sabotieren. Er könnte bewusst oder unbewusst falsche Antworten liefern, weil er hinter den Fragen ein 

bestimmtes Ziel vermutet, mit dem er nicht einverstanden ist.


Fragetypen: Geschlossene Fragen 

Geschlossene Fragen: 

2009-02-09 

Welche Qualität hat die GUI? Bitte ankreuzen. 

sehr gut 

gut 

schlecht 

weiß nicht 

Antwortalternativen vorgegeben 

auch Mehrfachantworten 




Ist-Analyse 



Geschlossene Fragen: 

Welche Qualität hat die GUI? Bitte ankreuzen. 

sehr gut 

gut 

schlecht 

weiß nicht 

Antwortalternativen vorgegeben 

auch Mehrfachantworten 

Fragen können in drei unterschiedlichen Formen verfasst sein: geschlossene, offene oder hybride Fragen. Sie 

unterscheiden sich durch die Form der Antworten, die auf sie möglich sind. 

Bei geschlossenen Fragen sind alternative Antworten bereits vorgegeben, aus denen der Befragte eine oder 

gegebenenfalls mehrere auswählen kann. Häufig findet man solche Fragen für Aspekte, die anhand einer Skala 

eingeschätzt werden sollen, also zum Beispiel die Frage, ob einem die GUI sehr gut, gut oder nicht gefällt. 

Durch die Vorgabe möglicher Antworten schafft man eine Normierung und kann die Antworten leicht automatisiert 

statistisch auswerten. 

Diesen Fragentyp kann man gut einsetzen, wenn man die möglichen Antworten gut vorwegsehen kann. Wenn man 

also bereits eine bestimmte Hypothese hat, kann man sie durch solche Fragen leicht überprüfen. In Bereichen, in 

denen man jedoch die Antworten nur schlecht abschätzen kann, besteht die Gefahr, dass die Antwort, die jemand 

eigentlich geben möchte, nicht dabei ist. Hier sind solche Fragetypen eher ungeeignet. In jedem Falle sollte es bei 

der Antwort immer möglich sein, dass der Befragte die Frage nicht beantworten kann oder will, um erzwungene 

Falschantworten zu vermeiden.


Fragetypen: Offene Fragen 

Offene Fragen: 

2009-02-09 

Wie sollte die GUI verbessert werden? 

Antworten in eigenen Worten, im eigenen Referenzsystem 

erfordert Ausdrucksfähigkeit der Befragten 

starker Einfluss des Fragenden, wenn präsent (durch Aufschreiben, 

Weglassen) 

hoher Auswertungsaufwand 




Ist-Analyse 



Offene Fragen: 

Wie sollte die GUI verbessert werden? 

Antworten in eigenen Worten, im eigenen Referenzsystem 

erfordert Ausdrucksfähigkeit der Befragten 

starker Einfluss des Fragenden, wenn präsent (durch Aufschreiben, 

Weglassen) 

hoher Auswertungsaufwand 

Offene Fragen sind solche, bei denen keine Antwort vorgegeben wird. Der Befragte beantwortet die Frage mit 

seinen eigenen Worten. Dazu kann er seine eigene Terminologie benutzen. Dies erfordert vom Befragten, dass er 

sich selbst ausdrücken kann. Da jede Antwort möglich ist, kann der Befragte in seiner Formulierung stark durch den 

anwesenden Fragenden beeinflusst werden. Dies gilt umso mehr, wenn nicht der Befragte die Antworten 

aufschreibt, sondern der Fragende, wie das meist üblich ist. Dadurch werden die Aussagen vom Fragenden oft 

gefiltert und aufbereitet, statt nur wörtlich wiedergegeben. Das Mindeste, was man dann tun sollte, ist es, dem 

Befragten das Protokoll seiner Antworten nochmals zur Kontrolle vorzulegen, um sicher zu stellen, dass man seine 

Aussagen korrekt wieder gegeben hat. 

Da die Antworten nicht vorgegeben sind, muss ein Mensch sie durchlesen, verstehen und einordnen. Damit ist die 

Auswertung erheblich aufwändiger als bei geschlossenen Fragen. Dem hohen Auswerteaufwand steht als Vorteil 

gegenüber, dass man die Antworten nicht schon beim Entwurf des Fragebogens vorwegsehen muss, wie das bei 

geschlossenen Fragen der Falle ist. Man hat also die Chance, Neues zu erfahren. Aus diesem Grund wendet man 

diesen Fragetyp an, wenn man noch keine rechte Hypothese zu den möglichen Antworten hat.


Fragetypen: Hybride Fragen 

Hybride Fragen: 

2009-02-09 

Was stört Sie an der GUI? 

lange Reaktionszeit 

mangelnde Selbsterklärungsfähigkeit 

fehlendes ” Undo“ 

umständliche Dialogführung 

 

Kombination von geschlossenen und offenen Fragen 




Ist-Analyse 



Hybride Fragen: 

Was stört Sie an der GUI? 

lange Reaktionszeit 

mangelnde Selbsterklärungsfähigkeit 

fehlendes ” Undo“ 

umständliche Dialogführung 

 

Kombination von geschlossenen und offenen Fragen 

Hybride Antworten kombinieren geschlossene und offene Fragen, indem eine Menge alternativer Antworten 

vorgegeben wird, es aber dennoch möglich ist, durch Freitextfelder eigene Antworten zu formulieren. Dies ist in 

vielen Fällen ein guter Kompromiss, der leichte Auswertbarkeit und die Möglichkeit, unvorhergesehene Antworten 

zu liefern, bestmöglich vereint, solange die vorgegebenen Antworten möglichst viele echte Antworten abdecken.


Wann welche Erhebungsform? 

weniger strukturiertes Interview 

2009-02-09 

unstrukturiertes 

Untersuchungsgebiet 

offene Gesprächsführung und 

größere Antwortspielräume 

persönlicher Kontakt möglich 

Ortsbegehung möglich 

stark strukturierter Fragebogen 

vorstrukturiertes 


gute Kenntnisse des 

Untersuchungsgebiets 

Operationalisierung der 

Hypothesen möglich 




Ist-Analyse 



weniger strukturiertes Interview 

unstrukturiertes 


offene Gesprächsführung und 

größere Antwortspielräume 

persönlicher Kontakt möglich 

Ortsbegehung möglich 

Welche Form der Erhebung, ob stark oder weniger strukturiertes Vorgehen, nun angemessen ist, hängt im 

Wesentlichen davon ab, wie gut wir unser Untersuchungsgebiet bereits durchdrungen haben. 

In einer frühen Phase, in der wir uns noch wenig auskennen und mögliche Antworten nicht vorweg sehen können, 

werden wir eher ein weniger strukturiertes Interview durchführen. Das Gespräch kann offen geführt werden, und der 

Befragte hat einen größeren Spielraum bei Antworten. Der Fragende kann spontaner auf die Situation reagieren. 

Der persönliche Kontakt und die Ortsbegehung werden uns weitere Einblicke gewähren. 

Ist unser Untersuchungsgebiet bereits gut vorstrukturiert, dann kommt auch ein strukturierteres Vorgehen in Frage. 

Da wir bereits über gute Kenntnisse des Untersuchungsgebiets verfügen, sind wir in der Lage, operationale 

Hypothesen aufzustellen, das heißt, Hypothesen, die wir objektiv durch Fragebögen überprüfen können. 

stark strukturierter Fragebogen 

vorstrukturiertes 


gute Kenntnisse des 

Untersuchungsgebiets 

Operationalisierung der 

Hypothesen möglich


Frageformulierung 

2009-02-09 

einfache Worte 

kurz und konkret 

keine doppelten Negationen 

nur auf einen Sachverhalt bezogen 

nicht hypothetisch 

neutral, nicht suggestiv 

Befragten nicht überfordern 

balanciert (negative und positive Antwortmöglichkeiten) 

immer eine ” weiß-nicht“-Kategorie bieten 




Ist-Analyse 



einfache Worte 

kurz und konkret 

keine doppelten Negationen 

nur auf einen Sachverhalt bezogen 

nicht hypothetisch 

neutral, nicht suggestiv 

Befragten nicht überfordern 

balanciert (negative und positive Antwortmöglichkeiten) 

immer eine ” weiß-nicht“-Kategorie bieten 

Auch über die Formulierung der Fragen muss man sich vorher sorgfältig Gedanken machen, da sie einen Einfluss auf 

die Antwort hat. Man wähle möglichst einfache, klare Worte, so dass die Frage sicher verstanden werden kann. Die 

Fragen sollten kurz und konkret sein. Lange Fragen beinhalten viele Aspekte, auf die man kaum eine klare, 

abgeschlossene Antwort geben kann. Auf abstrakte Fragen fällt die Antwort schwer. Doppelt negierte Fragen gilt es 

zu vermeiden, um den Befragten nicht zu verwirren. Gleichermaßen sollte man auf hypothetische Fragen mit vielen 

Konjunktiven verzichten. Ansonsten kann eine negative Antwort unterschiedliche Ursachen haben: die, die sich auf 

den eigentlichen Frageinhalt beziehen, oder jene, die die Prämissen in Frage stellen. Die Frage sollte neutral und 

nicht suggestiv gestellt werden, ansonsten legt man dem Befragten die Antwort bereits in den Mund. Man sollte 

eine gleiche Anzahl negativer und positiver Antwortmöglichkeiten vorsehen. Eine Disbalance von entweder 

negativen oder positiven Fragen wirkt suggestiv. Außerdem gibt es eine menschliche Tendenz, eher positiv zu 

antworten. Auch bei geschlossenen Fragen sollte es stets möglich sein, dass der Befragte aussagen kann, dass er auf 

eine Frage nicht antworten kann oder will, um erzwungene Falschaussagen zu vermeiden.


Beobachtung 

Prinzipien der Ethnographie (teilnehmende Beobachtung in der 

Feldforschung): 

2009-02-09 

Natürliche Umgebung 

→ Aktivitäten in Alltagsumgebung untersuchen 

Ganzheitlichkeit 

→ Einzelverhalten im Kontext untersuchen 

Beschreiben, nicht bewerten 

→ Ist-Verhalten, nicht Soll-Verhalten 

Sicht der Handelnden einnehmen 

→ Verhalten beschreiben in Begriffen, die für den Handelnden relevant 

und bedeutungsvoll sind 




Ist-Analyse 

Beobachtung 

Beobachtung 

Prinzipien der Ethnographie (teilnehmende Beobachtung in der 

Feldforschung): 

Natürliche Umgebung 

→ Aktivitäten in Alltagsumgebung untersuchen 

Ganzheitlichkeit 

→ Einzelverhalten im Kontext untersuchen 

Beschreiben, nicht bewerten 

→ Ist-Verhalten, nicht Soll-Verhalten 

Sicht der Handelnden einnehmen 

→ Verhalten beschreiben in Begriffen, die für den Handelnden relevant 

und bedeutungsvoll sind 

In der Befragung adressieren wir hauptsächlich das bewusste Wissen. Wir haben weiter oben schon gelernt, dass 

das nur rund ein Drittel des menschlichen Wissens ausmacht. Durch Beobachtung können wir uns noch weiteres 

Wissen erschließen. 

In der Sozialwissenschaft hat sich die Ethnographie als Technik etabliert. Die Ethnographie ist eine teilnehmende 

Beobachtung. Es hat offensichtlich keinen Sinn, das Leben von Urvölker zu ergründen, indem man sie ihrer Heimat 

entreißt und sie im Labor untersucht. Eigenschaften von Sozialgemeinschaften sind abhängig vom Kontext und 

müssen deshalb in diesem Kontext untersucht werden. 

Die Ethnographie folgt bei der Beobachtung einer Reihe von Prinzipien: 

• Die soziale Gemeinschaft wird in ihrer natürlichen Umgebung beobachtet. Auf diese Weise werden ihre Aktivitäten in der 

Alltagsumgebung untersucht. 

• Das Einzelverhalten wird im Kontext untersucht. Verhaltensweisen sind meist sehr komplex und lassen sich nur schwer 

isolieren und kontrollieren, wie das für Laborversuche versucht wird. 

• Im Vordergrund steht das neutrale Beschreiben und nicht die Bewertung. Wertung sozialen Handelns orientiert sich an 

moralischen Maßstäben, die jedoch kontextabhängig sind. Setzen wir uns die eigene moralische Brille auf, werden wir 

meist schlechtsichtiger und übersehen wichtige Details. Wir sind bei der Ist-Analyse am Ist- und nicht am Soll-Verhalten 

interessiert. 

• Wir versuchen, die Sicht der Handelnden einzunehmen, d.h. wir beschreiben das Verhalten in Begriffen, die für den 

Handelnden relevant und bedeutungsvoll sind. 

Die Einhaltung dieser Prinzipien sichert uns einen besseren Einblick.


Interview im Kontext 

2009-02-09 

ist eine Form der ethnographischen Untersuchung 

nach dem Meister-Lehrling-Modell 

Lernen durch Vormachen und Beobachten sowie Fragen und Klären 

geprägt durch 

Bescheidenheit 

Neugier 

Aufmerksamkeit 

konkrete (statt abstrakter) Fragen 




Ist-Analyse 



ist eine Form der ethnographischen Untersuchung 

nach dem Meister-Lehrling-Modell 

Lernen durch Vormachen und Beobachten sowie Fragen und Klären 

geprägt durch 

Bescheidenheit 

Neugier 

Aufmerksamkeit 

konkrete (statt abstrakter) Fragen 

Eine spezielle Form der ethnographischen Untersuchung ist das Interview im Kontext. Es orientiert sich am 

Meister-Lehrling-Modell. Lernen findet hier in der Beobachtung des Meisters, im aktiven Nachfragen und Zeigen 

sowie im Mitmachen statt. Statt in einem Frontalunterricht im Hörsaal zu theoretisieren, nimmt der Meister seinen 

Lehrling mit auf die Baustelle. Der Meister arbeitet vor und der Lehrling lernt aus der Beobachtung. Der Lehrling 

fragt nach, wenn ihm etwas nicht klar ist, und er versucht sich auch selbst. Das Meister-Lehrling-Modell ist geprägt 

durch Bescheidenheit, Neugier, Aufmerksamkeit und konkrete (statt abstrakter) Fragen des Lehrlings im 

unmittelbaren Kontext.


Beispiel eines Ablaufes 

2009-02-09 

1 Einleitung (15 min) 

Vorstellung, Ziele, Dank 

Zustimmung zu Aufzeichnung, Vertraulichkeit 

Arbeit, nicht Person wird betrachtet! 

Meinungen zu technischer Unterstützung? 

Überblick gewinnen 

2 Übergang (1 min) 

Regeln, Rollen, Beziehung 

ich frage, Sie dürfen abwehren 

3 Erhebung im Kontext (2 Std.) 

Beobachtung und Nachfragen 

Notizen machen, mitlaufen, sich unsichtbar machen 

Pausen nach Wunsch 

4 Zusammenfassung (15 min) 

was die Beschäftigte tut, ihre Rolle 

was wichtig ist 

Ergänzungen, Korrekturen? 




Ist-Analyse 



1 Einleitung (15 min) 

Vorstellung, Ziele, Dank 

Zustimmung zu Aufzeichnung, Vertraulichkeit 

Arbeit, nicht Person wird betrachtet! 

Meinungen zu technischer Unterstützung? 

Überblick gewinnen 

2 Übergang (1 min) 

Regeln, Rollen, Beziehung 

ich frage, Sie dürfen abwehren 

3 Erhebung im Kontext (2 Std.) 

Beobachtung und Nachfragen 

Notizen machen, mitlaufen, sich unsichtbar machen 

Pausen nach Wunsch 

4 Zusammenfassung (15 min) 

was die Beschäftigte tut, ihre Rolle 

was wichtig ist 

Ergänzungen, Korrekturen? 

Ein Interview im Kontext dauert in der Regel zwei Stunden plus direkte Vor- und Nachbearbeitung. Es könnte wie 

folgt ablaufen: 

1. In einer Einleitung (15 min) stellt sich der Fragende kurz vor und erläutert das Ziel der Befragung. Er vergisst nicht, 

sich ausdrücklich für das Interview zu bedanken. Er sichert absolute Vertraulichkeit zu und vergewissert sich über das 

Einverständnis des Befragten. Er weist darauf hin, dass die Arbeit betrachtet werden soll und nicht die Person. Man 

kann technische Hilfen für das Interview mitbringen, wie z.B. ein Audio- oder Videoaufnahmegerät. Wenn das der Fall 

ist, holt man sich spätestens jetzt noch das Einverständnis des Beobachteten ein. 

2. Im Übergang zur Erhebung im Kontext (1 min) bespricht man die Regeln, Rollen und die Beziehung zwischen 

Beobachter und Beobachtetem. Die Rolle des Beobachters ist es, zu beobachten und Fragen zu stellen. Die Rolle des 

Beobachteten ist es, sich möglichst wie gewöhnlich zu verhalten. Eine Grundregel lautet, dass der Beobachtete Fragen 

auch abwehren darf. 

3. Der Hauptteil ist die Erhebung im Kontext, die zwei Stunden möglichst nicht überschreiten sollte, weil spätestens dann 

die Konzentration auf beiden Seiten nachgelassen hat. In der Erhebung beobachtet man und fragt nach. Man macht 

sich Notizen, läuft mit, macht sich aber möglichst unsichtbar, um das beobachtete Geschehen so wenig wie möglich zu 

beeinflussen. Pausen können nach Wunsch gemacht werden. 

4. In der Zusammenfassung (15 min), erläutert man, was man beobachtet hat und lässt den Beobachteten korrigieren und 

ergänzen. Der Beobachtete erläutert sein Tun und seine Rolle und weist auf Wichtiges hin.


Wegweiser 

2009-02-09 

Soll-Analyse 

Wie können wir dem Benutzer frühzeitig ein 

konkretes Bild vermitteln, wie wir das Problem zu 

lösen gedenken? 





Wegweiser 

Wegweiser 

Soll-Analyse 

Wie können wir dem Benutzer frühzeitig ein 

konkretes Bild vermitteln, wie wir das Problem zu 

lösen gedenken? 

Durch Analyse von Dokumenten, Beobachtungen und Fragen haben wir den Ist-Zustand erfasst. Die Analyse des 

Erfassten deckt die Schwachstellen auf, die wir mit einer softwaretechnischen Lösung beseitigen sollen. Der nächste 

Schritt ist nun auszuarbeiten, was die softwaretechnische Lösung dazu leisten muss. Dieser Aufgabe widmet sich 

die Soll-Analyse. Die Soll-Analyse muss die Anforderungen an die zu implementierende Software aufstellen. Dazu 

gehört es auch, diese Anforderungen hinsichtlich ihrer Machbarkeit und Folgen einzuschätzen. In diesem Abschnitt 

lernen wir eine Technik kennen, mit der wir sowohl Anforderungen überprüfen als auch technische Machbarkeit 

untersuchen können. 

Beobachtungen setzen den beobachteten Gegenstand voraus. Somit zielen Beobachtungen klar auf den Ist-Zustand 

ab. Unsere softwaretechnische Lösung existiert aber noch nicht. Fragen hingegen sind sowohl hilfreiche Mittel für 

die Ist-Analyse als auch für die Soll-Analyse. Wir können z.B. die Benutzer fragen, wie etwas sein soll. Auf welche 

Probleme wir dabei allerdings stoßen, haben wir schon ganz zu Anfang bei der Einführung zur Anforderungsanalyse 

besprochen. Die Benutzer können oft auf Problem hinweisen, sie tun sich oft aber schwerer, eine geeignete Lösung 

zu ersinnen. Insbesondere fehlt ihnen dazu meist die realistische Einschätzung zur technischen Machbarkeit, für die 

sie einen softwaretechnischen Hintergrund bräuchten. Zudem richten sich Fragen an das bewusste Wissen und wir 

können damit nur eingeschränkt relevante Aspekte erfassen. 

Wenn aber Beobachtungen ausscheiden und Fragen nicht hinreichend sind, wie können wir dann vorgehen? Es gibt 

das geflügelte Wort des Benutzers: I know it when I see it. Ich weiß, was ich will, sobald ich es sehe. Dieses Prinzip 

können wir umsetzen: Wir führen dem Benutzer unsere Lösung vor, zu der er dann Stellung nehmen kann. 

Natürlich können wir uns es nicht leisten, gleich das gesamte System zu implementieren, denn der Schaden wäre 

groß, wenn diese Lösung dann doch nicht das war, was der Benutzer haben möchte. Statt dessen implementieren 

wir einen so genannten Prototypen.


Prototyping 

Zielsetzung: 

Idee: 

Anforderungen anhand eines Beispiels erheben und überprüfen 

technische Möglichkeiten überprüfen und demonstrieren 

frühzeitig mögliche Lösungsansätze präsentieren 

rasche und billige Entwicklung eines prototypischen Systems als 

Diskussionsgrundlage 

Typen unterscheiden sich in . . . 

2009-02-09 

Lebensdauer: Wegwerfprototyp, evolutionärer Prototyp 

Zweck: technische Machbarkeit, Demonstration der Funktionalität 

oder Interaktion 





Prototyping 

Prototyping 

Zielsetzung: 

Anforderungen anhand eines Beispiels erheben und überprüfen 

technische Möglichkeiten überprüfen und demonstrieren 

frühzeitig mögliche Lösungsansätze präsentieren 

Idee: 

rasche und billige Entwicklung eines prototypischen Systems als 

Diskussionsgrundlage 

Typen unterscheiden sich in . . . 

Lebensdauer: Wegwerfprototyp, evolutionärer Prototyp 

Zweck: technische Machbarkeit, Demonstration der Funktionalität 

oder Interaktion 

Prototypen sind Zwischenprodukte in der Entwicklung, die dem Endprodukt in bestimmten relevanten Aspekten 

bereits stark ähneln sollen, die aber noch nicht vollständig sind. Eine andere Sichtweise von Prototypen ist es, sie 

als ein kostengünstigeres Modell für das Endprodukt zu betrachten. 

Prototypen sind in anderen Ingenieursdisziplinen allgegenwärtig. Architekten lassen dreidimensionale 

maßstabsgetreue kleine Modelle eines Gebäudes anfertigen. Ein zukünftiger Bewohner kann auf diese Weise einen 

wesentlich lebendigeren Eindruck erhalten als es ihm mit einem Bauplan möglich wäre. Flugzeugbauer erproben an 

Prototypen den Windwiderstand im Windkanal. 

Diese Idee übernimmt die Softwaretechnik. Die Ziele hierbei sind meist, die Anforderungen anhand eines Beispiels 

zu erheben und überprüfen, technische Möglichkeiten zu überprüfen und demonstrieren oder frühzeitig mögliche 

Lösungsansätze zu präsentieren (letztere Prototypen werden auch als Demonstratoren bezeichnet). Die Idee der 

Prototypen in der Softwaretechnik ist dieselbe wie bei anderen Ingenieursdisziplinen: die rasche und billige 

Entwicklung eines prototypischen Systems zur Erprobung. 

Unter dem Begriff Prototypen versammeln sich in der Softwaretechnik aber sehr unterschiedliche Formen. Man 

kann sie unterscheiden anhand zweier unterschiedlicher Merkmale: zum einen anhand der Lebensdauer 

(Wegwerfprototyp, evolutionärer Prototyp), zum anderen anhand des Zwecks (Überprüfung der technischen 

Machbarkeit oder Demonstration der Funktionalität oder Interaktion). 

Wir werden sie im Folgenden näher kennen lernen.


Typen von Prototypen in Bezug auf Lebensdauer 

Wegwerf-Prototyp: 

2009-02-09 

beschreibt ein Softwaresystem exemplarisch 

dient zur Erhebung und Analyse von Anforderungen oder zur 

Überprüfung technischer Machbarkeit 

demonstriert die Funktionalität, die mit Stakeholdern diskutiert 

werden soll 

implementiert nicht notwendigerweise die gezeigte Funktionalität 

(z.B. GUI-Prototyp) 

ist als Komponente für das Endprodukt ungeeignet, weil billig erstellt 







Wegwerf-Prototyp: 

beschreibt ein Softwaresystem exemplarisch 

dient zur Erhebung und Analyse von Anforderungen oder zur 

Überprüfung technischer Machbarkeit 

demonstriert die Funktionalität, die mit Stakeholdern diskutiert 

werden soll 

implementiert nicht notwendigerweise die gezeigte Funktionalität 

(z.B. GUI-Prototyp) 

ist als Komponente für das Endprodukt ungeeignet, weil billig erstellt 

Der Wegwerfprototyp hat eine sehr begrenzte Lebensdauer. Er wird in keinem Fall zum Endprodukt werden. Sein 

Ziel ist es, einen Aspekt – sei es Funktionalität oder Interaktion – exemplarisch zu untersuchen oder zu 

demonstrieren. Dazu wird der relevante Aspekt mit möglichst billigen Mitteln realisiert (nicht notwendigerweise 

immer dadurch, dass tatsächlich Code geschrieben wird; siehe unten). Alle anderen Aspekte sind nicht realisiert. 

Weil der Prototyp unvollständig ist und mit billigen Mitteln erstellt wird, ist er für das Endprodukt ungeeignet – 

daher sein Name. Hat er den Aspekt demonstriert, wird er weggeworfen.



Evolutionärer Prototyp: 

2009-02-09 

dient zur schnellen Bereitstellung eines funktionsfähigen Systems im 

Rahmen von evolutionären Prozessmodellen zur Softwareentwicklung 

wird in weiteren Ausbaustufen zum endgültigen Produkt 

weiterentwickelt 







Evolutionärer Prototyp: 

dient zur schnellen Bereitstellung eines funktionsfähigen Systems im 

Rahmen von evolutionären Prozessmodellen zur Softwareentwicklung 

wird in weiteren Ausbaustufen zum endgültigen Produkt 

weiterentwickelt 

Im Gegensatz zum Wegwerf-Prototypen ist es beim evolutionären Prototypen vorgesehen, ihn schrittweise zum 

Endprodukt auszubauen. Er dient dazu, ein funktionsfähiges Systems möglichst schnell bereit zu stellen, wobei aber 

zu Anfang nicht die vollständige Funktionalität erwartet wird. Evolutionäre Prototypen finden ihren Einsatz unter 

anderem im Rahmen von evolutionären Prozessmodellen zur Softwareentwicklung. 

Der Vorteil dieser inkrementellen Entwicklung ist es, dass jede funktionstüchtige Ausbaustufe vom Benutzer erprobt 

werden kann. Die Erfahrung und Kritik der Benutzer mit der Ausbaustufe nimmt Einfluss auf die nächste 

Ausbaustufe. Iterativ wird der evolutionäre Prototyp in weiteren Ausbaustufen zum endgültigen Produkt 

weiterentwickelt. 

Bsp.: Die Ausbaustufen für die evolutionäre Entwicklung eines Textverarbeitungssystems könnten zum Beispiel so 

aussehen: 

1. grundlegende Funktionalität: Datei-Management, Editor, Textausgabe 

2. erweiterte Funktionalität: Style-Files, Bearbeitung mathematischer Formeln, Einbinden von Graphiken 

3. zusätzliche Funktionalität: Rechtschreibprüfung, Grammatiküberprüfung, Überarbeitungsmodus 

4. ergänzende Funktionalität: Tabellenkalkulation, Geschäftsgraphiken, E-Mail, Web-Browser, Scanner-Anbindung


Typen von Prototypen in Bezug auf Zweck 

Technischer Prototyp: 

2009-02-09 

zeigt die technische Umsetzbarkeit von Ansätzen zur Problemlösung 

implementiert einen (kleinen) Ausschnitt der Funktionalität des 

Systems 

wird eher zur Machbarkeitsabschätzung und -demonstration eingesetzt 







Technischer Prototyp: 

zeigt die technische Umsetzbarkeit von Ansätzen zur Problemlösung 

implementiert einen (kleinen) Ausschnitt der Funktionalität des 

Systems 

wird eher zur Machbarkeitsabschätzung und -demonstration eingesetzt 

Wegwerfprototypen und evolutionäre Prototypen unterscheiden sich anhand ihrer Lebensdauer. Ein völlig anderes 

Unterscheidungsmerkmal ist der Zweck, den man mit dem Prototypen verfolgt. Technische Prototypen zielen auf 

die technische Umsetzbarkeit von Ansätzen zur Problemlösung. Dazu implementiert der Prototyp einen (kleinen) 

Ausschnitt der Funktionalität des Systems. Technische Prototypen werden somit eher zur Machbarkeitsabschätzung 

und -demonstration eingesetzt. Sie gleichen dem Crash-Test-Stand, mit dessen Hilfe man das Verhalten von 

Karosserien im Automobilbau untersucht. 

Technische Prototypen können sowohl für den Wegwurf oder den evolutionären Ausbau vorgesehen sein. Sie 

können sich des Weiteren unterschieden in Bezug auf die Softwarearchitektur.


Horizontaler vs. vertikaler technischer Prototyp 

Horizontaler Prototyp: realisiert Aspekte einer spezifischen Ebene des 

Softwaresystems; Bsp: Oberflächenprototyp 

Benutzungsschnittstelle 

Anwendungslogik 

Netzwerk Datenhaltung 

System−Software 





Softwaresystems; Bsp: Anwendungsprototyp 






2009-02-09 







Softwaresystems; Bsp: Anwendungsprototyp 





Softwaresysteme können zumindest konzeptionell in verschiedene Schichten eingeteilt werden, die jeweils von 

bestimmten Aspekten abstrahieren. Grob kann die Implementierung einteilen in die Schicht der Systemsoftware, die 

durch das Betriebssystem zur Verfügung gestellt wird, Schichten mit technischen Diensten, wie 

Netzwerkkommunikation oder Datenhaltung, sowie die Schicht, die die eigentlich anwendungsspezifische Logik 

implementiert und die Schicht der Benutzungsschnittstelle, die die Interaktion mit dem Benutzer übernimmt. 

Hinsichtlich dieses konzeptionellen Aufbaus, kann man technische Prototypen weiter in horizontale und vertikale 

Prototypen unterscheiden. 

Der horizontale technische Prototyp realisiert Aspekte einer spezifischen Ebene des Softwaresystems. Der 

Anwendungsprototyp implementiert zum Beispiel die Anwendungslogik und der Oberflächenprototyp die 

Benutzungsschnittstelle. Hiermit untersucht oder demonstriert man die Funktionalität einer ausgesuchten Schicht. 

Da eine Schicht auf die andere aufbaut, aber nur eine Schicht implementiert wird, benötigen wir neben der 

Implementierung der relevanten Schicht selbst noch einen Simulator für die Schicht, auf die sich die relevante 

Schicht stützt. Man kann diese als Stumpf implementieren. Ein Stumpf bietet nicht die volle Funktionalität, 

sondern liefert auf die Anfragen der höheren Schicht einfach nur vorgefertigte Ergebnisse. Oberflächenprototypen 

können zum Beispiel so implementiert werden, dass die Anwendungsschicht alle Daten, die in der Oberfläche für 

bestimmte Anwendungsszenarien sichtbar sein sollen, in internen Tabellen abgespeichert hat und sie ohne weitere 

Berechnungen einfach als Ergebnis einer aufgerufenen Operation zurück liefert. Damit zeigt der Oberflächentyp 

möglicherweise falsche Daten an, aber zumindest die Interaktion lässt sich demonstrieren. 



Vertikaler Prototyp: realisiert ausgewählte Aspekte des Softwaresystems 

vollständig 






2009-02-09 






Vertikaler Prototyp: realisiert ausgewählte Aspekte des Softwaresystems 

vollständig 





Der vertikale technische Prototyp realisiert ausgewählte Aspekte des Softwaresystems vollständig durch alle 

Schichten hindurch. Er stellt einen Durchstich durch das System dar. Mit seiner Hilfe lässt sich die Zusammenarbeit 

verschiedener Schichten untersuchen. Er findet auch bei inkrementeller Entwicklung Einsatz, bei der die erste 

Ausbaustufe funktionstüchtig ist (wenn auch nicht alle Funktionen implementiert sind). Dann wird der Durchstich 

in die Breite in den weiteren Ausbausstufen ausgedehnt, um die restliche Funktionalität zu implementieren. Man 

geht also zuerst in die Tiefe und dann in die Breite bei diesem Vorgehen. 

Wir setzen solche Prototypen während der Anforderungsanalyse ein, wenn wir kritische Anforderungen haben, von 

denen wir nicht sicher sind, dass wir sie realisieren können. Ansonsten werden sie auch gerne vor Entwurf der 

Architektur angewandt, um einzusetzende Technologien oder geplante Entwürfe zu untersuchen. 


Prototypen für Interaktion: Storyboards 

Storyboards: 

Typen: 

Prototypen für die Interaktion zwischen Mensch und Maschine 

demonstrieren das zu diskutierende Systemverhalten als ” Geschichte“ 

passives Storyboard (Papierprototyp) 

aktives Storyboard (animierter Prototyp) 

interaktives Storyboard (ausführbarer Prototyp) 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

Aufwand 


2009-02-09 






Storyboards: 

Typen: 

Prototypen für die Interaktion zwischen Mensch und Maschine 

demonstrieren das zu diskutierende Systemverhalten als ” Geschichte“ 

passives Storyboard (Papierprototyp) 

aktives Storyboard (animierter Prototyp) 

interaktives Storyboard (ausführbarer Prototyp) 

In der Anforderungsanalyse müssen wir die Interaktion zwischen Benutzer und Anwender festlegen. Dieser 

Interaktion nimmt eine Schlüsselrolle ein, weil ein Softwaresystem, das alle gewünschten Funktionalitäten bietet, 

dennoch unbrauchbar sein kann, wenn man es nicht benutzen kann. Aus diesem Grunde wollen schon sehr früh, 

Interaktion ausprobieren können und sie Kunden und Benutzern vorstellen. Hier können wir Oberflächenprototypen 

entwickeln. 

Oberflächenprototypen sind horizontale Prototypen, bei denen die Interaktion untersucht oder demonstriert werden 

soll. Meist dienen sie weniger der technischen Machbarkeit, sondern vielmehr der konzeptionellen Angemessenheit 

und Schlüssigkeit. Wir untersuchen damit, ob der Benutzer später mit unserem System effizient und effektiv 

interagieren kann. 

Dem Oberflächenprototypen kommt unter den Prototypen eine Sonderstellung zu, weil es die Oberfläche ist, die der 

Benutzer später sehen und bedienen wird. Alle anderen Schichten sind für ihn unsichtbar. Wenn wir die von uns 

einzusetzenden Implementierungsechnologien bereits sicher beherrschen, können wir auf solche technische 

Prototypen tieferer Schichten verzichten. Weil wir aber in der Anforderungsspezifikation auch die 

Benutzungsschnittstelle beschreiben müssen und die Qualität einer Software aus Benutzersicht steht und fällt mit 

ihrer Benutzbarkeit, sind Oberflächenprototypen für die Anforderungsanalyse unerlässlich. 

Aus diesem Grunde genießen Oberflächenprototypen hier unser Hauptaugenmerk. Wir unterscheiden dabei die 

folgenden Typen: 

• passives Storyboard (Papierprototyp) 

• aktives Storyboard (animierter Prototyp) 

• interaktives Storyboard (ausführbarer Prototyp) 

Alle Typen von Storyboards beschreiben die zukünftige Interaktion mit dem System als eine Art Drehbuch, daher 

ihr Name. Sie unterscheiden sich jedoch im Grad ihrer Interaktivität. Das interaktive Storyboard bietet dabei die 

höchste Interaktivität. Mit dem Grad der Interaktivität steigen aber auch die Kosten für die Entwicklung des 

Storyboards. Wir werden im Folgenden diese drei Typen näher beschreiben. 


Passive Storyboards 

Demonstration: 

Mittel: 

Analytiker spielt die Bedienung mit dem System durch, indem er 

entlang eines Anwendungsszenarios Eingabemöglichkeiten und 

Systemreaktionen demonstriert 

Skizzen 

Bildschirm-Masken (Screenshots) 

mögliche Systemausgaben 

Bemerkung: 

+ ermöglicht einfache und billige Prototyperstellung 

+ ermöglicht Interaktion mit Beteiligten am Beispiel 

- erfordert Anwesenheit des Analytikers 


000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

000000000000000 

111111111111111 

Aufwand

2009-02-09 

2009-02-09 









Mittel: 

Skizzen 



Bemerkung: 




Passive Storyboards erlauben selbst keine Interaktion. Statt dessen spielt der Analytiker bei der Demonstration die 

Bedienung mit dem System durch, indem er entlang eines Anwendungsszenarios die Eingabemöglichkeiten und 

Systemreaktionen demonstriert. 

Als Mittel werden Skizzen, Bildschirm-Masken in Form von Bildschirmabzügen (Screenshots) und mögliche 

Systemausgaben verwendet. Die einfachsten Materialien sind Papier und Bleistift. Dafür sprechen die besonders 

einfache und billige Prototyperstellung sowie die Möglichkeit zur Interaktion mit den Beteiligten am konkreten 

Beispiel. Der Benutzer selbst kann mit diesen Materialien selbst umgehen und an der Entwicklung des Prototypen 

direkt mitwirken. 




Beispiel passives Storyboard 






Mittel: 

Skizzen 



Bemerkung: 




Bsp.: Unsere Analyse der Schwachstellen in der Ist-Analyse zu unserem Fahrradladenbeispiel hat ergeben, dass es 

oft schwierig ist, einen Kunden beim Einkauf eines Artikels für ein Fahrrad, das sich schon in seinem Besitz 

befindet, richtig zu beraten, weil er nicht weiß, welche Daten das Fahrrad hat. Wenn er einen Flaschenhalter kaufen 

möchte, so muss er zu den Ausmaßen und Bohrungen sowie der Farbe des Rahmens passen. Wenn er sie nicht 

kennt, kann ihm der Verkäufer keine Empfehlung aussprechen. 

Wir haben uns entschlossen, einen Einkaufsassistenten auf Basis eines PDAs zu entwickeln. Auf diesem tragbaren 

Kleinrechner sind alle Einkäufe des Kunden erfasst und zwar branchenübergreifend, also Fahrradteile genauso wie 

Computer-Hardware etc. Wir möchten dem Benutzer die zukünftige Interaktion mit einem solchen PDA 

demonstrieren. Die Interaktion mit einem PDA hat besondere Herausforderungen, weil die darstellbare Fläche sehr 

begrenzt und typische Eingabegeräte wie Maus und Tastatur nicht vorhanden sind. 

Bild 1: Wir fertigen einen Papierprototypen an, indem wir einen realen PDA hernehmen und die dargestellten 

Elemente zeichnen und auf das Display legen. Das Bild zeigt die Einstiegsmaske mit den Produktgruppen des 

Käufers, die mit dem PDA verwaltet werden. Im Fahrradladen wählt er das Fahrradsymbol aus, wenn er einen 

Artikel für sein Fahrrad kaufen möchte. Dadurch gelangt er zum nächsten Dialog.



2009-02-09 

abfragen 

ändern 

entfernen 

ersetzen 







Bsp.: Bild 2: Im nächsten Dialog wird sein Fahrrad angezeigt. Er kann dann mit dem Stift auf ein Bestandteil 

seines Rades tippen. Darauf hin wird ein Menü eingeblendet, in dem er die nächste Aktion auswählen kann. Er kann 

einen Artikel abfragen, um Daten über ihn abzufragen, ändern, um den Artikel in seinen Eigenschaften zu ändern, 

entfernen, um ihn aus seiner Konfiguration zu löschen, oder ersetzen, um ihn durch einen neuen Artikel zu ersetzen. 

 

abfragen 

ändern 

entfernen 

ersetzen



2009-02-09 

1 

4 

145 Euro 

100 Euro 

78 Euro 

47 Euro 






5 

6 

2 

3 


Bsp.: Bild 3: Nehmen wir an, wir wählen den Sattel aus, und wählen ersetzen. Dann gelangen wir zum nächsten 

Dialog. Als nächstes werden alle Sättel angezeigt, die zum Fahrrad des Kunden passen, sortiert nach dem Preis. Es 

werden maximal vier Artikel angezeigt. Diese Liste kann weiter verarbeitet werden, indem wir mit den Stift tippen 

oder die Tasten bedienen. Berühren wir mit dem Stift das Bild des Sattels (1), den Beschreibungstext (2) oder den 

Preis, dann gelangen wir zum Kaufdialog. Bedienen wir auf dem Tastenfeld die Nach-Oben- (4) beziehungsweise 

die Nach-Unten-Taste (5) können wir den sichtbaren Ausschnitt in der Liste der gefundenen Artikel nach oben 

beziehungsweise nach unten bewegen. Mit der Auswahltaste (5) gelangen wir zum Kaufdialog. 

1 

4 

145 Euro 

100 Euro 

78 Euro 

47 Euro 

5 

6 

2 

3



1 

2009-02-09 

Screen Auswahl Screen Kaufen 

100 Euro 

78 Euro 

47 Euro 

2 1 

145 Euro 145 Euro 

7 

5 6 4 4 

Wollen Sie diesen 

Artikel kaufen? 

ja 

nein 

5 6 







1 

100 Euro 

78 Euro 

47 Euro 

2 1 

7 

2 

8 



5 6 4 4 

Bsp.: Bild 4: Im Kaufdialog wird nur der ausgewählte Artikel angezeigt und der Kunde wird gefragt, ob er den 

Artikel kaufen möchte. Bestätigt er mit der Schaltfläche “Ja” (7), dann wird der Artikel in den virtuellen 

Warenkorb des elektronischen Verkaufsassistenten gelegt, der vom Verkäufer an der Kasse ausgelesen werden kann. 

Mit der Schaltfläche “Nein” wird der Vorgang abgebrochen, und man gelangt zum Auswahldialog zurück. 

Die Entscheidung, maximal vier Artikel anzuzeigen, haben wir in der Vorbereitung des Papierprototypen getroffen. 

Wir hatten sehr schnell im maßstabgetreuen Modell feststellen können, dass mehr als vier Artikel nicht auf dem 

kleinen Monitor zu präsentieren sind. Wir haben jedoch versäumt, irgendwie kenntlich zu machen, dass mehr als 

vier Artikel als Ergebnis der Suchanfrage geliefert wurden, aber nicht alle sichtbar sind. Der Kunde fragt uns 

während der Vorführung, wie das denn zu erkennen sei. Der Kunde nimmt dann einen roten Farbstift, zeichnet 

dafür rote Pfeile nach oben beziehungsweise unten über dem ersten beziehungsweise letzten angezeigten Element 

ein und sagt uns, dass er das gerne so hätte. Während wir dem Kunden diesen Prototypen vorführen, bemerkt 

dieser außerdem, dass wir im Auswahldialog keine Möglichkeit vorgesehen haben, den Dialog durch einen anderen 

Weg als zum Kaufdialog zu verlassen. Uns ist also glücklicherweise früh genug vom Kunden klar gemacht worden, 

dass wir in der Dialogführung einige Dinge übersehen haben. Die Überarbeitung unseres Papierprototypen ist aber 

einfach. So einfach, dass es der Kunde gleich selbst übernehmen konnte. 

Passive Storyboards eignen sich besonders in der frühen Phase des Interaktions-Designs, in der man den Benutzer 

aktiv in den Design-Prozess einbeziehen möchte. 



ja 

nein 

5 6 

2 

8


Aktive Storyboards 


Mittel: 

Abspielen einer selbstablaufenden Präsentation des Systemverhaltens 

Film, Diashow 

selbstablaufende Präsentation 

Bemerkung: 

2009-02-09 

+ ermöglicht einfache automatisierte Darstellung von typischen 

Anwendungsszenarien 

+ erfordert nicht unbedingt die Anwesenheit von Analytikern 

- erlaubt keine Interaktion während der Präsentation 





Aktive Storyboards 


Abspielen einer selbstablaufenden Präsentation des Systemverhaltens 

Mittel: 

Film, Diashow 

selbstablaufende Präsentation 

Bemerkung: 

+ ermöglicht einfache automatisierte Darstellung von typischen 

Anwendungsszenarien 

+ erfordert nicht unbedingt die Anwesenheit von Analytikern 

- erlaubt keine Interaktion während der Präsentation 

Während passive Storyboards durch den Analytiker demonstriert werden müssen, sind aktive Storyboards 

Präsentationen des Systemverhaltens, die von selbst ablaufen. Sie laufen wie ein Film ab. Dazu kann man 

tatsächlich kontinuierliche Sequenzen wie in einem Film darstellen (z.B. mit Werkzeugen wie Macromedia Flash 

oder Camtesia) oder aber Einzelbilder der Dialoge (z.B. mit einer Präsentationssoftware wie OpenOffice oder 

Powerpoint) anzeigen. 

Typische Anwendungsszenarien können automatisiert dargestellt werden. Weil ein aktives Storyboard von allein 

abläuft, ist die Anwesenheit von Analytikern nicht unbedingt erforderlich. Damit können solche Demos an eine 

Vielzahl von möglichen Benutzern verschickt und deren Meinung eingeholt werden. Allerdings erlauben aktive 

Storyboards keine Interaktion während der Präsentation, was gerade in der frühen Phase des Interaktions-Designs 

wünschenswert ist. 

Aktive Storyboards eignen sich besonders in einer fortgeschritteneren Phase des Interaktions-Designs, in der man 

ein ausgearbeitetes Konzept sehr vielen Benutzern vorstellen möchte.


Interaktive Storyboards 


Mittel: 

Prototyp ermöglicht dem Benutzer die frühzeitige Interaktion mit dem 

möglichen System; Funktionalität kann evtl. durch Analytiker ” von 

Hand“ simuliert werden 

ausführbares Programm, das Teile der Funktionalität realisiert 

Bemerkung: 

2009-02-09 

+ ermöglicht Interaktion des Nutzers mit dem System 

+ erlaubt größtmögliche Nähe zum realen System 

- erfordert höheren Aufwand bei Prototyp-Erstellung 





Interaktive Storyboards 


Prototyp ermöglicht dem Benutzer die frühzeitige Interaktion mit dem 

möglichen System; Funktionalität kann evtl. durch Analytiker ” von 

Hand“ simuliert werden 

Mittel: 

ausführbares Programm, das Teile der Funktionalität realisiert 

Bemerkung: 

+ ermöglicht Interaktion des Nutzers mit dem System 

+ erlaubt größtmögliche Nähe zum realen System 

- erfordert höheren Aufwand bei Prototyp-Erstellung 

Interaktive Storyboards bieten die größtmögliche Interaktion mit dem System. Dazu wird ein ausführbares 

Programm entwickelt, was die Eigenschaften der Benutzungsschnittstelle demonstriert. Es können einzelne Teile der 

Funktionalität bereits prototypisch implementiert sein. Meist genügen aber auch vorbereitete Daten für bestimmte 

Szenarien, die nicht wirklich berechnet, sondern nur in Reaktion auf die Eingabe des Benutzers angezeigt werden. 

Die Daten müssen auch nicht korrekt sein, solange es nur um die Demonstration der Interaktion geht. Die 

Funktionalität kann unter Umständen auch durch den Analytiker ” von Hand“ simuliert werden. 

Interaktive Storyboards ermöglichen echte Interaktion des Nutzers mit dem System mit einer größtmöglichen Nähe 

zum realen System. Dabei muss der Analytiker nicht bei der Demonstration anwesend sein. Allerdings kann der 

Benutzer auch hier nicht selbst eingreifen, um eigene Vorstellungen einzubringen, und wir haben einen höheren 

Aufwand bei der Prototyp-Erstellung. GUI-Design-Werkzeuge können jedoch einen Teil des Aufwands reduzieren. 

Interaktive Storyboards werden in der Regel in späteren Phasen des Interaktions-Designs entwickelt, bei denen man 

schon genaue Vorstellungen entwickelt hat. Sie können für Nutzertests zur Gebrauchsttauglichkeit des Systems 

eingesetzt werden, indem man verschiedene Nutzer (pro Persona mindestens einen) mit dem System interagieren 

lässt und diese Interaktion beobachtet und auswertet.


Vor- und Nachteile des Einsatzes von Prototypen 

2009-02-09 

+ erlauben frühzeitige Demonstration von Lösungsansätzen 

+ erlauben frühzeitige Beteiligung der Benutzer 

+ vermeiden das ” Leere-Blatt-Syndrom“ 

+ reduzieren Entwicklungsrisiken durch frühzeitige Diskussion mit 

Beteiligten 

+ geeignete Werkzeuge ermöglichen die schnelle Erstellung von 

Prototypen 

– erfordern erhöhten Entwicklungsaufwand durch (zusätzliche) 

Prototyp-Entwicklung 

– Gefahr, dass Wegwerf-Prototyp Teil des Produkts wird (z.B. aus 

Zeitdruck) 






Zum Ende des Abschnitts über Prototypen fassen wir die Vor- und Nachteile von Prototypen zusammen. 

Vorteile: 






Beteiligten 


Prototypen 




Zeitdruck) 

+ Prototypen erlauben eine frühzeitige Demonstration von Lösungsansätzen mit vertretbaren Kosten. Gerade weil der 

Interaktion eine hohe Bedeutung zukommt und sie auch in der Anforderungsspezifikation genau beschrieben sein sollte, 

sollten wir in der Anforderungsanalyse präzise Konzepte entwickeln und sie dem Kunden und Benutzer vorführen, um die 

Konzepte zu evaluieren und zu verbessern. Andererseits können wir zu einem so frühen Zeitpunkt nicht die ganze 

Applikation bereits entwickeln. Darum also Prototypen. 

+ Prototypen erlauben damit eine frühzeitige Beteiligung der Benutzer. Der Benutzer selbst kann sich ein genaueres Bild 

des späteren Systems machen und frühzeitig korrigierend eingreifen. 

+ Prototypen vermeiden das ” Leere-Blatt-Syndrom“, das wir von Schriftstellern kennen, die die erste Seite ihres neuen 

Romans schreiben sollen. Mit Prototypen können wir direkt loslegen. Insbesondere Papierprototypen helfen uns einen 

schnellen Einstieg zu finden, weil sie billig herzustellen und leicht änderbar sind. 

+ Prototypen reduzieren Entwicklungsrisiken durch frühzeitige Diskussion mit Beteiligten. Wir wissen, wie teuer uns späte 

Änderungen kommen. Darum stellen wir durch frühes Vorzeigen und Einbeziehen der Benutzer sicher, dass wir auf dem 

richtigen Weg sind. Dafür ist eine Anfangsinvestition notwendig, um den Prototypen zu entwickeln, die sich aber im 

Verlaufe des Projekts mit sehr hoher Wahrscheinlichkeit amortisiert, weil weniger Fehler in der Anforderungsanalyse 

gemacht werden. 

+ Geeignete Werkzeuge ermöglichen die schnelle Erstellung von Prototypen, so dass sich die Kosten in Grenzen halten. 

Beispielsweise gibt es GUI-Builder, mit denen man sich rasch graphische Benutzeroberflächen zusammen klicken kann. 

Oder man benutzt Werkzeuge wie Graphikprogramme (auch scripting-fähige, wie Adobe Flash) und 

Präsentationssoftware.

2009-02-09 


Nachteile: 


Wegweiser 









Beteiligten 


Prototypen 




Zeitdruck) 

– Auch wenn Prototypen billiger sind als das Endprodukt, so erfordern Prototypen einen erhöhten Entwicklungsaufwand 

durch die zusätzlich Prototyp-Entwicklung. Je nach Ausbau des Prototypen können die Kosten erheblich sein. 

– Bei der Entwicklung von Wegwerfprototypen wird kein großer Wert auf Qualität gelegt; sie müssen zeigen, was sie 

zeigen sollen, und ansonsten möglichst billig sein. Der größte Nachteil dieser Prototypen ist somit die Gefahr, dass sie 

zum Teil des Produkts werden (z.B. aus Zeitdruck). Bei interaktiven Storyboards erhalten Kunde und Projektmanager 

den Eindruck, dass das System schon beinahe fertig ist. Die Versuchung ist groß, den Wegwerfprototypen auszubauen, 

statt ihn wie geplant wegzuwerfen. Das rächt sich jedoch in der Regel, weil die Qualität des Wegwerfprototypen ein 

solches Vorgehen nicht unterstützt. Dieser Gefahr kann man durch Papierprototypen oder durch eine Entwicklung mit 

einer Programmiersprachen, die man später für das Endprodukt nicht benutzen möchte, vorbeugen. 

Analysetechniken 

Wann wird welche Analysetechnik eingesetzt? 




Ist-Zustand Soll-Zustand Folgen 

Auswertung vorhandener + - - 

Daten/Dokumente 

Beobachtungen + ◦ - 

Befragung 

- geschlossene Fragen + ◦ - 

- offene Fragen + ◦ - 

- hybride Fragen + ◦ - 

Prototyping - + + 

partizipative Entwicklung - + + 

2009-02-09 











Befragung 






Zum Abschluss der Ist- und Sollanalyse fassen wir noch einmal die Techniken, die wir kennen gelernt haben, 

zusammen und bewerten ihre Eignung für das Erfassen des Ist-Zustands, der Planung des Soll-Zustands und der 

Abschätzung mittel- und langfristiger Folgen unserer anvisierten Softwarelösung. Die folgende Tabelle gibt einen 

Überblick: 





Befragung 






Die Auswertung vorhandener Dokumente ist ein Instrument rein für die Erhebung des Ist-Zustands, weil sie auf 

Existierendem basiert. Befragung und Beobachtung setzen auch etwas Existierendes voraus. Man kann sie aber 

auch einsetzen, um Prototypen zu evaluieren. Prototypen sind eine Vision des Soll-Zustandes, die handfest und 

überprüfbar ist. Mit ihnen kann man durch geeignete Evaluierung auch die Folgen des Einsatzes des späterens 

Systems abschätzen. Man kann also zum Beispiel demonstrieren, dass frühere Redundanzen und manuelle Eingriffe 

nicht mehr existieren werden, was die Fehleranfälligkeit reduziert. Außerdem kann man nachweisen, dass ein 

Benutzer schneller seine Aufgabe erledigen kann, als das vorher der Fall war.

2009-02-09 










Befragung 






Die partizipative Entwicklung ist die Softwareentwicklung, die die späteren Benutzer einbezieht – wohl gemerkt, die 

Benutzer, nicht nur den Kunden. Es gibt hierfür verschiedene Ausprägungen. Die Benutzer können zu Anfang in der 

Phase des Interaktions-Designs bei der Entwicklung von Prototypen einbezogen werden und gegen Ende beim 

Akzeptanztest. Bei inkrementellen Entwicklungsprozessen, bei denen ein System in kleineren funktionstüchtigen 

Inkrementen entwickelt werden, werden sie noch stärker einbezogen. Dort evaluieren sie jedes einzelne Inkrement – 

also Zwischenprodukt – und nicht nur das Endprodukt. Da die Anforderungsanalyse bei der Entwicklungsphase des 

nächsten Inkrements wieder durchlaufen wird, kann der Benutzer an vielen Punkten der Entwicklung Einfluss 

nehmen. Diese Idee wird beim Extreme Programming, einem agilen Entwicklungsprozess, zum Extrem getrieben, 

indem ein Benutzer vor Ort der Entwicklung ist und wöchentlich das System testet und Verbesserungsvorschläge 

unterbreitet. Die Gebrauchstauglichkeit kann auf diese Weise besser sicher gestellt werden. Außerdem haben 

Benutzer die Möglichkeit, das System, das sie später einsetzen sollen, mitzugestalten, was zu einer höheren 

Akzeptanz führen sollte. 


Wegweiser 


Wie halten wir die Anforderungen fest? 



Anforderungsspezifikation nach IEEE Std 610.12-1990 

Definition 

requirement: condition or capability needed by a user to solve a problem 

or achieve an objective. 

specification: document that specifies, in a complete, precise, verifiable 

manner, the requirements (, ...) of a system or component, and, often, the 

procedures for determining whether these provisions have been satisfied. 

software requirements specification (SRS): documentation of the 

essential requirements (functions, performance, design constraints, and 

attributes) of the software and its external interfaces. 

2009-02-09 







Definition 









An die Ist- und Sollanalyse schließt sich die Formulierung der Anforderungen an. Die Sollanalyse ergibt, was die 

Software leisten muss, um die Schwachstellen, die durch die Ist-Analyse offenbar wurden, zu beseitigen. Die 

Sollanalyse hat jedoch nur die prinzipiellen Konzepte erarbeitet. Diese müssen wir nun präzise ausarbeiten und am 

besten schriftlich festhalten. In diesem Abschnitt setzen wir uns deshalb mit der Frage auseinander, wie die 

Anforderungen formuliert sein sollen. Bevor wir jedoch dazu kommen, müssen wir über ein paar grundlegende 

Begriffe einig werden. Was ist denn eine Anforderungsspezifikation genau? 

Im Englischen wird die Anforderungsspezifikation Requirement Specification genannt, was sich aus Requirement für 

Anforderung und Specification zusammen setzt. Das Software-Engineering-Glossar IEEE Std 610.12-1990 definiert 

Requirement wie folgt: 

Requirement : condition or capability needed by a user to solve a problem or achieve an objective. 

Zu Deutsch: eine Anforderung ist eine Bedingung oder Fähigkeit, die von einem Benutzer benötigt wird, um ein 

Problem zu lösen oder ein Ziel zu erreichen. 

Eine Spezifikation ist wie folgt definiert: 

Specification : document that specifies, in a complete, precise, verifiable manner, the requirements (, ...) of a system 

or component, and, often, the procedures for determining whether these provisions have been satisfied. 

Eine Spezifikation ist ein Dokument, das vollständig, präzise und überprüfbar die Anforderungen an ein System 

oder eine Komponente spezifiziert und oft auch die Prüfprozeduren nennt, um festzustellen, ob diese Forderungen 

tatsächlich erfüllt sind. 

Diese Definition erläutert nicht nur den Begriff Spezifikation, sondern stellt auch eine Reihe von Forderungen für 

Spezifikation auf. Sie sollen vollständig, präzise und überprüfbar sein. Vollständig bedeutet, dass die Spezifikation 

alle relevanten Anforderungen nennt. Präzise heißt, dass keine Anforderung missverstanden werden kann. 

Überprüfbar bedeutet, dass man für jede Anforderung eine Prüfprozedur angeben kann, anhand derer man objektiv 

nachweisen kann, dass eine Anforderung erfüllt ist. Wir werden uns mit diesen Eigenschaften und mit weiteren 

Qualitäten, die eine gute Anforderungsspezifikation auszeichnen, in diesem Abschnitt noch auseinander setzen.

2009-02-09 





Der zusammengesetzte Begriff Software Requirements Specification ist wie folgt definiert: 


Definition 









Software Requirements Specification : documentation of the essential requirements (functions, performance, design constraints, 

and attributes) of the software and its external interfaces. 

Diese Definition ergänzt die einzelnen Definitionen von Anforderung und Spezifikation um den Inhalt, der in einer 

Anforderungsspezifikation aufgeführt ist. Die Anforderungsspezifikation ist demnach eine Dokumentation der 

wesentlichen Anforderungen (Funktionen, Performanz, Entwurfseinschränkungen, und Attribute) einer Software 

sowie ihrer externen Schnittstellen. Diese Inhalte entstammen einer anderen IEEE-Norm, die beschreibt, wie 

Anforderungsspezifikation aufgebaut sind und welche Inhalte sie haben. Mit dieser Norm werden wir uns hier noch 

auseinander setzen. 


Anforderungen 

Anforderungen sind gleichbedeutend mit Minimalbedingungen hinsichtlich 

Funktion und Qualität. 

⇒ Wir müssen also die Funktion und Qualität definieren. 

Definition 

Funktion: in der Zeit ablaufende Transformation 

von Eingabedaten 

in Ausgabedaten 

unter Verwendung von Ressourcen 


2009-02-09 




Anforderungen 

Anforderungen 

Anforderungen sind gleichbedeutend mit Minimalbedingungen hinsichtlich 

Funktion und Qualität. 

⇒ Wir müssen also die Funktion und Qualität definieren. 

Definition 

Funktion: in der Zeit ablaufende Transformation 

von Eingabedaten 

in Ausgabedaten 

unter Verwendung von Ressourcen 

Anforderungen legen die Minimalbedingungen hinsichtlich Funktion und Qualität fest. Was aber sind Funktionen 

und wie definiert man Qualität für Software? 

Während sich Funktionen über den Zusammenhang von Eingaben des Benutzers und darauf hin erwartete 

Ausgaben unter Verwendung einer maximalen Menge von Ressourcen definieren lassen, ist der Begriff 

Softwarequalität weniger offensichtlich. 


Produktqualitäten nach ISO/IEC-Standard 9126 (2001) 

Änderbarkeit 

Übertragbarkeit 

Stabilität 

Zuverlässigkeit 

Prüfbarkeit 

Analysierbarkeit 

Reife 

Modifizierbarkeit 

Funktionalität 

Fehlertoleranz 

Wiederherstellbarkeit 

Ordnungsmäßigkeit 

Angemessenheit 

Interoperabilität 

Sicherheit 

Richtigkeit 

Softwarequalität 

Austauschbarkeit 

Installierbarkeit 

Konformität 

Verständlichkeit 

Erlernbarkeit 

Verbrauchsverhalten 

Zeitverhalten 

Anpassbarkeit 

Bedienbarkeit 

Benutzbarkeit 

Effizienz 


2009-02-09 

2009-02-09 






Änderbarkeit 


Zuverlässigkeit Funktionalität 


Stabilität Reife 

Prüfbarkeit 





Wiederher- 


stellbarkeit 

Sicherheit 

Richtigkeit 



Verständlichkeit Verbrauchs- 


verhalten 

Erlernbarkeit 

Konformität Zeitverhalten 

Bedienbarkeit 

Anpassbarkeit 

Der Begriff Softwarequalität ist sehr vielschichtig. Im Allgemeinen bedeutet Qualität lediglich, zu welchem Grad ein 

Gegenstand bestimmte Attribute aufweist. Während die Qualität einer Schraube recht einfach durch die Attribute 

Festigkeit, Gewicht, Material, Preis etc. festgelegt werden kann, sind die wesentlichen Attribute bei Software nicht 

ohne Weiteres offensichtlich. 

Im internationalen Standard ISO/IEC-Standard 9126 (2001) werden typische Softwarequalitäten in Form 

allgemeiner Kategorien und Subkategorien wie folgt aufgeführt: 

Funktionalität: Vorhandensein von Funktionen mit festgelegten Eigenschaften, die die definierten Anforderungen 

erfüllen: 

• Richtigkeit: Liefern der richtigen oder vereinbarten Ergebnisse oder Wirkungen, z.B. die benötigte Genauigkeit von 

berechneten Werten 

• Angemessenheit: Eignung der Funktionen für spezifizierte Aufgaben, z.B. aufgabenorientierte Zusammensetzung von 

Funktionen aus Teilfunktionen 

• Interoperabilität: Fähigkeit, mit vorgegebenen Systemen zusammen zu wirken 

• Ordnungsmäßigkeit: Erfüllung von anwendungsspezifischen Normen, Vereinbarungen, gesetzlichen Bestimmungen und 

ähnlichen Vorschriften 

• Sicherheit: Fähigkeit, unberechtigten Zugriff, sowohl versehentlich als auch vorsätzlich, auf Programme und Daten zu 

verhindern 

Zuverlässigkeit: Fähigkeit der Software, ihr Leistungsniveau unter festgelegten Bedingungen über einen festgelegten 

Zeitraum zu bewahren: 

• Reife: Geringe Versagenshäufigkeit durch Fehlerzustände 

• Fehlertoleranz: Fähigkeit, ein spezifiziertes Leistungsniveau bei Softwarefehlern oder Nicht-Einhaltung ihrer spezifizierten 

Schnittstelle zu bewahren 

• Wiederherstellbarkeit: Fähigkeit, bei einem Versagen das Leistungsniveau wiederherzustellen und die direkt betroffenen 

Daten wiederzugewinnen 





Benutzbarkeit 

Effizienz 


Änderbarkeit 





Prüfbarkeit 





Wiederher- 


stellbarkeit 

Sicherheit 

Richtigkeit 





verhalten 

Erlernbarkeit 


Bedienbarkeit 

Anpassbarkeit 

Benutzbarkeit: Aufwand, der zur Benutzung erforderlich ist, und individuelle Beurteilung der Benutzung durch eine 

festgelegte oder vorausgesetzte Benutzergruppe: 

• Verständlichkeit: Aufwand für den Benutzer, das Konzept und die Anwendung zu verstehen 

• Erlernbarkeit: Aufwand für den Benutzer, die Anwendung zu erlernen (z.B. Bedienung, Ein-, Ausgabe) 

• Bedienbarkeit: Aufwand für den Benutzer, die Anwendung zu bedienen 

Effizienz: Verhältnis zwischen dem Leistungsniveau der Software und dem Umfang der eingesetzten Betriebsmittel 

unter festgelegten Bedingungen: 

• Zeitverhalten: Antwort- und Verarbeitungszeiten sowie Durchsatz bei der Funktionsausführung 

• Verbrauchsverhalten: Anzahl und Dauer der benötigten Betriebsmittel für die Erfüllung der Funktionen 

Änderbarkeit: Aufwand, der zur Durchführung vorgegebener Änderungen notwendig ist; Änderungen: Korrekturen, 

Verbesserungen oder Anpassungen an Änderungen der Umgebung, der Anforderungen und der funktionalen 

Spezifikationen: 

• Analysierbarkeit: Aufwand, um Mängel oder Ursachen von Versagen zu diagnostizieren oder um änderungsbedürftige 

Teile zu bestimmen 

• Modifizierbarkeit: Aufwand zur Ausführung von Verbesserungen, zur Fehlerbeseitigung oder Anpassung an 

Umgebungsänderungen 

• Stabilität: Wahrscheinlichkeit des Auftretens unerwarteter Wirkungen von Änderungen 

• Prüfbarkeit: Aufwand, der zur Prüfung der geänderten Software notwendig ist 

Übertragbarkeit: Eignung der Software, von einer Umgebung in eine andere übertragen zu werden (Umgebung 

kann organisatorische Umgebung, Hardware oder Softwareumgebung einschließen): 

• Anpassbarkeit: Software an verschiedene festgelegte Umgebungen anpassen 

• Installierbarkeit: Aufwand, der zum Installieren der Software in einer festgelegten Umgebung notwendig ist 

• Konformität: Grad, in dem die Software Normen oder Vereinbarungen zur Übertragbarkeit erfüllt 

• Austauschbarkeit: Möglichkeit, diese Software anstelle einer spezifizierten anderen in der Umgebung jener Software zu 

verwenden, sowie der dafür notwendige Aufwand 

Benutzbarkeit 

Effizienz

2009-02-09 






Änderbarkeit 





Prüfbarkeit 





Wiederher- 


stellbarkeit 

Sicherheit 

Richtigkeit 





verhalten 

Erlernbarkeit 


Bedienbarkeit 

Anpassbarkeit 

Diese Kategorien sind immer noch sehr allgemein und müssen für die Anforderungen an eine bestimmte Software 

konkretisiert und gewichtet werden. Dabei ist zu beachten, dass sich Qualitätsattribute gegenseitig (auch negativ) 

beeinflussen können. So stehen hohe Performanz und hohe Wartbarkeit meist in einem Spannungsfeld zueinander. 

Die Konkretisierung und Gewichtung der Qualitätsattribute liefert das Qualitätsmodell. Für das Qualitätsmodell 

müssen dann Prüfkriterien festgelegt werden, anhand derer das Vorhandensein der gewünschten Eigenschaften 

überprüft werden kann. Im ISO/IEC-Standard 25000 (2005), der die Nachfolge von ISO/IEC-Standard 9126 (2001) 

angetreten hat, werden hierfür Metriken angegeben. Metriken sind ein numerisches Maß, das beschreibt, inwieweit 

eine bestimmte Qualität vorliegt. Durch Einsatz der Metriken wird die Qualität messbar. Über die wesentlichen 

Qualitätsattribute und sinnvolle Metriken zu ihrer Messung herrscht jedoch nicht immer Konsens. 

Auch die Kategorisierung der Qualitätsattribute ist nicht immer gleich. Ludewig (2003) beispielsweise unterscheidet 

auf oberster Ebene nach inneren und äußeren Qualitäten. Äußere Qualitäten sind solche, die für den Benutzer 

direkt spürbar sind. Innere Qualitäten richten sich primär an den Entwickler, sind jedoch zumindest indirekt auch 

für den Benutzer spürbar durch den Aufwand und die Dauer für Änderungen an der Software, um sie an neue und 

geänderte Anforderungen anzupassen. Die folgende Grafik zeigt die Aufteilung nach Ludewig (2003): 

Produktqualität 

innere 

äußere 

Wartbarkeit 

... 

Integrierbarkeit ... 

... ... 

Erstellbarkeit ... 

... 

Wiederverwendbarkeit 

... 

Zuverlässigkeit ... 

... ... 

Nützlichkeit ... 

... ... 

Robustheit ... 

... ... 

Bedienbarkeit ... 

... ... 

Sicherheit ... 

... 

Prüfbarkeit 

Änderbarkeit 

Portabilität 


Bedeutung einer Anforderungsspezifikation 

Zweck Folge von Mängeln 

Abstimmung mit 

Kunden 

... 

... 

... 

Die Anforderungen bleiben ungeklärt, Wünsche des 

Kunden bleiben unberücksichtigt. 

Entwurf Entwerfer fehlt Vorgabe, darum mehr Kommunikation 

/ eigene Vorstellung als Vorgabe. 

Benutzerhandbuch Basis für das Handbuch fehlt, es wird darum phänomenologisch 

verfasst. 

Testvorbereitung systematischer Test ist unmöglich 

Abnahme Korrektheit ist subjektiv, Streit ist unvermeidbar. 

Wiederverwendung nicht spezifizierte Systeme sind kaum durchschaubar, 

darum schwer wiederzuverwenden. 

spätere Reimplementierung 

Kompatibilität setzt voraus, dass man weiß, womit 

die neue Software kompatibel sein soll. 


... 

... 

..... 

... 

... ... 

... 

... 

Benutzbarkeit 

Effizienz

2009-02-09 

2009-02-09 








Kunden 






verfasst. 








Die Anforderungsspezifikation ist von zentraler Bedeutung für die Entwicklung. Sie wird von vielen Personen, die 

am Entwicklungsprozess beteiligt sind, als Grundlage ihrer Arbeit verwendet. Eine minderwertige 

Anforderungsspezifikation führt zwangsläufig zu Mängeln aller davon abhängiger weiterer Arbeitsprodukte. Da alle 

weiteren Arbeitspakete von der Anforderungsspezifikation abhängig sind, haben solche Mängel also eine nachhaltige 

Auswirkung auf die Qualität. Deshalb sollte man sich die Mühe machen, die Anforderungen genau zu beschreiben 

und sie am auch aufzuschreiben. 

Man kann die Auswirkungen einer mangelhaften Anforderungsspezifikation unterscheiden anhand der Zwecke, die 

man mit der Anforderungsspezifikation verfolgt: 

• Abstimmung: Die Anforderungsspezifikation dient der Abstimmung mit dem Kunden. Mängel in der 

Anforderungsspezifikation führen dazu, dass Anforderungen ungeklärt und Wünsche des Kunden unberücksichtigt 

bleiben. Ohne eine ausgearbeitete Anforderungsspezifikation kann der Kunde nicht ohne Weiteres in frühen Phasen des 

Projekts überprüfen, ob er richtig verstanden wurde und seine Wünsche wirklich umgesetzt werden. 

• Entwurf: Der Softwarearchitekt entwirft auf Basis der Anforderungsspezifikation die Softwarearchitektur. Bei einer 

unzureichenden Anforderungsspezifikation fehlt dem Architekten dafür die notwendige Vorgabe. Dies führt zu einem 

erhöhten Bedarf an Kommunikation. Der Architekt muss beim Analytiker beziehungsweise beim Kunden nachfragen. 

Außerdem besteht die Gefahr, dass der Architekt seine eigene Vorstellung der Anforderungen entwickelt, die von der des 

Kunden abweichen könnte. 

• Benutzerhandbuch: Anhand der Anforderungsspezifikation wird das Benutzerhandbuch geschrieben. Ohne 

Anforderungsspezifikation fehlt die Basis für das Handbuch. Dies führt dazu, dass es phänomenologisch erfasst wird; d.h. 

der Autor des Benutzerhandbuchs schreibt auf, was er beim lauffähigen System beobachtet. Das ist oft unzureichend, 

weil er nicht alle Möglichkeiten kennt und damit beobachten kann. 

• Testvorbereitung: Ohne präzise und vollständige Anforderungen ist ein systematischer Test unmöglich. 

• Vertrag und Abnahme: In der Regel bildet die Anforderungsspezifikation die vertragliche Grundlage für den Auftrag. Am 

Ende des Projekts wird bei der Abnahme überprüft, ob die Anforderungen erfüllt sind. Damit wird die Überprüfung der 

Korrektheit subjektiv und Streit ist unvermeidbar. Das führt zur Unzufriedenheit des Kunden und häufig zu 

Vertragsstreitigkeiten. Da aber die Anforderungen nicht vollständig und präzise beschrieben sind, ist ein Streit um das 

Recht mühsam. 








Kunden 






verfasst. 








• Wiederverwendung: Ohne eine Beschreibung, was die Software leistet, kann man nicht ohne Weiteres beurteilen, ob 

man die Software wiederverwenden kann. Nicht spezifizierte Systeme sind kaum durchschaubar, darum schwer 

wiederzuverwenden. 

• Spätere Reimplementierung: Soll das System später gegen ein neues System ersetzt werden, muss man wissen, was es 

tut. Kompatibilität setzt voraus, dass man weiß, womit die neue Software kompatibel sein soll.


Angestrebte Eigenschaften der Spezifikation 

inhaltlich 

(1) zutreffend (nicht ” korrekt“!) 

(2) vollständig (relativ zu den Wünschen des Kunden) 

(3) widerspruchsfrei (oder konsistent, damit auch realisierbar) 

(4) neutral d.h. abstrakt (und damit offen für beliebigen Entwurf) 

in der Darstellung 

(5) leicht verständlich (für alle Zielgruppen!) 

(6) präzise (schließt Umgangssprache aus) 

in der Form 

(7) leicht erstellbar (was die Notationen und Modelle betrifft) 

(8) leicht verwaltbar (also auch zweckmäßig strukturiert) 

(9) objektivierbar (auch – nicht sinnvoll – ” testbar“ genannt) 

Diese Merkmale konkurrieren, d.h. die Erfüllung des einen erschwert oder 

verhindert die Erfüllung des anderen. 

2009-02-09 







inhaltlich 








in der Form 






Weil eine Anforderungsspezifikation von so tragender Bedeutung ist, streben wir eine hochqualitative an. Welche 

Eigenschaften müssen wir aber hierzu anstreben? Die anzustrebenden Eigenschaften lassen sich wie folgt 

kategorisieren: 

Den Inhalt betreffend: 

(1) zutreffend: die Anforderungen des Kunden werden richtig wieder gegeben; an manchen Stellen wird für zutreffend auch 

der Begriff korrekt synonym verwendet; wir werden aber im Folgenden den Begriff korrekt für das Verhältnis der 

Implementierung zur Anforderungsspezifikation reservieren; eine Implementierung ist dann korrekt, wenn sie die 

spezifizierten Anforderungen richtig erfüllt. Daraus kann man jedoch noch nicht unmittelbar schließen, dass die 

Implementierung auch das implementiert, was der Kunde tatsächlich will. Hierzu ist es noch notwendig, dass die 

Anforderungsspezifikation auch die Wünsche des Kunden zutreffend wiedergibt. 

(2) vollständig: alle Wünsche des Kunden werden berücksichtigt. 

(3) widerspruchsfrei (oder konsistent, damit auch realisierbar): die Anforderungen widersprechen sich nicht; würden sie sich 

widersprechen, könnte man nichts implementieren, was alle Anforderungen erfüllt. 

(4) neutral, d.h. abstrakt: die Anforderungen sind aus Sicht des Kunden formuliert und nehmen keine unnötigen technischen 

Details vorweg. Implementierungsaspekte gehören nicht in die Anforderungsspezifikation, weil sie den Kunden in der 

Regel nicht interessieren, sondern eher verwirren. Außerdem bleibt damit dem Architekten beim Entwurf ein 

größtmöglicher Gestaltungsspielraum.

2009-02-09 

2009-02-09 




Die Darstellung betreffend: 



inhaltlich 








in der Form 






(5) leicht verständlich: Die Anforderungsspezifikation ist leicht verständlich für alle Zielgruppen. Dazu gehören neben 

Entwicklern mit technischem Verständnis auch Kunden und Benutzer, die meist mit formalen Methoden und Notation 

nichts anzufangen wissen. Selbst die Verwendung der Unified Modeling Language ist für einen Kunden und Benutzer 

nicht ohne Weiteres zumutbar, auch wenn manche sie als Notation für die Kommunikation mit Kunden und Benutzern 

anpreisen. Die Vorteile einer (semi-)formalen Notation ist ihre Präzision und Prägnanz. Aus diesem Grund würde man 

sich ihren Einsatz wünschen. Wird eine solche Notation verwendet, muss der Kunde aber darin geschult werden – oder 

würden wir einen Vertrag in Hieroglyphen unterzeichnen? 

(6) präzise: die Anforderungen müssen unmissverständlich formuliert sein, sonst besteht die Gefahr, dass etwas Falsches 

implementiert wird. Dies schließt Umgangssprache, die sich durch vage Begriffe und Mehrdeutigkeiten auszeichnet, aus. 

Ebenso sollten sprachliche Weichmacher wie könnte, müsste, circa, ungefähr etc. vermieden werden. 




Die Form betreffend: 



inhaltlich 








in der Form 






(7) leicht erstellbar: die Anforderungsspezifikation ist in vielen Fällen ein sehr umfangreiches Dokument. Darum ist es 

wichtig, das es leicht erstellt werden kann. Somit ist die Auswahl geeigneter Notationen und Modelle bedeutsam. Häufig 

wird sie nicht nur von einem Autoren erstellt, so dass die Zusammenarbeit mehrerer Autoren unterstützt werden muss. 

Die Anforderungsspezifikation muss also modular aufgebaut sein. 

(8) leicht verwaltbar: die Anforderungsspezifikation muss durch zweckmäßige Strukturierung, eindeutige Referenzierbarkeit 

und explizite Querbezüge leicht überarbeitet und versioniert werden können. Idealerweise ist der Code über den Entwurf 

hin zu den Anforderungen verknüpft, um eine hohe Nachvollziehbarkeit zwischen diesen Dokumenten zu gewährleisten, 

da die Dokumente nachgeführt werden müssen, wenn sich Dinge ändern. Hierfür wurden eine Reihe von Werkzeugen, 

wie z.B. Doors, entwickelt 

(9) objektivierbar: für jede Anforderung muss es möglich sein, eine Prüfprozedur anzugeben, mit deren Hilfe man objektiv 

entscheiden kann, ob das resultierende System die Anforderung erfüllt; synonym zu objektivierbar wird häufig auch der 

Begriff testbar verwendet; dieser Begriff suggeriert jedoch, dass man das System für die Prüfung ausführen können muss 

(vgl. das Kursmodul Test); die meisten Prüfungen lassen sich aber ohne Ausführung des Systems durchführen. 

Die Anforderung ” Die Programm soll eine hohe Performanz aufweisen“ ist ein Negativbeispiel für eine objektivierbare 

Anforderung. Hier ist unklar, was ” hohe Performanz“ genau bedeutet. Statt dessen sollte die Anforderung vielmehr in 

der folgenden Weise formuliert werden: ” Die Ausgabe soll in mindestens 60 % aller Fälle nach spätestens 20 Sekunden 

erfolgen; nach höchstens 30 Sekunden soll die Ausgabe in 100 % aller Fälle erfolgen. Die Berechnung muss mit maximal 

5 MB Hauptspeicher und 100 MB Plattenplatz auskommen“. 

Leider ist es nicht immer möglich, alle diese Merkmale bei einer Anforderungsspezifikation zu erfüllen, weil die 

Merkmale konkurrieren können, das heißt die Erfüllung des einen erschwert oder verhindert die Erfüllung des 

anderen. Präzise Anforderungen sind in der Regel nur mit Hilfe formaler Spezifikationsprachen zu erreichen, die sind 

aber für einen Kunden meist nicht verständlich.


Regeln für Analyse und Spezifikation 

2009-02-09 

Ein Begriffslexikon anlegen und entwickeln 

Von der Aufgabe ausgehen, nicht von ihrer Lösung 

Daten suchen, nicht Programmabläufe beschreiben 

Abstraktionsebene nicht in einer Darstellung wechseln 

Die Spezifikation nach Aspekten organisieren 

Ein Mengengerüst bilden 

Den Kunden (Benutzer) einbeziehen 

Geeignete Sprachen und Werkzeuge verwenden 

Die Spezifikation so früh wie möglich prüfen und dem 

Konfigurationsmanagement unterstellen 

Die Spezifikation intensiv verwenden 






Um eine gute Anforderungsspezifikation zu erreichen, ist es ratsam, einige Regeln zu befolgen. 













• Ein Begriffslexikon (auch: Glossar) anlegen und entwickeln. Das Begriffslexikon beschreibt alle Begriffe, die der Kunde 

und wir benützen, die nicht unmittelbar offensichtlich sind. Die schriftliche Niederlegung der Bedeutung aller Begriffe 

zwingt uns und den Kunden zur notwendigen Präzision in unserem Dialog und hilft damit, Missverständnisse zu 

vermeiden. Hier sollten auch alle Synonyme aufgezählt werden. Im eigentlichen Inhalt der schriftlichen 

Anforderungsspezifikation sollten wir aber Synonyme vermeiden und immer nur dasselbe Wort benutzen. Die 

Anforderungsspezifikation ist kein literatisches Werk, das durch hohe Sprachvariation gefallen will, sondern soll ein 

präzises, leicht verständliches technisches Dokument sein. Unterschiedliche Worte für denselben Sachverhalten verwirren 

nur. 

• Von der Aufgabe ausgehen, nicht von ihrer Lösung. Die Anforderungsspezifkation beschreibt das zu implementierende 

System aus Sicht des Kunden. Wie das System intern implementiert wird, interessiert den Kunden nicht, sondern 

verwirrt ihn eher, weil er sich mit Implementierungsfragen in der Regel nicht auskennt. Implementierungsfragen gehören 

in ein Entwurfsdokument, wie z.B. die Architekturbeschreibung. Wir sollten den Gestaltungsraum des 

Softwarearchitekten durch die Anforderungsspezifikation nicht unnötig einschränken. 

• Daten suchen, nicht Programmabläufe beschreiben. Primär sind wir an den Daten, d.h. den Objekten, der 

Anwendungsdomäne interessiert. Sie ändern sich meist weniger als die Abläufe, in denen sie verarbeitet werden. 

Natürlich gehören zur Beschreibung in der Anforderungsspezifikation die Kommunikation zwischen den Objekten und 

welche Operationen sie prinzipiell beherrschen. Die Software muss ja Arbeitsflüsse abbilden. Wie aber diese Operationen 

intern implementiert werden (der Programmablauf) ist ein Detail der Implementierung und sollte erst später im Entwurf 

oder in der Implementierungsphase spezifiziert werden. 

• Abstraktionsebene nicht in einer Darstellung wechseln. Um den Leser zu führen statt ihn zu verwirren, sollten wir uns 

Details für vertiefende Abschnitte aufheben. Die Anforderungsspezifikation sollte so gestaltet sein, dass der Leser erst 

einen allgemeinen Überblick über alle Anforderungen an das System erhält und erst dann einen detaillierten Einblick in 

die einzelnen Anforderungen. Ein Wechsel zwischen diesen Ebenen verwirrt unnötig.

2009-02-09 

2009-02-09 

















• Die Spezifikation nach Aspekten organisieren. Die Spezifikation ist nicht selten ein Dokument mit mehreren hundert 

Seiten. Es kann nicht ohne Unterbrechung gelesen werden. Außerdem wird es von Lesern mit sehr unterschiedlichen 

Interessen gelesen. Dazu gehören auf Kundenseite neben dem Auftraggeber (auch hier gibt es meist verschiedene Rollen: 

der Auftraggeber, der für den Inhalt verantwortlich ist und der Auftraggeber, der für die Finanzierung und Termintreue 

verantwortlich ist) die verschiedenen Benutzerklassen. Auf der Seite der Hersteller wird das Dokument von den 

Architekten, den Programmierern, den Handbuchautoren und den Testern gelesen. Alle interessieren sich für 

unterschiedliche Belange. Um die vielen Arten von Lesern zu unterstützen, muss die Spezifikation uniform nach 

relevanten Aspekten organisiert werden. 

• Ein Mengengerüst bilden. Damit der Architekt eine Vorstellung über die Anforderungen an die Belastbarkeit des Systems 

erhält, um das System dafür entsprechend auszulegen, muss er wissen, mit wie vielen Daten er es zu tun haben wird. Es 

macht einen gravierenden Unterschied, ob ein System etwa 10 oder 10.000 Benutzer unterstützen muss. Damit der 

Architekt das System auch für zukünftige Anforderungen skalierbar entwerfen kann, sollten neben dem heutigen 

Mengengerüst auch realistische Prognosen gemacht werden, wie sich das Mengengerüst in Zukunft entwickeln wird. 

• Den Kunden (Benutzer) einbeziehen. Wir entwickeln für den Kunden, der uns dafür bezahlt, und für die Benutzer, die 

unser System später benutzen sollen. Ihre Belange sind Ausgangspunkt unseres Projekts. Sie können an verschiedenen 

Stellen im Entwicklungsprozess eingebunden werden, nicht nur während der Anforderungsanalyse und am Ende beim 

Akzeptanztest. Beim partizipativen Vorgehen beispielsweise werden wir in kurzen Zeitabständen Prototypen und 

verschiedene Inkremente des Systems vorführen, um ihr Feedback einzuholen. Ganz besonders benötigen wir sie aber 

während der initialen Anforderungsanalyse. Um sicher zu stellen, dass wir die Anforderungsspezifikation die Wünsche des 

Kunden und der Benutzer treffend widerspiegelt, sollte die Anforderungsspezifikation in einem Review mit Kunden und 

Benutzern abgenommen werden. 

















• Geeignete Sprachen und Werkzeuge verwenden. Die Anforderungsspezifikation sollte möglichst präzise, aber eben auch 

verständlich sein. Hierzu kann man Diagrammen benutzen. Die UML beispielsweise enthält eine Reihe von 

Diagrammtypen, mit deren Hilfe man bestimmte Aspekte verständlich und genau beschreiben kann. Für das 

Datenmodell eignen sich zum Beispiel Klassendiagramme. Es versteht sich von selbst, dass wir dem Kunden unsere 

Notation erklären müssen. Zur Erstellung des Dokuments bedient man sich am besten spezieller Werkzeuge. Neben 

herkömmlicher Editierfunktionen können uns hierbei Werkzeuge helfen, Anforderungen eindeutig zu nummerieren sowie 

Verweise einzufügen, zu verfolgen und zu prüfen. Diese Werkzeuge können uns auch einen festen Rahmen vorgeben. 

Einfache Prüfungen auf Vollständigkeit werden damit möglich. 

• Die Spezifikation so früh wie möglich prüfen und dem Konfigurationsmanagement unterstellen. Die 

Anforderungsspezifikation sollte wir selbst mit internen Reviews überprüfen. Nach Fertigstellung der 

Anforderungsspezifikation sollte mindestens eine Prüfung mit dem Kunden und den Benutzern stattfinden. Weitere noch 

frühere Prüfungen kann man mit Hilfe von Prototypen erreichen. 

Die Anforderungsspezifikation wird sich ändern, weil in Prüfungen und auch später Fehler und Lücken gefunden werden. 

Außerdem können sich bei einer längeren Projektlaufzeit Anforderungen auch noch während der Entwicklung ändern 

aufgrund geänderter Rahmenbedingungen. Zudem arbeiten meist mehrere Personen an der Anforderungsspezifikation. 

Aus diesem Grund muss die Anforderungsspezifikation von Anbeginn unter das Konfigurationsmanagement gestellt 

werden. 

• Die Spezifikation intensiv verwenden. Die Anforderungsspezifikation ist der Ausgang für alle weiteren Entwicklungen. Sie 

wird nicht nur benutzt beim Vertragsabschluss von Auftragnehmer und -geber sondern für eine Reihe weiterer Personen, 

die für die Entwicklung verantwortlich sind. Dazu gehören Architekten, Programmierer, Tester und Handbuchautoren. Es 

sollte eine Selbstverständlichkeit sein, dass diese Menschen die Spezifikation intensiv nutzen. Leider hat die Praxis 

gezeigt, dass z.B. viele Programmierer Fehler deshalb machen, weil sie die Anforderungsspezifikation niemals gelesen 

haben.

2009-02-09 

















Nachdem wir wissen, welche Qualitäten der Anforderungsspezifikation wir anstreben und welche Regeln wir 

einhalten sollen, werden wir uns nun mit ihrem Inhalt und ihrer Struktur auseinander setzen. Glücklicherweise 

haben sich dazu bereits viele Spezialisten Gedanken gemacht, die sogar in einen Standard gemündet sind. Da wir 

das Rad nicht neu erfinden wollen und die Orientierung an Standards eine gute Ingenieurstugend ist, nehmen wir 

uns diesen Standard zum Vorbild. Wir können diesen Standard als einen Rahmen für unsere Spezifikation 

verwenden und laufen so weniger Gefahr, etwas zu vergessen. 

Es handelt sich dabei um den IEEE Recommended Practice for Software Requirements Specifications, IEEE 

Standard 830.1998. Er setzt vieles von dem um, was wir bislang kennen gelernt haben. Wir werden hierzu 

Konkretisierungen und darüber hinaus führende Ergänzungen kennen lernen (Ergebnisse der Soll-Analyse, 

Datenmodell und Prognosen für zukünftige Anforderungen), die auch beschrieben sein sollten. 


Inhalt der Anforderungsspezifikation nach IEEE Standard 

830.1998 

1. Einführung 

1.1 Zweck 

1.2 Rahmen 

1.3 Definitionen, Akronyme und Abkürzungen 


1.5 Übersicht über das Dokument 

2. Allgemeine Beschreibung 

2.1 Produktperspektive 

2.2 Produktfunktionen 

2.3 Charakteristika der Benutzer 

2.4 Einschränkungen 

2.5 Annahmen und Abhängigkeiten 

3. Detaillierte Beschreibung 


2009-02-09 




Inhalt der Anforderungsspezifikation nach IEEE 

Standard 830.1998 


830.1998 


1.1 Zweck 

1.2 Rahmen 











Der Standard gibt eine dreiteilige Struktur vor: eine Einführung, eine allgemeine Beschreibung und eine detaillierte 

Beschreibung. Er folgt hierin den oben erwähnten Regeln, nach Aspekten und Detaillierungsgrad zu ordnen. Die 

Struktur bis in die zweite Gliederungsebene ist wie folgt: 


1.1 Zweck 

1.2 Rahmen 











Wir werden diese Abschnitte nun im Einzelnen im Detail kennen lernen. Ein Beispiel für eine ausführliche 

Anforderungsspezifikation finden Sie unter . . . 



830.1998 


1.1 Zweck 

Zweck der Spezifikation 

adressierte Leser 

1.2 Rahmen 

herzustellende Software mit Name 

was die Software tut und nicht tut 

Anwendung der Software mit Nutzen und Zielen 





2009-02-09 







830.1998 


1.1 Zweck 

Zweck der Spezifikation 

adressierte Leser 

1.2 Rahmen 

herzustellende Software mit Name 

was die Software tut und nicht tut 

Anwendung der Software mit Nutzen und Zielen 




Das Ziel der Einführung ist es, den Kontext und Rahmen der Anforderungsspezifikation abzustecken. Sie hat 

folgende Struktur: 

1.1 Zweck 

Dieser Abschnitt beschreibt den Zweck der Spezifikation und an welche Leser sie sich wendet. Meist geschieht dies 

durch eine kurze Beschreibung des Projektkontextes und der Ziele des Projekts. Dann folgt der Hinweis, dass in diesem 

Dokument die Anforderungen dieses System spezifiziert werden sollen und oft die Aussage, dass dieses Dokument die 

vertragliche Grundlage bildet. Für die adressierten Leser werden mindestens die konkreten Namen der Kunden und 

Vertreter möglicher Benutzer genannt. 

1.2 Rahmen 

Hier geben wir der zu erstellenden Software einen Namen und beschreiben ganz kurz, was die herzustellende Software 

leisten soll und auch, was wir explizit nicht von ihr erwarten, um gleich zu Anfang falschen Vorstellungen Einhalt zu 

gebieten. Es folgt die Beschreibung der Anwendung der Software mit ihrem Nutzen und ihren Zielen. Dieser Abschnitt 

soll nur einen ersten Überblick vermitteln, was die Software genau machen soll, folgt in den zwei nachfolgenden Kapiteln. 

Bsp.: Der PDA-basierte Einkaufsassistent, den wir als laufendes Beispiel verwenden, soll den Namen PDAss tragen. 


Hier ist er der Ort, an dem Begriffe definiert und Akronyme und Abkürzungen eingeführt werden können, die im 

weiteren Dokument benutzt werden. Damit wird der Standard unserer oben geäußerten Forderung gerecht, ein 

Begriffslexikon (Glossar) zum Ausschluss von Missverständnissen zu verwenden. 

Bsp.: Wir würden hier beispielsweise das Akronym PDA für ” Personal Digital Assistant“ erläutern. 


Hier können weitere Dokumente aufgeführt werden, die für das Verständnis der Anforderungsspezifikation hilfreich sind 

und im folgenden Text referenziert werden. Dazu sollte auch z.B. der IEEE-Standard für diese Anforderungsspezifikation 

gehören. 

Bsp.: Hier könnten wir die Fahrradherstellerkataloge und weitere Dokumente, die wir in der Ist-Analyse gefunden haben, 

nennen. 


Schließlich erfolgt hier in diesem Abschnitt eine kurze Übersicht für den Leser über die weiteren Kapitel und Abschnitte 

dieser Anforderungsspezfikation. 



830.1998 



Einbettung in ein Gesamtsystem 

2.1.1 Systemschnittstellen 

2.1.2 Benutzungsschnittstelle (logische Charakteristika. z.B. Monitorformat, 

Seiten- oder Fensterlayout, Inhalt von Berichten oder Menüs, 

Verfügbarkeit von Funktionstasten) sowie Regeln für die Schnittstelle 

2.1.3 Hardwareschnittstellen 

2.1.4 Softwareschnittstellen 

2.1.5 Kommunikationsschnittstellen (Netzwerkprotokolle etc.) 

2.1.6 Speicherbeschränkungen 

2.1.7 Betriebsoperationen (Operationsmodi, Dauer interaktiver und 

nichtinteraktiver Operationen, unterstützende 

Datenverarbeitungsfunktionen, Sicherungs- und 

Wiederherstellungsoperationen) 

2.1.8 Möglichkeiten der lokalen Anpassung 


2009-02-09 

2009-02-09 







830.1998 

















Das Kapitel 2 beschreibt Allgemeines sowie die Anforderungen im Einzelnen, ohne jedoch gleich alle möglichen 

Details zu nennen (letztere folgen im dritten Kapitel). 


Dieser Abschnitt bettet das zu implementierende System in ein Gesamtsystem ein. Dazu werden alle seine 

Schnittstellen zu anderen Systemen und zum Benutzer beschrieben sowie weitere globale Einschränkungen. 

Wir werden bei der Beschreibung der Schnittstellen feststellen, dass es nicht immer einfach ist, eine Schnittstelle 

einer der unten aufgeführten Kategorien eindeutig zuzuordnen. Im Zweifel entscheiden wir uns für eine und fügen in 

den anderen Abschnitten einen Querbezug zu dieser Beschreibung ein. Primär ist wichtig, dass die Schnittstelle 

beschrieben ist. Durch die Querbezüge stellen wir sicher, dass wir diese Beschreibung finden werden, egal in 

welchem Abschnitt wir intuitiv suchen. 


Über Systemschnittstellen ist das zu implementierende System mit anderen Systemen verbunden, mit denen es 

zusammen arbeiten soll. Dazu gehören z.B. Import- und Exportschnittstellen für den Datenaustausch, 

Scripting-Schnittstellen, über die sich das System programmieren lässt, sowie Application Interfaces (API), über das 

man das System programmatisch steuern kann. 

Bsp.: Hier könnten wir für PDAss fordern, dass man die Herstellerkataloge in einem zu definierenden elektronischen 

XML-basierten Format einlesen können soll. 







830.1998 

















2.1.2 Benutzungsschnittstelle 

Eine besondere Schnittstelle ist die, die dem Benutzer angeboten wird. Die detaillierte Beschreibung dieser Schnittstelle 

erfolgt in Abschnitt 3.1.1. Hier werden lediglich die logischen Charakteristika der Schnittstelle erläutert, z.B. das 

Monitorformat, das Seiten- oder Fensterlayout, den Inhalt von Berichten oder Menüs oder die Verfügbarkeit von 

Funktionstasten. Außerdem werden alle relevanten Regeln für das Design der Schnittstelle genannt, wie z.B. die 

allgemeinen (in aller Regel ohnehin verbindlichen) Richtlinien der Norm EN ISO 9241-10:1995 (1995) für die 

Gebrauchstauglichkeit von Software. Die Angaben müssen aber hinreichend konkretisiert werden. Diese Regeln können 

auch eine einfache Liste von “Dos and Don’ts” sein, wie sich die Schnittstelle dem Benutzer darstellen soll. 

Beispielsweise ob kurze oder lange Fehlermeldungen vorzuziehen sind. In jedem Fall gilt auch hier, dass die 

Anforderungen objektivierbar sein müssen. Statt ” benutzerfreundlich“ sollte es also besser ” Persona X kann die Funktion 

Sortiment einsehen in zwei Minuten ausführen (nach einer Schulung von zehn Minuten)“ heißen. 

Charakteristika der Benutzer werden in Abschnitt 2.3 angegeben. 

Bsp.: Hier würden wir z.B. die Auflösung des PDA-Monitors für PDAss, die Farbtiefe, die Eingabemöglichkeiten über 

Stift und nur wenige Tasten und die minimalen Schriftgrößen etc. angeben. 


Hardwareschnittstellen sind Schnittstellen zu Hardware, die das System voraussetzt beziehungsweise bedient. Dieser 

Abschnitt ist insbesondere für eingebettete Systeme von großer Bedeutung. Für alle Arten von Systemen würde man 

hier aber die zu unterstützenden Prozessortypen beschreiben, auf denen die Software später laufen soll. Hardware, die 

eher der Benutzungsschnittstelle zuzuordnen ist, wird in Abschnitt 2.1.2 beschrieben.

2009-02-09 

2009-02-09 







830.1998 


















Softwareschnittstellen sind Schnittstellen zu Software, die Bestandteil des System werden soll. Dazu gehören 

Betriebssysteme, höhere Dienste wie z.B. Datenbanken sowie wiederverwendbare Bibliotheken, die eingebunden werden 

sollen. 

Wir erinnern uns, dass Implementierungsdetails eigentlich nicht in die Anforderungsspezifikation gehören. Insofern dürfen 

wir nur solche Softwareschnittstellen hier aufzählen, die tatsächlich von Interesse für den Kunden sind, z.B. dann wenn 

er diese Software bereits einsetzt und in diesem Kontext wieder verwenden möchte bzw. wenn sich aus ihrer Verwendung 

weitere lizenzrechtliche Aspekte für den Kunden ergeben würden. 

Bsp.: Der Ladenverkäufer hat eine MySQL-Datenbank der Version 4.1 bereits im Einsatz und besteht darauf, dass 

unsere Software alle persistenten Daten darin speichern soll. 

2.1.5 Kommunikationsschnittstellen 

Sofern das System mit anderen Systemen über ein Netzwerk kommuniziert, beschreiben wir hierfür die 

Kommunikationsschnittstelle sowie Netzwerkprotokolle etc. Auch hier gilt wieder, dass nur solche Schnittstellen 

interessieren, die zu anderen Systemen führen beziehungsweise für die der Kunde sorgen muss, damit unser System 

arbeiten kann. Ist eine solche Schnittstelle vollständig intern und wird von uns mitgeliefert, handelt es sich um ein 

Implementierungsdetail, das wir nicht in der Anforderungsspezifikation nennen. 

Bsp.: Wir wollen den PDA mit dem Ladenrechner über WLAN kommunizieren lassen. Wir setzen voraus, dass der Kunde 

für das WLAN in seinem Laden sorgt. Dann wäre WLAN mit einem Netzwerkprotokoll wie TCP/IP in der 

Anforderungsspezifikation zu erwähnen. Wir dürfen dann in unserer Implementierung voraussetzen, dass die 

Ausführungsumgebung diese Komponenten bereit hält. 


Hier nennen wir die mindestens verfügbare Größe des Hauptspeichers und der Festplatten, die das korrekte Funktionieren 

unserer Software voraussetzen darf. Anforderungen an die Laufzeit werden im Kontext der Operationen festgelegt. 







830.1998 

















2.1.7 Betriebsoperationen 

Neben den eigentlichen Produktfunktionen bietet ein System meist noch eine Menge allgemeiner Operationen, die für 

den Betrieb der Software notwendig oder hilfreich sind. Dazu gehören beispielsweise unterstützende 

Datenverarbeitungsfunktionen (wie z.B. Konsistenzprüfungen oder allgemeine Statistiken über die Datenvolumen) sowie 

Sicherungs- und Wiederherstellungsoperationen. Außerdem unterstützen viele Systeme verschiedene Operationsmodi, in 

denen unterschiedliche Produktfunktionen und Betriebsoperationen verfügbar beziehungsweise nicht verfügbar sind. 

Beispielsweise bietet eine Bank-Software einen Wartungsmodus, während dessen Kunden keine Transaktionen 

veranlassen können, weil Jahresabschlüsse berechnet werden. 

In diesem Abschnitt werden diese allgemeinen Betriebsoperationen, die relevanten Operationsmodi und die Dauer und 

Häufigkeit interaktiver und nichtinteraktiver Operationen aufgeführt. 


Systeme bieten häufig die Möglichkeit, dass Benutzer lokale Anpassungen vornehmen können. Diese werden hier 

beschrieben. 

Bsp.: Der Ladenbesitzer soll beispielsweise einstellen können, wie viele Benutzer maximal gleichzeitig auf den 

Ladenrechner zugreifen dürfen. 

Die Norm ISO 9241-11:1998 (1998) weist Individualisierbarkeit als anzustrebendes Qualitätsmerkmal aus. Beispielsweise 

sollen Schriftgrößen einstellbar sein. Möglichkeiten der lokalen Anpassung der Benutzungsschnittstelle werden jedoch in 

Abschnitt 2.3 beschrieben.



830.1998 


Zusammenfassung der Funktionen 


Bildungsstand, Erfahrung, technische Kenntnisse 


Beispiele: 

Gesetzliche Rahmenbedingungen 

Hardwarebeschränkungen 

parallelisierte Ausführung 

erforderliche Zuverlässigkeit 

sicherheitskritische Aspekte 

Datenschutzaspekte 


z.B. Betriebssystem ist auf Hardware verfügbar 

2009-02-09 








830.1998 


Zusammenfassung der Funktionen 


Bildungsstand, Erfahrung, technische Kenntnisse 


Beispiele: 

Gesetzliche Rahmenbedingungen 

Hardwarebeschränkungen 

parallelisierte Ausführung 

erforderliche Zuverlässigkeit 

sicherheitskritische Aspekte 

Datenschutzaspekte 


z.B. Betriebssystem ist auf Hardware verfügbar 


Hier werden alle Produktfunktionen, die unterstützt werden sollen, kurz zusammengefasst. Ihre Detaillierung folgt in 

Kapitel 3. 


In diesem Abschnitt werden die Charakteristika der Benutzer beschrieben. Dies kann in Form der oben eingeführten 

Personas geschehen. Alle für uns als Entwickler relevanten Details sollten erwähnt werden. Dazu gehören meist der 

Bildungsstand, die Erfahrung und vorhandene technische Kenntnisse. 


Alle maßgebenden Einschränkungen, die die Entwicklung betreffen, werden in diesem Abschnitt aufgeführt. Dazu 

gehören sowohl die so genannten nicht-funktionalen Produktattribute als auch organisatorische Rahmenbedingungen. 

Hier sind zum Beispiel gesetzliche Rahmenbedingungen, weitere Hardwarebeschränkungen, Zwang zur parallelisierten 

Ausführung, erforderliche Zuverlässigkeit, sicherheitskritische Aspekte sowie Aspekte des Datenschutzes zu nennen. 


Unsere Entwicklung startet oft mit Annahmen, bei denen wir zum gegenwärtigen Zeitpunkt nicht sicher sind, ob sie 

zutreffen. Wenn die Entwicklung von solche Annahmen abhängt, stellen die Annahmen ein Risiko dar, das wir in diesem 

Abschnitt explizit benennen. Der Architekt kann dann versuchen, die potentiellen Auswirkungen dieser Risiken im 

Architekturentwurf zu minimieren. 

Jede Abhängigkeit von Dritten stellt ein weiteres Risiko dar. Sie führen zur Annahme, dass die, von denen wir abhängen, 

die von uns erwünschte Leistung erbringen. Aus diesem Grund werden alle Abhängigkeiten hier auch explizit aufgeführt.



830.1998 


3.1 Externe Schnittstellen 


3.1.2 Hardwareschnittstelle 

3.1.3 Softwareschnittstelle 

3.1.4 Kommunikationsschnittstelle 


3.3 Performanzanforderungen 

3.4 Entwurfseinschränkungen 

z.B. Standards 

3.5 Softwaresystemattribute 

z.B. Zuverlässigkeit, Verfügbarkeit, Sicherheit, Wartbarkeit, 

Portabilität 

3.6 Andere Anforderungen 

2009-02-09 








830.1998 













Portabilität 


Den größten Anteil der Anforderungsspezifikation nimmt das Kapitel 3 ein, in dem die Anforderungen in größerem 

Detail beschrieben werden. 



In den vier folgenden Abschnitten werden die verschiedenen Schnittstellen im Detail beschrieben. Auf die Spezifikation 

der Benutzungsschnittstelle gehen wir an dieser Stelle besonders ein. 


Die Benutzungsschnittstelle kann durch einen GUI-Prototypen beschrieben werden. Wenn dieser ausführbar ist, 

dann werden im Text hier die wesentlichen Interaktionskonzepte beschrieben; ansonsten wird auf den 

ausführbaren Prototypen verwiesen, der vom Kunden abgenommen sein muss. Ist der GUI-Prototyp nicht 

ausführbar, dann kann man hier die Screenshots und Skizzen einfügen, die in der Soll-Analyse erstellt wurden, 

um die Benutzungsschnittstelle vorzuführen. Es genügt jedoch nicht, nur Bildschirmmasken aufzulisten. Es muss 

auch der Zusammenhang der Dialoge und der anderen Interaktionselementen mit den Anwendungsfällen (d.h. 

der Funktionalität im Kontext des Arbeitsflusses, der unterstützt werden soll) beschrieben werden. Für jede 

Eingabemöglichkeit muss beschrieben sein, was damit ausgelöst werden kann und welche Ausgabe erfolgt. 

Ebenso muss die Navigation zwischen allen Dialogen und etwaige Zustände der Schnittstelle beschrieben sein. 

Die Beschreibung soll so genau sein, dass man daraus ohne weitere Schritte ein Benutzerhandbuch erstellen 

kann. Die Entscheidung, wie die Benutzungsschnittstelle auszusehen hat, liegt also nicht beim Programmierer 

später, sondern steht von Anfang an fest. 





In diesem Abschnitt werden die Produktfunktionen im Detail beschrieben. Dieser Abschnitt bildet in der Regel mit der 

Benutzungsschnittstelle zusammen den umfangreichsten Teil. Deshalb ist eine sinnvolle Glieder unabdingbar. Wir werden 

weiter unten auf alternative Gliederungen eingehen. Der Zusammenhang zwischen Benutzungsschnittstellen (sowie allen 

anderen Schnittstellen) und der hier beschriebenen Produktfunktionen muss klar gemacht werden.

2009-02-09 

2009-02-09 







830.1998 













Portabilität 



Funktionale Anforderungen beschreiben die erwartete Ausgabe auf eine Eingabe hin. Bei Echtzeitsystemen mit harten 

Deadlines muss nicht nur die erwartete Ausgabe angegeben werden, sondern auch nach welcher Zeit die Antwort 

erfolgen muss, da sie ansonsten nicht mehr gebraucht wird. Bei Systemen ohne Echtzeitanforderungen hingegen werden 

zeitliche Aspekte häufig nicht explizit angegeben. Das ist jedoch falsch. Denn auch bei interaktiven Systemen erwarten 

wir eine zeitnahe Reaktion des Systems auf unsere Eingabe hin, weil wir das Programm sonst nicht verwenden wollen. 

Erfolgen keine konkreten Angaben zur maximalen Reaktionszeit ist es schwer, über die Vertragserfüllung bei der Abgabe 

zu diskutieren. Deshalb sollte man grundsätzlich Aussagen zur erforderlichen Performanz jeder Funktionalität machen. 

Dies kann relativ zum Datenvolumen erfolgen oder in absoluten Zeitangaben. Im letzteren Fall nimmt das Mengengerüst 

eine noch gewichtigere Stellung ein. Denn nur durch das Mengengerüst können wir zu absoluten Zeiten kommen, die 

später überprüfbar sind. 

In diesem Abschnitt ist der Platz für die Beschreibung der Performanzanforderungen aller Produktfunktionen. Alternativ 

kann man diese Anforderungen auch bei der Beschreibung der Produktfunktionen angeben und dann auf diesen 

Abschnitt verzichten. Das Prinzip der Trennung von Aspekten, dem wir bei einer Anforderungsspezifikation folgen, legt 

aber einen eigenen Abschnitt nahe. Die Beschreibung kann z.B. durch einfache Tabellen erfolgen, in denen die 

Produktfunktionen aufgeführt sind und die maximale Reaktionszeit in Abhängigkeit der Eingabe angegeben wird. 


Implementierungsdetails gehören – wie schon mehrfach gesagt – nicht in die Anforderungsspezifikation. Es gibt aber 

dennoch häufig Aspekte, die beim Entwurf berücksichtigt werden müssen. Dazu gehören z.B. Standards, an die sich die 

Software halten muss. In der Luft- und Raumfahrt beispielsweise gibt es Codierungsstandards wie MISRA, deren 

Einhaltung zuverlässigere Systeme verspricht. Hersteller von Software müssen sich an solche Standards halten, sonst 

wird ihr System nicht verwendet. In diesem Abschnitt werden aus diesem Grund alle weiteren Einschränkungen des 

Entwurfs beschrieben, sofern sie aus Kundensicht relevant sind. 







830.1998 













Portabilität 



Neben Performanzanforderungen gibt es noch weitere Systemattribute, zu denen die Anforderungsspezifikation Aussagen 

machen muss. Dazu gehören Zuverlässigkeit, Verfügbarkeit, Sicherheit, Wartbarkeit, Portabilität und weitere 

Softwarequalitäten (oft auch nichtfunktionale Anforderungen genannt). Wir werden weiter unten noch darauf zu 

sprechen kommen, dass diese Art Anforderungen konkret beschrieben werden müssen. Die Forderung ” Das System muss 

sicher sein“ ist viel zu allgemein als dass man sie erfüllen könnte. 


In diesem Abschnitt können weitere relevante Anforderungen beschrieben werden, die in keine der oben genannten 

Abschnitte passen.

2009-02-09 




Ergänzungen zum Standard: 




830.1998 













Portabilität 


Die Anforderungsspezifikation nach IEEE Standard 830.1998 verlangt nirgendwo, dass die Ergebnisse der 

Ist-Analyse beschrieben werden sollen. Diese Ergebnisse sind jedoch wichtig, um die Anforderungen zu verstehen 

und einschätzen zu können. Man sollte deshalb entweder ein eigenes Dokument hierfür anlegen, das in der 

Anforderungsspezifikation referenziert wird, oder aber im Einführungskapitel einen entsprechenden Abschnitt 

verfassen. 

Außerdem weist der Standard an keiner Stelle darauf hin, dass auch die möglichen zukünftigen Änderungen der 

Anforderungen beschrieben sein sollten. Diese sind jedoch wichtig, damit der Architekt die Architektur so entwerfen 

kann, dass diese Änderungen – so sie eintreffen – relativ einfach umgesetzt werden können. Aus diesem Grunde 

empfiehlt sich in Kapitel 2 beziehungsweise Kapitel 3 (je nach Detaillierungsgrad) ein Abschnitt zu zukünftigen 

Entwicklungen der Anforderungen. 

Im Datenmodell modellieren wir die Objekte der Anwendungsdomäne, die für die Beschreibung unserer 

Anforderungen relevant sind. Im Standard wird kein Ort explizit genannt, an dem das Datenmodell beschrieben 

werden soll. Hier bietet sich ein Unterabschnitt in Abschnitt 2.2 an. 


Softwaresystemattribute 

Softwaresystemattribute: 

versus: 

oft als nicht-funktionale Anforderungen bezeichnet 

müssen objektivierbar sein 

Das System soll sicher sein. 

PGP-Verschlüsselung wird verwendet 

Logging aller Aktionen 

Nachrichten dürfen nur über Verschlüsselungskomponente geschehen 

Indizierte Zugriffe auf Felder müssen zur Laufzeit geprüft werden 


2009-02-09 






Softwaresystemattribute: 

versus: 

oft als nicht-funktionale Anforderungen bezeichnet 

müssen objektivierbar sein 

Das System soll sicher sein. 

PGP-Verschlüsselung wird verwendet 

Logging aller Aktionen 

Nachrichten dürfen nur über Verschlüsselungskomponente geschehen 

Indizierte Zugriffe auf Felder müssen zur Laufzeit geprüft werden 

Wie oben beim Abschnitt 3.5 Softwaresystemattribute erwähnt sind neben den funktionalen Anforderungen auch 

die so genannten nicht-funktionalen Anforderungen, wie Portierbarkeit etc., zu beschreiben. Wie wir auch schon 

oben diskutiert haben, sollen alle Anforderungen überprüfbar sein. Das heißt die Aussagen zu den 

nicht-funktionalen Eigenschaften müssen so genau und konkret sein, dass man eine Prüfprozedur angeben kann, um 

bei Auslieferung überprüfen zu können, ob die Anforderung erfüllt wurde. Die Forderung ” Das System muss sicher 

sein“ genügt diesem Anspruch nicht, weil nicht klar ist, wogegen das System gesichert werden soll. Konkreter sollte 

man also etwa fordern: 

• Alle Netzwerktransaktionen werden mit PGP verschlüsselt. 

• Alle Operationen des Administrators werden aufgezeichnet. 

• Alle Benutzer müssen sich mit einem mindestens acht Zeichen langen Passwort authentifizieren. 

Diese Aussagen sind überprüfbar. Interessanterweise stellen wir an dieser Stelle fest, dass aus den so genannten 

nicht-funktionalen Eigenschaften durch die Konkretisierung funktionale Eigenschaften werden können. Die 

Trennung in funktionale und nicht-funktionale Eigenschaften ist also etwas künstlich bei allen Eigenschaften, die 

externe Eigenschaften betreffen. Externe Eigenschaften sind solche, die der Benutzer direkt wahrnehmen kann. 

Interne Eigenschaften betreffen vielmehr den inneren Aufbau. 



versus: 

Das System soll portierbar sein. 

Anteil der plattformabhängigen Komponenten < 2% 

Anteil der plattformabhängigen Codezeilen < 5% 

Verwendung einer portierbaren Hochsprache 

Einschränkung auf portierbare Sprachkonstrukte 

Verwendung eines verbreiteten Betriebssystems 


2009-02-09 






versus: 

Das System soll portierbar sein. 

Anteil der plattformabhängigen Komponenten < 2% 

Anteil der plattformabhängigen Codezeilen < 5% 

Verwendung einer portierbaren Hochsprache 

Einschränkung auf portierbare Sprachkonstrukte 

Verwendung eines verbreiteten Betriebssystems 

Aber auch Anforderungen zu inneren Eigenschaften der Software müssen hinreichend genau angegeben sein. Die 

Aussage ” Das System soll portierbar sein“, die eine innere Qualität darstellt, kann nicht überprüft werden, weil 

nicht klar ist, wohin portiert werden soll und was Portierbarkeit genau bedeuten soll. Besser muss angegeben 

werden, auf welcher Hardware und für welches Betriebssystem die Software portiert werden soll. Dann muss der 

Begriff portierbar konkretisiert werden, z.B. auf die folgende Weise: 

• Der Anteil der plattformabhängigen Komponenten soll weniger als 2% ausmachen. 

• Der Anteil der plattformabhängigen Codezeilen soll weniger als 5% sein. 

• Es soll eine Hochsprache als Implementierungssprache verwendet werden, die auf allen Plattformen verfügbar ist, auf die 

portiert werden soll. 

• Alle verwendeten Konstrukte der Programmiersprache müssen auf allen Zielplattformen verfügbar sein. 


Präsentation der Anforderungen 

Funktionale Anforderungen geordnet nach: 

Operationsmodus 

z.B. Kontrollsysteme: Training, Normal, Notfall 

Benutzerklassen 

z.B. Fahrzeugsteuerung: Fahrer, Fahrgäste, Wartungstechniker 

Objekte und Klassen 

z.B. Patientenmonitorsystem: Patienten, Sensoren, Pflegepersonal, 

Räume, 

Ärztinnen, Medizin 

jede Klasse wird beschrieben durch ihre Attribute und Methoden 

Features oder auch Anwendungsfälle (gewünschter nach außen 

sichtbarer Service) 

z.B. Telefonsystem: Nahgespräch, Weiterleitung, Konferenzgespräch 

Stimuli (bei reaktiven Systemen) 

z.B. Landesystem eines Flugzeugs: Energieverlust, Windwechsel, 

Schlingern 


2009-02-09 






Funktionale Anforderungen geordnet nach: 

Operationsmodus 

z.B. Kontrollsysteme: Training, Normal, Notfall 

Benutzerklassen 

z.B. Fahrzeugsteuerung: Fahrer, Fahrgäste, Wartungstechniker 

Objekte und Klassen 

z.B. Patientenmonitorsystem: Patienten, Sensoren, Pflegepersonal, 

Räume, Ärztinnen, Medizin 

jede Klasse wird beschrieben durch ihre Attribute und Methoden 

Features oder auch Anwendungsfälle (gewünschter nach außen 

sichtbarer Service) 

z.B. Telefonsystem: Nahgespräch, Weiterleitung, Konferenzgespräch 

Stimuli (bei reaktiven Systemen) 

z.B. Landesystem eines Flugzeugs: Energieverlust, Windwechsel, 

Schlingern 

Wie oben erwähnt, kommt der Strukturierung des Abschnitts 3.2 Produktfunktionen eine große Bedeutung zu. 

Dieses Kapitel ist sehr umfangreich und alle Leser sollen sich möglichst einfach darin zurecht finden. 

Welche Kategorisierung zu verwenden ist, hängt von der Art der Anwendung ab. Bei reaktiven Systemen, also z.B. 

Steuerungssystemen, kann man nach den Stimuli gruppieren, auf die die Software reagieren muss. Bei einer 

Software, die das Landen eines Flugzeugs steuert, könnte man z.B. nach plötzlichem Energieverlust, Windwechsel 

oder Schlingern etc. ordnen. Zu den allgemeineren Ordnungskriterien, die bei sehr vielen Arten von Systemen 

Anwendung finden können, zählen Operationsmodi. Kontrollsysteme haben z.B. häufig die Operationsmodi 

Training, Normal und Notfall. Ein weiteres allgemeines Kriterium ist das der Benutzerklassen. Die Software eines 

Busses könnte unterscheiden in Produktfunktionen, die Fahrer, Fahrgäste oder Wartungstechniker betreffen. Bei 

objektorientiertem Vorgehen ergeben sich in der Analyse Objekte und Klassen, nach denen man gruppieren könnte. 

In einem Patientenmonitorsystem erwarten wir als Klassen z.B. Patienten, Sensoren, Pflegepersonal, Räume, 

Ärztinnen, Medizin. Jede dieser Klassen wird dann beschrieben durch ihre Attribute und Nachrichten, die sie 

versteht. Schließlich können wir auch nach Anwendungsfällen kategorisieren. Bei einem Telefonsystem wären das 

zum Beispiel das Nahgespräch, die Weiterleitung und das Konferenzgespräch. 

Wie immer man sich entscheidet, man sollte in jedem Falle die Kategorisierung uniform anwenden. Es kann 

dennoch sinnvoll sein, Kategorien zu kombinieren, was kein Widerspruch zur Uniformität sein muss. Dem Ziel der 

Uniformität genügend könnte man z.B. auf erster Ebene nach Benutzerklassen ordnen und auf zweiter Ebene nach 

Anwendungsfällen. 



Was ist an der Erhebung der Anforderungen so schwierig? 

Erläutern Sie das Kano-Modell. Was folgt daraus für die 

Anforderungsspezifikation? 

Wozu dient die Anforderungsspezifikation und welche Folgen haben 

ihre Mängel? 

Was sind die Schritte der Anforderungsspezifikation? 

Was sind Personas und welches Ziel wird mit ihnen verfolgt? 

In welchen Phasen des Entwicklungsprozesses können Personas 

verwendet werden? 

Was ist das Ziel der Ist-Analyse und aus welchen Schritten besteht 

sie? 

Erläutern Sie Techniken zur Ist-Analyse. Bewerten Sie sie. 

Insbesondere: Auf welchen Prinzipien basiert das Interview im 

Kontext und wie wird es durchgeführt? 




Welche Arten des Prototypings gibt es und wozu dienen sie? 

Wegwerf-, technischer und evolutionärer Prototyp 

horizontaler versus vertikaler Prototyp 

passive, aktive, interaktive Storyboards 

Welche Eigenschaften der Anforderungsspezifikation streben wir an? 

Welche Bestandteile hat eine Anforderungsspezifikation? 

Welche Systemattribute spielen in der Anforderungsspezifikation eine 

Rolle und worauf ist bei ihrer Spezifikation zu achten? 


Objektorientierte Modellierung 





Ablauf 

Zeitplan 

Anmeldung 




Kontaktdaten 

Ressourcen 

Lehrbücher 








Lernziele 

objektorientiert modellieren können 

wesentliche Konstrukte der Unified Modeling Language (UML) lesen 

und anwenden können 

Anmerkung: kein UML-Kurs; zur UML siehe z.B.: Störrle (2005). 



Modellierung 

Was ist ein Modell? 

Abbild eines Originals 

Wozu modellieren wir? 

um etwas zu verstehen 

um Vorhersagen machen zu können 

um etwas zu dokumentieren 

Wann modellieren wir? 

jederzeit: Projektplan, Anforderungen, Architektur, . . . 




Ausgehend von Geschäftsprozessen. . . 

2009-02-09 

Identifiziere Aktoren 

Beschreibe Anwendungsfälle 

Bestimme statisches Modell 

Identifiziere Objekte 

Identifiziere Eigenschaften der Objekte 

Bestimme Assoziationen zwischen Objekten 

Fasse Objekte zu Klassen zusammen 

Ordne Klassen in Vererbungshierarchien ein 

Bestimme Multiplizitäten der Assoziationen 

Erstelle Verhaltensmodell 

Identifiziere Ereignisse und modelliere Interaktionen in 

Anwendungsfällen 

Identifiziere Verhalten der Objekte 

Beschreibe das Verhalten (Vor- und Nachbedingungen) 






Dies ist keine streng sequenzielle Folge. Die Aktivitäten verlaufen vielmehr parallel und iterativ. 


Ausgehend von Geschäftsprozessen. . . 

Identifiziere Aktoren 

Beschreibe Anwendungsfälle 

Bestimme statisches Modell 

Identifiziere Objekte 

Identifiziere Eigenschaften der Objekte 

Bestimme Assoziationen zwischen Objekten 

Fasse Objekte zu Klassen zusammen 

Ordne Klassen in Vererbungshierarchien ein 

Bestimme Multiplizitäten der Assoziationen 

Erstelle Verhaltensmodell 

Identifiziere Ereignisse und modelliere Interaktionen in 

Anwendungsfällen 

Identifiziere Verhalten der Objekte 

Beschreibe das Verhalten (Vor- und Nachbedingungen)


Ist → Soll 

Schwierig: Dinge im Abstrakten beschreiben. 

Einfacher: von konkreten Geschäftsprozessen ausgehen. 

Definition 

Ein Geschäftsprozess ist eine Folge von Schritten oder ein Rezept, um 

ein Geschäftsresultat zu erzielen. 



Prosaische Geschäftsprozessbeschreibung im Fahrradladen 

Geschäftsprozess Einkauf 

Kunde König möchte Flaschenhalter kaufen; besitzt mehrere 

Fahrräder 

König tritt in den Laden und zückt sein PDA 

PDA bietet alle Räder des Kunden an 

König wählt sein 28”-Rennrad mit Rahmen-Standardbohrung aus; 

Rahmenfarbe: magenta 

König wählt “Hinzufügen” aus 

König gibt “Flaschenhalter” ein und quittiert 

PDA nimmt Verbindung mit Laden-Host-Rechner auf 

PDA übermittelt Anfrage für Flaschenhalter (verschlüsselt!) 

Host-Rechner übermittelt Sortiment Flaschenhalter (verschlüsselt!) 

PDA prüft auf Verträglichkeit mit ausgewähltem Rad 



Beispiel Fahrradladen (Forts.) 

Geschäftsprozess Einkauf (Forts.) 

PDA präsentiert alle Flaschenhalter, die passen (hartes Kriterium) 

König deselektiert alle Flaschenhalter mit unpassender Farbe (weiches 

Kriterium) 

König lässt nach Preis sortieren 

König wählt Flaschenhalter in bestimmtem Preissegment aus 

König geht mit Auswahl zu Verkäufer 

Verkäufer Volker betrachtet Auswahl und berät 



Geschäftsprozess und Anwendungsfall (Use-Case) 

Merkmale von Geschäftsprozessen: 

systemübergreifend, 

unterbrechbar, 

lang laufend, 

erfordern fortlaufende Interaktion zwischen vielen Akteuren, 

bestehen aus Anwendungsfällen. 

Definition 

Anwendungsfall (auch: Nutzfall) 

beschreibt eine Menge von Aktionssequenzen (Varianten 

eingeschlossen) 

jede Sequenz repräsentiert die Interaktion zwischen externen Aktoren 

mit dem System 

Folge ist beobachtbares Resultat, relevant für Aktor 



Aktor 

Definition 

Aktor 

Beispiel: 

repräsentiert eine kohärente Menge von Rollen, die von Benutzern in 

der Interaktion mit dem System eingenommen werden können 

können Menschen und andere Dinge sein (z.B. andere automatisierte 

Systeme) 

Geschäftsprozess Einkauf im Fahrradladen 

ein Anwendungsfall darin: Kunde verbindet seinen PDA mit dem 

Ladenrechner 

→ Akteure: Kunde, Ladenrechner 



Textuelle Beschreibung von Anwendungsfällen 

Name: Artikelergänzung 

Aktoren: 

Kunde und Verkäufer 

Vorbedingung: 

Kunde möchte ergänzenden Artikel kaufen 

Kunde und Verkäufer sind im Laden 

PDA und Ladenrechner sind verbunden 

Nachbedingung: 

Kunde hat Artikel ausgewählt 

Ablauf: 

1 Kunde wählt zu ergänzenden Artikeltyp für Rad R aus 

2 Ladenrechner liefert alle Artikel dieses Typs, die zu R passen 

3 Kunde wählt aus dieser Liste aus 

Varianten: 

Kunde findet keinen passenden Artikel 

→ Verkäufer berät Kunde 

keine Verbindung zwischen PDA und Ladenrechner 

→ Verkäufer berät Kunde 



Aktoren und Anwendungsfälle 

1 Identifiziere Aktoren 

2 Betrachte System aus der Sicht der Aktoren 

3 Bestimme Anwendungsfälle für Aktoren 

→ liefert möglicherweise neue Aktoren 

4 zurück zu 1, bis keine neuen Aktoren/Anwendungsfälle mehr 

gefunden werden können 



UML-Notation für Anwendungsfälle (OMG) 

obsoletes 

Produkt 

entfernen 

Passendes 

Produkt 

finden 

Waren− 

sortiment 

pflegen 

Anwendungsfall 

Assoziation 

Kunde Verkäufer 

System 

Aktor 


2009-02-09 



UML-Notation für Anwendungsfälle 



Assoziationen werden in Anwendungsfalldiagrammen nicht benannt. Assoziationen sind keine Datenflüsse; 

Assoziationen beschreiben Kommunikationsbeziehungen zwischen Aktoren und dem System. 


Aktoren und Anwendungsfälle 

Strukturiere Anwendungsfälle 

obsoletes 

Produkt 

entfernen 

Passendes 

Produkt 

finden 

Kunde Verkäufer 

Waren− 

sortiment 

pflegen 


Aktor 

Assoziation 

1 identifiziere gemeinsame Anteile in Anwendungsfällen und faktorisiere 

entsprechend 

2 fasse ähnliche Anwendungsfälle und Aktoren in Vererbungshierarchien 

zusammen 


System



2009-02-09 

Waren− 

sortiment 

pflegen 

Kunden− 

daten 

pflegen 

 

 

Passwort− 

abfrage 

Authentifizierung 

inherits 

Person 

Retinatest 

Verkäufer 

Ladenbesitzer 







 

Authentifizierung 

Mit Hilfe von kann man gemeinsames Verhalten aus Anwendungsfällen herausfaktorisieren und nur 

einmal beschreiben; hilft, Redundanz zu vermeiden. 

Bedeutung B A: 

• Anwendungsfall B (Base) inkludiert das Verhalten von Anwendungsfall A (Inklusion) 

• Anwendungsfall B ist ohne Inklusion A nicht notwendigerweise ein vollständiger Anwendungsfall 

• Inklusion B kann ein Fragment sein 

Verwendung 

• Verhalten von Inklusion A wird in mehreren Anwendungsfällen benötigt 

Generalisierung: Anwendungsfälle können durch die inherit-Beziehung spezialisiert werden. Entspricht der 

objektorientierten Vererbung. 

Bedeutung 

• Anwendungsfall A (Child) erbt das Verhalten von Anwendungsfall B (Parent) 

• Anwendungsfall B ist ein vollständiger, von A unabhängiger Anwendungsfall 

• Anwendungsfall A ist ein vollständiger Anwendungsfall 

Verwendung 

• Verhalten eines Anwendungsfalls wird spezialisiert 

Waren− 

sortiment 

pflegen 

Kunden− 

daten 

pflegen 

Passwort− 

abfrage 

inherits 

Person 

Retinatest 

Verkäufer 

Ladenbesitzer



Spezialanwendungsfall 

2009-02-09 

Express− 

bestellung 

Erweiterungsrelation 

 

(setze Priorität) 

ausführen Bestellung 

ausführen 

Extension Points: 

Priorität setzen 

Basisanwendungsfall 

Variationspunkt 







Express− 

bestellung 

Spezialanwendungsfall 

Erweiterungsrelation 

 

(setze Priorität) 

ausführen Bestellung 

ausführen 

Extension Points: 

Priorität setzen 

Basisanwendungsfall 

Extend-Relation erlaubt die Beschreibung optionalen Verhaltens. Erlaubt damit die Trennung des optionalen vom 

notwendigen Verhalten. Kann auch benutzt werden, um ein alternatives Teilverhalten zu beschreiben, das an 

Bedingungen geknüpft ist (z.B. Fehlerausgabe und Benachrichtigung des Systemadministrators falls Passwort falsch 

ist). Kann auch verwendet werden, um Teilsequenzen zu kombinieren, deren Ausführung vom Benutzer bestimmt 

wird (z.B. Dialog zur Auswahl von Operationen). 

Bedeutung: A B: 

• Anwendungsfall A (Extension) erweitert das Verhalten von Anwendungsfall B (Base) 

• Anwendungsfall B ist auch ohne Extension A ein vollständiger Anwendungsfall 

• Extension A kann ein Fragment sein 

Verwendung 

• Verhalten eines Anwendungsfalls wird erweitert 

Variationspunkt


Beschreibung von Anwendungsfällen 

Anwendungsfalldiagramme: 

deklarieren voneinander unabhängige Anwendungsfälle 

beschreiben die Einbettung der Anwendungsfälle in den 

Systemkontext (externe Akteure) 

beschreiben (konkretisieren) die Anwendungsfälle jedoch nicht 

→ folgt später 

sind Ausgangspunkt für die objektorientierte Modellierung 

statische Eigenschaften (Attribute) 

dynamische Eigenschaften (Verhalten) 



Beispiel Fahrradladen 

Identifiziere Objekte: Suche nach Substantiven in Anwendungsfällen. 

Operation: Einkauf 

Kunde König möchte Sattel kaufen; besitzt mehrere Fahrräder 

. . . 

König wählt sein 28”-Rennrad mit aus; Rahmenfarbe: magenta 

. . . 

PDA nimmt Verbindung mit Laden-Host-Rechner auf 

. . . 

König lässt nach Preis sortieren 

. . . 

Verkäufer Volker betrachtet Auswahl und berät 



Anwendungsfall → Objekte 

Objekt: ” Ding“ (Gegenstand, Entität) mit eigener Identität 

Eigenschaft/Attribut 

König : 

+geld = 40 EUR 

Königs Hollandrad : 

+preis = 400 EUR 

+farbe = schwarz 

+größe = 58 cm 

Objekt (unterstrichen) 

Wert 

Königs Rennrad : 


+farbe = magenta 


Volker : 

Sattel #1234 : 



+härte = knallhart 

+gewicht = 200 g 



Anwendungsfall → Objekte 

Assoziation: Beziehung zwischen Objekten 

König : 

+geld = 40 EUR 

besitzt 

Königs Hollandrad : 




+Interessent 

besitzt 

Rolle 

Königs Rennrad : 


+farbe = magenta 


Assoziation 

Richtung 

berät 

+Berater 

passt-zu 

Assoziationsname 

Volker : 

Sattel #1234 : 

im-sortiment 



+härte = knallhart 

+gewicht = 200 g 



Objekte versus Klassen 

Instanz-Ebene 

Objektdiagramme beschreiben statische Zusammenhänge auf der 

Ebene einzelner, konkreter Dinge 

Schema-Ebene 

2009-02-09 

Klassendiagramme beschreiben statische Zusammenhänge 

unabhängig von Details konkreter Objekte, auf der Ebene mehrerer 

gleichartiger Dinge 




Bemerkung 

Statische Eigenschaften: Klassendiagramme 


• Objektdiagramme werden in der UML als Teil der Klassendiagramme aufgefasst 


Instanz-Ebene 

Objektdiagramme beschreiben statische Zusammenhänge auf der 

Ebene einzelner, konkreter Dinge 

Schema-Ebene 

Klassendiagramme beschreiben statische Zusammenhänge 

unabhängig von Details konkreter Objekte, auf der Ebene mehrerer 

gleichartiger Dinge


Objekte → Klassen 

Klasse: Menge von gleichartigen Objekten mit gemeinsamen Eigenschaften 

Kunde 

+name 

+geld 

* 

Rad 

+preis 

+farbe 

+größe 

Klasse 

besitzt 

* 

1 

berät 

passt-zu 

1 

Multiplizität 

Verkäufer 

+name 

Sattel 

+artikelnummer 

+preis 

+farbe 

+härte 

+gewicht 

im-sortiment 



Generalisierungen 

sind spezielle Beziehung auf Schema-Ebene 

beschreiben Beziehungen zwischen einer allgemeineren Klasse 

(Oberklasse, Superclass) und einer spezielleren Klasse (Unterklasse, 

Subclass) 

die Unterklasse ” erbt“ die Eigenschaften der Oberklasse: 

Attribute 

Methoden und deren Aufrufschnittstellen 

Assoziationen 

Unterklassen können 

neue Attribute, Methoden und Assoziationen definieren 

ererbte Attribute, Methoden und Assoziationen redefinieren 

(überschreiben) 

von mehreren Oberklassen erben (Mehrfachvererbung) 


2009-02-09 






sind spezielle Beziehung auf Schema-Ebene 

beschreiben Beziehungen zwischen einer allgemeineren Klasse 

(Oberklasse, Superclass) und einer spezielleren Klasse (Unterklasse, 

Subclass) 

die Unterklasse ” erbt“ die Eigenschaften der Oberklasse: 

Attribute 

Methoden und deren Aufrufschnittstellen 

Assoziationen 

Unterklassen können 

neue Attribute, Methoden und Assoziationen definieren 

ererbte Attribute, Methoden und Assoziationen redefinieren 

(überschreiben) 

von mehreren Oberklassen erben (Mehrfachvererbung) 

Bemerkung: unterschiedliche Umsetzung in verschiedenen Programmierumgebungen bzgl. Überschreiben und 

Mehrfachvererbung 


Klassen → Klassenhierarchien 

abstrakt 

Kunde 

+geld 

Rad 

+farbe 

+größe 

besitzt 

Person 

+name 

Artikel 

+preis 


passt-zu 

berät 

{XOR} 

ist-ein-Relation 

Verkäufer 

Sattel 

+farbe 

+härte 

+gewicht 

Oberklasse 

im-sortiment 

Unterklasse 

Einschränkung 

zweier 

Beziehungen 


2009-02-09 






abstrakt 

Kunde 

+geld 

Rad 

+farbe 

+größe 

Person 

+name 

Verkäufer 

berät 

Gemeinsame Attribute werden in gemeinsamen Oberklassen zusammengefasst. Kunde und Verkäufer haben jeweils 

Namen. Rad und Sattel haben einen Preis und eine Artikelnummer. Das Attribut Farbe taucht in diesem Beispiel 

nicht in der Oberklasse auf. Die Konsequenz wäre sonst, dass jeder mögliche Artikel dieses Attribut hat. Bei vielen 

Artikeln, wie z.B. bei einem Sattelrohr oder einer Schraube, spielt Farbe aber keine Rolle. Deshalb tritt Farbe nur 

bei Rad und Sattel auf. Eine alternative Modellierung wäre eine weitere Oberklasse Gefärbte Artikel von Rad und 

Sattel, die dieses Attribut einführt. Allerdings könnte es noch eine weitere Klasse Sattelrohr geben, die zwar keine 

Farbe, aber eine Härte hätte. Dann müssten auch Sattel und Sattelrohr eine gemeinsame Oberklasse mit dem 

Attribut Härte haben. Dies führte dann zu Mehrfachvererbung, weil ein Sattel sowohl Farbe als auch Härte hat. 

Bei der Modellierung von Anwendungskonzepten kann es gelegentlich zu Mehrfachvererbungen kommen. Dies ist 

nicht weiter tragisch, solange in jedem Falle Liskovs Substitutionsprinzip erfüllt ist. Bei der Abbildung des 

Analysemodells auf eine konkrete Implementierung mit einer Programmiersprache ohne Mehrfachvererbung wird es 

dann allerdings zu einem Bruch kommen. In der Analysephase konzentrieren wir uns jedoch auf eine genaue und 

einfache Modellierung und sollten uns deshalb von solchen Implementierungseinschränkungen noch nicht beirren 

lassen. 

Meist sind diese neuen Oberklassen abstrakt, d.h. es gibt eigentlich kein Objekt, das genau von diesem Typ ist. So 

ist Person natürlich ein abstraktes Gebilde: Es gibt eigentlich nur Kunden oder Verkäufer, aber nichts, was man nur 

als Person bezeichnen würde. 

Abstrakte Klassen sind daran zu erkennen, dass ihr Name kursiv geschrieben wird. In diesem Beispiel sind Person 

und Artikel abstrakt. 


Attributierte Assoziationen 

Assoziationsklassen 

beschreiben Beziehungen, die gleichzeitig Klassen sind 

werden genutzt, um Assoziationen Attribute zuzuordnen 

können eigene Beziehungen eingehen 

Assoziationsklasse 

im-sortiment 

+anzahl 

Verkäufer 

Sattel 


+preis 

+farbe 

+härte 

+gewicht 


besitzt 

Artikel 

+preis 


passt-zu 

{XOR} 

ist-ein-Relation 

Sattel 

+farbe 

+härte 

+gewicht 

Oberklasse 

im-sortiment 

Unterklasse 

Einschränkung 

zweier 

Beziehungen


Mehrstellige Assoziationen 

Assoziationsklassen 

können auch mehrere Klassen in Beziehung setzen 



Aufbau von Objekten 

Aggregation 

ist spezielle Assoziation zur Verdeutlichung von 

” Teil-Ganzes-Beziehungen“ 

beschreibt Zusammenfassung von Komponenten zu einem Aggregat 


2009-02-09 






Aggregation 

ist spezielle Assoziation zur Verdeutlichung von 

” Teil-Ganzes-Beziehungen“ 

beschreibt Zusammenfassung von Komponenten zu einem Aggregat 

Leserichtung der Aggregation: Rad besteht aus einem Rahmen; ein Rahmen kann Teil eines oder gar keines Rads 

sein. 



Komposition ist spezielle Aggregation: 

Existenz der Komponenten ist an die Existenz des Aggregats 

gekoppelt, 

jede Komponente gehört zu genau einem Aggregat (strong ownership) 


2009-02-09 






Komposition ist spezielle Aggregation: 

Existenz der Komponenten ist an die Existenz des Aggregats 

gekoppelt, 

jede Komponente gehört zu genau einem Aggregat (strong ownership) 

Brennt der Laden ab, sind auch alle seine Artikel verloren. Ein Verkäufer ohne einen Laden, ist kein Verkäufer mehr 

(auch wenn er als Person weiter existiert). 

Man würde kaum behaupten wollen, dass ein Artikel Teil eines Kunden ist. Die normale Assoziation erscheint hier 

angemessener. Kauft ein Kunde einen Artikel in einem Laden, ist dieser nicht länger Teil des Ladens; er geht in den 

Besitz des Kunden über. 


Vergleich der Assoziationstypen 

Vererbung: ist-ein-Relation (Liskovs Substitutionsprinzip erfüllt) 

Aggregation: teil-von-Relation 

Komposition: teil-von-Relation 

Teil gehört zu genau einem Ganzen 

Teil existiert nur im Kontext des Ganzen 

allgemeine Assoziation: sonst 



Liskovs Substitutionsprinzip (1988; 1994) 

Definition 

Liskovs Substitutionsprinzip: jede Instanz der Unterklasse kann immer 

und überall dort eingesetzt werden, wo Instanzen der Oberklasse auftreten. 



Zusammenfassung Klassendiagramme 

Beschreibungsinhalt 

statische Systemaspekte 

Beschreibung der wesentlichen, unterscheidbaren Dinge eines Systems 

und ihrer Beziehungen 

zentrale Modellierungskonstrukte: 

Klassen 

Assoziationen (Beziehungsklassen) 

spezielle Assoziationen: Generalisierung und Aggregation/Komposition 




textuelle Szenario-Beschreibungen (siehe oben) 

Interaktionsdiagramme 

Aktivitätsdiagramme 

Zustandsdiagramme 




Passendes 

Produkt 

finden 


Realisierung 

Produkt− 

suche 

Kollaboration 


2009-02-09 



Verhaltenseigenschaften 



Passendes 

Produkt 

finden 


Anwendungsfälle können durch die inherit-Beziehung spezialisiert werden. Entspricht der objektorientierten 

Vererbung. 


UML-Interaktionsdiagramme (OMG) 

Beschreibungsinhalt: 

dynamische Systemaspekte 

exemplarische Beschreibung von Interaktionsabfolgen zwischen 

kollaborierenden Objekten (Inter-Objektverhalten) 

zentrale Modellierungskonstrukte: 

Objekte: ” Dinge“ mit eigener Identität 

Nachrichten 

beschreiben den Austausch von Informationen zwischen Objekten zum 

Auslösen von Aktivitäten 

sind Signale/Ereignisse oder Methodenaufrufe 


Realisierung 

Produkt− 

suche 

Kollaboration


UML-Interaktionsdiagramme (OMG) 

Anwendung 

Präzisierung von Szenarien (exemplarische Folgen von Aktivitäten) 

Protokollierung des Nachrichtenaustausches 

Erhebung der von einzelnen Objekten bereit gestellten Funktionalität 

(Dienste, Methoden) 

Varianten 

Grenzen: 

Sequenzdiagramme 

betonen zeitlichen Ablauf 

Kommunikationsdiagramme 

betonen Objektstruktur 

beschreiben Verhalten nur beispielhaft und nicht vollständig 



UML-Sequenzdiagramme (OMG) 


2009-02-09 



Sequenzdiagramme 



Aufruf: synchrone Nachricht dargestellt durch durchgezogenen Pfeil vom Sender zum Empfänger mit gefüllter 

Pfeilspitze. Sender setzt Aktivität aus (gestrichelter Aktivierungsbalken); Empfänger wird aktiviert 

(Aktivierungsbalken beim Empfänger beginnt). 

Antwort synchrone Nachricht als Reaktion auf einen Aufruf dargestellt durch gestrichelter Pfeil vom Sender zum 

Empfänger mit offener Pfeilspitze). Antwortender Sender wird deaktiviert, ausgesetzter Empfänger lebt 

wieder auf. 

Signal asynchrone Nachricht dargestellt durch durchgezogenen Pfeil vom Sender zum Empfänger mit offener 

Pfeilspitze; Sender und Empfänger setzen ihre Aktivität parallel fort. 

Bei synchroner Nachricht (Aufruf): 

• Sender schickt Nachricht an Empfänger und gibt die Kontrolle über den weiteren Prozess an den Empfänger 

• Empfänger gibt nach Bearbeitung der Nachricht die Kontrolle an den Sender zurück 

• Interaktionen des Empfängers, die nach Erhalt der Nachricht begonnen wurden, müssen beendet sein, bevor der 

Empfänger die Kontrolle an den Sender zurückgibt (nested flow of control, method-call). 

Anmerkung: Die Notation hat sich hier ab UML 2.0 geändert. 


UML-Kommunikationsdiagramme (OMG) 


2009-02-09 






• beschreiben Interaktionen zwischen Objekten durch gerichtete Graphen 

• die Abfolge der Nachrichten wird durch Nummerierung angezeigt 


Sequenz- und Kommunikationsdiagramme beschreiben semantisch identische Inhalte mit unterschiedlichem Fokus 

(zeitlicher Ablauf bzw. Objekte stehen im Vordergrund). 


Interaktions- und Klassendiagramme 

Bemerkung: 

Interaktionsdiagramme beschreiben exemplarische 

Interaktionsszenarien eines Systems aus dynamischer Sicht 

Klassendiagramme beschreiben diese Systeme aus statischer, 

schematischer Sicht 

Interaktionsdiagramme dienen als Ausgangspunkt zur Ergänzung und 

Überprüfung von Klassendiagrammen 



Interaktionen → Methoden 



Interaktionen versus Methoden 

Interaktionen 

beschreiben das Wechselspiel zwischen Akteuren über 

Botschaften/Methoden 10 

liefern Methoden für die modellierten Klassen 

beschreiben jedoch nicht die Methoden selbst 

10 Methoden beschreiben hier abstraktes Verhalten im Kontext der Anforderungen; 

sind noch nicht notwendigerweise die Methoden im Sinne der Implementierung (führen 

letztlich aber zu diesen hin). 



Methoden 

Beschreibung: 

Parameter: Eingabe und Ausgabe 

Vorbedingung: beschreibt die Annahmen der Methode, die gelten 

müssen, damit sie ausgeführt werden kann 

Nachbedingung: beschreibt das Resultat der Methode 

Fehlerbedingungen: Verletzung der Vorbedingungen und Fehler, die 

während der Ausführung auftreten können 

Verhalten in Fehlersituationen: Nachbedingung für jeden 

aufgetretenen Fehler 

Reaktionszeit: Maximale Dauer, bis Resultat vorliegt (sowohl im 

Normal- als auch im Fehlerfall) 



Methoden 

Beispiel Sortierung und Ausgabe der Artikelliste: 

Parameter: 

Eingabe: Artikelliste, Attribut 

Ausgabe: Artikelliste’ 

Vorbedingung: 

Attribut kommt bei allen Artikeln der Artikelliste vor 

Nachbedingung: 

Artikelliste’ ist sortiert, d.h.: 

∀ i : 1 ≤ i < len(Artikelliste ′ ) 

⇒ element(Artikelliste ′ , i) ≤Attribut element(Artikelliste ′ , i + 1) 

Artikelliste’ ist eine Permutation von Artikelliste 

Fehlerbedingungen: keine, außer Vorbedingung nicht erfüllt 

Verhalten in Fehlersituationen: 

Artikelliste wird zurückgegeben 

Fehlermeldung wird ausgegeben 

Reaktionszeit: n · log(n) · 0, 001 [sec], wobei n die Länge der Liste ist 



Beschreibung der Benutzeroberfläche 

1 

4 

145 Euro 

100 Euro 

78 Euro 

47 Euro 

5 

6 

2 

3 

1 Grafik des Artikels in der Größe 

40x40 Pixel 

2 Artikeldaten (10pt-Schrift) 

3 Attribut, nach dem sortiert 

wurde (rot, 12pt-Schrift) 

4 Scrolling nach oben; es wird 

immer um einen Artikel nach 

oben geschoben 

5 Scrolling nach unten; es wird 

immer um einen Artikel nach 

unten geschoben 

6 Auswahl des Artikels; alternativ 

kann man mit dem Stift durch 

rasches doppeltes Anklicken 

einen Artikel auswählen 



Zusammenhang von Benutzernachrichten und GUI 

Nachrichten an Benutzer: Anzeige in GUI 

Nachrichten vom Benutzer: Aktionen des Benutzers mit GUI (Texteingabe, 

Mausklicks etc.) 


1 

2 1 


100 Euro 

78 Euro 

47 Euro 

7 

5 6 4 4 



ja 

nein 

5 6 

2 

8 

beschaffe (artikel-nr) 

Einfachklick auf Auswahl.1 

Einfachklick auf Kaufen.7 

ermittle (artikel-typ) 

. . . 

ende 

. . . 




2009-02-09 

Wurzeln: Flussdiagramme, Petrinetze 

modellieren klassenübergreifendes Verhalten (Kontrollfluss) 

beschreiben häufig Anwendungsfälle 

Einsatz empfohlen bei hauptsächlich intern ausgelösten 

Zustandsübergängen (einfacher Kontrollfluss) 







Wurzeln: Flussdiagramme, Petrinetze 

modellieren klassenübergreifendes Verhalten (Kontrollfluss) 

beschreiben häufig Anwendungsfälle 

Einsatz empfohlen bei hauptsächlich intern ausgelösten 

Zustandsübergängen (einfacher Kontrollfluss) 

Laut UML-Standard 1.x ist ein Aktivitätsdiagramm der ” Zustandsautomat einer Berechnung“. Ab UML 2.0 wird es 

auf Token-Konzept von Petri-Netzen zurück geführt. 

Eine gute Darstellung findet man unter: http://informatik.unibas.ch/lehre/hs07/cs203/se5full.pdf


2009-02-09 





Aktivitätsdiagramme: Bestandteile 

• Aktionszustände: Zustände mit nur einer Eingangsaktion und ohne interne Transitionen 

• Aufrufzustände: Aufruf einer Operation 

• Subaktivitätszustände: Zustände mit internen Aktivitätsdiagrammen 

• Entscheidungen ( ” if −then−else“) 

• Aktions-/Objekts-Flussbeziehungen 

• Schwimmbahnen: unterteilen Zuständigkeiten für auszuführende Aktionen 

• Kontroll-Icons für Signale


Nebenläufigkeit in Aktivitätsdiagrammen: Signale 

Machine 

anschalten 

an 

braue Kaffee 

Leuchte aus 

Kaffee 

einschenken 

Kaffeetasse 


Objektorientierte Kontroll-Icons Modellierungdeuten 

Richtung des Signals an 

UML-Zustandsautomatendiagramme 

modellieren Objektlebenszyklus: Verhalten eines Objekts in Bezug auf 

die verfügbaren Operationen seiner Klasse 

gehen zurück auf Zustandsautomaten nach Harel (1987) 

Zustand: Menge von Attributwerten eines Objekts 

Transition: Zustandsänderung 

geeignet auch zur Beschreibung von Anwendungsfällen und 

Protokollen 

erlauben Verschachtelung von Zuständen und Automaten 



Zustandsautomatendiagramme: Beispiel 

Idle 

caller hangs up 

/disconnect 

lift receiver 

/get dial tone 

DialTone 

do/ play dial tone 

callee 

answers 

Invalid 

Timeout 

do/ play message 

after (15 sec.) after (15 sec.) 

Pinned 

Talking 


Busy 

callee 

hangs up 

dial digit(n) 

do/ play busy tone 

callee answers 

/enable speech 

dial digit(n) 

[invalid] 

busy 

Ringing 

Dialing 

dial digit(n) 

[valid] 

Connecting 

dial digit(n) 

[incomplete] 

connected 

do/ play ringing tone 



Zustände 

lift receiver 


Idle 


/disconnect 

Active 

DialTone 


callee 

answers 

Invalid 

Timeout 



Pinned 

Talking 

einfach/zusammengesetzt 


Busy 

callee 

hangs up 

dial digit(n) 




dial digit(n) 

[invalid] 

busy 

Ringing 

Dialing 

dial digit(n) 

[valid] 

Connecting 

dial digit(n) 

[incomplete] 

connected 


” interne“ Aktionen: entry, exit, do, include, frei definierbare Events 


2009-02-09 



Transitionen 


Zustandsautomatendiagramme 

• do/ activity : Aktivität, die im Zustand ausgeführt wird 

• entry/ action : bei Eintritt ausgeführte Aktivität 

• exit/ action : bei Austritt ausgeführte Aktivität 

• include/ : Zustandsmaschine wird importiert 

• ereignisabhängig: Event [Condition] / ActionˆSend Event 

lift receiver 


Idle 


/disconnect 

Active 

DialTone 


callee 

answers 

Invalid 

Timeout 



Pinned 

Talking 


Busy 

callee 

hangs up 

Auslöser: Ereignis, Bedingung, Zeit 

dial digit(n) 




dial digit(n) 

[invalid] 

busy 

Ringing 

Dialing 

Connecting 

connected 


lift receiver 


Idle 


/disconnect 

Active 

DialTone 


Invalid 

Timeout 




Busy 

dial digit(n) 

dial digit(n) 

[invalid] 

Dialing 

dial digit(n) 

[valid] 

Connecting 

dial digit(n) 

[incomplete] 

Pinned 


busy 

connected 

callee callee 

answers hangs up 

Ringing 

Talking 




Zustände 

einfach/zusammengesetzt 

” interne“ Aktionen: entry, exit, do, include, frei definierbare Events 

dial digit(n) 

[incomplete] 

dial digit(n) 

[valid] 

Auswirkung: Aktion (z.B. Methodenaufruf), Zustandsänderung 



Nebenläufigkeit 

mehrere nebenläufige Regionen 

Parallelität durch Gabelung/Join (bedingungsfrei!) 



Synchronisation nebenläufiger Regionen 

” Pseudozustände“ zur Synchronisation 



Auswahl (Choice) 

2009-02-09 

n-fache Verzweigung des Kontrollflusses gesteuert von einer logischen 

Bedingung 

dynamische bedingungsabhängige Verzweigung: Guards an den 

ausgehenden Transitionen werden ausgewertet, nachdem die Aktion 

an der eingehenden Transition ausgeführt wurde. 




Zustandsautomatendiagramme 


Dynamische Auswertung der Bedingungen der ausgehenden Transitionen 


n-fache Verzweigung des Kontrollflusses gesteuert von einer logischen 

Bedingung 

dynamische bedingungsabhängige Verzweigung: Guards an den 

ausgehenden Transitionen werden ausgewertet, nachdem die Aktion 

an der eingehenden Transition ausgeführt wurde.


Mehrfachkreuzung (Junction) 

State2 

State0 State1 

e1[b>0] e1[b>0] 

/ a:=a+1 / a:=a+2 

[a0] 

State3 State4 

Kombination aus mehrfacher Fallunterscheidung und mehrfacher 

Verzweigung 

Vereinigung mehrerer Transitionen 

Verschmelzung eingehender Transitionen und/oder 

Erzeugung einer statischen bedingungsabhängigen Verzweigung: 

Guards an den ausgehenden Transitionen werden ausgewertet, bevor 

die Aktion an der eingehenden Transition ausgeführt wird. 



Anwendung von Zustandsdiagrammen 

Beschreibung von Objektlebenszyklen pro Klasse 

Beschreibung von Protokollen 

Verfeinerung von Anwendungsfällen 




Was ist ein Modell? Wann und wozu modellieren wir? 

Welches sind die wesentlichen Schritte der objektorientierten 

Modellierung im Kontext der Anforderungsspezifikation? 

Was ist ein Anwendungsfall? Wie können Sie Anwendungsfälle 

beschrieben? 

Was ist ein Aktor? 

Welche Beziehungen zwischen Anwendungsfällen unterstützt die 

UML? 

Was ist der Unterschied zwischen Objekt- und Klassendiagrammen? 

Erläutern Sie Klassendiagramme für die Datenmodellierung. 

Was ist eine Generalisierung? 

Worin besteht das Liskovsche Substitutionsprinzip? 

Wie lassen sich attributierte Assoziationen und n-stellige 

Assoziationen mit n > 2 darstellen? 




Was ist eine Aggregation bzw. eine Komposition? 

Wie wird ein Anwendungsfall textuell beschrieben? 

Erläutern Sie Interaktionsdiagramme (Sequenzdiagramme und 

Kommunikationsdiagramme). 

Erstellen Sie ein Sequenzdiagramm für ein bestimmtes Szenario. 

Überführen Sie dieses Sequenzdiagramm in ein 

Kommunikationsdiagramm. 

Wie lassen sich Methoden aus den Interaktionsdiagrammen ableiten? 

Wie sind Methoden zu beschreiben? 

Erläutern Sie Aktivitätsdiagramme der UML. Erstellen Sie ein 

Aktivitätsdiagramm für ein bestimmtes Szenario. 

Erläutern Sie Zustandsautomatendiagramme der UML. Erstellen Sie 

ein Zustandsautomatendiagramm für ein bestimmtes Szenario. 

Wofür können die genannten Diagrammarten benutzt werden? 



Weiterführende Literatur/Links 

Buchtipp: Störrle (2005) 

Ein kurzes Tutorial in Deutsch: 

http://ivs.cs.uni-magdeburg.de/~dumke/UML/ 

Eine sehr kurze Übersicht in Englisch: 

http://bdn.borland.com/article/0,1410,31863,00.html 

Weitere ausführlichere Tutorials in Englisch: 

http: 

//pigseye.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/ 

http://uml.tutorials.trireme.com/ 


Prüfung der Anforderungsspezifikation 





Ablauf 

Zeitplan 

Anmeldung 




Kontaktdaten 

Ressourcen 

Lehrbücher 








Motivation 

Anforderung− 

analyse 


spezifikation 

Entwurf 

Entwicklung = Sequenz von Aktivitäten mit 

Zwischenprodukten (Anforderungsspezifikation, 

Entwurf, Code, Testfälle etc.) 

Qualität der Zwischenprodukte bestimmt 

wesentlich Qualität der von ihnen abhängigen 

Aktivitäten 

→ die Qualität der Zwischenprodukte muss gesichert werden 

→ wir müssen sicher stellen, dass alle Beteiligten sich über das 

Zwischenprodukt einig sind 

Quellcode kann durch Tests überprüft werden 

aber was machen wir mit nicht direkt ausführbaren Dokumenten wie 

Anforderungsspezifikation und Entwurf? 



Lernziele 

Im Allgemeinen: 

Überblick über Software-Prüfungen haben 

Reviews beliebiger Dokumente durchführen können 

Im Speziellen: 

Bedeutung der Prüfung für die Anforderungsspezifikation kennen 

Anforderungsspezifikation prüfen können 



Arten der Prüfungen 

2009-02-09 

Validierung: Are we doing the right thing? 

Prüfung, ob das, was entwickelt wird, gewünscht ist. 

Verifikation: Are we doing the thing right? 

Prüfung, ob der Entwicklungsschritt X richtig durchgeführt wurde. 



Reviews 

Software-Prüfungen 



Zur Qualitätssicherung gehören Prüfungen; eine Prüfung in der Entwicklung kann grundsätzlich nach zwei 

Prinzipien erfolgen. 

Vergleich mit einer Fahrt auf der Basis einer Wegbeschreibung: 

A: Haben wir das vorgesehene Ziel erreicht? 

Validierung: Are we doing the right thing? 

Prüfung, ob das, was entwickelt wird, gewünscht ist. 

Verifikation: Are we doing the thing right? 

Prüfung, ob der Entwicklungsschritt X richtig durchgeführt wurde. 

B: Sind wir, wie es die Beschreibung verlangt, an der richtigen Stelle auf die richtige Straße abgebogen? 

Offenbar sind beide Prüfungen sinnvoll: (A) ergibt die wichtigere Aussage, lässt sich aber nur anwenden, wenn das 

Endziel oder ein definiertes Zwischenziel erreicht wurde. (B) lässt sich nach jedem Schritt anwenden. 

Man beachte aber, dass die Wörter Validierung und Verifikation auch anders gebraucht werden, nämlich 

• Validierung als Oberbegriff für alle Prüfungen, 

• Verifikation speziell für Prüfungen formaler Art (Programmbeweis und ähnliches). 

Zur Vermeidung von Missverständnissen spricht man dann von externer und interner Validierung (entsprechend A 

und B) bzw. von formaler Verifikation.


Software-Prüfung 

2009-02-09 

nicht−mechanisch 

(durch Menschen) 

Reviews 

Inspektionen 

Software−Prüfung 

mechanisch 

(durch den Rechner) 

statisch dynamisch 

Programm− 

analysen 

Tests 



Reviews 




nicht−mechanisch 

(durch Menschen) 

Reviews 

Inspektionen 

Software−Prüfung 

Am populärsten ist der Test; aber man kann mit dem Rechner auch statisch prüfen. Fast immer kann man aber 

inspizieren. 

mechanisch 

(durch den Rechner) 

statisch dynamisch 

Programm− 

analysen 

Tests


. . . ist prüfbar durch 

das Dokument . . . Inspektion Test 

Lastenheft X 

Pflichtenheft X 

Systementwurf X 

Definition der Daten und Algorithmen X 

Benutzerhandbuch X 

Testdaten X 

Code X X 

Anleitungen etc. X 

2009-02-09 



Reviews 


. . . ist prüfbar durch 

das Dokument . . . Inspektion Test 

Lastenheft X 

Pflichtenheft X 

Systementwurf X 

Definition der Daten und Algorithmen X 

Benutzerhandbuch X 

Testdaten X 

Code X X 

Anleitungen etc. X 

Naturgemäß lassen sich mechanische Prüfungen nur dann anwenden, wenn die zu prüfenden Informationen einer 

mechanischen Analyse zugänglich sind. Darum kommt in der Software-Entwicklung als Prüfverfahren ganz 

überwiegend die Inspektion in Frage.


Reviews (Frühauf u. a. 2000) 

Prinzip 

Ziel 

2009-02-09 

Eine Software-Einheit wird (dezentral) von mehreren Gutachtern 

inspiziert; 

in einer gemeinsamen Sitzung werden die Mängel zusammengetragen 

und dokumentiert. 

Fehler zu finden, 

nicht, die Fehler auch zu beheben. 

Fehlerbehebung ist ein separater Arbeitsschritt, den der Entwickler im 

Allgemeinen wieder ohne Mitwirkung Dritter durchführt. 



Reviews 

Reviews 



Prinzip 

Eine Software-Einheit wird (dezentral) von mehreren Gutachtern 

inspiziert; 

in einer gemeinsamen Sitzung werden die Mängel zusammengetragen 

und dokumentiert. 

Ziel 

Fehler zu finden, 

nicht, die Fehler auch zu beheben. 

Fehlerbehebung ist ein separater Arbeitsschritt, den der Entwickler im 

Allgemeinen wieder ohne Mitwirkung Dritter durchführt. 

Nachfolgend wird das technische Review beschrieben. In der Praxis gibt es zahlreiche Varianten. Zwischen diesen 

Formen gibt es keine simple Qualitätsordnung! Das heißt, wir wissen nicht, welche davon effektiver und effizienter 

ist in der Fehlersuche.



Prüfling 

kann jeder in sich abgeschlossene, für Menschen lesbare Teil von 

Software sein 

Beispiele: ein einzelnes Dokument, ein Codemodul, ein Testfall 

Voraussetzung: 

Referenzunterlagen benötigt, die eine Beurteilung erlauben 

dazu gehören eine Vorgabe oder Spezifikation sowie die relevanten 

Richtlinien 

zusätzlich können Fragenkataloge (Checklisten) verwendet werden 




Rollen 

Moderator leitet das Review, ist also für den ordnungsgemäßen 

Ablauf verantwortlich. 

Sekretär führt das Protokoll. 

Gutachter sind Experten (z.B. Kollegen), die den Prüfling beurteilen 

können. 

Autor ist der Urheber des Prüflings oder ein Repräsentant des Teams, 

das den Prüfling erstellt hat. 



Review-Prozess 

1−2 W 

vorher 

2 h 

[akzeptabel] 

Planung 

Vorbereitung 

Sitzung 

Freigabe 

Analyse 

Nacharbeit 

[nicht akzeptabel] 

1−2 W 



Review 

Gutachter: andere Entwickler, Benutzer, Auftraggeber, Produkt-Manager, 

Tester, Architekten, Handbuchautoren, Wartungspersonal. 

Aufgaben: 

Vorbereitung: Prüfling lesen und nach bestimmten, ihnen individuell 

zugeteilten Gesichtspunkten prüfen. 

Sitzung: gefundene Probleme vorbringen; Befund gemeinsam erheben, 

gewichten und protokollieren 

begutachten 

nicht korrigieren 

Nacharbeit: Autor korrigiert nach Auflagen der Gutachter 

eventuell weitere Iteration mit Gutachtern 


2009-02-09 


Reviews 

Ablauf von Reviews 

Review 

Review 

Gutachter: andere Entwickler, Benutzer, Auftraggeber, Produkt-Manager, 

Tester, Architekten, Handbuchautoren, Wartungspersonal. 

Aufgaben: 

Vorbereitung: Prüfling lesen und nach bestimmten, ihnen individuell 

zugeteilten Gesichtspunkten prüfen. 

Sitzung: gefundene Probleme vorbringen; Befund gemeinsam erheben, 

gewichten und protokollieren 

begutachten 

nicht korrigieren 

Nacharbeit: Autor korrigiert nach Auflagen der Gutachter 

eventuell weitere Iteration mit Gutachtern 

Beim technischen Review werden Kollegen als Gutachter beigezogen. Dafür kommen vor allem andere Entwickler in 

Frage, aber auch Benutzer, Produkt-Manager oder Auftraggeber. Die Gutachter erhalten im technischen Review 

konkrete Aufträge: 

• Im ersten Schritt des Reviews, in der Vorbereitung, müssen die Gutachter das zu prüfende Dokument lesen und nach 

bestimmten, ihnen individuell zugeteilten Gesichtspunkten prüfen. 

• Den zweiten Schritt bildet die Review-Sitzung, in der die Gutachter ihre in der Vorbereitung gefundenen Probleme 

vorbringen. Gemeinsam erheben, gewichten und protokollieren sie die Befunde. Der Auftrag für die Review-Sitzung 

lautet also, das Dokument oder Programm zu begutachten und nicht zu korrigieren, d.h. die Sitzung hat das Ziel, 

Probleme aufzuzeigen, nicht sie zu lösen. 

• Die Nacharbeit selbst wird dem Autor oder den Autoren zugeteilt. Die Gutachter kommen bei der Überprüfung der 

Nacharbeit evtl. nochmals zum Zug. 


Review-Regeln 

Review-Sitzung ist auf 2h beschränkt. 

Falls nötig wird eine weitere Sitzung, frühestens am nächsten Tag, 

einberufen. 

Der Moderator kann die Sitzung absagen oder abbrechen. Grund des 

Abbruchs ist zu protokollieren. 

z.B. weil Gutachter nicht erscheinen oder ungenügend vorbereitet sind 

Moderator ist nicht zugleich Gutachter. 

Jeder Gutachter bekommt Gelegenheit, seine Befunde angemessen zu 

präsentieren. 

Der Prüfling – nicht der Autor – steht zur Diskussion. Das heißt: 

Gutachter müssen auf ihre Ausdrucksweise achten. 

Autor darf weder sich noch das Resultat verteidigen. 



Review-Regeln II 

Stilfragen (außerhalb der Richtlinien) werden nicht diskutiert. 

Das Review-Team identifiziert Schwachpunkte und Fehler. 

Team macht keine konstruktiven Vorschläge, wie Mängel zu beheben 

sind; 

Befunde werden nicht in der Form von Anweisungen an den Autor 

protokolliert. 

Der Konsens der Gutachter zu einem Befund wird laufend 

protokolliert. Die einzelnen Befunde werden gewichtet als 

kritischer Fehler (Prüfling für den vorgesehenen Zweck unbrauchbar, 

Fehler muss vor der Freigabe behoben werden) 

Hauptfehler (Nutzbarkeit des Prüflings beeinträchtigt, Fehler sollte vor 

der Freigabe behoben werden), 

Nebenfehler (beeinträchtigen den Nutzen kaum), 

gut (fehlerfrei, bei Überarbeitung nicht ändern) 



Review-Regeln III 

Review-Team gibt Empfehlung über die Annahme des Prüflings: 

akzeptieren ohne Änderungen 

akzeptieren mit Änderungen (kein weiteres Review) 

nicht akzeptieren (weiteres Review erforderlich) 

Alle Sitzungsteilnehmer unterschreiben das Protokoll 



Checklisten: Fragenkatalog für ein Anforderungsdokument 

Prüfen Sie bitte das Dokument als Vorbereitung zur Sitzung gemäß den 

Ihnen in Punkt D der Einladung zugeteilten Aspekten aus der folgenden 

Liste. 

Aspekt Form: Ist die Darstellung im Dokument sinnvoll? 

a1 Sind Anforderungen als solche erkennbar, d.h. von Erklärungen 

unterscheidbar? 

a2 Sind alle Anforderungen eindeutig referenzierbar? 

a3 Ist die Spezifikation jeder Anforderung eindeutig? 

a4 Sind alle Anforderungen überprüfbar formuliert? 

Aspekt Schnittstellen: Sind alle Schnittstellen eindeutig spezifiziert? 

b1 Sind alle Objekte der Umgebung (Benutzer, andere Systeme, 

Basis-Software etc.) sowie alle Informationsflüsse von und nach diesen 

Objekten spezifiziert? 

b2 Sind alle Benutzerklassen (Dauerbenutzer, gelegentliche Benutzer, 

System-Administrator, etc.) des Systems identifiziert? 

b3 . . . 

b7 Sind Vorgaben gemacht bezüglich Verwendung von 

Betriebssystem-Funktionen, Bibliotheken und Hilfsprogrammen? 



Checklisten: Fragenkatalog für ein Anforderungsdokument 

(Fortsetzung) 

Aspekt Vertraulichkeit: Sind die wesentlichen Aspekte des 

Datenschutzes berücksichtigt? 

d1 Ist spezifiziert, welche Information vertraulich zu behandeln ist? 

d2 Sind die Zugriffsrechte aller Benutzerklassen definiert? 

d3 Ist definiert, gegen welche Art von unberechtigtem Zugriff die 

Information geschützt werden muss? 

. . . 



Varianten des Software-Reviews 

Design and Code Inspection (nach Fagan) 

mit Einführungssitzung, Gutachter-Notizen, die abgegeben werden, 

Vorleser, Entscheidungskompetenz, Metriken-Erhebung. 

Schreibtischtest (besser: die Selbstkontrolle) 

führt jeder Entwickler allein durch (vgl. Humphreys PSP); 

ersetzt die eigentliche Prüfung nicht. 

Stellungnahme 

ist ein ” off-line“–Review unter der Regie des Autors; 

den Vorteilen (geringer Organisationsaufwand) stehen erhebliche 

Nachteile gegenüber (Prüfling nicht vor Weiterbearbeitung geschützt, 

Qualität der Prüfung und Umsetzung der Resultate nicht kontrolliert). 

Structured Walkthrough 

ist die Billig-Variante des Reviews: Autor ist Moderator; 

er kompensiert durch seine Präsentation die Einsparung (oder 

Reduktion) der Vorbereitung; 

während seiner Vorbereitung entdeckt er selbst viele Fehler. 




Perspektivisches Review 

Prinzip: 

Prüfling wird von Gutachtern mit unterschiedlichem Interesse geprüft 

Gutachter haben konkreten Auftrag: Prüfling (hypothetisch) benutzen 

Beispiel: 

Tester → Testfälle entwickeln 

Benutzer → System benutzen 

Handbuchautor → Handbuch schreiben 

Architekt → Entwurf erstellen 




Empirische Studien legen nahe (Berling und Runeson 2003; Fusaro u. a. 

1997; Hayes 1999; Miller u. a. 1998; Porter u. a. 1995; Porter und Votta 

1998; Sandahl u. a. 1998): 

Reviews, die auf Checklisten basieren, sind effektiver als 

Ad-Hoc-Reviews; 

perspektivische Reviews sind effektiver und effizienter als Reviews, die 

auf Checklisten basieren: 

mehr Fehler/Mängel gefunden 

mehr Fehler/Mängel in gleicher Zeiteinheit gefunden 



Woran scheitern Reviews? Fallen und Gegenmittel 

Probleme bei der Ein-/Durchführung von Reviews: 

Es fehlen gute Moderatoren 

→ Leute aussuchen und ausbilden 

Es fehlen Bezugsdokumente 

→ suchen, anpassen, bereitstellen 

Entwickler haben Angst 

→ erste Reviews gründlich vorbereiten (und auf die Ängste eingehen, 

selbst wenn sie geleugnet werden) 

Reviews beißen sich an Äußerlichkeiten fest 

→ Bedeutung der Äußerlichkeiten klarstellen, aber dann weitergehen; 

→ beim zweiten Review sicherstellen, dass die Äußerlichkeiten in Ordnung 

sind. 

Bezugsdokumente sind ungeeignet 

→ diskutieren und verbessern 



Woran scheitern Reviews? Fallen und Gegenmittel II 

Zeitdruck sabotiert Prüfungen 

→ klare Entscheidungen über die Prioritäten treffen 

Geprüfte Dokumente werden verändert 

→ Konfigurationsmanagement verbessern 

Interesse an Reviews kühlt sich ab (,,Jetzt ist doch eigentlich alles in 

Ordnung!”) 

→ Statistiken führen, Erfolg nachweisen 




Was ist der Unterschied zwischen Verifikation und Validierung? 

Welche Arten der Software-Prüfung gibt es? 

Was ist ein Review? Welche Rollen sieht es vor? Wie wird es 

durchgeführt? 

Welche Review-Varianten gibt es? 

Worauf ist bei Reviews zu achten? 



Weiterführende Literatur 

Frühauf u. a. (2000) führen in Software-Prüfung ein. 

Shull u. a. (2000) zeigen in ihren empirischen Untersuchungen, dass 

perspektivische Reviews effektiver sein können als Reviews, die nur 

auf allgemeinen Check-Listen basieren 


Entwurf von Benutzungsschnittstellen 





Ablauf 

Zeitplan 

Anmeldung 




Kontaktdaten 

Ressourcen 

Lehrbücher 








Lernziele 

Ergonomische Software erstellen können: 

Bedienelemente graphischer Benutzungsschnittstellen kennen und 

einsetzen können 

Ergonomie bewerten können 



Ergonomie 

Definition 

Ergonomie: (von ergon (Arbeit, Werk) und nomos (Gesetz, Regel)) ist die 

Wissenschaft der Arbeitsbedingungen und deren optimale Anpassung an 

den Anwender. 

“Design for Use” 

Anpassung von Maschinen, Computern und Systemen an menschliche 

(Denk- und Kommunikations-) Fähigkeiten und Bedürfnisse 

zentral ist Schnittstelle zwischen Mensch und Maschine 

(Mensch-Computer-Interaktion) 

Auswirkungen auf zum Beispiel: Arbeitsabläufe, Menü-Hierarchien, 

Kommandosprachen, Farb- und Schriftwahl und die 

Funktionsaufteilung zwischen Mensch und Computer 


2009-02-09 



Ergonomie 

Ergonomie 

Ergonomie 

Definition 

Ergonomie: (von ergon (Arbeit, Werk) und nomos (Gesetz, Regel)) ist die 

Wissenschaft der Arbeitsbedingungen und deren optimale Anpassung an 

den Anwender. 

“Design for Use” 

Anpassung von Maschinen, Computern und Systemen an menschliche 

(Denk- und Kommunikations-) Fähigkeiten und Bedürfnisse 

zentral ist Schnittstelle zwischen Mensch und Maschine 

(Mensch-Computer-Interaktion) 

Auswirkungen auf zum Beispiel: Arbeitsabläufe, Menü-Hierarchien, 

Kommandosprachen, Farb- und Schriftwahl und die 

Funktionsaufteilung zwischen Mensch und Computer 

Alternative Definition 

” Der Software-Ergonomie geht es um eine Optimierung des Zusammenspiels aller Komponenten, die die 

Arbeitssituation von Computerbenutzern bestimmen: Mensch, Aufgabe, Technik und organisatorischer Rahmen. Sie 

beschränkt sich ausdrücklich nicht - wie oft fälschlich angenommen - auf die Behandlung der Präsentationsaspekte 

interaktiver Software.“ 

– nach Susanne Maaß, Software-Ergonomie, ” benutzer- und aufgabengerechte Systemgestaltung“, 

Informatik-Spektrum, 16, 1993, 191-205 


Usability 

Definition 

Usability: eines Produktes ist das Ausmaß, in dem es von einem 

bestimmten Benutzer verwendet werden kann, um bestimmte Ziele in 

einem bestimmten Kontext effektiv, effizient und zufriedenstellend zu 

erreichen. — Part 11: “Guidance on Usability” (ISO 9241-11:1998 1998) 

übersetzt als ” Benutzerfreundlichkeit” oder ” Benutzbarkeit” 

Verbesserung ist Ziel der (Software-)Ergonomie 


2009-02-09 



Ergonomie 

Usability 

Usability 

Definition 

Usability: eines Produktes ist das Ausmaß, in dem es von einem 

bestimmten Benutzer verwendet werden kann, um bestimmte Ziele in 

einem bestimmten Kontext effektiv, effizient und zufriedenstellend zu 

erreichen. — Part 11: “Guidance on Usability” (ISO 9241-11:1998 1998) 

übersetzt als ” Benutzerfreundlichkeit” oder ” Benutzbarkeit” 

Verbesserung ist Ziel der (Software-)Ergonomie 

Wird auch als ” Ein Maß für die Qualität, mit der ein Benutzer die Interaktion mit einer Maschine erlebt.“ definiert. 


Psychologische und kognitive Grundlagen 

Kurzzeitgedächtnis 

Information strukturieren und begrenzen: 7 ± 2 

menschliche Gestaltwahrnehmung 

→ bei Präsentation beachten 

z.B. Superzeichenbildung: 0 4 2 1 2 1 8 2 4 2 1 versus 0421/218-2421 

geteilte Aufmerksamkeit 

→ Fortsetzung nach Unterbrechung unterstützen 

begrenzte Konzentrationsfähigkeit 

→ nicht überfordern, Sicherheiten einbauen 

Unerfahrenheit verunsichert 

→ Metaphern verwenden, z.B. Ikonen wie Mülleimer, Briefkasten 

→ explorative Untersuchung unterstützen 



Vergleich von GUI und Kommandosprachen 

Kommandosprachen Graphical User Interface (GUI) 

komplexe Operationen einfache Operationen 

intensive Nutzung, gelegentlicher Einsatz, 

Experten leichte Erlernbarkeit 

funktionale Bedienung, Objektorientierung 

Berechnungen 



Wegweiser 

Meilensteine in der Geschichte graphischer 

Benutzungsschnittstellen 



Die ersten Ideen 

Memex (Memory Extender) von Bush (1945) 

2009-02-09 

Kompakt-Analog-Rechner zur Verwaltung 

verlinkter Informationen 

berührungssensitive Bildschirme projizieren 

Mikrofilme 

Mikrofilme verknüpft 

Vor- und Zurückblättern über Hebel 




Geschichte graphischer Benutzungsschnittstellen 


Dank auch an Matthias Kirschner für einige seiner Folien. 


Memex (Memory Extender) von Bush (1945) 

Kompakt-Analog-Rechner zur Verwaltung 

verlinkter Informationen 

berührungssensitive Bildschirme projizieren 

Mikrofilme 

Mikrofilme verknüpft 

Vor- und Zurückblättern über Hebel


Semi Automatic Ground Environment 

Bedienung durch Laien 

Lichtgriffel (Light-Pen) 



Sketchpad 

von Ivan Sutherland (1963) 

Objektorientierung statt 

Bitmaps 

Generische Operationen für 

verschiedene Objekte 

Constraints zu den graphischen 

Objekten (z.B. Länge) 

Copy & Paste 



Computermaus 

von Douglas Engelbart und Bill English (1963) 

relative Positionsveränderung 



Windows Icons Menus & Pointer 

Frühe Ideen: Xerox Palo Alto Research Center (1970) 

Prinzipien: 

abstrakte Datensicht, Visualisierung 

Raum und Objekte 

Metaphorisierung: Schreibtisch (Desktop) 

“What you see is what you get” (Texteditor BRAVO, Vorläufer von 

Microsoft Word) 

einheitliche Visualisierung und Interaktion 

wenige Modi, generische Kommandos 



Xerox Star GUI 



Marktreife 

1984 X-Windows System, Apple Lisa 

1985 Atari ST, Amiga, Windows 1.0 

1987 farbige GUI, Apple II 



Wegweiser 

Möglichkeiten graphischer Benutzungsschnittstellen 



Direkte Manipulation 

Direkte Manipulation: 

Metaphern visualisiert in Form von Ikonen (Gegenstände) 

physische Aktionen mittels Zeigegeräten 

permanente visuelle Rückkopplung 

nützt Intuition und Erfahrungen der Anwender in der metaphorisierten 

Welt aus 

Interaktionen: 

Auswahl: “Point & Click” 

Verschieben: 

Unmittelbar: “Drag & Drop” 

Unterbrechbar: “Cut & Paste” 

Vervielfältigen: “Copy & Paste” 



Rückkopplung an Nutzer 

Metaphern der physischen 

Welt, z.B. Räumlichkeit, 

→ Wiedererkennungswert 

Verbergen von Irrelevantem, 

Information auf Abruf, 

Kontextsensitivität 

Fortschrittsanzeige, 

Aktivitätsanzeige 



Fenster I 

Fokus 

Desktop, Hauptfenster 

Handles, Scrollbars 



Fenster II 

Reiter, Split-Fenster 

Layout Manager 

Dialogfenster 

modal: Dialog muss abgeschlossen werden, bevor nächster Dialog 

beginnt 

nicht-modal: Dialoge können ko-existieren 



Menüs und Schaltflächen I 

” Pull-Down-Menü“ 

Paneele, Gruppen 

Baumstruktur 



Menüs und Schaltflächen II 

Kontextmenü 

Schaltfläche, Button 

Toolbars 



Textelemente 

Mnemonics, Tooltips 

Formularfelder 

Listen, Tabellen 



Ikone, Metaphern 

Dateisymbole 

Programmverknüpfungen 

Thumbnails 



Manipulatoren und Attribute 

Checkbox 

(Boolean) 

Radio-Button 

(Alternativen) 

Slider 

(Zahlenwerte) 



Listen 

Teilmenge, 

Permutation 

statisch vs. 

erweiterbar 

Combo-Box 



Wegweiser 

Eigenschaften guter graphischer 

Benutzungsschnittstellen 



Qualitätskriterien (EN ISO 9241-10:1995 1995) 

Definition 

Aufgabenangemessenheit: Benutzer wird unterstützt, Arbeitsaufgabe 

effektiv und effizient zu erledigen 

2009-02-09 

Dialoge sollten nur sachdienliche Informationen enthalten 

Vermeidung von Ablenkungen 

weniger ist mehr (Funktionen) 

den Bildschirm nicht überfüllen 

vermeide es, Befehle redundant anzubieten 

keine unnötigen Dialoge und Popups 

Optimieren von häufigen Aufgaben 

kleine Anzahl von benötigten Schritten; Anzahl ” Klicks“ klein halten 

große Knöpfe für Hauptbefehle, Tastaturkürzel 

die häufigsten Funktionen auf dem ersten Bildschirm 

wichtige Befehle → hervorstehende Stelle 

weniger häufig benutzte Befehle → weniger hervorstehende Stelle 

(Untermenü, Einstellungsdialog) 




Software-ergonomische Richtlinien 

Weitere Qualitätsaspekte 

• Fehler verringern 


• Sicherheit erhöhen 

• Zuverlässigkeit erhöhen 

• Lernanforderungen verringern 

• Wartbarkeit verbessern 

• Wirksamkeit erhöhen 

• Produktivität erhöhen 

• Arbeitsumgebung verbessern 

• Ermüdung verringern 

• Langeweile und Eintönigkeit verringern 

• Zugang zur Anwendung erleichtern 

• Akzeptanz verbessern 

• Arbeitszufriedenheit steigern 

• Tätigkeitserweiterung ermöglichen 

• Lebensqualität verbessern 

• . . . 


Definition 

Aufgabenangemessenheit: Benutzer wird unterstützt, Arbeitsaufgabe 

effektiv und effizient zu erledigen 

Dialoge sollten nur sachdienliche Informationen enthalten 

Vermeidung von Ablenkungen 

weniger ist mehr (Funktionen) 

den Bildschirm nicht überfüllen 

vermeide es, Befehle redundant anzubieten 

keine unnötigen Dialoge und Popups 

Optimieren von häufigen Aufgaben 

kleine Anzahl von benötigten Schritten; Anzahl ” Klicks“ klein halten 

große Knöpfe für Hauptbefehle, Tastaturkürzel 

die häufigsten Funktionen auf dem ersten Bildschirm 

wichtige Befehle → hervorstehende Stelle 

weniger häufig benutzte Befehle → weniger hervorstehende Stelle 

(Untermenü, Einstellungsdialog)



Definition 

Selbstbeschreibungsfähigkeit: jeder einzelne Dialogschritt ist durch 

Rückmeldung unmittelbar verständlich bzw. eine Erklärung ist auf Anfrage 

verfügbar 

verständliche Benennung von Feldern 

Online-Hilfe 

Erläuterung der Konsequenzen des nächsten Schritts 




Definition 

Erwartungskonformität: Dialog ist konsistent und entspricht den 

Merkmalen des Benutzers (z.B. Kenntnisse aus dem Arbeitsgebiet, 

Ausbildung u. Erfahrung sowie allgemeinen Konventionen) 

vorhersagbares Verhalten 

passende Rückmeldung in angemessener Zeit 

Konsistenz von Benutzeraktionen, Präsentation, Anordnung von 

Elementen, Text 




Definition 

Steuerbarkeit: Benutzer ist in der Lage, den Dialogablauf zu starten sowie 

seine Richtung und Geschwindigkeit zu beeinflussen, bis Ziel erreicht ist 

2009-02-09 

erlaube es dem Benutzer, jederzeit die Anwendung zu verlassen oder 

zur Startseite zurückzukommen 

benutze modale Formulare sparsam 




Software-ergonomische Richtlinien 



Definition 

Steuerbarkeit: Benutzer ist in der Lage, den Dialogablauf zu starten sowie 

seine Richtung und Geschwindigkeit zu beeinflussen, bis Ziel erreicht ist 

erlaube es dem Benutzer, jederzeit die Anwendung zu verlassen oder 

zur Startseite zurückzukommen 

benutze modale Formulare sparsam 

Modaler Dialog: ein Dialog, der geschlossen werden muss, bevor weitere Aktionen anderer Dialoge durchgeführt 

werden können. Beispiel: Datei- Öffnen-Dialog.



Definition 

Fehlertoleranz: Ziel kann trotz erkennbarer fehlerhafter Eingabe mit 

minimalem Korrekturaufwand durch den Benutzer erreicht werden 

Hinweise sind sichtbar oder einfach erreichbar 

aussagekräftige Fehlermeldungen mit Hinweisen 

einfaches Wiederaufsetzen nach Fehlern, z.B. fehlerhafte Eingabe in 

Textfeld wird nicht einfach gelöscht, 

Fehler werden vor Eintreten verhindert 




Definition 

Individualisierbarkeit: Anpassungen an Erfordernisse der Arbeitsaufgabe, 

individuelle Vorlieben des Benutzers und Benutzerfähigkeiten sind möglich 

Sprache ist einstellbar 

Zeichensätze/-größe sind einstellbar 

Farben sind einstellbar 

eigene Tastaturbefehle für erfahrene Benutzer 




Definition 

Lernförderlichkeit: Benutzer wird beim Erlernen des Dialogsystems 

unterstützt und angeleitet 

Guided Tour 

Undo erlaubt gefahrlose Exploration 



Wegweiser 

Usability messen und verbessern 



Usability-Engineering 

Iterative Verbesserung der Usability 

1 Festlegen der Parameter 

2 Bewerten des Systems 

3 Verbessern des Systems 

4 Wiederhole ab 2 solange, bis Qualität akzeptabel 



Parameter für Bestimmung der Usability 

Beispiel Textverarbeitung: 

Ziel: Erstellen eines Textdokuments nach einer Papiervorlage 

Aufgaben: Eingeben des Textes 

Formatieren 

Einfügen eines Bildes 

Rechtschreibung überprüfen 

. . . 

Benutzer: wenig Vorkenntnisse über Computerbenutzung im 

Allgemeinen und Textverarbeitung im Speziellen 

Umgebung: Büroumgebung mit erheblichem Zeitdruck 

Meßgrößen: Zeitaufwand, Unterschiede im Text (mit Gewichtung) und 

Unterschiede im Layout und Stil (auch mit Gewichtung) 



Evaluationsverfahren 

Wie kann man Usability messen? 

objektiv versus subjektiv 

Fakten versus Gründe 



Subjektive Messungen 

Benutzerbefragung (Fragebögen oder Interviews) 

subjektiv 

breit anwendbar und statistisch auswertbar 

Standardfragebögen existieren (z.B. ErgoNorm, SUMI, QUIS, PUTQ) 

Experten-Reviews 

Checklisten für Normkonformität 

Heuristiken 



Objektive Messungen 

Evaluation eines Modells 

direkte Beobachtung der Benutzer 

Labor oder echte Arbeitsumgebung 

Aufzeichnung: Video, Audio (Think-Aloud), Eye-Tracking 

indirekte Beobachtung: Mitschnitte von Aktionen (z.B. Web-Logs) 

breiter anwendbar 

viel Fakten, wenig Hinweise auf Gründe 



A-Posteriori Messungen 

Messungen nach Auslieferung im Einsatz: 

Anzahl der Hotline-Anrufe 

Verkaufsrate 

siehe oben 

Speziell fürs Web: 

Traffic / Netzaufkommen 

Besucherzahl 

Anteil der Besucher, die zum Kauf eines Produkts animiert werden 

konnten 



Zusammenfassung 

entwickle für den Benutzer 

entwickle mit dem Benutzer 

Usability ist entscheidend für den Erfolg des Produktes 




Wie kann Usability verbessert werden? 

Wie lässt sich Usability messen? 

Was sind die Qualitätskriterien von Benutzungsschnittstellen nach EN 

ISO 9241-10:1995 (1995)? Erläutern Sie die Aspekte anhand eines 

konkreten Szenarios. 

Wie haben Sie diese konkret in Ihrem Projekt umgesetzt? 


Software-Architektur 





Ablauf 

Zeitplan 

Anmeldung 




Kontaktdaten 

Ressourcen 

Lehrbücher 









Vorgehen 

Lernziele 

Inhalt 

Zeitplan 


Risiken 



Verstehen, Allgemeinewas Risiken Software-Architektur in einem Software-Projekt ist 

Verschiedene Wiederholungsfragen Architektursichten kennen 

Lernziele 

Qualitäten einer Architektur kennen 


Eine Aktivitäten angemessene Software-Architektur entwerfen können 

Die Ist-Analyse Änderbarkeit einer Software-Architektur bewerten können 


Befragung 

Beobachtung 




Bedeutung 

Anzustrebende Eigenschaften 



Kontext 

Analyse 

Architektur 

Entwurf 

Datenstrukturen 

und Algorithmen 

Implemen− 

tierung 

Test 

Wartung 

& Evolution 



Client-Server-Architektur: Dynamische Sicht 

1 : PDA Client 

queries 

queries 

2 : PDA Client 

: Shop Server 

queries 

n : PDA Client 



Client-Server-Architektur: Statische Sicht 

PDA Client Shop Server 

Schnittstelle 

 

send receive 

Network 

Stereotyp 



Was ist Architektur? 

Architecture is the human organization of empty space using 

raw material. 

Richard Hooker, 1996. 

Definition 

Software-Architektur ist die grundlegende Organisation eines Systems 

verkörpert (IEEE P1471 2002) 

in seinen Komponenten, 

deren Beziehungen untereinander und zu der Umgebung 

und die Prinzipien, die den Entwurf und die Evolution leiten. 



Bedeutung von Software-Architektur 

2009-02-09 

Kommunikation zwischen allen Interessenten 

hoher Abstraktionsgrad, der von vielen verstanden werden kann 

Frühe Entwurfsentscheidungen 

→ nachhaltige Auswirkungen 

→ frühzeitige Analyse 

Transferierbare Abstraktion des Systems 

→ eigenständig wiederverwendbar 

→ unterstützt Wiederverwendung im großen Stil (Software-Produktlinien) 




Was ist Software-Architektur? 



Kommunikation zwischen allen Interessenten 

hoher Abstraktionsgrad, der von vielen verstanden werden kann 

Frühe Entwurfsentscheidungen 

→ nachhaltige Auswirkungen 

→ frühzeitige Analyse 

Transferierbare Abstraktion des Systems 

→ eigenständig wiederverwendbar 

→ unterstützt Wiederverwendung im großen Stil (Software-Produktlinien) 

Die Softwarearchitektur repräsentiert hohe Abstraktion eines Systems, die von den meisten Interessenten 

verstanden werden kann und damit eine Grundlage zum gegenseitigen Verständnis, zur Konsensbildung und zur 

Kommunikation darstellt. 

Die Softwarearchitektur ist die Manifestation früher Entwurfsentscheidungen; diese frühe Fixierung kann 

nachhaltige Auswirkungen haben auf die nachfolgende Entwicklung, Auslieferung sowie Wartung und Evolution. SA 

ist auch die früheste Systembeschreibung, die analysiert werden kann. 

Die Softwarearchitektur konstitutiert ein relativ kleines intellektuell fassbares Modell darüber, wie das System 

struktiert ist und wie seine Komponenten zusammenwirken; dieses Modell ist eigenständig nutzbar und kann über 

das spezifische System hinaus transferiert werden; insbesondere kann es für Systeme mit ähnlichen Eigenschaften 

und Anforderungen wiederverwendet werden, um so Wiederverwendung im großen Stil zu unterstützen (Stichwort: 

Software-Produktlinien).


Beispielsystem IS2000 (Hofmeister u. a. 2000) 

IS2000 

Probe 

01 

01 

01 

01 

01 

01 

00000 

11111 

00000 

11111 

0000000000000 

111111111111100000 

11111 

Imaging 

Computer 

Remote Imaging 

Computers 

User Control 

Panel 

Network 



Einflussfaktoren/Anliegen (Concerns) 

Einflussfaktoren 

Produktfunktionen und -attribute 

z.B. Performanz, Ansprüche an Zuverlässigkeit, Umfang und Stabilität 


Organisation 

z.B. Budget, verfügbare Zeit, Team-Größe und -erfahrung 

Technologie 

z.B. verfügbare Hard- und Software 

Keiner der Faktoren kann isoliert behandelt werden → globale Analyse. 




Anmerkung 

Ein Faktor ist nur dann relevant, wenn er Einfluss auf die Architektur hat. 

Test: 

Architektur A1 ergibt sich mit Betrachtung des Faktors 

Architektur A2 ergibt sich ohne Betrachtung des Faktors 

Nur wenn A1 und A2 sich unterscheiden, ist der Faktor relevant. 



Globale Analyse 

Organisatorische,und 

technologische Faktoren, 

Produktfaktoren 


Analysiere Faktoren 

1. Identifiziere und beschreibe Faktoren 

2. Charaktersiere ihre Flexibilität und Änderbarkeit 

3. Analysiere ihre Auswirkungen 

Faktortabelle neue Faktoren 

Entwickle Strategien 

1. Identifiziere Probleme und Einflussfaktoren 

2. Entwickle Lösungen und spezifische Strategien 

3. Identifiziere verwandte Strategien 

neue Faktoren 

neue Probleme 

oder Strategien 

Problem− 

karten 

Einfluss 

Rückkopplung 

Blickwinkel 

Abschließende 

Entwurfsaufgabe 

Zentrale Entwurfs− 

aufgabe 



Globale Analyse: Analysiere Faktoren 

1. Identifiziere und beschreibe Faktoren 

Beispiele: 

Faktoren, die viele Komponenten betreffen 

Faktoren, die sich über die Zeit ändern 

Faktoren, die schwer zu erfüllen sind 

Faktoren, mit denen man wenig Erfahrung hat 

Umfang funktionaler Anforderungen 

Abgabetermin 

Stabilität der Hardware-Plattform 




2.a Charakterisiere ihre Flexibilität 

Flexibilität 

Kann zu Beginn über Faktoren verhandelt werden mit Beteiligten 

(Manager, Marketingleute, Kunde, Benutzer etc.)? 

Relevante Fragen zur Flexibilität (am Beispiel Auslieferung der 

Funktionalität): 

Kann der Faktor beeinflusst oder geändert werden, so dass der 

Architekturentwurf vereinfacht werden kann? 

Auslieferung der Funktionalität ist verhandelbar. Weniger wichtige 

Funktionalität kann in späterem Release ausgeliefert werden. 

Wie kann man ihn beeinflussen? 

Nur nach rechtzeitiger Absprache mit dem Kunden. 

Zu welchem Grad kann man ihn beeinflussen? 

Der Kunde hat Mindestanforderungen, die erfüllt werden müssen. 




2.b Charakterisiere ihre Veränderlichkeit 

Veränderlichkeit 

Kann sich der Faktor während der Entwicklung ändern? 

Relevante Fragen (am Beispiel Auslieferung der Funktionalität): 

In welcher Weise kann sich der Faktor ändern? 

Prioritäten könnten sich ändern. 

Anforderungen könnten wegfallen, weil nicht mehr relevant. 

Anforderungen könnten hinzukommen, weil sich Rahmenbedingungen 

geändert haben. 

Wie wahrscheinlich ist die Änderung während und nach der 

Entwicklung? 

Moderat während der Entwicklung; sehr hoch danach. 

Wie oft wird er sich ändern? 

Alle 3 Monate. 

Wird der Faktor betroffen von Änderungen anderer Faktoren? 

Änderung technologischer Aspekte (Software-/Hardware-Plattform). 




3. Analysiere die Auswirkungen der Änderung von Faktoren auf Architektur 

Auswirkungen 

Wenn sich der Faktor ändert, was würde davon betroffen und wie? 

Auswirkungen auf: 

Andere Faktoren 

Z.B. moderater Einfluss auf Einhaltung des Zeitplans und damit darauf, 

was zu welchem Zeitpunkt ausgeliefert werden kann 

Systemkomponenten 

Z.B. geplante Komponenten müssen überarbeitet werden; 

Komponenten können hinzu kommen oder wegfallen. 

Operationsmodi des Systems 

Andere Entwurfsentscheidungen 

. . . 



Faktortabelle zu organisatorischen Aspekten 

Faktor Flexibilität und 


Auswirkung 

O1 : Entwicklungsplan 

O1.1 : Time-To-Market 

Auslieferung Keine Flexibilität Nicht alle Funktionen können 

Juli 2009 

implementiert werden 

O1.2 : Auslieferung von Produktfunktionen 

priorisierte Funktionen sind verhandelbar Die Reihenfolge bei der 

Funktionen 

Implementierung der 

Funktionen kann sich ändern 

O2 : Enwicklungsbudget 

O2.1 : Anzahl Entwickler 

5 Entwick- Keine neuen Entwickler Moderater Einfluss auf 

ler 

können eingestellt werden. Zeitplan; partielle 

Entwickler können (temporär) 

ausfallen. 

Implementierung droht 



Weitere organisatorische Beispielfaktoren I 

O1: Management 

Selbst herstellen versus kaufen 

Zeitplan versus Funktionsumfang 

Umgebung 

Geschäftsziele 

O2: Personal: Fähigkeiten, Interessen, Stärken, Schwächen 

Anwendungsdomäne 

Softwareentwurf 

Spezielle Implementierungstechniken 

Spezielle Analysetechniken 



Weitere organisatorische Beispielfaktoren II 

O3: Prozess und Entwicklungsumgebung 

Entwicklungsplattform 

Entwicklungsprozess und -werkzeuge 

Prozesse und Werkzeuge des Konfigurationsmanagements 

Produktionsprozesse und -werkzeuge 

Testprozesse und -werkzeuge 

Releaseprozesse und -werkzeuge 

O4: Entwicklungszeitplan 

Time-To-Market 

Auslieferung der Produktfunktionen 

Release-Zeitplan 



Weitere organisatorische Beispielfaktoren III 

O5: Entwicklungsbudget 

Anzahl Entwickler 

Kosten von Entwicklungswerkzeugen 



Faktortabelle zu technischen Aspekten 



T2 : Domänenspezifische Hardware 

T2.1 : Aufzeichungs-Hardware 

Nimmt Signal auf. Neuere Versionen alle 3 

Jahre. 

T2.2 : Netzwerk 

Kommunikation 

zwischen Aufzeichnung 

und allgemeiner 

Hardware 

Neuere Versionen alle 4 

Jahre 

Auswirkung 

Großer Einfluss auf 

Aufzeichnungs- und 

Bildverarbeitungskomponenten 

Großer Einfluss auf 

Aufzeichnungs- und 

Bildverarbeitungskomponenten 



Technische Beispielfaktoren I 

T1: Hardware 

Prozessoren 

Netzwerk 

Hauptspeicher 

Plattenspeicher 

domänenspezifische Hardware 

T2: Software 

Betriebssystem 

Benutzerschnittstelle 

Software-Komponenten 

Implementierungssprache 

Entwurfsmuster 

Rahmenwerke 



Technische Beispielfaktoren II 

T3: Architekturtechnologie 

Architekturstile/-muster und -rahmenwerke 

Domänenspezifische Architekturen oder Referenzarchitekturen 

Architekturbeschreibungssprachen 

Software-Produktlinien-Technologien 

Werkzeuge zur Analyse und Validierung von Architekturen 

T4: Standards 

Schnittstelle zum Betriebssystem (z.B. Posix) 

Datenbanken (z.B. SQL) 

Datenformate 

Kommunikation (z.B. TCP/IP) 

Kodierrichtlinien 



Faktortabelle zu Produktfaktoren 



Auswirkung 

P3 : Funktionale Eigenschaften 

P3.2 : Performanz der Aufzeichnung 

Performanz: Größe und Etwas flexibel. Große Auswirkung auf 

Anzahl von Bildern; 

alle Komponenten für 

Antwortszeit: 

Aufzeichnung, 

Ein-Ausgabe-Deadlines 

Bildverarbeitung, 

Speicherung und 

Betrachtung; 

Auswirkung variiert mit 

Performanztuning. 



Beispielproduktfaktoren I 

P1: Produktfunktionen 

P2: Benutzerschnittstelle 

Interaktionsmodell 

Funktionen der Benutzerschnittstelle 

P3: Performanz 

Ausführungszeiten 

Speicherbedarf 

Dauer des Systemstarts und -endes 

Wiederherstellungszeit nach Fehlern 



Beispielproduktfaktoren II 

P4: Verlässlichkeit 

Verfügbarkeit 

Zuverlässigkeit 

Sicherheit 

P5: Fehlererkennung, -bericht, -behandlung 

Fehlerklassifikation 

Fehlerprotokollierung 

Diagnostik 

Wiederherstellung 



Beispielproduktfaktoren III 

P6: Service 

Service-Dienste (Konfigurations- und Wartungsdienste) für den 

Betrieb des System 

Installation und Aktualisierung 

Test der Software 

Wartung und Erweiterung der Systemimplementierung 

P7: Produktkosten 

Hardwarebudget 

Softwarelizenzbudget (für verwendete Software) 



Globale Analyse: Entwickle Strategien I 

1. Identifiziere Probleme und deren Einflussfaktoren 

Analysiere Faktorentabelle: 

Grenzen oder Einschränkungen durch Faktoren 

Unverrückbarer Abgabetermin erlaubt keinen vollen Funktionsumfang 

Notwendigkeit, Auswirkung eines Faktors zu begrenzen 

Entwurf muss Portierbarkeit vorsehen 

Schwierigkeit, einen Produktfaktor zu erfüllen 

Speicher- und Prozessorbegrenzung erlaubt keine beliebig komplexen 

Algorithmen 

Notwendigkeit einer allgemeinen Lösung zu globalen Anforderungen 

wie Fehlerbehandlung und Wiederaufsetzen nach Fehlern 



Globale Analyse: Entwickle Strategien II 


. . . für die Behandlung der Probleme, die sich implementieren lassen und 

die notwendige Änderbarkeit unterstützen. 

Strategie muss konsistent sein zu: 

Einflussfaktor, 

dessen Veränderlichkeit 

und dessen Interaktion mit anderen Faktoren. 



Globale Analyse: Entwickle Strategien III 


Ziele: 

Reduzierung oder Kapselung des Faktoreinflusses 

Reduzierung der Auswirkung einer Änderung des Faktors auf den 

Entwurf und andere Faktoren 

Reduzierung oder Kapselung notwendiger Bereiche von 

Expertenwissen oder -fähigkeiten 

Reduzierung der Gesamtentwicklungsdauer und -kosten 

3. Identifiziere verwandte Strategien 



Globale Analyse: Entwickle Strategien IV 

Problemkarten (Issue Cards) beschreiben Problem und passende Strategien 

einmalig: 

Name des Problems 

Beschreibung des Problems 


Liste aller Einflussfaktoren 

Lösung 

Diskussion einer allgemeinen Lösung 

Strategie: Name der Strategie A 

Erläuterung der Strategie A 

Strategie: Name der Strategie B 

Erläuterung der Strategie B 

. . . 

Verwandte Strategien 

Referenzen zu verwandten Strategien. 

Diskussion, in welcher Weise sie verwandt sind. 



Beispiele 

Ambitionierter Zeitplan 

Abgabetermin ist fix, Ressourcen sind begrenzt. Möglicherweise können 

nicht alle Produktfunktionen realisiert werden. 


O1.1 : Time-To-Market 

O1.2 : Auslieferung von Produktfunktionen 

O2.1 : Anzahl Entwickler 

Lösung 

Strategie: Schrittweiser Ausbau 

System wird schrittweise ausgebaut. Anforderungen werden in der Reihenfolge 

ihrer Priorität realisiert. 

Strategie: Einkaufen statt Selbstentwickeln 

Einbindung externer COTS-Komponenten. 

Strategie: Wiederverwendung 

Einbindung interner wiederverwendbarer Komponenten. 



Änderungen in allgemeiner und domänenspezifischer Hardware 

Regelmäßige Änderungen der Hardware; Software soll mit minimalen 

Aufwand an Änderungen angepasst werden können. 


T1.1: Prozessoren werden leistungsfähiger. 

T2.1: Aufzeichnungs-Hardware ändert sich alle drei Jahre 

T2.2: Netzwerktechnologie ändert sich alle vier Jahre 

Lösung 

Strategie: Kapselung domänenspezifischer Hardware: 

Kapsle Details, die sich ändern können. 

Strategie: Kapselung allgemeiner Hardware: 

Kapsle Details, die sich ändern können. 



Betriebssystemanpassung 

Weiterentwicklung des Betriebssystems (BS) und Wechsel auf ein neues 

BS machen Anpassungen an betriebssystemspezifischen Komponenten 

notwendig. Für die Wartung steht nur ein Entwickler zur Verfügung. Die 

Anpassungen müssen schnell vorgenommen werden. 


O1.1: Time-To-Market 

O2.1: Anzahl Entwickler 

T2.3: Betriebssystem 

Lösung 

Strategie: Kapselung der BS-abhängigen Anteile 

BS-abhängige Anteile werden in Komponenten isoliert. Diese bilden eine 

virtuelle Maschine für alle anderen Komponenten. 



Gebäudearchitektur 

2009-02-09 




Architektursichten und -blickwinkel 



In der Gebäudearchitektur ist es üblich, von einem zu bauenden Gebäude verschiedene Modelle zu erstellen, bevor 

das Gebäude tatsächlich gebaut wird. Teilweise werden die Modelle als Prototypen benutzt, um dem zukünftigen 

Hausbesitzer einen Eindruck von der Ästhetik oder Funktion zu vermitteln. Teilweise sind die Modelle Pläne, wie es 

nachher tatsächlich werden soll. Es wird dabei stets eine Vielzahl unterschiedlicher Modelle erstellt, die jeweils 

bestimmte Aspekte betonen und von anderen abstrahieren. Der Grund liegt daran, dass unterschiedliche Personen, 

die am Gebäudebau beteiligt sind, das Gebäude aus unterschiedlichen Perspektiven betrachten wollen. Der spätere 

Besitzer interessiert sich für das Gesamterscheinungsbild, der Maurer für den Gebäuderahmen und der Elektriker für 

Kabelschächte, Steckdosen, Schalter etc. Das Prinzip, Unterschiedliches auseinander zu halten, ist in der 

Softwaretechnik als Separation of Concerns bekannt: die Trennung unterschiedlicher Belange. Dieses Prinzip wird 

auch beim Softwarearchitekturentwurf angewandt. Man nennt diese unterschiedlichen Baupläne oft Sichten der 

Architektur. 

Während sich in der Gebäudearchitektur über viele Jahre feste Normen zu Bauzeichnungen, das heißt, 

Architektursichten, etabliert haben, stehen wir in der Softwaretechnik noch ganz am Anfang einer Entwicklung hin 

zu normierten Architektursichten. Ein erster Meilenstand auf diesem Weg ist der IEEE-Standard IEEE P1471 

(2002) Recommended Practice for Architectural Description of Software-intensive Systems. Er stellt Richtlinien auf, 

wie man Sichten der Softwarearchitektur beschreiben soll. Da aber noch Uneinigkeit herrscht, welche Sichten der 

Softwarearchitektur überhaupt relevant sind, legt er uns nicht auf eine feste Menge solcher Sichten fest. Er geht 

viel mehr einen indirekten Weg. Er überlässt es uns, zu entscheiden, welche Sichten wir beschreiben wollen, fordert 

aber, dass für alle unsere Sichten definiert ist, was sie bedeuten.



Definition 

Architektursicht (View): Repräsentation eines ganzen Systems aus der 

Perspektive einer kohärenten Menge von Anliegen (IEEE P1471 2002). 

Definition 

Architekturblickwinkel (Viewpoint): Spezifikation der Regeln und 

Konventionen, um eine Architektursicht zu konstruieren und zu 

benutzen (IEEE P1471 2002). 

Ein Blickwinkel ist ein Muster oder eine Vorlage, von der aus individuelle 

Sichten entwickelt werden können, durch Festlegung von 

Zweck, 

adressierte Betrachter 

und Techniken für Erstellung, Gebrauch und Analyse. 

Unterschiedliche Sichten helfen der Strukturierung: Separation of 

Concerns. 


2009-02-09 






Definition 

Architektursicht (View): Repräsentation eines ganzen Systems aus der 

Perspektive einer kohärenten Menge von Anliegen (IEEE P1471 2002). 

Definition 

Architekturblickwinkel (Viewpoint): Spezifikation der Regeln und 

Konventionen, um eine Architektursicht zu konstruieren und zu 

benutzen (IEEE P1471 2002). 

Ein Blickwinkel ist ein Muster oder eine Vorlage, von der aus individuelle 

Sichten entwickelt werden können, durch Festlegung von 

Zweck, 

adressierte Betrachter 

und Techniken für Erstellung, Gebrauch und Analyse. 

Unterschiedliche Sichten helfen der Strukturierung: Separation of 

Concerns. 

Dazu führt der Standard eine Trennung von konkretem Inhalt und Bedeutung einer Sicht ein. Eine Architektursicht 

(im Englischen: View) ist die Repräsentation eines ganzen Systems aus der Perspektive einer kohärenten Menge von 

Anliegen (IEEE P1471 2002). Eine Architektursicht beschreibt also immer ein bestimmtes System, im Sinne der 

Gebäudearchitektur ist das also zum Beispiel die Facadenansicht des neuen Bürogebäudes in der Universitätsallee 

15. In der Software ist die Beschreibung der Klassen und ihrer Abhängigkeiten der Banksoftware PayMe der Version 

1.3 in Form eines Klassendiagramms eine Architektursicht. Damit man ein Klassendiagramme jedoch verstehen 

kann, muss beschrieben sein, welche Konstrukte in solch einem Diagramm auftauchen dürfen, was sie bedeuten und 

wie sie kombiniert werden können. Während das Klassendiagramm für PayMe spezifisch und damit nur für PayMe 

relevant ist, ist die Beschreibung, wie Klassendiagrammme an sich aussehen können und was sie bedeuten, 

übergreifend gültig für alle denkbaren Klassendiagramme unabhängig von den Systemen, die sie beschreiben. 

Für die Beschreibung aller möglichen Klassendiagramme führt der IEEE-Standard den Begriff 

Architekturblickwinkel (im Englischen: Viewpoint) ein. Ein Architekturblickwinkel (Viewpoint) ist die Spezifikation 

der Regeln und Konventionen, um eine Architektursicht zu konstruieren und zu benutzen (IEEE P1471 2002). Ein 

Blickwinkel ist ein Muster oder eine Vorlage, von der aus individuelle Sichten entwickelt werden können, durch 

Festlegung des Zwecks, der adressierten Betrachter und der Techniken für die Erstellung, den Gebrauch und die 

Analyse aller Sichten, die durch den Blickwinkel spezifiziert werden. 

Diese Trennung zwischen Sicht und Blickwinkel ist der eigentlich bedeutende Beitrag des genannten Standards. 

Das heißt für uns, wenn wir eine Architektur durch eine Sicht beschreiben wollen, müssen wir zunächst in Form des 

Blickwinkels die Bedeutung der Sicht spezifizieren.


Siemens-Blickwinkel (Hofmeister u. a. 2000) 

2009-02-09 

Konzeptioneller Blickwinkel: beschreibt logische Struktur des 

Systems; abstrahiert weitgehend von technologischen Details 

Modulblickwinkel: beschreibt die statische logische Struktur des 

Systems 

Ausführungsblickwinkel: beschreibt die dynamische logische 

Struktur des Systems 

Code-Blickwinkel: beschreibt die ” anfassbaren“ Elemente des 

Systems (Quelldateien, Bibliotheken, ausführbare Dateien etc.) 







Konzeptioneller Blickwinkel: beschreibt logische Struktur des 

Systems; abstrahiert weitgehend von technologischen Details 

Modulblickwinkel: beschreibt die statische logische Struktur des 

Systems 

Ausführungsblickwinkel: beschreibt die dynamische logische 

Struktur des Systems 

Code-Blickwinkel: beschreibt die ” anfassbaren“ Elemente des 

Systems (Quelldateien, Bibliotheken, ausführbare Dateien etc.) 

In der Literatur wurden sehr viele unterschiedliche Blickwinkel zur Beschreibung von Softwarearchitektur 

vorgeschlagen. Zachman (1987); Sowa und Zachman (1992); Zachman (1999) war einer der ersten Autoren, der 

Blickwinkel vorgeschlagen hat. Er schlug vor, Informationssysteme durch 6 × 6 verschiedene Blickwinkel zu 

beschreiben. Perry und Wolf (1992) haben mehrere Blickwinkel von Zachman zusammen gefasst und die Anzahl 

der Blickwinkel damit auf drei reduziert, die letzten Endes aber äquivalent sind und lediglich unterschiedliche 

Aspekte hervor heben. Von Kruchten (1995) stammen die 4+1-Blickwinkel. Dazu gehören der logische Blickwinkel, 

der das System abstrakt und anwendungsnah beschreibt, der Prozessblickwinkel, der die dynamische Ausführung 

beschreibt sowie der statische Entwicklungsblickwinkel und der physikalische Blickwinkel, der das System in die 

Hardware einbettet. Diese vier Blickwinkel werden zusammen gehalten durch einen redundanten Blickwinkel, der 

mittels Anwendungsszenarien beschreibt, wie die vier anderen Blickwinkel zusammen spielen. 

Die unterschiedlichen Blickwinkel in der Literatur sind verwirrend, zumal sehr viele Blickwinkel unterschiedlicher 

Autoren sehr ähnlich sind. Etwas Ordnung hat hier das Buch von (Clements u. a. 2002) geschaffen, in dem 

Kategorien von Blickwinkeln beschrieben sind. Dieses Buch ist auch zu empfehlen für die Frage, wie man 

Softwarearchitektur dokumentiert. 

Immerhin ist festzuhalten, dass viele der Blickwinkel sich auch auf die vier Siemens-Blickwinkel abbilden lassen 

(Hofmeister u. a. 2000). Es scheint, als ob mindestens die folgenden Aspekte zur Beschreibung eines Systems 

notwendig sind, die durch die vier Siemens-Blickwinkel abgedeckt werden: 

• Konzeptioneller Blickwinkel: beschreibt die logische Struktur des Systems. Er abstrahiert weitgehend von 

technologischen Details wie z.B. konkrete Technologien, mit denen das System implementiert wird. Dieser Blickwinkel 

ist der Anwendungsdomäne am nächsten. 

• Modulblickwinkel: beschreibt die statische logische Struktur des Systems in Form von Modulen und ihren 

Abhängigkeiten. 

• Ausführungsblickwinkel: beschreibt die dynamische logische Struktur des Systems, das heißt, die Ausführung und 

Einbettung in die ausführende Hardware. 

• Code-Blickwinkel: beschreibt die ” anfassbaren“ Elemente des Systems (Quelldateien, Bibliotheken, ausführbare Dateien 

etc.). 

Die vier Siemens-Blickwinkel wurden durch Befragung praktizierender Softwarearchitekten bei Siemens ermittelt,



2009-02-09 

Software−Architektur 

Konzeptioneller Blickwinkel 

Komponenten 

Konnektoren 

Konfiguration 

Module 

Subsysteme 

Schichten 

Modulblickwinkel 

Modul− 

beschränkungen 

neue 

Modula− 

risierung 

Code−Blickwinkel 

Quell−Code 

Komponenten 

Konnektoren 

Konfiguration 

Laufzeit− 

beschränk− 

ungen 

Module 

neue 

Modula− 

risierung 

Laufzeit− 

elemente 

Änderungen 

an Laufzeit− 

elementen 

Ausführungsblickwinkel 

Hardware−Architektur 

Einfluss 

Rückkopplung 







Software−Architektur 


Komponenten 

Konnektoren 

Konfiguration 

Module 

Subsysteme 

Schichten 


Modul− 

beschränkungen 

neue 

Modula− 

risierung 


Quell−Code 

Komponenten 

Konnektoren 

Konfiguration 

Laufzeit− 

beschränk− 

ungen 

Module 

neue 

Modula− 

risierung 

Laufzeit− 

elemente 

Änderungen 

an Laufzeit− 

elementen 

In der Methode von Hofmeister u. a. (2000) sind diese vier Blickwinkel der Gegenstand des Entwurfes. Die 

Softwarearchitektur wird entworfen, indem Sichten zu diesen vier Blickwinkeln erstellt werden. 

Wir werden im Folgenden näher auf diese Blickwinkel eingehen, indem wir sie im Kontext der Hofmeister-Methode 

beschreiben. 



Einfluss 

Rückkopplung


2009-02-09 






− Faktoren 

− Strategien 


aufgabe 

− Komponenten 

− Konnektoren 

− Konfiguration 

globale Evaluation 



Quell−Code 



− Ressourcenbudget 



Einfluss 

Rückkopplung 










− Faktoren 



aufgabe 

− Komponenten 

− Konnektoren 

− Konfiguration 




Quell−Code 



− Ressourcenbudget 

Der Ausgangspunkt des Architekturentwurfes ist der konzeptionelle Blickwinkel. Mit Hilfe dieses Blickwinkels wird 

die logische Struktur der angestrebten Architektur beschrieben. Ähnlich wie beim Datenbankentwurf, wo wir 

zunächst von einem konzeptionelle Schema ausgehen, das die Daten beschreibt so wie sie in der 

Anwendungsdomäne sind. Es handelt sich noch nicht um den Entwurf einer konkreten Datenbank für das 

Anwendungsproblem, der ja letztlich stark von der verwendeten Technologie abhängt. In der Gebäudearchitektur 

gleicht der logische Blickwinkel, den ersten Skizzen, die der Architekt von dem späteren Haus macht. Dabei will er 

den Kopf noch frei haben von Detailentscheidungen, welche Heizung eingebaut wird etc. 

Ausgehend von der globalen Analyse der Einflussfaktoren, entwirft der Softwarearchitekt die Hauptkomponenten 

und -konnektoren des Systems. Eine Komponente ist eine Berechnungseinheit oder eine Einheit, die Daten 

speichert. Dabei geht es nicht um einzelne Klassen oder gar spezifischen Algorithmen und Datenstrukturen, 

sondern um die grobe Verteilung der Zuständigkeiten in einem System auf größere Bausteine. Wie umfangreich so 

ein Baustein ausfällt, hängt von der Größe des Systems ab. Je größer das System, desto größer werden die 

Komponenten initial ausfallen. Große Komponenten können dann später verfeinert werden. Ein Beispiel für eine 

Komponente in einem größeren System ist etwa eine Datenbank, in einer Client-Server-Architektur wären sowohl 

Client als auch Server erste Komponenten. 

Komponenten interagieren miteinander, um eine gemeinsame Aufgabe zu erfüllen. Hierzu sind sie über so genannte 

Konnektoren verbunden. Ein Konnektor stellt den Kontroll- und Datenfluss zwischen Komponenten dar. Primitive 

Konnektoren sind Methodenaufrufe, Parameterübergabe und Zugriffe auf Attribute. Komplexere Konnektoren sind 

beispielsweise Mechanismen zur Interprozesskommunikation. 

Die Verbindung der Komponenten durch Konnektoren ergibt die Konfiguration. Ist eine Konfiguration entstanden, 

kann sie durch ein Review begutachtet werden. Ein Evaluationskriterium ist zum Beispiel, ob die Komponenten und 

Konnektoren alle geforderten Anwendungsfälle auch tatsächlich unterstützen. Hierzu kann man auf dem Papier 

überlegen, was die Komponenten und Konnektoren alles machen würden für jeden einzelnen Anwendungsfall. 

Abschließend werden noch die Ressourcen für Komponenten und Konnektoren eingeplant, also wie viel Speicher 

und Rechenzeit Komponenten und Konnektoren zuerkannt bekommen. 



Einfluss 

Rückkopplung


Konzeptioneller Blickwinkel (Hofmeister u. a. 2000) 

ist der Anwendungsdomäne am nächsten 

Systemfunktionalität wird abgebildet auf 

Konzeptionelle Komponenten: rechenbetonte Elemente oder 

Datenhaltung 

Konnektoren: Kontroll- und Datenfluss zwischen konzeptionellen 

Komponenten 

Engineering-Belange: 

2009-02-09 

Wie erfüllt das System seine Anforderungen? 

Wie werden Commercial-off-the-Shelf-Components (COTS) in das 

System integriert? 

Wie wird domänenspezifische Soft- und Hardware einbezogen? 

Wie kann die Auswirkung von Anforderungen oder der 

Anwendungsdomäne minimiert werden? 







ist der Anwendungsdomäne am nächsten 

Systemfunktionalität wird abgebildet auf 

Konzeptionelle Komponenten: rechenbetonte Elemente oder 

Datenhaltung 

Konnektoren: Kontroll- und Datenfluss zwischen konzeptionellen 

Komponenten 


Wie erfüllt das System seine Anforderungen? 

Wie werden Commercial-off-the-Shelf-Components (COTS) in das 

System integriert? 

Wie wird domänenspezifische Soft- und Hardware einbezogen? 

Wie kann die Auswirkung von Anforderungen oder der 

Anwendungsdomäne minimiert werden? 

Wie gesagt, steckt hinter der Aufteilung in Blickwinkel das Prinzip der Trennung unterschiedlicher Belange. Welche 

Belange adressiert der konzeptionelle Blickwinkel also? Es geht dabei um die folgenden Fragen: 

• Wie erfüllt das System seine Anforderungen? 

• Wie werden Commercial-off-the-Shelf-Components (COTS) in das System integriert, falls dies geplant ist? 

• Wie wird domänenspezifische Soft- und Hardware einbezogen? 

• Wie kann die Auswirkung von Anforderungen oder der Anwendungsdomäne minimiert werden? Idealerweise sollte man 

nur eine Komponente anfassen müssen, wenn sich eine neue Anforderung aus der Anwendungsdomäne ergibt. Dazu 

muss man jedoch die möglichen Änderungen vorwegsehen und die Architektur entsprechend so entwerfen, dass es leicht 

fallen wird, die zukünftige Anforderung zu realisieren.



2009-02-09 

* 

CComponent 

cbinding 

* 

* 

* 

CPort 

Conceptual Configuration 

* connection * 

obeys 

1 

* 

0..1 

CConnector 

0..1 0..1 0..1 * 0..1 

0..1 

CRole 

* * 

obeys 

Protocol 

1 1 conjugate 

1 

* 

* 

cbinding 






* 

* 


* 

* 

CComponent 


1 

* 

CConnector 

0..1 0..1 0..1 * 0..1 

0..1 

cbinding 

cbinding 

* 

* 

* 

CPort 


CRole 

* 

* * 

0..1 

obeys 

obeys 

Protocol 

1 1 conjugate 

Nachdem wir nun die Rolle und den Zweck des konzeptionellen Blickwinkels kennen, betrachten wir näher, wie eine 

konzeptionelle Sicht aufgebaut sein kann. Wir wenden uns also der Frage zu, wie der logische Blickwinkel eigentlich 

aussieht. 

Wir haben bereits über die prinzipiellen Modellierungselemente gesprochen: Komponenten, Konnektoren und die 

Art und Weise, wie sie in einer Konfiguration angeordnet werden. 

Das folgende Diagramm in UML beschreibt den logischen Blickwinkel genauer: 

* 

CComponent 

cbinding 

* 

* 

* 

CPort 



obeys 

1 

* 

CConnector 

0..1 0..1 0..1 * 0..1 

0..1 

0..1 

CRole 

* * 

obeys 

Protocol 

1 1 conjugate 

1 

* 

* 

cbinding 

Wie wir sehen, besteht eine Konfiguration aus einer Menge von Komponenten und Konnektoren. Sowohl 

Komponenten als auch Konnektoren können verfeinert werden, was die Komposition andeutet. Wenn eine 

Komponente verfeinert wird in Teilkomponenten, müssen diese selbstverständlich auch über Konnektoren wieder 

verbunden werden. Aus diesem Grunde ist auch die Komposition zwischen Konnektoren und Komponenten 

zwingend notwendig. Ähnliches gilt für die Verfeinerung von Komponenten. Hiermit können wir beschreiben, wie 

ein Konnektor durch Teilkomponenten und deren Konnektoren implementiert wird. 

* 

* 

1 

* 

*

2009-02-09 






* 

* 

CComponent 


1 

* 

CConnector 

0..1 0..1 0..1 * 0..1 

0..1 

cbinding 

cbinding 

* 

* 

* 

CPort 


CRole 

* 

* * 

0..1 

obeys 

obeys 

Protocol 

1 1 conjugate 

Zur Verbindung von Komponenten und Konnektoren existieren entsprechende Beschreibungselemente: Anschlüsse 

(Ports) und Rollen (Roles). Ein Anschluss (Port) ist ein Teil der Komponente. Das Pendant hierzu für Konnektoren 

ist die Rolle (Role). Wenn wir also beispielsweise eine Kommunikation zwischen einem Client und einem Server 

beschreiben wollen, dann werden diese zwei Komponenten über einen Konnektor für die Interprozesskommunikation 

verbunden, wie im oberen Teil der folgenden Grafik dargestellt: 

Die Kommunikation dient dem Datenaustausch, deshalb wird hierfür ein Query-Konnektor verwendet, der für 

Anfragen an Server gedacht ist. UML-Stereotypen beschreiben die Diagrammelemente. Die Stereotypen 

entstammen dem konzeptionellen Blickwinkel. 


Komponenten und Konnektoren 


1 

* 

*

2009-02-09 






Eine solche Kommunikation ist im Falle einer Client-Server-Architektur asymmetrisch, das heißt, der Konnektor 

wird unterschiedlich benutzt von den Komponenten. Während der Server am Konnektor auf eingehende Anfragen 

wartet und diese dann beantwortet, ergreift der Client die Initiative und schickt dem Server seine Anfragen. Der 

Query-Konnektor für die Interprozesskommunikation hat also eine Rolle für den Client und eine für den Server. Der 

Teil der Komponente, der die jeweilige Rolle, die durch einen Konnektor vorgegeben wird, anspricht ist der Port. 

Angenommen der Query-Konnektor wird durch später durch Remote Method Invocation (RMI) in Java 

implementiert, dann kann man sich den Port konkret vorstellen als der Code in der Komponente, der den 

RMI-Aufruf absetzt. 

Konnektoren beschreiben Kontroll- und/oder Datenfluss. Man kann entweder auf die allgemeinen Databeziehungsweise 

Control-Konnektoren zurück greifen oder aber sich seine eigenen Konnektoren definieren. In der 

zweiten Zeile des Diagramms sehen wir zum Beispiel einen allgemeinen Data-Konnektor für den Datenaustausch 

zwischen einem Produzenten und Konsumenten und in der dritten Zeile einen Control-Konnektor, der einen 

Observer benachrichtigt, wann immer sich eine observierte Komponenten in ihrem Zustand ändert. Die letzte Zeile 

beschreibt einen selbst definierten Konnektor für den Datenaustausch über eine Pipe, wie das zum Beispiel in Unix 

unterstützt wird. 

Die Verbindung von Komponenten und Konnektoren ist bislang rein strukturell dargestellt. Das bisher Gesagte 

beschreibt nur, dass Komponenten und Konnektoren interagieren, aber nicht wie. Wie eine Interaktion aussieht, 

wird durch ein Protokoll beschrieben, also etwa die Reihenfolge, in der Operationen ausgeführt werden. Der Port 

einer Komponente hat ein Protokoll, ebenso erwartet der Konnektor für eine Rolle eine vorgegeben 

Verwendungsweise, hat also auch ein Protokoll. Diese beiden Protokoll müssen selbstverständlich kompatibel sein. 

Zu der Bedeutung und den Einschränkungen von cbinding kommen wir später noch. 


Strategie 

Lege externe Schnittstellen fest. 

probeCommands 

probeData 

:IS2000 

networkAccess 


userAcqControl userAcqDisplay userImageExport

2009-02-09 

2009-02-09 




Strategie 


Wir illustrieren nun an unserem laufenden Beispiel, wie die Hofmeister-Methode eine konzeptionellen Sicht entwirft. 

Ausgangspunkt sind die Strategien, die wir in der globalen Analyse aufgestellt haben, um mit Entwurfskonflikten 

umzugehen. Sie werden nun eingesetzt. 

Wir beschreiben den Entwurfsprozess top-down, das heißt, wir beginnen im Folgenden mit dem System als eine 

große Komponente und verfeinern sie weiter. Das ist ein gängiges Vorgehen. Sollen aber existierende Komponenten 

wiederverwendet werden, dann kombiniert man den Top-Down-Ansatz mit einem Bottom-Up-Vorgehen. Letzterer 

geht von den existierenden Komponenten aus und baut sie zu einem größeren Ganzen sukzessive zusammen. In der 

Kombination entwirft man sowohl top-down als auch bottum-up und versucht, die beiden Entwurfsrichtungen 

aufeinander zuzuführen. Beim reinen Top-Down-Vorgehen kann es dazu kommen, dass existierende Komponenten 

nicht wiederverwendet werden, weil sie nicht das Gefüge passen; außerdem können redundante Komponenten 

entstehen. Erfahrene Architekten beherrschen beide Richtungen. 




probeCommands 

probeData 

:IS2000 

Strategie 


Wir beginnen hier also zunächst mit dem System als eine einzige Komponente. In der Anforderungsanalyse haben 

wir uns bereits damit auseinander gesetzt, welche Schnittstellen nach außen das System bieten muss. Diese werden 

nun eingezogen. Es ergibt sich das folgende Bild: 

probeCommands 

probeData 

:IS2000 

networkAccess 

Die schwarzen Kästchen am Rande der Komponente sind ihre Ports, das heißt, ihre Schnittstellen nach außen. 

userAcqControl userAcqDisplay userImageExport 

probeCommands 

probeData 

:IS2000 

networkAccess 

networkAccess 




Strategie 

Führe Komponenten für Aufzeichnung, Bearbeitung und Export ein. 

2009-02-09 

probeCommands 

probeData 

:IS2000 

receiver sender 

:Control 

:Acquisition 

source dest 

:Imaging 

:Data 

:Exporting 

networkAccess 






Strategie 


Nun führen wir Komponenten für Aufzeichnung, Bearbeitung und Export ein. Diese Aufteilung folgt dem 

EVA-Prinzip (Eingabe/Verarbeitung/Ausgabe) und stellt eine Umsetzung des Strategie Separation of Concern dar. 

Die inneren Komponenten werden über innere Konnektoren verbunden. Hier gilt die Regel, dass eine Verbindung 

zwischen einem Port und einer Rolle nur möglich ist, wenn die zugehörigen Komponenten und Konnektoren im 

selben anderen Element (Komponente oder Konnektor) enthalten sind. Mit anderen Worten, die Verbindung kann 

keine Abstraktionsebene durchqueren. Wir stellen fest, dass die Komponenten und Konnektoren wie gefordert Teil 

der selben Komponente sind. Damit ist das Diagramm in diesem Punkt wohlgeformt. 

probeCommands 

probeData 

:IS2000 

sender 

receiver 

:Control 

:Acquisition 

source dest 

:Imaging 

:Data 

:Exporting 

networkAccess 


probeCommands 

probeData 

:IS2000 

sender 

receiver 

:Control 

:Acquisition 

source dest 

:Data 

:Imaging 

:Exporting 

networkAccess 


2009-02-09 




Strategie 


Wir erkennen des Weiteren eine Verbindung zwischen zwei Ports und zwar von den inneren Komponenten zu den 

Ports der umgebenden Komponente. Dies sind die so genannten CBindings, auf die wir bislang noch nicht 

eingegangen sind. Sie dienen dazu, darzustellen wie die äußeren Ports auf die inneren Ports beziehungsweise die 

äußeren Rollen auf die inneren Rollen abgebildet werden, stellen also den Kontext der äußeren Schnittstellen zum 

inneren Aufbau her. Hier ist die Regel, dass ein CBinding von einem inneren Ports nur zu einem Port der 

unmittelbar umschließenden Komponente verlaufen darf. Entsprechendes gilt für ein CBinding zwischen Rollen. Das 

Diagramm hält sich auch an diese Regel. 


Strategie 

Kapselung domänenspezifischer Hardware. 

probeCommands 

probeData 

:Probe 

Control 


:Control 

:Data 

Collection 

:IS2000 


:Control 

:Acquisition 

source dest 

:Imaging 

:Data 

:Exporting 

probeCommands 

probeData 

:IS2000 

networkAccess 


sender 

receiver 

:Control 

:Acquisition 

source dest 

:Data 

:Imaging 


:Exporting 

networkAccess 


2009-02-09 




Strategie 

Kapselung domänenspezifischer Hardware. 

Im nächsten Schritt wenden wir die Strategie der Kapselung domänenspezifischer Hardware an, damit wir vor 

Änderungen dieser Hardware weitgehend geschützt sind. Dazu führen wir zwei weitere Teilkomponenten ein, die 

von den Eigenschaften der Eingabe-Hardware abstrahieren, die sich ändern können. Diese beiden Komponenten 

stellen Gerätetreiber dar. 

probeCommands 

probeData 

:Probe 

Control 

sender 

receiver 

:Control 

:Data 

Collection 

:IS2000 

sender 

receiver 

:Control 

:Acquisition 

source dest 

:Imaging 

:Data 

:Exporting 

networkAccess 

Wir erkennen in diesem Diagramm, wie die Anschlussbindung der innersten Komponenten zu den äußersten 

Systemschnittstellen von IS2000 über zwei Ebenen hinweg erfolgt. 


Strategie 

Entkopple Interaktionsmodell. 

probeCommands 

probeData 

:Probe 

Control 


:Control 

:Data 

Collection 

:IS2000 


:Control 

:Acquisition 

source dest 

:Imaging 

:Data 


:Exporting 

probeCommands 

probeData 

:Probe 

Control 

sender 

receiver 

:Control 

:Data 

Collection 

:IS2000 

:Acquire 

:Monitor 

networkAccess 


sender 

receiver 

:Control 

:Acquisition 

source dest 

:Data 

:Imaging 


:Exporting 

networkAccess 


2009-02-09 




Strategie 

Entkopple Interaktionsmodell. 

Um auch gefeit zu sein gegen Änderungen in der Art und Weise, wie mit dem Benutzer interaktiv kommuniziert 

wird, führen wir analog zu den Gerätetreibern eigene Teilkomponenten ein, die von Eingabe beziehungsweise 

Ausgabe von und zum Benutzer abstrahieren. Wir wenden damit eine Strategie zur Entkopplung des 

Interaktionsmodells an. 


Strategie 

probeCommands 

probeData 

:Probe 

Control 

sender 

receiver 

:Control 

:Data 

Collection 

:IS2000 

sender 

receiver 

:Control 

:Acquisition 

source dest 

:Imaging 

:Data 

:Exporting 

Separiere nach Anliegen: Separation of Concern. 

probeCommands 

probeData 

:Probe 

Control 


:Control 

:Data 

Collection 

:IS2000 

:Acquire 

:Monitor 

networkAccess 



:Control :Control 


:Control 

:Acquisition 

Management 

source dest 

:Imaging 

:Data 


:Exporting 

probeCommands 

probeData 

:Probe 

Control 

sender 

receiver 

:Control 

:Data 

Collection 

:IS2000 

:Acquisition 

:Acquire 

:Monitor 

networkAccess 


sender 

receiver 

:Control 

:Acquisition 

source dest 

:Data 

:Imaging 


:Exporting 

:Acquire 

:Monitor 

networkAccess 


2009-02-09 




Strategie 

Separiere nach Anliegen: Separation of Concern. 

probeCommands 

probeData 

:Probe 

Control 

sender 

receiver 

:Control 

:Data 

Collection 

:IS2000 

:Acquisition 



:Acquisition 


Management 

:Acquire 

Die Trennung in der Komponente Acquisition in zwei Teilkomponenten führt dazu, dass die verbleibende 

Funktionalität dieser Komponente, die weder hardware-spezifisch noch spezifisch für das Interaktionsmodell ist, in 

einer weiteren Komponente Aquisition-Management versammelt werden muss. 


Strategie 

probeCommands 

probeData 

:Probe 

Control 

sender 

receiver 

:Control 

:Data 

Collection 

:IS2000 

:Acquisition 

Management 




sender 

receiver 

:Control 

source dest 

Separiere zeitkritische Komponenten. 

probeCommands 

probeData 

:Probe 

Control 


:Control 

:Data 

Collection 

:IS2000 

:Image 

Processing 

:Imaging 

source dest source dest 

:Data 

:Exporting 

:Acquisition 

:Acquire 

:Monitor 

networkAccess 





:Control 

:Acquisition 

Management 

:Data :Data :Data 

source dest 

:Data 


:Control 

:Post 

Processing 


source dest 

:Exporting 

:Acquisition 

:Acquire 

:Imaging 

:Monitor 

networkAccess 


sender 

receiver 

:Control 

source dest 

:Data 

:Imaging 


:Exporting 

:Monitor 

networkAccess 


2009-02-09 




Strategie 

Separiere zeitkritische Komponenten. 

probeCommands 

probeData 

:Probe 

Control 

sender 

receiver 

:Control 

:Acquisition 



:Acquisition 


Management 

:Acquire 

sender 

receiver 

:Control 

:Imaging 


source dest 

:Data 

:Image 

:Post 


Collection 

Processing 

Processing 

:Monitor 

In analoger Weise müssen wir auch bei der Komponente Imaging so verfahren. Hier nehmen wir aber noch eine 

weitere Verfeinerung vor. Und zwar trennen wir Algorithmen mit Echtzeitanforderungen (also z.B. das komprimierte 

Abspeichern des aufgenommenen Bildes, damit kein Bild verloren geht) und weiterführende Algorithmen ohne 

Echtzeitanforderungen (wie z.B. das Aufhellen dunkler Bilder). Auf diese Weise können die Algorithmen mit 

unterschiedlichen Prioritäten versehen und auch auf unterschiedlichen Prozessoren ausgeführt werden. 


Strategie 

probeCommands 

probeData 

:Probe 

Control 

sender 

receiver 

:Control 

:Data 

Collection 

:IS2000 




receiver 

:Control 

:Image 

Processing 

:Acquisition 

Management 


sender 


:Control 

:Post 

Processing 

source dest 


source dest 

Kapselung domänenspezifischer Bild-Daten. 

probeCommands 

probeData 

:Probe 

Control 


:Control 

:Data 

Collection 

:IS2000 

:Data 

:Exporting 

:Image 

Collection 

:Acquisition 

:Acquire 

:Imaging 

:Monitor 

networkAccess 





:Control 

:Image 

Processing 

:Acquisition 

Management 



source dest 

:Data 


:Control 

:Post 

Processing 

:Data 

:Data 


source dest 

source dest 

source dest 


:Control 

:IS2000 

:Acquisition 

:Acquire 

:Exporting 

:Export 

:Comm 

:Imaging 

:Monitor 

networkAccess 


source dest 

:Data 


:Control 


:Exporting 

networkAccess 


2009-02-09 

2009-02-09 




Strategie 


probeCommands 

probeData 

:Probe 

Control 

sender 

receiver 

:Control 

:Acquisition 



:Acquisition 


Management 

:Acquire 

sender 

receiver 

:Control 

:Imaging 


source dest 

:Data 

:Image 

:Post 


Collection 

Processing 

Processing 

:Monitor 

:IS2000 

source dest 

:Data 


:Control 

:Image 

Collection 

source dest 

:Data 

Schließlich verfeinern wir noch die Komponenten Exporting. Hier wollen wir den Aufwand für den Export in 

unterschiedliche Bildformate minimieren. Wir wenden dazu eine Strategie an, die domänenspezifischer Bild-Daten 

kapselt. Wir wählen hierfür eine interne Repräsentation unserer Bild-Daten in einer Datenhaltungskomponente 

Image Collection. Für den Export gibt es dann je eine Transformation des internen in das gewünschte Format. Die 

Komponente Export übernimmt hierfür die notwendige Interaktion mit dem Benutzer. Außerdem können die Bilder 

auch noch über ein Netzwerk verschickt werden. Diese Aufgabe übernimmt die Komponente Comm. 


probeCommands 

probeData 

:Probe 

Control 

sender 

receiver 

:Control 

:Data 

Collection 

:IS2000 






receiver 

:Control 

:Image 

Processing 

:Acquisition 

Management 


sender 


:Control 

:Post 

Processing 


source dest 

:Data 

:Image 

Collection 

source dest 

source dest 

:Data 

source dest 

:Data 

sender 

receiver 

:Control 

:Acquisition 

:Acquire 

:Exporting 

:Export 

:Comm 

:Imaging 

:Monitor 

networkAccess 


Strategie 


sender 

receiver 

:Control 

sender 

receiver 

:Control 

:Exporting 

:Export 

source dest 

:Data :Comm 

:Image 

Collection 

source dest 

:Data 

networkAccess 

:Acquisition 



:Acquisition 


Management 

:Acquire 

:Imaging 


source dest 

:Data 

:Image 

:Post 


Collection 

Processing 

Processing 

:Monitor 

Wir haben in diesem Abschnitt gesehen, wie man eine konzeptionelle Sicht sukzessive durch Anwendung der 

vorbereiteten Strategien verfeinert. Dabei sollte jede Anwendung einer Strategie unbedingt dokumentiert werden, 

damit die Entwurfsentscheidungen nachvollziehbar werden. Die Begründungen für bestimmte 

Entwurfsentscheidungen lassen sich nämlich auch nicht durch Reverse-Engineering-Techniken, die allein vom 

Quellcode ausgehen, nicht wieder rekonstruieren. Der Quellcode ist die sicherste Beschreibung dafür, was die 

Software macht. Er enthält aber keinen Hinweis darauf, was er hätte machen sollen, warum er was macht und 

warum er es gerade so macht. 

probeCommands 

probeData 

:Probe 

Control 

:IS2000 

sender 

receiver 

:Control 

source dest 

:Data 


:Control 

sender 

receiver 

:Control 

:Exporting 

:Export 

source dest 

:Data :Comm 

networkAccess 




2009-02-09 






− Faktoren 




aufgabe 

− Module 

− Schichten 

− Subsysteme 



Quell−Code 



− Schnittstellen 



Einfluss 

Rückkopplung 










− Faktoren 




aufgabe 

− Module 

− Schichten 

− Subsysteme 



Quell−Code 



− Schnittstellen 

Im nächsten Schritt überführen wir die konzeptionelle Sicht in die Modulsicht, die den statischen Aufbau des 

Systems beschreibt in Form von Modulen, Schnittstellen, Subsystemen und Schichten. Es ist gut möglich, dass sich 

beim Entwurf der konzeptionellen Sicht, sich neue Aspekte ergeben haben, so dass wir die globale Analyse 

gegebenfalls wiederholen, bevor wir uns an die zentrale Entwurfsaufgaben machen, die Module zu entwerfen. Nach 

Entwurf der Module und ihre Anordnung in Schichten und Subsystemen, entwerfen wir abschließend deren 

Schnittstellen. 

In diesem Abschnitt vertiefen wir den Modulsichtentwurf. Es sei voraus geschickt, dass wir nicht streng sequentiell 

Modulsicht, dann Ausführungs- und dann Code-Sicht entwerfen. Vielmehr ist der Entwurfsprozess meist iterativ. 



Einfluss 

Rückkopplung



bildet Komponenten und Konnektoren auf Module, Schichten und 

Subsysteme ab 

setzt konzeptionelle Lösung mit aktuellen Softwareplattformen 

(Programmiersprachen, Bibliotheken) und Technologien um 

beschreibt statische Aspekte 


2009-02-09 

Wie wird das Produkt auf die Software-Plattform abgebildet? 

Welche Softwaredienste werden benutzt und von wem? 

Wie wird das Testen unterstützt? 

Wie können Abhängigkeiten zwischen Modulen minimiert werden? 

Wie kann die Wiederverwendung von Modulen maximiert werden? 

Welche Techniken können eingesetzt werden, um Auswirkungen von 

Änderungen zu minimieren. 







bildet Komponenten und Konnektoren auf Module, Schichten und 

Subsysteme ab 

setzt konzeptionelle Lösung mit aktuellen Softwareplattformen 

(Programmiersprachen, Bibliotheken) und Technologien um 

beschreibt statische Aspekte 


Wie wird das Produkt auf die Software-Plattform abgebildet? 

Welche Softwaredienste werden benutzt und von wem? 

Wie wird das Testen unterstützt? 

Wie können Abhängigkeiten zwischen Modulen minimiert werden? 

Wie kann die Wiederverwendung von Modulen maximiert werden? 

Welche Techniken können eingesetzt werden, um Auswirkungen von 

Änderungen zu minimieren. 

Beim Entwurf der Modulsicht bilden wir die Komponenten und Konnektoren der konzeptionellen Sicht auf Module, 

Schichten und Subsysteme ab. Hierzu setzen wir die konzeptionelle Lösung mit der aktuellen Softwareplattforme 

(Programmiersprachen, Bibliotheken, Werkzeuge) und Technologien um. Dabei werden rein statische Aspekte 

beschrieben. 

Die Belange, die durch die statische Modulsicht adressiert werden sind die folgenden: 

• Wie wird das Produkt auf die Software-Plattform abgebildet? 

• Welche Softwaredienste werden benutzt und von wem? 

• Wie wird das Testen unterstützt? 

• Wie können Abhängigkeiten zwischen Modulen minimiert werden? 

• Wie kann die Wiederverwendung von Modulen maximiert werden? 

• Welche Techniken können eingesetzt werden, um Auswirkungen von Änderungen zu minimieren. 

Für die Modulsichten interessieren sich Programmierer für die Programmierung. Tester interessieren für den 

Blackbox-Komponententest sowie den Integrationstest. Ein Projektleiter kann von der Modulsicht Gebrauch 

machen, um festzulegen, welcher Entwickler welches Modul implementieren soll.


Modulblickwinkel (Hofmeister u. a. 2000) 

2009-02-09 

0..1 

Subsystem 

contain 

* 

Module 

0..1 

* 

* 

require 

provide 

* 

* 

* 

use 

* 

* 

Interface 

assigned−to 

Module (layer) A uses 

module (layer) B when 

A requires an interface 

that B provides 

* 

require 

* provide 

0..1 

* * 

Layer 

* 

* 0..1 

use 

* 

contain 






Der Modulblickwinkel wird durch das folgende UML-Diagramm beschrieben: 

0..1 

Subsystem 

contain 

* 

Module 

0..1 

* 

* 

require 

provide 

* 

* 

* 

use 

* 

* 

Interface 

assigned−to 





* 

require 

* provide 

0..1 

* * 

Layer 

* 

* 0..1 

use 

* 


0..1 

Subsystem 

contain 

* 

Module 

0..1 

* 

* 

require 

provide 

* 

* 

* 

use 

* 

* 





* 

require 

Interface 

* provide 

0..1 

* * 

assigned−to 

Layer 

* 

* 0..1 

Ein Modul ist eine statische, austauschbare Gliederungseinheit mit einem bestimmten Zweck. Es kann in der 

Beschreibung durch Teilmodule verfeinert werden. Ein Modul hat zwei Kategorien von Schnittstellen: die 

Schnittstellen, die es selbst anderen anbietet (provides) und jene, die es von anderen benötigt require). In den 

meisten Programmiersprachen kann man nur die zur Verfügung gestellten Schnittstellen angeben, aber nicht jene, 

die das Modul voraussetzt. Wenn Module aber ausgetauscht werden und die Auswirkung von Änderungen analysiert 

werden sollen, dann benötigt man auch Wissen darüber, welche Schnittstelle ein Modul voraussetzt. 

Module können zu Schichten angeordnet werden. Damit wird die Sichtbarkeit von Modulen festgelegt. Bei einem 

strikten Schichtenmodell dürfen Module einer Schicht nur auf Module der nächst tieferen Schicht zugreifen. Dies 

erhöht die Austauschbarkeit. Ein Schicht implementiert eine Art virtuelle Maschine. Auch Schichten haben beide 

Arten von Schnittstellen und können wieder weiter in Teilschichten verfeinert werden. 

Schließlich können Module nochmal unabhängig von Schichten zu einem Subsystem zusammen gefasst werden. Ein 

Subsystem ist eine weitere Gliederungseinheit, die orthogonal zu hierarchischen Modulen und zu Schichten ist. Ihre 

Daseinberechtigung wird später im Kontext des Code-Blickwinkels deutlicher. 

contain 

use 

* 

contain


Notation für Module 

2009-02-09 

 

A 

+sichtbar 

-unsichtbar 

 

 

 

C 

+sichtbar 

-unsichtbar 

 

 

B 

+sichtbar 

-unsichtbar 

Schnittstelle 







 

A 

+sichtbar 

-unsichtbar 

 

 

 

C 

+sichtbar 

-unsichtbar 

 

B 

+sichtbar 

-unsichtbar 

Module sind ein etwas allgemeineres Konzept als Klassen. Klassen sind ein Konzept einer Programmiersprache und 

des objektorientierten Paradigmas. Module können aber in C auch durch Dateien implementiert werden. Oft werden 

sie durch mehrere Dateien oder Klassen implementiert. Insofern hat das Konzept Modul seine Berechtigung. 

Weil Module aber Klassen ähneln, kann man für sie auch eine ähnliche Notation verwenden. Im folgenden 

Diagramm verwenden wir den Stereotyp Modul um zu kennzeichnen, dass die Klassenikone als Module zu 

interpretieren sind. 

 

A 

+sichtbar 

-unsichtbar 

 

 

 

C 

+sichtbar 

-unsichtbar 

 

 

B 

+sichtbar 

-unsichtbar 

Schnittstelle 

Die UML-Notation für sichtbare und unsichtbare Elemente können zur Spezifikation der provides-Schnittstelle 

verwendet werden. Alternativ kann man auch auf die UML-Darstellungen für Schnittstellen zurück greifen. Der 

Lolipop an Modul B besagt, dass B eine Schnittstelle zur Verfügung stellt, von der Modul C abhängt. 

 

Schnittstelle


Beispiel einer Modulsicht 

2009-02-09 

 

 

Network 

Comm 

sender receiver 

 

forwarder 

 

TCP/IP 

 

dispatcher 

 

wrapper 

 

sockets 

+socket() 

+bind() 

+listen() 

+accept() 

+recvmsg() 

+sendmsg() 

 


 

receiver 







 

Comm 

 

Network 


Als Beispiel für eine Modulsicht verfeinern wir einen Aspekt der konzeptionellen Sicht unseres laufenden Beispiels 

der IS2000. Wir wenden uns hierzu der Komponente Comm der konzeptionellen Sicht zu. Ihre Aufgabe ist es, die 

Netzwerkkommunikation zu realisieren. 

Das folgende Beispieldiagramm beschreibt diesen kleinen Ausschnitt: 

 

Comm 

 

Network 


 

forwarder 

 

TCP/IP 

 

dispatcher 

 

wrapper 

 

sockets 

+socket() 

+bind() 

+listen() 

+accept() 

+recvmsg() 

+sendmsg() 

 


 

receiver 

 

forwarder 

 

TCP/IP 

 

dispatcher 

 

wrapper 

 

sockets 

+socket() 

+bind() 

+listen() 

+accept() 

+recvmsg() 

+sendmsg() 

 


 

receiver

2009-02-09 






 

Comm 

 

Network 


Das Diagramm beschreibt, wie die Comm-Komponente den Netzwerkzugriff realisiert. Wir haben uns dazu 

entschlossen das Netzwerkprotokoll TCP/IP zu verwenden, um Daten über das Internet auszutauschen. Da der 

Datentransfer zwischen einer heterogenen Rechnerlandschaft geschieht und deshalb Binärdaten konvertiert werden 

müssen, legen wir über die TCP/IP-Schicht noch eine weitere Schicht, die das Ein- und Auspacken der 

transferierten Daten vornimmt. Außerdem können wir auf diese Weise von TCP/IP abstrahieren und es bei Bedarf 

leicht gegen ein anderes Protokoll austauschen. Die Schicht Network wird sowohl von der IS2000 als auch von 

anderen Prozessen, die auf entfernten Rechnern ausgeführt werden, verwendet (stellvertretend steht hierfür das 

Module Remote Imaging). Die Schicht Network gliedert sich in ein Dispatcher-Modul, der die Verwaltung des 

Sendens und Empfangens übernimmt, und in ein Modul forwarder für das Einpacken für den Datenversand und ein 

Modul receiver für das Entpacken der Daten. Letztere beiden Module müssen sich auf eine gemeinsame 

Datenrepräsentation einigen. Aus diesem Grund sind sie dem selben Modul wrapper zugeordnet. 

Wir haben hier ein vergleichsweise kleines Detail der logischen Sicht auf Module abgebildet und bereits eine 

ansehnliche Anzahl von Modulen erhalten. Das Beispiel sollte deutlich machen, dass wir für die gesamte 

konzeptionelle Sicht eine große Anzahl von Modulen erhalten werden. Damit wir uns in diesem Abbildungsprozess 

verlieren, haben wir glücklicherweise die konzeptionelle Sicht, die alles zusammen hält und an der wir uns 

orientieren können. 








Quell−Code 



− Faktoren 



aufgabe 

− Laufzeitelemente 

− Kommunikationspfade 

− Ausführungskonfiguration 




− Ressourcenzuweisung 

 

forwarder 

 

TCP/IP 

 

dispatcher 

 

wrapper 

 

sockets 

+socket() 

+bind() 

+listen() 

+accept() 

+recvmsg() 

+sendmsg() 

 


 

receiver 


Einfluss 

Rückkopplung 


2009-02-09 










Quell−Code 



− Faktoren 



aufgabe 

− Laufzeitelemente 

− Kommunikationspfade 

− Ausführungskonfiguration 


Software ist primär Verhalten. Durch die Modulsicht wird aber nur der innere strukturelle Aufbau beschrieben. Im 

nächsten Schritt kümmern wir uns um dynamische Aspekte, also Dinge, die zur Laufzeit relevant sind. Dazu bilden 

wir die Module auf Elemente der Ausführungsplattform (sowohl Hardware als auch Software) ab. Dazu dient der 

Ausführungsblickwinkel. 



beschreibt dynamische Aspekte 

beschreibt, wie Module auf Elemente der Ausführungs- und 

Hardwareplattform abgebildet werden 

definiert Laufzeitelemente und deren Attribute (Speicher- und 

Zeitbedarf, Allokation auf Hardware) 




− Ressourcenzuweisung 

Wie verläuft Kontroll- und Datenfluss zwischen Laufzeitkomponenten? 

Wie kann Ressourcenverbrauch ausgewogen werden? 

Wie können Nebenläufigkeit, Replikation und Verteilung erreicht 

werden, ohne die Algorithmen unnötig zu verkomplizieren? 

Wie können Auswirkungen von Änderungen in der 

Ausführungsplattform minimiert werden? 



Einfluss 

Rückkopplung

2009-02-09 






beschreibt dynamische Aspekte 

beschreibt, wie Module auf Elemente der Ausführungs- und 

Hardwareplattform abgebildet werden 

definiert Laufzeitelemente und deren Attribute (Speicher- und 

Zeitbedarf, Allokation auf Hardware) 


Wie verläuft Kontroll- und Datenfluss zwischen Laufzeitkomponenten? 

Wie kann Ressourcenverbrauch ausgewogen werden? 

Wie können Nebenläufigkeit, Replikation und Verteilung erreicht 

werden, ohne die Algorithmen unnötig zu verkomplizieren? 

Wie können Auswirkungen von Änderungen in der 

Ausführungsplattform minimiert werden? 

Der Ausführungsblickwinkel definiert die Laufzeitelemente und deren Attribute wie Speicher- und Zeitbedarf und 

Allokation auf Hardware. Wir beschreiben hierbei, welche Prozesse und Objekte existieren, wie sie miteinander zu 

Ausführungszeit kommunizieren und wie sie auf die ausführende Hardware abgebildet werden. 

Die adressierten Belange des Ausführungsblickwinkels sind damit: 

• Wie verläuft der Kontroll- und Datenfluss zwischen den Laufzeitkomponenten (Prozesse, Objekte etc.)? 

• Wie kann der Ressourcenverbrauch (Speicher, Rechenzeit etc.) ausgewogen werden? 

• Wie können Nebenläufigkeit, Replikation und Verteilung erreicht werden, ohne die Algorithmen unnötig zu 

verkomplizieren? 

• Wie können Auswirkungen von Änderungen in der Ausführungsplattform minimiert werden (also Änderungen der 

Hardware)? 


Ausführungsblickwinkel (Hofmeister u. a. 2000) 

* 

Communication 

Mechanism 

1 

* 

Communication 

Path 

* 

* 

* 

consume 

use mechanism 

communicate over 


Platform 

Platform 

Element 

* 1 * * 

is a 

* 

Runtime 

Entity 

2..* 

* 

consume 

* 

contain 

Platform 

Resource 

assigned to 

assigned to 

* 1 

* 

Hardware 

Resource 

Module 


2009-02-09 

2009-02-09 





Das folgende UML-Diagramm beschreibt den Ausführungsblickwinkel: 

* 

Communication 

Mechanism 

1 

* 

use mechanism 

Communication 

Path 

* 

* 

* 

consume 



Platform 

* 

Platform 

Element 

* 1 * * 

is a 

* 

Runtime 

Entity 

2..* 

consume 

* 

contain 

Platform 

Resource 

assigned to 

assigned to 

* 1 

* 

Hardware 

Resource 

Module 


* 

Communication 

Mechanism 

1 

* 

Communication 

Path 

* 

* 

* 

consume 

use mechanism 



Platform 

* 

Platform 

Element 

* 1 * * 

Die Software-Plattform hält alle Aspekte der Ausführung zusammen. Sie besteht zunächst aus Plattformelementen, 

dies sind Dinge, die zur Laufzeit angelegt werden und ausgeführt werden können (z.B. Prozesse; wir lernen weitere 

Beispiele weiter unten kennen). 

Die Plattformelemente haben Instanzen, die Laufzeiteinheiten (Runtime Entity). Die Laufzeiteinheiten 

kommunizieren über Kommunikationspfade (Communication Path) mit einander. Mindestens zwei konkrete 

Laufzeitinstanzen kommunizieren dabei. Die Kommunikationspfade verwenden hierzu einen 

Kommunikationsmechanismus, wie beispielsweise eine Remote Method Invocation in Java oder eine 




Corba-Interprozesskommunikation. 


is a 

* 

Runtime 

Entity 

2..* 

consume 

* 

contain 

Platform 

Resource 

assigned to 

assigned to 

* 1 


* 

Communication 

Mechanism 

* 

Communication 

Path 

* 

consume 



Platform 

* 

Platform 

Element 

* 1 * * 

Bei der Ausführung konsumiert eine Laufzeiteinheit Laufzeitressourcen wie Speicher oder Rechenzeit. 

Auf der rechten Seite des Diagramms sehen wir die Einbettung in die Hardwareumgebung und in die statische 

Modulsicht. Module sind den Laufzeiteinheiten, die sie ausführen. Dabei kann ein Modul natürlich von vielen 

Laufzeiteinheiten verwendet werden. Durch diese Bezüge zur Modulsicht werden die beiden Sichten miteinander 

verknüpft. 

Die Plattformressourcen werden auf konkrete Hardware-Ressourcen abgebildet, die sie zur Verfügung stellen, wie 

beispielsweise Prozessoren oder gemeinsamer Speicher. 

1 

* 

* 

use mechanism 

is a 

* 

Runtime 

Entity 

2..* 

consume 

* 

contain 

Platform 

Resource 

assigned to 

* 

assigned to 

* 1 

* 

Hardware 

Resource 

Module 

Hardware 

Resource 

Module



2009-02-09 

Platform Element 

Thread 

Process 

Task 

Socket 

Queue 

File 

Shared Memory 

Shared Library 

DLL 

Platform Resource 

... 

CPU Time 

Address Space 

Memory 

Semaphore 

Timer 

Communication Mechanism 

DCOM 

Rainer Koschke (Uni Bremen) ... 

Software-Projekt Wintersemester 2008/09 392 / 634 





... 

IPC 

RPC 


Die Konzepte des Ausführungsblickwinkels sind noch relativ abstrakt. Die folgende Vererbungshierarchie 

konkretisiert die Konzepte. Ein Plattformelement ist eine Softwareeinheit, die zur Laufzeit existiert. Dazu gehören 

zum Beispiel Objekte als Instanzen von Klassen. Für die Realisierung von paralleler Ausführung haben wir Threads 

(als leichtgewichtige Prozesse mit gemeinsamem Speicher), Prozesse mit getrennten Speicher oder Tasks (als 

eigenes Sprachkonstrukt aus einer Programmiersprache). Diese Prozesse kommunizieren über weitere 

Plattformelemente wie Sockets, Warteschlangen, Dateien oder geteiltem Speicher. Außerdem kann man Module 

bündeln in dynamischen Bibliotheken und auf unterschiedlichen Rechnern installieren. 


... 

Thread 

Process 

Task 

Socket 

Queue 

File 

Shared Memory 


DLL 


... 

CPU Time 

Address Space 

Memory 

Semaphore 

Timer 


... 

DCOM 

IPC 

RPC 


... 

Thread 

Process 

Task 

Socket 

Queue 

File 

Shared Memory 


DLL 


... 

CPU Time 

Address Space 

Memory 

Semaphore 

Timer 


... 

DCOM 

IPC 

RPC

2009-02-09 






Plattformressourcen sind Ressourcen, die uns von der Software- und Hardwareplattform zur Verfügung gestellt 

werden, die von den Plattformelementen konsumiert werden, während sie ihre Arbeit erledigen. Dazu gehöhren 

neben Speicher und CPU-Zeit Betriebsmittel für die Synchronisation wie Semaphore oder Timer. 

Kommunikationsmechanismen schließlich dienen den Plattformelementen zum Nachrichtenaustausch. Unter dem 

Betriebssystem Windows gibt es hierfür zum Beispiel DCOM. Plattformunabhängigere Mechanismen sind die 

Interprozesskommunikation (IPC) oder der Remote Procedure Call (RPC), bei Java auch bekannt als Remote 

Method Invocation (RMI). 


Beispiel einer Ausführungssicht 


... 

Thread 

Process 

Task 

Socket 

Queue 

File 

Shared Memory 


DLL 


... 

CPU Time 

Address Space 

Memory 

Semaphore 

Timer 



... 

DCOM 

IPC 

RPC

2009-02-09 

2009-02-09 






Für Diagramme, die die Ausführungssicht beschreiben, gibt keine Standardnotation. Die Diagrammart in der UML, 

die der Ausführungssicht am nächsten kommt, ist das Deployment-Diagramm. Es zeigt aber nicht alle Aspekte, die 

im Ausführungsblickwinkel nach Hofmeister u. a. (2000) möglich sind. Hofmeister u. a. (2000) schlagen deshalb 

eine eigene Notation vor, die an das Deployment-Diagramm der UML angelehnt ist. Das folgende Diagramm ist ein 

Beispiel hierfür: 






Wir erkennen darin drei Rechnertypen, die als Quader dargestellt sind. In ihnen geschachtelt tauchen drei 

Prozesstypen, die mit dem Stereotyp process gekennzeichnet sind. Die Schachtelung drückt aus, dass der 

geschachtelte Prozess auf dem jeweiligen Rechner ausgeführt wird. Die Module, die die Prozesse dabei ausführen, 

sind in den Prozessen geschachtelt. Die Kommunikationspfade werden als Assoziationen zwischen den Prozessen 

dargestellt. Die Beschriftung der Assoziation gibt den Kommunikationsmechanismus wieder. Die Multiplizitäten an 

den Kommunikationspfaden gibt an, wie viele Prozess jeden Typs in der Kommunikation involviert sind. In unserem 

Fall ist das je eine n:1-Beziehungen, das heißt, mehrere Shop-Assistents kommunizieren mit einem Shop-Server und 

mehrere Shop-Server kommunizieren mit einem Datenbank-Server. 

Wie viele Instanzen es von den Typen von Hardware-Ressourcen und Plattformelementen zur Laufzeit gibt, wird 

durch die Zahl in den Kästen wieder gegeben. Den Ladenrechner und Datenbankrechner gibt es nur einmal, es kann 

aber beliebig viele PDAs geben. Auf jedem PDA wird nur ein Prozess vom Typ Personal Shop Assistent gestartet. 

Gleiches gilt für den Datenbankrechner, auf dem nur eine Instanz des Prozesstyps Data Base Server existiert. Um 

Ausfallsicherheit und Skalierbarkeit zu sichern, hat sich der Architekt entschlossen, auf dem Ladenrechner n 

Instanzen von Shop Server anzulegen.


2009-02-09 






− Faktoren 





aufgabe 

− Quellkomponenten 

− Zwischenprodukte 

− Auslieferungskomp. 


Quell−Code 



− Build−Prozess 

− Konfigurations− 

management 



Einfluss 

Rückkopplung 




Code-Sicht 






− Faktoren 





aufgabe 

− Quellkomponenten 

− Zwischenprodukte 

− Auslieferungskomp. 


Quell−Code 



− Build−Prozess 

− Konfigurations− 

management 

Nachdem wir Modulsicht und Ausführungssicht entworfen haben, planen wir die konkrete Implementierung. 

Elemente aus der Modulsicht und Ausführungssicht sind abstrakte Konzepte, die dann in einer 

Programmiersprachen realisiert werden müssen. Dies geschieht, indem Programmierer Dateien anlegen, in denen 

der Implementierungscode (textuell oder graphisch) aufgeführt ist. Wir nennen dies die Quellkomponenten. Aus 

den Quellkomponenten werden dann möglicherweise über Zwischenprodukte das erzeugt, was schließlich als Code 

an den Kunden ausgeliefert wird. Beispielsweise haben wir unser Programm in C geschrieben. Dann erzeugt der 

Compiler daraus als Zwischenprodukt Objektdateien und möglicherweise Bibliotheken. Daraus erzeugt der Linker 

schließlich das ausführbare Programm. Das ausführbare Programm und alle dynamischen Bibliotheken stellen die 

Ausführungskomponenten dar. Da Dateien meist die Einheit sind, in der Aufgaben an Programmierer verteilt 

werden, und die meisten Versionskontrollsysteme nur ganze Dateien verwalten, bestimmt die Aufteilung in Dateien 

die Aufgabenverteilung und das Konfigurationsmanagement. Außerdem kann der Build-Prozess unter Umständen 

bei großen Systemen, die nicht selten in vielen unterschiedlichen Programmiersprachen geschrieben wird, sehr 

komplex werden. Der Build-Prozess benötigt nicht selten viel Zeit selbst auf mächtiger Hardware. Aus diesen 

Gründen sollte für mittlere und große Systeme die Abbildung der abstrakten Konzepte aus der Modulsicht und 

Ausführungssicht auf “anfassbare” Dateien und auch der Build-Prozess geplant und dokumentiert werden. Dies ist 

die Aufgabe der Code-Sicht. 

Bevor wir die Code-Sicht entwerfen, ist es möglicherweise notwendig, die globale Analyse nochmals zu wiederholen, 

wenn sich durch den Entwurf der vorherigen Sichten Einflussfaktoren und Strategien geändert haben sollten. 



Einfluss 

Rückkopplung


Code-Blickwinkel 

bildet Laufzeiteinheiten auf installierbare Objekte (ausführbare 

Dateien, dynamische Link-Bibliotheken etc.) ab 

bildet Module auf Quellkomponenten (Dateien) ab 

zeigt, wie die installierbaren Dateien aus den Quellkomponenten 

generiert werden 


2009-02-09 

Wie kann die Zeit und der Aufwand für Produkt-Upgrades verringert 

werden? 

Wie sollen Produktversionen verwaltet werden? 

Wie kann die Build-Zeit verringert werden? 

Welche Werkzeuge werden in der Entwicklungsumgebung benötigt? 

Wie wird Integration und Test unterstützt? 




Code-Sicht 



bildet Laufzeiteinheiten auf installierbare Objekte (ausführbare 

Dateien, dynamische Link-Bibliotheken etc.) ab 

bildet Module auf Quellkomponenten (Dateien) ab 

zeigt, wie die installierbaren Dateien aus den Quellkomponenten 

generiert werden 


Wie kann die Zeit und der Aufwand für Produkt-Upgrades verringert 

werden? 

Wie sollen Produktversionen verwaltet werden? 

Wie kann die Build-Zeit verringert werden? 

Welche Werkzeuge werden in der Entwicklungsumgebung benötigt? 

Wie wird Integration und Test unterstützt? 

Die Code-Sicht bildet die Laufzeiteinheiten auf installierbare Objekte (ausführbare Dateien, dynamische 

Link-Bibliotheken etc.) ab. Außerdem bildet sie Module auf Quellkomponenten (Dateien) ab und zeigt, wie die 

installierbaren Dateien aus den Quellkomponenten generiert werden. 

Die Belange, die mit der Code-Sicht adressiert werden, sind wie folgt: 

• Wie kann die Zeit und der Aufwand für Produkt-Upgrades verringert werden? Dazu müssen wir wissen, welche 

ausgelieferten Einheiten wir erneuern müssen. Im schlimmsten Fall muss der Kunde alles neu installieren. Dies wollen wir 

aber vermeiden. 

• Wie sollen Produktversionen verwaltet werden? Unter Umständen müssen wir nachvollziehen können, welche einzelnen 

Dateien für die Installation bei einem bestimmten Kunden eingeflossen sind, um zum Beispiel Fehler zu diagnostizieren. 

Diese Information muss durch das Konfigurationsmanagement bereit gehalten werden. 

• Wie kann die Build-Zeit verringert werden? Die Zeit für die vollständige Übersetzung kann erheblich sein und damit die 

Entwicklung stark hemmen. Bei großen Systemen kann es viele Stunden dauern, bis ein System vollständig übersetzt ist. 

Wir wollen deshalb die Abhängigkeiten zwischen den Dateien möglichst gering halten, um den Build-Prozess so kurz wie 

möglich zu halten. 

• Welche Werkzeuge werden in der Entwicklungsumgebung benötigt? In manchen Fällen können zum Beispiel Teile des 

Code automatisch generiert werden. 

• Wie wird Integration und Test unterstützt? Bei der inkrementellen Integration werden Systemteile sukzessiv 

hinzugenommen und in ihrer Interaktion getestet. Dazu muss man den inneren Aufbau und die Abhängigkeiten aus der 

Modulsicht kennen und wissen, welche Dateien dazu jeweils zu übersetzen und zu testen sind.


Code-Blickwinkel (Hofmeister u. a. 2000) 

Subsystem 

Layer 

Module 

Interface 

2009-02-09 

0..1 

Runtime 

Entity 

0..1 

0..1 

trace 

trace 


Platform 

trace 

0..1 

* 

* * * 

Source 

Component 

import * 

Binary 

* Component 

* 

Library 

* 

Executable 

* 

Configuration 

Description 

* * 

generate 

trace 

1 1 * 

compile 

* 1 * 

link 

* * * 

link 

* 1 1 * 

use at runtime 

compile 

link 

* 

* 

* 

instantiate 




Code-Sicht 


Code-Sichten werden durch den folgenden Code-Blickwinkel beschrieben: 

Subsystem 

Layer 

Module 

Interface 

0..1 

Runtime 

Entity 

0..1 

0..1 

trace 

trace 


Platform 


Subsystem 0..1 trace 

Layer 

0..1 trace 

* 

* 


Platform 

Module 

Interface 

0..1 

Runtime 

trace 

0..1 

import * * * * 

* * * 

Source 

Binary 

Library Executable Configuration 

* Component * Component 

Description 

* * 1 1 * * 1 * * * * * 1 1 * 

generate 

compile 

link 

link 


trace 

compile 

link 

Entity * 

instantiate 

trace 

0..1 

* 

* * * 

Source 

Component 

import * 

Binary 

* Component 

* 

Library 

* 

Executable 

* 

Configuration 

Description 

* * 

generate 

trace 

1 1 * 

compile 

* 1 * 

link 

* * * 

link 

* 1 1 * 


compile 

link 

* 

* 

* 

instantiate

2009-02-09 



Code-Sicht 



Subsystem 0..1 trace 

Layer 

0..1 trace 

* 

* 


Platform 

Module 

Interface 

0..1 

Runtime 

trace 

0..1 

import * * * * 

* * * 

Source 

Binary 

Library Executable Configuration 

* Component * Component 

Description 

* * 1 1 * * 1 * * * * * 1 1 * 

generate 

compile 

link 

link 


trace 

compile 

link 

Entity * 

instantiate 

Alles, was für die Konstruktion des Systems notwendig ist, wird versammelt unter der Software-Plattform (Software 

Platform). Dazu gehören primär die Quell-Komponenten (Source Component), die die Module und Schnittstellen 

implementieren. Das sind in Java beispielsweise die Java-Quelldateien. Sie hängen zum Teil von einander ab, indem 

sie sich importieren. In Java gibt es dafür die import-Anweisung. Außer reinen Code-Dateien betrachten wir auch 

zum Beispiel UML-Diagramme als Quell-Komponenten, wenn aus ihnen Quell-Code generiert wird. Die 

Quell-Komponenten werden bei kompilierten Sprachen von einem Compiler in eine Binärform übersetzt. In Java ist 

das der Java-Bytecode. Die Binärdateien werden in einem weiteren Schritt oft in statischen oder dynamischen 

Bibliotheken zusammen gefasst. In Java sind das die JAR-Bibliotheken. Ein Linker linkt die Binärdateien und 

Bibliotheken schließlich zu einem ausführbaren Programm. Das Linken kann auch erst zum Zeitpunkt des 

Programms stattfinden, dann spricht man von einem dynamischen Linker. Die ausführbaren Programme können 

häufig durch Konfigurationsdateien (Configuration Description) zur Start- oder Laufzeit konfiguriert werden. 

Beispielsweise kann die Sprache, in der mit dem Anwender kommuniziert wird, bei internationalisierten 

Programmen eingestellt werden. 

Auf der linken Seite des Diagramms zum Code-Blickwinkel finden wir Elemente des statischen Modulblickwinkels 

und des Ausführungsblickwinkels. Auf diese Weise werden die verschiedenen Sichten miteinander verbunden. 

Zwischen Quell-Komponenten und Modulen und Schnittstellen haben wir eine trace-Beziehung. Sie beschreibt, 

welche Module durch welche Dateien implementiert werden, und ermöglicht damit die Nachvollziehbarkeit (im 

Englischen: Traceability) zwischen unterschiedlichen Ebenen eines Systems. Schichten und Subsysteme sind meist 

keiner einzelnen Quell-Komponente zuzuordnen. Vielmehr bilden wir sie ab auf die Software-Plattform. Eine Schicht 

oder ein Subsystem implementiert damit eine Software-Plattform. 

Die Programme erzeugen (instantiate) während ihrer Ausführung die Laufzeiteinheiten (Runtime Entity). 


Code-Blickwinkel: Beispiel 


2009-02-09 

2009-02-09 



Code-Sicht 


Das folgende Diagramm ist ein Beispiel für eine Code-Sicht: 


Die Modul dispatcher wird durch die Datei dispatcher.java implementiert. Das Modul wrapper sowie seine 

Die Teilmodule forwarder und receiver werden durch die Dateien forwarder.java und receiver.java umgesetzt. Das 

zusammengesetzte Modul wrapper wird nicht unmittelbar durch eine Quell-Komponente implementiert. Vielmehr 

besteht es aus den oben genannten Teilmodulen, die bestimmten Quell-Komponenten zugeordnet sind. 

Hierarchische Module werden als reine Gliederungseinheiten verwendet. Die Moduldekomposition ergibt einen 

Baum. Nur die Blätter dieses Baumes stellen Module dar, für die auch Code geschrieben werden muss. 

Die aus den Java-Dateien generierten Class-Dateien werden in einer JAR-Bibliothek für den Server abgelegt. Bei 

Ausführung der Bibliothek, indem die entsprechende main-Methode aktiviert wird, wird dann der Server-Prozess 

erzeugt. 



Code-Sicht 



Das Modell von Hofmeister ist sehr stark an herkömmlichen Sprachen wie C oder C++ orientiert. Im Falle von 

Java sind einige Spezialisierungen beziehungsweise Anpassungen sinnvoll. 

Eine Erleichterung in Java ist der Umstand, dass eine Class-Datei mit genau einer Java-Quelldatei korrespondiert 

(und umgekehrt; außer für innere Klassen). Und die Package-Struktur korrespondiert mit der physischen 

Dateisystem-Struktur. 

Die Bibliotheken in Java heißen JAR-Dateien (Java Archive; im Wesentlichen nichts anderes als ein Zip-Archiv mit 

Java-Class-Dateien). Die Class-Dateien werden nicht zu den Bibliotheken gelinkt, sondern lediglich hinzugefügt. 

Es gibt in Java eigentlich kein Exectuable wie bei C oder C++. Jede Klasse, die eine statische Methode main hat, 

kann zum Hauptprogramm werden. Enthält eine JAR-Datei mindestens eine solche Klasse, kann sie als Executable 

betrachtet werden. Eine JAR-Datei (oder auch eine Class-Datei) instantiates eine Runtime Entity, wenn ihr main 

aufgerufen wird, oder wenn ein Thread aktiviert wird.



Tabellendarstellung: 

Module Source File JAR 

dispatcher dispatcher.java server.jar 

forwarder forwarder.java server.jar 

receiver receiver.java server.jar 

. . . . . . . . . 

JAR instantiates 

server.jar Shop Server 

. . . . . . 

2009-02-09 




Code-Sicht 



Tabellendarstellung: 





. . . . . . . . . 



. . . . . . 

In der Praxis wird man kaum für die in der Code-Sicht auftretenden Relationen ein UML-Diagramm zeichnen, da es 

viel zu viele sind. Einfacher beschreibt man sie durch Tabellen, wie zum Beispiel: 





. . . . . . . . . 



. . . . . . 

Wenn Namenskonventionen existieren (im Falle von Java heißt die Class-Datei, die zu einer Java-Datei 

myfile.java gehört, schlicht myfile.class, wenn es sich nicht um eine innere Klasse handelt) müssen nicht alle 

Relationen durch Tabellen beschrieben werden.


Was ist Modularisierung? 

Definition 

Modularisierung: Dekomposition eines Systems in Module. 

Modul: austauschbares Programmteil, das eine geschlossene 

Funktionseinheit bildet. 

Arbeitspaket: von einer Person oder einer kleinen Gruppe von Entwicklern 

entwerfbar, implementierbar, testbar, verstehbar, änderbar, . . . 



Conways Gesetz: 

Conways Gesetz: 

Die Struktur der Software spiegelt die Struktur der Organisation wider. 



Schnittstellen 

Definition 

Schnittstelle (allgemein): Teil eines Systems, das dem Austausch von 

Informationen, Energie oder Materie mit anderen Systemen dient. 

– Wikipedia, die freie Enzyklopädie 

Definition 

Schnittstelle: Menge der Annahmen, die das Modul über seine Umgebung 

macht, sowie jene, die die Umgebung über das Modul macht. 

Definition 

Syntaktische Schnittstelle: öffentliche Attribute und Methoden mit 

deren Signaturen. 

Zwei Module sind über ihre Schnittstellen verbunden und damit abhängig. 



Ein Wort zu Schnittstellen 

Rectangle 

Figure 

+ Draw() 

Circle 

+ height + radius 

+ width 

+ Draw() 

+ Draw() 



Eine offene Schnittstelle 

a b s t r a c t c l a s s F i g u r e { 

p u b l i c a b s t r a c t v o i d Draw ( ) ; 

} 

c l a s s C i r c l e e x t e n d s F i g u r e { 

p u b l i c v o i d Draw ( ) { } ; 

p u b l i c i n t r a d i u s ; 

} 

c l a s s R e c t a n g l e e x t e n d s F i g u r e { 

} 


p u b l i c i n t h e i g h t ; 

p u b l i c i n t width ; 



Geheimnisprinzip (Information Hiding) nach Parnas (1972) 

Schnittstellen sind ein Kontrakt zwischen: 

Verwender: 

darf sich nur auf zugesicherte Annahmen verlassen 

muss Vorbedingungen einhalten 

Anbieter: 

muss zugesichertes Verhalten implementieren 

darf sich nur auf zugesicherte Vorbedingungen verlassen 

Der Kontrakt führt zu einer Kopplung zwischen Verwender und Anbieter. 

Schnittstellen werden so entworfen, dass 

Kopplung auf das Mindestmaß beschränkt wird; 

d.h. die Details, die sich ändern können, werden hinter Schnittstelle 

verborgen. 



Programmiersprachenunterstützung 

a b s t r a c t c l a s s F i g u r e { 

p u b l i c a b s t r a c t v o i d Draw ( ) ; 

} 

c l a s s C i r c l e e x t e n d s F i g u r e { 


p r i v a t e i n t r a d i u s ; 

} 

c l a s s R e c t a n g l e e x t e n d s F i g u r e { 

} 


p r i v a t e i n t h e i g h t ; 

p r i v a t e i n t width ; 



Verwender der Klasse 

p u b l i c v o i d Drawing ( F i g u r e A Figure , i n t Times ) { 

} 

f o r ( i n t i = 0 ; i < Times ; i ++) { 

A F i g u r e . Draw ( ) ; 

} 



Klassendiagramm 

Rectangle 

+ Draw() 

Figure 

+ Draw() 

Circle 

+ Draw() 

Drawing 




Rectangle 

+ Draw() 

Figure 

+ Draw() 

Circle 

+ Draw() 

Drawing 

Graphs 

Node 

+ Draw() 

Edge 

+ Draw() 




Rectangle 

+ Draw() 

Figure 

+ Draw() 

Circle 

+ Draw() 

Drawable 

Drawing 

Graphs 

Node 

+ Draw() 

Edge 

+ Draw() 



Schnittstelle als eigenes Sprachkonstrukt 

Schnittstelle: 

i n t e r f a c e Drawable { 

v o i d Draw ( ) ; 

} 

Schnittstellenverwender: 

p u b l i c v o i d Drawing ( Drawable Drawable Object , i n t Times ) { 

} 

f o r ( i n t i = 0 ; i < Times ; i ++) { 

D r a w a b l e O b j e c t . Draw ( ) ; 

} 

Schnittstellenanbieter: 

a b s t r a c t c l a s s F i g u r e implements Drawable {} 



Zusammenfassung zu Schnittstellen 

Schnittstelle ist Kontrakt zwischen Anbieter und Verwender, der die 

erlaubten wechselseitigen Annahmen festlegt 

Programmiersprachen erlauben die Spezifikation syntaktischer 

Eigenschaften von Schnittstellen 

moderne Programmiersprachen bieten Schnittstellen als eigenes 

Sprachkonstrukt an 

nur wenige erlauben die Spezifikation semantischer Eigenschaften 

Vor- und Nachbedingungen 

weitere Zusicherungen, wie z.B. Speicher- und Zeitkomplexität 



Kopplung und Zusammenhalt 

Definition 

Kopplung: Grad der Abhängigkeit zwischen Modulen. 

Definition 

Zusammenhalt (Kohärenz): Verwandtschaft der Teile eines Moduls. 

Modul A Modul B 



2009-02-09 






Definition 

Kopplung: Grad der Abhängigkeit zwischen Modulen. 

Definition 

Zusammenhalt (Kohärenz): Verwandtschaft der Teile eines Moduls. 



Der Architekt eines Konzertsaals bemüht sich, den Saal so zu bauen, dass die akustische Störung von außen extrem 

gering ist, die Hörbarkeit im Saal dagegen extrem hoch. Dem entspricht bei der Arbeit des Software-Architekten die 

Gliederung in Module so, dass 

• die Kopplung (d.h. die Breite und Komplexität der Schnittstellen) zwischen den Modulen möglichst gering, 

• der Zusammenhalt (d.h. die Verwandtschaft zwischen den Teilen eines Moduls) möglichst hoch wird. 

Das Konzept von Kopplung und Zusammenhalt basiert ursprünglich auf den FORTRAN- und COBOL-Programmen 

der frühen 70‘er Jahre. Heute haben wir Sprachen, die uns mehrere Abstraktionsebenen bieten. Dabei streben wir 

auf der Modulebene vor allem niedrige Kopplung (bei mäßigem Zusammenhalt), auf der Prozedurebene vor allem 

hohen Zusammenhalt (bei erheblicher Kopplung) an. 


Stufen des Zusammenhalts (von schlecht nach gut) 

Stufe innerhalb einer Funktion/Moduls betrifft 

kein 

Zusammenhalt 

rein zufällige Zusammenstellung Module 

Ähnlichkeit z.B. ähnlicher Zweck, also etwa alle 

Matrixoperationen; auch 

Fehlerbehandlung 

Module 

zeitliche Nähe Verwendung zum selben Zeitpunkt, Module, 

z.B. Initialisierung, Abschluss Funktionen 

gemeinsame Zugriff auf bestimmte Daten, Funktionen, 

Daten 

exklusiv, z.B. Kalenderpaket 

(Systemuhr) 

Module 

Hersteller / ein Teil erzeugt, was der andere Module, 

Verbraucher verwendet 

Funktionen 

einziges Datum Kapselung einer Datenstruktur, Module, 

Zusammenfassung der Operationen Funktionen 

einzige Operation Operation, die nicht mehr zerlegbar 

ist 

Funktionen 



Stufen der Kopplung (von schlecht nach gut) 

Stufe zwischen Funktionen/Modulen betrifft 

Einbruch Veränderung des Codes Funktionen 

volle 

selektive 

Öffnung 

Funktionskopplung 

keine 

Kopplung 

Öffnung Zugriff auf alle Daten, z.B. auf alle 

Attribute einer Klasse 

bestimmte Attribute sind zugänglich oder 

global durch expliziten Export/Import 

(Module) 

Funktionen 

Module, 

Funktionen 

nur Funktionsaufruf und Parameter Module 

(Funktion) 

Es besteht keine logische Beziehung Module 

(Zugriff ist syntaktisch unmöglich) 



Kriterien für einen guten Software-Entwurf 

Jeder Entwurf ist ein Kompromiss. 

Geringe Kopplung zwischen allen Modulen 

Hoher Zusammenhalt in allen Funktionen und Modulen 

Kriterium der naiven Suche: Jede Einheit sollte einen leicht 

erkennbaren Sinn haben. 

Abstraktion: Implementierungsdetails verbergen 

Kapselung von Dingen, die sich ändern können (Geheimnisprinzip; 

Information Hiding) 

Etwa gleich große Einheiten (Module, Funktionen). Abweichungen 

sollten plausibel sein; generell dürfen einfache Objekte größer sein als 

komplizierte. 



Kriterien für einen guten Software-Entwurf (Forts.) 

Uniforme Entwurfsstrategie; wenn z.B. eine Schichtenstruktur gewählt 

wurde, sollte sie nicht an irgendeiner Stelle korrumpiert sein. 

Uniforme Gestaltung der Schnittstellen. 

Uniforme Benennung. 

Prinzip der Isomorphie zur Realität (Michael Jackson11 ): Die Software 

sollte der Realität strukturell gleichen, damit die Änderungen der 

Realität in der Software leicht nachvollzogen werden können. 

11 Nein, nicht der Michael Jackson. 



Bewertung von Modularisierung 

Software Architecture Analysis Method (SAAM) (Kazman u. a. 1996): 

1 Lege wichtige Qualitätsaspekte fest 

2 Beschreibe alternative Modularisierungen 

3 Entwickle Szenarien für die Qualitätsaspekte 

4 Spiele die Szenarien durch und bewerte die Modularisierungen 

5 Betrachte Wechselwirkungen zwischen den Qualitätsaspekten 

6 Fasse die Evaluation zusammen 



Beispiel: Key Word in Context (KWIC) (Parnas 1972) 

westfälischer Friede 

Friede 

von 

zyklische Vertauschung 

jeder Zeile 

Osnabrück 

Bistum Osnabrück 


Friede westfälischer 

Friede von Osnabrück 

Osnabrück Friede 

von Osnabrück 


Osnabrück Bistum 

Sortierung der 

Zeilen 

von 

Friede 


Friede von Osnabrück 

Friede westfälischer 

Osnabrück Bistum 

Osnabrück Friede 

von Osnabrück 

von 

Friede 




Betrachtete Qualitätsaspekte und Szenarien 

Änderbarkeit 

Eingabeformat ändert sich 

größere Dateien müssen verarbeitet werden 

riesige Dateien müssen verarbeitet werden 

separate Entwickelbarkeit 

verteile Arbeit an Entwicklungsteams 

Performanz 

berechne KWIC für FB3-Webseiten 



Ablauf 

1 Eingabe der Daten 

2 Interne Speicherung der Daten 

3 Indizierung (Zeile, Wortanfang, Wortende) 

W e s t f ä l i s c h e r F r i e d e 

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 

B i s t u m O s n a b r ü c k 

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 

F r i e d e v o n O s n a b r ü c k 

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 

4 Zyklische Rotation der Indizierung 

5 Sortierung der Indizierung 

6 Ausgabe der Indizierung 

(1, 1, 13) 

(1, 15, 20) 

(2, 1, 6) 

(2, 8, 16) 

(3, 1, 6) 

(3, 8, 10) 

(3, 12, 20) 



Erste Modularisierung (ablauforientiert) 

Eingabe 

 

 

 

Input 

 

1. 

 

Master Control 

 

 

Shifter 

 

2. 

 

 

3. 4. 

 

 

Sorter 

Wissen über Eingabeformat 

 

characters index sorted_index 

Wissen über internes Datenformat 

Wissen, dass alle Daten im Speicher sind 

 

 

 

Output 

 

Ausgabe 



Qualitäten 

Änderbarkeit: 

betroffene Module 

Input Shifter Sorter Output 

Eingabeformat × 

größere Dateien × × × × 

riesige Dateien × × × × 

Getrennte Entwicklung: 

alle Datenstrukturen müssen bekannt sein 

komplexe Beschreibung notwendig 

Performanz: 

schneller Zugriff auf globale Variablen 



Geheimnisprinzip (Information Hiding) (Parnas 1972) 

Definition 

Geheimnisprinzip: Module verbergen alle 

Implementierungsentscheidungen, die sich ändern können, hinter einer 

abstrakten Schnittstelle. 



Zweite Modularisierung (objektbasiert) 

. . . nach dem Geheimnisprinzip (Information Hiding) (Parnas 1972) 

 

Master Control 

Eingabe 

 

 

Ausgabe 

Input 

-Eingabeformat 

 

 

 

Lines 

1. 

 

Indexer 

-zyklisches Schieben 

 

-int. Speicherung 

+add(c:char) 

+ Iteration() 

+get(l:linenr,w:wordnr) 

2. 

3. 

4. 

 

Sorter 

-Sortieralg. 

 

 

 

Index 

 

-Indexstruktur 

+add(l:linenr,w:wordnr) 

+ Iteration() 

+swap(p1:pos,p2:pos) 

Output 

-Ausgabeformat 



Qualitäten 

 

Änderbarkeit: 

betroffene Module 

Input Lines Index Indexer Sorter Output 

Eingabeformat × 

größere Dateien × 

riesige Dateien × 

Getrennte Entwicklung: 

nur Schnittstellen müssen bekannt sein 

Performanz: 

zusätzliche Aufrufe 



Abschließendes Wort zur Modularisierung 

Es gibt viele Modularisierungsmöglichkeiten. 

Jede ist gut für einen Zweck, schlecht für einen anderen. 

Mit gängigen Programmiersprachen muss man sich auf eine festlegen. 

Definition 

Querschnittsbelange (Cross-Cutting Concerns): 

Implementierungsaspekte, die eine große Zahl von Modulen betreffen. 

Beispiele: Fehlerbehandlung, Logging-Mechanismen, Vermeidung von 

Speicherlöchern etc. 

Aspektorientierte Programmiersprachen erlauben eine separate 

Beschreibung dieser Aspekte und ein ” Einweben“ des Aspekts in das 

System. 




Was ist Software-Architektur und welche Bedeutung hat sie? 

Welche Faktoren spielen eine Rolle für die Architektur? 

Erläutern Sie den Prozess von Hofmeister et al. zum Entwurf einer 

Architektur (globale Analyse, Faktoren, Strategien, 

Blickwinkelentwurf). 

Was ist ein Architekturblickwinkel bzw. eine Architektursicht? 

Erläutern Sie die Blickwinkel von Hofmeister et al. Wer hat jeweils ein 

Interesse an diesen Blickwinkeln? 

Warum verschiedene Blickwinkel? Warum gerade diese vier 

Blickwinkel? 

Wie lautet das Gesetz von Conway? 

Was ist Modularisierung? 

Was ist eine Schnittstelle? 




Was ist das Prinzip des Information-Hidings? 

Was versteht man unter Kopplung und Zusammenhalt? 

Nennen Sie Regeln für einen guten Architekturentwurf. 

Wie lässt sich Architektur prüfen? Erläutern Sie insbesondere SAAM. 




Bass u. a. (2003) geben eine gute Übersicht zu allen relevanten 

Aspekten von Software-Architektur 

Hofmeister u. a. (2000) beschreiben eine Methode für den 

Architekturentwurf, die auf vier verschiedenen Architektursichten 

beruht 

Shaw und Garlan (1996) geben eine Einführung in 

Software-Architektur und beschreiben einige Architekturstile bzw. 

-muster 


Architekturstile und Entwurfsmuster 





Ablauf 

Zeitplan 

Anmeldung 




Kontaktdaten 

Ressourcen 

Lehrbücher 








Vorgehen 


Lernziele 

Inhalt 

Zeitplan 


Risiken 




Verstehen, Wiederholungsfragen was Entwurfsmuster und Architekturstile sind 

Qualitäten Lernziele und Einsetzbarkeit der Entwurfsmuster/Architekturstile 

kennen Herausforderungen 

Aktivitäten 

Ist-Analyse 


Befragung 

Beobachtung 




Bedeutung 




Kontext 

Analyse 

Architektur 

Entwurf 


und Algorithmen 

Implemen− 

tierung 

Test 

Wartung 

& Evolution 



Entwurfsmuster 

Each pattern describes a problem which occurs over and over 

again in our environment, and then describes the core of the 

solution to that problem, in such a way that you can use this 

solution a million times over, without ever doing it the same way 

twice. 

Christopher Alexander (Architekt und Mathematiker), 

“A pattern language”, 1977. 

Definition 

Entwurfsmuster: ” Musterlösung“ für ein wiederkehrendes 

Entwurfsproblem. 



Bestandteile eines Entwurfsmusters 

Name (kurz und beschreibend) 

Problem: Was das Entwurfsmuster löst 

Lösung: Wie es das Problem löst 

Konsequenzen: Folgen und Kompromisse des Musters 



Beispielentwurfsproblem 

Mantel 

+entfernen() 

1 

0..1 

Artikel 

+entfernen() 

Rad 

+entfernen() 

0..1 

1..2 

Laufrad 

+entfernen() 

0..1 

0..1 

1 

1 

Rahmen 

+entfernen() 

Felge 

+entfernen() 



Beschreibung von Mustern (Gamma u. a. 2003) I 

Name: Composite 

Zweck: Teil-von-Hierarchie mit einheitlicher Schnittstelle beschreiben 

(überall wo ein Ganzes benutzt werden kann, kann auch ein Teil 

benutzt werden und umgekehrt) 

Motivation: . . . Einführung anhand eines konkreten Beispiels. . . 

Anwendbarkeit: 

wenn Teil-von-Beziehung beschrieben werden soll 

uniforme Schnittstelle für alle Elemente der Hierarchie 



Beschreibung von Mustern (Gamma u. a. 2003) II 

Struktur: 

Client 

Leaf 

+operation() 

operation() 

myElem 

+operation() 

Component 

+operation() 

for each c in children 

c.operation() 

spezifische 

Erweiterungen 

children 

Composite 

+operation() 

+add(component) 

+remove(component) 

+getChild(int) 

myComp 

+operation() 




Teilnehmer: 

Client: 

manipuliert Objekte der Komponenten nur durch die Schnittstelle von 

Composite 

Component: 

deklariert einheitliche Schnittstelle 

(optional) implementiert Standardverhalten 

p u b l i c a b s t r a c t c l a s s Component { 

p u b l i c a b s t r a c t v o i d o p e r a t i o n ( ) ; 

} 




Leaf : 

repräsentiert atomare Komponente 

definiert Verhalten für atomare Komponenten 

p u b l i c a b s t r a c t c l a s s L e a f e x t e n d s Component { 

p u b l i c a b s t r a c t v o i d o p e r a t i o n ( ) ; 

} 



Beschreibung von Mustern (Gamma u. a. 2003) III 

Composite: 

definiert Standardverhalten für zusammengesetzte Komponenten 

speichert Teile 

implementiert Operationen zur Verwaltung von Teilen 

import j a v a . u t i l . L i s t ; 

import j a v a . u t i l . A r r a y L i s t ; 

p u b l i c a b s t r a c t c l a s s Composite e x t e n d s Component { 

p r i v a t e L i s t c h i l d r e n 

= new A r r a y L i s t (); 

p u b l i c v o i d o p e r a t i o n ( ) { 

f o r ( Component c : c h i l d r e n ) c . o p e r a t i o n ( ) ; 

} 

p u b l i c v o i d add ( Component c ) { c h i l d r e n . add ( c ) ; } 

p u b l i c v o i d remove ( Component c ) { c h i l d r e n . remove ( c ) ; } 

p u b l i c Component g e t C h i l d ( i n t i ) { r e t u r n c h i l d r e n . g e t ( i ) ; } 

} 




Kollaborationen: 

Clients benutzen Component-Schnittstelle 

falls Empfänger ein Leaf ist, antwortet es direkt 

falls Empfänger ein Composite ist, wird die Anfrage an Teile 

weitergeleitet (möglicherweise mit weiteren eigenen Operationen vor 

und/oder nach der Weiterleitung) 




Konsequenzen: 

zweiteilt die Klassenhierarchie in Leaf und Composite mit 

einheitlicher Schnittstelle 

uniforme Verwendung auf Seiten des Clients 

neue Komponenten können leicht hinzugefügt werden 

könnte die Struktur unnötig allgemein machen (dynamische versus 

statische Typisierung) 

Implementierung: . . . Hinweise zur Implementierung . . . 



Dynamische versus statische Typisierung 

Mantel 

+entfernen() 

Verwender 

Mantel 

+entfernen() 

Blatt 

+entfernen() 

+hinzufügen(Artikel) 

Felge 

+entfernen() 

1 

0..1 

Artikel 

+entfernen() 

Rad 

+entfernen() 

0..1 

1..2 

Laufrad 

+entfernen() 

Artikel 

0..1 

0..1 

+entfernen() 

+hinzufügen(Artikel) 

+alleTeile(): list of Artikel 

Rahmen 

+entfernen() 

Laufrad 

+entfernen() 

1 

1 

Behälter 

+entfernen() 

Rahmen 

+entfernen() 

Felge 

+entfernen() 

Teile 

Rad 

+entfernen() 

for each t in Teile 

t.entfernen() 



Kategorien von Entwurfsmustern 

Erzeugungsmuster 

betreffen die Erzeugung von Objekten 

Beispiel: Factory Method 

Strukturelle Muster: 

betreffen Komposition von Klassen und Objekten 

Beispiel: Composite 

Verhaltensmuster: 

betreffen Interaktion und Verantwortlichkeiten 

Beispiel: Observer 



Fahrradladenbeispiel: Erweiterung für andere Domänen 

Anforderungen: 

Artikeldaten sollen von einer Datei gelesen werden können 

zukünftig sollen andere Domänen unterstützt werden (Fahrrad, 

Computer und Klettern) 

die Objekte dieser Domänen sind unterschiedlich 

notwendige Anpassungen sollen einfach realisiert werden können 

Lösungsstrategien: 

die Klassen der Benutzungsschnittstelle beziehen sich nur auf die 

Schnittstelle der abstrakten Klasse Artikel 

Datei hat gleiche Syntax für alle Domänen (nur die Inhalte variieren) 

die Artikel werden beim Einlesen der Datei als Objekte erzeugt 

→ aber der Leser muss doch die Konstruktoren der Objekte kennen, oder 

was? 



Lösungsstrategie 

GUI 

Artikel 

+ Preis() 

ComputerArtikel FahrradArtikel 

≪create≫ 

Rahmen 

Felge 

Leser 

+ lies(dateiname) 

≪create≫ ≪create≫ 

id=datei.liesId() 

s.FabrikMethode(id) 

FahrradSchöpfer 

ArtikelSchöpfer 

+ Artikel FabrikMethode(id) 

+FabrikMethode(id) 

if (id == ”rahmen”) 

return new Rahmen 

if (id == ”felge”) 

return new Felge 

ComputerSchöpfer 




Entwurfsmuster: Factory Method 



Anwendbarkeit 

eine Klasse weiß in manchen Fällen nicht im Voraus, von welcher 

Klasse ein zu erzeugendes Objekt sein soll 

die konkreten Unterklassen einer Klasse sollen dies entscheiden 

Verantwortlichkeit wird an Unterklassen delegiert, und das Wissen 

über die Unterklasse, an die delegiert wird, soll nur an einem Punkt 

vorhanden sein 



Teilnehmer 

Product 

deklariert die Schnittstelle von Objekten, die die Fabrikmethode 

erschafft 

ConcreteProduct 

implementiert die Product-Schnittstelle 

Creator 

deklariert die Fabrikmethode 

(optional) implementiert eine Standardfabrikmethode, die ein 

spezifisches konkretes Objekt erzeugt 

kann Fabrikmethode aufrufen, um ein Product-Objekt zu erzeugen 

ConcreteCreator 

überschreibt die Fabrikmethode, um konkretes Product-Objekt zu 

erschaffen 



Entwurfsmuster Observer 

Anwendbarkeit 

Komponenten hängen von anderen Komponenten ab 

Änderung der einen Komponente muss Änderung der anderen nach 

sich ziehen 

Komponenten sollen lose gekoppelt sein: Komponente kennt seine 

Abhängigen nicht im Voraus (zur Übersetzungszeit) 


Abhängige registrieren sich bei Komponente 

Komponente informiert alle registrierten Abhängigen über 

Zustandsänderung 



Entwurfsmuster Observer: Struktur 


2009-02-09 



Entwurfsmuster Observer 


Man beachte die Beziehung zu den Architekturmustern Blackboard und Model-View-Controller. 


Entwurfsmuster Observer: Teilnehmer Subject 


kennt seine Observer (zur Laufzeit) 

kann beliebig viele Observer haben 

stellt Schnittstelle zur Verfügung, um Observer zu registrieren und 

abzutrennen 

import j a v a . u t i l . L i s t ; 

import j a v a . u t i l . A r r a y L i s t ; 

p u b l i c a b s t r a c t c l a s s S u b j e c t { 

p r i v a t e L i s t o b s e r v e r s 

= new A r r a y L i s t (); 

p u b l i c v o i d Attach ( O b s e r v e r c ) { o b s e r v e r s . add ( c ) ; } 

p u b l i c v o i d Detach ( O b s e r v e r c ) { o b s e r v e r s . remove ( c ) ; } 

p u b l i c v o i d N o t i f y ( ) { 

f o r ( O b s e r v e r o : o b s e r v e r s ) o . update ( ) ; 

} 

} 



Entwurfsmuster Observer: Teilnehmer Observer 

deklariert Schnittstelle für die Update-Nachricht 

p u b l i c a b s t r a c t c l a s s O b s e r v e r { 

p u b l i c a b s t r a c t v o i d update ( ) ; 

} 



Entwurfsmuster Observer: Teilnehmer ConcreteSubject 

hat einen Zustand, der ConcreteObserver interessiert 

sendet Bekanntmachung via Notify(), wenn sich Zustand ändert 

(SetState) 

p u b l i c c l a s s Ampel e x t e n d s S u b j e c t { 

} 

p r i v a t e b o o l e a n r o t = f a l s e ; 

p u b l i c b o o l e a n i s t r o t ( ) { r e t u r n r o t ; } 

p u b l i c v o i d s c h a l t e n ( ) { 

s e t ( ! r o t ) ; 

} 

p r i v a t e v o i d s e t ( b o o l e a n newValue ) { 

r o t = newValue ; 

N o t i f y ( ) ; 

} 



Entwurfsmuster Observer: Teilnehmer ConcreteObserver 

kennt ConcreteSubject-Objekt 

verarbeitet Zustand dieses Subjects 

implementiert Update, um auf veränderten Zustand zu reagieren 

p u b l i c c l a s s Auto e x t e n d s O b s e r v e r { 

p r i v a t e Ampel ampel ; 

p r i v a t e b o o l e a n g a s p e d a l = f a l s e ; 

p u b l i c v o i d update ( ) { 

i f ( ! ampel . i s t r o t ( ) ) f a h r e n ( ) ; 

} 

p u b l i c v o i d f a h r e n ( ) { 

ampel . Detach ( t h i s ) ; 

g a s p e d a l = t r u e ; 

} 

p u b l i c v o i d stoppen ( Ampel a ) { 

ampel = a ; 

ampel . Attach ( t h i s ) ; 

g a s p e d a l = f a l s e ; 

} 

} 



Entwurfsmuster Observer: Konsequenzen 

abstrakte Kopplung zwischen Subject und Observer 

unterstützt Rundfunk (Broadcast) 

unerwartete Updates, komplizierter Kontrollfluss 

viel Nachrichtenverkehr, auch dann wenn sich ein irrelevanter Aspekt 

geändert hat 



Entwurfsmuster Observer: Verfeinerungen 

Push-Modell 

Subject sendet detaillierte Beschreibung der Änderung 

→ umfangreiches Update 

→ vermeidet GetState(), aber nicht Update() 

Pull-Modell 

Subject sendet minimale Beschreibung der Änderung 

→ Observer fragt gegebenfalls die Details nach 

→ erfordert weitere Nachrichten, um Details abzufragen 

Explizite Interessen 

Observers melden Interesse an spezifischem Aspekt an; Aspekt wird 

zusätzlicher Parameter von Update 



Architekturstile 

Definition 

Architekturstil: beschreibt eine Familie von Architekturen/Systeme als 

ein Muster der strukturellen Organisation durch 

ein Vokabular (Komponenten- und Konnektorentypen) 

und eine Menge von Einschränkungen, wie Komponenten und 

Konnektoren verbunden werden dürfen. 

Synonyme: Architekturmuster oder Architekturidiom. 



Architekturstil: Schichtung 

Netzwerk 

Nutzungsoberfläche 


Datenhaltung Utilities 




Architekturstil: Schichtung I 

Vokabular: 

Komponenten: Module und Schichten 

Konnektoren: Use-Beziehung 

Struktur: 

Module sind eindeutig einer Schicht zugeordnet 

Module einer Schicht dürfen nur auf Module derselben und der direkt 

darunter liegenden Schicht zugreifen 

Ausführungsmodell: 

Aufruf von Methoden tieferer Schichten 

Datenfluss in beide Richtungen (von der unteren Schicht zur oberen 

durch Rückgabeparameter) 



Architekturstil: Schichtung II 

Vorteile: 

Schicht implementiert virtuelle Maschine, deren Implementierung leicht 

ausgetauscht werden kann, ohne dass höhere Schichten geändert 

werden müssen 

Nachteile: 

höherer Aufwand durch das ” Durchreichen“ von Information 

Redundanz durch Dienste tieferer Schichten, die in hohen Schichten 

benutzt und auf allen Ebenen dazwischen repliziert werden 



Anforderungen 

Sättel: 12% 

Rahmen: 4% 

Felgen: 23% 

Mäntel: 43% 

Sonstige: 18% 


2009-02-09 



Architekturstil Model-View-Controller 

Anforderungen 

Anforderungen 

Sättel: 12% 

Rahmen: 4% 

Felgen: 23% 

Mäntel: 43% 

Sonstige: 18% 

Unterschiedliche Diagrammarten stellen statistische Daten über die nachgefragten Artikel dar. Die Diagramme 

müssen alle konsistent zu den aktuellen Daten sein. Neue Diagramme sollen leicht hinzugefügt werden können. 


Model-View-Controller (Buschmann u. a. 1996) 

4. call service 

GUI 

Controller 

− akzeptiert Benutzer− 

eingaben 

− übersetzt Eingaben 

in Nachrichten an 

Model (Fachlogik) bzw. 

an View (Anzeige) 

Subject 

2. display 

Model 

Observer 

update 

View 

− implementiert 

Fachlogik 

− registriert Views 

und Controllers 

− informiert Observer 

über Änderung 

− visualisiert Informationen 

über Model 

− holt sich Information 

vom Model 

1. register 

5. update 

3. getData 



Model-View-Controller Beispiel 

Ein Model: Wert in festem Bereich 

ProgressView 

SliderView 

Ein Controller: Verschiebung in SliderView verändert Model 

2009-02-09 




Architekturstil Model-View-Controller 


Dieses Beispiel und der Code dazu stammen von Thilo Mende. Ihm gilt mein Dank. 


Ein Model: Wert in festem Bereich 

ProgressView 

SliderView 

Ein Controller: Verschiebung in SliderView verändert Model


Beispiel-Model: Zustand 

1 import j a v a . u t i l . A r r a y L i s t ; 

2 import j a v a . u t i l . L i s t ; 

3 import j a v a x . swing . e v e n t . ChangeEvent ; 

4 import j a v a x . swing . e v e n t . C h a n g e L i s t e n e r ; 

5 

6 p u b l i c c l a s s Model { 

7 

8 // W e r t e b e r e i c h : 

9 p r i v a t e f i n a l i n t min = 0 ; // u n t e r e Grenze 

10 p r i v a t e f i n a l i n t max = 1 0 0 ; // o b e r e Grenze 

11 

12 // Zustand 

13 p r i v a t e i n t v a l u e = 5 0 ; 



Beispiel-Model: Oberver-Behandlung 

1 // a l l e O b s e r v e r 

2 p r i v a t e L i s t o b s e r v e r s ; 

3 

4 // K o n t r u k t o r 

5 p u b l i c Model ( ) { 

6 o b s e r v e r s = new A r r a y L i s t (); 

7 } 

8 

9 // neuen O b s e r v e r r e g i s t r i e r e n 

10 p u b l i c v o i d a d d C h a n g e L i s t e n e r ( C h a n g e L i s t e n e r o b s e r v e r ) { 

11 o b s e r v e r s . add ( o b s e r v e r ) ; 

12 } 

13 

14 // B e n a c h r i c h t i g u n g a l l e r O b s e r v e r ; 

15 // a u f z u r u f e n b e i a l l e n Zustandsänderungen 

16 p r i v a t e v o i d N o t i f y ( ) { 

17 f o r ( C h a n g e L i s t e n e r o b s e r v e r : o b s e r v e r s ){ 

18 o b s e r v e r . stateChanged ( new ChangeEvent ( t h i s ) ) ; 

19 } 

20 } 



Beispiel-Model: Setter und Getter 

1 p u b l i c i n t getMin ( ) { r e t u r n min ; } 

2 

3 p u b l i c i n t getMax ( ) { r e t u r n max ; } 

4 

5 p u b l i c i n t g e t V a l u e ( ) { r e t u r n v a l u e ; } 

6 

7 p u b l i c v o i d s e t V a l u e ( i n t v a l u e ) { 

8 i f ( v a l u e < min ){ 

9 t h i s . v a l u e = min ; 

10 } e l s e i f ( v a l u e > max){ 

11 t h i s . v a l u e = max ; 

12 } e l s e { 

13 t h i s . v a l u e = v a l u e ; 

14 } 

15 t h i s . N o t i f y ( ) ; 

16 // Zustand hat s i c h g e ä n d e r t 

17 } 



Beispiel-Controller 

1 p u b l i c c l a s s C o n t r o l l e r { 

2 

3 p r i v a t e Model model ; // das Model des C o n t r o l l e r s 

4 

5 // I n d i e s e r V a r i a n t e kennt d e r C o n t r o l l e r s e i n e 

6 // View n i c h t ; d i e A s s o z i a t i o n von View und C o n t r o l l e r 

7 // w i r d vom Hauptprogramm e t a b l i e r t 

8 

9 p u b l i c C o n t r o l l e r ( Model model ) { 

10 t h i s . model = model ; 

11 } 

12 

13 p u b l i c v o i d s e t V a l u e ( i n t v a l u e ) { 

14 model . s e t V a l u e ( v a l u e ) ; 

15 } 

16 } 



Beispiel-ProgressView I 

1 import j a v a x . swing . J P r o g r e s s B a r ; 



4 

5 p u b l i c c l a s s P r o g r e s s V i e w e x t e n d s J P r o g r e s s B a r 

6 implements C h a n g e L i s t e n e r { 

7 

8 p r i v a t e C o n t r o l l e r c o n t r o l l e r ; // View kennt C o n t r o l l e r 

9 p r i v a t e Model my model ; 

10 

11 p u b l i c P r o g r e s s V i e w ( C o n t r o l l e r c o n t r o l l e r , Model my model ){ 

12 s u p e r (VERTICAL ) ; 

13 t h i s . c o n t r o l l e r = c o n t r o l l e r ; 

14 t h i s . my model = my model ; 

15 

16 // Zustand von Model d a r s t e l l e n : 

17 t h i s . s e t V a l u e ( my model . g e t V a l u e ( ) ) ; 

18 

19 // R e g i s t r i e r u n g b e i Model 

20 my model . a d d C h a n g e L i s t e n e r ( t h i s ) ; 

21 } 

Rainer Koschke (Uni Bremen) 

22 


Software-Projekt Wintersemester 2008/09 478 / 634 

23 // R e d e f i n i t i o n ; e r e r b t 

24 Beispiel-ProgressView // e n t s p r i c h t update II 

von C h a n g e L i s t e n e r ; 

25 p u b l i c v o i d stateChanged ( ChangeEvent arg0 ) { 

26 s y n c h r o n i z e d ( t h i s ){ 

27 t h i s . s e t V a l u e ( my model . g e t V a l u e ( ) ) ; } 

28 } 

29 } 

1 // R e d e f i n i t i o n ; e r e r b t von C h a n g e L i s t e n e r ; 

2 // e n t s p r i c h t update 


4 s y n c h r o n i z e d ( t h i s ){ 

5 t h i s . s e t V a l u e ( my model . g e t V a l u e ( ) ) ; } 

6 } 

7 

8 } // Ende P r o g r e s s V i e w 



Beispiel-SliderView I 

1 import j a v a x . swing . J S l i d e r ; 



4 

5 p u b l i c c l a s s S l i d e r V i e w e x t e n d s J S l i d e r 

6 implements C h a n g e L i s t e n e r { 

7 p r i v a t e C o n t r o l l e r m y c o n t r o l l e r ; // View kennt C o n t r o l l e r 

8 p r i v a t e Model my model ; 

9 

10 // R e d e f i n i t i o n ; e r e r b t von C h a n g e L i s t e n e r ; 

11 // e n t s p r i c h t update 


13 t h i s . s e t V a l u e ( my model . g e t V a l u e ( ) ) ; 

14 } 



Beispiel-SliderView II 

1 // K o n s t r u k t o r 

2 p u b l i c S l i d e r V i e w ( f i n a l C o n t r o l l e r c o n t r o l l e r , Model model ) { 

3 s u p e r ( model . getMin ( ) , model . getMax ( ) , model . g e t V a l u e ( ) ) ; 

4 t h i s . my model = model ; 

5 t h i s . m y c o n t r o l l e r = c o n t r o l l e r ; 

6 

7 // R e g i s t r i e r u n g b e i Model 

8 model . a d d C h a n g e L i s t e n e r ( t h i s ) ; 

9 

10 // Zustand von Model d a r s t e l l e n : 

11 t h i s . a d d C h a n g e L i s t e n e r ( new C h a n g e L i s t e n e r ( ) { 


13 i f ( ! g e t V a l u e I s A d j u s t i n g ( ) ) { 

14 m y c o n t r o l l e r . s e t V a l u e ( g e t V a l u e ( ) ) ; 

15 } 

16 } 

17 } ) ; 

18 } 

19 } // Ende von S l i d e r V i e w 



Beispiel-Hauptprogramm I 

1 import j a v a . awt . BorderLayout ; 

2 import j a v a x . swing . JFrame ; 

3 import j a v a x . swing . WindowConstants ; 

4 

5 p u b l i c c l a s s MVCDemo { 

6 p u b l i c s t a t i c v o i d main ( S t r i n g [ ] a r g s ) { 

7 MVCDemo demo = new MVCDemo ( ) ; 

8 } 

9 } 



Beispiel-Hauptprogramm II 

1 p u b l i c MVCDemo( ) { 

2 Model model = new Model ( ) ; 

3 

4 // A s s o z i a t i o n d e s s e l b e n C o n t r o l l e r s mit b e i d e n Views 

5 C o n t r o l l e r c o n t r o l l e r = new C o n t r o l l e r ( model ) ; 

6 P r o g r e s s V i e w p r o g r e s s = new P r o g r e s s V i e w ( c o n t r o l l e r , model ) ; 

7 S l i d e r V i e w s l i d e r = new S l i d e r V i e w ( c o n t r o l l e r , model ) ; 

8 

9 // F e n s t e r um a l l e s 

10 JFrame d i s p l a y F r a m e = new JFrame ( ” D i s p l a y ” ) ; 

11 d i s p l a y F r a m e . getContentPane ( ) 

12 . add ( p r o g r e s s , BorderLayout .CENTER ) ; 

13 d i s p l a y F r a m e . getContentPane ( ) 

14 . add ( s l i d e r , BorderLayout .SOUTH) ; 

15 d i s p l a y F r a m e . s e t D e f a u l t C l o s e O p e r a t i o n 

16 ( WindowConstants . EXIT ON CLOSE ) ; 

17 d i s p l a y F r a m e . pack ( ) ; 

18 d i s p l a y F r a m e . s e t V i s i b l e ( t r u e ) ; 

19 } 

20 

21 } // End MVCDemo 




Was ist ein Entwurfsmuster? 

Warum sind sie interessant für die Software-Entwicklung? 

Erläutern Sie eines der in der Vorlesung vorgestellten Entwurfsmuster. 

Was ist ein Architekturstil? 

Nennen Sie Beispiele für Architekturstile. Erläutern Sie die Stile. 




Buschmann u. a. (1996) beschreiben Architekturstile bzw. -muster 

Shaw und Garlan (1996) geben eine Einführung in 

Software-Architektur und beschreiben einige Architekturstile bzw. 

-muster 

Das Standardbuch zu Entwurfsmustern ist das von Gamma u. a. 

(2003) 


Software-Test 






Ablauf 

Zeitplan 

Anmeldung 




Kontaktdaten 

Ressourcen 

Lehrbücher 








Vorgehen 

Lernziele 

Inhalt 

Zeitplan 


Risiken 


Notwendigkeit Erfahrungen aus unddem Grenzen SWP des 05/06 Tests verstehen 

Arten 

Allgemeine 

und Varianten 

Risiken in 

des 

einem 

Software-Tests 


kennen 


eine geeignete Test-Strategie auswählen können 

Lernziele 

Testpläne Herausforderungen erstellen können 

Tests Aktivitäten durchführen können 

Ist-Analyse 

N.B.: Diese Darstellung folgt in weiten Teilen Kapitel 11 des Buchs von 


Brügge und Dutoit (2004). 

Befragung 

Beobachtung 




Bedeutung 




Ein korrektes Programm? 

c l a s s K a l e n d e r { 

p u b l i c s t a t i c c l a s s MonatUngueltig e x t e n d s E x c e p t i o n { } ; 

p u b l i c s t a t i c c l a s s J a h r U n g u e l t i g e x t e n d s E x c e p t i o n { } ; 

p u b l i c s t a t i c b o o l e a n i s t S c h a l t J a h r ( i n t j a h r ) 

{ r e t u r n ( j a h r % 4) == 0 ; } 

p u b l i c s t a t i c i n t TageProMonat ( i n t monat , i n t j a h r ) 

throws MonatUngueltig , J a h r U n g u e l t i g { 

i n t anzTage ; 

i f ( j a h r < 1) { throw new J a h r U n g u e l t i g ( ) ; } 

i f ( monat i n {1 , 3 , 5 , 7 , 10 , 12}) { anzTage = 3 2 ; } 

e l s e i f ( monat i n {4 , 6 , 9 , 11}) { anzTage = 3 0 ; } 

e l s e i f ( monat == 2) { 

i f ( i s t S c h a l t J a h r ( j a h r ) ) anzTage = 2 9 ; 

e l s e anzTage = 2 8 ; 

} e l s e throw new MonatUngueltig ( ) ; 

r e t u r n anzTage ; 

} 

} 



Testen und seine Begriffe 

Definition 

Zuverlässigkeit: Maß für den Erfolg, inwieweit das beobachtete Verhalten 

mit dem spezifizierten übereinstimmt. 

Software-Zuverlässigkeit: Wahrscheinlichkeit, dass ein Software-System 

während einer festgelegten Zeit unter festgelegten Bedingungen keinen 

Systemausfall verursachen wird (IEEE Std. 982-1989 1989). 



Definition 

Fehlerbegriff 

Störfall (Ausfall, Failure): jegliche Abweichung des beobachteten 

Verhaltens vom spezifizierten. 

Im Nicht-Schaltjahr 200 wird für den Monat Februar 29 ausgegeben. 

Fehlerhafter Zustand (Error): Zustand, in dem ein Weiterlaufen des 

Systems zu einem Störfall führen würde. 

Die Funktion istSchaltjahr(200) liefert true. 

Fehler (Defekt, Fault): mechanische oder algorithmische Ursache eines 

fehlerhaften Zustands. 

2009-02-09 

Die Prüfung in istSchaltjahr ist falsch. 




Begriffe des Testens 

Fehlerbegriff 

Fehlerbegriff 

Definition 

Störfall (Ausfall, Failure): jegliche Abweichung des beobachteten 

Verhaltens vom spezifizierten. 

Im Nicht-Schaltjahr 200 wird für den Monat Februar 29 ausgegeben. 

Fehlerhafter Zustand (Error): Zustand, in dem ein Weiterlaufen des 

Systems zu einem Störfall führen würde. 

Die Funktion istSchaltjahr(200) liefert true. 

Fehler (Defekt, Fault): mechanische oder algorithmische Ursache eines 

fehlerhaften Zustands. 

Die Prüfung in istSchaltjahr ist falsch. 

Mechanische Ursache: Fehler in der virtuellen Maschine (Plattform); z.B. Bug in Java-Virtual-Machine, Compiler 

oder Hardwaredefekt. 

Algorithmische Ursache: Fehler im Algorithmus, z.B. Off-by-One-Fehler, uninitialisierte Variable, 

Performanzengpässe aufgrund eines schlechten Entwurfs.


Testen und seine Begriffe 

Definition 

Test: systematischer Versuch, in der implementierten Software Defekte zu 

finden. 

Erfolgreicher (positiver) Test: Test, der Defekt aufgedeckt hat. 

Erfolgloser (negativer) Test: Test, der keinen Defekt aufgedeckt hat. 

→ Tests sind Experimente zur Falsifikation der Hypothese “System ist 

korrekt”. 

→ Aus negativem Test folgt noch lange nicht, dass kein Defekt 

vorhanden ist. 



Der Test und seine Verwandten 

Tests sind nur ein Mittel, die Zuverlässigkeit zu steigern: 

Fehlervermeidung (z.B. Entwicklungsmethoden, Verifikation, statische 

Analyse) 

Fehlerentdeckung (z.B. Tests, assert, “Quality-Feedback-Agent”, 

Flugschreiber) 

Fehlertoleranz: Behandlung von Fehlern zur Laufzeit, um Programm 

fortzusetzen 



Soziologie des Testens 

Testen wird häufig (aber zu unrecht) als niedere Arbeit angesehen 

→ Frischlinge werden zu Testern 

Tester brauchen jedoch ein umfassendes Systemverständnis 

(Anforderungen, Entwurf, Implementierung) 

Tester brauchen darüber hinaus, Wissen über Prüftechniken 

Autoren haben eine Lesart der Spezifikation verinnerlicht 

Denkfehler in der Implementierung werden sich bei Erstellung von 

Testfällen wiederholen 

→ Tester sollten nicht gleichzeitig Autoren sein 

Tester versuchen, Fehler zu finden 

das Produkt wird kritisiert, dann fühlen sich Autoren selbst kritisiert 

→ Egoless-Programming (eine schöne Illusion) 



Managementplan 

Klassenentwurf 

Integrationsstrategie 

Subsystemzerlegung 

Funktionale 

Anforderungen 

Nichtfunktionale 

Anforderungen 

Entwickler Kunde Benutzer 

Testplan 

Komponententest 

Integrationstest 

Strukturtest 

Funktionstest 

Leistungstest 

Benutzungsschnittstellenentwurf 

Akzeptanztest 

Installationstest 

Benutzbarkeitstest 

Benutzungshandbuch 

Feldtest 

Projektvereinbarung 

Normalbetrieb 


2009-02-09 


Testfall 



Testaktivitäten 

Quelle: Brügge und Dutoit (2004) 

• Testplanung: Betriebsmittelzuteilung und Zeitplan 

Managementplan 


Integrationsstrategie 

Subsystemzerlegung 

Funktionale 

Anforderungen 

Nichtfunktionale 

Anforderungen 

• Benutzbarkeitstest: Fehler im Benutzerschnittstellenentwurf aufdecken; siehe (Papier-)Prototypen 

• Komponententest: Fehler in einzelner Komponente (Klasse, Paket o.Ä.) aufdecken 

• Integrationstest: Fehler im Zusammenspiel von Komponenten aufdecken 

Entwickler Kunde Benutzer 

• Strukturtest: Integrationstest mit allen Komponenten (abschließender und vollständiger Integrationstest) 

• Systemtest: Test aller in einem System zusammengefasster Subsysteme mit dem Ziel, Fehler bezüglich der Szenarien aus 

der problemstellung sowie der Anforderungen und Entwurfsziele, die in der Analyse bzw. im Systementwurf identifiziert 

wurden, zu finden 

• Funktionstest: testet die Anforderungen aus dem Lastenheft und die Beschreibung des Benutzerhandbuchs 

• Leistungstest: Test der Leistungsanforderungen (Performanz und Speicherbedarf) 

• Installationstest: Test der Installation beim Kunden (evtl. mit der Hilfe der Entwickler) 

• Akzeptanztest: Prüfung bzgl. Projektvereinbarung durch den Kunden (evtl. mit der Hilfe der Entwickler) 

Ein Testfall besteht aus: 

Name 

Ort: vollständiger Pfadname des 

lauffähigen Testprogramms 

Eingabe: Eingabedaten oder 

Befehle 

Orakel: erwartete 

Testergebnisse, die mit den 

aktuellen Testergebnissen des 

Testlaufs verglichen werden 

Protokoll: gesamte Ausgabe, die 

durch Test erzeugt wird 

Testplan 



Strukturtest 

Funktionstest 

Leistungstest 

Eingabe Prüfling Ist-Ergebnis 

Benutzungsschnittstellenentwurf 

Akzeptanztest 

Installationstest 

Benutzbarkeitstest 


Feldtest 

Projektvereinbarung 

Normalbetrieb 

Vergleich Protokoll 

Soll-Ergebnis 



Komponententest: Teststümpfe und -treiber 

2009-02-09 

spätere Umgebung Testumgebung 

Benutzerklasse Y 

Prüfling C 

Benutzerklasse X 

Benutzte Klasse A Benutzte Klasse B 

Testtreiber 

Prüfling C 

Benutzte Klasse A Teststumpf für benutzte Klasse B 




Teststümpfe und -treiber 



spätere Umgebung Testumgebung 

Benutzerklasse Y 

Prüfling C 

Benutzerklasse X 

Benutzte Klasse A Benutzte Klasse B 

Bestreben: Komponenten so früh wie möglich testen. 

Problem: die benutzenden Komponenten und die benutzten Komponenten existieren möglicherweise noch nicht. 

Lösung: Testtreiber und -stümpfe 

• Prüfling/Testkomponente: die zu testende Klasse/Komponente 

• Testtreiber: simuliert den Teil des Systems, der die Testkomponente benutzt 

• Teststumpf: simuliert die Komponenten, die die Testkomponente benutzt 

In vielen Fällen: Aufwand für Teststumpf entspricht Aufwand für die eigentliche Komponente → 

Bottom-Up-Entwicklung der Komponenten 

Testtreiber 

Prüfling C 

Benutzte Klasse A Teststumpf für benutzte Klasse B


Typen von Komponententests 

Definition 

Black-Box-Tests: Komponente wird nur mit Kenntnis der 

Schnittstellenbeschreibung entworfen (Implementierung unbekannt). 

Techniken: 

Äquivalenztest 

Grenztest 

(zustandsbasierter Test) 

. . . 



Typen von Komponententests 

Definition 

White-/Glass-Box-Tests: Testfall wird mit Kenntnis der Implementierung 

entworfen. 

Techniken: 

Pfadtest 

(zustandsbasierter Test) 

. . . 



Äquivalenztest I 

Ziel: Testfälle minimieren. 

Idee: 

Kriterien: 

Äquivalente Testfälle werden zusammengefasst. 

Ein Testfall wird als Repräsentant der Äquivalenzklasse aufgestellt. 

Abdeckung: Jede mögliche Eingabe gehört zu einer der 

Äquivalenzklassen 

Disjunktion: Keine Eingabe gehört zu mehr als einer einzigen 

Äquivalenzklasse 

Repräsentation (die Hoffnung): Falls Ausführung einen fehlerhaften 

Zustand anzeigt, sobald ein bestimmtes Mitglied einer 

Äquivalenzklasse als Eingabe benutzt wird, dann kann derselbe 

fehlerhafte Zustand entdeckt werden, wenn irgendein anderes Mitglied 

dieser Äquivalenzklasse als Eingabe verwendet wird 



Äquivalenztest II 

Für jede Äquivalenzklasse werden mindestens zwei Testeingaben 

ausgewählt: 

typische Eingabe, die den allgemeinen Fall abprüft 

unvollständige Eingabe, die auf korrektes Verhalten im Fehlerfall prüft 



Ein korrektes Programm? 

c l a s s K a l e n d e r { 

p u b l i c s t a t i c c l a s s MonatUngueltig e x t e n d s E x c e p t i o n { } ; 

p u b l i c s t a t i c c l a s s J a h r U n g u e l t i g e x t e n d s E x c e p t i o n { } ; 

p u b l i c s t a t i c b o o l e a n i s t S c h a l t J a h r ( i n t j a h r ) 

{ r e t u r n ( j a h r % 4) == 0 ; } 

p u b l i c s t a t i c i n t TageProMonat ( i n t monat , i n t j a h r ) 

throws MonatUngueltig , J a h r U n g u e l t i g { 

i n t anzTage ; 

i f ( j a h r < 1) { throw new J a h r U n g u e l t i g ( ) ; } 

i f ( monat i n {1 , 3 , 5 , 7 , 10 , 12}) { anzTage = 3 2 ; } 

e l s e i f ( monat i n {4 , 6 , 9 , 11}) { anzTage = 3 0 ; } 

e l s e i f ( monat == 2) { 

i f ( i s t S c h a l t J a h r ( j a h r ) ) anzTage = 2 9 ; 

e l s e anzTage = 2 8 ; 

} e l s e throw new MonatUngueltig ( ) ; 

r e t u r n anzTage ; 

} 

} 



Beispielspezifikation 

Kalender.TageProMonat(monat,jahr) liefere die Tage eines Monats 

wie folgt: 

Fehlerfall 

monat ∈ {1, 3, 5, 7, 8, 10, 12} ⇒ 31 

monat ∈ {4, 6, 9, 11} ⇒ 30 

jahr ist ein Schaltjahr ∧ monat = 2 ⇒ 29 

jahr ist kein Schaltjahr ∧ monat = 2 ⇒ 28 

monat < 1 ∨ monat > 12 ⇒ throw MonatUngueltig 

jahr < 0 ⇒ throw JahrUngueltig 



Beispieläquivalenzklassen 

Äquivalenzklassen: 

für Monate: 

Monate mit 31 Tagen 

Monate mit 30 Tagen 

Monate mit 28 oder 29 Tagen 

monat außerhalb gültigen Bereichs 

für Jahre: 

Schaltjahre 

Jahre, die keine Schaltjahre sind 

jahr außerhalb gültigen Bereichs 

→ Kombination der Äquivalenzklassen für alle Eingabeparameter ergibt 

Äquivalenzklassen für TageProMonat 



Beispieltestfälle 

Test der Interaktion von monat und jahr durch Kombination: 

Äquivalenzklasse monat jahr Soll 

31-Tage-Monat, Nicht-Schaltjahre 7 1901 31 

31-Tage-Monat, Schaltjahre 7 1904 31 

30 Tage-Monat, Nicht-Schaltjahre 6 1901 30 

30 Tage-Monat, Schaltjahre 6 1904 30 

Februar, Nicht-Schaltjahre 2 1901 28 

Februar, Schaltjahre 2 1904 29 

monat inkorrekt, jahr korrekt 17 1901 MonatUngueltig 

monat korrekt, jahr inkorrekt 7 -1901 JahrUngueltig 

monat inkorrekt, jahr inkorrekt 17 -1901 MonatUngueltig 

∨JahrUngueltig 



Komponententest mit JUnit 

import j u n i t . framework . ∗ ; 

p u b l i c c l a s s K a l e n d e r T e s t e x t e n d s TestCase { 

} 

p u b l i c K a l e n d e r T e s t ( S t r i n g name ) { 

s u p e r ( name ) ; 

} 

. . . 

// Test−Methoden 

. . . 

p u b l i c s t a t i c v o i d main ( S t r i n g [ ] a r g s ) { 

j u n i t . s w i n g u i . TestRunner . run ( K a l e n d e r T e s t . c l a s s ) ; 

} 




p u b l i c v o i d testTageProMonat1 ( ) { 

// 31−Tage−Monat , Nicht−S c h a l t j a h r e 

a s s e r t E q u a l s ( 3 1 , K a l e n d e r . TageProMonat ( 7 , 1 9 0 1 ) ) ; 

} 

p u b l i c v o i d testTageProMonat9 ( ) { 

// monat i n k o r r e k t , j a h r i n k o r r e k t 

t r y { i n t t = K a l e n d e r . TageProMonat ( 1 3 , −1901); 

a s s e r t T r u e ( f a l s e ) ; } 

c a t c h ( K a l e n d e r . J a h r U n g u e l t i g j e ) {} // e x p e c t e d 

c a t c h ( K a l e n d e r . MonatUngueltig me) {} // e x p e c t e d 

c a t c h ( E x c e p t i o n e ) { f a i l ( ” E x c e p t i o n e x p e c t e d ” ) ; } 

} 






Grenztest 

Beobachtung: “Off-by-one”-Fehler kommen häufig vor. 

Idee: Grenzen (Randbereiche) von 

Äquivalenzklassen testen. 

Schaltjahrregel: Ein Jahr ist ein Schaltjahr, wenn 

es durch 4 teilbar ist, 

es sei denn, es ist durch 100 teilbar, 

es sei denn, es ist durch 400 teilbar 

2000 ist ein Schaltjahr, 1900 ist kein Schaltjahr. 



Grenztest 

Äquivalenzklasse monat jahr Soll 

Schaltjahre teilbar durch 400 2 2000 29 

Nicht-Schaltjahre teilbar durch 100 2 1900 28 

gültige Monate 1 2000 31 

gültige Monate 12 2000 31 

Nichtpositive ungültige Monate 0 1234 MonatUngueltig 

Positive ungültige Monate 13 1234 MonatUngueltig 

gültiges Jahr 2 0 29 

gültiges Jahr 3 Max-Int 31 

ungültiges Jahr 2 -1 JahrUngueltig 



Pfadtest 

Ziel: Testfälle sollten alle Code-Teile testen. 

Idee: Konstruiere Testfälle, die jeden möglichen Pfad mindestens einmal 

ausführen. 

Ausgangspunkt: Kontrollflussgraph (KFG) pro Methode. 

Knoten: Anweisungen und Prädikate 

zwei weitere Knoten: eindeutiger Anfang und Ende einer Methode 

Kanten: Kontrollfluss zwischen Anweisungen (unbedingt) und 

Prädikaten (bedingt) 

Pfad: Menge von Kanten, die vom Anfang zum Ende des KFGs führen 



Verzweigung 

[jahr < 1] 

[monat in {1,3,5,7,10,12}] 

[monat in {4,6,9,11}] 

[monat == 2] 

throw new MonatUngueltig 

Ende 

Anfang 

throw new JahrUngueltig 

Bedingung 

n = 30 

n = 32 

[istSchaltJahr(jahr)] 

n = 29 n = 28 

return n 

Aktivität 



Maße der Testabdeckung 

C0, Anweisungsüberdeckung (Befehlsabdeckung/Statement-Coverage): 

Verhältnis von Anzahl der mit Testdaten durchlaufenen 

Anweisungen zur Gesamtanzahl der Anweisungen. 

Verzweigung 

[jahr < 1] 

[monat in {1,3,5,7,10,12}] 

[monat in {4,6,9,11}] 

[monat == 2] 


Ende 

Anfang 


Bedingung 

n = 30 

n = 32 


n = 29 n = 28 

return n 

Aktivität 


2009-02-09 






C0, Anweisungsüberdeckung (Befehlsabdeckung/Statement-Coverage): 

Verhältnis von Anzahl der mit Testdaten durchlaufenen 

Anweisungen zur Gesamtanzahl der Anweisungen. 

Befehlsabdeckung / statement coverage / C0-Abdeckung: Gesucht ist eine Menge von Testfällen, die jeden Befehl 

in dem zu testenden Code mindestens einmal ausführen. Dieses Kriterium ist sehr schwach, denn es werden in der 

Regel nur sehr wenige Fehler (20%) gefunden. Fehler entstehen meist dadurch, dass Befehle in bestimmten 

Zuständen ausgeführt werden und nicht nur in irgendeinem. 

Ein Code-Coverage-Tool kann helfen, um zu sehen, welche Befehle nicht oder selten ausgeführt werden. Denn ein 

notwendiges Kriterium ist die Befehlsabdeckung allemal. 



C1, Zweig-/Entscheidungsüberdeckung Verhältnis von Anzahl der mit 

Testdaten durchlaufenen Zweige zur Gesamtanzahl der 

Zweige. 

Verzweigung 

[jahr < 1] 

[monat in {1,3,5,7,10,12}] 

[monat in {4,6,9,11}] 

[monat == 2] 


Ende 

Anfang 


Bedingung 

n = 30 

n = 32 

n = 29 n = 28 

return n 

Aktivität 



Verzweigung 

[jahr < 1] 

[monat in {1,3,5,7,10,12}] 

[monat in {4,6,9,11}] 

[monat == 2] 


Ende 

Anfang 


Bedingung 

n = 30 

n = 32 


n = 29 n = 28 

return n 

Aktivität

2009-02-09 






C1, Zweig-/Entscheidungsüberdeckung Verhältnis von Anzahl der mit 

Testdaten durchlaufenen Zweige zur Gesamtanzahl der 

Zweige. 

Jedes Prädikat muss im Code mindestens einmal wahr und einmal falsch sein. Schließt die Befehlabdeckung mit ein 

(es sei denn, es gibt unerreichbare Befehle) und ist äquivalent zur Befehlsabdeckung, wenn jeder wahr/falsch-Fall 

auch mindestens einen Befehl beinhaltet. Dieses Kriterium ist weiterhin relativ schwach. Erfahrungsgemäß 25% 

Fehlerfindung. 



C2, Bedingungsabdeckung Verhältnis von Anzahl der mit Testdaten 

durchlaufenen Terme innerhalb von Entscheidungen zur 

Gesamtanzahl der Terme. 

i := 1 ; 

l o o p 

found := a ( i ) = key ; 

e x i t when found or i = M a x E n t r i e s ; 

i := i + 1 ; 

end l o o p ; 


Verzweigung 

[jahr < 1] 

[monat in {1,3,5,7,10,12}] 

[monat in {4,6,9,11}] 

[monat == 2] 


Ende 

Anfang 


Bedingung 

n = 30 

n = 32 


n = 29 n = 28 

return n 

Aktivität

2009-02-09 






C2, Bedingungsabdeckung Verhältnis von Anzahl der mit Testdaten 

durchlaufenen Terme innerhalb von Entscheidungen zur 

Gesamtanzahl der Terme. 

i := 1 ; 

l o o p 

found := a ( i ) = key ; 

e x i t when found or i = M a x E n t r i e s ; 

i := i + 1 ; 

end l o o p ; 

Nur verschieden von C1, wenn logische Operatoren keine Short-Circuit-Operatoren sind (d.h. es werden 

grundsätzlich alle Operanden eines logischen Operators ausgewertet). 

In jedem Prädikat wird jeder Bedingungsteil (Konjunktions- oder Alternationsglied) mindestens einmal wahr und 

einmal falsch gesetzt. 

N.B.: Das umfasst nicht die Entscheidungsfallabdeckung: 

true and false → false-Kante 

false and true → false-Kante 

(sofern der Operator and kein Short-Circuit-Operator ist). 

Man sollte beide kombinieren. 

Man bedenke, dass false and x → false ist wenn x keine Seiteneffekte hat. 



C3, Abdeckung aller Bedingungskombinationen Verhältnis von Anzahl der 

mit Testdaten durchlaufenen Bedingungskombinationen zur 

Gesamtanzahl der Bedingungskombinationen. 

Verzweigung 

[jahr < 1] 

[monat in {1,3,5,7,10,12}] 

[monat in {4,6,9,11}] 

[monat == 2] 


Ende 

Anfang 


Bedingung 

n = 30 

n = 32 


n = 29 n = 28 

return n 

Aktivität 


2009-02-09 






C3, Abdeckung aller Bedingungskombinationen Verhältnis von Anzahl der 

mit Testdaten durchlaufenen Bedingungskombinationen zur 

Gesamtanzahl der Bedingungskombinationen. 

Bedingungenkombinationsabdeckung / multiple condition coverage: Hier werden Prädikate gemäß einer 

Wahrheitstabelle alle Bedingungskombinationen aller in allen Kombinationen mal wahr und mal falsch gesetzt. 

Interessanterweise bringt dies nicht viel mehr an Erfolg, aber viel mehr an Aufwand. · 



C4, Pfadabdeckung Verhältnis von Anzahl der mit Testdaten 

durchlaufenen Pfade zur Gesamtanzahl der Pfade. 

Verzweigung 

[jahr < 1] 

[monat in {1,3,5,7,10,12}] 

[monat in {4,6,9,11}] 

[monat == 2] 


Ende 

Anfang 


Bedingung 

n = 30 

n = 32 

n = 29 n = 28 

return n 

Aktivität 



Verzweigung 

[jahr < 1] 

[monat in {1,3,5,7,10,12}] 

[monat in {4,6,9,11}] 

[monat == 2] 


Ende 

Anfang 


Bedingung 

n = 30 

n = 32 


n = 29 n = 28 

return n 

Aktivität

2009-02-09 






C4, Pfadabdeckung Verhältnis von Anzahl der mit Testdaten 

durchlaufenen Pfade zur Gesamtanzahl der Pfade. 

(Eingeschränkte) Pfadabdeckung: Hier werden auch bei Schleifen mehrere Durchläufe gemacht (keinmal, einmal, 

zweimal, typische Anzahl, maximale Anzahl). In aller Regel wird nicht auf diese Weise getestet, da der Aufwand 

sehr groß ist. 


Probleme beim Pfadtest 

Unrealisierbare Pfade: 

f o r ( i = 0 ; i < o . f o o ( ) ; i ++) // immer o . f o o ( ) == 0 ? 

{ 

x = . . . 

} 

. . .x. . . // hat x d e f i n i e r t e n Wert ? 

i f ( p ) {. . .} 

i f ( q ) { // p => not q ?? 

. . . 

} 


Verzweigung 

[jahr < 1] 

[monat in {1,3,5,7,10,12}] 

[monat in {4,6,9,11}] 

[monat == 2] 


Ende 

Anfang 


Bedingung 

n = 30 

n = 32 


n = 29 n = 28 

return n 

Aktivität


Polymorphismustest 

2009-02-09 

c l a s s T { p u b l i c i n t f o o ( ) ; } 

c l a s s NT e x t e n d s T { p u b l i c i n t f o o ( ) ; } 

c l a s s F a c t o r y { T c r e a t e ( i n t i ) ; } 

c l a s s UnderTest { 

v o i d bar ( i n t i ) 

{ T t = ( new F a c t o r y ) . c r e a t e ( i ) ; 

} 

} 

i f ( t . f o o ( ) > 0) 

doSomething ( ) ; 







c l a s s T { p u b l i c i n t f o o ( ) ; } 

c l a s s NT e x t e n d s T { p u b l i c i n t f o o ( ) ; } 

c l a s s F a c t o r y { T c r e a t e ( i n t i ) ; } 

c l a s s UnderTest { 

v o i d bar ( i n t i ) 

{ T t = ( new F a c t o r y ) . c r e a t e ( i ) ; 

} 

} 

i f ( t . f o o ( ) > 0) 

doSomething ( ) ; 

Methode bar kann nicht in Isolation getestet werden. Welches foo im Beispiel ausgeführt wird, hängt vom 

dynamischen Typ von t ab. Davon hängen wiederum die weiteren Pfade ab.


Zustandsbasiertes Testen 

Verhalten von Komponente hängt ab von 

der Eingabe 

ihrem Zustand 

c l a s s Stack { 

p u b l i c s t a t i c c l a s s EmptyStack e x t e n d s E x c e p t i o n { } ; 

p u b l i c s t a t i c c l a s s F u l l S t a c k e x t e n d s E x c e p t i o n { } ; 

} 

p u b l i c Stack ( i n t maxSize ) {. . . } ; 

p u b l i c b o o l e a n isEmpty ( ) {. . . } ; 

p u b l i c i n t s i z e ( ) {. . . } ; 

p u b l i c Object top ( ) throws EmptyStack {. . . } ; 

p u b l i c v o i d push ( Object o ) throws F u l l S t a c k {. . . } ; 

p u b l i c v o i d pop ( ) throws EmptyStack {. . . } ; 



Zustände eines Stacks 




Für alle Zustände einer Komponente: 

Komponente wird in zu testenden Zustand gebracht 

Test für alle möglichen Stimuli: 

korrekte Eingaben, 

fehlerhafte Eingaben 

und Aktionen, die Zustandsübergänge bewirken 



Zustandsbasiertes Testen I 

p u b l i c v o i d t e s t S t a t e F u l l ( ) { 

// t e s t o f S t a t e f u l l 

f i n a l i n t max = 1 0 0 ; 

Stack s = new Stack ( max ) ; 

Object l a s t = new Object ( ) ; 

// put Stack i n t o s t a t e f u l l 

f o r ( i n t i = 1 ; i


Zustandsbasiertes Testen II 

} 

// t e s t l e g a l a c t i o n ’ isEmpty ’ ; no t r a n s i t i o n 

a s s e r t E q u a l s ( f a l s e , s . isEmpty ( ) ) ; 

// t e s t i l l e g a l a c t i o n ’ push ’ 

t r y { s . push ( new Object ( ) ) ; f a i l ( ” e x c e p t i o n e x p e c t e d ” ) ; } 

c a t c h ( Stack . F u l l S t a c k e ) {} // OK 

// t e s t l e g a l a c t i o n / t r a n s i t i o n ’ pop ’ 

s . pop ( ) ; 

// r e v e r s e t r a n s i t i o n 

s . push ( new Object ( ) ) ; 



Vergleich von White- und Black-Box-Tests 

Black-Box-Tests (Funktionstests) betrachten den Prüfling als schwarze 

Box. Sie setzen keine Kenntnisse über die Interna voraus. 

White-Box-Tests (Strukturtests, Glass-Box-Tests) betrachten Interna des 

Prüflings, um Testfälle zu entwickeln. 

Eigenschaft Black-Box-Test White-Box-Test 

Test auf Basis von Schnittstellen- Lösung 

spezifikation 

Wiederverwendung bei ja eingeschränkt 

Änderung der Struktur 

Geeignet für Testart alle Komponententest 

Finden Fehler aufgrund von Abweichung von Spez. eher Kodierfehler 


2009-02-09 






Black-Box-Tests (Funktionstests) betrachten den Prüfling als schwarze 

Box. Sie setzen keine Kenntnisse über die Interna voraus. 

White-Box-Tests (Strukturtests, Glass-Box-Tests) betrachten Interna des 

Prüflings, um Testfälle zu entwickeln. 

Eigenschaft Black-Box-Test White-Box-Test 

Test auf Basis von Schnittstellen- Lösung 

spezifikation 

Wiederverwendung bei ja eingeschränkt 

Änderung der Struktur 

Geeignet für Testart alle Komponententest 

Finden Fehler aufgrund von Abweichung von Spez. eher Kodierfehler 

White-Box Methoden eignen sich lediglich für den Modultest, allenfalls noch für den Integrationstest. Die Idee ist 

es, die Testfälle anhand der inneren Programmstruktur zu finden. 

Achtung: White-Box-Testing testet keine fehlenden Pfade oder Anweisungen. Das ist eine echte Schwäche, denn es 

wird nur das getestet, woran der Programmierer auch wirklich (wenn auch evtl. fehlerhaft) gedacht hat! 

Black-Box-Tests können wiederverwendet werden, wenn sie die Struktur, aber nicht das Verhalten ändert. 


Black- versus White-Box-Tests 

Nicht entweder-oder, sondern sowohl-als-auch! 

Komplementäre Verwendung: 

1 Erstelle Funktionstest 

2 Messe Abdeckung 

3 Wenn Abdeckung nicht ausreichend; ergänze durch Strukturtest; 

zurück zu 2. 



Strategien des Integrationstests I 

Urknalltest: alle Komponenten werden einzeln entwickelt und dann in 

einem Schritt integriert 

→ erschwert Fehlersuche 

Bottom-Up: Integration erfolgt inkrementell in umgekehrter Richtung 

zur Benutzt-Beziehung 

→ keine Testrümpfe notwendig (aber Testtreiber) 

→ Fehler in der obersten Schicht werden sehr spät entdeckt; die enthalten 

jedoch die Applikationslogik 

Top-Down: Integration erfolgt in Richtung der Benutzt-Beziehung 

→ Fehler in der obersten Schicht werden sehr früh entdeckt 

→ Testrümpfe notwendig 



Strategien des Integrationstests II 

Sandwich-Test-Strategie: Kombination von Top-Down und 

Bottom-Up 

Identifikation der zu testenden Schicht: Zielschicht 

zuerst: individuelle Komponententests 

dann: kombinierte Schichttests: 

- Oberschichttest mit Zielschicht 

- Zielschicht mit Unterschicht 

- alle Schichten zusammen 



Leistungstests 

Härtetest: viele gleichzeitige Anfragen 

Volumentest: große Datenmengen 

Sicherheitstests: Sicherheitslücken aufspüren 

Zeitvorgabentests: werden spezifizierte Antwortzeiten eingehalten? 

Erholungstests: Tests auf Erholung von fehlerhaften Zuständen 



Zusammenfassung der Testarten 


Black−Box−Test 

Grenztest zustands− 

basierter Test 

Äquivalenztest 

White−Box−Test 

Pfadtest 


Strategie: 

− Urknall 

− Top−Down 

− Bottom−Up 

− Sandwich 

Härtetest 

Leistungstest 

Systemtest 

Funktionstest Feldtest Installationstest 

Volumentest 

Sicherheitstest 

Akzeptanztest 

Erholungstest 

Zeitvorgabentest 



Testdokumentation: Aufzeichnung der Testaktivitäten 

Testplan: Projektplan fürs Testen 

Testfallspezifikation: Dokumentation eines jeden Testfalls 

Testvorfallbericht (Testprotokoll): Ergebnisse des Tests und 

Unterschiede zu erwarteten Ergebnissen 

Testübersicht: Auflistung aller Fehler (entdeckt und noch zu 

untersuchen) 

→ Analyse und Priorisierung aller Fehler und deren Korrekturen 

Testplan und Testfallspezifikation können sehr früh schon erstellt werden. 



Testplan (IEEE Std. 829-1998 1998) 


2. Beziehung zu anderen Dokumenten 

3. Systemüberblick 

4. Merkmale, die getestet/nicht getestet werden müssen 

5. Abnahmekriterien 

6. Vorgehensweise 

7. Aufhebung und Wiederaufnahme 

8. Zu prüfendes Material (Hardware-/Softwareanforderungen) 

9. Testfälle 

10. Testzeitplan: Verantwortlichkeiten, Personalausstattung und 

Weiterbildungsbelange, Risiken und Schadensmöglichkeiten, Zeitplan 


2009-02-09 



Testplan 




2. Beziehung zu anderen Dokumenten 

3. Systemüberblick 

4. Merkmale, die getestet/nicht getestet werden müssen 

5. Abnahmekriterien 

6. Vorgehensweise 

7. Aufhebung und Wiederaufnahme 

8. Zu prüfendes Material (Hardware-/Softwareanforderungen) 

9. Testfälle 

10. Testzeitplan: Verantwortlichkeiten, Personalausstattung und 

Weiterbildungsbelange, Risiken und Schadensmöglichkeiten, Zeitplan 

(Entspricht einer vereinfachten Variante von IEEE Std. 829-1998 (1998).) 

2.: Beziehung zu Anforderungsspezifikation und Architekturbeschreibung; Einführung von Namenskonventionen, um 

Tests und Anforderungen/Architektur in Beziehung zu setzen. 

3.: Überblick über System hinsichtlich jener Komponenten, die durch Komponententests geprüft werden sollen. 

Granularität der Komponenten und ihre Abhängigkeiten. 

4.: Konzentration auf funktionale Gesichtspunkte beim Testen; identifiziert alle merkmale und Kombinationen von 

Merkmalen, die getestet werden müssen. Beschreibt auch diejenigen Merkmale, die nicht getestet werden und gibt 

Gründe dafür an. 

5.: Spezifiziert Abnahmekriterien für die Tests (z.B. Testabdeckung). 

6.: Allgemeine Vorgehensweisen beim Testablauf; Integrationsstrategien. 

7.: Kriterien, wann Testaktivitäten ausgesetzt werden. Testaktivitäten, die wiederholt werden müssen, wenn das 

Testen wieder aufgenommen wird. 

8.: Notwendige Betriebsmittel: physikalische Eigenarten der Umgebung sowie Anforderungen an Software, 

Hardware, Testwerkzeuge und andere Betriebsmittel (z.B. Arbeitsraum). 

9.: (das Herzstück des Testplans) Auflistung aller Testfälle anhand individueller Testfallspezifikationen. 


Testfallspezifikation 

Testfallbezeichner: eindeutiger Name des Testfalls; am Besten 

Namenskonventionen benutzen 

Testobjekte: Komponenten (und deren Merkmale), die getestet 

werden sollen 

Eingabespezifikationen: erwartete Eingaben 

Ausgabespezifikationen: erwartete Ausgaben 

Umgebungserfordernisse: notwendige Software- und 

Hardware-Plattform sowie Testrümpfe und -stümpfe 

Besondere prozedurale Anforderungen: Einschränkungen wie 

Zeitvorgaben, Belastung oder Eingreifen durch den Operateur 

Abhängigkeiten zwischen Testfällen 



Testschadensbericht 

welche Merkmale wurden getestet? 

wurden sie erfüllt? 

bei Störfällen: wie können sie reproduziert werden? 

→ Sammlung und Priorisierung in der Testübersicht 

→ Test = Fehlersuche bzw. -korrektur! 




Erläutern Sie die Unterschiede in den Fehlerbegriffen Störfall, 

fehlerhafter Zustand und Fehler. 

Was ist ein positiver, was ein negativer Testfall? 

Wer sollte testen? 

Welche Arten von Tests gibt es? 

Was ist ein Testfall? 

Welche Aufgabe erfüllen Teststümpfe und -treiber für den 

Komponententest? 

Was ist der Unterschied von Black- und Glass-Box-Tests? 

Welche Techniken des Komponententests gibt es? 

Erläutern Sie die Idee von 

Äquivalenztests am konkreten Beispiel. 

Erläutern Sie die Idee von Grenztests am konkreten Beispiel. 

Erläutern Sie die Idee von Pfadtests am konkreten Beispiel. 




Wie benutzt man JUnit für den Komponententest? 

Wozu benötigt man Polymorphismustests? 

Erläutern Sie die Idee von zustandsbasierten Tests am konkreten 

Beispiel. 

Welche Testabdeckungsmaße gibt es? 

Nennen Sie Strategien für Integrationstests und diskutieren Sie sie. 

Erläutern Sie Leistungstests. 

Was ist ein Testplan? 







Ablauf 

Zeitplan 

Anmeldung 




Kontaktdaten 

Ressourcen 

Lehrbücher 








Lernziele 

Feinentwurf eines Systems durchführen können 

Programmierrichtlinien entwerfen, kennen und einhalten 

Verständnis für Codequalität entwickeln 



Feinentwurf 

Der Feinentwurf ist die Brücke zwischen abstrakter Architektur und 

detailliertem Code. 

Er legt fest: 


→ Klassendiagramme mit zusätzlichen Implementierungsdetails; (z.B. 

Navigierbarkeit, Implementierung von Assoziationen, Behandlung von 

Mehrfachvererbung oder weiteren Implementierungsklassen etc.) 

Abläufe 

→ Zustandsautomaten 

→ Aktivitätsdiagramme 

→ Sequenzdiagramme 



Architekturkonformität 

Architekturbeschreibung und Quellcode sind zwei voneinander 

abhängige, aber separate Dokumente 

in der Weiterentwicklung werden oft Änderungen im Quellcode 

gemacht, die in der Architekturbeschreibung nicht nachgezogen 

werden 

Folge: Architekturbeschreibung wird obsolet 

Planung erfolgt aber meist auf Basis der Architekturbeschreibung 

Folge: böses Erwachen in der Umsetzung 

→ Reflektionsmethode von Murphy u. a. (1995, 2001) zur 

Synchronisation von Modulsicht und Quellcode 



Reflektionsmethode (Murphy u. a. 2001) 

1 Stelle Architekturmodell auf 

2 Extrahiere Implementierungsmodell 

3 Bilde Modelle aufeinander ab 

4 Berechne Reflektionsmodell 

5 Verfeinere/korrigiere 

Beispiel 

H1 

H2 


H3


Warum Programmierrichtlinien? 

bis zu 80% der Gesamtkosten für Software sind Wartungskosten 

Originalautor wartet Software oft nicht selbst 

Code muss lesbar und verständlich sein 



Programmierrichtlinien: Schlechte Beispiele 

// i n k o n s i s t e n t e Methodennamen 

T e x t F i e l d . s e t T e x t ( ) ; 

L a b e l . s e t T e x t ( ) ; 

Button . s e t L a b e l ( ) ; 

A b s t r a c t B u t t o n . s e t T e x t ( ) ; 

// i n k o n s i s t e n t e P a r a m e t e r s o r t i e r u n g 

S t r i n g B u f f e r . setCharAt ( i n t index , c h a r c ) ; 

Vector . s e t E l e m e n t A t ( Object o , i n t i n d e x ) ; 

L i s t . s e t ( i n t index , Object o ) ; 

// l e n g t h oder s i z e ? 

l e n O f A r r a y = myArray . l e n g t h ; 

l e n O f S t r i n g = myString . l e n g t h ( ) ; 

myList . s i z e ( ) ; 



Programmierrichtlinien: Sinnvolle Namen 

// S i n n l o s e Namen 

s t a t i c f i n a l i n t ONE = 1 ; 

s t a t i c f i n a l i n t TEN = 1 0 ; 

s t a t i c f i n a l i n t TWENTY = 3 0 ; 

// b e s s e r 

s t a t i c f i n a l i n t INPUT MODE = 1 ; 

s t a t i c f i n a l i n t INPUT BUFSIZE = 1 0 ; 

s t a t i c f i n a l i n t OUTPUT BUFSIZE = 3 0 ; 



Programmierrichtlinien: Lokale Variablen 

// Man kann ’ s auch ü b e r t r e i b e n . . . 

f o r ( i n t o u t e r I n d e x = 0 ; o u t e r I n d e x < maxOuterIndex ; 

o u t e r I n d e x++) 

{ 

f o r ( i n t i n n e r I n d e x = 0 ; i n n e r I n d e x < o u t e r I n d e x ; 

i n n e r I n d e x++) 

{ 

r e s u l t M a t r i x [ o u t e r I n d e x ] [ i n n e r I n d e x ] 

= o u t e r I n d e x ∗ i n n e r I n d e x ; 

} 

} 

// S c h l e i f e n v a r i a b l e n / I n d i z e s => k u r z e Namen 

f o r ( i n t i = 0 ; i < max ; i ++) 

{ 

f o r ( i n t j = 0 ; j 

{ 

r e s u l t [ i ] [ j ] = i ∗ j ; 

} 

} 



Ausdrücke in natürlicher Form 

// schwer v e r s t ä n d l i c h e r Ausdruck 

i f ( ! ( b l o c k I d < a c t b l k s ) | | ! ( b l o c k I d >= u n b l o c k s ) ) 

// b e s s e r 

i f ( ( b l o c k I d >= a c t b l k s ) | | ( b l o c k I d 



Magische Zahlen 

// Wer v e r s t e h t d i e s e Zahlen ? 

m = 60 ∗ h + em ; 

s = 60 ∗ m + e s ; 

t c = 60 ∗ b + l c ; 

// So i s t ’ s b e s s e r . 

s t a t i c f i n a l s h o r t MINUTES PER HOUR = 6 0 ; 

s t a t i c f i n a l s h o r t SECONDS PER MINUTE = 6 0 ; 

s t a t i c f i n a l s h o r t CLIPS PER BOX = 6 0 ; 

. 

. 

. 

minutes = MINUTES PER HOUR ∗ h o u r s + e x t r a M i n u t e s ; 

s e c o n d s = SECONDS PER MINUTE ∗ minutes + e x t r a S e c o n d s ; 

t o t a l C l i p s = CLIPS PER BOX ∗ boxes + l o o s e C l i p s ; 



Hartcodiert: String-Literale im Code 

t r y 

{ 

s t o r e . o p e n S t o r e ( ” . / c o n f i g . xml ” , ”PSA” ) ; 

manager . r e a d C o n f i g u r a t i o n ( s t o r e ) ; 

} 

c a t c h ( T r e e S t o r e E x c e p t i o n e ) 

{ 

System . e r r . p r i n t l n 

( ” Konnte K o n f i g u r a t i o n s d a t e i n i c h t l e s e n . ” ) ; 

} 

c a t c h ( C o n f i g E x c e p t i o n x ) 

{ 

System . e r r . p r i n t l n 

( ” F e h l e r beim A u s l e s e n d e r K o n f i g u r a t i o n s d a t e i . ” ) ; 

} 



Character sind zwar Zahlen, aber... 

// Wie b i t t e ? 

i f ( ( c >= 65) && ( c = ’A ’ ) && ( c


Sprachkonstrukte zur Berechnung von Größen 

// Doppelte Z a h l e n r e f e r e n z 

c h a r buf [ ] = new c h a r [ 1 0 2 4 ] ; 

f o r ( i n t i = 0 ; i < 1024; i ++) 

// Sprachmechanismus nutzen ! 

c h a r buf [ ] = new c h a r [ 1 0 2 4 ] ; 

f o r ( i n t i = 0 ; i < buf . l e n g t h ; i ++) 



Überflüssige Kommentare 

/∗ 

∗ d e f a u l t 

∗/ 

d e f a u l t : 

break ; 

/∗ r e t u r n SUCCESS ∗/ 

r e t u r n SUCCESS ; 

zeroCount++: /∗ I n c r e m e n t z e r o e n t r y c o u n t e r ∗/ 

/∗ I n i t i a l i z e t o t a l to numberReceived . ∗/ 

Node . t o t a l = Node . numberReceived ; 



Überflüssige Kommentare 

w h i l e ( ( ( c = getChar ( ) ) != EOF) && ( i s S p a c e ( c ) ) ) 

; /∗ s k i p w h i t e s p a c e ∗/ 

i f ( c == EOF) /∗ end o f f i l e ∗/ 

t y p e = END OF FILE ; 

e l s e i f ( c == ’ ( ’ ) /∗ l e f t paren ∗/ 

t y p e = LEFT PAREN ; 

e l s e i f ( c == ’ ) ’ ) /∗ r i g h t paren ∗/ 

t y p e = RIGHT PAREN ; 

e l s e i f ( c == ’ ; ’ ) /∗ s e m i c o l o n ∗/ 

t y p e = SEMICOLON ; 

e l s e i f ( isOp ( c ) ) /∗ o p e r a t o r ∗/ 

t y p e = OPERATOR; 

e l s e i f ( i s D i g i t ( c ) ) /∗ number ∗/ 

t y p e = NUMBER; 

. . . 



Verschluckte (hicks) Exceptions 

t r y 

{ 

F i l e O u t p u t S t r e a m out = new F i l e O u t p u t S t r e a m ( strName ) ; 

. . . 

out . f l u s h ( ) ; 

out . c l o s e ( ) ; 

} 

c a t c h ( I O E x c e p t i o n e ) 

{ ; 

} 



idKldW 

i n t f ( i n t f [ ] , i n t l , Item k ) 

{ i n t i ; 

f o r ( i =0; i < l ; i ++) 

i f ( f [ i ] == k ) r e t u r n i ; 

} 

In der Kürze liegt die Würze (idKldW)? 

i n t I n d e x ( i n t ∗ f i e l d , i n t l e n g t h , Item key ) 

{ i n t i ; 

f o r ( i =0; i < l e n g t h ; i ++) 

i f ( f i e l d [ i ] == key ) r e t u r n i ; 

} 



Software-Redundanz 

... 

for (i = 1; i < MAX; i++) { 

... 

x = func() * y + x; 

} for (i = 1; i < MAX; i++) { 

x = func() * y + x; 

... 

} 

for (j = 1; j < MAX; j++) { 

x = func() * y + x; 

} 

... 

foo.c bar.c fred.c 

Typisch: 5 – 30 % des Codes sind redundant. . . 

... 

... 

for (i = 1; i < MAX; i++) { 

x1 = func() * y1 + x1; 

} 

... 

for (i = 1; i < MAX; i++) { 

x2 = func() * y2 + x2; 

} 


...


Software-Redundanz 

... 

... 

... 

foo.c bar.c fred.c 

set_coordinate (&x, y); 


void set_coordinate ( 

float *x, float y) { 

} 

... 

... 

int i; 

. . . und können abstrahiert werden 


for (i = 1; i < MAX; i++) { 

*x = func() * y + *x; 

} 

... 

set_coordinate (&x1, y1); 

... 

set_coordinate (&x2, y2); 




...


Überlange Methoden 

Gedruckt von Rainer Koschke 

Mai 31, 05 7:18 b.cpp 

Seite 1/12 

// 

// java provides a variety of conditional branch instructions, so 

// that a number of operators merit special handling: 

// constant operand 

5 // negation (we eliminate it) 

// equality 

// ?: && and || (partial evaluation) 

// comparisons 

// Other expressions are just evaluated and the appropriate 

10 // branch emitted. 

// 

// TODO: return a bool that is true if the statement being branched over is 

// even needed (if statements and other places might have a constant false 

// expression, allowing the next block of code to be skipped entirely). 

15 // 

void ByteCode::EmitBranchIfExpression(AstExpression* p, bool cond, Label& lab, 

AstStatement* over) 

{ 

p = StripNops(p); 

20 assert(p −> Type() == control.boolean_type); 

if (p −> IsConstant()) 

{ 

if (IsZero(p) != cond) 

25 EmitBranch(OP_GOTO, lab, over); 

return; 

} 

AstPreUnaryExpression* pre = p −> PreUnaryExpressionCast(); 

30 if (pre) // must be ! 

{ 

// 

// branch_if(!e,c,l) => branch_if(e,!c,l) 

// 

35 assert(pre −> Tag() == AstPreUnaryExpression::NOT); 

EmitBranchIfExpression(pre −> expression, ! cond, lab, over); 

return; 

} 

40 AstConditionalExpression* conditional = p −> ConditionalExpressionCast(); 

if (conditional) 

{ 

if (conditional −> test_expression −> IsConstant()) 

{ 

45 // 

// branch_if(true?a:b, cond, lab) => branch_if(a, cond, lab); 

// branch_if(false?a:b, cond, lab) => branch_if(b, cond, lab); 

// 

EmitBranchIfExpression((IsZero(conditional −> test_expression) 

50 ? conditional −> false_expression 

: conditional −> true_expression), 

cond, lab, over); 

} 

else if (IsOne(conditional −> true_expression)) 

55 { 

// 

// branch_if(expr?true:true, c, l) => expr, branch if c 

// branch_if(expr?true:false, c, l) => branch_if(expr, c, l); 

// branch_if(expr?true:b, c, l) => branch_if(expr || b, c, l); 

60 // 

if (IsOne(conditional −> false_expression)) 

{ 

EmitExpression(conditional −> test_expression, false); 

if (cond) 

65 EmitBranch(OP_GOTO, lab, over); 

} 

else if (IsZero(conditional −> false_expression)) 

{ 

EmitBranchIfExpression(conditional −> test_expression, 

70 cond, lab, over); 

Dienstag Mai 31, 2005 1/12 


Mai 31, 05 7:18 b.cpp 

Seite 3/12 

EmitBranchIfExpression(conditional −> test_expression, false, 

skip, over); 

EmitBranchIfExpression(conditional −> true_expression, false, 

lab, over); 

145 DefineLabel(skip); 

CompleteLabel(skip); 

} 

} 


150 { 

// 

// branch_if(expr?a:false, c, l) => branch_if(expr && a, c, l); 

// 

if (! cond) 

155 { 


lab, over); 

EmitBranchIfExpression(conditional −> true_expression, false, 

lab, over); 

160 } 

else 

{ 

Label skip; 


165 skip, over); 

EmitBranchIfExpression(conditional −> true_expression, true, 

lab, over); 

DefineLabel(skip); 


170 } 

} 

else 

{ 

// 

175 // branch_if(expr?a:b, c, l) => 

// branch_if(expr, false, lab1) 

// branch_if(a, c, l) 

// goto lab2 

// lab1: branch_if(b, c, l) 

180 // lab2: 

// 

Label lab1, lab2; 

EmitBranchIfExpression(conditional −> test_expression, false, lab1, 

over); 

185 EmitBranchIfExpression(conditional −> true_expression, cond, lab, 

over); 

EmitBranch(OP_GOTO, lab2, over); 

DefineLabel(lab1); 

CompleteLabel(lab1); 

190 EmitBranchIfExpression(conditional −> false_expression, cond, lab, 

over); 

DefineLabel(lab2); 

CompleteLabel(lab2); 

} 

195 return; 

} 

AstInstanceofExpression* instanceof = p −> InstanceofExpressionCast(); 

if (instanceof) 

200 { 

AstExpression* expr = StripNops(instanceof −> expression); 

TypeSymbol* left_type = expr −> Type(); 

TypeSymbol* right_type = instanceof −> type −> symbol; 

if (right_type −> num_dimensions > 255) 

205 { 

semantic.ReportSemError(SemanticError::ARRAY_OVERFLOW, 

instanceof −> type); 

} 

if (left_type == control.null_type) 

210 { 



Mai 31, 05 7:18 b.cpp 

Seite 2/12 

} 

else if (cond) 

{ 

EmitBranchIfExpression(conditional −> test_expression, true, 

75 lab, over); 

EmitBranchIfExpression(conditional −> false_expression, true, 

lab, over); 

} 

else 

80 { 

Label skip; 


skip, over); 

EmitBranchIfExpression(conditional −> false_expression, false, 

85 lab, over); 



} 

} 

90 else if (IsZero(conditional −> true_expression)) 

{ 

// 

// branch_if(expr?false:true, c, l) => branch_if(expr, ! c, l); 

// branch_if(expr?false:false, c, l) => expr, branch if ! c 

95 // branch_if(expr?false:b, c, l) => branch_if(!expr && b, c, l); 

// 

if (IsOne(conditional −> false_expression)) 

{ 

EmitBranchIfExpression(conditional −> test_expression, 

100 ! cond, lab, over); 

} 


{ 

EmitExpression(conditional −> test_expression, false); 

105 if (! cond) 

EmitBranch(OP_GOTO, lab, over); 

} 

else if (! cond) 

{ 

110 EmitBranchIfExpression(conditional −> test_expression, true, 

lab, over); 

EmitBranchIfExpression(conditional −> false_expression, false, 

lab, over); 

} 

115 else 

{ 

Label skip; 


skip, over); 

120 EmitBranchIfExpression(conditional −> false_expression, true, 

lab, over); 



} 

125 } 

else if (IsOne(conditional −> false_expression)) 

{ 

// 

// branch_if(expr?a:true, c, l) => branch_if(!expr || a, c, l); 

130 // 

if (cond) 

{ 


lab, over); 

135 EmitBranchIfExpression(conditional −> true_expression, true, 

lab, over); 

} 

else 

{ 

140 Label skip; 

2/12 Dienstag Mai 31, 2005 


Mai 31, 05 7:18 b.cpp 

Seite 4/12 

// 

// We know the result: false. But emit the left expression, 

// in case of side effects in (expr ? null : null). 

// 

215 EmitExpression(expr, false); 

if (! cond) 


} 

else if (expr −> IsConstant() || // a String constant 

220 expr −> BinaryExpressionCast()) // a String concat 

{ 

// 

// We know the result: true, since the expression is non−null 

// and String is a final class. 

225 // 

assert(left_type == control.String()); 

EmitExpression(expr, false); 

if (cond) 


230 } 

else if ((expr −> ThisExpressionCast() || 

expr −> SuperExpressionCast() || 

expr −> ClassLiteralCast() || 

expr −> ClassCreationExpressionCast() || 

235 expr −> ArrayCreationExpressionCast()) && 

left_type −> IsSubtype(right_type)) 

{ 

// 

// We know the result: true, since the expression is non−null. 

240 // 

EmitExpression(expr, false); 

if (cond) 


} 

245 else 

{ 

EmitExpression(expr); 

PutOp(OP_INSTANCEOF); 

PutU2(RegisterClass(right_type)); 

250 EmitBranch((cond ? OP_IFNE : OP_IFEQ), lab, over); 

} 

return; 

} 

255 // 

// dispose of non−binary expression case by just evaluating 

// operand and emitting appropiate test. 

// 

AstBinaryExpression* bp = p −> BinaryExpressionCast(); 

260 if (! bp) 

{ 

EmitExpression(p); 

EmitBranch((cond ? OP_IFNE : OP_IFEQ), lab, over); 

return; 

265 } 

// 

// Here if binary expression, so extract operands 

// 

270 AstExpression* left = StripNops(bp −> left_expression); 

AstExpression* right = StripNops(bp −> right_expression); 

TypeSymbol* left_type = left −> Type(); 

TypeSymbol* right_type = right −> Type(); 

275 switch (bp −> Tag()) 

{ 

case AstBinaryExpression::AND_AND: 

// 

// branch_if(true&&b, cond, lab) => branch_if(b, cond, lab); 

280 // branch_if(false&&b, cond, lab) => branch_if(false, cond, lab); 



Mai 31, 05 7:18 b.cpp 

Seite 7/12 

420 // 

if (control.IsSimpleIntegerValueType(left_type) || 

left_type == control.boolean_type) 

{ 

assert(control.IsSimpleIntegerValueType(right_type) || 

425 right_type == control.boolean_type); 

if (IsZero(left) || IsZero(right)) 

{ 

if (left_type == control.boolean_type) 

430 { 

// 

// One of the operands is false. Branch on the other. 

// 

EmitBranchIfExpression(IsZero(left) ? right : left, 

435 cond == (bp −> Tag() != AstBinaryExpr 

ession::EQUAL_EQUAL), 

lab, over); 

} 

else 

{ 

440 // 

// One of the operands is zero. Only emit the other. 

// 

EmitExpression(IsZero(left) ? right : left); 

445 if (bp −> Tag() == AstBinaryExpression::EQUAL_EQUAL) 

EmitBranch((cond ? OP_IFEQ : OP_IFNE), lab, over); 

else EmitBranch((cond ? OP_IFNE : OP_IFEQ), lab, over); 

} 

} 

450 else 

{ 

EmitExpression(left); 

EmitExpression(right); 

455 if (bp −> Tag() == AstBinaryExpression::EQUAL_EQUAL) 

EmitBranch((cond ? OP_IF_ICMPEQ : OP_IF_ICMPNE), lab, over); 

else 

EmitBranch((cond ? OP_IF_ICMPNE : OP_IF_ICMPEQ), lab, over); 

} 

460 

return; 

} 

// 

465 // Both operands are reference types: just do the comparison. 

// 

if (IsReferenceType(left_type)) 

{ 

assert(IsReferenceType(right_type)); 

470 EmitExpression(left); 


if (bp −> Tag() == AstBinaryExpression::EQUAL_EQUAL) 

EmitBranch((cond ? OP_IF_ACMPEQ : OP_IF_ACMPNE), lab, over); 

475 else EmitBranch((cond ? OP_IF_ACMPNE : OP_IF_ACMPEQ), lab, over); 

return; 

} 

480 break; 

case AstBinaryExpression::IOR: 

// 

// One argument is false. Branch on other. 

// 

485 if (IsZero(left) || IsZero(right)) 

{ 

EmitBranchIfExpression(IsZero(left) ? right : left, 

cond, lab, over); 



Mai 31, 05 7:18 b.cpp 

Seite 9/12 

assert(left_type != control.boolean_type); 

560 if (control.IsSimpleIntegerValueType(left_type)) 

{ 

// 

// we have already dealt with EQUAL_EQUAL and NOT_EQUAL for the case 

// of two integers, but still need to look for comparisons for which 

565 // one operand may be zero. 

// 

if (IsZero(left)) 

{ 



{ 

case AstBinaryExpression::LESS: 

// if (0 < x) same as if (x > 0) 

op_true = OP_IFGT; 

575 op_false = OP_IFLE; 

break; 

case AstBinaryExpression::LESS_EQUAL: 

// if (0 = 0) 

op_true = OP_IFGE; 

580 op_false = OP_IFLT; 

break; 

case AstBinaryExpression::GREATER: 

// if (0 > x) same as if (x < 0) 

op_true = OP_IFLT; 

585 op_false = OP_IFGE; 

break; 

case AstBinaryExpression::GREATER_EQUAL: 

// if (0 >= x) same as if (x Tag()) 

{ 




break; 


op_true = OP_IFLE; 

op_false = OP_IFGT; 

610 break; 



op_false = OP_IFLE; 

break; 

615 case AstBinaryExpression::GREATER_EQUAL: 


op_false = OP_IFLT; 

break; 

default: 

620 assert(false); 

break; 

} 

} 

else 

625 { 





Mai 31, 05 7:18 b.cpp 

Seite 8/12 

return; 

490 } 

// 

// One argument is true. Emit the other, and result is true. 

// 

495 if (IsOne(left) || IsOne(right)) 

{ 

EmitExpression(IsOne(left) ? right : left, false); 

if (cond) 


500 return; 

} 

break; 

case AstBinaryExpression::AND: 

// 

505 // One argument is true. Branch on other. 

// 

if (IsOne(left) || IsOne(right)) 

{ 

EmitBranchIfExpression(IsOne(left) ? right : left, 

510 cond, lab, over); 

return; 

} 

// 

515 // One argument is false. Emit the other, and result is false. 

// 

if (IsZero(left) || IsZero(right)) 

{ 

EmitExpression(IsZero(left) ? right : left, false); 

520 if (! cond) 


return; 

} 

break; 

525 default: 

break; 

} 

// 

530 // here if not comparison, comparison for non−integral numeric types, or 

// integral comparison for which no special casing needed. 

// Begin by dealing with non−comparisons 

// 

switch (bp −> Tag()) 

535 { 





540 case AstBinaryExpression::EQUAL_EQUAL: 

case AstBinaryExpression::NOT_EQUAL: 

break; // break to continue comparison processing 

default: 

// 

545 // not a comparison, get the (necessarily boolean) value 

// of the expression and branch on the result 

// 

EmitExpression(p); 

EmitBranch(cond ? OP_IFNE : OP_IFEQ, lab, over); 

550 return; 

} 

// 

// 

555 // 

Opcode opcode = OP_NOP, 

op_true, 

op_false; 



Mai 31, 05 7:18 b.cpp 

Seite 10/12 


630 { 


op_true = OP_IF_ICMPLT; 

op_false = OP_IF_ICMPGE; 

break; 

635 case AstBinaryExpression::LESS_EQUAL: 

op_true = OP_IF_ICMPLE; 

op_false = OP_IF_ICMPGT; 

break; 


640 op_true = OP_IF_ICMPGT; 

op_false = OP_IF_ICMPLE; 

break; 


op_true = OP_IF_ICMPGE; 

645 op_false = OP_IF_ICMPLT; 

break; 

default: 

assert(false); 

break; 

650 } 

} 

} 

else if (left_type == control.long_type) 

{ 

655 EmitExpression(left); 


opcode = OP_LCMP; 

660 // 

// branch according to result value on stack 

// 


{ 


op_true = OP_IFEQ; 

op_false = OP_IFNE; 

break; 


670 op_true = OP_IFNE; 

op_false = OP_IFEQ; 

break; 




break; 




680 break; 




break; 

685 case AstBinaryExpression::GREATER_EQUAL: 



break; 

default: 

690 assert(false); 

break; 

} 

} 

else if (left_type == control.float_type) 

695 { 



10/12 Dienstag Mai 31, 2005 





Mai 31, 05 7:18 b.cpp 

Seite 5/12 

Mai 31, 05 7:18 b.cpp 

Seite 6/12 

Mai 31, 05 7:18 b.cpp 

Seite 11/12 

Mai 31, 05 7:18 b.cpp 

Seite 12/12 

// 




if (left −> IsConstant()) 

} 

700 { 

770 op_false = OP_IFLT; 

{ 

} 

case AstBinaryExpression::EQUAL_EQUAL: 

break; 

if (IsOne(left)) 

// 

opcode = OP_FCMPL; 

default: 

285 EmitBranchIfExpression(right, cond, lab, over); 

355 // branch_if(a||b,true,lab) => 



else if (! cond) 

// branch_if(a,true,lab); 

op_false = OP_IFNE; 

break; 


// branch_if(b,true,lab); 

705 break; 

775 } 

} 

// branch_if(a||b,false,lab) => 


} 

// 

// branch_if(a,true,skip); 


else assert(false && "comparison of unsupported type"); 

290 // branch_if(a&&true, cond, lab) => branch_if(a, cond, lab); 

360 // branch_if(b,false,lab); 

op_true = OP_IFNE; 

// branch_if(a&&false, cond, lab) => emit(a), pop; for side effects 

// skip: 

op_false = OP_IFEQ; 

if (opcode != OP_NOP) 

// 

// 

710 break; 

780 PutOp(opcode); // if need to emit comparison before branch 

else if (right −> IsConstant()) 



{ 

{ 

opcode = OP_FCMPG; 

EmitBranch (cond ? op_true : op_false, lab, over); 

295 if (IsOne(right)) 

365 EmitBranchIfExpression(left, true, lab, over); 


} 

EmitBranchIfExpression(left, cond, lab, over); 

EmitBranchIfExpression(right, true, lab, over); 

op_false = OP_IFGE; 

else 

} 

715 break; 

{ 

else 


EmitExpression(left, false); 

{ 

opcode = OP_FCMPG; 

300 if (! cond) 




EmitBranchIfExpression(left, true, skip, over); 


} 

EmitBranchIfExpression(right, false, lab, over); 

720 break; 

} 



// 



305 // branch_if(a&&b, true, lab) => 

375 } 


// branch_if(a,false,skip); 

return; 


// branch_if(b,true,lab); 

case AstBinaryExpression::XOR: // ^ on booleans is equavalent to != 

725 break; 

// skip: 

assert(left_type == control.boolean_type); 


// branch_if(a&&b, false, lab) => 

// Fallthrough! 


310 // branch_if(a,false,lab); 



// branch_if(b,false,lab); 



// 

// 

730 break; 


// One of the operands is null. We must evaluate both operands, to get 

default: 

{ 

// any side effects in (expr ? null : null). 



385 // 

break; 

EmitBranchIfExpression(left, false, skip, over); 

if (left_type == control.null_type || right_type == control.null_type) 

} 

EmitBranchIfExpression(right, true, lab, over); 

{ 

735 } 


EmitExpression(left, left_type != control.null_type); 

else if (left_type == control.double_type) 


EmitExpression(right, right_type != control.null_type); 

{ 

320 } 

390 if (left_type == right_type) 


else 

{ 


{ 

if (cond == (bp −> Tag() == AstBinaryExpression::EQUAL_EQUAL)) 


EmitBranchIfExpression(left, false, lab, over); 

{ 

{ 

EmitBranchIfExpression(right, false, lab, over); 


case AstBinaryExpression::EQUAL_EQUAL: 

325 } 

395 } 

opcode = OP_DCMPL; 

return; 

} 


case AstBinaryExpression::OR_OR: 

else 

745 op_false = OP_IFNE; 

// 

{ 

break; 

// branch_if(false||b, cond, lab) => branch_if(b, cond, lab); 

if (bp −> Tag() == AstBinaryExpression::EQUAL_EQUAL) 


330 // branch_if(true||b, cond, lab) => branch_if(true, cond, lab); 

400 EmitBranch(cond ? OP_IFNULL : OP_IFNONNULL, lab, over); 


// 

else EmitBranch(cond ? OP_IFNONNULL : OP_IFNULL, lab, over); 

op_true = OP_IFNE; 

if (left −> IsConstant()) 

} 

750 op_false = OP_IFEQ; 

{ 

return; 

break; 

if (IsZero(left)) 

} 


335 EmitBranchIfExpression(right, cond, lab, over); 

405 

opcode = OP_DCMPG; 


// 



// One of the operands is true. Branch on the other. 


} 

// 

break; 

// 

if (left_type == control.boolean_type && 


340 // branch_if(a||false, cond, lab) => branch_if(a, cond, lab); 

410 (IsOne(left) || IsOne(right))) 

opcode = OP_DCMPG; 

// branch_if(a||true, cond, lab) => emit(a), pop; for side effects 

{ 


// 

EmitBranchIfExpression(IsOne(left) ? right : left, 

760 op_false = OP_IFGT; 

else if (right −> IsConstant()) 

cond == (bp −> Tag() == AstBinaryExpression:: 

break; 

{ 

EQUAL_EQUAL), 


345 if (IsZero(right)) 

lab, over); 


EmitBranchIfExpression(left, cond, lab, over); 

415 return; 


else 

} 

765 op_false = OP_IFLE; 

{ 

break; 

EmitExpression(left, false); 

// 


350 if (cond) 

// Both operands are integer. 




Dienstag Mai 31, 2005 11/12 

12/12 Dienstag Mai 31, 2005 



Ignoranz, Not-Invented-Here-Syndrom oder die 

neuerfundenen Räder 

p u b l i c c l a s s A r t i c l e s { 

p r i v a t e A r t i c l e item ; 

p r i v a t e A r t i c l e s n e x t ; 

} 

p u b l i c A r t i c l e s ( ) { . . . } 

p u b l i c v o i d Add ( A r t i c l e a r t ) { . . . } 

p u b l i c v o i d Show ( ) { . . . } 


p r i v a t e j a v a . u t i l . L i n k e d L i s t a r t i c l e s ; 

} 


p u b l i c v o i d Add ( A r t i c l e a r t ) { . . . } 

p u b l i c v o i d Show ( ) { . . . } 



Die Oglala des 21. Jahrhunderts 


p r i v a t e j a v a . u t i l . L i n k e d L i s t a r t i c l e s ; 

} 


p u b l i c v o i d Add ( A r t i c l e a r t ) { a r t i c l e s . addLast ( a r t ) ; } 

p u b l i c v o i d Show ( ) { 

L i s t I t e r a t o r l i s t I t r = a r t i c l e s . l i s t I t e r a t o r ( ) ; 

w h i l e ( l i s t I t r . hasNext ( ) ) { 

A r t i c l e a r t = ( A r t i c l e ) l i s t I t r . n e x t ( ) ; 

a r t . show ( ) ; 

} 

} 

Oglala (bedeutet: ” Die ihre Habe verschleudern“ im Sinne von 

Großzügigkeit) sind ein Stamm der Lakota-Sioux-Indianer. 



Prinzipien 

einheitlich 

so einfach wie möglich 

sprechend, direkt verständlich 

prägnant 

frei von Redundanz 

übersichtlich 

strukturiert 

abgeschlossen 

abstrakt 

Separation of Concerns 



Was alles in den Code-Inspektionen 2004/05 auffiel 

Verwendung von verketteten Listen, wo Maps angebracht wären; 

manuelle Implementierung der entsprechenden Map-Zugriffe 

Verwendung von verketteten Listen, wo ArrayList angebrachter wäre; 

z.B. Iterieren durch die LinkedList über Indexzugriffe... 

alle Methoden einer Klasse static; die statischen Variablen werden 

über den Konstruktor initialisiert 

alle Methoden einer Klasse static, die Instanz, auf der die Methoden 

arbeiten, werden z.B. als LinkedList jeweils übergeben 

Neuimplementierung von Sortieralgorithmen 

die gesamte GUI wird in einer einzigen Klasse implementiert 

Datenbankzugriffe werden über alle Klassen verteilt, statt gekapselt 



Was alles in den Code-Inspektionen 2004/05 auffiel 

Query wird mit select * gemacht, danach werden manuell die 

benötigten Spalten rausgefiltert 

Datenbanknamen usw. werden hartcodiert 

manuelle Implementierung von Parsern für verschiedene Zwecke (wo 

z.B. XML oder Properties-Datei angebracht wäre) 

mehrfache Implementierung der gleichen Hilfsklassen von 

verschiedenen Leuten, z.B. Übersetzungen (dementsprechend auch 

mit verschiedenen Dateiformaten) 

keine Berücksichtigung von Performance (z.B. bei Operationen auf 

verketteter Liste, Dateioperationen; Konfigurationsdatei wird bei 

jedem Methodenaufruf neu eingelesen) 




Was sind Refactorings und Bad Smells? 

Wie wird Refactoring durchgeführt? 

Nennen Sie Beispiele für Bad Smells. 


Benutzerdokumentation 





Ablauf 

Zeitplan 

Anmeldung 




Kontaktdaten 

Ressourcen 

Lehrbücher 








Lernziele 

Eine Benutzerdokumentation erstellen können 

wissen, was hinein gehört 

Arten kennen 

ihre Qualitäten kennen 

Prozess ihrer Erstellung kennen 



Was ist Benutzerdokumentation? 

Definition (Benutzerdokumentation) 

ist eine Methode, technische Information einer Software an Nichttechniker 

zu vermitteln, um sie in ihrer Aufgabe zu unterstützen. 



Ist eine Methode. . . zu vermitteln. . . 

Es ist nur eine Methode unter vielen: 

Schulungen 

Seminare 

Coaching 

Versuch-und-Irrtum 

Selbsterklärungsfähigkeit der Software 

Hotline (Help-Desk) 



. . . Nichttechnikern . . . 

Benutzer sind keine Software-Experten und wollen auch keine werden. 

Sie wollen das wissen, was Sie für Ihre Aufgabe benötigen und nicht mehr. 



. . . um sie in ihrer Aufgabe zu unterstützen. . . 

Ihre Aufgabe ist es nicht, Software zu bedienen, sondern ein reales 

Problem zu lösen. 



Arten der Dokumentation 


Referenzhandbuch 

Tutorial 

Administrationshandbuch 

Installationshandbuch 

Quick Start Guide 

Reference Card 

Wall Charts und Poster 

Online-Dokumentation (Multi-Media) 

Online-Kontexthilfe 

Readme.txt 

Known-Bugs 

. . . 



Arten und Leser der Dokumentation (Sommerville 2004) 

System 

evaluators 

Functional 

description 

Description 

of services 

provided 

System 

administrator 

Installation 

document 

How to 

install 

Novice 

users 

Introductory 

manual 

Getting 

started 

Experienced 

users 

Reference 

manual 

Details of all 

system 

facilities 

System 

adminstrator 

System 

admin. guide 

Operate 

and maintain 

system 



Wie findet man, was zu dokumentieren ist? 

Quellen: 

Kommandos und Menüs in der Benutzungsoberfläche 

Aufgaben der Benutzer (was sie tun) 

Definition von Begriffen (Glossar) 



Struktur I 

Titel 

Inhaltsverzeichnis 


a. Adressierte Leser 

b. Zweck 

c. Verwandte Dokumente 

d. Konventionen 

e. Information über die Verwendung des Dokuments 

f. Instruktionen für Problemberichte 

2. Übersicht 

a. Zugrunde liegende Konzepte, Einbettung 

b. Funktionale Beschreibung 

c. Gefahren und Warnungen 

3. Instruktionen (für jeden Benutzertyp einzeln) 

a. Produktfunktionen (mit Beispielen) 

b. Problembehandlung: Ursachen und Gründe 



Struktur II 

4. Referenz 

a. Fehlermeldungen und -ursachen 

b. Index der Operationen 

Anhang 

A Glossar 

B Index (notwendig für ≥ 30 Seiten, sonst mindestens nützlich) 



Scheibchen toter Bäume oder doch besser Elektrizität? 

Papier: 

” 150 Euro — und dafür nur eine CD?“ 

deutsches Gesetz schreibt Handbuch vor 

Papier ist die zuverlässigere und bedienbarere Technologie 

erschwert Software-Piraterie 

Online-Dokumentation: 

einfachere Suche 

Information kann in vielen Formaten verpackt werden 

interaktiv (z.B. Tool-Tips) 

niedrigere Produktionskosten 

→ beides, aber mindestens Papier 



Wer sollte schreiben? 

Programmierer technischer Schreiber 

Technische Detailkenntnisse + - 

Schreibqualitäten - + 

Anwenderbrille - + 



Wozu Dokumentation? 

Zwecke der Dokumentation: 

Erläuterung 

Definitionen, Beschreibungen, Erklärungen, Übersichten, 

Prozessbeschreibung 

Instruktion 

Produktfunktionen, Aufgaben 

Referenz 

Regelungen, Listen, Tabellen, spezifische Funktionen 



Wann werden Benutzer die Dokumentation benutzen? 

. . . wenn sie zuversichtlich sind, dass 

sie finden, was sie suchen 

sie verstehen, was sie finden 

die Information korrekt ist 

die Information vollständig ist 



Der Prozess, eine Dokumentation zu erstellen (Stimely 

1990) 

1 Definition 

2 Entwurf 

3 Schreiben 

4 Editieren 

5 Korrekturlesen 

6 Produktion 

7 Anpassung/Änderung 



1. Definition 

(5-10% der Gesamtzeit für Dokumentation) 

Erste Frage: Wer sind die Leser? 

Identifiziere den ” normalen“ Leser. Beschreibe, was Du über ihn weißt. 

Identifiziere die Annahmen über den Leser. 

Es könnte mehrere Kategorien von Lesern geben. Identifiziere sie alle. 

Beschreibe, was sie benötigen (Erläuterung, Instruktion, Referenz). 

Lege Gegenstände der Dokumentation (mit Namen) und Medien fest 



2. Entwurf 

(10-30% der Gesamtzeit für Dokumentation) 

Plane für jeden Gegenstand: 

Inhaltsverzeichnis 

Schätzung der Anzahl Seiten/Fenster 

Musterlayout 



3. Schreiben 

(1-3 Stunden pro Seite/Fenster) 

Erste Fassung so schnell wie möglich schreiben. Dabei nicht editieren. 

Schreibblockade überkommen durch 

Verbalisieren (z.B. einem Unbedarften erklären) 

Zerlegung eines komplexen Gegenstands in seine Einzelteile 

Brain-Dump 

Mind-Map 

Auszeit nehmen und ausruhen 

(temporär) aufgeben und zum nächsten Abschnitt übergehen 



4. Editing 

(1-3 Stunden pro Seite/Fenster) 

Iterative Verbesserung: 

Bedürfnisse des Lesers Grammatik 

Struktur Orthographie 

Relevanz Konsistenz 

Vollständigkeit Konformität 

ansprechende graphische Darstellung Ausdrucksweise 



5. Korrekturlesen 

(5-20 Minuten pro Seite/Fenster) 

Unabhängige Begutachtung von 

technischer Korrektheit 

Vollständigkeit 

Verwendbarkeit 

Einhaltung des Stils 

Rechtmäßigkeit 



6. Produktion 

(dauert immer länger als man denkt) 

Druck und Verteilung 

Herstellung der CD und Verteilung 

Publikation im Web 



7. Anpassung/ Änderung 

(benötigt Zeit – muss eingeplant werden) 

regelmäßige Überprüfung, um sicher zu stellen, dass Dokumentation 

aktuell bleibt 

Programmierer müssen Handbuch kennen! 

Dokumentation muss bei Analyse von Änderungsauswirkungen 

(Change-Impact) berücksichtigt werden 



Hinweise und Regeln 

erkläre das zu lösende Problem 

stelle die Konzepte dar, nicht nur die Produktfunktionen 

beschreibe auch Anwendungsdomäne, nicht nur die Software selbst 

die Lektüre soll Spaß machen 

schreibe zur Leserschaft, nicht über sie 

konsistentes (und eingeschränktes) Vokabular benutzen 



Hinweise und Regeln 

sei bestimmt 

fasse dich kurz (kurze Sätze, Paragraphen, Abschnitte) 

benutze einfache Sprache 

aktive statt passive Sprache 

erkläre den Zweck eines jeden Schritts 

sage, was in jedem Schritt passieren wird 

teste mit echten Benutzern 

kenne deinen Leser 

beachte Markenzeichen und Copyrights 




Auf welche Weisen können Benutzer die Bedienung von Software 

erlernen? 

Was ist Benutzerdokumentation? 

Nennen Sie Beispiele für Software-Dokumentationen. 

Wie sollte eine Benutzerdokumentation strukturiert werden? 

Wer sollte eine Benutzerdokumentation erstellen? 

Wie verläuft der Prozess, um eine Benutzerdokumentation zu 

erstellen? 


Antworten auf gesammelte Fragen im Wiki 





Ablauf 

Zeitplan 

Anmeldung 




Kontaktdaten 

Ressourcen 

Lehrbücher 









Übersicht über alle UML Diagramme: Welche gibt es alle und 

was ist ihr Verwendungsgebiet? (Keine Wiederholung über die 

Erstellung, Eigenschaften u.ä.) 




Anwendungsfalldiagramm 

→ Übersicht von Anwendungsfällen, Zusammenhang mit Akteuren, 

Beziehungen zwischen Anwendungsfällen 


→ statische Beziehungen zwischen Dingen: 

Daten- bzw. Domänenmodell 





Sequenzdiagramm 

→ Interaktionen zwischen Akteuren 

Interaktionen in Anwendungsfällen 

Interaktionen zwischen Komponenten der Architektur 

Programmablauf (Methoden und Klassen) 

Kollaborationsdiagramme 

→ äquivalent zu Sequenzdiagrammen 

→ heben Akteure und deren prinzipielle Interaktion hervor, Reihenfolge 

tritt in den Hintergrund 




Zustandsdiagramme 

→ zustandsbasiertes Verhalten, Reaktion auf Stimuli 

Modellierung von Anwendungsfällen mit Zuständen 

Objektlebenszyklus 

Protokolle in Architektur 

zustandsbasiertes Testen 


→ Abläufe: Aktionen und ihre Reihenfolge 

Modellierung von Geschäftsprozessen 


Spezifikation/Entwurf von Algorithmen 

Pfadtest 



Softwarearchitektur 

Außerdem aus gegebenem Anlass, zu den unterschiedlichen 

Blickwinkel des Architekturentwurfs. 

Konzeptionelle Sicht nach Hofmeister u. a. 2000: Data und 

Control Konnektoren, Unterschiede? (Wir haben z.B. bei jeder 

Verbindung beides benutzt...??) 

Alternative Modellierung der Konzeptionellen Sicht mit UML? 

Vielleicht ein kleines Beispiel? 

Die Unterschiede und Zusammenhänge zwischen System, 

Subsystem, Modul und Komponente nochmal erläutern 




* 

CComponent 

cbinding 

* 

* 

* 

CPort 



obeys 

1 

* 

CConnector 

0..1 0..1 0..1 * 0..1 

0..1 

0..1 

CRole 

* * 

obeys 

Protocol 

1 1 conjugate 

1 

* 

* 

cbinding 


* 

*


Konzeptionelle Sicht 

«Data» 

Text-Pipe 

Compiler 

«Component» 

FrontEnd 

«call» 

Producer 

«Data» 

AST-Pipe 

«Component» 

Main 

«call» 

«bind» «bind» 

«Component» 

MiddleEnd 

Consumer 

call ist ein Control-Konnektor; 

ein einfacher Aufruf 

«call» 

«bind» «bind» 

Producer 

«Data» 

IL-Pipe 

«Component» 

BackEnd 

Consumer 

«Data» 

Assembler-Pipe 




0..1 

Subsystem 

contain 

* 

Module 

0..1 

* 

* 

require 

provide 

* 

* 

* 

use 

* 

* 

Interface 

assigned−to 





* 

require 

* provide 

0..1 

* * 

Layer 

* 

* 0..1 

use 

* 

contain 



Modulsicht 

FrontEnd 

 

Programrepresentation 

GetToken 

Lexer SyntaxAnalysis SemanticAnalysis 

Open 

TextBuffer 

GetText 

Main 

Parse Decorate 

Create 

AST 

Lookup 

Annotate 

Traverse 

Run 

 

MiddleEnd 

ILGenerator 

Optimizer 

Run 

Generate 

IL 

ControlFlowAnalyzer 




* 

Communication 

Mechanism 

1 

* 

Communication 

Path 

* 

* 

* 

consume 

use mechanism 



Platform 

Platform 

Element 

* 1 * * 

is a 

* 

Runtime 

Entity 

2..* 

* 

consume 

* 

contain 

Platform 

Resource 

assigned to 

assigned to 

* 1 

* 

Traverse 

Hardware 

Resource 

Module 


Run


Ausführungssicht 

Processor1 

* 

Lexer 

TextBuffer 

Shared Memory 

1 

1 

Processor2 

Main SyntaxAnalysis 

AST 

SemanticAnalysis 

ILGenerator 

Optimizer 

ControlFlowAnalyzer 

IL 

 



Entwurfsmuster und Architekturstile 

die factory method an einem kleinen konkreten 

Implementierungsbeispiel darstellen 


1


Fahrradladenbeispiel: Erweiterung für andere Domänen 

Anforderungen: 

Artikeldaten sollen von einer Datei gelesen werden können 

zukünftig sollen andere Domänen unterstützt werden (Fahrrad, 

Computer und Klettern) 

die Objekte dieser Domänen sind unterschiedlich 

notwendige Anpassungen sollen einfach realisiert werden können 

Lösungsstrategien: 

die Klassen der Benutzungsschnittstelle beziehen sich nur auf die 

Schnittstelle der abstrakten Klasse Artikel 

Datei hat gleiche Syntax für alle Domänen (nur die Inhalte variieren) 

die Artikel werden beim Einlesen der Datei als Objekte erzeugt 

→ aber der Leser muss doch die Konstruktoren der Objekte kennen, oder 

was? 




GUI 

Artikel 

+ Preis() 

ComputerArtikel FahrradArtikel 

≪create≫ 

Rahmen 

Felge 

Leser 

+ lies(dateiname) 

≪create≫ ≪create≫ 

id=datei.liesId() 

s.FabrikMethode(id) 

FahrradSchöpfer 

ArtikelSchöpfer 

+ Artikel FabrikMethode(id) 


if (id == ”rahmen”) 

return new Rahmen 

if (id == ”felge”) 

return new Felge 

ComputerSchöpfer 




Artikelklassen 

p u b l i c a b s t r a c t c l a s s A r t i k e l { 

d o u b l e P r e i s ( ) { . . . } 

} 

p u b l i c a b s t r a c t c l a s s F a h r r a d A r t i k e l e x t e n d s A r t i k e l {. . . } 

p u b l i c c l a s s F e l g e e x t e n d s F a h r r a d A r t i k e l {. . . } 

p u b l i c c l a s s Rahmen e x t e n d s F a h r r a d A r t i k e l {. . . } 



Leser 

p u b l i c c l a s s L e s e r { 

} 

A r t i k e l S c h o e p f e r s c h o e p f e r ; 

L e s e r ( A r t i k e l S c h o e p f e r s c h o e p f e r ) { 

t h i s . s c h o e p f e r = s c h o e p f e r ; 

} 

p r i v a t e S t r i n g r e a d i d ( F i l e I n p u t S t r e a m i n ) {. . . } 



Leser (Forts.) 

p u b l i c v o i d l i e s ( S t r i n g dateiname ) throws j a v a . i o . I O E x c e p t i o n { 

F i l e I n p u t S t r e a m i n = new F i l e I n p u t S t r e a m ( dateiname ) ; 

S t r i n g i d ; 

A r t i k e l a r t i k e l ; 

w h i l e ( i n . a v a i l a b l e ( ) > 0) { 

i d = r e a d i d ( i n ) ; 

t r y { 

a r t i k e l = s c h o e p f e r . FabrikMethode ( i d ) ; 

} 

c a t c h ( A r t i k e l S c h o e p f e r . Unknown Id e ) { 

System . out . p r i n t ( ”unknown i d ” + i d ) ; 

// keep g o i n g 

} 

} 

i n . c l o s e ( ) ; 

} 



Schöpfer 

p u b l i c a b s t r a c t c l a s s A r t i k e l S c h o e p f e r { 

} 

p u b l i c c l a s s Unknown Id e x t e n d s E x c e p t i o n { } ; 

a b s t r a c t A r t i k e l FabrikMethode ( S t r i n g i d ) throws Unknown Id ; 

p u b l i c c l a s s F a h r r a d S c h o e p f e r e x t e n d s A r t i k e l S c h o e p f e r { 

} 

F a h r r a d A r t i k e l FabrikMethode ( S t r i n g i d ) throws Unknown Id { 

i f ( i d == ” rahmen ” ) r e t u r n new Rahmen ( ) ; 

e l s e i f ( i d == ” f e l g e ” ) r e t u r n new F e l g e ( ) ; 

throw new Unknown Id ( ) ; 

} 



Softwaretechnik im Allgemeinen 

kleiner Exkurs über agile Softwareentwicklung im Vergleich zum 

Wasserfallmodell 



Extreme Programming (Beck 2000) 

Wasserfallmodell — Extreme Programming — Code&Fix 

Extreme Programming (XP) ist eine agile Methode für 

kleinere bis größere Entwicklerteams (max. 10-15 Personen), 

Probleme mit vagen Anforderungen 

und Projekte, bei denen ein Kundenrepräsentant stets greifbar ist. 

http://www.extremeprogramming.org/ 



Extreme Programming (Beck 2000) 

Anerkannte Prinzipien und Praktiken werden ” extrem“ umgesetzt: 

Code-Reviews → permanente Reviews durch Pair-Programming 

Testen → ständiges Testen: Unit-Tests sowie Akzeptanztests durch 

den Kunden/Benutzer 

klare Struktur → jeder verbessert sie kontinuierlich durch Refactoring 

Einfachheit → stets die einfachste Struktur wählen, die die aktuellen 

Anforderungen erfüllt 

Integration → permanente Integration auch mehrmals am Tag 

Validierung: 

Kunde/Benutzer ist stets involviert bei der Planung neuer Iterationen 

und verantwortlich für Akzeptanztest 

kurze Iterationen → Dauer in Minuten und Stunden, nicht Wochen, 

Tage, Jahre 

aber auch Auslassung anerkannter Prinzipien: 

Dokumentation: mündliche Überlieferung, Tests und Quellcode 

Planung: sehr begrenzter Horizont 



Weitere XP-Charakteristika 

Kunde vor Ort 

eine Metapher statt einer Architekturbeschreibung 

40-Stundenwoche 

Code ist kollektives Eigentum 

Kodierungsstandards 



Agile versus weit voraus planende Prozessmodelle (Boehm 

und Turner 2003) 

Risiken agiler Methode: 

Skalierbarkeit, Kritikalität, Einfachheit des Entwurfs, 

Personalfluktuation, Personalfähigkeiten 

Risiken weit voraus planender Prozessmodelle: 

Stabilität der Anforderungen, steter Wandel, Notwendigkeit schneller 

Resultate, Personalfähigkeiten 

Generelle Risiken: 

Unsicherheiten bei der Technologie, unterschiedliche 

Interessengruppen, komplexe Systeme 


Das SWP-Lied 

Das SWP-Lied 




Ablauf 

Zeitplan 

Anmeldung 




Kontaktdaten 

Ressourcen 

Lehrbücher 







Das SWP-Lied 

SWP-Lied 

Melodie: Paul McCartney: ” Let it be“; Text: Jochen Quante 

Irgendwann im Informatik-Studium 

kommt was, was ich nicht versteh’: 

Software Engineering – SWP. 

Pflichtenheft, Entwurfsbeschreibung. . . 

Sowas braucht man doch wohl nie?! 

Wir soll’n all das schreiben – SWP. 

SWP, SWP, SWP, SWP. 

Koschke sagt: ” Des g’hört so“– SWP. 

Wir wollen lieber programmieren, 

Java hacken, schnell was dreh’n! 

Soviel Dokumente – SWP. 


Das SWP-Lied 

SWP-Lied (Forts.) 

Und wenn wir endlich starten dürfen, 

ist das Wissen ganz passé: 

Wie ging noch mal Java? – SWP. 


Was war noch mal Java? – SWP. 

Die Zeit wird knapp, die Nächte kürzer, 

manch einer fällt aus – oh je. 

Keine Zeit für’s Testen – SWP. 

Die Software wurde grad’ noch fertig, 

war’n wir doch zuviel am See? 

Dafür war die Planung – SWP. 


Dafür also Planung – SWP. 


Das SWP-Lied 

1 Balzert 1998 Balzert, Helmut: Lehrbuch der Software-Technik. 

Spektrum Akademischer Verlag, 1998. – derzeit nicht mehr verfügbar, 

wird neu aufgelegt. – ISBN 978-3827403018 

2 Bass u. a. 2003 Bass, Len ; Clements, Paul ; Kazman, Rick: 

Software Architecture in Practice. 2nd edition. Addison Wesley, 2003 

3 Beck 2000 Beck, Kent: Extreme Programming Explained. 

Addison-Wesley, 2000 (The XP Series). – ISBN 201-61641-6 

4 Berling und Runeson 2003 Berling, T. ; Runeson, P.: Evaluation 

of a perspective based review method applied in an industrial setting. 

In: IEE Proceedings 150 (2003), Juni, Nr. 3 

5 Boehm und Turner 2003 Boehm, B. ; Turner, R.: Using risk to 

balance agile and plan-driven methods. In: IEEE Computer 36 (2003), 

Juni, Nr. 6, S. 57–66 

6 Boehm 2000 Boehm, Barry: Project Termination Doesn’t Equal 

Project Failure. In: IEEE Computer (2000), September, S. 94–96 

Das SWP-Lied 


7 Brügge und Dutoit 2004 Brügge, Bernd ; Dutoit, Allen H.: 

Objektorientierte Softwaretechnik. Prentice Hall, 2004 

8 Buschermöhle u. a. 2006 Buschermöhle, Ralf ; Eekhoff, Heike ; 

Josko, Bernhard: Success – Erfolgs- und Misserfolgsfaktoren bei der 

Durchfuhrung von Hard- und Softwareentwicklungsprojekten in 

Deutschland. www.offis.de/umfragesuccess. 2006 

9 Buschmann u. a. 1996 Buschmann, Frank ; Meunier, Regine ; 

Rohnert, Hans ; Sommerlad, Peter ; Stal, Michael: 

Pattern-oriented Software Architecture: A System of Patterns. Bd. 1. 

Wiley, 1996 

10 Bush 1945 Bush, Vannevar: As We May Think. In: Atlantic Monthly 

(1945), Juli, S. 101 ff 

11 Clements u. a. 2002 Clements, Paul ; Bachmann, Felix ; Bass, 

Len ; Garlan, David ; Ivers, James ; Little, Reed ; Nord, 

Robert ; Stafford, Judith: Documenting Software Architecture. 

Boston : Addison-Wesley, 2002 


Das SWP-Lied 

12 EN ISO 9241-10:1995 1995 : Ergonomische Anforderungen für 

Bürotätigkeiten mit Bildschirmgeräten – Teil 10: Grundsätze der 

Dialoggestaltung. Europäische Norm, ISO-Standard. 1995 

13 Fjeldstadt und Hamlen 1984 Fjeldstadt ; Hamlen: Application 

Program Maintenance Study: Report to Our Respondents. In: Proc. 

GUIDE 48, IEEE Computer Society Press, April 1984 

14 Frühauf u. a. 2000 Frühauf ; Ludewig ; Sandmayr: 

Software-Prüfung. 4. Auflage. vdf Zürich, 2000 

15 Fusaro u. a. 1997 Fusaro, P. ; Lunibile, F. ; Visaggio, G.: A 

replicated experiment to assess requirements inspection techniques. In: 

Empirical Software Engineering 2 (1997), S. 39–57 

16 Gamma u. a. 2003 Gamma, Erich ; Helm, Richard ; Johnson, 

Ralph ; Vlissides, John: Desig Patterns—Elements of Reusable 

Object-Oriented Software. Addison Wesley, 2003 

17 Gilb 1988 Gilb, Tom: Principles of Software Engineering 

Management. Harlow, UK : Addison-Wesley, 1988 

Das SWP-Lied 


18 Harel 1987 Harel, David: State Charts: a Visual Formalism for 

Complex Systems. In: Science of Computer Programming 8 (1987), 

Nr. 3, S. 231–274 

19 Hayes 1997 Hayes, Frank: Managing User Expectations. In: 

Computerworld (1997), November 

20 Hayes 1999 Hayes, W.: Research synthesis in software engineering: a 

case for meta-analysis. In: Proc. 6th Int. Symp. on Software Metrics, 

IEEE Computer Society Press, November 1999, S. 143–151 

21 Hofmeister u. a. 2000 Hofmeister, Christine ; Nord, Robert ; 

Soni, Dilip: Applied Software Architecture. Addison Wesley, 2000 

(Object Technology Series) 

22 IEEE P1471 2002 : IEEE Recommended Practice for Architectural 

Description of Software-intensive Systems—Std. 1471-2000. ISBN 

0-7381-2518-0, IEEE, New York, NY, USA. 2002 

23 IEEE Standard 830.1998 1998 : IEEE Recommended Practice for 

Software Requirements Specifications, IEEE Standard 830.1998. 1998 


Das SWP-Lied 

24 IEEE-Std-1058 1987 : ANSI/IEEE Standard for Software Project 

Management Plans. ANSI/IEEE Std. 1058.1-1987. 1987 

25 IEEE Std 610.12-1990 1990 : IEEE Standard Glossary of Software 

Engineering Terminology. IEEE Standard 610.12-1990. 1990 

26 IEEE Std. 829-1998 1998 : IEEE Standard for Software Test 

Documentation. IEEE Standards Board, IEEE Std. 829-1998. 1998 

27 IEEE Std. 982-1989 1989 : IEEE Standard Guide for the Use of IEEE 

Standard Dictionary of Measures to Produce Reliable Software. IEEE 

Standards Board, IEEE Std. 982-1989. Juli 1989 

28 ISO 9241-11:1998 1998 : Ergonomic requirements for office work with 

visual display terminals (VDTs) – Part 11: Guidance on usability. 

ISO-Standard. 1998 

29 ISO/IEC-Standard 25000 2005 ISO/IEC 25000:2005 Software 

Engineering – Software product Quality Requirements and Evaluation 

(SQuaRE). 2005. – umgesetzt in DIN 66272 

30 ISO/IEC-Standard 9126 2001 ISO/IEC 9126-1:2001 Software 

engineering – Product quality. 2001. – umgesetzt in DIN 66272 


Das SWP-Lied 

31 Kano 1984 Kano, N.: Attractive Quality and Must-be Quality. In: 

Journal of the Japanese Society for Quality Control 4 (1984), S. 39–48 

32 Kazman u. a. 1996 Kazman, Rick ; Abowd, Gregory ; Bass, Len ; 

Clements, Paul: Scenario-Based Analysis of Software Architecture. In: 

IEEE Software (1996), November, S. 47–55 

33 Kruchten 1995 Kruchten, Phillipe: The 4+1 View Model of 

Architecture. In: IEEE Software 12 (1995), November, Nr. 6, S. 42–50 

34 Lehman und Belady 1985 Lehman, M. ; Belady, L.: Program 

Evolution: Processes of Software Change. London : Academic Press, 

1985 

35 Liskov 1988 Liskov, Barbara: Data Abstraction and Hierarchy. In: 

SIGPLAN Notices 23 (1988), Mai, Nr. 5 

36 Liskov und Wing 1994 Liskov, Barbara ; Wing, Jeanette M.: A 

Behavioral Notion of Subtyping. In: ACM Transactions on Programming 

Lnguages and Systems 16 (1994), Nr. 6, S. 1811–1841 

37 Ludewig 2003 Ludewig, Jochen: Einführung in die Softwaretechnik. 

Vorlesungs-Skriptum. 2003 


Das SWP-Lied 

38 Ludewig und Lichter 2006 Ludewig, Jochen ; Lichter, Horst: 

Software Engineering – Grundlagen, Menschen, Prozesse, Techniken. 

dpunkt.verlag, 2006 

39 Maaß 2001 Maaß, Susanne: Soziotechnische Systeme. 


40 McKee 1984 McKee, J.R.: Maintenance as a Function of Design. In: 

AFIPS National Computer Conference, Las Vegas (Ch. 27), 1984 

41 Miller u. a. 1998 Miller, J. ; Wood, M. ; Roper, M.: Further 

experiences with scenarios and checklists. In: Empirical Software 

Engineering 3 (1998), S. 37–64 

42 Murphy u. a. 1995 Murphy, Gail C. ; Notkin, David ; Sullivan, 

Kevin: Software Reflexion Models: Bridging the Gap Between Source 

and High-Level Models. In: Proc. of the Third ACM SIGSOFT 

Symposium on the Foundations of Software Engineering, 1995, S. 18–28 

Das SWP-Lied 


43 Murphy u. a. 2001 Murphy, Gail C. ; Notkin, David ; Sullivan, 

Kevin J.: Software Reflexion Models: Bridging the Gap between Design 

and Implementation. In: IEEE Transactions on Software Engineering 27 

(2001), April, Nr. 4, S. 364–380 

44 Neumann 1999 Neumann, Peter G.: Risks to the Public in 

Computers and Related Systems. In: ACM SIGSOFT Software 

Engineering Notes 24 (1999), Nr. 1, S. 31 

45 Object Management Group 2003 Object Management Group: 

OMG Unified Modeling Language Specification. March 2003. – Version 

1.5 

46 OMG Object Management Group (OMG): Unified Modeling 

Language. http://www.uml.org 

47 Parnas 1972 Parnas, David L.: On the Criteria to Be Used in 

Decomposing Systems into Modules. In: Communications of the ACM 

15 (1972), Dezember, Nr. 12 


Das SWP-Lied 

48 Partsch 1998 Partsch, H.: Requirements-Engineering systematisch - 

Modellierung für softwaregestützte Systeme. Berlin, Heidelberg, New 

York : Springer-Verlag, 1998 

49 Perry und Wolf 1992 Perry, Dewayne E. ; Wolf, Alexander L.: 

Foundations for the Study of Software. In: ACM SIGSOFT 17 (1992), 

Oktober, Nr. 4, S. 40–52 

50 Porter und Votta 1998 Porter, A. ; Votta, L.: Comparing 

detection methods for software requirements inspection: a replication 

using professional subjects. In: Empirical Software Engineering 3 (1998), 

S. 355–379 

51 Porter u. a. 1995 Porter, A. ; Votta, L. ; Basili, V.: Comparing 

detection methods for software requirements inspection: a replicated 

experiment. In: IEEE Transactions on Software Engineering 21 (1995), 

Nr. 5, S. 563–575 

52 Pressman 2003 Pressman, Roger: Software Engineering – A 

Practioner’s Approach. Fünfte Ausgabe. McGraw-Hill, 2003 


Das SWP-Lied 

53 Rödiger 2004 Rödiger, Karl-Heinz: Vortrag 

Rechtlicher Rahmen der Software-Entwicklung in der Vorlesung 

Software-Projekt. Vorlesungs-Skriptum. 2004 

54 Sandahl u. a. 1998 Sandahl, K. ; Blomkvist, O. ; Karlsson, J. ; 

Krysander, C. ; Lindvall, M. ; Ohlsson, N.: An extended 

replication of an experiment for assessing methods for software 

requirements inspections. In: Empirical Software Engineering 3 (1998), 

S. 327–354 

55 Sauer und Cuthbertson 2003 Sauer, C. ; Cuthbertson, C.: The 

State of IT Project Management in the UK. 

http://www.cw360ms.com/pmsurveyresults/surveyresults. 2003 

56 Shaw und Garlan 1996 Shaw, Mary ; Garlan, David: Software 

Architecture – Perspectives on an Emerging Discipline. Upper Saddle 

River, NJ : Prentice Hall, 1996. – ISBN ISBN 0-13-182957-2 

57 Shull u. a. 2000 Shull, Forrest ; Rus, Ioana ; Basili, Victor: How 

Perspective-Based Reading Can Improve Requirements Inspections. In: 

IEEE Computer 33 (2000), Nr. 7, S. 73–79 


Das SWP-Lied 

58 Sommerville 2004 Sommerville, Ian: Software Engineering. Siebte 

Ausgabe. Addison-Wesley, 2004 

59 Sowa und Zachman 1992 Sowa, J. F. ; Zachman, J. A.: Extending 

and formalising the framework for information systems architecture. In: 

IBM Systems Journal (1992) 

60 Standish Group 1994 

61 Standish Group 2004 Standish Group: Third Quarter Research 

Report. http://www.standishgroup.com. 2004 

62 Stimely 1990 Stimely, Gwen L.: A stepwise approach to developing 

software documentation. In: ACM SIGDOC Asterisk Journal of 

Computer Documentation 14 (1990), Nr. 4, S. 121–124 

63 Störrle 2005 Störrle, Harald: UML 2 für Studenten. Pearson 

Studium, 2005. – ISBN 3-8273-7143-0 

64 Sun microsystems 1999 Sun microsystems: Code Conventions for 

the Java TM Programming Language. April 1999. – URL http: 

//java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html 

Das SWP-Lied 


65 Winter 2003 Winter, Andreas: Einführung in die Softwaretechnik. 


66 Zachman 1987 Zachman, J. A.: A framework for information systems 

architecture. In: IBM Systems Journal 26 (1987), Nr. 3 

67 Zachman 1999 Zachman, J. A.: A framework for information systems 

architecture. In: IBM Systems Journal 38 (1999), Nr. 2&3, S. 454—470 

68 Zuser u. a. 2004 Zuser, W. ; Grechenig, T. ; Köhle, M.: Software 

Engineering mit UML und dem Unified Process. Zweite Ausgabe. 

Pearson Studium, 2004

Software-Projekt ¨Uberblick I - Informatik - Universität Bremen

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?