Studien-/Bachelorarbeit oder Diplom-/Masterarbeit

Isolation vergangener Defekte in Open-Source Projekten

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.

Ansprechpartner

SebastianJekutsch oder LutzPrechelt

Sonstige Quellen

• D. Draheim and L. Pekacki: Analytical Processing of Version Control Data: Towards a Process-Centric Viewpoint, published at Freie Universität Berlin, Institute for Computer Science Technical Report B-03-07, March 2003
• Audris Mockus, Lawrence G. Votta: Identifying Reasons for Software Changes using Historic Databases, International Conference on Software Maintenance, pages 120-130, San Jose, California, October 11-14 2000.
• Michael Fischer, Martin Pinzger, and Harald Gall: Populating a Release History Database from Version Control and Bug Tracking Systems. In Proceedings of the International Conference on Software Maintenance (ICSM), pages 23-32, IEEE Computer Society Press, Amsterdam, September 2003.