Mail 0516

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 

> Sehr geehrte Damen und Herren,
> Folgende Anmerkungen und Fragen sind mir bei der Beschäftigung mit dem
> V-Modell aufgefallen. Es würde mich interessieren, ob es vielleicht
> Gründe für die gewählten Lösungen gibt, die ich übersehen habe oder ob
> die Anmerkungen von anderen V-Modell-Interessierten geteilt werden.
> Für Hinweise bin ich dankbar.
> R. Seemann

Da haben Sie aber fleissig Probleme gesammelt. 
 
> Datenmigration.
> Die Datenmigration wird, wenn ich nichts übersehen habe, in folgenden
> SE-Aktivitäten abgehandelt:
> · SE 1.8 SWPÄ-Konzept ( SWPÄK_9.  > Überleitung in die Nutzung)
> · SE 5.1 - Unterpunkt Betriebsinformationen ergänzen - unter anderem
> Installation und Datenübernahme
> · SE 7.1 Zur SW-Komponente integrieren... "Zu Integrationszwecken kann
> es erforderlich sein, daß zusätzlich zu den vorhandenen SW-Modulen Code
> erstellt oder Prozeduren geschrieben werden müssen.."
> · SE 9.1 Beitrag zur Einführungsunterstützung leisten - "Maßnahmen
> definieren und planen, die für Überleitung in die Nutzung erforderlich
> sind - u.a. "Vorgehen bei der Überleitung (Datenübernahme, Parallellauf,
> Übergangsregelungen)"
> Wird diese Behandlung der Stellung von Datenübernahmen  im notwendigen
> Umfang gerecht? Es werden oft eigene, umfassende Dokumente zu
> Datenübernahmen verfaßt. Meistens werden die Übernahmeprozeduren
> parallel zur SW-Entwicklung implementiert - sie unterscheiden sich
> jedoch von sonstigen SW-Modulen wesentlich, da sie nur für die einmalige
> Nutzung bestimmt sind. Insbesondere müssen auch QS-Prüfungen für die
> Datenübernahmen durchgeführt werden.

Wenn die Migration (ob Daten- oder Ablösung Altsystem durch 
Neusystem) sehr aufwendig und abstimmungsbedürftig wird, empfiehlt es 
sich einen eigenen Migrationsplan (manchmal auch Transitionsplan 
genant) zu erstellen. Das V-Modell kennt einen derartigen Plan nicht. 
Es wäre aber sinnvoll einen solchen Plan zu definieren.
Ich werde einen Änderungsantrag hierzu formulieren.

 
> Produkte Schnittstellenübersicht (SSUb_) und Schnittstellenbeschreibung (SSB_)
> Zwei inhaltlich stark überlappende Dokumente werden nahezu - aber doch
> nicht ganz - gleichzeitig angelegt und vorlegt:

Die Dokuemte überschneiden sich nicht. SSÜb sagt, welche 
Schnittstellen existieren und SSB gibt Aufschluss über die Semantik 
der SS

> 1) Schnittstellenübersicht (SSUb_) in SE 2.1 System technisch
> entwerfen angelegt, 

hier werden die System- und Segmentschnittstellen beschrieben.

> 2) Schnittstellenbeschreibung (SSB_) in SE 2.5. Schnittstellen
> beschreiben angelegt, in SE 4.2 SW-interne und -externe Schnittstellen
> beschreiben vorgelegt.

in SE 4.2 werden die internen SS der SW-Einheiten ergänzt.

> Wieso werden trotz der starken Überlappung zwei Dokumente mit zwei kurz
> aufeinander folgenden Produktprüfungen angelegt? 

Die Dokumente überschneiden sich nicht und von zwei 
aufeinander folgenden Produktprüfungen weiß ich auch nicht. Vorgelegt 
heißt nur, dass die Dokumente abgeschlossen werden. Ob sie geprüft 
werden, steht im QS-Plan. Hier macht das VM keine Vorgaben. 
Darüber hinaus können Sie bei großen Systemen die 
Schnittstellenbeschreibungen auch in Einzeldokumente aufgliedern.

> In diesen zwei
> Dokumenten müssen die Informationen redundant gepflegt werden. 

Redundanz sollte vermieden werden. Die Redundanz, die Sie 
unterstellen gibt es m. E. nicht. Es gibt jedoch Redundanz zwischen 
den Schnittstellenbeschreibungen in den Architekturdokumenten (z. B. 
SysArch_2.1.2) und der Schnittstellenbeschreibung. Um diese Redundanz 
zu vermeiden würde ich die Syntax und Semantik der SS nur in den 
Architekturdokumenten beschreiben und in die SSB weglassen.

> Eine
> realistischere Arbeitsweise scheint mir in der Bearbeitung des Dokuments
> Schnittstellenbeschreibung zu liegen, die Schnittstellenübersicht ist ja
> nicht viel mehr als ein erweitertes Inhaltsverzeichnis.

Da haben Sie recht.
 
> "Externe Rahmenbedingungen (Input für SE 1.7 Forderungscontrolling)?
> Mindestens zwei vorher durchgeführte Aktivitäten befassen sich ebenfalls
> mit Rahmenbedingungen:
> · SE1.4 Randbedingungen definieren
> ("Anwenderforderungen.Randbedingungen")
> · PM 1.2 Projektkriterien und Entwicklungsstrategie festlegen
> ("Projekthandbuch.Projektbeschreibung"
> Was für Rahmenbedingungen sind gemeint, die hier nicht bereits durch SE
> 1.4 und PM 1.2 bekannt sind?

SE 1.4 behandelt mehr die technischen und organisatorischen 
Randbedingungen. 
Wenn Sie einmal praktisch überlegen, wann die Aktivität SE 1.7  
ein Sinn gibt, dann kommen Sie zu dem Schluss, dass Sie die 
Anforderungen nur dann reduzieren, wenn Ihr Projektbudget knapp wird. 
Wenn Sie genügt Geld zur Verfügung haben, brauchen Sie kein 
Forderungscontrolling machen. Dann realisieren Sie alles. Aus dieser 
Überlegung schließe ich, dass die externen Rahmenbedingungen in SE 
1.7 hauptsächlicch aus den Grenzen Ihres Projektbudgets bestehen, 
also finanzielle Randbedingungen darstellen. Eigentlich hätte man das 
auch gleich so nennen können.

> Aktivität SE 2.1 System entwerfen
> · Die Aktivität SE 2.1 System entwerfen ist sehr komplex. Durch eine
> Untergliederung in Teilaktivitäten mit jeweils eigenen Produktflüssen
> würden diese erheblich an Informationsgehalt gewinnen, da m. A. die
> Zuordnung der den Zwischenüberschriften nahezu eine 1:1-Beziehung
> zwischen Aktivitäten und Produktabschnitten ergeben:
> SE 2.1.1 Lösungsvorschläge erarbeiten -> SysArc 3.1 Lösungsvorschläge
> SE 2.1.2 Systemarchitektur definieren -> SysArc 2.1.1 Technischer
> Aufbau, SysArc 2.1.2 Schnittstellenidentifikation, SysArc 2.2
> Zusammenarbeit techn. Elemente, SSÜb Schnittstellenübersicht
> SE 2.1.3 Technische Anforderungen -> Tanf Technische Anforderungen
> SE 2.1.4 Betriebsinformationen dokumentieren -> BI Betriebsinformationen

Da haben Sie vollkommen recht. Hier sind die Aktivitäten zu 
komprimiert. Zu diesem Punkt habe ich bereits einen Änderungsantrag 
formieren (siehe www.ansstand.de/Änderungsanträge)
Auf der anderen Seite ist es aber so, dass wenn das V-Modell zuviele 
verschiedene Aktivitäten vorschlägt, dann brechen die Leute wegen der 
Anzahl der vom V-Modell vorgegebenen Aktivitäten zusammen. Insofern 
ist es ein Stück Psychologie oder Kostmetik, wenn soviele Aspekte in 
eine Aktivität zusammengefasst werden. 
 
> Frühes Pflegen der Betriebsinformationen
> Obwohl es immer gut ist, früh zu dokumentieren, scheint mir der Beginn
> des Schreibens der Betriebsinformationen doch sehr früh. Es ist
> anzunehmen, daß sich noch vieles ändert und die Betriebsinformationen
> häufiger überarbeitet werden müssen, als das bei einem späteren Start -
> z.B. parallel zu SE 6- notwendig wäre.

Das haben Sie recht. Gemeint ist jedoch das Sammeln von Informationen 
für die Handbücher. Konkret erstellt und abgeschlossen werden werden 
sie erst ganz zum Schluss in SE 8.3.

Ich hoffe, ich konnet Ihnen etwas helfen.

Klaus Plögert
(V-Modell-Autor und -Berater)

 
*********************************************************
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