Previous Next V-Model Official Homepage by IABG  
Mail 0450  

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

Contents  
  • Title
  • From
  • Date
  •  
  • History
  • Content
  • Links to V-Model
  • Title

    Re: Qualitätsmerkmale im V-Modell (450)

    From

    Petrasch, R.

    Date

    Friday, 11. February 2000 13:05

    History

    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

    Content

    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

    Links to V-Model

    not defined

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