Bitte benutzen Sie diese Kennung, um auf die Ressource zu verweisen: http://dx.doi.org/10.18419/opus-11843
Autor(en): Kässmann, Tobias
Titel: Automatic issue relation prediction
Erscheinungsdatum: 2021
Dokumentart: Abschlussarbeit (Bachelor)
Seiten: xv, 53
URI: http://nbn-resolving.de/urn:nbn:de:bsz:93-opus-ds-118600
http://elib.uni-stuttgart.de/handle/11682/11860
http://dx.doi.org/10.18419/opus-11843
Zusammenfassung: Context. When developing or maintaining large component-based software systems (for example, microservices, which are getting more and more popular1), software developers are usually divided into multiple developer teams working on different components. Additionally, it is not uncommon to include third-party components in one’s software. During the development and maintenance of such a system, issues might occur. Those bugs might not harm the component they arose in but might cause failures on neighbouring ones. Traditionally, this is avoided by manually annotating or linking issues across components to indicate their relationships. Problem. In large projects, this is hardly feasible due to the lack of knowledge a single developer has over the whole system as well as the other issues/components involved. Objective. This bachelor’s thesis tries to predict issue relations using machine learning (ML), which solves the generalisation of the problem. The objective hereby is to create a data set of annotated issue relations, train ML models on it, as well as measure their performance. Method. ML models have to be trained on an existing data set of annotated issues and their relations. Those samples of issues and relations are obtained from public GitHub repositories by scraping and inferring their relations. Issue relations can be categorised into five distinct categories, namely: (1) “issue A depends on issue B” (2) “issue B depends on issue A” (3) “issue A and B do not stand in a relation” (4) “issue A and B have a mutual relation” (5) “issue A is a duplicate of B” Afterwards, a baseline model will be created to test other models against it and measure their performance. Conclusion. The conclusion would be to determine if and to what extent the method presented above will lead to good results.
Kontext. Bei der Entwicklung oder Wartung großer komponentenbasierter Softwaresysteme (z. B. Microservices, die immer beliebter werden2), werden Softwareentwickler in der Regel in mehrere Entwicklerteams aufgeteilt, die an verschiedenen Komponenten arbeiten. Darüber hinaus ist es nicht unüblich, Komponenten von Drittanbietern in die eigene Software einzubinden. Während der Entwicklung und Wartung eines solchen Systems können Probleme auftreten. Diese Fehler betreffen zwar nicht die Komponente, in der sie entstanden sind, können aber bei benachbarten Komponenten zu Bugs führen. Traditionell wird dies durch manuelle Anmerkungen oder Verknüpfungen von Bugs zwischen den Komponenten vermieden, um ihre Beziehungen zu verdeutlichen. Problem. Bei großen Projekten ist dies aufgrund des mangelnden Wissens eines einzelnen Entwicklers über das gesamte System und die anderen beteiligten Issues oder Komponenten kaum machbar. Zielsetzung. In dieser Bachelorarbeit wird versucht, Issue Relations mit Hilfe von maschinellem Lernen vorherzusagen, wodurch die Generalisierung des Problems gelöst wird. Das Ziel besteht darin, einen Datensatz mit annotierten Problembeziehungen zu erstellen, ML-Modelle darauf zu trainieren und ihre Leistung zu messen. Methodik. Die ML-Modelle müssen auf einem bestehenden Datensatz von annotierten Issues und deren Beziehungen trainiert werden. Diese Stichproben von Issues und Beziehungen werden aus öffentlichen GitHub-Repositories durch Scraping und durch die Ableitung ihrer Beziehungen gewonnen. Issue-Beziehungen können in fünf verschiedene Kategorien eingeteilt werden, nämlich: (1) “Issue A hängt von Issue B ab” (2) “Issue B hängt von Issue A ab” (3) “Issue A und B stehen nicht in einer Beziehung” (4) “Issue A und B stehen in einer gegenseitigen Beziehung” (5) “Issue A ist ein Duplikat von B” Anschließend wird ein Basismodell erstellt, um andere Modelle daran zu testen und deren Leistung zu messen. Schlussfolgerung. Abschließend wäre zu prüfen, ob und inwieweit die oben vorgestellte Methode zu guten Ergebnissen führt.
Enthalten in den Sammlungen:05 Fakultät Informatik, Elektrotechnik und Informationstechnik

Dateien zu dieser Ressource:
Datei Beschreibung GrößeFormat 
thesis.pdf1,19 MBAdobe PDFÖffnen/Anzeigen


Alle Ressourcen in diesem Repositorium sind urheberrechtlich geschützt.