1194 research outputs found
Sort by
Persona-Builder
Zunehmend gewinnt das Konzept der Spendenpersonas im Non-Profit-Bereich an Bedeutung, um die Interaktion zwischen Non-Profit-Organisation und Spendenden gezielter und adressatengerecht zu gestalten. ANT-Informatik AG greift diesen Trend in ihrer Gesamtlösung im Bereich des Fundraising- und Spendenmanagements mit der Integration eines neuen Moduls zur Verwaltung von Spendenpersonas auf. Das Modul soll Spendenpersonas als zentrales Konzept weiter etablieren und die langfristige Pflege derselben ermöglichen.
Ziel der vorliegenden Arbeit ist es zu untersuchen, wie eine solche Applikation zur Definition und Konfiguration von Spendenpersonas gestaltet sein muss, um die applikationsgestützte Verwaltung von Spendenpersonas optimal zu nutzen. Hierfür soll eine Lösung konzipiert und validiert werden, welche einen Mehrwert gegenüber herkömmlich dokumentierten Spendenpersonas in PowerPoint oder auf Flipcharts schafft.
Da es sich um ein Produkt handelt, welches sich erst in Konzeption befindet, und die damit einhergehenden Interaktionen erst in Form von Hypothesen vorliegen, sind ungenaue Zieldefinitionen und ungenauer Zielumfang mitunter Hauptrisiken des Projekts. Deshalb wird mit dem Collaborative UX Design [Steimle and Wallach 2018] ein Vorgehensmodell gewählt, welches iterativ ist und die kollaborative Zusammenarbeit in interdisziplinären Teams fördert und fordert. So kann sich das Projektteam Schritt für Schritt einer Lösung annähern und den Projektumfang eingrenzen. Dabei werden sämtliche Phasen des Modells durchlaufen, wobei die MVP-Planung durch eine Übergabe der Ergebnisse an die Auftraggeberin ersetzt wird.
Als zentrale Artefakte werden der Auftraggeberin die validierte User-Persona, Szenarien, die User Story Map sowie ein klickbarer Prototyp übergeben. Die Ergebnisse aus den Usability-Testings und konkrete Handlungsempfehlungen aus Projekt- und Produktsicht sind in einem Abschlussbericht festgehalten. Eine wesentliche Erkenntnis aus den Research-Aktivitäten ist, dass die Erarbeitung von Spendenpersonas voraussichtlich weiterhin ausserhalb des Systems an Workshops erfolgen wird. Die strukturierte Erfassung von Spendenpersonas führt jedoch zu einem Mehrwert, wenn das Persona-Set validiert und mit Daten von realen Spendenden verknüpft werden kann
Debugging Support for Reactive Programming
Debugging reactive data-flow-oriented applications is a cumbersome
task. Unfortunately, modern development environments
provide only suitable tools to debug control-floworiented
programs. As a result, software engineers utilizing
RxJS, a popular library for reactive programming in
JavaScript, use inapt debugging tools, utilities outside of
their accustomed IDE, or antiquated debugging practices like
manual print statements. This paper presents two contributions
to reactive debugging: (i) Operator log points, a novel
debugging utility for reactive programming, make manual
print statements obsolete.We implement them for RxJS as an
extension for Microsoft Visual Studio Code. By doing so, we
integrate the utility with the workflow of software engineers
seamlessly, thus (ii) proof the feasibility of a ready-to-hand
debugging utility for reactive programming by existence
OSM Monitoring Tool
The search & rescue organization [Schutz & Rettung Zurich](https://www.stadt-zuerich.ch/pd/de/index/schutz_u_rettung_zuerich.html) are taking different resources into account, when preparing an operation. One of these resources is [OpenStreetMap](osm.org) which is openly licensed. Therefore Schutz & Rettung Zurich has to ensure the correctness of the analysed data. To efficiently track and monitor the data integrity a tool is needed to list and filter changesets in Switzerland. Changesets are grouped modifications with a time-stamp whenever the data of OSM is edited.
Schutz & Rettung Zurich requested a tool to track and monitor changesets with the possibility to filter for specific features, called tags, directly on the underlying data of OSM.
"OSM Monitoring Tool" is a full stack web application and consists of three parts: The first part is the front-end (Javascript, [Quasar](https://quasar.dev/)) which enables the user to interact with the application. The second part is a [PostgreSQL](https://www.postgresql.org/) database for storing all the required data such as application specific information, as well as the complete history of the changeset data of OSM of Switzerland (tables changesets, users) and its underlying objects (tables nodes, ways, relations). The database gets updated with the newest modifications on a regular basis. The third part of the application is the business layer (Python, [Django](https://www.djangoproject.com/)). The business layer is responsible for handling all requests from the front-end, processing the data and gathering the necessary information from the database. For an easy deployment every part of the application runs in separate [Docker](https://www.docker.com/) container and the entire application can be started with a couple commands.
Schutz & Rettung Zurich has announced that their data curators will be using OpenStreetMap in their daily work in the near future
Cloud Native App Entwicklung im Finanzbereich
Seit der Corona Pandemie haben viele Mitarbeitenden das Homeoffice kennen und schätzen gelernt.
Arbeitgebende überlassen es mittlerweile oft den Mitarbeitenden selbst, ob sie im Büro oder von zu Hause aus arbeiten möchten.
Aufgrund dieser Möglichkeiten sind sehr selten alle Mitarbeitenden gleichzeitig im Büro und es werden somit nicht mehr alle Arbeitsplätze benötigt.
Dadurch kommt in immer mehr Firmen das Prinzip "Desk-Sharing" auf, bei welchem es keine fix zugeteilten Arbeitsplätze mehr gibt.
Im Rahmen dieser Arbeit soll anhand des Vorbilds der geteilten Arbeitsplätzen die Grundlage einer Applikation für das Teilen der Parkplätze bei der LGT Financial Services AG entwickelt werden.
Damit soll die Auslastung optimiert werden.
Um der LGT diese Funktionalität zu ermöglichen, wurde im Verlauf dieser Arbeit eine Cloud Native Applikation, bestehend aus modular aufgebauten Microservices in einem Azure Kubernetes Cluster, entwickelt.
Weiter soll eine Cloud IDE evaluiert werden, über welche die gesamte Entwicklung umgesetzt werden kann.
Damit erhofft sich die LGT eine bessere und einfachere Wartbarkeit der benötigten SDKs, da diese nun zentral und nicht mehr auf jedem Client gemanaged werden müssen.
Als Ergebnis dieser Arbeit entstand die "LGT Parkonomy"-Applikation über welche es möglich ist, Benutzer, Standorte sowie Parkplätze zu erfassen und diese für einen gewissen Zeitraum freizugeben.
Freie Parkplätze können für einen ausgewählten Zeitraum über die Applikation gebucht und eingesehen werden.
Die "LGT Parkonomy"-Applikation kann aufgrund der Progressive Web App (PWA) Architektur über einen herkömmlichen Web-Browser, aber auch auf allen mobilen Plattformen als App gespeichert werden.
Mit der PWA als App kann ohne zusätzlichen Aufwand ein nahezu "native-App feeling" auf der jeweiligen Plattform gewährleistet werden.
Die Applikation besteht aus verschiedenen Backend-Microservices, geschrieben in ASP.NET sowie mehreren Frontend-Microservices, welche auf React basieren.
Die Frontend Microservices wurden als Single-Page Application (SPA) entwickelt und werden schlussendlich über den Haupt-Frontend-Microservice den Benutzern als PWA angeboten.
Die gesamte Applikation wird im eigenen Azure Tenant der LGT betrieben. Die Microservices laufen in einem Kubernetes Cluster und für die Persistenz wurde der Azure SQL-Datenbank Service ausgewählt.
Die Microservices werden automatisch über die GitLab Pipeline im entsprechenden Namespace des Kubernetes Clusters deployed, sobald ein Merge in den entsprechenden Branch stattfindet.
Die gesamte Entwicklung wurde mit der evaluierten Cloud IDE Gitpod umgesetzt, welche ebenfalls auf Microservices basiert und in einem separaten Namespace auf dem gleichen Kubernetes Cluster gehosted wird
SecureRole (BA)
Over the last couple of years, cyber security attacks have become a dominant issue in the global landscape. Phishing campaigns are on the rise and the world is in a current "gold rush for ransomware". Companies are being targeted with an increased frequency all around the world. This calls for IT experts, which often receive their first in-depth training in security during their time at college or in secondary education. The goal of this thesis is to better prepare students with the development of an incident response role-playing game. This can be achieved by collaborative training and using simulations to mimic a situation as close as possible to the real-world scenario. Teaching with versatile and adaptable scenarios builds up skills to prepare a company against different kinds of attacks and how to mitigate them, should one of its systems be compromised. Additionally, they learn to appropriately react, how to communicate, and on which basis to make meaningful decisions, as a key to success for eradication of the attacker and recovery to normal operation.
The result of the bachelor thesis is a framework, that gives guidance for the creation of packages and scenarios in a versatile and adaptable way, packages, that can be chained to create scenarios, and predefined scenarios to directly start a cybersecurity role-playing game. The framework allows for interchangeable content, which makes it possible to change certain parts of the role-play giving it an agile nature. The packages also include additional materials, such as text scripts, presentations, and curated internet content to deepen the knowledge about cyber security attack techniques and mitigations. The predefined scenarios are created with the packages and were tested during the thesis.
It started with an analysis of existing products, we evaluated if any of them could be an exact fit for our purposes. Sadly, none of them fully met the requirements. So we then used them to draw inspiration for our product. After we defined how the game is going to be played and how the framework for content creation is structured, we started the process of content creation itself. For verification and improvements of the content, we established a process of peer-reviews, asked external educators for their opinions, and tested it with our target audience. The created content was finally verified with an acceptance test, the results of which allowed for final improvements to be made to the product.
The landscape of cybersecurity threats is ever-changing, and incident responders need to be trained with an adequately agile approach. Our product offers a solid framework that allows us to create, edit and change our scenarios to keep the simulation dynamic and tailor it to the user's needs. This allows us to provide an interactive learning experience that helps inexperienced students take their first steps in a simulated environment, or advanced students hone their skills.
Keywords: Instructional design, Cyber security simulation, Tabletop game, Game-based learnin
Stockit - Securities Trading of Concepts Implementierung
Die Identifikation von neuen, profitablen Produktkonzepten ist eine aufwändige Angelegenheit. Bestehende Methoden der Präferenzmessung wie beispielsweise Umfragen oder Conjoint-Analysen sind für das durchführende Unternehmen mit erheblichem finanziellem Aufwand verbunden und für die Probanden eine trockene Angelegenheit. Dahan et al. beschreiben in ihrem 2010 im Journal of Marketing Research erschienen Paper eine kostengünstige und skalierbare, alternative Methode der Präferenzmessung namens Securities Trading of Concepts (STOC), nach der Produktkonzepte von den Probanden wie Wertschriften an der Börse gehandelt werden. Am Ende der Handelsphase erfolgt die Auswertung, wobei das Konzept mit dem grössten VWAP bzw. Medianpreis gewinnt. Dahan et al. führten ihre STOC-Spiele mit dem MIT Web Market Simulator aus. Diese Applikation wurde zur Durchführung von verschiedensten Marktexperimenten entwickelt und ist daher nicht speziell auf die Bedürfnisse zur Durchführung von STOC-Spielen zugeschnitten. Im Rahmen dieser Studienarbeit sollte eine moderne Web-Applikation zur Erstellung, Durchführung und Auswertung von STOC-Spielen entwickelt werden.
In einem ersten Schritt musste im Kontext der Domainanalyse ein geeignetes Marktmodell evaluiert werden. Die Wahl fiel auf einen Continuous Double Auction Market. Für das Marktmodell wurde ein Interface definiert, sodass in Zukunft mit geringem Aufwand zusätzliche Marktmodelle implementiert werden können. Im nächsten Schritt wurde eine Anforderungsanalyse durchgeführt. Die Anforderungen wurden aus dem STOC-Paper gewonnen und im Gespräch mit dem Betreuer präzisiert. Aufgrund der Ergebnisse der Anforderungsanalyse konnten schliesslich Wireframes für das User Interface erstellt werden. Anschliessend erfolgte die Evaluation der Technologien, wobei die Wahl für das Frontend auf Vue.js und für das Backend auf NestJS fiel. Als Datenbank wird PostgreSQL eingesetzt. Die Kommunikation zwischen Front- und Backend findet mittels einer REST und einer Socket.io Schnittstelle statt. Zur Validierung der Applikation wurden automatisierte Unit- und Integrationstests erstellt. Am Ende der Entwicklungsmeilensteine wurden zudem manuelle Systemtests durchgeführt.
Das Ergebnis dieser Arbeit ist eine Web-Applikation, die die Erstellung, Durchführung und Auswertung von STOC-Spielen ermöglicht. Bei der Erstellung eines STOC-Spieles stehen zahlreiche Konfigurationsmöglichkeiten zur Verfügung. So kann der Organisator beispielsweise die Transaktionsgebühren oder das Startkapital der Trader festlegen. Während einem STOC-Spiel haben die Trader in Echtzeit Zugriff auf Marktinformationen und erhalten einen detaillierten Überblick über ihr Portfolio sowie ihre Performance. Am Ende eines STOC-Spieles wird für den Organisator ein Bericht generiert, mit dem er entscheiden kann, welches Produktkonzept weiterverfolgt werden sollte.
In zukünftigen Arbeiten sollten ausführliche Testdurchläufe mit ca. 50 Tradern durchgeführt werden, um Stockit konzeptionell und technisch zu validieren. Ferner könnten neue Marktmodelle implementiert oder der bestehende Continuous Double Auction Market ausgebaut werden
Kryptowährungen als Zahlungsmittel bei FlatFeeStack
Die heutige IT-Industrie ist sich ohne Open-Source Software nicht mehr vorzustellen. In vielen Services steckt ein Teil Open-Source drin. Darum ist es umso wichtiger, dass diese Software regelmässig gewartet wird, damit keine Sicherheitslücken auftreten. Ein Beispiel dafür ist die Schwachstelle in Log4j, die in der ganzen Welt für Unruhe gesorgt hat. FlatFeeStack ist eine Plattform, die es vereinfacht Open-Source-Projekte zu unterstützen damit in Zukunft solche Probleme vermieden werden können.
Das Ziel dieser Arbeit ist es die bestehende Applikation, um eine Einzahlung in Kryptowährungen zu erweitern. FlatFeeStack wünscht sich, dass Einzahlungen in Ethereum, NEO und Tezos in Zukunft möglich sind.
Als erstes wurde die aktuelle Applikation analysiert und die bestehenden Prozesse diskutiert, um ein Verständnis für die Abläufe zu entwickeln. Ebenfalls wurde die einzusetzende Technologie unter die Lupe genommen, um die Möglichkeiten und Limiten der einzelnen Kryptowährungen kennenzulernen. Nach dem Ausarbeiten mehrerer Möglichkeiten für die Implementation, wurde die beste Option gewählt. Darauffolgend wurde das Halten und Auszahlen schrittweise um die Möglichkeit von Kryptowährungen erweitert. Zeitgleich wurde eine Währung nach der anderen angebunden.
Die Integration der Kryptowährungen als neues Zahlungsmittel, inklusive Deployment auf die Testumgebung, konnte erfolgreich abgeschlossen werden. Um die Implementation zu vereinfachen, wurde NOWPayments als Gateway für Kryptowährungen eingesetzt.
NOWPayments bietet noch gewisse Einschränkungen im Bereich der Integration an die Test Blockchains sowie der NEO3 Unterstützung. In Zukunft könnte NOWPayments durch eine alternative Lösung ersetzt werden, die Testnetze sowie NEO3 unterstützt
Synthetische Datengenerierung aus PostgreSQL für PostgreSQL
In den Bereichen Software- und Data-Engineering sowie Machine-Learning besteht eine grosse Nachfrage nach umfangreichen Datensätzen. Dabei ist Datenschutz oftmals ein Grund, keine Realdaten zu verwenden. Die Generierung von synthetischen Daten mit ähnlichen statistischen Eigenschaften wie die Originaldaten ermöglichen es, einfach solche Datensets zu erstellen.
Das Kommandozeilen-Tool pgsynthdata erzeugt synthetische Daten ausgehend von einer PostgreSQL-Datenbank und füllt diese in eine generierte Datenbank mit gleicher Struktur ab. Grundlage für die Datengenerierung bilden statistische Werte, die PostgreSQL zur Verfügung stellt.
Ziel der Arbeit ist es, den bestehenden Prototyp in einen wartbaren, erweiterbaren und einfach zu nutzenden Zustand zu überführen. Das Programm soll auf beliebigen PostgreSQL-Datenbanken anwendbar sein und vollständig synthetisch generierte Datenbanken erstellen. Die schon unterstützten Datentypen sollen um weitere Datentypen ergänzt werden.
Unter Berücksichtigung gängiger Software Design Praktiken und Einbindung moderner Entwicklungswerkzeuge wurde ein umfassendes Refactoring vorgenommen und ein Plugin-System für die leichte Anbindung der Datengeneratoren geschaffen. Durch die Implementierung von neuen Generatoren für bisher noch nicht unterstützte Datentypen wie Arrays, Enums oder Spatial-Types (PostGIS) wurde das Tool einerseits erweitert und andererseits das Plugin-System validiert.
Entstanden ist ein wartbares und erweiterbares Programm mit einem flexiblen Plugin-System für Generatoren. Durch die klare Trennung nach Zuständigkeit der Module konnte die Qualität und Testbarkeit erhöht werden. Die neuen Generatoren haben demonstriert, dass sich das Plugin-System auch für komplexere oder benutzerdefinierte Datentypen eignet. Spezifische Generatoren ermöglichen über eine benutzerfreundliche Konfiguration die individuelle Anpassung an erweiterte Anwendungsfälle, wie die Generierung von realistische Personendaten oder Adressen
Kraken 2.0 - Datenaggregation in der Netzwerkautomatisierung
Bei der Netzwerkautomation sind die benötigten Informationen oft verstreut, so dass der Netzwerkengineer meist die einzige Person ist, welche genau weiss, was wo zu finden ist.
Änderungen im Netz können deshalb zeitaufwändig werden und bei redundanten Daten in verschiedenen Quellen zu inkonsistenten Werten führen.
Deshalb besteht der Wunsch nach einer Single Source of Truth (SSoT).
"Kraken" als SSoT soll also Daten aus verschiedenen Quellen zusammenziehen, die Produkte der Firmen aber nicht ablösen, sondern diese um neue Funktionen erweitern, damit so u.a. auch die Herstellerunabhängigkeit erreicht werden kann.
Anhand von Interviews mit verschiedenen Firmen soll ermittelt werden, welche Umsysteme vertreten sind und wofür sie verwendet werden.
Wie gehen die Firmen mit ihren Daten und der Automation um?
Es besteht eine Vorgängerarbeit namens "Kraken", die dieses Problem angeht.
In dieser Arbeit soll nun die Datenstruktur flexibler implementiert werden und mehr Informationen abdecken.
Die Datenstruktur soll nun auch Meta-Informationen wie Rack, Location und IP-Segmentation unterstützen.
Konflikte bei Attribut-Werten sollen erkannt und aufgelöst werden.
Durch die Interviews und den Fokus auf die Workflows der analysierten Firmen, konnten deren involvierte Umsysteme ermittelt werden.
Die Interviews ermöglichten einen Einblick darin, was deren Workflows und wo deren Pain-Points im Hinblick auf die Automation sind.
Leider haben uns die Interviews keine Workflows geliefert, welche direkt für den Test von "Kraken 2.0" hätten verwendet werden können.
Für das Mergen von Daten wurden mehrere Konzepte in Betracht gezogen und ein auf Ähnlichkeiten basierender Algorithmus implementiert.
Die Applikation kann nun unterschiedlichere Informationen verarbeiten.
Hierzu wurde aufgezeigt, wie verschiedene Informationen aus dem Netzwerk aus verschiedenen Quellen miteinander in Beziehung stehen und in welcher Art sie miteinander verbunden werden können. Mit diesem Wissen wurde ein flexibleres Datenschema entwickelt, welches schliesslich in der bestehenden Applikation implementiert wurde
LTB Organizer
Ausgangslage:
Der Lab Topology Builder (LTB) ist eine Applikation des “Institute for networked solutions (INS)”, welche für Forschungs- und Schulungszwecke benutzt wird, um virtuelle Umgebungen bereitzustellen. Das Tool ist eine strategische Ressource des INS und hat für die Zukunft eine hohe Relevanz.
Die virtuellen Umgebungen sind durch Labs definiert, welche die Geräte (Virtual Machines (VM), Docker Container, etc.) und Verbindungen unter den Geräten definieren. Die Labs werden auf unterschiedlichen physischen Servern bereitgestellt. Das Deployment, sowie die Entfernung eines Labs wird durch den Benutzer manuell angesteuert. Dies bedingt, dass keine Planung zur Auslastung und zur Reservation von Ressourcen existiert und teilweise die verfügbaren Server überbeansprucht werden, bzw. nicht voll ausgelastet sind.
Ziel der Arbeit:
Ziel der Arbeit ist eine zentrale Organisation und Koordination der Ressourcen und deren Deployment im LTB. Es soll nie möglich sein, mehr Ressourcen in Anspruch zu nehmen, als dass verfügbar sind. Um eine Planung der Ressourcen zu ermöglichen, soll die Bereitstellung der Labs nur noch über die Erstellung von Reservationen möglich sein. Die Bereitstellung und die Entfernung der Labs sollen neu automatisch und anhand der definierten Reservationen erfolgen.
In Zukunft soll es möglich sein, eine Art “Credit-System” zu implementieren. Dieses soll ermöglichen, die zeitliche Nutzung von Ressourcen für einen Benutzer zu beschränken. Zusätzlich soll es zukünftig möglich sein, die Dienste des LTB an externe Partner zu vermieten.
Ergebnis:
In der Arbeit wurden die Ziele “Ressourcenbasiertes Deployment” und “Reservationen von Labs” konzeptionell erarbeitet und umgesetzt.
Um ein ressourcenbasiertes Deployment umzusetzen, wurden zuerst Metriken definiert, welche die physischen Ressourcen repräsentieren. Diese sind: “Anzahl an logischen CPUs”, “Arbeitsspeicher” und “Speicherplatz auf der Disk”. Diese Ressourcen müssen pro Gerät definiert werden, um zu ermitteln, wie viele Ressourcen in Anspruch genommen werden. Zusätzlich sind die verfügbaren physischen Server als “Deployment Nodes” in der Anwendung mit ihren verfügbaren Ressourcen abgebildet. Anhand der Kosten und den verfügbaren Ressourcen wird ermittelt, ob ein Lab bereitgestellt werden kann. Ebenso kann die Auslastung der einzelnen Nodes dargestellt werden.
Neu können Labs nur noch über Reservationen gebucht werden, welche einen gewünschten Start- und Endzeitpunkt definieren. Die möglichen Tageszeiten für einen Start oder ein Ende werden durch die INS-Administration definiert, um eine reibungslose Bereitstellung sicherzustellen. Einerseits wird geprüft, ob genügend freie Ressourcen im gewünschten Zeitraum zur Verfügung stehen, andererseits wird sichergestellt, dass der gewünschte Startzeitpunkt für eine Reservation eingehalten werden kann. Dafür werden für die Geräte ihre entsprechenden Deployment- und Cleanupzeiten definiert