Studien-/Bachelorarbeit oder Diplom-/Masterarbeit

09 Aug 2023 - 17:03 | Version 7 | UnknownUser

Isolation vergangener Defekte in Open-Source Projekten

goldminer
John Stone with gold mining pan, around 1939

Projekt

Analyse des Programmierprozesses zwecks Vermeidung von Defekten

Art

Softwareentwurfs- und rechercheorientierte Arbeit

Beschreibung

In dem oben genannten Projekt wird untersucht, unter welchen Umständen und warum Softwareentwickler Fehler machen, die letztendlich zu defekter Software führen. Ein Defekt ist dabei eine strukturelle Schwäche von Software, die sie zum Versagen führen kann. Als Fehler hingegen wird ein menschliche Fehler verstanden (falsches Wissen, Irrtümer oder Flüchtigkeitsfehler), der letztlich zum Einbau eines Defekts in die Software führt.

Eine Herangehensweise an diese in der Informatik und Softwaretechnik kaum beachtete Fragestellung ist die Untersuchung von Defekten und deren Klassifizierung (siehe DefectTaxonomy), so dass man in einem nachfolgenden Schritt die Ursachen dieser Defekte, also die Fehler, systematisch untersuchen kann.

Ausreichend große Softwareprojekte haben eine Historie mit vielen Defekten und deren Behebung durchgemacht, sie sind also die naheliegende Quelle zur Defektbetrachtung. Softwarearchäologie allgemein nutzt die Historie eines Softwareproduktes, um Aussagen über die Produkt- oder Prozessqualität zu machen oder um den Prozess, etwa die Programmierung, zu regeln und zu verbessern. Die typische in Projekten vorhandene Historie liegt in den Versionsverwaltungssystemen, aber auch z.B. in Defektverfolgungsaufzeichnungen.

Aufgabe

Ähnlich einem Goldschürfer (siehe Bild) soll mittels softwarearchäologischer Methoden eine Isolation von vergangenen Defekten in großen Softwaresystemen (z.B. frei zugänglichen Open-Source-Projekten) unternommen werden. Genutzt wird dies nicht nur im Sinne des zugrunde liegenden Forschungsprojekts, sondern auch

um Defektvorhersagetheorien (aufgrund von Code-,Test- und Änderungsmetriken) zu prüfen
um den Entwicklern durch Statistiken aus den vergangenen Defekten helfen zu lernen

Zentrale Aufgaben der Arbeit sind:

Zieldefinition und Anforderungsanalyse. Die Anforderungen ergeben sich in erster Linie aus dem Forschungsgegenstand. Wichtig ist auf jeden Fall eine Erweiterbarkeit des Systems für zukünftige Anforderungen.
Recherche vorhandener Systeme, auf die man aufbauen oder die man nutzen könnte. Dokumentation der Grenzen und Vorbedingungen ihres Einsatzes. Im Extremfall findet man ein komplettes passendes System als freie Software.
Recherchieren und Evaluieren softwarearchäologischer Techniken und Formulieren der Voraussetzungen für deren Einsatz. Im Extremfall ist es nötig, Eigenforschung zu betreiben. Diese gälte es dann genau zu definieren. Je nach Aufwand und Ergebnis könnte die Arbeit hier schon enden.
Softwareentwurf. Es könnte sein, dass man schon ein ausreichendes System gefunden hat. Dann würde hier statt dessen die unten genannte Anwendung folgen.

Dies muss natürlich nicht in dieser Reihenfolge geschehen. Nicht mehr im Rahmen einer Studien-/Bachelorarbeit erledigbar, wohl aber für die Diplom-/Masterarbeit-Variante vorgesehen sind die logischen nächsten Schritte

Implementation (wenn notwendig)
Anwendung des Systems auf ein oder mehrere große Projekte. Hier stellt sich die Frage, wie man die Güte des Ergebnisses misst und auswertet.
Evtl. Erweiterung auf Nutzung mehrerer Quellen wie Protokolle, Fehlerverwaltungswerkzeuge, etc.

Mit einem solchen Werkzeug kann man in einem nächsten Schritt eine möglichst automatische Klassifikation von Defekten angehen. Eine solche ist aber nicht Teil der Arbeit.