Qualitätssicherung
Diese Seite dient der Beschreibung von Maßnahmen und Prozessen zur Sicherung der Softwarequalität bei SDQ.
Motivation
Im Umfeld des Palladio Component Model ist bei SDQ inzwischen eine beachtliche Menge Code entstanden. Die Sicherstellung der Softwarequalität ist eine wichtige Voraussetzung für
- die Wartung, Pflege und Erweiterung des Codes sowie
- den industriellen Einsatz der PCM-Tools.
Die Qualitätssicherung wird dadurch erschwert, daß viele verschiedene Codeersteller (Mitarbeiter und Studenten) an der Entwicklung beteiligt sind und die Fluktuation naturgemäß hoch ist. Die zu definierenden QS-Prozesse müssen daher so ausgelegt sein, daß möglichst viele Maßnahmen bereits entwicklungsbegleitend angewandt werden können. Zum Zeitpunkt der Fertigstellung einer Implementierungsarbeit muss eine Abnahme stattfinden, bei der möglicherweise noch existierende Mängel aufgedeckt und behoben werden können. Eventuelle Konsequenzen bei Nichteinhaltung von QS-Anforderungen sollten ebenfalls festgelegt sein.
Die Implementierung von Softwaretests sollte entwicklungsbegleitend erfolgen, da der Codeersteller nach Fertigstellung einer Implementierungsarbeit eventuell nicht mehr zur Verfügung steht, ein nachträgliches Hinzufügen von Tests durch andere Personen jedoch wesentlich aufwändiger wäre. Wichtig ist darüber hinaus die Durchführung von Codereviews, damit Fehler und qualitative Mängel einer Implementierungsarbeit noch während der Entwicklungsphase erkannt werden können.
Die der Qualitätssicherung dienenden Maßnahmen und Prozesse sollten auch immer selbst Gegenstand der Diskussion sein und auf ihre Wirksamkeit hin überprüft werden. Nur so ist eine dynamische Anpassung an sich verändernde Gegebenheiten möglich.
Bitte beachtet auch die SVN-Regeln für Arbeiten im PCM Code Repository.
Code-Überblick
... ausgelagert auf die Seite PCM Codebereiche
Grundverständnis von SW-Qualität
Verschiedene Aspekte von Software-Qualität sind beispielsweise im ISO/IEC 9126 aufgelistet.
Wichtige Qualitätsattribute im Kontext von Palladio sind Wartbarkeit und Zuverlässigkeit. Andere Qualitätseigenschaften sind je nach Unterprojekt ebenfalls relevant, insbesondere auch Benutzbarkeit.
Für die Wartbarkeit ist ein Grundverständnis, dass die Prinzipien guter Software-Entwicklung und guten Software-Entwurfs, die in den Vorlesungen Programmieren und SWT2 gelehrt werden, eingehalten werden sollen.
Für die Zuverlässigkeit ist ein Grundverständnis, dass sinnvolle Tesfälle erstellt werden sollen.
QS-Maßnahmen
An dieser Stelle werden die wichtigsten Maßnahmen zur Sicherung der Softwarequalität vorgestellt.
Code-Konventionen mit CheckStyle
Code-Konventionen erhöhen die Lesbarkeit und Verständlichkeit des Codes und tragen so zur Softwarequalität bei. Bei SDQ wurde die Verwendung des Eclipse-Plugins Checkstyle vereinbart, um einheitliche Code-Konventionen über alle Implementierungsarbeiten hinweg zu erreichen. Die Code-Konventionen gelten als erfüllt, wenn das CheckStyle-Modul unter Anwendung der SDQ-Code-Konventionen keine Warnungen mehr erzeugt (die Info-Meldung bei Zeilen mit mehr als 80 Zeichen kann toleriert werden).
Code-Dokumentation mit Javadoc
Die Kommentierung des Quellcodes ist die Grundlage für die Erstellung einer Dokumentation mit Hilfe von Javadoc. Entsprechend wichtig ist die Einhaltung der SDQ-Javadoc-Konventionen, die u.a. die Kommentierung aller Quellcodeelemente vorschreiben. Die Vollständigkeit der Kommentierung wird durch CheckStyle (s.o.) überprüft.
Testunterstützung mit JUnit
Die Durchführung von Unit Tests mit JUnit dient dazu, Implementierungsfehler und versteckte Nebenwirkungen von Systemerweiterungen aufzudecken. Da ein Testfall jederzeit wiederholt werden kann, dient er als dauerhafter Nachweis der Korrektheit des Systems auch bei Änderungen am System oder in der Systemumgebung. Grundsätzlich sollten alle wichtigen Systemfunktionen durch Testfälle abgedeckt sein.
Der Umfang und die Granularität der zu definierenden Testfälle kann nicht generell festgelegt werden. Im Einzelfall muss beim Codereview (s.u.) bestimmt werden, ob eine Implementierungsarbeit durch Testfälle ausreichend verifziert ist. Bei prototypischen Implementierungen ist das Anlegen von Testfällen unter Umständen zu zeitaufwändig, bei generiertem Code nicht sinnvoll.
Die Struktur zu definierenden Testfälle innerhalb eines Eclipse-Projektes wird durch die SDQ-JUnit-Konventionen bestimmt.
Fehlerverfolgung mit Jira
Jira ist das bei SDQ allgemein eingesetzte Tool zur Fehlerverfolgung. Beobachtete Fehler und Verbesserungswünsche können sowohl bei laufenden Implementierungsarbeiten als auch bei fertigen Produkten in Jira festgehalten werden. Bei Abnahme einer studentischen Implementierungsarbeit ist darauf zu achten, dass alle bis dahin entdeckten und in Jira dokumentierten Fehler bearbeitet bzw. gelöst wurden (Ausnahmen sind mit dem Betreuer abzuklären).
PCM Bugfixing Responsibilities
QS-Prozesse
Die Einhaltung der vereinbarten QS-Maßnahmen (s.o.) soll durch die im folgenden beschriebenen QS-Prozesse sichergestellt werden.
Codereview
Eines der wichtigsten Instrumente zur Verbesserung der Softwarequalität ist für uns der Codereview. Generell sind Codereviews für alle am Lehrstuhl durchgeführten Implementierungsarbeiten einzuplanen:
- Studienarbeiten: 1 Codereview nach 80% der Implementierung
- Diplomarbeiten: 1 Architektur-Review zu Beginn der Implementierung; 1 Codereview nach 80% der Implementierung
- Von Hiwis durchgeführte Implementierungsarbeiten: Je 1 Codereview nach einem (vom Betreuer definierten) Inkrement der Implementierung
- Von Mitarbeitern durchgeführte Implementierungsarbeiten: Codereviews je nach individueller Planung, spätestens vor dem Ausscheiden des Mitarbeiters
Bei Studien- und Diplomarbeiten sowie bei Hiwis kümmert sich jeweils der betreuende Mitarbeiter darum, dass Codereviews durchgeführt werden. Die QS-Beauftragten (Stand April 2008: Franz und Johannes) kontrollieren die fristgerechte Durchführung von Reviews. Für die Terminplanung von Codereviews siehe die Planungsseite.
Wenn die Durchführung eines Codereviews von den beteiligten Reviewern eine umfassendere Einarbeitung in spezielle Technologien und Verfahren erfordert, so sollte der Code-Verantwortliche vor dem eigentlichen Review eine entsprechende Einführung für die Reviewer (und weitere Interessierte) geben; eine solche Einführung kann z.B. in Form einer Lerngruppe organisiert und angekündigt werden (insbesondere wenn die besprochenen Technologien von allgemeinem Interesse sind).