Kontakt
Telefon +49 2161 17 58 83
Mobil +49 179 72 66 112
E-Mail info@ulrich-borchers.de

Software-Qualität im größeren Zusammenhang

Kürzlich wurde ich dadurch, dass ich über den sogenannten "Joel-Test" stolperte, auf die Frage aufmerksam, was denn eigentlich für Software-Qualität wichtig ist und dass es da doch einiges mehr gibt, als die reine Betrachtung einer entwickelten Software und der beobachtbaren Programmierqualität.

Der Test, den Joel Spolsky im Jahr 2000 veröffentlichte, besteht aus 12 Fragen an eine Software-Entwicklung, die man möglichst alle mit einem JA beantworten können sollte. Der von Spolsky gleich mit formulierte Bewertungsmaßstab lässt nicht viel Raum für Missverständnisse: 12 x JA ist ein perfektes Ergebnis, aber 11 x JA ist lediglich noch tolerierbar und bei zehn oder weniger mit JA beantworteten Fragen hat das Unternehmen, so Spolsky, ein ernsthaftes Problem.

Ich war ehrlich gesagt verblüfft, ausgerechnet durch ein Unternehmen, das seine Entwicklungspraxis hiermit öffentlich selbst bewertete, auf diese Test aufmerksam geworden zu sein, da hiermit doch in der Regel eher intransparent umgegangen wird oder schlichtweg das Bewusstsein für solche Themen wenig ausgeprägt bis gar nicht vorhanden ist. Das Ergebnis, das dieses Unternehmen nach eigener Bewertung erzielte und präsentierte, war mit 11 x JA gut. "Tolerierbar" dem Test zufolge, wenn man es genau nimmt. Leider fand ich die URL, die ich hier gerne eingebunden hätte, später nicht wieder.

Stattdessen fand ich bei einer späteren Recherche dann diese Selbstbewertung aus Österreich:

 

Trotz der lediglich acht JA-Antworten ist allein die selbstkritische und damit konstruktive Auseinandersetzung mit dem Thema aller Ehren Wert und verdient eigentlich die Auffüllung auf 11 positive Antworten, wenn ein Unternehmen solches bewusst thematisiert. Fairerweise muss man auch erwähnen, dass Spolsky davon ausgeht, dass die meisten Unternehmen nur auf 2-3 JA-Antworten kommen, wobei sich hieran seit dem Jahr 2000 durch die Verbreitung guter Werkzeuge und agile Entwicklungsansätze doch etwas verbessern haben dürfte.

Weiteres öffentliches Material aus dem deutschsprachigen Raum, das sich auf den "Joel-Test" bezieht und nicht aus dem rein fachlichen Bereich stammt, konnte ich leider nicht finden, was sich als Indiz dafür nehmen ließe, dass doch hauptsächlich andere Kriterien die Außenwahrnehmung bestimmen - im Gegensatz zu jenen, die der Sache und damit dem objektiven Erfolg eigentlich am zuträglichsten wären.

Umformuliert zielen Spolskys Fragen (der seinen Artikel als "sloppy", also übersetzt als "schludrig" bezeichnet), durchaus sehr konkret auf Folgendes ab:

  • Werden im Rahmen der Software-Entwicklung (die richtigen) Werkzeuge eingesetzt? (Do you use source control? Do you use the best tools money can buy?)
  • Wie qualitätsorientiert ist die Entwicklung? (Do you fix bugs before writing new code? Can you make a build in one step? Do you have a bug database? Do you have a spec?)
  • Wie handlungsorientiert ist die Entwicklung und sind die Mitarbeiter? (Do you make daily builds? Do new candidates write code during their interview?)
  • Wird das Ergebnis aus externer Sicht bewertet? (Do you have testers? Do you do [..] usability testing?)
  • Ist die Entwicklung zielgerichtet? (Do you have an up-to-date schedule?)
  • Orientieren sich die Arbeitsbedingungen an den Erfordernissen an die notwendigerweise hochkonzentrierte Arbeit? (Do programmers have quiet working conditions?)

Diese von Spolsky formulierten 12 Fragen hat er hier veröffentlicht:
http://www.joelonsoftware.com/articles/fog0000000043.html


Es gibt auch darüber hinaus eine ganze Reihe von Kriterien, die für erfolgreiche Software-Produkte und Entwicklungsprozesse verantwortlich sind, und die wichtigsten davon liegen auch außerhalb der eigentlichen Entwicklung. Es sind nicht nur die handwerkliche Befähigung von Spezialisten und Teams und deren Motivation, die Einfluss auf das Ergebnis haben. Ebenso die Rahmenbedingungen und Ziele nebst deren Klarheit, sowie auch die möglichen Interessenkonflikte und deren diplomatische Verknüpfbarkeit bestimmen das Ergebnis maßgeblich mit.

Vordergründig kann man die Erreichung eines bestimmten Ziels für eine gewisse Menge Geld fordern, sei es als Kunde oder als Arbeitgeber an seine entsprechende(n) Abteilung(en). Bei einer so komplexen Sache wie der Entwicklung einer Software, beziehungsweise einer fortlaufenden Entwicklung funktioniert diese Denke jedoch nicht wirklich gut, und in der Regel wird das nicht einmal bemerkt.

Die klassische Vorgehensweise, die sich auf Auftragserteilung, Leistungserbringung und Bezahlung beschränkt, ist im Bereich der Software-Entwicklung mit hohen Verlusten behaftet, denn es gibt zu viele Interessenkonflikte und mögliche, inhaltliche und zielbezogene Missverständnisse, die Orientierung, Kommunikation, Rahmenbedingungen und Werkzeuge fordern, um zu guten Ergebnissen zu kommen.

Es handelt sich bei einer entwickelten Software nicht um eine Leistung, die einfach zu beurteilen wäre, außer vielleicht, wenn sie gar nicht funktioniert. Man hat durchaus erkannt, dass die Qualität des Prozesses während der Entwicklung eine wesentlich leichter zu steuernde und zu kontrollierende Einflussgröße ist, als das klassische Modell von Auftrag-Leistung-Abnahme es zulässt. Letzteres mag in anderen Bereichen durchaus funktionieren - in der Software-Entwicklung wird es jedoch mindestens von enormen Reibungsverlusten und damit finanziellen Einbußen begleitet.

Legt man keine praktizierbaren Qualitätsmaßstäbe an einen Software-Entwicklungsprozess an, dann stellt sich das Produkt am Ende mitunter als magische Black-Box heraus, an der Nachbesserungen und Änderungen praktisch unmöglich sind, von den personellen und menschlichen Auswirkungen einmal ganz abgesehen. Man kennt auch hier den geflügelten Spruch, dass das "Kind in den Brunnen gefallen" ist. Wie es dazu gekommen ist, sollte dann eine spannende Frage sein. Und: Wie hätte man es verhindern können, dass ein Projekt gescheitert ist? Also: Wie kann man es beim nächsten Mal besser machen? Die Beantwortung dieser Fragen führt zu Qualitätsmaßstäben, Rahmenbedingungen und Leitlinien.

In der Software-Entwicklung hat man schon vor längerer Zeit begonnen, sich von kopflastigen Planungsmodellen zu verabschieden und eine iterative Entwicklung zu bevorzugen. Gute Planung und Konzeption mit dem dafür erforderlichen Energieaufwand sind und werden immer mit erfolgsentscheidende Kriterien bleiben, die auch eine iterative, agile Entwicklung nicht ersetzen kann und will. Agile Entwicklung ist jedoch das notwendige Gegenstück dazu und sorgt für eine produktive und damit umsetzungsorientierte Entwicklung, bei der durch häufige Iterationen und deren Bewertung ja eigentlich das wiederholte und zeitnahe TUN und das HINSEHEN in den Vordergrund gestellt werden. Für ein gutes Ergebnis, das sich kontinuierlich an einer Planung und Konzeption messen lässt und das durch seine Handlungsorientierung angemessen auf Änderungen zu reagieren in der Lage ist, kann das nur von Vorteil sein.

Was aber bietet Orientierung für Verbesserungen? Und was treibt eine agile Entwicklung an, die in die richtige Richtung geht, die im Einklang mit den formulierten Zielen und Konzepten steht und welche die notwendige Qualität produziert und damit den wirtschaftlichen Erfolg stark mit beeinflussen kann? Dass dies mehr als nur die stumpfe Bearbeitung von Projekten ohne Orientierung sein kann, die fremdbestimmt wird und sich nicht der unterschiedlichen Einflussgrößen bewusst ist, ist klar. Es braucht Kriterien wie sie beispielsweise im Spolsky-Test formuliert wurden, beziehungsweise ganz allgemein Maßstäbe, an denen sich die Software
-Entwicklung orientiert, so dass sie sich nicht lediglich um eine Auftragserfüllung mit oft unklarem Ergebnis und nicht erreichten Zielen beschränkt, sondern die ihre Qualitätsmaßstäbe und Werte bewusst formuliert und danach handelt - mit dem Ergebnis hoher Qualität und einer zuverlässigen Zielerreichung.

Kolumne

Bleistift

Frei von der Leber - Bissig, wenn es sein muss.

RSS
tl_files/open_clip_art/symbole/rss-icon.png  Abonnieren