Software Qualität
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Von SoftwareQualitätssicherung
Was ist SoftwareQualität im Sinne der SoftwareQualitätssicherung?
Antwort nach DIN ISO 9126
- SoftwareQualität ist die Gesamtheit der Merkmale und Merkmalswerte eines Softwareprodukts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen.'
Antwort (sinngemäß aus ISO 900x)
- Qualität ist die Übereinstimmung von Produkteigenschaften mit den Erwartungen des Kunden.
Querverweis zu SoftwareEigenschaften.
- Nein! Dies ist so meines Erachtens zu frei interpretiert. Der 'Kunde' hat an dieser Stelle (leider) noch nichts verloren, bzw. gewonnen! --AP.
Interpretation: eine "möglichst hohe" Qualität kann es nicht geben. Wenn ein Kunde eine bestimmte Funktionalität verlangt, dann ist ein mehr an Funktionalität (nehmen wir einmal an, mehr ist besser) genauso eine Qualitätsabweichung wie weniger (als gewünscht). Wahrscheinlich wird der Kunde die "bessere" Qualität nicht beanstanden, aber da in der Produktion offenbar unnötiger Aufwand getrieben und damit unnötige Kosten verursacht wurden, ist die Abweichung nach oben aus der Sicht der Qualitätssicherung genauso problematisch. Boshaft könnte man in Anlehnung an "Recht hat mit Gerechtigkeit nichts zu tun" sagen: "Qualitätssicherung hat mit dem üblichen Qualitätsbegriff nichts zu tun".
- Es erscheint mir wichtig - aber auch fragwürdig - dass es keinen eigenen Qualitätsbegriff für die Software gibt, sondern der gleiche Qualitätsbegriff wie z.B. für die Güterproduktion verwendet wird. (Würde man eine Prozentskale für Softwarequalität einführen, kann man an Hand einer Metall-Legierung anschauliche Parallelen ziehen, um dann in der Umsetzung auf die Softwareproduktion die entsprechenden Schlüsse zu ziehen.) SoftwareEntwickler haben normalerweise einen idealistischen Qualitätsbegriff, der mit dem vorliegenden Begriff nicht kompatibel und in der Praxis nicht sinnvoll ist (z.B. siehe SoftwareOptimierung). Andererseits erlaubt eben der Qualitätsbegriff aus den ISO-Normen die Produktion absolut minderwertiger Ware unter dem Regime der Qualitätssicherung und unter Anwendung des gleichen Begriffes von "Qualität". Das ist natürlich auch schwer zu verdauen. Aber wenn der Auftraggeber "Mist" fordert, dann ist der gelieferte "Mist" die Erfüllung von Qualitätsforderungen, also "Qualität" im Sinne der Qualitätssicherung. Oder habe ich da etwas missverstanden? -- hl
- Das ist recht gut formuliert. Mir erscheint es jedoch eher fragwürdig, das das Thema SoftwareEntwicklung immer Analogien aus anderen Bereichen benötigt um verstanden zu werden. SoftwareEntwicklung (insbesondere die Entwicklung von IndividualSoftware) sollte mal als etwas eigenständiges betrachtet werden. Die transzendente (idealistische) Sichtweise von SoftwareQualität ist jedoch so individuell, dass sie es nicht erlaubt weitergegeben zu werden. Die richtige Mischung aus Idealisierung und absoluter Quantifizierung muss für SoftwareQualität noch gefunden werden. (Oder etwas ganz neues, anderes, noch nie da gewesenes). --AP.
...Kunde...nichts verloren/gewonnen...
Gemeint war DerKundeAlsRolle? im Softwareprozess. So wie beim ExtremeProgramming interpretiert, kann jemand anderer in die Rolle des Kunden schlüpfen (z.B. ein Vertreter einer Fachabteilung bei Entwicklungen im Haus, eine Gruppe von Beta-Testern bei Entwicklungen für einen noch nicht existierenden Markt) und die entsprechenden QualitätsForderungen entwickeln und vertreten. -- HelmutLeitner
Die Aufgabenstellung sei "Erstelle in der SpracheCee eine Funktion f(), die zwei Argumente a und b hat und die int-Summe a + b zurückliefert. Die Funktion wird verwendet werden, um das Alter in Jahren von menschlichen Geschwisterpaaren zu berechnen.".
Verschiedene Parteien nehmen sich der Aufgabe an und programmieren:
| /* A: */
int f(int a, int b)
{
return a + b;
} |
|
|
| /* B: */
int f(int a, int b)
{
return a += b;
} |
|
|
| /* C: */
int f(int a, int b)
{
return b + a;
} |
|
|
| /* D: */
int f(int a, int b)
{
assert(a >= 0 && a < 10000);
assert(b >= 0 && b < 10000);
return a + b;
} |
|
|
| /* E: */
int f(int a, int b)
{
if (a == 12345 && b == 54321)
a = 42;
return a + b;
} |
|
|
Meine Frage wäre nun: Haben diese verschiedenen "Softwaren" (denn das sind sie ja, kann man wohl sagen) jeweils (oder auch vergleichend) irgendwie eine "SoftwareQualität"? Wie "hoch" ist sie?
-- VolkerGlave
Ich versuchs mal. Meiner Meinung nach ist die Qualitätsreihenfolge A >= C >= B > D >> E.
Die Unterschiede zwischen A, B und C sind ästhetisch, jeder Compiler sollte den selben Code liefern. Trotzdem ist es irritierend, wenn jemand B oder C programmiert statt der einfachsten Variante. Man fragt sich unwillkürlich, ob dahinter ein wirrer Gedanke oder nur Nachlässigkeit steckt.
E verletzt mutwillig mit einem Mehraufwand an Code und ohne Nutzen die Basisanforderungen ("liefert die int-Summe von a und b").
D versucht durch Kontrolle der Parameter einen positiven Beitrag zu liefern. Die Basisanforderungen ("liefert die int-Summe von a und b") werden verletzt, ohne dass dafür ein Auftrag vorliegt. Das Anliegen ist zwar positiv, aber in dieser Form unzureichend gelöst. Eine sinnvolle Kontrolle müsste auf Modul-Ebene mit einheitlichen und entsprechend konfigurierbaren Altersgrenzen erfolgen und auch in der Release-Version vorhanden sein.
Die Frage, ob eine Parameterkontrolle erfolgen soll oder nicht, könnte sich aus dem Funktionsname ergeben. Hier wäre eine Parameterkontrolle offenbar fehl am Platz:
| /* F: */
int IntAddIntRetSum(int a, int b)
{
return a + b;
} |
|
|
Hier wäre eine Parameterkontrolle möglich:
| /* G: */
int AlterLimitLo=...;
int AlterLimitHi=...;
int AlterInvalid(int a)
{
return (a<AlterLimitLo || a>AlterLimitHi);
}
int AlterAddAlterRetSum(int a, int b)
{
if(AlterInvalid(a) || AlterInvalid(b)) {
// Fehlerbehandlung
}
return a + b;
} |
|
|
In jedem der Fälle A-E ist der Funktionsname als wesentlicher Faktor für die Lesbarkeit, Wartbarkeit, Wiederverwendung und semantische Klarheit ausgespart. Aus meiner Sicht stecken dort zusätzliche, wesentliche Qualitätsmerkmale.
-- HelmutLeitner
Man sollte sich dessen bewusst sein, dass in diesen Beispielen SoftwareQualität auf den Code reduziert wird. Dies ist meines Erachtens jedoch keineswegs akzeptabel, da nicht vollständig. Wie ist der jeweilige Prozess, der zu den Codefragmenten geführt hat? Wie sind diese Codefragmente dokumentiert? Wie waren die SoftwareQualitätsmerkmale festgelegt? Waren sie überhaupt festgelegt? Als Beispiel sei die Änderbarkeit genannt. Keines der Codefragmente benennt die Variablen entsprechend geeignet. Wird also eine Änderbarkeit gefordert, sind alle vorgeschlagenen Fälle (A bis E) gleich schlecht oder gleich gut. Hier verweise ich auf meine Behauptung, dass SoftwareQualitätssicherung nicht trivial ist. Somit sollte die Sache der Entstehung der Software insgesamt betrachtet werden. Ein echtes Mengenmaß hier anzugeben ist eigentlich unmöglich, oder?
--AP.
- Man sollte sich dessen bewusst sein, ...: Ja, ist mir/uns bewußt. Dies ist meines Erachtens jedoch keineswegs akzeptabel, ...: Ich hingegen finde es schon ganz in Ordnung, wenn man versucht, zunächst erstmal "im Kleinen" (Bottom-Up) etwas zu behandeln. (Tatsächlich hatte ich gehofft, dass niemand antworten würde, was ich als Indiz gewertet hätte, dass sogen. "SoftwareQualität" auch "im Großen" nicht viel nützt. Schade, hat Helmut vereitelt.) Wie sind diese Codefragmente dokumentiert?: So wie sie da standen, gar nicht. Das muß auch noch nicht per se von Übel sein. ... SoftwareQualitätsmerkmale ... Änderbarkeit ... Keines der Codefragmente benennt die Variablen entsprechend geeignet.: Die Benennung erfolgte gemäß Aufgabenstellung, was so schlimm nicht ist. ... SoftwareQualitätssicherung nicht trivial ... Ein echtes Mengenmaß hier anzugeben ist eigentlich unmöglich, oder?: (Helmut hat ja auch nur relative Einschätzungen gegeben, und auch nur "seiner Meinung nach".) Aber, was denn nun? Entweder (a) postuliert man solche Begriffe wie bei SoftwareQualitätssicherung nachzulesen (DIN ...), kommt dann meiner Meinung nach allerdings auch nicht umhin, ausrechenbar Vergleiche anzustellen (d. h. eben doch Zahlen zu nennen). Oder (b) man läßt es bleiben. (Praxis: nach außen wird (a) vertreten/verkauft - inklusive Erhaltung einer nicht nur auf den Softwarebereich beschränkten "Qualitätsbewertungsbranche" -, faktisch gemacht wird (b), nicht automatisch "schlechte Qualität" erzeugend.) -- vgl
- Damit ist ganz gut mein Problem als "Qualitätssicherungsbeauftragter" in der SoftwareEntwicklung beschrieben. Metriken mit zu gestalten, mit denen die Qualität des Ergebnisses der Arbeit von Wissensarbeitern (eine Software mit allem Drum und Dran) bewertet werden kann. Die in SoftwareQualitätssicherung postulierten Sätze stammen aus den ISO-Normen. Sobald ein Unternehmen danach Zertifiziert ist, müssen diese Sätze quasi zum Gesetz gemacht werden. Leider kommen in den seltensten Fällen ja solch relativ eindeutige Aufgabenstellungen an die SoftwareEntwicklung. Meistens liegen diese doch mindestens eine Abstraktionsebene höher oder sind gar sehr diffus definiert. Vielleicht so: "Ich Brauche eine Funktion f. Sie soll das Alter in Jahren von zwei menschlichen Geschwisterpaaren addieren und als Ergebnis zurückliefern. Die Funktion soll universell einsetzbar und robust sein und in Cee-Programmen zum einsatz kommen."? Käme dann ein anderes Ergebnis heraus? Wenn Du unbedingt eine relative Berwertung der Code-Fragmente möchtest, in dem ich als Kunde die Schnittstelle angegeben hätte, dürfte ich mir auch nur diese ansehen. Sie war sehr genau definiert und im normalen Gebrauch der mit dem zweiten Satz angegeben wurde, wird offensichtlich bei allen Vorschlägen kein Fehler auftreten. Da ich sonst keine Anforderungen an z. B. Änderbarkeit, oder übertragbarkeit gemacht habe müsst die Qualität aus Kundensicht bei allen Codefragmenten zumindest erreicht worden sein. Aus Prozesssicht ist sie in den Fällen D: und E: überschritten, wodurch die Firma verluste erleiden könnte, da die Entwikclung mehr Aufwand verwendet hat, als zum erreichen der Anforderungen unbedingt nötig. --AP.
- Schade, ... Sorry, dass ich deine Intentionen durchkreuzt habe :-) . Ich glaube, wie wir die Diskussion begonnen haben, war schon klar, dass wir uns auf wackeligem Boden bewegen werden. -- hl
- Keines ... benennt die Variablen geeignet Axel, was sollten - ich nehme an längere - Variablennamen in obigen Beispielen bringen? --hl
- Wackliger Boden ist ein guter Begriff für SoftwareQualität. Mit ungeeigneten Variablennamen meinte ich nicht unbedingt längere. (Was jedoch zugegeben hier der Fall sein würde.) Sondern evtl. welche, die den Anwendungsfall entsprechend berücksichtigen. Hier setzt dann eine Beratung des Kunden ein. Da diese aber vermutlich zu dem Ergebnis gekommen ist, a und b sind als Interger entsprechend geeignet, lässt sich interpretieren, dass die Aussage, was damit gemacht werden soll, sich auf die Betrachtung der technischen Grenzen von Integer-Werten beziehen könnte. --AP.
- Wobei man jedoch bemerken sollte, dass bereits die Anforderungsdefinition schlecht ist. So wird die inhaltliche Anforderung zwei Alterswerte zu addieren mit einer unnötigen technischen Anforderung einen int zurückzugeben verknüpft werden. Weiterhin scheint es mir nicht gerade sinnvoll, das zwei Alterswerte zu addieren (Was sollen meine 25 Jahre plus deine 20 Jahre bedeuten? - Zusammen sind wir immer noch 25 und 20 Jahre alt und nicht 45.).
KategorieSoftwareQualität
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 11. September 2008 14:44 (diff))