"Amateure bauten die Arche, Profis bauten die Titanic."
(Unbekannt)

Konstruktionsaspekte

Oft sind in Projekten Hardwarestellungen erforderlich. Dies kann der Fall sein, wenn spezielle Geräte für die Entwicklung erforderlich sind, weil die Software zur Anwendung in diesen Geräten entwickelt wird (sog. Embedded Software = eingebettete Software, sei es bei Handys, bei Steuergeräten in Autos oder auch bei modernen Toastern). Dann sind Hardware-Prüfstände erforderlich, verschiedene Peripheriegeräte, Dummys, etc. Es kann aber auch ganz einfach sein, dass Sie die Software auf einer Messe präsentieren müssen und dafür einheitliche Hardware verwendet werden soll (z.B. alles die gleichen Monitore). Dann muss diese Hardware ggf. zur Installation vorab zur Verfügung gestellt werden. Es kann auch besonders teure Hardware erforderlich sein (Multi-CPU-Cluster), die Sie für kein anderes Projekt mehr benötigen werden. Dann kann man sich mit dem Kunden vielleicht darauf einigen, dass dieser später die Hardware als Testsystem übernimmt oder sich zumindest an den Kosten beteiligt. Manchmal sind zum Testen auch die Originalgeräte erforderlich, um Fehler reproduzieren zu können. Wenn Sie eine Vertriebssoftware entwickeln, die später mit einem Platten-Image auf hunderten von Vertriebsnotebooks installiert wird, sollten Sie auch so ein Notebook für die Entwicklungsdauer und später zum Testen bekommen.

Ein gutes Beispiel aus meiner Vergangenheit war die Entwicklung eines Betriebssystems für eine Speicherschreibmaschine in den 80ern. Die Software wurde in EPROMs gebrannt, in die Platinen im Chassis eingesetzt und über einen ICE (In Circuit Emulator = Hardware-Debugger, der zwischen CPU und Sockel gesteckt wird) getestet. Dieses Equipment war damals mächtig teuer, weil auch originale Intel-Entwicklungsmaschinen zur Ansteuerung des ICE erforderlich waren. Hinzu kamen die teuren Intel-Assembler und -Handbücher. All dies benötigten wir noch Monate nach Projektende in der Wartungsphase, um die Ursachen für Fehler lokalisieren zu können.

Bei Softwarelizenzen kann die Situation noch viel kniffliger sein, weil diese oft nicht verliehen werden dürfen und die vollständige Vernichtung schwer kontrollierbar ist. Manche Entwicklungssysteme arbeiten mit Floating-Lizenzen, die auf zentralen Servern installiert und bei Bedarf an die angemeldeten Clients weitergereicht werden. Dann sind komplizierte Verhandlungen mit den Herstellern abzusehen, zumal diese oft keine zeitlimitierten Lizenzen und auch keine reinen Entwicklungslizenzen zur Verfügung stellen können oder wollen. Bei der Weitergabe der Entwicklung an Unterlieferanten (Subunternehmen) müssen Sie auch beachten, dass die Lizenzrechte oft nicht an Dritte vererbbar sind.

Vorsichtig sollten Sie auch sein, wenn Sie die Entwicklung ganz oder teilweise ins Ausland verlegen und deshalb mit der Hardware oder den Softwarelizenzen über die Grenze müssen - z.B. im Handgepäck ;-) Kritisch kann dies vor allem werden, wenn Sie die EU verlassen, beispielsweise nach Indien oder China. Es gibt manchmal merkwürdige Aussenhandelsbeschränkungen, vor allem bei zentralstaatlichen Regierungen. Im Zweifelsfalle sollten frühzeitig Juristen hinzugezogen werden.

Hardwarestellungen oder Lizenzübergaben sollten immer frühzeitig vereinbart werden, damit es nicht deswegen im bereits fortgeschrittenen und ansonsten eigentlich erfolgreichen Projekt zu Unstimmigkeiten kommt. Eigentlich gehören diese Aspekte als Mitwirkungspflichten des Auftraggebers mit in den Vertrag, werden aber leider oft vergessen. Insbesondere, wenn erst im weiteren Projektverlauf der Bedarf entsteht, wird selten der Vertrag nachgebessert. Meist kommen diese Themen leider erst hoch, wenn zu Beginn der Konstruktionsphase die Entwickler hinzugezogen werden - viel zu spät! Dann sollten zumindest bei der Übergabe des Equipments Inventarlisten ausgefüllt und gegenseitig unterschrieben werden. Insbesondere ist dabei zu klären, ob und wie eine Vergütung gehandhabt wird und wann die Leihstellungen in welcher Form wieder zurückgegeben oder ggf. auch entsorgt werden müssen.

Eine Software ist wie eine Modelleisenbahn - sie wird nie fertig! Es gibt immer wieder Änderungswünsche vom Kunden, Fehlermeldungen von den Anwendern und damit letztendlich immer wieder neue Versionen der Software. Daher sollte man sich spätestens beim Beginn der Konstruktionsphase darüber klar werden, dass man in der Regel noch lange mit dem Ding zu tun haben wird, das man da gerade anfasst - man sollte sich also schnell damit identifizieren können!

Kathedralbau

...

Das "Rush-to-Code"-Syndrom

Höchste Risiken zuerst erledigen

Aktivitätendiagramme

technische Entscheidungen

Jedes Softwareprodukt hat einen Helden, der einen Teil seines Lebens für die Fertigstellung der Software geopfert hat. In unendlich vielen Stunden hat er das Projekt fast von Anfang an bis fast zum bitteren Ende begleitet und stellt die Seele des Quellcodes dar.

Horizontal / Vertikal

Instrumentenflug nach Spezifikation?

Bau der Datenbank
Finden von Datenstrukturen
Erstellen der Objekte
Konzeption von Algorithmen
Mnemonik, Inline-Dok
Erstellen der Testumgebungen
GUI-Verfeinerung

build Feature Teams with own schedule!
Fixed Shipping Date, but target milestones!
Code Complete!