Softwareprojekte bewerten

21.06.2017 15:52

Die Softwareentwicklung wird gern mit dem Bau eines Hauses gleichgesetzt. Da gibt es eine Person, die definiert wo die Fenster, Rohrleitungen und Wände hingehören (der Architekt) und eine Reihe anderer, die dann die Wünsche umsetzen (die Entwickler). Aber stimmt dieses Bild eigentlich?

Während ein Haus seinen eigentlichen Zweck erst erfüllt, wenn es fertig ist, gilt Software schon als veraltet, wenn niemand mehr neue Features hinzufügt. Dies sieht man zum Beispiel bei Open Source Frameworks. Wenn dort der letzte Commit mehr als ein Jahr zurückliegt, wird teilweise schon davon ausgegangen, dass jenes Framework veraltet und ungepflegt ist.

So lange man aber an Software arbeitet, so lange verändert sie auch ihre Struktur. Dinge werden hinzugefügt, andere wiederum entfernt und so entwickelt sie sich evolutionär anhand ihrer expliziten und impliziten Anforderungen. Entwickelt sie sich nicht fort, wird sie auf kurz oder lang eingestellt und stirbt. Es ähnelt daher weniger dem Haus als dem Garten. Da gibt es an der einen Stelle Unkraut zu zupfen, an der anderen Stelle Bäume zu verschneiden. Geschieht dies nicht, wuchern Flora und Fauna, bis von der eigentlichen Struktur nichts mehr zu erkennen ist. Diese Wucherungen sind es dann auch, was ein langläufiges Softwareprojekt zum Erliegen bringen kann, weil es zu teuer ist, neue Features hinzuzufügen oder weil bei jeder Änderung irgendwelche anderen Dinge kaputt gehen.

Es macht also gelegentlich Sinn, sich auf eine Metaebene zurück zu ziehen und ein Softwareprojekt von außen zu betrachten, damit man im täglichen Kleinklein nicht die Übersicht verliert. Zu dieser Überprüfung gehört dann nicht nur der Quellcode, sondern auch die generelle Zusammenarbeit, die eingesetzten Werkzeuge, der gesamte Softwareentwicklungsprozess eines Unternehmens usw. In einem gewissen Rahmen wird dies beispielsweise während einer Retrospektive in Scrum Projekten getan. Hierbei wird sich darüber ausgetauscht, welche Dinge gut oder weniger gut verliefen. Auch Code Reviews und Pair Programming sind ein wichtiges Mittel, um zumindest Wucherungen innerhalb des Quellcodes einzudämmen.

Darüber hinaus kann es bei langläufigen Projekten auch sehr nützlich sein, eine gesamtheitliche Überprüfung durchzuführen. Dies kann in Form eines Healthchecks oder eines kompletten Audits sein. Während ein Audit von speziell geschulten Auditoren durchgeführt wird und mehr darauf abzielt die Einhaltung von Prozessen und Standards sicherzustellen, stellt ein Healthcheck den Reifegrad der Software auf die Probe.

Bei einem Healthcheck ist es somit nicht direkt von Belang, ob spezielle Anforderungen erfüllt werden. Er dient dazu generelles Verbesserungspotential in der Umsetzung aufzudecken. Dazu gehört unter anderem eine strukturelle Analyse des Quellcodes, die Überprüfung der verwendeten Drittbibliotheken, die Betrachtung verschiedenster Code Metriken und der Abgleich von projektspezifischen mit industrieüblichen Vorgehen.

Healthchecks werden daher vor allem durch erfahrene Softwareentwickler durchgeführt, die neben dem Verständnis für die Technologiegrundlage auch tiefgreifendes Knowhow in der Softwarearchitektur aufweisen müssen. Je nach Ziel eines Healthchecks sollte dieser nicht durch Personen durchgeführt werden, die selbst zu dem umsetzenden Projektteam gehören. Andernfalls kann es zu starken Verfälschungen in der Ergebnisanalyse kommen. So kann man sich beispielsweise der Unterstützung eines Architekten eines anderen Teams oder gleich eines unternehmensexternen Spezialisten bedienen.

Der Einsatz von Außenstehenden kann sehr hilfreich sein, da sie mit einem unverstellten Auge die aktuelle Situation beurteilen. Sie sind nicht durch historisches Vorwissen oder persönliche Beziehungen belastet und können sich somit besser darauf konzentrieren, welche Auswirkungen bestimmte Dinge in Zukunft haben könnten. Um dies aber einschätzen zu können, müssen sie neben der reinen Lehre auch über eine gewisse Portion Zweckpragmatismus verfügen. Es ist nun einmal nicht unbedingt möglich eine zehn Jahre alte Software neu zu schreiben, nur weil es mittlerweile evtl. ein Framework gibt, das einen Großteil der Arbeit übernimmt. Darüber hinaus sollten sich die Einschätzungen nicht nur auf Zahlen und Tabellen stützen. Code Metriken sind hilfreich, aber man muss sie einschätzen können und um sie einschätzen zu können muss man sich mit den Personen unterhalten, die an der Entwicklung der Software beteiligt waren. Welche Muster haben sie verfolgt? Welche Konventionen gibt es? Welche Anforderungen können zu fraglichen Entscheidungen geführt haben?

Jede Softwarestruktur ist unterschiedlich und so muss auch jeder Healthcheck unterschiedlich geführt werden. Ebenso sollte man nicht vergessen, dass eine übereilige Kritik oder Zustimmung schwerwiegende Auswirkung haben kann, beeinflusst sie doch unter Umständen die Entscheidungen der kommenden Jahre. Des Weiteren werden durchaus gute Ratschläge nur selten angenommen, wenn sie unter einem böswilligen Verdacht stehen.

Aus diesem Grund ist es in Problemfällen immer besser Alternativen aufzuzeigen, als nur den Finger in die Wunde zu legen. Man muss erläutern, warum etwas ein Problem darstellt: Wie könnte es sich auswirken? Wie wahrscheinlich sind die Auswirkungen? Was genau kann man dagegen tun? Diese Dinge müssen mit harten Fakten wie Zahlen, Fachliteratur und evtl. sogar Studien belegt und zeitgleich mit Einfühlungsvermögen und Fingerspitzengefühl vermittelt werden.

Damit schließt sich dann auch der Kreis zum Hausbau. So nimmt man als Bewertender möglicherweise die Rolle eines Sachverständigen oder sogar Gutachters ein. Man muss sich somit im Klaren darüber sein, welche Auswirkungen es haben kann, wenn man die Arbeit anderer einschätzt. Je nach Vertragsgestaltung kann dies beispielsweise sogar rechtliche Folgen haben. Aus diesen Gründen muss man an jede Bewertung auch mindestens mit dem qualitativen Anspruch herangehen, den man vom Bewertungsgegenstand verlangt. Dazu gehört neben der notwendigen Dokumentation der Erkenntnisse auch die Dokumentation deren hinreichenden Lösungsstrategien.

Neugierig auf mehr? Unsere Experten rund um Hendrik Lösch sind auf der dwx mit Vorträgen unterwegs! Gern können Sie uns auch am Stand 13 oder unter www.sogehtsoftware.de besuchen.

Schlagwörter: Architektur , Qualität


Autor Hendrik Lösch

Hendrik Lösch ist Consultant und Entwickler der Saxonia Systems AG. Der Schwerpunkt seiner Arbeit liegt auf der Entwicklung von Software für Kunden im industriellen und medizinischen Umfeld. Darüber hinaus schreibt und spricht er gern über seine Arbeit sowie seine Begeisterung für die Testautomatisierung in ihren unterschiedlichen Ausprägungen.

Hendrik Lösch

Developer Week in Social Media

Folgen Sie uns auf:

Aussteller & Sponsoren

Infos anfordern

Infos anfordern
  • Florian Bender
  • Projektleitung
  • Tel.: +49 (89) 74117-206
  • Fax: +49 (89) 74117-448
  • E-Mail: florian.bender@nmg.de

Medienpartner