Mail 0500

1996-1997-1998-1999-2000-2001-2002

Contents		Title From Date		History Content Links to V-Model

Title

From

Date

History

Content

[Anmerkung des Moderators: Dies ist der 500. Beitrag in
dieser Mailingliste -- ein Tusch zum heißen Sommeranfang!]


From:           	Roland Petrasch 


Hallo,

die Verweise auf andere Quellen ist ja nett gemeint, aber das ist nicht
das Problem, welches ich ursprünglich ansprach: Wir alle kennen die
verschiedenen Normen und Standards der ISO, DIN, IEC, ANSI, OMG etc. zur
genüge, so daß einem damit keineswegs geholfen ist.
Insofern muß ich dem Beitrag von Herrn Hans-Ludwig Hausen vehement
widersprechen.
Es heißt hier: "Es ist nicht notwendig Q-Merkmale sowie den Umgang mit
diesen im V-Modell zu definieren."
Und dann sinngemäß als Begründung: Es gibt schon "irgendwo" andere
Normen und Standards zu dem Thema und außerdem sei das alles zu
"projektspezifisch", um es im V-Modell zu behandeln.
Diese Argumentation ist widersprüchlich:
a) Warum erwähnt dann das V-Modell überhaupt Q-Merkmale und nur EINE
Norm. Wenn die o.g. Aussagen stimmen würden, dann sollte sich das
V-Modell gar nicht damit auseinandersetzen (Motto: "Not-my-Job"). Aber
so konsequent "heraushalten" wollte man sich dann offensichtlich auch
wieder nicht ...
b) Es geht in der Frage NICHT darum, Merkmale zu "behandeln" oder zu
"definieren", sondern allgemein den _Umgang_ (!) mit Q-Merkmalen (welche
auch immer das sind) zu beschreiben - das ist die Aufgabe eines
Prozeßstandards und dieser Aufgabe kommt das V-Modell in keinster Weise
nach !
c) Wenn es denn so viele "tolle" Normen gibt, warum bezieht sich das
V-Modell nun ausgerechnet auf die ISO 9126 ? Das ist nicht
nachvollziehbar und weder konsequent, noch sinnvoll, da es auch andere
brauchbare Werke gibt, die sich gut mit Prozeßstandards verwenden
lassen.
d) Ebenfalls nach wie vor unbeantwortet bleibt die Frage, warum sich das
Submodell QS zwar explizit auf die Qualitätsdefinition der ISO 8402
bezieht, jedoch genau den wichtigsten Teil dabei ignoriert: Der
Zusammenhang zwischen Anforderungen und Merkmalen - nein so hilft das
V-Modell nicht. Dann sollte es das Thema "Qualität" besser ganz
totschweigen - das wäre dann wenigstens in sich konsistent.

Das Argument, man solle sich die Sachen doch selbst zusammensuchen, ist
nicht allzu überzeugend, denn dann braucht man das V-Modell auch nicht
mehr (ausser den netten Dokumentstrukturbeschreibungen vielleicht):
Erst soll man das alles einem Tailoring unterziehen,
dann die Methodenzuordnung vornehmen und 
dann beginnt das große Rätseln, wo, wann und wie man die "Requirements"
und die "Characteristics" zusammenbringt, um Qualität nachzuweisen, ohne
dass auch nur ansatzweise das V-Modell dabei hilt.
Dass es auch anders geht, habe ich in dem folgenden Artikel dargelegt:
Petrasch, R.: Über den Software-Qualitätsbegriff. In:
Gl-Softwaretechnik-Trends, Mitteilungen der Gesellschaft für Informatik,
Band 19, Heft 3, Nov. 1999, S. 36-39

Das Problem scheint mir eher zu sein, das viele (und evtl. die Ersteller
des V-Modells?) gar nicht berücksichtigen (oder wissen), dass man
zwischen Anforderungen und Merkmalen unterscheiden kann und dass es eine
prozeßorientierte Sichtweise darauf geben kann ! Der Qualitätsnachweis
gelingt nämlich nur durch die Gegenüberstellung von Anforderungen und
Merkmalen (gem. ISO 8402). Dies alles bei einem Prozeßstandard zu
ignorieren bedeutet, dass die Unterstützung bei der Erzeugung von
Produktqualität praktisch nicht vorhanden ist - das ist der (traurige)
Status Quo des V-Modells

Also aus meiner Sicht gibt es hier viel zu verbessern und ich hoffe
(auch ohne ein "Formular" ausgefüllt zu haben), dass man auf der
nächsten Änderungskonferenz einmal darüber nachdenkt.

Viele Grüße
Roland Petrasch

Links to V-Model

GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster