1194 research outputs found
Sort by
Profiling
Seit die EU im Mai 2018 die DSGVO in Kraft gesetzt hat, ist die Anzahl der sogenannten Cookie-Banner im Web schlagartig angestiegen.
Cookie-Banner sind Pop-ups, die auftauchen, wenn man eine Seite aufruft.
Ihre Funktion ist es, die Einwilligung des Benutzers einzuholen, um persönliche Daten über ihn verarbeiten zu dürfen.
Allen Cookies zuzustimmen, ist dabei oft die Standardeinstellung.
Die Banner ständig manuell auszufüllen ist mühselig und eine automatische Bearbeitung dieser ist wünschenswert.
Das Ziel dieser Arbeit ist es, eine Lösung zu entwerfen, die zum einen die User Experience des Benutzers verbessert, indem es ihm die Arbeit des Ausfüllens der Banner abnimmt.
Zum anderen soll die Lösung auch dazu dienen weniger Informationen an Webseiten zu übermitteln und somit dem Profiling entgegen zu wirken.
Für diesen Entwurf soll dann ein Prototyp entwickelt werden.
Um dies zu bewerkstelligen, wurden zunächst Cookie-Banner von verschiedenen Webseiten analysiert.
Anhand dieser Analyse wurden schliesslich Lösungsansätze erarbeitet.
Daraufhin wurden die Vor- und Nachteile der Ansätze miteinander verglichen und schlussendlich einer ausgewählt, der umgesetzt wurde.
Das Ergebnis unserer Arbeit ist ein Plugin Prototyp, welcher aufzeigt, dass es grundsätzlich möglich ist, die Cookie-Banner automatisiert zu bearbeiten.
Dabei kann der Benutzer festlegen, ob er nur die essentiellen Cookies akzeptieren will oder alle.
Der Prototyp unterstützt sieben CMPs und einige Webseiten, die den Banner selbständig implementieren.
Weiterhin kann das Plugin ohne viel Aufwand um zusätzliche CMPs erweitert werden, indem Regeln in einem JSON-File ergänzt werden. Benutzertests haben die Usability des Plugins bestätigt.
In unserer Arbeit haben wir die am weitverbreitetsten CMPs implementiert.
CMPs, welche seltener vorkommen, können das Plugin vollenden.
Allerdings ist es bereits jetzt in einem Stadium, in dem es der breiten Masse zugänglich gemacht werden kann und das Erlebnis der Benutzer verbessert
MISP - Malware Information Sharing Platform
Problemstellung: Das Cyber Defense Modul an der OST vermittelt Studierenden diverse Tools und Methoden, um sich besser gegen Cyber Kriminelle zu schützen. Dazu gehört auch MISP (Malware Information Sharing Platform), eine Software für die Klassifizierung und den Austausch von Indicators of Compromize (IOCs) und Malware Samples.
Ziel der Arbeit: Ziel dieser Arbeit ist die Erstellung von 8 verschiedenen Laborumgebungen auf der HackingLab Plattform, um den Studierenden einen Einblick in MISP zu geben. Ein Lab beinhaltet jeweils eine Einführung ins Thema, eine Problemstellung mit Step by Step Anleitungen, sowie Verständnisfragen und eine Lernkontrolle.
Ergebnis: Es wurden 8 unterschiedliche MISP-Labs erstellt. Sie behandeln diverse Features von MISP und decken einen grossen Teil der MISPFunktionalität ab. Auf GitHub wurde ein Repository eingerichtet, welches die MISP installation auf Basis von Docker automatisiert. Die Docker Labs sind modular und können einfach via Skript (Python) angepasst werden. Die Übungen sind auf die Hacking-Lab LiveCD https://livecd.hacking-lab.com/ abgestimmt
Unihockeyball Bestell-App
Ausgangslage
Im Techpark der OST Rapperswil wird eine Produktionszelle für das vollautomatisierte Herstellen von benutzerdefinierten Unihockeybällen als Show-Case betrieben. Ball-Bestellungen können aktuell nur über ein fixiertes Display an der Produktionszelle mit Direktanbindung an die Mastersteuerung der Produktionszelle getätigt werden. Zur benutzerdefinierten Abholung wird eine Quittung mit einem QR-Code herausgegeben.
Ziel der Arbeit
Innerhalb dieser Semesterarbeit soll eine funktionierende Bestell-App entwickelt werden, worüber Ball-Bestellungen an die Produktionszelle getätigt werden können.
Dazu soll eine Anbindung an die SAP Instanz der Smart Factory realisiert werden. Die SAP Instanz soll als neue Schnittstelle zwischen Bestell-App und Produktionszelle dienen. Weiter soll in der Bestell-App sichtbar werden, sobald eine Bestellung abholbereit ist. Der anschliessende Abholprozess, insbesondere die Herausgabe von Bällen aus dem Zwischenlager, ist ebenfalls in die Bestell-App integriert. Zusätzlich sollen Produktionsdaten aus der MindSphere Cloud heruntergeladen und in der Bestell-App visualisiert werden können. Dafür sind eine geeignete Systemarchitektur für die Bestell-App und verwendende Schnittstellen zum SAP zu definieren. Darauf aufbauend soll die Bestell-App realisiert und die Kommunikation zum SAP sowie zu MindSphere sichergestellt werden. Basierend auf der evaluierten Deploymentstrategie wird ein Software-Release umgesetzt.
Ergebnis
Der gesamte Bestellprozess an die Produktionszelle kann nun über die Bestell-App abgewickelt werden. Auch die Produktionsdaten können visuell dargestellt werden. Zusätzlich kann der Administrator die Bestellmöglichkeit temporär deaktivieren. Steht die Produktionszelle gerade nicht zur Verfügung, kann alternativ eine Simulation für den Bestellprozess gestartet werden. Ein weiteres Highlight ist sicher der dreidimensionale Unihockeyball, welcher das Bestellerlebnis markant steigert. Filter in der Bestellübersicht und ein Responsive Design runden das Frontend ab.
Das Backend ist in drei logisch getrennte Container gegliedert. Ein Container übernimmt die Kommunikation zu MindSphere, während ein anderer Container die Daten vom (externen) Bestellsystem aufbereitet. Der dritte Container bindet alle Container und bietet gegenüber dem Frontend offene Schnittstellen an. Diese Aufteilung garantiert eine hohe Wartbarkeit.
Technologisch wurde für das Frontend auf Typescript und React gesetzt. Für das Backend kam C# beziehungsweise ASP.NET Core zum Einsatz. Da zum gegebenen Zeitpunkt keine SAP-Schnittstelle vorlag, wurde kurzerhand mit einem weiteren Container eine direkte Verbindung zwischen der Produktionszelle und Bestell-App realisiert. Durch die konsequente Containerisierung und Continuous Deployment liegt ein produktiv lauffähiger Release der Bestell-App bereit
Webapplikation zur Prozessdigitalisierung
Ausgangslage:
Unternehmen und Organisationen beschäftigen sich zunehmend mit der Digitalisierung und der Optimierung der internen sowie externen Prozesse. Die Anwendung von automatisierten Abläufen und die Aufbereitungen von entstandenen Daten erlaubt eine schnellere und genauere Abwicklung und Validierung der essenziellen Prozesse eines Unternehmens. Daher ist es naheliegend, dass sich Organisationen und Unternehmen um eine Automatisierung von gewissen Abläufen bemühen.
Für das Innovation Network bedeutet dies die Digitalisierung des Anfrageprozess zur finanziellen Projektförderung. Die Abhandlung einer Anfrage verlangt im momentanen Zustand zu viel Eigenaufwand der involvierten Parteien. Das Einreichen einer Anfrage, der Entscheidungsprozess sowie die administrativen Abläufe werden über E-Mail koordiniert. Der Prozess ist nicht transparent genug und es muss mit unnötigem Mehraufwand bei der Absprache gerechnet werden.
Ziel der Arbeit:
Der Anfrageprozess soll anhand einer Webanwendung digitalisiert werden. Die Anwendung soll den Mehraufwand beseitigen, der durch die unkoordinierte E-Mail Kommunikation entsteht. Gleichzeitig soll dabei der Onlineauftritt des Innovation Networks erweitert werden, um den Benutzern, Besuchern und Mitglieder des Netzwerks eine transparente und informationsgewinnende Erfahrung zu bieten.
Vorgehen:
Anhand der Analyse der Abläufe sowie der Handlungen und Interessen der involvierten Parteien wird Einsicht in den zugrundeliegenden Prozess gewonnen. Aus den gesammelten Erkenntnissen geht ein Anwendung hervor, welche die bisherige Abwicklung ablöst bzw. optimiert und mit geringfügigem Zusatzaufwand in die bestehende Webseite integriert werden kann. Das Ergebnis bildet die Konstellation aus einem Reverse Proxy, der sich um die nahtlose Umleitung von der bestehenden Webseite kümmert und einer Full-Stack Anwendung, die für die Haltung, Verarbeitung und Darstellung der Daten verantwortlich ist
FreeCursor MediaPipe API
Problem
Touch-Oberflächen sind für die meisten normalen Geräte üblich ausser für Beamer. Im Moment werden Präsentationen jeweils mit einem Laserpointer bedient. Ein projiziertes Bild hat keine Möglichkeit die Oberfläche auf eine Berührung abzufragen. Mit zusätzlichen Hilfsmitteln wäre es technisch machbar die Koordinaten einer Berührung zu erkennen, dies würde Kosten verursachen und möglicherweise sogar zusätzliche Infrastruktur benötigen.
Ziel
Einerseits soll geprüft werden, in wie weit die MediaPipe Library verwendet werden kann, um Beamer ohne zusätzliche Hardware durch Software und mit der eingebauten Webcam in Touchpads zu verwandeln. Und andrerseits ist es Ziel, eine Beispiel-Software zu entwickeln, die es einem ermöglicht freihändig zu präsentieren und dabei auf dem Bild des Projektors/Bildschirms direkt den Cursor zu steuern.
Methode
Die Grenzen der MediaPipe API ertasten um herauszufinden, ob dieses Tool als mögliches Mittel dienen kann, eine Hand vor dem Bild eines Projektors auf dem Videostream einer eingebauten Webcam zu erkennen. Sofern eine Hand erkannt wird, kann eine digitale Bildtransformation zur Erkennung der Bildschirmkoordinaten der Hand gemacht werden und dann die Gestik ausgelesen werden, welche zur Steuerung des Mauscursors verwendet wird.
Ergebnisse
In der ersten Projektphase wurden die Grenzen der MediaPipe API manuell unter vorher festgelegten Bedingungen ertestet. Diese Bedingungen beinhalteten sowohl Infrastruktur als auch projizierten Bildinhalt. Daraus ergab sich, dass Tageslicht einen grossen Einfluss auf die Stabilität der Funktionsweise der MediaPipe API hat. Weiter ergab sich daraus, dass ein projiziertes Bild, welches stark gesättigte Farbanteile hat, ein Erkennen von Händen mittels der MediaPipe API verunmöglicht. Aus diesen Ergebnissen resultierende Tests haben aufgezeigt, dass ein Lösen dieser Probleme mittels konventionellem Vorgehen in der vorgegebenen Zeit nicht möglich war. Daraufhin wurde die Idee einen Beamer zu steuern verworfen und ein gestengesteuerter Touchscreen-Maus-Treiber für den Nontouch-Bildschirm entwickelt.
Empfehlungen
Für weitere Projekte, welche dieselbe Aufgabe umsetzen möchten empfiehlt es sich die Wahl der Trainingsdaten so zu treffen, dass die Test-Situation ungefähr den in dieser Arbeit beschriebenen Infrastruktur-Szenarien und Hintergrundbild-Dimensionen entspricht. Unsere Lösung zeigt, dass es grundsätzlich möglich ist, einen Beamer softwarebasiert in ein Touchpad zu verwandeln. Damit das Verfahren aber nicht nur für externe Bildschirme sondern auch konventionelle Beamer funktioniert, ist es erforderlich, dass das neuronale Netzwerk, welches zur Erkennung der Gesten verwendet wird, auch mit entsprechenden Bildern trainiert wird.
Schlüsselwörter
MediaPipe API, Beamer-Bedienung, Computersteuerung via Webca
UX-Hypothesen durch Web Analytics Daten überprüfen
Dieser Masterarbeit lag die Annahme zugrunde, dass Analytics Tools immer mächtiger werden, die UX-Community deren Möglichkeiten aber noch nicht vollends ausschöpft. Deshalb wurde mit Hilfe von Literaturrecherche, Experten-Interviews und einer Fallstudie die folgende Forschungsfrage untersucht: «Können UX-Hypothesen durch Web Analytics Daten überprüft werden?»
Das aus der Literaturrecherche und den Experten-Interviews angeeignete theoretische Wissen wurde festgehalten und in der Fallstudie praktisch angewendet. Die Fallstudie wurde hypothesenbasiert mit Lean UX durchgeführt und dreht sich um die «League of Legends» Guide-Seite lolchampion.de. Das Ziel der Auftraggeber ist, dass die Nutzer*innen länger auf der Webseite verweilen und regelmässig wiederkehren sollen. Mit dem Lean UX Canvas wurde dieses Ziel in anzustrebende Business Outcomes übersetzt.
In jedem Cycle wurden Hypothesen formuliert und daraus entsprechende Lernziele als Fragen abgeleitet. Zur Beantwortung dieser Fragen wurden jeweils Experimente durchgeführt. Basierend auf den Erkenntnissen der ersten drei Cycles wurde ein «Trainingsplan» Feature entwickelt. Parallel dazu wurden bestehende Web Analytics Daten von lolchampion.de analysiert und die Proto-Personas damit erweitert. Im vierten Cycle wurde ein Landing-Page Test umgesetzt. Damit wurde überprüft, ob die Nutzer*innen das Feature nutzen und ob Interesse an einer Weiterentwicklung besteht. Die Messkriterien, mit denen die UX des Trainingsplans gemessen wurde, wurden mit dem HEART Framework und dem Goals-Signals-Metrics Prozess definiert.
Die Fallstudie kann als Erfolg gewertet werden, denn durch das Feature «Trainingsplan» konnten die definierten Business Outcomes (15% höhere Retention und Engagement Overall) erreicht werden. Die Messung der Adoption zeigte eine reges Interesse der Nutzer*innen. Der Task Success von 87% zeigte, dass das Feature erfolgreich genutzt wird. Basierend auf diesen Ergebnissen entschieden die Auftraggeber, den Trainingsplan in Zukunft weiter auszubauen. Das Team empfiehlt, die nun geschaffene Baseline
durch die HEART-Metrics weiterhin regelmässig zu vergleichen und dadurch Veränderungen in der UX festzustellen.
Basierend auf diesen Ergebnissen kann auch die Forschungsfrage positiv beantwortet werden. Die Hypothesen konnten mit Web Analytics Daten mit Hilfe von Google Analytics und Hotjar überprüft werden
SmartEating
Einleitung: SmartEating bietet eine Plattform zum Finden von simplen und benutzerdefinierten Kochrezepten. Das Herzstück von SmartEating bildet eine Webapplikation, die basierend auf physischen Merkmalen des Benutzers auf ihn zugeschnittene Rezepte empfiehlt. Die Rezepte werden als Paket bestehend aus Frühstück, Mittagessen und Abendessen präsentiert und bilden somit einen Ernährungsplan für einen Tag.
Ziel der Arbeit: SmartEating soll es ermöglichen, eine ausgewogene und abwechslungsreiche Ernährung mit minimalem Aufwand sicherzustellen. Der Benutzer kann aus einer vordefinierten Liste von Rezepten seine Lieblingsrezepte auswählen. SmartEating kümmert sich um die Erfüllung der empfohlenen Tagesdosis an Nährstoffen. Dabei sollen simple Rezepte, die einfach und unkompliziert zubereitet werden können, bevorzugt werden.
Ergebnis: SmartEating berechnet, basierend auf physischen Merkmalen des Benutzers, die täglich empfohlene Tagesdosis an Nährstoffen. Zusätzlich wird die Komplexität jedes Rezepts mithilfe eines Algorithmus bestimmt, der dem Rezept einen Komplexitätswert zuweist. Dieser Algorithmus wurde im Zuge dieser Arbeit entworfen und implementiert. Er berücksichtigt sechs Attribute pro Rezept und errechnet daraus einen Komplexitätswert im Intervall von null bis sechs. Null bedeutet sehr simpel, sechs sehr komplex. Die Hälfte der Attribute werden mithilfe von Natural Language Processing analysiert, die andere Hälfte wird aus Metainformationen zum Rezept gewonnen. Die Attribute sind so gewählt, dass sie die Komplexität der Zubereitung des Rezepts möglichst objektiv und vergleichbar repräsentieren. Die Rezepte werden innerhalb ihrer Kategorie (Frühstück, Mittagessen und Abendessen) aufsteigend nach Komplexitätswert angezeigt. Aus den Rezeptvorschlägen kann ein Tagespaket beliebig zusammengestellt werden. Jedes Paket, bestehend aus drei Mahlzeiten, erfüllt die empfohlene Tagesdosis des Benutzers
Einsatzplanungstool für Compass Security
Firmen welche Dienstleistungen für Kunden erbringen, benötigen so gut wie immer eine Software fürs Projektmanagement. Daher gibt es auch sehr viele Projektmanagementlösungen, die diese Firmen dabei unter-stützen sollen. Im Falle der Compass Security wird aktuell eine solche Projektmanagement-Software verwendet, welche aber nun durch eine neue Webapplikation ergänzt werden soll.
Diese Arbeit befasst sich mit der Anforderungsanalyse, Konzeption und Umsetzung eines Prototyps dieser Webapplikation für die Einsatzplanung von Mitarbeitern. Im Rahmen dieser Arbeit wurden mit dem Auftraggeber Anforderungen iterativ erhoben.
Basierend auf den gesammelten Anforderungen entstand der hierbei entwickelte Prototyp. Dieser umfasst für die Compass Security zentrale Funktionalitäten, wie zum Beispiel Single Sign-on, Synchronisation von Updates über verschiedene Geräte, sowie die Planung von Mitarbeiter-Einsätzen mittels direkter Manipulation.
Vor Abschluss der Arbeit wurden mit Mitarbeitern der Compass Security ein Usability Test durchgeführt, um wichtige Inputs zur User Experience zu sammeln. Kritische Fehler oder schnell umsetzbare Features wurden noch vor Ende der Arbeit umgesetzt. Die weiteren Massnahmen, welche durch diese Tests entstanden sind, wurden für die spätere Weiterentwicklung dokumentiert und soweit sinnvoll mit einer Zeitschätzung ergänzt
Debugging Support for Reactive Programming with RxJS
Software engineers use numerous software tools in their daily working routine. These tools help them to streamline complex and repetitive tasks. Integrated development environments bundle such utilities ready-to-hand. This way, engineers benefit from a seamless developer experience where every tool feels and looks like a part of its host application and is only a keypress away. Of course, debuggers are a vital component of this toolset.
Debuggers built into contemporary development environments are tailored to work best with programs following an imperative programming style. However, when used with different programming paradigms, such as reactive programming, these tools do not adequately assist the engineers. This is why software engineers resort to more simple debugging techniques like manual print statements instead.
This summative thesis documents the debugging techniques engineers employ to debug programs implemented using RxJS, a popular library providing reactive programming functionality for JavaScript. First, it reveals why engineers abstain from using specialized reactive debugging tools by identifying a critical success factor for such utilities: A reactive debugger must be ready-to-hand, integrating with the engineers’ overall developer experience. Subsequently, the thesis illustrates the iterative research and development process of a ready-to-hand reactive debugger for Microsoft Visual Studio Code. “RxJS Debugging for Visual Studio Code” provides with Operator Log Points a novel reactive debugging utility. To my knowledge, this is the first reactive debugger that allows engineers to inspect RxJS applications’ runtime behavior without leaving their development environment or adding manual print statements
Visual OO Debugger (Folgearbeit)
Object-oriented programming can be a challenge for unexperienced or new developers. The relations between objects, variables, and the concept of call-by-reference in methods is difficult to comprehend for a lot of people, sometimes even for more experienced developers. Teaching object-oriented programming can be just as challenging as learning it. One of the best ways to teach this topic is to visualize the relations between objects and variables. In the autumn term of 2021, as our term project, we created the VS Code extension Visual OO Debugger, VOOD for short, whose goal it was to ease the process of learning and teaching the concepts of object-oriented programming. It achieves this by using debugger information at runtime to visualize objects and variables in a graph.
The goal of this project is to extend VOOD with more useful features, as well as adapt the code to facilitate further extension. The current library used for visualization, vis.js, is a great starting point, but it has its limitations. Thus, the main feature of this project is to add the option to change the visualization style. Currently, only Java is supported by VOOD. While the support of other languages is out of scope, it should be possible to add support for them. Since the Java specific parts are intertwined with the rest of the debugger, the code must be refactored to separate them.
The result was a new version of VOOD with many new features and improvements. As for the main feature, a new visualization was added, utilizing the library JointJS. JointJS was already evaluated in the term project and was deemed fit as an alternate visualization. It offered more flexibility for customization but at the cost of more complexity. Another new feature was the option to choose a stack frame of the call stack in a dropdown and visualize it. Hitherto, the topmost stack frame was always used for the visualization and other stack frames were discarded. With the growth of the graph, it becomes more and more confusing and polluted with information, which the user might not want. Two features were added to counteract this problem. By clicking on a node, it collapses with its referenced nodes, and they form a cluster. Those clusters can be opened either by clicking on them separately or by clicking the left button in the upper right-hand corner to open all clusters at once. The second feature involves the right button in the upper right-hand corner. By dragging a node or cluster of nodes over this button, they can be hidden completely from the visualization. And by clicking that button, all hidden nodes and clusters are displayed again. These are just a fraction of the features and improvements implemented in this project