Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03630.jsonl.gz/1823

Projektmanagement
Hartwig Thomas, 19. Mai 1997
Vorgehen EDV-Projekte (allgemeine Empfehlungen)
Wir werden immer wieder gebeten, Projekte von anderen zu begutachten.
Wir empfehlen jeweils ein einfaches und nützliches Vorgehen, das die
Wahrscheinlichkeit der erfolgreichen Projektdurchführung stark verbessert.
Wir arbeiten selber gerne für Projektleiter, die sich an diese
Empfehlungen halten. Die Empfehlungen sind keine weltbewegenden Neuheiten,
sondern etabliertes "Software-Engineering", das sich für
uns in der Praxis bestätigt hat.
- Möglichst kleiner Projektumfang
Es ist äusserst gefährlich, ein "umfassendes" EDV-Projekt
durchzuführen, das viele Bestandteile hat und dessen Entwicklung lange dauert.
Ein "gesundes" EDV-Projekt sollte in wenigen Monaten realisiert sein.
Oft lassen sich grosse Projekte in eine Folge von eigenständigen kleinen
Teilprojekten zerlegen, die einen Sinn haben, selbst wenn das gesamte Projekt nicht
in der ursprünglich geplanten Form realisiert wird.
- Überprüfbare, vollständige Anforderungen
Die allermeisten EDV-Projekte scheitern daran, dass den Entwicklern die
Anforderungen nicht bekannt sind. Sobald ein Programm neben dem Entwickler
auch nur einen weiteren Benutzer hat, müssen die Anforderungen schriftlich
festgehalten werden, bevor die Entwicklung anfängt. Zu den Anforderungen
gehören das technische (und ökonomische) Umfeld, die Reaktionsgeschwindigkeiten
der Software, Kernfunktionalitäten, Sicherheitsanforderungen, etc.
Anforderungen müssen in der Benutzersprache verfasst sein. Sie dürfen
kein Computerchinesisch enthalten, das der Auftraggeber nicht versteht.
- Überprüfbare, vollständige Spezifikationen
Basierend auf den Anforderungen sind die Spezifikationen des zu entwickelnden
Systems von den Entwicklern zu erarbeiten. Diese beinhalten die Wahl der
Entwicklungsumgebung, genaue Darstellung der Datenflüsse, genauer Design
der Benutzeroberfläche, Strukturierung der Datenbank, etc.
Diese Spezifikationen dürfen zwar in einer etwas technischen Sprache
abgefasst sein, sollten aber möglichst wenige Implementationsentscheide
vorwegnehmen. Die Projektleitung darf keine Zweifel haben, wie das System aussehen
wird, wenn es gemäss den Spezifikationen entwickelt ist. Die Spezifikationen
müssen in den entscheidenden Punkten genügend konkret und genau sein,
dass das Endprodukt daraufhin geprüft werden kann, ob es die Spezifikationen
erfüllt.
- Aufwandschätzungen durch Entwickler
Es ist bei vielen Softwarefirmen üblich, dass Aufwände und Preise von
Verkäufern mit den Kunden "ausgehandelt" werden. Die Frage, wie
gross der zeitliche Aufwand (Arbeitsstunden und verflossene Zeit sind separat zu beziffern)
ist, kann nicht Gegenstand von Verhandlungen sein. Die Erfahrung zeigt, dass
Entwickler diese Aufwände relativ realistisch einschätzen, bevor sie
von Managern (oder Kunden) "heruntergehandelt" werden. Der einzige Punkt,
wo ein Verhandlungsspielraum besteht, ist der Preis pro Arbeitsstunde, nicht aber
die Anzahl Arbeitsstunden.
- Meilensteine zur Überprüfbarkeit des Fortschritts
Auch Entwickler machen manchmal trotzdem Schätzfehler - je unerfahrener sie
sind, desto häufiger. Um diese möglichst früh zu entdecken und
damit die Projektleitung einen guten Einblick in den Fortschritt der Entwicklung hat,
empfiehlt es sich, überprüfbare Zwischenstationen ("Meilensteine")
der Entwicklung zu definieren. Von der Erreichung solcher Meilensteine sollten
allfällige Zahlungen abhängig gemacht werden. Wenn die zeitliche Planung
eines Meilensteins stark von der Realität abzuweichen droht, sind von der
Projektleitung Massnahmen ins Auge zu fassen.
- Unabhängigkeit vom ursprünglichen Hersteller
Der Auftraggeber sollte im allgemeinen eine minimale Unabhängigkeit vom
ursprünglichen Hersteller sicherstellen. Das heisst, dass er auf der Übergabe
des vollständigen Quellcodes und auf Entwicklerdokumentation bestehen sollte,
die es einem anderen Entwickler ermöglichen, die Anwendung weiterzuentwickeln.
Im Allgemeinen ist es für den Auftraggeber trotzdem lohnend, allfällige
Weiterentwicklungen wieder beim ursprünglichen Hersteller zu bestellen,
da in diesem Fall beträchtlicher Einarbeitungsaufwand wegfällt.
Sollte der ursprüngliche Entwickler aber nicht mehr greifbar sein oder sollte sich
die Beziehung zu diesem sehr stark verschlechtert haben, ist der Zugriff auf den
Quellcode für den Auftraggeber wenigstens ein minimaler Investitionsschutz.
Die Forderung nach Offenlegung des Quellcodes gilt natürlich nicht für
"Standardsoftware", die in grossen Mengen zu kleinen Preisen gehandelt wird.
Als Alternative zur Übergabe des Quellcodes an den Auftraggeber kann auch eine
Hinterlegung an einem sicheren Ort vereinbart werden, zusammen mit einer Regelung,
in welchen Fällen der Auftraggeber darauf zugreifen kann.
- Abnahme, Überprüfung der Resultate
Die Entwicklung einer Software ist ein "Werkauftrag". Um zu beurteilen,
ob die Arbeit ihren Preis wert war, ist es entscheidend, dass das Produkt mit den
Spezifikationen verglichen wird. Abweichungen von den Spezifikationen haben entweder
Preisreduktionen oder Nachbesserungspflichten zur Folge.
Für Punkte 2., 3. und 7. empfiehlt es sich eventuell, eine unabhängige
zweite Beurteilungsinstanz mit EDV-Erfahrung beizuziehen.
Dieses Vorgehen ist selbst dann empfehlenswert, wenn es sich um eine kleine
Entwicklung handelt, bzw. wenn die Entwicklung intern durchgeführt wird und
keinen "offiziellen" Projektstatus hat. Es hat sich bei einer Unzahl von
EDV-Projekten bewährt, da es Zeit- und Budgetüberschreitungen weitgehend
vermeiden hilft, bzw. wenigstens die Kostenfolgen einer solchen negativen Entwicklung
vom Kunden weg auf die Entwickler verschiebt.
E-mail an Hartwig Thomas