IT-Technologie im Branchenfocus tikal...Grafische Modellierung der Anforde- simulation mit UML 2.0 Arcway AG: Requirements in der Früh rungen von Elektronik-Systemen im phase: Ergebnisorientierte

Ver

tika

l I T- Te c h n o l o g i e i m B r a n c h e n f o c u s

Ausgabe 2 | 2006

AutomotiveAnforderungsmanagement in der Automobilbranche

! Vertikal Einleitung_News 31.01.2006 13:46 Uhr Seite 1

Automotive

Analysen zeigen: viele Software-Projekte scheitern nicht aus technischen Gründen, son-dern weil das Management der Anforderungen und die Kommunikation – im Team und mitden Kunden – nicht optimal funktioniert.

Entscheiden Sie sich für IrqA –Requirements-Management so individuell wie Ihre Anforderungen!

Die große Stärke von IRqA: das Requirements-Management kann ganz individuell aufIhre Anforderungen angepasst werden. Ob beim Sichten, Abfragen, bei Mehrsprachig-keiten und vielem anderem mehr ... IRqA läßt kaum individuelle Wünsche offen.

Ihre Mitarbeiter und Kollegen im Team werden IRqA lieben. Ihre Kunden werden Sie dafür schätzen!

• Modellierung (object-orientierte und strukturierte Methode)• Testszenarien-Management• Reporting und Metrikauswertungen• Grafische Navigation und Darstellung von Projekten, Workflows und Strukturen • DOORS, CALIBER, ReqPRO Datenaustausch/Migrations-Tool mit Change Management• lauffähig auf allen marktgängigen Datenbanksystemen

Mehr dazu im Internet: www.qasystems.de

www.qasystems.de

IRQA – Anforderungsmanagement – Bessere Software ist einfach… besser.

QA Systems GmbH • Schwieberdinger Straße 56 • D-70435 Stuttgart • Tel +49 (0)711 / 13 81 83 - 0 • Fax +49 (0)711 / 13 81 83 - 10 • [email protected] • www.qasystems.de

Anforderungsmanagement fest im Griff


Automotive

Anforderungsmanagement in der Auto-mobilbranche ist ein Thema, das nicht nurspannend ist, sondern vor einer Vielzahlvon Herausforderungen geprägt ist, dienoch lange nicht gelöst sind, auch wenndie Automobilbranche sicherlich mit zuden Vorreitern im Anforderungsmanage-ment zu sehen ist.

Aber auch andere Branchen erkennen zunehmend die Bedeutungdes Themas Anforderungsmanagements – es hat sich gezeigt, dasshier ein erhebliches Potential zur Steigerung der Softwarequalität,Steigerung der Kundenzufriedenheit und Fehlervermeidung vor-liegt.

In diesem Sonderheft möchte wir Ihnen zunächst die REConf2006 vorstellen, eine Konferenz vom 7. bis 8. März in München,die sich ausschließlich mit dem Thema Anforderungsmanage-ment auseinandersetzt. Ferner werden wir einige neue Ansätze imAnforderungsmanagement und neue Produkte, die auf demMarkt verfügbar sind, darstellen, bevor wir die etablierten Werk-zeuge behandeln. Schwerpunkt dieses Sonderheftes bildet dasThema Anforderungsmanagement und Testen, das wir in dreiBeiträgen beleuchten.

Ich würde mich freuen, Sie auf der REConf 2006 begrüßen zudürfen und wünsche Ihnen viel Spaß beim Lesen dieses Sonder-heftes unseres Mediasponsor manage it.

Ihr Colin Hood

Vertikal 2|2006 3

4 Requirements Management & EngineeringDie REConf 2006

10 Interview mit Andreas Ditze, Leiter des Product Management Boards der MID

12 Requirements Management & EngineeringMessbare Qualität in Anforderungsdokumenten

17 SourceForge endlich auch in Deutschland

18 Das ”Warum” ist meist klar, das ”Wie” häufig nichtRe-wissen.de

19 Definieren und Modellieren statt ProgrammierenEinführung eines Assessment tauglichenAnforderungs-Managements mit IRqA

22 Anforderungsmanagement und TestenDie imbus TestBench – ein iterativerProzess

27 Anforderungsmanagement und TestenMID hilft ihren Kunden auch beim Testen

28 Anforderungsmanagement und TestenWenn die Wirtschaftlichkeit im Vordergrund steht ...

31 Vernetztes Anforderungsmanagement & EngineeringModerne Software-Entwicklung für die Automobil-Branche

34 Neue Produkte im AnforderungsmanagementDefinieren und Modellieren statt Programmieren

37 Enterprise Resource PlanningPassende Lösung PARAT

39 Neue Produkte im AnforderungsmanagementNeue Ansätze im Anforderungsmanagement

42 Vernetztes Anforderungsmanagement & EngineeringAutobahnnetz oder Landstraße

44 Anforderungsmanagement – etablierte ProduktePrioritäten setzen auf der Wunschliste

Themen


er Einsatz von RequirementsManagement & Engineering istein essentieller Baustein großer,

weltweit tätiger Konzerne für erfolgreicheEntwicklung komplexer Produkte, Dienst-leistungen und Systeme. Branchen wiedie Luft- und Raumfahrtindustrie, dieTelekommunikations- oder die Automo-bilindustrie profitieren beim Einsatzschon seit längerem von Effizienzsteige-rungen durch den Einsatz von RM&E-Methoden. Aber auch die übrigen Bran-chen lernen zunehmend die Vorteile einesprofessionellen Anforderungsmanage-ments kennen.

Es gibt derzeit immer mehr Veranstal-tungen zu immer mehr Themengebieten(und auch Randgebieten) innerhalb desSoftware-Engineerings. Dies findet seineBegründung darin, dass die großen the-menübergreifenden Messen, wie zumBeispiel die Systems und die CeBIT vonimmer mehr Unternehmen nicht mehrbesucht werden. Ursache ist, dass hier zuviele Streuverluste vorliegen und der sogenannte Cost per Lead zu groß ist.

Daher konzentrieren sich die meistenUnternehmen zu Recht auf spezialisierteFachkongresse wie die REConf. DieseTagung findet nun bereits zum fünftenMal statt. Neben den technisch orientier-ten Branchen kommt Anforderungs-management immer mehr auch imFinanzdienstleistungs- und Logistikbe-reich sowie Medicalbereich zum Einsatz.Die REConf soll für die Interessenten,die bereits RM&E einsetzen eine weitereVertiefung bieten. Wir wollen aber auchTeilnehmern aus Branchen, in denendiese Thematik noch nicht so weit ver-breitet ist, die Möglichkeit bieten, sichüber Methodik, Erfolge und Hürden beider Einführung zu informieren.

Alleine die BMW Group wird vier An-wenderberichte halten, DaimlerChryslerund Volkswagen sind mit drei Vorträgenvertreten – aber auch die Zulieferer enga-gieren sich zunehmend bei diesem Kon-gress, Siemens VDO, Knorr Bremse undBosch berichten über Ihre Erfahrungenim Bereich Anforderungsmanagement.

Parallel zu den Anwenderberichten fin-den Methodenvorträge von anerkanntenKoryphäen wie zum Beispiel Colin Hoododer Bernd Oestereich statt. Der metho-dische Schwerpunkt der Konferenz liegtdieses Jahr beim "Spezifizieren undModellieren von Anforderungen".

Mit großer Spannung wird die Key-note von dem Träger der Benz-Daimler-Maybach-Medaille Christian Trowitzscherwartet. Der ehemalige Entwicklungs-leiter Elektronik der Hella KGaA Hueck& Co. berichtet über "Kürzere Lebens-zyklen von Elektronik und deren Konse-quenzen."

Des weiteren wird Prof. Dr.-Ing.Siegfried Wendt, Gründungsrektor desHasso-Plattner-Institutes, eine Keynotezum Thema: "Sehen und Verstehen –Bauzeichnungen für Gedankengebäude"halten. Ebenfalls von großem Interessewird der Beitrag der HIS-Group (Her-steller Initiative Software) sein. In einemeigenen Slot wird über die aktuellenArbeiten am RM-Tool-unabhängigen

Automotive

Vertikal 2|20064

Requirements Management & Engineering

Die REConf 2006 –Europas größte Konferenz zum Thema Anforderungsmanagement

D

! Vertikal Artikel 31.01.2006 13:52 Uhr Seite 4

Automotive

Vertikal 2|2006 5

Austausch von Anforderungsinformationüber Firmengrenzen hinweg berichtet.Besonders hier werden sowohl die OEMsals auch die Zulieferer eng mit eingebun-den."Wir legen großen Wert darauf, dass unsereTeilnehmer über Praxisberichte von ande-ren Unternehmen Erfahrungen imAnforderungsmanagement vermittelt be-kommen," so Rupert Wiebel, Geschäfts-führer der Hood GmbH. "Mit dem dies-jährigen Programm konnten wir das Niveaudes Kongresses erneut steigern, worauf wirsehr stolz sind."

Die Tagung gliedert sich in zweiTeile: In zwei Workshoptage am 6. und9. März 2006 und in die beiden Kon-ferenztage vom 7. - 8. März 2006. EineAusstellung von Werkzeugherstellern undDienstleistern auf dem Gebiet des Anfor-derungsmanagements findet parallel statt,Seite 9 zeigt, wer alles (Stand 14. Januar2006) als Sponsor oder Aussteller vertre-ten sein wird. Die REConf findet im nh Hotel in München/Dornach statt.Erwartet werden rund 500 Teilnehmer.Erstmals in diesem Jahr werden in dreiparallelen Tracks Anwenderberichte undMethodenvorträge gehalten (Siehe auchAgenda auf den Folgeseiten).

Das typische Besucherprofil derREConf sieht wie folgt aus:

[[ Personen, die Anforderungen formu-lieren (Fachabteilung und IT Abtei-lung)

[[ Personen, die Anforderungen model-lieren

[[ Personen, die Anforderungen testen[[ Personen, die ein Anforderungsma-

nagementwerkzeug suchen[[ Personen, die Unterstützung bei der

Einführung eines Anforderungsmana-gementprozesses suchen

[[ Personen, die sich über Erfolge und Misserfolge anderer Unternehmen bei der Einführung von Anforderungs-management informieren wollen

[[ Personen, die sich über die Integrationvon Anforderungsmanagement im Gesamtprozess der Software Entwick-lung informieren wollen

Historie der REConf

Im Jahr 2002 wurde zum ersten Mal die REConf durchgeführt – zu diesemZeitpunkt setzte sich das Auditorium noch aus einigen wenigen Spezialis-ten zusammen. Bereits im folgenden Jahr war ein klarer Trend in RichtungAutomobilbranche zu erkennen. Waren 2003 noch in erster Linie die Auto-mobilhersteller selber vertreten, so waren in 2004 bei der 3. REConf bereitseine Vielzahl von Zulieferern anwesend. Dementsprechend positiv hatsich auch die Teilnehmer-zahl über die einzelnenVeranstaltungen hinwegentwickelt, wie der Abbil-dung zu entnehmen ist.Für die REConf 2006 wer-den bis zu 500 Teilnehmererwartet.

Seit dem Jahr 2003 wurde damit begonnen, in einer PreConference, dieam Tag vor der Hauptkonferenz durchgeführt wird, Workshops anzubie-ten. Diese Workshops haben einen direkten Bezug zum Thema Anforde-rungsmanagement. Auch bei der Buchung der Workshops konnte ein ver-gleichbaren Anstieg festgestellt werden, wie bei der Teilnehmerzahl derHauptkonferenz, wie aus der nächsten Abbildung zu erkennen ist. Auf der

REConf 2006 wird nichtnur eine PreConferencemit Workshops stattfin-den, sondern am Tag nachder Hauptkonferenz einzusätzlicher Workshoptag– sozusagen als Post-Conference.

Auch die IT Branche hat auf diesen Trend reagiert, so wurden vonKonferenz zu Konferenz mehr Aussteller und Sponsoren registriert.Waren zunächst nur die vier relevanten Werkzeughersteller auf derREConf vertreten, so interessieren sich nun zunehmend Hersteller undDienstleistungsanbieter aus dem Umfeld des Requirements Engineeringfür die Konferenz. Für dieREConf 2006 konnte dieAnzahl der Sponsorenund Aussteller erneut umüber 30% gesteigert wer-den.


Workshops auf der REConf 2006Bereits am 6. März 2006 finden in einerPreConference eine Vielzahl von halbtä-gigen Workshops (siehe Tabelle S. 7) rundum das Thema Anforderungsmanage-ment statt. Eine detaillierte Beschreibungder einzelnen Workshops hinsichtlichInhalte, Agenda, Anforderungen, Ziel-gruppe usw. sind der Webseitewww.reconf.de zu entnehmen.

Am 8. März wird eine PostConferencemit vier ganztägigen Workshops stattfin-den, die das Thema Anforderungsma-nagement besonders intensiv betrachten:

[[ Ganztagesworkshop 1: Frank Stöckel, HOOD Group: Nur keine Überra-schungen – Stakeholder-Management im Entwicklungsprozess

[[ Ganztagesworkshop 2: Guido Dischinger, Liantis: Anforderungen präzise und verständlich schreiben

[[ Ganztagesworkshop 3: Stefan Fichtinger, HOOD Group: Mit RE&M-Methoden bessere Spezifi-kationen erstellen

[[ Ganztagesworkshop 4: Colin Hood:Zertifizierung zum HCM Manager

Die Buchung der Workshops (280,00 €je Halbtagesworkshop und 560,00 € fürden Ganztagesworkshop) sowie die zurKonferenz (750,00 €) kann entwederüber das Internet www.reconf.de oderdurch das auf Seite 8 aufgeführte Anmel-deformular vorgenommen werden.

Uhrzeit Raum ROM Raum PARIS Methodenvorträge Raum MADRID Anwendervorträge Automotive Modellierung von Anforderungen Einsteigervorträge

09:00 - 09:15 Eröffnung, Rupert Wiebel, HOOD Group09:15 - 10:00 Keynote: Colin Hood, HOOD Group:

Just following the rules for writing requirements is like having sex with an Englishman; very correct but not very satisfying

10:00 - 10:45 Keynote: Christian Trowitzsch, ehemaliger Leiter Elektronikentwicklung Hella KgaA Hueck & Co.:

Kürzere Lebenszyklen von Elektronik und deren Konsequenzen10:45 - 11:15 Pause und Besuch der Ausstellung11:15 - 12:00 Peter Hofmann, Volkswagen und Bernd Oestereich und Tim Weilkiens, Stefan Fichtinger, HOOD Group:

Urs Gulba: Volkswagen Reused OOSE: Die Modellierungssprache Jederzeit eine aktuelle SpezifikationSystems Modeling Language (SysML) – Voraussetzung für den Projekterfolg!

12:00 - 12:45 Dipl.-Ing. Thomas Saul, Volkswagen Dr. Rudolf Hauber, Kölsch & Altmann: Thomas Kujawski, Berliner Wasser-und Prof. Dr. Gert Bikker, EXTESSY: Use Case basierte Anforderungs- betriebe und Dr.-Ing. Frank Keller,Grafische Modellierung der Anforde- simulation mit UML 2.0 Arcway AG: Requirements in der Früh- rungen von Elektronik-Systemen im phase: Ergebnisorientierte Struktu-Kfz zur Bewertung von Architekturen. rierung (Big Picture) von IT-Projekten

anhand eines Beispiels der BerlinerWasserbetriebe

12:45 - 14:15 Mittagspause – Besuch der Ausstellung – Firmenvorträge 1- 614:15 - 15:00 Dr. Frank Houdek, Daimler-Chrysler Nicole Schimpfky, Christian Pikalek, Cahal Cormican, EADS: CaliberRM and

Sophist Group: RE und OO – wie passt TATEM. A requirements managementdas zusammen? tool in a European research project.

15:00 - 15:45 Dr. Richard Baumann, Knorr Bremse: Frank Lohmar, Borland: Requirements Dr. Klaus Heimannsfeld, Siemens COM:Einführung eines IT-unterstützten based UML und UML based Testing – Verteiltes Requirements ManagementRequirements Engineerings bei Knorr Brückenschlag von den Anforderungen als Basis der Angeboterstellung imBremse SfN über das Modell bis zum Quelltext Umfeld innovativer Telekommunikations-

dienste15:45 - 16:15 Pause und Besuch der Ausstellung16:15 - 17:00 Dr. Oliver Theissen, BMW AG und Andreas Ditze, MID: Traceability vom Katharina Brendebach, HVB Systems:

Christin Hiergeist, sd&m AG: Von der Geschäftsprozess bis zur Software Anforderungsmanagement im Vorge-Anforderung über den Anwendungsfall hensmodell der HVB Groupzur Lösung

17:00- 17:45 HIS Group: Das RIF Format – aktueller Alexander Heßeler, BearingPoint: Dr. Andrea Herrmann, Universität Heidel-Vortrag von Vertretern der HIS Group Herleitung des Nutzens und ROI-Bestim- berg; Ralf Fahney: How to convincemit anschließender Diskussion mung für Requirements Management Managers of Requirements Engineering(Open End)

17:45 - 19:45 Firmenvorträge 6 -18Happy Hour in der Hotelbar sponsored by Serena

20:00 - 23:00 Abendveranstaltung

Automotive

Vertikal 2|20066

Agenda der REConf 2006 – Dienstag, 7. März 2006


Automotive

Vertikal 2|2006 7

Agenda der REConf 2006 – Mittwoch, 8. März 2006

Workshops am 6. März vormittags - 09 Uhr bis 13 Uhr

Uhrzeit Raum ROM Raum PARIS Methodenvorträge Raum MADRID Anwendervorträge Anwendervorträge Medical

09:00 - 09:45 Matthias Reichhelm, Robert Bosch: Dr. Klaus Schmid, University of Hildesheim: Barbara Erdmann, Infineon Technologies undIRqA – von der Auswahl bis zum Einsatz Eine Übersicht und Analyse verschiedener Philipp Dreiss, Fraunhofer IPA: Tool Suppor-– Ein Erfahrungsbericht Ansätze zur Beschreibung von Produktlini- ted Capability Management for Semiconduc-

enanforderungen tor High Volume Equipment Integration09:45 - 10:15 Pause und Besuch der Ausstellung10:15 - 11:00 Graham Smethurst, BMW: Anforderungs- Kirsten Schwanitz, Carolin Dressel, Andreas Gerber, Angiomed Medizintechnik;

management bei BMW – Die Herausfor- Andreas Hötzel – alle ESG: Anforderungen Marcus Schorn, Plato: Anforderungen durchderungen der Zukunft in den Griff bekom- und Architekturen: Zwei Welten? Risikomanagement systematisch bewerten,men verfolgen und umsetzen

11:00 - 11:45 Dr. Volker Levering und Otto Schömann, Dr. Klaus Bergner, 4Soft: RE im V-Modell Emmanuel Joyeaux, Dräger Medical:BMW: Entwicklung von Hard-/Software- XT: Anforderungen an der Schnittstelle Information Model for Risk assessment in aKomponenten mit neuem BMW-Anforde- zwischen Auftraggeber und Auftragnehmer medical productrungsmanagement-Prozess - Roll-out bei der BMW Group und Lieferanten

11:45 - 12:30 Markus Stumpp, BMW: Traceability – Thomas Olsson, Tom Koenig, Fraunhofer Dr. Michael Schneider, Siemens CT:einmal anders genutzt IESE: Re-wissen.de – ein Kompass in der Bedeutung des Requirements Engineering

Anforderungswelt im Umfeld des PLM12:30 - 14:00 Mittagspause – Besuch der Ausstellung – Firmenvorträge 19 -2414:00 - 14:45 Dr. Peter Fromm, Karsten Kiehlmann, Dr. Stefan Joos, Robert Bosch; Dr. Klaus Knut Salomon, modulo3: 42 – Leben mit

Siemens VDO: Improving the Interface to Alfert, Zühlke Engineering: RE meets KM – Fragen, die niemand gestellt hatthe Customer – Automated Customer Konfigurationsmechanismen für varianteRequirement Import and Analysis Anforderungsmodelle

14:45 - 15:30 Diskussion: OEMs und Zulieferer Hans-Joachim Erchinger, Serena: Hans-Dieter Maier, HOOD Group: Die Requirements – und dann? Konsolidierungsmatrix, eine Methodik

innerhalb der Anforderungsdefinition15:30 - 16:15 Diskussion: OEMs und Zulieferer BearingPoint Andreas Seestädt, Deutsche Post World Net:

Service orientierte Architektur und Anforderungsmanagement

16:15 - 16:45 Pause und Besuch der Ausstellung16:45 - 17:30 Keynote Prof. Dr. Siegfried Wendt, Hasso-Plattner-Institut:

Sehen und Verstehen – Bauzeichnungen für Gedankengebäude 17:30 - 17:45 Verabschiedung und Ausblick REConf 2007

Rupert Wiebel, HOOD Group und Dieter Scheithauer, GfSE

Workshop 1: Uwe Valentini und Carsten Krennrich: Spezifizieren und Modellieren von Anforderungen mit UML 2.0 Workshop 3: Dr. Hans-Peter Hoffmann: UML2.0/SysML-Based Systems Engineering Using a Model-Driven Development Approach Workshop 5: Andreas Lobeck: UML-Modellierung Hand in Hand mit Anforderungs-Management Workshop 7: Daniel Kerkow, Dennis Landmann, Jörg Dörr, Dr. Klaus Schmid, alle Fraunhofer IESE: Vom Geistesblitz zur Anforderung –

Kreativitätstechniken im Requirements EngineeringWorkshop 9: Thomas Rossner: SPiCE up your TestingWorkshop 11: Andreas Plette: Requirements Engineering nach dem Sandwich-Prinzip – die Konvergenz von Anforderungen und Modellierung Workshop 13: Alexander Heßeler: Erarbeitung von Nutzenpotenzialen und Ursachen-Wirkungsketten für das AnforderungsmanagementWorkshop 15: Dr. Dieter Scheithauer: Systems Engineering EssentialsWorkshop 17: Michael Gerdom: Requirements Engineering unter Zeitdruck

Workshops am 6. März nachmittags – 14 Uhr bis 18 Uhr

Workshop 2: Knut Salomon: Die dunkle Seite des Chaos! Entropie im Projektgeschäft! Workshop 4: Guido Weischedel: Optimale Strukturierung und Verlinkung von Anforderungen Workshop 6: Timothy Ströbele: CMMI Anforderungen an das Requirements ManagementWorkshop 8: Michal Dobícek: Manage your Requirements with Subversion and Polarion LiveDocumentsWorkshop 10: Andreas Ditze: Extrahieren von Anforderungen aus GeschäftsprozessenWorkshop 12: Kay Fuhrmann: How to deploy Requirements Management – Was in der Praxis wirklich zählt Workshop 14: Rüdiger Bendick: Anforderungsbasiertes TestenWorkshop 16: Thomas Klingenberg: Das V-Modell XT in der Praxis – Werkzeuggestützte Projektarbeit mit der in-Step V-Modell XT EditionWorkshop 18: Christian Christophoridis: Assessment-fähiges Requirements Management


Hiermit melde ich mich verbindlich zur REConf 2006 vom 7. März bis 8. März 2006 an.

Rechnungsanschrift, falls abweichend Name Vorname von obiger Anschrift:

Firma Abteilung

Straße PLZ/Ort

Land E-mail

Telefon Fax

Datum Unterschrift

Zusätzlich buche ich die folgenden Workshops (bitte je Spalte nur ein Kreuz, da die Workshops parallel stattfinden):

Automotive

Vertikal 2|20068

Anmeldung(bitte an 089 / 4512 5319 faxen)

6.03.06 / 09:00 - 13:00� Workshop 1: Spezifizieren und Modellie-

ren von Anforderungen mit UML 2.0 – 280,00 €

� Workshop 3: UML2.0/SysML-Based Sys-tems Engineering Using a Model-Driven Development Approach (Workshop in Deutsch) – 280,00 €

� Workshop 5: UML-Modellierung Hand in Hand mit Anforderungs-Management – 280,00 €

� Workshop 7: Vom Geistesblitz zur Anfor-derung – Kreativitätstechniken im Requi-rements Engineering – 280,00 €

� Workshop 9: SPICE up your testing – 280,00 €

� Workshop 11: Requirements Engineering nach dem Sandwich-Prinzip – die Kon-vergenz von Anforderungen und Model-lierung – 280,00 €

� Workshop 13: Erarbeitung von Nutzenpo-tenzialen und Ursachen-Wirkungsketten für das Anforderungsmanagement – 280,00 €

� Workshop 15: Systems Engineering Essentials – 280,00 €

� Workshop 17: Requirements Engineering unter Zeitdruck – 280,00 €

6.03.06 / 14:00 - 18:00� Workshop 2: Die dunkle Seite des Chaos!

Entropie im Projektgeschäft! – 280,00 €� Workshop 4: Optimale Strukturierung und

Verlinkung von Anforderungen – 280,00 €� Workshop 6: CMMI Anforderungen an

das Requirements Management – 280,00 €� Workshop 8: Manage your requirements

with Subversion and Polarion LiveDocu-ments (Workshop wird in Englisch gehal-ten) – 280,00 €

� Workshop 10: Extrahieren von Anforde-rungen aus Geschäftsprozessen – 280,00 €

� Workshop 12: How to deploy Require-ments Management – Was in der Praxis wirklich zählt – 280,00 €€

� Workshop 14: Anforderungsbasiertes Testen – 280,00 €

� Workshop 16: Das V-Modell XT in der Praxis – Werkzeuggestützte Projektarbeitmit der in-Step V-Modell XT Edition – 280,00 €

� Workshop 18: Christian Christophoridis:Assessment-fähiges Requirements Management – 280,00 €

9.03.06 / 09:00 - 17:00� Ganztagesworkshop 1: Nur keine Über-

raschungen – Stakeholder-Management im Entwicklungsprozess – 580,00 €

� Ganztagesworkshop 2: Anforderungen präzise und verständlich schreiben – 580,00 €

� Ganztagesworkshop 3: Mit RE&M-Methoden bessere Spezifikationen erstellen – anhand eines praktischen Beispiels – 580,00 €

� Ganztagesworkshop 4: Zertifizierung zum HCM Manager – 1400,00 €

Die Teilnahmegebühr (fällig nach Erhalt derRechnung) beträgt 750 €. Wenn die Anmel-dung bei HOOD eingegangen ist, erhalten Sieeine Rechnung per Post. Sobald wir den Zah-lungseingang verzeichnen können, sendenwir Ihnen per E-Mail Ihre Zugangsbestäti-gung.

Allgemeine Bedingungen: Die Anmeldung istverbindlich. Die Annahme der Anmeldungmuss vom Veranstalter bestätigt werden. BeiRücktritt von der Anmeldung bis 25. Feb. 2006ist eine Bearbeitungsgebühr von € 200 zu ent-richten. Bei einem späteren Rücktritt ist dievolle Teilnahmegebühr zu entrichten. AllePreise verstehen sich zzgl. gesetzlicher MwSt.


Goldsponsor:

Logosponsor:

Dinnersponsor:

Technologiesponsor:

Premiumsponsor:

Mediasponsor:

[[ Agitar[[ Artisan Software[[ ASERVO AG[[ Arcway AG[[ Borland Software Corporation[[ Extessy AG[[ GfSE[[ HOOD GmbH[[ I-Logix Deutschland GmbH[[ IBM[[ Imbus AG[[ Intland GmbH[[ method park Software AG[[ microTOOL GmbH[[ MID Enterprise Software Solutions GmbH[[ MKS GmbH[[ NCH International[[ oose.de GmbH[[ Plato AG[[ Polarion Software GmbH

[[ QA Systems GmbH[[ QualityPark Group[[ Serena Software[[ Sophist Group[[ SQS AG[[ Steria Mummert[[ Telelogic Deutschland GmbH

Automotive

Vertikal 2|2006 9

Sponsoren der REConf 2006

Aussteller der REConf 2006


manage it: Herr Ditze, die MID enga-giert sich stark im Bereich Anforderungs-management. Was sind die Beweggründefür diesen Schritt?

AD: Der modellgetrie-bene Softwareentwick-lungsprozess beginntbei den Geschäftspro-zessen und den Anfor-derungen. Die Durch-gängigkeit in die Soft-wareentwicklung ist

unser ganzheitlicher Anspruch. Deshalbverfügt unsere ModellierungsplattformInnovatorAOX über eine Schnittstelle zudem AnforderungsmanagementwerkzeugDOORS von Telelogic. In diesem Rahmenhaben wir uns intensiv mit dem ThemaRequirements Engineering befasst undsind dabei, die Verallgemeinerung derSchnittstelle auch für andere Werkzeugevor zu nehmen. Dabei steht natürlich dasRequirements Interchange Format (RIF)

der HIS Group im Vordergrund. In die-sem Kontext arbeiten wir eng mit derHOOD Group und unseren Kundenzusammen.

manage it: Auf dem Markt existieren jabereits einige Anforderungsmanagement-werkzeuge, wird die MID hier künftigauch ein eigenes Tool anbieten?

AD: Auf keinen Fall, wir konzentrierenuns weiter auf unsere KernkompetenzModellierung: angefangen bei denGeschäftsprozessen, über das Extrahierenvon Anforderungen aus Geschäftsprozes-sen bis hin zur Modellierung der Anfor-derungen selbst. Dabei geben wir unserenKunden die Möglichkeit, das bereits imUnternehmen vorhandene RE-Tool weiterzu nutzen und eng mit InnovatorAOX zuintegrieren, um damit die Traceabilityvon der Anforderung über den Geschäfts-prozess bis hin zum Software Systemsicher zu stellen.

manage it: Traceability ist ein Schlag-wort, dass im Kontext des Anforderungs-managements immer wieder fällt, wiestellen Sie diese sicher?

AD: Unter Traceability wird im Anforde-rungsmanagement meist nur die Durch-gängigkeit und Nachvollziehbarkeit vonAnforderungen und deren Abhängigkei-ten untereinander verstanden. Wir gehenhier einen Schritt weiter und bietenTraceability von der Anforderung überdas Modell bis hin zum Source Code.

Dies realisieren wir durch eine Ver-knüpfung der Softwaremodelle mit denim RE-Tool formulierten Anforderun-gen, die ständig aktuell und somit konsi-stent gehalten wird. Die Verlinkung derModelle untereinander und zum SourceCode stellt eine vollständige Traceabilitysicher.

manage it: Wie gestaltet sich dann dasÄnderungsmanagement?

Automotive

Vertikal 2|200610

manage it sprach mit Andreas Ditze, dem Leiter des Product Management Boards der MID.

InterviewDie REConf 2006 ist die europäisch führende Konferenz

für das Anforderungsmanagement. Auf der REConf ist

erstmals die Modellierung von Anforderungen ein zen-

trales Thema. Die MID Enterprise Software Solutions

GmbH mit ihrer Modellierungsplattform InnovatorAOX ist

in diesem Kontext Technologiesponsor der REConf 2006.


Automotive

Vertikal 2|2006 11

AD: Wenn sich zum Beispiel eine fachli-che Anforderung ändert, führen die ebengenannten Verknüpfungen und Verlin-kungen exakt zu den Modell- und CodeTeilen, die von der Änderung betroffensind, überprüft und ggf. angepasst wer-den müssen. Somit haben wir dasAnforderungsmanagement mit demÄnderungsmanagement eng verbunden.

manage it: Die Strategie der MID gehtalso eher auf Integration von Drittpro-dukten als auf die Entwicklung neuerWerkzeuge?

AD: Wir sehen InnovatorAOX als zentraleModellierungsplattform innerhalb einerSoftware Production Line (SPL). Da nurselten Projekte auf einer grünen Wieseaufsetzen, ist die Integration der beste-henden Produktlandschaft oft die Her-ausforderung beim Kunden und nicht dieNeuentwicklung eines Produktes. Undgenau hier bietet InnovatorAOX eine fle-xible und effiziente Integrationsmöglich-keit existierender oder künftig anzuschaf-fender Werkzeuge.

manage it: Die MID verfügt ja auch übereine Vielzahl von Kunden im AutomotiveUmfeld. Wie reagieren diese auf die der-zeit in der Presse viel diskutierte SysMLund wie sieht da die künftige Strategieder MID aus?

AD: Unsere Kunden beschäftigen sichsehr wohl heute schon mit der SysML.Doch besteht eine gewisse Skepsis gegen-über der Komplexität und dem dadurch

notwendigen Einarbeitungsaufwand imVergleich zur derzeit eingesetzten Metho-de der Strukturierten Analyse/Design, wieeine Befragung unserer AutomotiveKunden auf der MID-Anwenderkonfe-renz im November 2005 ergab. Fernerhabe ich persönlich starke Zweifel, dasssich das in der SysML definierte Require-ments Diagramm für die Anforderungs-analyse durchsetzen wird, da es zu weitdavon entfernt ist, wie die Automotive-branche derzeit ihre sehr umfangreichenAnforderungen managt.

manage it: Also weiter Strukturierte Ana-lyse und Nassi Shneidermann?

AD: Zumindest für einen überschaubarenZeitraum wird der Fokus weiter auf denstrukturierten Methoden liegen. Solangeunsere Kunden die Strukturierte Analyseund Design einsetzen, werden wir dieToolunterstützung dafür weiter ausbauen.Gleichzeitig unterstützen wir mit Inno-vatorAOX sowohl die UML 1.4 als auchdie UML 2 und werden auch die Erweite-rungen der SysML umsetzen, um unserenKunden den Umstieg auf eine objekt-orientierte Modellierung zu ermöglichen.

manage it: Wie ist denn die Akzeptanzder SysML bei den Entwicklern?

AD: Gerade im Automotive/EmbeddedUmfeld ist bei den Entwicklern nach wievor aufgrund des gelebten Entwicklungs-prozesses eine große Nähe zum Code fest-stellbar. Deshalb ist hier eher eine gewisseZurückhaltung zu spüren – sie fühlen

sich durch die Nähe zum Code, die Ihnenunser Nassi Shneidermann Strukto-gramm-Editor bietet, sehr wohl und esbedarf wohl eines nicht zu unterschätzen-den Umstellungsprozesses, um den höhe-ren Abstraktionsgrad der SysML-Modellezu verinnerlichen.

manage it: Wird die SysML sich durchset-zen, und wann?

AD: Die SysML bietet mächtigereModellierungsmöglichkeiten als die Struk-turierte Analyse und Design. Dem gegen-über stehen mehr Komplexität, wenigerNähe zum Code sowie ein höherer Einar-beitungsaufwand. Mit steigenden Anforde-rungen an Abbildungs-/Beschreibungs-möglichkeiten, wird die SysML zuneh-mend die strukturierten Methoden ablösen.Viele unserer Kunden blicken auf einenZeitraum von fünf Jahren, den ich selbstfür realistisch halte.

manage it: Was sind Ihre nächstenSchritte auf diesem Weg?

AD: Neben der Unterstützung des RIF-Formats, und der damit verbundenenAnbindung eines größeren Spektrums anRE-Tools, werden wir auf Basis deraktuellen UML 2-Implementierung einoptimiertes Profil für System-Engineeringzur Verfügung stellen. Parallel dazu wer-den die Komponenten für StrukturierteAnalyse und Design sowie für unterneh-mensweite Datenmodellierung vollstän-dig auf die neue AOX-Plattform portiert.


Automotive

Vertikal 2|200612

nforderungen spielen für die erfolg-reiche Entwicklung eines Produk-tes eine maßgebliche Rolle. Im

Normalfall werden sie in Prosa dokumen-tiert und im besten Fall durch Diagram-me ergänzt. Die entstehenden Spezifika-tionen bilden einerseits die fachliche Basisfür die durchzuführenden Entwicklungs-arbeiten und werden damit gleichzeitig inden meisten Projekten zur Basis desVertrags zwischen Auftraggeber undAuftragnehmer. Alle Schwächen undLücken der Spezifikation werden so zuRisiken für die nachfolgenden Phasen desbeginnenden Projektes: Nicht eindeutigeAnforderungen können zu Fehlinterpre-tationen und schlimmer noch zu falschenImplementierungen führen, die nur mitzusätzlichem Aufwand wieder zu korri-gieren sind. Unvollständige Anforderun-gen können, abhängig vom zugrunde lie-genden Vertragsmodell, zu Ergänzungender Spezifikation und den damit verbun-

denen Nachverhandlungen auf der kom-merziellen Seite führen. Vor diesem Hin-tergrund wird deutlich, dass alle Ver-tragspartner bereits in Ausschreibungs-phase ein Interesse an einer überprüfbarguten Qualität der Spezifikation habensollten.

Wie aber lässt sich die Qualität derarti-ger Spezifikation einfach, schnell undobjektiv beurteilen? Eine Möglichkeitbesteht in der Erhebung von Messwertenoder Metriken, die bestimmte Qualitäts-kriterien der überprüften Spezifikation inZahlenwerte abbilden und so die Grund-lage einer vergleichenden oder absolutenBeurteilung darstellen.

Pro und Contra von Metriken?Metriken dienen laut [Ebert04] zurschnellen Beurteilung von Situationen,als Entscheidungsgrundlage und zurErstellung von Prognosen und Statistikenüber den Projektfortschritt. Im Zusam-

menhang mit einer Spezifikation bedeu-tet dies einerseits, dass sie das durch dieQualität der Spezifikation verursachteRisiko für den weiteren Projektverlaufbewertbar machen und dabei helfen,Schwachstellen in der Spezifikation auf-zudecken, die dann in einem nächstenSchritt eliminiert werden können. Dieauf diese Weise verbesserte Spezifikationbietet nicht nur Vorteile als Vertrags-grundlage, sie erleichtert auch die Arbeitin den folgenden Projektphasen (Design,Implementierung, Test) und stellt darü-ber hinaus auch noch eine sehr guteGrundlage für die Kommunikation allerProjektbeteiligten dar. Doch wie findetman diese Problemstellen?

Die Schwierigkeiten bei der objektivenErmittlung der Qualität von Spezifika-tionen beginnen bereits mit der Frage,wer die Beurteilung vornehmen sollte.Die Autoren selbst sind häufig so vertrautmit den Inhalten, dass sie sich nur noch

Requirements Management & Engineering

Messbare Qualität inAnforderungsdokumenten

A


Automotive

Vertikal 2|2006 13

schwer in die Rolle eines "unbelasteten"Lesers hineinversetzen können. Darüberhinaus muss häufig in Frage gestellt wer-den, ob die Autoren selbst objektiv genugsind, um die Qualität der eigenen Arbeitin Frage zu stellen. Andererseits habenunabhängiger Prüfer kaum die Möglich-keit, den Zustand des Anforderungs-dokuments eines komplizierten Projektesschnell und zu vertretbaren Kosten zubeurteilen.

In der Literatur findet sich eine Reihevon Kriterien, die gute Anforderungenerfüllen sollten (siehe Abb. 1).

Auch wenn auf eine genaue Erklärungder Bedeutung der einzelnen Kriterien andieser Stelle verzichtet wird (nähereInformationen finden sich in [Rupp04]),steht die Sinnhaftigkeit der Kriterien alsQualitätsziel außer Frage. Offen bleibtjedoch noch, wie die Erreichung derQualitätsziele unter den bereits erwähn-ten Rahmenbedingungen realer Projekteobjektiv und vergleichbar ermittelt wer-den kann.

Unter bestimmten Voraussetzungenkönnen hier Metriken weiter helfen.Dabei ist zu beachten, dass

[[ die Voraussetzungen für die Anwen-dung der jeweiligen Metrik gegeben sind,

[[ die Vorgehensweise zur Ermittlung desMesswertes möglichst eindeutig und nachvollziehbar dokumentiert ist,

[[ der Zusammenhang zwischen der Metrik und dem oder den zugehörigenQualitätskriterium verstanden und im Hinblick auf die Projektsituation als relevant betrachtet wird.

Sind diese Voraussetzungen gegeben,bieten Metriken eine gute Möglichkeitzur Beurteilung der aktuellen Qualität

von Spezifikationen in einem akzeptablenKosten-Nutzen Verhältnis.

An dieser Stelle muss jedoch noch aufeinen kleinen Haken hingewiesen wer-den: Metriken liefern zunächst nur Zah-lenwerte, die in einem Zusammenhangmit den genannten Qualitätskriterien fürAnforderungen stehen. Zwar lassen sich aus der Theorie heraus optimale Sollwertefür einen Teil der Metriken angeben, dieunter den jeweiligen Projektbedingungensinnvoll erreichbaren Werte können undwerden davon jedoch abweichen. Dieermittelten Messwerte ermöglichen aufdiese Weise zunächst vor allem denVergleich der Qualität von verschiedenenTeilen einer Gesamtspezifikation. Bei län-gerer Anwendung kann zusätzlich dieVerbesserung der Spezifikationsqualitätermittelt und dokumentiert werden.Darüber hinaus bieten die Metrikenzunächst nur Anhaltspunkte für dieQualität der Spezifikation und erlaubenallein noch keine Aussage über den tat-sächlichen Projekterfolg. Dies liegt daran,dass der Erfolg eines Projektes auch vonanderen, nicht messbaren Faktoren beein-flusst wird. So kann beispielsweise eine alsobjektiv schlecht bewertete Spezifikationfür einen erfahrenen Auftragnehmer aus-reichen. Im umgekehrten Fall kann einegute Spezifikation in den Händen eines

unerfahrenen Auftragnehmers trotzdemzu Problemen im weiteren Projektverlaufführen.

Zusammenfassend kann damit festge-halten werden, dass Metriken die Vergleich-barkeit innerhalb einer oder zwischenmehreren Spezifikationen herstellen kön-nen. Bei abweichenden Messergebnissenlassen sich Dokumente/-teile gezielt prü-fen und verbessern, bevor diese an denAuftragnehmer weitergegeben werden.

Das Vorgehen im DetailNachdem wir die grundsätzlichen Vor-und Nachteile von Metriken veranschau-licht haben, soll nun auf die konkreteAnwendung verschiedener Metriken ein-gegangen werden und das Ergebnis ausdem Vergleich mehrerer Spezifikationenrealer Projekte dargestellt werden.

Die VorbereitungUm Metriken sinnvoll einsetzen zu kön-nen, muss die damit verfolgte Absichtklar sein. Die Begründung dafür liegt aufder Hand: zu fast jeder der in Abbildung1 aufgeführten Qualitätskriterien könnenMetriken definiert und ermittelt werden.Dazu kommen noch weitere Metriken,welche die Qualität der Anforderungs-dokumente selbst beurteilen (siehe[Rupp04]). Um den Aufwand für dieErmittlung der Metriken in einem ver-tretbaren Rahmen zu halten, müssenmöglichst früh die Metriken ausgewähltwerden, die im Hinblick auf die jeweiligeZielsetzung die größte Aussagekrafthaben. Darüber hinaus muss sicherge-stellt werden, dass die gewählten Metri-ken in Verbindung mit den im Projektverwendeten Dokumenten die gewünsch-ten Ergebnisse liefern. In vielen Projekten

[[ vollständig (nach IEEE)[[ korrekt (nach IEEE)[[ klassifizierbar[[ konsistent (nach IEEE)[[ prüfbar (nach IEEE)[[ eindeutig (nach IEEE)

[[ verstehbar[[ gültig und aktuell[[ realisierbar[[ notwenig[[ verfolgbar (nach IEEE)[[ bewertet (nach IEEE)

Qualitätskriterien für Anforderungen (Abb. 1)

Sind [bestimmte] Voraussetzungen gegeben,bieten Metriken eine gute Möglichkeit zur Beurteilung der aktuellen Qualität vonSpezifikationen in einem akzeptablenKosten-Nutzen Verhältnis.


wird es beispielsweise Regeln für dieFormulierung von Anforderungen geben,während ergänzende, verständnisfördern-de Erläuterungen frei formuliert werdendürfen. Wendet man die ausgewähltenMetriken nun ohne geeignete Filterungauf den kompletten Text eines solchenAnforderungsdokumentes an, so wird dieAussagekraft der Metriken entsprechenddes Anteils der Erläuterungen amGesamtumfang des Dokumentes ver-fälscht. Zuletzt muss festgelegt werden,ob eine vollständige Vermessung derSpezifikationen sinnvoll ist oder ob einestichprobenartige Messung ausreicht.

Nachdem die geeigneten Metriken undder Umfang der Messungen festgelegtwurde, muss die Vergleichbarkeit der zuvermessenden Dokumente sichergestelltwerden. Um die Ergebnisse vergleichenzu können, müssen auch die zugrundeliegenden Dokumente vergleichbar sein.So dürften beispielsweise die an einerüberwiegend aus Screenshots bestehen-den Spezifikation einer Bedienoberflächeermittelten Kennzahlen nur schwer mitdenen einer Funktionsspezifikation inTextform zu vergleichen sein.

Für die genannten Vorbereitungen undEinschränkungen gilt: Um einen Mehr-wert aus der Anwendung von Metrikenzu ziehen geht es nicht darum, einenoptimalen, allen Voraussetzungen voll-ständig genügenden Idealzustand anzu-streben, sondern sich die aufgrund dergegebenen Randbedingungen geltendenEinschränkungen klar zu machen und beider Interpretation der Ergebnisse zuberücksichtigen.

Die ErhebungDie ausgewählten Metriken bestimmendas weitere Vorgehen: Einige Metrikenlassen sich automatisiert, d. h. mit einemgeeigneten Softwaretool, ermitteln. Man-che Metriken lassen sich allerdings nurmanuell durch einen ausgebildetenAnalytiker erheben. Darunter fallen alleMetriken, die auf der Semantik und logi-schen Zusammenhängen aufbauen. Eineautomatisierte Lösung würde hier imbesten Fall Indizien auf mangelhafteStellen in einer Spezifikation liefern. DieErhebung kann dabei im Zuge derPrüfung der Anforderungen, z.B. inner-halb eines Walkthroughs oder einer

Inspektion nach [Gilb93], erfolgen. Erfahrungen haben gezeigt, dass eine

Kombination aus manuellen und auto-matisierten Messungen am effektivstenist, da durch die verschiedenen Ermitt-lungsarten unterschiedliche, sich in ihrerAussagefähigkeit ergänzende Qualitäts-kriterien betrachtet werden. Darüber hin-aus führt die manuelle Analyse einesbereits automatisch bewerteten Textes zueiner Plausibilitätsprüfung der Ergeb-nisse, die stabilisierend auf die Qualitätder zu treffenden Aussagen wirkt.

Nach diesen grundlegenden Überle-gungen zur Auswahl und Anwendungvon Metriken, sollen im Folgenden einigeKennzahlen exemplarisch vorgestellt undauf reale Spezifikationen angewendetwerden. Aufgrund der Ziele wurden dazufolgende Metriken ausgewählt: Klassifi-zierbarkeit, Sortierbarkeit, Traceability,Verfolgbarkeit und Eindeutigkeit. Zusätz-lich wurde noch der Anteil der Passivsätzeermittelt, der als wichtiger und einfach zuermittelnder Indikator für das Vorhan-densein sprachlicher Defekte dient.

Textbasierte Metrik: die "Eindeutigkeit"Das Qualitätskriterium der "Eindeutig-keit" ist ein Vertreter der sogenanntentextbasierten Metriken. TextbasierteMetriken bewerten den Inhalt, d. h. dieBedeutung einer Anforderung. Unter"Eindeutigkeit" versteht man, dass einLeser eine Anforderung nur auf eine Artund Weise verstehen kann, um das Risikounterschiedlicher Interpretationen unddie damit verbundenen Gefahr vonFehlentwicklungen möglichst auszu-schließen. Die "Eindeutigkeit" einerAnforderung wird durch das Auftretensogenannter sprachlicher Defekte herab-gesetzt. Daraus ergibt sich folgendeFormel (Abb. 2):

Sprachliche Defekte (Tilgungen, Gene-ralisierungen, Verzerrungen) entstehendurch Transformationsprozesse des Men-schen bei der Wahrnehmung der Realitätund der anschließenden Weitervermitt-lung von Sachverhalten. Dadurch wirdder Inhalt einer Botschaft ungenau undmehrdeutig. Da dies gerade für Anfor-derungen nicht gelten sollte, handelt essich bei der Eindeutigkeit um eines derwichtigsten Qualitätskriterien. Auch dieWeltraumbehörde NASA hat dieserkannt. Von ihr durchgeführte Studien(vgl. [NASA98]) zeigen, welche sprach-lichen Elemente (der englischen Sprache)sich zu einer Auswertung, unter anderembezüglich der Eindeutigkeit eines Textes,anbieten.

Zur Beurteilung der Eindeutigkeitermittelt ein ausgebildeter Analytikerzum einen die durchschnittliche Anzahlvon "defekten" Anforderungen proAbschnitt und zum anderen die durch-schnittliche Anzahl von Defekten proAnforderung auf der Basis des SOPHISTREgelwerks (vgl. [Rupp04]). Da die Zahlder gefundenen Defekte mit der zurAnalyse zur Verfügung stehenden Zeitsteigt, wurde die Analysezeit pro Anfor-derung begrenzt. Mit Hilfe der ermittel-ten Ergebnisse konnten die verschiedenenSpezifikationen gut von einander abge-grenzt und konkrete Anhaltspunkte fürdie Überarbeitung identifiziert werden.

Könnte man diese Prüfung ganz oderauch nur teilweise automatisieren, sohätte man ein mächtiges Werkzeug fürdie Qualitätssicherung. Grundlage dafür,könnte die Untersuchung hinsichtlich derAutomatisierbarkeit von [Huesmann03]werden.

Automotive

Vertikal 2|200614

Eindeutigkeit =

Abb. 2: Formel zur Ermittlung einer Kennzahl der "Eindeutigkeit"

∑ (Anforderungen ohne Defekte)

∑ (Anforderungen)

”Eindeutigkeit”


Schnell und zuverlässig: PassivsätzeZu Beginn dieses Abschnittes haben wirbereits erwähnt, dass der Anteil derPassivsätze einen Hinweis auf die enthal-tenen Defekte liefert. Die Ursache dafürist in erster Linie, dass passive Formulie-rungen dazu verleiten, wichtige Informa-tionen bewusst oder unbewusst wegzulas-sen. Um den gleichen Zusammenhang ineinem korrekten Aktivsatz zu formulierenmuss beispielsweise die für eine Anfor-derung nicht uninteressante Informationüber die ausführende Person oder Einheitexplizit angegeben werden. Auf dieseWeise erhalten Anforderungen einenhöheren Informationsgehalt und das Pro-zesswort (= Verb) wird durch die Angabedes Akteurs näher spezifiziert.

Ein Tool zur einfachen Ermittlung desAnteils der Passivsätze an einem Texthaben die meisten bereits auf ihrem PC:Microsoft Word liefert diese Informationfür Texte im Rahmen der Grammatik-prüfung, sofern die entsprechenden Op-tionen aktiviert sind. Ermittelt Word alsoeinen hohen Anteil an Passivsätzen, solohnt es sich noch einmal genauer hinzu-sehen.

Die "Klassifizierbarkeit"Besonders bei Systemen, die in einemAuftraggeber/Auftragnehmer Verhältnisentwickelt werden, spielt die "Klassifizier-barkeit" (Abb. 3) eine wichtige Rolle. Siegibt an, ob alle Anforderungen eine Aus-sage hinsichtlich ihrer rechtlichen Ver-bindlichkeit treffen oder nicht. Diese For-derung lässt sich durch die Verwendungdefinierter Schlüsselwörter erfüllen, diez.B. mit Hilfe von Anforderungsschablo-nen (vgl. [Rupp04]) festgelegt werden.Eine Alternative stellt ein entsprechendesAttribut dar, welches für jede Anfor-derung befüllt werden muss.

Je nachdem welche Konvention für dieKennzeichnung der rechtlichen Verbind-lichkeit festgelegt wurde, kann nun derenEinhaltung überprüft werden. Bei Ver-wendung der Schlüsselwörter "muss","sollte", "wird" kann man bei der Mes-sung mit geringem Aufwand dasVorhandensein in den einzelnen Anfor-derungen prüfen.

Voraussetzung für das beschriebeneVorgehen ist, dass jede Anforderunggenau abgegrenzt werden kann. Dazu

muss festgelegt sein, woran man eineAnforderung erkennt. Ist sie durch Son-derzeichen oder eine ID von anderenInformationen abgegrenzt, gehört sie zueiner Zelle in einer Tabelle, ist sie in einerDatenbank gespeichert oder wird jedeAnforderung durch genau einen Satz for-muliert und werden Randbemerkungenund Erläuterungen separat verwaltet?Können Anforderungen bei der Ermitt-lung von Metriken nicht von erläutern-dem Text unterschieden werden, so führtdies zwangsläufig zu einer Verfälschungder Ergebnisse.

Strukturbasierte Metriken:"Verfolgbarkeit", "Traceability","Sortierbarkeit"Neben den textbasierten Metriken, gibtes die Gruppe der strukturbasierten oderstrukturbewertenden Metriken. Dazuzählen u.a. die "Verfolgbarkeit", "Sortier-barkeit" und "Traceability". Diese Krite-

rien beschäftigen sich in erster Linie mitder Struktur von Anforderungen inner-halb eines Dokumentes oder einer Daten-bank und der Dokumentation von Bezieh-ungen zwischen Anforderungen.

Eine Metrik hat sich hier als essentiellfür alle anderen strukturbasierten Metri-ken herauskristallisiert: die "Verfolgbar-keit" (Abb. 4). Diese setzt voraus, dassalle Anforderungen atomar, d.h. genauabgegrenzt, sind. Darauf aufbauend,bewertet sie, ob jede Anforderung eineeigene und eindeutige Identifikations-nummer besitzt, über die sie referenziertwerden kann. Wenn das Vorhandenseineiner eindeutigen Identifikationsnummernicht ohnehin vom verwendeten Require-ments Management Tool sichergestelltwird, lässt sich diese Kennzahl meist mitgeringem Aufwand ermitteln.

Die "Verfolgbarkeit" ist die Basis fürdie zweite strukturbasierte Metrik, die"Traceability". Von "Traceability" oder

Automotive

Vertikal 2|2006 15

Klassifizierbarkeit =

Abb. 3: Formel zur Ermittlung einer Kennzahl der "Klassifizierbarkeit"

∑ (Klassifizierbare Anforderungen)

∑ (Anforderungen)

”Klassifizierbarkeit”

Verfolgbarkeit =

Abb. 4: Formel zur Ermittlung einer Kennzahl der "Verfolgbarkeit"

∑ (Anforderungen mit ID)

∑ (Anforderungen)

”Verfolgbarkeit”

Traceability = Verfolgbarkeit .

Abb. 5: Formel zur Ermittlung einer Kennzahl der "Traceability"

1

∑ (fehlende Verweise)

”Traceability”


auch "Nachvollziehbarkeit" spricht man,sobald man in der Lage ist, von Anfor-derungen zu zugehörigen Informationen(z.B. Begründungen, Entscheidungen,Testfällen) zu gelangen. Die zur gleich-namigen Metrik gehörende Kennzahl(Abb. 5) bewertet, in welchem Maß dieseZusammenhänge dokumentiert sind.

In der Praxis erfolgt dies mit Hilfe vonReferenzen oder beim Einsatz vonRequirements Management Tools mitHilfe von Links. Bei der Ermittlung der"Traceability" kann es sinnvoll sein, dieMessung auf eine bestimmte Abhängig-keit von Informationen zu beschränken.Für die Ergebnisse der nachfolgend dar-gestellten Untersuchungen wurde analy-siert, ob jede Anforderung zu ihrer Quellezurückverfolgt werden kann und ob Zu-sammenhänge als solche gekennzeichnetsind.

Unabhängig von der "Verfolgbarkeit",wird mit der Ermittlung der "Sortierbar-keit" ein anderes Ziel verfolgt. Sie stelltdar, wie gut der Leser die für ihn relevan-ten Informationen erreichen kann. Diesist besonders wichtig, da z.B. das Mana-gement andere Informationen benötigtals die Entwickler. Dieses Qualitätskrite-rium lässt sich am einfachsten mit einerguten Gliederung und über Filter, mitderen Hilfe die im aktuellen Kontextweniger interessanten Informationen aus-geblendet werden können, realisieren. AlsFilterkriterium dienen Attribute, die fürjeden Informationstyp (Anforderungen,Definition, Abnahmekriterien, etc.) fest-zulegen sind. Welche Attribute oderVerwaltungsinformationen für einbestimmtes Projekt benötigt werdenhängt von den Projektrahmenbedingun-gen ab. In [Rupp04] ist eine Liste mitVerwaltungsinformationen aufgeführt,die als Grundlage für eine Sortierung die-nen kann. Für die Bewertung der "Sor-tierbarkeit" (Abb. 6) kann dann überprüftwerden, ob die Attributierung der Infor-mationen vollständig ist und wo Lückenauftreten.

Die AuswertungDer Aufwand für die Erhebung derMetriken ist nur dann gerechtfertigt,wenn die Ergebnisse in geeigneter Forminterpretiert und bei nachfolgenden Akti-vitäten berücksichtigt werden. Grund-

sätzlich können dabei verschiedeneAspekte untersucht werden. Besitzt mannoch keinen ausreichenden Pool anReferenzdaten, ermöglichen Metrikeneinen weitgehend objektiven Vergleichder Spezifikationsqualität innerhalb desProjektes. Auf diese Weise können kriti-sche Stellen in der Spezifikation identifi-ziert werden, die dann in einer zusätz-lichen Iterationsschleife verbessert oderdurch andere geeignete Maßnahmen imweiteren Verlauf abgesichert werden. Beiwiederholter Anwendung der selbenMetriken kann die aktuelle Spezifika-tionsqualität der in zurückliegenden Pro-jekten ermittelten gegenübergestellt wer-den. Auf diese Weise lässt sich erkennen,ob beispielsweise Schulungsmaßnahmen,

Änderungen in den Spezifikationspro-zessen oder die Verwendung von Spezifi-kationsleitfäden zu einer messbarenSteigerung der Spezifikationsqualitätgeführt haben. Stammen die vermessenenSpezifikationen aus verschiedenen Berei-chen, können Hinweise auf weiteres Op-timierungspotenzial abgeleitet werden.

Für die Gegenüberstellung der Ergeb-nisse bietet sich eine tabellarische Dar-stellung an. Möchte man zusätzlich nocheine grafische Aufbereitung vornehmen,dann empfiehlt sich ein Spinnennetz-diagramm wie in Abbildung 7. Unsereuntersuchten Dokumente werden durcheine Linie dargestellt, während dieermittelten Kennzahlen auf den "Achsen"des Spinnennetzes abgebildet werden.

Automotive

16

Sortierbarkeit =

Abb. 6: Formel zur Ermittlung einer Kennzahl der "Sortierbarkeit"

∑ (IST-Verwaltungsattribute)

∑ (SOLL-Verwaltungsattribute)

”Sortierbarkeit”

Abb. 7: Mögliche grafische Darstellung des Vergleichs mehrerer Dokumente

”Auswertung”

Vertikal 2|2006


Automotive

Vertikal 2|2006 17

Ein höherer Ausschlag der Linie repräsen-tiert in der Regel ein besseres Ergebnis (inProzent) hinsichtlich des Qualitätskrite-riums. Um diese einheitliche Darstellungaufrechtzuerhalten, wurde in diesemDiagramm der Anteil der Aktivformulie-rungen als Kriterium gewählt und nichtdie der Passivsätze. Somit spiegelt einegrößere Fläche auch eine bessere Gesamt-qualität der Spezifikation wider.

FazitRichtig angewendet sind Metriken einmächtiges Werkzeug zur Beurteilung vonSpezifikationen. Um belastbare Ergeb-nisse zu erzielen, ist die Auswahl undAnwendung der Metriken in geeigneterForm vorzubereiten. Im Hinblick auf dieangestrebte Verbesserung der Spezifika-tionsqualität ist es günstig, die den

Metriken zugrunde liegenden Qualitäts-kriterien bereits beim Schreiben derAnforderungen zu berücksichtigen.

Durch die Auswertung der Ergebnisselassen sich kritische Stellen in einerSpezifikation finden. Dies ermöglichtgezieltes Verbessern des Dokuments, sodass Fehler/Schwachstellen bereits früh-zeitig enttarnt werden. Durch die wieder-holte Anwendung von Metriken könnenVerbesserungen der Spezifikationsqualitätüber einen längeren Zeitraum erfasst unddokumentiert werden. Dies kann u. a.dafür genutzt werden, die Wirksamkeitqualitätsverbessernder Maßnahmen zuanalysieren und ihren Einsatz zu steuern.

Matthias Recknagel, DaimlerChrysler und Chris Rupp, Sophist Group

A Software ist mit SourceForge end-lich auch in Deutschland vertreten.

SourceForge ist eine effiziente Platt-form für die Optimierung einer dezentra-len Software Entwicklung. Sie basiert aufeinem zentralen, webbasierten Repositoryund verbessert die Kommunikation, dieZusammenarbeit und die Koordinierungvon geographisch verteilten Teams.

SourceForge wird vonUnternehmen eingesetzt um:[[ die Wiederverwendung von Software-

komponenten und die Nutzung von OpenSource Technologie im Unter-nehmen zu fördern

[[ ein sicheres, zentrales IP Repository aufzubauen

[[ die Start-up Phase für neue Projekte deutlich zu reduzieren

Literatur:[Ebert04]Ebert, C.; Dumke, R.; Bundschuh, M.; Schmietendorf, A.:Best Practices in Software Measurement. Berlin,Heidelberg, New York, Springer 2004. ISBN 3-540-20867-4[Gilb93]Gilb, T.; Graham, D.: Software Inspection. Boston,Addison Wesley 1993. ISBN 0-201-63181-4.[Rupp04]Rupp, C.: Requirements-Engineering und Management.München, Wien, Hanser 2004. ISBN 3-446-22877-2[NASA98]Rosenberg, L.; Hammer, T.; Huffman, L.: Requirements,Testing and Metrics. Veröffentlicht aufhttp://satc.gsfc.nasa.gov/support/index.html Stand: 30. März 2005.[Huesmann03]Huesmann, C.: Ein Automat zur linguistischen Analysenatürlichsprachlicher Anforderungen. UnveröffentlichteDiplomarbeit am Institut für Informatik der Fachhoch-schule Oldenburg/Ostfriesland/Wilhelmshaven 2003.

News

Weitere Informationen unterhttp://sourceforge.aservo.com/de/

SourceForge endlich auchin Deutschland V


Automotive

Vertikal 2|200618

as Bewusstsein von Unterneh-men bzgl. der Relevanz vonkonsequentem Anforderungs-

management ist in den letzten Jahren stetig gewachsen. Vielfältige Studien zeigen insbesondere, dass frühzeitige undkonsequente Qualitätssicherung bereitsin den sehr frühen Phasen der SoftwareEntwicklung eine enormeKosten-Nutzen Ersparnis bringenkann. Fehlerhafte oder unberück-sichtigte Anforderungen, die erstim Rahmen der Implementie-rungsphase aufgedeckt werden,können um den Faktor 10 teurersein als die frühzeitige Aufdeck-ung im Rahmen der Anforde-rungsphase.

Trotz dieses Bewusstseins fälltes vielen Unternehmen, insbeson-dere kleinen und mittelständi-schen Unternehmen (KMU), ausvielfältigsten Gründen schwer denEinstieg in den Anforderungs-bereich zu finden.

Das Portal re-wissen.de (siehe Abb. 1)bietet anhand verschiedener praxisrele-vanter Nutzungsszenarien für denUmgang mit Anforderungen eine Hilfe-stellung bezüglich dieser Problematik.Re-wissen.de entsteht im Rahmen desvom BMBF geförderten Reqman Projektsin Zusammenarbeit mit industriellenPartnern.

Den Einstieg erleichtertOftmals ist der eigentliche Einstieg in dieAnforderungswelt das zentrale Problemfür viele Unternehmen, da schlicht unklar

ist was der Anforderungsbereich umfasstund welche Aktivitäten sinnvollerweiseeingeführt werden sollten. Re-wissen.deversucht als neutrales Portal durch einengroben Überblick über die zentralenAktivitäten des Anforderungsbereichsdieser Problematik entgegenzutreten. DieAktivitäten unterteilen sich in die Phasen

Erhebung, Analyse, Spezifikation, Veri-fikation und Validation sowie Manage-ment. In einem ersten Schritt wird imPortal dargestellt WAS beim Anforde-rungsmanagement beachtet werden soll(z.B. durch die Praktik "NichtfunktionaleAnforderungen erheben"), in einem zwei-ten Schritt geht das Portal auf das WIEein (z.B. durch die Methode "MisuseCase Analyse"). Eine zusätzliche Klassifi-kation der Praktiken in Basis-Praktiken,die das Fundament bilden sollten, Erwei-terte Praktiken, die auf das Fundamentaufgesetzt werden können, sowie Kontext-Praktiken, die nur in bestimmten Fällen

Sinn machen, erleichtern dem Nutzerzudem die Auswahl konkreter Maßnah-men für seinen Anforderungskontext.Auch Firmen, die Lösungen zu einemganz konkreten Anforderungsproblemsuchen, finden auf re-wissen.de Hilfe-stellung.

Erfahrungsaustausch bietet zusätzliche UnterstützungDas Portal re-wissen.de richtet sich zumeinen gezielt an KMU, die Ihren Anfor-derungsprozess verbessern wollen, zumanderen soll Sie aber auch als Plattformzum Erfahrungs- und Wissensaustauschfür alle Anforderungsinteressierten dienen.So ist es beispielsweise möglich Erfah-rungen zum Einsatz von Anforderungs-management-Werkzeugen anderen Inter-essierten zugänglich zu machen. Da dieInhalte von re-wissen.de durch Anforde-rungsexperten aus Industrie und Wissen-

schaft erstellt, geändert und disku-tiert werden, spiegeln diese denaktuellen Stand der Praxis undWissenschaft wider.

Gemeinsame Arbeit fördernOffene und geschlossene Arbeits-gruppen ermöglichen die Zusam-menarbeit verschiedener Personenan einer bestimmten Thematik.Inhalte lassen sich im Rahmen derArbeitsgruppen beliebig anlegenund zur Diskussion stellen. Somitist es sowohl Anforderungsexpertenals auch Neulingen möglich sich inArbeitsgruppen zu organisieren und

über die Plattform vernetzt an einerThematik zu arbeiten.

Interesse an Anforderungen? –Machen Sie mit!Re-wissen.de möchte den Einstieg in dieAnforderungswelt erleichtern und dasBewusstsein für Anforderungen weiterfördern. Das Portal re-wissen.de steht je-dem Anforderungsinteressierten offen. BeiInteresse an Mitarbeit oder Inhalten, fin-den Sie Informationen unter re-wissen.deoder senden Sie eine email [email protected]

Dipl. Inform. Joerg Doerr, Fraunhofer IESE

Das "Warum" ist meist klar, das "Wie" häufig jedoch nicht

Re-wissen.de– das Portal für Anforderungsinteressierte

in der Software- & Systementwicklung

D

Abb. 1: Das neue Portal für das Anforderungsmanagement re-wissen.de


Automotive

Vertikal 2|2006 19

ereits heute ist der Trend erkenn-bar, dass immer mehr OEMs ihreEntwicklungstätigkeiten auf Zu-

lieferer bzw. Partner übertragen, diedadurch nicht selten in Konkurrenzsitu-ationen kommen, während sie sich selbstauf Kernkompetenzen wie die Montageund den Vertrieb zurückziehen. Insbeson-dere die Softwareentwicklung ist in derAutomobilbranche aktuell durch eineVielzahl von Koordinationsprozessen imBereich des Supply-Chain Managementsgekennzeichnet. Zeitgleich ist die Elek-tronik zur Archillesferse der modernenAutomobilindustrie geworden.

Definieren und Modellieren statt Programmieren

Einführung einesAssessment tauglichenAnforderungs-Managements mit IRqABedingt durch den Anspruch der Automobilhersteller,

in steigendem Maße nur noch Zulieferer zu akzeptieren,

welche CMMI-Level 2 oder besser Level 3 bzw. SPICE

Level 2/3 zertifiziert sind, wird das Anforderungs-

management als Teil der Supply-Chain der Automotive-

Branche immer mehr zu einem zentralen Qualitätsthema

für Automobilzulieferer.

B

Abb. 1: Der SPICE – Prozess im Überblick


Auf diesen Sachverhalt weist auch derrenommierte Wissenschaftler Dr. Ferdi-nand Dudenhöffer, Leiter des CAR(Center Automotive Research) der FHGelsenkirchen stets hin. Ein professionel-les, durchgängiges Anforderungsmanage-ment zur Qualitätssicherung ist von An-fang an unabdingbar geworden und dientin erster Linie der Verteidigung im Sinneder Qualitätssicherung.

Der puristische Einsatz von klassischenAnforderungsmanagement-Tools imUnternehmen führt dabei keineswegs zueinem funktionierenden Anforderungs-management. Vielmehr muss man sichbewusst sein, dass die Einführung desAnforderungsmanagements ein Prozessist, der über einen längeren Zeitraumkontinuierlich und iterativ innerhalb desUnternehmens etabliert werden muss.

Zunächst müssen der vorhandene Reife-grad ermittelt (SPICE – Assessment),Prozesse erarbeitet und abgestimmt sowieZiele definiert werden, die dann mit Hilfeder Software umgesetzt werden. Einekontinuierliche Prozessoptimierung wiein Abbildung 1 (Seite 19) dargestellt, hilftdabei das Anforderungsmanagement zuoptimieren.

Im Vordergrund des Interesses stehtjedoch das Assessment. Es gilt innerhalbder sog. SPICE Klassifizierung eine mög-lichst hohe Stufe zu erreichen.

Die Vorraussetzungen für das Erreichender einzelnen SPICE Level sind inAbbildung 2 dargestellt.

Es gilt die Geschäftsprozesse zu analy-sieren, zu modellieren und abzustimmen.Rahmenprozesse müssen etabliert wer-den, das Anforderungsmodell im Toolumzusetzen und die in den Prozessendefinierten Ergebnistypen mit Hilfe derToolunterstützung zu generieren. Hierkann eine gute Software ansetzen in demsie die Umsetzung der Ergebnisse derProzessstudien durch einen modellgetrie-benen Ansatz unterstützt.

Solch ein Werkzeug, welches sich ins-besondere durch seine Flexibilität undBenutzerfreundlichkeit auszeichnet, istIRqA. Der Regelkreis des Anforderungs-managements (Abb. 3) gibt hierbei einenguten Überblick über die durchzuführen-den Aktivitäten:

Eine gute Software ist in der Lage, jedesElement dieses Regelkreises optimal zuunterstützen, um die bestmöglichenResultate zu erzielen. In der Praxis ist esoft ein Problem, dass Anforderungen alsGesamtheit nur in textueller Form inDokumenten – wie beispielsweise einemLastenheft – beschrieben sind unddadurch die Identifizierung der einzelnenRequirements erschwert und eine Ver-

knüpfung mit anderen Elementen nichtmöglich ist.

Das Anforderungsmanagementwerk-zeug IRqA von QA Systems bietet hierdie Möglichkeit, Verknüpfungen zwi-schen den einzelnen Requirementsmittels so genannter "Motives" herzu-stellen, wie in Abbildung 4 dargestellt.

Diese Verknüpfungen sind frei definier-bar aber dennoch eindeutig. DerAnwender erhält damit die Möglichkeit,sowohl Beziehungen und Abhängigkeitenzwischen einzelnen Requirements, alsauch zwischen den Requirements undden Dokumentenauszügen darzustellen.Darüber hinaus lassen sich weitereObjekte wie Aktoren und Dokumentefließend in die modellierte Struktur ein-betten.

Zusätzlich bietet IRqA dieMöglichkeit, Problemstellungen in Formvon Problem-Domains zu erfassen undz.B. in Form von UML-Diagrammen zumodellieren (siehe Abb. 5).

Die umfangreiche Reportingfunktio-nalität, welche bereits standardmäßig eineVielzahl von vorgefertigten Reports bie-tet, ermöglicht die übersichtliche Ausgabeder Inhalte von IRqA in strukturierterForm. Durch die Möglichkeit, eigeneReports nach beliebiger Sortierung oderHierarchie zu erstellen, kann man die auf-genommenen Dokumente in ihrerGesamtheit aus IRqA heraus generieren.

Automotive

Vertikal 2|200620

Abb. 2: Die Vorraussetzungen für das Erreichen der einzelnen SPICE Level

Die SPICE-Level

Abb. 3: Der Regelkreis desAnforderungsmanagements

Regelkreis

Ein professionelles, durchgängiges Anforderungsmanagement zurQualitätssicherung ist von Anfang an unabdingbar geworden und dient inerster Linie der Verteidigung im Sinne der Qualitätssicherung.


Automotive

Vertikal 2|2006 21

Hierdurch besteht z.B. die Möglichkeit,das aus den Requirements entstandenePflichtenheft per Report zu erzeugen undauch das dem Projekt zu Grunde lie-gende Lastenheft in gleicher Weise zureproduzieren. Dabei lässt sich dasLastenheft exakt nach Hierarchie undAufbau des Original-Lastenheftes erstel-len, sofern dessen Aufnahme kapitelweiseerfolgte. Dies sichert für den Fall einesdurchzuführenden Assessments wiede-rum den Nachweis hinsichtlich der voll-ständigen Übernahme des Lastenheftes.

Ein weiterer, wichtiger Teil kommtder Lösungsbeschreibung (Services) undnatürlich den Testfällen zu, welche inIRqA erfasst, bearbeitet und vor allemmit den zugehörigen Requirements ver-knüpft werden können. In der Lösungs-beschreibung kann der Entwickler oderAnalyst seine Gedanken zur Lösung ent-sprechend der im System als Require-ments abgebildeten Anforderungen struk-turiert erfassen. Diese Lösungsbeschrei-bung ist auch die Basis für die durchzu-führenden Tests, die auf den in IRqAerfassten Testfällen beruhen, welche ihrer-seits bereits bei der Erfassung der

Anforderungen in Form der sog. "Fit-Criteria" bei den Requirements beschrie-ben wurden.

So kann jeder hinterlegter Test, Testfallund ggf. auch jeder Service und jedesModell bis auf das initiale Requirementzurückverfolgt werden, was ein ganzwesentlicher Punkt für eine erfolgreicheZertifizierung ist. Die Erfassung wird seitens IRqA durch eine Vielzahl vonWizzards unterstützt, welche in der Lagesind, strukturierte Informationen ausWord-Dokumenten oder Excel-Listen fürdie Bereiche Requirements, Services undTest-Cases automatisiert zu übernehmen.Eindeutige Indikatoren, wie z.B. Schlüs-sel, können hierbei selbstverständlichübernommen werden, was ein weitereswichtiges Kriterium für die Nachverfolg-barkeit ist.

Die wohl wichtigste Forderung imRahmen eines CMMI oder SPICEAssessments lautet: "Traceability" odervereinfacht gesagt, die durchgängigeNachverfolgbarkeit der Anforderungenbzw. der mit ihnen verbundenen Elemen-te wie z.B. Testfälle. Hierfür stellt IRqAeine Traceability Matrix (siehe Abb. 6)zur Verfügung, welche es ermöglicht, dieBeziehungen und Abhängigkeiten zwi-schen einzelnen Objekten grafisch darzu-stellen, Änderungen zu erkennen undnachzuverfolgen; ja sogar Simulationenvon geplanten Veränderungen und diedaraus resultierenden Folgen lassen sichhier abschätzen (Impactanalysen).

So lassen sich (und das nicht nur wäh-rend des Assessments) sehr schnell undübersichtlich die Verbindungen der ein-zelnen Requirements zu Ihrem Ursprungim Lastenheft aufzeigen. Dies ermöglichtbeispielsweise den Nachweis über die

vollständige Überführung des Lastenhef-tes in Requirements. Die im Rahmeneines gelebten Anforderungsmanage-ments entwickelten Prozesse und derensystematisch betreute Einführung stellensicher, dass das Anforderungsmanage-ment alle geltenden Qualitätsstandardserfüllt und das Werkzeug durchgängigverwendet wird. Diese Form der Quali-tätssicherung ist der Garant für die erfolg-reiche Absolvierung von Assessments undnatürlich für die Steigerung der Produk-tivität.

IRqA lässt sich hervorragend für denAuf- und Ausbau eines qualitätsorientier-ten Anforderungsmanagement einsetzen.Dies wird vor allem durch die durchgän-gige Verzahnung sowie die stimmigeIntegration der einzelnen Systemkompo-nenten erreicht. Die gleichzeitig vorhan-dene Customizing-Fähigkeit durch Mo-dellierung, erleichtert die Anpassung derSoftware an die spezifischen Unterneh-mensprozesse wie es im Rahmen vonSPICE erforderlich ist.

Hierbei wird von den Requirements imLastenheft über die Modellierung, dieAnalyse, die Lösungsidee bis hin zumTestfall eine durchgängige Unterstützunggeboten wie sie für Zertifizierungen nachCMMI oder SPICE unabdingbar ist. Somuss eine Softwarelösung konzipiert sein,welche bereits die Umsetzung der Ergeb-nisse von Prozessstudien durch einenmodellgetriebenen Ansatz unterstütztund eine durchgängige Plattform für denAuf- und Ausbau bietet. Eine ganzheitli-che Lösung muss die Geschäftsprozessedes Kunden optimal unterstützen, eingutes Aufwands-/Nutzenverhältnis besit-zen und dabei den strengen Kriterien derAssessoren insbesondere hinsichtlich derNachvollziehbarkeit (Traceability) undVollständigkeit genügen.

"Definieren und Modellieren stattProgrammieren" ist hierbei das Ziel. DieQA Systems GmbH kann neben derBereitstellung der Tool-Plattform IRqAund dem dazugehörigen Support auchden notwendigen Know-how Transfer fürden Aufbau und die Konfiguration desAnforderungsmanagements als Garantder Qualitätssteigerung und der erfolgrei-chen Zertifizierung bieten.

Klaus Lapp

Abb. 6: Die Traceability Matrix

Abb. 5: Modellierung in IRqA

Abb. 4: Verknüpfung durch Motives


iele Softwareprojekte leiden heut-zutage unter einem (oder auch

mehreren) der folgenden Mängel:

[[ Die Testdokumentation ist lückenhaft und nicht revisionssicher.

[[ Die Testfälle sind unsauber beschrie-ben und schwer reproduzierbar.

[[ Die automatisierten Testprozeduren und Testdaten sind inkonsistent, weil sie auf unzählige Skripte und Tabellen verstreut sind.

[[ Jedes neue Testobjekt-Release erzwingtaufwändige Anpassungen.

[[ Es existiert keine Anbindung zum Anforderungsmanagement bzw. zu Anforderungsmanagementwerkzeugen – es kann also nicht gegen existierendeAnforderungen getestet werden

[[ Die Freigabe eines Produktes erfolgt oft "aus dem Bauch heraus".

Automotive

Vertikal 2|200622

Anforderungsmanagement und Testen

Die imbus TestBench –ein iterativer ProzessDie Spezifikation von Anforderungen ist nur eine Seite

der Medaille – das Testen gegen zuvor spezifizierte

Anforderungen hingegen wird meist noch stiefmütter-

lich betrieben. Dabei liegen die Vorteile einer solchen

Vorgehensweise klar auf der Hand: Nur so kann glaub-

haft versichert werden, dass der Kunde das in der ent-

sprechenden Qualität erhalten hat, was er auch wollte.

VDer generische Testprozess

Abbildung 1


Automotive

Vertikal 2|2006 23

Die Auswirkungen dieser Mängel sindoffensichtlich – Qualitätsprobleme, War-tungsschwierigkeiten, Kundenunzufrie-denheit usw. Zur Lösung dieses Problemshat die imbus AG mit der imbusTestBench (siehe auch KurzbeschreibungSeite 26) ein Werkzeug auf den Marktgebracht, das alle Phasen im Testprozessunterstützt und über eine Anbindung zuden relevanten Anforderungsmanage-mentwerkzeugen, wie zum Beispiel IRqAvon QA Systems oder CaliberRM vonBorland verfügt.

Generischer, iterativer ProzessDie imbus TestBench basiert auf der Sichtdes Software-Tests als iterativen Prozess,der aus den folgenden Phasen besteht:

[[ Testplanung, [[ Testdesign, [[ Testautomatisierung und [[ Testdurchführung.

Diesem Standard-Testprozess liegenRollen- und Rechtedefinitionen, Use Casesund erzeugbare Dokumente zu Grunde,wie in Abbildung 1 dargestellt ist. Im fol-genden sollen die einzelnen Phasen undderen Inhalte näher dargestellt werden.

Die Testplanung beinhaltet alle Akti-vitäten, bei denen identifiziert wird, wasim weiteren Verlauf des Testprozesses zu validieren und zu verifizieren ist. Hierwerden Releasepläne und Testobjekte ver-waltet und die Testthemen aufgelistet,priorisiert und den entsprechenden Test-objekten zugeordnet. Ferner findet eineZuweisung der Testaufgaben auf die ein-zelnen Teammitglieder statt. Damit wirdeine saubere Planung der Testarchitekturund die erforderliche Aufgabenverteilunggewährleistet.

Bei der Testspezifikation (auch alsTestdesign bezeichnet) wird festgehalten,wie zu verifizieren und zu validieren ist.Ein formales, modulares Design von Test-fällen ist der wesentliche Erfolgsfaktor fürdie Wirksamkeit von systematischen Soft-waretests. Die imbus TestBench nutztdabei die sogenannte Interaktionsmetho-de. Die Interaktionsmethode basiert aufwiederverwendbaren Ablaufsequenzen –eben den Interaktionen – und abstrakten

Datentypen. Letztere werden in Äquiva-lenzklassen zerlegt, wobei jeder Äquiva-lenzklasse ein oder mehrere Repräsentan-ten zugeordnet sein können. Die denTestfällen zugeordneten Testdaten werdendadurch formal definiert abstrahiert. DieTestfälle werden in beliebig vielen Hier-archiestufen in Interaktionsschritte ge-gliedert. Je nach Abstraktionsebene isteine Interaktion ein fachlicher oder auchein technischer Testschritt. Hierunter ver-steht man das Anreizen des zu testendenSystems, zum Beispiel durch Eintragenvon Daten, Senden einer Nachricht oderähnlichem, oder die Prüfung einer erwar-teten Sollreaktion des Systems, zumBeispiel ein erzeugtes Datum oder eineempfangene Nachricht. Interaktionensind parametrierbar. Sie können bei jederVerwendung unterschiedliche Daten sen-den, empfangen und verarbeiten.

Durch Abstraktion und Kapselung vonInteraktionen und Datentypen wird einerobuste Test-Architektur gewährleistet,die stabil gegenüber Veränderungen desTestobjektes, von Testfällen oder Test-daten ist.

Die imbus TestBench gliedert Testfälleinnerhalb sogenannter Testfallsätze unddiese wiederum in Testthemen. AlleTestfälle in einem Testfallsatz haben diegleiche Sequenz von Interaktionen zwi-schen Testobjekt und Tester (bzw. Test-umgebung), aber ggf. verschiedene Para-metrierungen, also unterschiedliche An-

gaben, welche konkreten Daten währendder Durchführung dieses Testfalls an dasTestobjekt übergeben und welche Soll-reaktionen (Ausgabedaten) von ihmerwartet werden. Hierdurch ist eineErhöhung der Testtiefe oftmals durch ein-faches Hinzufügen von Parametrierungenmöglich. Testfallsätze können baumartigin Testthemen strukturiert werden, wobeiein Testthema sowohl Testfallsätze alsauch andere Testthemen enthalten darf.

In der Phase der Testautomatisie-rung werden diese Testspezifikationen zuautomatisch ablauffähigen Testprogram-men umgesetzt. Primäres Ziel ist es,durch die Automatisierung Zeit undRessourcen bei der Wiederholung vonTests einzusparen. Die Praxis zeigt leidervielfach, dass solche Automatisierungen,wenn sie nicht durch eine hinreichendreife Methodik bei der Entwicklung undVerwaltung der Automatisierungs-Skripteunterstützt werden, diesen Anspruchnicht erfüllen, sondern im Gegenteilhohe Aufwände bei der Wartung undErweiterung der Skripte erzeugen.

Durch die Anwendung der Inter-aktionsmethode bei der Spezifikationwird eine kostenoptimal nutzbare, robus-te und hochgradig wiederverwendbareTestautomatisierung auf einer abstraktenEbene bereits automatisch erzeugt. ZurErzeugung einer ablauffähigen Automati-sierung bedarf es lediglich noch der

Abb.2: Mittels der Interaktionsmethode werden Testabläufe aus einzelnen, wieder verwendbarenTestelementen zusammengesetzt.


Ausprogrammierung sogenannter ele-mentarer Interaktionen (oder auch Trei-ber) auf der Ebene eines konkreten, andie TestBench ankoppelbaren, Scripting-Werkzeuges. Die imbus TestBench arbei-tet mit praktisch allen solchen Werkzeu-gen im Bereich von GUI-, Embedded-und API-Testautomatisierung zusammen.

Bei der Testdurchführung werden dieTestläufe – einheitlich für manuelle oderautomatisierte Tests – gestartet, über-wacht und ihre Testergebnisse erfasst undrevisionssicher archiviert. Dabei könnenTestteilmengen gefiltert und zu zielge-richteten Testläufen bzw. Auswertungenzusammengestellt werden. Ein Highlightdieser Phase ist der sogenannte manuelleDurchführungsassistent, der sowohl imOnline- als auch im Offline-Betrieb (d.h.beispielsweise im Offshore-Testdurchfüh-rungslabor, bei Tests in Fahrzeugen etc.)dem manuellen Tester eine komfortableUmgebung zur Darstellung der Test-schritte, zur Protokollierung der Ergeb-nisse und zur Erfassung von Soll/Ist-Abweichungen zur Verfügung stellt.Solche Soll/Ist-Abweichungen könnenaus der TestBench heraus direkt in markt-übliche Defect Management-Systeme wiez.B. Bugzilla übernommen werden undbei Retests auch zur Planung z.B. vonFehlernachtests herangezogen werden.

Das Testmanagement überprüft danndie Abdeckung und die Produktqualität.Gerade hier haben eine Vielzahl vonUnternehmen mit den folgenden Schwie-rigkeiten zu kämpfen:

[[ Unklarer Testfortschritt (niemand hat den Überblick, was schon getestet wurde, und was noch nicht. Es ist nicht nachvollziehbar, welche Version des Testobjekts mit welcher Version der Testspezifikation mit welchem Ergebnis getestet wurde)

[[ Unvollständige Testdokumentation[[ Unbekannter Zustand der

Anforderungen[[ Unvollständige Berichte[[ Als Folge: unbekannte Produktqualität

und Freigabe "aus dem Bauch heraus"

Das Testmanagement verfolgt denFortschritt der Testentwicklung und -durchführung. Die TestBench sorgt fürdie homogene Ablage und Berichterstat-tung sowohl manuell als auch automati-siert erzeugter Testergebnisse und stelltzur Auswertung eine sehr flexibleReporting-Schnittstelle zur Verfügung.

Automatische Versionierung inbegriffenAlle Produkte des Testprozesses wie Test-spezifikationen und Durchführungser-

gebnisse können in der imbus TestBenchunabhängig voneinander versioniert wer-den, das heißt, der Bearbeiter kann denZustand der Bearbeitung eines Elementssichern und später wieder herstellen.Abhängigkeiten zwischen einzelnen Ele-menten, wie zum Beispiel zwischenTestfällen und den Designelementen, ausdenen sie bestehen, oder zwischen Test-durchführungsergebnissen und der Test-spezifikation, auf der sie basieren, werdendabei automatisch gepflegt und die Kon-sistenz zwischen ihnen wird sichergestellt.

Wichtige Ordnungselemente sindhierbei die sogenannte Testobjekt-Versionund der Testzyklus: Die Testobjekt-Version kennzeichnet die Zugehörigkeitvon Testspezifikations- und -automatisie-rungsdokumenten zu einem bestimmtenFunktionsumfang oder Lieferstand desSystems unter Test. Der Testzyklus kenn-zeichnet die Zugehörigkeit von Test-durchführungs-Ergebnissen zu einerbestimmten Testobjekt-Version.

Innerhalb eines Testprojekts sind dieVersionen der verschiedenen Objektebaumartig geordnet.

Innerhalb einer Testobjekt-Versionkönnen zudem beliebig viele Versioneneines Testspezifikations- oder -automati-sierungsdokuments erzeugt werden undinnerhalb eines Testzyklus beliebig vieleVersionen einer Durchführungsinforma-tion.

Stabile ArchitekturDie imbus TestBench ist ein plattformun-abhängiges skalierbares System auf derBasis von Sun Java 2 Enterprise Edition.Es handelt sich also um ein 3-Schicht-System mit einer SQL-basierten Daten-bank im Hintergrund, einem Java-Appli-cation-Server und beliebig vielen "Rich"-Clients mit grafischer Oberfläche eben-falls auf der Basis von Java. Als Daten-bank kann Microsoft SQL-Server oderORACLE RDMBS zum Einsatz kom-men, als Application Server dient JBoss.

Die imbus TestBench ist als Single-Server-System ausgelegt, d.h. alle Benut-zer arbeiten auf dem gleichen ApplicationServer mit der gleichen Datenbank.Durch die Clustering-Eigenschaften vonhinterlegtem Datenbank- und EJB-Serverist eine hohe Skalierbarkeit gegeben, so

Automotive

Vertikal 2|200624

Abb. 3: Die Testdurchführungssicht ermöglicht einen schnellen Überblick über alle Testergebnisse.


Automotive

Vertikal 2|2006 25

dass ein TestBench-System – je nach Leis-tungsfähigkeit der eingesetzten Hardware– durchaus Dutzende parallele Benutzerbedienen kann.

Highlight: Schnittstelle zumAnforderungsmanagementDie imbus TestBench bietet eine generi-sche Schnittstelle zur Ankopplung vonWerkzeugen für Anforderungsdefinitionund -management. Innerhalb derTestBench werden die Anforderungsda-ten verschiedener Werkzeuge wie BorlandCaliberRM oder QA Systems IRqAgleichartig dargestellt. Die Abbildungzwischen dem konkreten Anforderungs-managementwerkzeug und dem allgemei-nen Datenmodell der imbus TestBenchleistet ein toolspezifischer Wrapper, derBestandteil der TestBench-Serverarchi-tektur ist. Damit können die vier wichtig-sten Inhalte umgesetzt werden:

[[ Anforderungsbasierte Testplanung:Durch die generische Schnittstelle erhal-ten Testmitarbeiter innerhalb der Test-Bench Zugriff auf Struktur und Inhaltevon Anforderungen; Informationen wiez.B. Anforderungspriorität und -realisie-rungsstatus, Kategorisierung nach ver-schiedenen Qualitätsmerkmalen und dietextuelle Beschreibung der Anforderun-gen sind im direkten Zugriff und kön-nen zur Planung und zum Entwurf vonTestfällen herangezogen werden.

[[ Anforderungsbasierter Testfallentwurf:Testdesigner können direkt Einsicht indie Spezifikation der Anforderungennehmen und sie mit den Testfallsätzenverknüpfen und somit zum Ausdruckbringen, welche der Testfallsätze welcheAnforderungen verifizieren.

[[ Anforderungsbasiertes Reporting:Testmanager können sich mit den mäch-tigen Filter- und Reportingfunktioneneinen schnellen Überblick über diejeweils erreichten Testdesign- und Test-durchführungsabdeckungen schaffen.

[[ Management von Änderungen:Die Schnittstelle liefert auch jederzeitInformationen über Änderungen derAnforderungen zwischen zwei "Baselines"(Mengen zusammengehöriger Versionen

der Anforderungs-Objekte). Auf dieseWeise kann die Planung der Testaktivi-täten eng mit dem Fortschritt der Anfor-derungsdefinition und -umsetzung synchronisiert werden.

Technisch ist die Anbindung so gelöst,dass ein spezieller Client, die Require-ments-Bridge, der imbus TestBench mitder IRqA-API verbunden wird und darü-ber das Repository des Testmanagement-systems mit Daten versorgt wird. DieAnforderungen werden innerhalb desTestmanagements genau in der gleichenStruktur, wie durch das Anforderungs-managementsystems vorgegeben, abgelegtund dem Testdesigner innerhalb seinerTestspezifikation zur Verknüpfung ange-

boten. Der Testmanager kann dabei entscheiden, welches Projekt mit wel-chem View aus dem Anforderungsmana-gementsystems ins Testprojekt übernom-men wird. Die eventuell notwendigeAktualisierung der Anforderungsdatenkann ebenfalls jederzeit vom Testmanagerausgelöst werden. Innerhalb des Testspe-zifikation werden die Anforderungendurch einfaches Drag&Drop vom Test-designer mit den Tests verknüpft. Sinddie Tests durchgeführt, wird aus den Test-ergebnissen für jede Anforderung einTeststatus gebildet, der auch die möglichen:m-Beziehung von Anforderungen zuTests berücksichtigt. Der Teststatus kannwiederum über einen getriggerten

Abb. 4: Anforderungen können per Drag&Drop Tests oder ganzen Testthemen zugeordnetwerden.

Die Schnittstelle liefert auch jederzeitInformationen über Änderungen derAnforderungen zwischen zwei "Baselines".[...] Auf diese Weise kann die Planung derTestaktivitäten eng mit dem Fortschritt derAnforderungsdefinition und -umsetzung synchronisiert werden.


Abgleich in das Anforderungsmanage-mentsystem übernommen werden.

Abbildung 5 zeigt die Anbindung des An-forderungsmanagementwerkzeuges IRqAin der imbus TestBench.

Beteiligte RollenAn der Durchführung der in der imbusTestBench integrierten Methode sind ver-schiedene Rollen beteiligt:

[[ Die Fachabteilung (Kunde) hat das Wissen über Anforderungen und Use Cases des zu testenden Systems und stellt es in Form von Dokumentatio-nen und/oder Interviews oder durch Erstellung einer High-Level-Spezifi-kation mit der Interaktionsmethode zur Verfügung.

[[ Der Testdesigner transformiert dieses fachliche Wissen basierend auf den zu prüfenden Qualitätsmerkmalen und zur Prüfung geeigneter Teststrategien in entsprechende formale Testfälle.

[[ Der Testprogrammierer kann darauf aufbauend Testprogramme erzeugen, die die im formalen Testfallentwurf festgelegten Eigenschaften besitzen. Er benötigt hierzu keinen tiefgreifen-den fachlichen Hintergrund, sondern hauptsächlich Wissen über Testauto-matisierungswerkzeuge und ihre Programmiersprachen.

[[ Die Aufgabe des Testers ist es dann im Fall eines automatisierten Tests, die durch die imbus TestBench teilweiseautomatisch generierten Testprogram-me zu starten, ihre Ergebnisse auszu-werten und ggf. aussagekräftige Fehlermeldungen zu erstellen. Im Fall manueller Tests führt er – optional gestützt auf den Durchführungs-assistenten – die spezifizierten Tests exakt und wiederholbar durch und protokolliert Ergebnisse und begleiten-de Artefakte (zum Beispiel Screenshotsoder Ist-Datensätze).

Thomas Roßner

Automotive

Vertikal 2|200626

Abb. 5: Die Anbindung des Anforderungsmanagements in der imbus TestBench, wie sie mit demAnforderungsmanagementwerkzeug IRqA vorgenommen wurde

Die TestBench zeichnet sich durch die folgendenEigenschaften aus:

[[ Die imbus TestBench ist eine integriete Entwicklungsumgebung für Softwaretests. Sie ist plattformunabhängig und bietet eine konsequente, durchgängige Toolunterstützung über alle Phasen im Testprozess.

[[ In der imbus TestBench erfassen und bearbeiten Testteams alle testrelevanten Informationen. Insbesondere die Toolunterstützung der Testdesign-Aufgaben erzeugt robuste und wiederverwendbare Test-Architekturen.

[[ Unterschiedliche Testroboter, zum Beispiel für Komponenten- und Integrationstest, automatisierten GUI-Test oder embedded Test, können aus der TestBench heraus angesteuert werden.

[[ Mit der imbus TestBench lassen sich bereits entwickelte Testab-läufe einfach wiederverwenden und damit Testzykluszeiten verkürzen.


Automotive

Vertikal 2|2006 27

ie MID als Hersteller von praxis-bewährten Modellierungsplatt-formen unterstützt den Aufbau

kompletter Software-Fertigungsstraßen(Software Product Lines, SPLs) undermöglicht dabei die enge Integration vonTestprozessen in den Entwicklungspro-zess. Anforderungen, Softwaremodelleund Testmanagement werden so zu einemhocheffizienten und transparenten Gesamtprozess zusammengeführt. DieReaktionen der Kunden bestärken diesesVorhaben: Auch dort wird der Ruf nacheiner durchgehenden Verlinkung vonAnforderungen, Softwareartefakten undTestdaten laut, um insbesondere die inSPICE geforderte Traceability zu gewähr-leisten und somit Pflege und effizientesControlling zu ermöglichen. "Die MIDträgt dem wachsenden Bedürfnis nach ver-besserter Werkzeugunterstützung für dieTraceability Rechnung, indem sie Require-ment- und Testtools mit der ProduktfamilieInnovatorAOX zu einem sinnvollen Gan-zen verbindet und gleichzeitig den Prozessder Softwareentwicklung optimiert", resü-miert Andreas Ditze, Principal Consul-tant und Leiter des Product ManagementBoards der MID, der seit vielen JahrenKundenprojekte im Embedded-Umfeldbegleitet, zum Beispiel bei Hella undMarquardt.

Jedes IT-Projekt stellt aufgrund seinerindividuellen Prozesse andere Anforde-rungen an seine Toollandschaft, die danndie gesamte SPL bildet: Die beteiligten

Tools dürfen kein bestimmtes Vorgehenaufzwingen, sondern müssen hochflexibelan kundeneigene Vorgehensweisen an-passbar sein.

Wichtigstes Feature ist hierbei die Zu-ordnung zwischen Testfällen auf dereinen und Requirements bzw. Software-modellelementen auf der anderen Seite.Ist diese gegeben, lassen sich Fragenbeantworten, wie: Wie wird eine be-stimmte Funktionalität getestet? Ist Test-vollständigkeit (Abdeckung) gegeben?Sind diese Tests bereits erfolgreich gelau-fen, wie ist der Testfortschritt? Und:Wenn sich an einer Funktionalität etwasändert, welche sind die zugehörigenTestfälle, die dann ggf. überarbeitet undneu durchgeführt werden müssen?

MID unterstützt diese Anforderung aufzwei Wegen: Zum einen lassen sich inInnovatorAOX-Modellen an den für das

jeweilige Projekt geeigneten underwünschten Stellen die testrelevantenDaten direkt im Softwaremodell ablegenund dann über tooleigene Standard-

mechanismen mit einem Klickwiederfinden. Dies kann ge-schehen entweder durch dieKonfiguration von testspezifi-schen Spezifikationstextenoder aber durch Verlinkungexterner Dateien beliebigerFormate (z.B. Excel, XML,...). Zum anderen erlaubt esdie offene AOX-Architektur,Werkzeuge von Drittanbieternoptimal anzubinden – so etwaprofessionelle Werkzeuge zumTestmanagement und zur Test-fallverwaltung sowie Require-

ments-Management-Tools.Die MID hat in der Vergangenheit viel-

fach Kompetenz im Testumfeld bewiesen,etwa durch Aufbau eines Testkonzeptsund automatisierten Testsystems für einGroßprojekt der öffentlichen Hand, beidem die zu testende Software pro Jahr ca.30 Mrd. Euro bewegt, wie in Abbildung 1dargestellt.

So hilft MID ihren Kunden auch beimwichtigen Thema Test und liefert einenweiteren Baustein für die erfolgreicheAbwicklung komplexer, strategisch bedeut-samer und risikobehafteter Softwarepro-jekte.

Dr. Christian Brandes


MID hilft ihren Kundenauch beim TestenTraceability und Testen sind wichtige Bausteine für eine

erfolgreiche Systementwicklung.

D

Abb. 1: Entwicklungsprozess innerhalb eines Großprojektes der MID– die Verbindung von Anforderungen mit Testfällen und Software-modell durch InnovatorAOX gewährleistet die Traceability


Automotive

Vertikal 2|200628


Wenn dieWirtschaftlichkeit imVordergrund steht ...So genannte wertschöpfende Werkzeuge gibt es mehr

als genug auf dem Markt, die meisten davon stehen in

irgendeinem Schrank und werden nicht benutzt – daher

hat sich neben Software hier eher der Begriff der

Schrankware etablieren können. Doch wie sieht es

mit den wenigen Produkten aus, wo ein wirkliches Ein-

sparungspotential vorliegt? manage it hat den Newcomer

Agitar unter die Lupe genommen, der im Testbereich

neue Wege geht.


Automotive

Vertikal 2|2006 29

as amerikanische ProdukthausAgitar hat mit seinem Testpro-dukt Agitator in der letzten Zeit

für viel Aufmerksamkeit gesorgt. Selbstdas Wall Street Journal war mehr als ange-tan und hat dem Unternehmen denInnovation Award verliehen. Die Produkt-palette umfasst mit Agitator und demDashboard zwei sich ergänzende Werk-zeuge, die im Umfeld des Testens vonJAVA Code anzusiedeln sind und derzeitals Paket auf dem Markt vertrieben wer-den. Doch Testprodukte gibt es viele –wodurch zeichnet sich Agitator aus? Inerster Linie dadurch, dass hier bereits beider Codeerstellung getestet wird – nichterst im Anschluss, wie vielerorts üblich.Es liegt auf der Hand – desto früherFehler entdeckt werden, desto kostengün-stiger wird die Software Entwicklung.Dass dabei natürlich auch noch dieQualität der zu entwickelnden Softwaredrastisch steigt, ist ein angenehmerNebeneffekt.

Doch Qualitätsgewinn alleine stelltschon seit längerem keinen ursächlichenInvestitionsgrund mehr da – hingegenKosteneinsparungen schon eher. Sinddiese nachweislich innerhalb eines ver-tretbaren Zeitraums festzustellen (alsoinnerhalb weniger Wochen oder Mona-te), dann macht eine Investition Sinn undwird auch nach wie vor durchgeführt.Agitar kann hier mit beeindruckendenZahlen aufwarten:

[[ Reduzierung der Entwicklungskosten bis zu 45 %

[[ Anstieg der Wiederverwendbarkeit neuer und existierender Applikationen um bis zu 400 %

[[ Reduzierung der Wartungskosten um bis zu 75 %

[[ Reduzierung der Entwicklungszeit für Neuprojekte um bis zu 30 %

[[ Vermeidung von "Rework" um bis zu 80 %

[[ Reduzierung der Zeit, wo die Appli-kation nicht läuft, um über 70 %

Wie kann ein solch signifikantes Ergeb-nis erzielt werden? Ausschlaggebend sinddie Zeiten, die bei der Entwicklung vonJAVA Code bisher in Tests investiert wer-den mussten, genauer gesagt in dasSchreiben und das anschließende Pflegen

von Unit Tests. Nahezu Standard war hierbisher JUnit – hierbei handelt es sich umein Framework zum Testen von Java-Programmen, das besonders für automa-tisierte Unit-Tests einzelner Units (meistKlassen oder Methoden) geeignet ist.Hauptentwickler des JUnit-Frameworkssind Erich Gamma und Kent Beck, letz-terer arbeitet als Agitar Fellow seit 2004eng mit der Produktentwicklung zusam-men, erhält mittlerweile seine Sozialver-sicherungsnachweise von Agitar.

Agitation mit Agitator von AgitarWichtige Voraussetzung für den Erfolgvon Agitar ist die Tatsache, dass sich mitt-lerweile agile Software-Entwicklungs-prozesse, wo Entwickler selbst testen, aufdem Markt etabliert haben. Auf diese Arterhalten die Entwickler unmittelbar einFeedback bezüglich der von ihnen ent-wickelten Software. Deutliches Indiz fürdiese Entwicklung ist der Fakt, dass allei-ne das JUnit Framework bereits mehr alseine Millionen mal downgeloaded wurde.

Das Testwerkzeug Agitator von Agitargeht jedoch andere Wege als JUnit (JUnitTests werden mit dem entsprechendenSource Code assoziiert und können aus-geführt und gemonitort werden). Durcheine so genannte Agitation wird das hän-dische Schreiben von Unit Tests schlicht-weg wegrationalisiert – die Unit Testswerden parallel zur Software-Entwick-lung von Agitars Agitator generiert!Dabei geht der Agitator wie folgt vor:Zunächst analysiert der Agitator (darge-

stellt in Abb. 1) den ausführbaren JAVA-Code und untersucht das Verhalten sowiedie Codeabdeckung, nun können zweiErgebnisse auftreten:

1.) Wenn die so genannte Code Obser-vation einen Fehler meldet, kann der Entwickler den Fehler direkt im Code beheben.

2.) Wenn die Code Obervation erfolg-reich war, kann der Entwickler auf Knopfdruck einen Unit Test gene-rieren.

Während der Agitation erzeugt undsammelt der Agitator eine Reihe vonSnapshots, die Beispielswerte darstellen,wie sie bei dem Testlauf generiert wurden.Ebenso werden diese Snapshots fürZuordnungsfehler sowie für jedesErgebnis erzeugt.

Durch diese effiziente und praktikableVorgehensweise wird die Erstellung undPflege von Unit Test vereinfacht und vorallem signifikant beschleunigt. Da derSoftware Code der direkte Input für denAgitator ist, können auch Änderungensofort erkannt werden, um die Tests syn-chron zu halten. Ferner kann jeder einmaldurchgeführte Test zu jedem beliebigenZeitpunkt wiederholt werden.

Dabei verfolgt der Agitator alle wichti-gen Variablen, ihre Beziehungen unter-einander sowie die Pre- und Post-Values.Agitator nutzt dies zur Generierung derObservations, die anhand ihrer Bedeu-tung dem Anwender in chronologischer

D

Abb. 1: Der Agitator generiert Unit Tests auf Knopfdruck


Automotive

Vertikal 2|200630

Reihenfolge angezeigt werden. DieseObservations geben darüber Auskunft,was der entwickelte Code wirklich macht,unabhängig von dem, was im Design vor-her spezifiziert wurde oder was die"Erwartungshaltung" an den Code war.Der Agitator beginnt dabei an einem vomEntwickler festzulegenden Startpunktund verfolgt ab diesem sämtlichen abhän-gigen Code sowie alle logischen Branchesund analysiert das Verhalten zur Laufzeit.Dabei erhält der Entwickler statistischeAngaben, wie viel (und welcher) Codedabei berücksichtigt wurde und welcheZuordnungen überprüft wurden.

Ziel: JAVA-EntwicklerHier wird ebenfalls offensichtlich, wer dasZielpublikum von Agitar ist: Nicht dieQualitätssicherung, sondern der (JAVA)-Entwickler selber. Eben um frühzeitigFehler zu erkennen und die Effizienz beider Software-Entwicklung zu steigern.

Der Agitator speichert alle Daten inXML-Files ab (es wird also kein dedizier-ter Server oder Datenbank benötigt), sodass diese ohne Probleme parallel zu denSource Code Dateien von gängigen Kon-figurationsmanagementsystemen verwal-tet werden können. Diese Parallelität istvon großer Bedeutung, um die Vollstän-digkeit jederzeit im Blick zu haben.

Ein weiterer Nachteil von JUnit (nebendem manuellen Schreiben und der kom-plizierten Wartung von Unit-Tests) ist dieSchwierigkeit, die durch das Testen erhal-tene Ergebnisse auf zu zeigen. Hier hatAgitar mit dem Dashboard ein zweitesProdukt im Portfolio, was sich dieserHerausforderung stellt. Dabei werden inübersichtlicher Art und Weise TestErgebnisse, Codeabdeckung, kritische(Risikobehaftete) Klassen und Methodenusw. dargestellt. Ferner erhalten die Ent-wicklungsteams grafisch ihren Fortschrittdargestellt (im Vergleich zu dem, was er-forderlich ist, also im Vergleich zu den

gesetzten Zielen, Trendanalysen, usw.), sodass die erforderlichen Ressourcen effi-zient zugeordnet werden können. Einwichtiges Hilfsmittel für jeden Projekt-leiter und Entwickler. Abbildung 2 ver-mittelt einen Eindruck über das Look &Feel des Dashboards.

Wie bereits eingangs erwähnt, werdenbeide Produkte – also der Agitator unddas Dashboard – im Bundle vertrieben,das hat den folgenden Hintergrund:

Der Agitator speichert sämtliche TestErgebnisse und Codeabdeckungs- undZuordnungsmetriken in einem zentralenRepository und stellt damit sicher, dassdiese Informationen verteilt allen Projekt-

beteiligten zur Verfügung stehen. DasDashboard stellt das User Interface fürdiese Metriken dar. Die beiden Produktebauen also aufeinander auf.

Der Agitator steht als Plug-In fürEclipse zur Verfügung (ebenso ist Agitarintegrierbar in andere IDEs wie JBuilder,Rational Application Developer (RAD)oder IntelliJ IDEA) – eine wichtige Vor-aussetzung, um hierzulande die erforder-liche Akzeptanz zu erfahren.

À propos hierzulande – seit Ende 2005ist Agitar auch in Deutschland vertretenmit einer kleinen Niederlassung in

München. Ein ent-sprechendes Wachs-tum vorausgesetztkann somit auch dererforderliche Supportvor Ort sicher gestelltwerden.

IDC hat erst kürzlichin einem Whitepaperden Agitator und dasDashboard unter dieLupe genommen. Alswesentlichen Vorteilhaben die Analystendabei herausgestellt,dass künftig Entwick-ler ihren Fokus mehrauf das Implementie-ren neuer Funktio-nalitäten innerhalbeines Software Pro-jektes legen könnenund weniger mitFehlerbehebungen

beschäftigt sein werden. Basierend aufdiesem Ergebnis konnten nachvollziehba-re und fundierte Return on InvestmentRechnungen aufgestellt werden, die ineinem so genannten ROI Calculator aufder Webseite www.agitar.com der Allge-meinheit bereitgestellt werden. Hier kannjedes Unternehmen in wenigen Schrittenüberprüfen, in wie weit ein Optimie-rungspotential vorliegt.

Jürgen Triep

Abb. 2: Das Dashboard von Agitar, eine übersichtliche Darstellung des aktuellen State of the Art im Testbereich


Automotive

Vertikal 2|2006 31

ie MKS Integrity Suite wird beizahlreichen anderen bekanntenAutomobil-Herstellern und Zu-

lieferern wie Continental, Daimler-Chrysler, Ford, Hella, Knorr-Bremse,Robert Bosch oder Wabco in derSoftware-Entwicklung eingesetzt. Deshalbist MKS seit mehr als einem Jahr Mitgliedder Automotive Open System Architec-ture (AUTOSAR). Diese Initiative verschiedener Automobil-Hersteller undZulieferer setzt sich für die Standardisie-rung von Systemfunktionen und Schnitt-stellen in der Automobil-Elektronik ein.Eines der damit verbundenen Ziele ist dieWiederverwendbarkeit von Software-Modulen. In dieser Richtung sind beiMKS bereits erste Pilotprojekte entstanden.

Vernetztes Anforderungsmanagement & Engineering

Moderne Software-Entwicklung für dieAutomobil-BrancheDie MKS Integrity Suite bringt eine wesentliche

Verbesserung der Software-Qualität, hohe

Datenkonsistenz, größere Genauigkeit in der Planung

sowie die Nachvollziehbarkeit aller Abläufe innerhalb

des gesamten Lifecycle einer Applikation.

D

Die moderne Software-Entwicklung im Griff: Entscheidend sind Transparenz und eine Single-Architektur für alle Abläufe 5048. (Grafik: MKS GmbH)

IT für die Automobilindustrie – ITA


Automotive

Vertikal 2|200632

Die passende Version für jeden KundenEin typisches Beispiel für den umfassen-den Einsatz der MKS Integrity Suite zeigtKonzernbereich Continental AutomotiveSystems (CAS) der Continental AG – einmaßgeblicher Anbieter für Systeme,Komponenten und Ingenieurleistungenfür Fahrzeugsicherheit, Komfort undAntrieb. Seit 1999 entwickeln weltweitrund 700 Mitarbeiter sicherheitskritischeSoftware an 14 verschiedenen Standortengleichzeitig mit diesem System. Früherkam es vor, dass Software zum Testen aneinen Kunden ausgeliefert wurde, ohnespäter deren Dateien und Revisionsständenachvollziehen zu können. Eine durch-dachte Workflow- und Change-Manage-ment-Lösung stellt heute sicher, dassjeder Kunde die richtige Version erhält.Gleichzeitig können Komponenten oderModule der Software wieder verwendetund eine Verbesserung der Testtiefeerreicht werden.

Die MKS-Lösung überwacht und steu-ert den gesamten Lifecycle der entwickel-ten Software. Das beginnt bereits beimRequirements Management (Anforde-rungsmanagement). In dessen Rahmenwerden Fakten zu jedem neuen Projektgesammelt und erfasst. Neben den Unter-nehmenszielen für dieses Projekt ist jedesDetail der Leistungsanforderungen fest-gehalten. Bei einem erfolgreich abge-schlossenen Requirements Managementbefinden sich alle Anforderungen mit derzur Verfügung stehenden Zeit, dem Bud-get, den Zielen der Fachabteilungen undder IT-Infrastruktur im Einklang. Fallsnicht, wird über das Projektziel neu ver-handelt.

Exakte Planung vermeidet unnötigen EntwicklungsaufwandDer große Vorteil des RequirementsManagement liegt darin, dass bei konse-quenter Anwendung noch vor Beginn der

Entwicklungsarbeit eine Risikobewer-tung des IT-Projekts erfolgen kann. Erstdanach kommt das ›Go‹ zur Implemen-tierung oder es ist eine erneute Überprü-fung der Anforderungen und Ziele not-wendig.

Entscheidend für den Erfolg einesEntwicklungsprojekts ist die Transparenz,die ein Application Lifecycle Manage-ment System wie die MKS Integrity Suitevon den Anforderungen über Entwick-lung und Test bis zur erfolgreichen Aus-lieferung bietet. Alle Mitwirkenden sindin den Prozess integriert und könnenimmer den aktuellen Status und dieZeitschiene einsehen. Da bei weltweitaktiven Unternehmen wie Continentaldie Beteiligten auf unterschiedlicheStandorte verteilt sind, werden allenInformationen in einem Daten-Reposi-tory an einer zentralen Stelle abgelegt.Über Web-Anbindung ist der Zugriffjederzeit und von jedem beliebigen Ortaus möglich.

Darüber hinaus hat die Vereinheitli-chung länderspezifischer Arbeitsweisenzu einer weitaus besseren Transparenz inder Entwicklung geführt. Das Ergebniswaren weniger Fehlermöglichkeiten undeine deutlich verkürzte Entwicklungszeit.Die Wiederverwendung von Software-modulen hat sich sehr positiv auf dieTesttiefe der Software ausgewirkt.

Das professionelle Workflow-Manage-ment der MKS-Integrity-Lösung ermög-licht die einfache Einführung und Ände-rung neuer Prozesse. Das macht sowohlÄnderungen in der Software als auch diedazu gehörigen Anforderungen nachvoll-ziehbar. Somit ist eine aktive Verfolgungjeder Änderung auf allen Ebenen gewähr-leistet. Tritt ein Fehler in einer Software-Komponente auf, werden über einen Ver-wendungsnachweis sofort alle davonbetroffenen Applikationen identifiziert.Außerdem kann die MKS-Integrity-Lö-sung durch standardisierte Schnittstellen

als Expertensystem genutzt werden, dasalle relevanten Daten in aggregierterForm liefert. Diese Funktion ist zur Ent-scheidungsfindung und -unterstützung heute nicht mehr wegzudenken.

Einbeziehung externer Partner in den Requirements ManagementProzessMit verschiedenen Partnern hat MKSSchnittstellen zwischen der IntegritySuite und ergänzenden Lösungen geschaf-fen. Artisan zum Beispiel, der führendeAnbieter von kooperativen Modellie-rungstools für Anforderungsanalyse,Spezifikation, Design und Entwicklungkomplexer Applikationen, verbindet Soft-ware- und Systemmodellierung mittelsUML 2.0 direkt mit dem RequirementsManagement von MKS.

ILC PROSTEP, ein Spezialist für Inte-grationslösungen für mySAP PLM, bietetdie Integration von Product LifecycleManagement als Gesamtlösung inZusammenarbeit mit MKS. Ein weitererPartner, die Mummert ISS GmbH, liefertBranchen-neutrale Produkte für dieSoftware-Entwicklung an. Dazu gehört einumfangreiches Test-Framework für dascomputerunterstützte Testen komplexerAnwendungsprogramme. Das einfacheZusammenspiel zwischen RequirementsManagement und Test Management istdie Brücke zu einer besseren Software.

Holger Schmiedefeldt

... die Vereinheitlichung länderspezifischer Arbeitsweisen hat zu einer weitaus besseren Transparenz in der Entwicklung geführt.

Der Autor ist Director Business Development bei der MKS GmbH in Esslingen bei Stuttgart


Vertikal 2|2006 33

Anzeige mit Postkarten MKs

Impressum & Inserentenverzeichnis

Chefredakteur:Albert F. Absmeier

Verlagsanschrift:ap Verlag GmbH Bahnhofstr. 1585560 EbersbergTel.: +49 8092 24702 - 0Fax: +49 8092 24702 - 29Homepage: www.ap-verlag.deE-Mail: [email protected]

Herausgeber:Albert F. Absmeier

Geschäftsführer:Philipp K. Schiede, Albert F. Absmeier

Urheber- und Verlagsrechte:Alle in dieser Zeitschrift veröffentlichten Beiträgesind urheberrechtlich geschützt. Kein Teil dieserZeitschrift darf außerhalb der engen Grenzen desUrheberrechtsgesetzes ohne schriftliche Geneh-migung des verlages in irgendeiner Form – durchNachdruck, Kopie, Mikrofilm oder andere Ver-fahren – reproduziert oder in eine von Maschinen,insbesondere von Datenverarbeitungsanlagenverwendbare Sprache übertragen werden.Entsprechendes gilt auch für die sonstige Ver-breitung, insbesondere in elektronischen Medien.

Anzeigenagentur:MSP Media Service PartnerBöhmerwaldstr. 1585560 EbersbergTel.: +49 8092 852 088Fax: +49 8092 87 544

Grafische Bearbeitung:present perfect! GmbH, Oberhaching

Druckerei:Druckerei und Verlag E. Meyer GmbH,Neustadt a. d.Aisch


Automotive

Vertikal 2|200634

chon die Herkunft vom Hasso-Plattner-Institut lässt vermuten,dass es sich mit Arcway Cockpit

nicht nur um ein neues Produkt handelt, sondern dass sich auch eine durchdachteund wissenschaftlich erprobte Methodedahinter verbirgt. Dieser Verdacht erhär-tet sich, wenn man einen genaueren Blickauf das Unternehmen Arcway AG wirftund Prof. Dr. Siegfried Wendt, denGründungsrektor des Hasso-Plattner-Instituts als Vorsitzenden des wissen-schaftlichen Beirats findet. Prof. Dr.Siegfried Wendt gehört zu den wenigenschillernden Persönlichkeiten der deut-schen Universitätsszene, die immer wieder mit fundierten, aber auch polari-

Neue Produkte im Anforderungsmanagement

Definieren und Model-lieren statt ProgrammierenDass Anforderungsmanagement derzeit einen Hype auf dem Markt darstellt, ist

unumstritten. Dies zeigt schon alleine die Entwicklung der REConf, einer Fachkon-

ferenz zum Thema Anforderungsmanagement, die seit Jahren einen 2-stelligen

Zuwachs im Bereich der Teilnehmerzahlen verzeichnet. Da überrascht es nicht,

dass auch neue Produkte auf den Markt kommen, die ein Stück vom großen

Kuchen abhaben möchten. Neuester Kandidat ist das Unternehmen Arcway AG,

ein Spin-Off des Hasso-Plattner-Instituts aus Potsdam.

S


Automotive

Vertikal 2|2006 35

sierenden und rhetorisch brilliantenVorträgen auf sich aufmerksam machen.

Geschäftsidee von Arcway ist, dieweder sicht- noch greifbare Konstruktionkomplexer Softwaresysteme mit anschau-lichen Bildern zu erklären und IT-Vorgänge in ein zentrales Bild, ein BigPicture, zu fassen.

Das Arcway Cockpit unterstützt beider Erstellung von Spezifikationen (wiezum Beispiel dem Lastenheft oder demPflichtenheft), der Ansatz von Arcwayzielt dabei auf die besonders frühe Phaseim Anforderungsmanagement, die gleich-zeitig auch die kritischste ist: Da, wo zweiWelten auf einander prallen, wo dieFachabteilung ihre Vorstellungen der ITAbteilung mitteilt. Hier wird oft in zwei"Sprachen" miteinander kommuniziertund hier ist der Ursprung einer Vielzahlvon Problemen anzusiedeln, die im späte-ren Verlauf des Software Entwicklungs-zyklus festzustellen sind.

Ebenso geeignet ist das Arcway Cockpitin der Phase der Angebotserstellung, umeinerseits dem Auftragnehmer die not-wendige Sicherheit für die Vertragsver-handlung zu geben und andererseits demAuftraggeber die erforderliche Transpa-renz des Angebots aufzeigen zu können.

Das Produkt eignet sich zum Einsatz inkleineren bis mittleren Projekten, woman nicht mit einer Vielzahl überdimen-sionierter Software-Entwicklungswerk-zeuge einen unnötigen Projektoverheaderzeugen möchte. Demzufolge umfasstdas Arcway Cockpit die wichtigstenBestandteile, die in derartigen Projekt-typen von Bedeutung sind, angefangenvon Projektmanagementfunktionalitäten,über unterschiedliche Modellierungs-möglichkeiten bis hin zu einem professio-nellen Anforderungsmanagement. Abbil-dung 1 vermittelt einen ersten Eindruckvon dem Produkt. Als Beispielprojektwurde hier die Erstellung dieses Sonder-heftes ”Anforderungsmanagement in derAutomobilindustrie” gewählt.

Fundamental Modeling Concept als BasisZiel von Arcway ist es also, eine Art Kom-munikationsplattform bereitzustellen,

eine visuelle Darstellung komplexer Pro-jektzusammenhänge. Arcway bietet dazuAbstraktionskonzepte, die es ermögli-chen, die arbeitsteiligen Planungs- undAusführungsprozesse zu optimieren. DieBasis der Arcway Methode bildet das vonProf. Wendt entwickelte FundamentalModeling Concept (FMC). Hier insbe-sondere die Blockdiagramme und Pro-zessdiagramme. Details zu dem Funda-mental Modeling Concept können derWebseite www.f-m-c.org entnommenwerden.

Kernpunkt dabei ist die systematischeVisualisierung komplexer Zusammen-hänge, wie zum Beispiel zwischenAnwendungs- und Systemarchitekturensowie Prozessen in Form eines BigPictures. Das Besondere an der Methode:Durch die Reduzierung auf das Notwen-dige, ist sie unkompliziert und schnell zuerlernen. Selbst Nichttechniker sindinnerhalb kürzester Zeit in der Lage, ihreVorstellungen eines IT-Systems darzustel-len und bei der Analyse mitzuwirken –genau das, was sonst nicht der Fall ist,wenn eine Fachabteilung ihre Vorstellun-gen einer zu entwickelnden Software inAnforderungen ausdrücken soll.

Ein zentrales Element in ArcwayCockpit sind Konstruktionspläne – so,wie ein Architekt den Bauplan für einHaus zeichnet, oder ein Ingenieur eine

technische Zeichnung anfertigt, zeichnetman mit Arcway Cockpit Konstruktions-pläne für das System, welches als Ergebnisdes jeweiligen Projektes entstehen soll.Die Konstruktionspläne vereinfachen dieKommunikation zwischen Experten ausverschiedenen Disziplinen und gebendem Projektleiter einen detaillierten undpräzisen Überblick über das Projekt. Esgibt verschiedene Typen von Konstruk-tionsplänen, die jeweils einen bestimmtenAspekt des zu beschreibenden Systemsvisualisieren. So gibt es beispielsweiseeinen Plantyp, mit dem der Aufbau desSystems modelliert wird und anderePlantypen, mit denen man die Einbin-dung von Abläufen und Prozessen imSystem darstellen kann.

Die systematische Strukturierungvon Projektdaten sind ein weiteres zentra-les Element, dabei handelt es sich um all-gemeine Informationen (zum Beispieloffene Punkte, Vorgänge, Anforderungenoder Dokumente), die im Laufe einesProjektes entstehen und Konstruktions-pläne detaillieren bzw. ergänzen. SolcheProjektdaten können in Arcway Cockpitverwaltet und mit Konstruktionsplänenverknüpft werden. Die Informationenstehen damit zentral zur Verfügung undsind schnell auffindbar.

In Abbildung 1 wurden bereits Projekt-pläne und Tätigkeiten eingeführt – dieTätigkeiten dienen unter anderem dazu,

Abb. 1: Das Arcway Cockpit zeigt hier formulierte Anfor-derungen mit ihren wesentlichen Attributen sowieProjektpläne.


Automotive

Vertikal 2|200636

den Fortschritt des Projekts zu verfolgen.Dazu wird von den Projektmitarbeiterndie schon geleistete Arbeit und diegeschätzte noch verbleibende Arbeitregelmäßig aktualisiert. Ferner existiertauch noch ein Dokument-Modul, diesesverwaltet Verknüpfungen zu Webseitenund Dateien. Diese Verknüpfungen wer-den in Dokumentencontainern zusam-mengefasst.

Darstellung von AnforderungenBei der Erfassung von Anforderungen(dargestellt in Abb. 2) werden die we-sentlichen Attribute erfasst, angefangenvon der Kategorie über die Klassifizierungbis hin zu ausführlichen Angaben hin-sichtlich des Risikos. Eine Versionierungder Anforderungen wird ebenfalls vorge-nommen, ein Zeitstempel gibt Auskunft,wann die letzte Änderung durchgeführtwurde und es lassen sich die verschiede-nen Versionen miteinander vergleichen.

Die einzelnen Anforderungen lassensich untereinander in Abhängigkeit setzen(Siehe Abb. 2, Reiter: Verweise). In einemseparaten Fenster können diese Abhän-gigkeiten der Anforderungen untereinan-der dann grafisch angezeigt, vergleichbarzu einer Impactanalyse kann man so aufeinen Blick erkennen, welche zusätzlichenAnforderungen betroffen sind, wenn maneine bestimmte Anforderung ändert.Hierzu kann eine einzelne Anforderungselektiert werden und es werden nur nochdiejenigen Anforderungen angezeigt,

welche mit dieser in einer Abhängigkeitstehen, die also von einer Änderungbetroffen wären.

Neben Anforderungen stellen beiArcway Cockpit die bereits eingangsangesprochenen visuellen Modelle wieFMC (Fundamental Modeling Concept)Block- und Prozessdiagramme, Prozess-skizzen und UML-Klassendiagrammesowie UML-Sequenzdiagramme einenzentralen Aspekt dar. Zur Modellierungder Architektur stehen zum Beispiel dieFMC Blockdiagramme zur Verfügung,die einen wesentlichen Beitrag zumErreichen eines Big Pictures liefern.Prozesse und Abläufe werden mit Hilfevon FMC Petrinetzen und UMLSequenzdiagrammen dargestellt. Diesesollen in diesem Beitrag jedoch nichtnäher betrachtet werden, da sie denRahmen dieses Beitrags sprengen wür-den. Sie stellen ein wesentliches Elementinnerhalb des Arcway Cockpits dar undwerden Gegenstand eines weiterenArtikels in einer der künftigen Ausgabender manage it sein. Entscheidend ist, dass im ArcwayCockpit sämtliche Projektdaten mit Plan-elementen über Drag&Drop verknüpftwerden können. Planelemente sind visuelle Repräsentanten für bestimmteModellelemente, wie zum Beispiel Kom-ponenten der Softwarearchitektur oderSchritte eines Geschäftsprozesses. Mitdem Arcway Cockpit lassen sich Spezifi-

kationsdokumente wie Lasten und Pflich-tenhefte als auch gesamte Projektdoku-mentationen erzeugen.

Diese Projektdokumentation ist einstrukturiertes Dokument, dass sämtlichePläne und Projektdaten enthält. Es kön-nen sowohl Inhalt als auch Stil derDokumente über Vorlagen konfiguriertwerden. So ist es bei entsprechenderVorlage möglich, ein Lasten- oder einPflichtenheft auf Knopfdruck zu erstel-len.

FazitArcway bezeichnet zu Recht sein Cockpitals das Schweizer Offiziersmesser für Pro-jekte: Es vereint die wichtigsten Diszipli-nen wie Anforderungsmanagement,Projektplanung, Architekturmodellie-rung und andere Funktionen in einer flexiblen und vielseitigen Lösung, die ins-besondere die Projektfrühphase abdeckt.

Dr. Frank Keller

Abb. 2: Spezifizierung einer Anforderung inArcway – die wesentlichen Attribute sind bereitsvorgegeben und können so vollständig ausgefülltwerden.

Veranstaltungshinweis:Subversion Workshop am 23.02. in MünchenDas Open Source Versionsverwaltungs-system Subversion wird zurecht als derlegitime Nachfolger von CVS gesehen.Darüber hinaus hat Subversion in denletzten Jahren bewiesen, dass es durch-aus auch eine "Open Source" Alternativezu sogenannten kommerziellen Syste-men darstellt. In einem halbtägigenWorkshop, durchgeführt von PolarionSoftware GmbH, werden die folgendenThemen behandelt:[[ Konzepte, Installation und Konfigura-

tion von Subversion[[ Integration von Subversion in beste-

hende Entwicklungsumgebungen[[ Einsatz von Command Line, GUI,

TortoiseSVN[[ Migration von bestehenden Versions-

verwaltungssystemenDie Kosten je Teilnehmer liegen bei 99 €.Veranstaltungsort ist das Novotel an derNeuen Messe München, die Zielgruppesind: Projektleiter, Abteilungsleiter, ChiefArchitect, Konfigurationmanager.Alle Teilnehmer erhalten eine CD mit Sub-version 1.3, Maven, SVN Converter, SVN WebClient und SVK. Anmeldung unter www.polarion.com


Enterprise Resource Planning

Passende LösungPARATEine ausgediente Software und stetiges Wachstum des Unternehmens erforderten

bei der »Parat Automotive« eine neue Lösung. Den gewachsenen Anforderungen

soll die ERP-Software Psipenta gerecht werden.

er Audi TT hat eins und derBMW Z4 auch – die Cabrio-dachsysteme der Parat Auto-

motive Schönenbach GmbH & Co. KG.Dabei fing 1945 alles mit der Herstellungvon Ledertaschen an. Heute umfasst dieProduktpalette neben Schalen- undNotebook-Koffern auch Tiefzieh- undKaschierteile aus Kunststoff sowieCabrio-Stoffdachsysteme für die Auto-mobilindustrie. Das Familienunterneh-men hat neben dem Hauptsitz inRemscheid und einem weiteren Produk-tionsstandort in Neureichenau auchNiederlassungen in Rumänien, Ungarn,Österreich und seit Februar 2002 in den

USA. Rund 500 Mitarbeiter in Deutsch-land und weitere 775 in den übrigenNiederlassungen machen Parat zu einemleistungsstarken Zulieferer der Auto-mobilindustrie.

Neue Bedürfnisse – neue Lösung.Mit dem Wachstum der Firma und derEntwicklung in verschiedenen Bereichenwurde das Unternehmen vor eine neueHerausforderung gestellt: Die bisherigeAnwendung deckte die benötigten Funk-tionalitäten nicht mehr ab und konnteauch die Jahrtausendproblematik nichtbewältigen. »Wir mussten uns nach neuenMöglichkeiten am Markt umsehen. Die

D

Automotive

Vertikal 2|2006 37


Automotive

Vertikal 2|200638

derzeitige Software wurde unseren Bedürf-nissen nicht mehr gerecht«, schildert IT-Leiter Georg Hansbauer die damaligeSituation. Neue Versionen der Softwarestanden nicht zur Verfügung, da der alteSystemzulieferer vom Markt verschwun-den war. Es wurde eine Projektgruppegebildet, die nach einer Lösung suchensollte. Sie verschaffte sich einen Überblicküber den Markt und wählte möglicheERP-Software Anbieter im Vorfeld aus.Anhand des von allen Abteilungen erstell-ten Pflichtenhefts prüfte das Projektteam,welcher Anbieter die Anforderungenerfüllte. Schließlich präsentierten zweiERP-Anbieter ihre Produkte vor derGeschäftsführung und den Fachbereichs-leitern.

Highlight Multisite.Bei der Entscheidungsfindung spielte dieMultisite- oder Mehrwerkefähigkeit einewichtige Rolle. Mit der Funktion lassensich sämtliche logistischen Abläufe zwi-schen Werken automatisieren. Kapazitä-ten können so effektiver ausgelastet wer-den. Bestände aller Läger sind perKnopfdruck auf einen Blick verfügbar.Nicht zuletzt, weil die Berliner PsipentaSoftware Systems GmbH die größteFunktionalität bot und ein offenes, flexi-bles System präsentierte, konnte sie denAutomobilzulieferer für sich gewinnen.»Für unseren neuen Softwarelieferantensprach auch die professionelle Objekt-programmierung. Wir können jetzt aufjedes Objekt einzeln zugreifen«, erläutertHansbauer. Heute sind weltweit neunWerke in einem Multisite-Verbund.

Mit dem neuen System kam eine Reihevon Verbesserungen dazu. Mussten früherRechnungen zwischen den Werkengeschrieben und auf Papier ausgedrucktwerden, funktioniert dieser Vorgang jetztdank Multisite automatisiert als interneWerksrechnung. Auch zeigt das Systemden Anwendern, welche Artikel zu wel-chem Zeitpunkt bestellt werden müssen,damit die Fertigung nicht zum Erliegenkommt. Der neu eingerichtete Leitstandermöglicht jetzt eine Verknüpfung derverschiedenen Fertigungsabschnitte.

Diese Vorgänger-Nachfolger-Bezieh-ung zeigt dem Fertigungsplaner, wann einVorgänger fertig oder teilfertig ist und woder Nachfolger beginnen kann. Produk-

tionsstillstände und Fertigungsstaus kön-nen so vermieden werden. »Wir wissenüber jeden Start- und Endtermin der ein-zelnen Arbeitsstände sowie über die gesamteFertigungslaufzeit Bescheid«, erklärtHelmut Wagner, Sachbearbeiter Disposi-tion bei Parat.

Workshops für die Kollegen.Mitarbeiterschulungen hielten die Psipenta-Berater für die so genanntenKeyuser zentral in Berlin ab. Die Parat-Mitarbeiter aus den Filialen Remscheidund Neureichenau lernten dort dieAnwendung und Bedienung des neuenSystems. In anschließenden Workshopsschulten die Keyuser wiederum ihreKollegen in den Werken. Heute arbeitenin allen Bereichen mehr als 200 User mitder neuen Software. Die anfänglicheSkepsis der Mitarbeiter gegenüber einerneuen Software und der damit mittelfris-tig verbundene Mehraufwand in derEinführungsphase haben sich schnellgelohnt. Auch nach dem reibungslosenEchtstart bleibt das Softwarehaus präsent.Tritt eine Fehlermeldung auf, hilft dieDatenleitung von Neureichenau nach

Berlin. Die Störung kann dann gemein-sam analysiert und behoben werden. Ander Zusammenstellung der neuen 7er-Version des ERP-Standards hat Parat inArbeitskreisen und Workshops mitge-wirkt und damit einen aktiven Beitrag zurReleasepolitik geleistet. So wird derZulieferer noch in diesem Jahr auf dasneue Psipenta-Release migrieren und dieNeufunktionalität nutzen.

Durch die Einführung der PSI-Soft-ware optimierte der Automobilzuliefererdie Materialflüsse und erzielte eine deut-lich bessere Auslastung seiner Maschinen.Die Amortisation der Software-Investi-tion gelang überraschend schon im zwei-ten Betriebsjahr. Durch die bessere Über-schaubarkeit seiner Abläufe kann er seinen Kunden Pünktlichkeit bezüglichder Lieferungen zusichern. »Es wird der-zeit eine Ausweitung des Systems auf weite-re Werke im Ausland überlegt«, erläutertHansbauer die Zukunftspläne des Unter-nehmens.

Durch die passgenaueERP-Software optimiertder Automobilzuliefererden Materialfluss undverbessert die Auslas-tung seiner Maschinen.

Die Amortisation der Software-Investition gelangschon im zweiten Betriebsjahr.

www.parat-automotive.dewww.psipenta.de


Automotive

Vertikal 2|2006 39

Neue Produkte im Anforderungsmanagement

Neue Ansätze im Anforderungsmanagement

Die Polarion Software GmbH, ein international tätiger

Anbieter einer Unified Software Development Platform,

hat die neue Version 2.0 von Polarion angekündigt. Im

Zentrum steht dabei Requirements Management – und

das mit einem innovativen und vor allem an der Praxis

orientierten Konzept, das sich Live Documents [1] nennt.


nforderungsmanagementproduktegibt es mittlerweile einige auf demMarkt – manche sind gut manche

weniger – doch eins haben die meistengemeinsam: Sie sind bereits seit einigenJahren auf dem Markt und haben dahereine Vielzahl von "Altlasten" zu tragen.Manche hinterlassen auch den Eindruckeiner etwas intelligenteren Tabellenkalku-lation mit aufgesetzten Datenbankfunk-tionalitäten.

Die Stuttgarter Polarion SoftwareGmbH, gegründet im Jahr 2004, profi-tiert hier von der "Gnade der spätenGeburt" und hat mit Polarion einProdukt auf den Markt gebracht, das aufeiner völlig neuen Basis aufsetzt – voll-ständig webbasiert und um wichtigeFunktionalitäten des Projektmanage-ments angereichert.

Für die Inhalte der Version 2.0, die voreinigen Monaten der Öffentlichkeit vor-gestellt wurde, hat man sich mit einerVielzahl von Anwendern unterhalten unddabei festgestellt, dass RequirementsManagement nach wie vor dokumenten-orientiert vorgenommen wird. Dabei hateine empirische Untersuchung ergeben,dass die folgenden drei Ausgangssituatio-nen gegeben sind:[[ Unabhängig davon, mit welchem

Werkzeug Anforderungen erfasst werden, der eigentliche Umgang mit Anforderungen (die Kommunikation der Anforderungen) ist nach wie vor dokumentenbasiert.

[[ Zur Analyse von Anforderungen bzw. zum tagtäglichen Handling werden typische Funktionalitäten eines relatio-nalen Datenbankmanagementsystems benötigt (klassische SQL-Abfragen)

[[ Microsoft Word und Microsoft Excel sind die klassischen Produkte, die branchenübergreifend zum Handling von Dokumenten eingesetzt werden.

Auf Basis dieser Erkenntnisse wurdenbereits existierende RequirementsManagement Werkzeuge analysiert undman hat festgestellt, dass meist nur zweider obigen Ausgangssituationen Rech-nung getragen wird. Daher wurde mit derVersion 2.0 nun erstmals ein Produktdem Markt präsentiert, das alle dreiAspekte verinnerlicht und somit das ideale Werkzeug für das Anforderungs-management darstellt.

Technologisch wurde dieser Ansatz inPolarion wie folgt umgesetzt: Basierendauf dem Single Source Konzept wird jedeAnforderung gespeichert – die unter-schiedlichen Anwender:[[ Manager, [[ Entwickler, [[ Analyst, [[ Requirements Engineer, [[ usw.haben jedoch jeweils unterschiedlicheSichten auf die Anforderungen – entspre-chend ihrer Projektrollen. Die Anforde-rungen werden dabei direkt in derProduktionsumgebung gespeichert – derKunde kann hier selbst entscheiden, ob erSubversion oder NetWeaver nutzenmöchte. Damit wird auch die erforderli-che Traceability sichergestellt.

Ein weiteres Ziel von Polarion ist dieAuflösung der so genannten Automati-sierungsinseln, dargestellt in Abbildung 1.Derartige Inseln entstehen durch dieschrittweise Einführung bestimmterProdukte (zum Beispiel für das Testen,das Anforderungsmanagement oder dieVersionsverwaltung), ohne dass diese auf-einander abgestimmt sind. Jedes dieserWerkzeuge definiert ein neuesDatenmodell, neue Zugangsberechti-gungen, ein neues Daten-Repository usw.Die daraus resultierenden Probleme lie-gen auf der Hand und so mancher Her-steller hat hier versucht mit einem sogenannten ALM (Automated LifecycleManagement) Ansatz eine Lösung anzu-bieten.

Polarion gehört hier zu den Herstellern,die sich im Umfeld der CollaborativenSoftware Entwicklung bewegen und einevollständige Entwicklungsumgebung an-bieten, die solche Inseln vermeidet. Basisdessen ist der so genannte Single SourceAnsatz. Auf diese Art existieren alleProjektinformationen nur einmal in derEntwicklungsumgebung. Als Beispielkann man einen Testplan sehen, der wäh-rend der Anforderungsspezifikation er-stellt wird. Der Testplan muss sowohl mitden Anforderungen, aus denen er ent-standen ist, verbunden sein als auch mitdem Defect, der während der Implemen-tierung gefunden wurde – niemals miteiner Kopie des Testplans.

Der Live ApproachIn engen Zusammenhang zum SingleSource Ansatz ist der Live Approach [2]zu sehen, der auf diesem Ansatz aufsetztund den Umgang mit Projekt Informa-tionen beschreibt. Dabei können dreiBereiche von diesem Live Approach pro-fitieren: [[ Die Unternehmensführung, [[ das Anforderungsmanagement und [[ das Projekt-Management.

Eine solche neue Generation vonWerkzeugen und Methoden verbindetdirekt Anforderungsdefinition, Projekt-Planung und Unternehmensführung mitder Entwicklung und hält das Entwick-lungsteam agile ohne Zusatzarbeit undAblenkung.

Der Live Approach ist keine Methodewie XP, SCRUM oder RUP, es handeltsich vielmehr um einen Satz von Richt-linien, deren Ziel es ist, eine "Roadmap"für Software Entwicklungsumgebungenund Tools zu definieren, um unterschied-liche Entwicklungsmethoden zu unter-stützen. Damit wird eine bessereAnwendbarkeit verbunden mit LiveInformationen zum jeweiligen ProjektStatus erreicht.

Stefano Rizzo

Automotive

40

A

Abb. 1: Auflösung von Automatisierungsinseln

Vertikal 2|2006

Literatur:[1] www.polarion.com [2] Live Approach Org.see http://www.liveapproach.org



Automotive

Vertikal 2|200642

n diesem vielfach vernetzten Ge-flecht muss sichergestellt werden,dass die Anforderungen für ein

bestimmtes Projekt oder eine geplanteVariante jedem Mitarbeiter in allen betei-ligten Teams in der aktuellen Versionzugänglich sind. Gleichzeitig müssen ver-trauliche Informationen geschützt wer-den, sowohl beim Hersteller als auchbeim Zulieferer. Um im Bild zu bleiben:die auszutauschenden Informationenmüssen auf dem schnellsten Weg kom-muniziert werden – über das Autobahn-netz – und sie müssen am richtigen Ortankommen – ohne das Risiko auf derLandstraße den falschen Abzweig zu wäh-len.

Entwicklungsprojekte in der Automo-bilindustrie haben immer interdisziplinä-ren Charakter: eine Vielzahl unterschied-licher Komponenten und Subsystememüssen am Ende ein lauffähiges Gesamt-system ergeben, das den definiertenAnforderungen entspricht. Dabei sind dieeinzelnen Teile in der Regel heterogen;

es gibt Elektronik-, Software-, Mechatro-nik-, elektrische und mechanische Kom-ponenten, die von verschiedenen Ent-wicklungsbereichen des Herstellers odervon Zulieferern beigestellt werden. DieKomponenten existieren bereits, sie wer-den neu entwickelt, oder sie werdendurch Anpassung oder Weiterentwick-lung aus vorhandenen Komponentenhergeleitet. Es entsteht ein äußerst kom-plexes Projekt-Szenario von Beziehungenund Abhängigkeiten, die sowohl horizon-tal (Abteilungs-, Bereichs- oder Unter-nehmensübergreifend) als auch vertikal(auf der Zeitachse) zu betrachten und zukontrollieren sind. Dass bei einem sol-chen Projekt am Ende ein Ergebnis steht,dass dem ursprünglich vereinbarten Ziel-profil entspricht, ist eigentlich nur demZufall zu verdanken – es sei denn, mandefiniert und implementiert einen klarstrukturierten Prozess, der alle Akteure inihren unterschiedlichen Rollen (undorganisatorischen Einheiten) über dieganze Projektlaufzeit einbezieht.

Vernetztes Anforderungsmanagement & Engineering

Autobahnnetz oder LandstraßeAnforderungsmanagement in der Automobilindustrie ist

an Komplexität kaum zu überbieten. Der Hersteller bin-

det spezialisierte Zulieferer in Entwicklung und

Produktion ein, während der Zulieferer wiederum meh-

rere Hersteller mit Varianten seiner Erzeugnisse belie-

fert und seinerseits gegebenenfalls weitere Zulieferer

einbindet.

I


Automotive

Vertikal 2|2006 43

Die wichtigsten Elemente eines an-forderungsgetriebenen Design- und Ent-wicklungsprozesses sind:

[[ Erfassung und Aktualisierung des Ziel-profils. Alle sinnvollen Quellen müssenzur Sammlung, Analyse und Bewertungder Anforderungen beitragen (können).Auch Negativ-Aussagen (Einschränkun-gen), oder zulassungsrelevante Anfor-derungen gehören zum Zielprofil. Die Aktualisierung des Zielprofils muss möglich sein, um Änderungen von Anforderungen nach Beginn der Rea-lisierung gerecht zu werden.

[[ Kommunikation des Zielprofils. Alle an der Realisierung beteiligten Teams innerhalb und außerhalb des Unter-nehmens müssen jederzeit Zugriff haben auf die für sie relevanten An-forderungen in der aktuellen Version. Es kann notwendig sein, das Zielprofilim Verlaufe des Projektes an aktuelle Gegebenheiten anzupassen, daher ist Kommunikation keine Momentauf-nahme sondern eine das Projekt begleitende Notwendigkeit.

[[ Kontrolle des Zielprofils. Es reicht nicht zu wissen, wohin man will, wennkeine Navigationshilfen zur Verfügungstehen. Der kontinuierliche Abgleich des aktuellen Standortes mit dem an-gestrebten Ziel ist unerlässlich für die zielführende Projektkontrolle und Steuerung.

[[ Test des Zielprofils. Der Nachweis, dass die implementierten Funktionen einwandfrei laufen, ist bestenfalls ein Zwischenergebnis. Viel wichtiger für den Projekterfolg (und den Unterneh-menserfolg) ist der Nachweis, dass die implementierten Funktionen dem ver-einbarten Zielprofil entsprechen.

Dieser Prozess verfolgt den Weg derAnforderungen von den Marktinforma-tionen bis hin zu Testfällen für einzelneFunktionen. Ausgehend von der Mengeder relevanten Marktinformationen wer-den die Anforderungen für ein neuesModell oder eine Variante hergeleitet. DieSumme der Anforderungen wird struktu-riert und aufgegliedert in Teilmengen füreinzelne Versionen, und die Anforde-rungsspezifikation wird erzeugt. Diesedient als Grundlage für die Erarbeitung

der Menge der Eigenschaften und Funk-tionen, die ebenfalls versionsabhängigvariieren können. Um sicherzugehen,dass das entstehende System auf dieErfüllung der Anforderungen hin getestetwird und nicht auf die tatsächliche Imple-mentierung, wird die Generierung derTestfälle ebenfalls in diesen Ablauf inte-griert.

Die Teilmengen der Informationsele-mente – Anforderungen, Eigenschaftenund Testfälle – die einzelnen Versionenzugeordnet sind, können dabei überlap-pen, so dass ein Element in mehrerenVersionen enthalten sein kann. Dabeikann dieses Element selbst auch wieder inunterschiedlichen Versionen vorhandensein, um den einzelnen Versionen best-möglich zu entsprechen.

Damit ein solcher Prozess für alle amProjekt beteiligten Mitarbeiter anwend-bar wird, muss die Werkzeugumgebungeine Reihe von Leistungskriterien erfül-len. Gerade die Möglichkeit, dass Anfor-derungen gleichzeitig in verschiedenenAusprägungen für unterschiedliche Ver-sionen existieren, ist in der Automobilin-dustrie kein exotischer Einzelfall.

Die Dynamik der heutigen Marktent-wicklung macht es unmöglich, bereits imVorfeld alle Anforderungsspezifikationenvollständig zu sammeln und für diegesamte Projektlaufzeit festzuschreiben.Gleichzeitig stellt sich die Aufgabe, meh-rere einander ähnliche Varianten zu ent-wickeln, um den besonderen Marktan-forderungen der Länder gerecht werdenzu können, in denen das Modell einge-führt werden soll.

Eine Lösung für dieses Problem istdynamisches Anforderungsmanagement.Dynamisches Anforderungsmanagementermöglicht das professionelle und effekti-ve Managen von Anforderungen, die imVerlauf eines komplexen und inkremen-tellen/iterativen Entwicklungsprojekteskontinuierlich wachsen und sich verän-dern können. Es erlaubt die Weiterent-wicklung und Ableitung der Anforderun-gen entsprechend dem Projektfortschrittund stellt Kontrollmechanismen bereit,um Änderungswünsche, Projektumfang,entstehende Kosten, Qualität des Ergeb-nisses und Auslieferungszeitpunkt in Ein-klang zu bringen.

Eine Implementierung von dynami-schem Anforderungsmanagement liefertTelelogic DOORS®, das bei vielen nam-

haften Unternehmen der Automobilin-dustrie für Anforderungsmanagementund Requirements Engineering eingesetztwird. Zu den besonderen Leistungsmerk-malen von DOORS zählt zum Beispieldie übersichtliche Darstellung aller rele-vanten Elemente auf einen Blick. DOORSrealisiert dynamisches Anforderungsma-nagement mit intelligenter Traceability,Markierung kritischer Links und demLifecycle Change Management System(LCM). Die intelligente Traceability stelltsicher, dass alle Teams und Anwender mitden für die aktuell bearbeitete Versionkorrekten Anforderungen arbeiten.Verknüpfungen von Anwenderanforde-rungen, Systemanforderungen und Test-fällen (Links) werden mit der korrektenBaseline in Verbindung gebracht, so dassdie Konformität mit fortschreitendemProjekt jederzeit gesichert ist.

Abb. 2: Die intelligente Traceability stellt Anforderungen und Testfälle in einen Versionskontext


Besonderes Merkmal der intelligen-ten Traceability ist die Tatsache, dass auchdie Historie und Varianten berücksichtigtwerden und somit ein vollständiger Audi-tierungslauf unterschiedlicher Entwick-lungsstränge ermöglicht wird. Entwick-lungsteams, die an unterschiedlichenVersionen arbeiten, können parallel vor-gehen.

Das Prinzip der Markierung kritischerLinks stellt sicher, dass alle Benutzer kon-tinuierlich über Änderungen, die vonanderen Benutzern vorgenommen wer-den, informiert werden, sofern diese fürden individuellen Arbeitsbereich relevant

sein könnten. DOORS generiert aktiveine Änderungsmitteilung direkt in dasAnforderungsdokument, so dass hiernichts mehr übersehen werden kann. DieAuswirkungen einer Änderung könnensehr schnell abgeschätzt werden undunterstützen die Entscheidung, ob ent-sprechende Aktivitäten erforderlich sindoder die Markierung "kritischer Link"entfernt werden kann.

Lifecycle Change Management (LCM)bietet die umfassende Unterstützung fürManagement und sichere Kontrolle vonAnforderungsänderungen auf jeder Ebene– vom Gesamtsystem bis auf die

Detailebene – und ermöglicht darüberhinaus die Verfolgung der Implementie-rung von Änderungen. Dabei berücksich-tigt LCM sowohl unternehmensinterneals auch externe Projektszenarien, wie siegerade in der Automobilindustrie zurRegel geworden sind. LCM wird realisiertdurch die Integration von DOORS mitTelelogic SYNERGY™, dem führendenWerkzeug für Änderungs- undKonfigurationsmanagement.

Renate Stücka

eschäftsanforderungen bildendie Qualitäts-Messlatte in jedemSoftwareprojekt. Die prozesso-

rientierte Integration dieser Anforderun-gen in den Lebenszyklus einer Anwen-dung erhöht die Entwicklungs-Produk-tivität, sichert die Einhaltung vonZeitplänen und hebt die gesamte Qualitätder Lösung an.

In der Theorie klingt alles ganz plausi-bel: Das Anforderungs- oder Require-ments Management hat die Aufgabe, dieSicht des Anwenders einzunehmen. Dasist leichter gesagt als getan, denn derBenutzer, der genau weiß, was er will,muss zuerst noch erfunden werden. DieseErfahrung haben alle schon gemacht, dieim Kundenauftrag Software entwickeln,sei es in einer internen Entwicklungsab-teilung eines Großunternehmens oder beieinem externen IT-Dienstleister.

Interviewt man den potenziellenBenutzer einer Software, entwirft er eine

Wunschlösung, die eine Vielzahl vonSonderfällen abbildet. Die Basisanforde-rungen jedoch sind so selbstverständlich,dass der Anwender sie häufig übergeht.Mehr noch: Im Verlauf der Zeit ändernsich Anforderungen, sie sind nicht sta-tisch. Wird der gleiche Anwender achtMonate nach dem ersten Interviewerneut befragt, sehen die Anforderungenganz anders aus.

Manche Entwicklungsorganisationenhaben in der Vergangenheit zur Erfassungvon Anforderungen ihre eigenen Verfah-ren verwendet, sei es mit einer Textverar-beitung oder Microsoft Excel. Haben sichAnforderungen im Laufes des Entwick-lungsprozesses gewandelt, wurden dieseoft ungeprüft übernommen. Von einemdefinierten Änderungsprozess kann manin solch einem Fall natürlich nicht spre-chen. Auch wenn das Verfahren nachSchnelligkeit und Flexibilität aussieht,birgt es doch enorme Risiken:

[[ Viele Änderungen passen nicht zusam-men, denn es existiert ja keine zentraleKoordinationsinstanz.

[[ Wo die Dokumentation der vorge-nommenen Änderungen fehlt, bleibt bis zum Auslieferungstermin unklar, welche Änderungen warum vorgenom-men wurden.

[[ Es ist nicht nachvollziehbar, warum bestimmte Änderungen vorgenommenwurden und andere nicht.

Ob bei einer Bank, einem Konsumgüter-hersteller oder einem Versicherungs-unternehmen eine neue Software erstelltbeziehungsweise vorhandene Lösungenzusammengeführt und um neue Funktio-nalitäten ergänzt werden, entscheidet dieGeschäftsleitung; in seltenen Fällenbefindet darüber auch der Leiter einesGeschäftsbereichs, so er über die dazubenötigten Finanzmittel verfügt.

Ist das angeforderte Produkt fertiggestellt, muss es von einem dazu befugten

Automotive

Vertikal 2|200644

Anforderungsmanagement – etablierte Produkte

G

Prioritäten setzen auf der Wunschliste


Gremium abgenommen werden. Erstdann geht die Software in den produkti-ven Betrieb über. Neben der Entschei-dung über die Softwarequalität lautet dieKernfrage: Wurden die anfangs definier-ten – möglicherweise in der Zwischenzeitangepassten – Anforderungen erfüllt?

Selbst wenn diese Frage mit ja beant-wortet wird, befinden letztlich die End-anwender über den Erfolg oder Miss-erfolg einer Applikation beziehungsweiseeines Softwareprojekts.

Requirements Management alsEckpfeiler der SoftwareentwicklungVon der anderen Seite aus aufgerollt: Werdas Anforderungsmanagement im Griffhat, befindet sich auf gutem Wege zumZiel. Die Vorgaben und Ansprüche an dieSoftwareentwicklung kommen heute vonmehreren Seiten: Kunden und Endbe-nutzer benötigen neue Features, die Ent-wickler neue Design-Modelle, die Quali-tätssicherung neue Testprozeduren, derService fordert die rasche Beseitigung vonBugs und alle zusammen wollen laufendneue Änderungswünsche realisiert sehen.

Im Idealfall werden all diese Anfragenvon Personen aufgegriffen, die in unter-schiedlichen Rollen (Fachabteilung,Systemdesign, Entwickler, Tester, etc.) indie Softwareentwicklung involviert sind.Sie müssen Change Requests (Ände-rungsanfragen, Anomalien, Fehlermel-dungen) in eine zentrale Ablage (Repo-sitory) eingeben können und sind viaAbfragen über den Stand der Fehler-behebung laufend orientiert. Durch denhohen Grad der Formalisierung werdenProjektmitarbeiter angehalten, Meldun-

gen strukturiert einzugeben. Da es mög-lich ist, jederzeit einen Request einzuge-ben, gehen keine Meldungen verloren.

Ein Change-Request-Team bewertet dieAnforderungen undweist die Requestseinem Bearbeiter zu,der dann für dieEinarbeitung der Än-derung verantwortlichist. Das gesamte Teamist damit idealerweiselaufend über Problemein einzelnen Moduleninformiert. Die Projekt-leitung kann Fehlereinfach analysierenund den Entwicklernzuweisen. Zudem istder Stand der Softwarejederzeit bekannt. Derhohe Grad der For-malisierung und Stan-dardisierung bei derVerfolgung der Change Requests und derVersionierung setzt ein Projekt- oderEntwicklungsteam in die Lage, bei Bedarfper Knopfdruck auch einen historischlange zurückliegenden Softwarestandwieder zu reproduzieren.

Das Gelingen eines Projektes hängtdamit wesentlich von der Fähigkeit ab,die Anforderungen zu steuern und dabeidie Vorgaben hinsichtlich Kosten undZeitplanung einzuhalten. In der Praxisder Softwareentwicklung lässt sich dasnur mit einem leistungsfähigen Manage-mentwerkzeug für Requirements undTraceability – also für das Management

von Anforderungen undderen Rückverfolgbar-keit – erreichen. Einesolche Lösung wie sieetwa Serena mit RTM(Requirements undTraceability Manage-ment) anbietet, musseine Reihe von Voraus-setzungen erfüllen: [[ Nutzung eines zen-

tralen, durchgängi-gen Repository für alle relevanten Informationen. Das Repository sollte

Internetfähig und beliebig skalierbar sein. Somit kann es auch in globalen Großprojekten eingesetzt werden. Das

Repository gewährleistet die vollstän-dige Rückverfolgbarkeit aller Arbeits-schritte im gesamten Entwicklungs-prozess

[[ Verwendung eines gängigen Editors und ein Web-User-Interface mit hohem Standardisierungsgrad

[[ Unterstützung für alle Daten-Formate,die ein Unternehmen in der Software-entwicklung benötigt, von Texten, über Tabellen und Grafiken bis zu Audio und Video

[[ Online-Zusammenarbeit von Entwick-lerteams in Echtzeit mit Live-Daten

[[ Darstellung von Anforderungen sowohl in Dokument- als auch in Objekt-Form. Ist die Anforderung genehmigt, muss sie zunächst im Dokument geändert werden und erst dann im dem anzupassenden Produkt

[[ Echte Baselines und Versionierung miteiner vollständigen Historie aller Änderungen.

Auf dieser Basis lassen sich sämtliche Vor-gänge im Entwicklungsprozess auf Unter-nehmensebene umfassend steuern undkontrollieren. Damit wird Software-Qualität auf hohem Niveau sichergestellt. Einer der Erfolgsfaktoren des Require-ments Management ist das Zusammen-wirken (Collaboration) aller Beteiligten.

Automotive

Vertikal 2|2006 45

Abb. 2: Gelegentliche Nutzer oder Mitarbeiter von Zulieferfirmen kön-nen Sammlungen (Collections) von Requirements in Word bearbeiten.Das Dokument wird per Knopfdruck generiert und ist dann vollwertigerRequirements-Editor. Nach Bearbeitung der Requirements können dieÄnderungen automatisch in die RTM-Datenbank zurückgespielt wer-den, dabei kann jede Änderung individuell ausgewählt oder verworfenwerden.

Abb. 1: Serena RTM: Eine spezielle gesplittete Darstellung zeigt ver-knüpfte Requirements aus zwei Klassen. Damit können Zusammenhängekontrolliert werden.


Automotive

Vertikal 2|200646

Dies wird erleichtert durch die Verwen-dung bekannter Werkzeuge zur Erfassungund Dokumentation von Anforderungenetwa mit dem gewohnten Texteditor. Erstdurch die Verknüpfung der Requirementsmit Attributen wie geschätzte Kosten,Zeitaufwand oder eine Prioritätenvergabefinden die Anforderungen Eingang in dasRepository, wo sie dann für Abfragenautorisierter Benutzer bereit stehen.Somit lassen sich jederzeit auch zu einemspäteren Zeitpunkt die sich darananschließenden Entscheidungsprozessenachvollziehen.

Während der Phasen der eigentlichenUmsetzung der Requirements gilt esmehrere Arten von Informationen wieAnforderungen, Design, Testvorgabenund -ergebnisse, Kosten, Fehlermeldun-gen etc. zu erfassen und kontinuierlich zuverwalten. Notwendig ist damit eine voll-ständige Transparenz des gesamtenLebenszyklus einer Applikation.

Ganzheitliche Sicht auf denApplication LifecycleVerdeutlichen lässt sich dies durch einelogische IT-Sicht auf die zentralen Kate-gorien eines Unternehmens: Mitarbeiter,IT-Werkzeuge und IT-Bestände (Hard-ware und Software). Diese logischenKomponenten sind vielfach miteinanderverflochten:

[[ Die Mitarbeiter üben verschiedene funktio-nale und organisatori-sche Rollen wie Abtei-lungsleiter, Projekt-manager, Entwickler, Tester oder andere aus.

[[ Ihren Rollen angemes-sen verwenden die Mitarbeiter unter-schiedliche IT-Werk-zeuge wie Programme für die Verwaltung von Verträgen, Help-Desk-Lösungen, integrierte Entwicklungsumgebungen, Testwerkzeuge oder Tools für die Qualitätssicherung.

[[ Mit IT-Werkzeugen administrieren dieMitarbeiter ein umfangreiches Spek-trum von IT-Beständen; diese umfas-sen sowohl Software (eigenentwickelte und zugekaufte Applikationen, Daten oder Webinhalte) als auch Hardware (Mainframes, Unix-, Linux- und Win-dows-Server sowie Netzwerk-Router und Switches).

Ein wesentliches Problem besteht nundarin, dass einzelne Werkzeuge (Entwick-lungsumgebungen, Standardsoftware,Administrations-Tools) und die vonihnen erzeugten und verwalteten Daten-bestände als in sich geschlossene Insel-lösungen nebeneinander existieren. Dieunterschiedlichen Tools wissen nichtsvoneinander, Mitarbeiter können Infor-

mationen und IT-Bestände nur in selte-nen Fällen gemeinsam nutzen undProjektleiter oder Vorgesetzte habenkaum die Möglichkeit, bei anstehendenÄnderungen funktionsübergreifende, einheitliche Abläufe und Prozeduren zudefinieren und für deren Einhaltung zusorgen. Nachhaltige Fortschritte könnenhier nur erzielt werden, wenn die IT-Funktionen enger mit den operativenBereichen des Unternehmens zusammen-wachsen.

Zusammenfassend bleibt festzuhalten,dass ein möglichst effizientes Manage-ment der Anforderungen bereits beimEndbenutzer beginnt und den gesamtenLebenszyklus einer Software umfasst. MitBlick auf diesen ganzheitlichen Lifecyclehat Serena in einer eigens dafür geschaffe-nen Architektur SAFE (Serena Appli-cation Framework for Enterprises) dieerforderlichen Komponenten neu defi-niert und setzt diese Architektur strate-gisch um. Nicht alles dabei wird neu ent-wickelt. Vielmehr werden vorhandeneProdukte, Individual-Applikationen undzugekaufte Software nahtlos in dieseArchitektur eingepasst. Für die Steuerungder Prozesse wird Serena TeamTrack ein-gesetzt. Diese Komponente ist auch dasKernstück für das Request Management.

Hans-Joachim Erchinger

In ihrer Rolle als Soft-waretechniker führenMitarbeiter folgende,beispielhafte Aktivi-täten aus:

[[ Gab oder gibt es in anderen Projekten ähnliche Requirements?

[[ Arbeitet schon jemand an einer Lösung?

[[ Könnte ein früherer "Soft-warefix" das vorliegende Problem verursacht haben?

[[ Wer hat den Sourcecode geändert?

[[ Welche Änderungen gab es?

[[ Wie wurde getestet?

In ihrer Rolle"Qualitätssicherung"führen Mitarbeiter folgende, beispielhafteAktivitäten aus:

[[ Welche Änderungen haben die Entwickler gemacht?

[[ Was ist zu testen?

[[ Welches Problem wurde gemeldet?

[[ Welche Funktionen sind neu?

[[ Wie lässt sich die Erfüllung des Requirements testen? Wird nur getestet, was neu ist?

Abb. 3: In der Trace-Darstellung können alle mit dem Requirement ver-knüpften Objekte, seine Historie, Diskussionsbeiträge etc. angezeigtwerden. Aus dieser Darstellung kann von jedem angezeigten Objektwiederum der entsprechend weiterführende Trace aufgerufen werden.


