Mail 0502

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

Contents		Title From Date		History Content Links to V-Model

Title

From

Date

History

Content

From:           	Roland Petrasch 


Sehr geehrter Herr Hausen,

auch auf die Gefahr, dass ich mich wiederhole: 
Es mag richtig sein, dass die Verwendung von
ISO/IEEE/IEC/ANSI/OMG/ECMA/BSA-Normen und -Standards empfehlenswert ist,
ABER:
a) die Normen sind NICHT aufeinander abgestimmt, verwenden eine z.T.
sehr unterschiedliche Terminologie, enthalten recht abstrakte (und
manchmal praxisfremde) Modelle und widersprechen sind sogar in einigen
Punkten (was die Praxistauglichkeit nicht gerade erhöht) und
b) das hat mit den von mir angesprochenen Mängeln des V-Modells nichts
zu tun.

Mein Diskussionsbedarf liegt darin begründet, dass ich mit der Aussage 
 "Es ist nicht notwendig Q-Merkmale sowie den Umgang mit diesen im
V-Modell zu definieren."
nicht Leben kann. Auch das Hilfsargument, daß es
ISO/IEEE/IEC/ANSI/BSA-Normen gibt, ist nicht befriedigend.

Also gern führe ich meine "Magenprobleme" noch mal auf:
a) Warum erwähnt das V-Modell die Anforderungen und im SE-Submodell zwar
Q-Merkmalem aber disbzgl. nur EINE
Norm. Der "Höhepunkt" an Inkonsistenz entsteht nun dadurch, dass das
Submodell QS den Begriff Q-Merkaml noch nicht einmal erwähnt. Wenn die
o.g. Aussagen stimmen würden, dann sollte sich das V-Modell gar nicht
damit auseinandersetzen (Motto: "Not-my-Job"). 
b) Es geht in der Frage darum, 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 (wenn auch
nicht hilfreich im Sinne der praktischen Anwendung).

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
Der o.g. Artikel zeigt, daß man Aktivitäten durchaus allgemein aber MIT
Bezug zu Anforderungen und Merkmalen beschreiben kann - wieso es beim
V-Modell nicht gehen soll, ist nicht nachvollziehbar.

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

Viele Grüße
Roland Petrasch 


vm-d-l wrote:

Software Evaluation for Certification: Principles, Practice and Legal
Liability. Rae A., Robert P. and Hausen H. L. (Eds)
McGraw Hill, International Software Quality Assurance Series,
verweisen
-- 
 Hochachtungsvoll Ihr / 
Hans-Ludwig Hausen                               mailto:hausen@gmd.de
ORG:   GMD German National Research Center for Information Technology
MAIL:  GMD, Schloss Birlinghoven, D-53757 St Augustin, Germany, EU 
URL:   http://www.scope.gmd.de  <> ftp://ftp.gmd.de/GMD/SW-Quality
FON:  +49-2241-14-2937(office)  +49-2241-14-2717(secretariate) +49-2251-51998(home)
FAX:  +49-2241-14-2618(paper) +49-2241-14-2197(computer)

Links to V-Model

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