Android-Monitoring zur Erhebung und Interpretation des Ausführungskontexts von Apps

Größe: px
Ab Seite anzeigen:

Download "Android-Monitoring zur Erhebung und Interpretation des Ausführungskontexts von Apps"

Transkript

1 Gottfried Wilhelm Leibniz Universität Hannover Fakultät für Elektrotechnik und Informatik Institut für Praktische Informatik Fachgebiet Software Engineering Android-Monitoring zur Erhebung und Interpretation des Ausführungskontexts von Apps Masterarbeit im Studiengang Informatik von Sascha Betten Prüfer: Prof. Dr. Kurt Schneider Zweitprüfer: Prof. Dr. Joel Greenyer Betreuer: M. Sc. Tristan Wehrmaker Hannover,

2 Zusammenfassung Während für Desktopapplikation viele Werkzeuge und Methoden zur Usability- Evaluation und Fehlererkennung vorhanden sind, existiert ein Mangel für mobile Applikationen (Apps). Vorhandene Vorgehensweisen umfassen Laborversuche und direkte Beobachtungen von Benutzern, um Probleme einer Applikation festzustellen. Allerdings werden Benutzer so aus ihrer natürlichen Umgebung gerissen und zeigen oft kein natürliches Benutzerverhalten mehr. Deshalb wurde in dieser Arbeit ein Konzept entwickelt, welches als Remote Usability Evaluation System (RUES) umgesetzt wurde. Benutzer sind so jederzeit und von überall aus in der Lage Feedback zu einer App abzugeben. Zusätzlich wird der Ausführungskontext der App zu dem betreffenden Zeitpunkt erfasst und zusammen mit dem Feedback an eine Serveranwendung verschickt. Diese Serveranwendung analysiert anschließend automatisiert den Ausführungskontext. Hierzu wurden einige Konzepte entwickelt die zeigen, wie Usability-Probleme und Fehler erkannt werden können. Evaluationsexperten und Entwickler sind dann, mit Hilfe des analysierten Ausführungskontexts, in der Lage die Qualität einer App zu verbessern.

3 Abstract While for desktop applications many tools and methods for usability evaluation and error detection are available, there is a lack for mobile applications (apps). Existing approaches attempt to determine problems in an application by laboratory experiments and direct observation of users. But users may be torn from their natural environment and show no natural user behaviour. Therefore, a concept was developed in this work, which is implemented as a remote usability evaluation system (RUES). The system provides feedback to users at anytime and from anywhere. In addition, the execution context of the app will be captured and sent to a server application together with the feedback. These automatically analyses the execution context and tries to find errors and usability problems. For this, some concepts have been developed, showing how usability problems and errors can be detected. Evaluation experts and developers are able to improve the quality of an app with the help of the analyzed execution context.

4 Inhaltsverzeichnis Inhaltsverzeichnis 1. Einleitung Motivation Ziel der Arbeit Vorgehensweise Problemszenarien Grundlagen Ausführungskontext von mobilen Applikationen Monitoring AspectJ Usability Usability Evaluation Remote Usability Evaluation Mobile Usability Usability Activities Contexter Android Grundlagen Activity Activity-Lebenszyklus Gesten RUES - Remote Usability Evaluation System Datenerfassung Android-Monitoring Datenanalyse Berührpunkt-Interpretation Gesten-Interpretation Android Benutzeroberflächen-Richtlinien Benutzeraktivitätserkennung Use-Cases-Erkennung Fehlereproduktion Datenauswertung Prototypische Umsetzung Systemüberblick

5 Inhaltsverzeichnis 4.2. Datenerfassung Bibliothek Datenspeicherung Senden eines Feedbacks Erfassungssystem Sensorkonfiguration Anwendungsfälle im Datenerfassungssystem Datenanalyse RUES Analyse System Interpreter System Datenauswertung Entities Feedback Verwandte Arbeiten FastFix muevaluationframework MultiDevice RemUsine RERAN Auswertung Demoszenarien Stärken von RUES Schwächen von RUES Fazit und Ausblick Kritische Würdigung Systementwurf Datenerfassung Datenanalyse Datenauswertung Ausblick Literaturverzeichnis 69 Abbildungsverzeichnis 72 A. Compact Disc 74 5

6 1. Einleitung 1. Einleitung 1.1. Motivation Wenn mobile Applikationen (Apps) erstellt werden, ist es sinnvoll sie auf Fehler, Tauglichkeit und Usability unter realistischen Einsatzbedingungen zu überprüfen. Im Desktopbereich existieren gute Werkzeuge und Methoden die den Entwicklern dabei helfen, die Qualität ihrer Software zu verbessern, jedoch existiert ein Mangel an Unterstützung für mobile Plattformen. Usability-Evaluationen für mobile Plattformen sind problematisch, denn sie sind sehr teuer und zeitintensiv und beinhalten komplizierte Laboraufbauten. In diesen Laboraufbauten wird oft versucht, den Benutzer so gut wie möglich mit Kameras zu filmen um seine Interaktionen mit dem Gerät nachverfolgen zu können. Allerdings werden die Benutzer so aus ihrer natürlichen Umgebung gerissen und zeigen evtl. nicht das übliche Benutzerverhalten, welches notwendig wäre, um gute Evaluationsergebnisse zu erzielem. Anders als bei Desktop-Anwendungen interagieren Benutzer mit ihrem mobilen Gerät oft unter schwierigen Bedingungen. Eine laute Umgebung oder auch starke Sonneneinstrahlung können die Benutzung des Geräts erschweren. Aus diesen Gründen ist es notwendig Feedback von Benutzern zu erhalten bzw. es ihnen zu ermöglichen ein Feedback abzugeben, wenn Probleme auftauchen oder besondere Beobachtungen gemacht werden. Ein solches Feedback möchte ein Benutzer aber mit möglichst wenig Aufwand formulieren können und dennoch fundierte Informationen darüber liefern, was die Anwendung gerade getan hat, als die Beobachtung gemacht wurde oder das Problem aufgetreten ist. Deshalb ist es wichtig, den Ausführungskontext der Applikationen zu dem betreffenden Zeitpunkt zu erfassen, damit die Rückmeldung gut interpretiert werden kann. Durch die enormen Datenmengen, die durch die Erfassung des Ausführungskontexts entstehen, ist es sehr schwer Usability-Probleme und Systemfehler zu identifizieren. Eine manuelle Analyse durch einen Evaluationsexperten wäre zu zeitintensiv, deshalb wäre es wünschenswert, wenn die Analyse dieser Daten zum größten Teil automatisch passieren würde, um die Arbeit für die Evaluationsexperten einfacher zu gestalten. Evaluationsexperten können dann zusammen mit den Entwicklern Probleme in der entwickelten Applikation (im Folgenden als Host-Applikation bezeichnet) identifizieren, um die Qualität der Software zu verbessern. 1

7 1. Einleitung Diese Arbeit beschreibt ein Remote Usability Evaluation System mit dem Namen RUES für mobile Geräte, welches Softwareentwicklern dabei helfen soll, Fehler und Usability-Probleme in ihrer entwickelten Android-Applikation mit Hilfe von User- Feedback und des analysierten Ausführungskontexts zu finden Ziel der Arbeit Ziel der Arbeit ist die Entwicklung von Konzepten, die es ermöglichen, den Ausführungskontext einer Host-Applikation zu erfassen und zu analysieren. Dazu ist es notwendig, alle Interaktionen eines Benutzers sowie Sensordaten des mobilen Geräts bei der Benutzung einer zu evaluierenden Host-Applikation aufzuzeichnen. Benutzer der zu evaluierenden Host-Applikation sollen in der Lage sein, möglichst einfach Feedback abzugeben. Alle erfassten Daten sollen mit dem Feedback zusammen an eine Serveranwendung geschickt werden, die die Daten aufschlüsselt, analysiert und anschaulich aufbereitet. Die Analyse dieser Daten soll dabei helfen Usability-Probleme zu identifizieren, die mit herkömmlichen Werkzeugen und Methoden der Usabilty-Evaluation nicht aufspürbar bzw. nur mit einem sehr viel höheren Aufwand zu identifizieren wären. Die Aufbereitung der analysierten Daten soll zudem helfen Fehler die Benutzer festgestellt haben, zu reproduzieren Vorgehensweise Diese Arbeit besteht aus insgesamt sieben Kapiteln. Im Kapitel 1 wird die Problemstellung und das Ziel der Arbeit formuliert, zusätzlich werden Problemszenarien beschrieben, welche zeigen, unter welche Umständen gängige Methoden zur Überprüfung von Fehlern und Usability-Problemen scheitern. Kapitel 2 erklärt die elementaren Grundlagen die zum Verständnis dieser Arbeit benötigt werden. Kapitel 3 stellt die Konzepte von RUES vor. Das Kapitel unterteilt sich in die drei Abschnitte Datenerfassung, Datenanalyse und Datenauswertung. Im Abschnitt Datenerfassung geht es um Konzepte zur Erfassung von Daten auf mobilen Geräten. Der Abschnitt Datenanalyse beschäftigt sich mit Konzepten zur Analyse dieser Daten, um den Ausführungskontexts zu erheben. Dabei geht es zum größten Teil um die automatische Interpretation dieser Daten, um Evaluationsexperten und Entwicklern die Auswertung von Feedbacks zu erleichtern. Der Abschnitt Datenauswertung fasst die Ergebnisse des analysierten Ausführungskontexts zusammen und veranschaulicht den gesamten Prozess von RUES. 2

8 1. Einleitung Kapitel 4 behandelt die prototypische Umsetzung der beschriebenen Konzepte von RUES. In Kapitel 5 werden verwandte Arbeiten vorgestellt. In Kapitel 6 wird eine Evaluation durchgeführt. Dazu werden zunächst Demoszenarien beschrieben, die die Problemszenarien aus Kapitel 1 aufgreifen. Anschließend werden die Stärken und Schwächen von RUES diskutiert. Im letzten Kapitel 7 wird eine Zusammenfassung sowie ein Fazit zur Arbeit gegeben. Zum Abschluss wird ein Ausblick gegeben, in dem mögliche Erweiterungen zur Verbessung von RUES diskutiert werden Problemszenarien In diesem Abschnitt werden Problemszenarien beschrieben, welche zeigen, unter welchen Umständen gängige Methoden zur Usability Evaluation für mobilen Geräten an ihre Grenzen stoßen. Problemszenario 1 Alice arbeitet an einer mobilen Lernsoftware für Schulen. Sie möchte eine Evaluation durchführen, um ihre App zu verbessern. Szenarioname: Problem - Lernsoftware Akteure: Alice (Entwickler), Bob (Testbenutzer) Ereignisse: i Alice beschließt die Evaluation selbst durchzuführen. ii Bob ist ein Kind im Alter von 7 Jahren. Alice stellt Bob ein mobiles Gerät zur Verfügung, damit er ihre neue App testen kann. Nach einer Weile bemerkt Alice, dass Bob Probleme mit der App hat, die App scheint nicht mehr auf Benutzereingaben zu reagieren. Dieses ist Alice selber noch nie passiert, deswegen fragt sie Bob, wie es zu dem Problem kam. Aufgrund seins Alters kann er Alice aber nicht genau erklären, wie es dazu kam. iii Alice beschließt Bob während der Benutzung ihrer Applikation zu beobachten, um zu sehen, wie der Fehler zustande kommt. Aufgrund der kleinen Bildschirmgröße, des mobilen Geräts, gelingt es Alice aber nicht alle Interaktionen von Bob genau mitzuverfolgen. Aus diesem Grund ist Alice nicht in der Lage den Fehler zu reproduzieren. 3

9 1. Einleitung iv Also beschließt Alice Bobs Interaktionen mit dem Gerät, mit einer Kamera zu filmen. Bob ist nicht sehr erfreut darüber, denn durch die Kamera, ist er in seiner Bewegung eingeschränkt. v Nachdem Alice genügend Videomaterial mit der Kamera gesammelt hat, versucht sie, anhand des aufgezeichneten Materials, den Fehler zu finden. Nach einiger Zeit gelingt es ihr schließlich den Fehler zu reproduzieren. Analyse Sehr junge Testbenutzer sind oft nicht in der Lage sich genau genug mitzuteilen, damit aufgrund dieser Informationen, Fehler gefunden werden können. Interaktionen lassen sich aufgrund der meist kleinen Bildschirmgröße kaum mit bloßem Auge mitverfolgen, da der Bildschirm zum großten Teil durch die Finger des Testbenutzers verdeckt wird. Die Aufnahme von Interaktionen mittels einer Kamera ist oft sehr belastend für den Benutzer, da dieser in der Bewegung einschränkt wird. Möglicherweise zeigt der Benutzer so kein natürliches Verhalten mehr, so dass die Probleme oder die Fehler nicht mehr auftauchen bzw. reproduziert werden können. Die Analyse von Videomaterial kann dabei helfen Fehler zu finden, allerdings nimmt eine solche Analyse oft sehr viel Zeit in Anspruch. Problemszenario 2 Alice hat eine neue App zum Erstellen von Notizen entwickelt und stellt diese als Beta-App in den Google-Play-Store. Sie möchte den Benutzern eine Möglichkeit geben, Feedback zu ihrer Applikation abzugeben, um ihre Applikation verbessern zu können. Szenarioname: Problem - Notiz Applikation Akteure: Alice (Entwickler), Charlie und Dave (Testbenutzer) Ereignisse: i Alice beschließt ein einfaches Feedbacksystem zu implementieren. Benutzern soll es so möglich sein, ein einfaches textuelles Feedback abzugeben. ii Charlie hat sich diese Applikation heruntergeladen und benutzt diese nun eifrig. Bereits nach kurzer Zeit ist Charlie sehr unzufrieden mit der Bedienung der App und beschließt ein Feedback abzugeben. Er beschreibt die Applikation als benutzerunfreundlich, denn er benötigt sehr viel Zeit, um einfache 4

10 1. Einleitung Aufgaben mit der Applikation zu erfüllen. Alice bekommt das Feedback kurze Zeit später. Leider weiß Alice nichts mit dem Feedback anzufangen, sie war eigentlich ganz zufrieden mit der Benutzerfreundlichkeit und hat selber nie Probleme damit, eine Aufgabe mit ihrer Applikation zu lösen. Sie beschließt ihre Applikation nochmals selber zu testen, kann aber nach langer Zeit immer noch nicht verstehen, was Charlie mit seinem Feedback genau gemeint hat. iii Auch Dave hat sich diese Applikation heruntergeladen. Nach kurzer Zeit reagiert die App nicht mehr, woraufhin auch er beschließt ein Feedback abzugeben. In seinem Feedback beschreibt er die Stelle an der die App nicht mehr reagiert hat. iv Als Alice das Feedback liest, versucht sie umgehend den Fehler zu finden. Nach einer gewissen Zeit ist Alice sehr frustriert, es gelingt ihr einfach nicht den Fehler zu reproduzieren, obwohl sie die Stelle des Fehlers kennt. Analyse Benutzer haben oft nicht ausreichend Zeit oder Lust, bzw. können sich nicht ausreichend genug mitteilen, damit mit diesem Feedback Fehler gefunden werden können. Charlie beschreibt die Applikation als benutzerunfreundlich, aber gibt nicht genügend Informationen darüber, wo genau seine Probleme liegen. Dave kann zwar die Stelle den Fehlers nennen, weiß aber zu wenig über die internen Strukturen der App, um das Problem genau genug für Alice beschreiben zu können. Alice weiß nicht genau, welche Interaktionen dem Fehler vorangegangen sind, um diesen zu reproduzieren. Alice hat zwar Feedback bekommen und weiß, dass es Probleme gibt, kann diese aber aufgrund mangelnder Informationen nicht beheben. Zusammenfassung Problemszenario 1 beschreibt Probleme von gängigen mobilen Usability-Evaluationen, bei denen versucht wird, Probleme durch Beobachten oder Befragen eines Benutzers zu erkennen. Leider unterliegen mobile Geräte, wie schon in Abschnitt beschrieben, einigen Einschränkungen, so dass das Beobachten von Benutzern, durch die relativ kleinen Displaygrößen der Geräte, erschwert wird. Die Bedienung von mobilen Geräten erfolgt fast ausschließlich durch die Finger der Benutzer, so dass bei der Eingabe das Display zu einem großen Teil verdeckt wird und nicht immer genau mitverfolgt werden kann, mit welchem Objekt der Benutzeroberfläche, Benutzer 5

11 1. Einleitung interagiert haben. Auch der Versuch, Benutzer während der Interaktion mit einer Kamera zu filmen, kann dieses Problem nicht vollständig lösen, denn es schränkt die Benutzer in ihrem Bewegungsraum ein, die dadurch möglicherweise kein natürliches Benutzerverhalten mehr zeigen, so dass die Evaluationsergebnisse verfälscht werden. Zudem sind diese Methoden sehr kostspielig, denn sie benötigen immer anwesende Testbenutzer und Evaluationsexperten sowie oft teure Laboraufbauten. Problemszenario 2 beschreibt Probleme der Remote Usability Evaluation bei Benutzer und Evaluationsexperten räumlich voneinander getrennt sind, so dass keine direkten Befragungen oder Beobachtungen der Benutzers möglich sind. Bei der Remote Usability Evaluation können Benutzer direkt Feedback zu einer App abgeben, welches dann später von einem Evaluationsexperten ausgewertet wird. Allerdings besitzen Benutzer einer App oft nicht genug Wissen über die internen Strukturen der App, um Fehler richtig und genau genug beschreiben zu können. Zudem besitzen sie in der Regel kein ein umfangreiches Wissen über Usability-Richtlinien, so dass sie Usability-Probleme nicht direkt identifizieren und für die Evaluationsexperten beschreiben können. Hinzu kommt, dass Benutzer oft keine Zeit und Lust haben, ein umfangreiches textuelles Feedback zu erstellen. 6

12 2. Grundlagen 2. Grundlagen 2.1. Ausführungskontext von mobilen Applikationen Definition 1 (Ausführungskontext). Der Ausführungskontext beschreibt den gesamten Ablauf sowie Prozess einer Applikation. Dazu zählen interne Abläufe einer Applikation wie z.b. der Activity-Lifecycle, die Sensoren des mobilen Geräts sowie Benutzereingaben durch einfaches Berühren des Displays, durch Gesten und Tastatureingaben. Nach der Erhebung des Ausführungskontexts besteht dieser aus nichts Anderem als rohen Ereignisdaten, die erst durch eine Interpretation Sinn bzw. Nutzen ergeben. Durch die Interpretation des Ausführungskontexts werden Erkenntnisse über die internen Abläufe der Applikation sowie Aufschlüsse über das Benutzerverhalten, sowie die Benutzerintension bei der Interaktion mit einer Applikation erlangt. Nach der Erhebung des Ausführungskontexts besteht dieser aus nichts Anderem als rohen Ereignisdaten, die erst durch eine Interpretation Sinn bzw. Nutzen ergeben. Durch die Interpretation des Ausführungskontexts werden Erkenntnisse über die internen Abläufe der Applikation sowie Aufschlüsse über das Benutzerverhalten, sowie die Benutzerintension bei der Interaktion mit einer Applikation erlangt Monitoring Definition 2 (Monitoring). Unter Monitoring versteht man Beobachtung, Kontrolle oder Überwachung. Zu den Aufgaben des Monitorings gehören das Erfassen sowie das Aufzeichnen des Laufzeitverhaltens von Softwarekomponenten. In dieser Arbeit geht es speziell um das Software-Monitoring zur Laufzeit, dabei werden alle Nutzereingaben sowie das Verhalten der Software beobachtet und protokolliert. Für das Monitoring auf einer unteren Systemebene, wie z.b. für das Plattform- oder Netzwerk-Monitoring existieren bereits gute und ausgereifte Monitoring-Mechanismen. Für das Monitoring von selbst entwickelten Anwendungen sind aber oft eigene Instrumentierungsansätze notwendig, um Systemzustände nachvollziehen zu können [FHRS07]. 7

13 2. Grundlagen Ein einfacher Ansatz wäre hier, den bestehenden Code durch den Monitoring-Code zu erweitern. Dieses führt aber zu verteiltem und redundanten Code, der sich schlecht warten lässt, wodurch zusätzlich die Fehleranfälligkeit des Systems erhöht wird. Es wird also ein Ansatz benötigt, der die zu überwachenden Applikationsteile automatisch und generisch instrumentiert. Objektorientierte Ansätze stoßen hier an ihre Grenzen, da sich sogenannte Crosscutting-Concerns (CCC) nicht bzw. sehr schlecht in eigenen Klassen kapseln lassen [Lah09]. Crosscutting-Concerns sind Anliegen in einem System, die quer zueinander liegen, unabhängig von einander sind und für die es keine Zerlegung in Module gibt, wie es beim Monitoring der Fall ist. Damit gibt es keine Möglichkeit, diese Anliegen in einer hierarchischen Struktur zu gliedern [Lah09]. Eine Lösung für dieses Problem bietet die aspektorientierte Programmierung. Für Java existiert die aspektorientierte Erweiterung AspectJ [FHRS07] AspectJ Die Aspektorientierte Programmierung ist ein Paradigma für die objektorientierte Programmierung. Sie führt Aspekte als syntaktische Strukturen ein und ermöglicht so die Modalisierung von Cross- Cutting Concerns. Durch diese programmierten Aspekte wird ermöglicht, dass Cross- Cutting Concerns in die betroffenen Klassen automatisch eingepflegt werden. Man bezeichnet diesen Prozess auch als Einweben (engl. weave). Es wird in zwei grundsätzliche Klassen des Crosscutting unterschieden, dem dynamischen und dem statischen Crosscutting. Beim dynamischen Crosscutting wird das Verhalten von Objekten modifiziert, so dass zusätzliche Befehle in die Ausführung von Methoden hinzugefügt werden können. Mit dem statischen Crosscutting ist es möglich, die Struktur des Programms selbst zu verändern, um so z.b. die Vererbungshierachie anzupassen [Lah09]. Der für diese Arbeit relevante Teil beschränkt sich allerdings ausschließlich auf das dynamische Crosscutting. So können zusätzliche Aktionen, die zum Monitoring notwendig sind, beim Eintritt oder auch Austritt einer Methode hinzugefügt werden. Hierfür verwendet man sogenannte Interzeptoren, die den Programmfluss unterbrechen. An welcher Stelle einer Methode etwas hinzugefügt wird, kann durch die Interzeptoren before, after und around festgelegt werden. Die Punkte, an denen sich Interzeptoren in ein bestehendes Programm einklinken, werden Joinpoints genannt. Joinpoints können z.b. Methodenausführungen oder Zugriffe auf bestimmte Variablen sein. Über Pointcuts wird definiert, an welchen konkreten Joinpoints Interzeptoren aufgerufen werden sollen. Sie legen fest, welche Joinpoints konkret genutzt werden sollen. Ein Pointcut kann durchaus auch mehrere Joinpoints beinhalten. Ein Pointcut legt zwar fest, welcher Joinpoint genutzt werden soll, aber nicht welcher Interzeptor verwendet wird. Dazu benötigt man das Kontrukt Advice. Ein Advice ist eine Anweisung, die zum Einen festlegt, welche Inzeptoren an den durch einen 8

14 2. Grundlagen Pointcut selektierten Jointpoints in den Programmfluss eingefügt werden und zum Anderen, welcher Code an diesen Stellen ausgeführt werden soll [Lah09]. Folgendes Beispiel soll die Funktionsweise von AspectJ verdeutlichen. Listing 2.1 zeigt eine übliche Android-Activity. Bei jeder Ausführung bzw. bei jeder Berührung des Displays wird die ontouch-methode ausgeführt. Diese gibt, in dem einfach gehaltenen Beispiel, nur die Log-Message ontouch aus. Listing 2.1: MainActivity - MainActivity.java lmtt 1 public class MainActivity extends Activity{ 2 4 public boolean ontouchevent(motionevent event) { 5 Log.i("Info", "ontouch"); 6 return true; 7 } 8 } Listing 2.2 zeigt einen Aspekt mit einem Pointcut und einem Advice. Der Pointcut ontouchcall legt einen konkreten Joinpoint fest. Das Schlüsselwort execution legt fest, dass bei Ausführung der Methode reagiert werden soll. In den Klammern dieses Schlüsselworts wird dann die Methodenkennung angegeben. Diese kann auch Wildcards (z.b. *) im Methodennamen sowie in der Parameterangabe enthalten. Listing 2.2: MonitoringAspect - MonitoringAspect.aj lmtt 1 public aspect MonitoringAspect { 2 3 pointcut ontouchcall() //Pointcut 4 : execution(boolean ontouchevent(motionevent)); 5 6 before() : ontouchcall(){ //Advice 7 Log.i("Info", "AspectJ"); 8 } 9 } Bei jeder Ausführung einer ontouch-methode wird nun zusätzlich der Code des Advices ausgeführt, der die Log-Message AspectJ ausgibt. 9

15 2. Grundlagen 2.3. Usability Usability ist in der DIN EN ISO 9241 wie folgt definiert [DIN]: Definition 3 (Usability). Usability ist das Ausmaß, in dem ein Produkt durch bestimmte Benutzer in einem bestimmten Nutzungskontext genutzt werden kann, um bestimmte Ziele effektiv, effizient und zufriedenstellend zu erreichen. Generell wird Usability als Benutzerfreundlichkeit, Nutzbarkeit, Gebrauchstauglichkeit oder Akzeptanz eines Systems für eine bestimmte Zielgruppe von Benutzern definiert. Die folgenden fünf Usability Attribute sollten immer in einem Software Projekt beachtet werden [Hol05]: Learnability / Erlernbarkeit: Wie schwer ist es für den Benutzer mit der Anwendung zu interagieren um Aufgaben beim erstmaligen Bedienen zu erledigen? Efficiency / Effizienz: Wie gut und schnell kann ein Benutzer eine bestimmte Aufgabe lösen? Memorability / Einprägsamkeit: Wie gut findet sich ein Benutzer zurecht, nachdem er eine Weile nicht mit dem System interagiert hat? Wie schwer fällt es dem Benutzer Kenntnisse über die Benutzung der Anwendung abzurufen? Errors / Fehler: Wie viele Fehler macht ein Benutzer? Wie schwer sind diese Fehler und ist es dem Benutzer möglich nach einem Fehler weiterzuarbeiten? Hiermit sind keine Fehler durch fehlerhaftes Programmieren gemeint, sondern z.b. verwirrende Menüführungen und fehlplazierten Buttons (evtl. auch zu klein). Satisfaction / Zufriedenheit: Wie angenehm ist es für den Benutzer die Anwendung zu bedienen? Usability Evaluation Usability Evaluation bezeichnet das Vorgehen, um z.b. die Usability einer Anwendung sicherzustellen. Dazu werden bestimmte Methoden angewandt, um Usability messbar zu machen [ST02]. Es wird in zwei generellen Usability-Evalutionsmethoden unterschieden: empirische und analytische Methoden. Analytische Methoden versuchen ohne das Vorhandensein eines Benutzers auszukommen. Die Beurteilung findet mit Hilfe von Richtlinien durch Experten statt, welche versuchen sich in die Lage der Nutzer zu versetzen. Holzinger beschreibt die grundsätzlichen analytischen Methoden wie folgt [Hol05]: 10

16 2. Grundlagen Heuristische Evaluation: Experten überprüfen die Benutzeroberfläche nach anerkannten Prinzipien (Heuristiken). Cognitive Walkthrough: Eine Simulation, bei der Schritt für Schritt die Interaktion eines hypothetischen Benutzers mit der Benutzeroberfläche durchgeführt wird. Empirische Methoden dagegen arbeiten eng mit dem Benutzer zusammen. Hier werden Informationen durch Befragungen und Beobachtungen richtiger Benutzer gewonnen. Oft können nur richtige Benutzer wirklich Auskunft darüber geben, wie Benutzer mit dem System interagieren und wo die genauen Probleme liegen [Hol05]: Lautes Denken: Benutzer sollen, während sie bestimmte Aktionen mit dem System ausführen, laut sprechen und mitteilen was und wie sie etwas machen. Feldbeobachtung: Beobachtung von Benutzern während sie mit dem System interagieren. Fragebögen: Benutzer geben mit Hilfe von Fragebögen ihr subjektives Feedback zum System ab Remote Usability Evaluation Alle im Abschnitt beschriebenen Methoden benötigen Evaluationsexperten, die Benutzer simulieren oder direkt mit Benutzern interagieren, um die gewünschten Informationen zu erhalten. Wünschenswert wäre es, wenn man die Informationen auch ohne direkten Kontakt mit dem Benutzer erhalten könnte. Remote Usability Evaluation beschäftigt sich genau mit dieser Idee, dass Benutzer und Evaluationsexperte räumlich voneinander getrennt sind. So wird es möglich, detaillierte Information über das Benutzerverhalten in einer realen Umgebung zu erhalten. Darüber hinaus trägt die Tatsache, dass Benutzer die Durchführung der Evaluation in einer natürlichen Umgebung tätigen, dazu bei, dass bessere Informationen über das natürliche Benutzerverhalten gewonnen werden können [PRS07]. Um ein vollständiges Bild über die Usability einer Applikation zu erhalten, um daraus Rückschlüsse auf die Benutzerfreundlichkeit zu ziehen, reicht es nicht aus nur zu protokollieren wie ein Benutzer mit der Applikation interagiert hat, man muss auch die Kontextinformationen analysieren, die den Benutzer beeinflusst haben könnten. Wenn diese Informationen nicht vollständig vorhanden sind, könnten falsche Schlüsse über die Benutzerfreundlichkeit der Anwendung gezogen werden [PRS07]. Es gibt zwei grundsätzliche Kategorien von Remote-Evaluationsmethoden: synchrone und aysnchrone. Bei der synchronen Methode ist der Evaluationsexperte vom 11

17 2. Grundlagen Benutzer räumlich, aber nicht zeitlich, getrennt. Bei der asynchronen Methode ist der Evaluator sowohl zeitlich als auch räumlich getrennt [ANSS07]. In dieser Arbeit wird ausschließlich die asynchrone Methode benutzt. Ein Benutzer kann zu jeder Zeit ein Feedback für die Evaluation abgeben. Der Evaluationsexperte kann sich dieses Feedback zu einem beliebigen späteren Zeitpunkt ansehen Mobile Usability Mobile Usability ist ein aufstrebendes Forschungsgebiet, da es eine Vielzahl von Herausforderungen, aufgrund der einzigartigen Eigenschaften von mobilen Geräten, zu lösen gilt. Traditionelle Richtlinien können nicht direkt bei mobilen Anwendungen genutzt werden. Zhang und Adipat beschreiben die folgenden speziellen Eigenschaften von mobilen Geräten [ZA05]: Umgebung: Nutzer können durch ihre unmittelbare Umgebung beeinflusst (gestört) werden, wie z.b. Lärm, andere Personen oder Umgebungsobjekte, die die Aufmerksamkeit des Benutzers auf sich ziehen. Internet: Mobile Geräte besitzen, in einigen Regionen, eine langsame und nicht immer verfügbare Internetverbindung. Kleine Displaygröße: Die begrenzte Bildschirmgröße kann sich erheblich auf die Benutzerfreundlichkeit von mobilen Anwendungen auswirken. Unterschiedliche Displaygrößen: Es gibt viele unterschiedliche mobile Geräte auf dem Markt, die sich in der Displaygröße drastisch unterscheiden. Daher können die Usability-Testergebnisse stark variieren. Begrenzter Speicher und begrenzte Prozessorleistung: Die Leistung und Speicherkapazität von mobilen Geräten hängt weit hinter der von Desktop- Computern. Daher können einige Anwendungen nicht optimal auf mobilen Geräten umgesetzt werden. Eingabemethoden Kleine Displays, virtuelle Eingabemethoden, Lichteinstrahlung oder auch der Benutzerstatus (Sitzen, Gehen, Laufen etc.) können die Dateneingabe erschweren Usability Activities Usability-Evaluation selbst ist ein Prozess der viele Aktivitäten beinhaltet. Es wird dabei meist in drei große Aktivitäten unterschieden, die während einer Evaluation durchlaufen werden [IH01]: Datenerfassung: Erfassen und Speichern von Daten. 12

18 2. Grundlagen Datenanalyse: Interpretieren der Daten um Usability Probleme des Interfaces zu entdecken. Datenauswertung: Kritik und/oder Lösungen aufgrund der analysierten Daten Contexter Der ConTexter wurde an der Leibniz Universität Hannover vom Fachgebiet Software Engineering entwickelt, damit Benutzer, mit einer einfachen mobilen Anwendung vom Smartphone aus, Feedback über Probleme und Fehler abgeben können. Der ConTexter zeichnet Kontextinformationen des Benutzers auf, wie z.b. GPS-Daten, wodurch eingehende Feedbacks automatisch sortiert und ausgewertet werden können. Ein Feedback kann so direkt einer bestimmten Entität zugeordnet werden. Eine Entität ist beim ConTexter definiert als ein Konzept der Anwendungsdomäne, das vom Anbieter bzw. vom Domänenexperten eingerichtet wird, um Feedbacks über diese Entität erhalten zu können. Entitäten werden durch ortsbezogene Daten wie z.b. GPS oder WLAN identifiziert, so dass einem Benutzer beim Abgeben eines Feedbacks, eine Liste von passenden Entitäten angezeigt werden kann. Benutzer müssen deshalb nicht alle Entitäten kennen und identifizieren können. Das ConTexter Feedback System besteht aus dem ConTexter Server System und einer mobilen Android-Anwendung. Abbildung 2.1 zeigt die verschiedenen Interessengruppen die im ConTexter Feedback System zusammenspielen [WGS12]. Abbildung 2.1.: Interessensgruppen des ConTexter Feedback System [WGS12] Der Ablauf zum Abgeben eines Feedback innerhalb der Smartphone Applikation wird in Abbildung 2.2 dargestellt [WGS12]. Zunächst kann die Art des Feedbacks gewählt werden, anschließend werden die durch Kontextdaten ermittelten Entitäten 13

19 2. Grundlagen zur Auswahl angezeigt. Nachdem eine Entität ausgewählt wurde, kann ein Feedback zu dieser Entität abgegeben werden. Abbildung 2.2.: ConTexter Applikation [WGS12] 2.5. Android Grundlagen In diesem Abschnitt werden die nötigen Android Grundlagen erläutert, um die beschriebenen Konzepte dieser Arbeit verstehen zu können Activity Eine Activity repräsentiert eine sichtbare Benutzeroberfläche. Sie kann Buttons, Eingabefelder und sonstige Benutzeroberflächen-Objekte enthalten. Sie kapselt die Anwendungslogik, welche festlegt, wie z.b. auf die Interaktionen eines Benutzes mit der Benutezroberfläche reagiert werden soll. In der Regel wird für jede neue Bildschirmseite, auch eine neue Activity angelegt Activity-Lebenszyklus Als Lebenszyklus (engl. Lifecycle) bezeichnet man die Zustandswechsel einer Activity von ihrer Erzeugung bis zu ihrer Beendigung. Activities werden im System als Stack (dt. Stapel) verwaltet. Wenn eine neue Activity gestartet wird (1), wird sie oben auf dem Stack platziert und wird zur ausführenden Activity. Die vorherigen Activities verbleiben auf dem Stack und werden nicht wieder aktiv, bis die neue Activity beendet wird. Im Wesentlichen kann eine Activity vier verschiedene Zustände annehmen [AA14]: Wenn eine Activity im Vordergrund des Bildschirms ist, dann ist sie aktiv (2). Wenn eine Activity den Fokus verloren hat, aber immer noch sichtbar ist, wird sie pausiert (3). 14

20 2. Grundlagen Abbildung 2.3.: Activity-Lebenszyklus [AA14] Wenn eine Activity vollständig von einer anderen Activity verdeckt wird, wird sie angehalten (4). Nachdem eine Activity angehalten wurde, kann sie zerstört (engl. destroyed) werden. Dieses kann gewollt vom Benutzer geschehen (5) oder auch vom System (6), wenn Apps mit einer höheren Priorität den Speicher der Activity benötigen. Wenn nun die Activity dem Benutzer wieder angezeigt werden soll, muss die Activity vollständig neu gestartet und in den vorherigen Zustand versetzt werden Gesten Definition 4 (Geste). Gesten sind intuitive Bewegungen, die von einem Benutzer mit einem oder zwei Fingern auf dem Bildschirm ausführt werden. Im Folgenden werden einige Standardgesten erläutert, die auch im Verlauf der weiteren Arbeit zur Sprache kommen. 15

21 2. Grundlagen Tap Der Tap ist eine einfache Berührung des Bildschirms, ohne das sich die Position des Fingers, während der Berührung, verändert. Abbildung 2.4.: Tap [Wro10] Double Tap Analog zum Doppelklick im Desktop-Bereich, existiert der Double Tap, bei dem zwei Taps schnell hintereinander folgen. Abbildung 2.5.: Double Tap [Wro10] Swipe Der Swipe ist eine schnelle Wischenbewegung, die oft zur Navigation innerhalb von Apps verwendet wird. Abbildung 2.6.: Swipe [Wro10] 16

22 2. Grundlagen Drag Bei einem Drag wird ein Objekt auf dem Bildschirm berührt und eine Bewegung ausgeführt, ohne dass die Berührung beendet wird. Abbildung 2.7.: Drag [Wro10] Pinch Bei einem Pinch werden zwei Finger aufeinander zu bewegt. Ein Pinch wird meistens benutzt, um die Größe eines Elements zu verkleinern (rauszoomen). Abbildung 2.8.: Pinch [Wro10] Spread Bei einem Spread werden zwei Finger voneinander weg bewegt. Ein Spread wird meistens benutzt, um die Größe eines Elements zu vergrößern (reinzoomen). Abbildung 2.9.: Spread [Wro10] 17

23 3. RUES - Remote Usability Evaluation System 3. RUES - Remote Usability Evaluation System In dieser Arbeit wurde ein Konzept entwickelt und dieses als Remote Usability Evaluation System mit dem Namen RUES umgesetzt. Um die Durchführbarkeit des Konzepts zu demonstrieren, wurde eine applikationsunabhängige prototypische Implementierung für Android entwickelt. Wie der Name des Konzepts schon verraten lässt, wird eine Remote Usability Evaluation durchgeführt, das heißt, dass die Benutzer und die Evaluationsexperten räumlich voneinander getrennt sind. RUES durchläuft, wie übliche Usability-Evaluationen, drei Phasen (siehe Abschnitt 2.3.4). Abbildung 3.1.: Phasen von RUES Folgendes Szenario soll die Funktion von RUES verdeutlichen: 1. Ein Benutzer macht eine Entdeckung oder stellt ein Problem fest und möchte ein Feedback abgeben. Alle Interaktionen die ein Benutzer mit der App gemacht hat, werden erfasst und gespeichert. Bei der Feedbackabgabe werden alle erfassten Daten zusammen mit dem Feedback an eine Serveranwendung verschickt (Datenerfassung). 2. Die Serveranwendung empfängt das Feedback mit allen während der Datenerfassungsphase gesammelten Daten und analysiert diese Daten auf Fehler und Usability-Probleme. Die Ergebnisse dieser Analyse können statistische Werte, Visualisierungen der Interaktion mit der Benutzeroberfläche, Aufgaben die ein Benutzer erreicht bzw. versucht hat zu erreichen sowie ggf. Probleme die aufgetreten sind, sein (Datenanalyse). 3. Evaluationsexperten und Entwickler können dann mit Hilfe der analysierten Daten, Usability-Probleme der App identifizieren und beheben. Zusätzlich können diese Daten auch genutzt werden, um Programmierfehler der App zu finden (Datenauswertung). In den folgenden drei Abschnitten werden die Konzepte der drei Phasen Datenerfassung, Datenanalyse sowie Datenauswertung beschrieben. 18

24 3. RUES - Remote Usability Evaluation System 3.1. Datenerfassung Während der Erfassungsphase müssen alle notwendigen Daten erfasst werden, um den Ausführungskontext vollständig erheben zu können, damit dieser in der Analyse- Phase gut interpretiert werden kann, um so mögliche Usability-Probleme der Host- Applikation zu erkennen. Es reicht nicht aus nur Daten aus der Interaktion des Benutzers mit der Benutzeroberfläche zu monitoren, wie z.b. Berührungpunkte (engl. Touchpoints) oder Gesten, sondern es müssen auch Hardware-Sensoren wie dem Beschleunigungssensor und dem GPS-Sensor des mobilen Geräts abgefragt werden. Zusätzlich muss der vollständige Lifecycle einer Android-Activity erfasst werden Android-Monitoring Es gibt verschiedene Ansätze, Monitoring unter Android zu betreiben. Ein möglicher Ansatz zum Monitoring unter Android wird in [GNAM13] beschrieben. Wenn Benutzer mit einer Android-App interagieren, generieren die Android-Sensoren Ereignisse und senden diese zum Systemkernel (dev/input/event*). Solche Ereignisse bestehen aus fünf Feldern mit folgendem Format: timestamp: device: type code value Der Timestamp ist die Zeit zum letzten Systemneustart, device bezeichnet den Namen des Geräts, dass das Ereignis erzeugt hat und die restlichen drei Felder hängen vom spezifischen Ereignis ab. Ein Ereignis könnte z.b. so aussehen [GNAM13]: : /dev/input/event4: f Der Timestamp besagt, dass seit dem letzten Systemneustart 50 Sekunden und 617,652 Mikrosekunden verstrichen sind. Das Eingabegerät ist event4, welches z.b. für eine Berührung mit der Benutzeroberfläche stehen könnte bedeutet, dass es sich um die x-position des Ereignisses handelt und f (hex) entspricht 287 (dezimal), der Koordinate des x-wertes. Wie man unschwer erkennen kann, bietet so ein Ereignis nicht genügend viele Informationen, um z.b. eine Geste wiederherzustellen. Eine einfache Berührung mit der Benutzeroberfläche erzeugt rund 18 Ereignisse und eine Swipe-Geste rund 50 Ereignisse. Abbildung 3.2 zeigt die Ereignisliste einer Swipe-Geste [GNAM13]: Aufgrund der hohen Anzahl von Ereignissen entstehen allerdings einige Probleme, da die Daten zur Auswertung zusammen mit dem Feedback an einen Server geschickt werden müssen. In der Regel ist die Bandbreite eines mobilen Geräts beschränkt und in einigen Regionen sehr unzuverlässig, so dass die Übertragung zum Teil sehr lange dauern kann. Eine Idee ist, die Daten schon auf dem Gerät zu analysieren und so aus den 50 Einzelereignissen, eine Swipe-Geste zu abstrahieren. Allerdings 19

25 3. RUES - Remote Usability Evaluation System Abbildung 3.2.: Swipe-Ereignisliste [GNAM13] erfordert dieser Prozess eine intensive Rechenarbeit, was zu Performance verlusten der Host-Applikation führen kann. Zudem können mit diesem Ansatz einige Konzepte zur Datenanalyse von RUES nicht umgesetzt werden, da nicht alle benötigten Informationen erfasst werden können, wie z.b. die Bezeichnung und Größe von Oberflächen-Objekten, die zur Use-Case Erkennung oder auch zur Überprüfung der Android-Guidelines benötigt werden. Daher wird ein Ansatz benötigt, der Ereignisse auf einer höheren Abstraktionsebene erfasst. Seit der Android-SDK-Version 4.0 sind die Sicherheitsvorkehrungen extrem erhöht worden, so dass kein Zugriff von außen erfolgen kann, bspw. durch eine andere App. Deshalb bleibt nur die Möglichkeit, den Quellcode der Host-Applikation so zu manipulieren, dass die gewünschten Ereignisse herausgefiltert werden können. Ein einfacher Ansatz wäre das manuelle Instrumentieren von Monitoring-Code, welches aber zu verstreuten und redundanten Quellcode der Host-Applikation führt. Hinzu kommt, dass die Wartbarkeit verschlechtert und die Fehleranfälligkeit erhöht wird, weil Systeme üblicherweise häufigen Änderungen unterliegen [FHRS07]. Wie bereits im Abschnitt 2.2 beschrieben, ermöglicht die aspektorientierte Programmierung (AOP) ein automatisiertes Integrieren in den Applikationscode. Abbildung 3.3 zeigt den Build-Prozess eines Android-Projekts in eine Android- Anwendung (.apk). Zunächst wird der Quellcode eines Android-Projekts in.class- Dateien kompiliert (1) und anschließend in Dalvik Bytecode (.dex) konvertiert (2). Aus Dalvik Bytecode generiert der apkbuilder ein Android-Paket (.apk) (3), welches dann auf einem mobilen Gerät ausführbar ist. 20

26 3. RUES - Remote Usability Evaluation System Abbildung 3.3.: Android Build-Prozess (in Anlehnung an [BR14]) Der AspectJ Builder (4) setzt zwischen dem Kompilieren des Quellcodes in Java Bytecode (1) und dem Konvertieren in Dalvik Bytecode (2) an und webt die Aspekte in den Java Bytecode ein. Damit ist es möglich, Android-Quellcode um Monitoring- Quellcode zu erweitern, ohne den Quellcode der Host-Applikation selbst verändern zu müssen. Zudem ist es mit diesem Ansatz möglich, alle benötigten Daten zur Analyse zu erfassen Datenanalyse In der Analyse-Phase wird der, in der Datenerfassungs-Phase, erhobene Ausführungskontext interpretiert. Die Analyse wird zum größten Teil automatisch durchgeführt. Am Ende der Analyse-Phase wird ein Bericht erzeugt, der Informationen zu Usability-Problemen enthält. Der Bericht wird von Evaluatoren und Entwicklern der Host-Applikation ausgewertet und Lösungsansätze erstellt. Es gibt eine Reihe 21

27 3. RUES - Remote Usability Evaluation System von Möglichkeiten, den Ausführungskontext auf Usability-Probleme und Fehler zu untersuchen. Hierfür wurden einige Konzepte entwickelt, auf die in den folgenden Abschnitten eingegangen wird Berührpunkt-Interpretation Bei der Berührpunkt-Interpretation geht es vor allem darum, Berührpunkte (engl. touchpoints) des Benutzers mit der Benutzeroberfläche aufzuspüren, welche keine direkte Funktion in der Host-Applikation auslösen. Dieses deutet daraufhin, dass z.b. ein Benutzeroberflächen-Objekt zu klein ist oder es den Anschein erweckt haben könnte, dass es berührbar ist bzw. eine Funktion erfüllt. Um solche Berührpunkte aufzuspüren ist es notwendig, jeden Berührpunkt des Benutzers aufzuzeichnen. Zu jedem Berührpunkt muss zusätzlich noch der Zeitstempel des Auftretens gespeichert werden. Anhand des Zeitstempels können dann Berührpunkte, Ereignissen, die sie ausgelöst haben, zugeordnet werden. Ein Ereignis wird z.b. erzeugt, wenn ein Benutzer mit einem Benutzerflächen-Objekt, wie z.b. einem Button oder einer Checkbox interagiert. Berührpunkte, welche nicht zugeordnet werden können, werden als Fehler interpretiert. Abbildung 3.4.: Beispiel Activity mit zwei Berührpunkten Abbildung 3.4 zeigt eine Android-Activity zur Speicherung einer Notiz mit zwei eingezeichneten Berührpunkten. Berührpunkt 1 hat offensichtlich sein Ziel, den Button zum Speichern einer Notiz, verfehlt. Berührpunkt 2 hat den Button dagegen getroffen. 22

28 3. RUES - Remote Usability Evaluation System Abbildung 3.5.: Aufgezeichnete Daten Wie man in den aufgezeichneten Daten in Abbildung 3.5 sieht, kann Berührpunkt 2 eindeutig, wegen seiner unmittelbaren zeitlichen Nähe, dem Benutzeroberflächen- Ereignis (engl. user interface event) zugeordnet werden. Berührpunkt 1 kann als Fehler interpretiert werden, weil zwischen den beiden Berührpunkten keine weiteren Ereignisse aufgezeichnet wurden. Natürlich gibt auch einige Ausnahmen, wie z.b. bei Gesten, wie dem Double Tap, bei dem zwei Berührpunkte direkt hintereinander folgen. In so einem Fall wird kein Fehler interpretiert. Eine weitere Aufgabe der Berührpunkt-Interpretation ist es, den Fehlern ein mögliches Ziel zuzuordnen. Im obigen Beispiel wäre es der Button mit der ID savenotebutton für den Berührpunkt 1 (siehe Abbildung 3.5). Zunächst wird überprüft, welches Benutzeroberflächen-Objekt als nächstes berührt wurde, denn wenn ein Ziel verfehlt wurde, wird der User in den meisten Fällen nochmal versuchen, das Ziel zu treffen. Zudem wird die räumliche Distanz zu naheliegenden Benutzeroberflächen-Objekten berechnet. Ist das Benutzeroberflächen-Objekt dabei, welches als nächstes berührt wurde, kann eine eindeutige Zuordnung stattfinden, ist es nicht dabei, wird der Berührpunkt dem nächstgelegenen Benutzeroberflächen-Objekt zugeordnet. Der gesamte Prozess der Berührpunkt-Interpretation wird in Abbildung 3.6 dargestellt. Abbildung 3.6.: Berührpunkt-Interpretations Prozess Eine Berührung mit der Benutzeroberfläche, die ihr Ziel verfehlt, kann jedem und überall passieren, was bedeutet, dass nicht jede Berührung, welche keine Funktion in 23

29 3. RUES - Remote Usability Evaluation System der Host-Applikation ausgelöst, ein Usability-Problem als Ursache hat. Deshalb müssen Fehler statistisch erfasst werden und erst wenn eine bestimmte Schwelle (Anzahl von Fehlern) überschritten wurde, darf ein Usability-Problem gemeldet werden Gesten-Interpretation Dieser Abschnitt beschäftigt sich mit der Erkennung von Stroke Gestures (Touchscreen- Gesten), die ein Benutzer in der Interaktion mit der Host-Applikation benutzt hat. Stroke Gestures sind Gesten, die vom Benutzer mit einem oder mit zwei Fingern ausgeführt werden, wie z.b. Pinch, Swipe, Drag, Spread oder Double Tap. Von einer informationstheoretischen Sicht sind Stroke Gestures zweidimensionale geometrische Signale vom Benutzer zum Computer, die Text oder Befehle (Nachrichten) kodieren. Übertragen wird eine Geste durch einen Kanal mit Rauschen (engl. noise), aufgrund von Ungenauigkeiten in der Ausübung einer Geste. Die verrauschte Geste wird dann vom Computer empfangen und von einem Recognizer (dt. Erkenner) in die Nachricht dekodiert, die vom Benutzer beabsichtigt wurde. Abbildung 3.7.: Stroke-Gesture Erkennungsprozess [ZKAA+12] Abbildung 3.7 zeigt den Prozess der Gestenerkennung [ZKAA+12]. Gestenerkennung in RUES dient vor allem dem Zweck, Gesten eines Benutzers zu erkennen, die von der Host-Applikation nicht akzeptiert wurden. Nicht erkannte Gesten können ein Indiz für ein Usability-Problem der Applikation sein. Die Host-Applikation könnte z.b. den Eindruck erweckt haben, dass an dieser Stelle eine bestimmte Geste anwendbar ist. Wie bei der Touchpoint-Interpretation müssen statistische Werte erfasst werden, sodass ein Usability-Problem erst gemeldet wird, wenn mehrere Benutzer versucht haben an der gleichen Stelle eine Geste auszuführen, die nicht möglich ist. Bei der Gestenerkennung muss zunächst festgestellt werden, ob eine Geste von Host- Applikation erkannt wurde. Die beiden folgenden Ansätze sind denkbar: 24

30 3. RUES - Remote Usability Evaluation System Überprüfung von Methoden: Android bietet grundsätzlich nur zwei Methoden an, welche es ermöglichen, Gesten zu erkennen. Zum Einen die ontouch- Methode und zum Anderen die ontouchview-methode. Ist keine dieser beiden Methoden in der Activity, in der die Geste ausgeführt wurde, implementiert, können auch keine Gesten erkannt werden. Betrachtung der aufgezeichneten Ereignisliste: Folgt in der aufgezeichneten Ereignisliste eine Reaktion der Host-Applikation auf eine Geste, wie z.b. das Wechseln zu einer anderen Activity, dann wurde die Geste von der Host- Applikation erkannt. Zusätzlich muss noch erkannt werden, was für eine Geste ausgeführt wurde. Die Erkennung einer Geste ist aber nicht trivial, denn bis auf ein paar Standard-Gesten wie z.b. dem Double Tap, muss der Entwickler einer Applikation sich selbst um die Erkennung von Gesten kümmern. Die Definition, wie diese Gesten auszusehen haben, ist zwar gegeben, aber die Implementierung der Erkennung von Gesten (Recognizer), kann von App zu App abweichen, was dazu führt, dass keine einheitliche Implementierung von Gesten existiert. Zudem kann jeder Entwickler auch neue Gesten erstellen und in seiner Applikation verfügbar machen. Es wird also ein einheitliches Erkennungssystem für Gesten benötigt, welches es erlaubt, Gesten zu lernen, um z.b. folgende Aussage treffen zu können: Die Geste wurde nicht erkannt, aber fünf Benutzer haben an dieser Stelle die gleiche oder eine ähnliche Geste versucht anzuwenden. Es ist also nicht relevant, dass die genaue Bezeichnung einer nicht erkannten Geste bekannt ist, aber dass eine Geste schon von mehreren Benutzern genau in dieser Activity angewendet wurde. Für den Evaluator muss die Geste aber noch visualisiert werden, damit dieser erkennen kann, welche Geste von den Benutzern ausgeführt wurde. Abbildung 3.8.: Beispielhafte Visualisierung einer individuellen Stroke-Gesture Abbildung 3.8 zeigt eine beispielhafte Visualisierung einer individuellen Geste. Der Prozess der Gestenerkennung wird noch einmal in Abbildung 3.9 veranschaulicht. Wurde eine Geste von der Host-Applikation erkannt, wird nichts weiter un- 25

31 3. RUES - Remote Usability Evaluation System Abbildung 3.9.: Gesten-Interpretations Prozess ternommen. Wurde sie von Host-Applikation nicht erkannt, versucht die Gesten- Interpretation sie zu erkennen, indem sie mit anderen Gesten verglichen wird. Anschließend findet eine statitische Auswertung statt, in der analysiert wird, wie oft diese Geste an genau dieser Stelle in der Host-Applikation, schon ausgeführt wurde. Wurde sie schon öfter an dieser Stelle ausgeführt und ist die Schwelle für nicht erkannte Gesten an dieser Stelle überschritten, wird ein Usability-Problem der Host- Applikation gemeldet Android Benutzeroberflächen-Richtlinien Dieser Abschnitt beschäftigt sich mit der Überprüfung der Android-Benutzeroberflächen- Richtlinien. Diese Richtlinien sind Design-Vorgaben von Google an die Entwickler, um die Usability sowie die Benutzerzufriedenheit, bei der Benutzung einer App, zu verbessern. Diese Vorgaben gliedern sich in folgende Kategorien [GO14]: Devices and Display: Flexible Gestaltung der Inhaltsgrößen aufgrund von unterschiedlichen Bildschirmgrößen. Themes: Verwenden von Themen um einer App einen einheitlichen Stil zu verleihen. Touch Feedback: Rückmeldung vom System an den Benutzer der Interaktion mit der App wie z.b. das Ändern von Farben oder ein haptisches Feedback (leichtes vibrieren). Typography: Wahl der Schrittgröße, Schriftart, Zeilenabstand etc. 26

32 3. RUES - Remote Usability Evaluation System Color: Optimale Farbwahl. Iconography: Regeln zum Icon-Entwurf. Your Branding: Richtlinien um eine App individuell zu gestalten, um diese von anderen Apps abzugrenzen. Writing Style: Regeln zum Schreibstil, welche in der App eingehalten werden sollte. Metrics and Grids: Größe und Distanz zwischen Benutzeroberflächen-Objekten. Alle diese Richtlinien sollten beachtet und so gut wie möglich von den Entwicklern umgesetzt werden. Allerdings sind viele dieser von Google empfohlenen Vorgaben schwer mit maschinellen Regeln zu überprüfen, deshalb beschränkt sich die Überprüfung in dieser Arbeit auf die Größe und Distanz zwischen Benutzeroberflächen- Objekten. Größe und Distanz zwischen Benutzeroberflächen-Objekten Dieser Abschnitt befasst sich mit den von Maschinen überprüfbaren Regeln. Zum Einen wird die Größe und zum Anderen die Distanz zwischen der Benutzeroberflächen- Objekten untersucht. Ist die Größe eines Benutzeroberflächen-Objekten zu gering oder der Abstand zwischen zwei der Benutzeroberflächen-Objekten zu klein, kann dieses zur Folge haben, dass Benutzer ihr Ziel bei einer Berührung verfehlen, was zu einer schlechten Benutzererfahrung führen kann. Deshalb ist es wichtig diese Regeln einzuhalten. Abbildung 3.10.: Größe und Distanz zwischen Benutzeroberflächen-Objekten Die Größe von berührbaren Benutzeroberflächen-Objekten sollte mindestens 48dp und die Distanz zwischen ihnen sollte mindestens 8dp betragen. dp sind von der Pixeldichte unabhängige Bildpunkte. 160dp sind immer genau 1 Zoll auf jedem Bildschirm, daher ist diese Maßeinheit geräteunabhängig und eignet sich aufgrund 27

33 3. RUES - Remote Usability Evaluation System der vielen auf dem Markt vorhandenen Android-Geräte mit unterschiedlichen Bildschirmgrößen sehr gut [Bac12]. Im Durchschnitt sind 48dp mit 9mm zu einer physikalischen Größe zu übersetzen. Von daher kann immer garantiert werden, dass die UI-Elemente im Rahmen der Vorgabe für Zielgrößen (7-10mm) liegen. Abbildung 3.11.: Überprüfung der Größe und Distanz zwischen Benutzeroberflächen-Elementen Abbildung 3.11 zeigt das exemplarische Vorgehen. Zunächst muss die Größe, in Pixeln, für alle Benutzeroberflächen-Objekte berechnet werden. Nun kann mit Hilfe der Host-Applikation, die Größe in das geräteunabhängige Format dp umgerechnet werden. Wird bei einem Benutzeroberflächen-Objekt festgestellt, dass es kleiner als 48dp ist, wird ein Usability-Problem gemeldet. Nebenläufig kann die Distanz von jedem Benutzeroberflächen-Objekt zu allen anderen, in einer Activity befindlichen, Benutzeroberflächen-Objekten berechnet werden. Ist die Distanz zwischen zwei Objekten kleiner als 8dp, wird ein Usability-Problem gemeldet Benutzeraktivitätserkennung Dieser Abschnitt beschäftigt sich mit der Erkennung der physischen Benutzeraktivität, unmittelbar vor der Feedbackabgabe. Physische Benutzeraktivitäten können beispielsweise Gehen, Laufen, Fahrrad- oder Autofahren sein. Aktivitätserkennung 28

34 3. RUES - Remote Usability Evaluation System wird bereits von vielen Applikationen genutzt, um z.b. auf eine erkannte Benutzeraktivität mit einem veränderten Inhalt zu reagieren. Die App passt sich also der Situation des Benutzers an, was oft zu einer verbesserten Usability und einer besseren Benutzerzufriedenheit führt. Die Aktivitätserkennung ist für die Arbeit aber aus anderen Gesichtspunkten interessant. So kann der Kontext eines Benutzers besser interpretiert werden, z.b. bei der Benutzung einer Sportstracker-App. Eine Sportstracker-App erfasst GPS-Daten, zählt Schritte und misst die Herzfrequenz eines Benutzers, während er eine sportliche Aktivität ausübt. Hier kann es interessant sein zu erfahren, welche Aktivität der Benutzer gerade ausgeübt hat, ob er gejoggt ist oder gerade still stand, als ein Problem vom Benutzer festgestellt wurde. Evaluationsexperten können so analysieren, ob ein Benutzer bei der Erreichung eines bestimmten Use-Cases Probleme hatte, weil er eine bestimmte Aktivität ausgeübt hat. Ein Use-Case in diesem Beispiel könnte z.b. das Ändern von Einstellungen der Host-Applikation sein. So kann festgestellt werden, ob einige Use-Cases bei der Ausübung einer bestimmten Aktivität nicht optimal sind. Die Softwareentwickler können dann mit dieser Erkenntnis ihre App anpassen und beispielsweise Umstrukturierungen vornehmen oder wie oben schon beschrieben, selbst eine Erkennung der Benutzeraktivität vornehmen, um auf eine erkannte Aktivität zu reagieren. Beispielsweise könnte man Buttons vergrößern oder Inhalte, welche während der Ausübung einer bestimmten Aktivität uninteressant sind, entfernen. Benutzeraktivitätserkennung ist eine anspruchsvolle Aufgabe für kontextbezogene Systeme und Anwendungen. Die meisten Techniken aus diesem Forschungsgebiet basieren auf dem maschinellen Lernen von Sensordaten [RB10]. In heutigen Mobiltelefonen befindet sich neben den Sensoren zum Messen von Temperatur, Licht, Schwerkraft, und GPS-Koordinaten, ein 3-Achsen-Beschleunigungssensor (x-, y- und z-achse) [WN11]. Der Beschleunigungssensor kann, wie bereits andere Projekte gezeigt haben, beispielsweise zur Gangerkennung [NDBB11] oder auch zur Fallerkennung von Patienten genutzt werden [ST09]. Abbildung 3.12 zeigt den Prozess der Aktivitätserkennung. Zunächst müssen die Sensordaten von einem Beschleunigungssensor erfasst werden. Ein Datensatz von einem Beschleungingssensor besteht aus einem x-, y- und z-wert. Damit eine Klassifikation mit Hilfe dieser erfassten Daten geschehen kann, müssen aber zuerst Merkmale erstellt bzw. berechnet werden. Diese Merkmale sind Werte, die hauptsächlich zum Gebiet der Statistik gehören. In [KWM10] werden diese Merkmale wie folgt beschrieben: Standardabweichung (STD): Für alle Achsen getrennt ST D = s = 1 n (a i ā) n 2 i=1 29

35 3. RUES - Remote Usability Evaluation System Abbildung 3.12.: Prozess der Aktivitätserkennung Durchschnittliche absolute Differenz (AAD): Für alle Achsen getrennt AAD = ā = 1 n a i ā n i=1 Durchschnittliche resultierende Beschleunigung: ARA = 1 n n i=1 x 2 i + y2 i + z2 i Mittelwert (AVG): Für alle Achsen getrennt (a x,y,z) AV G = ā = 1 n a i n i=1 Mit Hilfe dieser Werte kann nun eine Klassifizierung von Aktivitäten vorgenommen werden. Dazu müssen Trainingsdatensätze erstellt werden, die das System lernt. Die Trainingsdatensätze bestehen aus den oben genannten Merkmalen und dem Klassenattribut. Das Klassenattribut, nach welchem klassifiziert werden soll, ist die 30

36 3. RUES - Remote Usability Evaluation System physische Benutzeraktivität. Ziel der Klassifizierung ist es nun ein Modell für das Klassenattribut zu finden, womit die Klassifizierung von ungesehenen Testdatensätzen (Klassenattribut unbekannt) vorgenommen werden kann. Zum Erstellen dieses Modells existieren unterschiedliche Algorithmen. Einige Algorithmen basieren auf der Erstellung von Bäumen, andere auf dem Erstellen von Regeln. Für die Validierung dieses Modells werden Testdatensätze erstellt, bei denen das Klassenattribut nicht angegeben wird, aber es bekannt ist. Es wird nun mit Hilfe des durch die Trainingsdaten erstellten Modells versucht, dass Klassenattribut zu finden. Anschließend wird überprüft, wie viele Testdatensätze richtig klassifiziert wurden. Abbildung 3.13 zeigt dieses Verfahren. Abbildung 3.13.: Klassifikation: Modellerstellung [TSK05] Für die Erstellung von Trainings- und Testdatensätze werden mehrere Personen benötigt, ansonsten könnte eine Überanpassung (engl. overfitting) die Folge sein, was bedeutet, dass das Erkennungssystem zu spezifisch für eine Person reagiert. Das System kann dann zwar Datensätze einer Person gut klassifizieren, allerdings wird es keine guten Ergebnisse bei anderen Personen liefern. Es spielen aber auch noch einige andere Faktoren bei der Erstellung des Modells eine Rolle, welche Einfluss auf die Erkennungsrate haben: Wahl des Klassifizierungsalgorithmus (REPTree, J48, NaiveBayes etc.) Erfassungsrate, mit der Beschleunigungssensordaten erfasst werden (z.b. 100Hz, 200Hz) 31

37 3. RUES - Remote Usability Evaluation System Dauer der Erfassung von Daten (10s, 20s, 30s, 1m,..) Die große Herausforderung der Klassifizierung ist das Finden der optimalen Faktoren, die zufriedenstellende Ergebnisse liefern. Meist wird eine Erkennungsrate von 90 % angestrebt. Ist die Erkennungsrate zufriedenstellend, kann das Modell für das System zur Benutzeraktivitätserkennung genutzt werden, ansonsten muss der Prozess der Modellerstellung wiederholt werden Use-Cases-Erkennung Die Use-Cases-Erkennung beschäftigt sich mit der Analyse der Aufgaben und Ziele, welcher ein Benutzer verfolgt hat, während er eine Entdeckung gemacht bzw. ein Problem festgestellt hat. Eine Aufgabe oder ein Ziel kann z.b. das Speichern oder Erstellen einer Notiz sein. Die Use-Case-Erkennung kann, wie einige andere Arbeiten gezeigt haben, sehr nützlich sein, wie z.b. zur Steuerung eines Agenten, welcher Benutzern bei der Ausübung bestimmter Aufgaben behilflich ist [Mae94] oder awerdeuch um unbefugten Zugriff zu erkennen (Intrusion Detection), indem das Benutzerverhalten mit dem gewöhnlichen Benutzerverhalten verglichen wird. Werden Anomalien entdeckt, weist dieses auf einen unbefugten Zugriff hin [RLM97]. Das Ziel der Use-Case Erkennung in dieser Arbeit ist es herauszufinden, welche Aufgabe oder welches Ziel ein Benutzer verfolgt hat bzw. versucht hat zu verfolgen, um mögliche Fehler, die der Benutzer bei der Ausführung der Applikation hatte, besser interpretieren zu können, weil so die Intention des Benutzers bekannt ist. Die Stelle des Scheiterns kann so besser erkannt werden und mögliche Usability-Probleme können von Evaluationsexperten besser analysiert werden. Beispielsweise können so umständliche Wege, welche ein Benutzer zur Erreichung eines Use-Cases genommen hat, erkannt werden. Sollte dieses bei mehreren Benutzern auftreten, ist die App möglicherweise an bestimmten Stellen irreführend und sollte umstrukturiert werden. Des Weiteren kann statistisch mitverfolgt werden, wie oft bestimmte Use-Cases ausgeführt werden. Zusätzlich können Zyklen erkannt werden, welche immer wieder auftauchen. Zyklen können Indizien für ein suchendes Verhalten von Benutzern sein. Häufig genutzte Use-Cases können von den Entwicklern besser angeordnet bzw. erreichbarer für Benutzer angelegt werden, so dass sie mit weniger Aufwand erfüllbar sind. Genauso können selten genutzte Use-Cases weiter hinten in der Applikationshierarchie angeordnet werden. Ein Problem stellt das Erkennen von nicht erreichten Use-Cases dar, weil einige Use-Cases evtl. gleiche Anfangsoperationen haben. Eine Lösung hierfür bieten maschinelle Lernverfahren, welche das allgemeine Benutzerverhalten analysieren und so versuchen, den richtigen Use-Case zu erkennen. 32

38 3. RUES - Remote Usability Evaluation System Task-Modell Um eine Aufgabe (engl. Task) eines Benutzers zu identifizieren, wird ein Task-Modell benötigt, welches festlegt, was das Ziel ist und welche Schritte zur Erfüllung dieses Ziel nötig sind. So ein Task-Modell kann mit Task-Modellierungstechniken wie GOMS [JK96] erstellt werden. GOMS wurde 1983 von Moran, Card und Newell mit dem Ziel der Entwicklung einer Methode, die es ermöglicht zu erkennen, ob ein Benutzer Vorkenntnisse besitzen muss, um Aufgaben in einer Applikation lösen zu können. GOMS zerlegt Interaktionen eines Benutzers mit einer Benutzeroberfläche in elementare Aktionen. Ein System wird in Aufgaben und Handlungsmöglichkeiten, zur Erreichung dieser Aufgaben zerlegt, die dann auf Usability untersucht werden können. GOMS steht für Goals (dt. Ziele), Operators (dt. Operatoren), Methods (dt. Methoden) und Selection Rules (dt. Selektionsregeln). Im Folgenden werden die einzelnen Begriffe anhand eines Beispiels erläutert. Beispiel: Ein Benutzer möchte in seiner Notiz-Applikation eine Notiz erstellen und diese dann auch speichern. Goals Goals sind Ziele, die ein Benutzer erreichen möchte, wie im obigen Beispiel das Erstellen und Speichern einer Notiz. Ein Ziel besteht oft aus kleinen Teilzielen, wie z.b. das Eingeben des Titels und das Eingeben der Notiz. Alle diese Teilziele müssen erreicht werden, um das eigentliche Ziel zu erreichen [JK96]. Operators Ein Operator ist eine Aktion, die ausgeführt wird, um ein Ziel zu erreichen. Operatoren sind z.b. das Anklicken des Textfelds oder das Drücken eines Buttons. Welche Operationen möglich sind, wird von der Applikation festgelegt [JK96]. Methods Methoden sind Sequenzen von Operatoren und Teilzielen um ein Ziel zu erreichen. Wenn die Ziele eine hierarchische Form haben, dann gibt es eine entsprechende Hierarchie von Methoden [JK96]. Eine mögliche Sequenz zur Erfüllung des Ziels des obigen Beispiels wäre: Anklicken des Titelfeld, Eingeben eines Titels, Anklicken des Notizfeldes, Eingeben der Notiz und Drücken des Speichern-Buttons. 33

39 3. RUES - Remote Usability Evaluation System Selection Rules Es gibt oft mehrere Methoden, um ein Ziel zu erfüllen. Anstatt den Speichern-Button zu drücken, könnte man beispielsweise auch die Zurücktaste benutzen, über die jedes gängige mobile Android-Gerät verfügt, um eine Notiz zu speichern. Existieren mehrere Methoden zur Erfüllung eines Ziels, dann sind Selektionsregeln notwendig [JK96]. Der Unterschied zwischen einem Goal und einem Operator ist nur eine Frage des Detailgrades. Der Analyst entscheidet also, wie detailreich die jeweiligen Ziele ausformuliert werden. Manchmal ist es sinnvoll Ziele sehr detailreich zu gestalten, um komplexe Abläufe bis ins Detail mitverfolgen zu können. Bei simplen Abläufen reicht teilweise aber auch schon eine einfache Zielformulierung. Es ist also nicht notwendig, jedes Ziel bis ins Detail auszuformulieren [JK96]. Es existieren zwei grundsätzliche Formen von GOMS-Modellen, die Program Form und die Sequence Form: Program Form: Die Program Form teilt das System aufgabenorientiert in Klassen mit verschiedenen Methoden ein, mit der die Aufgaben erfüllt werden können. Dies hat den Vorteil, dass das gesamte prozedurale Wissen über den Ablauf dem Analysten bekannt ist. Die Program Form hat aber auch zwei Nachteile, zum Einen ist der einzige Weg, um eine Folge von Operationen einer Task zu bestimmen, das Modell auszuführen (entweder von Hand oder per Maschine). Zum Anderen kann es sehr aufwendig sein eine vollständige und genaue Program Form auszudrücken, besonders wenn es als maschinenausführbares Modell dargestellt wird [JK96]. Sequence Form: Bei der Sequence Form werden Aufgaben sequentiell durch angeordnete und festgelegte Opertoren definiert. Zusätzlich können Bedingungen und Parameter mit einbezogen werden. Die Vor- und Nachteile der Sequence Form sind invers zur Programm Form. Die Abfolgen von Operatoren müssen explizit vom Analysten modelliert werden, d.h. hat der Analyst kein prozedurales Wissen über alle Aufgabensitutionen. Für simple Systeme ist die Sequence Form schneller und einfacher umsetzbarer, als die komplexe Program Form [JK96]. In dieser Arbeit wird die Sequence Form genutzt, da es nicht nötig ist, alle möglichen Aufgaben und Ziele bis ins Detail abzudecken, sondern es sollen gezielt Use-Cases untersucht und verbessert werden. Android-Apps sind in der Regel einfach gestrickt, daher hält sich der Aufwand, Use-Cases in GOMS-Modelle zu überführen, in Grenzen. 34

40 3. RUES - Remote Usability Evaluation System Ein solches Task-Modell zu erstellen, ist die Aufgabe der Entwickler, denn nur sie kennen alle Use-Cases ihrer Applikation und wissen, wie diese zu erfüllen sind. Das heißt, bevor Use-Cases in einer Host-Applikation erkannt werden können, muss das Task-Modell erstellt werden. Ein Goal kann z.b. die Berührung eines bestimmten Buttons sein. Methoden zur Erreichung eines Goals könnten z.b. Interaktionen mit anderen Benutzeroberflächen-Objekten sein. Für den Fall, dass die Applikation keine Standard-Benutzeroberflächen-Objekte verwendet, kann eine Operation auch ein Zustandswechsel einer Android-Activity sein (Activity-Lebenszyklus) wie z.b. onpause, onstart oder onstop. Die Daten, welche erfasst werden müssen, um Use-Cases identifizieren können, sind also zum Einen die Namen von Benutzeroberflächen-Objekten, mit denen Benutzer interagieren und zum Anderen der Activity-Lebenszyklus Fehlereproduktion Um einen Software-Fehler verstehen und beheben zu können, ist es in der Regel notwendig, den Fehler zu reproduzieren. Die Reproduktion eines Fehlers erlaubt es die Existenz des Fehlers zu bestätigen und hilft dabei den Fehler zu verstehen und die Ursache zu identifizieren. Entwickler können so schneller die entsprechende Stelle im Quellcode finden und versuchen den Fehler durch Debugging zu beheben. Für die Reproduktion eines Fehlers ist es notwendig, alle Schritte des Ablaufs, bis zum Auftreten des Fehler zu kennen. Bei einer App interagiert der Benutzer immer mit einer Benutzeroberfläche, daher ist es notwendig alle Interaktionen des Benutzers mit der Benutzeroberfläche mitzuverfolgen. Bei normalen Fehlerberichten (engl. bug reports) fehlen diese Informationen, weil Benutzer meist nicht in der Lage sind, diese Fehler genau genug für die Entwickler zu beschreiben oder sie einfach keine Zeit haben darüber zu berichten. Dieses macht die Fehlerreproduktion, mit Hilfe eines normalen Fehlerberichts, sehr schwer und ist meist sehr zeitintensiv [RGBJ+13]. Die meisten GUI-level Tools, wie z.b. Android GUITAR [AG14] oder GUI crawler [AFT11], bedienen sich dem typischen Keyword Action Paradigma bei der Aufzeichnung von Benutzeroberflächen-Ereignissen. Bei diesem Paradigma werden die Eingabeereignisse von der konkreten Benutzeroberflächen-Ebene eine auf höhere Ebene abstrahiert, z.b. Klick auf Button1. Ein Problem ist, dass manche Android Apps keine Benutzeroberflächen-Objekte besitzen, wie z.b. Buttons, Menüs oder Eingabefelder. Deshalb gibt es bei solchen Apps keinen Ansatzpunkt für diese Tools. Während diese Tools gute Arbeit für normale Desktop-Anwendungen (point-and-click GUIs) leisten, sind sie für mobile Anwendungen nicht sehr tauglich. Mobile Anwendungen verwenden ein viel reicheres GUI-Paradigma mit kontinuierlichen Gesten wie Swipe, Spread und Pinch. Selbst wenn eine mobile Anwendung aus mehreren Bildschirmen, Buttons, Menüs etc. besteht, in die sich diese Tools einhaken könnten, sind Touchscreen-Gesten schwer zu erfassen und als Keyword Action Event darzustellen, weil sie an beliebigen Stellen der Benutzeroberfläche auftreten können. Daher wird 35

41 3. RUES - Remote Usability Evaluation System eine Low-Level-Präzision benötigt, um eine genaue Wiedergabe der Interaktion zu gewährleisten. Diese Präzision ist während der Aufzeichnung und der Wiedergabe der Interaktion erforderlich. Sie muss räumlich (Koordinaten) und zeitlich (Ereigniszeitpunkt) genau sein, um die Interaktion mit dem Interface genau reproduzieren zu können. Ereignisse wie z.b. eine Geste, welche zu langsam erfasst wird, kann möglicherweise nur als eine Sequenz von Berührpunkten wiedergegeben werden. Hinzu kommt, dass es nicht ausreichend ist nur die Benutzeroberflächen-Ereignisse zu monitoren, sondern es müssen zusätzlich externe Ereignisse erfasst werden, die durch Sensoren am mobilen Gerät entstehen, wie z.b. durch den Beschleunigungssensor. Denn diese Sensordaten werden von vielen gängigen Android-Apps zur Eingabe verwendet. Beispielsweise kann bei vielen Spielen durch das Accelerometer (Kippen und Schwenken des Geräts) die Steuerung erfolgen [GNAM13]. Die Tatsache, dass es sich bei RUES um ein Remote Usability Evaluation System (siehe Abschnitt 2.3.2) handelt, erschwert die Fehlerreproduktion, denn die Benutzer bzw. die Feedbackgeber sind räumlich vom Evaluationsexperten getrennt. Dadurch entstehen einige Probleme, denn die Evaluationsexperten besitzen nicht dasselbe mobile Gerät wie die Benutzer, was dazu führen kann, dass das Laufzeitverhalten der aufgezeichneten Daten nicht mit dem ursprünglichen Laufzeitverhalten der Benutzer übereinstimmt. Selbst wenn Entwickler und Benutzer das gleiche Modell des mobilen Geräts besitzen ist nicht garantiert, dass das selbe Laufzeitverhalten reproduziert werden kann. Hintergrundprozesse, Akkuladung und die allgemeine Auslastung des Geräts können Einfluss auf das Laufzeitverhalten haben. Zudem können die erzeugten Werte der Hardwaresensoren von mobilen Geräten von Hersteller zu Hersteller stark variieren. [RGBJ+13] zeigt, dass mit einer einfachen Visualisierung von Ereignissen bereits sehr gute Ergebnisse erzielt werden können. Es wurden Experimente mit normalen Fehlerberichten und mit einem Tool durchgeführt, welches die Ereignisse grafisch visualisiert, um zu schauen, welche Methode bessere Ergebnisse liefert. Die Fehler konnten mit diesem Tool meist alle gefunden werden, im Gegensatz zu normalen Fehlerberichten, mit deren Hilfe nicht immer Fehler reproduziert werden konnten. Zudem wurden die Fehler mit dem Tool immer schneller gefunden. Deshalb wird in RUES ein einfacheres Tool zur Verfügung gestellt, welches für jede Android-Activity, die während der Sitzung aktiv war, einen Screenshot erzeugt und die Interaktionen des Benutzers mit der Benutzeroberfläche nach und nach in diesen Screenshot einzeichnet. Der Evaluationsexperte hat so die Möglichkeit, sich von jeder Activity den Ablauf visuell darstellen zu lassen und kann nebenbei noch die Ereignisliste begutachten, um aufgetretene Fehler zu lokalisieren. 36

42 3. RUES - Remote Usability Evaluation System 3.3. Datenauswertung Die Auswertung des analysierten Ausführungskontexts erfolgt durch Evaluationsexperten sowie den Entwicklern der Host-Applikation. Aus jedem eingereichten Feedback generiert das Analyse-System ein Dokument, welches dem Evaluationsexperten, sowie den Entwicklern zur Verfügung steht. Die im Kapitel Datenanalyse beschriebenen Konzepte helfen dabei, die Auswertungsarbeit der Experten zu minimieren. Folgende Resultate stehen den Experten nach der Analyse zur Verfügung: 1. Berührpunkt-Interpretation: Berührpunkte die ihre Ziele verfehlt haben mit x- und y- Koordinaaten, sowie den Zielen, welche die Berührpunkte eigentlich treffen sollten. 2. Gesten-Interpretation: Gesten, die von der Host-Applikation nicht erkannt wurden mit der Gestenbezeichnung und der Anzahl, welche angibt, wie oft diese Geste an dieser Stelle schon nicht erkannt wurde. 3. Android Benutzeroberflächen-Richtlinien: Zu kleine bzw. Benutzeroberflächen- Objekte wie z.b. Buttons oder Menu-Elemente die räumlich zu nah beieinander liegen. 4. Benutzaktivitätserkennung: Erkannte physische Aktivität des Benutzers. 5. Use-Case Erkennung: Intension des Benutzers bei der Benutzung der Applikation mit allen gelungen sowie evtl. fehlgeschlagenen Use-Cases. 6. Ereignislisten: Listen aller gesammelten Ereignisse des Feedbacks. Nicht alle Daten können automatisiert erkannt werden und benötigen deshalb Evaluationsexperten, welche die richtigen Schlüsse ziehen. Zum Beispiel können Programmierfehler nicht automatisch erkannt werden, weil die Fehler im Quellcode liegen. Die Evaluationsexperten müssen diese Fehler zusammen mit den Entwicklern lokalisieren, indem sie sich die Screenshots der Activities mit den dazu gehörenden Ereignislisten anschauen. So kann der Fehlerraum eingeschränkt werden und die Entwickler können den Fehler im Quellcode finden und beheben. Zusätzlich stehen den Evaluationsexperten und Entwicklern statistische Werte zu allen Feedbacks einer bestimmten Host-Applikation zur Verfügung: Anzahl von Ausführungen eines bestimmten Use-Cases Fehlklicks in bestimmten Activities Nicht erkannte Gesten in bestimmten Activities 37

43 3. RUES - Remote Usability Evaluation System Abbildung 3.14.: Remote Usability Evaluation System (RUES) In der Abbildung 3.14 wird der Prozess von RUES veranschaulicht. Benutzer nutzen eine Host-Applikation, welche von RUES überwacht wird. Die Benutzer haben die Möglichkeit ein Feedback zu dieser Host-Applikation abzugeben. Beim Absenden eines solchen Feedbacks werden alle erfassten Ereignisse, zusammen mit dem Benutzerfeedback, an RUES verschickt, welches die Daten analysiert. Als Ergebnis dieser Analyse wird ein Dokument erzeugt, dass die Usability-Probleme sowie Fehler, die bei der Benutzung aufgetreten sind, enthält. Evaluationsexperten können aufgrund dieses Dokuments, zusammen mit den Entwicklern, versuchen Lösungen zur Verbesserung der Host-Applikation zu erarbeiten. 38

44 4. Prototypische Umsetzung 4. Prototypische Umsetzung Dieses Kapitel beschäftigt sich mit der technischen Umsetzung der Konzepte als Prototyp. Es wird gezeigt, wie der RUES-Prototyp die drei Phasen Datenerfassung, Datenanalyse und Datenauswertung bewältigt. Wegen der begrenzten Zeit, die zur Bearbeitung dieser Arbeit zur Verfügung stand, konnten nicht alle Konzepte zur Datenanalyse, welche im Abschnitt 3.2 beschriebenen sind, vollständig umgesetzt werden. Einige konnten nur zum Teil exemplarisch implementiert werden Systemüberblick Zunächst wird ein kurzer Überblick über die Struktur des RUES-Prototypen gegeben. Abbildung 4.1.: Systemkomponenten des RUES-Prototypen Der Prototyp besteht aus fünf Komponenten, der RUES Monitoring-Bibliothek, dem ConTexter (siehe Abschnitt 2.4), dem ConTexter-Server, der ConTexter-Datenbank und dem RUES Analyse System. Die RUES Monitoring-Bibliothek und das RUES Analyse System wurden im Rahmen dieser Arbeit entwickelt. Der ConTexter-Server, 39

45 4. Prototypische Umsetzung die ConTexter-Datenbank und der ConTexter sind bereits in einem früheren Projekt am Fachgebiet Software Engineering an der Leibniz Universität Hannover entstanden. Ihre Infrastruktur kann für den Prototypen genutzt werden und ergänzt ihn optimal. Die RUES Monitoring-Bibliothek erfasst die benötigten Sensor- und Benutzerdaten und speichert diese zunächst auf dem mobilen Gerät ab. Zusätzlich bietet die Bibliothek dem Benutzer die Möglichkeit ein Feedback abzugeben. Dieses Feedback wird zunächst an den ConTexter weitergeleitet. Im ConTexter kann der Benutzer ein textuelles Feedback abgeben und zusätzlich Bilder, Videos und Audiodateien anhängen, welche zusammen mit den gesammelten Sensor- und Benutzerdaten an den ConTexter-Server geschickt werden. Der Server speichert alle Daten in der ConTexter-Datenbank ab. Die Daten werden zusätzlich an einer REST-Schnittstelle zur Verfügung gestellt, so dass das RUES Analyse System die Daten im JSON- Format an dieser Schnittstelle abrufen kann. Das RUES Analyse System analysiert diese Daten und stellt die Ergebnisse auf einer Web-Plattform für die Evaluationsexperten und Entwickler zur Verfügung Datenerfassung Während der Datenerfassungsphase des RUES-Prototypen müssen alle benötigen Daten auf dem mobilen Gerät erfasst und für einen gewissen Zeitraum gespeichert werden. Im Folgenden wird vor allem auf die internen Strukturen und Vorgänge des Datenerfassungssystems von RUES eingegangen Bibliothek Damit jede beliebige App RUES nutzen kann, wurde das Datenerfassungssystem als Android-Bibliothek implementiert. Diese Bibliothek muss vor dem Kompilieren der Host-Applikation eingebunden werden. Nach dem Kompilieren der Host-Applikation zu einer ausführbaren Android-App, ist diese mit dem RUES-Datenerfassungssystem ausgestattet und besitzt zudem eine einfache Möglichkeit ein Feedback abzugeben Datenspeicherung Alle erfassten Benutzereingaben und Sensordaten werden zunächst intern auf dem mobilen Gerät gespeichert. Damit der Speicher aber nicht irgendwann vollläuft, wurde dieser als Ringspeicher angelegt. Das heißt, dass die Daten nur für eine bestimmte Zeit zwischengespeichert werden. Wie lange Daten gespeichert werden, muss von App zu App entschieden werden. Bei Apps bei denen längere Use-Cases vorkommen, 40

46 4. Prototypische Umsetzung ist eine längere Aufzeichnung der Daten erforderlich, damit genügend Daten zur Analyse vorhanden sind und der Ausführungskontext möglichst gut interpretiert werden kann. Allerdings kann die Dauer nicht beliebig lang sein, denn die Daten müssen zusammen mit dem Feedback von einem mobilen Gerät zu einem Server geschickt werden. Die Bandbreite von mobilen Geräten ist zum Teil sehr begrenzt, deshalb kann der Sendeprozess eines Feedbacks unter Umständen sehr lange dauern, welches Benutzer als störend empfinden könnten. Eventuell bricht der Benutzer sogar den Sendevorgang ab. Damit aufgezeichnete Daten nach Systemabstürzen der Host-Applikation nicht verloren gehen, werden die erfassten Ereignisse sofort persistent in einem Content Provider gespeichert. Stürzt eine App ab, befinden sich alle Daten bis zum Absturz im Content Provider. Der Benutzer wird dann beim nächsten Start der Host- Applikation darüber informiert, dass sich noch Daten im Speicher befinden. Er hat dann die Möglichkeit, diese Daten noch zu senden. Mit Hilfe dieser Daten kann dann genau nachverfolgt werden, was der Benutzer bis zum Systemabsturz getan hat Senden eines Feedbacks Das Senden eines Feedbacks wurde über eine Notifikation gelöst, welche immer angezeigt wird, egal wo sich ein Benutzer in der Host-Applikation befindet. Somit können Benutzer ein Feedback jederzeit abgeben, ohne erst an einen bestimmten Punkt der App zurückkehren zu müssen. Abbildung 4.2 zeigt zwei Screenshots, im Linken ist die Notifikation oben in der Statusleiste zu sehen, im Rechten sieht man die große Notifikation, wenn die Statusleiste aufgefaltet wird. Abbildung 4.2.: Notifikation zum Abschicken eines Feedbacks 41

47 4. Prototypische Umsetzung Nachdem die Notifikation betätigt wurde, wird der ConTexter gestartet und alle aufgezeichneten Daten aus dem Content Provider werden an den ConTexter übergeben. Der Benutzer hat nun die Möglichkeit im ConTexter ein textuelles Feedback abzugeben sowie Bilder, Videos und Audiodateien anzuhängen (siehe Abbildung 4.3). Abbildung 4.3.: Contexter Menü Alle aufgezeichneten Sensor- und Benutzerdaten werden dann mit dem Feedback zusammen an die ConTexter Serveranwendung geschickt, welche die Daten in ihrer Datenbank speichert Erfassungssystem Ziel unseres Erfassungssystems ist es, Zustandsänderungen in der Host-Applikation wahrzunehmen und diese als Ereignis persistent zu speichern. Für die Erfassung von Ereignis-Daten wurde für jeden der unterschiedlichen Ereignis-Typen, eine eigene Sensorklasse implementiert, die von der Basisklasse AndroidSensor erbt. Abbildung 4.4.: Sensoren 42

48 4. Prototypische Umsetzung Alle Sensoren überwachen die Host-Applikation auf Zustandsänderungen. Wird eine Zustandsänderung wahrgenommen, erzeugt der entsprechende Sensor ein Ereignis (Event-Objekt) und speichert dieses im Content Provider ab. Ein Ereignis besteht immer aus einem Zeitstempel und spezifischen, vom Ereignis-Typen abhängigen, Daten. Damit der Speicher, wie oben schon beschrieben, nicht vollläuft, wurde ein Ringspeicher implementiert. Dazu wurde eine Crawler-Klasse implementiert, die in festen Abständen über die Datenbank des Content Providers läuft und Events löscht, deren Zeitstempel älter als eine applikationsspezifische Zeit ist. Applikationsspezifisch heißt, dass von App zu App eine unterschiedliche Erfassungsdauer sinnvoll ist, was vor allem vom Umfang der enthaltenen Use-Cases in der Host-Applikation abhängt. Der Prozess der Datenerfassung und Datenspeicherung wird in Abbildung 4.5 veranschaulicht. Abbildung 4.5.: Datenerfassung und Datenspeicherung Ein Event (Ereignis) ist eine generalisierte Basisklasse für spezifische Ereignis-Typen (siehe Abbildung 4.6). Im Folgenden eine kurze Erläuterung der einzelnen Ereignistypen: UserTouch-Events: Berührung des Benutzers mit dem Display. Key-Events: Tastatureingaben des Benutzers. Gesture-Events: Gesten des Benutzers. GPS-Events: GPS Koordinaten. 43

49 4. Prototypische Umsetzung Abbildung 4.6.: Events UserInterface-Events: Benutzeroberflächen-Ereignisse wie z.b. das Drücken eines Button oder einer Checkbox. MotionSensor-Events: Daten von Hardwaresensoren wie dem Beschleunigungssensor. Screenshot-Events: Screenshot einer Activity. Application-Events: Activity-Lifecycle. Zusätzlich werden noch Informationen wie z.b. Bildschirmauflösung, Bildschirmhelligkeit, Systemversion, Hersteller sowie Modell des mobilen Geräts gespeichert, um Probleme die evtl. durch das benutzte mobile Gerät oder dem verwendeten Betriebssystem entstanden sind, zu erkennen Sensorkonfiguration Nicht für jede Applikation ist es notwendig alle verschiedenen Ereignis-Typen zu erfassen. Beispielsweise für eine Applikation, die keine Standard-Android-UI-Elemente nutzt, wie Buttons, Menus etc., wie es zum Teil bei Spielen der Fall ist, ist es nicht notwendig Benutzeroberflächen-Ereignisse zu erfassen. Es ist auch denkbar, dass bei einer App nur bestimmte Usability-Probleme untersucht werden sollen. Somit können nicht benötigte Daten bei der Übertragung an den Server gespart werden. Deshalb wurde das System so konzipiert, dass es möglich ist, Sensoren einfach einund auszuschalten und dieses separat für alle Host-Applikationen. Abbildung 4.7.: Sensor-Manager 44

50 4. Prototypische Umsetzung Um eine Erweiterung von zusätzlichen Sensoren zu gewährleisten, wurde die Klasse MonitorSensorManager implementiert, bei der sich alle Sensoren anmelden müssen. Diese zentrale Klasse startet, stoppt und pausiert alle Sensoren. Um also einen neuen Sensor in das System einzupflegen, muss dieser Sensor nur von der Basisklasse AndroidSensor erben und sich beim MonitorSensorManager registrieren Anwendungsfälle im Datenerfassungssystem Durch die Anforderungen und vorgestellten Features des Erfassungssystems ergeben sich fünf Use-Cases sowie die fünf Akteure Testbenutzer, Evaluationsexperte, ConTexter, EventContentProvider und HostApplikation. Abbildung 4.8.: Use-Case Datenerfassungssystem 45

51 4. Prototypische Umsetzung 4.3. Datenanalyse Dieses Kapitel beschäftigt sich mit der technischen Umsetzung der Datenanalyse von RUES, welches den Ausführungskontext interpretiert. Wie schon im Abschnitt 3.2 beschrieben, geschieht die Analyse zum größten Teil automatisch. Die gesammelten Daten der Erfassungsphase werden auf Usability-Probleme und Fehler analysiert. Die Ergebnisse der Analyse werden dann auf einer Web-Plattform für die Entwickler und für die Evaluationsexperten zur Verfügung gestellt RUES Analyse System Für die Analyse der Daten wurde ein RUES Analyse System entwickelt das folgende Aufgaben hat: Automatisches Abfragen neuer Feedbacks von der ConTexter-REST-Schnittstelle Analyse der Feedbacks auf Usability-Probleme und Fehler Darstellung der Ergebnisse auf einer Web-Plattform Nachdem ein Feedback abgeschickt wurde wird es zunächst in der ConTexter Datenbank gespeichert. Diese Feedbacks können dann von der ConTexter-REST-Schnittstelle abgerufen werden. Abbildung 4.9.: RUES Analyse System Abbildung 4.9 veranschaulicht das RUES Analyse System. Das System besteht aus vier Komponenten, einer Web-Plattform zur Darstellung der Ergebnisse (Abschnitt 4.4), einem Interpreter System, einer Control Unit und einer internen Datenbank zur Speicherung der Feedbacks und der Ergebnisse der Analyse. Die Control Unit schickt alle zwei Minuten eine GET-Anfrage an die ConTexter-REST-Schnittstelle um zu schauen, ob neue Feedbacks vorhanden sind. Existieren neue Feedbacks werden diese sofort in der internen Datenbank gespeichert und dem Interpreter System 46

52 4. Prototypische Umsetzung übergeben. Das Interpreter System analysiert die Eventdaten der Feedbacks auf Usability Probleme und Fehler und speichert die Ergebnisse in der internen Datenbank ab. Evaluationsexperten und Entwickler können sich dann die Ergebnisse, sowie die vollständigen Ereignis-Listen auf der Web-Plattform anschauen Interpreter System Das System besteht aus sieben verschiedenen Interpretern, welche die Daten der Erfassungsphase analysieren. Alle Interpreter erben dabei von der Basisklasse Interpreter. Abbildung 4.10.: Interpretertypen Abbildung 4.10 zeigt die verschiedenen Interpretertypen. Nachdem das Feedback durch alle Interpreter analysiert wurde, werden die Ergebnisse in der internen Datenbank gespeichert. Im Folgenden werden die einzelnen Interpreter genauer erläutert. ActivityInterpreter Der ActivityInterpreter versucht die physische Benutzaktivität zu erkennen. Zur Klassifikation werden Merkmale wie Standardabweichung, Mittelwert, durchschnittliche absolute Differenz und Beschleunigung benutzt. Wie andere Arbeiten, wie z.b. [WN11] oder [KWM10] gezeigt haben, reichen diese Merkmale für eine gute Benutzeraktivitätserkennung mit einer Erkennungsrate von bis zu 90% aus. Allerdings 47

53 4. Prototypische Umsetzung wird bei diesen Projekten davon ausgegangen, dass sich der Beschleunigungssensor am Körper befindet, wie z.b. am Gürtel. Abbildung 4.11.: Beschleunigungssensor am Gürtel [WN11] Allerdings wird bei Apps, die von RUES überwacht werden, davon ausgegangen, dass der Benutzer das Gerät in der Hand hält, während er ein Problem entdeckt. Daher sind die physischen Benutzeraktivitäten, die es zu erkennen gilt, schwieriger zu identifizieren, weil die Bewegungen, dadurch das sich das Gerät in der Hand befindet, ausgeglichen werden. Die Bewegung sind zudem nicht so intensiv, wie es der Fall wäre, wenn sich das Gerät z.b. am Gürtel befinden würde. Daher wurde als zusätzliches Merkmal für die Modellbildung die durchschnittliche Geschwindigkeit hinzugenommen, die sich aus den GPS-Koordinaten berechnen lässt. Mit diesem zusätzlichen Merkmal konnten gute Ergebnisse erzielt werden. Zur Klassifikation wurde die Software WEKA (Waikato Enviroment for Knowledge Analysis) verwendet, welche auch als Java API verfügbar ist verwendet. WEKA ist ein Softwaretool das die grundlegenden Techniken, wie Klassifikation, Clustering und Assoziation, zum Data Mining unterstützt. Mit Hilfe dieser Software konnte ein Modell erstellt werden, welches es erlaubt, zukünftige Feedbacks hinsichtlich ihrer Benutzeraktivität, zu klassifizieren. Abbildung 4.12 der WEKA zeigt einen Auszug der Trainingsdatensätze, welche zur Modelbildung verwendet wurden. Zunächst werden alle Attribute (Merkmale) mit dem definiert. Das letzte Attribut ist das Klassenattribut, die Benutzeraktivität mit den vorgegebenen möglichen Aktivitäten going, standing, on_bicycle, jogging und on_car. Unter dem können alle Trainingsdaten eingefügt werden. Ein Trainingsdatensatz besteht aus allen definierten Attributen inklusive dem Klassenattribut. Als Algorithmus wurde J48 benutzt, welcher einen Entscheidungsbaum aus den Trainingsdaten erzeugt, mit dem zukünftige Datensätze, bei denen das Klassenattribut unbekannt ist, klassifiziert werden können. Das in dieser Arbeit implementierte System zur Benutzeraktivitätserkennung soll nur exemplarisch zeigen, dass es möglich ist, eine Benutzeraktivität zu erkennen. 48

54 4. Prototypische Umsetzung Abbildung 4.12.: WEKA Trainingsdaten Um ein effektives System für dieses Problem zu entwickeln, sind zusätzliche komplexe Verfahren nötig, die aber den Umfang dieser Arbeit sprengen würden. Zum Beispiel müssten die Sensoren exakt kalibriert werden und zudem Smoothing-Techniken angewandt werden, um Flackern (engl. jitter) zu entfernen, um einheitliche Ergebnisse für jedes Feedback ohne Störungen zu erhalten. Zusätzlich müssten die Beschleunigungssensordaten in einen einheitlichen Raum transformiert werden, damit die Haltung des Geräts (horizontal oder vertikal) keinen Einfluss auf das Ergebnis hat. GestureInterpreter Der GestureInterpreter analysiert, ob eine Geste in einer Android-Activity möglich ist oder nicht. Die Analyse, ob Gesten möglich sind, findet dabei bereits auf dem mobilen Gerät statt, in dem für jede spezifische Activity überprüft wird, ob die ontouch-methode oder die ontouchview-methode implementiert ist. Ist keine der beiden Methoden implementiert, können auch keine Gesten in dieser Activity erkannt werden. Es geht also darum eine generelle Aussage treffen zu können, ob Gesten möglich sind oder nicht. Eine Gestenerkennung wurde im entwickelten System nur zum Teil implementiert, denn es können nur die Standardgesten wie Double Tap, Swipe, Pinch, Spread oder Drag erkannt werden. Um jede Geste zu erkennen ist es notwendig, wie bereits in Abschnitt beschrieben, ein Erkennungssystem für Gesten zu implementieren, welches nicht bekannte Gesten lernt und sie bei erneuten Auftreten wiedererkennt. 49

55 4. Prototypische Umsetzung GPSInterpreter Der GPSInterpreter berechnet die zurückgelegte Distanz und die dafür benötigte Zeit zwischen jeweils zwei GPS-Koordinaten. Zusätzlich berechnet der GPSInterpreter die durchschnittliche Geschwindigkeit des Benutzers. LifecycleInterpreter Der LifecycleInterpreter ordnet Ereignisse einem Lebenszyklus (engl. lifecycle) zu. Hierbei ist nicht der normale Android-Lebenszyklus (Abschnitt 2.5.2) für Activities gemeint, sondern nur eine Aktivitätsphase einer Activity. Beispiel: Ein Benutzer interagiert mit der Activity mit dem Namen MainActivity. Alle Ereignisse die jetzt erfasst werden, gehören zu diesem Lifecycle. Sobald zu einer anderen Activity, z.b. NoteActivity, gewechselt wird, endet der Lebenszyklus von der MainActivity. Würde jetzt zu der MainActivity zurücknavigiert werden, würde wieder ein neuer Lebenszyklus beginnen. So können sich die Evalutionsexperten später auf der Webplattform alle Ereignisse, geordnet nach Lebenszyklen, anschauen. Dieses Verfahren ist wesentlich übersichtlicher und leichter für Menschen zu interpretieren, als die Sortierung nach dem Android-Lebenszyklus. TouchpointInterpreter Der TouchpointInterpreter spürt Berührpunkte des Benutzers auf, die keine Funktion in der Host-Applikation ausgelöst haben. ScreenshotInterpreter Der ScreenshotInterpreter ordnet jedem Screenshot einem bestimmten Lebenszyklus zu. Außerdem müssen die Screenshots von normalen Bilderuploads unterschieden werden, weil diese in der ConTexter-Datenbank gleichbehandelt werden. UseCaseInterpreter Der UseCaseInterpreter versucht die Ziele bzw. Aufgaben, die ein Benutzer verfolgt, hat herauszufinden. Dazu vergleicht er die aufgezeichneten Ereignisdaten mit einem Task-Modell, welches durch die Entwickler zunächst erstellt werden muss. Dazu können zunächst Use-Cases (Goals) erstellt werden und anschließend Methoden hinzufügt werden. 50

56 4. Prototypische Umsetzung Abbildung 4.13.: Use-Case Erstellung Abbildung 4.13 zeigt den Use-Case Gruppe anlegen mit drei Operatoren. Eine Operator besteht immer aus einer Beschreibung (engl. description) und einer Aktion (engl. Action). Die Beschreibung kann z.b. der Name eines Benutzeroberflächen- Objekts oder der Name einer Activity sein. Eine Aktion kann z.b. ein Button-Klick oder eine Geste sein. Der Interpreter geht alle Operatoren der Reihe nach durch und vergleicht sie mit den aufgezeichneten Ereignisdaten. Ein Use-Case gilt als erfüllt, wenn seine letzten Operatoren in den aufgezeichneten Daten gefunden werden können. Es müssen daher nicht alle Operatoren erfüllt werden, denn es kann durchaus vorkommen, dass ein Use-Case, durch die zeitliche Begrenzung der aufgezeichneten Daten, nicht vollständig erfasst werden konnte, aber dennoch erfüllt wurde. Ein Use-Case gilt als gescheitert, wenn seine anfänglichen Operatoren gefunden werden können, aber nicht die zur Erfüllung notwendigen Operatoren Datenauswertung Zur Auswertung der analysierten Daten wurde eine Web-Plattform erstellt, die Teil des RUES Analyse Systems ist (siehe Abbildung 4.9). Nachdem ein Feedback von den Interpretern analysiert wurde, werden die Ergebnisse der Analyse in der internen Datenbank gespeichert. Die Web-Plattform lädt die Ereignisdaten sowie die Ergebnisse aus der Datenbank und stellt diese anschaulich und übersichtlich zur weiteren Auswertung dar. Durch die Analyse werden zwar Probleme aufgedeckt, aber Lösungsvorschläge müssen erst durch eine Auswertung von den Evaluationsexperten und Entwicklern erstellt werden. 51

57 4. Prototypische Umsetzung Entities Jede Host-Applikation die von RUES überwacht wird, bekommt eine eigene Entität (engl. entity) im System. Unter dieser Entität werden alle Feedbacks der Host- Applikation gespeichert und können unter dieser auch eingesehen werden (siehe Abbildung 4.14). Abbildung 4.14.: Auswahl einer Entität Nachdem eine Entität ausgewählt wurde, wird eine Liste aller Feedbacks dieser Entität angezeigt (siehe Abbildung4.15). Abbildung 4.15.: Feedbackauswahl Feedback Bei der Ansicht eines Feedbacks hat man die sechs Menüpunkte Metadata, Chronology, Events, Interpretation, Warnings und Use-Cases zur Auswahl, welche im Folgeden näher erläutert werden. 52

58 4. Prototypische Umsetzung Metadata Hier werden Metadaten wie API-Level, Systemversion, Bildschirmauflösung, Modelund Herstellername des mobilen Geräts, sowie der eingegebene Text des Benutzers angezeigt. Zusätzlich werden hier die Bilderuploads zum Feedback dargestellt. Mit den Metadaten können mögliche Fehler, die auf das benutzte Gerät oder das verwendete Betriebsystem zurückzuführen sind, erkannt werden. Abbildung 4.16.: Metadaten eines Feedbacks Chronology Die Chronology ist hauptsächlich für die Fehlerreproduktion gedacht. Hier werden alle Ereignisse chronologisch nach ihrem Lebenszyklus sortiert, wie es in Abschnitt beschrieben wurde. Ein Lebenszyklus besteht aus einer Ereignisliste sowie einem Screenshot der Activity, in der die Ereignisse aufgetreten sind. Mit einem Klick auf den zum Screenshot gehörigen Replay-Button, werden die Berührpunkte in den Screenshot eingezeichnet. Dabei werden die zeitliche Abstände zwischen den Berührpunkten genau eingehalten, so dass das genaue Benutzerverhalten erkennbar wird. Zusätzlich werden Berührpunkte die keine Funktion in der Host-Applikation ausgelöst haben sowie Gesten, die nicht möglich waren, farblich in der Ereignisliste markiert. Im Screenshot kann so die genaue Position dieser Berührpunkte und Gesten eingesehen werden. 53

59 4. Prototypische Umsetzung Abbildung 4.17.: Chronology: Lebenszyklus einer Activity Events Unter dem Menüpunkt Events kann man sich alle Arten von Ereignissen getrennt anschauen. Abbildung 4.18.: Ereignislisten eines Feedbacks Warnings Unter Warnings sind die Berührpunkte die keine Funktion der Host-Applikation ausgelöst haben, sowie Gesten die nicht möglich waren, noch einmal zusammengefasst. 54

60 4. Prototypische Umsetzung Abbildung 4.19.: Warnings zu einem Feedback Use-Cases Unter Use-Cases können alle erkannten und gescheiterten Use-Cases eingesehen werden. Abbildung 4.20.: Use-Case Analyse Wie die Legende in Abbildung 4.20 zeigt, können die Use-Cases und Operatoren drei unterschiedliche Zustände haben: performed: Ereignis wurde gefunden not performed: Ereignis wurde nicht gefunden not captured: Ereignis wurde durchgeführt, ist aber nicht in den aufgezeichneten Daten vorhanden 55

61 4. Prototypische Umsetzung Interpretation Unter dem Menüpunkt Interpretation werden alle Interpretationsergebnisse zur Benutzeraktivitätserkennung zusammengefasst. Zum Einen ist hier die erkannte Benutzeraktivität zu sehen, zum Anderen drei Diagramme, die dem Benutzer zur zusätzlichen Interpretation der Benutzeraktivität dienen sollen. Das erste Diagramm zeigt die Benutzergeschwindigkeit, das zweite Diagramm zeigt die zurückgelegten Meter und das dritte Diagramm zeigt die G-Kräfte, welche auf das mobile Gerät eingewirkt haben. Abbildung 4.21.: Diagramme zur Benutzeraktivität 56

62 5. Verwandte Arbeiten 5. Verwandte Arbeiten 5.1. FastFix FastFix [PJBR+12] ist eine Plattform für Desktop-Anwendungen, welches eine Echtzeit- Wartungsumgebung bietet. FastFix beobachtet die Interaktionen eines Benutzers zur Laufzeit. Das allgemeine Ziel des Systems ist es, Software-Ingenieuren mit einer Echtzeit-Wartungsumgebung zu unterstützen, um so die Effizienz zu verbessern und die Gesamtkosten zu verringern. FastFix ermöglicht es fernab vom Benutzer, mit einer Reihe von Werkzeugen und Umgebungen, das Sammeln von Informationen über Benutzerinteraktionen und über die Ausführung einer Anwendung. FastFix überwacht automatisch und erkennt Symptome der Ausführung über Fehler, Leistungsabfälle oder über Änderungen des Benutzerverhaltens. FastFix besteht aus zwei Komponenten: Dem FastFix-Client der sich in der Laufzeitumgebung der Host- Applikation befindet und dem FastFix-Server der sich in der Wartungsumgebung befindet. Der Server kommuniziert mit allen Clients über ein Netzwerk. Die FixFix Plattform ermöglicht es zudem Fehler zu reproduzieren, weil es alle auftretenden Ereignisse aufzeichnet und so eine genaue Wiedergabe ermöglicht. FastFix identifiziert zudem automatisch fehlerhafte Ausführungsmuster und schlussfolgert mögliche Problemursachen. Eine Überprüfung zur Ausführungszeit ist durch RUES nicht möglich und nicht sinnvoll, weil es sich bei RUES um ein System für mobile Geräte handelt und eine asynchrone Remote Usability Evaluation durchgeführt wird. Um so einen Ansatz für mobile Geräte zu ermöglichen, müsste eine dauerhafte stabile und schnelle Internetverbindung gegeben sein muevaluationframework Bader [BAD12] beschreibt in seiner Arbeit ein Framework zur Usability Evaluation für die Apple ios Plattform. Das Framework, mit dem Namen muevaluationframework, versucht durch das Monitoren von Sensordaten, Daten aus dem Betriebssystem und Benutzerinteraktionen wie Berührpunkten, Usability-Probleme zu finden. Anders als bei RUES, werden beim muevaluationframework die Daten in einer Laborumgebung erfasst. Mindestens ein Evaluationsexperte und immer genau eine Testperson müssen bei einer Sitzung zum Erfassen von Usability-Daten anwesend sein. Während eine Testperson mit der zu überwachenden App interagiert, können 57

63 5. Verwandte Arbeiten Evaluationexperten am Computer alle Interaktionen mit dem mobilen Gerät genau mitverfolgen. Dieser Ansatz beschränkt die Evaluation allerdings auf eine Laborumgebung, wodurch sich Benutzer allerdings nicht in einer natürlichen Umgebung befindet. Somit geben die Ergebnisse der Evaluation möglicherweise kein natürliches Benutzerverhalten wieder MultiDevice RemUsine MultiDevice RemUsine [PRS07] ist ein Remote Usability Evaluation Framework für mobile Geräte und kann zur Analyse von Windows CE Applikationen verwendet werden. Der Fokus liegt auf dem Erfassen von kontextuellen Informationen, über die Umgebung des Benutzers, wie z.b. Lärm oder Akkuverbrauch. Das Framework besteht aus einem logging tool zur Erfassung von Usability-Daten, über eine Software zum Analysieren dieser Daten und eine interaktive Ergebnisdarstellung. MultiDevice RemUsine unterscheidet in vier unterschiedliche Typen von Ereignisdaten: Contextual events: Kontextuelle Informationen System events: Systemereignisse Intension events: Benutzervorhaben Interaction events: Ereignisse aus der Interaktion zwischen Benutzer und Gerät Zur Analyse der Daten verwendet das Framework ein internes Task-Model, welches beschreibt, wie Benutzer eine Aufgabe zu erledigen haben. Das Framework vergleicht dazu das Benutzervorhaben mit einem geplanten Benuterverhalten. Dadurch können Abweichungen im Benutzerverhalten erkannt werden. Diese Abweichungen können dann durch die Entwickler untersucht werden, um Usability-Probleme zu erkennen. Ein ähnlicher Ansatz wird in dieser Arbeit zur Use-Case-Erkennung verfolgt, um die Intension eines Benutzers zu erkennen, um so bessere Aufschlüsse über das gesamte Feedback erhalten zu können RERAN RERAN (REcord and Replay for ANdroid) [GNAM13] ist ein Tool zur Fehlerreproduktion. Es erfasst Low-Level-Events direkt aus dem System-Kernel und überträgt diese zu einem stationären Computer. Diese Low-Level-Events können durch einen Replay-Agenten wieder in das System angespeist werden. Der Agent kann dann alle aufgezeichneten Ereignisse durchlaufen, so dass der Ablauf zeitlich genau reproduziert werden kann. 58

64 5. Verwandte Arbeiten Abbildung 5.1.: RERAN System [GNAM13] Abbildung 5.1 zeigt das RERAN System [GNAM13]. RERAN ist also in der Lage Eingabeereignisse, einer spezifischen Sitzung, genau in der gleichen Weise ablaufen zu lassen, wie sie ursprünglich aufgezeichnet wurden (Replay). Dies beinhaltet Ereignisse wie Berührpunkte und Sensordaten vom Beschleunigungssensor. RERAN kann den Entwicklern dabei helfen, Fehler in ihrer Applikationen zu reproduzieren. Allerdings werden durch diesen Ansatz sehr viele Daten erzeugt und zusätzlich müssen sich Evaluationsexperten und Testbenutzer am selben Ort befinden. Die Auswertung findet direkt am Computer statt, dazu muss das mobile Gerät mit dem Computer verbunden werden. Aufgrund der hohen Datenmengen, welche durch diesen Ansatz entstehen, eignet sich dieser Ansatz nicht für ein Remote Usability Evaluation System für mobile Geräte nicht, weil diese selten über eine schnelle und zuverlässige Internetverbindung verfügen. 59

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

Mehr

SEMINARVORTRAG ANDROID ENTWICKLUNG ETIENNE KÖRNER EMBEDDED SYSTEMS SS2013 - HSRM

SEMINARVORTRAG ANDROID ENTWICKLUNG ETIENNE KÖRNER EMBEDDED SYSTEMS SS2013 - HSRM SEMINARVORTRAG ANDROID ENTWICKLUNG ETIENNE KÖRNER EMBEDDED SYSTEMS SS2013 - HSRM ÜBERSICHT Android Android Dalvik Virtuelle Maschine Android und Desktop Applikationen Android Entwicklung Tools R Activity

Mehr

Einführung in AOP. Rico Schiekel - 012816 rschiekel@web.de. Agenda. Kernproblem der Objekt Orientierung

Einführung in AOP. Rico Schiekel - 012816 rschiekel@web.de. Agenda. Kernproblem der Objekt Orientierung Einführung in AOP Informatikseminar Rico Schiekel - 012816 rschiekel@web.de Fachhochschule Ravensburg Weingarten Hochschule für Technik und Sozialwesen Einführung in AOP Agenda Kernproblem der Objekt Orientierung

Mehr

Software Engineering und Projektmanagement 2.0 VO

Software Engineering und Projektmanagement 2.0 VO Software Engineering und Projektmanagement 2.0 VO Inhalte der Einheit Was ist Usability? Wieso ist Usability wichtig? Vorlesung 2009W Usability Engineering (Christoph Wimmer) Sicherheit in der Softwareentwicklung

Mehr

Messen von Usability. Wie kann man eine GUI unter dem Gesichtspunkt Usability bewerten?

Messen von Usability. Wie kann man eine GUI unter dem Gesichtspunkt Usability bewerten? Messen von Usability Wie kann man eine GUI unter dem Gesichtspunkt Usability bewerten? 1 Motivation Warum Usability messen? Usability Probleme frühzeitig erkennen Unterschiedliche Bedienelemente / Interaktionsmöglichkeiten

Mehr

Einführung in Android. 9. Dezember 2014

Einführung in Android. 9. Dezember 2014 Einführung in Android 9. Dezember 2014 Was ist Android? Software für mobile Geräte: Betriebssystem Middleware Kernanwendungen Android SDK: Tools und APIs zur Entwicklung von Anwendungen auf der Android-Plattform

Mehr

Multivariate Tests mit Google Analytics

Multivariate Tests mit Google Analytics Table of Contents 1. Einleitung 2. Ziele festlegen 3. Einrichtung eines Multivariate Tests in Google Analytics 4. Das JavaScript 5. Die Auswertung der Ergebnisse Multivariate Tests mit Google Analytics

Mehr

Johannes Rahn 29.07.2010. Usability und User Experience

Johannes Rahn 29.07.2010. Usability und User Experience Johannes Rahn 29.07.2010 Usability und User Experience Seite 2 Inhalt Begriffsdefinitionen: Was ist Usability und was User Experience? Was sind die Unterschiede? Warum ist Usability und User Experience

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem

1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem 1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem Management, Access Management a. Event Management b. Service Desk c. Facilities Management d. Change Management e. Request Fulfilment

Mehr

Das System sollte den Benutzer immer auf dem Laufenden halten, indem es angemessenes Feedback in einer angemessenen Zeit liefert.

Das System sollte den Benutzer immer auf dem Laufenden halten, indem es angemessenes Feedback in einer angemessenen Zeit liefert. Usability Heuristiken Karima Tefifha Proseminar: "Software Engineering Kernkonzepte: Usability" 28.06.2012 Prof. Dr. Kurt Schneider Leibniz Universität Hannover Die ProSeminar-Ausarbeitung beschäftigt

Mehr

Whitepaper. Warum Usability-Tests wichtig sind

Whitepaper. Warum Usability-Tests wichtig sind Whitepaper 01 Die Wichtigkeit von Usability-Tests Haben Sie sich schon einmal gefragt, ob Ihre Webseite ihr Potential voll ausschöpft? Ob es irgendwelche Stellschrauben gibt, an denen Sie drehen können

Mehr

PIWIN 1 Übung Blatt 5

PIWIN 1 Übung Blatt 5 Fakultät für Informatik Wintersemester 2008 André Gronemeier, LS 2, OH 14 Raum 307, andre.gronemeier@cs.uni-dortmund.de PIWIN 1 Übung Blatt 5 Ausgabedatum: 19.12.2008 Übungen: 12.1.2009-22.1.2009 Abgabe:

Mehr

DRESDEN. Ermitteln von Sprunghöhen mit einem Windows Phone. ZfP-Sonderpreis der DGZfP beim Regionalwettbewerb Jugend forscht.

DRESDEN. Ermitteln von Sprunghöhen mit einem Windows Phone. ZfP-Sonderpreis der DGZfP beim Regionalwettbewerb Jugend forscht. ZfP-Sonderpreis der DGZfP beim Regionalwettbewerb Jugend forscht DRESDEN Ermitteln von Sprunghöhen mit einem Windows Phone Felix Guttbier Schule: Gymnasium Brandis Jugend forscht 2014 ERMITTELN VON SPRUNGHÖHEN

Mehr

Programmieren für mobile Endgeräte SS 2013/2014. Dozenten: Patrick Förster, Michael Hasseler

Programmieren für mobile Endgeräte SS 2013/2014. Dozenten: Patrick Förster, Michael Hasseler Programmieren für mobile Endgeräte SS 2013/2014 Programmieren für mobile Endgeräte 2 Besprechung der Aufgaben 1) Legen Sie das Android-Projekt HelloWorldApp an so wie es in den vorherigen Folien beschrieben

Mehr

Usability Engineering

Usability Engineering Fakultät Informatik, Prof. Dr. rer. pol. Thomas Urban Usability Engineering Kapitel 5 Mobile Usability Gliederung 1 Usability Engineering - Einführung 2 Wahrnehmungspsychologie 3 Usability Engineering

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Autor: Michael Spahn Version: 1.0 1/10 Vertraulichkeit: öffentlich Status: Final Metaways Infosystems GmbH

Autor: Michael Spahn Version: 1.0 1/10 Vertraulichkeit: öffentlich Status: Final Metaways Infosystems GmbH Java Einleitung - Handout Kurzbeschreibung: Eine kleine Einführung in die Programmierung mit Java. Dokument: Autor: Michael Spahn Version 1.0 Status: Final Datum: 23.10.2012 Vertraulichkeit: öffentlich

Mehr

Smartphone Entwicklung mit Android und Java

Smartphone Entwicklung mit Android und Java Smartphone Entwicklung mit Android und Java predic8 GmbH Moltkestr. 40 53173 Bonn Tel: (0228)5552576-0 www.predic8.de info@predic8.de Was ist Android Offene Plattform für mobile Geräte Software Kompletter

Mehr

Das Handbuch zu KCM Tablet. Jörg Ehrichs Übersetzung: Burkhard Lück

Das Handbuch zu KCM Tablet. Jörg Ehrichs Übersetzung: Burkhard Lück Jörg Ehrichs Übersetzung: Burkhard Lück 2 Inhaltsverzeichnis 1 Wacom-Tablett-Einstellungen 5 1.1 Profilverwaltung...................................... 5 1.2 Allgemeine Tablett-Einstellungen und -Informationen.................

Mehr

Reaktive Systeme und synchrones Paradigma

Reaktive Systeme und synchrones Paradigma Sascha Kretzschmann Freie Universität Berlin Reaktive Systeme und synchrones Paradigma Einführung in das Seminar über synchrone Programmiersprachen Worum geht es? INHALT 2 Inhalt 1. Einleitung - Wo befinden

Mehr

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit IT-basierte Erstellung von Nachhaltigkeitsberichten Diplomarbeit zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen Fakultät der Leibniz Universität Hannover vorgelegt von

Mehr

Übungen zur Android Entwicklung

Übungen zur Android Entwicklung Übungen zur Android Entwicklung Aufgabe 1 Hello World Entwickeln Sie eine Hello World Android Applikation und laden diese auf den Emulator. Leiten Sie hierfür die Klasse android.app.activity ab und entwerfen

Mehr

Drei Strategien, die First-Call-Resolution zu verbessern

Drei Strategien, die First-Call-Resolution zu verbessern Drei Strategien, die First-Call-Resolution zu verbessern Das Messen von Kennzahlen ist allen Managern im Kunden-Service- Bereich ein Begriff. Die meisten von ihnen messen weit mehr als die branchenüblichen

Mehr

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013 Software Komponenten FS13 Gruppe 03 Horw, 24.05.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Adresse Telefon

Mehr

Integration mobiler Endgeräte in Medizinprodukte und Medizintechnik-nahe Produkte

Integration mobiler Endgeräte in Medizinprodukte und Medizintechnik-nahe Produkte Integration mobiler Endgeräte in Medizinprodukte und Medizintechnik-nahe Produkte Agenda Problemstellung Medizinprodukt App Grundlagen Szenarien (Problemstellungen und Lösungsansätze) 03.06.2013 2 Innovationen

Mehr

Seminarthemen WS 14/15

Seminarthemen WS 14/15 Dr. Max Mustermann Referat Kommunikation & Marketing Verwaltung Seminarthemen WS 14/15 Präsentation Alexander Schiller, Lars Lewerenz, Dominik Schön Prof. Dr. Bernd Heinrich Lehrstuhl für Wirtschaftsinformatik

Mehr

Prüfungszeuch im Fach Objektorientierte Programmierung WS 2000

Prüfungszeuch im Fach Objektorientierte Programmierung WS 2000 Prüfungszeuch im Fach Objektorientierte Programmierung WS 2000 A. Beschreibung der Projektarbeit. Welche Aufgabe haben Sie im Rahmen der Projektarbeit gelöst? 2. Mit welchen Tools bzw. Programmen (Anwendung,

Mehr

Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird.

Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird. AGILO HOWTO Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird. ROLLEN IM TEAM In Scrum hat jedes Teammitglied eine

Mehr

IT-Sicherheit mobiler Applikationen zur Unterstützung von Geschäftsprozessen. Bachelorarbeit

IT-Sicherheit mobiler Applikationen zur Unterstützung von Geschäftsprozessen. Bachelorarbeit IT-Sicherheit mobiler Applikationen zur Unterstützung von Geschäftsprozessen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft der

Mehr

Perzentile mit Hadoop ermitteln

Perzentile mit Hadoop ermitteln Perzentile mit Hadoop ermitteln Ausgangspunkt Ziel dieses Projektes war, einen Hadoop Job zu entwickeln, der mit Hilfe gegebener Parameter Simulationen durchführt und aus den Ergebnissen die Perzentile

Mehr

Praktikum Internetprotokolle - POP3

Praktikum Internetprotokolle - POP3 Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik/Rechnernetze 19. Mai 2008 1 Aufgabenstellung Praktikum

Mehr

Webdesign in Bibliotheken:

Webdesign in Bibliotheken: Webdesign in Bibliotheken: Zwischen Usability und Informationskompetenz Antje Schimpf Kerstin Schoof Überblick 1. Websites in Bibliotheken Alte und neue Funktionen 2. Usability vs. Informationskompetenz

Mehr

Finaler Testbericht. Finaler Testbericht. 1 Einführung 2. 1.1 Warum Softwaretests?... 2

Finaler Testbericht. Finaler Testbericht. 1 Einführung 2. 1.1 Warum Softwaretests?... 2 Inhaltsverzeichnis 1 Einführung 2 1.1 Warum Softwaretests?.................................... 2 2 Durchgeführte Tests 2 2.1 Test: allgemeine Funktionalität............................... 2 2.1.1 Beschreibung.....................................

Mehr

«Web und Multimedia» Usability

«Web und Multimedia» <Grundlagen und Technologien> Usability «Web und Multimedia» Usability 1 Usability: Definition Was ist Usability? Der Begriff «Usability» tritt bei verschiedenen Gelegenheiten z.b. Produkte, Gegenstände, Software...

Mehr

5.3.3.7 Übung - Überwachen und Verwalten von Systemressourcen in Windows XP

5.3.3.7 Übung - Überwachen und Verwalten von Systemressourcen in Windows XP 5.0 5.3.3.7 Übung - Überwachen und Verwalten von Systemressourcen in Windows XP Einführung Drucken Sie diese Übung aus und führen Sie sie durch. In dieser Übung verwenden Sie administrative Tools zur Überwachung

Mehr

Beispiel droidremoteppt

Beispiel droidremoteppt Arthur Zaczek Nov 2014 1 Beispiel droidremoteppt 1.1 Beschreibung Powerpoint soll mit ein Android Handy über Bluetooth gesteuert werden Folien wechseln (Vor/Zurück) Folien am Handy darstellen Am Handy

Mehr

Inhalt: Version 1.7.5

Inhalt: Version 1.7.5 Inhalt: Objekte ohne Methoden Objekte mit einfachen Methoden Objekte und Methoden mit Parametern Objekte und Methoden mit Rückgabewert Objekte mit einem Array als Attribut Beziehungen zwischen Objekten

Mehr

Cross-Platform Apps mit HTML5/JS/CSS/PhoneGap

Cross-Platform Apps mit HTML5/JS/CSS/PhoneGap Cross-Platform Apps mit HTML5/JS/CSS/PhoneGap Proseminar Objektorientiertes Programmieren mit.net und C# Florian Schulz Institut für Informatik Software & Systems Engineering Einführung Was hat Cross-Plattform

Mehr

3. Konzepte der objektorientierten Programmierung

3. Konzepte der objektorientierten Programmierung 3. Konzepte der objektorientierten Programmierung 3.1 Basiskonzepte 3.2 Generalisierung / Spezialisierung 3.3 Aggregation 3.4 Assoziation 3.5 Nachrichten 3.6 Polymorphismus 3. Konzepte der Objektorientierung

Mehr

Programmieren für mobile Endgeräte SS 2013/2014. Dozenten: Patrick Förster, Michael Hasseler

Programmieren für mobile Endgeräte SS 2013/2014. Dozenten: Patrick Förster, Michael Hasseler Programmieren für mobile Endgeräte SS 2013/2014 Programmieren für mobile Endgeräte 2 Organisatorisches Anmelden im Web: ZIV Lehre Anmelden Anwesenheitsliste Anwesenheitsschein bei 75% Anwesenheit Allgemeine

Mehr

Messdaten auswerten und visualisieren 5 Tipps, die passende Darstellungstechnik für ein Messsystem zu finden

Messdaten auswerten und visualisieren 5 Tipps, die passende Darstellungstechnik für ein Messsystem zu finden Messdaten auswerten und visualisieren 5 Tipps, die passende Darstellungstechnik für ein Messsystem zu finden 27.05.13 Autor / Redakteur: Nach Unterlagen von National Instruments / Hendrik Härter Messdaten

Mehr

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector 7.4 Analyse anhand der SQL-Trace 337 7.3.5 Vorabanalyse mit dem Code Inspector Der Code Inspector (SCI) wurde in den vorangegangenen Kapiteln immer wieder erwähnt. Er stellt ein paar nützliche Prüfungen

Mehr

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java Willkommen zur Vorlesung Objektorientierte Programmierung Vertiefung - Java Zum Dozenten Mein Name: Andreas Berndt Diplom-Informatiker (TU Darmstadt) Derzeit Software-Entwickler für Web- Applikationen

Mehr

DevOps bei den ID Build-Automatisierung statt Silo-Betrieb

DevOps bei den ID Build-Automatisierung statt Silo-Betrieb DevOps bei den ID Build-Automatisierung statt Silo-Betrieb SWS Entwicklertreffen vom 1.10.2015 Benno Luthiger 1.10.2015 1 Ausgangslage Kundenwunsch: Stabiles System, das schnell reagiert ( Betrieb) Neue

Mehr

Manuelles Testen großer industrieller Systeme Dr. Uwe Doetzkies Informatik für die Industrie Berlin

Manuelles Testen großer industrieller Systeme Dr. Uwe Doetzkies Informatik für die Industrie Berlin Manuelles Testen großer industrieller Systeme Dr. Uwe Doetzkies Informatik für die Industrie Berlin In Kürze Nichtfunktionale Anforderungen an große Softwaresysteme lassen sich in der Regel noch nicht

Mehr

Dr. Nicholas Merriam Rapita Systems Ltd., IT Centre, York Science Park, Heslington, York, YO10 5DG (UK) nick.merriam@rapitasystems.

Dr. Nicholas Merriam Rapita Systems Ltd., IT Centre, York Science Park, Heslington, York, YO10 5DG (UK) nick.merriam@rapitasystems. Das zeitliche Verhalten von Echtzeitsoftware zu analysieren und sicher zu stellen, dass die Anforderungen an das Echtzeitverhalten erfüllt werden kann sehr aufwendig und teuer sein. In diesem Artikel sollen

Mehr

Windows programmieren mit VisualBasic Einführung in die objektorientierte Programmiersprache

Windows programmieren mit VisualBasic Einführung in die objektorientierte Programmiersprache Dipl. Ing. (FH) Hans-Peter Kiermaier Windows programmieren mit VisualBasic Einführung in die objektorientierte Programmiersprache 1 Allgemeines Die Geschichte von VisualBasic oder kurz VB: 1991 Visual

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

Thema: Virtueller 3D Desktop. augmented reality

Thema: Virtueller 3D Desktop. augmented reality Thema: Virtueller 3D Desktop Problemstellung Dritte Dimension wird immer bedeutender im IT-Bereich Maus- und Tastatur- Konzept basiert auf zweidimensionaler Ein- und Ausgabe Ein neues, intuitives und natürliches

Mehr

CloudMatic V1.0. Inhalt

CloudMatic V1.0. Inhalt CloudMatic V1.0 Inhalt Einleitung... 2 CCUs hinzufügen... 3 meine-homematic.de... 4 Eigenes VPN... 4 View Editor... 5 Übersicht... 5 Allgemeine Einstellungen... 6 Kanäle hinzufügen... 6 Spezielle Kanäle...

Mehr

Variablen manipulieren per JDI

Variablen manipulieren per JDI Variablen manipulieren per JDI Zusammenfassung Jede moderne Java IDE verfügt über eine mächtige und dennoch meist einfach zu bedienende Benutzeroberfläche die das finden von Fehlern in lokalen oder entfernt

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

Praktikum Entwicklung von Mediensystemen mit ios

Praktikum Entwicklung von Mediensystemen mit ios Praktikum Entwicklung von Mediensystemen mit ios WS 2011 Prof. Dr. Michael Rohs michael.rohs@ifi.lmu.de MHCI Lab, LMU München Today Heuristische Evaluation vorstellen Aktuellen Stand Software Prototyp

Mehr

Fortgeschrittene Servlet- Techniken. Ralf Gitzel ralf_gitzel@hotmail.de

Fortgeschrittene Servlet- Techniken. Ralf Gitzel ralf_gitzel@hotmail.de Fortgeschrittene Servlet- Techniken Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht Servlet Initialisierung Attribute und Gültigkeitsbereiche Sessions

Mehr

Collaborative Virtual Environments

Collaborative Virtual Environments Collaborative Virtual Environments Stefan Lücking Projektgruppe Kreativität und Technik AG Domik WS 02/03 09.01.2003 1/35 Was sind CVE? Versuch einer Definition : Ein CVE ist ein Programm, das eine virtuelle

Mehr

Philosophie & Tätigkeiten. Geschäftsfelder. Software Engineering. Business Applikationen. Mobile Applikationen. Web Applikationen.

Philosophie & Tätigkeiten. Geschäftsfelder. Software Engineering. Business Applikationen. Mobile Applikationen. Web Applikationen. Philosophie & Tätigkeiten Wir sind ein Unternehmen, welches sich mit der Umsetzung kundenspezifischer Softwareprodukte und IT-Lösungen beschäftigt. Wir unterstützen unsere Kunde während des gesamten Projektprozesses,

Mehr

3.9 Grundelemente einer Benutzeroberfläche

3.9 Grundelemente einer Benutzeroberfläche 92 3 Grundlagen einer ios-anwendung 3.8.4 Target-Actions Einer der häufigsten Anwendungsfälle bei einer Oberfläche ist das Betätigen einer Schaltfläche durch einen Anwender, woraufhin eine bestimmte Aktion

Mehr

Eclipse User Interface Guidelines

Eclipse User Interface Guidelines SS 2009 Softwarequalität 06.05.2009 C. M. Bopda, S. Vaupel {kaymic/vaupel84}@mathematik.uni-marburg.de Motivation (Problem) Motivation (Problem) Eclipse is a universal tool platform - an open, extensible

Mehr

Zeiterfassungsanlage Handbuch

Zeiterfassungsanlage Handbuch Zeiterfassungsanlage Handbuch Inhalt In diesem Handbuch werden Sie die Zeiterfassungsanlage kennen sowie verstehen lernen. Es wird beschrieben wie Sie die Anlage einstellen können und wie das Überwachungsprogramm

Mehr

Java Einführung Methoden in Klassen

Java Einführung Methoden in Klassen Java Einführung Methoden in Klassen Lehrziel der Einheit Methoden Signatur (=Deklaration) einer Methode Zugriff/Sichtbarkeit Rückgabewerte Parameter Aufruf von Methoden (Nachrichten) Information Hiding

Mehr

Informatik Kurs 12 André Hoffmann. Delphi. Einführung in die Windows- Programmierung

Informatik Kurs 12 André Hoffmann. Delphi. Einführung in die Windows- Programmierung Informatik Kurs 12 André Hoffmann Delphi Einführung in die Windows- Programmierung Grundlagen Entwicklung von Windows-Programmen Relativ unkompliziert durch typische, vorgefertigte Elemente Programmiertechnische

Mehr

Dynamische Plug-ins mit Eclipse 3. Martin Lippert (martin.lippert@it-agile.de, www.it-agile.de) Tammo Freese (freese@acm.org)

Dynamische Plug-ins mit Eclipse 3. Martin Lippert (martin.lippert@it-agile.de, www.it-agile.de) Tammo Freese (freese@acm.org) Dynamische Plug-ins mit Eclipse 3 Martin Lippert (martin.lippert@it-agile.de, www.it-agile.de) Tammo Freese (freese@acm.org) Überblick Die Ausgangslage Dynamische Plug-ins Warum? Eclipse 3 Die OSGi-basierte

Mehr

Ausarbeitung des Interpreter Referats

Ausarbeitung des Interpreter Referats Ausarbeitung des Interpreter Referats Gliederung 1. Programmiersprache 1.2. Syntax 1.2.1. Konkrete Syntax 1.2.2. Abstrakter Syntax Baum (Abstrakte Syntax) 2. Parser 2.1. Syntaktische Struktur einer Sprache

Mehr

Effizientes Änderungsmanagement in Outsourcing- Projekten

Effizientes Änderungsmanagement in Outsourcing- Projekten Effizientes Änderungsmanagement in Outsourcing- Projekten Dr. Henning Sternkicker Rational Software IBM Deutschland GmbH Sittarder Straße 31 52078 Aachen henning.sternkicker@de.ibm.com Abstract: Es werden

Mehr

Einführung in das Microsoft.NET-Framework. Programmiersprache C# MEF Das Managed Extensibility Framework. André Kunz

Einführung in das Microsoft.NET-Framework. Programmiersprache C# MEF Das Managed Extensibility Framework. André Kunz Einführung in das Microsoft.NET-Framework Programmiersprache C# MEF Das Managed Extensibility Framework André Kunz 21.09.2010 1 In dieser Einführung bekommen Sie einen kurzen Einstieg in das.net-framework

Mehr

Grundlagen der Verwendung von make

Grundlagen der Verwendung von make Kurzskript zum Thema: Grundlagen der Verwendung von make Stefan Junghans Gregor Gilka 16. November 2012 1 Einleitung In diesem Teilskript sollen die Grundlagen der Verwendung des Programmes make und der

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Sichtbar im mobilen Web. Die Optimierung von Websites für mobile Endgeräte

Sichtbar im mobilen Web. Die Optimierung von Websites für mobile Endgeräte Die Optimierung von Websites für mobile Endgeräte 1 2 Die Optimierung von Websites für mobile Endgeräte Die Anzahl der Personen, die das mobile Internet nutzt, hat sich seit 2012 nahezu verdoppelt. Waren

Mehr

Seminararbeit Ruby Uno Kartenspiel

Seminararbeit Ruby Uno Kartenspiel Seminararbeit Ruby Uno Kartenspiel Autor: Fabian Merki Fabian Merki 05.11.2006 1 von 10 Inhaltsverzeichnis Einleitung... 3 Die Idee... 4 Design und Implementierung in Ruby... 5 Testing... 7 Startbefehle...

Mehr

Claudia Hewelt Sarah Waschkewitz

Claudia Hewelt Sarah Waschkewitz Claudia Hewelt Sarah Waschkewitz Ziele der Softwareevaluation Anforderungen an die Software Methoden Expertenevaluation Benutzerevaluation Ergebnisse auswerten Optimierung/ Vergleich von Software Benutzerfreundlichkeit

Mehr

Einführung in Betriebssysteme

Einführung in Betriebssysteme Einführung in Betriebssysteme APPLE ios Entwicklung von ios Entwickelt auf der Basis von MacOS X UNIX Vorgestellt am 9.1.2007 Zusammen mit iphone Markenname von Cisco Internetwork Operating System Für

Mehr

Objektorientierte Programmierung. Kapitel 12: Interfaces

Objektorientierte Programmierung. Kapitel 12: Interfaces 12. Interfaces 1/14 Objektorientierte Programmierung Kapitel 12: Interfaces Stefan Brass Martin-Luther-Universität Halle-Wittenberg Wintersemester 2012/13 http://www.informatik.uni-halle.de/ brass/oop12/

Mehr

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014 Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung Klaus Kusche, September 2014 Inhalt Ziel & Voraussetzungen Was sind abstrakte Datentypen? Was kann man damit grundsätzlich?

Mehr

User Interface Guidelines - Möglichkeiten und Grenzen

User Interface Guidelines - Möglichkeiten und Grenzen Folie Titel User Interface Guidelines - Möglichkeiten und Grenzen Ellen Reitmayr relevantive AG World Usability Day Berlin 3. November 2005 www.openusability.org Übersicht 1 Einführung Wozu User Interface

Mehr

KURZANLEITUNG CLOUD BLOCK STORAGE

KURZANLEITUNG CLOUD BLOCK STORAGE KURZANLEITUNG CLOUD BLOCK STORAGE Version 1.12 01.07.2014 SEITE _ 2 INHALTSVERZEICHNIS 1. Einleitung......Seite 03 2. Anlegen eines dauerhaften Block Storage...Seite 04 3. Hinzufügen von Block Storage

Mehr

5.3.3.6 Übung - Überwachen und Verwalten von Systemressourcen in Windows Vista

5.3.3.6 Übung - Überwachen und Verwalten von Systemressourcen in Windows Vista 5.0 5.3.3.6 Übung - Überwachen und Verwalten von Systemressourcen in Windows Vista Einführung Drucken Sie diese Übung aus und führen Sie sie durch. In dieser Übung verwenden Sie administrative Tools zur

Mehr

Mobile Security Configurator

Mobile Security Configurator Mobile Security Configurator 970.149 V1.1 2013.06 de Bedienungsanleitung Mobile Security Configurator Inhaltsverzeichnis de 3 Inhaltsverzeichnis 1 Einführung 4 1.1 Merkmale 4 1.2 Installation 4 2 Allgemeine

Mehr

Java Kurs für Anfänger Einheit 5 Methoden

Java Kurs für Anfänger Einheit 5 Methoden Java Kurs für Anfänger Einheit 5 Methoden Ludwig-Maximilians-Universität München (Institut für Informatik: Programmierung und Softwaretechnik von Prof.Wirsing) 22. Juni 2009 Inhaltsverzeichnis Methoden

Mehr

Web und Mobile Apps Programmieren mit Dart

Web und Mobile Apps Programmieren mit Dart Web und Mobile Apps Programmieren mit Dart Marco Jakob Kalaidos Fachhochschule Schweiz majakob@gmx.ch Abstract: Bisher war es kaum realistisch, im Anfängerunterricht mobile oder webbasierte Applikationen

Mehr

Mobile Device Management

Mobile Device Management Mobile Device Management Ein Überblick über die neue Herausforderung in der IT Mobile Device Management Seite 1 von 6 Was ist Mobile Device Management? Mobiles Arbeiten gewinnt in Unternehmen zunehmend

Mehr

Agile Programmierung - Theorie II SCRUM

Agile Programmierung - Theorie II SCRUM Agile Programmierung - Theorie II SCRUM Arne Brenneisen Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Seminar Softwareentwicklung in der Wissenschaft Betreuer: Christian

Mehr

Social Media Datennutzung im Customer Relationship Management

Social Media Datennutzung im Customer Relationship Management Social Media Datennutzung im Customer Relationship Management Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B. Sc.) im Studiengang Wirtschaftswissenschaft der Wirtschaftswissenschaftlichen

Mehr

Erste Erfahrungen mit Android

Erste Erfahrungen mit Android Java User Group München, 22. 9. 2008 Erste Erfahrungen mit Android 1 Was ist Android? Die erste vollständige, offene und freie Plattform für mobile Telefone Entwickelt von der Open Handset Alliance (Telecoms,

Mehr

Java Einführung Programmcode

Java Einführung Programmcode Java Einführung Programmcode Inhalt dieser Einheit Programmelemente Der erste Programmcode Die Entwicklungsumgebung: Sun's Java Software Development Kit (SDK) Vom Code zum Ausführen des Programms 2 Wiederholung:

Mehr

Hauptseminar AOSD. Design-by-Contract

Hauptseminar AOSD. Design-by-Contract Hauptseminar AOSD Seite 1 Entstehung Was ist das? Java Annotations und AOP ConceptJ Zusammenfassung Seite 2 Entstehung Entwickelt von Bertrand Meyer Heute Prof. an der ETH Zürich Erstmals in Programmiersprache

Mehr

Das Studiengangsinformationssystem (SGIS)

Das Studiengangsinformationssystem (SGIS) Das Studiengangsinformationssystem (SGIS) Manual für Typo3-Redakteure Version 1.a Mai 2015 Kontakt: Referat 1.4 - Allgemeine Studienberatung und Career Service Christian Birringer, christian.birringer@uni-rostock.de

Mehr

App-Entwicklung mit Titanium

App-Entwicklung mit Titanium Masterstudienarbeit Betreuung Prof. Dr. M. von Schwerin 1 Gliederung 1.Motivation 2.Aufgabenstellung 3.Projektbeschreibung 4.Projektstatusbericht 5.Fazit und Ausblick 2 1.Motivation Verbreitung von Smartphones

Mehr

Analyse kritischer Erfolgsfaktoren für Enterprise Social Networking Anwendungen. Bachelorarbeit

Analyse kritischer Erfolgsfaktoren für Enterprise Social Networking Anwendungen. Bachelorarbeit Analyse kritischer Erfolgsfaktoren für Enterprise Social Networking Anwendungen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaften

Mehr

Design Betrachtungen für r Tablet PC Software

Design Betrachtungen für r Tablet PC Software Design Betrachtungen für r Tablet PC Software Stefan Wick Software Design Engineer / Test Lead Tablet PC Group - Microsoft Corporation swick@microsoft.com Überblick Design Betrachtungen Richtlinien für

Mehr

3 Anwendungsarchitektur und Entwicklungsumgebung

3 Anwendungsarchitektur und Entwicklungsumgebung 21 3 Anwendungsarchitektur und Bei den Entwicklern von Web-basierten Dialogsystemen hat sich im Laufe der Zeit eine Vorgehensweise im Design von Anwendungen entwickelt, dies es ermöglicht, flexible Web-Dialoge

Mehr

Windows 7 starten. Kapitel 1 Erste Schritte mit Windows 7

Windows 7 starten. Kapitel 1 Erste Schritte mit Windows 7 Windows 7 starten Wenn Sie Ihren Computer einschalten, wird Windows 7 automatisch gestartet, aber zuerst landen Sie möglicherweise auf dem Begrüßungsbildschirm. Hier melden Sie sich mit Ihrem Benutzernamen

Mehr

Debian Installer Basics

Debian Installer Basics Debian Installer Basics Zinching Dang 09. Mai 2014 1 Debian Installer Debian Installer Installationsmedium für Debian verschiedene Typen: CD- und DVD-Installer: für Installation ohne oder mit langsamen

Mehr

Erste Schritte mit Elvis 3 ein Beispielprojekt

Erste Schritte mit Elvis 3 ein Beispielprojekt Erste Schritte mit Elvis 3 ein Beispielprojekt Um Sie mit Elvis 3 vertraut zu machen möchten wir mit Ihnen mit diesem Kapitel ein Beispielprojekt vom ersten Aufruf von Elvis 3 bis zum Testlauf aufbauen.

Mehr

Programmieren 2 (Prof. Hasbargen) Klausur

Programmieren 2 (Prof. Hasbargen) Klausur Programmieren 2 (Prof. Hasbargen) 1 Klausur Aufgabe 1 (10 Punkte) Dynamisierung von HTML-Seiten HTML-Seiten sind eine gängige Art und Weise, Informationen darzustellen. Nennen Sie die Gründe, welche Vorteile

Mehr

SOFTWARE. ekey TOCAhome pc. Herausgeber: ekey biometric systems GmbH Lunzerstraße 64 A-4030 Linz office@ekey.net n www.ekey.net

SOFTWARE. ekey TOCAhome pc. Herausgeber: ekey biometric systems GmbH Lunzerstraße 64 A-4030 Linz office@ekey.net n www.ekey.net SOFTWARE ekey TOCAhome pc Herausgeber: ekey biometric systems GmbH Lunzerstraße 64 A-4030 Linz office@ekey.net n www.ekey.net Ihr Finger ist der Schlüssel Inhaltsverzeichnis 1. ZWECK DIESES DOKUMENTS 3

Mehr

SELBSTREFLEXION. Selbstreflexion

SELBSTREFLEXION. Selbstreflexion INHALTSVERZEICHNIS Kompetenz... 1 Vergangenheitsabschnitt... 2 Gegenwartsabschnitt... 3 Zukunftsabschnitt... 3 GOLD - Das Handbuch für Gruppenleiter und Gruppenleiterinnen Selbstreflecion Kompetenz Die

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

Mobile App Testing. Software Test im mobilen Umfeld ATB Expertentreff, Wien, 2013. Functional Test Automation Tools

Mobile App Testing. Software Test im mobilen Umfeld ATB Expertentreff, Wien, 2013. Functional Test Automation Tools Functional Test Automation Tools Mobile App Testing Software Test im mobilen Umfeld ATB Expertentreff, Wien, 2013 Presenter: Christoph Preschern (cpreschern@ranorex.com) Inhalte» Ranorex Company Overview»

Mehr