AbschlussprÃ¼fung Sommer 2017 - Dokumentation · d W/ D Æ ] u ] o ] v D À ] v

Abschlussprüfung Sommer 2017

Fachinformatiker für Anwendungsentwicklung

Dokumentation zur betrieblichen Projektarbeit

TAPI Implementierung einer Schnittstelle zu Telekommunikationsanlagen

und eine Zuordnung der Anrufer zu bestehenden Kundendatensätzen

Abgabetermin: 19.05.2017

Prüfungsbewerber:

Maximilian Marvin

Marienweg 2

96215, Lichtenfels

Ausbildungsbetrieb:

Z.I.E.L. GmbH

Judengasse 14

96215 Lichtenfels

TAPI

© Maximilian Marvin II

Inhaltsverzeichnis

Inhaltsverzeichnis Abbildungsverzeichnis ............................................................................................................................. V

Tabellenverzeichnis ................................................................................................................................ VI

Abkürzungsverzeichnis .......................................................................................................................... VII

Listingverzeichnis.................................................................................................................................. VIII

1. Einleitung ............................................................................................................................................ IX

1.1 Projektbeschreibung .................................................................................................................... IX

1.2 Projektziel ...................................................................................................................................... X

1.3 Projektumfeld ................................................................................................................................ X

1.4 Projektbegründung ....................................................................................................................... XI

1.5 Projektschnittstellen .................................................................................................................... XI

1.6 Projektabgrenzung ...................................................................................................................... XII

2. Projektplanung .................................................................................................................................. XII

2.1 Projektphasen .............................................................................................................................. XII

2.2 Abweichungen vom Projektantrag ............................................................................................. XIII

2.3 Ressourcenplanung .................................................................................................................... XIII

2.4 Entwicklungsprozess .................................................................................................................. XIII

3. Planungs- und Analysephase ............................................................................................................ XIV

3.1 Ist-Analyse .................................................................................................................................. XIV

3.2 Soll-Konzept ................................................................................................................................. XV

3.3 Erstellung des Lastenheftes ......................................................................................................... XV

3.4 Wirtschaftlichkeitsanalyse ........................................................................................................... XV

3.4.1 „Make or Buy“ Entscheidung ............................................................................................... XV

3.4.2 Projektkosten ....................................................................................................................... XV

3.4.3 Amortisationsdauer ............................................................................................................. XVI

3.4.4 nicht-monetäre Vorteile ..................................................................................................... XVII

4. Entwurfsphase ................................................................................................................................. XVII

4.1 Zielplattform .............................................................................................................................. XVII

4.2 Architekturdesign ..................................................................................................................... XVIII

4.3 Benutzeroberflächen entwerfen ................................................................................................ XIX

4.4 Datenbankdesign konzipieren .................................................................................................... XIX

4.5 Planung der Geschäftslogik ......................................................................................................... XX

4.6 Pflichtenheft ............................................................................................................................... XXI

5. Implementierungsphase ................................................................................................................... XXI

5.1 Iterationsplanung ....................................................................................................................... XXI

TAPI

© Maximilian Marvin III

5.2 Benutzeroberflächen erstellen ................................................................................................... XXI

5.3 Datenbankdesign realisieren ...................................................................................................... XXI

5.4 Geschäftslogik umsetzen ........................................................................................................... XXII

6. Qualitätsmanagement .................................................................................................................... XXIII

6.1 Sammeln von möglichen Testfällen und Situationen ............................................................... XXIV

6.1.1 Vorbereitungen und Entscheidung bezüglich des Testverfahrens .................................... XXIV

6.1.2 Sammeln von Testfällen- und Situationen ........................................................................ XXIV

6.2 Testfälle gemäß gesammelter Infos erstellt und durchgeführt ................................................ XXV

6.3 Fehlerbehebung ........................................................................................................................ XXV

6.4 Code-Review mit dem Entwicklungsleiter ................................................................................ XXVI

6.4.1 Erstellen einer Testversion von SYNCCESS® ...................................................................... XXVI

7. Erstellen der Dokumentationen ..................................................................................................... XXVI

7.1 Projektdokumentation ............................................................................................................. XXVI

7.2 Entwicklerdokumentation ....................................................................................................... XXVII

7.3 Anwenderdokumentation ....................................................................................................... XXVII

7.4 Fehlerdokumentation .............................................................................................................. XXVII

8. Projektbewertung .......................................................................................................................... XXVII

8.1 Fazit ......................................................................................................................................... XXVII

8.2 Ausblick.................................................................................................................................... XXVII

Literaturverzeichnis .......................................................................................................................... XXVIII

A Anhang ............................................................................................................................................ XXIX

A.1 Detaillierte Zeitplanung............................................................................................................ XXIX

A.2 Verwendete Ressourcen ........................................................................................................... XXX

A.3 EPK des Ist-Zustandes............................................................................................................... XXXI

A.4 Lastenheft (Auszug) ................................................................................................................. XXXII

A.5 Oberflächenentwürfe ............................................................................................................. XXXIII

A.6 Analyse des Kommunikationsablaufs und herausfiltern der nötigen Entitäten .................... XXXIV

A.7 Entity Relationship Modell ...................................................................................................... XXXV

A.8 Tabellenmodell ....................................................................................................................... XXXVI

A.9 Pflichtenheft(Auszug) ............................................................................................................ XXXVII

A.10 SQL-Prozedur „SucheEreignisse“ ....................................................................................... XXXVIII

A.11 Iterationsplan ............................................................................................................................ XLI

A.12 Screenshots der Oberflächen ................................................................................................... XLII

A.13 Listing – RadGridView ............................................................................................................. XLIII

A.14 – Listings der Kern-Klassen ..................................................................................................... XLIV

A.15 Listings – Klassen „AnrufersucheZeile“ und „EreignissucheZeile“ ......................................... XLVI

TAPI

© Maximilian Marvin IV

A.16 Listing – Methode „AnruferSuche“ ...................................................................................... XLVIII

A.17 Listing - Methode „SucheEreignisse“ ......................................................................................XLIX

A.18 Listing – Anrufer-Kunde Zuordnung ............................................................................................. L

A.19 Listings – Event-Handler der TAPI-Schnittstelle(Auszug) ............................................................ LI

A.20 Listings - Methoden der Tapi-Maske(Auszug) ......................................................................... LIII

A.21 Hinterlegung der TAPI-Leitung in der Administration von SYNCCESS® ................................... LIV

A.22 Listing – XAML-Code des „Speichern und auflegen“-Button .................................................... LV

A.23 Listing – Beispielkorrektur des XAML-Code ............................................................................. LVI

A.24 Entwicklerdokumentation(Auszug) ......................................................................................... LVII

A.25 Anwenderdokumentation(Auszug) ........................................................................................ LVIII

A.26 Fehlerdokumentation(Auszug) ................................................................................................. LIX

TAPI

© Maximilian Marvin V

Abbildungsverzeichnis

Abbildungsverzeichnis

Abbildung 1: Suchmaske ...................................................................................................................... XIV Abbildung 2: EPK des Ist-Zustandes ................................................................................................... XXXI Abbildung 3: Mock-Up der Anruferliste ........................................................................................... XXXIII Abbildung 4: Mock-Up der neuen TAPI-Maske ................................................................................ XXXIII Abbildung 5: Entity Relationship Modell ........................................................................................... XXXV Abbildung 6: Screenshot - Anruferliste ................................................................................................ XLII Abbildung 7: Screenshot - Tapi-Maske ................................................................................................. XLII Abbildung 8: TAPI-Einstellungen in der Administration von SYNCCESS® ............................................. LIV

TAPI

© Maximilian Marvin VI

Tabellenverzeichnis

Tabellenverzeichnis

Tabelle 1 : Grobe Zeitplanung .............................................................................................................. XIII Tabelle 2: Aufstellung der Projektkosten ............................................................................................. XVI Tabelle 3: Beispielhafte Modulkosten .................................................................................................. XVI Tabelle 4: Zeiteinsparung ..................................................................................................................... XVI

TAPI

© Maximilian Marvin VII

Abkürzungsverzeichnis

Abkürzungsverzeichnis

ASP.NET .............................................................................................................. Active Server Pages .NET EPK .......................................................................................................... Ereignisgesteuerte Prozesskette ERM ................................................................................................................. Entity Relationship Modell FiBu .............................................................................................................................. Finanzbuchhaltung GUI .................................................................... graphical User Interface / grafische Benutzeroberfläche MVC ....................................................................................................................... Model View Controller TAPI .................................................................................. Telephony Application Programming Interface TFS ..................................................................................................................... Team-Foundation-Server TK-Anlagen .................................................................................................. Telekommunikationsanlagen WPF .................................................................................................... Windows Presentation Foundation XAML ....................................................................................... Extensible Application Markup Language

TAPI

© Maximilian Marvin VIII

Listingsverzeichnis

Listingverzeichnis

Listing 1: SQL-Prozedur "SucheEreignisse"

Listing 2: RadGridView

Listing 3: Klasse "EreignisZuordnung"


Listing 5: Klasse "AnrufersucheZeile

Listing 6: Klasse "EreignissucheZeile"

Listing 7: Methode "AnruferSuche"

Listing 8: Methode "SucheEreignisse"

Listing 9: Anrufer-Kunde Zuordnung

Listing 10: Event-Handler "EingehenderAnruf"

Listing 11: Event-Handler "EingehenderAnrufVerbunden"

Listing 12: Event-Handler "AnrufBeendet"

Listing 13: Methode "SpeichereEreignis”

Listing 14: XAML-Code "Speichern und auflegen"-Button

Listing 15: XAML-Code Beispielkorrektur(vorher)

Listing 16: XAML-Code Beispielkorrektur(nachher)

Listing 17: Entwicklerdokumentation(Auszug) - Beispielkommentare

TAPI

© Maximilian Marvin IX

Einleitung

1. Einleitung

Die folgende Projektdokumentation beschreibt den Entwicklungsprozess des IHK-Abschlussprojekts, welches der Autor im Rahmen seiner Ausbildung zum Fachinformatiker, Fachrichtung Anwendungsentwicklung, durchgeführt hat.

Der zuständige Ausbildungsbetrieb war die Z.I.E.L. GmbH in Lichtenfels, Bayern.

1.1 Projektbeschreibung

In einem Reisebüro gibt es ein enorm hohes Maß an täglich anfallender Kommunikation, in den meisten Fällen via Telefon. Gegenstand dieser Gespräche sind häufig Rückfragen zu bereits gebuchten Reisen, das Interesse an einem Beratungsgespräch oder ähnlichen Anliegen. Im Zuge solcher Nachfragen ist es häufig nötig zuerst die Kundendaten sowie dessen Warenkörbe abzurufen. Um dem Expedient1 an dieser Stelle den manuellen Aufwand abzunehmen, und somit mehr Fokus auf das Gespräch mit dem Anrufer selbst zu gewährleisten, ist hier angedacht Abhilfe zu schaffen.

Eine ähnliche Situation spiegelt sich firmenintern in der Z.I.E.L. wieder. Der Support von Kunden findet über eine interne Support-Abteilung statt. Um einen Anrufer bei einem spezifischen Problem zu helfen ist es meistens notwendig dass dieser sich authentifiziert. Im Zuge dieses Arbeitsablaufes muss der Mitarbeiter nach der Kundennummer des Anrufers fragen, um anschließend dessen Kundendaten und offene Calls anzuzeigen. In SYNCCESS® gibt es ein zusätzliches Modul, das Call-Center. Dabei werden Anliegen, die durch Kunden entstehen, als Call abgelegt. Zudem ist es häufig auch so, dass der Mitarbeiter sich Notizen zum Gespräch anfertigt. Diese Aufzeichnung findet häufig noch in reiner Papierform statt. Somit ist hier eine ähnliche Situation gegeben, weshalb eine entsprechende Abwendung des manuellen Aufwands ebenfalls für interne Arbeitsabläufe der Z.I.E.L. diverse Vorteile hätte.

SYNCCESS®, ein voll-modulares Mid- und Back-Office System, stellt das Kerngeschäft der Z.I.E.L. GmbH dar. Diese Modularität zeichnet sich durch den Aufbau des Systems aus. Es gibt grundlegende Programmbestandteile, wie in etwa eine Kunden- und Vorgangsverwaltung. Zu diesen lassen sich je nach Bedarf zusätzliche Module zuschalten. Eines dieser Module ist die Telephony Application Programming Interface(TAPI). Hierbei wird mit Hilfe einer Schnittstelle zu Telekommunikationsanlagen (TK-Anlagen) die Möglichkeit geboten, direkt aus dem System heraus Anrufe zu tätigen. Da dieses Modul jedoch nicht die benötigte Funktionalität für eine Reduzierung des manuellen Aufwands bereitstellt, ist eine Erweiterung und Neustrukturierung nötig.

1 Expedient: Reisebürokaufmann

TAPI

© Maximilian Marvin X

Einleitung

1.2 Projektziel

Eines der Ziele des Projekts ist eine Anruferliste, welche die eingegangenen Anrufe protokolliert und hierarchisch anzeigt. Außerdem soll eine neue Maske entstehen, welche die Daten eventuell getätigter Zuordnungen zwischen Anrufer und Kunde, strukturiert anzeigt und die Möglichkeit bietet zu dem Gespräch eine Notiz zu erfassen. Zukünftig sind diverse Auswertungen geplant, wie in etwa die durchschnittliche Gesprächsdauer eines einzelnen Mitarbeiters pro Tag. Um das zu ermöglichen müssen bereits hier entsprechende Grundlagen dafür geschaffen werden. Dies geschieht durch eine sinnvolle Speicherung der Daten in der Datenbank. Abschließend sollen diese Änderungen in eine Testversion von SYNCCESS® implementiert werden, welche anschließend an den Auftraggeber übergeben wird.

1.3 Projektumfeld

Der Auftraggeber des Projekts ist die Z.I.E.L. GmbH, deren Firmensitz in Lichtenfels, Bayern, ist.

Mit ca. 30 Mitarbeitern entwickelt und vertreibt Z.I.E.L. erfolgreich individualisierte Soft- und Hardware-Lösungen für die Tourismusbranche, insbesondere Reisebüros.

Für die Anforderungen an die Umsetzung des Projekts stehen mehrere Ansprechpartner bereit. Herr Gerd Laatz, seinerseits Geschäftsführer der Z.I.E.L., Herr Erik Gentsch, Leiter der Abteilungen Business Development und Qualitätssicherung, sowie Herr Markus Grüner, Entwicklungsleiter der Z.I.E.L.. Zudem wird mit den Mitarbeitern des Supports der Z.I.E.L. gesprochen, da diese die bisherige Implementierung der TAPI bereits genutzt haben und somit bestens mit eventuellen Herausforderungen und Einzelheiten vertraut sind. Vor allem bei der Betreuung der Kunden und deren Anliegen ist häufig Kommunikation über TK-Anlagen nötig, weshalb der Autor hier auf die Erfahrung der Mitarbeiter zurückgreifen kann. Diese wird vor allem bei der Zusammentragung von möglichen Testfällen von Wert sein.

Den Kern des Geschäfts stellt SYNCCESS® dar, ein voll-modulares Mid- und Back-Office System für Reisebüros. Mit dem Ziel den Expedienten im Reisebüro den Fokus auf den Verkauf von Reisen und der Beratung von Kunden zu ermöglichen, bietet SYNCCESS® vor allem im Bereich der Finanzbuchhaltung (FiBu) und Vorgangs- sowie Kundenverwaltung ein hohes Maß an Automatismen.

Um sämtlichen Anforderungen an der Umsetzung des Projekts gerecht zu werden, ist eine intensive und regelmäßige Kommunikation und Absprache mit allen Ansprechpartnern nötig.

TAPI

© Maximilian Marvin XI

Einleitung

1.4 Projektbegründung

Es gibt mehrere Faktoren, die für die Initiierung dieses Projekts eine Rolle spielen. Einerseits geht es um die Reduzierung des bereits in der Projektbeschreibung beschriebenen hohen, manuellen Aufwand bei der Kommunikation über TK-Anlagen, sowie die dadurch nötige Anrufer-Authentifizierung. Die Modernisierung der Benutzeroberflächen in SYNCCESS® ist ein bereits in der Z.I.E.L. laufendes Projekt, welches hier direkt unterstützend berücksichtigt werden kann. Das System selbst ist komplett web-basiert konzipiert und entwickelt worden. Als die Software 2004 ihre Markteinführung hatte, wurden die Oberflächen in Active Server Pages .NET (ASP.NET) erstellt. Nun wird das System seit 2010 nach und nach auf Windows Presentation Foundation (WPF) umgestellt. Da die grafische Benutzeroberfläche(GUI) der bisherigen Umsetzung der TAPI ebenfalls in ASP.NET vorliegt, wird die im Rahmen dieses Projekts entstehende GUI direkt in WPF realisiert.

Hieraus ergeben sich einige Vorteile. Dadurch, dass die bisherige Implementierung auf ASP.NET basiert, sind zusätzlich Webserver für diese Seiten nötig. Dank der Substitution dieser Websites durch auf WPF basierende Oberflächen, steht der Abschaltung der bisher benötigten Webserver somit ein Programmteil weniger im Weg. Durch diese Abschaltung würde die Administration dieser wegfallen. Dadurch lassen sich Kosten und auch zeitlicher Aufwand einsparen. Zuerst fallen die fixen Kosten, welche durch den Betrieb und der Wartung der Server entstehen, weg. Dadurch entfällt der benötigte zeitliche Aufwand bei der durch den Betrieb und der Wartung entsteht.

Dank der endlosen Gestaltungsmöglichkeiten und dem zeitgemäß modernen Design der neuen Oberflächen würden sich diese auch besser präsentieren und vermarkten lassen. Damit kann Neukunden direkt ein optisch ansprechendes und modernes Produkt gezeigt und angeboten werden. Zudem wird diese Modernisierung auch für Bestandskunden freigeschalten. Diese kontinuierliche Weiterentwicklung, sowie der Ausbau des Systems SYNCCESS®, stärken somit das Vertrauen der Kunden in eine zukunfts- und kundenorientierte Entwicklungsplanung der Firma Z.I.E.L..

Zudem wird durch die automatische Zuordnung von Anrufer zu eventuell vorhandenen Kunden der tägliche Arbeitsablauf der Support-Mitarbeiter der Z.I.E.L. wesentlich erleichtert.

Zusammen mit der Tatsache, dass die steigende Relevanz von IP-basierten TK-Anlagen enormes Markt- und Entwicklungspotential mit sich zieht, würde eine Umstellung und Erweiterung der bereits vorhandenen Funktionen somit viele Vorteile bringen.

1.5 Projektschnittstellen

Um die Kommunikation zwischen den Telekommunikationsanlagen und SYNCCESS® zu ermöglichen, muss eine Schnittstelle dafür implementiert werden. Hierfür soll die externe Programmbibliothek AddTapi.NET von Traysoft2 verwendet werden. Dadurch wird gewährleistet dass jede TK-Anlage und deren Anbindung an das System unabhängig von deren Hersteller oder ähnlichen Faktoren, welche sich von Anlage zu Anlage unterscheiden können, von SYNCCESS® erkannt und angesprochen werden kann.

2 AddTapi.NET: http://www.traysoft.com/add-tapi-telephony-library

TAPI

© Maximilian Marvin XII

Einleitung + Projektplanung

Um ein einheitliches Design, in Anbetracht der bereits in SYNCCESS® vorhandenen Oberflächen, zu gewährleisten, wird die von Telerik3 angebotene Programmbibliothek „UI for WPF“4 genutzt. Diese inkludiert erweiterte Grafikelemente zur Gestaltung der GUI.

Die Mittel für dieses Projekt werden vorerst von der Z.I.E.L. GmbH bereitgestellt. Der Break-Even-Point5 für dieses Projekt soll primär durch den Verkauf des Moduls erzielt werden, wobei die zeitlichen Einsparungen bei den täglichen Arbeitsabläufen der Mitarbeiter der Z.I.E.L. GmbH ebenfalls zu berücksichtigen sind.

Die Zielgruppe gliedert sich in zwei Teile. Primär ist diese Umsetzung für die Anwender von SYNCCESS® gedacht. Sekundär wird dieses Modul ebenfalls von den Mitarbeitern der Z.I.E.L. GmbH, insbesondere dem Support, genutzt. Der Support der Z.I.E.L. GmbH kümmert sich um sämtliche Angelegenheiten der Kunden.

1.6 Projektabgrenzung

SYNCCESS® ist voll-modular aufgebaut. Im Rahmen dieser Modularität existieren bereits Features. Mit Hilfe dieser Features findet die Differenzierung der Module pro Kunde statt. Somit existiert für jedes Modul das angeboten wird ein eigenes Feature. Diese Features sind in der ebenfalls kundenspezifischen Datenbank gespeichert. Diese Logik ist bereits vorhanden und wird hier lediglich genutzt. Zudem existieren bereits die Kundendatenbanken, da diese direkt beim erstmaligen Anlegen der Kunden in unserem eigenen Bestand von SYNCCESS® angelegt werden. Um die Anbindung und Erkennung sämtlicher TK-Anlagen zu gewährleisten, ist bereits die AddTapi.Net Bibliothek von Traysoft in das System eingebunden. Auf diese wird hier zurückgegriffen.

Ebenfalls vorhanden ist bereits die für die Rufnummernsuche zuständige SQL-Prozedur. Diese wird im Zuge der Umsetzung an die Anforderungen des Projekts angepasst.

2. Projektplanung

Die Projektplanung soll die benötigte Zeit sowie verwendete Ressourcen darstellen. Zudem soll der Prozess der Projektdurchführung geplant werden.

2.1 Projektphasen

Vor Projektbeginn wurde die zur Verfügung stehende Zeit in verschiedene Phasen eingeteilt. Diese Zeit beläuft sich auf 70 Stunden. Diese Einteilung ist in der Tabelle 1: Grobe Zeitplanung zu sehen. Dargestellt wird jeweils die Phase zusammen mit der geplanten Zeit. Diese Hautphasen lassen sich zusätzlich in kleinere Unterphasen, welche zum Beispiel einen einzelnen Arbeitsschritt oder Prozess darstellen können, unterteilen. Diese Darstellung der aufgeteilten Hauptphasen befindet sich im Anhang A.1 Detaillierte Zeitplanung.

3Vgl. http://www.telerik.com

4 Vgl. http://www.telerik.com/products/wpf/overview.aspx

5Break-Even-Point: Gewinnschwelle (Deckung der fixen und variablen Kosten)

TAPI

© Maximilian Marvin XIII

Projektplanung

Projektphase Geplante Zeit Planungs- und Analysephase 7h Entwurfsphase 14h Implementierungsphase 25h Qualitätsmanagement 10h Erstellen der Dokumentationen 13h Projektbewertung 1h Gesamt 70h

Tabelle 1 : Grobe Zeitplanung

2.2 Abweichungen vom Projektantrag

Zusätzlich zu den im Projektantrag genannten Ressourcen nutzt der Autor „ARIS Express“6 sowie „Enterprise Architect“7. Das Programm dient dazu diverse Diagramme, wie zum Beispiel EPK, anzufertigen. Zudem wurde die Gliederung aus dem Projektantrag des Autors weiter aufgeschlüsselt und um ein paar Punkte, z.B.: der Beschreibung des Architekturdesigns sowie der Zielplattform, ergänzt, so dass der Aufbau des Projekts noch klarer wird.

2.3 Ressourcenplanung

In der Übersicht A.2 Verwendete Ressourcen sind jegliche für dieses Projekt nötige Ressourcen zu sehen. Beachtet wurden dabei die genutzte Hardware, Software und hinzugezogenes Personal. Bei der Verwendung von Software von Drittanbietern wurde stets darauf geachtet, dass diese entweder kostenlos nutzbar ist, oder die Lizenzen bereits vorhanden sind. Dadurch ist gewährleistet dass der Aspekt der Wirtschaftlichkeit weiterhin beachtet wird.

2.4 Entwicklungsprozess

Der Realisierung des Projekts vorgehend ist die Entscheidung des Autors bezüglich eines Entwicklungsprozesses. An dem ausgewählten Entwicklungsprozess orientiert sich die gesamte Vorgehensweise der Umsetzung. Hierbei gilt es die Anforderungen an die Umsetzung zu beachten. Da im Rahmen dieses Projekts mehrere einzelne Teilergebnisse voneinander unabhängig angefertigt werden, wurde hier ein agiler Entwicklungsprozess ausgewählt. Dieser erlaubt ein iteratives Durchlaufen der Projektphasen und ermöglicht zudem kontinuierliche Rücksprache mit den Stakeholdern8.

6Vgl. http://www.ariscommunity.com/aris-express

7Vgl. http://www.sparxsystems.de/start/startseite/

8Stakeholder: sämtliche am Projekt beteiligte Personen, Institutionen sowie Dokumente

TAPI

© Maximilian Marvin XIV

Projektplanung + Planungs- und Analysephase

Diese Herangehensweise ist von dem Vorgehensmodell Scrum abgeleitet. Die relativ kurzzeitigen Iterationen erlauben eine stetige Präsentation der in den Iterationen entstandenen Resultate. Als Resultat der kontinuierlichen Kommunikation entsteht ebenso eine gesteigerte Reaktionsfähigkeit auf Änderungswünsche. Das iterative durchlaufen der Phasen gewährt eine schnelle Reaktionszeit auf eventuelle Änderungswünsche. Dadurch, dass sämtliche am Projekt beteiligte Personen stets die Resultate sehen, ist es meist nicht nötig eine äußerst ausführliche Schulung zu dem Projektergebnis durchzuführen. Das resultiert in einer sanfteren und voraussichtlich ruhigeren Einführung der Änderungen.

3. Planungs- und Analysephase

3.1 Ist-Analyse

Ein großer Teil der täglich in einem Reisebüro anfallenden Kommunikation findet via Telefon statt. Gegenstand dieser Gespräche sind zu meist Rückfragen zu bereits getätigten Buchungen, Interesse an einer Beratung oder ähnliche Anliegen. Um hier Auskunft geben zu können müssen die Daten9 zu dem jeweiligen Kunden manuell in eine Suchmaske, siehe Abbildung 1: Suchmaske, eingegeben werden, so dass dessen Daten dargestellt werden können.

Im Support der Z.I.E.L. GmbH findet man eine ähnliche Situation vor. Hier gilt es ebenso manuell die Informationen zu einem Anrufer im System herauszusuchen.

Die bisherige Implementierung der TAPI ermöglicht somit keinerlei Zuordnung zwischen Anrufer und bestehenden Kundeninformationen. Zudem fehlt eine entsprechende Anzeige aller getätigten und angenommenen Anrufe, weshalb es schwer wird innerhalb des Systems Übersicht über die Kommunikation zu behalten. Zudem gibt es keine Möglichkeit eine digitale Notiz zu dem Gespräch zu verfassen, was sehr häufig der Fall beider Zielgruppen ist.

Um diesen Prozess der Kommunikation besser nachvollziehen zu können wurde dieser in Form einer ereignisgesteuerten Prozesskette(EPK) dargestellt, siehe A.3 EPK des Ist-Zustandes.

9Daten: Personendaten sowie getätigte Buchungen in Form von Warenkörben

Abbildung 2: Suchmaske

TAPI

© Maximilian Marvin XV

Planungs- und Analysephase

3.2 Soll-Konzept Nun gilt es auszuarbeiten, wie das Modul in seiner Gesamtheit aussehen und agieren soll. Im Vordergrund steht hier natürlich das Ziel, dem Expedienten den manuellen Aufwand, der im Abschnitt 3.1 Ist-Analyse beschrieben ist, zu minimieren. Um grob die Anforderungen aufzulisten, hier eine kurze Zusammenfassung. Vorab soll eine Anruferliste entstehen, welche alle Anrufe hierarchisch anzeigt. Bei einem eingehenden Anruf soll die anrufende Nummer mit denen im Kundendatenbestand abgeglichen werden, um so eventuell eine Zuordnung zwischen Anrufer und Kunde zu ermöglichen. Es soll eine neue Maske entstehen, welche relevante Daten zu diesem Kunden anzeigt. Sprich Personendaten, getätigte Buchungen etc. . Zusätzlich soll eine neue Notiz zu diesem Gespräch erfasst werden. Die Anforderungen werden noch im Zuge der Erstellung des Lastenheftes, siehe Abschnitt 3.3 Erstellung des Lastenheftes, in Zusammenarbeit mit den Stakeholdern genauer definiert werden.

3.3 Erstellung des Lastenheftes

Für die Gewährleistung der Vollständigkeit, entsprechend der Anforderungen der Stakeholder, mussten diese ein Lastenheft erstellen. Hierbei hat der Autor geholfen, so dass die Anforderungen vollumfänglich vorhanden und klar definiert sind. Ein Auszug aus diesem Lastenheft, welcher einen Teil der Anforderungen darstellt, befindet sich im Anhang A.4 Lastenheft (Auszug).

3.4 Wirtschaftlichkeitsanalyse

Mit Hilfe einer Analyse der Projektkosten und einer Amortisationsrechnung soll im Folgenden die Wirtschaftlichkeit der Umsetzung betrachtet werden.

3.4.1 „Make or Buy“ Entscheidung

Der Gegenstand des Projekts ist eine Modernisierung und Erweiterung eines bereits im System SYNCCESS® vorhandenen Moduls. Dadurch besteht keine Möglichkeit die speziellen Anforderungen an diese Implementierung bereits vorgefertigt von einem Drittanbieter zu erwerben. Zudem soll dieses Projekt nach seiner Entstehung stets weiterentwickelt werden, wodurch hier eine unerwünschte Abhängigkeit externer Unternehmen entstehen würde.

3.4.2 Projektkosten

Da die genauen Stundensätze nicht herausgegeben werden dürfen, finden in der folgenden Kalkulation frei erfundene Werte Anwendung. Diese inkludieren den Bruttostundenlohn zusammen mit den Sozialabgaben des Arbeitgebers. Für eine Stunde eines Auszubildenden werden 15€, für die eines

Mitarbeiters 30€ veranschlagt. Berücksichtigt werden neben der Aufwendung für das Personal ebenfalls die Ressourcenkosten, hier mit 10 € pauschalisiert. In Tabelle 2: Aufstellung der Projektkosten, sind die Gesamtkosten des Projekts in einzelne Faktoren, die jeweiligen Projektschritte, aufgeschlüsselt.

TAPI

© Maximilian Marvin XVI

Planungs- und Analysephase

Projektschritt Mitarbeiter Zeit Personal Ressourcen Gesamt Entwicklungskosten 1x Auszubildender 70 h 1.050,00 € 700,00 € 1.750,00 € Fachgespräch - Anforderungen

2 x Mitarbeiter 2 h 140,00 € 20,00 € 160,00 €

Code-Review 1 x Mitarbeiter 2 h 80,00 € 20,00 € 100,00 € Abnahme durch Auftraggeber

3 x Mitarbeiter 1 h 100,00 € 10,00 € 110,00 €

Projektkosten gesamt 2.120,00 € Tabelle 2: Aufstellung der Projektkosten

3.4.3 Amortisationsdauer

Nun wird ermittelt wie lange es dauert bis der Zeitpunkt der Amortisation erreicht wird. Dieser setzt sich in diesem Fall aus zwei einzelnen Faktoren zusammen. Zum einen hat man den Umsatz, welcher durch den Verkauf des Moduls an Neu- und Bestandskunden erzielt wird, und zum anderen zusätzlich noch die Zeitersparnis durch die interne Verwendung durch den Support.

Beim Verkauf des Moduls fallen verschiedene Gebühren an. Diese variieren je nach Kundenstatus. Folgend ist eine Kostenaufstellung, Tabelle 3: Beispielhafte Modulkosten, welche beispielhaft die Kosten bei Bestellung und erstmaliger Einrichtung des Moduls aufzeigt.

Aufgabe einmalige Kosten monatliche Kosten Ersteinrichtung und Bereitstellung an zwei Arbeitsplätzen

99,00 € -

Nutzungsgebühr pro Arbeitsplatz - 3,90 € einmalige Gesamtkosten 99,00 € Gesamt/Monat 3,90€

Tabelle 3: Beispielhafte Modulkosten

Zusätzlich fällt die manuelle Suche des Supports nach den Daten eines Anrufers weg. Die Zeiteinsparung durch den Wegfall dieses manuellen Prozesses wird in Tabelle 4: Zeiteinsparung dargestellt. Die Zeit pro Vorgang wurde von den Mitarbeitern des Supports geschätzt, da es hier keinen fixen Wert gibt. Da die Mitarbeiteranzahl sich stets verändern kann, basiert diese Tabelle auf dem Einsatz eines einzigen Mitarbeiters im Support der Z.I.E.L. GmbH.

Aktion Anzahl pro Tag Zeit(alt) pro Aktion

Zeit(neu) pro Aktion

Einsparung pro Arbeitstag

Daten eines Anrufers suchen ca. 40 1 Minute 0,1 Minute 36 Minuten

Zeiteinsparung pro Arbeitsjahr(220 Arbeitstage) 7920 Minuten Tabelle 4: Zeiteinsparung

TAPI

© Maximilian Marvin XVII

Planungs- und Analysephase + Entwurfsphase

7920𝑀𝑖𝑛𝑢𝑡𝑒𝑛

60= 132ℎ 𝐸𝑖𝑛𝑠𝑝𝑎𝑟𝑢𝑛𝑔 𝑝𝑟𝑜 𝐴𝑟𝑏𝑒𝑖𝑡𝑠𝑗𝑎ℎ𝑟

Diese Zeiteinsparung resultiert in einer jährlichen Kostenreduktion von

132ℎ ∗(30 + 10)€

ℎ= 5.280,00 €

Eine Analyse der bisherigen Verkäufe des Moduls TAPI sowie einer Einschätzung der Mitarbeiter im Vertrieb entsprechend ist davon auszugehen, dass im nächsten Jahr ungefähr 40 Module verkauft werden. Dies ist kein fixer Wert und stellt lediglich eine Prognose dar.

Wenn man im Laufe des nächsten Jahres von 40 Verkäufen ausgeht, ergeben sich folgende einmalige, garantierte Einnahmen:

99,00€ ∗ 40 = 3.960,00 €

Kombiniert man nun diese beiden Faktoren, ergibt sich im Laufe des nächsten Jahres eine Kostenreduktion von 9.240,00 €. Die jährlichen Wartungs- und Folgekosten der Entwicklung des Moduls werden nun mit 20% der Entwicklungskosten beziffert.

Die Amortisationszeit lässt sich somit wie folgt berechnen:

2.120,00€ + (2.120,00€ ∗ 0,2)

9.240,00 €/𝐽𝑎ℎ𝑟 ≈ 0,27 𝐽𝑎ℎ𝑟𝑒 ≈ 14 𝑊𝑜𝑐ℎ𝑒𝑛

3.4.4 nicht-monetäre Vorteile

Einer der positiven Aspekte, die die Durchführung dieses Projekts mit sich zieht, ist der gegenüber den Käufern und Anwendern des Moduls vermittelte Eindruck einer zukunfts- und kundenorientierten Entwicklung. Wie bereits in der Projektbegründung erwähnt, können sich die Kunden der Z.I.E.L. GmbH dadurch sicher sein, dass das System stets weiterentwickelt und im Sinne der Anwender selbst positiv verändert wird.

Einen ähnlichen Effekt wird diese Umsetzung auf die Mitarbeiter des Supports der Z.I.E.L. GmbH haben. Diese werden sehen, dass Ressourcen für die Erleichterung Ihres Arbeitsalltages aufgewendet werden.

4. Entwurfsphase

4.1 Zielplattform

Das Projekt soll die teilweise bereits vorhandene Implementierung des Moduls TAPI um neue Funktionalitäten erweitern, wie bereits im Projektziel beschrieben. Somit wird das Projekt in SYNCCESS® integriert und wird keine eigenständige Applikation.

TAPI

© Maximilian Marvin XVIII

Entwurfsphase

Da SYNCCESS® selbst in C# entwickelt wurde, wird dieses Projekt ebenfalls in C# realisiert. Für die Nutzung von SYNCCESS® wird jedem Kunden eine eigene Datenbank bereitgestellt. Für dieses Projekt wird auf eine bereits vorhandene Datenbank eines Test-Bestandes von SYNCCESS® zurückgegriffen.

SYNCCESS® ist ein Client/Server-basiertes System. Dies bedeutet, dass der Server dem Client Dienstleistungen und eine Schnittstelle zur Datenbank bereitstellt. Es findet eine strikte Trennung von Benutzeroberfläche, Anwendungslogik und Datenspeicherung statt.

Im Rahmen der Umsetzung des Projekts werden somit am Client, am Server sowie an der Datenbank, welche für jeden Kunden der Z.I.E.L. GmbH bei Vertragsabschluss angelegt wird, Änderungen durchgeführt.

Da SYNCCESS® nur für die Nutzung mit Windows ausgelegt ist, gibt es keinen Bedarf die Entwicklung auch für andere Betriebssysteme, z.B.: iOS von Apple, zu optimieren.

Die Datenbanken der Kunden wurden auf vier SQL-Server verteilt. Auf diesen Servern findet Microsofts SQL Server 2012 Anwendung.

4.2 Architekturdesign

Um die bereits erwähnte Trennung von Benutzeroberfläche, Anwendungslogik und Datenhaltung zu gewährleisten, wird die Entwicklung entsprechend dem Entwurfsmodel Model View Controller(MVC) stattfinden. Hier lässt sich die zu erstellende Anwendung, beziehungsweise die einzelnen Teile des zu erstellenden Moduls, in drei Komponenten einteilen. Jeder dieser drei Teile, Model, View und Controller, hat eine bestimmte Zuständigkeit. Die Datenhaltung sowie die Anwendungslogik werden hier nun dem Modell zugeordnet. Die View dient zur Darstellung der Daten und Oberflächen. Der Controller wird zur Verknüpfung von Model und View genutzt und steuert somit die Anwendung.

Diese Trennung erlaubt es die einzelnen Teile unabhängig voneinander zu entwickeln, zu ändern und zu verwenden. Ein Austausch der GUI würde somit keinen Einfluss auf die Datenhaltung oder der Anwendungslogik haben. Zudem wird es durch Einsatz dieser Architektur einfacher das Modul, beziehungsweise die einzelnen Bestandteile, zu testen. Auch die Möglichkeit diese nach Belieben anzupassen sowie zu warten ist hier gegeben.

Die GUI wird unter Verwendung von WPF erstellt. Eine so erstellte Benutzeroberfläche setzt sich aus zwei Teilen zusammen. Die visuellen Aspekte der GUI werden in Form von Extensible Application Markup Language(XAML) definiert, im so genannten Application Markup. Um das Verhalten der einzelnen Objekte der GUI bei einer Interaktion durch einen User festzulegen, gibt es zu jedem Application Markup den Code-Behind. In diesem Code wird definiert, wie sich z.B.: ein Button verhalten soll sobald der Nutzer der GUI diesen gedrückt hat.

Für die Anbindung der jeweiligen TK-Anlagen an SYNCCESS® wird eine Schnittstelle benötigt. Da die Entwicklung einer komplett neuen Schnittstelle den Rahmen dieses Projekts sprengen, und zudem bereits eine entsprechende Bibliothek in SYNCCESS® eingebunden ist, wird auf AddTapi.NET von Traysoft, wie bereits in den Schnittstellen des Projekts erwähnt, zurückgegriffen.

TAPI

© Maximilian Marvin XIX

Entwurfsphase

4.3 Benutzeroberflächen entwerfen

Vor allem im Bereich der Kommunikation ist es von äußerster Relevanz, dass die GUI intuitiv, flüssig und angenehm bedienbar ist. Sie sollte möglichst einfach strukturiert sein, so dass kein Anwender Schwierigkeiten hat sich zurecht zu finden. Hier finden nun so genannte Mock-Ups10 Anwendung.

Hier hat der Autor mit Hilfe von der Software Pencil Entwürfe der Oberflächen, zu finden im A.5 Oberflächenentwürfe, erstellt. Hier wurde nach jedem Entwurf das Feedback der Stakeholder eingeholt, so dass die Konzeption der GUI von Anfang an entsprechend der Vorstellungen und Wünsche dieser ist.

Wie bereits im Projektziel beschrieben, ist eines der Ziele eine Anruferliste. Diese Liste soll folgende Informationen darstellen:

Name des zugeordneten Kunden Kundennummer Kundenkategorie Rufnummer Spalte für einen Rückruf-Button den Status des Anrufs

o angenommen/nicht angenommen Gesprächsdauer in Minuten Datum des Anrufs angerufenen Expedient Anrufrichtung

o eingegangen/ausgegangen

Ein entsprechendes Mock-Up wurde vom Autor erstellt und anschließend zusammen mit den Stakeholdern begutachtet.

Zusätzlich soll eine neue Maske entstehen. Diese neue Maske soll die Kundendaten eines eventuell zugeordneten Kunden und dessen Warenkörbe anzeigen. Zusätzlich soll es die Möglichkeit geben, eine neue Notiz zu einem Anruf zu verfassen. Auch für diese Maske wurde ein Mock-Up angefertigt.

Um für eine optisch ansprechende und äußerst funktionale GUI zu sorgen, nutzt SYNCCESS® die von Telerik bereitgestellte Bibliothek UI for WPF. Auf diese Bibliotheken wird auch für die Oberflächen, die im Rahmen dieses Projekts erstellt werden, zurückgegriffen. Dadurch ist gewährleistet, dass das einheitliche Design des Gesamtsystems beibehalten wird.

4.4 Datenbankdesign konzipieren

Zur Darstellung des Datenmodells soll ein Entity Relationship Model (ERM) hergezogen werden. Um dieses abzubilden müssen entsprechende Entitäten, Attribute und Beziehungen zwischen den Objekten, die im Rahmen der Umsetzung dieses Projekts von Belang sind, erstellt werden.

10 Vgl. http://pencil.evolus.vn/

TAPI

© Maximilian Marvin XX

Entwurfsphase + Implementierungsphase

Zuerst gilt es diese Objekte zu identifizieren. Hierfür befindet sich im Anhang A.6 Analyse des Kommunikationsablaufs und herausfiltern der nötigen Entitäten eine Analyse des Ablaufs eines Gesprächs. Zusätzlich sind die hier nötigen Entitäten herausgefiltert und anschließend in einem ERM dargestellt, siehe Anhang A.7 Entity Relationship Model. Folgend sind die abzubildenden Objekte: Anrufer, Ereignis und EreignisZuordnung.

Um keinerlei Anomalien sowie eine effiziente und zielgerichtete Speicherung der Daten zu gewährleisten, hat sich der Autor dafür entschieden dieses Datenmodell in ein relationales Datenbankmodell zu überführen. Für diese Zwecke wurde das ERM in ein Tabellenmodell überführt, siehe Anhang A.8 Tabellenmodell.

Zusätzlich plant der Autor SQL-Prozeduren11 für die Suche nach Rufnummern sowie der Suche nach Ereignissen, da hier ja geplant ist die Ereignisse pro Benutzer anzeigen zu lassen. Hier würde eine SQL-Prozedur die Übergabe der Such-Parameter, sprich in diesem Fall die BenutzerDBOID, vereinfachen. Auch der Aufruf innerhalb der Geschäftslogik wird dadurch leichter, da es so nicht nötig ist die SQL-Befehle im Quellcode zu codieren. Dadurch werden ebenfalls Sicherheitsrisiken vermieden, welche dadurch entstehen könnten.

4.5 Planung der Geschäftslogik Für die Planung der Geschäftslogik kann teilweise die sich im Anhang A.3 EPK des Ist-Zustandes befindene EPK genutzt werden. Daraus lässt sich ableiten, dass für jeden Anruf, der rein- oder rauskommt, ein eigenes Objekt vom Typ Anrufer erstellt werden muss. Um Events, wie in etwa einen eingehenden Anruf oder beendeten Anruf, im System mitzubekommen, müssen diese von Event-Handlern abgefangen werden. Diese Anrufer -Objekte sollen anschließend direkt in der Anruferliste angezeigt werden. Durch die Frage des Expedienten nach der Kundennummer nach Gesprächsannahme wird klar ersichtlich, dass an dieser Stelle die Zuordnung zwischen Anrufer und eventuell vorhandenen Kundendatensatz stattfinden muss. Bei Gesprächsannahme soll nun das entsprechende Objekt an eine neue Instanz der Tapi-Maske übergeben werden. Mit diesem Objekt, und seinem Verweis auf einen eventuell vorhandenen Kunden zu der anrufenden Nummer, können dann dessen Daten übersichtlich und strukturiert in der Tapi-Maske angezeigt werden. Nun gilt es natürlich zu beobachten ob der Anruf beendet wird. Sobald das der Fall ist, werden das Anrufer –Objekt sowie das entstandene Ereignis abgespeichert.

11 Vgl.Microsoft Corporation 2015

TAPI

© Maximilian Marvin XXI

Implementierungsphase

4.6 Pflichtenheft Die Entwurfsphase wird mit einem zu erstellenden Pflichtenheft beendet. Das Pflichtenheft setzt sich aus dem Lastenheft, siehe A.4 Lastenheft (Auszug), und der geplanten Umsetzung gemäß der Anforderungen, des Autors zusammen. Es soll somit eine bei der Entwicklung unterstützende Position in Form eines roten Fadens darstellen. Ein Auszug aus dem Pflichtenheft befindet sich im Anhang A.9 Pflichtenheft(Auszug).

5. Implementierungsphase 5.1 Iterationsplanung In Abschnitt 2.4 Entwicklungsprozess hat sich der Autor für eine agile Vorgehensweise bei der Projektdurchführung entschieden. Um ein iteratives Durchlaufen der einzelnen Projektphasen zu ermöglichen und zu unterstützen wurde ein Iterationsplan erstellt. Dieser zeigt anhand einer Auflistung der einzelnen Schritte in deren korrekter Reihenfolge auf, welche Aufgaben in welcher Reihenfolge zu erledigen sind. Zu finden ist der Iterationsplan im Anhang A.11 Iterationsplan.

5.2 Benutzeroberflächen erstellen Da hier das Prinzip von MVC Anwendung finden soll, hat sich der Autor dafür entschieden mit der Erstellung der Benutzeroberflächen anzufangen. Hier wurde mit Hilfe von WPF sowie zusätzlichen Grafikelementen von Telerik, gebündelt in der Bibliothek UI for WPF, entwickelt. Die Funktionalität der einzelnen Bestandteile der GUI wurde im Code-Behind definiert. In diesem wurden ebenso sämtliche Hilfsmethoden, wie in etwa Methoden für die Bereitstellung der Kundendaten, definiert und den einzelnen Elementen zugeordnet. Um das Design in seiner Gesamtheit an das Design des Gesamtsystems, SYNCCESS®, anzupassen, wurde z.B.: das Element „RadGridView“ genutzt. Dabei handelt es sich um ein Steuerelement zur Anzeige von Daten in Tabellenform. WPF selbst bietet bereits solche Elemente, da aber diese optisch in Ihrer Einstellungsmöglichkeit beschränkt sind, wird hier auf das Ausweichelement von Telerik zurückgegriffen. Im Anhang A.13 Listing – RadGridView befindet sich ein solches „RadGridView“ als Beispiel. Es unterscheidet sich vom Grundaufbau nicht groß von dem eines normalen Grids, weshalb die Bezeichnungen selbsterklärend sind.

Screenshots der fertigen Oberflächen befindet sich im Anhang A.12 Screenshots der Oberflächen.

5.3 Datenbankdesign realisieren

Mit Hilfe des sich Im Anhang A.8 Tabellenmodell befindlichen Modells wurden die entsprechenden Tabellen angelegt. Hierfür wurden die benötigten SQL-Befehle für die Erstellung der Tabellen manuell vom Autor geschrieben und anschließend ausgeführt. Da dieses Projekt nicht sofort in das Live-System übernommen wird, wurden diese Tabellen vorerst lediglich in einer Test-Datenbank erstellt. Bei späterem Release in das Live-System werden diese Tabellen in allen sich auf den SQL-Servern befindenden Kundendatenbanken erstellt. Die benötigten Tabellen für den Rahmen dieses Projekts sind somit erstellt und stehen für die Nutzung gemäß der Anforderungen bereit.

Da ein Expedient ja in der Lage sein sollte die Ereignisse zu sehen, die nur er erstellt hat, gibt es hier die Herausforderung möglichst sinnvoll diese Selektion umzusetzen. Auf Grund der in 4.4 Datenbankdesign konzipieren genannten Vorteile hat sich der Autor vorher dafür entschieden SQL-

TAPI

© Maximilian Marvin XXII

Implementierungsphase

Prozeduren zu entwickeln. Eine Prozedur dient dazu immer wiederkehrende Aufgaben und Arbeiten direkt innerhalb von einer Datenbank auszuführen. Um zu verdeutlichen wie eine Prozedur entsteht, diese aufgebaut ist und letztendlich aufgerufen wird, ist im Anhang A.10 SQL-Prozedur „SucheEreignisse“ die Prozedur für die Suche nach Ereignissen als Beispiel erläutert.

5.4 Geschäftslogik umsetzen Die Implementierung der Geschäftslogik stellt den größten Entwicklungsaufwand dar und muss daher sehr gut durchdacht und möglichst effizient durchgeführt werden.

Zuerst mussten die entsprechenden Klassen gemäß Anhang A.8 Tabellenmodell erstellt werden. Zwei Beispiele befinden sich im Anhang A.14 – Listings der Kern-Klassen.

Im Anschluss daran wurde die Zusatzklassen erstellt, so dass die Ergebnisse der noch zu erstellenden Methoden „Anrufersuche“ und „SucheEreignisse“ direkt in eine Liste gespeichert und in einem Grid angezeigt werden können. Hier wurden die Klasse Anrufer und Ereignis um einige Eigenschaften erweitert, zum Beispiel mit den Kundendaten. Zusätzlich wurde für diese Klassen jeweils ein Konstruktor so angelegt, dass das Ergebnis der entsprechenden Methode direkt in eine Liste vom Typ dieser neuen Klasse umgewandelt werden kann. Der Aufbau der neuen Klassen AnrufersucheZeile und EreignissucheZeile befindet sich im Anhang A.15 Listings – Klassen „AnrufersucheZeile“ und „EreignissucheZeile“.

Nachdem nun die Klasse für das Ergebnis der Methode erstellt ist, gilt es die Methoden selbst zu definieren. Hier wurde mit der Methode AnruferSuche begonnen. Die Implementierung der Methode befindet sich im Anhang A.16 Listing – Methode „AnruferSuche“. Hier wurde vorerst auf die Erstellung einer SQL-Prozedur verzichtet, was aber im Laufe der Weiterentwicklung des Projekts definitiv geplant ist. Diese Methode wird in der Anruferliste aufgerufen und dient dazu die bisher getätigten Gespräche hierarchisch anzeigen zu lassen.

Der nächste Schritt involviert die Implementierung der Methode SucheEreignisse. Hier konnte nun direkt auf die vorher bereits erstellte SQL-Prozedur „SucheEreignisse“, siehe Anhang A.10 SQL-Prozedur „SucheEreignisse“, zugegriffen werden. Lediglich die Parameter werden noch Serverseitig definiert und an die Prozedur übergeben. Der Zugriff auf die Prozedur erfolgt über die Klasse SyncessDB. Hier kann auch direkt die Datenbank angesprochen werden, auf die der aktuell angemeldetete Benutzer gerade zugreift. Diese Information wird in der im Listing, siehe Anhang A.17 Listing - Methode „SucheEreignisse“, zu sehenden Eigenschaft SyncessDB.Current gespeichert.

Nachdem man die aktuelle Datenbank über diese Eigenschaft anspricht, kann man auf hier nun auf die Methode AnfrageDT zugreifen, welche letztendlich eine DataTable mit den Ergebnissen der SQL-Prozedur zurückgibt. Diese Methode ruft die Prozedur selbstständig auf und speichert die Ergebnisse. Der Autor hat auf diese DataTable zugegriffen und diese zu einem Array vom Typ EreignissucheZeile umgewandelt. Dies geschieht ähnlich wie bei der Methode AnruferSuche.

Nachdem nun ein guter Teil der Datenmodellierung und Geschäftslogik implementiert ist, geht es darum die Informationen, die die Schnittstelle zu der jeweiligen TK-Anlage liefert, auszuwerten und weiterzuvearbeiten. Dies geschieht über entsprechende Event-Handler. So gilt es zum Beispiel ein Event abzufeuern wenn ein Anruf z.B.: reinkommt, rausgeht, angenommen, abgelehnt oder beendet wird. Bei solchen Aktionen feuert der TAPI-Treiber der TK-Anlage ein Event, welches die AddTapi.NET Schnittstelle letztendlich abfängt und für die Weiterverarbeitung bereitstellt. Um auf diese Events zuzugreifen, muss ein Objekt der Klasse TapiService verwendet werden. Anschließend erstellt man

TAPI

© Maximilian Marvin XXIII

Implementierungsphase + Qualitätsmanagement

die Event-Handler und weist diese dem TapiService zu. Dadurch weiß dieser, dass z.B. bei einem eingehenden Anruf das entsprechende Event gefeuert werden muss.

Zuerst gilt es überhaupt etwas zu tun sobald ein Anruf reinkommt. Hierfür wurde ein Event-Handler entwickelt, welcher ein neues Objekt vom Typ Anrufer erstellt und anschließend die Anruferliste öffnet. Hier wird sofort ein neuer Eintrag oben angefügt, welcher initial erst einmal die bereits bekannten Informationen zu dem Anruf anzeigt. Dazu zählen unter anderem die Nummer, die

Anrufrichtung, der angerufene Expedient sowie die Uhrzeit des Gesprächbeginns. Im Anhang A.18 Listings – Event-Handler der TAPI-Schnittstelle(Auszug) befindet sich ein Auszug der entwickelten Event-Handler. Zusätzlich zu den dort aufgezeigten Event-Handlern wurden folgende Event-Handler implementiert: AusgehenderAnrufEvent, AusgehenderAnrufVerbunden, AnrufGehalten.

Für jeden Anruf, egal ob ausgehend oder eingehend, wird in der Anruferliste ein neues Objekt vom Typ AnrufersucheZeile erstellt. Dieses Objekt wird bei Gesprächsannahme direkt an eine neue Instanz der Tapi-Maske weitergegeben, so dass dort die benötigten Informationen für die Suche nach einem eventuell vorhandenen Kunden zur Verfügung stehen.

Der nächste Schritt ist somit die Implementierung der Zuordnung zwischen Anrufer und einem eventuell dazu passenden Kundendatensatz. Das erfolgt im Code-Behind der Tapi-Maske. Um diese eventuell stattfindende Zuordnung zu ermöglichen, muss auf die im Abschnitt 1.6 Projektabgrenzung erwähnte SQL-Prozedur „Rufnummernsuche“ zugegriffen werden. Um das zu realisieren wurde am Server von SYNCCESS® eine neue Methode erstellt, welche nach der Übgabe einer Telefonnummer die Datenbank, um genauer zu sein sämtliche gespeicherte Kontakte, nach einer Übereinstimmung mit dieser Telefonnummer durchsucht. Mit Hilfe des an die Tapi-Maske übergebenen Objekts kann nun nach einem Match gesucht werden. Im Anhang A.18 Listing – Anrufer-Kunde Zuordnung befindet sich dieser entsprechende Programmteil. Wie man dort erkennen kann, wird über einen DataService die zuvor neu am Server erstellte Methode aufgerufen. Ebenfalls zu erkennen ist, dass hier asynchrone Programmierung vom Autor eingesetzt wurde. Da das Durchsuchen eines gesamten Kundendatenbestandes durchaus einige Sekunden dauern kann, da teilweise mehr als 50.000 Nummern hinterlegt sind, muss hier gewährleistet sein, dass die Oberfläche weiterhin nutzbar ist und das Programm sich auf Grund der Wartezeit bis zur Antwort vom Server nicht aufhängt.

Im letzten Schritt der Implementierung der Geschäftslogik werden die Methoden implementiert, welche die eventuell vorhandenen Daten bei einer erfolgreichen Zuordnung zwischen einem Anrufer und einem Kundendatensatz bereitstellen. Diese werden im Code-Behind der vorher erstellten Tapi-Maske definiert. Um diese eventuell stattfindende Zuordnung zu ermöglichen, muss auf die im Abschnitt 1.6 Projektabgrenzung erwähnte SQL-Prozedur „Rufnummernsuche“ zugegriffen werden. Das Ergebnis dieser Methode beinhaltet unter anderem einen Verweis auf den gefundenen Kontakt. Über diesen Verweis können anschließend die Daten zu diesem Kunden geladen werden. Im Anhang A.19 Listings - Methoden der Tapi-Maske(Auszug) befindet sich ein Auszug der in diesem Rahmen implementierten Methoden.

6. Qualitätsmanagement In diesem Abschnitt soll es nun darum gehen die im Rahmen dieses Projekts entstandenen Entwicklungen zu testen, mit dem Entwicklungsleiter der Z.I.E.L. GmbH gemeinsam zu bewerten und diese anschließend daran in eine Testversion von SYNCCESS® zu integrieren.

TAPI

© Maximilian Marvin XXIV

Qualitätsmanagement

6.1 Sammeln von möglichen Testfällen und Situationen 6.1.1 Vorbereitungen und Entscheidung bezüglich des Testverfahrens Vorab musste sich der Autor entscheiden, wie die Anwendung getestet werden soll. Hier gibt es nun verschiedene Varianten, unter anderem Komponententests. Hier wird die Funktionalität des Programms in einzelne, testfähige Verhalten gegliedert.12

Da es in diesem Fall schwierig wäre, die gesamte Funktionalität zu gliedern, hat sich der Autor für ein empirisches Testverfahren entschieden. Empirie bezeichnet die Sammlung von Erkenntnissen auf Grundlage von gemachten Erfahrungen.13 Das bedeutet, dass jede Funktion der Anwendung aus der Praxis heraus getestet wird. Um in diesem Projekt danach zu agieren, hat der Autor eine so genannte Softphone-Applikation14 und eine externe TK-Anlage, die bereits an seinem Arbeitsplatz vorhanden war, hergezogen. Eine Softphone-Applikation ermöglicht die Nutzung von Voice-Over-IP-Telefonie, ohne direkt ein IP-Telefon physikalisch nutzen zu müssen. Hier wurde nun über das firmeninterne Telefon-Netzwerk der Z.I.E.L. GmbH eine neue Leitung für die Nutzung durch die Softphone-Applikation erstellt. Dadurch stehen dem Autor somit zwei funktionsfähige TK-Anlagen bereit. Die Leitung, die das Softphone nutzt, wurde anschließend in der Administration in SYNCCESS® hinterlegt. Im Anhang A.21 Hinterlegung der TAPI-Leitung in der Administration von SYNCCESS® ist diese Möglichkeit der Einstellung zu betrachten.

6.1.2 Sammeln von Testfällen- und Situationen

Nun gilt es mögliche Testfälle und Situationen zu sammeln. Hier wurde in einem Fachgespräch mit einem Mitarbeiter des Supports der Z.I.E.L. GmbH zusammen erörtert, was für Fälle eintreten können.

Zuerst gilt es noch zu erwähnen, dass es allgemeingültiges Verhalten gibt. Das heißt, dass ein paar Effekte unabhängig von dem einzelnen Testfall gegeben sein sollen. Das wären folgende Punkte:

Eintrag in der Anruferliste bei jedem Anruf Für jedes Gespräch soll eine Notiz erfasst werden können Jedes Gespräch muss vom System erkannt werden

[…]

Hier nun die gesammelten Testfälle, welche die Kernfunktionalität der Entwicklungen prüfen:

1. Anrufer ist bereits im System als Kunde gespeichert -> Zuordnung sowie Darstellung der bereits vorhandenen Kundendaten muss erfolgen

2. Anrufer ist noch nicht im System als Kunde gespeichert -> Tapi-Maske muss trotzdem aufgehen, aber soll keinerlei Daten anzeigen und nur die Möglichkeit geben, eine Notiz zu erfassen

3. Eingehender Anruf wird abgelehnt, somit soll keine Tapi-Maske aufgehen, aber ein Eintrag in der Anruferliste

12 Vgl. Microsoft Corporation 2016

13 Vgl. Universität Augsburg 2017

14 Vgl. Deutsche Telefon Standard AG: https://www.deutsche-telefon.de/telefone/power-fon.html

TAPI

© Maximilian Marvin XXV

Qualitätsmanagement

4. Eingehender Anruf wird angenommen und im späteren Verlauf über den entsprechenden Button in der Maske beendet

Dabei handelt es sich nun um die Kernfunktionalitäten der Entwicklung, weshalb diese Testfälle erste Priorität haben. Nachdem diese erfolgreich abgeschlossen wurden, können weitere Tests für die Weiterentwicklung dieses Projekts geplant werden.

6.2 Testfälle gemäß gesammelter Infos erstellt und durchgeführt

Die Tests werden nun gemäß der Testfälle durchgeführt. Hierfür wird der Autor die in SYNCCESS® hinterlegte Leitung über sein eigenes Telefon an seinem Arbeitsplatz anrufen. Bei Tests, die eine gespeicherte Nummer voraussetzen, wird die Nummer des Telefons vom Autor in einem Testkunden hinterlegt, so dass hier eine Zuordnung stattfinden kann.

1. Testfall -> Erfolgreich Hier gab es keinerlei Probleme, so dass diese Funktionalität gewährleistet ist.

2. Testfall -> Erfolgreich Auch hier hat die gründliche Planung Fehler verhindert.

3. Testfall -> Erfolgreich Der Anruf wurde abgelehnt, aber ein Eintrag erschien in der Anruferliste, somit erfolgreich.

4. Testfall -> Nicht erfolgreich Der Anruf wurde zwar entsprechend beendet, der Button blieb aber weiterhin aktiv. Dadurch könnten Anwender Fehler durch erneutes Klicken verursachen.

Dieser Test wurden in der Form ein zweites Mal von einem anderen Entwickler der Z.I.E.L. GmbH durchgeführt, um zu gewährleisten dass die Ergebnisse dieser Tests als Grundlage für die Fehlerbehebung genutzt werden können. Das Ergebnis der zweiten Durchführung des Tests ist identisch mit dem Ergebnis der Tests durchgeführt durch den Autor. Somit kann nun die Fehlerbehebung durchgeführt werden.

6.3 Fehlerbehebung

Nachdem nun eine Grundlage für die Behebung dieser Fehler besteht, können diese lokalisiert und behoben werden. Um die fehlende Deaktivierung des Buttons nach dem Ende eines Gesprächs zu realisieren, hat sich der Autor dazu entschieden, das über den XAML-Code der Tapi-Maske zu lösen. Hier würde sich der Einsatz eines DataTriggers anbieten. Ein DataTrigger überwacht den Status eines an ihn gebundenen Objekts, so dass je nach Status von diesem Objekt das Verhalten des GUI-Elements, dem der DataTrigger zugeordnet ist, angepasst werden kann. Im Anhang A.21 Listing – XAML-Code des „Speichern und auflegen“-Button ist der angepasste Button zu sehen.

TAPI

© Maximilian Marvin XXVI

Qualitätsmanagement + Dokumentation

6.4 Code-Review mit dem Entwicklungsleiter

Nachdem nun die Implementierung sowie die nötige Funktionalität durch Tests nachgewiesen wurde, folgt nun ein Code-Review mit dem Entwicklungsleiter der Z.I.E.L. GmbH. Hierbei wurde der vom Autor geschriebene Code auf diverse Faktoren geprüft, unter anderem der Wartbarkeit, Effizienz und Lesbarkeit. Viel Wert wird vor allem auf den letzten Punkt gelegt, weshalb hier nachträglich noch Anpassungen vollzogen wurden. Ein Beispiel wäre die Auflistung der im XAML-Code festgelegten Eigenschaften. Diese wurden bisher vom Autor in einer Zeile aneinander geschrieben. Nun wurden diese jedoch in Zeilen aufgeteilt, so dass diese leserlicher sind. Ein Vorher-Nachher Beispiel befindet sich im Anhang A.23 Listing – Beispielkorrektur des XAML-Code.

6.4.1 Erstellen einer Testversion von SYNCCESS®

Nun werden die durchgeführten Änderungen in eine Testversion von SYNCCESS® implementiert. Diese Testversion wird anschließend den Stakeholdern des Projekts zur Verfügung gestellt. Nachdem diese die Anwendung ausgiebig getestet und für gut befinden, werden diese Änderungen in das Produktivsystem übernommen und damit an die Kunden rausgespielt.

Zuerst musste der Autor die Build-Einstellung seiner Entwicklungsumgebung, Visual Studio 2012 Premium, von „Debug“ auf „Release“ umstellen. Diese Umstellung erfolgte jeweils am Client und am Server von SYNCCESS®. Nach dieser Umstellung musste die Version der Anwendung angepasst werden. Dies geschieht manuell in der sog. „GlobalAssemblyInfo.cs“. Im Anhang A.24 Listing – GlobalAssemblyInfo ist der Aufbau dieser Klasse zu sehen. Dort wird ersichtlich, wie die Versionierung der Software erfolgt. Da neue Versionen von SYNCCESS® stets von einer einzigen Person, welche die Änderungen aller Entwickler über einen Team-Foundation-Server(TFS) zusammenträgt und verbindet, erstellt werden, ist der manuelle Aufwand somit überschaubar.

Nach der Anpassung dieser Klasse mussten der Client und der Server neu erstellt werden. SYNCCESS® hat ein eigenständiges Setup. Dieses Setup muss nach erfolgreicher Erstellung des Clients und des Servers ebenfalls neu erstellt werden. Dadurch entsteht das neue Setup, welches die durchgeführten Änderungen inkludiert und den Stakeholdern somit bereitgestellt werden kann.

7. Erstellen der Dokumentationen Die gesamte Dokumentation setzt sich aus vier einzelnen Dokumenten zusammen. Diese Dokumentationen werden nun einzeln erläutert.

7.1 Projektdokumentation Die Projektdokumentation beschreibt die gesamte Planung und Umsetzung des Projekts. Sie wurde während der gesamten Bearbeitungszeit angefertigt.

TAPI

© Maximilian Marvin XXVII

Dokumentation + Projektbewertung

7.2 Entwicklerdokumentation Die Entwicklerdokumentation soll anderen Entwicklern, die an diesem Projekt arbeiten, einige Erklärungen bieten, so dass der Einstieg und die Einarbeitung in das Projekt nicht so umständlich werden. Die Entwicklerdokumentation findet direkt im Quellcode, in Form von Kommentaren statt. Durchgeführt wurde diese nach Abschluss der Implementierung. Dadurch erhält der Autor einen Gesamtüberblick über die Entwicklung. Im Anhang A.24 Entwicklerdokumentation(Auszug) befindet sich ein Auszug daraus.

7.3 Anwenderdokumentation Die Anwenderdokumentation soll den Benutzern des Moduls eine Möglichkeit bieten, eventuelle Fragen so direkt prüfen zu können. Sie soll einen Überblick über die Funktionalität bieten und ein Anhaltspunkt sein. Ein Auszug daraus befindet sich im Anhang A.25 Anwenderdokumentation(Auszug).

7.4 Fehlerdokumentation Die Fehlerdokumentation dient der Dokumentation der bisher vorhandenen Fehler im System, so dass hier eine Übersicht vorhanden ist und man bei eventuell auftretenden Problemen einen Anhaltspunkt hat. Ein Auszug daraus befindet sich im Anhang A.26 Fehlerdokumentation(Auszug).

8. Projektbewertung

8.1 Fazit Die Gesamtzeit von 70 Stunden wurde exakt eingehalten, ein paar Punkte wiesen jedoch Abweichungen vom geplanten Zeitaufwand auf. Dazu zählt unter anderem die Punkte 6.3 Fehlerbehebung und 6.4 Code-Review mit dem Entwicklungsleiter. Hier waren für Punkt eins drei Stunden und für den zweiten Punkt zwei Stunden geplant. Nachdem nur ein kleiner Fehler aufgetreten ist, konnte die Fehlerbehebung in einer Stunde durchgeführt werden. Das Code-Review liegt mit einer und einer halben Stunde ebenfalls leicht unter dem geschätzten Zeitaufwand. Die hier gesparte Zeit wurde an anderer Stelle eingesetzt. Die Projektdokumentation hat die restlichen zweieinhalb Stunden verzehrt, womit diese insgesamt bei neuneinhalb Stunden liegt.

8.2 Ausblick Alle Anforderungen konnten realisiert und zur Zufriedenheit der Stakeholder des Projekts umgesetzt werden. Durch dieses Projekt wurde ein Grundstein für die stetige Weiterentwicklung, Verbesserung und Optimierung der Kommunikation über SYNCCESS® gelegt. Es gab bereits erste Wünsche die im Rahmen dieses Projekts entstandenen Ereignisse an anderer Stelle zu nutzen. Zudem sollen, wie bereits im Abschnitt 1.2 Projektziel erwähnt, Auswertungen über zum Beispiel die monatliche Gesprächszeit eines Expedienten, entwickelt werden.

TAPI

© Maximilian Marvin XXVIII

Literaturverzeichnis

Literaturverzeichnis

Microsoft Corporation 2015

MICROSOFT CORPORATION: Erstellen einer gespeicherten Prozedur https://msdn.microsoft.com/de-de/library/ms345415.aspx Version: 2016 und später

Microsoft Corporation 2016

MICROSOFT CORPORATION: Grundlagen zum Komponententest https://msdn.microsoft.com/de-de/library/hh694602.aspx Version: 2015 und später

Universität Augsburg 2017

UNIVERSITÄT AUGSBURG: Der Empiriebegriff http://qsf.e-learning.imb-uni-augsburg.de/node/505

TAPI

© Maximilian Marvin XXIX

A Anhang

A Anhang

A.1 Detaillierte Zeitplanung

Planungs- und Analysephase 7h Ist-Analyse(Fachgespräche, Use-Case-Diagramm, EPK) 1h Soll-Konzept 2h Erstellung des Lastenheftes (unterstützende Tätigkeit) 2h Wirtschaftlichkeitsanalyse sowie Amortisationsrechnung 2h Entwurfsphase 14h Benutzeroberflächen entwerfen 4h Datenbankdesign konzipieren(ERM, Relationenmodell) 6h Planung der Geschäftslogik (Entscheidungstabelle) 4h Implementierungsphase 25h Benutzeroberflächen erstellen 6h Datenbankdesign realisieren 4h Geschäftslogik umsetzen 15h Qualitätsmanagement 10h Sammeln von möglichen Testfällen und Situationen 3h Testfälle gemäß gesammelten Infos erstellt und durchgeführt 2h Fehlerbehebungen 3h Code-Review mit dem Entwicklungsleiter 2h Erstellen der Dokumentationen 13h Projektdokumentation 7h Entwicklerdokumentation 2h Anwenderdokumentation 2h Fehlerdokumentation 2h Projektbewertung 1h Fazit 1/2h Ausblick 1/2h Gesamt 70h

TAPI

© Maximilian Marvin XXX

A Anhang

A.2 Verwendete Ressourcen

Hardware

Büroarbeitsplatz o Thin-Client o Tastatur o Maus o Zweiter Monitor o Telekommunikationsanlage

Software

Internet Explorer 7.0 – Web Browser für Darstellung der in ASP.NET entwickelten Websites Visual Studio Premium 2012, Version 11.0.61219.00 Update 5 – Entwicklungsumgebung C# Pencil, Version 2.0.5 – Software zur Erstellung von Mock-Ups Microsoft SQL Server Management Studio , Version 11.0.6020 – Datenbankverwaltung Microsoft Office Word 2013, Version 15.0.4893.1000 – Erstellung der Dokumentationen Microsoft Office Excel 2013, Version 15.0.4885.1000 – Anfertigung von Tabellen Programmbibliothek „AddTapi.NET“ von Traysoft, Version 5.1.0.41119 – Schnittstelle zu TK-Anlage Programmbibliothek „UI for WPF“ von Telerik1, Version 2016.1.217.40 – GUI Erweiterungen Power-FON, Version 2.4.3 – Softphone-Applikation der Deutsche Telefon Standard AG für Tests ARIS Express, Version 2.4c – Erstellung von Diagrammen(EPK) Enterprise Architect, Version 13.0.1310 – Erstellung von Modellen und Diagrammen

Personal

Führungsebene des Unternehmens – Anforderungsanalyse und Projektabnahme Auszubildender(Autor) – Umsetzung des Projekts Entwickler – Tests Entwicklungsleiter – Review des Codes Mitarbeiter des Supports – Unterstützung bei der Anforderungsanalyse

TAPI

© Maximilian Marvin XXXI

A Anhang

A.3 EPK des Ist-Zustandes

Abbildung 3: EPK des Ist-Zustandes

TAPI

© Maximilian Marvin XXXII

A Anhang

A.4 Lastenheft (Auszug)

In Zusammenarbeit mit den Stakeholdern wurde ein Lastenheft erstellt. Folgend ist ein Auszug aus diesem, welches die Anforderungen an die Umsetzung definieren.

Anforderungen

Folgende Anforderungen gilt es zu berücksichtigen:

Automatische Zuordnung von Anrufer und insofern vorhanden Kundendatensätzen sowie dazu gehörigen Vorgängen

Anruferliste, welche Anrufe eines vorher definierten Zeitraums hierarchisch darstellt Darstellung der getätigten Zuordnungen in einer neuen, einzelnen Maske

o Personendaten o Warenkörbe o Falls der Ansprechpartner ein anderer ist als der Kunde, bei dem diese Nummer

hinterlegt ist, die Personendaten von diesem Protokollierung der Informationen zu dem Gespräch

o Telefonnummer des Anrufers sowie Telefonnummer, die angerufen wurde o Status des Anrufes

Angenommen/nicht angenommen o Zeitliche Informationen zum Gespräch

Start- und Endzeit Möglichkeit parallel zur Darstellung der anderen Daten eine neue Notiz zu diesem Gespräch

zu erfassen o Anzeige der bereits erstellten Notizen zu einem Kunden

[…]

TAPI

© Maximilian Marvin XXXIII

A Anhang

A.5 Oberflächenentwürfe

Abbildung 4: Mock-Up der Anruferliste

Abbildung 5: Mock-Up der neuen TAPI-Maske

TAPI

© Maximilian Marvin XXXIV

A Anhang

A.6 Analyse des Kommunikationsablaufs und herausfiltern der nötigen Entitäten

Bei einem eingehenden beziehungsweise ausgehenden Anruf sollen zuerst die zu diesem Moment bekannten Informationen abgespeichert werden. Hier muss die initiale Speicherung direkt bei Eingang oder Ausgang des Anrufs geschehen, da nur so sichergestellt ist dass jedes Gespräch erfasst wird. Für diesen Zweck soll die Entität Anrufer dienen. Hier werden diverse Informationen zu den Gesprächen gespeichert.

Nun soll der Expedient die Möglichkeit haben eine neue Notiz zu diesem Gespräch digital zu erfassen. Die Speicherung dieser Notiz soll zum einen automatisch bei Gesprächsende, sowie manuell durch den Expedienten erfolgen. Da im Verlauf der Weiterentwicklung des Moduls, siehe 8.2 Ausblick, weitere Kommunikationskanäle protokolliert und gebündelt gespeichert werden sollen, hat der Autor hier eine neutrale Bezeichnung für die Entität gewählt, Ereignis. Dadurch ist die Wiederverwendbarkeit dieser Entität gewährleistet, so dass insgesamt gesehen der Entwicklungsaufwand minimiert werden kann.

Wie man im ERM erkennen kann werden einige Informationen zu dem Ereignis abgespeichert. Vorab ist natürlich der Text dazu relevant. Zudem werden hier durch Von und Bis die genauen Zeitpunkte des Ereignisses abgespeichert.

Zu einem Ereignis kann man, siehe A.5 Oberflächenentwürfe, eine Verknüpfung zwischen dem Ereignis selbst und einem anderen Objekt, in diesem Fall einem Warenkorb, hergestellt werden. Da es nötig sein wird hier die Referenzen auf diese Objekte abzuspeichern, wird eine entsprechende Entität erstellt. Diese Verknüpfung soll für die im Verlauf der Weiterentwicklung dieses Projekts entstehenden Auswertungen dienen. Für die Speicherung dieser Information dient die Entität EreignisZuordnung. Die DBObjektDBOID wird hier dann der Verweis auf das verknüpfte Objekt sein. Auch diese Bezeichnung wurde allgemein und neutral vergeben, so dass man hier erneut die Gewährleistung der Wiederverwendbarkeit erreicht.

TAPI

© Maximilian Marvin XXXV

A Anhang

A.7 Entity Relationship Modell

Abbildung 6: Entity Relationship Modell

TAPI

© Maximilian Marvin XXXVI

A Anhang

A.8 Tabellenmodell

TAPI

© Maximilian Marvin XXXVII

A Anhang

A.9 Pflichtenheft(Auszug)

Dieser Auszug aus dem Pflichtenheft soll zeigen wie der Autor die Umsetzung der im Lastenheft definierten Anforderungen plant:

Umsetzung der Anforderungen

Die automatische Zuordnung zwischen Anrufer und, falls vorhanden, einem Kunden soll mit Hilfe einer Rufnummernsuche-Prozedur in der Datenbank realisiert werden.

Unter Verwendung von WPF in Verbindung mit den erweiterten und zusätzlichen Grafikelementen von Teleriks UI for WPF wird eine Anruferliste erstellt. Ein entsprechendes Mock-Up, siehe A.5 Oberflächenentwürfe, wird als Grundlage für diese Maske dienen.

Sobald einem Anrufer ein Kunde zugeordnet werden konnte, werden die Daten von diesem Kunden zusammen mit einem neuen Notizfenster, seinen Warenkörben sowie den Ereignissen in einer Maske angezeigt. Auch hier wird ein Mock-Up, siehe Anhang A.5 Oberflächenentwürfe, als Grundlage dienen. Auch dieser Teil wird mit WPF und den Elementen von Teleriks UI for WPF entwickelt.

Die Protokollierung der Gesprächsinformationen erfolgt über eine entsprechende Speicherung in der Datenbank. Als Grundlage für ein Datenmodell dient der Anhang A.8 Tabellenmodell.

Es wird möglich sein die neue Notiz direkt in der Tapi-Maske anzufertigen. Diese Notiz wird allgemeingültig als Ereignis abgespeichert. Diese Ereignisse können anschließend pro Expedient beziehungsweise insgesamt ausgegeben und angezeigt werden.

TAPI

© Maximilian Marvin XXXVIII

A Anhang

A.10 SQL-Prozedur „SucheEreignisse“

Wie bereits in Abschnitt 4.4 Datenbankdesign konzipieren beschrieben, zieht die Nutzung von SQL-Prozeduren einige Vorteile mit sich. Unter anderem müssen die benötigten SQL-Befehle so nicht mehr im Quellcode der Anwendung selbst, in diesem Fall dem Server von SYNCCESS®, vorhanden sein. Die Prozedur kann relativ simpel über ihren Namen direkt aus der Anwendung heraus aufgerufen werden. Dabei können direkt die benötigten Parameter übergeben werden. Folgend ist nun die gesamte Prozedur „SucheEreignisse“, welche die Ereignisse eines einzelnen Expedienten, oder allen, zurückgibt. Zusätzlich ist es möglich hier in den Ereignissen nach einem Text zu suchen oder auch nur die Ereignisse zurückzugeben, die bereits als erledigt markiert wurden. Hier nun der Aufbau inklusive Erläuterungen:

USE [KN14023_2] /*Auswahl der Datenbank - Test-Datenbank für erste Tests*/ GO /*GO dient dazu einzelne SQL-Batches voneinander zu trennen.*/ SET ANSI_NULLS ON /*Sorgt dafür dass jeder NULL-Vergleich eine 0 zurückgibt.*/ GO SET QUOTED_IDENTIFIER ON /*Dadurch beachtet der SQL-Server die ISO-Regeln für Anführungszeichen bei Bezeichnern und Literalzeichnern.*/ GO -- ============================================= -- Author: MMA -- Create date: 04.05.2017 -- Description: Suche von Ereignissen -- ============================================= CREATE PROCEDURE [dbo].[SucheEreignisse] @BenutzerDBOID uniqueidentifier=NULL, @DBObjektDBOID uniqueidentifier=NULL, @Text varchar(500) = NULL, @Erledigt bit = NULL, @Typ nvarchar(50) = NULL /* Hier werden nun die für diese Prozedur benötigten/möglichen Parameter definiert. Diese können an die Prozedur übergeben werden.*/ AS BEGIN SET NOCOUNT ON; /*Durch "SET NOCOUNT ON" werden unnötigte extra Ergebnisse durch sich gegenseitig beeinflussende SQL-Abfragen vermieden.*/ IF @DBObjektDBOID IS NOT NULL /*Diese IF-Prüfung dient dazu um zwischen Ereignissen ohne und mit Zuordnungen zu unterscheiden.*/ SELECT tbl.*, /*tbl.* stellt die gefundenen Ereignisse inklusive derer Zuordnungen dar.*/ prg_KundenSuche.KNr, prg_KundenSuche.Email, prg_KundenSuche.TelefonMobil /*prg_KundenSuche ist eine bereits vorhandene Prozedur zur Suche nach Kundendaten, sprich in diesem Fall der Kundennummer, E-Mail und der Mobiltelefonnummer*/

TAPI

© Maximilian Marvin XXXIX

A Anhang


FROM (SELECT vwEreignis.Von, vwEreignis.Bis, vwEreignis.Erledigt, vwEreignis.Text, vwEreignis.DBOID, vwEreignis.CreateDate FROM vwEreignis WHERE (@Benutzerdboid IS NULL OR BenutzerDBOID = @BenutzerDBOID) AND (@Text IS NULL OR Text like @Text) AND (@Erledigt IS NULL or Erledigt = @Erledigt) AND (@DBObjektDBOID IS NULL or DBOID in /*Bis zu diesem Punkt werden die Informationen zu den Ereignissen anhand der übergebenen Parametern selektiert.*/ (SELECT EreignisDBOID FROM vwEreignisZuordnung WHERE vwEreignisZuordnung.Aktiv = 1 AND vwEreignisZuordnung.Deleted = 0 AND (@Typ IS NULL OR vwEreignisZuordnung.Typ = @Typ) AND @DBObjektDBOID IS NULL OR vwEreignisZuordnung.DBObjektDBOID = @DBObjektDBOID ))) as tbl /*Bis hierher wird nun noch geschaut ob es zu einem Ereignis EreignisZuordnungen gibt.*/ LEFT JOIN vwEreignisZuordnung on vwEreignisZuordnung.Aktiv = 1 AND vwEreignisZuordnung.Deleted = 0 AND (@Typ IS NULL OR vwEreignisZuordnung.Typ = @Typ) AND vwEreignisZuordnung.EreignisDBOID=tbl.DBOID LEFT JOIN prg_KundenSuche on prg_KundenSuche.DBOID=vwEreignisZuordnung.DBObjektDBOID /*Über diesen LEFT JOIN wird Prozedur prg_KundenSuche eingebunden, so dass hier nach den Daten gesucht werden kann.*/ order by CreateDate desc /*Zuletzt werden die Ergebnisse absteigend sortiert, so dass die Anzeige hierarchisch ist.*/ ELSE /*Wenn keine DBObjektDBOID übergeben wurde, sprich keine EreignisZuordnungen vorhanden sind, wird diese Abfrage ausgeführt.*/ SELECT tbl.*, prg_KundenSuche.KNr, prg_KundenSuche.Email, prg_KundenSuche.TelefonMobil FROM (SELECT vwEreignis.Von, vwEreignis.Bis, vwEreignis.Erledigt, vwEreignis.Text, vwEreignis.DBOID, vwEreignis.CreateDate FROM vwEreignis WHERE (@Benutzerdboid IS NULL OR BenutzerDBOID = @BenutzerDBOID) AND (@Text IS NULL OR Text like @Text) AND (@Erledigt IS NULL or Erledigt =

TAPI

© Maximilian Marvin XL

A Anhang


AND (@Erledigt IS NULL or Erledigt = @Erledigt)) as tbl LEFT JOIN prg_KundenSuche on prg_KundenSuche.DBOID IS NULL order by CreateDate desc END

Listing 1: SQL-Prozedur "SucheEreignisse"

TAPI

© Maximilian Marvin XLI

A Anhang

A.11 Iterationsplan

Folgend ist der vom Autor erstellt Iterationsplan. Er gliedert sich in jeweils einer entsprechenden Aufgabe sowie der Plattform, auf der die Änderungen durchgeführt werden.

Erstellen der benötigten Benutzeroberflächen o SYNCCESS®-Client

Erstellen der Tabellen für die Datenbank o Datenbank

Erstellen der Prozedur „SucheEreignisse“ o Datenbank

Erstellen der Klassen „Anrufer“, „Ereignis“ und „EreignisZuordnung“ o SYNCCESS®-Server

Erstellen der Zusatzklassen „AnrufersucheZeile“ und „EreignissucheZeile“ o SYNCCESS®-Server

Implementierung der Methode „AnruferSuche“ o SYNCCESS®-Server

Implementierung der Methode „SucheEreignisse“ o SYNCCESS®-Server

Implementierung der Event-Handler für die Schnittstelle zu den TK-Anlagen o SYNCCESS®-Client

Implementierung der Zuordnung zwischen Anrufer und Kunde o SYNCCESS® Server, SYNCCESS®-Client

Implementierung der benötigten Methoden zur Datenholung in der neuen Tapi-Maske o SYNCCESS®-Client

TAPI

© Maximilian Marvin XLII

A Anhang

A.12 Screenshots der Oberflächen

Abbildung 7: Screenshot – Anruferliste

Abbildung 8: Screenshot - Tapi-Maske

TAPI

© Maximilian Marvin XLIII

A Anhang

A.13 Listing – RadGridView

<telerik:RadGridView x:Name="RadGridViewAnruferliste" ItemsSource="{Binding Anrufersuche}" ShowGroupPanel="False" SelectionUnit="FullRow" IsReadOnly="True" RowLoaded="RadGridViewAnruferliste_RowLoaded" RowIndicatorVisibility="Collapsed"> <i:Interaction.Behaviors> <Behaviors:ExcelExportBehavior/> <Behaviors:WordExportBehavior/> </i:Interaction.Behaviors> <telerik:RadGridView.Columns> <telerik:GridViewDataColumn Header="Kunde" Width="250" DataMemberBinding="{Binding KundenName}"/> <telerik:GridViewDataColumn Header="KNr" Width="50" DataMemberBinding="{Binding KNr}"/> <telerik:GridViewDataColumn Header="Kat." Width="50" DataMemberBinding="{Binding Kategorie}"/> <telerik:GridViewDataColumn Header="Rufnummer" Width="150" DataMemberBinding="{Binding Telefonnummer}"/> <telerik:GridViewDataColumn x:Name="ColumnRueckruf" Header="Aktion" Width="50"> <telerik:GridViewDataColumn.CellTemplate> <DataTemplate> <controls:PhoneControl Phone="{Binding Telefonnummer}" ContactDBOID="{Binding Anrufer}" ContactPersonDBOID="{Binding Anrufer.AnsprechpartnerDBOID}" PhoneVisibility="Collapsed" HorizontalAlignment="Left"/> </DataTemplate> </telerik:GridViewDataColumn.CellTemplate> </telerik:GridViewDataColumn> <telerik:GridViewDataColumn Header="Status" DataMemberBinding="{Binding Status, Converter={StaticResource Enum2String}}"/> <telerik:GridViewDataColumn Header="Gesprächsdauer (Min.)" DataMemberBinding="{Binding Dauer}" TextAlignment="Right"/> <telerik:GridViewDataColumn Header="Datum" Width="150" DataMemberBinding="{Binding UhrzeitBeginn}"/> <telerik:GridViewDataColumn Header="Exp." Width="50" DataMemberBinding="{Binding ExpedientenNr}"/> <telerik:GridViewDataColumn Header="Anrufrichtung" DataMemberBinding="{Binding Richtung, Converter={StaticResource Enum2String}}"/> </telerik:RadGridView.Columns> </telerik:RadGridView>

Listing 2: RadGridView

TAPI

© Maximilian Marvin XLIV

A Anhang

A.14 – Listings der Kern-Klassen

using System; using System.Runtime.Serialization; namespace ZIEL.Synccess.DAL { [Serializable] [DataContract] public sealed class EreignisZuordnung : SynccessDBObjekt { /// <summary> /// Diese Klasse dient zur Speicherung der Beziehung zwischen einem Ereignis /// und einem eventuell verknüften Objekt. /// </summary> [DataMember] public Guid DBObjektDBOID { get; set; } [DataMember] public Guid EreignisDBOID { get; set; } [DataMember] public string Typ { get; set; } } }


TAPI

© Maximilian Marvin XLV

A Anhang

A.14 – Listings der Kern-Klassen

using System; using System.Runtime.Serialization; namespace ZIEL.Synccess.DAL { [Serializable] [DataContract] public sealed class Ereignis : SynccessDBObjekt { /// <summary> /// Diese Klasse dient zur Speicherung von Informationen zu getätigter Kommunikation. /// </summary> #region Properties [DataMember] public Guid BenutzerDBOID { get; set; } [DataMember] public DateTime? Von { get; set; } [DataMember] public DateTime? Bis { get; set; } [DataMember] public string Text { get; set; } [DataMember] public bool Erledigt { get; set; } [DataMember] public Guid? DBObjektDBOID { get; set; } #endregion } }


TAPI

© Maximilian Marvin XLVI

A Anhang

A.15 Listings – Klassen „AnrufersucheZeile“ und „EreignissucheZeile“

using System; using System.Collections.Generic; using System.Data; using System.Linq; using System.Runtime.Serialization; using System.Text; using System.Xml.Serialization; using ZIEL.Synccess.DAL; namespace ZIEL.Synccess.BOL.Suche { [DataContract] public class AnrufersucheZeile { /// <summary> /// Diese Klasse dient dazu um die Ergebnisse der Methode "AnruferSuche" in /// einem Objekt/einer Liste bündeln zu können. /// </summary> public AnrufersucheZeile(DataRow r) { ExpedientenNr = r.Field<string>("ExpedientenNr"); KNr = r.Field<int?>("KNr"); BenutzerDBOID = r.Field<Guid>("BenutzerDBOID"); AnruferDBOID = r.Field<Guid>("DBOID"); KontaktDBOID = r.Field<Guid?>("KontaktDBOID"); Telefonnummer = r.Field<string>("Telefonnummer"); UhrzeitBeginn = r.Field<DateTime>("UhrzeitBeginn"); UhrzeitEnde = r.Field<DateTime?>("UhrzeitEnde"); Status = r.Field<Anrufer.AnrufStatus>("Status"); Kategorie = r.Field<Kunde.KundenKategorieEnum?>("Kategorie"); KundenName = r.Field<string>("Kunde"); AnsprechpartnerDBOID = r.Field<Guid?>("AnsprechpartnerDBOID"); Richtung = r.Field<Anrufer.AnrufRichtung?>("Richtung"); } #region Properties [DataMember] public string ExpedientenNr { get; set; } […] [DataMember] public Anrufer.AnrufRichtung? Richtung { get; set; }

Listing 5: Klasse "AnrufersucheZeile“

TAPI

© Maximilian Marvin XLVII

A Anhang

A.15 Listings – Klassen „AnrufersucheZeile“ und „EreignissucheZeile“

using System; using System.Data; using System.Runtime.Serialization; namespace ZIEL.Synccess.BOL.Suche { [DataContract] public class EreignissucheZeile { public EreignissucheZeile(DataRow r) { EreignisDBOID = r.Field<Guid>("DBOID"); Von = r.Field<DateTime?>("Von"); Bis = r.Field<DateTime?>("Bis"); Text = r.Field<string>("Text"); Erledigt = r.Field<bool>("Erledigt"); KNr = r.Field<int?>("KNr"); eMail = r.Field<string>("Email"); Telefonnummer = r.Field<string>("TelefonMobil"); } #region Properties [DataMember] public Guid EreignisDBOID { get; set; } [DataMember] public DateTime? Von { get; set; } [DataMember] public DateTime? Bis { get; set; } [DataMember] public string Text { get; set; } [DataMember] public bool Erledigt { get; set; } [DataMember] public int? KNr { get; set; } [DataMember] public string eMail { get; set; } [DataMember] public string Telefonnummer { get; set; } #endregion } }

Listing 6: Klasse "EreignissucheZeile"

TAPI

© Maximilian Marvin XLVIII

A Anhang

A.16 Listing – Methode „AnruferSuche“

public AnrufersucheZeile[] AnruferSuche(AnrufersucheParameter ap) { try { string strSQL = @"SELECT TOP 40 vwAnrufer.DBOID ,vwAnrufer.Telefonnummer ,vwAnrufer.Status ,vwAnrufer.BenutzerDBOID ,vwAnrufer.UhrzeitBeginn ,vwAnrufer.UhrzeitEnde ,vwAnrufer.AnsprechpartnerDBOID ,vwAnrufer.BenutzerDBOID ,vwAnrufer.Richtung ,vwAkteur.Name+', '+vwAkteur.Vorname as Kunde ,vwAkteur.DBOID AS KontaktDBOID ,vwAkteur.Objekttyp ,vwKunde.Kategorie ,vwKunde.KNr ,vwBenutzer.ExpedientenNr FROM vwAnrufer LEFT JOIN vwAkteur on vwAkteur.DBOID=vwAnrufer.KontaktDBOID LEFT JOIN vwKunde ON vwKunde.DBOID=vwAkteur.DBOID INNER JOIN vwBenutzer ON vwBenutzer.DBOID = vwAnrufer.BenutzerDBOID"; string strWhere = @" WHERE vwAnrufer.BenutzerDBOID=@UserDBOID"; var parameter = new List<SqlParameter> { new SqlParameter("@UserDBOID", ap.BenutzerDBOID) } ; if (ap.DBOID != Guid.Empty) { parameter.Add(new SqlParameter(@"AnruferDBOID", ap.DBOID)); strWhere += " AND vwAnrufer.DBOID = @AnruferDBOID"; } strWhere += " ORDER BY vwAnrufer.CreateDate DESC"; var dt = SyncessDB.Current.AnfrageDT(strSQL+strWhere, parameter.ToArray()); var ret = dt.AsEnumerable().Select(r => new AnrufersucheZeile(r)).ToArray(); return ret; } catch (Exception exc) { _logger.Error(exc); ExceptionManagement.Publish(exc); throw new FaultException(exc.Message); } }

Listing 7: Methode "AnruferSuche"

TAPI

© Maximilian Marvin XLIX

A Anhang

A.17 Listing - Methode „SucheEreignisse“

public EreignissucheZeile[] SucheEreignisse(EreignisSucheParameter parameter) { try { CheckDatabaseConnection(); var lstParameter = new List<SqlParameter>(); if(parameter.BenutzerDBOID.HasValue) lstParameter.Add(new SqlParameter("@BenutzerDBOID", parameter.BenutzerDBOID ?? System.Data.SqlTypes.SqlGuid.Null)); if(parameter.DBObjektDBOID.HasValue) lstParameter.Add(new SqlParameter("@DBObjektDBOID", parameter.DBObjektDBOID ?? System.Data.SqlTypes.SqlGuid.Null)); if (!string.IsNullOrEmpty(parameter.Text)) lstParameter.Add(new SqlParameter("@Text", "%" + parameter.Text + "%")); if (parameter.Erledigt.HasValue) lstParameter.Add(new SqlParameter("@Erledigt", parameter.Erledigt.Value)); if (!string.IsNullOrEmpty(parameter.Typ)) lstParameter.Add(new SqlParameter("@Typ", parameter.Typ)); var dt = SyncessDB.Current.AnfrageDT("SucheEreignisse", CommandType.StoredProcedure, lstParameter.ToArray()); return dt.AsEnumerable().Select(r => new EreignissucheZeile(r)).ToArray(); } catch(Exception exc) { _logger.Error(exc); throw new FaultException(exc.Message); } }

Listing 8: Methode "SucheEreignisse"

TAPI

© Maximilian Marvin L

A Anhang

A.18 Listing – Anrufer-Kunde Zuordnung

protected async override void OnPropertyChanged(DependencyPropertyChangedEventArgs e) { base.OnPropertyChanged(e); /* * Fall 1: Anrufer ist nicht bekannt; Ansprechpartner- und Kontakt-DBOID somit null * Fall 2: Anrufer ist bereits bekannt; KontaktDBOID vorhanden, AnsprechpartnerDBOID möglicherweise * Fall 3: Anrufer ist bereits bekannt, ist aber nicht der Ansprechpartner; Kontakt- und AnsprechpartnerDBOID vorhanden und verschieden */ if (e.Property == AnrufersucheZeileProperty) { Anrufer = (Anrufer)(await DataService.GetInstanceDeepAsync(AnrufersucheZeile.AnruferDBOID)); GetEreignisse(); DBObjekt dbObject = null; if (!AnrufersucheZeile.KontaktDBOID.HasValue) { using (GetProgressHandler(@"Suche nach Kontakt..")) { var result = await DataService.RufnummernsucheNummerOnlyAsync(AnrufersucheZeile.Telefonnummer); if (result.Count > 0 && Anrufer != null) { Anrufer.KontaktDBOID = result[0].DBOID; Anrufer.AnsprechpartnerDBOID = result[0].AnsprechpartnerDBOID; var anruferResult = (Anrufer)await DataService.SaveAndReturnAsync(Anrufer); Anrufer = anruferResult; AnrufersucheZeile.KontaktDBOID = result[0].DBOID; AnrufersucheZeile.AnsprechpartnerDBOID = result[0].AnsprechpartnerDBOID; var anruferlisteWindow = Application.Current.Windows.OfType<Dialog<AnruferlisteView>>().FirstOrDefault(); if (anruferlisteWindow != null) anruferlisteWindow.View.LadeAnrufer(); } } }

[…]

Listing 9: Anrufer-Kunde Zuordnung

TAPI

© Maximilian Marvin LI

A Anhang

A.19 Listings – Event-Handler der TAPI-Schnittstelle(Auszug)

private void TapiServiceEingehenderAnruf(object sender, TapiEventArgs e) { try { Trace.WriteLine("MainModule->TapiServiceOnIncomingCall"); Anrufer = new Anrufer { Status = Anrufer.AnrufStatus.NichtAngenommen, BenutzerDBOID = Container.Resolve<IAuthenticationService>().CurrentUser.Key.ToString(), Leitung = e.Line.Name, Telefonnummer = e.Call.CallerID, UhrzeitBeginn = DateTime.Now, Richtung = Anrufer.AnrufRichtung.Eingegangen }; Anrufer = Resolve<IDataService>().SaveAndReturn(this.Anrufer) as Anrufer; var tapiEventArgsCallerTuple = new Tuple<TapiEventArgs, Anrufer>(e, Anrufer); GlobalCommands.OpenAnruferliste.Execute(tapiEventArgsCallerTuple); } catch (Exception exc) { _log.Error(exc); } }

Listing 10: Event-Handler "EingehenderAnruf"

void TapiService_EingehenderAnrufVerbunden(object sender, TapiEventArgs e) { this.Anrufer.Status = Anrufer.AnrufStatus.Angenommen; }

Listing 11: Event-Handler "EingehenderAnrufVerbunden"

TAPI

© Maximilian Marvin LII

A Anhang

A.19 Listings – Event-Handler der TAPI-Schnittstelle(Auszug)

private async void TapiAnrufBeendet(TapiCallDisconnectedArgs args) { if (args.Anrufer == null) return; if (!args.Anrufer.UhrzeitEnde.HasValue) args.Anrufer.UhrzeitEnde = DateTime.Now; args.Anrufer.Richtung = this.Anrufer.Richtung; args.Anrufer.Status = this.Anrufer.Status == Anrufer.AnrufStatus.NichtAngenommen ? Anrufer.AnrufStatus.NichtAngenommen : Anrufer.AnrufStatus.Angenommen; await Resolve<IDataService>().SaveAsync(args.Anrufer); AktualisiereAnruferliste(); }

Listing 12: Event-Handler "AnrufBeendet"

TAPI

© Maximilian Marvin LIII

public async void SpeichereEreignis(bool aktualisiereAnzeige) { try { if (Ereignis == null) return; if (Anrufer != null) { Ereignis.Bis = Anrufer.UhrzeitEnde ?? DateTime.Now; Ereignis.Von = Anrufer.UhrzeitBeginn ?? DateTime.Now; } var neuesEreignis = Ereignis.IsNew; var result = (Services.Wcf.Ereignis)(await DataService.SaveAndReturnAsync(Ereignis)); foreach (var prop in Ereignis.GetType().GetProperties().Where(prop => prop.CanWrite && prop.CanRead)) { try { prop.SetValue(Ereignis, prop.GetValue(result, null), null); } catch (Exception e) { HandleException(e); } } if (neuesEreignis) { if (AnrufersucheZeile.KontaktDBOID.HasValue) { await DataService.SaveAsync(new EreignisZuordnung() { EreignisDBOID = Ereignis.Key, DBObjektDBOID = AnrufersucheZeile.KontaktDBOID.Value, Typ = "Kunde" }); } if (AnrufersucheZeile.AnsprechpartnerDBOID.HasValue && AnrufersucheZeile.AnsprechpartnerDBOID != AnrufersucheZeile.KontaktDBOID) { await DataService.SaveAsync(new EreignisZuordnung() { EreignisDBOID = Ereignis.Key, DBObjektDBOID = AnrufersucheZeile.AnsprechpartnerDBOID.Value, Typ = "Ansprechpartner" }); } } //aktualisieren der Anzeige der Events, um das neue direkt zu sehen if(aktualisiereAnzeige) GetEreignisse(); } catch (Exception e) { HandleException(e); } }

A Anhang

A.20 Listings - Methoden der Tapi-Maske(Auszug)

Listing 13: Methode "SpeichereEreignis“

TAPI

© Maximilian Marvin LIV

A Anhang

A.21 Hinterlegung der TAPI-Leitung in der Administration von SYNCCESS®

Abbildung 9: TAPI-Einstellungen in der Administration von SYNCCESS®

TAPI

© Maximilian Marvin LV

A Anhang

A.22 Listing – XAML-Code des „Speichern und auflegen“-Button

<telerik:RadButton Name="btnSaveAndHangUp" Click="btnSaveAndHangUp_Click" Grid.Column="2" Height="25" Content="Speichern und auflegen"> <telerik:RadButton.Style> <Style TargetType="telerik:RadButton"> <Style.Triggers> <DataTrigger Binding="{Binding AnrufStatus}" Value="Disconnected"> <Setter Property="IsEnabled" Value="False"/> </DataTrigger> <DataTrigger Binding="{Binding AnrufStatus}" Value="Unknown"> <Setter Property="IsEnabled" Value="False"/> </DataTrigger> <DataTrigger Binding="{Binding AnrufStatus " Value="Connected"> <Setter Property="IsEnabled" Value="True"/> </DataTrigger> </Style.Triggers> </Style> </telerik:RadButton.Style> </telerik:RadButton>

Listing 14: XAML-Code "Speichern und auflegen"-Button

TAPI

© Maximilian Marvin LVI

A Anhang

A.23 Listing – Beispielkorrektur des XAML-Code

<telerik:RadButton Name="btnSaveAndHangUp" Click="btnSaveAndHangUp_Click" Grid.Column="2" Height="25" Content="Speichern und auflegen">

<telerik:RadButton Name="btnSaveAndHangUp" Click="btnSaveAndHangUp_Click" Grid.Column="2" Height="25" Content="Speichern und auflegen">

Listing 15: XAML-Code Beispielkorrektur(vorher)

Listing 16: XAML-Code Beispielkorrektur(nachher)

TAPI

© Maximilian Marvin LVII

A Anhang

A.24 Entwicklerdokumentation(Auszug)

Dieses Listing soll als Beispiel für die Dokumentation durch den Entwickler dienen. Zusätzlich zu den Kommentaren werden noch Architekturentwürfe, Prinzipien und Anforderungen an die Weiterentwicklung sowie weitere Code-Kommentare enthalten.

private void _tapiService_CallDisconnected(object sender, TapiEventArgs e) { CallState = TapiCallState.Disconnected; // Binding wird entsprechend auf Disconnected gesetzt -> Deaktivierung der Buttons _tapiService.Disconnect(new TapiCallDisconnectedArgs(Anrufer)); // Event beim TapiService wird gefeuert -> erneute Speicherung des Anrufers für die Endzeit des Gesprächs SpeichereEreignis(true); // Ereignis wird automatisch gespeichert -> Übergabeparameter gibt an, dass die Liste der Ereignisse aktualisiert werden soll _tapiService.CallDisconnected -= _tapiService_CallDisconnected; // der Event-Handler wird entladen }

Listing 17: Entwicklerdokumentation(Auszug) - Beispielkommentare

TAPI

© Maximilian Marvin LVIII

A Anhang

A.25 Anwenderdokumentation(Auszug)

Im folgenden Auszug aus der Anwenderdokumentation werden die einzelnen Spalten der Anruferliste genau beschreiben.

„Kunde“:

Hier finden Sie den Namen des Kunden vor, der Sie angerufen hat. Hier gilt es zu beachten dass es sich um den Namen des Hauptkunden, nicht um einen eventuell vorhandenen abweichenden Ansprechpartner handelt.

„KNr“: Dabei handelt es sich um die Kundennummer des zugeordneten Kunden.

„Rufnummer“: Das ist die Nummer, mit der der Kunde Sie angerufen hat.

„Aktion“: Hier haben Sie die Möglichkeit die angegebene Nummer direkt zurückzurufen.

„Status“: Der Status gibt an, ob ein Gespräch angenommen oder nicht angenommen wurde.

„Gesprächsdauer(Min.)“: Hier finden Sie die Gesprächsdauer in Minuten vor.

„Datum“: Hierbei handelt es sich um den Zeitpunkt, zu dem der Anruf gestartet wurde.

„Exp.“: Das ist das Kürzel des angerufenen Expedienten.

„Anrufrichtung“: Hieraus können Sie erkennen, ob der Anruf ausgehend oder eingehend war.

TAPI

© Maximilian Marvin LIX

A Anhang

A.26 Fehlerdokumentation(Auszug)

Dieser Auszug aus der Fehlerdokumentation zeigt wie eventuell gefundene Fehler dokumentiert werden.

Fehler 1, Modul TAPI, 15.05.2017

Wie hat sich der Fehler ausgewirkt?

Fehler hat dafür gesorgt dass trotz beendeten Gesprächs der Button „Speichern und auflegen“ der Tapi-Maske weiterhin betätigt werden konnte.

Potentielle Folgen des Fehlers?

Der Kunde könnte dadurch Fehlermeldungen und einen Programmabsturz erzeugen. Zudem könnte es durchaus verwirrend sein, wenn der Button weiterhin aktiv ist.

Ursache des Fehlers?

Trotz korrekter Aktualisierung des Anrufstatus wurde vor Fehlerbehebung kein Update an den Button darüber geschickt.

Wie wurde der Fehler behoben?

Der Button wurde um einen DataTrigger erweitert, welcher dessen Aktivität je nach Anrufstatus nun korrekt steuert.

AbschlussprÃ¼fung Sommer 2017 - Dokumentation · d W/ D Æ ] u ] o ] v D À ] v

Documents

Transcript of AbschlussprÃ¼fung Sommer 2017 - Dokumentation · d W/ D Æ ] u ] o ] v D À ] v