mail 0735

Hallo Herr Gnatz,

Sie sind mit dem neuen V-Modell tatsächlich nicht weit weg unserer
Vorgehensweise.

Zu den von Ihnen angesprochenen Punkten:
- Zustandsmodell von Anforderungen: Generell gilt, dass sich bestimmte
Zustände ausdrücken lassen müssen. Beispiele: Ist eine Anforderunge "fertig"
im Sinne des Auftraggebers, Anforderungsstellers oder allgemein
Stakeholders? Ist sie von den Entwicklern akzeptiert i.S.v. "verstanden" und
in die Planung übernommen? Ist eine Anforderung im Sinne der
Abnahmekriterien "richtig" realisiert? Wie die Zustände heißen, ist dabei
egal. Welche Zustände es insgesamt gibt, ist von einer ganzen Reihe von
Faktoren abhängig, die in der Masse im Bereich Organisation (Ablaufo.,
Aufbauo., Rollenmodell, Arbeitsteilung, Einbindung QM etc.) liegen. Auch
wenn die Aussage schwammig ist: Das Zustandsmodell muss zur IT-Abteilung
"passen".

- Abnahmekriterien: Bei den Abnahmekriterien ist nach unserer Ansicht
wichtig, dass sie immer einer Anforderung zugeordnet sind. Wenn ein
Abnahmekriterium nicht erfüllt wird, gilt die zugehörige Anforderung als
nicht erfüllt. Sind alle Abnahmekriterien erfüllt, gilt die zugehörige
Anforderung als erfüllt. Abnahmekriterien ohne Anforderungen machen keinen
Sinn, weil sie nicht gegen eine vom Stakeholder gewollte, geforderte,
verantwortete und bezahlte Anforderung prüfen. Einen separaten Typ
"Prüfspezifikation Lieferung" kennen wir nicht. M.E. ist das eine
Spezialisierung des Typs Abnahmekriterium. Vielleicht teilen Sie meine
Meinung: Mit je weniger Typen man in einem Vorgehensmodell auskommt, desto
besser.
Das ist (auch) nicht agil, sondern schon mindestens seit dem Lean Management
bekannt ;-)

- Gruppierungsmöglichkeiten werden Sie bei jedem größeren Projekt brauchen,
um die Übersicht zu behalten. Das Problem verstärkt sich in dem Maße, je
fein-granularer die Anforderungen sind. Wenn die Anforderungssteller (in
ihrem Kopf) den Zusammenhang zwischen einzelnen Anforderungen nicht mehr
herstellen können und die Übersicht verlieren, hat man ein *sehr großes*
Problem. An dieser Stelle muss man auch stark auf die Denkweise der
Anforderungssteller eingehen. Manche denken prozeßorientiert, manche in
Strukturen.

- Die Anforderungsbewertung (z.B. Kritikalität, Komplexität, Priorität) ist
bei uns konzeptuell eine Reihe von Attributen des Typs Anforderung. Die
"Offenen Fragen" sind etwas anderes und nicht auf die Anforderungsanalyse
beschränkt. Gesetzt den Fall, es besteht Arbeitsteilung zwischen
Modellierern und Implementierern stellt ein Implementierer einem Modellierer
eine Offene Frage, wenn nach seiner Meinung im Modell etwas fehlt oder
widersprüchlich ist und er deshalb nicht arbeiten kann. Dadurch wird ganz
klar der Modellierer ins Obligo gesetzt, Auskunft zu geben, um den Bogen
zurück zu der ursprünglichen Frage von Herrn von Hagen in der Email #728 zu
schlagen. Die Offenen Fragen helfen dabei, dass im Falle der Arbeitsteilung
notwendige Informationen bei allen involvierten Aktivitäten des
Entwicklungsprozesses vorhanden sind und "man sich nichts aus den Fingern
saugen muss". Pragmatisch lindern sie das allen Programmierern bekannte
Problem: "Ich habe eigentlich keine Ahnung was ich tun soll. Aber einen
Termin einhalten soll ich!"

Vielen Dank für Ihre Auskunft, Herr Gnatz. Wir finden den eingeschlagenen
Weg gut und richtig.

Gruß,


Oliver Linssen
______________________________________________________
Geschäftsführer Liantis GmbH & Co. KG
Mobil: +49 (0) 163/2469006
http://www.liantis.com

Free your work. Liantis.


-----Ursprüngliche Nachricht-----
Von: vm-d-l [mailto:vm-d-l@gmx.de]
Gesendet: Dienstag, 23. März 2004 09:15
An: Multiple recipients of V-Modell-Mailingliste
Betreff: Re: Agile Methoden im neuen V-Modell (734)


Hallo Herr Linssen,

soweit ich das sehe, sind wir mit dem neuen V-Modell gar nicht weit weg von
Ihren Vorstellungen.

Wir haben zwar keine Metatypen, sondern nur Typen (aber das ist wohl nur
eine Frage der Bezeichnung), diese gehen aber in die Richtung, die sie sich
vorstellen:

- Anforderungen haben eine definierte Struktur. Ein Zustandsmodell ist dabei
momentan nicht vorgesehen - zumindest keines, dass das V-Modell vorgibt. Das
sollte meines Erachtens nach projektspezifisch sein. Wie sieht das denn bei
Ihnen aus?

- Abnahmekriterien haben wir explizit als Produkt aufgenommen. Ausserdem
gibt es eine "Prüfspezifikation Lieferung" als Produkt, die Vorgaben für die
Abnahmeprüfung auf Seiten des AG macht und eine Produktabhängigkeit zu den
Anforderungen hat.

- Gruppierungen und offene Punkte haben wir nicht als Produkte modelliert.
Dafür gibt es aber die "Anforderungsbewertung" hinsichtlich Machbarkeit,
Finanzierbarkeit, Wichtigkeit, etc.. Diese ist auch kein Ergebnis im engeren
Sinne, sondern entsprechend der "Offenen Punkte"-Liste ein definiertes
Kommunikationsmedium. Das sollte es doch eigentlich tun?

Viele Grüße
 Michael Gnatz


Michael Gnatz
Institut für Informatik
Technische Universität München
Raum 00.11.053, Boltzmannstr. 3, 85748 Garching

Tel. +49 (89) 2 89-1 73 88
Fax. +49 (89) 2 89-1 73 07

mailto:michael.gnatz@in.tum.de

Links to V-Model

not defined

This page online • GDPA Online • Last Updated 16.Nov.2006 by C. Freericks