Wie bei jedem Produkt gilt auch für Software: Qualität ist wichtig. Doch was bedeutet «Qualität» in der Softwareentwicklung? «Auf der einen Seite gibt es die Produktqualität gemäss ISO-Standard 25010, mit Kriterien wie Performance, Effizienz, Kompatibilität mit anderen Systemen, Usability oder Zuverlässigkeit», erklärt Urs Enzler, Fachleiter agile und Architektur bei bbv. «Auf der anderen Seite gibt es die Servicequalität: Bei der Softwareentwicklung sollte man mit einem vernünftigen Aufwand Erwartungen erfüllen sowie effektiv und effizient arbeiten; ausserdem sollten Entwickler Kunden möglichst keine Überraschungen bescheren und ein Gefühl von Sicherheit vermitteln.»
Qualität sollte dabei schon zu Beginn einer Produkteentwicklung berücksichtigt werden. Ansonsten riskieren Entwickler, dass sie am Ende gar nicht da ist: Die Software läuft nicht, die Kunden akzeptieren sie nicht – das Produkt scheitert. «Früher gingen Entwickler davon aus, dass man Qualität erst in einem späten Stadium der Softwareentwicklung noch ‹reintesten› könne», erklärt Enzler. «Das funktioniert nicht. Man kann keine Qualität nachträglich einführen, man kann sie nur beim Entwickeln einbauen.» Und je später man versucht, Qualität einzubauen, desto teurer wird die Produktentwicklung.
«Feature-itis» ist der falsche Ansatz
Entwickler erreichen Qualität deshalb mit methodischem Wissen: Sie kennen Entwicklungsansätze wie Test Driven Development, in dem Software fortwährend getestet und iteriert wird. Oder Rapid Prototyping, bei dem anhand eines Prototyps schnell herausgefunden wird, ob der verfolgte Ansatz auch wirklich das Problem löst oder nicht. Beide Methoden sind elementar, um bereits zu einem frühen Zeitpunkt der Softwareentwicklung Qualität zu gewährleisten.
Damit ist es aber noch nicht getan. Denn die grösste Herausforderung besteht darin, für Qualität überhaupt sensibilisiert zu sein: Manche Entwickler leiden unter «Feature-itis» und entwickeln ein Feature nach dem anderen. Das ist nicht immer zielführend: Der Kunde möchte im Grunde genommen keine Software bedienen, sondern einfach ein Problem gelöst haben. Wenn ein Feature dazu beiträgt, ist es berechtigt. Wenn nicht, schadet es nur: Es ist teuer in der Entwicklung und hat schlimmstenfalls noch Bugs. «Deshalb sollten Softwareentwickler besser herausfinden, wie man mit möglichst wenig Software möglichst viele Probleme lösen kann», erklärt Enzler. «Das Qualitätsverständnis beginnt also schon dort.»
Der Experte
Urs Enzler
Urs Enzler war als Expert Software-Architekt .NET bei bbv tätig. Als agil gesinnter Softwareentwickler spricht er an Konferenzen und Communityanlässen gerne über architektonische Herausforderungen und über das Lernen im Team. Enzler ist Co-Gründer der .NET Usergroup Zentralschweiz.