Erstaunlich, jeder redet darüber, alle wollen es haben, aber eine anständige Definition fehlt. Dazu ein Zitat aus der ISO 9000-3:
There is no universally accepted definition of software quality
Der Grund dafür liegt vor allem in den unterschiedlichen Sichten auf ein Softwareprodukt. Ein Nutzer hat einen anderen Blickwinkel als der Programmierer. Da kann der Code noch so schön sein – wenn die Software nicht das macht, was sie tun sollte und nicht zuverlässig ist, wird kein Benutzer von einer Software mit hoher Qualität reden.
Im Einzelfall muss man sich also sehr genau ansehen, was denn tatsächlich gefordert ist und dann überlegen, wie man dieses Ziel erreichen kann. Mit pauschalen Aussagen und Messwerkzeugen wird man nicht weit kommen.
Das war ja sowieso das Thema: Qualität meßbar machen, Qualität transparent machen oder Qualität vergleichbar machen. Wie wir jetzt wissen ist das so nicht möglich – dieses Versprechen kann man nicht einhalten. Was aber funktioniert: Qualitätsteilaspekte messen und vergleichen; jedoch nur in einem fest abgesteckten Rahmen.
Die große Gefahr ist dabei allerdings, dass man sich zu stark auf die messbaren Größen fixiert und das eigentliche Ziel aus dem Auge verliert. Was ist denn nun aber das Ziel? Für Anwendungssoftware ist die Antwort:
Die eigentliche Arbeit des Nutzer so gut wie nur irgend möglich durch die Software zu unterstützen.
Und dabei die Wirtschaftlichkeit des Unterfangens nicht aus den Augen zu verlieren. Wenn eine Software mehr kostet, als sie mir nachher im Betrieb bringt – dann brauchen wir ja gar nicht erst anfangen zu entwickeln.
![[del.icio.us]](http://blog.soly.org/wp-content/plugins/bookmarkify/delicious.png)
![[Digg]](http://blog.soly.org/wp-content/plugins/bookmarkify/digg.png)
![[Google]](http://blog.soly.org/wp-content/plugins/bookmarkify/google.png)
![[StumbleUpon]](http://blog.soly.org/wp-content/plugins/bookmarkify/stumbleupon.png)
![[Windows Live]](http://blog.soly.org/wp-content/plugins/bookmarkify/windowslive.png)
![[Yahoo!]](http://blog.soly.org/wp-content/plugins/bookmarkify/yahoo.png)
![[Email]](http://blog.soly.org/wp-content/plugins/bookmarkify/email.png)
This post was written by oscar on September 26, 2008
“Da kann der Code noch so schön sein – wenn die Software nicht das macht, was sie tun sollte und nicht zuverlässig ist, wird kein Benutzer von einer Software mit hoher Qualität reden.”
=> Das stimmt. Vor allen Dingen ist heute aber auch die Benutzerfreundlichkeit und der “Style”-Faktor wichtig, a la IPhone, etc.
Nach DIN ISO 9126
gibt es aber schon einige SW-Qualitätspunkte:
Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit, Übertragbarkeit
Richtig, aber der Standard verlässt diesen Abstrakten Level nie und liefert auch keinen Hinweis darauf in wie weit die Qualitätsbetrachtung vollständig ist.
Erstes hat zur Folge, dass zwei Personen/Unternehmen bei der Bewertung eines Softwareproduktes zu komplett unterschiedlichen Aussagen kommen können.
Zweites ist problematisch, weil niemand weiß, ob selbst auf diesem abstrakten Level überhaupt alle Aspekte berücksichtigt worden sind.
Ganz nutzlos ist der Standard trotzdem nicht – die Qualitätsmerkmale sind auf jeden Fall richtig UND der Standard bildet die Grundlage für einen gemeinsamen Wortschatz. Immerhin weiß man dann, worüber man sich unterhält.
Ok, das stimmt.
Kann man denn in der Software überhaupt konkreter werden? Ist nicht gerade die Vielfalt und Einzigartigkeit das Besondere?
Ja, so wie es im Moment läuft schon. Ich frage mich im Moment immer öfter ob das wirklich so sein muss. Angenommen wir würden so weit kommen, dass wir die Funktionalität unsere Software in einer leicht zu überprüfenden Metasprache definieren könnten – dann wäre die Codequalität eigentlich egal. Model-Driven-Development wäre zum Beispiel so ein Ansatz – weit verbreitet – oder gar im Industriellen Maßstab eingesetzt – wird die Technik im Moment aber nicht.
Diese Dilemma stellt so nebenbei auch den Begriff “Software-Engineering” in Frage. In den meisten Ingenieurswissenschaften bildet das Messen von Systemen eine wichtige Grundlage der Arbeiten