Migration und Austausch von Anforderungen

Anbieter zum Thema

MicroConsult Academy GmbH

emlix GmbH

RTI Real-Time Innovations

Mixed Mode GmbH

Es kann sinnvoll sein, im alten System (aus dem exportiert werden soll) nicht jedes mögliche Attribut bzw. nicht jeden möglichen Wertebereich von Attributen zu definieren. So kann es eine beträchtliche Anzahl von Werten für das Attribut „Status" geben, die in diesem (praxisrelevanten) Beispiel nicht alle in das Zielsystem Integrity übernommen werden sollen. Auf der anderen Seite kann das simple Weglassen der Werte in Integrity aber beim Rückaustausch bzw. einem eventuellen Rückmigrieren zu Informationsverlust führen.

Die Rückmigration kann z.B. bei Kunden notwendig werden, die noch das alte System betreiben, um abwärtskompatibel zu bleiben. Dieses grundsätzliche Problem kann durch Einführung von Dummy-Werten für manche Attribute umgangen werden. So kann für das Attribut „Status“ in einem Modul der Wert „new“, „in Progress“, „reviewed“, „approved“ und „published“ stehen, in einem anderen „new“, „reviewed“, „approved“ und „rejected“. In Integrity wollen wir nicht die Vereinigungsmenge aller Werte einführen, sondern beschränken uns auf ganz bestimmte Werte. Die anderen Attributwerte werden auf „dummy_1“, „dummy_2“ etc. abgebildet und sind nur für das Altsystem relevant.

In diesem Beispiel soll das Mapping etwa 90 Prozent der in den DOORS-Modulen vorhandenen Attribute berücksichtigen. Für die Integrity-Seite wird eine Auswahl an häufig benutzten Attributen zusammengestellt, welche die am häufigsten benutzen Felder möglichst neutral abbilden sollen.

Mappings sind nicht nur zwischen DOORS und Integrity, sondern auch zwischen Integrity-Installationen und jedem anderen RM-Tool notwendig. Als Teil der Integrity-eigenen RIF-Toolkette existiert ein Utility, mit dem sich das Mapping sich auf graphische Weise bequem erstellen lässt. Auf händische Erstellung oder Nacharbeit per Editor kann deswegen im Allgemeinen weitgehend verzichtet werden.

Vorbereitungen für die eigentliche Migration

Zunächst werden die DOORS-Projekte in einen Testserver importiert. Die in Atego Exerpt erzeugten RIF-Dateien werden per Integrity-eigenem Tool eingespielt. Alle Importvorgänge sind mit zu protokollieren und auf Fehler zu überprüfen. Bei Bedarf muss die Migration mit veränderten Parametern auf der Integrity-Seite wiederholt werden. Hierbei muss man berücksichtigen, dass ein zentraler Bestandteil des RIF-Formats die eindeutige Identifizierung der Anforderungen über einer Global Unique ID (GUID) ist.

Zwischen RIF und DOORS ist Atego Exerpt für das Mapping der Requirements verantwortlich, zwischen RIF und Integrity das Austausch-Utility. Beim Erstimport muss Integrity für jedes Requirement eine GUID anlegen, wofür ein eigener Datenbank-Trigger installiert werden muss. Fehlt dieser Trigger, erzeugt das Austauschtool eigene IDs, die aber unter Umständen nicht eindeutig für alle Dokumente sind. Deshalb muss sichergestellt werden, dass dieser Trigger vorhanden ist, da sonst die gesamte Migration wiederholt werden muss.

Eine weitere konzeptionelle Einschränkung bezüglich des Austauschs auf Integrity-Seite ist die Tatsache, dass es nicht einfach ein Tool zum Requirements-Management ist, sondern vielmehr eine Lifecycle-Solution mit Workflow für Quellcode- und Konfigurationsmanagement, Change-Management und Testen. Dokumente liegen in verschiedenen Zuständen vor und können unter Umständen für bestimmte Nutzergruppen zwar noch lesbar, aber nicht mehr beschreibbar sein. Dann aber ist ein Import nicht möglich. Vor dem Austausch sollte man also immer darauf achten, dass die jeweiligen Dokumente beim Update tatsächlich beschreibbar sind.

Die Mapping-Konfiguration ist zwar im Prinzip wiederverwendbar, muss aber bei manchen Dokumenten beim Wechsel von Import zu Export jedes Mal neu ausgewählt werden. Dadurch muss die jeweilige Mapping-Konfiguration immer mit abgespeichert werden, was einen gewissen Verwaltungsaufwand nach sich zieht.

Ein Task, den jede Austausch-Lösung anbieten muss, ist das Erkennen von Updates gegenüber Neuimporten.

Hier muss es die Möglichkeit eines Vergleichs mit früheren Versionen geben, den Integrity in Form von Baselines mitbringt. Dadurch wird bei einer Auswertung der Updates in einem Report schnell klar, welche Objekte sich geändert haben. Es gibt auch die Möglichkeit von Revisions-Items, die einen noch schnelleren Überblick über die Änderungen bieten.

Der Austausch der Requirements

Wenn zu Beginn der Migration bereits ein Requirements-Austausch zwischen der Integrity-Installation eines Zulieferers und der DOORS-Datenbank der Beispielfirma besteht, muss dieser Austausch natürlich trotz der Migration bei der Beispielfirma reibungs- und fehlerlos aufrecht erhalten werden. Anforderungen dieser Art müssen bei der Planung eines Migrationsprojekts berücksichtigt werden und stellen eine besondere Herausforderung dar.

Zusammenfassung: Migration – das bringt's!

Die grundsätzlichen Erfahrungen bei Migrationen zeigen, dass auch bei verschiedenen Ansätzen und Wirkungsweisen der Tools eine gründliche Vorbereitung, Planung und Projektüberwachung zum Erfolg führt. Gewisse Reibungsverluste sind normal und dienen zur Feinabstimmung des Konzepts. Die Einführung einer integrierten Lösung für Systementwicklung bringt für den Betrieb unter dem Strich deutliche Vorteile bei der Vereinheitlichung und Konzentration der Tool-Landschaft. Requirements, Source- und Konfigurationsmanagement, Change Management und Testing werden unter einer gemeinsamen Datenverwaltung und Oberfläche vereint.

* Frank Lippert bearbeitet als Softwarearchitekt bei Mixed-Mode das Themenfeld Requirements Engineering.

(ID:42675833)