1996-1997-1998-1999-2000-2001-2002
Re: Qualitätsmerkmale im V-Modell (450)
Petrasch, R.
Friday, 11. February 2000 13:05
Mail 0442

Mail 0443

Mail 0444

Mail 0446

Mail 0447 (Color: Blue)

Mail 0448 (Color: Green)

Mail 0450

Mail 0452

Mail 0458

Mail 0459

Mail 0488

Mail 0489

Mail 0490

Mail 0491

Mail 0492

Mail 0493

Mail 0494

Mail 0495

Mail 0496

Mail 0497

Mail 0500

Mail 0501

Mail 0502
From: Roland Petrasch
Hallo Herr Beckmann,
> Was das Problem ist, weiss ich aber immer noch nicht. Ist
> es mehr, als dass im QS-Submodell das Wort (!) "Merkmal"
> nicht mehr vorkommt?
Ja, denn es wäre hilreich mehr darüber zu erfahren. Im Prinzip läßt sich
doch mit Merkmalen eine ganze Menge anfangen, z.B. bei dem Nachweis,
ob bestimmte Kategorien von Anforderungen erfüllt werden. Ein anderes
Thema sind Metriken, die ebenfalls auf der Merkmalsebene entstehen.
Das V-Modell könnte als Prozeßstandard helfen, da die Zuordnung zu Methoden
möglich sein soll.
So aber erhalte ich keine Hinweise, welche Merkmale mit welchen
Testmethoden untersucht werden können, damit ein Nachweis der Erfüllung von
bestimmmten Anforderungen erfolgen kann.
Ein Beispiel: Der Äquivalenzklassentest (wenn als Funtkionstest im Einsatz)
ermittelt sicherlich nicht Merkmalswerte für das Zeitverhalten von Software-
Systemen, so daß auch keine Anforderungen an die Reaktionsgeschwindigkeit zu
betrachten sind. Hier hätte ich mir von einem prozeßorientierten Standard,
der eine Methodenzuordnung vorsieht mehr erwartet und sicherlich wird dies
einer der Bereiche sein, wo in der Praxis die meisten Fragen entstehen.
Welche QS-Techniken in Verbindung zu welcher Art von SWKE, Aktivität und
Anforderungsklasse.
> Ein einfacher Hinweis auf Teil 1/S. 3-1, zweiter Satz kürzt
> die Suche ab... (Ist das die Stelle, um die es Ihnen geht?)
>
> Da heisst es ja dann weiter: "an die Qualitätsmerkmale, wie
> z. B. Wartbarkeit". D.h. wohl, dass wir "Funktionalität,
> Zuverlässigkeit, Benutzbarkeit, Effizienz und Übertragbarkeit"
> (Teil 1/Anhang) ergänzen dürfen, wenn wir mal davon, dass
> "Änderbarkeit" die "Wartbarkeit" ersetzt.
> Und Anforderungen an diese 'Dinge' zu stellen ist doch ok
> - oder?
Genau an dieser Stelle wird die Inkonsistenz bzgl. der Terminologie beim
V-Modell besonders deutlich: Anforderungen sind eben nicht dasselbe wie
Merkmale. Das geht aber beim V-Modell drunter und drüber:
Mal Anforderungen, mal Merkmale, mal Anforderungen an Merkmale - oh je!
Wer räumt da mal auf?
> So verstehe ich zumindest den Abschnitt:
> 'Die aufgestellten Anforderungen an das zu entwickelnde
> System werden im Laufe des Projekts durch detailliertere
> Anforderungen verfeinert und in den Produkten "Anwender-
> forderungen" und "Technische Anforderungen" fest-
> gehalten. Die im Submodell "Qualitätssicherung" (QS)
> beschriebenen Maßnahmen dienen dem Nachweis der Erfüllung
> dieser vorgegebenen Anforderungen, der präventiven Vermei-
> dung von Mängeln und der Sicherstellung einer Prozeßqualität.'
> (Teil 1/S. 5.1)
Ja, gut. ABER: Warum erhalte ich keine Hilfe bei der Zuordnung ?
Die Merkmale, die es ja wohl unbestritten bei jeder Software gibt,
sind doch produkt- und prozeßorientiert in Hinblick auf die
Anforderungen zu untersuchen. Das Submodell QS als wichtigster Teil für
Qualität bemüht sich jedoch noch nicht einmal ansatzweise um Klärung:
Lapidar heißt es, daß die Maßnahmen dem Nachweis der Erfüllung dienen.
Das ist ja noch abstrakter als die Qualitätsdefinition der ISO, die
das Wort "Merkmal" wenigstens noch nennt. Was nützt mir denn ein Submodell,
welches noch weniger Informationen liefert als die ohnehin schon sehr
allgemeine und abtrakte ISO 9000 ff.? So geht das nicht.
> Nein, das sehe ich nicht so! Aber die das QS-Submodell kümmert
> sich verstärkt um den Teil "bezüglich ihrer Eignung, festgelegte
> und vorausgesetzte Erfordernisse zu erfüllen".
Ja, ohne auch nur ansatzweise Hinweise bzgl. der Prüfung von Merkmalen
in Hinblick auf die Anforderungen zu geben. Das ist schwach!
(s. nächste Punkte)
> Ist das nicht das, was in Abbildung 2 Ihres Papers dargestellt
> wird?!? Und echte "Äquivalenz" hat man dann, wenn Merkmale und
> Anforderungen die gleich Granularität haben (wenn man also z.B.
> die Anfoderung "Erwartungskonformität durch Konsistenz" soweit
> herunterbricht, dass sie in einzelne Anforderungen für die Dia-
> loge u.ä. zerfällt.).
Richtig, aber dann besteht immer noch keine "Identität" zwischen
Anforderungen und Merkmalen, sondern eine n:m-Beziehung, die eine
Qualitätsbewertung zuläßt. Von Äquivalenz zu sprechen, paßt hier
eigentlich nicht so recht, da das Ziel die Prüfung der Merkmale GEGEN
die Anforderungen ist, d.h. die Beziehung z.B. die Ausprägung "erfüllt"
bzw. "nicht erfüllt" hat. Aber gut, der Begriff "Äquivalenz" ist das
geringste Problem. Das V-Modell sollte an dieser Stelle helfen, egal ob
es um Äquivalenz oder um Erfüllung geht. Aber das tut es halt nicht.
> >> Das beigefügte Paper fand ich leider auch nicht sehr erhellend!-(
> >> Das Beispiel ist m.E. problematisch, da Merkmal und Anforderung
> >> von verschiedenem Kaliber sind.
> >Nun, da haben Sie recht. Wenn diese aber von "verschiedenem Kaliber"
> >sind, warum werden diese denn nicht auch entsprechend vom V-Modell
> >behandelt ?
> Statt "Kaliber" hätte ich hier die im obigen Sinne "Granu-
> larität" sagen sollen. Ich wollte nicht sagen, dass es sich
> dabei um wesensverschiedene Dinge handelt, sondern das sie
> in dem Paper verschieden detailliert sind.
Nein, Anforderungen können genauso verfeinert werden wie Merkmale.
Der Anwender hat Anforderungen, die er sehr detailliert darlegen kann.
Die Entwicklung von Merkmalen ist Aufgabe des Software-Entwicklers,
d.h. die Granularität ist bei der Unterscheidung zwischen Anforderungen
und Merkmalen nicht primär wichtig - auf jeden Fall genügt dies nicht
als "Ausrede", um nun gar nicht mehr von Merkmalen zu sprechen.
Es wäre daher unzulässig zu sagen: "Merkmale sind feiner granuliert und
deshbalb reden wir im V-Modell (Submodell QS) überhaupt nicht davon. "
Wenn das so stimmen würde, dann müßte das Submodell auch nicht mehr die
Merkmale erwähnen - das tut es aber.
> In der Hoffnung, nicht noch mehr zur Verwirrung
> beigetragen zu haben, wünsche ich ein schönes
> Wochenende!
> Markus Beckmann
Danke, das wünsche ich auch !
Viele Grüße
Roland Petrasch
not defined
 |
 |
GDPA Online
Last Updated 01.Jan.2002
Updated by Webmaster
Last Revised 01.Jan.2002
Revised by Webmaster
 |
|