<?xml version="1.0" encoding="utf-8"?>
<export-example>
  <doc>
    <id>212</id>
    <completedYear/>
    <publishedYear>2018</publishedYear>
    <thesisYearAccepted/>
    <language>deu</language>
    <pageFirst/>
    <pageLast/>
    <pageNumber>52</pageNumber>
    <edition/>
    <issue/>
    <volume/>
    <type>bachelorthesis</type>
    <publisherName/>
    <publisherPlace/>
    <creatingCorporation/>
    <contributingCorporation/>
    <belongsToBibliography>0</belongsToBibliography>
    <completedDate>2018-03-26</completedDate>
    <publishedDate>--</publishedDate>
    <thesisDateAccepted>2018-02-20</thesisDateAccepted>
    <title language="deu">Untersuchung der Vorgehensweise ausgewählter Internetplattformen gegen gefälschte Online-Bewertungen</title>
    <abstract language="deu">Diese Arbeit dokumentiert ein Experiment zur Untersuchung des Umgangs von Facebook, Google Maps, Google Play Store und Zalando mit gefälschten Bewertungen („Opinion Spam“). Es wurde untersucht, ob die Plattformen im Rahmen dieser Arbeit abgegebene gefälschte Bewertungen veröffentlichen. Dazu wurden je Plattform 24 unterschiedlich authentisch wirkende Konten erstellt. Mit diesen wurden je 48 gefälschte Bewertungen nach folgenden Kriterien abgegeben: 1) Kopierte Produkt-/Ortsbeschreibung oder Werbesprache 2) Aussagen ohne Produkt-/Ortsbezug oder inhaltliche Fehler 3) Blindtexte oder sehr viele Rechtschreibfehler 4) eine Meinung verknüpft mit der Aussage, dass der Bewertende das Produkt/den Ort nicht kennt. Innerhalb von 14 Tagen wurde mehrmals überprüft, ob eine Bewertung freigeschaltet oder gelöscht wurde. &#13;
Bei Facebook wurden 6,7% der abgegebenen Bewertungen innerhalb der ersten 14 Tage gelöscht. Nachdem die verbleibenden Bewertungen der Plattform gemeldet wurden, waren es 47,7%. Bei Google Maps wurden 4,2% entfernt, im Google Play Store 12,5% (bei beiden keine Änderung durch Melden). Bei Zalando (kein Melden möglich) war die eigenständige Löschquote mit 43,8% mit Abstand am höchsten. Besonders häufig wurden im Experiment Blindtexte gelöscht. Positive und negative Bewertungen wurden nahezu gleich oft entfernt. Bewertungen von Konten mit simulierter Nutzerinteraktion wurden häufiger gelöscht als Bewertungen von Konten ohne Nutzerinteraktion.&#13;
Das Experiment hat gezeigt, dass sehr viele gefälschte Bewertungen, die eindeutig den Richtlinien der Plattformen widersprechen, nicht gelöscht wurden. Deren Sichtbarkeit variiert allerdings je nach Plattform und Produkt/Ort stark. Der Aufwand für die Erstellung vieler Konten bei den Diensten ist überschaubar. Wenn Nutzer gefälschte Bewertungen nach den im Experiment untersuchten Kriterien abgeben wollen, werden sie von den Plattformen daran wenig gehindert.</abstract>
    <abstract language="eng">This bachelor thesis contains the documentation of an experiment to evaluate how Facebook, Google Maps, Google Play Store and Zalando deal with fake reviews (“opinion spam”). Measured was whether the platforms publish or delete fake reviews submitted in the context of this work. For this purpose, 24 accounts with different attributes according to age and user interaction were created on each platform. With those accounts 48 reviews per platform were submitted based on the following criteria: 1) Copied product/location description or advertising-language 2) reviews without product/location reference or contextual errors 3) Blind texts or many spelling mistakes 4) reviews which contain an opinion but state that the author does not know the product/location. &#13;
6.7% of the reviews submitted to Facebook were deleted within the first 14 days, 47.7% after reporting the remaining reviews to Facebook. Google Maps deleted 4.2%, Google Play Store 12.5% (both showed no changes after reporting). Zalando (no reporting possible) has the by far highest independent deletion rate with 43.8%. Blind texts were most often deleted during the experiment. Positive and negative ratings were deleted almost the same number of times. Reviews from accounts with simulated user interaction were deleted more often than reviews from accounts without user interaction.&#13;
The experiment showed that many fake reviews, which contradict the guidelines of the platforms, were not deleted. But their visibility varies depending on platform and product/location. The creation of many accounts at the services does not require too much effort. If users want to publish fake reviews according to the criteria used in the experiment, the platforms do not really hinder them.</abstract>
    <identifier type="urn">urn:nbn:de:hbz:1383-opus4-2126</identifier>
    <licence>CC BY 4.0 International - Namensnennung</licence>
    <author>Johannes Nolte</author>
    <subject>
      <language>deu</language>
      <type>uncontrolled</type>
      <value>Gefälschte Bewertungen</value>
    </subject>
    <subject>
      <language>eng</language>
      <type>uncontrolled</type>
      <value>Opinion spam</value>
    </subject>
    <subject>
      <language>eng</language>
      <type>uncontrolled</type>
      <value>Fake reviews</value>
    </subject>
    <collection role="ddc" number="000">Informatik, Informationswissenschaft, allgemeine Werke</collection>
    <collection role="institutes" number="">Fakultät Kommunikation und Umwelt</collection>
    <thesisPublisher>Hochschule Rhein-Waal</thesisPublisher>
    <thesisGrantor>Hochschule Rhein-Waal</thesisGrantor>
    <file>https://opus4.kobv.de/opus4-rhein-waal/files/212/BA_Nolte_opus.pdf</file>
  </doc>
  <doc>
    <id>291</id>
    <completedYear/>
    <publishedYear>2018</publishedYear>
    <thesisYearAccepted/>
    <language>deu</language>
    <pageFirst/>
    <pageLast/>
    <pageNumber>43</pageNumber>
    <edition/>
    <issue/>
    <volume/>
    <type>bachelorthesis</type>
    <publisherName/>
    <publisherPlace/>
    <creatingCorporation/>
    <contributingCorporation/>
    <belongsToBibliography>0</belongsToBibliography>
    <completedDate>2018-10-05</completedDate>
    <publishedDate>--</publishedDate>
    <thesisDateAccepted>2018-09-21</thesisDateAccepted>
    <title language="deu">Entwurf und Implementierung eines Monitoringsystems für Continuous Delivery Pipelines am Beispiel der Schleupen AG</title>
    <abstract language="deu">Die Schleupen AG ändert ihre Entwicklungsarchitektur zu Continuous Delivery (CD). Continuous Delivery beschreibt eine Reihe von Vorgängen, die als Ziel eine schnelle und sichere Softwarebereitstellung haben. Am Ende der Umstellung wird das Unternehmen eine Ansammlung von automatisierten Schritten besitzen.&#13;
In dieser Bachelorarbeit wird ein Monitoringsystem entwickelt, das eine Überwachung des Continuous Delivery Prozesses ermöglicht. Die wesentlichen Ziele sind die Erstellung eines Dashboards und das Sammeln von Telemetriedaten.</abstract>
    <abstract language="eng">The software company Schleupen AG is changing their development architecture to continuous delivery (CD). Continuous delivery describes a number of processes that enable faster and safer software deployment. At the end of the change the company will have an accumulation of automated steps.&#13;
This bachelor thesis is about the development of a system that monitors the continuous delivery process. The main focuses are the implementation of a dashboard and the use of telemetry.</abstract>
    <identifier type="urn">urn:nbn:de:hbz:1383-opus4-2919</identifier>
    <licence>CC BY-NC-ND 4.0 International - Namensnennung-Nicht kommerziell-Keine Bearbeitungen</licence>
    <author>Joshua Siegemund</author>
    <subject>
      <language>eng</language>
      <type>uncontrolled</type>
      <value>Continuous delivery</value>
    </subject>
    <subject>
      <language>eng</language>
      <type>uncontrolled</type>
      <value>Dashboard</value>
    </subject>
    <collection role="institutes" number="">Fakultät Kommunikation und Umwelt</collection>
    <thesisPublisher>Hochschule Rhein-Waal</thesisPublisher>
    <thesisGrantor>Hochschule Rhein-Waal</thesisGrantor>
    <file>https://opus4.kobv.de/opus4-rhein-waal/files/291/Bachelorarbeit.pdf</file>
  </doc>
  <doc>
    <id>854</id>
    <completedYear/>
    <publishedYear>2021</publishedYear>
    <thesisYearAccepted/>
    <language>deu</language>
    <pageFirst/>
    <pageLast/>
    <pageNumber>64</pageNumber>
    <edition/>
    <issue/>
    <volume/>
    <type>bachelorthesis</type>
    <publisherName/>
    <publisherPlace/>
    <creatingCorporation/>
    <contributingCorporation/>
    <belongsToBibliography>0</belongsToBibliography>
    <completedDate>2021-06-09</completedDate>
    <publishedDate>--</publishedDate>
    <thesisDateAccepted>2021-04-05</thesisDateAccepted>
    <title language="deu">Automatisierte Tests oberflächenbezogener Geschäftslogik mit simulierten Benutzereingaben</title>
    <abstract language="eng">A lack of stability and reliability in user interfaces leads to user dissatisfaction. If this dissatisfaction is a repeating occurence users loose trust in the software and the company behind it. In the long run this leads to a migration from existing users to competitors and less new customers. To combat these effects companies have to ensure their user interfaces are stable and reliable. The Schleupen AG provides a browserbased user interface to its customers, which is split into a display layer running in the browser and a logic layer running on the server. In this thesis an automated solution for finding such problems in the logic layer was developed and applied to a selected subset of user interfaces. The solution was able to find multiple issues with most of them representing possible stability problems. This showed that automated testing of user interfaces for stability and reliability is possible and worthwhile.</abstract>
    <identifier type="urn">urn:nbn:de:hbz:1383-opus4-8544</identifier>
    <enrichment key="opus.source">publish</enrichment>
    <enrichment key="opus.doi.autoCreate">false</enrichment>
    <enrichment key="opus.urn.autoCreate">true</enrichment>
    <licence>CC BY 4.0 International - Namensnennung</licence>
    <author>Tobias Meyer</author>
    <subject>
      <language>eng</language>
      <type>uncontrolled</type>
      <value>User experience</value>
    </subject>
    <subject>
      <language>eng</language>
      <type>uncontrolled</type>
      <value>Propertybased testing</value>
    </subject>
    <subject>
      <language>eng</language>
      <type>uncontrolled</type>
      <value>Test automation</value>
    </subject>
    <subject>
      <language>eng</language>
      <type>uncontrolled</type>
      <value>Continuous feedback</value>
    </subject>
    <collection role="ddc" number="000">Informatik, Informationswissenschaft, allgemeine Werke</collection>
    <collection role="institutes" number="">Fakultät Kommunikation und Umwelt</collection>
    <thesisPublisher>Hochschule Rhein-Waal</thesisPublisher>
    <thesisGrantor>Hochschule Rhein-Waal</thesisGrantor>
    <file>https://opus4.kobv.de/opus4-rhein-waal/files/854/bachelorarbeit.pdf</file>
  </doc>
  <doc>
    <id>1314</id>
    <completedYear/>
    <publishedYear>2022</publishedYear>
    <thesisYearAccepted/>
    <language>deu</language>
    <pageFirst/>
    <pageLast/>
    <pageNumber>53</pageNumber>
    <edition/>
    <issue/>
    <volume/>
    <type>bachelorthesis</type>
    <publisherName/>
    <publisherPlace/>
    <creatingCorporation/>
    <contributingCorporation/>
    <belongsToBibliography>0</belongsToBibliography>
    <completedDate>2022-03-03</completedDate>
    <publishedDate>--</publishedDate>
    <thesisDateAccepted>2022-02-22</thesisDateAccepted>
    <title language="deu">Untersuchung der npm Registry auf die Codequalität ihrer Pakete</title>
    <abstract language="eng">The aim of this project was to check whether the code quality of a npm package has an impact on some of its other properties.&#13;
To check possible connections, lots of data had to be gathered. This was done by collecting available information from the GitHub and npm API about each package. Additionally, packages were downloaded to analyze them with cloc for data about the amount of lines of code, and with eslint to check the package for possible errors. This process was conducted for almost all packages with a public GitHub repository, and in more detail for the most downloaded packages.&#13;
Results show that for top packages less errors lead to more popularity, this does not apply to the whole npm registry though. Furthermore, in both cases, more con- tributors in the repository lead to fewer errors. Lastly, it’s shown that the more recent packages were updated, the more popular they were and the count of packages in- creases the more recent their update was.</abstract>
    <identifier type="urn">urn:nbn:de:hbz:1383-opus4-13148</identifier>
    <enrichment key="opus.source">publish</enrichment>
    <licence>CC BY-SA 4.0 International - Namensnennung-Weitergabe unter gleichen Bedingungen</licence>
    <author>Philipp Zelle</author>
    <collection role="institutes" number="">Fakultät Kommunikation und Umwelt</collection>
    <thesisPublisher>Hochschule Rhein-Waal</thesisPublisher>
    <thesisGrantor>Hochschule Rhein-Waal</thesisGrantor>
    <file>https://opus4.kobv.de/opus4-rhein-waal/files/1314/Zelle_Philipp_Bachelorarbeit.pdf</file>
  </doc>
</export-example>
