Konfigurationsmanagement und Evolution: Änderungsverwaltung und Repository-Analyse. Dr. Thorsten Arendt Marburg, 13. November 2014

Transkript

1 Konfigurationsmanagement und Evolution: Änderungsverwaltung und Repository-Analyse Dr. Thorsten Arendt Marburg, 13. November 2014

2 Überblick Was ist eine Änderungsverwaltung und warum braucht man sie? Fehlerverfolgung Neue Features Bugzilla Erfassung und Verfolgung von Fehlern und neuen Anforderungen Berichte Analyse von Repositories Wie ist die Entwickleraktivität? Wo wird besonders viel geändert? 2 Software-Evolution WS 2014/2015

3 Fehlerverfolgungssysteme (Bugtracker) Fehlerverfolgungssysteme helfen, die Downtime eines Systems zu reduzieren, die Produktivität der Entwickler zu erhöhen, die Anwender zufriedener zu machen und die Kommunikation zwischen den Beteiligten zu erhöhen. (webbasierte) Werkzeuge: z.b. Bugzilla Atlassian Jira 3 Software-Evolution WS 2014/2015

4 Aufbau eines Bug-Reports Obligatorisch Status und Resolution Zusammenfassung Ein Satz Wer hat berichtet? Wem zugeordnet? Bekommt eine Soll den Bug beurteilen und gegebenenfalls beheben Priorität Sollte von Anderen nicht geändert werden. Version Produkt und Komponente Plattform und Betriebssystem Optional Wer ist für ist für die QA zuständig? Schwierigkeitsgrad von unbenutzbar bis kosmetisch CC Liste Wer sollte zusätzlich noch per davon erfahren? Kommentare Anhänge Stack Trace Beispiel Screendump 4 Software-Evolution WS 2014/2015

5 Funktionalität rund um Bugs Einen neuen Bug anlegen Einen Fehler berichten Aber auch: Ein Feature anfordern Einen Bug ändern Den Status ändern, Kommentieren, etc. Nach verschiedenen Kriterien Bugs in der Datenbank suchen Nach verschiedenen Kriterien Berichte über die Bug- Datenbank anfertigen lassen 5 Software-Evolution WS 2014/2015

6 Listen aktueller Bugs (1) 6 Software-Evolution WS 2014/2015

7 Listen aktueller Bugs (2) Such-Einstellungen: Status: NEW Contains String: Model Explorer 7 Software-Evolution WS 2014/2015

8 Beispiel für einen Bug (1) 8 Software-Evolution WS 2014/2015

9 Beispiel für einen Bug (2) 9 Software-Evolution WS 2014/2015

10 Wie beschreibt man einen Bug? (1) Der Bug sollte reproduzierbar sein. Der Bug sollte möglichst genau beschrieben sein. Das betrifft das Produkt, die Komponente, die Plattform, das Betriebssystem und die Version des Produkts. Welches Verhalten wird erwartet, welches kommt stattdessen? Wenn möglich ein möglichst kleines Beispiel, in dem der Bug auftritt Nur einen Bug pro Eintrag 10 Software-Evolution WS 2014/2015

11 Wie beschreibt man einen Bug? (2) Kein Bug ist zu trivial, kleine Bugs können größere verstecken. Fakten müssen klar von Spekulationen unterschieden werden. Beispiel: Schlecht: Das Programm stürzt ab." Besser: Der Browser zeigt meine Webseite nicht an. Gut: Drückt man den Cancel-Button im File Copy Dialog, stürzt der File Manager ab." Bug Writing Guidelines 11 Software-Evolution WS 2014/2015

12 Das Leben eines Bugs Ein Bug sollte von derselben Person geschlossen werden, die ihn eröffnet hat. Es gibt viele Wege, einen Bug zu lösen. WONTFIX ist beliebt, wenn eine genaue Beschreibung fehlt. [Bugzilla] 12 Software-Evolution WS 2014/2015

13 Analyse von Repositories Was können uns Repositories erzählen? Wie aktiv sind die Entwickler und wie ist deren soziales Netzwerk? Welche Auswirkungen haben bestimmte Änderungen? An welchen Stellen wird viel geändert? Was ist der Trend? An welchen Stellen werden vermutlich Fehler auftreten? 13 Software-Evolution WS 2014/2015

14 Analyse-Werkzeuge Erstellung eines Berichts auf der Basis von SVN- oder Git-Repositories SVN: StatSVN, TortoiseSVN, Subversion, etc. Git: gitinspector, GitStats, TortoiseGit, etc. Aktivität in Eclipse-Projekten Eclipse Dash Weitere Werkzeuge, die verschiedene Aspekte der Software Evolution darstellen: viele für CVS-Repositories z.b: Evolution Radar, Fractal Figures, Evospaces 14 Software-Evolution WS 2014/2015

15 Evolution des Projektumfangs (1) [OpenHUB ] 15 Software-Evolution WS 2014/2015

16 Evolution des Projektumfangs (2) 16 Software-Evolution WS 2014/2015

17 Entwickleraktivität Wie viele Entwickler arbeiten an einer Entität (Projekt, Paket, Klasse)? Wie war die Aktivität zwischen ihnen verteilt? Gibt es einen Entwickler, dem der Code gehört? Gibt es einen Entwickler, der sich speziell um den Code kümmert? Aktivitätsmuster: Ein Entwickler Wenige gleichberechtigte Entwickler Ein Hauptentwickler Viele gleichberechtigte Entwickler 17 Software-Evolution WS 2014/2015

18 Beispiel Entwickleraktivität (1) [OpenHUB ] 18 Software-Evolution WS 2014/2015

19 Beispiel Entwickleraktivität (2) [gitinspector] 19 Software-Evolution WS 2014/2015

20 Beispiel Entwickleraktivität (3) [TortoiseGit] 20 Software-Evolution WS 2014/2015

21 Beispiel Entwickleraktivität (4) [TortoiseGit] 21 Software-Evolution WS 2014/2015

22 Beispiel Entwickleraktivität (5) [TortoiseGit] 22 Software-Evolution WS 2014/2015

23 Beispiel Entwickleraktivität (6) [gitinspector] 23 Software-Evolution WS 2014/2015

24 Auswirkungen von Änderungen Für eine Änderung müssen häufig diverse Dateien angefasst werden. Git fasst alle Dateien, die zu einem bestimmten Zeitpunkt eingecheckt wurden, in einem Change Set zusammen. [TortoiseGit] 24 Software-Evolution WS 2014/2015

25 Versionierungsaktivität [OpenHUB ] 25 Software-Evolution WS 2014/2015

26 Was macht ein Modul fehleranfällig? Hohe Softwarekomplexität Komplexitätsmetriken korrelieren mit Fehlerraten. Unerfüllte Anforderungen, hohe Problemkomplexität Problemkomplexität korreliert mit Fehlerraten. Sich schnell ändernde Anforderungen und dadurch sich schnell ändernde Software Je mehr sich Software ändert, desto mehr Fehler enthält sie. Unsystematischer Entwicklungsprozess 26 Software-Evolution WS 2014/2015

27 Beispiel für die Evolution von Bug Reports [Bugzilla] 27 Software-Evolution WS 2014/2015

28 Welche sind die größten Dateien? [gitinspector] 28 Software-Evolution WS 2014/2015

29 Zusammenfassung Änderungsverwaltung zur Verfolgung von Fehlern und zur Planung von neuen Features. Ein Fehler bzw. Feature pro Eintrag. Bug-Beschreibung: Welche Situation finden wir vor, welche ist die gewünschte? Repositories können bezüglich der Entwickleraktivität, Änderungsauswirkungen und Aktivitäten untersucht werden. An wen muss ich bei Problemen mit Komponente X wenden? Wo wurde in letzter Zeit besonders viel geändert? 29 Software-Evolution WS 2014/2015

30 Sekundär-Literatur und Werkzeuge Bugzilla: Atlassian Jira: Eclipse Bugzilla Bug Writing Guidelines: gitinspector: Eclipse Dash: OpenHUB: TortoiseGit: M. D Ambros, H. Gall, M. Lanza, M. Pinzger: Analyzing software repositories to understand software evolution, in T. Mens, S. Demeyer: Software Evolution, 2008 T. Zimmermann, N. Nagappan, A. Zeller: Predicting Bugs from History, in T. Mens, S. Demeyer: Software Evolution, Software-Evolution WS 2014/2015