Integration in Managementsysteme für Softwaresteuerung

IBM® Rational Asset Manager ergänzt vorhandene Managementsysteme für Softwaresteuerung wie IBM Rational Team Concert, IBM Rational ClearCase, Unified Change Management und CVS und fügt diesen Funktionen zum Überprüfen, Klassifizieren, Archivieren, Herunterladen, Diskutieren, Bewerten und Verfolgen von wiederverwendbaren Code-Assets hinzu.

Diese Tabelle illustriert die Integration des Rational Asset Manager-Repositorys in Systeme zur Quellcodeverwaltung.

Tabelle 1. Unterschiede zwischen Managementsystemen für Softwaresteuerung und dem Asset-Repository
  Managementsysteme für Softwaresteuerung (Team Concert, ClearCase, UCM, CVS) Rational Asset Manager-Repository
Primäre Aufgabenbereiche Entwickler Geschäftsanalysten, Entwickler, Architekten, Manager
Inhaltsebene Dateien Assets – ein Asset kann mehrere zugehörige Artefakte (Dateien) und zugehörige Metadaten enthalten
Änderungsrate Hoch; Objekte sind in Arbeit Niedrig; geprüfte, wiederverwendbare Komponenten
Collaboration Bei der Erstellung von Artefakten und der parallelen Entwicklung Bei der Überprüfung und Wiederverwendung von Assets über Diskussionsforen, E-Mails, Benachrichtigungen, RSS-Feeds
Taxonomie Nicht zutreffend Assettypen und Beziehungen; Kunden können weitere Klassifikationen hinzufügen
Suche Dateibasiert Auf Metadaten basierende Suche; angepasste Metadatenattribute
Messdaten Nicht zutreffend Verfolgung von Assetverwendung, Feedback und Popularität
Überprüfung und Freigabe Änderungsmanagement Prüfkommissionen, anpassbarer Prüfprozess
Assettypen, Beziehungen und Wirkungsanalyse Keine Erkennung von Assettypen und Beziehungen. Unterstützung bei der durchgängigen Rückverfolgbarkeit einschließlich Implementierung in der Produktionsumgebung
Versionierung Auf der Ebene der Quellendateien Auf der Assetebene; ein Asset kann mehrere Dateien enthalten
Clientzugriff Eclipse Eclipse und Web

Code, der als ein Asset publiziert wurde, ist leicht zu finden und wiederzuverwenden und spart daher Entwicklungszeit. Das folgende Beispiel illustriert ein Szenario, das die Definition, die Entwicklung, den Build, die Überprüfung, die Freigabe und die Wiederverwendung eines Assets umfasst.

  1. Ein Softwarearchitekt definiert Assettypen, Kategorisierungen, Prüfkommissionen und Überprüfungsrichtlinien in Rational Asset Manager für die Asset-Governance und -wiederverwendung.
  2. Entwickler A sucht nach Assets für die Wiederverwendung (eine JAR-Datei für die Anmeldung bei einer Webanwendung), findet jedoch kein geeignetes Asset.
  3. Entwickler A erstellt ein Asset für die Anmeldung durch Verwendung der endgültigen Referenzversion für die Artefakte, deren Version durch das Managementsystem für Softwaresteuerung gesteuert wird.
  4. Entwickler A übergibt das Quellenasset für die Anmeldung an Rational Asset Manager. Die Assetversion ist 1 und der Assettyp ist 'Quelle'.
  5. Ein Release-Engineer erstellt einen Build und damit binäre Dateien aus den Quellendateien im Quellenasset für die Anmeldung.
  6. Ein Release-Engineer erstellt neue Assets, die die binären Dateien als Artefakte enthalten, und ordnet eine Beziehung zum ursprünglichen Quellenasset zu: Das Quellenasset verfügt über die Beziehung 'Buildquelle für' zum binären Asset und das binäre Asset verfügt über die Beziehung 'Build von' zum Quellenasset.
  7. Ein Prüfer überprüft das übergebene Asset (die JAR-Datei für die Anmeldung) und gibt es frei. Das Asset steht jetzt für die Suche und Wiederverwendung zur Verfügung.
  8. Entwickler B sucht und findet das Asset für die Anmeldung und integriert es mithilfe der Rational Asset Manager-Befehlszeilen-API in den Build seiner Webanwendung.
  9. Entwickler B aktualisiert sein Webanwendungsasset so, dass es die Beziehung 'enthält' zu der JAR-Datei für die Anmeldung umfasst.

Durch die Wiederverwendung des Codes, den Entwickler A bereits geschrieben hat, spart Entwickler B Zeit. Dadurch, dass Entwickler B die Befehlszeilen-API in Rational Asset Manager zum Erstellen des Builds der JAR-Datei für die Anmeldung aus dem Quellenasset verwendet, stellt er sicher, dass er immer die aktuelle Version des Assets von Entwickler A verwendet.


Feedback