Qualität von Softwareprojekten und Spaghetti

 Jenn Forman Orth

Softwareprojekte sind auch nicht anders als andere Projekte: Vor der (z.B. iterativen) Umsetzung der Anforderungen werden diese analysiert und z.B. in Form von Storycards oder Pflichtenheften oder Testfällen fixiert. Leider reicht das in der Praxis nicht, um damit die fachliche- und technische- (Wartbarkeit) Qualität zu definieren.

Wer im Rahmen von Softwareprojekten gute Qualität geliefert bekommen möchte, muss dasselbe beachten wie beim Kauf von Spaghetti (und allem anderen was käuflich ist):

• Mache neben fachlichen Vorgaben ("250 gleichzeitige Benutzer" oder "250 Gramm Spaghetti") auch Vorgaben hinsichtlich Qualität (z.B. "keine Methode länger als 40 Zeilen" oder "keine Spaghetti länger als 40 cm.") 
• UND prüfe diese Vorgaben auch (z.B. mittels PMD oder Zentimetermaß) 
• UND reklamiere bei Nicht-Erreichung der Vorgaben (z.B. das Programm nicht abnehmen oder die Spaghetti wieder zum Billa zurückbringen) 

Qualitative Vorgaben zu machen ist noch relativ einfach, es reicht beispielsweise global die maximale Fehlerdichte zu definieren, sowie Kennzahlen für die Wartbarkeit (siehe z.B. "Quality Gates bei Java Entwicklung") zu definieren. Leider wird ersteres in der Praxis meist nur ungenau definiert ("Es sollte keine bekannten schweren Fehler geben") und auf Wartbarkeit gar nicht näher eingegangen ("Das Programm muss wartbar sein").
Prüfung qualitativer Vorgaben ist schon schwieriger, weil es Dinge gibt, die man nicht, oder nur aufwändig messen kann wie "gut wartbarer Code" oder "gut schmeckende Spaghetti". Für technische Qualität müssen die im ersten Schritt definierten Kennzahlen "nur" überprüft werden. Um Fehlerdichte zu messen, reicht es aber nicht, alle fachlichen Tests durchzuführen, denn diese können ja selbst ungenügend sein. Für die Berechnung der Fehlerdichte müssen Tests durchgeführt werden, welche nachweisbar eine umfangreiche fachliche- und technische (Anforderungs-, Code- und Daten-) Abdeckung haben.
Reklamation klingt zwar einfach, ist es in der Praxis aber nicht. Wenns eng wird ("Das Feature brauchen wir aber dringend" bzw. "Ich hab aber so einen Hunger"), wird fachlich- und technisch ungenügende Software meist dennoch in Betrieb genommen. "Bedingte Abnahme" funktioniert bei Software aber ähnlich schlecht, wie bei Spaghetti - wird Software einmal eingesetzt sind nachträglich kommende Änderungen (vor allem für den Auftraggeber) zumeist wesentlich aufwändiger auszurollen.

Um bei Softwareprojekten gute Qualität geliefert zu bekommen benötigt der Auftraggeber:

1. Definition der funktionalen Anforderungen
2. Prüfung der Erreichung der funktionalen Anforderungen 
3. Definition der non-funktionalen Anforderungen 
4. Prüfung der Erreichung der non-funktionalen Anforderungen 
5. Verhinderung der Abnahme bei Nicht-Erreichung der Vorgaben (auch gegen den Wunsch der Fachbereiche / Endanwender) 

Für ersteres gibt es Analytiker, für zweiteres gibt es Tester und Test-Manager, Punkt 3 und 4 sollte von Lead-Developern oder Architekten beherrscht werden, Punkt 5 sollte von Managern gemacht werden.

Sollte beherrscht werden - wird es aber zumeist nicht, da Test-Manger lieber Code testen, als sich selbst durch Testabdeckung zu prüfen, Lead-Developer und Architekten sich lieber mit technisch interessanteren Dingen beschäftigen und Manager Projekterfolg mehr durch das "Wann geht die Software in Einsatz" als das "Wie geht sie in Einsatz" definieren. In der Praxis wird Punkt 2 bis 5 daher meist ungenügend umgesetzt. Darum ist die fachliche- und technische- Qualität bei Softwareprojekten auch so schlecht (und darum essen wir oft viel zu schlechte Spaghetti).

P.S. Ich kann gerne bei Punkt 3 und 4 helfen (hab das schon bei einigen Unternehmen gemacht). Ich habe mir aber geschworen es nur dann zu machen, wenn es von einem Manager beauftragt wird, der Punkt 5 beherrscht.