Projektdokument Business Intelligence in the Cloud for Energy

272 Pages·2015·4.06 MB·German

Department fu¨r Informatik
Abteilung Informationssysteme
Projektdokument
Business Intelligence in the Cloud for Energy
BICE
Projekt: BICE
Auftraggeber: Marco Haas, Oliver Norkus
Auftragnehmer: Cloud-BI
Autoren: Projektgruppe Cloud-BI
Datum: 4. Oktober 2015
Inhaltsverzeichnis
1 Einleitung 1
2 Projektorganisation 2
2.1 Projektmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.3 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Meta–Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1 Kommunikations–Radar . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.2 Einsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.3 Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.4 Konsequenzen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Anforderungen 9
3.1 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Anforderungserhebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1 Produkteinsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2 Deckungsbeitragsrechnung . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.3 Gesamtkostenrechnung . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.4 Kennzahlen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.5 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4 Nichtfunktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 System-Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5.1 Musskriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5.2 Wunschkriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5.3 Abgrenzungskriterien . . . . . . . . . . . . . . . . . . . . . . . . . 24
4 Entwurf 26
4.1 U¨berblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.1 Local Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.2 User Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.3 Load Management & Balancing . . . . . . . . . . . . . . . . . . . . 28
4.2.4 Data Retrieval und Accounting . . . . . . . . . . . . . . . . . . . . 28
4.2.5 Datenbanksystem und ETL . . . . . . . . . . . . . . . . . . . . . . 29
4.3 Kennzahlen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.1 Gesamtkosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
ii
4.3.2 Deckungsbeitrag . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4 Betriebsbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5 Implementation 36
5.1 Infrastrukturebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1.1 Load Balancing & Autoscaling . . . . . . . . . . . . . . . . . . . . 36
5.2 Plattformebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3 Softwareebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3.1 Local Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3.2 Dispatcher & Session Management . . . . . . . . . . . . . . . . . . 42
5.3.3 Authentication Management . . . . . . . . . . . . . . . . . . . . . 43
5.3.4 Data Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3.5 Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6 Evaluation 46
6.1 Leistungsspektrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.2 Qualit¨at der Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.2.1 Quelltext-Ebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.2.2 Komponenten-Ebene . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.2.3 System-Ebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.3 Rahmenbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7 Zusammenfassung und Ausblick 55
7.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.2.1 Customer Relationship Management . . . . . . . . . . . . . . . . . 56
7.2.2 ene’t Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.2.3 Energiedaten-Management . . . . . . . . . . . . . . . . . . . . . . 58
7.2.4 Kundendaten-Datenbank . . . . . . . . . . . . . . . . . . . . . . . 58
8 Glossar 60
9 Literatur 63
A Benutzerhandbuch 64
A.1 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A.2 Calculation-Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A.3 Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
A.4 Logout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
B Seminararbeiten 68
C Protokolle 152
iii
Abbildungsverzeichnis
2.1 Organigramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Kommunikations–Radar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Bezeichnung der eEPK-Symbole . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 eEPK Deckungsbeitragsrechnung . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 eEPK Gesamtkostenrechnung . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4 U¨bersicht u¨ber die Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1 U¨bersicht u¨ber das BICE System . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 Local Client Komponentendiagramm . . . . . . . . . . . . . . . . . . . . . 27
4.3 User- und Load Management und Balancing Komponentendiagramm . . . 29
4.4 Struktur der Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5 Data Retrieval, Accounting, Database System und ETL Komponenten-
diagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.6 MER-Diagramm Gesamtkosten . . . . . . . . . . . . . . . . . . . . . . . . 33
4.7 MER-Diagramm Deckungsbeitrag. . . . . . . . . . . . . . . . . . . . . . . 35
6.1 Graphik Performanztest . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.2 Graphik Referenzwerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
A.1 Login-Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A.2 Calculation-Seite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A.3 Customer-Dropdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
A.4 Customer Site Dropdown . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
A.5 Datepicker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
A.6 Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
A.7 Tabelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
A.8 Accounting-Seite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
iv
Tabellenverzeichnis
2.1 Rollenu¨bersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Auswertung Kommunikations–Radar . . . . . . . . . . . . . . . . . . . . . 8
3.1 Beschreibung Deckungsbeitragsrechnung . . . . . . . . . . . . . . . . . . . 13
3.2 Kurzbeschreibung aller Use Cases . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4 Funktionale Anforderungen (Fortsetzung) . . . . . . . . . . . . . . . . . . 19
3.5 Nichtfunktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 20
3.6 Nichtfunktionale Anforderungen (Fortsetzung) . . . . . . . . . . . . . . . 21
3.7 Musskriterien funktionale Anforderungen Musskriterien . . . . . . . . . . 22
3.8 Nichtfunktionale Anforderungen der Musskriterien . . . . . . . . . . . . . 23
3.9 Funktionale Anforderungen der Wunschkriterien . . . . . . . . . . . . . . 23
3.10 Nichtfunktionale Anforderungen der Wunschkriterien . . . . . . . . . . . . 24
4.1 Kennzahlensteckbrief Gesamtkosten . . . . . . . . . . . . . . . . . . . . . 32
4.2 Kennzahlensteckbrief Deckungsbeitrag . . . . . . . . . . . . . . . . . . . . 34
6.1 Ergebnisse eines Blackboxtests . . . . . . . . . . . . . . . . . . . . . . . . 47
6.2 Ergebnisse eines Blackboxtests . . . . . . . . . . . . . . . . . . . . . . . . 48
6.3 Empirischer Mittelwert und empirische Varianz . . . . . . . . . . . . . . . 49
6.4 Ergebnisse der Anpassungstest . . . . . . . . . . . . . . . . . . . . . . . . 50
v
1 Einleitung
ImKontextderGlobalisierungundderletztenFinanzkrisenzeichnetsichab,dassUnter-
nehmensichaneineWeltanpassenmu¨ssen,diesichrapidever¨andertundvonunsicheren
und unvollst¨andigen Informationen gepr¨agt ist, um weiter im Wettbewerb zu bestehen.
Sie mu¨ssen schnell auf Ver¨anderungen und Trends reagieren k¨onnen und dementspre-
chend agil und flexibel mu¨ssen auch die Entscheidungsprozesse gestaltet sein. Aus die-
semGrundsteigenauchdieAnforderungenandieverwendetenIT-Werkzeuge.Eswerden
proaktive und integrierte Systeme zur Entscheidungsunterstu¨tzung gebraucht, die hoch-
verfu¨gbar und erreichbar sind.[NS14]
Business Intelligence in the Cloud for Energy (BICE) soll eine Realisierung eines sol-
chen Systems werden, das einen konkreten Anwendungsfall aus der Energiewirtschaft
bedient. Dabei handelt es sich um die Deckungsbeitragsrechnung, die die Beschaffung,
Aggregation und Analyse relevanter Daten umfasst. Zu diesen Daten geh¨oren unter an-
derem Leistungs-, Arbeits- und Netznutzungskosten sowie einige Kundendaten. Mit den
aktuellen Mitteln dauert die Deckungsbeitragsrechnung jedoch zu lange, um die notwen-
dige Agilit¨at und Flexibilit¨at in der Entscheidungsfindung zu gew¨ahrleisten. Das System
BICE soll die Komplexit¨at der Deckungsbeitragsrechnung verringern. Derzeit sind fu¨r
die Deckungsbeitragsrechnung mehrere Prozesse notwendig und die Daten mu¨ssen aus
verschiedenen Quellen geladen werden. Die Deckungsbeitragsrechnung soll als ein Pro-
zess und als Service verfu¨gbar gemacht werden.
Dieses Dokument stellt die finale Projektdokumentation des BICE-Projekts dar. Da-
bei wird detailliert auf die allgemeine Projektorganisation, die Anforderungserhebung,
den konzeptionellen Entwurf, die technische Realisierung (Implementation), das Tes-
ting sowie die anschließende Evaluation des BICE-Systems eingegangen. Weiter enth¨alt
dieses Dokument im Anhang die Seminararbeiten der Projektgruppenmitglieder sowie
s¨amtliche verfasste Protokolle w¨ahrend der Projektphase.
1
2 Projektorganisation
In diesem Kapitel werden die Projektmanagement-Methoden sowie die sich daraus erge-
benden Rollen vorgestellt, die von den Mitgliedern der Projektgruppe umgesetzt, bzw.
bekleidet wurden. Daraus lassen sich Erkenntnisse schließen, wie ein solches Projekt in
der Wirtschaft umgesetzt werden k¨onnte.
2.1 Projektmanagement
Fu¨r die Umsetzung des Projektes wurde die Projektmanagement-Methode Scrum ver-
wendet. Scrum ist ein iteratives Projektmanagementverfahren, welches eine enge Bin-
dung zwischen dem Entwicklerteam und dem Kunden schaffen soll. Der iterative Cha-
rakter f¨ordert daru¨ber hinaus die Kommunikation innerhalb des Entwicklerteams sowie
die M¨oglichkeit, schnell auf auftretende Probleme zu reagieren. Eine detaillierte Be-
schreibung dieser Projektmanagementmethode kann in der Seminararbeit u¨ber Scrum
nachgelesen werden, die sich im Anhang des Projektdokuments befindet.
2.2 Rollen
Fu¨r die Bearbeitung des Projektes wurden einzelne Rollen identifiziert, die von den Teil-
nehmernderProjektgruppezurRealisierungdesProjekteseingenommenwurden.Scrum
siehtdieRollenKunde,EntwicklungsteamundScrumMastervor.DieRolledesKunden
u¨bernehmen im Fall des BICE-Projekts der Betreuer der Projektgruppe Oliver Norkus
und der Sparingspartner aus der Energiewirtschaft Marco Haas von Ceyoniq Consulting
GmbH. Die studentischen Mitglieder der Projektgruppe bilden das Entwicklungsteam.
Der Scrum Master stammt ebenfalls aus dem Entwicklungsteam.
Neben den Hauptrollen, welche durch Scrum vorgegeben werden, wurden daru¨ber hin-
aus einzelne Rollen innerhalb des Entwicklerteams identifiziert. Zu diesen Rollen z¨ahlen
der Projektleiter, der stellv. Projektleiter, der Architektur Manager, der Entwickler, der
Server Administrator, der Qualit¨atsmanager, der Homepage Beauftragte und der Doku-
mentenbeauftragte. Das zugeh¨orige Diagramm ist in der Abbildung 2.1 zu sehen. Die
Aufteilung der Rollen ist in Tabelle 2.1 zu sehen. Im Folgenden werden die einzelnen
Rollen kurz beschrieben.
Projektleiter u. Scrum Master: Die Rollen des Projektleiters und des Scrum Mas-
ters werden im Falle der Projektgruppe von einem einzelnen Studenten u¨bernommen,
da sowohl der Projektleiter, als auch der Scrum Master ¨ahnliche Aufgabengebiete verei-
nen. Dem Projektleiter obliegt die operative Planung und Steuerung des Projekts. Der
2
2 Projektorganisation
Projektleiter
stellv. Projektleiter
Architektur Manager Entwickler Server Administrator Qualitätsmanager Homepage Dokumenten-
Beauftragter beauftragter
Confluence
Beauftragter Sozialbeauftragter
Abbildung 2.1: Das Organigram zur Rollenverteilung in der Projektgruppe.
Person Rolle
Clark, Brian Entwickler
Friedrich Bj¨orn Entwickler, Homepage Beauftragter
Izadpanah, Babak Entwickler, Architektur Manager, Sozialbeauftragter
Merkel, Florian Entwickler, Server Administrator
Schweer, Ilias Entwickler, stellv. Projektleiter, Qualit¨atsmanager
Zimak, Alexander Entwickler, Projektleiter, Confluence Beauftragter
Tabelle 2.1: U¨bersicht u¨ber die Teammitglieder und denen von ihnen u¨bernommenen
Rollen
Scrum Master ist fu¨r den reibungslosen Ablauf des Scrum verantwortlich. Er soll sich,
wie der Projektleiter auch, um pers¨onliche Konflikte im Team, die Zusammenarbeit und
dieKommunikationzwischendenTeammitgliedernku¨mmern.Außerdemisterauch,wie
der Projektleiter, fu¨r Projektorganisation zust¨andig. Im Normalfall hat der Projektleiter
weiterreichende Befugnisse als der Scrum Master. Er ist dem Team gegenu¨ber weisungs-
befugt und ist verantwortlich fu¨r die Ressourcenplanung. Der Scrum Master ist nicht
weisungsbefugt und die Ressourcenplanung wird vom Team selbst durchgefu¨hrt.
stellv. Projektleiter: Der stellv. Projektleiter u¨bernimmt die Aufgaben, des Projekt-
leiters, falls dieser verhindert ist. Sollte dies der Fall sein, hat der stellv. Projektleiter
dieselben Befugnisse und Entscheidungsspielr¨aume, wie der Projektleiter.
Entwickler: Jedes Teammitglied hat die Rolle des Entwicklers inne. Der Entwickler ar-
beitet an der Erstellung der Bestandteile zur Realisierung des Produkts. Dies umfasst
alle zugeh¨origen Aufgaben wie Dokumentation, Programmierung, Wartung, Adminis-
tration ect. Hinzu kommen die Aufgaben, die das Team im Scrum Prozess u¨bernehmen
soll. Dazu z¨ahlen Aufwandsabsch¨atzungen, Product Backlog Refinement und die Sprint
3
2 Projektorganisation
Planung.
Dokumentenbeauftragter: Damit die Dokumente eine einheitliche Form haben, er-
stellt der Dokumentenbeauftragte Vorlagen. Insbesondere bei h¨aufig wiederkehrenden
Dokumenten, wie bspw. Protokolle, ist eine einheitliche Form wichtig. Die umfassende-
ren Dokumente, wie das Anforderungsdokument, das Pflichtenheft und der Abschluss-
bericht mu¨ssen strukturiert werden. Die Anfertigung des Grundgeru¨sts u¨bernimmt der
Dokumentenbeauftragte.
Architektur Manager: Der Architektur Manager hat eine administrative Aufgabe. Die
Entwicklung und Dokumentation der Architektur wird vom gesamten Team gemeinsam
u¨bernommen. Der Architektur Manager sorgt fu¨r den strukturierten Aufbau der Archi-
tektur und ist erster Ansprechpartner bei Fragen bezu¨glich der Architektur. Daru¨ber
hinaus ist er hauptverantwortlich fu¨r alle konzeptionellen und praktischen Arbeiten an
der Architektur.
Confluence Beauftragter: Fu¨r die Kollaboration haben wird w¨ahrend des Projektes
Confluence eingesetzt. Damit die gemeinschaftlich gesammelten Erfahrungen und das
gemeinschaftlich gesammelte Wissen abgerufen werden k¨onnen, muss es strukturiert do-
kumentiert werden. Der Confluence Beauftrage sorgt dafu¨r, dass alle Dokumente katalo-
gisiert werden und im Confluence zum Abruf bereitstehen. Weiterhin organisiert er die
Struktur im Confluence und sorgt dafu¨r, dass sie eingehalten wird.
Homepage Beauftragter: Der Homepage Beauftragte ku¨mmert sich um die Homepa-
ge der Projektgruppe (www.cloud-bi.informatik.uni-oldenburg.de). Seine Aufgabe
ist es, die Homepage zu erstellen, zu hosten und zu pflegen. Außerdem obliegt ihm die
AufgabesichumalleanfallendenadministrativenAufgabenbzgl.derHomepagezuku¨m-
mern.
Qualit¨atsmanager: Fu¨r alle Dokumente wurde eine Stufe fu¨r die Qualit¨atssicherung
eingebaut. Der Qualit¨atsmanager soll fu¨r einen Standard bei den Dokumenten sorgen.
Die Stufe der Qualit¨atssicherung wird in allen Prozessen, die Dokumente beinhalten,
beru¨cksichtigt.
Server Administrator: Fu¨r die Kollaboration werden verschiedene Tools (JIRA, Con-
fluence, SVN) eingesetzt. Diese mu¨ssen auf Servern installiert und administriert werden.
Diese Aufgabe u¨bernimmt der Server Administrator. Weiterhin pflegt er die Systeme
und steht den Mitgliedern des Teams bei Fragen und Problemen bzgl. der Systeme zur
Seite.
Sozialbeauftragter: NebenderfachlichenKompetenzimTeamistdieZusammenarbeit
und die Stimmung von essentieller Bedeutung. Der Sozialbeauftragte organisiert Team-
Events, um die Kommunikation im Team zu f¨ordern und den Zusammenhalt zu st¨arken.
4
2 Projektorganisation
2.3 Vorgehensweise
Es wurde beschlossen, dass w¨ahrend der Bearbeitung des Projektes eine bestimmte Ab-
folge von Arbeitsschritten einzuhalten ist. Da Scrum als Projektmanagement- bzw. Soft-
wareentwicklungsmethode verwendet wird, wurden die einzelnen Prozesse und Phasen
fu¨r die Bedu¨rfnisse der Projektgruppe angepasst. Dabei wurden die Rollen nicht in dem
Ausmaß verfolgt, wie es Scrum eigentlich vorsieht. So war der Produkt Owner zum Teil
stark in die Entwicklung des Systems involviert, gleiches gilt fu¨r den Scrum Master. Fu¨r
ein genaues Verst¨andnis der Scrum Methodik steht die Seminararbeit u¨ber Scrum zur
Verfu¨gung, welche im Anhang zu finden ist.
ProductBacklog:WurdevonderProjektgruppe,inTeamarbeit,regelm¨aßigaktua-
•
lisiert und erweitert.
Sprint Planning: Wurde jede Woche von der Projektgruppe durchgefu¨hrt.
•
Sprint Backlog: Wurde w¨ahrend des Sprint Planning erstellt.
•
Daily Scrum: Aufgrund des Arbeitsumfeldes einer studentischen Projektgruppe
•
wurde auf das Daily Scrum verzichtet. Der Scrum Master konnte bei Konflikten
jedoch jeder Zeit kontaktiert werden.
Sprint Execution: Die Dauer eines Sprints wurde auf eine Woche festgelegt.
•
Sprint Review: Der Sprint Review wurde einmal w¨ochentlich, parallel mit dem
•
Sprint Planning und der Sprint Retrospective, im Beisein des Product Owners
durchgefu¨hrt.
Sprint Retrospective: Die Retrospective wurde einmal w¨ochentlich durchgefu¨hrt.
•
NebendemVorgehenbezu¨glichderScrumMethodikhatsichdieProjektgruppeauchbe-
zu¨glich der Anforderungserhebung mittels Interviews auf ein Vorgehensmodell geeinigt.
Das Vorgehen wird in den folgenden Schritten iterativ durchgefu¨hrt.
1. Fragenkatalog fu¨r das Interview erstellen.
2. Interview mit dem Kunden aus der Energiewirtschaft fu¨hren, aufzeichnen und ein
Protokoll anfertigen.
3. Erkenntnisse aus dem Interview auswerten und Ermitteln von Anforderungen aus
diesen.
4. Pr¨asentation der Ergebnisse.
5