Skip to main content

Von der Idee über das Produkt zur Entsorgung

ALM (Application Lifecycle Management) ist in aller Munde. Immer mehr Werkzeuge kommen auf den Markt, die als ALM Tool bezeichnet werden.

Aber was genau ist ALM? Ein Werkzeug, ein Vorgehen, eine Methode?

Unser Software Engineering Report wird sich mit dieser Frage beschäftigen und Antworten geben.

Und natürlich bezieht sich der SW Report auf das so genannte Embedded Engineering. Wie so häufig gibt es gravierende Unterschiede zwischen der Entwicklung von Anwender - Software und Embedded Produkten. So auch im Bereich ALM, wobei erstere die Produktion vermisst, die bei ALM natürlich eine wichtige Rolle spielt.

Application Lifecycle Management hört nicht nach der Entwicklung auf. Es bezieht sich, wie der Name schon sagt, auf den kompletten Lebenszyklus des Produktes. Das bezieht alles mit ein bis zur Verschrottung. Oder sollten wir besser in Kreisläufen denken und recyceln anstelle zu verschrotten?

Dann ist auch dieser Schritt bereits bei der Entwicklung und Konstruktion zu berücksichtigen. Das ist Lifecycle Management.

Application Lifecycle Management

Der Begriff ALM wurde im Bereich des Software Engineering von so genannter Anwendungssoftware geprägt. Symptomatisch für diesen Bereich des Software Engineering ist, dass die klassische Produktion fehlt.

Im Bereich des Embedded- oder Systems Engineering hingegen folgt der Entwicklung die eigentliche Produktion. Da im Unterschied zu reiner Software durch die Produktion auch Materie zum Bestandteil des Produktes gehört, muss Application Lifecycle Management über den Bereich des Services und der Wartung in diesem Fall auch die Entsorgung und zukünftig sicher auch das Recycling berücksichtigen.

Wenn von einer ALM Lösung gesprochen wird, dann bezieht sich das meistens auf die Sicht des reinen Software Engineerings. Im Bereich des Embedded Systems Engineerings stellen sich jedoch etwas andere Herausforderungen und die allgemeinen Definitionen von ALM (z.B. bei Wikipedia) sind nicht ganz zutreffend. Hier sind die Pfade noch nicht sehr ausgetreten, was in der Praxis sicher an der einen oder anderen Ecke zu spüren ist.

Wenn sich also ein Werkzeug als ALM - Lösung darstellt, so ist dieses in 99% aller Fälle lediglich auf den Teil des Software Engineerings zutreffend.

Bleiben wir erst einmal beim klassischen Ansatz, was ist dann ALM konkret? Um diese Frage zu beantworten möchte ich folgendes Bild nutzen. Auf der einen Seite ist die Idee, die in Form von Anforderungen, Konstruktionen, Entwürfen ... erst einmal zu einer virtuellen Spezifikation führt.

Nennen wir diese Landkarte. Dann entsteht in einem Entwicklungs- und Produktionsprozess aus dieser Landkarte ein reales Produkt. Im Idealfall entsprechen sich Landkarte und Realität zu einem geplanten Zeitpunkt (z.B. zur Einführung des Produktes) zu 100%.

Die Sichtweise Landkarte und Realität ist eine rein statische Sichtweise. Betrachten wir einmal den Zeitpunkt der Produkteinführung und gehen wir davon aus, dass Landkarte und Realität im idealen Zustand sind und sich 100% entsprechen. (Auch wenn es praktisch nahezu niemals vor kommt)

Nun gibt es die Idee einer Produktverbesserung, die in die Landkarte designed wird. Als ALM kann nun das Managen aller durchzuführenden Tätigkeiten bezeichnet werden, die notwendig sind, um die Realität zu erzeugen, so dass sie wieder 100% der Landkarte entspricht.

Man kann sich leicht vorstellen, dass bei der Umsetzung der Änderung der Spezifikation zu einer realen Produktänderung eine sehr große Anzahl an Fachdomänen beteiligt sind und diese von verschiedensten Personen vertreten werden.

Diese wiederum setzen ihrer Fachdomäne entsprechende Werkzeuge ein, die in erster Linie Daten verarbeiten. Blicken wir erst einmal auf die Entwicklung, dann wird es sich im Wesentlichen um CAD (Compuder Aided Design) und CASE (Compuder Aided Software Engineering) Werkzeuge handeln. Deren Daten sind Source Code, Konstruktionspläne, Kommunikationspläne oder Ablaufdiagramme, Stücklisten, ...

Diese werden in so genannten Repositories gespeichert.

Viele dieser Daten stehen Fachdomänen-übergreifend in Zusammenhang und ein erster Schritt in Richtung ALM liegt schlicht im Management der Domänen-übergreifenden Daten.

Synchronisation von Daten

Hier ist der Stand der Technik die auszugsweise Synchronisation der Repositories. Soll z.B. eine Anforderung, die in der Fachdomäne des Requirements Engineering entstanden ist, im Entwurf der Software in einem UML Diagramm zur Dokumentation des Modells wieder verwendet werden, so wird dieses heute auf Basis der Synchronisation von bestimmten Daten der Repositories ermöglicht.

Eine große Anzahl an Anforderungs-Management-Werkzeugen und Modellierungswerkzeugen haben hierfür Schnittstellen, bzw. gibt es diverse Unternehmen, die sich genau diesem Problem annehmen und Schnittstellen zwischen den Werkzeugen verschiedener Fachdomänen und deren Repositories ermöglichen.

Nicht ganz ideal an diesen Lösungen ist die Synchronisation an sich (Werden Daten an beiden Seiten gleichzeitig geändert entstehen Konflikte) und der hohe Aufwand die zwei Werkzeuge auf diese Weise zu integrieren.

Interface zwischen Repositories

Es gibt am Markt verschiedene Firmen und Produkte, die eine Synchronisation der Repositories unterschiedlichster Werkzeuge ermöglichen.

  • Argosense (Symphony)
  • IBM® Rational® (Gateway, Jazz, OSLC)
  • Sparx Systems (MDG Link)
  • PROSTEP (Open DXM Integration Framework)
  • Tasktop (Sync)

Zentrales Repository

Eine mögliche Lösung für dieses Problem läge darin, dass alle Werkzeuge auf das selbe Repository zugreifen. IBM® Rational® Jazz (eine Integrationsplattform für verschiedene Werkzeuge) ermöglicht diesen Ansatz. Aber es stellt sich schnell heraus,dass zwar die Synchronisation entfällt, aber die Anpassungen immer noch sehr aufwändig sind, da die Metamodelle der Daten nicht identisch sind.

In Abbildung Nr. 3 ist ein kleiner Auszug aus dem Metamodell von IBM® Rational® DOORS® und IBM® Rational® Rhapsody® dargestellt. Der Sinn der Daten entsprechen sich zwar, aber die Kennzeichnung (das Metamodell) unterscheidet sich. Rhapsody müsste also Kenntnisse über das Metamodell (Sympolische Information, Art der Struktur und Speicherung der Daten ....) von DOORS besitzen und umgekehrt.

Selbst innerhalb von Fachdomänen existieren häufig signifikante Unterschiede im Metamodell der Daten.

So kennen die beiden Modellierungswerkzeuge MATLAB und Enterprise Architekt beide das Notationselement ,Signal‘. Dieses Modellelement ist aber nahezu konträr in seiner Bedeutung. (MATLAB -> zeitkontinuierliches Datenobjekt - Enterprise Architect -> zeitdiskretes Datenobjekt). Eine Synchronisation der Metainformationen und gegenseitige Wiederverwendung würde zu katastrophalen Ergebnissen führen. So einfach geht es also nicht.

Ein Werkzeug für alles

Für kleinere und einfache Projekte oder innerhalb weniger Fachdomänen bietet sich die Möglichkeit, sich auf ein Werkzeug zu beschränken, dass möglichst viele Bereiche der involvierten Fachdomänen abdeckt. In diesem Fall gibt es nur ein Repository mit einem Metamodell der Daten. Hinsichtlich des Datenmanagements ein idealer Zustand.

Das Software Engineering Werkzeug Enterprise Architect z.B. entwickelt sich zu einem sehr breit aufgestellten Werkzeug und wird in diesem Sinn zunehmend genutzt.

Aber auch hier gibt es Nachteile. Zum einen wird das Werkzeug in seiner Bedienung zunehmend komplexer und zum anderen befriedigt es die speziellen Anforderungen einzelner Fachdomänen nicht so, wie spezialisierte Werkzeuge.

OSLC Open Services for Lifecycle Collaboration

Eine ganz andere Sicht ergibt sich, wenn nicht nur die statischen Daten betrachtet werden, sondern die Tätigkeiten der Fachdomänen und deren Überschneidungen. So wird ein Testingenieur im Wesentlichen andere Tätigkeiten durchführen und auf andere Daten zugreifen, als ein Software Architekt oder ein Programmierer. Darüber hinaus wird es Tätigkeiten geben, die auf Daten der angrenzenden Fachdomänen zurückgreifen. So ist es aus Sicht von ALM interessant zu wissen, mit welcher Testroutine eine bestimmte Anforderung getestet wird.

Sinnvoll wäre es nun, wenn das Test-Management-Werkzeug ermöglichen würde die Testspezifikation mit der entsprechenden Anforderung zu verlinken, und im Gegenzug das Anforderungs-Management-Werkzeug die Möglichkeit besitzt zu einer Anforderung die verlinkten Testspezifikationen anzuzeigen.

Oder noch besser die Ergebnisse eines Testruns. Betrachtet man die Schnittstellen zwischen verschiedenen Fachdomänen, dann ergeben sich eine eingeschränkte Anzahl an sinnvollen Tätigkeiten. OSLC schlägt nun vor, diese als Dienste bereitzustellen.

Würde z.B. das Anforderungs - Management einen Service bereitstellen, der einen Link zu einer Anforderung durchführen kann und das Testmanagement-Werkzeug diesen Dienst wiederum in seiner Oberfläche bereitstellt, dann könnten die Testspezifikationen aus dem Testmanagement-Werkzeug zu den Anforderungen verlinkt werden. Das Testwerkzeug muss dabei nicht das Metamodell des Anforderungsmanagement-Werkzeugs kennen, sondern nur die Anwendung des bereitgestellten Dienstes.

Der Testingenieur hingegen müsste sich nicht in ein fremdes Werkzeug einarbeiten, er könnte in der Bedienphilosophy seines gewohnten Werkzeuges den Dienst des Anforderungs-Management-Werkzeuges anwenden.

OSLC ist ein Standard, der für die Interfaces verschiedener Fachdomänen im Engineering-Umfeld die jeweils gebräuchlichen Dienste definiert.

Kommunikation und Workflow

Bisher haben wir vor allem die Daten und deren Nutzung betrachtet.

Ein weiteres wichtiges Ziel von ALM liegt darin, den Workflow von Tätigkeiten zu managen. Im Grunde geht es darum, dass bei der Änderung innerhalb einer Fachdomäne die Auswirkungen und daraus resultierenden Tätigkeiten in andere Fachdomänen vollständig erfasst und durchgeführt werden. Erinnern Sie sich an unser ursprüngliches Bild mit Landkarte und Realität.

ALM ist das Management aller notwendigen Tätigkeiten, um die Realität konsistent zur Landkarte zu halten. Und wie wir festgestellt haben, reichen die Aktivitäten in verschiedenste Fachdomänen.

Wie also kann sichergestellt werden, dass eine Tätigkeit in einer Fachdomäne zum einen angestoßen wird, aber auch den vollständig richtigen Schritt durchführt?

Kommunikation ist hierfür eine wesentliche Grundlage. Vera F. Birkenbihl (Kommunikations- und Hirnforscherin) hat zur Erläuterung von Kommunikation unter anderem ihr Insel-Modell, das ich im folgenden kurz skizzieren möchte.

Von Vera F. Birkenbihl habe ich folgendes Beispiel: Stellen Sie sich vor, in einem Restaurant ist eine Gesellschaft von mehreren Personen. Zwei Gäste von ihnen haben Wiener Schnitzel bestellt, einer ein echtes aus Kalbfleisch und ein anderer nach Wiener Art aus Schweinefleisch. Der Ober kommt mit den Gerichten und fragt ,Schwein?‘ und der Gast, der das Kalbsschnitzel bestellt hat zeigt auf sein gegenüber und sagt ,der Herr dort‘.

In dem gesamten Kontext ist diese Kommunikation ohne Wiederspruch. Aber stellen Sie sich einmal die losgelöste Kommunikation in einem anderen Kontext vor. Es kommt jemand und fragt ,Schwein?‘ und jemand anderes deutet auf eine Person und sagt ,Der Herr dort‘.

Vollständige Kommunikation muss immer den gesamten Kontext einbeziehen. Die reine verbale Kommunikation trägt in der Regel nur 20% zum vollen Verständnis bei. Die restlichen Informationen liefert der Kontext. Ist der Kontext bei beiden Kommunikationspartnern gleich gibt es geringes Potential für Missverständnisse (Täuschung). Ist der Kontext jedoch unterschiedlich, gibt es ein großes Potential an Täuschung mit anschließender Enttäuschung.

Also nicht so sehr das was kommuniziert wird entscheidet, sondern alle notwendigen Informationen aus Sicht eines Kontextes. Für einen Experten ist es evtl. eine banale Sache, dass eine Metallic Lackierung eine spezielle Grundierung und zusätzlichen Klarlack-Überzug benötigt. Es gehört zu den Allgemeinkenntnissen eines Lackierers (Kontext innerhalb einer Fachdomäne). Aber hat der Einkauf die Bestellung von zusätzlichem Klarlack berücksichtigt?

Wie können wir sicherstellen, dass die übergreifende Fachdomäne jeweils das aus dem Kontext der anderen Domäne an Informationen bekommt was für vollständige Kommunikation notwendig ist?

Es gibt dabei noch ein anderes Problem. Heutige Systeme sind so komplex, dass die Verfügbarkeit aller Informationen zu einem Augenblick nicht wirklich hilfreich ist. Wenn in Dutzenden Dokumenten mit jeweils mehreren Dutzend Seiten alle Informationen abgelegt sind, dann fehlt die Zeit sich die für diese Situation notwendigen Informationen aus dem Gesamtumfang aller Informationen zu extrahieren.

Der heute praktikabelste Mechanismus, um Kontexte vollständig und situationsgerecht zu beschreiben sind Verlinkungen. Rot-Metallic bekommt eine Linkbeziehung zu Grundierung und Gehäusefarbe. Alles was in Beziehung steht bekommt eine Linkbeziehung. Diesen Beziehungen kann dann in die gesamte Tiefe des Kontextes gefolgt werden, was sicher stellt, dass der Informationsgehalt vollständig ist.

Linkbeziehungen und die so genannte Traceability (Verfolgung der Linkbeziehungen) sind eine wesentliche Grundlage für ALM.

Wird die Landkarte an einer Stelle geändert kann auf Basis der Linkbeziehungen der so genannte ,Impact‘ analysiert werden. Ändert sich die Gehäusefarbe, dann bekommen z.B. Einkauf und Produktion einen Hinweis darauf. Nun können Sie auf Basis der Linkbeziehungen den vollständigen Kontext aller beteiligten Domänen analysieren und für die jeweilige eigene Fachdomäne alle relevanten Informationen berücksichtigen. Auf Basis der Workflow-Definition können Aussagen über das notwendige Vorgehen definiert werden, so dass keine Arbeitsschritte vergessen werden.

Voraussetzung dafür ist der Übergang von Dokumenten-zentrischen zu Objektzentrischen Metastrukturen. Das Verlinken von Dokumenten ist nicht ausreichend filigran. Zudem können in einer Metastruktur von Objekten für diese auch Attribute und Zustände definiert werden.

Nun sind wir den Voraussetzungen für ALM schon recht nah gekommen. Eine Metastruktur, die Informationen (Artefakte) und deren Beziehungen filigran darstellt. Jedem Artefakt kann auf Basis von Zuständen und Aktivitäten ein Workflow gegeben werden und das alles Fachdomänen- und Werkzeug-Übergreifend.

ALM in der Praxis

Zum Beispiel Polarion: bezeichnet sich als ein ALM Werkzeug und es besitzt alle zuvor besprochenen Voraussetzungen. Werfen wir einmal einen kurzen Blick auf die wesentlichen Merkmale.

Kapselung der Aussagen über ein System (Artefakte) in Objekte als eigenständige Einheit, kontextübergreifende gegenseitige Verlinkung von in Beziehung stehenden Artefakten und die Definition eines Workflows bezogen auf Artefakte sind die Basis-Mechanismen für einen erfolgreichen ALM Ansatz. Heutige Werkzeuge, so genannte ALM Werkzeuge liefern diese Mechanismen.

Es bleibt die spannende Frage: Wie integrieren sie sich in die verschiedenen Fachdomänen? Wie bilden sich die Schnittstellen zum Beispiel zu Fachdomänen-spezifischer Werkzeuge in den Bereichen PPS, CAD, CASE, FMEA, Test ... . Ein erster zur Zeit praktizierter Ansatz ist Domänen-spezifische Artefakte und Workflow parallel zu den herkömmlichen Werkzeugen zu verwalten. Ein interessanter, aber noch nicht durchgängig verbreiteter Ansatz ist OSLC.

Aber selbst, wenn aus heutiger Sicht ein vollständiger ALM Ansatz noch nicht zu erreichen ist, den ersten Schritt, z.B. in Kombination mit Anforderungs- und Test-Management zu machen erscheint auf jeden Fall sinnvoll. Heutige verfügbare Lösungen und methodische Ansätze haben bereits großes Potential Effizienz und Qualität im Engineering zu erhöhen, auch wenn die Lösungen noch nicht in allen Bereichen des Engineerings durchgängig sind.

In diesem Sinn wünsche ich Ihnen viel Erfolg in Ihren Projekten.

Autor:

Andreas Willert
Haben Sie noch Fragen oder Anregungen zum Thema? Dann freue ich mich über eine E-Mail: awillert@willert.de

Herausgeber:

WILLERT SOFTWARE TOOLS GMBH
Hannoversche Straße 21
31675 Bückeburg
E-Mail: info@willert.de
Tel.: +49 5722 9678 - 60

Alle ESE-Reports im Überblick

Aktuelles Know-how und neueste Entwicklungen und Trends rund um das Thema Emedded Software Engineering

> zu den ESE-Reports

Hinweis: Unsere Webseite nutzt Cookies. Wenn Sie fortfahren, nehmen wir an, dass wir Ihre Erlaubnis haben Cookies zu setzen. Informationen zum Einsatz von Cookies sowie unsere Datenschutzbestimmungen finden Sie in unserer Datenschutzerklärung und über unser Impressum.