Definitionsphase - STS

Definitionsphase - STS
Vorlesung "Software-Engineering"
Rainer Marrone, TUHH, Arbeitsbereich STS
zVorige Vorlesungen
yPlanung
⌧Lastenheft (requirements definition document)
⌧Verfahren zur Aufwandsschätzung
zHeute
yDefinition
⌧Pflichtenheft (requirements specification document)
⌧Detaillierte Anforderungsanalyse (detailed requirements engineering)
1
Gegenstand der Vorlesung
zUnter dem Namen SW-Engineering werden
Methoden und Prinzipien zur Lösung von
„bösartigen Problemen“ (Rittel 73*) diskutiert
zProbleme sind „bösartig“,
ywenn sie in so viele Einzelteile verstrickt sind, daß es
keine endgültige Spezifikation des Problems gibt.
ywenn sich das wahre Gesicht erst bei der Entwicklung der
Lösung zeigt
ywenn sich Anforderungen erst bei bzw. nach der
Implementierung ergeben
* “Dilemmas in a General Theory of Planning”
2
Systemanalyse: Einordnung
Planungsphase
Planungsphase
Lastenheft
Lastenheft
Definitionsphase
Definitionsphase
Vorgaben und
Rahmenbedingungen
aus der
Planungsphase
vage, verschwommene,
unzusammenhängende,
unvollständige,widersprüchliche
Anforderungen
Definitionsprozeß
Produkt-Definition
Pflichtenheft
Entwurfsphase
vollständige, konsistente,
eindeutige und durchführbare
Produktanforderungen
Entwurfsphase
Produkt-Entwurf
Produktentwurf
Implementierungsphase
Implementierungsphase
Programme
Produkt, Komponenten
Abnahme &
Einführungsphase
Abnahme und Einführung
Installiertes Produkt
Installiertes Produkt
Legende:
Phase
Weitergabe von
Teilprodukten
Phasenergebnis
3
Systemanalyse: Aktivitäten und Ergebnisse
„Requirements Engineering“
Definitionsphase
Produktdefinition
• Anforderungen ermitteln
• Anforderungen festlegen und
beschreiben
• Anforderungen analysieren
• Anforderungen u.U. animieren,
simulieren und ausführen
• Anforderungen verabschieden
Pflichtenheft
• Produktmodell
• Konzept Benutzungsoberfläche
• Benutzerhandbuch
z Anforderungen (requirements) : Legen die qualitativen und
quantitativen Eigenschaften eines Produkts aus der Sicht des
Auftraggebers fest.
z Systemanalyse (requirements engineering): Systematische
Vorgehensweise, um die Anforderungen in einem iterativen Prozeß zu
ermitteln.
4
Produktdefinition
zZiel: Projektvertrag
= Produktdefinition (Pflichtenheft, Produktmodell, Konzept für
Benutzungsoberfläche, Benutzerhandbuch)
+ Zahlungsbedingungen
+ Garantie
+ Projektplan
+ ...
Juristischer Vertrag!
è Überprüfung der erbrachten Leistung
5
Wie es der
Kunde erklärte
Wie es der
Projektleiter verstand
Wie es der
Engineer geplant hat
Wie es der Programmierer umsetzte
Wie es dokumentiert
wurde
Wie es installiert wurde
Was dem Kunde
berechnet wurde
Was der Servicevertrag
unterstützt
Wie es der Berater
verstand
Was der Kunde wirklich
wollte
6
2.2 Softskills für die Anforderungserhebung
2.2.1 Mehrdeutigkeiten in der Problemstellung
2.2.2 Methoden und Werkzeuge der Anforderungserhebung
(Softskills)
2.2.2.1 Direkte Fragen
2.2.2.2 Kontextfreie Fragen
2.2.2.3 Die richtigen Personen involvieren
2.2.2.4 Meetings
2.2.2.5 Mehrdeutigkeiten
7
2.2.1 Mehrdeutigkeiten in der Problemstellung (1)
zProblemstellung zur Illustration:
zCreate a means for protecting a small group of
human beings from the hostile elements of their
environment.
z(Erstellen Sie eine Unterkunft für eine kleine Gruppe
Personen zum Schutz vor feindlicher Umgebung.)
[GaWe89]
8
Mehrdeutigkeiten in der Problemstellung (2)
z Lösung 1: Das Iglu
Quelle: http://www1.erwischt.ch
9
Mehrdeutigkeiten in der Problemstellung (3)
z Lösung 2: Die Burg
Quelle: http://www.kultursoft.de
10
Mehrdeutigkeiten in der Problemstellung (4)
z Lösung 3: Die Raumstation
Quelle: http://www.esa.de
11
Mehrdeutigkeiten in der Problemstellung (5)
⇒ Alles richtige Lösungen
⇒ Durch Untersuchung der Unterschiede in den Lösungen kann
man die Quellen der Mehrdeutigkeit herausfinden.
z Arten von Mehrdeutigkeiten
yFehlende Anforderungen
⌧Keine Aussage über das Material: Verfügbarkeit, Beständigkeit, Kosten
⌧Keine Aussage über die Struktur: Größe, Form, Gewicht, Lebensdauer
⌧Keine Aussage über Funktionen: Ofen, Bedienstete, Betten, Ballsaal,…
⌧Keine Aussage über physische Umgebung: Land, See, Erde, Weltraum,..
⌧Keine Spezifikation der Personen: Familie, Arbeitsgruppe, Jäger, Tänzer,...
yMehrdeutige Begriffe
⌧Z.B. „klein“ oder „billig“ kann auf verschiedene Arten interpretiert werden
⌧Z.B. „Gruppe“ impliziert das Interagieren von Personen. Es könnte sich um eine
Gruppe Schauspieler bei einer Theateraufführung handeln oder um eine
Freundesgruppe, die sich im Cafe trifft. Die Interaktionen der Personen
unterscheiden sich deutlich voneinander.
[GaWe89]
12
Natürliche Sprache
- Allg. Problem natürlicher Sprache
⇒inhärente Mehrdeutigkeiten, Missverständnisse
yMehrdeutigkeiten reduzieren, durch Alternativen zur
natürlichen Sprache,
⌧Z.B. graphische Mittel wie SADT oder UML,
⌧Aber auch Pseudocode (= strukturierte natürliche Sprache),
⌧Programming Description Language (PDL) angelehnt an
Programmiersprache wie Java,
⌧Schnittstellenspezifikation,
⌧Mathematische Spezifikation (z.B. Zustandsmaschine)
[Somm01]
13
2.2.2 Ein Bild der Anforderungen
z Das Universum aller Lösungsmöglichkeiten:
Was wir
wollen
Was wir
nicht wollen
z Das Herausfinden der richtigen Anforderungen ist ein iterativer Prozess:
Me
tho
de
z Schwarze Bereiche:
das, was wir haben wollen,
aber nicht spezifiziert haben,
oder das, was wir spezifiziert haben,
aber nicht haben wollen.
z Mit Hilfe von Methoden können
wir uns iterativ an die gewünschten
Anforderungen herantasten.
Softskills hierzu werden im Folgenden dargestellt
[GaWe89]
14
2.2.2.1 Direkte Fragen (1)
z Um Anforderungen zu spezifizieren, ist es wichtig, Mehrdeutigkeiten zu
beseitigen.
z Ein Weg, dieses zu tun, wäre es, direkte Fragen an den Kunden zu stellen.
z Jedoch reicht das alleinige Stellen von Fragen ohne Unterstützung anderer
Hilfsmittel, wie
y Direkte Beobachtung
y Interviewtechniken
z nicht aus.
z Dazu ein Beispiel: Das Entscheidungsbaum-Modell
y Die Wurzel des Baumes repräsentiert
die erste vage Idee.
y Die Knoten zeigen Entscheidungen auf,
die die Lösung des Problems eingrenzen.
y Die Blätter sind mögliche Lösungen.
y Jeder Schritt entlang des Baums
verringert die Mehrdeutigkeit.
y Bei einer falschen Entscheidung zu Anfang
des Baums, liegt die Lösung weit von der
korrekten, durch den Kunden gewünschten
Lösung entfernt.
[GaWe89]
15
Direkte Fragen (2)
zDie Reihenfolge der Fragen ist wichtig:
zEinige nicht korrekte Lösungen sind eher
akzeptierbarer als andere.
yz.B. Der Kunde möchte ein grünes Fahrrad.
⌧Mit einem lila Fahrrad ist er zufriedener als mit einem grünen Skateboard.
⌧Von daher ist die Frage nach der Farbe eine der späteren Designfragen.
⌧Und die Frage, ob es sich um ein Fahrrad oder ein Skateboard handeln
soll, eine frühe Entscheidung
⇒Die richtige Reihenfolge produziert Lösungen, die näher an der
gewünschten Lösung liegen
[GaWe89]
16
Direkte Fragen (3) – Beispiel (1)
FM
z Ein Beispiel: Kunde: „Ich benötige
ein Fortbewegungsmittel (FM).“
18
z Designer: „Bis wann brauchen sie es?“
Kunde: „in 18 Monaten“
P
z Designer: “Was soll transportiert werden?“
Kunde: „Personen“
1
z Designer: „Wie viele?“
Kunde: „Eine“
z Designer: „Wie ist der Antrieb?“
PK
Kunde: „mit der eigenen Kraft der Person (PK)“
z Designer: „Über was für eine Oberfläche?“
Kunde: „über sehr harte, flache Oberfläche (HO)“
z Designer: „Wie groß sind die Strecken?“
2
Kunde: „bis zu 2 km“
HO
[GaWe89]
17
Direkte Fragen (3) – Beispiel (2)
FM
18
P
1
z Designer: „Wie schnell?“
Kunde: „mindestens 400m pro Stunde“
z Designer: „Wie zuverlässig?“
Kunde: „Versagen darf den Passagier nicht
gefährden, nur ein Versagen auf
1600 km.“
z Designer: „Maximale Kosten?“
Kunde: „Design, Entwicklung und Herstellung so,
dass pro Benutzung höchstens Kosten
von 200 Euro entstehen.“
PK
HO
2
400
1V
200
[GaWe89]
18
Direkte Fragen (4) – Beispiel (3)
z Frage:
Wie sieht das Fortbewegungsmittel aus?
z
z Lösung:
Ein kompaktes, leichtgewichtiges, faltbares Dreirad, welches in der
z
Hosentasche getragen werden kann.
z Begründung:
Diese Lösung ist konsistent mit allen Antworten!
z
z Entspricht dieses Produkt wirklich den Wünschen des Kunden?
[GaWe89]
19
Direkte Fragen (6)
⇒ Schlussfolgerungen:
⇒ Direkte Fragen sind zwar eine gute Technik, können aber nur im
Zusammenhang mit anderen Techniken erfolgreich eingesetzt werden.
⇒ Überzeugen Sie sich immer davon, dass Sie das bauen, was der Kunde
haben möchte, nicht dass, was er braucht.
⇒ Wenn ein Produkt unbekannt ist, sollten Sie zuerst den Kunden davon
überzeugen, dass er es braucht
⇒ Benutzen Sie die Entscheidungsbaumtechnik. Zeigen Sie den Baum der
Person, der sie die Fragen stellen, um festzustellen, ob Sie auf dem
richtigen Weg sind.
[GaWe89]
20
Die richtigen Personen involvieren (4)
zAlle Benutzer identifizieren
yErstellen einer potenziellen Benutzerliste durch
Brainstorming: wer könnte alles potenzieller Benutzer
sein?
yZurechtstutzen der Benutzerliste
⌧Aktive Entscheidung über Benutzergruppen,
⌧denen man freundlich oder
⌧unfreundlich gegenüber steht oder
⌧die man ignoriert.
[GaWe89]
21
2.2.2.4 Grundzüge des produktiven Meetings (1)
z Teilnahme und Sicherheit
y Symptome für unsicheres Klima
⌧ Das Meeting verlassen
⌧ Nicht beim Meeting erscheinen
⌧ Körperlich, aber nicht geistig anwesend sein
y Bevor das Meeting beginnt, eine Vereinbarung über die Regeln des Meetings
treffen
1. Unterbrechungsregel:
keine Person darf eine andere unterbrechen
2. Zeitlimitregel:
damit jeder zu Wort kommt, die Sprechzeit auf z.B. 2 Minuten reduzieren
3. Persönliche-Angriffe-Regel:
keiner möchte persönliche Angriffe, aber in der Hitze der Diskussion kommt es
ständig dazu
⇒ dem Moderator muss erlaubt werden, hier einzugreifen
22
[GaWe89]
Grundzüge des produktiven Meetings (2)
4. Druck-verringern-Regel:
jeder Person soll es erlaubt sein, ohne Angabe von Gründen ein 1- oder 5-minütiges
Timeout zu beantragen, um Informationen zu holen, nachzudenken, wichtige
persönliche Dinge zu erledigen, auf‘s Klo zu gehen, etc.
5. Zeit-nehmen-Regel:
erlauben Sie die benötigte Zeit, um alle Angelegenheiten zu klären, aber beenden Sie
das Meeting pünktlich, d.h. setzen Sie ein neues Meeting an, falls noch nicht alles
geklärt ist. Der Moderator sollte jedem am Ende des Meetings folgende Frage
stellen:“ Wurde alles zu Ihrer Zufriedenheit behandelt?“
6. Verwandte-Angelegenheiten-Regel:
Themen, die nicht direkt Fokus des Meetings sind, werden auf einer separaten Liste
festgehalten => Teilnehmer fühlen sich sicher, wenn ihre Idee festgehalten wurde.
Am Ende des Meetings überträgt der Moderator die einzelnen Punkte der Liste an
Personen, die sich darum kümmern sollen
7. Ergänzungsregel:
Der Moderator braucht im Vorhinein das Einverständnis der Teilnehmer, die Regeln zu
ändern oder zu ergänzen, falls unvorhergesehene Dinge passieren.
23
[GaWe89]
Grundzüge des produktiven Meetings (4)
zProduktivität
yJedes Meeting hat einen anderen Zweck, also sollte auch
das Klima des Meetings angepasst werden
zZweck von Meetings
yInformationen verbreiten
yVerbessern der Stimmung
yAnzahl der Ideen erhöhen (Brainstorming)
yAnzahl der Ideen verringern
⇒Pro Meeting nur einen Zweck
24
Pro Meeting nur ein Thema
= interessiert an
Thema A
= interessiert an
Thema A und B
= interessiert an
Themen B
Ein Meeting über Thema A und B dauert 2 Stunden. 5 Leute sind beim Meeting über
Thema A gelangweilt, 7 Leute sind beim Meeting über Thema B gelangweilt.
Zwei separate Meetings: Niemand ist gelangweilt beim Meeting über Thema A, niemand
ist gelangweilt beim Meeting über Thema B.
25
[Gause / Weinberg]
Aufbau eines Pflichtenheftes
z Aufgabe:
Zusammenfassung aller fachlichen Anforderungen
z Adressaten:
Auftraggeber,
Auftragnehmer (Manager, Entwickler, Tester, Warter)
z Inhalt:
fachlicher Funktions-, Daten- und Leistungsumfang, Qualitätsanforderungen
Was, nicht Wie
Basis des juristischen Vertrages!
z Form:
Standardisiertes, gegliedertes Schema,
meistens: textuell
Eventuell: Beschreibung durch Modelle
z Sprache:
detaillierte verbale Beschreibung (falls textuell), für Auftraggeber lesbar!
z Zeitpunkt:
direkt nach Planungsphase
z Umfang: ausführlich, vollständig
26
Aufbau und Inhalt eines Pflichtenheftes (1)
1. Zielbestimmung
yMuß-Kriterien: Was muß das Produkt leisten?
yWunschkriterien: Was soll das Produkt evtl. noch leisten?
yAbgrenzungskriterien: Was soll das Produkt nicht leisten?
2. Produkt-Einsatz
ydefiniert Anwendungsbereiche (wofür), Zielgruppen (für wen) und
Betriebsbedingungen (z.B. physikalische Umgebung, Betriebszeiten,
Bediener nötig etc.)
3. Produkt-Umgebung
ySoftware, Hardware, Orgware, Produkt-Schnittstellen
(Betriebssystem, Rechner, Peripherie, organisatorische
Voraussetzungen (z.B. Mail-Anschluß), Integration in bestehende
Anwendungen)
27
Aufbau und Inhalt eines Pflichtenheftes (2)
4. Produkt-Funktionen (funktionale Anforderungen)
ydefiniert abstrakte Funktionalität aus Benutzersicht
ytextuelles, num. Gliederungsschema (z.B. /F10/ oder /F20/W für
Wunschkriterium)
U.U.: Funktionsbäume, Zustandsautomaten,
Petrinetze, Klassendiagramme, Interaktionsdiagramme
5. Produkt-Daten
yBeschreibung langfristig zu speichernder Daten aus Benutzersicht
ytextuell, num. Gliederungsschema (z.B. /D10/)
U.U.: ER-Modelle, XML-Schemata,
Klassendiagramme
28
Verfeinerung der Funktionen (Beispiel)
verwalte
Seminare und
Kunden
verwalte Kunden
verwalte KundenStammdaten
/F10/
verwalte FirmenStammdaten
/D20/
beantworte
Anfragen
buche
Veranstaltungen
/F120/
erfasse
Kundenstamm
erfasse
Firmenstamm
erfasse
Anmeldungen
/F20/ ... /F55/
erfasse
Abmeldungen
/F70/ ... /F100/
bearbeite
Stornierungen
/F110/
aktualisiere
KundenStammdaten
aktualisiere
FirmenStammdaten
erstelle AnmeldeBestätigung
/F60/
erstelle AbmeldeBestätigung
erstelle
StornierungsMitteilung
lösche
Kundenstamm
lösche FirmenStammdaten
erstelle Rechnung
/F210/
erstelle korrigierte
Rechnung
erstelle korrigierte
Rechnung
erstelle
Adreßaufkleber
/F130/
erstelle
Rechnungskopie
/F220/
erstelle korrigierte
Rechnungskopie
erstelle korrigierte
Rechnungskopie
trage Zahlungsverzüge ein
/F140/
erstelle Mitteilung
erstelle Mitteilung
Legende: /.../ Bezüge zum Pflichtenheft
29
Aufbau und Inhalt eines Pflichtenheftes (3)
6. Produkt-Leistungen (nicht-funktionale Anforderungen)
yAntwortzeiten, max. Datenumfang, Benutzerzahl, Genauigkeit bei
num. Daten, ...
7. Benutzungsoberfläche (falls gewünscht)
8. Qualitäts-Zielbestimmung
(nicht-funktionale Anforderungen)
9. Globale Testszenarien/Testfälle
yAbnahmetest
10. Entwicklungsumgebung
11. Ergänzungen
12. Glossar, Begriffslexikon
30
Nach dem Erstellen
zAnforderungen validieren (Requirements Validation)
⌧Anforderungen evaluieren
⌧Auf Korrektheit (Vollständigkeit, Konsistenz) und Durchführbarkeit
(Kosten, Ressourcen) überprüfen
zAnforderungen verwalten (Requirements
Management)
⌧Die Evolution der Anforderungen im Griff behalten
⌧Nachverfolgbarkeit der Anforderungen
⌧Verträglichkeitsprüfung von sich ändernden Anforderungen
31
Systemanalyse: Einsatzszenarien
Lastenheft
Lastenheft
Pflichtenheft
Pflichtenheft
SzenarienModelle
Produktmodell
Benutzungsschnittstelle
Glossar
Handbuch
32
Szenarien
zEreignisszenarien:
Beschreibung von Ereignissen, die eine gewisse
Systemfunktionalität auslösen, und deren Interaktion
zBeschreibung von Anwendungsfällen (use cases):
Beschreibung der Funktionalität aus der
Benutzungsschnittstellensicht (für externe Akteure)
zEthnographische Analyse: Einbettung eines
Systems in den Arbeitskontext (vgl. Ist-Analyse)
yFür Anforderungen, die sich daraus ergeben, wie
Menschen wirklich arbeiten, und nicht wie sie arbeiten
sollen nicht wie sie sagen wie sie arbeiten (sollen)
z...
33
Anwendungsfallbeispiel: Point of Sale Terminal (1)
z Ein Point of Sale Terminal (POST) ist ein computergestütztes System, um
Verkäufe, Bezahlungen und Auszahlungen in einem Handelsgeschäft zu
unterstützen.
z Es enthält Hardwarekomponenten (Computer, Anzeige, BalkencodeLesegerät, ...) und Softwarekomponenten.
Buy items
Log in
Customer
Refund purchased
items
Cashier
34
Beispiel: Point of Sale Terminal (2)
zAnwendungsfallbeschreibung
Use Case: Buy item
1. This use case begins when a customer arrives
at a POST checkout with items to purchase.
2. The cashier records the universal product code
(UPC) from each item.
3. The System determines the item price and adds
the item to the running sales transaction.
4. If there is more than one of the same item, the cashier
can enter the quantity as well.
5. The description and the price of the current item are
displayed.
6. ...
35
Begriffliche Analyse
z In Funktionsbeschreibungen, Datenbeschreibungen oder
Szenarien tauchen Begriffe und Beziehungen auf
z Begriffe beschreiben gleichstrukturierte Objekte einer
Anwendung
yWir gehen von einer Grundmenge von unterscheidbaren Objekten aus
z Die Struktur von Objekten ergibt sich durch Attribute mit
jeweiligen Wertebereichen
yWir gehen von verschiedenen Wertebereichen (Zahlen,
Zeichenketten, usw.) zur Strukturbeschreibung aus
z Assoziationen beschreiben Beziehungen zwischen
einzelnen Objekten (etwas ungenau wird auch von
Beziehungen zwischen Begriffen gesprochen)
36
Methodisches Vorgehen: Finde Begriffe (1)
1. Identifiziere Begriffe über die „Substantivmethode“
yRelevante Dokumente: Lastenheft, Anwendungsfalldokumentation,
Glossar, Formulare, technische Systembeschreibungen,
Gesprächsnotizen, ...
yIdentifiziere Substantive (Begriffe, Konzepte), die für das
Problemverständnis relevant sind
⌧Technik: Unterstreichen im Text, lieber zunächst zu viele Substantive als zu wenige
yIdentifiziere Synonyme, Akronyme.
⌧Zwei verschiedene Namen sind Synonyme, falls sie die gleiche Menge von Objekten
bezeichnen
⌧Ein Akronym (Initialwort) ist ein Name, der aus den Anfangsbuchstaben eines Namens
gebildet wird
yIdentifiziere Homonyme.
⌧Ein Homonym ist ein Name, der zwei (verschiedene) Mengen von Objekten benennt
yOptional: Identifiziere Oberbegriffe / Unterbegriffe
⌧Ein Begriff ist ein Oberbegriff (Unterbegriff), wenn er einen Obermenge (Untermenge)
von Objekten bezeichnet
37
Methodisches Vorgehen: Finde Begriffe (2)
2. Kategorisiere die Substantive
yKonkrete Objekte bzw. Dinge, z.B. Pkw
yPersonen und deren Rollen, z.B. Kunde, Mitarbeiter, Dozent
yInformationen über Aktionen, z.B. Banküberweisung
yOrte, z.B. Wartezimmer
yOrganisationen, z.B. Filiale
ySchnittstellen des Systems, z.B. Liste, Auswahlliste
yBeziehungen zwischen Begriffen, z.B. Mietvertrag zwischen Kunde und
Mietobjekt
yAllgemeine und fachbezogene Informationen, z.B. Artikel, Seminartyp
38
Methodisches Vorgehen: Finde Begriffe (3)
3. Streiche Substantive, die keine eigenständigen Begriffe
bezeichnen
yStreichen aller Mehrfachnennungen, sowie der Irrelevanten oder
derjenigen, die ausserhalb des Kontexts liegen.
yGestrichene Substantive können evtl. in einer To-Do-Liste gesammelt
werden, da sie später bei der Identifikation relevanter Attribute,
Operationen und Beziehungen hilfreich sind.
yStreiche Namen für Rollen, die ein Begriff in einer Beziehung zu
einem anderen Begriff spielt.
yIndizien für zu streichende Substantive:
⌧Es lassen sich weder Attribute noch Funktionen identifizieren, die sich auf die
Begriffe beziehen.
⌧Das Substantiv modelliert Implementierungsdetails.
⌧Der Begriff ist nur durch Funktionen gekennzeichnet, die sich anderen Begriffen
zuordnen lassen.
39
Methodisches Vorgehen: Finde Begriffe (4)
4. Wähle aussagefähige und verbindliche Namen
yJeder Name für einen Begriff soll
⌧ein Substantiv im Singular sein
⌧so konkret wie möglich gewählt werden
⌧kein Homonym sein
⌧nur in seltenen Fällen ein Akronym sein
5. Dokumentiere jeden Begriff knapp
yEin definierender Satz, z.B.
Eine Seminarbuchung ist ein Dokument, das die Anmeldung eines
Kunden zu einer Seminarveranstaltung dokumentiert.
yListe der Synonyme, eventuell Abgrenzung zu anderen Begriffen
Synonyme: Anmeldung, Reservierung
40
Methodisches Vorgehen: Finde Attribute
1. Identifiziere Attribute im Anschluss an die
Substantivmethode
yIdentifiziere für das Pflichtenheft relevante Attribute eines jeden
Begriffes
yErfasse Attribute nur dann, wenn sie fachlich notwendig sind
2. Überprüfe den Attributnamen
yJeder Attributname soll
⌧ein Substantiv im Singular oder Plural sein
⌧so konkret wie möglich gewählt werden
⌧kein Homonym sein
3. Definiere den Typ der Attribute
yWähle einen der angenommenen Basiswertebereiche
yDer Typ kann auch unspezifiziert oder nur vage spezifiziert bleiben
yKomplex strukturierte Typen sollten u.U. durch eigenständige Begriffe
ersetzt werden.
41
Beispiel: Point of Sale Terminal (2)
zAnwendungsfallbeschreibung
Use Case: Buy item
1. This use case begins when a customer arrives
at a POST checkout with items to purchase.
2. The cashier records the universal product code
(UPC) from each item.
3. The System determines the item price and adds
the item to the running sales transaction.
4. If there is more than one of the same item, the cashier
can enter the quantity as well.
5. The description and the price of the current item are
displayed.
6. ...
42
Beispiel: Point of Sale Terminal (3)
POST
Sale
Item
Cashier
Payment
Product
Catalog
Customer
Sales
LineItem
Store
Product
Specification
Anfänglich identifizierte Begriffe
Manager
Iterativ identifizierte Begriffe
43
Assoziationen zwischen Begriffen
z Assoziationen beschreiben Beziehungen zwischen
Elementen aus Objektmengen, die durch Begriffe
beschrieben sind (assoziierte Begriffe)
yAssoziierte Begriffe treten in verschiedenen Rollen auf
yBeispiel: Vorlesung setzt Vorlesung voraus
⌧Assoziation: Voraussetzung bzw. voraussetzen
⌧Rollen: Vor, Nach
z Teil-Ganzes-Assoziationen
yAggregation
⌧Teile existieren auch ohne das Ganze
⌧Teile können in mehreren Teil-Ganzes-Beziehungen involviert sein
yKomposition
⌧Teile existieren nicht ohne das Ganze
⌧Pro Teil nur ein Ganzes zugeordnet
44
Methodisches Vorgehen: Finde Assoziationen (1)
1. Identifiziere mögliche Assoziationen zwischen Objekten
ySuche in den relevanten Dokumenten nach Verben und nach
Substantiven, die Aktionen oder Prozesse in der
Problembeschreibung identifizieren
yIdentifiziere für jede Assoziation die beteiligten Begriffe
yBevorzuge binäre Assoziationen (d.h. mit zwei beteiligten Begriffen)
2. Kategorisiere diese Assoziationen
yräumliche Nähe (in der Nähe von)
yAktionen (fährt, bucht)
yKommunikation (redet mit)
yBesitz (hat)
yallgemeine Beziehungen (ist abhängig von, ist verheiratet mit)
45
Methodisches Vorgehen: Finde Assoziationen (2)
3. Streiche Assoziationen, die keine Assoziationen sind, die
sich auf bestehende Begriffe beziehen
yStreiche nicht-permanente Beziehungen
yStreiche für das Pflichtenheft irrelevante Assoziationen
yStreiche implementierungsbezogene Assoziationen
4. Falls erforderlich, definiere Assoziations- und
Rollennamen
yAssoziationen sind in der Mehrzahl der Fälle durch die
partizipierenden Begriffe eindeutig bestimmt. In diesem Fall sind
Assoziations- und Rollennamen nicht erforderlich.
yAnsonsten (z.B. bei rekursiven Assoziationen) definiere
⌧einen Namen (ein Verb oder eine Verbalphrase) für die Assoziation
⌧einen Rollennamen für jeden an der Assoziation beteiligte Begriff
⌧einen Satz, der die Semantik der Assoziation beschreibt.
46
Methodisches Vorgehen: Finde Assoziationen (3)
5. Bestimme die Kardinalität jeder Rolle jeder Assoziation
yLiegt eine Muss-Beziehung vor?
⇒ Kardinalität 1..
⌧Sobald das Objekt erzeugt ist, muss auch die Beziehung zu dem anderen Objekt
aufgebaut werden.
yLiegt eine Kann-Beziehung vor?
⇒ Kardinalität 0..
⌧Die Beziehung kann zu einem beliebigen Zeitpunkt nach dem Erzeugen des Objekts
erzeugt werden.
yIst die Obergrenze fest oder variabel?
⇒ Kardinalität ..k
⌧Ist eine Obergrenze vom Problem her zwingend vorgegeben?
⌧Im Zweifelsfall immer mit variablen Obergrenzen arbeiten!
yGelten besondere Bedingungen?
⌧Gerade Anzahl, Untergrenze, ...
Bemerkung: Bei einer festen Kardinalität k (z.B. 2 als Unterund Obergrenze) ist zu prüfen, ob nicht k separate
Assoziationen zu verwenden sind.
47
Methodisches Vorgehen: Finde Assoziationen (4)
5. Unterscheide Assoziation und Aggregation anhand der
folgenden Kann-Kriterien:
yLässt sich die Beziehung durch „besteht aus“ oder „ist Teil von“
beschreiben? à Aggregation
(Kollektion, Behälter, Ganzes & Teile, Gruppe & Mitglied)
yIst die Kardinalität auf einer Seite der Assoziation 1 oder 0..1 ? à
Aggregation
yIst die Assoziation transitiv und asymmetrisch? à Aggregation
yErfolgt der Zugriff auf die Teilobjekte ausschließlich über das AggregatObjekt? à Aggregation
yIst die Lebensdauer der Komponente durch die Lebensdauer des
Aggregats beschränkt? à Aggregation
48
Methodisches Vorgehen: Finde Assoziationen (5)
6. Entscheide, ob ein Schnappschuss oder eine Historie zu
modellieren ist
ySchnappschuss: Wer ist augenblicklich Chef der Abteilung?
yHistorie: Wer war zum Zeitpunkt t Chef der Abteilung?
7. Dokumentiere Restriktionen auf der Assoziation
yOrdnung auf den Beziehungen {ordered}
yAbgeleitete Beziehungen {derived as ...}
yKonsistenzbeziehungen im Bezug auf andere Beziehungen
Bemerkung
yIn dieser Phase der Analyse werden Generalisierungen u.U. noch
nicht beachtet.
49
Modellierung von Homomorphismen
z Homomorphismen treten in der Praxis häufig auf, z.B.
y Dienstleistung entspricht Dienstleistungsangebot
z Modellierungsalternative A
z Komplexe Restriktionen auf
Begriffen
z {for all ü in r.Übernachtung:
some üa in
r.Reiseangebot.Übernachtungsangebot
(üa = ü.Übernachtungsangebot)}
z Modellierungsalternative B
z Beziehung zwischen Assoziationen
mit zugehöriger Restriktion.
Reise
Reiseangebot
Übernachtung
Übernachtungs
angebot
Reise
Reiseangebot
{subset}
Übernachtung
Übernachtungs
angebot
50
Zielorientiertes Modell: KAOS
51
KAOS - Übersicht
52
Typen
53
54
55
56
57
58
59
60
Kommentare
zVerfeinerung bis keine mehr möglich bildet Basis für
Abbildung nach UML
zEs existiert ein UML Profile für KAOS
zUML basiertes Modell kann in den UML basierten
Modellierungsprozess eingebunden werden.
61
Pflichtenheft
zNoch fehlend
yQualitätsangaben
yAngaben zum Test (Abnahmekriterien)
62
Qualität bei Individualsoftware
z Zur Erinnerung
Auftraggeber
Qualitätsanforderungen
Anfrage (Analyseauftrag)
Auftragnehmer
Anforderungsermittlung
Qualitätsverpflichtung
Angebot (Leistung, Preis)
Auftrag
Produkt
(AG)
Abnahme
(AN)
Wartung, Support
Qualitätskontrolle
Qualitätsmanagement
z Ziel des Qualitätsmanagements beim Auftragnehmer ist die
Erreichung von Qualitätsanforderungen in der gesamten Lebensdauer der
Software
63
Metriken und ihre Eigenschaften (1)
z Eine Metrik (ein Maßsystem) ist eine Algebra, die meßbare
Eigenschaften durch Zahlen (Maßzahlen) ausdrückt.
z Metriken lassen sich anhand der für die Maßzahlen gültigen
algebraischen Regeln (Skalen) klassifizieren:
y Eine Nominalskala definiert eine endliche, ungeordnete Menge von diskreten
Merkmalsausprägungen.
Beispiel: Grundfarben.
Operationen: Gleichheitstest
y Eine Ordinalskala ist eine Nominalskala erweitert um eine vollständige
Ordnung, und ist daher isomorph zu einer monoton steigenden Folge
natürlicher Zahlen. Beispiele: Einkommen (hoch, mittel, niedrig).
Zusätzliche Operationen: Ordnungstest, Median, Rang.
Minimalanforderung an SW-Qualitätsmaß
y Eine Intervallskala ist eine Ordinalskala erweitert um ein Abstandsmaß.
Beispiele: Schulnoten, Flutmarken.
Zusätzliche Operationen: Arithmetisches Mittel und Standardabweichung,
Differenz.
64
Metriken und ihre Eigenschaften (2)
yEine Rationalskala verwendet als Maßzahlen reelle Zahlen und eine
Maßeinheit. Dabei kann ein absoluter oder natürlicher Nullpunkt
vorhanden sein. Beispiele: Preise, Längen, Volumina, Zeiten.
Zusätzliche Operationen: Multiplikation, Division.
yEine Absolutskala verwendet als Maßzahlen reelle Zahlen.
Eine Skalenverschiebung ist nicht möglich.
Beispiele: Anzahl Codezeilen, Kommentardichte, Häufigkeiten.
65
Beispiel: Qualitätsstufen nach ISO 9126
voll geeignet
Meßwert
gut geeignet
Qualitätseinstufung
akzeptabel
ausreichend
geeignet
schlecht
geeignet
Maßskala
nicht
akzeptabel
Qualitätsstufen
66
Maßtheoretische Grundlagen
Nach: Clemens Holzmann
Seminar Programmierstil, WS2002/03
Institut für Systemsoftware
Univ. Linz
Skalenhierarchie am Beispiel eines Softwaremoduls
Anwendungsbereich
f: reale Welt → Zahlenbereich
Absolutskala
Skala: Logistik, Personal,
Rechnungswesen
Verhältnisskala
Anzahl an
Codezeilen
Skala: nicht-negative
ganze Zahlen
Intervallskala
Ordinalskala
Nominalskala
Eignung für kleine
Unternehmen
Skala: --, -, o, +, ++
Kosten (Preis
eines Moduls)
Verfügbarkeit
Skala: Kalendertage
Skala: EURO
67
Beispiele für Metriken (1)
Kategorie
Eingabedaten
Anzahl
Abfragen
Ausgaben
Datenbestände
Referenzdaten
Klassifizierung
einfach
mittel
komplex
einfach
mittel
komplex
einfach
mittel
komplex
einfach
mittel
komplex
einfach
mittel
komplex
Summe
Einflußfaktoren
(ändern den Function
Point-Wert um ± 30%)
Quelle: IBM 85, S. 12
IBMWerte
E3 = E2 / 100 =+ 0.7
Summe der 7 Einflüsse
Faktor Einflußbewertung
= E2 100 + 0,7 E3
Bewertete Function
Points: E1 * E3
Gewichtung
x3
x4
x6
x3
x4
x6
x4
x5
x7
x7
x 10
x 15
x5
x7
x 10
E1
1 Verflechtung mit anderen
Anwendungssystemen (0–5)
2 Dezentrale Daten,
dezentrale Verarbeitung (0–5)
3 Transaktionsrate (0–5)
4 Verarbeitungslogik
a Rechenoperationen (0–10)
b Kontrollverfahren (0–5)
c Ausnahmeregelungen (0–10)
d Logik (0–5)
5 Wiederverwendbarkeit (0–5)
6 DatenbestandsKonvertierungen (0–5)
7 Anpaßbarkeit (0–5) =
E2
Zeilensumme
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
z 3. Schritt
=
=
=
=
=
=
=
=
z 4. Schritt
z Berechnung der
Gewichtung
=
=
=
=
68
Beispiele für Metriken (2)
Nach: Clemens Holzmann
Seminar Programmierstil, WS2002/03
Institut für Systemsoftware
Univ. Linz
z LOC (lines of code)
y ☺ Starke Korrelation mit anderen Maßen
y L Komplexität von Anweisungen und Ablaufstrukturen
unberücksichtigt, abhängig von Programmierstil/ -sprache
z Halstead
Umfang V = (N1+N2) * ld(n1+n2)
n1,n2
N1,N2
Operator
Operand
Anzahl unterschiedl. Operatoren, Operanden
Gesamtzahl verwendeter Operatoren, Operanden
kennzeichnet Aktionen (+, *, While, For, ...)
kennzeichnet Daten (Variablen, Konstanten, ...)
Schwierigkeit L = (n1/2) * (N2/n2)
Testaufwand E = (V/L)
y ☺ Komplizierte Ausdrücke sowie viele verschiedene Variablen
berücksichtigt
y L Ablaufstrukturen unberücksichtigt
berücksichtigt nur lexikalische/textuelle Komplexität
69
Beispiel
70
71
Nach: Clemens Holzmann
Seminar Programmierstil, WS2002/03
Institut für Systemsoftware
Univ. Linz
Beispiele für Metriken (3)
z McCabe
y Programm wird als gerichteter Graph dargestellt
y ☺ Einfach zu berechnen
y L Komplexität von Anweisungen unberücksichtigt
Allgemein
Sequenz
Abweisende
Schleife
Auswahl
V(g) = e – n + 2p
e … Anzahl der Kanten
n … Anzahl der Knoten
p … Anz. verbundener Komponenten
T
IF
F
FOR
T
F
Bei nur einem Ein- und Ausgang
V(g) = 1 + Anzahl der
Binärverzweigungen
V(g) = 1-2+2 = 1
V(g) = 1+0 = 1
V(g) = 4-4+2 = 2
V(g) = 1+1 = 2
V(g) = 3-3+2 = 2
V(g) = 1+1 = 72
2
73
Zusammenfassung, Kernpunkte
zDefinitionsphase
zPflichtenheft
yInhalt
yStruktur / Gliederungsschema
zAnforderungsanalyse
zProduktmodellierung
zQualität
74
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement