Anforderungsmanagement konsistente Dokumente im V-Modell

Im Software Engineering werden immer noch viele Informationen in Form von Office - Dokumenten gemanaged. Dabei entstehen je nach

Phase und Technik im Engineering-Prozess separate Dokumente mit redundanten Informationen. Unter dem wachsenden Zeitdruck ist es fast

unmöglich diese redundanten Informationen in den verschiedenen Dokumenten konsistent zu halten.

So zeigt eine Umfrage unter unseren Kunden, dass in 95% der Projekte die Dokumentation der Software (egal, ob sie mit MS Word, MS Visio

oder anderen dokumentenzentrischen Werkzeugen erstellt wird) nahezu nutzlos ist, da sie nicht konsistent mit dem Source-Code gehalten

werden kann und damit nicht verlässlich ist. In Projekten, in denen auf Grund von Sicherheitsanforderungen hohe Qualität gefordert wird, gehört es schon seit langem zum Stand der

Technik, dass alle Dokumente, Modelle, Code und Testfälle untereinander konsistent gehalten werden. Grundsätzlich ist es also möglich und nur

eine Frage des Vorgehens. Was mit einer dokumentenzentrischen Arbeitsweise ein fast unmögliches Unterfangen ist wird auf Basis eines

Repository auf einmal sehr einfach.Dieses White Paper zeigt, wie Informationen auf Basis eines Repository

effizient genutzt werden können, welche Werkzeuge es gibt und wie der Einstieg in das so genannte Anforderungs-Management (Requirement

Engineering) aussehen kann.

Inhalt:

Anforderungs - Management, was ist das?

Lassen sich redundante Informationen vermeiden?

Anforderungen an die Req. Engineering Werkzeuge

Vom Requirements Engineering zum Aplication Lifecycle Management (ALM)

Normen, Staat und Rechtsprechung als Stakeholder

Lösungen die Willert Software Tools liefert

Einstieg: Best Practice zur Einführung von Requirement Management

Lassen sich redundante Informationen vermeiden?Stellen wir uns einmal die Rollen und Personen in folgendem Projekt vor. Eine Firma möchte die Entwicklung eines Audio DA Konverter in Auftrag geben. Betrachten wir die so genannten Stakeholder in diesem Projekt, hinsichtlich einer Produkteigenschaft, dann könnten in etwa folgende Informationen entstehen.

Der angestrebte Zielmarkt sind Menschen mit gehobenem Musikanspruch, hinsichtlich des Sounds steht im Lastenheft ,HiFi High End Qualität‘ (Abb. Nr.1)Der Projektleiter hat bei dieser Definition berechtigte Bedenken bezüglich der Testbarkeit und definiert etwas exakter eine Auflösung von 16 Bit und eine Samplefrequenz von 44,1 kHz entsprechend dem RedBook Standard für Audio CD‘s. Der Entwickler programmiert einen Timer, um den Takt für die erforderliche Samplefrequenz zu erzeugen und die Syntax könnte in etwa so aussehen: GPT1Reload = 0xFF32.Eigentlich steckt hinter der Syntax aller Stakeholder die gleiche Information. Aber können wir auf die verschiedenen sprachlichen Ausprägungen verzichten? Ich fürchte nicht. Die Aussagen sind domänenübergreifend nicht mehr verständlich

Excellence im Engineering Seite - -2

Abbildung 2

Abbildung 4

Abbildung 3

oder nicht präzise genug. Wir müssen also mit redundanten Informationen leben, aber wie geht das mit vertretbarem Aufwand?Im dokumentenzentrischen Vorgehen ergeben sich eine große Anzahl an Dokumenten mit redundanten Informationen und gegenseitigen Abhängigkeiten, wie in Abbildung Nr. 2 zu sehen ist.Werfen wir einen Blick in die Dokumente (Abbildung Nr. 3), dann stellt sich heraus, dass es sich in der Regel um eins zu n Beziehungen handelt. In realen Projekten ist die Größe eines Lasten- oder Pflichtenheftes im Bereich von 100 Seiten nicht selten. Ändert sich eine Anforderung im Lastenheft, dann wird niemand das komplette Pflichtenheft durcharbeiten, um alle Abhängigkeiten herauszufinden. Dieses ist der erste Schritt zu inkonsistenten Dokumenten.Einfacher geht es auf Basis eines Repository z.B. mit Hilfe eines Anforderungsmanagement-Werkzeugs. In Abbildung Nr. 4 ist die Gegenüberstellung der Dokumente auf Basis ihrer Beziehungen zu sehen. Hier können Auswirkungen auf einen Blick vollständig erfasst werden. Auf Basis eines Repository lassen sich Abhängigkeiten von Anforderungen eines Projektes in Beziehung setzen. Sehr häufig werden als Quellen für Anforderungen lediglich Kunden oder Anwender gesehen. In der Praxis können Anforderungen aber von überall her kommen. Stellen Sie sich vor, die Leistung des eingesetzten Mikrocontrollers ist nicht mehr ausreichend. Es ist ein HW Re-Design geplant und in diesem Zusammenhang muss ein neuer Mikrocontroller ausgewählt werden. Was sind die Anforderungen für den MC ? In diesem Fall, in dem die SW wiederverwendet werden soll, kommen die Anforderungen im wesentlichen aus der Implementierung. Wurden im Repository die Abhängigkeiten der Software-Dokumentation zur genutzten Peripherie des MC definiert, dann lässt sich sehr schnell ein Dokument erstellen, in dem alle Peripherie-Elemente mit den Anforderungen aus der Software in Bezug zur MC Peripherie stehen.

Implementierung auf Basis eines RepositoryNun werden nicht alle Arbeitsschritte auf Basis textueller Informationen durchgeführt. Zum Beispiel wird Software programmiert oder modelliert. An dieser Stelle entstehen redundante Informationen zwischen Source-Code und Dokumentation. Auch diese Zusammenhänge und Abhängigkeiten lassen sich auf Basis eines Repository leichter verwalten.Modellierungswerkzeuge, auf Basis von UML zum Beispiel, ermöglichen Import und Synchronisation von Anforderungen in das Modell. Innerhalb des Modells können die Anforderungen (z.B. zur Dokumentation des Modells) direkt in einer Darstellung angezeigt werden, sie können aber auch mit Modellelementen verlinkt werden und im Fall der Codegenerierung als Kommentar in den Code übernommen werden. Das gleiche gilt auch für andere Werkzeuge, z.B. zur Erstellung von Regression Tests. Voraussetzung ist immer ein Repository. Auf Basis der Traceability eines Repository oder mehrerer verlinkter Repositories können folgende Analysen durchgeführt werden.

• Coverage Analyse - sind alle Anforderungen erfüllt • Impact Analyse - Analyse der Auswirkung möglicher Änderungen• Trace Analyse - Analyse der Ursache

Automatische Nachricht über ÄnderungenSind die Abhängigkeiten verschiedener Informationen im Repository definiert und hat jeder Stakeholder ein Dokument

mit seiner domänenspezifischen Sichtweise auf das System und anschließend ändert sich etwas im System, zu dem sein Dokument einen Bezug hat, dann wird in seinem Dokument ein so genannter Suspect Link angezeigt (Abbildung Nr 5). Mit einem Mausklick darauf kann er die Änderungen in angrenzenden Domänen nachverfolgen.Auf diese Weise werden alle entstehenden Inkonsistenten sichtbar und einfach nachverfolgbar gehalten. Eine wesentliche Voraussetzung, um die entsprechend der Domänen und Stakeholder redundanten Informationen untereinander konsistent zu halten.

Excellence im Engineering Seite - -3

Abbildung 5

Anforderungen an die WerkzeugeEiner der Hauptvorteile im Anforderungsmanagement liegt in der Traceability - Analyse der Abhängigkeiten und den daraus entstehenden Ansichten. In der Praxis gibt es häufig verschiedene Sichtweisen auf die Traceability (ist erfüllt durch, ist Testfall zu, wurde getestet, entspricht Norm ...). Diese sollten bei einer Analyse auch unterschieden werden können. Dazu müssen verschiedene Linkbeziehungen und deren mögliche Richtungen exakt vorgegeben werden (So genanntes Link Controle). Ist das nicht möglich, so geben die Analysen in der Regel bereits nach kurzer Zeit keine sinnvollen Aussagen mehr.Die Möglichkeit der Definition verschiedener Link - Arten und die exakte Vorgabe von Regeln zu deren Anwendung ist eines der wichtigsten Eigenschaften. Leider versagen an diesem Punkt schon sehr viele Werkzeuge.Flexible Darstellung der Repository-Inhalte mit guten Filtermöglich-keiten ist ein weiteres elementares Kriterium für ein gutes Werkzeug. Was hilft Ihnen das beste Repository, wenn die Informationen und deren Zusammenhänge nicht aussagekräftig dargestellt werden können. Vor allem Filterfunktionen werden nach einiger Zeit sehr wichtig. Fängt

Excellence im Engineering Seite - -4

Erster Schritt: Beschränken auf das WesentlicheWir empfehlen, sich im Rahmen der Einführung auf die wichtigsten Elemente im Anforderungs- Management zu konzentrieren. Das ist im Wesentlichen die Traceability von Anforderungen, Datenaus-tausch zu den wichtigsten Stakeholdern und Datensicherung.Es gibt natürlich weitere Aspekte. Die zukünftige Relevanz muss geklärt und deren Unterstützung zugesichert sein. Die Einführung kann aber nach und nach zu späteren Zeitpunkten geschehen.

Weitere SchritteTraceability über Werkzeuggrenzen hinweg

zu Modellierungswerkzeugen

zu Testwerkzeugen

in den Sourcecode

Daten Handover

Normengerechte Erzeugung von Dokumenten

Erzeugung von Dokumenten nach hausinternen Standards

Einstieg in Aplication Lifecycle Management. Definition Automatisierung von Prozessen

Change Management

Review Management

Test Management

Support Management

...

sich Ihr Repository an mit Daten zu füllen, dann wird es für aussagekräftige Darstellungen zunehmend wichtiger zu definieren, was NICHT angezeigt werden soll. Sie hätten ja gerne den Blick auf das Wesentliche. Auch an dieser Stelle versagen bereits viele Werkzeuge.Natürlich sind gute Import- und Export- Funktionen sehr hilfreich. Vor allem auch zu anderen Werkzeugen. Zu diesem Thema ist IBM® Jazz® eine interessante Entwicklung (http://jazz.net). Jazz® hat u.a. zum Ziel Repositories verschiedener Werkzeuge zu vereinheitlichen. Wenn sich Jazz® durchsetzen kann werden Probleme mit Daten-Import und -Export in Zukunft der Vergangenheit angehören.In Abbildung Nr. 6 sind mögliche Schnittstellen zu anderen Werkzeugen dargestellt. In Summe bildet sich dann aus allen Werkzeugen eine sogenannte ALM- (Application Livecycle Management) Lösung.Wer langfristig eine ALM - Lösung anstrebt sollte sich frühzeitig um die notwendigen Interfaces seiner Werkzeuge kümmern und bei Toolentscheidungen entsprechend berücksichtigen.Nicht alle Werkzeuge können ideal kombiniert werden. Hier gibt es mehr oder weniger gute Schnittstellen zwischen den verschiedenen Werkzeugen.

Excellence im Engineering Seite - -5

Abbildung Nr. 6: Exemplarische Darstellung einer durchgängigen Traceability über den gesamten Zyklus des V-Modells auf Basis von IBM Rational-Produkten.

Was ist ALM Application Lifecycle Management (also known as Application Management) is a continuous process of managing the life of an application through governance, development and maintenance. ALM is the marriage of business management to software engineering made possible by tools that facilitate and integrate requirements management, architecture, coding, testing, tracking, and release management.

Vom Requirements Engineering zum Application Lifecycle Management (ALM)Bisher haben wir im wesentlichen einen Blick auf die statische Darstellung, die Aussagen und Informationen zu einem System und die Darstellung und deren Zusammenhänge geworfen.Dahinter liegt jedoch immer ein Vorgehen, beziehungsweise die dynamische Sicht auf den Verlauf der Arbeitsschritte zur Entwicklung des Systems. Ein Beispiel dazu haben wir bereits gesehen, es sind die Suspect Links. Ein noch besseres Beispiel sind Testfälle. In der statischen Sicht sehen wir, dass zu einer Anforderung ein Testfall existiert. Aber wir sehen noch nicht das Ergebnis der Ausführung des Testfalls. Bzw. sehen wir nicht, ob der Testfall nach einer Änderung der Anforderung und deren Implementation erneut ausgeführt wurde. Neben der bereits besprochenen Darstellung der Traceability gibt es also noch weitere Zusammenhänge aus Sicht der dynamischen Abläufe von Tätigkeiten, die zu einem strukturierten Vorgehen gehören.Gerade in Projekten, die für den Einsatz der Systeme in sicherheits-relevanten Bereichen zertifiziert werden müssen ist die dynamische Sicht sehr wichtig. Dort müssen unter anderem bestimmte Arbeitsschritte (z.B. Reviews) protokolliert und abgezeichnet werden. Oder es muss sichergestellt werden, dass nach bestimmten Tätigkeiten andere Tätigkeiten durchgeführt werden (z.B. nach Änderungen in der Implementation die Tests erneut durchlaufen werden).In der Praxis gibt es viele weitere Gründe (nicht nur in der Entwicklung im Bereich Safety und Secure) auch die dynamschien Vorgänge zu definieren. Z.B. wenn sichergestellt werden soll, dass Systemerweiterungen erst entwickelt werden, wenn bestimmte Stakeholder diese abgezeichnet haben. Vorgehen wie Scrum, aber auch Change Management, Defect Management .... lassen sich effizienter gestalten, wenn der darin enthaltene Prozess definiert und die Abläufe von einem Werkzeug automatisiert werden. Die Tool-gestützte Definition nennt sich dann ALM-Lösung.So genannte ALM-Lösungen können auch die dynamische Ebene auf das Anforderungs-Management darstellen. Dazu werden zusätzlich zu den Anforderungen ToDo‘s oder Workitems verschiedenster Art herangezogen.Nun können auf dieser Basis Arbeitsabläufe (Prozesse) und deren Abhängigkeiten definiert werden. Z.B. nach jeder Änderung einer Anforderung wird automatisch ein Workitem als Aufgabe für die Entwicklung erzeugt. Nachdem dieses abgearbeitet wurde, wird ein Workitem für die Durchführung eines Testfalles erzeugt.Diese Workitems werden an die statische Struktur des Systems gekoppelt, damit ist der System- Kontext des Workitem direkt sichtbar und muss nicht aufwändig beschrieben werden. Der Fortschritt der Entwicklung kann auf diese Art sehr gut verfolgt werden, Zeitabschätzungen werden realistischer.Auch hier hilft ein Repository den administrativen Aufwand gering zu halten. Eine wichtige Vorraussetzung dafür, dass der Nutzen größer ist als der Aufwand. Trotzdem ist der Aufwand zur Einrichtung des Workflow nicht zu unterschätzen. Hier sollten je nach Vorbedingungen auf Werkzeug und Komplexität 3 bis 10 Tage veranschlagt werden. Es gibt auch Werkzeuge die einen Workflow vorgeben, hier ist der Aufwand der Einführung gering, jedoch ist die Flexibilität eingeschränkt.

Excellence im Engineering Seite - -6

Abbildung 7

Klassische Anforderungsmanagement-Werkzeuge z.B. IBM® Rational® DOORS® bedienen vorrangig die statische Darstellung. Neuere Werkzeuge z.B. Polarion bedienen beide Darstellungen. Parallel gibt es spezialisierte Werkzeuge, die nur die dynamische Sicht des Workflow bedienen, z.B. IBM® Rational® Team Concert®. Nachfolgend geben wir Ihnen einen groben Überblick über die Lösungen, die Willert Software Tools unter diesen Gesichtspunkten anbietet.

Normen, Staat und Rechtsprechung als StakeholderNicht nur in Bereichen, in denen die Verursachung von größeren Schäden bei Fehlverhalten eines Systems offensichtlich ist, werden heutzutage Sicherheitsnormen angewandt. Längst hat die EU die IEC 61508 als Standard für die Entwicklung von Produkten und Systemen deklariert. Kommt es durch den Einsatz eines Produktes oder Systems zu einem Schaden, dann wird im Fall einer gerichtlichen Auseinandersetzung die 61508 herangezogen und nachträglich beurteilt, ob das Produkt am Stand der Technik orientiert und mit ausreichender Sorgfalt entwickelt und produziert wurde. Auch bei der Stakeholder- Analyse im Rahmen des Anforderungsmanagements sollte der Staat oder die EU nicht vergessen werden; häufiger als erwartet wird hier zukünftig eine Sicherheitsnorm Berücksichtigung finden, z.B. die neue Automotive-Norm ISO 26262.Im Umfeld des Anforderungsmanagements spielen Normen in doppelter Hinsicht eine wesentliche Rolle. 1. Beinhalten die Normen Anforderungen über das Anforderungs-

Management an sich, vor allem im Bereich der Traceability (Nachverfolgbarkeit).

2. Sind sie dabei selber als Anforderung zu sehen und müssen in die Traceability mit einbezogen werden.

Das bedeutet, dass sie als Anforderungen auch im Anforderungs- management-Werkzeug vorhanden sein sollten. Hier kann das Werkzeug RiskCAT sehr hilfreich sein.

Umgang mit Normen erleichternDie IEC 61508 gibt mehrere hundert Maßnahmen vor, die während des Entwicklungsprozesses von sicherheitskritischen Systemen angewendet werden können. Die meisten anderen Industrienormen sind von der IEC 61508 abgeleitet und nicht weniger umfangreich. Wie verbindlich diese Maßnahmen sind, hängt davon ab, mit welchem Risiko der Betrieb des Systems verbunden ist, was durch den Safety- Integrity-Level (SIL) angegeben wird. RiskCAT hilft auf Basis der Be- rechnung des SIL, die Spreu vom Weizen zu trennen und die Inhalte der Normen auf die individuellen Anforderungen des zu entwickeln- den Systems zu skalieren.Systematischer Zugang zu den Maßnahmen der Normadd4QAuf dieser Basis können automatisiert Traceability-Analysen durchgeführt und zusammenhängende Dokumente und ihre Beziehungen in hoher Granularität durch DOORS® oder Polarion® automatisch erstellt werden. Diese Dokumente bieten optimale Voraussetzungen für eine Zertifizierung gegen die zu erfüllende Norm. RiskCAT ist verfügbar für alle gängigen Sicherheitsnormen.

Excellence im Engineering Seite - -7

ISO 26262 Die ISO 26262 („Road vehicles – Functional safety“) ist eine entstehende ISO-Norm für sicher-heitsrelevante elektronische Systeme in Kraftfahrzeugen. Die ISO 26262 wird ein Prozess-Rahmenwerk und Vorgehensmodell zusammen mit geforderten Aktivitäten und Arbeitsprodukten, sowie anzuwendenden Methoden definieren. Die Umsetzung der Norm soll die funktionale Sicherheit eines elektrischen/elektronischen Systems im Kraftfahrzeug gewährleisten. Damit ist die kommende Norm eine Ableitung der IEC 61508 an die spezifischen Gegebenheiten im Automobilbereich.

Im Juli 2009 wurde die ISO 26262 als Draft International Standard (DIS, Baseline 15) veröffentlicht. Den an der Normierung beteiligten Gremienmitgliedern liegen zwischenzeitlich die Baselines 16 und 17 in englischer Sprache vor; diese dienen zur Vorbereitung auf den Final Draft International Standard (FDIS) (Veröffentlichung im Dezember 2010). Die ISO 26262 wird von der ISO-Arbeitsgruppe „ISO TC22/SC3/WG16“ bearbeitet. Die Veröffentlichung als internationaler Standard ist für Mitte 2011 vorgesehen. Die an der Normierung beteiligten Mitglieder verwenden die Entwürfe der ISO 26262 bereits zum Teil.

Lösungen, die Willert Software Tools liefert

Excellence im Engineering Seite - -8

Lösung Haupt-Einsatzgebiet Einführung

IBM® Rational®

DOORS®

Die klassische Lösung für Requirements Engineering. Die Oberfläche für die Anwender ist ähnlich einer Mischung aus Textverarbeitungs- und Tabellenkalkulations- Applikation. Dadurch ist die Einarbeitung für die Anwender einfach, was sich sehr positiv auf die Akzeptanz auswirkt. Auch die Traceability wird in Anlehnung an Dokumente dargestellt. Link-Controle gewährt langfristig saubere Traceability -Analysen. DOORS® ist eines der ältesten Werkzeuge dieser Art und ist dadurch stark im Markt vertreten. Das gewährt Betriebsbewährtheit und hervorragende Unterstützung in nahezu allen Bereichen. Auch Schnittstellen zu verschiedensten Werkzeugen bis hin zu SAP ist bei DOORS® sehr gut gewährleistet.Einer der größten Vorteile von DOORS® ist die Abbildung von Lieferanten-Ketten (Suplier Chain) auf Basis der Exchange Erweiterung. (Kostenpflichtige Erweiterung)DOORS® beinhaltet jedoch nur rudimentäre ALM -Funktionalität. Um ALM vollständig abbilden zu können kann es z.B. mit IBM Rational Team Concert ergänzt werden.

Durchschnittliche Kosten für die Ausstattung eines Arbeitsplatzes mit DOORS ca. 3.000 - 5.000,- € je nach Lizenzart und Funktions-umfang.1 Tag Schulung für Anwender2 Tage Schulung für sogenannte Power User (Anwender mit Administrationsfähigkeiten)2 - 4 Tage Anpassung, Konfiguration und Einführung, wenn die ersten Schritte durch einen erfahrenen Coach unterstützt werden.

Polarion® ALM

Polarion® ist eine der umfangreichsten und flexibelsten Werkzeuge, die sowohl Requirements Engineering als auch ALM unterstützen und parallel noch ein Wiki bereit hält, in dem der Zugang in das System für die Anwender sehr einfach gestaltet und dokumentiert werden kann.Polarion® beinhaltet alles, was eine gute Lösung benötigt, dokumentenorientierte Darstellung, Linkcontrole, umfangreiche Traceability-Möglichkeiten, Abbildung und Automatisierung von Prozessen und Workitems als Einstiege in eine ALM-Lösung. Synchronisation zu Word-Dokumenten vereinfacht die Integration von Stakeholdern, die nicht mit einem Req. -Werkzeug arbeiten wollen.Polarion® ist sehr flexibel an die verschiedensten Anforderungen anpassbar, dieser Vorteil ist auch gleichzeitig der größte Nachteil. Bei der Einführung kann es zur Erfindung der Eierlegendenwollmilchsau verleiten. Keep it simple sollte hier das Motto sein.

Durchschnittliche Kosten für die Ausstattung eines Arbeitsplatzes mit Polarion ca. 2.000 - 4.000,- € je nach Lizenzart und Funktions-umfang.1 Tag Schulung für Anwender2 Tage Schulung für sogenannte Power User (Anwender mit Administrationsfähigkeiten)Je nach Grad der Einführung 2 - 10 Tage Anpassung, Konfiguration und Einführung, wenn die ersten Schritte durch einen erfahrenen Coach unterstützt werden.

Excellence im Engineering Seite - -9

Willert Software Tools liefert auch Werkzeuge zur Erweiterung der Requirement Engineering Werkzeuge zu ALM -Lösungen

IBM Rational Rhapsody, Sparx Enterprise Architect (Modellierung von Anforderungen in Form von UML-Diagrammen)

IBM Rational Quality Manager (Zur Überführung von Anforderungen in Testdaten und Testfälle.)

RiskCAT (Tailoring von Normen und Aufbereitung zum Digitalen Import in Req. Engineering- lösungen)

IBM Rational Team Concert (ALM Lösung)

IBM Rational Test Realtime

Best Practice: Evaluierung

Training und Coaching

Ein Tag PowerUser Training.

Ein Tag Coaching zur Erstellung eines einfachen Datenbank-Schemas.

Ein bis zwei Tage Coaching zur Umsetzung des Schemas.

Eigenes Arbeiten

Ein bis zwei Tage vollständige Umsetzung des Schemas.

Schulung der Anwender

Ein Tag Kombination Schulung und Coaching der Anwender des Tools auf Basis des projektspezifischen Repository.

Praktischer Einsatz von Tools in einem möglichst realen Projekt

2-3 Wochen Einsatz der Lösung.

Repository, Interfaces, SonstigesDOORS® speichert seine Daten in einem eigenen Repository. Synchronisationen des Repository zu anderen Werkzeugen sind in vielfältiger Weise möglich. • Auf Basis des IBM Gateway zu verschiedenen Modellierungs-

Werkzeugen.• Auf Basis von Open PDM zu verschiedenen CAD Verwaltungs-

und PDM (Produkt Daten Management) - Lösungen u.a. auch zu SAP. (Weitere Informationen http://www.prostep.com/unsere-produkte/openpdm)

• Auf Basis von agosense.symphony zu verschiedenen Third Party ALM-Tools.

Auf Basis der IBM® Jazz® Technologie werden Schnittstellen zu den IBM® Rational® Produkten unterstützt wie RQM, RTC ... mit denen DOORS® zu einer vollständigen ALM-Lösung ausgebaut werden kann.Die DOORS®-Applikation kommt als Windows-Oberfläche. Parallel gibt es ein Web Frontend, das aber nur rudimentäre Funktionen unterstützt und eher zum Review von Anforderungen gedacht ist.

Polarion speichert seine Daten direkt in Subversion. Das hat verschiedene Vorteile. Zum Beispiel ist ein einfacher Zugang zu den Daten auch ohne Polarion Frontend möglich. Wird Subversion auch für die Verwaltung des Source Code genutzt, kann auf Basis von Tags in den Commit-Texten die Traceability zum Sourcecode gewährleistet werden.Im Vergleich zu DOORS® deckt Polarion neben dem eigentlichen Anforderungsmanagement und den statischen Sichten auch den dahinter liegenden dynamischen Workflow ab. Damit lässt sich z.B. der Nachweis von Reviews oder die Durchführung von Tests organisieren und dokumentieren.Interfaces zu anderen Werkzeugen werden teilweise durch Polarion selber, aber auch von Fremdanbietern unterstützt, z.B. durch ,agosense.symphony‘ zu verschiedenen Third Party Test -Management, Modellierungs- und Change-Management -Werkzeugen.Die Bedienoberfläche von Polarion® ist ein Web Frontend.

Einstieg: Best Practice zur Einführung von Requirements Management Der Nutzen im Anforderungs-Management liegt im Wesentlichen in der Traceability von Abhängigkeiten unter verschiedenen Gesichtspunkten in einem Projekt oder auch projektübergreifend. Leider ist auch mit dem besten Tool die Aussage einer Analyse nur so gut, wie die Struktur der Daten, auf dessen Basis die Analyse durchgeführt wird. Sehr häufig kann der Nutzen im Bereich Anforderungs-Management trotz Einsatz eines guten Werkzeugs nicht erzielt werden, weil bei der Einführung des Werkzeugs die Struktur des Repository nicht weitsichtig genug angelegt wurde.Um das volle Potential aus Anforderungs-Management in Verbindung mit einem Tool nutzen zu können ist das Aufsetzen der Struktur des Repository die wichtigste Voraussetzung. Wir empfehlen, den Inhalt der Evaluierung darauf zu konzentrieren. IBM® Rational® DOORS® oder Polarion z.B. besitzen mit ,Link Controle‘ ein mächtiges Konzept für ein sauberes Design, das jedoch etwas Einarbeitung erfordert, Schulung und Coaching ist aus unserer Sicht im Rahmen einer Einführung unerlässlich.

Von Dokumenten zum RepositoryZur Einführung eines Repository zur Speicherung und Strukturierung aller projektrelevanten Informationen sind auf Basis eines geeigneten Anforderungsmanagement-Werkzeuges folgende Schritte erforderlich:3. Anpassung der Struktur des Repository auf die Vorgehensweise und die Informationen des Unternehmens (Erstellung

eines so genannten Datenbank-Schemas)4. Definition und Erstellung von Darstellungen und Ansichten der Repository-Inhalte für die verschiedenen Fachdomänen

bzw. Stakeholder5. Evtl. Import vorhandener Dokumente in das Repository6. Definition der Abhängigkeiten7. Evtl. Export der Daten in übliche Dokumente für Stakeholder, die nicht mit dem Werkzeug arbeiten8. Schulung des Teams im Umgang mit Methode und WerkzeugFür die Durchführung der obigen Schritte werden folgende Kenntnisse und Aufwand benötigt:Für die Erstellung eines Datenbank-Schemas muss mit einigen Tagen gerechnet werden. Beim ersten Mal sollte hier auf jeden Fall die Unterstützung eines Experten herangezogen werden. Das Datenbank-Schema ist das Gerüst des Repository. Bei der Erstellung müssen bereits im Vorfeld mögliche zukünftige Analysen und Darstellungen berücksichtigt werden, die evtl. erst im Verlauf des Projektes interessant werden. Das geht nur mit Erfahrung. Für die Erstellung der domänenspezifischen Ansichten (Views) müssen ein bis zwei Tage Aufwand gerechnet werden. Auch hierfür ist beim ersten Mal die Unterstützung durch einen Experten hilfreich.In der Regel liegen bereits Dokumente mit Informationen vor. Gut strukturierte Dokumente lassen sich mit modernen Anforderungsmanagement - Werkzeugen sehr einfach automatisch importieren. Schlecht strukturierte Dokumente müssen vorher strukturiert werden. (GIGO - Garbage in Garbage out). Auf Basis von Styles bzw. Formatvorlagen sind hier pro Seite ca. ein bis drei Minuten zu rechnen, wenn die Inhalte nicht verändert werden müssen.Die Definition der Abhängigkeiten empfiehlt sich im Verlauf des Projektes nach und nach durchzuführen. Der Vorgang an sich ist sehr einfach. Innerhalb einiger Monate sind die wichtigsten Abhängigkeiten in der Regel definiert. (Voraus- gesetzt das Team hat den Nutzen erkannt, wird in der Praxis fleißig verlinkt)Inhalte aus dem Repository lassen sich sehr einfach in RTF, MS Word® oder HTML Dokumente exportieren. Etwas schwieriger wird es, wenn die Dokumente festgelegte Formate und Inhalte haben müssen. Dann wird auch hier entsprechender Aufwand, z.B. die Erstellung einer MS Word - Vorlage, notwendig sein.Last but not least bleibt die Schulung des Teams. Grundsätzlich wird zwischen Anwendern (Usern) und so genannten Power Usern unterschieden. Die Bedienung der meisten Werkzeuge ist heute nicht viel schwieriger, als die Bedienung einer Tabellenkalkulation. Ein Tag Schulung ist hierfür in der Regel ausreichend. Voraussetzung ist, dass das System konfiguriert und eingerichtet ist.Ein bis zwei Mitarbeiter im Unternehmen sollten auch dafür die Kenntnisse besitzen. Hier sind 2 - 4 Tage Kombination aus Schulung und Coaching notwendig.In Summe sollte zur Einführung eines Anforderungsmanagement Systems mit 5 - 10 Tagen Aufwand, und das gleiche noch einmal für die ALM-Lösungen einkalkuliert werden.

Excellence im Engineering Seite - -10

Requirements Start-up TrainingDiese Schulung ist an Personen gerichtet, die mit Dokumenten-zentrischem Anforderungsmanagement zunehmend an Grenzen stoßen und zu Repository-zentrischem Anforderungsmanagement umsteigen möchten.In der Schulung wird gezeigt, wie das Management von Zusammenhängen in komplexen Systemen und Projekten auf Basis eines Repository‘s im Vergleich zu Dokumenten wesentlich vereinfacht werden kann.Dazu werden Elemente wie Workitem, Attribute, Views, Linking, Impact Analysen und viele weitere erklärt.Auf Basis des Anforderungsmanagement -Tools IBM® Rational® DOORS® werden die wichtigsten Funktionen in eigenständigen Übungen durchgeführt. Am Ende hat jeder Seminarteilnehmer ein eigenes Repository erstellt und kann sicher abschätzen:

• Was die Vorteile gegenüber Dokumenten Zentrischem Anforderungs-Management sind.

• Wie die eigenen Anforderungen an eine Anforderungs- Management-Lösung sind.

• Welche Anforderungen daraus an ein Werkzeug gestellt werden müssen.

• Mit welchem Aufwand die Einführung von Repository-zentrischem Anforderungsmanagement im eigenen Unternehmen verbunden ist.

Das Seminar vermittelt Basis-Kenntnisse zur konkreten Einführung einer Anforderungs-Management-Lösung incl. dem Ausbau zu einer kompletten ALM-Lösung. Es kann sehr gut als Grundlage zur Entscheidungsfindung, ob Repository- zentrisches Anforderungsmanagement auf Basis eines Werkzeuges gewinnbringend im eigenen Projekt eingeführt werden kann, genutzt werden und bietet eine ideale Grundlage für eine sichere Werkzeugentscheidung.Inhalte :

Aufzeigen von aktuellen Problemen beim Dokumenten-zentrischen Vorgehen im Anforderungsmanagement und deren Lösungen mit einem Repository und Werkzeug

Einführung in die Basis - Elemente des Anforderungsmanagements exemplarisch auf Basis von DOORS®

Struktur des Repository, Rechte, Folder, Projekte ...

Struktur von Anforderungen, Module, Objekte, Attribute ...

Link Controle, Linkbeziehungen, Linkmodule, Linksetparing

Darstellung und Analyse der Anforderungen, Views, Filter, Impact Analysen, Trace

Import und Export von Daten, von und zu RTF (Word), HTML, Spreadsheet (Excel)

Zeitliche Sicht auf Anforderungen, Baselining

Erstellung von Templates, Schema, Archiven und Datensicherung

Excellence im Engineering Seite - -11

Erforderliche Kenntnisse des PersonalsFür eine erfolgreiche Einführung von Anforderungsmanagement sind bestimmte Kenntnisse erforderlich. Wir unterscheiden im Bereich der Mitarbeiter zwischen folgenden Personengruppen und Kenntnisständen:

IT-Administrator

Der Administrator arbeitet selber nicht mit dem Req. Eng. Tool, er übernimmt lediglich die Installation der einzelnen Komponenten in der EDV Infrastruktur. Kenntnisse eines erfahrenen IT-Administrators sind hierfür erforderlich und ausreichend. Es werden keine spezifischen Tool-Kenntnisse benötigt.

PowerUser

Sind alle zum Betrieb Req. Eng. Tools notwendigen Komponenten installiert, wird die Struktur des Repository eingerichtet und das Tool entsprechend individueller Anforderungen konfiguriert., z.B. User und deren Rechte. Dieses muss in der Regel nur einmal am Anfang eines Projektes durchgeführt werden. Hierfür sind Kenntnisse erforderlich, die über die Nutzung der Tools im Alltag hinausgehen. Diese Kenntnisse werden nicht von jedem Anwender benötigt. Es ist ausreichend, wenn ein bis zwei Mitarbeiter eines Unternehmens diese Kenntnisse haben. Diese werden als so genannte PowerUser bezeichnet.

User

Ist das Repository einmal eingerichtet, dann ist der Umgang mit dem Req. Eng. Tool sehr einfach. Die Bedienung ähnelt einer Mischung aus Textverarbeitung und Tabellenkalkulation. Die eigentlichen Anwender kommen in der Regel nach wenigen Stunden mit den wichtigsten Elementen zur Bedienung zurecht. Voraussetzung dafür ist, dass das Repository orientiert an den Projekt- und Anwender-Anforderungen vollständig eingerichtet wurde.

Kursdauer:1 Tag / 9.00 - 17.00 Uhr

Preis:750,- € je Teilnehmer

Termine + Anmeldung:willert.de/events

Excellence im Engineering Seite - -12

Autor:

ANDREAS WILLERT

Herausgeber:

WILLERT SOFTWARE TOOLS GMBH

Hannoversche Straße 2131675 Bückeburgwww.willert.deinfo@willert.deTel.: +49 5722 9678 - 60

Weitere Trainings und Schulungen bei Willert:

■ EMBEDDED UML START-UP TRAININGS 1. Hands-on exercises based on Rational® Rhapsody® in C 2. Hands-on exercises based on SPARX Systems® Enterprise Architect

■ SOFTWARE ARCHITEKTUR & DESIGN für Embedded Systeme / Workshop

Interessiert an einer Schulung zu diesem Thema?

■ REQUIREMENTS ENGINEERING START-UP TRAININGS Hands-on exercises based on 1. IBM® Rational® DOORS® 2. Polarion®