Mail 0529

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

Contents		Title From Date		History Content Links to V-Model

Title

From

Date

History

Content

> From:           	Rahel Seemann 

> im folgenden sind  einige Fragen und Anmerkungen zum V-Modell
> aufgelistet, die ich hier stellen bzw. zur Diskussion stellen möchte.
> Ich bin für jede Antwort dankbar.

##################################################################### 
> · Produktbezeichnung "Technische Anforderungen"
> Die Produktbezeichnung "Technische Anforderungen" erscheint mir etwas
> irreführend. Mit dem Produkt ist doch, wenn ich es richtig verstehe, in
> weiten Teilen eine fachliche Spezifikation gemeint, die sich allerdings
> in der Struktur an der bereits festgelegten Systemarchitektur
> orientiert. Technische Anforderungen sind in meinem Verständnis nur die
> Anforderungen, die tatsächlich aufgrund der gewählten technischen
> Architektur entstehen und für das Zusammenspiel der SW-Elemente, nicht
> aber für die Wiedergabe der fachlicher Anforderungen, notwendig sind.
> Entsprechend verstehe ich auch die meisten im Beispiel Tanf (ISS)
> aufgelisteten "technischen Anforderungen" als fachliche
> Feinanforderungsdefinitionen. Beruhen meine Schwierigkeiten auf einem
> inhaltlichen Mißverständnis oder einer abweichenden Definition des
> Begriffs "technisch"?

In den Anwenderforderungen finden sich die Wünsche des Anwenders oder 
Auftraggebers an das System als Ganzes.
Die Technischen Anforderungen werden von den Anwenderforderungen 
abgeleitet. Sie können sich auf das Gesamtsystem beziehen oder auf 
seine Teile. Der Schwerpunkt der TAnf bezieht allerdings auf Teile 
der Erzeugnisstruktur, als auf Segmente (falls welche existieren) 
oder auf SW- und HW-Einheiten. Die Anforderungen an SW-Einheiten 
befinden sich im Kap. 5 der TAnf und sind die Designvorgabe für jede 
einzelne SW-Einheit. D. h. der SW-Einwickler einer SW-Einheit erhält 
die TAnf einer SW-Einheit und entwickelt auf dieser Basis die 
SW-Einheit. 

Manchmal macht es Schwierigkeiten zwischen deteillierten 
fachlichen Anforderungen und technischen Anforderungen zu 
unterscheiden, dies trifft besonders bei SW-Systemen im 
administrativen Umfeld zu, wie es bei Ihnen offensichtlich der Fall 
ist. Hier von "technischen Anforderungen" zu sprechen macht manchmal 
Probleme, weil es sich hier um die detaillierten (abgeleiteten) 
fachlichen Anforderungen handelt, die dann in Software umgesetzt 
werden. 
Diese Diskussion zum schwierigen Verständnis der fachlichen 
und technischen Anforderungen hatten wir in der Mailingliste schon 
mal im Juni. 98 (siehe Archiv bei der Uni Bremen Nr.175, 178) 
vielleicht steht da etwas, was Ihnen hilft. 

Siehe Mailingliste bei:
http://www.informatik.uni-bremen.de/uniform/gdpa_d/

#####################################################################

> · Erzeugnisstruktur SE insgesamt:
> Die Erzeugnisstruktur wird nur sehr abstrakt beschrieben. Auch das
> Glossar unterstützt ein sicheres und eindeutiges Verständnis dieser
> Begriffe nicht. Die abstrakte Beschreibung vergrößert sicher die
> universale Anwendbarkeit des V-Modells, allerdings sehr zu Lasten eines
> einheitlichen Verständnisses. Ein einheitliches Verständnis der
> Erzeugnisstruktur beeinflußt jedoch die Detailtiefe der Ergebnisse der
> folgenden SE-Hauptaktivitäten und ist damit unverzichtbar für die
> sinnvolle Anwendung des V-Modells. 

Da haben Sie recht. Diese Definitionen sind zu allgemein. Damit kann 
man nicht viel anfangen. Aus diesem Grund erscheint mir eine 
projektspezifische Detaillierung, mit Beispielen untermauert, 
hilfreich.

> Es wäre daher wünschenswert, wenn die
> Erzeugnisstruktur mit Beispielen verdeutlicht würde. Ist so etwas
> geplant? Bzw. entsprechen die Beispiele im Buch "Das V-Modell in der
> Praxis" (Hg. Versteegen, 2000) den Vorstellungen der Entwickler des
> V-Modells?

In dem von Ihnen genanten Buch habe ich auf der Seite 156 die 
Definitionen von System, Segment SW- und HW-Einheit weiter 
präzisiert und dafür Beispiele gegeben. Diese beispiele müssen jedoch 
auf das jeweilige Umfeld angepaßt werden. 

Insofern kann man es im V-Modell nicht viel detaillierter machen, 
weil es sonst in den sehr unterschiedlichen Einsatzbereichen des VM 
nicht mehr passt. 
#####################################################################

> · Identische Behandlung der Beschreibung von Modulen und Datenbanken (SE
> 4 und SE 5)
> Die Anforderung nach unterschiedlichen Aktivitäten für das Beschreiben
> von Modulen/SW-Komponenten und Datenbanken wurde schon des öfteren
> gebracht. Es soll in Zukunft hier stärker differenziert werden. Ich
> befürworte die Bestrebungen, diese Aktivitäten in diesem Sinne zu
> detaillieren. 

In meinem Änderungsantrag (Nr. 0051) habe ich gefordert, dass die 
Aktivität SE 5.1, entsprechend ihren zwei Teilaspekten, zergliedert 
wird.

> Zum einen sind die bei Modul- und Datenbankbeschreibungen
> verwendeten Methoden, mitwirkende Rollen usw. andere. 

Die Methoden, Rollen und Tätigkeiten sind total verschieden.
Darüber hinaus würde auch das Tailoring vereinfacht.

> Der
> Datenbankaufbau wird oft auch in einem zentralen Dokument und nicht
> verteilt jeweils beim betreffenden Modul beschrieben -- hier wird nur die
> Datenverwendung des Moduls berücksichtigt. Außerdem wird bei
> inkrementell entwickelten Projekten Datenbank- und Modulbeschreibung
> eventuell in unterschiedlicher Detaillierung durchgeführt -- während das
> Datenbankdesign für das mit der letzten Ausbaustufe geplante System
> zumindest bereits grob vorliegt, werden die Modulbeschreibungen
> vielleicht nur für das aktuell geplante Inkrement im Detail
> durchgeführt.

Sie sprechen sehr in meinem Sinne. 

Allerdings habe ich das Problem (Trennen von SE 5.1) bereits im Dez. 
98 (Nr. 262) in der Mailingliste diskutiert. Dr. Eduardo 
Garcia-Herreros von Softing GmbH meinte damals, es sei besser SE 5.1 
zusammenzulassen. Es gibt also auch andere Meinungen hierzu.
####################################################################


Damit habe ich Ihre Fragenliste in mehreren Tranchen abgearbeitet.

Vielleicht haben aber noch andere erfahrene VM-Anwender eine Meinung 
zu den angesprochenen Themen.

Klaus Plögert
*********************************************************
Dr. Klaus P. Ploegert
IABG mbH
Dept.:  IK61                        Tel: +49-89-6088-3420
D-85521 Ottobrunn, Einsteinstr. 20  Fax: +49-89-6088-3722              
Germany
E-Mail: ploegert@iabg.de            Mobil: 0172-9302352
URL:    http://www.v-modell.iabg.de
        http://www.iabg.de

Links to V-Model

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