Software-as-a-Service (SaaS) ist inzwischen nichts Exotisches mehr. SaaS-Architekturen bieten eine breite Palette von Vorteilen, die manchmal nicht auf den ersten Blick herausstechen, aber neue Prozesse und Funktionen oft erst ermöglichen. Mit Onshape kam im Dezember 2015 das erste Cloud-native CAD-System auf den Markt, das System ist ein gutes Beispiel dafür, dass Cloud mehr ist als „nur“ Speicherplatz und Rechenleistung ohne Grenzen. In einer Artikelreihe möchte ich diese Vorteile genauer analysieren. In dieser Folge geht es um die agile, nichtlineare Produktentwicklung und deren Management.
Lineare und nichtlineare Entwicklung sind zwei Konzepte, wie der Ablauf der Entwicklung und Konstruktion verwaltet wird. In der traditionellen, weitverbreiteten linearen Verwaltung werden im Verlauf der Konstruktion an bestimmten Zeitpunkten eine Version oder Revision gespeichert. In vielen Unternehmen werden Zwischenstände als Versionen bezeichnet, unter Revision versteht man in diesem Konzept feste Zeitpunkte, beispielsweise Prototyp, Testprodukt, Vorserie und Serienprodukt.
So hat man Zugriff auf vorherige Stadien der Entwicklung – in der Softwarebranche würden diese als 0.1, 0.2 und so weiter bezeichnet. Ist das Produkt fertig entwickelt, wird es veröffentlicht – Released – und geht in den Serienstatus über. Damit ist die Konstruktionshistorie beendet. Wird das Produkt fortentwickelt, entsteht eine Entwicklungsversion – Development – die wiederum in einen neuen Released-Status übergeht.
Gemeinsam ist allen Ausprägungen des linearen Konzepts, dass Ideen und Entwicklungsversionen, die nicht weiterverfolgt wurden, nicht archiviert werden. Es existiert nur eine einzige Versionshistorie, von der zu gegebenen Zeitpunkten „Schnappschüsse“ erstellt werden, die Revisionen. Es existiert also nur der durchgängige Pfad zum Endprodukt.
Dabei gehen jedoch viele Informationen verloren. Ein Produkt wird praktisch nie im ersten Anlauf perfekt konstruiert, es werden verschiedene Lösungsansätze ausgearbeitet, bis sich zeigt, dass einer dieser Ansätze der richtige ist. Oder eben zu sein scheint, bis sich in einem späteren Stadium der Entwicklung zeigt, dass dieser Ansatz nicht optimal ist und es besser gewesen wäre, einen anderen weiterzuverfolgen. Das wird nun schwierig, weil die Alternativen im linearen Modell eben nicht aufbewahrt werden.
In der Softwareentwicklung werden deshalb schon lange nichtlineare Entwicklungs-Verwaltungswerkzeuge genutzt, deren bekanntestes wohl Git ist. Die zentrale Idee der nichtlinearen Entwicklung ist Branching und Merging (Verzweigen und Verschmelzen). Um einen Lösungsansatz zu entwickeln, wird von der zentralen Historienline eine Abzweigung erstellt, ein Branch (Zweig). In diesem Zweig wird die Idee weiterentwickelt, es können natürlich mehrere Zweige entstehen, um verschiedene Ansätze eines Features zu erforschen.
Ideen, die nicht praktikabel erscheinen, bleiben als Zweig stehen und enden. Die optimale Idee wird zurück in den Hauptzweig verschmolzen (merged). Dabei vergleicht die Verwaltungssoftware den Zustand zu Beginn des Zweigs mit dem Endzustand beim Merge und überträgt genau die geänderten und hinzugekommenen Features ins Hauptmodell. Das hat den großen Vorteil, dass mehrere Features in mehreren Zweigen parallel entwickelt werden können. Werden mehrere Features nacheinander ins Hauptmodell verschmolzen, würde ohne diesen Vergleich das letzte Zweigmodell die vorherigen Merges überschreiben und löschen, da ein Zweig ja nicht „mitbekommt“, was in anderen Zweigen passiert ist. Stattdessen entsteht ein „Best of“ aller Zweige – und das ist übrigens auch der Unterschied zur Arbeit mit Varianten. Varianten sind Abwandlungen einer einzigen Entwicklung, es findet kein Merging statt.
So lassen sich auch verteilte Teams organisieren: Bei einer Autoentwicklung würde das Gesamtfahrzeug im Hauptstrang verwaltet, während dessen Komponenten in Zweigen entwickelt werden. In Unterzweigen könnten dann Alternativen verfolgt werden, beispielsweise im Antriebszweig Benziner, Diesel und Elektroantrieb. Am Ende werden dann die besten Zweige wieder zusammengeführt.
Stellt sich nun, wie oben beschrieben, im Verlauf einer Entwicklung heraus, dass ein anderer Lösungsansatz besser gewesen wäre, geht man einfach in diesen Zweig zurück, und entwickelt am damaligen Stand weiter. Der Hauptentwicklungsstrang wird auf den Zeitpunkt vor dem nun verworfenen Merge zurückgesetzt, spätere Merges müssen neu durchgeführt werden.
Dieser scheinbare Rückschritt hat einen wichtigen Grund: Bei jedem Merge prüft das System auf Konflikte. Es kann passieren, dass ein Feature des Hauptmodells, das im Zweig verwendet wird, durch einen zwischenzeitlichen Merge eines anderen Zweigs verändert wurde. Dann muss dieser Konflikt zuerst gelöst werden, bevor der Merge stattfindet. Geht man nun viele Merges zurück, können natürlich viele dieser Konflikte auftreten. Diese Vorgehensweise garantiert, dass das Modell immer konsistent bleibt.
Vor allem: Es bleiben eben alle weiteren Entwicklungen in ihren Zweigen erhalten. Sie müssen nicht nochmals neu modelliert werden, wie es in einem linearen Kontext notwendig wäre, sondern es geht lediglich darum, neu zu mergen und dabei die Konflikte aufzulösen.
Alle Ideen, die jemals in einem Entwicklungsprojekt erarbeitet wurden, bleiben erhalten und können in anderen Projekten weitergenutzt werden. Onshape kombiniert diese nichtlineare Entwicklung mit einem „Chatsystem“, in dem die Entwickler über die Ansätze diskutieren und Vor- oder Nachteile aufzeigen und bewerten. Auch diese Entscheidungsabläufe werden so dauerhaft konserviert und bleiben zu jedem Zeitpunkt nachvollziehbar.
So bietet die Onshape-Datenverwaltung Möglichkeiten und Funktionen, die eine agile Entwicklung nicht nur ermöglichen, sondern geradezu fördern. Der gesamte Entwicklungsprozess wird transparent und effizienter. Was heute als eine Fehlentwicklung erscheint, kann morgen schon die Lösung sein – kein Problem mit Onshape!
Eine gute Beschreibung, wie ein solcher Prozess in der realen Konstruktion umgesetzt werden kann, findet sich hier.
Onshape unterscheidet sich technisch sehr von anderen Systemen und bietet deshalb völlig neue, bisher undenkbare Möglichkeiten. In den nächsten Folgen dieser Serie werde ich diese Besonderheiten jeweils einzeln und wesentlich detaillierter vorstellen. Erst dann zeigt sich das ganze Potential dieses Systems. Testen Sie Onshape kostenlos selbst – nach einer kurzen Anmeldung steht Ihnen das System direkt zur Verfügung! Onshape stellt im Learning Center einen interessanten Kurs namens Hands-On Test Drive zur Verfügung, der einen guten Überblick über die CAD-Funktionen bietet.
Transparenz: Onshape stattet mich mit einer Profilizenz zum Testen aus und unterstützt diese Serie finanziell. Inhaltlich wurde keinerlei Einfluss genommen.