OSLC: Offener Standard für die Tool-Integration

Unter dem Oberbegriff Open Services for Lifecycle Collaboration gibt es einen Integrationsansatz zur Sichtung, Bearbeitung und Verknüpfung von Lifecycle-Ressourcen über die Entwicklungswerkzeuge hinaus.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 12 Min.
Von
  • Renate Stücka
Inhaltsverzeichnis

Wie viel effektiver wäre die Entwicklung von Software und Systemen, wenn es im Verlauf eines Projekts nicht so viele Lücken zwischen Teams, Standorten, Tools und Prozessen zu zu überwinden gäbe? Unter dem Oberbegriff Open Services for Lifecycle Collaboration (OSLC) gibt es einen Integrationsansatz zur Sichtung, Bearbeitung und Verknüpfung von Lifecycle-Ressourcen über die Entwicklungswerkzeuge hinaus.

Oft ist schon viel gewonnen, wenn sich die im Projekt eingesetzten Werkzeuge nicht isoliert, sondern integriert nutzen lassen. Ideal wären die Verknüpfung von Artefakten über Werkzeuge und die Zuordnung von Verantwortlichkeiten über Prozesse hinweg, ohne beschwerlichen manuellen Overhead. Die Werkzeuge jedoch, in der Regel organisch gewachsen aus dezidiert eingesetzten und nicht selten von Unternehmen selbst entwickelten Tools für die Lösung spezifischer Aufgaben, bieten meist nur unzureichende Integrationen.

Die Artefakte entlang des Lebenszyklus einer Anwendung, wie Anforderungen, Modelle, Aufgaben, Quellcode oder Testfälle, sollten durchgängig verknüpft und verfolgbar sein, jedoch stehen dafür nur einzelne paarweise Verbindungen zwischen den Werkzeugen zur Verfügung. Hinzu kommt, dass die Daten meist in den Tiefen der Tools vergraben sind und sich nur per spezifischer bilateraler Integration für ein anderes Werkzeug zugänglich machen lassen. Möchte man die Integration funktional erweitern, ist eine neue Anpassung oder Erweiterung des Datenzugriffs erforderlich.

Dieses eng geknüpfte Netz speziell angepasster Integrationen ist durch alltägliche Ereignisse leicht angreifbar: Schon Upgrades des zugrunde liegenden Betriebssystems oder eine neue Version der Schnittstellenspezifikation können zu Problemen führen. So bieten viele Werkzeuge eine Schnittstelle, mit deren Hilfe Anwender das Werkzeug für spezifische Szenarien anpassen können. Wenn sich nun beim Übergang auf die nächste Version Änderungen an der Schnittstelle ergeben, kann das zur Folge haben, dass die Anpassungen neu zu erstellen sind.

Außerdem nutzen einzelne Tools oft ein eigenes Vokabular, sodass unterschiedliche Begriffe für vergleichbare Dinge verwendet werden oder Werkzeuge denselben Begriff unterschiedlich verstehen. Selbst wenn sich Daten über Werkzeuggrenzen hinweg nutzen lassen, kann es wegen der Bedeutung Missverständnisse geben, oder ein logisches Konstrukt im Entwicklungsprozess kann über mehrere Tools verteilt sein, mit besonderen Anforderungen an die Integration und Synchronisierung zwischen diesen Tools.

Ein ideales Produkt würde eine einheitliche Architektur definieren, ebenso wie Protokolle, die die Artefakte aus den unterschiedlichen Werkzeugen in konsistenter Weise integrieren. Würde man das jedoch einem einzelnen Anbieter überlassen, wäre das Resultat nur eine weitere größere "Blackbox", die die Entwicklung weiterer spezifischer Integrationen erfordert. Verwendet man stattdessen offene Standards, die viele Anbieter unterstützen, wird der Nutzen der neuen integrierten Welt die zusätzlichen Kosten der Teilnahme aufwiegen.

Genau die Eigenschaften findet man im Internet, und tatsächlich lässt sich eine solche Integrationsarchitektur dem Internet nachbilden. Charakteristika einer solchen Architektur sind:

  • skalierbar: Es gibt keine Limitierung bezüglich der Anzahl der Anwender beziehungsweise Ressourcen.
  • verteilt: Anwender und Ressourcen können global verteilt sein.
  • zuverlässig: Ein breites Spektrum an Zugriffsprofilen wird zuverlässig unterstützt.
  • erweiterbar: Ressourcen und Protokolle/Dienste sind für zukünftige Erweiterungen vorbereitet.
  • einfach: leicht und flexibel zu erlernen und anzuwenden, eine enge Kooperation und kontinuierliche Koordination zwischen Herstellern ist nicht erforderlich.
  • gleichberechtigt: gleichermaßen zugänglich für alle Teilnehmer, von einzelnen Projekten bis zu großen Anbietern, für Open-Source-, In-house- oder kommerzielle Entwicklung – niemandem wird die Teilnahme verwehrt.