Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

1 Dozenten: Markus Rentschler Andreas Stuckert Version 17.07.2015 Software Engineering I VE 08: Analysephase Vorlesung Software Engineering I Analysephase.

Ähnliche Präsentationen


Präsentation zum Thema: "1 Dozenten: Markus Rentschler Andreas Stuckert Version 17.07.2015 Software Engineering I VE 08: Analysephase Vorlesung Software Engineering I Analysephase."—  Präsentation transkript:

1 1 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase Vorlesung Software Engineering I Analysephase

2 2 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase Entwicklungsphasen: Inputs, Outputs Analyse Design CodierungTest EinführungWartung SAS, MODs Implementierung, Modultests Bugreports Change Requests (CRQ) SAS, MODs Implementierung, Modultests Systemtestplan (STP), Systemvalidierungsplan (SVP) SAS, MODs, Implementierung, Modultests Kundenanforderungen, Lastenheft (CRS Pflichtenheft (SRS) Systemspezifikation (Grob-,Feinentwurf) Bugreports Change Requests (CRQ) Systemmodellierung, Pflichtenheft (SRS) Bugreports, Change Requests (CRQ) Systemtestreport (STR), Systemvalidierungs- report (SVR ) MODs, Systemintegrations- report (SIR) Architekturspezifikation (SAS), Modulspezifikationen (MODs)

3 3 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase 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).

4 4 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase Analyse Anforderungs- Ermittlung Anforderungsanalyse, Systemmodellierung Produkt- Spezifikation (Pflichtenheft) “Projektstart“ Analysephase  Designphase Anforderungs- Spezifikation (Lastenheft) Design Architekturentwurf Detailentwurf Architektur- Spezifikation Modul-/Klassen- Spezifikationen

5 5 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase 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

6 6 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase 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)!

7 7 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase 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.

8 8 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase 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

9 9 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase 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

10 10 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase Basiskonzepte zur Modellierung informal semiformal formal textuell grafisch Text Nummerierte Anforderungen Pseudocode Entscheidungstabellen Regeln Data Dictionary Petri-Netz (textuell) Kollaborationsdiagramm Sequenzdiagramm Struktogramm Entscheidungs- bäume Zustands- automat DFDs ERD Klassendiagramm Petri- Netze Funktionsbaum

11 11 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase Systemanalyse mit UML UML Design Pattern

12 12 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase UML Design Pattern

13 13 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase 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

14 14 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase SA/SD Strukturierte Analyse

15 15 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase 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/)http://www.yourdon.com/ –SA/RT Ergänzt um Modellierung für Dynamik

16 16 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase 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

17 17 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase 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.

18 18 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase DFD: Datenflüsse

19 19 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase 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 = !Typ Funktionsname = !Aktion

20 20 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase DFD: Fehlermöglichkeiten Folgendes funktioniert nicht, bzw ist nicht sinnvoll:

21 21 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase 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?).

22 22 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase SA: Hierarchiekonzept

23 23 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase 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

24 24 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase 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.

25 25 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase 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 DFD n.m...

26 26 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase 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

27 27 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase 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 SymbolBedeutungBsp =ist äquivalent zuA=B +SequenzA=B+C [ | ]Auswahl (xor)A=[B|C] { }WiederholungA={B} N{ }M Wiederholung N-M malA=1{B}5 ( )OptionA=B+(C) * *Kommentar*muss* Data Dictionary (DD)

28 28 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase 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 + Adresse Buch = Buch_id + Autor + Titel + Preis Buchliste = {Buch} Einkauf = {Bestellung + Gesamtbetrag} Kundenliste = {Kunde} Kundenstatus = [“reich” | “arm”] Zimmerart = [”Einzelzimmer” | “Doppelzimmer”] * Ein Kommentar ist immer wichtig. *

29 29 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase 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

30 30 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase Strukturierte Analyse - Design Pattern Methodik zur Systemmodellierung mit der SA: 1.Schnittstellen und Ein/Ausgaben finden 2.Funktionen finden 3.Speicher finden 4.Datenflüsse finden 5.Data Dictionary erstellen 6.Konsolidieren des Modells 7.Iterative Verfeinerung 8.Mini-Spezifikationen erstellen

31 31 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase 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

32 32 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase Data Function Data Function Data Systemlayout SA/SD vs. OOAD

33 33 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase SA/SD: Funktionsbaum  DFD SD: Transformation der DFD-Prozesse in hierarchisch strukturierte Funktionen

34 34 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase SD: Transformation Analyse  Design A BDEFG CHK Do job A B CG FED K H

35 35 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase 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!

36 36 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase Beispiel Strukturierte Analyse Seminarverwaltung

37 37 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase Beispiel SA: Kontextdiagramm

38 38 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase Beispiel SA: DFD Ebene 0

39 39 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase Beispiel SA: DFD Ebene 0 mit Speicher

40 40 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase Beispiel SA: DFD Verfeinerung (Ebene 1)

41 41 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase Beispiel SA: DD und DFD (Ausschnitt)

42 42 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase Beispiel SA: MiniSpec

43 43 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase ERD Entity Relationship Diagramme

44 44 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase 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

45 45 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase ERD: Grundlegende Begriffe

46 46 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase 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 des angegebenen 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)

47 47 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase ERD: Beispiel Kunden Preis #PosNr Menge bekommt Rechnung enthält Rechnungs- positionen kommt vor in Name #KdNr Adresse Artikel Grösse#ArtNrFarbe interessiert an (0,*)(1,1) (1,*) (1,1) (0,*)

48 48 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase Übungen

49 49 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase Übung: Pflichtenheft Gegeben 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, ), 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,

50 50 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase Ü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

51 51 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase Ü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

52 52 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 08: Analysephase Ü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


Herunterladen ppt "1 Dozenten: Markus Rentschler Andreas Stuckert Version 17.07.2015 Software Engineering I VE 08: Analysephase Vorlesung Software Engineering I Analysephase."

Ähnliche Präsentationen


Google-Anzeigen