Mail 0452

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

Contents		Title From Date		History Content Links to V-Model

Title

From

Date

History

Content

From:           	Uta.Birk@t-online.de (Markus Beckmann)

On Fri, 11 Feb 2000 13:01:22 +0100, you wrote:

>From:           	Roland Petrasch 
>...
>                                                    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.
Das wäre natürlich in vielen Fällen sicherlich hilfreich.
Ich denke nur, dass das einen Standard sher heftig über-
fordert - oder zumindest überfrachtet, denn je detaillier-
ter so eine Zuordnung erfolgt, desto mehr Unterscheidungen
muss man einbauen. Von dem "Standard" als so etwas wie dem
kleinsten gemeinsamen Nenner würde man sich damit sehr
schnell entfernen!?

>...
>Genau an dieser Stelle wird die Inkonsistenz bzgl. der Terminologie beim
>V-Modell besonders deutlich: Anforderungen sind eben nicht dasselbe wie
>Merkmale.
Nicht dasselbe - aber (unter bestimmten Bedingungen, s.u.)
äquivalent.

>          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?
Man kann da sprachlich sicher etwas verbessern!
 
>> 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 ? s.o.!?!
>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 kann man aber auch so verstehen: "Was immer hier getan
wird, egal welche Methode man verwendet und welche Merkmale
man im einzelnen betrachtet, die Aktivität/der Prozess muss
dem Nachweis der Erfüllung der Anforderung dienen." Die Aus-
gestaltung durch konkrete Methoden bleibt dann dem (V-Modell)
Anwender überlassen. (Dass die Auswahl der richtigen Methode
mühsam sein kann und eine Anleitung hilfreich sein könnte,
ist unbestritten.)

>...
>Richtig, aber dann besteht immer noch keine "Identität" zwischen
>Anforderungen und Merkmalen, sondern eine n:m-Beziehung, die eine
>Qualitätsbewertung zuläßt.
Eine n:m-Beziehung hat man nur dann, wenn man verschieden
Detaillierrungsgrade bei Anforderungen und Merkmalen hat.
Das wird in der Praxis wahrscheinlich immer so sein, kann
sich aber auch immer zu handfesten Problemen auswachsen!

> ...
>> 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.
Hier sehe ich einen kleinen aber feinen Unterschied:
Anforderungen kann und muss man (in der Regel verfeinern),
da sie von einer groben Idee - als Anforderung für das
gesamte System -  hin zu einer Sammlung sehr detaillierter
- und einzeln nachprüfbarer (!) - Forderungen konkretisiert
werden muss.

Hat man das fertige System, kann man eine riesige Menge von
"atomaren" Merkmalen identifizieren (z.B. die Position eines
Buttons in einem bestimmten Fenster), diese kann man dann zu
"komplexen Merkmalen" (z.B. Fenster-Layout) zusammenfassen.
(Noch komplexere Merkmale sind die Qualitätsmerkmale...)

Beim Nachweisen der Anforderungen muss man dann zu jeder An-
forderung jeweils das passende (komplexe) Merkmal finden.

>Der Anwender hat Anforderungen, die er sehr detailliert darlegen kann.
(So sollte es sein - ist in der Praxis aber leider nicht so
- zumindest nicht immer. Aber das ist ein anderes Thema...)

>Die Entwicklung von Merkmalen ist Aufgabe des Software-Entwicklers,
Hm, jetzt wird es schwierig! Entwickelt der Software-Ent-
wickler wirklich die Merkmale (atomar)? Oder verfeinert
er - mehr oder weniger implizit, i.e. im Kopf oder etwas
formaler in einem Design - die Anforderungen, bis er etwas
entwickelt hat, mit dessen Merkmalen man die Erfüllung
der Anforderungen nachweisen kann?

Das wird jetzt vielleicht etwas philosophisch. Aber viel-
leicht steckt hier auch das Problem: Bei der Formulierung
von Anforderungen - selbst wenn sie sehr detailliert sind,
hat man in der Regel nicht alle möglichen oder nötigen
Merkmale im Kopf, anhand deren man später ihre Erfüllung
nachweisen kann. Damit wird dann auch in einem konkreten
Projekt die Zuordnung von Methoden zu QS-Maßnahmen sehr
schwierig. (Noch schwieriger ist das dann im Rahmen eines
"abstrakten" Standards.) Trotzdem kommt man nicht darum
herum das zu tun - zumindest wenn man an einem echten
Nachweis der Anforderungserfüllung interessiert ist. Und
daher stimme ich Ihnen zu, wenn  Sie sagen, dass hierbei
Hilfestellungen sehr wertvoll wären.

>...
>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.
Die Frage ist, bis zu welchem Detaillierungsgrad ein
Standard Hilfestellung geben will und kann...

Nachdem das Wochenende diesesmal fast rum ist,
wünsche ich allseits frohes Schaffen...
Markus Beckmann

Links to V-Model

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