Mail 0590

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

Contents		Title From Date		History Content Links to V-Model

Title

From

Date

History

Content

Hallo Herr Schwager,
 
> - Im Produkt "KM-Plan" wird unter 2.1 von einer Produktbiblithek gesprochen. Werden unter 2.1 
> 	a) nur die Attribute der Produktbibliothek festgelegt, jedoch
> 	   die Produkte (Produktident-Nr + Atrribut-Werte), 
> 	   die unter KM stehen nicht  aufgefuehrt ? Oder
> 	b) Neben den Attributendefinitionen ZUSAETZLICH alle KM-Produkte inkl.
> 	   ihrer Attributwerte aufgelistet.

Hier wird beschrieben, wo und wie die Ergebnisse im Projekt abgelegt werden.
Manche haben hier für ein eigenes KM-Tool (PVCS, ClearCase oder ähnliches) 
manche legen das Ganze aber auch im Filesystem des Projektservers ab. Wenn 
dies der Fall ist, so sollte man hier die geeignete Struktur der Ablage 
(Hierarchiebaum) beschreiben.
 
> - Wenn der Fall b) richtig sein sollte, gibt es dann nicht 
>   eine redundante Aufzaehlung der KM-Produkte
> 	- einmal im KM-Plan und 
> 	- einmal im Projektplan, Kapitel 2.1 "Produktsstruktur Plan" ??

Der Text verwirrt etwas, weil sich 2.1 und 2.2 etwas überschneiden.
2.1 meint die physikalische Art der Verwahrung Ihrer Ergebnisse.

In 2.2 wird beschrieben, 
- welche Ergebnisse (Typen) Sie dort (grundsätzlich) ablegen wollen. 
- welche Rechte die einzelnen Teammitglieder haben (darf jeder alles verändern?)
- welche Zustände Sie verwenden wollen (das V-Modell macht Ihnen da Vorschläge. 
Sie könne aber auch Ihre eigenen Zustände definieren - oder aber gar keine Zustände 
verwenden.

Eine Redundanz zwischen dem KM-Plan und dem Projektplan existiert eigentlich nicht.
Im KM-Plan sagen Sie beispielsweise, dass Sie das Dokument "SW-Architektur" 
grundsätzlich unter KM-Verwaltung nehmen wollen. 
Im Produktstrukturplan des Projektplans benennen alle SW-Architekturen von jeder 
SW-Einheit, die Sie erstellen wollen. 
Haben Sie 5 SW-Einheiten, so taucht im Produktstrukturplan fünf mal das Produkt 
SW-Architektur auf. Hier werden Instanzen festgelegt.

Die Zielrichtung ist eine andere. Der KM-Plan definiert, wie lege ich meine Ergebnisse 
ab und vor allen, was lege grundsätzlich wo ab.
Im Projektplan, speziell Produktstrukturplan sage ich, welche Produkte will ich denn 
erstellen will und welche Dokumente gehören dazu . 
Der Blickwinkel hier ist mehr der Aspekt "welche Produkte muss ich erstellen und 
welche Aktivitäten muss ich durchführen, damit ich zu den Produkten komme".
 
> - Eine Frage zum Projektplan, Kapitel 2.1 "Produktsstruktur Plan":
> 	- Werden hier alle ueber den Projektverlauf 
>  	  identifizierte Produkte (Einheiten, HW/SW-Komponenten, SW-Module) 
> 	  erfasst - d.h. der Projektplan ist bzgl. diesem Kapitel andauernd 
> 	  "InBearbeitung" ?

Das ist richtig. Hier wird dauernd geplant. Dies sieht man auch daran, dass der Produktplan 
am Ende der jeweiligen Feinplanung im Zustand in Bearbeitung bleibt. 
Wenn ich eine neue SW-Einheit oder ein neues Segment identifiziert habe, 
dann trage ich im Produktstrukturplan die jeweils zugehörigen Produkte ein. Dies 
wird auch häufig mit der Bezeichnung "Work Breakdown Structure" bezeichnet. 
Obwohl dieser Begriff auch unterschiedlich interpretiert wird.

> 	- Werden hier auch die V-Modell Dokumente einzeln aufgelistet ?
> 	  (Auch Aktennotitzen, Sachstandsberichte, ....)

Im Produktstrukturplan würde ich das nicht auflisten.
Im KM-Plan definieren sie aber beispielsweise, ob eine Aktiennotiz unter 
KM-Verwaltung kommt oder ob jeder Mitarbeiter diese selbst verwahrt. 
 
>> Fragen ueber Fragen (-: 

Gut, das Ganze ist ja auch  nicht so einfach. 
Sollten Sie jedoch von einigen Texten in den Produktbeschreibungen verwirrt  
werden, so überlegen Sie einfach, was am meisten Sinn gibt. Kleben Sie nicht so 
genau am Buchstaben.

> Ich bedanke mich schon im voraus fuer die Mithilfe an unserem 
> ersten V-Modell Projekt.

Beim ersten mal ist das sicher etwas schwieriger. Bei den nächsten Malen können Sie 
von den Erfahrungen des ersten Projekts profitieren.

Deshalb mein Vorschlag: Machen Sie sich Notizen, was im Projekt (nach V-Modell) gut  
funktioniert hat und was schwierig war. Diese Dinge sollten am Ende des Projekt in 
"Lessons learned" (PM 14) aufgearbeitet werden; zum Nutzen der weiteren Projekte.
So erreichen Sie Synergie von Projekt zu Projekt. Das Ziel ist die IT-Prozesse zu 
vereinfachen und aus Erfahrungen zu lernen und Hilfsmittel und Beispiele zu sammeln.

Viel Erfolg bei Ihrem Projekt.

Klaus Plögert
(V-Modell-Berater)

Links to V-Model

This page online  •  GDPA Online  •  Last Updated 03.Sep.2002 by C. Freericks