Lightweight DWH Interface
Werbung
Pflichtenheft Master Thesis Lightweight DWH Interface in der Firma Emmi Schweiz AG Abstract Diese Arbeit beinhaltet das Entwickeln einer Schnittstellentechnik, welche die Daten von einem Quellsystem in ein Datawarehouse überträgt. Hauptziel ist, die heutige Belastung der Quellsysteme um mindestens 70% zu verringern. Auch soll der Konfigurationsaufwand neuer Schnittstellen minimiert werden. Klasse.Nr / Datum: MAS-07-01.21 / 20. März 2009 Experte: Thomas Glauser, Lährenbühlstrasse 14b , 8112 Otelfingen Tel. P: +41 79 217 66 82 Tel. G: +41 52 261 57 58 E-Mail: [email protected] Betreuer: Urs Müller, Forelstrasse 1, 3072 Ostermundigen Tel. G: +41 31 930 24 84 E-Mail: [email protected] Student: Stefan Lüthi, Allmendingenstrasse 16, 3608 Thun Tel. P: +41 79 458 46 84 Tel. G: +41 31 930 24 88 E-Mail: [email protected] Keywords: Datenbank, Datawarehouse, Oracle, ETL, Schnittstelle Pflichtenheft Master Thesis MAS-07-01.21 Änderungskontrolle Version Datum Autor Bemerkungen 0.1 0.2 0.3 0.4 0.5 0.6 1.0 20.03.2009 29.03.2009 01.04.2009 08.04.2009 09.04.2009 22.04.2009 23.04.2009 Stefan Lüthi Stefan Lüthi Stefan Lüthi Stefan Lüthi Stefan Lüthi Stefan Lüthi Stefan Lüthi Erstellung Projektmanagement hinzugefügt Projektplan, Projektübersicht hinzugefügt Mögliche Lösungen und Entscheid Anforderungen definieren Testing & Funktionale Anforderungen Fertigstellung und Abgabe Review / Prüfung Version Prüfdatum Prüfende Stelle Bemerkungen 0.5 20.04.2009 Th. Glauser Ganzes Dokument ohne Kapitel 3 Referenzierte Dokumente Version 10.09.2009 Datum Seite 2 von 35 Pflichtenheft Master Thesis MAS-07-01.21 Inhaltsverzeichnis 1 Allgemeines ......................................................................................................... 5 1.1 Dokument ........................................................................................................... 5 1.1.1 Zweck.......................................................................................................... 5 1.1.2 Umfang........................................................................................................ 5 1.1.3 Leserkreis.................................................................................................... 5 1.1.4 Übersicht ..................................................................................................... 5 1.1.5 Begriffe und Definitionen ............................................................................. 5 1.1.6 Nomenklatur................................................................................................ 5 1.2 Umfeld ................................................................................................................ 6 1.2.1 Die Emmi Schweiz AG ................................................................................ 6 1.2.2 Das Datawarehouse .................................................................................... 6 1.2.3 Die Quellsysteme ........................................................................................ 6 2 Projektübersicht.................................................................................................. 7 2.1 2.2 2.3 2.4 2.5 3 Allgemeine Beschreibung.................................................................................... 7 2.1.1 ETL Prozess................................................................................................ 7 2.1.2 Ladeprozess kleine Tabellen ....................................................................... 8 2.1.3 Ladeprozess grosser Tabellen ................................................................... 8 Problemstellung .................................................................................................. 9 Projektziele ......................................................................................................... 9 Mögliche Lösungen ........................................................................................... 10 2.4.1 LogMiner (erste Vision) ............................................................................. 10 2.4.2 Timestamp / Change Key Column ............................................................. 11 2.4.3 Tabel differencing...................................................................................... 11 2.4.4 Oracle Change Data Capture .................................................................... 12 Entscheid .......................................................................................................... 13 2.5.1 Erklärung zur Bewertung ........................................................................... 13 Anforderungen .................................................................................................. 15 3.1 3.2 Namenskonvention der Anforderungen ............................................................. 15 Funktionale Anforderungen ............................................................................... 15 3.2.1 Übersicht Use Cases................................................................................. 15 3.2.2 Use Case Diagramm LDI........................................................................... 16 3.2.3 Aktoren...................................................................................................... 17 3.2.4 Use Cases................................................................................................. 17 3.2.5 Grafisches User Interface (GUI) ................................................................ 24 3.3 Nicht funktionale Anforderungen ....................................................................... 25 3.3.1 Anforderungskatalog ................................................................................. 25 3.4 Rahmenbedingungen........................................................................................ 26 3.4.1 Testsystem / Entwicklungsumgebung........................................................ 26 3.5 Abgrenzung....................................................................................................... 26 4 Testen ................................................................................................................ 27 4.1 4.2 5 Systemtests ...................................................................................................... 27 Usability Test .................................................................................................... 27 Planung.............................................................................................................. 28 5.1 5.2 10.09.2009 Vorgehensmodell .............................................................................................. 28 Aufwandschätzung............................................................................................ 29 Seite 3 von 35 Pflichtenheft Master Thesis MAS-07-01.21 5.3 5.4 5.5 5.6 Projektplan / Zeitplan und Meilensteine............................................................. 30 Termine............................................................................................................. 31 Projektmanagement .......................................................................................... 31 Meetings / Reviews /Statusmeldungen.............................................................. 31 5.6.1 Meetings.................................................................................................... 31 5.7 Reviews ............................................................................................................ 31 5.7.1 Statusmeldungen ...................................................................................... 31 6 Kosten................................................................................................................ 32 6.1 6.2 6.3 7 Interner personeller Aufwand (Kosten) .............................................................. 32 Externe Kosten ................................................................................................. 32 Kosten gesamt .................................................................................................. 32 Anhang............................................................................................................... 33 7.1 7.2 7.3 7.4 10.09.2009 Glossar ............................................................................................................. 33 Referenzen ....................................................................................................... 34 Tabellenverzeichnis .......................................................................................... 35 Abbildungsverzeichnis ...................................................................................... 35 Seite 4 von 35 Pflichtenheft Master Thesis MAS-07-01.21 1 Allgemeines 1.1 Dokument 1.1.1 Zweck Das Dokument beschreibt das Pflichtenheft der Master Thesis MAS-07-01.21 „Lightweight DWH Interface“. Alle funktionalen und nichtfunktionalen Anforderungen, sowie deren Abgrenzungen sind im vorliegenden Dokument enthalten. Es gibt auch Aufschluss über die gesamte Planung des Projekts. 1.1.2 Umfang Diese Arbeit wird in der Form einer Master Thesis vollzogen. Sie bildet einen Teil der Ausbildung zum Master of Advanced Studies in Information Technology (MAS-IT). Der gesamte Arbeitsaufwand beträgt 360 Stunden (12 ECTS-Punkte) und dauert ein Semester. 1.1.3 Leserkreis Dieses Dokument richtet sich in erster Linie an den Experten, den Betreuer und an den Autor dieser Arbeit. 1.1.4 Übersicht Dieses Dokument ist wie folgt aufgebaut: Kapitel 1 Kapitel 2 Kapitel 3 Kapitel 4 Kapitel 5 Kapitel 6 Kapitel 7 Vermittelt einen Überblick über das Dokument. Gibt einen Überblick über das Projekt, die Vision und die Ziele. Spezifiziert die funktionalen Anforderungen und nicht funktionalen Anforderungen. Beschreibt das Testing Beschreibt die gesamte Planung der Arbeit. Zeigt die Kosten auf. Enthält das Glossar, die Referenzen und die verschiedenen Verzeichnisse 1.1.5 Begriffe und Definitionen Die in diesem Dokument verwendeten Begriffe und Definitionen sind im Glossar beschrieben. 1.1.6 Nomenklatur Das Dokument ist in Deutsch gehalten. Dort wo es jedoch sinnvoll erscheint, werden die englischen Originalbegriffe verwendet. Zu Gunsten einer besseren Lesbarkeit wird für sämtliche Bezeichnungen nur die männliche Form verwendet. 10.09.2009 Seite 5 von 35 Pflichtenheft Master Thesis MAS-07-01.21 1.2 Umfeld 1.2.1 Die Emmi Schweiz AG Die Firma Emmi ist der grösste Schweizer Milchverarbeiter und eine der innovativsten Premium-Molkereien in Europa. In der Schweiz fokussiert sich Emmi auf die Entwicklung, Produktion und Vermarktung eines Vollsortiments an Molkerei- und Frischprodukten sowie auf die Herstellung, die Reifung und den Handel hauptsächlich von Schweizer Käse. Im Ausland konzentriert sich Emmi mit Markenkonzepten und Spezialitäten auf Märkte in Europa und Nordamerika. Bei den Frischprodukten stehen Lifestyle-, Convenience- und Gesundheitsprodukte im Vordergrund. Beim Käse positioniert sich Emmi als das weltweit führende Unternehmen für Schweizer Käse. Die Kunden von Emmi sind hauptsächlich der Detailhandel, der Bereich Food Service und die Lebensmittelindustrie. Im Jahr 2007 hat Emmi einen Nettoumsatz von CHF 2.5 Mrd. erzielt und beschäftigte Ende 2007 in der Schweiz und im Ausland 3'350 Mitarbeitende (auf Vollzeitbasis). 1.2.2 Das Datawarehouse Das Datawarehouse wurde im Jahre 2006 erstellt und der erste Bereich (Sales) wurde aus dem ERP System in das DWH übernommen. Seither kamen auch die Finanzdaten und acht weitere kleine Bereiche hinzu. Die Datenmenge beläuft sich auch ca. 800MB. Auf die Architektur des DWH wird im Kapitel 2 genauer eingegangen. 1.2.3 Die Quellsysteme Die Hauptquelle des DWH stellt sicher das ERP dar. Daneben wurden auch noch die zentrale Stammdatenverwaltung und die Budgetdaten übernommen. 10.09.2009 Seite 6 von 35 Pflichtenheft Master Thesis MAS-07-01.21 2 Projektübersicht 2.1 Allgemeine Beschreibung Das Projekt befasst sich mit der Problematik der Übernahme von operativen Daten in den Staging Bereich eines Datawarehouse. Die Kapitel 2.1.1 und 2.1.2 zeigen die Ist - Situation dieser Schnittstellen im analysierten System auf. Das Kapitel 2.1.3 beschreibt die Probleme, welche sich in diesem Bereich stellen und auch den Anstoss für dieses Projekt gegeben haben. 2.1.1 ETL Prozess Die Abbildung 1 zeigt den ETL - Prozess in der Emmi Schweiz AG. Dieser folgt immer dem gleichen Ablauf. Zuerst werden alle benötigten Daten von den Quellsystemen in den Stagingbereich des DWH übernommen (Punkt 1). Ab dort werden die Daten transformiert und konvertiert und werden in die verschiedenen Data - Marts geladen (Punkt 2). Die rot gestreifte Linie markiert den Bereich, in welchem sich dieses Projekt bewegt. Bereiche ausserhalb der Markierung sind von der geplanten Arbeit nicht betroffen. relational Quellsysteme transformation / converting ERP DB (OLTP) evaluations Standard Reports (Microstrategy) Datawarehouse MIS DB Oracle 11g R1 landing-zone E1 Master dimensional Sales Line ERP DB (OLTP) DWH Bus EFM 2 1 Staging Query Service Ad hoc Zugriff (SQL) Financial Stammdaten DB (OLTP) DWH Bus ESDS Procurement Feedback operationelle Systeme (PROCOS) Budget DB PROCOS Metadaten Abbildung 2-1: ETL Prozess Schema 10.09.2009 Seite 7 von 35 Pflichtenheft Master Thesis MAS-07-01.21 2.1.2 Ladeprozess kleine Tabellen Bei der Übernahme von Tabellen mit Records < 30'000'000 in den Stagingbereich, werden die kompletten Daten bei jeder Übertragung gelöscht und wieder geladen. Die Löschung erfolgt mit dem Befehl Truncate und ist dadurch sehr schlank gehalten. Der Ladevorgang ist bei einer grossen Anzahl Records aufwendig. 2.1.3 Ladeprozess grosser Tabellen Bei der Übernahme von Tabellen mit Records > 30'000'000 in den Stagingbereich, werden nur Änderungen seit der letzten Übernahme verarbeitet. Abbildung 2 zeigt den Standardvorgang einer solchen Übernahme. 1. Als erstes wird eine Hilfstabelle gelesen, welche die Primary Keys der gelöschten Records von der Haupttabelle enthält. Anhand dieses Keys werden auch auf der Zieltabelle diese Records gelöscht. 2. Anhand einer Spalte, welche das Änderungsdatum enthält, werden die zusätzlichen oder geänderten Records seit der letzten Übernahme identifiziert. Da diese Spalte nicht indexiert ist, löst dies jede Nacht einen Full Table Scan aus. 3. Um zu prüfen, ob auch wirklich die Daten auf der Quell- wie auch auf der Zieldatenbank gleich sind, wird nach jeder Übernahme einen Abgleich gemacht. Dies wird gemacht, indem man auf einer definierten Spalte eine Summe bildet und diese beiden Summen vergleicht. Die Vergangenheit hat gezeigt, dass dieser Abgleich notwendig ist, da schon einige Fehler gefunden wurden. 4. Dies ist ein Trigger, welcher auf der Quelltabelle programmiert werden muss. Dieser stellt sicher, dass alle Änderungen mit einem korrekten Änderungsdatum versehen werden. Auch kann durch den Trigger gewährleistet werden, dass gelöschte Records zu einem späteren Zeitpunkt auf der Zieltabelle via Primary Key auch gelöscht werden können. ERP DB 4 Datawarehouse MIS DB Oracle 11g R1 Full T able S can - s Ro w lös ch te ge PK Full T Quelltabelle Ände ru able S can Summ e 3 ausre chnen ngen se lektie ren Summ e Gelöschte Records auch in DWH löschen Delete Tabelle Stagingbereich DWH 2 - vergle ichen Änder ungen üb Summ e erneh men ausre chnen - Full Table Scan 1 Zieltabelle Trigger Abbildung 2-2: Ladeprozess grösserer Tabellen 10.09.2009 Seite 8 von 35 Pflichtenheft Master Thesis MAS-07-01.21 2.2 Problemstellung Durch die aufwendige Übernahme der grossen Tabellen, werden die Quellsysteme derart belastet, dass der produktive Betrieb während den Übernahmen beeinträchtigt wird. Abbildung 3 zeigt die Kurve der CPU auf dem Quellsystem während einer Übernahme an einem Wochenende. Es ist deutlich zu sehen, dass ab ca. 17:00 bis ca. 07:00 die Last ansteigt. Genau in dieser Zeit wurden die Daten, welche nur wöchentlich übernommen werden können, übertragen und abgeglichen. Abbildung 2-3: CPU Kurve Quellsystem Des Weiteren besteht der Wunsch die Daten mindestens vom Vortag im Datawarehouse auswerten zu können. Bei dieser Übertragungstechnik ist dies aber nicht möglich, da die Laufzeit der Schnittstellen bis um ca. 12:00 Mittags dauern würde. Auch darf eine solche Belastung der Quellsysteme nicht während des Tagesgeschäfts der Emmi AG auftreten, da dies den Lieferprozess der Firma beeinträchtigt würde. 2.3 Projektziele Das Ziel dieses Projekts ist eine Schnittstellentechnik zu beschreiben und zu realisieren: • Welche die Daten im gewünschten Zeitrahmen (max. 2 Stunden für die grössten Tabellen) in den Staging - Bereich des DWH bringt. • Welche die Belastung des Quellsystems um mindestens 70% verringert. • Welche es erlaubt die zukünftigen Schnittstellen mit 50% Aufwand zu realisieren. • Welche der Stabilität zur jetzigen Technik ebenwürdig ist. • Welche das weglassen der Trigger auf den Quellsystemen erlaubt. Um diese Ziele zu erreichen, werden in den folgenden Kapiteln die Lösungsansätze analysiert und die Anforderungen sowie die Ziele genauer beschrieben. 10.09.2009 Seite 9 von 35 Pflichtenheft Master Thesis MAS-07-01.21 2.4 Mögliche Lösungen In diesem Kapitel werden die möglichen Lösungen für das erreichen der Projektziele kurz beschrieben und verglichen. Danach wird entschieden, welche Technik für das Projekt geeignet ist. Dieser Entscheid wird die technische Umsetzung des Projekts massiv beeinflussen. Daher wird diesem Teil genügend Zeit beigemessen. Jede Lösung wird auch praktisch analysiert und ein schlanker „Proof of Concept“ wird durchgeführt. 2.4.1 LogMiner (erste Vision) Die erste Idee, wie man die im Kapitel 2.1.3 beschriebenen Probleme lösen könnte, sah wie folgt aus: Staging Table Change Table Abbildung 2-4: Prozessablauf Vision Die archivierten Redo Logs der Quelldatenbank, werden auf den Rechner der Zieldatenbank kopiert. Dort werden mit der bestehenden Oracle Technologie LogMiner alle Änderungen in eine Zwischentabelle geschrieben. Diese Änderungen werden mittels einer neu programmierten Applikation gefiltert und aufbereitet. Danach werden die aufbereiteten Records in die entsprechende Stagingtabelle geschrieben. Jeder Record enthält zusätzliche wichtige Merkmale wie: • • • Änderungsart (Insert, Update, Delete) SCN damit die Reihenfolge bestimmt werden kann Ein Flag Verarbeitet Ja/Nein 10.09.2009 Seite 10 von 35 Pflichtenheft Master Thesis MAS-07-01.21 2.4.2 Timestamp / Change Key Column Diese Methode ist bereits bei den grössten Tabellen umgesetzt und im Kapitel 2.1.3 beschrieben. Sie belastet die Systeme stark und bedeutet einen grossen Aufwand bei der Programmierung neuer Schnittstellen. Mit dieser Technik können die Projektziele nicht erreicht werden. 2.4.3 Tabel differencing Bei dieser Methode, werden die gesamten Daten von der Quelldatenbank zur Zieldatenbank transportiert. Danach werden sie mittels speziellen SQL’s verglichen (minus). Auch diese Technik ist sehr belastend für die Systeme. Mittels Datenbanklink kann eine Verbesserung erzielt werden. Mit dieser Technik können die Projektziele nicht erreicht werden. 10.09.2009 Seite 11 von 35 Pflichtenheft Master Thesis MAS-07-01.21 2.4.4 Oracle Change Data Capture Oracle bietet das Feature „Change Data Capture“ an. Diese Technologie kann in verschiedenen Modi betrieben werden: • • • • • Synchronus Asynchronus HotLog Asynchron Distributed HotLog Asynchronus HotLog online Asynchronus Autolog archive Für das anstehende Projekt bietet sich „Asynchronus Autolog Archive“ am besten an, da die Anforderungen ziemlich genau auf die bestehende Umgebung in der Emmi Schweiz AG passen. Auch ist eine möglichst zeitnahe Übertragung nicht nötig. Des Weiteren belastet dieser Modus die Systeme am wenigsten. In diesem Kapitel wird also nur auf den „Asynchronus Autolog Archive“ Modus eingegangen. Um die Funktionsweise der anderen Modi zu erfahren wird auf das Kapitel 16 im Dokument Oracle Data Warehousing Guide 11g Release 1 (B28313-02) verwiesen. Asynchronus Autolog Archive Dieser Modus beinhaltet einen ziemlich ähnlichen Vorgang wie im Kapitel 2.4.1 beschrieben. Die Daten werden auch aus den Archivierten Redo Logs gewonnen. Anstelle des LogMiners steht das Feature Change Data Capture, welches auch die Funktion des Aufbereitens der Daten beinhaltet. In der Abbildung 5 sieht man ein Übersichtsschema, wie dieser Modus funktioniert. Eine genaue Beschreibung kann aus dem Dokument Oracle Data Warehousing Guide 11g Release 1 (B28313-02) entnommen werden. Abbildung 2-5: Prozessablauf Change Data Capture 10.09.2009 Seite 12 von 35 Pflichtenheft Master Thesis MAS-07-01.21 2.5 Entscheid Bei den verschiedenen Lösungsansätzen im Kapitel 2.4 kommen nur die Logminer - Lösung und das Change Data Capture in Frage. Bei allen Anderen können die gesteckten Ziele nicht erreicht werden. 1 2 3 4 5 6 7 8 Kriterien Gewicht LogMiner Belastung Quellsystem 9 5 Belastung Zielsystem 3 3 Implementationsaufwand / Tabelle 5 2 Stabilität 7 3 Supportbarkeit 6 2 Releasefähigkeit 7 1 Aufwand 5 2 Kosten 2 5 Resultat 124 Change Data Capture 5 4 4 5 4 4 4 5 194 Tabelle 2-1: Entscheidungstabelle Aufgrund des Resultats der Entscheidungstabelle wird sich für „Change Data Capture“ entschieden. 2.5.1 Erklärung zur Bewertung Belastung Quellsystem Aufgrund der sehr ähnlichen Technologie werden bei beiden Varianten die Quellsysteme kaum belasten. Belastung Zielsystem Da bei der LogMiner Lösung das aufbereiten der Daten programmiert werden muss, gehe ich nicht davon aus, dass ich dies gleich effizient gestalten könnte wir die Firma Oracle. Implementationsaufwand / Tabelle „Change Data Capture“ stellt einige der gewünschten Funktionen zur Verfügung. Somit kann die zur Verfügung stehende Zeit auch in die Entwicklung eines GUI investiert werden. Somit sollte auch das Ziel der einfachen Weiterentwicklung erreicht werden. Stabilität Da „Change Data Capture“ ein Standard Feature von Oracle ist und dieses weltweit in Firmen eingesetzt wird, kann von einer guten Stabilität ausgegangen werden. Bei der selber entwickelten Variante, wäre das „handeln“ jeglicher Spezialsituationen sicher schwierig gewesen. 10.09.2009 Seite 13 von 35 Pflichtenheft Master Thesis MAS-07-01.21 Supportbarkeit Bei der LogMiner Variante ist es schwierig über Jahre das Know-How aufrechtzuerhalten. Da „Change Data Capture“ ein Standard Feature ist, kann man sich auch bei der Firma Oracle Unterstützung besorgen. Releasefähigkeit Das „Change Data Capture“ Feature wird bei Oracle mit den DB Relases gleichzeitig ausgeliefert, da es ein Bestandteil der ganzen Software ist. Die eigene Lösung müsste bei jedem Upgrade der Umgebung neu erweitert und getestet werden. Aufwand Beim Aufwand kann gesagt werden, dass eine eigene Entwicklung den Rahmen der Diplomarbeit gesprengt hätte. Beim „Change Data Capture“ kann die vorgesehene Zeit voraussichtlich eingehalten werden. Kosten Das sowohl LogMiner wie auch „Change Data Capture“ keine Option ist, welche separat Lizenziert werden muss, dürften sich die Kosten im gleichen Rahmen bewegen. 10.09.2009 Seite 14 von 35 Pflichtenheft Master Thesis MAS-07-01.21 3 Anforderungen Ziel ist es, eine Schnittstellentechnik zu implementieren, welche die Daten eines Quellsystems möglichst schlank in den Stagingbereich des DWH bringt. Das Quellsystem soll durch diese Schnittstelle kaum belastet werden. Als Technologie wird Change Data Capture von Oracle eingesetzt. Da die Konfiguration sehr aufwendig ist, soll ein Konfigurationstool entwickelt werden, welches den ETL Programmierer eine einfaches Konfigurieren ermöglicht. In diesem Kapitel sind die funktionalen und nichtfunktionalen Anforderungen aufgeführt. Des Weiteren werden die Rahmenbedingungen und Abgrenzungen dieser Arbeit festgelegt. 3.1 Namenskonvention der Anforderungen Name FA.XX FA.XX.XXX NFA.XX NFA.XX.XXX M K Beschreibung Gruppe funktionaler Anforderungen Funktionale Anforderung Gruppe nichtfunktionaler Anforderungen Nichtfunktionale Anforderung Muss Anforderung Kann Anforderung Tabelle 3-1: Namenskonvention der Anforderungen 3.2 Funktionale Anforderungen 3.2.1 Übersicht Use Cases ID FA.01 FA.01.010 FA.01.020 FA.02 FA.02.010 FA.02.020 FA.03 FA.03.010 FA.03.020 FA.04 FA.04.010 FA.04.011 FA.04.012 FA.04.020 FA.05 FA.05.010 FA.05.020 Beschreibung Verbindungsaufbau zu Datenbank Login DB - Verbindung konfigurieren Destinationsystem Destinationsystem konfigurieren Destinationsystem löschen Schnittstellengruppe Schnittstellengruppe konfigurieren Schnittstellengruppe löschen Schnittstelle Schnittstelle konfigurieren Sourcetabelle konfigurieren Destinationtabelle konfigurieren Schnittstelle löschen Sourcesystem Sourcesystem konfigurieren Sourcesystem löschen M K X X X X X X X X X X X X Tabelle 3-2: Übersicht Use Cases 10.09.2009 Seite 15 von 35 Pflichtenheft Master Thesis MAS-07-01.21 3.2.2 Use Case Diagramm LDI Dieses Diagramm vermittelt einen groben Überblick über das geplante Konfigurationstool und über die Systemgrenzen. Dieses wird in der Detailspezifikation in einer zweiten Iteration verfeinert und genauer spezifiziert. Auf die Reihenfolge wie die Cases verwendet werden, wurde keine Rücksicht genommen. Use Case Diagramm: LDI <<extend>> Login FA.01.010 DB - Verbindung konfigurieren FA.01.020 Destinationsystem konfigurieren FA.02.010 Destinationsystem löschen FA.02.020 Schnittstellegruppe Konfigurieren FA.03.010 DWH System Schnittstellegruppe löschen FA.03.020 Schnittstelle löschen FA.04.020 <<include>> Schnittstelle konfigurieren FA.04.010 ETL - Programmierer Sourcetabelle konfigurieren FA.04.011 <<include>> Destinationtabelle konfigurieren FA.04.012 Sourcesystem konfigurieren FA.05.010 Sourcesystem löschen FA.05.020 Source System Abbildung 3-1: Use Case Diagramm LDI 10.09.2009 Seite 16 von 35 Pflichtenheft Master Thesis MAS-07-01.21 3.2.3 Aktoren Es werden alle Aktoren kurz beschrieben. Name ETL - Programmierer Source System Destination System Beschreibung Dies ist der Hauptbenutzer dieser Software. Er definiert die ETL Schnittstellen für das DWH. Das Sourcesystem ist die Datenbank, welche die Quelldaten für die Schnittstelle enthält. Das Zielsystem ist der Stagingbereich des DWH. Dies auch in der Form einer Oracle Datenbank. Tabelle 3-3: Aktoren 3.2.4 Use Cases Jeder Use Case des LDI Tools wird nach gleichem Template spezifiziert. Die Angaben dienen zum allgemeinen Verständnis. Die genaue Spezifikation wird in der Entwurfsphase gemacht und in der Detailspezifikation dokumentiert. FA.01.010 Login Stefan Lüthi Geändert durch: 22.04.2009 Änderungsdatum: ETL - Programmierer Um eine Verbindung vom Tool in die Datenbank herzustellen, muss der Benutzer sich anmelden. Vorbedingung - Das Tool muss aufgestartet sein - Der Aktor muss auf der Datenbank ein gültiges Benutzerprofil haben - Datenbankverbindung muss konfiguriert sein Normaler Ablauf: 1. Aktor klickt auf Menupunkt Login 2. Aktor gibt die gültigen Benutzerangaben an 3. Aktor bestätigt die Benutzerangaben Alternativer Ablauf: - Aktor bricht das Login ab Nachbedingung: - DB Verbindung mit Tool ist hergestellt Includes: Gebrauchshäufigkeit: Einmal nach Toolstart Anmerkungen und Als Berechtigungssystem wird die Benutzerverwaltung des Problem: Datenbanksystems genutzt. Somit ist der ganze Berechtigungsprozess gleich wie dieser der normalen DB Benutzer. Dieser Prozess ist in der Emmi Schweiz AG bereits dokumentiert und umgesetzt. Tabelle 3-4: UC Login FA.01.010 Use Case ID: Use Case Name: Ersteller: Erstellungsdatum: Aktor: Beschreibung: 10.09.2009 Seite 17 von 35 Pflichtenheft Master Thesis MAS-07-01.21 Use Case ID: Use Case Name: Ersteller: Erstellungsdatum: Aktor: Beschreibung: FA.01.020 DB - Verbindung konfigurieren Stefan Lüthi Geändert durch: 22.04.2009 Änderungsdatum: ETL - Programmierer Die Verbindung des Tools zu der Datenbank kann konfiguriert werden Vorbedingung - Das Tool muss aufgestartet sein - Der Aktor muss auf der Datenbank berechtigt sein - Datenbank muss auf dem Client konfiguriert sein (tnsnames.ora) Normaler Ablauf: 1. Aktor klickt auf Menupunkt Eigenschaften 2. Aktor klickt in Register DB - Verbindung 3. Aktor wählt die Datenbank aus einer Liste aus (tnsnames.ora) 4. Aktor speichert Angaben 5. Aktor schliesst das Fenster Eigenschaften Alternativer Ablauf: - Aktor bricht die Konfiguration ab Nachbedingung: - DB Verbindung ist für diesen Client abgespeichert Includes: Gebrauchshäufigkeit: Nur einmal vor der ersten Verwendung auf einem Client Anmerkungen und Es gibt nur eine Verbindung für das Tool. Diese wird voraussichtlich in Problem: einem .ini File abgelegt. Tabelle 3-5: UC DB Verbindung konfigurieren FA.01.020 Use Case ID: Use Case Name: Ersteller: Erstellungsdatum: Aktor: Beschreibung: FA.02.010 Destinationsystem konfigurieren Stefan Lüthi Geändert durch: 22.04.2009 Änderungsdatum: ETL - Programmierer Im Tool können ein oder mehrere Destinationen konfiguriert werden Vorbedingung - Das Tool muss aufgestartet sein - DB - Verbindung muss konfiguriert sein - Destination DB muss vorbereitet sein (User, Tablespace, Parameter, etc.) 1. Aktor klickt mit RMT in Navigationspanel und auf Menupunkt Destinationsystem erstellen 2. Aktor gibt Destination Name an 3. Aktor wählt Destination DB aus Liste (tnsname.ora) 4. Aktor gibt die Benutzerinformationen für das Destinationssystem an 5. Tool prüft Datenbankkonfiguration und informiert über fehlende Einstellungen (Datenbankparameter, etc.) 6. Aktor wählt Destinationsschema aus 7. Aktor speichert Destinationsystem - Aktor bricht Konfiguration ab - Destinationsystem wird gespeichert - Destinationsystem wird in Navigationpanel angezeigt Selten Die Destinationsdatenbank muss vom DBA für CDC vorbereitet sein. Normaler Ablauf: Alternativer Ablauf: Nachbedingung: Includes: Gebrauchshäufigkeit: Anmerkungen und Problem: Tabelle 3-6: UC Destinationsystem konfigurieren FA.02.010 10.09.2009 Seite 18 von 35 Pflichtenheft Master Thesis MAS-07-01.21 Use Case ID: Use Case Name: Ersteller: Erstellungsdatum: Aktor: Beschreibung: FA.02.020 Destinationsystem löschen Stefan Lüthi Geändert durch: 22.04.2009 Änderungsdatum: ETL - Programmierer Im Tool können die überflüssigen Destinationen gelöscht werden. Vorbedingung - Das Tool muss aufgestartet sein - DB - Verbindung muss konfiguriert sein - mindestens ein Destinationssystem muss konfiguriert sein 1. Aktor markiert gewünschtes Destinationssystem in Navigationspanel 2. Aktor klickt mit RMT auf Destinationsystem und auf Menupunkt Destinationsystem löschen 3. Aktor klickt auf Button löschen 4. Tool kontrolliert ob keine Sourcesysteme für dieses Destinationsystem bestehen. 5. Löschung Destination - Aktor bricht Löschung ab. - Destinationsystem ist gelöscht. - Destinationsystem wird im Navigationpanel nicht mehr angezeigt. Selten Normaler Ablauf: Alternativer Ablauf: Nachbedingung: Includes: Gebrauchshäufigkeit: Anmerkungen und Problem: Tabelle 3-7: UC Destinationssystem löschen FA.02.020 Use Case ID: Use Case Name: Ersteller: Erstellungsdatum: Aktor: Beschreibung: Vorbedingung Normaler Ablauf: Alternativer Ablauf: Nachbedingung: FA.03.010 Schnittstellengruppe konfigurieren Stefan Lüthi Geändert durch: 22.04.2009 Änderungsdatum: ETL - Programmierer Im Tool können pro Source mehrere Schnittstellengruppen konfiguriert werden. - Das Tool muss aufgestartet sein - DB - Verbindung muss konfiguriert sein - entsprechendes Sourcesystem muss konfiguriert sein - entsprechendes Destination System muss konfiguriert sein 1. Aktor markiert in Navigationspanel das Sourcesystem 2. Aktor klickt mit RMT auf Sourcesystem und wählt Schnittstellengruppe konfigurieren 3. Aktor gibt Name für Schnittstellengruppe an 4. Aktor speichert Schnittstellengruppe - Aktor bricht Konfiguration ab - Schnittstellengruppe ist gespeichert - Schnittstellengruppe wird in Navigationpanel angezeigt Selten Innerhalb dieser Gruppen sind die Tabellen transaktionskonsistent. Includes: Gebrauchshäufigkeit: Anmerkungen und Problem: Tabelle 3-8: UC Schnittstellengruppe konfigurieren FA.03.010 10.09.2009 Seite 19 von 35 Pflichtenheft Master Thesis MAS-07-01.21 Use Case ID: Use Case Name: Ersteller: Erstellungsdatum: Aktor: Beschreibung: Vorbedingung Normaler Ablauf: Alternativer Ablauf: Nachbedingung: FA.03.020 Schnittstellengruppe löschen Stefan Lüthi Geändert durch: 22.04.2009 Änderungsdatum: ETL - Programmierer Im Tool können nicht mehr benötigte Schnittstellengruppen gelöscht werden. - Das Tool muss aufgestartet sein - DB - Verbindung muss konfiguriert sein - mindestens eine Schnittstellengruppe muss konfiguriert sein 1. Aktor klickt mit RMT auf entsprechende Schnittstellengruppe im Navigationspanel 2. Aktor klickt auf Menupunkt Schnittstellengruppe löschen 3. Aktor klickt auf Button löschen 4. Tool kontrolliert ob keine Schnittstellen für diese Schnittstellengruppe bestehen. 5. Löschung Schnittstellengruppe - Aktor bricht Löschung ab - Schnittstellengruppe ist gelöscht - Schnittstellengruppe wird im Navigationpanel nicht mehr angezeigt. Selten - Includes: Gebrauchshäufigkeit: Anmerkungen und Problem: Tabelle 3-9: UC Destinationssystem löschen FA.03.020 Use Case ID: Use Case Name: Ersteller: Erstellungsdatum: Aktor: Beschreibung: Vorbedingung Normaler Ablauf: Alternativer Ablauf: Nachbedingung: Includes: FA.04.010 Schnittstelle konfigurieren Stefan Lüthi Geändert durch: 22.04.2009 Änderungsdatum: ETL - Programmierer Im Tool können Schnittstellen konfiguriert werden. Pro Tabelle gibt es eine Schnittstelle. - Das Tool muss aufgestartet sein - DB - Verbindung muss konfiguriert sein - Schnittstellengruppe muss konfiguriert sein 1. Aktor markiert in Navigationspanel die gewünschte Schnittstellengruppe 2. Aktor klickt mit RMT auf Schnittstellengruppe und wählt Schnittstelle konfigurieren 3. Aktor gibt die geforderten Parameter an 4. Aktor konfiguriert Sourcetabelle (include FA.04.011) 5. Aktor konfiguriert Destinationtabelle (include FA.04.012) 6. Aktor speichert Schnittstelle - Aktor bricht Konfiguration ab - Schnittstelle ist konfiguriert - Schnittstelle wird in Navigationpanel angezeigt - Sourcetabelle konfigurieren FA.04.011 - Destinationstabelle konfigurieren FA.04.012 Max. 50 Schnittstellen pro Tag Gebrauchshäufigkeit: Anmerkungen und Problem: Tabelle 3-10: UC Schnittstelle konfigurieren FA.04.010 10.09.2009 Seite 20 von 35 Pflichtenheft Master Thesis MAS-07-01.21 Use Case ID: Use Case Name: Ersteller: Erstellungsdatum: Aktor: Beschreibung: FA.04.020 Schnittstelle löschen Stefan Lüthi Geändert durch: 22.04.2009 Änderungsdatum: ETL - Programmierer Im Tool können nicht mehr benötigte Schnittstellen gelöscht werden. Vorbedingung - Das Tool muss aufgestartet sein - DB - Verbindung muss konfiguriert sein - mindestens eine Schnittstelle muss konfiguriert sein Normaler Ablauf: 1. Aktor klickt mit RMT auf entsprechende Schnittstelle im Navigationspanel 2. Aktor klickt auf Menupunkt Schnittstelle löschen 3. Aktor klickt auf Button löschen 4. Löschung Schnittstelle Alternativer Ablauf: - Aktor bricht Löschung ab. Nachbedingung: - Schnittstelle ist gelöscht. - Schnittstelle wird im Navigationpanel nicht mehr angezeigt. Includes: Gebrauchshäufigkeit: Selten Anmerkungen und Beim Löschen der Schnittstellen muss auch die Destinationtabelle gelöscht Problem: werden Tabelle 3-11: UC Schnittstelle löschen FA.04.020 Use Case ID: Use Case Name: Ersteller: Erstellungsdatum: Aktor: Beschreibung: FA.04.011 Sourcetabelle konfigurieren Stefan Lüthi Geändert durch: 22.04.2009 Änderungsdatum: ETL - Programmierer Bei der Definition einer Schnittstelle muss die Quelltabelle definiert werden. Vorbedingung - Das Tool muss aufgestartet sein - DB - Verbindung muss konfiguriert sein - Eine Schnittstelle und ausgewählt sein 1. Aktor wählt Source Schema und Tabelle aus 2. Aktor wählt gesamte Tabelle oder selektiert die gewünschten Spalten 3. Aktor speichert ausgewählte Parameter - Aktor bricht Konfiguration ab - Angaben der Sourcetabelle sind zu Schnittstelle gespeichert Max. 50 Tabellen pro Tag Normaler Ablauf: Alternativer Ablauf: Nachbedingung: Includes: Gebrauchshäufigkeit: Anmerkungen und Problem: Tabelle 3-12: UC Sourcetabelle konfigurieren FA.04.011 10.09.2009 Seite 21 von 35 Pflichtenheft Master Thesis MAS-07-01.21 Use Case ID: Use Case Name: Ersteller: Erstellungsdatum: Aktor: Beschreibung: Vorbedingung Normaler Ablauf: Alternativer Ablauf: Nachbedingung: FA.04.012 Destinationtabelle konfigurieren Stefan Lüthi Geändert durch: 22.04.2009 Änderungsdatum: ETL - Programmierer Bei der Definition einer Schnittstelle muss die Destinationtabelle definiert und erstellt werden. - Das Tool muss aufgestartet sein - DB - Verbindung muss konfiguriert sein - Eine Schnittstelle muss ausgewählt sein - Die dazugehörige Sourcetabelle muss konfiguriert sein 1. Aktor wählt Destination Schema aus 2. Aktor definiert die geforderten Parameter 3. Aktor speichert ausgewählte Parameter 4. Tool erstellt die Destinationstabelle - Aktor bricht Konfiguration ab - Angaben der Destinationstabelle sind zu Schnittstelle gespeichert - Tabelle ist auf Destinationsystem erstellt und wird abgefüllt Max. 50 Tabellen pro Tag Includes: Gebrauchshäufigkeit: Anmerkungen und Problem: Tabelle 3-13: UC Destinationtabelle konfigurieren FA.04.012 Use Case ID: Use Case Name: Ersteller: Erstellungsdatum: Aktor: Beschreibung: FA.05.010 Sourcesystem konfigurieren Stefan Lüthi Geändert durch: 22.04.2009 Änderungsdatum: ETL - Programmierer Im Tool können ein oder mehrere Sourcesysteme konfiguriert werden Vorbedingung - Das Tool muss aufgestartet sein - DB - Verbindung muss konfiguriert sein - mindestens ein Destinationssystem muss konfiguriert sein - Sourcedatenbank muss vorbereitet sein (Parameter, etc.) 1. Aktor markiert Destinationssystem 2. Aktor klickt mit RMT auf Destinationssystem und auf Menupunkt Sourcesystem erstellen 3. Aktor gibt Sourcename an 4. Aktor wählt Source DB aus Liste (tnsname.ora) 5. Aktor gibt die Benutzerinformationen für die Verbindung an 6. Tool prüft Datenbankkonfiguration und Informiert über fehlende Einstellungen (Datenbankparameter, etc.) 7. Aktor speichert Source - Aktor bricht Konfiguration ab - Sourcesystem ist gespeichert - Sourcesystem wird in Navigationpanel angezeigt Selten Die Sourcedatenbank muss vom DBA für CDC vorbereitet sein. Normaler Ablauf: Alternativer Ablauf: Nachbedingung: Includes: Gebrauchshäufigkeit: Anmerkungen und Problem: Tabelle 3-14: UC Sourcesystem konfigurieren FA.05.010 10.09.2009 Seite 22 von 35 Pflichtenheft Master Thesis MAS-07-01.21 Use Case ID: Use Case Name: Ersteller: Erstellungsdatum: Aktor: Beschreibung: FA.05.020 Sourcesystem löschen Stefan Lüthi Geändert durch: 22.04.2009 Änderungsdatum: ETL - Programmierer Im Tool können die überflüssigen Sourcesysteme gelöscht werden. Vorbedingung - Das Tool muss aufgestartet sein - DB - Verbindung muss konfiguriert sein - mindestens ein Sourcesystem muss konfiguriert sein 1. Aktor markiert gewünschtes Sourcesystem im Navigationspanel 2. Aktor klickt mit RMT auf Sourcesystem und auf Menupunkt Sourcesystem löschen 3. Aktor klickt auf Button löschen 4. Tool kontrolliert ob keine Schnittstellen für dieses Sourcesystem bestehen. 5. Löschung Sourcesystem - Aktor bricht Löschung ab. - Sourcesystem ist gelöscht. - Sourcesystem wird im Navigationpanel nicht mehr angezeigt. Selten Normaler Ablauf: Alternativer Ablauf: Nachbedingung: Includes: Gebrauchshäufigkeit: Anmerkungen und Problem: Tabelle 3-15: UC Destinationssystem löschen FA.05.020 10.09.2009 Seite 23 von 35 Pflichtenheft Master Thesis MAS-07-01.21 3.2.5 Grafisches User Interface (GUI) 3.2.5.1 Übersicht Tool Das GUI orientiert sich stark am Layout des Oracle SQL Developer. Auf der linken Seite befindet sich der Navigationsteil und auf der rechten Seite kann die Auswahl vom Navigation Panel bearbeitet werden. Die Applikationssprache wird ausschliesslich englisch sein. Abbildung 3-2: GUI 3.2.5.2 Navigation Panel Im Navigationspanel kann mit der rechten Maustaste auf eine Kategorie geklickt werden und es erscheint ein Menu, welches die möglichen Funktionen der gewählten Kategorie enthält. Die gewählte Funktion blendet im rechten Teil des GUI die entsprechenden Werkzeuge und Register ein. 10.09.2009 Seite 24 von 35 Pflichtenheft Master Thesis MAS-07-01.21 3.3 Nicht funktionale Anforderungen Bei den nicht funktionalen Anforderungen, werden nur diese aufgeführt, welche für dieses System wichtig sind. Die Verfügbarkeit der Source und Destinationssysteme, werden in diesem Dokument vernachlässigt. 3.3.1 Anforderungskatalog ID NFA.01 NFA.01.010 NFA.01.020 NFA.01.030 NFA.02 NFA.02.010 NFA.03 NFA.03.010 NFA.03.020 NA.04 NFA.04.010 NFA.04.020 NFA.05 NFA.05.010 NFA.06 NFA.06.010 NFA.06.020 NFA.06.030 NFA.07 NFA.07.010 NFA.08 NFA.08.010 NFA.08.020 NFA.09 NFA.09.010 NFA.09.020 Beschreibung Architektur / Plattform Das GUI muss auf eine Emmi Standard PC lauffähig sein Als Datenbanksystem muss Oracle unterstützt werden Die Erstellung des GUI soll im Visual Studio .net erfolgen Zuverlässigkeit / Stabilität Die Stabilität der neue Schnittstellentechnik soll mindestens der jetzigen Technik entsprechen Performance Die Belastung der Quellsysteme soll um mindestens 70% verringert werden Die Daten jeder Schnittstelle sollen täglich übernommen werden können. Konfiguration Mit der neuen Technik soll der Aufwand der Konfiguration einer neuen Schnittstelle um 50% verringert werden Auf Trigger in den Quellsystemen soll verzichtet werden können Monitoring / Logging Alle Konfigurationen sollen geloggt und ausgewertet werden können. Dokumentation Installationshandbuch muss erstellt werden Benutzerhandbuch muss erstellt werden Projektbericht muss erstellt werden Sicherheit Die Benutzerverwaltung soll dem Emmi Standard für Datenbankbenutzer entsprechen Sprache Die Sprache im Tool muss englisch sein Die Dokumentation soll ausschliesslich in deutscher Sprache erfolgen. Usability Ein ETL - Programmierer soll sich intuitiv im GUI zurechtfinden (Know - How CDC wird vorausgesetzt) Das System soll den User unterstützen möglichst wenig Fehler zu machen M K X X X X X X X X X X X X X X X X X Tabelle 3-16: Anforderungskatalog nicht funktionaler Anforderungen 10.09.2009 Seite 25 von 35 Pflichtenheft Master Thesis MAS-07-01.21 3.4 Rahmenbedingungen 3.4.1 Testsystem / Entwicklungsumgebung Das Test- und Entwicklungssystem wird von der Emmi Schweiz AG zur Verfügung gestellt und muss während der ganzen Projektzeit zur Verfügung stehen. Das Projekt wird in Visual Studio 2008 entwickelt. Als Programmiersprache wird Visual Basic .net verwendet. 3.5 Abgrenzung Das Resultat der Diplomarbeit wird ausschliesslich für eine reine Oracle Umgebung erstellt. Der genaue Umfang der Anforderungen ist den Kapiteln 3.2 und 3.3 zu entnehmen. Von den aufgeführten Anforderungen sind lediglich die Muss - Anforderungen zur erfüllen. Wenn es der zeitliche Aufwand zulässt werden auch Kann - Anforderungen umgesetzt. Bei Abschluss des Projekts ist eine Schnittstelle (Sourcetabelle nach Stagingbereich des DWH) im produktiven System umgesetzt. Die weiteren Konfigurationen der Schnittstellen sind nicht Teil dieses Projekts. 10.09.2009 Seite 26 von 35 Pflichtenheft Master Thesis MAS-07-01.21 4 Testen Getestet wird, um die Funktionalität der Software an den Anforderungen zu messen und um Softwarefehler zu ermitteln. Es werden System- und Usabilitytests durchgeführt. Auf Stresstests wird verzichtet, da dies keine Kernanforderungen an das System ist. Auf Tests der Standardkomponenten wie Oracle, Windows, etc. wird ebenfalls verzichtet. Ein Testsystem wird schon früh im Projekt installiert, damit die ganze Entwicklung auf dieser Plattform realisiert werden kann. 4.1 Systemtests Bei den Systemtests werden sämtliche funktionalen und nicht funktionalen Anforderungen getestet. Jeder Use Cases wird manuell durchgetestet. Dazu werden Schnittstellen in den verschiedenen Möglichkeiten erstellt. In der Entwurfsphase werden zusätzliche Test Cases definiert, um die Applikation auch bei Fehlmanipulationen zu testen. 4.2 Usability Test Wenn die erste Lauffähige Version der Applikation erstellt ist, wird ein Usability Test mit dem ETL - Programmierer durchgeführt. Aus zeitlichen Gründen werden nicht mehrere Personen einbezogen. Das Resultat soll, sofern es mit dem Aufwand des Projekts zu vereinbaren ist, in die Applikation einfliessen. Ansonsten werden die Erkenntnisse festgehalten zu einem späteren Zeitpunkt umgesetzt. 10.09.2009 Seite 27 von 35 Pflichtenheft Master Thesis MAS-07-01.21 5 Planung 5.1 Vorgehensmodell Beim Vorgehensmodell wird sich nach an dem klassischen Wasserfallmodel orientiert. Da in diesem Projekt die Phasen ziemlich genaue abgrenzbar sind und die Laufzeit auch ziemlich kurz ist (5 Monate), sollte sich dieses Vorgehen gut eigenen. Das Modell hat folgende Phasen: Abbildung 5-1: Vorgehensmodell Nachfolgend sind die Inhalte und Resultate pro Projektphase aufgelistet: Projektphase Inhalt Resultat Initialisierung • Projektinitialisierung Auftraggeber • Projektantrag • Kick-Off Meeting Experte Analyse • Pflichtenheft • Analyse der bestehenden Lösung • Analyse möglicher Lösungswege • Projektplan • Diskussion mit Auftraggeber und ETL Programmierer • Definition Ziele und Anforderungen • Projektablauf festlegen • Erstellung Pflichtenheft Entwurf • Erhöhung des Verständnisses der • Detailspezifikation Anforderungen • Erstellen der notwendigen UML Diagramme • Erarbeiten der Detailspezifikation • Definition der Testfälle Realisierung • Konfiguration der Umgebung • Benutzerhandbuch • Entwicklung GUI • Software • Testen der Software • Testprotokoll • Erstellung Benutzerhandbuch Einführung • Umsetzung der neuen Technik in • Diplombericht einem Bereich • Fertigstellung Diplombericht • Präsentation der Diplomarbeit Nutzung • Nicht Bestandteil der Diplomarbeit • Komplette ETL Schnittstelle auf • Flächendeckender Einsatz der neuen neuen Technik Technik umgesetzt Tabelle 5-1: Inhalte und Resultate der Projektphasen 10.09.2009 Seite 28 von 35 Pflichtenheft Master Thesis MAS-07-01.21 5.2 Aufwandschätzung Arbeit Projektleitung Dokumentation Projektantrag Pflichtenheft Detailspezifikation Benutzerhandbuch Diverse Protokolle Diplombericht Prototyping Analyse Bestehende Lösung Lösungswege Entscheide Entwurf Architektur Design Realisierung Installation Testumgebung Konfiguration Umgebung Ausbildung .net Programmierung Konfigurationstool Testing Einführung Konfiguration produktive Umgebung Installation Konfigurationstool Inbetriebsetzung produktive Schnittstelle Schulung Anwender Aufwand Total Aufwand in Std. 24 124 2 36 36 14 8 28 42 24 8 14 2 28 12 16 132 10 10 32 44 36 32 10 10 8 4 392 Tabelle 5-2: Aufwandschätzung 10.09.2009 Seite 29 von 35 5.3 Projektplan / Zeitplan und Meilensteine Abbildung 5-2: Projektplan Pflichtenheft Master Thesis MAS-07-01.21 5.4 Termine Termin 20.04.2009 23.04.2009 04.06.2009 20.08.2009 10.09.2009 11.09.2009 Ziel Review Pflichtenheft Abgabe Pflichtenheft Review Entwurf (Detailspezifikation) Review Realisierung Abgabe Diplomarbeit Präsentation Diplomarbeit Tabelle 5-3: Termine 5.5 Projektmanagement Der Projektplan kann aufgrund neuer Erkenntnisse einer vorgängigen Phase überprüft und angepasst werden. In der Entwurfsphase wird nach Bedarf eine zweite Iteration durchgeführt, um die Analyse zu verfeinern und zu vertiefen. 5.6 Meetings / Reviews /Statusmeldungen 5.6.1 Meetings Mit dem Experten wird nach jeder Phase ein Meeting durchgeführt. Mit dem Betreuer, welcher auch gleichzeitig der Auftraggeber darstellt, werden nur nach Bedarf Meetings durchgeführt. 5.7 Reviews Die Meetings mit dem Experten, können zum Teil auch gerade als Review einer vergangenen Phase verwendet werden. 5.7.1 Statusmeldungen Dem Experten und dem Betreuer wird jede zweite Woche ein Statusreport (Vorlage von BFH) gesendet, damit diese über den Projektfortschritt auf dem Laufenden sind. 10.09.2009 Seite 31 von 35 Pflichtenheft Master Thesis MAS-07-01.21 6 Kosten 6.1 Interner personeller Aufwand (Kosten) Aufwand Emmi intern Ausbildung (.net Kurs) zu Lasten des Diplomanden Gesamtaufwand intern Stunden 240 32 120 392 Ansatz / Std 100.-100.--100.-- Total in sFr 24'000.-3'200.--27’200 Stunden - Ansatz / Std - Total in sFr - Tabelle 6-1: Interne personelle Aufwände 6.2 Externe Kosten Aufwand / Kosten Externe Beraterkosten Externes Personal Software Lizenzen • Visual Studio .net Ausbildung (.net Kurs) Gesamtaufwand - - 713.65 2'600.-3’313.65 Tabelle 6-2: Externe Kosten 6.3 Kosten gesamt Kosten Interne Kosten Externe Kosten Gesamtaufwand Total in sFr 27'200.-3’313.65 30’513.65 Tabelle 6-3: Kosten gesamt 10.09.2009 Seite 32 von 35 Pflichtenheft Master Thesis MAS-07-01.21 7 Anhang 7.1 Glossar Begriff Aktor Beschreibung Ein Aktor ist ein Benutzer oder ein System welches mit der Applikation interagiert. CDC Change Data Capture - Technologie von Oracle zum Übertragen der Änderungen einer Datenbank zentrale Verarbeitungseinheit eine Computers (Prozessor) Datenbank Datenbankadministrator Ziel - in diesem Projekt meist der Staging bereich des DWH Datawarehouse. Zentrale Datensammlung (Datenbank), deren Inhalt sich aus Daten unterschiedlicher Quellen zusammensetzt. CPU DB DBA Destination DWH E1 EFM ERP ETL GUI Name des ERP Releases, welcher in der EMMI eingesetzt wird. Emmi Factory Management Enterprise Ressource Planning Bezeichnet den Prozess einer Schnittstelle zu einem DWH. E. Extraktion (Extract) der relevanten Daten aus verschiedenen Quellen T. Transformation (Transform) der Daten in das Format der Zieldatenbank L. Laden (Load) der Daten in die Zieldatenbank. Graphical User Interface, englischer Begriff für Bedienoberfläche. LDI MIS OLAP OLTP Oracle Proof of Concept Records Redo Logs Review RMT Rows SCN Source tnsnames.ora Lightweight Datewarehouse Interface Management Information System Online Analytical Processing Online Transaction Processing Oracle ist eine Datenbankmanagementsoftware Machbarkeitsstudie Datensatz einer Tabelle Dort werde alle Änderungen einer DB gespeichert Begutachtung Rechte Maus Taste siehe Record System Change Number Quelle - in diesem Projekt eine ERP System File welches die auf dem Client konfigurierten Datenbanken enthält Tool Trigger Werkzeug Datenbanktrigger. Bei einer bestimmten Art einer Änderung, wird ein gespeichertes Programm aufgerufen. Unified Modeling Language Anwendungsfall - Verhalten zwischen Aktoren und dem betrachteten System UML Use Case Tabelle 7-1: Glossar 10.09.2009 Seite 33 von 35 Pflichtenheft Master Thesis MAS-07-01.21 7.2 Referenzen Folgende Dokumente und Webadressen dienten als Informationsquellen. Projektmanagement http://de.wikipedia.org/ http://www.stefan-baur.de http://www.it-checklists.com Unterlagen BFH CAS Business Engineering, Zühlke Engineering AG Oracle Data Capture Oracle Data Warehousing Guide 10g Release 2 (B14223-02) Oracle Data Warehousing Guide 11g Release 1 (B28313-02) ETL Architektur The Data Warehouse Lifecycle Toolkit, Ralph Kimball 10.09.2009 Seite 34 von 35 Pflichtenheft Master Thesis MAS-07-01.21 7.3 Tabellenverzeichnis Tabelle 2-1: Entscheidungstabelle........................................................................................ 13 Tabelle 3-1: Namenskonvention der Anforderungen............................................................. 15 Tabelle 3-2: Übersicht Use Cases ........................................................................................ 15 Tabelle 3-3: Aktoren ............................................................................................................. 17 Tabelle 3-4: UC Login FA.01.010 ......................................................................................... 17 Tabelle 3-5: UC DB Verbindung konfigurieren FA.01.020..................................................... 18 Tabelle 3-6: UC Destinationsystem konfigurieren FA.02.010................................................ 18 Tabelle 3-7: UC Destinationssystem löschen FA.02.020 ...................................................... 19 Tabelle 3-8: UC Schnittstellengruppe konfigurieren FA.03.010............................................. 19 Tabelle 3-9: UC Destinationssystem löschen FA.03.020 ...................................................... 20 Tabelle 3-10: UC Schnittstelle konfigurieren FA.04.010........................................................ 20 Tabelle 3-11: UC Schnittstelle löschen FA.04.020................................................................ 21 Tabelle 3-12: UC Sourcetabelle konfigurieren FA.04.011 ..................................................... 21 Tabelle 3-13: UC Destinationtabelle konfigurieren FA.04.012............................................... 22 Tabelle 3-14: UC Sourcesystem konfigurieren FA.05.010 .................................................... 22 Tabelle 3-15: UC Destinationssystem löschen FA.05.020 .................................................... 23 Tabelle 3-16: Anforderungskatalog nicht funktionaler Anforderungen................................... 25 Tabelle 5-1: Inhalte und Resultate der Projektphasen .......................................................... 28 Tabelle 5-2: Aufwandschätzung ........................................................................................... 29 Tabelle 5-3: Termine ............................................................................................................ 31 Tabelle 6-1: Interne personelle Aufwände ............................................................................ 32 Tabelle 6-2: Externe Kosten ................................................................................................. 32 Tabelle 6-3: Kosten gesamt.................................................................................................. 32 Tabelle 7-1: Glossar ............................................................................................................. 33 7.4 Abbildungsverzeichnis Abbildung 2-1: ETL Prozess Schema ..................................................................................... 7 Abbildung 2-2: Ladeprozess grösserer Tabellen..................................................................... 8 Abbildung 2-3: CPU Kurve Quellsystem ................................................................................. 9 Abbildung 2-4: Prozessablauf Vision .................................................................................... 10 Abbildung 2-5: Prozessablauf Change Data Capture ........................................................... 12 Abbildung 3-1: Use Case Diagramm LDI .............................................................................. 16 Abbildung 3-2: GUI............................................................................................................... 24 Abbildung 5-1: Vorgehensmodell.......................................................................................... 28 Abbildung 5-2: Projektplan ................................................................................................... 30 10.09.2009 Seite 35 von 35
