Mail 0647

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

Contents		Title From Date		History Content Links to V-Model

Title

From

Date

History

Content

Hallo,

mit großem Interesse habe ich die Diskussion der letzten Zeit (genauer: vor
etwa zwei Wochen) verfolgt. Aus der Sicht eines Praktikers (wir sind ein
Beratungsunternehmen mit den Schwerpunkten Objektorientierung,
Software-Architekturen/MDA, Requirements Engineering und Projektmanagement)
würde ich gerne hinzufügen, was wir unseren Kunden empfehlen. Die sind
meistens in der Rolle des AN oder es handelt sich um Eigenentwicklungen in
Konzernen.

Meine Kommentare beziehen sich auf die Mails #634 ff.
Um keine Reply auf mehrere Mails schreiben zu müssen, habe ich alles in
einer Mail zusammengefasst.

Technische Anforderungen:
Im Fall betrieblicher Informationssysteme will der Kunde ein fachliches
Problem lösen.
Die technischen Anforderungen (SE 3-Spezifikation) interessieren ihn nur so
weit, dass hinterher ein verwendbares System entsteht. Bei den fachlichen
Anforderungen sieht die Sache völlig anders aus, aber die technischen
Anforderungen kann der AG i.d.R. nicht verantworten, außer er macht
dezidierte Vorgaben zur Technik. Dabei spielt es auch keine Rolle, wie lange
man ihm Zeit gibt. Nebenbei bemerkt: Selbst mit der Formulierung präziser
fachlicher Anforderungen haben die meisten AG ein Problem. Wir empfehlen
hier immer ein Verfahren, bei dem Anforderungen nur zusammen mit ihren
Abnahmekriterien (entspricht in etwa einer Prüffallbeschreibung) formuliert
werden dürfen.
Das bedeutet aber nicht, dass die technischen Anforderungen nicht
schriftlich fixiert werden müssen. Wie soll langfristig die Wartung ohne
dokumentierte Anforderungen sichergestellt werden?
Das das der Stand der Praxis ist, ist ja schon schlimm genug.

Papierform der Spezifikation:
Es ist vielleicht formal in Ordnung, einem AG die Spezifikation in
Papierform zu überreichen. Aber arbeiten kann man mit so einem
Pflichten"heft" überhaupt nicht. Das Requirements Engineering sollte in
jedem Fall werkzeuggestützt sein. Dadurch wird zwar der Umfang nicht
geringer. Aber eine vernünftige Organisation (Gliederungskriterien,
Indizierung) lindert dieses Problem in erheblichem Maße. Nebenbei: Auch eine
Ansammlung von Use Case-Beschreibungen wird schnell zum Chaos.

Pflege der Spezifikation:
Auch pflegen läßt sich eine Spezifikation in Form einer Bleiwüste nicht. Sie
bleibt auch nie stabil. Im Gegenteil: Die Technik (IT-Architektur) ändert
sich viel häufiger als die betriebswirtschaftliche Fachlichkeit. Hier hat
die möglichst weitgehende Trenung von Fachlichkeit und Technik während der
Systementwicklung höchste Priorität: Wenn ich die Datenbankaufrufe für einen
bestimmten SQL-Server direkt in die fachlichen Algorithmen einfüge,
erschaffe ich durch Tausende von Wartungspunkten ein Ungeheuer. Moderne
Ansätze wie die Model Driven Architecture können dieses Problem erheblich
reduzieren. Aber an der Pflege der technischen Spezifikation kommt man nicht
vorbei. Möglicherweise handoptimierte Programmquellen zum Zugriff auf
TP-Monitore, Netzwerk, Middleware, Legacy-Systeme etc. versteht man ohne
Dokumentation kaum.

Goldene Türgriffe /YAGNI:
Es enstpricht leider zu oft dem Projektalltag, dass AG "goldene Türgriffe"
wünschen. (Jeder kennt die Anforderung 1: "Das System ist beliebig
erweiterbar") Man erkennt diese Anforderungen häufig schon daran, dass sie
unpräzise und vage formuliert sind ("beliebig", "jeder Art", "vollständig
konfigurierbar"). Es existieren mehrere Verfahren, die man in dieser
Situation einsetzen kann. Am einfachsten: Man schätzt ab, was die
Realisierung dieser Anforderung kosten würde und fragt den AG, ob diesem
Aufwand ein entsprechender ROI gegenübersteht.

Stabilität von Anforderungen:
Das Anforderungen an ein Softwaresystem über seine Einsatzdauer stabil
bleiben, ist eher selten. Gerade bei längerfristigen Projekten ist die
Änderung von Anforderungen auch während der Entwicklung die Regel. Hier ist
ein Verfahren namens Timeboxing zu empfehlen: Zu einem bestimmten Zeitpunkt
werden die Anforderungen für eine Version des Produkts eingefroren. Nach
diesem Zeitpunkt veränderte Anforderungen werden erst im nächsten Release
berücksichtigt.

XP/Agile Methoden:
Trotz einiger be-denkenswerter Aspekte halte ich XP insgesamt für ein
buzzword, welches manchem Consultingunternehmen neue Einnahmequellen
eröffnen soll. Worüber man aber bei der Anwendung jedes Vorgehensmodells
immer nachdenken soll, ist: Macht die Erstellung dieses Dokuments Sinn? Das
Ziel ist doch, Softwaresysteme zu erstellen. Die Erstellung der
Dokumentation ist nur ein Hilfsmittel, um dieses Ziel zu erreichen.
Eine kritische Haltung zum Thema XP/Agile Methoden nimmt auch Matt Stevens
ein:
http://www.softwarereality.com/lifecycle/xp/case_against_xp.jsp

Gruss,

Oliver Linssen
____________________________________________
Oliver Linssen
Geschäftsführer LIANTIS GmbH
Mobil: +49 (0) 163/2469006
http://www.liantis.com

Links to V-Model

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