Upload
thilo-berg
View
223
Download
1
Embed Size (px)
Citation preview
Version 04/26/23
Software Engineering I VE 08: Analysephase 1
Dozenten:Markus RentschlerAndreas Stuckert
Vorlesung
Software Engineering I
Analysephase
Version 04/26/23
Software Engineering I VE 08: Analysephase 2
Dozenten:Markus RentschlerAndreas Stuckert
Entwicklungsphasen: Inputs, Outputs
Analyse Design Codierung Test Einführung Wartung
SAS, MODsImplementierung,
Modultests
BugreportsChange Requests (CRQ)
SAS, MODsImplementierung,
Modultests
Systemtestplan (STP),Systemvalidierungsplan
(SVP)
SAS, MODs,Implementierung,
ModultestsKundenanforderungen,
Lastenheft (CRS
Pflichtenheft (SRS)Systemspezifikation (Grob-,Feinentwurf)
BugreportsChange Requests (CRQ)
Systemmodellierung,Pflichtenheft (SRS) Bugreports,
Change Requests (CRQ)
Systemtestreport (STR),Systemvalidierungs-
report (SVR)
MODs,Systemintegrations-
report (SIR)
Architekturspezifikation (SAS),
Modulspezifikationen (MODs)
Version 04/26/23
Software Engineering I VE 08: Analysephase 3
Dozenten:Markus RentschlerAndreas Stuckert
Analysephase
• Beschreibung des zu lösenden Problems und aller wichtigen Umgebungsbedingungen - möglichst vollständig und eindeutig.
• Ergebnis der Anforderungsermittlung ist das Lastenheft (CRS), welches die Kundenanforderungen enthält (Klärung des WAS)
• Untersuchung der Durchführbarkeit der geplanten Systementwicklung
• Ergebnis der Anforderungsanalyse ist das Pflichtenheft (SRS), welches die aus den Kundenanforderungen abgeleitete Systemanforderungen und ein Systemmodell enthält (Klärung des WIE aus Black-Box-Sicht).
Version 04/26/23
Software Engineering I VE 08: Analysephase 4
Dozenten:Markus RentschlerAndreas Stuckert
Analyse
Anforderungs-Ermittlung
Anforderungsanalyse, Systemmodellierung
Produkt-Spezifikation(Pflichtenheft)
“Projektstart“
Analysephase Designphase
Anforderungs-Spezifikation(Lastenheft)
Design
Architekturentwurf
Detailentwurf
Architektur-Spezifikation
Modul-/Klassen-Spezifikationen
Version 04/26/23
Software Engineering I VE 08: Analysephase 5
Dozenten:Markus RentschlerAndreas Stuckert
Die Analysephase
• Ziel der Analysephase ist die– vollständige– konsistente– eindeutige
Definition des zu realisierenden Produkts durch die Spezifizierung eines Produktmodells.
• Das Produktmodell kann bestehen aus: – Pflichtenheft (Vertragsgrundlage!)– Analysemodell– Prototypen
Version 04/26/23
Software Engineering I VE 08: Analysephase 6
Dozenten:Markus RentschlerAndreas Stuckert
Das Pflichtenheft
• Aufgabe:– Zusammenfassung aller fachlichen Anforderungen
• Adressaten:– Auftraggeber, Auftragnehmer (Projektleiter, Systemanalytiker,
Entwickler, ...)
• Inhalt: – fachlicher Funktions-, Daten- und Leistungsumfang,
Qualitätsanforderungen– Abnahmekriterien (spätestens hier festzulegen)!
Version 04/26/23
Software Engineering I VE 08: Analysephase 7
Dozenten:Markus RentschlerAndreas Stuckert
Pflichtenheft: Standards
• Ein sehr bekannter Standard zum Requirements Management ist der IEEE 830 (Recommended Practice for Software Requirements Specifications). Er ist ein konkreter praxisnaher Standard für die Beschreibung und die Definition von Softwareanforderungen. Es werden Strukturen vorgeben für den Aufbau der Dokumentation, den Aufbau der einzelnen Anforderungen und sogar zur Formulierung der Anforderungen.
• Eine gute Ergänzung hierzu ist der Standard IEEE 1362 (Guide for Information Technology – System Definition, Definition - Concept of Operations Document), der letztendlich ein Standard für Anforderungsdokumente (Lasten-/Pflichtenhefte) darstellt.
• Eine weitere sinnvolle Ergänzung zu den beiden genannten Standards sind die Spezifikationen aus VDI 2519 – Blatt 1 (Vorgehensweise bei der Erstellung von Lasten-/Pflichtenheften). Hier wird definiert was Lasten- und Pflichtenhefte sind, was sie enthalten sollten und wie sie erstellt werden sollten.
Version 04/26/23
Software Engineering I VE 08: Analysephase 8
Dozenten:Markus RentschlerAndreas Stuckert
Methodik zur Erstellung des Produktmodells
1. (Iterative) Erstellung des Pflichtenheftes
2. Begleitend auf Basis des Pflichtenhefts:– Iterative Erstellung eines Produktmodells unter Einsatz der
gewählten Methoden (z.B. SA/SD, OOAD)– Iterative Konzeption der Benutzungsoberfläche, ggf.
Erstellung eines entsprechenden Prototyps– Erstellung einer ersten Version des Benutzerhandbuches
Version 04/26/23
Software Engineering I VE 08: Analysephase 9
Dozenten:Markus RentschlerAndreas Stuckert
Modellierungskonzepte
• Modellierungskonzepten werden verwendet zur Anforderungsspezifikation
• Sie beschreiben das System aus verschiedenen Sichten (Statik, Dynamik, Logik)
• Auftraggeber und Auftragnehmer müssen diese Modellierungskonzepte (Notationen) verstehen.
• Heute weitverbreitet: UML-Diagramme
Version 04/26/23
Software Engineering I VE 08: Analysephase 10
Dozenten:Markus RentschlerAndreas Stuckert
Basiskonzepte zur Modellierung
informal semiformal formal
text
uell
graf
isch
TextNummerierte
Anforderungen
Pseudocode
Entscheidungstabellen
RegelnData
Dictionary Petri-Netz
(textuell)
Kollaborationsdiagramm
Sequenzdiagramm
Struktogramm
Entscheidungs-bäume
Zustands-automat DFDs
ERD
Klassendiagramm
Petri-Netze
Funktionsbaum
Version 04/26/23
Software Engineering I VE 08: Analysephase 11
Dozenten:Markus RentschlerAndreas Stuckert
Systemanalyse mit UML
UML Design Pattern
Version 04/26/23
Software Engineering I VE 08: Analysephase 12
Dozenten:Markus RentschlerAndreas Stuckert
UML Design Pattern
Version 04/26/23
Software Engineering I VE 08: Analysephase 13
Dozenten:Markus RentschlerAndreas Stuckert
UML Design Pattern
Verhaltensorientierte Methodik zur Systemmodellierung mit der UML:
1. Anwendungsfälle ermitteln– Ermitteln aller Aktoren und Uses Cases aus Benutzersicht– Jeden Use Case mit Szenarios (Aktivitätendiagramme, Sequenzdiagramme) beschreiben
2. Systemobjekte und -daten identifizieren– In den Use-Case-Szenarios die Systemobjekte und -daten identifizieren– Für die identifizierten Systemobjekte und –daten Klassendiagramme erstellen
3. Systemarchitektur modellieren– Klassendiagramme in Komponentendiagrammen sinnvoll gruppieren – Schnittstellen entwerfen– Komponenten im Verteilungsdiagramm sinnvoll gruppieren
4. Systemdynamik modellieren– Anhand der Use-Case-Szenarios für die Interaktion der Aktoren und Objekte
Sequenzdiagramme ableiten– Für die Klassendiagramme anhand der Sequenzdiagramme Zustandsdiagramme erstellen
5. Implementierung– Klassen ausprogrammieren
Version 04/26/23
Software Engineering I VE 08: Analysephase 14
Dozenten:Markus RentschlerAndreas Stuckert
SA/SD
Strukturierte Analyse
Version 04/26/23
Software Engineering I VE 08: Analysephase 15
Dozenten:Markus RentschlerAndreas Stuckert
Strukturierte Analyse (SA)
• DeMarco, 1975, „Structured Analysis and System Specification“
• Varianten der Strukturierten Analyse:
– Weinberg, 1978: “Structured Analysis”– Gane & Sarson, 1979: “Structured Systems Analysis”– McMenamin & Palmer, 1984: “Modern Structured Analysis”– Yourdon, 1989: “Modern Structured Analysis”
• Hier werden die Erfahrungen der Strukturierten Analyse seit dem Erscheinen von DeMarco’s Methode gebündelt. Es wird keine neue Methode propagiert, jedoch wird die Strukturierte Analyse im gesamten Umfeld des Software-Engineering betrachtet. (http://www.yourdon.com/)
– SA/RT• Ergänzt um Modellierung für Dynamik
Version 04/26/23
Software Engineering I VE 08: Analysephase 16
Dozenten:Markus RentschlerAndreas Stuckert
SA: Konzepte
Die Strukturierte Analyse fußt im Wesentlichen auf folgenden, miteinander verknüpften Basiskonzepten:
1. Datenflussdiagramm (Data Flow Diagram (DFD))• Strukturierung des Systems• Funktionen und Daten und ihr Zusammenwirken
2. Datenlexikon (Data Dictionary (DD))• Strukturierung der Daten• Detaillierte Datenbeschreibung
3. Primitive Prozessspezifikation (MiniSpec)• Detaillierte Funktionsbeschreibung
4. Funktionsbaum• Strukturierung der Funktionen
Version 04/26/23
Software Engineering I VE 08: Analysephase 17
Dozenten:Markus RentschlerAndreas Stuckert
DFD: Definitionen• Datenflüsse sind vergleichbar mit Pipelines, durch die Daten transportiert
werden.
• Datenspeicher bilden eine Ablagemöglichkeit für Daten, bei denen sich der Erstellungszeitpunkt vom Gebrauchszeitpunkt unterscheidet.
• Prozesse haben die Aufgabe, Eingabedaten in Ausgabedaten zu verarbeiten und enthalten die hierfür notwendigen Algorithmen.
• Terminatoren (Schnittstellen) stehen für die Beziehungen des Systemes zur Außenwelt. Sie senden oder empfangen Daten, verarbeiten diese jedoch nicht.
Version 04/26/23
Software Engineering I VE 08: Analysephase 18
Dozenten:Markus RentschlerAndreas Stuckert
DFD: Datenflüsse
Version 04/26/23
Software Engineering I VE 08: Analysephase 19
Dozenten:Markus RentschlerAndreas Stuckert
DFD: Semantische Regeln
• DFD beschreibt den Datenfluss, nicht den Kontrollfluss
• Schnittstellen sind so zu wählen, dass die ursprüngliche Datenquelle und Senke angegeben werden (Also die Benutzerrolle, nicht bspw. Tastatur und Drucker)
• Datenflussname = <Substantiv> !Typ
• Funktionsname = <Verb><Objekt> !Aktion
Version 04/26/23
Software Engineering I VE 08: Analysephase 20
Dozenten:Markus RentschlerAndreas Stuckert
DFD: Fehlermöglichkeiten
• Folgendes funktioniert nicht, bzw ist nicht sinnvoll:
Version 04/26/23
Software Engineering I VE 08: Analysephase 21
Dozenten:Markus RentschlerAndreas Stuckert
Strukturierte Analyse
• Unter Anwendung von Datenflussdiagrammen (DFD) wird eine hierarchische Betrachtung des Systems modelliert.
– Kontextdiagramm (nullte Ebene): Beschreibt die Umwelt des Systemes, es gibt genau einen Prozess.
– Diagramm 0 (erste Ebene): Der Gesamtsystems-Prozess, Prozess 0, wird in Subsysteme zerlegt; Angabe der Daten, welche zwischen den Subsystemen bzw. Teilfunktionen fließen.
– Subdiagramme (n-te Ebene): Prozessverfeinerung, Zerlegung des vorherigen Subsystemes in weitere Subsysteme.
– MiniSpec: Wurde ein Prozess ausreichend verfeinert, wird er abschließend durch eine MiniSpec beschrieben.
• Prozesse, Datenspeicher und Datenflüsse sollen mit einem möglichst prägnanten Namen versehen werden. Zum Beispiel: “prüfe Passwort”, aber nicht: “verarbeite Datei” (Welche Datei? - Wie wird sie verarbeitet?).
Version 04/26/23
Software Engineering I VE 08: Analysephase 22
Dozenten:Markus RentschlerAndreas Stuckert
SA: Hierarchiekonzept
Version 04/26/23
Software Engineering I VE 08: Analysephase 23
Dozenten:Markus RentschlerAndreas Stuckert
SA: Kontextdiagramm
• Syntax– enthält nur einen Prozess, dieser erhält die Nummer 0 und stellt
das Gesamtsystem dar– verfügt über mindestens eine Schnittstelle
• Semantik– beschreibt den Anwendungsbereich des modellierten Systemes– zeigt Datenflüsse, welche Systemgrenzen überschreiten– ist die Zusammenfassung von Diagramm 0
Version 04/26/23
Software Engineering I VE 08: Analysephase 24
Dozenten:Markus RentschlerAndreas Stuckert
SA: Diagramm 0
• Das Diagramm 0 beschreibt die Verfeinerung des Kontextdiagrammes:– Der Prozess 0 aus dem Kontextdiagramm wird in
Teilprozesse zerlegt.– Speicher werden eingefügt.
Version 04/26/23
Software Engineering I VE 08: Analysephase 25
Dozenten:Markus RentschlerAndreas Stuckert
SA: Prozessverfeinerung
• Jeder Prozess kann wieder zu einem neuen Diagramm verfeinert werden, welches folgende Bedingungen erfüllen muss:
– Der Prozess wird in Teilprozesse zerlegt.– Jeder Prozess wird fortlaufend nummeriert.– Wurde ein Prozess ausreichend verfeinert, wird er abschließend
durch eine MiniSpec beschrieben.– Die Anzahl der Prozesse pro Diagramm sollte sieben nicht
überschreiten.
DFD 1, DFD 2, DFD n ... DFD 1.1, DFD 1.2 ... DFD n.m ...
Version 04/26/23
Software Engineering I VE 08: Analysephase 26
Dozenten:Markus RentschlerAndreas Stuckert
SA: Mini Specs
• Bei den MiniSpecs handelt es sich um Subsysteme, welche nicht mehr (sinnvoll) durch Datenflussdiagramme aufgeteilt werden können. Sie beschreiben implementierungsunabhängig, wie Eingangsdaten in Ausgangsdaten umgewandelt werden.
• Erscheint eine Verfeinerung für eine Funktion nicht mehr als sinnvoll, so wird zu dieser Funktion eine Mini Spec angegeben. Diese sollte mit einer der folgenden Methoden erstellt werden:
– Pseudo Code– Struktogramm / Programmablaufplan– Entscheidungstabelle / -baum
Version 04/26/23
Software Engineering I VE 08: Analysephase 27
Dozenten:Markus RentschlerAndreas Stuckert
Das Datenlexikon ist ein Verzeichnis, das Informationen über die Struktur von Daten, ihre Eigenschaften und ihre Verwendung enthält.
Engl.: Data Dictionary (DD)
Zur Beschreibung der Speicherinhalte
Symbol Bedeutung Bsp
------------------------------------------------------------------
-
= ist äquivalent zu A=B
+ Sequenz A=B+C
[ | ] Auswahl (xor) A=[B|C]
{ } Wiederholung A={B}
N{ }M Wiederholung N-M mal A=1{B}5
( ) Option A=B+(C)
* * Kommentar *muss*
Data Dictionary (DD)
http://de.wikipedia.org/wiki/Data_Dictionary
Version 04/26/23
Software Engineering I VE 08: Analysephase 28
Dozenten:Markus RentschlerAndreas Stuckert
DD: Beispiel
Artikeldaten = Artikel_id + Erstellungsdatum + Titel + Text
Benachrichtigungsschreiben = [Account angelegt | Account gelöscht | Nachricht von anderem Nutzer]
Artikelanfrage = User_id + 1{ Artikel_id }20
Kunde = Kunden_id + Name + AdresseBuch = Buch_id + Autor + Titel + PreisBuchliste = {Buch}Einkauf = {Bestellung + Gesamtbetrag}Kundenliste = {Kunde}Kundenstatus = [“reich” | “arm”]
Zimmerart = [”Einzelzimmer” | “Doppelzimmer”]
* Ein Kommentar ist immer wichtig. *
Version 04/26/23
Software Engineering I VE 08: Analysephase 29
Dozenten:Markus RentschlerAndreas Stuckert
SA: Integritätsregeln
• In der Strukturierten Analyse sind folgende Integritätsregeln zu beachten:
– Jeder Datenfluß hat einen Namen. Ausnahme: Zugriff auf einen kompletten Speicherinhalt
– Jeder Datenflußname ist im DD beschrieben
– Jeder Speicher hat einen Namen
– Jeder Speichername ist im DD beschrieben
– Alle Datenflüsse in einem untergeordneten DFD müssen im übergeordneten DFD vorkommen oder eine Komponente eines Datenflusses aus dem übergeordneten DD sein.
– Die Komponenteneigenschaft ergibt sich aus dem DD
Version 04/26/23
Software Engineering I VE 08: Analysephase 30
Dozenten:Markus RentschlerAndreas Stuckert
Strukturierte Analyse - Design Pattern
Methodik zur Systemmodellierung mit der SA:
1. Schnittstellen und Ein/Ausgaben finden2. Funktionen finden3. Speicher finden4. Datenflüsse finden5. Data Dictionary erstellen6. Konsolidieren des Modells7. Iterative Verfeinerung8. Mini-Spezifikationen erstellen
Version 04/26/23
Software Engineering I VE 08: Analysephase 31
Dozenten:Markus RentschlerAndreas Stuckert
SA: Vor-/Nachteile
• Stärken der Strukturierten Analyse:– leicht verständlich– Kombination bewährter Basiskonzepte– ermöglicht Top-Down-Erarbeitung des Systems– hierarchische Gliederung sorgt für Übersichtlichkeit– Kontextdiagramm ähnlich wie Use Case– Zusammenhang zu ER-Modellen herstellbar (über Speicher)
• Schwächen der Strukturierten Analyse:– Schnittstellen und Speicher können nicht verfeinert werden– Logik, Dynamik und Kontrollfluss können nicht modelliert werden– nur der Datenfluss wird analysiert – keine Lokalität von Daten, daher kaum für OO geeignet
Version 04/26/23
Software Engineering I VE 08: Analysephase 32
Dozenten:Markus RentschlerAndreas Stuckert
Data
Function
Function
Function
Function
Function
Function
Function
Data
Function
Data
Systemlayout SA/SD vs. OOAD
Version 04/26/23
Software Engineering I VE 08: Analysephase 33
Dozenten:Markus RentschlerAndreas Stuckert
SA/SD: Funktionsbaum DFD
• SD: Transformation der DFD-Prozesse in hierarchisch strukturierte Funktionen
Version 04/26/23
Software Engineering I VE 08: Analysephase 34
Dozenten:Markus RentschlerAndreas Stuckert
SD: Transformation Analyse Design
A B D E F G
C H K
Do job
A
B
C G
FED
K
H
Version 04/26/23
Software Engineering I VE 08: Analysephase 35
Dozenten:Markus RentschlerAndreas Stuckert
Zusammenfassung SA/SD
• Zur Modellierung von Softwaresystemen waren Strukturierte Methoden früher weit verbreitet.
• Strukturierte Analyse (SA) : Erstellung eines logischen Systemmodells, bestehend aus hierarchisch strukturierten DFDs, begleitet von Data Dictionaries, MiniSpecs, etc. Grundsätzlich stellt sich in der strukturierten Analyse folgende Frage: Was soll das geplante Softwaresystem können?
• Strukturiertes Design (SD): beinhaltet Operationsmodell und Modulmodelle. Umsetzung der DFDs aus der SA in Strukturdiagramme. Im strukturierten Design stellt sich dann folgende Frage: Wie sollen die Funktionalitäten des Softwaresystems umgesetzt werden?
• SA/SD ist ein kreativer, nicht formalisierbarer Prozess!
Version 04/26/23
Software Engineering I VE 08: Analysephase 36
Dozenten:Markus RentschlerAndreas Stuckert
Beispiel Strukturierte Analyse
Seminarverwaltung
Version 04/26/23
Software Engineering I VE 08: Analysephase 37
Dozenten:Markus RentschlerAndreas Stuckert
Beispiel SA: Kontextdiagramm
Version 04/26/23
Software Engineering I VE 08: Analysephase 38
Dozenten:Markus RentschlerAndreas Stuckert
Beispiel SA: DFD Ebene 0
Version 04/26/23
Software Engineering I VE 08: Analysephase 39
Dozenten:Markus RentschlerAndreas Stuckert
Beispiel SA: DFD Ebene 0 mit Speicher
Version 04/26/23
Software Engineering I VE 08: Analysephase 40
Dozenten:Markus RentschlerAndreas Stuckert
Beispiel SA: DFD Verfeinerung (Ebene 1)
Version 04/26/23
Software Engineering I VE 08: Analysephase 41
Dozenten:Markus RentschlerAndreas Stuckert
Beispiel SA: DD und DFD (Ausschnitt)
Version 04/26/23
Software Engineering I VE 08: Analysephase 42
Dozenten:Markus RentschlerAndreas Stuckert
Beispiel SA: MiniSpec
Version 04/26/23
Software Engineering I VE 08: Analysephase 43
Dozenten:Markus RentschlerAndreas Stuckert
ERD
Entity Relationship Diagramme
Version 04/26/23
Software Engineering I VE 08: Analysephase 44
Dozenten:Markus RentschlerAndreas Stuckert
Entity-Relationship Modellierung (ERD)
• Ziel ist die Beschreibung von – Gegenständen (Entities, Objekte)– Beziehungen (Relationships)– Eigenschaften (Attribute)
• ER-Modell wird aufgebaut, um– Anwendungsdaten zu strukturieren und zu analysieren– Oft werden daraus Datenbanktabellen aufgebaut
• Modellierung erfolgt über ER-/EER-Diagramme
• Gute Modellierungstools verfügbar– http://de.wikipedia.org/wiki/MySQL_Workbench
Entität
Beziehung
Attribut
Version 04/26/23
Software Engineering I VE 08: Analysephase 45
Dozenten:Markus RentschlerAndreas Stuckert
ERD: Grundlegende Begriffe
Entität Element derRealität
Franz Mayer
Entitätstyp Gruppe gleich-artiger Entitäten
Mitarbeiter
Attribut Entitätseigenschaft PersonalNummer,Name, Anschrift ...
Schlüsselkandidat Identifikations-attribut (minimal)
#PersNr
Wertebereich ZulässigeAttributwerte
#PersNr String(10)
Kardinalität /Komplexität
Quantifizierungvon Beziehungen
Jede Abteilung hatmehrere Mitarbeiter
Mandatorische /Optionale Bez.
Muss-/KannBeziehungen
Ein Mitarbeiterkann einen Chefhaben
Version 04/26/23
Software Engineering I VE 08: Analysephase 46
Dozenten:Markus RentschlerAndreas Stuckert
Entity-Relationship Diagramm (ERD)
A B(1,1)(0,n)
R
0 bis n Genau 1„Jedes A hat 0 bis n Beziehungen zu einem B“
! (n,m) legt das Minimum und Maximum der Anzahl Beziehungen desangegebenen Typs fest, die ein Objekt haben kann.
Möglich und üblich sind: (0,1) höchstens 1(1,1) genau eins(n,m) zwischen n und m mit n,m >= 0
(* für unbekannte Obergrenze)
Version 04/26/23
Software Engineering I VE 08: Analysephase 47
Dozenten:Markus RentschlerAndreas Stuckert
ERD: Beispiel
Kunden
Preis
#PosNr
Menge
bekommt Rechnung
enthält
Rechnungs-positionenkommt
vor in
Name
#KdNr
Adresse
Artikel
Grösse #ArtNrFarbe
interessiertan
(0,*) (1,1)
(1,*)
(1,1)
(1,1)(0,*)
(0,*)
(0,*)
Version 04/26/23
Software Engineering I VE 08: Analysephase 48
Dozenten:Markus RentschlerAndreas Stuckert
Übungen
Übungen
Version 04/26/23
Software Engineering I VE 08: Analysephase 49
Dozenten:Markus RentschlerAndreas Stuckert
Übung: PflichtenheftGegeben seien einige Ausschnitte aus einem Pflichtenheft gemäß dem vorgestellten Pflichtenheft-Muster. Untersuchen Sie diese Ausschnitte auf Fehler.
1 Visionen und Ziele/V10/ Das Produkt dient der Kunden- und Mitarbeiterverwaltung eines Unternehmens.
2 Rahmenbedingungen/R10/ kommerzieller Anwendungsbereich/R20/ Zielgruppe Mitarbeiter des Unternehmens, speziell Verwaltungskräfte
3 Kontext und Überblick/K10/ Zielgruppe sind Mitarbeiter des Unternehmens, speziell Verwaltungskräfte/K20/ Einsatz in Büroumgebung
4 Funktionale Anforderungen/F10/ Verwalten der Mitarbeiter mit Adressen und Gehältern/F20/ Verwalten der Kunden (Firmen und Privatkunden) mit Adressen, Umsatzdaten und Bestellverhalten/F30/ Schnittstellen zu gängiger Bürosoftware (Serienbriefe)/F40/ Typische Listenabfragen/F50/ Typische Reportausgaben/D10/ Zu einem Kunden sind folgende Daten zu speichern: Adresse, Kontakte (Telefon, Fax, Email), typische Zahlungsweise: Seminaranfang, Seminarende,
monatlich mehrere Einzelrechungen
5 Qualitätsanforderungen/Q10/ Das Produkt soll qualitativ hochwertig sein./Q20/ Alle gängigen Betriebssysteme müssen unterstützt werden/Q30/ Alle gängigen Rechnerplattformen müssen unterstützt werden/Q40/ Schnittstellen zu gängiger Windows-Software/L10/ Die Bearbeitungszeit aller Funktionen darf nicht über 100ms liegen./L20/ Die Funktion "Ausdrucken" soll möglichst schnell arbeiten./L30/ Die Kundendaten aus /D10/ sollen ohne sichtbaren Zeitverzug gelöscht werden können.
6 Abnahmekriterien/A10/Gültiges Abnahmeszenario: Einen Kunden erfassen, einen Mitarbeiter erfassen,
Version 04/26/23
Software Engineering I VE 08: Analysephase 50
Dozenten:Markus RentschlerAndreas Stuckert
Übung 1: Datenflussdiagramm
• Zeichnen Sie ein Datenflussdiagramm, das den Seminarverwaltungsteil einer Seminarorganisation beschreibt.
• Berücksichtigen Sie die folgenden funktionalen Anforderungen:– /F10/ Informieren (von Anfrage bis Auskunft)– /F20/ Veranstaltung durchführen– /F30/ Dozenten akquirieren
• Berücksichtigen Sie außerdem die folgenden Daten-Anforderungen:– /D10/ Seminartyp– /D20/ Seminarveranstaltung– /D30/ Dozent
Version 04/26/23
Software Engineering I VE 08: Analysephase 51
Dozenten:Markus RentschlerAndreas Stuckert
Übung 2: Datenflussdiagramm
• Zeichnen Sie ein Datenflussdiagramm zur Verwaltung einer Arztpraxis.
– Neue Patienten werden in eine Patientenkartei aufgenommen, an der auch später noch Änderungen vorgenommen werden können.
– Erscheint ein Patient zur Behandlung, so werden dem behandelnden Arzt die Patientendaten und die Daten der letzten Behandlungen zur Verfügung gestellt.
– Nach der Behandlung werden das Datum, die erbrachten Leistungen und die Verordnungen gespeichert
Version 04/26/23
Software Engineering I VE 08: Analysephase 52
Dozenten:Markus RentschlerAndreas Stuckert
Übung 1: Datenflussdiagramm
• Zeichnen Sie ein Datenflussdiagramm zur Beschreibung des „Generic Assessment Tool“.
• Berücksichtigen Sie die folgenden funktionalen Anforderungen:– /F10/ Assessment Modelle anlegen und verwalten– /F20/ Audit-Projekte anlegen und verwalten– /F30/ Auditoren anlegen und verwalten– /F40/ Audit-Projekt durchführen und auswerten
• Berücksichtigen Sie die folgenden Daten-Anforderungen:– /D10/ Assessment-Modell– /D20/ Audit-Projekt– /D30/ Auditor– /D40/ Auditiertes System