Prof. Dr. Rainer Koschke - Informatik - FB3 - Uni Bremen · Software-Projekt Prof. Dr. Rainer Koschke Fachbereich Mathematik und Informatik Arbeitsgruppe Softwaretechnik Universit

Software-Projekt

Prof. Dr. Rainer Koschke

Fachbereich Mathematik und InformatikArbeitsgruppe Softwaretechnik

Universitat Bremen

Wintersemester 2008/09

Uberblick I

1 Vorbemerkungen

2 Softwaretechnik

3 Planung

4 Anforderungsanalyse

5 Objektorientierte Modellierung

6 Reviews

7 Entwurf von Benutzungsschnittstellen

Uberblick 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

Vorbemerkungen1 Vorbemerkungen

Ziele und InhaltAngestrebte ResultateAktivitaten der Software-EntwicklungAblaufZeitplanAnmeldungScheinbedingungenProjektplanVorstellung der AufgabeKontaktdatenRessourcenLehrbucherEigenschaften von SoftwareSoftware-LebenszyklusSoftware-EvolutionEntstehung der SoftwaretechnikMerkmale der SoftwaretechnikProjektVorgehenInhaltZeitplanPlanung und Aufwand im SWP 05/06RisikenRisiko-ManagementErfahrungen aus dem SWP 05/06Allgemeine Risiken in einem Software-ProjektWiederholungsfragenLernzieleHerausforderungenAktivitatenIst-Analyse

ErhebungstechnikenBefragungBeobachtung

Soll-Analyse: PrototypingZusammenfassung der TechnikenAnforderungsspezifikation

BedeutungAnzustrebende EigenschaftenRegelnAufbau und Inhalt

WiederholungsfragenLernzieleModellbildungObjektorientierte ModellierungGeschaftsprozesseAnwendungsfalleUML-Notation fur AnwendungsfalleStatische Eigenschaften: KlassendiagrammeVerhaltenseigenschaftenInteraktionsdiagrammeSequenzdiagrammeKommunikationsdiagrammeAktivitatsdiagrammeZustandsautomatendiagrammeWiederholungsfragenMotivationLernzieleSoftware-PrufungenReviewsAblauf von ReviewsReview-RegelnReview-ChecklistenReview-VariantenFallen und GegenmittelWiederholungsfragenMotivationLernzieleErgonomiePsychologische und kognitive GrundlagenKommandosprachen versus GUIGeschichte graphischer BenutzungsschnittstellenInteraktionsmechanismenSoftware-ergonomische RichtlinienUsability messen und verbessernZusammenfassungWiederholungsfragenWas ist Software-Architektur?EinflussfaktorenArchitektursichten und -blickwinkelKonzeptioneller BlickwinkelModulblickwinkelAusfuhrungsblickwinkelCode-SichtModularisierungSchnittstellenKopplung und ZusammenhaltQualitatenBewertung von ArchitekturenWiederholungsfragenWas ist ein Entwurfsmuster?Bestandteile eines EntwurfsmustersKategorien von EntwurfsmusternEntwurfsmuster Factory MethodEntwurfsmuster ObserverArchitekturstileArchitekturstil SchichtungArchitekturstil Model-View-ControllerWiederholungsfragenBegriffe des TestensSoziologie des TestensTestaktivitatenTestfallTeststumpfe und -treiberKomponententestsAquivalenztestKomponententest mit JUnitGrenztestPfadtestMaße der TestabdeckungZustandsbasiertes TestenIntegrationstestLeistungstestsZusammenfassung der TestartenTestmanagementTestplanTestfallspezifikationTestschadensberichtWiederholungsfragenMotivationArchitekturkonformitatProgrammierrichtlinienAnhangWiederholungsfragenLernzieleWas ist Benutzerdokumentation?Arten der DokumentationStrukturAuf Papier oder elektronisch?AutorWie schreibt man eine Dokumentation?Hinweise und RegelnWiederholungsfragenObjektorientierte ModellierungSoftwarearchitekturEntwurfsmuster und ArchitekturstileSoftwaretechnik im Allgemeinen

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

Vorbemerkungen

Anmerkungen zu diesem Skriptum

Einige dieser Folien basieren inhaltlich auf Skripten von. . .

Prof. Dr. Jochen Ludewig (2003), Universitat Stuttgart

Prof. Dr. Susanne Maaß (2001), Universitat Bremen

Prof. Dr. Karl-Heinz Rodiger (2004), Universitat Bremen

Dr. Andreas Winter (2003), Universitat Koblenz

Ich danke fur deren freundliche Genehmigung.


Vorbemerkungen

Ziele der Vorlesung

Primare Ziele:

Rustzeug fur die erfolgreiche Durchfuhrung Ihres Software-Projektsvermitteln

Modell fur zukunftige ahnliche Projekte bieten

→ Praktikum und Vorlesung bilden eine Einheit

Primare Ziele sind nicht:

Vollstandige Darstellung aller Themengebiete der Softwaretechnik1

Vermittlung von spezifischen Kenntnissen fur die Entwicklung desAnwendungssystems X

1Wird im Hauptstudium nachgereicht.Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 6 / 634

Vorbemerkungen

Software-Projekt

Szenario:

Erstellung eines großen Softwaresystems

hier: mehrere Mitarbeiter uber einen langen Zeitraumhier nicht: ein

”Freizeit“-Programmierer

fur einen Auftraggeber

hier: Individualsoftwarehier nicht: Standardsoftware

im Rahmen eines Projekts

hier: einmalige Zielverfolgunghier (eher) nicht: Weiterentwicklung existierender Software(aber: die Software wird von uns spater weiterentwickelt; Wartbarkeitist erklartes Ziel)


Vorbemerkungen

Angestrebte Resultate

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.


Vorbemerkungen

Aktivitaten bei der Softwareentwicklung

managem

ent

Qualitäts−

Konfigurations−management

man

agem

ent

Projekt−

Imple−men−tierung

Inbetrieb−nahme

Analyse

Entwurf

Test


Vorbemerkungen

beeinflusst/startet

pruft

Infrastruktur einrichten

Initiale Projektplanung

Ist-Analyse

Soll-Analyse

Usability-Prototyp

Anforderungsspezifikation

Review der Anforderungs-spezifikation

HandbuchschreibenArchitekturentwurf

TechnischesPrototyping

Architekturreview

Testplan u. Unit-Test-Entw.

Implementierung

Code-InspektionUnit-/Integrationstests

Systemtests

Testprotokoll

Akzeptanztest(Prasentation)

Ubergabe


beeinflusst/startet

pruft

Infrastruktur einrichten

Initiale Projektplanung

Ist-Analyse

Soll-Analyse

Usability-Prototyp


Review der Anforderungs-spezifikation

HandbuchschreibenArchitekturentwurf

TechnischesPrototyping

Architekturreview

Testplan u. Unit-Test-Entw.

Implementierung

Code-InspektionUnit-/Integrationstests

Systemtests

Testprotokoll

Akzeptanztest(Prasentation)

Ubergabe

20

09

-02

-09

Software-Projekt

Vorbemerkungen

Ablauf

Aktivitaten in schwarzer Schrift sind konstruktiv; Aktivitaten in blauer Schrift dienen der analytischenQualitatssicherung. Das Symbol kennzeichnet abzugebende Dokumente, die Produkt einer Aktivitat sind.

Vorbemerkungen

Zeitplan

24.11.2008 Initialer Projektplan12.1.2009 Anforderungsspezifikation mit Angebot

12.-30.1.2009 Review der Anforderungsspezifikationvorauss. 9-13.2.2009 Vorlesung Datenbankgrundlagenvorauss. 9-20.3.2009 Prufung zur Vorlesung

16.3.2009 Architekturentwurf6.-13.4.2009 Walkthrough des Architekturentwurfs

20.4.2009 Testplan mit Unit-TestsMai/Juni 2009 Code-Inspektion

10.7.2009 Endabgabe2

15-17.7.2009 Abschlussprasentationen

Vorlaufige Teilergebnisse mussen Sie evtl. in den Tutorien vorher abgeben.

2Implementierung (Source+lauffahig), Dokumentation, Whiteboxtests, Testprotokoll,Dokumentation der Abweichungen von Spezifikation und Architektur


Vorbemerkungen

Anmeldung

Tutorienwahl ab sofort bis zum bis 30.10., 23.59 Uhr3

(erstes Tutorium am 3.11.)

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

gruppenweise anmelden

Gruppengroße 6 Personen

Gruppennamen sorgfaltig auswahlen

auslandische Studierende integrieren

3Ortszeit BremenRainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 12 / 634

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

Vorbemerkungen

Scheinbedingungen

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




Vorbemerkungen

Abgabe des Projektplans

abzugebender initialer Projektplan umfasst Aufgaben, Teilnehmer,Rollen, Verantwortlichkeiten, Pflichten, Risiken und deren Behandlung

danach: inkrementelle Fortfuhrung

kann abgegeben werden fur Feedback vom Tutor, muss aber nichtraten wir aber dringend anVerantwortlicher ist z.B. Phasenleiter fur die zu planende Phaseerste Woche jeder Phase dient Einarbeitung und PlanungGranularitat der Arbeitspakete: Arbeitsumfang von 1-2 Personen mitmax. 1-2 Zeitwochengerade in Krisenzeiten (Implementierungsphase) braucht man einenPlan (was ware die Feuerwehr ohne Plan?)

Fertigstellung (Ist) wird dokumentiert durch individuelle Zeiterfassungaufgeschlusselt in Aktivitaten (Anette).


Vorbemerkungen

Anette: Aufgaben-Management


Vorbemerkungen

Anette: Zeiterfassung


Vorbemerkungen

Die Aufgabe

Aktuelle Probleme bei der Durchfuhrung von Arbeitssitzungen im SWPund anderswo:

Terminfindung ist ein langwieriger Prozess

keine Moglichkeit 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 Unterstutzung von Arbeitssitzungenz.B. im SWP


Vorbemerkungen

Durchfuhrung von Arbeitssitzungen

Rollen: Moderator, Protokollant, sonstige Teilnehmer

Vorbereitung:

1 Terminfindung

2 Aufstellung der Agenda mit Priorisierung und Zeitplan

3 Versenden der Einladung mit Agenda


Vorbemerkungen


Durchfuhrung:

1 Feststellung der Anwesenheit

2 ggf. Anpassung der Agenda

3 Abfragen der offenen Aufgaben des letzten Treffens4 Abarbeitung der Agenda:

entlang der PriorisierungEinhaltung des ZeitplansProtokollierung aller wesentlichen Punkte

5 Festlegung von Aufgaben mit Verantwortlichen und Erledigungsdatum


Vorbemerkungen


Nachbearbeitung:

1 Versenden des Protokolls

2 ggf. Anpassung des Protokolls

3 Auswertungen von Statistiken, um Arbeitssitzungen kontinuierlich zuverbessern


Vorbemerkungen

Erforderliche Funktionalitat

Meeting Assistant soll den gesamten Prozess unterstutzen:

Zeitfindung unter den Teammitglieder

Vorbereitung der Agenda und Verteilung im Vorfeld

Protokollerstellung wahrend der Besprechung und Verteilung imAnschluss

Uberprufen der offenen Punkte vom letzten Protokoll

Integration mit Anette ware vorteilhaft, ist aber nicht verbindlich.Quellcode von Anette kann erweitert werden.


Vorbemerkungen

Erforderliche Funktionalitat

Randbedingungen:

Implementierung in Java 5 oder hoher

Swing-GUI, keine Webanwendung

Mehrbenutzerbetrieb

hoher Anspruch an Datenschutz und -sicherheit

hoher Anspruch an Benutzbarkeit/Ergonomie

Client/Server Anwendung

Verwendung von MySQL fur den Server

Verwendung von SQL-Abfragen

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


Vorbemerkungen

Vorlesungsbegleitender Technikkurs

Themen:

Swing

Sockets (TCP)

RMI

SSL

Serialisierung

Datenbankanbindung

OR-Mapping

XML Parser

Multithreading

. . .

jeweils Einfuhrung + betreute Ubung

optionales Angebot, Teilnahme freiwillig

etwa 4–5 Termine

Termin: im Januar/Februar?


Vorbemerkungen

Die Beteiligten

Tel. E-Mail OrtRainer Koschke 9671 koschke OAS 3016Raimar Falke 2576 rfalke OAS 3012Markus Eich 64105 eich DFKI 212Hendrik Iben 2447 hiben TAB 1.91Hui Shi 64260 shi Cartesium 1.053Xin Xing 3035 xing TAB 1.77

. . . und naturlich Sie!


Vorbemerkungen

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


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

http://www.informatik.uni-bremen.de/st/lehredetails.php?id=&lehre_id=46

http://www.informatik.uni-bremen.de/st/lehredetails.php?id=&lehre_id=46

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

http://mlecture.uni-bremen.de

fb3.lv.swp

Vorbemerkungen

Lehrbucher zur Softwaretechnik I

Allgemeine Literatur zur Softwaretechnik:

Balzert (1998): Umfassendes deutsches Lehrbuch vmtl. der Bestsellerin Deutschland; leider nicht mehr im Buchhandel verfugbar, wird neuaufgelegt

Ludewig und Lichter (2006): Umfassendes Lehrbuch, das ausLudewigs Vorlesungen rund um Softwaretechnik entstanden ist. DieseVorlesung basiert in großen Teilen auf dem Skript von LudewigsVorlesung.

Sommerville (2004): Ein Standardlehrbuch, sowohl in deutscher alsauch englischer Sprache verfugbar. Im Umfang vergleichbar mit demBuch von Pressman (2003).

Pressman (2003): Ein umfassendes englisches Lehrbuch, das man fastschon als Enzyklopadie bezeichnen konnte. Behandelt auchnicht-objektorientierte Konzepte.


Vorbemerkungen

Lehrbucher zur Softwaretechnik II

Brugge und Dutoit (2004): Eine Einfuhrung in Deutsch mitSchwerpunkt Objektorientierung und UML.

Zuser u. a. (2004): Eine Einfuhrung in Deutsch mit SchwerpunktObjektorientierung und dem Rational Unified Process. Wenigerumfassend als das Buch von Brugge und Dutoit (2004).

Spezialthemen:

Storrle (2005): Eine kurze Einfuhrung in die Konzepte der UML 2.0 indeutscher Sprache.


Allgemeines zur Softwaretechnik


Ziele und InhaltAngestrebte ResultateAktivitaten der Software-EntwicklungAblaufZeitplanAnmeldungScheinbedingungenProjektplanVorstellung der AufgabeKontaktdatenRessourcenLehrbucher

2 SoftwaretechnikEigenschaften von SoftwareSoftware-LebenszyklusSoftware-EvolutionEntstehung der SoftwaretechnikMerkmale der SoftwaretechnikProjektVorgehenInhaltZeitplanPlanung und Aufwand im SWP 05/06RisikenRisiko-ManagementErfahrungen aus dem SWP 05/06Allgemeine Risiken in einem Software-ProjektWiederholungsfragenLernzieleHerausforderungenAktivitatenIst-Analyse







Was ist Software?

Definition

Software: Computer programs, procedures, and possibly associateddocumentation and data pertaining to the operation of a computer system.

IEEE Std 610.12-1990 (1990)


Was ist Software?

Definition

Software: Computer programs, procedures, and possibly associateddocumentation and data pertaining to the operation of a computer system.

IEEE Std 610.12-1990 (1990)

20

09

-02

-09

Software-Projekt

Softwaretechnik

Eigenschaften von Software

Was ist Software?

Software umfasst also nach IEEE Std 610.12 Programme, Ablaufe, Regeln, auch Dokumentation und Daten, diemit 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.



Software

ist ein technisches Produkt,

weist aber einige einmalige Merkmale auf.

→ Sie sollten beim Umgang mit Software beachtet werden.

20

09

-02

-09

Software-Projekt

Softwaretechnik



Generell kann und sollte Software als technisches Produkt betrachtet werden, das wie andere Produkte vonIngenieuren systematisch entwickelt werden kann und durch feststellbare Eigenschaften (Funktionalitat, Qualitat)gekennzeichnet ist. Software ist sogar frei von allen Unwagbarkeiten, die anderen technischen Produkten anhaften.Sie ist in diesem Sinne das ideale technische Produkt. Als Software-Leute sollten wir darum keine spezielleNachsicht erwarten. Software weist aber (wie viele andere Produkttypen) einige besondere und wenigstens in dieserKombination einmalige Merkmale auf: Sie mussen beim Umgang mit Software beachtet werden.



Software ist immateriell:

Software kann nicht ohne Weiteres betrachtet werden.Kopie und Original sind vollig gleich.Software wird nicht gefertigt, sondern nur entwickelt.Software verschleißt nicht.Software

”altert“ in dem Maße, in dem sich ihre Umwelt andert.



Software ist immateriell:

Software kann nicht ohne Weiteres betrachtet werden.Kopie und Original sind vollig gleich.Software wird nicht gefertigt, sondern nur entwickelt.Software verschleißt nicht.Software

”altert“ in dem Maße, in dem sich ihre Umwelt andert.

20

09

-02

-09

Software-Projekt

Softwaretechnik



Was wir als naturlich empfinden, ist an materielle Eigenschaften geknupft. An Software ist nichts naturlich.Erfahrungen aus der naturlichen Welt sind nicht ubertragbar (werden dennoch standig ubertragen, siehe z.B.Wartung). Kopie und Original sind vollig gleich. Software wird nicht gefertigt, sondern nur entwickelt. Softwareverschleißt nicht; die Wartung stellt nicht den alten Zustand wieder her, sondern einen neuen. Wiederverwendungist bei Software extrem lukrativ, wenn der Aufwand fur Anpassungen relativ gering ist. Programmiererunterschatzen meist das Problem (. . . oder uberschatzen sich selbst!)



Software hat keine naturliche Lokalitat.

Ihre Werkstoffe sind amorph und universell.

Strukturen mussen aktiv geschaffen werden.

Ein Programm realisiert keine stetige Funktion.

Korrektheit ist durch Test nicht prufbar.



Software hat keine naturliche Lokalitat.

Ihre Werkstoffe sind amorph und universell.

Strukturen mussen aktiv geschaffen werden.

Ein Programm realisiert keine stetige Funktion.

Korrektheit ist durch Test nicht prufbar.

20

09

-02

-09

Software-Projekt

Softwaretechnik



Naturliche Lokalitat gibt es bei Software nicht. Im Speicher eines Rechners gibt es keine schutzende Distanz. DieWerkstoffe der Software sind amorph und universell. Werkstoffe sind die eingesetzten Sprachen, meist nur dienaturliche Sprache und die Programmiersprache, evtl. noch andere, z.B. graphische Notationen.Ein Programm realisiert keine stetige Funktion. Der Zusammenhang zwischen Eingabe und Ausgabe lasst sich nichtdurch eine kontinuierliche Funktion beschreiben.



Software-Systeme sind sehr komplex:

→ Entwicklungskosten sind unvermeidlich hoch.→ Korrekte Konstruktion ist extrem schwierig.

Software spiegelt (in vielen Fallen) die Realitat wider.

“This complexity is compounded by the necessity to conform toan external environment that is arbitrary, unadaptable, andeverchanging.”

–F.P. Brooks, 1987



Software-Systeme sind sehr komplex:

→ Entwicklungskosten sind unvermeidlich hoch.→ Korrekte Konstruktion ist extrem schwierig.

Software spiegelt (in vielen Fallen) die Realitat wider.

“This complexity is compounded by the necessity to conform toan external environment that is arbitrary, unadaptable, andeverchanging.”

–F.P. Brooks, 1987

20

09

-02

-09

Software-Projekt

Softwaretechnik



Software-Systeme sind sehr komplex (nach Zahl der relevanten Entscheidungen darin), vergleichbar mit anderensehr komplexen Systemen. Es ist extrem schwer, sie trotzdem so zu konstruieren, dass sie automatisch und korrektarbeiten.



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

Sie verbindet Hardware und Umgebung.Details der Aufgabenstellung werden in aller Regel durch Softwarerealisiert.

→ Anderungen schlagen sich entsprechend primar in der Software nieder.

4Software ist nur in dem Maße flexibel, in dem die Flexibilitat explizit eingebaut ist.Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 34 / 634


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

Sie verbindet Hardware und Umgebung.Details der Aufgabenstellung werden in aller Regel durch Softwarerealisiert.

→ Anderungen schlagen sich entsprechend primar in der Software nieder.

4Software ist nur in dem Maße flexibel, in dem die Flexibilitat explizit eingebaut ist.

20

09

-02

-09

Software-Projekt

Softwaretechnik



Software ist nur in dem Maße flexibel, in dem die Flexibilitat explizit eingebaut ist: Es ist leicht einen Parameter zuverandern, aber nur wenn dieser Parameter in der Software vorhanden ist.


Software-Lebenszyklus

Entwurf

Analyse

Implemen−tierung

Test

Wartung& Evolution



Entwurf

Analyse

Implemen−tierung

Test

Wartung& Evolution

20

09

-02

-09

Software-Projekt

Softwaretechnik



Wie jeder komplexe Engineering-Prozess, so verlauft auch die Software-Entwicklung in mehreren Phasen. DieSoftware wird spezifiziert, eine Losung wird entworfen und implementiert und schließlich getestet. Nach derAuslieferung wird sie gewartet. Das heißt, Fehler werden korrigiert sowie Erweiterungen und Anpassungenvorgenommen.Diese Darstellung suggeriert, dass alle Teilphasen mehr oder minder gleich lang sind. Dies stimmt jedoch nicht.


Aufwand in den Phasen nach McKee (1984)

Implemen−

tierung

Wartung

& Evolution

Analyse

Entwurf

Test



Implemen−

tierung

Wartung

& Evolution

Analyse

Entwurf

Test

20

09

-02

-09

Software-Projekt

Softwaretechnik



Hier sehen Sie eine Darstellung des Entwicklungsprozesses, in der die einzelnen Phasen entsprechend ihrer Dauergezeichnet sind.Empirische Untersuchungen zeigen, dass bis zu 80% der Kosten erst nach der Auslieferung entstehen. Das heißt, inder Wartungs- und Evolutionsphase.Diese Phase unterscheidet sich von den anderen Phasen darin, dass man sich mit einem existierenden Systemauseinander setzen muss.Diese Verteilung sagt ubrigens auch aus, dass unsere Studenten zu 80prozentiger Wahrscheinlichkeit es in ihremspateren Berufsleben mit der Wartung zu tun haben werden. Nur an wenigen Universitaten werden sie hieraufausreichend vorbereitet.


Evolutionsphase nach Fjeldstadt und Hamlen (1984)

Änderung und TestVerstehen

Implemen−tierung

Wartung& Evolution

Analyse

Entwurf

Test



Änderung und TestVerstehen

Implemen−tierung

Wartung& Evolution

Analyse

Entwurf

Test

20

09

-02

-09

Software-Projekt

Softwaretechnik



Weitere Studien zeigen, dass Wartungsprogrammierer etwa die Halfte ihrer Zeit allein mit der Analyse der Softwareverbringen, ehe sie ihre Anderungen vornehmen und testen. Bei der Korrektur von Fehlern liegt der Aufwand eherbei 60%.Dieser hohe Aufwand liegt an der unzureichenden Information, die den Wartungsprogrammierern zur Verfugungsteht. Die Programmierer mussen die Informationen muhsam von Hand herleiten, weil ihnen die dazu notwendigenWerkzeuge fehlen.Wer Kosten bei der Software-Entwicklung sparen mochte, muss hier ansetzen.


Lehman und Beladys”Gesetze“ (1985)

Gesetz vom fortwahrenden Wandel

Software lost ein Problem der realen Welt,

die reale Welt andert sich,

Software muss sich anpassen,

bis sie abgelost wird.



Gesetz vom fortwahrenden Wandel

Software lost ein Problem der realen Welt,

die reale Welt andert sich,

Software muss sich anpassen,

bis sie abgelost wird.

20

09

-02

-09

Software-Projekt

Softwaretechnik

Software-Evolution


Warum muss Software uberhaupt angepasst werden? Die Begrundung fallt leicht. . . .



Gesetz der zunehmendenKomplexitat

die Komplexitat derSoftware erhoht sichbeim Wandel,

wenn keineGegenmaßnahmenergriffen werden



Gesetz der zunehmendenKomplexitat

die Komplexitat derSoftware erhoht sichbeim Wandel,

wenn keineGegenmaßnahmenergriffen werden

20

09

-02

-09

Software-Projekt

Softwaretechnik

Software-Evolution


Leider geht mit dem Zwang zur Anderung der Anstieg der Komplexitat der Software einher. Hier sehen Sie eineGrafik von Many Lehman, der sich als einer der ersten mit dem Phanomen der Software-Evolution empirischauseinander gesetzt hat.Sie sehen hier den Umfang eines Systems, gemessen in der Anzahl seiner Module, uber die Zeit. Die Messpunktesind die verschiedenen Releases der Software.Sie bemerken das Wachstum. Aber auch gleichzeitig die Verlangsamung des Wachstums. Die Dauer zwischenReleases nimmt zu.Um diesem Trend entgegen zu wirken, mussen Sie Maßnahmen ergreifen, um die Komplexitat einzudammen.


Software-Evolution

Konsequenzen:

Anderbarkeit ist eine Schlusselqualitat

Anderbarkeit muss fruhzeitig angestrebt werden

sie lasst sich nicht nachtraglich uberstulpen

wer sie vernachlassigt, nimmt einen Kredit auf, den er teuer abzahlenwird



Wo liegen die Probleme in der Softwaretechnik?

In den spaten 60er Jahren:

Manche Software-Projekte sind selbst mit gigantischem Aufwandnicht zu schaffen.

In vielen anderen Fallen wird der Abschluss nur mit unbefriedigendenResultaten, viel zu spat und/oder mit extremenKostenuberschreitungen erreicht.

Andererseits erzielt die Hardware-Entwicklung atemberaubendeFortschritte.

“The whole trouble comes from the fact that there is so muchtinkering with software. It is not made in a clean fabricationprocess, which it should be. What we need is softwareengineering.”

–F.L. Bauer, 1968



In den spaten 60er Jahren:

Manche Software-Projekte sind selbst mit gigantischem Aufwandnicht zu schaffen.

In vielen anderen Fallen wird der Abschluss nur mit unbefriedigendenResultaten, viel zu spat und/oder mit extremenKostenuberschreitungen erreicht.

Andererseits erzielt die Hardware-Entwicklung atemberaubendeFortschritte.

“The whole trouble comes from the fact that there is so muchtinkering with software. It is not made in a clean fabricationprocess, which it should be. What we need is softwareengineering.”

–F.L. Bauer, 1968

20

09

-02

-09

Software-Projekt

Softwaretechnik

Entstehung der Softwaretechnik


Kurz: Es ist nicht alles machbar, was prinzipiell moglich sein musste. Fur diese Probleme kam das SchlagwortSoftware Crisis in Mode. Die Software-Krise war Anlass fur viele Diskussionen und Tagungen. Auf derNATO-Konferenz in Garmisch (1968) pragte F.L. Bauer das Wort Software Engineering als Provokation (siehe dazuBauer, 1993).


Wie viel hat sich bis heute daran geandert?

Beispiel

Fehler:

vollstandiger Batterieausfall in Fahrzeugen eines deutschenAutomobil-Herstellers

Ursache:

Fehler in der software-gesteuerten Innenbeleuchtung

Folge:

Ruckrufaktion mit einem (geschatzten) Schaden von mehrerenMillionen DEM

Partsch (1998)




Beispiel

Fehler:

Bei der rechnergestutzten Auswertung der OB-Wahl in Neu-Ulm 1994wurde zunachst eine Wahlbeteiligung von 104% festgestellt.

Ursache:

In der Auswertungssoftware hatte sich ein mysterioser Faktor 2eingeschlichen.

Folge:

Neuauszahlung

Partsch (1998)




Beispiel

Fehler:

USS Yorktown treibt wahrend eines Manovers im September 1997manovrierunfahig bei Cape Charles, VA.

Ursache:

Fehler in einer Routine zum Abfangen einer Division durch Null in einerWindows 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 2hours and 45 minutes.”

Neumann (1999)



Produktgarantie?

Disclaimer of Warranty:

This car is provided under this license on an “as is” basis, withoutwarranty 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. Theentire risk as to the quality and performance of the car is with you.Should any car prove defective in any respect, you (not the initialdeveloper or any other contributor) assume the cost of any necessaryservicing, repair or correction.



Garantien uber Software?


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 freeof defects, merchantable, fit for a particular purpose ornon-infringing. The entire risk as to the quality and performance ofthe software is with you. Should any software prove defective inany 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 freeof defects, merchantable, fit for a particular purpose ornon-infringing. The entire risk as to the quality and performance ofthe software is with you. Should any software prove defective inany respect, you (not the initial developer or any other contributor)assume the cost of any necessary servicing, repair or correction.

20

09

-02

-09

Software-Projekt

Softwaretechnik

Entstehung der Softwaretechnik


An solche Disclaimer haben wir uns schon lange gewohnt. Stellen Sie sich vor, sie lesen einen solchen in derBetriebsanleitung Ihres Autos. Sie wurden das Auto sofort zuruckgeben.Ubrigens: Solche Disclaimer sind nach deutschem Recht hinfallig. Stellen Sie jemandem auf dem Netz einProgramm zur Verfugung, sind Sie automatisch in der Haftung. Grobe Fahrlassigkeit und Vorsatz lassen sich inDeutschland nicht ausschließen.Spezifizieren Sie nicht den Zweck Ihres Programms, so wird zu Grunde gelegt, was man ublicherweise von einemProgramm dieser Art erwartet.


Ingenieursdisziplin (Shaw und Garlan 1996)

Kunst

Talentierte Amateure

• Herstellung fur die Verwendung,

• verschwenderische Verwendung• gelegentliche Ubermittlung• wahlloser Fortschritt

weniger fur den Verkauf

verfugbaren Materials

• intuitiv und ad hoc

ProduktionHandwerk

• pragmatische Verfeinerungen

• Herstellung fur den Verkauf

• Ausbildung in der Ausfuhrung

• etabliertes Vorgehen

• okonomische Betrachtungder Materialien

Geubte Arbeiter

Wissenschaft

Ingenieursdisziplin

• Analyse und Theorie

• Einfuhrung neuer

• Marktsegmentierung durchProduktvielfalt

Wissenschaft

Anwendungen durch Analyse

Ausgebildete Personen

• Fortschritt basiert auf



Definition

Softwaretechnik:

Entdeckung und Anwendung solider Ingenieur-Prinzipien mit demZiel, auf wirtschaftliche Art Software zu bekommen, die zuverlassig istund auf realen Rechnern lauft.

–F.L. Bauer

Herstellung und Anwendung einer Software, wobei mehrere Personenbeteiligt sind oder mehrere Versionen entstehen.

–D.L. Parnas

(1) The application of a systematic, disciplined, quantifiable approachto the development, operation, and maintenance of software; that is,the application of engineering to software. (2) The study ofapproaches as in (1). IEEE Std 610.12-1990 (1990)


Definition

Softwaretechnik:

Entdeckung und Anwendung solider Ingenieur-Prinzipien mit demZiel, auf wirtschaftliche Art Software zu bekommen, die zuverlassig istund auf realen Rechnern lauft.

–F.L. Bauer

Herstellung und Anwendung einer Software, wobei mehrere Personenbeteiligt sind oder mehrere Versionen entstehen.

–D.L. Parnas

(1) The application of a systematic, disciplined, quantifiable approachto the development, operation, and maintenance of software; that is,the application of engineering to software. (2) The study ofapproaches as in (1). IEEE Std 610.12-1990 (1990)2

00

9-0

2-0

9

Software-Projekt

Softwaretechnik

Merkmale der Softwaretechnik

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, undeinen anderen undefinierten Begriff zu Grunde legt.


Abschrift aus dem Vorwort zum Vorlesungsskript Werkstoffe derElektrotechnik (Prof. Fischer, Uni-Dortmund, 1977)



Merkmale der alten Ingenieurdisziplinen

Kostendenken als Grundlage von Bewertungen

praktischer Erfolg als einziger zulassiger Beweis

Qualitatsbewusstsein als Denkprinzip

Einfuhrung und Beachtung von Normen (Schnittstellen, Verfahren,Begriffe)

Denken in Baugruppen



Kostendenken als Grundlage von Bewertungen

praktischer Erfolg als einziger zulassiger Beweis

Qualitatsbewusstsein als Denkprinzip

Einfuhrung und Beachtung von Normen (Schnittstellen, Verfahren,Begriffe)

Denken in Baugruppen

20

09

-02

-09

Software-Projekt

Softwaretechnik

Merkmale der Softwaretechnik


Definition und Anwendung von Methoden, Bereitstellung und Verwendung von Werkzeugen sind allgemeinbewahrte Ansatze, also nicht typisch fur Ingenieure. Ingenieur-spezifisch sind dagegen:

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

• praktischer Erfolg als einziger zulassiger Beweis: nur was gezahlt oder gemessen wurde, ist ein akzeptables Argument;

• Qualitatsbewusstsein: hohe Qualitat ist ein Prinzip der unspezifischen Kostensenkung; kommt aus der handwerklichenTradition, die die Ingenieure ubernommen haben;

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

• Baugruppen: Durch Normen entsteht die Moglichkeit, Baugruppen zu verwenden, also die Losung der Teilproblemeauszuklammern.


Wiederholungsfragen

Was sind die besonderen Eigenschaften von Software?

Was folgt aus diesen Eigenschaften fur die Softwareentwicklung?

Aus welchen Phasen besteht der Software-Lebenszyklus?

Was ist die Besonderheit der Wartungsphase und was folgt daraus furdie Softwareentwicklung?

Warum muss Software uberhaupt angepasst werden? Welche Folgenkonnen diese Anderungen haben?

Welche Einsichten fuhrten zur Entstehung der Softwaretechnik? Mitwelchen Problemen ist die Softwaretechnik nach wie vor konfrontiert?

Was ist Softwaretechnik? Welche Ziele verfolgt sie?

Was sind die Kennzeichen einer Ingenieursdisziplin und wie entstehtsie?


Planung eines Software-Projekts


Ziele und InhaltAngestrebte ResultateAktivitaten der Software-EntwicklungAblaufZeitplanAnmeldungScheinbedingungenProjektplanVorstellung der AufgabeKontaktdatenRessourcenLehrbucherEigenschaften von SoftwareSoftware-LebenszyklusSoftware-EvolutionEntstehung der SoftwaretechnikMerkmale der Softwaretechnik

3 PlanungProjektVorgehenInhaltZeitplanPlanung und Aufwand im SWP 05/06RisikenRisiko-ManagementErfahrungen aus dem SWP 05/06Allgemeine Risiken in einem Software-ProjektWiederholungsfragenLernzieleHerausforderungenAktivitatenIst-Analyse







Projekt

Definition

Projekt: eine fur begrenzte Zeit mit bestimmtem Ziel bestehendeOrganisation mit all ihren Bestandteilen, Beziehungen im Innern und nachaußen.



Planung

Planung

am Anfang:

Gliederung in Phasen, Aktivitaten, Arbeitspakete,zeitlicher Ablauf (Meilensteine),Arbeitsorganisation,Aufbau der Dokumentation.

wahrend des Projekts:

Controlling (d.h. die Uberwachung des Projektfortschritts),Reaktion auf Abweichung (Anpassung des Plans).


Planung

Planung

am Anfang:

Gliederung in Phasen, Aktivitaten, Arbeitspakete,zeitlicher Ablauf (Meilensteine),Arbeitsorganisation,Aufbau der Dokumentation.

wahrend des Projekts:

Controlling (d.h. die Uberwachung des Projektfortschritts),Reaktion auf Abweichung (Anpassung des Plans).

20

09

-02

-09

Software-Projekt

Planung

Projekt

Planung

Planung hat im Software-Projekt zwei verschiedene Bedeutungen: Zu Beginn des Projekts mussen Plane aufgestelltwerden fur die Gliederung in Phasen, den fur die Arbeitsorganisation, den fur den Aufbau der Dokumentation, undden fur die Prufungen. Die Existenz und die Qualitat dieser Plane hat zentrale Bedeutung fur den Erfolg desProjekts.Wahrend des Projekts bleibt die Planung eine Daueraufgabe, weil sich die Realitat meist nicht an unsere Planungenhalt. Notwendig ist ein Kompromiss zwischen der starrsinnigen Verteidigung von Planen, die offenkundig nichteinzuhalten sind, und der laufenden Anpassung der Plane an den realen Stand. Eine gewisse Spannung zwischenPlan und Realitat ist normal. Planung und Planverfolgung sind die wichtigsten Aufgaben der Projektleitung. Engdamit verbunden sind Controlling (d.h. die Uberwachung der Ausgaben in einem Projekt) und Qualitatssicherung(d.h. die Prufung aller Teilresultate und Resultate).


Elemente eines Projekts

Abnahmedurch Kunden abgenommene


Anforderungs−spezifikationSpezifikation

der Anforderungen

Prototyp

Soll−Beschreibung

Soll−Analyse

Ist−Analyse

Ist−Beschreibung

Prototyp

erstellen

Analysephase






der Anforderungen

Prototyp

Soll−Beschreibung

Soll−Analyse

Ist−Analyse

Ist−Beschreibung

Prototyp

erstellen

Analysephase

20

09

-02

-09

Software-Projekt

Planung

Projekt


Fur das Verstandnis von Projekten sind einige Grundbegriffe notwendig. Keiner dieser Begriffe ist spezifisch fur einSoftware-Projekt. Insgesamt kann angemerkt werden, dass allgemeine Aussagen zu Projekten (jedweder Form) inaller Regel auch fur Software-Projekte gelten. Die Natur der Software, die in einem Software-Projekt entwickeltwerden soll, kommt vielmehr in den Inhalten der Arbeitspakete zum Tragen.






der Anforderungen

Prototyp

Soll−Beschreibung

Soll−Analyse

Ist−Analyse

Ist−Beschreibung

Prototyp

erstellen

Analysephase

Definition

Aktivitat: Arbeitseinheit mitprazisem Anfangs und -enddatum

enthalt Aufgaben

benotigt Ressourcen

produziert Arbeitsprodukt







der Anforderungen

Prototyp

Soll−Beschreibung

Soll−Analyse

Ist−Analyse

Ist−Beschreibung

Prototyp

erstellen

Analysephase

Definition

Projektfunktion: Aktivitat, die diegesamte Projektlaufzeit uberspannt.Beispiele:

Projektmanagement

Konfigurationsmanagement

Qualitatssicherung.







der Anforderungen

Prototyp

Soll−Beschreibung

Soll−Analyse

Ist−Analyse

Ist−Beschreibung

Prototyp

erstellen

AnalysephaseDefinition

Arbeitspaket: Spezifikation fur einezu erledigende Arbeit. Definiert

Arbeitsprodukt,

Personalbedurfnisse,

erwartete Entwicklungsdauer,

verwendete Ressourcen,

Akzeptanzkriterien,

Namen desHauptverantwortlichen

und sonstige relevante Aspekteder Arbeit.







der Anforderungen

Prototyp

Soll−Beschreibung

Soll−Analyse

Ist−Analyse

Ist−Beschreibung

Prototyp

erstellen

AnalysephaseDefinition

Arbeitsprodukt ein konkretesErgebnis einer Projektfunktion oder-aktivitat. Beispiele:

Anforderungsspezifikation,

Projektplan,

funktionale Spezifikation,

Entwurfsdokumente,

Benutzerhandbuch,

Testplan

oder Protokolle von Reviewsoder Meetings.







der Anforderungen

Prototyp

Soll−Beschreibung

Soll−Analyse

Ist−Analyse

Ist−Beschreibung

Prototyp

erstellen

Analysephase

Definition

Meilenstein:

Menge von Kriterien

und vorgesehener Zeitpunkt

und erreichter Zeitpunkt

fur die Abnahme eines(Zwischen-)Resultats







der Anforderungen

Prototyp

Soll−Beschreibung

Soll−Analyse

Ist−Analyse

Ist−Beschreibung

Prototyp

erstellen

Analysephase

Definition

Baseline: Arbeitsprodukt,

formal begutachtet undakzeptiert,

nur durch formalenkontrollierten Anderungsprozessanderbar;

bildet Basis fur nachfolgendeArbeitsaktivitaten.



Vorgehen zur Planung

1 Auswahl eines geeigneten Prozesses (oder Prozessmodells)

2 Grobe Abschatzung des Gesamtumfangs und des Gesamtaufwands

3 Aufstellen eines Zeitplans

4 Aufstellen eines Dokumentationsplans

5 Aufstellen eines Prufplans

6 Aufstellen eines Organisationsplans

7 Definition der Meilensteine (1-6)

und naturlich: Iteration dieser Schritte, bis die Resultate zusammenpassen.



Vorgehen zur Planung

Wo es definierte Prozessmodelle gibt, kann (und muss) die Projektleiterindie Vorlagen fur die Plane aus der Schublade (d.h. aus dem Intranet)nehmen.

Der Projektplan sollte sorgfaltig gepruft werden!

Der Projektplan entsteht mit dem Projekt und wird im Verlauf desProjekts fortgeschrieben, aber nicht laufend geandert.

Der Projektplan ist Gegenstand der Anderungskontrolle.



Inhalt des Projektplans

Plan macht prinzipiell Aussagen zu den folgenden W-Punkten:

warum

was getan wird,

fur wieviel Geld,

von wem,

wann und

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



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

Ubersicht

0. Version und Anderungsgeschichte1. Einleitung2. Projektorganisation3. Managementprozess4. Technischer Prozess5. Arbeitspakete, Zeitplan und Budget6. Zusatzliche Elemente7. Index8. Anhang



Ubersicht

0. Version und Anderungsgeschichte1. Einleitung2. Projektorganisation3. Managementprozess4. Technischer Prozess5. Arbeitspakete, Zeitplan und Budget6. Zusatzliche Elemente7. Index8. Anhang2

00

9-0

2-0

9

Software-Projekt

Planung

Inhalt


Der Projektplan, wie jedes andere Dokument auch, erhalt eine Versionsnummer. Anderungen des Projektplans sindunausweichlich (er wird schrittweise verfeinert und angepasst). Die Anderungen mussen dokumentiert und

nachvollziehbar sein. Der Abschnitt “Version und Anderungsgeschichte” enthalt diese Information.Die Einleitung gibt einen Uberblick uber das Projekt und das Produkt, die Liste der auszuliefernden Dinge, der Planfur die Entwicklung und die Fortfuhrung des Projektplans, Referenzmaterial sowie Definitionen und Akronyme.Der Abschnitt “Projektorganisation” spezifiziert das Prozessmodell des Projekts, die Organisationsstruktur, dieGrenzen und Schnittstellen der Organisation und die individuellen Verantwortlichkeiten.Der Abschnitt “Managementprozess” spezifiziert die Managementziele und -prioritaten, Annahmen undEinschrankungen, Risiken und deren Behandlung sowie Kontrollmechanismen und den Personalplan.Der Abschnitt “Technischer Prozess” spezifiziert die technischen Methoden, Werkzeuge und Techniken, die imProjekt benutzt werden sollen. Außerdem wird der Dokumentationsplan und die Plane fur die Projektfunktionenspezifiziert, wie etwa die Qualitatssicherung und das Konfigurationsmanagement.Der Abschnitt “Arbeitspakete” spezifiziert die Arbeitspakete, ihre Abhangigkeiten und Beziehungen, die benotigtenRessourcen, Zuteilung des Budgets und Ressourcen auf Arbeitspakete sowie den Zeitplan.Der Abschnitt “Zusatzliche Elemente” enthalt Plane fur zusatzliche Komponenten.



Einleitung

1.1 Projektubersicht

Zusammenfassung der Ziele, Resultate, Hauptarbeitsaktivitaten und-produkte, Hauptmeilensteine, benotigte Ressourcen, grober Zeitplanund Budget; Kontaktdaten des Kunden

1.2 Auszuliefernde Produkte

alle an den Kunden auszuliefernde Produkte mit Auslieferungsdatumund -ort sowie deren Anzahl6

1.3 Evolution des Plans

Plan fur vorausgesehene und nicht vorausgesehene Aktualisierung desProjektplans und deren Bekanntmachung

1.4 Referenzen

1.5 Definitionen und Akronyme

6Die Anforderungsspezifikation ist ein separates Dokument!Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 67 / 634


Einleitung

1.1 Projektubersicht

Zusammenfassung der Ziele, Resultate, Hauptarbeitsaktivitaten und-produkte, Hauptmeilensteine, benotigte Ressourcen, grober Zeitplanund Budget; Kontaktdaten des Kunden

1.2 Auszuliefernde Produkte

alle an den Kunden auszuliefernde Produkte mit Auslieferungsdatumund -ort sowie deren Anzahl6

1.3 Evolution des Plans

Plan fur vorausgesehene und nicht vorausgesehene Aktualisierung desProjektplans und deren Bekanntmachung

1.4 Referenzen

1.5 Definitionen und Akronyme

6Die Anforderungsspezifikation ist ein separates Dokument!

20

09

-02

-09

Software-Projekt

Planung

Inhalt


Die Referenzen enthalten Verweise auf alle Dokumente und andere Informationsquellen, die im Projektplanreferenziert werden. Hierfur gelten die ublichen Zitierregeln.Der Abschnitt “Definitionen und Akronyme” beschreibt alle Begriffe, die fur das Verstandnis des Projektplansnotwendig sind, auch in Form von Verweisen auf entsprechende Dokumente mit deren Definition.Es handelt sich hier nicht um das Glossar der Anforderungsspezifikation, von dem spater noch die Rede sein wird.Der Projektplan kann aber auf dieses Glossar verweisen.



Projektorganisation

2.1 Prozessmodell

Beziehungen zwischen den Projektfunktionen und -aktivitaten mitHauptmeilensteinen, Baselines, Reviews, Produkte (interne undauszuliefernde) und Abschlusse

2.2 Organisationsstruktur

interne Managementstruktur (z.B. durch Organigramme):Weisungsbefugnis, Verantwortlichkeit und Kommunikation im Projekt7

2.3 Organisationsgrenzen und -schnittstellen

zwischen ubergeordneter Organisation, Kundenorganisation undUntervertragsnehmer

2.4 Verantwortlichkeiten

Auflistung aller Projektfunktionen und -aktivitaten unter Nennung derVerantwortlichen

7Kontaktdaten aller Beteiligter nicht vergessen!Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 68 / 634



Managementprozess

3.1 Managementziele und -prioritaten

Beispiele: Haufigkeit und Mechanismen der Berichterstattung; relativePrioritaten zwischen Anforderungen, Zeitplan und Budget; Absicht zurWiederverwendung existierender Software

3.2 Annahmen, Abhangigkeiten und Einschrankungen

Annahmen, auf denen das Projekt beruht; externe Ereignisse, vondenen es abhangt; Beschrankungen, unter denen das Projektdurchgefuhrt wird

3.3 Risikomanagement

Identifikation und Bewertung von Risiken; Mechanismen fur Verfolgungder Risikofaktoren; Notfallplane;Beispiele: Risiken mit Vertragen, technologische Risiken, Große undKomplexitat der Aufgabe, Personal, Akzeptanz des Kunden etc.




Managementprozess (Fortsetzung)

3.4 Projektuberwachung

Berichtswesen, Formate fur Berichte, Informationsflusse, Reviews undAudits; auf der Ebene von Arbeitspaketen; Beziehung zuProjektfunktionen (bspw. Qualitatssicherung,Konfigurationsmanagement)

3.5 Mitarbeiter

Anzahl und Typen der notwendigen Mitarbeiter; erforderlicheFahigkeiten, Beginn und Dauer der Mitarbeit; Methoden zurAnwerbung, Ausbildung, Bindung und Ausgliederung von Mitarbeitern




Technische Prozesse

4.1 Methoden, Werkzeuge und Techniken

Entwicklungsplattform, Entwicklungsmethode, Programmiersprachesowie andere Notationen, Techniken und Methoden, um das Systemund andere auszuliefernde Produkte zu spezifizieren, entwerfen,konstruieren, testen, integrieren, dokumentieren, modifizieren oderpflegen;technische Standards, Richtlinien, Zertifizierungskriterien

4.2 Dokumentationsplan

Anforderungen an die Dokumentation, Meilensteine, Baselines, Reviewsund Abnahme der Software-Dokumentation;Style-Guide, Namenskonventionen, Dokumentationsformate

4.3 Unterstutzende Projektfunktionen

z.B. Konfigurationsmanagement und Qualitatssicherungmit Verantwortlichkeiten, Ressourcen, Zeitplanen und Budget




Arbeitspakete, Zeitplan und Budget

5.1 Arbeitspakete

eindeutig identifizierbar (z.B. mit Nummer);Zerlegung der Arbeitspakete

5.2 Abhangigkeiten

Abhangigkeiten zwischen Arbeitspaketen und zu externen Elementen;Reihenfolge der Abarbeitung

5.3 Ressourcenanforderung

Dauer und Ressourcen;Beispiele: Anzahl und Qualifikation des Personals, Hardware,unterstutzende Software, Buro- und Laborraume, Reisekosten,Wartungskosten

5.4 Zuteilung des Budgets und der Ressourcen auf Projektfunktionen undAktivitaten

5.5 Zeitplan




Beispiele fur zusatzliche Elemente:

Managementplane fur Unterauftragsnehmer

Ausbildungsplane

Beschaffungsplane fur Hardware

Raumplane

Installationsplane

Plane fur die Konvertierung von Daten

Plane fur die Ubergabe des Systems (intern, extern)

Plane fur die Wartung und Evolution



Zeitplan: Aktivitaten und Dauer (Gantt-Diagramme)



20

09

-02

-09

Software-Projekt

Planung

Zeitplan


Die Gantt-Notation ist nach ihrem Erfinder, Henry L. Gantt (1917), benannt. Sie beschreibt kausaleAbhangigkeiten einzelner Aktivitaten sowie deren zeitlichen Verlauf.Das Projekt wird zunachst in einzelne Aktivitaten gegliedert. Deren Aufwand wird geschatzt. Mogliche Aktivitatenbehandeln wir in spateren Kapiteln.Die Granularitat der Aktivitaten muss angemessen sein. Die in diesem Beispiel gewahlte ist es sicher nicht. Jedetaillierter die Angabe desto leichter fallt die Schatzung (und desto aufwandiger die Planung; was sich jedoch inder Regel auszahlt). “Anfangern” ist eine moglichst feingranulare Darstellung zu empfehlen, da ihre Schatzungdadurch zuverlassiger wird.


Zeitplan: Meilensteine



20

09

-02

-09

Software-Projekt

Planung

Zeitplan


An verschiedenen Zeitpunkten des Projekts werden Meilensteine gesetzt.Ein Meilenstein ist ein Zeitpunkt, zu dem ein prufbares Ergebnis vorliegen muss.Meilensteine erlauben die Beobachtung des Projektfortschritts. Die Projektverfolgung und die Qualitatssicherungwerden interne Meilensteine setzen, also solche die nur dem Projekt bekannt sind, wie zum Beispiel das Review desEntwurfs. Zumindest bei jeder Ubergabe eines Zwischenprodukts (Entwurfsdokument, Quellcode etc.) sollte ein

Meilenstein definiert werden, der die Ubergebenden und Empfanger des Zwischenprodukts einbezieht. DerMeilenstein legt die Kriterien fur eine erfolgreiche Ubergabe fest.Externe Meilensteine involvieren den Kunden, z.B. die Abnahme der Spezifikation und der Akzeptanztest.


Zeitplan: Abhangigkeiten



20

09

-02

-09

Software-Projekt

Planung

Zeitplan


Zwischen den Aktivitaten existieren kausale Abhangigkeiten, die festgelegt werden mussen. Beispielsweise kann nurgetestet werden, wenn der Quellcode existiert.Die kausalen Abhangigkeiten fuhren zu einer partiellen Sequenzialisierung der Aktivitaten.


Zeitplan: Verfeinerung



20

09

-02

-09

Software-Projekt

Planung

Zeitplan


Grobgranulare Aktivitaten sollten verfeinert werden (siehe oben). Die Verfeinerung erlaubt auch eine getreuereDarstellung der Abhangigkeiten zwischen den Aktivitaten. So konnen zum Beispiel Testfalle fur den Black-Box-Test(siehe das spatere Kapitel uber Tests) bereits beim Vorliegen der Spezifikation vorbereitet werden.Dadurch kann die Moglichkeit zur Parallelisierung der Aktivitaten erhoht werden.


Zeitplan: Ressourcen



20

09

-02

-09

Software-Projekt

Planung

Zeitplan


Ressourcen im Software-Projekt sind in der Regel menschliche Wesen. Bei der Entwicklung eingebetteter Systemeist z.B. auch die Zielhardware eine Ressource, die eingeplant werden muss. In vielen Fallen wird sie parallel zurSoftware entwickelt.Der Kunde ist eine wichtige Ressource, die eingeplant werden muss, und selten verfugbar ist.Der Begriff “Ressource” auf Menschen angewandt klingt sehr technokratisch. Das ist hier nicht so gemeint.


Zeitplan: Einplanung der Ressourcen



20

09

-02

-09

Software-Projekt

Planung

Zeitplan


Schließlich werden die Ressourcen den Aktivitaten zugewiesen. Dadurch kann sich die Dauer von Aktivitatenverlangern oder verkurzen. Sie verlangern sich zum Beispiel, weil ein Entwickler auch fur quasi-zeitgleicheAktivitaten eingeplant wurde und selbstverstandlich eine begrenzte wochentliche Arbeitszeit hat. Sie verkurzt sich,wenn mehrere Entwickler einer Aktivitat zugeordnet werden. Aber Achtung! Im Gegensatz zu anderen Projektengilt im Software-Projekt nicht:

Dauer = AufwandAnzahl Personen

Je mehr Personen an einer Aktivitat beteiligt sind desto hoher ist der Aufwand fur Kommunikation undAbstimmung. Statt dessen gilt der Rat: Weniger und bessere Leute nehmen!Ein noch haufiger Irrglaube ist, dass man durch spate Hinzunahme zusatzlicher Leute einen in Schieflage geratenenPlan noch einhalten kann. Der Aufwand erhoht sich dann nicht nur durch erhohte Kommunikation, sondern auchdurch die Einarbeitung der Neuen.


Kritischer Pfad

Definition

Kritischer Pfad: die von der Dauer her langste Kette von Aktivitaten.

bestimmt die Dauer des Projekts;

Verspatungen in dieser Kette schlagen sich auf die Dauer des Projektsnieder;

muss wahrend des Projektverlaufs stets im Auge behalten werden.



Geschriebene Codezeilen im SWP 05/06

0

2500

5000

7500

10000

12500

15000

17500

20000

22500

25000

27500

LOC pro Gruppe

TestCode

lila = Testcode, orange = Produktionscode



Aufwandsverteilung im SWP 05/06

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

0

100

200

300

400

500

600

700

800

900

1000

1100

1200

1300

Aufwand nach Phasen

Aufw

and/

h



Note versus Aufwand

1 1,5 2 2,5 3 3,5 40

500

1000

1500

2000

2500

3000

3500

Aufwand zu Note

Note

Auf

wan

d/h



Planung: Soll und Ist

0 1000 2000 3000 4000 5000 60000

1000

2000

3000

4000

5000

6000

Plan zu IstStunden

geplante Stunden

tats

ächl

iche

Stu

nden



Arbeitsstunden pro Tag

0

100

200

300

400

500

600

700

800

900

1000

1100

Stunden nach Tag

Tag der Projektlaufzeit

Ges

amts

tund

en



Risiken

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

– Gilb (1988)

Definition

Ein Risiko ist ein Ereignis, dessen Eintreten den Erfolg des Projektsentscheidend behindern kann.Quantifizierte Risikohohe = Eintrittswahrscheinlichkeit × max.Schadenshohe

Risikomanagement kummert sich um Risiken, bevor sie auftreten.Krisenmanagement kummert sich um aufgetretene Risiken.



Risiko-Management

Risikoanalyse

Identifizierung der Risiken

Einschatzung der Eintrittswahrscheinlichkeit

Einschatzung des potentiellen Schadens

Risikomaßnahmen: Planung von Gegenmaßnahmen

Vermeidung: Unterlassung der Aktivitat

Verminderung/Begrenzung auf akzeptables Maß, z.B. Streuung oderHaftung bis zu einem Limit

Abwalzung: z.B. Unterauftragnehmer

Akzeptanz, wenn Kosten/Nutzen im Verhaltnis stehen

Risiko-Controlling: Monitoring wahrend 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

Umfeldabhangig

Organisatorische Einbettung

Politik

Recht

Kultur

z.B. Verschiebung vonPrioritaten

z.B. Abhangigkeit zu anderenProjekten

→ Historie: aus abgeschlossenen Projekten lernen


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

Umfeldabhangig

Organisatorische Einbettung

Politik

Recht

Kultur

z.B. Verschiebung vonPrioritaten

z.B. Abhangigkeit zu anderenProjekten

→ Historie: aus abgeschlossenen Projekten lernen

20

09

-02

-09

Software-Projekt

Planung

Erfahrungen aus dem SWP 05/06

Risiken im Software-Projekt

Zu Risiken und Nebenwirkungen fragen Sie Ihren

. . . gesunden Menschenverstand, erfahrene Software-Entwickler, die Tageszeitung, die Literatur uber

Softwaretechnik . . .


Personalausfall

0 1 2 3 4 5 split0%

5%

10%

15%

20%

25%

30%

35%

40%

Personalausfall

Ausfälle

Häu

figke

it



Note versus Personalausfall

0 1 2 3 4 5 split1

1,5

2

2,5

3

3,5

4

Note nach Personalausfall

Ausfälle

Dur

chsc

hnitt

snot

e



Projektabbruch

31% aller Software-Projekte werden vor Abschluss abgebrochen; weitere53% sprengen den Zeit- oder Kostenrahmen oder liefern nicht die volleFunktionalitat (Standish Group 1994)8

Gilt: Abbruch = Misserfolg wegen mangelhaftem Management?

8Dieser Bericht ist nicht unumstritten. Es gibt eine Reihe anderer Untersuchungenmit unterschiedlichen Ergebnissen Buschermohle u. a. (2006); Sauer und Cuthbertson(2003); Standish Group (2004)


Projektabbruch

31% aller Software-Projekte werden vor Abschluss abgebrochen; weitere53% sprengen den Zeit- oder Kostenrahmen oder liefern nicht die volleFunktionalitat (Standish Group 1994)8

Gilt: Abbruch = Misserfolg wegen mangelhaftem Management?

8Dieser Bericht ist nicht unumstritten. Es gibt eine Reihe anderer Untersuchungenmit unterschiedlichen Ergebnissen Buschermohle u. a. (2006); Sauer und Cuthbertson(2003); Standish Group (2004)

20

09

-02

-09

Software-Projekt

Planung

Allgemeine Risiken in einem Software-Projekt

Projektabbruch

Die Statistik uber den Abbruch von Projekten legt die Folgerung nahe, dass die Projekte abgebrochen wurden, weilsie schlecht gefuhrt wurden. Diese Implikation ist falsch und gefahrlich. Sie ist falsch, weil viele gut gefuhrteProjekte abgebrochen werden, weil sich ihre ursprunglichen Annahmen geandert haben. Sie werden ausvertretbarem Grund beendet. Dies ist vor allem in Feldern mit schnellem Wandel haufig anzutreffen.Die Implikation ist gefahrlich, weil Projektmanager sich der Verfuhrung konfrontiert sehen, ein eigentlich obsoletesProjekt weiterzufuhren, um nicht als Versager dazustehen. Es gibt oft gute, vertretbare Grunde, ein Projektabzubrechen. Der Abbruch ist dann weiser als die Fortfuhrung.


Grunde fur Projektabbruch nach Boehm (2000)

Unvollstandige Anforderungen (13 %9):

Ursache beischlecht gefuhrtem Projekt gut gefuhrtem Projekt

meistens haufig

Projekt startet ohne klare Idee derBedurfnisse und Prioritaten derStakeholder.

Stakeholder konnen sich nicht aufAnforderungen einigen.

9relativ zu den abgebrochenen ProjektenRainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 93 / 634


Unvollstandige Anforderungen (13 %9):


meistens haufig

Projekt startet ohne klare Idee derBedurfnisse und Prioritaten derStakeholder.

Stakeholder konnen sich nicht aufAnforderungen einigen.

9relativ zu den abgebrochenen Projekten

20

09

-02

-09

Software-Projekt

Planung



Die angegebenen Zahlen hat Barry Boehm anhand von Projekten ermittelt, bei denen er selbst involviert war (5-6Projekte fur digitale Bibliotheken pro Jahr, Begutachtung von ungefahr 20 Berichten uber abgebrocheneIndustrieprojekte, die unter Beteiligung von den 30 Angehorigen des Center for Software Engineering, das er leitet.Andere Autoren berichten von Abbruchraten mit 40% und 50%, insbesondere fur Gebiete, in denen neue Produkteeingefuhrt werden Hayes (1997).Die meisten hier genannten Ursachen fur Abbruche stellen handfeste Risiken fur Ihr Software-Projekt dar, denen Siesich bewusst sein sollten. Die Fehler, die bei schlecht gefuhrten Projekten gemacht werden, sollten Sie meiden.Fur Sie folgt hier: Machen Sie die Anforderungen und Prioritaten Ihres Kunden fest, bevor Sie anfangen zuentwerfen und zu implementieren.



Mangelhafte Einbeziehung der Benutzer (12 %):


gleich haufig

Projekt kommuniziert nicht mitBenutzer.

Benutzer kommuniziert nicht mitProjekt.



Mangelhafte Einbeziehung der Benutzer (12 %):


gleich haufig

Projekt kommuniziert nicht mitBenutzer.

Benutzer kommuniziert nicht mitProjekt.

20

09

-02

-09

Software-Projekt

Planung



Fur Sie folgt hier: Suchen Sie Ihren Kunden auf. Beziehen Sie ihn bei der Anforderungsanalyse ein. Machen Sie eineanstandige und umfassende Ist-Analyse. Lassen Sie den Kunden das Pflichtenheft prufen (verwenden Sie dabei eineihm passende Terminologie; definieren Sie ein Begriffslexikon). Entwickeln Sie Prototypen, die Sie dem Kundenvorfuhren. Halten Sie Kontakt mit dem Kunden auch wahrend der Implementierungsphase. Prufen Sie periodisch,ob sich seine Prioritaten und Anforderungen geandert haben.



Mangel an Ressourcen (11 %):


gleich haufig; schlecht gefuhrte Projekte haben jedoch niedrigerenGeschaftswert und sind tendenziell eher betroffen

Projekt hat wenig Geschaftswert.Budgeteinschnitte, Verkleinerungen, Repriorisierungen.



Mangel an Ressourcen (11 %):


gleich haufig; schlecht gefuhrte Projekte haben jedoch niedrigerenGeschaftswert und sind tendenziell eher betroffen

Projekt hat wenig Geschaftswert.Budgeteinschnitte, Verkleinerungen, Repriorisierungen.2

00

9-0

2-0

9

Software-Projekt

Planung



Fur Sie folgt hier: Ihre Ressource ist im Wesentlichen die Zeit; insbesondere auch die Zeit Ihrer Mitstreiter imProjekt. Deren Prioritaten sind nicht immer die Ihrigen. Manche Projektteilnehmer werden es an Einsatz vermissenlassen.Weitere potenziell mangelnde Ressourcen sind Rechner, Netzwerke und Software-Werkzeuge, die Sie fur Ihr Projektbenotigen.



Unrealistische Erwartungen (10 %):


gleich haufig

Machbarkeit wurde nicht gepruft. Machbarkeitsprufung fiel negativaus.



Unrealistische Erwartungen (10 %):


gleich haufig

Machbarkeit wurde nicht gepruft. Machbarkeitsprufung fiel negativaus.

20

09

-02

-09

Software-Projekt

Planung



Unrealistische Erwartungen des Benutzers liegen in dessen Natur. Er kennt selten technische Randbedingungen undGrenzen der Berechenbarkeit. Software gilt als beliebig flexibel: “Ich dachte, da mussen Sie nur ein Bit umkippen.”.Und selbstverstandlich will er stets noch einmal uber den Preis reden.Die Tutoren werden versuchen, den Benutzer realistisch zu simulieren.Aber auch Sie selbst konnten zu unrealistischen Erwartungen neigen. Sie sind moglicherweise nicht mit demAnwendungsbereich vertraut genug oder unterschatzen den Aufwand an Kommunikation, den einMehrpersonenprojekt mit sich bringt, und den Aufwand fur die Analyse, den Entwurf und den Test.Letztlich steht Ihnen circa ein Tag pro Woche fur das Projekt zur Verfugung, und diese Projekttage sindunterbrochen von vielen anderen Aktivitaten.Fur Sie folgt hier: Klopfen Sie fruhzeitig die Anforderungen des Kunden auf Machbarkeit ab. Erstellen SiePrototypen, um die Machbarkeit kritischer Anforderungen zu uberprufen. Planen Sie realistisch. Geben sie nicht inallen Punkten dem Kunden nach, wenn dieser seine Wunsche außert. Es gilt “quid pro quo”: etwas fur etwas. Willer X, muss er sich bei Y beschranken. Verlangen Sie ihm Prioritaten ab.



Mangelnde Unterstutzung bei der Ausfuhrung (9 %):Ursache bei

schlecht gefuhrtem Projekt gut gefuhrtem Projekt

meistens haufig

Manager machen unverifizierteAnnahmen uber Unterstutzung (z.B.verlassen sich darauf, dass andereInitiativen repriorisiert werden, umProjekt zu unterstutzen).

Unterstutzung wird entzogen(z.B. Verantwortliche werdenausgetauscht; neueVerantwortliche haben anderePrioritaten und Agenda).



Mangelnde Unterstutzung bei der Ausfuhrung (9 %):Ursache bei


meistens haufig

Manager machen unverifizierteAnnahmen uber Unterstutzung (z.B.verlassen sich darauf, dass andereInitiativen repriorisiert werden, umProjekt zu unterstutzen).

Unterstutzung wird entzogen(z.B. Verantwortliche werdenausgetauscht; neueVerantwortliche haben anderePrioritaten und Agenda).

20

09

-02

-09

Software-Projekt

Planung



Sie mussen sich mit Mitgliedern Ihrer Gruppe und auch mit anderen Gruppen auseinander setzen. Der Betreuer/dieBetreuerin betreut mehrere Gruppen und hat noch viele andere Pflichten. Teilnehmer wie Betreuer sindmoglicherweise zeitweise oder auch dauerhaft nicht verfugbar.Fur Sie folgt hier: Seien Sie explizit daruber, was Sie von anderen erwarten und auch bis wann Sie etwas erwarten.Kommunizieren Sie!



Anforderungen andern sich (9%):Ursache bei


meistens nicht selten

Anderungen werden akzeptiert, ohnedass Budget und Projektplanangepasst werden.

Folgekosten der Anderunguberwiegen den Nutzen desProjekts.



Anforderungen andern sich (9%):Ursache bei


meistens nicht selten

Anderungen werden akzeptiert, ohnedass Budget und Projektplanangepasst werden.

Folgekosten der Anderunguberwiegen den Nutzen desProjekts.

20

09

-02

-09

Software-Projekt

Planung



Die Anforderungen sind am Anfang nicht klar verstanden. Der Kunde selbst wird sich im Laufe des Projekt klarerdaruber, was er eigentlich will. Rahmenbedingungen andern sich.Die Anforderungen sind selten als stabil zu betrachten.Fur Sie folgt hier: Halten Sie vertraglich fest, wie Sie und der Kunde mit Anderungen umgehen wollen. AntizipierenSie mogliche Anderungen. Uberlegen Sie sich gut, welche Anderung Sie akzeptieren. Seien Sie sich uber dieKonsequenzen einer Anderung im Klaren.



Mangelhafte Planung (8%):Ursache bei


immer —

Projektmanager haben keineAhnung, wo sie sich befinden undwann das Projekt fertig wird.



Mangelhafte Planung (8%):Ursache bei


immer —

Projektmanager haben keineAhnung, wo sie sich befinden undwann das Projekt fertig wird.

20

09

-02

-09

Software-Projekt

Planung



Sie sind weder mit dem Anwendungsbereich noch mit einem Projekt dieser Art vertraut. Sie werden es besondersschwer haben.Fur Sie folgt: Seien Sie nicht zu optimistisch. Unterschatzen Sie nicht das Problem, insbesondere in seinen Details,und uberschatzen Sie nicht sich selbst.Planen Sie und seien Sie sich zu jedem Zeitpunkt daruber im Klaren, wo sie sich tatsachlich befinden und was IhrPlanziel war. Seien Sie vorsichtig in dem Glauben “Das holen wir spater wieder ein”.Wenn Soll und Ist zu weit auseinander klaffen, reagieren Sie. Sprechen Sie fruhzeitig mit Ihrem Kunden ubermogliche Einschrankungen bei der Leistung. Der Kunde ist sehr wahrscheinlich besser bedient, wenn er wenigstenetwas bekommt, und nicht gar nichts. Das Vertrauensverhaltnis ware auf immer zerruttet, wenn Sie ihm erst amTag der Auslieferung uber den wahren Zustand Ihres Projekts aufklaren.Denken Sie an die Manager von TollCollect, die noch einen Monat vor der geplanten Einfuhrung behauptet haben,sie wurden den Termin halten.



Kein Nutzen (8%):Ursache bei


gleich haufig in Feldern mit schnellem Wandel

Gute Projektmanager verfolgenTrends und erkennennachlassenden Nutzen fruher; siereagieren fruhzeitiger mitAbbruch.




Mangelndes IT-Management (6%):Ursache bei


immer —

Offensichtlich mangelhaftes Manage-ment.



Mangelndes IT-Management (6%):Ursache bei


immer —

Offensichtlich mangelhaftes Manage-ment.

20

09

-02

-09

Software-Projekt

Planung



Gehen Sie in die Vorlesung. Die Vorlesung mochte 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 uber das Problem. EinProjektleiter ist kein General, sondern ein Dienstleister fur die Projektmitglieder. Er soll die Ubersicht wahren unddas Projekt zusammenhalten. Schafft er dies nicht, obwohl Sie mit ihm daruber geredet haben, wechseln Sie Ihn aus.



Mangelndes Verstandnis der Technologie (4%):Ursache bei


allermeistens —

Fehlende Kenntnisse der Entwicklerund Manager; Projekte, die niemalshatten begonnen werden sollen.



Mangelndes Verstandnis der Technologie (4%):Ursache bei


allermeistens —

Fehlende Kenntnisse der Entwicklerund Manager; Projekte, die niemalshatten begonnen werden sollen.

20

09

-02

-09

Software-Projekt

Planung



Bilden Sie Experten, die sich mit spezifischen technischen Problemen gezielt auseinander setzen. Bauen SiePrototypen in einer Technologie, die Sie noch nicht beherrschen. Drehen Sie nicht gleichzeitig an zu vielenSchrauben: Nicht allen Technologien gleichzeitig hinterherlaufen, sondern eine nach der anderen inkrementelleinfuhren. Betrachten Sie das Problem unbekannter Technologien fruhzeitig in ihrem Projektplan (raumen Siezusatzliche Zeit hierfur ein). Bedenken Sie, dass es nicht ausreicht, mehrere Technologien isoliert zu beherrschen.Sie konnten Ihr blaues Wunder erleben, wenn Sie versuchen, diese Technologien miteinander zu integrieren.


Menschliche Wahrnehmung von Risiken

Selbstgewahlte Gefahren erscheinen geringer als aufgezwungene.

Prinzipiell kontrollierbare Risiken sind akzeptabler als solche, auf diewir scheinbar keinen Einfluss haben.

Naturliche Risiken werden eher hingenommen als von Menschengeschaffene.

Katastrophen alarmieren uns mehr als der alltagliche Wahnsinn.

Risiken, die von schwer fassbaren Techniken ausgehen, werden eherwahrgenommen als die von vertrauten Techniken.

Schlechte Nachrichten werden eher geglaubt als positive.



Selbstgewahlte Gefahren erscheinen geringer als aufgezwungene.

Prinzipiell kontrollierbare Risiken sind akzeptabler als solche, auf diewir scheinbar keinen Einfluss haben.

Naturliche Risiken werden eher hingenommen als von Menschengeschaffene.

Katastrophen alarmieren uns mehr als der alltagliche Wahnsinn.

Risiken, die von schwer fassbaren Techniken ausgehen, werden eherwahrgenommen als die von vertrauten Techniken.

Schlechte Nachrichten werden eher geglaubt als positive.

20

09

-02

-09

Software-Projekt

Planung



Allgemein:

• Die Risiken bestimmter Sportarten wie Skifahren oder Reiten gehen wir bewusst ein. Dagegen wehren wir uns gegenKonservierungsstoffe in der Nahrung.

• Fettes, nahrstoffarmes Essen ist beliebt, wahrend Leitungswasser auch dann gemieden wird, wenn die Trinkqualitatgarantiert ist.

• In der Erde vorkommendes Radon erscheint uns harmlos im Vergleich zur selben Strahlungsintensitat aus kunstlichenQuellen.

• Werden nach einem Schiffsungluck Giftbeutel oder Olklumpen an die Strande geschwemmt, ist die Aufregung groß,wahrend die schleichende Vergiftung der Meere kaum zur Kenntnis genommen wird.

• Eine Mullverbrennungsanlage mit relativ geringen Emissionen wird bekampft, der Autoverkehr hingegen verteidigt.

• Sturme und Uberschwemmungen gelten als Beweis fur den Treibhauseffekt, doch die geringer gewordene Verschmutzungdes Rheins halten viele fur 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ßenverhaltnisse erscheinen uns harmlos im Vergleich zu Fehlern in der Software des Bremssystems imAuto.

• Der Projektabbruch alarmiert uns mehr als die schleichende Verschlechterung der Qualitat, die wir ausliefern.

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

• Das Gerucht, dass das Projekt in Schieflage geraten ist, macht hellhorig; eine Aussage, die Deadline werde eingehalten,glauben wir gerne.


Wiederholungsfragen I

Erstellen Sie einen Projektplan fur ein Software-Projekt.

Was sind die Elemente eines Projekts? Insbesondere was ist einMeilenstein 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 derenBesonderheiten?

Was sind typische Risiken in einem Software-Projekt? Wie geht manmit ihnen um?

Was sind die Besonderheiten eines Software-Projekts?



Wiederholungsfragen II

Welche Risiken sind typisch fur Software-Projekte? Wie ist mit ihnenumzugehen?

Erlautern Sie Risiko-Management.


Anforderungsanalyse

Anforderungsanalyse

Ziele und InhaltAngestrebte ResultateAktivitaten der Software-EntwicklungAblaufZeitplanAnmeldungScheinbedingungenProjektplanVorstellung der AufgabeKontaktdatenRessourcenLehrbucherEigenschaften von SoftwareSoftware-LebenszyklusSoftware-EvolutionEntstehung der SoftwaretechnikMerkmale der SoftwaretechnikProjektVorgehenInhaltZeitplanPlanung und Aufwand im SWP 05/06RisikenRisiko-ManagementErfahrungen aus dem SWP 05/06Allgemeine Risiken in einem Software-ProjektWiederholungsfragen

4 AnforderungsanalyseLernzieleHerausforderungenAktivitatenIst-Analyse






Anforderungsanalyse

Lernziele

Ist- und Soll-Zustand ermitteln konnen

Anforderungsspezifikation schreiben konnen

Anforderungsspezifikation begutachten konnen


Lernziele

Ist- und Soll-Zustand ermitteln konnen

Anforderungsspezifikation schreiben konnen

Anforderungsspezifikation begutachten konnen

20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Lernziele

Lernziele

Bevor ein System implementiert werden kann, mussen die Anforderungen an das System erhoben werden. DieserAufgabe widmet sich die Anforderungsanalyse. Ihr Ziel ist es, einen moglichst genauen und vollstandigen Katalogvon Anforderungen an ein System zu erfassen und zu beschreiben. Die Anforderungen beschreiben einSoll-Konzept, das Verbesserung fur 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 desIst-Zustands und seiner Probleme Teil einer Anforderungsanalyse.

Das Ergebnis der Anforderungsanalyse ist der Katalog der Anforderungen. In welcher Form dieser Katalogbeschrieben ist, hangt vom Vorgehensmodell ab. Bei dokumentengetriebenen Vorgehensmodellen – wie demWasserfallmodell – werden die Anforderungen in Form einer Anforderungsspezifikation schriftlich festgehalten. Invielen agilen Vorgehensmodellen erfolgt die Anforderungsspezifikation als Zuruf des Kunden.

Wann und wie oft die Anforderungsanalyse durchgefuhrt wird, hangt ebenso stark vom Vorgehensmodell zurSoftwareentwicklung ab. Beim Wasserfallmodell wird die Anforderungsanalyse nur einmal und ganz zu Anfangdurchgefuhrt. Beim inkrementellen Vorgehen, bei dem die Entwicklung in kleinen abgeschlossenen Inkrementen deszu entwickelnden Systems erfolgt, wird sie jedes Mal wieder vor der Entwicklung jedes Inkrements durchgefuhrt.Beim Extreme-Programming hat man durch die Prasenz eines Kundenvertreters vor Ort eine fast kontinuierlichstattfindende Anforderungsanalyse.

In diesem Modul geht es um die Durchfuhrung der Anforderungsanalyse. Wir streben hier die schriftlicheDokumentation der Anforderungen in Form einer Anforderungsspezifikation an, da dies in den meisten Fallen eineReihe von Problemen vermeidet. Der Inhalt dieses Abschnitts ist jedoch auch fur agiles Vorgehen ohne schriftlicheSpezifikation der Anforderungen relevant, weil auch orale Uberlieferung zu allen Aspekten derAnforderungsspezifikation Stellung nehmen muss.

Ubersicht:

Zunachst widmen wir uns der Frage, warum die Anforderungsanalyse so wichtig aber leider auch schwierig ist.Dann lernen wir die grundsatzlichen Schritte der Anforderungsanalyse kennen. Dazu gehoren die Erfassung desIst-Zustands und seiner Probleme durch die Ist-Analyse, die angestrebte Verbesserung durch ein Soll-Konzept durchdie Soll-Analyse und die genaue und vollstandige Beschreibung der Anforderungen in Form einerAnforderungsspezifikation. Wir vertiefen alle Schritte und lernen Techniken fur diese einzelnen Schritte kennen.

Anforderungsanalyse

Wegweiser

Herausforderungen

Warum sind die Anforderungen so kritisch?Warum ist ihre Erhebung so schwer?


Anforderungsanalyse

Kosten fur Anderungen

1,5 − 6 x

60 − 100 x

1 x

Kosten für Änderung

nach AuslieferungDefinition Entwicklung

Zeit

Pressman (2003)



1,5 − 6 x

60 − 100 x

1 x

Kosten für Änderung

nach AuslieferungDefinition Entwicklung

Zeit

Pressman (2003)

20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Herausforderungen


Die Anforderunganalyse ist von zentraler Bedeutung fur den Erfolg eines Projektes. Passieren hier Fehler, entstehtein System, was an den Bedurfnissen des Kunden vorbei entwickelt und damit unbrauchbar wird. Fehler in derAnforderungsanalyse konnen zwar oft noch in spateren Phasen entdeckt und dann korrigiert werden, die Korrekturdieser Fehler ist jedoch meist mit einem erheblichen Mehraufwand verbunden. Pressman (2003) berichtet von denrelativen Kosten fur Korrekturen von Fehlern in der Anforderungsanalyse in Abhangigkeit vom Zeitpunkt, zu demdiese Fehler bekannt werden. Findet man einen Fehler der Anforderungsspezifikation in spateren Aktivitaten derEntwicklung, also beim Entwurf, der Implementierung oder dem Test noch vor Auslieferung, dann konnen dieKosten um einen Faktor 1,5 bis 6 hoher sein als die Korrekturkosten, die entstanden waren, hatte man den Fehlernoch wahrend der Anforderungsanalyse gefunden. Wird der Fehler noch spater gefunden, also nach der Auslieferungder Software, kann er gar um einen Faktor 60 bis 100 hoher sein. Es entstehen dann nicht nur zusatzliche Kostenfur die Nachbesserung von Anforderungsspezifikation und Entwurf, Fehlerkorrektur und Restrukturierung derImplementierung sowie Wiederholung des Tests. Es entstehen daruber hinaus auch Kosten fur die Beseitigung vonAuswirkungen des Fehlers. Hat eine eingebettete Software in einem Automobil beispielsweise einen Fehler, somussen alle Fahrzeuge in der Werkstatt uberholt werden. Dadurch entstehen hohe direkte Kosten, aber auch nochindirekte Kosten durch den Imageverlust des Automobilherstellers, wenn sich der Imageverlust auf dieVerkaufszahlen auswirkt.

Anforderungsanalyse

Warum die Anforderungsanalyse so schwer ist

Kunden wissen haufig nicht, was sie genau wollen, bzw. konnen esnicht genau außern

Kunden sprechen ihre Sprache, die von Entwicklern nicht verstandenwird

unterschiedliche Kundengruppen haben unterschiedlicheAnforderungen, die sich mitunter widersprechen

politische Entscheidungen konnen Anforderungen beeinflussen

die Welt andert sich, die Anforderungen an die Software auch; auchwahrend der Entwicklung

– Sommerville (2004)



Kunden wissen haufig nicht, was sie genau wollen, bzw. konnen esnicht genau außern

Kunden sprechen ihre Sprache, die von Entwicklern nicht verstandenwird

unterschiedliche Kundengruppen haben unterschiedlicheAnforderungen, die sich mitunter widersprechen

politische Entscheidungen konnen Anforderungen beeinflussen

die Welt andert sich, die Anforderungen an die Software auch; auchwahrend der Entwicklung

– Sommerville (2004)20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Herausforderungen


Die Anforderungsanalyse ist schwierig, so dass die Wahrscheinlichkeit, dass wir Fehler machen, recht hoch ist.Sommerville (2004) nennt hierfur eine Reihe von Grunden:

• Die Kunden wissen haufig nicht genau, was sie genau wollen, beziehungsweise konnen es nicht genau außern.

• Kunden sind Experten in ihrem Anwendungsbereich, haben jedoch in der Regel wenig Kenntnisse in der Informatik. Beiden Informatikern verhalt es sich meist umgekehrt. Es treffen also Menschen aufeinander, die erst zu einer gemeinsamenSprache und einem gemeinsamen Verstandnis finden mussen.

• Es gibt meist nicht den Kunden oder Benutzer, sondern sehr viele mit recht unterschiedlichen Anforderungen, die sichnicht selten widersprechen. Bei der Anforderungsanalyse mussen also Konflikte aufgedeckt und Kompromissegeschlossen werden.

• Die Anforderungen werden nicht selten durch politische Entscheidungen beeinflusst. Das aus organisatorischer undtechnischer Sicht bestmogliche Soll-Konzept kann dann immer noch aus rein politischen Grunden scheitern.Beispielsweise sieht der Abteilungsleiter durch eine Anderung im Arbeitsfluss dank softwaretechnischer Unterstutzungplotzlich seinen Einfluss gefahrdet und boykottiert die angestrebte Losung.

• Die Welt ist einem standigen Wandel unterworfen. Weil sich die Welt andert, andern sich notwendigerweise auch dieAnforderungen an die Software, die einen Arbeitsfluss dieser Welt automatisiert. Das geschieht sicherlich in der Zeitnach Auslieferung der Software in der so genannten Wartungsphase, d.h. wahrend ihres Einsatzes, aber nicht selten auchschon wahrend der Entwicklung. Mit der Anforderungsanalyse ist man also selten fertig. Man sollte deshalb idealerweisewahrscheinliche zukunftige Anderungen vorwegsehen und schon in der initialen Entwicklung berucksichtigen.

Anforderungsanalyse

Bewusstseinsebenen

bewusstes Wissen (20-30%)

Wissen, uber das man sich im Klaren ist oder das in seiner vollenBedeutung klar erkannt wird

unbewusstes Wissen (≤40%)

Wissen, das sich dem Bewusstsein im Moment nicht darbietet, aberdennoch handlungsbestimmend ist, und potenziell aufgerufen werdenkann

unterbewusstes Wissen

unbekannte Wunsche, die erst von außen herangetragen werdenmussen, um als Anforderungen erkannt zu werden


Bewusstseinsebenen







20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Herausforderungen

Bewusstseinsebenen

Dass Benutzer oft nicht genau wissen, was sie wollen beziehungsweise es nicht sagen, liegt meist nicht an einemMangel an Kenntnis, Vorstellungsvermogen oder Kooperationsbereitschaft, sondern an der Gestalt menschlichenWissens. Menschliches Wissen lasst sich unterteilen in drei ungefahr gleich große Bereiche.

Das bewusste Wissen ist solches Wissen, uber das man sich im Klaren ist oder das in seiner vollen Bedeutung klarerkannt wird. Fragt man einen Radfahrer danach, wie man mit einem Fahrrad eine Kurve fahrt, so wird er einemsicherlich antworten, dass man hierfur den Lenker einschlagen muss. Das bewusste Wissen ist durch direkte Fragenunmittelbar zuganglich.

Das unbewusste Wissen ist solches Wissen, das sich dem Bewusstsein im Moment nicht darbietet, aber dennochhandlungsbestimmend ist und potenziell aufgerufen werden kann. Wird man denselben Radfahrer daraufaufmerksam machen, dass man beobachtet habe, dass er seinen Korper neigt, bevor er den Lenker zur Kurveeinschlagt, wird er die maßgebende Rolle des Korpergewichtes bestatigen. An das unbewusste Wissen vermag mandurch Beobachtung und Nachfragen zu kommen.

Wahrend 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 desmenschlichen Wissens ist dem Wissenden selbst namlich gar nicht bewusst. Das unterbewusste Wissen besteht ausdem uns nicht bekannten Wissen, das dennoch fur unsere Handlungen maßgebend ist. Oft sind es Angste,unbewusste Wunsche oder Triebe, die fur uns handlungsbestimmend sind. Warum der Radfahrer in bestimmtenSituationen es scheut, eine Kurve schneller zu nehmen, hat vielleicht damit zu tun, dass er sich einmal kraftig durcheinen Sturz blamiert hat, als er einst versuchte, eine Kurve besonders schnittig zu nehmen, um seinen Freunden zuimponieren. Unbewusste Anforderungen mussen erst von außen an uns herangetragen werden, um alsAnforderungen erkannt zu werden.

Bewusstseinsebenen







20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Herausforderungen

Bewusstseinsebenen

Folgt fur den Informatiker, der eine Anforderungsanalyse durchfuhrt, nun daraus, dass er besser eine Ausbildung alsPsychoanalytiker absolvieren sollte? Wenngleich das sicherlich helfen konnte, so ist es fur unsere Zwecke meistausreichend, sich uber diese Formen des Wissens im Klaren zu sein und passende Techniken anzuwenden, um anmoglichst viel Wissen und Anforderungen zu kommen. Mit reinen Fragetechniken wird man zum uberwiegenden Teilallein das bewusste Wissen erschließen konnen. Mit Beobachtungen und Nachfragen kann man noch den Bereichdes unbewussten Wissens erfassen. Bei der Einschatzung der Aussagen eines Benutzers sollte man sich aber auchGedanken machen, warum er eine Antwort in einer bestimmten Weise geben konnte oder warum er sich auf einebestimme Art und Weise verhalt. Es konnten zum Beispiel Angste vor der Umstellung durch die softwaretechnischeLosung sein, die einen Menschen unbewusst umtreiben – seien es berechtigte Angste um den moglichen Verlust desArbeitsplatzes oder einfach nur die allgemeine Angst, durch die Neuerungen uberfordert zu werden.

Anforderungsanalyse

Basisfaktoren

Minimalanforderungen

→ Mangel fuhrt zu massiverUnzufriedenheit

→ mehr als Zufriedenheit ist nicht moglich

Leistungsfaktoren

bewusst verlangte Sonderausstattung

→ bei Erfullung: Kundenzufriedenheit

→ sonst: Unzufriedenheit

Begeisternde Faktoren

unbewusste Wunsche,nutzliche/angenehme Uberraschungen

→ steigern Zufriedenheit uberproportional

Kano-Modell

Kunde unzufriedenenttäuscht

Erwartungennicht erfüllt

Kunde sehr zufrieden,begeistert Begeisternde Faktoren

Leistungsfaktoren

Basisfaktoren

Erfüllungsgrad


Basisfaktoren




Leistungsfaktoren







Kano-Modell




Leistungsfaktoren

Basisfaktoren

Erfüllungsgrad

20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Herausforderungen

Eine gute Anforderungsanalyse ist der Grundstock fur den Erfolg. Dazu muss es uns gelingen, den Kunden mitunserem Produkt zu begeistern, indem wir auf alle seine Anforderungen eingehen und diese spater auch umsetzen.

Der Zusammenhang zwischen dem Erfullungsgrad der Anforderungen und der Begeisterung, die wir damit beimKunden wecken konnen, wird durch das Kano-Modell (Kano 1984) beschrieben. Generell gilt offensichtlich, dasswir mit einem hoheren Erfullungsgrad der Anforderungen auch eine hohere Zufriedenheit erreichen konnen. Ob eineerfullte Anforderung den Kunden zur Begeisterung treibt oder ob es fur ihn vielmehr eine Selbstverstandlichkeitdarstellt, hangt jedoch ab von der Art der Anforderung.

Die erste Kategorie von Anforderungen sind die Basisfaktoren der Software. Diese Anforderungen stellenMindestanforderungen dar, die die Software erfullen muss, damit sie eingesetzt werden kann, Werden sie nichterfullt, ist die Software unbrauchbar. Dies fuhrt zu massiver Unzufriedenheit. Da es sich um Mindestanforderungenhandelt, werden wir den Kunden selbst mit einer hundertprozentigen Erfullung allenfalls zufrieden, aber nichtbegeistern konnen.

Die Gesamtheit der Leistungsfaktoren ist die bewusst verlangte Sonderausstattung. Werden diese Anforderungenerfullt, konnen wir den Kunden mehr als nur zufrieden stellen. Werden sie nicht erfullt, ist der Kunde enttauscht –er hatte sich diese Leistungsfaktoren ja explizit gewunscht. Es droht dann Unzufriedenheit.

Den Kunden begeistern konnen wir, indem wir ihn uberraschen. Die begeisternde Faktoren erfullen ihm unbewussteWunsche oder stellen nutzliche und angenehme Uberraschungen dar. Mit diesen Faktoren konnen wir dieZufriedenheit uberproportional steigern, aber bei Nichterfullen niemals enttauschen, weil der Kunde dieseAnforderungen nicht explizit verlangt hat.

Basisfaktoren




Leistungsfaktoren







Kano-Modell




Leistungsfaktoren

Basisfaktoren

Erfüllungsgrad

20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Herausforderungen

Daraus folgt nun nicht, dass wir eigene Anforderungen hinzu erfinden sollten, von denen wir glauben, dass sie denKunden vom Hocker reißen werden. Schließlich mussen wir die Anforderungen implementieren und wenn sie vomKunden nicht bestellt sind, mussen wir dafur bezahlen. Wenn es uns aber gelingt, solche Anforderungen in derAnforderungsanalyse zu identifizieren und dem Kunden vorzuschlagen, so konnen sie zum Vertragsgegenstandwerden, fur die er gerne Geld ausgibt. Allerdings werden sie so dann schnell zu Leistungsfaktoren, die beiNichterfullung Unzufriedenheit hervor rufen. Aber zumindest kann es fur den Kunden den Ausschlag geben, sich furunsere Dienste und nicht fur die unserer Mitbewerber zu entscheiden.

Anforderungsanalyse

Wegweiser

Erhebung der Anforderungen

Was sind die wesentlichen Schritte zur Erhebung derAnforderungen?


Wegweiser

Erhebung der Anforderungen

Was sind die wesentlichen Schritte zur Erhebung derAnforderungen?

20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Aktivitaten

Wegweiser

In diesem Abschnitt wenden wir uns den einzelnen Aktivitaten der Anforderungsanalyse zu. Dazu gehoren dieIst-Analyse, die Soll-Analyse und das Festhalten der Anforderungen in Form einer Anforderungsspezifikation. DieseAktivitaten haben eine naturlichen Abfolge, weil sie voneinander kausal abhangen. Allerdings werden sie in derPraxis meist wiederholt.

Anforderungsanalyse

Schritte der Anforderungsanalyse: Ist-Analyse

Ist−Analyse

Ist−Zustand

Glossar

Ziel: Verstandnis der Welt, fur dieSoftwarelosung angestrebt wird.Haufige Fehler:

Entwickler sieht nicht, dass Kundeprimar keine Veranderung, sondernVerbesserung anstrebt.

Kunde beschreibt selten, was sich nichtandern soll (weil es gut genug ist).

Kunde 6= Endbenutzer; weiß nicht, wasdieser braucht.

Folgen von Mangeln: Eigentliches Problemwird ignoriert.Erforderlich: Beobachtungsgabe,Einfuhlungsvermogen,Kommunikationsfahigkeit.



Ist−Analyse

Ist−Zustand

Glossar

Ziel: Verstandnis der Welt, fur dieSoftwarelosung angestrebt wird.Haufige Fehler:

Entwickler sieht nicht, dass Kundeprimar keine Veranderung, sondernVerbesserung anstrebt.

Kunde beschreibt selten, was sich nichtandern soll (weil es gut genug ist).

Kunde 6= Endbenutzer; weiß nicht, wasdieser braucht.

Folgen von Mangeln: Eigentliches Problemwird ignoriert.Erforderlich: Beobachtungsgabe,Einfuhlungsvermogen,Kommunikationsfahigkeit.

20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Aktivitaten


Die Aktivitat Ist-Analyse zielt darauf ab, den Ausschnitt der Welt zu verstehen, fur den eine softwaretechnischeLosung angestrebt wird. Das heißt, wir streben an, den Ist-Zustand genau zu verstehen und zu analysieren. Uberdie Beschreibung des Ist-Zustands hinaus, entsteht in dieser Phase ein Glossar (Begriffslexikon), in dem wir dieBegriffe aus der Anwendungsdomane definieren, die der Kunde verwendet. Das Begriffslexikon ist notwendig, umUnklarheiten und Missverstandnisse auszuschließen. In der Regel sind Softwareentwickler mit den Begriffen derAnwendungsdomane nicht vertraut genug oder haben eine etwas falsche Vorstellung. Besonders problematisch sinddie Falle, in denen wir meinen zu wissen, was vermeintlich gemeint ist, aber leider daneben liegen, ohne es zumerken. Dieses Glossar wird vom Kunden gelesen und verifiziert. Es wird uber die Projektdauer gepflegt undangepasst.

Ein haufiger Fehler bei der Ist-Analyse ist es, dass wir uns nicht bewusst werden, dass der Kunde primar keineVeranderung, sondern eine Verbesserung anstrebt. Das bedeutet, dass der Kunde mit vielen Dingen so wie sie sindbereits zufrieden ist und die auch weiterhin so bleiben sollen. Der Kunde beschreibt aber selten, was sich nichtandern soll, weil es gut genug ist. Er konzentriert sich vielmehr darauf, was sich andern soll. Nichtsdestotrotzmussen wir auch die Anforderungen kennen, die ubernommen werden sollen. Wenn es darum geht, ein existierendesSoftwaresystem abzulosen, bietet sich uns eine große Chance vom existierenden System zu lernen. VieleInformatiker machen jedoch den Fehler, das existierende Systeme allerhochstens oberflachlich zu untersuchen.Dabei konnten wir den Kunden gezielt danach fragen, was wir vom existierenden System ubernehmenbeziehungsweise verbessern sollten.

Erfolgt die Ist-Analyse mangelhaft, droht die Gefahr, dass wir das eigentliche Problem ignorieren. Fur eineerfolgreiche Durchfuhrung der Ist-Analyse benotigen wir Beobachtungsgabe, Einfuhlungsvermogen undKommunikationsfahigkeit.

Anforderungsanalyse

Schritte der Anforderungsanalyse: Soll-Analyse

Soll−Analyse

Lastenheft

Ist−Analyse

Ist−Zustand

Glossar

Ziel: Aufdeckung und Verbesserungbisheriger Schwachen durch Softwarelosung.Antizipation von Anderungen.Haufige Fehler:

Entwickler gleiten in technische Detailsab.

Kunde hat keine klare Vorstellung bzw.kann sie nicht vermitteln.

Folgen von Mangeln: falsche Losung wirdspezifiziert.Erforderlich: Analytische Fahigkeitenkombiniert mit Wissen uber Machbarkeit vonSoftwarelosungen.



Soll−Analyse

Lastenheft

Ist−Analyse

Ist−Zustand

Glossar

Ziel: Aufdeckung und Verbesserungbisheriger Schwachen durch Softwarelosung.Antizipation von Anderungen.Haufige Fehler:

Entwickler gleiten in technische Detailsab.

Kunde hat keine klare Vorstellung bzw.kann sie nicht vermitteln.

Folgen von Mangeln: falsche Losung wirdspezifiziert.Erforderlich: Analytische Fahigkeitenkombiniert mit Wissen uber Machbarkeit vonSoftwarelosungen.2

00

9-0

2-0

9

Software-Projekt

Anforderungsanalyse

Aktivitaten


Auf Basis der Ergebnisse der Ist-Analyse identifiziert die Soll-Analyse die bisherigen Schwachen und erarbeitetVerbesserungsmaßnahmen. Dabei interessieren uns nicht nur die unmittelbar anstehenden Anforderungen sondernauch jene, die in absehbarer Zukunft relevant werden konnen. Wahrscheinliche zusatzliche Anforderungen an dasSystem, die in der Zukunft eintreffen werden, sollen beschrieben werden, damit die Softwarelosung so strukturiertwerden kann, dass diese Anderungen spater einfach zu realisieren sind.

Das Ergebnis der Soll-Analyse ist das Lastenheft, in dem wir aus Sicht des Kunden beschreiben, was die Problemeder bisherigen Situation sind und was die neue Software verbessern soll.

Haufig wird in der Soll-Analyse der Fehler gemacht, dass wir in technische Details der Losung abgleiten, obwohl esdoch zunachst um grobe Konzepte zur Verbesserung geht. Wir stoßen auch auf das oben bereits angefuhrteProblem, dass der Kunde nicht notwendigerweise eine klare Vorstellung von der moglichen softwaretechnischenVerbesserung hat beziehungsweise sie nicht vermitteln kann.

Mangel in der Soll-Analyse fuhren dazu, dass eine falsche Losung spezifiziert wird. Am Ende entsteht einSoftwaresystem, das nicht die relevanten Probleme beseitigt und damit unnutz ist. Um eine gute Soll-Analysemachen zu konnen, brauchen wir neben analytischen Fahigkeiten bei der Problemsuche auch softwaretechnischesWissen, um abzuschatzen ob und mit welchem Aufwand, anvisierte softwaretechnische Losungen machbar sind.

Anforderungsanalyse

Schritte der Anforderungsanalyse: Spezifikation


Anforderungs−

(Pflichtenheft)

spezifikation

Anforderungs−spezifikation

der Anforderungen

Spezifikation

Soll−Analyse

Lastenheft

Ist−Analyse

Ist−Zustand

Glossar

Ziel: Anforderungen genau beschreiben.Haufige Fehler:

Anforderungen bleiben vage

Implementierungsdetails stattAnforderungen

Folgen von Mangeln:

Vertragsstreitigkeiten am Projektende.

Erforderlich: Kommunikationsfahigkeit.




Anforderungs−

(Pflichtenheft)

spezifikation


der Anforderungen

Spezifikation

Soll−Analyse

Lastenheft

Ist−Analyse

Ist−Zustand

Glossar




Folgen von Mangeln:



20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Aktivitaten


Die Ist-Analyse untersucht die Anwendungsdomane, fur die eine softwaretechnische Losung angestrebt wird. DieseAnalyse ist rein deskriptiv. Die Soll-Analyse untersucht die Schwachen des Ist-Zustands und formuliert darausAnforderungen an eine softwaretechnische Losung, die diese Schwachen ausgleichen sollen. Die Soll-Analyse mussPrioritaten setzen (nicht alle Anforderungen sind gleich wichtig) und mogliche Konflikte auflosen (Anforderungenkonnen sich widersprechen; z.B. Performanz versus Sicherheit). Bei der Soll-Analyse mussen eventuell auch Folgenvon softwaretechnischen Losungen abgeschatzt werden. Diese Abschatzung konnte dazu fuhren, eine anderesoftwaretechnische Losung zu finden beziehungsweise – im Extremfall – eine softwaretechnische Losung ganzauszuschließen.

Mit Losung ist hier nicht die Implementierung gemeint, sondern lediglich der Anforderungskatalog an dieImplementierung. Es geht hier noch nicht darum, sich zu uberlegen, wie die Anforderungen implementiert werden.

Das Lastenheft beschreibt die Wunsche des Kunden aus dessen Sicht. Es ist haufig 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 werdensoll, sind Uberlegungen zu der generellen Machbarkeit notwendig. Eine Anforderungsspezifikation muss auchrealisierbar sein. Dennoch sollten diese Uberlegungen lediglich dazu fuhren, moglicherweise die Anforderungenabzuandern. Mogliche Wege, die Anforderungen zu implementieren, gehoren in ein Entwurfsdokument und nicht indie Anforderungsspezifikation.

Die Anforderungsspezifikation stellt den Vertrag zwischen Kunde und Entwickler dar und muss entsprechend genaugepruft werden. Meist geschieht dies durch ein Review mit dem Kunden.



Anforderungs−

(Pflichtenheft)

spezifikation


der Anforderungen

Spezifikation

Soll−Analyse

Lastenheft

Ist−Analyse

Ist−Zustand

Glossar




Folgen von Mangeln:



20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Aktivitaten


Typische Fehler bei der Anforderungsspezifikation sind vage Anforderungen (z.B. dass die Softwarebenutzerfreundlich sein soll) und dass sie Implementierungsdetails beschreibt statt Anforderungen aus Kundensicht.

Weil die Anforderungsspezikation den Vertragsgegenstand festlegt, fuhren Mangel nicht selten zuVertragsstreitigkeiten am Ende des Projekts. Wenn die Anforderungen nicht genau definiert wurden, ist einegerichtliche Auseinandersetzung sehr muhselig. In jedem Falle ist ein solcher Streit fur alle Parteien zum eigenenSchaden. Der Kunde hat nicht bekommen, was er wollte; wir bekommen moglicherweise unser Geld nicht. Einenttauschter Kunde schadet uns, denn Enttauschung spricht sich schnell herum.

Wir werden uns also große Muhen bei der Anforderungsspezifikation geben. In den folgenden Abschnitten werdenwir hierzu verschiedene Techniken kennen lernen, die uns bei richtiger Ausfuhrung vor Schaden bewahren konnen.Es sei auch hier nochmal darauf hingewiesen, dass die genannten Schritte der Ist- und Soll-Analyse sowie dasFesthalten der Anforderungen hochgradig iterativ sind und keineswegs so sequentiell, wie durch den Datenfluss imDiagramm suggeriert. Das muss bei der Planung beachtet werden.

Anforderungsanalyse

Wegweiser

Ist-Analyse

Was ist das Ziel und der Gegenstand derIst-Analyse?


Anforderungsanalyse

Soziotechnisches System

Definition

Soziotechnisches System: organisierte Menge von Menschen undTechnologien, die in einer bestimmten Weise strukturiert sind, um eineAufgabe zu erfullen.

Aufgaben

Menschen

Technologien

Rolle/Struktur

AusgabeEingabe

Technisches

Soziales

Umgebung

– Emery, Thorsrud & Trist 1964Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 119 / 634

Anforderungsanalyse

Ist-Zustand: Was?

Verstandnis von:Struktur

Aufgaben

Kommunikation

Dokumenten

Daten

Schwachstellen

. . . aus allenrelevantenBlickwinkeln.


Ist-Zustand: Was?


Aufgaben

Kommunikation

Dokumenten

Daten

Schwachstellen

. . . aus allenrelevantenBlickwinkeln.

20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Ist-Analyse

Ist-Zustand: Was?

In diesem Abschnitt lernen wir Analysetechniken fur die Ist-Analyse kennen. Zunachst untersuchen wir, was wir beider Ist-Analyse uberhaupt analysieren sollen.

Durch die Ist-Analyse streben wir ein Verstandnis folgender Aspekte des Ist-Zustands aus allen relevantenBlickwinkeln an:

• Struktur: das organisatorische Gefuge des Systems, fur das die Softwarelosung 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 uber sie hinaus

• Schwachstellen: die bestehenden Mangel, Unvollstandigkeiten und Redundanzen des Ist-Zustands

Wie werden diese Aspekte nun vertiefen und benutzen als illustrierendes Beispiel eine Verkaufssituation in einemFahrradladen, fur die wir eine softwaretechnische Unterstutzung entwickeln sollen.

Anforderungsanalyse

Ist-Zustand: Was?


Aufgaben

Kommunikation

Dokumenten

Daten

Schwachstellen

Bestandteile

organisatorisches Gefuge des Systems, fur dasSoftwarelosung angestrebt wird

relevante Akteure

Systemgrenzen

Art und Umfang der Verbindungen innerhalbund nach außen

Kunde 1Verkäufer 1

Kunde 2

Verkäufer 2

Ladenbesitzer

Großhändler


Ist-Zustand: Was?


Aufgaben

Kommunikation

Dokumenten

Daten

Schwachstellen

Bestandteile

organisatorisches Gefuge des Systems, fur dasSoftwarelosung angestrebt wird

relevante Akteure

Systemgrenzen

Art und Umfang der Verbindungen innerhalbund nach außen

Kunde 1Verkäufer 1

Kunde 2

Verkäufer 2

Ladenbesitzer

Großhändler

20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Ist-Analyse

Ist-Zustand: Was?

Bei der Analyse der Struktur identifizieren wir zunachst alle relevanten Akteure (Benutzer und andereSoftwaresysteme, die miteinander interagieren. Im Fahrradladen sind das Kunden und Verkaufer sowie derLadenbesitzer und seine Lieferanten.

Dann legen wir die Systemgrenzen fest. Mit System ist hier weder das Softwaresystem gemeint, das wirimplementieren sollen (wir kennen ja die Anforderungen dafur noch gar nicht) noch etwa ein moglicherweise bereitsexistierendes Softwaresystem, das wir ablosen sollen. Vielmehr meinen wir damit den Ausschnitt der Welt, fur denwir die softwaretechnische Verbesserung anstreben sollen. Diesen Ausschnitt fassen wir als ein System miteinanderagierender Akteure auf.

Wenn wir die Systemgrenzen festlegen, bestimmen wir also, was alles zu dem Ausschnitt der Welt gehort, der furuns relevant ist. Bsp.: Nehmen wir an, wir sind beauftragt, das Verkaufsgesprach zwischen Kaufer und Verkaufer zuoptimieren, dann gehoren diese beiden Personengruppen zu unserem untersuchten System. Ihr Zusammenspielsollen wir optimieren. Ladenbesitzer und Lieferanten hingegen sind außerhalb unseres Systems, aber dennochrelevant fur unsere Aufgabenstellung, weil der Verkaufer den Ladenbesitzer bei bestimmten Entscheidungen zu Rateziehen und Lieferanten zu Lieferzeiten befragen muss. �

Haben wir die Systemgrenzen gezogen, untersuchen wir die Art und den Umfang der Verbindungen innerhalb desSystems und nach außen. Wir bestimmen, wer innerhalb des System miteinander und welche unserer innerenAkteure mit welchen externen Akteuren interagiert. Die Interaktion zwischen externen Akteuren konnen wir in derRegel vernachlassigen.

Das Ergebnis lasst sich als Graph reprasentieren, dessen Knoten die Akteure und dessen Kanten die Interaktionendarstellen.

Anforderungsanalyse

Ist-Zustand: relevante Akteure

Grundsatz: Kenne deinen Benutzer!

Aber: Der Benutzer bzw. die Benutzerin ist eine Illusion. Es sindindividuelle Menschen, um die es geht.

Andererseits: Wir konnen nicht jeden betrachten und mussenzusammenfassen.



Grundsatz: Kenne deinen Benutzer!

Aber: Der Benutzer bzw. die Benutzerin ist eine Illusion. Es sindindividuelle Menschen, um die es geht.

Andererseits: Wir konnen nicht jeden betrachten und mussenzusammenfassen.

20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Ist-Analyse


Nachdem wir alle Akteure bestimmt haben, untersuchen wir die menschlichen Akteure weiter im Detail. Dies sinddie potentiellen Benutzer unseres zukunftigen Softwaresystems. Zum Teil erscheinen sie uns bisher noch rechtabstrakt, etwa der Verkaufer und der Kaufer. Diese Rollen definieren bestimmte Klassen von Benutzern mitunterschiedlichen Aufgaben und Zielen in unserem Systemgefuge. Diese Rollen abstrahieren aber von denEigenschaften konkreter Benutzer. So konnen wir sicherlich ganz unterschiedliche Kaufer in unserem Fahrradladenausmachen, die sich in Erfahrungen, Vorlieben, Wunschen, Alter, Geschlecht und Finanzkraft unterscheiden. Allewollen ein Fahrrad oder ein Fahrradbestandteil kaufen, aber ihre Auswahl und ihre Interaktion mit dem Kaufer wirdwesentlich durch ihre personlichen Eigenschaften bestimmt. Es reicht also nicht aus, nur funktionale Rollen zuidentifizieren. Da das Softwaresystem von konkreten Menschen benutzt werden wird, mussen wir deren Eigenheitengenau kennen, damit wir ein nutzliches Softwaresystem fur sie entwickeln konnen.

Andererseits konnen wir auch nicht jedes mogliche Individium einzeln betrachten, da die Anzahl der Benutzer meistsehr hoch ist und uns nicht alle Benutzer bekannt sind. Aus okonomischen Grunden mussen wir also mehrereIndividuen mit ahnlichen Eigenschaften zu Klassen zusammenfassen.

Anforderungsanalyse


Persona

(in archetypischer Psychologie) die Maske oder Erscheinung, die man derWelt prasentiert.

(in der Softwareergonomie) erzahlerische Beschreibung charakterischerEigenschaften und Verhalten eines Benutzers oder Kunden, die spezifischeDetails nennt, statt Verallgemeinerungen.



Persona

(in archetypischer Psychologie) die Maske oder Erscheinung, die man derWelt prasentiert.

(in der Softwareergonomie) erzahlerische Beschreibung charakterischerEigenschaften und Verhalten eines Benutzers oder Kunden, die spezifischeDetails nennt, statt Verallgemeinerungen.

20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Ist-Analyse


Es ist die Aufgabe des Analysten, eine angemessene Menge von Benutzerklassen zu finden, die die richtige Balancezwischen abstrakten Rollen und individuellen Benutzern wahrt. Zur Beschreibung dieser Benutzerklassen kann mansich der so genannten Personas bedienen. Die Persona ist ursprunglich eine im griechischen Theater von denSchauspielern verwendete Maske, die die Rolle typisierte und als Schallverstarker benutzt wurde. In derarchetypischen Psychologie ist es die Maske oder Erscheinung, die man der Welt prasentiert.

In der Anforderungsanalyse der Softwaretechnik steht eine Persona fur eine Benutzerklasse. Sie beschreibt derengemeinsamen Eigenschaften, gibt ihnen aber ein konkretes Bild. Sie ist in der Softwareergonomie eine erzahlerischeBeschreibung charakterischer Eigenschaften und Verhalten eines Benutzers oder Kunden, die spezifische Detailsnennt, statt nur Verallgemeinerungen.

Neben der Konkretisierung statt Verallgemeinerung geben uns die Personas etwas Spielerisches imEntwicklungsprozess, das unsere Kreativitat stimulieren kann. Wir konnen große Poster unserer Personas aufhangenund sie betrachten, wahrend wir an der Anforderungsspezfikation schreiben. Wir leben damit die Idee, fur und mitdem Benutzer zu entwickeln.

Anforderungsanalyse

Persona-Poster:

Bild (fiktiv)

Name (fiktiv),Beruf, Motto

Rolle, Ziele,Aufgaben, Ideen,Wunsche,Vorlieben,personlicheDetails


Persona-Poster:

Bild (fiktiv)

Name (fiktiv),Beruf, Motto

Rolle, Ziele,Aufgaben, Ideen,Wunsche,Vorlieben,personlicheDetails

20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Ist-Analyse

Die ursprungliche Idee der Personas fur die Anforderungsaanalyse stammt von Cooper. Zur Beschreibung einerPersona gehoren ein fiktives Bild und ein fiktiver Name sowie weitere personliche Eigenschaften, wie den Beruf oderein charakterisierendes Motto. Statt von der abstrakten Benutzerklasse Verkaufer sprechen wir also von HerrnSchmidt, dem Verkaufer. Dann werden die gemeinsamen Eigenschaften der Benutzer, die sich hinter der Personaverbergen, aufgefuhrt. Dazu gehoren die Rolle, die Herr Schmidt ausfullt, die Ziele, die Herr Schmidt verfolgt, seineIdeen, Wunsche, Vorlieben und weitere personliche Details, soweit sie von Relevanz fur die Analyse sind.

Quelle fur das Bild:http://www.research.microsoft.com/research/coet/Grudin/Personas/Pruitt-Grudin.doc. Der Artikelerlautert auch wesentliche Ideen.

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

Anforderungsanalyse

Bedeutung von Personas

archetypische Benutzerbeschreibungen

typisch fur Zielgruppen

decken deren Anforderungen, Bedurfnisse und Ziele ab

stehen im Designprozess stellvertretend fur die realen Benutzer (stattder relativ anonymen und pauschalen Große “Benutzer”)

konnen bei Design und beim Usability-Test der Benutzerinteraktionverwendet werden

konnen beim Handbuchschreiben und -prufen sowie Akzeptanztestverwendet werden

– Astrid Beck, FHT Esslingen



archetypische Benutzerbeschreibungen

typisch fur Zielgruppen

decken deren Anforderungen, Bedurfnisse und Ziele ab

stehen im Designprozess stellvertretend fur die realen Benutzer (stattder relativ anonymen und pauschalen Große “Benutzer”)

konnen bei Design und beim Usability-Test der Benutzerinteraktionverwendet werden

konnen beim Handbuchschreiben und -prufen sowie Akzeptanztestverwendet werden

– Astrid Beck, FHT Esslingen20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Ist-Analyse


Astrid Beck, von der Fachhochschule fur Technik in Esslingen, fasst die Bedeutung von Personas in derSoftwaretechnik wie folgt zusammen. Personas sind archetypische Benutzerbeschreibungen und beschreibentypische Zielgruppen durch deren gemeinsame Eigenschaften. Die Gesamtheit der Anforderungen aller Personasdeckt die Anforderungen, Bedurfnisse und Ziele aller Benutzer ab. Wie viele Personas man benotigt, hangt starkvom Projekt ab. In der Regel wird man mit zwischen 5 und 15 verschiedene Personas auskommen.

Die Personas stehen im Designprozess stellvertretend fur die realen Benutzer und bilden eine kreative und konkreteAlternative zu der relativ anonymen und pauschalen Große

”Benutzer“. Die Anforderungsspezifikation muss die

Anforderungen fur jede Persona beinhalten. Sie konnen aber nicht nur wahrend der Anforderungsanalyse derfunktionalen Anforderungen an die Software verwendet werden. Die Personas helfen uns auch beim Design derMensch-Maschine-Kommunikation und beim Usability-Test der Benutzerinteraktion. Hier muss dieBenutzerinteraktion so gestaltet sein, dass alle Personas ihr Anwendungsproblem mit dem Softwaresystem effektivund effizient losen konnen. Aus den Personas lassen sich fur den Usability-Test, der dies uberprufen soll,unmittelbar entsprechende Test-Benutzer ableiten, die das Profil der Personas erfullen. Schließlich konnen diePersonas beim Handbuchschreiben und -prufen sowie beim Akzeptanztest verwendet werden. Auch hier helfen sie,sicher zu stellen, dass die Anforderungen zutreffend und vollstandig sind, indem das Handbuch und System ausallen relevanten Blickwinkeln der Benutzersicht untersucht wird.

Anforderungsanalyse

Ist-Zustand: Was?

Verstandnis von:

Struktur

Aufgaben

Kommunikation

Dokumenten

Daten

Schwachstellen

Bestandteile

Umfang und Art der anfallenden Aufgaben(Operationen) und Besonderheiten im Ablauf.

Was wird gemacht?→ Kundenberatung

Wer oder was fuhrt Operation aus?→ Kunde + Verkaufer

Wann und wie haufig?→ werktags: 50 Mal/Tag; samstags: 80Mal/Tag


Anforderungsanalyse

Ist-Zustand: Was?

Verstandnis von:

Struktur

Aufgaben

Kommunikation

Dokumenten

Daten

Schwachstellen

Bestandteile (Forts.)

Zu welchem Zweck?→ Kauf eines Artikels

Nach welchen Regeln wirken Operationenzusammen?→ Beratung vor Kauf-Operation, aber optional

Was benutzt/produziert Operation?→ Zeit und Wissen des Verkaufers/Auswahldes Kaufers


Ist-Zustand: Was?

Verstandnis von:

Struktur

Aufgaben

Kommunikation

Dokumenten

Daten

Schwachstellen





20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Ist-Analyse

Ist-Zustand: Was?

Nachdem wir uns durch die Personas einen Uberblick verschafft haben, welche Benutzerklassen zu beachten sind,untersuchen wir als nachstes die Aufgaben der einzelnen Akteure, die im untersuchten System vorkommen. DieAufgaben konnen wir als Operationen der Akteure auffassen. Hier interessiert uns, was eine Operation macht, wersie ausfuhrt, wann und wie haufig die Operation ausgefuhrt wird, zu welchem Zweck sie durchgefuhrt wird, welcheRegeln der Ausfuhrung der Operation selbst und welche dem Zusammenwirken der Operationen zu Grunde liegensowie was eine Operation benutzt und produziert.

Ist-Zustand: Was?

Verstandnis von:

Struktur

Aufgaben

Kommunikation

Dokumenten

Daten

Schwachstellen





20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Ist-Analyse

Ist-Zustand: Was?

Betrachten wir diese Fragen zu den Aufgaben an unserem Beispiel des Fahrradladens. Wir untersuchen hier diebesondere Aufgabe des Einkaufes. Dies ist eine Operation unter vielen in einem Fahrradladen. Die Reparatur oderder Umtausch sind weitere Beispiele fur Operationen in einem Fahrradladen.

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

1. Der Kunde betritt den Laden und außert seinen Wunsch gegenuber dem Verkaufer.

2. Der Verkaufer fragt nach den Details und berat den Kunden.

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

4. Der Verkaufer ubergibt den Artikel und den Kassenzettel, sobald der Betrag durch den Kunden beglichen wurde.

• Wer oder was fuhrt Operation aus?

→ Die Ausfuhrenden sind Kunde und Verkaufer in den oben beschriebenen Rollen.

• Wann und wie haufig?

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

• Zu welchem Zweck?

→ Der Kaufer benotigt einen Fahrradartikel. Der Verkaufer mochte Umsatz erzielen.

• Nach welchen Regeln wirken Operationen zusammen?

→ Wenn der Kunde nichts Passendes findet oder der Verkaufer ihn unzureichend berat, geht der Kunde ohne zu kaufen.Wenn der Kunde nicht komplett bezahlen kann, schreibt der Verkaufer an, wenn er den Kunden gut genug kennt.Ansonsten ubergibt ihm der Verkaufer den Artikel nicht. Ein Umtausch ist nur moglich, wenn ein Artikel vorher gekauftwurde. Kaufer und Verkaufer verhalten sich kooperativ, das heißt, der Verkaufer berat nach bestem Wissen undGewissen und der Kunde liefert ihm hierfur notwendige Hintergrundinformationen zu seinen bereits gekauften Artikelnund seinen Wunschen.

• Was benutzt/produziert Operation?

→ Die Operation uberfuhrt den Artikel aus dem Besitz des Ladens in den Besitz des Kaufers. Sie uberfuhrt den Geldbetrag,der zu entrichten ist, vom Kunden in die Kasse des Verkaufers.

�

Anforderungsanalyse

Ist-Zustand: Was?

Verstandnis von:

Struktur

Aufgaben

Kommunikation

Dokumenten

Daten

Schwachstellen

Bestandteile

Welche Vorrichtungen und Gelegenheiten zurKommunikation gibt es (im Rahmen welcherAufgaben)?→ Laden, Telefon

Wie lauft Kommunikation ab?→ initiiert vom Kunden


Ist-Zustand: Was?

Verstandnis von:

Struktur

Aufgaben

Kommunikation

Dokumenten

Daten

Schwachstellen

Bestandteile

Welche Vorrichtungen und Gelegenheiten zurKommunikation gibt es (im Rahmen welcherAufgaben)?→ Laden, Telefon

Wie lauft Kommunikation ab?→ initiiert vom Kunden

20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Ist-Analyse

Ist-Zustand: Was?

Wenn wir die Kommunikation untersuchen, interessieren wir uns fur die Vorrichtungen fur die Kommunikation, dieGelegenheit, zu der die Kommunikation stattfindet, sowie den Ablauf der Kommunikation.

Bsp.: Beim Verkaufsgesprach, wie oben dargestellt, verwenden die Akteure im Laden schlicht die menschlicheStimme, wenn das Gesprach im Laden stattfindet. Alternativ kann der Kunde sich aber auch uber das Telefon vomVerkaufer beraten lassen und erst spater den Laden betreten, um den passenden Artikel zu besorgen.

Die Kommunikation findet wahrend der Ladenoffnungszeiten statt und wird vom Kunden initiiert. Wenn derVerkaufer frei ist, spricht er jedoch auch Kunden an, wenn er den Eindruck hat, dass sie seine Hilfe benotigen. �

Anforderungsanalyse

Ist-Zustand: Was?

Verstandnis von:

Struktur

Aufgaben

Kommunikation

Dokumenten

Daten

Schwachstellen

klara: Kundin

volker : Verkäufer

gib−artikel()

gib−detail()

Detail

Auswahl

wähle−aus()

gib−geld()

Geld

Artikel


Ist-Zustand: Was?

Verstandnis von:

Struktur

Aufgaben

Kommunikation

Dokumenten

Daten

Schwachstellen

klara: Kundin

volker : Verkäufer

gib−artikel()

gib−detail()

Detail

Auswahl

wähle−aus()

gib−geld()

Geld

Artikel20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Ist-Analyse

Ist-Zustand: Was?

Den Ablauf der Kommunikation kann man verbal beschreiben oder zu etwas formaleren Notationen greifen. Hierfureignen sich insbesondere die UML-Sequenzdiagramme, die fur solche Zwecke entworfen wurden.

Wichtig ist bei allen gewahlten Notationen, dass sie einerseits prazise genug sind – was fur stark formalisierteNotationen spricht – und dass sie auch vom Kunden verstanden werden – was meist gegen stark formalisierteNotationen spricht. Sequenzdiagramme sind jedoch ein recht einfach zu erlauterndes Mittel, das nach kurzenErlauterungen auch Nichtinformatikern verstandlich sein kann. Fur zustandsbasierte Kommunikation eignen sichauch Zustandsdiagramme. Ebenso kann man mit Aktivitatsdiagrammen komplexere Ablaufe gut beschreiben.

Bsp.: Das Diagramm hier beschreibt die Kommunikation als eine Abfolge von Nachrichten, die sich die Akteuregegenseitig zuschicken. Einige davon, wie z.B. gib-detail(), erhalten eine Antwort. Es bescheibt dieselbe Abfolge wieder naturlichsprachliche Text weiter oben. Das Sequenzdiagramm muss aber hierfur noch erganzt werden um dieBedeutung der Nachrichten. �

Anforderungsanalyse

Ist-Zustand: Was?

Verstandnis von:

Struktur

Aufgaben

Kommunikation

Dokumenten

Daten

Schwachstellen

Bestandteile

Dokumente, die verwendet und produziert werden

Bezeichnung→ Kassenzettel

Inhalt→ gekaufte Ware, Preis, MWST, Datum,Verkaufer

Grad der Formalisierung, Aufbau→ genugt Gesetz

Verteiler→ Kunde und Laden


Anforderungsanalyse

Ist-Zustand: Was?

Verstandnis von:

Struktur

Aufgaben

Kommunikation

Dokumenten

Daten

Schwachstellen

Bestandteile (Fortsetzung)

Archivierung→ als Papier beim Kunden, elektronisch in derLadenkasse

von wem produziert/verwendet?

→ produziert von Kasse/Verkaufer→ verwendet von Kunde beim Umtausch,

Steuererklarung


Ist-Zustand: Was?

Verstandnis von:

Struktur

Aufgaben

Kommunikation

Dokumenten

Daten

Schwachstellen


Archivierung→ als Papier beim Kunden, elektronisch in derLadenkasse

von wem produziert/verwendet?

→ produziert von Kasse/Verkaufer→ verwendet von Kunde beim Umtausch,

Steuererklarung

20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Ist-Analyse

Ist-Zustand: Was?

Eine wichtige Informationsquelle bei der Ist-Analyse liefern existierende Dokumente, die verwendet und produziertwerden. Meist mussen sie bei einer softwaretechnischen Losung im Rechner nachgebildet werden. Dokumentekonnen eher formalisiert sein, wie z.B. der Kassenbons im Fahrradladen, oder eher informell sein, wie z.B. derNotizzettel des Kaufers, auf dem er sich aufgeschrieben hat, was er einkaufen mochte und zu welchem Fahrrad inseinem Besitz der neue Artikel passen soll.

Bei diesen Dokumenten interessieren uns die Bezeichnung, der Inhalt, der Grad der Formalisierung, der Aufbau, derVerteiler (d.h. wer das Dokument erhalt), die Archivierung des Dokuments sowie die Produzenten undKonsumenten des Dokuments.

Bsp.: Im Fahrradladen gibt es beispielsweise den Kassenzettel. Sein Inhalt ist die gekaufte Warte, der Preis, dieanrechenbare Mehrwertsteuer, das Kaufdatum sowie der Verkaufer. Der Kassenzettel muss dem Gesetz genugenund ist darum recht formalisiert. Den Kassenzettel erhalt der Kunde, ein Durchschlag bleibt in der Kasse desLadens. Sowohl der Kunde als auch der Laden archivieren den Kassenzettel – der Kunde um gegebenenfalls seineGarantieanspruche durchzusetzen, der Laden fur das Finanzamt. Produziert wird der Kassenzettel von der Kassedes Ladens durch den Verkaufer und verwendet wird er vom Kunden im Falle eines Umtausches beziehungsweisevom Ladenbesitzer fur die Steuererklarung. �

Anforderungsanalyse

Ist-Zustand: Was?

Verstandnis von:

Struktur

Aufgaben

Kommunikation

Dokumenten

Daten

Schwachstellen

Bestandteile

Umfang und Art der verarbeiteten Daten

Volumen und Wachstum→ 41 Flaschenhalter

Wertebereiche→ Radius Halterung, Abstand Schrauben,versch. Farben etc.

Datentrager→ Katalog in Papierform, Online-Katalog inHTML

Ordnungsstrukturen→ Name, Hersteller, Typ

Verarbeitungshaufigkeit→ wird alle drei Tage einmal verkauft


Anforderungsanalyse

Ist-Zustand: Was?

Verstandnis von:

Struktur

Aufgaben

Kommunikation

Dokumenten

Daten

Schwachstellen


Art und Erfordernisse der Datensicherung→ Speicherung verkaufter Waren und desInventars

Abhangigkeiten zwischen den Daten→ passt nur an bestimmte Rahmen


Ist-Zustand: Was?

Verstandnis von:

Struktur

Aufgaben

Kommunikation

Dokumenten

Daten

Schwachstellen




20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Ist-Analyse

Ist-Zustand: Was?

Wir untersuchen die Dokumente, um die Daten zu ermitteln, die fur die Ist-Analyse relevant sind. Oft sind esverschiedene Daten, die in den Dokumenten aufgefuhrt und verknupft werden. Allerdings sind nicht alle relevantenDaten auf Dokumenten wiedergegeben. Im nachsten Schritt untersuchen wir weitere Daten, die moglicherweise nurmundlich ausgetauscht werden.

Um die Daten prazise und vollstandig zu modellieren, wird hierzu oft ein Datenmodell aufgestellt. DasDatenmodell beschreibt die wesentlichen Daten, ihre Eigenschaften, ihren Umfang und ihre Beziehungen. ZurReprasentation eignen sich fur eine Reihe der relevanten Aspekte beispielsweise UML-Klassendiagramme. DasDatenmodell beschreibt das Volumen und zukunftig erwartete Wachstum der Daten. Dies wird haufig als dasMengengerust bezeichnet. Es ist unerlasslich fur die Abschatzung des Speicherbedarfs und der Anforderungen andie Performanz der Algorithmen. Mit der Betrachtung des zukunftigen Wachstums stellen wir sicher, dass unserSystem skaliert und auch in einigen Jahren noch die notwendige Performanz zur Verfugung stellen wird. Die Datenhaben einen Typ, fur den wir den Wertebereich angeben. Sie werden in vielen Fallen dauerhaft gespeichert aufDatentragern, die aber nicht notwendigerweise unmittelbar elektronisch verarbeitbar sind, z.B. weil sie von Handauf Papier geschrieben werden. Viele Daten konnen sortiert werden, d.h. verfugen uber ein oder mehrereOrdnungskriterien. Unsere Programme mussen sie meist nach diesen Ordnungskriterien sortieren konnen. DieHaufigkeit ihrer Verarbeitung ist fur uns wichtig, weil wir damit die Zugriffe entsprechend organisieren mussen.Haufig verarbeitete Daten mussen schnell verfugbar sein. Schließlich interessieren uns die Art und Erfordernisse derDatensicherung sowie die Abhangigkeiten zwischen den Daten. Haufige solche Abhangigkeiten sind dieTeil-Von-Beziehung in Form der Aggregation und Komposition. Andere Beziehungen werden inUML-Klassendiagrammen mit allgemeinen Assoziationen modelliert.

Ist-Zustand: Was?

Verstandnis von:

Struktur

Aufgaben

Kommunikation

Dokumenten

Daten

Schwachstellen




20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Ist-Analyse

Ist-Zustand: Was?

Bsp.: In unserem Fahrradladen gibt es beispielsweise 41 Flaschenhalter in funf verschiedenen Typen von dreiverschiedenen Herstellern. Ein Flaschenhalter wird beschrieben durch die Attribute Radius der Halterunggemessen in Zentimetern, der Abstand der Schrauben gemessen in Zentimetern, die Farben in rot, grun, gelb, blausowie der Preis im Bereich von 5 bis 25 Euro. Die Datentrager zu den Flaschenhaltern sind die Herstellerkataloge inPapierform 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 Verarbeitungshaufigkeit.Die verkauften und im Lager befindlichen Flaschenhalter werden in einer Datenbank des Ladenbesitzers gespeichert.Die Flaschenhalter passen nur an bestimmte Rahmen; dies hangt vom Schraubenabstand und dem Radius ab. Eineweitere

”weiche“ Abhangigkeit ist die Farbe des Rahmens, zu der der Flaschenhalter passen soll. �

Anforderungsanalyse

Ist-Zustand: Was?

Verstandnis von:

Struktur

Aufgaben

Kommunikation

Dokumenten

Daten

Schwachstellen

Bestandteile

Untersuchung auf:

Mangel

Unvollstandigkeiten

Redundanzen


Ist-Zustand: Was?

Verstandnis von:

Struktur

Aufgaben

Kommunikation

Dokumenten

Daten

Schwachstellen

Bestandteile

Untersuchung auf:

Mangel

Unvollstandigkeiten

Redundanzen

20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Ist-Analyse

Ist-Zustand: Was?

Nachdem wir die oben genannten relevanten Aspekte des Ist-Zustands erfasst haben, analysieren wir sie aufSchwachstellen und Probleme. Dazu gehoren Mangel, Unvollstandigkeiten oder Redundanzen. Auf dieSchwachstellen werden wir sowohl durch eigene Analyse und Beobachtung der erhobenen Aspekte als auch durchBefragung und Beobachtung der Akteure selbst aufmerksam. Zu entsprechenden Techniken der Befragung undBeobachtung kommen wir weiter unten.

Anforderungsanalyse

Ist-Zustand: Was?

Verstandnis von:

Struktur

Aufgaben

Kommunikation

Dokumenten

Daten

Schwachstellen

Beispielschwachstellen

Abhangigkeiten und wechselseitige Ausschlussevon Teilen sind nirgendwo dokumentiert

Verkaufer kennt nicht alle Einschrankungen

Kunde kennt seine Konfiguration nicht

Verkaufer kennt Sortiment nicht vollstandig

verschiedene uberlappende Teilekataloge

Inventarlisten sind obsolet


Ist-Zustand: Was?

Verstandnis von:

Struktur

Aufgaben

Kommunikation

Dokumenten

Daten

Schwachstellen

Beispielschwachstellen

Abhangigkeiten und wechselseitige Ausschlussevon Teilen sind nirgendwo dokumentiert

Verkaufer kennt nicht alle Einschrankungen

Kunde kennt seine Konfiguration nicht

Verkaufer kennt Sortiment nicht vollstandig

verschiedene uberlappende Teilekataloge

Inventarlisten sind obsolet

20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Ist-Analyse

Ist-Zustand: Was?

Bsp.: In unserem Fahrradladen konnen wir beispielsweise durch unsere Analyse der erhobenen Aspekte und durchBeobachtung im Laden folgende Schwachstellen identifizieren:

• Die Abhangigkeiten und wechselseitige Ausschlusse der Bestandteile eines Fahrrads sind nirgendwo dokumentiert. EinVerkaufer kann sie nicht nachschlagen und muss sie alle kennen, um einen Kunden zu beraten.

• Nicht alle Verkaufer kennen aber alle Einschrankungen. Dies fuhrt dazu, dass weniger erfahrene Verkaufer Rucksprachehalten mussen mit erfahreneren Verkaufern oder gar Lieferanten und dass Kunden verargert ihre falschen Artikelumtauschen mussen, wenn sie falsch beraten wurden.

• Die Verkaufer konnen die Kunden nicht ausreichend beraten, weil der Kunde die bereits gekauften Fahrradbestandteilenicht genau kennt, zu denen der neu zu kaufende Artikel passen soll. Der Kunde muss in solchen Fallen unverrichteterDinge den Laden wieder verlassen und die Information besorgen.

• Verkaufer kennen das Sortiment nicht vollstandig und wissen nicht genau, was im Laden selbst oder im Lager nochverfugbar ist.

• Die Fahrradartikel sind in verschiedenen teilweise uberlappenden Teilekatalogen beschrieben. Dies fuhrt zu unnotigenRedundanzen.

• Die Inventarlisten sind obsolet. Der Ladenbesitzer weiß nicht genau, welche Ware noch vorratig, verkauft oder gargestohlen ist.

�

Anforderungsanalyse

Wegweiser

Ist-Analyse

Welchen Techniken konnen wir in der Ist-Analysenutzen?


Anforderungsanalyse

Ist-Zustand: Wie?

Erhebungstechniken

Auswertung vorhandener Dokumente

Befragung

schriftlicher FragebogenInterview

Beobachtung

anekdotisch ↔ systematischteilnehmend ↔ nicht-teilnehmendoffen ↔ verdecktselbst ↔ fremdFeld ↔ Labor


Ist-Zustand: Wie?

Erhebungstechniken


Befragung


Beobachtung

anekdotisch ↔ systematischteilnehmend ↔ nicht-teilnehmendoffen ↔ verdecktselbst ↔ fremdFeld ↔ Labor2

00

9-0

2-0

9

Software-Projekt

Anforderungsanalyse

Ist-Analyse

Ist-Zustand: Wie?

Wir wissen nun, was wir erheben sollen, aber leider noch nicht, wie wir das tun konnen. In diesem Abschnitt lernenwir hierfur verschiedene Erhebungstechniken kennen. Die Auswertung der vorhandenen Dokumente ist eine ersteoffensichtliche Technik. Daruber hinaus konnen wir jedoch auch die Akteure fragen oder beobachten.

Um Akteure zu befragen, konnen wir sie selbst interviewen oder ihnen aber einen schriftlichen Fragebogenzuschicken. Beim Interview kann man auch mit einem vorher grundlich ausgearbeiteten Fragebogen arbeiten oderaber nur eine grobe Skizze der Fragen haben, um dann die Fragen an die Situation spontan anzupassen. Ganz zuAnfang, wenn man sich ein Gebiet erschließen mochte, ist man oft gar nicht in der Lage, prazise Fragenauszuarbeiten. Das Interview hat gegenuber der Befragung durch einen schriftlichen Fragebogen, den der Befragteohne unser Beisein ausfullt, den Vorteil, dass wir auch Gestik und Mimik des Befragten sehen, seine Gegenfragendirekt klaren konnen und individuell auf die Situation reagieren konnen. Allerdings kann die Anwesenheit einesFragenden die Antworten des Befragten beeinflussen. Zum einen lasst sich die Anonymitat hier nicht sicher stellen,zum anderen fallen die Antworten oft auch abhangig davon aus, inwieweit der Fragende dem Befragtensympathisch ist. Außerdem ist das individuelle Interview erheblich zeitaufwandiger und teurer. Bei den schriftlichenFragebogen verhalt es sich gerade umgekehrt. Aus diesem Grunde werden wir meistens sowohl Interviews als auchschriftliche Fragebogen anwenden, weil sie sich bestens erganzen. Wir werden meist zu Anfang eine kleinere Zahlvon Interviews fuhren. Spater konnen wir auf Basis dieser Interviews prazise Fragebogen aufstellen, um eine großereDatenbasis zu schaffen.

Ist-Zustand: Wie?

Erhebungstechniken


Befragung


Beobachtung

anekdotisch ↔ systematischteilnehmend ↔ nicht-teilnehmendoffen ↔ verdecktselbst ↔ fremdFeld ↔ Labor2

00

9-0

2-0

9

Software-Projekt

Anforderungsanalyse

Ist-Analyse

Ist-Zustand: Wie?

Statt zu fragen konnen wir auch beobachten. Beobachtungen haben aber viele Facetten, aus denen wir diegeeignete Beobachtungsart zusammen stellen mussen. Hier mussen wir zunachst entscheiden, ob wir systematischoder eher anekdotisch vorgehen wollen. Wenn wir z.B. ganz einfach einmal den Fahrradladen betreten und dort eineStunde verbringen, liefert das eher anekdotisches Wissen. Bei einem systematischen Vorgehen wurden wir vorherermitteln, wie sich die Kundenbesuche uber die Ladenoffnungszeiten verteilen. Dann wurden wir zu qualitativunterschiedlichen Zeiten den Laden betreten, z.B. Montag morgens, wenn nicht viel los ist, Mittwoch abends, wennmehr los ist, und Samstag vormittags, wenn der Laden meist voll ist. Außerdem mussen wir entscheiden, ob wir beider Beobachtung teilnehmen. Wir konnten uns also einerseits nur einfach in den Laden stellen und beobachten,oder aber konnten wir selbst Kunde spielen und uns beraten lassen. Die Beobachtung kann offen oder verdeckterfolgen. Erfolgt sie offen, kann das den Beobachtungsgegenstand beeinflussen. Ein Verkaufer wird sich in einersolchen Situation zum Beispiel eher freundlich verhalten, als wenn er sich unbeobachtet fuhlt. Andererseits werfenverdeckte Beobachtungen ethische Fragen auf und sind moglicherweise schlicht verboten. Dann mussen wir unsentscheiden, ob wir selbst beobachten oder die Beobachtung Dritten uberlassen. Wenn wir selbst beobachten,haben wir ein unmittelbareres Bild. Andererseits sind wir moglicherweise ungeubt, und ausgebildete und erfahrenedritte Beobachter sehen mehr als wir. Schließlich mussen wir uns zwischen einer Feld- oder Laborbeobachtungentscheiden. Im Labor konnen wir viel starker beeinflussende Faktoren kontrollieren, um so spezielle Situationenund den Einfluss der Faktoren durch deren Variation genauer zu studieren. So konnten wir z.B. eine stressigeLadensituation im Labor nachbilden, indem wir sehr viele Menschen unzufriedene Kunden schauspielern lassen. Dasnaturlichere Bild ergibt sich aber durch die Feldbeobachtung. Hier lassen sich aber keine Situationen nachstellen.

Auch hier gilt wieder, dass man Fur und Wider anhand der konkreten Ausgangslage und des Ziels abwagen muss.Eine Feldbeobachtung ist jedoch immer vernunftig. Im Labor kann man dann bestimmte Situationen nachstellenund naher untersuchen.

Anforderungsanalyse

Befragung

Fragen zu Fragen:

Wird die Frage verstanden?

Bezugsrahmen der Befragten?

Informationsstand der Befragten?

Art der Frage?

Anordnung der Fragen?

Erhebungssituation (Interviewereinfluss)?

Grunde fur die Antwort der Befragten?


Befragung

Fragen zu Fragen:




Art der Frage?




20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Ist-Analyse

Befragung

Die Antwort auf eine Frage hangt nicht nur vom Inhalt der Frage selbst, sondern auch vom Kontext und von derArt und Weise ab, wie man die Frage stellt. Aus diesem Grunde sollte man sich bei der Gestaltung einesFragebogens die Fragen und die Art der Frage sorgfaltig uberlegen und sich uber den Einfluss des Kontextes imKlaren werden. Die Sozialwissenschaften haben hierzu umfangreiche Lehrbucher entwickelt.

Zu unseren Fragen mussen wir uns selbst folgende Fragen stellen:

• Wird die Frage uberhaupt richtig verstanden? Benutzen wir Begriffe, zu denen der Befragte die gleichen Vorstellungenhat wie der Fragende? Bsp.: Wenn wir Softwaretechniker von Server sprechen und damit einen Prozess meinen, dannversteht der Befragte darunter moglicherweise den Rechner, auf dem seine Applikation laufen, wenn er etwasHintergrund 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 sowohlberuflicher als auch personlicher Art? Bsp.: Es hat keinen Sinn den Besitzer unseres Fahrradladens zum ublichen Ablaufvon Verkaufsgesprachen zu fragen, wenn er selbst seit langer Zeit das Verkaufen nicht mehr selbst praktiziert hat undlediglich Managementaufgaben wahrnimmt. �

• Informationsstand der Befragten? Was kann der Befragte uberhaupt wissen? Fragen wir ihn zu Dingen, die er nichtwissen kann, wird er keine Antwort abgeben konnen 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. Uber jede Frage denkt der Befragtenach. Die Assoziationen konnen einen Kontext herstellen, der die Antwort auf die nachste Frage beeinflusst. Bsp.: Umein krasses Beispiel zu nennen: Wenn wir den Verkaufer in unserem Fahrradladen als erstes fragen wurden, ob er sichdurch den geplanten Einsatz unseres Softwaresystems unnutz fuhlen wurde, wird das vermutlich Einfluss auf den Verlaufder weiteren Befragung nehmen. �

Befragung

Fragen zu Fragen:




Art der Frage?




20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Ist-Analyse

Befragung

• Was ist der mogliche Einfluss der Situation, in der der Fragebogen erhoben wird? Was ist insbesondere der Einfluss desInterviewers, falls die Fragen in einem Interview gestellt werden? Bsp.: Fragt man Menschen, die eben aus einemKinofilm zu einer Naturkatastrophe – wie z.B. einer Flutwelle – kommen, zum Thema Naturschutz, sind andereAntworten zu erwarten, wie wenn wir die selben Menschen bei einem Transatlantikflug zu ihrem Urlaubsort fragen. �Auch der Fragende hat einen moglichen Einfluss auf die Antworten. Ob uns jemand sympathisch oder unsympathisch ist,beeinflusst, wie kooperativ wir in einem Interview sind. Fatal ware es, wenn der Befragte vor dem Fragenden etwas zubefurchten hatte. Bsp.: So ware der Ladenbesitzer eher ungeeignet, Fragen zum Thema Auslastung und Schwachen derVerkaufer zu stellen, wenn sie zu befurchten haben, dass ihnen aus ehrlichen Antworten negative Konsequenzenerwachsen konnten. �

• Was sind die moglichen Grunde fur die Antwort der Befragten? Der Befragte konnte uns einen Gefallen tun wollen oderwill uns sabotieren. Er konnte bewusst oder unbewusst falsche Antworten liefern, weil er hinter den Fragen einbestimmtes Ziel vermutet, mit dem er nicht einverstanden ist.

Anforderungsanalyse

Fragetypen: Geschlossene Fragen

Geschlossene Fragen:

Welche Qualitat hat die GUI? Bitte ankreuzen.� sehr gut� gut� schlecht� weiß nicht

Antwortalternativen vorgegeben

auch Mehrfachantworten



Geschlossene Fragen:

Welche Qualitat hat die GUI? Bitte ankreuzen.� sehr gut� gut� schlecht� weiß nicht

Antwortalternativen vorgegeben

auch Mehrfachantworten

20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Ist-Analyse


Fragen konnen in drei unterschiedlichen Formen verfasst sein: geschlossene, offene oder hybride Fragen. Sieunterscheiden sich durch die Form der Antworten, die auf sie moglich sind.

Bei geschlossenen Fragen sind alternative Antworten bereits vorgegeben, aus denen der Befragte eine odergegebenenfalls mehrere auswahlen kann. Haufig findet man solche Fragen fur Aspekte, die anhand einer Skalaeingeschatzt werden sollen, also zum Beispiel die Frage, ob einem die GUI sehr gut, gut oder nicht gefallt.

Durch die Vorgabe moglicher Antworten schafft man eine Normierung und kann die Antworten leicht automatisiertstatistisch auswerten.

Diesen Fragentyp kann man gut einsetzen, wenn man die moglichen Antworten gut vorwegsehen kann. Wenn manalso bereits eine bestimmte Hypothese hat, kann man sie durch solche Fragen leicht uberprufen. In Bereichen, indenen man jedoch die Antworten nur schlecht abschatzen kann, besteht die Gefahr, dass die Antwort, die jemandeigentlich geben mochte, nicht dabei ist. Hier sind solche Fragetypen eher ungeeignet. In jedem Falle sollte es beider Antwort immer moglich sein, dass der Befragte die Frage nicht beantworten kann oder will, um erzwungeneFalschantworten zu vermeiden.

Anforderungsanalyse

Fragetypen: Offene Fragen

Offene Fragen:

Wie sollte die GUI verbessert werden?

Antworten in eigenen Worten, im eigenen Referenzsystem

erfordert Ausdrucksfahigkeit der Befragten

starker Einfluss des Fragenden, wenn prasent (durch Aufschreiben,Weglassen)

hoher Auswertungsaufwand



Offene Fragen:

Wie sollte die GUI verbessert werden?

Antworten in eigenen Worten, im eigenen Referenzsystem

erfordert Ausdrucksfahigkeit der Befragten

starker Einfluss des Fragenden, wenn prasent (durch Aufschreiben,Weglassen)

hoher Auswertungsaufwand

20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Ist-Analyse


Offene Fragen sind solche, bei denen keine Antwort vorgegeben wird. Der Befragte beantwortet die Frage mitseinen eigenen Worten. Dazu kann er seine eigene Terminologie benutzen. Dies erfordert vom Befragten, dass ersich selbst ausdrucken kann. Da jede Antwort moglich ist, kann der Befragte in seiner Formulierung stark durch denanwesenden Fragenden beeinflusst werden. Dies gilt umso mehr, wenn nicht der Befragte die Antwortenaufschreibt, sondern der Fragende, wie das meist ublich ist. Dadurch werden die Aussagen vom Fragenden oftgefiltert und aufbereitet, statt nur wortlich wiedergegeben. Das Mindeste, was man dann tun sollte, ist es, demBefragten das Protokoll seiner Antworten nochmals zur Kontrolle vorzulegen, um sicher zu stellen, dass man seineAussagen korrekt wieder gegeben hat.

Da die Antworten nicht vorgegeben sind, muss ein Mensch sie durchlesen, verstehen und einordnen. Damit ist dieAuswertung erheblich aufwandiger als bei geschlossenen Fragen. Dem hohen Auswerteaufwand steht als Vorteilgegenuber, dass man die Antworten nicht schon beim Entwurf des Fragebogens vorwegsehen muss, wie das beigeschlossenen Fragen der Falle ist. Man hat also die Chance, Neues zu erfahren. Aus diesem Grund wendet mandiesen Fragetyp an, wenn man noch keine rechte Hypothese zu den moglichen Antworten hat.

Anforderungsanalyse

Fragetypen: Hybride Fragen

Hybride Fragen:

Was stort Sie an der GUI?� lange Reaktionszeit� mangelnde Selbsterklarungsfahigkeit� fehlendes

”Undo“

� umstandliche Dialogfuhrung�

Kombination von geschlossenen und offenen Fragen



Hybride Fragen:

Was stort Sie an der GUI?� lange Reaktionszeit� mangelnde Selbsterklarungsfahigkeit� fehlendes

”Undo“

� umstandliche Dialogfuhrung�

Kombination von geschlossenen und offenen Fragen

20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Ist-Analyse


Hybride Antworten kombinieren geschlossene und offene Fragen, indem eine Menge alternativer Antwortenvorgegeben wird, es aber dennoch moglich ist, durch Freitextfelder eigene Antworten zu formulieren. Dies ist invielen Fallen ein guter Kompromiss, der leichte Auswertbarkeit und die Moglichkeit, unvorhergesehene Antwortenzu liefern, bestmoglich vereint, solange die vorgegebenen Antworten moglichst viele echte Antworten abdecken.

Anforderungsanalyse

Wann welche Erhebungsform?

weniger strukturiertes Interview

unstrukturiertesUntersuchungsgebiet

offene Gesprachsfuhrung undgroßere Antwortspielraume

personlicher Kontakt moglich

Ortsbegehung moglich

stark strukturierter Fragebogen

vorstrukturiertesUntersuchungsgebiet

gute Kenntnisse desUntersuchungsgebiets

Operationalisierung derHypothesen moglich



weniger strukturiertes Interview

unstrukturiertesUntersuchungsgebiet

offene Gesprachsfuhrung undgroßere Antwortspielraume

personlicher Kontakt moglich

Ortsbegehung moglich

stark strukturierter Fragebogen

vorstrukturiertesUntersuchungsgebiet

gute Kenntnisse desUntersuchungsgebiets

Operationalisierung derHypothesen moglich

20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Ist-Analyse


Welche Form der Erhebung, ob stark oder weniger strukturiertes Vorgehen, nun angemessen ist, hangt imWesentlichen davon ab, wie gut wir unser Untersuchungsgebiet bereits durchdrungen haben.

In einer fruhen Phase, in der wir uns noch wenig auskennen und mogliche Antworten nicht vorweg sehen konnen,werden wir eher ein weniger strukturiertes Interview durchfuhren. Das Gesprach kann offen gefuhrt werden, und derBefragte hat einen großeren Spielraum bei Antworten. Der Fragende kann spontaner auf die Situation reagieren.Der personliche Kontakt und die Ortsbegehung werden uns weitere Einblicke gewahren.

Ist unser Untersuchungsgebiet bereits gut vorstrukturiert, dann kommt auch ein strukturierteres Vorgehen in Frage.Da wir bereits uber gute Kenntnisse des Untersuchungsgebiets verfugen, sind wir in der Lage, operationaleHypothesen aufzustellen, das heißt, Hypothesen, die wir objektiv durch Fragebogen uberprufen konnen.

Anforderungsanalyse

Frageformulierung

einfache Worte

kurz und konkret

keine doppelten Negationen

nur auf einen Sachverhalt bezogen

nicht hypothetisch

neutral, nicht suggestiv

Befragten nicht uberfordern

balanciert (negative und positive Antwortmoglichkeiten)

immer eine”weiß-nicht“-Kategorie bieten


Frageformulierung

einfache Worte

kurz und konkret

keine doppelten Negationen

nur auf einen Sachverhalt bezogen

nicht hypothetisch

neutral, nicht suggestiv

Befragten nicht uberfordern

balanciert (negative und positive Antwortmoglichkeiten)

immer eine”weiß-nicht“-Kategorie bieten2

00

9-0

2-0

9

Software-Projekt

Anforderungsanalyse

Ist-Analyse

Frageformulierung

Auch uber die Formulierung der Fragen muss man sich vorher sorgfaltig Gedanken machen, da sie einen Einfluss aufdie Antwort hat. Man wahle moglichst einfache, klare Worte, so dass die Frage sicher verstanden werden kann. DieFragen sollten kurz und konkret sein. Lange Fragen beinhalten viele Aspekte, auf die man kaum eine klare,abgeschlossene Antwort geben kann. Auf abstrakte Fragen fallt die Antwort schwer. Doppelt negierte Fragen gilt eszu vermeiden, um den Befragten nicht zu verwirren. Gleichermaßen sollte man auf hypothetische Fragen mit vielenKonjunktiven verzichten. Ansonsten kann eine negative Antwort unterschiedliche Ursachen haben: die, die sich aufden eigentlichen Frageinhalt beziehen, oder jene, die die Pramissen in Frage stellen. Die Frage sollte neutral undnicht suggestiv gestellt werden, ansonsten legt man dem Befragten die Antwort bereits in den Mund. Man sollteeine gleiche Anzahl negativer und positiver Antwortmoglichkeiten vorsehen. Eine Disbalance von entwedernegativen oder positiven Fragen wirkt suggestiv. Außerdem gibt es eine menschliche Tendenz, eher positiv zuantworten. Auch bei geschlossenen Fragen sollte es stets moglich sein, dass der Befragte aussagen kann, dass er aufeine Frage nicht antworten kann oder will, um erzwungene Falschaussagen zu vermeiden.

Anforderungsanalyse

Beobachtung

Prinzipien der Ethnographie (teilnehmende Beobachtung in derFeldforschung):

Naturliche Umgebung

→ Aktivitaten 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 fur den Handelnden relevantund bedeutungsvoll sind


Beobachtung

Prinzipien der Ethnographie (teilnehmende Beobachtung in derFeldforschung):

Naturliche Umgebung

→ Aktivitaten 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 fur den Handelnden relevantund bedeutungsvoll sind2

00

9-0

2-0

9

Software-Projekt

Anforderungsanalyse

Ist-Analyse

Beobachtung

In der Befragung adressieren wir hauptsachlich das bewusste Wissen. Wir haben weiter oben schon gelernt, dassdas nur rund ein Drittel des menschlichen Wissens ausmacht. Durch Beobachtung konnen wir uns noch weiteresWissen erschließen.

In der Sozialwissenschaft hat sich die Ethnographie als Technik etabliert. Die Ethnographie ist eine teilnehmendeBeobachtung. Es hat offensichtlich keinen Sinn, das Leben von Urvolker zu ergrunden, indem man sie ihrer Heimatentreißt und sie im Labor untersucht. Eigenschaften von Sozialgemeinschaften sind abhangig vom Kontext undmussen deshalb in diesem Kontext untersucht werden.

Die Ethnographie folgt bei der Beobachtung einer Reihe von Prinzipien:

• Die soziale Gemeinschaft wird in ihrer naturlichen Umgebung beobachtet. Auf diese Weise werden ihre Aktivitaten in derAlltagsumgebung untersucht.

• Das Einzelverhalten wird im Kontext untersucht. Verhaltensweisen sind meist sehr komplex und lassen sich nur schwerisolieren und kontrollieren, wie das fur Laborversuche versucht wird.

• Im Vordergrund steht das neutrale Beschreiben und nicht die Bewertung. Wertung sozialen Handelns orientiert sich anmoralischen Maßstaben, die jedoch kontextabhangig sind. Setzen wir uns die eigene moralische Brille auf, werden wirmeist schlechtsichtiger und ubersehen wichtige Details. Wir sind bei der Ist-Analyse am Ist- und nicht am Soll-Verhalteninteressiert.

• Wir versuchen, die Sicht der Handelnden einzunehmen, d.h. wir beschreiben das Verhalten in Begriffen, die fur denHandelnden relevant und bedeutungsvoll sind.

Die Einhaltung dieser Prinzipien sichert uns einen besseren Einblick.

Anforderungsanalyse

Interview im Kontext

ist eine Form der ethnographischen Untersuchung

nach dem Meister-Lehrling-Modell

Lernen durch Vormachen und Beobachten sowie Fragen und Klaren

gepragt durch

BescheidenheitNeugierAufmerksamkeitkonkrete (statt abstrakter) Fragen



ist eine Form der ethnographischen Untersuchung

nach dem Meister-Lehrling-Modell

Lernen durch Vormachen und Beobachten sowie Fragen und Klaren

gepragt durch

BescheidenheitNeugierAufmerksamkeitkonkrete (statt abstrakter) Fragen

20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Ist-Analyse


Eine spezielle Form der ethnographischen Untersuchung ist das Interview im Kontext. Es orientiert sich amMeister-Lehrling-Modell. Lernen findet hier in der Beobachtung des Meisters, im aktiven Nachfragen und Zeigensowie im Mitmachen statt. Statt in einem Frontalunterricht im Horsaal zu theoretisieren, nimmt der Meister seinenLehrling mit auf die Baustelle. Der Meister arbeitet vor und der Lehrling lernt aus der Beobachtung. Der Lehrlingfragt nach, wenn ihm etwas nicht klar ist, und er versucht sich auch selbst. Das Meister-Lehrling-Modell ist gepragtdurch Bescheidenheit, Neugier, Aufmerksamkeit und konkrete (statt abstrakter) Fragen des Lehrlings imunmittelbaren Kontext.

Anforderungsanalyse

Beispiel eines Ablaufes

1 Einleitung (15 min)Vorstellung, Ziele, DankZustimmung zu Aufzeichnung, VertraulichkeitArbeit, nicht Person wird betrachtet!Meinungen zu technischer Unterstutzung?Uberblick gewinnen

2 Ubergang (1 min)Regeln, Rollen, Beziehungich frage, Sie durfen abwehren

3 Erhebung im Kontext (2 Std.)Beobachtung und NachfragenNotizen machen, mitlaufen, sich unsichtbar machenPausen nach Wunsch

4 Zusammenfassung (15 min)was die Beschaftigte tut, ihre Rollewas wichtig istErganzungen, Korrekturen?



1 Einleitung (15 min)Vorstellung, Ziele, DankZustimmung zu Aufzeichnung, VertraulichkeitArbeit, nicht Person wird betrachtet!Meinungen zu technischer Unterstutzung?Uberblick gewinnen

2 Ubergang (1 min)Regeln, Rollen, Beziehungich frage, Sie durfen abwehren

3 Erhebung im Kontext (2 Std.)Beobachtung und NachfragenNotizen machen, mitlaufen, sich unsichtbar machenPausen nach Wunsch

4 Zusammenfassung (15 min)was die Beschaftigte tut, ihre Rollewas wichtig istErganzungen, Korrekturen?

20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Ist-Analyse


Ein Interview im Kontext dauert in der Regel zwei Stunden plus direkte Vor- und Nachbearbeitung. Es konnte wiefolgt ablaufen:

1. In einer Einleitung (15 min) stellt sich der Fragende kurz vor und erlautert das Ziel der Befragung. Er vergisst nicht,sich ausdrucklich fur das Interview zu bedanken. Er sichert absolute Vertraulichkeit zu und vergewissert sich uber dasEinverstandnis des Befragten. Er weist darauf hin, dass die Arbeit betrachtet werden soll und nicht die Person. Mankann technische Hilfen fur das Interview mitbringen, wie z.B. ein Audio- oder Videoaufnahmegerat. Wenn das der Fallist, holt man sich spatestens jetzt noch das Einverstandnis des Beobachteten ein.

2. Im Ubergang zur Erhebung im Kontext (1 min) bespricht man die Regeln, Rollen und die Beziehung zwischenBeobachter und Beobachtetem. Die Rolle des Beobachters ist es, zu beobachten und Fragen zu stellen. Die Rolle desBeobachteten ist es, sich moglichst wie gewohnlich zu verhalten. Eine Grundregel lautet, dass der Beobachtete Fragenauch abwehren darf.

3. Der Hauptteil ist die Erhebung im Kontext, die zwei Stunden moglichst nicht uberschreiten sollte, weil spatestens danndie Konzentration auf beiden Seiten nachgelassen hat. In der Erhebung beobachtet man und fragt nach. Man machtsich Notizen, lauft mit, macht sich aber moglichst unsichtbar, um das beobachtete Geschehen so wenig wie moglich zubeeinflussen. Pausen konnen nach Wunsch gemacht werden.

4. In der Zusammenfassung (15 min), erlautert man, was man beobachtet hat und lasst den Beobachteten korrigieren underganzen. Der Beobachtete erlautert sein Tun und seine Rolle und weist auf Wichtiges hin.

Anforderungsanalyse

Wegweiser

Soll-Analyse

Wie konnen wir dem Benutzer fruhzeitig einkonkretes Bild vermitteln, wie wir das Problem zu

losen gedenken?


Wegweiser

Soll-Analyse

Wie konnen wir dem Benutzer fruhzeitig einkonkretes Bild vermitteln, wie wir das Problem zu

losen gedenken?

20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Soll-Analyse: Prototyping

Wegweiser

Durch Analyse von Dokumenten, Beobachtungen und Fragen haben wir den Ist-Zustand erfasst. Die Analyse desErfassten deckt die Schwachstellen auf, die wir mit einer softwaretechnischen Losung beseitigen sollen. Der nachsteSchritt ist nun auszuarbeiten, was die softwaretechnische Losung dazu leisten muss. Dieser Aufgabe widmet sichdie Soll-Analyse. Die Soll-Analyse muss die Anforderungen an die zu implementierende Software aufstellen. Dazugehort es auch, diese Anforderungen hinsichtlich ihrer Machbarkeit und Folgen einzuschatzen. In diesem Abschnittlernen wir eine Technik kennen, mit der wir sowohl Anforderungen uberprufen als auch technische Machbarkeituntersuchen konnen.

Beobachtungen setzen den beobachteten Gegenstand voraus. Somit zielen Beobachtungen klar auf den Ist-Zustandab. Unsere softwaretechnische Losung existiert aber noch nicht. Fragen hingegen sind sowohl hilfreiche Mittel furdie Ist-Analyse als auch fur die Soll-Analyse. Wir konnen z.B. die Benutzer fragen, wie etwas sein soll. Auf welcheProbleme wir dabei allerdings stoßen, haben wir schon ganz zu Anfang bei der Einfuhrung zur Anforderungsanalysebesprochen. Die Benutzer konnen oft auf Problem hinweisen, sie tun sich oft aber schwerer, eine geeignete Losungzu ersinnen. Insbesondere fehlt ihnen dazu meist die realistische Einschatzung zur technischen Machbarkeit, fur diesie einen softwaretechnischen Hintergrund brauchten. Zudem richten sich Fragen an das bewusste Wissen und wirkonnen damit nur eingeschrankt relevante Aspekte erfassen.

Wenn aber Beobachtungen ausscheiden und Fragen nicht hinreichend sind, wie konnen wir dann vorgehen? Es gibtdas geflugelte Wort des Benutzers: I know it when I see it. Ich weiß, was ich will, sobald ich es sehe. Dieses Prinzipkonnen wir umsetzen: Wir fuhren dem Benutzer unsere Losung vor, zu der er dann Stellung nehmen kann.Naturlich konnen wir uns es nicht leisten, gleich das gesamte System zu implementieren, denn der Schaden waregroß, wenn diese Losung dann doch nicht das war, was der Benutzer haben mochte. Statt dessen implementierenwir einen so genannten Prototypen.

Anforderungsanalyse

Prototyping

Zielsetzung:

Anforderungen anhand eines Beispiels erheben und uberprufen

technische Moglichkeiten uberprufen und demonstrieren

fruhzeitig mogliche Losungsansatze prasentieren

Idee:

rasche und billige Entwicklung eines prototypischen Systems alsDiskussionsgrundlage

Typen unterscheiden sich in . . .

Lebensdauer: Wegwerfprototyp, evolutionarer Prototyp

Zweck: technische Machbarkeit, Demonstration der Funktionalitatoder Interaktion


Prototyping

Zielsetzung:

Anforderungen anhand eines Beispiels erheben und uberprufen

technische Moglichkeiten uberprufen und demonstrieren

fruhzeitig mogliche Losungsansatze prasentieren

Idee:

rasche und billige Entwicklung eines prototypischen Systems alsDiskussionsgrundlage

Typen unterscheiden sich in . . .

Lebensdauer: Wegwerfprototyp, evolutionarer Prototyp

Zweck: technische Machbarkeit, Demonstration der Funktionalitatoder Interaktion2

00

9-0

2-0

9

Software-Projekt

Anforderungsanalyse


Prototyping

Prototypen sind Zwischenprodukte in der Entwicklung, die dem Endprodukt in bestimmten relevanten Aspektenbereits stark ahneln sollen, die aber noch nicht vollstandig sind. Eine andere Sichtweise von Prototypen ist es, sieals ein kostengunstigeres Modell fur das Endprodukt zu betrachten.

Prototypen sind in anderen Ingenieursdisziplinen allgegenwartig. Architekten lassen dreidimensionalemaßstabsgetreue kleine Modelle eines Gebaudes anfertigen. Ein zukunftiger Bewohner kann auf diese Weise einenwesentlich lebendigeren Eindruck erhalten als es ihm mit einem Bauplan moglich ware. Flugzeugbauer erproben anPrototypen den Windwiderstand im Windkanal.

Diese Idee ubernimmt die Softwaretechnik. Die Ziele hierbei sind meist, die Anforderungen anhand eines Beispielszu erheben und uberprufen, technische Moglichkeiten zu uberprufen und demonstrieren oder fruhzeitig moglicheLosungsansatze zu prasentieren (letztere Prototypen werden auch als Demonstratoren bezeichnet). Die Idee derPrototypen in der Softwaretechnik ist dieselbe wie bei anderen Ingenieursdisziplinen: die rasche und billigeEntwicklung eines prototypischen Systems zur Erprobung.

Unter dem Begriff Prototypen versammeln sich in der Softwaretechnik aber sehr unterschiedliche Formen. Mankann sie unterscheiden anhand zweier unterschiedlicher Merkmale: zum einen anhand der Lebensdauer(Wegwerfprototyp, evolutionarer Prototyp), zum anderen anhand des Zwecks (Uberprufung der technischenMachbarkeit oder Demonstration der Funktionalitat oder Interaktion).Wir werden sie im Folgenden naher kennen lernen.

Anforderungsanalyse

Typen von Prototypen in Bezug auf Lebensdauer

Wegwerf-Prototyp:

beschreibt ein Softwaresystem exemplarisch

dient zur Erhebung und Analyse von Anforderungen oder zurUberprufung technischer Machbarkeit

demonstriert die Funktionalitat, die mit Stakeholdern diskutiertwerden soll

implementiert nicht notwendigerweise die gezeigte Funktionalitat(z.B. GUI-Prototyp)

ist als Komponente fur das Endprodukt ungeeignet, weil billig erstellt



Wegwerf-Prototyp:

beschreibt ein Softwaresystem exemplarisch

dient zur Erhebung und Analyse von Anforderungen oder zurUberprufung technischer Machbarkeit

demonstriert die Funktionalitat, die mit Stakeholdern diskutiertwerden soll

implementiert nicht notwendigerweise die gezeigte Funktionalitat(z.B. GUI-Prototyp)

ist als Komponente fur das Endprodukt ungeeignet, weil billig erstellt

20

09

-02

-09

Software-Projekt

Anforderungsanalyse



Der Wegwerfprototyp hat eine sehr begrenzte Lebensdauer. Er wird in keinem Fall zum Endprodukt werden. SeinZiel ist es, einen Aspekt – sei es Funktionalitat oder Interaktion – exemplarisch zu untersuchen oder zudemonstrieren. Dazu wird der relevante Aspekt mit moglichst billigen Mitteln realisiert (nicht notwendigerweiseimmer dadurch, dass tatsachlich Code geschrieben wird; siehe unten). Alle anderen Aspekte sind nicht realisiert.Weil der Prototyp unvollstandig ist und mit billigen Mitteln erstellt wird, ist er fur das Endprodukt ungeeignet –daher sein Name. Hat er den Aspekt demonstriert, wird er weggeworfen.

Anforderungsanalyse


Evolutionarer Prototyp:

dient zur schnellen Bereitstellung eines funktionsfahigen Systems imRahmen von evolutionaren Prozessmodellen zur Softwareentwicklung

wird in weiteren Ausbaustufen zum endgultigen Produktweiterentwickelt



Evolutionarer Prototyp:

dient zur schnellen Bereitstellung eines funktionsfahigen Systems imRahmen von evolutionaren Prozessmodellen zur Softwareentwicklung

wird in weiteren Ausbaustufen zum endgultigen Produktweiterentwickelt

20

09

-02

-09

Software-Projekt

Anforderungsanalyse



Im Gegensatz zum Wegwerf-Prototypen ist es beim evolutionaren Prototypen vorgesehen, ihn schrittweise zumEndprodukt auszubauen. Er dient dazu, ein funktionsfahiges Systems moglichst schnell bereit zu stellen, wobei aberzu Anfang nicht die vollstandige Funktionalitat erwartet wird. Evolutionare Prototypen finden ihren Einsatz unteranderem im Rahmen von evolutionaren Prozessmodellen zur Softwareentwicklung.

Der Vorteil dieser inkrementellen Entwicklung ist es, dass jede funktionstuchtige Ausbaustufe vom Benutzer erprobtwerden kann. Die Erfahrung und Kritik der Benutzer mit der Ausbaustufe nimmt Einfluss auf die nachsteAusbaustufe. Iterativ wird der evolutionare Prototyp in weiteren Ausbaustufen zum endgultigen Produktweiterentwickelt.

Bsp.: Die Ausbaustufen fur die evolutionare Entwicklung eines Textverarbeitungssystems konnten zum Beispiel soaussehen:

1. grundlegende Funktionalitat: Datei-Management, Editor, Textausgabe

2. erweiterte Funktionalitat: Style-Files, Bearbeitung mathematischer Formeln, Einbinden von Graphiken

3. zusatzliche Funktionalitat: Rechtschreibprufung, Grammatikuberprufung, Uberarbeitungsmodus

4. erganzende Funktionalitat: Tabellenkalkulation, Geschaftsgraphiken, E-Mail, Web-Browser, Scanner-Anbindung

�

Anforderungsanalyse

Typen von Prototypen in Bezug auf Zweck

Technischer Prototyp:

zeigt die technische Umsetzbarkeit von Ansatzen zur Problemlosung

implementiert einen (kleinen) Ausschnitt der Funktionalitat desSystems

wird eher zur Machbarkeitsabschatzung und -demonstration eingesetzt



Technischer Prototyp:

zeigt die technische Umsetzbarkeit von Ansatzen zur Problemlosung

implementiert einen (kleinen) Ausschnitt der Funktionalitat desSystems

wird eher zur Machbarkeitsabschatzung und -demonstration eingesetzt

20

09

-02

-09

Software-Projekt

Anforderungsanalyse



Wegwerfprototypen und evolutionare Prototypen unterscheiden sich anhand ihrer Lebensdauer. Ein vollig anderesUnterscheidungsmerkmal ist der Zweck, den man mit dem Prototypen verfolgt. Technische Prototypen zielen aufdie technische Umsetzbarkeit von Ansatzen zur Problemlosung. Dazu implementiert der Prototyp einen (kleinen)Ausschnitt der Funktionalitat des Systems. Technische Prototypen werden somit eher zur Machbarkeitsabschatzungund -demonstration eingesetzt. Sie gleichen dem Crash-Test-Stand, mit dessen Hilfe man das Verhalten vonKarosserien im Automobilbau untersucht.

Technische Prototypen konnen sowohl fur den Wegwurf oder den evolutionaren Ausbau vorgesehen sein. Siekonnen sich des Weiteren unterschieden in Bezug auf die Softwarearchitektur.

Anforderungsanalyse

Horizontaler vs. vertikaler technischer Prototyp

Horizontaler Prototyp: realisiert Aspekte einer spezifischen Ebene desSoftwaresystems; Bsp: Oberflachenprototyp

System−Software

Netzwerk Datenhaltung

Anwendungslogik

Benutzungsschnittstelle


Anforderungsanalyse


Horizontaler Prototyp: realisiert Aspekte einer spezifischen Ebene desSoftwaresystems; Bsp: Anwendungsprototyp

System−Software


Anwendungslogik




Horizontaler Prototyp: realisiert Aspekte einer spezifischen Ebene desSoftwaresystems; Bsp: Anwendungsprototyp

System−Software


Anwendungslogik

Benutzungsschnittstelle2

00

9-0

2-0

9

Software-Projekt

Anforderungsanalyse



Softwaresysteme konnen zumindest konzeptionell in verschiedene Schichten eingeteilt werden, die jeweils vonbestimmten Aspekten abstrahieren. Grob kann die Implementierung einteilen in die Schicht der Systemsoftware, diedurch das Betriebssystem zur Verfugung gestellt wird, Schichten mit technischen Diensten, wieNetzwerkkommunikation oder Datenhaltung, sowie die Schicht, die die eigentlich anwendungsspezifische Logikimplementiert und die Schicht der Benutzungsschnittstelle, die die Interaktion mit dem Benutzer ubernimmt.

Hinsichtlich dieses konzeptionellen Aufbaus, kann man technische Prototypen weiter in horizontale und vertikalePrototypen unterscheiden.

Der horizontale technische Prototyp realisiert Aspekte einer spezifischen Ebene des Softwaresystems. DerAnwendungsprototyp implementiert zum Beispiel die Anwendungslogik und der Oberflachenprototyp dieBenutzungsschnittstelle. Hiermit untersucht oder demonstriert man die Funktionalitat einer ausgesuchten Schicht.

Da eine Schicht auf die andere aufbaut, aber nur eine Schicht implementiert wird, benotigen wir neben derImplementierung der relevanten Schicht selbst noch einen Simulator fur die Schicht, auf die sich die relevanteSchicht stutzt. Man kann diese als Stumpf implementieren. Ein Stumpf bietet nicht die volle Funktionalitat,sondern liefert auf die Anfragen der hoheren Schicht einfach nur vorgefertigte Ergebnisse. Oberflachenprototypenkonnen zum Beispiel so implementiert werden, dass die Anwendungsschicht alle Daten, die in der Oberflache furbestimmte Anwendungsszenarien sichtbar sein sollen, in internen Tabellen abgespeichert hat und sie ohne weitereBerechnungen einfach als Ergebnis einer aufgerufenen Operation zuruck liefert. Damit zeigt der Oberflachentypmoglicherweise falsche Daten an, aber zumindest die Interaktion lasst sich demonstrieren.

Anforderungsanalyse


Vertikaler Prototyp: realisiert ausgewahlte Aspekte des Softwaresystemsvollstandig

System−Software


Anwendungslogik




Vertikaler Prototyp: realisiert ausgewahlte Aspekte des Softwaresystemsvollstandig

System−Software


Anwendungslogik

Benutzungsschnittstelle2

00

9-0

2-0

9

Software-Projekt

Anforderungsanalyse



Der vertikale technische Prototyp realisiert ausgewahlte Aspekte des Softwaresystems vollstandig durch alleSchichten hindurch. Er stellt einen Durchstich durch das System dar. Mit seiner Hilfe lasst sich die Zusammenarbeitverschiedener Schichten untersuchen. Er findet auch bei inkrementeller Entwicklung Einsatz, bei der die ersteAusbaustufe funktionstuchtig ist (wenn auch nicht alle Funktionen implementiert sind). Dann wird der Durchstichin die Breite in den weiteren Ausbausstufen ausgedehnt, um die restliche Funktionalitat zu implementieren. Mangeht also zuerst in die Tiefe und dann in die Breite bei diesem Vorgehen.

Wir setzen solche Prototypen wahrend der Anforderungsanalyse ein, wenn wir kritische Anforderungen haben, vondenen wir nicht sicher sind, dass wir sie realisieren konnen. Ansonsten werden sie auch gerne vor Entwurf derArchitektur angewandt, um einzusetzende Technologien oder geplante Entwurfe zu untersuchen.

Anforderungsanalyse

Prototypen fur Interaktion: Storyboards

Storyboards:

Prototypen fur die Interaktion zwischen Mensch und Maschine

demonstrieren das zu diskutierende Systemverhalten als”Geschichte“

Typen:

passives Storyboard (Papierprototyp)

aktives Storyboard (animierter Prototyp)

interaktives Storyboard (ausfuhrbarer Prototyp)��

��

Aufwand



Storyboards:

Prototypen fur die Interaktion zwischen Mensch und Maschine

demonstrieren das zu diskutierende Systemverhalten als”Geschichte“

Typen:

passives Storyboard (Papierprototyp)

aktives Storyboard (animierter Prototyp)

interaktives Storyboard (ausfuhrbarer Prototyp)��

��

Aufwand20

09

-02

-09

Software-Projekt

Anforderungsanalyse



In der Anforderungsanalyse mussen wir die Interaktion zwischen Benutzer und Anwender festlegen. DieserInteraktion nimmt eine Schlusselrolle ein, weil ein Softwaresystem, das alle gewunschten Funktionalitaten bietet,dennoch unbrauchbar sein kann, wenn man es nicht benutzen kann. Aus diesem Grunde wollen schon sehr fruh,Interaktion ausprobieren konnen und sie Kunden und Benutzern vorstellen. Hier konnen wir Oberflachenprototypenentwickeln.

Oberflachenprototypen sind horizontale Prototypen, bei denen die Interaktion untersucht oder demonstriert werdensoll. Meist dienen sie weniger der technischen Machbarkeit, sondern vielmehr der konzeptionellen Angemessenheitund Schlussigkeit. Wir untersuchen damit, ob der Benutzer spater mit unserem System effizient und effektivinteragieren kann.

Dem Oberflachenprototypen kommt unter den Prototypen eine Sonderstellung zu, weil es die Oberflache ist, die derBenutzer spater sehen und bedienen wird. Alle anderen Schichten sind fur ihn unsichtbar. Wenn wir die von unseinzusetzenden Implementierungsechnologien bereits sicher beherrschen, konnen wir auf solche technischePrototypen tieferer Schichten verzichten. Weil wir aber in der Anforderungsspezifikation auch dieBenutzungsschnittstelle beschreiben mussen und die Qualitat einer Software aus Benutzersicht steht und fallt mitihrer Benutzbarkeit, sind Oberflachenprototypen fur die Anforderungsanalyse unerlasslich.

Aus diesem Grunde genießen Oberflachenprototypen hier unser Hauptaugenmerk. Wir unterscheiden dabei diefolgenden Typen:

• passives Storyboard (Papierprototyp)

• aktives Storyboard (animierter Prototyp)

• interaktives Storyboard (ausfuhrbarer Prototyp)

Alle Typen von Storyboards beschreiben die zukunftige Interaktion mit dem System als eine Art Drehbuch, daherihr Name. Sie unterscheiden sich jedoch im Grad ihrer Interaktivitat. Das interaktive Storyboard bietet dabei diehochste Interaktivitat. Mit dem Grad der Interaktivitat steigen aber auch die Kosten fur die Entwicklung desStoryboards. Wir werden im Folgenden diese drei Typen naher beschreiben.

Anforderungsanalyse

Passive Storyboards

Demonstration:

Analytiker spielt die Bedienung mit dem System durch, indem erentlang eines Anwendungsszenarios Eingabemoglichkeiten undSystemreaktionen demonstriert

Mittel:

Skizzen

Bildschirm-Masken (Screenshots)

mogliche Systemausgaben

Bemerkung:

+ ermoglicht einfache und billige Prototyperstellung

+ ermoglicht Interaktion mit Beteiligten am Beispiel

- erfordert Anwesenheit des Analytikers


Passive Storyboards

Demonstration:


Mittel:

Skizzen



Bemerkung:



- erfordert Anwesenheit des Analytikers20

09

-02

-09

Software-Projekt

Anforderungsanalyse


Passive Storyboards erlauben selbst keine Interaktion. Statt dessen spielt der Analytiker bei der Demonstration dieBedienung mit dem System durch, indem er entlang eines Anwendungsszenarios die Eingabemoglichkeiten undSystemreaktionen demonstriert.

Als Mittel werden Skizzen, Bildschirm-Masken in Form von Bildschirmabzugen (Screenshots) und moglicheSystemausgaben verwendet. Die einfachsten Materialien sind Papier und Bleistift. Dafur sprechen die besonderseinfache und billige Prototyperstellung sowie die Moglichkeit zur Interaktion mit den Beteiligten am konkretenBeispiel. Der Benutzer selbst kann mit diesen Materialien selbst umgehen und an der Entwicklung des Prototypendirekt mitwirken.

Passive Storyboards

Demonstration:


Mittel:

Skizzen



Bemerkung:



- erfordert Anwesenheit des Analytikers20

09

-02

-09

Software-Projekt

Anforderungsanalyse


Beispiel passives Storyboard

Bsp.: Unsere Analyse der Schwachstellen in der Ist-Analyse zu unserem Fahrradladenbeispiel hat ergeben, dass esoft schwierig ist, einen Kunden beim Einkauf eines Artikels fur ein Fahrrad, das sich schon in seinem Besitzbefindet, richtig zu beraten, weil er nicht weiß, welche Daten das Fahrrad hat. Wenn er einen Flaschenhalter kaufenmochte, so muss er zu den Ausmaßen und Bohrungen sowie der Farbe des Rahmens passen. Wenn er sie nichtkennt, kann ihm der Verkaufer keine Empfehlung aussprechen.

Wir haben uns entschlossen, einen Einkaufsassistenten auf Basis eines PDAs zu entwickeln. Auf diesem tragbarenKleinrechner sind alle Einkaufe des Kunden erfasst und zwar branchenubergreifend, also Fahrradteile genauso wieComputer-Hardware etc. Wir mochten dem Benutzer die zukunftige Interaktion mit einem solchen PDAdemonstrieren. Die Interaktion mit einem PDA hat besondere Herausforderungen, weil die darstellbare Flache sehrbegrenzt und typische Eingabegerate wie Maus und Tastatur nicht vorhanden sind.

Bild 1: Wir fertigen einen Papierprototypen an, indem wir einen realen PDA hernehmen und die dargestelltenElemente zeichnen und auf das Display legen. Das Bild zeigt die Einstiegsmaske mit den Produktgruppen desKaufers, die mit dem PDA verwaltet werden. Im Fahrradladen wahlt er das Fahrradsymbol aus, wenn er einenArtikel fur sein Fahrrad kaufen mochte. Dadurch gelangt er zum nachsten Dialog. �

Anforderungsanalyse


abfragenändernentfernenersetzen



abfragenändernentfernenersetzen

20

09

-02

-09

Software-Projekt

Anforderungsanalyse



Bsp.: Bild 2: Im nachsten Dialog wird sein Fahrrad angezeigt. Er kann dann mit dem Stift auf ein Bestandteilseines Rades tippen. Darauf hin wird ein Menu eingeblendet, in dem er die nachste Aktion auswahlen kann. Er kanneinen Artikel abfragen, um Daten uber ihn abzufragen, andern, um den Artikel in seinen Eigenschaften zu andern,entfernen, um ihn aus seiner Konfiguration zu loschen, oder ersetzen, um ihn durch einen neuen Artikel zu ersetzen.�

Anforderungsanalyse


1

2

47 Euro

78 Euro

100 Euro

145 Euro3

4

5

6



1

2

47 Euro

78 Euro

100 Euro

145 Euro3

4

5

6

20

09

-02

-09

Software-Projekt

Anforderungsanalyse



Bsp.: Bild 3: Nehmen wir an, wir wahlen den Sattel aus, und wahlen ersetzen. Dann gelangen wir zum nachstenDialog. Als nachstes werden alle Sattel angezeigt, die zum Fahrrad des Kunden passen, sortiert nach dem Preis. Eswerden maximal vier Artikel angezeigt. Diese Liste kann weiter verarbeitet werden, indem wir mit den Stift tippenoder die Tasten bedienen. Beruhren wir mit dem Stift das Bild des Sattels (1), den Beschreibungstext (2) oder denPreis, dann gelangen wir zum Kaufdialog. Bedienen wir auf dem Tastenfeld die Nach-Oben- (4) beziehungsweisedie Nach-Unten-Taste (5) konnen wir den sichtbaren Ausschnitt in der Liste der gefundenen Artikel nach obenbeziehungsweise nach unten bewegen. Mit der Auswahltaste (5) gelangen wir zum Kaufdialog. �

Anforderungsanalyse


1 2 1 2

8747 Euro

78 Euro

100 Euro

145 Euro 145 Euro

5 64 4 5 6

neinja

Artikel kaufen?Wollen Sie diesen

Screen Auswahl Screen Kaufen



1 2 1 2

8747 Euro

78 Euro

100 Euro

145 Euro 145 Euro

5 64 4 5 6

neinja



20

09

-02

-09

Software-Projekt

Anforderungsanalyse



Bsp.: Bild 4: Im Kaufdialog wird nur der ausgewahlte Artikel angezeigt und der Kunde wird gefragt, ob er denArtikel kaufen mochte. Bestatigt er mit der Schaltflache “Ja” (7), dann wird der Artikel in den virtuellenWarenkorb des elektronischen Verkaufsassistenten gelegt, der vom Verkaufer an der Kasse ausgelesen werden kann.Mit der Schaltflache “Nein” wird der Vorgang abgebrochen, und man gelangt zum Auswahldialog zuruck.

Die Entscheidung, maximal vier Artikel anzuzeigen, haben wir in der Vorbereitung des Papierprototypen getroffen.Wir hatten sehr schnell im maßstabgetreuen Modell feststellen konnen, dass mehr als vier Artikel nicht auf demkleinen Monitor zu prasentieren sind. Wir haben jedoch versaumt, irgendwie kenntlich zu machen, dass mehr alsvier Artikel als Ergebnis der Suchanfrage geliefert wurden, aber nicht alle sichtbar sind. Der Kunde fragt unswahrend der Vorfuhrung, wie das denn zu erkennen sei. Der Kunde nimmt dann einen roten Farbstift, zeichnetdafur rote Pfeile nach oben beziehungsweise unten uber dem ersten beziehungsweise letzten angezeigten Elementein und sagt uns, dass er das gerne so hatte. Wahrend wir dem Kunden diesen Prototypen vorfuhren, bemerktdieser außerdem, dass wir im Auswahldialog keine Moglichkeit vorgesehen haben, den Dialog durch einen anderenWeg als zum Kaufdialog zu verlassen. Uns ist also glucklicherweise fruh genug vom Kunden klar gemacht worden,dass wir in der Dialogfuhrung einige Dinge ubersehen haben. Die Uberarbeitung unseres Papierprototypen ist abereinfach. So einfach, dass es der Kunde gleich selbst ubernehmen konnte. �

Passive Storyboards eignen sich besonders in der fruhen Phase des Interaktions-Designs, in der man den Benutzeraktiv in den Design-Prozess einbeziehen mochte.

Anforderungsanalyse

Aktive Storyboards

Demonstration:

Abspielen einer selbstablaufenden Prasentation des Systemverhaltens

Mittel:

Film, Diashow

selbstablaufende Prasentation

Bemerkung:

+ ermoglicht einfache automatisierte Darstellung von typischenAnwendungsszenarien

+ erfordert nicht unbedingt die Anwesenheit von Analytikern

- erlaubt keine Interaktion wahrend der Prasentation


Aktive Storyboards

Demonstration:

Abspielen einer selbstablaufenden Prasentation des Systemverhaltens

Mittel:

Film, Diashow

selbstablaufende Prasentation

Bemerkung:

+ ermoglicht einfache automatisierte Darstellung von typischenAnwendungsszenarien

+ erfordert nicht unbedingt die Anwesenheit von Analytikern

- erlaubt keine Interaktion wahrend der Prasentation20

09

-02

-09

Software-Projekt

Anforderungsanalyse


Wahrend passive Storyboards durch den Analytiker demonstriert werden mussen, sind aktive StoryboardsPrasentationen des Systemverhaltens, die von selbst ablaufen. Sie laufen wie ein Film ab. Dazu kann mantatsachlich kontinuierliche Sequenzen wie in einem Film darstellen (z.B. mit Werkzeugen wie Macromedia Flashoder Camtesia) oder aber Einzelbilder der Dialoge (z.B. mit einer Prasentationssoftware wie OpenOffice oderPowerpoint) anzeigen.

Typische Anwendungsszenarien konnen automatisiert dargestellt werden. Weil ein aktives Storyboard von alleinablauft, ist die Anwesenheit von Analytikern nicht unbedingt erforderlich. Damit konnen solche Demos an eineVielzahl von moglichen Benutzern verschickt und deren Meinung eingeholt werden. Allerdings erlauben aktiveStoryboards keine Interaktion wahrend der Prasentation, was gerade in der fruhen Phase des Interaktions-Designswunschenswert ist.

Aktive Storyboards eignen sich besonders in einer fortgeschritteneren Phase des Interaktions-Designs, in der manein ausgearbeitetes Konzept sehr vielen Benutzern vorstellen mochte.

Anforderungsanalyse

Interaktive Storyboards

Demonstration:

Prototyp ermoglicht dem Benutzer die fruhzeitige Interaktion mit demmoglichen System; Funktionalitat kann evtl. durch Analytiker

”von

Hand“ simuliert werden

Mittel:

ausfuhrbares Programm, das Teile der Funktionalitat realisiert

Bemerkung:

+ ermoglicht Interaktion des Nutzers mit dem System

+ erlaubt großtmogliche Nahe zum realen System

- erfordert hoheren Aufwand bei Prototyp-Erstellung


Interaktive Storyboards

Demonstration:

Prototyp ermoglicht dem Benutzer die fruhzeitige Interaktion mit demmoglichen System; Funktionalitat kann evtl. durch Analytiker

”von

Hand“ simuliert werden

Mittel:

ausfuhrbares Programm, das Teile der Funktionalitat realisiert

Bemerkung:

+ ermoglicht Interaktion des Nutzers mit dem System

+ erlaubt großtmogliche Nahe zum realen System

- erfordert hoheren Aufwand bei Prototyp-Erstellung

20

09

-02

-09

Software-Projekt

Anforderungsanalyse


Interaktive Storyboards bieten die großtmogliche Interaktion mit dem System. Dazu wird ein ausfuhrbaresProgramm entwickelt, was die Eigenschaften der Benutzungsschnittstelle demonstriert. Es konnen einzelne Teile derFunktionalitat bereits prototypisch implementiert sein. Meist genugen aber auch vorbereitete Daten fur bestimmteSzenarien, die nicht wirklich berechnet, sondern nur in Reaktion auf die Eingabe des Benutzers angezeigt werden.Die Daten mussen auch nicht korrekt sein, solange es nur um die Demonstration der Interaktion geht. DieFunktionalitat kann unter Umstanden auch durch den Analytiker

”von Hand“ simuliert werden.

Interaktive Storyboards ermoglichen echte Interaktion des Nutzers mit dem System mit einer großtmoglichen Nahezum realen System. Dabei muss der Analytiker nicht bei der Demonstration anwesend sein. Allerdings kann derBenutzer auch hier nicht selbst eingreifen, um eigene Vorstellungen einzubringen, und wir haben einen hoherenAufwand bei der Prototyp-Erstellung. GUI-Design-Werkzeuge konnen jedoch einen Teil des Aufwands reduzieren.

Interaktive Storyboards werden in der Regel in spateren Phasen des Interaktions-Designs entwickelt, bei denen manschon genaue Vorstellungen entwickelt hat. Sie konnen fur Nutzertests zur Gebrauchsttauglichkeit des Systemseingesetzt werden, indem man verschiedene Nutzer (pro Persona mindestens einen) mit dem System interagierenlasst und diese Interaktion beobachtet und auswertet.

Anforderungsanalyse

Vor- und Nachteile des Einsatzes von Prototypen

+ erlauben fruhzeitige Demonstration von Losungsansatzen

+ erlauben fruhzeitige Beteiligung der Benutzer

+ vermeiden das”Leere-Blatt-Syndrom“

+ reduzieren Entwicklungsrisiken durch fruhzeitige Diskussion mitBeteiligten

+ geeignete Werkzeuge ermoglichen die schnelle Erstellung vonPrototypen

– erfordern erhohten Entwicklungsaufwand durch (zusatzliche)Prototyp-Entwicklung

– Gefahr, dass Wegwerf-Prototyp Teil des Produkts wird (z.B. ausZeitdruck)









– Gefahr, dass Wegwerf-Prototyp Teil des Produkts wird (z.B. ausZeitdruck)2

00

9-0

2-0

9

Software-Projekt

Anforderungsanalyse



Zum Ende des Abschnitts uber Prototypen fassen wir die Vor- und Nachteile von Prototypen zusammen.Vorteile:

+ Prototypen erlauben eine fruhzeitige Demonstration von Losungsansatzen mit vertretbaren Kosten. Gerade weil derInteraktion eine hohe Bedeutung zukommt und sie auch in der Anforderungsspezifikation genau beschrieben sein sollte,sollten wir in der Anforderungsanalyse prazise Konzepte entwickeln und sie dem Kunden und Benutzer vorfuhren, um dieKonzepte zu evaluieren und zu verbessern. Andererseits konnen wir zu einem so fruhen Zeitpunkt nicht die ganzeApplikation bereits entwickeln. Darum also Prototypen.

+ Prototypen erlauben damit eine fruhzeitige Beteiligung der Benutzer. Der Benutzer selbst kann sich ein genaueres Bilddes spateren Systems machen und fruhzeitig korrigierend eingreifen.

+ Prototypen vermeiden das”Leere-Blatt-Syndrom“, das wir von Schriftstellern kennen, die die erste Seite ihres neuen

Romans schreiben sollen. Mit Prototypen konnen wir direkt loslegen. Insbesondere Papierprototypen helfen uns einenschnellen Einstieg zu finden, weil sie billig herzustellen und leicht anderbar sind.

+ Prototypen reduzieren Entwicklungsrisiken durch fruhzeitige Diskussion mit Beteiligten. Wir wissen, wie teuer uns spateAnderungen kommen. Darum stellen wir durch fruhes Vorzeigen und Einbeziehen der Benutzer sicher, dass wir auf demrichtigen Weg sind. Dafur ist eine Anfangsinvestition notwendig, um den Prototypen zu entwickeln, die sich aber imVerlaufe des Projekts mit sehr hoher Wahrscheinlichkeit amortisiert, weil weniger Fehler in der Anforderungsanalysegemacht werden.

+ Geeignete Werkzeuge ermoglichen die schnelle Erstellung von Prototypen, so dass sich die Kosten in Grenzen halten.Beispielsweise gibt es GUI-Builder, mit denen man sich rasch graphische Benutzeroberflachen zusammen klicken kann.Oder man benutzt Werkzeuge wie Graphikprogramme (auch scripting-fahige, wie Adobe Flash) undPrasentationssoftware.








– Gefahr, dass Wegwerf-Prototyp Teil des Produkts wird (z.B. ausZeitdruck)2

00

9-0

2-0

9

Software-Projekt

Anforderungsanalyse



Nachteile:

– Auch wenn Prototypen billiger sind als das Endprodukt, so erfordern Prototypen einen erhohten Entwicklungsaufwanddurch die zusatzlich Prototyp-Entwicklung. Je nach Ausbau des Prototypen konnen die Kosten erheblich sein.

– Bei der Entwicklung von Wegwerfprototypen wird kein großer Wert auf Qualitat gelegt; sie mussen zeigen, was siezeigen sollen, und ansonsten moglichst billig sein. Der großte Nachteil dieser Prototypen ist somit die Gefahr, dass siezum Teil des Produkts werden (z.B. aus Zeitdruck). Bei interaktiven Storyboards erhalten Kunde und Projektmanagerden Eindruck, dass das System schon beinahe fertig ist. Die Versuchung ist groß, den Wegwerfprototypen auszubauen,statt ihn wie geplant wegzuwerfen. Das racht sich jedoch in der Regel, weil die Qualitat des Wegwerfprototypen einsolches Vorgehen nicht unterstutzt. Dieser Gefahr kann man durch Papierprototypen oder durch eine Entwicklung miteiner Programmiersprachen, die man spater fur das Endprodukt nicht benutzen mochte, vorbeugen.

Anforderungsanalyse

Wegweiser

Analysetechniken

Wann wird welche Analysetechnik eingesetzt?


Anforderungsanalyse

Analysetechniken

Ist-Zustand Soll-Zustand FolgenAuswertung vorhandener + - -Daten/DokumenteBeobachtungen + ◦ -Befragung- geschlossene Fragen + ◦ -- offene Fragen + ◦ -- hybride Fragen + ◦ -Prototyping - + +partizipative Entwicklung - + +


Analysetechniken


20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Zusammenfassung der Techniken

Analysetechniken

Zum Abschluss der Ist- und Sollanalyse fassen wir noch einmal die Techniken, die wir kennen gelernt haben,zusammen und bewerten ihre Eignung fur das Erfassen des Ist-Zustands, der Planung des Soll-Zustands und derAbschatzung mittel- und langfristiger Folgen unserer anvisierten Softwarelosung. Die folgende Tabelle gibt einenUberblick:


Die Auswertung vorhandener Dokumente ist ein Instrument rein fur die Erhebung des Ist-Zustands, weil sie aufExistierendem basiert. Befragung und Beobachtung setzen auch etwas Existierendes voraus. Man kann sie aberauch einsetzen, um Prototypen zu evaluieren. Prototypen sind eine Vision des Soll-Zustandes, die handfest unduberprufbar ist. Mit ihnen kann man durch geeignete Evaluierung auch die Folgen des Einsatzes des spaterensSystems abschatzen. Man kann also zum Beispiel demonstrieren, dass fruhere Redundanzen und manuelle Eingriffenicht mehr existieren werden, was die Fehleranfalligkeit reduziert. Außerdem kann man nachweisen, dass einBenutzer schneller seine Aufgabe erledigen kann, als das vorher der Fall war.

Analysetechniken


20

09

-02

-09

Software-Projekt

Anforderungsanalyse

Zusammenfassung der Techniken

Analysetechniken

Die partizipative Entwicklung ist die Softwareentwicklung, die die spateren Benutzer einbezieht – wohl gemerkt, dieBenutzer, nicht nur den Kunden. Es gibt hierfur verschiedene Auspragungen. Die Benutzer konnen zu Anfang in derPhase des Interaktions-Designs bei der Entwicklung von Prototypen einbezogen werden und gegen Ende beimAkzeptanztest. Bei inkrementellen Entwicklungsprozessen, bei denen ein System in kleineren funktionstuchtigenInkrementen entwickelt werden, werden sie noch starker einbezogen. Dort evaluieren sie jedes einzelne Inkrement –also Zwischenprodukt – und nicht nur das Endprodukt. Da die Anforderungsanalyse bei der Entwicklungsphase desnachsten Inkrements wieder durchlaufen wird, kann der Benutzer an vielen Punkten der Entwicklung Einflussnehmen. Diese Idee wird beim Extreme Programming, einem agilen Entwicklungsprozess, zum Extrem getrieben,indem ein Benutzer vor Ort der Entwicklung ist und wochentlich das System testet und Verbesserungsvorschlageunterbreitet. Die Gebrauchstauglichkeit kann auf diese Weise besser sicher gestellt werden. Außerdem habenBenutzer die Moglichkeit, das System, das sie spater einsetzen sollen, mitzugestalten, was zu einer hoherenAkzeptanz fuhren sollte.

Anforderungsanalyse

Wegweiser


Wie halten wir die Anforderungen fest?


Anforderungsanalyse

Anforderungsspezifikation nach IEEE Std 610.12-1990

Definition

requirement: condition or capability needed by a user to solve a problemor achieve an objective.

specification: document that specifies, in a complete, precise, verifiablemanner, the requirements (, ...) of a system or component, and, often, theprocedures for determining whether these provisions have been satisfied.

software requirements specification (SRS): documentation of theessential requirements (functions, performance, design constraints, andattributes) of the software and its external interfaces.



Definition



software requirements specification (SRS): documentation of theessential requirements (functions, performance, design constraints, andattributes) of the software and its external interfaces.2

00

9-0

2-0

9

Software-Projekt

Anforderungsanalyse



An die Ist- und Sollanalyse schließt sich die Formulierung der Anforderungen an. Die Sollanalyse ergibt, was dieSoftware leisten muss, um die Schwachstellen, die durch die Ist-Analyse offenbar wurden, zu beseitigen. DieSollanalyse hat jedoch nur die prinzipiellen Konzepte erarbeitet. Diese mussen wir nun prazise ausarbeiten und ambesten schriftlich festhalten. In diesem Abschnitt setzen wir uns deshalb mit der Frage auseinander, wie dieAnforderungen formuliert sein sollen. Bevor wir jedoch dazu kommen, mussen wir uber ein paar grundlegendeBegriffe einig werden. Was ist denn eine Anforderungsspezifikation genau?

Im Englischen wird die Anforderungsspezifikation Requirement Specification genannt, was sich aus Requirement furAnforderung und Specification zusammen setzt. Das Software-Engineering-Glossar IEEE Std 610.12-1990 definiertRequirement 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 Fahigkeit, die von einem Benutzer benotigt wird, um einProblem zu losen 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 systemor component, and, often, the procedures for determining whether these provisions have been satisfied.

Eine Spezifikation ist ein Dokument, das vollstandig, prazise und uberprufbar die Anforderungen an ein Systemoder eine Komponente spezifiziert und oft auch die Prufprozeduren nennt, um festzustellen, ob diese Forderungentatsachlich erfullt sind.

Diese Definition erlautert nicht nur den Begriff Spezifikation, sondern stellt auch eine Reihe von Forderungen furSpezifikation auf. Sie sollen vollstandig, prazise und uberprufbar sein. Vollstandig bedeutet, dass die Spezifikationalle relevanten Anforderungen nennt. Prazise heißt, dass keine Anforderung missverstanden werden kann.Uberprufbar bedeutet, dass man fur jede Anforderung eine Prufprozedur angeben kann, anhand derer man objektivnachweisen kann, dass eine Anforderung erfullt ist. Wir werden uns mit diesen Eigenschaften und mit weiterenQualitaten, die eine gute Anforderungsspezifikation auszeichnen, in diesem Abschnitt noch auseinander setzen.


Definition



software requirements specification (SRS): documentation of theessential requirements (functions, performance, design constraints, andattributes) of the software and its external interfaces.2

00

9-0

2-0

9

Software-Projekt

Anforderungsanalyse



Der zusammengesetzte Begriff Software Requirements Specification ist wie folgt definiert:

Software Requirements Specification : documentation of the essential requirements (functions, performance, design constraints,and attributes) of the software and its external interfaces.

Diese Definition erganzt die einzelnen Definitionen von Anforderung und Spezifikation um den Inhalt, der in einerAnforderungsspezifikation aufgefuhrt ist. Die Anforderungsspezifikation ist demnach eine Dokumentation derwesentlichen Anforderungen (Funktionen, Performanz, Entwurfseinschrankungen, und Attribute) einer Softwaresowie ihrer externen Schnittstellen. Diese Inhalte entstammen einer anderen IEEE-Norm, die beschreibt, wieAnforderungsspezifikation aufgebaut sind und welche Inhalte sie haben. Mit dieser Norm werden wir uns hier nochauseinander setzen.

Anforderungsanalyse

Anforderungen

Anforderungen sind gleichbedeutend mit Minimalbedingungen hinsichtlichFunktion und Qualitat.⇒ Wir mussen also die Funktion und Qualitat definieren.

Definition

Funktion: in der Zeit ablaufende Transformation

von Eingabedaten

in Ausgabedaten

unter Verwendung von Ressourcen


Anforderungen

Anforderungen sind gleichbedeutend mit Minimalbedingungen hinsichtlichFunktion und Qualitat.⇒ Wir mussen also die Funktion und Qualitat definieren.

Definition

Funktion: in der Zeit ablaufende Transformation

von Eingabedaten

in Ausgabedaten

unter Verwendung von Ressourcen

20

09

-02

-09

Software-Projekt

Anforderungsanalyse


Anforderungen

Anforderungen legen die Minimalbedingungen hinsichtlich Funktion und Qualitat fest. Was aber sind Funktionenund wie definiert man Qualitat fur Software?

Wahrend sich Funktionen uber den Zusammenhang von Eingaben des Benutzers und darauf hin erwarteteAusgaben unter Verwendung einer maximalen Menge von Ressourcen definieren lassen, ist der BegriffSoftwarequalitat weniger offensichtlich.

Anforderungsanalyse

Produktqualitaten nach ISO/IEC-Standard 9126 (2001)

Wiederher-stellbarkeit

Fehler-toleranz

Verbrauchs-verhalten

Software-qualitat

Sicherheit

Interoperabilitat

Richtigkeit

Angemessenheit

Funktionalitat

OrdnungsmaßigkeitReife

Anderbarkeit

Stabilitat

Prufbarkeit

Analysierbarkeit

Modifizierbarkeit

Austauschbarkeit

Installierbarkeit

Anpassbarkeit

Konformitat Zeitverhalten

Verstandlichkeit

Erlernbarkeit

Bedienbarkeit

Ubertragbarkeit

Zuverlassigkeit

EffizienzBenutzbarkeit




Fehler-toleranz


Software-qualitat

Sicherheit

Interoperabilitat

Richtigkeit

Angemessenheit

Funktionalitat


Anderbarkeit

Stabilitat

Prufbarkeit

Analysierbarkeit

Modifizierbarkeit

Austauschbarkeit

Installierbarkeit

Anpassbarkeit


Verstandlichkeit

Erlernbarkeit

Bedienbarkeit

Ubertragbarkeit

Zuverlassigkeit


20

09

-02

-09

Software-Projekt

Anforderungsanalyse



Der Begriff Softwarequalitat ist sehr vielschichtig. Im Allgemeinen bedeutet Qualitat lediglich, zu welchem Grad einGegenstand bestimmte Attribute aufweist. Wahrend die Qualitat einer Schraube recht einfach durch die AttributeFestigkeit, Gewicht, Material, Preis etc. festgelegt werden kann, sind die wesentlichen Attribute bei Software nichtohne Weiteres offensichtlich.

Im internationalen Standard ISO/IEC-Standard 9126 (2001) werden typische Softwarequalitaten in Formallgemeiner Kategorien und Subkategorien wie folgt aufgefuhrt:

Funktionalitat: Vorhandensein von Funktionen mit festgelegten Eigenschaften, die die definierten Anforderungenerfullen:

• Richtigkeit: Liefern der richtigen oder vereinbarten Ergebnisse oder Wirkungen, z.B. die benotigte Genauigkeit vonberechneten Werten

• Angemessenheit: Eignung der Funktionen fur spezifizierte Aufgaben, z.B. aufgabenorientierte Zusammensetzung vonFunktionen aus Teilfunktionen

• Interoperabilitat: Fahigkeit, mit vorgegebenen Systemen zusammen zu wirken

• Ordnungsmaßigkeit: Erfullung von anwendungsspezifischen Normen, Vereinbarungen, gesetzlichen Bestimmungen undahnlichen Vorschriften

• Sicherheit: Fahigkeit, unberechtigten Zugriff, sowohl versehentlich als auch vorsatzlich, auf Programme und Daten zuverhindern

Zuverlassigkeit: Fahigkeit der Software, ihr Leistungsniveau unter festgelegten Bedingungen uber einen festgelegtenZeitraum zu bewahren:

• Reife: Geringe Versagenshaufigkeit durch Fehlerzustande

• Fehlertoleranz: Fahigkeit, ein spezifiziertes Leistungsniveau bei Softwarefehlern oder Nicht-Einhaltung ihrer spezifiziertenSchnittstelle zu bewahren

• Wiederherstellbarkeit: Fahigkeit, bei einem Versagen das Leistungsniveau wiederherzustellen und die direkt betroffenenDaten wiederzugewinnen



Fehler-toleranz


Software-qualitat

Sicherheit

Interoperabilitat

Richtigkeit

Angemessenheit

Funktionalitat


Anderbarkeit

Stabilitat

Prufbarkeit

Analysierbarkeit

Modifizierbarkeit

Austauschbarkeit

Installierbarkeit

Anpassbarkeit


Verstandlichkeit

Erlernbarkeit

Bedienbarkeit

Ubertragbarkeit

Zuverlassigkeit


20

09

-02

-09

Software-Projekt

Anforderungsanalyse



Benutzbarkeit: Aufwand, der zur Benutzung erforderlich ist, und individuelle Beurteilung der Benutzung durch einefestgelegte oder vorausgesetzte Benutzergruppe:

• Verstandlichkeit: Aufwand fur den Benutzer, das Konzept und die Anwendung zu verstehen

• Erlernbarkeit: Aufwand fur den Benutzer, die Anwendung zu erlernen (z.B. Bedienung, Ein-, Ausgabe)

• Bedienbarkeit: Aufwand fur den Benutzer, die Anwendung zu bedienen

Effizienz: Verhaltnis zwischen dem Leistungsniveau der Software und dem Umfang der eingesetzten Betriebsmittelunter festgelegten Bedingungen:

• Zeitverhalten: Antwort- und Verarbeitungszeiten sowie Durchsatz bei der Funktionsausfuhrung

• Verbrauchsverhalten: Anzahl und Dauer der benotigten Betriebsmittel fur die Erfullung der Funktionen

Anderbarkeit: Aufwand, der zur Durchfuhrung vorgegebener Anderungen notwendig ist; Anderungen: Korrekturen,Verbesserungen oder Anpassungen an Anderungen der Umgebung, der Anforderungen und der funktionalenSpezifikationen:

• Analysierbarkeit: Aufwand, um Mangel oder Ursachen von Versagen zu diagnostizieren oder um anderungsbedurftigeTeile zu bestimmen

• Modifizierbarkeit: Aufwand zur Ausfuhrung von Verbesserungen, zur Fehlerbeseitigung oder Anpassung anUmgebungsanderungen

• Stabilitat: Wahrscheinlichkeit des Auftretens unerwarteter Wirkungen von Anderungen

• Prufbarkeit: Aufwand, der zur Prufung der geanderten Software notwendig ist

Ubertragbarkeit: Eignung der Software, von einer Umgebung in eine andere ubertragen zu werden (Umgebungkann 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

• Konformitat: Grad, in dem die Software Normen oder Vereinbarungen zur Ubertragbarkeit erfullt

• Austauschbarkeit: Moglichkeit, diese Software anstelle einer spezifizierten anderen in der Umgebung jener Software zuverwenden, sowie der dafur notwendige Aufwand



Fehler-toleranz


Software-qualitat

Sicherheit

Interoperabilitat

Richtigkeit

Angemessenheit

Funktionalitat


Anderbarkeit

Stabilitat

Prufbarkeit

Analysierbarkeit

Modifizierbarkeit

Austauschbarkeit

Installierbarkeit

Anpassbarkeit


Verstandlichkeit

Erlernbarkeit

Bedienbarkeit

Ubertragbarkeit

Zuverlassigkeit


20

09

-02

-09

Software-Projekt

Anforderungsanalyse



Diese Kategorien sind immer noch sehr allgemein und mussen fur die Anforderungen an eine bestimmte Softwarekonkretisiert und gewichtet werden. Dabei ist zu beachten, dass sich Qualitatsattribute gegenseitig (auch negativ)beeinflussen konnen. So stehen hohe Performanz und hohe Wartbarkeit meist in einem Spannungsfeld zueinander.

Die Konkretisierung und Gewichtung der Qualitatsattribute liefert das Qualitatsmodell. Fur das Qualitatsmodellmussen dann Prufkriterien festgelegt werden, anhand derer das Vorhandensein der gewunschten Eigenschaftenuberpruft werden kann. Im ISO/IEC-Standard 25000 (2005), der die Nachfolge von ISO/IEC-Standard 9126 (2001)angetreten hat, werden hierfur Metriken angegeben. Metriken sind ein numerisches Maß, das beschreibt, inwieweiteine bestimmte Qualitat vorliegt. Durch Einsatz der Metriken wird die Qualitat messbar. Uber die wesentlichenQualitatsattribute und sinnvolle Metriken zu ihrer Messung herrscht jedoch nicht immer Konsens.

Auch die Kategorisierung der Qualitatsattribute ist nicht immer gleich. Ludewig (2003) beispielsweise unterscheidet

auf oberster Ebene nach inneren und außeren Qualitaten. Außere Qualitaten sind solche, die fur den Benutzerdirekt spurbar sind. Innere Qualitaten richten sich primar an den Entwickler, sind jedoch zumindest indirekt auchfur den Benutzer spurbar durch den Aufwand und die Dauer fur Anderungen an der Software, um sie an neue undgeanderte Anforderungen anzupassen. Die folgende Grafik zeigt die Aufteilung nach Ludewig (2003):

PrüfbarkeitÄnderbarkeitPortabilität

NützlichkeitRobustheitBedienbarkeitSicherheit

Zuverlässigkeit

...

...

...

...

...

...

...

...

...

...

...

...............

...

...

...

...

...............

...

... ............

...

...

Produktqualität

innereErstellbarkeitWiederverwendbarkeit

Integrierbarkeit

Wartbarkeit

äußere

Anforderungsanalyse

Bedeutung einer Anforderungsspezifikation

Zweck Folge von Mangeln

Abstimmung mitKunden

Die Anforderungen bleiben ungeklart, Wunsche desKunden bleiben unberucksichtigt.

Entwurf Entwerfer fehlt Vorgabe, darum mehr Kommunikati-on / eigene Vorstellung als Vorgabe.

Benutzerhandbuch Basis fur das Handbuch fehlt, es wird darum phano-menologisch verfasst.

Testvorbereitung systematischer Test ist unmoglich

Abnahme Korrektheit ist subjektiv, Streit ist unvermeidbar.

Wiederverwendung nicht spezifizierte Systeme sind kaum durchschaubar,darum schwer wiederzuverwenden.

spatere Reimple-mentierung

Kompatibilitat setzt voraus, dass man weiß, womitdie neue Software kompatibel sein soll.













20

09

-02

-09

Software-Projekt

Anforderungsanalyse



Die Anforderungsspezifikation ist von zentraler Bedeutung fur die Entwicklung. Sie wird von vielen Personen, dieam Entwicklungsprozess beteiligt sind, als Grundlage ihrer Arbeit verwendet. Eine minderwertigeAnforderungsspezifikation fuhrt zwangslaufig zu Mangeln aller davon abhangiger weiterer Arbeitsprodukte. Da alleweiteren Arbeitspakete von der Anforderungsspezifikation abhangig sind, haben solche Mangel also eine nachhaltigeAuswirkung auf die Qualitat. Deshalb sollte man sich die Muhe machen, die Anforderungen genau zu beschreibenund sie am auch aufzuschreiben.

Man kann die Auswirkungen einer mangelhaften Anforderungsspezifikation unterscheiden anhand der Zwecke, dieman mit der Anforderungsspezifikation verfolgt:

• Abstimmung: Die Anforderungsspezifikation dient der Abstimmung mit dem Kunden. Mangel in derAnforderungsspezifikation fuhren dazu, dass Anforderungen ungeklart und Wunsche des Kunden unberucksichtigtbleiben. Ohne eine ausgearbeitete Anforderungsspezifikation kann der Kunde nicht ohne Weiteres in fruhen Phasen desProjekts uberprufen, ob er richtig verstanden wurde und seine Wunsche wirklich umgesetzt werden.

• Entwurf: Der Softwarearchitekt entwirft auf Basis der Anforderungsspezifikation die Softwarearchitektur. Bei einerunzureichenden Anforderungsspezifikation fehlt dem Architekten dafur die notwendige Vorgabe. Dies fuhrt zu einemerhohten 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 desKunden abweichen konnte.

• Benutzerhandbuch: Anhand der Anforderungsspezifikation wird das Benutzerhandbuch geschrieben. OhneAnforderungsspezifikation fehlt die Basis fur das Handbuch. Dies fuhrt dazu, dass es phanomenologisch erfasst wird; d.h.der Autor des Benutzerhandbuchs schreibt auf, was er beim lauffahigen System beobachtet. Das ist oft unzureichend,weil er nicht alle Moglichkeiten kennt und damit beobachten kann.

• Testvorbereitung: Ohne prazise und vollstandige Anforderungen ist ein systematischer Test unmoglich.

• Vertrag und Abnahme: In der Regel bildet die Anforderungsspezifikation die vertragliche Grundlage fur den Auftrag. AmEnde des Projekts wird bei der Abnahme uberpruft, ob die Anforderungen erfullt sind. Damit wird die Uberprufung derKorrektheit subjektiv und Streit ist unvermeidbar. Das fuhrt zur Unzufriedenheit des Kunden und haufig zuVertragsstreitigkeiten. Da aber die Anforderungen nicht vollstandig und prazise beschrieben sind, ist ein Streit um dasRecht muhsam.












20

09

-02

-09

Software-Projekt

Anforderungsanalyse



• Wiederverwendung: Ohne eine Beschreibung, was die Software leistet, kann man nicht ohne Weiteres beurteilen, obman die Software wiederverwenden kann. Nicht spezifizierte Systeme sind kaum durchschaubar, darum schwerwiederzuverwenden.

• Spatere Reimplementierung: Soll das System spater gegen ein neues System ersetzt werden, muss man wissen, was estut. Kompatibilitat setzt voraus, dass man weiß, womit die neue Software kompatibel sein soll.

Anforderungsanalyse

Angestrebte Eigenschaften der Spezifikation

inhaltlich

(1) zutreffend (nicht”korrekt“!)

(2) vollstandig (relativ zu den Wunschen des Kunden)(3) widerspruchsfrei (oder konsistent, damit auch realisierbar)(4) neutral d.h. abstrakt (und damit offen fur beliebigen Entwurf)

in der Darstellung

(5) leicht verstandlich (fur alle Zielgruppen!)(6) prazise (schließt Umgangssprache aus)

in der Form

(7) leicht erstellbar (was die Notationen und Modelle betrifft)(8) leicht verwaltbar (also auch zweckmaßig strukturiert)(9) objektivierbar (auch – nicht sinnvoll –

”testbar“ genannt)

Diese Merkmale konkurrieren, d.h. die Erfullung des einen erschwert oderverhindert die Erfullung des anderen.



inhaltlich



in der Darstellung


in der Form




20

09

-02

-09

Software-Projekt

Anforderungsanalyse



Weil eine Anforderungsspezifikation von so tragender Bedeutung ist, streben wir eine hochqualitative an. WelcheEigenschaften mussen wir aber hierzu anstreben? Die anzustrebenden Eigenschaften lassen sich wie folgtkategorisieren:

Den Inhalt betreffend:

(1) zutreffend: die Anforderungen des Kunden werden richtig wieder gegeben; an manchen Stellen wird fur zutreffend auchder Begriff korrekt synonym verwendet; wir werden aber im Folgenden den Begriff korrekt fur das Verhaltnis derImplementierung zur Anforderungsspezifikation reservieren; eine Implementierung ist dann korrekt, wenn sie diespezifizierten Anforderungen richtig erfullt. Daraus kann man jedoch noch nicht unmittelbar schließen, dass dieImplementierung auch das implementiert, was der Kunde tatsachlich will. Hierzu ist es noch notwendig, dass dieAnforderungsspezifikation auch die Wunsche des Kunden zutreffend wiedergibt.

(2) vollstandig: alle Wunsche des Kunden werden berucksichtigt.

(3) widerspruchsfrei (oder konsistent, damit auch realisierbar): die Anforderungen widersprechen sich nicht; wurden sie sichwidersprechen, konnte man nichts implementieren, was alle Anforderungen erfullt.

(4) neutral, d.h. abstrakt: die Anforderungen sind aus Sicht des Kunden formuliert und nehmen keine unnotigen technischenDetails vorweg. Implementierungsaspekte gehoren nicht in die Anforderungsspezifikation, weil sie den Kunden in derRegel nicht interessieren, sondern eher verwirren. Außerdem bleibt damit dem Architekten beim Entwurf eingroßtmoglicher Gestaltungsspielraum.


inhaltlich



in der Darstellung


in der Form




20

09

-02

-09

Software-Projekt

Anforderungsanalyse



Die Darstellung betreffend:

(5) leicht verstandlich: Die Anforderungsspezifikation ist leicht verstandlich fur alle Zielgruppen. Dazu gehoren nebenEntwicklern mit technischem Verstandnis auch Kunden und Benutzer, die meist mit formalen Methoden und Notationnichts anzufangen wissen. Selbst die Verwendung der Unified Modeling Language ist fur einen Kunden und Benutzernicht ohne Weiteres zumutbar, auch wenn manche sie als Notation fur die Kommunikation mit Kunden und Benutzernanpreisen. Die Vorteile einer (semi-)formalen Notation ist ihre Prazision und Pragnanz. Aus diesem Grund wurde mansich ihren Einsatz wunschen. Wird eine solche Notation verwendet, muss der Kunde aber darin geschult werden – oderwurden wir einen Vertrag in Hieroglyphen unterzeichnen?

(6) prazise: die Anforderungen mussen unmissverstandlich formuliert sein, sonst besteht die Gefahr, dass etwas Falschesimplementiert wird. Dies schließt Umgangssprache, die sich durch vage Begriffe und Mehrdeutigkeiten auszeichnet, aus.Ebenso sollten sprachliche Weichmacher wie konnte, musste, circa, ungefahr etc. vermieden werden.


inhaltlich



in der Darstellung


in der Form




20

09

-02

-09

Software-Projekt

Anforderungsanalyse



Die Form betreffend:

(7) leicht erstellbar: die Anforderungsspezifikation ist in vielen Fallen ein sehr umfangreiches Dokument. Darum ist eswichtig, das es leicht erstellt werden kann. Somit ist die Auswahl geeigneter Notationen und Modelle bedeutsam. Haufigwird sie nicht nur von einem Autoren erstellt, so dass die Zusammenarbeit mehrerer Autoren unterstutzt werden muss.Die Anforderungsspezifikation muss also modular aufgebaut sein.

(8) leicht verwaltbar: die Anforderungsspezifikation muss durch zweckmaßige Strukturierung, eindeutige Referenzierbarkeitund explizite Querbezuge leicht uberarbeitet und versioniert werden konnen. Idealerweise ist der Code uber den Entwurfhin zu den Anforderungen verknupft, um eine hohe Nachvollziehbarkeit zwischen diesen Dokumenten zu gewahrleisten,da die Dokumente nachgefuhrt werden mussen, wenn sich Dinge andern. Hierfur wurden eine Reihe von Werkzeugen,wie z.B. Doors, entwickelt

(9) objektivierbar: fur jede Anforderung muss es moglich sein, eine Prufprozedur anzugeben, mit deren Hilfe man objektiventscheiden kann, ob das resultierende System die Anforderung erfullt; synonym zu objektivierbar wird haufig auch derBegriff testbar verwendet; dieser Begriff suggeriert jedoch, dass man das System fur die Prufung ausfuhren konnen muss(vgl. das Kursmodul Test); die meisten Prufungen lassen sich aber ohne Ausfuhrung des Systems durchfuhren.Die Anforderung

”Die Programm soll eine hohe Performanz aufweisen“ ist ein Negativbeispiel fur 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 Falle nach spatestens 20 Sekunden

erfolgen; nach hochstens 30 Sekunden soll die Ausgabe in 100 % aller Falle erfolgen. Die Berechnung muss mit maximal5 MB Hauptspeicher und 100 MB Plattenplatz auskommen“.

Leider ist es nicht immer moglich, alle diese Merkmale bei einer Anforderungsspezifikation zu erfullen, weil dieMerkmale konkurrieren konnen, das heißt die Erfullung des einen erschwert oder verhindert die Erfullung desanderen. Prazise Anforderungen sind in der Regel nur mit Hilfe formaler Spezifikationsprachen zu erreichen, die sindaber fur einen Kunden meist nicht verstandlich.

Anforderungsanalyse

Regeln fur Analyse und Spezifikation

Ein Begriffslexikon anlegen und entwickeln

Von der Aufgabe ausgehen, nicht von ihrer Losung

Daten suchen, nicht Programmablaufe beschreiben

Abstraktionsebene nicht in einer Darstellung wechseln

Die Spezifikation nach Aspekten organisieren

Ein Mengengerust bilden

Den Kunden (Benutzer) einbeziehen

Geeignete Sprachen und Werkzeuge verwenden

Die Spezifikation so fruh wie moglich prufen und demKonfigurationsmanagement unterstellen

Die Spezifikation intensiv verwenden












Die Spezifikation intensiv verwenden20

09

-02

-09

Software-Projekt

Anforderungsanalyse



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 Kundeund wir benutzen, die nicht unmittelbar offensichtlich sind. Die schriftliche Niederlegung der Bedeutung aller Begriffezwingt uns und den Kunden zur notwendigen Prazision in unserem Dialog und hilft damit, Missverstandnisse zuvermeiden. Hier sollten auch alle Synonyme aufgezahlt werden. Im eigentlichen Inhalt der schriftlichenAnforderungsspezifikation sollten wir aber Synonyme vermeiden und immer nur dasselbe Wort benutzen. DieAnforderungsspezifikation ist kein literatisches Werk, das durch hohe Sprachvariation gefallen will, sondern soll einprazises, leicht verstandliches technisches Dokument sein. Unterschiedliche Worte fur denselben Sachverhalten verwirrennur.

• Von der Aufgabe ausgehen, nicht von ihrer Losung. Die Anforderungsspezifkation beschreibt das zu implementierendeSystem aus Sicht des Kunden. Wie das System intern implementiert wird, interessiert den Kunden nicht, sondernverwirrt ihn eher, weil er sich mit Implementierungsfragen in der Regel nicht auskennt. Implementierungsfragen gehorenin ein Entwurfsdokument, wie z.B. die Architekturbeschreibung. Wir sollten den Gestaltungsraum desSoftwarearchitekten durch die Anforderungsspezifikation nicht unnotig einschranken.

• Daten suchen, nicht Programmablaufe beschreiben. Primar sind wir an den Daten, d.h. den Objekten, derAnwendungsdomane interessiert. Sie andern sich meist weniger als die Ablaufe, in denen sie verarbeitet werden.Naturlich gehoren zur Beschreibung in der Anforderungsspezifikation die Kommunikation zwischen den Objekten undwelche Operationen sie prinzipiell beherrschen. Die Software muss ja Arbeitsflusse abbilden. Wie aber diese Operationenintern implementiert werden (der Programmablauf) ist ein Detail der Implementierung und sollte erst spater im Entwurfoder in der Implementierungsphase spezifiziert werden.

• Abstraktionsebene nicht in einer Darstellung wechseln. Um den Leser zu fuhren statt ihn zu verwirren, sollten wir unsDetails fur vertiefende Abschnitte aufheben. Die Anforderungsspezifikation sollte so gestaltet sein, dass der Leser ersteinen allgemeinen Uberblick uber alle Anforderungen an das System erhalt und erst dann einen detaillierten Einblick indie einzelnen Anforderungen. Ein Wechsel zwischen diesen Ebenen verwirrt unnotig.












09

-02

-09

Software-Projekt

Anforderungsanalyse



• Die Spezifikation nach Aspekten organisieren. Die Spezifikation ist nicht selten ein Dokument mit mehreren hundertSeiten. Es kann nicht ohne Unterbrechung gelesen werden. Außerdem wird es von Lesern mit sehr unterschiedlichenInteressen gelesen. Dazu gehoren auf Kundenseite neben dem Auftraggeber (auch hier gibt es meist verschiedene Rollen:der Auftraggeber, der fur den Inhalt verantwortlich ist und der Auftraggeber, der fur die Finanzierung und Termintreueverantwortlich ist) die verschiedenen Benutzerklassen. Auf der Seite der Hersteller wird das Dokument von denArchitekten, den Programmierern, den Handbuchautoren und den Testern gelesen. Alle interessieren sich furunterschiedliche Belange. Um die vielen Arten von Lesern zu unterstutzen, muss die Spezifikation uniform nachrelevanten Aspekten organisiert werden.

• Ein Mengengerust bilden. Damit der Architekt eine Vorstellung uber die Anforderungen an die Belastbarkeit des Systemserhalt, um das System dafur entsprechend auszulegen, muss er wissen, mit wie vielen Daten er es zu tun haben wird. Esmacht einen gravierenden Unterschied, ob ein System etwa 10 oder 10.000 Benutzer unterstutzen muss. Damit derArchitekt das System auch fur zukunftige Anforderungen skalierbar entwerfen kann, sollten neben dem heutigenMengengerust auch realistische Prognosen gemacht werden, wie sich das Mengengerust in Zukunft entwickeln wird.

• Den Kunden (Benutzer) einbeziehen. Wir entwickeln fur den Kunden, der uns dafur bezahlt, und fur die Benutzer, dieunser System spater benutzen sollen. Ihre Belange sind Ausgangspunkt unseres Projekts. Sie konnen an verschiedenenStellen im Entwicklungsprozess eingebunden werden, nicht nur wahrend der Anforderungsanalyse und am Ende beimAkzeptanztest. Beim partizipativen Vorgehen beispielsweise werden wir in kurzen Zeitabstanden Prototypen undverschiedene Inkremente des Systems vorfuhren, um ihr Feedback einzuholen. Ganz besonders benotigen wir sie aberwahrend der initialen Anforderungsanalyse. Um sicher zu stellen, dass wir die Anforderungsspezifikation die Wunsche desKunden und der Benutzer treffend widerspiegelt, sollte die Anforderungsspezifikation in einem Review mit Kunden undBenutzern abgenommen werden.












09

-02

-09

Software-Projekt

Anforderungsanalyse



• Geeignete Sprachen und Werkzeuge verwenden. Die Anforderungsspezifikation sollte moglichst prazise, aber eben auchverstandlich sein. Hierzu kann man Diagrammen benutzen. Die UML beispielsweise enthalt eine Reihe vonDiagrammtypen, mit deren Hilfe man bestimmte Aspekte verstandlich und genau beschreiben kann. Fur dasDatenmodell eignen sich zum Beispiel Klassendiagramme. Es versteht sich von selbst, dass wir dem Kunden unsereNotation erklaren mussen. Zur Erstellung des Dokuments bedient man sich am besten spezieller Werkzeuge. Nebenherkommlicher Editierfunktionen konnen uns hierbei Werkzeuge helfen, Anforderungen eindeutig zu nummerieren sowieVerweise einzufugen, zu verfolgen und zu prufen. Diese Werkzeuge konnen uns auch einen festen Rahmen vorgeben.Einfache Prufungen auf Vollstandigkeit werden damit moglich.

• Die Spezifikation so fruh wie moglich prufen und dem Konfigurationsmanagement unterstellen. DieAnforderungsspezifikation sollte wir selbst mit internen Reviews uberprufen. Nach Fertigstellung derAnforderungsspezifikation sollte mindestens eine Prufung mit dem Kunden und den Benutzern stattfinden. Weitere nochfruhere Prufungen kann man mit Hilfe von Prototypen erreichen.Die Anforderungsspezifikation wird sich andern, weil in Prufungen und auch spater Fehler und Lucken gefunden werden.Außerdem konnen sich bei einer langeren Projektlaufzeit Anforderungen auch noch wahrend der Entwicklung andernaufgrund geanderter Rahmenbedingungen. Zudem arbeiten meist mehrere Personen an der Anforderungsspezifikation.Aus diesem Grund muss die Anforderungsspezifikation von Anbeginn unter das Konfigurationsmanagement gestelltwerden.

• Die Spezifikation intensiv verwenden. Die Anforderungsspezifikation ist der Ausgang fur alle weiteren Entwicklungen. Siewird nicht nur benutzt beim Vertragsabschluss von Auftragnehmer und -geber sondern fur eine Reihe weiterer Personen,die fur die Entwicklung verantwortlich sind. Dazu gehoren Architekten, Programmierer, Tester und Handbuchautoren. Essollte eine Selbstverstandlichkeit sein, dass diese Menschen die Spezifikation intensiv nutzen. Leider hat die Praxisgezeigt, dass z.B. viele Programmierer Fehler deshalb machen, weil sie die Anforderungsspezifikation niemals gelesenhaben.












09

-02

-09

Software-Projekt

Anforderungsanalyse



Nachdem wir wissen, welche Qualitaten der Anforderungsspezifikation wir anstreben und welche Regeln wireinhalten sollen, werden wir uns nun mit ihrem Inhalt und ihrer Struktur auseinander setzen. Glucklicherweisehaben sich dazu bereits viele Spezialisten Gedanken gemacht, die sogar in einen Standard gemundet sind. Da wirdas Rad nicht neu erfinden wollen und die Orientierung an Standards eine gute Ingenieurstugend ist, nehmen wiruns diesen Standard zum Vorbild. Wir konnen diesen Standard als einen Rahmen fur unsere Spezifikationverwenden und laufen so weniger Gefahr, etwas zu vergessen.

Es handelt sich dabei um den IEEE Recommended Practice for Software Requirements Specifications, IEEEStandard 830.1998. Er setzt vieles von dem um, was wir bislang kennen gelernt haben. Wir werden hierzuKonkretisierungen und daruber hinaus fuhrende Erganzungen kennen lernen (Ergebnisse der Soll-Analyse,Datenmodell und Prognosen fur zukunftige Anforderungen), die auch beschrieben sein sollten.

Anforderungsanalyse

Inhalt der Anforderungsspezifikation nach IEEE Standard830.1998

1. Einfuhrung

1.1 Zweck1.2 Rahmen1.3 Definitionen, Akronyme und Abkurzungen1.4 Referenzen1.5 Ubersicht uber das Dokument

2. Allgemeine Beschreibung

2.1 Produktperspektive2.2 Produktfunktionen2.3 Charakteristika der Benutzer2.4 Einschrankungen2.5 Annahmen und Abhangigkeiten

3. Detaillierte Beschreibung



1. Einfuhrung





20

09

-02

-09

Software-Projekt

Anforderungsanalyse


Inhalt der Anforderungsspezifikation nach IEEEStandard 830.1998

Der Standard gibt eine dreiteilige Struktur vor: eine Einfuhrung, eine allgemeine Beschreibung und eine detaillierteBeschreibung. Er folgt hierin den oben erwahnten Regeln, nach Aspekten und Detaillierungsgrad zu ordnen. DieStruktur bis in die zweite Gliederungsebene ist wie folgt:

1. Einfuhrung





Wir werden diese Abschnitte nun im Einzelnen im Detail kennen lernen. Ein Beispiel fur eine ausfuhrlicheAnforderungsspezifikation finden Sie unter . . . <<hier erganzen: gute Spec. vom ersten SWP zu PDAhinzufugen>>

Anforderungsanalyse


1. Einfuhrung

1.1 Zweck

Zweck der Spezifikationadressierte Leser

1.2 Rahmen

herzustellende Software mit Namewas die Software tut und nicht tutAnwendung der Software mit Nutzen und Zielen

1.3 Definitionen, Akronyme und Abkurzungen

1.4 Referenzen

1.5 Ubersicht uber das Dokument



1. Einfuhrung

1.1 Zweck

Zweck der Spezifikationadressierte Leser

1.2 Rahmen

herzustellende Software mit Namewas die Software tut und nicht tutAnwendung der Software mit Nutzen und Zielen

1.3 Definitionen, Akronyme und Abkurzungen

1.4 Referenzen

1.5 Ubersicht uber das Dokument20

09

-02

-09

Software-Projekt

Anforderungsanalyse



Das Ziel der Einfuhrung ist es, den Kontext und Rahmen der Anforderungsspezifikation abzustecken. Sie hatfolgende Struktur:

1.1 ZweckDieser Abschnitt beschreibt den Zweck der Spezifikation und an welche Leser sie sich wendet. Meist geschieht diesdurch eine kurze Beschreibung des Projektkontextes und der Ziele des Projekts. Dann folgt der Hinweis, dass in diesemDokument die Anforderungen dieses System spezifiziert werden sollen und oft die Aussage, dass dieses Dokument dievertragliche Grundlage bildet. Fur die adressierten Leser werden mindestens die konkreten Namen der Kunden undVertreter moglicher Benutzer genannt.

1.2 RahmenHier geben wir der zu erstellenden Software einen Namen und beschreiben ganz kurz, was die herzustellende Softwareleisten soll und auch, was wir explizit nicht von ihr erwarten, um gleich zu Anfang falschen Vorstellungen Einhalt zugebieten. Es folgt die Beschreibung der Anwendung der Software mit ihrem Nutzen und ihren Zielen. Dieser Abschnittsoll nur einen ersten Uberblick 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. �

1.3 Definitionen, Akronyme und AbkurzungenHier ist er der Ort, an dem Begriffe definiert und Akronyme und Abkurzungen eingefuhrt werden konnen, die imweiteren Dokument benutzt werden. Damit wird der Standard unserer oben geaußerten Forderung gerecht, einBegriffslexikon (Glossar) zum Ausschluss von Missverstandnissen zu verwenden.Bsp.: Wir wurden hier beispielsweise das Akronym PDA fur

”Personal Digital Assistant“ erlautern. �

1.4 ReferenzenHier konnen weitere Dokumente aufgefuhrt werden, die fur das Verstandnis der Anforderungsspezifikation hilfreich sindund im folgenden Text referenziert werden. Dazu sollte auch z.B. der IEEE-Standard fur diese Anforderungsspezifikationgehoren.Bsp.: Hier konnten wir die Fahrradherstellerkataloge und weitere Dokumente, die wir in der Ist-Analyse gefunden haben,nennen. �

1.5 Ubersicht uber das DokumentSchließlich erfolgt hier in diesem Abschnitt eine kurze Ubersicht fur den Leser uber die weiteren Kapitel und Abschnittedieser Anforderungsspezfikation.

Anforderungsanalyse



2.1 ProduktperspektiveEinbettung in ein Gesamtsystem

2.1.1 Systemschnittstellen2.1.2 Benutzungsschnittstelle (logische Charakteristika. z.B. Monitorformat,

Seiten- oder Fensterlayout, Inhalt von Berichten oder Menus,Verfugbarkeit von Funktionstasten) sowie Regeln fur die Schnittstelle

2.1.3 Hardwareschnittstellen2.1.4 Softwareschnittstellen2.1.5 Kommunikationsschnittstellen (Netzwerkprotokolle etc.)2.1.6 Speicherbeschrankungen2.1.7 Betriebsoperationen (Operationsmodi, Dauer interaktiver und

nichtinteraktiver Operationen, unterstutzendeDatenverarbeitungsfunktionen, Sicherungs- undWiederherstellungsoperationen)

2.1.8 Moglichkeiten der lokalen Anpassung










20

09

-02

-09

Software-Projekt

Anforderungsanalyse



Das Kapitel 2 beschreibt Allgemeines sowie die Anforderungen im Einzelnen, ohne jedoch gleich alle moglichenDetails zu nennen (letztere folgen im dritten Kapitel).

2.1 Produktperspektive

Dieser Abschnitt bettet das zu implementierende System in ein Gesamtsystem ein. Dazu werden alle seineSchnittstellen zu anderen Systemen und zum Benutzer beschrieben sowie weitere globale Einschrankungen.

Wir werden bei der Beschreibung der Schnittstellen feststellen, dass es nicht immer einfach ist, eine Schnittstelleeiner der unten aufgefuhrten Kategorien eindeutig zuzuordnen. Im Zweifel entscheiden wir uns fur eine und fugen inden anderen Abschnitten einen Querbezug zu dieser Beschreibung ein. Primar ist wichtig, dass die Schnittstellebeschrieben ist. Durch die Querbezuge stellen wir sicher, dass wir diese Beschreibung finden werden, egal inwelchem Abschnitt wir intuitiv suchen.

2.1.1 SystemschnittstellenUber Systemschnittstellen ist das zu implementierende System mit anderen Systemen verbunden, mit denen eszusammen arbeiten soll. Dazu gehoren z.B. Import- und Exportschnittstellen fur den Datenaustausch,Scripting-Schnittstellen, uber die sich das System programmieren lasst, sowie Application Interfaces (API), uber dasman das System programmatisch steuern kann.Bsp.: Hier konnten wir fur PDAss fordern, dass man die Herstellerkataloge in einem zu definierenden elektronischenXML-basierten Format einlesen konnen soll. �









20

09

-02

-09

Software-Projekt

Anforderungsanalyse



2.1.2 BenutzungsschnittstelleEine besondere Schnittstelle ist die, die dem Benutzer angeboten wird. Die detaillierte Beschreibung dieser Schnittstelleerfolgt in Abschnitt 3.1.1. Hier werden lediglich die logischen Charakteristika der Schnittstelle erlautert, z.B. dasMonitorformat, das Seiten- oder Fensterlayout, den Inhalt von Berichten oder Menus oder die Verfugbarkeit vonFunktionstasten. Außerdem werden alle relevanten Regeln fur das Design der Schnittstelle genannt, wie z.B. dieallgemeinen (in aller Regel ohnehin verbindlichen) Richtlinien der Norm EN ISO 9241-10:1995 (1995) fur dieGebrauchstauglichkeit von Software. Die Angaben mussen aber hinreichend konkretisiert werden. Diese Regeln konnenauch 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 dieAnforderungen objektivierbar sein mussen. Statt

”benutzerfreundlich“ sollte es also besser

”Persona X kann die Funktion

Sortiment einsehen in zwei Minuten ausfuhren (nach einer Schulung von zehn Minuten)“ heißen.

Charakteristika der Benutzer werden in Abschnitt 2.3 angegeben.

Bsp.: Hier wurden wir z.B. die Auflosung des PDA-Monitors fur PDAss, die Farbtiefe, die Eingabemoglichkeiten uberStift und nur wenige Tasten und die minimalen Schriftgroßen etc. angeben. �

2.1.3 HardwareschnittstellenHardwareschnittstellen sind Schnittstellen zu Hardware, die das System voraussetzt beziehungsweise bedient. DieserAbschnitt ist insbesondere fur eingebettete Systeme von großer Bedeutung. Fur alle Arten von Systemen wurde manhier aber die zu unterstutzenden Prozessortypen beschreiben, auf denen die Software spater laufen soll. Hardware, dieeher der Benutzungsschnittstelle zuzuordnen ist, wird in Abschnitt 2.1.2 beschrieben.









20

09

-02

-09

Software-Projekt

Anforderungsanalyse



2.1.4 SoftwareschnittstellenSoftwareschnittstellen sind Schnittstellen zu Software, die Bestandteil des System werden soll. Dazu gehorenBetriebssysteme, hohere Dienste wie z.B. Datenbanken sowie wiederverwendbare Bibliotheken, die eingebunden werdensollen.

Wir erinnern uns, dass Implementierungsdetails eigentlich nicht in die Anforderungsspezifikation gehoren. Insofern durfenwir nur solche Softwareschnittstellen hier aufzahlen, die tatsachlich von Interesse fur den Kunden sind, z.B. dann wenner diese Software bereits einsetzt und in diesem Kontext wieder verwenden mochte bzw. wenn sich aus ihrer Verwendungweitere lizenzrechtliche Aspekte fur den Kunden ergeben wurden.

Bsp.: Der Ladenverkaufer hat eine MySQL-Datenbank der Version 4.1 bereits im Einsatz und besteht darauf, dassunsere Software alle persistenten Daten darin speichern soll. �

2.1.5 KommunikationsschnittstellenSofern das System mit anderen Systemen uber ein Netzwerk kommuniziert, beschreiben wir hierfur dieKommunikationsschnittstelle sowie Netzwerkprotokolle etc. Auch hier gilt wieder, dass nur solche Schnittstelleninteressieren, die zu anderen Systemen fuhren beziehungsweise fur die der Kunde sorgen muss, damit unser Systemarbeiten kann. Ist eine solche Schnittstelle vollstandig intern und wird von uns mitgeliefert, handelt es sich um einImplementierungsdetail, das wir nicht in der Anforderungsspezifikation nennen.

Bsp.: Wir wollen den PDA mit dem Ladenrechner uber WLAN kommunizieren lassen. Wir setzen voraus, dass der Kundefur das WLAN in seinem Laden sorgt. Dann ware WLAN mit einem Netzwerkprotokoll wie TCP/IP in derAnforderungsspezifikation zu erwahnen. Wir durfen dann in unserer Implementierung voraussetzen, dass dieAusfuhrungsumgebung diese Komponenten bereit halt. �

2.1.6 SpeicherbeschrankungenHier nennen wir die mindestens verfugbare Große des Hauptspeichers und der Festplatten, die das korrekte Funktionierenunserer Software voraussetzen darf. Anforderungen an die Laufzeit werden im Kontext der Operationen festgelegt.









20

09

-02

-09

Software-Projekt

Anforderungsanalyse



2.1.7 BetriebsoperationenNeben den eigentlichen Produktfunktionen bietet ein System meist noch eine Menge allgemeiner Operationen, die furden Betrieb der Software notwendig oder hilfreich sind. Dazu gehoren beispielsweise unterstutzendeDatenverarbeitungsfunktionen (wie z.B. Konsistenzprufungen oder allgemeine Statistiken uber die Datenvolumen) sowieSicherungs- und Wiederherstellungsoperationen. Außerdem unterstutzen viele Systeme verschiedene Operationsmodi, indenen unterschiedliche Produktfunktionen und Betriebsoperationen verfugbar beziehungsweise nicht verfugbar sind.Beispielsweise bietet eine Bank-Software einen Wartungsmodus, wahrend dessen Kunden keine Transaktionenveranlassen konnen, weil Jahresabschlusse berechnet werden.In diesem Abschnitt werden diese allgemeinen Betriebsoperationen, die relevanten Operationsmodi und die Dauer undHaufigkeit interaktiver und nichtinteraktiver Operationen aufgefuhrt.

2.1.8 Moglichkeiten der lokalen AnpassungSysteme bieten haufig die Moglichkeit, dass Benutzer lokale Anpassungen vornehmen konnen. Diese werden hierbeschrieben.

Bsp.: Der Ladenbesitzer soll beispielsweise einstellen konnen, wie viele Benutzer maximal gleichzeitig auf denLadenrechner zugreifen durfen. �

Die Norm ISO 9241-11:1998 (1998) weist Individualisierbarkeit als anzustrebendes Qualitatsmerkmal aus. Beispielsweisesollen Schriftgroßen einstellbar sein. Moglichkeiten der lokalen Anpassung der Benutzungsschnittstelle werden jedoch inAbschnitt 2.3 beschrieben.

Anforderungsanalyse


2.2 Produktfunktionen

Zusammenfassung der Funktionen

2.3 Charakteristika der Benutzer

Bildungsstand, Erfahrung, technische Kenntnisse

2.4 EinschrankungenBeispiele:

Gesetzliche RahmenbedingungenHardwarebeschrankungenparallelisierte Ausfuhrungerforderliche Zuverlassigkeitsicherheitskritische AspekteDatenschutzaspekte

2.5 Annahmen und Abhangigkeiten

z.B. Betriebssystem ist auf Hardware verfugbar




Zusammenfassung der Funktionen

2.3 Charakteristika der Benutzer

Bildungsstand, Erfahrung, technische Kenntnisse

2.4 EinschrankungenBeispiele:

Gesetzliche RahmenbedingungenHardwarebeschrankungenparallelisierte Ausfuhrungerforderliche Zuverlassigkeitsicherheitskritische AspekteDatenschutzaspekte

2.5 Annahmen und Abhangigkeiten

z.B. Betriebssystem ist auf Hardware verfugbar

20

09

-02

-09

Software-Projekt

Anforderungsanalyse



2.2 ProduktfunktionenHier werden alle Produktfunktionen, die unterstutzt werden sollen, kurz zusammengefasst. Ihre Detaillierung folgt inKapitel 3.

2.3 Charakteristika der BenutzerIn diesem Abschnitt werden die Charakteristika der Benutzer beschrieben. Dies kann in Form der oben eingefuhrtenPersonas geschehen. Alle fur uns als Entwickler relevanten Details sollten erwahnt werden. Dazu gehoren meist derBildungsstand, die Erfahrung und vorhandene technische Kenntnisse.

2.4 EinschrankungenAlle maßgebenden Einschrankungen, die die Entwicklung betreffen, werden in diesem Abschnitt aufgefuhrt. Dazugehoren sowohl die so genannten nicht-funktionalen Produktattribute als auch organisatorische Rahmenbedingungen.Hier sind zum Beispiel gesetzliche Rahmenbedingungen, weitere Hardwarebeschrankungen, Zwang zur parallelisiertenAusfuhrung, erforderliche Zuverlassigkeit, sicherheitskritische Aspekte sowie Aspekte des Datenschutzes zu nennen.

2.5 Annahmen und AbhangigkeitenUnsere Entwicklung startet oft mit Annahmen, bei denen wir zum gegenwartigen Zeitpunkt nicht sicher sind, ob siezutreffen. Wenn die Entwicklung von solche Annahmen abhangt, stellen die Annahmen ein Risiko dar, das wir in diesemAbschnitt explizit benennen. Der Architekt kann dann versuchen, die potentiellen Auswirkungen dieser Risiken imArchitekturentwurf zu minimieren.

Jede Abhangigkeit von Dritten stellt ein weiteres Risiko dar. Sie fuhren zur Annahme, dass die, von denen wir abhangen,die von uns erwunschte Leistung erbringen. Aus diesem Grund werden alle Abhangigkeiten hier auch explizit aufgefuhrt.

Anforderungsanalyse



3.1 Externe Schnittstellen

3.1.1 Benutzungsschnittstelle3.1.2 Hardwareschnittstelle3.1.3 Softwareschnittstelle3.1.4 Kommunikationsschnittstelle


3.3 Performanzanforderungen

3.4 Entwurfseinschrankungenz.B. Standards

3.5 Softwaresystemattributez.B. Zuverlassigkeit, Verfugbarkeit, Sicherheit, Wartbarkeit,Portabilitat

3.6 Andere Anforderungen











20

09

-02

-09

Software-Projekt

Anforderungsanalyse



Den großten Anteil der Anforderungsspezifikation nimmt das Kapitel 3 ein, in dem die Anforderungen in großeremDetail beschrieben werden.


3.1 Externe SchnittstellenIn den vier folgenden Abschnitten werden die verschiedenen Schnittstellen im Detail beschrieben. Auf die Spezifikationder Benutzungsschnittstelle gehen wir an dieser Stelle besonders ein.

3.1.1 BenutzungsschnittstelleDie Benutzungsschnittstelle kann durch einen GUI-Prototypen beschrieben werden. Wenn dieser ausfuhrbar ist,dann werden im Text hier die wesentlichen Interaktionskonzepte beschrieben; ansonsten wird auf denausfuhrbaren Prototypen verwiesen, der vom Kunden abgenommen sein muss. Ist der GUI-Prototyp nichtausfuhrbar, dann kann man hier die Screenshots und Skizzen einfugen, die in der Soll-Analyse erstellt wurden,um die Benutzungsschnittstelle vorzufuhren. Es genugt jedoch nicht, nur Bildschirmmasken aufzulisten. Es mussauch der Zusammenhang der Dialoge und der anderen Interaktionselementen mit den Anwendungsfallen (d.h.der Funktionalitat im Kontext des Arbeitsflusses, der unterstutzt werden soll) beschrieben werden. Fur jedeEingabemoglichkeit muss beschrieben sein, was damit ausgelost werden kann und welche Ausgabe erfolgt.Ebenso muss die Navigation zwischen allen Dialogen und etwaige Zustande der Schnittstelle beschrieben sein.Die Beschreibung soll so genau sein, dass man daraus ohne weitere Schritte ein Benutzerhandbuch erstellenkann. Die Entscheidung, wie die Benutzungsschnittstelle auszusehen hat, liegt also nicht beim Programmiererspater, sondern steht von Anfang an fest.

3.1.2 Hardwareschnittstelle3.1.3 Softwareschnittstelle3.1.4 Kommunikationsschnittstelle

3.2 ProduktfunktionenIn diesem Abschnitt werden die Produktfunktionen im Detail beschrieben. Dieser Abschnitt bildet in der Regel mit derBenutzungsschnittstelle zusammen den umfangreichsten Teil. Deshalb ist eine sinnvolle Glieder unabdingbar. Wir werdenweiter unten auf alternative Gliederungen eingehen. Der Zusammenhang zwischen Benutzungsschnittstellen (sowie allenanderen Schnittstellen) und der hier beschriebenen Produktfunktionen muss klar gemacht werden.










20

09

-02

-09

Software-Projekt

Anforderungsanalyse



3.3 PerformanzanforderungenFunktionale Anforderungen beschreiben die erwartete Ausgabe auf eine Eingabe hin. Bei Echtzeitsystemen mit hartenDeadlines muss nicht nur die erwartete Ausgabe angegeben werden, sondern auch nach welcher Zeit die Antworterfolgen muss, da sie ansonsten nicht mehr gebraucht wird. Bei Systemen ohne Echtzeitanforderungen hingegen werdenzeitliche Aspekte haufig nicht explizit angegeben. Das ist jedoch falsch. Denn auch bei interaktiven Systemen erwartenwir 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, uber die Vertragserfullung bei der Abgabezu diskutieren. Deshalb sollte man grundsatzlich Aussagen zur erforderlichen Performanz jeder Funktionalitat machen.Dies kann relativ zum Datenvolumen erfolgen oder in absoluten Zeitangaben. Im letzteren Fall nimmt das Mengengerusteine noch gewichtigere Stellung ein. Denn nur durch das Mengengerust konnen wir zu absoluten Zeiten kommen, diespater uberprufbar sind.

In diesem Abschnitt ist der Platz fur die Beschreibung der Performanzanforderungen aller Produktfunktionen. Alternativkann man diese Anforderungen auch bei der Beschreibung der Produktfunktionen angeben und dann auf diesenAbschnitt verzichten. Das Prinzip der Trennung von Aspekten, dem wir bei einer Anforderungsspezifikation folgen, legtaber einen eigenen Abschnitt nahe. Die Beschreibung kann z.B. durch einfache Tabellen erfolgen, in denen dieProduktfunktionen aufgefuhrt sind und die maximale Reaktionszeit in Abhangigkeit der Eingabe angegeben wird.

3.4 EntwurfseinschrankungenImplementierungsdetails gehoren – wie schon mehrfach gesagt – nicht in die Anforderungsspezifikation. Es gibt aberdennoch haufig Aspekte, die beim Entwurf berucksichtigt werden mussen. Dazu gehoren z.B. Standards, an die sich dieSoftware halten muss. In der Luft- und Raumfahrt beispielsweise gibt es Codierungsstandards wie MISRA, derenEinhaltung zuverlassigere Systeme verspricht. Hersteller von Software mussen sich an solche Standards halten, sonstwird ihr System nicht verwendet. In diesem Abschnitt werden aus diesem Grund alle weiteren Einschrankungen desEntwurfs beschrieben, sofern sie aus Kundensicht relevant sind.










20

09

-02

-09

Software-Projekt

Anforderungsanalyse



3.5 SoftwaresystemattributeNeben Performanzanforderungen gibt es noch weitere Systemattribute, zu denen die Anforderungsspezifikation Aussagenmachen muss. Dazu gehoren Zuverlassigkeit, Verfugbarkeit, Sicherheit, Wartbarkeit, Portabilitat und weitereSoftwarequalitaten (oft auch nichtfunktionale Anforderungen genannt). Wir werden weiter unten noch darauf zusprechen kommen, dass diese Art Anforderungen konkret beschrieben werden mussen. Die Forderung

”Das System muss

sicher sein“ ist viel zu allgemein als dass man sie erfullen konnte.

3.6 Andere AnforderungenIn diesem Abschnitt konnen weitere relevante Anforderungen beschrieben werden, die in keine der oben genanntenAbschnitte passen.










20

09

-02

-09

Software-Projekt

Anforderungsanalyse



Erganzungen zum Standard:

Die Anforderungsspezifikation nach IEEE Standard 830.1998 verlangt nirgendwo, dass die Ergebnisse derIst-Analyse beschrieben werden sollen. Diese Ergebnisse sind jedoch wichtig, um die Anforderungen zu verstehenund einschatzen zu konnen. Man sollte deshalb entweder ein eigenes Dokument hierfur anlegen, das in derAnforderungsspezifikation referenziert wird, oder aber im Einfuhrungskapitel einen entsprechenden Abschnittverfassen.

Außerdem weist der Standard an keiner Stelle darauf hin, dass auch die moglichen zukunftigen Anderungen derAnforderungen beschrieben sein sollten. Diese sind jedoch wichtig, damit der Architekt die Architektur so entwerfenkann, dass diese Anderungen – so sie eintreffen – relativ einfach umgesetzt werden konnen. Aus diesem Grundeempfiehlt sich in Kapitel 2 beziehungsweise Kapitel 3 (je nach Detaillierungsgrad) ein Abschnitt zu zukunftigenEntwicklungen der Anforderungen.

Im Datenmodell modellieren wir die Objekte der Anwendungsdomane, die fur die Beschreibung unsererAnforderungen relevant sind. Im Standard wird kein Ort explizit genannt, an dem das Datenmodell beschriebenwerden soll. Hier bietet sich ein Unterabschnitt in Abschnitt 2.2 an.

Anforderungsanalyse

Softwaresystemattribute

Softwaresystemattribute:

oft als nicht-funktionale Anforderungen bezeichnet

mussen objektivierbar sein

Das System soll sicher sein.

versus:

PGP-Verschlusselung wird verwendet

Logging aller Aktionen

Nachrichten durfen nur uber Verschlusselungskomponente geschehen

Indizierte Zugriffe auf Felder mussen zur Laufzeit gepruft werden



Softwaresystemattribute:

oft als nicht-funktionale Anforderungen bezeichnet

mussen objektivierbar sein

Das System soll sicher sein.

versus:

PGP-Verschlusselung wird verwendet

Logging aller Aktionen

Nachrichten durfen nur uber Verschlusselungskomponente geschehen

Indizierte Zugriffe auf Felder mussen zur Laufzeit gepruft werden20

09

-02

-09

Software-Projekt

Anforderungsanalyse



Wie oben beim Abschnitt 3.5 Softwaresystemattribute erwahnt sind neben den funktionalen Anforderungen auchdie so genannten nicht-funktionalen Anforderungen, wie Portierbarkeit etc., zu beschreiben. Wie wir auch schonoben diskutiert haben, sollen alle Anforderungen uberprufbar sein. Das heißt die Aussagen zu dennicht-funktionalen Eigenschaften mussen so genau und konkret sein, dass man eine Prufprozedur angeben kann, umbei Auslieferung uberprufen zu konnen, ob die Anforderung erfullt wurde. Die Forderung

”Das System muss sicher

sein“ genugt diesem Anspruch nicht, weil nicht klar ist, wogegen das System gesichert werden soll. Konkreter sollteman also etwa fordern:

• Alle Netzwerktransaktionen werden mit PGP verschlusselt.

• Alle Operationen des Administrators werden aufgezeichnet.

• Alle Benutzer mussen sich mit einem mindestens acht Zeichen langen Passwort authentifizieren.

Diese Aussagen sind uberprufbar. Interessanterweise stellen wir an dieser Stelle fest, dass aus den so genanntennicht-funktionalen Eigenschaften durch die Konkretisierung funktionale Eigenschaften werden konnen. DieTrennung in funktionale und nicht-funktionale Eigenschaften ist also etwas kunstlich bei allen Eigenschaften, dieexterne Eigenschaften betreffen. Externe Eigenschaften sind solche, die der Benutzer direkt wahrnehmen kann.Interne Eigenschaften betreffen vielmehr den inneren Aufbau.

Anforderungsanalyse


Das System soll portierbar sein.

versus:

Anteil der plattformabhangigen Komponenten < 2%

Anteil der plattformabhangigen Codezeilen < 5%

Verwendung einer portierbaren Hochsprache

Einschrankung auf portierbare Sprachkonstrukte

Verwendung eines verbreiteten Betriebssystems



Das System soll portierbar sein.

versus:

Anteil der plattformabhangigen Komponenten < 2%

Anteil der plattformabhangigen Codezeilen < 5%

Verwendung einer portierbaren Hochsprache

Einschrankung auf portierbare Sprachkonstrukte

Verwendung eines verbreiteten Betriebssystems

20

09

-02

-09

Software-Projekt

Anforderungsanalyse



Aber auch Anforderungen zu inneren Eigenschaften der Software mussen hinreichend genau angegeben sein. DieAussage

”Das System soll portierbar sein“, die eine innere Qualitat darstellt, kann nicht uberpruft werden, weil

nicht klar ist, wohin portiert werden soll und was Portierbarkeit genau bedeuten soll. Besser muss angegebenwerden, auf welcher Hardware und fur welches Betriebssystem die Software portiert werden soll. Dann muss derBegriff portierbar konkretisiert werden, z.B. auf die folgende Weise:

• Der Anteil der plattformabhangigen Komponenten soll weniger als 2% ausmachen.

• Der Anteil der plattformabhangigen Codezeilen soll weniger als 5% sein.

• Es soll eine Hochsprache als Implementierungssprache verwendet werden, die auf allen Plattformen verfugbar ist, auf dieportiert werden soll.

• Alle verwendeten Konstrukte der Programmiersprache mussen auf allen Zielplattformen verfugbar sein.

Anforderungsanalyse

Prasentation der Anforderungen

Funktionale Anforderungen geordnet nach:

Operationsmodus

z.B. Kontrollsysteme: Training, Normal, Notfall

Benutzerklassen

z.B. Fahrzeugsteuerung: Fahrer, Fahrgaste, Wartungstechniker

Objekte und Klassen

z.B. Patientenmonitorsystem: Patienten, Sensoren, Pflegepersonal,Raume, Arztinnen, Medizinjede Klasse wird beschrieben durch ihre Attribute und Methoden

Features oder auch Anwendungsfalle (gewunschter nach außensichtbarer Service)

z.B. Telefonsystem: Nahgesprach, Weiterleitung, Konferenzgesprach

Stimuli (bei reaktiven Systemen)

z.B. Landesystem eines Flugzeugs: Energieverlust, Windwechsel,Schlingern



Funktionale Anforderungen geordnet nach:

Operationsmodus

z.B. Kontrollsysteme: Training, Normal, Notfall

Benutzerklassen

z.B. Fahrzeugsteuerung: Fahrer, Fahrgaste, Wartungstechniker

Objekte und Klassen

z.B. Patientenmonitorsystem: Patienten, Sensoren, Pflegepersonal,Raume, Arztinnen, Medizinjede Klasse wird beschrieben durch ihre Attribute und Methoden

Features oder auch Anwendungsfalle (gewunschter nach außensichtbarer Service)

z.B. Telefonsystem: Nahgesprach, Weiterleitung, Konferenzgesprach

Stimuli (bei reaktiven Systemen)

z.B. Landesystem eines Flugzeugs: Energieverlust, Windwechsel,Schlingern

20

09

-02

-09

Software-Projekt

Anforderungsanalyse



Wie oben erwahnt, kommt der Strukturierung des Abschnitts 3.2 Produktfunktionen eine große Bedeutung zu.Dieses Kapitel ist sehr umfangreich und alle Leser sollen sich moglichst einfach darin zurecht finden.

Welche Kategorisierung zu verwenden ist, hangt 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 einerSoftware, die das Landen eines Flugzeugs steuert, konnte man z.B. nach plotzlichem Energieverlust, Windwechseloder Schlingern etc. ordnen. Zu den allgemeineren Ordnungskriterien, die bei sehr vielen Arten von SystemenAnwendung finden konnen, zahlen Operationsmodi. Kontrollsysteme haben z.B. haufig die OperationsmodiTraining, Normal und Notfall. Ein weiteres allgemeines Kriterium ist das der Benutzerklassen. Die Software einesBusses konnte unterscheiden in Produktfunktionen, die Fahrer, Fahrgaste oder Wartungstechniker betreffen. Beiobjektorientiertem Vorgehen ergeben sich in der Analyse Objekte und Klassen, nach denen man gruppieren konnte.In einem Patientenmonitorsystem erwarten wir als Klassen z.B. Patienten, Sensoren, Pflegepersonal, Raume,Arztinnen, Medizin. Jede dieser Klassen wird dann beschrieben durch ihre Attribute und Nachrichten, die sieversteht. Schließlich konnen wir auch nach Anwendungsfallen kategorisieren. Bei einem Telefonsystem waren daszum Beispiel das Nahgesprach, die Weiterleitung und das Konferenzgesprach.

Wie immer man sich entscheidet, man sollte in jedem Falle die Kategorisierung uniform anwenden. Es kanndennoch sinnvoll sein, Kategorien zu kombinieren, was kein Widerspruch zur Uniformitat sein muss. Dem Ziel derUniformitat genugend konnte man z.B. auf erster Ebene nach Benutzerklassen ordnen und auf zweiter Ebene nachAnwendungsfallen.

Anforderungsanalyse


Was ist an der Erhebung der Anforderungen so schwierig?

Erlautern Sie das Kano-Modell. Was folgt daraus fur dieAnforderungsspezifikation?

Wozu dient die Anforderungsspezifikation und welche Folgen habenihre Mangel?

Was sind die Schritte der Anforderungsspezifikation?

Was sind Personas und welches Ziel wird mit ihnen verfolgt?

In welchen Phasen des Entwicklungsprozesses konnen Personasverwendet werden?

Was ist das Ziel der Ist-Analyse und aus welchen Schritten bestehtsie?

Erlautern Sie Techniken zur Ist-Analyse. Bewerten Sie sie.

Insbesondere: Auf welchen Prinzipien basiert das Interview imKontext und wie wird es durchgefuhrt?


Anforderungsanalyse


Welche Arten des Prototypings gibt es und wozu dienen sie?

Wegwerf-, technischer und evolutionarer 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 eineRolle und worauf ist bei ihrer Spezifikation zu achten?


Objektorientierte Modellierung






Wiederholungsfragen5 Objektorientierte Modellierung

LernzieleModellbildungObjektorientierte ModellierungGeschaftsprozesseAnwendungsfalleUML-Notation fur AnwendungsfalleStatische Eigenschaften: KlassendiagrammeVerhaltenseigenschaftenInteraktionsdiagrammeSequenzdiagrammeKommunikationsdiagrammeAktivitatsdiagrammeZustandsautomatendiagrammeWiederholungsfragenMotivationLernzieleSoftware-PrufungenReviewsAblauf von ReviewsReview-RegelnReview-ChecklistenReview-VariantenFallen und GegenmittelWiederholungsfragenMotivationLernzieleErgonomiePsychologische und kognitive GrundlagenKommandosprachen versus GUIGeschichte graphischer BenutzungsschnittstellenInteraktionsmechanismenSoftware-ergonomische RichtlinienUsability messen und verbessernZusammenfassungWiederholungsfragenWas ist Software-Architektur?EinflussfaktorenArchitektursichten und -blickwinkelKonzeptioneller BlickwinkelModulblickwinkelAusfuhrungsblickwinkelCode-SichtModularisierungSchnittstellenKopplung und ZusammenhaltQualitatenBewertung von ArchitekturenWiederholungsfragenWas ist ein Entwurfsmuster?Bestandteile eines EntwurfsmustersKategorien von EntwurfsmusternEntwurfsmuster Factory MethodEntwurfsmuster ObserverArchitekturstileArchitekturstil SchichtungArchitekturstil Model-View-ControllerWiederholungsfragenBegriffe des TestensSoziologie des TestensTestaktivitatenTestfallTeststumpfe und -treiberKomponententestsAquivalenztestKomponententest mit JUnitGrenztestPfadtestMaße der TestabdeckungZustandsbasiertes TestenIntegrationstestLeistungstestsZusammenfassung der TestartenTestmanagementTestplanTestfallspezifikationTestschadensberichtWiederholungsfragenMotivationArchitekturkonformitatProgrammierrichtlinienAnhangWiederholungsfragenLernzieleWas ist Benutzerdokumentation?Arten der DokumentationStrukturAuf Papier oder elektronisch?AutorWie schreibt man eine Dokumentation?Hinweise und RegelnWiederholungsfragenObjektorientierte ModellierungSoftwarearchitekturEntwurfsmuster und ArchitekturstileSoftwaretechnik im Allgemeinen



Lernziele

objektorientiert modellieren konnen

wesentliche Konstrukte der Unified Modeling Language (UML) lesenund anwenden konnen

Anmerkung: kein UML-Kurs; zur UML siehe z.B.: Storrle (2005).



Modellierung

Was ist ein Modell?

Abbild eines Originals

Wozu modellieren wir?

um etwas zu verstehenum Vorhersagen machen zu konnenum etwas zu dokumentieren

Wann modellieren wir?

jederzeit: Projektplan, Anforderungen, Architektur, . . .




Ausgehend von Geschaftsprozessen. . .

Identifiziere Aktoren

Beschreibe Anwendungsfalle

Bestimme statisches Modell

Identifiziere ObjekteIdentifiziere Eigenschaften der ObjekteBestimme Assoziationen zwischen ObjektenFasse Objekte zu Klassen zusammenOrdne Klassen in Vererbungshierarchien einBestimme Multiplizitaten der Assoziationen

Erstelle Verhaltensmodell

Identifiziere Ereignisse und modelliere Interaktionen inAnwendungsfallenIdentifiziere Verhalten der ObjekteBeschreibe das Verhalten (Vor- und Nachbedingungen)



Ausgehend von Geschaftsprozessen. . .

Identifiziere Aktoren

Beschreibe Anwendungsfalle

Bestimme statisches Modell

Identifiziere ObjekteIdentifiziere Eigenschaften der ObjekteBestimme Assoziationen zwischen ObjektenFasse Objekte zu Klassen zusammenOrdne Klassen in Vererbungshierarchien einBestimme Multiplizitaten der Assoziationen

Erstelle Verhaltensmodell

Identifiziere Ereignisse und modelliere Interaktionen inAnwendungsfallenIdentifiziere Verhalten der ObjekteBeschreibe das Verhalten (Vor- und Nachbedingungen)

20

09

-02

-09

Software-Projekt




Dies ist keine streng sequenzielle Folge. Die Aktivitaten verlaufen vielmehr parallel und iterativ.


Ist → Soll

Schwierig: Dinge im Abstrakten beschreiben.

Einfacher: von konkreten Geschaftsprozessen ausgehen.

Definition

Ein Geschaftsprozess ist eine Folge von Schritten oder ein Rezept, umein Geschaftsresultat zu erzielen.



Prosaische Geschaftsprozessbeschreibung im Fahrradladen

Geschaftsprozess Einkauf

Kunde Konig mochte Flaschenhalter kaufen; besitzt mehrereFahrrader

Konig tritt in den Laden und zuckt sein PDA

PDA bietet alle Rader des Kunden an

Konig wahlt sein 28”-Rennrad mit Rahmen-Standardbohrung aus;Rahmenfarbe: magenta

Konig wahlt “Hinzufugen” aus

Konig gibt “Flaschenhalter” ein und quittiert

PDA nimmt Verbindung mit Laden-Host-Rechner auf

PDA ubermittelt Anfrage fur Flaschenhalter (verschlusselt!)

Host-Rechner ubermittelt Sortiment Flaschenhalter (verschlusselt!)

PDA pruft auf Vertraglichkeit mit ausgewahltem Rad



Beispiel Fahrradladen (Forts.)

Geschaftsprozess Einkauf (Forts.)

PDA prasentiert alle Flaschenhalter, die passen (hartes Kriterium)

Konig deselektiert alle Flaschenhalter mit unpassender Farbe (weichesKriterium)

Konig lasst nach Preis sortieren

Konig wahlt Flaschenhalter in bestimmtem Preissegment aus

Konig geht mit Auswahl zu Verkaufer

Verkaufer Volker betrachtet Auswahl und berat



Geschaftsprozess und Anwendungsfall (Use-Case)

Merkmale von Geschaftsprozessen:

systemubergreifend,

unterbrechbar,

lang laufend,

erfordern fortlaufende Interaktion zwischen vielen Akteuren,

bestehen aus Anwendungsfallen.

Definition

Anwendungsfall (auch: Nutzfall)

beschreibt eine Menge von Aktionssequenzen (Varianteneingeschlossen)

jede Sequenz reprasentiert die Interaktion zwischen externen Aktorenmit dem System

Folge ist beobachtbares Resultat, relevant fur Aktor



Aktor

Definition

Aktor

reprasentiert eine koharente Menge von Rollen, die von Benutzern inder Interaktion mit dem System eingenommen werden konnen

konnen Menschen und andere Dinge sein (z.B. andere automatisierteSysteme)

Beispiel:

Geschaftsprozess Einkauf im Fahrradladen

ein Anwendungsfall darin: Kunde verbindet seinen PDA mit demLadenrechner

→ Akteure: Kunde, Ladenrechner



Textuelle Beschreibung von Anwendungsfallen

Name: ArtikelerganzungAktoren:

Kunde und Verkaufer

Vorbedingung:Kunde mochte erganzenden Artikel kaufenKunde und Verkaufer sind im LadenPDA und Ladenrechner sind verbunden

Nachbedingung:Kunde hat Artikel ausgewahlt

Ablauf:1 Kunde wahlt zu erganzenden Artikeltyp fur Rad R aus2 Ladenrechner liefert alle Artikel dieses Typs, die zu R passen3 Kunde wahlt aus dieser Liste aus

Varianten:Kunde findet keinen passenden Artikel→ Verkaufer berat Kundekeine Verbindung zwischen PDA und Ladenrechner→ Verkaufer berat Kunde



Aktoren und Anwendungsfalle

1 Identifiziere Aktoren

2 Betrachte System aus der Sicht der Aktoren3 Bestimme Anwendungsfalle fur Aktoren

→ liefert moglicherweise neue Aktoren

4 zuruck zu 1, bis keine neuen Aktoren/Anwendungsfalle mehrgefunden werden konnen



UML-Notation fur Anwendungsfalle (OMG)

System

Waren−

sortiment

pflegen

entfernen

Produkt

obsoletes

Passendes

Produkt

finden

Kunde Verkäufer

AktorAnwendungsfall

Assoziation



System

Waren−

sortiment

pflegen

entfernen

Produkt

obsoletes

Passendes

Produkt

finden

Kunde Verkäufer

AktorAnwendungsfall

Assoziation

20

09

-02

-09

Software-Projekt


UML-Notation fur Anwendungsfalle


Assoziationen werden in Anwendungsfalldiagrammen nicht benannt. Assoziationen sind keine Datenflusse;Assoziationen beschreiben Kommunikationsbeziehungen zwischen Aktoren und dem System.


Aktoren und Anwendungsfalle

Strukturiere Anwendungsfalle

1 identifiziere gemeinsame Anteile in Anwendungsfallen und faktorisiereentsprechend

2 fasse ahnliche Anwendungsfalle und Aktoren in Vererbungshierarchienzusammen




Person

Ladenbesitzer

Verkäufer

Retinatest

Passwort−

abfrage

inherits

Authentifizierung

<<include>>

<<include>>

Waren−

sortiment

pflegen

Kunden−

daten

pflegen



Person

Ladenbesitzer

Verkäufer

Retinatest

Passwort−

abfrage

inherits

Authentifizierung

<<include>>

<<include>>

Waren−

sortiment

pflegen

Kunden−

daten

pflegen

20

09

-02

-09

Software-Projekt




Mit Hilfe von <<include>> kann man gemeinsames Verhalten aus Anwendungsfallen herausfaktorisieren und nureinmal beschreiben; hilft, Redundanz zu vermeiden.Bedeutung B <<include>> A:

• Anwendungsfall B (Base) inkludiert das Verhalten von Anwendungsfall A (Inklusion)

• Anwendungsfall B ist ohne Inklusion A nicht notwendigerweise ein vollstandiger Anwendungsfall

• Inklusion B kann ein Fragment sein

Verwendung

• Verhalten von Inklusion A wird in mehreren Anwendungsfallen benotigt

Generalisierung: Anwendungsfalle konnen durch die inherit-Beziehung spezialisiert werden. Entspricht derobjektorientierten Vererbung.Bedeutung

• Anwendungsfall A (Child) erbt das Verhalten von Anwendungsfall B (Parent)

• Anwendungsfall B ist ein vollstandiger, von A unabhangiger Anwendungsfall

• Anwendungsfall A ist ein vollstandiger Anwendungsfall

Verwendung

• Verhalten eines Anwendungsfalls wird spezialisiert



Spezialanwendungsfall

Basisanwendungsfall

Variationspunkt

Erweiterungsrelation

Express−

bestellung

ausführen Bestellung

Priorität setzenExtension Points:

ausführen

<<extend>>

(setze Priorität)



Spezialanwendungsfall

Basisanwendungsfall

Variationspunkt

Erweiterungsrelation

Express−

bestellung

ausführen Bestellung

Priorität setzenExtension Points:

ausführen

<<extend>>

(setze Priorität)

20

09

-02

-09

Software-Projekt




Extend-Relation erlaubt die Beschreibung optionalen Verhaltens. Erlaubt damit die Trennung des optionalen vomnotwendigen Verhalten. Kann auch benutzt werden, um ein alternatives Teilverhalten zu beschreiben, das anBedingungen geknupft ist (z.B. Fehlerausgabe und Benachrichtigung des Systemadministrators falls Passwort falschist). Kann auch verwendet werden, um Teilsequenzen zu kombinieren, deren Ausfuhrung vom Benutzer bestimmtwird (z.B. Dialog zur Auswahl von Operationen).Bedeutung: A <<extend>> B:

• Anwendungsfall A (Extension) erweitert das Verhalten von Anwendungsfall B (Base)

• Anwendungsfall B ist auch ohne Extension A ein vollstandiger Anwendungsfall

• Extension A kann ein Fragment sein

Verwendung

• Verhalten eines Anwendungsfalls wird erweitert


Beschreibung von Anwendungsfallen

Anwendungsfalldiagramme:

deklarieren voneinander unabhangige Anwendungsfalle

beschreiben die Einbettung der Anwendungsfalle in denSystemkontext (externe Akteure)

beschreiben (konkretisieren) die Anwendungsfalle jedoch nicht

→ folgt spater

sind Ausgangspunkt fur die objektorientierte Modellierung

statische Eigenschaften (Attribute)dynamische Eigenschaften (Verhalten)



Beispiel Fahrradladen

Identifiziere Objekte: Suche nach Substantiven in Anwendungsfallen.

Operation: Einkauf

Kunde Konig mochte Sattel kaufen; besitzt mehrere Fahrrader

. . .

Konig wahlt sein 28”-Rennrad mit aus; Rahmenfarbe: magenta

. . .

PDA nimmt Verbindung mit Laden-Host-Rechner auf

. . .

Konig lasst nach Preis sortieren

. . .

Verkaufer Volker betrachtet Auswahl und berat



Anwendungsfall → Objekte

Objekt:”Ding“ (Gegenstand, Entitat) mit eigener Identitat

Volker :

König :

+geld = 40 EUR

Königs Rennrad :

+preis = 1500 EUR

+farbe = magenta

+größe = 60 cm

Sattel #1234 :

+preis = 20 EUR

+farbe = schwarz

+härte = knallhart

+gewicht = 200 g

Objekt (unterstrichen)Eigenschaft/Attribut

Königs Hollandrad :

+preis = 400 EUR

+farbe = schwarz

+größe = 58 cm

Wert



Anwendungsfall → Objekte

Assoziation: Beziehung zwischen Objekten

Volker :

König :

+geld = 40 EUR

Königs Rennrad :

+preis = 1500 EUR

+farbe = magenta

+größe = 60 cm

Sattel #1234 :

+preis = 20 EUR

+farbe = schwarz

+härte = knallhart

+gewicht = 200 g

Königs Hollandrad :

+preis = 400 EUR

+farbe = schwarz

+größe = 58 cm

besitzt

besitzt

passt-zu

berät+Berater+Interessent

im-sortiment

Assoziation

AssoziationsnameRichtung

Rolle



Objekte versus Klassen

Instanz-Ebene

Objektdiagramme beschreiben statische Zusammenhange auf derEbene einzelner, konkreter Dinge

Schema-Ebene

Klassendiagramme beschreiben statische Zusammenhangeunabhangig von Details konkreter Objekte, auf der Ebene mehrerergleichartiger Dinge



Instanz-Ebene

Objektdiagramme beschreiben statische Zusammenhange auf derEbene einzelner, konkreter Dinge

Schema-Ebene

Klassendiagramme beschreiben statische Zusammenhangeunabhangig von Details konkreter Objekte, auf der Ebene mehrerergleichartiger Dinge

20

09

-02

-09

Software-Projekt


Statische Eigenschaften: Klassendiagramme


Bemerkung

• Objektdiagramme werden in der UML als Teil der Klassendiagramme aufgefasst


Objekte → Klassen

Klasse: Menge von gleichartigen Objekten mit gemeinsamen Eigenschaften

Verkäufer

+name

Kunde

+name

+geld

Sattel

+artikelnummer

+preis

+farbe

+härte

+gewicht

Klasse

Rad

+preis

+farbe

+größe

besitzt

im-sortiment

berät

passt-zu

1

Multiplizität

1

*

*



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:

AttributeMethoden und deren AufrufschnittstellenAssoziationen

Unterklassen konnen

neue Attribute, Methoden und Assoziationen definieren

ererbte Attribute, Methoden und Assoziationen redefinieren(uberschreiben)

von mehreren Oberklassen erben (Mehrfachvererbung)


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:

AttributeMethoden und deren AufrufschnittstellenAssoziationen

Unterklassen konnen

neue Attribute, Methoden und Assoziationen definieren

ererbte Attribute, Methoden und Assoziationen redefinieren(uberschreiben)

von mehreren Oberklassen erben (Mehrfachvererbung)

20

09

-02

-09

Software-Projekt



Generalisierungen

Bemerkung: unterschiedliche Umsetzung in verschiedenen Programmierumgebungen bzgl. Uberschreiben undMehrfachvererbung


Klassen → Klassenhierarchien

VerkäuferKunde

+geld

Rad

+farbe

+größe

Sattel

+farbe

+härte

+gewicht

Unterklasse

ist-ein-Relation

OberklassePerson

+name

abstrakt

Artikel

+preis

+artikelnummer

berät

im-sortiment

passt-zu

besitzt

{XOR}

Einschränkungzweier Beziehungen



VerkäuferKunde

+geld

Rad

+farbe

+größe

Sattel

+farbe

+härte

+gewicht

Unterklasse

ist-ein-Relation

OberklassePerson

+name

abstrakt

Artikel

+preis

+artikelnummer

berät

im-sortiment

passt-zu

besitzt

{XOR}

Einschränkungzweier Beziehungen

20

09

-02

-09

Software-Projekt




Gemeinsame Attribute werden in gemeinsamen Oberklassen zusammengefasst. Kunde und Verkaufer haben jeweilsNamen. Rad und Sattel haben einen Preis und eine Artikelnummer. Das Attribut Farbe taucht in diesem Beispielnicht in der Oberklasse auf. Die Konsequenz ware sonst, dass jeder mogliche Artikel dieses Attribut hat. Bei vielenArtikeln, wie z.B. bei einem Sattelrohr oder einer Schraube, spielt Farbe aber keine Rolle. Deshalb tritt Farbe nurbei Rad und Sattel auf. Eine alternative Modellierung ware eine weitere Oberklasse Gefarbte Artikel von Rad undSattel, die dieses Attribut einfuhrt. Allerdings konnte es noch eine weitere Klasse Sattelrohr geben, die zwar keineFarbe, aber eine Harte hatte. Dann mussten auch Sattel und Sattelrohr eine gemeinsame Oberklasse mit demAttribut Harte haben. Dies fuhrte dann zu Mehrfachvererbung, weil ein Sattel sowohl Farbe als auch Harte hat.Bei der Modellierung von Anwendungskonzepten kann es gelegentlich zu Mehrfachvererbungen kommen. Dies istnicht weiter tragisch, solange in jedem Falle Liskovs Substitutionsprinzip erfullt ist. Bei der Abbildung desAnalysemodells auf eine konkrete Implementierung mit einer Programmiersprache ohne Mehrfachvererbung wird esdann allerdings zu einem Bruch kommen. In der Analysephase konzentrieren wir uns jedoch auf eine genaue undeinfache Modellierung und sollten uns deshalb von solchen Implementierungseinschrankungen noch nicht beirrenlassen.Meist sind diese neuen Oberklassen abstrakt, d.h. es gibt eigentlich kein Objekt, das genau von diesem Typ ist. Soist Person naturlich ein abstraktes Gebilde: Es gibt eigentlich nur Kunden oder Verkaufer, aber nichts, was man nurals Person bezeichnen wurde.Abstrakte Klassen sind daran zu erkennen, dass ihr Name kursiv geschrieben wird. In diesem Beispiel sind Personund Artikel abstrakt.


Attributierte Assoziationen

Assoziationsklassen

beschreiben Beziehungen, die gleichzeitig Klassen sind

werden genutzt, um Assoziationen Attribute zuzuordnen

konnen eigene Beziehungen eingehen

Verkäufer

Sattel

+artikelnummer

+preis

+farbe

+härte

+gewicht

im-sortiment

+anzahl

Assoziationsklasse



Mehrstellige Assoziationen

Assoziationsklassen

konnen 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


Aufbau von Objekten

Aggregation

ist spezielle Assoziation zur Verdeutlichung von

”Teil-Ganzes-Beziehungen“

beschreibt Zusammenfassung von Komponenten zu einem Aggregat2

00

9-0

2-0

9

Software-Projekt



Aufbau von Objekten

Leserichtung der Aggregation: Rad besteht aus einem Rahmen; ein Rahmen kann Teil eines oder gar keines Radssein.


Aufbau von Objekten

Komposition ist spezielle Aggregation:

Existenz der Komponenten ist an die Existenz des Aggregatsgekoppelt,

jede Komponente gehort zu genau einem Aggregat (strong ownership)


Aufbau von Objekten

Komposition ist spezielle Aggregation:

Existenz der Komponenten ist an die Existenz des Aggregatsgekoppelt,

jede Komponente gehort zu genau einem Aggregat (strong ownership)2

00

9-0

2-0

9

Software-Projekt



Aufbau von Objekten

Brennt der Laden ab, sind auch alle seine Artikel verloren. Ein Verkaufer ohne einen Laden, ist kein Verkaufer mehr(auch wenn er als Person weiter existiert).Man wurde kaum behaupten wollen, dass ein Artikel Teil eines Kunden ist. Die normale Assoziation erscheint hierangemessener. Kauft ein Kunde einen Artikel in einem Laden, ist dieser nicht langer Teil des Ladens; er geht in denBesitz des Kunden uber.


Vergleich der Assoziationstypen

Vererbung: ist-ein-Relation (Liskovs Substitutionsprinzip erfullt)

Aggregation: teil-von-Relation

Komposition: teil-von-Relation

Teil gehort zu genau einem GanzenTeil existiert nur im Kontext des Ganzen

allgemeine Assoziation: sonst



Liskovs Substitutionsprinzip (1988; 1994)

Definition

Liskovs Substitutionsprinzip: jede Instanz der Unterklasse kann immerund uberall dort eingesetzt werden, wo Instanzen der Oberklasse auftreten.



Zusammenfassung Klassendiagramme

Beschreibungsinhalt

statische Systemaspekte

Beschreibung der wesentlichen, unterscheidbaren Dinge eines Systemsund ihrer Beziehungen

zentrale Modellierungskonstrukte:

Klassen

Assoziationen (Beziehungsklassen)

spezielle Assoziationen: Generalisierung und Aggregation/Komposition



Beschreibung von Anwendungsfallen

textuelle Szenario-Beschreibungen (siehe oben)

Interaktionsdiagramme

Aktivitatsdiagramme

Zustandsdiagramme




Kollaboration

Anwendungsfall

RealisierungPassendes

Produkt

finden Produkt−

suche



Kollaboration

Anwendungsfall

RealisierungPassendes

Produkt

finden Produkt−

suche

20

09

-02

-09

Software-Projekt


Verhaltenseigenschaften


Anwendungsfalle konnen durch die inherit-Beziehung spezialisiert werden. Entspricht der objektorientiertenVererbung.


UML-Interaktionsdiagramme (OMG)

Beschreibungsinhalt:

dynamische Systemaspekte

exemplarische Beschreibung von Interaktionsabfolgen zwischenkollaborierenden Objekten (Inter-Objektverhalten)

zentrale Modellierungskonstrukte:

Objekte:”Dinge“ mit eigener Identitat

Nachrichten

beschreiben den Austausch von Informationen zwischen Objekten zumAuslosen von Aktivitatensind Signale/Ereignisse oder Methodenaufrufe



UML-Interaktionsdiagramme (OMG)

Anwendung

Prazisierung von Szenarien (exemplarische Folgen von Aktivitaten)

Protokollierung des Nachrichtenaustausches

Erhebung der von einzelnen Objekten bereit gestellten Funktionalitat(Dienste, Methoden)

Varianten

Sequenzdiagramme

betonen zeitlichen Ablauf

Kommunikationsdiagramme

betonen Objektstruktur

Grenzen:

beschreiben Verhalten nur beispielhaft und nicht vollstandig



UML-Sequenzdiagramme (OMG)



20

09

-02

-09

Software-Projekt


Sequenzdiagramme


Aufruf: synchrone Nachricht dargestellt durch durchgezogenen Pfeil vom Sender zum Empfanger mit gefullterPfeilspitze. Sender setzt Aktivitat aus (gestrichelter Aktivierungsbalken); Empfanger wird aktiviert(Aktivierungsbalken beim Empfanger beginnt).

Antwort synchrone Nachricht als Reaktion auf einen Aufruf dargestellt durch gestrichelter Pfeil vom Sender zumEmpfanger mit offener Pfeilspitze). Antwortender Sender wird deaktiviert, ausgesetzter Empfanger lebtwieder auf.

Signal asynchrone Nachricht dargestellt durch durchgezogenen Pfeil vom Sender zum Empfanger mit offenerPfeilspitze; Sender und Empfanger setzen ihre Aktivitat parallel fort.

Bei synchroner Nachricht (Aufruf):

• Sender schickt Nachricht an Empfanger und gibt die Kontrolle uber den weiteren Prozess an den Empfanger

• Empfanger gibt nach Bearbeitung der Nachricht die Kontrolle an den Sender zuruck

• Interaktionen des Empfangers, die nach Erhalt der Nachricht begonnen wurden, mussen beendet sein, bevor derEmpfanger die Kontrolle an den Sender zuruckgibt (nested flow of control, method-call).

Anmerkung: Die Notation hat sich hier ab UML 2.0 geandert.


UML-Kommunikationsdiagramme (OMG)



20

09

-02

-09

Software-Projekt





• 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 exemplarischeInteraktionsszenarien eines Systems aus dynamischer Sicht

Klassendiagramme beschreiben diese Systeme aus statischer,schematischer Sicht

Interaktionsdiagramme dienen als Ausgangspunkt zur Erganzung undUberprufung von Klassendiagrammen



Interaktionen → Methoden



Interaktionen versus Methoden

Interaktionen

beschreiben das Wechselspiel zwischen Akteuren uberBotschaften/Methoden10

liefern Methoden fur die modellierten Klassen

beschreiben jedoch nicht die Methoden selbst

10Methoden beschreiben hier abstraktes Verhalten im Kontext der Anforderungen;sind noch nicht notwendigerweise die Methoden im Sinne der Implementierung (fuhrenletztlich aber zu diesen hin).



Methoden

Beschreibung:

Parameter: Eingabe und Ausgabe

Vorbedingung: beschreibt die Annahmen der Methode, die geltenmussen, damit sie ausgefuhrt werden kann

Nachbedingung: beschreibt das Resultat der Methode

Fehlerbedingungen: Verletzung der Vorbedingungen und Fehler, diewahrend der Ausfuhrung auftreten konnen

Verhalten in Fehlersituationen: Nachbedingung fur jedenaufgetretenen Fehler

Reaktionszeit: Maximale Dauer, bis Resultat vorliegt (sowohl imNormal- als auch im Fehlerfall)



Methoden

Beispiel Sortierung und Ausgabe der Artikelliste:

Parameter:Eingabe: Artikelliste, AttributAusgabe: 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 erfullt

Verhalten in Fehlersituationen:Artikelliste wird zuruckgegebenFehlermeldung wird ausgegeben

Reaktionszeit: n · log(n) · 0, 001 [sec], wobei n die Lange der Liste ist



Beschreibung der Benutzeroberflache

1

2

47 Euro

78 Euro

100 Euro

145 Euro3

4

5

6

1 Grafik des Artikels in der Große40x40 Pixel

2 Artikeldaten (10pt-Schrift)

3 Attribut, nach dem sortiertwurde (rot, 12pt-Schrift)

4 Scrolling nach oben; es wirdimmer um einen Artikel nachoben geschoben

5 Scrolling nach unten; es wirdimmer um einen Artikel nachunten geschoben

6 Auswahl des Artikels; alternativkann man mit dem Stift durchrasches doppeltes Anklickeneinen Artikel auswahlen



Zusammenhang von Benutzernachrichten und GUI

Nachrichten an Benutzer: Anzeige in GUINachrichten vom Benutzer: Aktionen des Benutzers mit GUI (Texteingabe,Mausklicks etc.)

1 2 1 2

8747 Euro

78 Euro

100 Euro

145 Euro 145 Euro

5 64 4 5 6

neinja



beschaffe (artikel-nr)Einfachklick auf Auswahl.1Einfachklick auf Kaufen.7

ermittle (artikel-typ). . .

ende. . .



Aktivitatsdiagramme

Wurzeln: Flussdiagramme, Petrinetze

modellieren klassenubergreifendes Verhalten (Kontrollfluss)

beschreiben haufig Anwendungsfalle

Einsatz empfohlen bei hauptsachlich intern ausgelostenZustandsubergangen (einfacher Kontrollfluss)


Aktivitatsdiagramme

Wurzeln: Flussdiagramme, Petrinetze

modellieren klassenubergreifendes Verhalten (Kontrollfluss)

beschreiben haufig Anwendungsfalle

Einsatz empfohlen bei hauptsachlich intern ausgelostenZustandsubergangen (einfacher Kontrollfluss)

20

09

-02

-09

Software-Projekt


Aktivitatsdiagramme

Aktivitatsdiagramme

Laut UML-Standard 1.x ist ein Aktivitatsdiagramm der”Zustandsautomat einer Berechnung“. Ab UML 2.0 wird es

auf Token-Konzept von Petri-Netzen zuruck gefuhrt.

Eine gute Darstellung findet man unter: http://informatik.unibas.ch/lehre/hs07/cs203/se5full.pdf

http://informatik.unibas.ch/lehre/hs07/cs203/se5full.pdf



20

09

-02

-09

Software-Projekt


Aktivitatsdiagramme

Aktivitatsdiagramme: Bestandteile

• Aktionszustande: Zustande mit nur einer Eingangsaktion und ohne interne Transitionen

• Aufrufzustande: Aufruf einer Operation

• Subaktivitatszustande: Zustande mit internen Aktivitatsdiagrammen

• Entscheidungen (”

if−then−else“)

• Aktions-/Objekts-Flussbeziehungen

• Schwimmbahnen: unterteilen Zustandigkeiten fur auszufuhrende Aktionen

• Kontroll-Icons fur Signale


Nebenlaufigkeit in Aktivitatsdiagrammen: Signale

Kaffee einschenken

Machineanschalten

Leuchte aus

an

braue Kaffee

Kaffeetasse

Kontroll-Icons deuten Richtung des Signals anRainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 245 / 634


UML-Zustandsautomatendiagramme

modellieren Objektlebenszyklus: Verhalten eines Objekts in Bezug aufdie verfugbaren Operationen seiner Klasse

gehen zuruck auf Zustandsautomaten nach Harel (1987)

Zustand: Menge von Attributwerten eines Objekts

Transition: Zustandsanderung

geeignet auch zur Beschreibung von Anwendungsfallen undProtokollen

erlauben Verschachtelung von Zustanden und Automaten



Zustandsautomatendiagramme: Beispiel

Busy

do/ play busy tonebusy

Invalid

do/ play message

dial digit(n)

[invalid]

Timeout

do/ play message

after (15 sec.) after (15 sec.)

caller hangs up

/disconnect

callee

hangs up

callee

answers

Pinned

Talking

/enable speech

callee answers

Ringing

do/ play ringing tone

connected

Connecting

dial digit(n)

[valid]

[incomplete]

dial digit(n)

Dialingdial digit(n)DialTone

do/ play dial tone

lift receiver

/get dial tone

Idle



lift receiver

/get dial tone

Active

Busy


Invalid

do/ play message

dial digit(n)

[invalid]

Timeout

do/ play message


caller hangs up

/disconnect

callee

hangs up

callee

answers

Pinned

Talking

/enable speech

callee answers

Ringing


connected

Connecting

dial digit(n)

[valid]

[incomplete]

dial digit(n)


do/ play dial tone

Idle

Zustande

einfach/zusammengesetzt

”interne“ Aktionen: entry, exit , do, include , frei definierbare Events


lift receiver

/get dial tone

Active

Busy


Invalid

do/ play message

dial digit(n)

[invalid]

Timeout

do/ play message


caller hangs up

/disconnect

callee

hangs up

callee

answers

Pinned

Talking

/enable speech

callee answers

Ringing


connected

Connecting

dial digit(n)

[valid]

[incomplete]

dial digit(n)


do/ play dial tone

Idle

Zustande

einfach/zusammengesetzt

”interne“ Aktionen: entry, exit , do, include , frei definierbare Events

20

09

-02

-09

Software-Projekt


Zustandsautomatendiagramme

• do/ activity : Aktivitat, die im Zustand ausgefuhrt wird

• entry/ action : bei Eintritt ausgefuhrte Aktivitat

• exit/ action : bei Austritt ausgefuhrte Aktivitat

• include/ : Zustandsmaschine wird importiert

• ereignisabhangig: Event [Condition] / ActionˆSend Event


lift receiver

/get dial tone

Active

Busy


Invalid

do/ play message

dial digit(n)

[invalid]

Timeout

do/ play message


caller hangs up

/disconnect

callee

hangs up

callee

answers

Pinned

Talking

/enable speech

callee answers

Ringing


connected

Connecting

dial digit(n)

[valid]

[incomplete]

dial digit(n)


do/ play dial tone

Idle

Transitionen

Ausloser: Ereignis, Bedingung, Zeit

Auswirkung: Aktion (z.B. Methodenaufruf), Zustandsanderung



Nebenlaufigkeit

mehrere nebenlaufige Regionen

Parallelitat durch Gabelung/Join (bedingungsfrei!)



Synchronisation nebenlaufiger Regionen

”Pseudozustande“ zur Synchronisation



Auswahl (Choice)

n-fache Verzweigung des Kontrollflusses gesteuert von einer logischenBedingung

dynamische bedingungsabhangige Verzweigung: Guards an denausgehenden Transitionen werden ausgewertet, nachdem die Aktionan der eingehenden Transition ausgefuhrt wurde.


Auswahl (Choice)

n-fache Verzweigung des Kontrollflusses gesteuert von einer logischenBedingung

dynamische bedingungsabhangige Verzweigung: Guards an denausgehenden Transitionen werden ausgewertet, nachdem die Aktionan der eingehenden Transition ausgefuhrt wurde.

20

09

-02

-09

Software-Projekt


Zustandsautomatendiagramme

Auswahl (Choice)

Dynamische Auswertung der Bedingungen der ausgehenden Transitionen


Mehrfachkreuzung (Junction)

State2

State0 State1

State3 State4

e1[b>0] e1[b>0]/ a:=a+1 / a:=a+2[a<0]

[a=0] [a>0]

Kombination aus mehrfacher Fallunterscheidung und mehrfacherVerzweigung

Vereinigung mehrerer Transitionen

Verschmelzung eingehender Transitionen und/oder

Erzeugung einer statischen bedingungsabhangigen Verzweigung:Guards an den ausgehenden Transitionen werden ausgewertet, bevordie Aktion an der eingehenden Transition ausgefuhrt wird.



Anwendung von Zustandsdiagrammen

Beschreibung von Objektlebenszyklen pro Klasse

Beschreibung von Protokollen

Verfeinerung von Anwendungsfallen




Was ist ein Modell? Wann und wozu modellieren wir?

Welches sind die wesentlichen Schritte der objektorientiertenModellierung im Kontext der Anforderungsspezifikation?

Was ist ein Anwendungsfall? Wie konnen Sie Anwendungsfallebeschrieben?

Was ist ein Aktor?

Welche Beziehungen zwischen Anwendungsfallen unterstutzt dieUML?

Was ist der Unterschied zwischen Objekt- und Klassendiagrammen?

Erlautern Sie Klassendiagramme fur die Datenmodellierung.

Was ist eine Generalisierung?

Worin besteht das Liskovsche Substitutionsprinzip?

Wie lassen sich attributierte Assoziationen und n-stelligeAssoziationen mit n > 2 darstellen?




Was ist eine Aggregation bzw. eine Komposition?

Wie wird ein Anwendungsfall textuell beschrieben?

Erlautern Sie Interaktionsdiagramme (Sequenzdiagramme undKommunikationsdiagramme).

Erstellen Sie ein Sequenzdiagramm fur ein bestimmtes Szenario.

Uberfuhren Sie dieses Sequenzdiagramm in einKommunikationsdiagramm.

Wie lassen sich Methoden aus den Interaktionsdiagrammen ableiten?

Wie sind Methoden zu beschreiben?

Erlautern Sie Aktivitatsdiagramme der UML. Erstellen Sie einAktivitatsdiagramm fur ein bestimmtes Szenario.

Erlautern Sie Zustandsautomatendiagramme der UML. Erstellen Sieein Zustandsautomatendiagramm fur ein bestimmtes Szenario.

Wofur konnen die genannten Diagrammarten benutzt werden?



Weiterfuhrende Literatur/Links

Buchtipp: Storrle (2005)

Ein kurzes Tutorial in Deutsch:http://ivs.cs.uni-magdeburg.de/~dumke/UML/

Eine sehr kurze Ubersicht in Englisch:http://bdn.borland.com/article/0,1410,31863,00.html

Weitere ausfuhrlichere Tutorials in Englisch:http://pigseye.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/http://uml.tutorials.trireme.com/


http://ivs.cs.uni-magdeburg.de/~dumke/UML/

http://bdn.borland.com/article/0,1410,31863,00.html

http://pigseye.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/

http://pigseye.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/

http://uml.tutorials.trireme.com/

Prufung der Anforderungsspezifikation






WiederholungsfragenLernzieleModellbildungObjektorientierte ModellierungGeschaftsprozesseAnwendungsfalleUML-Notation fur AnwendungsfalleStatische Eigenschaften: KlassendiagrammeVerhaltenseigenschaftenInteraktionsdiagrammeSequenzdiagrammeKommunikationsdiagrammeAktivitatsdiagrammeZustandsautomatendiagrammeWiederholungsfragen

6 ReviewsMotivationLernzieleSoftware-PrufungenReviewsAblauf von ReviewsReview-RegelnReview-ChecklistenReview-VariantenFallen und GegenmittelWiederholungsfragenMotivationLernzieleErgonomiePsychologische und kognitive GrundlagenKommandosprachen versus GUIGeschichte graphischer BenutzungsschnittstellenInteraktionsmechanismenSoftware-ergonomische RichtlinienUsability messen und verbessernZusammenfassungWiederholungsfragenWas ist Software-Architektur?EinflussfaktorenArchitektursichten und -blickwinkelKonzeptioneller BlickwinkelModulblickwinkelAusfuhrungsblickwinkelCode-SichtModularisierungSchnittstellenKopplung und ZusammenhaltQualitatenBewertung von ArchitekturenWiederholungsfragenWas ist ein Entwurfsmuster?Bestandteile eines EntwurfsmustersKategorien von EntwurfsmusternEntwurfsmuster Factory MethodEntwurfsmuster ObserverArchitekturstileArchitekturstil SchichtungArchitekturstil Model-View-ControllerWiederholungsfragenBegriffe des TestensSoziologie des TestensTestaktivitatenTestfallTeststumpfe und -treiberKomponententestsAquivalenztestKomponententest mit JUnitGrenztestPfadtestMaße der TestabdeckungZustandsbasiertes TestenIntegrationstestLeistungstestsZusammenfassung der TestartenTestmanagementTestplanTestfallspezifikationTestschadensberichtWiederholungsfragenMotivationArchitekturkonformitatProgrammierrichtlinienAnhangWiederholungsfragenLernzieleWas ist Benutzerdokumentation?Arten der DokumentationStrukturAuf Papier oder elektronisch?AutorWie schreibt man eine Dokumentation?Hinweise und RegelnWiederholungsfragenObjektorientierte ModellierungSoftwarearchitekturEntwurfsmuster und ArchitekturstileSoftwaretechnik im Allgemeinen



Motivation

Entwurf


analyseAnforderung−

Entwicklung = Sequenz von Aktivitaten mitZwischenprodukten (Anforderungsspezifikation,Entwurf, Code, Testfalle etc.)

Qualitat der Zwischenprodukte bestimmtwesentlich Qualitat der von ihnen abhangigenAktivitaten

→ die Qualitat der Zwischenprodukte muss gesichert werden

→ wir mussen sicher stellen, dass alle Beteiligten sich uber dasZwischenprodukt einig sind

Quellcode kann durch Tests uberpruft werden

aber was machen wir mit nicht direkt ausfuhrbaren Dokumenten wieAnforderungsspezifikation und Entwurf?



Lernziele

Im Allgemeinen:

Uberblick uber Software-Prufungen haben

Reviews beliebiger Dokumente durchfuhren konnen

Im Speziellen:

Bedeutung der Prufung fur die Anforderungsspezifikation kennen

Anforderungsspezifikation prufen konnen



Arten der Prufungen

Validierung: Are we doing the right thing?

Prufung, ob das, was entwickelt wird, gewunscht ist.

Verifikation: Are we doing the thing right?

Prufung, ob der Entwicklungsschritt X richtig durchgefuhrt wurde.


Arten der Prufungen

Validierung: Are we doing the right thing?

Prufung, ob das, was entwickelt wird, gewunscht ist.

Verifikation: Are we doing the thing right?

Prufung, ob der Entwicklungsschritt X richtig durchgefuhrt wurde.

20

09

-02

-09

Software-Projekt

Reviews

Software-Prufungen

Arten der Prufungen

Zur Qualitatssicherung gehoren Prufungen; eine Prufung in der Entwicklung kann grundsatzlich nach zweiPrinzipien erfolgen.Vergleich mit einer Fahrt auf der Basis einer Wegbeschreibung:

A: Haben wir das vorgesehene Ziel erreicht?

B: Sind wir, wie es die Beschreibung verlangt, an der richtigen Stelle auf die richtige Straße abgebogen?

Offenbar sind beide Prufungen sinnvoll: (A) ergibt die wichtigere Aussage, lasst sich aber nur anwenden, wenn dasEndziel oder ein definiertes Zwischenziel erreicht wurde. (B) lasst sich nach jedem Schritt anwenden.Man beachte aber, dass die Worter Validierung und Verifikation auch anders gebraucht werden, namlich

• Validierung als Oberbegriff fur alle Prufungen,

• Verifikation speziell fur Prufungen formaler Art (Programmbeweis und ahnliches).

Zur Vermeidung von Missverstandnissen spricht man dann von externer und interner Validierung (entsprechend Aund B) bzw. von formaler Verifikation.


Software-Prufung

TestsProgramm−analysen

ReviewsInspektionen

nicht−mechanisch(durch Menschen)

mechanisch(durch den Rechner)

Software−Prüfung

statisch dynamisch


Software-Prufung

TestsProgramm−analysen

ReviewsInspektionen

nicht−mechanisch(durch Menschen)

mechanisch(durch den Rechner)

Software−Prüfung

statisch dynamisch

20

09

-02

-09

Software-Projekt

Reviews

Software-Prufungen

Software-Prufung

Am popularsten ist der Test; aber man kann mit dem Rechner auch statisch prufen. Fast immer kann man aberinspizieren.


. . . ist prufbar durchdas Dokument . . . Inspektion TestLastenheft XPflichtenheft XSystementwurf XDefinition der Daten und Algorithmen XBenutzerhandbuch XTestdaten XCode X XAnleitungen etc. X


. . . ist prufbar durchdas Dokument . . . Inspektion TestLastenheft XPflichtenheft XSystementwurf XDefinition der Daten und Algorithmen XBenutzerhandbuch XTestdaten XCode X XAnleitungen etc. X

20

09

-02

-09

Software-Projekt

Reviews

Software-Prufungen

Naturgemaß lassen sich mechanische Prufungen nur dann anwenden, wenn die zu prufenden Informationen einermechanischen Analyse zuganglich sind. Darum kommt in der Software-Entwicklung als Prufverfahren ganzuberwiegend die Inspektion in Frage.


Reviews (Fruhauf u. a. 2000)

Prinzip

Eine Software-Einheit wird (dezentral) von mehreren Gutachterninspiziert;

in einer gemeinsamen Sitzung werden die Mangel zusammengetragenund dokumentiert.

Ziel

Fehler zu finden,

nicht, die Fehler auch zu beheben.

Fehlerbehebung ist ein separater Arbeitsschritt, den der Entwickler imAllgemeinen wieder ohne Mitwirkung Dritter durchfuhrt.



Prinzip

Eine Software-Einheit wird (dezentral) von mehreren Gutachterninspiziert;

in einer gemeinsamen Sitzung werden die Mangel zusammengetragenund dokumentiert.

Ziel

Fehler zu finden,

nicht, die Fehler auch zu beheben.

Fehlerbehebung ist ein separater Arbeitsschritt, den der Entwickler imAllgemeinen wieder ohne Mitwirkung Dritter durchfuhrt.2

00

9-0

2-0

9

Software-Projekt

Reviews

Reviews


Nachfolgend wird das technische Review beschrieben. In der Praxis gibt es zahlreiche Varianten. Zwischen diesenFormen gibt es keine simple Qualitatsordnung! Das heißt, wir wissen nicht, welche davon effektiver und effizienterist in der Fehlersuche.



Prufling

kann jeder in sich abgeschlossene, fur Menschen lesbare Teil vonSoftware sein

Beispiele: ein einzelnes Dokument, ein Codemodul, ein Testfall

Voraussetzung:

Referenzunterlagen benotigt, die eine Beurteilung erlauben

dazu gehoren eine Vorgabe oder Spezifikation sowie die relevantenRichtlinien

zusatzlich konnen Fragenkataloge (Checklisten) verwendet werden




Rollen

Moderator leitet das Review, ist also fur den ordnungsgemaßenAblauf verantwortlich.

Sekretar fuhrt das Protokoll.

Gutachter sind Experten (z.B. Kollegen), die den Prufling beurteilenkonnen.

Autor ist der Urheber des Pruflings oder ein Reprasentant des Teams,das den Prufling erstellt hat.



Review-Prozess

Vorbereitung

Nacharbeit

Analyse

Sitzung

Freigabe

Planung

1−2 Wvorher

2 h

1−2 W

[akzeptabel][nicht akzeptabel]



Review

Gutachter: andere Entwickler, Benutzer, Auftraggeber, Produkt-Manager,Tester, Architekten, Handbuchautoren, Wartungspersonal.

Aufgaben:

Vorbereitung: Prufling lesen und nach bestimmten, ihnen individuellzugeteilten Gesichtspunkten prufen.

Sitzung: gefundene Probleme vorbringen; Befund gemeinsam erheben,gewichten und protokollieren

begutachtennicht korrigieren

Nacharbeit: Autor korrigiert nach Auflagen der Gutachter

eventuell weitere Iteration mit Gutachtern


Review

Gutachter: andere Entwickler, Benutzer, Auftraggeber, Produkt-Manager,Tester, Architekten, Handbuchautoren, Wartungspersonal.

Aufgaben:

Vorbereitung: Prufling lesen und nach bestimmten, ihnen individuellzugeteilten Gesichtspunkten prufen.

Sitzung: gefundene Probleme vorbringen; Befund gemeinsam erheben,gewichten und protokollieren

begutachtennicht korrigieren

Nacharbeit: Autor korrigiert nach Auflagen der Gutachter

eventuell weitere Iteration mit Gutachtern20

09

-02

-09

Software-Projekt

Reviews

Ablauf von Reviews

Review

Beim technischen Review werden Kollegen als Gutachter beigezogen. Dafur kommen vor allem andere Entwickler inFrage, aber auch Benutzer, Produkt-Manager oder Auftraggeber. Die Gutachter erhalten im technischen Reviewkonkrete Auftrage:

• Im ersten Schritt des Reviews, in der Vorbereitung, mussen die Gutachter das zu prufende Dokument lesen und nachbestimmten, ihnen individuell zugeteilten Gesichtspunkten prufen.

• Den zweiten Schritt bildet die Review-Sitzung, in der die Gutachter ihre in der Vorbereitung gefundenen Problemevorbringen. Gemeinsam erheben, gewichten und protokollieren sie die Befunde. Der Auftrag fur die Review-Sitzunglautet also, das Dokument oder Programm zu begutachten und nicht zu korrigieren, d.h. die Sitzung hat das Ziel,Probleme aufzuzeigen, nicht sie zu losen.

• Die Nacharbeit selbst wird dem Autor oder den Autoren zugeteilt. Die Gutachter kommen bei der Uberprufung derNacharbeit evtl. nochmals zum Zug.


Review-Regeln

Review-Sitzung ist auf 2h beschrankt.

Falls notig wird eine weitere Sitzung, fruhestens am nachsten Tag,einberufen.

Der Moderator kann die Sitzung absagen oder abbrechen. Grund desAbbruchs ist zu protokollieren.

z.B. weil Gutachter nicht erscheinen oder ungenugend vorbereitet sind

Moderator ist nicht zugleich Gutachter.

Jeder Gutachter bekommt Gelegenheit, seine Befunde angemessen zuprasentieren.

Der Prufling – nicht der Autor – steht zur Diskussion. Das heißt:

Gutachter mussen 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 Vorschlage, wie Mangel zu behebensind;Befunde werden nicht in der Form von Anweisungen an den Autorprotokolliert.

Der Konsens der Gutachter zu einem Befund wird laufendprotokolliert. Die einzelnen Befunde werden gewichtet als

kritischer Fehler (Prufling fur den vorgesehenen Zweck unbrauchbar,Fehler muss vor der Freigabe behoben werden)Hauptfehler (Nutzbarkeit des Pruflings beeintrachtigt, Fehler sollte vorder Freigabe behoben werden),Nebenfehler (beeintrachtigen den Nutzen kaum),gut (fehlerfrei, bei Uberarbeitung nicht andern)



Review-Regeln III

Review-Team gibt Empfehlung uber die Annahme des Pruflings:

akzeptieren ohne Anderungenakzeptieren mit Anderungen (kein weiteres Review)nicht akzeptieren (weiteres Review erforderlich)

Alle Sitzungsteilnehmer unterschreiben das Protokoll



Checklisten: Fragenkatalog fur ein Anforderungsdokument

Prufen Sie bitte das Dokument als Vorbereitung zur Sitzung gemaß denIhnen in Punkt D der Einladung zugeteilten Aspekten aus der folgendenListe.

Aspekt Form: Ist die Darstellung im Dokument sinnvoll?a1 Sind Anforderungen als solche erkennbar, d.h. von Erklarungen

unterscheidbar?a2 Sind alle Anforderungen eindeutig referenzierbar?a3 Ist die Spezifikation jeder Anforderung eindeutig?a4 Sind alle Anforderungen uberprufbar formuliert?

Aspekt Schnittstellen: Sind alle Schnittstellen eindeutig spezifiziert?b1 Sind alle Objekte der Umgebung (Benutzer, andere Systeme,

Basis-Software etc.) sowie alle Informationsflusse von und nach diesenObjekten spezifiziert?

b2 Sind alle Benutzerklassen (Dauerbenutzer, gelegentliche Benutzer,System-Administrator, etc.) des Systems identifiziert?

b3 . . .b7 Sind Vorgaben gemacht bezuglich Verwendung von

Betriebssystem-Funktionen, Bibliotheken und Hilfsprogrammen?



Checklisten: Fragenkatalog fur ein Anforderungsdokument

(Fortsetzung)

Aspekt Vertraulichkeit: Sind die wesentlichen Aspekte desDatenschutzes berucksichtigt?

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 geschutzt werden muss?

. . .



Varianten des Software-Reviews

Design and Code Inspection (nach Fagan)

mit Einfuhrungssitzung, Gutachter-Notizen, die abgegeben werden,Vorleser, Entscheidungskompetenz, Metriken-Erhebung.

Schreibtischtest (besser: die Selbstkontrolle)

fuhrt jeder Entwickler allein durch (vgl. Humphreys PSP);ersetzt die eigentliche Prufung nicht.

Stellungnahme

ist ein”off-line“–Review unter der Regie des Autors;

den Vorteilen (geringer Organisationsaufwand) stehen erheblicheNachteile gegenuber (Prufling nicht vor Weiterbearbeitung geschutzt,Qualitat der Prufung und Umsetzung der Resultate nicht kontrolliert).

Structured Walkthrough

ist die Billig-Variante des Reviews: Autor ist Moderator;er kompensiert durch seine Prasentation die Einsparung (oderReduktion) der Vorbereitung;wahrend seiner Vorbereitung entdeckt er selbst viele Fehler.




Perspektivisches ReviewPrinzip:

Prufling wird von Gutachtern mit unterschiedlichem Interesse gepruftGutachter haben konkreten Auftrag: Prufling (hypothetisch) benutzen

Beispiel:

Tester → Testfalle entwickelnBenutzer → System benutzenHandbuchautor → Handbuch schreibenArchitekt → 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 Votta1998; Sandahl u. a. 1998):

Reviews, die auf Checklisten basieren, sind effektiver alsAd-Hoc-Reviews;

perspektivische Reviews sind effektiver und effizienter als Reviews, dieauf Checklisten basieren:

mehr Fehler/Mangel gefundenmehr Fehler/Mangel in gleicher Zeiteinheit gefunden



Woran scheitern Reviews? Fallen und Gegenmittel

Probleme bei der Ein-/Durchfuhrung von Reviews:

Es fehlen gute Moderatoren

→ Leute aussuchen und ausbilden

Es fehlen Bezugsdokumente

→ suchen, anpassen, bereitstellen

Entwickler haben Angst

→ erste Reviews grundlich vorbereiten (und auf die Angste eingehen,selbst wenn sie geleugnet werden)

Reviews beißen sich an Außerlichkeiten fest

→ Bedeutung der Außerlichkeiten klarstellen, aber dann weitergehen;→ beim zweiten Review sicherstellen, dass die Außerlichkeiten in Ordnung

sind.

Bezugsdokumente sind ungeeignet

→ diskutieren und verbessern



Woran scheitern Reviews? Fallen und Gegenmittel II

Zeitdruck sabotiert Prufungen

→ klare Entscheidungen uber die Prioritaten treffen

Geprufte Dokumente werden verandert

→ Konfigurationsmanagement verbessern

Interesse an Reviews kuhlt sich ab (,,Jetzt ist doch eigentlich alles inOrdnung!”)

→ Statistiken fuhren, Erfolg nachweisen



Wiederholungsfragen

Was ist der Unterschied zwischen Verifikation und Validierung?

Welche Arten der Software-Prufung gibt es?

Was ist ein Review? Welche Rollen sieht es vor? Wie wird esdurchgefuhrt?

Welche Review-Varianten gibt es?

Worauf ist bei Reviews zu achten?



Weiterfuhrende Literatur

Fruhauf u. a. (2000) fuhren in Software-Prufung ein.

Shull u. a. (2000) zeigen in ihren empirischen Untersuchungen, dassperspektivische Reviews effektiver sein konnen als Reviews, die nurauf allgemeinen Check-Listen basieren


Entwurf von Benutzungsschnittstellen






WiederholungsfragenLernzieleModellbildungObjektorientierte ModellierungGeschaftsprozesseAnwendungsfalleUML-Notation fur AnwendungsfalleStatische Eigenschaften: KlassendiagrammeVerhaltenseigenschaftenInteraktionsdiagrammeSequenzdiagrammeKommunikationsdiagrammeAktivitatsdiagrammeZustandsautomatendiagrammeWiederholungsfragenMotivationLernzieleSoftware-PrufungenReviewsAblauf von ReviewsReview-RegelnReview-ChecklistenReview-VariantenFallen und GegenmittelWiederholungsfragen

7 Entwurf von BenutzungsschnittstellenMotivationLernzieleErgonomiePsychologische und kognitive GrundlagenKommandosprachen versus GUIGeschichte graphischer BenutzungsschnittstellenInteraktionsmechanismenSoftware-ergonomische RichtlinienUsability messen und verbessernZusammenfassungWiederholungsfragenWas ist Software-Architektur?EinflussfaktorenArchitektursichten und -blickwinkelKonzeptioneller BlickwinkelModulblickwinkelAusfuhrungsblickwinkelCode-SichtModularisierungSchnittstellenKopplung und ZusammenhaltQualitatenBewertung von ArchitekturenWiederholungsfragenWas ist ein Entwurfsmuster?Bestandteile eines EntwurfsmustersKategorien von EntwurfsmusternEntwurfsmuster Factory MethodEntwurfsmuster ObserverArchitekturstileArchitekturstil SchichtungArchitekturstil Model-View-ControllerWiederholungsfragenBegriffe des TestensSoziologie des TestensTestaktivitatenTestfallTeststumpfe und -treiberKomponententestsAquivalenztestKomponententest mit JUnitGrenztestPfadtestMaße der TestabdeckungZustandsbasiertes TestenIntegrationstestLeistungstestsZusammenfassung der TestartenTestmanagementTestplanTestfallspezifikationTestschadensberichtWiederholungsfragenMotivationArchitekturkonformitatProgrammierrichtlinienAnhangWiederholungsfragenLernzieleWas ist Benutzerdokumentation?Arten der DokumentationStrukturAuf Papier oder elektronisch?AutorWie schreibt man eine Dokumentation?Hinweise und RegelnWiederholungsfragenObjektorientierte ModellierungSoftwarearchitekturEntwurfsmuster und ArchitekturstileSoftwaretechnik im Allgemeinen



Lernziele

Ergonomische Software erstellen konnen:

Bedienelemente graphischer Benutzungsschnittstellen kennen undeinsetzen konnen

Ergonomie bewerten konnen



Ergonomie

Definition

Ergonomie: (von ergon (Arbeit, Werk) und nomos (Gesetz, Regel)) ist dieWissenschaft der Arbeitsbedingungen und deren optimale Anpassung anden Anwender.

“Design for Use”

Anpassung von Maschinen, Computern und Systemen an menschliche(Denk- und Kommunikations-) Fahigkeiten und Bedurfnisse

zentral ist Schnittstelle zwischen Mensch und Maschine(Mensch-Computer-Interaktion)

Auswirkungen auf zum Beispiel: Arbeitsablaufe, Menu-Hierarchien,Kommandosprachen, Farb- und Schriftwahl und dieFunktionsaufteilung zwischen Mensch und Computer


Ergonomie

Definition

Ergonomie: (von ergon (Arbeit, Werk) und nomos (Gesetz, Regel)) ist dieWissenschaft der Arbeitsbedingungen und deren optimale Anpassung anden Anwender.

“Design for Use”

Anpassung von Maschinen, Computern und Systemen an menschliche(Denk- und Kommunikations-) Fahigkeiten und Bedurfnisse

zentral ist Schnittstelle zwischen Mensch und Maschine(Mensch-Computer-Interaktion)

Auswirkungen auf zum Beispiel: Arbeitsablaufe, Menu-Hierarchien,Kommandosprachen, Farb- und Schriftwahl und dieFunktionsaufteilung zwischen Mensch und Computer

20

09

-02

-09

Software-Projekt


Ergonomie

Ergonomie

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. Siebeschrankt sich ausdrucklich nicht - wie oft falschlich angenommen - auf die Behandlung der Prasentationsaspekteinteraktiver 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 einembestimmten Benutzer verwendet werden kann, um bestimmte Ziele ineinem bestimmten Kontext effektiv, effizient und zufriedenstellend zuerreichen. — Part 11: “Guidance on Usability” (ISO 9241-11:1998 1998)

ubersetzt als”Benutzerfreundlichkeit” oder

”Benutzbarkeit”

Verbesserung ist Ziel der (Software-)Ergonomie


Usability

Definition

Usability: eines Produktes ist das Ausmaß, in dem es von einembestimmten Benutzer verwendet werden kann, um bestimmte Ziele ineinem bestimmten Kontext effektiv, effizient und zufriedenstellend zuerreichen. — Part 11: “Guidance on Usability” (ISO 9241-11:1998 1998)

ubersetzt als”Benutzerfreundlichkeit” oder

”Benutzbarkeit”

Verbesserung ist Ziel der (Software-)Ergonomie

20

09

-02

-09

Software-Projekt


Ergonomie

Usability

Wird auch als”Ein Maß fur die Qualitat, mit der ein Benutzer die Interaktion mit einer Maschine erlebt.“ definiert.


Psychologische und kognitive Grundlagen

Kurzzeitgedachtnis

Information strukturieren und begrenzen: 7± 2

menschliche Gestaltwahrnehmung

→ bei Prasentation beachtenz.B. Superzeichenbildung: 0 4 2 1 2 1 8 2 4 2 1 versus 0421/218-2421

geteilte Aufmerksamkeit

→ Fortsetzung nach Unterbrechung unterstutzen

begrenzte Konzentrationsfahigkeit

→ nicht uberfordern, Sicherheiten einbauen

Unerfahrenheit verunsichert

→ Metaphern verwenden, z.B. Ikonen wie Mulleimer, Briefkasten→ explorative Untersuchung unterstutzen



Vergleich von GUI und Kommandosprachen

Kommandosprachen Graphical User Interface (GUI)komplexe Operationen einfache Operationen

intensive Nutzung, gelegentlicher Einsatz,Experten leichte Erlernbarkeit

funktionale Bedienung, ObjektorientierungBerechnungen



Wegweiser

Meilensteine in der Geschichte graphischerBenutzungsschnittstellen



Die ersten Ideen

Memex (Memory Extender) von Bush (1945)

Kompakt-Analog-Rechner zur Verwaltungverlinkter Informationen

beruhrungssensitive Bildschirme projizierenMikrofilme

Mikrofilme verknupft

Vor- und Zuruckblattern uber Hebel


Die ersten Ideen

Memex (Memory Extender) von Bush (1945)

Kompakt-Analog-Rechner zur Verwaltungverlinkter Informationen

beruhrungssensitive Bildschirme projizierenMikrofilme

Mikrofilme verknupft

Vor- und Zuruckblattern uber Hebel

20

09

-02

-09

Software-Projekt


Geschichte graphischer Benutzungsschnittstellen

Die ersten Ideen

Dank auch an Matthias Kirschner fur einige seiner Folien.


Semi Automatic Ground Environment

Bedienung durch Laien

Lichtgriffel (Light-Pen)



Sketchpad

von Ivan Sutherland (1963)

Objektorientierung stattBitmaps

Generische Operationen furverschiedene Objekte

Constraints zu den graphischenObjekten (z.B. Lange)

Copy & Paste



Computermaus

von Douglas Engelbart und Bill English (1963)

relative Positionsveranderung



Windows Icons Menus & Pointer

Fruhe Ideen: Xerox Palo Alto Research Center (1970)

Prinzipien:

abstrakte Datensicht, VisualisierungRaum und ObjekteMetaphorisierung: Schreibtisch (Desktop)“What you see is what you get” (Texteditor BRAVO, Vorlaufer vonMicrosoft Word)einheitliche Visualisierung und Interaktionwenige 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

Moglichkeiten graphischer Benutzungsschnittstellen



Direkte Manipulation

Direkte Manipulation:

Metaphern visualisiert in Form von Ikonen (Gegenstande)

physische Aktionen mittels Zeigegeraten

permanente visuelle Ruckkopplung

nutzt Intuition und Erfahrungen der Anwender in der metaphorisiertenWelt aus

Interaktionen:

Auswahl: “Point & Click”

Verschieben:

Unmittelbar: “Drag & Drop”Unterbrechbar: “Cut & Paste”

Vervielfaltigen: “Copy & Paste”



Ruckkopplung an Nutzer

Metaphern der physischenWelt, z.B. Raumlichkeit,→ Wiedererkennungswert

Verbergen von Irrelevantem,Information auf Abruf,Kontextsensitivitat

Fortschrittsanzeige,Aktivitatsanzeige



Fenster I

Fokus

Desktop, Hauptfenster

Handles, Scrollbars



Fenster II

Reiter, Split-Fenster

Layout Manager

Dialogfenster

modal: Dialog muss abgeschlossen werden, bevor nachster Dialogbeginntnicht-modal: Dialoge konnen ko-existieren



Menus und Schaltflachen I

”Pull-Down-Menu“

Paneele, Gruppen

Baumstruktur



Menus und Schaltflachen II

Kontextmenu

Schaltflache, Button

Toolbars



Textelemente

Mnemonics, Tooltips

Formularfelder

Listen, Tabellen



Ikone, Metaphern

Dateisymbole

Programmverknupfungen

Thumbnails



Manipulatoren und Attribute

Checkbox(Boolean)

Radio-Button(Alternativen)

Slider(Zahlenwerte)



Listen

Teilmenge,Permutation

statisch vs.erweiterbar

Combo-Box



Wegweiser

Eigenschaften guter graphischerBenutzungsschnittstellen



Qualitatskriterien (EN ISO 9241-10:1995 1995)

Definition

Aufgabenangemessenheit: Benutzer wird unterstutzt, Arbeitsaufgabeeffektiv und effizient zu erledigen

Dialoge sollten nur sachdienliche Informationen enthaltenVermeidung von Ablenkungen

weniger ist mehr (Funktionen)den Bildschirm nicht uberfullenvermeide es, Befehle redundant anzubietenkeine unnotigen Dialoge und Popups

Optimieren von haufigen Aufgabenkleine Anzahl von benotigten Schritten; Anzahl

”Klicks“ klein halten

große Knopfe fur Hauptbefehle, Tastaturkurzeldie haufigsten Funktionen auf dem ersten Bildschirmwichtige Befehle → hervorstehende Stelleweniger haufig benutzte Befehle → weniger hervorstehende Stelle(Untermenu, Einstellungsdialog)



Definition

Aufgabenangemessenheit: Benutzer wird unterstutzt, Arbeitsaufgabeeffektiv und effizient zu erledigen

Dialoge sollten nur sachdienliche Informationen enthaltenVermeidung von Ablenkungen

weniger ist mehr (Funktionen)den Bildschirm nicht uberfullenvermeide es, Befehle redundant anzubietenkeine unnotigen Dialoge und Popups

Optimieren von haufigen Aufgabenkleine Anzahl von benotigten Schritten; Anzahl

”Klicks“ klein halten

große Knopfe fur Hauptbefehle, Tastaturkurzeldie haufigsten Funktionen auf dem ersten Bildschirmwichtige Befehle → hervorstehende Stelleweniger haufig benutzte Befehle → weniger hervorstehende Stelle(Untermenu, Einstellungsdialog)

20

09

-02

-09

Software-Projekt


Software-ergonomische Richtlinien


Weitere Qualitatsaspekte

• Fehler verringern

• Sicherheit erhohen

• Zuverlassigkeit erhohen

• Lernanforderungen verringern

• Wartbarkeit verbessern

• Wirksamkeit erhohen

• Produktivitat erhohen

• Arbeitsumgebung verbessern

• Ermudung verringern

• Langeweile und Eintonigkeit verringern

• Zugang zur Anwendung erleichtern

• Akzeptanz verbessern

• Arbeitszufriedenheit steigern

• Tatigkeitserweiterung ermoglichen

• Lebensqualitat verbessern

• . . .



Definition

Selbstbeschreibungsfahigkeit: jeder einzelne Dialogschritt ist durchRuckmeldung unmittelbar verstandlich bzw. eine Erklarung ist auf Anfrageverfugbar

verstandliche Benennung von Feldern

Online-Hilfe

Erlauterung der Konsequenzen des nachsten Schritts




Definition

Erwartungskonformitat: Dialog ist konsistent und entspricht denMerkmalen des Benutzers (z.B. Kenntnisse aus dem Arbeitsgebiet,Ausbildung u. Erfahrung sowie allgemeinen Konventionen)

vorhersagbares Verhalten

passende Ruckmeldung in angemessener Zeit

Konsistenz von Benutzeraktionen, Prasentation, Anordnung vonElementen, Text




Definition

Steuerbarkeit: Benutzer ist in der Lage, den Dialogablauf zu starten sowieseine Richtung und Geschwindigkeit zu beeinflussen, bis Ziel erreicht ist

erlaube es dem Benutzer, jederzeit die Anwendung zu verlassen oderzur Startseite zuruckzukommen

benutze modale Formulare sparsam



Definition

Steuerbarkeit: Benutzer ist in der Lage, den Dialogablauf zu starten sowieseine Richtung und Geschwindigkeit zu beeinflussen, bis Ziel erreicht ist

erlaube es dem Benutzer, jederzeit die Anwendung zu verlassen oderzur Startseite zuruckzukommen

benutze modale Formulare sparsam

20

09

-02

-09

Software-Projekt


Software-ergonomische Richtlinien


Modaler Dialog: ein Dialog, der geschlossen werden muss, bevor weitere Aktionen anderer Dialoge durchgefuhrtwerden konnen. Beispiel: Datei-Offnen-Dialog.



Definition

Fehlertoleranz: Ziel kann trotz erkennbarer fehlerhafter Eingabe mitminimalem Korrekturaufwand durch den Benutzer erreicht werden

Hinweise sind sichtbar oder einfach erreichbar

aussagekraftige Fehlermeldungen mit Hinweisen

einfaches Wiederaufsetzen nach Fehlern, z.B. fehlerhafte Eingabe inTextfeld wird nicht einfach geloscht,

Fehler werden vor Eintreten verhindert




Definition

Individualisierbarkeit: Anpassungen an Erfordernisse der Arbeitsaufgabe,individuelle Vorlieben des Benutzers und Benutzerfahigkeiten sind moglich

Sprache ist einstellbar

Zeichensatze/-große sind einstellbar

Farben sind einstellbar

eigene Tastaturbefehle fur erfahrene Benutzer




Definition

Lernforderlichkeit: Benutzer wird beim Erlernen des Dialogsystemsunterstutzt 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 Qualitat akzeptabel



Parameter fur Bestimmung der Usability

Beispiel Textverarbeitung:

Ziel: Erstellen eines Textdokuments nach einer Papiervorlage

Aufgaben: Eingeben des TextesFormatierenEinfugen eines BildesRechtschreibung uberprufen. . .

Benutzer: wenig Vorkenntnisse uber Computerbenutzung imAllgemeinen und Textverarbeitung im Speziellen

Umgebung: Buroumgebung mit erheblichem Zeitdruck

Meßgroßen: Zeitaufwand, Unterschiede im Text (mit Gewichtung) undUnterschiede im Layout und Stil (auch mit Gewichtung)



Evaluationsverfahren

Wie kann man Usability messen?

objektiv versus subjektiv

Fakten versus Grunde



Subjektive Messungen

Benutzerbefragung (Fragebogen oder Interviews)

subjektivbreit anwendbar und statistisch auswertbarStandardfragebogen existieren (z.B. ErgoNorm, SUMI, QUIS, PUTQ)

Experten-Reviews

Checklisten fur NormkonformitatHeuristiken



Objektive Messungen

Evaluation eines Modells

direkte Beobachtung der Benutzer

Labor oder echte ArbeitsumgebungAufzeichnung: Video, Audio (Think-Aloud), Eye-Tracking

indirekte Beobachtung: Mitschnitte von Aktionen (z.B. Web-Logs)

breiter anwendbarviel Fakten, wenig Hinweise auf Grunde



A-Posteriori Messungen

Messungen nach Auslieferung im Einsatz:

Anzahl der Hotline-Anrufe

Verkaufsrate

siehe oben

Speziell furs Web:

Traffic / Netzaufkommen

Besucherzahl

Anteil der Besucher, die zum Kauf eines Produkts animiert werdenkonnten



Zusammenfassung

entwickle fur den Benutzer

entwickle mit dem Benutzer

Usability ist entscheidend fur den Erfolg des Produktes



Wiederholungsfragen

Wie kann Usability verbessert werden?

Wie lasst sich Usability messen?

Was sind die Qualitatskriterien von Benutzungsschnittstellen nach ENISO 9241-10:1995 (1995)? Erlautern Sie die Aspekte anhand eineskonkreten Szenarios.

Wie haben Sie diese konkret in Ihrem Projekt umgesetzt?


Software-Architektur






WiederholungsfragenLernzieleModellbildungObjektorientierte ModellierungGeschaftsprozesseAnwendungsfalleUML-Notation fur AnwendungsfalleStatische Eigenschaften: KlassendiagrammeVerhaltenseigenschaftenInteraktionsdiagrammeSequenzdiagrammeKommunikationsdiagrammeAktivitatsdiagrammeZustandsautomatendiagrammeWiederholungsfragenMotivationLernzieleSoftware-PrufungenReviewsAblauf von ReviewsReview-RegelnReview-ChecklistenReview-VariantenFallen und GegenmittelWiederholungsfragenMotivationLernzieleErgonomiePsychologische und kognitive GrundlagenKommandosprachen versus GUIGeschichte graphischer BenutzungsschnittstellenInteraktionsmechanismenSoftware-ergonomische RichtlinienUsability messen und verbessernZusammenfassungWiederholungsfragen

8 Software-ArchitekturWas ist Software-Architektur?EinflussfaktorenArchitektursichten und -blickwinkelKonzeptioneller BlickwinkelModulblickwinkelAusfuhrungsblickwinkelCode-SichtModularisierungSchnittstellenKopplung und ZusammenhaltQualitatenBewertung von ArchitekturenWiederholungsfragenWas ist ein Entwurfsmuster?Bestandteile eines EntwurfsmustersKategorien von EntwurfsmusternEntwurfsmuster Factory MethodEntwurfsmuster ObserverArchitekturstileArchitekturstil SchichtungArchitekturstil Model-View-ControllerWiederholungsfragenBegriffe des TestensSoziologie des TestensTestaktivitatenTestfallTeststumpfe und -treiberKomponententestsAquivalenztestKomponententest mit JUnitGrenztestPfadtestMaße der TestabdeckungZustandsbasiertes TestenIntegrationstestLeistungstestsZusammenfassung der TestartenTestmanagementTestplanTestfallspezifikationTestschadensberichtWiederholungsfragenMotivationArchitekturkonformitatProgrammierrichtlinienAnhangWiederholungsfragenLernzieleWas ist Benutzerdokumentation?Arten der DokumentationStrukturAuf Papier oder elektronisch?AutorWie schreibt man eine Dokumentation?Hinweise und RegelnWiederholungsfragenObjektorientierte ModellierungSoftwarearchitekturEntwurfsmuster und ArchitekturstileSoftwaretechnik im Allgemeinen



Lernziele

Verstehen, was Software-Architektur ist

Verschiedene Architektursichten kennen

Qualitaten einer Architektur kennen

Eine angemessene Software-Architektur entwerfen konnen

Die Anderbarkeit einer Software-Architektur bewerten konnen



Kontext

Implemen−tierung

Test

Wartung& Evolution

Architektur

Datenstrukturen

und Algorithmen

AnalyseEntwurf



Client-Server-Architektur: Dynamische Sicht

queries

queries

queries

: Shop Server

1 : PDA Client

2 : PDA Client

n : PDA Client



Client-Server-Architektur: Statische Sicht

PDA Client Shop Server

Network

send receive

<<call>> <<call>>

Stereotyp

Schnittstelle



Was ist Architektur?

Architecture is the human organization of empty space usingraw material.

Richard Hooker, 1996.

Definition

Software-Architektur ist die grundlegende Organisation eines Systemsverkorpert (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

Kommunikation zwischen allen Interessenten

hoher Abstraktionsgrad, der von vielen verstanden werden kann

Fruhe Entwurfsentscheidungen

→ nachhaltige Auswirkungen→ fruhzeitige Analyse

Transferierbare Abstraktion des Systems

→ eigenstandig wiederverwendbar→ unterstutzt Wiederverwendung im großen Stil (Software-Produktlinien)



Kommunikation zwischen allen Interessenten

hoher Abstraktionsgrad, der von vielen verstanden werden kann

Fruhe Entwurfsentscheidungen

→ nachhaltige Auswirkungen→ fruhzeitige Analyse

Transferierbare Abstraktion des Systems

→ eigenstandig wiederverwendbar→ unterstutzt Wiederverwendung im großen Stil (Software-Produktlinien)

20

09

-02

-09

Software-Projekt


Was ist Software-Architektur?


Die Softwarearchitektur reprasentiert hohe Abstraktion eines Systems, die von den meisten Interessentenverstanden werden kann und damit eine Grundlage zum gegenseitigen Verstandnis, zur Konsensbildung und zurKommunikation darstellt.Die Softwarearchitektur ist die Manifestation fruher Entwurfsentscheidungen; diese fruhe Fixierung kannnachhaltige Auswirkungen haben auf die nachfolgende Entwicklung, Auslieferung sowie Wartung und Evolution. SAist auch die fruheste Systembeschreibung, die analysiert werden kann.Die Softwarearchitektur konstitutiert ein relativ kleines intellektuell fassbares Modell daruber, wie das Systemstruktiert ist und wie seine Komponenten zusammenwirken; dieses Modell ist eigenstandig nutzbar und kann uberdas spezifische System hinaus transferiert werden; insbesondere kann es fur Systeme mit ahnlichen Eigenschaftenund Anforderungen wiederverwendet werden, um so Wiederverwendung im großen Stil zu unterstutzen (Stichwort:Software-Produktlinien).


Beispielsystem IS2000 (Hofmeister u. a. 2000)

User ControlPanel

Remote ImagingComputers

ImagingComputer

Probe

Network

IS2000

��

��

��

��



Einflussfaktoren/Anliegen (Concerns)

Einflussfaktoren

Produktfunktionen und -attribute

z.B. Performanz, Anspruche an Zuverlassigkeit, Umfang und Stabilitatder Anforderungen

Organisation

z.B. Budget, verfugbare Zeit, Team-Große und -erfahrung

Technologie

z.B. verfugbare Hard- und Software

Keiner der Faktoren kann isoliert behandelt werden → globale Analyse.



Einflussfaktoren

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

1. Identifiziere und beschreibe Faktoren2. Charaktersiere ihre Flexibilität und Änderbarkeit3. Analysiere ihre Auswirkungen

Analysiere Faktoren

Entwickle Strategien1. Identifiziere Probleme und Einflussfaktoren

3. Identifiziere verwandte Strategien2. Entwickle Lösungen und spezifische Strategien

Produktfaktoren

Organisatorische,undtechnologische Faktoren,

Einfluss

Rückkopplung

neue Problemeoder Strategien

Problem−karten

Faktortabelle neue Faktoren

BlickwinkelGlobale Analyse

neue Faktoren

AbschließendeEntwurfsaufgabe

Zentrale Entwurfs−aufgabe



Globale Analyse: Analysiere Faktoren

1. Identifiziere und beschreibe Faktoren

Faktoren, die viele Komponenten betreffen

Faktoren, die sich uber die Zeit andern

Faktoren, die schwer zu erfullen sind

Faktoren, mit denen man wenig Erfahrung hat

Beispiele:

Umfang funktionaler Anforderungen

Abgabetermin

Stabilitat der Hardware-Plattform




2.a Charakterisiere ihre Flexibilitat

Flexibilitat

Kann zu Beginn uber Faktoren verhandelt werden mit Beteiligten(Manager, Marketingleute, Kunde, Benutzer etc.)?

Relevante Fragen zur Flexibilitat (am Beispiel Auslieferung derFunktionalitat):

Kann der Faktor beeinflusst oder geandert werden, so dass derArchitekturentwurf vereinfacht werden kann?

Auslieferung der Funktionalitat ist verhandelbar. Weniger wichtigeFunktionalitat kann in spaterem 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 erfullt werden mussen.




2.b Charakterisiere ihre Veranderlichkeit

Veranderlichkeit

Kann sich der Faktor wahrend der Entwicklung andern?

Relevante Fragen (am Beispiel Auslieferung der Funktionalitat):

In welcher Weise kann sich der Faktor andern?Prioritaten konnten sich andern.Anforderungen konnten wegfallen, weil nicht mehr relevant.Anforderungen konnten hinzukommen, weil sich Rahmenbedingungengeandert haben.

Wie wahrscheinlich ist die Anderung wahrend und nach derEntwicklung?

Moderat wahrend der Entwicklung; sehr hoch danach.

Wie oft wird er sich andern?Alle 3 Monate.

Wird der Faktor betroffen von Anderungen anderer Faktoren?Anderung technologischer Aspekte (Software-/Hardware-Plattform).




3. Analysiere die Auswirkungen der Anderung von Faktoren auf Architektur

Auswirkungen

Wenn sich der Faktor andert, was wurde 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 mussen uberarbeitet werden;Komponenten konnen hinzu kommen oder wegfallen.

Operationsmodi des Systems

Andere Entwurfsentscheidungen

. . .



Faktortabelle zu organisatorischen Aspekten

Faktor Flexibilitat undVeranderlichkeit

Auswirkung

O1 : EntwicklungsplanO1.1 : Time-To-Market

AuslieferungJuli 2009

Keine Flexibilitat Nicht alle Funktionen konnenimplementiert werden

O1.2 : Auslieferung von Produktfunktionen

priorisierteFunktionen

Funktionen sind verhandelbar Die Reihenfolge bei derImplementierung derFunktionen kann sich andern

O2 : EnwicklungsbudgetO2.1 : Anzahl Entwickler

5 Entwick-ler

Keine neuen Entwicklerkonnen eingestellt werden.Entwickler konnen (temporar)ausfallen.

Moderater Einfluss aufZeitplan; partielleImplementierung droht



Weitere organisatorische Beispielfaktoren I

O1: Management

Selbst herstellen versus kaufen

Zeitplan versus Funktionsumfang

Umgebung

Geschaftsziele

O2: Personal: Fahigkeiten, Interessen, Starken, Schwachen

Anwendungsdomane

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


Auswirkung

T2 : Domanenspezifische HardwareT2.1 : Aufzeichungs-Hardware

Nimmt Signal auf. Neuere Versionen alle 3Jahre.

Großer Einfluss aufAufzeichnungs- undBildverarbeitungskom-ponenten

T2.2 : Netzwerk

Kommunikationzwischen Aufzeichnungund allgemeinerHardware

Neuere Versionen alle 4Jahre

Großer Einfluss aufAufzeichnungs- undBildverarbeitungskom-ponenten



Technische Beispielfaktoren I

T1: Hardware

Prozessoren

Netzwerk

Hauptspeicher

Plattenspeicher

domanenspezifische Hardware

T2: Software

Betriebssystem

Benutzerschnittstelle

Software-Komponenten

Implementierungssprache

Entwurfsmuster

Rahmenwerke



Technische Beispielfaktoren II

T3: Architekturtechnologie

Architekturstile/-muster und -rahmenwerke

Domanenspezifische 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 EigenschaftenP3.2 : Performanz der Aufzeichnung

Performanz: Große undAnzahl von Bildern;Antwortszeit:Ein-Ausgabe-Deadlines

Etwas flexibel. Große Auswirkung aufalle Komponenten furAufzeichnung,Bildverarbeitung,Speicherung undBetrachtung;Auswirkung variiert mitPerformanztuning.



Beispielproduktfaktoren I

P1: ProduktfunktionenP2: Benutzerschnittstelle

Interaktionsmodell

Funktionen der Benutzerschnittstelle

P3: Performanz

Ausfuhrungszeiten

Speicherbedarf

Dauer des Systemstarts und -endes

Wiederherstellungszeit nach Fehlern



Beispielproduktfaktoren II

P4: Verlasslichkeit

Verfugbarkeit

Zuverlassigkeit

Sicherheit

P5: Fehlererkennung, -bericht, -behandlung

Fehlerklassifikation

Fehlerprotokollierung

Diagnostik

Wiederherstellung



Beispielproduktfaktoren III

P6: Service

Service-Dienste (Konfigurations- und Wartungsdienste) fur denBetrieb des System

Installation und Aktualisierung

Test der Software

Wartung und Erweiterung der Systemimplementierung

P7: Produktkosten

Hardwarebudget

Softwarelizenzbudget (fur verwendete Software)



Globale Analyse: Entwickle Strategien I

1. Identifiziere Probleme und deren EinflussfaktorenAnalysiere Faktorentabelle:

Grenzen oder Einschrankungen durch Faktoren

Unverruckbarer Abgabetermin erlaubt keinen vollen Funktionsumfang

Notwendigkeit, Auswirkung eines Faktors zu begrenzen

Entwurf muss Portierbarkeit vorsehen

Schwierigkeit, einen Produktfaktor zu erfullen

Speicher- und Prozessorbegrenzung erlaubt keine beliebig komplexenAlgorithmen

Notwendigkeit einer allgemeinen Losung zu globalen Anforderungenwie Fehlerbehandlung und Wiederaufsetzen nach Fehlern



Globale Analyse: Entwickle Strategien II

2. Entwickle Losungen und spezifische Strategien. . . fur die Behandlung der Probleme, die sich implementieren lassen unddie notwendige Anderbarkeit unterstutzen.

Strategie muss konsistent sein zu:

Einflussfaktor,

dessen Veranderlichkeit

und dessen Interaktion mit anderen Faktoren.



Globale Analyse: Entwickle Strategien III

2. Entwickle Losungen und spezifische Strategien

Ziele:

Reduzierung oder Kapselung des Faktoreinflusses

Reduzierung der Auswirkung einer Anderung des Faktors auf denEntwurf und andere Faktoren

Reduzierung oder Kapselung notwendiger Bereiche vonExpertenwissen oder -fahigkeiten

Reduzierung der Gesamtentwicklungsdauer und -kosten

3. Identifiziere verwandte Strategien



Globale Analyse: Entwickle Strategien IV

Problemkarten (Issue Cards) beschreiben Problem und passende Strategieneinmalig:

Name des Problems

Beschreibung des ProblemsEinflussfaktorenListe aller Einflussfaktoren

LosungDiskussion einer allgemeinen LosungStrategie: Name der Strategie AErlauterung der Strategie AStrategie: Name der Strategie BErlauterung der Strategie B. . .

Verwandte StrategienReferenzen zu verwandten Strategien.Diskussion, in welcher Weise sie verwandt sind.



Beispiele

Ambitionierter Zeitplan

Abgabetermin ist fix, Ressourcen sind begrenzt. Moglicherweise konnennicht alle Produktfunktionen realisiert werden.EinflussfaktorenO1.1 : Time-To-MarketO1.2 : Auslieferung von ProduktfunktionenO2.1 : Anzahl Entwickler

Losung

Strategie: Schrittweiser AusbauSystem wird schrittweise ausgebaut. Anforderungen werden in der Rei-henfolge ihrer Prioritat realisiert.

Strategie: Einkaufen statt SelbstentwickelnEinbindung externer COTS-Komponenten.Strategie: WiederverwendungEinbindung interner wiederverwendbarer Komponenten.



Anderungen in allgemeiner und domanenspezifischer Hardware

Regelmaßige Anderungen der Hardware; Software soll mit minimalenAufwand an Anderungen angepasst werden konnen.

EinflussfaktorenT1.1: Prozessoren werden leistungsfahiger.T2.1: Aufzeichnungs-Hardware andert sich alle drei JahreT2.2: Netzwerktechnologie andert sich alle vier Jahre

Losung

Strategie: Kapselung domanenspezifischer Hardware:Kapsle Details, die sich andern konnen.

Strategie: Kapselung allgemeiner Hardware:Kapsle Details, die sich andern konnen.



Betriebssystemanpassung

Weiterentwicklung des Betriebssystems (BS) und Wechsel auf ein neuesBS machen Anpassungen an betriebssystemspezifischen Komponentennotwendig. Fur die Wartung steht nur ein Entwickler zur Verfugung. DieAnpassungen mussen schnell vorgenommen werden.

EinflussfaktorenO1.1: Time-To-MarketO2.1: Anzahl EntwicklerT2.3: Betriebssystem

Losung

Strategie: Kapselung der BS-abhangigen AnteileBS-abhangige Anteile werden in Komponenten isoliert. Diese bilden einevirtuelle Maschine fur alle anderen Komponenten.



Gebaudearchitektur


Gebaudearchitektur

20

09

-02

-09

Software-Projekt


Architektursichten und -blickwinkel

Gebaudearchitektur

In der Gebaudearchitektur ist es ublich, von einem zu bauenden Gebaude verschiedene Modelle zu erstellen, bevordas Gebaude tatsachlich gebaut wird. Teilweise werden die Modelle als Prototypen benutzt, um dem zukunftigenHausbesitzer einen Eindruck von der Asthetik oder Funktion zu vermitteln. Teilweise sind die Modelle Plane, wie esnachher tatsachlich werden soll. Es wird dabei stets eine Vielzahl unterschiedlicher Modelle erstellt, die jeweilsbestimmte Aspekte betonen und von anderen abstrahieren. Der Grund liegt daran, dass unterschiedliche Personen,die am Gebaudebau beteiligt sind, das Gebaude aus unterschiedlichen Perspektiven betrachten wollen. Der spatereBesitzer interessiert sich fur das Gesamterscheinungsbild, der Maurer fur den Gebauderahmen und der Elektriker furKabelschachte, Steckdosen, Schalter etc. Das Prinzip, Unterschiedliches auseinander zu halten, ist in derSoftwaretechnik als Separation of Concerns bekannt: die Trennung unterschiedlicher Belange. Dieses Prinzip wirdauch beim Softwarearchitekturentwurf angewandt. Man nennt diese unterschiedlichen Bauplane oft Sichten derArchitektur.Wahrend sich in der Gebaudearchitektur uber viele Jahre feste Normen zu Bauzeichnungen, das heißt,Architektursichten, etabliert haben, stehen wir in der Softwaretechnik noch ganz am Anfang einer Entwicklung hinzu 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 derSoftwarearchitektur uberhaupt relevant sind, legt er uns nicht auf eine feste Menge solcher Sichten fest. Er gehtviel mehr einen indirekten Weg. Er uberlasst es uns, zu entscheiden, welche Sichten wir beschreiben wollen, fordertaber, dass fur alle unsere Sichten definiert ist, was sie bedeuten.



Definition

Architektursicht (View): Reprasentation eines ganzen Systems aus derPerspektive einer koharenten Menge von Anliegen (IEEE P1471 2002).

Definition

Architekturblickwinkel (Viewpoint): Spezifikation der Regeln undKonventionen, um eine Architektursicht zu konstruieren und zubenutzen (IEEE P1471 2002).Ein Blickwinkel ist ein Muster oder eine Vorlage, von der aus individuelleSichten entwickelt werden konnen, durch Festlegung von

Zweck,

adressierte Betrachter

und Techniken fur Erstellung, Gebrauch und Analyse.

Unterschiedliche Sichten helfen der Strukturierung: Separation ofConcerns.



Definition

Architektursicht (View): Reprasentation eines ganzen Systems aus derPerspektive einer koharenten Menge von Anliegen (IEEE P1471 2002).

Definition

Architekturblickwinkel (Viewpoint): Spezifikation der Regeln undKonventionen, um eine Architektursicht zu konstruieren und zubenutzen (IEEE P1471 2002).Ein Blickwinkel ist ein Muster oder eine Vorlage, von der aus individuelleSichten entwickelt werden konnen, durch Festlegung von

Zweck,

adressierte Betrachter

und Techniken fur Erstellung, Gebrauch und Analyse.

Unterschiedliche Sichten helfen der Strukturierung: Separation ofConcerns.

20

09

-02

-09

Software-Projekt




Dazu fuhrt der Standard eine Trennung von konkretem Inhalt und Bedeutung einer Sicht ein. Eine Architektursicht(im Englischen: View) ist die Reprasentation eines ganzen Systems aus der Perspektive einer koharenten Menge vonAnliegen (IEEE P1471 2002). Eine Architektursicht beschreibt also immer ein bestimmtes System, im Sinne derGebaudearchitektur ist das also zum Beispiel die Facadenansicht des neuen Burogebaudes in der Universitatsallee15. In der Software ist die Beschreibung der Klassen und ihrer Abhangigkeiten der Banksoftware PayMe der Version1.3 in Form eines Klassendiagramms eine Architektursicht. Damit man ein Klassendiagramme jedoch verstehenkann, muss beschrieben sein, welche Konstrukte in solch einem Diagramm auftauchen durfen, was sie bedeuten undwie sie kombiniert werden konnen. Wahrend das Klassendiagramm fur PayMe spezifisch und damit nur fur PayMerelevant ist, ist die Beschreibung, wie Klassendiagrammme an sich aussehen konnen und was sie bedeuten,ubergreifend gultig fur alle denkbaren Klassendiagramme unabhangig von den Systemen, die sie beschreiben.Fur die Beschreibung aller moglichen Klassendiagramme fuhrt der IEEE-Standard den BegriffArchitekturblickwinkel (im Englischen: Viewpoint) ein. Ein Architekturblickwinkel (Viewpoint) ist die Spezifikationder Regeln und Konventionen, um eine Architektursicht zu konstruieren und zu benutzen (IEEE P1471 2002). EinBlickwinkel ist ein Muster oder eine Vorlage, von der aus individuelle Sichten entwickelt werden konnen, durchFestlegung des Zwecks, der adressierten Betrachter und der Techniken fur die Erstellung, den Gebrauch und dieAnalyse 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 fur uns, wenn wir eine Architektur durch eine Sicht beschreiben wollen, mussen wir zunachst in Form desBlickwinkels die Bedeutung der Sicht spezifizieren.


Siemens-Blickwinkel (Hofmeister u. a. 2000)

Konzeptioneller Blickwinkel: beschreibt logische Struktur desSystems; abstrahiert weitgehend von technologischen Details

Modulblickwinkel: beschreibt die statische logische Struktur desSystems

Ausfuhrungsblickwinkel: beschreibt die dynamische logischeStruktur des Systems

Code-Blickwinkel: beschreibt die”anfassbaren“ Elemente des

Systems (Quelldateien, Bibliotheken, ausfuhrbare Dateien etc.)



Konzeptioneller Blickwinkel: beschreibt logische Struktur desSystems; abstrahiert weitgehend von technologischen Details

Modulblickwinkel: beschreibt die statische logische Struktur desSystems

Ausfuhrungsblickwinkel: beschreibt die dynamische logischeStruktur des Systems

Code-Blickwinkel: beschreibt die”anfassbaren“ Elemente des

Systems (Quelldateien, Bibliotheken, ausfuhrbare Dateien etc.)

20

09

-02

-09

Software-Projekt




In der Literatur wurden sehr viele unterschiedliche Blickwinkel zur Beschreibung von Softwarearchitekturvorgeschlagen. Zachman (1987); Sowa und Zachman (1992); Zachman (1999) war einer der ersten Autoren, derBlickwinkel vorgeschlagen hat. Er schlug vor, Informationssysteme durch 6× 6 verschiedene Blickwinkel zubeschreiben. Perry und Wolf (1992) haben mehrere Blickwinkel von Zachman zusammen gefasst und die Anzahlder Blickwinkel damit auf drei reduziert, die letzten Endes aber aquivalent sind und lediglich unterschiedlicheAspekte hervor heben. Von Kruchten (1995) stammen die 4+1-Blickwinkel. Dazu gehoren der logische Blickwinkel,der das System abstrakt und anwendungsnah beschreibt, der Prozessblickwinkel, der die dynamische Ausfuhrungbeschreibt sowie der statische Entwicklungsblickwinkel und der physikalische Blickwinkel, der das System in dieHardware einbettet. Diese vier Blickwinkel werden zusammen gehalten durch einen redundanten Blickwinkel, dermittels Anwendungsszenarien beschreibt, wie die vier anderen Blickwinkel zusammen spielen.Die unterschiedlichen Blickwinkel in der Literatur sind verwirrend, zumal sehr viele Blickwinkel unterschiedlicherAutoren sehr ahnlich sind. Etwas Ordnung hat hier das Buch von (Clements u. a. 2002) geschaffen, in demKategorien von Blickwinkeln beschrieben sind. Dieses Buch ist auch zu empfehlen fur die Frage, wie manSoftwarearchitektur 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 Systemsnotwendig sind, die durch die vier Siemens-Blickwinkel abgedeckt werden:

• Konzeptioneller Blickwinkel: beschreibt die logische Struktur des Systems. Er abstrahiert weitgehend vontechnologischen Details wie z.B. konkrete Technologien, mit denen das System implementiert wird. Dieser Blickwinkelist der Anwendungsdomane am nachsten.

• Modulblickwinkel: beschreibt die statische logische Struktur des Systems in Form von Modulen und ihrenAbhangigkeiten.

• Ausfuhrungsblickwinkel: beschreibt die dynamische logische Struktur des Systems, das heißt, die Ausfuhrung undEinbettung in die ausfuhrende Hardware.

• Code-Blickwinkel: beschreibt die”anfassbaren“ Elemente des Systems (Quelldateien, Bibliotheken, ausfuhrbare Dateien

etc.).

Die vier Siemens-Blickwinkel wurden durch Befragung praktizierender Softwarearchitekten bei Siemens ermittelt,haben also offenbar praktische Relevanz.



Modul−beschränkungen

ModuleSubsysteme

Schichten

neueModula−risierung

Änderungen

elementenan Laufzeit−

KonnektorenKonfiguration

Komponenten

KomponentenKonnektorenKonfiguration

Laufzeit−beschränk−ungen

neueModula−risierungLaufzeit−elemente

Modulblickwinkel

Code−Blickwinkel

Aus

führ

ungs

blic

kwin

kel

Konzeptioneller Blickwinkel

Software−Architektur

Einfluss

Rückkopplung

Module

Quell−Code

Har

dwar

e−A

rchi

tekt

ur



Modul−beschränkungen

ModuleSubsysteme

Schichten

neueModula−risierung

Änderungen

elementenan Laufzeit−

KonnektorenKonfiguration

Komponenten

KomponentenKonnektorenKonfiguration

Laufzeit−beschränk−ungen

neueModula−risierungLaufzeit−elemente

Modulblickwinkel

Code−Blickwinkel

Aus

führ

ungs

blic

kwin

kel


Software−Architektur

Einfluss

Rückkopplung

Module

Quell−Code

Har

dwar

e−A

rchi

tekt

ur

20

09

-02

-09

Software-Projekt




In der Methode von Hofmeister u. a. (2000) sind diese vier Blickwinkel der Gegenstand des Entwurfes. DieSoftwarearchitektur wird entworfen, indem Sichten zu diesen vier Blickwinkeln erstellt werden.Wir werden im Folgenden naher auf diese Blickwinkel eingehen, indem wir sie im Kontext der Hofmeister-Methodebeschreiben.


− Ressourcenbudget

Globale Analyse− Faktoren− Strategien

globale Evaluation

Produktfaktoren


Modulblickwinkel

Code−Blickwinkel

Einfluss

RückkopplungQuell−Code


Aus

führ

ungs

blic

kwin

kel

Har

dwar

e−A

rchi

tekt

ur



− Konfiguration− Konnektoren− Komponenten


− Ressourcenbudget


globale Evaluation

Produktfaktoren


Modulblickwinkel

Code−Blickwinkel

Einfluss



Aus

führ

ungs

blic

kwin

kel

Har

dwar

e−A

rchi

tekt

ur



− Konfiguration− Konnektoren− Komponenten

20

09

-02

-09

Software-Projekt



Der Ausgangspunkt des Architekturentwurfes ist der konzeptionelle Blickwinkel. Mit Hilfe dieses Blickwinkels wirddie logische Struktur der angestrebten Architektur beschrieben. Ahnlich wie beim Datenbankentwurf, wo wirzunachst von einem konzeptionelle Schema ausgehen, das die Daten beschreibt so wie sie in derAnwendungsdomane sind. Es handelt sich noch nicht um den Entwurf einer konkreten Datenbank fur dasAnwendungsproblem, der ja letztlich stark von der verwendeten Technologie abhangt. In der Gebaudearchitekturgleicht der logische Blickwinkel, den ersten Skizzen, die der Architekt von dem spateren Haus macht. Dabei will erden Kopf noch frei haben von Detailentscheidungen, welche Heizung eingebaut wird etc.Ausgehend von der globalen Analyse der Einflussfaktoren, entwirft der Softwarearchitekt die Hauptkomponentenund -konnektoren des Systems. Eine Komponente ist eine Berechnungseinheit oder eine Einheit, die Datenspeichert. Dabei geht es nicht um einzelne Klassen oder gar spezifischen Algorithmen und Datenstrukturen,sondern um die grobe Verteilung der Zustandigkeiten in einem System auf großere Bausteine. Wie umfangreich soein Baustein ausfallt, hangt von der Große des Systems ab. Je großer das System, desto großer werden dieKomponenten initial ausfallen. Große Komponenten konnen dann spater verfeinert werden. Ein Beispiel fur eineKomponente in einem großeren System ist etwa eine Datenbank, in einer Client-Server-Architektur waren sowohlClient als auch Server erste Komponenten.Komponenten interagieren miteinander, um eine gemeinsame Aufgabe zu erfullen. Hierzu sind sie uber so genannteKonnektoren verbunden. Ein Konnektor stellt den Kontroll- und Datenfluss zwischen Komponenten dar. PrimitiveKonnektoren sind Methodenaufrufe, Parameterubergabe und Zugriffe auf Attribute. Komplexere Konnektoren sindbeispielsweise 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 undKonnektoren alle geforderten Anwendungsfalle auch tatsachlich unterstutzen. Hierzu kann man auf dem Papieruberlegen, was die Komponenten und Konnektoren alles machen wurden fur jeden einzelnen Anwendungsfall.Abschließend werden noch die Ressourcen fur Komponenten und Konnektoren eingeplant, also wie viel Speicherund Rechenzeit Komponenten und Konnektoren zuerkannt bekommen.


Konzeptioneller Blickwinkel (Hofmeister u. a. 2000)

ist der Anwendungsdomane am nachsten

Systemfunktionalitat wird abgebildet auf

Konzeptionelle Komponenten: rechenbetonte Elemente oderDatenhaltungKonnektoren: Kontroll- und Datenfluss zwischen konzeptionellenKomponenten

Engineering-Belange:

Wie erfullt das System seine Anforderungen?

Wie werden Commercial-off-the-Shelf-Components (COTS) in dasSystem integriert?

Wie wird domanenspezifische Soft- und Hardware einbezogen?

Wie kann die Auswirkung von Anforderungen oder derAnwendungsdomane minimiert werden?



ist der Anwendungsdomane am nachsten

Systemfunktionalitat wird abgebildet auf

Konzeptionelle Komponenten: rechenbetonte Elemente oderDatenhaltungKonnektoren: Kontroll- und Datenfluss zwischen konzeptionellenKomponenten


Wie erfullt das System seine Anforderungen?

Wie werden Commercial-off-the-Shelf-Components (COTS) in dasSystem integriert?

Wie wird domanenspezifische Soft- und Hardware einbezogen?

Wie kann die Auswirkung von Anforderungen oder derAnwendungsdomane minimiert werden?

20

09

-02

-09

Software-Projekt




Wie gesagt, steckt hinter der Aufteilung in Blickwinkel das Prinzip der Trennung unterschiedlicher Belange. WelcheBelange adressiert der konzeptionelle Blickwinkel also? Es geht dabei um die folgenden Fragen:

• Wie erfullt das System seine Anforderungen?

• Wie werden Commercial-off-the-Shelf-Components (COTS) in das System integriert, falls dies geplant ist?

• Wie wird domanenspezifische Soft- und Hardware einbezogen?

• Wie kann die Auswirkung von Anforderungen oder der Anwendungsdomane minimiert werden? Idealerweise sollte mannur eine Komponente anfassen mussen, wenn sich eine neue Anforderung aus der Anwendungsdomane ergibt. Dazumuss man jedoch die moglichen Anderungen vorwegsehen und die Architektur entsprechend so entwerfen, dass es leichtfallen wird, die zukunftige Anforderung zu realisieren.



CComponent

CPort

Conceptual Configuration

CConnector

CRole

Protocolobeysobeys

cbindingcbinding

connection

11

* *

*

*

*

*

* *

* *

* *

1 1

0..1

0..1 0..1 0..1 0..10..1*

*

conjugate



CComponent

CPort


CConnector

CRole

Protocolobeysobeys

cbindingcbinding

connection

11

* *

*

*

*

*

* *

* *

* *

1 1

0..1

0..1 0..1 0..1 0..10..1*

*

conjugate

20

09

-02

-09

Software-Projekt




Nachdem wir nun die Rolle und den Zweck des konzeptionellen Blickwinkels kennen, betrachten wir naher, wie einekonzeptionelle Sicht aufgebaut sein kann. Wir wenden uns also der Frage zu, wie der logische Blickwinkel eigentlichaussieht.Wir haben bereits uber die prinzipiellen Modellierungselemente gesprochen: Komponenten, Konnektoren und dieArt und Weise, wie sie in einer Konfiguration angeordnet werden.Das folgende Diagramm in UML beschreibt den logischen Blickwinkel genauer:

CComponent

CPort


CConnector

CRole

Protocolobeysobeys

cbindingcbinding

connection

11

* *

*

*

*

*

* *

* *

* *

1 1

0..1

0..1 0..1 0..1 0..10..1*

*

conjugate

Wie wir sehen, besteht eine Konfiguration aus einer Menge von Komponenten und Konnektoren. SowohlKomponenten als auch Konnektoren konnen verfeinert werden, was die Komposition andeutet. Wenn eineKomponente verfeinert wird in Teilkomponenten, mussen diese selbstverstandlich auch uber Konnektoren wiederverbunden werden. Aus diesem Grunde ist auch die Komposition zwischen Konnektoren und Komponentenzwingend notwendig. Ahnliches gilt fur die Verfeinerung von Komponenten. Hiermit konnen wir beschreiben, wieein Konnektor durch Teilkomponenten und deren Konnektoren implementiert wird.


CComponent

CPort


CConnector

CRole

Protocolobeysobeys

cbindingcbinding

connection

11

* *

*

*

*

*

* *

* *

* *

1 1

0..1

0..1 0..1 0..1 0..10..1*

*

conjugate

20

09

-02

-09

Software-Projekt




Zur Verbindung von Komponenten und Konnektoren existieren entsprechende Beschreibungselemente: Anschlusse(Ports) und Rollen (Roles). Ein Anschluss (Port) ist ein Teil der Komponente. Das Pendant hierzu fur Konnektorenist die Rolle (Role). Wenn wir also beispielsweise eine Kommunikation zwischen einem Client und einem Serverbeschreiben wollen, dann werden diese zwei Komponenten uber einen Konnektor fur die Interprozesskommunikationverbunden, wie im oberen Teil der folgenden Grafik dargestellt:

Die Kommunikation dient dem Datenaustausch, deshalb wird hierfur ein Query-Konnektor verwendet, der fur

Anfragen an Server gedacht ist. UML-Stereotypen beschreiben die Diagrammelemente. Die Stereotypen

entstammen dem konzeptionellen Blickwinkel.


Komponenten und Konnektoren



20

09

-02

-09

Software-Projekt




Eine solche Kommunikation ist im Falle einer Client-Server-Architektur asymmetrisch, das heißt, der Konnektorwird unterschiedlich benutzt von den Komponenten. Wahrend der Server am Konnektor auf eingehende Anfragenwartet und diese dann beantwortet, ergreift der Client die Initiative und schickt dem Server seine Anfragen. DerQuery-Konnektor fur die Interprozesskommunikation hat also eine Rolle fur den Client und eine fur den Server. DerTeil der Komponente, der die jeweilige Rolle, die durch einen Konnektor vorgegeben wird, anspricht ist der Port.Angenommen der Query-Konnektor wird durch spater durch Remote Method Invocation (RMI) in Javaimplementiert, dann kann man sich den Port konkret vorstellen als der Code in der Komponente, der denRMI-Aufruf absetzt.Konnektoren beschreiben Kontroll- und/oder Datenfluss. Man kann entweder auf die allgemeinen Data-beziehungsweise Control-Konnektoren zuruck greifen oder aber sich seine eigenen Konnektoren definieren. In derzweiten Zeile des Diagramms sehen wir zum Beispiel einen allgemeinen Data-Konnektor fur den Datenaustauschzwischen einem Produzenten und Konsumenten und in der dritten Zeile einen Control-Konnektor, der einenObserver benachrichtigt, wann immer sich eine observierte Komponenten in ihrem Zustand andert. Die letzte Zeilebeschreibt einen selbst definierten Konnektor fur den Datenaustausch uber eine Pipe, wie das zum Beispiel in Unixunterstutzt wird.Die Verbindung von Komponenten und Konnektoren ist bislang rein strukturell dargestellt. Das bisher Gesagtebeschreibt 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 ausgefuhrt werden. Der Porteiner Komponente hat ein Protokoll, ebenso erwartet der Konnektor fur eine Rolle eine vorgegebenVerwendungsweise, hat also auch ein Protokoll. Diese beiden Protokoll mussen selbstverstandlich kompatibel sein.Zu der Bedeutung und den Einschrankungen von cbinding kommen wir spater noch.


Strategie

Lege externe Schnittstellen fest.pro

beC

om

mands

pro

beD

ata

userA

cqC

ontro

luserIm

ageE

xport

userA

cqD

ispla

y

networkAccess

:IS2000


Strategie

Lege externe Schnittstellen fest.

pro

beC

om

mands

pro

beD

ata

userA

cqC

on

trol

use

rImageE

xpo

rtuserA

cq

Dis

pla

y

networkAccess

:IS2000

20

09

-02

-09

Software-Projekt



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 Entwurfskonfliktenumzugehen. Sie werden nun eingesetzt.Wir beschreiben den Entwurfsprozess top-down, das heißt, wir beginnen im Folgenden mit dem System als einegroße Komponente und verfeinern sie weiter. Das ist ein gangiges Vorgehen. Sollen aber existierende Komponentenwiederverwendet werden, dann kombiniert man den Top-Down-Ansatz mit einem Bottom-Up-Vorgehen. Letzterergeht von den existierenden Komponenten aus und baut sie zu einem großeren Ganzen sukzessive zusammen. In derKombination entwirft man sowohl top-down als auch bottum-up und versucht, die beiden Entwurfsrichtungenaufeinander zuzufuhren. Beim reinen Top-Down-Vorgehen kann es dazu kommen, dass existierende Komponentennicht wiederverwendet werden, weil sie nicht das Gefuge passen; außerdem konnen redundante Komponentenentstehen. Erfahrene Architekten beherrschen beide Richtungen.

Strategie

Lege externe Schnittstellen fest.

pro

beC

om

mands

pro

beD

ata

userA

cqC

on

trol

use

rImageE

xpo

rtuserA

cq

Dis

pla

y

networkAccess

:IS2000

20

09

-02

-09

Software-Projekt



Wir beginnen hier also zunachst mit dem System als eine einzige Komponente. In der Anforderungsanalyse habenwir uns bereits damit auseinander gesetzt, welche Schnittstellen nach außen das System bieten muss. Diese werdennun eingezogen. Es ergibt sich das folgende Bild:

pro

be

Co

mm

an

ds

pro

be

Da

tau

se

rAcq

Co

ntro

lu

se

rIma

ge

Exp

ort

use

rAcq

Dis

pla

y

networkAccess

:IS2000

Die schwarzen Kastchen am Rande der Komponente sind ihre Ports, das heißt, ihre Schnittstellen nach außen.


Strategie

Fuhre Komponenten fur Aufzeichnung, Bearbeitung und Export ein.

:Contr

ol

:Data

sender

receiv

er

source dest

:Exporting

:Imaging

:Acquisition

pro

beC

om

mands

pro

beD

ata

userA

cqC

ontro

luserIm

ageE

xport

userA

cqD

ispla

y

networkAccess

:IS2000


Strategie


:Co

ntr

ol

:Data

se

nd

er

rece

ive

r

source dest

:Exporting

:Imaging

:Acquisition

pro

beC

om

mands

pro

beD

ata

userA

cqC

on

trol

use

rImageE

xpo

rtuserA

cq

Dis

pla

y

networkAccess

:IS2000

20

09

-02

-09

Software-Projekt



Nun fuhren wir Komponenten fur Aufzeichnung, Bearbeitung und Export ein. Diese Aufteilung folgt demEVA-Prinzip (Eingabe/Verarbeitung/Ausgabe) und stellt eine Umsetzung des Strategie Separation of Concern dar.Die inneren Komponenten werden uber innere Konnektoren verbunden. Hier gilt die Regel, dass eine Verbindungzwischen einem Port und einer Rolle nur moglich ist, wenn die zugehorigen Komponenten und Konnektoren imselben anderen Element (Komponente oder Konnektor) enthalten sind. Mit anderen Worten, die Verbindung kannkeine Abstraktionsebene durchqueren. Wir stellen fest, dass die Komponenten und Konnektoren wie gefordert Teilder selben Komponente sind. Damit ist das Diagramm in diesem Punkt wohlgeformt.

:Contr

ol

:Data

se

nd

er

rece

ive

r

source dest

:Exporting

:Imaging

:Acquisition

pro

be

Co

mm

an

ds

pro

be

Da

tau

se

rAcq

Co

ntro

lu

se

rIma

ge

Exp

ort

use

rAcq

Dis

pla

y

networkAccess

:IS2000

Strategie


:Co

ntr

ol

:Data

se

nd

er

rece

ive

r

source dest

:Exporting

:Imaging

:Acquisition

pro

beC

om

mands

pro

beD

ata

userA

cqC

on

trol

use

rImageE

xpo

rtuserA

cq

Dis

pla

y

networkAccess

:IS2000

20

09

-02

-09

Software-Projekt



Wir erkennen des Weiteren eine Verbindung zwischen zwei Ports und zwar von den inneren Komponenten zu denPorts der umgebenden Komponente. Dies sind die so genannten CBindings, auf die wir bislang noch nichteingegangen sind. Sie dienen dazu, darzustellen wie die außeren Ports auf die inneren Ports beziehungsweise dieaußeren Rollen auf die inneren Rollen abgebildet werden, stellen also den Kontext der außeren Schnittstellen zuminneren Aufbau her. Hier ist die Regel, dass ein CBinding von einem inneren Ports nur zu einem Port derunmittelbar umschließenden Komponente verlaufen darf. Entsprechendes gilt fur ein CBinding zwischen Rollen. DasDiagramm halt sich auch an diese Regel.


Strategie

Kapselung domanenspezifischer Hardware.

:Contr

ols

ender

receiv

er

:Probe

Control

:DataCollection

:Contr

ol

:Data

sender

receiv

er

source dest

:Exporting

:Imaging

:Acquisition

pro

beC

om

mands

pro

beD

ata

userA

cqC

ontro

luserIm

ageE

xport

userA

cqD

ispla

y

networkAccess

:IS2000


Strategie

Kapselung domanenspezifischer Hardware.

:Co

ntr

ols

en

de

rre

ce

ive

r

:Probe

Control

:DataCollection

:Co

ntr

ol

:Data

se

nd

er

rece

ive

r

source dest

:Exporting

:Imaging

:Acquisition

pro

beC

om

mands

pro

beD

ata

userA

cqC

on

trol

use

rImageE

xpo

rtuserA

cq

Dis

pla

y

networkAccess

:IS2000

20

09

-02

-09

Software-Projekt



Im nachsten Schritt wenden wir die Strategie der Kapselung domanenspezifischer Hardware an, damit wir vorAnderungen dieser Hardware weitgehend geschutzt sind. Dazu fuhren wir zwei weitere Teilkomponenten ein, dievon den Eigenschaften der Eingabe-Hardware abstrahieren, die sich andern konnen. Diese beiden Komponentenstellen Geratetreiber dar.

:Co

ntr

ols

en

de

rre

ce

ive

r:Probe

Control

:DataCollection

:Co

ntr

ol

:Data

se

nd

er

rece

ive

r

source dest

:Exporting

:Imaging

:Acquisition

pro

be

Co

mm

an

ds

pro

be

Da

tau

se

rAcq

Co

ntro

lu

se

rIma

ge

Exp

ort

use

rAcq

Dis

pla

y

networkAccess

:IS2000

Wir erkennen in diesem Diagramm, wie die Anschlussbindung der innersten Komponenten zu den außerstenSystemschnittstellen von IS2000 uber zwei Ebenen hinweg erfolgt.


Strategie

Entkopple Interaktionsmodell.

:Acquire

:Monitor

:Contr

ols

ender

receiv

er

:Probe

Control

:DataCollection

:Contr

ol

:Data

sender

receiv

er

source dest

:Exporting

:Imaging

:Acquisition

pro

beC

om

mands

pro

beD

ata

userA

cqC

ontro

luserIm

ageE

xport

userA

cqD

ispla

y

networkAccess

:IS2000


Strategie

Entkopple Interaktionsmodell.

:Acquire

:Monitor

:Co

ntr

ols

en

de

rre

ce

ive

r

:Probe

Control

:DataCollection

:Co

ntr

ol

:Data

se

nd

er

rece

ive

r

source dest

:Exporting

:Imaging

:Acquisition

pro

beC

om

mands

pro

beD

ata

userA

cqC

on

trol

use

rImageE

xpo

rtuserA

cq

Dis

pla

y

networkAccess

:IS2000

20

09

-02

-09

Software-Projekt



Um auch gefeit zu sein gegen Anderungen in der Art und Weise, wie mit dem Benutzer interaktiv kommuniziertwird, fuhren wir analog zu den Geratetreibern eigene Teilkomponenten ein, die von Eingabe beziehungsweiseAusgabe von und zum Benutzer abstrahieren. Wir wenden damit eine Strategie zur Entkopplung desInteraktionsmodells an.

:Acquire

:Monitor

:Co

ntr

ols

en

de

rre

ce

ive

r:Probe

Control

:DataCollection

:Co

ntr

ol

:Data

se

nd

er

rece

ive

r

source dest

:Exporting

:Imaging

:Acquisition

pro

be

Co

mm

an

ds

pro

be

Da

tau

se

rAcq

Co

ntro

lu

se

rIma

ge

Exp

ort

use

rAcq

Dis

pla

y

networkAccess

:IS2000


Strategie

Separiere nach Anliegen: Separation of Concern.

:Control :Control

senderreceiver receiver sender

:Acquisition

Management

:Acquisition:Acquire

:Monitor

:Contr

ols

ender

receiv

er

:Probe

Control

:DataCollection

:Contr

ol

:Data

sender

receiv

er

source dest

:Exporting

:Imaging

pro

beC

om

mands

pro

beD

ata

userA

cqC

ontro

luserIm

ageE

xport

userA

cqD

ispla

y

networkAccess

:IS2000


Strategie

Separiere nach Anliegen: Separation of Concern.

:Control :Control


:Acquisition

Management


:Monitor

:Co

ntr

ols

en

de

rre

ce

ive

r

:Probe

Control

:DataCollection

:Co

ntr

ol

:Data

se

nd

er

rece

ive

r

source dest

:Exporting

:Imaging

pro

beC

om

mands

pro

beD

ata

userA

cqC

on

trol

use

rImageE

xpo

rtuserA

cq

Dis

pla

y

networkAccess

:IS2000

20

09

-02

-09

Software-Projekt



Die Trennung in der Komponente Acquisition in zwei Teilkomponenten fuhrt dazu, dass die verbleibendeFunktionalitat dieser Komponente, die weder hardware-spezifisch noch spezifisch fur das Interaktionsmodell ist, ineiner weiteren Komponente Aquisition-Management versammelt werden muss.

:Control :Control


:Acquisition

Management


:Monitor

:Contr

ols

en

de

rre

ce

ive

r

:Probe

Control

:DataCollection

:Contr

ol

:Data

se

nd

er

rece

ive

r

source dest

:Exporting

:Imaging

pro

be

Co

mm

an

ds

pro

be

Da

tau

se

rAcq

Co

ntro

lu

se

rIma

ge

Exp

ort

use

rAcq

Dis

pla

y

networkAccess

:IS2000


Strategie

Separiere zeitkritische Komponenten.

:Data :Data :Data

:Contr

ol

source dest source dest

receiv

er

sender

source dest

:Imaging

:ImageProcessing

:PostProcessing

:Control :Control


:Acquisition

Management


:Monitor

:Contr

ols

ender

receiv

er

:Probe

Control

:DataCollection

:Contr

ol

:Data

sender

receiv

er

source dest

:Exporting

pro

beC

om

mands

pro

beD

ata

userA

cqC

ontro

luserIm

ageE

xport

userA

cqD

ispla

y

networkAccess

:IS2000


Strategie

Separiere zeitkritische Komponenten.

:Data :Data :Data

:Co

ntr

ol


rece

ive

rse

nd

er

source dest

:Imaging

:ImageProcessing

:PostProcessing

:Control :Control


:Acquisition

Management


:Monitor

:Co

ntr

ols

en

de

rre

ce

ive

r

:Probe

Control

:DataCollection

:Co

ntr

ol

:Data

se

nd

er

rece

ive

r

source dest

:Exporting

pro

beC

om

mands

pro

beD

ata

userA

cqC

on

trol

use

rImageE

xpo

rtuserA

cq

Dis

pla

y

networkAccess

:IS2000

20

09

-02

-09

Software-Projekt



In analoger Weise mussen wir auch bei der Komponente Imaging so verfahren. Hier nehmen wir aber noch eineweitere Verfeinerung vor. Und zwar trennen wir Algorithmen mit Echtzeitanforderungen (also z.B. das komprimierteAbspeichern des aufgenommenen Bildes, damit kein Bild verloren geht) und weiterfuhrende Algorithmen ohneEchtzeitanforderungen (wie z.B. das Aufhellen dunkler Bilder). Auf diese Weise konnen die Algorithmen mitunterschiedlichen Prioritaten versehen und auch auf unterschiedlichen Prozessoren ausgefuhrt werden.

:Data :Data :Data

:Contr

ol


rece

ive

rse

nd

er

source dest

:Imaging

:ImageProcessing

:PostProcessing

:Control :Control


:Acquisition

Management


:Monitor

:Contr

ols

en

de

rre

ce

ive

r

:Probe

Control

:DataCollection

:Contr

ol

:Data

se

nd

er

rece

ive

r

source dest

:Exporting

pro

be

Co

mm

an

ds

pro

be

Da

tau

se

rAcq

Co

ntro

lu

se

rIma

ge

Exp

ort

use

rAcq

Dis

pla

y

networkAccess

:IS2000


Strategie

Kapselung domanenspezifischer Bild-Daten.

:Data

:Data

:Contr

ol

source dest

sender

receiv

er

source dest

:Exporting

:ImageCollection

:Comm

:Export

:Data :Data :Data

:Contr

ol


receiv

er

sender

source dest

:Imaging

:ImageProcessing

:PostProcessing

:Control :Control


:Acquisition

Management


:Monitor

:Contr

ols

ender

receiv

er

:Probe

Control

:DataCollection

:Contr

ol

:Data

sender

receiv

er

source dest

pro

beC

om

mands

pro

beD

ata

userA

cqC

ontro

luserIm

ageE

xport

userA

cqD

ispla

y

networkAccess

:IS2000


Strategie


:Data

:Data

:Co

ntr

ol

source dest

se

nd

er

rece

ive

r

source dest

:Exporting

:ImageCollection

:Comm

:Export

:Data :Data :Data

:Co

ntr

ol


rece

ive

rse

nd

er

source dest

:Imaging

:ImageProcessing

:PostProcessing

:Control :Control


:Acquisition

Management


:Monitor

:Co

ntr

ols

en

de

rre

ce

ive

r

:Probe

Control

:DataCollection

:Co

ntr

ol

:Data

se

nd

er

rece

ive

r

source dest

pro

beC

om

mands

pro

beD

ata

userA

cqC

on

trol

use

rImageE

xpo

rtuserA

cq

Dis

pla

y

networkAccess

:IS2000

20

09

-02

-09

Software-Projekt



Schließlich verfeinern wir noch die Komponenten Exporting. Hier wollen wir den Aufwand fur den Export inunterschiedliche Bildformate minimieren. Wir wenden dazu eine Strategie an, die domanenspezifischer Bild-Datenkapselt. Wir wahlen hierfur eine interne Reprasentation unserer Bild-Daten in einer DatenhaltungskomponenteImage Collection. Fur den Export gibt es dann je eine Transformation des internen in das gewunschte Format. DieKomponente Export ubernimmt hierfur die notwendige Interaktion mit dem Benutzer. Außerdem konnen die Bilderauch noch uber ein Netzwerk verschickt werden. Diese Aufgabe ubernimmt die Komponente Comm.

:Data

:Data

:Contr

ol

source dest

se

nd

er

rece

ive

r

source dest

:Exporting

:ImageCollection

:Comm

:Export

:Data :Data :Data

:Contr

ol


rece

ive

rse

nd

er

source dest

:Imaging

:ImageProcessing

:PostProcessing

:Control :Control


:Acquisition

Management


:Monitor

:Contr

ols

en

de

rre

ce

ive

r

:Probe

Control

:DataCollection

:Contr

ol

:Data

se

nd

er

rece

ive

r

source dest

pro

be

Co

mm

an

ds

pro

be

Da

tau

se

rAcq

Co

ntro

lu

se

rIma

ge

Exp

ort

use

rAcq

Dis

pla

y

networkAccess

:IS2000

Strategie


:Data

:Data

:Co

ntr

ol

source dest

se

nd

er

rece

ive

r

source dest

:Exporting

:ImageCollection

:Comm

:Export

:Data :Data :Data

:Co

ntr

ol


rece

ive

rse

nd

er

source dest

:Imaging

:ImageProcessing

:PostProcessing

:Control :Control


:Acquisition

Management


:Monitor

:Co

ntr

ols

en

de

rre

ce

ive

r

:Probe

Control

:DataCollection

:Co

ntr

ol

:Data

se

nd

er

rece

ive

r

source dest

pro

beC

om

mands

pro

beD

ata

userA

cqC

on

trol

use

rImageE

xpo

rtuserA

cq

Dis

pla

y

networkAccess

:IS2000

20

09

-02

-09

Software-Projekt



Wir haben in diesem Abschnitt gesehen, wie man eine konzeptionelle Sicht sukzessive durch Anwendung dervorbereiteten Strategien verfeinert. Dabei sollte jede Anwendung einer Strategie unbedingt dokumentiert werden,damit die Entwurfsentscheidungen nachvollziehbar werden. Die Begrundungen fur bestimmteEntwurfsentscheidungen lassen sich namlich auch nicht durch Reverse-Engineering-Techniken, die allein vomQuellcode ausgehen, nicht wieder rekonstruieren. Der Quellcode ist die sicherste Beschreibung dafur, was dieSoftware macht. Er enthalt aber keinen Hinweis darauf, was er hatte machen sollen, warum er was macht undwarum er es gerade so macht.


Produktfaktoren


Code−Blickwinkel

Einfluss


− Schnittstellen


globale Evaluation

Aus

führ

ungs

blic

kwin

kel

Har

dwar

e−A

rchi

tekt

urModulblickwinkel



Zentrale Entwurfs−aufgabe− Module− Schichten− Subsysteme


Produktfaktoren


Code−Blickwinkel

Einfluss


− Schnittstellen


globale Evaluation

Aus

führ

ungs

blic

kwin

kel

Har

dwar

e−A

rchi

tekt

urModulblickwinkel



Zentrale Entwurfs−aufgabe− Module− Schichten− Subsysteme

20

09

-02

-09

Software-Projekt


Modulblickwinkel

Im nachsten Schritt uberfuhren wir die konzeptionelle Sicht in die Modulsicht, die den statischen Aufbau desSystems beschreibt in Form von Modulen, Schnittstellen, Subsystemen und Schichten. Es ist gut moglich, dass sichbeim Entwurf der konzeptionellen Sicht, sich neue Aspekte ergeben haben, so dass wir die globale Analysegegebenfalls wiederholen, bevor wir uns an die zentrale Entwurfsaufgaben machen, die Module zu entwerfen. NachEntwurf der Module und ihre Anordnung in Schichten und Subsystemen, entwerfen wir abschließend derenSchnittstellen.In diesem Abschnitt vertiefen wir den Modulsichtentwurf. Es sei voraus geschickt, dass wir nicht streng sequentiellModulsicht, dann Ausfuhrungs- und dann Code-Sicht entwerfen. Vielmehr ist der Entwurfsprozess meist iterativ.


Modulblickwinkel

bildet Komponenten und Konnektoren auf Module, Schichten undSubsysteme ab

setzt konzeptionelle Losung 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 unterstutzt?

Wie konnen Abhangigkeiten zwischen Modulen minimiert werden?

Wie kann die Wiederverwendung von Modulen maximiert werden?

Welche Techniken konnen eingesetzt werden, um Auswirkungen vonAnderungen zu minimieren.


Modulblickwinkel

bildet Komponenten und Konnektoren auf Module, Schichten undSubsysteme ab

setzt konzeptionelle Losung 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 unterstutzt?

Wie konnen Abhangigkeiten zwischen Modulen minimiert werden?

Wie kann die Wiederverwendung von Modulen maximiert werden?

Welche Techniken konnen eingesetzt werden, um Auswirkungen vonAnderungen zu minimieren.

20

09

-02

-09

Software-Projekt


Modulblickwinkel

Modulblickwinkel

Beim Entwurf der Modulsicht bilden wir die Komponenten und Konnektoren der konzeptionellen Sicht auf Module,Schichten und Subsysteme ab. Hierzu setzen wir die konzeptionelle Losung mit der aktuellen Softwareplattforme(Programmiersprachen, Bibliotheken, Werkzeuge) und Technologien um. Dabei werden rein statische Aspektebeschrieben.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 unterstutzt?

• Wie konnen Abhangigkeiten zwischen Modulen minimiert werden?

• Wie kann die Wiederverwendung von Modulen maximiert werden?

• Welche Techniken konnen eingesetzt werden, um Auswirkungen von Anderungen zu minimieren.

Fur die Modulsichten interessieren sich Programmierer fur die Programmierung. Tester interessieren fur denBlackbox-Komponententest sowie den Integrationstest. Ein Projektleiter kann von der Modulsicht Gebrauchmachen, um festzulegen, welcher Entwickler welches Modul implementieren soll.


Modulblickwinkel (Hofmeister u. a. 2000)

Module (layer) A uses

Module

Interface

Layer

module (layer) B whenA requires an interfacethat B provides

Subsystem

use

0..1

require *

*

*

require

* provide

*

* * * * *

0..1

0..1

use *

* *

* assigned−to

*

cont

ain

provide

contain

0..1




Module

Interface

Layer


Subsystem

use

0..1

require *

*

*

require

* provide

*

* * * * *

0..1

0..1

use *

* *

* assigned−to

*

cont

ain

provide

contain

0..1

20

09

-02

-09

Software-Projekt


Modulblickwinkel


Der Modulblickwinkel wird durch das folgende UML-Diagramm beschrieben:


Module

Interface

Layer


Subsystem

use

0..1

require *

*

*

require

* provide

*

* * * * *

0..1

0..1

use *

* *

* assigned−to

*

cont

ain

provide

contain

0..1

Ein Modul ist eine statische, austauschbare Gliederungseinheit mit einem bestimmten Zweck. Es kann in derBeschreibung durch Teilmodule verfeinert werden. Ein Modul hat zwei Kategorien von Schnittstellen: dieSchnittstellen, die es selbst anderen anbietet (provides) und jene, die es von anderen benotigt require). In denmeisten Programmiersprachen kann man nur die zur Verfugung gestellten Schnittstellen angeben, aber nicht jene,die das Modul voraussetzt. Wenn Module aber ausgetauscht werden und die Auswirkung von Anderungen analysiertwerden sollen, dann benotigt man auch Wissen daruber, welche Schnittstelle ein Modul voraussetzt.Module konnen zu Schichten angeordnet werden. Damit wird die Sichtbarkeit von Modulen festgelegt. Bei einemstrikten Schichtenmodell durfen Module einer Schicht nur auf Module der nachst tieferen Schicht zugreifen. Dieserhoht die Austauschbarkeit. Ein Schicht implementiert eine Art virtuelle Maschine. Auch Schichten haben beideArten von Schnittstellen und konnen wieder weiter in Teilschichten verfeinert werden.Schließlich konnen Module nochmal unabhangig von Schichten zu einem Subsystem zusammen gefasst werden. EinSubsystem ist eine weitere Gliederungseinheit, die orthogonal zu hierarchischen Modulen und zu Schichten ist. IhreDaseinberechtigung wird spater im Kontext des Code-Blickwinkels deutlicher.Ein Modul benutzt (use) ein anderes Modul beziehungsweise Schicht, wenn das Modul auf eine Schnittstellezugreift, das von dem anderen Modul beziehungsweise der Schicht zur Verfugung gestellt wird.Die use-Beziehung ist eine allgemeine Form von Abhangigkeit. Man kann unter ihr auch eine Vererbungsbeziehungsubsumieren. Die Unterklasse benutzt ihre Oberklasse dadurch, dass sie von ihr erbt.


Notation fur Module

<<Modul>>

A

+sichtbar

-unsichtbar

<<call>> <<Modul>>

B

+sichtbar

-unsichtbar

<<use>>

<<Modul>>

C

+sichtbar

-unsichtbar

<<call>>

Schnittstelle


Notation fur Module

<<Modul>>

A

+sichtbar

-unsichtbar

<<call>> <<Modul>>

B

+sichtbar

-unsichtbar

<<use>>

<<Modul>>

C

+sichtbar

-unsichtbar

<<call>>

Schnittstelle

20

09

-02

-09

Software-Projekt


Modulblickwinkel

Notation fur Module

Module sind ein etwas allgemeineres Konzept als Klassen. Klassen sind ein Konzept einer Programmiersprache unddes objektorientierten Paradigmas. Module konnen aber in C auch durch Dateien implementiert werden. Oft werdensie durch mehrere Dateien oder Klassen implementiert. Insofern hat das Konzept Modul seine Berechtigung.Weil Module aber Klassen ahneln, kann man fur sie auch eine ahnliche Notation verwenden. Im folgendenDiagramm verwenden wir den Stereotyp Modul um zu kennzeichnen, dass die Klassenikone als Module zuinterpretieren sind.

<<Modul>>

A

+sichtbar

-unsichtbar

<<call>> <<Modul>>

B

+sichtbar

-unsichtbar

<<use>>

<<Modul>>

C

+sichtbar

-unsichtbar

<<call>>

Schnittstelle

Die UML-Notation fur sichtbare und unsichtbare Elemente konnen zur Spezifikation der provides-Schnittstelleverwendet werden. Alternativ kann man auch auf die UML-Darstellungen fur Schnittstellen zuruck greifen. DerLolipop an Modul B besagt, dass B eine Schnittstelle zur Verfugung stellt, von der Modul C abhangt.


Beispiel einer Modulsicht

<<module>>

Comm<<module>>

Remote Imaging

<<module>>

dispatcher

sender receiver

Network

<<Layer>>

<<module>>

forwarder

<<module>>

receiver

<<Layer>>TCP/IP

<<module>>

sockets

+socket()

+bind()

+listen()

+accept()

+recvmsg()

+sendmsg()

<<module>>

wrapper



<<module>>

Comm<<module>>

Remote Imaging

<<module>>

dispatcher

sender receiver

Network

<<Layer>>

<<module>>

forwarder

<<module>>

receiver

<<Layer>>TCP/IP

<<module>>

sockets

+socket()

+bind()

+listen()

+accept()

+recvmsg()

+sendmsg()

<<module>>

wrapper

20

09

-02

-09

Software-Projekt


Modulblickwinkel


Als Beispiel fur eine Modulsicht verfeinern wir einen Aspekt der konzeptionellen Sicht unseres laufenden Beispielsder IS2000. Wir wenden uns hierzu der Komponente Comm der konzeptionellen Sicht zu. Ihre Aufgabe ist es, dieNetzwerkkommunikation zu realisieren.Das folgende Beispieldiagramm beschreibt diesen kleinen Ausschnitt:

<<module>>

Comm<<module>>

Remote Imaging

<<module>>

dispatcher

sender receiver

Network

<<Layer>>

<<module>>

forwarder

<<module>>

receiver

<<Layer>>TCP/IP

<<module>>

sockets

+socket()

+bind()

+listen()

+accept()

+recvmsg()

+sendmsg()

<<module>>

wrapper


<<module>>

Comm<<module>>

Remote Imaging

<<module>>

dispatcher

sender receiver

Network

<<Layer>>

<<module>>

forwarder

<<module>>

receiver

<<Layer>>TCP/IP

<<module>>

sockets

+socket()

+bind()

+listen()

+accept()

+recvmsg()

+sendmsg()

<<module>>

wrapper

20

09

-02

-09

Software-Projekt


Modulblickwinkel


Das Diagramm beschreibt, wie die Comm-Komponente den Netzwerkzugriff realisiert. Wir haben uns dazuentschlossen das Netzwerkprotokoll TCP/IP zu verwenden, um Daten uber das Internet auszutauschen. Da derDatentransfer zwischen einer heterogenen Rechnerlandschaft geschieht und deshalb Binardaten konvertiert werdenmussen, legen wir uber die TCP/IP-Schicht noch eine weitere Schicht, die das Ein- und Auspacken dertransferierten Daten vornimmt. Außerdem konnen wir auf diese Weise von TCP/IP abstrahieren und es bei Bedarfleicht gegen ein anderes Protokoll austauschen. Die Schicht Network wird sowohl von der IS2000 als auch vonanderen Prozessen, die auf entfernten Rechnern ausgefuhrt werden, verwendet (stellvertretend steht hierfur dasModule Remote Imaging). Die Schicht Network gliedert sich in ein Dispatcher-Modul, der die Verwaltung desSendens und Empfangens ubernimmt, und in ein Modul forwarder fur das Einpacken fur den Datenversand und einModul receiver fur das Entpacken der Daten. Letztere beiden Module mussen sich auf eine gemeinsameDatenreprasentation 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 eineansehnliche Anzahl von Modulen erhalten. Das Beispiel sollte deutlich machen, dass wir fur die gesamtekonzeptionelle Sicht eine große Anzahl von Modulen erhalten werden. Damit wir uns in diesem Abbildungsprozessverlieren, haben wir glucklicherweise die konzeptionelle Sicht, die alles zusammen halt und an der wir unsorientieren konnen.


Produktfaktoren


Einfluss


Code−Blickwinkel



Har

dwar

e−A

rchi

tekt

ur

globale Evaluation

− Ressourcenzuweisung

Ausführungsblickwinkel

Modulblickwinkel

Zentrale Entwurfs−aufgabe− Laufzeitelemente− Kommunikationspfade− Ausführungskonfiguration



Produktfaktoren


Einfluss


Code−Blickwinkel



Har

dwar

e−A

rchi

tekt

ur

globale Evaluation

− Ressourcenzuweisung

Ausführungsblickwinkel

Modulblickwinkel

Zentrale Entwurfs−aufgabe− Laufzeitelemente− Kommunikationspfade− Ausführungskonfiguration


20

09

-02

-09

Software-Projekt


Ausfuhrungsblickwinkel

Software ist primar Verhalten. Durch die Modulsicht wird aber nur der innere strukturelle Aufbau beschrieben. Imnachsten Schritt kummern wir uns um dynamische Aspekte, also Dinge, die zur Laufzeit relevant sind. Dazu bildenwir die Module auf Elemente der Ausfuhrungsplattform (sowohl Hardware als auch Software) ab. Dazu dient derAusfuhrungsblickwinkel.



beschreibt dynamische Aspekte

beschreibt, wie Module auf Elemente der Ausfuhrungs- undHardwareplattform abgebildet werden

definiert Laufzeitelemente und deren Attribute (Speicher- undZeitbedarf, Allokation auf Hardware)


Wie verlauft Kontroll- und Datenfluss zwischen Laufzeitkomponenten?

Wie kann Ressourcenverbrauch ausgewogen werden?

Wie konnen Nebenlaufigkeit, Replikation und Verteilung erreichtwerden, ohne die Algorithmen unnotig zu verkomplizieren?

Wie konnen Auswirkungen von Anderungen in derAusfuhrungsplattform minimiert werden?



beschreibt dynamische Aspekte

beschreibt, wie Module auf Elemente der Ausfuhrungs- undHardwareplattform abgebildet werden

definiert Laufzeitelemente und deren Attribute (Speicher- undZeitbedarf, Allokation auf Hardware)


Wie verlauft Kontroll- und Datenfluss zwischen Laufzeitkomponenten?

Wie kann Ressourcenverbrauch ausgewogen werden?

Wie konnen Nebenlaufigkeit, Replikation und Verteilung erreichtwerden, ohne die Algorithmen unnotig zu verkomplizieren?

Wie konnen Auswirkungen von Anderungen in derAusfuhrungsplattform minimiert werden?

20

09

-02

-09

Software-Projekt




Der Ausfuhrungsblickwinkel definiert die Laufzeitelemente und deren Attribute wie Speicher- und Zeitbedarf undAllokation auf Hardware. Wir beschreiben hierbei, welche Prozesse und Objekte existieren, wie sie miteinander zuAusfuhrungszeit kommunizieren und wie sie auf die ausfuhrende Hardware abgebildet werden.Die adressierten Belange des Ausfuhrungsblickwinkels sind damit:

• Wie verlauft der Kontroll- und Datenfluss zwischen den Laufzeitkomponenten (Prozesse, Objekte etc.)?

• Wie kann der Ressourcenverbrauch (Speicher, Rechenzeit etc.) ausgewogen werden?

• Wie konnen Nebenlaufigkeit, Replikation und Verteilung erreicht werden, ohne die Algorithmen unnotig zuverkomplizieren?

• Wie konnen Auswirkungen von Anderungen in der Ausfuhrungsplattform minimiert werden (also Anderungen derHardware)?


Ausfuhrungsblickwinkel (Hofmeister u. a. 2000)

SoftwarePlatform

PlatformElement

PlatformResource

HardwareResource

CommunicationPath

RuntimeEntity

CommunicationMechanism

Module

*

* * *

consumeconsume

* contain

is a

communicate over

*

1

use mechanism

assigned to

* 2..*

1

*

assigned to

*

*

*

* 1

*



SoftwarePlatform

PlatformElement

PlatformResource

HardwareResource

CommunicationPath

RuntimeEntity


Module

*

* * *

consumeconsume

* contain

is a

communicate over

*

1

use mechanism

assigned to

* 2..*

1

*

assigned to

*

*

*

* 1

*

20

09

-02

-09

Software-Projekt




Das folgende UML-Diagramm beschreibt den Ausfuhrungsblickwinkel:

SoftwarePlatform

PlatformElement

PlatformResource

HardwareResource

CommunicationPath

RuntimeEntity


Module

*

* * *

consumeconsume

* contain

is a

communicate over

*

1

use mechanism

assigned to

* 2..*

1

*

assigned to

*

*

*

* 1

*

Die Software-Plattform halt alle Aspekte der Ausfuhrung zusammen. Sie besteht zunachst aus Plattformelementen,dies sind Dinge, die zur Laufzeit angelegt werden und ausgefuhrt werden konnen (z.B. Prozesse; wir lernen weitereBeispiele weiter unten kennen).

Die Plattformelemente haben Instanzen, die Laufzeiteinheiten (Runtime Entity). Die Laufzeiteinheiten

kommunizieren uber 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.


SoftwarePlatform

PlatformElement

PlatformResource

HardwareResource

CommunicationPath

RuntimeEntity


Module

*

* * *

consumeconsume

* contain

is a

communicate over

*

1

use mechanism

assigned to

* 2..*

1

*

assigned to

*

*

*

* 1

*

20

09

-02

-09

Software-Projekt




Bei der Ausfuhrung konsumiert eine Laufzeiteinheit Laufzeitressourcen wie Speicher oder Rechenzeit.Auf der rechten Seite des Diagramms sehen wir die Einbettung in die Hardwareumgebung und in die statischeModulsicht. Module sind den Laufzeiteinheiten, die sie ausfuhren. Dabei kann ein Modul naturlich von vielenLaufzeiteinheiten verwendet werden. Durch diese Bezuge zur Modulsicht werden die beiden Sichten miteinanderverknupft.Die Plattformressourcen werden auf konkrete Hardware-Ressourcen abgebildet, die sie zur Verfugung stellen, wiebeispielsweise Prozessoren oder gemeinsamer Speicher.



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

IPC

RPC

...



Platform Element

Thread

Process

Task

Socket

Queue

File

Shared Memory

Shared Library

DLL

...

Platform Resource

CPU Time

Address Space

Memory

Semaphore

Timer

...


DCOM

IPC

RPC

...

20

09

-02

-09

Software-Projekt




Die Konzepte des Ausfuhrungsblickwinkels sind noch relativ abstrakt. Die folgende Vererbungshierarchiekonkretisiert die Konzepte. Ein Plattformelement ist eine Softwareeinheit, die zur Laufzeit existiert. Dazu gehorenzum Beispiel Objekte als Instanzen von Klassen. Fur die Realisierung von paralleler Ausfuhrung haben wir Threads(als leichtgewichtige Prozesse mit gemeinsamem Speicher), Prozesse mit getrennten Speicher oder Tasks (alseigenes Sprachkonstrukt aus einer Programmiersprache). Diese Prozesse kommunizieren uber weiterePlattformelemente wie Sockets, Warteschlangen, Dateien oder geteiltem Speicher. Außerdem kann man Modulebundeln in dynamischen Bibliotheken und auf unterschiedlichen Rechnern installieren.

Platform Element

Thread

Process

Task

Socket

Queue

File

Shared Memory

Shared Library

DLL

...

Platform Resource

CPU Time

Address Space

Memory

Semaphore

Timer

...


DCOM

IPC

RPC

...


Platform Element

Thread

Process

Task

Socket

Queue

File

Shared Memory

Shared Library

DLL

...

Platform Resource

CPU Time

Address Space

Memory

Semaphore

Timer

...


DCOM

IPC

RPC

...

20

09

-02

-09

Software-Projekt




Plattformressourcen sind Ressourcen, die uns von der Software- und Hardwareplattform zur Verfugung gestelltwerden, die von den Plattformelementen konsumiert werden, wahrend sie ihre Arbeit erledigen. Dazu gehohrenneben Speicher und CPU-Zeit Betriebsmittel fur die Synchronisation wie Semaphore oder Timer.Kommunikationsmechanismen schließlich dienen den Plattformelementen zum Nachrichtenaustausch. Unter demBetriebssystem Windows gibt es hierfur zum Beispiel DCOM. Plattformunabhangigere Mechanismen sind dieInterprozesskommunikation (IPC) oder der Remote Procedure Call (RPC), bei Java auch bekannt als RemoteMethod Invocation (RMI).


Beispiel einer Ausfuhrungssicht



20

09

-02

-09

Software-Projekt




Fur Diagramme, die die Ausfuhrungssicht beschreiben, gibt keine Standardnotation. Die Diagrammart in der UML,die der Ausfuhrungssicht am nachsten kommt, ist das Deployment-Diagramm. Es zeigt aber nicht alle Aspekte, dieim Ausfuhrungsblickwinkel nach Hofmeister u. a. (2000) moglich sind. Hofmeister u. a. (2000) schlagen deshalbeine eigene Notation vor, die an das Deployment-Diagramm der UML angelehnt ist. Das folgende Diagramm ist einBeispiel hierfur:


20

09

-02

-09

Software-Projekt




Wir erkennen darin drei Rechnertypen, die als Quader dargestellt sind. In ihnen geschachtelt tauchen dreiProzesstypen, die mit dem Stereotyp process gekennzeichnet sind. Die Schachtelung druckt aus, dass dergeschachtelte Prozess auf dem jeweiligen Rechner ausgefuhrt wird. Die Module, die die Prozesse dabei ausfuhren,sind in den Prozessen geschachtelt. Die Kommunikationspfade werden als Assoziationen zwischen den Prozessendargestellt. Die Beschriftung der Assoziation gibt den Kommunikationsmechanismus wieder. Die Multiplizitaten anden Kommunikationspfaden gibt an, wie viele Prozess jeden Typs in der Kommunikation involviert sind. In unseremFall ist das je eine n:1-Beziehungen, das heißt, mehrere Shop-Assistents kommunizieren mit einem Shop-Server undmehrere Shop-Server kommunizieren mit einem Datenbank-Server.Wie viele Instanzen es von den Typen von Hardware-Ressourcen und Plattformelementen zur Laufzeit gibt, wirddurch die Zahl in den Kasten wieder gegeben. Den Ladenrechner und Datenbankrechner gibt es nur einmal, es kannaber beliebig viele PDAs geben. Auf jedem PDA wird nur ein Prozess vom Typ Personal Shop Assistent gestartet.Gleiches gilt fur den Datenbankrechner, auf dem nur eine Instanz des Prozesstyps Data Base Server existiert. UmAusfallsicherheit und Skalierbarkeit zu sichern, hat sich der Architekt entschlossen, auf dem Ladenrechner nInstanzen von Shop Server anzulegen.


Produktfaktoren


Einfluss


− Build−Prozess− Konfigurations− management


globale Evaluation

Aus

führ

ungs

blic

kwin

kel

Har

dwar

e−A

rchi

tekt

ur


Code−Blickwinkel

Modulblickwinkel


Zentrale Entwurfs−aufgabe− Quellkomponenten

− Auslieferungskomp.− Zwischenprodukte


Produktfaktoren


Einfluss


− Build−Prozess− Konfigurations− management


globale Evaluation

Aus

führ

ungs

blic

kwin

kel

Har

dwar

e−A

rchi

tekt

ur


Code−Blickwinkel

Modulblickwinkel


Zentrale Entwurfs−aufgabe− Quellkomponenten

− Auslieferungskomp.− Zwischenprodukte

20

09

-02

-09

Software-Projekt


Code-Sicht

Nachdem wir Modulsicht und Ausfuhrungssicht entworfen haben, planen wir die konkrete Implementierung.Elemente aus der Modulsicht und Ausfuhrungssicht sind abstrakte Konzepte, die dann in einerProgrammiersprachen realisiert werden mussen. Dies geschieht, indem Programmierer Dateien anlegen, in denender Implementierungscode (textuell oder graphisch) aufgefuhrt ist. Wir nennen dies die Quellkomponenten. Ausden Quellkomponenten werden dann moglicherweise uber Zwischenprodukte das erzeugt, was schließlich als Codean den Kunden ausgeliefert wird. Beispielsweise haben wir unser Programm in C geschrieben. Dann erzeugt derCompiler daraus als Zwischenprodukt Objektdateien und moglicherweise Bibliotheken. Daraus erzeugt der Linkerschließlich das ausfuhrbare Programm. Das ausfuhrbare Programm und alle dynamischen Bibliotheken stellen dieAusfuhrungskomponenten dar. Da Dateien meist die Einheit sind, in der Aufgaben an Programmierer verteiltwerden, und die meisten Versionskontrollsysteme nur ganze Dateien verwalten, bestimmt die Aufteilung in Dateiendie Aufgabenverteilung und das Konfigurationsmanagement. Außerdem kann der Build-Prozess unter Umstandenbei großen Systemen, die nicht selten in vielen unterschiedlichen Programmiersprachen geschrieben wird, sehrkomplex werden. Der Build-Prozess benotigt nicht selten viel Zeit selbst auf machtiger Hardware. Aus diesenGrunden sollte fur mittlere und große Systeme die Abbildung der abstrakten Konzepte aus der Modulsicht undAusfuhrungssicht auf “anfassbare” Dateien und auch der Build-Prozess geplant und dokumentiert werden. Dies istdie Aufgabe der Code-Sicht.Bevor wir die Code-Sicht entwerfen, ist es moglicherweise notwendig, die globale Analyse nochmals zu wiederholen,wenn sich durch den Entwurf der vorherigen Sichten Einflussfaktoren und Strategien geandert haben sollten.


Code-Blickwinkel

bildet Laufzeiteinheiten auf installierbare Objekte (ausfuhrbareDateien, dynamische Link-Bibliotheken etc.) ab

bildet Module auf Quellkomponenten (Dateien) ab

zeigt, wie die installierbaren Dateien aus den Quellkomponentengeneriert werden


Wie kann die Zeit und der Aufwand fur Produkt-Upgrades verringertwerden?

Wie sollen Produktversionen verwaltet werden?

Wie kann die Build-Zeit verringert werden?

Welche Werkzeuge werden in der Entwicklungsumgebung benotigt?

Wie wird Integration und Test unterstutzt?


Code-Blickwinkel

bildet Laufzeiteinheiten auf installierbare Objekte (ausfuhrbareDateien, dynamische Link-Bibliotheken etc.) ab

bildet Module auf Quellkomponenten (Dateien) ab

zeigt, wie die installierbaren Dateien aus den Quellkomponentengeneriert werden


Wie kann die Zeit und der Aufwand fur Produkt-Upgrades verringertwerden?

Wie sollen Produktversionen verwaltet werden?

Wie kann die Build-Zeit verringert werden?

Welche Werkzeuge werden in der Entwicklungsumgebung benotigt?

Wie wird Integration und Test unterstutzt?

20

09

-02

-09

Software-Projekt


Code-Sicht

Code-Blickwinkel

Die Code-Sicht bildet die Laufzeiteinheiten auf installierbare Objekte (ausfuhrbare Dateien, dynamischeLink-Bibliotheken etc.) ab. Außerdem bildet sie Module auf Quellkomponenten (Dateien) ab und zeigt, wie dieinstallierbaren 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 fur Produkt-Upgrades verringert werden? Dazu mussen wir wissen, welcheausgelieferten Einheiten wir erneuern mussen. Im schlimmsten Fall muss der Kunde alles neu installieren. Dies wollen wiraber vermeiden.

• Wie sollen Produktversionen verwaltet werden? Unter Umstanden mussen wir nachvollziehen konnen, welche einzelnenDateien fur 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 fur die vollstandige Ubersetzung kann erheblich sein und damit dieEntwicklung stark hemmen. Bei großen Systemen kann es viele Stunden dauern, bis ein System vollstandig ubersetzt ist.Wir wollen deshalb die Abhangigkeiten zwischen den Dateien moglichst gering halten, um den Build-Prozess so kurz wiemoglich zu halten.

• Welche Werkzeuge werden in der Entwicklungsumgebung benotigt? In manchen Fallen konnen zum Beispiel Teile desCode automatisch generiert werden.

• Wie wird Integration und Test unterstutzt? Bei der inkrementellen Integration werden Systemteile sukzessivhinzugenommen und in ihrer Interaktion getestet. Dazu muss man den inneren Aufbau und die Abhangigkeiten aus derModulsicht kennen und wissen, welche Dateien dazu jeweils zu ubersetzen und zu testen sind.


Code-Blickwinkel (Hofmeister u. a. 2000)

RuntimeEntity

Interface

Module

Layer

SubsystemSoftwarePlatform

Executable ConfigurationDescriptionLibraryBinary

ComponentSource

Component

trace

trace

trace

trace

*

1 * 1 * * *

link

*

* 11 * *

0..1

0..1

0..1

0..1

*

*

* 1

*

*

*

*

*

*

* * * *

instantiate

link

compile

linkcompile

import

use at runtimegenerate



RuntimeEntity

Interface

Module

Layer



ComponentSource

Component

trace

trace

trace

trace

*

1 * 1 * * *

link

*

* 11 * *

0..1

0..1

0..1

0..1

*

*

* 1

*

*

*

*

*

*

* * * *

instantiate

link

compile

linkcompile

import


20

09

-02

-09

Software-Projekt


Code-Sicht


Code-Sichten werden durch den folgenden Code-Blickwinkel beschrieben:

RuntimeEntity

Interface

Module

Layer



ComponentSource

Component

trace

trace

trace

trace

*

1 * 1 * * *

link

*

* 11 * *

0..1

0..1

0..1

0..1

*

*

* 1

*

*

*

*

*

*

* * * *

instantiate

link

compile

linkcompile

import



RuntimeEntity

Interface

Module

Layer



ComponentSource

Component

trace

trace

trace

trace

*

1 * 1 * * *

link

*

* 11 * *

0..1

0..1

0..1

0..1

*

*

* 1

*

*

*

*

*

*

* * * *

instantiate

link

compile

linkcompile

import


20

09

-02

-09

Software-Projekt


Code-Sicht


Alles, was fur die Konstruktion des Systems notwendig ist, wird versammelt unter der Software-Plattform (SoftwarePlatform). Dazu gehoren primar die Quell-Komponenten (Source Component), die die Module und Schnittstellenimplementieren. Das sind in Java beispielsweise die Java-Quelldateien. Sie hangen zum Teil von einander ab, indemsie sich importieren. In Java gibt es dafur die import-Anweisung. Außer reinen Code-Dateien betrachten wir auchzum Beispiel UML-Diagramme als Quell-Komponenten, wenn aus ihnen Quell-Code generiert wird. DieQuell-Komponenten werden bei kompilierten Sprachen von einem Compiler in eine Binarform ubersetzt. In Java istdas der Java-Bytecode. Die Binardateien werden in einem weiteren Schritt oft in statischen oder dynamischenBibliotheken zusammen gefasst. In Java sind das die JAR-Bibliotheken. Ein Linker linkt die Binardateien undBibliotheken schließlich zu einem ausfuhrbaren Programm. Das Linken kann auch erst zum Zeitpunkt desProgramms stattfinden, dann spricht man von einem dynamischen Linker. Die ausfuhrbaren Programme konnenhaufig durch Konfigurationsdateien (Configuration Description) zur Start- oder Laufzeit konfiguriert werden.Beispielsweise kann die Sprache, in der mit dem Anwender kommuniziert wird, bei internationalisiertenProgrammen eingestellt werden.Auf der linken Seite des Diagramms zum Code-Blickwinkel finden wir Elemente des statischen Modulblickwinkelsund des Ausfuhrungsblickwinkels. 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 ermoglicht damit die Nachvollziehbarkeit (imEnglischen: Traceability) zwischen unterschiedlichen Ebenen eines Systems. Schichten und Subsysteme sind meistkeiner einzelnen Quell-Komponente zuzuordnen. Vielmehr bilden wir sie ab auf die Software-Plattform. Eine Schichtoder ein Subsystem implementiert damit eine Software-Plattform.Die Programme erzeugen (instantiate) wahrend ihrer Ausfuhrung die Laufzeiteinheiten (Runtime Entity).


Code-Blickwinkel: Beispiel



20

09

-02

-09

Software-Projekt


Code-Sicht


Das folgende Diagramm ist ein Beispiel fur eine Code-Sicht:

Die Modul dispatcher wird durch die Datei dispatcher.java implementiert. Das Modul wrapper sowie seineDie Teilmodule forwarder und receiver werden durch die Dateien forwarder.java und receiver.java umgesetzt. Daszusammengesetzte Modul wrapper wird nicht unmittelbar durch eine Quell-Komponente implementiert. Vielmehrbesteht es aus den oben genannten Teilmodulen, die bestimmten Quell-Komponenten zugeordnet sind.Hierarchische Module werden als reine Gliederungseinheiten verwendet. Die Moduldekomposition ergibt einenBaum. Nur die Blatter dieses Baumes stellen Module dar, fur die auch Code geschrieben werden muss.Die aus den Java-Dateien generierten Class-Dateien werden in einer JAR-Bibliothek fur den Server abgelegt. BeiAusfuhrung der Bibliothek, indem die entsprechende main-Methode aktiviert wird, wird dann der Server-Prozesserzeugt.


20

09

-02

-09

Software-Projekt


Code-Sicht


Das Modell von Hofmeister ist sehr stark an herkommlichen Sprachen wie C oder C++ orientiert. Im Falle vonJava 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 fur innere Klassen). Und die Package-Struktur korrespondiert mit der physischenDateisystem-Struktur.Die Bibliotheken in Java heißen JAR-Dateien (Java Archive; im Wesentlichen nichts anderes als ein Zip-Archiv mitJava-Class-Dateien). Die Class-Dateien werden nicht zu den Bibliotheken gelinkt, sondern lediglich hinzugefugt.Es gibt in Java eigentlich kein Exectuable wie bei C oder C++. Jede Klasse, die eine statische Methode main hat,kann zum Hauptprogramm werden. Enthalt eine JAR-Datei mindestens eine solche Klasse, kann sie als Executablebetrachtet werden. Eine JAR-Datei (oder auch eine Class-Datei) instantiates eine Runtime Entity, wenn ihr mainaufgerufen wird, oder wenn ein Thread aktiviert wird.



Tabellendarstellung:

Module Source File JAR

dispatcher dispatcher.java server.jarforwarder forwarder.java server.jarreceiver receiver.java server.jar. . . . . . . . .

JAR instantiates

server.jar Shop Server. . . . . .



Tabellendarstellung:

Module Source File JAR

dispatcher dispatcher.java server.jarforwarder forwarder.java server.jarreceiver receiver.java server.jar. . . . . . . . .

JAR instantiates

server.jar Shop Server. . . . . .

20

09

-02

-09

Software-Projekt


Code-Sicht


In der Praxis wird man kaum fur die in der Code-Sicht auftretenden Relationen ein UML-Diagramm zeichnen, da esviel zu viele sind. Einfacher beschreibt man sie durch Tabellen, wie zum Beispiel:

Module Source File JARdispatcher dispatcher.java server.jarforwarder forwarder.java server.jarreceiver receiver.java server.jar. . . . . . . . .

JAR instantiatesserver.jar Shop Server. . . . . .

Wenn Namenskonventionen existieren (im Falle von Java heißt die Class-Datei, die zu einer Java-Dateimyfile.java gehort, schlicht myfile.class, wenn es sich nicht um eine innere Klasse handelt) mussen nicht alleRelationen durch Tabellen beschrieben werden.


Was ist Modularisierung?

Definition

Modularisierung: Dekomposition eines Systems in Module.Modul: austauschbares Programmteil, das eine geschlosseneFunktionseinheit bildet.Arbeitspaket: von einer Person oder einer kleinen Gruppe von Entwicklernentwerfbar, implementierbar, testbar, verstehbar, anderbar, . . .



Conways Gesetz:

Conways Gesetz:

Die Struktur der Software spiegelt die Struktur der Organisation wider.



Schnittstellen

Definition

Schnittstelle (allgemein): Teil eines Systems, das dem Austausch vonInformationen, Energie oder Materie mit anderen Systemen dient.

– Wikipedia, die freie Enzyklopadie

Definition

Schnittstelle: Menge der Annahmen, die das Modul uber seine Umgebungmacht, sowie jene, die die Umgebung uber das Modul macht.

Definition

Syntaktische Schnittstelle: offentliche Attribute und Methoden mitderen Signaturen.

Zwei Module sind uber ihre Schnittstellen verbunden und damit abhangig.



Ein Wort zu Schnittstellen

+ Draw()

Figure

Rectangle

+ Draw()

Circle

+ Draw()+ width+ height + radius



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 v o i d Draw ( ) {} ;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 verlassenmuss Vorbedingungen einhalten

Anbieter:

muss zugesichertes Verhalten implementierendarf sich nur auf zugesicherte Vorbedingungen verlassen

Der Kontrakt fuhrt zu einer Kopplung zwischen Verwender und Anbieter.

Schnittstellen werden so entworfen, dass

Kopplung auf das Mindestmaß beschrankt wird;

d.h. die Details, die sich andern konnen, werden hinter Schnittstelleverborgen.



Programmiersprachenunterstutzung

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 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 u b l i c v o i d Draw ( ) {} ;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

Drawing+ Draw()

Figure

Rectangle

+ Draw()

Circle

+ Draw()



Klassendiagramm

Graphs

Node

+ Draw()

Edge

+ Draw()

Drawing+ Draw()

Figure

Rectangle

+ Draw()

Circle

+ Draw()



Klassendiagramm

Graphs

Node

+ Draw()

Edge

+ Draw()

Drawing

+ Draw()

Figure

Rectangle

+ Draw()

Circle

+ Draw()

Drawable



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 Drawab le 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 dieerlaubten wechselseitigen Annahmen festlegt

Programmiersprachen erlauben die Spezifikation syntaktischerEigenschaften von Schnittstellen

moderne Programmiersprachen bieten Schnittstellen als eigenesSprachkonstrukt an

nur wenige erlauben die Spezifikation semantischer Eigenschaften

Vor- und Nachbedingungenweitere Zusicherungen, wie z.B. Speicher- und Zeitkomplexitat



Kopplung und Zusammenhalt

Definition

Kopplung: Grad der Abhangigkeit zwischen Modulen.

Definition

Zusammenhalt (Koharenz): Verwandtschaft der Teile eines Moduls.

Modul A Modul B

Modul A Modul B



Definition

Kopplung: Grad der Abhangigkeit zwischen Modulen.

Definition

Zusammenhalt (Koharenz): Verwandtschaft der Teile eines Moduls.

Modul A Modul B

Modul A Modul B

20

09

-02

-09

Software-Projekt




Der Architekt eines Konzertsaals bemuht sich, den Saal so zu bauen, dass die akustische Storung von außen extremgering ist, die Horbarkeit im Saal dagegen extrem hoch. Dem entspricht bei der Arbeit des Software-Architekten dieGliederung in Module so, dass

• die Kopplung (d.h. die Breite und Komplexitat der Schnittstellen) zwischen den Modulen moglichst gering,

• der Zusammenhalt (d.h. die Verwandtschaft zwischen den Teilen eines Moduls) moglichst hoch wird.

Das Konzept von Kopplung und Zusammenhalt basiert ursprunglich auf den FORTRAN- und COBOL-Programmender fruhen 70‘er Jahre. Heute haben wir Sprachen, die uns mehrere Abstraktionsebenen bieten. Dabei streben wirauf der Modulebene vor allem niedrige Kopplung (bei maßigem Zusammenhalt), auf der Prozedurebene vor allemhohen Zusammenhalt (bei erheblicher Kopplung) an.


Stufen des Zusammenhalts (von schlecht nach gut)

Stufe innerhalb einer Funktion/Moduls betrifft

keinZusammenhalt

rein zufallige Zusammenstellung Module

Ahnlichkeit z.B. ahnlicher Zweck, also etwa alleMatrixoperationen; auchFehlerbehandlung

Module

zeitliche Nahe Verwendung zum selben Zeitpunkt,z.B. Initialisierung, Abschluss

Module,Funktionen

gemeinsameDaten

Zugriff auf bestimmte Daten,exklusiv, z.B. Kalenderpaket(Systemuhr)

Funktionen,Module

Hersteller /Verbraucher

ein Teil erzeugt, was der andereverwendet

Module,Funktionen

einziges Datum Kapselung einer Datenstruktur,Zusammenfassung der Operationen

Module,Funktionen

einzige Operation Operation, die nicht mehr zerlegbarist

Funktionen



Stufen der Kopplung (von schlecht nach gut)

Stufe zwischen Funktionen/Modulen betrifft

Einbruch Veranderung des Codes Funktionen

volle Offnung Zugriff auf alle Daten, z.B. auf alleAttribute einer Klasse

(Module)Funktionen

selektiveOffnung

bestimmte Attribute sind zuganglich oderglobal durch expliziten Export/Import

Module,Funktionen

Funktions-kopplung

nur Funktionsaufruf und Parameter Module(Funktion)

keineKopplung

Es besteht keine logische Beziehung(Zugriff ist syntaktisch unmoglich)

Module



Kriterien fur 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 leichterkennbaren Sinn haben.

Abstraktion: Implementierungsdetails verbergen

Kapselung von Dingen, die sich andern konnen (Geheimnisprinzip;Information Hiding)

Etwa gleich große Einheiten (Module, Funktionen). Abweichungensollten plausibel sein; generell durfen einfache Objekte großer sein alskomplizierte.



Kriterien fur einen guten Software-Entwurf (Forts.)

Uniforme Entwurfsstrategie; wenn z.B. eine Schichtenstruktur gewahltwurde, sollte sie nicht an irgendeiner Stelle korrumpiert sein.

Uniforme Gestaltung der Schnittstellen.

Uniforme Benennung.

Prinzip der Isomorphie zur Realitat (Michael Jackson11): Die Softwaresollte der Realitat strukturell gleichen, damit die Anderungen derRealitat in der Software leicht nachvollzogen werden konnen.

11Nein, nicht der Michael Jackson.Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 422 / 634


Bewertung von Modularisierung

Software Architecture Analysis Method (SAAM) (Kazman u. a. 1996):

1 Lege wichtige Qualitatsaspekte fest

2 Beschreibe alternative Modularisierungen

3 Entwickle Szenarien fur die Qualitatsaspekte

4 Spiele die Szenarien durch und bewerte die Modularisierungen

5 Betrachte Wechselwirkungen zwischen den Qualitatsaspekten

6 Fasse die Evaluation zusammen



Beispiel: Key Word in Context (KWIC) (Parnas 1972)

Bistum Osnabrück

Friede von Osnabrück

Friede westfälischer

Osnabrück Bistum

vonOsnabrück Friede

Friedevon Osnabrück

westfälischer Friede

Zeilen

Sortierung der


Friede westfälischer

Friede von Osnabrück

vonOsnabrück Friede

Friedevon Osnabrück

Bistum Osnabrück

Osnabrück Bistum

jeder Zeile

zyklische Vertauschung

von

Bistum Osnabrück


OsnabrückFriede



Betrachtete Qualitatsaspekte und Szenarien

Anderbarkeit

Eingabeformat andert sichgroßere Dateien mussen verarbeitet werdenriesige Dateien mussen verarbeitet werden

separate Entwickelbarkeit

verteile Arbeit an Entwicklungsteams

Performanz

berechne KWIC fur FB3-Webseiten



Ablauf

1 Eingabe der Daten

2 Interne Speicherung der Daten

3 Indizierung (Zeile, Wortanfang, Wortende)

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20

W e s t f ä l i s c h e r F r i e d e

F r i e d e v o n O s n a b r ü c k

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

(3, 12, 20)

(3, 8, 10)

(3, 1, 6)

(2, 8, 16)

(2, 1, 6)

(1, 15, 20)

(1, 1, 13)

4 Zyklische Rotation der Indizierung

5 Sortierung der Indizierung

6 Ausgabe der Indizierung



Erste Modularisierung (ablauforientiert)

<<Modul>>

Master Control

<<Modul>>

Input<<Modul>>

Shifter

<<Modul>>

Sorter

characters index sorted_index

<<Modul>>

Output

<<call>>

1.

<<call>> <<call>><<call>>

2. 3. 4.

<<use>><<set>><<use>>

<<use>>

<<set>>

<<use>> <<set>>

<<use>>

Eingabe Ausgabe

Wissen über Eingabeformat

Wissen über internes Datenformat

Wissen, dass alle Daten im Speicher sind



Qualitaten

Anderbarkeit:betroffene Module

Input Shifter Sorter Output

Eingabeformat ×großere Dateien × × × ×riesige Dateien × × × ×

Getrennte Entwicklung:

alle Datenstrukturen mussen bekannt sein

komplexe Beschreibung notwendig

Performanz:

schneller Zugriff auf globale Variablen



Geheimnisprinzip (Information Hiding) (Parnas 1972)

Definition

Geheimnisprinzip: Module verbergen alleImplementierungsentscheidungen, die sich andern konnen, hinter einerabstrakten Schnittstelle.



Zweite Modularisierung (objektbasiert)

. . . nach dem Geheimnisprinzip (Information Hiding) (Parnas 1972)

<<Modul>>

Master Control

<<Modul>>

Input

-Eingabeformat

<<Modul>>

Indexer

-zyklisches Schieben

<<Modul>>

Sorter

-Sortieralg.

<<Modul>>

Output

-Ausgabeformat

<<call>>

1.

<<call>><<call>>

<<call>>2.

3.

4.

<<call>>

Eingabe Ausgabe

<<Modul>>

Lines

-int. Speicherung

+add(c:char)

+<<interface>> Iteration()

+get(l:linenr,w:wordnr)

<<Modul>>

Index

-Indexstruktur

+add(l:linenr,w:wordnr)

+<<interface>> Iteration()

+swap(p1:pos,p2:pos)

<<call>><<call>> <<call>> <<call>>

<<call>>



Qualitaten

Anderbarkeit:betroffene Module

Input Lines Index Indexer Sorter Output

Eingabeformat ×großere Dateien ×riesige Dateien ×

Getrennte Entwicklung:

nur Schnittstellen mussen bekannt sein

Performanz:

zusatzliche Aufrufe



Abschließendes Wort zur Modularisierung

Es gibt viele Modularisierungsmoglichkeiten.

Jede ist gut fur einen Zweck, schlecht fur einen anderen.

Mit gangigen 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 vonSpeicherlochern etc.

Aspektorientierte Programmiersprachen erlauben eine separateBeschreibung dieser Aspekte und ein

”Einweben“ des Aspekts in das

System.




Was ist Software-Architektur und welche Bedeutung hat sie?

Welche Faktoren spielen eine Rolle fur die Architektur?

Erlautern Sie den Prozess von Hofmeister et al. zum Entwurf einerArchitektur (globale Analyse, Faktoren, Strategien,Blickwinkelentwurf).

Was ist ein Architekturblickwinkel bzw. eine Architektursicht?

Erlautern Sie die Blickwinkel von Hofmeister et al. Wer hat jeweils einInteresse an diesen Blickwinkeln?

Warum verschiedene Blickwinkel? Warum gerade diese vierBlickwinkel?

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 fur einen guten Architekturentwurf.

Wie lasst sich Architektur prufen? Erlautern Sie insbesondere SAAM.




Bass u. a. (2003) geben eine gute Ubersicht zu allen relevantenAspekten von Software-Architektur

Hofmeister u. a. (2000) beschreiben eine Methode fur denArchitekturentwurf, die auf vier verschiedenen Architektursichtenberuht

Shaw und Garlan (1996) geben eine Einfuhrung inSoftware-Architektur und beschreiben einige Architekturstile bzw.-muster


Architekturstile und Entwurfsmuster






WiederholungsfragenLernzieleModellbildungObjektorientierte ModellierungGeschaftsprozesseAnwendungsfalleUML-Notation fur AnwendungsfalleStatische Eigenschaften: KlassendiagrammeVerhaltenseigenschaftenInteraktionsdiagrammeSequenzdiagrammeKommunikationsdiagrammeAktivitatsdiagrammeZustandsautomatendiagrammeWiederholungsfragenMotivationLernzieleSoftware-PrufungenReviewsAblauf von ReviewsReview-RegelnReview-ChecklistenReview-VariantenFallen und GegenmittelWiederholungsfragenMotivationLernzieleErgonomiePsychologische und kognitive GrundlagenKommandosprachen versus GUIGeschichte graphischer BenutzungsschnittstellenInteraktionsmechanismenSoftware-ergonomische RichtlinienUsability messen und verbessernZusammenfassungWiederholungsfragenWas ist Software-Architektur?EinflussfaktorenArchitektursichten und -blickwinkelKonzeptioneller BlickwinkelModulblickwinkelAusfuhrungsblickwinkelCode-SichtModularisierungSchnittstellenKopplung und ZusammenhaltQualitatenBewertung von ArchitekturenWiederholungsfragen

9 Architekturstile und EntwurfsmusterWas ist ein Entwurfsmuster?Bestandteile eines EntwurfsmustersKategorien von EntwurfsmusternEntwurfsmuster Factory MethodEntwurfsmuster ObserverArchitekturstileArchitekturstil SchichtungArchitekturstil Model-View-ControllerWiederholungsfragenBegriffe des TestensSoziologie des TestensTestaktivitatenTestfallTeststumpfe und -treiberKomponententestsAquivalenztestKomponententest mit JUnitGrenztestPfadtestMaße der TestabdeckungZustandsbasiertes TestenIntegrationstestLeistungstestsZusammenfassung der TestartenTestmanagementTestplanTestfallspezifikationTestschadensberichtWiederholungsfragenMotivationArchitekturkonformitatProgrammierrichtlinienAnhangWiederholungsfragenLernzieleWas ist Benutzerdokumentation?Arten der DokumentationStrukturAuf Papier oder elektronisch?AutorWie schreibt man eine Dokumentation?Hinweise und RegelnWiederholungsfragenObjektorientierte ModellierungSoftwarearchitekturEntwurfsmuster und ArchitekturstileSoftwaretechnik im Allgemeinen



Lernziele

Verstehen, was Entwurfsmuster und Architekturstile sind

Qualitaten und Einsetzbarkeit der Entwurfsmuster/Architekturstilekennen



Kontext

Implemen−tierung

Test

Wartung& Evolution

Architektur

Datenstrukturen

und Algorithmen

AnalyseEntwurf



Entwurfsmuster

Each pattern describes a problem which occurs over and overagain in our environment, and then describes the core of thesolution to that problem, in such a way that you can use thissolution a million times over, without ever doing it the same waytwice.

Christopher Alexander (Architekt und Mathematiker),“A pattern language”, 1977.

Definition

Entwurfsmuster:”Musterlosung“ fur ein wiederkehrendes

Entwurfsproblem.



Bestandteile eines Entwurfsmusters

Name (kurz und beschreibend)

Problem: Was das Entwurfsmuster lost

Losung: Wie es das Problem lost

Konsequenzen: Folgen und Kompromisse des Musters



Beispielentwurfsproblem

Laufrad

+entfernen()

Felge

+entfernen()

Mantel

+entfernen()

Rahmen

+entfernen()

10..1

10..1

1

0..1

0..1

1..2

Artikel

+entfernen()

Rad

+entfernen()



Beschreibung von Mustern (Gamma u. a. 2003) I

Name: Composite

Zweck: Teil-von-Hierarchie mit einheitlicher Schnittstelle beschreiben(uberall wo ein Ganzes benutzt werden kann, kann auch ein Teilbenutzt werden und umgekehrt)

Motivation: . . . Einfuhrung anhand eines konkreten Beispiels. . .

Anwendbarkeit:

wenn Teil-von-Beziehung beschrieben werden solluniforme Schnittstelle fur alle Elemente der Hierarchie



Beschreibung von Mustern (Gamma u. a. 2003) II

Struktur:

for each c in children c.operation()

spezifischeErweiterungen

childrenClient

myElem+operation()

myComp+operation()

Composite

+add(component)+remove(component)+getChild(int)

+operation()

Leaf+operation()

operation()Component

+operation()




Teilnehmer:

Client:

manipuliert Objekte der Komponenten nur durch die Schnittstelle vonComposite

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 :

reprasentiert atomare Komponentedefiniert Verhalten fur 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 fur zusammengesetzte Komponentenspeichert Teileimplementiert Operationen zur Verwaltung von Teilen

i m p o r t j a v a . u t i l . L i s t ;i m p o r t 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 <Component> c h i l d r e n= new A r r a y L i s t <Component >() ;

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 Empfanger ein Leaf ist, antwortet es direkt

falls Empfanger ein Composite ist, wird die Anfrage an Teileweitergeleitet (moglicherweise mit weiteren eigenen Operationen vorund/oder nach der Weiterleitung)




Konsequenzen:

zweiteilt die Klassenhierarchie in Leaf und Composite miteinheitlicher Schnittstelle

uniforme Verwendung auf Seiten des Clients

neue Komponenten konnen leicht hinzugefugt werden

konnte die Struktur unnotig allgemein machen (dynamische versusstatische Typisierung)

Implementierung: . . . Hinweise zur Implementierung . . .



Dynamische versus statische Typisierung

Laufrad

+entfernen()

Felge

+entfernen()

Mantel

+entfernen()

Rahmen

+entfernen()

10..1

10..1

1

0..1

0..1

1..2

Artikel

+entfernen()

Rad

+entfernen()

Artikel

+entfernen()

+hinzufügen(Artikel)

+alleTeile(): list of Artikel

Behälter

+entfernen()

Blatt

+entfernen()

+hinzufügen(Artikel)

Mantel

+entfernen()

Rahmen

+entfernen()

Felge

+entfernen()

Laufrad

+entfernen()

Rad

+entfernen()

VerwenderTeile

for each t in Teile

t.entfernen()



Kategorien von Entwurfsmustern

Erzeugungsmuster

betreffen die Erzeugung von ObjektenBeispiel: Factory Method

Strukturelle Muster:

betreffen Komposition von Klassen und ObjektenBeispiel: Composite

Verhaltensmuster:

betreffen Interaktion und VerantwortlichkeitenBeispiel: Observer



Fahrradladenbeispiel: Erweiterung fur andere Domanen

Anforderungen:

Artikeldaten sollen von einer Datei gelesen werden konnen

zukunftig sollen andere Domanen unterstutzt werden (Fahrrad,Computer und Klettern)

die Objekte dieser Domanen sind unterschiedlich

notwendige Anpassungen sollen einfach realisiert werden konnen

Losungsstrategien:

die Klassen der Benutzungsschnittstelle beziehen sich nur auf dieSchnittstelle der abstrakten Klasse Artikel

Datei hat gleiche Syntax fur alle Domanen (nur die Inhalte variieren)

die Artikel werden beim Einlesen der Datei als Objekte erzeugt

→ aber der Leser muss doch die Konstruktoren der Objekte kennen, oderwas?



Losungsstrategie

FelgeRahmen

+ Preis()

Artikel

GUI

ComputerArtikel FahrradArtikel

+ lies(dateiname)

Leser

id=datei.liesId()

s.FabrikMethode(id)

+ Artikel FabrikMethode(id)

ArtikelSchopfer

+FabrikMethode(id)

FahrradSchopfer

+FabrikMethode(id)

ComputerSchopfer

if (id == ”rahmen”)return new Rahmen

if (id == ”felge”)return new Felge�create�

�create� �create�



Entwurfsmuster: Factory Method



Anwendbarkeit

eine Klasse weiß in manchen Fallen nicht im Voraus, von welcherKlasse ein zu erzeugendes Objekt sein soll

die konkreten Unterklassen einer Klasse sollen dies entscheiden

Verantwortlichkeit wird an Unterklassen delegiert, und das Wissenuber die Unterklasse, an die delegiert wird, soll nur an einem Punktvorhanden sein



Teilnehmer

Product

deklariert die Schnittstelle von Objekten, die die Fabrikmethodeerschafft

ConcreteProduct

implementiert die Product-Schnittstelle

Creator

deklariert die Fabrikmethode(optional) implementiert eine Standardfabrikmethode, die einspezifisches konkretes Objekt erzeugtkann Fabrikmethode aufrufen, um ein Product-Objekt zu erzeugen

ConcreteCreator

uberschreibt die Fabrikmethode, um konkretes Product-Objekt zuerschaffen



Entwurfsmuster Observer

Anwendbarkeit

Komponenten hangen von anderen Komponenten ab

Anderung der einen Komponente muss Anderung der anderen nachsich ziehen

Komponenten sollen lose gekoppelt sein: Komponente kennt seineAbhangigen nicht im Voraus (zur Ubersetzungszeit)

Losungsstrategie

Abhangige registrieren sich bei Komponente

Komponente informiert alle registrierten Abhangigen uberZustandsanderung



Entwurfsmuster Observer: Struktur



20

09

-02

-09

Software-Projekt


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 Verfugung, um Observer zu registrieren undabzutrennen

i m p o r t j a v a . u t i l . L i s t ;i m p o r t 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 <Observer> o b s e r v e r s= new A r r a y L i s t <Observer >() ;

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 fur 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 andert(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-Objektverarbeitet Zustand dieses Subjectsimplementiert Update, um auf veranderten 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 s t o p p e n ( 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

unterstutzt Rundfunk (Broadcast)

unerwartete Updates, komplizierter Kontrollfluss

viel Nachrichtenverkehr, auch dann wenn sich ein irrelevanter Aspektgeandert hat



Entwurfsmuster Observer: Verfeinerungen

Push-Modell

Subject sendet detaillierte Beschreibung der Anderung→ umfangreiches Update→ vermeidet GetState(), aber nicht Update()

Pull-Modell

Subject sendet minimale Beschreibung der Anderung→ Observer fragt gegebenfalls die Details nach→ erfordert weitere Nachrichten, um Details abzufragen

Explizite Interessen

Observers melden Interesse an spezifischem Aspekt an; Aspekt wirdzusatzlicher Parameter von Update



Architekturstile

Definition

Architekturstil: beschreibt eine Familie von Architekturen/Systeme alsein Muster der strukturellen Organisation durch

ein Vokabular (Komponenten- und Konnektorentypen)

und eine Menge von Einschrankungen, wie Komponenten undKonnektoren verbunden werden durfen.

Synonyme: Architekturmuster oder Architekturidiom.



Architekturstil: Schichtung

System−Software

Netzwerk

Anwendungslogik

Nutzungsoberfläche

Datenhaltung Utilities



Architekturstil: Schichtung I

Vokabular:

Komponenten: Module und SchichtenKonnektoren: Use-Beziehung

Struktur:

Module sind eindeutig einer Schicht zugeordnetModule einer Schicht durfen nur auf Module derselben und der direktdarunter liegenden Schicht zugreifen

Ausfuhrungsmodell:

Aufruf von Methoden tieferer SchichtenDatenfluss in beide Richtungen (von der unteren Schicht zur oberendurch Ruckgabeparameter)



Architekturstil: Schichtung II

Vorteile:

Schicht implementiert virtuelle Maschine, deren Implementierung leichtausgetauscht werden kann, ohne dass hohere Schichten geandertwerden mussen

Nachteile:

hoherer Aufwand durch das”Durchreichen“ von Information

Redundanz durch Dienste tieferer Schichten, die in hohen Schichtenbenutzt und auf allen Ebenen dazwischen repliziert werden



Anforderungen

Sonstige: 18%Mäntel: 43%Felgen: 23%Rahmen: 4%Sättel: 12%


Anforderungen

Sonstige: 18%Mäntel: 43%Felgen: 23%Rahmen: 4%Sättel: 12%

20

09

-02

-09

Software-Projekt


Architekturstil Model-View-Controller

Anforderungen

Unterschiedliche Diagrammarten stellen statistische Daten uber die nachgefragten Artikel dar. Die Diagrammemussen alle konsistent zu den aktuellen Daten sein. Neue Diagramme sollen leicht hinzugefugt werden konnen.


Model-View-Controller (Buschmann u. a. 1996)

Observer

update

Subject

an View (Anzeige) Model (Fachlogik) bzw. in Nachrichten an− übersetzt Eingaben eingaben− akzeptiert Benutzer−

Fachlogik− implementiert

Controller View

Model

GUI

− visualisiert Informationen über Model

− holt sich Information vom Model

und Controllers− registriert Views

Änderungüber− informiert Observer

1. register

2. display

3. getData

4. call service

5. update



Model-View-Controller Beispiel

Ein Model: Wert in festem Bereich

ProgressView

SliderView

Ein Controller: Verschiebung in SliderView verandert Model



Ein Model: Wert in festem Bereich

ProgressView

SliderView

Ein Controller: Verschiebung in SliderView verandert Model

20

09

-02

-09

Software-Projekt


Architekturstil Model-View-Controller


Dieses Beispiel und der Code dazu stammen von Thilo Mende. Ihm gilt mein Dank.


Beispiel-Model: Zustand

1 i m p o r t j a v a . u t i l . A r r a y L i s t ;2 i m p o r t j a v a . u t i l . L i s t ;3 i m p o r t j a v a x . swing . e v e n t . ChangeEvent ;4 i m p o r t 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 // Wer t ebe r e i ch :9 p r i v a t e f i n a l i n t min = 0 ; // un 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 ; // obe re Grenze11

12 // Zustand13 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 Obse rve r2 p r i v a t e L i s t <C h a n g e L i s t e n e r > o b s e r v e r s ;3

4 // Kont ruk to r5 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 <C h a n g e L i s t e n e r >() ;7 }8

9 // neuen Obse rve r r e g i s t r i e r e n10 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 // Benach r i c h t i gung a l l e r Obse rve r ;15 // au f z u r u f e n b e i a l l e n Zustands anderungen16 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 . s t a t e C h a n g e d ( 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 ge a nde r t17 }



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 s4

5 // In d i e s e r Va r i a n t e kennt de r C o n t r o l l e r s e i n e6 // 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 r7 // wi rd vom Hauptprogramm e t a b l i e r t8

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 i m p o r t j a v a x . swing . J P r o g r e s s B a r ;2 i m p o r t j a v a x . swing . e v e n t . ChangeEvent ;3 i m p o r t 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 ;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 r6 imp lements 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 r9 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 Model20 my model . a d d C h a n g e L i s t e n e r ( t h i s ) ;21 }22

23 // R e d e f i n i t i o n ; e r e r b t von ChangeL i s t ene r ;24 // e n t s p r i c h t update25 p u b l i c v o i d s t a t e C h a n g e d ( 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 }



Beispiel-ProgressView II

1 // R e d e f i n i t i o n ; e r e r b t von ChangeL i s t ene r ;2 // e n t s p r i c h t update3 p u b l i c v o i d s t a t e C h a n g e d ( ChangeEvent arg0 ) {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 Prog re s sV i ew



Beispiel-SliderView I

1 i m p o r t j a v a x . swing . J S l i d e r ;2 i m p o r t j a v a x . swing . e v e n t . ChangeEvent ;3 i m p o r t 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 ;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 r6 imp lements 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 r8 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 ChangeL i s t ene r ;11 // e n t s p r i c h t update12 p u b l i c v o i d s t a t e C h a n g e d ( ChangeEvent arg0 ) {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 // Kons t ruk to r2 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 Model8 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 ( ) {12 p u b l i c v o i d s t a t e C h a n g e d ( ChangeEvent arg0 ) {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 rV i ew



Beispiel-Hauptprogramm I

1 i m p o r t j a v a . awt . BorderLayout ;2 i m p o r t j a v a x . swing . JFrame ;3 i m p o r t 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 be i d en Views5 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 // Fen s t e r um a l l e s10 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 n16 ( 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 MVCDemoRainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 483 / 634


Wiederholungsfragen

Was ist ein Entwurfsmuster?

Warum sind sie interessant fur die Software-Entwicklung?

Erlautern Sie eines der in der Vorlesung vorgestellten Entwurfsmuster.

Was ist ein Architekturstil?

Nennen Sie Beispiele fur Architekturstile. Erlautern Sie die Stile.




Buschmann u. a. (1996) beschreiben Architekturstile bzw. -muster

Shaw und Garlan (1996) geben eine Einfuhrung inSoftware-Architektur und beschreiben einige Architekturstile bzw.-muster

Das Standardbuch zu Entwurfsmustern ist das von Gamma u. a.(2003)


Software-Test

Software-Test





WiederholungsfragenLernzieleModellbildungObjektorientierte ModellierungGeschaftsprozesseAnwendungsfalleUML-Notation fur AnwendungsfalleStatische Eigenschaften: KlassendiagrammeVerhaltenseigenschaftenInteraktionsdiagrammeSequenzdiagrammeKommunikationsdiagrammeAktivitatsdiagrammeZustandsautomatendiagrammeWiederholungsfragenMotivationLernzieleSoftware-PrufungenReviewsAblauf von ReviewsReview-RegelnReview-ChecklistenReview-VariantenFallen und GegenmittelWiederholungsfragenMotivationLernzieleErgonomiePsychologische und kognitive GrundlagenKommandosprachen versus GUIGeschichte graphischer BenutzungsschnittstellenInteraktionsmechanismenSoftware-ergonomische RichtlinienUsability messen und verbessernZusammenfassungWiederholungsfragenWas ist Software-Architektur?EinflussfaktorenArchitektursichten und -blickwinkelKonzeptioneller BlickwinkelModulblickwinkelAusfuhrungsblickwinkelCode-SichtModularisierungSchnittstellenKopplung und ZusammenhaltQualitatenBewertung von ArchitekturenWiederholungsfragenWas ist ein Entwurfsmuster?Bestandteile eines EntwurfsmustersKategorien von EntwurfsmusternEntwurfsmuster Factory MethodEntwurfsmuster ObserverArchitekturstileArchitekturstil SchichtungArchitekturstil Model-View-ControllerWiederholungsfragen

10 Software-TestBegriffe des TestensSoziologie des TestensTestaktivitatenTestfallTeststumpfe und -treiberKomponententestsAquivalenztestKomponententest mit JUnitGrenztestPfadtestMaße der TestabdeckungZustandsbasiertes TestenIntegrationstestLeistungstestsZusammenfassung der TestartenTestmanagementTestplanTestfallspezifikationTestschadensberichtWiederholungsfragenMotivationArchitekturkonformitatProgrammierrichtlinienAnhangWiederholungsfragenLernzieleWas ist Benutzerdokumentation?Arten der DokumentationStrukturAuf Papier oder elektronisch?AutorWie schreibt man eine Dokumentation?Hinweise und RegelnWiederholungsfragenObjektorientierte ModellierungSoftwarearchitekturEntwurfsmuster und ArchitekturstileSoftwaretechnik im Allgemeinen


Software-Test

Lernziele

Notwendigkeit und Grenzen des Tests verstehen

Arten und Varianten des Software-Tests kennen

eine geeignete Test-Strategie auswahlen konnen

Testplane erstellen konnen

Tests durchfuhren konnen

N.B.: Diese Darstellung folgt in weiten Teilen Kapitel 11 des Buchs vonBrugge und Dutoit (2004).


Software-Test

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 MonatUngue l t ig 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 MonatUnguelt ig , 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 MonatUngue l t ig ( ) ;r e t u r n anzTage ;

}}


Software-Test

Testen und seine Begriffe

Definition

Zuverlassigkeit: Maß fur den Erfolg, inwieweit das beobachtete Verhaltenmit dem spezifizierten ubereinstimmt.

Software-Zuverlassigkeit: Wahrscheinlichkeit, dass ein Software-Systemwahrend einer festgelegten Zeit unter festgelegten Bedingungen keinenSystemausfall verursachen wird (IEEE Std. 982-1989 1989).


Software-Test

Fehlerbegriff

Definition

Storfall (Ausfall, Failure): jegliche Abweichung des beobachtetenVerhaltens vom spezifizierten.

Im Nicht-Schaltjahr 200 wird fur den Monat Februar 29 ausgegeben.

Fehlerhafter Zustand (Error): Zustand, in dem ein Weiterlaufen desSystems zu einem Storfall fuhren wurde.

Die Funktion istSchaltjahr(200) liefert true.

Fehler (Defekt, Fault): mechanische oder algorithmische Ursache einesfehlerhaften Zustands.

Die Prufung in istSchaltjahr ist falsch.


Fehlerbegriff

Definition

Storfall (Ausfall, Failure): jegliche Abweichung des beobachtetenVerhaltens vom spezifizierten.

Im Nicht-Schaltjahr 200 wird fur den Monat Februar 29 ausgegeben.

Fehlerhafter Zustand (Error): Zustand, in dem ein Weiterlaufen desSystems zu einem Storfall fuhren wurde.

Die Funktion istSchaltjahr(200) liefert true.

Fehler (Defekt, Fault): mechanische oder algorithmische Ursache einesfehlerhaften Zustands.

Die Prufung in istSchaltjahr ist falsch.20

09

-02

-09

Software-Projekt

Software-Test

Begriffe des Testens

Fehlerbegriff

Mechanische Ursache: Fehler in der virtuellen Maschine (Plattform); z.B. Bug in Java-Virtual-Machine, Compileroder Hardwaredefekt.

Algorithmische Ursache: Fehler im Algorithmus, z.B. Off-by-One-Fehler, uninitialisierte Variable,

Performanzengpasse aufgrund eines schlechten Entwurfs.

Software-Test

Testen und seine Begriffe

Definition

Test: systematischer Versuch, in der implementierten Software Defekte zufinden.

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 istkorrekt”.

→ Aus negativem Test folgt noch lange nicht, dass kein Defektvorhanden ist.


Software-Test

Der Test und seine Verwandten

Tests sind nur ein Mittel, die Zuverlassigkeit zu steigern:

Fehlervermeidung (z.B. Entwicklungsmethoden, Verifikation, statischeAnalyse)

Fehlerentdeckung (z.B. Tests, assert, “Quality-Feedback-Agent”,Flugschreiber)

Fehlertoleranz: Behandlung von Fehlern zur Laufzeit, um Programmfortzusetzen


Software-Test

Soziologie des Testens

Testen wird haufig (aber zu unrecht) als niedere Arbeit angesehen

→ Frischlinge werden zu Testern

Tester brauchen jedoch ein umfassendes Systemverstandnis(Anforderungen, Entwurf, Implementierung)

Tester brauchen daruber hinaus, Wissen uber Pruftechniken

Autoren haben eine Lesart der Spezifikation verinnerlicht

Denkfehler in der Implementierung werden sich bei Erstellung vonTestfallen wiederholen

→ Tester sollten nicht gleichzeitig Autoren sein

Tester versuchen, Fehler zu finden

das Produkt wird kritisiert, dann fuhlen sich Autoren selbst kritisiert

→ Egoless-Programming (eine schone Illusion)


Software-Test

Testplan

Komponententest

Integrationstest

Strukturtest

Funktionstest

Leistungstest

Akzeptanztest

Installationstest

Benutzbarkeitstest

Feldtest

Normalbetrieb

Management-plan

Klassen-entwurf

Integrations-strategie

Subsystem-zerlegung

FunktionaleAnforderungen

NichtfunktionaleAnforderungen

Benutzungs-handbuch

Projekt-vereinbarung

Benutzungs-schnittstellen-

entwurf

Entwickler Kunde Benutzer


Testplan

Komponententest

Integrationstest

Strukturtest

Funktionstest

Leistungstest

Akzeptanztest

Installationstest

Benutzbarkeitstest

Feldtest

Normalbetrieb

Management-plan

Klassen-entwurf

Integrations-strategie

Subsystem-zerlegung

FunktionaleAnforderungen

NichtfunktionaleAnforderungen

Benutzungs-handbuch

Projekt-vereinbarung

Benutzungs-schnittstellen-

entwurf

Entwickler Kunde Benutzer

20

09

-02

-09

Software-Projekt

Software-Test

Testaktivitaten

Quelle: Brugge und Dutoit (2004)

• Testplanung: Betriebsmittelzuteilung und Zeitplan

• Benutzbarkeitstest: Fehler im Benutzerschnittstellenentwurf aufdecken; siehe (Papier-)Prototypen

• Komponententest: Fehler in einzelner Komponente (Klasse, Paket o.A.) aufdecken

• Integrationstest: Fehler im Zusammenspiel von Komponenten aufdecken

• Strukturtest: Integrationstest mit allen Komponenten (abschließender und vollstandiger Integrationstest)

• Systemtest: Test aller in einem System zusammengefasster Subsysteme mit dem Ziel, Fehler bezuglich der Szenarien ausder problemstellung sowie der Anforderungen und Entwurfsziele, die in der Analyse bzw. im Systementwurf identifiziertwurden, 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: Prufung bzgl. Projektvereinbarung durch den Kunden (evtl. mit der Hilfe der Entwickler)

Software-Test

Testfall

Ein Testfall besteht aus:

Name

Ort: vollstandiger Pfadname deslauffahigen Testprogramms

Eingabe: Eingabedaten oderBefehle

Orakel: erwarteteTestergebnisse, die mit denaktuellen Testergebnissen desTestlaufs verglichen werden

Protokoll: gesamte Ausgabe, diedurch Test erzeugt wird

Eingabe Ist-ErgebnisPrüfling

Vergleich Protokoll

Soll-Ergebnis


Software-Test

Komponententest: Teststumpfe und -treiber

Benutzerklasse X

Benutzte Klasse A Benutzte Klasse B

Prüfling C

Testtreiber

Benutzte Klasse A Teststumpf für benutzte Klasse B

Prüfling C

Benutzerklasse Y

spätere Umgebung Testumgebung



Benutzerklasse X

Benutzte Klasse A Benutzte Klasse B

Prüfling C

Testtreiber

Benutzte Klasse A Teststumpf für benutzte Klasse B

Prüfling C

Benutzerklasse Y

spätere Umgebung Testumgebung2

00

9-0

2-0

9

Software-Projekt

Software-Test

Teststumpfe und -treiber


Bestreben: Komponenten so fruh wie moglich testen.Problem: die benutzenden Komponenten und die benutzten Komponenten existieren moglicherweise noch nicht.Losung: Testtreiber und -stumpfe

• Prufling/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 Fallen: Aufwand fur Teststumpf entspricht Aufwand fur die eigentliche Komponente→Bottom-Up-Entwicklung der Komponenten

Software-Test

Typen von Komponententests

Definition

Black-Box-Tests: Komponente wird nur mit Kenntnis derSchnittstellenbeschreibung entworfen (Implementierung unbekannt).

Techniken:

Aquivalenztest

Grenztest

(zustandsbasierter Test)

. . .


Software-Test

Typen von Komponententests

Definition

White-/Glass-Box-Tests: Testfall wird mit Kenntnis der Implementierungentworfen.

Techniken:

Pfadtest

(zustandsbasierter Test)

. . .


Software-Test

Aquivalenztest I

Ziel: Testfalle minimieren.Idee:

Aquivalente Testfalle werden zusammengefasst.

Ein Testfall wird als Reprasentant der Aquivalenzklasse aufgestellt.

Kriterien:

Abdeckung: Jede mogliche Eingabe gehort zu einer derAquivalenzklassen

Disjunktion: Keine Eingabe gehort zu mehr als einer einzigenAquivalenzklasse

Reprasentation (die Hoffnung): Falls Ausfuhrung einen fehlerhaftenZustand anzeigt, sobald ein bestimmtes Mitglied einerAquivalenzklasse als Eingabe benutzt wird, dann kann derselbefehlerhafte Zustand entdeckt werden, wenn irgendein anderes Mitglieddieser Aquivalenzklasse als Eingabe verwendet wird


Software-Test

Aquivalenztest II

Fur jede Aquivalenzklasse werden mindestens zwei Testeingabenausgewahlt:

typische Eingabe, die den allgemeinen Fall abpruft

unvollstandige Eingabe, die auf korrektes Verhalten im Fehlerfall pruft


Software-Test

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 MonatUngue l t ig 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 MonatUnguelt ig , 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 MonatUngue l t ig ( ) ;r e t u r n anzTage ;

}}


Software-Test

Beispielspezifikation

Kalender.TageProMonat(monat,jahr) liefere die Tage eines Monatswie folgt:

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

Fehlerfall

monat < 1 ∨monat > 12⇒ throw MonatUngueltig

jahr < 0⇒ throw JahrUngueltig


Software-Test

Beispielaquivalenzklassen

Aquivalenzklassen:

fur Monate:

Monate mit 31 TagenMonate mit 30 TagenMonate mit 28 oder 29 Tagenmonat außerhalb gultigen Bereichs

fur Jahre:

SchaltjahreJahre, die keine Schaltjahre sindjahr außerhalb gultigen Bereichs

→ Kombination der Aquivalenzklassen fur alle Eingabeparameter ergibtAquivalenzklassen fur TageProMonat


Software-Test

Beispieltestfalle

Test der Interaktion von monat und jahr durch Kombination:

Aquivalenzklasse monat jahr Soll

31-Tage-Monat, Nicht-Schaltjahre 7 1901 3131-Tage-Monat, Schaltjahre 7 1904 31

30 Tage-Monat, Nicht-Schaltjahre 6 1901 3030 Tage-Monat, Schaltjahre 6 1904 30

Februar, Nicht-Schaltjahre 2 1901 28Februar, Schaltjahre 2 1904 29

monat inkorrekt, jahr korrekt 17 1901 MonatUngueltigmonat korrekt, jahr inkorrekt 7 -1901 JahrUngueltigmonat inkorrekt, jahr inkorrekt 17 -1901 MonatUngueltig

∨JahrUngueltig


Software-Test

Komponententest mit JUnit

i m p o r t j u n i t . f ramework . ∗ ;

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 ) ;}

}


Software-Test


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 ea 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 tt 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 ) {} // expec t edc a t c h ( K a l e n d e r . MonatUngue l t ig me) {} // expec t edc 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 ” ) ; }

}


Software-Test



Software-Test

Grenztest

Beobachtung: “Off-by-one”-Fehler kommen haufig vor.

Idee: Grenzen (Randbereiche) von Aquivalenzklassen 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.


Software-Test

Grenztest

Aquivalenzklasse monat jahr Soll

Schaltjahre teilbar durch 400 2 2000 29Nicht-Schaltjahre teilbar durch 100 2 1900 28

gultige Monate 1 2000 31gultige Monate 12 2000 31

Nichtpositive ungultige Monate 0 1234 MonatUngueltigPositive ungultige Monate 13 1234 MonatUngueltiggultiges Jahr 2 0 29gultiges Jahr 3 Max-Int 31

ungultiges Jahr 2 -1 JahrUngueltig


Software-Test

Pfadtest

Ziel: Testfalle sollten alle Code-Teile testen.

Idee: Konstruiere Testfalle, die jeden moglichen Pfad mindestens einmalausfuhren.

Ausgangspunkt: Kontrollflussgraph (KFG) pro Methode.

Knoten: Anweisungen und Pradikate

zwei weitere Knoten: eindeutiger Anfang und Ende einer Methode

Kanten: Kontrollfluss zwischen Anweisungen (unbedingt) undPradikaten (bedingt)

Pfad: Menge von Kanten, die vom Anfang zum Ende des KFGs fuhren


Software-Test

throw new JahrUngueltig

[jahr < 1]

n = 32[monat in {1,3,5,7,10,12}]

n = 30[monat in {4,6,9,11}]

[monat == 2]

throw new MonatUngueltig n = 29 n = 28

[istSchaltJahr(jahr)]

return n

Anfang

Ende

Aktivität

VerzweigungBedingung


Software-Test

Maße der Testabdeckung

C0, Anweisungsuberdeckung (Befehlsabdeckung/Statement-Coverage):Verhaltnis von Anzahl der mit Testdaten durchlaufenenAnweisungen zur Gesamtanzahl der Anweisungen.


[jahr < 1]

n = 32[monat in {1,3,5,7,10,12}]

n = 30[monat in {4,6,9,11}]

[monat == 2]



return n

Anfang

Ende

Aktivität




C0, Anweisungsuberdeckung (Befehlsabdeckung/Statement-Coverage):Verhaltnis von Anzahl der mit Testdaten durchlaufenenAnweisungen zur Gesamtanzahl der Anweisungen.


[jahr < 1]

n = 32[monat in {1,3,5,7,10,12}]

n = 30[monat in {4,6,9,11}]

[monat == 2]



return n

Anfang

Ende

Aktivität


20

09

-02

-09

Software-Projekt

Software-Test



Befehlsabdeckung / statement coverage / C0-Abdeckung: Gesucht ist eine Menge von Testfallen, die jeden Befehlin dem zu testenden Code mindestens einmal ausfuhren. Dieses Kriterium ist sehr schwach, denn es werden in derRegel nur sehr wenige Fehler (20%) gefunden. Fehler entstehen meist dadurch, dass Befehle in bestimmtenZustanden ausgefuhrt werden und nicht nur in irgendeinem.Ein Code-Coverage-Tool kann helfen, um zu sehen, welche Befehle nicht oder selten ausgefuhrt werden. Denn einnotwendiges Kriterium ist die Befehlsabdeckung allemal.

Software-Test


C1, Zweig-/Entscheidungsuberdeckung Verhaltnis von Anzahl der mitTestdaten durchlaufenen Zweige zur Gesamtanzahl derZweige.


[jahr < 1]

n = 32[monat in {1,3,5,7,10,12}]

n = 30[monat in {4,6,9,11}]

[monat == 2]



return n

Anfang

Ende

Aktivität




C1, Zweig-/Entscheidungsuberdeckung Verhaltnis von Anzahl der mitTestdaten durchlaufenen Zweige zur Gesamtanzahl derZweige.


[jahr < 1]

n = 32[monat in {1,3,5,7,10,12}]

n = 30[monat in {4,6,9,11}]

[monat == 2]



return n

Anfang

Ende

Aktivität


20

09

-02

-09

Software-Projekt

Software-Test



Jedes Pradikat 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 aquivalent zur Befehlsabdeckung, wenn jeder wahr/falsch-Fallauch mindestens einen Befehl beinhaltet. Dieses Kriterium ist weiterhin relativ schwach. Erfahrungsgemaß 25%Fehlerfindung.

Software-Test


C2, Bedingungsabdeckung Verhaltnis von Anzahl der mit Testdatendurchlaufenen Terme innerhalb von Entscheidungen zurGesamtanzahl der Terme.

i := 1 ;l o o p

found := a ( i ) = key ;e x i t when found o r i = M a x E n t r i e s ;i := i + 1 ;

end l o o p ;



C2, Bedingungsabdeckung Verhaltnis von Anzahl der mit Testdatendurchlaufenen Terme innerhalb von Entscheidungen zurGesamtanzahl der Terme.

i := 1 ;l o o p

found := a ( i ) = key ;e x i t when found o r i = M a x E n t r i e s ;i := i + 1 ;

end l o o p ;

20

09

-02

-09

Software-Projekt

Software-Test



Nur verschieden von C1, wenn logische Operatoren keine Short-Circuit-Operatoren sind (d.h. es werdengrundsatzlich alle Operanden eines logischen Operators ausgewertet).In jedem Pradikat wird jeder Bedingungsteil (Konjunktions- oder Alternationsglied) mindestens einmal wahr undeinmal falsch gesetzt.N.B.: Das umfasst nicht die Entscheidungsfallabdeckung:true and false→ false-Kantefalse 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.

Software-Test


C3, Abdeckung aller Bedingungskombinationen Verhaltnis von Anzahl dermit Testdaten durchlaufenen Bedingungskombinationen zurGesamtanzahl der Bedingungskombinationen.


[jahr < 1]

n = 32[monat in {1,3,5,7,10,12}]

n = 30[monat in {4,6,9,11}]

[monat == 2]



return n

Anfang

Ende

Aktivität




C3, Abdeckung aller Bedingungskombinationen Verhaltnis von Anzahl dermit Testdaten durchlaufenen Bedingungskombinationen zurGesamtanzahl der Bedingungskombinationen.


[jahr < 1]

n = 32[monat in {1,3,5,7,10,12}]

n = 30[monat in {4,6,9,11}]

[monat == 2]



return n

Anfang

Ende

Aktivität


20

09

-02

-09

Software-Projekt

Software-Test



Bedingungenkombinationsabdeckung / multiple condition coverage: Hier werden Pradikate gemaß einerWahrheitstabelle 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. ·

Software-Test


C4, Pfadabdeckung Verhaltnis von Anzahl der mit Testdatendurchlaufenen Pfade zur Gesamtanzahl der Pfade.


[jahr < 1]

n = 32[monat in {1,3,5,7,10,12}]

n = 30[monat in {4,6,9,11}]

[monat == 2]



return n

Anfang

Ende

Aktivität




C4, Pfadabdeckung Verhaltnis von Anzahl der mit Testdatendurchlaufenen Pfade zur Gesamtanzahl der Pfade.


[jahr < 1]

n = 32[monat in {1,3,5,7,10,12}]

n = 30[monat in {4,6,9,11}]

[monat == 2]



return n

Anfang

Ende

Aktivität


20

09

-02

-09

Software-Projekt

Software-Test



(Eingeschrankte) Pfadabdeckung: Hier werden auch bei Schleifen mehrere Durchlaufe gemacht (keinmal, einmal,zweimal, typische Anzahl, maximale Anzahl). In aller Regel wird nicht auf diese Weise getestet, da der Aufwandsehr groß ist.

Software-Test

Probleme beim Pfadtest

Unrealisierbare Pfade:

f o r ( i = 0 ; i < o . f o o ( ) ; i ++) // immer o . foo ( ) == 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??. . .

}


Software-Test

Polymorphismustest

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 ( ) ;

}}


Polymorphismustest

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 ( ) ;

}}

20

09

-02

-09

Software-Projekt

Software-Test


Polymorphismustest

Methode bar kann nicht in Isolation getestet werden. Welches foo im Beispiel ausgefuhrt wird, hangt vomdynamischen Typ von t ab. Davon hangen wiederum die weiteren Pfade ab.

Software-Test

Zustandsbasiertes Testen

Verhalten von Komponente hangt 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 {. . .} ;

}


Software-Test

Zustande eines Stacks


Software-Test


Fur alle Zustande einer Komponente:

Komponente wird in zu testenden Zustand gebracht

Test fur alle moglichen Stimuli:

korrekte Eingaben,fehlerhafte Eingabenund Aktionen, die Zustandsubergange bewirken


Software-Test

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 ta t e f u l lf 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 lf o r ( i n t i = 1 ; i <max ; i ++) {

l a s t = new Object ( ) ;s . push ( l a s t ) ;// e x c e p t i o n ( i f any ) w i l l be caught by JUn i t

}

// t e s t l e g a l a c t i o n ’ s i z e ’ ; no t r a n s i t i o na s s e r t E q u a l s (max , s . s i z e ( ) ) ;

// t e s t l e g a l a c t i o n ’ top ’ ; no t r a n s i t i o na s s e r t E q u a l s ( l a s t , s . top ( ) ) ;


Software-Test

Zustandsbasiertes Testen II

// t e s t l e g a l a c t i o n ’ i sEmpty ’ ; no t r a n s i t i o na s s e r t E q u a l s ( f a l s e , s . i sEmpty ( ) ) ;

// 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 ns . push ( new Object ( ) ) ;

}


Software-Test

Vergleich von White- und Black-Box-Tests

Black-Box-Tests (Funktionstests) betrachten den Prufling als schwarzeBox. Sie setzen keine Kenntnisse uber die Interna voraus.

White-Box-Tests (Strukturtests, Glass-Box-Tests) betrachten Interna desPruflings, um Testfalle zu entwickeln.

Eigenschaft Black-Box-Test White-Box-Test

Test auf Basis von Schnittstellen- Losungspezifikation

Wiederverwendung bei ja eingeschrankt

Anderung der Struktur

Geeignet fur Testart alle Komponententest

Finden Fehler aufgrund von Abweichung von Spez. eher Kodierfehler



Black-Box-Tests (Funktionstests) betrachten den Prufling als schwarzeBox. Sie setzen keine Kenntnisse uber die Interna voraus.

White-Box-Tests (Strukturtests, Glass-Box-Tests) betrachten Interna desPruflings, um Testfalle zu entwickeln.

Eigenschaft Black-Box-Test White-Box-Test

Test auf Basis von Schnittstellen- Losungspezifikation

Wiederverwendung bei ja eingeschrankt

Anderung der Struktur

Geeignet fur Testart alle Komponententest

Finden Fehler aufgrund von Abweichung von Spez. eher Kodierfehler

20

09

-02

-09

Software-Projekt

Software-Test



White-Box Methoden eignen sich lediglich fur den Modultest, allenfalls noch fur den Integrationstest. Die Idee istes, die Testfalle anhand der inneren Programmstruktur zu finden.Achtung: White-Box-Testing testet keine fehlenden Pfade oder Anweisungen. Das ist eine echte Schwache, denn eswird nur das getestet, woran der Programmierer auch wirklich (wenn auch evtl. fehlerhaft) gedacht hat!Black-Box-Tests konnen wiederverwendet werden, wenn sie die Struktur, aber nicht das Verhalten andert.

Software-Test

Black- versus White-Box-Tests

Nicht entweder-oder, sondern sowohl-als-auch!

Komplementare Verwendung:

1 Erstelle Funktionstest

2 Messe Abdeckung

3 Wenn Abdeckung nicht ausreichend; erganze durch Strukturtest;zuruck zu 2.


Software-Test

Strategien des Integrationstests I

Urknalltest: alle Komponenten werden einzeln entwickelt und dann ineinem Schritt integriert

→ erschwert Fehlersuche

Bottom-Up: Integration erfolgt inkrementell in umgekehrter Richtungzur Benutzt-Beziehung

→ keine Testrumpfe notwendig (aber Testtreiber)→ Fehler in der obersten Schicht werden sehr spat entdeckt; die enthalten

jedoch die Applikationslogik

Top-Down: Integration erfolgt in Richtung der Benutzt-Beziehung

→ Fehler in der obersten Schicht werden sehr fruh entdeckt→ Testrumpfe notwendig


Software-Test

Strategien des Integrationstests II

Sandwich-Test-Strategie: Kombination von Top-Down undBottom-Up

Identifikation der zu testenden Schicht: Zielschicht

zuerst: individuelle Komponententests

dann: kombinierte Schichttests:- Oberschichttest mit Zielschicht- Zielschicht mit Unterschicht- alle Schichten zusammen


Software-Test

Leistungstests

Hartetest: viele gleichzeitige Anfragen

Volumentest: große Datenmengen

Sicherheitstests: Sicherheitslucken aufspuren

Zeitvorgabentests: werden spezifizierte Antwortzeiten eingehalten?

Erholungstests: Tests auf Erholung von fehlerhaften Zustanden


Software-Test

Zusammenfassung der Testarten

Strategie:− Urknall− Top−Down− Bottom−Up− Sandwich

SystemtestIntegrationstestKomponententest

Äquivalenztest

Grenztest zustands−basierter Test

Pfadtest

White−Box−TestBlack−Box−Test

Härtetest

Leistungstest

Feldtest

Erholungstest

Zeitvorgabentest

Funktionstest Installationstest

Akzeptanztest

Sicherheitstest

Volumentest


Software-Test

Testdokumentation: Aufzeichnung der Testaktivitaten

Testplan: Projektplan furs Testen

Testfallspezifikation: Dokumentation eines jeden Testfalls

Testvorfallbericht (Testprotokoll): Ergebnisse des Tests undUnterschiede zu erwarteten Ergebnissen

Testubersicht: Auflistung aller Fehler (entdeckt und noch zuuntersuchen)

→ Analyse und Priorisierung aller Fehler und deren Korrekturen

Testplan und Testfallspezifikation konnen sehr fruh schon erstellt werden.


Software-Test

Testplan (IEEE Std. 829-1998 1998)

1. Einfuhrung

2. Beziehung zu anderen Dokumenten

3. Systemuberblick

4. Merkmale, die getestet/nicht getestet werden mussen

5. Abnahmekriterien

6. Vorgehensweise

7. Aufhebung und Wiederaufnahme

8. Zu prufendes Material (Hardware-/Softwareanforderungen)

9. Testfalle

10. Testzeitplan: Verantwortlichkeiten, Personalausstattung undWeiterbildungsbelange, Risiken und Schadensmoglichkeiten, Zeitplan



1. Einfuhrung

2. Beziehung zu anderen Dokumenten

3. Systemuberblick

4. Merkmale, die getestet/nicht getestet werden mussen

5. Abnahmekriterien

6. Vorgehensweise

7. Aufhebung und Wiederaufnahme

8. Zu prufendes Material (Hardware-/Softwareanforderungen)

9. Testfalle

10. Testzeitplan: Verantwortlichkeiten, Personalausstattung undWeiterbildungsbelange, Risiken und Schadensmoglichkeiten, Zeitplan2

00

9-0

2-0

9

Software-Projekt

Software-Test

Testplan


(Entspricht einer vereinfachten Variante von IEEE Std. 829-1998 (1998).)2.: Beziehung zu Anforderungsspezifikation und Architekturbeschreibung; Einfuhrung von Namenskonventionen, umTests und Anforderungen/Architektur in Beziehung zu setzen.

3.: Uberblick uber System hinsichtlich jener Komponenten, die durch Komponententests gepruft werden sollen.Granularitat der Komponenten und ihre Abhangigkeiten.4.: Konzentration auf funktionale Gesichtspunkte beim Testen; identifiziert alle merkmale und Kombinationen vonMerkmalen, die getestet werden mussen. Beschreibt auch diejenigen Merkmale, die nicht getestet werden und gibtGrunde dafur an.5.: Spezifiziert Abnahmekriterien fur die Tests (z.B. Testabdeckung).6.: Allgemeine Vorgehensweisen beim Testablauf; Integrationsstrategien.7.: Kriterien, wann Testaktivitaten ausgesetzt werden. Testaktivitaten, die wiederholt werden mussen, wenn dasTesten wieder aufgenommen wird.8.: Notwendige Betriebsmittel: physikalische Eigenarten der Umgebung sowie Anforderungen an Software,Hardware, Testwerkzeuge und andere Betriebsmittel (z.B. Arbeitsraum).9.: (das Herzstuck des Testplans) Auflistung aller Testfalle anhand individueller Testfallspezifikationen.

Software-Test

Testfallspezifikation

Testfallbezeichner: eindeutiger Name des Testfalls; am BestenNamenskonventionen benutzen

Testobjekte: Komponenten (und deren Merkmale), die getestetwerden sollen

Eingabespezifikationen: erwartete Eingaben

Ausgabespezifikationen: erwartete Ausgaben

Umgebungserfordernisse: notwendige Software- undHardware-Plattform sowie Testrumpfe und -stumpfe

Besondere prozedurale Anforderungen: Einschrankungen wieZeitvorgaben, Belastung oder Eingreifen durch den Operateur

Abhangigkeiten zwischen Testfallen


Software-Test

Testschadensbericht

welche Merkmale wurden getestet?

wurden sie erfullt?

bei Storfallen: wie konnen sie reproduziert werden?

→ Sammlung und Priorisierung in der Testubersicht→ Test 6= Fehlersuche bzw. -korrektur!


Software-Test


Erlautern Sie die Unterschiede in den Fehlerbegriffen Storfall,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 erfullen Teststumpfe und -treiber fur denKomponententest?

Was ist der Unterschied von Black- und Glass-Box-Tests?

Welche Techniken des Komponententests gibt es?

Erlautern Sie die Idee von Aquivalenztests am konkreten Beispiel.

Erlautern Sie die Idee von Grenztests am konkreten Beispiel.

Erlautern Sie die Idee von Pfadtests am konkreten Beispiel.


Software-Test


Wie benutzt man JUnit fur den Komponententest?

Wozu benotigt man Polymorphismustests?

Erlautern Sie die Idee von zustandsbasierten Tests am konkretenBeispiel.

Welche Testabdeckungsmaße gibt es?

Nennen Sie Strategien fur Integrationstests und diskutieren Sie sie.

Erlautern Sie Leistungstests.

Was ist ein Testplan?


Implementierung

Implementierung





WiederholungsfragenLernzieleModellbildungObjektorientierte ModellierungGeschaftsprozesseAnwendungsfalleUML-Notation fur AnwendungsfalleStatische Eigenschaften: KlassendiagrammeVerhaltenseigenschaftenInteraktionsdiagrammeSequenzdiagrammeKommunikationsdiagrammeAktivitatsdiagrammeZustandsautomatendiagrammeWiederholungsfragenMotivationLernzieleSoftware-PrufungenReviewsAblauf von ReviewsReview-RegelnReview-ChecklistenReview-VariantenFallen und GegenmittelWiederholungsfragenMotivationLernzieleErgonomiePsychologische und kognitive GrundlagenKommandosprachen versus GUIGeschichte graphischer BenutzungsschnittstellenInteraktionsmechanismenSoftware-ergonomische RichtlinienUsability messen und verbessernZusammenfassungWiederholungsfragenWas ist Software-Architektur?EinflussfaktorenArchitektursichten und -blickwinkelKonzeptioneller BlickwinkelModulblickwinkelAusfuhrungsblickwinkelCode-SichtModularisierungSchnittstellenKopplung und ZusammenhaltQualitatenBewertung von ArchitekturenWiederholungsfragenWas ist ein Entwurfsmuster?Bestandteile eines EntwurfsmustersKategorien von EntwurfsmusternEntwurfsmuster Factory MethodEntwurfsmuster ObserverArchitekturstileArchitekturstil SchichtungArchitekturstil Model-View-ControllerWiederholungsfragenBegriffe des TestensSoziologie des TestensTestaktivitatenTestfallTeststumpfe und -treiberKomponententestsAquivalenztestKomponententest mit JUnitGrenztestPfadtestMaße der TestabdeckungZustandsbasiertes TestenIntegrationstestLeistungstestsZusammenfassung der TestartenTestmanagementTestplanTestfallspezifikationTestschadensberichtWiederholungsfragen

11 ImplementierungMotivationArchitekturkonformitatProgrammierrichtlinienAnhangWiederholungsfragenLernzieleWas ist Benutzerdokumentation?Arten der DokumentationStrukturAuf Papier oder elektronisch?AutorWie schreibt man eine Dokumentation?Hinweise und RegelnWiederholungsfragenObjektorientierte ModellierungSoftwarearchitekturEntwurfsmuster und ArchitekturstileSoftwaretechnik im Allgemeinen


Implementierung

Lernziele

Feinentwurf eines Systems durchfuhren konnen

Programmierrichtlinien entwerfen, kennen und einhalten

Verstandnis fur Codequalitat entwickeln


Implementierung

Feinentwurf

Der Feinentwurf ist die Brucke zwischen abstrakter Architektur unddetailliertem Code.

Er legt fest:

Datenstrukturen

→ Klassendiagramme mit zusatzlichen Implementierungsdetails; (z.B.Navigierbarkeit, Implementierung von Assoziationen, Behandlung vonMehrfachvererbung oder weiteren Implementierungsklassen etc.)

Ablaufe

→ Zustandsautomaten→ Aktivitatsdiagramme→ Sequenzdiagramme


Implementierung

Architekturkonformitat

Architekturbeschreibung und Quellcode sind zwei voneinanderabhangige, aber separate Dokumente

in der Weiterentwicklung werden oft Anderungen im Quellcodegemacht, die in der Architekturbeschreibung nicht nachgezogenwerden

Folge: Architekturbeschreibung wird obsolet

Planung erfolgt aber meist auf Basis der Architekturbeschreibung

Folge: boses Erwachen in der Umsetzung

→ Reflektionsmethode von Murphy u. a. (1995, 2001) zurSynchronisation von Modulsicht und Quellcode


Implementierung

Reflektionsmethode (Murphy u. a. 2001)

1 Stelle Architekturmodell auf

2 Extrahiere Implementierungsmodell

3 Bilde Modelle aufeinander ab

4 Berechne Reflektionsmodell

5 Verfeinere/korrigiere

Beispiel

H3H2H1


Implementierung

Warum Programmierrichtlinien?

bis zu 80% der Gesamtkosten fur Software sind Wartungskosten

Originalautor wartet Software oft nicht selbst

Code muss lesbar und verstandlich sein


Implementierung

Programmierrichtlinien: Schlechte Beispiele

// i n k o n s i s t e n t e MethodennamenT 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 Pa r ame t e r s o r t i e r u ngS t r i n g B u f f e r . s e t C h a r A t ( i n t index , c h a r c ) ;V e c t o r . 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 = myStr ing . l e n g t h ( ) ;myL i s t . s i z e ( ) ;


Implementierung

Programmierrichtlinien: Sinnvolle Namen

// S i n n l o s e Namens 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 rs 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 ;


Implementierung

Programmierrichtlinien: Lokale Variablen

// Man kann ’ s auch u 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 < maxOuter Index ;

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 => ku r ze Namenf o r ( i n t i = 0 ; i < max ; i ++){

f o r ( i n t j = 0 ; j < i ; j ++){

r e s u l t [ i ] [ j ] = i ∗ j ;}

}


Implementierung

Ausdrucke in naturlicher Form

// schwer v e r s t a n d l i c h e r Ausdrucki 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 ri 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 ) )


Implementierung

Magische Zahlen

// Wer v e r s t e h t d i e s e Zah len ?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 ;...m inutes = 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 ;


Implementierung

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 . ” ) ;

}


Implementierung

Character sind zwar Zahlen, aber...

// Wie b i t t e ?i f ( ( c >= 65) && ( c <= 90) ). . .

i f ( ( c >= ’A ’ ) && ( c <= ’Z ’ ) ). . .

// Ach so !i f ( C h a r a c t e r . i s U p p e r C a s e ( c ) )


Implementierung

Sprachkonstrukte zur Berechnung von Großen

// Doppe l te Z a h l e n r e f e r e n zc h a r buf [ ] = new c h a r [ 1 0 2 4 ] ;f o r ( i n t i = 0 ; i < 1 0 2 4 ; 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 ++)


Implementierung

Uberflussige Kommentare

/∗∗ d e f a u l t∗/

d e f a u l t :b r e a k ;

/∗ r e t u r n SUCCESS ∗/r e t u r n SUCCESS ;

zeroCount++: /∗ I nc r ement z e r o e n t r y coun t e r ∗/

/∗ I n i t i a l i z e t o t a l to numberRece ived . ∗/Node . t o t a l = Node . numberRece ived ;


Implementierung

Uberflussige Kommentare

w h i l e ( ( ( c = getChar ( ) ) != EOF) && ( i s S p a c e ( c ) ) ); /∗ s k i p wh i t e space ∗/

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 em i co l on ∗/t y p e = SEMICOLON ;

e l s e i f ( i sOp ( c ) ) /∗ op 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;. . .


Implementierung

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 ){ ;}


Implementierung

idKldW

i n t f ( i n t f [ ] , i n t l , I tem 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 Kurze liegt die Wurze (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 , I tem 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 ;

}


Implementierung

Software-Redundanz

for (j = 1; j < MAX; j++) { x = func() * y + x;}

for (i = 1; i < MAX; i++) { x = func() * y + x;} for (i = 1; i < MAX; i++) {

x = func() * y + x;}

for (i = 1; i < MAX; i++) { x2 = func() * y2 + x2;}

for (i = 1; i < MAX; i++) { x1 = func() * y1 + x1;}

...

...

...

...

...

......

...

foo.c bar.c fred.c

Typisch: 5 – 30 % des Codes sind redundant. . .


Implementierung

Software-Redundanz

for (i = 1; i < MAX; i++) { *x = func() * y + *x;}

}

float *x, float y) {void set_coordinate (

int i;

...

...

......

...

......

...

set_coordinate (&x, y);

set_coordinate (&x, y);

set_coordinate (&x, y);set_coordinate (&x1, y1);

set_coordinate (&x2, y2);

foo.c bar.c fred.c

. . . und konnen abstrahiert werden


Implementierung


Implementierung

Uberlange Methoden

//// 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);

Mai 31, 05 7:18 Seite 1/12b.cppGedruckt von Rainer Koschke

Dienstag Mai 31, 2005 1/12

} else if (cond) { EmitBranchIfExpression(conditional −> test_expression, true,

75 lab, over); EmitBranchIfExpression(conditional −> false_expression, true, lab, over); } else

80 { Label skip; EmitBranchIfExpression(conditional −> test_expression, true, skip, over); EmitBranchIfExpression(conditional −> false_expression, false,

85 lab, over); DefineLabel(skip); CompleteLabel(skip); } }

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); } else if (IsZero(conditional −> false_expression)) { 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; EmitBranchIfExpression(conditional −> test_expression, true, skip, over);

120 EmitBranchIfExpression(conditional −> false_expression, true, lab, over); DefineLabel(skip); CompleteLabel(skip); }

125 } else if (IsOne(conditional −> false_expression)) { // // branch_if(expr?a:true, c, l) => branch_if(!expr || a, c, l);

130 // if (cond) { EmitBranchIfExpression(conditional −> test_expression, false, lab, over);

135 EmitBranchIfExpression(conditional −> true_expression, true, lab, over); } else {

140 Label skip;


2/12 Dienstag Mai 31, 2005

EmitBranchIfExpression(conditional −> test_expression, false, skip, over); EmitBranchIfExpression(conditional −> true_expression, false, lab, over);

145 DefineLabel(skip); CompleteLabel(skip); } } else if (IsZero(conditional −> false_expression))

150 { // // branch_if(expr?a:false, c, l) => branch_if(expr && a, c, l); // if (! cond)

155 { EmitBranchIfExpression(conditional −> test_expression, false, lab, over); EmitBranchIfExpression(conditional −> true_expression, false, lab, over);

160 } else { Label skip; EmitBranchIfExpression(conditional −> test_expression, false,

165 skip, over); EmitBranchIfExpression(conditional −> true_expression, true, lab, over); DefineLabel(skip); CompleteLabel(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 {



// // 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) EmitBranch(OP_GOTO, lab, over); } 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) EmitBranch(OP_GOTO, lab, over);

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) EmitBranch(OP_GOTO, lab, over); }

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);



// if (left −> IsConstant()) { if (IsOne(left))

285 EmitBranchIfExpression(right, cond, lab, over); else if (! cond) EmitBranch(OP_GOTO, lab, over); } //

290 // branch_if(a&&true, cond, lab) => branch_if(a, cond, lab); // branch_if(a&&false, cond, lab) => emit(a), pop; for side effects // else if (right −> IsConstant()) {

295 if (IsOne(right)) EmitBranchIfExpression(left, cond, lab, over); else { EmitExpression(left, false);

300 if (! cond) EmitBranch(OP_GOTO, lab, over); } } //

305 // branch_if(a&&b, true, lab) => // branch_if(a,false,skip); // branch_if(b,true,lab); // skip: // branch_if(a&&b, false, lab) =>

310 // branch_if(a,false,lab); // branch_if(b,false,lab); // else if (cond) {

315 Label skip; EmitBranchIfExpression(left, false, skip, over); EmitBranchIfExpression(right, true, lab, over); DefineLabel(skip); CompleteLabel(skip);

320 } else { EmitBranchIfExpression(left, false, lab, over); EmitBranchIfExpression(right, false, lab, over);

325 } return; case AstBinaryExpression::OR_OR: // // branch_if(false||b, cond, lab) => branch_if(b, cond, lab);

330 // branch_if(true||b, cond, lab) => branch_if(true, cond, lab); // if (left −> IsConstant()) { if (IsZero(left))

335 EmitBranchIfExpression(right, cond, lab, over); else if (cond) EmitBranch(OP_GOTO, lab, over); } //

340 // branch_if(a||false, cond, lab) => branch_if(a, cond, lab); // branch_if(a||true, cond, lab) => emit(a), pop; for side effects // else if (right −> IsConstant()) {

345 if (IsZero(right)) EmitBranchIfExpression(left, cond, lab, over); else { EmitExpression(left, false);

350 if (cond)



EmitBranch(OP_GOTO, lab, over); } } //

355 // branch_if(a||b,true,lab) => // branch_if(a,true,lab); // branch_if(b,true,lab); // branch_if(a||b,false,lab) => // branch_if(a,true,skip);

360 // branch_if(b,false,lab); // skip: // else if (cond) {

365 EmitBranchIfExpression(left, true, lab, over); EmitBranchIfExpression(right, true, lab, over); } else {

370 Label skip; EmitBranchIfExpression(left, true, skip, over); EmitBranchIfExpression(right, false, lab, over); DefineLabel(skip); CompleteLabel(skip);

375 } return; case AstBinaryExpression::XOR: // ^ on booleans is equavalent to != assert(left_type == control.boolean_type); // Fallthrough!

380 case AstBinaryExpression::EQUAL_EQUAL: case AstBinaryExpression::NOT_EQUAL: // // One of the operands is null. We must evaluate both operands, to get // any side effects in (expr ? null : null).

385 // if (left_type == control.null_type || right_type == control.null_type) { EmitExpression(left, left_type != control.null_type); EmitExpression(right, right_type != control.null_type);

390 if (left_type == right_type) { if (cond == (bp −> Tag() == AstBinaryExpression::EQUAL_EQUAL)) { EmitBranch(OP_GOTO, lab, over);

395 } } else { if (bp −> Tag() == AstBinaryExpression::EQUAL_EQUAL)

400 EmitBranch(cond ? OP_IFNULL : OP_IFNONNULL, lab, over); else EmitBranch(cond ? OP_IFNONNULL : OP_IFNULL, lab, over); } return; }

405

// // One of the operands is true. Branch on the other. // if (left_type == control.boolean_type &&

410 (IsOne(left) || IsOne(right))) { EmitBranchIfExpression(IsOne(left) ? right : left, cond == (bp −> Tag() == AstBinaryExpression::EQUAL_EQUAL), lab, over);

415 return; }

// // Both operands are integer.



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() != AstBinaryExpression::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); EmitExpression(right);

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);



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) EmitBranch(OP_GOTO, lab, over);

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) EmitBranch(OP_GOTO, lab, over); 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 { case AstBinaryExpression::LESS: case AstBinaryExpression::LESS_EQUAL: case AstBinaryExpression::GREATER: case AstBinaryExpression::GREATER_EQUAL:

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;



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)) { EmitExpression(right);

570 switch (bp −> Tag()) { 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 <= x) same as if (x >= 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 <= 0) op_true = OP_IFLE;

590 op_false = OP_IFGT; break; default: assert( false); break;

595 } } else if (IsZero(right)) { EmitExpression(left);

600

switch (bp −> Tag()) { case AstBinaryExpression::LESS: op_true = OP_IFLT;

605 op_false = OP_IFGE; break; case AstBinaryExpression::LESS_EQUAL: op_true = OP_IFLE; op_false = OP_IFGT;

610 break; case AstBinaryExpression::GREATER: op_true = OP_IFGT; op_false = OP_IFLE; break;

615 case AstBinaryExpression::GREATER_EQUAL: op_true = OP_IFGE; op_false = OP_IFLT; break; default:

620 assert( false); break; } } else

625 { EmitExpression(left); EmitExpression(right);



switch (bp −> Tag())630 {

case AstBinaryExpression::LESS: 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; case AstBinaryExpression::GREATER:

640 op_true = OP_IF_ICMPGT; op_false = OP_IF_ICMPLE; break; case AstBinaryExpression::GREATER_EQUAL: 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); EmitExpression(right);

opcode = OP_LCMP;

660 // // branch according to result value on stack // switch (bp −> Tag()) {

665 case AstBinaryExpression::EQUAL_EQUAL: op_true = OP_IFEQ; op_false = OP_IFNE; break; case AstBinaryExpression::NOT_EQUAL:

670 op_true = OP_IFNE; op_false = OP_IFEQ; break; case AstBinaryExpression::LESS: op_true = OP_IFLT;

675 op_false = OP_IFGE; break; case AstBinaryExpression::LESS_EQUAL: op_true = OP_IFLE; op_false = OP_IFGT;

680 break; case AstBinaryExpression::GREATER: op_true = OP_IFGT; op_false = OP_IFLE; break;

685 case AstBinaryExpression::GREATER_EQUAL: op_true = OP_IFGE; op_false = OP_IFLT; break; default:

690 assert( false); break; } } else if (left_type == control.float_type)

695 { EmitExpression(left); EmitExpression(right);



switch (bp −> Tag())700 {

case AstBinaryExpression::EQUAL_EQUAL: opcode = OP_FCMPL; op_true = OP_IFEQ; op_false = OP_IFNE;

705 break; case AstBinaryExpression::NOT_EQUAL: opcode = OP_FCMPL; op_true = OP_IFNE; op_false = OP_IFEQ;

710 break; case AstBinaryExpression::LESS: opcode = OP_FCMPG; op_true = OP_IFLT; op_false = OP_IFGE;

715 break; case AstBinaryExpression::LESS_EQUAL: opcode = OP_FCMPG; op_true = OP_IFLE; op_false = OP_IFGT;

720 break; case AstBinaryExpression::GREATER: opcode = OP_FCMPL; op_true = OP_IFGT; op_false = OP_IFLE;

725 break; case AstBinaryExpression::GREATER_EQUAL: opcode = OP_FCMPL; op_true = OP_IFGE; op_false = OP_IFLT;

730 break; default: assert( false); break; }

735 } else if (left_type == control.double_type) { EmitExpression(left); EmitExpression(right);

740 switch (bp −> Tag()) { case AstBinaryExpression::EQUAL_EQUAL: opcode = OP_DCMPL; op_true = OP_IFEQ;

745 op_false = OP_IFNE; break; case AstBinaryExpression::NOT_EQUAL: opcode = OP_DCMPL; op_true = OP_IFNE;

750 op_false = OP_IFEQ; break; case AstBinaryExpression::LESS: opcode = OP_DCMPG; op_true = OP_IFLT;

755 op_false = OP_IFGE; break; case AstBinaryExpression::LESS_EQUAL: opcode = OP_DCMPG; op_true = OP_IFLE;

760 op_false = OP_IFGT; break; case AstBinaryExpression::GREATER: opcode = OP_DCMPL; op_true = OP_IFGT;

765 op_false = OP_IFLE; break; case AstBinaryExpression::GREATER_EQUAL: opcode = OP_DCMPL;



op_true = OP_IFGE;770 op_false = OP_IFLT;

break; default: assert(false); break;

775 } } else assert(false && "comparison of unsupported type");

if (opcode != OP_NOP)780 PutOp(opcode); // if need to emit comparison before branch

EmitBranch (cond ? op_true : op_false, lab, over);}




Implementierung

Ignoranz, Not-Invented-Here-Syndrom oder dieneuerfundenen Rader

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 i tem ;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 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 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 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 ( ) { . . . }

}


Implementierung

Die Oglala des 21. Jahrhunderts

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 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 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ßzugigkeit) sind ein Stamm der Lakota-Sioux-Indianer.


Implementierung

Prinzipien

einheitlich

so einfach wie moglich

sprechend, direkt verstandlich

pragnant

frei von Redundanz

ubersichtlich

strukturiert

abgeschlossen

abstrakt

Separation of Concerns


Implementierung

Was alles in den Code-Inspektionen 2004/05 auffiel

Verwendung von verketteten Listen, wo Maps angebracht waren;manuelle Implementierung der entsprechenden Map-Zugriffe

Verwendung von verketteten Listen, wo ArrayList angebrachter ware;z.B. Iterieren durch die LinkedList uber Indexzugriffe...

alle Methoden einer Klasse static; die statischen Variablen werdenuber den Konstruktor initialisiert

alle Methoden einer Klasse static, die Instanz, auf der die Methodenarbeiten, werden z.B. als LinkedList jeweils ubergeben

Neuimplementierung von Sortieralgorithmen

die gesamte GUI wird in einer einzigen Klasse implementiert

Datenbankzugriffe werden uber alle Klassen verteilt, statt gekapselt


Implementierung

Was alles in den Code-Inspektionen 2004/05 auffiel

Query wird mit select * gemacht, danach werden manuell diebenotigten Spalten rausgefiltert

Datenbanknamen usw. werden hartcodiert

manuelle Implementierung von Parsern fur verschiedene Zwecke (woz.B. XML oder Properties-Datei angebracht ware)

mehrfache Implementierung der gleichen Hilfsklassen vonverschiedenen Leuten, z.B. Ubersetzungen (dementsprechend auchmit verschiedenen Dateiformaten)

keine Berucksichtigung von Performance (z.B. bei Operationen aufverketteter Liste, Dateioperationen; Konfigurationsdatei wird beijedem Methodenaufruf neu eingelesen)


Implementierung

Wiederholungsfragen

Was sind Refactorings und Bad Smells?

Wie wird Refactoring durchgefuhrt?

Nennen Sie Beispiele fur Bad Smells.


Benutzerdokumentation






WiederholungsfragenLernzieleModellbildungObjektorientierte ModellierungGeschaftsprozesseAnwendungsfalleUML-Notation fur AnwendungsfalleStatische Eigenschaften: KlassendiagrammeVerhaltenseigenschaftenInteraktionsdiagrammeSequenzdiagrammeKommunikationsdiagrammeAktivitatsdiagrammeZustandsautomatendiagrammeWiederholungsfragenMotivationLernzieleSoftware-PrufungenReviewsAblauf von ReviewsReview-RegelnReview-ChecklistenReview-VariantenFallen und GegenmittelWiederholungsfragenMotivationLernzieleErgonomiePsychologische und kognitive GrundlagenKommandosprachen versus GUIGeschichte graphischer BenutzungsschnittstellenInteraktionsmechanismenSoftware-ergonomische RichtlinienUsability messen und verbessernZusammenfassungWiederholungsfragenWas ist Software-Architektur?EinflussfaktorenArchitektursichten und -blickwinkelKonzeptioneller BlickwinkelModulblickwinkelAusfuhrungsblickwinkelCode-SichtModularisierungSchnittstellenKopplung und ZusammenhaltQualitatenBewertung von ArchitekturenWiederholungsfragenWas ist ein Entwurfsmuster?Bestandteile eines EntwurfsmustersKategorien von EntwurfsmusternEntwurfsmuster Factory MethodEntwurfsmuster ObserverArchitekturstileArchitekturstil SchichtungArchitekturstil Model-View-ControllerWiederholungsfragenBegriffe des TestensSoziologie des TestensTestaktivitatenTestfallTeststumpfe und -treiberKomponententestsAquivalenztestKomponententest mit JUnitGrenztestPfadtestMaße der TestabdeckungZustandsbasiertes TestenIntegrationstestLeistungstestsZusammenfassung der TestartenTestmanagementTestplanTestfallspezifikationTestschadensberichtWiederholungsfragenMotivationArchitekturkonformitatProgrammierrichtlinienAnhangWiederholungsfragen

12 BenutzerdokumentationLernzieleWas ist Benutzerdokumentation?Arten der DokumentationStrukturAuf Papier oder elektronisch?AutorWie schreibt man eine Dokumentation?Hinweise und RegelnWiederholungsfragenObjektorientierte ModellierungSoftwarearchitekturEntwurfsmuster und ArchitekturstileSoftwaretechnik im Allgemeinen



Lernziele

Eine Benutzerdokumentation erstellen konnen

wissen, was hinein gehort

Arten kennen

ihre Qualitaten kennen

Prozess ihrer Erstellung kennen



Was ist Benutzerdokumentation?

Definition (Benutzerdokumentation)

ist eine Methode, technische Information einer Software an Nichttechnikerzu vermitteln, um sie in ihrer Aufgabe zu unterstutzen.



Ist eine Methode. . . zu vermitteln. . .

Es ist nur eine Methode unter vielen:

Schulungen

Seminare

Coaching

Versuch-und-Irrtum

Selbsterklarungsfahigkeit der Software

Hotline (Help-Desk)



. . . Nichttechnikern . . .

Benutzer sind keine Software-Experten und wollen auch keine werden.

Sie wollen das wissen, was Sie fur Ihre Aufgabe benotigen und nicht mehr.



. . . um sie in ihrer Aufgabe zu unterstutzen. . .

Ihre Aufgabe ist es nicht, Software zu bedienen, sondern ein realesProblem zu losen.



Arten der Dokumentation

Benutzungshandbuch

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)

Systemevaluators

Functionaldescription

Descriptionof servicesprovided

Systemadministrator

How toinstall

Noviceusers

Introductorymanual

Referencemanual

Systemadminstrator

Installationdocument

Experiencedusers

Systemadmin. guide

Gettingstarted

Details of allsystemfacilities

Operateand maintain

system



Wie findet man, was zu dokumentieren ist?

Quellen:

Kommandos und Menus in der Benutzungsoberflache

Aufgaben der Benutzer (was sie tun)

Definition von Begriffen (Glossar)



Struktur I

Titel

Inhaltsverzeichnis

1. Einfuhrung

a. Adressierte Leserb. Zweckc. Verwandte Dokumented. Konventionene. Information uber die Verwendung des Dokumentsf. Instruktionen fur Problemberichte

2. Ubersicht

a. Zugrunde liegende Konzepte, Einbettungb. Funktionale Beschreibungc. Gefahren und Warnungen

3. Instruktionen (fur jeden Benutzertyp einzeln)

a. Produktfunktionen (mit Beispielen)b. Problembehandlung: Ursachen und Grunde



Struktur II

4. Referenz

a. Fehlermeldungen und -ursachen

b. Index der Operationen

Anhang

A Glossar

B Index (notwendig fur ≥ 30 Seiten, sonst mindestens nutzlich)



Scheibchen toter Baume oder doch besser Elektrizitat?

Papier:

”150 Euro — und dafur nur eine CD?“

deutsches Gesetz schreibt Handbuch vor

Papier ist die zuverlassigere 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 + -Schreibqualitaten - +Anwenderbrille - +



Wozu Dokumentation?

Zwecke der Dokumentation:

Erlauterung

Definitionen, Beschreibungen, Erklarungen, Ubersichten,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 vollstandig ist



Der Prozess, eine Dokumentation zu erstellen (Stimely1990)

1 Definition

2 Entwurf

3 Schreiben

4 Editieren

5 Korrekturlesen

6 Produktion

7 Anpassung/Anderung



1. Definition

(5-10% der Gesamtzeit fur Dokumentation)

Erste Frage: Wer sind die Leser?

Identifiziere den”normalen“ Leser. Beschreibe, was Du uber ihn weißt.

Identifiziere die Annahmen uber den Leser.

Es konnte mehrere Kategorien von Lesern geben. Identifiziere sie alle.

Beschreibe, was sie benotigen (Erlauterung, Instruktion, Referenz).

Lege Gegenstande der Dokumentation (mit Namen) und Medien fest



2. Entwurf

(10-30% der Gesamtzeit fur Dokumentation)

Plane fur jeden Gegenstand:

Inhaltsverzeichnis

Schatzung der Anzahl Seiten/Fenster

Musterlayout



3. Schreiben

(1-3 Stunden pro Seite/Fenster)

Erste Fassung so schnell wie moglich schreiben. Dabei nicht editieren.

Schreibblockade uberkommen durch

Verbalisieren (z.B. einem Unbedarften erklaren)

Zerlegung eines komplexen Gegenstands in seine Einzelteile

Brain-Dump

Mind-Map

Auszeit nehmen und ausruhen

(temporar) aufgeben und zum nachsten Abschnitt ubergehen



4. Editing

(1-3 Stunden pro Seite/Fenster)

Iterative Verbesserung:

Bedurfnisse des Lesers GrammatikStruktur OrthographieRelevanz KonsistenzVollstandigkeit Konformitatansprechende graphische Darstellung Ausdrucksweise



5. Korrekturlesen

(5-20 Minuten pro Seite/Fenster)

Unabhangige Begutachtung von

technischer Korrektheit

Vollstandigkeit

Verwendbarkeit

Einhaltung des Stils

Rechtmaßigkeit



6. Produktion

(dauert immer langer als man denkt)

Druck und Verteilung

Herstellung der CD und Verteilung

Publikation im Web



7. Anpassung/Anderung

(benotigt Zeit – muss eingeplant werden)

regelmaßige Uberprufung, um sicher zu stellen, dass Dokumentationaktuell bleibt

Programmierer mussen Handbuch kennen!

Dokumentation muss bei Analyse von Anderungsauswirkungen(Change-Impact) berucksichtigt werden



Hinweise und Regeln

erklare das zu losende Problem

stelle die Konzepte dar, nicht nur die Produktfunktionen

beschreibe auch Anwendungsdomane, nicht nur die Software selbst

die Lekture soll Spaß machen

schreibe zur Leserschaft, nicht uber sie

konsistentes (und eingeschranktes) Vokabular benutzen



Hinweise und Regeln

sei bestimmt

fasse dich kurz (kurze Satze, Paragraphen, Abschnitte)

benutze einfache Sprache

aktive statt passive Sprache

erklare den Zweck eines jeden Schritts

sage, was in jedem Schritt passieren wird

teste mit echten Benutzern

kenne deinen Leser

beachte Markenzeichen und Copyrights



Wiederholungsfragen

Auf welche Weisen konnen Benutzer die Bedienung von Softwareerlernen?

Was ist Benutzerdokumentation?

Nennen Sie Beispiele fur Software-Dokumentationen.

Wie sollte eine Benutzerdokumentation strukturiert werden?

Wer sollte eine Benutzerdokumentation erstellen?

Wie verlauft der Prozess, um eine Benutzerdokumentation zuerstellen?


Antworten auf gesammelte Fragen im Wiki






WiederholungsfragenLernzieleModellbildungObjektorientierte ModellierungGeschaftsprozesseAnwendungsfalleUML-Notation fur AnwendungsfalleStatische Eigenschaften: KlassendiagrammeVerhaltenseigenschaftenInteraktionsdiagrammeSequenzdiagrammeKommunikationsdiagrammeAktivitatsdiagrammeZustandsautomatendiagrammeWiederholungsfragenMotivationLernzieleSoftware-PrufungenReviewsAblauf von ReviewsReview-RegelnReview-ChecklistenReview-VariantenFallen und GegenmittelWiederholungsfragenMotivationLernzieleErgonomiePsychologische und kognitive GrundlagenKommandosprachen versus GUIGeschichte graphischer BenutzungsschnittstellenInteraktionsmechanismenSoftware-ergonomische RichtlinienUsability messen und verbessernZusammenfassungWiederholungsfragenWas ist Software-Architektur?EinflussfaktorenArchitektursichten und -blickwinkelKonzeptioneller BlickwinkelModulblickwinkelAusfuhrungsblickwinkelCode-SichtModularisierungSchnittstellenKopplung und ZusammenhaltQualitatenBewertung von ArchitekturenWiederholungsfragenWas ist ein Entwurfsmuster?Bestandteile eines EntwurfsmustersKategorien von EntwurfsmusternEntwurfsmuster Factory MethodEntwurfsmuster ObserverArchitekturstileArchitekturstil SchichtungArchitekturstil Model-View-ControllerWiederholungsfragenBegriffe des TestensSoziologie des TestensTestaktivitatenTestfallTeststumpfe und -treiberKomponententestsAquivalenztestKomponententest mit JUnitGrenztestPfadtestMaße der TestabdeckungZustandsbasiertes TestenIntegrationstestLeistungstestsZusammenfassung der TestartenTestmanagementTestplanTestfallspezifikationTestschadensberichtWiederholungsfragenMotivationArchitekturkonformitatProgrammierrichtlinienAnhangWiederholungsfragenLernzieleWas ist Benutzerdokumentation?Arten der DokumentationStrukturAuf Papier oder elektronisch?AutorWie schreibt man eine Dokumentation?Hinweise und RegelnWiederholungsfragen

13 Antworten auf gesammelte Fragen im WikiObjektorientierte ModellierungSoftwarearchitekturEntwurfsmuster und ArchitekturstileSoftwaretechnik im Allgemeinen




Ubersicht uber alle UML Diagramme: Welche gibt es alle undwas ist ihr Verwendungsgebiet? (Keine Wiederholung uber dieErstellung, Eigenschaften u.a.)




Anwendungsfalldiagramm

→ Ubersicht von Anwendungsfallen, Zusammenhang mit Akteuren,Beziehungen zwischen Anwendungsfallen

Klassendiagramm

→ statische Beziehungen zwischen Dingen:

Daten- bzw. DomanenmodellKlassenentwurf




Sequenzdiagramm

→ Interaktionen zwischen Akteuren

Interaktionen in AnwendungsfallenInteraktionen zwischen Komponenten der ArchitekturProgrammablauf (Methoden und Klassen)

Kollaborationsdiagramme

→ aquivalent zu Sequenzdiagrammen

→ heben Akteure und deren prinzipielle Interaktion hervor, Reihenfolgetritt in den Hintergrund




Zustandsdiagramme

→ zustandsbasiertes Verhalten, Reaktion auf Stimuli

Modellierung von Anwendungsfallen mit ZustandenObjektlebenszyklusProtokolle in Architekturzustandsbasiertes Testen

Aktivitatsdiagramme

→ Ablaufe: Aktionen und ihre Reihenfolge

Modellierung von GeschaftsprozessenBeschreibung von AnwendungsfallenSpezifikation/Entwurf von AlgorithmenPfadtest



Softwarearchitektur

Außerdem aus gegebenem Anlass, zu den unterschiedlichenBlickwinkel des Architekturentwurfs.

Konzeptionelle Sicht nach Hofmeister u. a. 2000: Data undControl Konnektoren, Unterschiede? (Wir haben z.B. bei jederVerbindung beides benutzt...??)

Alternative Modellierung der Konzeptionellen Sicht mit UML?Vielleicht ein kleines Beispiel?

Die Unterschiede und Zusammenhange zwischen System,Subsystem, Modul und Komponente nochmal erlautern




CComponent

CPort


CConnector

CRole

Protocolobeysobeys

cbindingcbinding

connection

11

* *

*

*

*

*

* *

* *

* *

1 1

0..1

0..1 0..1 0..1 0..10..1*

*

conjugate



Konzeptionelle Sicht

«Component»

Main

«Component»

FrontEnd

«Component»

MiddleEnd

«Component»

BackEnd

«call»

call ist ein Control-Konnektor;

ein einfacher Aufruf

«call»

«call»

«Data»

AST-Pipe

Producer

Consumer

«bind» «bind»

«Data»

IL-Pipe

Producer

Consumer

«bind» «bind»

«Data»

Text-Pipe

«Data»

Assembler-Pipe

Compiler





Module

Interface

Layer


Subsystem

use

0..1

require *

*

*

require

* provide

*

* * * * *

0..1

0..1

use *

* *

* assigned−to

*

cont

ain

provide

contain

0..1



Modulsicht

Lexer SyntaxAnalysis SemanticAnalysis

GetToken

TextBuffer

GetText

Open

Main

Parse Decorate

AST

Lookup

Create

Annotate

<<Subsystem>> FrontEnd

Traverse

ControlFlowAnalyzerILGenerator

IL

Generate

Traverse

<<Subsystem>>

MiddleEnd

Optimizer

Run Run

Run

<<Layer>>

Programrepresentation




SoftwarePlatform

PlatformElement

PlatformResource

HardwareResource

CommunicationPath

RuntimeEntity


Module

*

* * *

consumeconsume

* contain

is a

communicate over

*

1

use mechanism

assigned to

* 2..*

1

*

assigned to

*

*

*

* 1

*



Ausfuhrungssicht

Processor2Processor1

Lexer

SyntaxAnalysis

SemanticAnalysis

TextBuffer

Main AST

ControlFlowAnalyzerILGenerator

ILOptimizer

11

Shared Memory

<<Thread>>

<<Thread>>

*

1



Entwurfsmuster und Architekturstile

die factory method an einem kleinen konkretenImplementierungsbeispiel darstellen



Fahrradladenbeispiel: Erweiterung fur andere Domanen

Anforderungen:

Artikeldaten sollen von einer Datei gelesen werden konnen

zukunftig sollen andere Domanen unterstutzt werden (Fahrrad,Computer und Klettern)

die Objekte dieser Domanen sind unterschiedlich

notwendige Anpassungen sollen einfach realisiert werden konnen

Losungsstrategien:

die Klassen der Benutzungsschnittstelle beziehen sich nur auf dieSchnittstelle der abstrakten Klasse Artikel

Datei hat gleiche Syntax fur alle Domanen (nur die Inhalte variieren)

die Artikel werden beim Einlesen der Datei als Objekte erzeugt

→ aber der Leser muss doch die Konstruktoren der Objekte kennen, oderwas?



Losungsstrategie

FelgeRahmen

+ Preis()

Artikel

GUI

ComputerArtikel FahrradArtikel

+ lies(dateiname)

Leser

id=datei.liesId()

s.FabrikMethode(id)

+ Artikel FabrikMethode(id)

ArtikelSchopfer

+FabrikMethode(id)

FahrradSchopfer

+FabrikMethode(id)

ComputerSchopfer

if (id == ”rahmen”)return new Rahmen

if (id == ”felge”)return new Felge�create�

�create� �create�



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 date iname ) 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 ( date iname ) ;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 . Fabr ikMethode ( 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 go ing

}}i n . c l o s e ( ) ;

}



Schopfer

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 Fabr ikMethode ( 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 Fabr ikMethode ( 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 uber agile Softwareentwicklung im Vergleich zumWasserfallmodell



Extreme Programming (Beck 2000)

Wasserfallmodell — Extreme Programming — Code&FixExtreme Programming (XP) ist eine agile Methode fur

kleinere bis großere Entwicklerteams (max. 10-15 Personen),

Probleme mit vagen Anforderungen

und Projekte, bei denen ein Kundenreprasentant stets greifbar ist.

http://www.extremeprogramming.org/


http://www.extremeprogramming.org/


Extreme Programming (Beck 2000)

Anerkannte Prinzipien und Praktiken werden”extrem“ umgesetzt:

Code-Reviews → permanente Reviews durch Pair-Programming

Testen → standiges Testen: Unit-Tests sowie Akzeptanztests durchden Kunden/Benutzer

klare Struktur → jeder verbessert sie kontinuierlich durch Refactoring

Einfachheit → stets die einfachste Struktur wahlen, die die aktuellenAnforderungen erfullt

Integration → permanente Integration auch mehrmals am TagValidierung:

Kunde/Benutzer ist stets involviert bei der Planung neuer Iterationenund verantwortlich fur Akzeptanztestkurze Iterationen → Dauer in Minuten und Stunden, nicht Wochen,Tage, Jahre

aber auch Auslassung anerkannter Prinzipien:

Dokumentation: mundliche Uberlieferung, Tests und Quellcode

Planung: sehr begrenzter HorizontRainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 617 / 634


Weitere XP-Charakteristika

Kunde vor Ort

eine Metapher statt einer Architekturbeschreibung

40-Stundenwoche

Code ist kollektives Eigentum

Kodierungsstandards



Agile versus weit voraus planende Prozessmodelle (Boehmund Turner 2003)

Risiken agiler Methode:

Skalierbarkeit, Kritikalitat, Einfachheit des Entwurfs,Personalfluktuation, Personalfahigkeiten

Risiken weit voraus planender Prozessmodelle:

Stabilitat der Anforderungen, steter Wandel, Notwendigkeit schnellerResultate, Personalfahigkeiten

Generelle Risiken:

Unsicherheiten bei der Technologie, unterschiedlicheInteressengruppen, komplexe Systeme


Das SWP-Lied

Das SWP-Lied






14 Das SWP-Lied


Das SWP-Lied

SWP-Lied

Melodie: Paul McCartney:”Let it be“; Text: Jochen Quante

Irgendwann im Informatik-Studiumkommt 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’hort 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 durfen,ist das Wissen ganz passe:Wie ging noch mal Java? – SWP.

SWP, SWP, SWP, SWP.Was war noch mal Java? – SWP.

Die Zeit wird knapp, die Nachte kurzer,manch einer fallt aus – oh je.Keine Zeit fur’s Testen – SWP.

Die Software wurde grad’ noch fertig,war’n wir doch zuviel am See?Dafur war die Planung – SWP.

SWP, SWP, SWP, SWP.Dafur also Planung – SWP.


Das SWP-Lied

1 Balzert 1998 Balzert, Helmut: Lehrbuch der Software-Technik.Spektrum Akademischer Verlag, 1998. – derzeit nicht mehr verfugbar,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.: Evaluationof 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 tobalance 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 EqualProject Failure. In: IEEE Computer (2000), September, S. 94–96


Das SWP-Lied

7 Brugge und Dutoit 2004 Brugge, Bernd ; Dutoit, Allen H.:Objektorientierte Softwaretechnik. Prentice Hall, 2004

8 Buschermohle u. a. 2006 Buschermohle, Ralf ; Eekhoff, Heike ;Josko, Bernhard: Success – Erfolgs- und Misserfolgsfaktoren bei derDurchfuhrung von Hard- und Softwareentwicklungsprojekten inDeutschland. 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


www.offis.de/umfragesuccess

Das SWP-Lied

12 EN ISO 9241-10:1995 1995 : Ergonomische Anforderungen furBurotatigkeiten mit Bildschirmgeraten – Teil 10: Grundsatze derDialoggestaltung. Europaische Norm, ISO-Standard. 1995

13 Fjeldstadt und Hamlen 1984 Fjeldstadt ; Hamlen: ApplicationProgram Maintenance Study: Report to Our Respondents. In: Proc.GUIDE 48, IEEE Computer Society Press, April 1984

14 Fruhauf u. a. 2000 Fruhauf ; Ludewig ; Sandmayr:Software-Prufung. 4. Auflage. vdf Zurich, 2000

15 Fusaro u. a. 1997 Fusaro, P. ; Lunibile, F. ; Visaggio, G.: Areplicated 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 ReusableObject-Oriented Software. Addison Wesley, 2003

17 Gilb 1988 Gilb, Tom: Principles of Software EngineeringManagement. Harlow, UK : Addison-Wesley, 1988


Das SWP-Lied

18 Harel 1987 Harel, David: State Charts: a Visual Formalism forComplex 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: acase 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 ArchitecturalDescription of Software-intensive Systems—Std. 1471-2000. ISBN0-7381-2518-0, IEEE, New York, NY, USA. 2002

23 IEEE Standard 830.1998 1998 : IEEE Recommended Practice forSoftware Requirements Specifications, IEEE Standard 830.1998. 1998


Das SWP-Lied

24 IEEE-Std-1058 1987 : ANSI/IEEE Standard for Software ProjectManagement Plans. ANSI/IEEE Std. 1058.1-1987. 1987

25 IEEE Std 610.12-1990 1990 : IEEE Standard Glossary of SoftwareEngineering Terminology. IEEE Standard 610.12-1990. 1990

26 IEEE Std. 829-1998 1998 : IEEE Standard for Software TestDocumentation. IEEE Standards Board, IEEE Std. 829-1998. 1998

27 IEEE Std. 982-1989 1989 : IEEE Standard Guide for the Use of IEEEStandard Dictionary of Measures to Produce Reliable Software. IEEEStandards Board, IEEE Std. 982-1989. Juli 1989

28 ISO 9241-11:1998 1998 : Ergonomic requirements for office work withvisual display terminals (VDTs) – Part 11: Guidance on usability.ISO-Standard. 1998

29 ISO/IEC-Standard 25000 2005 ISO/IEC 25000:2005 SoftwareEngineering – Software product Quality Requirements and Evaluation(SQuaRE). 2005. – umgesetzt in DIN 66272

30 ISO/IEC-Standard 9126 2001 ISO/IEC 9126-1:2001 Softwareengineering – 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 ofArchitecture. In: IEEE Software 12 (1995), November, Nr. 6, S. 42–50

34 Lehman und Belady 1985 Lehman, M. ; Belady, L.: ProgramEvolution: 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.: ABehavioral Notion of Subtyping. In: ACM Transactions on ProgrammingLnguages and Systems 16 (1994), Nr. 6, S. 1811–1841

37 Ludewig 2003 Ludewig, Jochen: Einfuhrung 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.Vorlesungs-Skriptum. 2001

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.: Furtherexperiences with scenarios and checklists. In: Empirical SoftwareEngineering 3 (1998), S. 37–64

42 Murphy u. a. 1995 Murphy, Gail C. ; Notkin, David ; Sullivan,Kevin: Software Reflexion Models: Bridging the Gap Between Sourceand High-Level Models. In: Proc. of the Third ACM SIGSOFTSymposium 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 Designand 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 inComputers and Related Systems. In: ACM SIGSOFT SoftwareEngineering Notes 24 (1999), Nr. 1, S. 31

45 Object Management Group 2003 Object Management Group:OMG Unified Modeling Language Specification. March 2003. – Version1.5

46 OMG Object Management Group (OMG): Unified ModelingLanguage. http://www.uml.org

47 Parnas 1972 Parnas, David L.: On the Criteria to Be Used inDecomposing Systems into Modules. In: Communications of the ACM15 (1972), Dezember, Nr. 12


http://www.uml.org

Das SWP-Lied

48 Partsch 1998 Partsch, H.: Requirements-Engineering systematisch -Modellierung fur softwaregestutzte Systeme. Berlin, Heidelberg, NewYork : 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.: Comparingdetection methods for software requirements inspection: a replicationusing professional subjects. In: Empirical Software Engineering 3 (1998),S. 355–379

51 Porter u. a. 1995 Porter, A. ; Votta, L. ; Basili, V.: Comparingdetection methods for software requirements inspection: a replicatedexperiment. In: IEEE Transactions on Software Engineering 21 (1995),Nr. 5, S. 563–575

52 Pressman 2003 Pressman, Roger: Software Engineering – APractioner’s Approach. Funfte Ausgabe. McGraw-Hill, 2003


Das SWP-Lied

53 Rodiger 2004 Rodiger, Karl-Heinz: VortragRechtlicher Rahmen der Software-Entwicklung in der VorlesungSoftware-Projekt. Vorlesungs-Skriptum. 2004

54 Sandahl u. a. 1998 Sandahl, K. ; Blomkvist, O. ; Karlsson, J. ;Krysander, C. ; Lindvall, M. ; Ohlsson, N.: An extendedreplication of an experiment for assessing methods for softwarerequirements inspections. In: Empirical Software Engineering 3 (1998),S. 327–354

55 Sauer und Cuthbertson 2003 Sauer, C. ; Cuthbertson, C.: TheState of IT Project Management in the UK.http://www.cw360ms.com/pmsurveyresults/surveyresults. 2003

56 Shaw und Garlan 1996 Shaw, Mary ; Garlan, David: SoftwareArchitecture – Perspectives on an Emerging Discipline. Upper SaddleRiver, NJ : Prentice Hall, 1996. – ISBN ISBN 0-13-182957-2

57 Shull u. a. 2000 Shull, Forrest ; Rus, Ioana ; Basili, Victor: HowPerspective-Based Reading Can Improve Requirements Inspections. In:IEEE Computer 33 (2000), Nr. 7, S. 73–79


http://www.cw360ms.com/pmsurveyresults/surveyresults

Das SWP-Lied

58 Sommerville 2004 Sommerville, Ian: Software Engineering. SiebteAusgabe. Addison-Wesley, 2004

59 Sowa und Zachman 1992 Sowa, J. F. ; Zachman, J. A.: Extendingand formalising the framework for information systems architecture. In:IBM Systems Journal (1992)

60 Standish Group 1994

61 Standish Group 2004 Standish Group: Third Quarter ResearchReport. http://www.standishgroup.com. 2004

62 Stimely 1990 Stimely, Gwen L.: A stepwise approach to developingsoftware documentation. In: ACM SIGDOC Asterisk Journal ofComputer Documentation 14 (1990), Nr. 4, S. 121–124

63 Storrle 2005 Storrle, Harald: UML 2 fur Studenten. PearsonStudium, 2005. – ISBN 3-8273-7143-0

64 Sun microsystems 1999 Sun microsystems: Code Conventions forthe JavaTM Programming Language. April 1999. – URL http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html


http://www.standishgroup.com

http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html

http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html

Das SWP-Lied

65 Winter 2003 Winter, Andreas: Einfuhrung in die Softwaretechnik.Vorlesungs-Skriptum. 2003

66 Zachman 1987 Zachman, J. A.: A framework for information systemsarchitecture. In: IBM Systems Journal 26 (1987), Nr. 3

67 Zachman 1999 Zachman, J. A.: A framework for information systemsarchitecture. In: IBM Systems Journal 38 (1999), Nr. 2&3, S. 454—470

68 Zuser u. a. 2004 Zuser, W. ; Grechenig, T. ; Kohle, M.: SoftwareEngineering mit UML und dem Unified Process. Zweite Ausgabe.Pearson Studium, 2004


Documents

Prof. Dr. Rainer Koschke - Informatik - FB3 - Uni Bremen · Software-Projekt Prof. Dr. Rainer Koschke Fachbereich Mathematik und Informatik Arbeitsgruppe Softwaretechnik Universit