Client/Server Applikation mit Android

Transkript

1 Hochschule Luzern Bachelor Diplomarbeit TA.BA_BAA+INF.F1201 Client/Server Applikation mit Android Eine Projektarbeit von Christoph Moser und Thomas Galliker Horw, 8. Juni 2012

2

3 Abstract The vast majority of small and midsized companies in Switzerland are focused on service delivery. Vertec is a Zurich-based software vendor which has built up an enterprise resource planning (ERP) software to address the needs of service delivering companies. The business partner of this Bachelor thesis, Achermann & Partner GmbH, is a representative agent of Vertec. It has strong aims to lead the Vertec ERP together with its customers towards a converged mobile solution. Field service employees will be given a tool to track their tasks and charge services using a mobile platform. The purpose of this project is to design and develop a mobile application which is able to gather tasks, projects, services and customer information from the Vertec ERP system. Users can browse through their daily tasks and the respective information. Once they finish customer orders, they can charge service fees immediately onsite. The outcome of this project is a ready-touse Android application called Vertec Mobile App (VMA) which connects to a sophisticated integration service, Vertec Integration Service (VIS). The data communication between VMA and VIS builds up on basic web technologies like HTTP and TLS, and uses JSON as a bandwidth-optimized data exchange format. The key technology behind VIS is Microsoft Windows Communication Foundation (WCF). It turns VIS into a powerful and flexible integration service with high potential for further integration propositions. The user interface of VMA was designed to meet usability standards. Intuitive and informative UI elements like the dashboard with its numbered bullets and the flipping tab indicator of the task list are just two out of a handful of gadgets. The cutting edge of this project is a C2DM-less push notification service which informs VMA users about recently changed Vertec objects.

4

5 Dokumentenübersicht 1 Bericht Management Summary, Einführung, Evaluation, Projektergebnis, Diskussion, Fazit 2 Projektplan Meilensteinplanung, Grob-/Feinplanung, Risikomanagement, Build-/Release Management 3 Kundenanforderung Zielbestimmung, Anforderungen, Anwendungsfälle 4 Systemspezifikation Softwarearchitektur, UI-Konzept, Design-Entscheide, Environment-Anforderungen 5 Testplan Teststrategie, Testfälle, Testumgebung, Testwerkzeuge 6 Akzeptanztest Formale Projektabnahme vom 31. Mai Beta Programm Vorgehensweise bei Systemtests, Feedback-Formular 8 Anhang

6

7 Selbständigkeitserklärung Hiermit erklären wir, dass die vorliegende Arbeit selbstständig angefertigt und keine anderen als die angegebenen Hilfsmittel verwendet wurden. Sämtliche verwendeten Textausschnitte, Zitate oder Inhalte anderer Verfasser wurden ausdrücklich als solche gekennzeichnet. Horw, 8. Juni 2012 Unterschrift Christoph Moser Unterschrift Thomas Galliker

8

9 Hochschule Luzern Bachelor Diplomarbeit TA.BA_BAA+INF.F1201 Client/Server Applikation mit Android B e r i c h t Horw, 8. Juni 2012

10

11 Projekt Dokument Schule Modul Client/Server Applikation mit Android Bericht Hochschule Luzern, TA.BA_BAA+INF.F1201 Projektteam Dozent Experte Letzte Änderung Galliker Thomas Studiengang Informatik (BB) Panorama 6123 Geiss Tel Roland Gisler Urs Gehrig 7. Juni 2012, 21:03:00 Uhr Moser Christoph Studiengang Informatik (VZ) Zugerbergstrasse Unterägeri Tel

12

13 Management Summary Aufgabenstellung Der Auftraggeber dieses Projekts, die Achermann & Partner GmbH mit Sitz in Luzern, vertreibt das für Dienstleistungsunternehmen ausgelegte ERP System Vertec. Für das Vertec ERP-System soll eine Anwendung für Android Mobiltelefone erstellt werden, sodass Projektaufträge unterwegs bearbeitet werden können. Zudem soll es möglich sein, Leistungen direkt auf dem Android Gerät zu erfassen. Vorgehen Während der Initialisierungsphase wurde die Projektorganisation aufgebaut, die Planung vorgenommen sowie die Schulung am ERP-System organisiert. Zu Beginn der anschliessenden Konzeptionierungsphase wurden in einer Evaluation verschiedene Lösungswege bewertet. Das Zusammenführen von verschiedenen, voneinander unabhängigen Prototypen war die Grundlage für den vertikalen Durchstich. Dadurch konnte die konzeptionierte Softwarearchitektur verifiziert werden. In der nächsten Phase wurden die einzelnen Anwendungsfälle umgesetzt und systematisch getestet. In regelmässigen Abständen wurden den Interessensgruppen zu Qualitätssicherungszwecken erste Versionen der Software ausgeliefert. Rückmeldungen aus Systemtests wurden systematisch in die Entwicklung miteinbezogen. Resultate Die entwickelte Lösung verbindet eine Android App (Vertec Mobile App; VMA) über einen Integrationsdienst (Vertec Integration Service; VIS) mit dem Vertec ERP-System. Der auf WCF basierende Integrationsdienst VIS setzt eine moderne, Service-orientierte Architektur um. Ein raffinierter Synchronisationsmechanismus sorgt dafür, dass Änderungen beidseitig repliziert werden. Der Offline-Betrieb garantiert, dass der Anwender Aufträge und Leistungen auch dann bearbeiten kann, wenn keine Internetverbindung besteht. Als experimentelles Feature wird ein eigenentwickelter Push Notification Service angeboten, welcher VMA Clients automatisch über Änderungen an den ERP-Daten informiert. Ausblick Die Architektur dieses Projektsystems ist so konzipiert, dass eine Erweiterung des Funktionsumfangs (z.b. Spesenabrechnung) problemlos möglich ist. Die intelligente Trennung von Integrationslogik und Kommunikationstechnologie auf VIS ermöglicht das problemlose Einbinden von weiteren mobilen Endgeräten. Der Auftraggeber beabsichtigt, die erstellte Softwarelösung schrittweise in bestehende Kundeninstallationen zu integrieren.

14

15 Inhalt 1 Einleitung Ausgangslage Aufgabenstellung Motivation Auflagen Projektvorgehen Eingesetzte Werkzeuge Ist-/Soll-Vergleich Evaluation Lösungsvarianten Evaluation der Android Plattform Projektergebnis Umfang und Erfüllungsgrad Innovationsgehalt Aufgetretene Probleme Lessons Learned Diskussion Beurteilung der Anwendungsleistung Mögliche Erweiterungen Projektabschluss Persönliches Fazit von Christoph Moser Persönliches Fazit von Thomas Galliker Quellen Abbildungsverzeichnis Abbildung 1: Bereits existierende Vertec iphone Applikation [9]... 3 Abbildung 2: Rahmenplan mit den durchlaufenen Iterationen... 5 Abbildung 3: Verteilung der Android Versionen (Erhebung von Anfang Mai 2012, [1]) Abbildung 4: Unverschlüsselter Datenverkehr (links) und SSL-verschlüsselter Datenverkehr (rechts) Abbildung 5: Source Code Statistik Abbildung 6: Automatisierten Unit- und Integrationstests des VIS Abbildung 7: Die Statistik der Code Inspektion visualisiert das Refactoring Abbildung 8: Zertifikatwarnung des Android Browsers Tabellenverzeichnis Tabelle 1: Begriffe & Abkürzungen... 9 Tabelle 2: Referenzierte Dokumente... 9 Tabelle 3: Soll-/Ist-Vergleich... 7 Tabelle 4: Morphologischer Kasten zur Eruierung geeigneter Lösungsvarianten [5] Tabelle 5: Bewertung und Vergleich der Lösungsvarianten Tabelle 6: Übersicht der Android Bildschirmauflösungen und deren Verbreitung in Prozent (rot) [2] Tabelle 7: Messergebnisse des Leistungstests... 25

16 Änderungsprotokoll Version Datum Autor Beschreibung moc Initialversion von Vorlage erstellt, Evaluation Android Plattformen gat Evaluation mit morphologischem Kasten gat Dokumentation der prinzipiellen Lösungen moc Dokumentation der Auflage bezüglich der Smartphone Plattform moc Vertec XML Schnittstelle dokumentiert moc Dokumentation der Vertec XML Schnittstelle überarbeitet moc Entwurf für Einleitung erstellt moc Vertec XML Schnittstelle überarbeitet moc Projektübersicht erstellt moc Projektvorgehen beschrieben moc Eingesetzte Werkzeuge dokumentiert moc Evaluation der Android Plattform aktualisiert gat Abstract geschrieben moc/gat Allgemeine Korrekturen

17 Begriffe & Abkürzungen Abkürzung DPI ERP GPS HSLU HTAgil JIRA JSON OCL REST RPC SOAP Vertec VIS VMA WCF XMPP WCF Tabelle 1: Begriffe & Abkürzungen Erklärung Dots per Inch Enterprise Resource Planning. Ein ERP-System wird in Unternehmen für die Ressourcenplanung eingesetzt. Global Positioning System Hochschule Luzern Iterativ-inkrementelles Vorgehensmodell der Hochschule Luzern JIRA ist ein webbasiertes Applikation um gemeldete Fehler zu verwalten JavaScript Object Notation, kompaktes Datenaustauschformat mit geringerem Overhead im Vergleich zu XML Object Constraint Language, eine UML-standardisierte Abfragesprache Representational State Transfer, ein Set von fundamentalen Standardprotokollen, welche für die Web Kommunikation eingesetzt werden Remote Procedure Call, Aufruf von Prozeduren auf entfernten Systemen Simple Object Access Protocol, ein Internetstandard von W3C für die Repräsentation von Austauschinformationen zwischen Web Services [12] Hersteller des Vertec ERP-Systems, welches in diesem Projekt verwendet wird Vertec Integration Service Vertec Mobile App Windows Communication Foundation, eine Service-orientierte Kommunikationsplattform für Microsoft.Net Extensible Messaging and Presence Protocol, ehem. Jabber, Kommunikationsprotokoll für Instant Messanging (Facebook Chat, Google Talk) Windows Communication Foundation, eine Service-orientierte Kommunikationsplattform basierend auf Microsoft.Net Referenzen Ref Dokument [PPLAN] 03 Dokumentation \ BDA_Projektplan.doc [KUNAF] 03 Dokumentation \ BDA_Kundenanforderung.doc [SPEZ] 03 Dokumentation \ BDA_Systemspezifikation.doc [TPLAN] 03 Dokumentation \ BDA_Testplan.doc [APROT] 03 Dokumentation \ BDA_Akzeptanztest.doc [TPROT] 03 Dokumentation \ BDA_Testprotokoll_<yyyy-mm-dd>.doc [BETAP] 03 Dokumentation \ BDA_BetaProgramm.doc [APPX] 03 Dokumentation \ BDA_Appendix.doc [RELN] 04 Entwicklung \ 04 Release Info \ release.txt Tabelle 2: Referenzierte Dokumente

18

19 Bericht Einleitung Hochschule Luzern 1 Einleitung Die rasante Verbreitung von mobilen Geräten und deren wachsende Leistungsfähigkeit erlauben immer weitere Anwendungsmöglichkeiten. Diese Feststellung hat auch die Achermann & Partner GmbH gemacht und sich dazu entschieden, als Wirtschaftspartner der Hochschule Luzern eine Smartphone Applikation als Erweiterung für eine bestehende ERP Lösung entwickeln zu lassen. Die Achermann & Partner GmbH ist der Auftraggeber dieses Projekts und wird als solches in allen Projektdokumenten vermerkt. Die Umsetzung dieses Auftrags wurde im Rahmen der Bachelor Diplomarbeit (BDA) von Christoph Moser und Thomas Galliker durchgeführt. 1.1 Ausgangslage Vertec ist ein ERP-System für Dienstleistungsunternehmen, welches vorwiegend von Schweizer KMUs eingesetzt wird. Unser Wirtschaftspartner, die Achermann & Partner GmbH mit Sitz in Luzern, vertreibt dieses ERP-System erfolgreich in der Zentralschweiz. Zum Kundenkreis von Vertec gehören namhafte Firmen, wie AlpTransit, ELCA, Zühlke Engineering und die Zürcher Kantonalbank. Projektleiter können im Vertec ERP-System Projekte verwalten und ihren Projektmitarbeitern Aufträge zuteilen. Da der Interaktionsradius der Vertec Anwender oft weit über den Geschäftssitz des Unternehmens hinaus reicht, möchte die Achermann & Partner GmbH eine mobile Anbindung an das ERP-System realisieren. Für das Vertec ERP-System soll deshalb eine Android Applikation entwickelt werden, welche es Aussendienstmitarbeitern erlaubt, Aufträge unterwegs abzurufen und nach geleisteter Arbeit die aufgewendeten Stunden zu rapportieren. Zusätzlich soll der Anwender mit Funktionalitäten unterstützt werden, welche das effiziente Erledigen von Aufträgen ermöglicht. 1.2 Aufgabenstellung Im Rahmen dieser Arbeit soll ein Lösungskonzept erarbeitet und in einem Prototyp umgesetzt werden, welches erlaubt, mittels einer Android Applikation auf das ERP-System zugreifen zu können. Ein konkreter Use Case ist die mobile Erfassung von Dienstleitungen. Dafür sollen die in Android bereits vorhandenen Dienste zur Positionsbestimmung oder die Fotokamera verwendet werden können. Der Auftraggeber stellt eine Reihe von nicht-funktionalen Anforderungen wie z.b. Robustheit, minimaler, ressourcenschonender Datenaustausch und sichere Datenübertragung. Deshalb muss in einem ersten Schritt eine sinnvolle Gesamtarchitektur erarbeitet werden. Diese soll vorsehen, die von Vertec angebotenen Schnittstellen bereits serverseitig so zu abstrahieren, dass eine möglichst effiziente Kommunikation mit den Android-Clients möglich ist (Datenmenge, Caching etc.). Bezüglich serverseitig verwendeter Sprache gibt es vom Auftraggeber keine Präferenz. Die Softwarearchitektur soll mit einem Prototyp verifiziert werden. Der definitive Umfang der Umsetzung (im Rahmen der BDA) wird nach Vorliegen des verifizierten Konzeptes und der Architektur gemeinsam mit dem Auftraggeber festgelegt. Wesentliche Teile der Arbeit sind: Analyse der Anforderungen, Konzept, Prototyping, Implementation, Test und vollständige Dokumentation. Zusätzlich sollen auch die verwendete Entwicklungsumgebung (IDE, Libraries etc.) und die exakte Zielplattform (Android-Versionen, Geräte, Auflösungen etc.) klar definiert werden. Client/Server Applikation mit Android 1

20 Hochschule Luzern Bericht Einleitung Es ist mit aktuellen Techniken zur Continuous Integration zu arbeiten. Es sollen, so weit als möglich, automatisierte Testfälle vorliegen, welche im Falle von Integrationstests von den jeweiligen Back- oder Frontendsystemen sinnvoll zu entkoppeln sind. Die Studenten werden vom Auftraggeber in die vorhandene ERP-Lösung eingeführt und erhalten ein entsprechendes Testsystem bzw. die dazu notwendige Software und Lizenzen. (Die Originalfassung der Aufgabenstellung ist im Anhang [APPX] zu finden). 1.3 Motivation Durch den Einsatz einer Smartphone Applikation, die es erlaubt, Daten vom ERP-System abzurufen und zu bearbeiten, ist ein wesentlich effizienterer Arbeitsablauf möglich. Ein Aussendienstmitarbeiter kann sich die Zeit für den Ausdruck der Auftrags- und Kundeninformationen sparen. Er muss zu Beginn des Arbeitstages lediglich die Vertec Mobile Applikation starten und erhält so alle benötigten Informationen für den aktuellen Arbeitstag. Des Weiteren gewinnt man durch den Einsatz einer mobilen Applikation Flexibilität bei der Arbeitsplanung. Wenn beispielsweise in einem Unternehmen ein neuer Auftrag mit hoher Priorität aufgegeben wird, kann der Projektleiter diesen Auftrag direkt einem Mitarbeiter zuweisen, ohne dass er diesen telefonisch kontaktieren muss. Der neue Auftrag erscheint beim Mitarbeiter automatisch in der Auftragsliste des entsprechenden Tages. Durch das Abrechnen von erbrachten Leistungen über eine mobile Lösung kann der administrative Aufwand wesentlich verringert werden. Zudem kann die Durchlaufzeit von der Ausführung eines Auftrages bis zur Rechnungsstellung massiv verkürzt werden. Papier ist geduldig und bleibt in der Regel eine gewisse Zeit liegen. Das Übertragen von Papierformularen ins System kostet nicht nur unnötige Personalressourcen, sondern ist auch eine äusserst demotivierende Tätigkeit. Zudem hat der Projektleiter eine bessere Übersicht über ein Projekt, wenn die bereits geleisteten Stunden gleich kurz nach dem Erfassen im System aufgeführt werden. 2 Client/Server Applikation mit Android

21 Bericht Einleitung Hochschule Luzern 1.4 Auflagen Vertec bietet bereits eine iphone Applikation an, mit welcher Leistungen und Spesen erfasst werden können. Die verfügbare iphone Applikation wurde als Web-Applikation realisiert und könnte dadurch auf den verschiedensten Plattformen (Android, BlackBerry, WindowsPhone) eingesetzt werden [9]. Der Auftraggeber hat sich entschieden, eine eigene Applikation für Android Smartphones zu entwickeln, da die vorhandene Vertec iphone Applikation die Anforderung der Achermann & Partner GmbH nicht erfüllen kann. Abbildung 1: Bereits existierende Vertec iphone Applikation [9] Die folgenden Punkte sind in der Verte iphone Applikation nicht zufriedenstellend und müssen in diesem Projekt unbedingt beachtet werden: Der Benutzer wird auf der iphone Applikation mit Informationen überflutet. Beispielsweise werden alle Projekte aufgelistet, welche im ERP-System verwaltet werden. Dadurch muss der Benutzer durch alle Projekte navigieren, um die für ihn relevanten Aufträge zu finden. Das kann u.u. sehr umständlich sein. Mit der iphone Web Applikation können Leistungen nur erfasst werden, wenn eine Verbindung zum Server besteht. Wenn keine Internetverbindung aktiv ist oder der Web Server nicht erreichbar ist, kann die Web Applikation nicht verwendet werden. Bordmittel, wie z.b. Google Maps oder die Fotokamera können in der Web Applikation nicht verwendet werden. Daraus haben sich für die Umsetzung des Projektsystems folgende Anforderungen herauskristallisiert: Das primäre Ziel der Applikation ist das Unterstützen des Mitarbeiters beim Ausführen von Aufträgen. Somit ist es von zentraler Bedeutung, dass er die ihm zugewiesenen Aufträge schnell auffinden kann. Der Mitarbeiter sollte Leistungen im Offline-Betrieb erfassen können. Bei der nächsten Verbindung zum Server sollen die lokal erfassten Leistungen mit dem ERP-System synchronisiert werden. Es sollen die vorhandenen Bordmittel für die Navigation und das Erfassen von Fotos verwendet werden können. Client/Server Applikation mit Android 3

22 Hochschule Luzern Bericht Projektvorgehen 2 Projektvorgehen Für das Vorgehen in diesem Projekt wurde ein iterativer, inkrementeller Entwicklungsansatz gewählt. Der iterative Ansatz erlaubt es, die verschiedenen Disziplinen Kundenanforderungen, Spezifikation, Realisierung und Tests mehrmals zu durchlaufen. So kann rechtzeitig auf Probleme reagiert werden und kontrollierte Änderungen der Anforderungen können in das Projekt einfliessen. Die iterative Vorgehensweise erlaubte es, den definitiven Umfang welcher zu Beginn des Projektes noch nicht feststand mit dem Auftraggeber im Verlauf des Projekts auszuarbeiten. Zusätzlich wurde der Funktionsumfang bei jedem Release erweitert und dem Kunden für Testzwecke zur Verfügung gestellt. Dadurch erhielt der Auftraggeber frühzeitig einen ersten Eindruck der Applikation und konnte wertvolle Rückmeldungen in die Weiterentwicklungen einbringen. Die Dokumente, welche im Rahmen dieses Projekts erarbeitet wurden, sind in Anlehnung an HTAgil entstanden [10]. Zu Beginn des Projekts ging es darum, einen Rahmenplan zu erstellen, sowie das ERP-System Vertec kennenzulernen. Bei den Einführungen ins ERP-System kristallisierten sich auch bereits erste Anforderungen heraus, welche im Gespräch mit dem Kunden verfeinert wurden. In der Konzeptionierungsphase wurde die Evaluation der Architektur lanciert (Kapitel 3, Seite 8). Dabei wurde das Gesamtsystem in einzelne Subsysteme unterteilt. Für die einzelnen Teilsysteme wurde recherchiert, welche Technologien eingesetzt werden könnten. Diese Technologien wurden in einem morphologischen Kasten zu prinzipiellen Lösungen zusammengeführt und bewertet. Es wurde früh damit begonnen, voneinander unabhängige Prototypen zu erstellen, welche einzelne oder mehrere Anforderungen abdecken konnten. Anforderungen mit hoher Risikoeinschätzung wurden mit höherer Priorität in Prototypen umgesetzt. Mit dieser Massnahme wurde versucht, möglichst früh für die einzelnen Risiken Lösungen zu erarbeiten und dadurch das Gesamtrisiko des Projekts zu minimieren. Beispielsweise wurde ein Prototyp für die Kommunikation zwischen der Android Applikation und dem Server Service basierend auf WCF erstellt. Am Ende der Prototyping-Phase wurde überprüft, ob die erstellten Prototypen die Anforderungen des Auftraggebers abdecken konnten. Während der Realisierungsphase wurden die zu entwickelnden Funktionalitäten in mehrere Iterationen aufgeteilt, wobei der definitive Inhalt einer Iteration jeweils zu Beginn einer Iteration festgelegt wurde. In der ersten Iteration wurden die erstellten Prototypen in einem Gesamtprototyp vereint. Das Ziel der ersten Iteration war, den vertikalen Durchstich zu realisieren, d.h. erste Datenobjekte vom ERP-System auf die Android App zu übertragen und anzuzeigen. In der zweiten Iteration wurden die weiteren Use Cases implementiert. Vertec Datenobjekte sollten gemäss diesen Use Cases vom ERP-System in die Android App geladen, bearbeitet und zurück ins ERP-System geschrieben werden können. Das Konstruieren eines Synchronisationsmechanismus war eines der grossen Ziele dieser Iteration. Mit dem Abschluss der zweiten Iteration wurde auch das Konzept für das Build- und Release-Management fertiggestellt, womit aktuelle Releases den Interessenten für Tests zur Verfügung gestellt werden konnten. Die Erkenntnisse aus den Systemtests und die Rückmeldungen von Interessenten, wurden in einer Issue-Tracking Liste erfasst. Diese Liste war jeweils ein wesentlicher Bestandteil bei der Planung einer neuen Iteration. 4 Client/Server Applikation mit Android

23 Bericht Projektvorgehen Hochschule Luzern Rahmenplan Vertec kennenlernen Anforderung erfasst Lauffähiger Prototyp Zwischenpräsentation Systemtests durchgeführt Abgabe Bachelorarbeit M1 M2 M3 M4 M5 Initialisierung Konzeptionierung Realisierung Abschluss Prototyping Iter. 1 Iter. 2 Iter. 3 Iter. 4 Iter. 5 Iter. 6 SW1 SW2 SW3 SW4 SW5 SW6 SW7 SW8 SW9 SW10 SW11 SW12 SW13 SW14 SW15 SW16 Abbildung 2: Rahmenplan mit den durchlaufenen Iterationen In der dritten Iteration der Realisierungsphase wurden die Android API Funktionen implementiert. API Funktionen, wie z.b. das Anrufen von Telefonnummern aus der App, sind gut dokumentiert und können mit geringem Aufwand in eine App integriert werden. Diese Android Bordfunktionen wurden bewusst nicht zu früh implementiert, da das Risiko für die Umsetzung dieser Anwendungsfälle als gering eingeschätzt wurde. Nach der dritten Iteration waren alle Funktionalitäten grob implementiert, welche als Muss-Anforderungen zu Beginn des Projektes definiert wurden. Deshalb wurde nach der dritten Iteration mit dem Auftraggeber eine Standortbestimmung durchgeführt, um die Prioritäten für die letzten fünf Wochen festzulegen. Während der Entwicklungsphase sind einige Fragen bezüglich der Benutzerführung aufgetaucht. Diese Fragen wurden im ursprünglichen UI-Konzept, welches während der Konzeptionierungsphase erstellt wurde, nur ungenügend behandelt. Deshalb war die Standortbestimmung eine gute Gelegenheit, verschiedenen Möglichkeiten mit dem Kunden zu besprechen und dadurch das UI-Konzept zu verfeinern. Neben den Usability- Verbesserungen wurde noch ein neuer Use Case definiert. Das Ziel des neuen Use Case ist, dass erfasste Leistungen bearbeitet werden können. In der vierten Iteration wurden neben dem neuen Use Case Leistung erfassen, vor allem Usability- Verbesserungen und Korrekturen für bereits erfasste Issues implementiert. Für die Navigation zwischen den Auftragslisten wurden Tabs eingeführt, damit der Benutzer blitzschnell zwischen den Auftragslisten wechseln kann. Zudem wurde eine zusätzliche Auftragsliste für favorisierte und undatierte Aufträge angefügt. In der fünften Iteration wurde nochmals ein Augenmerk auf die Usability gelegt, indem die im überarbeiteten UI-Konzept [SPEZ] definierten Features implementiert wurden. Die wichtigsten Issues wurden korrigiert, um so die Stabilität der Anwendung im Hinblick auf den Akzeptanztest zu verbessern. Während des Akzeptanztests wurden sämtliche Use Cases zusammen mit dem Auftraggeber durchgespielt. Verbesserungen wurden in der Issue-Tracking Liste aufgenommen. In der sechsten Iteration wurden nur noch kleinere Korrekturen am Projektsystem vorgenommen. Darunter fällt das Beheben der Mängel, welche beim Akzeptanztest [APROT] festgestellt wurden. Client/Server Applikation mit Android 5

24 Hochschule Luzern Bericht Projektvorgehen 2.1 Eingesetzte Werkzeuge In diesem Kapitel werden die Werkzeuge, welcher zur Projektunterstützung eingesetzt wurden, kurz erläutert Rollende Feinplanung und Projekt-Controlling Der Rahmenplan, welcher während der Initialisierungsphase erstellt wurde gab den groben Fahrplan für das Projekt vor. Damit die Tätigkeiten zwischen den einzelnen Phasen genauer eingeplant werde konnte, wurde eine rollende Feinplanung erstellt. Dies geschah jeweils zu Beginn einer Phase. Für jede Tätigkeit wurden der geschätzte Aufwand, die ausführende Person, sowie der Status in einem Excel-Dokument gepflegt. Sämtliche Tätigkeiten, welche bis zum Ende einer Phase nicht erledigt werden konnten, wurden in die nächste Phase übernommen. Die rollende Feinplanung wurde auch für das Projekt-Controlling eingesetzt. Das heisst jedes Projektmitglied hat seine geleisteten Stunden direkt einer eingeplanten Tätigkeit in der Feinplanung zugewiesen. Am Ende einer Phase wurden die aufgewendeten Stunden in die Grobplanung des Dokumentes [PPLAN] übertragen, um den Soll-/Ist-Vergleich über das gesamte Projekt aufzuzeigen Risikomanagement Im Projektplan [PPLAN] wurde ein Kapitel Risikomanagement geführt, in welchem die Projektrisiken erfasst wurden. Die bereits erfassten Risiken wurden wöchentlich geprüft und neubewertet. Zusätzlich wurden neue Risiken umgehend bei Erkennung in die Risikoliste aufgenommen. Die Risikoliste war die Grundlage um entscheiden zu können, für welche Teilprobleme Prototypen erstellt werden müssen Build- und Releasemanagement Das aufgezogene Build-Management [PPLAN] war der Grundstein für eine effiziente Entwicklung. Durch den automatisierten Erstellungsprozess werden repetitive Aufgaben automatisiert und der Entwickler erhält nach Abschluss des Erstellungsprozesses eine Rückmeldung, ob der neue Code mit den bestehenden Objekten interagiert. Damit lauffähige Releases regelmässig den Interessenten zugänglich gemacht werden konnten, wurde ein Release-Management Prozess [PPLAN] eingeführt. Stabile Releases mussten lediglich auf dem Continuous Integration Server als solche markiert werden. Dadurch wurden die betroffenen Artefakte automatisch für die Freigabe vorbereitet und auf einer öffentlichen Webseite publiziert. 6 Client/Server Applikation mit Android

25 Bericht Projektvorgehen Hochschule Luzern 2.2 Ist-/Soll-Vergleich Der ursprünglich eingeplante Aufwand von 720 Stunden wurde mit 826 geleisteten Stunden um 15 % überschritten. Die zusätzlich investierten Stunden können allerdings mit dem vorliegenden Projektergebnis gerechtfertigt werden. Der detaillierte Ist-/Soll-Vergleich der Projektaufwände in Bezug auf die geplanten Tätigkeiten ist im Projektplan [PPLAN] zu finden. In der nachfolgenden Tabelle 3 ist der konsolidierte Ist-/Soll- Vergleich auf der Stufe Phase dargestellt. SOLL Aufwand IST/SOLL Auswertung in [h] in [h] in [%] Projektinitialisierung Konzeptionierung Realisierung - Phase Realisierung - Phase Testing Verteilung und Einsatz Projektabschluss Total Tabelle 3: Soll-/Ist-Vergleich Die Auswertung hat ergeben, dass für die Phasen Projektinitialisierung, Realisierung Phase 2 und Projektabschluss mehr Zeit aufgewendet wurde als geplant. Im Gegensatz dazu wurden die einkalkulierten Stunden für Verteilung und Einsatz bis dato nicht benötigt, da das Deployment auf dem Server des Auftraggebers erst nach dem Abgabetermin der Bachelor Diplomarbeit erfolgen wird. In der Projektinitialisierung wurde vor allem für die Tätigkeiten Projekt-Management, Risikomanagement und Anforderungsanalyse mehr Zeit benötigt als geplant. Die Ursache dafür ist, dass zu Beginn des Projektes nicht die optimalen Projekt-Management Werkzeuge eingesetzt wurden. Die Optimierung der Werkzeuge beanspruchte viel Zeit. Der Aufwand für die Koordination der beteiligten Interessensgruppen, wurde ebenfalls unterschätzt. In der zweiten Realisierungsphase, in welcher die Umsetzung der Kundenanforderung im Vordergrund stand, wurden 78 Stunden mehr benötigt als ursprünglich eingeplant. Vor allem die Umsetzung des Android Benutzerschnittstelle hat mehr Zeit beansprucht als zu Beginn des Projektes geschätzt wurde. Einerseits ist dies auf die fehlende Erfahrung bezüglich Android UI-Design zurückzuführen. Anderseits wurden Stunden auf die Erstellung der Android UI-Komponente gebucht, welche auf die Entwicklung der Android Kommunikations-Komponente hätten gebucht werden können. Für die Entwicklung der Android Kommunikations- Komponente wurden nämlich nur 30 der 60 geplanten Stunden benötigt. Hauptgrund dafür ist, dass Änderungen an der Benutzerschnittstelle meist mit Änderungen an der Programmierschnittstelle VertecAPI verbunden waren. Somit war es nicht immer eindeutig, auf welche Position die geleisteten Stunden gebucht werden müssen. Client/Server Applikation mit Android 7

26 Hochschule Luzern Bericht Evaluation 3 Evaluation Die Evaluationsphase wurde genutzt, um wichtige Grundsatzentscheide im Zusammenhang mit dem Design der Software Architektur zu fällen. Als Resultat der Evaluation wird eine Komposition von Technologien und Protokollen erwartet, welche zu einer Softwarearchitektur modelliert und später in einem funktionalen Prototyp geprüft werden kann. In der nachfolgenden Tabelle (Tabelle 4) sind Einzelevaluationen der folgenden Bereiche aufgeführt Plattform Kommunikationstechnologie Sicherheit In einer ersten Phase wurde recherchiert, welche Technologien und Protokolle zur Umsetzung des angestrebten Systems beitragen könnten. Danach wurde ein morphologischer Kasten erstellt, in welchem die relevanten Technologien und Protokolle den entsprechenden Teilproblemen zugeordnet wurden. Durch das Kombinieren von potentiellen Lösungen für Teilprobleme sind verschiedene Lösungsvarianten entstanden. Abschliessend wurden die Lösungsvarianten auf ihre Machbarkeit geprüft und miteinander verglichen. Im Fokus steht dabei immer die Kundenanforderung. Es soll jene Lösung gefunden werden, welche die Bedürfnisse des Auftraggebers am besten befriedigen kann. 8 Client/Server Applikation mit Android

27 Bericht Evaluation Hochschule Luzern 1 Plattform Variante A Variante B Variante C Variante D 1.1 Vertec Mobile App (VMA) Der Kunde wünscht gemäss Anforderungsliste ausdrücklich eine Implementation auf einem Android Smartphone, ist aber nicht abgeneigt gegenüber Lösungen, welche auf anderen Plattformen laufen. Aus diesem Grund werden verschiedene Varianten geprüft. Android Applikation Die mobilen Endgeräte werden mit einer Java-basierten Android App bestückt. Vorteile: Reaktionsschnell Erlaubt Caching von Daten (Offline Betrieb möglich) Zugriff auf OS Funktionen (Kamera, GPS, usw.) Google Maps API ist wesentlich schneller als über Web Browser Nachteile: Plattformabhängigkeit Wartbarkeit eher schlecht Web App Die Applikation wird in Form einer webbasierten Anwendung bereitgestellt. Die Verteilung dieser Web App geschieht über eine App, welche die Webanwendung darstellt. Vorteile: Plattformunabhängig Zentral wart- und verwaltbar Nachteile: Kein Offline Betrieb möglich Kein Zugriff auf OS Funktionen (Kamera, GPS, usw.) Google Maps Zugriff reaktionsarm PhoneGap Ein Framework unterstützt die Entwicklung der Smartphone App. HTML5 Code wird von Phone Gap in eine native Smartphone App kompiliert. Vorteile: Viele gängige Plattformen unterstützt Nachteile: Kein Vorwissen über Technologie vorhanden Es kann nicht der volle Umfang der OS Funktionen genutzt werden Dauert lange bis neue Features verfügbar sind 1.2 Vertec Integration Service (VIS) Laut Kundenwunsch soll ein Integration Service eingesetzt werden, welcher die Schnittstelle zum Vertec ERP-System implementiert. Hier bietet sich eine breite Auswahl von nativen Applikationen bis zu Web Services. Java Applikation Der Integration Layer wird in Form einer Java Applikation betrieben..net Applikation Der Integration Layer wird in Form einer Microsoft.Net Applikation als Windows Service betrieben. Java Web Service Der Integration Layer wird als Java Web Service mit der Java API for XML Web Services (JAX-WS) implementiert. WCF Web Service Der Integration Layer wird als Windows Communication Foundation (WCF) Web Service implementiert. WCF bietet eine stark Serviceorientierte Architektur, welche die Integration von unterschiedlichen Plattformen zulässt. Vorteile: Bekannte Technologie Plattformunabhängig Nachteile: Keine Erfahrung im Zusammenhang mit Android Vorteile: Bekannte Technologie Nachteile: Plattformabhängig Runtime (Windows) Vorteile: Plattformunabhängig Nachteile: Fehlende Praxiserfahrung mit Java Web Services Vorteile: Plattformübergreifende Interoperabilität dank REST Sprachunabhängigkeit Komfortable Entwicklungsumgebung Homogenität: Der Vertec Hersteller plant das Frontend zukünftig in.net anzubieten. Nachteile: Plattformabhängig Runtime (Windows) Client/Server Applikation mit Android 9

28 Bericht Evaluation Hochschule Luzern 2 Kommunikationstechnologie 2.1 Kommunikation VIS-VMA Für die Kommunikation zwischen Vertec Integration Service und Vertec Mobile App muss ein geeignetes Protokoll gefunden werden. Hauptaugenmerk gilt es laut Kundenanforderung auf die Effizienz zu legen. XMPP Das Extensible Messaging and Presence Protocol (XMPP; früher bekannt als Jabber ) wurde für Instant Messanging entwickelt und wird in vielen bekannten Anwendungen eingesetzt (Facebook Chat, Whatsapp Messenger, Google GTalk). Peers kommunizieren indirekt über einen XMPP Server und erlangen so eine zeitliche wie auch örtliche Entkopplung. Zur Repräsentation der Informationen wird XML eingesetzt. Interfaces werden über XMPP-RPC angeboten. SOAP Zwischen VIS und VMA könnte Simple Object Access Protocol (SOAP) als Netzwerkprotokoll genutzt werden. SOAP nutzt XML zur Repräsentation von Informationen und baut auf HTTP und TCP auf. Vorausgesetzt wird ein SOAP Web Service. REST Alternativ zu SOAP könnte die Idee von Representational State Transfer (REST) verfolgt werden. REST ist zwar kein ratifiziertes Protokoll, gesinnt sich aber, grundlegende Web Technologien (HTTP) für den Austausch zwischen Peers zu verwenden. Für die Repräsentation der Informationen könnte JSON genutzt werden. Vorausgesetzt wird ein REST Web Service. Vorteile: Starke Entkopplung von Kommunikationspartnern Nachteile: Hohe Komplexität von XMPP- RPC War in vergangenem Projekt für viel Mehraufwand verantwortlich Vorteile: Bekannter Standard Bibliotheken verfügbar Nachteile: Grosser Overhead wegen XML Probleme mit SSL Unterstützung in ksoap2 für Android Vorteile: Breite Akzeptanz der eingesetzten Technologien Geringer Kommunikations- Overhead Schnelle Verarbeitung von JSON Nachrichten Nachteile: Fehlende Praxiserfahrung mit RESTful Services 2.2 Kommunikation VIS-VertecServer COM Schnittstelle Vertec bietet Zugriff auf das ERP- System über eine COM (Component Object Model) Schnittstelle an. Vorteile: Wird vom Auftraggeber bereits erfolgreich eingesetzt Gut dokumentierte Schnittstelle mit Anwendungsbeispielen Nachteile: Fehleranfälliges Kommunikationsmodell Umständliches Exception Handling Publish/Subscribe nicht möglich XML Schnittstelle Eine SOAP-ähnliche Schnittstelle wird angeboten, über welche HTTP GET und POST Requests Vorteile: Bessere Entkopplung zwischen VIS und dem Vertec Server Gut dokumentierte Schnittstelle mit Anwendungsbeispielen Nachteile: Kein offizieller Standard (Vertec Eigenentwicklung) Publish/Subscribe nicht möglich Client/Server Applikation mit Android 10

29 Bericht Evaluation Hochschule Luzern 3 Sicherheit 3.1 Transportsicherheit Transport Layer Security TLS (auch bekannt als Secure Socket Layer, kurz SSL) ist ein weitverbreitetes Verschlüsselungsprotokoll, welches häufig im Zusammenhang mit HTTPS verwendet wird. Das Protokoll arbeitet im TCP/IP Referenzmodell auf dem Transport Layer. Vorteile: Weitverbreiteter Industriestandard Vorhandene Prototypen Nachteile: Hohe Komplexität Message Layer Security Alternativ könnte jede Nachricht einzeln verschlüsselt werden. Nach TCP/IP Referenzmodell wäre diese Verschlüsselungsmethode auf dem Application Layer anzusiedeln. Das Verfahren könnte dem Prinzip nach PGP nahe kommen. Vorteile: Alternative zu komplexen SSL Implementationen Hohe Flexibilität beim Implementieren Nachteile: Starke Abhängigkeiten, da Sicherheit in Application Layer integriert wird Eigene Sicherheitsprotokolle sind grundsätzlich unsicher 3.2 Authentifizierung Die Auswahl der Authentifizierungsmethoden wird im Wesentlichen durch den Plattform Entscheid beeinflusst. Nach den Kundenanforderungen soll eine Methode gewählt werden, die nach aktuellem Wissenstand sicher ist, d.h. robust sind gegen gängige Angriffsarten. Basic Authentication Die Authentifizierungsmethode Basic Authentication wird in RFC 2617 beschrieben. Zur Authentifizierung eines Benutzers werden zwei Strings, Benutzername und Passwort, übermittelt und ausgewertet. Diese Authentifizierungsmethode gilt als sehr unsicher, wenn auf dem Transport Layer keine geeigneten Sicherheitsprotokolle zum Einsatz kommen. Digest Authentication Die Authentifizierungsmethode Digest Authentication wird in RFC 2617 beschrieben. Wie Basic Authentication versucht auch Digest Authentication Geheimnis zu verifizieren, welches beiden Kommunikationspartnern bekannt ist. Im Gegensatz zu Basic wird bei Digest das Passwort nicht in Klartext übertragen. Eine vom Authenticator gegebene Nonce wird zusammen mit Passwort und Benutzername in einen kryptographischen Hash (z.b. MD5) umgewandelt. NTLM NT LAN Manager ist ein von Microsoft entwickelter, proprietärer Authentifizierungsmechanismus. NTLM soll sichere sein als Digest Authentication, da die bereitgestellte Nonce vom Benutzernamen abhängig ist. [17] Kerberos Kerberos ist ein offener Standard für die Authentifizierung von Identitäten in unsicheren Netzwerken. Der Standard Kerberos V5 wurde in RFC 4120 ratifiziert. Zum Einsatz kommt ein zentraler Anmeldeserver (sog. Trusted Intermediary) welcher die Kennwörter der Clients verwaltet und Zugriffstickets für Ressourcen ausstellt. [18][19] Vorteile: Geringe Komplexität, sehr einfach einsetzbar Wird von den meisten Web Server unterstützt Nachteile: Passwörter werden in Klartext übermittelt Bedingt den Einsatz von TLS Vorteile: Geringe Komplexität, sehr einfach einsetzbar Sicherer als Basic Authentication Wird von den meisten Web Server unterstützt Nachteile: Bekannte Angriffsmethoden (Man-in-the-Middle Attacke) Vorteile: Proprietärer Standard Nachteile: Bekannte Sicherheitsprobleme Vorteile: Industriestandard Gilt als sehr sicher und effizient Nachteile: Benötigt ein Kerberos Authentifizierungssystem (z.b. Microsoft ActiveDirectory) Tabelle 4: Morphologischer Kasten zur Eruierung geeigneter Lösungsvarianten [5] Client/Server Applikation mit Android 11

30 Hochschule Luzern Bericht Evaluation 3.1 Lösungsvarianten Die nachfolgende Sektion bewertet die drei gefundenen Lösungsvarianten und vergleicht diese mit den gestellten Kundenforderungen. Aus Zeitgründen können nicht alle Lösungsvarianten weiterverfolgt werden. Die Lösungsvariante mit dem höchsten Erfüllungsgrad wird als Vorlage für einen funktionalen Prototypen verwendet Variante 1 Die erste Variante (blauer Pfad im morphologischen Kasten) sieht eine native Android Applikation vor, welche über XMPP mit einem Java-basierten Integration Service kommuniziert. Zwischen Android Applikation und Integration Service gibt es folglich keinen Technologiebruch. Beide Teilprojekte können in derselben Entwicklungsumgebung und auf derselben Programmiersprache (Java) entwickelt werden. Basic Authentication könnte über eine sichere SSL-Verbindung eingesetzt werden. Sämtliche aufgeführten Technologien wurden vom ausführenden Projektteam schon in irgendeiner Form eingesetzt, sodass sich das Risiko hinsichtlich dem Einsatz unbekannter Technologie reduziert. Erfahrungsgemäss bringt der Einsatz von verteilten, Nachrichten-basierten Kommunikationssystemen eine massive Erhöhung der Komplexität. Frühere Projekte haben gezeigt, dass XMPP-RPC zwar viel Flexibilität in der Kommunikation bringt, jedoch auch einige Kinderkrankheiten einschleust. Das Protokoll XMPP läuft zwar auf Android, hat jedoch Einschränkungen (Stichwort MultiUserChat), welche zwingend notwendig wären, um das Protokoll im vorliegenden Projekt sinnvoll einsetzen zu können. Grundsätzlich könnten für die Kommunikation auch TCP Sockets eingesetzt werden. Der Aufwand, diese mit geeigneten Methoden zu abstrahieren, wäre allerdings ziemlich gross. Insbesondere darum, weil die geplante Android Applikation nicht nur rudimentäre Befehle, sondern komplexe Datenstrukturen übertragen muss Variante 2 Ebenfalls eine native Android Applikation sieht Variante 2 vor. Im Unterschied zu Variante 1 wird hier aber die Integrationsschicht als Web Service angeboten. Microsoft hat mit Windows Communication Foundation (WCF) ein Framework ins Leben gerufen, welches das Erstellen von Service-orientierten Anwendungen auf Basis von Microsoft.Net unterstützt. WCF bietet eine breite Palette von Kommunikationstechnologien. So wird neben dem bekannten SOAP Standard auch JSON angeboten. Sogenannte RESTful WCF Services werden im Zusammenhang mit der Android Programmierung von der Community x-fach empfohlen, da diese weniger Overhead verursachen, als der XML-basierte SOAP Standard [7]. Da der Integration Service alle Anfragen unabhängig voneinander behandelt, skaliert dieser Service optimal. Eine grosse Anzahl Benutzer kann durch etablierte HTTP Load Balancing Methoden einfacher bedient werden, als dies bei RPC-basierten Ansätzen der Fall ist [8]. 12 Client/Server Applikation mit Android

31 Bericht Evaluation Hochschule Luzern Variante 3 In Variante 3 wurde die Option eines Web-basierten Android Clients geprüft. Ein Web Applikation hätte einige frappante Vorteile gegenüber nativen Applikationen Web Apps sind grundsätzlich plattformunabhängig. Es müsste lediglich eine Web View gebaut werden, welche die Web App auf dem Mobiltelefon anzeigt. Die Anwendung könnte mit kleinen Anpassungen auch mit herkömmlichen Browser genutzt werden. Änderungen an einer webbasierten Anwendung werden auf dem zentralen Web Server vorgenommen. Ein Neuausrollen der Anwendungen auf den Endgeräten wäre hinfällig. Die hohe Flexibilität hat aber ihren Preis. Die Anforderung bezüglich des Offline Modus, welcher vom Auftraggeber gewünscht wird, ist mit einer webbasierten Anwendung nur schwer lösbar. Zudem soll die Anwendung auf Systemfunktionen (Fotokamera, GPS, Telefon) zugreifen können, was bei webbasierten Anwendungen nur mit umständlichen Tricks möglich ist Entscheidung für Prototypen-Entwicklung Die Entscheidung, um den zu priorisierenden Prototypen fiel enorm knapp aus. Diese Tatsache findet ihre Begründung in der minutiös geführten Evaluation, welche bereits viele Technologien wegen potenziellen Unverträglichkeiten mit Anforderungen ausgeschlossen hatte. Schliesslich wurden die Lösungsvarianten mit einer Auswahl von Kriterien bewertet und miteinander verglichen. Client/Server Applikation mit Android 13

32 Bericht Evaluation Hochschule Luzern Kriterium Bewertung Kommentar Erfüllung der Anforderungen Wie gut können die Muss-Anforderungen erfüllt werden? Gibt es vorhersehbare Probleme? Effizienz und Effektivität Wie effizient und effektiv arbeitet die Lösung? Werden Ressourcen (CPU, Memory, Netzwerk) optimal genutzt? Variante 1 und Variante 2: Weil diese Varianten eine native Android App vorsehen, können die Vorstellungen seitens Auftraggeber abgedeckt werden. Variante 3: Der Kundenwunsch bezüglich Offline Modus ist mit Variante 3 nur schwer realisierbar. Der Kunde möchte nicht nur ein Caching der Webseite, sondern die Möglichkeit, dass Benutzer auch dann Daten erfassen können, wenn kein Netzzugang bereitsteht. Variante 1: Mit Data Transfer Objects (DTOs) könnte die Netzwerkauslastung optimal gestaltet werden. Demgegenüber stehen Transformationsoperationen, welche aber bei der erwarteten Datenmenge nicht ins Gewicht fallen. Variante 2: Dank dem Einsatz von etablierten Web Technologien (Http,Uri) und dem leichtgewichtigen Datenrepräsentationsformat JSON kann diese Variante einen effizienten und effektiven Informationsaustausch ermöglichen. Variante 3: Viele Operationen werden auf den Integrationsservice ausgelagert. So kann zwar auf dem Endgerät Akku gespart werden, es wird im Gegenzug aber mehr Bandbreite für das Übertragen der Webseite benötigt. Client/Server Applikation mit Android 14

33 Bericht Evaluation Hochschule Luzern Mehrnutzen und Wiederverwendung Kann die Lösung einen Mehrnutzen erzielen, um Wunsch-Anforderungen zu erfüllen? Besteht Potenzial für zukünftige Wiederverwendung der Lösung? Flexibilität Flexibilität punkto Entwicklung sowie Test- und Wartbarkeit. Können die einzelnen Teilsysteme sowie das Gesamtsystem sinnvoll entwickelt, getestet und erweitert werden? Variante 1: Diese Lösung ist relativ isoliert, was die Weiterverwendung durch andere Systeme anbelangt. Die Schnittstellen sind sehr technologiespezifisch und unterstützen nur bedingt eine Wiederverwendung. Variante 2: Ein REST-basierter Web Service könnte in Zukunft auch von anderen Systemen genutzt werden (z.b. für eine iphone/ipad Anwendung. Variante 3: Sowohl das webbasierte User Interface als auch der Web Service weist einen hohen Wiederverwendungsgrad auf. Einen Mehrnutzen entsteht insofern, als dass die Web Applikation mit geringem Aufwand auch auf anderen Plattformen eingesetzt werden kann. Variante 1: Minuspunkte gibt s bei dieser Lösung vor allem wegen dem relativ aufwändigen Kommunikationskonzept, welches den Einsatz eines zentralen XMPP Messanging Servers vorsieht. Die Erfahrung hat gezeigt, dass nur Systemtests sehr unflexibel durchführbar sind. Variante 2: Web Services sind grundsätzlich flexibel testbar, da diese stateless operieren. Die bereitgestellten Schnittstellen können mit Mock-Tests abgedeckt werden. Variante 3: Diese Lösung glänzt dank der zentralen Wartbarkeit und der einfachen Möglichkeit, Aktualisierungen vorzunehmen. Minuspunkte gibt s für fehlenden Zugriff auf Systemfunktionen (Kamera, GPS) seitens Smartphone. Client/Server Applikation mit Android 15

34 Bericht Evaluation Hochschule Luzern Beherrschbarkeit der Komplexität Wie hoch ist die geschätzte Gesamtkomplexität der Lösung? Gibt es Systemteile, welche noch nie in dieser Form eingesetzt wurden und deren Komplexität schwer einzuschätzen ist? Minimierung der Entwicklungsrisiken Generiert die Lösung hohe oder gar unkalkulierbare Risiken? Inwiefern ist es mit Prototypen möglich, diese Risiken zu minimieren? Variante 1: Am meisten Komplexität bringt diese Lösung mit der verwendeten Kommunikationstechnologie. Das Projektteam hat zwar bereits reichlich Erfahrung mit XMPP, weiss aber auch, dass das Protokoll zusammen mit RPC eher instabil ist. Variante 2: Die Komplexität dieser Lösung ist eher moderat. WCF ist ein bekanntes und gut dokumentiertes Framework. In Communities wird von vielen positiven Erfahrungen im Zusammenhang mit Android Applikationen berichtet. Variante 3: Da diese Lösung in vergangenen Projekten schon öfters erfolgreich eingesetzt wurde, besteht hier grosse Gewissheit, dass die Komplexität beherrschbar ist. Variante 1: Die eingesetzten Technologien sind bereit bekannt. Dennoch bestehen bei der Kommunikation grosse Risiken. Risikominimierend wirkt die Tatsache, dass nur eine Entwicklungssprache zum Einsatz kommt. Variante 2: Codebeispiele und WCF Design Artikel konnten dem Projektteam die Gewissheit geben, dass die in dieser Variante vorgeschlagene Kombination bereits praxiserprobt ist. Variante 3: Die Anforderungserfüllung ist ganz klar in Gefahr, da nicht bei allen Aspekten die Gewissheit besteht, dass diese durch die vorgeschlagene Technologie umgesetzt werden können. Client/Server Applikation mit Android 16

35 Bericht Evaluation Hochschule Luzern Sicherheit des Gesamtsystems Wie sicher ist das System in Bezug auf Authentifizierung und die Übertragung von Informationen? Ergebnis Variante 1 und Variante 2: Beide Varianten sehen Sicherheitslösungen für Authentifizierung und Übertragung vor, welche dem aktuellen Stand des Wissens entsprechen. Die an sich unsichere Basic Authentication wird mit einer SSL-Verschlüsselung geschützt. Dieses Vorgehen ist praxisgeprüft und wird von renommierten Marktteilnehmern empfohlen. Variante 3: Eine Verschlüsselung auf Nachrichten-Ebene ruft bestimmte Sicherheitsrisiken hervor (Replay Attacken), welche behandelt werden müssen. Die Recherchen haben keine bestehende Lösung ergeben, welche SOAP-Nachrichten paketweise Verschlüsseln. SSL hat leider mit SOAP auf Android Probleme verursacht. Die Evaluation führt zum Ergebnis, dass mit erster Priorität ein Prototyp von Lösungsvariante 2 erstellt wird. Diese Variante bietet ein guter Mix aus marktgängigen Technologien und moderaten Entwicklungsrisiken. Insbesondere die gute Unterstützung von WCF im Zusammenspiel mit REST und JSON hat der Variante 2 entscheidend Gewicht beigesteuert. Mit Variante 2 können die Android API Funktionen eingesetzt werden, was ganz im Sinne des Auftraggebers ist. Tabelle 5: Bewertung und Vergleich der Lösungsvarianten Client/Server Applikation mit Android 17

36 Hochschule Luzern Bericht Evaluation 3.2 Evaluation der Android Plattform In diesem Kapitel werden die unterschiedlichen Android Versionen verglichen, um die optimale Plattform für die Vertec Mobile Applikation zu wählen. In Abbildung 3 ist ersichtlich, dass gemäss einer Erhebung von Anfangs Mai 2012, die Android Version mit 63.9% am Häufigsten im Einsatz ist. Abbildung 3: Verteilung der Android Versionen (Erhebung von Anfang Mai 2012, [1]) Für Smartphones wurde die Versionen 2.x entwickelt, während die Versionen 3.x ausschliesslich für Tablets optimiert wurde (siehe [APPX]). Mit Android 4.0 wurde die Entwicklung zusammengeführt, um eine lauffähige Version sowohl für Smartphones als auch für Tablets auf den Markt zu bringen. Die Version 4.0 wurde Ende Oktober 2011 veröffentlicht und ist gemäss Aussage von Google auf jedem Android Smartphone und Tablet lauffähig, welches mindestens Android 2.3 unterstützt. Momentan ist das Update auf Android 4.0 für einige Android Smartphones (Samsung Galaxy S2, HTC Sensation) verfügbar. Für die Mobiletelefon Hersteller bedeutet es einen immensen Aufwand, ihre Systeme anzupassen, um Android 4.0 ausliefern zu können. Deshalb wird der Android 4.0 Update in naher Zukunft nicht für alle Android Smartphones zur Verfügung stehen. Deshalb ist wohl auch die Verbreitung von Android 4.0 mit 4.4% noch eher gering [4][11]. 18 Client/Server Applikation mit Android

37 Bericht Evaluation Hochschule Luzern In der nachfolgenden Tabelle sind die verschiedenen Auflösungen ersichtlich, welche von den Geräteherstellern angeboten werden. Die Bildschirmgrössen und die Dichte der Bildpunkte werden jeweils in vier Gruppen eingeteilt. Diese Gruppierung ermöglicht ein einfacheres Entwickeln und Gestalten von User Interfaces. Gemäss einer Erhebung von Ende Mai 2012 sind Geräte mit einer normalen Bildschirmgrösse und einer Dichte von 240 dpi mit 57.8% momentan am weitesten verbreitet. [2] Low Density Medium Density High Density High Density (120 dpi) (160 dpi) (240 dpi) (240 dpi) Small Screen 2.3% 2.4% 240x x640 Normal Screen 0.7% 26.2% 57.8% 0.9% 240x x x x x x x1024 Large Screen 0.3% 2% 480x x x x853 Extra Large 1024x % 1536x x1536 Screen 1024x x x x x1200 Tabelle 6: Übersicht der Android Bildschirmauflösungen und deren Verbreitung in Prozent (rot) [2] Aus der Evaluation der Android Plattform hat sich ergeben, dass die zu entwickelnde Android App für Android Version und für die Auflösungen der Kategorie Normal Screen und High Density ausgelegt wird. Die zu entwickelnde Applikation soll auch unter der Android 4.0 lauffähig sein, da neue Android Smartphones vorwiegend mit dieser Version ausgeliefert werden. Client/Server Applikation mit Android 19

38 Hochschule Luzern Bericht Projektergebnis 4 Projektergebnis Das Resultat dieses Projekts ist ein Softwaresystem, bestehend aus einer Android Applikation (Vertec Mobile App) sowie einem Integrationsdienst (Vertec Integration Service), welches nahtlos in das vom Auftraggeber bereitgestellte Vertec ERP-System integriert werden kann. 4.1 Umfang und Erfüllungsgrad Mit mehreren Systemtests und einem abschliessenden Akzeptanztest wurden die gestellten Anforderungen verifiziert und vom Auftraggeber abgenommen. Was ursprünglich als Prototyp in Auftrag gegeben wurde, endete in einem einsatzfähigen Produkt. Bis auf zwei Wunsch-Anforderungen konnten alle Ziele erreicht werden. Eines dieser beiden Wunsch-Anforderungen ist das Erfassen von Spesen, welches technisch identisch ist, wie das Erfassen von Leistungen. Deshalb sollte es für einen Softwareentwickler keine Hürde sein, diese Anforderung nachträglich einzubauen. Im Verlauf der Entwicklungen wurden zudem Features eingebaut, welche den Mehrwert der Anwendung massiv steigern konnten. Neben den funktionalen Anforderungen wurde auch eine Vielzahl nicht-funktionaler Anforderungen umgesetzt. So zum Beispiel die Implementierung des Offline-Modus mit einem eigenentwickelten Synchronisationsmechanismus, die effiziente Datenübertragung mit Hilfe von JSON oder etwa die Verschlüsselung der Transportschicht mit SSL (Abbildung 4). Abbildung 4: Unverschlüsselter Datenverkehr (links) und SSL-verschlüsselter Datenverkehr (rechts) Der quantitative Umfang dieser Projektarbeit ist beträchtlich. Die beiden Teilprojekte umfassen knapp Zeilen Source Code, welche innerhalb von rund drei Monaten entstanden sind. Abbildung 5 zeigt den Code- Umfang in Abhängigkeit der Zeit. Abbildung 5: Source Code Statistik 20 Client/Server Applikation mit Android

39 Bericht Projektergebnis Hochschule Luzern Die Qualität des Projektsystems wird mit über 90 automatisierten Tests sichergestellt. Abbildung 6 zeigt die kontinuierliche Zunahme der automatisierten Unit- und Integrationstests im Verlauf des Projekts. Der Funktionsumfang der Applikation nahm stetig zu, wodurch auch die automatisierten Tests erweitert wurden. Abbildung 6: Automatisierten Unit- und Integrationstests des VIS Es wurden zwei grössere Refactorings durchgeführt, um die Wartbarkeit des Codes zu verbessern. In einem der beiden Refactorings wurden systematisch Code Warnings behoben. Dank optimalem Tool Support konnten viele Ungereimtheiten ausgemerzt werden. Abbildung 7 (blaue Markierung) zeigt die Abnahme der Warnings im Teilprojekt VIS eindrücklich. Abbildung 7: Die Statistik der Code Inspektion visualisiert das Refactoring Bei gleichbleibendem Funktionsumfang konnten die Anzahl Code Zeilen in beiden Teilprojekten massiv reduziert werden. Dies wiederspiegelt sich u.a. auch in der Source Code Statistik (Abbildung 5). 4.2 Innovationsgehalt Die Anwendung macht auf den ersten Blick nicht den Eindruck einer weltumwerfenden Innovation. Trotzdem beinhaltet sie mehrere eindrückliche Features, welche den Innovationsgehalt des Gesamtprodukts positiv beeinflussen. Allem voran die Konstellation von Android und WCF kann als leistungsfähige und zukunftsorientierte Lösung betrachtet werden. Das vorliegende Projekt demonstriert eindrücklich, dass diese Kombination sehr flexibel einsetzbar ist. Der Integrationsdienst VIS könnte nun ohne nennenswerte Erweiterungen für die Integration von weiteren Anwendungen genutzt werden. Als besondere Innovation dieses Projekts kann der Push Notification Service für Android und WCF gesehen werden. Die Autoren dieses Dokuments sind überzeugt, dass es eine vergleichbare Lösung für Android im Zusammenspiel mit WCF zurzeit nicht gibt. Client/Server Applikation mit Android 21

40 Hochschule Luzern Bericht Projektergebnis 4.3 Aufgetretene Probleme Im Verlauf des Projekts sind einige Probleme aufgetreten, welche mit geeigneten Massnahmen eliminiert wurden. Nachfolgend ein kurzer Auszug: Zeitsynchronisation: Bei verteilten Systemen besteht das Problem, dass die Systeme nicht exakt die gleiche Zeit kennen oder in verschiedenen Zeitzonen stationiert sind. Im vorliegenden Projektsystem sind drei Teilsysteme VMA, VIS und das ERP-System involviert. Dementsprechend musste die Zeitdifferenz bei der Kommunikation dieser Systeme berücksichtigt und bestmöglich kompensiert werden. Serialisierung: Es war bereits zu Beginn des Projekts absehbar, dass die Serialisierung von Informationen ein zentrales Thema werden könnte. Erwartungsgemäss gab es einige Umwandlungsprobleme zwischen VMA, VIS und dem Vertec ERP-System. Die Probleme waren mannigfaltig. Beispielsweise musste für die Android App ein Date-Serializer geschrieben werden, welcher Datumswerte in ein JSON String umwandelt, sodass dieser vom WCF Service korrekt interpretiert werden kann. Null-Werte und Enumerationen mussten ebenfalls speziell behandelt werden. Ein sehr delikates Serialisierungsproblem versteckte sich im JSON-Serializer der DateTime Klasse in WCF. Das statische Property DateTime.MinValue trägt standardmässig die Zeitzone DateTimeKind.Unspecified, was beim Serialisieren Probleme verursachte. Die Methode ToUniversalTime() konnte das Problem nach stundenlangem Debuggen eliminieren. Systemtests mit Robotium: Um Systemtests zu automatisieren, wurde das Testframework Robotium eingesetzt. Robotium ist ein eindrückliches Hilfsmittel, hat aber bestimmte Einschränkungen, welche das Testen erheblich erschweren. Als kleines Beispiel kann der Fall mit den AsyncTasks erwähnt werden. AsyncTasks werden genutzt, um Benutzeraktionen in einem separaten Thread laufen zu lassen. Robotium (Release 3.2.1) konnte an diesen AsyncTasks keinen Gefallen finden. So musste mit Hilfe des Source Codes von android.os.asynctask eine neue Klasse, AsyncTask2, geschrieben werden, welche in den Systemtests schliesslich einwandfrei funktionierte. Entwicklungsinfrastruktur: Ein Standardrisiko, welches plötzlich zum ernsthaften Problem wurde, war die Entwicklungsinfrastruktur. Während der Realisierungsphase gab es regelmässig Ausfälle im SVN Repository. Auch die Entwicklungsserver bereiteten oft Bauchschmerzen. Vertec XML-Schnittstelle: Für viel Aufwand und teilweise Unverständnis hat die Vertec XML- Schnittstelle gesorgt. Das Erstellen von XML-Requests lief oft unter dem Motto Trial-Error. Einzelne Leerzeichen konnten bereits dafür sorgen, dass Anfragen nicht korrekt interpretiert wurden. So musste in VertecRequestBuilder auf VIS viel Sisyphusarbeit geleistet werden, um eine höhere Zuverlässigkeit zu erreichen. Projektplanung: Das eingesetzte Planungswerkzeug (Excel) hat das Projekt zwar stets auf der rechten Bahn gehalten. Es war jedoch oft sehr aufwändig, alle Aufwände an der korrekten Position zu verbuchen. Die Konsistenz des Projektplans konnten nur mit grossem Aufwand sichergestellt werden. 22 Client/Server Applikation mit Android

41 Bericht Projektergebnis Hochschule Luzern 4.4 Lessons Learned Wenn wir nochmals zum Anfang des Projektes zurückblättern, stellen wir fest, dass wir unsere Projektmethodik in diesem Projekt stark verändert und in vielen Punkten verbessert haben. Vieles was wir heute als selbstverständlich erachten, gehörte vor einigen Monaten schlicht noch nicht zum Umfang unseres Erfahrungsbereiches. Wir erlauben uns, nachfolgend einige Beispiele zu nennen. Im vorliegenden Projekt wurde ein Risikomanagement geführt. Im Vergleich zu früheren Projekten wurde der Prozess in diesem Projekt tatsächlich gelebt. Neue Risiken wurden laufend hinzugefügt und jeweils zum Wochenbeginn gemeinsam neu bewertet. Anhand der Höhe des Risikos wurden schliesslich die Prioritäten für den weiteren Verlauf des Projekts gesetzt. Ein weiteres Planungswerkzeug, welches in diesem Projekt zum Einsatz kam, waren die Feinplanungstabellen, welche jeweils die Planung bis zum nächsten Meilenstein enthielten. Diese haben uns geholfen, konkrete Arbeitspakete zu schnüren und diese dann auch im geplanten Zeitraum abzuarbeiten. Eher umständlich war das Abbuchen von Ist-Stunden auf der Grobplanungstabelle. Mehr Automatismus wäre hier wünschenswert. In einem kleineren Projektteam stört dies weniger, aber in einem grösseren Projekt wäre die Excel Tabelle sicher kein verlässliches Planungswerkzeug mehr. Ein Issue-Tracking System haben wir bislang noch in keinem Projekt verwendet. Das Aufsetzen der JIRA Instanz hat sich als Fehler herausgestellt! Unser Projekt war schlicht zu klein, um daraus einen Nutzen ziehen zu können. Als Alternative dazu entschieden wir uns, eine Excel Tabelle einzusetzen. Die Liste erwies einen guten Dienst. Es kostete nur wenig Zeit, neue Issues zu erfassen. Im Nachhinein hätten wir diese Liste regelmässiger mit der Feinplanung vergleichen müssen. Neu in diesem Projekt war der kontrollierte und automatisierte Release Prozess. Bereits in vergangenen Projekten wurden integrierte Build-Environments eingesetzt, um Software automatisch erstellen und testen zu lassen. Die automatisierte Freigabe von Software hingegen war Neuland. Der TeamCity Continuous Integration Server machte auch in dieser Disziplin eine gute Figur. Das Aufsetzen der Infrastruktur war enorm aufwändig. Man darf aber nicht vergessen, welchen enormen Dienst einem der automatisierte Release Prozess abnimmt. Apropos Continuous Integration: Erstmals wurden nicht nur Android Test Cases geschrieben, sondern diese auch in TeamCity automatisch getestet. Die grosse Unbekannte in diesem Projekt war Windows Communication Foundation. Obwohl wir schon bald nach dem Projektstart einen lauffähigen Prototyp zur Hand hatten, war die Unsicherheit ziemlich gross. Es war ein riskantes Unterfangen, eine noch so unbekannte Technologie für den ersten vertikalen Durchstich einzusetzen. Vielleicht war auch ein wenig Glück mit dabei, dass der Durchstich erfolgreich durchgeführt werden konnte. In einem neuen Projekt wäre es sicher empfehlenswert, mehr Zeit in Technologierecherchen und Prototyping zu investieren. It s never too late to change habits. Frei nach diesem Motto haben wir uns vorgenommen, das Android Java Projekt in der Entwicklungsumgebung Eclipse Indigo zu entwickeln. Dieser Entscheid hat sich bewährt, obwohl die Probanden dieser Diplomarbeit noch keine Erfahrung mit Eclipse hatten. In zukünftigen Projekten müsste man für einen solchen Wechsel jedoch mehr Zeit einplanen und dafür ein entsprechendes Risiko erfassen. Client/Server Applikation mit Android 23

42 Hochschule Luzern Bericht Diskussion 5 Diskussion Der Diskussionsteil dieses Berichts befasst sich mit zwei interessanten Themen. Der Auftraggeber hat sich in einer Besprechung gewünscht, ungefähre Nutzungszahlen in Bezug auf das erwartete Datenaufkommen zu erfahren. Diesem Wunsch wird im nachfolgenden Abschnitt nachgekommen. Zudem haben sich im Verlauf des Projekts einige Innovationen für mögliche Erweiterungen angesammelt. Diese werden gleich im Anschluss an die Beurteilung der Anwendungsleistung erläutert. 5.1 Beurteilung der Anwendungsleistung Damit der Auftraggeber abschätzen kann, wie viel Datenverkehr die VMA in einem bestimmten Nutzungsszenario generiert, wurde eine Leistungsmessung durchgeführt. Bereits zu Beginn der Arbeit wurde der Effizienz in Bezug auf die Bruttodatenmenge eine hohe Priorität beigemessen. Die nachfolgenden Abschnitte zeigen nun, welche Vorgänge mit welchen ungefähren Netzkosten verbunden sind Rahmenbedingungen der Leistungsmessung Um die Aussagekraft der Messung zu steigern, werden verbindliche Rahmenbedingungen geschaffen. Es wird versucht, ein möglichst realistisches Nutzungsszenario zu simulieren. Die Leistungsmessungen unterliegen folgenden Bedingungen: Benutzer Login o Benutzername: Galliker o Passwort: 1234 o Option Login merken aktiviert Aufträge o Textumfang: 20 Zeichen für Titel, 500 Zeichen für Beschreibung. o Aufträge haben immer ein Projekt aber keine Phase zugeordnet. Ein Projekt soll niemals zweimal vorkommen. o Aufträge haben immer einen Kundenkontakt zugewiesen. Ein Kontakt soll niemals zweimal vorkommen. Leistungen o Textumfang: 200 Zeichen. o Leistungen müssen auf ein Projekt erfasst werden, für welchen mindestens ein Auftrag besteht. Ansonsten werden sie nicht synchronisiert. o Aufwand im Stundenformat 00:00 ist definiert. Der effektive Wert ist irrelevant. Testumgebung o Die Messungen wurden in der Testumgebung dieses Projekts durchgeführt. Siehe [TPLAN]. o Das Testgerät war ein Samsung Nexus II mit Android 4.0. o Als Datenverbindung kam WLAN zum Einsatz. 24 Client/Server Applikation mit Android

43 Bericht Diskussion Hochschule Luzern Messergebnisse Als Messwerkzeug wurde die Netzwerkanalysesoftware WireShark eingesetzt. Gefiltert wurde nur auf Layer 3 (IP Source/Destination Filter 1 ). Die Tabelle 7 zeigt die einzelnen Vorgänge mit den jeweiligen Datenmengen, welche über das Netzwerk versendet wurden. Bei den Werten handelt es sich um Mittelwerte aus mehreren Messungen. In der Messung werden Bruttovolumina erfasst, d.h. inklusive Overhead durch TLS. Vorgang Datenvolumen Anzahl Pakete [in KB] Login Login mit Passwort und Benutzername 3 11 Auto Login mit SessionId 3 11 Synchronisation Lokal 2 keine Daten vorhanden. Keine Änderungen empfangen Lokal keine Daten vorhanden Je 5 Aufträge, Kunden, Projekte und Leistungen empfangen. Je 5 Aufträge, Kunden, Projekte und Leistungen lokal vorhanden, 6 21 ohne Änderung auf ERP System. Je 5 Aufträge, Kunden, Projekte und Leistungen lokal vorhanden, Leistung erstellt und den Auftrag desselben Projekts abgeschlossen, ohne Änderung auf ERP System. Push Benachrichtigung Initialisierung der Push-Verbindung h Wartezeit mit aktiver Push-Verbindung Auftrag per Push-Benachrichtigung empfangen Tabelle 7: Messergebnisse des Leistungstests Auswertung Bei einem Datenvolumen von 20 Kilobytes pro Synchronisation und 10 Synchronisationen täglich, würden pro Monat und Benutzer gerade mal 6MB 4 Datenverkehr verursacht. Das ist ein Datenvolumen, welches kein teures Datenabonnement voraussetzt. In der Schweiz wäre ein Datenpaket wie z.b. das Swisscom NATEL Data Start mit 500MB komplett ausreichend für den Betrieb einer VMA [12]. Die Messungen zeigen auch, dass sich der Einsatz von Push Notification in Bezug auf das Datenvolumen nur in bestimmten Anwendungsfällen lohnen könnte. Wenn von durchschnittlich 10 Synchronisationen pro Tag ausgegangen wird, reicht die zeitgesteuerte Synchronisation allemal. 1 WireShark IP Filter: (ip.dst == ) (ip.src == ) 2 Die Begriffe lokal und empfangen beziehen sich auf die Sichtweise der VMA. 3 Der erwähnte Auftrag wurde nicht direkt via Push empfangen. Push Notifications lösen lediglich eine Synchronisation aus. Siehe Systemspezifikation [SPEZ] MB/Tag * 10 Synchronisationen * 30 Tage = 6MB/Monat Client/Server Applikation mit Android 25

44 Hochschule Luzern Bericht Diskussion 5.2 Mögliche Erweiterungen Das entwickelte Projektsystem hat viel Potenzial für Erweiterungen. Die nachfolgenden Abschnitte geben Impulse zur Weiterentwicklung des vorliegenden Projektsystems Zusätzliche Vertec Objekte synchronisieren Bei der Konzipierung des Synchronisationsmechanismus wurde darauf geachtet, dass dieser für alle Vertec- Datenobjekt gleich funktioniert. Dabei spielt es keine Rolle, ob die VMA das zu synchronisierende Objekt gemäss den aktuellen Anforderungen bearbeiten oder nur einsehen können muss. Dies erlaubt es, mit minimalem Aufwand beliebige weiter Vertec-Datenobjekte von der VMA abzufragen oder zu bearbeiten. Dadurch könnte der Wunsch Use Case 7 Spesen erfassen (siehe [KUNAF]) mit geringem Aufwand analog zur Leistungserfassung implementiert werden Fotos für Aufträge erfassen Einer der Wunsch Use Cases, welcher aus zeitlichen Gründen nicht umgesetzt werden konnte, war UC9 Foto erfassen (siehe [KUNAF]). Diesem Use Case steht aus technischer Sicht nichts im Weg, realisiert zu werden. Die VMA müsste um einige Methoden erweitert werden, welche Bilddaten in einen Byte Array umwandelt und diesen in einem Http POST Request an den VIS sendet. Der VIS seinerseits müsste eine entsprechende Web-Schnittstelle implementieren, welche das Empfangen von Byte Streams ermöglicht. Empfangene Bilder würden vom VIS direkt in das Dateisystem des ERP-Servers verschoben und schliesslich mit dem Auftragsobjekt im ERP-System verknüpft Push Notification optimieren In der aktuellen Version von VMA und VIS ist es möglich, dass sich ein VMA Client beim VIS Updates vom Typ Task abonnieren kann. Neu erstellte oder geänderte Objekte werden via einen eigenentwickelten Push Notification Service an die VMA gesendet. Die umgekehrte Variante wenn Updates von der VMA ins Vertec ERP-System übertragen werden müssen basiert jedoch immer noch auf manueller und/oder zeitgesteuerter Synchronisation. Hier wäre es sinnvoll, ebenfalls ein Push-ähnlicher Dienst einzurichten. Die Datenbanklogik der VMA müsste eine neue Schnittstellenmethode bereitstellen, über welche sich die Synchronisationslogik auf Updates informieren lassen kann. Die Synchronisationslogik würde dann je nach Verfügbarkeit des Datennetzes selber entscheiden, ob und wann neu angelegte oder aktualisierte Objekte an den VIS übermittelt werden sollen. Der VIS müsste ebenfalls erweitert werden. Neue Methoden zum Aktualisieren von einzelnen Vertec Objekten müssten erstellt werden. Es wäre ineffizient, die bestehenden Update- Methoden zu verwenden, da diese für die Synchronisation von kompletten Datensets ausgelegt sind. Die bestehende Implementation der Synchronisationslogik würde jedoch bestehen bleiben. Sie würde weiterhin verwendet, um Initialsynchronisationen oder zeitlich gesteuerte Neusynchronisationen auszuführen Konfigurationsverteilung automatisieren Für den Betrieb sollte die VMA App erweitert werden, sodass diese alle wesentlichen Konfigurationsattribute direkt vom zuständigen Integration Service beziehen kann. Denn die Konfiguration von Android Applikation befindet sich standardmässig im Applikationspaket (APK) und wird zusammen mit den Binaries der Software ausgeliefert. Ein IT-Dienstleister müsste die Android Anwendung neu kompilieren und verteilen, um ein Konfigurationsattribut auf allen verwalteten Endgeräten zu verändern. Wenn die VMA in der Lage ist, die Konfigurationsattribute vom Integration Service zu beziehen, dann müsste vor einem Rollout der VMA lediglich die serviceurl zum Integration Service konfiguriert werden. Das ist ein vertretbarer Aufwand, welcher selbst unversierte Anwender nicht überfordern dürfte. 26 Client/Server Applikation mit Android

45 Bericht Diskussion Hochschule Luzern Für die Erweiterung müsste der Integration Service um eine neue Schnittstellenmethode und einen neuen Datentype erweitert werden, um Konfigurationsanfragen beantworten zu können Selbstsignierte Zertifikate verteilen Das Thema Sicherheitszertifikate wirft in Online Foren immer wieder kontroverse Diskussionen auf. Besonders dann, wenn es darum geht, sog. Self-Signed Certificates 5 in eine Android App zu integrieren [15]. Viele Entwickler scheinen sich mit der SSLSocketFactory-Option ALLOW_ALL_HOSTNAME_VERIFIER zu begnügen. Diese Option umgeht die Prüfung der Herkunft von SSL Zertifikaten. Es findet sehr wohl eine Verschlüsselung statt der Client weiss nur nicht, mit wem er eine sichere Verbindung aufgebaut hat. Das macht SSL nutzlos. Ein komfortabler Weg wäre die Integration eines CA-signierten Zertifikats. Dies ist jedoch oft mit beträchtlichen Kosten verbunden. Zudem ist die Gültigkeitsdauer von CA-signierten Zertifikaten oft stark beschränkt. Im Rahmen dieses Projekts wurden deshalb Bestrebungen unternommen, die Integration von Self-Signed Certificates zu vereinfachen. Es sind grundsätzlich mehrere Lösungswege denkbar. Nachfolgend werden zwei Ansätze erläutert: Variante 1, die Konfiguration entscheidet: Die Vertrauenswürdigkeit von Zertifikaten könnte direkt über die Konfiguration festgelegt werden. In der Konfiguration müsste lediglich der Fingerprint des Zertifikats definiert werden. Ein eigenentwickelter X509TrustManager würde prüfen, ob der Fingerprint eines empfangenen Zertifikats mit jenem der Konfiguration übereinstimmt. Einziger Nachteil dieser Lösung: Der vertrauenswürdige Fingerprint muss auf jeder VMA Installation manuell konfiguriert werden. Ob diese Aufgabe dem Benutzer anvertraut werden kann, bleibt zu bezweifeln. Variante 2, der Benutzer entscheidet: Nach dem Vorbild der Zertifikatwarnungen des Android Browsers (Abbildung 8) könnte die Android App umgebaut werden, sodass nichtvertrauenswürdige Zertifikate dem Benutzer gezeigt werden. Dieser soll selber entscheiden, ob er dem Zertifikat vertrauen will oder nicht. Akzeptierte Zertifikate würden in der Konfiguration vermerkt und beim nächsten Verbindungsaufbau automatisch als vertrauenswürdig erkannt. Abbildung 8: Zertifikatwarnung des Android Browsers Eine wichtige Quelle für diese Erweiterung könnte der Artikel in Quelle [16] sein. 5 Self-Signed Certificates sind Sicherheitszertifikate, welche selber erstellt und nicht von einer vertrauenswürdigen Certification Authority (z.b. VeriSign) signiert wurden. Client/Server Applikation mit Android 27

46 Hochschule Luzern Bericht Projektabschluss 6 Projektabschluss Wenige Stunden vor dem offiziellen Projektabschluss erlauben sich die Autoren dieser Diplomarbeit, ein persönliches Fazit zu ziehen. 6.1 Persönliches Fazit von Christoph Moser Zu Beginn des Projektes stand vor allem die Projektplanung im Vordergrund. Im vorangehenden Projektmodul, dem Informatikprojekt, hatten wir eine Forschungsaufgabe bearbeitet, bei welcher die Projektplanung geringere Priorität hatte. Deshalb konnten wir nicht auf die Planungswerkzeuge des Informatikprojektes zurückgreifen. Das Erstellen der Projektmanagement-Werkzeuge, sowie die laufende Verbesserung der Werkzeuge hat viel Zeit in Anspruch genommen. Dadurch konnten wir wichtige Erfahrungen sammeln, die wir in einem zukünftigen Projekt wieder verwendet können. Beispielsweise würde ich für ein zukünftiges Projekt, eine Projektablage einrichten, auf welche alle beteiligten Personen Zugriff haben. Somit müssten die überarbeiteten Dokumente nicht wöchentlich per verteilt werden. In den ersten Wochen haben wir viel Zeit in die Einrichtung der Infrastruktur investiert. Das Einrichten des Teamcity-Server für die beiden Plattformen.Net und Android nahm viel Zeit in Anspruch. Die Investition dieser Zeit hat sich rückblickend sicherlich gelohnt, denn während der Entwicklungsphase konnten wir dank des Teamcity-Servers effizient arbeiten. Die Erstellung von guten Testfällen erleichterte das Erkennen und Beheben von Fehlern. Während der Konzeptphase haben wir einen Mock-Up des User Interface erstellt. Dieser wurde letztendlich komplett überarbeitet und im vorliegenden Projektresultat sind nur noch wenige Teile vom ursprünglichen Konzept ersichtlich. Trotzdem vereinfachte der erstellte Mock-Up das Aufnehmen von Kundenanforderungen. Durch den UI Mock-Up erhielten alle beteiligten Parteien eine Vorstellung wie die Applikation funktionieren könnte. Mit dem erzielten Projektergebnis bin ich sehr zufrieden. Wir haben eine stabile Architektur erarbeitet, die es erlaubt, die funktionalen sowie die nicht-funktionalen Anforderungen zu erfüllen. Das Projektsystem ist so konzipiert, dass mit geringem Aufwand weitere Vertec Datenobjekte abgerufen oder erfasst werden können. Zusätzlich wurde die Benutzerfreundlichkeit der VMA während den letzten Wochen laufend verbessert, sodass der Benutzer mit Freude Leistungen erfassen wird. Das frühe Erstellen von Prototypen für die verschiedenen Teilprobleme war sicherlich ein wichtiges Puzzleteil, welches zum Erfolg geführt hat. Durch das Erstellen der Prototypen konnten wichtige Erkenntnisse für den Entwurf der Architektur gewonnen werden. Zudem konnten viele Codeabschnitte, welche in der Prototyping-Phase erstellt wurden, für das finale Produkt übernommen werden. Die Zusammenarbeit im Projektteam hat hervorragend funktioniert und dies obwohl wir nur zwei überschneidente Arbeitsblöcke pro Woche a 3 Stunden zur Verfügung hatten. Die spannende Projektaufgabe hat alle beteiligten Projektpartner motiviert. Die wertvollen Rückmeldungen von Auftraggeber und Betreuer haben dazu beigetragen, dass wir ein beindruckendes Projektergebnis erzielt haben. 28 Client/Server Applikation mit Android

47 Bericht Projektabschluss Hochschule Luzern 6.2 Persönliches Fazit von Thomas Galliker Die ersten Wochen haben wir uns eingehend mit Planungsaktivitäten beschäftigt. Diese Aufgaben kosteten viel Zeit und Geduld. Die Dokumentenvorlagen der vergangenen Projekte haben uns geholfen, den administrativen Aufwand wenigstens minim einzudämmen. Erstaunlich war dennoch, dass wir immer wieder Optimierungen an Planungswerkzeugen finden konnten. Nicht zuletzt dank den konstruktiven Rückmeldungen unseres Betreuers, Roland Gisler. Es war eine äusserst gute Idee, die Prototyping Phase parallel zur Planungsphase laufen zu lassen. Nach tagelanger Anforderungserhebung und Interpretation von Kundenaussagen kommt es mehr als gelegen, mal eine Idee in Code umzusetzen. Nach etwas mehr als vier Wochen hatten wir die wichtigsten Einzelprototypen für die Kommunikation zwischen Android Smartphone und Integration Service sowie zwischen Integration Service und Vertec ERP-System mit den dazugehörigen Tests fertiggestellt. Als Meisterleistung dieser Projektarbeit würde ich die entstandene Konstellation mit der Android App und dem WCF Service zusammen mit der ausgeklügelten Architektur rund um die VertecAPI bezeichnen. Vor 15 Wochen hätte ich nicht geglaubt, dass das Zusammenspiel einer Java-basierten Runtime Umgebung in ein.net-basierten Web Service so verblüffend gut harmonieren würde. Wir können von Glück sprechen, dass alles so einwandfrei geklappt hat. Von den unzähligen Prototypen die reibungslos zusammengeführt werden konnten, der stabilen Softwarearchitektur, den konstruktiven Gesprächen mit Auftraggeber und Betreuer bis hin zu diffizilen Programmierproblemen. Vielleicht war es auch der unbändige Ehrgeiz und das Wettbewerbsdenken, was uns während 15 Wochen zu Spitzenleistungen getrieben hat. Wir haben uns im Projektteam stets einwandfrei verstanden und konnten Aufgaben rasch und unkompliziert aufteilen. Die gegenseitige Unterstützung war gross. Da es nicht das erste Projekt war, welches wir zusammen in Angriff genommen haben, wussten wir um die Stärken und Schwächen unseres Gegenübers. Persönlich würde ich mich sehr freuen, wenn der Auftraggeber das Produkt tatsächlich ausrollen würde. Client/Server Applikation mit Android 29

48

49 Danksagung Nach tausenden von Zeilen Code, hunderten von Stunden Arbeit, einer Hand voll Dokumentation und einer gewaltigen Menge dazugewonnenem Knowhow, möchten sich die Probanden, Christoph Moser und Thomas Galliker, bei allen Personen bedanken, welche direkt oder indirekt dem guten Gelingen dieses Projekts beigesteuert haben. Allen voran sind dies der Auftraggeber, die Achermann & Partner GmbH mit Christoph und Georg Achermann, der Betreuer der Hochschule Luzern, Roland Gisler, sowie der externe Experte von Roche Diagnostics AG, Urs Gehrig.

50

51 Bericht Quellen Hochschule Luzern 7 Quellen Ref Quellenangabe / URL [1] Android Developers, Platform Versions, [2] Android Developers, Screen Sizes and Densities, [3] Android Developers, Supporting Multiple Screens, [4] areamobile.de, Android 4.0 Ice Cream Sandwich: Diese Smartphones und Tables erhalten es, Letzter Zugriff [5] [6] R. Fielding, Architectural Styles and the Design of Network-based Software Architectures, [7] MSDN, A Guide to Designing and Building RESTful Web Services with WCF [8] T. Bayer, REST Web Services, [9] Vertec, Vertec iphone App [10] Hochschule Luzern, HTAgil [11] Netzwelt.de, Android-Handys: Der grosse Update-Fahrplan [12] W3C Simple Object Access Protocol (SOAP) Specification, [13] Swisscom, NATEL Data Tarife, [14] Stackoverflow, DateTime.MinValue cannot be serialized, [15] Stackoverflow, Trusting all certificates using HttpClient over HTTPS, [16] Nikolay Elenkov, Using a Custom Certificate Trust Store on Android, Client/Server Applikation mit Android 31

52 Hochschule Luzern Bericht Quellen [17] MSDN: NT LAN Manager (NTLM) Authentication Protocol Specification, [18] IETF, The Kerberos Network Authentication Service (V5), [19] MIT, Kerberos: The Network Authentication Protocol, Client/Server Applikation mit Android

53

54

55 Hochschule Luzern Bachelor Diplomarbeit TA.BA_BAA+INF.F1201 Client/Server Applikation mit Android P r o j e k t p l a n Horw, 8. Juni 2012

56 Projekt Dokument Schule Modul Client/Server Applikation mit Android Projektplan Hochschule Luzern, TA.BA_BAA+INF.F1201 Projektteam Dozent Experte Letzte Änderung Galliker Thomas Studiengang Informatik (BB) Panorama 6123 Geiss Tel Roland Gisler Urs Gehrig 7. Juni 2012, 19:58:00 Uhr Moser Christoph Studiengang Informatik (VZ) Zugerbergstrasse Unterägeri Tel Änderungsprotokoll Version Datum Autor Beschreibung moc Initialversion von Vorlage erstellt moc Kapitel Technischer Prozess angefügt gat Überarbeitung gat Risikoliste überarbeitet und neu bewertet moc Feinplanung erstellt moc Feinplanung und Arbeitsjournal harmonisiert gat Risikoliste überarbeitet und neu bewertet gat Risikoliste überarbeitet und neu bewertet moc Meilensteinbericht für Konzeptionierungsphase erstellt gat Feinplanung ergänzt gat Meilensteinbericht und Risikoliste überarbeitet gat Projektpläne in Excel extrahiert gat Build- und Releasemanagement gat Risikoliste überarbeitet und neu bewertet, Meilensteinbericht moc Feinplanung bis zum Meilenstein 4 aktualisiert moc Aufgabenmanagement überarbeitet gat Meilensteinauswertung M moc Meilensteinbericht M4 erstellt gat/moc Allgemeine Korrekturen an Inhalt und Layout

57 Inhalt 1 Einleitung Ziel & Zweck dieses Dokuments Projektübersicht Begriffe & Abkürzungen Referenzen Projektorganisation Auftraggeber Projektbetreuung Auftragnehmer Rollen & Zuständigkeiten Planung Grobplanung Meilensteine Rahmenplan Arbeitspakete und Aufwandschätzung Feinplanung Arbeitspakete bis Meilenstein Arbeitspakete bis Meilenstein Arbeitspakete bis Meilenstein Arbeitspakete bis Meilenstein Arbeitspakete bis Meilenstein Meilensteinberichte Meilenstein Meilenstein Meilenstein Meilenstein Meilenstein Risikomanagement Build- und Releasemanagement Buildplanung Release Planung Assembly Versionisierung Qualitätsmanagement Konfigurationsmanagement Code Dokumentation Aufgabenmanagement Kontinuierliche Integration Quellen... 37

58 Abbildungsverzeichnis Abbildung 1: Übersicht der Stakeholder... 2 Abbildung 2: Gantt-Diagramm des Rahmenplans... 6 Tabellenverzeichnis Tabelle 1: Abkürzungserklärungen... 1 Tabelle 2: Referenzierte Dokumente... 1 Tabelle 3: Stakeholderliste... 2 Tabelle 4: Koordinaten des Auftraggebers... 3 Tabelle 5: Koordinaten des betreuenden Dozenten... 3 Tabelle 6: Koordinaten der Projektmitglieder... 3 Tabelle 7: Rollen & Zuständigkeiten... 4 Tabelle 8: Detaillierte Aufschlüsselung der Meilensteine... 5 Tabelle 9: Aufwandschätzung und Controlling... 8 Tabelle 10: Arbeitspakete bis Meilenstein Tabelle 11: Arbeitspakete bis Meilenstein Tabelle 12: Arbeitspakete bis Meilenstein Tabelle 13: Arbeitspakete bis Meilenstein Tabelle 14: Arbeitspakete bis Meilenstein Tabelle 15: Risikoplan mit identifizierten Risiken und geplanten Gegenmassnahmen Tabelle 16: Build Konfiguration VMA Tabelle 17: Build Konfiguration des VMA-Testprojekts Tabelle 18: Build Konfiguration VIS Tabelle 19: Liste der Dokumente, welche im Rahmen des Projekts entstanden sind... 35

59 Projektplan Einleitung Hochschule Luzern 1 Einleitung 1.1 Ziel & Zweck dieses Dokuments Dieser Projektplan ist das zentrale Dokument für das Projekt Management der Bachelor Diplomarbeit Client/Server Applikation mit Android. 1.2 Projektübersicht Das Projekt Client/Server Applikation mit Android umfasst die Erarbeitung eines Lösungskonzeptes sowie die Entwicklung eines Prototyps, welcher es erlaubt anhand einer Android Applikation auf das Vertec ERP- System zugreifen zu können. 1.3 Begriffe & Abkürzungen Abkürzung ERP gat GPS HSLU moc OCL SOAP SQLite TDD Vertec Erklärung Enterprise Resource Planning. Ein ERP-System wird in Unternehmen für die Ressourcenplanung eingesetzt Namenskürzel für Thomas Galliker Global Positioning System Hochschule Luzern Namenskürzel für Christoph Moser Object Contraint Language, eine UML-standardisierte Abfragesprache Simple Object Access Protocol, ein Internetstandard von W3C für die Repräsentation von Austauschinformationen zwischen Web Services [2] Dateibasiertes, leichtgewichtiges Datenbanksystem Test-Driven Development; ein Entwicklungsansatz, bei welchem Code zuerst in Testfällen entworfen wird, bevor er in die Applikation überführt wird Hersteller des in diesem Projekt verwendeten Vertec ERP-System Tabelle 1: Abkürzungserklärungen 1.4 Referenzen Ref [SPEZ] [TPLAN] [ISSTR] Tabelle 2: Dokument 03 Dokumentation \ BDA_Systemspezifikation.doc 03 Dokumentation \ BDA_Testplan.doc 04 Entwicklung \ 05 Feedback \ Issue_Tracking.xls Referenzierte Dokumente Client/Server Applikation mit Android 1

60 Hochschule Luzern Projektplan Projektorganisation 2 Projektorganisation Dieses Kapitel befasst sich mit den im Projekt involvierten Personen und deren Interessen. Es gilt die Interessen aller Interessensgruppen bestmöglich zu berücksichtigen. Vorrang haben Interessen, welche vom Sponsor des Projekts priorisiert werden. Abbildung 1 und Tabelle 3 zeigen eine Übersicht der Interessensgruppen, welche in irgendeiner Form am Projekt beteiligt sind. Die nachfolgenden Unterkapitel enthalten die Kontaktangaben der jeweiligen Personen. Achermann & Partner GmbH Projektteam Client / Server Applikation mit Android Hochschule Luzern Vertec AG Abbildung 1: Übersicht der Stakeholder Name Rolle Interessen Achermann & Partner GmbH Hochschule Luzern Roland Gisler Vertec AG Auftraggeber, Sponsor Projektbetreuung, STASS Hersteller des ERP-Systems Einsatzfähiges Softwareprodukt in der gewünschten Qualität und zum definierten Zeitpunkt ausgeliefert. Akquirieren von Neukunden durch die Smartphone Applikation. Als Steuerungsausschuss ist Herr Gisler für die Überprüfung von Prozess-Standards in den Bereichen des Projektmanagements und der Software Quality Assurance verantwortlich. Weiterverbreitung des ERP-Systems, Kundenbindung, finanzielle Anreize. Projektteam Auftragnehmer Erfolg, Akkreditierung der Abschlussarbeit. Tabelle 3: Stakeholderliste 2 Client/Server Applikation mit Android

61 Projektplan Projektorganisation Hochschule Luzern 2.1 Auftraggeber Name / Adresse Telefon Achermann & Partner GmbH Christoph Achermann Pilatusstrasse Luzern Achermann & Partner GmbH Georg Achermann Pilatusstrasse Luzern c@achermann-partner.ch g@achermann-partner.ch Tabelle 4: Koordinaten des Auftraggebers 2.2 Projektbetreuung Name / Adresse Telefon Roland Gisler Hochschule Luzern - T&A Technikumstrasse Horw roland.gisler@hslu.ch Tabelle 5: Koordinaten des betreuenden Dozenten 2.3 Auftragnehmer Name / Adresse Telefon Galliker Thomas Studiengang Informatik (BB) Panorama 6123 Geiss Moser Christoph Studiengang Informatik (VZ) Zugerbergstrasse Unterägeri thomas.galliker@stud.hslu.ch christoph.moser@stud.hslu.ch Tabelle 6: Koordinaten der Projektmitglieder Client/Server Applikation mit Android 3

62 Hochschule Luzern Projektplan Projektorganisation 2.4 Rollen & Zuständigkeiten Rolle Projektspezifisch Verantwortung Beschreibung / Aufgaben Projektmanagement moc - Organisiert und leitet die Sitzungen - Verteilt Aufgaben an Teammitglieder - Hält den Projektplan aktuell - Führt das Controlling (Ist-/Soll Auswertung) - Ist verantwortlich für die regelmässige Kommunikation mit den Interessensgruppen. Risikomanagement gat - Ist verantwortlich für die regelmässige Aktualisierung und Bewertung der Projektrisiken - Eskaliert im Fall von kritischen Risiken Dokumentenverwaltung gat - Erstellt das Layout aller Dokumente, setzt Standard für Dokumentationen durch - Behält den Überblick über die Dokumente - Kontrolliert Dokumentationsfortschritt Entwicklungsspezifisch Architektur gat - Verantwortlich für die Softwarearchitektur - Setzt Richtlinien zur Softwareentwicklung Testmanagement moc - Verantwortlich für Testplan und Testprotokolle - Ist für die Protokollierung der Testergebnisse zuständig - Vergleicht Testresultate mit Anforderungen Integration Vertec ERP-System moc - Ist zuständig für die Anbindung des ERP-Systems Android-spezifische Komponenten gat - Ist zuständig für die Entwicklung Android-spezifischer Softwarekomponenten Tabelle 7: Rollen & Zuständigkeiten 4 Client/Server Applikation mit Android

63 Projektplan Planung Hochschule Luzern 3 Planung 3.1 Grobplanung Projektstart Zwischenpräsentation Projektabgabe Schlusspräsentation Diplomausstellung Meilensteine Woche Inhalt 1 Projekt Kick-off ERP-System Vertec kennengelernt Erstellung Projektmanagementplan Identifizierung und Bewertung von Risiken Rahmenplan mit Meilensteinen erstellen Entwicklungsumgebung und Testsystem eingerichtet 2 Beschreibung der wichtigsten Geschäftsprozesse (Use Cases, Test Cases) Testplan mit Testphilosophie und wesentlichen Testaspekten Erster Entwurf einer Systemspezifikation mit Systemübersicht Definition der Arbeitspakete Feinplanung mit Aufwandschätzung für Arbeitspakete Detaillierte Aufgabenteilung 3 Softwarearchitektur definiert und dokumentiert Schnittstellen definiert Funktionale Prototypen (vertikal) sowie passende Test Cases erstellen Zwischenpräsentation 4 Proof of Concept: Vertikaler Prototyp lauffähig System Tests durchgeführt und protokolliert 5 Abgabe der Dokumentation und des Source Codes Poster erstellt Meilenstein M M M M M Präsentation der Diplomarbeit M Tabelle 8: Detaillierte Aufschlüsselung der Meilensteine Client/Server Applikation mit Android 5

64 Projektplan Planung Hochschule Luzern 3.3 Rahmenplan Abbildung 2: Gantt-Diagramm des Rahmenplans Client/Server Applikation mit Android 6

65 Projektplan Arbeitspakete und Aufwandschätzung Hochschule Luzern 4 Arbeitspakete und Aufwandschätzung Um die Gesamtkomplexität des zu entwickelnden Systems besser beherrschen zu können, wurden unter Beizug der Kundenanforderungen einzelne Projektschritte (sog. Arbeitspakete) definiert. Die Pakete stehen im Bezug zum Rahmenplan (Kapitel 3.3) und werden in Tabelle 9 zusätzlich mit einer Aufwandschätzung und -auswertung verbunden. Die Stundenangaben verstehen sich als Mannstunden. Um einen aussagekräftigen IST-SOLL Vergleich zu erlangen, wird wöchentlich der geleistete Aufwand pro Position erfasst und ausgewertet. Projektinitialisierung SOLL Aufwand IST Aufwand IST/SOLL Auswertung SW1 SW2 SW3 SW4 SW5 SW6 SW7 SW8 SW9 SW10 SW11 SW12 SW13 SW14 SW15 SW16 in [h] in [h] in [h] in [h] in [h] in [h] in [h] in [h] in [h] in [h] in [h] in [h] in [h] in [h] in [h] in [h] in [h] in [h] in [%] PM Projekt-Management P.1 Projekt Kick-Off P.2 Projektmanagementplan mit Grob- und Meilensteinplan P.3 Risikomanagement: Identifizierung und Bewertung von Risiken; laufende Beobachtung der Risiken P.4 Rahmenplan mit Aufwandschätzung P.5 Anforderungsanalyse Konzeptionierung K.1 Entwicklungs- und Testumgebung einrichten K.2 Schulung ERP-System K.3 Anwendungsfälle definieren K.4 Testplan erstellen K.5 Systemspezifikation: Architektur, Schichten, Schnittstellen K.6 Datenmodellierung Realisierung - Phase 1 R1.1 Entwickeln von einzelnen funktionalen Prototypen inkl. Tests 0 - Prototyp Lösungsvariante Prototyp Lösungsvariante R1.2 Isolierte Unit Tests mit Mock Objects R1.3 Integration der Prototypen (Vertikaler Durchstich) R1.4 Verifikation Softwarearchitektur (PoC) Realisierung - Phase 2 Implementierung der Kundenanforderungen 0 - R2.1 Vertec Integration Service R2.2 Security Library R2.3 Android Service R2.4 Android Communication Components Client/Server Applikation mit Android 7

66 Projektplan Arbeitspakete und Aufwandschätzung Hochschule Luzern - R2.5 Android UI Controls R2.6 Refactoring und Source Code Dokumentation Testing T.0 Machbarkeit von Tests abklären T.1 Testdaten vorbereiten T.2 Integrations- und Systemtests T.3 Feedback vom Kunden bearbeiten Verteilung und Einsatz V.1 Softwareverteilungskonzept V.2 Auslieferung des Produkts (Installation und Parametrisierung auf Kundensystem) Projektabschluss PA.1 Dokumentation fertigstellen PA.2 Vorbereitung und Durchführung der Präsentation PA.3 Reserve Tabelle 9: Aufwandschätzung und Controlling Client/Server Applikation mit Android 8

67 Projektplan Feinplanung Hochschule Luzern 5 Feinplanung Die Feinplanung stützt sich auf die im Rahmenplan erfassten Vorhaben. In diesem Projekt wurde die rollende Feinplanung jeweils bis zum nächsten Meilenstein vorgenommen. Die einzelnen Arbeitspakete wurden so dimensioniert, dass sie zwischen 10 und 20 Personenstunden umfasst haben. 5.1 Arbeitspakete bis Meilenstein 1 Ref AP Projektinitialisierung Zuständig Status Soll- Ist- SW1 SW2 SW3 Aufwand Aufwand in [h] in [h] in [h] in [h] in [h] gat moc gat moc gat moc P.1 Projekt Kick-Off gat / moc Erledigt P.2 Projektmanagementplan mit Grob- und Meilensteinplan gat / moc Erledigt P.3 Risikomanagement: Identifizierung und Bewertung von Risiken; laufende Beobachtung gat / moc Erledigt der Risiken P.4 Rahmenplan mit Aufwandschätzung gat Erledigt P.5 Anforderungsanalyse moc Erledigt K.1 Weiterverfolgen TeamCity für Continous Integration konfigurieren gat bis M T.0 Prototyp Android Tests moc Erledigt K.2 ERP-System Schulung / Recherchen gat / moc Erledigt R1.1 Prototyp WCF Service mit Android gat Erledigt UI-Konzept erstellen moc Erledigt Tabelle 10: Arbeitspakete bis Meilenstein 1 110h 116h Client/Server Applikation mit Android 9

68 Projektplan Feinplanung Hochschule Luzern 5.2 Arbeitspakete bis Meilenstein 2 Soll- Ist- SW4 SW5 SW6 Ref Projektinitialisierung Zuständig Status Aufwand Aufwand in [h] in [h] in [h] AP in [h] in [h] gat moc gat moc gat moc K.1 TeamCity für Continous Integration konfigurieren gat Erledigt K.1 Code Metriken (Duplicate Code, Code Complexity) auf TeamCity erweitern gat Erledigt K.1 Produktive BDA Projekte für Andorid und.net erstellen und in TeamCity integrieren gat Erledigt K.3 Kundenanforderung fertigstellen moc Erledigt K.4 Testplan erstellen gat Erledigt K.5 Synchronisation-Konzept erstellen moc Weiterverfolgen bis M3 K.5 Schnittstellen definieren gat Erledigt K.6 Datenmodellierung inklusive Recherchen ORMLite Framework gat Erledigt R1.1 Weiterverfolgen VertecConnector (.Net) erstellen (inklusive OCL moc Queries für alle Use Cases) bis M R1.1 Vertec XML in.net Objekt wandeln moc Erledigt R1.1 Login Prototyp (Android + Session Handling) gat Erledigt R1.1 Testmessung für Push/Pull Synchronisationsszenarien gat Erledigt Client/Server Applikation mit Android 10

69 Projektplan Feinplanung Hochschule Luzern R1.2 NMock Test für VertecConnector, sodass ohne ERP-System getestet werden kann. moc Erledigt R1.2 Mock-Tests für Android REST Client (VertecHttpClient) gat Erledigt R1.3 Prototypen (Android REST Client und WCF Service mit VertecConnector und SessionManagement) gat Erledigt zusammenführen R1.4 Review der Softwarearchitektur gat / moc Erledigt R2.1 EventLog Integration für WCF Service gat Erledigt T.0 Machbarkeit von Unit Tests für WCF Services gat Erledigt PM Projektmanagement (Ist-/Soll Planung, Risikoanalyse, Besprechungen) gat / moc Erledigt PM Prozesse und Standards zur Qualitätssicherung dokumentiert gat Erledigt Tabelle 11: Arbeitspakete bis Meilenstein 2 152h 181h Client/Server Applikation mit Android 11

70 Projektplan Feinplanung Hochschule Luzern 5.3 Arbeitspakete bis Meilenstein 3 Ref AP Projektinitialisierung Zuständig Status Soll- Aufwand Ist- Aufwand SW7 in [h] SW8 in [h] SW9 in [h] SW10 in [h] in [h] in [h] gat moc gat moc gat moc gat moc R2.1 Vertec XML in.net Objekt wandeln für die weiteren Objekte. moc Erledigt R2.1 VertecConnector um alle benötigten Objekttypen erweitern moc Erledigt K.5 Synchronisation-Konzept erstellen moc Erledigt R2.1 Synchronisationslogik in VertecConnector implementieren moc Erledigt R2.1 Mock Tests für VertecConnector erweitern moc Erledigt R2.1 Serialisierungsproblem mit DateTime beheben gat Erledigt K1 Release Management in TeamCity CI Umgebung integrieren gat Erledigt K5 Schnittstellen der Prototypen in produktive Projekte übernehmen und aktualisieren gat Erledigt K5 Dokumentation der Schnittstellen aktualisieren gat Weiterverfolgen bis M4 K5 Dokumentation der Design Entscheide aktualisieren gat /moc Weiterverfolgen bis M4 R1.3 Integration ORMLite Prototyp in produktives Android Projekt gat Erledigt R2.2 SSL auf IIS einrichten und Zertifikat ausstellen gat Erledigt Client/Server Applikation mit Android 12

71 Projektplan Feinplanung Hochschule Luzern R2.2 SSL Erweiterung für HttpClient (Android) gat Erledigt R2.2 SSL Erweiterung für WCF Service gat Erledigt R2.3 Android Data Service implementieren gat Erledigt R2.4 Android Sync Service implementieren moc Erledigt R2.5 Android UI für Tasks erstellen gat In Arbeit R2.5 Android UI für Auftragsdetails und Kundendaten erstellen gat Erledigt R2.5 Android UI für Leistungserfassung erstellen moc Erledigt R2.5 Internationalisierung der Android Benutzeroberfläche integrieren. gat Erledigt R2.5 Android Preferences in VMA integrieren gat Erledigt R2.6 Refactoring und Source Code Dokumentation gat /moc In Arbeit T.2 Android Systemtests für sämtliche Use Cases erstellen gat Weiterverfolgen bis M4 PM Projektmanagement (Ist-/Soll Planung, Risikoanalyse, Besprechungen) moc / gat Erledigt Weiterverfolgen PM Zwischenpräsentation vorbereiten moc / gat bis M4 Tabelle 12: Arbeitspakete bis Meilenstein 3 221h 186h Client/Server Applikation mit Android 13

72 Projektplan Feinplanung Hochschule Luzern 5.4 Arbeitspakete bis Meilenstein 4 Soll- Ist- SW11 SW12 Ref Projektinitialisierung Zuständig Status Aufwand Aufwand in [h] in [h] AP in [h] in [h] gat moc gat moc R2.5 UseCase 06 "Kunde anrufen" implementieren gat Erledigt R2.5 UseCase 08 "Aufzeigen des Anfahrtsweges" implementieren gat Erledigt R2.4 Activity für Visualisieren der erfassten Services implementieren moc Erledigt R2.1 Vertec Requests aus Konfiguration-File lesen moc Erledigt R2.5 Usability Konzept überarbeiten und Quick wins implementieren gat Erledigt R2.5 Exception Handling und Logging vereinheitlichen gat Erledigt R2.6 Responsiveness in Android UI optimieren gat Erledigt R2.6 Refactoring und Stabilisierung gat / moc Erledigt T.2 Android Systemtests für sämtliche Use Cases erstellen -> Service erfassen, Services anzeigen gat Erledigt T.2 Systemtests durchführen und auswerten moc Erledigt T.3 Kunden-Feedback bezüglich Tests von Release bearbeiten gat / moc Erledigt K5 Dokumentation der Schnittstellen aktualisieren gat /moc Weiterverfolgen bis M5 K5 Dokumentation der Design Entscheide aktualisieren gat /moc Erledigt PM Projektmanagement (Ist-/Soll Planung, Risikoanalyse, Besprechungen) gat /moc Erledigt PA.2 Zwischenpräsentation vorbereiten gat /moc Erledigt Tabelle 13: Arbeitspakete bis Meilenstein 4 80h 83h Client/Server Applikation mit Android 14

73 Projektplan Feinplanung Hochschule Luzern 5.5 Arbeitspakete bis Meilenstein 5 Ist- Soll- SW13 SW14 SW15 SW16 Ref Aufwand Projektinitialisierung Zuständig Status Aufwand in [h] in [h] in [h] in [h] AP in [h] in [h] gat moc gat moc gat moc gat moc R2.5 UseCase 11 "bestehende Leistung bearbeiten" implementieren moc Erledigt R2.1 Synchronisation ändern (Create, Update, Read) zusammenführen moc Erledigt R2.1 Synchronisationsfehler beheben (Issues 2.2, 16, 21, 23, 20) moc Erledigt T.3 Usability optimieren (Issue 12.1, 35) moc Erledigt T.3 OCL Request anpassen & testen, sodass Task ohne Bearbeiter zurückgelifert werden. (Issue 34) moc Erledigt T.2 Systemtest für Iteration 4 durchführen gat Erledigt V.1 Softwareverteilungskonzept erstellen gat Erledigt T.2 Systemtest für Iteration 5 durchführen moc Erledigt T.2 Akzeptanztest mit Kunden durchführen gat / moc Erledigt R2.2 SSL Zertifikate für produktiven Betrieb (Issue 3) gat Erledigt R2.5 Darstellung der Service Liste ändern (Issue 5) gat Erledigt R2.5 Tab Indicator für "Serivces, Tasks, Favourites" (Issue 6) gat Erledigt R2.5 Undatierte Aufträge unter neuem Tab anzeigen (Issue 25) gat Erledigt R2.5 Zeitzone für neue Services überprüfen (Issue 9) gat Erledigt R2.5 GPS Location Fix (Issue 17) gat Erledigt T.2 Login Problem: Error 401 nach Login beheben (Issue 24) gat Erledigt Client/Server Applikation mit Android 15

74 Projektplan Feinplanung Hochschule Luzern R2.5 Neue/aktualisierte Tasks und Services optisch kennzeichnen (Issue 26) gat Erledigt R2.5 Preferences Activity mit allen konfigurierbaren Attributen ergänzen (Issue 32) gat Erledigt R2.3 Unterdrückung des Initialsync (Issue 33) gat Erledigt R2.5 Support-Informationen in InfoActivity anzeigen (Issue 39) gat Erledigt T.2/.3 Reserve für Feedback aus Quality/Acceptance Tests gat / moc Erledigt K.5 Dokumentation der Schnittstellen aktualisieren gat /moc Erledigt PA.1 Dokumentation, Layout und Korrekturen gat / moc Erledigt PA.1 Bachelordiplomarbeit (3 Exemplare) drucken und binden gat / moc Erledigt PA.1 CD's erstellen mit SourceCode und Dokumentation gat / moc Erledigt PA.2 Weiterverfolgen Abschlusspräsentation und Plakat/WebAbstract für Diplomausstellung erstellen gat / moc bis M PM Projektmanagement (Ist-/Soll Planung, Risikoanalyse, Besprechungen) gat / moc Erledigt Tabelle 14: Arbeitspakete bis Meilenstein 5 197h 260h Client/Server Applikation mit Android 16

75 Projektplan Meilensteinberichte Hochschule Luzern 6 Meilensteinberichte 6.1 Meilenstein 1 Periode: Projektphase: Soll/Ist-Vergleich Zeitplan Projektinitialisierung 110h / 116h Aufwandindikator 116h = 16.1% Projektfortschritt Bericht: 0 von 6 (Muss Use Cases realisiert) 0 von 4 (Wunsch Use Cases realisiert) Die Gruppe ist organisiert, die Rollen wurden verteilt. Während der ersten Periode wurden die Dokumente (Projektplan, Systemspezifikation, Bericht, Kundenanforderungen) erstellt, welche für den weiteren Verlauf des Projektes benötigt werden. Es wurden die Ziele der Meilensteine definiert und damit den Rahmenplan für das Projekt abgesteckt. In der zweiten Woche fand das erste Meeting mit dem Auftraggeber, der Achermann & Partner GmbH, statt. Bei diesem Meeting erhielten wir eine Einführung ins ERP-System Vertec und konnten die groben Anforderungen für die Client/Server Applikation mit Android eruieren. Zusätzlich zu den geplanten Tätigkeiten für diese Periode, konnte bereits mit der Formulierung der Geschäftsprozesse sowie der Evaluation der Systemarchitektur gestartet werden. Client/Server Applikation mit Android 17

76 Hochschule Luzern Projektplan Meilensteinberichte Ergebnisse der letzten Arbeitsphase Ziele Resultat Bemerkung Projekt Kick-off ERP-System Vertec kennengelernt Erstellung Projektmanagementplan Rahmenplan mit Meilensteinen erstellen Identifizierung und Bewertung von Risiken Entwicklungsumgebung und Testsystem eingerichtet Siehe Kapitel 7 auf Seite 27 dieses Dokuments. Es gibt noch einige Probleme mit dem CI Server. Testprojekte für.net (mit Nunit und Nmock resp. Moq) laufen noch nicht. Android Testprojekte brauchen noch eine Ant Konfiguration. Ziele der nächsten Arbeitsphase Entwicklungsumgebung und Testsystem eingerichtet Testplan mit Testphilosophie und wesentlichen Testaspekten Erster Entwurf einer Systemspezifikation mit Systemübersicht Definition der Arbeitspakete Feinplanung mit Aufwandschätzung für Arbeitspakete Detaillierte Aufgabenteilung 18 Client/Server Applikation mit Android

77 Projektplan Meilensteinberichte Hochschule Luzern 6.2 Meilenstein 2 Periode: Projektphase: Soll/Ist-Vergleich Zeitplan Konzeptionierung 152h / 181h Aufwandindikator 297h = 41.3% Projektfortschritt Bericht: 1 von 6 (Muss Use Cases realisiert) 0 von 4 (Wunsch Use Cases realisiert) In der Konzeptionierungsphase war das primäre Ziel, die Architektur für das Projektsystem zu definieren und in der Systemspezifikation festzuhalten. Die Architektur wurde anhand von verschiedenen Prototypen (VertecConnector, WCF Service, AndroidORMLite, AndroidRESTClient) verifiziert. Durch das Verbinden der einzelnen Prototypen gelang ein erster Durchstich für den Use Case 01 Login. Die Arbeitspakete wurden im Kapitel 4 definiert und geschätzt. Zusätzlich wurde eine rollende Feinplanung eingeführt, in welcher die Tätigkeiten von Meilenstein zu Meilenstein genauer definiert werden. Des Weitern wurden die Kundenanforderungen mit dem Auftraggeber geprüft und überarbeitet. Dabei wurden sechs Use Cases (UC-01 bis UC- 06) als besonders wichtig definiert. Diese Anwendungsfälle gilt es in der kommenden Projektphase in den produktiven Softwareprojekten umzusetzen. Client/Server Applikation mit Android 19

78 Hochschule Luzern Projektplan Meilensteinberichte Ergebnisse der letzten Arbeitsphase Ziele Resultat Bemerkung Entwicklungsumgebung und Testsystem eingerichtet Testplan mit Testphilosophie und wesentlichen Testaspekten Erster Entwurf einer Systemspezifikation mit Systemübersicht Definition der Arbeitspakete Feinplanung mit Aufwandschätzung für Arbeitspakete Detaillierte Aufgabenteilung Kundenanforderung überarbeitet VertecConnector Synchronisation-Konzept Die Kundenanforderung wurde zusammen mit dem Auftraggeber geprüft und überarbeitet. Der VertecConnector unterstützt in der aktuellen Version das Login sowie das Abfragen von Aufträgen. In der nächsten Phase soll der VertecConnector erweitert werden, damit die restlichen Objekttypen (Kunden, Projekte, Phasen, ServiceTyp) abgefragt werden können. Das Synchronisationskonzept wurde erstellt und dokumentiert, muss allerdings noch anhand eines Prototyps verifiziert werden. Ziele der nächsten Arbeitsphase Softwarearchitektur definiert und dokumentiert Schnittstellen definiert und dokumentiert Use Cases, welche Daten vom ERP-System empfangen resp. zurückschreiben rudimentär implementieren. Dies betrifft insbesondere die Use Cases UC-02 bis UC-05 Funktionale Prototypen (vertikal) sowie entsprechende Test Cases erstellen Zwischenpräsentation am 11.Mai Client/Server Applikation mit Android

79 Projektplan Meilensteinberichte Hochschule Luzern 6.3 Meilenstein 3 Periode: Projektphase: Soll/Ist-Vergleich Zeitplan Realisierung 221h / 186h Aufwandindikator 483h = 67% Projektfortschritt Bericht: 5 von 6 (Muss Use Cases realisiert) 1 von 4 (Wunsch Use Cases realisiert) Nach dem ersten Durchstich während der Konzeptionierungsphase wurden Schritt für Schritt alle Prototypen in die produktiven Softwareprojekte überführt. Da bereits während dem Prototyping der TDD-Ansatz verfolgt wurde, konnten auch die produktiven Projekte von Beginn weg eine Code Coverage zwischen 85 und 90% aufweisen. Die als besonders wichtig definierten Use Cases wurden in der vergangenen Projektphase erstellt und getestet. Als grösste Schwierigkeiten können sicherlich die Serialisierungsprobleme zwischen dem WCF Service (VIS) und der Android App (VMA) genannt werden. Es sei an dieser Stelle auch erwähnt, dass die bereits implementierten Use Cases technisch einwandfrei funktionieren, jedoch punkto Usability teils grossen Nachholbedarf haben. Diese Pendenz wurde für die nächste Phase aufgenommen. Ein Build- und Releasemanagement wurde organisiert und in die CI Umgebung integriert. Sie soll uns dabei helfen, stabile Releases kontrolliert an Testpersonen freizugeben und nützliches Feedback einzuholen. Client/Server Applikation mit Android 21

80 Hochschule Luzern Projektplan Meilensteinberichte Ergebnisse der letzten Arbeitsphase Ziele Resultat Bemerkung Softwarearchitektur definiert und dokumentiert Schnittstellen definiert und dokumentiert Use Cases, welche Daten vom ERP- System empfangen resp. zurückschreiben rudimentär implementieren. Dies betrifft insbesondere die Use Cases UC-02 bis UC-05 Funktionale Prototypen (vertikal) sowie entsprechende Test Cases erstellen Zwischenpräsentation am 11. Mai 2012 Termin war zum Planungszeitpunkt nicht definiert Softwarearchitektur definiert und dokumentiert Ziele der nächsten Arbeitsphase Implementieren der Use Cases UC6 und UC8 Optimieren der Usability und der Stabilität Rückmeldung zu Test Release von Auftraggeber System Tests für Use Cases vorbereiten Zwischenpräsentation am 11. Mai Client/Server Applikation mit Android

81 Projektplan Meilensteinberichte Hochschule Luzern 6.4 Meilenstein 4 Periode: Projektphase: Soll/Ist-Vergleich Zeitplan Realisierung 80h / 76h Aufwandindikator 559h = 77.6% Projektfortschritt Bericht: 6 von 7 (Muss Use Cases realisiert) 2 von 4 (Wunsch Use Cases realisiert) In dieser kurzen Phase zwischen Meilenstein 3 und Meilenstein 4 ging es darum, die Applikation und Dokumentation auf einen guten Stand für die Zwischenpräsentation zu bringen. Als zusätzliche Funktionalitäten wurden die Use Cases UC6 und UC8 implementiert. Diese Use Cases unterstützen den Benutzer mit nativen Android Funktionalitäten, wie beispielsweise das Ermitteln der Wegstrecke zum nächsten Kunden. Mit dem Auftraggeber, der Achermann & Partner Gmbh, wurde eine Standortbestimmung durchgeführt, um den aktuellen Stand der Entwicklungen zu präsentieren und die Prioritäten für die letzten vier Wochen zu setzen. Der Auftraggeber ist mit dem derzeitigen Stand der Arbeit sehr zufrieden. Für die letzte Phase stehen vor allem die Optimierung der Usability sowie die Stabilisierung des Systems im Vordergrund. Zusätzlich wurde ein neuer Use Case für das Bearbeiten einer erfassten Leistung definiert. Bei der Zwischenpräsentation am Freitag wurde der aktuelle Stand des Projektes dem Betreuer und dem Experte präsentiert. Das Feedback für die Zwischenpräsentation war mehrheitlich positiv. Es wurde bestätigt, dass das Projekt auf gutem Wege ist. Client/Server Applikation mit Android 23

82 Hochschule Luzern Projektplan Meilensteinberichte Ergebnisse der letzten Arbeitsphase Ziele Resultat Bemerkung Implementieren der Use Cases UC6 und UC8 Optimieren der Usability und der Stabilität Rückmeldung zu Test Release von Auftraggeber Standortbestimmung am durchgeführt System Tests für Use Cases vorbereiten Zwischenpräsentation am 11. Mai 2012 Ziele der nächsten Arbeitsphase UC11 Bestehende Leistung bearbeiten implementieren. UI-Konzept erweitern und implementieren Alle gemeldeten Fehler mit Priorität hoch und mittel beheben. Akzeptanztest mit dem Auftraggeber durchführen. Dokumentation inklusive CD fertigstellen und abgegeben. 24 Client/Server Applikation mit Android

83 Projektplan Meilensteinberichte Hochschule Luzern 6.5 Meilenstein 5 Periode: Projektphase: Soll/Ist-Vergleich Zeitplan Projektabschluss 197h / 260h Aufwandindikator 826h = 115% Projektfortschritt Bericht: 8 von 8 (Muss Use Cases realisiert) 3 von 5 (Wunsch Use Cases realisiert) Der Abgabetermin vom 8. Juni 2012 rückte in grossen Schritten näher. Deshalb stand während dieser Phase das Stabilisieren und Verbessern der Applikation, sowie das Abschliessen der Dokumentation im Vordergrund. Die Issue-Tracking Liste nahm während dieser Phase eine zentrale Rolle ein. Die festgestellten Fehler aus den Systemtests sowie die Rückmeldungen der Projektbeteiligten (Auftraggeber und Betreuer) wurden in der Issue-Tracking Liste erfasst, priorisiert und umgesetzt. Es gab einige Vorschläge bezüglich der Verbesserung der Benutzerfreundlichkeit, weshalb das gesamte UI-Konzept überarbeitet und verbessert wurde. Der Benutzer kann nun über Tabs durch die Auftragslisten navigieren. Zusätzlich wird dem Benutzer angezeigt, welche Aufträge auf dem ERP-System verändert oder hinzugefügt wurden. Zudem wurden zwei neue Use Cases, UC12 und UC13, hinzugefügt. UC12 befasst sich mit dem Anzeigen der Leistungen, während UC13 das Anzeigen von Support Informationen beinhaltet. In der zweitletzten Woche wurde mit dem Auftraggeber ein Akzeptanztest durchgeführt, bei welchem die Erfüllung der Anforderungen überprüft wurde. Der Auftraggeber war insgesamt von der umgesetzten Lösung begeistert. Die Korrekturen, welche aus dem Akzeptanztest hervorgegangen sind, wurden im Testprotokoll festgehalten. Mit der Abgabe der Bachelor-Diplomarbeit wurde der Release (VIS: , VMA ) der Iteration 6 fertiggestellt und freigegeben. Client/Server Applikation mit Android 25

84 Hochschule Luzern Projektplan Meilensteinberichte Ergebnisse der letzten Arbeitsphase Ziele Resultat Bemerkung UC11 Leistung bearbeiten implementiert UI-Konzept erweitern und implementieren Alle gemeldeten Issues mit Priorität hoch und mittel beheben Akzeptanztest mit dem Auftraggeber durchführen. Gemäss UI-Konzept, [SPEZ] Gemäss [ISSTR]. Akzeptanztest wurde am mit dem Auftraggeber durchgeführt. Dokumentation inklusive CD fertigstellen und abgegeben. Ziele der nächsten Arbeitsphase Präsentation der Diplomarbeit vorbereiten und vortragen Poster und WebAbstract für Diplomausstellung fertigstellen 26 Client/Server Applikation mit Android

85 Projektplan Risikomanagement Hochschule Luzern 7 Risikomanagement Das Risikomanagement dieses Projekts beschäftigt sich mit der Identifikation und Bewertung von möglichen Risiken, welche das Projekt potenziell gefährden können. Risiken können sich im Verlauf der Zeit ändern, deshalb ist es wichtig, Risikomanagement als iterativer Prozess zu leben. Folgende Schritte werden in diesem Projekt wöchentlich durchlaufen: Risikoidentifikation: Projektrisiken werden kontinuierlich identifiziert und priorisiert. Risikoanalyse- und Bewertung: Eintrittswahrscheinlichkeit, Folgen von Risiken einschätzen. Risikobehandlung: Planung von Gegenmassnahmen, Aktionen zur Risikominimierung. Risikoüberwachung: Monitoring des aktuellen Risikostatus und regelmässige Kommunikation im Projektteam und sofern nötig an Stakeholder. Im nachfolgenden Risikoplan (Tabelle 15) werden die Risiken dieses Projekts aufgeführt und bewertet. Die Quantifizierung erfolgt nach folgendem Schema: Risiko (R): 1=Geringes Risiko, 2=Mittleres Risiko, 3=Hohes Risiko Vermeidungsaufwand (V): 1=Geringer Aufwand, 2=Mittlerer Aufwand, 3=Hoher Aufwand Risikoziffer (Z): Indiziert die (R), mit welcher ein Risiko unter Beizug geeigneter Massnahmen entschärft werden muss. Hohe Ziffern geniessen hohe Priorität (und umgekehrt). Berechnung: (Z) = (R) / (V). Client/Server Applikation mit Android 27

86 Projektplan Risikomanagement Hochschule Luzern Initialrisiko 1 Vermeidungs -aufwand 2 Risikoziffer 3 Massnahmen Risikoziffer 4 SW2 Risikoziffer SW3 Risikoziffer SW4 Risikoziffer SW5 Risikoziffer SW6 Risikoziffer SW7 Risikoziffer SW8 Risikoziffer SW9 Risikoziffer SW10 Risikoziffer SW11 Risikoziffer SW12 Risikoziffer SW13 Risikoziffer SW14 Managementrisiken Änderungen im Projektauftrag Kunde in Änderungsprozess einbinden. Projektumfang nach abgeschlossener Anforderungsanalyse nicht willkürlich anpassen. Missverständnisse im Projektauftrag Projektauftrag sauber lesen und alle Unklarheiten zusammen mit Auftraggeber besprechen. Frühestmöglich ein Systementwurf resp. Prototyp präsentieren Ausfall von Teammitgliedern Kommunizieren, sobald ein kritisches Ereignis (Krankheit, Unfall) eintritt Abweichungen im Zeitplan Erst durch eine Analyse die Arbeitspakete festlegen, danach durch Synthese einen realistischen Rahmenplan erstellen. Controlling sauber nachführen Projekt-Kommunikation (nur zwei Arbeitsblöcke pro Woche überschneiden sich) Arbeitspakte müssen klar definiert und besprochen werden. Die erreichten Resultat sowie die offenen Probleme müssen während den gemeinsamen Arbeitsblöcken abgestimmt werden Datenverlust Das regelmässige Sichern von Projektdaten gehört zum Entwicklungsprozess und muss strikt befolgt werden. Subversion Repositories und virtuelle Testserver werden von den jeweiligen Kompetenzzentren des HSLU Enterprise Labs gesichert Client/Server Applikation mit Android 28

87 Projektplan Risikomanagement Hochschule Luzern Entwicklungsrisiken Fehler in der Softwarearchitektur Teilprobleme formulieren, modularisierter Aufbau ermöglichen, bekannte Softwarestrukturen (Design Pattern) verwenden Kommunikation zwischen Schichten Frühzeitig Prototyp erstellen und falls nötig alternative Technologien einsetzen Synchronisationskonzept Abklären, welche Daten in welchem Rhythmus und in welche Richtung synchronisiert werden müssen. Softwarearchitektur so flexibel wie möglich gestalten, damit Synchronisationsalgorithmus ersetzbar wird. Konvertierung der Datenformate In Softwarearchitektur berücksichtigen, dass verschiedene Datenformate konvertiert werden müssen. Einzelne Konvertierungen mit Unit-Tests prüfen. Benutzerauthentifizierung Vertikaler Prototyp des Login-Vorgangs erstellen und prüfen, ob dieser den Sicherheitsanforderungen entspricht Sicherheitsanforderungen nicht umsetzbar Hohe Priorisierung für Einführung von SSL in VMA und VIS Software nicht verteilbar Build- und Releasemanagement einführen, welches regelmässig Artefakte erstellt, publiziert und ggf. automatisch auf Zielsystem installiert Zeitsynchronisation zwischen der Android App (VMA) und dem Vertec ERP System Unit-Tests für bestimmte Komponente nicht durchführbar Anwendungsfälle nicht umsetzbar, da Vertec ERP System kein Standarttyp Auftrag zulässt Fehlende Dokumentation der Vertec Schnittstellen Gefährliche Konfigurationen sollen abgefangen und verunmöglicht werden, Synchronisationsproblematik dokumentieren, sodass klar ist, warum bestimmte Konfigurationen nicht problemlos funktionieren können Bereits bei der Planung der Komponenten daran denken, dass diese mit geeigneten Methoden (z.b. Mock-Tests) automatisch geprüft werden können Frühzeitig prüfen, ob der angelegte Typ Auftrag die Anforderungen (Person und Ausführungsdatum zuweisen) erfüllen kann. In den Kundenanforderungen festhalten, welche Datenfelder ein Auftrag enthalten muss Frühzeitig über Dokumentation der Schnittstellen recherchieren. Hersteller/Auftraggeber nach bestehenden Code-Beispielen anfragen Probleme mit Entwicklungsumgebung Ticketing System des Dienstleisters (HSLU Enterprise Lab) nutzen. Rechtzeitig eskalieren, falls Infrastrukturprobleme den Projektverlauf gefährden Gesamtrisiko Differenz zur letzten Bewertung (in %) Tabelle 15: Risikoplan mit identifizierten Risiken und geplanten Gegenmassnahmen Client/Server Applikation mit Android 29

88 Hochschule Luzern Projektplan Build- und Releasemanagement 8 Build- und Releasemanagement Diese Disziplin befasst sich mit dem kontrollierten und automatisierten Erstellungs- und Freigabeprozess der im Rahmen dieses Projekts entwickelten Softwareeinheiten. 8.1 Buildplanung Die Planung des Erstellungsprozesses ist der Grundstein einer erfolgreichen Entwicklung. In diesem Prozess wird versucht, repetitive Aufgaben zu automatisieren, sodass die Entwickler laufend Gewähr haben, dass der neue Code erfolgreich in das bestehende Projekt integriert werden konnte. Folgende Varianten von Builds wurden in verschiedenen Fällen auf dem CI Server eingerichtet. Triggered Build: Ein Build wird automatisch gestartet, wenn beim entsprechenden Projekt ein Code Update festgestellt wurde. Code Updates werden mit einer maximalen Verzögerung von 60 Sekunden festgestellt. Nach erfolgreichem Build-Vorgang werden automatisch alle Testfälle des betroffenen Projekts durchgeführt. Dependency Build: Ein Build wird ausgelöst, wenn eine festgelegte Abhängigkeit neu erstellt wurde. Diese Art des Erstellens wird vor allem für Testprojekte angewendet, damit diese neu erstellt werden, wenn das zu testende Projekt neugebaut wurde. Nightly Build: Jede Nacht um 00:00 Uhr wird auf dem CI Server ein Build sämtlicher verwalteter Projekte gestartet. Nightly Builds repräsentieren die aktuellste getestete Version der Software. Effektiv erstellt und getestet wird jedoch nur, wenn Änderungen am Code vorgenommen wurden. Release Build: Bei diesem Build handelt es sich um eine kontrollierte Freigabe eines Releases für die Qualitätsprüfung. Im Gegensatz zu den anderen Erstellungsarten wird der Release Build manuell gestartet Build Konfiguration VMA Das Android Softwareprojekt VertecMobileApp musste in zwei Teilprojekte getrennt werden: Ein Projekt mit dem effektiven Applikationscode sowie ein Testprojekt. Diese Konstellation wird per Design so vorgegeben. Auf dem CI Server werden demzufolge zwei getrennte Build Prozesse eingerichtet. Nachfolgende Tabellen erläutern die Konfiguration dieser beiden Prozesse kurz: Tabelle 16: Build Konfiguration VMA 30 Client/Server Applikation mit Android

89 Projektplan Build- und Releasemanagement Hochschule Luzern Tabelle 17: Build Konfiguration des VMA-Testprojekts Android Ant Build in TeamCity Um detaillierte Informationen über ausgeführte Android-Tests in TeamCity zu erhalten, wird der Android Junit Report Test Runner verwendet [1][2]. Dieser erstellt automatisch beim Ausführen der Tests eine XML Datei, welche vom Android Emulator auf den TeamCity Server gezogen und dort in die Testübersicht eingebettet wird. Es gilt zu beachten, dass dieser Test Runner nur dann verwendet wird, wenn dies explizit in der Konfiguration von Ant (ant.properties) so festgelegt wird: test.runner=com.zutubi.android.junitreport.junitreporttestrunner Automatisierte Android Tests auf TeamCity Android verwendet für Tests das bekannte Junit Test Framework. Damit die Tests auf TeamCity automatisch ausgeführt werden können, muss auf dem TeamCity Server ein Android Device verfügbar sein. Voraussetzung für dies ist wiederum, dass das Android SDK lokal auf dem Server installiert ist. Es muss sichergestellt werden, dass jederzeit ein Android Emulator für Tests verfügbar ist. Da in unserem Fall nur ein TeamCity Projekt gleichzeitig Android Tests ausführen kann, wurde nur ein Emulator konfiguriert. Dieser wird jeweils beim Systemstart des Servers mit folgendem Kommando gestartet: emulator avd avd10 no window wipe data Client/Server Applikation mit Android 31

90 Hochschule Luzern Projektplan Build- und Releasemanagement Build Konfiguration VIS Für den Erstellungs- und Testprozess des Vertec Integration Service wird eine einzige Build Konfiguration verwendet. Die Testprojekte befinden sich jeweils hierarchisch neben dem zu testenden Softwareprojekt und enden immer mit.test. Nach dem Motto Convention over Configuration werden mit diesem Setup nur Assemblies getestet, welche dem Muster *.Test.dll entsprechen. Tabelle 18: Build Konfiguration VIS 32 Client/Server Applikation mit Android

91 Projektplan Build- und Releasemanagement Hochschule Luzern 8.2 Release Planung Nach erfolgtem Erstellungsprozess ist es wünschenswert, die entstandenen Artefakte automatisch an einem Ort bereitzustellen, wo sie von Testern und Interessensgruppen eingesehen werden können. In diesem Projekt wurden drei verschiedene Qualitätsstufen von Produktfreigaben festgelegt: Development: Die Artefakte werden für Entwickler freigegeben, um neuste Änderungen zu prüfen. Die Kompilate können Debug- oder Metrik-Informationen enthalten und sollten keineswegs für produktive Zwecke eingesetzt werden. Es ist zudem möglich, dass Produkte dieser Entwicklungsstufe nicht ohne spezielles Vorwissen resp. Geeigneten Entwicklungswerkzeugen eingesetzt werden können. Quality Assurance: Produkte dieser Stufe sind für bestimmten Testbenutzer und Interessensgruppen bestimmt. Tests durch dieses Benutzergruppen sollen Rückmeldungen und Fehlerberichte liefern. Freigegeben werden jeweils jene Produkte der Stufe Development, welche über einen stabilen und lauffähigen Stand verfügen. Auf dieser Stufe werden auch Akzeptanztests zur Abnahme des Projekts durchgeführt. Production: Wie der Name bereits impliziert sind Produkte dieser Stufe für den produktiven Einsatz vorgesehen. In Produktion gelangen nur jene Releases, welche den Akzeptanztest erfolgreich bestehen. TeamCity unterstützt den Freigabeprozess mit einem sogenannten Pinning (Stecknadelprinzip). Die Stufe Development erreicht jeder erfolgreich getestete Build. Auf Stufe Development wird mit einem Pin festgelegt, welche Version für die nächste Stufe, Quality Assurance, freigegeben werden kann. Dasselbe geschieht mit Produkten der Stufe Quality Assurance; auch hier gelangen nur Produkte in die nächste Stufe, welche mit einem Pin markiert wurden. 8.3 Assembly Versionisierung Die Versionisierung der Artefakte ist insbesondere darum wichtig, weil es unerlässlich ist, allfällige Rückmeldungen und Fehlerberichte eindeutig zu bestimmten Versionen zuweisen zu können. Zusammen mit den Subversion Kommentaren kann so herausgefunden werden, was wann an welchen Artefakten verändert wurde. Über die Darstellung der Versionsnummer lassen sich kontroverse Diskussionen führen. In diesem Projekt wird ein Versionsschema vorgeschlagen, welche stark an jenes anlehnt, welches von Microsoft.Net propagiert wird [1]. Folgendes Versionsschema wird für die beiden Teilprojekte VIS und VMA verwendet: <major version>.<minor version>.<patch version>.<build number> VIS Assemblies werden automatisch durch TeamCity angepasst. Dafür stellt TeamCity ein Build Feature namens AssemblyInfo Patcher zur Verfügung. Bei Android Projekten wird die Versionsnummer im AndroidManifest.xml festgelegt. TeamCity sucht den Tag [version-tag] im Manifest und ersetzt den String mit der aktuellen Buildversion des Buildservers. Wichtiger Hinweis zur Versionisierung Assembly Versionen werden immer und nur vom TeamCity Buildserver vergeben. Buildversionen werden nicht in das Code Repository zurückgeschrieben! Während dem Entwickeln und Debuggen stellen Entwickler somit eine falsche resp. Nicht aktuelle Produktversion fest. Das ist absolut ok. Wichtig ist, dass veröffentlichte Produkte einheitlich und fortlaufend nummeriert werden. Client/Server Applikation mit Android 33

92 Hochschule Luzern Projektplan Qualitätsmanagement 9 Qualitätsmanagement 9.1 Konfigurationsmanagement Die nachfolgenden Sektionen dieses Dokuments befassen sich mit dem Configuration Management (CM) des vorliegenden Software Projekts. CM beschreibt ein integraler Prozess, welcher das Softwareprodukt während des ganzen Lebenszyklus begleitet. Wie der Name bereits impliziert, befasst sich der Prozess mit der Identifikation und Integration von Änderungen an einem Softwareprodukt. Dies kann sowohl Änderungen an einem Prototypen wie auch spätere Anpassungen am produktiven System umfassen Konfigurationseinheiten Als Configuration Items (CI) werden (Teil-) Produkte bezeichnet, welche im Configuration Control des Projekts geführt werden. Folgende Cis wurden identifiziert: Executables o VMA-release.apk o VertecIntegration.svc Common.dll SessionManagement.dll PushNotification.dll VertecConnector.dll VertecIntegrationService.dll Source Code o VertecMobileApp o VertecMobileAppTest o VertecIntegrationService Common Common.Test PushNotification PushNotification.Test SessionManagement SessionManagement.Test VertecConnector VertecConnector.Test VertecIntegrationService VertecIntegrationService.Test Dokumentationen (gemäss Dokumentationsplan, siehe Kapitel 9.1.2) 34 Client/Server Applikation mit Android

93 Projektplan Qualitätsmanagement Hochschule Luzern Dokumentationsplan Das Projektmanagement und die damit verbundene Dokumentationsarbeit werden mit Hilfe des Prozessmodells HTAgil abgewickelt. Das Grundgerüst der Dokumente aus HTAgil wurde übernommen und auf dieses Projekt angepasst. Tabelle 19 zeigt die Liste der relevanten Dokumente. Die Sortierreihenfolge der gedruckten Bachelor Diplomarbeit ist bestimmt durch die erste Zeile #. # Dokument Kurzreferenz 1 Kommentar zur Abgabe 2 Verantwortung 1 BDA_Bericht.doc BER Gedruckt + PDF gat 2 BDA_Projektplan.doc PPLAN Gedruckt + PDF moc 3 BDA_Kundenanforderung.doc KUNAF Gedruckt + PDF moc 4 BDA_Systemspezifikation.doc SPEZ Gedruckt + PDF gat 5 BDA_Testplan.doc TPLAN Gedruckt + PDF moc 6 BDA_Akzeptanztest.doc APROT Gedruckt + PDF moc - BDA_Testprotokoll_ <yyyy-mm-dd>.doc TPROT PDF moc 7 BDA_BetaProgramm.doc BETAP Gedruckt + PDF gat - release.txt RELN Als TXT abgeben moc - Issue_Tracking.xls ISSTR Als XLS abgeben gat - 04 Entwicklung\API Documentation APIDOC Als HTML abgeben gat Tabelle 19: Liste der Dokumente, welche im Rahmen des Projekts entstanden sind Versionskontrolle Java-basierte Softwarekomponenten werden in diesem Projekt mit der Eclipse IDE implementiert während Microsoft.Net Komponenten mit Microsoft Visual Studio 2010 entwickelt werden. Alle Softwareprojekte werden mit Subversion versionisiert. Somit können Änderungen am Code vollständig nachvollzogen und im Fehlerfall rückgängig gemacht werden. Das Subversion Repository wird von der HSLU bereitgestellt und ist unter folgender URL zugänglich: Alle im Rahmen des Projekts erarbeiteten Dokumente werden von den Autoren manuell versionisiert. Dafür wurde eine Versionisierungstabelle in jedem Dokument eingefügt. Abgelegt werden die Dokumente in einem Dropbox Ordner BDA. Dadurch ist der gemeinsame Zugriff auf die Dokumente gewährleistet. 1 Diese Kürzel werden in der Dokumentation eingesetzt, um Referenzen auf andere Dokumente zu setzen. 2 Sämtliche persönliche Notizen, Checklisten und andere Hilfsmittel werden mit dem BDA Datenträger abgegeben. Client/Server Applikation mit Android 35

94 Hochschule Luzern Projektplan Qualitätsmanagement 9.2 Code Dokumentation Im Quellcode werden die Kommentare in Englisch verfasst, damit eine grosse Community angesprochen werden kann, welche die Software warten und weiter entwickeln könnte Coding Style Es werden die Code Conventions verwendet, welche im Resharper 6 definiert sind. Dieses Regelwerk wird gegebenenfalls angepasst und zwischen den Teammitgliedern synchronisiert. 9.3 Aufgabenmanagement Nach erfolgter Anforderungsanalyse mussten die einzelnen Anforderungen in Teilprobleme und konkrete Aufträge (Arbeitspakete) heruntergebrochen werden. Um die Aufgaben spezifisch den einzelnen Teammitgliedern zuzuteilen, wurde eine rollende Feinplanung eingeführt. Am Ende eines Meilensteins wird jeweils die detaillierte Planung bis zum nächsten Meilenstein festgelegt. Die Work-Items einer Feinplanung beziehen sich jeweils auf die Arbeitspakete, welche zu Beginn des Projektes definiert wurden. Die Grobplanung und Feinplanung wird in einem separaten Excel-Dokument durchgeführt und nach Abschluss der jeweiligen Phase in diese Dokument übernommen Fortschrittsbesprechung Jeweils am ersten gemeinsamen Treffen einer Arbeitswoche wird der Projektfortschritt anhand der einzelnen Arbeitspakete besprochen. Bei allfälligen Verzögerungen und Problemen werden Massnahmen getroffen. Dieser Prozess tangiert den Risikomanagementprozess stark. So werden jeweils im Anschluss an die Fortschrittsbesprechung die Risiken neu bewertet. Ergeben sich aus der Fortschrittsbesprechung neue Arbeitspakete, welche bei der letzten Feinplanung nicht eingeplant wurden, dann können diese bei der Fortschrittsbesprechung in die Feinplanung aufgenommen werden Issue-Tracking Das Issue-Tracking kommt zum Einsatz, sobald erste Release zum Testen dem Kunden zur Verfügung gestellt werden. Rückmeldung zu getesteten Releases vom Kunden oder aus eigenen Systemtests werden in einem Excel-Dokument [ISSTR] eingetragen. Dabei wird jeder Pendenz eine verantwortliche Person zugewiesen, welche die Pendenz bearbeiten soll. 9.4 Kontinuierliche Integration Der wohl wichtigste Unterstützungsprozess der Softwareentwicklung wird im Begriff Continuous Integration, kurz CI, zusammengefasst. Dieser Prozess beschreibt das systematische Neubilden und Testen von Softwarekomponenten. Aus Gründen bereits bekannter Technologie sowie der Unterstützung einer Vielzahl von Entwicklungsplattformen wurde für CI ein TeamCity Server aufgesetzt: Weitere Informationen über Continuous Integration sind im [TPLAN] zu finden. 36 Client/Server Applikation mit Android

95 Projektplan Quellen Hochschule Luzern 10 Quellen Ref Quellenangabe / URL [1] Microsoft Assembly Versioning,.NET Framework 1.1, [2] W3C Simple Object Access Protocol (SOAP) Specification, [3] Security Research.at, IKT Risikomanagement Letzter Zugriff Client/Server Applikation mit Android 37

96

97 Hochschule Luzern Bachelor Diplomarbeit TA.BA_BAA+INF.F1201 Client/Server Applikation mit Android K u n d e n a n f o r d e r u n g Horw, 8. Juni 2012

98 Projekt Dokument Schule Modul Client/Server Applikation mit Android Kundenanforderung Hochschule Luzern, TA.BA_BAA+INF.F1201 Projektteam Dozent Experte Letzte Änderung Galliker Thomas Studiengang Informatik (BB) Panorama 6123 Geiss Tel Roland Gisler Urs Gehrig 7. Juni 2012, 19:52:00 Uhr Moser Christoph Studiengang Informatik (VZ) Zugerbergstrasse Unterägeri Tel Änderungsprotokoll Version Datum Autor Beschreibung moc Initialversion von Vorlage erstellt moc Entwurf der funktionalen und nichtfunktionalen Anforderungen erstellt moc UseCase erstellt gat Überarbeitung, Ergänzung und Korrektur der Anforderungen moc UI-Konzept Vertec Mobile App erstellt gat Use Cases (inkl. Diagramm) überarbeitet moc Use Cases UC-5 und UC-6 angefügt moc Produktdaten ergänzt moc Use Case UC-10 Auftrag abschliessen erstellt moc Use Case UC-11 Leistung bearbeiten erstellt gat Use Case UC-13 Support Informationen abrufen erstellt moc Allgemeine Korrekturen

99 Inhalt 1 Einleitung Ziel & Zweck dieses Dokuments Begriffe & Abkürzungen Referenzen Zielbestimmung Produktübersicht Anforderungen Liste der funktionalen Anforderungen Liste der nicht-funktionalen Anforderungen Anwendungsfälle (Use Cases) UC-01: Login UC-02: Aufträge abrufen UC-03: Auftragsdetails anzeigen UC-04: Leistung erfassen UC-05: Kundendaten anzeigen UC-06: Kunde anrufen UC-07: Spesen erfassen UC-08: Aufzeigen des Anfahrtswegs UC-09: Foto erfassen UC-10: Auftrag abschliessen UC-11: Leistung bearbeiten UC-12: Leistungen abrufen UC-13: Support Informationen anzeigen Features Produktdaten Auftrag Leistung Projekt Kunde Phase Tätigkeit Benutzeroberfläche Look & Feel Aufbau Quellen... 28

100 Abbildungsverzeichnis Abbildung 1: Kontext-Diagramm... 3 Abbildung 2: Use Case Diagramm... 8 Abbildung 3: MainActivity Abbildung 4: Detailinformationen eines Auftrages Abbildung 5: Kontaktdaten eines Kunden Abbildung 6: Leistungen erfassen Abbildung 7: Servicezeiten einer Leistung erfassen Tabellenverzeichnis Tabelle 1: Begriffe & Abkürzungen... 1 Tabelle 2: Referenzierte Dokumente... 1 Tabelle 3: Funktionale Anforderungen an die Software... 5 Tabelle 4: Nicht-funktionale Anforderungen an die Software... 7 Tabelle 5: Use Case UC-01 Login... 9 Tabelle 6: Use Case UC-02 Aufträge abrufen Tabelle 7: Use Case UC-03 Auftragsdetails anzeigen Tabelle 8: Use Case UC-04 Leistung erfassen Tabelle 9: Use Case UC-05 Kundendaten anzeigen Tabelle 10: Use Case UC-06 Kunde anrufen Tabelle 11: Use Case UC-07 Spesen erfassen Tabelle 12: Use Case UC-08 Aufzeigen des Anfahrtsweges Tabelle 13: Use Case UC-09 Foto erfassen Tabelle 14: Use Case UC-10 Auftrag abschliessen Tabelle 15: Use Case UC-11 Leistung bearbeiten Tabelle 16: Use Case UC-12 Leistungen abrufen Tabelle 17: Use Case UC-13 Support Informationen anzeigen Tabelle 18: Liste der Features Tabelle 19: Attribute einer Aktivität [1] Tabelle 20: Attribute einer Leistung [3] Tabelle 21: Attribute eines Projektes Tabelle 22: Attribute eines Kunden [2] Tabelle 23: Attribute einer Phase Tabelle 24: Attribute einer Tätigkeit... 24

101 Kundenanforderung Einleitung Hochschule Luzern 1 Einleitung 1.1 Ziel & Zweck dieses Dokuments Dieses Dokument enthält einerseits eine Beschreibung der Grundidee des Projektvorhabens sowie einen abschliessenden Katalog mit funktionalen und nicht-funktionalen Benutzeranforderungen, welche in Zusammenarbeit mit dem Auftraggeber erarbeitet wurden. Die konkreten Anwendungsfälle wurden so definiert, dass diese spezifiziert [SPEZ] und getestet [TPLAN] werden können. 1.2 Begriffe & Abkürzungen Abkürzung ERP gat HSLU moc SAP XI UI VIS VMA Erklärung Enterprise Resource Planning. Ein ERP-System wird in Unternehmen für die Ressourcenplanung eingesetzt Namenskürzel für Thomas Galliker Hochschule Luzern Namenskürzel für Christoph Moser SAP Exchange Infrastructure, ermöglicht den Datenaustausch zwischen SAP und Fremdsystemen User Interface Vertec Integration Service Vertec Mobile App Wireframe Ein konzeptueller Prototyp für Frontends; verschafft einen Überblick, wie das grobe Layout der Benutzerschnittstelle aussehen könnte Tabelle 1: Begriffe & Abkürzungen 1.3 Referenzen Ref [BER] [SPEZ] [TPLAN] Tabelle 2: Dokument 03 Dokumentation \ BDA_Bericht.doc 03 Dokumentation \ BDA_Systemspezifikation.doc 03 Dokumentation \ BDA_Testplan.doc Referenzierte Dokumente Client/Server Applikation mit Android 1

102 Hochschule Luzern Kundenanforderung Zielbestimmung 2 Zielbestimmung Der Endbenutzer des vorliegenden Projektsystems ist ein Mitarbeiter eines Dienstleistungsunternehmen, welcher von seinem Vorgesetzten in Vertec Projektaufträge zugewiesen bekommt und diese während der Arbeit bei Kunden mit Hilfe der Vertec Mobile App (VMA) abarbeitet. Die zu entwickelnde Android Applikation soll dem Auftraggeber unterwegs eine Übersicht über die ihm zugewiesenen Aufträge gewähren und ihm nach ausgeführter Arbeit ermöglichen, die erbrachte Leistung auf ein Projekt zu verbuchen. Die Benutzergruppe des Endproduktes, VMA, bezieht sich vorwiegend auf Aussendienstmitarbeiter eines Dienstleistungsunternehmens. Die in der VMA aufgeführten Aufträge stammen aus dem Vertec ERP- System, wo sie vom Projektleitern oder fachlichen Vorgesetzten erfasst und zugewiesen wurden. Die mobilen Endgeräte greifen nicht direkt auf das Vertec ERP-System zu, sondern kommunizieren indirekt über einen Integration Service. Durch die Abstraktion über den Integration Service wird eine klare Aufgabenteilung erreicht. Zudem erlaubt der Integration Service, dass weitere Systeme über die abstrahierte Schnittelle darauf zugreifen können und nur ein geringer Overhead entsteht. Ein Synchronisationsalgorithmus sorgt dafür, dass VMA Clients Daten auch dann lesen und bearbeiten können, wenn keine Datenverbindung besteht. Dadurch ist es notwendig, dass die synchronisierten Datensätze zwischenzeitlich in einer lokalen Datenbank auf der VMA gespeichert werden. Der Hersteller des Vertec ERP-Systems bietet bereits eine webbasierte Applikation für Mobile Plattformen an. Diese Anwendung ist jedoch stark auf die Apple iphone Plattform optimiert und funktioniert auf anderen Geräten nur mit Einschränkungen. Die zu entwickelnde Android Applikation soll sich mit den folgenden Eigenschaften von der bereits bestehenden iphone Applikation abheben: Die VMA soll die Smartphone üblichen Bordmittel, wie beispielsweise Google Maps oder die Kamerafunktion nutzen können. Der VMA Benutzer soll Leistungen erfassen können, auch wenn keine Verbindung zum Server besteht. Das heisst es wird zwischen VIS und VMA ein Synchronisationsmechanismus benötigt. Dem VMA Benutzer werden nur die Aufträge angezeigt welche ihm zugewiesen sind. Damit er das wichtigste auf einen Blick sieht. 2 Client/Server Applikation mit Android

103 Kundenanforderung Produktübersicht Hochschule Luzern 3 Produktübersicht Das Kontext-Diagramm in Abbildung 1 zeigt die Nutzer und die beteiligten Fremdsysteme der Client / Server Applikation mit Android. Dadurch werden die Systemgrenzen des zu entwickelten Systems und die Interaktion mit den Umsystemen ersichtlich. Der Projektleiter kann im Vertec ERP-System Projektaufträge erstellen und diese an einem Mitarbeiter zur Erledigung zuweisen. Das ERP-System bietet darüber hinaus eine XMLsowie eine COM-Schnittstelle an, über welche Daten abgefragt und bearbeitet werden können. Die Client / Server Applikation mit Android nutzt die angebotenen Schnittstellen vom ERP-System um Kunden, Projekte und Aufträge abzufragen und Leistungen zu erfassen. Über die Android Applikation kann der Benutzer eine Leistung zu einem Projekt erfassen. Zusätzlich werden Android API s verwendet um den VMA Benutzer mit zusätzlichen Funktionalitäten, wie beispielsweise das Ermitteln des Weges zu einem Kunden, zu unterstützen. Abbildung 1: Kontext-Diagramm Client/Server Applikation mit Android 3

104 Hochschule Luzern Kundenanforderung Anforderungen 4 Anforderungen Die folgenden Anforderungen wurden zusammen mit dem Auftraggeber und den beteiligten Interessensgruppen erfasst. Die Anforderungen sollen möglichst lösungsneutral sein. Konkrete Beispiele dienen nur als Illustrationszweck. Die Anforderungserhebung wurde in folgende zwei Kategorien aufgeteilt: Funktionale und nichtfunktionale Anforderungen. 4.1 Liste der funktionalen Anforderungen Nr. M W 1 Bezeichnung Werte Daten Erläuterungen Änderungen 1 Vertec Android App 1.1 M Login Der VMA Benutzer kann sich über die Android Applikation beim ERP-System anmelden. Dazu nutzt er ein Benutzername und ein persönliches Kennwort. 1.2 M Aufträge des aktuellen Tages abrufen 1.3 M Detailinformation zu Projektauftrag anzeigen Der VMA Benutzer kann eine Übersicht der Aufträge des laufenden Tages einsehen. Die Aufträge sollen nach Priorität (absteigend) sortiert werden. Der VMA Benutzer kann Detailinformationen zu einem Auftrag anzeigen. Folgende Attribute sollen angezeigt werden: Auftragstitel, Projekt, Phase, Kunde, Stichdatum, Auftragsbeschreibung. 1.4 M Leistung erfassen Der VMA Benutzer kann Leistungen, die bezüglich eines Projekts erbracht wurden, erfassen. Jede erfasste Leistung umfasst folgende Attribute: Projekt, Leistungstyp, Stichdatum, Aufwand und Beschreibung. Der Aufwand kann entweder als Zahl in Stunden und Minuten ausgewählt werden oder in Form einer Zeitspanne (von, bis) festgelegt werden. Letztere Methode soll dem Benutzer die Möglichkeit geben, auch Pausen zu erfassen. 1.5 M Kontaktdaten anzeigen Der VMA Benutzer kann die Kontaktinformationen des Kunden anzeigen lassen. 1.6 M Kunde anrufen Der VMA Benutzer kann den Kunden über die Telefonnummer in der Kontaktadresse anrufen. 1.7 W Spesen erfassen Der Benutzer kann Spesen (z.b. Reisezeit), die in einem Projekt angefallen sind, in der VMA erfassen. 1.8 W Aufzeigen des Anfahrtsweges Aufzeigen des Anfahrtsweges mit dem aktuellen Standort als Ausgangsadresse und der Kundenadresse des Auftrages als Zieladresse. Es soll versucht werden, die aktuelle GPS Position des VMA Benutzers auszulesen. Wenn dies nicht funktioniert, soll der Benutzer selber die Möglichkeit haben, seine Position anzugeben. 1 M = Muss-Anforderung, W = Wunsch-Anforderung 4 Client/Server Applikation mit Android

105 Kundenanforderung Anforderungen Hochschule Luzern 1.9 W Foto erfassen Es kann mit dem Smartphone ein Foto aufgenommen werden. Das erstellte Foto wird im Filesystem des Servers abgelegt und bei Vertec einer Aktivität zugeordnet W Auftrag abschliessen Der Benutzer kann einen Auftrag abschliessen. Das heisst, im ERP-System wird das Enddatum gesetzt, an welchem der Auftrag abgeschlossen wurde. Abgeschlossene Aufträge verschwinden nach ausgeführter Synchronisation von der VMA des jeweiligen Benutzers W Leistung bearbeiten Der VMA Benutzer kann eine bestehende Leistung bearbeiten. Dabei spielt es keine Rolle, ob diese Leistung ursprünglich in der VMA oder im ERP-System erstellt wurde M Leistungen abrufen Leistungen, welche für den angemeldeten Benutzer in Vertec erfasst wurden, können auf die VMA heruntergeladen und angezeigt werden W Support Informationen anzeigen Der VMA Benutzer soll Informationen zur Support Organisation abrufen können. 2 Vertec Integration Service 2.1 M Schnittstelle Vertec ERP- System Der Integration Service abstrahiert die von Vertec angebotene Schnittstelle (vergleichbar mit SAP XI), sodass die Anforderung an die Android App erfüllt werden können. 2.2 M Synchronisation Der Integration Service ist fähig, einen Synchronisationsmechanismus zu implementieren, welcher es erlaubt, Aufträge- und Kundendaten zwischen dem ERP-System und den Android Client abzugleichen. 2.3 W Foto im Dokumentenpfad ablegen Die Android Applikation kann ein Foto an den Server Service senden. Das erhaltene Foto soll im Dokumentenpfad des Projektes abgelegt werden. Tabelle 3: Funktionale Anforderungen an die Software 4.2 Liste der nicht-funktionalen Anforderungen Nr. M W 2 Bezeichnung Werte Daten Erläuterungen Änderungen 1 Leistung 1.1 M Effizienter Datenaustausch Die angebotene Schnittstelle von Vertec soll bereits serverseitig so abstrahiert werden, dass eine möglichst effiziente Kommunikation zwischen dem Integration Service und den Android Clients möglich ist. Es sollen nur jene Informationen übermittelt werden, die zur Weiterverarbeitung notwendig sind. 2 M = Muss-Anforderung, W = Wunsch-Anforderung Client/Server Applikation mit Android 5

106 Hochschule Luzern Kundenanforderung Anforderungen 1.2 M Effektivität Um die Ressourcen der Android Applikation zu schonen, soll auf die Effektivität der ausgeführten Operationen geachtet werden. 1.3 M Robustheit Die Android Applikation soll mit Netzunterbrüchen umgehen können. Lange Antwortzeiten sollen mit einem konfigurierbaren Timeout abgebrochen werden. Des Weiteren sollten parallele Aktivitäten (z.b. eingehende Telefonate) auf dem Geräte keinen Einfluss auf die Funktionsweise der VMA haben. Fehlerfälle sollen mit einer Fehlermeldung angezeigt werden. 1.4 M Parallelität Der Integration Service muss in der Lage sein, mehre Anfragen von VMAs parallel beantworten zu können. Die Benutzerschnittstelle darf bei zeitintensiven Operationen nicht blockiert werden. Der Einsatz von Progress Dialogen ist zu bevorzugen. 1.5 M Synchronisation Die Datenobjekte (Aufträge, Leistungen, etc.) welche auf dem Endgerät verändert oder erstellt werden, können ohne Prüfung auf Konflikte in das ERP-System geschrieben werden. 2 Benutzbarkeit 2.1 M Einfache Erlernbarkeit Der Benutzer kann die gewünschten Funktionen mit geringem Vorwissen erfolgreich benutzen. 2.2 AM Logischer Aufbau Abläufe der Funktionen in der Software sind gut strukturiert und selbsterklärend. 2.3 M Dialogschritte Dialoge sind verständlich und geben bei Bedarf Rückmeldungen an den Benutzer. 2.4 M Look & Feel Das GUI soll ansprechend gestaltet sein. Selbsterklärende Icons und Grafiken sollen für einfache Benutzung wichtiger Funktionen eingesetzt werden. 2.5 M Sortierung der Aufträge Die Aufträge werden sortiert nach Prioritäten aufgelistet. 2.6 M Sprache Standartmässig soll die Sprache Deutsch eingesetzt werden. Andere Sprachen sollen mit geringem Mehraufwand eingebunden werden können. 2.7 M Undatierte Aufträge Projektaufträge, für welche kein Erledigungsdatum erfasst wurde, sollen in der VMA unter Favoriten erscheinen. Dadurch kann der Projektleiter einen generellen Auftrag für ein Projekt anlegen, worauf Stunden verbucht werden können. 2.8 W Navigieren durch Aufträge Der VMA Benutzer soll die Möglichkeit haben zu den Projektaufträgen des vorherigen und nachfolgenden Tages zu navigieren. 2.9 W Erwartungskonformität Dialoge sind konsistent mit den Erwartungen des Benutzers. Es werden, sofern möglich, Icons verwendet, welche dem Benutzer bereits aus dem Vertec System bekannt sind. 3 Sicherheit 3.1 M Sichere Datenübertragung Die übertragenen Daten müssen verschlüsselt übertragen werden. 6 Client/Server Applikation mit Android

107 Kundenanforderung Anforderungen Hochschule Luzern 3.2 M Sichere Datenhaltung Daten auf mobilen Geräten soll sicher gespeichert werden. Aus anderen Applikation soll kein Zugriff auf die Daten möglich sein. Zudem sollten die Daten bei einem Diebstahl des Gerätes nicht einsehbar sein. 4 Entwicklungsspezifisch 4.1 M Wartbarkeit Der Code soll so konstruiert und dokumentiert werden, dass Änderungen im Nachhinein möglich sind und einen möglichst kleinen Einfluss auf bestehenden Code haben. 4.2 M Konfigurationsverwaltung Die einzelnen Software Komponenten sollen in einem Versionisierungssystem verwaltet werden, sodass der Verlauf der Entwicklung jederzeit nachvollziehbar ist. Bei Bedarf können Änderungen rückgängig gemacht werden. 4.3 M Kontinuierliche Integration Es soll stets eine lauffähige Version der Software vorliegen. Ein Continuous Integration System prüft automatisch die gegebenen Testfälle und erstellt regelmässig einen lauffähigen Build aller Softwarekomponenten. Tabelle 4: Nicht-funktionale Anforderungen an die Software Client/Server Applikation mit Android 7

108 Hochschule Luzern Kundenanforderung Anwendungsfälle (Use Cases) 5 Anwendungsfälle (Use Cases) Ein Anwendungsfall (engl. Use Case) stellt ein konkretes Szenario dar, welches eintreten kann, wenn ein Akteur mit Hilfe einer Software-Funktion ein bestimmtes Ziel erreichen will. Im nachfolgenden Abschnitt werden die vorgesehenen Anwendungsfälle nach einer einheitlichen Schablone (Alistair Cockburn, 2001) dargestellt und beschrieben. Systemgrenze Login Aufträge abrufen Auftragsdetails anzeigen Leistungen abrufen Auftrag abschliessen Vertec ERP System Vertec Mobile App Benutzer Leistung bearbeiten Leistung erfassen Project Repository Spesen erfassen Kundendaten anzeigen Android Camera API Foto erfassen Kunde anrufen Android Call API Aufzeigen des Anfahrtsw eges Support Informationen anzeigen Android Maps API Abbildung 2: Use Case Diagramm 8 Client/Server Applikation mit Android

109 Kundenanforderung Anwendungsfälle (Use Cases) Hochschule Luzern 5.1 UC-01: Login Identifikation Name Beschreibung UC-01 Login Um die Anforderung der Benutzerauthentifizierung zu erfüllen, hat der Benutzer die Möglichkeit, sich am System über eine Login-Maske anzumelden. Das projektierte Integrationssystem ist zuständig für das sichere Weiterleiten der Login Credentials. Das Authentifizierungs- und Autorisierungskonzept wird jedoch vom ERP-System umgesetzt und liegt nicht im Verantwortungsbereich des geplanten Integrationssystems. Akteure Vertec Mobile App Benutzer Vertec ERP-System Vorbedingungen Benutzeraccount vorhanden; Credentials bekannt Standardablauf Alternative Abläufe 1. Vertec Mobile App starten. 2. Benutzername und Passwort in Loginmaske eingeben. 3. Das Projektsystem leitet den Benutzername und das Passwort zur Validierung ans Vertec ERP-System weiter 4. Der VMA Benutzer wird informiert ob das Login erfolgreich war. 1. Reauthentifizierung: Sofern der Benutzer bereits erfolgreich angemeldet ist, erfolgen alle weiteren Authentifizierungen über ein Session Token und nicht, wie beim ersten Login, mit Benutzername/Passwort. 2. Reauthentifizierung mit abgelaufenem Session Token: Ist das Session Token wegen zu langer Inaktivität ungültig, dann wird dem VMA Benutzer wieder die Loginmaske angezeigt und er muss sich erneut Authentifizieren. 3. Erneutes Login: Ein Benutzer hat die Möglichkeit, sich über eine Menüoption erneut am System anzumelden und dabei andere Credentials zu verwenden. Es wird nur eine Login Session unterhalten. Nachbedingungen Benutzer ist am System angemeldet und ist berechtigt, weitere Aktionen auszuführen. Bemerkung - Status Entwurf In Überarbeitung Abgeschlossen Änderungen Datum Editor Kommentar gat, moc Entwurf erstellt gat Überarbeitung, alternative Abläufe moc Standardablauf überarbeitet Tabelle 5: Use Case UC-01 Login Client/Server Applikation mit Android 9

110 Hochschule Luzern Kundenanforderung Anwendungsfälle (Use Cases) 5.2 UC-02: Aufträge abrufen Identifikation Name Beschreibung UC-02 Aufträge abrufen Vertec Projektmanager haben im Vertec GUI (Umsystem; geliefert vom Hersteller) die Möglichkeit, Projektaufträge (d.h. Vertec Aktivtäten vom Typ Auftrag ) einzelnen Mitarbeitern zuzuweisen. Der VMA Benutzer kann die ihm zugewiesenen Aufträge auf das Smartphone herunterladen und anzeigen. Akteure Vertec Mobile App Benutzer Vertec ERP-System Vorbedingungen UC-01: Benutzer ist am System angemeldet Standardablauf Alternative Abläufe 1. Automatisch nach dem Starten der Applikation resp. nach erfolgreichem Login werden beim Vertec ERP-System die Projektaufträge, welche dem angemeldeten Benutzer zugeordnet und am aktuellen Tag erledigt werden müssen, geladen. 2. Zusätzlich werden beim Vertec ERP-System Projektaufträge geladen welche dem angemeldeten Benutzer zugeordnet sind und kein Auftragsdatum gepflegt wurde. 3. Dem VMA Benutzer werden die Projektaufträge des aktuellen Tages, sortiert nach Prioritäten, angezeigt. 1. Manueller Reload: Projektaufträge können über eine Menüoption manuell geladen werden. 2. Zeitgesteuerter Reload: Projektaufträge werden periodisch geladen. Nachbedingungen Aufträge werden in einer Liste, sortiert nach Prioritäten, aufgelistet. Wenn keine Aufträge vorhanden sind, wird keine Liste angezeigt. Bemerkung - Status Entwurf In Überarbeitung Abgeschlossen Änderungen Datum Editor Kommentar gat, moc Entwurf erstellt gat Überarbeitung moc UseCase überarbeitet nach der Besprechung mit dem Auftraggeber Tabelle 6: Use Case UC-02 Aufträge abrufen 10 Client/Server Applikation mit Android

111 Kundenanforderung Anwendungsfälle (Use Cases) Hochschule Luzern 5.3 UC-03: Auftragsdetails anzeigen Identifikation Name Beschreibung UC-03 Auftragsdetails anzeigen Der VMA Benutzer kann für einen bestimmten Projektauftrag detaillierte Informationen anzeigen lassen. Akteure Vertec Mobile App Benutzer Vorbedingungen UC-01: Benutzer ist am System angemeldet. UC-02: Projektaufträge sind geladen. Standardablauf 1. VMA Benutzer wählt einen Projektauftrag aus. 2. Detailinformationen werden in einer neuen Ansicht angezeigt. Alternative Abläufe - Nachbedingungen - Bemerkung - Status Entwurf In Überarbeitung Abgeschlossen Änderungen Datum Use Case owner Kommentar gat, moc Entwurf erstellt gat Überarbeitung Tabelle 7: Use Case UC-03 Auftragsdetails anzeigen Client/Server Applikation mit Android 11

112 Hochschule Luzern Kundenanforderung Anwendungsfälle (Use Cases) 5.4 UC-04: Leistung erfassen Identifikation Name Beschreibung UC-04 Leistung erfassen Der VMA Benutzer kann für ein Projekt eine Leistung erfassen. Akteure Vertec Mobile App Benutzer Vertec ERP-System Vorbedingungen UC-01: Benutzer ist am System angemeldet UC-02: Projektaufträge sind geladen Standardablauf Alternativer Ablauf 1. Der VMA Benutzer wählt ein Projektauftrag aus der Auftragsliste aus. 2. Über die Schaltfläche Leistung erfassen kann der Benutzer eine neue Leistung für das Projekt des gewählten Auftrages erfassen. Eine neue Eingabemaske wird gezeigt, auf welcher das Projekt und die Phase (falls vorhanden) bereits vorgegeben sind. 3. Der VMA Benutzer kann die geleisteten Stunden oder die Arbeitsperiode (von, bis) erfassen. 4. Mit der Schaltfläche Speichern wird die erfasste Leistung persistiert. 5. Synchronisation starten, um die erfasste Leistung in das ERP-System zu schreiben. 1. Neue Leistung über Leistungsliste erstellen: Alternativ kann eine Leistung auch über die Auflistung der Leistungen erstellt werden. Bei dieser Variante können die Attribute Projekt und Phase (sofern vorhanden) frei gewählt werden. Nachbedingungen - Die erfasste Leistung wird nach ausgeführter Synchronisation im Vertec ERP-System aufgeführt. Bemerkung - Status Entwurf In Überarbeitung Abgeschlossen Änderungen Datum Editor Kommentar gat, moc Entwurf erstellt gat Überarbeitung moc UseCase überarbeitet nach der Besprechung mit dem Auftraggeber Tabelle 8: Use Case UC-04 Leistung erfassen 12 Client/Server Applikation mit Android

113 Kundenanforderung Anwendungsfälle (Use Cases) Hochschule Luzern 5.5 UC-05: Kundendaten anzeigen Identifikation Name Beschreibung UC-05 Kundendaten anzeigen Der VMA Benutzer kann die Kontaktdaten eines Kunden, für welchen der angemeldete Benutzer einen Auftrag ausführen muss, anzeigen lassen. Akteure Vertec Mobile App Benutzer Vertec ERP-System Vorbedingungen UC-01: Benutzer ist am System angemeldet UC-02: Projektaufträge sind geladen Standardablauf Alternative Ablauf 1. VMA Benutzer wählt einen Projektauftrag aus. Detailinformationen zum ausgewählten Projektauftrag werden in einer neuen View angezeigt. 2. Durch das Anwählen des Kunden in der Detailinformation des Projektauftrags wird eine neue View geöffnet, welche die Kontaktdaten des Kunden anzeigt. 1. Keine Kontakt für den gewählten Auftrag erfasst: Dem VMA Benutzer wird der Kunde, welcher dem Projekt zugewiesen ist, angezeigt. Nachbedingungen - Bemerkung - Status Entwurf In Überarbeitung Abgeschlossen Änderungen Datum Editor Kommentar moc Entwurf erstellt Tabelle 9: Use Case UC-05 Kundendaten anzeigen Client/Server Applikation mit Android 13

114 Hochschule Luzern Kundenanforderung Anwendungsfälle (Use Cases) 5.6 UC-06: Kunde anrufen Identifikation Name Beschreibung UC-06 Kunde anrufen Der VMA Benutzer kann über die Kontaktdaten eines Kunden direkt einen Anruf tätigen. Akteure Vertec Mobile App Benutzer Vertec ERP-System Android Call API Vorbedingungen UC-01: Benutzer ist am System angemeldet UC-02: Projektaufträge sind geladen UC-05: Kundendaten werden angezeigt Standardablauf 1. VMA Benutzer wählt den Link, in welchem die Nummer der Kontaktperson angezeigt wird. 2. Der Aufruf das ein Anruf getätigt werden soll, wird an eine vorhandene Android Call API weitergeleitet und enthält die vom VMA Benutzer gewählte Nummer als Parameter Alternative Ablauf - Nachbedingungen - Bemerkung - Status Entwurf In Überarbeitung Abgeschlossen Änderungen Datum Editor Kommentar moc Entwurf erstellt Tabelle 10: Use Case UC-06 Kunde anrufen 14 Client/Server Applikation mit Android

115 Kundenanforderung Anwendungsfälle (Use Cases) Hochschule Luzern 5.7 UC-07: Spesen erfassen Identifikation Name Beschreibung UC-07 Spesen erfassen Der VMA Benutzer kann für ein Projekt Spesen erfassen. Akteure Vertec Mobile App Benutzer Vertec ERP-System Vorbedingungen UC-01: Benutzer ist am System angemeldet UC-02: Projektaufträge sind geladen Standardablauf Alternativer Ablauf 1. Der VMA Benutzer wählt ein Projektauftrag aus. 2. Über die Schaltfläche Spesen erfassen wird eine neue Eingabemaske geöffnet. Damit können neue Spesen für das Projekt des gewählten Projektauftrags erfassen werden. 3. Der VMA Benutzer kann die Spesen in der Eingabemaske erfassen. 4. Synchronisation starten, um die erfasste Spesenabrechnung in das ERP-System zu schreiben. 1. Neue Spesen über Spesenliste erstellen: Alternativ können Spesen auch über die Spesenliste erstellt werden. Nachbedingungen - Die Spesenabrechnung wird nach ausgeführter Synchronisation im Vertec ERP-System aufgeführt. Bemerkung - Status Entwurf In Überarbeitung Abgeschlossen Änderungen Datum Editor Kommentar gat, moc Entwurf erstellt gat Überarbeitung moc UseCase überarbeitet nach der Besprechung mit dem Auftraggeber Tabelle 11: Use Case UC-07 Spesen erfassen Client/Server Applikation mit Android 15

116 Hochschule Luzern Kundenanforderung Anwendungsfälle (Use Cases) 5.8 UC-08: Aufzeigen des Anfahrtswegs Identifikation Name Beschreibung UC-08 Aufzeigen des Anfahrtswegs Aufzeigen des Anfahrtswegs mit dem aktuellen Standort als Ausgangspunkt und der Kundenadresse des Auftrages als Zieladresse. Akteure Vertec Mobile App Benutzer Vertec ERP-System Android Maps API Vorbedingungen UC-01: Benutzer ist am System angemeldet UC-02: Projektaufträge sind geladen GPS Modul und GPS Empfang vorhanden Standardablauf Alternative Ablauf 1. VMA Benutzer wählt einen Projektauftrag aus. Die Detailinformationen zum gewählten Projektauftrag werden in einer neuen Ansicht angezeigt. 2. In den Detailinformationen des Projektauftrages klickt der VMA Benutzer auf den Kunden. Es wird eine neue Ansicht mit den Kontaktdaten des Kunden angezeigt. 3. Der VMA Benutzer kann durch anwählen der Kundenadresse die Strecke zum Kunden ermitteln. 4. Eine vorhanden Applikation (z.b. Google Maps), welche die Strecke aufzeigen kann, wird auf dem Smartphone gestartet und erhält als Parameter den aktuellen Standort sowie die Kundenadresse. 1. Keine Kartenapplikation vorhanden: Der VMA Benutzer wird informiert, dass die Strecke nicht ermittelt werden kann, da auf dem Gerät keine Kartenapplikation verfügbar ist. 2. Kein GPS Modul oder kein GPS Empfang vorhanden: Die VMA versucht während einer bestimmten Zeit, eine GPS Position auszulesen. Gelingt dies nicht vor Ablauf eines Timeouts, wird als Abfahrtsort ein Fragezeichen gesetzt. Der Benutzer kann in der Navigationsapplikation selber wählen, von wo er abfahren möchte. Nachbedingungen - Korrekte Route vom Abfahrtsort zum Zielort (Kundenadresse) wird in der Kartenapplikation dargestellt. Bemerkung - Dieser Use Case ist stark auf den Funktionsumfang der Kartenapplikation angewiesen. Änderungen an dieser externen Applikation können diesen Use Case beeinträchtigen. Status Entwurf In Überarbeitung Abgeschlossen Änderungen Datum Editor Kommentar gat, moc Entwurf erstellt gat Überarbeitung moc UseCase überarbeitet nach der Besprechung mit dem Auftraggeber Tabelle 12: Use Case UC-08 Aufzeigen des Anfahrtsweges 16 Client/Server Applikation mit Android

117 Kundenanforderung Anwendungsfälle (Use Cases) Hochschule Luzern 5.9 UC-09: Foto erfassen Identifikation Name Beschreibung UC-09 Foto erfassen Projektresultate können mit Hilfe von Fotografien dokumentiert werden. Das erstellte Foto wird im Dateisystem des Servers abgelegt und im Vertec ERP- System einem Auftrag zugeordnet. Akteure Vertec Mobile App Benutzer Vertec ERP-System Project Repository Android Camera API Vorbedingungen UC-01: Benutzer ist am System angemeldet UC-02: Projektaufträge sind geladen Standardablauf Alternative Ablauf 1. Projektauftrag auswählen. 2. Über Menüaufruf die Kamerafunktion des Telefons aufrufen. 3. Der VMA Benutzer erstellt anhand einer Kamera Applikation ein Foto. 4. Der VMA Benutzer entscheidet, ob das erstellte Foto dem Projektauftrag zugewiesen werden soll. Dieser Vorgang kann beliebig oft wiederholt werden, bis der Benutzer sich für ein Foto entscheidet. 1. Keine Kamera vorhanden: Der VMA Benutzer wird informiert, dass keine Fotos erfasst werden können. Nachbedingungen - Die Aufnahme kann im Vertec ERP-System unter Dokumente eingesehen werden. Bemerkung - Dieser Use Case ist stark auf den Funktionsumfang der Kameraapplikation angewiesen. Änderungen an dieser externen Applikation können diesen Use Case beeinträchtigen. Status Entwurf In Überarbeitung Abgeschlossen Änderungen Datum Editor Kommentar gat, moc Entwurf erstellt gat Überarbeitung moc UseCase überarbeitet nach der Besprechung mit dem Auftraggeber Tabelle 13: Use Case UC-09 Foto erfassen Client/Server Applikation mit Android 17

118 Hochschule Luzern Kundenanforderung Anwendungsfälle (Use Cases) 5.10 UC-10: Auftrag abschliessen Identifikation Name Beschreibung UC-10 Auftrag abschliessen Der Benutzer kann einen Auftrag abschliessen. Durch das Abschliessen eines Auftrages wird dieser dem ERP-System als abgeschlossen zurückgemeldet und erscheint somit nicht mehr in der Auftragsliste des angemeldeten Benutzers. Akteure Vertec Mobile App Benutzer Vertec ERP-System Vorbedingungen UC-01: Benutzer ist am System angemeldet UC-02: Projektaufträge sind geladen Standardablauf 1. Projektauftrag auswählen. 2. Der VMA Benutzer bestätigt über einen Button Abschliessen, dass er den Auftrag erledigt hat. 3. Synchronisation ausführen. Alternative Ablauf - Nachbedingungen - Der Auftrag wird nach ausgeführter Synchronisation von der VMA entfernt und in der Liste der Aufträge nicht mehr aufgeführt. Bemerkung - Status Entwurf In Überarbeitung Abgeschlossen Änderungen Datum Editor Kommentar moc Entwurf erstellt Tabelle 14: Use Case UC-10 Auftrag abschliessen 18 Client/Server Applikation mit Android

119 Kundenanforderung Anwendungsfälle (Use Cases) Hochschule Luzern 5.11 UC-11: Leistung bearbeiten Identifikation Name Beschreibung UC-11 Leistung bearbeiten Der VMA Benutzer kann eine erfasste Leistung, welche von ihm ausgeführt wurde, bearbeiten. Akteure Vertec Mobile App Benutzer Vertec ERP-System Vorbedingungen UC-01: Benutzer ist am System angemeldet Standardablauf Alternative Ablauf 1. Der VMA Benutzer öffnet über das Menü die Liste mit den erfassten Leistungen. 2. Das Projektsystem zeigt eine Liste mit den erfassten Leistungen an. In der Liste sind die Leistungen ersichtlich, welche vom angemeldeten Benutzer ausgeführt wurden und einem Projekt zugewiesen sind für welches der angemeldeten Benutzer einen offenen Auftrag besitzt. Dabei werden auch die Leistungen angezeigt, welche direkt im ERP- System für den angemeldeten Benutzer erfasst wurden. 3. Der VMA Benutzer wählt eine Leistung aus, die er editieren möchte. 4. Der Editiermodus wird gestartet und die erfassten Werte (z.b. Projekt, aufgewendete Stunden) für die gewählte Leistung werden angezeigt. 5. Der VMA Benutzer editiert ein oder mehrere Attribute der Leistung. Im Editiermodus kann das Projekt und die Phase nicht verändert werden, da dies vom ursprünglichen Auftrag übernommen wurden. 6. Der VMA Benutzer speichert die Änderung. 7. Mit der nächsten Synchronisation wird die Änderung ins ERP-System übernommen. 1. VMA Benutzer erfasst keinen Aufwand: Der VMA Benutzer wird informiert das Leistung ohne Aufwand nicht erfasst werden können. Nachbedingungen - Änderungen werden im ERP-System übernommen. Bemerkung - Status Entwurf In Überarbeitung Abgeschlossen Änderungen Datum Editor Kommentar moc Entwurf erstellt Tabelle 15: Use Case UC-11 Leistung bearbeiten Client/Server Applikation mit Android 19

120 Hochschule Luzern Kundenanforderung Anwendungsfälle (Use Cases) 5.12 UC-12: Leistungen abrufen Identifikation Name Beschreibung UC-12 Leistungen abrufen Leistungen, welche ein bestimmter Benutzer in Vertec erfasst hat, können auf die VMA heruntergeladen und angezeigt werden. Es werden immer nur jene Leistungen geladen, welche einem Projekt zugewiesen sind für welches der angemeldete Benutzer offene Aufträge besitzt. Akteure Vertec Mobile App Benutzer Vertec ERP-System Vorbedingungen UC-01: Benutzer ist am System angemeldet Standardablauf Alternative Abläufe 1. Automatisch nach dem Starten der Applikation resp. nach erfolgreichem Login werden beim Vertec ERP-System die Leistungen entsprechend der geladenen Aufträge heruntergeladen. 2. Dem VMA Benutzer werden die Leistungen, absteigend sortiert nach dem Stichdatum, angezeigt. 1. Manueller Reload: Projektaufträge können über eine Menüoption manuell geladen werden. 2. Zeitgesteuerter Reload: Projektaufträge werden periodisch geladen. Nachbedingungen Aufträge werden in einer Liste korrekt sortiert aufgelistet. Wenn keine Aufträge vorhanden sind, wird keine Liste angezeigt. Bemerkung Status Entwurf In Überarbeitung Abgeschlossen Änderungen Datum Editor Kommentar gat Entwurf erstellt Tabelle 16: Use Case UC-12 Leistungen abrufen 20 Client/Server Applikation mit Android

121 Kundenanforderung Anwendungsfälle (Use Cases) Hochschule Luzern 5.13 UC-13: Support Informationen anzeigen Identifikation Name Beschreibung UC-13 Support Informationen anzeigen Der VMA Benutzer soll die Möglichkeit haben, Informationen zur Support Organisation abrufen zu können. Zu den Informationen gehören Name, Telefonnummer und -Adresse der Betreiberorganisation der jeweiligen VMA. Akteure Vertec Mobile App Benutzer Vorbedingungen Keine Standardablauf 1. Der VMA Benutzer öffnet über das Menü das Info Fenster. Alternative Ablauf Nachbedingungen - Auf dem Info Fenster werden folgende Informationen angezeigt: VIS/VMA Versionsnummer, Name/Telefon/Mail der Support Organisation, Session Identifikationsnummer (sofern Benutzer angemeldet), konfigurierte Service URL. Bemerkung - Status Entwurf In Überarbeitung Abgeschlossen Änderungen Datum Editor Kommentar gat UC nachträglich erstellt und abgeschlossen Tabelle 17: Use Case UC-13 Support Informationen anzeigen Client/Server Applikation mit Android 21

122 Hochschule Luzern Kundenanforderung Features 6 Features In der zu entwickelnden Software sind einige Features vorgesehen. Als Features werden all jene Eigenschaften bezeichnet, welche der Anwendung zwar einen Mehrwert geben, jedoch nicht als konkrete Anforderungen definiert wurden. Darunter fällt beispielsweise die Verhaltensweise von grafischen Elementen der Benutzerschnittstelle oder Ergänzungen, welche vom Auftraggeber nicht explizit gewünscht wurden. Ein Grossteil der Features kann nicht systematisch mit automatisierten Tests abgedeckt werden. Deshalb ist es umso wichtiger, dass diese bei den Systemtests (siehe [TPLAN]) berücksichtig werden. ID Name Beschreibung F-1 Berührungsverhalten von Schaltflächen F-2 Berührungsverhalten von Listenelementen Siehe UI-Konzept, [SPEZ] Siehe UI-Konzept, [SPEZ] F-3 Activity Animationen Siehe UI-Konzept, [SPEZ] F-4 Sync Bar Siehe UI-Konzept, [SPEZ] F-5 Felder mit leeren Informationen ausblenden F-6 Änderungsstatus visualisieren Siehe UI-Konzept, [SPEZ] Siehe UI-Konzept, [SPEZ] F-7 Supportmail versenden Der Benutzer hat die Möglichkeit, Fehlermeldungen an die Support- Organisation zu senden. Über den Link der Support-Mailadresse kann er eine neue Mail erstellen, welche bereits einen vorformulierten Text sowie das Ereignisprotokoll der VMA enthält. F-8 Kalendereintrag für Auftrag erstellen F-9 Wählverhalten von Telefonnummern Dem Stichdatum eines Auftrags ist ein Link hinterlegt, welcher das Formular zum Erstellen neuer Kalendereinträge öffnet. Dieses Formular ist bereits mit den wichtigsten Kalenderattributen (Titel, Ort, Zeit, Beschreibung) abgefüllt. Das Verhalten beim Berühren von Telefonnummern kann individuell konfiguriert werden: Es stehen die beiden Optionen CALL und DIAL zur Verfügung. Siehe Konfiguration der VMA, [SPEZ] F-10 Push Notification Siehe Design-Entscheide, [SPEZ] Tabelle 18: Liste der Features 22 Client/Server Applikation mit Android

123 Kundenanforderung Produktdaten Hochschule Luzern 7 Produktdaten Dieses Kapitel definiert welche Mengengerüste auf der VMA abgerufen, respektive angelegt werden können. 7.1 Auftrag Name Technischer Name Bemerkung Datum datum Erfassungsdatum der Aktivität. Erfasst von erfasser Mitarbeiter, der die Aktivität erfasst hat. Typ typ Typ der Aktivität. Definiert dass es sich um einen Auftrag handelt. Kontaktart kontaktart Art des Kontaktes: Telefon, schriftlich, per oder Vorort. Termin termin Datum, an welchem der Auftrag ausgeführt werden soll. Priorität prioritaet Auswahl aus 0 = hoch, 1 = normal oder 2 = tief Zuständig zustaendig Mitarbeiter, der für die Erledigung der Aktivität zuständig ist. Erledigt erledigt Checkbox für Status der Aktivität. 1 = erledigt, 0 = offen Erledigt am erledigtdatum Datum, an welchem der Auftrag Erledigt wurde. Projekt projekt Projekt, zu dem die Aktivität gehört. Phase phase Phase, respektive Teilprojekt, zu welchem die Aktivität gehört. Kontakt adresseintrag Referenz zum Kunden oder einer Ansprechperson. Titel titel Kurztext für die Aktivität. Text text Beschreibender Text der Aktivität Dokument pfad Pfad eines der Aktivität zugeordneten Dokumentfiles. Der Basispfad für das Dokument wird aufgrund der Projektzuordnung bestimmt. Beispielsweise mit dem Link zum Foto, welches anhand vom : Use Case UC-09 Foto erfassen erstellt wurde. Geändert am modifieddatetime Datum und Zeit, an welchem der Datensatz verändert wurde. Tabelle 19: Attribute einer Aktivität [1] 7.2 Leistung Name Technischer Name Bemerkung Projekt projekt Projekt, zu welchem eine Leistung erbracht wurde. Phase phase Projektphase, in welcher die Leistung erbracht wurde. Bearbeiter bearbeiter Mitarbeiter, welcher die Leistung erbracht hat. Text text Text, welcher die erbrachte Leistung beschreibt. Tätigkeit typ Datum datum Datum, an welchem die Leistung erbracht wurde Aufwand minutenint Geleistete Arbeitszeit. von minutenintvon Arbeitsbeginn Client/Server Applikation mit Android 23

124 Hochschule Luzern Kundenanforderung Produktdaten bis minutenintbis Arbeitsende Pause minutenpause Dauer der Pause, welche während dem Erbringen der Leistung eingelegt wurde. Geändert am modifieddatetime Datum und Zeit, an welchem der Datensatz verändert wurde. Tabelle 20: Attribute einer Leistung [3] 7.3 Projekt Name Technischer Name Bemerkung Projekt-Code code Kurzbezeichnung eines Projektes Beschrieb beschrieb Beschreibung Geändert am modifieddatetime Datum und Zeit, an welchem der Datensatz verändert wurde. Tabelle 21: Attribute eines Projektes 7.4 Kunde Name Vertec Name Bemerkung Firma name Name des Unternehmens. Addition Adresse PLZ Ort Telefon Mobile zusatz standardadresse standardplz standardort standardtelefon standard standardmobile Geändert am modifieddatetime Datum und Zeit, an welchem der Datensatz verändert wurde. Tabelle 22: Attribute eines Kunden [2] 7.5 Phase Name Technischer Name Bemerkung Code code Kurzbezeichnung einer Phase Beschreibung beschreibung Beschreibung Geändert am modifieddatetime Datum und Zeit, an welchem der Datensatz verändert wurde. Tabelle 23: Attribute einer Phase 7.6 Tätigkeit Name Technischer Name Bemerkung Code code Kurzbezeichnung einer Tätigkeit. Text text Name der Tätigkeit. Geändert am modifieddatetime Datum und Zeit, an welchem der Datensatz verändert wurde. Tabelle 24: Attribute einer Tätigkeit 24 Client/Server Applikation mit Android

125 Kundenanforderung Benutzeroberfläche Hochschule Luzern 8 Benutzeroberfläche Zur Evaluation des Vertec Mobile App User Interface wird ein Wireframe Prototyp mit der Software Justinmind Prototyper [4] erstellt. Damit kann überprüft werden, ob das UI-Konzept den Bedürfnissen des Kunden entspricht noch bevor eine Zeile Code geschrieben wird. 8.1 Look & Feel Die Vertec Mobile App wird im Android Style entwickelt. Durch die Verwendung von üblichen Android Widgets wird sichergestellt, dass der Benutzer die App anhand bereits bekannter UI-Komponenten bedienen kann. Zusätzlich werden die Vertec Icons (Projekt, Customer) in der VMA genutzt, um den Wiedererkennungswert zu verstärken. Der Prototyp der VMA wird in der Sprache Deutsch umgesetzt und für die Auflösung 480x800 optimiert, da dies gemäss aktuellem Stand mit 57.8% (siehe [BER]) am Häufigsten verwendet wird. 8.2 Aufbau Die MainActivity (Abbildung 3) ist das Fenster, welches beim Starten der Applikation angezeigt wird. Das Primärziel der VMA ist es, den Mitarbeiter über anstehende Aufträge zu informieren. Deshalb werden in der MainActivity diejenigen Aufträge nach Priorität sortiert angezeigt, welche dem Benutzer zugewiesen wurden. Durch das Anwählen eines Auftrages wird dem Benutzer ein neues Fenster (Abbildung 4) mit den Detailinformationen angezeigt. Über das Menü können neue Leistungen und Spesen erfasst werden. Zudem lässt sich die Synchronisation mit dem Server manuell starten. Abbildung 3: MainActivity Client/Server Applikation mit Android 25

126 Hochschule Luzern Kundenanforderung Benutzeroberfläche Im Auftragsfenster werden die Detailinformationen zu einem Auftrag angezeigt. Durch einen Klick auf den Kunden, wird ein neues Fenster (Abbildung 5) mit den Kontaktdaten des Kunden geöffnet. Über das Menü können neue Leistungen und Spesen erfasst werden. Zudem lässt sich die Synchronisation mit dem Server manuell starten. Abbildung 4: Detailinformationen eines Auftrages Über das Menü wird dem Benutzer die Funktion zum Bestimmen des Anfahrtsweges vom aktuellen Standort zum Kunden angeboten. Abbildung 5: Kontaktdaten eines Kunden 26 Client/Server Applikation mit Android

127 Kundenanforderung Benutzeroberfläche Hochschule Luzern Der VMA Benutzer öffnet das Fenster (Abbildung 6) für die Erfassung von Leistungen über das Menü eines Projektauftrages. Dadurch sind bereits Projekt und Phase, für welche die Leistung erfasst werden soll, selektiert. Für die geleistete Arbeit können direkt Stunden bzw. Minuten erfasst werden. Alternativ kann die Arbeitszeit über das Fenster Service Time (Abbildung 7) durch die Eingabe von Beginn- und Endzeit, sowie der Pausenzeit ermittelt werden. Abbildung 6: Leistungen erfassen Abbildung 7: Servicezeiten einer Leistung erfassen Client/Server Applikation mit Android 27

128 Hochschule Luzern Kundenanforderung Quellen 9 Quellen Ref Quellenangabe / URL [1] Vertec, Aktivitäten eten [2] Vertec, UML Modell Adressen dressen [3] Vertec, Leistung erfassen leistungsgrundlagen/leistungserfassung [4] Justinmind, Rich interactive wireframes to define web and mobile applications Letzter Zugriff Client/Server Applikation mit Android

129

130

131 Hochschule Luzern Bachelor Diplomarbeit TA.BA_BAA+INF.F1201 Client/Server Applikation mit Android S y s t e m s p e z i f i k a t i o n Horw, 8. Juni 2012

132 Projekt Dokument Schule Modul Client/Server Applikation mit Android Systemspezifikation Hochschule Luzern, TA.BA_BAA+INF.F1201 Projektteam Dozent Experte Letzte Änderung Galliker Thomas Studiengang Informatik (BB) Panorama 6123 Geiss Tel Roland Gisler Urs Gehrig 7. Juni 2012, 21:22:00 Uhr Moser Christoph Studiengang Informatik (VZ) Zugerbergstrasse Unterägeri Tel Änderungsprotokoll Version Datum Autor Beschreibung gat Initialversion von Vorlage erstellt, Outline reorganisiert gat Systemübersicht gat Schichtenmodell gat Komponentenansicht gat/moc Schnittstellendefinition moc Synchronisationskonzept erstellt moc Datensicht erstellt gat Design Entscheid zu Kommunikation und Serialisierung moc Synchronisationskonzept überarbeitet moc ER-Diagramm überarbeitet moc Synchronisationskonzept überarbeitet: Create und Update vereint gat Design-Entscheide Concurrency, Logging und Exception Handling moc Synchronisation überarbeitet moc Konfigurierbare Vertec Read Requests angefügt moc Vertec XML-Schnittstelle Beschreibung eingefügt moc Zeitsynchronisation zwischen VMA und Vertec System dokumentiert gat Verteilung und Konfiguration von VMA und VIS moc Schnittstellenbeschreibung und Konfigurationsparameter ergänzt moc UI-Konzept dokumentiert moc Caching und Synchronisation angepasst / Vertec Requests angefügt moc/gat Korrekturen

133 Inhalt 1 Einleitung Ziel & Zweck dieses Dokuments Begriffe & Abkürzungen Referenzen Softwarearchitektur Systemübersicht Schichtenarchitektur Komponentenansicht Schnittstellen Datenstruktur Klassenübersicht Softwareverteilung UI-Konzept Übersicht Look & Feel Design-Entscheide Integration Service Prinzip Multithreading Kommunikation und Serialisierung zwischen den Schichten Persistenz Login und Session Handling GPS Routenplanung Caching und Synchronisation Push Notification Logging Environment-Anforderungen Quellen... 52

134 Abbildungsverzeichnis Abbildung 1: Systemübersicht... 3 Abbildung 2: Schichtenmodell mit Tier-Grenzen... 4 Abbildung 3: Komponentendiagramm des Gesamtsystems... 5 Abbildung 4: Grundstruktur einer XML Message... 9 Abbildung 5: Authentifizierung gegenüber dem VertecServer... 9 Abbildung 6: Beispiel für eine Objektabfrage Abbildung 7: Mögliche Antwort auf eine Anfrage Abbildung 8: Ein Vertec Create Request um ein Vertec Objekt zu erzeugen Abbildung 9: Die Antwort auf einen Vertec Create Request Abbildung 10: Ein Vertec Update Request (ohne Header) Abbildung 11: Antwort auf einen Update Request Abbildung 12: Physisches Entity-Relationship Modell der Vertec Mobile App Abbildung 13: Klassenansicht der VMA Abbildung 14: Klassenansicht des VIS Abbildung 15: Verteilungsansicht Abbildung 16: Überblick über die verschiedenen Android Activities Abbildung 17: Das Dashboard als Einstiegspunkt Abbildung 18: Zeigt wie ein klickbarer Attributwert visualisiert wird Abbildung 19: Ein Listenelement vor (links) und während (rechts) einer Berührung Abbildung 20: Sync Bar gibt Auskunft über die letzte Synchronisation Abbildung 21: Auftragsliste zeigt die Aufträge gruppiert nach den Prioritäten Abbildung 22: Kunde mit (links) und ohne (rechts) Mobiletelefonnummer Abbildung 23: Das Dashboard zeigt die Statusübersicht der Änderungen vom Vertec ERP-System Abbildung 24: Grafische Darstellung der Nebenläufigkeit in VIS Abbildung 25: Beispiel einer WCF Schnittstelle, welche JSON als Austauschformat anwendet Abbildung 26: Ansicht des X.509 Zertifikats, welches für vis.enterpriselab.ch verwendet wurde Abbildung 27: Ablauf des Login Vorgangs Abbildung 28: Ablauf eines authentifizierten Methodenaufrufs Abbildung 29: Call Interception anhand eines einfachen Methodenaufrufs Abbildung 30: Sequenzdiagramm zur Synchronisation Abbildung 31: Flussdiagramm zur Synchronisation Abbildung 32: Änderungen könnten verloren gehen, wenn die Zeitabweichung nicht beachtet wird Abbildung 33: Neuberechnung des Zeitstempels lastsync durch VIS Abbildung 34: Sequentieller Ablauf von Push Notification Abbildung 35: Web.config Log Tracing Konfiguration eines WCF Services Tabellenverzeichnis Tabelle 1: Begriffe & Abkürzungen... 1 Tabelle 2: Referenzierte Dokumente... 2 Tabelle 3: Beschreibung der Softwarekomponenten... 7 Tabelle 4: Übersicht der internen Schnittstellen... 8 Tabelle 5: Übersicht der externen Schnittstellen... 9 Tabelle 6: Beschreibung der Elemente einer Vertec Abfrage [13] Tabelle 7: Beschreibung der Entitäten Tabelle 8: Konfigurationsattribute von VMA Tabelle 9: Konfigurationsattribute von VIS Tabelle 10: Vertec Icons Tabelle 11: Android Icons Tabelle 12: Auftrag und Leistungs-Icons zum visualisieren des Änderungsstatus Tabelle 13: Schrittweise Erklärung zum Ablauf des Login Vorgangs Tabelle 14: Schrittweise Erklärung zum Ablauf eines authentifizierten Methodenaufrufs Tabelle 15: Datenobjekte und ihre verfügbaren Datenbankoperationen Tabelle 16: Beschreibung der einzelnen Synchronisationsschritte Tabelle 17 Operationen, welche an die VMA kommuniziert werden Tabelle 18: Systemanforderungen... 51

135 Systemspezifikation Einleitung Hochschule Luzern 1 Einleitung 1.1 Ziel & Zweck dieses Dokuments In diesem Dokument werden die technischen Aspekte des Projektes Client/Server Applikation mit Android definiert. Softwareentwickler sollen mit den Informationen in diesem Dokument rasch einen Überblick über die Eigenschaften und Konzepte des Projektsystems erlangen. 1.2 Begriffe & Abkürzungen Abkürzung CRUD ERP GPS GSON HSLU Keystore MSDN OCL ORM ORMLite REST SOAP SQLite Truststore UML URL Vertec VIS VMA WCF Erklärung Die grundlegenden Datenbankoperationen Create, Read, Update, Delete Enterprise Resource Planning. Ein ERP-System wird in Unternehmen für die Ressourcenplanung eingesetzt Global Positioning System, ein satellitengestütztes Positionierungssystem Java Bibliothek, um JSON-serialisierte Objekte in Java Objekte (und umgekehrt) umzuwandeln [3] Hochschule Luzern Applikationsinterne Sammlung von vertrauenswürdigen Zertifikaten Microsoft Developer Network; Wissensplattform für Microsoft Produkte Object Constraint Language, eine UML-standardisierte Abfragesprache Object Relational Mapper Object Relational Mapper für SQLite Datenbanken Representational State Transfer, ein Set von fundamentalen Standardprotokollen, welche für die Web Kommunikation eingesetzt werden Simple Object Access Protocol, ein Internetstandard von W3C für die Repräsentation von Austauschinformationen zwischen Web Services [1] Dateibasiertes, leichtgewichtiges Datenbanksystem Systemweite Sammlung von vertrauenswürdigen Zertifikaten Unified Modeling Language, eine grafische Modellierungssprache zur Spezifikation von Software Uniform Resource Locators; Identifizierung von Web-Ressourcen Hersteller des in diesem Projekt verwendeten Vertec ERP System Vertec Integration Service; ein WCF Web Service, welcher im Rahmen dieses Projekts entwickelt wurde Vertec Mobile App; eine Android App, welche im Rahmen dieses Projekts entwickelt wurde Windows Communication Foundation, eine Service-orientierte Kommunikationsplattform für Microsoft.Net Tabelle 1: Begriffe & Abkürzungen Client/Server Applikation mit Android 1

136 Hochschule Luzern Systemspezifikation Einleitung 1.3 Referenzen Ref Dokument [BER] 03 Dokumentation \ BDA_Bericht.doc [PPLAN] 03 Dokumentation \ BDA_Projektplan.doc [KUNAF] 03 Dokumentation \ BDA_Kundenanforderung.doc [TPLAN] 03 Dokumentation \ BDA_Testplan.doc [APPX] 03 Dokumentation \ BDA_Appendix.doc [APIDOC] 04 Entwicklung \ 07 API Documentation Tabelle 2: Referenzierte Dokumente 2 Client/Server Applikation mit Android

137 Systemspezifikation Softwarearchitektur Hochschule Luzern 2 Softwarearchitektur Dieses Kapitel enthält eine Übersicht über die eingesetzte Softwarearchitektur inklusive aller involvierten Komponenten. Einige Informationen wurden gezielt ausgeblendet, um das Verständnis der wesentlichen architektonischen Elemente in den Vordergrund zu rücken. 2.1 Systemübersicht Das Projektsystem kann grob in zwei miteinander kommunizierende Einheiten unterteilt werden. Eine Anwendung für Mobiltelefone, die Vertec Mobile App (VMA), interagiert mit der Integrationsschicht, dem Vertec Integration Service (VIS). Der Vertec Integration Service adaptiert die vom Vertec ERP- System bereitgestellten Schnittstellen so, dass ein Informationsaustausch mit den mobilen Endgeräten möglich ist. Abbildung 1 zeigt die Systemübersicht mit den erwähnten Einheiten. Das Vertec ERP-System gehört als solches nicht zum Umfang der Entwicklungen und wird in Abbildung 1 als Umsystem aufgeführt. Im Anschluss an Abbildung 1 werden die Einheiten kurz beschrieben. Abbildung 1: Systemübersicht Vertec Mobile App: Diese Anwendung übernimmt die Rolle der Präsentationsschicht der mobilen Erweiterung von Vertec. Aussendienstmitarbeiter haben mit der VMA die Möglichkeit, Auftragsinformationen anzuzeigen und Leistungen abzurechnen. Die VMA kommuniziert direkt und ausschliesslich mit dem Vertec Integration Service. Vertec Integration Service: Damit die Mobiltelefone mit dem Vertec ERP-System Informationen austauschen können, wird ein Integrationsdienst benötigt. Als Integration wird das Anbinden von fremden Systemen (im vorliegenden Fall: die Vertec Mobile App) in eine bestehende Umgebung bezeichnet. VIS ist für die Konvertierung und Adaptierung von Informationen, welche zwischen der VMA und dem ERP-System ausgetauscht werden, zuständig. Vertec ERP-System: Die Geschäftslogik sowie die Datenbasis sind auf dem Vertec ERP-System vorzufinden. Diese Einheit wird als Blackbox betrachtet. Vertec stellt Schnittstellen bereit, welche die Kommunikation mit dem ERP-System ermöglichen. Client/Server Applikation mit Android 3

138 Hochschule Luzern Systemspezifikation Softwarearchitektur 2.2 Schichtenarchitektur Um das Verständnis für die in der Systemübersicht (Abbildung 1) vorgelegten Schichten zu stärken, wird in Abbildung 2 ein Schichtenmodell eingeführt. Dieses Modell zeigt, wie die Logik innerhalb der Schichten verteilt wird und wie die einzelnen Schichten über die Tier-Grenzen hinweg miteinander kommunizieren. Wichtiges Design-Prinzip des Schichtenmodells ist die strikte Trennung der Aufgabenbereiche. Jede Schicht übernimmt eine bestimmte Funktion, welche sie über Schnittstellen anderen Schichten anbietet. Die Pfeilrichtungen in Abbildung 2 symbolisieren die Aufrufrichtung. Vertec Mobile App Presentation Layer User Interface Communication Subsystem Service Layer Data Access Layer RESTful WCF Service API Vertec Integration Service Integration Layer Communication Subsystem Integration Logic Systemgrenze Vertec XML Interface Vertec ERP System Business Logic Data Layer Communication Subsystem User Interface Business Logic Data Access Layer Abbildung 2: Schichtenmodell mit Tier-Grenzen Bemerkenswert sind die beiden aufgezeichneten Schnittstellen, die RESTful WCF Service API sowie das Vertec XML Interface. Erstgenannte wird im Rahmen der Entwicklungen des Vertec Integration Service umgesetzt. Die Vertec XML Schnittstelle wird vom Vertec ERP-System bereitgestellt. Das Vertec ERP- System gehört wie dies auf Abbildung 2 ersichtlich ist nicht zum Umfang dieses Projekts. 4 Client/Server Applikation mit Android

139 Systemspezifikation Softwarearchitektur Hochschule Luzern 2.3 Komponentenansicht Aufbauend auf dem Schichtenmodell des vorhergehenden Kapitels illustriert Abbildung 3 eine Auswahl wichtiger Komponenten sowie die dazwischen eingesetzten Schnittstellen. Die Komponentenansicht ermöglicht einen tieferen Einblick in die Architektur des vorliegenden Softwareprojekts. Vertec Mobile App Android UI android-support-v4 IVertec IAuthentication VertecAPI IntegrationServiceConnector IIntegrationServiceConnector SyncManager IVertecBase DataAccess gson-2.1 VMA.IHttpClient ormlite-android-4.28 VMA.HttpClient httpclient IVertecIntegration Vertec Integration Service web.config «manifest» WCF Web Serv ice INotificationManager IVertecConnector ISessionManager PushNotification VertecConnector SessionManagement VIS.IHttpClient VIS.HttpClient Systemgrenze XML COM Vertec ERP System Vertec Server Abbildung 3: Komponentendiagramm des Gesamtsystems Client/Server Applikation mit Android 5

140 Hochschule Luzern Systemspezifikation Softwarearchitektur Die in Abbildung 3 illustrierten Komponenten werden in der Tabelle 3 genauer beschrieben. Die Beschreibung ist auf die wesentlichen Eigenschaften der jeweiligen Komponenten reduziert. Komponenten von Vertec Mobile App Allgemeine Beschreibung der Komponente Android UI VertecAPI DataAccess SyncManager IntegrationService Connector VMA.HttpClient Sämtliche Einheiten, welche Teile der Benutzerschnittstelle umsetzen, werden in einer Komponente vereint. Das Android UI beinhaltet Activities mit Listen, Menüs, Schaltflächen und Grafiken. Die VertecAPI ist eine der zentralen Komponenten dieses Systems. Sie implementiert als Application Programming Interface IVertec. Grundsätzlich implementiert VertecAPI keine Logik, welche nicht bereits in den Komponenten DataAccess oder IntegrationServiceConnector vorhanden ist. Die Aufgabe von VertecAPI besteht darin, die Login Methoden aus IAuthentication direkt an IntegrationServiceConnector weiterzuleiten, während die Datenzugriffe direkt an die Komponente DataAccess gerichtet werden. IVertec fasst aus diesem Grund die beiden Schnittstellen IAuthentication und IVertecBase zusammen und definiert keine neuen Methoden. DataAccess stellt, wie der Name bereits impliziert, den Datenzugriff auf Entitäten der lokalen Datenbank sicher. Die Schnittstelle IVertecBase gibt vor, welche Methoden benötigt werden. Hinter DataAccess verbirgt sich ein Objekt-relationaler Entity-Mapper. (Siehe Kapitel 4.4, Seite 35). Die Komponente SyncManager ist das Bindeglied zwischen DataAccess und IntegrationServiceConnector. Über die Schnittstelle IIntegrationServiceConnector wird mit dem Vertec ERP-System kommuniziert, während die Schnittstelle IVertecBase Zugriff auf die lokale Datenbank gewährt. Die integrierte Synchronisationslogik stellt sicher, dass Daten zeitnah und konsistent zwischen Vertec Mobile App und Vertec ERP synchronisiert werden. Die Komponente IntegrationServiceConnector implementiert Methoden der beiden Schnittstellen IIntegrationServiceConnector und IAuthentication. Die Komponente ist primär zuständig für die Aufbereitung von Http Requests und Responses. Der HttpClient ist für das Ausführen von Http Requests Aufgaben zuständig. Dazu gehört nicht nur das Auslösen von synchronen und asynchronen Http POST Requests, sondern auch das Prüfen der Vertrauenswürdigkeit von SSL Zertifikaten unter Beizug des lokalen Keystores. Komponenten von Vertec Integration Service WCF Web Service Die Web Service Komponente ist der Dreh- und Angelpunkt dieses Projektsystems. Er publiziert Webschnittstellen, nimmt Webanfragen entgegen und leitet diese zur Verarbeitung an die referenzierten Komponenten weiter. Der Web Service bestimmt weiter, welche Repräsentationsformate an den Webschnittstellen genutzt werden sollen. Serialisierung, Kontextmanagement und Multithreading stehen unter seiner Verantwortung. 6 Client/Server Applikation mit Android

141 Systemspezifikation Softwarearchitektur Hochschule Luzern VertecConnector VIS.HttpClient SessionManagement PushNotification Die Komponente ist zuständig für die Aufbereitung von Vertec-spezifischen Http Requests sowie für die Konvertierung der Http Responses. Für das effektive Ausführen von Http-bezogenen Aufgaben wird die Komponente HttpClient benutzt. HttpClient ist für das Ausführen von Http-bezogenen Aufgaben zuständig. Beim VIS.HttpClient handelt es sich um einen in.net implementierten HttpClient. Die Komponente SessionManagement verwaltet die aktiven User Sessions, welche am System angemeldet sind. Der SessionManger kennt die Vertec Login- Informationen (Benutzername und Passwort) aller angemeldeter Benutzer. Die Login-Informationen werden nur im Memory des Servers gespeichert und haben eine zeitlich eingeschränkte Gültigkeit. Mehr Informationen zum Thema Session Management: Kapitel 4.4, Seite 35. Die Komponente implementiert die Push-Benachrichtigung für das Vertec ERP- System. Ein NotificationManager stellt über eine Schnittstelle Methoden bereit, welche es Clients erlaubt, sich für Updates auf bestimmte Datentypen zu assoziieren. Diese Clients werden innerhalb der Komponente als Subscriber bezeichnet. Sie führen in regelmässigen Zeitabständen Anfragen ans ERP-System aus und prüfen so, ob ein bestimmtes Set von Daten auf dem ERP-System geändert wurde. Mehr Informationen zum Thema Push Notification: Kapitel 4.8, Seite 48. Tabelle 3: Beschreibung der Softwarekomponenten 2.4 Schnittstellen Komplexe Systeme werden in der Softwareentwicklung jeweils in kleinere, kontrollierbare Einheiten unterteilt. Diese Komponenten bieten ihre Dienste über klar definierte Schnittstellen anderen Komponenten und Subsystemen an. Die Dokumentation dieser Schnittstelle ist für kommende Wartungsarbeiten von immenser Wichtigkeit. Die Autoren dieses Dokuments haben sich entschieden, nachfolgend eine Übersicht aller in VIS und VMA vorkommenden Schnittstellen abzubilden. Die effektive API Dokumentation ist auf Wunsch des Auftraggebers in englischer Sprache abgefasst und ist auf der CD [APIDOC] zu finden Interne Schnittstellen Allgemeine Beschreibung der Schnittstelle Schnittstellen von Vertec Mobile App Die Schnittstelle IAuthentication enthält Methoden für das Benutzer-Login. Die Komponente, welche diese Schnittstelle auf der VMA implementiert, muss die Validierung der Anmeldeinformationen nicht selber vornehmen, diese aber an den Integration Service weiterleiten. Die CallbackHandler Schnittstelle wird in VMA sehr oft eingesetzt, um Resultate aus asynchronen Aufrufen zurückzugeben. IHttpClient enthält Methoden um Http Anfragen synchron und asynchron auszulösen. Diese Schnittstelle gibt die Methoden für die Aufbereitung von Http Requests für die Kommunikation mit dem Vertec Integration Service vor. IAuthentication ICallbackHandler IHttpClient IIntegrationService Connector Client/Server Applikation mit Android 7

142 Hochschule Luzern Systemspezifikation Softwarearchitektur IServiceInfo ISyncManager IVertec IVertecBase IVertecType Enthält Methoden um die verwendete VIS Version sowie Supportkontakt Information abzurufen. Die Schnittstelle ISyncManager abstrahiert die Komponente des Synchronisationsmanagers. Die zentrale Methode dieser Schnittstelle ist die Update-Methode, welche den Synchronisationsprozess aller Vertec Datentypen initialisiert. Mit der Einführung des Push-Benachrichtigungsdiensts stellt die Schnittstelle auch Methoden zum Abonnieren von Push-Nachrichten zur Verfügung. IVertec ist die eigentliche Programmierschnittstelle der VMA. Eigene Methodensignaturen stellt die Schnittstelle nicht bereit. Sie erbt lediglich jene, welche in IVertecBase, IAuthentication und IServiceInfo definiert wurden. Die Summe dieser Methoden reicht für alle Operationen, welche die Activities der Android App ausführen können muss. IVertecBase ist die Schnittstelle zur Datenbasis. Hinter ihr verbirgt sich die Datenbanklogik, welche für das Persistieren von Vertec Datentypen benötigt wird. Bereitgestellt werden generische CRUD-Operationen, welche für Objekte des Typs IVertecType applizierbar sind. Definiert die Methoden welche ein Vertec-Datenobjekt anbieten muss. Schnittstellen von Vertec Integration Service IVertecIntegration IVertecConnector IVertecType IVertecSerializer IVertecIntegration definiert die Methoden welche als Web Services angeboten werden. IVertecConnector ist die Schnittstelle, um Objekte mit dem ERP-System zu synchronisieren. Dahinter verbirgt sich das Erstellen der Vertec ERP spezifischen XML Requests und die Auswertung der resultierenden Rückmeldung. Definiert die Methoden, welche ein Vertec-Datenobjekt anbieten muss. Enthält eine Methode, um einen Serializer zu registrieren. IVertecTypeSerializer Definiert die Methoden, welche ein spezifischer Vertec Serializer implementieren muss, um XML Responses in.net Objekte umzuwandeln und umgekehrt. IHttpClient ISessionManager ISession Die Schnittstelle IHttpClient enthält eine Methode um synchrone Http-Anfragen abzusetzen. Die ISessionManager Schnittstelle enthält Methoden, welche den Zugriff auf die Sessions erlaubt. Sessions können über ISessionManager erstellt, gelöscht, gesucht und reaktiviert werden. Eine Login Session wird über die Schnittstelle ISession abstrahiert. Sie gibt Methoden vor, welche Login Sessions bereitstellen müssen. INotificationManager Die INotificationManager Schnittstelle enthält Methoden für das Abonnieren von Push-Benachrichtigungen. ISubscriber Ein abonnierter Push-Client wird über die Schnittstelle ISubscriber abstrahiert. Die Schnittstelle gibt Methoden vor, welche Push-Clients bereitstellen müssen. Tabelle 4: Übersicht der internen Schnittstellen 8 Client/Server Applikation mit Android

143 Systemspezifikation Softwarearchitektur Hochschule Luzern Externe Schnittstellen Schnittstelle android-support-v4 gson-2.1 httpclient ormlite-android-4.28 Allgemeine Beschreibung der Schnittstelle Das Support Package V4 wird von Android bereitgestellt, um ältere Android Plattformen mit neuen API Utilities zu ergänzen [24]. In der VMA wird das Support Package V4 für die Tab Indicators benötigt. GSON ist eine Library von Google, welche Java Objekte in JSON Strings umwandelt [25]. GSON wird vor allem in der Komponente IntegrationServiceConnector verwendet. Log Messages werden auf der VMA ebenfalls GSON-serialisiert gespeichert. Die VMA verwendet den HttpClient von Apache für die Kommunikation über das Hypertext Transfer Protocol. Dieser wird in der Http Components Library zur Verfügung gestellt [26]. ORMLite abstrahiert den Zugriff auf die Datenbank der VMA. Tabelle 5: Übersicht der externen Schnittstellen Vertec XML Schnittstelle Das Vertec ERP-System bietet eine XML Schnittstelle an, um Daten vom ERP-System abzufragen und zu erfassen. Diese Schnittstelle wird im vorliegenden Projektsystem verwendet, um mit dem ERP-System zu kommunizieren. Mit der Schnittstelle kann anhand vom Request / Response Schema kommuniziert werden. Das heisst, der Client formuliert eine XML-Anfrage und sendet diese via Http POST Request an den Vertec Server. Der Vertec Server bearbeitet die empfangene Anfrage und sende eine entsprechende XML-Antwort zurück [13] Aufbau der XML Message Die Grundstruktur besteht aus dem Grundelement Envelope und dem Unterelement Body. Diese Elemente sind in jeder Request oder Response Message enthalten. [13] Authentifizierung Bei jedem Request, welcher an den Vertec Server gesendet wird, muss eine Authentifizierung erfolgen. Deshalb wird bei jedem Request ein Header mitgesendet, welcher den Benutzername und das Passwort des jeweiligen Benutzers enthält. [13] <Envelope> <Body> </Body> </Envelope> Abbildung 4: Grundstruktur einer XML Message <Header> <BasicAuth> <Name>Administrator</Name> <Password>1234</Password> </BasicAuth> </Header> Abbildung 5: Authentifizierung gegenüber dem VertecServer Vertec Objekt abfragen Um Daten beim ERP-System abzufragen, wird der XML Request um ein Element namens Query erweitert. Die weiteren Elemente, welche für die Abfrage von Daten aus dem Vertec ERP-System benötigt werden, sind in der Beispielabfrage in Abbildung 6 und der darauffolgenden Tabelle 6 erläutert. Client/Server Applikation mit Android 9

144 Hochschule Luzern Systemspezifikation Softwarearchitektur <Envelope> <Header> <BasicAuth> <Name>Administrator</Name> <Password></Password> </BasicAuth> </Header> <Body> <Query> <Selection> <ocl> aktivitaet >select((erledigt.asstring='n') and (termin >= encodedate(2012,05,01))and (encodedate(2012,05,06) >= termin)) </ocl> </Selection> <Resultdef> <member>termin</member> <member>titel</member> <member>text</member> <member>projekt</member> <member>erledigtdatum</member> <member>modifieddatetime</member> <member>...</member> </Resultdef> </Query> </Body> </Envelope> Abbildung 6: Beispiel für eine Objektabfrage Element Selection Erklärung In diesem Element wird die Abfrage zusammengestellt. Selection kann die folgenden Unterelemente enthalten: ocl: Ist die Abfragesprache, welche in Vertec verwendet wird, um Objekte abzufragen. <ocl> aktivitaet >select((erledigt.asstring='n') and (termin >= encodedate(2012,05,01)) and (encodedate(2012,05,06) >= termin)) </ocl> Diese OCL-Abfrage lieferte alle Objekte vom Typ Aktivität zurück, welche noch nicht erledigt wurden deren Ausführungsdatum zwischen dem und dem liegt. objref: Um ein spezifisches Objekt anhand der Objekt ID abzufragen. sqlwhere: Damit können zusätzliche Filterkriterien angegeben werden. o (z.b. kann nachdem Datum gefiltert werden) sqlorder: darüber können Sortierkriterien definiert werden. 10 Client/Server Applikation mit Android

145 Systemspezifikation Softwarearchitektur Hochschule Luzern Resultdef Im Element Resultdef wird definiert, welche Attribute der abgefragten Objekte zurückgeliefert werden sollen. Im Element Resultdef können die Unterelement Member oder Expression vorkommen. Member: Über das Element Member kann direkt der Attributname, von welchem man den Wert anzeigen möchte, angegeben werden. Expression: Eine Expression hingegen kann wieder Logik enthalten, wie beispielswiese eine If-Else Bedingung oder Berechnungen. <expression> <alias>abgeschrieben</alias> <ocl>wertint wertext</ocl> </expression> Tabelle 6: Beschreibung der Elemente einer Vertec Abfrage [13] Das Resultat der Beispielabfrage wird im Element QueryResponse zurückgeliefert. Abbildung 7 veranschaulicht die XML Response exemplarisch: <Envelope> <Body> <QueryResponse> <Aktivitaet> </Aktivitaet> </QueryResponse> </Body> </Envelope> <objid>22537</objid> <adresseintrag> <objref>3222</objref> </adresseintrag> <dokpfad>c:/temp</dokpfad> <erledigtdatum> T23:13:25</erledigtDatum> <modifieddatetime> T15:34:53</modifiedDateTime> <phase><objref/></phase> <prioritaet>1</prioritaet> <projekt> <objref>14774</objref> </projekt> <termin> </termin> <text/> <titel>22537 Task with contact</titel> Abbildung 7: Mögliche Antwort auf eine Anfrage Client/Server Applikation mit Android 11

146 Hochschule Luzern Systemspezifikation Softwarearchitektur Vertec Objekt erzeugen Über das Element Create kann ein Objekt im Vertec ERP-System erstellt werden. Für das zu erzeugende Objekt wird der entsprechende Klassenname angegeben. Die Klasse OffeneLeistungen wird im vorliegenden Projektsystem verwendet, um den geleisteten Aufwand zu rapportieren. Ein Create Request kann ein oder mehrere zu erstellende Objekte enthalten. Die entsprechenden Member eines zu erstellenden Objekts können entweder direkt Werte enthalten oder aber eine Objektreferenz <objref> zu einem bestehenden Vertec Objekt [13]. <Envelope> <Header> <BasicAuth> <Name> Administrator</Name> <Password>1234</Password> </BasicAuth> </Header> <Body> <Create> <OffeneLeistung> <bearbeiter><objref>676</objref></bearbeiter> <projekt><objref>14780</objref></projekt> <phase></phase> <typ></typ> <text>router ausgewechselt</text> <minutenint>160</minutenint> <datum> </datum> </OffeneLeistung> </Create> </Body> </Envelope> Abbildung 8: Ein Vertec Create Request um ein Vertec Objekt zu erzeugen Als Antwort wird ein CreateResponse-Element zurückgeliefert, welches ein Unterelement mit dem Klassennamen des erzeugten Objekts enthält. Im folgenden Beispiel wurde ein Objekt mit dem Klassename OffeneLeistung erzeugt. Dies entspricht einer erfassten Leistung. Das Element mit dem Klassennamen enthält zwei Unterelemente. Das Element objid enthält die Objekt ID des erzeugten Objektes und das Element isvalid gibt an ob das erzeugte Objekt gültig (1 = gültig; 0 = ungültig) ist [13]. <Envelope> <Body> <CreateResponse> <OffeneLeistung> <objid>23108</objid> <isvalid>1</isvalid> </OffeneLeistung> </CreateResponse> </Body> </Envelope> Abbildung 9: Die Antwort auf einen Vertec Create Request 12 Client/Server Applikation mit Android

147 Systemspezifikation Softwarearchitektur Hochschule Luzern Vertec Objekte ändern Das Ändern von Vertec Objekten funktioniert ähnlich wie das Erstellen von Vertec Objekten. Anstelle eines Create Elementes wird für das Update ein Update Element verwendet. Zusätzlich muss die Objekt ID jenes Objektes mitgegeben werden, welches verändert werden möchte. Der Update Request erlaubt es analog zum Create Request mehrere Objekte in einem einzigen Request zu verändern. Abbildung 10 zeigt ein Beispiel eines Vertec Update Requests. <Update> <OffeneLeistung> <datum> T22:00:00Z</datum> <bearbeiter> <objref>22356</objref> </bearbeiter> <projekt> <objref>2873</objref> </projekt> <text>changed</text> <minutenint>78</minutenint> </OffeneLeistung> </Update> Abbildung 10: Ein Vertec Update Request (ohne Header) Als Antwort auf einen Update Request wird eine Update Response zurückgeliefert, welche die Anzahl der aktualisierten Objekte deklariert. Das Problem bei dieser Rückmeldung ist, dass nicht angegeben wird, welche Objekte aktualisiert wurden. Im Fehlerfall, also wenn z.b. drei von vier Updates ausgeführt wurden, kann nicht bestimmt werden, welche Update Requests erfolgreich ausgeführt wurden. Um das Problem zu umgehen muss für jedes Objekt einen separaten Update Request an die Vertec-Schnittstelle abgesetzt werden. <Envelope> <Body> <UpdateResponse> <text>updated 1 Objects</text> </UpdateResponse> </Body> </Envelope> Abbildung 11: Antwort auf einen Update Request Client/Server Applikation mit Android 13

148 Hochschule Luzern Systemspezifikation Softwarearchitektur 2.5 Datenstruktur Die Organisation der Informationen auf der Vertec Mobile App hängt im Wesentlichen von der Datenstruktur des Vertec ERP-Systems ab. Laut Kundenanforderung [KUNAF] wird ein Synchronisationsmechanismus zwischen VMA und Vertec ERP gewünscht, welcher das Arbeiten im Offlinemodus d.h. ohne Internetverbindung ermöglicht. Um diesem Wunsch nachzukommen, musste das Datenmodell entsprechend angepasst werden. Das ER-Diagramm in Abbildung 12 zeigt die Datenstruktur, mit welcher in der VMA gearbeitet wird. Vollständigkeitshalber sei erwähnt, dass der Vertec Integration Service keine eigene Datenbank unterhalten muss. Abbildung 12: Physisches Entity-Relationship Modell der Vertec Mobile App Gemeinsame Attribute Die meisten Attribute der jeweiligen Datentypen korrelieren mit den Feldern, welche im Vertec Datenmodell vorzufinden sind. Beispielsweise besitzt jede Entität ein Integer-Feld mit der Bezeichnung id, welches die eindeutige Objekt ID eines Vertec Objekts enthält. Ebenfalls bei allen Typen gemeinsam sind die Felder editstatusvis, editstatusvma und modifieddate. Das Attribut editstatusvma wird für das Erkennen von lokalen Veränderungen verwendet. Das Attribut editstatusvis wird verwendet, damit der VMA Benutzer über den Änderungsstatus von empfangenen Objekten informiert werden kann. Der letzte Änderungszeitpunkt eines Objektes wird im Attribut modifieddate gespeichert. Dabei handelt es sich immer um den Zeitpunkt, zu welchem ein bestimmtes Objekt auf dem Vertec ERP-System geändert wurde. 14 Client/Server Applikation mit Android

149 Systemspezifikation Softwarearchitektur Hochschule Luzern Ein Objekt kann vom Vertec ERP oder von der VMA verändert werden. Änderungen, welche von der VMA vorgenommen werden, sind autoritativ. Weitere Informationen diesbezüglich sind im Synchronisationskonzept im Kapitel 4.7, Seite 40, zu finden Beschreibung der Entitäten Entität task customer projekt phase service servicetype Beschreibung Diese Tabelle enthält die Aufträge, welche vom angemeldeten Mitarbeiter ausgeführt werden sollen. Des Weitern sind in der Tabelle task die sog. Favoriten Aufträge enthalten. Es handelt sich dabei um Aufträge, welche keinem spezifischen Mitarbeiter zugewiesen sind oder kein bestimmtes Ausführungsdatum enthalten. Dadurch kann der Projektleiter beispielsweise einen Auftrag für administrative Tätigkeiten erfassen, welcher für jeden Mitarbeiter sichtbar ist. Dadurch muss der Auftrag nicht für jeden Mitarbeiter angelegt werden. Aufträge, die nicht einem spezifischen Mitarbeiter zugewiesen sind, werden mit dem Attribut unassignedtask gekennzeichnet. In der Tabelle Customer werden die Kontaktdaten eines Kunden gespeichert, für welchen ein Auftrag ausgeführt werden muss. Im Vertec ERP-System gibt es verschiedene Objekte (Firma, Kontakt), welche als Kunde für einen Auftrag angegeben werden können. In der VMA Datenbank werden die Vertec Objekte Firma und Kontakt in einer gemeinsamen Tabelle gespeichert. Dadurch ist es möglich, dass einzelne Felder keine Werte enthalten. Bei einer Firma wären beispielsweise die Felder firstname und lastname leer. Die Projekt Tabelle enthält die Projekte, für welche der angemeldete Benutzer Aufträge ausführen soll. Ein Projekt kann in mehrere Phasen unterteilt werden. Die Aufträge und Leistungen können einer Phase zugeordnet werden, sofern das Projekt Phasen besitzt. Für einen erledigten Auftrag kann dem Kunden die erbrachte Leistung in Rechnung gestellt werden. In dieser Tabelle werden die erfassten Leistungen gespeichert. Neben dem Attribute id ist in dieser Tabelle ein Attribut tempid enthalten. Wenn mit der VMA eine neue Leistung erfasst wird, wird der Leistung beim Persistieren in der Datenbank eine temporäre ID tempid zugewiesen. Der Wert für das Attribut id wird erst gesetzt, wenn das ERP-System bestätigt, dass die Leistung erfolgreich angelegt werden konnte. Im Vertec ERP-System können mehrere Typen von Tätigkeiten verwaltet werden. Diese Typen haben einen Einfluss darauf, ob eine Leistung dem Kunden verrechnet werden kann. Beispielsweise könnte eine Tätigkeit Offerten Erstellung angelegt werden, bei welcher die darauf verbuchten Leistungen nicht dem Endkunden belastet werden. Die Geschäftslogik des ERP-Systems entscheidet letztlich, welche Leistungen dem Kunden verrechnet werden. Tabelle 7: Beschreibung der Entitäten Client/Server Applikation mit Android 15

150 Hochschule Luzern Systemspezifikation Softwarearchitektur 2.6 Klassenübersicht Die Klassenansicht zeigt präzise Informationen über die Konstellation der einzelnen Klassen und den eingesetzten Schnittstellen. Der besseren Übersicht halber wurden einige Schnittstellen, Klassen, Member Variablen und Methoden ausgeblendet. Es wurde versucht, die Elemente so anzuordnen, dass sich Parallelen zum Komponentendiagramm (Abbildung 3, Seite 5) finden lassen. Abbildung 13 zeigt ein Klassendiagramm der VMA. Das Konstrukt um die Klasse VertecAPI bildet den Einstiegspunkt der VMA. IVertec fasst sowohl Methoden der Authentifizierungsschnittstelle (IAuthentication) wie auch der Datenbankschnittstelle (IVertecBase) zusammen. So müssen Anwender der VertecAPI nicht ständig zwischen IAuthentication und IVertecBase casten, wenn sie entsprechende Methoden ausführen wollen. Die Synchronisationslogik um die Klasse SyncManager wird in der VertecAPI nicht referenziert. UI Komponenten platzieren Synchronisationsanfragen immer beim Android SyncService (nicht aufgeführt). Dieser besitzt seinerseits eine Referenz auf den SyncManager. Der IntegrationServiceConnector wird in den meisten Fällen direkt vom SyncManager verwendet, um Vertec Objekte zu lesen resp. zu schreiben. Eine Ausnahme bilden die Authentifizierungsmethoden, login(string, String) und checklogin(). Diese beiden Methoden müssen Anfragen direkt über den IntegrationServiceConnector und ferner über die Webschnittstelle (HttpClient) an den VIS senden. Der IntegrationServiceConnector initialisiert eine Instanz von GSON, dem JSON Serializer von Google [3]. Er ist somit verantwortlich für die korrekte Umwandlung von JSON Strings in Java Objekte und umgekehrt. Speziell an der Klasse HttpClient ist, dass diese die Standard-HttpClient Klasse von Apache um einen AsyncTask erweitert. Dieser AsyncTask kann so paradox es klingt synchron wie auch asynchron ausgeführt werden. Asynchrone Aufrufe werden beispielsweise bei Push Notification benötigt. Ansonsten kommen ausschliesslich synchrone Aufrufe zum Einsatz. 16 Client/Server Applikation mit Android

151 Systemspezifikation Softwarearchitektur Hochschule Luzern IServiceInfo «interface» interfaces::ivertec api::vertecapi - dataaccess: IVertecBase - serviceconnector: IAuthentication «interface» interfaces::iauthentication + checklogin() : boolean + login(string, String) : String + checklogin() : boolean + cleardatabase() : void + deleteobject(t) : int + getobject(class<t>, int, boolean) : T + getobjects(class<t >) : Li st<t > + login(string, String) : String + updateobject(t) : CreateOrUpdateStatus -serviceconnector «interface» interfaces::iintegrationserviceconnector + updateobjects(class<t>, List<T>, List<Integer>, Date) : List<T> -serviceconnector -dataaccess «interface» interfaces::ivertecbase + cleardatabase() : void + deleteobject(t) : int + getobject(class<t>, int, boolean) : T + getobjects(class<t>) : List<T> + updateobject(t) : CreateOrUpdateStatus -dataaccess - conn: IHttpClient - gson: Gson - sessionid: String service::integrationserviceconnector + checklogin() : boolean + IntegrationServiceConnector() + IntegrationServiceConnector(IHttpClient) + login(string, String) : String + updateobjects(list<t>, List<Integer>, Date) : List<Task> service::syncmanager - dataaccess: IVertecBase - lastsync: Date = new Date(0l) - serviceconnector: IIntegrationServiceConnector + SyncManager(Context) + update() : void - update(class<t>)() : List<T> data::dataaccess - context: Context - dbhelper: DatabaseHelper + cleardatabase() : void + DataAccess(Context) + deleteobject(t) : int + getobject(class<t>, int, boolean) : T + getobj ects(cl ass<t >) : Li st<t > + updateobject(t) : CreateOrUpdateStatus -instance -conn «interface» interfaces::ihttpclient + createrequest(string, String, JsonElement) : JsonElement + createrequest(string, String, JsonElement, ICallbackHandler<AsyncTaskResult<JsonElement>>) : void DefaultHttpClient OnSharedPreferenceChangeListener - exceptiondispatcher: ExceptionDispatcher - serviceurl: String + createrequest(string, String, JsonElement) : JsonElement + createrequest(string, String, JsonElement, ICallbackHandler<AsyncTaskResult<JsonElement>>) : void - getresponse(httpentity) : JsonElement Abbildung 13: Klassenansicht der VMA In Abbildung 14 wird ein Klassendiagramm von VIS gezeigt. Das Interface IVertecIntegration wurde als WCF Schnittstelle entworfen. Die effektive Logik hinter diesem Web Interface liegt in der Klasse VertecIntegrationService. Leider konnten die Methoden in VertecIntegrationService nicht generisch implementiert werden. Der Grund dafür liegt in der Serialisierung von WCF, welche generische Typen nicht unterstützt. Die Methoden in VertecIntegrationService bedienen sich im Wesentlichen von den drei angefügten Komponenten, SessionManagement, VertecConnector und PushNotification. Gemeinsam genutzte Schnittstellen, Datentypen und Utilities wurden in eine Common Komponente ausgelagert. (Common wurde in Abbildung 14 nicht aufgeführt). Client/Server Applikation mit Android 17

152 Systemspezifikation Softwarearchitektur Hochschule Luzern VertecIntegrationService::VertecIntegration ContextBoundObject «interface» VertecIntegrationService::IVertecIntegration + CheckLogin() : bool + GetSupportInfo() : string[] + GetVersion() : String + Login(String, String) : String + SubscribeTaskUpdates(List<Task>, List<Int32>, DateTime) : Int32 + UpdateCustomers(List<Customer>, List<Int32>, DateTime, DateTime) : List<Customer> + UpdatePhases(List<Phase>, List<Int32>, DateTime, DateTime) : List<Phase> + UpdateProjects(List<Project>, List<Int32>, DateTime, DateTime) : List<Project> + UpdateServices(List<Service>, List<Int32>, DateTime, DateTime) : List<Service> + UpdateServiceTypes(List<ServiceType>, List<Int32>, DateTime, DateTime) : List<ServiceType> + UpdateTasks(List<Task>, List<Int32>, DateTime, DateTime) : List<Task> - notificationmanager: INotificationManager - sessionmanager: ISessionManager - vertecconnector: IVertecConnector - webcontextmanager: WebContextManager {readonly} + CheckLogin() : bool + GetSupportInfo() : string[] + GetVersion() : string + Login(String, String) : String - SetNotificationManager(NotificationManager) : void + SetSessionManager(ISessionManager) : void + SetVertecConnector(IVertecConnector) : void + SubscribeTaskUpdates(List<Task>, List<Int32>, DateTime) : Int32 + UpdateCustomers(List<Customer>, List<Int32>, DateTime, DateTime) : List<Customer> + UpdatePhases(List<Phase>, List<Int32>, DateTime, DateTime) : List<Phase> + UpdateProjects(List<Project>, List<Int32>, DateTime, DateTime) : List<Project> + UpdateServices(List<Service>, List<Int32>, DateTime, DateTime) : List<Service> + UpdateServiceTypes(List<ServiceType>, List<Int32>, DateTime, DateTime) : List<ServiceType> + UpdateTasks(List<Task>, List<Int32>, DateTime, DateTime) : List<Task> + VertecIntegration() -sessionmanager -vertecconnector -notificationmanager «interface» SessionManagement::ISessionManager «interface» SessionManagement::ISession «interface» VertecConnector::IVertecConnector «interface» PushNotification::INotificationManager «interface» PushNotification::ISubscriber + AddSession(String, int, String) : Guid + FindSession(String) : ISession + FindSession(Guid) : ISession + IsValidSession(Guid) : bool + ReactivateSession(Guid) : void + RemoveSession(Guid) : void + RemoveSession(String) : void + Reactivate(TimeSpan) : void «property» + IsValid() : bool + Password() : string + Sessi onid() : Gui d + UserId() : int + Username() : string + Login(String, String) : int + Sync(string, string, int, IEnumerable<IVertecType>, List<int>, DateTime, DateTime) : List<T> + NewSubscription(UpdateDelegate<T>, List<T>, List<int>, DateTime) : ISubscriber<T> «property» + Subscribers() : List<ISubscriber<IVertecType>> + Start(int, int) : IEnumerable<T> «property» + Id() : Guid «event» + UpdateEvent() : UpdateEventHandler<IVertecType> «use» «use» T SessionManagement::SessionManager SessionManagement::Session VertecConnector::VertecConnector PushNotification::NotificationManager PushNotification::Subscriber - instance: volatile SessionManager - sessi ons: Li st<isessi on> -instance - SyncRoot: object = new Object() {readonly} + AddSession(String, int, String) : Guid + FindSession(String) : ISession + FindSession(Guid) : ISession + IsValidSession(Guid) : bool + ReactivateSession(Guid) : void + RemoveSession(Guid) : void + RemoveSession(String) : void - SessionManager() «property» + Instance() : SessionManager - password: String {readonly} - sessionexpi ration: DateT im e - sessionid: Guid {readonly} - userid: int {readonly} - username: String {readonly} + Reactivate(TimeSpan) : void + Session(String, int, String) «property» + IsValid() : bool + Password() : string + Sessi onid() : Gui d + UserId() : int + Username() : string - conn: IHttpClient {readonly} - vertecrequestbuilder: VertecRequestBuilder {readonly} - vertecserializer: IVertecSerializer {readonly} - CalculateLastSync(DateTime, DateTime) : DateTime - Create(string, string, int, IEnumerable<IVertecType>) : List<T> - Get(string, string) : IEnumerable<T> + Login(string, string) : int + Sync(string, string, int, IEnumerable<IVertecType>, List<int>, DateTime, DateTime) : List<T> - Update(string, string, IEnumerable<IVertecType>) : List<T> + VertecConnector(IHttpClient, IVertecSerializer) -conn «interface» VertecConnector::IHttpClient - instance: volatile NotificationManager - subscribers: List<ISubscriber<IVertecType>> {readonly} -instance - SyncRoot: object = new Object() {readonly} + NewSubscription(UpdateDelegate<T>, List<T>, List<int>, DateTime) : ISubscriber<T> - NotificationManager() - SubscriberUpdateEvent(object, UpdateEventArgs<T>) : void «property» + Instance() : NotificationManager + Subscribers() : List<ISubscriber<IVertecType>> - idlist: List<int> {readonly} - lastsync: DateTime {readonly} - objectlist: List<T> {readonly} - resultlist: List<T> - stop: bool = false - updatedelegate: UpdateDelegate<T> {readonly} + Start() : IEnumerable<T> + Start(int, int) : IEnumerable<T> + Stop() : void + Subscriber(UpdateDelegate<T>, List<T>, List<Int32>, DateTime) «property» + Id() : Guid «event» + TaskUpdateEvent() : UpdateEventHandler<IVertecType> + CallHttpPOST(String) : string VertecConnector::HttpClient - serviceurl: string + CallHttpPOST(String) : string + HttpClient(string) Abbildung 14: Klassenansicht des VIS Client/Server Applikation mit Android 18

153 Systemspezifikation Softwarearchitektur Hochschule Luzern 2.7 Softwareverteilung Um das Projektsystem in den produktiven Betrieb überführen zu können, sind einige Zusatzinformationen notwendig. Dieses Unterkapitel zeigt die Verteilungs- und Betriebssicht des Projektsystems und erläutert, welche Punkte bei der Einführung zu beachten sind Verteilungsansicht Die Verteilung der Software kann prinzipiell auf verschiedene Arten vorgenommen werden, da sämtliche Komponenten individuell konfigurierbar sind. Der bevorzugte Fall wird in der nachfolgenden Verteilungsansicht (Abbildung 15) illustriert. Es wird vorgeschlagen, dass ein Unternehmen, welches die VMA einsetzen will, die entsprechenden Android Geräte vorgängig mit der VMA Software (VMA-release.apk) bestückt und ihren Bedürfnissen entsprechend konfiguriert. Der Vertec Integration Service wird vorzugsweise auf denselben Server installiert, wie das Vertec ERP-System. Der Grund dafür ist die fehlende Verschlüsselung zwischen VIS und dem ERP-System. An dieser Stelle sei auf die Environment-Anforderungen in Kapitel 5 (Seite 51) hingewiesen, welche aufschlussreiche Informationen über die einzusetzenden Betriebssysteme und Zusatzsoftware geben. Abbildung 15: Verteilungsansicht Konfiguration der Komponenten In den nachfolgenden Abschnitten werden die wichtigsten Konfigurationsattribute der einzelnen Softwarekomponenten aufgelistet und beschrieben. Einige Komponenten werden zwar in Konfigurationsdateien aufgeführt, haben aber für die individuelle Parametrisierung der Software keinen Einfluss. Diese irrelevanten Attribute werden der besseren Übersicht halber nicht aufgeführt. Client/Server Applikation mit Android 19

154 Hochschule Luzern Systemspezifikation Softwarearchitektur Konfiguration der VMA Die Konfiguration der Vertec Mobile App befindet sich im Applikationspaket (APK) und wird zusammen mit den Binaries der Software ausgeliefert. Android Installationspakete erlauben keine Parametrisierung zur Installationszeit. Anpassungen an die Standardkonfiguration müssen nach der Installation und vor der Auslieferung an die Endanwender vorgenommen werden. Attribut serviceurl Konfigurationsbeispiel {Wertebereich} 1 lab.ch/vertecintegra tion.svc Beschreibung Die serviceurl ist der Service Endpunkt des Vertec Integration Services. Angegeben wird die gesamte URL, wie sie von Clients aufgelöst werden kann. In den meisten Anwendungsfällen muss der DNS Name (im Konfigurationsbeispiel: vis.enterpriselab.ch) im Internet aufgelöst werden können. autosyncmode true {true, false} autosyncinterval { } Das Attribut autosyncmode aktiviert die automatische Synchronisation, welche nach dem in autosyncinterval definierten Intervall repetitiv ausgeführt wird. Das Intervall wird als Ganzzahlwert in Sekunden angegeben. initialsync pushnotification true {true, false} false {true, false} IntitialSync entscheidet, ob beim Starten der Anwendung eine Synchronisation ausgelöst werden soll. Dieses Attribut aktiviert den Push Notification Service, welcher Benachrichtigungen über Änderungen an den Auftragsinformationen automatisch an betroffene VMA Clients sendet. connectiontimeout 15 {0 60} sockettimeout 15 {0 60} Das Connection Timeout definiert die Zeitspanne, welche während einem Verbindungsaufbau maximal verstreichen darf, bis der Versuch abgebrochen wird. Eine TCP Verbindung gilt erst dann als hergestellt, wenn der TCP Handshake abgeschlossen ist. Der Wert 0 deaktiviert das Timeout. Das Socket Timeout definiert die Zeitspanne, welche während einem Lese-/Schreibvorgang auf einem TCP Socket maximal verstreichen darf, bis der Versuch abgebrochen wird. Der Wert 0 deaktiviert das Timeout. 1 Der angegebene Wertebereich bezieht sich nicht auf technische Minimal- bzw. Maximalwerte, sondern um sinnvolle Randbereiche. 20 Client/Server Applikation mit Android

155 Systemspezifikation Softwarearchitektur Hochschule Luzern rememberlogin calloption true {true, false} DIAL {DIAL, CALL} Wird rememberlogin aktiviert, so speichert die VMA App den letzten Benutzernamen und die dazugehörige SessionID. Achtung: Dieses Feature ist grundsätzlich sicher, da die sensiblen Informationen im privaten Speicherbereich der Anwendung abgelegt werden. Es hängt aber davon ab, wie lange die Gültigkeitsdauer von Sessions konfiguriert wurde. (Siehe Konfigurationsattribut SessionExpiration unter Vertec Integration Service). Das Attribut calloption bezieht sich auf den Umgang mit Telefonnummern, welche in der VMA angezeigt werden. Die Option DIAL wählt eine Telefonnummer, sodass der Anwender selber entscheiden kann, ob er die Nummer anrufen will. Die CALL Option hingegen tätigt unmittelbar einen Anruf der gewählten Nummer. logsize 3 {1 10} Die VMA App nutzt ein zentrales Logsystem, um Laufzeit- Informationen über aufgetretene Ereignisse aufzuzeichnen. Das Attribut logsize bestimmt die Grösse der Logdatei in Megabyte (MB). Kleine Log-Dateien haben den Vorteil, dass sie schneller geöffnet und versendet werden können, während grössere Dateien ein vollständigeres Bild von möglichen Fehlfunktionen geben können. loglevel ALL {ALL, FINEST, FINER, FINE, CONFIG, INFO, WARNING, SEVERE, OFF} Wie der Name des Attributs bereits impliziert, wird hier bestimmt, welche Ereignisse im Log aufgezeichnet werden sollen. Die Log Levels sind hierarchisch geordnet und schliessen sich in absteigender Reihenfolge ein [16]. (Beispiel: Das Log Level INFO zeichnet auch Meldungen des Levels WARNING auf nicht aber umgekehrt). logtaillimit 20 {0 100} Um die Wartezeit beim Anzeigen von Log-Nachrichten zu minimieren, kann die Anzahl anzuzeigender Log-Einträge beschränkt werden. Die konfigurierte Zahl bestimmt die Anzahl Einträge vom Ende des Logs (d.h. die aktuellsten Einträge), welche im integrierten Log Viewer angezeigt werden sollen. Tabelle 8: Konfigurationsattribute von VMA Client/Server Applikation mit Android 21

156 Hochschule Luzern Systemspezifikation Softwarearchitektur Konfiguration von VIS Der auf Microsoft.Net basierende Vertec Integration Service übernimmt das von Microsoft vorgegebene Konfigurationskonzept. Dieses erwartet Konfigurationsattribute nur in der zentralen Konfigurationsdatei, der.config Datei. Alle konfigurierbaren Attribute, welche von VIS oder einer referenzierten Komponente benötigt werden, müssen folglich in Web.config angepasst werden. Attribut Konfigurationsbeispiel {Wertebereich} 2 Beschreibung IntegrationService.svc VertecXMLServiceURL MethodCallLogging LogLevel Common.dll ml True {True, False} Information {All, ActivityTracing, Verbose, Information, Warning, Error, Critical, Off} Das Attribut gibt an, unter welcher Adresse der XML Web Service des Vertec ERP-System zu finden ist. Methodenaufrufe können bei der Fehlersuche von entscheidender Bedeutung sein. Dieses Attribut aktiviert das Logging pauschal für sämtliche Methodenaufrufe. Die Granularität der Log-Informationen kann auch auf dem Integration Service bestimmt werden. Log Levels sind hierarchisch geordnet und schliessen sich in absteigender Reihenfolge ein [15]. (Beispiel: Das Log Level Information zeichnet auch Meldungen des Levels Warning auf nicht aber umgekehrt) VertecDateFormat yyyy MM dd Das Datumsformat, welches von der Vertec XML Schnittstelle verwendet wird. VertecDateTimeFormat yyyy MM dd\thh:mm:ss Das kombinierte Datums- und Zeitformat, welches von der Vertec XML Schnittstelle verwendet wird. SessionManagement.dll SessionExpiration 00:00:30 {00:00:01 01:00:00} Die Gültigkeitsdauer von Sessions wird über dieses Attribut bestimmt. Das Datenformat dieses Attributs ist Time- Span und definiert eine bestimmte Zeitspanne. (01:02:03 ist gleichbedeutend mit einer Zeitspanne von einem Tag, zwei Stunden und drei Minuten). 2 Der angegebene Wertebereich bezieht sich nicht auf technische Minimal- bzw. Maximalwerte, sondern um sinnvolle Randbereiche. 22 Client/Server Applikation mit Android

157 Systemspezifikation Softwarearchitektur Hochschule Luzern PushNotification.dll PollingInterval 20 {10 300} Wegen fehlendem Notification Service seitens Vertec ERP muss der Integration Service periodisch prüfen, ob sich diejenigen Daten verändert haben, für welche sich ein VMA Client interessiert. Das Intervall dieser Abfragen wird in diesem Attribut festgelegt. MaxIterations 0 Um einem möglichen Lifelock vorzubeugen, kann das Polling auf eine maximale Anzahl Iterationen beschränkt werden. Das Erreichen von MaxIteration beantwortet die offene Http-Anfrage der VMA. VertecConnector.dll AvgRoundTripTime 1 {1 10} Bestimmt die durchschnittliche Zeit, welche eine Anfrage von einer VMA braucht, bis diese beim Integration Service eintrifft und verarbeitet werden kann. RangeOfTaskDatePeriod 1 Definiert die Länge der Datumsperiode für die Synchronisation. Der Wert 1 bedeutet, dass die Datumsperiode der aktuelle Tag +/- 1 Tag umfasst. Alle Aufträge, welche in dieser Datumsperiode liegen, werden bei einer Synchronisation auf Änderungen geprüft. SyncTolerance 20 Bestimmt einen Toleranzwert in Sekunden, welcher in die Berechnung des lasysync Zeitstempels miteinbezogen wird. Zum einen wird damit die Ungenauigkeit des last Sync Zeitstempels abgefangen. Denn die Berechnung des lastsync Zeitstempels ist nur eine Annäherung an den korrekten Wert. Zudem könnten Änderungen, welche während einem Synchronisationsdurchlauf vorgenommen werden, verloren gehen. Dies kann passieren, da der lastsync Zeitstempel auf der VMA erst am Ende des gesamten Sychronisationsvorgangs gesetzt wird. Wenn der Toleranzwert zu gross ist, kann es sein, dass Änderungen mehrmals zurückgeliefert werden. Wenn dieser Wert zu klein ist, besteht die Gefahr das Änderungen nicht an die VMA kommuniziert werden. Der Toleranzwert sollte mindestens die durchschnittliche Zeit eines gesamten Synchronisationsdurchlaufes (aller Objekte) betragen. {Type}Request {Type}ReplaceDate {Type}Member Siehe Parametrisierung der Vertec Read-Requests {Type}Expression Tabelle 9: Konfigurationsattribute von VIS Client/Server Applikation mit Android 23

158 Hochschule Luzern Systemspezifikation Softwarearchitektur Parametrisierung der Vertec Read-Requests Die vom VIS benötigten OCL Read-Requests um Vertec Datenobjekte beim ERP-System abzufragen, sind individuell konfigurierbar. Diese Flexibilität wurde im Hinblick auf veränderbare Gegebenheiten seitens Vertec XML-Schnittstelle eingebaut. Falls sich die OCL Abfragen in Zukunft ändern sollten, könnten diese ganz bequem über die Konfiguration von VIS geändert werden. Folgende vier Parameter können in VIS für jedes Vertec Datenobjekt definiert werden: {Type}Request: Die OCL Abfrage definiert, welche Objekte zurückgeliefert werden sollen. Für das Auftrags-Objekt werden alle Aktivitäten vom Typ Auftrag abgefragt, welche dem angemeldeten VMA Benutzer oder keinem Benutzer zugewiesen sind und in der angegebenen Periode liegen. Konfigurationsbeispiel für die Abfrage eines Auftages: aktivitaet >select(((zustaendig=timsession.allinstances >first.login) or (zustaendig >isempty)) and (typ.asstring='auftrag') and (erledigt.asstring='n') and (((termin >= encodedate( {0}, {1}, {2})) and (encodedate( {3}, {4}, {5} ) >= termin)) or termin.isnull)) {Type}ReplaceDate: Wenn der boolean-wert ReplaceDate auf True gesetzt ist, werden die Werte {0}, {1} usw. im Request mit den Werten der aktuellen Datumsperiode ersetzt. {Type}Member: Mit diesem Parameter werden die Vertec-Attribute definiert die von den Objekten ausgelesen werden möchten. Der Parameter Member ist ein String, welcher kommasepariert die einzelnen Vertec-Attribute aufnimmt. Konfigurationsbeispiel für die Abfrage eines Auftrages: termin,titel,text,projekt,erledigtdatum,modifieddatetime,prioritaet,dokpfad,phase,zustaend ig {Type}Expression: Bei den Expression handelt es sich ebenfalls um ein String welcher die Rückgabewerte der einzelne Objekte definiert. Im Gegensatz zu den Member kann eine Expression Logik enthalten. Eine Expression wird beispielsweise eingesetzt um zu erkennen, ob einem Auftrag eine Kontaktperson oder eine Firma zugewiesen ist. Eine Expression besteht aus einem Namen und der Logik, die definiert, welcher Wert zurückgeliefert werden muss. Es können mehrere, durch (Pipe) separierte Expressions definiert werden. Für die Abfrage der Aufträge sind beispielsweise zwei Expressions definiert: createdby,erfasser.name adresseintrag,if adresseintrag >isempty.asstring='y' then (projekt.kunde.boldid.asstring) else adresseintrag.boldid.asstring endif Die Parameter Request und Member müssen für jeden Datentyp, von welchem Objekte synchronisiert werden, festgelegt werden. Die Parameter ReplaceDate und Expression hingegen sind optional. In der Konfiguration wird der Platzhalter {Type} durch den Namen des jeweiligen Vertec Datentyps (z.b. Task) ersetzt. Beispiel: TaskRequest, TaskMember, usw. Anpassungen, welche nur die Parameter Request und ReplaceDate betreffen, bedingen keine Änderungen am Source Code von VIS und VMA. Werden jedoch zusätzliche Rückgabewerte über den Parameter Member oder Expression festgelegt, dann muss die entsprechende Enitätsklasse sowie der dazugehörige Serializer für das betroffene Datenobjekt angepasst werden. 24 Client/Server Applikation mit Android

159 Systemspezifikation UI-Konzept Hochschule Luzern 3 UI-Konzept Während der Entwicklung wurde festgestellt, dass das ursprüngliche Konzept, welches in [KUNAF] für den Aufbau der Benutzerschnittstelle definiert wurde, nicht ausreichend war. Dies hatte einerseits mit dem fehlenden Know-How im Projektteam bezüglich den vorhandenen Android UI-Komponenten zu tun. Anderseits war es zu Beginn des Projektes schwierig voraus zu sehen, welche Möglichkeiten dem Benutzer geboten werden müssen, um eine effiziente Arbeitsweise mit der Applikation zu ermöglichen. 3.1 Übersicht Für die Benutzer einer neuen Anwendung ist es immer schwierig, sich im Dschungel der Benutzerschnittstelle zurechtzufinden. Als Starthilfe könnte hier die Abbildung 16 dienlich sein. Sie zeigte eine Übersicht über alle Android Activities, welche in der VMA vorkommen. Abbildung 16: Überblick über die verschiedenen Android Activities 3.2 Look & Feel Beim Design der Benutzerschnittstelle wurde hohen Wert auf den Wiedererkennungswert des Vertec Corporate Design gelegt. Farben und Icons wurden grösstenteils von Vertec übernommen. Die folgenden Abschnitte zeigen, welche Gadgets eingebaut wurden, um das Arbeiten mit der VMA zu einem emotionalen Erlebnis zu machen. Client/Server Applikation mit Android 25

160 Hochschule Luzern Systemspezifikation UI-Konzept Dashboard Nach erfolgtem Login wird dem Benutzer das Dashboard gezeigt. Oberstes Prinzip des Dashboards: Es soll übersichtlich und informativ sein. Im derzeitigen Release wird ein Menüpunkt für die Aufträge sowie einer für die Leistungen angezeigt. Der Benutzer muss lediglich das Listenelement berühren und schon gelangt er in die Auftrags- resp. Leistungsübersicht. Abbildung 17: Das Dashboard als Einstiegspunkt Icons und Grafiken Für die zwei Hauptobjekte Auftrag und Leistung, welche über die VMA verwaltet werden können, werden die aus Vertec bekannten Icons verwendet. Durch die Verwendung der Icons soll für den Benutzer der Wiedererkennungswert verstärkt werden. Icon Beschreibung Dieses Icon wird in Vertec für Aktivitäten verwendet. Ein Auftrag ist in Vertec eine Aktivität mit dem Typ Auftrag. Deshalb wird dieses Icon in der VMA verwendet um Aufträge darzustellen. Diese Icon repräsentiert in Vertec sowie in der VMA eine Leistung Navigation Aufträge und Leistungen können durch Auswählen des jeweiligen Listenelements geöffnet werden. Klickbare Elemente sind immer mit einem der Funktion naheliegenden Icon oder mit dem Standard Navigationsicon versehen. Tabelle 10: Vertec Icons Icon Beschreibung Standard Navigationsicon Anruf ausführen Wegstrecke aufzeigen Tabelle 11: Android Icons Kann über ein Attribut eines Objektes navigiert werden, wird der Attributwert als Link dargestellt. Es kann jeweils über das gesamte Feld zur nächsten Activity navigiert werden und nicht nur über der Attributwert, welcher als Link dargestellt wird. Abbildung 18: Zeigt wie ein klickbarer Attributwert visualisiert wird 26 Client/Server Applikation mit Android

161 Systemspezifikation UI-Konzept Hochschule Luzern Berührt der VMA Benutzer ein klickbares Feld, so wird dies optisch hervorgehoben, indem der Hintergrund des Feldes grau dargestellt wird. Dadurch kann der VMA Benutzer seine Bewegungen mitverfolgen und klickbare Element erkennen. Abbildung 19: Ein Listenelement vor (links) und während (rechts) einer Berührung Schaltflächen haben dasselbe Verhalten. Auch sie wechseln die optische Erscheinung bei einer Berührung Sync Bar Die Sync Bar informiert den VMA Benutzer über die letzte erfolgreiche Synchronisation. Zusätzlich kann über die Sync Bar eine Synchronisation manuell gestartet werden. Die Sync Bar wird auf jeder Übersichts-Activity angezeigt, damit der VMA Benutzer sehen kann, wie aktuell die Daten sind mit welchen er arbeitet. Als Übersichts-Activity gelten die Activities, auf welchen der Benutzer eine Übersicht über die Aufträge oder Leistungen gewinnen kann. Konkret sind dies die Auftrag- und Leistungslisten, sowie das Dashboard. Abbildung 20: Sync Bar gibt Auskunft über die letzte Synchronisation Auftragsliste Die abzuarbeitenden Aufträge sind in vier Auftragslisten aufgeteilt. Es gibt eine Liste für den aktuellen, morgigen und gestrigen Tag. Zusätzlich gibt es eine Liste, die favorisierte Aufträge anzeigt. Als Favorit gilt ein Auftrag, welcher keiner Person zur Erledigung zugewiesen ist oder ein Auftrag ohne Erledigungsdatum. Der VMA Benutzer kann über die Tabs oder mit horizontalem scrollen durch die Auftragslisten navigieren. Wenn der VMA Benutzer über das Dashboard die Aktivität mit den Auftragslisten öffnet, wird die Auftragsliste des aktuellen Tages angezeigt. Innerhalb der Auftragsliste werden die Aufträge nach Prioritäten gruppiert aufgelistet. Dabei erscheinen die Aufträge mit der höchsten Priorität zuoberst in der Liste. Abbildung 21: Auftragsliste zeigt die Aufträge gruppiert nach den Prioritäten Client/Server Applikation mit Android 27

162 Hochschule Luzern Systemspezifikation UI-Konzept Leistungsliste Die Liste mit den Leistungen wird ebenfalls über das Dashboard geöffnet. Alle lokal vorhandenen Leistungen werden in einer Liste nach dem Ausführungsdatum sortiert angezeigt. Die Liste enthält alle Leistungen, welche der angemeldete Benutzer erbracht hat und einem Projekt zugewiesen sind für welches der angemeldete Benutzer einen offenen Auftrag besitzt. Hinweis für produktiven Betrieb Es ist schwierig abzuschätzen, welche Leistungen der Benutzer wirklich auf seinem Geräte verwalten möchte. Deshalb müsste mit einem Feldtest überprüft werden, ob die angewandten Selektions- und Sortierkriterien tatsächlich sinnvoll sind Activity Animationen Wird durch die Berührung eines Elementes eine neue Android Activity geöffnet, so wird die neue Aktivität immer von rechts nach links eingeschoben. Benutzt der VMA Benutzer den Back Button, um eine Stufe zurück zu navigieren, wird die vorherige Activity von links nach rechts eingeschoben Darstellung der Vertec Objekte Die Attributnamen und Attributwerte eines Vertec-Objektes werden in einem Feld angezeigt. Die Felder sind jeweils mit einer Linie voneinander unterteilt. Enthält ein Attribut keinen zugehörigen Wert, wird das gesamte Feld ausgeblendet. Wenn beispielsweise für einen Kunden keine Mobiletelefonnummer gepflegt ist, wird das Feld Mobile nicht angezeigt. Abbildung 22: Kunde mit (links) und ohne (rechts) Mobiletelefonnummer Mehrsprachigkeit Die VMA Applikation wird in jener Sprache gestartet, in welcher das jeweilige Endgerät konfiguriert ist. Die Voraussetzung ist, dass die konfigurierte Sprachversion von der VMA unterstützt wird. Die Applikation wird in Englisch gestartet, wenn keine Sprachversion für die auf dem Endgerät konfigurierte Sprache existiert. Alle im UI angezeigten Texte sind in XML-Files abgelegt. Um eine neue Sprachversion anzubieten müssen lediglich die XML-Files übersetzt werden. Verfügbare Sprachen In Version x der VMA werden nur die Sprachen Deutsch und Englisch vollständig unterstützt! 28 Client/Server Applikation mit Android

163 Systemspezifikation UI-Konzept Hochschule Luzern Änderungsstatus visualisieren Der Änderungsstatus soll es dem Benutzer ermöglichen, neue und veränderte Aufträge zuerkennen. Die Zahl innerhalb der Icons zeigt die Anzahl der veränderten Objekte auf dem ERP-System. Diese Zahl umfasst die neuen und die modifizierten Objekte. Wenn der VMA Benutzer ein Auftrag oder eine Leistung öffnet, wird dieses Objekt nicht mehr als neues oder modifiziertes Objekt aufgeführt. Abbildung 23: Das Dashboard zeigt die Statusübersicht der Änderungen vom Vertec ERP-System In den Listen, in welchen die Aufträge und Leistungen aufgeführt werden, wird für jedes Objekt der jeweilige Änderungsstatus im Icon (siehe Tabelle 12) anhand eines Buchstabens dargestellt. Auftrag Leistung Beschreibung Diese Icons werden verwendet, wenn ein neues Objekt vom VIS empfangen wird. (Das Zeichen N steht für New). Erhält die VMA eine Änderung für ein Objekt, welches bereits lokal gespeichert ist, wird das U-Icon angezeigt. (Das Zeichen U steht für Update). Objekte mit dem Status N werden beim erneuten Eintreffen einer Änderung nicht auf U gesetzt. Diese Icons werden verwendet, wenn der VMA Benutzer ein Objekt bereits angesehen hat und keine Änderung seitens ERP-System vorliegt. Tabelle 12: Auftrag und Leistungs-Icons zum visualisieren des Änderungsstatus Client/Server Applikation mit Android 29

164 Hochschule Luzern Systemspezifikation Design-Entscheide 4 Design-Entscheide Dieses Kapitel enthält Hinweise über Design-Entscheidungen, welche während des Projekts getroffen wurden. Es ist essentiell wichtig, in bestimmten Bereichen die Warum Fragen zu beantworten obwohl im Manifesto for Agile Software Development [10] unmissverständlich statuiert wird, dass lauffähiger Code wichtiger ist, als eine verständliche Dokumentation. (Zitat: Working software over comprehensive documentation ). 4.1 Integration Service Prinzip Integration impliziert Begriffe wie Abstraktion, Transformation, Schnittstellen und Konvergenz. Integration Services erlauben das Orchestrieren von heterogenen Systemumgebungen. Sie sorgen dafür, dass die Schnittstellen von Legacy Systemen zu einem einheitlichen Service zusammengeführt werden. Die gewonnene Abstraktion von Legacy Systemen kann als Investitionsschutz für Service Konsumenten betrachtet werden. Der in diesem Projekt konzipierte Vertec Integration Service (VIS) soll massgeblich dazu beitragen, externen 3 Systeme einen einfachen Zugang zum Vertec ERP-System zu verschaffen. Mitunter wird mit dem VIS folgender Mehrwert generiert: Die ERP Abfragelogik wird abstrahiert und entkoppelt. VIS transformiert Schnittstellenaufrufe in ERP Abfragen und konvertiert ERP Abfrageresultate zurück in ein standardisiertes Austauschformat. Effizientere Nutzung der Netzwerkkapazität, da nur jene Daten übertragen werden, welche vom Endsystem effektiv benötigt werden. Zudem kommt mit JSON ein Austauschformat zum Einsatz, welches wesentlich effizienter arbeitet als XML. Unterstützung für Offline Synchronisation. Erweiterung für Push Notification möglich. Weil VIS auf verbreitete Standards setzt, können auch andere Nutzersysteme daran angebunden werden (z.b. in Form einer Web Schnittstelle oder Anwendungen für andere mobile Plattformen). 3 gemeint ist extern, aus Sicht des Vertec ERP-Systems 30 Client/Server Applikation mit Android

165 Systemspezifikation Design-Entscheide Hochschule Luzern 4.2 Multithreading Nebenläufigkeit ist seit der Einführung von Mehrprozessorsystemen zu einem Dauerbrenner geworden. Die nachfolgenden Kapitel beschreiben, wie Multithreading in diesem Projekt eingesetzt wird. Beim Einsatz von nebenläufigen Prozessen geht es nicht nur um die Steigerung der Leistungsfähigkeit einer Applikation. Das nachfolgende Kapitel zeigt, wie Multithreading die Usability verbessern kann Android Responsiveness Applikationen auf Android laufen standardmässig in einem einzigen Thread. Das kann bei zeitintensiven Operationen schnell zu Problemen führen, weshalb Multithreading ein wichtiges Thema ist. So wichtig, dass sich die Macher von Android dazu gezwungen sahen, eine Richtlinie zu Designing for Responsiveness [11] aufzustellen. Nach dieser Richtlinie sollen Operationen, welche potentiell mehr als 200ms Zeit in Anspruch nehmen, in einen neuen Thread ausgelagert werden. Android liefert bereits seit API Level 3 umfangreiche Bordmittel für Multithreading. So zum Beispiel die Klasse android.os.asynctask [12], welche selbst ohne Vorwissen über Thread Synchronisation einsetzbar ist. Im vorliegenden Projekt wird AsyncTask innerhalb des HttpClients verwendet, um Http Requests abzusetzen. Defizite von AsyncTask Die Implementation von AsyncTask weist leider einige Unschönheiten auf. Beispielsweise können AsyncTasks nicht verschachtelt werden. (Der Nutzen von verschachtelten AsyncTasks mag umstritten sein. Dass verschachtelte Aufrufe in einer Exception enden, ist diskussionslos unschön). Punkt zwei: AsyncTask hat nachweislich Probleme im Zusammenhang mit Robotium Instrumentation Tests verursacht. Robotium wird in diesem Projekt für Multi-Activity Systemtests eingesetzt. AsyncTasks haben regelmässig zu Unterbrüchen in automatisierten Tests geführt. Als Konsequenz wurde der Source Code von AsyncTask studiert und basierend auf den Ideen von AsyncTask eine neue Klasse, AsyncTask2, konstruiert. Diese nutzt einfachere Thread Synchronisationsmethoden und ist daher minim leistungsfähiger. Für asynchrone Rückmeldungen wird ein Interface, ICallbackHandler, bereitgestellt, welches jeweils anonym implementiert werden kann. Als Datenobjekt für Rückmeldungen wurde eine generische Klasse AsyncTaskResult entwickelt. Diese liefert nicht nur Resultatwerte an den Aufrufer zurück, sondern kann im Fehlerfall auch Exceptions zurückgeben. Das ist insbesondere darum sehr komfortabel, weil die Fehlerbehandlung oft nicht innerhalb des AsyncTasks gemacht werden kann. Das Ausgeben von Fehlermeldungen (sog. Alert Dialogs) muss zwingend über den UI Thread vollzogen werden. Deshalb ist es wichtig, dass Exceptions, welche in AsyncTasks entstanden sind, an den Aufrufer zurückgemeldet werden WCF ConcurrencyMode Auf dem Vertec Integration Service gibt es ebenfalls Gründe, über Nebenläufigkeit nachzudenken. Obwohl es für den VIS keine Voraussagen für eine maximale Nutzerzahl gibt, sollte das System die Aspekte der Skalierbarkeit berücksichtigen. Microsoft ermöglicht in Windows Communication Foundation (WCF) eine intuitive Konfiguration des InstanceContextMode sowie des ConcurrencyMode. Diese beiden Attribute werden im ServiceBehavior der Implementation des Web Services (IntegrationService.svc) definiert und betreffen alle Schnittstellenmethoden. Nachfolgend werden diese beiden Modi kurz beschrieben und begründet, warum die beschriebene Konfiguration gewählt wurde: Client/Server Applikation mit Android 31

166 Hochschule Luzern Systemspezifikation Design-Entscheide InstanceContextMode = InstanceContextMode.Single: Der InstanceContextMode definiert, welchen Kontextstatus ein bestimmter WCF Service unterhalten soll. Es stehen drei mögliche Kontextmodi zur Auswahl: PerCall, Single und PerSession. In VIS wurde die Option Single ausgewählt, weil dieses den WCF Service als Singleton Instanz startet. Der Entscheid war beeinflusst durch die eingesetzte Pass-Through Authentifizierungsmethode (Kapitel 4.5, Seite 35), welche nur dann korrekt funktioniert, wenn alle Clients für alle Aufrufe denselben Session Manager verwenden. (Die Option PerCall würde beispielsweise kein Session Caching erlauben, was die ganze Authentifizierung unbrauchbar machen würde). ConcurrencyMode = ConcurrencyMode.Multiple: Wie der Name bereits verlauten lässt, bestimmt der ConcurrencyMode das Multithreading-Verhalten bei Methodenaufrufen. Die Option Multiple besagt, dass jeder Methodenaufruf in einem separaten Thread ausgeführt wird. Das Verhalten wurde so gewählt, damit sich einerseits Methodenaufrufe gegenseitig nicht blockieren und andererseits damit die Leistungsfähigkeit von Mehrprozessorsystemen effektiv beansprucht werden kann. Abbildung 24: Grafische Darstellung der Nebenläufigkeit in VIS Die gewählte Kombination von InstanceContextMode und ConcurrencyMode befreien weitgehend von der Entwicklung von eigenen Multithreading-Konstrukten. Die Kombination bedingt aber auch, dass diejenigen Komponenten, welche Kontextinformationen mehreren Threads zugänglich machen, auch die korrekte Thread Synchronisation berücksichtigen. Der MSDN Artikel in Quelle [19] bestätigt dies: When the service is configured with ConcurrencyMode.Multiple, WCF will stay out of the way and will not synchronize access to the service instance in any way. Verschiedene Kombinationsmöglichkeiten von InstanceContextMode und ConcurrencyMode sind in der Quelle [20] und [21] dokumentiert. 32 Client/Server Applikation mit Android

167 Systemspezifikation Design-Entscheide Hochschule Luzern 4.3 Kommunikation und Serialisierung zwischen den Schichten Bereits zu Beginn des Projektes war absehbar, dass ein nicht unwesentlicher Teil des Aufwands in die Entwicklung von korrekten und effizienten Serialisierungsmechanismen fliessen wird. Die vorgeschlagene Architektur beschreibt drei verschiedene Tiers, welche durch klar definierte Schnittstellen voneinander entkoppelt sind. Das Delikate an diesen Schichten ist, dass diese nicht nur physisch voneinander getrennt sind, sondern hinter den jeweiligen Implementationen auch verschiedene Technologien stecken. Die nachfolgenden Kapitel geben Einblick in die Ideen und Gedanken der eingesetzten Serialisierungsmethoden Zwischen ERP und VIS Das Vertec ERP-System stellt eine XML Webschnittstelle bereit. Anfragen werden mit HTTP POST Requests ausgelöst. Als Austauschformat wird ein SOAP-ähnliches Protokoll verwendet. Bestimmte Eigenschaften von SOAP werden nach Herstellerangaben (noch) nicht vollständig umgesetzt [1][2]. Dennoch verwenden die Request- und Response-Nachrichten das standardisierte XML Schema. Der auf dem.net Framework basierende Vertec Integration Service (VIS) implementiert HttpClient zur Initiierung von Web Requests. Diese Komponente wird vom übergeordneten VertecConnector verwendet, welcher sich um die Aufbereitung von Requests und Responses kümmert. Die Serialisierungskomponente ist generisch aufgebaut. Sie erlaubt die Registration von TypeSerializer Klassen während der Laufzeit. Dieses Designprinzip wird bereits bei Google s GSON, einer JSON-zu-Java Objekt Konvertierungskomponente, erfolgreich eingesetzt [3] Zwischen VIS und VMA Als Schnittstelle zwischen VIS und VMA wird [OperationContract] ein Windows Communication Foundation [WebInvoke(UriTemplate = "/Login", Method = "POST", (WCF) Service eingesetzt. Dieser Web Service kann mit verschiedenen Konvertie- RequestFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.WrappedRequest, ResponseFormat = WebMessageFormat.Json)] rungsoptionen konfiguriert werden. Im vorliegenden Projekt wurde entschieden, JSON als String Login(String username, String password); Austauschformat zwischen VIS und VMA Abbildung 25: Beispiel einer WCF Schnittstelle, welche JSON als Austauschformat anwendet einzusetzen. Die Konvertierung von JSON zu.net Objekten (und umgekehrt) übernimmt der Web Service ohne spezielles Dazutun des Entwicklers. Wie Abbildung 25 zeigt, muss lediglich das RequestFormat sowie das ResponseFormat auf WebMessageFormat.Json gesetzt werden. Wichtiger Hinweis zur Konvertierung von DateTime Objekten in WCF WCF verwendet einen integrierten Konverter, um.net Datentypen zu serialisieren. Unglücklicherweise wird in diesem Konverter das DateTime Attribut DateTimeKind zu wenig genau differenziert. Die DateTimeKind Enumeration kann die Werte Utc, Local und Unspecified annehmen. Im Forum der Community Stacktrace wird berichtet, dass der Json-Konverter nicht zwischen Local und Unspecified unterscheidet und diese gleich behandelt [4]. DateTime.MinValue setzt standardmässig DateTimeKind auf Unspecified. Infolgedessen wurden DateTime Attribute, welche mit MinValue initialisiert wurden, nicht in die Serialisierung eingeschlossen. Als Lösung wird vorgeschlagen, sämtliche Zeitwerte (auch MinValue) vor der Serialisierung in Universal Time (Utc) umzuwandeln. Das Framework stellt dafür die Methode ToUniversalTime() bereit. Client/Server Applikation mit Android 33

168 Hochschule Luzern Systemspezifikation Design-Entscheide Sicherung der Transportschicht Die Sicherung der Transportschicht übernimmt in diesem Projektsystem das Verschlüsselungsprotokoll Transport Layer Security (TLS), der Vorgänger von Secure Socket Layer (SSL). Dieses Protokoll gilt als Industriestandard für die Verschlüsselung von Internetverkehr. Sie vertraut der Sicherheit von asymmetrischer Kryptographie. Konkret bedeutet dies, dass für den Server, welcher den Vertec Integration Service betreibt, ein vertrauenswürdiges X.509 Zertifikat ausgestellt werden muss. Vertrauenswürdig kann folgendes heissen: Self-Signed Certificates: Das TLS Zertifikat für VIS wurde selber erstellt (sog. Self-Signed Certificate) und das dazugehörige Public Key Zertifikat wird via Truststore resp. Keystore der VMA als vertrauenswürdig eingestuft. (Abbildung 26 zeigt den Inhalt eines Self-Signed Certificates, welches für den Entwicklungsserver von VIS eingesetzt wurde). CA-Signed Certificates: VIS nutzt ein TLS Zertifikat, welches von einer öffentlichen Certification Authority (CA) als vertrauenswürdig eingestuft wurde und welches im Truststore des jeweiligen Android Endgeräts enthalten ist. Ein hilfreicher Artikel über das Erstellen von Keystores und das Einpflegen von Zertifikaten auf Android kann in [27] gefunden werden. Dieser Artikel war auch die Basis für die Integration von TLS in der VMA. Abbildung 26: Ansicht des X.509 Zertifikats, welches für vis.enterpriselab.ch verwendet wurde Hinweis zur Weiterentwicklung Der Aufwand für das Einpflegen von Public Key Zertifikaten auf der VMA könnte bei einer grossen Zahl Benutzer zum Problem werden. Der Vorgang ist zwar technisch einwandfrei, könnte aber für den Praxiseinsatz zu umständlich sein. Im Projektbericht [BER] wird im Diskussionsteil eine Empfehlung abgegeben, wie die Integration von TLS reibungsfreier gestaltet werden könnte. 34 Client/Server Applikation mit Android

169 Systemspezifikation Design-Entscheide Hochschule Luzern 4.4 Persistenz In der Softwarearchitektur (Kapitel 2.5, Seite 14) wird eine Ansicht des Datenmodells der VMA Datenbank eingeführt. Die Umsetzung dieses Datenmodells geschieht mit einem Object Relational Mapper (ORM). Das Open Source Projekt ORMLite wurde in einem Prototypen verifiziert und für geeignet befunden [18]. ORM- Lite basiert auf einer SQLite Datenbank und stellt Methoden zum vereinfachten Datenzugriff bereit. Die Datenbank besteht aus einer Datei 4, und wird im internen Speicherbereich der Android Applikation abgelegt. Andere Applikationen 5 haben darauf keinen Zugriff. Sämtliche Vertec Datentypen werden in ORMLite als Data Access Objects implementiert. Eine Klasse DatabaseHelper wurde entwickelt, um den Zugriff auf die DAOs zu vereinfachen. Die Implementierung der eigentlichen Datenlogik geschieht in der Klasse DataAccess, welche über das Interface IVertecBase abstrahiert wird (siehe 2.4.1, Seite 7). Hinweis zum Datentyp TEXT auf SQLite Die Grössenlimitierungen von Columns des Typ TEXT liegt bei SQLite bei 1GB. Zeichenreservationen in runden Klammern werden ignoriert. Zitat aus Artikel [23]: Note that numeric arguments in parentheses that following the type name (ex: "VARCHAR(255)") are ignored by SQLite - SQLite does not impose any length restrictions (other than the large global SQLITE_MAX_LENGTH limit) on the length of strings, BLOBs or numeric values. 4.5 Login und Session Handling In verteilten Multiuser-Systemen spielen Authentifizierung und Autorisierung eine wichtige Rolle. Im vorliegenden Projekt wird die Benutzer- und Rechteverwaltung bereits vom ERP-System bereitgestellt. Trotzdem ist es immens wichtig, den Sicherheitsgedanken auch für die mobile Plattform zu berücksichtigen. Die Sicherheit des Gesamtsystems ist schliesslich nur so gut, wie das schwächste Glied im Gesamtsystem. Für die Integration der mobilen Plattform wird eine auf Session Identifikationsnummern basierende Authentifizierung vorgeschlagen. Erfolgreiche Authentifizierungen erhalten jeweils eine sog. SessionId, welche für alle darauffolgenden Aufrufe verwendet wird. Beim eingesetzten Verfahren handelt es sich um eine Pass- Through Authentifizierung. Dies bedeutet, dass der Vertec Integration Service zwar Authentifizierungsmethoden bereitstellt, jedoch nicht selber authentifiziert. Die Anfrage wird an das Vertec ERP-System weitergeleitet und ausgewertet. VIS implementiert jedoch ein Session Manager, welcher die Funktion des Session Caching übernimmt. Die Anmeldeinformationen (Benutzername, Passwort) von erfolgreichen Logins werden im Arbeitsspeicher des Session Managers abgelegt und bei nachfolgenden Methodenaufrufen wiederverwendet. Abbildung 27 sowie die Tabelle 13 versuchen, den Ablauf einer Benutzeranmeldung detailliert zu beschreiben. 4 Die SQLite Datenbankdatei der VMA ist auf dem Gerät unter /data/data/ch.hslu.bda.vma/databases/vertec.db zu finden. 5 Ausgenommen sind Apps mit Root-Rechten. Diese haben Lese- und Schreibzugriff auf alle Dateien des lokalen Dateisystems. Client/Server Applikation mit Android 35

170 Hochschule Luzern Systemspezifikation Design-Entscheide VertecMobileApp VertecIntegrationService Vertec ERP-System Login(user, pwd) :string Login(user, pwd) :bool alt [authentication successful] CreateSession(user, pwd) :string :string :HttpException [authentication failed] Abbildung 27: Ablauf des Login Vorgangs 1 VMA fordert Benutzer auf, Login-Informationen (Benutzername und Passwort) in entsprechendes GUI einzutragen. Die Login Methode übermittelt diese Informationen verschlüsselt an den Integration Service. 2 Der Vertec Integration Service leitet Benutzername und Passwort umgehend an das Vertec ERP- System weiter. 3 Das Vertec ERP-System entscheidet, ob die Login-Informationen gültig sind und für den Benutzer eine Session angelegt werden darf. 4 Ist der Login-Versuch vom ERP-System gutgeheissen worden, wird innerhalb WCF Services eine neue Login-Session angelegt. 5 Die zurückgegebene SessionId kann vom Client während der konfigurierten Gültigkeitszeitdauer für alle folgenden Anfragen verwendet werden, um sich gegenüber dem Vertec ERP-System zu authentifizieren. 6 Werden die Login-Informationenen vom ERP-System abgelehnt, so wird dies mit einer Http Statusmeldung (401, Unauthorized) an den Client zurückgemeldet. Tabelle 13: Schrittweise Erklärung zum Ablauf des Login Vorgangs Umgang mit aktiven Sessions Praktischerweise wird die SessionId nicht bis zur API zurückgegeben, da diese dort von geringem Interesse ist. Es wäre für den Anwender der API sehr umständlich, wenn er diese SessionId bei jedem Methodenaufruf als Parameter mitgeben müsste. Deshalb sorgt in der VMA die Komponente IntegrationServiceConnector dafür, dass die SessionId automatisch bei jedem Http Request im Http Header mitgesendet wird. Der Ablauf eines einzelnen Methodenaufrufs unter Beizug einer gültigen SessionId wird in Abbildung 28 sowie in der Tabelle 14 vereinfacht dargestellt. 36 Client/Server Applikation mit Android

171 Systemspezifikation Design-Entscheide Hochschule Luzern VertecMobileApp VertecIntegrationService Vertec ERP-System UpdateTasks(params) :JsonEl ement FindSession(sessionId) :ISession alt :HttpException [Session not found or expired] [Session found and valid] ExtendSessi onval i di ty(sessi on) UpdateT asks(user, pwd, params) :stri ng :JsonElement Abbildung 28: Ablauf eines authentifizierten Methodenaufrufs 1 API Methoden, welche eine Webzugriff fordern, werden an die Komponente IntegrationServiceConnector weitergeleitet. Diese Komponente fügt jedem Aufruf die zwischengespeicherte SessionId hinzu. Die SessionId wird im Http Header X VertecSessionId platziert. 2 Der Integration Service liest die SessionId aus dem Http Header und sucht im Session Manager nach einer gültigen Session. 3 Kann keine Session gefunden werden oder wurde das Gültigkeitsdatum einer gefundenen Session überschritten, so wird dies mit einer Http Statusmeldung (401, Unauthorized) an den Client zurückgemeldet. 4 Die gefundene, gültige Session wird um die konfigurierte Zeitdauer verlängert. Dieses Extend-On- Usage Prinzip funktioniert ohne ressourcenintensive Managementprozesse, welche periodisch ungültige Sessions entfernen. Der Benutzername und das Passwort wird aus der Session ausgelesen und in den eingehenden Http Header des WebOperationContexts geschrieben. Dieser Kontext ist nur innerhalb des aufrufenden Threads lesbar. 5 Schliesslich wird die effektive Anfrage an das Vertec ERP-System gesendet. Dafür wird vorgängig der Benutzername und das Passwort aus dem Http Header gelesen und zusammen mit den anderen Parametern an das Vertec System gesendet. 6 Die Antwort des ERP-Systems wird auf dem VIS aufbereitet und an die anfragende VMA weitergeleitet. Tabelle 14: Schrittweise Erklärung zum Ablauf eines authentifizierten Methodenaufrufs Client/Server Applikation mit Android 37

172 Hochschule Luzern Systemspezifikation Design-Entscheide Authentifizierungsprüfung VMA Clients haben die Möglichkeit ihre SessionId auf Gültigkeit zu prüfen. Dafür nutzten Sie die CheckLogin Methode auf VIS. Eine CheckLogin Anfrage wird mit True oder False beantwortet. Genauere Informationen gibt VIS aus sicherheitstechnischen Gründen nicht zurück. CheckLogin wird auf der VMA genutzt, um Authentifizierungsproblemen vorzubeugen. Im Falle einer negativen Rückmeldung wird der VMA Benutzer an das Login Fenster weitergeleitet Call Interception In VIS gibt es authentifizierte und nicht-authentifizierte Methoden. Beispielsweise gehört die Methode Login und GetVersion zu den nicht-authentifizierten Methoden, da diese von Clients ohne gültige Session aufgeruft werden können müssen. Wer bestimmt nun aber, welche Methoden authentifiziert werden sollen und welche auch ohne gültige Anmeldung aufgerufen werden können? Die Antwort auf die Frage ist in der Klasse SecurityAspect zu finden. Diese Klasse wird auf dem Integration Service als Call Interceptor für Authentifizierungsanfragen gebraucht. Sämtliche eingehende Http Requests werden zuerst an die SecurityAspect Klasse weitergeleitet. Dort wird geprüft, ob die Methode authentifiziert werden muss oder nicht. War die Authentifizierung erfolgreich, so wird der eingehende Http Header mit den Anmeldeinformationen (Benutzername, Passwort) ergänzt. Der Aufruf wird in jedem Fall an die ursprüngliche Methode weitergegeben also auch bei fehlgeschlagener Authentifizierung. Die ursprünglich aufgerufene Methode muss entsprechend auf erfolgreiche resp. nicht erfolgreiche Authentifizierungen reagieren. Abbildung 29 visualisiert den Sachverhalt in groben Zügen. Abbildung 29: Call Interception anhand eines einfachen Methodenaufrufs 38 Client/Server Applikation mit Android

173 Systemspezifikation Design-Entscheide Hochschule Luzern 4.6 GPS Routenplanung Der Auftraggeber möchte in der VMA eine einfache Navigationsfunktion integrieren, welche das Planen von Routen zu gegebenen Kundenadressen ermöglicht. Aussendienstmitarbeiter sollen mit einem Klick auf die Kundenadresse eine visuelle resp. textuelle Beschreibung des Anfahrtswegs erhalten Google Maps API oder nicht? Für diese Anforderung kommt grundsätzlich Google Maps in Frage, da dies bereits alle benötigten Navigationsfunktionen implementiert. Umstritten war allerdings die Frage, ob die Google Maps App oder die Google Maps API [17] verwendet wird. Google Maps ist als Applikation bereits auf jedem Android Gerät vorinstalliert. Http-Aufrufe, welche auf maps.google.com verweisen, werden automatisch an die Google Maps App weitergeleitet. Die Google Maps API hingegen erlaubt das Anzeigen von Kartenmaterial direkt in Activities der eigenentwickelten App. Die API würde voraussetzen, dass die Google Distribution von Android verwendet würde. Folgende Gründe haben dazu geführt, dass die Lösung mit der integrierten Google Maps App anstelle der Google Maps API verwendet wurde: Der Entwicklungsaufwand für die Einbindung der Google Maps App ist wesentlich einfacher als mit der Google Maps API. Sämtliche Navigationsfunktionen sind in der App bereits implementiert und können individuell parametrisiert werden. Das Entwicklungsrisiko kann dadurch minimiert werden. Der Verzicht auf die Google Android Distribution bedeutet zugleich mehr Unabhängigkeit. Was wären beispielsweise die Auswirkungen auf das Projektsystem, wenn Google die Maps API kostenpflichtig machen würde? Die Navigationsfunktion wurde dem Auftraggeber präsentiert und für gut befunden Technische Umsetzung Die Integration der Google Maps App ist denkbar einfach. Die von Google produzierte Activity com.google.android.maps.mapsactivity wird über einen Intent mit nachfolgendem Parameter als neuer Task gestartet. Folgende URL wird der Activity als Parameter überreicht: + sourceaddress + "&daddr=" + destaddress Der Wert für die Destination Address (daddr) entspricht jeweils der Postadresse der Kontaktperson, zu welcher navigiert werden will. Beim Auslesen der Source Address war mehr Kreativität gefragt. Google Maps stellt in der App zwar die Option Current Location zur Verfügung, diese kann aber nicht programmatikalisch als Parameter mitgegeben werden. Folglich muss als Source Address die GPS Lokation ausgelesen werden um die Latitude/Longitude Werte als Parameter saddr zu übergeben. Nachfolgendes Beispiel veranschaulicht den beschriebenen Vorgang: Zugerstr%2013%2C%206030%20Ebikon Das Vorgehen hat eine kleine Limitierung. Das Erreichen eines GPS Fixes (d.h. eine Positionsbestimmung mit sinnvoller Genauigkeit) kann bei schlechtem GPS Empfang rasch mehr als 30 Sekunden in Anspruch nehmen. Aus diesem Grund versucht die VMA zuerst, die LastKnownLocation auszulesen. Falls diese kein Resultat zurückliefert, wird ein Location Listener gestartet, welcher vor Ablauf einer konfigurierten Timeout- Periode ein Resultat zurückliefern muss. Schlägt auch diese Methode fehl, so wird der saddr-parameter von Google Maps auf? gesetzt. Der Anwender kann in diesem Fall selber nochmals versuchen, die Current Location auszulesen. Client/Server Applikation mit Android 39

174 Hochschule Luzern Systemspezifikation Design-Entscheide 4.7 Caching und Synchronisation Eine wichtige Anforderung für die Umsetzung des Projektsystems ist die Implementation eines Offline- Betriebes. Damit ein Offline-Betrieb sichergestellt werden kann, müssen Daten lokal auf die VMA kopiert werden. Um einen ressourcenschonend Betrieb zu ermöglichen, muss die Kommunikation zwischen VMA und VIS möglichst effizient sein. Es sollen nur jene Informationen übermittelt werden, welche für den VMA Benutzer tatsächlich relevant sind. Gemäss Kundenanforderungen [KUNAF] werden für die Synchronisation die CRUD Operationen Create, Read und Update benötigt. Das Löschen von Objekten ist laut Kundenanforderung vorerst nicht gewünscht. Deshalb wurde die Delete Operation in der vorliegenden Synchronisation für kein Datenobjekt implementiert. Zudem ist es nicht vorgesehen, dass alle Vertec Datenobjekt in der VMA modifiziert oder erstellt werden können. In der Tabelle 15, ist ersichtlich, welche Datenbankoperation für die jeweiligen Vertec-Datenobjekte entsprechend den Anwendungsfällen implementiert wurden. Datenobjekt Create Read Update Delete Änderbare Attribute customer X task X X finisheddate, docpath project phase X X service X X X servicetype X Tabelle 15: Datenobjekte und ihre verfügbaren Datenbankoperationen Das Konzept der Synchronisation sieht vor, dass ein Synchronisationsaufruf für jedes Vertec-Datenobjekt gleich abläuft. Bei Bedarf kann die Synchronisation mit geringem Aufwand angepasst oder erweitert werden, um so in Zukunft weitere CRUD-Operationen und/oder weitere Datenobjekte zu unterstützen Synchronisationsablauf Die VMA startet eine Synchronisation entweder periodisch nach einem konfigurierten Intervall oder nach manueller Aufforderung durch den Benutzer. Beim Starten eines Synchronisationsprozesses wird für jedes Vertec-Datenobjekt nacheinander ein Update-Aufruf an den VIS abgesetzt. Die Aufrufe müssen genau in der folgenden Reihenfolge ausgeführt werden, da zwischen den Datenobjekten bestimmte Abhängigkeiten 7 bestehen: 1. Customer 2. Project 3. Phase 4. Task 5. ServiceType 6. Service 6 Bei einer Erweiterung um neue Datenobjekte und/oder CRUD-Operationen müssten auf der VMA und auf VIS neue TypeSerializer geschrieben werden. Diese Serializer Klassen sorgen dafür, dass die Objekte korrekt in JSON Elemente umgewandelt werden. Im gegenwärtigen Umfang werden nur die Serializer und die CRUD-Operationen gemäss Tabelle 15 implementiert. 7 Die Abhängigkeiten sind im ER-Diagramm in Abbildung 12 auf Seite 19 ersichtlich. 40 Client/Server Applikation mit Android

175 Systemspezifikation Design-Entscheide Hochschule Luzern Auf dem Android Smartphone wird der Zeitpunkt lastsync, zu welchem zuletzt synchronisiert wurde, als Shared Preference gespeichert. Wenn die Synchronisation für alle Vertec-Datenobjekte erfolgreich verlaufen ist, wird der Wert des Zeitstempels mit dem aktuellen Datum/Zeit überschrieben. Im vorliegen Projektsystem wurden die Datenbankoperationen Create, Read und Update in einem Methodenaufruf Update zusammengefasst. Durch das Zusammenlegen der Datenbankoperation kann der Datenaustausch zwischen VIS und der VMA gering gehalten werden. Wären die Datenbankoperationen nicht in einer einzigen Methode, dann bestünde die Gefahr, dass ein zu änderndes Objekt mehrmals zwischen VIS und VMA hin und her geschoben würde. Eine Read-Operation, welche auf eine Update-Operation folgt, würde u.u. die Objekte der vorhergehenden Update-Operation gleich wieder einlesen. SyncManager VertecIntegrationService Vertec ERP System Update(objectList, idlist, lastsync, currentdatetime) loop Create [for all createobjects] CreateVertecObjects(newObject) :objectidlist loop Update [for all updateobjects] UpdateVertecObjects(updateObject) :# of updated objects ReadVertecObjects(oclQuery) :objectlist :updatedobjectlist Abbildung 30: Sequenzdiagramm zur Synchronisation In der Abbildung 30 wird die Synchronisation anhand eines Sequenzdiagrammes erläutert. Wie bereits erwähnt, verläuft die Synchronisation für jedes Datenobjekt gleich. Die VMA besitzt einen SyncManager, welcher ein Update Befehl synchron an den VIS übermittelt. Der SyncManager überträgt bei einem Update die Parameter objectlist, idlist, lastsync und currentdatetime. Die objectlist enthält die Objekte, welche auf der VMA erstellt oder verändert wurden. Beim Übertragen von Objekten zwischen VIS und VMA wird ein Client/Server Applikation mit Android 41

176 Hochschule Luzern Systemspezifikation Design-Entscheide zusätzliches Attribut DbCommand angefügt. Dieses Attribut kennzeichnet erstellte Objekte mit dem Wert DbOperation.Create und veränderte Objekte mit DbOperation.Update. Die Liste idlist enthält all jene Objekt IDs, welche bereits in der lokalen VMA Datenbank gespeichert sind. Durch das Überliefern des Zeitstempels lastsync, kann der VIS feststellen, für welche Objekte ein Update an die VMA gesendet werden muss. Das Attribut currentdatetime enthält den aktuellen Zeitstempel der VMA. Mit diesem Attribut wird die Zeitabweichung kompensiert, welche zwischen dem Vertec ERP-System und der VMA potenziell bestehen kann. (Siehe Kapitel 4.7.2). Synchronisationsaufrufe von der VMA an VIS laufen synchron ab. Der VIS stellt indes sicher, dass alle Anfragen in neuen Threads ausgeführt werden. Somit kann VIS alle während einer Synchronisation benötigten ERP Abfragen synchron ausführen. In der Abbildung 31 ist die Synchronisation anhand eines Ablaufdiagramms etwas detaillierter dargestellt. Die jeweiligen Schritte sind in der Tabelle 16 beschrieben. 1 Die VMA ermittelt die Objekte, welche seit der letzten Synchronisation auf der VMA erstellt oder verändert wurden. Neu erstellte Objekte enthalten keine Vertec Objekt ID. Das heisst, bei diesen besitzt das Attribut id den Wert 0. Bei veränderten Objekten ist das Attribut editstatusvma auf den Wert true gesetzt. 2 Der VIS nimmt die Anfrage entgegen und prüft das Session Token. 3 Der VIS erstellt für das zu kreierende Objekt einen Create-Request (siehe Kapitel , Seite 12) und übermittelt diesen an die Vertec XML Schnittstelle. 4 Das Objekt wird im Vertec ERP-System angelegt. Als Rückmeldung wird die Objekt ID sowie der Status(1 = gültig; 0 = ungültig) eines Objektes an den VIS übermittelt. 5 Der VIS erstellt eine Resultatliste, in welcher alle für die VMA relevanten Änderungen gesammelt und am Ende des Synchronisationsprozesses an die VMA übermittelt werden. Für jede erfasste Änderung wird eine Datenbank-Operation angegeben, damit die VMA weiss, wie die Rückmeldung behandelt werden muss. Die möglichen Operation sind in der Tabelle 17 definiert. Die Objekte, welche erfolgreich angelegt werden konnten, werden in der Resultatliste mit der dazugehörigen ERP Objekt ID angefügt und mit der Operation DbOperation.Update versehen. Objekte bei denen es während dem Erstellen zu Fehlern kommt, werden ebenfalls in der Resultatliste angefügt. Allerdings werden diese Objekte mit der Operation DbOperation.Failure vermerkt. Es kann vorkommen, dass ein Objekt, welches erfolgreich angelegt werden konnte, die Selektionskriterien der darauffolgenden Read Operation nicht mehr erfüllt. Diese Objekte werden mit der Operation DbOperation.Delete versehen. 6 Für jedes einzelne Objekt, welches auf der VMA verändert wurden, wird ein Update Request (siehe Kapitel , Seite 13) erstellt und an die Vertec XML Schnittstelle gesendet. Die Änderungsanfragen werden einzeln an das ERP-System übermittelt, damit es nachvollziehbar ist, welche Änderungen erfolgreich waren. Denn das ERP-System meldet als Antwort auf einen Update Request nur wie viele Objekte erfolgreich verändert wurden. Wenn nun alle Objekte mit einem Aufruf an das ERP-System übertragen werden, dann ist nicht ersichtlich, für welche Objekte die Änderungen erfolgreich waren. 42 Client/Server Applikation mit Android

177 Systemspezifikation Design-Entscheide Hochschule Luzern 7 Das ERP-System nimmt die gemeldeten Änderungen an den Objekten vor und liefert als Antwort die Anzahl der veränderten Objekte zurück. 8 Wenn eine Änderung nicht ins ERP-System übernommen werden konnte, wird dieses der Resultatliste hinzugefügt und mit der Operation DbOperation.Failure vermerkt. Für erfolgreich angepasste Objekte wird kein Eintrag in der Resultatliste gemacht, ausser mit der Operation DbOperation.Delete, falls die Selektionskriterien nicht mehr erfüllt werden. 9 Der VIS erstellt einen Read-Request 8, mit der spezifischen OCL Abfrage für das zu synchronisierende Objekt und übermittelt diesen an die XML Schnittstelle des ERP-Systems. Der konfigurierte Read- Request fragt alle Datensätze des betroffenen Objektes ab, welche zu einem Projektauftrag der aktuellen Periode referenzieren. Bei der aktuellen Periode handelt es sich um den aktuellen Tag +/- 1 Tag, abhängig vom Parameter RangeOfTaskDatePeriod (Kapitel , Seite 22), welcher im VIS konfiguriert werden kann. 10 Das Vertec ERP-System liefert als Antwort alle Objekte des bestimmten Vertec-Datenobjektes zurück, welche die Kriterien der OCL-Abfrage erfüllen. 11 Die Objekt ID s, welche von der VMA als Parameter mitgegeben wurden, werden mit den Objekten verglichen, welche vom ERP-System empfangen wurden. Objekte, deren Objekt ID s nicht mehr vom ERP-System zurückgemeldet wurden, können in der VMA gelöscht werden. Der Resultatliste werden die Objekt ID s der zu löschenden Objekte hinzugefügt und mit der Operation DbOperation.Delete versehen. 12 In diesem Schritt wird geprüft, ob die Objekte des ERP-Systems einen aktuelleren Stand besitzen als Objekte, welche auf dem Smartphone vorhanden sind. Objekte, für welche sowohl eine ID der VMA, wie auch eine Antwort des ERP-Systems vorliegt, wird das modifieddate mit dem lastsync Zeitstempel verglichen. Wenn das modifieddate des Objekts vom ERP-System grösser ist als der lastsync Zeitstempel der VMA, wird wiederum ein Eintrag in der Resultatliste angefügt. Diese Einträge werden mit der Operation DbOperation.Update versehen. Objekte, für welche in derselben Anfrage bereits ein Update an die Vertec XML Schnittstelle gesendet wurde, werden in die Resultatliste nicht aufgenommen. 13 Zum Schluss werden noch die neuen Objekte d.h. jene Objekte, welche sich noch nicht auf dem Smartphone befinden in die Resultatliste eingefügt. Zu den neuen Objekten gehören jene, welche vom ERP-System auf Anfrage (in Schritt 9) zurückgemeldet wurden, jedoch mit keiner von der VMA bereitgestellten Objekt ID übereinstimmen. Diese Objekte werden in der Resultatlist mit der Operation DbOperation.Create versehen. 14 Die Resultatliste, welche nun alle geplanten Änderungen, für einen bestimmten Vertec Datentyp enthält, wird an die VMA gesendet. In der Resultatliste ist für jeden Datensatz vermerkt, welche Datenbankoperation die VMA dafür anwenden muss. Die möglichen Operationen sind in der Tabelle 17 beschrieben. 15 Die VMA erhält nach erfolgreicher Synchronisation die Resultatliste vom Integration Service und nimmt die gemeldeten Änderungen in der lokalen Datenbank vor. Tabelle 16: Beschreibung der einzelnen Synchronisationsschritte 8 In Kapitel , Seite 12, werden die OCL Requests erläutert. Kapitel auf Seite 25 zeigt, wie die OCL Abfragen im VIS konfiguriert werden können. Die vorkonfigurierten OCL Requests sind im Anhang [APPX] zu finden. Client/Server Applikation mit Android 43

178 Hochschule Luzern Systemspezifikation Design-Entscheide VertecMobileApp Vertec Integration Service Vertec ERP-Sytem Update<IVertecType> 1 Update( objectlist, idlist, lastsynch, currentdatetime) Receive request 2 Create «Create» request 3 4 Return object Id s of created Create() objects Verify if objects was created 5 Yes more create objects? No Create «Update» request 6 Update() Return number of updated objects 7 Verify if objects were updated 8 Yes more update objects? No 9 10 Create «Read» request Read() Return requested objects Verify if an object was deleted 11 Verify if an object was changed 12 Verify if new objects are available 13 Update Database 15 Return all changes 14 Abbildung 31: Flussdiagramm zur Synchronisation 44 Client/Server Applikation mit Android

179 Systemspezifikation Design-Entscheide Hochschule Luzern Wie im Flussdiagramm in Abbildung 31 bei Schritt 6 ersichtlich ist, wird vor dem Schreiben von Updates nicht geprüft, ob die betroffenen Objekte nicht bereits auf dem ERP-System geändert wurden. Das heisst, Änderungen der VMA sind immer autoritativ und dürfen somit auch Objekte überschreiben, für welche im ERP-System eine aktuellere Version vorliegt. Operation Create Update Delete Failure Beschreibung Es handelt sich um ein neues Objekt, welches in der lokalen VMA Datenbank eingefügt werden muss. Das Objekt befindet sich bereits in der lokalen VMA Datenbank. Im Vertec ERP-System ist eine aktuellere Version dieses Objektes vorhanden, darum muss dieses in der lokalen VMA Datenbank aktualisiert werden. Ein Objekt, welches die Selektionskriterien nicht mehr erfüllt, muss in der lokalen VMA Datenbank gelöscht werden. Objekte, welche gelöscht werden müssen, sind beispielsweise abgeschlossene Aufträge oder Aufträge, die einem anderen Aussendienstmitarbeiter zugewiesen wurden. Dieser Resultattyp wird zurückgemeldet, wenn die gewünschte Aktion für das betroffene Objekt nicht ausgeführt werden konnte. Tabelle 17 Operationen, welche an die VMA kommuniziert werden Zeitabweichungen zwischen VMA und VIS kompensieren Ein häufiges Problem bei verteilten Systemen ist die zeitliche Koordination. Jedes System hat eine eigene physikalische Uhr. Die Uhrzeiten der Systeme stimmen typischerweise nicht exakt miteinander überein. Es ist zwar möglich die Uhrzeiten in zeitlichen Abständen neu zu synchronisieren, trotzdem kann eine synchrone Zeit über mehrere System nicht garantiert werden. Es ist deshalb schwierig, Ereignisse von verteilten Systemen in zeitlich korrekter Reihenfolge einzuordnen, wenn keine exakte, globale Zeit garantiert werden kann. [14] Im vorliegenden Projektsystem muss genau dieses Problem beim Abgleichen von Änderungen zwischen der VMA und dem ERP-System berücksichtigt werden. In Abbildung 32 wird aufgezeigt, wie Änderungen im ERP-System nie an die VMA kommuniziert würden, falls die Zeit der VMA gegenüber jener des Vertec ERP- Systems voraus laufen würde. Client/Server Applikation mit Android 45

180 Hochschule Luzern Systemspezifikation Design-Entscheide Initial time: 14:01 Vertec Mobile App Vertec Integration Service Initial time: 14:00 Vertec ERP-Sytem 14:01 Start synchronisation Update( lastsync=null) Create «Read» request Read() 14:00 Return requested objects Update local database Verify if an object was changed 14:02 Set timestamp lastsync = 14:02 14:01 Project leader changed task Id=1 14:03 Start synchronisation Update( lastsync=14:02) Create «Read» request Read() 14:02 Return requested objects Update local database Verify if an object was changed Verify if modifieddate > lastsync Task1 : Task Id = 1.. modifieddate = 14:01 > 14:02 Change on Task1 is not passed to VMA Abbildung 32: Änderungen könnten verloren gehen, wenn die Zeitabweichung nicht beachtet wird In Abbildung 32 sind nur die Schritte des Synchronisationsprozesses enthalten, welche für die Erklärung des Problems nötig sind. Es ist ersichtlich, dass die VMA und das ERP-System immer eine Zeitdifferenz von einer Minute aufweisen. Bei der initialen Synchronisation kommt es noch zu keinem Problem, da der lastsync Zeitstempel der VMA einen sehr tiefen Zeitstempel (lastsync=new Date(0)) enthält. Alle Objekte, welche die Selektionskriterien erfüllen, werden in diesem Fall an die VMA zurückgesendet. Im obigen Beispiel wird angenommen, dass ein Projektleiter um 14:01 (Zeit auf Vertec ERP) einen Auftrag direkt im ERP-System verändert. Um 14:03 (VMA-Zeit) wird auf der VMA der zweite Synchronisationsdurchlauf gestartet. Als Parameter wird der Zeitstempel der letzten erfolgreichen Synchronisation (lastsync=14:02) übergeben. Der VIS sendet den Read Request an das ERP-System und erhält dadurch als Resultat alle Objekte, welche die Selektionskriterien erfüllen. Somit also auch den veränderten Auftrag Task1. Beim Vergleich allerdings, ist der beim Update Aufruft übertragene lastsync-wert (14:02) grösser als der Änderungszeitstempel (14:01) des Objektes. Der VIS muss davon ausgehen, dass die VMA die erwähnte Änderung bereits erhalten hat und gibt das Objekt fälschlicherweise nicht an die VMA zurück. 46 Client/Server Applikation mit Android

181 Systemspezifikation Design-Entscheide Hochschule Luzern Um diesem Problem entgegen zu wirken, übergibt die VMA bei der Synchronisation ein zusätzliches Attribut currentdatetime, welches die aktuelle Systemzeit der VMA enthält. Bei einem Synchronisationsaufruf berechnet der VIS abhängig von der mitgelieferten VMA-Systemzeit einen neuen Zeitstempel lastsync, welcher die Zeitdifferenz zwischen VIS und VMA berücksichtigt. DateTime currentservicetime = DateTime.UtcNow; currentdatetime = currentdate.addseconds(appsettings.default.avgroundtriptime); TimeSpan difftime = currentservicetime currentdatetime; lastsync = lastsync.add(difftime); lastsync = lastsync.addseconds( 1 * AppSetings.Default.SyncTolerance); return lastsync; Abbildung 33: Neuberechnung des Zeitstempels lastsync durch VIS Zuerst wird zur mitgelieferten VMA-Systemzeit eine durchschnittliche Roundtrip-Zeit 9 AvgRoundTripTime addiert. Danach wird die Differenz zwischen der VMA-Systemzeit und der VIS-Systemzeit ermittelt. Die Differenz wird je nach Resultat dieser Operation (positiv/negativ) vom lastsync Zeitstempel addiert oder subtrahiert. Zusätzlich wird eine Toleranz SyncTolerance vom lastsync Zeitstempel abgezogen, damit sichergestellt werden kann, dass auch dann keine Änderungen verloren gehen, wenn der Synchronisationsprozess lange dauert. Beide Parameter, AvgRoundTripTime und SyncTolerance, können in der Konfiguration von VIS festgelegt werden. 9 Das Attribut AvgRoundTripTime bestimmt die durchschnittliche Übertragungszeit zwischen VMA und VIS. Client/Server Applikation mit Android 47

182 Hochschule Luzern Systemspezifikation Design-Entscheide 4.8 Push Notification Das Vertec ERP-System implementiert in der vorliegenden Version keinen Push Notification Service, welcher über die bereitgestellten Schnittstellen genutzt werden kann. Abfragen zwischen dem Vertec Integration Service und dem Vertec ERP-System können also nur auf periodischem Polling basieren. Zwischen der VMA und VIS hingegen ist ein Push Notification Service sinnvoll. Obwohl die Kundenanforderung ausdrücklich besagt, dass ein konfigurierbarer Polling-Ansatz durchaus genügend ist, wurden Recherchen über eine Push Integration durchgeführt. Im gegenwärtigen VIS Release wird Push Notification als experimentelles Feature ausgerollt. Die nachfolgenden Unterkapitel zeigen, welche Möglichkeiten bestehen, Push Notification in WCF einzubauen WCF CallbackContracts Microsoft stellt in WCF sogenannte CallbackContracts bereit. Diese können in ServiceContracts genutzt werden, um Client-Anfragen asynchron zu beantworten. In einem Artikel auf MSDN [5] kann jedoch nachgelesen werden, dass diese Methode nur dann anwendbar ist, wenn auch die Client-Software auf.net basiert. Nur in diesem Fall kann die Binding-Variante WSDualHttpBinding genutzt werden. WSDualHttpBinding ist eine Binding-Variante, welche für Duplex Service entworfen wurde. Clients und Services können in diesem Binding senden und empfangen [6]. Diskussionen in Fachforen, wie z.b. jene auf Stackoverflow.com [7], führen immer wieder zum Schluss: Push Notification mit einem RESTful WCF Service funktioniert nicht, wegen fehlender Bidirektionalität Android Cloud to Device Messaging (C2DM) Google stellt für Android einen Kommunikationsdienst bereit, der bereits viele Aspekte von Push Notification decken würde. Dieses sog. Cloud to Device Messaging Framework erlaubt das Kontaktieren von Android Apps über einen Cloud-basierten Dienst, welcher von Google betrieben wird [22]. Unumgänglich ist dabei, dass der Benutzer mit einem Google Account auf dem Gerät eingeloggt ist. Diese Einschränkung macht C2DM für interne Firmenanwendungen und somit für die VMA unbrauchbar. Hinzu kommt die grosse Abhängigkeit von einem externen Dienstleister (Google), welche es in jedem Fall zu vermeiden gilt. C2DM birgt auch Sicherheitsrisiken: Die vorgesehene Sicherung der Transportschicht 10 wäre nutzlos, wenn Push-Informationen über eine externen Dienstleister versendet würden. Niemand weiss mit bestimmter Sicherheit, dass die Push-Nachrichten nicht von Google analysiert und für Werbezwecke missbraucht werden. 10 Kapitel 4.3.3, Seite Client/Server Applikation mit Android

183 Systemspezifikation Design-Entscheide Hochschule Luzern Unidirekte Callbacks Die realisierte Push Notification Lösung basiert auf asynchronen Http Requests, welche sich bei VIS Updates für einen bestimmten Vertec Datentyp abonnieren können. Subscription-Anfragen werden auf dem VIS solange blockiert, bis ein Update vorliegt (oder eine StarvationException 11 auftritt oder die Push Notification manuell gestoppt wurde). Der Vertec Integration Service übernimmt also die Aufgabe des Pollers und führt in regelmässigen Zeitabständen die Update-Anfrage aus. Sobald die Anfrage ein Resultat liefert, wird die Blockierung des Http Requests aufgehoben und ein Resultat zurückgegeben. Auf der VMA wurde beim asynchronen Http Request ein Callback Handler hinterlegt, welcher beim Eintreffen der Http Response aufgerufen wird. Callback Handler werden in Java oft gebraucht, um Resultate asynchron zurückzugeben. An dieser Stelle sei auch die AsyncTaskResult Klasse erwähnt, welche generische Rückgabewerte und/oder Exceptions über Callback Handler zurückgeben kann. VMA.SyncManager VMA.HttpClient VertecIntegrationService Vertec ERP-System Subscribe(objectList, idlist, lastsync, currentdatetime, callbackhandler) Subscribe(objectList, idlist, lastsync, currentdatetime) :Integer loop check for updated objects [objectlist.count == 0] ReadVertecObjects(oclQuery) :objectlist :objectlist.count as Integer HandlePushCallback() :Integer Abbildung 34: Sequentieller Ablauf von Push Notification Tatsächlich ist Push Notification komplexer, als in Abbildung 34 gezeigt wird. Dennoch gibt Abbildung 34 einen guten Überblick über die prinzipielle Umsetzung von Push Notification in VMA und VIS. Nicht erwähnt wird z.b. die abstrakte CallbackRelay Klasse, welche entwickelt wurde, um asynchrone Rückgabewerte zu konvertieren und an einen weiteren Callback Handler weiterzuleiten. Der Http Client der VMA empfängt beispielsweise asynchrone Rückmeldungen vom Typ JsonElement und gibt diese wiederum asynchron, aber als Rückgabewert vom Typ Integer an den SyncManager zurück. Hinweise für die Weiterentwicklung von Push Notification Eine Weiterentwicklung von Push Notification muss gezwungenermassen im Zusammenspiel mit dem Synchronisationskonzept geschehen. Die derzeitige Implementation ist lediglich ein funktionaler Prototyp, welcher weiter getestet und verfeinert werden muss. Die Push Notification Komponente in VIS ist soweit vorbereitet, dass sie Push Informationen direkt an die VMA zurückgeben kann. Die VMA muss nun erweitert werden, damit diese Informationen direkt in die lokale Datenbasis eingespeist werden können. 11 Die Starvation Checks wurden eingebaut, um unendlich dauernde Update-Versuche vorzeitig zu stoppen. Client/Server Applikation mit Android 49

184 Hochschule Luzern Systemspezifikation Design-Entscheide 4.9 Logging Erfahrungsgemäss können nur jene Fehlerzustände abgefangen werden, welche im Laufe der Entwicklungsund Testphase eruiert werden. Das korrekte Behandeln von Fehlerzuständen erfordert viel Erfahrung im Umgang mit der neu entwickelten Anwendung. Um auch neue, noch unbekannte Fehlerzustände nachvollziehen zu können, ist es unerlässlich, konsistente Logs zu führen sowohl auf dem WCF Service wie auch auf den Android Endgeräten Android Log Handling Ein Logging Paket gehört bei Android bereits zum Standardequipment des API Frameworks. Auf der VMA wurde eine Singleton-Klasse Log erstellt, welche unter Beizug des Standard-Loggers (java.util.logging.logger) einfache Log-methoden implementiert. Der Grund für diese Enkapsulierung liegt darin, dass diese Log Klasse einen FileHandler initialisiert, welcher Log-Nachrichten direkt in eine JSONserialisierte Log-Datei schreibt. Android Log auslesen Mit dem Befehl adb shell logcat ch.hslu.bda.vma können die letzten Log-Einträge eines Android Geräts ausgelesen werden WCF Event Logging Standardmässig loggt WCF keine Meldungen in den Event Log des Betriebssystems. Ob der Windows Event Log ein idealer Ort ist, um Log Nachrichten abzulegen, ist umstritten. Die Kopplung von Applikation und Betriebssystem wird zweifelsohne grösser. Der Event Log ist jedoch unbestreitbar jener Ort, welcher vom Systembetreiber in Fehlerfällen am ehesten konsultiert wird. Deshalb wurde der Vertec Integration Service in den Application Log des Betriebssystems eingebunden. Microsoft bietet mit System.Diagnostics die Möglichkeit, WCF Services zu loggen. Analog zur VMA wird auch in VIS eine Singleton Klasse Log verwendet, um Log-Nachrichten zu schreiben. Das Log Level reicht von Off bis All und ist über Web.config konfigurierbar. (Siehe Tabelle 9, Seite 23). In der Web Konfiguration können bei Bedarf weitere Log Handler konfiguriert werden. Abbildung 35 zeigt beispielhaft eine Konfiguration, um Meldungen vom Log Level Information und ActivityTracing in die festgelegte Logdatei zu schreiben. <configuration> <system.diagnostics> <sources> <source name="system.servicemodel" switchvalue="information, ActivityTracing" propagateactivity="true"> <listeners> <add name="tracelistener" type="system.diagnostics.xmlwritertracelistener" initializedata= "c:\log\traces.svclog" /> </listeners> </source> </sources> </system.diagnostics> </configuration> Abbildung 35: Web.config Log Tracing Konfiguration eines WCF Services 50 Client/Server Applikation mit Android

185 Systemspezifikation Environment-Anforderungen Hochschule Luzern 5 Environment-Anforderungen Nachfolgende Tabelle zeigt die Systemempfehlungen, welche für die VMA resp. VIS zu beachten sind. Die meisten Werte sind von der Nutzung des Systems abhängig und müssen von Fall zu Fall neu beurteilt werden. Die Resultate der Android Plattform Evaluation sind in die Mindestanforderung eingeflossen. Mindestanforderung Empfehlung Vertec Mobile App Prozessorleistung 1GHz 1GHz Arbeitsspeicher 512MB RAM 1GB RAM Freier Speicherplatz 12 8MB 20MB Betriebssystem Android OS Android OS 4.0 Bildschirmauflösung 480x x720 Hardware - GPS Empfänger Internetverbindung EDGE 3G, WLAN Vertec Integration Service Prozessorleistung 2x 2.6 GHz 2x 2.6 GHz Arbeitsspeicher 4GB 8GB Freier Speicherplatz 13 10MB 20MB Betriebssystem Windows Server 2008 R2 Windows Server 2008 R2 Bildschirmauflösung 1024x x768 Software IIS7.5 Microsoft.Net 4 IIS7.5 Microsoft.Net 4 Internetverbindung 14 Breitbandanschluss Breitbandanschluss Tabelle 18: Systemanforderungen 12 Das Installationspaket benötigt ca. 6MB Speicher. Dazu kommen die Dateien des Ereignisprotokolls (je nach konfigurierter Dateigrösse) sowie die Datenbank. Bei je 5 Aufträgen, Projekten, Kundenkontakten und Leisten wird ca. 30KB Speicher benötigt. 13 Das Softwarepaket benötigt ca. 2MB Festplattenspeicher. Der restliche Speicher wird für das Ereignisprotokoll benötigt. 14 Die Bandbreite muss individuell dimensioniert werden. Für VMA Clients mit durchschnittlichem Synchronisationsverhalten sollte ein symmetrischer 2Mbps Anschluss ausreichen. Client/Server Applikation mit Android 51

186 Hochschule Luzern Systemspezifikation Quellen 6 Quellen Ref Quellenangabe / URL [1] W3C Simple Object Access Protocol (SOAP) Specification, [2] rvice/xml/xmlschnittstelle Letzter Zugriff [3] [4] [5] MSDN, Juval Lowy, What You Need To Know About One-Way Calls, Callbacks, And Events [6] MSDN, WSDualHttpBinding Class, [7] Stackoverflow, Diskussion über WebHttpBinding and Callbacks, [8] Stackoverflow, Diskussion über Return null or throw an Exception, [9] Microsoft MSDN Artikel über WCF Log Tracing, [10] Manifesto for Agile Software Development, [11] Android Developers, Designing for Responsiveness, [12] Android Developers, AsyncTask Klasse, [13] Vertec, XML Schnittstelle rvice/xml/xmlschnittstelle [14] G. Coulouris, J. Dollimore, T. Kindberg, G. Blair, Distributed Systems, Concepts and Design, Fifth Edition, Edinburgh 2011 [15] Microsoft MSDN, SourceLevels Enumeration, [16] Android Developers, Log Klasse, [17] Google Developers, Google API Übersicht Client/Server Applikation mit Android

187 Systemspezifikation Quellen Hochschule Luzern [18] Lightweight Object Relational Mapping, ORMLite [19] Juval Lowy, Programming WCF Services, Second Edition: Building Service Oriented Applications with Windows Communication Foundation, [20] Codeproject, Shivprasad Koirala, WCF Concurrency and Throttling Reentrant-and [21] Microsoft MSDN, Sessions, Instancing, and Concurrency, [22] Google Developers, Android Cloud to Device Messaging Framework, [23] Datatypes In SQLite Version 3, [24] Android Developers, Support Package V4, [25] Google GSON Library, A Java library to convert JSON to Java objects, [26] Apache HttpComponents for Java, [27] Antoine Hauck, Trusting SSL certificates, 22. Oktober 2010, Client/Server Applikation mit Android 53

188

189 Hochschule Luzern Bachelor Diplomarbeit TA.BA_BAA+INF.F1201 Client/Server Applikation mit Android T e s t p l a n Horw, 8. Juni 2012

190 Projekt Dokument Schule Modul Client/Server Applikation mit Android Testplan Hochschule Luzern, TA.BA_BAA+INF.F1201 Projektteam Dozent Experte Letzte Änderung Galliker Thomas Studiengang Informatik (BB) Panorama 6123 Geiss Tel Roland Gisler Urs Gehrig 7. Juni 2012, 20:04:00 Uhr Moser Christoph Studiengang Informatik (VZ) Zugerbergstrasse Unterägeri Tel Änderungsprotokoll Version Datum Autor Beschreibung gat Initialversion mit Teststrategie und Testfälle gat Dokumentation Testumgebung gat Continuous Integration, Build Konfigurationen moc Testfälle für UC05 und UC06 angefügt moc Testfälle hinzugefügt moc Testfälle für UC11 hinzugefügt moc Testplan überarbeitet gat Zuweisung Features/Test Cases moc Datenbasis für Integrationstests dokumentiert gat/moc Allgemeine Korrekturen an Inhalt und Layout

191 Inhalt 1 Einleitung Ziel & Zweck dieses Dokuments Begriffe & Abkürzungen Referenzen Teststrategie Testziele Testobjekte Testmethoden Testfälle Teststruktur Datenbasis für Integrationstests Systemtests Tests von Features Testumgebung und -Werkzeuge Continuous Integration Issue Tracking UI- und System-Tests Mock-Tests Mock-Tests für WCF JUnit NUnit Quellen Abbildungsverzeichnis Abbildung 1: Übersicht der Testumgebung Tabellenverzeichnis Tabelle 1: Begriffe & Abkürzungen... 1 Tabelle 2: Referenzierte Dokumente... 1 Tabelle 3: Teststruktur... 4 Tabelle 4: Datenbasis für Integrationstests... 5 Tabelle 5: Zuordnung von Use Cases und Features... 12

192

193 Testplan Einleitung Hochschule Luzern 1 Einleitung 1.1 Ziel & Zweck dieses Dokuments In diesem Dokument werden die Philosophie und die Vorgehensweise beim systematischen Testen der Softwarekomponenten beschrieben. Dieser Testplan dient der Nachvollziehbarkeit bezüglich des Testumfangs, der Testmethodik sowie der Verifikation von Erfolg und Misserfolg der einzelnen Tests. Anwendungsfälle werden in Testfällen abgebildet. Jeder Testfall enthält genaue Spezifikationen bezüglich Testbedingungen, Testvorgehen und erwarteten Resultaten. Alle Informationen, welche mit der Planung von Tests im Zusammenhang stehen, werden in diesem Dokument festgehalten. Die Testprotokolle, d.h. die Protokollierung der einzelnen Testabläufe, werden in separaten Dokumenten (sog. Testprotokolle) abgelegt. 1.2 Begriffe & Abkürzungen Abkürzung ERP HSLU IDE Integrationstest LoC Peer Review Systemtest UI Unit Test VIS VMA WCF Erklärung Enterprise Resource Planning. Ein ERP-System wird in Unternehmen für die Ressourcenplanung eingesetzt. Hochschule Luzern Integrated Development Environment Testet die voneinander abhängigen Komponenten Line of Code, eine Zeile Programmcode Verfahren zur Qualitätssicherung durch unabhängige Gutachter Peers (engl. für Ebenbürtige, Gleichrangige) Testphase wo das gesamte System auf die Anforderungen (funktionale und nicht funktionale Anforderungen) getestet wird User Interface Dient zur Verifikation der Korrektheit von Modulen einer SW Vertec Integration Service Vertec Mobile App Windows Communication Foundation, eine Service-orientierte Kommunikationsplattform für Microsoft.Net Tabelle 1: Begriffe & Abkürzungen 1.3 Referenzen Ref [TPROT] [ISSTR] Dokument 03 Dokumentation \ BDA_Testprotokoll_<yyyy-mm-dd>.doc 04 Entwicklung \ 05 Feedback \ Issue_Tracking.xls Tabelle 2: Referenzierte Dokumente Client/Server Applikation mit Android 1

194 Hochschule Luzern Testplan Teststrategie 2 Teststrategie Die nachfolgenden Kapitel beschreiben die Teststrategien, welche im Zusammenhang mit dem vorliegenden Projekt angewendet werden. 2.1 Testziele Das oberste Ziel beim Testen eines Softwaresystems ist die Erfüllung der qualitativen Aspekte gemäss den definierten Anforderungen. Dieses Ziel kann nur dann erreicht werden, wenn beim Testen eine bestimmte Systematik angewandt wird. Testfälle sollen möglichst automatisiert und wiederholbar ausgeführt werden. Sie definieren bestimmte Eingabewerte und prüfen Erfolg resp. Misserfolg anhand der generierten Ausgabewerte. Da aber in der vorgegebenen Zeit ein Kundenwunsch erfüllt werden muss, werden die Testfälle in priorisierter Reihenfolge erstellt: Vorrang haben jene Tests, welche ein unverzichtbares Ziel erfüllen. Je früher solche Muss-Ziele in Tests umgesetzt werden, je geringer sind die Risiken für das laufende Projekt. Die Testziele dieses Projekts sind nicht nur freigedichtetes Wunschdenken, sondern lassen sich in Zahlen messen. Folgende Kriterien wurden festgelegt: Anforderungserfüllung: Misst nachweisbar den Erfüllungsgrad von Muss-Anforderungen. Die Soll- Vorgabe liegt bei 100%. Testerfolg: Anzahl der Testfälle, welche erfolgreich ausgeführt werden konnten. Die Soll-Vorgabe liegt bei 100%. Code Coverage: Die Code-Abdeckung misst, wie viele Zeilen Code durch automatisierte Tests abgedeckt wurden. Als Soll-Vorgabe wird grundsätzlich 100% des relevanten 1 Codes gesetzt. Sämtliche eingesetzten Klassen sollen in Tests geprüft werden. Die Methoden- und LoC-Abdeckung muss über 80% sein. 2.2 Testobjekte Vertec Mobile App, VMA Vertec Integration Service, VIS 1 Als relevant wird jener Code bezeichnet, welcher in der Erfüllung einer Anforderung direkt oder indirekt beteiligt ist. 2 Client/Server Applikation mit Android

195 Testplan Teststrategie Hochschule Luzern 2.3 Testmethoden Unit Tests: In den Unit-Tests werden einzelne, in sich abgeschlossene Klassen getestet. Die Unit- Tests sollen wo immer möglich parallel zur Entwicklung erstellt und ausgeführt werden. Die Unit-Tests sollen nach dem Test-First Prinzip erstellt werden. Der Test-First Ansatz geht davon aus, dass der Entwurf von Tests und deren Ausführung auch das Design des Programms vorantreibt. Bevor ein Stück eines Programms geschrieben wird, wird zuerst ein Test entworfen, der die zu implementierende Logik prüft [9]. Anschliessend wird nur so viel Programmcode geschrieben, wie der Test verlangt. Dementsprechend findet die Programmentwicklung in einer raschen Folge von Test- und Implementierungsschritten statt. Funktionalität ist bei Unit-Tests gleichbedeutend mit dem Ein-/Ausgabeverhalten der zu prüfenden Einheit. Dabei wird jede Einheit isoliert getestet um sicher zu stellen, dass andere Einheiten keinen Einfluss auf das Verhalten der zu prüfenden Einheit haben und somit ein Fehler rasch zugeordnet werden kann. Mock Tests: Es gibt bestimmte Konstellationen, bei denen es notwendig ist, Subsysteme für Testzwecke zu simulieren. Dazu werden sog. Mock-Objekte gebaut. Mock-Objekte können helfen, bestimmte Unit-Tests auszuführen ohne dabei auf andere Teilsysteme zugreifen zu müssen. Mock Testing bedingt sauberes Trennen der Verantwortlichkeiten unter den eingesetzten Softwarekomponenten sowie die Abstraktion der bereitgestellten Funktionalität über Schnittstellen. Integration Tests: Der Integrationstest hingegen prüft das Zusammenspiel von Komponenten und deren Wechselwirkung. Sowohl Unit-Tests als auch Integrationstests werden an den Schnittstellen der zu prüfenden Einheit durchgeführt. Wichtig ist, dass die Komponenten auf Basis der Systemspezifikation untereinander korrekt agieren und dass eine gute Leistung gewährleistet ist. System Tests: Unit- und Integrationstest können mit entsprechenden Werkzeugen weitgehend automatisiert werden. Systemtests werden in diesem Projekt teilweise manuell durch Testpersonen durchgeführt. Getestet werden hauptsächlich die im Kapitel 3.3 (Seite 6) erfassten Systemtest, welche abhängig von den Anwendungsfällen (Use Cases) definiert wurden. Es wird auch verifiziert, ob die funktionalen und nicht-funktionalen Anforderungen erfüllt werden können. Die durchgeführten System Tests werden in Testprotokollen dokumentiert [TPROT]. Regression Tests: Diese Art des Testens versucht sicherzustellen, dass Änderungen am Programmcode keine neuen Fehler produzieren. Der Testumfang umfasst alle definierten Tests und sollte mit jeder zusätzlich entwickelten Funktionalität erweitert werden. Eminent wichtig ist, dass das ganze Softwaresystem systematisch neu geprüft wird, sobald Änderungen am Code vorgenommen wurden. Um diese Aufgabe zu automatisieren, wurde ein Continuous Integration Server eingerichtet (siehe 4.1 Continuous Integration, Seite 14). Acceptance Tests: Als Akzeptanztest wird ein kompletter Systemtest bezeichnet, welcher feststellt, ob die gestellten Anforderungen durch das zu entwickelnde Projektsystem erfüllt werden. In diesem Projekt wird der Akzeptanztest vom Auftraggeber ausgeführt. Dieser beschliesst letztlich, ob die von ihm gestellten Anforderungen wunschgemäss umgesetzt wurden. Die (Nicht-)Akzeptanz wird in einem Testformular begründet festgehalten. Client/Server Applikation mit Android 3

196 Hochschule Luzern Testplan Testfälle 3 Testfälle Dieses Kapitel gibt einen Einblick in die Teststruktur der beiden Teilprojekte, VMA und VIS. Danach folgt eine Auflistung von Testdaten, welche für Systemtests benötigt werden. Schliesslich werden sämtliche Systemtestfälle aufgelistet. 3.1 Teststruktur Auf eine Übersicht aller Unit- und Integrationstests wird an dieser Stelle verzichtet. Die Tabelle 3 zeigt die Struktur, in welcher die einzelnen automatisierten Testfälle abgelegt wurden. Vertec Mobile App Inhalt ch.hslu.bda.vma.test.unit ch.hslu.bda.vma.test.integration ch.hslu.bda.vma.test.system In diesem Package werden einzelne, in sich abgeschlossene Klassen der VMA getestet. Dieses Package beinhaltet Integrationstests. Das heisst es werden Tests durchgeführt, welche auf den VIS und dadurch auf Daten aus dem ERP-System zugreifen. Robotium erlaubt es Android Activities und Dialoge zu testen. [3] In diesem Package wird Robotium verwendet um auf dem UI automatisierte Tests auszuführen. Vertec Integration Service Common.Test SessionManagement.Test PushNotification.Test VertecConnector.Test.IntegrationTests VertecConnector.Test.UnitTests VertecIntegrationService.Test Testprojekt für Klassenbibliothek Common Testprojekt für Klassenbibliothek SessionManagement Testprojekt für Klassenbibliothek PushNotification Hierbei handelt es sich um Integrationstests, welche auf das Fremdsystem Vertec zugreifen. Deshalb muss für diese Tests auch eine definierte Datenbasis in Vertec zur Verfügung stehen (siehe Kapitel 3.2). Dieses Package enthält Mock-Tests, welche den Zugriff auf das ERP-System anhand von Testdaten simulieren. Diese Tests können also auch durchgeführt werden, wenn kein Zugriff auf das ERP-System besteht. Testprojekt für Klassenbibliothek VertecIntegrationService Tabelle 3: Teststruktur 4 Client/Server Applikation mit Android

197 Testplan Testfälle Hochschule Luzern 3.2 Datenbasis für Integrationstests Im Vertec ERP-System müssen einige Datenobjekte vorhanden sein, damit die automatischen Integrationstests erfolgreich durchgeführt werden können. In Tabelle 4 sind die vorausgesetzten Objekte mit den relevanten Attributwerten definiert, welche für Integrationstests vorausgesetzt werden. Attribut Objekt1 Objekt2 Objekt3 Objekt4 Task Id Projekt Kontakt Customer Id Firma Esotherik GmbH Hutform AG Name Keller Vorname Verena Adresse Wolkenstrasse 7 Zwielstrasse 76a PLZ Ort Zürich Zürich Telefon Projekt Id Projekt Code Beschrieb Phase TESTCONNECTOR Esotherik GmbH Id Projekt Code PRE REQ IMP TEST Beschreibung Pre Project Requirements Implementation Test Service Id Projekt Phase Tätigkeit Aufwand Text test test ServiceType Id Code ADM ALLG Text Administration Allgemeine Arbeiten User Id Benutzername Passwort TestVertecConnector test Tabelle 4: Datenbasis für Integrationstests Client/Server Applikation mit Android 5

198 Hochschule Luzern Testplan Testfälle 3.3 Systemtests Folgende Vorbedingungen liegen sämtlichen Testfällen zu Grunde: Es muss eine Vertec Benutzer vorhanden sein. Dem Vertec Benutzer welcher für die Tests verwendet wird, müssen Aufträge (Vertec Aktivitäten vom Typ Auftrag für den aktuellen Tag zugewiesen sein ST-01.1: Erfolgreicher Login Identifikation Name ST-01.1 Erfolgreiche Anmeldung am Vertec ERP-System Voraussetzung Vertec ERP Server läuft. Vertec XML Schnittstelle verfügbar. Anmeldeinformationen (Credentials) bekannt. Vorgehen 1. Vertec Mobile App starten. 2. Anmeldeinformationen eingeben und bestätigen. 3. Erfolgsmeldung abwarten. Erwartetes Resultat Nach erfolgreichem Login werden automatisch die Projektaufträge geladen und angezeigt. Die VMA unterhält im Hintergrund eine Session ID, mit welcher alle nachfolgenden Anfragen an den Vertec Integration Service gesendet werden. Nachfolgende Aufrufe können ohne Neuanmeldung ausgeführt werden ST-01.2: Fehlgeschlagener Login Identifikation Name ST-01.2 Fehlgeschlagene Anmeldung am Vertec ERP-System Voraussetzung Vertec ERP Server läuft. Vertec XML Schnittstelle verfügbar. Vorgehen 1. Vertec Mobile App starten. 2. Anmeldeinformationen (falscher Benutzername oder falsches Passwort) eingeben und bestätigen. 3. Misserfolgsmeldung abwarten. Erwartetes Resultat Benutzer wird mit einer Fehlermeldung informiert, dass die eingegebenen Login Informationen (Passwort und/oder Benutzername) falsch waren. Die Passwort-Maske wird bei misslungenem Versuch geleert. 6 Client/Server Applikation mit Android

199 Testplan Testfälle Hochschule Luzern ST-02.1: Aufträge abrufen Identifikation Name ST-02.1 Aufträge abrufen Voraussetzung ST-01 erfolgreich: Benutzer am System angemeldet. Vorgehen 1. Über Synchronisations-Button Aufträge neu laden. 2. Auftragsliste mit Projektaufträgen im Vertec ERP-System vergleichen. Erwartetes Resultat Aufträge werden so angezeigt, wie diese im Vertec ERP-System erfasst wurden ST-02.2: Auftragsdetails aktualisieren neuer Auftrag Identifikation Name ST-02.2 Auftragsdetails aktualisieren neuer Auftrag Voraussetzung ST-01 erfolgreich: Benutzer am System angemeldet. ST-02.1 erfolgreich: Aufträge abgerufen. Vorgehen 1. Neuer Auftrag mit dem aktuellen Testdatum im Vertec ERP-System erfassen. 2. Synchronisation starten. 3. Prüfen, ob der neue erfasste Auftrag in der Auftragsliste der VMA angezeigt wird. Erwartetes Resultat Der erstellte Auftrag wird in der Liste mit den heutigen Aufträgen aufgelistet ST-02.3: Auftragsdetails aktualisieren Auftrag löschen Identifikation Name ST-02.3 Auftragsdetails aktualisieren Auftrag löschen Voraussetzung ST-01 erfolgreich: Benutzer am System angemeldet. ST-02.1 erfolgreich: Aufträge abgerufen. Vorgehen 1. Einen Auftrag im ERP-System löschen, welcher in der VMA angezeigt wird. 2. Synchronisation starten. 3. Prüfen, ob Auftrag auf VMA entfernt wird. Erwartetes Resultat Der gelöschte Auftrag wird von der Auftragsliste verschwinden. Client/Server Applikation mit Android 7

200 Hochschule Luzern Testplan Testfälle ST-02.4: Auftragsdetails aktualisieren Auftrag ändern Identifikation Name ST-02.4 Auftragsdetails aktualisieren Auftrag ändern Voraussetzung ST-01 erfolgreich: Benutzer am System angemeldet. ST-02.1 erfolgreich: Aufträge abgerufen. Vorgehen 1. Im Vertec ERP-System für den Auftrag, welcher bei ST-02.2 angelegt wurde, das Datum auf den gestrigen Tag ändern. 2. Synchronisation starten. 3. Änderungen in der Detailansicht des Auftrages überprüfen. Erwartetes Resultat Der veränderte Auftrag sollte neu in der List Aufträge von gestern erscheinen ST-03: Auftragsdetails anzeigen Identifikation Name ST-03 Auftragsdetails anzeigen Voraussetzung ST-01 erfolgreich: Benutzer am System angemeldet. ST-02 erfolgreich: Aufträge abgerufen. Vorgehen 1. Auftrag auswählen. 2. Auftragsdetails mit Projektauftrag im Vertec ERP-System vergleichen. Erwartetes Resultat Auftragsdetails sollen mit erfassten Daten im Vertec ERP-System übereinstimmen ST-04.1: Leistung über Auftrag erfassen Identifikation Name ST-04.1 Leistung über Auftrag erfassen Voraussetzung ST-01 erfolgreich: Benutzer am System angemeldet. ST-02 erfolgreich: Aufträge abgerufen. Vorgehen 1. Auftrag auswählen. 2. Über Schaltfläche neue Leistung erstellen. 3. Leistungsdaten für das Projekt des gewählten Auftrags erfassen. 4. Leistungsdaten speichern. 5. Synchronisation starten. Erwartetes Resultat Die erfasste Leistung sollte nach der Synchronisation im ERP-System angelegt werden und die Werte der Felder sollten übereinstimmen. (Hinweis: Das ERP-System rundet die Aufwandwerte automatisch auf eine Genauigkeit von 5 Minuten) 8 Client/Server Applikation mit Android

201 Testplan Testfälle Hochschule Luzern ST-04.2: Leistung erfassen Identifikation Name ST-04.2 Leistung erfassen Voraussetzung ST-01 erfolgreich: Benutzer am System angemeldet. ST-02 erfolgreich: Aufträge abgerufen. Vorgehen 1. Liste der Leistungen aufrufen. 2. Über Schaltfläche neue Leistung erstellen. 3. Leistungsdaten erfassen und speichern. 4. Synchronisation starten. Erwartetes Resultat Die erfasste Leistung sollte nach der Synchronisation im ERP-System angelegt werden und die Werte der Felder sollten übereinstimmen. (Hinweis: Das ERP-System rundet die Aufwandwerte automatisch auf eine Genauigkeit von 5 Minuten) ST-05.1: Kundendaten anzeigen Identifikation Name ST-05.1 Kundendaten anzeigen Voraussetzung ST-01 erfolgreich: Benutzer am System angemeldet. ST-02 erfolgreich: Aufträge abgerufen. Vorgehen 1. Projektauftrag auswählen 2. Den Kunden anwählen, welcher in den Auftragsdetails des gewählten Projektauftrags angezeigt wird. 3. Kundendetails mit den Kundendaten im Vertec ERP-System vergleichen Erwartetes Resultat Kundendetails sollen mit den erfassten Daten im Vertec ERP-System übereinstimmen ST-05.2: Kundendaten anzeigen nachdem der Kunde verändert wurde. Identifikation Name ST-05.2 Kundendaten anzeigen nachdem der Kunde verändert wurde. Voraussetzung ST-01 erfolgreich: Benutzer am System angemeldet. ST-02 erfolgreich: Aufträge abgerufen. Vorgehen 1. Projektauftrag auswählen 2. Im ERP-System beim gewählten Projektauftrag eine neue Kontaktperson zuweisen. 3. Synchronisation starten. 4. Den Kunden anwählen, welcher in den Auftragsdetails des gewählten Projektauftrags angezeigt wird. Erwartetes Resultat Es sollten die Kundendetails des neu zugewiesenen Kunden angezeigt werden. Client/Server Applikation mit Android 9

202 Hochschule Luzern Testplan Testfälle ST-06: Kunde anrufen Identifikation Name ST-06 Kunde anrufen Voraussetzung ST-01 erfolgreich: Benutzer am System angemeldet. ST-02 erfolgreich: Aufträge abgerufen. ST-05 erfolgreich: Kundendetails werden angezeigt. Vorgehen 1. Die Telefonnummer in den Kontaktdetails wählen. 2. In der Android Call API bestätigen, dass der Anruf ausgeführt werden soll. Erwartetes Resultat Die angezeigte Telefonnummer aus den Kontaktdetails wird angerufen ST-08: Aufzeigen des Anfahrtswegs Identifikation Name ST-08 Aufzeigen des Anfahrtswegs Voraussetzung ST-01 erfolgreich: Benutzer am System angemeldet. ST-02 erfolgreich: Aufträge abgerufen. ST-05 erfolgreich: Kundendetails werden angezeigt. Vorgehen 1. Die Adresse des Kunden wählen. Erwartetes Resultat Google Maps wird geöffnet und es wird die Strecke vom aktuellen Standort zum Standort des Kunden angezeigt. Wenn die GPS Lokation nicht ausgelesen werden kann, wird beim Abfahrtsort ein Fragezeichen eingetragen ST-10: Auftrag abschliessen Identifikation Name ST-10 Auftrag abschliessen Voraussetzung ST-01 erfolgreich: Benutzer am System angemeldet. ST-02 erfolgreich: Aufträge abgerufen. Vorgehen 1. Projektauftrag auswählen. 2. Über den Button Abschliessen in den Auftragsdetails, den gewählten Projektauftrag abschliessen. 3. Synchronisation starten. Erwartetes Resultat Der Auftrag verschwindet in der Auftragsliste der VMA. Im Vertec ERP-System ist beim gewählten Auftrag das aktuelle Datum im Feld erledigt? gesetzt. 10 Client/Server Applikation mit Android

203 Testplan Testfälle Hochschule Luzern ST-11.1: Leistung bearbeiten (Source ERP-System) Identifikation Name ST-11.1 Leistung bearbeiten (Source ERP-System) Voraussetzung ST-01 erfolgreich: Benutzer am System angemeldet. ST-02 erfolgreich: Aufträge abgerufen. Vorgehen 1. Im ERP-System eine Leistung für den Benutzer erstellen, welcher in der VMA angemeldet ist. Die Leistung muss für ein Projekt erfasst werden, für welches der Benutzer mindestens einen offenen Auftrag besitzt. 2. In der VMA die Synchronisation starten. 3. Die Liste mit den erfassten Leistungen öffnen. 4. Die in Schritt 1 erstellte Leistung öffnen. 5. Den Text sowie den Aufwand der Leistung ändern und speichern. 6. Synchronisation starten. Erwartetes Resultat Der geänderte Text sowie der Aufwand wurden im ERP-System verändert ST-11.2: Leistung bearbeiten (Source VMA-System) Identifikation Name ST-11.2 Leistung bearbeiten (Source VMA-System) Voraussetzung ST-01 erfolgreich: Benutzer am System angemeldet. ST-02 erfolgreich: Aufträge abgerufen. ST-04 erfolgreich: Leistung erfasst Vorgehen 1. Die Liste mit den erfassten Leistungen öffnen. 2. Eine bestehende Leistung öffnen, welche ursprünglich mit der VMA erfasst wurde. 3. Den Text sowie den Aufwand der Leistung ändern und speichern. 4. Synchronisation starten. Erwartetes Resultat Der geänderte Text sowie der Aufwand wurden im ERP-System verändert ST-12.1: Leistungen abrufen Identifikation Name ST-12.1 Leistungen abrufen Voraussetzung ST-01 erfolgreich: Benutzer am System angemeldet. Vorgehen 1. Über Synchronisations-Button Aufträge neu laden. 2. Leistungsliste mit den Leistungen im Vertec ERP-System vergleichen. Erwartetes Resultat Leistungen werden so angezeigt, wie diese im Vertec ERP-System erfasst sind. Client/Server Applikation mit Android 11

204 Hochschule Luzern Testplan Testfälle ST-12.2: Leistungen aktualisieren neue Leistung Identifikation Name ST-12.2 Leistungen aktualisieren neue Leistung Voraussetzung ST-01 erfolgreich: Benutzer am System angemeldet. ST-12-1 erfolgreich Leistungen abgerufen Vorgehen 1. Neue Leistungen für ein Projekt anlegen, für welches der angemeldete Benutzer einen offenen Auftrag besitzt. 2. Synchronisation starten. 3. Prüfen, ob Leistung auf VMA angezeigt wird. Erwartetes Resultat Die erstellte Leistung wird in der Liste mit den Leistungen angezeigt ST-13.1: Support Informationen anzeigen Identifikation Name ST-13.1 Support Informationen anzeigen Voraussetzung VMA gestartet. Vorgehen 1. Über Menüaufruf das Info Fenster öffnen. Erwartetes Resultat VIS und VMA Versionen werden angezeigt. Support Organisation mit Name, Telefon und Mail wird angezeigt. Session Identifikationsnummer (sofern angemeldet) wird angezeigt. Konfigurierte Service URL wird angezeigt. 3.4 Tests von Features In einigen Use Cases kommen die in der Kundenanforderung aufgeführten Features vor. Da diese nur teilweise durch automatische Tests gedeckt sind, ist es wichtig, dass die Funktionsweise der Features im Zuge der manuellen Systemtests geprüft wird. Tabelle 5 zeigt, welche Features in welchen Use Cases (UC) vorkommen. In den Testprotokollen sollen jene Features erwähnt werden, welche nicht korrekt funktionieren. UC1 UC2 UC3 UC4 UC5 UC6 UC7 UC8 UC9 UC10 UC11 UC12 UC13 F-1 F-2 F-3 F-4 F-5 F-6 F-7 F-8 F-9 F-10 Tabelle 5: Zuordnung von Use Cases und Features 12 Client/Server Applikation mit Android

205 Testplan Testumgebung und -Werkzeuge Hochschule Luzern 4 Testumgebung und -Werkzeuge Um das geplante Testkonzept umsetzten zu können, werden verschiedene Werkzeuge eingesetzt. Die Testumgebung hat das oberste Ziel der Automatisierung des Erstellungs-, Test- und Qualitätssicherungsprozesses. Die Rollen der involvierten Systeme werden im nachfolgenden Diagramm erläutert: Abbildung 1: Übersicht der Testumgebung Die Entwickler arbeiten vorwiegend im internen Netzwerk der Hochschule, können sich aber auch über VPN auf dieses Netzwerk verbinden. Der Entwicklungsprozess läuft parallel zu sämtlichen anderen Prozessen ab (1). Der Quellcode kann auf das vom Enterprise Lab betriebene Subversion Repository eingecheckt werden (2). Der Continuous Integration Server pollt in regelmässigen Zeitabständen das Subversion Repository, um Änderungen am Code festzustellen (3). Abhängig von der aktuellen Build Konfiguration wird geänderter Code sofort oder zu einem bestimmten Zeitpunkt ausgecheckt, kompiliert und geprüft (4). Ausgecheckter Code von Web Projekten wird direkt ins entsprechende Verzeichnis des Web Servers kopiert. Damit steht dieser für Development Tests bereit (5). Beim Auslösen eines Release Builds wird das aktuellste Web Projekt vom internen Entwicklungsserver auf den externen DMZ Web Server kopiert (6). Softwaretester können die Software von der Artifakt-Webseite herunterladen (7), auf ihr Android Testgerät installieren (8) und die Software testen (9). Client/Server Applikation mit Android 13

206 Hochschule Luzern Testplan Testumgebung und -Werkzeuge Ohne Tool Support wäre die beschriebene Testumgebung kaum realisierbar. In den nachfolgenden Sektionen werden die verwendeten Hilfsmittel kurz beschrieben. 4.1 Continuous Integration Produkt TeamCity 7.0 Beschreibung Referenz TeamCity ist ein Continuous Integration Server von JetBrains. TeamCity unterstützt die Entwicklung für verschiedene Plattformen (.NET, Java und Ruby) und ist deshalb gut geeignet für das vorliegende Projektsystem. In TeamCity wurde der ganze Build- und Release-Prozess abgebildet. Projekte werden automatisch kompiliert, getestet und veröffentlicht. Es werden verschiedene Plugins eingesetzt: Code Coverage, Code Inspection, Duplicate Finder, Assembly Patcher, sowie eigenentwickelte Scripts (z.b. für das automatisierte Publizieren von Webprojekten) Issue Tracking Produkt Beschreibung Referenz Microsoft Excel Um den Überblick, über die gemeldeten Fehler aus Systemtests oder Rückmeldungen von Interessensgruppen zu wahren, wurde eine Issue Tracking Liste erstellt. In dieser Excel-Liste wird jeder Fehler kurz beschrieben und einer verantwortlichen Person zugeteilt. Die offenen Issues dienen jeweils als Basis für die Feinplanung. [ISSTR] 4.3 UI- und System-Tests Produkt Beschreibung Robotium Robotium ist ein Test-Framework für Android, welches für automatisierte UI-und Systemtests eingesetzt wird. Robotium-Tests versuchen, das Benutzerverhalten so weit wie möglich zu simulieren. Referenz [3] 4.4 Mock-Tests Produkt Beschreibung NMock2 NMock2 unterstützt den Ansatz von Test-Driven Development für Microsoft.Net. NMock2 wurde zwar für.net 2.0 geschrieben, konnte aber in VIS sehr praktisch für Mock Tests eingesetzt werden. NMock2 wird beispielsweise auf VIS eingesetzt, um die Vertec Connector Klasse zu testen, ohne dabei auf das ERP- System zugreifen zu müssen. Referenz [5] 14 Client/Server Applikation mit Android

207 Testplan Testumgebung und -Werkzeuge Hochschule Luzern 4.5 Mock-Tests für WCF Produkt Beschreibung Moq + WCFMock Moq wird als Mock Test Framework genutzt und erlaubt es zusammen mit WCFMock Unit Tests für WCF Services zu schreiben. WCFMock simuliert einund ausgehende WebContexts. WCFMock funktioniert leider nur mit Moq und nicht mit NMock2. So wurde während dem Projekt entschieden, dass die Mock Tests für WCF mit Moq und nicht mit NMock2 geschrieben werden. Referenz [7] [8] 4.6 JUnit Produkt JUnit Beschreibung Im vorliegenden VMA-Testprojekt wird JUnit zum Ausführen von automatisierten Unit-, Integrations- und Systemtests eingesetzt. Referenz [10] 4.7 NUnit Produkt NUnit Beschreibung NUnit ist ein Unit Testing-Framework für alle.net Sprachen. Der Leistungsumfang von MSTest war für dieses Projekt nicht genügend. Ein weiterer Vorteil ist, dass NUnit nicht abhängig von einer bestimmten IDE ist. NUnit kommt auch im TeamCity Server zum Einsatz, um Testfälle automatisiert auszuführen. Referenz [6] Client/Server Applikation mit Android 15

208 Hochschule Luzern Testplan Quellen 5 Quellen Ref Quellenangabe / URL [1] Android Testing: XML Reports for Continuous Integration, [2] Android JUnit Report Test Runner, [3] Robotium, User scenario testing for Android, [4] Jetbrains, Teamcity 7, Continuous Integration for Everybody, [5] NMock2 Team, NMock2, [6] NUnit [7] Moq, The simplest mocking library for.net and Silverlight [8] WCFMock [9] Scott W. Ambler, Introduction to Test Driven Development (TDD), [10] Android Developers, Testing Fundamentals, Letzter Zugriff Client/Server Applikation mit Android

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223 Hochschule Luzern Bachelor Diplomarbeit TA.BA_BAA+INF.F1201 Client/Server Applikation mit Android B e t a P r o g r a m m Horw, 8. Juni 2012

224 Projekt Dokument Schule Modul Client/Server Applikation mit Android Beta Programm Hochschule Luzern, TA.BA_BAA+INF.F1201 Projektteam Dozent Experte Letzte Änderung Galliker Thomas Studiengang Informatik (BB) Panorama 6123 Geiss Tel Roland Gisler Urs Gehrig 7. Juni 2012, 00:10:00 Uhr Moser Christoph Studiengang Informatik (VZ) Zugerbergstrasse Unterägeri Tel Änderungsprotokoll Version Datum Autor Beschreibung gat Initialversion gat Neue Use Cases (12+13) hinzugefügt gat Ergänzungen zu den Teststufen Inhalt 1 Über das Beta Programm Vorgehensweise Android Gerät vorbereiten APK installieren VMA testen Rückmeldung abgeben Bekannte Probleme und Hinweise... 4

225 Beta Programm Über das Beta Programm Hochschule Luzern 1 Über das Beta Programm Dieses Beta Programm wurde ins Leben gerufen, um die Anforderungen an das Softwaresystem frühzeitig und direkt vom Auftraggeber respektive den späteren Endanwender testen zu lassen. Beta Tester haben die Möglichkeit, die Software Releases der Stufe Quality Assurance eingehend zu testen, mit den gestellten Anforderungen zu vergleichen und danach eine Rückmeldung zu geben. Die nachfolgenden Kapitel enthalten sowohl eine Anleitung zur Vorgehensweise, ein Formular für Rückmeldungen sowie eine Sektion mit bekannten Fehlern und generellen Hinweisen zur Handhabung der Software. 2 Vorgehensweise Die nachfolgenden Schritte erklären Ihnen, wie Sie Ihr Android Gerät für die Installation vorbereiten, wie Sie die Vertec Mobile App installieren können und wie Sie beim Testen der Anwendung vorgehen sollten. Anschliessend können Sie das Rückmeldeformular nutzen, um Ihre Erkenntnisse in die Entwicklung einzubringen. 2.1 Android Gerät vorbereiten Einige Versionen von Android müssen für das Installieren von unbekannten Quellen aktiviert werden. Die entsprechende Einstellung ist unter Einstellungen Anwendungen zu finden. Hinweis zur Einstellung Unbekannte Quellen Die Einstellung Unbekannte Quellen kann dazu führen, dass Schadsoftware auf das Android Gerät gelangt. Es ist dringend zu empfehlen, diese Option nach Gebrauch wieder zu deaktivieren. 2.2 APK installieren Android Software wird in Form eines Installationspakets, kurz APK, ausgeliefert. Es gibt verschiedene Wege, wie ein Android Software Paket installiert werden kann. Laden Sie die aktuellste VMA Version der Qualitätsstufe quality auf Ihr Android Gerät herunter: Artefakte der Stufe Development : Artefakte der Stufe Quality Assurance : Artefakte der Stufe Production : Die ausführbaren VMA Installationspakete sind mit *_bin.zip gekennzeichnet. Die jeweilige Versionsnummer (hier: ) vermerken Sie Rückmeldeformular unter Test Release. Nach erfolgtem Download entpacken Sie das Zip Archiv und installieren die darin befindliche APK Datei auf Ihr Android Gerät. Das Installationspaket erstellt automatisch eine Verknüpfung auf den Desktop Ihres Android Geräts. Starten Sie die Anwendung indem Sie das Applikationslogo berühren. Client/Server Applikation mit Android 1

226 Hochschule Luzern Beta Programm Vorgehensweise 2.3 VMA testen Starten Sie die Anwendung Vertec Mobile App, welche Sie unter den installierten Anwendungen auf Ihrem Android Gerät finden. Als erstes wird das Login-Fenster angezeigt. Wählen Sie im Menü die Einstellungen Schaltfläche. Konfigurieren Sie die Service URL. Es wurde für jede Qualitätsstufe eine Service URL hinterlegt. Wählen Sie die Stufe VIS-Quality, um die Artefakte der Stufe Qualitätssicherung zu testen Mit der Zurück -Taste kehren Sie zum Login-Fenster zurück. Wählen Sie im Menü die Info Schaltfläche. Notieren Sie sich die aufgeführten Versionsnummern für VMA und VIS. Sie werden diese später beim Ausfüllen des Rückmeldeformulars benötigen. Mit der Zurück -Taste kehren Sie zum Login-Fenster zurück. Benutzername und Passwort sind (je nach Qualitätsstufe) bereits eingefüllt. Drücken Sie Einloggen, um fortzufahren. Testen Sie funktionale und nicht-funktionale Anforderungen. Notieren Sie allfällige Diskrepanzen, Fehler und Unschönheiten. 2 Client/Server Applikation mit Android

227 Beta Programm Vorgehensweise Hochschule Luzern 2.4 Rückmeldung abgeben Folgende Tabelle kann als Rückmeldeformular verwendet werden. Geben Sie präzise Informationen, sodass Fehler vom Entwicklerteam reproduziert werden können. Die schraffierten Flächen müssen nicht ausgefüllt werden. Senden Sie das Formular an ID Test Person Datum Test Release VMA Version: VIS Version: Testumfang Use Case 1 Use Case 2 Use Case 3 Use Case 4 Use Case 6 Use Case 8 Use Case 10 Use Case 11 Use Case 12 Use Case 13 Bemerkung (Beschreiben Sie hier, wie Sie vorgegangen sind und was Sie mit Ihrem Test erreichen wollten). Rückmeldung Funktionalität, Benutzerfreundlichkeit, Fehlermeldungen, Reaktionszeit, Verbesserungsvorschläge Funktion X funktioniert nicht, Funktion Y nicht verständlich, Bearbeiter Massnahmen Client/Server Applikation mit Android 3

228 Hochschule Luzern Beta Programm Bekannte Probleme und Hinweise 3 Bekannte Probleme und Hinweise Die Artefakte können über den Android Browser nur via Http und nicht via Https von der Artefakt- Webseite heruntergeladen werden. Der Browser scheint das nicht-vertrauenswürdige Zertifikat nicht ohne weiteres zu akzeptieren. Deinstallieren Sie alte Versionen von VMA bevor Sie neuere Versionen installieren. Die persönlichen Einstellungen gehen dabei verloren. Fehlermeldung bezüglich Unable to resolve vis.enterpriselab.ch oder Connection to refused kann folgende Gründe haben: o Keine Internetverbindung. Prüfen Sie WLAN/3G Verbindungen indem Sie eine beliebige Internetseite (z.b. öffnen. o Falscher VIS festgelegt: Prüfen Sie die Konfiguration der Service URL. Die Übersetzung ist teilweise noch nicht vollständig. 4 Client/Server Applikation mit Android

229

230

231 Hochschule Luzern Bachelor Diplomarbeit TA.BA_BAA+INF.F1201 Client/Server Applikation mit Android A P P E N D I X Horw, 8. Juni 2012

232

233 APPENDIX Hochschule Luzern Appendix A: Aufgabenstellung Client/Server Applikation mit Android 1

234 Hochschule Luzern APPENDIX 2 Client/Server Applikation mit Android

235 APPENDIX Hochschule Luzern Client/Server Applikation mit Android 3

236 APPENDIX Hochschule Luzern Appendix B: Übersicht der Android Versionen Plattform Codename API Level Neue Funktionen Device Verteilung Android 1.6 Donut 4 - WVGA Screen Resolution Smartphone 1.0% Anrdoid 2.1 Eclair 7 - HTML 5 support - Bluetooth Better screen size resolution & contrast ratio Smartphone 7.6% Android 2.2 Froyo 8 - Improved speed, memory & Performance Smartphone 27.8% Android Gingerbread 10 - NFC - Concurrent Garbage collection - Download manager for large downloads - Enhanced Power management Smartphone 58.1% Android 3.1 Honeycomb 12 - UI imporvements - USB host API Tablet 1.4% Android 3.2 Honeycomb 13 - Optimization for a wider range of tablets Tablet 1.9% Android Ice Cream Sandwich 14 - Facial recognition - UI use Hardware acceleration Android Ice Cream Sandwich 15 - Accessibilty API refinements for screen readers Auflistung der wesentlichen Android Versionen 1, 2 Smartphone / Tablet 0.3% Smartphone / Tablet 0.7% Client/Server Applikation mit Android 4

237 APPENDIX Hochschule Luzern Appendix C: User Interface Map TaskListActivity TaskDetailsActivity Google Maps Activity TaskDetailsActivity Select «Address» Select «Customer» Select «Task» LoginActivity MainActivity Press «Create Service» Press «Login» START APP Dashboard «Tasks» Dashboard «Services» ServiceListActivity ServiceDetailsActivity Select «Phone» Select «Due Date» Calendar API Phone Activity Select «Service» EXIT APP Menu «Exit» Menu «Log» LogActivity Client/Server Applikation mit Android Menu «Preferences» PreferencesActivity Menu «Info» InfoActivity 5