Bachelorarbeit. im Studiengang Technische Informatik. von. Constantin Schomburg

Größe: px
Ab Seite anzeigen:

Download "Bachelorarbeit. im Studiengang Technische Informatik. von. Constantin Schomburg"

Transkript

1 Gottfried Wilhelm Leibniz Universität Hannover Fakultät für Elektrotechnik und Informatik Institut für Praktische Informatik Fachgebiet Software Engineering Evaluierung einer Sensor-Simulationsumgebung zum Testen von Android-Anwendungen Evaluation of a Sensor Simulation Framework for Android Application Testing Bachelorarbeit im Studiengang Technische Informatik von Constantin Schomburg Prüfer: Prof. Dr. Kurt Schneider Zweitprüfer: Prof. Dr. Joel Greenyer Betreuer: Dipl.-Inform. Stefan Gärtner Hannover, 10. September 2013

2 Zusammenfassung Mobile Geräte wie Smartphones und Tablets werden heutzutage mit einer wachsenden Anzahl von Sensoren ausgestattet, mit denen Anwendungen die Umwelt wahrnehmen und kontextspezifisch reagieren können. Im Entwicklungsprozess solcher sensorgebundener Anwendungen reichen herkömmliche Methoden und Werkzeuge zum Testen der Software meist nicht aus. Die Zielgeräte haben oft unterschiedliche Sensoren mit stark variierender Qualität, gemessene Daten können Störungen unterliegen oder sind an eine Umgebung gebunden, die sich nur schwer reproduzieren lässt. Bestehende Werkzeuge im Bereich der Sensorsimulation auf mobilen Geräten ermöglichen es bereits, von einem Quellgerät Sensordaten aufzunehmen und anschließend in der eigenen Anwendung unverändert wiederzugeben und damit die Sensoren zu simulieren. Diese sind allerdings nur begrenzt einsetzbar, da der Entwickler weiterhin Daten aus einem breiten Spektrum von Zielgeräten aufnehmen muss, um seine Anwendung zu testen. Diese Arbeit evaluiert Sensor-Simulationsumgebungen in der mobilen Software-Entwicklung. Da diese Umgebungen bei der Vielfalt mobiler Geräte nur einen eingeschränkten Nutzen haben, wird hier eine Methode präsentiert, die Sensordaten eines Quellgerätes so zu verändern, dass die Sensoren verschiedener anderer Gerätemodelle damit simuliert werden können. Des Weiteren wurden die Sensoren verschiedener Smartphones analysiert und ein Konzept zur Evaluierung der Simulation erarbeitet. Die vorgestellte Methode kann in einer Simulationsumgebung implementiert werden, um den Aufwand im Testprozess zu reduzieren. Der Nutzen eines solchen Systems im Entwicklungsprozess wird herausgestellt und die Integration in verschiedene bekannte Vorgehensmodelle untersucht. ii

3 Abstract Nowadays mobile devices such as smartphones and tablets are equipped with a growing number of sensors to perceive the environment and act accordingly. Traditional development tools often do not suffice for testing these context aware applications. The target devices regularly use different sensors which vary in quality, measurements are influenced by noise or the application uses an environment that is hard to replicate. Existing sensor simulation tools for mobile devices enable the developer to record sensory data from a source device and then play it back in their own application for simulating the sensors. However, these tools are limited by the fact that the developer still has to record data from a broad spectrum of target devices to test his applications with specific sensors. This work evaluates the use of sensor simulation frameworks in mobile application development. Since these tools only have a limited use in the variety of mobile devices, a method is presented to modify sensor values of a source device so that other devices sensors can be simulated. With this method, the developer only needs to record a single time and can use this data to simulate across a wide range of devices. In addition, this work analyzed the sensors of multiple smartphones and presents a concept to evaluate the quality of the simulation. The method can be implemented into a sensor simulation framework to reduce the effort in the testing phase. This work highlights the value of such a system in the development process and examines the integration in various established software development processes. iii

4 Inhaltsverzeichnis 1. Einführung Motivation und Problemstellung Zielsetzung Struktur der Arbeit Grundlagen Testen sensorgebundener Applikationen Die Simulationsumgebung Beschleunigungssensoren Evaluierungskonzept und Durchführung Beschreibung des Vorgehens zur Evaluierung Datenerhebung Evaluierungskonzept Referenzbewegung Sensormodellierung Normalisierung Glättung Auflösungsquantisierung der Beschleunigung Zeitliche Abstände zwischen Messwerten Evaluierung Leistungsanalyse der Simulation Auswahl eines Profilers Durchführung Auswertung Integration in den Entwicklungsprozess Black-Box-Test Zwischen Mock-Objekt und Gerät Automatisches Testen Integration in Vorgehensmodelle Wasserfall-Modell V-Modell Spiralmodell Agile Prozesse Fazit und Ausblick Fazit iv

5 Inhaltsverzeichnis 6.2. Ausblick A. Inhalt der CD 38 v

6 1. Einführung 1.1. Motivation und Problemstellung Mit dem Aufkommen von Smartphones und Tablets vor einigen Jahren haben sich die Anforderungen an Software mobiler Geräten stark verändert. Anwendungen haben nun Zugriff auf eine stetig steigende Anzahl von Sensoren, um die Umgebung wahrzunehmen. Dazu zählt der Beschleunigungssensor, der der Anwendung Informationen über die Orientierung und Bewegung im Raum liefert und zur Standardausstattung gehört, aber auch sehr speziellen Sensoren wie dem Lichtsensor oder Sensoren zum Messen von Druck, Temperatur und Luftfeuchtigkeit. Ein zweiter Unterschied zu älteren Mobiltelefonen ist auch die Verbreitung von Anwendungen über das Internet. Während früher die Anwendungen auf den Geräten von den Herstellern fest vorinstalliert und somit passend zum Gerätetyp waren, hat der Endbenutzer nun Zugriff auf eine um viele Größenordnungen höhere Anzahl von Anwendungen über sogenannte App Stores 1 im Internet. Mit der Einführung von Betriebssystemen wie Android, die auf einer großen Breite von Geräten unterschiedlicher Hersteller ausgeliefert werden, steigt auch der Anwenderkreis der eigenen Applikation um ein Vielfaches [1]. Die eigene Anwendung muss nun von vielen verschiedenen Geräten unterstützt werden, die aus unterschiedlichen Generationen, Preisklassen oder Formfaktoren stammen, und den Endnutzern dabei möglichst ähnliche Funktionalität bereitstellen. Dies wird erschwert durch verschiedene Bildschirmauflösungen, Eingabemethoden und auch im Bereich der Sensorik, wo die Bauteile sich oft stark in Qualität, Auflösung und Geschwindigkeit unterscheiden. Mit der Anzahl der Geräte, auf denen eine Anwendung läuft, erhöht sich somit auch die Komplexität in der Entwicklung. Entwickelt man für ein so großes Spektrum an verschiedenen Geräten? Es reicht nicht mehr allein, die Anwendung auf einem einzelnen Zielgerät zu testen. Vielmehr muss der Entwickler seine Anwendung mehrmals im Entwicklungsprozess an mehreren Geräten testen, die einen hohen Abdeckungsgrad über den Android-Markt bieten, um sicherzustellen, dass seine Anwendung auch jedem Nutzer uneingeschränkt zur Verfügung steht. Gerade bei Tests auf vielen Geräten steigt daher der Aufwand und die Komplexität. Möchte der Entwickler beispielsweise die Reaktion seiner Anwendung auf eine Bewegungsfolge testen, so muss er diese Bewegung mit jedem Gerät mechanisch reproduzieren, um Unterschiede zwischen den Geräten zu vermeiden. Hat ein schwaches Gerät zum Beispiel eine gewisse Trägheit beim Messen der Sensordaten, müsste dies 1 Application Store, eine digitale Vertriebsplattform von Anwendungssoftware im Internet 1

7 1. Einführung durch einen Algorithmus in der Anwendung ausgeglichen werden, um Input Lag 2 zu vermeiden Zielsetzung Zentrales Ziel dieser Arbeit ist es, eine Methode zu entwickeln, aufgenommene Sensordaten eines Gerätes so zu verändern, dass sie möglichst denen eines zweiten Gerätes ähneln und damit als Modell für dieses verwendet werden können. Dies ermöglicht es einem Anwendungsentwickler, mit nur einem einzigen aufgenommenen Datensatz das Verhalten seiner Anwendung auf mehreren Geräten testen zu können, ohne die Eingaben mehrfach zu wiederholen und die Umgebung originalgetreu zu reproduzieren. Um zu gewährleisten, dass die simulierten Daten mit denen eines echten Gerätes übereinstimmen, wird die Qualität dieser Daten anhand eines erarbeiteten Evaluierungskonzeptes überprüft und daraus das Sensormodell und die Methode verifiziert. Die Evaluierung erfordert den Vergleich mehrerer Geräte unter möglichst gleichen Umgebungsbedingungen. Daher wird eine mechanische Apparatur entwickelt, die ein Gerät reproduzierbaren Bewegungen aussetzt. Weiterhin wird untersucht, ob das verwendete Simulationssystem selbst während der Simulation der Daten auf dem Endgerät den Test zur Laufzeit beeinflussen kann. Mögliche Stärken und Limitierungen werden dabei genannt. Damit wird sichergestellt, dass die Simulationsumgebung selbst die Sensordaten beim Abspielen nicht verfälscht und die Anwendung so reagieren kann, wie sie es unter realen Sensoren täte. Mit dem so gewonnenen Einblick in Sensorsimulation unter Android wird letztendlich evaluiert, wie ein solches System den Entwicklungsprozess mobiler Anwendungen unterstützen und in die bekanntesten Vorgehensmodelle des Software Engineerings integriert werden kann Struktur der Arbeit Diese Arbeit gliedert sich in sechs Kapitel. Das zweite Kapitel beschäftigt sich mit den Grundlagen, die für das Verständnis der folgenden Konzepte hilfreich sind. Es wird ein Überblick über den bisherigen Testprozess von mobilen Anwendungen gegeben und die verwendete Simulationsumgebung erläutert. Im dritten Kapitel wird die erarbeitete Methode, um Sensordaten eines Gerätes zu modellieren, vorgestellt und ein Konzept zur Evaluierung präsentiert. Es wird auf die einzelnen Teilbereiche eingegangen und die Sensoren verschiedener Geräte werden gegenübergestellt. Die Ergebnisse der Evaluierung werden diskutiert und daraus ein Fazit gezogen. 2 Verzögerung zwischen Benutzereingabe und Reaktion auf dem Bildschirm 2

8 1. Einführung Kapitel 4 untersucht die Auswirkungen der verwendeten Simulationsumgebung auf die Zielgeräte und analysiert das Verhalten zur Laufzeit. Daraus werden mögliche Beschränkungen und Stärken des Systems abgeleitet. Das fünfte Kapitel widmet sich der Integration eines solchen Systems in den Entwicklungsprozess. Es wird ein Beispielszenario präsentiert und verschiedene Vorgehensmodelle untersucht. In Kapitel 6 werden die Ergebnisse der Arbeit zusammengefasst und es wird ein Ausblick gegeben, wie die verwendete Methode implementiert und weiterentwickelt werden kann. 3

9 2. Grundlagen 2.1. Testen sensorgebundener Applikationen Mobile Anwendungen zu entwickeln ist in vielerlei Hinsicht ähnlich zu der Softwareentwicklung von eingebetteten Geräten. Bekannte Probleme beinhalten die Integration mit der Hardware vom Gerät, die traditionellen Aspekte der Sicherheit, Performance und Verlässlichkeit [1]. Doch moderne Smartphones und Tablets stellen ein paar weitere Anforderungen, die weniger bekannt in traditioneller Software-Entwicklung sind. Mobile Anwendungen machen sehr starken Gebrauch von gemessenen Daten, die von verschiedenen Kontextanbietern kommen. Dies beinhaltet integrierte Umgebungssensoren (wie Licht-, Bewegungs- und Temperatur-Sensoren und Kamera) oder Netzwerkverbindungen (Bluetooth, GPS, WLAN, 3G-Netze) [2]. Die Qualität und der Nutzen können sich dabei je nach Umgebung und Anwendung ändern. Die eigene Anwendung muss daher in verschiedenen Situationen getestet werden, um die Bandbreite der möglichen Sensordaten, die empfangen werden können, abzudecken. Entwickelt man zum Beispiel eine Anwendung, die von der aktuellen Position abhängt, dann schließen sich weitere Fragen an. Wie verhält sich die Anwendung innerhalb von Gebäuden, wenn GPS ausfällt? Wie genau ist die Ortsbestimmung über Funknetze in Gebieten mit schlechter Abdeckung? Gerade bei ortsabhängigen Anwendungen ist ein Testen oftmals sehr aufwändig. Der Entwickler kann meist nicht einfach vor seinem Arbeitsplatz testen, sondern muss die entsprechende Testumgebung physisch aufsuchen oder Routen entlanggehen, um den Kontextwechsel seiner App zu überwachen. Außerdem können Störungen der Sensoren auftreten: Der GPS-Sensor kann je nach Signalstärke der Satelliten rapide zwischen Orten springen, ein Beschleunigungssensor ist je nach seiner Qualität unterschiedlich stark verrauscht, ein WLAN-Signal kann plötzlich von einer Störquelle behindert werden. Diese Szenarien müssen je nach Anwendung berücksichtigt werden und lassen sich schwierig unter Laborbedingungen reproduzieren. Moderne Entwicklungsumgebungen unterstützen den Entwickler schon in einer Vielzahl von Bereichen innerhalb der mobilen Anwendungsentwicklung. Viele Hersteller und Plattformen bieten ihre eigenen zugeschnittenen Werkzeuge für den Entwicklungsprozess an. Neben weit verbreiteten Funktionen wie Syntax Highlighting oder Debuggern enthalten diese oft noch weitere Werkzeuge für mobile Geräte. Das offizielle Android Studio beinhaltet zum Beispiel noch eine direkte Verbindung zum Gerät, mit dem Anwendungen sofort installiert werden und Laufzeitinformationen übertragen werden können 4

10 2. Grundlagen [3]. Zusätzlich ermöglichen es GUI-Editoren, die grafische Oberfläche auf einer Vielzahl von Geräten und Formfaktoren schon bei der Entwicklung zu sehen (siehe Abbildung 2.1). Hinzu kommen Frameworks zur Testautomatisierung wie Robotium, die automatisch Benutzeraktionen auf dem Gerät simulieren können [4]. Abbildung 2.1.: Android Studio: Simulieren der Bildschirmgrößen verschiedener Geräte Doch möchte man eine Anwendung mit Sensoren testen, stoßen diese Werkzeuge oft an ihre Grenzen. Es fehlen die nötigen Funktionen, um Sensoren zu emulieren, und der Entwickler muss wieder selbst mit dem physischen Gerät interagieren. Eine bekannte Alternative dafür ist der OpenIntents Sensor Simulator. Der Simulator verbindet sich direkt mit der Anwendung auf dem Gerät oder im Emulator und speist simulierte Sensordaten in Echtzeit ein (siehe Abbildung 2.2). Es ist ebenfalls möglich, Daten von einem Gerät aufzunehmen und unverändert wieder abzuspielen. [5] Dies deckt schon einmal eine grundlegende Funktion ab. Der Entwickler kann nun schon am Emulator während der Entwicklung Bewegungsfolgen an seine Anwendung übergeben ohne die Aktion physisch durchführen zu müssen. Eine vollständige Lösung des Sensor-Problems ist es aber nicht: Störungen des Signals oder Rauschen eines Sensors werden weiterhin nicht betrachtet und müssen in weiteren Tests abgedeckt werden. Der Entwickler muss immer noch die Umgebungsbedingungen ändern und seine Anwendung auf mehreren Geräten testen. Die Methode, die in dieser Arbeit vorgestellt wird, hat zum Ziel, diesen Aufwand zu verringern, indem die aufgenomme- 5

11 2. Grundlagen nen Daten gezielt verändert werden, um anderen Geräten entsprechen. Abbildung 2.2.: OpenIntents Sensor Simulator: Steuerung und Gerät [5] 2.2. Die Simulationsumgebung In der Lehrveranstaltung Softwareprojekt WS 2012 wurde am Fachgebiet Software Engineering eine Suite für Sensorsimulierung entwickelt, um die Entwicklung sensorgebundener Apps zu unterstützen. SensorSim besteht aus drei Komponenten: Eine Aufnahme-App dient zum Aufnehmen einer Reihe von Sensoren wie Beschleunigungssensor, WLAN-Netzen und GPS auf dem Zielgerät. Eine Upload- Funktion ermöglicht es, die aufgenommenen Daten sofort hochzuladen. Ein Web-Repository verwaltet alle hochgeladenen Datensätze in einer Datenbank und ermöglicht es, die Daten mit Rauschen zu versehen. Eine Abspiel-Library kann in die eigene Anwendung integriert werden, um Daten vom Webserver zur Simulierung von Sensoren zu verwenden. Ein Entwickler, der eine mobile Anwendung entwickeln möchte, kann mit Hilfe der Aufnahme-App entsprechende Sensordaten aufnehmen. Für eine ortsbasierte App 6

12 2. Grundlagen Abbildung 2.3.: Überblick über die Komponenten von SensorSim kann dies zum Beispiel eine Reihe von GPS-Positionen sein, während das Gerät von einem Ort zu einem anderen getragen wird. Für eine Anwendung, die den Beschleunigungssensor zur Orientierung verwendet, wie z.b. eine Wasserwaagen-App, könnten Beschleunigungsdaten aufgenommen werden. Nachdem die Aufnahme gestoppt wurde, werden die Daten ins Repository hochgeladen. Im Repository werden alle bisherigen Daten verwaltet und können nach bestimmten Kriterien eingegrenzt werden. So kann der Entwickler auf Daten aus anderen Projekten, z.b. verrauschte Daten anderer Geräte, zugreifen. Zusätzlich gibt es die Möglichkeit, die Daten mit einem einfachen additiven weißen gaußschen Rauschen (AWGN) zu versehen. Damit kann die eigene App unter verschiedenen Störeinflüssen getestet werden. Indem die Abspiel-Library in die eigene Anwendung integriert wird, können die Daten wieder abgespielt werden. Die Bibliothek verbindet sich mit dem Repository und wartet auf Daten, die auf dem Server ausgewählt wurden. Die Datensätze werden auf Gerät oder den Emulator gestreamt und sind über Klassen wie SensorManager, die den Klassen von Android nachgebildet sind, verfügbar. Der Entwickler muss seinen Code nur minimal anpassen, damit die Klassen von SensorSim statt den Android-eigenen benutzt werden (siehe Listing 2.1). Listing 2.1: Einbindung von SensorSim in eigene Applikation 1 / / Verwende Android Service 2 / / SensorManager sensormanager = ( SensorManager ) getsystemservice ( Context. SENSOR_SERVICE) ; 3 4 / / Verwende SensorSim 5 SensorSim sim = SensorSim. getinstance ( this, " mydevice " ) ; 6 Sensormanager sensormanager = ( SensorManager ) sim. getsystemservice ( Context. SENSOR_SERVICE) ; 7 8 / / R e g i s t r i e r e L i s t e n e r 9 sensormanager. r e g i s t e r L i s t e n e r ( mylistener, sensormanager. getdefaultsensor ( Sensor.TYPE_ACCELEROMETER), sensormanager. SENSOR_DELAY_NORMAL) ; 7

13 2. Grundlagen SensorSim ermöglicht eine bessere Verwaltung der Daten mehrerer Geräte und bietet einfache Möglichkeiten zum Hinzufügen von Rauschen, aber löst das zentrale Problem bei der Entwicklung sensorgebundener Apps nicht: der Entwickler muss weiterhin von vielen unterschiedlichen Geräten die notwendigen Daten erfassen, um seine App damit testen zu können. Abbildung 2.4.: SensorSim Aufnahme-App Abbildung 2.5.: SensorSim Web-Repository 8

14 2. Grundlagen 2.3. Beschleunigungssensoren Die nächsten Kapitel konzentrieren sich nur noch auf einen bestimmten Sensor mobiler Geräte, den Beschleunigungssensor (engl. Accelerometer). Die erläuterten Konzepte können in unterschiedlichem Umfang auch auf andere Sensoren angewendet werden. Der Beschleunigungssensor ist von den verfügbaren Sensoren allerdings aufgrund mehrerer Eigenschaften für die Simulation am interessantesten und wichtigsten: Er gehört zur Grundausstattung eines jeden modernen Mobilgerätes, wodurch über eine große Reihe an Geräten getestet werden kann. Das Rauschen ist im Wesentlichen sensor-inhärent und daher abhängig vom Gerätemodell im Vergleich zu umweltgestörten Sensoren wie GPS oder WLAN. Damit lassen sich gut Unterschiede zwischen Geräten feststellen und Umwelteinflüsse minimieren, was die Modellierung vereinfacht. Der Sensor liefert sowohl Orientierungs- als auch Bewegungsdaten und findet dabei in vielen Apps Verwendung, z.b. als Eingabemethode oder für Bildschirmrotation. Die Daten werden in wenigen Millisekunden kontinuierlich bereitgestellt und nicht erst auf Anfrage, womit sich die Performance des Systems gut testen lässt. Die Umweltbedingungen lassen sich einfach kontrollieren, da das Gerät lediglich standardisiert bewegt werden muss. Abbildung 2.6.: Koordinatensystem in Android [6] Auf den Beschleunigungssensor in Android wird zugegriffen, indem über den Sensor- Manager ein neuer Listener registriert wird. Um Rechenzeit und Strom zu sparen, kann dabei die Rate, mit der die Anwendung über neue Werte informiert wird, limitiert werden: SENSOR_DELAY_FASTEST: 0 ms Verzögerung, kein Limit SENSOR_DELAY_GAME: 20 ms Verzögerung SENSOR_DELAY_UI: 60 ms Verzögerung SENSOR_DELAY_NORMAL: 200 ms Verzögerung 9

15 2. Grundlagen Der Sensor informiert die Anwendung über neue Daten, indem der Listener mit der Methode onsensorchanged() aufgerufen wird und übergibt ein Objekt mit dem Zeitpunkt in ns, der Genauigkeit und den X,Y,Z-Beschleunigungswerten in ms 2 [6]. Nach [7] kann ein Modell, welches ein Accelerometer und sein Rauschen beschreibt, folgendermaßen formuliert werden: a x = x + c x + b x + w accel : (2.1) Hierbei ist a x der zurückgegebene Wert, der sich aus der tatsächlichen Beschleunigung (x), einem konstanten Offset (c x ), einem wandernden Bias (b x ) und einem weißen Sensorrauschen (w accel ) zusammensetzt. Im späteren Verlauf dieser Arbeit wird versucht, aus den erhaltenen Daten a x die tatsächliche Beschleunigung x möglichst rauschfrei zu rekonstruieren. 10

16 3. Evaluierungskonzept und Durchführung In diesem Kapitel werden die Beschleunigungssensoren verschiedener Android-Geräte miteinander verglichen und daraus eine Methode entwickelt, Sensordaten eines Gerätes so zu modifizieren, dass sie denen eines anderen Gerätes gleichen. Zur Überprüfung dieser Methode wird ein Evaluierungskonzept entwickelt, anhand dessen die Güte der modellierten Daten bestimmt werden kann. Die Methode ermöglicht es, in einer Sensor-Simulationsumgebung mehrere Geräte mit einem einzelnen Datensatz zu simulieren. Dies ist eine notwendige Funktionalität, damit eine Evaluation einer solchen Umgebung im Kontext mobiler Anwendungsentwicklung überhaupt sinnvoll ist Beschreibung des Vorgehens zur Evaluierung Die grundlegende Idee, wie man die Sensordaten eines Gerätes simuliert, ist relativ simpel. Man zeichnet mit einem anderen Gerät, welches zur Verfügung steht, die gewünschte Bewegungsfolge auf. Diese Bewegung richtet sich nach dem Ziel in der Entwicklung der eigenen Anwendung. Dies kann z.b. ein Orientierungswechsel des Gerätes vom Hoch- ins Querformat sein oder eine Schüttelbewegung. Nun entfernt man das Rauschen des Gerätes im aufgezeichneten Datensatz, z.b. durch Mittelung mehrerer Bewegungsfolgen oder Glättung mittels Tiefpassfilter. Hieraus erhält man normalisierte Daten, die möglichst nah an den tatsächlichen Beschleunigungswerten sind und keine vom Gerätesensor eingebrachten Störungen oder zeitlichen Verzögerungen enthalten. Diese bereinigte Bewegungsfolge enthält nun im Idealzustand die grundlegende Bewegung, mit der man die eigene Anwendung testen möchte, aber keine sensorabhängigen Verunreinigungen eines bestimmten Gerätes. Im nächsten Schritt wird diesen Daten nun wieder Rauschen hinzugefügt, diesmal mit den Merkmalen der Sensoren anderer Geräte (im folgenden Sensorprofil genannt), um den Einfluss der jeweiligen Sensoren zu simulieren. Am Ende erhält man aus der einzelnen aufgenommenen Bewegung n verschiedene geräteabhängige Bewegungen, die mehr oder weniger stark von Rauschen beeinflusst sind, je nach der Qualität und Bauweise des Sensors. Die Sensorprofile der einzelnen Geräte lassen sich in einer Datenerhebungsphase ermitteln, die im nächsten Abschnitt erläutert wird. 11

17 3. Evaluierungskonzept und Durchführung Datenerhebung Um die Sensoren verschiedener Geräte miteinander vergleichen zu können, müssen am Anfang erst einmal Daten gesammelt und ausgewertet werden. Die verwendeten Geräte sollten dabei ein breites Spektrum des Marktes abdecken. Für diese Arbeit wurden sechs Smartphones verschiedener Hersteller getestet, die von der ersten Android-Generation bis zu den aktuellen Martkführern reichen. Tabelle 3.1.: Übersicht über die verwendeten Geräte Hersteller Gerät Erscheinungsjahr Android-Version Firmware HTC Dream Stock LG P Stock LG P CyanogenMod Samsung Galaxy S II CyanogenMod Samsung Galaxy S Stock HTC One Stock In einer ersten Datenerfassung werden die Ausgabewerte der Beschleunigungssensoren aller Geräte in der Ruhelage über einen Zeitraum von ein paar Minuten gemessen (siehe Abbildung 3.1). Damit lassen sich sensor-inhärente Parameter wie die Samplingrate, Auflösung und die Verteilung des Rauschens bestimmen. Damit die Sensorparameter möglichst unverfälscht bestimmt werden können, müssen die Geräte in einer kontrollierten Umgebung getestet werden und externe Einflüsse auf ein Minimum reduziert werden. Um Störungen von außerhalb zu erkennen, werden die Sensordaten mehrerer Geräte parallel zum gleichen Zeitpunkt aufgenommen. Sollte ein externes Ereignis also das Gerät beschleunigen, wäre dieses in den Aufnahmen aller Geräte zu sehen. Die Geräte werden alle mit der gleichen Version der Aufnahme-App von SensorSim bespielt, welche die Beschleunigung misst, der das Gerät über einen Zeitraum ausgesetzt wird, und diese Datenreihe abspeichert. Die Messrate des Beschleunigungssensors wird im SensorManager von Android dabei mit SENSOR_DELAY_FASTEST konfiguriert, wodurch Android die Signale des Sensors so schnell wie möglich an die Anwendung sendet [6]. Die Aufnahmereihen aller Geräte werden anschließend mehrmals wiederholt, um einmalige Faktoren und Diskrepanzen wie Temperaturschwankungen oder externe Stöße in einer einzigen Reihe zu erkennen. Dies reduziert einen Einfluss der Umgebungsbedingungen, da es darum geht, nur Merkmale des Sensors selbst zu identifizieren. 12

18 3. Evaluierungskonzept und Durchführung Abbildung 3.1.: Aufnahme von Sensordaten In Abbildung 3.2 werden die gemessenen Beschleunigungsdaten aller Geräte in Ruhelage gezeigt. Schon bei einfacher Betrachtung sind die Unterschiede zwischen den Sensoren der einzelnen Geräte deutlich erkennbar. Sie unterscheiden sich stark in Stärke und Frequenz des Rauschens, Steigung und generellem Verlauf. Ebenso weicht der nahezu gerade, stufige Verlauf der beiden HTC-Geräte vom eher schwankenden Verhalten der anderen Geräte stark ab Evaluierungskonzept Nachdem im ersten Schritt die notwendigen Sensordaten gesammelt wurden, lässt sich nun in mehreren Schritten der Sensor anhand des Sensorprofils eines Zielgerätes nachbilden. Die so simulierten Beschleunigungsdaten werden nun mit den Originaldaten des Gerätes, dessen Sensorprofil verwendet wurde, verglichen. Berechnet man die Differenz der beiden Datensätze, lässt sich der mittlere Fehler der Näherung zu den Originaldaten berechnen, welcher als Gütekriterium dient. In Abbildung 3.3 sind die einzelnen Schritte des Konzeptes verdeutlicht. In einem er- 13

19 3. Evaluierungskonzept und Durchführung Abbildung 3.2.: Ausschnitt: Ruhebeschleunigung einiger Geräte sten Schritt wird von einem Referenzgerät A eine Bewegungsfolge aufgenommen. Die so erhaltenen Daten enthalten noch Rauschen und Verzögerungen, die durch die Aufnahme mit Gerät A bedingt sind. In einem Normalisierungsschritt werden diese Störelemente entfernt, um den bereinigten Datensatz zu erhalten. Anschließend wird das Rauschen eines Gerätes B nach dessen vorher ermittelten Sensorprofils hinzugerechnet, um die mittels Gerät A simulierten Daten von Gerät B zu bekommen. In einem zweiten Schritt wird mit Gerät B dieselbe Bewegungsfolge aufgenommen, welche als Referenz für unsere Simulation dient. Die Qualität der Simulation wird im dritten Schritt berechnet, indem die mittlere Abweichung der beiden Datensätze ermittelt wird. Diesen Fehler gilt es zu minimieren, da die Simulation möglichst nah am Originalgerät liegen soll. Der mittlere Fehler berechnet sich nach [9] folgendermaßen: m x = 1 n n je i j = 1 n i=1 n jx A (i ) x B (i )j (3.1) i=1 Die Simulation wird als erfolgreich gewertet, wenn der mittlere Fehler der simulierten Beschleunigungsdaten jx A (i ) x B (i )j zu Gerät B kleiner ist als der Fehler zu Gerät A. Dies bedeutet, dass unsere Simulation objektiv eher mit Daten, wie man sie von Gerät B bekommen würde, übereinstimmt als mit Daten von Gerät A. 14

20 3. Evaluierungskonzept und Durchführung Abbildung 3.3.: Evaluierungskonzept Referenzbewegung Für den Vergleich der Sensordaten zweier Geräte muss die Umgebung möglichst exakt zwischen Tests reproduzierbar sein. Im Falle des Beschleunigungssensors bedeutet dies, dass er einer immer gleichen Bewegungsfolge ausgesetzt werden muss. So lässt sich bestimmen, welche Werte des Sensors durch externe Einflüsse bestimmt werden und welche durch das Gerät selbst verursacht werden. Als Prototyp wurde mit LEGO Mindstorms eine Apparatur entworfen, die eine solche Referenzbewegung erzeugen kann. Die Anforderungen daran waren: Erzeugung einer linearen Bewegung, da diese im Vergleich zu einer Rotation unabhängig von der Position des Accelerometers immer die gleichen Daten liefert. Erzeugung einer Sinusbewegung zur leichteren Auswertung und Modellierung. externe Stromversorgung, um allmähliches Verlieren der Batteriespannung zu verhindern. das Gewicht des Gerätes muss gehalten werden können, ohne dass dadurch die Bewegung beeinträchtigt bzw. verlangsamt wird. 15

21 3. Evaluierungskonzept und Durchführung Der Motor erzeugt eine 1 Hz-Sinus-Bewegung auf der Y-Achse des Gerätes. Es stellte sich bei dem Vergleich mehrerer Geräte allerdings heraus, dass noch weitere Unterschwingungen auftraten, die sich zwischen den Testreihen änderten und durch Vibrationen des Aufbaus erzeugt wurden. Das Konzept wurde so modifiziert, dass das Referenzgerät und das zu simulierende Gerät beide übereinander auf die Apparatur gelegt werden, damit beide die gleichen Vibrationen erfahren. Dies erhöht zwar das Gewicht und macht die Apparatur damit anfälliger gegenüber Vibrationen, aber führt zu einer besseren Vergleichbarkeit der Geräte. Bevor die Daten verglichen werden können, müssen noch die Zeiten synchronisiert werden. Die Aufnahmen auf beiden Geräten sind leicht gegeneinander verschoben, da der Aufnahmeprozess manuell gestartet wird. Dies lässt sich erreichen, indem bei Variation der Verschiebung der Datensätze zueinander der mittlere Fehler minimiert wird, analog zu Schritt 3 des Konzeptes. Abbildung 3.4.: Apparatur zur Erzeugung einer Referenzbewegung 16

22 3.2. Sensormodellierung 3. Evaluierungskonzept und Durchführung Wie sich im Laufe der Arbeit gezeigt hat, muss das verwendete Sensormodell bei Android-Geräten durch ein paar zusätzliche Elemente erweitert werden. Wie aus der vorherigen Abbildung 3.2 der Ruhebeschleunigung zum Teil ersichtlich war, unterliegt nicht jedes Gerät einem reinen weißen Rauschen, wie im bisherigen Modell eines Beschleunigungssensors angenommen wurde. Stattdessen scheinen die Beschleunigungsdaten im Gerät zusätzlich modifiziert zu werden: Abbildung 3.5.: Erweitertes Sensormodell Filter: Ein lineares Filter, welches das Signal glättet. Quantisierung: Diskretisiert die gemessenen Werte in bestimmte Zahlenwerte, bestimmt durch die Sensorauflösung. Verzögerung: Zeitliche Unregelmäßigkeiten in der Abfolge der Werte, die durch den verwendeten Sensor und Android bedingt sind. Diese zusätzlichen Einflüsse ergeben sich vermutlich durch die Verwendung von kostengünstigen Accelerometern für Endkunden statt Sensoren, wie sie in der Industrie verwendet werden. Gleichzeitig können die Hersteller die Sensoren über die Firmware im Gerät auf mehrere unterschiedliche Betriebsmodi setzen, die die Bandbreite und damit die Filterqualität und das Intervall zwischen Messwerten regulieren [11][12]. Die benötigten Eigenschaften der Sensoren sind überwiegend nicht in den Datenblättern der Hersteller zu finden. Viele werden auch vom Android-Betriebssystem beeinflusst. Darüber hinaus ist oftmals nicht bekannt, welches Sensormodell in dem jeweiligen Mobilgerät verbaut ist. Daher wird in diesem Abschnitt im Detail erläutert, wie die Sensorprofile in den einzelnen Stufen ermittelt werden können und Beschleunigungsdaten mit so einem Profil wieder verrauscht werden können. Die Schritte folgen dabei der Reihenfolge, die im vorherigen Modell festgelegt wurde Normalisierung Da die gemessenen Beschleunigungsdaten eines Gerätes bereits verrauscht sind, gilt es in einem ersten Schritt, diese wieder zu normalisieren und möglichst auf die Originalbewegung zurückzuführen, wie sie ohne Einfluss durch das Gerät aussehen würde. Zuerst müssen die Zeitabstände zwischen den einzelnen Messwerten normalisiert werden. Durch geräteabhängige Verzögerungen schwanken diese um eine bestimmte 17

23 3. Evaluierungskonzept und Durchführung Rate. Die Normalisierung wird durchgeführt, indem die Werte zu äquidistanten Zeitpunkten interpoliert werden. In dieser Arbeit wird immer mit einem Zeitabstand von 10 ms gearbeitet, da dieser der Rate des schnellsten Gerätes entspricht, dem Galaxy S4. Im nächsten Schritt gilt es, die Sensordaten von geräteabhängigem Rauschen zu bereinigen. Im Frequenzspektrum der Sensordaten ist die mit der Testapparatur erzeugte Referenzbewegung bei ca. 1 Hz deutlich erkennbar (siehe Abbildung 3.6). Ebenso erkennt man weitere Ausschläge um 10 Hz herum, die auf Vibrationen der Apparatur hindeuten. Da diese durch den Testaufbau und damit die Umgebung erzeugt wurden, zählen sie ebenfalls zu unserer Referenzbewegung und müssen berücksichtigt werden. Das Rauschen des Gerätes wird als deutlich höherfrequent als eine normale Bewegung des Geräts angenommen, also lässt sich mit einem Tiefpassfilter das Rauschen herausfiltern. Die Cutoff-Frequenz des Filters richtet sich nach der durchgeführten Bewegung und lässt sich am Spektrum ablesen, da die Stärke des Rauschens deutlich geringer ausfällt als die der Referenzbewegung. Man erhält die bereinigten Daten, frei von Geräterauschen (siehe Abbildung 3.7). Abbildung 3.6.: Frequenzspektrum des Galaxy S4 bei Referenzbewegung 18

24 3. Evaluierungskonzept und Durchführung Abbildung 3.7.: Ausschnitt: Tiefpassgefilterte Sensordaten bei 13 Hz Glättung Bei vielen älteren Modellen lassen sich im Vergleich zum Galaxy S4 Anzeichen finden, die darauf hindeuten, dass das Signal geglättet wird, bevor es die Anwendung erreicht. Dies erkennt man dadurch, dass die Schwingung des Gerätes nicht den vollen Ausschlag vom S4 erreicht und einen flacheren Verlauf hat, da es auf schnelle Beschleunigungsänderungen nicht direkt reagiert. Dieses Glättungsfilter wirkt sich sehr stark auf das Signal aus und ist daher am genauesten zu modellieren. In dieser Arbeit wurde die Glättung durch ein Moving-Average- Filter angenähert [10]. Dieser mittelt die letzten n Werte innerhalb eines Zeitraumes und gibt diesen Mittelwert zurück. Um die Länge des Moving-Average-Filters zu bestimmen, wurden der Zeitraum variiert und der Verlauf des erhaltenen Signals in Bezug auf Amplitude und Steigung mit den Originaldaten verglichen. Man sieht, dass die LG P500s und das HTC Dream geglättet werden, während neuere Modelle keine Glättung aufweisen und die Daten sofort zurückgeben. Ein Beispiel für die Glättung sieht man später in Abbildung 3.9, bei dem die Sensordaten des S4 mit einem 70 ms-moving-average-filter geglättet wurden. 19

25 3. Evaluierungskonzept und Durchführung Tabelle 3.2.: Glättungsparameter Gerät Zeitraum in ms HTC Dream 70 HTC One 0 LG P500 Stock 80 LG P500 CM 80 Galaxy S II 0 Galaxy S Auflösungsquantisierung der Beschleunigung Jeder Sensor kann nur einen bestimmten Bereich von Messwerten abdecken und diese Zahlenwerte sind diskret verteilt. Die Auflösung gibt dabei die minimalen Abstände zwischen den verschiedenen Beschleunigungswerten an. Da diese zwischen verschiedenen Geräten wieder stark unterschiedlich ausfällt, sollte sie ebenfalls modelliert werden. Die Auflösung eines Gerätes kann leicht berechnet werden, indem die minimale Differenz zwischen einer Reihe von Beschleunigungswerten bestimmt wird. Über mehrere Testreihen sollte dieser Wert pro Gerät identisch sein. Die folgende Tabelle zeigt die Ergebnisse für die jeweiligen Geräte, errechnet aus 10 Testreihen in Ruhelage und unter Einfluss der Referenzbewegung: Tabelle 3.3.: Ermittelte Auflösungen der Geräte Gerät Auflösung in ms 2 Gerät Auflösung in ms 2 HTC One HTC Dream LG P500 Stock LG P500 CM Galaxy S II Galaxy S Auffallend ist, dass beide HTC-Geräte von 2008 und 2013 deutlich schlechtere Auflösungen haben als die anderen Geräte. Der Unterschied ist gut erkennbar in der folgenden Abbildung 3.8. Beim Galaxy S4 streuen sich die Beschleunigungswerte herum um den Nullpunkt und bilden eine Normalverteilung um den realen Wert, welche aufgrund des weißen Rauschens im Sensor zu erwarten wäre. Das HTC One zeigt ein anderes Bild: Aufgrund der niedrigen Auflösung des Sensors gibt es nur zwei Werte, zwischen denen der Sensor wechselt. Das weiße Rauschen wird fast vollständig verdeckt. 20

26 3. Evaluierungskonzept und Durchführung Falls das genaue Modell des Sensors bekannt ist, lässt sich die Auflösung auch im dazugehörigen Datenblatt finden. Das Datenblatt vom BMA250, welcher im HTC One Verwendung findet, gibt die Auflösung mit 3:91mg an, welche umgerechnet dem Wert von den gemessenen 0:038307ms 2 entspricht [12]. Abbildung 3.8.: Verteilung der Beschleunigungswerte in Ruhelage Die Auflösung lässt sich leicht modellieren, indem die bereinigten Daten auf die jeweilig nächsten Auflösungsstufen gerundet werden. x x r es = r ound( ) r esolution (3.2) r esolution Zeitliche Abstände zwischen Messwerten Je nach Gerät werden die Werte auch in unterschiedlichen Zeitabständen geliefert. Diese lassen sich ebenfalls leicht bestimmen, indem die Differenz zwischen benachbarten Zeitpunkten der Datenreihe gebildet wird. Auch hier zeigen sich wieder deutliche Unterschied zwischen den HTC-Modellen und den restlichen Geräten (siehe Tabelle 3.4). Während die anderen Geräte mehr oder weniger genau alle 10 ms neue Sensordaten liefern, sind die zeitlichen Abstände bei den HTC-Geräten deutlich größer und sie schwanken auch stärker. Ebenfalls verändern sie sich je nach Umgebung: wird das Gerät einer Beschleunigung ausgesetzt, liefert es öfters Daten. Bei diesen Gerät findet vermutlich ein Thresholding 1 statt, bei dem die Software erst über neue Beschleunigungswerte informiert wird, wenn eine bestimmte Schwelle überschritten wird [8]. Dies erklärt die höheren Verzögerungen in Ruhelage gegenüber der Referenzbewegung, wo die Schwelle häufiger überschritten wird. 1 Schwellwertverfahren. Ein Wert wird erst als anders vom vorherigen angenommen, wenn er um einen bestimmten Betrag von ihm abweicht. 21

27 3. Evaluierungskonzept und Durchführung Tabelle 3.4.: Mittlere zeitliche Abstände Gerät Abstand in ms bei Ruhelage Abstand in ms bei Ref.-Bewegung HTC Dream HTC One LG P500 Stock LG P500 CM Galaxy S II Galaxy S Verzögerungen bei den Zeitabständen können für Geräte ohne Thresholding simuliert werden, indem die Zeitpunkte zu festen Abständen interpoliert und mit einer Normalverteilung gemäß der berechneten Standardabweichungen verzögert werden. Bei Geräten mit Thresholding müssen in einem zusätzlichen Schritt Datenpunkte verworfen werden, wenn die Differenz zum vorherigen Wert geringer als der Schwellwert ist Evaluierung Für die Evaluierung wurde die Methode wie oben genannt durchgeführt. Das Galaxy S4 wurde als Ausgangspunkt für die zu simulierenden Daten gewählt, da es anhand der aufgenommenen Sensorprofile die höchste Auflösung, die präzisesten Zeitabstände bietet und kein interner Filtervorgang erkennbar ist, der die Daten verfälschen würde. Jedes andere Gerät wurde anschließend in mehreren separaten Testreihen zusammen mit dem Galaxy S4 auf die Testapparatur gelegt und der 1 Hz-Referenzbewegung ausgesetzt. Gleichzeitig zeichnete die Aufnahme-App von SensorSim die Sensordaten auf beiden Geräten auf. Die vom Galaxy S4 erhaltenen Daten wurden nun dem entwickelten Verfahren unterzogen. Zuerst wurde anhand des Spektrums ein Tiefpassfilter von 20 Hz gewählt (siehe Abbildung 3.6), um die normalisierte Referenzbewegung ohne Rauschen zu erhalten. Die Referenzbewegung wurde nun den einzelnen Stufen der geräteabhängigen Glättung, Auflösungsquantisierung und Zeitverzögerung unterzogen. Das erhaltene simulierte Signal wurde letztendlich mit den aufgenommenen Originaldaten des jeweiligen Gerätes verglichen und der mittlere Fehler bestimmt. Dieser Fehler ist in Tabelle 4.1 für die einzelnen Geräte aufgeführt. Einen Ausschnitt der simulierten Daten sieht man für das HTC Dream in Abbildung 3.9. Der Fehler S4 zu Original bezeichnet die Nähe der beiden Rohdaten ohne Verände- 22

28 3. Evaluierungskonzept und Durchführung Tabelle 3.5.: Qualität der mit Galaxy S4 simulierten Daten Gerät Fehler zu Original Fehler zu S4 S4 zu Original Verbesserung in ms 2 in ms 2 in ms 2 HTC Dream % HTC One % LG P500 Stock % LG P500 CM % Galaxy S II % rungen zueinander. Er dient als Kontrollwert und beschreibt, wie ähnlich die Sensordaten des Gerätes zum Galaxy S4 sind. Die beiden anderen Fehlerwerte sind die Vergleichswerte der erhaltenen Simulation zu den jeweiligen Geräten. Wenn also der Fehler zu Original geringer als der Vergleichswert S4 zu Original ist, so haben wir mit der Methode eine Verbesserung erzielt: die simulierten Daten sind ähnlicher zu den Originaldaten als zu denen des Galaxy S4. Analog dazu erwarten wir eine Vergrößerung des Fehlers zu S4, da unsere Simulation nicht mehr den Daten des S4 entspricht. Ist der Fehler zum Original letztendlich sogar kleiner als der zum S4, so kann man davon sprechen, dass die simulierten Daten eher zu dem zu simulierenden Gerät passen als zum S4 und das Ziel ist erfüllt. Man sieht, dass beim HTC Dream, dem ältesten Gerät, die Methode sehr gut funktioniert. Bei den beiden LG P500 lässt sich ebenfalls eine erkennbare Verbesserung zeigen. Auch wenn der Fehler zum Original längst nicht so niedrig ist, ist er dennoch ausreichend. Beim HTC One funktioniert die Methode nur geringfügig, sie verbessert zwar die Daten (Fehler zu Original kleiner als Vergleichswert) und entfernt sich von den aufgenommenen S4-Daten (Fehler zu S4 größer als 0), aber diese Veränderung ist nicht wesentlich (Fehler zu S4 überwiegt nicht gegenüber Fehler zu Original). Beim Galaxy S II zeigt sich, dass die Methode nicht funktioniert: Auch wenn der Fehler zum S4 größer wird, ist auch der Fehler zum Original gewachsen und nun größer als der Vergleichswert. Anhand der Rohdaten in der Datenerhebungsphase ließ sich erkennen, dass den größten Einfluss auf die Sensordaten im Wesentlichen der interne Glättungsfilter des Gerätes hat. Dies ist auch aus Abbildung 3.9 ersichtlich, wo die Schwankungen des HTC Dream deutlich schwächer und länger ausfallen als beim Galaxy S4. Da dieser Filter bei den älteren Geräten gut zu modellieren ist, sind auch die simulierten Daten entsprechend nah am Original. Bei moderneren Geräten ohne Glättungsfilter (wie dem Galaxy S II) versagt die Näherung, da die Unterschiede sowieso geringer sind und die Methode somit nur zusätzliche Störungen hinzufügt. 23

29 3. Evaluierungskonzept und Durchführung Abbildung 3.9.: Ausschnitt: Simulation des HTC Dream aus Galaxy S4 Letztendlich können aber durch die Auflösungsquantisierung und die Zeitverzögerungen wenigstens ein paar Unterschiede vom Galaxy S II zum Galaxy S4 modelliert werden. Die Methode zeigt also, dass es insbesondere bei älteren Geräten möglich ist, sie durch andere Geräte zu simulieren und liefert einen Ansatz, um dies zu erreichen. Zusätzlich können die gewonnen Sensordaten können in der Entwicklung der eigenen Anwendung hilfreich sein, um einen Filter zu entwerfen, der gerätespezifisches Rauschen entfernt. 24

30 4. Leistungsanalyse der Simulation Für eine vollständige Evaluation einer Sensor-Simulationsumgebung im Testprozess ist es wichtig, zu untersuchen, ob diese die Testergebnisse selbst beeinflusst. Wenn sich die Simulationsumgebung zur Laufzeit negativ auf die Anwendung auswirkt, beispielsweise durch zuviel CPU- oder Speicherverbrauch, spiegelt das Testergebnis nicht mehr notwendigerweise den Test auf einem realen Gerät wider. Aus diesem Grund wird die Performance einer mobilen Anwendung gemessen, die die Simulationsumgebung auf einem Gerät benutzt, und mit derselben Anwendung verglichen, wenn diese die Sensordaten vom Android-Betriebssystem erhält. Als Simulationsumgebung wird die Abspielbibliothek-Komponente von SensorSim verwendet, die in die eigene Anwendung integriert wird Auswahl eines Profilers Um Laufzeitinformationen zu messen, während eine Anwendung auf dem Gerät läuft, wurde eine Android-Anwendung gesucht, die solche Informationen aufzeichnet. Die folgenden Auswahlkriterien standen dabei im Vordergrund: Messung von System-Informationen: Gesamte Speicher- und CPU-Auslastung, Netzwerk- und Batteriestatus Messung von Anwendung-Informationen: CPU-Verbrauch, Speicherauslastung (Heap-Größe) Daten-Export in ein einfaches Format zur Auswertung Kontinuierliche Messung in niedrigem Intervall von wenigen Sekunden Ausgewählt wurde letztendlich die Profiling-Anwendung Diagnosis [13], die alle oben genannten Punkte erfüllt. Die Anwendung legt eine SQLite-Datenbank an, in der alle Messdaten einfach verfügbar und einsehbar sind Durchführung Als Beispielanwendung zum Messen der Simulation wurde die SensorSim-Aufnahme- App gewählt, da diese bereits von mehreren Sensoren Gebrauch macht und der Quellcode zur Verfügung steht. In der Anwendung werden alle Aufrufe von Android-Sensorfunktionen durch Aufrufe der SensorSim-Abspielbibliothek ersetzt. Die Verzögerung zwischen Messwerten wird im System auf SENSOR_DELAY_GAME gesetzt, welches ungefähr 25

31 4. Leistungsanalyse der Simulation Abbildung 4.1.: Profiler: Diagnosis [13] 20 ms zwischen Messwerten entspricht. Dadurch werden Sensordaten nicht mehr von den Sensoren des Gerätes aufgezeichnet, sondern von der Simulation von Sensor- Sim. Die erhaltene Anwendung wird anschließend auf jedem Mobilgerät installiert. Ebenfalls wird die Profiling-Anwendung Diagnosis installiert und der Messvorgang gestartet. In der Abspielbibliothek wird ein Datensatz ausgewählt, der die 1Hz-Referenzbewegung des jeweiligen Gerätes aus dem vorherigen Kapitel enthält und anschließend die Aufnahme gestartet. Nach ein paar Minuten werden beide Vorgänge angehalten. Anschließend wird der Vorgang mit einer unmodifizierten Variante der Aufnahme-App wiederholt, die die Sensordaten von den realen Sensoren aufzeichnet. Dies dient als Vergleichswert. Die Messungen werden für jedes Gerät mehrmals wiederholt. 26

32 4. Leistungsanalyse der Simulation 4.3. Auswertung Für jedes Gerät werden anschließend die gemessenen Laufzeitinformationen der simulierten Anwendung mit denen der normalen Anwendung verglichen. Die Werte sind in der folgenden Tabelle dargestellt: Tabelle 4.1.: Laufzeitinformationen der Simulierung Gerät CPU simuliert CPU real Speicher simuliert Speicher real HTC Dream 34.1% 28.4% MB MB HTC One 7.9% 7.0% MB MB LG P500 Stock 27.2% 23.9% MB MB LG P500 CM 26.8% 21.7% MB MB Galaxy S II 12.5% 10.9% MB MB Galaxy S 4 7.3% 6.4% MB MB Bei allen Geräten steigt die CPU-Auslastung um wenige Prozent an, aber lastet das Gerät in keinster Weise aus. Im Speicherverbrauch ist die Erhöhung sichtbarer und beträgt im Regelfall um die 7-10 MB. Durch die Einbindung der Simulationsbibliothek und ein Zwischenspeichern der zu simulierenden Daten ist ein gewisser Anstieg zu erwarten. Da die Anwendung weiterhin ohne Einschränkungen Sensordaten aufzeichnen konnte, schien dies aber nicht zu Problemen zu führen. Die CPU-Auslastung der Simulation wird im Wesentlichen durch das Intervall zwischen Messwerten des SensorManagers (regelbar in der Anwendung) bestimmt, da eine höhere Folge von Messwerten mit mehr Rechenaufwand verbunden ist. Die Speicherauslastung hängt davon ab, wie groß die zwischengespeicherten Sensordaten sind. Dies kann reduziert werden, indem der Abstand zwischen Zugriffen vermindert wird, bei denen SensorSim neue Sensordaten vom Repository holt. 27

33 5. Integration in den Entwicklungsprozess Im folgenden Kapitel wird betrachtet, wie ein Sensor-Simulationssystem den Entwicklungsprozess unterstützen und in welchen Phasen es Anwendung finden kann. Da die Simulation die Sensoren eines Gerätes ersetzen soll, lassen sich mögliche Einsatzmöglichkeiten dort finden, wo man zu einem richtigen Gerät greifen würde, um die Sensoren zu benutzen. Dies findet vor allem in zwei Phasen statt: Integrationstests: Einzelne Module der Anwendung werden kombiniert und als Gruppe getestet. Systemtests: Die gesamte, integrierte Anwendung wird getestet. Eine Simulation kann unter Umständen besser als das reale Gerät geeignet sein, auch wenn sie immer nur eine Näherung bietet. Dies kann der Fall sein, wenn das Gerät aktuell nicht zur Verfügung steht (z.b. in einem anderen Projekt gebraucht wird).... sich die Umgebung nur schwierig kontrollieren lässt (z.b. durch kontextbezogenen Ortswechsel).... die Eingabe deterministisch und reproduzierbar sein muss (z.b. beim Testen bekannter Fehler).... die Funktionsweise der Anwendung bei unterschiedlich starken Störungen sichergestellt werden soll.... die Funktionsweise der Anwendung auf unterschiedlichen Geräten sichergestellt werden soll Black-Box-Test Ein Test mit einer Sensor-Simulationsumgebung funktioniert in der Regel nach Art des Black-Box-Prinzips. Ein Black-Box-Test dient der Anforderungsüberdeckung und läuft ohne Wissen über die Funktionsweise der eigenen Anwendung ab. Die Testfälle, und damit Eingabe und erwartete Ausgabe, ergeben sich damit nur aus der Spezifikation [14]. Die möglichen Tests, bei denen eine Sensor-Simulationsumgebung unterstützen kann, hängen dabei sehr von der Art der eigenen mobilen Anwendung ab. Im folgenden ist ein mögliches Beispielszenario aufgelistet: 28

34 5. Integration in den Entwicklungsprozess Abbildung 5.1.: Black-Box-Test Szenario Tabelle 5.1.: Testszenario: Rennspiel Es wird ein Rennspiel für Android entwickelt. Der Anwender lenkt das Fahrzeug durch eine 3D-Umgebung, indem er das Mobilgerät in die gewünschte Richtung neigt. Je stärker er das Gerät neigt, desto enger fährt das Fahrzeug die Kurve. Teil der Anwendung ist ein Modul, welches Beschleunigungsdaten des Gerätes in die Lenkung des Fahrzeugs übersetzt. Test 1 Eingabe Das Smartphone wird in einem Neigungswinkel von 35 nach rechts gehalten. Ausgabe Das Fahrzeug führt eine Rechtskurve mit einem Radius von 2 m aus. Test 2 Eingabe Das Smartphone wird in 500 ms von 0 auf 35 gedreht und nach 2 s wieder zurückgedreht. Ausgabe Das Fahrzeug reagiert innerhalb weniger Millisekunden auf die Bewegung und nach 2 s hat sich seine Bewegungsrichtung um 50 geändert. Test 3 Eingabe Das Smartphone wird 30 cm linear nach rechts bewegt. Ausgabe Das Fahrzeug behält seine Bewegungsrichtung unverändert bei. Im Rennspiel-Szenario sind ein paar Testfälle definiert, wie sie für eine mobilen Anwendung aussehen könnten, die Gebrauch vom Beschleunigungssensor als Eingabe macht. Die zugrunde liegenden Anforderungen an die Anwendung können folgende sein: Präzise, gleichbleibende Lenkbewegung auf allen Mobilgeräten Schnelle Richtungsänderung im Millisekundenbereich (geringer Input Lag) auf allen Geräten Lineare Bewegungen / Positionsänderungen sollten die Lenkung nicht beeinflussen Um diese Tests durchzuführen, benötigt der Entwickler nun im Regelfall Zugriff auf mehrere physische Geräte. Die aktuelle Version der eigenen Anwendung wird auf den 29

35 5. Integration in den Entwicklungsprozess Geräten installiert. Anschließend werden die notwendigen Bewegungen als SOLL- Eingabe auf jedem Gerät einzeln durchgeführt, entweder manuell oder mit einer mechanischen Apparatur. Letztendlich wird die Ausgabe mit der SOLL-Ausgabe verglichen. Ist der Test fehlgeschlagen, werden die Tests später nach Korrektur wiederholt. Mit einer Sensor-Simulationsumgebung kann der Testaufwand reduziert werden. Der Benutzer nimmt die Referenzbewegungen aus den Testfällen mit einem einzigen Gerät auf. Dies muss nicht im Test der Anwendung selbst erfolgen. Da die SOLL-Eingabe schon nach Erstellen der Spezifikation definiert ist, reicht es auch, schon vor Implementierung der Anwendung diese Bewegungsdaten mittels Aufnahme-App von SensorSim zu erfassen. Bei Test-Durchführung wird der Datensatz zum entsprechenden Testfall in der eigenen Anwendung mittels SensorSim-Library abgespielt, entweder im Emulator (kein Gerät benötigt) oder am Gerät selbst (für reale Laufzeitbedingungen). Das Verrauschen mit den Sensorprofilen von Geräten ermöglicht es, die aufgenommenen Daten auf mehreren Geräten zu simulieren. Schlägt der Test fehl, kann dieser später mit den identischen SOLL-Eingaben wiederholt werden. Die Vorteile sind zusammengefasst: Konkrete SOLL-Eingabe schon nach Anforderungsanalyse aufnehmbar Physisches Gerät muss nicht verwendet werden, Testen auf Emulator möglich Reproduzierbare Eingabe bei mehrmaligen Testdurchführungen Mehrere Geräte können unkompliziert mit einem einzigen Datensatz abdeckt werden. Dies betrifft nicht allein Beschleunigungssensoren. Auch in anderen Anwendungsfällen mit allen anderen Sensoren von Android kann eine Simulationsumgebung ähnliche Vorteile bringen. Möchte der Entwickler beispielsweise testen, ob seine Locationbasierte Anwendung problemlos von einem Ortswechsel von draußen in ein Gebäude umgehen kann, so würde er den Weg mit einem Mobilgerät entlanggehen und dabei GPS- und WLAN-Signale mit der SensorSim-Aufnahme-App aufzeichnen. Später in einem Test können diese Daten dann wiederverwendet werden und der Ortswechsel muss nicht noch einmal für jeden Test und jedes Gerät durchgeführt werden Zwischen Mock-Objekt und Gerät Der obere Abschnitt konzentrierte sich stark auf einen Test auf Systemebene, der vollständigen Anwendung auf dem Zielgerät. Bei Modul- oder Integrationstests werden solche externen Komponenten häufig durch sogenannte Mock-Objekte ersetzt. Diese Objekte stehen als Platzhalter für echte Objekte ein, mit denen das zu testende Modul interagiert [15]. Damit lässt sich die Umgebung nachbilden und kontrollieren. Eine Sensor-Simulationsumgebung weist schon auf den ersten Blick eine Reihe von Gemeinsamkeiten mit Mock-Objekten auf. Sie bildet die Sensor-Schnittstelle des Betriebssystems nach, hat keine externen Abhängigkeiten und liefert ein determiniertes, kontrollierbares Verhalten. 30

36 5. Integration in den Entwicklungsprozess Doch je nach Art der abgespielten Daten geht sie über ein reines Mock-Objekt hinaus. In der Regel sind Mock-Objekte winzig im Funktionsumfang und liefern nur fest einprogrammierte Rückgabewerte zurück. Dies könnte im Falle von Beschleunigungssensoren ein Nullwert oder eine glatte Sinusschwingung sein. SensorSim erweitert dies, da mit realen Daten gearbeitet werden kann. Das Objekt wird zusätzlich mit Eigenschaften des realen Gerätes ausgestattet, wie Rauschen, Störungen, Auflösung oder Zeitverhalten. Damit deckt SensorSim einen großen Bereich zwischen Mock-Objekten und dem echten Gerät ab, für den es bisher keine gängigen, verfügbaren Alternativen gab (siehe Abbildung 5.2). Abbildung 5.2.: Einordnung in die verfügbaren Testmittel Je nach Anwendung und Testfall lässt sich der Grad der Simulation dabei über die aufgenommenen Daten und verfügbaren Optionen in der Simulationsumgebung bestimmen. Beispiel Filtermodul im Rennspiel: das Modul empfängt Beschleunigungsdaten vom Betriebssystem und glättet sie, um Rauschen vom jeweiligen Gerät herauszufiltern. Im Test gibt SensorSim unterschiedlich stark verrauschte Daten in das Modul (Ersatz für Android-SensorManager). Beispiel Eingabemodul im Rennspiel: das Modul bekommt eine geglättete Bewegung vom Filtermodul und lenkt das Fahrzeug dadurch in eine bestimmte Richtung. Im Test gibt SensorSim eine Referenzbewegung frei von Störungen in das Modul (Ersatz für Filtermodul). 31

37 5.3. Automatisches Testen 5. Integration in den Entwicklungsprozess Mit einer Sensor-Simulationsumgebung ist es auch möglich, in bestimmten Anwendungsfällen die Tests automatisiert nach dem Beispiel von JUnit durchzuführen. Die SensorSim-Library steht als Mock-Objekt für das Android-Betriebssystem ein und vor Testbeginn wird ein Sensor-Datensatz eingelesen, der für den Test verwendet wird. In Listing 5.1 wird ein Beispiel präsentiert, bei dem ein WLAN-Modul getestet werden soll, welches erkennt, wenn sich das Gerät in Reichweite eines WLAN-Netzes befindet. Das Modul würde normalerweise das Android-Betriebssystem zum Scannen verfügbarer WLANs benutzen, im Test wird dieses durch SensorSim ersetzt. Ein Datensatz, bei dem vom WLAN First_Router zu WLAN Second_Router gewechselt wird, wird bei Testbeginn als Umgebung eingelesen, anschließend wird der Test durchgeführt und die Rückgabewerte des zu testenden Moduls überprüft. Dies kann besonders in Test-Driven Development von Nutzen sein, z.b. wenn es darum geht, einen Filter zu entwerfen, der nur für die Anwendung relevante Sensordaten durchlässt oder gerätespezifisches Rauschen entfernt. Die eigenen Filterparameter werden angepasst und der Test automatisch neu durchgeführt. Listing 5.1: Pseudo-Code: Automatischer Test eines WLAN-Moduls 1 public void testlocationchange ( ) { 2 SensorSim sim = SensorSim. getinstance ( ) ; 3 sim. p l a y F i l e ( " dataset / sgs4_change_wifi. sim " ) ; 4 5 LocationModule mymodule = new LocationModule ( ) ; 6 assertequals ( " F i r s t _ R o u t e r ", mymodule. getwifiname ( ) ) ; 7 mymodule. waitforlocationchange ( 3 0) ; 8 assertequals ( " Second_Router ", mymodule. getwifiname ( ) ) ; 9 } 5.4. Integration in Vorgehensmodelle In diesem Abschnitt wird darauf eingegangen, an welcher Stelle eine Sensorsimulation in bekannte Vorgehensmodelle der Softwareentwicklung eingebunden werden kann Wasserfall-Modell Das Wasserfallmodell nach Royce ist ein lineares Vorgehensmodell, dass aus der Abfolge der Phasen Anforderungen, Analyse, Entwurf, Implementierung, Test und Betrieb besteht [16]. Eine Simulationsumgebung kann dabei hauptsächlich in der Test-Phase nach der Implementierung zum Einsatz kommen. Da ein finaler Test aber immer an echten Gerä- 32

38 5. Integration in den Entwicklungsprozess ten durchgeführt werden sollte, um Fehler der Simulation vor Auslieferung zu vermeiden, sollte eine Simulation vor allen Dingen in den früheren Tests stattfinden. Abbildung 5.3.: Wasserfall-Modell V-Modell Das von Boehm entwickelte V-Modell besteht im Gegensatz zum Wasserfall-Modell aus miteinander korrelierenden Phasen. Jeder konstruktiven Phase schließt sich später eine prüfende Phase auf der jeweiligen Ebene an. Die Test-Phase ist auf mehrere Teststufen unterschiedlicher Systemebenen verteilt. [16] Eine Simulationsumgebung kann auch hier in den Testphasen eingesetzt werden. Wie in den vorherigen Abschnitten erläutert, lassen sich damit im Wesentlichen die Integrations- und Systemtests abdecken. Bei Systemtests sollte wiederum final am echten Gerät getestet werden, um Fehler zu vermeiden. Ein Einsatz auf Unit-Test- Ebene ist prinzipiell möglich (siehe Abschnitt 5.3), aber nur in eingeschränktem Rahmen für einzelne Module. In den konstruktiven Phasen lassen sich bereits Datensätze als SOLL-Eingaben für die späteren Testphasen aufzeichnen. Abbildung 5.4.: V-Modell 33

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

Messsystemanalyse (MSA)

Messsystemanalyse (MSA) Messsystemanalyse (MSA) Inhaltsverzeichnis Ursachen & Auswirkungen von Messabweichungen Qualifikations- und Fähigkeitsnachweise Vorteile einer Fähigkeitsuntersuchung Anforderungen an das Messsystem Genauigkeit

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

Einführung in die Cross-Plattform Entwicklung Zugriff auf Sensoren mit dem Intel XDK

Einführung in die Cross-Plattform Entwicklung Zugriff auf Sensoren mit dem Intel XDK Einführung in die Cross-Plattform Entwicklung Zugriff auf Sensoren mit dem Intel XDK Einführung Dieses Hands-on-Lab (HOL) macht den Leser mit dem Intel XDK und dem Zugriff auf Sensoren vertraut. Es wird

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

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

Einführung in die Cross-Plattform Entwicklung Das Intel XDK

Einführung in die Cross-Plattform Entwicklung Das Intel XDK Einführung in die Cross-Plattform Entwicklung Das Intel XDK Einführung Dieses Hands-on-Lab (HOL) macht den Leser mit dem Intel XDK vertraut. Es wird Schritt für Schritt die erste eigene Hybrid-App entwickelt

Mehr

Inhalt 1 Inbetriebnahme 2 Erläuterungen zum Gateway 3 Bedienung der App 4 Hinweise zur Fehlerbehebung. 1 - Inbetriebnahme. 1.1 - Gateway anschließen

Inhalt 1 Inbetriebnahme 2 Erläuterungen zum Gateway 3 Bedienung der App 4 Hinweise zur Fehlerbehebung. 1 - Inbetriebnahme. 1.1 - Gateway anschließen Inhalt 1 Inbetriebnahme 2 Erläuterungen zum Gateway 3 Bedienung der App 4 Hinweise zur Fehlerbehebung 1 - Inbetriebnahme Nachdem Sie die WeatherHub App von TFA Dostmann aus dem Apple App Store oder dem

Mehr

Customer-specific software for autonomous driving and driver assistance (ADAS)

Customer-specific software for autonomous driving and driver assistance (ADAS) This press release is approved for publication. Press Release Chemnitz, February 6 th, 2014 Customer-specific software for autonomous driving and driver assistance (ADAS) With the new product line Baselabs

Mehr

Kurtosis - der fehlende Knopf bei der Schwingprüfung oder Sigma Dehnung mit B&K Regelsystem 1059

Kurtosis - der fehlende Knopf bei der Schwingprüfung oder Sigma Dehnung mit B&K Regelsystem 1059 Kurtosis - der fehlende Knopf bei der Schwingprüfung oder Sigma Dehnung mit B&K Regelsystem 1059 Wer sich mit der Schwingprüfung in der Umweltsimulation befasst, verwendet dabei oft weißes, also normal-

Mehr

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

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

Brainloop Secure Dataroom Version 8.30. QR Code Scanner-Apps für ios Version 1.1 und für Android

Brainloop Secure Dataroom Version 8.30. QR Code Scanner-Apps für ios Version 1.1 und für Android Brainloop Secure Dataroom Version 8.30 QR Code Scanner-Apps für ios Version 1.1 und für Android Schnellstartanleitung Brainloop Secure Dataroom Version 8.30 Copyright Brainloop AG, 2004-2015. Alle Rechte

Mehr

Systematisches Testen von Software

Systematisches Testen von Software Programmierung Systematisches Testen von Software Markus Eckstein Systematika Information Systems GmbH Kurfürsten-Anlage 36 69115 Heidelberg markus.eckstein@systematika.com Zusammenfassung Die wichtigsten

Mehr

Android Testautomatisierung mit dem Framework Robotium

Android Testautomatisierung mit dem Framework Robotium Android Testautomatisierung mit dem Framework Robotium Daniel Knott XING AG @dnlkntt http://www.adventuresinqa.com Daniel Knott Manager Quality Assurance @dnlkntt daniel.knott@xing.com Daniel Knott hat

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

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation Softwareentwicklungspraktikum Sommersemester 2007 Testdokumentation Auftraggeber Technische Universität Braunschweig

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

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

Optimierung des Energieverbrauchs eingebetteter Software

Optimierung des Energieverbrauchs eingebetteter Software Optimierung des Energieverbrauchs eingebetteter Software Welchen Einfluss hat eine Programmänderung auf den Energiebedarf einer Applikation? Welcher Programmteil verursacht den größten Energieverbrauch?

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Grundlagen der Elektro-Proportionaltechnik

Grundlagen der Elektro-Proportionaltechnik Grundlagen der Elektro-Proportionaltechnik Totband Ventilverstärkung Hysterese Linearität Wiederholbarkeit Auflösung Sprungantwort Frequenzantwort - Bode Analyse Der Arbeitsbereich, in dem innerhalb von

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

4 1 0.2 2.1 0 1 rtsch e s G ia tth a M Herzlich Willkommen

4 1 0.2 2.1 0 1 rtsch e s G ia tth a M Herzlich Willkommen Herzlich Willkommen 1 «Neue Technologien» Welche Möglichkeiten gib es ausser dem 0815 Variound GPS? 2 Ablauf Grundsätzlich Hardware Software Stromversorgung Externe Sensoren Quellenverzeichniss Fragen

Mehr

Über dieses Buch. Kapitel 1. 1.1 Einleitung

Über dieses Buch. Kapitel 1. 1.1 Einleitung Kapitel 1 Über dieses Buch 1.1 Einleitung Dieses Buch behandelt das Vorgehensmodell Kanban und seinen Einsatz in Softwareentwicklungsprojekten. Kanban ist ein Vorgehensmodell der schlanken Softwareentwicklung

Mehr

Kirstin Hübner Armin Burgmeier Gruppe 15 10. Dezember 2007

Kirstin Hübner Armin Burgmeier Gruppe 15 10. Dezember 2007 Protokoll zum Versuch Transistorschaltungen Kirstin Hübner Armin Burgmeier Gruppe 15 10. Dezember 2007 1 Transistor-Kennlinien 1.1 Eingangskennlinie Nachdem wir die Schaltung wie in Bild 13 aufgebaut hatten,

Mehr

Mobile Enterprise Application Platforms

Mobile Enterprise Application Platforms Mobile Enterprise Application Platforms 17. April 2013 Fachbereich Wirtschaft und Gesundheit Prof. Dr. Volker Wiemann volker.wiemann@fh bielefeld.de +49 (0) 521/106 389 Problem 0. Ausgangslage Blackberry

Mehr

Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung

Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung Hintergrund Bei komplexen Baugruppen ergeben sich sehr hohe Anforderungen an die Tolerierung der einzelnen

Mehr

Diskussion eines hybriden Projektmanagements im Vergleich zu klassischem und agilem Projektmanagement. Bachelorarbeit

Diskussion eines hybriden Projektmanagements im Vergleich zu klassischem und agilem Projektmanagement. Bachelorarbeit Diskussion eines hybriden Projektmanagements im Vergleich zu klassischem und agilem Projektmanagement Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft

Mehr

Hochschule Mittweida. UML-Dokumenation. Franziska Frenzel [Wählen Sie das Datum aus]

Hochschule Mittweida. UML-Dokumenation. Franziska Frenzel [Wählen Sie das Datum aus] Hochschule Mittweida UML-Dokumenation Franziska Frenzel [Wählen Sie das Datum aus] Inhalt UML-Dokumenation Inhalt... 1 /PF 000/ App ausführen inkl. Tracking und UUID erstellen... 2 /PF 001/ Modus wechseln...

Mehr

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells...

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells... Inhaltsverzeichnis Inhaltsverzeichnis... I 1 Problemstellung... 1 2 V-Modell... 1 2.1 Allgemeines... 1 2.2 Anwendung des V-Modells... 3 3 SCRUM-Modell... 4 3.1 Allgemeines... 4 3.2 Anwendung des SCRUM-Modells...

Mehr

Ein Auszug aus... Studie. Content Management Systeme im Vergleich. Empfehlungen und Entscheidungshilfen für Unternehmensbereiche

Ein Auszug aus... Studie. Content Management Systeme im Vergleich. Empfehlungen und Entscheidungshilfen für Unternehmensbereiche Ein Auszug aus... Studie Content Management Systeme im Vergleich Empfehlungen und Entscheidungshilfen für Unternehmensbereiche Die komplette Studie ist bei amazon.de käuflich zu erwerben. Inhaltsverzeichnis

Mehr

Der Bipolar-Transistor und die Emitterschaltung Gruppe B412

Der Bipolar-Transistor und die Emitterschaltung Gruppe B412 TECHNISCHE UNIVERSITÄT MÜNCHEN Der Bipolar-Transistor und die Emitterschaltung Gruppe B412 Patrick Christ und Daniel Biedermann 16.10.2009 1. INHALTSVERZEICHNIS 1. INHALTSVERZEICHNIS... 2 2. AUFGABE 1...

Mehr

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG ALM mit Visual Studio Online Philip Gossweiler Noser Engineering AG Was ist Visual Studio Online? Visual Studio Online hiess bis November 2013 Team Foundation Service Kernstück von Visual Studio Online

Mehr

Datamining-Cup 2012 - TeamFK i. Datamining-Cup 2012 - TeamFK

Datamining-Cup 2012 - TeamFK i. Datamining-Cup 2012 - TeamFK i Datamining-Cup 2012 - TeamFK ii Inhaltsverzeichnis 1 Programme und Datenvorverarbeitung 1 2 Vorbetrachtung der Daten 2 2.1 Zeitintervalle..................................................... 2 2.2 Mittelwert

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

Forumslader App für Android Kurzbeschreibung

Forumslader App für Android Kurzbeschreibung Forumslader App für Android Kurzbeschreibung Für den Forumslader ab Firmware xx281112 steht ein spezielles Bluetoothmodul mit integriertem Fahrradcomputer als Zusatzkomponente zur Verfügung. Dieses sammelt,

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

EO - Oszilloskop Blockpraktikum Frühjahr 2005

EO - Oszilloskop Blockpraktikum Frühjahr 2005 EO - Oszilloskop, Blockpraktikum Frühjahr 25 28. März 25 EO - Oszilloskop Blockpraktikum Frühjahr 25 Alexander Seizinger, Tobias Müller Assistent René Rexer Tübingen, den 28. März 25 Einführung In diesem

Mehr

Versuchsauswertung mit Polynom-Regression in Excel

Versuchsauswertung mit Polynom-Regression in Excel Versuchsauswertung mit Polynom-Regression in Excel Aufgabenstellung: Gegeben sei die in Bild 1 gezeigte Excel-Tabelle mit Messwertepaaren y i und x i. Aufgrund bekannter physikalischer Zusammenhänge wird

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

Teststrategie festlegen und Teststufen aufeinander abstimmen Testen Teststrategie festlegen und Teststufen aufeinander abstimmen Bereich Projektplanung und -steuerung Aktivität Projekt planen Ziele Effiziente Testausführung Vermeidung von doppelter Arbeit schnell

Mehr

10 things I wished they d told me! aktuell. innovativ. praxisbezogen.

10 things I wished they d told me! aktuell. innovativ. praxisbezogen. 10 things I wished they d told me! aktuell. innovativ. praxisbezogen. 10 things I wished they d told me! Reinhard Salomon SEQIS Geschäftsleitung SEQIS 10 things Programm 2015 19.03.2015 Mobile Testing:

Mehr

NUTZUNG VON SMARTPHONES FÜR DIE DOKUMENTATION VON UNFÄLLEN, KRITISCHEN SITUATIONEN UND NORMALFAHRVERHALTEN

NUTZUNG VON SMARTPHONES FÜR DIE DOKUMENTATION VON UNFÄLLEN, KRITISCHEN SITUATIONEN UND NORMALFAHRVERHALTEN NUTZUNG VON SMARTPHONES FÜR DIE DOKUMENTATION VON UNFÄLLEN, KRITISCHEN SITUATIONEN UND NORMALFAHRVERHALTEN Dipl.-Ing. Henrik Liers Verkehrsunfallforschung an der TU Dresden GmbH Dokumentation realer Unfälle

Mehr

Bildverarbeitung in der Medizintechnik

Bildverarbeitung in der Medizintechnik Bildverarbeitung in der Medizintechnik Aufgrund einer Zusammenarbeit mit Würth Elektronik im Gebiet der Medizintechnik ist eine Arbeit aus dem Gebiet der Bildverarbeitung in der Medizintechnik ausgeschrieben.

Mehr

Softwaretechnik (WS 11/12)

Softwaretechnik (WS 11/12) Universität Augsburg, LSt. Softwaretechnik, K. Stenzel, H. Seebach, G. Anders Softwaretechnik (WS 11/12) Lösungsvorschlag 5 Aufgabe 1 (System Behavior: System Sequence Diagrams) (10/5 Punkte) a) Was sind

Mehr

Linearer Zusammenhang von Datenreihen

Linearer Zusammenhang von Datenreihen Linearer Zusammenhang von Datenreihen Vielen Problemen liegen (möglicherweise) lineare Zusammenhänge zugrunde: Mein Internetanbieter verlangt eine Grundgebühr und rechnet minutenweise ab Ich bestelle ein

Mehr

A-Plan 12.0. Zeiterfassung 2.0. Ausgabe 1.1. Copyright. Warenzeichenhinweise

A-Plan 12.0. Zeiterfassung 2.0. Ausgabe 1.1. Copyright. Warenzeichenhinweise A-Plan 12.0 Zeiterfassung 2.0 Ausgabe 1.1 Copyright Copyright 1996-2014 braintool software gmbh Kein Teil dieses Handbuches darf ohne ausdrückliche Genehmigung von braintool software gmbh auf mechanischem

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Service Delivery. erfolgreich einführen und betreiben

Service Delivery. erfolgreich einführen und betreiben Service Delivery erfolgreich einführen und betreiben Einführung und Betrieb eines neuen Service Nicht immer läuft bei der Einführung eines neuen Service oder einer Anwendung alles wie geplant! Keine termingerechte

Mehr

Absolut, relativ oder einfach mehr Geld? Analyse der Netto-Differenzen 2014

Absolut, relativ oder einfach mehr Geld? Analyse der Netto-Differenzen 2014 Voraussetzungen Absolut, relativ oder einfach mehr Geld? Analyse der -en 2014 Tarifbeschäftigte und beamtete Lehrerinnen und Lehrer erhalten bei gleicher Arbeitszeit, gleichen Aufgaben und gleichen Belastungen

Mehr

Spannungsstabilisierung

Spannungsstabilisierung Spannungsstabilisierung 28. Januar 2007 Oliver Sieber siebero@phys.ethz.ch 1 Inhaltsverzeichnis 1 Zusammenfassung 4 2 Einführung 4 3 Bau der DC-Spannungsquelle 5 3.1 Halbwellengleichrichter........................

Mehr

Welche Unterschiede gibt es zwischen einem CAPAund einem Audiometrie- Test?

Welche Unterschiede gibt es zwischen einem CAPAund einem Audiometrie- Test? Welche Unterschiede gibt es zwischen einem CAPAund einem Audiometrie- Test? Auch wenn die Messungsmethoden ähnlich sind, ist das Ziel beider Systeme jedoch ein anderes. Gwenolé NEXER g.nexer@hearin gp

Mehr

Referenzprozessmodell zur erfolgreichen Durchführung von CRM - Projekten

Referenzprozessmodell zur erfolgreichen Durchführung von CRM - Projekten Referenzprozessmodell zur erfolgreichen Durchführung von CRM - Projekten Eine große Anzahl von CRM- Projekten scheitert oder erreicht die gesetzten Ziele nicht. Die Ursachen hierfür liegen oftmals in der

Mehr

6 InfoCubes erstellen und konfigurieren

6 InfoCubes erstellen und konfigurieren InfoCubes bilden die Reportingschicht in der LSA; sie sind für die Performance des Reportings entscheidend. In diesem Kapitel stellen wir Ihnen vor, welche InfoCubes es gibt und wie Sie damit arbeiten.

Mehr

Parallele und funktionale Programmierung Wintersemester 2013/14. 8. Übung Abgabe bis 20.12.2013, 16:00 Uhr

Parallele und funktionale Programmierung Wintersemester 2013/14. 8. Übung Abgabe bis 20.12.2013, 16:00 Uhr 8. Übung Abgabe bis 20.12.2013, 16:00 Uhr Aufgabe 8.1: Zeigerverdopplung Ermitteln Sie an folgendem Beispiel den Rang für jedes Listenelement sequentiell und mit dem in der Vorlesung vorgestellten parallelen

Mehr

1. Motivation 2. Begriffsklärung 3. Komponententests 4. Integrationstests 5. Integrationsstrategien 6. Zusammenfassung

1. Motivation 2. Begriffsklärung 3. Komponententests 4. Integrationstests 5. Integrationsstrategien 6. Zusammenfassung Übersicht s s Gregoire Kemgne 1 Motivation Problem: Software wird immer größer und komplexer, dadurch ist diese immer schwerer zu überschauen Ein Projekt benötigt mehr Zeit und/oder Entwickler. Lösung:

Mehr

Simulation der SW-Systemzuverlässigkeit in Automatisierungssystemen auf Grundlage von SW-Komponenten

Simulation der SW-Systemzuverlässigkeit in Automatisierungssystemen auf Grundlage von SW-Komponenten Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner Simulation der SW-Systemzuverlässigkeit in Automatisierungssystemen auf Grundlage von SW-Komponenten

Mehr

PRAKTIKUM Experimentelle Prozeßanalyse 2. VERSUCH AS-PA-2 "Methoden der Modellbildung statischer Systeme" Teil 2 (für ausgewählte Masterstudiengänge)

PRAKTIKUM Experimentelle Prozeßanalyse 2. VERSUCH AS-PA-2 Methoden der Modellbildung statischer Systeme Teil 2 (für ausgewählte Masterstudiengänge) FACHGEBIET Systemanalyse PRAKTIKUM Experimentelle Prozeßanalyse 2 VERSUCH AS-PA-2 "Methoden der Modellbildung statischer Systeme" Teil 2 (für ausgewählte Masterstudiengänge) Verantw. Hochschullehrer: Prof.

Mehr

HERAUSFORDERUNGEN BEI DER ENTWICKLUNG VON HEALTH-APPS

HERAUSFORDERUNGEN BEI DER ENTWICKLUNG VON HEALTH-APPS FZI FORSCHUNGSZENTRUM INFORMATIK HERAUSFORDERUNGEN BEI DER ENTWICKLUNG VON HEALTH-APPS am Beispiel der Stroke Manager App Roland A. Görlitz FZI Forschungszentrum Informatik, Karlsruhe Agenda Einführung

Mehr

Whitepaper. Automatisierte Akzeptanztests mit FIT. Einleitung. Die Bedeutung von Akzeptanztests

Whitepaper. Automatisierte Akzeptanztests mit FIT. Einleitung. Die Bedeutung von Akzeptanztests Automatisierte Akzeptanztests mit FIT Einleitung Dieses beschreibt, wie man Tests aus Anwender-/Kundensicht mit dem Open-Source-Werkzeug FIT beschreibt und durchführt. Das ist für Kunden, Anwender und

Mehr

Abschlussarbeiten 2010 in der Medizininformatik

Abschlussarbeiten 2010 in der Medizininformatik Abschlussarbeiten 2010 in der Medizininformatik Ansprechpartner: Prof. Dr. Eberhard Beck eberhard.beck@fh-brandenburg.de FACHHOCHSCHULE BRANDENBURG FACHBEREICH INFORMATIK UND MEDIEN Konzeption und prototypische

Mehr

Agiles Testmanagment. Hugo Beerli bbv Software Services AG. Luzern, September 2011. www.bbv.ch

Agiles Testmanagment. Hugo Beerli bbv Software Services AG. Luzern, September 2011. www.bbv.ch Agiles Testmanagment Hugo Beerli bbv Software Services AG Luzern, September 2011 Product Backlog (Agenda) 1) Warum System Tests 2) Agile Arbeitsmethode Stand up Meeting 3) Vorteile der agilen Methode 4)

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

Geschäftsbereich Mobile Services Was ist Android?

Geschäftsbereich Mobile Services Was ist Android? Geschäftsbereich Mobile Services Was ist Android? Hinter Hoben 149 53129 Bonn www.visionera.de Ansprechpartner: Arno Becker arno.becker@visionera.de +49 228 555 1111 +49 160 98965856 Einleitung Android

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

Der Entwicklungsprozess. Oder wie entwickle ich ein eingebettetes System?

Der Entwicklungsprozess. Oder wie entwickle ich ein eingebettetes System? Der Entwicklungsprozess Oder wie entwickle ich ein eingebettetes System? Einleitung Problemstellung erläutern, Eine Entwicklungsprozess ist ein Prozess, der beschreibt, wie man eine Entwicklung anzugehen

Mehr

TD-Mobile-Beispiel mit Barcodescanner

TD-Mobile-Beispiel mit Barcodescanner TD-Mobile-Beispiel mit Barcodescanner 1 Einleitung Viele Interessenten für die Entwicklungsumgebung TD-Mobile wollen mit einem mobilen Endgerät (sprich: Handy) Daten über entsprechende Barcodes erfassen

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

Untersuchung zur hardwareunterstützten Entwurfsverifikation von Stream-basierten Kommunikations- und Verarbeitungsalgorithmen

Untersuchung zur hardwareunterstützten Entwurfsverifikation von Stream-basierten Kommunikations- und Verarbeitungsalgorithmen Fakultät Informatik Institut für Technische Informatik, Professur für VLSI-Entwurfssysteme, Diagnostik und Architektur Untersuchung zur hardwareunterstützten Entwurfsverifikation von Stream-basierten Kommunikations-

Mehr

Testen in der Wolke -

Testen in der Wolke - Test- und Qualitätsmanagement bei ckc Testen in der Wolke - nachhaltig oder vom Winde verweht? Competence Cluster Test- und Qualitätsmanagement AGENDA 1. Einleitung 2. Motivation 3. Projektvorgehen 3.1

Mehr

Deploy von PHP-Applikationen

Deploy von PHP-Applikationen Deploy von PHP-Applikationen Jan Burkl System Engineer Zend Technologies Wer bin ich? Jan Burkl jan.burkl@zend.com PHP Entwickler seit 2001 Projektarbeit Bei Zend seit 2006 System Engineer Zend Certified

Mehr

BlackBerry Mobile Fusion Universal Device Service. Thomas Dingfelder, Senior Technical Account Manager ubitexx a Subsidiary of Research In Motion

BlackBerry Mobile Fusion Universal Device Service. Thomas Dingfelder, Senior Technical Account Manager ubitexx a Subsidiary of Research In Motion BlackBerry Mobile Fusion Universal Device Service Stefan Mennecke, Director Stefan Mennecke, Director Thomas Dingfelder, Senior Technical Account Manager ubitexx a Subsidiary of Research In Motion RIM

Mehr

REQUIREMENTS ENGINEERING KONSTRUKTIVE QS REQUIREMENTS ENGINEERING 1

REQUIREMENTS ENGINEERING KONSTRUKTIVE QS REQUIREMENTS ENGINEERING 1 REQUIREMENTS ENGINEERING KONSTRUKTIVE QS REQUIREMENTS ENGINEERING 1 QUALITÄT FÜR SIE Qualität zeigt sich in Ergebnissen und Erfolgen. Sie hängt von der jeweiligen Problemstellung ab, deshalb sehen wir

Mehr

Learning Suite Talent Suite Compliance Suite. Systemvoraussetzungen

Learning Suite Talent Suite Compliance Suite. Systemvoraussetzungen Learning Suite Talent Suite Compliance Suite Systemvoraussetzungen Vorwort Dieses Dokument beschreibt, welche Anforderungen an die Installationsumgebung zu stellen sind, um die Plattform unter optimalen

Mehr

AV-TEST. Sicherheitslage Android

AV-TEST. Sicherheitslage Android AV-TEST Sicherheitslage Android Sicherheitslage Android 1 SICHERHEITSLAGE ANDROID MEHR ALS 30 IT-SPEZIALISTEN MEHR ALS 15 JAHRE EXPERTISE IM BEREICH ANTIVIREN-FORSCHUNG UNTERNEHMENSGRÜNDUNG 2004 EINE DER

Mehr

Approximationsalgorithmen

Approximationsalgorithmen Ausarbeitung zum Thema Approximationsalgorithmen im Rahmen des Fachseminars 24. Juli 2009 Robert Bahmann robert.bahmann@gmail.com FH Wiesbaden Erstellt von: Robert Bahmann Zuletzt berarbeitet von: Robert

Mehr

PRESS RELEASE. Kundenspezifische Lichtlösungen von MENTOR

PRESS RELEASE. Kundenspezifische Lichtlösungen von MENTOR Kundenspezifische Lichtlösungen von MENTOR Mit Licht Mehrwert schaffen. Immer mehr Designer, Entwicklungsingenieure und Produktverantwortliche erkennen das Potential innovativer Lichtkonzepte für ihre

Mehr

Telefonieren mit "App's"! Android-Smartphone und Android-Tablet-PC mit Bria Informationen zur Nutzung von TeScript

Telefonieren mit App's! Android-Smartphone und Android-Tablet-PC mit Bria Informationen zur Nutzung von TeScript Telefonieren mit "App's"! Android-Smartphone und Android-Tablet-PC mit Bria Informationen zur Nutzung von TeScript Der Begriff App ist die Kurzform für Applikation und bedeutet Anwendungssoftware. Mit

Mehr

BESCHAFFUNG UND LIZENZIERUNG MIT DEM VEREINFACHTEN ORACLE LIZENZMODELL

BESCHAFFUNG UND LIZENZIERUNG MIT DEM VEREINFACHTEN ORACLE LIZENZMODELL BESCHAFFUNG UND LIZENZIERUNG MIT DEM VEREINFACHTEN ORACLE LIZENZMODELL DIESER LEITFADEN IST FÜR FOLGENDE ORACLE SOFTWARE PROGRAMME GÜLTIG Oracle Database 11g Standard Edition One Die passende Datenbank-Lösung

Mehr

Entwicklungsumgebungen. Packer, Vagrant, Puppet. Alexander Pacnik Mannheim, 10.11.2014

Entwicklungsumgebungen. Packer, Vagrant, Puppet. Alexander Pacnik Mannheim, 10.11.2014 Entwicklungsumgebungen Packer, Vagrant, Puppet Alexander Pacnik Mannheim, 10.11.2014 inovex... über inovex und den Referenten 2 Entwicklungsumgebungen... Übersicht Einführung Packer Konfiguration Packer

Mehr

Präsentation. homevisu Familie. Peter Beck. Juni 2011. www.p-b-e.de. 2011 p b e Peter Beck 1

Präsentation. homevisu Familie. Peter Beck. Juni 2011. www.p-b-e.de. 2011 p b e Peter Beck 1 Präsentation homevisu Familie Peter Beck Juni 2011 2011 p b e Peter Beck 1 Funktionensumfang Der Funktionsumfang das provisu Framework. Modular und durch Plug-In erweiterbar / anpassbar. Plug-In Schnittstelle

Mehr

Telefonieren mit "App's"! Android-Smartphone und Android-Tablet-PC mit Bria Informationen zur Nutzung von TeScript

Telefonieren mit App's! Android-Smartphone und Android-Tablet-PC mit Bria Informationen zur Nutzung von TeScript Telefonieren mit "App's"! Android-Smartphone und Android-Tablet-PC mit Bria Informationen zur Nutzung von TeScript Der Begriff App ist die Kurzform für Applikation und bedeutet Anwendungssoftware. Mit

Mehr

Tinytag Funk- Datenlogger- Software

Tinytag Funk- Datenlogger- Software Tinytag Funk- Datenlogger- Software Seite: 1 Tinytag Funk- Datenlogger- Software Tinytag Explorer ist die Windows- basierte Software zum Betrieb eines Tinytag Funk- Systems. Die Anwender können ihre Daten

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

11 DYNAMISCHES GRUNDWASSERMANAGEMENT- SYSTEM

11 DYNAMISCHES GRUNDWASSERMANAGEMENT- SYSTEM Kapitel 11: Dynamisches Grundwassermanagementsystem 227 11 DYNAMISCHES GRUNDWASSERMANAGEMENT- SYSTEM 11.1 Übersicht Das entwickelte Optimierungssystem für instationäre Verhältnisse lässt sich in der praktischen

Mehr

Eine Testautomatisierung für Roboter-Steuerprogramme auf Android unter Verwendung von TTCN-3

Eine Testautomatisierung für Roboter-Steuerprogramme auf Android unter Verwendung von TTCN-3 Eine Testautomatisierung für Roboter-Steuerprogramme auf Android unter Verwendung von TTCN-3 Yassine El Amrani Hans W. Nissen FH Köln Fakultät für Informations-, Medien- und Elektrotechnik Institut für

Mehr

Lizenzierung von System Center 2012

Lizenzierung von System Center 2012 Lizenzierung von System Center 2012 Mit den Microsoft System Center-Produkten lassen sich Endgeräte wie Server, Clients und mobile Geräte mit unterschiedlichen Betriebssystemen verwalten. Verwalten im

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

Generating Fingerprints of Network Servers and their Use in Honeypots. Thomas Apel

Generating Fingerprints of Network Servers and their Use in Honeypots. Thomas Apel Generating Fingerprints of Network Servers and their Use in Honeypots Thomas Apel Der Überblick Fingerprinting von Netzwerkdiensten Banner Verfügbare Optionen Reaktionen auf falsche Syntax Verwendung für

Mehr

Monte Carlo Simulation (Grundlagen)

Monte Carlo Simulation (Grundlagen) Der Titel des vorliegenden Beitrages wird bei den meisten Lesern vermutlich Assoziationen mit Roulette oder Black Jack hervorrufen. Allerdings haben das heutige Thema und die Spieltische nur den Namen

Mehr

SOFTWARE-ENTWICKLUNG FÜR EMBEDDED SYSTEMS

SOFTWARE-ENTWICKLUNG FÜR EMBEDDED SYSTEMS SOFTWARE-ENTWICKLUNG FÜR EMBEDDED SYSTEMS Stimmungsbild zu den Herausforderungen bei der Software-Entwicklung für Embedded Systems Motivation In dieser Umfrage geht es um die Entwicklung von Software für

Mehr

Performance und Bandbreitenmanagement Tests Version 10.01.2005. MuSeGa

Performance und Bandbreitenmanagement Tests Version 10.01.2005. MuSeGa Berner Fachhochschule Hochschule für Technik und Informatik HTI Performance und Bandbreitenmanagement Tests Version 10.01.2005 Diplomarbeit I00 (2004) MuSeGa Mobile User Secure Gateway Experte: Andreas

Mehr

Bin ich fit für myconvento?

Bin ich fit für myconvento? Bin ich fit für myconvento? Sie planen den Einsatz unserer innovativen Kommunikationslösung myconvento und fragen sich gerade, ob Ihr Rechner die Anforderungen erfüllt? Hier erfahren Sie mehr. Inhalt Was

Mehr

Die COMLINE AG präsentiert. Enterprise Mobility Introductional Guide

Die COMLINE AG präsentiert. Enterprise Mobility Introductional Guide Die COMLINE AG präsentiert Enterprise Mobility Introductional Guide April 2013 Agenda COMLINE Enterprise Mobility Mission Leistungsportfolio Eckdaten Methodik Ausgangssituation Herausforderung / Problemstellung

Mehr

Agiles Schätzen. Quelle: Kap. 7 aus Wie schätzt man in agilen Projekten oder wieso Scrum-Projekte erfolgreicher sind [Boris Gloger 2014]

Agiles Schätzen. Quelle: Kap. 7 aus Wie schätzt man in agilen Projekten oder wieso Scrum-Projekte erfolgreicher sind [Boris Gloger 2014] Agiles Schätzen Quelle: Kap. 7 aus Wie schätzt man in agilen Projekten oder wieso Scrum-Projekte erfolgreicher sind [Boris Gloger 2014] Schätzen der Größe Wir bestimmen die Größe, nicht den Aufwand. Auf

Mehr

Swp08-6 Verantwortliche: Yundensuren, Baigalmaa. Testkonzept

Swp08-6 Verantwortliche: Yundensuren, Baigalmaa. Testkonzept Testkonzept 1.Einführung Um die Zuverläsigkeit und die Qualität der Software und des gesamten Systems zu verbessern, sind Tests durchzuführen. Die Testreihe läst sich in drei Stufen einteilen, nülich Komponententest,

Mehr

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim Test- Grundsätzliches - - - Ablauf von Tests Grundsätzliche Test- -Tests Äquivalenzklassenbildung Randwertanalyse -Tests Man unterscheidet verschiedene Überdeckungsgrade: Statement Coverage Decision Coverage,

Mehr

Zuerst: Installation auf dem Mobilgerät (des Kindes)

Zuerst: Installation auf dem Mobilgerät (des Kindes) Inhalt Willkommen... 3 Was ist der Chico Browser?... 3 Bei Android: App Kontrolle inklusive... 3 Das kann der Chico Browser nicht... 3 Zuerst: Installation auf dem Mobilgerät (des Kindes)... 4 Einstellungen

Mehr

VERSIONSHINWEISE. Versionshinweise. Versionsmitteilung. Produktversion: Vision und Vision Pro Version 8.2. Build-Nummer: Versanddatum:

VERSIONSHINWEISE. Versionshinweise. Versionsmitteilung. Produktversion: Vision und Vision Pro Version 8.2. Build-Nummer: Versanddatum: Versionshinweise Produktversion: Vision und Vision Pro Version 8.2 Build-Nummer: Versanddatum: VERSIONSHINWEISE 8300 15. Oktober 2013 Versionsmitteilung Diese Version konzentriert sich auf die Unterstützung

Mehr