Fachartikel  zur Übersicht

Sicherung der Software-Qualität bei Mitarbeit in externen Projekten

Das Sicherstellen von Qualität ist bei der modernen Softwareentwicklung ein wichtiger Aspekt und trotz allem immer wieder eine Herausforderung an Team und Management. Insbesondere in hektischen Projektabschnitten wird der Qualitäts­anspruch immer wieder dem schnellen Projektfortschritt geopfert, mit allen Aus­wirkungen auf die späteren Lebensphasen. Qualität ist ein wichtiger Faktor für den Erfolg von Projekten und die Sybit GmbH ist sich dessen bewusst – unabhängig davon, ob wir nun Projekte in Eigenregie durchführen oder bei Kundenprojekten mitarbeiten.

Um eine hohe Qualität von Software zu garantieren, gibt es verschiedenste Lösungen. Angefangen bei Tools, die den Quellcode auf die Einhaltung der Format-Standards untersuchen, über Analyse-Tools, die ein ganzes Modul auf typische Fehler­muster überprüfen bis hin zu Werkzeugen, die die Erstellung und Verwaltung von Tests unterstützen. Gekrönt wird das ganze von Tools zur Test­­automatisierung, die – einmal definiert – Tests wiederholbar mit nur wenigen manuellen Eingriffen reproduzieren können.

Eine besondere Herausforderung ist es, die Qualität der Sybit-Mitarbeiter bei Kunden­projekten vor Ort zu sichern. Diesem Thema hat sich die Sybit GmbH schon frühzeitig gestellt und daraus einige pragmatische Praktiken und Lösungen erarbeitet.

Innere Softwarequalität

Geht es darum, schon frühzeitig die Qualität der Software zu gewährleisten, dann spielt die innere Qualität eine herausragende Rolle.

Die Kosten für die Projektentwicklung werden auf lange Sicht entscheidend durch die innere Qualität der erstellten Software bestimmt. Das ist die Softwarequalität, die vom Entwickler in Form technischer Strukturen und Merkmale wahrgenommen wird. Diese Qualität entscheidet letztendlich auch über die äußere Qualität. Vergleichbar mit der persönlichen inneren Verfassung, die sich oft auch nach außen widerspiegelt und nur schwer zu verleugnen ist. Die innere Qualität der Software bestimmt also auch die Verfassung des Projektes.

Welche Ursachen können die Software im Inneren beeinflussen? Wichtige Faktoren sind sicher Architektur, Design, Kodierrichtlinien, Abhängigkeiten, Komplexität und diverse sprachabhängige Programmierfallen. Man könnte die Liste beliebig um spezifischere Punkte erweitern.

Betrachtet man die Faktoren, so wird klar warum man von innerer Softwarequalität spricht. Für den Endanwender sind diese nicht sichtbar –  geschweige denn zu bewerten. Dem entgegen steht die äußere Qualität, die Faktoren wie Ergonomie, Performance, Fehlertoleranz usw. beschreibt. Diese kann der Anwender durchaus bewerten, indem er z.B. feststellt, dass Anforderungen etwa nicht so umgesetzt wurden, wie er dies erwartet hatte.

Kosten

Geht man davon aus, dass die innere Qualität der Software die nach außen sichtbare Qualität beeinflusst, so ist klar, dass durch Sicherung der inneren Qualitäts­­anforderungen nicht nur Ärger sondern auch Kosten reduziert werden können. Die innere Qualität kann häufig schon zu einem sehr frühen Zeitpunkt überprüft werden. Auch wenn das System noch lange nicht voll funktionsfähig ist.

So stellte sich für uns schon bald die Frage, wie wir qualitativ hochwertige Software in die Kundenprojekte einbringen können. Welche Möglichkeiten bestehen, wenn man keinen direkten Einfluss auf Dinge, wie Testdriven Development, Continuous Integration, Code Coverage usw. hat?

Reviews

Begonnen haben wir mit Reviews. Bei Reviews im Bereich Architektur und Design als auch bei Quellcode Reviews haben wir bereits bei hausinternen Kunden­projekten sehr gute Erfahrungen erzielt. Selbst Code Reviews, die zunächst von den Entwicklern mit Skepsis gesehen wurden, etablierten sich sehr schnell.

Reviews innerhalb des eigenen Unternehmens und der Projektteams mögen eine organisatorische Herausforderung sein, wenn die Beteiligten jedoch den Nutzen für sich persönlich erkennen, können sie auch zum Selbstläufer werden – Mitarbeiter fordern Reviews ein, um dem eigene Qualitätsanspruch gerecht zu werden.

Sind die Softwareingenieure jedoch beim Kunden vor Ort in ein Projekt eingebunden, so gestalten sich derartige Reviews weitaus schwieriger. Zum einen kann der externe Projekt­­mitarbeiter meist die Projektartefakte nicht mit zur eigenen Firma nehmen. Oft bestehen Geheimhaltungsklauseln und andere Hürden, die es verbieten derlei Artefakte für Reviews mitzunehmen. Auf der anderen Seite kann zwar ein Reviewer zum Kunden kommen, um die Artefakte vor Ort zu reviewen. Dies bedeutet jedoch Einiges mehr an organisatorischem Aufwand (Terminabsprachen, Einlass­genehmigungen, Zustimmung der Dateneinsicht für Reviewer, etc.). Zudem wird die Störung im Projektalltag durch derlei externen Reviews von den Kundenteams meist als Kontrolle empfunden – Vertrauen spielt bei Reviews eine wichtige Rolle.

Es stellt sich nun die Frage, wie können Reviews durchgeführt werden, die effektiv sind, jedoch den Projektalltag beim Kunden nicht stören?

Automatisierte Reviews

Einen Ansatz fanden wir auf unserem Continuous Integration Server. Dieser führt schon seit eh und je diverse automatisierte Reviews durch. Je nach Projekt werden bei jedem Build Findbugs-, Checkstyle-, PMD- und Codecoverage-Analysen und Trends durchgeführt und protokolliert.

Kann dieser Ansatz auch in die Kundenprojekte vor Ort getragen werden? Sind die Reviews erst einmal automatisiert, so sind sie mit recht wenig Aufwand durch­zu­führen und man kann sich auf die Analyse der Ergebnisse konzentrieren.

Externe Projektmitarbeit

Auf die Buildumgebung des Kunden kann man nur selten Einfluss nehmen. Es ist also nicht möglich eine CI-Umgebung wie bei Sybit inhouse aufzusetzen. Es wäre auch unproduktiv dies parallel einzuführen. Es stellt sich also die Frage, wie die Analysen mit möglichst geringem Aufwand durchgeführt und daraus entsprechende Reports und Trends gebildet werden können.

Das Sybit Quality Bundle

Da die meisten unserer Kundenprojekte unter Java entwickelt werden, haben wir uns zunächst auf eine Umgebung beschränkt, die die Java-Welt abdeckt. Es entstand das "Sybit Quality Bundle", welches die Entwickler beim Kunden vor Ort ausführen können. Dieses "Quality Bundle" analysiert Software-Module und erzeugt die entsprechenden Reports auf Basis von bewährten Tools, wie Findbugs oder Checkstyle. Der Software­entwickler kann die Ergebnisse selbst im HTML-Format auswerten. Für das Reporting werden XML-Dateien an die Sybit Qualitätssicherung geliefert. Diese Berichte beinhalten nur noch Paketstrukturen und Klassen­bezeichnungen jedoch keinerlei Interna, die unter die Geheimhaltung fallen würden.

Die XML-Reports werden in einem fest definierten Zyklus vom Entwickler an den Qualitätsbeauftragten der Sybit geliefert und in einem Subversion-Repository abgelegt. Der hausinterne CI-Server wertet die Änderungen in diesem Repository aus und erzeugt somit nach einem Commit immer wieder aktuelle Berichte und Trends aus den XML-Dateien.

Derzeit beschränken sich die Audits auf die innere Qualität des Codes. Ansatzweise werden auch Design und Architektur bei der Bewertung der Komplexität und den Zyklen im Code geprüft, jedoch ist gutes Design nicht einfach an Zahlen abzulesen. Aus diesem Grund tauschen sich unsere Entwicklungsingenieure auch regelmäßig untereinander aus und diskutieren ihre Architektur- und Designansätze.

Anpassbarkeit

Da die Kunden auch eigene spezielle Konventionen haben, was zum Beispiel die Codierrichtlinien angeht, so ist es wichtig, dass das "Sybit Quality Bundle" entsprechend angepasst werden kann. Gemeinsam mit den Qualitätsbeauftragten wird die Konfiguration an die Richtlinien der Kunden angepasst und bereitgestellt. So ist es möglich beim Start ein kundenspezifisches Konfigurationsset auszuwählen.

Der Qualitätsprozess

Ein Tool wie das "Sybit Quality Bundle" alleine sorgt noch lange nicht für mehr Qualität. Es muss auch gelebt werden. Es muss also einen Prozess geben, der die Anwendung des "Sybit Quality Bundles" sicherstellt.

Bei der Sybit GmbH wurde ein Prozess eingeführt, der die Qualität auf Basis der Ergebnisse des "Sybit Quality Bundles" misst und Trends aufzeigt: Für die Mitarbeiter, die beim Kunden vor Ort mitarbeiten, gibt es bei der Sybit GmbH einen Qualitäts­beauftragten, der in regelmäßigen Abständen die Ergebnisse des "Quality Bundles" einfordert und die Trends auf dem Integrationsserver analysiert. Bei Problemen werden entsprechende Gegen­maßnahmen durchgesprochen und in die Wege geleitet.

So können wir garantieren, dass wir unsere hohen Qualitäts­standards und ‑ansprüche auch in die externe Projektmitarbeit ausdehnen. Die Trends können auch gegenüber dem Kunden offengelegt werden und schaffen so eine weitere Vertrauensbasis.

Fazit

Durch die geschickte Kombination von Open-Source Produkten ist es mit geringen Mitteln möglich, auch die Qualität in externen Projekten zu gewährleisten und zu verbessern. Durch die einfache und schnelle Handhabung erzielt das "Sybit Quality Bundle" sowohl bei den Entwicklern als auch beim Kunden eine hohe Akzeptanz.

 

---

Stephan Strittmatter ist Projektmanager und Certified Scrum Product Owner bei der Sybit GmbH. Durch testgetriebene Software-Entwicklung bringt er unsere Kundenprojekte auf höchstes Qualitätsniveau.

 

Download als PDF (136 kB)

• Sicherung der Software-Qualität bei Mitarbeit in externen Projekten