"Wenn es ein Geheimnis eines Erfolges gibt, so ist es das:
den Standpunkt des anderen zu verstehen und die Dinge mit seinen Augen zu betrachten."
(Henry Ford)

Lieferung

Von einem "Launch" ("Start") spricht man eher bei einem kommerziellen Produkt (so richtig mit Handbuch im Vierfarbkarton), das in Stückzahlen hergestellt und über Distributionskanäle verkauft wird. In dem Moment, wo die Auslieferung des Produkts beginnt, spricht man auch von "Shipping" (Lieferung). Es gab mal einen sehr interessanten Vortrag auf einem der ersten Microsoft TechTalks von dem Produktmanager von Excel 3; er nannte den Vortrag "Shipping Software", weil er dies als Hauptziel einer jeden Softwareentwicklung betrachtete und damit den Entwicklern klar machen wollte, dass eben nicht die Entwicklung selbst das Wesentliche ist, sondern das Produkt, das am Ende steht! Eine weitere Bezeichnung für die Auslieferung der fertigen Software ist "Roll Out". Diese ist der Luftfahrtindustrie entnommen; dort wird das erstmalige Herausrollen des Flugzeugs aus dem Hanger nach der Fertigstellung so bezeichnet. Ich persönlich finde diesen Begriff allerdings für neue Netzwerkverkabelungen viel passender als für Software, denn Netze werden ja auch ausgerollt.

Bei Individualsoftware (also kundenspezifischer Software, engl.: Custom Software) erfolgt die Lieferung der Software bei iterativ inkrementeller Vorgehensweise in der Regel mehrfach parallel zur Entwicklung, und sei es nur zur Sichtung in einem Testlabor. Es werden also Builds aus den Iterationen gezogen, indem die Entwickler ihre Änderungen lokal testen, in das zentrale Versionierungssystem einspielen und daraus einen neuen Gesamtstand generieren, der alle lokal getesteten Änderungen enthält.

Dieser Stand wird sicherlich auf eine CD gebrannt (engl.: burning); ich lasse in dem Projekt, das ich zurzeit leite, stets drei von diesen CDs brennen. Alle drei CDs werden dann zunächst auf einem neutralen System auf Lesbarkeit getestet und mit der Build-Nummer und dem Brenndatum beschriftet. Die erste wird zur Installation auf einem Referenzsystem in unserem Haus verwendet, auf dem die Software vor der Auslieferung einem Gesamttest unterzogen wird. Diese CD geht danach in unseren Safe, damit wir später nachvollziehen können, was alles das Haus verlassen hat. Die zweite CD verwenden wir in der Fachabteilung des Kunden zur Installation auf dem System des Testlabors. Diese CD verbleibt auch in der Fachabteilung und erst nach der Freigabe durch die Fachabteilung erfolgt mit der dritten CD die Installation mit den Administratoren der IT-Abteilung auf dem Echtsystem. Die dritte CD verbleibt dann bei den Administratoren, damit diese bei neuen Maschinen oder nach Plattendefekten jederzeit neu installieren können.

Diese Installationen erfolgen natürlich nach genauer Planung und Terminabsprache sowie Ankündigung an die Anwender. Spätestens bei der Installation auf dem Echtsystem ist schließlich der laufende Betrieb betroffen, so dass die Anwender diese geplante Down-Time kennen müssen. Idealerweise liegt diese natürlich außerhalb der normalen Arbeitszeiten, was aber spätestens bei international genutzten Internet-Applikationen mit 7x24-Betrieb nicht mehr möglich ist.

Bei dieser Arbeitsweise sollte es in der Projektmappe Dokumente geben, die dieses Prozedere beschreiben und als Checkliste beim Erstellen und Brennen eines Builds eingesetzt werden können. Darin sollte genau stehen, wo die Dateien zum Brennen gesammelt werden, wie die CDs beschriftet werden, wie sie auf Lesbarkeit getestet werden und wer welche CD wann wofür verwendet. Kurzum: Prozesse, Zuständigkeiten und Verantwortungen müssen verbindlich (d.h. schriftlich) definiert werden. Natürlich sollten diese Dokumente dann auch genutzt und peinlich genau befolgt werden!

Ich halte es für absolut erforderlich und selbstverständlich, dass es in der Entwicklungsabteilung für Tests ein neutrales System gibt, dass beim Kunden eine Testlandschaft existiert und das diese Systeme auch intensiv genutzt werden, bevor auf dem Echtsystem ausgeliefert wird. Um so erstaunter bin ich immer wieder, dass es in den meisten Projekten noch immer die Regel ist, dass ein Entwickler auf seinem lokalen System eine CD brennt, die dann direkt ins Echtsystem wandert. Ich kenne auch größere Projekte, bei denen die Entwickler sogar von ihrem Arbeitsplatz aus remote (dt.: ferngesteuert) direkt auf das Echtsystem des Kunden liefern - sogar ohne dass die Administratoren des Kunden davon erfahren. Ich frage mich dann immer, wer da eigentlich die Verantwortung für den Betrieb der Software beim Kunden trägt und wie sich so etwas - meist schleichend und ohne die Kenntnisse des Managements - etablieren kann und alle die Augen in der Hoffnung zu machen, dass schon nichts passieren wird. Mit Bezug auf den Spruch dieser Seite kann ich nur erneut betonen, dass die Installation auf dem Echtsystem natürlich immer nur durch die Administratoren des Kunden erfolgt - aber genauso natürlich das Softwarehaus dabei Unterstützung liefert. Diese Sitzungen stellen in der Regel auch den intensivsten technischen Kontakt zwischen Kunde und Lieferant dar.

Die Lieferung und Installation einer neuen Programmversion sollte protokolliert und ggf. durch Lieferscheine oder Abnahmedokumente unterstützt werden, damit diese Schritte auch später noch nachvollziehbar sind. Das genaue Vorgehen sollte am Projektanfang zwischen Kunde und Lieferant im Projektvertrag vereinbart werden.

Bei großen Projekten kann es durchaus eigene Teams geben, die nur für das Einsammeln der Änderungen und das Erstellen eines neuen Builds oder das Brennen und Verteilen der CDs oder das "Pflanzen auf dem Feld" zuständig sind [B21]. Diese Prozesse können dann auch schnell so komplex und zeitaufwändig werden, dass dafür eine Projektleitungsassistenz oder gar ein Teilprojektleiter oder gar ein eigenes Steuerungsteam erforderlich wird. Dies alles muss zu Projektanfang bei der Erstellung des Rollenprofils und der Einsatzplanung der Mitarbeiter berücksichtigt werden.

Und wenn was gar nicht will, dann muss es halt entweder abgeklemmt werden, oder das Messehäschen im Kino, das die Software vorführt, muss nach der Installation noch eben schnell über die dos und don'ts informiert werden. Beim ersten Mal hat da jeder Entwickler und Produktmanager ein flaues Gefühl, aber meiner Erfahrung nach eher zu Unrecht: Manchmal studieren diese Damen sogar an Eliteunis Internationale Wirtschaft, sprechen mehrere Sprachen (sehen meistens auch noch gut aus) und suchen auf der Messe den Kontakt zu führenden Unternehmen der Branche. Die sind so clever, denen brauchen Sie nur einmal zu zeigen, wie die Software angefasst werden soll und die Messe ist gerettet!

In solchen Momenten lernt man durchaus, dass Software nicht immer gut, sondern nur für den jeweiligen Zweck gut genug sein muss - jedenfalls längst nicht immer fehlerfrei! Sehen Sie dies einfach als weitere Antwort auf meine Frage "Warum testen?"

...

Inbetriebnahme / Einführung
- direkte Umstellung
- Parallellauf
- Versuchslauf
- Pilotinstallation

Availability Management

Konfigurationsmanagement

Datenmigration

Konkurrierende Teams - z.B. in Indien; Einhalten von Termin ist dann besonders wichtig; Bezug auf Spruch der Kapiteleinführungsseite