Übernahme von Software

Nicht immer kann eine Software von denselben Personen und Unternehmen über ihre gesamte Lebenszeit betreut werden - oft findet sogar ein Wechsel bereits während der Umsetzungsphase statt. Übernahmen sind bei Software juristisch problematisch und alles andere als einfach oder günstig. Es benötigt viel diesbezügliche Erfahrung, damit es auch möglichst effizient und effektiv umgesetzt wird:

Oft wird hier zwischen freundlicher und feindlicher Übernahme unterschieden, je nachdem ob der bisherige Auftragnehmer die Übernahme involviert wird und sogar aktiv unterstützt oder eben nicht bzw. nichts davon mitbekommen darf, weil befürchtet wird, dass er aktiv gegen die Übernahme arbeiten könnte. Solange nur alle Artefakte (insbesondere Sourcecode und Dokumentation) historisch gesichert werden, ist auch eine feindliche Übernahme bei Software möglich.
→ Der Auftraggeber sollte vor einer Übernahme sicherstellen, dass alle Artefakte der Software (wie auch üblich) in einem Repository gesichert sind und sich das Repository in seinem Einflussbereich befindet (und nicht z.B. durch Änderung von Passwörtern für ihn unerreichbar wird).

Oft wird davon ausgegangen, dass eine Übernahme vor allem genügend verständliche Dokumentation benötigt. Die Erfahrung zeigt aber, dass das nicht der Fall ist: Dokumentation ist in den meisten Fällen veraltet und nicht ausreichend um alleine aus der Dokumentation alle für eine Übernahme notwendigen Fragen zu beantworten. Statt zu versuchen alle möglichen Fragen durch Dokumentation zu beantworten, wird empfohlen 1) die Notwendigkeit für Dokumentation zu reduzieren und 2) sie auf die wichtigsten, nicht aus den Artefakten ableitbaren Informationen zu fokussieren und auch zu testen:

Build & Deployment - die für eine Übernahme wichtigste Information ist, wie die Software gebaut und in Produktion gesetzt wird. Stand der Technik und vom Auftragnehmer unbedingt einzufordern wäre diesbezüglich eine 100% Automatisierung, gepaart mit Continuous Integration und eventuell auch Continuous Delivery. Stand der Technik ist auch, dass diese Automatisierung leicht verständlich ist und sich wie alle anderen Artefakte im Repository befindet. Getestet wird sie ohnedies mit jedem Build und Deployment. → Ist eine Software am Stand der Technik, ist keine Dokumentation für Build und Deployment nötig.✔

Architektur - die fürs technische Verständnis einer Software wichtigste Information ist die Architektur der Software. Welche Bestandteile sie hat und wie diese miteinander interagieren. Stand der Technik ist, dass die Architektur auch im Sourcecode ersichtlich ist: Die einzelnen Bestandteile der Software im Sourcecode klar voneinander getrennt, die internen Schnittstellen klar ersichtlich, die externen Schnittstellen klar mit geeigneten Technologien definiert. Die Abhängigkeiten und Schnittstellen zwischen den Bestandteilen durch sprechende Tests geprüft. All das befindet sich ebenfalls im Repository und wird auch mit jedem Build getestet. → Ist eine Software am Stand der Technik, ist keine Dokumentation für ihre Architektur nötig.✔

Anforderungen - die fürs fachliche Verständnis einer Software wichtigste Information ist die Sammlung der Anforderungen an die Software. Auf Grund inkrementeller Entwicklung und ChangeRequests ist so eine Sammlung meist nicht vorhanden und wenn dann meist veraltet. Eine Software am Stand der Technik besitzt aber (Regressions-)Tests, die alle Anforderungen prüfen - im besten Fall automatisiert. Wurde das (was empfohlen wird) mittels Behavior Driven Development Technologien gemacht, so erkennt man aus diesen die Anforderungen und sie befinden sich im Repository und werden auch mit jedem Build getestet. Wenn nicht, ist sicherzustellen, dass diese Tests nicht nur die Anforderungen vollständig abdecken, sondern dass man aus den Tests auch die Anforderungen erkennt. → Ist eine Software am Stand der Technik, ist keine extra Dokumentation für ihre Anforderungen nötig. Es muss allerdings getestet werden, dass man in den Tests die dahinterliegenden Anforderungen erkennt.

Entscheidungen - die für das allgemeine Verständnis einer Software wichtigste Information ist die Beantwortung der Frage WARUM bestimmte Dinge so und nicht anders entschieden wurden. Das erspart einem das laufende Hinterfragen und neuerliche Prüfen dieser Entscheidungen. Ist eine Software am Stand der Technik, so existieren sogenannte Architectural Decision Records. Aber auch bei nicht-architekturellen Entscheidungen benötigt man für eine erfolgreiche Übernahme die Entscheidungsgrundlagen. → Es wird empfohlen analog zu Architectural Decision Records für alle Entscheidungen zu dokumentieren, warum sie so und nicht anders gefällt wurden.

Fazit: Ist eine Software am Stand der Technik (was man vom bisherigen Auftragnehmer ja auch verlangen und einklagen kann), so ist für eine Übernahme durch Andere bereits ein Großteil der empfohlenen Arbeit getan.