Blog-Serie – Teil 4 von 6
In diesem Blogbeitrag möchten wir Ihnen zeigen wie Baselines und Branches bei der Zusammenarbeit mehrerer Autorinnen und Autoren helfen können.
Haben Sie schon die anderen Teile der Blog-Serie gelesen?
Im ersten Blogbeitrag haben wir folgende Erkenntnisse gewonnen:
Innerhalb einer Anforderungsspezifikation ist es gar nicht so leicht, zu erkennen, welche Stände der Anforderungen innerhalb einer Anforderungsspezifikation für die Freigabe relevant sind. Bei der Zusammenarbeit mehrerer Autor*innen an einer Anforderungsspezifikation ist Abstimmungsbedarf nötig, um die Anforderungsspezifikation konsistent zu halten und eine Freigabe der Anforderungsspezifikation erwirken zu können
Im zweiten Blogbeitrag haben wir Ihnen gezeigt, wie Statusmodelle bei der Lösung der Probleme helfen können.
Im dritten Blogbeitrag sind wir auf Systemverantwortliche als koordinative Stelle zwischen Anforderungsautoren eingegangen.
Nun aber zurück zum vierten Teil:
Was sind überhaupt Baselines und Branches?
Baseline (deutsch: Basislinie):
Eine Basislinie ist ein kohärentes Set an Anforderungen, welches jede Anforderung nur in einer Version beinhaltet und zusätzlich für die Weiterentwicklung in anderen Disziplinen (z.B. Design, Umsetzung, Testmanagement) genutzt werden soll. Zudem ist eine Basislinie unveränderlich. Ändert sich eine Anforderung, so muss die Anforderungsautorin oder der Anforderungsautor eine neue Basislinie erzeugen, um die geänderte Anforderung an weitere Entwicklungsdisziplinen weiterzugeben. Somit ist es möglich zu verschiedenen Zeitpunkten einen stabilen Stand an Anforderungen zu identifizieren.
Branch (deutsch: Zweig):
Ein Branch ist technisch gesehen eine Kopie einer Anforderungsspezifikation. Falls mehrere Autorinnen und Autoren an einer Anforderungsspezifikation arbeiten, kann jede Autorin und jeder Autor jeweils einen Branch nutzen, um ihre*seine Anforderungen unabhängig voneinander weiterzuentwickeln. Die Autorinnen und Autoren können mit einem Branch von der originalen Anforderungsspezifikation (auch Mainline genannt) abzweigen. Ein Branch kann einem Arbeitsstand entsprechen. Hat eine Autorin oder ein Autor die Arbeit im Branch beendet, so können Änderungen, die im Branch vorgenommen wurden, zurück in die Mainline eingespielt werden. Die Mainline entspräche dann dem freigegebenen Stand. Abbildung 1 zeigt das Arbeiten mit Branches:
Abbildung 1
Wir beginnen in t1 mit der Mainline, die zwei Anforderungen enthält. In Schritt werden die Anforderungen aus der Mainline in Branch 1 ausgeleitet. Im zweiten Schritt verändert eine Anforderungsautorin oder ein Anforderungsautor die Anforderung1. Währenddessen leitet eine andere Anforderungsautorin oder ein anderer Anforderungsautor die Anforderungen in einen zweiten Branch aus (Schritt 3). Die beiden Anforderungsautorinnen oder Anforderungsautoren können bis hierhin unabhängig voneinander an der Anforderungsspezifikation arbeiten. In Schritt 5 kommen wir an einen kritischen Punkt, denn Branch 1 soll nun in die Mainline zurückgespielt werden (auch Merge genannt). Das Zurückspielen muss eine bewusste Entscheidung sein. An diesem Punkt muss eine Person entscheiden, ob der Merge eingespielt werden soll oder nicht. Dazu ist eine Person (z.B. der oder die Systemverantwortliche) im Unternehmen nötig, die die Macht und das Wissen hat, zu entscheiden und zu verantworten, dass die einzuspielenden Änderungen nicht zu Konflikten in der Anforderungsspezifikation führen. In Schritt 6 möchten wir einen solchen Konflikt aufzeigen. Nun möchte eine andere Anforderungsautorin oder ein Anforderungsautor den Branch 2 in die Mainline einspielen, der genauso wie Branch 1 die erste Anforderung verändert. Hier nehmen wir jetzt an, dass eine Systemverantwortliche oder ein Systemverantwortlicher diesen Merge nicht durchführt, weil die Anforderung1 in Version 2a weiterhin erhalten bleiben soll. Ein professionelles RM-Tool bietet Hilfestellung bei dem Vergleich von Mainline und Branch.
Das dargestellte Szenario ist nur ein Szenario für die Arbeit mit Branches. Weitere Szenarien werden wir in der dedizierten Blogbeiträgen darstellen.
Vorteile:
Problem 1: Innerhalb einer Anforderungsspezifikation ist gar nicht so leicht zu erkennen, welche Stände der Anforderungen innerhalb einer Anforderungsspezifikation für die Freigabe relevant sind.
Theoretisch sind Baselines das Konstrukt, um Anforderungen zu kapseln, die zu einem Weiterentwicklung genutzt werden sollen. Baselines bringen den Nachweis, dass ein Set von Anforderungen zu einem bestimmten Zeitpunkt für die Umsetzung bestimmt ist. Professionelle RM-Tools bringen für die Erstellung einer Baseline in der Regel einen Mechanismus mit.
Problem 2: Bei der Zusammenarbeit mehrerer Autoren an einer Anforderungsspezifikation ist Abstimmungsbedarf nötig, um die Anforderungsspezifikation konsistent zu halten und eine Freigabe erwirken zu können.
Sowohl die Mainline als auch die Branches sind eigene Items, die miteinander verglichen werden können. Typischerweise bringen professionelle RM-Tools Mechanismen mit, um Unterschiede zwischen der Mainline und einem Branch sichtbar zu machen und Änderungen aus dem Branch in die Mainline zu übernehmen. Daraus ergibt sich die Chance Änderungen zu koordinieren. Die Koordination selbst muss jedoch eine Person übernehmen (z.B. Die oder der Systemverantwortliche).
Nachteile:
Problem 1: Innerhalb einer Anforderungsspezifikation ist gar nicht so leicht zu erkennen, welche Stände der Anforderungen innerhalb einer Anforderungsspezifikation für die Freigabe relevant sind.
Der Baseline-Mechanismus in professionellen RM-Tools hilft nicht pauschal, sichtbar zu machen, welche Anforderungen für einen bestimmten Zeitpunkt die Umsetzung relevant sind. Da der Baseline-Mechanismus in professionellen RM-Tools typischerweise eine ganze Anforderungsspezifikation einfriert, muss organisatorisch gewährleistet werden, dass sich in einer Anforderungsspezifikation zum Zeitpunkt der Erstellung einer Baseline nur Anforderungen befinden, die zur Weiterentwicklung genutzt werden sollen.
Problem 2: Bei der Zusammenarbeit mehrerer Autoren an einer Anforderungsspezifikation ist Abstimmungsbedarf nötig, um die Anforderungsspezifikation konsistent zu halten und eine Freigabe erwirken zu können.
Für die Einführung und Schulung eines Konzepts für die Arbeit mit Branches ist Aufwand nötig, weil die Arbeitsweise aufwändiger ist. Zudem kann, je nach RM-Tool, die Performance des RM-Tools leiden, weil das RM-Tool mehr Datenmengen verarbeiten muss.
Fazit:
Branches helfen dabei den Koordinationsbedarf zwischen Anforderungsautorinnen und Anforderungsautoren während der Entwicklung einer Anforderungsspezifikation sichtbar zu machen und Baselines sind ein Hilfsmittel einen Stand der Anforderungsspezifikation zu einem bestimmten Zeitpunkt nachzuweisen. Ob diese beiden Hilfsmittel die richtigen sind, kommt auf den Kontext an. Wie viele Autorinnen und Autoren müssen gemeinsam an einer Anforderungsspezifikation arbeiten und sind Nachweise für Stände von Anforderungsspezifikationen nötig, sind Fragestellungen, die bei der Auswahl der Hilfsmittel beantwortet werden sollten.
Falls Sie Hilfe bei der Evaluierung nach den richtigen Hilfsmitteln und dem passenden RM-Tool benötigen, melden Sie sich gerne bei unserem Vertrieb.
Der nächsten Blogbeitrag zeigt Ihnen, wie geeignete Ablagestrukturen der Anforderungen innerhalb der Anforderungsspezifikation bei der Koordination zwischen Anforderungsautorinnen und Anforderungsautoren helfen. Seien Sie gespannt und freuen Sie sich auf die nächsten Blogbeiträge!
Viele Grüße,
Ihre SOPHISTen
Definition Baseline (übersetzt aus dem IREB online Glossar):
Eine stabile, änderungskontrollierte Konfiguration von Arbeitsprodukten.
Definition Konfiguration (übersetzt aus dem IREB online Glossar):
Eine konsistente Menge an logisch kohärenten Elementen. Die Elemente sind identifizierbare Arbeitsprodukte oder Teile eines Arbeitsprodukte in maximal einer Version.
Definition Arbeitsprodukt (übersetzt aus dem IREB online Glossar):
Ein aufgezeichnetes Zwischen- oder Endergebnis entstand aus einem Arbeitsprozess.
Definition Branch (übersetzt aus dem IREB online Glossar):
Ein Pfad von Konfigurationen oder Versionen von Arbeitsprodukten, der sich vom Hauptpfad abzweigt.
Notiz: Ein Branch wird durch das Erstellen einer Kopie einer Konfiguration oder Version eines Arbeitsproduktes erzeugt. Die Kopie der Konfiguration oder der Version des Arbeitsproduktes ist die Wurzel der Branches. Ein Branch kann später in die Mainline oder in einen anderen Branch eingespielt werden.