Freitag, 24. April 2015

Wer weiß schon, was alles dazu gehört? Von der Lust oder Unlust zur Versionsverwaltung.

Managementaufgaben

Artikelübersicht
1. Teil Managementaufgaben zwischen Fremd- und Selbstverwaltung.
2. Teil Was soll ich zuerst tun? Die Qual der Wahl.
3. Teil Prioritäten verteilen ist eine Kunst.
4. Teil Nur ein Fool wählt gleich ein Tool und ein Plädoyer gegen Monsterprogramme.
5. Teil Wer weiß schon, was alles dazu gehört? Von der Lust oder Unlust zur Versionsverwaltung.
6. Teil Im Dschungel der Nachvollziehbarkeit.
7. Teil Gib Deiner Version einen nachvollziehbaren Namen.
8. Teil Das Erstellen reproduzierbarer Software Releases.


Im Rahmen der Entwicklung erzeugen wir eine Fülle von Artefakten. Unser Hauptaugenmerk sollte auf dem Sinn der Artefakte und deren Umsetzung liegen. Nur wenn sie für das endgültige Produkt und dessen Wartung einen Sinn ergeben, sollten sie in ausreichendem Umfang umgesetzt werden. Der Prozess, in dem diese Artefakte erstellt werden, ist diesem sinnhaften Erzeugen von Artefakten untergeordnet. Der Prozess, den wir benötigen, ist der Weg, auf dem wir am schnellsten zu guten Artefakten kommen. Prozesse um der Prozesse willen steuern ziellos durch den Raum und erzeugen einen Schein von Sinnlosigkeit. Sie fesseln uns an Arbeitsschritte, deren Inhalt uns nicht klar ist. Verliehene Zertifikate für solche kafkaesken Prozesse steigern nur den Unmut der daran Gebundenen und sind oft nur zum Schein für den zu betrügenden Kunden gedacht.

Auch im beschriebenen Objekt-Aufgaben-Modell liegt der Schwerpunkt auf den zu erzeugenden Objekten (Artefakte). Diese sind nur aus Umsetzungsgründen mit zu planenden Aufgaben zu verknüpfen. Die Aufgabe ist die Zeiteinheit, in der das Artefakt erstellt wird. Die Aufgabe wird in Planungsreihenfolge mit anderen Aufgaben gestellt und erzeugt so einen Projektplan.

Im Laufe der Zeit erzeugt auch ein kleines Team eine Vielzahl von Artefakten. Jedes dieser Artefakte durchläuft Änderungen. Eine Anforderung kann mehrfach umgeschrieben, vollkommen verändert oder auch nur einfach gestrichen werden. Dass eine Anforderung über einen langen Zeitraum unverändert bleibt, ist eher die Ausnahme. Normal ist die Änderung. Ein Artefakt kann geändert, gesplittet, zusammengefasst oder gelöscht werden. Trotzdem sollte jederzeit festgestellt werden können, in welchen Zustand es zu welchem Zeitpunkt war. Welche Anforderungen gehörten zur Version 1.3 unserer Anwendung und welche Anforderungen zur Version 1.7? Können Sie das beantworten?

Die meisten Firmen sind durchaus in der Lage, mithilfe von Versionsverwaltungen wie CVS, SVN oder GIT, Aussagen über die Zugehörigkeit von Codedateien zu machen. Eine Java-Quellcodedatei wird in der Versionsverwaltung abgelegt. Sie kann einer Version der Software zugeordnet werden, falls das Setzen eines Tags nicht vergessen wurde. Bei anderen Artefakten ist diese Zuordnung jedoch bereits nicht mehr gegeben. Oft werden zugehörige Libraries beim Erstellen einer Anwendungsversion gesucht, genau wie die Anforderungen für diesen Stand der Software nicht mehr zuzuordnen sind.

Diese Problemlage deutet auf nicht beherrschte Komplexität. Für die Codedateien ist das Vorgehen einsichtig und nachvollziehbar, für die anderen Artefakte, die oft belastendes Beiwerk sind, wird der Sinn geleugnet oder ignoriert. Diese Situation entsteht also, weil man sich durch viele Artefakte gequält fühlt und sie bewusst oder unterbewusst dem Vergessen übergibt. Erzeugen Sie nur Artefakte, deren Sinn Sie anerkennen! Ihre Lebenszeit ist zu wertvoll, als dass man den Stein von einer Seite zur anderen rollen muss und wieder zurück. Müssen Sie sinnlose Artefakte erstellen, hat Ihre Firma noch ein Problem, sie haben anscheinend nicht die Möglichkeit, sich über Sinn oder Unsinn auseinander zu setzen.

Nehmen wir an, Sie haben die Möglichkeit, Ihre Artefakte auf das einzuschränken, was für Sie Sinn ergibt, dann müssen Sie sich immer noch von der Realität überzeugen lassen. In regelmäßig zu wiederholenden Retrospektiven sollten Sie Rückschau auf das Getane halten. Die Welt Ihrer Artefakte wird sich verändern. Und damit auch der Zustand Ihrer Artefaktwelt zu verschiedenen Zeitpunkten. Sorgen Sie dafür, dass sowohl der Metaplan Ihrer Artefakte als auch alle Artefakte versioniert werden. Um den Überblick zu behalten, vor allem aber um das Sinnhafte einzusehen, sollten Sie die Artefakte auf das maximal Sinnvolle reduzieren.

Bei einer Produktentwicklung ist das maximal Sinnvolle nicht der Code. Zu jedem Zeitpunkt müssen die geltenden Anforderungen, die notwendigen Libraries, die auszuliefernden Handbücher und vieles mehr zu ermitteln sein. Zwischen den Artefakten gibt es verschiedene Beziehungen zu betrachten. Im Folgenden versuche ich eine möglichst umfängliche Untersuchung dieser Beziehungen durchzuführen. Stellen wir uns vor, dass wir funktionale Anforderungen in einem System verwalten, welches Versionen managen kann. Günstig wäre, wenn es nur ein System gäbe, welches für diese Versionsverwaltung verantwortlich wäre.

Wir checken eine Anforderung A mit der Version V001 in unser System ein. Zu einem späteren Zeitpunkt erweitern wir die Anforderung A und checken sie mit der Version V002 in das System ein. Beim Einchecken geben wir den Grund der Erweiterung in den Bemerkungen zum Einchecken mit an. Es können und sollten also zusätzliche Informationen zur neuen Version eingetragen werden. Welche Informationen sind später für die Nachvollziehbarkeit der Entscheidung notwendig? [RUPP07] stellt sich folgende Fragen: "Wer hat die neue Version erstellt? Wann wurde die neue Version erstellt? Warum wurde eine neue Version erstellt?" [S.415, RUPP07]

Solange diese Geradlinigkeit der Artefaktentwicklung gegeben ist, können wir das System ohne Weiteres beherrschen. Jedoch unterliegen Anforderungen anderen Änderungserscheinungen. Eine weitere einfach zu beherrschende Änderung ist das Streichen von Teilen der Anforderung und das Umformulieren von Passagen sowie die Ergänzung. In allen diesen Fällen bleibt die Geradlinigkeit der Entwicklung erhalten, auch wenn der neue Zustand mit der Version V003 eingecheckt wird.



Aus zwei Gründen kann eine solche Anforderung verloren gehen. Zum Einen kann sie gelöscht werden. Die Umsetzung der Anforderung ist nicht mehr notwendig. Zum Anderen mutiert die Anforderung mit der Zeit zu einer Mammutanforderung, die dem Prinzip Teile und Herrsche widerspricht. Aus der Anforderung A werden die Anforderungen B, C und D. Sie alle erhalten die Version V004. Eine Version später (V005) geht die Anforderung B verloren, soll also nicht mehr umgesetzt werden, C wird geändert und D verharrt in der Version V004.



Innerhalb dieser versionierten Artefakte müssen wir genau wissen, zu welchem unserer auszuliefernden Systeme ein Artefakt in welcher Version gehört. Dazu setzen wir eine Baseline. "Hiermit bezeichnet man eine spezifizierte und hoffentlich in sich konsistente Menge an Informationen (z.B. Anforderungen, Abnahmekriterien, …) zu einem definierten Zeitpunkt, welche im Rahmen eines Konfigurationsmanagements verwaltet wird." [S.418, RUPP07] Mithilfe der Baseline können wir genau ermitteln, was wir auszuliefern haben. Das setzt natürlich voraus, dass wir alle auszuliefernden Artefakte in der Baseline erfasst haben. Auch der Stand der Anforderungen, die zu diesem System Gültigkeit besitzen, ist so zu ermitteln.



Die Welt der Abhängigkeiten ist jedoch weitaus komplexer, als Versionen von Artefakten und Baselines. Systeme erhalten durch eine Vielzahl von Kunden kundenspezifische Anteile. Die Reduktion solcher Anteile ist Sache der Abstraktion von Systemen. Durch das gewissenhafte Trennen von gemeinsamen Teilen, durch das Bilden von Abstraktionen und durch das Separieren von kundenspezifischen Besonderheiten sollte man diese Unterschiede auf ein Minimum reduzieren. Trotzdem müssen solche Unterschiede verwaltet werden.

Eine zweite Denkrichtung ist die Beziehung zwischen verschiedenen Artefakttypen. Ziele stehen mit User Stories in Beziehung, User Stories können mit Use Cases in Beziehung stehen, Use Cases mit Anforderungen. Diese Kette lässt sich weiter über den Code bis zu den Testfällen spannen. Die Untersuchung dieser Beziehung setzen wir in weiteren Artikeln dieser Reihe fort.

  • [RUPP07] Chris Rupp & SOPHISTen: "Requirements Engineering und – Management", 4. aktualisierte und erweiterte Auflage, Carl Hanser Verlag, München, Wien, 2007


vorheriger Post dieses Themas     folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

1 Kommentar:

  1. Hallo, Herr Baumann,
    vielen Dank für Ihre gut aufbereitete Darstellung! Die Herausforderung ist sehr gut beschrieben und Ihrer Analyse über die gängige Arbeitsweise stimme ich zu.

    Bei der Lösung gehen wir nach vielen Projekten inzwischen nach anderen Maximen vor, wobei an dieser Stelle auf Details verzichtet wird:
    * Dateibasierte Versionierung (genau: 'Historisierung') ist für Anforderungen nicht geeignet. Besser ist eine objektbezogene Historisierung.
    * Das Arbeiten mit Baselines ist sehr mühsam. Hat man eine vergessen, kann man den Stand zu diesem Zeitpunkt nicht mehr reproduzieren. Wir arbeiten (ähnlich wie SVN auf Dateiebene) mit projektweiten Revisions-Nummern auf Objektebene, dann ist jederzeit jeder Stand ohne Baselining reproduzierbar. Und bestimmte Stände können (wieder ähnlich SVN) durch Tag=Revision-Nr markiert werden.
    * Für eine Vernetzung der Daten entlang der Werkzeugkette ohne Kopieren muss jede Revision jedes Objekts eindeutig über Werkzeuggrenzen hinweg adressierbar sein, natürlich am besten per URL.

    .. und so werden manche Dinge, die zuvor ganz schwierig waren, plötzlich handhabbar.

    Viele Grüße,
    Oskar v. Dungern

    AntwortenLöschen