Beitrag die Herausforderungen für das Variantenmanagement in Anforderungsdokumenten



Ähnliche Dokumente
Ist Excel das richtige Tool für FMEA? Steve Murphy, Marc Schaeffers

Gezielt über Folien hinweg springen

Mobile Intranet in Unternehmen

Informationssystemanalyse Problemstellung 2 1. Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse:

iphone- und ipad-praxis: Kalender optimal synchronisieren

MORE Profile. Pass- und Lizenzverwaltungssystem. Stand: MORE Projects GmbH

Application Requirements Engineering

Wo sind meine Anforderungen?

Konzept Themenkarte zur Verbesserung von Reviews

Advance Steel Nachverfolgung von Änderungen während der Revisionsphasen im Projekt

mobifleet Beschreibung 1. Terminverwaltung in der Zentrale

Lineargleichungssysteme: Additions-/ Subtraktionsverfahren

AGROPLUS Buchhaltung. Daten-Server und Sicherheitskopie. Version vom b

etutor Benutzerhandbuch XQuery Benutzerhandbuch Georg Nitsche

Elexis-BlueEvidence-Connector

[Customer Service by KCS.net] KEEPING CUSTOMERS SUCCESSFUL

Veröffentlichen von Apps, Arbeitsblättern und Storys. Qlik Sense Copyright QlikTech International AB. Alle Rechte vorbehalten.

CodeSaver. Vorwort. Seite 1 von 6

How to do? Projekte - Zeiterfassung

Speicher in der Cloud

SWOT-Analyse. Der BABOK V2.0 (Business Analysis Body Of Knowledge) definiert die SWOT-Analyse wie folgt:

Matrix42. Use Case - Sicherung und Rücksicherung persönlicher Einstellungen über Personal Backup. Version September

Rundung und Casting von Zahlen

Abschluss Version 1.0

Erstellung von Reports mit Anwender-Dokumentation und System-Dokumentation in der ArtemiS SUITE (ab Version 5.0)

Konzentration auf das. Wesentliche.

PRÜFMODUL D UND CD. 1 Zweck. 2 Durchführung. 2.1 Allgemeines. 2.2 Antrag

Feiertage in Marvin hinterlegen

SERVICE SUCHE ZUR UNTERSTÜTZUNG

Pflegeberichtseintrag erfassen. Inhalt. Frage: Antwort: 1. Voraussetzungen. Wie können (Pflege-) Berichtseinträge mit Vivendi Mobil erfasst werden?

Nicht kopieren. Der neue Report von: Stefan Ploberger. 1. Ausgabe 2003

Dokumentation. Black- und Whitelists. Absenderadressen auf eine Blacklist oder eine Whitelist setzen. Zugriff per Webbrowser

Qualitätsmanagement: Dokumentieren. Kontrollieren. Verfolgen.

Datenübernahme in ein Produkt der Lexware premium, professional oder plus line

ACHTUNG: Voraussetzungen für die Nutzung der Funktion s-exposé sind:

E-Sourcing einfach, effizient und erfolgreich

Outlook. sysplus.ch outlook - mail-grundlagen Seite 1/8. Mail-Grundlagen. Posteingang

Würfelt man dabei je genau 10 - mal eine 1, 2, 3, 4, 5 und 6, so beträgt die Anzahl. der verschiedenen Reihenfolgen, in denen man dies tun kann, 60!.

Hilfe Bearbeitung von Rahmenleistungsverzeichnissen

DIE NEUE PROMOLENS. Herausforderungen und Antworten

Abschnitt 2 Vier Fragen, jeweils 5 Punkte pro Frage erreichbar (Maximal 20 Punkte)

1 Einleitung. Lernziele. automatische Antworten bei Abwesenheit senden. Einstellungen für automatische Antworten Lerndauer. 4 Minuten.

Terminabgleich mit Mobiltelefonen

I n f o r m a t i o n s s i c h e r h e i t i n G e m e i n d e n B e v ö l k e r u n g s z a h l < 6 000

Geyer & Weinig: Service Level Management in neuer Qualität.

1 Mathematische Grundlagen

Wichtiges Thema: Ihre private Rente und der viel zu wenig beachtete - Rentenfaktor

mobilepoi 0.91 Demo Version Anleitung Das Software Studio Christian Efinger Erstellt am 21. Oktober 2005

Anleitung über den Umgang mit Schildern

Mit dem Tool Stundenverwaltung von Hanno Kniebel erhalten Sie die Möglichkeit zur effizienten Verwaltung von Montagezeiten Ihrer Mitarbeiter.

FRILO-Aktuell Ausgabe 2/2013

White Paper. Fabasoft Folio Zugriffsdefinitionen Winter Release

2. Psychologische Fragen. Nicht genannt.

Maschinenrichtlinie 2006/42/EG 150 Fragen und Antworten zum Selbststudium

Erstellung des integrierten kommunalen Klimaschutzkonzeptes. für die Samtgemeinde Sottrum

Fünf einfache Schritte

Arbeitshilfen Messecontrolling Wie geht denn das?

Beispielfragen L4(3) Systemauditor nach AS/EN9100 (1st,2nd party)

07. November, Zürich-Oerlikon

DIE SICHERE ENTSCHEIDUNG!

ECDL Europäischer Computer Führerschein. Jan Götzelmann. 1. Ausgabe, Juni 2014 ISBN

«PERFEKTION IST NICHT DANN ERREICHT, WENN ES NICHTS MEHR HINZUZUFÜGEN GIBT, SONDERN DANN, WENN MAN NICHTS MEHR WEGLASSEN KANN.»

Ist Fernsehen schädlich für die eigene Meinung oder fördert es unabhängig zu denken?

Externe Abfrage von für Benutzer der HSA über Mozilla-Thunderbird

impact ordering Info Produktkonfigurator

ecaros2 - Accountmanager

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem

15 Social-Media-Richtlinien für Unternehmen!

Informationssystemanalyse Lebenszyklusmodelle 3 1. Lebenszyklusmodelle sollen hauptsächlich drei Aufgaben erfüllen:

Begriff 1 Begriff 2 Datenbank 1

Nutzung von GiS BasePac 8 im Netzwerk

Anleitung mtan (SMS-Authentisierung) mit SSLVPN.TG.CH

Arbeitsgruppen innerhalb der Website FINSOZ e.v.

2.5.2 Primärschlüssel

MARCANT - File Delivery System

Erläuterungen zur Untervergabe von Instandhaltungsfunktionen

Melde- und Veröffentlichungsplattform Portal (MVP Portal) Hochladen einer XML-Datei

MULTIWEB Banking. Installation und Update unter Windows

Lehrer: Einschreibemethoden

Test zur Bereitschaft für die Cloud

Online Intelligence Solutions TESTABLAUF. 7 Schritte für ein erfolgreiches Testing.

Generative Prozessmodelle Patrick Otto MDD Konferenz

Synchronisations- Assistent

Tutorial about how to use USBView.exe and Connection Optimization for VNWA.

CTI SYSTEMS S.A. CTI SYSTEMS S.A. 12, op der Sang. Fax: +352/ L Lentzweiler. G.D.

Erfolgreiche ITIL Assessments mit CMMI bei führender internationaler Bank

Anwenderdokumentation Prüfung nach dem Heilmittelkatalog

Änderung des IFRS 2 Anteilsbasierte Vergütung

Kurzanleitung bezüglich erforderlicher Rechnungsdaten

Was sind Jahres- und Zielvereinbarungsgespräche?

teamsync Kurzanleitung

104 WebUntis -Dokumentation

M e r k b l a t t. Neues Verbrauchervertragsrecht 2014: Beispiele für Widerrufsbelehrungen

Leseprobe. Bruno Augustoni. Professionell präsentieren. ISBN (Buch): ISBN (E-Book):

Tech-Clarity Perspective: Best Practices für die Konstruktionsdatenverwaltung

4. BEZIEHUNGEN ZWISCHEN TABELLEN

Kontenaktualisierung in Lexware buchhalter

Mean Time Between Failures (MTBF)

HR-Herausforderungen meistern

Jetzt neu: Online Reporting Schritt für Schritt durch das Online Reporting (OLR) Online Liedmeldung

Transkript:

Herausforderungen fürvariantenmanagement in Anforderungsdokumenten Ekaterina Boutkova Group Research and Advanced Engineering Daimler AG Postfach 2360 89013 Ulm ekaterina.boutkova@daimler.com Abstract: Effektive Methoden für Variantenmanagement in Anforderungsdokumenten sind die essentielle Voraussetzung für eine effektive und effiziente Wiederverwendung von Anforderungen, die zu einer Entwicklungszeitreduktion und somit zu einem Wettbewerbvorteil führt. Dieser Beitrag beschreibt die aktuelle Vielfalt der Anforderungsdokumente eines Automobilherstellers am Beispiel der Daimler AG. Außerdem stellt dieser Beitrag die Herausforderungen für das Variantenmanagement in Anforderungsdokumenten vor, die während einer Studie zu existierenden Variabilitätsmanagementansätzen bei der Daimler AG identifiziert wurden. 1 Einleitung Die Automobilindustrie ist durch eine große Anzahl an Produktvarianten charakterisiert. Die Gründe für die Variantenvielfalt sind vielseitig. Alsein prominentesbeispiel können im Fall der PKW-Sparte der Daimler AG die Modellreihen (z.b. C-Klasse, E-Klasse oder S-Klasse) betrachtet werden. Dabei werden für jedes Modell mehrere Ausführungsarten (z.b. Limousine, Coupé, T-Modell, Cabriolet) und Ausstattungsvarianten (z.b. Classic, Elegance) angeboten, die die unterschiedlichen Kunden- bzw. Marktanforderungen berücksichtigen. Mit der steigenden Komplexität der Fahrzeuge sind auch die Anforderungen an die einzelnen Komponenten und Systemen immer vielfältiger geworden. Reichte früher eine Zeichnung und Stückliste für die Anforderungsdokumentation einer Komponente, so ist heute ein umfassendes Lastenheft erforderlich. Ein Lastenheft bündelt die Anforderungen aller im Produktentstehungsprozess beteiligten Bereiche (z.b. Entwicklung, Produktion) und bildet die Basis für die Ausschreibung. Die Schwächen eines Lastenheftes (z.b. unvollständige oder fehlerhafte Anforderungen) führen häufig zu einer Vielzahl von Änderungen und Terminverzögerungen im Entwicklungsprozess und damit zur Kostenüberschreitung. 329

Die Reduktion der Entwicklungszeit durch die Wiederverwendung ist der Leitgedanke der letzten Jahrzehnte in der Automobilindustrie. Die Anforderungsdokumente in der Automobilindustrie bieten ein großes Wiederverwendungspotential ist ein effektives und effizientes Variantenmanagement. Die effektive Methoden des Variantenmanagements für Anforderungsdokumente sind die Voraussetzung für die erfolgreiche Wiederverwendung von Anforderungen, weil das Variantenmanagement die Spezifizierung mehrere Produkte einer Produktlinie durchwiederverwendung von Anforderungen unterstütz. Das Ziel unserer Arbeit ist eine Verbesserung des Variantenmanagements in Lastenheften. In diesem Beitrag wird die Welt der Anforderungsdokumente bei der Daimler AG vorgestellt (Kapitel 2). Daraus folgende Herausforderungen für das Variantenmanagement werden im Kapitel 3 präsentiert. Kapitel 4 beschreibt die aktuellen und geplanten ArbeitenindiesemGebiet. 2 Anforderungsmanagement bei der Daimler AG Dieses Kapitel präsentiert die Vielfalt der Anforderungsdokumente bei der Daimler AG (Kapitel 2.1) sowie die aktuellen Ansätze zum Variabilitätsmanagement (Kapitel 2.2). 2.1 Anforderungsdokumente Für die Dokumentation der Anforderungen bei der Daimler AG existieren im Wesentlichen drei Typen von Lastenheften: das Fahrzeuglastenheft, das Systemlastenheft sowie das Komponentenlastenheft. Für jeden Lastenheft-Typ existieren entsprechenden Standardvorlagen, die den Entwicklungs- und Spezifikationsprozess durch die Verwendung standardisierter Inhalte und Anforderungspakete unterstützen. Ein Fahrzeuglastenheft (FLH) enthält eine umfangreiche Beschreibung des neuen Fahrzeugs. Im FLH werden zum Beispiel die Marketingaspekte (z.b. Zielgruppen, Produktpositionierung auf den Märkten), Designanforderungen und technischen Konzepte des neuenfahrzeuges festgehalten. Ein Systemlastenheft (SLH) bildet die Brücke zwischen den Anforderungen andas Gesamtfahrzeug und den Anforderungen an die einzelnen Komponenten. Ein System ist in diesem Fall kein physikalisches sondern ein logisches. Es besteht aus Fahrzeugfunktionen, die ein Kunde benutzen kann (z.b. Außenlicht, Sitzheizung), deren Eigenschaften sowie deren Komponentenbeschreibungen, die diese Funktionalität realisieren. Die Notwendigkeit des SLH entsteht aus der Problematik, die Komponentenanforderungen direkt aus Fahrzeuganforderungen vollständig und widerspruchsfrei abzuleiten. Das SLH ist eine interne Spezifikation und wird in der Regel nicht an den Lieferanten weiter gegeben. 330

Ein Komponentenlastenheft (KLH) dokumentiert die Anforderungen aneine einzelne Komponente (z.b. eine Sonnenblende, einen Stoßfänger). Es bildet die Basis für die Ausschreibung und den Vertrag mit dem Lieferanten. In einem KLH werden sowohl technische alsauch nichttechnische (z.b. prozessuale) Anforderungenandie Komponentenentwicklung und spätere Serienproduktion dokumentiert. Die Anforderungen im KLH müssen alle beschlossenen Varianten (Farbvarianten, Ausstattungsvarianten, Ländervariantenetc.) umfassen. Die Beziehungen zwischen einzelnen Lastenhefttypen sind nicht 1:1 (siehe Abbildung 1), weil ein System in mehreren Fahrzeuge) implementiert werden kann. Des Weiteren können mithilfe ein und derselben Komponente die unterschiedlichen Systemfunktionen realisiert werden. Zum Beispiel die Komponente Türschloss realisiert sowohl die Funktionendes Systems Schließung alsauchdie dessystems Außenlicht. Zusätzlich kanndas System Schließung kann mit gleichen Anforderungen für mehrere Baureihen verwendet werden. FLH A-Klasse SLH Schließung KLH Türschloss FLH B-Klasse SLH Außenlicht KLH Abbildung1:Die Beziehungen zwischen FLH-SLH-KLH 2.2 Variantenmanagement in Anforderungsdokumenten Die Systeme und Komponenten für die verschiedenen Baureihen weisen oft nur geringe Unterschiede auf. Deshalb existiert ein großes Potenzial für die Wiederverwendung der Anforderungen. Diese Erkenntnis erlaubt es, die Varianten eines Systems bzw. einer Komponente im gleichen Lastenheft zuspezifizieren. Wichtig ist, dass alle Anforderungen eines Lastenhefteszuden jeweiligenbaureihen und Varianten nachvollziehbar zugeordnet sein müssen, um die Erstellung von baureihenspezifischen Lastenheften für eine System- bzw. Komponentenvariante zu ermöglichen. Diese Lastenhefte werden für die Ausschreibungen benötigt, da die Lieferanten eine Spezifikation für eine konkrete Komponentenvariante, die für eine bestimmte Baureihe festgelegt wurde, benötigen. In diesem Beitrag werden die existierenden Ansätze benannt und deren Vor- und Nachteile kurz vorgestellt. Die vollständige Studie zu dem State-of-the-Practice kann aus [Bo08] entnommen werden. Im Rahmen der Studie zum State-of-the-Practice wurden folgende Ansätze identifiziert, analysiert und bewertet: 1. VariantendokumentationimAnforderungstext 331

2. VariantendokumentationinAttributsspalten 3. Variantendokumentation mit Multi-Enumeration-Attribut 4. Variantendokumentationdurch Kapitelstruktur 5. VariantendokumentationinunterschiedlichenDoors-Modulen 6. VariantendokumentationimAnforderungspool 7. Ansatz mit Stücklistencode zur Variabilitätsbeschreibung (Code-Regel-Ansatz) Zu den Vorteilen dieser Ansätze gehören eine einfache Handhabung (1-4), eine transparente Zuordnung von Anforderungen zu den Varianten sowie die Verbindung mit Stücklisten (7). Zu den Nachteilen gehören ein hoher Aufwand und eine hohe Fehlerwahrscheinlichkeit bedingt durch die manuelle Zuordnung sowie die fehlende Möglichkeit diese Zuordnung zu überprüfen. Außerdem skalieren diese Ansätze schlecht. Bei einer großen Anzahl von Varianten geht der Überblick schnell verloren. Ein zusätzlicher Nachteil des Code-Regel-Ansatzes ist eine nicht intuitive Anwendung der verwendeten Codes. 3 Herausforderungen für Variantenmanagement In diesem Kapitel werden Herausforderungen für das Variantenmanagement beschrieben, die während der Analyse der existierenden Variantenmanagementansätze in Lastenheften bei der Daimler AG identifiziert wurden. 3.1 Umfang und Heterogenität der Lastenhefte Die meisten Lastenhefte bei der Daimler AG sind sehr groß. Ein Lastenheft für eine Komponente beinhaltet zwischen 1.000 und mehreren 10.000 Anforderungen. Ein Lastenheft für ein System beinhaltet zwischen einigen 100 und mehreren 1.000 Anforderungen. Die unterschiedlichen Komponenten bzw. Systeme haben eine unterschiedliche Anzahl von variablen Anforderungen. Auch die Anzahl der Variabilitätsmerkmalen (Variabilitätskriterien und deren Ausprägungen) ist bei allen Komponenten bzw. Systemen unterschiedlich. Die Begriffe Variabilitätskriterium und Ausprägung des Variabilitätskriteriums wurdenals Spezifizierungdes Begriffs Merkmal in [Bo08] definiert. Ein Variantenmanagement-Ansatz für Lastenhefte muss alle diese Besonderheiten berücksichtigen. Der Ansatz muss skalierbar sein, so dass er sowohl für die Lastenhefte mit mehreren 10.000 Anforderungen als auch für die Lastenhefte mit paar 100 Anforderungen anwendbar ist. Der Ansatz muss Lastenhefte mit wenigen sowie auch solche mit vielen variablen Anforderungen imgleichen Maße unterstützen. Außerdem muss der gesuchte Ansatz es erlauben, mehrere hundert Variabilitätsmerkmale zuverwalten. 332

3.2 Use Casesfür Variabilitätsmanagement Das Variantenmanagement in Lastenheften kann mehrere Use Cases unterstützen, einige davon werden in diesem Abschnitt vorgestellt. Die Voraussetzung für alle Use Cases ist, dass die Zuordnung von jeder einzelner Anforderung in der Spezifikation zu den ausgewählten Varianten immer bekannt ist. Im letzten Abschnitt wurden die typischen Umfänge von Lastenheften diskutiert. Somit es ist verständlich, dass der Aufwand für die Zuordnung von einzelnen Anforderungen zu Varianten enorm ist und dieses Zuordnungsproblem die größte Herausforderung für das Variabilitätsmanagement in Lastenheften darstellt. Die Entwicklung bzw. Weiterentwicklung einer Komponenten bzw. eines Systems geschieht inrahmen der Entwicklung eines neuen Fahrzeuges (einer neuen Baureihe). Für jede neue Baureihe werden entsprechend die neuen Lastenhefte erstellt. Viele Komponenten bzw. Systeme unterschieden sich von Baureihe zur Baureihe nicht existenziell. Deswegen werden oft die Anforderungen einer Baureihe als Basis für die neue Baureihe übergenommen und angepasst. Zum Beispiel können die Anforderungen für den Fensterheber einer E-Klasse für den Fensterheber der C-Klasse kopiert und an wenigen Stellen(z.B. Geometriedaten) angepasst werden. Eine andere Möglichkeit der Wiederverwendung von Anforderungen ist die Dokumentation von mehreren Varianten einer Komponente (bzw. eines Systems) im gleichen Lastenheft. Es ist möglich die Anforderungen für mehrere Baureihen (z.b. A-Klasse und B- Klasse) oder für unterschiedliche Varianten einer Komponente (z.b. Sonnenblende mit Beleuchtung und Sonnenblende ohne Beleuchtung) innerhalb einer Baureihe im gleichen Lastenheft zudokumentieren. Natürlich muss esmöglich sein, die Baureihen-Varianten und Komponenten-Varianten zusammen in einem Lastenheft zu dokumentieren. Für die Ausschreibung werden die Lastenhefte einer konkreten Variante bzw. einer Auswahl an Varianten benötigt, die für eine bestimmte Baureihe geplant sind. Um die Ausleitung von variantenspezifischen Lastenheften zu ermöglichen, ist eine nachvollziehbare Zuordnungvon Anforderungen zu Varianten unabdingbar. Ein weiterer Use Case ist die Verbindung der Anforderungen mit den Stücklistennummern. Das Wissen über die Zuordnung von Anforderungen zu Varianten kann die Verbindung zwischen Anforderungen und Stücklisten herstellen. Wenn diese Information zur Verfügung steht, erlaubt sie im Fall eines Fehlers, der während der Produktion auftritt, anhand der Komponenten-Teilenummer alle Anforderungen der fehlerhaften Komponente zu identifizieren. Danach kann die Korrektheit der Anforderung überprüft werden und bei Bedarf können die Gegenmaßnahmen durchgeführt werden. Außerdem wäre es möglich, anhand der Zuordnungsinformationen alle anderen Varianten dieser Komponenten, die die gleichen Anforderungenimplementieren, zu identifizieren. Die nachvollziehbare Zuordnung von Anforderungen zuvarianten unterstützt auch das Änderungsmanagement. Sollte eine Anforderung während des Entwicklungsprozesses geändert werden, so wäre es immer möglich, alle betroffenen Baureihen und Komponenten- bzw. System-Varianten zu identifizieren. 333

3.3Menschlicher Faktor Die Komponenten- und System-Anforderungen werden bei der Daimler AG von den Entwicklern spezifiziert. Als Experten im Bereich der Produktentwicklung sind sie entsprechend als Maschinenbauer oder Ingenieure ausgebildet. Der Großteil dieser Spezialisten hat jedoch kein umfangreiches Know-how in den Informatik- und Anforderungsmanagement-Bereichen. Die Hauptaufgabe eines solchen Spezialisten besteht in der Entwicklung von Systemen und System-Komponenten. Für die Erstellung eines Lastenheftes haben die Entwickler 2-6 Monate zur Verfügung. Nach der Erstellungsphase sind die Entwickler nur für die Änderungspflege in ihren Lastenheften zuständig. Die Zeitspanne zwischen der Erstellungvon neuen Lastenheftenbeträgt 3-5 Jahre. Daraus entsteht eine weitere Anforderung an den Variantenmanagement-Ansatz: Er muss die Fähigkeiten der zukünftigen Anwender berücksichtigen. Er muss einfach und intuitiv bedienbar sein. Die Software-Unterstützung muss es ermöglichen, das Variabilitätsmodell einfach grafisch zu visualisieren. Die Anwendung von Prädikaten-Logik oder programmier-ähnlichensprachen wird vonden potenziellen Anwendernnicht akzeptiert. 3.4 IT-Infrastruktur Für die Verwaltung von SLH und KLH wird das Tool Doors von IBM/Telelogic verwendet. Ein SLH bzw. KLH besteht aus einem bzw. mehreren Doors-Modulen, die jeweils mehrere tausend Doors-Objekte beinhalten können. Die Standardvorlagen für SLH und KLH sind als Kopiervorlagen in Form von Doors-Modulen verfügbar und bestehen aus circa 150 Seiten. Ein SLH bzw. KLH hat 1-2 Autoren, aber esexistieren auch Lastenhefte, andenen biszu40entwickler parallel arbeiten. Doors ist ein Standard-Tool bei der Daimler AG für das Anforderungsmanagement auf der System und Komponenten-Ebene. Daraus folgt, dass die Kompatibilität des Variantenmanagementansatzes mit Doors eine notwendige Bedingung darstellt. Anderseits muss der Variantenmanagementansatz eine tool-unabhängige Basis haben, um auch in Zukunft mit einem potenziell anderen Anforderungsmanagement-Tool funktionsfähig zu bleiben. 3.5 Landschaft der Lastenhefte Eine weitere Herausforderung sind die Standardvorlagen, die für alle Lastenheftstypen existieren. Ein Standardlastenheft beinhaltet einigen Standardanforderungen die nicht gelöscht oder verändert werden dürfen, aber auch die Kapitel, deren Befüllung der Entwickler komponentenspezifisch vornehmen muss (Verantwortlichkeiten, Termine, Gewichte). Weiterhin enthält die Standardvorlage KLH Kapitel, die dem Entwickler im Sinne einer Checkliste dienen und auf deren Basis der Entwickler die technische Anforderungenbeschreiben kann. 334

Die KLH-Standardvorlage besteht zurzeit aus circa 150 Seiten und wird ständig weiterentwickelt. Gründe für Änderungen der Standardvorlage sind Erfahrungen aus abgeschlossenen Projekten sowie Verbesserungen zu den identifizierten Defizienten in der existierenden Vorlage. In einigen Fällen kommt es auch zu Strukturänderungen der Standardvorlage. In einem solchem Fall müssen alle komponenten-spezifische Anforderungen neu angeordnet werden (siehe Abbildung 2). Derartige Umstrukturierungen von mehreren tausenden Anforderungen inmehreren hunderten Lastenheften sind sehr kostenintensiv. Deshalb wurde einkonzept zur Trennung voninhalten ausgearbeitet. Komponentenspezifische Anforderungen Anforderungen aus Standardvorlage Anforderungen aus Standardvorlage Komponentenspezifische Anforderungen Standard-KLH Version1.0 Standard-KLH Version 2.0 Abbildung2:Verteilung der Anforderungen nach denstrukturänderungen Die Grundidee ist die Teilung der Komponentenanforderungen in zwei Gruppen: die Anforderungen an die Komponente (definieren die Komponente selbst) und die komponentenspezifischen Projekt-, Produktions- und Logistik-Anforderungen. Die Anforderungen an eine Komponente werden in einem Anforderungspool verwaltet. Dabei sind in diesem Pool die Anforderungen für alle Baureihen sowie alle definierten Varianten enthalten. Bei der Erstellung eines KLH werden die relevanten Anforderungen aus dem Pool in die Kopie der Standardvorlage kopiert und bei Bedarf angepasst. Die komponentenspezifischen Projekt-, Produktions- und Logistik-Anforderungen werden weiterhin in einer Kopie der KLH-Standardvorlage gepflegt. Dieses Konzept bringt eine Reihe Vorteile mit sich. Zum Beispiel die Anforderungen an eine Komponente werden in einem Anforderungspool über den gesamten Produktentstehungsprozess dokumentiert. Der andere Vorteil ist, dass durch die Speicherung der Anforderungen in einem Anforderungspool die Wiederverwendung von Anforderungen unterstützt. Die Herausforderungen sind das Varianten- und Änderungsmanagement. Der Variantenmanagement-Ansatz muss die bestehende Lastenheft-Landschaft (FLH- SLH-KLH) und weitere existierende Konzepte, sowie die Existenz der Standardvorlagen berücksichtigen. 335

3.6 Interne und externe Variabilität Die aktuellen Spezifikationsprozesse sowie die Entwicklungsprozesse sind an die Entwicklung der Fahrzeugpalette gekoppelt. So werden bei der Entwicklung einer neuen Baureihe die existierenden Anforderungen für eine Komponente im Hinblick auf die Eigenschaften und Funktionalitäten eines neuen Produktes bewertet. Als Produkt kennzeichnen wir eine Komponenten-Variante, die zur Produktionausgewählt wurde. Baureihe/ Produkt gültig für Anforderungen Abbildung3:Aktuelle Zuordnung Die Analyse der Studie zuaktuellen Variantendokumentationsansätzen hat gezeigt, dass eine Trennung der internen und externen Variabilität notwendig ist. Die interne Variabilität beschreibt die Merkmale einer Komponente bzw. eines Systems, die variieren können (z.b. Farbe, Material). Die externe Variabilität beschreibt solche Aspekte, die die Gründe für die Existenz der internen Variabilität sind. Zum Beispiel existieren zwei Varianten der Tachometeranzeige: die Geschwindigkeit wird in km/h oder in mph angezeigt. Das Merkmal der internen Variabilität ist Geschwindigkeitsanzeige. Die externe Variabilität ist zum Beispiel Markt (z.b. Europa oder USA). Welche Anzeige in einem Fahrzeug eingebaut wird, hängt vom Zielmarkt ab. Durch diese Trennung entsteht ein neuesprozessbild (siehe Abbildung4). Bei der neuen Vorgehensweise werden die Anforderungen den Merkmalen (Variabilitätskriterien bzw. deren Ausprägungen) zugeordnet. Diese Zuordnung ist über die Zeit konstant. Neue Produkte, die als Konfigurationen der Variabilitätsmerkmale definiert sind, können dann zur jeweiligen Baureihen zugeordnet werden. Eine ähnliche Vorgehensweise (Product-Sets-Ansatz) wurde von Reiser und Weber in[rw05] vorgeschlagen. Baureihe/ Markt geplant für ausgewählt gültig Produkt Merkmal Anforderungen für für Abbildung4:Zielzuordnung Der Variantenmanagementansatz muss diese Trennung, sowie die Dokumentation der Zuordnungsentscheidungen unterstützen können. 3.7 Weitere Herausforderungen Außer der davor diskutierten Herausforderungen müssen folgende Herausforderungen beachtet werden: 336

- Alle Lastenhefte bei der Daimler AG werden meistens in natürlicher Sprache spezifiziert. - Die gleichen Anforderungen dürfen nicht mehrfach ineinem Lastenheft dokumentiert werden, um die Größe von Lastenheften nicht zu steigern. - Es muss möglich sein, innerhalb eines Lastenheftes einen Variantenvergleich durchzuführen. Also zu vergleichen, welche Anforderungen in einer Variante implementiert sind. - Die Anforderungen, die für alle Varianten gültigsind, müssenerkennbar sein. - Die Beziehungen zwischen einzelnen Variabilitätsmerkmalen müssen prüfbar sein, umdie Konsistenz der Varianten überprüfen zu können. - Die Zuordnung von Anforderungen zu Varianten muss automatisch überprüfbar sein, umdie Qualität der Lastenhefte zu garantieren. 4 Ausblick Parallel zur Analyse der existierenden Ansätze wurde eine umfangreiche Literaturrecherche durchgeführt, die in diesem Beitrag nicht vorgestellt wird. Basierend auf den Ergebnissen der Literaturrecherche und State-of-the-Practice wurden zwei Arbeitsthemen identifiziert. Das erste Thema beschäftigt sich mit dem Variantenmanagement (die Identifikation der Variabilitätsmerkmalen, Variabilitätsmodellierung und Auswahl der zulässigen Konfigurationen für die Systeme und Komponenten). Das zweite Thema beinhaltet die Zuordnung von AnforderungenzuVarianten in Lastenheften. Für den Bereich des Variantenmanagements können Ansätze aus der Literatur (z.b. [Be03], [B01], [CE00], [Ka90], [PBL05], [Re08], [TH03]) übernommen werden. Natürlich müssen die in der Forschung ausgearbeiteten Ansätze an die Herausforderungen der Praxis (siehe z.b. Kapitel 2) angepasst werden. Für die Variabilitätsmodellierung haben wir die Merkmalsmodelle anvisiert. Die Merkmalsmodellierung hat eine große Akzeptanz in der Praxis erfahren [Li03]. Auch bei der Daimler AG wird dieser Ansatz in der Design- und Implementierungsphase der internen Softwareentwicklungverwendet. Bei der Literaturrecherche wurde kein Ansatz gefunden, der sich mit der Zuordnung von Anforderungen zu Varianten beschäftigt. Basierend auf den identifizierten Problemen und Anforderungen der Entwickler sowie den Ergebnissen der Literaturrecherche wurde das Thema des Variabilitätsmanagements in Anforderungsdokumenten für meine Dissertation ausgewählt. Das Ziel meiner Arbeit ist es, eine Lösung für existierendes Problem der Zuordnungder AnforderungenzuVarianten zu finden. Literaturverzeichnis [Be03] M. Becker, Towards ageneral ModelofVariability in ProductFamilies, Proceedings of the 1st Workshop on Software Variability Management. Groningen, Netherlands, 2003. 337

[B001] [Bo08] [CE00] [CN01] [Ka90] [Li03] [PBL05] [Re08] [Te03] [RW05] J. Bosch, G. Florijn, D.Greefhorst, J. Kuusela, H. Obbink, K.Pohl, Variability Issues in Software Product Lines, Proceedings of PFE-4, 2001, pp. 11-19. E. Boutkova, Variantenmanagement inanforderungsdokumenten: Stateof thepractice. GI Fachtreffen, Karlsruhe,2008. K. Czarnecki, U. Eisenecker, Generative Programming. Addison-Wesley, 2000. P. Clements, L.Northrop, Software ProductLines:Practices andpatterns, SEI Series insoftwareengineering. Addison-Wesley, 2001. K. Kang, S. Cohen, J. Hess, W. Novak, S. Peterson: FeatureOriented Domain Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90-TR-021, 1990. H. Lichter, T.von der Maßen, A.Nyßen, T.Weiler, Vergleich von Ansätzen zur FeatureModellierung beider Softwareproduktlinienentwicklung, 2003. K. Pohl, G.Böckle, F. vander Linden, SoftwareProduct Line Engineering: Foundations, Principles, and Techniques. Springer Verlag, 2005. M.O. Reiser, Managing Complex Variability in Automotive Software Product Lines with Subscoping andconguration Links, Dissertation, TU Berlin,2008. J.C. Trigaux, P. Heymans, ModellingVariability Requirements insoftware Product Lines: Acomparativesurvey, Technical reportplenty project, Bel gium, 2003. M.O. Reiser, M.Weber, Using Product Sets todefinecomplex Product Decisions. In: H.Obbinkand K. Pohl (Hrsg.): SPLC 2005, LNCS3714, Springer-Verlag, pp. 21 32, 2005. 338