Mail 0374

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

Contents		Title From Date		History Content Links to V-Model

Title

From

Date

History

Content

Hallo Herr Verlage!

Ich denke wir sind uns in vielen Punkten inhaltlich einig. Sie wollen einen
Standard als Leitlinie, als Orientierunghilfe und als Quelle der
Inspiration eingesetzt wissen. Soweit stimme ich Ihnen voll zu. Wir selbst
sind als Softwarehaus kein Auftragnehmer einer Bundesbehörde und wir nutzen
das V-Modell genauso, wie Sie es vorschlagen. Ich lese jedoch aus
existierenden Standards auch aus dem V-Modell einen anderen, viel
weitergehenden Anspruch.

> Die Thesen von Hr Steinmann beruhen zum Teil auf einer Interpretation,
die
> nicht ganz im Sinne der Entwickler von (modernen) Standards ist. Seine
> ersten drei Thesen implizieren, daß ein Standard so benutzt wird, daß er
> den Entwicklern vorschreibt, was sie zu tun haben. Dies ist meiner Auf-
> fassung nach nicht das Ziel von Standards.
>    Ein Standard sollte immer nur die Schnittstellen zwischen den
> Arbeiten verschiedener Personen oder Organisationseinheiten definieren.

Das V-Modell gilt, wenn ich das richtig verstanden habe, als verbindlicher
Entwicklungsstandard für IT-Systeme des Bundes. Verbindlich sind dabei die
Beschreibungen der Aktivitäten, und die Aktivitätenbeschreibungen legen
sehr weitgehend und sehr genau fest, was Entwickler zu tun haben. Für eine
Schnittstellendefinition wären eher die Produktmuster und das Rollenkonzept
als verbindlich zu erklären.

Wird das V-Modell als Vertragsgrundlage zugrundegelegt, dann ist gegenüber
dem Auftraggeber zumindest eine V-Modell konforme Sicht zu verschaffen.
Intern kann man dann vielleicht auch arbeiten, ohne sich an das V-Modell zu
klammern, aber es besteht dann das Problem, die V-Modell konforme Sicht
aufrechtzuerhalten.

> Qualität in einem Projekt mit 100 Entwicklern kann nicht dadurch er-
> reicht werden, daß jeder um Qualität bemüht ist. Ingenieurmäßige
> Softwareentwicklung bedarf bestimmter Prinzipien. Bei der Programmierung
> ist dies z.B. die Strukturierte Programmierung (wer akzeptiert
> heute noch GOTOs?). Bei der SE ist dies die Unterteilung in Schritte,
> die verschiedene Ziele haben (Anforderungen, Entwurf, Code, usw.).
> Innerhalb des definierten Rahmens existiert dann ein Freiraum.

Jede Softwareentwicklung bedarf bestimmter Prinzipien. Die
Softwareentwickler müssen die aktuellen Methoden kennen und wissen, wie man
diese einsetzt. Softwareentwickler müssen auch wissen, daß jemand darauf
achtet, ob sie die Methoden auch wirklich einsetzen. Ein Prozeßstandard wie
das V-Modell ist aber doch etwas viel weitergehendes. Ein Prozeßstandard
setzt erst auf einem bestehenden Methodenfundament auf und erzwingt in
allen Projekten das gleiche Vorgehen. Ich bin ja nicht gegen methodisches
Arbeiten, sondern ich stelle den Sinn von Standards an dieser Stelle in
Frage.

Unbenommen bleibt der Punkt, daß in es Projekten mit 100 Entwicklern
notwendig ist, ein gemeinsames Vorgehen zu vereinbaren. Aber dennoch gilt
auch in großen Projekten: Ein Standard schafft keine Qualität, Qualität
folgt aus methodischer Arbeit und Qualitätsverantwortung.

> Hier würde ich gerne einen Vergleich zum Führerschein ziehen. Sicher-
> lich ist das Autofahren "standard-konform". Auch kommt niemand durch
> Lesen und Anwenden der Regeln von A nach B. Sicherlich sind Tempo-
> sünden an der Tagesordnung, aber im Großen und Ganzen funktioniert
> es. Ich möchte hier nicht mit mehr Kreativität leben.
Der Vergleich zum Straßenverkehr wird häufig gezogen. Meiner Ansicht nach,
ist dieser Vergleich aber grundsätzlich falsch. Zum Autofahren brauche ich
einen Satz von Regeln, ich muß einige Methoden erlernen und wissen, wie ich
sie anwende. Ok. Ich kann dann aber Autofahren, indem ich das Gelernte stur
anwende. Autofahren funktioniert am besten, wenn alle "Dienst nach
Vorschrift" machen. Zum Autofahren ist Kreativität schädlich. Aber das hat
doch nichts mit Softwareentwicklung zu tun!

>    Das Analogon mit den Straßenverkehrregeln illustirert noch
> eine andere Seite von Standards: Regeln werden im Straßenverkehr
> so aufgestellt, daß auch noch der schwächste Teilnehmer
> sicher die Straße befahren kann (deswegen stehen vor vielen Kurven
> Tempo 70-Schilder, für Autofahrer manchmal etwas überflüssig, aber
> für Motorradfahrer bei naßer Fahrbahn überlebenswichtig). Genauso
> definiert ein Standard, daß der Durchschnittsentwickler noch gute
> Software produzieren kann. Daß es manchmal schneller geht, wenn man
> den richtigen Drive hat steht außer Frage.

Ein Standard kann für Mitarbeiter eine gute Hilfestellung sein, an der sich
jeder bei Bedarf orientieren kann. Mache ich aber diese Regeln zum
Standard, mache ich alle Entwickler gleich. Und dies ist eben gerade bei
geistig kreativer Arbeit kontraproduktiv. Warum soll ich, wenn ich
schwächeren helfe, die anderen demotivieren? Ein
Softwareentwicklungsprojekt ist keine Ralleystrecke. Es wird niemand
überfahren. Der Projektleiter kann hier seinen "schwächeren" Mitarbeitern
den Standard vorgeben, sollte dies bei anderen aber tunlichst unterlassen.
Ein verbindlicher Standard richtet unnötig Schaden an.
> Richtig, man kann STandards nicht über die Mauer in ein Unternehmen
> werfen. Standards stellen aber auch einen guten Weg dar, um von anderen
> zu lernen. Hier kann das V-Modell als Referenzwerk dienen, um einen
> Vergleich mit existierenden Standards zu ermöglichen. Gründe, das
> V-Modell zu benutzen sind zum Beispiel sein gutes Verfahren zum
> Tailoring, die Definition von Rollen (auch wenn viele Unternehmen den
> Sinn och nicht verstehen) oder die Vollständigkeit der Aktivitäten.
Auch hier sind wir einer Meinung. Wenn ich das V-Modell als Referenzwerk
verwende, mache ich es nicht zum verbindlichen Standard. Viele Unternehmen
gehen jedoch diesen Schritt, gerade auch in Hinblick auf Zertifizierungen.
Die Bundesbehörden müssen ihn sogar gehen. Das Modell wird oft genug weder
sorgfältig eingeführt, noch überhaupt auf seine Eignung im Unternehmen
überprüft. DeMarco schreibt: ?Für uns klingt das nach gesundem
Hausverstand, aber es weicht von den weitverbreiteten Vorstellungen in der
Industrie ab, daß man neue Ansätze finden soll und diese als Standard
festschreiben, bevor irgend jemand in der Firma sie ausprobiert hat."

Für mich steht somit der Nutzen verbindlicher Prozeßstandards aus Sicht
eines Softwarehauses oder Auftragnehmers weiterhin in Frage. Mich würden
weitere Meinungen und Erfahrungen sehr interessieren!

Mit freundlichen Grüßen
Christian Steinmann

-----------------------------------------
Dr. Christian Steinmann
GIS GmbH
Qualitätsmanagement
Friedrich-Ebert-Anlage 2-14
60325 Frankfurt am Main
Tel: 069 / 75690-205
E-Mail: Christian.Steinmann@GIS-online.de

Links to V-Model

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