SW-Qualität ist mehr als Testen / warum die SW-Qualität schlecht sein kann, obwohl die SW funktioniert?

Computer: Software & Programmierung Programmierung allgemein
#1

Hallo zusammen,

ich stoße immer wieder auf folgendes Phänomen:
Die SW-Qualitätsmanager einer Firma sind fleißig dabei die Qualität der Software (die von Lieferanten kommt) zu sichern. Konstruktiv in Form von Prozessmodellen (CMMI, Spice usw.), reaktiv in Form von SW-Metriken (entlang der ISO25010). Das Testen (Blackbox) oder die Analyse von allgemeinen Projektmanagementkennzahlen obliegt der Entwicklungsabteilung.

Jedoch stelle ich immer öfter fest, dass die Sinnhaftigkeit von SW-Qualität bzw. die Daseinsberechtigung der Abteilung intern in Frage gestellt wird. Es heißt dann immer, die Entwicklung ist doch zufrieden mit dem und dem Lieferanten, oder die Tests sind nicht auffälliger als sonst. Von Prozessarbeit hält in der Entwicklungsabteilung ohnehin niemand was.

Meiner Meinung nach verstehen viele Leute nicht dass SW-Qualität mehr ist als nur Funktionalität. Der Aufbau und die Sauberkeit des Source Codes bspw. Gerade wenn man an so Dinge wie SW-ReUse denkt. Der modulare Aufbau, minimale Abhängigkeiten usw.

Aber wie bringt man das am besten Leuten bei, die einfach nur die Blackbox sehen und von internen Dingen keine Ahnung haben?

Gruß
AXL

#2

Software-Qualität ist auch nichts genau definiertes, so lässt sich darüber trefflich streiten.
Nehmen wir zwei Erdbeeren - eine ist groß und kräftig rot und macht sich prima zur Dekoration bei Festen, schmeckt aber fade/wässrig.
Eine andere ist klein, etwas unregelmäßig geformt, schmeckt aber super fruchtig-süß. Die wird einfach gern gegessen, wenn man sie essen will, aber nicht zur festlichen Dekoration verwendet.

Wenn ich als Firma eine Software einsetze, kommt es auch drauf an, was ich damit machen will. Will ich sie einfach nur benutzen, dann kann es mir doch völlig egal sein, wie es im Inneren dieser Blackbox aussieht, wenn alles funktioniert wie gewünscht. Der Source-Code ist für mich als Anwender uninteressant.
Wenn ich allerdings Module kaufe, die ich noch für meine Zwecke anpassen oder mit anderen Modulen verbinden muss, dann kann es natürlich schon eine Rolle spielen, weil davon natürlich auch mein eigener Aufwand abhängt, den ich da noch reinstecken muss…das lässt sich dann aber auch durch entsprechende Zahlen (Abrechnug Arbeitszeit/Personalkosten) begründen.

Beatrix

#3

Naja, sie sichern nicht die Qualität. Sie können maximal prüfen, ob der Lieferant Prozesse hat, von denen Ihr meint, sie fördern die Qualität.

Ob der Lieferant die Prozesse auch lebt, und ob sie bei ihm die Qualität heben, könnt ihr nicht prüfen.

In der Regel ist es förderlich, wenn gewisse Strukturen gefordert werden. Der Umkippmoment, ab dem diese Strukturen nur vorgespielt werden oder gar kontraproduktiv werden (zuviel Doku, UML, Codeabdeckung bei TDD, …) ist schwer zu erkennen.

Es ist wie mit Kommentaren im Quelltext.
Keine Kommentare ist schlecht.
Zuviel Kommentare sind noch schlechter.

#4

Hi!

Wie sagte ein ehemaliger Arbeitskollege: „Der Code ist der Kommentar“ bzw. „Wer den Code nicht lesen kann, versteht auch den Kommentar nicht“. :joy:

Grüße,
Tomh