In den letzten beiden Monaten haben wir den Fahnder vorgestellt, der nach Architektur- oder Codesünden und ähnlichen Missetaten in bestehenden Systemen sucht. Die Fahnder suchten in den letzten Folgen nach technischen Schulden, Risiken und anderen Sünden, und zwar durch Opfer- und Zeugenvernehmung sowie Bestandsaufnahmen im Code und der Dokumentation. Sie überprüften ihre Funde durch Kreuzverhöre und schlugen für die wirklichen Sünden im Code Maßnahmen vor. Im dritten Teil diskutieren wir, wie Fahnder mit den Ergebnissen ihrer Arbeit umgehen sollten.

Was geschieht mit den Fahndungsergebnissen?

Sie haben als Softwarefahnder unter Umständen eine Menge an Indizien aufgespürt, Aussagen erhalten und Beweise aufgesammelt. Im Fernsehkrimi bringen Sie alles zurück ins Kommissariat zu der großen Wandtafel. Dort heften sie diese Fakten einfach an und bringen Sie grafisch mit Strichen in Verbindung (in der Hoffnung, dass die SOKO dann anhand dieses Überblicks weitere Schritte und Maßnahmen beschließen kann, die zur Aufklärung des Verbrechens führen).

Während Sie als Fahnder noch nach Ursachen und Zusammenhängen suchen, können Sie für erkannte Softwaresünden ebenso ein semantisches Netz bzw. eine Concept-Map aufbauen, wofür es einige (teils kostenfreie) Tools gibt. Ordnen Sie identifizierte Risikobereiche, anfällige Codeteile, Bausteine mit zu harten Abhängigkeiten im Überblick an und diskutieren Sie daran die dringendsten Maßnahmen.

Langfristig besser: Der Standardarchitekturschrank – lose gefüllt

Nach erfolgreicher Klärung eines Falls bleibt auch den Fahndern im Krimi nichts erspart: Sie müssen einen sauberen Abschlussbericht vorlegen, damit sie selbst, aber auch Kollegen aus anderen Kommissariaten geordnet darauf zugreifen können. Das macht meistens weniger Spaß als die eigentliche Fahndungsarbeit, gehört bei nachhaltig angelegter Entwicklungsarbeit aber dazu – auch für Softwarefahnder. Im Grunde ist das einfach und schmerzfrei:

Stellen Sie sich einmal kurz vor, Sie müssen nicht auf der grünen Wiese mit der Dokumentation Ihrer Architektur beginnen, sondern Sie hätten eine halbwegs ordentliche Dokumentation des zu modifizierenden Systems. Dann könnten Sie alle Erkenntnisse über Risiken und Schwachstellen natürlich als Annotationen an die richtige Stelle dieser Doku anhängen. In der Projektrealität ist eine solche Doku über Altsysteme jedoch (noch) relativ selten. Trotzdem hilft uns diese Vorstellung einer idealen Doku weiter.

Wir haben Ihnen in der ersten und zweiten...