Mail 0373

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

Contents		Title From Date		History Content Links to V-Model

Title

From

Date

History

Content

From:          "Dr. Martin Verlage" 

At 15:32 22.06.99 +0200, you wrote:
>Hallo Herr Maucher!
>
>Sie stellen sehr interessante Fragen, mit denen ich mich auch seit ein paar
> Wochen
>beschäftige.

Die Thesen von Hr Steinman 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 (Textbücher werden üblicher-
weise dafür angewendet, sind aber nicht immer geeigneter).

	Ein Standard sollte immer nur die Schnittstellen zwischen den
Arbeiten verschiedener Personen oder Organisationseinheiten definieren.
Führt eine Person alle Aktivitäten von "Spezifikation" bis "Systemtest"
eigenverantwortlich durch, so ist ein Standard nur sehr defensiv einzu-
setzen.

>Ich stelle hier mal fünf Thesen auf, die die Diskussion vielleicht weiter
>anfachen:
>
>1. Ein verbindlicher Prozeßstandards wie das V-Modell widerspricht modernen
>
>Managementmethoden, ist geradezu das Gegenteil moderner Mitarbeiterführung.
>
>
>Qualitätsbewußtsein ergibt sich aus Qualitätsverantwortung. Den Mitarbeitern die
>Verantwortung für ihr Tun zu geben, ist der Kern modernen Managements. Verantwortung
>setzt Kompetenzen und Freiräume voraus. Ein Prozeßstandard nimmt dem
>Softwareentwickler die Verantwortung für sein Tun ab, weil er keine Kompetenzen mehr
>besitzt. Was er zu tun hat, steht im Prozeßstandard.

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.

>2. Ein Prozeßstandard wirkt demotivierend.
>
>Gute Mitarbeiter werden demotiviert, denn die Message ist: Ihr seid nicht in der Lage,
>selbst zu entscheiden, haltet Euch bitte an den Standard. Zudem ist der Sinn von
>Methodenstandards fraglich, denn so groß und überschaubar ist die Methodenvielfalt
>nicht. Wieso soll nicht jeder Mitarbeiter seine Methode wählen dürfen?

Wenn es nichts ausmacht, so soll der Mitarbeiter entscheiden. Nur
bezweifle ich, daß dies in den meisten Fällen so gegeben ist.

>3. Ein Prozeßstandard hemmt die Kreativität der Softwareentwickler.
>
>Das V-Modell ist wie andere stark auf die eher handwerklichen Aufgaben der
>Softwareentwicklung konzentriert. Durch Dokumentation und durch standardkonformes
>Arbeiten wird aber noch nichts getan. Vor einem müssen Autoren eines Prozeßstandards
>wirklich Angst haben, nämlich davor, daß sich alle genau nach dem Standard richten.
>Dienst nach Vorschrift darf es in der Softwareentwicklung nicht geben.

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.

	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.

>4. Zum Standard kann nur erklärt werden, was schon Standard ist.
>
>Änderungen im Softwareentwicklungsprozeß bedingen Änderungen der Kultur. Ohne den
>nötigen Unterbau siegt die etablierte Kultur über jede Änderung. Zunächst müssen alle
>einzelnen Schritte in einem Unternehmen etabliert werden, ehe ein Prozeßstandard
>erlassen werden kann. In diesem Zusammenhang fällt mir kein vernünftiger Grund dafür ein,
>daß ein Unternehmen einen bestehenden Standard durch das V-Modell ersetzen sollte.

Richitg, 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.

>5. Ein Prozeßstandard wirkt in manchen Unternehmen kontraproduktiv.
>
>Ein Prozeßstandard hilft Unternehmen, deren Wettbewerbsposition durch Kostenvorteile
>zu sichern ist. Diese Unternehmen brauchen einen stabilen Prozeß. In Unternehmen, die
>ihre Wettbewerbsfähigkeit durch Anpassungsfähigkeit und Innovation sichern,  und die
>in Projekten, die neusten Technologien einsetzen, wäre ein stabiler Prozeß eher ein
>Hemmnis. Zudem: Großen Projekten hilft ein Standard als Steuerungsinstrument. Kleine
>Projekte brauchen dieses zusätzliche Steuerungsinstrument nicht.
>
>Zu den Thesen verweise ich auf jedes beliebige Managementlehrbuch jüngeren Datums,
>auf DeMarcos "Wien wartet auf Dich!" auf Veröffentlichungen zum CMM, beispielsweise
>Yourdon oder Wallmüller, und auf aktuelle Artikel im Informatik Spektrum und in der
>Wirtschaftsinformatik.

Hier gebe ich Ihnen auch Recht. In erster Linie hängt die Notwendigkeit des
#Einsatzes von Standards vom Produkt ab. Ist Time-To-Market relevant und die
Zuverlässigkeit uninteressant (siehe manche Web-Produkte), dann stört ein
Standard. Wird ein Produkt in tausend Kopien in Autos eingebaut, dann
würde es mich als Auftraggeber und Auftragnehmer beruhigen, wenn ein
Standard akzeptiert und gelebt wird.

>Sicherlich sind diese Thesen teilweise etwas schwarzweiß gemalt. Dafür sind es Thesen.
>Wichtig ist: Die Unterwerfung des Softwareentwicklungsprozesses eines Unternehmens
>unter einen Standard sollte, wenn dies nicht vom Auftraggeber erzwungen wird, gut
>überlegt werden.

Es stellt sich meist nicht die Frage des "ob", sondern des "wie". Eine
intelligente Nutzung von Standards ist immer hilfreich (und sei es nur
als Quelle der Inspiration). Blinde Vorschriftswut ist kontraproduktiv.

>Dadurch wird das V-Modell nicht sinnlos. Im Gegenteil. Einerseits verschafft es dem
>Auftraggeber notwendigen Einblick und Einfluß. Und dann kann es als Beschreibung eines
>optimalen Prozesses sowohl zur Schwachstellenanalyse als auch zur Leitlinie eines
>kontinuierlichen Verbesserungsprozesses genutzt werden.
>
>Ich bin sehr gespannt auf Reaktionen.
>
>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