Wie bereits angekündigt werden wir Software Lifecycle Management (SLM) ein wenig erörtern und ein paar Tipps zur Einführung geben. Mein Kollege Stefan Heldt hat überzeugend dargestellt, dass sogar innerhalb kürzester Zeit der Verzicht auf SLM zu immensen Mehrkosten führt. Jetzt stellt sich dem aufmerksamen Leser die Frage: Was ist SLM und was gehört alles dazu?
SLM ist ein Prozess zur Überwachung und Steuerung, sowie kontinuierlichen Verbesserung von Software-Produkten. Folgende Aspekte sind in diesem Zusammenhang wichtig:
Disziplin
SLM ist ein lebendiger Prozess, der symbiotisch mit dem Sterben des letzten Software-Produktes in einem Unternehmen zu Ende geht. Wie alle kontinuierlichen Prozesse erfordert auch SLM ein hohes Maß an Disziplin, dass man nicht „mal eben schnell“ etwas macht, damit ein Problem gelöst wird. Alle Problemlösungen sollten wohl konzeptioniert sein und so ist der erste Indikator für schlechtes SLM eine Situation, in der man „schnell“ ein Problem lösen muss.
Software und Praktiken
Fehler machen ist menschlich und aus diesen kann man lernen. Wer kennt diese Weisheit nicht? Doch wann immer es möglich ist, sollte man Fehler im Vorfeld vermeiden. Dazu nutzen wir heutzutage haufenweise Software und Praktiken. Die folgende Aufzählung nur der wichtigsten Dinge ist hoffentlich jedem bekannt, der der Meinung ist, dass er SLM gut umzusetzen vermag.
- Version Control System
Jeder kennt es, jeder nutzt es. Am häufigsten ist es CVS oder SVN. Ein solches System dient dazu, alle Änderungen von Dateien – ich spreche ganz bewusst nicht nur von Quelltexten – zu versionieren. Der Einsatz ist für eine einzelne Person zwar sinnvoll, da man ohne Angst um Verluste arbeiten kann, aber die wahre Kraft wird erst im Team entfaltet. So werden unter anderem Integrität und Datenschutz gewährleistet. - Issue Tracking System
Damit Anliegen – bezogen auf Software zumeist Bugs, Change Requests und Request for Enhancements – verwaltet werden können, verwendet man heutzutage Systeme mit klaren Vorgaben und ausgeklügelten Workflows. - Test Driven Development
Immer wieder bewahrheitet sich, dass konsequentes TDD zur Reduktion von Fehlern führt. Zwar ist es kurzfristig mit Mehraufwand verbunden, aber auf lange Sicht immer lohnenswert. Schreibt man z.B. einen Test für eine Schnittstelle, so kann für jede weitere Version immer wieder sichergestellt werden, dass nichts „kaputt refaktorisiert“ wurde. So werden automatisierte Regressionstests zum Kinderspiel. - Build Management System
Mit diesem Punkt meine ich ein System, das beim Auslesen von Quelltexten ansetzt und alle nötigen Schritte durchführt, um ein fertiges Produkt auf einem Zielsystem (sei es z.B. Test oder Produktion) zu installieren. Nach dem Start sollte nicht ein einziger Handgriff manuell passieren, denn nicht automatisierte Arbeitsschritte sind ein Fehlerpotenzial. Ich habe es erlebt, dass ein Software-Lieferant zwar Build-Skripte bereitstellt, aber keinen Build-Server verwendet und den Aufruf der Skripte sowie die Auswertung und Verarbeitung der Ergebnisse manuell vornimmt. Die Folge sind Mehrkosten und eine hohe Quote an Nachbesserungen. - Software Quality Platform
Eine solche Plattform gibt einen Überblick darüber, wie gut eigentlich die Verarbeitung des Software-Produktes ist. Mit dem quelloffenen Produkt Sonar können viele Metriken ermittelt werden, die Aufschluss darüber geben, ob der momentane Qualitätsstandard erfüllt ist.
Knoff-Hoff
Der schwierigste Teil ist die Aneignung von Wissen und Strategien um die beste Verwendung von Technologien, Software und Praktiken. Als Beispiel sei hier eine Frage in den Raum geworfen: Welche Dateien sollen eigentlich versioniert werden? Ich pflichte demjenigen bei, der Konzeptdateien ebenfalls versionieren möchte. Ein Diagramm ist häufig sehr viel aussagekräftiger als Quelltext, wenn es um ein Gesamtbild geht. In vielen Fällen werden diese Dateien aber in unterschiedlichen Systemen aufbewahrt (häufig werden Daten, die kein Quelltext sind, einfach auf ein Netzlaufwerk abgelegt). Eine Suche nach Informationen ist praktisch vorprogrammiert und Unterschiede zwischen verschiedenen Versionen können nur schwer ermittelt werden.
Aller Anfang ist schwer
Ich hoffe, dass dieser grobe Überblick über SLM hilfreich war, den Sachverhalt etwas besser verstehen zu können. Wer jetzt begierig ist direkt loszulegen, den muss ich leider auf den nächsten Beitrag vertrösten. Dann stellen wir vor, wie man den Anfang in Richtung solides SLM macht.
