EPS SES EPS SES - Software and Systems Engineering - TUM

Abschlußbericht der Vordringlichen Aktion des
Bundesministeriums für Bildung und Forschung
Entwicklung, Produktion und Service
von Software für eingebettete Systeme
in der Produktion
Arbeitsgruppe Prof. Gausemeier
Heinz Nixdorf Institut
Universität Paderborn
Lehrstuhl Prof. Färber
Fakultät für Elektro- und
Informationstechnik
TU München
Lehrstuhl Prof. Broy
Fakultät für Informatik
TU München
EPS
SES
Entwicklung, Produktion und Service von
Software für eingebettete Systeme in der
Produktion"
Abteilung Prof. Pfeifer
Institut für
Produktionstechnologie
Frauenhofer Gesellschaft
Aachen
Arbeitsgruppe Prof. Schäfer
Fachbereich
Mathematik/Informatik
Universität Paderborn
Lehrstuhl Prof. Bender
Institut für
Informationstechnik im
Maschinenwesen
TU München
Bernhard Schätz, Michael Fahrmair, Michael von der Beeck,
Peter Jack, Hans Kespohl, Ali Koç, Benito Liccardi, Sandra
Scheermesser, Albert Zündorf

Dieses Forschungs- und Entwicklungsprojekt wird mit Mitteln des Bundesministeriums für
Bildung und Forschung (BMBF) innerhalb des Rahmenkonzepts „Produktion 2000“ gefördert
und vom Projektträger Produktion und Fertigungstechnologien, Forschungszentrum Karlsruhe
betreut.
Das vorliegende Dokument wurde im Rahmen der Vordringlichen Aktion „Entwicklung, Produktion
und Service von Software für eingebettete Systeme in der Produktion“ erstellt. Die
Durchführung der Arbeiten erfolgte durch die Projektpartner
• Lehrstuhl Prof. Dr. Manfred Broy, Fakultät für Informatik, Technische Universität München,
Projektleitung
• Lehrstuhl Prof. Dr. Klaus Bender, Institut für Informationstechnik im Maschinenwesen,
Technische Universität München
• Lehrstuhl Prof. Dr.-Ing. Georg Färber, Fakultät für Elektro- und Informationstechnik, Technische
Universität München
• Arbeitsgruppe Prof. Dr. Jürgen Gausemeier, Heinz Nixdorf Institut, Universität Paderborn
• Forschungsabteilung Prof. Dr.-Ing, Dr. h.c. Tilo Pfeifer, Institut für Produktionstechnologie,
Frauenhofer Gesellschaft Aachen
• Arbeitsgruppe Prof. Dr. Wilhelm Schäfer, Fachbereich für Mathematik und Informatik, Universität
Gesamthochschule Paderborn
Die Durchführung der Arbeit wurde durch einen Steuerkreis überwacht. Mitglieder des Steuerkreises
sind
• Dipl.-Ing. Knut Balzer, Robert Bosch GmbH, Zentralbereich Forschung und Vorausentwicklung,
Abteilung Produktionsinformatik und Logistik, Steuerkreissprecher
• Dr.-Ing. Lothar Borrmann, Siemens AG, Zentralabteilung Technik, Fachzentrum für Software-
und Systemarchitekturen
• Dr.-Ing. Robert Grob, DaimlerChrysler AG, Zentralbereich Qualitätsmanagement
• Dipl.-Ing. Erik Mertens, Projektträgerschaft Produktion und Fertigungstechnologien PFT,
Forschungszentrum Karlsruhe
• Dipl.-Ing. Claus Oetter, Fachgemeinschaft Software, VDMA Verein Deutscher Maschinenund
Anlagenbau e.V.
• Dr.-Ing. Rainer Stetter, SoftwareFactory, Industriekreissprecher
Die Ergebnisse der Arbeit wurden durch die Mitglieder eines Industriekreises überwacht. Die
teilnehmenden Unternehmen sind im Anhang dieses Dokuments aufgeführt.
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 iii

Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 iv

0 Kurzfassung
Dieser Abschnitt enthält auszugsweise die im Hauptteil ausführlich beschriebenen Ergebnisse
der VA. Da aus den Ergebnissen einer Umfragen jedoch nur bereits existierende oder kurzfristige
zukünftige Probleme ermitteltet werden können, werden in einem weiteren Punkt die
Ergebnisse der ebenfalls angewandten Szenariotechnik zusammengefasst. Mit Hilfe dieser
Technik ist es möglich, aus vorhandendem Expertenwissen methodisch mögliche zukünftige
Entwicklungen darzustellen und in leicht verständlicher Form zu bündeln. Die Szenarios zeigen
mögliche Entwicklungstendenzen der nächsten acht Jahre auf und geben dadurch Mittel an
die Hand, vom gegenwärtigen (durch die Umfrage ermittelten) Ist-Zustand auf mittel bis langfristige
Probleme, Risiken und Verbesserungspotentiale hinzuweisen. Im letzten Punkt werden
die entwickelten Einzellösungsschritte zu Themenfeldern gebündelt, in denen durchgeführte
Aktionen den größtmöglichen Nutzen für eine breite Zielgruppe erreichen können (Aktionsfelder).
0.1 Executive Summary
Infolge der zunehmenden Bedeutung der Informationstechnologie in der Produktion als Wertschöpfungsfaktor,
sowohl im Produktionsprozeß als auch im Produkt selbst, ist die ingenieurmäßige
Softwareentwicklung gerade für die KMUs der Zukunft als dritte Kernkompetenz
zusätzlich zu Maschinenbau und Elektrotechnik von entscheidender Bedeutung. Die Informationstechnologie
erlaubt nicht nur schnellere und effizientere Realisierung von Produkten sondern
auch die Umsetzung neuer Funktionalitäten und sichert so die internationale
Wettbewerbsfähigkeit der KMUs.
Vordringlichstes Ziel ist daher die Integration der beteiligten Fachrichtungen Maschinenbau,
Elektro- und Informationstechnik und Informatik. Dies bedeutet insbesondere das Zusammenführen
ihrer Ansätze und Werkzeuge in eine anwendungsorientierte Vorgehensweise zur Entwicklung
eingebetteter Systeme. Folgende Forschungs- und Entwicklungsaktivitäten
erscheinen in dieser Hinsicht besonders vordringlich:
• Adaption und Transfer
Aufgrund der Eigenarten eingebetteter Systeme sind im Bereich Software-Engineering entwickelte
Ansätze und Verfahren nicht immer unmittelbar einsetzbar. Benötigt wird daher die
Anpassung vorhandener Vorgehensmodelle (inkl. Kostenmodelle) und Richtlinien an die
Bedürfnisse der KMUs, einschließlich der Einführung von Konfigurationsmanagement mit
Berücksichtigung der Variantenvielfalt und von auf die Anwendung für eingebettete
Systeme zugeschnittenen Qualitätssicherung. Ebenso benötigt werden darauf aufbauend
Maßnahmen zur Vermittlung der ingenieurmäßigen Softwareentwicklung sowie allgemein
aktueller Entwicklungen und Lösungsansätze im Bereich der Informationstechnologie.
• Beherrschung der Komplexität
Die Bedeutung der Einzelfertigung im Anlagenbau einerseits sowie das Zusammenspiel von
unterschiedlichen Fachgruppen im Bereich Produktionstechnik andererseits machen die
Beherrschung der Komplexität im Entwicklungsprozeß zu einer wesentlichen Aufgabe.
Themen von besonderer Dringlichkeit sind hier Definition und Einsatz von Bausteinen und
Standardarchitekturen und Standardplattformen bestehend aus Hardware und Software und
die Rückverfolgung und Sicherung der Abhängigkeiten im Entwicklungsprozeß über Produktversions-
und Fachrichtungsgrenzen.
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 v

• IT-Werkzeuge für die Produktion
Wesentliche Reibungsverluste entstehen durch die fehlende Integration der Werkzeuge der
Fachrichtungen. Benötigt wird daher eine anwendungsorientierte durchgängige und fachrichtungsübergreifende
Werkzeugunterstützung für die gesamte Systementwicklung. Unterthemen
reichen hier vom einheitlichen Produktdatenmanagement über
Konsistenzsicherung, bausteinorientiertes Arbeiten bis hin zur Generierung von Testfällen,
Steuerungscode, Benutzeroberflächen oder Dokumentation.
• Integriertes Vorgehensmodell für die Produktion
Infolge der Kombination verschiedener Fachrichtungen und Aktivitäten zur Realisierung
eines Produkts kommt dem Einsatz eines übergreifenden Vorgehensmodell für die ingenieurmäßige
Entwicklung eine Schlüsselrolle zu. Hier zu behandelnde Unterthemen sind
vor allem die fachrichtungs-, unternehmens- und phasenübergreifende Entwicklung,
Systeminteroperabilität, ein aktives, entwicklungsbegleitendes Qualitätsmanagement,
Kosten- und Risikomanagement sowie die Schaffung von Standards für Dokumente und
Beschreibungstechniken.
Da die hier beschriebenen Themenfelder im Regelfall nicht unabhängig zu behandeln sind, sollen
insbesondere solche Projekte berücksichtigt werden, die Aufgabenstellung aus unterschiedlichen
Themenfelder kombiniert behandeln.
0.2 Interdisziplinäre Zusammenarbeit
Bei der Erstellung und Planung von Systemen mit eingebetteter Software ist die Zusammenarbeit
verschiedener Disziplinen notwendig.
In kleinen Projektteams können nach einer Anfangsphase, die bei der Klärung unterschiedlicher
Begrifflichkeiten behilflich ist, die der Herstellung eines einheitlichen Projektverständnisses
im Wege stehenden Kommunikations- und Verständnisprobleme durch gegenseitiges
Voneinanderlernen schnell behoben werden. Die unterschiedliche Sichtweise der beteiligten
Ingenieurdisziplinen führt gerade in den frühen Entwicklungsphasen zu einer ganzheitlicheren
Betrachtung und hilft in der Analysephase, wichtige Systemaspekte nicht zu vergessen.
In größeren Projekten ist die Zusammenarbeit zwischen Softwareentwicklern und Systementwicklern
auf kurze Absprachen beschränkt. Hier ist auch eine hierarchische Abstufung zwischen
den Entwicklungsdomänen zu beobachten. Während die Entwicklung des
Gesamtsystems das Projekt dominiert und dabei Projektphasen, Meilensteine, Anforderungen
und Randbedingungen bestimmt, wird die Software als der flexibelste Part verstanden, der sich
den Gegebenheiten im Gesamtprojekt uneingeschränkt anpassen muss. Hier fehlt auf beiden
Seiten das Verständnis für die Bedürfnisse der verschiedenen Entwicklungsprojektbestandteile.
Bei der Bewertung dieser Ergebnisse ist jedoch zu berücksichtigen, daß nur in wenigen Unternehmen
Informatiker an der System- und Softwareentwicklung beteiligt sind; im Regelfall
sind die „traditionellen“ Disziplinen Maschinenbau und Elektrotechnik an der Entwicklung
beteiligt.
Die Analyse der Schnittstellen, die der softwareentwicklende Unternehmensbestandteil mit
anderen Bereichen hat, zeigt, daß eine Zusammenarbeit mit Vertrieb, Marketing und Produktplanung
in den meisten Unternehmen vorkommt. Aus Einzelaussagen lässt sich entnehmen,
daß gerade die Kommunikation mit dem Vertrieb und den betriebswirtschaftlichen Bereichen
schwierig und unzureichend ist. Ursache ist mangelndes Wissen über die Eigenschaften von
Software und überholte Vorstellungen in denen beispielsweise Anlagen noch immer nur aus
Hardware bestehen und die Software lediglich ein Zubehör, aber kein integraler Bestandteil ist.
vi Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

Aus diesem Grunde ist vielfach die Kommunikation der Komplexität nicht möglich, besonders
in den frühen Phasen der Anforderung und ganz besonders, wenn es sich um neue Aufgabenstellungen
handelt.
In der Softwareentwicklung sind überdies starke Nachwuchsprobleme zu verspüren. Aufgrund
mangelnder Erfahrungen wird zudem ein Defizit im Bereich Projektmanagement deutlich.
Gerade im universitären Bereich werden den zukünftigen Entwicklern kaum organisatorische
Fähigkeiten und Methoden vermittelt. Insgesamt vermissen die Unternehmen bei den Berufsanfängern
Wissen über organisatorische Zusammenhänge in einem Unternehmen und Erfahrungen
in Teamarbeit.
Lösungsansätze:
Eine Lösung der beschriebenen Probleme kann durch folgende Ansätze angestrebt werden:
• Bereitstellung und Pflege von domänenübergreifenden Terminologiedatenbanken
Damit über die Disziplinen hinweg ein fruchtbarer Gedankenaustausch stattfinden kann, ist
es wichtig mit Hilfe von Terminologiedatenbanken zum einen Begriffe mit mehreren
Bedeutungen beziehungsweise einer Bedeutung, die durch mehrere disziplinspezifische
Ausdrücke beschrieben wird, zu identifizieren und zum ändern in einer Art Glossarfunktion
wirklich domänenspezifische Begriffe zu erklären.
• Integrierte und praxisorientierte Ausbildung/Studiengänge
Abgesehen davon, daß ein Studiengang geschaffen werden könnte, der die besonderen
Anforderungen an Projektingenieure, Entwicklungsleiter und Produktverantwortliche in
Unternehmen, die eingebettete Systeme erstellen, vermittelt, sollten vorhandene Studienund
Ausbildungsgänge so angepasst werden, daß die entscheidenden Fähigkeiten vermittelt
werden, welche die Entwicklung und Innovation solcher Systeme problemlos ermöglichen.
Dazu gehört unter anderem die Förderung einiger sogenannter „soft-skills“, wie Kommunikations-
und Teamfähigkeit. Weiterhin müssen Methoden gelehrt werden, wie Informationen
schnell beschafft und für die jeweilige Situation so aufgearbeitet und präsentiert werden
können, daß sie von anderen Teammitgliedern problemlos aufgenommen werden können.
Die Integration von Praxissemestern oder die Einbindung von Studenten in industrielle Projekte
muss tiefer in den Studiengängen verankert werden
• Integrierte Projektmanagementmethoden
In jeder Disziplin gibt es spezifische Vorgehensweisen bei der organisatorischen Planung
und Durchführung von Entwicklungsprozessen. Diese Projektmanagementmethoden sind
um solche Ansätze zu erweitern oder zu ergänzen, die eine ideale Zusammenarbeit verschiedener
Entwicklungsteams unterschiedlicher Disziplinen ermöglichen und verbessern.
Mit der zu entwickelnden Art von Projektmanagementmethodik sollte vor allem der
momentan schwer planbare Zeitbedarf für die Entwicklung von Software optimiert werden.
Hier gilt es Frühwarnsysteme zu integrieren, die Alarm schlagen, sobald ein Projekt zeitlich
oder bezüglich der erwarteten Ergebnisse nicht der Zielplanung entspricht.
0.3 Vorgehensweise
Bei den meisten Unternehmen (ca. 75%) findet sich ein phasenorientiertes Vorgehen, das aus
den Hauptphasen
• Anforderungsanalyse mit Erstellung der Anforderungsdokumente (Lastenheft, Pflichtenheft),
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 vii

• Design mit Erstellung der Systemarchitektur und der Systemkomponenten oder des funktionalen
Aufbaus des Systems, teilweise unterschieden in Grob- und Feindesign,
• Implementierung oder Umsetzung des Systems in Form von Hardware und Software (C-,
C++-, SPS-Code etc.),
• Test (Modultest, Integrationstest, Inbetriebnahmetest, Systemabnahmetest) und
• Systembetrieb mit Service und Wartung (Fehlerbehebung, Einspielen neuer SW-Versionen)
besteht. Dabei sind nicht immer alle Phasen vorhanden; insbesondere die Designphase existiert
nicht in allen Unternehmen in Form einer eigenständige Phase. Auch sind die einzelnen Phasen
und damit das gesamte Vorgehensmodell unterschiedlich stark ausgeprägt. Dabei liegt das
Gewicht inbesondere auf den späten Entwicklungsphasen, vor allem der Implementierung
sowie der Qualitätssicherung in Form von Tests. Nur in wenigen Unternehmen wird ein standardisiertes
Vorgehensmodell wie das V-Modell mit den damit verbundenen Dokumenten eingesetzt.
Allgemein ist bei jedem Unternehmen, unabhängig davon ob ein definiertes Vorgehensmodell
vorhanden ist oder nicht, eine Analysephase in der praktischen Projektdurchführung vorgesehen;
generell ist die Bedeutung dieser Phase anerkannt und damit ein entsprechendes Vorgehen
definiert. Bei über 80% der befragten Unternehmen ist die Erstellung eines Pflichtenhefts vorgesehen
sowie die Vorgaben für die Durchführung der Analyse oder die Erstellung des Pflichtenhefts
vorhanden. Dabei unterscheiden sich jedoch die in der Analysephase
vorgeschriebenen Aktionen wesentlich. Nur bei ca. 50% liegen genaue Vorgaben zur Durchführung
der Analyse vor, einschließlich der Einplanung von Reviews.
Die Erstellung eines Lastenhefts ist nicht in allen Fällen vorgesehen (und auch nicht in allen
Fällen vollständig möglich, beispielsweise bei innovationsgetriebenen Prozessen). Auch in den
Fällen, in denen ein Lastenheft als Vertragsgrundlage eingesetzt wird, erfolgt die Erstellung
des Lastenhefts im Regelfall noch nicht systematisch. Auch in den Fällen, in denen ein Lastenheft
oder vergleichbares Dokument vorgesehen ist, wird das Pflichtenheft nur in Ausnahmefällen
systematisch daraus abgeleitet. Eine Möglichkeit der Rückverfolgung von Anforderungen
aus dem Pflichtenheft zu Anforderungen aus dem Lastenheft ist generell nicht gegeben.
Ähnlich wie im Fall der Analysephase - mit mehr oder weniger ausgeprägten Vorgaben einschließlich
eines Pflichtenhefts - existiert prinzipiell auch eine eigenständige Designphase.
Diese ist aber im Regelfall noch etwas schwächer ausprägt als die Analysephase: nur ca. 60%
der Befragten legen im Design den Systemaufbau einschließlich funktionaler Anforderungen
an die Systemkomponenten - mehr oder weniger vollständig - in Form des Feindesigns fest.
Wie auch bei den bisher beschriebenen Entwicklungsdokumenten wird in den Designdokumenten
der softwaretechnische Anteil im allgemeinen nur unvollständig, unpräzise abstrakt
(d.h. ohne Implementierungsinformation) beschrieben. Eine genaue Beschreibung der Funktionalität
(des Verhaltens) der Softwarekomponenten wird nur in Ausnahmefällen erstellt.
Die Implementierungsphase spiegelt die Vorgehensweise der Softwareentwicklung wie keine
andere Phase wider. Für die Mehrheit der Unternehmen findet Softwareentwicklung ausschließlich
in der Implementierungsphase statt, wohingegen für einzelne Ausnahmen diese
Phase lediglich zur Konvertierung des erarbeiteten Design in eine physikalische Abbildung ist.
Die Ist-Situation stellt sich gerade in dieser Phase aufgrund der jahrzehntelangen gereiften
Implementierungstechnik nicht in allen Punkten so schlecht dar. Alle Unternehmen setzen
Standardentwicklungsumgebungen ein, die in ihrer Anwendung gut verstanden sind, jedoch al
„stand alone“ Produkte noch weitgehend nicht mit Werkzeugen anderer Phasen verknüpft sind.
viii Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

Es kommen Implementierungsrichtlinien zum Einsatz, deren Einhaltung in vielen Fällen fraglich
beziehungsweise nicht nachvollziehbar ist.
Eine phasenübergreifende vollständige und durch ein Vorgehensmodell abgedeckte Wiederverwendung
wird entweder überhaupt nicht oder nur vereinzelt betrieben. Dabei findet eine Wiederverwendung
nur auf Basis von Klassenbibliotheken, GUI Bausteinen und SPS Code
Modulen statt.
Betrachtet man die oben angesprochene automatische Generierung der ausführbaren Codestücke,
so lässt sich feststellen, daß fast kein Unternehmen diese Technik ernsthaft einsetzt. Der
generierte Code ist oft zu groß, zu langsam oder schlichtweg nicht generierbar, da die vorhergehende
Designphase fehlt.
Harte als auch weiche Echtzeitbedingungen, die eine zentrale Rolle in der Entwicklung für
Software für eingebettete Systeme spielen, werden zwar als wichtig angesehen aber an keiner
Stelle formal erfasst beziehungsweise implementierungsspezifisch berücksichtigt.
Auch die Verwaltung von Hardwareressourcen und die Verlagerung der Komplexität in eine
Modulare Struktur durch ein Realzeitbetriebssystem wird von wenigen eingesetzt. Auch hier
ist die Akzeptanz durch Kostenüberlegungen oder aus Perfomanzgründen gedämpft.
Service und Wartung wird von den befragten Unternehmen sehr unterschiedlich behandelt.
Komplett ausgereifte Formen nimmt die Wartung bei Systemen an, die über Ferndiagnosemöglichkeiten
verfügen und über Datenleitung steuerbar, instandsetzbar und wartbar sind. Systeme,
die Telemonitoring, Teleservice und Prozessaufzeichnung ermöglichen, haben High-
Tech-Standard und nutzen sämtliche Möglichkeiten der Kommunikationstechnologie. Eine
weitere Abstufung bilden die Produkte der Unternehmen, die Logbuchfunktionalitäten enthalten
oder Diagnoseergebnisse und Daten erfassen und speichern, die bei Fehlfunktionen analysiert
werden können. Jedoch nicht bei allen Unternehmen, deren Systeme dies ermöglichen,
werden die Diagnoseergebnisse systematisch analysiert und genutzt. Die letzte Stufe bilden die
Systeme, die bei Fehlfunktionen oder Ausfall komplett ausgetauscht werden, ohne daß eine
Ursachenanalyse stattfindet.
Die organisatorische Zusammenarbeit der Entwickler mit den Servicemitarbeitern sehr unterschiedlich
gestaltet. Sie reicht von keinerlei Kommunikation bis dahin, daß die Entwickler in
der Produkteinführungsphase und auch noch später selbst am Service beteiligt sind. Im zweiten
Fall stellt sich die Frage nach einer ausreichenden Qualifikation der Servicemitarbeiter
nicht, während es im anderen Fall zum Teil bemängelt wurde.
Lösungsansätze:
Eine Lösung der beschriebenen Probleme kann durch folgende Ansätze angestrebt werden:
• Definition standardisierter Beschreibungen für den Softwareanteil eingebetteter Systeme als
Grundlage für Lasten- und Pflichtenhefte
Während für den Hardwareanteil eingebetteter Systeme standardisierte Beschreibungsformen
vorliegen, gilt vergleichbares für den Softwareanteil nicht. Die bisher bei der Softwareentwicklung
allgemein eingesetzten Beschreibungsformen sind eher im Bereich der
datenintensiven Systeme angesiedelt (z.B. E/R-Diagramme, Klassendiagramme). Die für
die Aspekte eingebetteter Systeme geeigneten Beschreibungsformen unterscheiden sich je
nach Ansatz und Werkzeughersteller (z.B. State Charts, State Flow Diagrams, ROOM State
Diagrams, etc.). Die Definition geeigneter Beschreibungsformen bietet den Unternehmen
die Möglichkeit, die Anforderungen an den Softwareanteil umfassend, präzise und trotzdem
ausreichend abstrakt und kompakt zu beschreiben.
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 ix

• Definition standardisierter, produktbereichspezifischer Standardarchitekturen und „hoher“
Schnittstellen für den modularen Aufbau von Systemen aus HW/SW-Bausteinen
Obwohl gerade in vielen Bereichen der Entwicklung eingebetteter Systeme die Verwendung
von Bausteinen und Standardarchitekturen in der ingenieurmäßigen Tradition der Systementwicklung
liegt, finden sich standardisierte Schnittstellen eher im Bereich der Hardware
oder der Software, weniger jedoch bei deren Kombination. Die Verwendung einheitlicher
hoher Schnittstellen (z.B. einheitliche Fehlerbehandlung, einheitliche Steuerung) für ganze
Baugruppen erlaubt eine bausteinorientierte Entwicklung des Systems durch Zusammenstellen
solcher Komponenten. Der Einsatz einheitlicher Architekturen und Schnittstellen ist
besonders für die Kombination von Komponenten verschiedener Hersteller von Bedeutung.
Die Verwendung hoher Schnittstellen erlaubt eine einfachere Integration von verschiedenen
Elementen und Versionen vergleichbarer Baugruppen.
• Definition eines integrierten Vorgehensmodells einschließlich geeigneter Beschreibungen
und Werkzeugunterstützung
Für den Einsatz bei der Entwicklung eingebetteter Systeme wird ein Vorgehensmodell
benötigt, das die Besonderheiten solcher Entwicklungen (z.B. stark unterschiedlicher Projektumfang,
intensiver Einsatz von Bausteinen und Standardarchitekturen, interdisziplinäre
Entwicklung, Berücksichtigung von strengen Anforderungen wie Echtzeitkriterien) berücksichtigt.
Wesentliche Ziele des integrierten Vorgehensmodells sind die Konsistenzüberprüfung
beschriebener Systeme und Komponenten, der Einsatz von Simulation, die
Möglichkeit der Generierung von ausführbarem Code, von Testfällen sowie von Dokumentation
sein. Dabei darf sich die Werkzeugunterstützung wie bisher nicht nur auf die Behandlung
der späteren Phasen (ab Design) beschränken, sondern muss bereits ab der
Anforderungsanalyse ansetzen und inbesondere die Möglichkeit der Dokumentation von
Entwurfsentscheidungen sowie der Rückverfolgung von Anforderungen berücksichtigen.
Ein solches Vorgehensmodell muss möglichst übergreifend für den Bereich der eingebetteten
Systeme definiert werden. Dies ist vor allem für eine unternehmensübergreifende Entwicklung
von Systemen von Bedeutung, bei der einzelne Arbeitspakete von
unterschiedlichen Unternehmen entwickelt werden.
• Verbesserung der Vorgehensweise in der Implementierung
Die Punkte Entwicklungsumgebung, Programmierrichtlinien und Wiederverwendung werden
im Abschnitt 5.1.2 II „Definition eines integrierten Vorgehensmodells einschließlich
geeigneter Beschreibungen und Werkzeugunterstützung“ behandelt. Eine Bearbeitung dieser
Thematik kann nur in einem phasenübergreifenden Kontext bearbeitet werden und wird
hier nicht näher aufgeführt.
Die Einhaltung von Echtzeitbedingungen verlangt zum einen nach einer formalen Spezifikation
dieser Randbedingungen und zum anderen nach einer „Messbarkeit“ dieser Kennwerte.
Daher werden Vorgehensweisen (Benchmarking Methoden) benötigt, die
Leistungskennwerte von Software (und in Zukunft auch Softwarebausteine) transparent
darlegen.
• Optimierung automatischer Codegenerierung
Ein zweiter zentraler Lösungsansatz ist die Verbesserung der „Last Mile“ Phase, d.h. die
Optimierung der automatischen Codegenerierung. In diesem Fall sind die existierenden
Lösungen nicht auf den Spezialfall der eingebetteten Systeme abgestimmt. Für eine mittelbis
langfristige Lösung müsste eine Beschreibung der verwendeten Hardwarearchitektur
existieren, die eine automatische Generierung von Compilern für diese Architektur erlaubt.
x Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

• Automatisiertes Design - Intelligente Bausteine, selbstorganisierende adaptive dynamische
Systeme und Middleware für eingebettete Systeme
Einige Zukunftsprojektionen haben gezeigt, dass bereits innerhalb der nächste acht Jahre
autonome, dezentral vernetzte intelligente mechatronische Systeme eine zunehmend stärkere
Rolle spielen könnten, weshalb es angeraten erscheint, sich bereits jetzt durch die
Beschäftigung mit den dafür notwendigen technischen und methodischen Grundlagen einen
Vorsprung zu verschaffen.
Neben dem Aufbau einer adäquaten Vetriebsstruktur für Bausteine (auffinden, zertifizieren
von Echtzeit und Sicherheitseigenschaften, automatische Lizensierung usw.) kommt der
Middlware, d.h. der softwaretechnologischen Infrastruktur für den Betrieb dieser Art von
Systemen und Bausteinen eine gesteigerte Bedeutung zu. Bestehende Ansätze wie SUNs
Jini oder Microsofts UPNP müssen auf ihre Tauglichkeit untersucht und auf die Bedürfnisse
von eingebetteten Systemen angepasst beziehungsweise in diese Richtung erweitert werden.
0.4 Qualitätssicherung
Eine der wichtigsten Aufgaben der Unternehmen liegt in der Sicherung der Produktqualität.
Vor dem Hintergrund, dass heute - und in Zukunft verstärkt - die Software eine Kernkomponente
von innovativen Produkten darstellt, hat die SW-Qualität einen hohen Einfluss auf die
Qualität des Gesamtprodukts. Die Herausforderung an die Qualitätssicherung liegt darin, eine
hinreichreichende Fehlerfreiheit der Software bei akzeptablem Zeit- und Kostenaufwand zu
garantieren. Wobei die Komplexität der Qualitätssicherung von eingebetteten Software höher
ist als bei herkömmlicher Software, da das eingebettete System wesentliche Unterschiede aufweißt,
wie z B. die Echtzeitfähigkeit und die enge Verzahnung von Software, Hardware und
Gerätemechanik.
Fast alle Unternehmen besitzen ein definiertes bzw. standardisiertes Qualitätsmanagementsystem,
jedoch wird dabei die Softwareentwicklung meist außer Acht gelassen bzw. nur sehr grob
beschrieben. Auch fehlt es oft an einer kompetenten Organisationseinheit für die SW-Qualitätssicherung.
Daher verwundert es nicht, dass die SW-Qualitätssicherung oft wenig geplant
und unsystematisch vorgenommen wird.
Obwohl alle Unternehmen sich prinzipiell bewusst sind, dass Fehler möglichst frühzeitig entdeckt
werden sollten, wird der meiste Aufwand dennoch erst am Ende der Entwicklung in den
Testphasen (Modultest, Integrationstest, Systemtest) betrieben, was dazu führt, dass Projektverzögerungen
sich unmittelbar auf die Testzeit auswirken. In den frühen Phasen (Analyse,
Design) werden bestenfalls Reviews angewendet, und diese meist auch sehr unsystematisch
und ohne eine explizite Planung
Das Testen erfolgt meist unsystematisch durch den Entwickler selbst und ist dabei zusätzlich
erfahrungsabhängig. Erschwerend kommt hinzu, dass das Ermitteln von Testfällen nicht
methodisch erfolgt und ein geeignetes und einheitliches Beschreibungsmittel für Testfälle
fehlt. Auch ein Werkzeugeinsatz für die einzelnen Testaktivitäten findet nur in geringem Maße
statt. Dies lässt sich aber hauptsächlich dadurch begründen, dass die meisten kommerziell verfügbaren
Werkzeuge zum Testen die besonderen Anforderungen von eingebetteten Systemen
nur unzureichend erfüllen.
Lösungsansätze:
Die Besonderheiten eingebetteter Software unterscheiden sich grundsätzlich von denen der
gewöhnlichen Softwaresysteme. Die dadurch bedingte zusätzliche Komplexität bedarf im
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 xi

Bereich der Qualitätssicherung neuer Ansätze und Lösungen, die im folgenden kurz beschrieben
werden:
• Evaluierung von Werkzeugen und Methoden für die Qualitätssicherung
Da der Markt der verfügbaren Werkzeuge und Methoden sehr unübersichtlich ist und
KMUs gewöhnlich nicht die Kapazitäten haben um deren Tauglichkeit im Bereich der Entwicklung
Eingebetteter Systeme zu evaluiert, sollte diese Evaluierung innerhalb eines Projektes
bearbeitet werden.
• Bewertung von QS-Maßnahmen
Die Qualität und Effektivität von QS-Maßnahmen sind oftmals schwer zu bewerten, bzw. es
gibt wenig Aussagen darüber, was eine bestimmte Maßnahme an Nutzen bringt und unter
welchen Rahmenbedingungen man diese einsetzen sollte. Daher wäre es sinnvoll, Maßzahlen
für QS-Methoden zu ermitteln.
• Leitfaden für Unternehmen zur Auswahl und Einführung von QS-Maßnahmen
Welche QS-Maßnamen für ein Unternehmen sinnvoll sind, kann man nicht pauschal definieren,
d.h. nachdem man Bewertungskriterien für QS-Maßnahmen gefunden hat, müssen
diese an den Gegebenheiten und unterschiedlichen Anforderungen in den Unternehmen
gespiegelt werden. Ein Leitfaden sollte erarbeitet werden, welcher den Aufwand für die
Unternehmen bei der Auswahl und Einführung entscheidend minimieren würde.
• QS-Modell für Eingebettete Systeme
Ausgehend von vorhandenen Vorgehensmodellen (für Standardsoftware) sollte ein an die
Anforderungen von Eingebetteten Systemen angepasstes QS-Modell entwickelt werden,
welches an die Projektanforderungen adaptierbar ist.
• Methoden für die entwicklungsbegleitende QS
Der größte Aufwand der Qualitätssicherung liegt heute am Ende des Entwicklungsprozesses,
nämlich beim Integrations- und Systemtest. Dies liegt aber im kritischen Projektpfad
und stellt somit hohe QS-Risiken, daher bedarf es den Einsatz neuer Technologien um in
den frühen Entwicklungsphasen effektivere Prüfungen durchführen zu können.
• Systematische Ableitung und Beschreibung von Testfällen
Das Ermitteln und Beschreiben von Testfällen für Eingebettete Systeme stellt eine große
Herausforderung dar, welche es noch zu bewältigen gilt. Ein sinnvoller Ansatz dazu wäre,
eine geeignete Beschreibungstechnik zu entwickeln, welche die Besonderheiten von Eingebetteten
Systemen berücksichtigt und hinreichend einfach anwendbar ist.
• Testautomatisierung und Wiederverwendung
Die Eigenschaften eingebetteter Systeme und die Anforderung nach einer hohen Qualität
ziehen umfangreiche Tests und komplexe Testbetts nach sich. Um die praktische Anwendbarkeit
zu gewährleisten, muss ein besonderer Augenmerk auf die Wiederverwendung und
Automatisierung gelegt werden.
0.5 Konfigurationsmanagement
Die durchgeführten Interviews haben ergeben, daß etwa 25% der befragten Unternehmen gar
kein Konfigurationsmanagementsystem einsetzen, etwa 50% der Unternehmen setzen einfach
Konfigurationsmanagementsysteme, wie PVCS, CVS, SourceSafe, etc., ein und weitere 25%
sehr moderne Systeme wie ClearCase.
xii Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

Konfigurationsmanagementsysteme sind in der Softwareentwicklung als ein unentbehrliches
Hilfsmittel zur Koordination von Entwicklerteams sind einigen Jahren weitgehend etabliert.
Sie haben sich insbesondere zur Verwaltung von Quelltexten sehr bewährt. Durch den Einsatz
von Konfigurationsmanagementverfahren, wie der Verwaltung von Zugriffssperren, der Verwendung
von optimistischen Sperrverfahren und Entwicklungs-Sandboxes, oder gar einer einfachen
Work-Flow-Unterstützung, können viele Reibungsverluste bei der
Softwareentwicklung vermieden werden, die Produktivität der Entwickler kann entscheidend
verbessert werden und auch große Projekte mit mehr als 20 Entwicklern und mehreren 100000
Quelltextzeilen werden beherrschbar.
Für den Bereich der eingebetteten Systeme sind diese Ergebnisse aber leider nur eingeschränkt
übertragbar. Weitergehende Konfigurationsmanagementtechniken, wie optimistische Sperrund
Mischverfahren, stehen im allgemeinen nur für rein textuelle Dokumente zur Verfügung.
Desweiteren basieren diese Verfahren auf einer weitgehenden automatischen Konsistenzprüfung
wie sie bei der Softwareentwicklung vom Compiler vorgenommen wird. Dabei wird mit
hoher Sicherheit festgestellt, ob parallel zu einander durchgeführte Änderungen verschiedener
Entwickler an unterschiedlichen (oder sogar an den selben) Dateien sich widersprechen oder
ob diese nebenläufigen Änderungen Konflikte erzeugen, die der manuellen Überprüfung
bedürfen.
Im Bereich der eingebetteten Systeme stellen Quelltexte nur einen (kleinen) Teil der gesamten
Entwicklungsdokumente dar. Ebenso wichtig für die gesamte Funktionalität sind CAD-Zeichnungen,
Funktionsskizzen, Schaltpläne für die Elektronik, Bauteilspezifikationen, Anschlusspläne,
Platinenlayouts und Bestückungspläne. Die Mehrzahl dieser Dokumente liegt in
werkzeug- oder domänenspezifischen Dateiformaten vor, die sich einer zentralen Konfigurationsverwaltung
und zentralen Mischverfahren entziehen. Schlimmer noch, eine übergreifende
automatische projektweite Konsistenzsicherung fehlt im Bereich der eingebetteten Systeme
aufgrund der vielen proprietären Dateiformate bisher vollständig. Das bedeutet, wenn ein Entwickler
A eine mechanische Komponente modifiziert dann müssen die Auswirkungen dieser
Änderung auf Verdrahtungs- und Schaltpläne und die daraus entstehenden Auswirkungen auf
Softwarekomponenten manuell an die jeweils zuständigen Entwickler weitergeleitet und von
denen manuell nachgezogen werden. Dabei kommt es oft vor, dass Änderungsvorschläge von
davon betroffenen Entwicklern aus anderen Bereichen später abgelehnt oder modifiziert und
zurückgegeben werden. In einem großen Projekt mit vielen Entwicklern werden täglich dutzende
solcher Änderungsprozesse in Gang gesetzt (teilweise widerrufen und neu initiiert).
Dies führt schnell zu sich überholenden und widersprüchlichen Änderungsvorgängen und nach
kurzer Zeit weiß niemand mehr, welcher Änderungsstand von welchem Dokument welche
Änderungen schon enthält und mit welchem Stand der anderen Dokumente zusammen passt.
Dies verursacht hohe Reibungsverluste.
Lösungsansätze:
Zur Lösung der Probleme im Bereich Konfigurationsmanagement für eingebettete Systeme
sollte man kurz- bis mittelfristige Schritte und mittel- bis langfristige Ansätze betrachten:
• Adaption und Ausweitung des Konfigurationsmanagements
Kurz- bis mittelfristig sollten die bestehenden Möglichkeiten und Techniken des Konfigurationsmanagements
und die Erfahrungen aus dem Bereich der reinen Softwareentwicklung
so weit wie möglich auf das Gebiet der eingebetteten Systeme übertragen werden. Hierzu
gehört die flächendeckende Einführung von Konfigurationsmanagementsystemen, die Ausdehnung
des Konfigurationsmanagements von der Quelltext verwaltung auf die Verwaltung
aller möglichen Projektdokumente und vor allem der vermehrte Einsatz von optimistischen
Sperrverfahren und Sandbox-Techniken. In diesem Bereich ist aber auch die Schulung der
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 xiii

Mitarbeiter von zentraler Bedeutung. Konfigurationsmanagementsysteme greifen direkt
oder indirekt in die Organisation und Arbeitsweise von Projekten und ihren Mitarbeitern
ein. Dies führt zur Umstellung von gewohnten Arbeitsabläufen und erfordert eine umfangreiche
Vorbereitung der einzelnen Mitarbeiter vor und bei der Einführung neuer Konfigurationsmangementverfahren.
• Interdisziplinäre Konsistenzprüfungen
Mittel- bis langfristig müssen die zentralen Probleme des Konfigurationsmanagments im
Bereich der eingebetteten Systeme angegangen werden. Dies sind die projektweite automatische
Konsistenzprüfung (wie sie im Bereich der Softwareentwicklung durch den Compiler
weitgehend sicher gestellt wird). Eine solche projektweite Konsistenzprüfung muss insbesondere
disziplin- und dokumenttypübergreifend funktionieren, damit auch die Arbeit von
Maschinenbauern, Elektrotechnikern und Informatikern gezielt koordiniert werden kann.
Hierzu ist es erforderlich, dass die verschiedenen Hersteller von Entwicklungswerkzeugen
dazu bewegt werden, ihre Dateiformate offen zu legen beziehungsweise Standarddateiformate
zu verwenden. Basierend auf solchen Industriestandards für die verschiedenen Dokumentarten
im Bereich der eingebetteten Systeme können dann allgemeine,
domänenübergreifende Konsistenzprüfungswerkzeugen entwickelt werden. Die Entwicklung
von domänenübergreifenden Konsistenzprüfungswerkzeugen kann aber auch so schon
für einige verbreitete Werkzeuge und Dokumentarten in Angriff genommen werden. Mit der
projektweiten Konsistenzprüfung einher sollte eine verbesserte Anbindung der verwendeten
Entwicklungswerkzeuge an die Konfigurationsmanagementsysteme erreicht werden. Dies
kann in einfachen Fällen durch geeignete Benachrichtigungs-Mechanismen geschehen,
wodurch das Konfigurationsmanagementsystem Kenntnis darüber erhält, wer mit welchem
Werkzeug auf welche Dokumente zugreift und möglicherweise entsprechende Zugriffssperren
vergeben kann. Zur Unterstützung von optimistischen Sperrverfahren und Sandbox-
Techniken ist aber auch die Bereitstellung von geeigneten Mergeverfahren für die verschiedenen
Dokumentarten wünschenswert.
0.6 Beschreibungstechniken und Werkzeuge
Über alle Klassifikationen hinweg werden nur isolierte Werkzeuge und isolierte Beschreibungstechniken
verwendet, hauptsächlich zur Veranschaulichung beziehungsweise einfacheren
Darstellung bestimmter Sachverhalte sowohl in der Kommunikation der Entwickler untereinander,
als auch bei der Erstellung von Dokumentationen.
Die eingesetzten Maßnahmen sind unzureichend, da es den Entwicklern meist völlig freisteht,
welche Beschreibungsmittel und welche Werkzeuge sie einsetzen und wenn doch Vorschriften
existieren, dann ist meist der Grad, bis zu dem sie angewendet werden müssen nicht festgelegt.
Die Verwendung von Beschreibungstechniken für über Dokumentation und Kommunikation
hinaus gehende Zwecke, wie beispielsweise phasenübergreifende Generierung, hängt stark mit
der Verfügbarkeit und Anwendbarkeit entsprechender Werkzeuge zusammen. Die Mehrzahl
der Interviewten setzen jenseits von Textverarbeitung und Entwicklungsumgebung keine weitergehenden
Werkzeuge ein. Weitere Ergebnisse waren:
• Einsatz von Beschreibungstechniken hautsächlich in der Analyse und im Grobdesign
• Favorisierte Beschreibungstechniken sind Automaten, Architekturdarstellungen und Klassendiagramme
(nur zusammen mit Werkzeug), Einsatz von UML nur bei Struktur (1/3),
nicht bei Verhaltensbeschreibung.
xiv Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

• Eine Modularisierung der Systementwicklung findet wenn überhaupt nur informell statt
(nicht durch besondere BT oder Werkzeuge unterstützt)
• Kein effektiver Einsatz von Codegenerierung
• Echtzeitanforderungen spielen eine wichtige Rolle, werden aber oft nicht methodisch
erfasst
Ursachen sind einerseits fehlende Kenntnis der Möglichkeiten, oder Ablehnung moderner
Techniken, andererseits die fehlende Durchgängigkeit der Werkzeuge, deren schlechte Qualität,
unwirtschaftlichkeit und mangelnde Berücksichtigung der Anforderungen von eingebetteten
Systemen.
Der Systementwurf insgesamt findet also weitesgehend informell und wenig detailliert statt.
Viele Entwurfsentscheidung sind schlecht oder gar nicht dokumentiert, weshalb es auch wenig
verwunderlich erscheint, daß Wiederverwendung, oder bausteinorientierte Entwicklung so gut
wie keine Rolle spielt. Weitere ermittelte Ursachen waren:
• Unterschiedliche Endkundenanforderungen
• Wenig Werkzeuge für Analyse und Test
• Keine phasenübergreifende Vorwärts- und Rückwärtsverfolgbarkeit
• Übergewicht Feindesign/ Implementierung
Abschließend ist festzustellen, daß nur etwa 30% der Befragten alle wesentlichen Eigenschaften
des Systems beschreiben. Nur etwa 5% der Befragten lieferen eine vollständige nicht informelle
Beschreibung ab, etwa die gleiche Anzahl Befragter gab an, sich komplett auf informelle
Beschreibung zu stützen, oder überhaupt nichts zu dokumentieren.
Eine vollständige integrierte und durchgängige Beschreibung etwa für automatische Überprüfung
der Stimmigkeit findet sich nirgends
Lösungsansätze:
Für die Lösung der vorherrschenden Probleme im Bereich des Werkzeugeinsatzes und der
Beschreibungstechniken bieten sich folgende Ansätze an:
• Bestehende Vorurteile und Widerstände abbauen - Wirksamkeit beweisen
Die Realisierung eines gewünschten Vorgehens steht und fällt mit der Akzeptanz der einzusetzenden
Mittel und genau hier liegt eines der grundlegendsten ermittelten Probleme.
Eine mittelfristige Lösungsmöglichkeit besteht daher darin, die Wirksamkeit und möglicherweise
erst zukünftige Bedeutung zu beweisen. Hier ist auch die Wissenschaft in der
Pflicht, nicht nur Grundlagen in Form von Beschreibungstechniken und Methoden zu erforschen,
sondern auch deren Wirksamkeit im realen Einsatz zu erproben. Möglicherweise
müssen auch erst noch Techniken erfunden oder verbessert werden, die diese Art von Wirksamkeitsbeweisen
methodisch ermöglichen.
• Bestehende Nischen- und Speziallösungen nutzen
Einige Firmen haben für ganz spezifische Anforderungen bereits eigene Methoden oder
Werkzeuge entwickelt. Es fehlen jedoch die Mittel, diese improvisierten und aus pragmatischen
Ansätzen entstandene Produkte kurzfristig so weit zu verbessern, daß sie auch von
anderen genutzt werden könnten, die ähnliche Anforderungen haben.
• Erfahrungsaustausch und Evaluierung bestehender Methoden und Werkzeuge
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 xv

Ein großes kurzfristiges Verbesserungspotential liegt in der Ausnutzung von Synergieeffekten
bei jeweils firmeninternen Evaluierungen bestehender Methoden und Werkzeuge.
Momentan werden jeweils eigene beschränkte Mittel nur dafür eingesetzt, einen kleinen
Ausschnitt der vorhandenen Möglichkeiten für zu begutachten. Gesammelt und allen
zugänglich gemacht, ergeben die vielen Einzelerfahrungen einen guten Überblick über den
gesamten Markt der Möglichkeiten.
• Multidisziplinäre Werkzeug & Methodenintegration durch mehr Abstraktion
Langfristig erscheint der Einsatz von Forschungsmitteln für die bessere Berücksichtigung
von domänenspezifischer Besonderheiten in Beschreibungstechniken oder in Werkzeugen
wenig sinnvoll, da der volkswirtschaftliche Nutzen im Vergleich zu den eingesetzten Mitteln
nur sehr gering sein wird. Eine rein technische Integration und die Beschränkung auf
die Berücksichtigung domänenspezifischer Besonderheiten würde beim augenblicklichen
Zersplitterungsgrad der Domänenanforderungen unweigerlich zu noch umfangreicheren
und teureren Werkzeugen führen, und damit nicht ausreichend zur Steigerung der Produktivität
der Anwender führen, da die Komplexität der Werkzeuge überproportional gegenüber
der Steigerung möglicher Anwender wachsen würde.
Zunächst sollte statt dessen versucht werden, den Entwicklungsprozess für Software auf das
gleiche ingenieurmäßige Niveau zu heben, wie es in anderen Disziplinen z.B. bei der Hardwareentwicklung
zu finden ist. Sind die Grundlagen geschaffen, die eine Entwicklung
bedarfsgerechter integrierter Werkzeuge mit vertretbarem Aufwand und für einen größeren
Markt erlauben, reicht der bereits existierende Bedarf bei weitem aus, um durch die Kräfte
des Marktes zu qualitativ hochwertigen und günstigen Werkzeugen zu kommen.
In einem zweiten Schritt sollte versucht werden, das Abstraktionsniveau noch weiter anzuheben
und die verschiedenen Disziplinen, die von der Softwareentwicklung für ES berührt
werden unter einem gemeinsamen Vorgehensmodell zu vereinen, beispielsweise einem digitalen
Produktmodell, das alle Aspekte eines Produktlebenszyklus in sich vereint und die
verschiedenen Einzelvorgehensmodelle miteinander integriert.
0.7 Strategische Szenarien - die Anforderungen von morgen
Von strategisch hoher Bedeutung ist das Ermitteln der Anforderungen von morgen für die Entwicklung,
Produktion und den Service von Software in eingebetteten Systemen sowie die
Erschließung zukünftiger Erfolgspotenziale. Die Betrachtung und Lösung der heute offenstehenden
Probleme reicht angesichts der sehr dynamischen technologischen Entwicklung mit
Sicherheit nicht aus, die Herausforderungen der Zukunft zu bewältigen. Im Rahmen der VA
wurden daher Zukunftsszenarien entwickelt, um heute wahrnehmbare Entwicklungen zu antizipieren
und zu schlüssigen Zukunftsbildern (Szenarien) zu verknüpfen. Wichtig ist in diesem
Zusammenhang, eine größere Anzahl von Einflussfaktoren aus den Bereichen Technologie -
insbesondere Softwaretechnologie und Kommunikationtechnologie -, Branchen und Märkte
und deren Vernetzung zu berücksichtigen sowie mehrere Entwicklungen eines Einflussfaktors
ins Kalkül zu ziehen. Als Betrachtungszeitraum für diese Entwicklungen liegt den Szenarien
das Jahr 2008 zugrunde. Für die einzelnen Anwendungsdomänen wurden Schlüsselfaktoren
bestimmt, die besonder stark eingebunden sind in die Vernetzung der Einflussfaktoren. Für
diese Schlüsselfaktoren wurden anschließend Zukunftsprojektionen für das Jahr 2008 im Rahmen
von Workshops ermittelt. Die anschließende Konsistenzanalyse führt zu den einzelnen
Szenarien. Die wesentlichen Stoßrichtungen der Szenarien ergeben sich aus dem Vergleich der
Unterschiede der Szenarien einer Anwendungsdomäne.
xvi Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

Anlagen- und Maschinenbau:
Die Szenarien für den Anlagen- und Maschinenbau verdeutlichen unterschiedliche Zukünfte.
Neben der Entwicklung der Informations- und Kommunikationstechnologie hängt der Erfolg
zukünftiger Anlagen und Maschinen im wesentlichem an effizienten Methoden und Werkzeugen
des Softwareengineerings, der Modularisierung der Produkte sowie dem Vorhandensein
und Einhalten von weitreichenden Standards. Differenzierungen sind vor allem hinsichtlich
betroffener Komponenten und Anwendungen zu erkennen. Sicherheitsrelevante Funktionsgruppen
mit Echtzeitanforderungen können z.B. erst langsam aufgrund der notwendigen
Zuverlässigkeit IT-mäßig vernetzt werden. Kostspielige IT-Anwendungen für den Sondermaschinebau
sind eher denkbar bei vergleichsweisen hohen Entwicklungskosten der Softwarefunktionalität.
Neben den Produkten selbst sind aber auch die Umfeldentwicklungen wie Verfügbarkeit von
effizienter Softwareentwicklungsumgebungen oder wirksame Einhaltung des Patentrechts zu
betrachten. Sie stellen entscheidende Weichen hinsichtlich der Konsistenz der möglichen
Zukunftsbilder. Darüber hinaus muss es der Branche gelingen, ingenieurmäßiges Standesdenken
der Disziplinen durch Offenheit, breitere Bildung sowie Verknüpfung von Informatik und
Maschinebau entgegen zu treten. Letztendlich aber entscheiden die Kunden mit ihren Qualitätsanforderungen
über den Maßstab der Entwicklungsanstrengungen.
Automatisierungs- und Produktionstechnik:
Die Szenarien für die Automatisierungs- und Produktionstechnik verdeutlichen unterschiedliche
Zukünfte. Die konsistenten Entwicklungen der Schlüsselfaktoren zeigen ein gespaltenes
Bild, in dem vor allem die Spannungsdreiecke „Qualität-Produktkomplexität-Preis“ und
„Beherrschung von Software-Zuverlässigkeit-Anbieter“ die entscheidenden Rollen spielen.
Insbesondere die Beherrschung von Software gepaart mit den rasanten Entwicklung auf dem
Gebiet der Sensorik und der Kommunikationstechnik erscheinen als Notwendigkeit für die
Verbreitung von autonomen mechatronischen vernetzten Systemen und damit zu einer Modularisierung
sowie auch Standardisierung von Lösungselementen. Ihre Durchdringung in den
Bereich der echzeitfähigen Systeme hängt dabei im wesentlichen von der zuverlässigen und
wirtschaftlichen technischen Machbarkeit ab. Dahingegen kann eine Software-Krise im
Bereich der eingebetteten Systeme viele wirtschaftlich notwendige Innovationen behindern
bzw. verzögern. Aus wettbewerblicher Sicht hätte dies starke Konzentrationsbemühungen der
Anbieter zu Folge. Gar könnten die Kunden im Business-to-Business bewusst auf weniger
Informationstechnologie setzen, um ihre Produkte noch an Endkunden vertreiben zu können.
Verkehrstechnik:
Die Szenarien für die Verkehrstechnik verdeutlichen im wesentlichen drei unterschiedliche
Zukünfte. Sie sind bestimmt durch das Spannungsfeld Hi-Tech-Einsatz, Sicherheitsstreben und
Akzeptanz gegenüber technischen Systemen. Je nach Dominanz dieser Faktoren werden die
Zukunftsbilder maßgeblich beeinflusst. Eine starke Stellung des Hi-Tech-Einsatzes führt zu
einer Fortbewegung, die ständig durch alle Möglichkeiten der mobilen Informationsversorgung
und Kommunikationstechnik begleitet wird. Deren Verbreitung setzt aber die sichere
Beherrschung von IuK-Technologien sowie der Software-Entwicklung voraus. Überwiegt das
Sicherheitsstreben der Gesellschaft werden Innovationen gebremst, standort-immanente Nachteile
Deutschlands gestärkt und folgerichtig internationale Wettbewerbsfähigkeit eingebüßt.
Als dritte Variante kann die Akzeptanz technischer Systeme die Zukunft der Verkehrstechnik
entscheidend bestimmen. Gelingt der Umgang mit der Komplexität der Systeme und der Softwareentwicklung
nicht zuverlässig, so kann dies zu einem Grundmißtrauen in der Gesellschaft
führen. In Fragestellung des Verkehrsaufkommen und Forderung nach Transparenz können
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 xvii

konsistente Folgen darstellen. In den beiden letzten Fällen kann die Verkehrstechnik aber nur
schwer als Motor für die gesamtwirtschaftliche Entwicklung dienen. Ihre Vorreiter Rolle wäre
in Frage gestellt.
Fazit:
Bei dem Übergang von den Ergebnissen der Szenario-Untersuchung zur Strategieentwicklung
sind grundsätzlich zwei Sichtweisen möglich. Einerseits kann eine Strategie zukunftsrobust
angelegt werden. In einem solchem Falle wären alle Maßnahmen gleichermaßen gut für eine
der alternativen Zukünfte geeignet. Andererseits kann eine Strategie fokussiert angelegt werden,
nämlich dann, wenn auf bestimmt notwendige Voraussetzung für eine oder mehrere
Zukünfte abgehoben wird. Dies birgt selbstredend die Gefahr der Fehlentscheidung in sich.
Bei den hier betrachteten eingebetteten Systemen besteht der Fortschritt auf der technischen
und wirtschaftlichen Machbarkeit. Ihm entgegen treten aber Kundenanforderungen, die aus
vielen unterschiedlichen Faktoren bestimmt werden. Diese können sich progressiv oder
degressiv auf den Fortschritt auswirken. Vor diesem Hintergrund erscheint eine zukunftsrobuste
Strategie nicht wirkungsvoll. Vielmehr sind internationale Faktoren ebenfalls ins Kalkül
mit einzubeziehen. Daher wird hier eine Technologie-orientierte, fokussierte Strategie empfohlen.
Zusammenführend lässt sich feststellen, dass die Software-Technologie eine Schlüsselrolle
hinsichtlich der Konsistzenzfähigkeit der Szenarien einnimmt. Ihre Beherrschung in puncto
Effizienz, Qualität, Ausbildung, Methoden und Werkzeuge sind unabdingbare Voraussetzung
für die Erschließung der Erfolgspotenziale von morgen. Dabei spielen selbstredend bei eingebetteten
Systemen aufgrund ihrer „Hardware-Nähe“ zu benachbarten Forschungsgebieten wie
Mechatronik, Sensorik oder Kommunikationstechnik enge Verknüpfungen von denen die eingebetteten
Systeme profitieren wie auch entsprechend gehemmt werden können.
Ohne Software-Technologie sind allerdings die Erfolgspotenziale, die sich durch die rasch entwickelnde
Informations- und Kommuninaktionstechnik für den Maschinenbau und artverwandten
Branchen ergeben nicht erschließbar.
0.8 Aktionsfelder
Im folgenden werden sechs mögliche Vorschläge für Aktionsfelder aufgeführt, die sich aus den
Lösungsansätzen und Szenarien, die im Rahmen der Vordringlichen Aktion ermittelt wurden,
ableiten lassen. Die in Abschnitt erarbeiteten Lösungsansätze stellen technische Lösungen für
die identifizierten Problemfelder dar, benötigen aber zu ihrer Realisierung Umsetzungsmaßnahmen.
Die im folgenden beschriebenen Aktionsfelder stellen jeweils Umsetzungsmechanismen
für ganze Bündel solcher Lösungsansätze da:
• Adaption und Transfer: Aufgabe ist die Einführung eines nach dem heutigen Stand der
Technik und Wissenschaft möglichen Entwicklungsprozesses in kleinen und mittelständischen
Unternehmen. Dabei soll diese Einführung in Form von geförderten Projekten mit
repräsentativen Pilotunternehmen durchgeführt werden. Hauptaufgaben bei der Einführung
eines Entwicklungsprozesses sind die Anpassung vorhandener Vorgehensmodell an die
Bedürfnisse der Unternhemenszielgruppe der Vordringlichen Aktion, die Einführung von
Konfigurationsmanagement und die Definition eines Qualitätssicherungsleitfaden für eingebettete
Systeme.
• Kompetenzzentrum: Ziel dieses Aktionsfelds ist der Aufbau einer Einrichtung zur Koordination
von Aus- und Weiterbildung der Softwareentwicklung für die Anwendungsbereiche
eingebetteter Systeme. Wesentliche Funktion eines solchen Kompetenzzentrum ist es, als
xviii Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

zentrale Anlaufstelle, besonders für klein - und mittelständische Unternehmen, in softwaretechnologischen
Fragen zu dienen. Die Aufgabenstellung eines solchen Kompetenzzentrums
umfasst insbesonder die Vermittlung der ingenieurmäßigen Softwareentwicklung, die
Funktion einer Anlaufstelle für Transfer aktueller Entwicklung im Bereich Softwareentwicklung
für eingebettete Systeme, einer Innovationsdrehscheibe für Diskussion aktueller
Trends und Herausforderungen sowie eines Beratungsgremiums zur Unterstützung von Studiengangreformen.
• Koordination Werkzeugentwicklung: Aufgabe dieses Aktionsfeldes ist es, eine Kontaktplattform
für Werkzeughersteller und KMUs zu schaffen. Diese Kontaktplattform soll als
vermittelnde und moderierende Schnittstelle zwischen den ansonsten gegenüber Werkzeugherstellern
nicht ausreichend repräsentierten kleinen und mittleren Unternehmen dienen.
Die Anpassung an spezifische Bedürfnisse kann beispielsweise in Form von geförderten
Pilotprojekten mit KMUs des Anwendungsbereichs erfolgen.
• Unternehmensübergreifende Standardformen: Schwerpunkt dieses Aktionsfeldes ist die
Schaffung und Bewertung von Standards im Bereich eingebetteter Software. Hierbei steht
nicht die Schaffung von Normen, sondern die Erstellung von direkt umsetzbaren Vorlagen
und Grundkonzepten für die Unternehmen im Vordergrund. Wesentliche Teilaufgaben sind
hierbei die Erfassung von Best-Practice-Ansätzen, die Definition von Standards für Dokumenten-
und Beschreibungsformen (z.B. Lasten- und Pflichtenheft, Prüfpläne), von Standardsystemarchitekturen
und Standardsystembausteine (z.B. Kommunikationsstruktur,
Fehlerbehandlung) und von Standards für Plattformen (z.B. Echtzeitbetriebssysteme) und
Standardrealisierungsarchitekturen (HW und SW).
• Integriertes Vorgehensmodell: Ziel ist hier die Definition eines fach- und unternehmensübergreifenden
Vorgehensmodells. Dieses langfristig angelegte Aktionsfeld stellt daher
einerseits Bündelung der Ergebnisse der vorausgehenden Aktionsfelder dar sowie andererseits
die Integration der Ergebnisse und die Erweiterung um phasen-, fach- und unternehmensübergreifende
Aspekte. Dabei fallen folgende Einzelaufgabenstellungen an:
Phasenübergreifende Entwicklung (Generierung, Rückverfolgung), Unternehmensübergreifende
Entwicklung, Domänenübergreifende Entwicklung (Informatik, E-Technik, Maschinenbau),
Konfiguration und Konsistenzsicherung, Kostenmanagement,
entwicklungsbegleitende Qualitätssicherung, Bausteine und Standardarchitekturen, eine
durchgängige Werkzeugkette sowie der Rückfluss in den Prozess (Wartung).
Ziel dieses Aktionsfelds ist die Bereitstellung neuer Technologien der Informationsverarbeitung
für die Anwendung im Maschinen/Anlagenbau, der Produktions/Automatisierungs/
Verkehrstechnik, z.B. Netzwerktechnologien (inkl. Internet, Jini, etc.), intelligente Bausteine
und adaptive Systeme, OO-Technologien (inkl. CORBA etc.), Virtuelle Produktentwicklung.Verbunden
mit diesen Themenstellungen ist naturgemäß deren Integration in die
anderen Aktionsfelder, insbesondere - wegen des langfristigen Charakters - in das integrierte
Vorgehensmodell. Damit gehen jeweils spezifische Fragestellungen einher, beispielsweise
deren Übernahme in Standardarchitekturen oder Bausteine, Beschreibungsformen
und Werkzeuge, Fragen der Qualitätssicherung oder Konfiguration.
Die vorgestellten Aktionsfelder stellen jedoch keine Projektdefinitionen dar. Es lassen sich
je nach Aufwand und Ressourcen unterschiedliche Schnitte durch diese Themenfelder
legen, um entsprechende Realisierungsprojekte zu definieren. Ein Beispiel für einen Schnitt
ist das Projekt „Einführung eines bausteinorientiertes Vorgehensmodell im Bereich Anlagenbau“,
mit den betroffenen Aktionsfeldern Integriertes Vorgehensmodell mit Schwerpunkt
Bausteinorientierung, Unternehmensübergreifende Standardformen mit Schwerpunkt
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 xix

Standard-SW-Architektur für den Anlagenbau, Adaption und Transfer unter Verwendung
des entwickelten Vorgehensmodells sowie die Überführung in ein Kompetenzzentrum nach
Erprobung des entwickelten Vorgehensmodells mit Pilotunternehmen.
xx Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

Inhalt
1 Einleitung...................................................................................................................... 1
2 Gegenstand der Vordringlichen Aktion........................................................................ 3
2.1 Inhalte, Ziele und Aufbau des Abschlußberichts ................................................4
2.2 Angrenzende Projekte .........................................................................................5
2.2.1 FORSOFT-Befragung „Stand der Software-Entwicklung” .......................5
2.2.2 Befragung SoftBed .....................................................................................6
2.2.3 Untersuchung: "Stand des Qualitätsmanagements in der Softwareentwicklung"
...........................................................................................................7
2.2.4 Umfrage: “Prüfen und Testen von Software in Deutschland” ...................7
3 Befragung der Unternehmen......................................................................................... 9
3.1 Ziel der Befragung ...............................................................................................9
3.2 Klassifikation der Unternehmen ..........................................................................9
3.3 Ergebnisse der Befragung ..................................................................................10
3.3.1 Interdisziplinäre Zusammenarbeit ............................................................11
3.3.2 Vorgehensmodell .....................................................................................14
3.3.3 Anforderungsanalyse ...............................................................................18
3.3.4 Design ......................................................................................................21
3.3.5 Implementierung ......................................................................................24
3.3.6 Service und Wartung ................................................................................29
3.3.7 Qualitätssicherung ....................................................................................31
3.3.8 Konfigurationsmanagement .....................................................................38
3.3.9 Beschreibungstechniken und Werkzeuge ................................................42
4 Zukunftsszenarien - Ergebnisse einer Szenario-Analyse............................................ 51
4.1 Einordnung der Zukunftsszenarien in die VA ...................................................52
4.2 Szenarien der Vordringlichen Aktion ................................................................53
4.2.1 Szenarien des Anlagen- und Maschinenbaus ...........................................53
4.2.2 Szenarien der Automatisierungs- und Produktionstechnik ......................58
4.2.3 Szenarien der Verkehrstechnik ................................................................63

5 Lösungsansätze ........................................................................................................... 67
5.1 Interdisziplinäre Zusammenarbeit .....................................................................67
5.1.1 Kurz- bis mittelfristige Lösungsansätze ...................................................67
5.1.2 Langfristige Lösungsansätze ....................................................................68
5.1.3 Übersicht Problemfelder und Lösungsansätze .........................................69
5.2 Prozeßmanagement und Vorgehensmodell .......................................................70
5.2.1 Kurz- bis mittelfristige Ansätze ...............................................................70
5.2.2 Langfristige Ansätze und Forschungsbedarf ............................................71
5.2.3 Übersicht Problemfelder und Lösungsansätze .........................................75
5.3 Qualitätssicherung .............................................................................................76
5.3.1 Kurz- bis mittelfristige Ansätze ...............................................................77
5.3.2 Langfristige Ansätze und Forschungsbedarf ............................................78
5.3.3 Übersicht Problemfelder und Lösungsansätze .........................................79
5.4 Konfigurationsmanagement ..............................................................................79
5.4.1 Kurz- bis mittelfristige Ansätze ...............................................................79
5.4.2 Langfristige Ansätze und Forschungsbedarf ............................................81
5.4.3 Übersicht Problemfelder und Lösungsansätze .........................................83
5.5 Werkzeuge und Beschreibungstechniken ..........................................................83
5.5.1 Kurz- bis mittelfristige Ansätze ...............................................................84
5.5.2 Langfristige Ansätze und Forschungsbedarf ...........................................86
5.5.3 Übersicht Problemfelder und Lösungsansätze .........................................88
6 Aktionsfelder............................................................................................................... 89
6.1 Adaption und Transfer .......................................................................................89
6.2 Kompetenzzentrum ............................................................................................90
6.3 Koordination Werkzeugentwicklung .................................................................91
6.4 Unternehmensübergreifende Standardformen ...................................................92
6.5 Integriertes Vorgehensmodell ...........................................................................93
6.6 Neue Ansätze in der Informationsverarbeitung .................................................95
6.7 Projekte ..............................................................................................................96
7 Fragebögen.................................................................................................................. 97
7.1 Vorabfragebogen ...............................................................................................97
7.2 Interviewleitfaden ............................................................................................101
8 Szenario-Management .............................................................................................. 113
8.1 Grundlagen des Szenario-Managements .........................................................113
8.1.1 Vernetztes Denken .................................................................................113
8.1.2 Multiple Zukunft ....................................................................................114
8.1.3 Phasen des Szenario-Projektes ...............................................................114
8.2 Szenariofeld-Analyse ......................................................................................117
8.2.1 Bildung von Einflußbereichen ...............................................................117
8.2.2 Ermittlung von Einflußfaktoren .............................................................118
8.2.3 Ermittlung von Schlüsselfaktoren ..........................................................121
8.2.4 Zuordnung der Schlüsselfaktoren zu den Anwendungsdomänen ..........125
8.3 Szenario-Prognostik ........................................................................................125
xxii Version vom 3.Februar 00 Abschlußbericht Vordringliche Aktion

8.3.1 Vorgehen ................................................................................................125
8.4 Szenario-Bildung .............................................................................................140
8.4.1 Vorgehen ................................................................................................140
9 Liste der beteiligten Unternehmen............................................................................ 145
Abschlußbericht Vordringliche Aktion Version vom 3.Februar 00 xxiii

xxiv Version vom 3.Februar 00 Abschlußbericht Vordringliche Aktion

1 Einleitung
Die Softwaretechnik hat sich in vielen Anwendungsgebieten zu einer Schlüsseltechnologie
entwickelt. Dies gilt insbesondere für den Maschinen- und Anlagenbau, die Automatisierungsund
Produktionstechnik und die Verkehrstechnik. Hier werden sogenannte “eingebettete Systeme”
für komplexe und vielfältige Aufgaben eingesetzt, mit den verschiedensten Realisierungsformen,
von der SPS bis hin zur Firmware in Aktoren und Sensoren.
Ein eingebettetes System ist eine Software-/Hardware-Einheit, die über Sensoren und Aktuatoren
mit einem Gesamtsystem verbunden ist und in diesem Überwachungs-, Steuerungs- oder
Regelungsaufgaben wahrnimmt. In der Regel handelt es sich um reaktive, häufig auch um verteilte
Systeme mit gemischt analog/digitalen Anteilen und Echtzeitanforderungen. Typischerweise
bleiben solche Systeme dem menschlichen Benutzer verborgen, er interagiert mit ihnen,
ohne sich der Mitwirkung eines eingebetteten Systems bewußt zu sein. Eingebettete Systeme
verfügen meist über keine standardisierte Peripherie. Aufgrund ihrer vielfältigen Anwendungsbereiche
stellen sie ein Paradebeispiel für ein interdisziplinäres Forschungs- und Entwicklungsgebiet
dar.
Software bestimmt in vielen Bereichen zunehmend den Kundennutzen und macht einen erheb-
Abbildung 1. Entwicklung der Produktanteile
lichen Teil der Wertschöpfung aus. In den Produkten hat sich der Anteil der Kosten von den
traditionellen Elementen Mechanik und Elektrik stark in Richtung der neuen Technologien
Mikroelektronik und Software verlagert (siehe Abbildung 1). Beispielsweise liegt der Anteil
der Elektronik in der Automobilindustrie heute schon zwischen 25% und 30% – mit steigender
Tendenz. Es gibt Aussagen, wonach der Mehrwert am Automobil zukünftig ausschließlich
durch Software und Elektronik zu Stande kommt. Eine noch stärkere Verlagerung in Richtung
Software ist im Bereich der Kleinserie und der Unikate zu erkennen, wo in erster Linie die Entwicklungskosten
dominieren. Von den Entwicklungsaufwendungen für neue Produkte im
Bereich des Maschinenbaus entfallen bis zu 50 % auf die darin enthaltene Software. In einigen
technischen Produkten des Maschinen- und Anlagenbaus erreicht die Software sogar Anteile
von 75% bis 80% der Herstellungskosten1 .
Darüber hinaus bilden Erzeugnisse mit einem hohen Softwareanteil auch eine gute Plattform
für die Ausweitung der Geschäftstätigkeit in Richtung Dienstleistungen. Viele Unternehmen
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 1

haben unter Berücksichtigung dieser Gegebenheiten bereits heute Software als Kernkompetenz
identifiziert.
Zwischen Anspruch und Wirklichkeit klafft jedoch eine erhebliche Lücke. Trotz jahrzehntelanger
Tradition in der Softwareentwicklung hat sich bis auf wenige Ausnahmen an der wenig
professionellen Art der Softwareentwicklung und -wartung in den Unternehmen nichts maßgebliches
geändert. Von einer systematischen Software-Entwicklung sind die meisten Unternehmen
noch weit entfernt. Die Folge sind erhebliche Kosten und Risiken im Zusammenhang
mit der Entwicklung und dem Service von Software. Kleinere Unternehmen konzentrieren sich
auf die Herstellung der maschinenbaulichen Komponenten und überlassen die Entwicklung
der Steuerung auf der Basis von LON (Local Operating Network) Dritten.
Aus der rasanten Entwicklung der Informations- und Kommunikationstechnologie ergeben
sich für den Maschinenbau und artverwandte Branchen erhebliche Chancen, aber auch Risken.
Diese Potentiale gehen häufig über den aktuellen Erfahrungshorizont hinaus. Was wäre beispielsweise
möglich, wenn leistungsfähige, voll kommunikationsfähige Mikroprozessoren und
Sensoren zum Preis einer Schraube erhältlich wären? Der Umgang mit den sich abzeichnenden
Lösungsprinzipien und Lösungselementen der Zukunft wird erhebliche Verfahrensinnovationen
(aber auch Verhaltensinnovationen) in den Produktentwicklungsprozessen erfordern. Die
Entwicklung und Wartung von eingebetteter Software wird dabei eine Schlüsselstellung einnehmen.
Zusammenfassend läßt sich feststellen:
Die Entwicklung und der Service eingebetteter Systeme führt auf große Probleme und Herausforderungen
- dies gilt vornehmlich für den Softwareanteil dieser Systeme. Jedoch stecken in
den Anwendungsmöglichkeiten eingebetteter Systeme prinzipiell erhebliche Erfolgspotentiale
für die Industrie. Diese sind um so größer, je besser diese Probleme gelöst werden.
Im Rahmen der Vordringlichen Aktion (VA) “Entwicklung, Produktion und Service von Software
für eingebettete Systeme in der Produktion” werden diese Probleme und Erfolgspotentiale
herausgearbeitet.
1. Software und Services: Markt- und Technologietrends in der Softwareszene, Presse Information zur Swiss
Automation Week S. A. W. ’96, PRESSLine, 1996.
2 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

2 Gegenstand der Vordringlichen Aktion
Aufbauend auf den Erfahrungen aus dem Rahmenkonzept "Produktion 2000" und der Empfehlung
des Gesprächskreises "Strategien für die Produktion im 21. Jahrhundert" startete das
BMBF Anfang 1997 eine Untersuchung "Produktion 2000plus". Sie hatte zum Ziel, standortbestimmende
Faktoren für produzierende Unternehmen in Deutschland zu ermitteln und Handlungsempfehlungen
zur Stärkung der Wettbewerbsfähigkeit abzuleiten. Repräsentanten aus
Industrie und Forschung, Vertreter der Tarifvertragspartner und der Fachverbände haben über
aktuelle Trends und Lösungsvorschläge diskutiert und Empfehlungen für den daraus resultierenden
Handlungsbedarf ausgesprochen.
Das Gremium hat während der Untersuchung "Produktion 2000plus" Themen identifiziert, die
von wesentlicher Bedeutung für eine wettbewerbsfähige Produktion sind. Es sind übergreifende
Fragestellungen mit
• einer hohen volkswirtschaftlichen Relevanz,
• die in der Breite wirksam werden,
• die eine Stärkung des Mittelstandes bewirken können,
• die sich durch einen hohen Neuheitsgrad auszeichnen und rasch aufgegriffen werden sollen.
Diese Themen wurden als "Vordringliche Aktionen" gestartet. Sie dienen als Vorprojekte und
Impulsgeber zur Spezifikation und Konkretisierung weiterer Handlungsfelder.
Die Vordringliche Aktion „Entwicklung, Produktion und Service von Software für eingebettete
Systeme in der Produktion” beschäftigt sich mit dem Themenfeld der Entwicklung und dem
Service von Software für bestimmte Klassen eingebetteter Systeme. Unter besonderer Berücksichtigung
der Softwaretechnik ergeben sich die folgenden Teilziele:
Es werden
• der konkrete - aber unternehmensübergreifende - Bedarf der Industrie zu diesem Themenfeld
festgestellt,
• aktuelle und zukünftige Probleme innerhalb dieses Themenfeldes erkannt, bewertet und
verglichen,
• existierende Lösungsansätze dargestellt und bewertet sowie
• Aktionsfelder abgeleitet werden, deren zukünftige Durchführung zur Lösung der obigen
Probleme und dadurch zur Erschließung der Erfolgspotentiale beim Einsatz eingebetteter
Systeme beitragen könnten.
Insbesondere das erste Teilziel wurde in enger Interaktion mit einer repräsentativen Auswahl
an Industriefirmen durchgeführt. Dazu wurde eine detaillierte Befragung in der Industrie vorgenommen,
um ein Vorgehen sicherzustellen, das an konkreten industriellen Belangen mit
hoher volkswirtschaftlicher Bedeutung orientiert ist.
Der im letzten Teilziel erwähnte Begriff „Aktionsfelder” umfaßt erfolgversprechende gezielte
Maßnahmen zum Technologietransfer (z.B. Etablierung von Industriearbeitskreisen oder
Workshops), zur Aus- und Weiterbildung (z.B. Definition der Rahmenbedingungen eines
neuen Studienganges) sowie zur Gewinnung neuer Forschungsergebnisse (z.B. Charakterisierung
zukünftiger, evtl. internationaler Forschungsprojekte).
Das Thema „eingebettete Systeme” dieser VA ist unter anderem durch den Sachverhalt motiviert,
daß derartige Systeme viele Bereiche mehr und mehr durchdringen - wichtige Beispiele
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 3

hierfür sind: Anlagen- und Maschinenbau, Automatisierungs- und Produktionstechnik, Automobiltechnik,
Avionik, Bahntechnik, Telekommunikation, Konsumelektronik (Unterhaltungsund
Haushaltsgerätebereich) und Medizintechnik.
Die besondere Berücksichtigung software-technischer Belange in dieser VA trägt der Tatsache
Rechnung, daß die Verbreitung eingebetteter Regelsystem und auch ihr Software-Anteil in eingebetteten
Systemen sprunghaft angestiegen ist und zukünftig noch weiter wachsen wird.
Dabei bereitet aber gerade die Entwicklung des Software-Anteils zunehmend Schwierigkeiten.
2.1 Inhalte, Ziele und Aufbau des Abschlußberichts
Ziel des Abschlußbericht ist es, den Ist-Stand des Softwareentwicklungsprozesses im Bereich
der eingebetteten Systeme in der Produktion ausgehend von den im Industriekreis durchgeführten
Interviews zu dokumentieren, die identifizierten Problemfelder zu erfassen, sowie den
von den Unternehmen selbst festgestellten Handlungsbedarf zu erheben. Die Zielgruppe dieser
Erhebung, und die damit im Industriekreis vertretenen Firmen sind kleine- und mittelständische
Unternehmen sowie einige Großfirmen aus den Bereichen
• Maschinen- und Anlagenbau
• Automatisierungs- und Produktionstechnik
• Verkehrstechnik
Die Schwerpunkte der Erhebung liegen dabei auf den Themenfeldern
• Software-Qualität
• Standardarchitekturen/komponentenbasierte Entwicklung
• Konfigurations-/Versionsmanagement
wobei unter dem Stichwort Software-Qualität die Themenblöcke
• Qualitätsmanagement
• integriertes, werkzeuggestütztes Vorgehensmodell
• Qualitätssicherung
zusammengefaßt sind.
Im Anschluss an die Kurzbeschreibung einiger im Umfeld der Vordringlichen Aktion angesiedelten
Untersuchungen (siehe Abschnitt 2.2) werden die Ergebnisse der Erhebung in Abschnitt
3 beschrieben. Die Darstellung der Ergebnisse orientiert sich dabei an dem für die Erhebung
verwendeten Vorabfragebogen sowie Interviewleitfaden (siehe Abschnitt 7). Ziel der Befragung
war es dabei nicht, einen statistische Aussage über die Unternehmen der oben genannten
Felder zu machen, sondern vielmehr den Bedarf dieser Unternehmen zu charakterisieren.
Daher werden in der Beschreibung der Ergebnisse in erster Linie qualitative anstatt quantitative
Aussagen getroffen.
Für die nachhaltige Sicherung der Wettbewerbsfähigkeit ist jedoch eine Entwicklung ausschließlich
aufgrund von aktuellen Defiziten nicht ausreichend. Für die Identifizierung langfristiger
Aufgabenstellungen ist darüber hinaus eine sorgfältige Analyse möglicher
Entwicklungen in der Branche, im Branchenumfeld, im technologischen Umfeld sowie innerhalb
der Gesellschaft notwendig. Daher wurden im Rahmen der Vordringlichen Aktion mögliche
mittelfristige Zukunftszenarien für die Bereiche Maschinen- und Anlagenbau,
Produktions- und Automatisierungstechnik sowie Verkehrstechnik mit einem Zeithorizont von
acht Jahren (ca. 2008) entwickelt, um vorausgreifende Maßnahmen rechtzeitig etablieren zu
4 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

können. Die Ergebnisse der Szenarienerstellung sind in Abschnitt 4 zusammengefaßt. Aufgrund
des langfristigen Charakters der Szenarien können die dabei gewonnenen Erkenntnisse
nicht umfassend in Zeitrahmen der Vordringlichen Aktion umgesetzt werden. Trotzdem wurde
der ausführlichen Behandlung der Szenarien in diesem Abschnitt bewußt ein entsprechender
Anteil eingeräumt, da diese den begonnenen und in Zukunft sich verschärfenden Wandel im
Themengebiet der Vordringlichen Aktion über die bereits sichtbaren Anzeichen hinaus deutlich
macht. Die Vorbereitung auf diesen Wandel über die den Rahmen der Vordringlichen
Aktion übersteigenden Möglichkeiten ist für die Sicherung der Wettbewerbsfähigkeit großer
wie kleiner und mittelständischer Unternehmen von wesentlicher Bedeutung.
Ausgehend von den in der Erhebung gewonnenen Informationen über die identifizierten Problemstellungen
und dem genannten Handlungsbedarf werden, teilweise zusammen mit den
Erkenntnissen aus den Zukunftszenarien, konkrete Aufgabenstellungen abgeleitet und mögliche
kurz-, mittel- und langfristigen Lösungsansätze sowie die sich daraus ergebenden Vorteile
für die Unternehmen der Zielgruppe beschrieben. Die Lösungsansätze werden in Abschnitt 5
beschrieben.
Die in Abschnitt 3.3 beschriebenen Probleme und Verbesserungspotentiale spiegeln den konzentrierten
Bedarf der Industrie unter Berücksichtigung des aktuellen Standes von Technik und
Wissenschaft wider. In Zusammenarbeit mit den Unternehmen der Zielgruppe der Vordringlichen
Aktion wurden durch Gruppierung dieser Verbesserungspotentiale Aktionsfelder für die
Sicherung des Standorts Deutschland in der Produktion definiert. Aus diesen, in Abschnitt 6
beschriebenen Aktionsfeldern lassen sich unterschiedliche Projektkonfigurationen ableiten,
von denen eine Projektdefinition beispielhaft vorgestellt werden.
2.2 Angrenzende Projekte
Im thematischen Umfeld der Vordringlichen Aktion wurden bereits Arbeiten geleistet, deren
Ergebnisse für die Ziele der VA von Bedeutung sind. Im folgenden wird daher auf diese Projekte
und die dabei erzielten Ergebnisse kurz eingegangen, soweit sie für die VA von Belang
sind.
2.2.1 FORSOFT-Befragung „Stand der Software-Entwicklung”
Im Rahmen des “Bayerischen Forschungsverbunds Software-Engineering” (FORSOFT) wurde
bei 14 Unternehmen eine Befragung zur Erhebung des Standes der Software-Entwicklung
durchgeführt. 1 Insbesondere wurden in dieser Befragung auch die für die VA wesentlichen
Punkte Prozeßmodell, Qualitätssicherung, Beschreibungstechniken und Werkzeuge untersucht.
Bei der Gestaltung des VA-Fragebogens konnte daher auf die entsprechenden Themenfelder
des FORSOFT-Fragebogens zurückgegriffen werden. Da die FORSOFT-Befragung
jedoch allgemein den Stand der Softwareentwicklung untersucht und nicht speziell die Gegebenheiten
klein- und mittelständischer Unternehmen im Bereich eingebetteter Systeme berücksichtigt,
sind die Ergebnisse nur bedingt im Rahmen der VA anwendbar.
Die Befragungen haben gezeigt, daß die grundsätzliche Situation der Softwareentwicklung
sich in den verschiedenen Anwendungsbereichen kaum unterscheidet. So werden beispielsweise
allgemein kaum abstraktere Systembeschreibungsformen in der Entwicklung verwendet
oder phasenübergreifend geeignete Werkzeuge eingesetzt. Die besonderen Gegebenheiten in
1. Siehe Deifel, B. et al. Die Praxis der Softwareentwicklung: Eine Erhebung. Informatik-Spektrum 22(1). Springer,
1999.
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 5

Bereichen der VA wie der Automatisierungstechnik stellen jedoch spezifische Anforderungen,
beispielsweise die Behandlung von Echtzeitanforderungen, ermöglichen aber auch spezifische
Lösungen, beispielsweise die intensive Verwendung von Systembausteinen mit HW- und SW-
Anteilen zur effizienten Variantenbildung.
2.2.2 Befragung SoftBed
Gegenstand des Forschungsvorhabens SOFTBED war es, Antworten auf die folgenden Fragen
zu geben und diese in Handlungsempfehlungen an das BMBF umzusetzen:
• Inwieweit ist der Prozeß der Entwicklung eingebetteter Systeme - beginnend bei der Funktionsdefinition
bis hin zum Serienprodukt - in seinen wissenschaftlichen Grundlagen und der
industriellen Praxis beherrscht?
• Besteht Potential und Bedarf zur zielgerichteten, öffentlichen Förderung von Forschung
und Entwicklung im Bereich eingebetteter Systeme in der Automobiltechnik?
Ein wesentlicher Teil der Arbeit im Projekt SOFTBED bestand in der Erstellung einer Ist-Analyse
des Standes Deutschlands bei Entwicklung und Einsatz eingebetteter Systeme in der
Automobiltechnik. Um die Analyse auf eine möglichst breite Basis von Meinungen zu stellen,
wurde eine Befragung von Expertinnen und Experten aus Industrie und akademischer Forschung
verwendet.
Als Ergebnis der Studie wurden die Behandlung der folgenden Themengebiete als Handlungsbedarf
identifiziert:
• Phasenübergreifendes Prozeßmodell
• Modellierungs- und Beschreibungstechniken:
+ Integration von diskreter und kontinuierlicher Information
+ Modularisierung mit geeigneten Schnittstellen
+ Ausführbarkeit von Spezifikationen
+ generische Beschreibungen auf allen Abstraktionsebenen
+ semantisches Verfolgbarkeitsmodell zwischen den Beschreibungen in den verschiedenen
Phasen
• Erstellung eines integrierten Qualitätssicherungskonzepts unter Einbeziehung von Rapid-
Prototyping
• Behandlung der Zeitaspekte eingebetteter Systeme
• Softwarebausteine:
+ Beschreibungstechniken
+ Kompositionskonzepte
+ angepaßte Verifikationstechniken
+ generische Bausteinbibliotheken
• Globale Vernetzung
• Hardware-Constraints und HW/SW-Codesign
+ Targeting-Problematik
+ DSSA
+ Verifikation und Validation
6 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

• Verteilung
+ Beschreibungstechniken,
+ Simulation,
+ Verifikation und Validation
+ Systemintegration
• Kostenoptimierung
+ Metriken zur Kostenermittlung
+ Optimierungsverfahren
Grundsätzlich stimmen die dort definierten Themengebiete, zumindest im groben Ansatz, mit
den hier festgestellten Verbesserungspotentialen überein, bedingt durch die teilweise vergleichbaren
Randbedingungen der befragten Unternehmen. Da im Zuge der Vordringlichen
Aktion jedoch - wie in Abschnitt 3.2 beschrieben - unterschiedliche Klassen von Unternehmen
berücksichtigt wurden, unterscheiden sich die hier vorgeschlagenen Lösungsansätze vor
allem hinsichtlich der kurz- bis mittelfristigen Vorschläge, die stark von der Anwendungsdomäne
sowie von der Größe der Unternehmen (KMU) geprägt sind.
2.2.3 Untersuchung: "Stand des Qualitätsmanagements in der Softwareentwicklung"
In einer 1997 durchgeführten schriftlichen Befragung wurde der Stand des Qualitätsmanagements
und der kontinuierlichen Verbesserung in den Softwareunternehmen in Deutschland
untersucht, die ihr Qualitätsmanagementsystem nach ISO 9001 hatten zertifizieren lassen. 1
Aus den 119 in die Stichprobe einbezogenen Unternehmen wurden 90 gültige Fragebögen
zurückgesandt. Mehr als 80 % der Befragungsteilnehmer halten die QM-Systeme für erfolgreich.
Allerdings haben die durch das Qualitätsmanagement erzielten Vorteile nur in wenigen Unternehmen
zu einer verbesserten Einhaltung von Zeit- und Kostenplänen oder zu nennenswerten
Umsatzerhöhungen geführt.
Bewertung für die VA: Die Untersuchung besitzt aus Sicht der Vordringlichen Aktion einen zu
engen Fokus, da sie ausschließlich Softwareunternehmen sowie das Thema Qualitätsmanagementsystem
nach ISO 9001 betrachtet.
2.2.4 Umfrage: “Prüfen und Testen von Software in Deutschland”
Im Herbst 1997 wurde eine empirische Untersuchung zu dem obigen Thema an der Universität
zu Köln durchgeführt. Die Umfrage hatte zum Ziel, den Praxisstand der Prüf- und Testprozesse
in der Softwareentwicklung darzustellen und Verbesserungspotentiale aufzuzeigen. 74 Unternehmen
wurden zu den Themen Management, Ausgestaltung, Methoden und Techniken sowie
zum Werkzeugeinsatz beim Prüfen und Testen von Software befragt.
Für die Untersuchung wurde ausgehend von 10 Hypothesen ein Fragebogen entwickelt. Auf
einer fünfstufigen Zustimmungs- bzw. Ablehnungsskala nahmen die Befragten (i. d. R. Leiter
der Entwicklungs- oder Qualitätsabteilungen) zu den vorformulierten Aussagen Stellung. Es
wurden unter Verwendung des Fragebogens 589 Firmen befragt, neben Softwarehäusern (ein-
1. Dirk Stelzer, Werner Mellis, Frank Taube. Stand des Qualitätsmanagements in der Softwareentwicklung. In:
Wilhelm Hummeltenberg (Hrsg.): Information Management for Business and Competitive Intelligence and
Excellence. Proceedings der Frühjahrstagung Wirtschaftsinformatik ‘98. Wiesbaden 1998, S. 313-326
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 7

schließlich den 25 größten) gehörten die 100 umsatzstärksten Unternehmen Deutschlands
sowie die 50 größten Banken und Versicherungen zu der Grundgesamtheit der Umfrage.
Die Ergebnisse dieser Untersuchung sind für die Software von technischen Produkten – eingebettete
Systeme – wegen deren besonderen Anforderungen nicht vergleichbar und übertragbar.
Sehr wohl können aber die Methodik und gegebenenfalls einige Teilaspekte übertragen werden.
8 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

3 Befragung der Unternehmen
3.1 Ziel der Befragung
Im Rahmen der Befragung sollten vor allem die folgenden drei Aufgabenstellungen bearbeitet
werden:
• Ermittelung des Ist-Zustands einschließlich vorgefundener praxiserprobter Ansätze („Best
Practice“)
• Ableitung nicht ausreichend gelöster Problemstellungen
• Erfassung des vorgefundenen Handlungsbedarfs der befragten Unternehmen
Aufbauend auf der Dokumentation der Ergebnisse der Befragungen werden in Abschnitt
Abschnitt 5 konkrete Verbesserungspotentiale definiert. Diese Handlungsempfehlungen sind
dabei einerseits am kurz- bis mittelfristigen Bedarf der Unternehmen orientiert, aber auch um
langfristige Empfehlungen zur Sicherung und Steigerung der Produktivität ergänzt. Soweit
nötig, werden diese Potentiale auf Basis der im folgenden beschriebenen Klassifikation der
Unternehmen vorgenommen.
3.2 Klassifikation der Unternehmen
Für die Durchführung der Befragungen stellten sich die Mitglieder des Industriekreises zur
Verfügung. Die Zielgruppe der Vordringlichen Aktion besteht in erster Linie aus klein- und
mittelständische Unternehmen, aber auch Bereiche von Großunternehmen aus dem Themenbereich
der Vordringlichen Aktion zählen zu den anvisierten Gruppen. Dementsprechend setzt
sich der Industriekreis aus 40 Unternehmen zusammen mit einer entsprechenden Gewichtung
der Mitarbeitergröße:
• 1-50: 10
• 51-1000: 15
• 1001- : 15
Dabei sind die Themenfelder der Vordringlichen Aktion abgedeckt durch die Teilnahme von
Unternehmen aus den verschiedenen Bereichen:
• Automatisierungstechnik: 13
• Maschinen- und Anlagenbau: 9
• Elektrik, Meßtechnik: 6
• Software-Entwicklung: 6
• Verkehrstechnik: 4
• Andere Bereiche: 2
Aus den unterschiedlichen Themenfeldern der befragten Unternehmen ergeben sich auch
unterschiedliche Anforderungen und Bedürfnisse hinsichtlich des Entwurfs, der Produktion
und des Service von Software für eingebettete Systeme. Hier lassen sich im wesentlichen drei
Hauptgruppen unterscheiden, die sich auf den Anteil der Software am vom Unternehmen
erstellten Produkt zurückführen läßt:
• Schwerpunkt SW:
+ Unternehmen meist Auftragnehmer von ES-Herstellern
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 9

+ Produktspektrum: Kaum Varianten
+ Fokus: Komplexe/kritische SW
• Gleiche Gewichtung HW/SW
+ Anlagenhersteller mit eigener SW-Abteilung
+ Produktspektrum: Hohe Anzahl von Varianten
+ Fokus: Konfiguration
• Schwerpunkt HW
+ Komponentenhersteller mit Einzelinstallationen von Anlagen
+ Produktspektrum: Mittlere Anzahl von Varianten
+ Fokus: Integration der SW
Viele Aufgabenstellungen des SW-Entwicklungsprozesses lassen sich unabhängig von dieser
Unterscheidung auf die Unternehmen anwenden, beispielsweise Messverfahren zur Beurteilung
der Softwarequalität, die Definition eines integrierten und durchgängig werkzeuggestützen
Entwicklungsprozesses, die Definition geeigneter und standardisierter präziser und
echtzeittauglicher Beschreibungsformen, eine verstärkte Automatisierung der Tests im Qualitätssicherungsbereich
oder die Behandlung von Dokumentabhängigkeiten im Konfigurationsmanagement.
Andere Aufgabenstellungen sind stark an die Einordnung des Unternehmens
gekoppelt, wie beispielsweise die Definition von Bausteinen (mit HW- und SW-Anteilen) und
die Verwendung von Standardarchitekturen für Unternehmen mit gleichgestellten SW- und
HW-Anteilen. Beide Arten von Anforderungen finden sich sowohl im kurz- und mittelfristigen
Bedarf der Unternehmen (siehe Abschnitt 5.2) als auch im langfristigen (siehe Abschnitt
5.1.2). Diese Gruppierung ist selbstverständlich nicht scharf: es finden sich daher Beispiele für
Unternehmen, die sich zwischen zwei solcher nebeneinanderliegender Gruppen einordnen lassen.
Für diese Unternehmen ist eine Kombination der Aufgabenstellungen der einzelnen Bereiche
sowie der grundlegenden Aufgabenstellungen notwendig.
3.3 Ergebnisse der Befragung
Die Ergebnisse der Befragung sind entsprechend der Gliederung der Fragebögen in die folgenden
Themenfelder gruppiert:
• Interdisziplinäre Zusammenarbeit
• Vorgehensmodell
• Anforderungsanalyse
• Design
• Implementierung
• Wartung und Service
• Qualitätssicherung
• Konfigurationsmanagement
• Beschreibungstechniken und Werkzeuge
Zur besseren Lesbarkeit wurde dabei die Reihenfolge gegenüber den Fragebögen geändert:
1. Im ersten Block werden diejenigen Themen behandelt, die allgemein den Entwicklungsprozeß
betreffen (Interdisziplinäre Zusammenarbeit, Vorgehensmodell).
10 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

2. Im zweiten Block werden einzelne Phasen im Entwicklungsprozeß behandelt (Anforderungsanalyse,
Design, Implementierung, Wartung- und Service).
3. Im dritten Block sind übergreifende technische Fragestellung behandelt (Qualitätssicherung,
Konfigurationsmanagement, Beschreibungstechniken und Werkzeuge).
Dabei treten naturgemäß teilweise Überschneidungen auf, beispielsweise zwischen den phasenbezogenen
Themen und den übergreifenden technischen Fragestellungen, aber auch zwischen
letzteren und den allgemeinen prozeßbezogenen Themen.
Da sich die Gliederung dieses Abschnitts zur besseren Zuordnung an die Befragung am Aufbau
des Fragebogens orientiert, wurde einigen Themen, wie dem Einsatz von Standardarchitekturen
und Bausteinen, kein eigener Abschnitt zugeordnet, obwohl sie im Rahmen der
Befragung als Themen mit hoher Bedeutung identifiziert wurden. Die Bedeutung der einzelnen
Themenfelder für die Sicherung der Wettbewerbsfähigkeit spiegelt sich jedoch bei allen
Themen in der abschließenden Beschreibung der Aktionsfelder in Abschnitt 6 wider.
Die Ergebnisse in den genannten Themenfelder sind jeweils in drei Gruppen gegliedert:
4. Im Abschnitt „Ist-Stand“ wird jeweils eine zusammenfassende Auswertung des aktuellen
Standes der einzelnen Themenfelder, gegebenenfalls klassifiziert nach Unternehmensart,
vorgestellt. Soweit möglich, werden die Befragungsergebnisse statistisch aufbereitet.
5. Bei der Erhebung des Ist-Standes werden bereits Defizite hinsichtlich eines nach dem heuteigen
Stand der Technik und Wissenschaft optimal erscheinenden Entwicklungsprozesses
identifiziert und deren Auswirkungen für die Unternehmen im Abschnitt „Probleme“
beschrieben. Dabei wurden vor allem anerkannte Ansätze aus dem Bereich der Softwareentwicklung
herangezogen, wie der „Capability Maturity Model“-Ansatz (CMM), das V-
Modell oder aktuelle Werkzeugansätze im Bereich Test, Konfigurationsmanagement,
Anforderungsanalyse oder Design.
6. Soweit die Unternehmen selbst Handlungsbedarf identifizierten, werden diese Nennungen
im Abschnitt „Handlungsbedarf“ zusammengefaßt und erläutert. Dabei bestehen naturgemäß
teilweise Überschneidungen zum vorherigen Abschnitt. Dieser Abschnitt spiegelt
ebenfalls das Problembewußtsein der befragten Unternehmen wider.
3.3.1 Interdisziplinäre Zusammenarbeit
Ist-Stand
Bei der Erstellung und Planung von Systemen mit eingebetteter Software ist die Zusammenarbeit
verschiedener Disziplinen notwendig. Normalerweise werden durch unterschiedliche Terminologien
und Sprachweisen auf der einen Seite Programmierer und Informatiker und auf der
anderen Seite Ingenieure (Maschinenbau, Elektrotechnik, Physik) ab einem gewissen Abstraktionsgrad
mit Kommunikationsbarrieren konfrontiert.
Bei den befragten Unternehmen stellen sich die Probleme bezüglich der interdisziplinären
Zusammenarbeit, sofern sie zwischen den Ingenieurdisziplinen stattfinden, als weniger kritisch
als zunächst vermutet dar. Gerade in kleinen Projektteams können nach einer Anfangsphase,
die bei der Klärung unterschiedlicher Begrifflichkeiten behilflich ist, die der Herstellung eines
einheitlichen Projektverständnisses im Wege stehenden Kommunikations- und Verständnisprobleme
durch gegenseitiges Voneinanderlernen schnell behoben werden. Die unterschiedliche
Sichtweise der beteiligten Ingenieurdisziplinen führt gerade in den frühen
Entwicklungsphasen zu einer ganzheitlicheren Betrachtung und hilft in der Analysephase,
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 11

wichtige Systemaspekte nicht zu vergessen. Dies gilt aber wirklich nur für kleine Entwicklungsteams,
in denen die Zusammenarbeit und der Informationsfluß sehr informell geregelt
werden können.
Bei Projekten, in denen die Systemanforderungen von einem separaten Bereich vorgegeben
werden, der zusätzlich auch den Entwicklungsfortschritt des Gesamtprojektes bestimmt, also
solche Projekte, wo die Softwareentwicklung eine eher nebengeordnete Rolle spielt und nicht
Treiber des Projektes ist, sondern nur zuarbeitet, ist die Zusammenarbeit zwischen Softwareentwicklern
und Systementwicklern auf kurze Absprachen beschränkt. Hier ist auch eine hierarchische
Abstufung zwischen den Entwicklungsdomänen zu beobachten. Während die
Entwicklung des Gesamtsystems das Projekt dominiert und dabei Projektphasen, Meilensteine,
Anforderungen und Randbedingungen bestimmt, wird von der Softwareentwicklung erwartet,
daß sie alle geforderten Spezifikationen erfüllt und die gesetzten Termine einhält. Die Software
wird als der flexibelste Part verstanden, der sich den Gegebenheiten im Gesamtprojekt uneingeschränkt
anpassen muß. Hier fehlt auf beiden Seiten das Verständnis für die Bedürfnisse der
verschiedenen Entwicklungsprojektbestandteile.
Die Probleme der interdisziplinären Zusammenarbeit von Mitarbeitern spiegeln sich aber auch
in der fehlenden Integration der verwendeten Entwicklungswerkzeuge wieder. So gibt es in
den einzelnen Disziplinen of gute Werkzeuge, die etwa den Schaltungsentwurf und das Platinenlayout
unterstützen. Diese Werkzeuge sind dann aber beispielsweise nicht mit dem CAD-
Tool für den mechanischen Bauplan und auch nicht mit der Programmierumgebung für eine
SPS-Steuerung integriert. Wird nun zum Beispiel ein Sensor zur Überprüfung des Verschlusses
einer großen Klappe aus Stabilitätsgründen verdoppelt, so muß dies natürlich im Schaltungsentwurf
und eventuell auch in der Steuerungssoftware berücksichtigt werden. In der reinen
Softwareentwicklung würde ein Compiler solche Inkonsistenzen zwischen verschiedenen Projektteilen
mit hoher Zuverlässigkeit entdecken und melden. Im interdisziplinären Bereich fehlen
solche Konsistenzüberprüfungswerkzeuge. Dies führt oft zu Fehlern wie zum Beispiel,
dass ein SPS-Entwickler zwar den aktuellen Schaltplan vorliegen hat, er aber nicht bemerkt,
daß sich ein bestimmtes Eingangssignal geändert hat, dessen Verarbeitung in der SPS-Steuerung
er schon vor einigen Wochen programmiert hat. Dies wird dann wieder als “Verständigungsproblem
zwischen den Disziplinen” sichtbar.
Bei der Bewertung dieser Ergebnisse ist jedoch zu berücksichtigen, daß nur in wenigen Unternehmen
Informatiker an der System- und Softwareentwicklung beteiligt sind; im Regelfall
sind die „traditionellen“ Disziplinen Maschinenbau und Elektrotechnik an der Entwicklung
beteiligt. Dies relativiert die Tatsache, daß in vielen Unternehmen keine Probleme hinsichtlich
der interdisziplinären Zusammenarbeit festgestellt werden. In den wenigen Fällen, in denen
Informatiker in Unternehmen mit gleichem oder stärkerem Anteil der Hardware am Produkt
gegenüber der Software eingesetzt wurden, wurde durchaus auf die mehr naturwissenschaftliche
als ingenieurmäßige Denkweise der Informatiker hingewiesen.
Die Analyse der Schnittstellen, die der softwareentwicklende Unternehmensbestandteil mit
anderen Bereichen hat, zeigt, daß eine Zusammenarbeit mit Vertrieb, Marketing und Produktplanung
in den meisten Unternehmen vorkommt. Über die Häufigkeit der Zusammenarbeit
wurden keine Werte ermittelt. Aus Einzelaussagen läßt sich jedoch herausfiltern, daß gerade
die Kommunikation mit dem Vertrieb und den betriebswirtschaftlichen Bereichen schwierig
und unzureichend ist. Ursache ist mangelndes Wissen über die Eigenschaften von Software, da
das Management sich meist aus anderen Disziplinen und älteren Ausbildungssemestern rekrutiert
(Betriebswirtschaftler, Feinwerktechniker usw.), in deren Vorstellung beispielsweise
Anlagen noch immer nur aus Hardware bestehen und die Software lediglich ein Zubehör, aber
kein integraler Bestandteil ist. Aus diesem Grunde ist vielfach die Kommunikation der Kom-
12 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

plexität nicht möglich, besonders in den frühen Phasen der Anforderung und ganz besonders,
wenn es sich um neue Aufgabenstellungen handelt.
Probleme
Wie bereits im obigen Abschnitt erläutert, ergeben sich die Hauptprobleme der interdisziplinären
Zusammenarbeit vor allem bei größeren Projektteams gerade dann, wenn Vertreter unterschiedlicher
Disziplinen unregelmäßig und selten miteinander kommunizieren. Innerhalb der
Ingenieurdisziplinen lassen sich diese Probleme bei regelmäßiger Kommunikation offensichtlich
leicht überwinden. Für eine praktische Lösung dieses Sachverhalts wäre zu überprüfen, ab
welcher kritischen Entwickleranzahl die Probleme bei der Zusammenarbeit zunehmen.
Schwierigkeiten wurden vor allem bei räumlich verteilt arbeiten Entwicklungsteams genannt,
die in international besetzten Gruppen durch Mentalitätsunterschiede noch verstärkt werden.
Diese Problematik ist aber nicht orginär Arbeitsgruppen bei der Softwareentwicklung zuzuordnen,
sondern wäre in anderen global agierenden Arbeitsteams ebenfalls zu erwarten.
Gerade in der Softwareentwicklung sind starke Nachwuchsprobleme zu verspüren. Somit
wurde aufgrund mangelnder Erfahrungen ein Defizit im Bereich Projektmanagement deutlich.
Gerade im universitären Bereich werden den zukünftigen Entwicklern kaum organisatorische
Fähigkeiten und Methoden vermittelt. Insgesamt vermissen die Unternehmen bei den Berufsanfängern
Wissen über organisatorische Zusammenhänge in einem Unternehmen und Erfahrungen
in Teamarbeit.
Handlungsbedarf
Folgender Handlungsbedarf wird von den Unternehmen selbst angegeben:
• Ein einheitliches Produktmodell für eingebettete Systeme entwickeln, das die Anforderungen
aller beteiligten Disziplinen (Mechanik, Elektrik, Elektronik, Informatik) berücksichtigt.
• Es fehlen gut ausgebildete Informatiker und Entwickler. Hier müssen von den Universitäten,
Schulen und Ausbildungsbetrieben mehr Anreize gesetzt werden, um ausreichend
Schulabgänger für diese Berufe zu interessieren.
• Mitarbeiter sollten in Informationsbeschaffungstechniken geschult werden, Einzelkämpfertum
ist zu vermeiden.
• Die Schnittstellen zu Marketing, Vertrieb und Management könnten verbessert werden und
die Mitarbeiter in diesen Organisationseinheiten mehr für die spezifische Probleme von
Software sensibilisiert werden.
• Es müssen Fähigkeiten vermittelt werden, die den Kundenkontakt verbessern.
• Forschungsprojekte sollten auch für den Mittelstand bezahlbar sein, dadurch wird der Kontakt
zu den Universitäten verbessert.
• Dem Studiengang Ingenieur-Informatik gleiches Gewicht geben wie Wirtschaftsinformatik.
• Weiterbildungsmaßnahmen für Autodidakten verbessern.
• Schulung in der Anwendung von Prozeßhandbüchern, stärker ingenieurmäßige Softwareentwicklung
fördern, mehr Erfahrungen im Projektmanagement vermitteln.
• Während der Ausbildung mehr Teamarbeit fördern und die Einbindung von Studenten in
Projekte unterstützen (Erfahrungszuwachs).
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 13

• Es sollten mehr integrierte Studiengänge angeboten werden (Ingenieur-, Informatik- und
Wirtschaftswissenschaften).
• In der Informatikerausbildung sollte explizit auf eingebettete Systeme eingegangen werden.
3.3.2 Vorgehensmodell
Ist-Stand
Die Softwareabteilungen der befragten Unternehmen sind, soweit als eigenständige Abteilung
überhaupt vorhanden, im Regelfall durch Anwachsen aus der Elektrik-Abteilung entstanden.
Dieses natürliche Wachstum führte insbesondere bei den von den Unternehmen eingesetzten
Vorgehensmodellen zu einigen Besonderheiten gegenüber „klassischen” Softwarehäusern.
Bei den meisten Unternehmen (ca. 75%) findet sich ein phasenorientiertes Vorgehen, das aus
den Hauptphasen
• Anforderungsanalyse mit Erstellung der Anforderungsdokumente (Lastenheft, Pflichtenheft),
• Design mit Erstellung der Systemarchitektur und der Systemkomponenten oder des funktionalen
Aufbaus des Systems, teilweise unterschieden in Grob- und Feindesign,
• Implementierung oder Umsetzung des Systems in Form von Hardware und Software (C-,
C++-, SPS-Code etc),
• Qualitätssicherung und Test (Modultest, Integrationstest, Inbetriebnahmetest, Systemabnahmetest)
und
• Systembetrieb mit Service und Wartung (Fehlerbehebung, Einspielen neuer SW-Versionen)
besteht. Dabei sind nicht immer alle Phasen vorhanden; insbesondere die Designphase existitiert
nicht in allen Unternehmen in Form einer eigenständige Phase. Auch sind die einzelnen
Phasen und damit das gesamte Vorgehensmodell unterschiedlich stark ausgeprägt. Dabei liegt
das Gewicht inbesondere auf den späten Entwicklungsphasen, vor allem der Implementierung
sowie der Qualitätssicherung in Form von Tests.
Im allgemeinen wird zur Entwicklung ein wasserfallartiges oder “top-down”-orientiertes Verfahren
verwendet. Nur wenige der Befragten benutzen allgemeinere Formen wie eine V-
Modell-artige Vorgehensweise oder zyklische (“software life cycle”) Modelle1 . Dabei sind die
eingesetzten Vorgehensmodelle unterschiedlich präzise definiert und meist nur bei größeren
Unternehmen ausführlich vorgeschrieben, beispielsweise in Form eines Prozeßhandbuchs.
Diese Vorgehenshandbücher sind im Regelfall firmenspezifisch und nach hauseigenem Standard
vom Qualitätsmanagement entwickelt. Nur in wenigen Unternehmen wird ein standardisiertes
Vorgehensmodell wie das V-Modell mit den damit verbundenen Dokumenten
eingesetzt.
Der geringe Einsatz standardisierter Techniken gilt auch für den Bereich der Spezifikation.
Generell werden zur Beschreibung des Softwareanteils eines Systems kaum Beschreibungstechniken,
wenn überhaupt meist unsystematisch, eingesetzt. Im Gegensatz dazu geschieht
dies im Bereich der Systemhardware beispielsweise mit Konstruktionsplänen, Schaltplänen
1. Dabei ist zu beachten, daß zyklische Modelle für bestimmte Unternehmen, z.B. im Bereich der Herstellung
von Bauelementen für die Automatisierung, nur bedingt einsetzbar sind, da eine wiederholte prototypische
Realisierung des Produkts erhebliche Kosten verursachen kann.
14 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

1
Güte
Anzahl
Unternehmen
3
1
18
16
14
12
10
8
6
4
2
0
1 2 3
Definition Vorgehensmodell
Definition Vorgehensmodell
1 - alle Phasen, klar getrennt
2 - alle Phasen, grobe Trennung
3 - einige Phasen, kaum Trennung
Abbildung 2. Vollständigkeit und Definition des Vorgehensmodells
5
6
2
1
2
1
7
5
SW höher SW/HW
gleich
1
4
1
3
HW etwas
höher
HW höher
und anderen technischen Dokumenten durchwegs systematisch und mehr oder weniger vollständig.
Ein umfassender, für Hardware und Softwareaspekte geeigneter und standardisierter
Satz von Beschreibungsformen ist nach dem heutigen Stand der Technik noch nicht gegeben.
Während die Verwendung (unternehmensübergreifender) standardisierter modularer Architekturen
und Systembausteine (Feldbus, Ethernet, SPS, Sensoren) im Hardwarebereich Stand der
Technik ist, wird auf der Softwareseite auch im Bereich der eingebetteten Systeme eine konsequente
bausteinorientierte Entwicklung mittels Standardarchitekturen noch nicht eingesetzt.
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 15
1
2
1
0
5
4
3
7
6
Anzahl
Unternehmen
Abbildung 3. Güte der eingesetzten Vorgehensmodelle
Güte Vorgehensmodell
1 - standardisiertes V.
2 - eigenes, vollständiges V.
3 - eigenes, partielles V.
4 - Vorgaben für Dokumente
5 - kaum Vorgaben
6 - kein Vorgehensmodell

Wiederverwendung findet in vielen Unternehmen oft nur unsystematisch oder nur in Form von
Codewiederverwendung statt.
Die Bedeutung der Software für eingebettete Systeme in den Themenbereichen der Vordringlichen
Aktion wird von den Unternehmen generell hoch bewertet. Trotzdem erfolgt nicht in
allen Systemen die Entwicklung von Hardware und Software immer ausreichend abgestimmt.
Dies ist besonders dann der Fall, wenn die frühen Phasen der Systementwicklung ohne Mitwirkung
und Berücksichtigung der Softwareabteilungen erfolgen. Dies ist jedoch bei den befragten
Unternehmen nicht die Regel.
Zusammenfassung Ist-Zustand
• Hauptsächlich Einsatz unterschiedlich stark ausgeprägter Wasserfallmodelle
• Wenig Einsatz abstrakter und präziser Beschreibungformen für (Software)Funktionalität
• Kein systematischer Einsatz von Standardarchitekturen und Bausteinen auf Softwareebene
• Nicht immer ausreichende Abstimmung zwischen Software- und Hardwareentwicklung
Probleme
Ein wesentliches Manko eines nicht ausreichend definierten Vorgehensmodells liegt in der
Planbarkeit und Prognostizierbarkeit von Produktentwicklungen. Ist das Vorgehensmodell entsprechend
vorgeschrieben (unter Berücksichtigung des Umfelds, des Unternehmens sowie der
Projektgröße), ist eine realistischere Beurteilung des Stands des laufenden Projekts möglich.
Weiterhin kann so eine gleichbleibende Qualität bei der Durchführung der Projekte sichergestellt
und Aufwandsabschätzungen auf Folgeprojekte übertragen werden. Schließlich vereinfacht
die gezielte Abwicklung eines Projekts mit definierten Schritten und Ergebnissen die
Wiederverwendung von gewonnenem KnowHow oder sogar direkt von Projektergebnissen.
Ohne ein solches standardisiertes Vorgehen sind die Projektverfolgung, Sicherung des Unternehmensstandards
sowie die Übertragung von Ergebnissen wesentlich schwieriger. Gleichzeitig
dient ein standardisiertes Vorgehen als unternehmensübergreifendes Qualitätsmerkmal.
Dies ist unter anderem für die Unterauftragsvergabe von großer Bedeutung.
Das in Abschnitt 3.3.7 beschriebene Fehlen geeigneter Techniken zur Beschreibung der
Gesamtfunktionalität des System und der SW-Anteile wirkt sich auch auf die Wiederverwendung
von Entwicklungsdokumenten aus. Gerade im Bereich der eingebetteten Systeme, vor
allem bei der Prozeßautomatisierung und im Anlagenbau, spielt oftmals die Erstellung einer
breiten Palette von Produktvarianten eine große Rolle. Wiederverwendung wird aber im
Regelfall nur auf der Implementierungsebene durch “Code-Recycling” in großem Umfang
betrieben (siehe Abbildung 4). Nur wenige Unternehmen machen von der Möglichkeit
Gebrauch, Entwicklungs-KnowHow in Form von System- oder Prozeßbeschreibungen aus
Pflichtenheften oder Designdokumenten systematisch für die Erstellung neuer Produktvarianten
einzusetzen.
Eine wesentliche Rolle bei der Wiederverwendung spielt dabei der Einsatz von Standardarchitekturen.
In der HW ist die Verwendung von standardisierten Komponenten wie beispielsweise
SPS und deren Integration in standardisierte Architekturen bestehend aus Stationen, Bussystem
und Prozeß/Leitrechner gängige Verfahrensweise. Auf der SW-Seite kommt ein solcher
Ansatz nicht konsequent zum Einsatz.
Auch die Kombination von SW- und HW-Anteilen zu flexiblen Bausteinen wird nur in Ausnahmefällen
konsequent praktiziert. Hierzu gehört die Gruppierung von HW und SW zu Sys-
16 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

Anzahl
Unternehmen
16
14
12
10
8
6
4
2
0
1 2 3
Grad Wiederverwendung
temmodulen, die unter Verwendung einheitlicher Kommunikationsschnittstellen (Fehler-,
Status- und Steuersignale) definiert werden. Solche Module können dann nach entsprechender
Parametrierung zusammen mit der stationsübergreifenden Anlagensteuerung zu einer kompletten
Anlage konfiguriert werden.
Zusammenfassung Probleme
• Fehlen geeigneter standardisierter Vorgehensmodelle
• Aufwendungen (Kosten, Personalressourcen, Zeit etc.) für Projekte besonders bei stark
individueller Systemfunktionalität oft nicht ausreichend prognostizierbar bzw. planbar
• Fehlen geeigneter, ingenieurmäßig einsetzbarer und standardisierter Beschreibungstechniken
• Kaum Einsatz von Bausteinen (Software oder kombinierte Hardware/Software-Module)
• Kaum Einsatz von (unternehmensübergreifenden) Software- bzw. System-Standardarchitekturen
• Späte Berücksichtigung der Software-Anforderungen
Handlungsbedarf aus Sicht der Unternehmen
Grad Wiederverwendung
1 - hoch: durchgägngig
2 - mittel: isoliert, aufwendig
3 - niedrig: vereinzelt
Abbildung 4. Umfang der Wiederverwendung im Entwicklungsprozeß
Von vielen Unternehmen wird eine auf das Zielgebiet der eingebetteten Systeme zugeschnittene
und standardisierte Vorgehensweise vermißt. Bei existierenden Ansätzen wird dabei
besonders die mangelnde Berücksichtigung der Besonderheiten des Anwendungsgebietes (beispielsweise
die gleichzeitige Entwicklung von HW und SW, die Verwendung standardisierter
(HW-)Bausteine, fehlende Orientierung an vorhandenen Vorgaben aus Maschinenbau oder E-
Technik etc.) beklagt. Auch die Unhandlichkeit der Vorgehensmodelle, vor allem beim Einsatz
für kleinere Projekte im Umfang von einigen Personenmonaten wurde kritisiert. Eine einfache
(vorzugsweise automatische) Anpassung des Vorgehensmodells (“tailoring”) an den Projekt-
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 17

umfang ist eine wesentliche Voraussetzung für die Akzeptanz bei kleinen und mittleren Unternehmen.
Auch im Bereich der Beschreibungsformen, einschließlich Dokumentvorgaben (Lastenheft
bzw. Anforderungedefinition, Pflichtenheft bzw. Systemspezifikation), Beschreibungstechniken
(Architektur- und Verhaltensbeschreibungen) wird die Definition von unternehmensübergreifenden
und zertifizierten Standards im Bereich Anlagenbau und Produktions- und
Automatisierungstechnik vermißt.
Schließlich werden Studien und Belege für den effektiven Nutzen einer systematischen und
ausführlichen Vorgehensweise vermißt bzw. die Information über die Verfügbarkeit solcher
Berichte.
Vielfach wird darüberhinaus kritisiert, daß sich das systematische und ingenieurmäßige Arbeiten
mit Software noch nicht ausreichend durchgesetzt hat. Dies wird sowohl im Bereich der
Ingenieurdisziplinen als auch im Bereich der Informatik als Defizit wahrgenommen.
Zusammenfassung Handlungsbedarf
• Fehlen eines speziellen Vorgehensmodells für eingebettete Systeme mit Tailoringmöglichkeit
• Definition unternehmenübergreifender, standardisierter Beschreibungsformen
• Ausbildungsmöglichkeiten für die ingenieurmäßige Entwicklung von Software für eingebettete
Systeme
3.3.3 Anforderungsanalyse
Ist-Stand
Wie in Abbildung 5 dargestellt ist allgemein bei jedem Unternehmen, unabhängig davon ob
Anzahl
Unternehmen
14
12
10
8
6
4
2
0
1 2 3
Güte Analysephase
5 6
Abbildung 5. Güte der Analysephase
Güte Analysephase
1 - Standardisierte Analyse
2 - Eigene, vollständige Analyse
3 - grobe Vorgabe, Pflichtenheft
4 - keine Vorgabe, Pflichtenheft
5 - Analyse ohne Vorgabe
6 - Keine Analyse
ein definiertes Vorgehensmodell vorhanden ist oder nicht, eine Analysephase in der prakti-
18 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

schen Projektdurchführung vorgesehen; generell ist die Bedeutung dieser Phase anerkannt und
damit ein entsprechendes Vorgehen definiert. Bei über 80% der befragten Unternehmen ist die
Erstellung eines Pflichtenhefts vorgesehen sowie die Vorgaben für die Durchführung der Analyse
oder die Erstellung des Pflichtenhefts vorhanden. Dabei unterscheiden sich jedoch die in
der Analysephase vorgeschriebenen Aktionen wesentlich. Nur bei ca. 50% liegen genaue Vorgaben
zur Durchführung der Analyse vor, einschließlich der Einplanung von Reviews.
Auch die Vorgaben der zu verwendenden Beschreibungsformen und damit der zu erstellenden
Informationen sind stark unterschiedlich (siehe auch Abschnitt 3.3.9). Dies wird besonders bei
den erstellten Lasten- und Pflichtenheften deutlich. Während diese im Regelfall vollständige
Stücklisten der verwendeten Hardware, Hardwarearchitekturpläne oder Schaltpläne enthalten,
ist in vielen Fällen keine Beschreibung des zu realisierenden Systemverhaltens vorhanden. Insbesondere
werden hier keine Beschreibungsformen verwendet, die beispielsweise ein weitgehend
automatisches oder zumindest systematisches Ableiten von Testfällen erlauben.
Die Erstellung eines Lastenhefts ist nicht in allen Fällen vorgesehen (und auch nicht in allen
Fällen vollständig möglich, beispielsweise bei innovationsgetriebenen Prozessen). Auch in den
Fällen, in denen ein Lastenheft als Vertragsgrundlage eingesetzt wird, erfolgt die Erstellung
des Lastenhefts im Regelfall noch nicht systematisch, beispielsweise unter Verwendung von
vorgegebenen Vorlagen oder durch Auswahl der Kundenwünsche aus einem, vom Unternehmen
definierten Katalog von Leistungsmerkmalen. Eine systematische Priorisierung von Kundenwünschen
wird nur in Ausnahmefällen vorgenommen und dargestellt.
Wie bereits erwähnt, ist die Erstellung eines Pflichtenhefts in über 80% der befragten Unternehmen
vorgesehen. Bezüglich der verwendeten Beschreibungsformen sowie der Vollständigkeit
der beschriebenen Information gilt prinzipiell ähnliches wie im Fall des Lastenhefts. Auch
in den Fällen, in denen ein Lastenheft oder vergleichbares Dokument vorgesehen ist, wird das
Pflichtenheft nur in Ausnahmefällen systematisch daraus abgeleitet. Eine Möglichkeit der
Rückverfolgung von Anforderungen aus dem Pflichtenheft zu Anforderungen aus dem Lastenheft
ist generell nicht gegeben. Für die Erstellung des Pflichtenhefts sind jedoch in vielen Fällen
Vorlagen (in Form auszufüllender strukturierter Dokumente) vorhanden, in einigen Fällen
wird die Pflichtenhefterstellung mittels Verwendung von Pflichtenheften aus vorherigen Projekten
betrieben. Ein Pflichtenheft mit einer vollständigen, gemeinsamen Beschreibung des
Systems aus Hardware- und Softwaresicht, gemeinschaftlich erstellt von den beteiligten Parteien
(Mechanik, Elektrik, Software, Qualitätssicherung) ist nur in Ausnahmefällen vorhanden.
Zusammenfassung Ist-Stand
• Erstellung von Pflichtenheften, teilweise keine strukturierte Vorgehensweise
• Gelegentlich Erstellung von Lastenheften, umfaßt oft nur Hardware
• Kaum präzise Beschreibung der Software- bzw. Systemfunktionalität
• Erstellung der Analysedokumente oft nicht übergreifend über HW, SW, QS
Probleme
Die im vorherigen Abschnitt beschriebene Erstellung unpräziser oder unvollständiger (Software-)Entwicklungsdokumente
führt zu einer Reihe von potentiellen Problemen
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 19

• Werden die Anforderungen an die Funktionalität des Systems (insbesondere an sein Verhalten)
nur unvollständig beschrieben, so ist diese Beschreibung im allgemeinen kaum als Vertragsgrundlage
geeignet. Dies gilt insbesondere im Fall eines unvollständigen Lastenheftes
für das Unternehmen, sowohl als Systemverkäufer als auch als Käufer, beispielsweise von
Softwaremodulen.
• Analysedokumente stellen in der Qualitätssicherungsphase die Grundlage für Planung und
Vorbereitung der Tests (Integrationstest, Abnahmetest) dar. Wird die Funktionalität des Systems
nicht oder nur unvollständig erfaßt, so ist beispielsweise das Pflichtenheft nicht als
Grundlage für eine systematische Qualitätssicherung geeignet. Inbesondere ist eine automatische
Ableitung von Testfällen nicht möglich.
• Die Verwendung unpräziser Entwicklungsdokumente erschwert deren Reviewprozeß: sie
sind dann nur schwer auf Richtigkeit und Vollständigkeit überprüfbar.
Die Erstellung von Lasten- und Pflichtenheften ist ein aufwendiger Prozeß, der besonders in
bedarfsorientierten Feldern wie dem Maschinen- und Anlagenbau, vom Kunden oft nicht als
gewinnbringende und damit zu vergütende Leistung angesehen wird. Daher ist es notwendig,
gerade im variantenorientierten Prozeß des Maschinen- und Anlagenbaus Anforderungsdokumente
so systematisch wie möglich zu erstellen. Falls keine ensprechenden Kataloge von Kundenwünschen
und damit gekoppelte Systemanforderungen vorhanden sind, wird eine
ausführliche Erstellung von Lasten- und Pflichtenheften vielfach zu kosten- und zeitintensiv
sein und damit gerade bei Standardlösungen nicht stattfinden. Entsprechend wichtig ist daher
auch die systematische Ableitung von Systemanforderungen im Pflichtenheft aus den Kundenanforderungen
im Lastenheft.
Zusammenfassung Probleme
• Unvollständige Beschreibung der Anforderungen an den Softwareanteil beziehungsweise
an das Verhalten des Systems und damit
+ fehlende Vertragsgrundlage/Lastenheft
+ schlechte Eignung für Ableitung von QS-Maßnahmen
+ schwer auf Vollständigkeit/Korrektheit überprüfbar
• Fehlende Systematik in der Erstellung eines Lastenhefts sowie der Ableitung eines Pflichtenhefts
• Geringer Einsatz von Wiederverwendung in der Analysephase
Handlungsbedarf aus Sicht der Unternehmen
Besonders im Bereich Anlagenbau wird die Anforderung erhoben, daß das Lastenheft zum
Schutz des Technologievorsprungs keine Designinformation und damit Know-How für den
Kunden leicht verfügbar dokumentiert enthalten soll. Anderenfalls besteht die Gefahr, daß die
im Lastenheft offengelegte Designinformation vom Kunden in Verbindung mit einem anderen
Anbieter genutzt wird. Ein Lastenheft muß daher ausreichend abstrakt sein.
Da weiterhin gerade im Bereich Anlagenbau vom Kunden die System- bzw. Softwarefunktionalität
als „Zusatz“ zur technischen Anlage (Hardware) gesehen wird, werden Kosten für die
Erstellung eines Lasten- bzw. Pflichtenheft auf Kundenseite oft nicht akzeptiert. Daher ist es
notwendig, die Kosten insbesondere für die Erstellung des Lastenheftes zu verringern oder
Rentabilität auch für den Kunden sichtbar zu machen.
20 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

Gelegentlich findet sich in den Systemanforderungen (Pflichtenheft) einer Anlage eine
Beschreibung des Gesamtprozesses, aus dem die möglichen Anlagenzustände, Fehlersitutationen
und Benutzereingriffe bereits hervorgehen. Eine Generierung von Benutzungsoberflächen
aus der Beschreibung des Prozesses wird daher als wünschenswert angesehen.
Zusammenfassung Handlungsbedarf
• Abstrakte Beschreibungsformen für die Darstellung von Systemanforderungen
• Rentabilität der Lastenheft/Pflichtenheft-Erstellung verbessern
• Generierung von Benutzerschnittstellen aus Systemanforderungen
3.3.4 Design
Ist-Stand
Wie bereits in Abschnitt 3.3.2 erwähnt, liegt der Schwerpunkt der Softwareentwicklung besonders
auf den späteren Phasen, also der Implementierung, dem Testen, der Installation und dem
Service. Ähnlich wie im Fall der Analysephase - mit mehr oder weniger ausgeprägten Vorgaben
einschließlich eines Pflichtenhefts - existiert prinzipiell auch eine eigenständige Designphase
(siehe Abbildung 6). Diese ist aber im Regelfall noch etwas schwächer ausprägt als die
Analysephase: nur ca. 60% der Befragten legen im Design den Systemaufbau einschließlich
funktionaler Anforderungen an die Systemkomponenten - mehr oder weniger vollständig - in
Form des Feindesigns fest.
Anzahl
Unternehmen
14
12
10
8
6
4
2
0
1 2 3 4 5 6
Güte Designphase
Abbildung 6. Güte der Designphase
Güte Designphase
1 - Integriertes Design
2 - vollständiges, nichtint. Design
3 - Grobdesign, ansatzw. Feindesign
4 - Nur Grobdesign
5 - Ansatzweises Grobdesign
6 - Keine Designphase
Dabei ist das Design nur in Ausnahmefällen (unter 20%) vollständig in den Entwicklungsprozeß
integriert, beispielsweise durch systematische Ableitung aus dem Pflichtenheft mit Möglichkeiten
zur Rückverfolgung zu diesem. Wird ein eigenes Designdokument erstellt, so wird
dieses in vielen Fällen durch Fortschreiben des Pflichtenhefts vorgenommen. Wird ein Feindesign
erstellt, so wird dazu die im Grobdesign gewonnene Struktur genutzt und weiterentwi-
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 21

ckelt. Da der Softwareanteil von vielen der entwickelten Systeme, besonders im Bereich
Produktions- und Automatisierungstechnik sowie im Anlagen- und Maschinenbau, von einem
Entwickler bewältigt werden kann, findet eine gleichzeitige Weiterentwicklung einzelner
Module durch unabhängige Entwickler entsprechend dem Grobdesign nur in Ausnahmefällen
statt.
Wie auch bei den bisher beschriebenen Entwicklungsdokumenten wird in den Designdokumenten
der softwaretechnische Anteil im allgemeinen nur unvollständig, unpräzise abstrakt
(d.h. ohne Implementierungsinformation) beschrieben. Eine genaue Beschreibung der Funktionalität
(des Verhaltens) der Softwarekomponenten wird, wie in Abschnitt 3.3.9 beschrieben,
nur in Ausnahmefällen erstellt.
Ein systematischer Einsatz von Bausteinen oder Modulen findet nur in wenigen Fällen statt
(ca. 25%, siehe Abschnitt 3.3.2). Inbesondere wird in der Designphase kaum systematisch die
Vorbereitung für Wiederverwendung betrieben: zwar wird in vielen Fällen beim Grobdesign
auf die Verwendung von Standardarchitekturen bzw. Architekturen vergleichbarer Projekte
zurückgegriffen; ein Feindesign mit gezielter Identifikation und Konstruktion von wiederverwendbaren
Bausteinen ist jedoch eher selten. Ein konsequent bausteinorientiertes Design
durch Zusammenfügen und Parametrieren von Software- und Hardwarebausteinen unter Verwendung
einer einheitlichen, projektunabhängigen und flexiblen Standardarchitektur bleibt die
Ausnahme. Ebenso kommen nur in Ausnahmefällen Entwurfsmuster („Design-Pattern“) zum
Einsatz. Hierbei ist zu beachten, daß eine Wiederverwendung von Ergebnissen, je nach Klassifikation
des Unternehmens, aufgrund der geringen Variantenbreite oft nur zum Teil sinnvoll
oder möglich ist.
Die Generierung von ausführbaren und somit testbaren Prototypen des Systems oder des Softwareanteils
des Systems wird nur in wenigen Fällen eingesetzt. Eine systematische Simulation
während der Designphase zur Überprüfung von Designentscheidungen findet nicht statt. Zur
Qualitätssicherung werden im Design in erster Linie Reviewtechniken eingesetzt. Im Design
getroffene Entwurfsentscheidungen werden selten dokumentiert und stehen daher bei vergleichbaren
Entwicklungen nicht zur Verfügung.
Zusammenfassung Ist-Stand
• Designphase im Regelfall nicht integriert
• Design oft nur Systemstruktur/Systemgrobarchitektur (Grobdesign)
• Designdokumente beschreiben Software oft nur unzureichend
• Strukturierte Wiederverwendung auf Designebene, Einsatz von Entwurfsmustern und Bausteineinsatz
eher selten eingesetzt
• Wiederverwendung im allgemeinen auf Systemarchitektur beschränkt
• Generierung und Prototyping wenig eingesetzt
Probleme
Wie bereits bei der Anforderungsanalyse hat der Einsatz unvollständiger oder unpräziser Entwicklungsdokumente
auch Auswirkungen auf die Designphase:
22 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

• Eine Überprüfung der in der Designphase erstellten Dokumente auf ihre Konsistenz (d.h.
das Zusammenpassen, beispielsweise von Schnittstellen, Nachrichten, etc.) ist nur schwer
durchführbar. Insbesondere ist eine automatische Überprüfung der Dokumente nicht möglich.
• Eine Generierung von weiteren Entwicklungsergebnissen aus den Designdokumenten ist im
allgemeinen nicht möglich. Beispielsweise läßt sich während des Designs keine Simulation
der Software oder des Gesamtsystems erstellen und so das Design überprüfen. Auch die
Generierung von Code aus den Designdokumenten ist damit nicht möglich. 1
• Wie bereits im Fall der Anforderungsanalyse lassen sich aus solchen Beschreibungen nur
schwer systematisch Testfälle für den Modultest des Systems gewinnen. Eine automatische
Ableitung von Testfällen ist bei unpräzisen Dokumenten nicht möglich.
In den Bereichen eingebetteter Systeme, die durch eine große Anzahl von Varianten eines Produkts
geprägt sind, führt die Verwendung von Standardarchitekturen und Systembausteinen zu
einer wesentlichen Effizienzsteigerung im Entwicklungsprozeß.
Zusammenfassung Probleme
• Fehlende Systematik bei der Herleitung des Designs aus den Analysedokumenten (Pflichtenheft)
• Fehlender Einsatz präziser Beschreibungsformen
+ Keine Mechanismen zur Überprüfung der Korrektheit des Design (Konsistenz)
+ Kaum Einsatz von Generierung (Simulation, Prototypen)
+ Kaum Ableitung von QS-Eingaben (Testfälle)
• Keine Möglichkeit der Rückverfolgung von den Designdokumenten zum Pflichtenheft
• Kaum systematische Verwendung von Bausteinen (Identifikation, Definition, Einsatz)
Handlungsbedarf aus Sicht der Unternehmen
Generell wurde in allen in Abschnitt 3.2 beschriebenen Klassen von Unternehmen festgestellt,
daß die Definition unternehmensübergreifender Standardarchitekturen für einzelne Produktbereiche
aus dem Themenfeld der Vordringlichen Aktion notwendig ist. Dies wurde besonders
im Bereich des Maschinen- und Anlagenbaus mehrfach betont.
In diesem Zusammenhang wurde auch auf die Notwendigkeit der Erstellung von Designvorschriften
für diese Produktbereiche aus dem Themenfeld der Vordringlichen Aktion festgestellt.
Generell in der Entwicklung, aber besonders im Design, werden ausgereifte und stabile Designwerkzeuge
vermißt: dabei vor allem solche, die die besonderen Anforderungen der eingebetteten
Systeme sowie die Definition und Anwendung von Bausteinen berücksichtigen.
Das bereits für das ganze Vorgehen festgestellte Defizit hinsichtlich des systematischen und
ingenieurmäßigen Entwickelns von Software für eingebettete System wurde vor allem in der
Designphase als Problem genannt.
1. In diesem Zusammenhang wurde allerdings ebenfalls die mangelhafte Qualität des generierten Codes kommerzieller
Werkzeughersteller seitens der Befragten bemängelt.
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 23

Zusammenfassung Handlungsbedarf
• Definition von unternehmensübergreifenden Standardarchitekturen für einzelne Produktbereiche
• Erstellung von Designvorschriften für einzelne Produktbereiche
• Ausgereifte und stabile Designwerkzeuge
• Schulung des systematischen und ingenieurmäßigen Designs
3.3.5 Implementierung
Die Implementierung stellt den Abschnitt dar, in dem das Produkt »Software« zum ersten Mal
greifbar und sichtbar wird. Daher ist sie auch genau die Phase, die bei allen Unternehmen
zwingend mehr oder weniger gut strukturiert vorgefunden wurde. Von der klassischen Implementierung
wie sie schon seit Jahren »State of the Art« ist, hat sich im Basisvorgehen nichts
Wesentliches verändert. Ein Editor dient zum Eingeben von Instruktionen, ein Compiler übersetzt
diese in für die CPU verständliche Maschinenbefehle und ein Simulator der eingesetzten
Architektur dient zur Verifikation der programmierten Zeilen.
Die Entwicklung in den letzten Jahren hat in dieser Phase eine Vielzahl neuer Werkzeuge und
auch Erweiterungen eingeführt, welche die Bedienung der obengenannten Implementierungsabschnitte
verbessert haben. Somit ist man heutzutage in der Lage, komplexe und große Softwareimplementierungen
durchzuführen und zu verwalten.
Aber gerade die steigende Komplexität und das Eindringen in die hardwaredominierten Bereiche
haben die Randbedingungen und Voraussetzungen für erfolgreiche Implementierungen
verändert. Heutzutage ist eine gut strukturierte und organisierte Implementierungsphase lediglich
notwendige aber nicht hinreichende Bedingung für erfolgreiche Softwareimplementierungen.
Vielmehr verlagern sich Konzeptions- und Desingüberlegungen, die früher durchaus Teil
der Implementierungsphase waren, in eigenständige vorgelagerte Phasen.
Insofern ist die Implementierungsphase, wie keine andere, sehr stark abhängig von der »Qualität«
der Vorarbeit, die in den vorhergehenden Phasen geleistet wurde.
Im folgenden Abschnitt soll der Ist-Stand der befragten Unternehmen dargestellt werden, die
zur Implementierung und deren Anbindung an angrenzende Phasen des Softwareentwicklungsprozesses
befragt wurden.
Ist-Stand Implementierung
Alle befragten Unternehmen setzen Standardwerkzeuge zum Schreiben, Editieren, Compilieren
und Debuggen sowohl von Hochsprachen als auch Assemblercode ein. Die Anwendung
dieser Werkzeuge stellt in der Regel keine größeren Probleme dar, die nicht mit angemessenem
Aufwand zu lösen wären. Dies ist auch nicht weiter verwunderlich, da Produkte aus dieser
Phase in allen Bereichen der Software Entwicklung zur Produktion von Software eingesetzt
werden und somit einen gewissen Reifegrad besitzen.
Die Implementierung erfolgt in fast allen Unternehmen nach hauseigenen, beziehungsweise
standardisierten Programmierrichtlinien. Auch diese Methoden haben sich aus der klassischen
Softwaretechnik durchgesetzt und dienen der Handhabbarkeit und Lesbarkeit von Quellcode.
Ein weiterer Punkt, der sich ebenfalls aus der Entwicklung von Software im allgemeinen
ergibt, ist die Wiederverwendung von Implementierungsprodukten auf Codeebene, die in über
der Hälfte der befragten Unternehmen betrieben wird. Dabei reicht das Spektrum von der Nut-
24 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

zung von eigenen bzw. Standard Klassenbibliotheken über GUI (Graphical User Interface)
Bibliotheksbausteine bis hin zu SPS-Code Modulen.
Dieser Anteil wiederverwendbarer Implementierungsprodukte ergibt sich aus der Heterogenität
der Tätigkeitsfelder der einzelnen Unternehmen. Unternehmen, die stark heterogene Projekte
bearbeiten, können aus bereits abgeschlossenen Projekten kaum etwas wiederverwenden.
Andere Unternehmen hingegen, welche die bestehende Software lediglich an neue geforderte
Funktionalitäten anpassen oder eine große Versionsvielfalt anbieten müssen, können einen
hohen Anteil an Wiederverwendung vorweisen. Allerdings ist die Wiederverwendung auch
hier nur auf die Codeebene beschränkt und wird meist nur unsystematisch aus der Designphase
heraus diktiert.
Wenn man nun von der klassischen handcodierten Implementierung einen Schritt zurück im
Entwicklungsfluß auf die automatische Codegenerierung sieht, ist es mit deren Verwendung in
den Unternehmen eher schlecht bestellt.
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%
Klassenbibliotheken, GUI
Bausteinen, SPS-Code
überhaupt nicht, oder dem Zufall
überlassen
Abbildung 7. Grad und Art der Wiederverwendung in der Implementierung
Ein sehr geringer Anteil der befragten Unternehmen nutzt nach der Fertigstellung der Dokumente
am Ende der Designphase Werkzeuge für die automatische Codegenerierung (< 10%).
Diejenigen, die diese Technik bereits nutzen, verwenden den generierten Code lediglich als
Anhaltspunkt für die folgende Implementierung. Vielfach gibt es auch keine definierte Designphase,
die sich für eine automatische Codegenerierung eignet.
An dieser Stelle macht sich die fehlende Spezialisierung der Softwaretechnik auf eingebettete
Systeme bemerkbar. Die Randbedingungen der Zielplattform und der Anforderungen wirken
sich unmittelbar auf die Softwareerstellung und deren Werkzeuge aus.
Gut 70% der Befragten sehen Echtzeitanforderungen als einen wichtigen Punkt in der Entwicklung
von Software für eingebettete Systeme an. Allerdings stellte sich auch heraus, daß
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 25

nur 20% aller Unternehmen für die Implementierung auf der Zielhardware ein Betriebssystem
vorsehen. Die restlichen Unternehmen gaben bei der Befragung an, daß ein Betriebssystem
entweder aus Kosten- oder aus Perfomanzgründen nicht eingesetzt werde. Andere Unternehmen
wiederum setzen aufgrund von fehlender Laufzeitkomplexität der zur Zeit bearbeiteten
Projekte keine Betriebssysteme ein.
Zusammenfassung Ist-Stand
• Standardentwicklungsumgebungen werden im Großen und Ganzen zufriedenstellend eingesetzt.
• Implementierungsrichtlinien (hauseigen/Standard) werden größtenteils (ca. 90%) angewendet.
• Wiederverwendung findet lediglich mit parametrierbaren Quellcodemodulen statt.
• Automatische Codegenerierung wird fast überhaupt nicht (< 10%) eingesetzt.
• (Echtzeit)-Betriebssysteme kommen vergleichsweise selten (< 20%) zum Einsatz.
Probleme
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%
Einsatz von automatischer
Codegenerierung
Überhaupt keine automatische
Codegenerierung
Abbildung 8. Einsatz von Codegenerierung in der Implementierung
Im folgenden Abschnitt sollen die Bereiche herausgegriffen werden, welche die Unternehmen
bei der Befragung als Problemfelder im eigenen Prozeß sahen:
Wie im vorhergehenden Abschnitt beschrieben, sind die Disziplinen aus der klassischen Softwaretechnik
in der Implementierungsphase durchaus gut etabliert und nicht für die Hauptprobleme
verantwortlich. Sobald jedoch der Pfad der konventionellen Softwareentwicklung
26 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

verlassen wird und Spezialisierungen auf bestimmte Systeme (zeit-, kosten- und sicherheitskritisch)
hin benötigt werden, fehlt die notwendige Unterstützung.
Der einzige Punkt zu dem keine nennenswerten Probleme berichtet wurden, ist der Einsatz von
Standardentwicklungsumgebungen. Zu den weiteren Punkten kristallisiert sich ein recht klares
Problembild heraus, das im folgenden beschrieben werden soll.
Programmierrichtlinien
Der Einsatz von Programmierrichtlinien wird in allen Unternehmen bestätigt. Allerdings liegen
zwischen dem »Vorschreiben« und »Einhalten beziehungsweise Überprüfen« von Richtlinien
Welten. Zum einen existieren erarbeitete Richtlinien, der Einsatz jedoch wird jedem
Einzelnen selbst überlassen. Zum anderen wird auf die Richtlinien sehr viel Wert gelegt, aber
eine Prüfung ob die Richtlinien eingehalten werden wird nicht im Rahmen eines Codereviews
als Qualitätssicherungsmaßnahme durchgeführt. Zudem werden auch unter anderem die Fälle
angetroffen, in denen die Codegröße entweder zu gering ist, um den Aufwand einer Richtlinienanwendung
zu rechtfertigen oder zu groß, um eine Überprüfung überhaupt vollständig zu
ermöglichen.
Wiederverwendung
Effiziente Wiederverwendung läßt sich nicht an einer definierten Phase der Softwareentwicklung
festmachen. Die vorhergehenden Phasen bilden die notwendige Voraussetzung, um eine
konsequente Wiederverwendung unter anderem auch auf Codeebene erfolgreich einzusetzen.
Die befragten Unternehmen sehen diesen Punkt ebenfalls als Problem an und beklagen zudem,
daß die Wiederverwendungsthematik oft dem Entwickler überlassen wird. Eine Organisation
und Methodik für eine systematische Wiederverwendung von Quellcode ist bei fast keinem der
Befragten anzutreffen. Eine Prozeßoptimierung findet sozusagen unkoordiniert und verteilt in
Abhängigkeit von der Güte des Entwicklungsteams statt. Als Gründe werden hier der Kostenund
Zeitdruck genannt, die es nicht zuließen, sich mit dem »Herauslösen« von Bausteinen zu
beschäftigen. Daher beschränkt sich die Wiederverwendung rein auf parametrierbare Quellcodemodule.
Automatische Codegenerierung
Automatische Codegenerierung ist bei vielen Interviews als großes Problemfeld angesprochen
worden. Die Gründe sind infolge von heterogenen Bedürfnissen sehr unterschiedlich.
• Automatisch generierter Code ist zu ineffizient; d.h. der Ressourcenverbrauch (Instruktionsspeicher,
Datenspeicher, Rechenleistung) ist gerade für eingebettete Systeme zu hoch.
Eine Implementierung ist auf dem eingebetteten System daher entweder nicht mit den
geforderten zeitlichen Anforderungen möglich oder aber die benötigten Ressourcen treiben
die Hardwarekosten in die Höhe.
• es besteht keine Möglichkeit, Informationen über Codeausführungszeiten zu erhalten bzw.
Zeitanforderungen explizit zu spezifizieren, so daß eine Berücksichtigung der spezifizierten
Zeiten garantiert wird.
• eine Überarbeitung von Assemblercode ist immer notwendig, um Echtzeitverhalten garantieren
zu können. Dies ist meist mit erhöhtem Zeitaufwand und Fehleranfälligkeit verbunden.
• Wird eine Nachbearbeitung von Assemblercode vorgenommen, so ist ein Reverse Engineering
Vorgang auf die höhere Ebene nicht möglich.
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 27

• Nicht immer werden von den Werkzeugen die gewünschten Zielplattformen unterstützt.
Insbesondere decken Werkzeuge aus dem Umfeld der Softwaretechnik den Bereich der
SPS-Programmierung nicht ausreichend ab.
• Wiederverwendung wird nur unsystematisch durchgeführt
Viele der hier aufgeführten Punkte sind in der Softwaretechnik im allgemeinen ebenfalls vorhanden,
jedoch sind die Nachteile dort durchaus in Kauf zu nehmen. Bei eingebetteten Systemen
gestaltet sich die Situation unterschiedlich. Die von den Unternehmen genannten
Problemfelder überwiegen zu stark, um sich im Entwicklungsprozeß auf automatische Codegenerierung
einzustellen.
Phasenübergang
Ein definierter Phasenübergang wird erst dann möglich, wenn am Ende der vorhergehenden
Phase wohldefinierte Dokumente vorliegen. Dies ist auch ein Grund dafür, daß bei über der
Hälfte der Unternehmen diesbezüglich keine Methodik vorhanden ist. Aus unstrukturierten
Textdokumenten kann kein definierter Übergang zur Implementierungsphase durchgeführt
werden. Bei den befragten Unternehmen funktioniert dies jedoch trotzdem, da die Entwickler
in vielen Fällen räumlich gebündelt sind und informelle Notationen durch direkte Kommunikation
klären können. Zudem hält sich die Projektgröße bei vielen Unternehmen in einem
überschaubaren Rahmen, so daß die Nachteile noch nicht zu überdurchschnittlich verlängerten
Entwicklungszeiten führen.
Ebenso bedeutend ist sicherlich die Durchgängigkeit der Werkzeugunterstützung. Es werden
viele verschiedene, teilweise nur auf die einzelnen Phasen zugeschnittene, Werkzeuge eingesetzt
und somit ein definierter Phasenübergang erschwert. Es fehlen zum Teil standardisierte
Schnittstellen, um eine nahtlose Verbindung zu den angrenzenden Phasen in endlicher Zeit zu
ermöglichen.
Betriebssystem
Der Einsatz von Betriebssystemen, auch zur Reduktion der Laufzeitkomplexität, ist aus verschiedenen
Gründen nicht sehr verbreitet.
Von den befragten Unternehmen wurden sowohl zu hohe Kosten als auch das Zeitverhalten
kritisiert. Je nach Codedynamik (reaktive Systeme - transformatorische Systeme), Schedulingstrategie,
Deadlines und Ausführungszeiten existieren noch weitere Parameter, die für das
Einhalten der Echtzeitbedingungen verantwortlich sind.
Daher ist die »trial and error« Methodik in vielen Fällen kostengünstiger und führt meistens
auch in der geforderten Zeit zum Erfolg. Jedoch birgt diese Form der „Behandlung“ der Problematik
ein hohes Risiko bei der zunehmenden Komplexität der Systeme: ein exhaustives
Testen ist dann nicht mehr durchführbar, womit eine Gewährleistung der Funktionalität gerade
in kritischen Bereichen ist nicht mehr möglich ist.
Zusammenfassung Probleme
• Standardentwicklungsumgebungen werden ohne nennenswerte Probleme für die Basisanforderungen
der Implementierungsphase eingesetzt.
• Einhaltung von Programmierrichtlinien wird nicht konsequent verfolgt.
• Wiederverwendung wird, wenn überhaupt, nur unsystematisch auf Codeebene durchgeführt.
28 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

• Automatische Codegenerierung wird aus Performanzgründen oder fehlender Abdeckung
der Zielplattform nicht eingesetzt.
• Ein definierter Phasenübergang existiert zum Teil nur bei der Hälfte der Unternehmen und
ist dort auch nicht besonders ausgebaut.
• (Echtzeit)-Betriebssysteme bieten in vielen Fällen nicht die geforderten Eigenschaften für
einen kostengünstigen und reibungslosen Einsatz in eingebetteten Systemen.
Handlungsbedarf aus Sicht der Unternehmen
In diesem Abschnitt werden die Handlungsempfehlungen aufgeführt, die von den Unternehmen
während der Befragung geäußert wurden.
• An erster Stelle steht dabei der Wunsch nach einer effizienten und automatischen Codegenerierung
für ressourcenbeschränkte Hardware. Die Nachteile, die im vorhergehenden
Abschnitt genannt wurden, sorgen dafür, daß von einer automatischen Codegenerierung
abgesehen wird.
• An zweiter Stelle wurde von mehreren Unternehmen eine geeignete Modellierung und
Beschreibung von Zeitaspekten genannt. Damit könnte dann bereits in frühen Phasen der
Spezifikation das Zeitverhalten berücksichtigt werden, um die tatsächliche Ausführungszeit
in der Implementierungsphase zu garantieren. Auch automatisch ermittelte »Worst Case
Execution« Zeiten während der Implementierungsphase wären dort zumindest ein Anfang.
• Zwei weitere Punkte, die von den befragten Unternehmen geäußert wurden, waren sowohl
der Bedarf nach Verwendung von konfigurierbaren Hardware- und Softwarebausteinen zur
bausteinorientierten Modellierung von Systemen als auch auf die Standardhardware eines
Unternehmens anpassungsfähige Softwarewerkzeuge. Oft scheitert die Einführung von
neuen kommerziellen Werkzeugen aufgrund der mangelnden Anpaßbarkeit an den hiesigen
Entwicklungsprozeß.
Zusammenfassung Handlungsbedarf
• Effiziente automatische Code-Genenerierung
• Modellierung von Zeit-Aspekten
• Konfigurierbare Hard- und Softwarebausteine
• Anpassungsfähige Softwarewerkzeuge für Standardhardware
3.3.6 Service und Wartung
Ist-Stand
Im Befragungsteil Service und Wartung sind die Befragungsergebnisse sehr unterschiedlich
ausgefallen. Die Spannbreite reicht von Unternehmen, die dieses Thema sehr detailliert behandeln
und mit hohem Stellenwert belegen bis hin zu Unternehmen, die hierzu gar keine Aktivitäten
erkennen lassen und diese auch nicht für wichtig halten.
Am einen Rand der beiden Extreme sind Unternehmen vorzufinden, die voll implementierte
Wartungs- und Diagnosesysteme haben, die Diagnose- und Wartungsdaten systematisch und
statistisch auswerten und diese zwecks Einbindung von Verbesserungsmaßnahmen in die Entwicklungsbereiche
zurück leiten. Komplett ausgereifte Formen nimmt die Wartung bei Syste-
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 29

men an, die über Ferndiagnosemöglichkeiten verfügen und über Datenleitung steuerbar,
instandsetzbar und wartbar sind. Dies hängt in erster Linie vom Grad des Entwicklungsstandes
und den Einsatzrahmenbedingungen der Systemtechnologie, in der die eingebetteten Systeme
eingesetzt werden, ab. Diese Systeme, die Telemonitoring, Teleservice und Prozeßaufzeichnung
ermöglichen, haben High-Tech-Standard und nutzen sämtliche Möglichkeiten der Kommunikationstechnologie.
Eine weitere Abstufung bilden die Produkte der Unternehmen, die
Logbuchfunktionalitäten enthalten oder Diagnoseergebnisse und Daten erfassen und speichern,
die bei Fehlfunktionen analysiert werden können. Jedoch nicht bei allen Unternehmen,
deren Systeme dies ermöglichen, werden die Diagnoseergebnisse systematisch analysiert und
genutzt. Die letzte Stufe bilden die Systeme, die bei Fehlfunktionen oder Ausfall komplett ausgetauscht
werden, ohne daß eine Ursachenanalyse stattfindet.
Je nach Einordnung der softwareentwickelnden Bereiche in die Unternehmen und je nach Art
des Produktes (Massenprodukt, Baukastenprodukt, Individualentwicklung oder Grundsystementwicklung,
die in Auftragsprojekten angepaßt wird), ist die organisatorische Zusammenarbeit
der Entwickler mit den Servicemitarbeitern sehr unterschiedlich gestaltet. Sie reicht von
keinerlei Kommunikation bis dahin, daß die Entwickler in der Produkteinführungsphase und
auch noch später selbst am Service beteiligt sind. Im zweiten Fall stellt sich die Frage nach
einer ausreichenden Qualifikation der Servicemitarbeiter nicht, während es im anderen Fall
zum Teil bemängelt wurde.
Probleme
Je nach Ausprägung des Themas „Service und Wartung“ entsprechend der oben dargestellten
Bandbreite, ergeben sich bei den Problembeschreibungen sehr unterschiedliche Ergebnisse.
Zum Teil werden Fehler über Diagnosemodule in den Systemen zwar erfaßt aber nicht ausgewertet,
zum andern werden Diagnoseergebnisse auf informellem Wege in die Entwicklung
zurückgesendet, aber diese Rückführung wird nicht explizit als Bestandteil eines abgesicherten
Serviceprozesses verstanden und zum Verbesserungs- und Änderungsmanagement genutzt.
Bei den Servicetechnikern beziehungsweise den Mitarbeitern, die Wartungsarbeiten durchführen,
wird mangelndes Funktionswissen bemängelt, dessen Ursache in den häufigen Versionswechseln
zu suchen ist. Bei Produkten, die keine Spezialanwendungen sind und individuell
entwickelte Funktionen enthalten, also Standardprodukte sind, besteht eine Tendenz zu ungeschultem
Service-Personal. Aber selbst Standard-Systeme können sehr komplex aufgebaut
sein und verlangen darum intelligentere Wartungssysteme.
Handlungsbedarf aus Sicht der Unternehmen
Folgende Handlungsbedarfe werden von den Unternehmen angegeben:
• Funktionsdokumente für Ausnahmeverhalten müssen einfacher erstellt beziehungsweise
ihre Erstellung sichergestellt und verlangt werden.
• Erhöhte Selbstdiagnosefunktionalitäten und Wartungsfunktionalitäten müssen implementiert
und bei der Spezifikation der Software eingeplant werden.
• Bei Neuentwicklungen sollte der Service bei der Erstellung des Lastenheftes eingebunden
werden, Wartung und Diagnose sollten explizit bei der Entwicklung berücksichtigt werden.
• Service-Personal muß besser ausgestattet und besser ausgebildet werden.
30 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

• Vor Markteinführung müssen Schulungen durchgeführt und Service-Tools entwickelt werden.
• Erfassungs- und Analysetools müssen entwickelt und weiterentwickelt werden.
• Im Qualitätsmanagementsystem sollte die systematische Auswertung von Felddaten und die
Förderung der Entwicklungsoptimierung durch Fehleranalysen vorgeschrieben werden.
• Technische Voraussetzungen für Teleservice sind zu optimieren.
• Know-how und Technologietransfer sowie Netzwerkbildung zwischen den fortgeschrittenen
Unternehmen und denen, die keinerlei Diagnosesysteme nutzen, fördern (dieser Handlungsbedarf
ergibt sich aus den starken Diskrepanzen zwischen weit fortgeschrittenen
Unternehmen und denen, die das Potential dieses Themas noch gar nicht realisiert haben).
• Entwicklungen neuer und moderner Fernwartungssysteme sind zu fördern.
• Rückführung von Diagnosedaten in die Entwicklung vorsehen und Systeme schaffen, die
das erleichtern.
• Speziell geschulte Serviceteams für eingebettete Systeme ausbilden und in andere Serviceteams
integrieren.
• In den Systemen Funktionalitäten für Wartung, Monitoring und Remote Service vorsehen
und deren Entwicklung fördern.
• Diagnosesicherheit ist ein spezifisches Thema, hier sollten Standards gefördert werden.
3.3.7 Qualitätssicherung
Eine der wichtigsten Aufgaben der Unternehmen liegt in der Sicherung der Produktqualität.
Vor dem Hintergrund, daß heute – und in Zukunft verstärkt – die Software eine Kernkomponente
innovativer Produkte darstellt, hat die SW-Qualität einen hohen Einfluss auf die Qualität
des Gesamtprodukts1 . Die Herausforderung an die Qualitätssicherung liegt darin, eine hinreichreichende
Fehlerfreiheit der Software bei akzeptablem Zeit- und Kostenaufwand zu
garantieren. Die Komplexität der Qualitätssicherung von eingebetteter Software ist dabei
höher als bei herkömmlicher Software, da das eingebettete System wesentliche Unterschiede
aufweist, wie beispielsweise die Echtzeitfähigkeit und die enge Verzahnung von Software,
Hardware und Gerätemechanik.
Ist-Stand
Da der Prozeß der Qualitätssicherung sehr vielgestaltig ist, ließ er sich nicht mit einem stark
strukturierten Fragebogen abfragen. Daher wurden hauptsächlich qualitative Fragen gestellt
und die daraus ermittelten Antworten bei der Auswertung klassifiziert und statistisch aufbereitet.
Die Zahlen stellen die expliziten Nennungen der Unternehmen dar.
1. W. A. Halang: Software-Sicherheit in der Prozeßautomation, Automatisierungstechnische Praxis (atp), Bd. 36,
H. 10, R. Oldenbourg Verlag, 1994, S. 9–10.
H. Jansen: Anforderungen an Rechnersysteme für sicherheitsrelevante Anwendungen, Automatisierungstechnische
Praxis (atp), Bd. 37, H. 2, R. Oldenbourg Verlag, 1994, S. 7–8.
U. Krämer: Anforderungen beim Einsatz programmierbarer Systeme für Schutzeinrichtungen, Automatisierungstechnische
Praxis, Bd. 36, H. 10, R. Oldenbourg Verlag, 1994, S. 22–28.
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 31

Überblick
Fast alle Unternehmen besitzen ein definiertes oder standardisiertes Qualitätsmanagementsystem,
jedoch wird dabei die Softwareentwicklung außer Acht gelassen bzw. nur sehr grob
beschrieben.
Die untersuchten Unternehmen sind sehr unterschiedlicher Natur, mit jeweils einer Vielzahl
von unterschiedlichen Projekttypen. Trotz der daraus resultierenden Vielfalt an Vorgehen, speziell
hinsichtlich der Qualitätssicherung, kristallisiert sich eine Struktur (siehe Abbildung 9)
heraus.
Abbildung 9. Qualitätssicherung: Vorgehensweise
Allen Unternehmen ist prinzipiell bewußt, daß Fehler möglichst frühzeitig entdeckt werden
sollten. Jedoch wird der größte QS-Aufwand am Ende der Entwicklung, nämlich in den Testphasen
betrieben. Dort ist wiederum zu erkennen, daß der abschließende Systemtest eine zentrale
Rolle einnimmt.
In den frühen Entwicklungsphasen werden das Pflichtenheft von ca. 89%, der Entwurf von ca.
80%, und der Code von ca. 86% der Befragten einem Review unterzogen. Bemerkenswert ist,
daß diese QS-Maßnahme von etwa 60% der Unternehmen nicht systematisch, mit entsprechenden
Zieldefinitionen und Vorschriften, betrieben wird. Der Rest verfügt hauptsächlich
über Check-Listen. In den meisten Fällen ist der Projektleiter für die Reviews verantwortlich.
Falls eine QS-Abteilung existiert, ist sie bei den Reviews selten beteiligt. Auch eine frühe
Berücksichtigung der Testphase während der Analyse oder des Entwurfs ist nicht gegeben. Nur
wenige Unternehmen beziehen in diesen Phasen alle am Projekt Beteiligten mit ein. Lediglich
vier der befragten Unternehmen setzen in der Analyse- und Entwurfsphase Prototypen beziehungsweise
Mock-Ups (Werkmodelle) als QS-Maßnahme ein. Da beim Review die Software
nicht ausgeführt wird und die Zielhardware sowie der technische Prozeß – was für eingebettete
Systeme von großer Bedeutung ist – nicht berücksichtigt werden, bleiben hier Fehler unentdeckt.
Dies sind hauptsächlich jene Fehler im Zeitverhalten und im Zusammenspiel der Einzelkomponenten,
welche in den nachfolgenden Testphasen erkannt werden sollen.
32 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

Trotz unterschiedlicher Begriffsdefinitionen für die einzelnen Phasen läßt sich folgendes
erkennen: Zunächst erfolgt ein Modultest (vgl. mit dem Entwurfsdokument) durch die Entwickler.
Bemerkenswert dabei ist, daß bei ca. 63 % der Unternehmen die Entwickler selbst ihr
Programm testen. Die Projektgrößen variieren zwischen wenigen Personentagen bis mehreren
Personenjahren. Bei den Kleinstprojekten macht es vielleicht wirtschaftlich wenig Sinn, den
Modultest durch eine unabhängige QS-Abteilung durchführen zulassen, jedoch sollten Entwickler
zumindest gegenseitig ihre Software testen.
Der Modultest erfolgt auf dem Host-Rechner (Entwicklungsumgebung). Hier kommen Testverfahren
wie Black-box und White-box zum Einsatz, um logische Fehler im Programm zu
finden. Als Hilfsmittel werden in der Regel Debugger eingesetzt. In dieser Phase werden auch
die Integration und der anschließende Test der einzelnen SW-Module durchgeführt. Da die
Zielhardware nicht berücksichtigt wird, stellt der Modultest eine logische Überprüfung der
Softwarefunktionalität dar.
Die Prüfung unter Echtzeitbedingungen erfolgt im Integrationstest. Hier wird die Software
direkt auf die Zielhardware beziehungsweise auf Emulatoren zum Laufen gebracht. Da hier ein
Vergleich gegen das Pflichtenheft stattfindet, kommen hauptsächlich Black-box-Testverfahren
zum tragen. Neben dem Emulator setzen ca. 43% der Unternehmen die Simulation ein.
Obwohl beim Testen unter Echtzeitbedingungen die Berücksichtigung des technischen Prozesses
wichtig ist, simulieren nur drei dieser Unternehmen das technische Umfeld des eingebetteten
Systems. Alle anderen simulieren die Hardware.
Während auch beim Integrationstest die Entwickler maßgebend beteiligt sind, stehen diese
beim Systemtest außen vor. Hier erfolgt eine sogenannte Abnahme (vgl. mit dem Lastenheft)
durch die Elektronik-Abteilung bziehungsweise, falls vorhanden, durch die QS-Abteilung. Zu
diesem Zweck wird eine entsprechende Prüfumgebung oder Simulation aufgebaut, welche oft
Eigenentwicklungen darstellen und von daher sehr aufwendig sind.
QS-Organisation
Annähernd 66 % aller Unternehmen geben an, daß sie eine zentrale QS-Abteilung besitzen.
Jedoch regelt diese selten die Prüf- und Testprozesse, oder gibt Vorschriften und Richtlinien
für die Software vor. Ihre Verantwortung liegt mehr in der Hardware- und Produktqualität bis
hin zur Qualitätssicherung in der Fertigung. Obwohl durchweg alle Unternehmen angeben, daß
sie dem Thema Software-Qualität eine große Bedeutung beimessen, wird dies nicht organisatorisch
durch eine zentrale QS-Abteilung für die Software berücksichtigt. Gelegentlich wird
die zentrale QS-Abteilung ganz am Ende des SW-Entwicklungsprozesses, nämlich bei der
Abnahme (Systemtest) eingebunden. Leider werden in diesem Fall, die Vorschriften und die
Testfälle zur Prüfung der Software oft durch die Entwickler vorgegeben.
Insbesondere bei größeren Projekten stellt die Qualitätssicherung der Software einen entscheidenden
Erfolgsfaktor dar. Kennzeichnend dafür ist, daß Großunternehmen jeweils einen QS-
Beauftragten je Abteilung beziehungsweise je Projekt besitzen, der sich speziell um diese
Belange kümmert. Obwohl eine unabhängige Prüfung die effektivste und erfolgversprechendste
Art der Qualitätssicherung darstellt, erfolgen insbesondere die Tests bei etwa 63 %
der Befragten durch die Entwickler selbst. In der Studie der Universität Köln kam man auf
einen ähnlichen Wert (70%). Falls der Kunde an QS-Maßnahmen beteiligt wird, erfolgt dies
hauptsächlich über die Reviews.
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 33

Abbildung 10. Organisation der Qualitätssicherung
QS-Ziele
Die Defizite hinsichtlich der QS-Organisation spiegeln sich auch in den verfolgten QS-Zielen
wieder: Fast alle Unternehmen (94%) sehen die Sicherung der Produktqualität als ihr oberstes
Ziel an. Erschreckend viele, nämlich zwei Drittel aller Unternehmen, nutzen die Ergebnisse
der QS-Maßnahmen nicht, um zum Beispiel Rückschlüsse auf die Fehlerursachen – womöglich
in frühen Phasen – zu schließen und so den Entwicklungs- und QS-Prozeß zu verbessern.
QS-Praktiken
Bemerkenswert viele Unternehmen (ca. 60%) betreiben keine systematische QS-Maßnahmen
für die frühen Entwicklungsphasen Analyse und Design, was ja außerordentlich wichtig ist für
eine kostengünstige Fehlerbehebung. Kennzeichnend dafür ist, daß hier vornehmlich – nur vier
Unternehmen setzen Prototyping oder Mock-Ups ein – Reviews durchgeführt werden, für die
es keine Vorschriften und Richtlinien gibt. Der Test stellt eine dynamische QS-Maßnahme dar,
welche besonders bei eingebetteten Systemen zur Funktionsprüfung unter Echtzeitbedingungen
bevorzugt wird. Etwa 57% geben auch an, daß sie im Projektplan eine Testphase berücksichtigen.
Eine Definition der Inhalte und des Vorgehens, in der Testziele definiert,
Risikoabschätzungen vorgenommen, oder Umfang und Art der Tests festgelegt werden, erfolgt
in den seltensten Fällen. Gut die Hälfte der Unternehmen haben Vorschriften für die Tests.
Wenn man aber bedenkt, daß diese sich in erster Linie auf den Systemtest beziehen, was eine
„offizielle” Abnahme darstellt, erkennt man, daß die wichtigen vorgelagerten Testphasen
(Modultest, Integrationstest) erst recht nicht systematisch und nachvollziehbar erfolgen.
Eine gute Anforderungsanalyse ist ein Garant für eine erfolgreiche Entwicklung. Für den Testprozeß
ist das Äquivalent die Testfallermittlung beziehungsweise -definition. Nahezu 60%
ermitteln ihre Testfälle, die dazu dienen sollen, die Qualität und Effizienz der Tests sicherzustellen,
nur unsystematisch. Bei diesen Unternehmen wird die Testfallermittlung den Entwicklern
selbst überlassen, die sich sich auf ihre Erfahrung erlassen. Auch hier ist weiter
34 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

Abbildung 11. Qualitätssicherung: Praktiken
einzuschränken, daß die praktizierte systematische Testfallermittlung sich hauptsächlich auf
den Systemtest bezieht. Daher ist nicht verwunderlich, daß nur 3% eine automatische Generierung
von Testfällen, vornehmlich direkt aus der Spezifikation, anstreben.
Der große Teil (ca. 71%) der Befragten dokumentiert die Durchführung der Tests zumindest
bei der Abnahme. Jedoch setzen etwa 89% keine Werkzeuge dazu ein. Folglich ist auch die
Analyse der Testergebnisse zum Zweck der Ermittlung von Kennzahlen, um damit Ursachenforschung
und Fehlervermeidung zu betreiben, praktisch nicht möglich. Siebzig Prozent der
Befragten sehen dies sogar nicht einmal als Ziel an.
Die erforderliche Anzahl von Testfällen ist enorm hoch, da eingebettete Systeme unter anderem
konfigurierbar und parametrierbar sind sowie verschiedenste Betriebsarten besitzen. Um
den Testaufwand zu reduzieren und noch wirtschaftlich akzeptabel zu gestalten, ohne Abstriche
an der Testgüte vorzunehmen, bedarf es einer geeigneten Unterstützung der Testaktivitäten
durch Werkzeuge. Fast 86% der Unternehmen führen keine automatischen Tests durch, obwohl
Regressionstests – insbesondere bei eingebetteter Software, die sehr optimiert und mit der
Hardware sowie dem technischen Umfeld eng verzahnt ist – sinnvoll sind. Weitere Indizien für
Mängel in der Systematik des Testens sind, daß nur 17% geeignete Prüfumgebungen (Testbett)
besitzen und mehr als 83% keine Werkzeuge zur Ausführung der Tests einsetzen.
Zusammenfassung Ist-Stand
• Wenig Planung und systematisches, definiertes Vorgehen der SW-Qualitätssicherung.
• Eine kompetente Organisationseinheit für die SW-Qualität fehlt. Der Entwickler selbst testet
erfahrungsgetrieben.
• Die Prüfung unter Echtzeitbedingungen spielt eine wichtige Rolle. Sie findet jedoch keine
geeignete Unterstützung durch Methoden und Werkzeuge.
• Wenig systematische Reviews als QS-Maßnahme für das Pflichtenheft, den Entwurf und
den Code.
• Tests als dynamische QS-Maßnahme und Durchführung in verschiedenen Phasen (Modultest,
Integrationstest, Systemtest).
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 35

• Die Verbesserung des Entwicklungsprozesses spielt nur eine geringe Rolle
• Werkzeugeinsatz findet für die einzelnen Testaktivitäten nur in geringem Maße statt.
Probleme
Abbildung 12. Qualitätssicherung: Werkzeugeinsatz beim Testen
Ausgelöst durch die steigenden Softwareanteile, bereitet fast allen Entwicklungsabteilungen
die erheblich gestiegene Produktkomplexität, die enge Verzahnung der Software mit dem
Hardwareumfeld sowie die stark von Optimierungsbemühungen getriebene Entwicklung große
Schwierigkeiten vor allem bei der Qualitätssicherung solcher Art integrierter Systeme. Die
Qualitätsansprüche an intelligente technische Produkte und damit an eingebettete Systeme sind
jedoch sehr hoch. Die SW-Entwicklung ist als ein weitgehend kreativer und in weiten Bereichen
manuell durchgeführter Prozeß stark fehlerbehaftet. Weiterhin stellt Software ein imaginäres
Produkt dar, welches man nicht fassen und fühlen kann. Die Folge davon ist, daß man die
Qualität von Software nur sehr schwer definieren und messen kann.
QS-Planung
Viele Unternehmen sind noch weit entfernt von einer systematischen Planung und Durchführung
der Qualitätssicherung von Software über alle Entwicklungsphasen hinweg. Darüber hinaus
verkürzen häufig Projektverzögerungen die verbleibende Testzeit. Die Folge ist, daß unter
hohem Zeitdruck und ohne definierte Zielvereinbarung gearbeitet wird. Eine organisatorische
Einheit mit dem notwendigen Wissen über SW-Qualität ist selten vorhanden und die Tests werden
dem Entwickler selbst überlassen. Die Tests und die erforderliche Testumgebung werden
erst kurz vor dem Testen erstellt.
Eine systematische QS-Planung kann hier vieles verbessern. Das Festlegen der zu prüfenden
Objekte und die Art der Prüfung stellt sicher, daß die Qualitätssicherung vollständiger und
zuverlässiger wird. Der Testprozeß muß genau definiert werden, um ihn besser zu organisieren
36 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

und zu rationalisieren. Dazu gehört auch die Entwicklung eines Testplans um eine gute und
definierte Testabdeckung zu erhalten. Die Planung ermöglicht effektivere Qualitätssicherung,
da sie transparent und nachvollziehbar wird. Dadurch ergibt sich die Möglichkeit, durch Risikoabschätzungen
auf den QS-Prozeß geeignet steuernd einzuwirken. Kennzahlen können zur
Aufwandsabschätzung und Zeitplanung benutzt werden. Damit man eine definierte und wiederholbare
Qualität erzielen kann, darf die Qualitätssicherung nicht alleine von der Erfahrung
Einzelner abhängen.
Testfälle – Testmethoden
Ähnlich unsystematisch und erfahrungsabhängig wird das Ermitteln von Testfällen betrieben.
Mit dieser Aufgabe sind hauptsächlich die Entwickler selbst beschäftigt. Als erstem Schritt im
Testprozeß kommt diesem eine enorme Bedeutung zu.
Der Entwurf von Testfällen erfordert ein hohes Maß an Kreativität. Trotzdem existieren
Methoden, mit deren Hilfe man systematisch Testfälle ermitteln kann. Das direkte Ableiten aus
der Spezifikation würde beispielsweise sicherstellen, daß mit einer minimalen Anzahl von
Testfällen die gesamte Funktionalität überprüft würde. Die Beschreibung und Dokumentation
von Testfällen wirken sich auch positiv auf den Entwicklungsprozeß aus. Anforderungen und
Spezifikationen können aus einer anderen Sicht betrachtet werden und zu klareren und testbareren
Anforderungen führen. Testfälle können abgelegt und wiederverwendet werden, wobei
die Ausführung der Tests von verschiedenen Personen erfolgen kann. Die Validierung der Testfälle
wird möglich und ihre Qualität kann durch wiederholte Reviews gesteigert werden,
wodurch eine sicherere Abschätzung der Produktqualität möglich wird. Die Verwaltung und
Wiederverwendung einmal entwickelter Testfälle kann hier den Aufwand minimieren und vor
allem eine Unabhängigkeit von Personen bieten. Der Test selbst kann Dank der adäquaten und
qualitativen Testfälle eine höhere Testtiefe und -breite erhalten.
Testwerkzeuge
Die Unternehmen setzen relativ wenig Werkzeuge zum Testen ein. Der Grund dafür ist, daß es
keine Werkzeuge gibt, die den besonderen Anforderungen von eingebetteten Systemen genügen
und gleichzeitig ein akzeptables Preis-/Leistungsverhältnis bieten. Erschwerend kommt
hinzu, daß sie an die Gegebenheiten der Unternehmen und den gelebten Entwicklungsprozeß
schwer anpaßbar sind.
Festzuhalten bleibt jedoch, daß man auf Werkzeuge angewiesen ist, um die Tests effizient
durchführen zu können. Komplizierte Funktionen sind nur mit aufwendigen Testszenarien,
unter Zuhilfenahme von Werkzeugen möglich. Immer öfter ist es erforderlich, beim Test auch
den technischen Prozeß aufwandsarm nachzubilden. Durch Eigenentwicklungen versuchen
derzeit die Unternehmen den Fehlstand zu lindern.
Zusammenfassung Probleme
• Keine systematische Planung und Durchführung der QS
• Projektverzögerungen verkürzen die Testzeit
• Selten ist eine organisatorische Einheit für die SW-Qualität vorhanden
• Das Ermitteln von Testfällen erfolgt unsystematisch und ist erfahrungsabhängig
• Ein geeignetes und einheitliches Beschreibungsmittel für Testfälle fehlt
• Werkzeuge zum Testen erfüllen die besonderen Anforderungen eingebetteter Systeme nur
unzureichend
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 37

• Ungenügende Anpaßbarkeit der Testwerkzeuge an den Entwicklungsprozeß und an die
Gegebenheiten des Unternehmens
Handlungsbedarf aus Sicht der Unternehmen
Von den Befragten wurden die folgenden Vorschläge als Handlungsbedarf identifiziert:
• QS-Prozeßmodell für eingebettete Systeme
• automatische Testfallgenerierung
• systematische QS für Design und Analyse
• Testautomatisierung
• Rückverfolgbarkeit (Testdaten, Testfälle, Code, Entwurf, Anforderungen)
• QS für Fremdkomponenten
• Berücksichtigung der Testphasen in frühen Entwicklungsphasen (Analyse, Design)
• Ableiten von Testszenarien aus der Spezifikation
• Systematische Ableitung und Beschreibung von Testfällen
• Beschreibungstechniken für QS
• Tools zur Unterstützung der QS
• Bewertung der Simulationstechnik bezüglich QS
• Aufwandsarme Nachbildung des technischen Prozesses zu Testzwecken
• Verbesserung des Entwicklungsprozesses durch Auswertung der Testergebnisse
• Effektive QS-Maßnahmen für Analyse und Design
3.3.8 Konfigurationsmanagement
Ist-Stand
Die durchgeführten Interviews haben ergeben, daß etwa 25% der befragten Unternehmen gar
kein Konfigurationsmanagementsystem einsetzen, etwa 50% der Unternehmen setzen einfache
Konfigurationsmanagementsysteme, wie PVCS, CVS, SourceSafe, etc., ein und weitere 25%
sehr moderne Systeme wie ClearCase.
Die Unternehmen ohne Konfigurationsverwaltungssystem haben meist nur mit relativ kleinen
(Software)Projekten zu tun, die sich noch durch ein diszipliniertes Vorgehen weniger Entwickler
bewältigen lassen. Trotzdem befinden sich etwa 50% dieser Firmen auf dem Sprung zu Projekten
der nächst größeren Kategorie (oder haben sich bereits an solchen Projekten versucht).
Für diese Firmen stellt das Fehlen eines geeigneten Konfigurationsmanagementsystems ein
entscheidendes Wachstumshemmnis dar. Erschreckend war hier die Unkenntnis von eigentlich
bereits weit verbreiteten Konfigurationsmanagementwerkzeugen und das mangelnde Problembewußtsein
vieler Firmen. Nicht selten wird die Dokumentenverwaltung ausschließlich dem
jeweiligen Entwickler überlassen, was zu entsprechenden Problemen bei Krankheit, Urlaub
oder Weggang dieser Person führt und wodurch das Überleben von Projekten nach einem einfachen
Plattenfehler allein von der Sorgfalt der entsprechenden Person abhängt.
38 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

Die Unternehmen mit einfachen Konfigurationsverwaltungssystemen waren weitgehend mit
der Ist-Situation zufrieden und sahen hier keinen direkten Handlungsbedarf für sich selbst.
Hier herrschen Projekte mit bis zu 15 Entwicklern vor, die durchaus mit der verwendeten
Technologie beherrscht werden können. Auffällig bei dieser Unternehmensgruppe war, daß bei
über 80% dieser Unternehmen pessimistische Sperrverfahren verwendet werden. Das heißt,
wenn ein Mitarbeiter einige Dokumente ändern möchte, dann werden diese Dokumente für
weitere schreibende Zugriffe gesperrt, um das gegenseitige Überschreiben von Änderungen zu
verhindern. Bei dieser Vorgehensweise entstehen jedoch (abhängig von der Projektgröße) oft
lange Wartezeiten für den Zugriff auf Dokumente, zum Beispiel durch unvorhergesehene Programmfehler.
Dann werden solche Dokumentsperren immer wieder aufgehoben oder umgangen,
wodurch der gewünschte Koordinierungseffekt verloren geht.
Ein weiteres Problem, das meist mit pessimistischen Sperrverfahren einhergeht, ist, daß oft nur
die zu verändernden Dokumente in den privaten Arbeitsbereich des einzelnen Entwicklers
kopiert werden, während lesend verwendete Dokumente im Gruppenarbeitsverzeichnis verbleiben.
Werden dann veränderte Dokumente in den Gruppenarbeitsbereich zurückgestellt,
entstehen für alle Entwickler, die diese Dokumente benutzen, Konsistenzprobleme. Diese
Konsistenzprobleme können durch optimistische Sperrverfahren und die Verwendung von
geschützten Arbeitsbereichen (sogenannten Sand-Boxes) vermieden werden. Für den sinnvollen
Einsatz solcher optimistischer Koordinationstechniken sind jedoch projektweite automtische
Konsistenzprüfung auch über Disziplinengrenzen hinweg unabdingbar. Solche
projektweiten Konsistenzprüfung stehen bisher nicht zur Verfügung.
Im Bereich der sehr großen Unternehmen fanden wir einheitlich ClearCase als
Konfigurationsverwaltungssystem vor. Alle Unternehmen, die ClearCase erfolgreich eingeführt
hatten zeigten sich damit sehr zufrieden. (Es wurde vereinzelt von Problemen bei der
Einführung von ClearCase berichtet. Hierfür dürfte wohl die vergleichsweise hohe notwendige
technische Kompetenz verantwortlich sein.) Insbesondere bieten solche Systeme eine rudimentäre
Workflow-Unterstützung an, mit der die Weiterleitung von Teilergebnissen zu nachfolgenden
Bearbeitern und die Koordinierung solcher Arbeitsketten verbessert werden kann.
Mit modernen Konfigurationsmanagementsystemen wie ClearCase scheinen auch recht große
Projekte mit 60 bis 100 Mitarbeitern ganz gut beherrschbar zu sein.
Ein für alle Konfigurationssysteme offener Problempunkt ist, dass praktisch nur reine Textdokumente
unterstützt werden. Dies reicht für die Organisation von Quelltexten in reinen Softwareprojekten
meist aus. Im Bereich der eingebetteten Systeme gibt es jedoch eine Vielzahl
nicht textueller Dokumente wie graphische SPS-Programme, Schaltpläne, CAD-Zeichnungen,
Platinenlayouts und CASE-Tool-Dateien. I
Nur sehr wenige Firmen verwalten mit ihren Konfigurationsmanagementsystemen auch die
Dokumente sehr früher Phasen, wie Verträge, Anforderungsdefinitionen, Pflichtenhefte und
Prototypunterlagen, und Dokumente aus den späten Phasen, wie Testtreiber, Testprotokolle
und Maintenanceunterlagen, sowie projektbegleitende Dokumente, wie Projektpläne, Entwicklungsrichtlinien
und die technische Dokumentation. Hier entstehen wieder die gleichen
Koordinierungsprobleme, die schon zwischen den verschiedenen Domainen auftreten, nämlich,
daß aufgrund paralleler Änderungen Inkonsistenzen entstehen, die dann zum Beispiel
dazu führen können, daß Entwickler veraltete Anforderungsdefinitionen implementieren.
Zusammenfassung Ist-Stand
• 25% der Unternehmen haben kein Konfigurationsmanagement
=> Projekte bis 3 Entwickler werden beherrscht
• 50% der Unternehmen haben einfache Systeme wie CVS, davon
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 39

- 80% pessimistische Sperrverfahren
=> keine Entwicklungs-Sand-Boxes
=> Projekte bis 15 Entwickler werden beherrscht
- 20% optimistische Sperrverfahren
=> Projekte bis 30 Entwickler werden beherrscht
• 25% Clearcase
=> Projekte bis 100 Mitarbeiter werden beherrscht
• Hauptsächlich nur Quelltexte und eventuell Entwurfsunterlagen
• Keine Dokumenttypübergreifende Konsistenzanalysen
• proprietäre Datenformate vieler Werkzeuge behindern Konfigurationsmanagement
Probleme
Konfigurationsmanagementsysteme dienen ganz allgemein der Verwaltung von Dokumenten
und zur Koordinierung der Zugriffe unterschiedlicher Bearbeiter auf solche Dokumente. Unter
dem Begriff Dokument verstehen wir in diesem Zusammenhang alle Arten von Menschen
erstellter beziehungsweise bearbeiteter Dateien. Typische Beispiele sind Quelltexte, CAD-
Dateien und Anforderungsdefinitionen. Automatisch generierte Dateien wie Objektdateien
und Executables werden hier nicht betrachtet. Zueinander passende Versionen aller Dokumente
eines Projektes werden als Konfiguration bezeichnet.
Geordnete Ablage aller zu einem Projekt gehörender Dokumente
Das erste wichtige Problemfeld im Bereich Konfigurationsmanagement besteht in der geordneten
Ablage aller zu einem Projekt gehörenden Dokumente. Hier reicht es zunächst, wenn ein
zentraler, für alle Beteiligten zugänglicher Ablageort und ein einheitliches Ablagesystem existieren.
Dies garantiert, dass alle Projektbeteiligten jederzeit wissen, wo für sie wichtige Dokumente
aufzufinden sind, und daß sie dort einen geordneten Zugriff auf die aktuell gültigen
Fassungen dieser Dokumente haben. Wichtig ist hierbei, daß wirklich alle Projektdokumente
aller Projektphasen zusammengefaßt werden. Oft werden nur Entwurfs-und Realisierungsdokumente,
wie Quelltexte, Schaltpläne und CAD-Zeichnungen, zentral organisiert, während
Vertrags- oder Anforderungsdefinitionsdokumente fehlen. Dies kann leicht dazu führen, daß
Entwickler mit veralteten Pflichtenheften arbeiten und dementsprechend falsche Funktionalitäten
realisieren.
Verwaltung von alten Projektstände
Das zweite Problemfeld des Konfigurationsmanagements betrifft die Verwaltung alter Projektstände.
Nach Abschluß eines Projektes werden die beteiligten Dokumente oft für Folgeprojekte
weiterverwendet und in diesen Folgeprojekten an neue Anforderungen angepaßt. Dabei
kommt es oft vor, daß nach einiger Zeit das alte Projekt wieder aufgenommen werden soll,
etwa um einen Fehler zu beheben oder aufgrund eines Weiterentwicklungsauftrags. Dafür ist
es meist erforderlich, exakt die Originalstände oder Versionen der alten Projektdokumente
wieder zur Verfügung zu haben, da die inzwischen durchgeführten Modifikationen zu schwer
identifizierbaren Inkonsistenzen des Gesamtsystems führen können.
Parallelbearbeitung von Dokumente
Weitere typische Probleme im Bereich Konfigurationsmanagement entstehen, wenn mehrere
Personen gleichzeitig oder parallel zueinander die selben Dokumente bearbeiten. Hier kann es
ohne geeignete Werkzeugunterstützung sehr leicht passieren, daß zwei Bearbeiter unabhängig
40 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

voneinander das gleiche Dokument bearbeiten und sich ihre jeweiligen Fassungen gegenseitig
überschreiben.
Ähnliche Probleme können auch bei der parallelen Bearbeitung verschiedener Dokumente entstehen,
die inhaltlich aufeinander aufbauen. Hier kommt es oft vor, daß die Änderungen des
einen Bearbeiters für sich genommen korrekt sind, aber mit den später eingespielten Veränderungen
des anderen Bearbeiters nicht zusammen passen. Ähnliche „Reibungsverluste“ entstehen
auch, wenn ein Entwickler mit einem komplizierten Umbau beschäftigt ist und seine
Arbeit testen möchte. Hier kommt es ohne geeignete Koordination oft vor, daß ein solcher Entwickler
andere Dokumente direkt oder indirekt benutzt, die inzwischen verändert wurden. Die
Veränderungen an den benutzten Dokumenten erfordern dann häufig, daß der einzelne Entwickler
seine Dokumente entsprechend anpaßt, damit wieder eine in sich konsistente und testbare
Gesamtkonfiguration entsteht. In der Praxis führt dies oft dazu, daß ein Entwickler
ständig seine eigentliche Arbeit unterbrechen muß, um Änderungen anderer Entwickler nachzuziehen
und um Konsistenz und Testbarkeit des Gesamtsystems wieder herzustellen.
Disziplinübergreifende Koordination
Die Projektanteile der verschienden Disziplinen, wie Informatik, Elektrotechnik, Maschinenbau
und Betriebswirtschaft, sind oft organisatorisch getrennt und werden von einander unabhängig
bearbeitet. Dadurch entstehen leicht voneinander relativ unabhängige Kopien vieler
Dokumente, welche die oben diskutierten Probleme des Auffindens der aktuell gültigen Dokumentfassung
und der Koordination des Zugriffs auf diese Dokumente im Großen noch einmal
neu hervorrufen. Hinzu kommt, dass eine automatische, projektweite Konsistenzprüfung über
Disziplingrenzen hinweg bisher völlig fehlt. Nach einiger Projektlaufzeit kann oft niemand
mehr sagen, welche Fassung einer SPS-Steuerung zu welchem Bauplan und zu welchem
Schaltplan passt. In diesem Bereich sind bisher kaum geeignete Vorgehensstrategien und
Werkzeuge bekannt.
Zusammenfassung Probeleme
• zentrale Ablageorte und einheitliche Ablagesysteme fehlen teilweise
• nicht alle Phasen werden abgedeckt
• alte Projektstände sind nicht wieder herstellbar
• Koordination des Zugriffs auf einzelne Dokumente ungenügend
(Sperren sind nicht vorhanden oder müssen umgangen werden)
• Änderungen an verschiedenen Dokumenten, die aufeinander aufbauen, sind oft unkoordiniert
• Entwickler-Sand-Boxes fehlen
(Arbeit wird oft durch Abgleich mit anderen Entwicklern unterbrochen)
• Projektweite disziplinübergreifende Konsistenzanalysen stehen nicht zur Verfügung
• Konfigurationsmanagement scheitert an Abteilungs- und Organisationsgrenzen
(mangelhafte Koordinierung mehrerer Repositories)
Handlungsbedarf aus Sicht der Unternehmen
Wie bereits oben beschrieben, waren in fast allen Bereichen die befragten Unternehmen mit
ihrer aktuellen Situation im Bereich Konfigurationsmanagement relativ zufrieden. Die Unter-
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 41

nehmen, die bereits einfache Konfigurationsmanagementsysteme einsetzen, äußerten gelegentlich
den Wunsch nach besserer Bedienbarkeit und Anschaulichkeit der Werkzeuge. Wirklich
Handlungsbedarf haben nur einige größere Unternehmen berichtet, die ein modernes Konfigurationsmanagementsystem
in Standort übergreifenden Projekten einsetzen. Hier wurde eine
bessere Prozeßunterstützung gewünscht. Ein häufiger geäußerter Wunsch von Unternehmen,
die mit dem Einsatz ihres jeweiligen Konfigurationsmanagementsystems sehr zufrieden sind,
war die Ausdehnung der Unterstützung auf weiterer Dokumenttypen. Insbesondere wurde die
mangelnde Versionsunterstützung von SPS-Werkzeugen beklagt. Ein immer wieder genanntes
Problem ist auch das Zusammenführen von parallel bearbeiteten Entwurfsdokumenten.
Zusammenfassung Handlungsbedarf
• Ausdehnung des Konfigurationsmanagement auf weitere Dokumenttypen
(z.B. Word- und Excel-Dateien, Rational-Rose-Files, CAD-Zeichnungen, Schaltpläne)
• Unterstützung von Mischalgorithmen für das optimistische Sperren auch bei
- Anforderungsdefinitionsdokumenten (z.B. Word- und Excel-Dateien) und
- Designdokumenten (z.B. Rational-Rose-Files, CAD-Zeichnungen, Schaltpläne, ...)
• Prozeßunterstützung für die Koordination von Projekten mit mehreren Repositories
(z.B. Multi-Site-Projekte)
3.3.9 Beschreibungstechniken und Werkzeuge
Ist-Stand
Über alle Klassifikationen hinweg werden nur isolierte Werkzeuge und isolierte Beschreibungstechniken
verwendet, hauptsächlich zur Veranschaulichung beziehungsweise einfacheren
Darstellung bestimmter Sachverhalte sowohl in der Kommunikation der Entwickler
untereinander, als auch bei der Erstellung von Dokumentationen. Diese Gegebenheit kann man
mitunter aus der Tatsache ableiten, daß Beschreibungstechniken hauptsächlich in Dokumenten
der Analyse (falls die Auftraggeber über technisches Hintergrundwissen verfügen, das es ihnen
erlaubt, höhere Beschreibungstechniken zu verstehen) und des Grobdesigns anzutreffen sind.
Favorisierte Beschreibungstechniken
So ist es nicht verwunderlich, daß Techniken zur Veranschaulichung der Programm- oder Systemstruktur
(Stukturdiagramme, Architekturdarstellungen und Klassendiagramme, siehe dazu
Abbildung 14) und einfach zu verstehende Verhaltensbeschreibungen (Automaten, siehe dazu
Abbildung 13) eindeutig favorisiert werden. Alle anderen Beschreibungstechniken spielen nur
eine untergeordnete Rolle. Interessant ist, daß bei der Strukturbeschreibung nur weniger als ein
Drittel der Befragten UML als Beschreibungsstandard verwenden. Bei den Verhaltensbeschreibungen
spielt UML keine Rolle, da hier das Traditionsbewußtsein scheinbar stärker ist
und man auf die Beschreibungsformen zurückgreift, die „schon immer” verwendet wurden
und von denen man glaubt, daß sie von allen Betroffenen auch verstanden werden.
Vorschriften zum Einsatz von Beschreibungstechniken & Werkzeugen
Aber selbst für die eingeschränkten Ziele der Kommunikation und Dokumentation sind die
eingesetzten Maßnahmen unzureichend, da es den Entwicklern meist völlig freisteht zu entscheiden,
welche Beschreibungsmittel und welche Werkzeuge sie einsetzen und wenn doch
Vorschriften existieren, dann ist meist der Grad, bis zu dem sie angewendet werden müssen,
42 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

60
50
40
30
20
10
0
80
70
60
50
40
30
20
10
0
keine
keine
Prozessdiagramme(SDL)
Strukturdiagramm
Petrinetze
Datenflussdiagramme(SA)
Kontrollflussdiagramme(SA/RT)
Automaten
Prozeßaktivierung
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 43
Collaboration
Abbildung 13. Wie wird Verhalten beschrieben
Entity Relationship Diagram
(ERD)
Klassen/Rollendiagramm
Instanzend.
Abbildung 14. Wie wird Strukturinformation beschrieben
Typdef
Activity
oo-Prog. Strukt
MSCs
Tabellen
inf. Archit.
Strukt. Text
Prozess/Deploymentdiagramm
Pseudocode
(UML)
(UML)

nicht festgelegt. So kann es passieren, daß innerhalb einer Abteilung zwei Entwicklergruppen
mit verschiedenen Werkzeugen arbeiten und sogar innerhalb einer Entwicklergruppe ein Teil
mit Beschreibungstechniken arbeitet, ein anderer gänzlich auf sie verzichtet.
Fortgeschrittener Einsatz von Beschreibungstechniken - Werkzeuge
Die Verwendung von Beschreibungstechniken für über Dokumentation und Kommunikation
hinaus gehende Zwecke, wie beispielsweise phasenübergreifende Generierung, darunter fallen
die Generierung von Dokumentationen, Benutzerschnittstellen, Testfällen oder klassische
Codegenerierung, beziehungsweise für Konsistenzanalysen bis hin zur kompletten Simulation
des Entwurfs, hängt natürlich stark mit der Verfügbarkeit und Anwendbarkeit entsprechender
Werkzeuge zusammen. An dieser Stelle sollte aber noch einmal ausdrücklich darauf hingewiesen
werden, daß ein gutes Werkzeug für sich niemand zu einem guten Entwickler machen
kann. Vielmehr ist eine gute Werkzeugunterstützung das letzte Glied in einer langen Wirkungskette
von Voraussetzungen für eine effiziente und effektive Softwareentwicklung.
Betrachtet man die statistische Auswertung der Befragungsergebnisse, so stellt man fest, daß
die Mehrzahl der Interviewten jenseits von Textverarbeitung und Entwicklungsumgebung
keine weitergehenden Werkzeuge einsetzen. Die fortgeschrittenste Verwendung von Werkzeugen
findet man noch in der Entwurfsphase, hier wird durch gezieltes Nachfragen jedoch
schnell klar, daß die Werkzeuge dort meist lediglich als spezialisierter Ersatz für ein Zeichenprogramm
verwendet werden, erkennbar an der Tatsache, daß weniger als 10% die erstellten
Diagramme und Beschreibungen für weitere Entwicklungsschritte verwenden. Selbst Codegenerierung
ist sehr wenig verbreitet und beschränkt sich tatsächlich auf wenige spezialisierte
Teilgebiete, wie beispielsweise Generatoren für Benutzerschnittstellen.
100
90
80
70
60
50
40
30
20
10
0
100
90
80
70
60
50
40
30
20
10
0
Analyse Design Implementierung
Design Implementierung
44 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion
100
90
80
70
60
50
40
30
20
10
0
100
90
80
70
60
50
40
30
20
10
0
Design Implementierung
Design Implementierung
Abbildung 15. Übersicht über Werkzeugeinsatz

Die Ursache liegt aber nicht nur an fehlender Kenntnis der Möglichkeiten, oder Ablehnung
moderner Techniken, sondern auch daran, daß die meisten Werkzeuge ungeeignet erscheinen,
die mit ihnen gewonnenen Ergebnisse in eine spätere Entwicklungsphase und damit möglicherweise
in ein anderes Werkzeug zu exportieren. Die Durchgängigkeit der Werkzeuge,
sprich also die Übernahme von Arbeitsergebnissen in andere Phasen und Werkzeuge wird in
den meisten Fällen als praktisch nicht existent oder schlecht angegeben.
So ist es eigentlich auch nicht verwunderlich, daß die umgekehrte Richtung, also die Rückwärtsverfolgbarkeit
eines Entwicklungsergebnisses bis auf die korrespondierende ursprüngliche
Anforderung praktisch nirgends verwirklicht werden kann.
Der Systementwurf insgesamt findet also weitesgehend informell und wenig ausgeprägt statt.
Viele Entwurfsentscheidung sind schlecht oder gar nicht dokumentiert, weshalb es auch wenig
verwunderlich erscheint, daß Wiederverwendung, oder von vorne herein bausteinorientierte
Entwicklung auf der Basis definierter anwendungsspezifischer Standardarchitekturen bis auf
sehr wenige Ausnahmen so gut wie keine Rolle spielt. Wiederverwendung findet meist nur auf
Basis manuell modifizierter Quellcodemodule statt. Im vorausgehenden Entwicklungsprozeß
werden für solche Module auch nur die Neuerungen analysiert und deren Entwurf dokumentiert,
nicht aber das Gesamtsystem durch Wiederverwendung der korrespondierenden Analyse
und Entwurfsdokumentation der verwendeten Bausteine.
Besondere Anforderungen Eingebetteter Systeme - Echtzeit
100
90
80
70
60
50
40
30
20
10
0
keine untergeordnet wichtig zentral Beschreibung
Abbildung 16. Rolle der Echtzeitanforderungen
Im Zuge der Befragungen sollten ebenfalls die besonderen Anforderungen der Softwareentwicklung
für eingebettete Systeme ermittelt werden. Etwa 70% der Befragten gaben an, daß
Echtzeitanforderungen in ihrem Entwicklungsprozeß eine zentrale oder wichtige Rolle spielen.
Nur für weniger als 10% spielen Echtzeitanforderungen keine Rolle (Abbildung 16).
Erschreckend dabei ist die Tatsache, daß nur etwa 30% derer, für die Echtzeitanforderungen
irgendeine Rolle spielen, diese auch in irgendeiner Form beschreiben. Der Rest verläßt sich
offensichtlich auf die Erfahrung und Intuition seiner Entwickler, beziehungsweise löst die
Echtzeitproblematik mittels Versuch und Irrtum.
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 45

Güte des Einsatzes von Beschreibungstechniken
Abschließend ist festzustellen, daß nur etwa 30% der Befragten alle wesentlichen Eigenschaf-
100
90
80
70
60
50
40
30
20
10
0
vollständig,
durchgängig
vollständig
wesentliche
Eigenschaften
rudimentär/schwer
kommunizierbar
kaum
vorhanden/nicht
kommunizierbar
Abbildung 17. Wie gut ist der Einsatz von Beschreibungstechniken
ten des Systems beschreiben. Nur etwa 5% der Befragten lieferen eine vollständige nicht informelle
Beschreibung ab, die als Basis für moderne Werkzeugtechnologien wie beispielsweise
Simulation nötig wären. Etwa die gleiche Anzahl Befragter gab an, sich komplett auf informelle
Beschreibung stützt, oder überhaupt nichts zu dokumentieren.
Eine vollständige integrierte und durchgängige Beschreibung etwa für automatische Überprüfung
der Stimmigkeit findet sich nirgends
Zusammenfassung Ist-Zustand
• Einsatz isolierter Werkzeuge und isolierter Beschreibungstechniken zur Veranschaulichung
bzw. Entwicklerkommunikation liegt im Ermessen der Entwickler
• Einsatz von Beschreibungstechniken hautsächlich in der Analyse und im Grobdesign
• Favorisierte Beschreibungstechniken sind Automaten, Architekturdarstellungen und Klassendiagramme
(nur zusammen mit Werkzeug)
• Eine Modularisierung der Systementwicklung findet wenn überhaupt nur informell statt
(nicht durch besondere BT oder Werkzeuge unterstützt)
• Kein effektiver Einsatz von Codegenerierung
• Echtzeitanforderungen spielen eine wichtige Rolle, werden aber oft nicht methodisch erfaßt
46 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion
kein

Probleme
Keine Vorschriften für den Einsatz von Beschreibungstechniken & Werkzeugen
Die bei der Dokumentation des vorgefundenen Ist-Zustandes ermittelte mangelnde Festschreibung
des Beschreibungstechnik- und Werkzeugeinsatzes hat mehrere Gründen. Zunächst gibt
es ganz triviale Ursachen, wie daß ein Kunde bestimmte Techniken und Werkzeuge vorschreibt,
weil er das Produkt selbst in seinen eigenen Entwicklungsprozeß integrieren muß. Für
Firmen mit einer großen Anzahl unterschiedlicher Kunden stellt dies das Hauptproblem dar,
weniger die mangelnde Kenntnis des Marktes der Beschreibungstechniken und Werkzeuge.
Ist dagegen nicht vorgegeben, welche Beschreibungstechniken und Werkzeuge verwendet
werden, dann liegt dies meist an einem mangelhaften Problembewußtsein der technisch Verantwortlichen.
Diese halten Beschreibungstechniken und Werkzeuge entweder für wenig wirksam
und sehen sie lediglich als Spielzeug an, mit dem Entwickler bei Laune gehalten werden,
oder trauen sich nicht zu, eine gemeinsame Entscheidung zu forcieren, weil ihnen die Zeit oder
die Fähigkeit fehlt, sich intensiv mit der Materie auseinanderzusetzen.
Fehlende Berücksichtigung der Besonderheiten eingebetteter Systeme
Wird tatsächlich versucht, Beschreibungstechniken ernsthaft einzusetzen, wird manchmal festgestellt,
daß die vorhandenen Techniken mehr auf die Entwicklung großer Anwendungsprogramme
zugeschnitten sind und die Besonderheiten von eingebetteten Systemen nicht, oder
nur unzureichend berücksichtigen. Echtzeitanforderungen werden an dieser Stelle immer wieder
als Problemgebiet genannt. Leider sind die betrachteten Domänen in ihren Anforderungen
selbst in sich sehr stark zersplittert. Fast jeder Befragte konnte spezielle Anforderungen nennen,
die nur für seine ganz spezielle Situation anwendbar und von vorhandenen Methoden und
Werkzeugen nicht befriedigend gelöst worden waren.
Hier wird neben dem oft fehlenden Problembewußtsein eine weitere Problematik am Ursprung
der sich aufspannenden Wirkungskette aus Problemen sichtbar. Direkt über der Abstraktionsebene
der Kodierung wird von gängigen Techniken und Werkzeugen lediglich eine weitere
Abstraktionsebene eingeführt, die dann alle vorhandenen Probleme für alle existierenden
Domänen lösen soll. Von der Komplexität und des zu betreibenden Aufwandes ist dies natürlich
nicht möglich. Daher beschränken sich die angebotenen Lösungen generell auf einen vergleichsweise
kleinen Ausschnitt an Domänen, die bisher zahlenmäßig eine Mehrheit stellen.
Viele Anwendungsbereiche eingebetteter Systeme gehören aber nicht in diese Gruppe, vor
allem auch, weil sie in sich zu inhomogen sind, um nach außen hin als eine größere Interessengruppe
aufzutreten. Weiterhin mangelt es existierenden Techniken und Werkzeugen an offenen
Schnittstellen, die es ermöglichen würden, nur die jeweils domänenspezifischen Anforderungslösungen
zu ergänzen. Das nicht Vorhandensein offener Schnittstellen liegt an der Tatsache,
daß eben nur eine weitere Abstraktionsschicht eingezogen wurde, die eine in sich
geschlossene Lösung darstellt und damit nicht auf gleicher Ebene erweitert werden kann. Dies
führt dann dazu, daß eine domänenspezifische Anpassung der Abstraktion von Umfang und
Aufwand zu groß und damit für die Betroffenen unwirtschaftlich ist.
Schlechte Qualität der Werkzeuge
Selbst für diejenigen, die keine domänenspezifischen Anforderungen haben, stellt sich das
Problem, daß käuflich zu erwerbende Werkzeuge einerseits unwirtschaftlich, andererseits von
schlechter Qualität oder mangelhafter Integration sind.
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 47

Unwirtschaftlich sind diese Werkzeuge deshalb, weil die Gesamtkosten von Werkzeugbeschaffungen,
also Anschaffungspreis, Support- und Schulungskosten die Budgets von kleineren
Projekten bei weitem übersteigen. Dies gilt um so mehr, da die Werkzeuge oft nur eine Teilaufgabe
mehr schlecht als recht lösen, es andererseits aber effektiv verhinden, daß für die nicht
gelösten Teile der Aufgabe andere Werkzeuge eingesetzt, oder die Ergebnisse weiter in einen
ganz anderen Entwicklungsschritt übernommen werden können. Das Angebot von Werkzeugen
konzentriert sich zudem auf die Bereiche des Entwicklungsprozesses, die einfach in ein
Werkzeug zu implementieren sind. Für die schwierigen Teile des Entwicklungsprozesses, wie
beispielsweise Analyse und Test gibt es nur sehr wenig Werkzeugunterstützung.
Dies führt letzten Endes dazu, daß durch die angebotenen Werkzeuge das bereits vorhandene
Übergewicht des Feindesigns und der Implementierung durch den traditionellen Entwicklungsprozeß
von eingebetteten Systemen noch verstärkt wird, die Werkzeuge also eher einen
Multiplikator für die grundlegenden Probleme darstellen, anstatt diese abzuschwächen.
Zusammenfassung der Probleme
• Beschreibungstechniken:
+ Unterschiedliche Endkundenanforderungen
+ Fehlende Kenntnis der Möglichkeiten
+ Grad des Einsatzes jedem Entwickler freigestellt (fehlendes Problembewußtsein)
+ Mangelhafte Werkzeugunterstützung
+ Nicht immer auf Anwendungsgebiet zugeschnitten
• Werkzeuge:
+ Mangelhafte Integration
+ Einführungskosten zu hoch & laufende Kosten zu hoch => unwirtschaftlich
+ Fehlender Überblick über einen dynamischen Markt
+ Qualität der Werkzeuge schlecht
+ Wenig Werkzeuge für Analyse und Test
• Davon abhängige Probleme:
+ Keine phasenübergreifende Vorwärts- und Rückwärtsverfolgbarkeit
+ Übergewicht Feindesign/ Implementierung
+ Qualitätsprobleme, wenig Wiederverwendung und Bausteinorientierung, hohe Kosten
Handlungsbedarf aus Sicht der Unternehmen
Von den Befragten wurden die folgenden Vorschläge als Handlungsbedarf identifiziert:
Stärkerer Einsatz von Informatikern
Ausgenommen die reinen Softwaredienstleister beschäftigen die meisten der befragten Firmen
bis auf wenige Ausnahmen keine Informatiker. Die meisten der mit Software beauftragten Mitarbeiter
kommen aus anderen Sparten und haben sich die notwendigen Kenntnisse selbst erarbeitet.
Von einigen Befragten wird die Befürchtung geäußert, daß diese Mitarbeiter nicht ausreichend
in abstraktem Denken geschult sind und über kein breites Grundwissen an Methoden verfügen
48 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

und die Einstellung oder Beratung eines Informatikers vielleicht Abhilfe schaffen könnte,
wenn dieser den Markt der verfügbaren Methoden und Werkzeuge genau kennt und die notwendigen
Innovationsimpulse geben könnte.
Förderung von Wissenstransfer
Von vielen Befragten wird der Austausch von Erfahrungen zwischen gleichartigen Firmen
einer Anwendungsdomäne gewünscht. Dies muß nicht auf den Erfahrungsaustausch, welche
Werkzeuge und Methoden gut einsatzbar sind, beschränkt bleiben, sondern bezieht sich auch
auf die vielen Speziallösungen die in vielen Firmen für den Eigenbedarf entwickelt wurden.
Oft fehlen aber selbst die relativ geringen Mittel, diese Lösungen so weiter zu entwickeln, daß
sie auch von anderen eingesetzt werden können.
Ebenso wird beklagt, daß der Kontakt zwischen Universtäten und dem Mittelstand sehr
schlecht ist (da eine mittelständische Firma alleine keine großen Forschungsprojekte finanzieren
kann) beziehungsweise, daß die universitäre Forschung zu wenig anwendungsorientiert
arbeitet und nicht daran interessiert ist, anwendungsspezifische Lösungsvarianten für ein prinzipiell
bereits gelöstes Problem zu erforschen
Mehr automatische Generierung
Ein Punkt großer Resonanz ist der Wunsch, zwecks Arbeitsersparnis ableitbare Informationen
aus bereits erarbeiteten Ergebnissen gewinnen zu können, konkret beispielsweise aus der
sowieso zu erstellenden Spezifikation Testfälle generieren zu können und diese dazu zu benutzen,
die erstellte Software möglichst automatisch gegen die Spezifikation zu testen.
Berücksichtigung der Besonderheiten des Anwendungsgebietes
Einhellig von fast allen Befragten wird gewünscht, die Besonderheiten ihres Anwendungsgebietes
stärker zu berücksichtigen. Die meisten existierenden Werkzeuge und Methodiken versuchen
eine möglichst große Zahl von Anwendern zu erreichen, was dazu führt, daß sie groß,
unhandlich und teuer werden, dabei der Nutzeffekt für einen einzelnen Anwender jedoch nur
sehr gering ist, besonders wenn er sich auf einem Gebiet abseits klassischer Anwendungsentwicklung
bewegt.
Ein gutes Beispiel dafür ist die Codegenerierung, also die automatische Erzeugung von Quellcode
aus einer vorher erstellten Spezifikation des Programms. Die Ergebnisse sind, wenn überhaupt
brauchbar nicht optimiert und damit ungeeignet für Plattformen, deren Ressourcen
eingeschränkt sind, was im Bereich der eingebetteten Systeme aber fast immer der Fall ist.
Eine weitere Besonderheit von eingebetteten Systemen sind Echtzeitanforderungen. Nicht nur,
daß diese Anforderungen in geeigneter Weise beschrieben können müßten, die Beschreibung
sollte dann ebenfalls auch bei der Codegenerierung berücksichtigt werden.
Beschreibungstechniken verbessern
Bei den vorhandenen Beschreibungstechniken wird oft bemängelt, daß sie nicht immer ausreichend
praxistauglich sind. Das kann bedeuten, daß ihr Einsatz unwirtschaftlich ist, das heißt
die Relation an aufgewendeten Mitteln im Vergleich zu den Vorteilen zu schlecht ist, daß wichtige
Aspekte nicht oder nicht ausreichend beschrieben werden können, oder schlicht, daß die
Beschreibungstechnik für die angestrebten Zielgruppen nicht ausreichend leicht verständlich
oder erlernbar ist.
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 49

Zusammenfassung Handlungsbedarf
• Stärkerer Einsatz von Informatikern
+ Innovationsimpulse, Technologiebeobachtung, Methodiken
• Förderung von Wissenstransfer
+ Domänenspezifische Erfahrungen mit Werkzeugen allen zugänglich machen
+ Kooperation/Mittel um domänenspezifisches Know-How in spezialisierten Werkzeugen/
Methodiken zu realisieren
• Mehr automatische Generierung
+ Dokumentation & Testfälle aus Spezifikation
+ Werkzeuge für (semi-)automatische Tests
• Berücksichtigung der Besonderheiten des Anwendungsgebietes
+ Spezialisierung und Integration von Werkzeugen, Beschreibungstechniken und Vorgehensmodellen
+ Ressourcensparendere Codegenerierung
+ Echtzeitanforderungen stärker berücksichtigen (auch bei Codegenerierung)
• Beschreibungstechniken verbessern
+ Praxistauglicher/verständlicher für Nichtinformatiker gestalten
+ Echtzeitanforderungen unterstützen
50 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

4 Zukunftsszenarien - Ergebnisse einer Szenario-Analyse
Anhand der Befragung der Unternehmen lassen in erster Linie nur Defizite und Verbesserungspotentiale
in Hinblick auf den aktuellen Stand der Technik ermitteln. Damit können naturgemäß
auch nur Maßnahmen mit vergleichsweise kurzfristigem Charakter ermittelt werden. Um
Maßnahmen mit strategischem Charakter ableiten zu können, müssen bei der Erhebung der
Aufgabenfeldbeschreibung stärker zukünftige Entwicklungen berücksichtigt werden. Hierzu
wurde die Szenariotechnik eingesetzt, um zukünftige Entwicklungen miteinplanen zu können.
Die Szenarien werden aufgrund der Aufgabenstellung der Vordringlichen Aktion in den
Lösungsansätzen in Abschnitt 5 nur insoweit berücksichtigt, soweit sie durch Handlungsmaßnahmen
innerhalb einer Laufzeit von bis zu vier Jahren integriert werden können. Jedoch
machen die Szenarien deutlich, daß durch die sich weiter beschleunigende Entwicklung der
Informationstechnologie der bereits eingesetzte Wandel in den Bereichen Produktions- und
Automatisierungtechnik, Maschinen- und Anlagenbau und Verkehrstechnik sich weiter verstärken
wird. Zur Sicherung der Wettwerbsfähigkeit müssen daher schon jetzt sich abzeichneden
Entwicklungen von den Unternehmen dieser Bereiche berücksichtigt werden müssen.
Wir befinden uns in einem tiefgreifenden Wandel von der Industriegesellschaft zur globalen
Informationsgesellschaft. Haupttreiber dieses Wandels sind die rasante Entwicklung von Technologien
- allen voran die Informations- und Kommunikationstechnologie - und die Globalisierung.
Auch in Zukunft wird sich der Lebensstandard einer hochentwickelten Nation auf der
Fähigkeit begründen, innovative Industrieerzeugnisse hervorzubringen und auf dem Weltmarkt
mit Gewinn zu verkaufen. In der Informationsgesellschaft hat die industrielle Produktion also
nach wie vor eine Schlüsselstellung, es finden nur weniger Menschen Beschäftigung in diesem
Bereich.
Im Vordergrund der Bemühungen, die Zukunft zu gestalten, müssen Produktinnovationen und
damit einhergehende Dienstleistungsinnovationen stehen. Ein hohes Lohnkostenniveau erfordert
adäquate Spitzenleistungen an Kreativität und industrieller Wertschöpfung. Auf dem Weg
zu den Produkten und Märkten von morgen, wird es den Unternehmen kaum weiterhelfen, die
Kunden und den Vertrieb zu befragen. Sie fordern oft Problemlösungen aus heutiger Sicht und
zeichnen sich häufig durch eine gewisse Phantasielosigkeit aus. Wer die Probleme von heute
löst, hat noch lange nicht die Herausforderungen von morgen bewältigt (Bild 18). Diese ergeben
sich aus heute wahrnehmbaren Entwicklungen wie die zunehmende Betonung der nachhaltigen
Entwicklung (Sustainable Development) und der Verbreitung der Informations- und
Kommunikationstechnik 1 . Beispielsweise ist damit zu rechnen, daß im Jahre 2020 ein Tischrechner
die Leistung aufweist, die heute alle Rechner in Silicon Valley zusammen haben 2 , und
daß in einigen Jahren voll kommunikationsfähige Sensoren und Mikroprozessoren zum Preis
einer Schraube erhältlich sind. Die Möglichkeiten dieser Entwicklungen scheinen nur durch
unsere Vorstellungskraft begrenzt zu sein. Es ist unbestritten, daß die dargestellte Entwicklung
im Wechselspiel mit der Globalisierung das Geschäft der Schlüsselbranchen wie den Maschinen-
und Anlagenbau, die Automobilindustrie und die Elektroindustrie stark beeinflussen werden.
Es zeichnen sich neue faszinierende Möglichkeiten zur Gestaltung der Produkte und
Dienstleistungen von morgen ab.
1. Schmidheiny, S.: Kurswechsel - Globale unternehmerische Perspektiven für Entwicklung und Umwelt. Artemis-Verlag,
1992
2. Patterson, David A: Mikroprozessoren im Jahre 2020; in: Spektrum der Wissenschaft, Spezial 4: Schlüsseltechnologien,
S. 14-17
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 51

Abbildung 18. Kreativität wird eingeengt; Neue Möglichkeiten werden nicht erkannt
Mehr als bisher wird es darauf ankommen, die unternehmerischen Erfolgspotentiale der
Zukunft frühzeitig zu identifizieren und rechtzeitig zu erschließen. Dazu wird eine Methodik
benötigt, die das vernetzte Denken unterstützt und mehrere Entwicklungen von Einflußfaktoren
auf die Zukunft zuläßt. Eine solche Methodik ist die Szenario-Technik 1 . Dabei geht es nach
Kurt Sontheimer weniger um das Voraussagen, sondern mehr um das Vorausdenken der
Zukunft. Und genau das sollten die Unternehmen tun, um Agilität beim Wettlauf um Produkte
und Märkte von morgen zu entwickeln. Angesichts des rasanten Wandels und der Turbulenz in
den globalen Märkten fällt es zwar vielfach schwer, sich systematisch mit der Zukunft zu
befassen - es nicht zu tun wäre aber in den meisten Fällen fahrlässig. Es wäre nichts anderes,
als wenn ein Autofahrer mit hoher Geschwindigkeit auf einer kurvenreichen Bergstraße fährt
und glaubt, er könne die Spitze erreichen, indem er ausschließlich in den Rückspiegel sieht.
Natürlich wird uns die Zukunft immer überraschen - aber sie sollte uns nicht überrumpeln
(Buckminster Fuller).
4.1 Einordnung der Zukunftsszenarien in die VA
Von strategisch hoher Bedeutung ist das Ermitteln der Anforderungen von morgen für die Entwicklung,
Produktion und den Service von Software in eingebetteten Systemen sowie die
Erschließung zukünftiger Erfolgspotenziale. Die Betrachtung und Lösung der heute offenstehenden
Probleme reicht angesichts der sehr dynamischen technologischen Entwicklung mit
Sicherheit nicht aus, die Herausforderungen der Zukunft zu bewältigen. Im Rahmen der VA
wurden daher Zukunftsszeanrien entwickelt, um heute wahrnehmbare Entwicklungen zu antizipieren
und zu schlüssigen Zukunftsbildern (Szenarien) zu verknüpfen. Wichtig ist in diesem
Zusammenhang, eine größere Anzahl von Einflußfaktoren aus den Bereichen Technologie -
insbesondere Softwaretechnologie und Kommunikationtechnologie -, Branchen und Märkte
und deren Vernetzung zu berücksichtigen sowie mehrere Entwicklungen eines Einflußfaktors
1. Gausemeier, J. / Fink, A. / Schlake, O.: Szenario-Management - Planen und Führen mit Szenarien. 2. Auflage,
Carl Hanser Verlag, München, 1996
Fahey, L. / Randall, R.M.: Learning from the future. Competitive Foresight Scenarios. Wiley, New York, 1998
52 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

ins Kalkühl zu ziehen. Als Betrachtungszeitraum für diese Entwicklungen liegt den Szenarien
das Jahr 2008 zugrunde.
4.2 Szenarien der Vordringlichen Aktion
Im folgenden werden die für die Themengebiete der Vordringlichen Aktion bedeutsamen
Zukunftszenarien beschrieben. Da für die Szenarien je nach Themengebiet unterschiedliche
Schlüsselfaktoren anwendbar sind, werden sie nach Themengebiete gegliedert wiedergegeben.
Die Szenarien sind allgemeinverständlich beschrieben. Die Technik zur Ermitllung solcher
Zukunftszenarien ist sehr komplex. Um einerseits den Lesefluß nicht zu unterbrechen, aber
andererseits ausreichend Information über die Szenariotechnik und damit die Plausibilität der
erstellten Szenarien zur Verfügung zu stellen, wird das Verfahren zur Ermittlung von Zukunftszenarien
im Detail in Abschnitt 8 beschrieben.
4.2.1 Szenarien des Anlagen- und Maschinenbaus
Die Szenarien des Anlagen- und Maschinenbaus beruhen auf den Zukunftsprojektionen und
Konsistenzwertungen der ausgewählten Schlüsselfaktoren für diese Anwendungsdomäne. Die
Auswertung des Scree-Diagramm führt zu einer Clusterung von insgesamt fünf Szeanrien.
Diese sind nachfolgend beschrieben.
Szenario 4
Mechatronischer Modulmarkt
auf dem Vormarsch
Szenario 1
Massiver IT-Einsatz im
modernen Maschinenbau
Szenario 3
Mangelnder Innovationsschutz im
zukunftsorientierten Maschinenbau
Szenario 2
Intelligente Maschinennetzwerke
Szenario 5
Hi-Tech-Anlagen und -Maschinen
nur für Spezialanwendungen
Abbildung 19. Zukunftsraum-Mapping der fünf Szenarien des Anlagen- und Maschinenbaus
Szenario 1 „Massiver IT-Einsatz im modernen Anlagen- und Maschinenbau“
In den Produkten des Anlagen- und Maschinenbaus ist Software nicht mehr wegzudenken.
Software bestimmt Funktionalität und Kundennutzen entscheidend. Ein erheblicher Anteil der
Wertschöpfung entfällt auf Software. Sie ist kaufentscheidend, denn globale Hochleistungsnetze
für Kommunikation erlauben dank der hohen Bandbreiten, jede Maschine am jedem Ort
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 53

dieser Erde mit einer beliebigen anderen, Steuerinformationen auszutauschen. Die informationstechnische
Anbindung erlaubt vor allem auch die Verarbeitung von Expertensystemen, die
inzwischen überall Einsatz finden. Effiziente Entwicklungsumgebungen lassen den Software-
Anteil der Maschinen schnell und sicher produzieren. Ingenieure „bedienen” sich einfach bei
Software-Brokern und erhalten postwendend Module für ihre Anwendungszwecke. Diese einfachen
Entwicklungsvoraussetzungen sowie die übergreifenden Standards und Normen der IT
bringen ständig neue Anbieter hervor. Sie bringen frischen Wind in verkrustete Wettbewerbsstrukturen.
Neuartige Post Sales Services bestimmen ebenso das Bild wie eine nicht enden
wollende Reihe von Innovationserfolgen, die aufgrund des wirksamen Patentsystems eine ausreichenden
Pioniervorsprung sichern. Attraktive Arbeitsplätze auf hohem technischen Niveau
werden geschaffen.
1 Kommunikationsnetze
2 Autonome vern. mecha. Systeme Mechatronischer Ameisenhaufen [74] Massenware “AMS” [24]
3 Tool Support
Breite Palette hochwertiger Entwicklungsumgebungen [92]
4 HW / SW Co Design
Neues Selbstverständnis der integrierten Systementwicklung [88]
5 Softwareengineering
Softwarearchitekten der neuen Generation [91]
6 Wissensmanagement
XPS durchdringen den Alltag [79]
7 FuE
FuE strategisch entscheidend [39] Signifikant höhere Invest. beider Seiten [61]
8 Globalisierung der Produktion Verteilte Wirtschaftsräume mit Eigenfokus [83]
9 Bildungssystem
Breite Spitze hochqualifizierender Ausbildungsformen [91]
10 Innovationsdynamik
Dynamische Entwicklung mit Erfolg [100]
11 Standards und Normen der IT Übergreifende Standards [95]
12 Neue Märkte/Marktformen Dynamischer Modulmarkt [92]
13 Post Sales Services
Tele-Konfiguration ohne Service-Techniker [85]
14 Qualitäts- und Sicherheitsanford. Qualität und Sicherheit nicht kaufentscheidend [92]
15 Wettbewerbsintensität
Innovative Anbieter frischen Wettbewerb auf [100]
16 Schutz von technol. Vorsprung Wirksames Patentsystem [91]
17 Struktur der Software-Anbieter Einige Key-Player mit h. Reifegrad [82]
Abbildung 20. Ausprägungsliste Szenario 1 „Massiver IT-Einsatz im modernen
Maschinenbau
Szenario 2 „Intelligente Maschinennetzwerke“
Globale Hochleistungsnetze für Kommunikation [91]
Die Metapher des “Mechatronsichen Ameisenhaufens” verkörpert das neue Selbstverständnis
unter den Anlagen- und Maschinenbauern. Autonome vernetzte mechatronische Systeme bilden
die Komponenten heutiger Maschinen und Anlagen. Integrierte Systementwicklung und
professioneller Umgang mit der Softwareentwicklung sind die Lorbeeren der Forschungs- und
Ausbildungsbemühungen der vergangenen Jahre. Partiell intelligente Maschinen werden allerdings
nur in prosperierenden Wirtschaftsregionen nachgefragt. Ein diversifizierter Modulmarkt
mit vielen Anbietern kann sich nur schwer entwickeln. Einerseits wünschen die Kunden
eine stärkere Integration in ihr Prozeßdenken, andererseits spielt der Preis nur eine sekundäre
Rolle. Qualität ist vorentscheidend. Zudem sorgt das wirksame Patentsystem dabei für ein stabiles
Wettbewerbsgefüge mit überschaubarer aber erfolgreicher Eigendynamik.
Szenario 3 „Mangelnder Ideenschutz im zukunftsorientiertem Maschinenbau“
Unternehmer bezeichnen die Situation im Anlagen- und Maschinenbau als “Haifischbecken
voller Ideen”. Während die einen schwer mit von der Konkurrenz kopierten Produkten zu
kämpfen haben, sehen andere genau hier ihre Chancen. Schnelligkeit und innovativer Vorsprung
gewinnen das Rennen um die Gunst der Kunden. Software-Architekten der neuen
54 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

1 Kommunikationsnetze
2 Autonome vern. mecha. Systeme
3 Tool Support Support
4 HW / SW Co Design
Globale Hochleistungsn. für Kommunik. [52] Hochleistungsn. für Hi-Tech Reg. [36]
Mechatronischer Ameisenhaufen [84]
Breite Palette hochwertiger Entwicklungsumgebungen [96]
Neues Selbstverständnis der integrierten Systementwicklung [96]
5 Softwareengineering
Software-Architekten der neuen Generation [88]
6 Wissensmanagement
Klassifikation nur anhand sicherem Wissen [72] XPS durchdringen den Alltag [24]
7 FuE
FuE strategisch entscheident [24] Signifikant höhere Investitionen [76]
8 Globalisierung der Produktion Verteilte Wirtschaftsräume mit Eigenfokus [88]
9 Bildungssystem
Breite Spitze hochqualifizierender Ausbildungsformen [100 ]
10 Innovationsdynamik
Dynamische Entwicklung mit Erfolg [76]
11 Standards und Normen der IT Übergreifende Standards [100]
12 Neue Märkte/Marktformen Dynam. Modulmarkt [32] Käuferm. v. höhere Integ. in das Prozess Know-how [44]
13 Post Sales Services
Tele-Konfiguration ohne Service Techniker [88]
14 Qualitäts- und Sicherheitsanford. Hohes Maß an Qualität gefordert - Preis sekundär [100]
15 Wettbewerbsintensität
Stabiles Wettbewerbsgefüge [100]
16 Schutz von technol. Vorsprung Wirksames Patentsystem [100]
17 Struktur der Software-Anbieter Einige Key-Player mit hohem Reifegrad [100]
Abbildung 21. Ausprägungsliste Anlagen- und Maschinenbau Szenario 2: „Intelligente
Maschinennetzwerke“
Generation, integrierte Systementwicklung und online Wissensmanagement lassen die Branche
sich rasant weiterentwickeln. Mangelnde Einhaltbarkeit des Patentschutzes aber sorgt für
eine Art Selbstbedienungsladen der Produktentwicklung. Die Industrie stellt ihre Aufwendungen
für Forschung- und Entwicklung vielerorts in Frage. Nur die vermeintlich Großen können
mit ihrem finanziellem Stehvermögen Entwicklungsflops unbeschadet verkraften. Insbesondere
junge, agressive Unternehmen profitieren von den Gepflogenheiten des Marktes. Zusätzlich
brauchen sie nicht auf höchste Qualitäts- und Sicherheitsansprüche Rücksicht nehmen, da
niedrige Preise und Verfügbarkeit kaufentscheidende Faktoren darstellen.
1 Kommunikationsnetze
Globale Hochleistungsnetze für Kommunikation [100]
2 Autonome vern. mecha. Systeme Massenware “AMS” [100]
3 Tool Support
4 HW / SW Co Design
5 Softwareengineering
6 Wissensmanagement
7 FuE
8 Globalisierung der Produktion
9 Bildungssystem
Bildungssystem
10 Innovationsdynamik
11 Standards und Normen der IT
12 Neue Märkte/Marktformen
13 Post Sales Services
14 Qualitäts- und Sicherheitsanford.
15 Wettbewerbsintensität
16 Schutz von technol. Vorsprung
17 Struktur der Software-Anbieter
Breite Palette hochwertiger Entwicklungsumgebungen [100]
Integrierte Systementwicklung nicht standesgemäß [100]
Software-Architekten der neuen Generation [100]
XPS durchdringen den Alltag [100]
Nutzen der FuE seitens der Industrie in Frage gestellt [100]
Aufwind der Schwellenländer durch steig. Qualität der Arbeitskräfte [100]
Breite Spitze hochqualifizierender Ausbildungsformen [100]
Dynamische Entwicklung mit Erfolg [100]
Übergreifende Standards [100]
Dynamischer Modulmarkt [100]
Ferndiagnose- und Softwaredienste [67] Tele-Konfig. ohne Service Techniker [33]
Qualität und Sicherheit nicht kaufentscheidend [100]
Innovative Anbieter frischen Wettbewerb auf [100]
“Haifischbecken“ voller Ideen
Einige Key-Player mit h. Reifeg. [67] Open-Source statt teuere SW-Lizenzen [33]
Abbildung 22. Ausprägungsliste Anlagen- und Maschinebau Szenario 3 „Mangelnder
Innovationsschutz im zukunftsorientiertem Maschinenbau“
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 55

Szenario 4: „Mechatronischer Modulmarkt auf dem Vormasch“
Die stürmische Weiterentwicklung der Kommunikationstechnik in Richtung hoher Bandbreiten
ermöglicht völlig neue Anwendungen über Kommunikationsnetze zu betreiben. Zudem ist
das Preis/Leistungsverhältnis der Kommunikationsanwendungen so attraktiv, dass es zu einem
massiven Ausbau der Telekommunikation kommt. Individuelle, mobile Kommunikationseinrichtungen
ermöglichen eine sichere Kommunikation beliebiger Personen und technischer Produkte
rund um die Welt. Hohe Bandbreiten erlauben den effizienten Einsatz von technischen
Applikationen über die Netze. Durch die Vernetzung entsteht ein globales Dorf. Autonome
vernetzte mechatronische Systeme gehören zum State-of-the-art moderner Industrieerzeugnisse.
Ihre Verbreitung ist dank ihrer günstigen Realisierung durch flexible Module/Komponenten
rasant. Allerdings werden sie nur innerhalb von sicherheitsunkritischen Systemen
eingesetzt wie beispielsweise dem intelligentem Haus. Komplexe Systeme mit Echtzeitanforderungen
im Millisekundenbereich sind derzeit noch nicht ausreichend zuverlässig aufgrund
mangelnder Garantie des Antwortzeitverhaltens einzelner Komponenten. Der Schutz technischen
Vorsprung kann allerdings nicht wirksam gewährleistet werden. Als Folge entsteht ein
floriender Modulmarkt, in dem innovative Anbieter den konventionellen Wettbewerb auffrischen.
Sorgenkind in den Entwicklungsabteilungen ist aber nach wie vor die Software. "Feld-Waldund-Wiesen"-Software-Werkzeuge
finden aller Orts in den Entwicklungsabteilungen Einsatz.
Charakteristisch sind ihre geringe Mächtigkeit und immense Spezialisierung auf Sonderfälle.
Die Software-Tool Kosten sind verhältnismäßig gering und bewegen sich im Shareware-
Bereich. Das erklärt auch ihre hohe Verbreitung und Beliebtheit. Allerdings unterstüzten sie
den durchgängigen Entwicklungsprozeß nur mäßig. Dank der Open-Source Philosophie
gelingt es überhaupt Software für mechatronsiche Systeme schnell zu entwickeln. Im großen
und Ganzen bleiben aber komplexerer Aufgabenstellungen software-technisch unbewältig.
1 Kommunikationsnetze
Globale Hochleistungsnetze für Kommunikation [100]
2 Autonome vern. mecha. Systeme Massenware AMS [100]
3
4
5
6
7
8
9
10
11 Standards und Normen der IT
12
13
Tool Tool Support
HW / SW Co Design
Softwareengineering
Wissensmanagement
FuE
Globalisierung der Produktion
Bildungssystem
Innovationsdynamik
Neue Märkte/Marktformen
Post Sales Services
16 Schutz von technol. Vorsprung
17 Struktur der Software-Anbieter
Feld-Wald-und-Wiesen Tools [100]
“Bastellösungen” stillen den Bedarf [100]
Software-technische Komplexität unbewältigt [100]
Klassifikation nur anhand sicherem Wissen [100]
Signifikant höhere Investitionen beider Seiten [100]
Aufwind der Schwellenländer durch steig. Qualität der Arbeitskräfte [100]
Öffentliche Bildungsversorgung gewährleistet [100]
Dynamische Entwicklung mit Erfolg [100]
Übergreifende Standards [100]
Dynamischer Modulmarkt [100]
Ferndiagnose- und Softwaredienste [33] Tele-Konfig. ohne Service Techniker [67]
14 Qualitäts- und Sicherheitsanford. Qualität und Sicherheit nicht kaufentscheident [67] Qualitätskrise [33]
15 Wettbewerbsintensität
Innovative Anbieter frischen Wettbewerb auf [100]
“Haifischbecken” voller Ideen [75]
Open-Source statt teuere SW-Lizenzen [100]
Abbildung 23. Ausprägungsliste Anlagen- und Maschinebau Szenario 4
„Mechatronischer Modulmarkt auf dem Vormarsch“
56 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

Szenario 5: „Hi-Tech-Anlagen und -Maschinen nur für Spezialanwendungen“
Software bestimmt weder Funktionalität noch Kundennutzen entscheidend. Unprofessioneller
Umgang mit Software in der Systementwicklung führte in der letzten Vergangenheit zu vielen
Fehlern. Kunden wünschen ausdrücklich verstärkt nur Basisfunktionalität und haben ihr Vertrauen
in software-dominierte Systeme verloren. Der Mißbrauch von Informationsnetzen und
die mangelnde Qualität in sicherheitsrelevanten Umgebungen wirft einen großen Schatten auf
die allgemeine Akzeptanz hoch-technologisierter Systeme. Softwareentwickler stehen zunehmend
unter Erfolgsdruck. Ein oder zwei dominante Anbieter von Softwareentwicklungswerkzeugen
setzen sich durch. Es gelingt ihnen, über 90% des Bedarfs mit ihren Tools abzudecken.
Die Giganten können sich dem Innovationsdruck durch ihre Machtstellung zeitweise verschließen.
Die Innovationsgeschwindigkeit wird gebremst. Effiziente Entwicklungsumgebungen
sind nur für einen hohen Preis zu erwerben. Phasen- und disziplinübergreifendes Arbeiten
unterstützen sie zwar gut, aber der Aufwand für die Einarbeitung/Schulung ist verhältnismäßig
hoch. Die gesamten Investitionskosten für derartige Entwicklungsumgebungen (Total Costs of
Ownership) sind nur für teure Produktentwicklungen wirtschaftlich.
Standesdenken der einzelnen Ingenieurdiszlipinen verhindert vielerorts die integrierte Systementwicklung.
Da seitens der öffentlichen Bildung nicht mit entscheidenden Impulsen gerechnet
werden kann, treiben die Unternehmen selbstständig viele Grundlegende Enwicklungen an.
Im Rahmen von vorwettbewerblichen Kooperationen gelingt es immerhin, einige - wenn auch
isolierte - Standards zu setzen. Diese ermöglichen zumindest in begrenztem Rahmen Services
wie den Fernbetrieb von stand-alone Anlagen.
Unbedeutende Innovationen und moderate Entwicklung des internationalen Geschäfts sorgen
für stabile Wettbewerbsverhältnisse. Lediglich im High-End Segment des Anlagen- und
Maschinenbaus werden für Spezialanwendungen komplexe mechatronische Systeme integriert,
wo es technisch unabdingbar ist. Die Qualität ist hoch, doch die damit verbundenen
Aufwände sind beachtlich. Hohe Preise sind die Konsequenz.
1 Kommunikationsnetze
Hochleistungsnetze zwischen Hi-Tech Regionen [100]
2 Autonome vern. mecha. Systeme Teuere AMS Lösungen für Spezialgebiete [100]
3
4
5
6
7
8
9
10
11 Standards und Normen der IT
12
13
15
Tool Support Support
HW / SW Co Design
Softwareengineering
Wissensmanagement
FuE
Globalisierung Globalisierung der Produktion
Bildungssystem
Innovationsdynamik
Neue Märkte/Marktformen
Post Sales Services
16 Schutz von technol. Vorsprung
17 Struktur der Software-Anbieter
Entwicklungsumgebungen nur für hochkomplexe Produkte [100]
Integrierte Systementwicklung nicht standesgemäß [100]
Neue Softwarekrise [100]
Komplexität ist für XPS nicht wirtschaftlich durchdringbar [100]
Industrie bewertet FuE als strategisch entscheidend [100]
Verteilte Wirtschaftr. mit Eigenfokus [67] Billiglohnländer g. ins Hintertreffen [33]
Amerikanisches Modell mit privatwirtschaftlicher Förderung [100]
Unbed. Innov. werden umgesetzt [33] Verlangsamung der Innovationsgeschw. [67]
Isolierte Standards [100]
Komplett Lösungsanbieter setzen sich durch [100]
Fernbetrieb von stand-alone Anlagen [100]
14 Qualitäts- und Sicherheitsanford. Hohes Maß an Qualität erforderlich - Preis sekundär [100]
Wettbewerbsintensität
Stabiles Wettbewerbsgefüge [100]
Wirksames Patentsystem [100]
“Microsoft vs. Oracle Variante” [100]
Abbildung 24. Ausprägungsliste Anlagen- und Maschinebau Szenario 5 „Hi-Tech-
Anlagen und -Maschinen nur für Spezialanwendungen“
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 57

Zusammenfassung der Szenarien des Anlagen- und Maschinenbaus
Die Szenarien für den Anlagen- und Maschinenbau verdeutlichen unterschiedliche Zukünfte.
Neben der Entwicklung der Informations- und Kommunikationstechnologie hängt der Erfolg
zukünftiger Anlagen und Maschinen im wesentlichem an effizienten Methoden und Werkzeugen
des Softwareengineerings, der Modularisierung der Produkte sowie dem Vorhandensein
und Einhalten von weitreichenden Standards. Differenzierungen sind vor allem hinsichtlich
betroffener Komponenten und Anwendungen zu erkennen. Sicherheitsrelevante Funktionsgruppen
mit Echtzeitanforderungen können z.B. erst langsam aufgrund der notwendigen
Zuverlässigkeit IT-mäßig vernetzt werden. Kostspielige IT-Anwendungen für den Sondermaschinebau
sind eher denkbar bei vergleichsweisen hohen Entwicklungskosten der Softwarefunktionalität.
Neben den Produkten selbst sind aber auch die Umfeldentwicklungen wie Verfügbarkeit von
effizienter Softwareentwicklungsumgebungen oder wirksame Einhaltung des Patentrechts zu
betrachten. Sie stellen entscheidende Weichen hinsichtlich der Konsistenz der möglichen
Zukunftsbilder. Darüber hinaus muss es der Branche gelingen, ingenieurmäßiges Standesdenken
der Disziplinen durch Offenheit, breitere Bildung sowie Verknüpfung von Informatik und
Maschinebau entgegen zu treten. Letztendlich aber entscheiden die Kunden mit ihren Qualitätsanforderungen
über den Maßstab der Entwicklungsanstrengungen.
4.2.2 Szenarien der Automatisierungs- und Produktionstechnik
Die Szenarien der Automatisierungs- und Produktionstechnik beruhen auf den Zukunftsprojektionen
und Konsistenzwertungen der ausgewählten Schlüsselfaktoren für diese Anwendungsdomäne.
Die Auswertung des Scree-Diagramm führt zu einer Clusterung von insgesamt
fünf Szeanrien. Diese sind nachfolgend beschrieben.
Szenario 1: „Mechatronik beflügelt Automatisierungs- und Produktionsbranche“
Die stürmische Entwicklung der Kommunikationstechnik in Richtung hoher Bandbreiten
ermöglicht völlig neue Anwendungen über Kommunikationsnetze zu betreiben. Autonome
vernetzte mechatronische Systeme gehören zum State-of-the-Art moderner Industrieerzeugnisse.
Sie halten in immer mehr Produkten wie Automobilen oder Weiße Ware Einzug und
agieren zunehmend im Verbund dynamisch und dezentral. Neue Paradigmen der Steuerungsund
Automatisierungstechnik entstehen. Die Beherrschbarkeit selbst komplexer Systeme ist
technisch gewährleistet. Steuerungs- und Regelungseinrichtungen sind in der Regel komplett
vernetzt. Das Spektrum wirtschaftlich erfassbarer physikalischer Größen erlaubt ein einfaches
und umfassendes Telemonitoring. Hersteller bieten online Fehlerbehandlungen mit steigendem
Erfolg an. Die ortsgebundene Wartung nimmt drastisch ab.
Die Wachstumsraten in der Automatisierungs- und Produktionstechnik sind außerordentlich
hoch. Der Siegeszug der Informationstechnik puscht die Unternehmen stetig, Innovationen zu
bringen und die Variantenvielfalt zu erhöhen. Preisdruck herrscht vornehmlich in vereinzelten
Nischen. Insgesamt zeichnet sich ein aufstrebender, dynamischer Markt in einer aufgeklärten
Hi-Tech Gesellschaft ab.
Szenario 2: „Hochkonjunktur bringt neue Anbieter hervor“
Die IuK-Branche boomt. Im Sog der IuK-Branche gewinnt auch die Automatisierungs- und
Produktionstechnik-Branche rasant an Fahrt. IuK-Unternehmen entdecken in der Automatisie-
58 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

Szenario4
Konzentration durch
intelligente Massenprodukte
Szenario2
Hochkonjunktur bringt
neue Anbieterhervor
Szenario1
Mechatronik beflügelt
Automatisierungs- und
Produktionstechnik-Branche
Szenario5
Erklärungsbedürftige Produkte
verhindern die Verbreitung
elektronischer Vertriebskanäle
Szenario3
Software-Krise hemmt
innovative Entwicklungen
Abbildung 25. Zukunftsraum-Mapping der fünf Szenarien der Automatisierungs- und
Produktionstechnik
1 Kommunikationsnetze
Globale Hochleistungsnetze für Kommunikation [78]
2 Autonome vern. mecha. Systeme Mechatronischer Ameisenhaufen [86]
3 Tool Support
Breite Palette hochwertiger Entwicklungsmöglichkeiten [96]
4 HW / SW Co Design
Neues Selbstverständnis der integrierten Systementwicklung[100]
5 Softwareengineering
Softwarearchitekten der neuen Generation [100]
6 Wissensmanagement
XPS durchdringen den Alltag [81]
7 FuE
FuE strategisch entscheidend [39] Signifikant höhere Invest. beider Seiten [61]
8 Globalisierung der Produktion Verteilte Wirtschaftsräume mit Eigenfokus [90]
9 Bildungssystem
Bildungssystem
Breite Spitze hoch qualifizierender Ausbildungsformen [91]
10 Technologieakzeptanz
Aufgeklärte Hi Tech Gesellschaft [87]
11 Standards und Normen der IT Übergreifende Standards [96]
12 Neue Märkte/Marktformen Diversifikation und Dynamiksteigen rasant [87]
13 Post Sales Services
Online Fehlerbehebung [87]
14 Qualitäts- und Sicherheitsanford. Hohe MTBF wird vorausgesetzt [86]
15 Wettbewerbsintensität
Diversifizierte Märkte voller NIschenprodukte [87]
16 Schutz von technol. Vorsprung Wirksames Patentsystem [96]
17 Struktur der Software-Anbieter Einige Key-Player mit h. Reifeg. [71] Open-Spurce statt teuere SW Lizenzen [25]
Abbildung 26. Ausprägungsliste Automatisierungs- und Produktionstechnik
Szenario 1 „Mechatronik beflügelt Automatisierungs- und Produktionsbranche“
rungs- und Produktionstechnik neue strategische Geschäftsfelder, die sie mit ihrem hohen
technologischem Know-how spielend erobern könnten. Spin-Offs drängen daher in den beste-
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 59

henden Wettbewerb, nutzen Distributions- und Service-Netze ihrer “alten Umgebung” und
agrieren zu dem höchst preisaggresiv. Die überschaubare Komplexität der Produkte im AuP-
Umfeld steht nicht im Konflikt mit der Einhaltung von Qualitäts- und Sicherheitsanforderungen.
Das sehen vor allem die Kunden so und setzen daher Qualität voraus. Kennzahlen wie
z.B. Mean Time Between Failure werden zu kaufentscheidenen Kriterien. Ein zusätzlicher
Preis seitens der Kunden wird nicht akzeptiert und ist wegen der vielen Anbieter auch nicht
durchsetzbar. Die Verbreitung autonomer vernetzter mechatronischer Systeme ist dank ihrer
günstigen Realisierung durch flexible Module hoch. Allerdings werden sie nur innerhalb
sicherheitsunkritischen Systemen eingesetzt. Komplexe Systeme mit Echtzeitanforderungen
im Millisekundenbereich sind derzeit noch nicht ausreichend zuverlässig. Dies liegt im besonderen
an der sich zu langsam durchsetzenden integrierten Systementwicklung und den Problemen
im Umgang mit Software.
1 Kommunikationsnetze
Globale Hochleistungsnetze für Kommunikation [91]
2 Autonome vern. mecha. Systeme SystemeMassenware
AMS [91]
3 Tool Support
Br. Palette hochwert. Entw’umgeb.[50] Entw’umgeb. n. f. hoch-komplexe Prod. [36]
4 HW / SW Co Design
Integr. Systementwickl. nicht standesgemäß [55] Bastellös. st. den Bedarf [32]
5 Softwareengineering
Software-Architekten der neuen Generation [45] Isolation der Informatik [32]
6 Wissensmanagement
Klassifikation nur anhand sicherem Wissen [32] XPS durchdringen den Alltag [55]
7 FuE
FuE strategisch entscheident [55] Signifikant höhere Investitionen [45]
8 Globalisierung der der Produktion Verteilte Wirtschaftsräume mit Eigenfokus [86]
9 Bildungssystem
Bildungssystem
Breite Spitze hochqualifizierender Ausbildungsformen [91]
10 Technologieakzeptanz
Aufgeklärte Hi Tech Gesellschaft [100]
11 Standards und Normen der IT Übergreifende Standards [100]
12 Neue Märkte/Marktformen Diversifikation und Dynamik steigen rasant [100]
13 Post Sales Services
Intelligente Massenkomponenten [73] Online Fehlerbehebung [27]
14 Qualitäts- und Sicherheitsanford. Hohe MTBF wird vorausgesetzt [100]
15 Wettbewerbsintensität
Diversifizierte Märkte voller Nischenprodukte[100]
16 Schutz von technol. Vorsprung Wirksames Patentsystem [95]
17 Struktur der Software-Anbieter Open-Source statt teuere SW-Lizenzen [86]
Abbildung 27. Ausprägungsliste Automatisierungs- und Produktionstechnik
Szenario 2 „Hochkonjunktur bringt neue Anbieter hervor“
Szenario 3: „Software-Krise hemmt innovative Entwicklungen“
Der technologische Fortschritt durchdringt immer mehr Bereiche des Lebens. Allerdings ist
seine Ausbreitungsgeschwindigkeit langsamer als erwartet. Dies liegt vor allem am unprofessionellem
Umgang mit Software in der Systementwicklung in den vergangenen Jahren, welcher
zu vielen Fehlern führte. Kunden wünschen ausdrücklich verstärkt wieder
Basisfunktionalität und haben ihr Vertrauen in Software dominiernde Systeme verloren. Der
hohe Imageverlust der Software-Industrie wirft einen großen Schatten auf die allgemeine
Akzeptanz hochtechnischer Systeme. Softwareentwickler stehen zunehmend unter Erfolgsdruck.
Zwar gelingt es mit hohen Anstrengungen hochwertige Spezialanwendungen zu realisieren,
doch fehlen entsprechend ausgebildete Arbeitskräfte und übergreifende Standards zu
einer Verbesserung der Situation. Die quasi-monopolistische Stellung der wenigen Softwaretool-Anbieter
verhindern zudem einen schnelleren Wettbewerb der Innovationen.
60 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

1 Kommunikationsnetze
Hochleistungsnetze zwischen Hi-Tech Regionen [100]
2 Autonome vern. mecha. Systeme Teuere AMS Lösungen für Spezialgebiete [100]
3
5
6
7
8
9
10
11 Standards und Normen der IT
12
13
14
15
Tool Tool Support
4 HW / SW Co Design
Softwareengineering
Wissensmanagement
FuE
Globalisierung Globalisierung der Produktion
Bildungssystem
Technologieakzeptanz
Neue Märkte/Marktformen
Post Sales Services
Qualitäts- und Sicherheitsanford.
Wettbewerbsintensität
16 Schutz vor technol. Vorsprung
17 Struktur der Software-Anbieter
Entwicklungsumgebungen nur für hochkomplexe Produkte [100]
Neues Selbstverständnis der integrierten Systementwicklung [100]
Neue Softwarekrise [100]
Klassifikation nur anhand sicherem Wissen [100]
Industrie bewertet FuE als strategisch entscheidend [100]
Verteilte Wirtschafträume mit Eigenfokus [100]
Amerikanisches Modell mit privatwirtschaftlicher Förderung [100]
Starke Stellung von Wissens-Eliten [100]
Isolierte Standards [100]
Konzentration auf weltweites Angebot [100]
Online Fehlerbehebung [100]
Hohe MTBF wird vorausgesetzt [100]
Konzentration des Angebots stärkt die Intensität [100]
Wirksames Patentsystem [50] Schutzwahn [50]
“Microsoft vs. Oracle” Varianten [100]
Abbildung 28. Ausprägungsliste Automatisierungs- und Produktionstechnik
Szenario 3 „Software-Krise hemmt innovative Entwicklungen“
Szenario 4: „Konzentration durch intelligente Massenprodukte“
Die Automatisierungs- und Produktionstechnik-Branche steht unter Druck. Die Kunden wünschen
einfache und günstige Komponenten, die schnell konfigurierbar sind. Der Preisdruck
zwingt die Unternehmen die Variantenvielfalt deutlich zu reduzieren. Der härtere Wettbewerb
ist überall zu spüren. Fusionen verschiedenster Unternehmen versuchen das Produktprogramm
bei geringen Varianten zu komplementieren, um so die eigene Wettbewerbsposition zu stärken.
Elektronischer Handel findet für weltweiten Vertrieb Verwendung. Die erzielbaren Skaleneffekte
bei Massenproduktion fördern intelligente Massenkomponeten. Die FuE-Anstrengungen
erlauben jetzt Produkte mit hoher Teilintelligenz konstengünstig herzustellen. Fortschritte im
Einsatz lokaler Expertensystemen und Multifunktionssensoren sind hauptsächliche Ursachen.
Eigendiagnose, Systemredundanzen und adaptive Betriebsstrategien machen die Produkteinheiten
relativ fehlerrobust. Die intelligenten Produkte können aufgrund hoher Stückzahlen zu
niedrigen Preisen angeboten werden. Wartungsverträge sind nicht rentabel. Das Service-Technikernetz
wird entscheidend verkleinert. Es herrscht “Fire-and-Forget” Strategie bei den Herstellern
vor.
Szenario 5: „Erklärungsbedürftige Produkte verhindern die Verbreitung elektronischer
Vertriebskanäle“
Die Ausbreitung von E-Business Anwendungen (Vertrieb und Service) bleiben in der Automatisierungs-
und Produktionstechnik hinter den Erwartungen zurück. Was für viele Konsumgüter
Standard geworden ist, setzt sich im Investitionsgüterbereich nur vereinzelt durch. Gründe
hierfür liegen zum einen in den erklärungsbedürftigen Produkten und zum anderen in den langjährigen
Kunden-Lieferanten Beziehungen, wo Qualität und Liefertreue kaufentscheidend
sind. Trotz der weiten Verbreitung von IuK-Technologien, gelingt es nicht, ausreichende Informationen
für eine online Fehlerbehebung zu erfassen. Die Verarbeitung von fallspezifischem
Wissen in Echtzeit spielt für eingebettete Systeme keine wesentliche Rolle. Weder sind die
Anwendungsfelder ausreichend durch Wissensbasen beschrieben, noch sind die Schlußregeln
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 61

1
2
3
4
5
6
7
8
9
10
11 Standards und Normen der IT
12
13
15
Kommunikationsnetze
Globale Hochleistungsnetze für Kommunikation [100]
Autonome vern. mecha. Systeme Massenware AMS [100]
Tool Support
HW / SW Co Design
Softwareengineering
Wissensmanagement
FuE
Globalisierung der Produktion
Bildungssystem
Technologieakzeptanz
Neue Märkte/Marktformen
Post Sales Services
16 Schutz von technol. Vorsprung
17 Struktur der Software-Anbieter
Breite Palette hochwertiger Entwicklungsumgebungen [100]
Integrierte Systementwicklung nicht standesgemäß [100]
SW-Architekten der neuen Generation [75] Isolation der Informatik [25]
Klassifikation nur anhand sicherem Wissen [25] XPS durchdringen den Alltag [75]
Nutzen der FuE in Frage gestellt [75] Signifik. höhere Investit. beider Seiten [25]
Verteilte Wirtschafträume mit Eigenfokus [75] Aufwind der Schwellenländer [25]
Breite Spitze hoch qualifizierender Ausbildungsformen [100]
Aufgeklärte Hi-Tech Gesellschaft [100]
Übergreifende Standards [100]
Konzentration auf weltweites Angebot [100]
Intelligente Massenkomponenten [100]
14 Qualitäts- und Sicherheitsanford. Hohe MTBF wird vorausgesetzt [100]
Wettbewerbsintensität
Konzentration des Angebots stärkt die Intensität [100]
Schutzwahn [50] “Haifischbecken” voller Ideen [75]
“Microsoft vs. Oracle” Varianten [25] Einige Key-Player mit hohem Reifegrad [75]
Abbildung 29. Ausprägungsliste Automatisierungs- und Produktionstechnik
Szenario 4 „Konzentration durch intelligente Massenprodukte
und Constraints für Deduktionssysteme der jeweiligen Fälle erarbeitet. Lediglich simple
Anwendungen von unbedeutender Natur sind realisiert. Einer der Gründ hierfür liegt vor allem
in der unwirtschaftlichen technischen Machbarkeit. Service-Techniker müssen die Mehrzahl
der Problemstellungen vor Ort lösen. Der Bedarf an Service-Verträgen, die Unterstützung in
Problemfällen zu sichern ist folglich hoch. Die Kunden sind auch bereit für Qualitätsstandards
entsprechende Preise zu zahlen. Ein anderer Grund liegt in der Vielzahl der isolierten Standards.
Nur wenige Bestrebungen hinsichtlich einer Konvergenz sind zu verzeichnen. Weiterhin
sieht sich die Informatik nicht in der Rolle, für das Qualitätssiegel der Software zu sorgen. Formale
Aspekte der Softwaretechnik stehen im Vordergrund. Die Unternehmen versuchen daher
die Sache selbst in die Hand zu nehmen, in dem sie stark in unternehmengebundene Aus- und
Weiterbildung sowie in Forschung und Entwicklung investiert.
1 Kommunikationsnetze
Hochleistungsnetze zwischen Hi-Tech Regionen [100]
2 Autonome vern. mecha. Systeme Teuere AMS Lösungen für Spezialgebiete [100]
3
4
5
6
7
8
9
10
11 Standards und Normen der IT
12
13
14
15
Tool Support Support
HW / SW Co Design
Softwareengineering
Wissensmanagement
FuE
Globalisierung Globalisierung der Produktion
Bildungssystem
Technologieakzeptanz
Neue Märkte/Marktformen
Post Sales Services
Qualitäts- und Sicherheitsanford.
Wettbewerbsintensität
16 Schutz von technol. Vorsprung
17 Struktur der Software-Anbieter
Entwicklungsumgebungen nur für hochkomplexe Produkte [100]
Integrierte Systementwicklung nicht standesgemäß [100]
Isolation der Informatik [100]
Komplexität ist für XPS nicht wirtschaftlich durchdringbar [100]
Industrie bewertet FuE als strategisch entscheidend [100]
Verteilte Wirtschafträume mit Eigenfokus [100]
Amerikanisches Modell mit privatwirtschaftlicher Förderung [100]
Starke Stellung von Wissens-Eliten [100]
Isolierte Standards [100]
E-Business wird ignoriert [100]
Fehlerbeseitigung vor Ort [100]
Qualität schlägt sich im Preis nieder [100]
Konzentr. d. Angeb. stärkt d. Intensi. [67] Diversif. Märkte voller Nischenprod. [33]
Wirksames Patentsystem [100]
“Microsoft vs. Oracle” Varianten [33] Einige Key-Player mit hohem Reifegrad [67]
Abbildung 30. Ausprägungsliste Automatisierungs- und Produktionstechnik
Szenario 5
62 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

Zusammenfassung der Szenarien der Automatisierungs- und Produktionstechnik
Die Szenarien für die Automatisierungs- und Produktionstechnik verdeutlichen unterschiedliche
Zukünfte. Die konsistenten Entwicklungen der Schlüsselfaktoren zeigen ein gespaltenes
Bild, in dem vor allem die Spannungsdreiecke „Qualität-Produktkomplexität-Preis“ und
„Berherrschung von Software-Zuverlässigkeit-Anbieter“ die entscheidenden Rollen spielen.
Insbesondere die Berherrschung von Software gepaart mit den rasanten Entwicklung auf dem
Gebiet der Sensorik und der Kommunikationstechnik erscheinen als Notwendigkeit für die
Verbreitung von autonomen mechatronsichen vernetzten Systemen und damit zu einer Modularisierung
sowie auch Standardisierungn von Lösungselementen. Ihre Durchdringung in den
Bereich der echzeitfähigen Systeme hängt dabei im wesentlichen von der zuverlässigen und
wirtschaftlichen technischen Machbarkeit ab. Dahingegen kann eine Software-Krise im
Bereich der eingebetteten Systeme viele wirtschaftlich notwendige Innovationen behindern
bzw. verzögern. Aus wettbewerblicher Sicht hätte dies starke Konzentrationsbemühungen der
Anbieter zu Folge. Gar könnten die Kunden im Business-to-Business bewußt auf weniger
Informationstechnologie setzen, um ihre Produkte noch an Endkunden vertreiben zu können.
4.2.3 Szenarien der Verkehrstechnik
Die Szenarien der Verkehrstechnik beruhen auf den Zukunftsprojektionen und Konsistenzwer-
Szenario3
Langsame Akzeptanz
technischer Innovationen
tungen der ausgewählten Schlüsselfaktoren für diese Anwendungsdomäne. Die Auswertung
des Scree-Diagramm führt zu einer Clusterung von insgesamt drei Szeanrien. Diese sind nachfolgend
beschrieben.
Szenario 1: „Die mobile Technologie-Gesellschaft“
Szenario2
Sicherheitsstreben bremst
Fortschritt der mobilen
Informationsgesellschaft
Szenario1
Die mobileTechnologie-Gesellschaft
Abbildung 31. Zukunftsraum-Mapping der fünf Szenarien der Verkehrstechnik
Hi-Tech prägt unsere tägliche Fortbewegung. Ob im Auto, Zug oder Flugzeug, ständig werden
wir mit neusten Informationen über das lokale und gobale Geschehen versorgt. Software ist
entscheidende Schlüsselkompetenz derzeit. Sie bestimmt einen hohen Anteil des Kundennutzens
und der Unabhänigigkeit der Menschen. Globale Hochleistungsnetze für Kommunikation
erlauben überall, beliebige Anwendungen zu nutzen. Expertensysteme helfen über kleine Probleme
im Alltag hinweg. Sie sind in vielen Produkten integriert. Umweltgerechte, innovative
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 63

Fahrzeugkonzepte werden bereitwillig von der Gesellschaft aufgenommen. Information und
Mobilität haben einen hohen Stellenwert. Unternehmen konzentrieren sich im Zuge der Optimierung
der Branchenwertschöpfungskette auf ihre Kernkompetenzen. Es entsteht ein offener
Wettbewerb der kernkompetenz-orientierten Unternehmen, die innovative Vehikel entwickeln.
1 Kommunikationsnetze
Globale Hochleistungsnetze für Kommunikation [78]
2 Autonome vern. mecha. Systeme
Mechatronischer Ameisenhaufen [95]
3 Tool Support
Breite Palette hochwertiger Entwicklungmöglichkeiten [100]
4 HW / SW Co Design
Neues Selbstverständnis [100]
5 Softwareengineering
Softwarearchitekten der neuen Generation [96]
6 Wissensmanagement
XPS durchdringen den Alltag [81]
7 FuE
Signifikant höhere Investitionen beider Seiten [82]
8 Globalisierung der Produktion
Verteilte Wirtschaftsräume mit Eigenfokus [90]
9 Bildungssystem
Breite Spitze hochqualifizierender Ausbildungsformen [88]
10 Sicherheitsbewußt. d. Menschen
Hohes Maß an Sicherheitsstreben [47] Menschen akzeptieren Fehler [47]
11 Umweltpolitik
Deutschland als umweltpolitisches Vorbild mit innovativen Konzepten [92]
12 Mobilität
Die mobile Gesellschaft [84]
13 Neue Märkte/Marktformen Innovative Vehikel auf dem Vormarsch [84]
14 Post Sales Services
Das Informationsvehikel [78]
15 Qualitäts- und Sicherheitsanford. Kunden fordern Transparenz [44] Preis für Qualität und Sicherheit wird bezahlt [52]
16 Wettbewerbsintensität
Offener Wettbewerb der Kernkompetenzen [95]
Abbildung 32. Ausprägungsliste Verkehrstechnik Szenario 1 „Die mobile Technologie-
Gesellschaft“
Szenario 2: „Sicherheitsstreben bremst Fortschritt der mobilen
Informationsgesellschaft“
Die Kunden nehmen Qualitäts- und Sicherheitsmängel nicht mehr länger hin. Sie fordern die
strikte Einhaltung der Standards bzw. Erhöhung der Richtwerte und -linien. Im Gegenzug sind
sie aufgrund der Risikovermeidung bereit, den höheren Preis für Sicherheit zu bezahlen.
Unternehmen sind daher in erster Linie bemüht sichere Systeme zu entwickeln. Das geht zu
Lasten der Innovationsgeschwindigkeit. Langsamer als erwartet setzen sich neue Schlüsseltechnologien
in Deutschland fest. Auf internationalen Märkten sehen sich die Unternehmen
allerdings einem härteren Wettbewerb ausgesetzt, in dem sie sich schwer tun, mit teuren Produkten
Stand zu halten. Neue Märkte und Marktformen sowie produktnahe Dienstleistungen
sind erste im Entstehen.
Szenario 3: „Langsame Akzeptanz technischer Innovationen“
Die aus der zunehmenden Komplexität der technischen Systeme folgende schwerere
Beherrschbarkeit ist die Hauptursache für höhrer Fehleranfälligkeit. Fehlende Möglichkeiten
das gesamte Zustandsverhalten zu validieren, führen zu einem Grundmißtrauen. Das Vertrauen
der Gesellschaft in den technologischen Fortschritt ist durch mehrere Katasprophen arg gebeutelt.
Schlechte Aufklärungspotitik ist neben der polarisiernden Presse hauptverantwortlich für
den Image-Schaden. Zuvor unartikulierte Ängste der Bevölkerung werden organisiert gesammelt
und Bürgerinitiativen sowie Interessensvertretungen machen den Herstellern und Betreibern
Druck, mehr Transparenz in der Qualitätssicherung zu schaffen. Die Industrie erkennt den
Forschungsbedarf und investiert viel, die technischen Mängel zu beheben. Software-Entwicklung
kämpft in erster Linie noch mit der Komplexität der technischen Systeme. Zusätzlich
besteuert die Regierung die Energiestoffe hoch, was die Unternehmen weiter unter Druck
64 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

1 Kommunikationsnetze
Hochleistungsnetze zwischen Hi Tech Regionen [100]
2 Autonome vern. mecha. Systeme Teuere AMS Lösungen für Spezialgeb. [63] Mechatronischer Ameisenhaufen [38]
3 Tool Support
Br. Palette hochwert. Entw’umgeb.[25] Entw’umgeb. n. f. hoch-komplexe Prod. [75]
4 HW / SW Co Design
Neues Selbstverständnis [63] Integr. Systementwickl. nicht standesgemäß [38]
5 Softwareengineering
Software-Architekten der neuen Generation [100]
6 Wissensmanagement
Klassifikation nur anhand sicherem Wissen [100]
7 FuE
FuE strategisch entscheidend [75] Signifikant höhere Investitionen [25]
8 Globalisierung der Produktion Verteilte Wirtschaftsräume mit Eigenfokus [100]
9 Bildungssystem
Breite Spitze hochqualifizierender Ausbildungsf. [75] Amerikanisches Modell [25]
10 Sicherheitsbewußt. d. Menschen Gesellschaft hat hohes Maß an Sicherheitsstreben [100]
11 Umweltpolitik
Deutschland als umweltpolitisches Vorbild mit innovativen Konzepten [100]
12 Mobilität
Die mobile Gesellschaft [100]
13 Neue Märkte/Marktformen Innovat. Vehikel auf d. Vormarsch [63] Wenig Anbieter mit modul. Varianten [38]
14 Post Sales Services
D. Informationsvehikel [50] O. Service-Call-Center [25] M. Service Werkstatt [25]
15 Qualitäts- und Sicherheitsanford. Preis für Qualität und Sicherheit wird bezahlt [100]
16 Wettbewerbsintensität
Schlüsseltechnologien werden “eingekauft” [100]
Abbildung 33. Ausprägungsliste Verkehrstechnik Szenario 2 „Sicherheitsstreben bremst
Fortschritt der mobilen Informationsgesellschaft“
setzt, innovative Antriebe zu entwickeln. Die hohen Kosten schränken zudem den Individualverkehr
zunehmend ein.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Kommunikationsnetze
Tool Support
HW / SW Co Design
Softwareengineering
Wissensmanagement
Hochleistungsnetze zwischen Hi Tech Regionen [100]
Autonome vern. mecha. Systeme Teuere AMS Lösungen für Spezialgebiete [95]
Entwicklungsumgebungen nur für hochkomplexe Produkte [89]
Integrierte Systementwicklung nicht standesgemäß [68]
Klassifik. nur anhand sicherem Wissen. [47]
Abbildung 34. Ausprägungsliste Verkehrstechnik Szenario 3 „Langsame Akzeptanz technischer
Innovationen“
Zusammenfassung der Szenarien der Verkehrstechnik
Isolation der Informatik [63] Software-technische Komplexität unbewältigt [21]
Kompl. für XPS nicht wirtschaft. [53]
FuE
Industrie bewertet FuE als strategisch entscheidend [84]
Globalisierung der Produktion Billiglohnl. g. ins Hintert. [47] Aufw. d. Schwellenl. [21] Vert. Wirt.’r. mit Eigenf. [32]
Bildungssystem
Amerikanisches Modell mit privatwirtschaftlicher Förderung [100]
Sicherheitsbewußt. d. Menschen Sicherheitsbewußtsein reagiert hoch empfindlich auf Katastrophen [100]
Umweltpolitik
Hohe Besteuerung von Energiestoffen [89]
Mobilität
Eingeschränkte Mobilität von Personen und Gütern [100]
Neue Märkte/Marktformen Wenige Anbieter mit modularen Systemen [58] Individ. Lösungen nicht in Sicht. [26]
Post Sales Services
Das Informationvehikel [42] Mobile Service Werkstatt [53]
Qualitäts- und Sicherheitsanford. Latente Angst vor der technischen Beherrschbarkeit [100]
Wettbewerbsintensität
Schlüsseltechnologien werden “eingekauft” [100]
Die Szenarien für die Verkerhrstechnik verdeutlichen im wesentlichen drei unterschiedliche
Zukünfte. Sie sind bestimmt durch das Spannungsfeld Hi-Tech-Einsatz, Sicherheitsstreben und
Akzeptanz gegenüber technischen Systemen. Je nach Dominanz dieser Faktoren werden die
Zukunftsbilder maßgeblich beeinflusst. Eine starke Stellung des Hi-Tech-Einsatzes führt zu
einer Fortbewegung, die ständig durch alle Möglichkeiten der mobilen Informationsversorgung
und Kommunikationstechnik begleitet wird. Deren Verbreitung setzt aber die sichere
Beherrschung von IuK-Technologien sowie der Software-Entwicklung voraus. Überwiegt das
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 65

Sicherheitsstreben der Gesellschaft werden Innovationen gebremst, standort-immanente Nachteile
Deutschlands gestärkt und folgerichtig internationale Wettbewerbsfähigkeit eingebüßt.
Als dritte Variante kann die Aktzeptanz technischer Systeme die Zukunft der Verkehrstechnik
entscheidend bestimmen. Gelingt der Umgang mit der Komplexität der Systeme und der Softwareentwicklung
nicht zuverlässig, so kann dies zu einem Grundmißtrauen in der Gesellschaft
führen. In Fragestellung des Verkehrsaufkommen und Forderung nach Transparenz können
konsistente Folgen darstellen. In den beiden letzten Fällen kann die Verkehrstechnik aber nur
schwer als Motor für die gesamtwirtschaftliche Entwicklung dienen. Ihre Vorreiter Rolle wäre
in Frage gestellt.
66 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

5 Lösungsansätze
Bei der Erfassung des Ist-Zustandes wurden bereits Problemfelder und Handlungsbedarf der
Unternehmen identifiziert. Im folgenden Abschnitt werden zu diesen Punkten einzelne
Lösungsansätze vorgestellt. Es handelt sich dabei um technische Lösungen, die jeweils eines
odere mehrere der genannten Problemfelder abdecken. Zu jedem Ansatz wird beschrieben:
• Welche technischen Fragestellungen sind im Rahmen des Ansatzes zu bearbeiten?
• Welche Problemstellungen und welcher von den Unternehmen identifizierte Handlungsbedarf
wird durch den Ansatz abgedeckt?
• Welche Verbesserungen ergeben sich durch den Lösungansatz?
Dabei werden die identifizierten Ansätze nach den Themenbereichen
• Interdisziplinäre Zusammenarbeit (einschließlich Aus- und Weiterbildung)
• Prozeßmanagement (einschließlich Vorgehensmodell, Prozeßphasen)
• Qualitätssicherung
• Konfigurationsmanagement
• Werkzeuge und Beschreibungstechniken
gruppiert. Da diese Aufgabenstellungen schließlich in die Definition von Aktionsfeldern
müden, wird jeweils unterschieden nach
• Ansätzen, die mit dem heutigen Stand der Wissenschaft, insbesondere mittels Transferleitungen,
kurz- oder mittelfristig umgesetzt werden können, sowie
• Ansätzen, bei denen noch Bedarf für Forschungs- und Entwicklungsleistungen besteht.
Lösungsansätze stellen, wie oben beschrieben, einzelne technische Aufgabenstellungen dar,
die Realisierung beziehungsweise Umsetzung solcher Fragestellungen wird jedoch in diesem
Abschnitt nicht angegangen. Basierend auf der Unterscheidung in kurz- und mittelfristige
Ansätze werden im nachfolgenden Abschnitt 6 mittels geeigneter Strategien Aktionsfelder für
die Umsetzung dieser Ansätze abgeleitet.
5.1 Interdisziplinäre Zusammenarbeit
Die Lösungsansätze zu diesem Thema sind zum Teil schon in den Ansätzen zu den anderen
Themenschwerpunkten enthalten. Die interdisziplinäre Zusammenarbeit bildet ein Querschnittsthema
zu allen Problemfeldern und Lösungsansätzen, die mit den grundsätzlichen Vorgehensweisen,
mit der Ausbildung und den disziplinspezifischen Qualitätsstandards zu tun
haben. Besonders der Lösungsansatz 5.1.2 „intergriertes Vorgehensmodell” kann nur durch
Unterstützung von interdisziplinären Lösungen und Berücksichtigung der Anforderungen einzelner
Disziplinen sinnvoll bearbeitet werden.
5.1.1 Kurz- bis mittelfristige Lösungsansätze
I. Bereitstellung und Pflege von domänenübergreifenden Terminologiedatenbanken
Häufig werden in einzelnen Disziplinen Begriffe über längere Zeiträume geprägt und angewendet.
Terminologien mit ähnlichen Bedeutungen aber anderen Bezeichnungen werden in
den anderen Disziplinen verwendet. Ein Beispiel dafür sind die im Softwarebereich mit
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 67

„Metriken" bezeichneten Kenngrößen und Kennwerte zur Beurteilung der Reife von Vorgehensmodellen.
In den Ingenieur – und Wirtschaftswissenschaften werden solche Meßgrößen
als „Kennzahlen und Qualitätsmerkmale" bezeichnet. Damit über die Disziplinen hinweg ein
fruchtbarer Gedankenaustausch stattfinden kann, ist es wichtig mit Hilfe solcher Terminologiedatenbanken
zum einen Begriffe mit mehreren Bedeutungen beziehungsweise einer Bedeutung,
die durch mehrere disziplinspezifische Ausdrücke beschrieben wird, zu identifizieren
und zum andern in einer Art Glossarfunktion wirklich domänenspezifische Begriffe zu erklären.
5.1.2 Langfristige Lösungsansätze
I. Integrierte und praxisorientierte Ausbildung/Studiengänge
Dieser Lösungsansatz betrifft hauptsächlich die Ausbildungs- und Studiengänge an deutschen
Hoch- und Fachochschulen. Abgesehen davon, daß ein Studiengang geschaffen werden
könnte, der die besonderen Anforderungen an Projektingenieure, Entwicklungsleiter und Produktverantwortliche
in Unternehmen, die eingebettete Systeme erstellen, vermittelt, sollten
vorhandene Studien- und Ausbildungsgänge so angepaßt werden, daß die entscheidenden
Fähigkeiten vermittelt werden, welche die Entwicklung und Innovation solcher Systeme problemlos
ermöglichen. Dazu gehört unter anderem die Förderung einiger sogenannter "softskills",
wie Kommunikations- und Teamfähigkeit. Die wenigsten Aufgaben in heutigen Studiengängen
sind so gestaltet, daß sie nur im Team und bei regelmäßiger Kommunikation unter
den Kommilitonen gelöst werden können. Diese Fähigkeiten müssen aber frühzeitig verlangt
und mit eigenen Erfahrungen hinterlegt werden. Hierzu müssen außerdem Methoden gelehrt
werden, wie Informationen schnell beschafft und für die jeweilige Situation so aufgearbeitet
und präsentiert werden können, daß sie von anderen Teammitgliedern problemlos aufgenommen
werden können. Die Integration von Praxissemestern oder die Einbindung von Studenten
in industrielle Projekte muß tiefer in den Studiengängen verankert werden. Damit wird das
Bild von den zukünftigen Aufgaben und Anforderungen frühzeitig konkret und die Möglichkeit,
vorhandene Fähigkeiten zu erkennen und neue aufzubauen, motiviert.
Im Einzelenen sind folgende Aspekte in die Ingenieur- und Informatikerausbildung zu integrieren:
• Projektmanagementfähigkeiten
• Team- und Kommunikationsfähigkeit
• Praxiserfahrungen
• Disziplinübergreifende Fächerkombinationen
• Embedded-Systems-spezifische Fächer
II. Integrierte Projektmanagementmethoden
In jeder Disziplin gibt es spezifische Vorgehensweisen bei der organisatorischen Planung und
Durchführung von Entwicklungsprozessen. Diese Projektmanagementmethoden sind um solche
Ansätze zu erweitern oder zu ergänzen, die eine ideale Zusammenarbeit verschiedener
Entwicklungsteams unterschiedlicher Disziplinen ermöglichen und verbessern.
Im einzelnen sind folgende Aufgaben zu lösen:
• Strukturierung des geplanten Entwicklungsprojektes in geeignete Entwicklungsphasen mit
Teilprojektzielen
68 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

• Erarbeitung von Arbeitsplänen und Handlungsanweisungen zum Erreichen der Teilprojektziele
für jede einzelne Disziplin
• Controlling der Teilprojektziele und Erarbeitung von geeigneten Controllingmethoden dazu
• Risikoabschätzung bei Nichterfüllung der Teilprojektziele und Ableitung von Korrekturmaßnahmen
zur Weiterführung des Projektes
Mit der zu entwickelnden Art von Projektmanagementmethodik sollte vor allem der momentan
schwer planbare Zeitbedarf für die Entwicklung von Software optimiert werden. Hier gilt es
Frühwarnsysteme zu integrieren, die Alarm schlagen, sobald ein Projekt zeitlich oder bezüglich
der erwarteten Ergebnisse nicht der Zielplanung entspricht. Dieser Lösungsansatz hat
einen starken Bezug zu dem in Abschnitt 5.1.2 vorgeschlagenem integrierten Vorgehensmodell.
5.1.3 Übersicht Problemfelder und Lösungsansätze
Folgende Tabelle dient zur Veranschaulichung der Zuordnung zwischen Problemfeldern und
Lösungsansätzen:
Problemfeld Lösungsansatz Zeithorizont
Fehlen gut ausgebildeter Informatiker 5.5.2 I langfristig
Schwierige zeitliche Planbarkeit von Entwicklungsprojekten
5.5.2 II langfristig
Koordinationsprobleme bei großen Projektteams 5.5.2 II langfristig
Informationsbeschaffungstechniken schulen 5.5.2 I
5.5.1 I
Einzelkämpfertum vermeiden 5.5.2 I
5.5.1 I
Schnittstellen zu Marketing/Vertrieb/Management
verbessern
Fähigkeiten vermitteln, die Kundenkontakt verbessern
langfristig
kurz-mittelfristig
langfristig
kurz-mittelfristig
5.5.1 II kurz-mittelfristig
5.5.2 I langfristig
Kontakt zu den Universitäten verbessern 5.5.2 I langfristig
Studiengang Ingenieur-Informatik gleiches Geweicht
geben wie Wirtschaftsinformatik
stärker ingenieurmäßige Softwareentwicklung fördern,
mehr Erfahrungen im Projektmanagement vermitteln
Einbindung von Studenten in Projekte unterstützen
(Erfahrungszuwachs)
In der Informatikerausbildung sollte explizit auf eingebettete
Systeme eingegangen werden.
5.5.2 I langfristig
5.5.2 II langfristig
5.5.2 I langfristig
5.5.2 I langfristig
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 69

5.2 Prozeßmanagement und Vorgehensmodell
5.2.1 Kurz- bis mittelfristige Ansätze
I. Definition standardisierter Beschreibungen für den Softwareanteil eingebetteter
Systeme als Grundlage für Lasten- und Pflichtenhefte
Während für den Hardwareanteil eingebetteter Systeme standardisierte Beschreibungsformen
vorliegen, gilt vergleichbares für den Softwareanteil nicht. Die bisher bei der Softwareentwicklung
allgemein eingesetzten Beschreibungsformen sind eher im Bereich der
datenintensiven Systeme angesiedelt (z.B. E/R-Diagramme, Klassendiagramme). Die für
die Aspekte eingebetteter Systeme geeigneten Beschreibungsformen unterscheiden sich je
nach Ansatz und Werkzeughersteller (z.B. State Charts, State Flow Diagrams, ROOM State
Diagrams, etc.). Die Definition geeigneter Beschreibungsformen bietet den Unternehmen
die Möglichkeit, die Anforderungen an den Softwareanteil umfassend, präzise und trotzdem
ausreichend abstrakt und kompakt zu beschreiben. Die Verwendung standardisierter und
präziser Beschreibungsformen führt zu den folgenden Verbesserungen:
+ Abbau der Hemmschwelle: Dem Setzen eines Standards geht eine eingehende Prüfung
und die Zustimmung durch verschiedene Unternehmen voraus. Dies schafft Vertrauen in
den Standard und führt zu einer schnelleren Akzeptanz der Beschreibungsformen.
+ Präzise Beschreibung von Lasten- und Pflichtenheften: Der Einsatz geeigneter Beschreibungformen
erlaubt es, die Anforderungen an ein System umfassend, vollständig und
dennoch abstrakt zu beschreiben. Damit werden die Möglichkeiten für eine genaue
Beschreibung des Leistungsumfangs sowohl für das zu erstellende System gegenüber
dem Kunden als auch für einzelne Komponenten gegenüber Unterauftragnehmern
geschaffen. Die Verwendung standardisierter Formen macht es für Kunden wie für
Unterauftragnehmer einfacher, diese Beschreibungen als Vertragsgrundlage zu akzeptieren.
+ Wirkung auf Werkzeughersteller: Liegen standardisierte Beschreibungsformen vor, so
haben Werkzeughersteller Interesse daran, diesen Standard zu übernehmen, um so ihrem
Produkt eine bessere Akzeptanz zu verschaffen.
+ Einsatz in der Ausbildung: Standardisierte Beschreibungsformen lassen sich gut in die
Ausbildung integrieren und führen so zu einer umfassenden Verbreitung.
Durch diesen Lösungsansatz werden die in Abschnitt 3.3.2, Abschnitt 3.3.3 und Abschnitt
3.3.4 vermissten standardisierten abstrakten Beschreibungsformen abgedeckt und somit die
Voraussetzungen für eine vollständige abtrakte Beschreibung des Softwareanteils eines Systems
geschaffen.
II. Entwicklung eines Vorgehensmodells, das spezifisch auf die Bedürfnisse der
Unternehmen im Bereich eingebetteter Systeme zugeschnitten ist
Die aus der Softwareentwicklung bekannten Vorgehensmodelle kommen bei der Entwicklung
eingebetteter Systeme nur in Ansätzen zum Einsatz, vorwiegend beschränkt auf größere
Unternehmen. Dies ist sicher auch darauf zurückzuführen, daß diese Modelle bisher
sehr allgemein gehalten und nicht speziell auf die Bedürfnisse einzelner Anwendungsgebiete
zugeschnitten sind. Neben allgemeiner Anforderungen im Bereich der eingebetteten
Systeme (z.B. einheitliche Beschreibung von Hard- und Softwarefunktionalität auf hoher
Ebene) ergeben sich in Abhängigkeit der Klassifikation des Unternehmens auch besondere
Anforderungen:
70 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

+ Einsatz geeigneter Beschreibungsformen (z.B. Berücksichtigung von Echtzeitanforderungen)
+ Leichte Anpaßbarkeit auf den Projektumfang
+ Berücksichtigung der bausteinorientierten Entwicklung in allen Phasen
Durch den Einsatz eines definierten Vorgehensmodells lassen sich für die Unternehmen, vor
allem für traditionelle klein- und mittelständische, wesentliche Vorteile erzielen, insbesondere
hinsichtlich
+ Sicherung der einheitlichen Produktqualität
+ Beurteilung des Projektstatus (einschließlich Abschätzung des Projektumfangs)
+ Wiederverwendung von KnowHow und Entwicklung
Die Standardisierung kann hier - wie auch im Fall der Beschreibungsformen - die Akzeptanz
eines solchen Vorgehensmodells wesentlich fördern. Damit lassen sich die in den
Abschnitten 3.3.2, 3.3.3 und 3.3.4 festgestellten Defizite hinsichtlich geeigneter standardisierter
Vorgehensmodelle mit ausreichend früher Berücksichtigung des Softwareanteils einschließlich
systematischer und rentabler Enwicklungsdokumenterstellung abdecken.
III. Definition standardisierter, produktbereichspezifischer Standardarchitekturen und
„hoher“ Schnittstellen für den modularen Aufbau von Systemen aus HW/SW-
Bausteinen
In der Softwareentwicklung gewinnt die Verwendung von Bausteinen und Standardarchitekturen
gerade im Zuge der Objektorientierung zunehmend an Bedeutung. Obwohl gerade
in vielen Bereichen der Entwicklung eingebetteter Systeme ein solcher Ansatz in der ingenieurmäßigen
Tradition der Systementwicklung liegt, finden sich standardisierte Schnittstellen
eher im Bereich der Hardware oder der Software, weniger jedoch bei deren
Kombination. So lassen sich beispielsweise im Bereich des Anlagenbaus Systeme als Kombination
von Stationsmodulen, bestehend aus parametrierten Hard- und Softwaremodulen
sowie einem übergeordneten Prozeßmodul, darstellen. Die Verwendung einheitlicher hoher
Schnittstellen (z.B. einheitliche Fehlerbehandlung, einheitliche Steuerung) für ganze Baugruppen
erlaubt eine bausteinorientierte Entwicklung des Systems durch Zusammenstellen
solcher Komponenten.
Die Verwendung einheitlicher Architekturen und Schnittstellen ist besonders für die Kombination
von Komponenten verschiedener Hersteller von Bedeutung. Die Verwendung
hoher Schnittstellen erlaubt eine einfachere Integration von verschiedenen Elementen und
Versionen vergleichbarer Baugruppen.
Durch diesen Lösungsansatz lassen sich die Defizite hinsichlich der Definition und Verwendung
von Bausteinen sowie des Einsatzes von Standardarchitekturen, wie in den Abschnitten
3.3.2 und 3.3.4 beschrieben, abdecken.
5.2.2 Langfristige Ansätze und Forschungsbedarf
I. Definition eines integrierten Vorgehensmodells einschließlich geeigneter
Beschreibungen und Werkzeugunterstützung
In der Softwaretechnik nimmt die Definition eines durchgängigen, werkzeuggestützten Vorgehensmodells
eine zentrale Rolle ein. Es liegt somit nahe, dies als Klammer der hier
beschriebenen kurz-, mittel- und langfristigen Ansätze zu verwenden. Im Gegensatz zum
kurz- bis mittelfristigen Ansatz spielt hier vor allem die Werkzeugintegration in Form einer
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 71

durchgängigen Werkzeugkette eine wesentliche Rolle. Notwendige Voraussetzung für die
Einführung eines solchen durchgängig werkzeuggestützen Vorgehensmodells ist die
Behandlung der kurz- bis mittelfristigen Aufgabenstellungen, insbesondere die Standardisierung
der Vorgehensweise sowie der Beschreibungsformen. Wesentliche Ziele des integrierten
Vorgehensmodells sollen dabei die Konsistenzüberprüfung beschriebener Systeme
und Komponenten, der Einsatz von Simulation, die Möglichkeit der Generierung von ausführbarem
Code, von Testfällen sowie von Dokumentation sein. Dabei darf sich die Werkzeugunterstützung
wie bisher nicht nur auf die Behandlung der späteren Phasen (ab Design)
beschränken, sondern muß bereits ab der Anforderungsanalyse ansetzen und inbesondere
die Möglichkeit der Dokumentation von Entwurfsentscheidungen sowie der Rückverfolgung
von Anforderungen berücksichtigen.
Im Gegensatz zur mittelfristigen Einführung standardisierter Vorgehensmodelle für einzelne
Themenbereich der Vordringlichen Aktion sollte ein solches Vorgehensmodell möglichst
übergreifend für den Bereich der eingebetteten Systeme definiert werden. Dies ist vor
allem für eine unternehmensübergreifende Entwicklung von Systemen von Bedeutung, bei
der einzelne Arbeitspakete von unterschiedlichen Unternehmen entwickelt werden. Ein solches
bereichsübergreifendes Vorgehensmodell wird besonders bei der zunehmenden Spezialisierung
von Unternehmen, der damit nötigen Auslagerung von Kompetenzen und dem
Zusammenschluß von Unternehmen für einzelne Entwicklungen wichtig.
Da die bausteinorientierte Entwicklung gerade im Bereich der eingebetteten Systeme mit
der damit verbundenen Variantenvielfalt eine große Rolle spielt, ist auf diesen Bereich
besonderes Gewicht zu legen. Neben den damit verbunden Fragen hinsichtlich geeigneter
Beschreibungstechniken und Werkzeuge sind hier vor allem grundlegende Fragestellungen
wie die Definition von Bausteinen, das Auswählen geeigneter Bausteine aus einem Baukasten
sowie das Konfigurieren und Zusammensetzen von Bausteinen zu Systemen zu bearbeiten.
Dieser langfristige und übergreifende Lösungsansatz deckt - mit unterschiedlicher Gewichtung
- die in den Abschnitten 3.3.2 bis 3.3.4 identifizierten Defizite - ausschließlich der Fragestellungen
der Schulung und Vermittlung der ingenieurmäßigen Softwareentwicklung -
ab.
II. Definition von standardisierten, produktbereichspezifischen Benchmarking
Methodiken für die Klassifizierung von HW/SW Bausteinen in Verbindung mit
Laufzeitsystemen
Die Spezifikationdes Zeitverhaltens eines eingebetteten Systems ist der wesentliche
Bestandteil der Entwicklung von Software für eingebettete Systeme.
Der Bedarf für entsprechende Beschreibungstechniken wird für wichtig erachtet, jedoch
existieren derzeit keine geeigneten Mittel hierfür.
Ein Lösungsansatz für dieses Problemfeld stellt sich zweigeteilt dar.
Die eine Seite betrifft die Bereitstellung von Sprachmitteln für die Beschreibung des Zeitverhaltens.
Diese Thematik wird genauer im Abschnitt über Beschreibungstechniken (5.5)
behandelt.
Die andere Seite benötigt zudem die genaueren Leistungsdaten der verwendeten Bausteine
(ein bausteinorientierter Entwurf vorausgesetzt), um im Vorfeld Aussagen über die Performaz
des Gesamtsystems treffen zu können.
72 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

In den Spezifikationen von Hardwarebausteinen finden sich in der Regel Angaben über die
Leistung beziehungsweise entsprechende Kennwerte wieder. Welche Perfomanz ein solches
System bei einer Verschaltung dieser Bauteile erbringt ist aber schon nicht mehr allzu einfach
zu ermitteln, vor allem dann nicht, wenn die Komplexität der Hardwarezusammenstellung
sich in der Software widerspiegelt.
Betrachtet man hingegen Softwarebausteine, sofern sie überhaupt angeboten werden, so
stellt man fest, daß außer den Bibliotheken und einer API (Application Programming Interface)
nichts darüber bekannt ist. Somit wird die Einbindung von externen Bausteinen in
Zukunft zum größten Teil von den Metriken abhängen, mit denen man diese Bausteine
beschreiben wird.
Benchmarking Suiten (Winstone, SPECint/SPECfp (SPEC=System Performance an Evaluation
Cooperative), wie sie in der OFFICE beziehungsweise Workstation Welt Ende der
80iger Jahre zum Vergleich von Rechnerarchitekturen entstanden sind, werden im eingebetteten
Bereich nicht die notwendigen Informationen liefern können. Die technischen Anforderungen,
die es zu bearbeiten gilt, sind:
+ Referenzarchitekturen analysieren
+ mehrere realistische und praktisch angewendete Szenarien erstellen
+ Varianten- und Versions/Ausstattungsvielfalt berücksichtigen
+ eine Benchmarking Architektur (Testbench) erstellen, in der mit relativ geringem Aufwand
eigene Bausteine "gebenchmarked" werden können
+ Standardisierung zur einer weiten Verbreitung verhelfen
Die Vorteile, die sich daraus ergeben sind:
+ für Bausteine, die in der Designphase eingesetzt werden, existieren zu einer Referenzarchitektur
genau spezifizierte und nachvollziehbare Leistungswerte
+ Designentscheidungen bezüglich Laufzeiten können mit diesem Wissen rechtzeitig
durchgeführt werden
+ fehleranfällige Handcodierung beziehungsweise Optimierung von Assemblercode entfällt,
da bereits im Vorfeld Engpässe festgestellt werden können.
+ keine "trial and error" Strategie mehr
III. Rechnerarchitekturspezifikationsmethodik zur automatischen Generierung von
Generatoren
Gewöhnlich entstehen Compiler für Rechnerkerne erst dann, wenn der Kern in seiner Struktur
bereits feststeht. Die Compilerschreiber haben daher den Nachteil hinterher unendlich
viel Optimierungswissen in diese Generatoren integrieren zu müssen.
Die Auswertung der Fragebögen hat gezeigt, daß die Unzufriedenheit in dieser Domäne
sowohl mit der Generierung von Zwischendarstellungsformaten aus Spezifikationssprachen,
als auch mit der Abbildung von Hochsprachencode auf die Zielarchitektur groß ist.
Das bestehende Know-How ist für den Bereich der eingebetteten Systeme nicht ausreichend.
Da in Zukunft immer mehr HW-Bausteine der Peripherie in einen Chip integriert werden,
wird auch dort die Funktionalität und die Komplexität steigen. Dies spiegelt sich letztendlich
in der zu generierenden Software wider.
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 73

Ein möglicher Ansatz wäre hier die Beschreibung der Kernarchitektur durch eine spezielle
Architekturspezifikation, aus der dann automatisch Generatoren für Hochsprachen bzw.
Spezifikationssprachen generiert werden könnten.
Gerade im Hinblick auf ein integriertes Vorgehensmodell mit neuen bausteinbasierten
Beschreibungstechniken und auf die Vielzahl an verfügbaren Architekturen ist diesbezüglich
ein bedeutender Forschungsbedarf gegeben. Allerdings sind hier existierende Ansätze
aus dem Compilerbau zu evaluieren und auf ihre praxistauglichkeit zu überprüfen.
Für kurz- und mittelfristige Ansätze wäre eine Evaluierung von existierenden Compilern
sinnvoll. Vielfach werden dramatische Codegenerierungsverbesserung durch minimale
Änderungen am Hochsprachencode erreicht.
IV. Automatisiertes Design - Intelligente Bausteine, selbstorganisierende adaptive
dynamische Systeme und Middleware für eingebettete Systeme
Auf lange Sicht gesehen ist eine der Möglichkeiten zur Sicherung von technologischem
Vorsprung, dessen kontinuierlicher Ausbau und die Konzentration auf schwer kopierbare
Innovationen. Gerade in einem so schnell wachsenden und dynamischen Markt, wie den
eingebetteten Systemen ist es wichtig, den momentan eingenommenen Spitzenplatz auch
durch visionäre Technologieansätze zu verteidigen, sonst besteht die Gefahr den Anschluß
an flexiblere massiv geförderte ausländische Unternehmen zu verlieren.
Einige Szenarien (siehe Seite 53ff) haben gezeigt, dass bereits innerhalb der nächste acht
Jahre autonome, dezentral vernetzte intelligente mechatronische Systeme eine zunehmend
stärkere Rolle spielen könnten, weshalb es angeraten erscheint, sich bereits jetzt durch die
Beschäftigung mit den dafür notwendigen technischen und methodischen Grundlagen einen
Vorsprung zu verschaffen.
Ausgehend vom klassischen Begriff der standardarchitektur- und bausteinbasierten Softwareentwicklung,
besteht die Möglichkeit, effektive Generierung von der reinen Implementierung
unabhängig auf das Design zu erweitern. Ausgehend von einer
Anforderungsspezifikation könnten automatisiert bestehende SW bzw. HW/SW Bausteine
aus einem Fundus ausgewählt werden, die sich selbst zu der gewünschten Applikation vernetzen
und das nicht nur statisch festgelegt auf die Entwicklungsphase.
Damit wäre es möglich eine Maschine sogar während des laufenden Betriebs um zusätzliche
oder neue Module zu erweitern (Hot Plug & Play), notwendige Software Änderungen,
oder Erweiterungen könnten über das Internet in die Maschine geladen werden, während sie
läuft oder es wäre möglich, die Software im Betrieb zu optimieren.
Neben dem Aufbau einer adäquaten Vetriebsstruktur für Bausteine (auffinden, zertifizieren
von Echtzeit und Sicherheitseigenschaften, automatische Lizensierung usw.) kommt der
Middlware, d.h. der softwaretechnologischen Infrasttruktur für den Betrieb dieser Art von
Systemen und Bausteinen eine gesteigerte Bedeutung zu. Bestehende Ansätze wie SUNs
Jini oder Microsofts UPNP müssen auf ihre Tauglichkeit untersucht und auf die Bedürfnisse
von eingebetteten Systemen angepasst beziehungsweise in diese Richtung erweitert werden.
Dieser Lösungsansatz ist keine direkte Lösung für bereits bestehende Probleme, sondern
stellt eine innovative Möglichkeit dar, sich gegenüber Mitbewerbern zukünftig durch erhöhten
Kundennutzen bei gleichbleibenden Entwicklungsaufwendungen abzuheben.
74 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

5.2.3 Übersicht Problemfelder und Lösungsansätze
Folgende Tabelle dient zur Veranschaulichung der Zuordnung zwischen Problemfeldern
und Lösungsansätzen:
Problemfeld Lösungsansatz Zeithorizont
Fehlen geeigneter standardisierter Vorgehensmodelle 5.2.2(I) lang
Aufwendungen (Kosten, Personalressourcen, Zeit
etc.) für Projekte besonders bei stark individueller
Systemfunktionalität oft nicht ausreichend prognostizierbar
bzw. planbar
Fehlen geeigneter, ingenieurmäßig einsetzbarer und
standardisierter Beschreibungstechniken
Kaum Einsatz von Bausteinen (Software oder kombinierte
Hardware/Software-Module)
Kaum Einsatz von (unternehmensübergreifenden)
Software- bzw.-System-Standardarchitekturen
5.2.2(I) lang
5.2.1(I) kurz-mittel
5.2.1(III) kurz-mittel
5.2.1(III) kurz-mittel
Späte Berücksichtigung der Software-Anforderungen 5.2.2(I) lang
Fehlen eines speziellen Vorgehensmodells für eingebettete
Systeme mit Tailoringmöglichkeit
Definition unternehmenübergreifender, standardisierter
Beschreibungsformen
Ausbildungsmöglichkeiten für die ingenieurmäßige
Entwicklung von Software für eingebettete Systeme
Unvollständige Beschreibung der Anforderungen an
den Softwareanteil bzw. das Verhalten des Systems
Fehlende Systematik in der Erstellung eines Lastenhefts
sowie der Ableitung eines Pflichtenhefts
Geringer Einsatz von Wiederverwendung in der Analysephase
Abstrakte Beschreibungsformen für die Darstellung
von Systemanforderungen
Rentabilität der Lastenheft/Pflichtenheft-Erstellung
verbessern
Generierung von Benutzerschnittstellen aus Systemanforderungen
Fehlende Systematik bei der Herleitung des Designs
aus den Analysedokumente (Pflichtenheft)
5.2.1(I) ,5.2.2(I) kurz-lang
5.2.1(I) kurz-mittel
Siehe Abschnitt 3.3.1
5.2.1(I) , 5.2.1(II) kurz-mittel
5.2.1(II) kurz-mittel
5.2.2(I) lang
5.2.1(I) kurz-mittel
5.2.1(II) kurz-mittel
5.2.2(I) lang
5.2.1(II) kurz-mittel
Fehlender Einsatz präziser Beschreibungsformen 5.2.1(I) , 5.2.1(II) kurz-mittel
Keine Möglichkeit der Rückverfolgung von den
Designdokumenten zum Pflichtenheft
5.2.2(I) lang
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 75

Problemfeld Lösungsansatz Zeithorizont
Kaum systematische Verwendung von Bausteinen
(Identifikation, Definition, Einsatz)
Definition von unternehmensübergreifenden Standardarchitekturen
für einzelne Produktbereiche
Erstellung von Designvorschriften für einzelne Produktbereiche
5.3 Qualitätssicherung
5.2.1(III) kurz-mittel
5.2.1(III) kurz-mittel
5.2.1(II) kurz-mittel
Ausgereifte und stabile Designwerkzeuge 5.2.2(I) lang
Keine Beschreibung von Zeitaspekten aufgrund fehlender
Beschreibungstechniken
5.1.2(II) mittel-lang
Effiziente und automatische Codegenerierung 5.1.2(III) mittel-lang
Schulung des systematischen und ingenieurmäßigen
Designs
Siehe Abschnitt 3.3.1
Ein naheliegender Ansatz zur Lösung der Probleme bei der Qualitätsicherung im Bereich der
eingebetteten Systeme liegt darin, etablierte Vorgehensweisen der Qualitätssicherung aus dem
Bereich herkömmlicher großer Softwaresysteme auch für eingebettete Systeme anzuwenden.
Aufgrund ihrer Besonderheiten unterscheiden sich eingebettete Software jedoch grundsätzlich
von denen der gewöhnlichen Softwaresysteme. Diese Merkmale (z.B. Echtzeit, engste Verzahnung
von SW/HW/Mechanik) stellen für die Qualitätssicherung der eingebetteten Software
entscheidende Randbedingungen dar, die zu berücksichtigen sind.
Die Trends, welche in den Zukunftszenarien dargestellt werden, zeigen die zukünftige Bedeutung
der Qualitätssicherung von Software auf:
• Der zunehmen Einsatz der Modularisierung und die Verbreitung von Standards (siehe dazu
“Zusammenfassung der Szenarien des Anlagen- und Maschinenbaus” auf Seite 58) bedingt,
daß jedes einzelne Modul für sich ausführlich getestet werden muß und parallel zu den Entwicklungsstandards
auch aussagekräftige QS-Standards für eingebettete Systeme entwickelt
werden müssen.
• Zukünftig stellt die Beherrschung der SW-Zuverlässigkeit (siehe dazu “Zusammenfassung
der Szenarien der Automatisierungs- und Produktionstechnik” auf Seite 63) - eine wesentliche
Anforderung intelligenter technischer Produkte - ein großes Problem dar, deren Nachweis
insbesondere durch eine nachvollziehbare SW-QS erreicht werden kann. Dies würde
auch das Sicherheitsbedürfnis der Menschen, welches als ein mögliches Hindernis für die
Verbreitung der Informationstechnik angesehen wird (s. Seite 68), Rechnung tragen.
• Der Trend zu vernetzten mechatronischen Systemen (siehe dazu “Zusammenfassung der
Szenarien der Automatisierungs- und Produktionstechnik” auf Seite 63) wird die Testzugangsmöglichkeiten
wesentlich einschränken und durch die "Verteilung von Intelligenze"
die Komplexität der SW-QS erhöhen.
Die dadurch bedingte zusätzliche Komplexität erfordert neue Ansätze und Lösungen, die im
folgenden beschrieben werden.
76 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

5.3.1 Kurz- bis mittelfristige Ansätze
I. Evaluierung von Werkzeugen und Methoden für die Qualitätssicherung
Für die Qualitätssicherung bei der Entwicklung von Standardsoftware gibt es heute schon
unterschiedlichste Werkzeuge und Methoden. Da der Markt jedoch sehr unübersichtlich ist
und KMUs gewöhnlich nicht die Kapazitäten haben, um deren Tauglichkeit im Bereich der
Entwicklung eingebetteter Systeme zu evaluieren, sollte diese Evaluierung innerhalb eines
Projektes bearbeitet werden.
Durch diesen Lösungsansatz werden folgende Problemfelder abgedeckt:
+ Werkzeuge zum Testen erfüllen die besonderen Anforderungen eingebetteter Systeme
nur unzureichend
+ Ungenügende Anpaßbarkeit der Testwerkzeuge an den Entwicklungsprozeß und an die
Gegebenheiten des Unternehmens
II. Bewertung von QS-Maßnahmen
Die Qualität und Effektivität von QS-Maßnahmen sind oftmals nur schwer zu bewerten,
oder es gibt wenig Aussagen darüber, was eine bestimmte Maßnahme an Nutzen bringt und
unter welchen Rahmenbedingungen man diese einsetzen sollte. Daher wäre es sinnvoll,
Maßzahlen für QS-Methoden zu ermitteln, welche auch die Besonderheiten der Enwicklung
eingebetteter Systeme berücksichtigen.
Durch diesen Lösungsansatz werden folgende Problemfelder abgedeckt:
+ Keine systematische Planung und Durchführung der QS
+ Das Ermitteln von Testfällen erfolgt unsystematisch und ist erfahrungsabhängig
+ Werkzeuge zum Testen erfüllen die besonderen Anforderungen eingebettetet Systeme
nur unzureichend
III. Leitfaden für Unternehmen zur Auswahl und Einführung von QS-Maßnahmen
Welche QS-Maßnamen für ein Unternehmen sinnvoll sind, kann man nicht pauschal definieren:
nachdem man Bewertungskriterien für QS-Maßnahmen gefunden hat, müssen diese
an den Gegebenheiten und unterschiedlichen Anforderungen in den Unternehmen gespiegelt
werden. Dies stellt aber eine schwierige Aufgabe für die Unternehmen dar, da dies nur
mit einem hohen Aufwand zu bewerkstelligen ist. Daher sollte ein Leitfaden erarbeitet werden,
welcher den Aufwand für die Unternehmen entscheidend minimieren würde.
Durch diesen Lösungsansatz werden folgende Problemfelder abgedeckt:
+ Keine systematische Planung und Durchführung der QS
+ Selten ist eine organisatorische und kompetente Einheit für die SW-Qualität vorhanden
+ Das Ermitteln von Testfällen erfolgt unsystematisch und ist erfahrungsabhängig
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 77

5.3.2 Langfristige Ansätze und Forschungsbedarf
I. QS-Prozeßmodell für eingebettete Systeme
Eingebettete Systeme und deren Qualitätssicherung stellen besondere Anforderungen an
den Entwicklungsprozeß, welche durch die für Standardsoftware existierenden Vorgehensmodelle
nicht vollständig abgedeckt werden. Daher muß ausgehend von vorhandenen Vorgehensmodellen
ein an die Anforderungen von eingebetteten Systemen angepaßtes QS-
Prozeßmodell entwickelt werden, welches an die Projektanforderungen adaptierbar ist.
Durch diesen Lösungsansatz werden folgende Problemfelder abgedeckt:
+ Keine systematische Planung und Durchführung der QS
+ Selten ist eine organisatorische und kompetente Einheit für die SW-Qualität vorhanden
II. Methoden für die enwicklungsbegleitende QS
Der größte Aufwand der Qualitätssicherung liegt heute am Ende des Entwicklungsprozesses,
nämlich beim Integrations- und Systemtest. Der Grund dafür liegt darin, daß die Software
ohne das fertige Produkt (z.B. die Maschine) nur beschränkt testbar ist. Da dies
wiederum erst im kritischen Projektpfad zur Verfügung steht und QS-Risiken sehr hoch
sind, bedarf es des Einsatzes neuer Technologien, wie beispielsweise der Simulationstechnik
oder der "ablauffähige Spezifikation", um in den frühen Entwicklungsphasen effektivere
Prüfungen durchführen zu können.
Durch diesen Lösungsansatz werden folgende Problemfelder abgedeckt:
+ Werkzeuge zum Testen erfüllen die besonderen Anforderungen von eingebetteten Systemen
nur unzureichend
+ Ungenügende Anpaßbarkeit der Testwerkzeuge an den Entwicklungsprozeß und an die
Gegebenheiten des Unternehmens
III. Systematische Ableitung und Beschreibung von Testfällen
Es fehlt an geeigneten Strategien zur Ermittlung und Beschreibung der Testfälle für eingebettete
Systeme. Die Testfälle beinhalten, neben den Eingangs- und Ausgangsdaten noch
die Angabe über das Zeit- und Toleranzverhalten sowie die Interaktion der Komponenten.
Erschwerend kommt hinzu, daß die Tests nicht jeweils eine einzelne Funktion prüfen, sondern
eine Sequenz von Einzelprüfungen darstellen.
Daher stellt das Ermitteln und Beschreiben von Testfällen für eingebettete Systeme eine
große Herausforderung dar, welche es noch zu bewältigen gilt. Ein sinnvoller Ansatz dazu
ist die Entwicklung einer geeigneten Beschreibungstechnik, welche die Besonderheiten von
eingebetteten Systemen berücksichtigt und hinreichend einfach anwendbar ist.
Durch diesen Lösungsansatz werden folgende Problemfelder abgedeckt:
+ Das Ermitteln von Testfällen erfolgt unsystematisch und ist erfahrungsabhängig
+ Ein geeignetes und einheitliches Beschreibungsmittel für Testfälle fehlt
IV. Testautomatisierung und Wiederverwendung
Die Eigenschaften eingebetteter Systeme und die Forderung nach einer hohen Qualität ziehen
umfangreiche Tests und komplexe Testbetts (mit denen nicht nur die Testszenarien
automatisch ausgeführt werden müssen, sondern auch das technische Umfeld geeignet
angebunden beziehungsweise simuliert/emuliert werden muß) nach sich. Um den Aufwand
78 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

zu reduzieren und somit die praktische Anwendbarkeit zu gewährleisten, muß ein besonderer
Augenmerk auf die Wiederverwendung und Automatisierung gelegt werden. Beispielsweise
kann der Testfallentwurf durch systematische Wiederverwendung effizienter gestaltet
werden, oder die Werkzeugunterstützung - vor allem der Planungsaspekte - kann die
Anwendungshemmnisse reduzieren helfen und so zur einer effektiveren Qualitätssicherung
beitragen.
Daher ist die Konzeption und Entwicklung einer geeigneten, leicht an die Gegebenheiten
von eingebetteten Systemen anpaßbaren Testumgebung und Testausführung sinnvoll.
Durch diesen Lösungsansatz werden folgende Problemfelder abgedeckt:
+ Das Ermitteln von Testfällen erfolgt unsystematisch und ist erfahrungsabhängig
+ Werkzeuge zum Testen erfüllen die besonderen Anforderungen von eingebetteten Systemen
nur unzureichend.
+ Ungenügende Anpaßbarkeit der Testwerkzeuge an den Entwicklungsprozeß und an die
Gegebenheiten des Unternehmens
5.3.3 Übersicht Problemfelder und Lösungsansätze
Folgende Tabelle dient zur Veranschaulichung der Zuordnung zwischen Problemfeldern und
Lösungsansätzen:
Problemfeld Lösungsansatz Zeithorizont
Keine systematische Planung und Durchführung der
QS
Selten ist eine organisatorische und kompetente Einheit
für die SW-Qualität vorhanden
Das Ermitteln von Testfällen erfolgt unsystematisch
und ist erfahrungsabhängig
Ein geeignetes und einheitliches Beschreibungsmittel
für Testfälle fehlt
Werkzeuge zum Testen erfüllen die besonderen
Anforderungen von eingebetteten Systemen nur
unzureichend.
Ungenügende Anpaßbarkeit der Testwerkzeuge an
den Entwicklungsprozeß und an die Gegebenheiten
des Unternehmens
5.4 Konfigurationsmanagement
5.4.1 Kurz- bis mittelfristige Ansätze
5.2.1(II), 5.2.1(III),
5.2.2(I)
kurz-lang
5.2.1(III), 5.2.2(I) kurz-lang
5.2.1(II), 5.2.1(III),
5.2.2(III), 5.2.2(IV)
5.2.2(III) lang
5.2.1(I), 5.2.1(II),
5.2.2(II), 5.2.2(IV)
5.2.1(I), 5.2.2(II),
5.2.2(IV)
kurz-lang
kurz-lang
kurz-lang
I. Technologietransfermaßnahmen
Im kurz- bis mittelfristigen Umfang sind im Bereich von Konfigurationsmanagementproblemen
vor allem Technologietransfermaßnahmen in Erwägung zu ziehen. Für die Unternehmen,
die noch kein Konfigurationsmanagementsystem einsetzen, ist in den meisten Fällen
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 79

die Einführung eines einfachen Systems ratsam, auch wenn das Unternehmen in diesem
Bereich bisher nur wenig Probleme identifiziert hat. Auf jeden Fall kann so die Verantwortung
für die Verwaltung der einzelnen Dokumentstände von den Schultern der einzelnen
Mitarbeiter genommen werden und man hat eine einheitliche, zentrale Ablage, in der alle
Stände aller Projekte wieder gefunden und verwaltet werden können.
Verbesserungen auf diesem Gebiet hätten folgende Wirkung:
+ Einheitliche Verwaltung elektronischer Dokumente
+ Schutz vor Verlust von System(teilen)
+ Zugriff auf alte Stände
+ Projekthistorien
Dies schafft Lösungen für folgende Probleme:
+ zentrale Ablageorte und einheitliche Ablagesysteme fehlen teilweise
+ Koordination des Zugriffs auf einzelne Dokumente ungenügend
(Sperren sind nicht vorhanden oder müssen umgangen werden)
+ alte Projektstände sind nicht wieder herstellbar
II. Einsatz von optimistischen Sperrverfahren und Sandbox-Methodiken
Für die Gruppe von Unternehmen, die bereits einfache Konfigurationsmanagementsysteme
einsetzen, ist ein Übergang zu optimistischen Sperrverfahren und zu Sandbox-Methodiken
zu erwägen. Hierdurch können mit wenig Aufwand meist immer noch vorhandene Reibungsverluste
minimiert werden.
Verbesserungen auf diesem Gebiet hätten folgende Wirkung:
+ erhöhte Produktivität der Entwickler
+ auch größere Projekte und größere Teams können koordiniert werden
Dies schafft Lösungen für folgende Probleme:
+ Änderungen an verschiedenen Dokumenten, die aufeinander aufbauen, sind oft unkoordiniert
+ Entwickler-Sand-Boxes fehlen
(Arbeit wird oft durch Abgleich mit anderen Entwicklern unterbrochen)
III. Ausdehnung des Konfigurationsmanagements auf alle Projektphasen und
Dokumenttypen
Ganz allgemein sollte angestrebt werden, daß alle Projektdokumente aller Phasen in die
Konfigurationsverwaltung einbezogen werden, um in allen Bereichen eine optimale Koordination
und Unterstützung zu erreichen. Leider bieten heutige Konfigurationsmanagementsysteme
nur für reine Textdokumente eine ausreichende Unterstützung. Zeichnungen,
Pläne oder Tabellen werden nur eingeschränkt unterstützt.
Verbesserungen auf diesem Gebiet hätten folgende Wirkung:
+ Projektweite Konsistenzsicherung
+ geänderte Anforderungen finden garantiert Eingang in die laufende Entwicklung
Dies schafft Lösungen für folgende Probleme:
+ nicht alle Phasen werden abgedeckt
+ Änderungen an verschiedenen Dokumenten, die aufeinander aufbauen, sind oft unkoor-
80 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

diniert
IV. Mitarbeiterschulung
Bei diesen Technologietransferaufgaben ist zu berücksichtigen, daß die Anschaffung des
entsprechenden Systems alleine in keiner Weise ausreichend ist. Gerade bei Konfigurationsmanagementsystem
ist eine entsprechende Schulung der Mitarbeiter und eine gezielte Einführungsunterstützung
dringend erforderlich. Der richtige Einsatz von
Konfigurationsmanagementsystemen greift direkt in die Arbeitsweise der einzelnen Entwickler
und in die bestehende Teamorganisation ein.
Verbesserungen auf diesem Gebiet hätten folgende Wirkung:
+ Verbessertes Problembewußtsein
+ weitere Verbreitung bewährter Organsisationsformen
Dies schafft Lösungen für folgende Probleme:
+ schlechter Ausbildungsstand der Entwickler
5.4.2 Langfristige Ansätze und Forschungsbedarf
I. Entwicklung von Mischverfahren für optimistische Sperrververfahren
Im Themenfeld Konfigurationsmanagement konnten vor allem drei Probleme identifiziert
werden, bei denen dringender Forschungsbedarf besteht. Zur besseren Unterstützung von
optimistischen Sperrverfahren und ganz allgemein zur Verbesserung der Teamkoordination
sind halbautomatische Mischverfahren für alle wichtigen Dokumenttypen zu entwickeln.
Bisher wird halbautomatisches Mischen im wesentlichen nur im Bereich von ASCII-Texten
mit Erfolg angewandt. Prinzipiell sind diese Techniken auch auf andere Dokumenttypen,
wie Word-Dokumente, CAD-Dokumente und Schaltpläne, übertragbar. Dabei könnte sich
die Entwicklung von Mischverfahren als erstes auf Dokumenttypen konzentrieren, für die
allgemein etablierte und weit verbreitete Standards existieren, so daß ein möglichst großer
Benutzerkreis in den Genuß der entstehenden Vorteile kommen kann. Falls einige Werkzeuge
bereits über interne Mischverfahren verfügen, so ist eine geeignete Anbindung an
bestehende Konfigurationsmanagementsysteme zu entwickeln, die eine einfache Gesamtkonfigurationsverwaltung
erlaubt.
Verbesserungen auf diesem Gebiet hätten folgende Wirkung:
+ bewährte Techniken aus dem Bereich der Quelltextverwaltung werden auch in anderen
Phasen (Anforderungsdefinition, Entwurf) und für andere Disziplinen (Maschinenbau,
Elekrotechnik) nutzbar
Dies schafft Lösungen für folgende Probleme:
+ nicht alle Phasen werden abgedeckt
+ Ausdehnung des Konfigurationsmanagements auf weitere Dokumenttypen
(z.B. Word- und Excel-Dateien, Rational-Rose-Files, CAD-Zeichnungen, Schaltpläne)
+ Unterstützung von Mischalgorithmen für das optimistische Sperren auch bei
- Anforderungsdefinitionsdokumenten (z.B. Word- und Excel-Dateien) und
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 81

- Designdokumenten (z.B. Rational-Rose-Files, CAD-Zeichnungen, Schaltpläne, ...)
II. Entwicklung von dokumenttypübergreifenden Konsistenzanalysen
Zur weiteren Verminderung immer noch bestehender Reibungsverluste sind gerade im
Bereich eingebetteter Systeme dokumenttypübergreifende Konsistenzprüfungen zu entwikkeln.
Hier ist besonders der disziplinübergreifende Bereich angesprochen. Geeignete
Konsistenzprüfungen könnten für alle Entwicklungsdokumente eines eingebetteten Systems
von der Blaupause über die elektronischen Schaltungsanteile bis zur Software sicherstellen,
daß Änderungen an einer Stelle an allen betroffenenen Stellen nachgezogen werden. Innerhalb
der reinen Softwareentwicklung ist dieses Problem bereits seit einiger Zeit weitgehend
gelöst und hat hier zu wesentlichen Erleichterungen geführt. Für eingebettete Systeme existieren
aber bisher kaum dokumenttypübergreifende Cross-Checks, die zum Beispiel sicherstellen
könnten, daß nach der Änderung eines Steckers in der Blaupause die entsprechenden
Änderungen im Platinenelayout gemacht werden oder daß nach der Neubelegung einiger
Eingänge die entsprechenden Modifikationen in der Software durchgeführt wurden. Das
Fehlen solcher Überprüfungen führt in der Praxis immer wieder zu immensen Reibungsverlusten
durch Realisierung von nicht zueinander passenden Systemkomponenten.
Verbesserungen auf diesem Gebiet hätten folgende Wirkung:
+ der für eingebettete Systeme typische und kritische Problembereich der interdisziplinären
Zusammenarbeit wird dramatisch verbessert.
+ Konsistenz zwischen den mechanischen, elektronischen und programmierten Anteilen
eines Systems wird gesichert.
+ Änderungen an mechanischen oder elektronischen Komponenten werden garantiert in
die betroffenen elektronischen oder Programm-Komponenten propagiert.
+ komplexe Produktvarianten werden auch disziplinübergreifend beherrschbar.
Dies schafft Lösungen für folgende Probleme:
+ nicht alle Phasen werden abgedeckt
+ Dokumenttypübergreifende Konsistenzanalysen
(z.B.Prüfungen ob Änderungen an Schaltungen in der Software nachgezogen wurden)
III. Bessere Prozeßunterstützung für Projekte mit mehreren Repositories
(z.B. an mehreren Standorten)
Für sehr große Projekte, die auf mehrere Standorte verteilt sind, ist eine geeignete und komfortable
Unterstützung der Verteilung von Projektrepositories dringend notwendig. Hier
müssen zunächst für die verschiedenen Anwendungsbereiche geeignete Vorgehensweisen
identifiziert werden. Darauf aufbauend kann dann im nächsten Schritt eine geeignete Werkzeugunterstützung
für diese Vorgehensweisen entwickelt werden.
Verbesserungen auf diesem Gebiet hätten folgende Wirkung:
+ sehr große Projekte werden beherrschbar
Lösung für folgende Probleme:
+ Prozeßunterstützung für die Koordination von Projekten mit mehreren Repositories
(z.B. Multi-Site-Projekte)
82 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

5.4.3 Übersicht Problemfelder und Lösungsansätze
Folgende Tabelle dient zur Veranschaulichung der Zuordnung zwischen Problemfeldern und
Lösungsansätzen:
Problemfeld Lösungsansatz Zeithorizont
schlechter Ausbildungsstand der Entwickler 5.3.1(IV) kurz-mittel
zentrale Ablageorte und einheitliche Ablagesysteme
fehlen teilweise
nicht alle Phasen werden abgedeckt 5.3.1(III), 5.3.2(I),
5.3.2(II)
5.5 Werkzeuge und Beschreibungstechniken
5.3.1(I) kurz-mittel
kurz-lang
alte Projektstände sind nicht wieder herstellbar 5.3.1(I), kurz-mittel
Koordination des Zugriffs auf einzelne Dokumente
ungenügend
(Sperren sind nicht vorhanden oder müssen umgangen
werden)
Änderungen an verschiedenen Dokumenten, die aufeinander
aufbauen, oft unkoordiniert
Entwickler-Sand-Boxes fehlen
(Arbeit wird oft durch Abgleich mit anderen Entwicklern
unterbrochen)
Dokumenttypübergreifende Konsistenzanalysen stehen
nicht zur Verfügung
Ausdehnung des Konfigurationsmanagement auf
weitere Dokumenttypen
(z.B. Word- und Excel-Dateien, Rational-Rose-Files,
CAD-Zeichnungen, Schaltpläne)
Unterstützung von Mischalgorithmen für das optimistische
Sperren auch bei
- Anforderungsdefinitionsdokumenten
(z.B. Word- und Excel-Dateien) und
- Designdokumenten (z.B. Rational-Rose-Files,
CAD-Zeichnungen, Schaltpläne, ...)
Prozeßunterstützung für die Koordination von Projekten
mit mehreren Repositories (z.B. Multi-Site-
Projekte)
5.3.1(I), kurz-mittel
5.3.1(II), 5.3.1(III) kurz-mittel
5.3.1(II), kurz-mittel
5.3.2(II) mittel-lang
5.3.2(I) mittel-lang
5.3.2(I) mittel-lang
5.3.2(II) mittel-lang
Werkzeuge und Beschreibungstechniken stellen bei der Beschreibung des Ist-Zustandes kein
eigenstäniges isoliertes Themengebiet dar, sondern sind lediglich ein thematisch spezialisierter
Ausschnitt des Vorgehens bei der Entwicklung von Software für eingebettete Systeme. Ensprechend
sind auch die Lösungsansätze für in diesem Bereich ermittelte Probleme an einigen Stellen
ein Vorschlag zur Verbesserung des Vorgehens, besonders wenn grundlegendere Probleme
behoben werden müssen, deren Ursachen außerhalb des Themenkomplexes Beschreibungstechniken
und Werkzeuge liegen, aber direkt in diesen hineinwirken. Wie auch für den Ist-
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 83

Zustand gilt, daß Werkzeuge und Beschreibungstechniken die Mittel zur Verwirklichung eines
bestimmten Vorgehens sind. Die zukünftige Bedeutung des Vorhanden seins von fundierten,
nützlichen und weit verbreiteten Werkzeugen läßt sich sehr gut aus den im vorigen Hauptabschnitt
beschriebenen Zukunftsszenarien ableiten (siehe dazu z.B. “Zusammenfassung der
Szenarien des Anlagen- und Maschinenbaus” auf Seite 58).
5.5.1 Kurz- bis mittelfristige Ansätze
I. Bestehende Vorurteile und Widerstände abbauen - Wirksamkeit beweisen
Aus genau zuvor genanntem Grund steht und fällt die Realisierung eines gewünschten Vorgehens
natürlich mit der Akzeptanz der einzusetzenden Mittel und genau hier liegt eines der
grundlegendsten ermittelten Probleme (siehe dazu Abschnitt 3.3.9).
Das erste Hindernis auf dem Weg zur Verbesserung der bestehenden Situation ist zunächst
häufig die Tradition, das heißt der Widerstand der Betroffenen ein möglicherweise schon
länger praktiziertes Verfahren zu verändern, ohne selbst eine unmittelbare Notwendigkeit
erkennen. Meist kristallisiert sich dieses Verhalten in Vorurteilen, welche die Wirksamkeit
einer bestimmten Maßnahme anzweifeln, ohne konkrete Beweise dafür vorlegen zu müssen.
Eine, wenn auch unbefriedigende Lösungsmöglichkeit ist natürlich zu warten, bis eine
unmittelbare Notwendigkeit besteht, wodurch aber eben ein unerwünschter Effekt bereits
eingetreten ist. Im Gegensatz zu großen Konzernen bringen KMUs in den seltensten Fällen
genügend Resourcen mit, um in einem hart umkämpften Markt mit immer schnelleren Innovationszyklen
die Mittel aufzubringen, sich von einer der hinteren Positionen wieder aus
eigener Kraft an die Spitze zu kämpfen.
Eine bessere Möglichkeit besteht daher darin, die Wirksamkeit und möglicherweise erst
zukünftige Bedeutung zu beweisen. Hier ist also auch die Wissenschaft in der Pflicht, nicht
nur Grundlagen in Form von Beschreibungstechniken und Methoden zu erforschen, sondern
auch deren Wirksamkeit im realen Einsatz zu erproben. Möglicherweise müssen auch
erst noch Techniken erfunden oder verbessert werden, die diese Art von Wirksamkeitsbeweisen
methodisch ermöglichen.
Die Industrie wiederum muß diesen Wirksamkeitsbeweis ermöglichen, indem sie einerseits
die Parameter vorgibt und andererseits die praktische Durchführung ermöglicht und die
gewonnene Information dann auch über adäquate Kanäle verbreitet.
Die grundlegende Bedeutung dieses Lösungsansatzes kann gar nicht oft genug betont werden.
Die Entwicklung der besten Techniken nützt nichts, wenn deren Vorteil nicht angemessen
denen vermittelt werden kann, die sie später einsetzen sollen.
Durch diesen Lösungsansatz werden folgende Probleme abgedeckt:
+ Fehlende Kenntnis der Möglichkeiten
+ Grad des Einsatzes jedem Entwickler freigestellt (fehlendes Problembewußtsein)
+ Unterschiedliche Endkundenanforderungen (sofern durch mangelhaftes Problembewußtsein
und falsche Sparsamkeit bedingt)
Folgende Verbesserungen ergeben sich direkt oder indirekt:
+ Generell verbessertes Problembewußtsein
84 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

+ Die Herausbildung von Standards wird unterstützt
II. Bestehende Nischen- und Speziallösungen nutzen
Einige Firmen haben für ganz spezifische Anforderungen bereits eigene Methoden oder
Werkzeuge entwickelt. Es fehlen jedoch gerade im Bereich der KMUs die Mittel, diese
improvisierten und aus pragmatischen Ansätzen entstandenen Produkte so weit zu verbessern,
daß sie auch von anderen genutzt werden könnten, die ähnliche Anforderungen haben.
Auch ist niemand anderer gewillt, in diese Produkte zu investieren, weil der Kreis der möglichen
Abnehmer zunächst als viel zu klein und deshalb kein echter Markt vorhanden zu
sein scheint. Die Entwicklung dieser Produkte stellt daher eher ein volkswirtschaftliches
denn ein betriebswirtschaftliches Ziel dar. Weiterhin ist in diesen Lösungen viel praxisorientiertes
Wissen eingeflossen, dessen Auswertung sich für mittel- und längerfristige Vorhaben
lohnen könnte.
Natürlich kann dieser Ansatz maximal mittelfristiger Natur sein. Langfristig gesehen müssen
die stark spezialisierten domänenspezifischen Anforderungen, aus denen diese Lösungen
gewachsen sind durch multidisziplinäre Integration abstrahiert (siehe auch 5.5.2)
werden, die kurzfristige übergangsweise Unterstützung von vorhandenen Speziallösungen
kann jedoch zumindestens in bestimmten Teilbereichen eine Milderung folgender Probleme
bewirken:
+ Mangelhafte Werkzeugunterstützung
+ nicht immer auf Anwendungsgebiet zugeschnitte Werkzeuge und Methoden
+ Zu wenig Werkzeuge für Analyse und Test
Der beschriebene Lösungsansatz hat zunächst die Wirkung, daß Nischen und Speziallösungen
allen zugänglich gemacht werden. Mit möglicherweise neuen Vermarktungsmethoden
(z.B. geförderte Open Source bei der Verschlüsselungstechnik) ist es möglich, die Lösungen
eventuell sogar einem größeren Kreis zu erschliessen. Außerdem ist es möglich, daß auf
diesem Wege auch pragmatische Konzepte konserviert und der Forschung zugänglich
gemacht werden, um möglicherweise ihren Weg in langfristige Forschungsergebnisse zu
finden.
III. Erfahrungsaustausch und Evaluierung bestehender Methoden und Werkzeuge
Ein großes kurzfristiges Verbesserungspotential liegt in der Ausnutzung von Synergieeffekten
bei jeweils firmeninternen Evaluierungen bestehender Methoden und Werkzeuge.
Anstatt jeweils eigene beschränkte Mittel nur dafür einzusetzen, einen kleinen Ausschnitt
der vorhandenen Möglichkeiten für sich zu begutachten, sollten die Ergebnisse allen Vertretern
einer bestimmten Domäne zugänglich gemacht werden. Gesammelt ergeben die vielen
Einzelerfahrungen einen guten Überblick über den gesamten Markt der Möglichkeiten.
Weiterhin besteht die Möglichkeit, auf diesem Weg direkten Einfluß auf die Werkzeughersteller
zu nehmen oder sogar ihnen gegenüber als gemeinschaftliche Interessensgruppe aufzutreten.
Für die Werkzeughersteller hat es den Vorteil des direkten Kundenfeedbacks und bietet die
Möglichkeit, schnell auf die Bedürfnisse der Kunden einzugehen, ohne eigene Erhebungen
über die Kundenzufriedenheit durchführen zu müssen.
Ein Erfahrungsaustausch bezüglich beziehungsweise eine Evaluierung bestehender Methoden
und Werkzeuge wird folgende Problemfelder adressieren:
+ Fehlende Kenntnis der Möglichkeiten
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 85

+ Grad des Einsatzes jedem Entwickler freigestellt
+ Mangelhafte Werkzeugunterstützung
+ nicht immer auf Anwendungsgebiet zugeschnitten
+ fehlender Überblick über einen dynamischen Markt
+ Qualität der Werkzeuge schlecht
Ein zentraler Erfahrungsaustausch, beispielsweise in der Form einer allen zugänglichen
Werkzeug und Methodendatenbank hat folgende Verbesserungen zur Folge:
+ Genauere Kenntnis der bestehenden Lösungen
+ Notwendigkeit einer teuren umfassenden Marktbeobachtung und Werkzeugbewertung
für die KMUs entfällt
+ Direkte Einflußnahme auf Werkzeughersteller
+ Immer auf dem neusten Stand
+ Stärkere Konkurrenz der Werkzeughersteller führt zu qualitativ hochwertigeren Produkten
+ Mehr Werkzeuge werden verkauft, Preis kann sinken, wodurch sich zusätzliche Kundenkreise
erschliessen
5.5.2 Langfristige Ansätze und Forschungsbedarf
I. Multidisziplinäre Werkzeug & Methodenintegration durch mehr Abstraktion -
Abstraktion als Grundlage für die Unterstützung domänenspezifischer
Anforderungen durch Beherrschung der Komplexität
Dienstorientierte Systemprogrammierung
wachsen würde.
Komponentenorientierte
Dienstprogrammierung
Klassische Komponentenprogrammierung
Klassische Hochsprachenprogrammierung
Der Einsatz von Forschungsmitteln für die bessere
Berücksichtigung von domänenspezifischer
Besonderheiten in
Beschreibungstechniken oder unmittelbar in
Werkzeugen erscheint wenig sinnvoll, da der
volkswirtschaftliche Nutzen im Vergleich zu
den eingesetzten Mitteln nur sehr gering sein
wird. Eine rein technische Integration und die
Beschränkung auf die Berücksichtigung domänenspezifischer
Besonderheiten würde beim
augenblicklichen Zersplitterungsgrad der
Domänenanforderungen unweigerlich zu noch
umfangreicheren und teureren Werkzeugen führen,
und damit nicht ausreichend zur Steigerung
der Produktivität der Anwender führen, da die
Komplexität der Werkzeuge überproportional
gegenüber der Steigerung möglicher Anwender
Statt dessen bieten sich ein Lösungsweg in zwei Schritten an. Zunächst sollte versucht werden,
den Entwicklungsprozeß für Software auf das gleiche ingenieurmäßige Niveau zu
heben, wie es in anderen Disziplinen beispielsweise bei der Hardwareentwicklung zu finden
ist. Bei der Definition eines gemeinsamen und stark ingenieurmäßig ausgerichteten Entwicklungsprozesses
muß dabei auf die Erfahrungen des Anwendungsbereiches zurückgegriffen
werden, denn dort wurden viele Probleme, die bei der Softwareentwicklung noch
86 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

estehen, bereits gelöst. Vordringlich sind dies ja die hohe Komplexität und große Anforderungsunterschiede
der untersuchten Subdomänen. Hier müssen zur Beherrschung der Komplexität
dringend oberhalb der klassischen Hochsprachenprogrammierung weitere
Abstraktionsebenen etabliert oder eingeführt werden. Der Übergang zu komponenten- und
wiederverwendungsbasierter Entwicklung wäre ein erster Schritt, Systemprogrammierung
auf Basis intelligenter konfigurierbarer Softwaredienste, die zu Anlagenmodulen korrespondieren
ein weiterer. Wenn es gelingt, die praktischen und theoretischen Probleme, die
einem Einsatz zur Zeit noch entgegenstehen, zu lösen, dann würden die Sonderanforderungen
stärker gebündelt und (durch die Schichtung) von den gemeinsamen Anforderungen
getrennt, die dann auch mit wenig Aufwand gefördert werden können, die Ergebnisse aber
der gesamten Domäne zugute kommen.
Sind die Grundlagen
geschaffen, die eine Entwicklung
bedarfsgerechter
integrierter Werkzeuge mit
vertretbarem Aufwand und
für einen größeren Markt
erlauben, reicht der bereits
existierende Bedarf an diesen
Werkzeugen bei weitem aus,
um durch die Kräfte des
SW-
Vorgehensmodell
Digitales Produktmodell
Mechnik-
Vorgehensmodell
... ...
Marktes zu qualitativ hochwertigen und preisgünstigen Werkzeugen zu kommen.
In einem zweiten Schritt sollte versucht werden, das Abstraktionsniveau noch weiter anzuheben
und die verschiedenen Disziplinen, die von der Softwareentwicklung für ES berührt
werden unter einem gemeinsamen Vorgehensmodell zu vereinen, beispielsweise einem
digitalen Produktmodell, das alle Aspekte eines Produktlebenszyklus in sich vereint und die
verschiedenen Einzelvorgehensmodelle miteinander integriert.
Natürlich besteht hier die
Mehr Abstraktion
Gefahr, daß sich die unter-
Beherrschung der Komplexität
schiedlichenVorgehensmo- Algemeiner einsetzbare Werkzeuge
delle verschiedenener
Kostengünstiger, da größere Verbreitung
Disziplinen nicht integrieren
Weniger Nischen und Spezialprodukte
lassen, ohne daß in einigen
Bereichen zunächst Rückschritte
in Kauf genommen
Flexiblere Werkzeuge
werden müssen. Aus diesem
Leichtere Anpaßbarkeit der Werkzeugean spezielle Anforderungen
Grund ist es wichtig, bereits
Stärkere Verwendung von Werkzeugen
die erste Phase sorgfältig
dahingehend zu planen, daß eine Harmonisierung der Vorgehensmodelle der verschiedenen
Disziplinen angestrebt wird, um dann ihre Integration möglichst verlust- und reibungsfrei
zu realisieren.
Durch diesen Lösungsansatz entsteht zunächst die abgebildete Wirkungskette. Dadurch
ergeben sich Lösungen für folgende Probleme:
+ Einführungskosten zu hoch & laufende Kosten zu hoch => unwirtschaftlich
+ Wenig Werkzeuge für Analyse und Test
+ mangelhafte Integration
+ fehlender Überblick über einen dynamischen Markt
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 87
...

+ Qualität der Werkzeuge schlecht
+ Fehlende Kenntnis der Möglichkeiten
+ Grad des Einsatzes jedem Entwickler freigestellt
+ nicht immer auf Anwendungsgebiet zugeschnitten
+ Keine phasenübergreifende Vorwärts- und Rückwärtsverfolgbarkeit
+ Übergewicht Feindesign/ Implementierung
+ Qualitätsprobleme, wenig Wiederverwendung und Bausteinorientierung, hohe Kosten
5.5.3 Übersicht Problemfelder und Lösungsansätze
Folgende Tabelle dient zur Veranschaulichung der Zuordnung zwischen Problemfeldern und
Lösungsansätzen:
Problemfeld Lösungsansatz Zeithorizont
Beschreibungstechniken:
Unterschiedliche Endkundenanforderungen 5.4.1(I) mittel
Fehlende Kenntnis der Möglichkeiten 5.4.1(I), 5.4.1(III), 5.4.2 kurz-lang
Grad des Einsatzes jedem Entwickler freigestellt
(fehlendes Problembewußtsein)
5.4.1(I), 5.4.1(III), 5.4.2 kurz-lang
Mangelhafte Werkzeugunterstützung 5.4.1(II), 5.4.1(III) kurz-mittel
nicht immer auf Anwendungsgebiet zugeschnitten 5.4.1(II), 5.4.1(III), 5.4.2 kurz-lang
Werkzeuge:
mangelhafte Integration 5.4.2 lang
Einführungskosten zu hoch & laufende Kosten zu
hoch => unwirtschaftlich
5.4.2 lang
fehlender Überblick über einen dynamischen Markt 5.4.1(III), 5.4.2 kurz-lang
Qualität der Werkzeuge schlecht 5.4.1(III), 5.4.2 kurz-lang
Wenig Werkzeuge für Analyse und Test 5.4.1(II), 5.4.2 mittel-lang
Davon abhängige Probleme:
Keine phasenübergreifende Vorwärts- und Rückwärtsverfolgbarkeit
5.4.2 lang
Übergewicht Feindesign/ Implementierung 5.4.2 lang
Qualitätsprobleme, wenig Wiederverwendung und
Bausteinorientierung, hohe Kosten
5.4.2 lang
88 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

6 Aktionsfelder
Im folgenden werden sechs mögliche Vorschläge für Aktionsfelder aufgeführt, die sich aus den
Lösungsansätzen und Szenarien, die im Rahmen der Vordringlichen Aktion ermittelt wurden,
ableiten lassen. Die in Abschnitt 5 erarbeiteten Lösungsansätze stellen technische Lösungen
für die in Abschnitt 3 und 4 identifizierten Problemfelder dar, benötigen aber zu ihrer Realisierung
Umsetzungsmaßnahmen. Die im folgenden beschriebenen Aktionsfelder stellen jeweils
Umsetzungsmechanismen für ganze Bündel solcher Lösungsansätze dar. Dazu wird zu jedem
Aktionsfeld beschrieben:
• Welche Arbeiten sind in diesem Aktionsfeld zu leisten, welche Lösungansätze werden in
diesem Aktionsfeld gebündelt?
• Welcher Zeitrahmen ist für das Aktionsfeld nötig (kurz-, mittel- oder langfristig)?
• Welche Zielgruppe profitiert von den Arbeiten?
• Welche Partner sind zur Durchführung der Arbeiten hinzuzuziehen?
Die vorgestellten Aktionsfelder stellen jedoch keine Projektdefinitionen dar. Wie in Abschnitt
6.7 beschrieben lassen sich je nach Aufwand und Ressourcen unterschiedliche Schnitte durch
diese Themenfelder legen, um entsprechende Realisierungsprojekte zu definieren.
6.1 Adaption und Transfer
Zentrale Aufgabe dieses Aktionsfeldes ist die Einführung eines nach dem heutigen Stand der
Technik und Wissenschaft möglichen Entwicklungsprozesses in kleinen und mittelständischen
Unternehmen. Dabei soll diese Einführung in Form geförderter Projekte mit repräsentativen
Pilotunternehmen durchgeführt werden. Hauptaufgaben bei der Einführung eines Entwicklungsprozesses
sind
• Anpassung vorhandener Vorgehensmodelle (inkl. Kostenmodelle) an die Bedürfnisse kleinund
mittelständischer Unternnehmen in den Anwendungsgebieten der Vordringlichen
Aktion
• Einführung von Konfigurationsmanagement mit Berücksichtigung der Variantenvielfalt
sowie der Interdisziplinarität
• Definition eines Leitfadens zur Qualitätssicherung, zugeschnitten auf die Anwendung für
eingebettete Systeme
In diesem Aktionsfeld werden die folgenden Lösungsansätze aus Abschnitt 5 gebündelt:
• Entwicklung eines Vorgehensmodells, das spezifisch auf die Bedürfnisse der Unternehmen
im Bereich eingebetteter Systeme zugeschnitten ist
• Leitfaden für Unternehmen zur Auswahl und Einführung von QS-Maßnahmen
• Technologietransfermaßnahmen für das Konfigurationsmanagement
• Werkzeuge: Bestehende Nischen- und Speziallösungen nutzen
Entsprechend der Klassifizierung der Lösungsansätze handelt es sich um ein kurzfristig realisierbares
Aktionsfeld, bestehend aus der Definition des Vorgehendmodells sowie entsprechender
Leitfäden für Konfigurationsmanagement und Qualitätssicherung und ihrer Einführung
und Erprobung in den ausgewählten Pilotunternehmen.
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 89

Als Zielgruppe für diese Pilotunternehmen eigenen sich besonders kleine und mittlere Unternehmen
mit gleicher Gewichtung von Hardware und Software im System, also beispielsweise
im Bereich Maschinen- und Anlagenbau. Diese Unternehmen sind auftragsgetrieben, haben im
allgemeinen eine große Variantenvielfalt von Produkten bei mittlerer Projektlaufzeit und Qualitätsanforderungen
mittlerer Kritikalität. Damit spielt hier ein definiertes Vorgehen mit definierter
Analysephase sowie Projektabschätzungsmöglichkeiten, das Management von
Produktkonfigurationen und eine standardisierte Qualitätssicherung eine wesentliche Rolle.
Von der Einführung eines solchen Entwicklungsprozesses profitieren nicht nur die Pilotunternehmen.
Die erstellten Modelle und Leitfäden zusammen mit den gewonnenen Erkenntnissen
können auch auf andere Unternehmen der gleichen Zielgruppe übertragen werden sowie bei
diesen mit vermindertem Aufwand eingeführt werden. Besonders sinnvoll ist hier das Einführen
einer Schnittstelle zu Aktionsfeld 6.2.
Im Aktionsfeld werden die Teilaufgaben Adaption des Stands der Technik sowie Transfer der
angepaßten Ergebnisse bearbeitet. Für die Durchführung dieses Aktionsfelds empfiehlt sich
daher eine Konfiguration mit drei Gruppen:
• Pilotunternehmen der Zielgruppe
• Transfer-Partner
- Fachvereinigungen (z.B. Fachgemeinschaft Software des VDMA)
- Beratungshäuser (z.B. SoftwareFactory)
• Universitäre Institute mit Kompetenz in den Bereichen
- Softwaretechnik
- Konfigurationsmanagement
- Qualitätssicherung
6.2 Kompetenzzentrum
Die zentrale Aufgabenstellung dieses Aktionsfelds ist der Aufbau einer Einrichtung zur Sicherung
und Verbesserung von Aus- und Weiterbildung der Softwareentwicklung für die Anwendungsbereiche
eingebetteter Systeme, sowie die Vermittlung aktueller
Technologieentwicklungen. Wesentliche Funktion eines solchen Kompetenzzentrum ist es, als
zentrale Anlaufstelle, besonders für klein - und mittelständische Unternehmen, in softwaretechnologischen
Fragen zu dienen. Die Aufgabenstellung eines solchen Kompetenzzentrums
umfaßt im besonderen Maße:
• Vermittlung der ingenieurmäßigen Softwareentwicklung (Schulungen)
• Anlaufstelle für Transfer aktueller Entwicklung im Bereich Softwareentwicklung für eingebettete
Systeme
• Innovationsdrehscheibe für Diskussion aktueller Trends und Herausforderungen (Workshops)
• Beratungsgremien zur Unterstützung von Studiengangreformen
Neben der generellen Problematik der Bewertung, Umsetzung und Vermittlung der Lösungsansätze
sind insbesondere die folgenden Lösungsansätze betroffen:
• Evaluierung von Werkzeugen und Methoden für die Qualitätssicherung
• Bewertung von QS-Maßnahmen
90 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

• Konfigurationsmanagement: Technologietransfermaßnahmen
• Einsatz optimistischer Verfahren und Sandbox-Methodiken
• Konfigurationsmanagement: Mitarbeiterschulung
• Werkzeuge/Beschreibungstechniken: Wirksamkeit beweisen/Vorurteile abbauen
• Erfahrungsaustausch/Evaluierung von Werkzeugen
• Integrierte und praxisorientierte Ausbildung/Studiengänge
Darüberhinaus spielt auch die Vorbereitung von Unternehmen auf sich abzeichnenden Technologieändeurngen,
wie in diesem Bereicht durch die Szenarien skizziert, eine wesentliche Rolle.
Entsprechend dem Zeitrahmen der betroffenen Lösungsansätze, dem zeitlichen Aufwand zum
Aufbau sowie der Laufzeit einer solchen Einrichtung ist dieses Aktionsfeld als mittel-bis langfristig
einzustufen.
Vor allem kleine und mittlere Unternehmen sind vielfach nicht in der Lage, in gleichem Maße
wie große Unternehmen Ressourcen für die Aus- und Weiterbildung sowie die Beobachtung
aktueller technologischer Entwicklungen bereitzustellen. Dies kann gerade bei Unternehmen
mit gleicher oder stärkerer Gewichtung der Hardware gegenüber der Software zu Know-How-
Defiziten bei der Softwareentwicklung führen. Hinsichtlich der damit verbundenen Sicherung
der Wettbewerbsfähigkeit ist die Einrichtung eines solchen Kompetenzzentrums gerade für
kleine und mittlere Betriebe von hoher wirtschaftlicher Bedeutung.
Für die Einrichtung eines Kompetenzzentrums wird neben der fachlichen Kompetenz im
Bereich Softwaretechnik/eingebettete Systeme insbesondere Kompetenz im Bereich Beratung
und Vermittlung sowie eine Kontaktinfrastruktur (z.B. Fachverband) benötigt. Geeignete Partner
für die Realisierung dieses Aktionsfeldes sind daher
• Fachvereinigungen im Bereich der Ingenieurdisziplinen eingebetteter Systeme (VDMA;
VDI, VDA)
• Beratungshäuser im Bereich Software für eingebettete Software
• Universitäre Institute in beratender Funktion, aus den Bereichen
+ Softwaretechnik
+ Elektro- und Informationstechnik
+ Maschinenwesen
+ Wirtschaftswissenschaften
+ Arbeitswissenschaften
Bei der Bearbeitung dieses Aktionsfeldes sollten die Ergebnisse der Vordringlichen Aktion
„Kompetenznetzwerke produzierender Unternehmen“ besonders berücksichtigt werden.
6.3 Koordination Werkzeugentwicklung
Zentrale Aufgabenstellung für dieses Aktionsfeld ist es, eine Kontaktplattform für Werkzeughersteller
und KMUs zu schaffen. Diese Kontaktplattform soll als vermittelnde und moderierende
Schnittstelle zwischen den ansonsten gegenüber Werkzeugherstellern nicht ausreichend
repräsentierten kleinen und mittleren Unternehmen dienen. Die Anpassung an spezifische
Bedürfnisse kann beispielsweise in Form von geförderten Pilotprojekten mit KMUs des
Anwendungsbereichs erfolgen. Teilaufgaben dieses Aktionsfelds sind daher:
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 91

• Anlaufstelle für Transfer aktueller Entwicklung im Bereich Entwicklungswerkzeuge für
eingebettete Systeme
• Bündelung der Bedürfnisse von KMUs
• Umsetzung aktueller Ergebnisse aus Forschung und Entwicklung in Werkzeuge zur Nutzung
durch KMUs
Neben den generellen Aufgabenstellungen zu Transfer von Entwicklungen und Moderation
von Bedürfnissen der KMUs sind insbesondere die folgenden Lösungsansätze in diesem Aktionsfeld
zu bearbeiten:
• Definition eines Vorgehensmodells einschließlich geeigneter Beschreibungsformen
• Methoden für die entwicklungsbegleitende QS
• Systematische Ableitung und Beschreibung von Testfällen
• Testautomatisierung und Wiederverwendung
• Konfigurationsmanagement: Ausdehnung auf alle Phasen und Dokumenttypen
• Neue Mischverfahren
• Dokumentübergreifende Konsistenzanalyse
Entsprechend dem Zeitrahmen der bearbeiteten Lösungsansätze handelt es hier um ein mittelbis
langfristig zu bearbeitendes Aktionsfeld.
Bisher sind die Bedürfnisse des von kleinen und mittleren Unternehmen geprägten Bereich des
Maschinen- und Anlagenbaus sowie der Produktions- und Automatisierungstechnik von den
im Bereich Softwareentwicklung angesiedelten Werkzeugherstellern nicht ausreichend
berücksichtigt; beispielsweise wurden die dort benötigten Zielplattformen (SPS, Speicherresourcen,
etc.) nicht abgedeckt. So können gerade KMUs dieser Domänen viele existierende
Werkzeuge nicht zur Produktionssteigerung einsetzen.
Geeignete Partner für dieses Aktionsfeld sind
• Pilotunternehmen aus dem KMU-Bereich
• Hersteller von SW-Entwicklungswerkzeugen
• Universitäre Institute aus dem Bereich
+ Maschinenwesen
+ Elektro- und Informationstechnik
+ Informatik
6.4 Unternehmensübergreifende Standardformen
Schwerpunkt dieses Aktionsfeldes ist die Schaffung und Bewertung von Standards im Bereich
eingebetteter Software. Hierbei steht nicht die Schaffung von Normen, sondern die Erstellung
von direkt umsetzbaren Vorlagen und Grundkonzepten für die Unternehmen im Vordergrund.
Wesentliche Teilaufgaben sind hierbei:
• Erfassung von Best-Practice-Ansätzen
• Standards für Dokumenten- und Beschreibungsformen (z.B. Lasten- und Pflichtenheft,
Prüfpläne)
92 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

• Standardsystemarchitekturen und Standardsystembausteine (z.B. Kommunikationsstruktur,
Fehlerbehandlung)
• Standards für Plattformen (z.B. Echtzeitbetriebssysteme) und Standardrealisierungsarchitekturen
(HW und SW)
Bei der Behandlung dieses Aktionsfeldes sind insbesondere die folgenden Lösungsansätze zu
berücksichtigen:
• Definition standardisierter Beschreibungen für den Softwareanteil eingebetteter Systeme als
Grundlage für Lasten- und Pflichtenhefte
• Definition standardisierter, produktspezifischer Standardarchitekturen und „hohe“ Schnittstellen
für den modularen Aufbau von Systemen aus HW/SW-Bausteinen
• QS-Prozeßmodell für eingebettete Systemen
• Terminologiedatenbank
Entsprechend dem zeitlichen Rahmen der bearbeiteten Lösungsansätzen handelt es sich hier
um ein mittel- bis langfristig einzuordnendes Aktionsfeld.
Die Produktentwicklung generell, besonders aber in der Produktionstechnik, erfolgt zunehmend
in stark unternehmensübergreifender Verflechtung spezialisierter Unternehmen. Für die
Steigerung der Produktivität der beteiligten Unternehmen ist daher der Einsatz von Standardformen
in der Softwareentwicklung ebenso von grundlegender Bedeutung wie die Verwendung
von traditioneller Standardbeschreibungsformen, -konstruktionen, -bausteinen und -
schnittstellen der Elektrotechnik und des Maschinenbaus. Damit ist dieses Aktionsfeld sowohl
für kleinere und mittlere als auch für Großunternehmen von wirtschaftlicher Relevanz.
Für die Umsetzung dieses Aktionsfelds ist neben der fachlichen Kompetenz im Bereich Softwareentwicklung
für eingebettete Systeme vor allem die Erfassung der in den Unternehmen
eingesetzen Ansätze und Konzepte sowie die Koordination der Entwicklung solcher Standardformen
notwendig. Geeignete Partner für die Umsetzung dieses Aktionsfelds sind daher:
• Fachgemeinschaften (VDMA, VDI, VA, GI) der Bereiche
+ Maschinenwesen
+ Elektro- und Informationstechnik
+ Informatik
• Universitäre Institute in beratender Funktion aus den Bereichen
+ Maschinenwesen
+ Elektro- und Informationstechnik
+ Informatik
6.5 Integriertes Vorgehensmodell
Ziel dieses Aktionsfeldes ist die Definition eines fach- und unternehmensübergreifenden Vorgehensmodells.
Dieses langfristig angelegte Aktionsfeld stellt daher einerseits Bündelung der
Ergebnisse der vorausgehenden Aktionsfelder dar sowie andererseits die Integration der
Ergebnisse und die Erweiterung um phasen-, fach- und unternehmensübergreifende Aspekte.
Dabei fallen folgende Einzelaufgabenstellungen an:
• Phasenübergreifende Entwicklung
+ Generierung
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 93

+ Rückverfolgung
• Unternehmensübergreifende Entwicklung
• Domänenübergreifende Entwicklung (Informatik, E-Technik, Maschinenbau), Konfiguration
und Konsistenzsicherung
• Kostenmanagement
• Entwicklungsbegleitende Qualitätssicherung
• Bausteine und Standardarchitekturen
• Durchgängige Werkzeugkette
• Rückfluß in den Prozeß (Wartung)
Während prinzipiell auch die in den anderen Aktionsfeldern genannten Lösungsansätze zu
bearbeiten sind, liegt hier der Schwerpunkt auf den folgenden Ansätzen:
• Definition standardisierter Beschreibungen als Grundlage für Lasten- und Pflichtenhefte
• Entwicklung eines Vorgehensmodells, das spezifisch auf die Bedürfnisse der Unternehmen
im Bereich eingebetteter Systeme zugeschnitten ist
• Definition eines Vorgehensmodells einschließlich geeigneter Beschreibungen und Werkzeugunterstützung
• Leitfaden für Unternehmen zur Auswahl und Einführung von QS-Methoden
• QS-Prozeßmodell für eingebettete Systeme
• Methoden für die entwicklungsbegleitende QS
• Systematische Ableitung und Beschreibung von Testfällen
• Testautomatisierung und Wiederverwendung
• Konfigurationsmanagement: Ausdehnung auf alle Phasen und Dokumententypen
• Neue Mischverfahren
• Dokumentenübergreifende Konsistenzanalysen
• Bessere Prozeßunterstützung bei mehreren Repositories
• Werkzeuge: Mehr Abstraktion
• Integrierte Projektmanagementmethoden
Entsprechend dem Zeitrahmen der Lösungsansätze ist dieses Aktionsfeld als langfristige Aufgabenstellung
mit hohem Forschungs- und Entwicklungsbedarf einzustufen. Wichtig bei der
Bearbeitung dieses Aktionsfeldes ist die Berücksichtigung aktueller Gegebenheiten der
Anwendungsgebiete (z.B. SPS-Programmierung) als Ausgangspunkt für eine schrittweise
Migrationsmöglichkeit zu einem übergreifenden Ansatz.
Wegen des hohen Forschungs- und Entwicklungsaufwands liegt hier der Unternehmensschwerpunkt
bei der Durchführung ressourcenbedingt auf größeren Unternehmen. Ein übergreifendes
und integriertes Vorgehensmodell ist jedoch der bestimmende Faktor gerade bei der
unternehmensübergreifenden Systementwicklung mit hohem Qualitätsanspruch. Damit kommt
diesem Aktionsfeld langfristig - vor allem hinsichtlich der sich auch im Produktionssektor
abzeichnenden Entwicklung hin zu Kompetenznetzwerken von Unternehmen - eine zentrale
volkswirtschaftliche Bedeutung zu.
94 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

Geeignete Partner für die Bearbeitung dieses Aktionsfelds sind
• Universitäre Institute mit Kompetenz in den Bereichen
+ Prozeßmanagement und Qualitätssicherung
+ Softwaretechnik und Software Engineering
+ Qualitätsmanagement, Konfigurationsmanagement und Qualitätssicherung
• Mittlere bis große Unternehmen im Bereich eingebetteter Systeme mit etabliertem Vorgehensmodell
(z.B. Festo, Bosch, DaimlerChrysler, BMW; Siemens)
• Hersteller von SW-Entwicklungswerkzeugen
6.6 Neue Ansätze in der Informationsverarbeitung
Ziel dieses Aktionsfelds ist die Bereitstellung neuer Technologien der Informationsverarbeitung
für die Anwendung im Maschinen/Anlagenbau, der Produktions/Automatisierungs/Verkehrstechnik,
z.B.:
• Netzwerktechnologien (inkl. Internet, Jini, etc.)
• intelligente Bausteine und adaptive Systeme
• OO-Technologien (inkl. CORBA etc.)
• Virtuelle Produktentwicklung
• Entwurfsmuster (design pattern) für eingebettete Systeme
Verbunden mit diesen Themenstellungen ist naturgemäß deren Integration in die anderen Aktionsfelder,
insbesondere - wegen des langfristigen Charakters - in das integrierte Vorgehensmodell.
Damit gehen jeweils spezifische Fragestellungen einher, beispielsweise deren Übernahme
in Standardarchitekturen oder Bausteine, Beschreibungsformen und Werkzeuge, Fragen der
Qualitätssicherung oder Konfiguration.
Da bei diesem Aktionsfeld die ständige Beobachtung der aktuellen Entwicklungen im Bereich
Softwaretechnologien und deren Integration in eingebettete Systeme im Vordergrund steht, ist
dieses Aktionsfeld langfristig und als Forschungs- und Entwicklungsbedarf angelegt.
Zielgruppe für dieses Aktionsfeld sind grundsätzlich alle Unternehmen, für die Durchführung
liegt jedoch ressourcenbeding der Schwerpunkt auf größeren Unternehmen. Diese Technologien
stellen langfristig potentielle Schlüsselfaktoren für Produktinnovationen dar und sind
damit - gerade hinsichtlich der oben beschriebenen exportorientieren Bereiche - von hoher
wirtschaftlicher Bedeutung.
Wegen des hohen Innovationscharakters und der damit bedingten Ressourcenbindung sind für
die Umsetzung des Aktionsfelds geeignete Partner
• Universitäre Institute mit Kompetenz in den Bereichen
+ Prozeßmanagement/Systementwicklung
+ Softwaretechnik und Softwareentwicklung
+ Qualitätsmanagement, Konfigurationsmanagement und Qualitätssicherung
• Mittlere bis große Unternehmen im Bereich eingebetteter Systeme
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 95

6.7 Projekte
Die vorgeschlagenen Themenfelder erlauben eine Vielzahl unterschiedlicher Möglichkeiten
zur Definition von Projekten in Verbundform. Dabei können unterschiedliche Schnitte durch
diese Aktionsfelder gelegt werden:
• Vertikal: Ein Verbundprojekt deckt einen Abschnitt eines Aktionsfeldes ab
• Aktionsfeld abdeckend: Ein Verbundprojekt deckt den gesamten Inhalt eines Aktionsfeldes
ab
• Horizontal: Ein Verbund deckt einzelne Ausschnitte verschiedener Aktionsfelder ab
Die Sinnfälligkeit solcher Projektdefinitionen ist wesentlich von den Randbedingungen (Aufwand,
Anzahl und Struktur Partner, Laufzeit) geprägt. Ein Beispiel für einen horizontalen
Schnitt ist:
• Einführung eines bausteinorientierten Vorgehensmodell im Bereich Anlagenbau:
a) Betroffene Aktionsfelder:
- Abschnitt 6.5 "Integriertes Vorgehensmodell": mit Schwerpunkt Bausteinorientierung
- Abschnitt 6.4 "Unternehmensübergreifende Standardformen": Standard-SW-
Architektur für den Anlagenbau
- Abschnitt 6.1 "Adaption und Transfer": unter Verwendung des entwickelten Vorgehensmodells
- Abschnitt 6.2 "Kompetenzzentrum": nach Erprobung des entwickelten Vorgehensmodells
mit Pilotunternehmen
b) Aktionsklasse: kurz-, mittel- und langfristige Anteile
c) Zielgruppe: KMUs aus dem Bereich Anlagenbau
d) Projektpartner: die an den Aktionsfeldern beteiligten Partner ohne Großunternehmen,
evtl. ohne Beteiligung von Werkzeugherstellern
96 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

7 Fragebögen
Für die Befragung der Unternehmen wurden zwei Fragebögen eingesetzt:
• ein Vorabfragebogen zur Einordnung des Unternehmens und zur Vorbereitung auf das
eigentliche Interview
• ein Interviewleitfaden zur detaillierten Befragung der Unternehmen
Beide Fragebögen werden im folgenden wiedergegeben. Zur Auswertung des eigentlichen
Interviews wurde ein Auswertungsbogen eingesetzt, um möglichst unabhängig von den Fachkenntnissen
des Auswerters ein einheitliches Bewertungsschema für alle Themengebieten einsetzen
zu können.
7.1 Vorabfragebogen
Der Vorabbogen wurde den interviewten Unternehmen vor dem eigentlichen Interview zur
eigenständigen Beantwortung zugestellt. Entsprechend den Antworten konnte neben der Einordnung
des Unternehmens so eine möglichst gezielte Befragung vorgenommen werden.
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 97

Entwicklung, Produktion und Service von Software für eingebettete
Systeme
(Interview – Vorabfragebogen)
1 Zielsetzung des Vorabfragebogens
• Erfassung von Kenntnisstand und Umfeld des Interviewpartners
2 Leitfaden für Interview
Hinweise zum Fragebogen:
• Dieser Fragebogen wird im Vorfeld des Interviews schriftlich oder telefonisch beantwortet. Bei einer schriftlichen
Auswertung bitte acht Tage vor dem Interview an den Interviewenden zurücksenden.
• Anhand der Antworten kann eine Vorauswahl der Module für das Hauptinterview durchgeführt werden.
2.1 Strukturelle Einordnung
2.1.1 Fragen zum Unternehmen als Ganzes
Z1: Struktur: Mitarbeiterzahl:........................................... (deutschlandweit),
Umsatz:....................................................
Z2: Produkte (Produktspate):...........................................................................................
2.1.2 Fragen zur Einordnung des Teilbereiches des Befragten (z.B. Software&Systemabteilung/
Electrical Engineering) in das Unternehmen als Ganzes
Z3: Struktur: Mitarbeiterzahl:...........................................Umsatz:..................................................
Z4: Produkte: Produktsparte:..........................................,
Softwareanteil (an den gesamten Entwicklungskosten):.........................%
Z5: Schnittstellen, d.h. Personen, mit denen der Entwickler während des Entwicklungsprozesses der Software in
einer oder mehrerer der Phasen kommuniziert (zutreffende bitte ankreuzen)
❏Kunde
❏Produktplanung
❏Marketing
❏Vertrieb
❏Entwicklung
❏Service
❏systematischer Austausch von Informationen
2.1.3 Art der erstellten Software
Z6: Art der Software
❏Standardsoftware (Anzahl der Installationen einer Version > 100)
❏ Individualsoftware (Anzahl der Installationen einer Version _ 100)
2.1.4 Hintergrund des/der Befragten
Z7: Ausbildungsrichtung
❏Ingenieur (E-Technik, Maschinen/Anlagenbau,andere)
❏Informatiker
❏Betriebswirt
Z8: Bisherige Einsatzgebiete
❏Implementierung
❏Entwicklung
❏Konzeption
❏Technische Beratung
❏Management
❏Andere:....................................................................................
98 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

2.2 Einstiegsfragen zur Ist-Situation des Befragten
2.2.1 Vorgehensmodell
2.2.1.1 Allgemeine Fragen zum Qualitätsmanagement
Z9: Verwenden Sie ein standartisiertes QM-System?
❏Nein
❏Ja, für die HW-Entwicklung das QM-System
...........................................................................................
❏Ja, für die SW-Entwicklung das QM-System
...........................................................................................
❏Ja, für die HW- und SW-Entwicklung das QM-System
...........................................................................................
2.2.1.2 Allgemeines zum Vorgehensmodell
Z10: Zwischen welchen Phasen der Entwicklung von technischen Systemen und von Embedded Software unterscheiden
Sie im Entwicklungsprozeß?
.....................................................................................................................................
.....................................................................................................................................
.....................................................................................................................................
.....................................................................................................................................
Z11: Haben diese Phasen definierte Grenzen?
❏Nein
❏Ja
2.2.1.3 Modul: Anforderungsanalyse und –definition
A1: Exisitiert eine eigene Anforderungsanalysephase (d.h. eine Phase zur Festlegung der Anforderungen/Pflichtenheft)?
❏Nein
❏Ja
2.2.1.4 Modul: Design/Entwurf (Nicht Code-Design)
D1: Gibt es im Entwurfsprozeß eine eigenständige Designphase? (Merkmale sind Modularisierung des Systems in
Funktionalitätem, Verteilungsaspekte (Zuordnung von Funktionen zu Modulen))
❏Nein
❏Ja
D2: Wird das Design werkzeugunterstützt durchgeführt?
❏Nein
❏Ja, mit dem Werkzeug ...........................................................................................
D3: Wird beim Design zwischen Grob- und Feindesign unterschieden? (Grobdesign mit Aufteilung in grobgranulare
Komponenten/Funktionalitäten, Feindesign mit Entwicklung von Funktionseinheiten entsprechend dem Grobdesign)?
❏Nein
❏Ja
2.2.1.5 Modul: Implementierung
I1: Welche Größe haben die implementierten Systeme (mögliche Maße: Größenordnung in LOC/Personenmonaten/Funktionen,
bitte kennzeichnen)?
.......................... LOC/PM/No.Funktionen
I2: Verwendet das realisierte System ein Realzeitbetriebssystem?
❏Nein
❏Ja, das Betriebssystem.............................................................................
2.2.1.6 Modul: Qualitätssicherung
Q1: Wie groß ist der Aufwand bezüglich Personalstärke und Kosten (Personal + Ressourcen)?
.......................................................................Personen bzw..........................................................DM
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 99

Q2: Existiert ein definierter Vorgehensplan für die Qualitätssicherung? (Q - ja/nein) (V)
❏Nein
❏Ja, nach allgemeinem Standard (V-Modell, ISO 9000, CMM, IEEE Standards)
❏Ja, nach unternehmensspezifischem Standard
2.2.1.7 Modul: Produktwartung, Instandhaltung und Service
S7: Halten Sie es grundsätzlich für wichtig, Produkte Ihres Unternehmens während der Nutzungsphase zu beobachten
oder durch ein Serviceteam zu begleiten?
❏Nein
❏Ja
2.2.2 Modul: Dokumente, Konfigurationen und Beschreibungstechniken (orthogonal zu allen
Phasen und Aufgaben des Lebenszyklus)
2.2.2.1 Modul Dokument- und Konfigurationsverwaltung
V1: Gibt es bei Ihnen ein Versions/Konfigurations-Repository (Datenbank, ...)?
❏Nein
❏Ja, das Repository: .................................................................................................................
2.2.2.2 Modul: Beschreibungstechniken
B1: In welchen Entwicklungsphasen werden Beschreibungstechniken (BT) eingesetzt? Erfolgt die Bearbeitung der
Beschreibungstechniken werkzeuggestützt? (z.B. für die graphische Darstellung, Visualisierung, Bearbeitung,
die Simulation des Systems mit Hilfe von ablauffähigen Beschreibungen, die Codegenerierung?)
•
Phase BT-Einsatz Werkzeugunterstützung für BT
Anforderungsanalyse o nein
o ja
Design o nein
o ja
Implementierung o nein
o ja
Qualitätssicherung o nein
o ja
Service/Wartung/
Dokumentation
o nein
o ja
o nein o ja, z.B. mit
...................................................
.....
o nein o ja, z.B. mit
...................................................
.....
o nein o ja, z.B. mit
...................................................
.....
o nein o ja, z.B. mit
...................................................
.....
o nein o ja, z.B. mit
...................................................
.....
2.2.2.3 Modul: Werkzeugunterstützung
•
W1: Welche Werkzeuge oder Hilfsmittel setzen Sie zur Unterstützung Ihrer Tätigkeit ein?
.....................................................................................................................................
.....................................................................................................................................
W2: Warum werden diese Werkzeuge eingesetzt? (Managemententscheidung/Werkzeug zu etablierter Vorgehensweise/Kosten
o.ä)?
...................................................................................................................................
100 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

7.2 Interviewleitfaden
Für die Durchführung der eigentlichen Interviews wurde ein Interviewleitfaden eingesetzt.
Ziel des Leitfaden war es, einen möglichst detaillierten Einblick in den Entwicklungsprozess
des Unternehmens zu bekommen und trotzdem die Besonderheiten jedes einzelnen Unternehmens
berücksichtigen zu können. Daher wurde statt einer durch einen starren Fragebogen eingeschränkten
Befragung ein durch einen Leitfaden geleitetes Interview eingesetzt.
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 101

Entwicklung, Produktion und Service von Software für
eingebettete Systeme
1 Zielsetzung des Interviews
(Interviewleitfaden – Hauptinterview)
• Erfassung von Ist-Zustand, Verbesserungspotentialen und Vorstellungen über ein Soll-Konzept des Softwareentwicklungsprozesses
für eingebettete Systeme in Hinblick auf
• Vorgehensmodell
• Beschreibungstechniken und Darstellungsmittel
• Werkzeugunterstützung
• Management und Controlling
• Prozeßdefinition und Prozeßverbesserung
• Dokumentation des State of the Practice
• Ableiten von Handlungsbedarf
2 Leitfaden für Interview
Hinweise zum Fragebogen:
...
Numerierte Fragen sind Muß-Fragen, Fragen hinter Aufzählungszeichen prinzipiell optional. Optionale Fragen dienen nur als
Anhaltspunkte in welche Richtung sich das Interviewgespräch entwickeln kann, bzw. können gestellt werden, wenn sich aus
den Muß-Fragen kein freies Gespräch entwickelt, oder am Ende eines Fragenmoduls noch Zeit zur Verfügung steht.
2.3 Einstiegsfragen zur Ist-Situation des Befragten
2.3.1 Vorgehensmodell
2.3.1.1 Allgemeine Fragen zum Qualitätsmanagement
Z12: Führen Sie in irgendeiner Form präventive Qualitätsplanungen durch? (Q ja [in welcher Form] / nein) (Beispiele:
Statistische Prozeßkontrolle, QFD (Quality Function Deployment), FMEA (Failure Mode and Effect Analysis),
Zielgrößenvorgaben z.B. bei ppm-Zielen)!
Z13: Hat Ihr Unternehmen einen Qualitätsmanagement-Beauftragten? (Q – ja/nein))
Z14: Ist Ihr Unternehmen zertifiziert, wenn ja nach welcher Norm? (Q –ja [Norm angeben] /nein)
Z15: Sind Ihnen die Begriffe KVPCMM, FMEA und QFD bekannt? (Q – ja[welche Begriffe] / nein)
Z16: Gibt es andere Formen von Produkt- oder Prozeßabsicherungen? (Q –ja/nein)
Z17: -Handlungsbedarf-
2.3.1.2 Allgemeines zum Vorgehensmodell
Z18: Sind die Aktivitäten in den einzelnen Entwicklungsphasen in Ihrem Unternehmen organisatorisch und zeitlich
getrennt? (Q – ja/ nein)
• Wenn ja, wo gibt es genau die organisatorischen Grenzen?
• Werden am Ende der einzelnen Entwicklungsphasen Teilergebnisse in einem vorher festgelegten Konkretisierungsgrad
erwartet? (Q –ja /nein)´
• Gibt es eine gemeinsame Projektplanung von den Entwicklern des technischen Systems mit denen der Embedded
Software? (Q –ja/nein))
• Gibt es übergeordnete Organisatoren oder Vermittlungs- und Koordinationspersonen? (Q –ja/nein))
• Gibt es Abstimmungstermine zwischen einzelnen Softwareentwicklern? (Q – ja/nein)
• Wenn ja, was ist der Gegenstand solcher Abstimmungstermine?
102 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

• Werden Konkretisierungsgrade zu bestimmten Zeitpunkten (Meilensteinplanung) im Projekt verlangt werden, werden
diese überprüft? (Q – ja/nein)
• Wenn ja, gibt es dazu Überpüfungskriterien?
• Welche Maßnahmen werden ergriffen, wenn der geforderte Konkretisierungsgrad nicht erreicht worden ist?
• Werden diese Maßnahmen zeitlich festgelegt und werden verantwortliche Personen für deren Durchführung
benannt und die Maßnahmenergebnisse überwacht?
• Werden Risikoanalysen durchgeführt, wenn das Gesamtprojekt trotz Nichterreichen eines geforderten Teilergebnisses
weitergeführt wird? (Q – ja/nein)
• Werden präventive Methoden genutzt, um mögliche Fehlerauswirkungen beim technischen System und bei der
Embedded Software sowie auch beim Zusammenwirken beider Komponenten vorherzusagen? (Q – ja/nein)
Z19: Welche Form des Vorgehens kommt bei der Entwicklung zum Einsatz?
• inkrementelle oder parallele Vorgehensweise (Systemmodule) (Wasserfallmodell)
• iteratives Vorgehens (d.h. Verzahnung von Anforderungsanalyse / -definition / Systement wurf / -realisierung,
zyklisches Modell)
• Mischung aus Top-Down und Bottom-Up Vorgehen
Z20: Wird eine informelle/formale/kombinierte Entwicklung eingesetzt? (Q – ja/nein)
Z21: Wird Individualsoftware entwickelt und – falls ja – deren Erstellung gezielt unterstützt? (Q – ja/nein)
Z22: Verwenden Sie bausteinorientierte Entwicklung, evtl. auf unterschiedlichen Abstraktionsniveaus? (Q – ja/nein)
Z23: Erfolgt eine integrierte Entwicklung von Hardware und Software (Entwicklung erfolgt abgestimmt, kein Faktor ist
untergeordent)? (Q – ja/nein)
Z24: Verwenden Sie ein definiertes Vorgehensmodell?
• Objektorientierte Ansätze (ROOM/ Real-Time Object Oriented Modeling), OMT)
• SSADM (Structured System Ananlysis and Design Methodology, UK Standard)
• SA/DT, SA-RT
• V-Modell
• Hauseigener Standard
Z25: Wie gestaltet sich die Zusammenarbeit zwischen Systementwicklern und Softwareentwicklern?
Z26: Ist sichergestellt, daß alle Beteiligten die für sie relevanten Informationen erhalten? (Q –ja [wie]/ nein)
• Welche Probleme tauchen dabei auf?
• In welchen Projektphasen arbeiten diese Gruppen zusammen?
• Wie werden Änderungen, die sich Projektverlauf ergeben behandelt?
• Wie werden die Beteiligten informiert?
Z27: Welche Rolle spielt die Nutzerpartizipation (der Kunde) in allen Phasen der Entwicklung?
▲ Findet die Entwicklung mittels einer durchgängigen Werkzeugunterstützung statt? (Q – ja/nein)
▲ Welche Rolle spielt die Einbindung oder der Ersatz von Altsystemen im Entwicklungsprozeß?
▲ Gibt es Problemschwerpunkte im Bereich Vorgehensmodell, die durch die bisherigen Fragestellungen nicht angesprochen
wurden?
▲ Handlungsbedarf?
2.3.1.3 Modul: Anforderungsanalyse und –definition
2.3.1.3.1Allgemeines
A2: Werden Kundenanforderungen systematisch erfaßt, konkretisiert und gebündelt? (Q –ja /nein)
• Wenn ja, wie fließen diese Informationen in den Softwareentwicklungsprozeß ein und in welcher Weise könne sie
dort genutzt werden?
• Werden dazu Methoden zur Übertragung, Bewertung und Priorisierung von Kundenwünschen in Softwarefunktionen
angewendet? (Q –ja [welche]/nein)
• Wenn ja, in welcher Form werden die Ergebnisse der Anwendung solcher Methoden dokumentiert?
A3: Findet ein systematischer Übergang vom Lastenheft zur Anforderungsdefinition statt? (Q-ja/nein)
A4: Wird zwischen Anforderungsanalyse und Anforderungsdefinition (Pflichtenheft) unterschieden? (Q-ja/nein)
A5: Welche Form der Beschreibung der Anforderungsdefinition wird verwendet? (natürliche Sprache, formalisierte
Beschreibungsformen (Automaten, Prozeßgraphen,..), tabellarische Techniken)
A6: Wurde bei Ihnen in letzter Zeit ein Versionsverwaltungssystem (oder ein neues CASE-Tool) eingeführt? Wenn
ja:)
• Unterstützt die Dokumentation verschiedene Sichten auf das System (Interessen der Beteiligten)? (Q-ja/nein)
• Verwenden Sie zusätzliche informelle Beschreibungsmittel zur Unterstützung der Integration der verschiedenen
Sichten, z.B. informellen Text? (Q-ja/nein)
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 103

• Einhaltung von Standards bei der Analyse und Definition (z.B. IEEE-Standard für Anforderungsdefinition, ISO
9000, CMM)
• Welche Rolle spielt die Wiederverwendbarkeit von Analyseprodukten für die Analysephase späterer Entwicklungen?
• Einplanung der Wiederverwendbarkeit von Information über Anforderungen
• Einplanung der Wiederverwendbarkeit von Ergebnissen, Umfragen, Erfahrungen
• Bestehen Techniken zur Erfassung und Dokumentation von nicht-funktionalen Anforderungen?
• Für Anforderungen an Entwicklungssprozeß (bzgl. Zeit, Kosten, Implementierung, Standards etc.)?
• Für Anforderungen an Produkte (bzgl. Benutzbarkeit, Effizienz, Zuverlässigkeit, Portabilität)?
• Für externe Anforderungen (z.B. Gesetze, Interoperabilität)?
•
A7: Welche Rolle spielt die frühe Berücksichtigung der späten Phasen (Einplanung von Wartbarkeit, Anpaßbarkeit,
Weiterentwicklung und Wiederverwendung) in der Anforderungsanalyse?
A8: Werden in der Analysephase Validierungsmechanismen eingesetzt? (Q - ja/nein)
• Werden spezifische Techniken zur Anforderungsvalidierung (z.B. Prototyping, Mock-Ups/Modlelle, Usrer Interface-
Evaluationsprototypen...) eingesetzt? Wenn ja, welche?
• Werden Reviews zur Validierung der Anforderungen an das Softwareprodukt eingesetzt? Falls ja, von wem?
A9: Welche Rolle spielt die Schnittstellenmodellierung in der Anforderungsanalyse?
• Modellierung von Bedienschnittstellen, Informationsschnittstellen zum Management, Prozeßschnittstellen
• Modellierung graphischer Benutzungsoberflächen
▲ Ist es sinnvoll, die Softwareentwickler in die Anforderungsanlyse /–definition frühzeitig einzubeziehen? (Q -ja/nein)
▲ Ist den Softwareentwicklern immer bekannt, für welches technisches Gesamtprodukt die Software erstellt wird und
für welche Art von Kunden das Produkt gedacht ist? (Q ja/nein)
2.3.1.3.2Anforderungsdefinition/Anforderungsspezifikation/Pflichtenheft
A10: Wie bedeutsam ist es im durchgeführten Entwicklungsprozeß, die Anforderungen aus Sicht der Kunden (Auftraggeber
und Benutzer) zu definieren, d.h. gilt es, daß die Anforderungen
• explizit als Anforderungsdefinition dienen: Anforderungen an die Auswirkungen des Systemeinsatzes (Wünsche
der Kunden)
• für Kunden verständlich dokumentiert sind
• zur Erfassung, Klärung und Dokumentation von (oft diffusen) Kundenwünschen dienen
A11: Wie bedeutsam ist es im durchgeführten Entwicklungsprozeß, die Anforderungen aus der Systemsicht zu definieren,
d.h. gilt es, daß die Anforderungen
• explizit als Anforderungsspezifikation dienen: detaillierte Servicebeschreibung, Grundlage für Vertrag
• mit der Möglichkeit der Rückverfolgung von Systemanforderungen auf Kundenanforderungen versehen werden
• zur Beschreibung des Systemverhaltens im Fehlerfall (sicherer Systemzustand nach Fehler, erneutes Starten des
Systems) dienen
A12: Wie bedeutsam ist es im durchgeführten Entwicklungsprozeß, die Anforderungen aus der Softwaresicht zu definieren,
d.h. gilt es, daß die Anforderungen
• explizit als Softwarespezifikation dienen: Grundlage für die Entwicklung
• lesbar für Entwickler sind
• mit der Möglichkeit der Rückverfolgung von Softwareanforderungen auf Systemanforderungen und Kundenanforderungen
versehen sind
A13: Wie werden Spezifikationen für Embedded Software erstellt, beschrieben und dokumentiert?
• Wie detailliert müssen diese Beschreibungen idealerweise sein?
• Werden dazu Visualisierungs- und/oder Dokumentationshilfsmittel genutzt? (Q ja/nein)
• Sind Ihnen Tools zur Spezifikationsentwicklung bekannt? (Q –ja/nein)
• Wer beschreibt seine Anforderungen zuerst, die Systementwickler (1) oder die Softwareentwickler (2)? (Qentweder
1 oder 2))
• Gibt es hier einen unterschiedlichen Sprachgebrauch bei der Spezifikationsbeschreibung? (Q - ja/nein)
• Sollten für beide Seiten gemeinsam zu nutzende, synchronisierte Techniken entworfen werden oder Systeme zur
Verfügung stehen, die in der Lage sind, in den jeweils anderen Bereich zu übersetzen? (Q - ja/nein)
• Sehen Sie einen Unterschied der Spezifikationsmethoden im Bereich der Ingenieurdisziplinen (Zeichnungen, Lastenhefte,
Beschreibung von technischen Anforderungen) und denen der Informatik (Daten-, Funktions- und Verhaltensmodelle),
d.h. sehen Sie ein Kommunikationsproblem? (Q –ja[warum] / nein))
▲ Wie werden Änderungen an den Spezifikationen in den laufenden Prozeß eingebunden?
• Gibt es definierte Vorgehensweisen für die Änderung von Spezifikationen? (Q ja/nein))
2.3.1.4 Modul: Design
D4: Wie gut ist die Designphase in einen systematischen, durchgängigen Entwicklungsprozeß integriert?(Nahtlos
ohne sichtbare Übergänge und vollständiger Wiederverwendung von Ergebnissen bisheriger Phasen, teilweise
mittels automatischer/schematischer Wiederverwendung von Ergebnissen bisheriger Phasen, kaum bei manueller
oder nicht vorhandener sichtbarer Wiederverwendung von Ergebnissen bisheriger Phasen)
104 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

• Wird ein systematischer (oder sogar nahtloser) Übergang von der Anforderungsdefinition/Anforderungsspezifikation/Pflichtenheft
zum Design unterstützt (Umsetzung und Fortschreibung von Analysedokumenten)? Welche
Dokumente werden wieder eingesetzt? In welcher Form?
• Besteht eine Möglichkeit der Rückverfolgung zu den Anforderungen? (Q - ja/nein) Wenn ja, welche?
• Findet bereits das Grobdesign parallelisiert/partitioniert entsprechend der Modularisierung der Analysephase
statt?(z.B. wegen Anforderungen aus der Analysephase) (Q - ja/nein)
• Erfolgt ein systematischer Übergang vom Grobentwurf zum Feinentwurf? (Q - ja/nein)
• Besteht eine Möglichkeit der Rückverfolgung zum Grobentwurf? (Q - ja/nein)
• Findet das Feindesign parallelisiert/partitioniert entsprechend der Modularisierung im Grobentwurf statt? (Q - ja/
nein)
D5: Welche Rolle spielt die Berücksichtigung der späteren Phasen, d.h. Einplanung von Wartbarkeit, Anpaßbarkeit,
Weiterentwicklung und Wiederverwendung, im Design?
D6: Welche Rolle spielt die Wiederverwendung von Ergebnissen früherer Entwicklungsprozesse?
• Kommen Entwurfsmuster (`design pattern´) oder Standardarchitekturen zur Anwendung?
• Kommt eine bausteinorientierte Entwicklung zum Einsatz, d.h. wird das System wesentlich durch die Verwendung
und Konfigurationen von bestehenden Komponenten entwickelt?
• Spielt die Einplanung der Wiederverwendbarkeit von Diagrammen, Zeichnungen, Strukturen, Modulen eine
Rolle?
• Welche Rolle spielt die Wiederverwendung vorhandener Komponenten?
• Wird die Wiederwendbarkeit beim Feindesign berücksichtigt, d.h. wird das Design so vorgenommen, daß die
entwickelten Komponenten gut wiederverwendet werden können (Schnittstellenfestlegung, Modularisierung von
funktionellen Einheiten etc.)?
• Wird das Herauslösen von Bausteinen während der Systementwicklung berücksichtigt?
• Wird das Einbindung von Standardkomponenten aus Bibliotheken unterstützt? (eigene/fremde, mit Begründung
für Auswahl fremd/eigen)
• Welche Rolle spielt standardisierte Hardware zur Vereinfachung des Design?
D7: Werden in der Designphase Mechanismen zur Sicherung der Qualität eingesetzt?
• Kommen Konsistenzsicherungsmechamismen zum Einsatz (Überprüfung der Schnittstelle, Fehlende Nachrichten/Methoden/Typen)
etc?
• Kommt Simulation in der Designphase zum Einsatz (z.B. bei der Verwendung simulierbarer Spezifikationen im
Feindesign)
• Kommt Prototpying in der Designphase zum Einsatz? (Q - ja/nein)
• Zum Entwurf der Nutzungsschnittstelle (exploratives Prototyping)?
• Zum Experimentieren mit Entwurfsalternativen (experimentelles Prototyping)
• Mittels Weiterverwendung von Prototypen (evolutionäres Prototyping)
2.3.1.5 Modul: Implementierung
I3: Kommt Werkzeugunterstützung zum Einsatz?(Q-ja/nein)
(zugekaufte oder selbstentwickelte Softwarewerkzeuge zum Generieren von Code, Simulieren von Code und
zum Finden von Programmierfehlern (Debugging))
Wenn ja, dann
• Arbeitet das Werkzeug vollautomatisch oder besteht Bedarf zur Nachbearbeitung?(Q-ja/nein)
• Wenn Bedarf zur Nachbearbeitung besteht, wieviel Prozent des gesamten automatisch generierten Codes muß
schätzungsweise nachbearbeitet werden? (Q - %)
•
• Wird eine Rückverfolgung zum Feinentwurf ermöglicht (trotz manueller Nachbearbeitung?)? (Q-ja/nein)
• Welche Compiler, Linker, Assembler werden bei der Generierung von Code für das Zielsystem genutzt? (kommerz.,
freie, eigene Entwicklung)
• Welche Debugger werden eingesetzt? (kommerz., freie, ...)
• Werden Tools von den Hardwareherstellern genutzt?
(Beispiel: DAvE von Siemens für Microcontroller kombiniert mit den Tools von Tasking) (Q-ja/nein)
•
I4: Kommen bei der Implementierung Programmierrichtlinien, Styleguides, Standards o.ä. zum Einsatz? (Q-ja/nein,
welche) ?:
• Mittels Einhaltung von Standards bei der Implementierung (z.B. ISO 9000, CMM) oder Hausstandards? (Name)
• Bei der Dokumentation? (Q-Name)
• Zur Sicherung der Verständlichkeit und Lesbarkeit des Quellcodes? (Q- Name)
I5: Welche Rolle spielt die frühe Berücksichtigung der späten Phasen, d.h. Einplanung von Wartbarkeit, Anpaßbarkeit
und Weiterentwicklung?
(a) starke Rolle, wird für fast alle Codeabschnitte vorgesehen,
(b) nur an den Stellen, die wirklich wichtig sind,
(c) wird mehr oder weniger dem Einzelnen überlassen
I6: Welche Rolle spielt die Einplanung der Wiederverwendbarkeit von Klassen, Bibliotheken, Modulen und fertigen
Programmen?
(a) es wird sehr viel Wert daurauf gelegt, auch von "InHouse" erzeugten Modulen,
(b) nur von Standardelementen, wie sie von Softwareherstellern angeboten werden,
(c) es bleibt dem Einzelnen überlassen, welche Wiederverwendungstechnik angewendet wird.
• Wie hoch ist der Grad der Wiederverwendung? (Q, %)
Wieviel Prozent des Codes wird ausbestehendem Code sozusagen recycled?
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 105

▲ Wird die Implementierung verteilt, d.h. von mehreren Leuten durchgeführt?(Q-ja/nein)
• Gibt es einen Verantwortlichen für die Integrationsphase der erzeugten Codeabschnitte?(Q-ja/nein)
2.3.1.6 Modul: Qualitätssicherung
Die Qualitätssicherung in Form von Test und Prüfungen findet während und nach der Implementierung bzw. Produktion statt
und ist deshalb nicht nur als einzelne der Produktion nachgelagerte Phase zu verstehen.
2.3.1.6.1Organisation
Q3: Wie ist die Qualitätssicherung organisatorisch in das Unternehmen eingebunden?
• übergeordnete eigenständige QS-Abteilung
• für jedes Projekt bzw. Abteilung existiert eine eigene QS-Abteilung
• Entwickler führen die Qualitätssicherung selbst durch.
• externe QS-Abteilung
2.3.1.6.2Methoden
Q4: Zu welchen Zeitpunkten und in welchen Phasen werden Tests und Prüfungen durchgeführt?
Q5: Welche Ziele werden in den einzelnen Phasen des Vorgehensplans (QS-Phasen) verfolgt?
• Tests und Validierung aller Ergebnisse
• Kennzahlen für Produktqualität
• Überprüfung der Einhaltung der Qualitätsziele
• Prozeßverbesserung (Qualitätsprozeß, Entwicklungsprozeß)
Q6: Welche Methoden werden dabei eingesetzt
• Standards für Review, Test und Dokumentation
• Unternehmensspezifische
• In welchen QS-Phasen werden in welchem Umfang diese Methoden angewendet
Q7: Welche Dokumente werden genutzt und entstehen in den jeweiligen QS-Phasen?
Q8: Werden die Software und das technische System getrennt oder zusammen oder sowohl als auch getestet?
• Simulation mit kommerziellen Simulatoren?
• Emulation mit Hardwareemulationsboards?
• Hardware in the Loop bzgl. Systemintegration?
Q9: Wie werden die Tests und Prüfungen geplant?
• Gibt es dazu Planungsunterlagen und die vorherige Einbeziehung von Testzeiträumen in den Projektplan? (Q ja /
nein))
Q10: Wie werden geeignete Testfälle ermittelt?
Q11: Wie werden die Test- und Prüfungsergebnisse dokumentiert?
Q12: Werden projektübergreifend Ergebnisse verwertet?
• z. B. Testfall-Beschreibungen
Q13: Verlangt der Kunde die Durchführung bestimmter Prüfungen und will er die Ergebnisdokumentation einsehen?
(Q ja /nein))
Q14: Werden Testergebnisse in anderer Form an den Kunden weitergeleitet? (Q - ja/nein)
Q15: Gibt es spezielle Analysemethoden für die Testsauswertung? (Q - ja/nein)
• Werden statistische Methoden angewendet? (Q - Ja/nein))
▲ In welchen Bereichen der QS sehen Sie sich von den derzeit in Ihrem Unternehmen eingesetzten Praktiken nicht
optimal in der Ausführung Ihrer Aufgaben unterstützt? Im Hinblick auf
• Organisation/Management
• Methodik
• Werkzeuge
▲ Wer führt Tests durch (der Entwickler selber oder anderes Personal)?
▲ Werden Erfahrungen aus alten Testreihen genutzt? (Q ja /nein)
▲ Gibt es Standardtests? (Q ja/nein)
▲ Was würden Sie gerne verbessern?
2.3.1.7 Modul: Produktwartung, Instandhaltung und Service
S8: Welche besonderen Anforderungen an die Wartung und Instandhaltung stellen Systeme mit Embedded Soft-
106 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

ware (z.B. hoher Anteil an Monitoring/Schnittstellen/Prüftsoftware)?
S9: Welcher Produktbestandteil bewirkt nach Ihrer Erfahrungen im Feld die meisten Probleme?
S10: Wodurch wird in Reklamations- und Reparaturfällen die Diagnosesicherheit beeinflußt?
S11: Werden Daten und Diagnoseergebnisse bzw. Fehleranalysen zu den in der Nutzung befindlichen Systemen
gesammelt und an die Entwickler zurückgeführt? (Q-ja/nein)
• Wenn ja, werden solche Daten für die Produktoptimierung und die Planung von Nachfolgeprodukten genutzt? (Q
ja/nein)
S12: Werden Fehler, die an der Software oder dem technischen System während der Nutzung auftreten automatisch
erfaßt und statistisch ausgewertet?(Q-ja/nein)
• Wenn nein, könnten Sie sich vorstellen, daß eine solche Fehler bzw. Ausfallanalyse wertvolle Ergebnisse liefern
könnte? (Q ja/nein)
S13: Welche Kompetenzen/Ausbildung muß das Servicepersonal aufweisen?
S14: Halten Sie die Fähigkeiten der durchschnittlichen Servicemitarbeiter für ausreichend oder besteht Ihrer Meinung
nach hier ein erhöhter Ausbildungsbedarf? (Q Ja/nein)
2.3.2 Modul: Dokumente, Konfigurationen und Beschreibungstechniken (orthogonal zu allen
Phasen und Aufgaben des Lebenszyklus)
2.3.2.1 Modul Dokument- und Konfigurationsverwaltung
Begriffsklärung
• Dokument /Artefakt (von Menschen gemacht)
Alles was man erstellen/verändern kann (Elektronisch oder Papier oder Hardware oder Metall)
• Z.B.: Quelltextdokumente, Schaltpläne, CAD-Zeichnungen, Designdokumente, Spezifikationsdokumente, Analysedokumente,
Verträge, Projektplan (PERT Charts / GANTT Charts, ...)
2.3.2.1.1Dokumentablageorte
V2: Gibt es (zentrale) Projektverzeichnisse / Regalwand
V3: Verteilte Ablage, z.B.
• pro Person, pro Abteilung, pro Disziplin, (Informatik / Elektrotechnik / Maschinenbau), pro Firma
• pro Phase: Analyse, Spezifikation, Design, Implementierung, Produktion, Service
V4: Lokale / persönliche Arbeitskopien (oder für verschiedene Abteilungen)
(insbesondere von Quelltexten/CAD-Zeichnungen, ...)
2.3.2.1.2Strukturierte Dokumentbezeichner
V5: Gibt es spezielle / strukturierte Dokumentbezeichner/Teilenummern (Q-ja/nein)
• Wenn ja, welche Informationen sind darin enthalten:
• Dokumenttyp, Projektnummer, erstellende / zuständige: Person (Abteilung, Disziplin, Firma), Erstellungs- /
Änderungsdatum, Status (in Bearbeitung, freigegeben, eingefroren, ...), Versionsnummer
2.3.2.1.3Zugriffskontrolle
V6: Wer darf wann welche Dokumente lesen (/kopieren)
V7: Wird das protokolliert (wer hat welches Dokument in welcher Version / welcher Stand)
2.3.2.1.4Redundanzen
V8: Gibt es Dokumente (unterschiedlicher Typen) mit inhaltlicher Überschneidung
(z.B. CAD Zeichnungen für Motor und Getriebe überlappen im Anschlußbereich, elektrischer Schaltplan überlappt
mit Signaldeklarationen im Softwaredesign, Klassendiagramme überlappen mit Deklarationen im Quellcode)
(Q-ja/nein)
• Wenn es bei Ihnen solche Überlappungen gibt, wo genau:
• Welche Redundanzen liegen innerhalb (der Zuständigkeit) einzelner Personen, Abteilungen, Disziplinen, Ebenen,
Phasen (Analyse, Spezifikation, Design, Implementierung, Produktion, Service)
• Welche Redundanzen betreffen mehrere Personen, Abteilungen, Disziplinen, Managementebenen, Phasen
(Analyse, Spezifikation, Design, Implementierung, Produktion, Service)
• Wie werden solche Dokumente untereinander konsistent gehalten:
• Wer darf wann welches Dokument ändern (z.B. erst elektrischen Schaltplan ändern, dann Softwaresignaldeklarationen
nachziehen)
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 107

• Wie werden solche Änderungen in den anderen Dokumenten nachgezogen / propagiert
• Wer ist für das Nachziehen verantwortlich
• Gibt es dafür explizite Regeln (z.B. in einem Projekthandbuch, schriftliche Firmenleitlinien, Versionsverwaltungssystem)
• Gibt es explizite / regelmäßige / vorgeschriebene Konsistenzprüfungen
• Wie wichtig ist diese Fragestellung für Sie:
• Gibt es in diesem Bereich nie, selten, gelegentlich oder oft Problem
• Sind diese Probleme sehr leicht, mit wenig Aufwand, mit merklichem Aufwand oder nur mit großem Aufwand in
den Griff zu kriegen
• Können Sie sich hier technische Hilfestellungen kaum, vielleicht oder gut vorstellen
• Sehen Sie hier für die Zukunft Forschungsbedarf
2.3.2.1.5Dokumentabhängigkeiten
(Eine Änderung in Dokument A (z.B. CAD-Zeichnung, Schaltplan, Klassendiagramm, ...) macht entsprechende
Änderungen in davon abhängigen Dokumenten B, C, u.s.w., notwendig (z.B. in NC-Programmen, in
Platinenlayouts, in Quelltexten.)
V9: Gibt es zusätzlich zu Redundanzen weitere Abhängigkeiten zwischen verschiedenen Dokumenten / Dokumenttypen.
(Q-ja/nein)
• Wenn ja, wo überall:
• Welche Abhängigkeiten liegen innerhalb (der Zuständigkeit) einzelner Personen, Abteilungen, Disziplinen,
Managementebenen, Phasen (Analyse, Spezifikation, Design, Implementierung, Produktion, Service)
• Welche Abhängigkeiten betreffen mehrere Personen, Abteilungen, Disziplinen, Ebenen, Phasen (Analyse, Spezifikation,
Design, Implementierung, Produktion, Service)
• Wie werden solche Abhängigkeiten gemanagt:
• Wer darf wann was ändern (nach typischen Beispielszenarien fragen)
• Ist das explizit festgelegt (z.B. in einem Projekthandbuch, schriftliche Firmenleitlinien, Versionsverwaltungssystem)
• Gibt es Programm-/Werkzeugunterstützung für die Zugriffskontrolle
• Wie werden Änderungen an betroffene Dokumente und Personen propagiert
• Welche Nachrichtenwege gibt es dafür (Scenarien erfragen)
• Gibt es dafür Formblätter (Papier, E-mail, ...)
• Wie sieht eine typische Änderungsnachricht aus (welches Dokument geändert, wo und wie geändert, warum
geändert, warum ist der Empfänger betroffen, empfohlene Maßnahmen, ...)
• Wie findet der Verursacher die abhängigen Dokumente beziehungsweise die betroffenen Personen, gibt es dazu
explizite Unterlagen (z.B. in jedem Dokument, im Projekthandbuch, im Versionsverwaltungssystem)
• Wie werden Änderungsnachrichten übermittelt (mündlich, schriftlich, E-mail, ... , Meetings, ... , mit Rückmeldung,
...)
• Gibt es hierfür Werkzeug-/Programmunterstützung
• Wie wird die Wiederherstellung der (projektweiten) Konsistenz geprüft / sichergestellt:
• Manuell, mit Werkzeug-/Programmunterstützung, ...
• gibt es dafür explizite Richtlinien (z.B. in einem Projekthandbuch, schriftliche Firmenleitlinien, Versionsverwaltungssystem,
...)
• werden diese Vorgänge protokolliert, wenn ja
• Manuell
• mit Werkzeug-/Programmunterstützung
• gibt es dafür explizite Richtlinien (z.B. in einem Projekthandbuch, schriftliche Firmenleitlinien, Versionsverwaltungssystem,
...)
• Wie wichtig ist diese Fragestellung für Sie:
• Gibt es in diesem Bereich nie, selten, gelegentlich oder oft Problem
• Sind diese Probleme sehr leicht, mit wenig Aufwand, mit merklichem Aufwand oder nur mit großem Aufwand in
den Griff zu kriegen
• Können Sie sich hier technische Hilfestellungen kaum, vielleicht oder gut vorstellen
• Sehen Sie hier für die Zukunft Forschungsbedarf
V10: Wie werden Zuständigkeits- und Personalwechsel gehandhabt
• gibt es dafür explizite Richtlinien (z.B. in einem Projekthandbuch, schriftliche Firmenleitlinien, Versionsverwaltungssystem,
...)
• Gibt es in diesem Bereich nie, selten, gelegentlich oder oft Problem
• Sind diese Probleme sehr leicht, mit wenig Aufwand, mit merklichem Aufwand oder nur mit großem Aufwand in
den Griff zu kriegen
• Können Sie sich hier technische Hilfestellungen kaum, vielleicht oder gut vorstellen
• Sehen Sie hier für die Zukunft Forschungsbedarf
V11: Kommt es vor, daß während eines laufenden Projekts die Richtlinien (z.B für die Zugriffskontrolle, Nachrichtenwege,
Verantwortungsbereiche, Zuständigkeiten) geändert werden.
108 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

• gibt es dafür explizite Richtlinien (z.B. in einem Projekthandbuch, schriftliche Firmenleitlinien, Versionsverwaltungssystem,
...)
• wird die Umsetzung solcher Änderungen geplant / überwacht, wenn ja wie (Szenarien erfragen)
• Gibt es in diesem Bereich nie, selten, gelegentlich oder oft Problem
• Sind diese Probleme sehr leicht, mit wenig Aufwand, mit merklichem Aufwand oder nur mit großem Aufwand in
den Griff zu kriegen
• Können Sie sich hier technische Hilfestellungen kaum, vielleicht oder gut vorstellen
• Sehen Sie hier für die Zukunft Forschungsbedarf
V12: Gibt es wichtige Teilprojekte / -entwicklungen, die gleichzeitig zu verschiedenen Projekten beitragen (z.B. Motorgruppe
für mehrere Modellserien)?
• Wenn ja, wie werden Änderungen an diesen gemeinsamen Teilprojekten gemanagt
• gibt es dafür explizite Richtlinien (z.B. in einem Projekthandbuch, schriftliche Firmenleitlinien, Versionsverwaltungssystem,
...)
• wird die Umsetzung solcher Änderungen geplant / überwacht (Szenarien erfragen)
• Werden von den Teilprojekten unterschiedliche Stände / Versionen / Varianten für verschiedene Projekte vorgehalten
/ entwickelt
• Wenn ja wie werden Änderungen die mehrere Varianten betreffen gemanagt.
• Gibt es von mehreren Projekten verwendete Basisbibliotheken / Programmsysteme
• Wenn ja, wie werden Änderungen an diesen Basisbibliotheken gemanagt
• gibt es dafür explizite Richtlinien (z.B. in einem Projekthandbuch, schriftliche Firmenleitlinien, Versionsverwaltungssystem,
...)
• Werden von den Basisbibliotheken unterschiedliche Stände / Versionen / Varianten für verschiedene Projekte
vorgehalten
• Wenn ja wie werden Änderungen, die mehrere Varianten betreffen, gemanagt.
• Gibt es in diesem Bereich nie, selten, gelegentlich oder oft Problem
• Sind diese Probleme sehr leicht, mit wenig Aufwand, mit merklichem Aufwand oder nur mit großem Aufwand in
den Griff zu kriegen
• Sehen Sie hier für die Zukunft Forschungsbedarf
V13: Werden in Ihren Projekten Dokumente von früheren Projekten wiederverwendet?
wenn ja:
• Welche Typen von Dokumenten (und aus welchen Phasen)
• Werden abhängige Dokumente mit wiederverwendet? Wie werden diese identifiziert?
• Bleibt ein Bezug zu den ursprünglichen Dokumenten erhalten
• Kann man feststellen von wo das Dokument / der Dokumentteil kopiert wurde
• Werden Fehlerbehebung an so kopierten Dokumenten propagiert (d.h. Fehlerbehebung im Originaldokument
kommt auch den Kopien zu Gute. Und umgekehrt)
• Gibt es in diesem Bereich nie, selten, gelegentlich oder oft Problem
• Sind diese Probleme sehr leicht, mit wenig Aufwand, mit merklichem Aufwand oder nur mit großem Aufwand in
den Griff zu kriegen
• Können Sie sich hier technische Hilfestellungen kaum, vielleicht oder gut vorstellen
• Sehen Sie hier für die Zukunft Forschungsbedarf
V14: Wurde bei Ihnen in letzter Zeit ein Versionsverwaltungssystem (oder ein neues CASE-Tool) eingeführt?
Wenn ja:
• Wie war die Akzpetanz der Mitarbeiter in der Anfangsphase (Weigerungen, passiver Wiederstand, Sabotage,
Unbefangenheit, Begeisterung, ...
• Welche Managmentmaßnahmen unterstützten die Einführung (Schulungen, umfangreiche Vorabinformation, Mitbestimmung
der Betroffenen, ...)
• Wie ist die Akzeptanz der Mitarbeiter nach einiger Zeit der Benutzung?
2.3.2.2 Modul: Beschreibungstechniken
Beschreibungstechniken umfassen Techniken zur Beschreibung von Softwareentwürfen, von Softwarespezifikationen oder
von Software-Dokumentationen. Sie besitzen eine strukturierte Form und haben oft diagrammatische Darstellungen. Beispiele
sind: Klassendiagramme, Strukturdiagramme, Use-Cases, Sequenzdiagramme, Automaten, Petrinetze.
2.3.2.2.1Dargestellte Systemaspekte
B2: Besteht die Möglichkeit zur Beschreibung struktureller Information? (Q - ja/nein)
• logische oder physikalische Struktur (Topologie) (Q - ja/nein)
• Beschreibung von Komponenten und Einheiten (Q - ja/nein)
• hierarchische Strukturierung, Modularität, Definition klarer Schnittstellen (Q - ja/nein)
• dynamische Aspekte (Änderung der Kommunikationsstruktur, Hinzunahme neuer Systemkomponenten) (Q - ja/
nein)
Dabei eingesetzte gängige Beschreibungsformen:
• Strukturdiagramm
• Entity Relationship Diagram (ERD)
• Klassendiagramm (z.B.UML, OMT, Booch)
• Klassen-/Rollenbeschreibung
• Instanzendiagramm
• Typdefinition (z.B. SDL-Datentypdefinitionen)
• objektorientierte Beschreibung von Programmstrukturen
• informelle Architekturdarstellung
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 109

• Zuordnung von Prozessen auf Prozessoren (Prozeßdiagramm (Booch), Deployment Diagram (UML))
B3: Besteht die Möglichkeit zur Beschreibung von Verhalten, Dynamik, Abläufen? (Q - ja/nein)
• Vollständige Beschreibung (Q - ja/nein)
• Exemplarisch (Szenarien) (Q - ja/nein)
Dabei eingesetzte gängige Beschreibungsformen
• Prozeßdiagramme (SDL)
• Petrinetze
• Datenflußdiagramme (SA)
• Kontrollflußdiagramme (SA/RT)
• State Transition Diagram (STD)
• Automaten
• State Charts
• Prozeßaktivierungstabelle
• Collaboration Diagram
• Activity Charts
• Message Sequence Charts
• Tabellenartige Aufschreibungen
• Strukturierter Text
• Pseudocode
2.3.2.2.2Zeitaspekte und physikalische Aspekte
B4: Wird die Beschreibung von Echtzeitaspekten benötigt? (Q - ja/nein) (oder sind die benötigten Reaktionszeiten so
gering, daß die heutige Mikroprozessortechnik ausreichend Leistung zur Verfügung stellt?) Wenn ja, dann
• Wird sie durch die Beschreibungstechniken ausreichend unterstützt? (Q, bzw. bieten es die Tools an?)
• Welche Strukturelemente werden damit beschrieben?
• Reaktionszeiten
• Bearbeitungszeiten
• Nachrichtenlaufzeiten
B5: Werden bei der Beschreibung sowohl ereignisdiskrete als auch kontinuierliche Modelle angewendet? (a) beide ,
(b) nur eins der beiden,
• (ereignisdiskret: Zustandsautomaten, -maschinen; durch irgendein geartetes Ereignis (z.B. Wert a überschreitet
Grenzwert a>5) wird ein Zustandsübergang ausgelöst.
• kontinuierlich: In festen Zeitabständen muß eine Berechnung erfolgen)
• Wenn vorher mit (a) geantwortet wurde,
• Wird die Verwendung von den beiden Modellen bei der Beschreibung durch das Werkzeug unterstützt? (Bsp.
hier: Matlab & Simulink )
• Wenn ja,
• Bis zu welcher Phase wird diese Werkzeugunterstützung gewährt (Implementierung, Test, etc.)?
B6: Wird die Modellierung diskreter und kontinuierlicher Systemanteile unterstützt (d.h. z.B. prozessorgesteuerter
Anteile und physikalische Prozesse)? (Q-ja/nein)
2.3.2.2.3Handhabbarkeit
B7: Dienen die Beschreibungstechniken als Kommunikationsgrundlage im gesamten Entwicklungsprozeß, z.B. für
Kommunikation zwischen SW-Entwicklern und Kunden, HW-Entwicklern, Testern usw.? (Q/N)
• Sind die eingesetzten Beschreibungstechniken für die Entwickler auch ausreichend leicht handhabbar und intuitiv
verständlich? (Q - ja/nein)
• Sind die eingesetzten Beschreibungstechniken auch ausreichend einfach verständlich für Personen, die nicht
selbst aus der Softwareentwicklung kommen (z.B. aus dem Maschinenbau) (Q - ja/nein)
• Wie werden im Entwicklungsprozeß Beschreibungstechniken eingesetzt? Zur Beschreibung des Gesamtsystems
(Anwendungskontext), des Nutzungssystems (Hard- und Softwaresystem) und des Softwaresystems?
2.3.2.2.4Qualitätssicherung und Korrektheit
B8: Sind die Beschreibungstechniken ausreichend integriert, d.h.
• Zwischen den unterschiedlichen Beschreibungstechniken
• Besteht eine Möglichkeit der Konsistenzsicherung zwischen den verschiedenen Systemsichten? (Q - ja/nein)
• Besteht die Möglichkeit des automatischer Nachweis der Vollständigkeit (d.h. der Erkennung von offenen Punkten
in der Systembeschreibung)? Falls nein, besteht dazu Bedarf? (Q - ja/nein)
• In den Entwicklungsprozeß
• Gibt es die Möglichkeit, Systeme ablauffähig bzw. simulierbar zu beschreiben?(Q - ja/nein)
• Gibt es die Möglichkeit der Generierung von Testabläufen?
• Besteht eine Möglichkeit der Anbindung an Theorembeweiser / Model Checker zum Nachweisen von Eigenschaften?
Falls nein, besteht dazu Bedarf? (Q - ja/nein)
• Existieren für die Beschreibungstechniken klar (z.B. formal) definierte Syntax und Semantik? Falls nein, besteht
dazu Bedarf? (Q - ja/nein)
110 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

B9: Werden komponentenorientierte Beschreibungstechniken verwendet, d.h. liegen die Beschreibungen in einer
Form vor, daß sich die Entwicklung durch die Verwendung von Konfiguration der Beschreibungen der bestehenden
Komponenten durchführen bzw. unterstützen läßt?
2.4 Modul: Werkzeugunterstützung
W3: Besteht eine ausreichende Durchgängigkeit der Werkzeugunterstützung? Dh. Ist das Werkzeug einsetzbar in
den Phasen/unterstützt die Phasen
• Analyse
•Design
• Implementierung
• Qualitätssicherung/Test
• Service/Wartung/Dokumentation
Im einzelnen:
• Wird Verfolgung einer Anforderung über den Entwurf bis hin zum Code unterstützt? (Q - ja/nein)
• Wird Führung eines Data Dictionary unterstützt, falls nötig? (Q - ja/nein)
• Gibt es Unterstützung des Oberflächenentwurfs (User Interface Builder)? (Q - ja/nein)
• Gibt es Unterstützung von Prototyping? (Q - ja/nein)
• Gibt es Codegenerierung aus dem Entwurf? (Q - ja/nein)
• Gibt es Möglichkeiten zur Einbindung von (speziellen) Komponenten (z.B. Datenbank), falls nötig? (Q - ja/nein)
• Gibt es Unterstützung für die Einbindung von vorhandenem Code / Altsystemen? (Q - ja/nein)
• Wird die Durchführung von Tests unterstützt? (Q - ja/nein)
• Wird Generierung von Benutzermanuals für das entwickelte SW-System unterstützt? (Q - ja/nein)
• Gibt es Unterstützung bei Installation des SW-Systems? (Q - ja/nein)
W4: Erfüllt das verwendete Werkzeug die gestellten Erwartungen hinsichtlich praktischer Einsetzbarkeit?
• Besteht eine ausreichende Konfigurierbarkeit, bzw. was wird hier vermißt z.B. hinsichtlich
• Anpaßbarkeit an den Entwicklungsprozeß / Bediener / Firma
• Anpaßbarkeit der Bedienoberfläche
• Anpaßbarkeit der generierten Beschreibungen
• Auswahl der Zielsprache
• Besteht eine ausreichende Handhabbarkeit, bzw. was wird vermißt z.B. hinsichtlich
• einfache Erlernbarkeit (z.B. homogene Bedienoberfläche)
• Ressourcenbedarf
• Betriebssicherheit
• Antwortzeiten
• einfache Administrierbarkeit
• Ist die Versionsverwaltung und Entwicklung im Team möglich? Falls nein, ist dies erwünscht? (Q - ja/nein)
• Ist die Unterstützung durch Hersteller ausreichend? (Q - ja/nein)
• Ist die Dokumentation ausreichend? (Q - ja/nein)
• SindTutorial / Schulung ausreihend? (Q - ja/nein)
• Ist die Wartung des Werkzeugs ausreichend? (Q - ja/nein)
• Sind die Skalierbarkeit und Erweiterbarkeit für die firmenspezifischen Bedürfnisse ausreichend? (Q - ja/nein)
• Ist die Einbindung von Fremdwerkzeugen (Import / Export von Daten, Aufruf) möglich? (Q - ja/nein)
• Besitzt das Werkzeug dokumentierte Schnittstellen und sind diese ausreichend? (Q - ja/nein)
• Gibt es eine Automatisierung von Aufgaben (Batchsprache, Makros, etc.) ? (Q - ja/nein)
• Ist das Werkzeug plattformunabhängig? (Q - ja/nein)
• Ist die Portierbarkeit des erzeugten Codes ausreichend? (Q - ja/nein)
W5: Unterstützt des Werkzeug eine integrierte Bearbeitung der eingesetzten Beschreibungstechniken?
• Besteht die Möglichkeit der Durchführung von Konsistenzüberprüfungen? (Q - ja/nein)
• Unterstützung von mehreren mögliche Sichten / Darstellungsweisen für die gleiche Information (etwa graphisch /
textuell / tabellenbasiert)
• Editoren für alle Beschreibungstechniken
• einfache Navigation zwischen verschiedenen Beschreibungstechniken
• hypertextartige Verknüpfung mit informellen Texten
• Rückübersetzbarkeit der Änderungen von Beschreibungen auf tieferen Abstraktionsebenen in Beschreibungen
höherer Abstraktionsebenen
• Besteht die Möglichkeit zum Einsatz formaler Methoden (z.B. Verifikation in Form von Model Checking und Theorembeweisen)?
(Q - ja/nein)
2.4.0.1 Gängige Werkzeuge
W6: Welchen Werkzeugtyp nutzen Sie?
• Werkzeuge zu objektorientierten Ansätzen (Q - ja/nein). Nutzen Sie
• Objectory (Methode Booch)
• Rational Rose (Methode UML)
• Rhapsody (Methode UML, Firma iLogix)
• StP (von Aonix; Methoden UML, Booch, OMT)
• Together, Cool Jexx, ObjectiF (UML-Werkzeuge)
• Werkzeuge zu strukturierten Ansätzen (Q - ja/nein). Nutzen Sie
• ereignisgesteuerte Systeme
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 111

• Statemate (Methode SA/RT)
• ObjecTime (Methode ROOM)
• SDT (Methode SDL)
• ASCET SD (Firma ETAS und Bosch)
• transformierende Systeme
• MatrixX (bei BMW)
• Matlab / Simulink
• ASCET SD (Firma ETAS und Bosch)
• Nutzen Sie (Q - ja/nein)
• Esterel (V5 Compiler)
• Metaframe (für bausteinorientierte Dienstentwicklung)
• GRADE (für Modellierung von Geschäftsprozessen)
• ARIS (für Modellierung von Geschäftsprozessen)
2.5 Modul: Qualifikation und interdisziplinäre Zusammenarbeit
Z28: Welche Disziplinen sind an der Erstellung von Systemen mit Embedded Software beteiligt (Maschinenbauer,
Elektrotechniker, Physiker, Informatiker)?
Z29: Wie gestaltet sich die Zusammenarbeit?
Z30: Sehen Sie in der interdisziplinären Zusammenarbeit überhaupt eine Problemfeld oder funktioniert dies in Ihrem
Unternehmen reibungslos? (Q-ja/nein)
• Welche Probleme treten dabei auf?
• Werden die Probleme durchunterschiedlichen Kommunkationsformen, unterschiedlichen Sprachgebrauch, unterschiedlicher
Ausbildungsstände und –inhalte oder durch andere Umstände bedingt? (Q –ja/nein)
• Welche Folgen haben diese Probleme?
• Gibt es Probleme bei der Sensibilisierung von Managementebenen (meist kaufmännische Disziplinen) für die
besonderen Belange bei der Planung und Erstellung von Systemen mit Embedded Software? (Q - ja/nein)
• Gibt es Ansätze um den Schwierigkeiten aus dem Problemfeld interdisziplinäre Zusammenarbeit entgegenzuwirken?
(Q –ja/nein)
• Gibt es für Sie in diesem Themenkomplex einen Handlungsbedarf, z. B. bei der Ausbildung von Ingenieuren und
Informatikern? (Q - ja/nein)
• Was sind Ihrer Meinung nach die wesentlichen Anforderungen für einen Entwickler
• In der Analysephase?
• In der Designphase?
• In der Implementierungsphase?
• In der Qualitätssicherung?
• Im Service und der Wartung?
• Sehen Sie dazu Bedarf bei der Ausbildung von Ingenieuren, Informatikern, Betriebswirten etc.? (Q ja/nein) Wenn
ja, welchen?
2.5.1 Fragen an Informatiker:
Z31: Besitzen Sie Wissen über die Mathematik kontinuierlicher Systeme, über Differentialgleichungen und über
Numerik?(Q –ja/nein)
• Wenn ja, wann in Ihrer Ausbildung oder Ihrem Berufsleben haben Sie sich dieses Wissen angeeignet?
Z32: Haben Sie Grundlagenwissen über Mechanik; Elektrotechnik und Thermodynamik?(Q–ja/nein)
• Wenn ja, wann in Ihrer Ausbildung oder Ihrem Berufsleben haben Sie sich dieses Wissen angeeignet?
Z33: Kennen Sie die Eigenschaften von technischen, also kontinuierlich (analog) wirkenden Systemen und die darin
enthaltenen Größen und deren Ausprägung?(Q–ja/nein))
Z34: Kennen Sie typische Vorgehensmodelle und Methoden bei der Entwicklung von technischen Systemen durch
Ingenieure?(Q–ja/nein))
2.5.2 Frage an Ingenieure:
Z35: Besitzen Sie Wissen über die Mathematik diskreter/ nicht analoger Systeme? (Q–ja/nein)
Z36: Kennen Sie typische Vorgehensmodelle aus der Informatik zur Entwicklung von Software?
2.6 Abschluß
Z37: Haben Sie Anmerkungen zum Fragebogen?
112 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

8 Szenario-Management
8.1 Grundlagen des Szenario-Managements
Auf der Suche nach den Produkten und Märkten von morgen benötigen die Unternehmen ein
geeignetes Werkzeug, mit dem sich zukünftige Erfolgspotentiale aufspüren lassen. Dieses
Werkzeug ist die Szenario-Technik. Am Heinz Nixdorf Institut der Universität Paderborn wurden
bestehende Ansätze der Szenario-Technik aufgegriffen und zum Szenario-Management
weiterentwickelt 1 . Dieses Rahmenkonzept basiert auf den beiden Grundprinzipien „Vernetztes
Denken“ und „Multiple Zukunft“.
Abbildung 35. Die zwei Grundprinzipien des Szenario-Managements.
8.1.1 Vernetztes Denken
Angesichts der zunehmenden Anzahl von gesellschaftlichen und ökologischen Problemen
beginnt sich die Erkenntnis durchzusetzen, daß ein Unternehmen ein Subsystem in einem
Gesamtsystem ist und folglich in einem komplexen Netz von Einflußfaktoren eingebettet ist.
Komplexität wird dabei verstanden als Zusammentreffen von Vielfalt und Dynamik. Dörner
hat in seinem Buch „Die Logik des Mißlingens“ eindrucksvoll aufgezeigt, daß der Mensch nur
sehr begrenzt in der Lage ist, komplexe Zusammenhänge zu erfassen 2 . Mit der Zunahme der
Komplexität versagen auch die traditionellen Managementansätze, die auf einer getrennten
Betrachtung einzelner Funktionsbereiche, Marktsegmente oder Einflußfaktoren beruhen. Die
Wechselwirkungen zwischen den bisher getrennten Betrachtungsbereichen spielen eine immer
1. Gausemeier, J. / Fink, A. / Schlake, O.: Szenario-Management - Planen und Führen mit Szenarien. 2. Auflage,
Carl Hanser Verlag, München, 1996
2. Dörner, D.: Die Logik des Mißlingens - Strategisches Denken in komplexen Situationen, Rowohlt, Reinbek bei
Hamburg, 1992
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 113

größere Rolle. Daher müssen die Unternehmen in Systemen von vernetzen Einflußfaktoren
denken. Wir sprechen hier von „vernetztem Denken“ (Bild 35, links).
8.1.2 Multiple Zukunft
Früher war das prognostische Instrumentarium der Unternehmen nur wenig ausgeprägt. Erst
mit der Verschärfung des Wettbewerbs in den 60er und 70er Jahren wurde es ausgebaut, um
bestmögliche Planungsgrundlagen zu erhalten. Dabei übersahen viele Unternehmen jedoch,
daß sich zukünftige Entwicklungen aufgrund der zunehmenden Umweltdynamik und der zahlreichen
Unsicherheiten immer weniger exakt vorhersagen lassen. Daher versagen viele Langfrist-Pläne,
in denen aktuelle Trends fortgeschrieben und je die Zukunft nach Interessenslage
„rosarot“ geredet oder schwarz gesehen wird. Durch die Erstellung von Szenarien wird die
„Planungsfalle“ umgangen. Die Unternehmen entwickeln bewußt mehrere Möglichkeiten, wie
sich die Zukunft entwickeln könnte. Schwartz sieht den entscheidenden Vorteil einer solchen
multiplen Zukunft darin, daß Führungspersönlichkeiten auf möglichst viele Eventualitäten
vorbereitet werden1 . (Bild 35 rechts).
8.1.3 Phasen des Szenario-Projektes
Ein Szenario ist somit eine allgemeinverständliche Beschreibung einer möglichen Situation in
der Zukunft, die auf einem komplexen Netzwerk von Einflußfaktoren beruht. Das Szenario-
Management erfolgt nach eine Phasenmodell in fünf Phasen, wie sie in Bild 36 dargestellt
sind.
Abbildung 36. Phasenmodell des Szenario-Managements
1. ]Schwartz, P.: The Art of Long View, Currency & Doubleday, New York, 1991
114 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

Szenario-Vorbereitung - Ermittlung von Stärken und Schwächen
Die Aufgaben eines Szenario-Projektes beziehen sich immer auf ein bestimmtes Gestaltungsfeld,
beispielsweise ein Unternehmen („Welches sind unsere Kernfähigkeiten?“), ein Produkt
(„Wie muß unser Produkt gestaltet werden, um am Markt erfolgreich zu sein?“) oder eine
Technologie („Welche Technologie sollen wir einsetzen?“). Daher muß zunächst das Gestaltungsfeld
definiert werden. Anschließend wird das Gestaltungsfeld in seiner gegenwärtigen
Situation analysiert. Dazu können herkömmliche Analyseinstrumente eingesetzt werden. Dies
ist ausführlich in den vorangegangenen Kapitel des Abschlußberichtes erfolgt.
Szenariofeld-Analyse - Identifikation von Schlüsselfaktoren
Mit der Szenariofeld-Analyse beginnt der in den Abbildungen 37 und 38 schematisch dargestellte
Prozeß der Szenario-Erstellung. Dazu wird zunächst ein Szenariofeld definiert, das
genau auf die jeweilige Planungssituation zugeschnitten ist. Es geht in der Regel über das
Gestaltungsfeld hinaus und umfaßt vor allem nicht unmittelbar beeinflußbare Faktoren aus drei
Bereichen: Branche, Branchenumfeld und Globales Umfeld (Abbildung 37 links).
Dieses Szenariofeld wird zunächst durch eine Vielzahl von Einflußfaktoren beschrieben. In
einer Einflußmatrix werden die Beeinflussungen zwischen den Faktoren erfaßt. Für einzelne
Faktoren läßt sich so ermitteln, wie stark sie von anderen Faktoren beeinflußt werden (Passivsumme)
und wie stark sie das System bzw. das Gestaltungsfeld beeinflussen (Aktivsumme).
Beide Kennwerte können in einem System-Grid verzeichnet werden. Aus der Position der Einflußfaktoren
im System-Grid können Rückschlüsse auf ihr systemisches Verhalten und damit
die Eignung als Schlüsselfaktoren gezogen werden (Abbildung 37, Mitte). Eine spezielle Szenario-Software
ermöglicht darüber hinaus die Erfassung und die Einbeziehung indirekter Einflüsse
wie Verkettungen und Rückkopplungen.
Abbildung 37. Szenario-Erstellung I: Vom Szenenfeld zu Zukunftsprojektionen
Mit Hilfe der Kennwerte der Einflußanalyse werden anschließend die Faktoren identifiziert,
die für die Entwicklung des Szenariofeldes charakteristisch sind oder den stärksten Einfluß
ausüben. Diese werden als Schlüsselfaktoren bezeichnet.
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 115

Szenario-Prognostik - Mögliche Entwicklungen beschreiben
Diese Phase ist die Kernphase des Szenario-Managements, denn hier erfolgt der „Blick in die
Zukunft“. Nach der Festlegung eines Zukunftshorizontes werden für jeden Schlüsselfaktor
mögliche zukünftige Entwicklungen, sog. Zukunftsprojektionen ermittelt. Für jeden Schlüsselfaktor
werden mehrere alternative Zukunftsprojektionen entwickelt. Dabei geht es nicht
darum, im Team der Szenario-Ersteller Einigkeit über die zukünftige Entwicklung herzustellen
bzw. die wahrscheinlichste Zukunft zu beschreiben. Das Ziel dieser Phase ist es vielmehr,
bewußt divergierende und auch extreme Projektionen zu erarbeiten, damit die Szenarien
das»window of opportunity«vollständig beschreiben (Abbildung 37, rechts).
Szenario-Bildung - Zukunftsszenarien entwickeln
Szenarien beruhen auf möglichst widerspruchsfreien Kombinationen der in der dritten Phase
ermittelten Zukunftsprojektionen. Dazu werden zunächst in einer Konsistenzmatrix alle paarweisen
Kombinationen von Projektionen auf ihre Verträglichkeit überprüft. Die Szenario-Software
analysiert die vielen Millionen möglichen Kombinationen und identifiziert die
widerspruchsfreien Kombinationsmöglichkeiten. Diese sog. Projektionsbündel werden
anschließend mit Hilfe der Clusteranalyse zu zwei bis fünf Gruppen von ähnlichen Projektionsbündeln
zusammengefaßt. Diese Rohszenarien können mit Hilfe der Multidimensionalen-
Skalierung (MDS) visualisiert werden, so daß die Szenario-Ersteller einen kompakten Einblick
in die zukünftigen Möglichkeiten erhalten (Abbildung 38, Mitte).
Abbildung 38. Szenario-Erstellung II: Von den Zukunftsprojektionen zu den Szenarien
Im letzten Schritt der Szenario-Erstellung werden die einzelnen Rohszenarien analysiert. Die
Zukunftsprojektionen, die in der überwiegenden Anzahl der Bündel eines Rohszenarios vorkommen,
finden Eingang in die Szenarien. Im Zuge eines kreativen Prozesses werden die Szenarien
abschließend in „Prosa“ beschrieben (Abbildung 38, rechts).
116 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

Szenario-Transfer - Strategieentwicklung
Der Szenario-Transfer beginnt mit einer Auswirkungsanalyse. Dazu werden in einer Matrix
die Folgen der erstellten Szenarien für das Gestaltungsfeld systematisch analysiert. Daraus
ergeben sich Chancen und Risiken, die entsprechend ihrer Bedeutung und ihrer Eintrittswahrscheinlichkeit
bewertet werden. Nun werden daraus Strategien und Handlungsempfehlungen
entwickelt. Grundsätzlich besteht die Möglichkeit, sich bei der Planung auf ein Szenario zu
stützen (Fokussierte Strategien) oder mehrere Szenarien in den Planungsprozeß einzubeziehen
(Zukunftsrobuste Strategien).
8.2 Szenariofeld-Analyse
Mit der Szenariofeld-Analyse beginnt der Prozeß der Szenario-Erstellung. Dazu wurde
zunächst ein „Szenariofeld“ definiert. Das Szenariofeld ist ein komplexer Prognosebereich,
dessen zukünftige Entwicklungsmöglichkeiten in Form von Szenarien beschrieben werden.
Drei typische Formen von Szenariofeldern können unterschieden werden:
• Umfeldszenarien: Ein Szenariofeld kann ausschließlich externe, höchstens mittelbar lenkbare
Umfeldgrößen enthalten. Sie eignen sich beispielsweise gut, Marktentwicklungen der
nächsten Jahren darzustellen.
• Gestaltungsfeldszenarien: Ein Szenariofeld kann ausschließlich interne Lenkungsgrößen
enthalten. Solche Szenarien sind „voll lenkbar“ - der Szenario-Anwender kann hier direkt
zwischen den alternativen Szenarien auswählen.
• Systemszenarien: Ein Szenariofeld kann sowohl externe Umfeldgrößen als auch interne
Lenkungsgrößen enthalten. In diesem Fall bildet das Szenariofeld das gesamte System aus
Gestaltungsfeld und Umfeld ab. Wegen der Verbindung von internen und externen Größen
sind die Szenarien nur bedingt lenkbar.
Im Rahmen dieser Vordringlichen Aktion wurde als Szenariofeld „Die Entwicklung von Software
für eingebettete Systeme für die Anwendungsdomänen Anlagen- und Maschinenbau,
Automatisierungs- und Produktionstechnik sowie Verkehrstechnik“ definiert. Insofern enthielt
das Szenariofeld sowohl externe Umfeldgrößen als auch interne Lenkungsgrößen.
8.2.1 Bildung von Einflußbereichen
Aus der in der Regel eher allgemeinen Definition des Szenariofeldes lassen sich Einflußfaktoren
nur „ungeordnet“ ableiten. Es besteht die Gefahr „schleichender Schwerpunktbildung“.
Um dies zu vermeiden, werden zunächst sog. Einflußbereiche identifiziert. Sie stellen die
Schwerpunkte des Szenariofeldes dar und müssen vom Szenario-Team einvernehmlich festgelegt
werden, was auf einem Workshop im Rahmen dieser VA in München der Fall war.
Das Szenariofeld „Die Entwicklung von Software für eingebettete Systeme für die Anwendungsdomänen
Anlagen- und Maschinenbau, Automatisierungs- und Produktionstechnik
sowie Verkehrstechnik“ wurde zunächst in vier Systemebenen eingeteilt (Bild 39).
• Embedded Software (SW): Entwicklungsabteilungen der Unternehmen und somit Gestaltungsfeld
bestehend aus Lenkungsgrößen.
• Branchenumfeld: Das Branchenumfeld umfaßt die direkten Umfeldbereiche eines Unternehmens.
Zu ihm gehören gemäß dem klassischen wettbewerbstheoretischem Ansatz von
Porter die Teilbereiche Lieferanten, Kunden, Komplementärleistungen, Substitutionsleistungen
und Branche.
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 117

• Technologisches Branchenumfeld: Allgemeine Einflüsse aus dem Technologie Umfeld
werden hier besonders wegen der Wechselwirkungen zu dem technischem Gestaltungsfeld
getrennt vom globalem Umfeld aufgeführt. Einflußbereiche sind Informations- und Kommunikations
(IuK)-Technologie sowie Grundlagen-Technologien.
• Globales Umfeld: Das globale Umfeld erfaßt allgemeine wirtschaftliche, politische, gesellschaftliche,
technische und ökologische Faktoren.
U m w e l t
Technik
Branche
IuK Technologie
Lieferanten
G e s e l l s c h a f t
P o l i t i k
Komplementär-
leistungen
Embedded
SW
Substitutions-
K u n d e n
Grundlagen Technologie
l e i s t u n g e n
Ö ko n om i e
Branchenumfeld:
Verkehrstechnik
Anlagen
und
Maschinenbau
Automatisierungsund
Produktionstechnik
8.2.2 Ermittlung von Einflußfaktoren
Die Gliederung des Szenariofeldes in Systemebenen und Einflußbereiche reicht nicht aus, weil
sich deren konkrete Entwicklungsmöglichkeiten nicht konkret beschreiben lassen. Daher sind
die einzelnen Einflußbereiche durch geeignete Einflußfaktoren näher zu beschreiben.
Dazu werden zunächst für die einzelnen Einflußbereiche mögliche Einflußfaktoren identifiziert,
mit denen der gegenwärtige Zustand eines Einflußbereiches, dessen zukünftige Entwicklungsmöglichkeiten
sowie die gegenwertigen und zukünftigen Wechselwirkungen mit anderen
Einflußbereichen weitestgehend beschrieben werden können. Dabei werden bewußt mehr Einflußfaktoren
zugelassen, als später zur Szenario-Erstellung verwendet werden. Mögliche Verfahren
zur Ermittlung von Einflußfaktoren sind Systemische Analysen, Cognitive Mapping,
Methode 6-3-5, Laterales Denken, etc.
Anschließend werden die identifizierten Einflußfaktoren aufbereitet, indem sie wertneutral
beschrieben werden. Zusätzlich wird überprüft, ob die Verteilung der Einflußfaktoren innerhalb
der Einflußbereiche mit den vorgesehenen Schwerpunkten übereinstimmen.
Dies erfolgte ebenfalls im Rahmen eines Workshop in München. Als Ergebnis der Einflußfaktorenermittlung
ergab sich ein Einflußfaktoren-Katalog, mit dem das Szenariofeld umfassend
beschrieben werden konnte.
Gestaltungsfeld
E1 Methodeneinsatz: Formen der Produktentwicklungsmethodik; Bedeutung der Produktentwicklungsmethodik
in den Unternehmen; evtl. separat Methodik der SW-Entwicklung
118 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion
ESW
ESW
ESW
Abbildung 39. Einflußbereiche und Systemebenen

(Durchgängigkeit
E2 Organisation der Produktentwicklung: Arbeitsteilung; Zusammenarbeit mit Unterauftragnehmern;
Verteilte Produktentwicklung; Simultaneous / Concurrent Engineering; Zusammenarbeit
mit angrenzenden Ingenieurdomänen (Mechatronik); Einbindung in den
Produktentwicklungsprozeß (Kooperative Produktengineering)
E3 Investitionsneigung: Neigung und wirtschaftliche Fähigkeit zu investieren; Stellung von
Software im Unternehmen
E4 Kostenmanagement: Einsatz von Zielkostenmanagement; Kostenbewußtsein allgm. Stückkostenminimierung
contra Entwicklungsaufwände. „Unnützes Festhalten an HW-Begrenzungen
aufgrund kurzsichtiger Kalkulationen. Transparenz
E5 Interdisziplinäre Personalpolitik: Verhältnis von Ingenieuren, Informatiker; Fachkräfte,
E6 Qualitätssicherung, -bewusstsein: Maßnahmen zur Einhaltung der Sicherheitsstandards, der
Nachvollziehbarkeit; Testverfahren;
E7 Variantenmanagement: Entwicklung der Variantenvielfalt (Stimulation durch Käufermarkt
etc.); Prozeßbeherrschung, Dokumentation, Flexibilität, Modularität, Transfer, Änderungsmanagement,
Versionen
E8 Know-how Transfer: Personalentwicklungssysteme (Fachlaufbahn; Führungslaufbahn);
Innerbetriebliche Ausbildung; Teilnahme an außerbetrieblichen Fortbildungsmaßnahmen;
Ausgaben der Unternehmen für Aus- und Weiterbildung (Humankapitalinvestitionen); Ausund
Weiterbildung sowie Qualifikation, Technology-Watch, Schulungen, Testphasen
E9 Pionier- und Teamgeist
Branchenumfeld
E10 Qualitäts- und Sicherheitsanforderungen: z.B. Ausfallsicherheit, Redundanz.
E11 Post-Sales-Services: Bedeutung der Marktnähe der Vertriebs- und Wartungsorganisation;
(z.B. Install and Forget); Durchschnittliche Produktlebensdauer; Übliche Gestaltung der
Überg-änge von alten zu neuen Produkten; Entwicklungszeiten; Länge von Produktlebenszyklen;
Lebenszyklusbetrachtung
E12 Branchenstandards: Bedeutung von Branchenstandards; Zusammensetzung von relevanten
Expertengruppen
E13 Schutz von technologischem Vorsprung: Möglichkeit zur Sicherung von technologischem
Vorsprung gegenüber Nachahmung
E14 Wettbewerbsintensität der Hersteller von ESW: Fusionen (Unternehmenszusammenschlüsse
im Feld der Mitbewerber); Art und Umfang des Engagements großer Konzerne im
Markt (High-volume-manufacturer); Globalisierung der Branche (Anzahl und Marktanteil
globaler Anbieter); Anteil kleiner Anbieter / Nischenanbieter
E15 Spektrum der Kundenwünsche: Vielfältigkeit der Kundenanforderungen
E16 Struktur und Macht der Software-Anbieter: Marktmacht der Softwarepaket Anbieter; Einfluß
der Inputs auf Kosten und Leistung; Lieferantenkonzentration; Systemlieferanten; Sortimentspolitik
der Lieferanten; Produktlebenszyklus der Inputs
E17 Struktur und Macht der Hardware-Anbieter: Marktmacht der Lieferanten; Einfluß der
Inputs auf Kosten und Leistung; Lieferantenkonzentration; Systemlieferanten; Sortimentspolitik
der Lieferanten; Produktlebenszyklus der Inputs, insbesondere Prozessorgenerationen
E18 Neue Marktformen, Märkte: Formen der Abwicklung von Geschäften über elektronische
Kommunikationssysteme; Anteil von Electronic Commerce am gesamten Handel; Elektronische
Fernwartung, Service, SW-Downloads auf Zeitbasis; Bereitstellung von Service, z.B.
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 119

Engineering- Leistungen; Bedeutung und Struktur des Post Sales Support; Entwicklung der
traditionellen Wartungsgeschäfts; „maintenance on call“ durch externe Dienstleistungsunternehmen
E19 Markenimage: Erkennbarkeit einzelner Hersteller bzw. Marken; Bedeutung der Hersteller
und Marken im Wettbewerb; globaler Wettbewerb
E20 DAU- Faktor/Systemusability: Einfache Wartung; wenig vs. viel geschultes Personal/
Bediener; Betriebspersonal; Servicepersonal
E21 Planbarkeit des Geschäfts: Komplexität der Unternehmensumwelt, Planungssicherheit; Planungshorizont;
Systemgröße und -komplexität
Technologische Branchenumfeld
E22 Software-Engineering: Entwicklung der Softwaretechnik („Kunsthandwerk“ vs. Intelligente
Software-Bausteine); Kommunikationsorientierung; Software-Agenten; Component- Ware;
Aspektorientierung; Verteilte Intelligenz; Verifikation etc.
E23 Tool Support: Integrierte Ingenieursysteme; Verfügbarkeit von Entwicklungswerkzeugen;
Preise von Entwicklungswerkzeugen; Nutzung von Entwicklungswerkzeugen in der Praxis;
Unterstützung der Entwicklungsphasen durch SW-Tools
E24 Standards und Normen der IT: In Protokollen, Programmierung, HMI; Standards / Zulassungsverfahren;
Branchen, HW, SW; Defacto- Standards, Industriemacht
E25 HW und SW Co-Design Methodik: Grad der Verschmelzung, Co-Design; Standard Designs
(Plattformstrategie); Verknüpfung organisatorisch von HW-SW-Entwicklung als Paradigma
E26 Leistungsfähigkeit der Informationstechnologie: Verarbeitungsgeschwindigkeit von Prozessoren;
Hard- und Software auf der Grundlage hochentwickelter Chiptechnologie (Multimedia-Computer;
Telecomputer; Parallelprozessorsysteme; Multisensor-Roboter)
E27 Autonomie und Vernetzung mechatronischer Systeme: Entwicklung und Einsatzreife von
Robotern; Aufgabenbereiche wie Service-Robotik oder Personel-Robotik. Zusammenspiel
von Sensor-Aktor-Systemen, Vielfalt, Empfindlichkeit, Dimension, phys. Größen von Sensorarten,
Software - Aspekte/Agenten, intelligente Teilkonzepte(alleinstehend)
E28 Innovative Fertigungstechnologien und Werkstoffe: Entwicklung von Fertigungstechnologien
im Umfeld der IuK-Branche, z.B. Halbleiterfertigung. Billige Fertigungstechnologien
für neue Werkstoffe. Entwicklung von Werkstücken oder Werkstoffen, die Eigendiagnosen,
Selbstreparaturen als kennzeichnendes Verhalten aufweisen. Smart Materials.
E29 Intelligente SW- HW- Bausteine: Erfassung verschiedener physikalischer Größen; Informationsvorverarbeitung
vor Ort; Netzfähigkeit durch unterstützte Bussysteme. Bausteine der
Informationstechnologie, die verschiedene Aufgabenbereiche mit einander verbinden und
komplexe Teilaufgaben autonom lösen können. Austauschbare, wartungsfreie Module
(HW,SW). Schnittstellenstandards: logisch und physikalisch; Plug'n'Play; JINI;Sensor und
Anzeige
E30 Bandbreite der Kommunikationsnetze: Nutzer mit Zugang zu einem Netz; Verhältnis von
netzgebundenen zu isolierten Rechnersystemen; Übertragungsgeschwindigkeit; Antwortzeitverhalten;
Informationsverlust während der Kommunikation durch technische Umsetzung;
Bandbreite der Kommunikationsmöglichkeiten Zusicherung von Bandbreiten /ATM Verbreitung
und Akzeptanz; Contentmanagement Wissen, Lösungselemente, Dienstleistungen
E31 Sicherheit der Informationsübertragung: Vermeidung von Verlust oder Verfälschung von
Daten
E32 Wissensmanagement: Beziehungswissen, Expertensysteme, Dokumentation, Archivierung
120 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

Zugriff, Manipulation, Verwaltung
E33 Human Machine Interface: Monitoring der techn. Prozesse; Ausfallzeitenreduzierung, Eingabe,
Ausgabe, Erstellung von SW-Ergonomie für HMI
Globales Umfeld
E34 Bildungssystem: Ausbildung von Fachpersonal; Universitäre vs. andere Formen; Schule
E35 Forschungs- und Entwicklungsaktivitäten: Die FuE-Aktivitäten werden gemessen als
Anteil der Bruttoinlandsausgaben für FuE (GERD = Gross domestic expenditure on R&D)
am Bruttoinlandsprodukt (BIP).
E36 Produkthaftung: Vorfall: Siemens Airbag Kind; Test auch von Software wie auch HW auf
Sonderfälle.
E37 Technologieakzeptanz: Einstellung zur Technik („Eher ein Segen“ vs. „Eher ein Fluch“);
Einstellung zu neuen Technologien; Bereitschaft zum Umgang mit neuen Technologien;
Lernfähigkeit (Anteil der Menschen, die neue Technologien verstehen und nutzen können)
E38 Arbeitskräftepotential: Anzahl potentiell Erwerbswilliger; Zuwanderung von Erwerbswilligen;
Anteil der Frauen an den Erwerbswilligen; »Stille Reserve«
E39 Globalisierung der Produktion: Verlagerung von Produktionsstätten deutscher Unternehmen
ins Ausland (Anteil inländischer/ausländischer Produktionsstätten)
E40 Sicherheitsbewußtsein der Menschen: Grad des Sicherheitsstreben der Menschen in einer
Hochtechnologie.
E41 Innovationsdynamik: Technischer Fortschritt (qualitativ und quantitativ); Wettbewerbsanstrengungen
und Wettbewerbsstärke deutscher Unternehmen
E42 Mobilität: Gesamte räumliche Mobilität im Alltag; Durchschnittliche Kilometerleistung im
Jahr (beruflich; privat)
E43 Umweltpolitik: Bedeutung des Umweltschutzes bei politischen Entscheidungen; Art und
Umfang der Umweltpolitik (Staatliche Vorgaben zur Erreichung von Umweltzielen; ökologische
Komponenten im Steuersystem, etc.); Staatliche Beteiligung an Umweltkosten
8.2.3 Ermittlung von Schlüsselfaktoren
Ein Einflußfaktoren-Katalog enthält in der Regel eine große Anzahl von Einflußfaktoren. Da
sich diese in den folgenden Phasen des Szenario-Managements nur schwer handhaben lassen,
müssen zunächst die wesentlichen Einflußfaktoren identifiziert werden. Das Ergebnis dieser
Unterphase und damit der Szenariofeld-Analyse ist ein verkleinerter Einflußfaktoren-Katalog.
Wir bezeichnen die darin enthaltenen, für das Szenariofeld charakteristischen Einflußfaktoren
als Schlüsselfaktoren.
Direkte Einflußanalyse
Zunächst werden in einer direkten Einflußanalyse die (direkten) Beziehungen der Einflußfaktoren
untereinander bewertet. Für jedes Einflußfaktoren-Paar wird der Einfluß ermittelt, mit
dem der eine Einflußfaktor auf den anderen wirkt - und umgekehrt. Dabei steht die Frage im
Vordergrund: Wenn sich der Einflußfaktor A verändert, wie stark oder wie schnell verändert
sich durch die direkte Einwirkung von A der Einflußfaktor B? Die Bewertung der Einflüsse
erfolgt anhand der folgenden Skala:
• 0 = keine oder sehr schwache Wirkung, d.h. wenn sich Einflußfaktor A sehr stark verändert,
wirkt sich dies gar nicht oder nur sehr schwach auf Einflußfaktor B aus.
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 121

• 1 = schwache oder zeitlich verzögerte Wirkung, d.h. wenn sich Einflußfaktor A verändert,
wirkt sich dies schwach auf Einflußfaktor B aus.
• 2 = mittlere Wirkung, d.h. wenn sich Einflußfaktor A start verändert, beeinflußt das den
Einflußfaktor B mit mittlerer Stärke.
• 3 = starke oder sehr starke Wirkung, d.h. wenn sich Einflußfaktor A leicht verändert,
wirkt sich das sehr stark auf Einflußfaktor B aus.
Die direkten Beziehungswerte werden in einer Einflußmatrix verzeichnet (Bild 40).
Einflußmatrix
Fragestellung: »Wie stark
beeinflußt Einflußfaktor A (Zeile)
Einflußfaktor B (Spalte)?«
Bewertungsmaßstab:
0 = kein Einfluß
1 = schwacher, verzögerter Einfluß
2 = mittlerer Einfluß
3 = starker, unmittelbarer Einfluß
1 Methodeneinsatz
2 Organisation der Produktentw.
3 Investitionsneigung
4 Kostenmanagement
5 Interdisziplinäre Personalpolitik
6 Qualitätsbewußtsein/ -sicherung
7 Variantenmanagement
8 Know-how Transfermaßnahmen
42 Mobilität
43 Umweltpolitik
Passivsumme
2 1 1 2 3 2 2 1
1 2 1 3 2 1 2 3
1 1 2 2 - 2 1
2 -
3
- -
1 2
1
1
1
1
2
-
3
3 2 2 2 1 2 2 2
1 - 2 - - - -
3 1 1 1 3 2 2 2
2
2
2 3
2
- - - - - -
1 - - 1 1 - 1 1
2
Kostenmanagement
Qualitätsbewußtsein/ -sicherung
1 Methodeneinsatz
2 Organisation der Produktentw.
3 Investitionsneigung
4
5 Interdisziplinäre Personalpolitik
6
7 Variantenmanagement
8 Know-how Transfermaßnahmen
9 Team- und Pioniergeist
2 2
2
70 68 51 39 54 70 58 62 50
Wirkungssumme
14 - - - - -
15 - - - - -
11 - - - - -
12 - - - - -
12 - - - - -
16 - - - - -
5 - - - - -
14 - - - - -
6
7
3 = Beispiel
Kostenmanagement (Zeile 4)
beeinflußt die Investitionsneigung
(Spalte 3) stark
und unmittelbar.
Aus der Einflußmatrix
ergeben sich drei wichtige
Kennwerte für das
systemische Verhalten der
Einflußfaktoren:
Abbildung 40. Direkte Einflußmatrix zur Ermittlung der direkten Beziehungen
Aus der Einflußmatrix können verschiedene Kennwerte ermittelt werden:
• Aktivsumme: Die Aktivität eines Einflußfaktors ist die Zeilensumme aller Beziehungswerte.
Sie zeigt die Stärke an, mit der ein Einflußfaktor direkt auf alle anderen Einflußfaktoren
im System wirkt
• Wirkungssumme: Die Wirkungssumme eines Einflußfaktors ist die Zeilensumme aller
Beziehungswerte von Einflußfaktoren mit Gestaltungsfeldfaktoren. Sie zeigt die Stärke an,
mit der ein Einflußfaktor auf das Gestaltungsfeld wirkt.
• Passivsumme: Die Passivität eine Einflußfaktors ergibt sich aus der Spaltensumme. Sie ist
ein Maß dafür, wie stark der jeweilige Einflußfaktor durch alle übrigen Einflußfaktoren
beeinflußt wird.
• Impuls-Index: Durch Division von Aktiv- und Passivsumme erhält man einen Impuls-
Index. Er ist ein Maß für die Einflüsse, die von einem Einflußfaktor ausgehen, ohne daß der
Einflußfaktor dadurch Veränderungen erfährt. Die Einflußfaktoren mit den größten Quotienten
werden daher als impulsive Größen, diejenigen mit den niedrigsten Quotienten als
reaktive Größen bezeichnet.
• Dynamik-Index: Dieser Kennwert errechnet sich durch die Multiplikation von Aktiv- und
Passivsumme. Er ist ein Maß für die Einbindung des Einflußfaktors in das Gesamtsystem
bzw. dessen Einfluß auf das Verhalten des Gesamtsystems.
122 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion
Qualitätsanforderungen
10
2
Post-Sales Services
11
1
Branchenstandards
12
-
2 2 2
Umweltpolitik
Mobilität
42
43
3
3
31 47 26 44 15
Aktivsumme
16
15
11
12
12
16
7
14
58
42
Aktivsumme
Wie stark beeinflußt ein Einflußfaktor
die anderen Faktoren?
Wirkungssumme
Wie stark beeinflußt ein Faktor
die Lenkungsgrößen?
Passivsumme
Wie stark wird ein Einflußfaktor
von anderen Faktoren beeinflußt?

Durch die Ermittlung der verschiedenen Aktivsummen wird es möglich, zwei Varianten der
Einflußanalyse zu verwenden:
• Bei der Interdependenzanalyse sind alle Einflußfaktoren gleichwertig. Es werden die Einflußfaktoren
zu Schlüsselfaktoren, die das gesamte Szenariofeld am besten charakterisieren,
d.h. den größten Einfluß ausüben.
• Bei der Wirkungsanalyse nehmen die lenkbaren Größen eine herausgehobene Stellung ein,
weil die Wirkung des Szenariofeldes auf diese Größen ermittelt wird. Es werden die Einflußfaktoren
zu Schlüsselfaktoren, die die größte Wirkung auf das Gestaltungsfeld ausüben.
Im Rahmen dieser Untersuchung war vor allem der Einfluß der einzelnen Einflußfaktoren auf
die Entwicklung von Software für eingebette Systeme von Interesse. Daher wurde vornehmlich
eine Wirkungsanalyse durchgeführt.
Indirekte Einflußanalyse
Bei der bisherigen Einflußanalye wurden lediglich direkte Beziehungen berücksichtigt - Einflußketten
und Rückverkettungen wurden nicht betrachtet. Um den großen Einfluß solcher
indirekten Vernetzungen zu erfassen, wurde zusätzlich eine indirekte Einflußanalyse durchgeführt,
mit der die bisherigen Ergebnisse verbessert werden konnten.
Mit Hilfe eines am Heinz Nixdorf Institut entwickelten Verfahrens wurde eine indirekte Einflußmatrix
erstellt, in der die indirekten Beziehungen zwischen den Einflußfaktoren verzeichnet
werden, sofern diese größer sind als die direkten Beziehungen (Abbildung 41). Eine solche
indirekte Einflußmatrix läßt sich prinzipiell genauso lesen wie eine direkte Einflußmatrix.
Daher wurden neben Interdependenz- auch indirekte Wirkungsanalysen durchgeführt.
Direkte Einflußmatrix
1
2
3
4
5
6
7
8
9
WS
10
11
1 Methodeneinsatz
2 Organisation der Produktentw.
3 Investitionsneigung
4 Kostenmanagement
1
1
2
2
2
2
1
2
3
1
1
1
2
3
2
1
3 2
2 1
2 0
2 1 2
2
2
2
1
1 14
3 15
1 11
0 12 -
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
16
15
11
12
Berechnung von
Werten für die indirekte
Beeinflussung zwischen
den einzelnen Einflußfaktoren
5 Interdiziplinäre Personalpolitik 2 3 0 0 1 1 2 3 12 0 0 0 0 0 0 12
6 Qualitätsbewußtsein
7 Variantenmanagement
3
1
2
2
2
0
23
2
1
0 0
2 2
0
2 16 2
0 5
0
0
0
0
0
0
0
0
0
0
0
0
16
7
8 Know-how Transfermaßnahmen 3
-
1
- - - 2 3 -
Indirekte Einflußmatrix
14
- - - - - - 6
42 Mobilität
43 Umweltpolitik
Passivsumme
0 12
Methodeneinsatz
2 1,5 1,5 2 3 2 2 1,5 15,5 0,42 0,56 0,5 0,28
- 1 - - - - - - - - - - 2 26
1 20
Organisation der Produktentw. 1,5 2 1 3 2 1,5 2 3 16 0,19 0,21 0,19 0,19
- - 3 1 - - - - - 1 - 1 - 19
3 Investitionsneigung
2,3 2 1 2,2 2 1,1 3 1,7 13,3 0,24 0,32 0,28 0,16
30
13
41
31 14 7 25 17 24 26 12 13 24 14 10 14
4 Kostenmanagement
2 2 3 1,7 1,5 1 2,31,5 1,5 14,9 0,21 0,28 0,25 0,14
0,5 0,4 36
0,2 0,2 24
0,2 0,2 24
0,3 0,2 25
Beispiel für die Wirkungsweise 5 Interdiziplinäre Personalpolitik 2 3 1,5 1 1,5 2 2 3 16 0,25 0,28 0,25 0,19 0,3 0,3 27
indirekter Vernetzung
6 Qualitätsbewußtsein
3 2 2 2 1,5 2 2 2 16,5 0,32 0,42 0,38 0,21 0,4 0,3 32
7 Variantenmanagement
1 2 1,5 2 1,5 1 1,7 1,5 12,2 0,5 0,5 0,5 0,38 0,5 0,5 29
8 Know-how Transfermaßnahmen 3 2,31,1
1,1 3 2,3 1,5 2,3 16,5 0,32 0,42 0,38 0,21 0,4 0,3 31
0 = Direkte Vernetzung: Das Kostenmanagement
hat keinen direkten
Einfluß auf den Team- und Pioniergeist.
2
2
=
Indirekte Vernetzung: Das
Kostenmanagement beeinflußt das
Qualitätsbewußtsein, das wiederum den
Team- und Pioniergeist beeinflußt.
42 Mobilität
43 Umweltpolitik
Passivsumme
Abbildung 41. Indirekte Einflußmatrix zur Ermittlung der indirekten Beziehungen
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 123
12
1
2
13
3
4
42
43
5
6
7
8
9
WS
94 90 83 73 90 88 88 84 80 64 74 60 45 59 52
10
11
12
13
1,7 2,3 2,3 2,3 1,7 2,3 2,3 1,7 2 18,3 2,3 2,3 1,7 1,5
2,3 2,31,7
1,7 2,32,3 1,7 1,7 1,7 17,5 2,3 2 2 1,3
42
43
3
2
89
90

System-Grids
Zur Veranschaulichung der Ergebnisse der direkten und auch der indirekten Einflußanalyse
eignet sich ein System-Grid. Mit den ermittelten Aktiv- und Passivsummen entsteht ein einfach
zu interpretierendes Abbild der Beziehungen im Szenariofeld.
43 40 35 30 25 20 15 10 5 1
Rang Aktivsumme
I
II
IV
36
28
12
19
III
Rang Passivsumme
43 40 35 30 25 20 15 10 5 1
1
10
15
43
43
34
13
43
40
38
42
17
10
16
32
26
31
XI
15
22
20
XII
21
30
33
25
4
VII
14
11
37
39
35
VI
IX
24
23
29
18
9
27
41
X
V
VIII
3
6
8
7
2
5
Impulsive Einflußfaktoren
Aktive Hebel: Nachhaltige Einflußmöglichkeiten auf
das Gesamtsystem / Gestaltungsfeld
Normale Hebel: Lenkungseingriffe können durch die
Systemdynamik kompensiert werden.
Kritische Hebel: Lenkungseingriffe werden durch die
Systemdynamik bedroht und müssen kontrolliert werden.
Schwache Hebel: Lenkungseingriffe müssen häufig
wiederholt oder verstärkt werden.
Dynamische Einflußfaktoren
Extreme Destabilisatoren: Extrem dynamische Größen, die
»nur mit Samthandschuhen« angefaßt werden sollten.
Destabilisatoren: Sehr flexible, dynamische Größen, die häufig
zu Problemen führen.
Moderate Destabilisatoren: Bei behutsamer Veränderung
moderate Systemdynamik.
Potentielle Destabilisatoren: Bei direkter Lenkung hohe
Systemdynamik mit entsprechenden Problemen.
Reaktive und puffernde Einflußfaktoren
Indikatoren: Extrem reaktive Größen. Lenkungseingriffe
gleichen einer Symptombehandlung und sich nicht sinnvoll.
Kritische Indikatoren: Reaktive Größen. Lenkungseingriffe
sind nicht sinnvoll und können zu Problemen führen.
Puffer: Reaktiv-puffernde Größen, mit denen sich das
System bedingt stabilisieren läßt.
Stabilisatoren: Weitgehend selbstregulierende Größen, die
das System stabilisieren.
Abbildung 42. Systemgrid der indirekten Vernetzung nach den Rängen der Aktiv- und
Passivsummen
Rang nach Wirkungssumme
21
13
19
12
28
34
36 38
32
15
40
43
17
22
25
29
42
16
14
15
23
39
31
33
20
10
24
26
27
10
30
Abbildung 43. Auswahl von Schlüsselfaktoren nach den Rängen der Wirkungssumme
und des Dynamik-Indexes
Die zur Auswahl verwendeten System-Grids sind in Abbildung 42 und Abbildung 43 dargestellt.
Auf dem zweiten Szenario-Workshop in Rahmen dieser VA in Paderborn, wurden die
Schüsselfaktoren im Team ausgewählt, die für die Szenarien-Erstellung die Grundlage bilden.
Hierbei wurde insbesondere auf Verteilung der Schlüssefaktoren auf die drei äußeren Systeme-
124 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion
1
Erklärung:
Rang nach Dynamik-Index
11
35
41
18
37
1
I
II
III
IV
V
VI
VII
VIII
IX
X
XI
XII
Schlüsselfaktor (ausgewählt für den Bereich Automatisierungsu.
Produktionstechnik)
Schlüsselfaktor (ausgewählt für den Bereich Verkehrstechnik)
Schlüsselfaktor (ausgewählt für alle drei Bereiche)
Nicht-lenkbarer Einflußfaktor (Umfeldgröße)
Eindeutiger Schlüsselfaktor: Nachhaltige Beeinflussung des
Gestaltungsfeldes sowie erhebliche Vernetzung im Gesamtsystem;
in der Regel sicherer Schlüsselfaktor.
Sehr stark vernetzter Schlüsselfaktor: Erhebliche Vernetzung
und Gesamtsystem und starke Beeinflussung des Gestaltungsfeldes;
in der Regel ebenfalls Schlüsselfaktor.
Sehr stark wirkender Schlüsselfaktor: Nachhaltige Beeinflussung
des Gestaltungsfeldes sowie starke Vernetzung im
Gesamtsystem; in der Regel ebenfalls Schlüsselfaktor
Möglicher Schlüsselfaktor: Starke Beeinflussung des Gestaltungsfeldes
sowie starke Vernetzung im Gesamtsystem;
häufig ebenfalls Schlüsselfaktor.
Sehr stark vernetzter Einflußfaktor: Starke Vernetzung im
Gesamtsystem aber keine signifikante Beeinflussung des
Gestaltungsfeldes; daher spezifische Abwägung notwendig.
Stark vernetzter Einflußfaktor: Vernetzung und Beeinflussung
des Gestaltungsfeldes wie oben.
Sehr stark wirkender Einflußfaktor: Nachhaltige Beeinflussung
des Gestaltungsfeldes aber nur geringe Vernetzung
im Gesamtsystem; daher häufig geringe Wechselwirkung mit
anderen Schlüsselfaktoren.
Stark wirkender Einflußfaktor: Beeinflussung des Gestaltungsfeldes
und Vernetzung wie oben.
Kein Schlüsselfaktor: Keine nachhaltige Beeinflussung des
Gestaltungsfeldes und keine signifikante Vernetzung im Gesamtsystem.
Nur im Ausnahmefall Schlüsselfaktoren.

enen geachtet. Einflußfaktoren aus dem Gestaltungsfeld haben naturgemäß nur wenig Einfluß
auf globalere Faktoren und weisen daher nur geringe Systemaktivität auf. Diese Faktoren wurden
nicht für die Szenarien-Erstellung berücksichtigt. Insofern handelt es sich bei den erarbeiteten
Szenarien um die eingangs erwähnten Umfeldszenarien.
8.2.4 Zuordnung der Schlüsselfaktoren zu den Anwendungsdomänen
Die ausgewählten Schlüsselfaktoren werden nachfolgend auf die Anwendungsdomänen Anlagen-
und Maschinenbau, Automatisierungs- und Produktionstechnik sowie Verkehrstechnik
verteilt.Dabei ergaben sich allgemeine Schlüsselfaktoren, die in jeder Anwendungsdomäne
berücksichtigt wurden, Schlüsselfaktoren die nur in zwei der drei Domänen Verwendung fanden
sowie individuelle Schlüsselfaktoren als auch gleiche Schlüsselfaktoren mit domänenspezifischen
Entwicklungsmöglichkeiten.
Branchenumfeld
Technologisches
Branchenumfeld
Globales
Umfeld
Abbildung 44. Verteilung der Schlüsselfaktoren auf die Systemebenen und
Anwendungsdomänen.
8.3 Szenario-Prognostik
Anlagen- und
Maschinenbau
Automatisierungsund
Produktionstechnik
Verkehrstechnik
Qualitäts- und Sicherheits- Qualitäts- und Sicherheits- Qualitäts- und Sicherheitsanforderungenanforderungenanforderungen
Post-Sales-Services Post-Sales-Services Post-Sales-Services
Schutz von technol. Vorsprung Schutz von technol. Vorsprung Wettbewerbsintensität
Wettbewerbsintensität Wettbewerbsintensität
Neue Märkte/Marktformen
Struktur der SW-Anbieter Struktur der SW-Anbieter
Neue Märkte/Marktformen Neue Märkte/Marktformen
Softwareengineering Softwareengineering Softwareengineering
Tool-Support Tool-Support Tool-Support
Standards und Normen der IT Standards und Normen der IT
HW / SW Co Design
HW / SW Co Design HW / SW Co Design Autonome. vern. mecha. Systeme
Autonome. vern. mecha. Systeme Autonome. vern. mecha. Systeme Kommunikationsnetze
Kommunikationsnetze Kommunikationsnetze
Wissensmanagement
Wissensmanagement Wissensmanagement
Bildungssystem Bildungssystem Bildungssystem
FuE FuE FuE
Globalisierung der Produktion Technologieakzeptanz Globalisierung der Produktion
Innovationsdynamik
Globalisierung der Produktion Sicherheitsbewußt. der Menschen
Mobilität
Umweltpolitik
8.3.1 Vorgehen
In der Szenario-Prognostik geht es darum, für die näher beschriebenen Schlüsselfaktoren mögliche
Zukunftsentwicklungen zu identifizieren und zu beschreiben. Dieser „Blick in die
Zukunft“ erfolgt in den drei Schritten:
• Ermittlung möglicher Zukunftsprojektionen,
• Auswahl der Zukunftsprojektionen und
• Formulierung und Begründung der Zukunftsprojektionen.
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 125

Ermittlung möglicher Zukunftsprojektionen
Ähnlich wie bei der Ermittlung von Einflußfaktoren sind auch in diesem Schritt gleichzeitig
analytische und kreative Fähigkeiten gefragt: Auf analytischem Weg lassen sich Zukunftsprojektionen
von Schlüsselfaktoren mit quantitativ meßbarem Merkmalen erfassen wie beispielsweise
die Entwicklung der Investititionsausgaben von Unternehmen oder des
Forschungshaushaltes der Bundesregierung. Andere Schlüsselfaktoren lassen sich besser qualitativ
beschreiben. Ein exaktes Verfahren zur Ermittlung möglicher Zukunftsprojektionen
kann wegen der starken kreativen Komponente nicht genannt werden. Gausemeier/Fink/
Schlake nennen als Möglichkeiten zur Ermittlung möglicher Zukunftsprojektionen1 :
• Entwicklungen fortschreiben oder simulieren
• Entwicklungen und ihre Merkmale überzeichnen
• Entwicklungen bewußt beschleunigen
• Umfeldentwicklungen bewußt einbeziehen
• Zukunftsprojektionen aus Prozessen entwickeln
Auswahl der Zukunftsprojektionen
Werden die Entwicklungsmöglichkeiten eines Schlüsselfaktors nur durch eine Zukunftsprojektion
beschrieben, so sprechen wir von einem unkritischen Schlüsselfaktor. Die Projektion wird
als unkritische Projektion bezeichnet. Demgegenüber werden Schlüsselfaktoren mit mehreren
Projektionen als kritische Schlüsselfaktoren bezeichnet. Deren Projektionen heißen kritische
Projektionen. In den meisten Fällen liegen kritische Schlüsselfaktoren vor. Es ist das Ziel diese
Schrittes, aus der teilweisen großen Menge möglicher Zukunftsprojektionen zwei oder drei
geeignete Projektionen auszuwählen, mit denen die Entwicklungsmöglichkeiten beschrieben
werden können.
Formulierung und Begründung der Zukunftsprojektionen
Im Anschluß an die Auswahl der Zukunftsprojektionen müssen diese so formuliert und
begründet werden, daß sie auch von Unbeteiligten leicht und schnell verstanden werden. Daher
sollte eine Zukunftsprojektion zunächst eine prägnante Kurzbezeichnung erhalten. Neben
einer Kurzbezeichnung bedarf es einer ausführlichen Beschreibung und Begründung der
Zukunftsprojektion.
Projektionskatalog der Schlüsselfaktoren
Zunächst werden die Schlüsselfaktorprojektionen der Schlüsselfaktoren beschrieben, die in
allen Anwendungsdomänen Berücksichtigung finden. Anschließend werden die Anwendungsdomänen
getrennt betrachtet und jeweils die zu ergänzenden Schlüsselfaktoren mit ihren Ausprägungen
aufgelistet.
1. Gausemeier, J. / Fink, A. / Schlake, O.: Szenario-Management - Planen und Führen mit Szenarien. 2. Auflage,
Carl Hanser Verlag, München, 1996
126 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

Allgemeine Projektionen
S16 Bandbreite der Kommunikationsnetze
S16a Hochleistungsnetze zwischen Hi-Tech Regionen:
Die stürmische Weiterentwicklung der Kommunikationstechnik in Richtung hoher
Bandbreiten ermöglicht völlig neue Anwendungen über Kommunikationsnetze zu
betreiben. Allerdings ist das Preis/Leistungsverhältnis der Kommunikationsanwendungen
nicht überall attraktiv. Insbesondere hohe Bandbreiten sind nach wie vor nur
für wenige erschwinglich. Florierende Wirtschaftsregionen sind aber bereit die hohen
Preis des Fortschritts zu zahlen. Es entsteht ein globales Ungleichgewicht, von denen
die reichen Industrieregionen vornehmlich profitieren
S16b Globale Hochleistungsnetze für Kommunikation
Die stürmische Weiterentwicklung der Kommunikationstechnik in Richtung hoher
Bandbreiten ermöglicht völlig neue Anwendungen über Kommunikationsnetze zu
betreiben. Zudem ist das Preis/Leistungsverhältnis der Kommunikationsanwendungen
so attraktiv, dass es zu einem massiven Ausbau der Telekommunikation kommt.
Individuelle, mobile Kommunikationseinr-ichtungen ermöglichen eine sichere Kommunikation
beliebiger Personen und technischer Produkte rund um die Welt. Hohe
Bandbreiten erlauben den effizienten Einsatz von technischen Applikationen über die
Netze. Durch die Vernetzung entsteht ein globales Dorf.
S16c Massenkommunikationsnetze ohne Hi-Tech Applikationen
Die Ausbreitung der Telekommunikation bleibt hinter den euphorischen Erwartungen
zurück. Gründe hierfür liegen einerseits in dem schlechtem Preis/Leistungsverhältnis
sowie dem unattraktiven Angebot. Die „Quality of Service“ (Echtzeitanforderungen,
garantiertes Antwortzeitverhalten, etc.) gemäß der Ansprüche von Hi-Tech Anwendungen
ist nicht zuverlässig genug. Lediglich die mobile Telefonie hat eine kostengünstige
Massenausdehnung mit hinreichender Qualität erreicht.
S17 Autonome vernetzte mechatronische Systeme
S17a Teure AMS Lösungen für Spezialgebiete
Autonome vernetzte mechatronische Systeme wurden bereits seit Jahren erprobt. Ihre
Qualität und Zuverlässigkeit ließen einen uneingeschränkten Einsatz zu. Allerdings
sind die Entwicklungskosten immer noch zu hoch für viele Anwendungen. Sie finden
daher hauptsächlich Verwendung in Spezialanwendungen wie z.B. in der Avionik.
S17b Mechatronischer Ameisenhaufen
Autonome vernetzte mechatronische Systeme gehören zum State-of-the-art moderner
Industrieerzeugnisse. Sie halten in mehr Produkten wie Automobilen oder Weiße
Ware Einzug und agieren zunehmend im Verbund dynamisch und dezentral. Neue
Paradigmen der Steuerungs- und Automatisierungstechnik entstehen. Die Beherrschbarkeit
selbst komplexer Systeme ist technisch gewährleistet.
S17c Massenware „AMS“
Autonome vernetzte mechatronische Systeme gehören zum State-of-the-art moderner
Industrieerzeugnisse. Ihre Verbreitung ist dank ihrer günstigen Realisierung durch flexible
Module/Komponenten rasant. Allerdings werden sie nur innerhalb sicherheitsunkritischen
Systemen eingesetzt wie dem intelligentem Haus beispielsweise.
Komplexe Systeme mit Echtzeitanforderungen im Millisekundenbereich sind derzeit
noch nicht ausreichend zuverlässig aufgrund mangelnder Garantie des Antwortzeitverhaltens
einzelner Komponenten.
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 127

S18 Tool Support
S18a Feld-Wald-und-Wiesen Tools
„Feld-Wald-und-Wiesen“-Software-Werkzeuge finde aller Orts in den Entwicklungsabteilungen
Einsatz. Charakteristisch sind ihre geringe Mächtigkeit und immense
Spezialisierung auf Sonderfälle. Die Software-Tool Kosten sind verhältnismäßig
gering und bewegen sich im Shareware-Bereich. Das erklärt auch ihre hohe Verbreitung
und Beliebtheit. Allerdings unterstützen sie den durchgängigen Entwicklungsprozeß
nur mäßig. Insbesonders disziplinübergreifende Aufgabenstellungen sind
lediglich als Speziallösungen erhältlich.
S18b Breite Palette hochwertiger Entwicklungsumgebungen
Effiziente Entwicklungswerkzeuge werden zu fairen Preisen angeboten. Sie lassen
sich leicht zu mächtigen Entwicklungsumgebungen konfigurieren. Phasen- und disziplinübergreifendes
Arbeiten unterstützen sie optimal. Der Aufwand für die Einarbeitung/Schulung
ist verhältnismäßig gering. Die gesamten Investitionskosten für
derartige Entwicklungsumgebungen (Total Costs of Ownership) sind so attraktiv, dass
sie auch für Standardentwicklungen verwendet werden.
S18c Entwicklungsumgebungen nur für hoch-komplexe Produkte
Effiziente Entwicklungsumgebungen sind nur für einen hohen Preis zu erwerben.
Phasen- und disziplinübergreifendes Arbeiten unterstützen sie zwar gut, aber der Aufwand
für die Einarbeitung/Schulung ist verhältnismäßig hoch. Die gesamten Investitionskosten
für derartige Entwicklungsumgebungen (Total Costs of Ownership) sind
nur für teure Entwicklungen wie in der Flugzeugindustrie wirtschaftlich.
S19 HW/SW Co-Design
S19a „Bastellösungen“ stillen den Bedarf
Die zunehmende Durchdringung der eingebetteten Systeme in Industrieerzeugnissen
führt zu einen verstärktem Bewußtsein auf Management- und Systementwicklerebene.
Vielerorts sind die Unternehmen bemüht Entwicklungsprozesse effizient und
verzahnend zwischen einzelnen Ingenieurdisziplinen zu gestalten. Allerdings fehlen
die entsprechenden Methoden und Werkzeuge dazu. Insbesondere die Bedeutung des
Hardware/Software Co-Designs sind erkannt, können aber nicht in voller Konsequenz
erschlossen werden. Prototyphaft werden Lösungen bei Bedarf entwickelt.
S19b Neues Selbstverständnis der integrierten Systementwicklung
Die zunehmende Durchdringung der eingebetteten Systeme in Industrieerzeugnissen
führt zu einen verstärktem Bewußtsein auf Management- und Systementwicklerebene.
Methoden und Werkzeuge für die integrierte Systementwicklung werden vielerorts
von den Unternehmen erprobt und mit Erfolg eingesetzt. Es zeichnet sich ein
neues Selbstverständnis der integrierten Systementwicklung ab, indem Software- und
Hardwarefunktionalität gleichberechtigt sowie aufeinander abgestimmt entwickelt
wird.
S19c Integrierte Systementwicklung nicht standesgemäß
Eingebettete Systeme in Industrieerzeugnissen werden weiterhin relativ isoliert entwickelt.
Seitens der Entwickler wie des Führungspersonals wird keine Handlungsnotwendigkeit
gesehen, die Systementwicklung stärker integrativ zu gestalten. Gründe
hierfür liegen zum einen an der mangelnden Bereitschaft, Standesdenken in den Entwicklungsabteilungen
zu überwinden sowie der unzureichenden Nutzenargumentation
und zum anderen an der unbedeutenden Weiterentwicklung von Methoden und
Werkzeugen zum integrativen HW/SW-Co-Design.
128 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

S20 Softwareengineering
S20a Software-technische Komplexität unbewältigt
Software bestimmt Funktionalität und Kundenutzen entscheidend. Ein erheblicher
Teil der Wertschöpfung entfällt auf Software. Software ist aber nach wie vor mehr das
Werk von individuellen Künstlern als das Resultat eines transparenten, reproduzierbaren
Prozesses. Standardisierte Bausteine sind die Ausnahme. Es kommt immer wieder
zu Parallelentwicklungen bzw. das Rad wird immer wieder neu erfunden. Sehr hohe
Entwicklungskosten beeinträchtigen den Geschäftserfolg. Das Problembewußtsein
festigt sich in den Köpfen.
S20b Software-Architekten der neuen Generation
Software bestimmt Funktionalität und Kundenutzen entscheidend. Ein erheblicher
Teil der Wertschöpfung entfällt auf Software. Softwareentwicklungsstandards (Entwicklungsmethoden,
Entwicklungsumgebungen und QS-Verfahren) haben sich
durchgesetzt. Es gibt ein außerordentlich großes Angebot von hochwertigen Softwarebausteinen
zu niedrigen Preisen. Software-Broker stellen über die Kommunikationsnetze
für jedweden Zweck Softwarebausteine zur Verfügung. Die Hersteller von
Softwaresystemen können sich auf die Entwicklung der Systemarchitektur und die
Integration der Softwarebausteine konzentrieren. Selbst komplexe Softwaresysteme
entstehen schnell, kostengünstig und mit hoher Qualität.
S20c Isolation der Informatik:
Software bestimmt Funktionalität und Kundenutzen entscheidend. Ein erheblicher
Teil der Wertschöpfung entfällt auf Software. De facto-Standards und proprietäre Entwicklungsumgebungen
erlauben es fast jedermann, Software zu erstellen. Das Angebot
ist nahezu unüberschaubar; die Qualität ist aber gering. Software erhält das Image
einer billigen Massenware. Dadurch ist es den Kunden schwer zu vermitteln, für Software
einen hohen Preis zu zahlen. Die Informatik zeigt sich wenig Interesse am Massenartikel
„Software“ und konzentriert sich stärker auf formale Aspekte als dem
Softwareengineering das Qualitätssiegel zu verpassen.
S20d Neue Softwarekrise
Software bestimmt weder Funktionalität noch Kundennutzen entscheidend. Unprofessioneller
Umgang mit Software in der Systementwicklung führte in der letzteren Vergangenheit
zu vielen Fehlern. Kunden wünschen ausdrücklich verstärkt nur
Basisfunktionalität und haben ihr Vertrauen in software-dominierte Systeme verloren.
Der hohe Imageverlust der Softwareindustrie nach der Jahr-2000-Problematik, den
Mißbrauch von Informationsnetzen und der mangelnden Qualität in sicherheitsrelevanten
Umgebungen (wie Flugzeugen) wirft einen großen Schatten auf die allgemeine
Akzeptanz hoch-technischer Systeme. Softwareentwickler stehen zunehmend
unter Erfolgsdruck.
S21 Wissensmanagement
S21a Aufwendige Insellösungen
Die Verarbeitung von fallspezifischem Wissen in Echtzeit gewinnt für eingebettete
Systeme zunehmend an Bedeutung. Die Autonomie der Systeme kann dadurch entscheidend
erhöht werden. Voraussetzung dafür ist aber das Vorhandensein und die
Aufbereitung einer entsprechenden Wissensbasis. Dieses ist beides nur mit hohem
Aufwand möglich und rentiert sich daher nur in kostenintensiven Entwicklungsprojekten
(z.B., Online-Fehlerdiagnose Systeme in der Verkehrtstechnik).
S21b XPS durchdringen den Alltag
Die Verarbeitung von fallspezifischem Wissen in Echtzeit gewinnt für eingebettete
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 129

Systeme zunehmend an Bedeutung. Die Autonomie der Systeme kann dadurch entscheidend
erhöht werden. Voraussetzung dafür ist aber das Vorhandensein und die
Aufbereitung einer entsprechenden Wissensbasis. Solche Wissensbasen sind für die
verschiedensten Anwendungen verfügbar und einfach portierbar auf neue Module.
Dank von Standardisierungen geschieht dies sehr kostengünstig. Expertensysteme
(XPS) finden eine breite Verwendung und setzen sich im Alltag vielerorts unbemerkt
durch.
S21c Klassifikation nur anhand sicherem Wissen
Die Verarbeitung von fallspezifischem Wissen in Echtzeit gewinnt für eingebettete
Systeme zunehmend an Bedeutung. Die Autonomie der Systeme kann dadurch entscheidend
erhöht werden. Voraussetzung dafür ist aber das Vorhandensein und die
Aufbereitung einer entsprechenden Wissensbasis. Die vorhandenen Wissenbasen bilden
allerdings im wesentlichen nur Informationstrukturen ab. Automatisches Schließen
ist wenig entwickelt. Für Diagnose- und Klassifikationszwecke eignen sich diese
Systeme aber weitestgehend.
S21d Komplexität ist für XPS nicht wirtschaftlich durchdringbar
Die Verarbeitung von fallspezifischem Wissen in Echtzeit spielt für eingebettete
Systeme keine wesentliche Rolle. Weder sind die Anwendungsfelder ausreichend
durch Wissensbasen beschrieben, noch sind die Schlußregeln und Constraints für
Deduktionssysteme der jeweiligen Fälle erarbeitet. Lediglich simple Anwendungen
von unbedeutender Natur sind realisiert.
S22 Forschungs und Entwicklungsaktivität (FuE)
S22a Industrie bewertet FuE als strategisch entscheidend
Angesichts zurückgehender Leistungsfähigkeit der Hochschulen auf dem Gebiet der
Eingebetteten Systeme treiben die Unternehmen ihre Produktinnovationen eigenständig
voran. Den steigenden FuE-Investitionen begegnen die Firmen mit eigenen Kompentenzzentren
oder durch verstärkte vorwettbewerbliche Kooperationen anhand von
Kernkompetenzen.
S22b Signifikant höhere Investitionen beider Seiten
Durch enge Kooperationen von Hochschulen, Unternehmen und Politik gelingt es, die
Forschung und Entwicklung effektive zu koordinieren. Investitionen und Risiken sind
verteilt und Doppelarbeiten können weitgehend vermieden werden. Neuartige Transfereinrichtungen
ermöglichen u.a. auch KMUs am raschen Fortschritt mit weniger
Mitteln zu partizipieren. Durch diese konzertierte Aktion wird das vorhandene Knowhow
optimal genutzt.
S22c Nutzen der FuE seitens der Industrie in Frage gestellt
Die Unternehmen bringen in immer schnellerer Folge neue Produkte auf den Markt
und müssen immer mehr Ressourcen in FuE investieren. Gleichzeitig erschöpft sich
die Aufnahmebereitschaft des Marktes für Produktinnovationen, was zum Umsatzrückgang
führt. Die Situation eskaliert und viele Unternehmen steigen aus der FuE-
Spirale aus. Insgesamt sinken die Forschungs- und Entwicklungsaktivitäten.
S23 Globalisierung der Produktion
S23a Aufwind der Schwellenländer durch steigende Qualität der Arbeitskräfte
Der Mangel an qualifizierten Arbeitskräften in Deutschland und den anderen Industrienationen
ist signifikant. Die Ausbildungssysteme kommen nur langsam aufgrund
der Ausbildungsdauer dem Bedarf nach. Einige Schwellenländer wie Indien oder
Ägypten genießen dank ihrer progressiven Bildungspolitik einen Aufwind und stellen
130 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

Fachkräfte in einigen Bereichen wie der Softwareentwicklung zur Verfügung.
S23b Billiglohnländer geraten ins Hintertreffen
Politische Instabilitäten und Naturkatastrophen führen zu einem Rückgang der Investitionsneigung
deutscher Unternehmen in sog. Billiglohnländern. Steigender Automatisierungsgrad
der Produkte sowie erhöhter Bedarf an hochqualifiziertem Personal
in Produktion und Betrieb veranlassen Unternehmer heimische Standorte zu bevorzugen.
Die Billiglohnländer geraten zusehends ins Hintertreffen.
S23c Verteilte Wirtschaftsräume mit Eigenfokus
Neben politischen Allianzen von Wirtschaftsregionen spielen vielmehr die technischen
Voraussetzungen von Wirtschaftsräumen eine dominierende Rolle. Hochentwickelte
Regionen sind Magneten für neue innovative Unternehmen mit Hi-Tech
Produkten. Die Verfügbarkeit von hochqualifizierten Arbeitskräften und modernsten
Kommunikationsanbindungen sowie hoher Lebensqualität sind entscheidende Standortfaktoren.
Es entstehen mehrere Hi-Tech Regionen wie das Silicon Valley.
S24 Bildungssystem
S24a Öffentliche Bildungsversorgung gewährleistet
Im Zuge der Verkürzung von Studienzeiten werden fachliche Inhalte gestrichen und
die Vermittlung von Sozialkompetenz gefördert. Da an dem System der Einheitshochschulen
festgehalten wird, kommt es zu einer Angleichung auf niedrigem, fachlichem
Niveau
S24b Breite Spitze hoch qualifizierender Ausbildungsformen
Aufgrund des politischen Drucks wird die Hochschullandschaft flexibilisiert und die
einzelnen Hochschulen erhalten größere Gestaltungsspielräume. Es bilden sich Spitzenuniversitäten
und Hochschulen mittlerer Qualität. Fachwissen auf hohem Niveau
und Sozialkompetenz werden gleichermaßen vermittelt. Parallel entwickelt sich ein
reichhaltiges Angebot aktueller Ausbildungsberufe für technische Aufgaben.
S24c Amerikanisches Modell mit privatwirtschaftlicher Förderung
Die deutsche Hochschullandschaft ist starr organisiert. Die rigiden Prüfungs- und Studienordnungen
orientieren sich vorwiegend an bestehendem Fachwissen und vernachlässigen
die Vermittlung von Sozialkompetenz. Sie erlauben nur geringe
Unterschiede zwischen den Hochschulen und führen zu geringer Flexibilität. Aktuelle
Inhalte finden nur langsam Eingang in die Ausbildung. Die Unternehmen fördern
daher zunehmend privatwirtschaftliche Einreichtungen zur Vermittlung aktuellem
Fachwissen und nötiger Sozialkompetenz. Allerdings sind diese Plätze begrenzt.
Zusätzliche und identische Projektionen für den Anlagen- und Maschinenbau sowie der
Automatisierungs- und Produktionstechnik
S25 Standards u. Normen der IT
S25a Isolierte Standards
In einigen Bereichen können sich Standards und Normen etablieren. Es werden allerdings
nur Teilbereiche angeschnitten. Insbesondere die hohe Verzahnung vieler Disziplinen
wird durch isolierte Insellösungen nicht unterstützt. Es entstehen viele De
facto- und Hersteller-spezifische Standards.
S25b Übergreifende Standards
Übergreifende Standards lösen das Vielfaltsproblem. Die betroffenen Ingenieurdisziplinen
arbeiten gut zusammen. Dank übergreifender Standards und Normen ist es ein-
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 131

fach geworden, komplexe Produkte einfach zu spezifizieren und Änderungen
nachzuvollziehen.
S26 Schutz von techn. Vorsprung
S26a Wirksames Patentsystem
Ein international funktionierendes Patenwesen sichert das geistige Eigentum von Forschungstreibenden.
Die effektive Verfolgung von Patentrechtsverletzungen auf internationalem
Niveau sorgt für die Durchsetzung der Ansprüche von Patent- und
Gebrauchsmusterinhabern.
S26b „Haifischbecken“ voller Ideen
Ein komplexes und zu langsames Patentwesen kann den Schutz von technologischem
Vorsprung nicht garantieren. Es gelingt nicht, einen rechtlichen Rahmen zu schaffen,
um international geistige Eigentumsrechte zu definieren und durchsetzen zu können.
Die einzige Möglichkeit zur Sicherung eines technologischen Vorsprungs besteht in
dessen kontinuierlichem Ausbau und der Konzentration auf schwer kopierbare Innovationen
(z.B. Software oder komplexe Fertigungstechnologien).
S26c Schutzwahn
Der geistige Schutz nimmt unsinnige Formen an. Jeder schützt sich alles mögliche.
Eine größer werdende Gruppe von Bürgern versucht durch Nutzung des Patentwesen,
sich individuell zu bereichern. Von lukrativ erscheinenden Telefonnummern über
Internetdomains bis hinzu Software-Routinen/-algorithmen wird alles „für ein paar
Mark“ angemeldet und belegt.
S27 Struktur der Software-Anbieter
S27a "Microsoft vs. Oracle-Variante"
Ein oder zwei dominate Anbieter von Softwareentwicklungswerkzeugen setzen sich
durch. Es gelingt ihnen 90% des Bedarfs mit ihren Tools zu decken. Die Giganten
können sich dem Innovationsdruck durch ihre Machtstellung zeitweise verschließen.
Die Innovationsgeschwindigkeit wird gebremst.
S27b Einige Key-Player mit hohem Reifegrad
Einige Key-Player setzen sich als Anbieter für Tools durch. Ihre Werkzeuge zeichnen
sich durch hohen Komfort und Reifegrad aus. Die Tools ermöglichen die rasche Entwicklung
neuer eingebetteter Systeme. Die Branche kann Innovationen im hohen
Maße schnell und sicher umsetzen.
S27c Open-Source statt teure SW-Lizenzen
Source Codes von Entwicklungswerkzeugen und Steuer-/Regelroutinen werden den
Entwicklern frei zu Verfügung gestellt. Die Tools werden durch die Entwickler Community
schnell um Spezialfälle erweitert. Entwickler rund um den Globus entwickeln
Routinen, testen Module und berichten über Stabilität und Einsatzverhalten. Insbesondere
der Vielfalt der durch den Echtzeit-Betrieb entstehenden Anwendungsprobleme
wird schnell gerecht.
Zusätzliche Projektionen für den Anlagen- und Maschinenbau
S28 Innovationsdynamik
S28a Unbedeutende Innovationen werden umgesetzt
Innovationen beziehen sich im wesentlichen nur auf Zusatzfunktionen. Sie beeinflussen
den bisherigen Erfolg von Produkten nur unwesentlich. Lebenszyklus und
132 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

Umsatzerwartungen werden erwartungsgemäß erfüllt. Beim Wechsel zur neuen Generation
werden die Innovationen automatisch mit eingekauft. Sie stellen aber keinen
Grund zum vorzeitigen Wechsel dar.
S28b Dynamische Entwicklung mit Erfolg
Die Produktlebenszyklen und Time-to-market verkürzen sich weiter. Es entsteht ein
Forschungs-und-Entwicklungs-Wettlauf in der Industrie: Was gestern hinter den technischen
Möglichkeiten lag, wird heute schon angeboten - das Neue ist das einzig
Beständige.
S28c Verlangsamung der Innovationsgeschwindigkeit
Neue Technologien führen zu neuen Produkten, die die Wettbewerbsfähigkeit konventioneller
Produkte in Frage stellen und damit deren Produktlebenszyklus verkürzen.
Da die damit verbunden Umsätze aber nur „zeitlich nach vorne“ geschoben
wurden, geraten die Unternehmen in eine Beschleunigungsfalle. Es kommt zu einer
FuE-Eskalation, aus der sich immer mehr Unternehmen aufgrund der geringeren und
immer unsicheren Erfolge zurückziehen. Die Innovationsgeschwindigkeit geht langfristig
zurück.
S29 Neue Märkte/Marktformen
S29a Dynamischer Modulmarkt
Die Forderung der Kunden nach modulorientierter Kompaktbauweise von Maschinen
und Anlagen nimmt zu. Die konfigurierbare Maschine bringt nicht nur erhöhte Flexibilität
in die Fertigungsprozesse der Kunden, sie hilft auch Kosten bei den Anbieter
einzusparen. Diese richten ihr Angebot zwangsläufig immer mehr um. Der Sondermaschinenbau
gerät aufgrund der günstigen universal Anlagen stark kostentechnisch
unter Druck. Die Integration in den technischen Prozeß nimmt stetig ab. Die austauschbaren
Module führen wegen etablierter Standards zu einer verstärkten Dynamik
im Modulmarkt.
S29b Komplett Lösungsanbieter setzen sich durch
Weltweit wünschen die Kunden einen Ansprechpartner für komplette Fertigungsanlagen.
Die Rolle dieser Generalunternehmer wird von den großen Anbietern der Branche
bereitwillig angenommen. Aus Gründen von Kosteneinsparungen und höherer
Verfügbarkeit beginnen sie zudem ihr Angebot zu erweitern. Es entstehen „All-purpose“
Anbieter, die den Kunden komplette Lösungen aus einer Hand verkaufen.
S29c Klassische Märkte dominieren
Die Märkte im Anlagen- und Maschinenbau werden als stabil bezeichnet. Wesentliche
Änderungen der Angebots- oder Nachfragestrukturen zeichnen sich nicht ab.
Mögliche Gründe hierfür liegen in der geringen Innovationsgeschwindigkeit bzw. im
langsameren Durchdringen der Anlagen und Maschinen mit Informationstechnik, als
allgemein erwartet worden war.
S29d Käufermarkt verlangt höhere Integration in das Prozeß-Know-how
Kunden erwarten von den Maschinenbauern eine stärkere Auseinandersetzung mit
ihren Fertigungstechnologien und -prozessen. Als Folge entstehen vermehrt Individuallösungen.
Die steigenden Kosten können aber nur bedingt auf die Kunden abgewälzt
werden, da diese nicht zögern auf die breite Palette der Anbieter
zurückzugreifen. Anbieter mit stark ausgeprägter Kunden- und Prozeßorientierung
agieren klar erfolgreicher.
S30 Post Sales Services
S30a Ferndiagnose- und Softwaredienste
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 133

Aufgrund der Vernetzung von Anlagen und Maschinen über IuK-Techniken gelingt es
den Herstellen verstärkte Post Sales Service zu bieten. Softwarewartung und Upgrades,
Selbstdiagnose mit Expertensystemen, Tele-Monitoring der Prozeß- und
Betriebsparameter gehören zu typischen Services-Verträgen mit den Kunden. Ihr
Anteil gewinnt zunehmend Bedeutung am Geschäftserfolg.
S30b Tele-Konfiguration ohne Service-Techniker
Modularer Anlagen- und Maschinenbau ermöglicht den Betreibern Wartungs- und
Umrüstungsarbeiten mit gering geschultem Personal vor Ort durchzuführen. Bei
Bedarf können technische „Call-Center“ mit Hilfe von Augmented Reality zugeschaltet
werden. Das lästige Warten auf Service-Techniker entfällt.
S30c Fernbetrieb von stand-alone Anlagen
In vielen Bereichen des Anlagen- und Maschinenbau führen die Innovations- und
Entwicklungsanstrengungen der Hersteller zum Fernbetrieb von „Stand-alone Anlagen“.
Gut ausgebildete Techniker bedienen gleich mehrere Anlagen im Fernbetrieb.
S31 Qualitäts- und Sicherheitsanforderungen
S31a Qualität und Sicherheit nicht kaufentscheidend:
Die allgemein etablierten Qualitäts- und Sicherheitsstandards werden von Unternehmen
mühelos eingehalten. Die Kunden erwarten über diese Standards vor allem technischen
Funktionsumfang, lange Lebensdauer und gute Service-Verträge. Qualitätsund
Sicherheitsanforderungen stehen nicht an erster Stelle der kaufentscheidenden
Faktoren.
S31b Hohes Maß an Qualität erforderlich - Preis sekundär
Die Kunden haben ein stark ausgeprägtes Bewußtsein für den Preis von Qualität. Präzision
und Verläßlichkeit stehen noch vor Funktionsumfang oder Service. Der Preis
ist lediglich sekundär
S31c Qualitätskrise
Es gelingt den Unternehmen nicht, bei komplexeren Produkten die hohen geforderten
Qualitätsmaßstäbe zu erreichen. Preislich liegen sie zudem über den international vergleichbaren
Angeboten. Kunden wandern ins Ausland ab. Ausländische Kunden kaufen
bei der Konkurrenz auf den Weltmärkten ein. Die Qualitätskrise lähmt vor allem
die Innovationsfreudigkeit der Branche.
S32 Wettbewerbsintensität
S32a Innovative Anbieter frischen Wettbewerb auf
Moderne Maschinen mit mehr Schnittstellen zur Informationsverarbeitung stehen in
der Gunst der Kunden. Junge sowie technologisch aufgeschlossene ältere Unternehmen
plazieren innovative Produkte mit Erfolg am Markt. Ihr Auftreten ist hinsichtlich
Preis und Dienstleistungsangebot forsch. Insgesamt sorgen sie für frischen Wind in
der Branche. Insbesondere die beachtliche Qualität und weltweite Vermarktung
machen den „Alten“ in der Branche zunehmend zu schaffen.
S32b Stabiles Wettbewerbsgefüge
Die Kundenanforderungen sind über die Jahre nur unwesentlich verändert. Die konventionellen
Maschinen und Anlagen, die sich durch hohe Lebensdauer und höchste
Qualität auszeichnen, sind weiter die Umsatzlöwen in einem eher stabilen Wettbewerb.
Fehlende Innovationen, moderates Wachstum und wenig neue Anbieter stabilisieren
die Branche.
134 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

Zusätzliche Projektionen für die Automatisierungs- und Produktionstechnik
S33 Technologieakzeptanz
S33a Starke Stellung von Wissens-Eliten
Technik wird trotz des geringem Technikverständnisses eher als Segen verstanden.
Die Technologie wird durch Wissens-Eliten für die Allgemeinheit nutzbar gemacht.
S33b Aufgeklärte Hi-Tech Gesellschaft
Technik wird von einem hohen Anteil der Bevölkerung als etwas Positives empfunden
und zur Erleichterung und Unterstützung ihrer Tätigkeiten eingesetzt. Neue Technologien
werden gern aufgegriffen und genutzt.
S33c Allgemeine Technologie-Skepsis
Die Mehrheit versteht auch in den Grundzügen die neuen Technologien nicht und
empfindet die technologische Entwicklung als Bedrohung. Die Chancen, die sich aus
den neuen Technologien ergeben, werden nicht genutzt.
S34 Neue Märkte/Marktformen
S34a Diversifikation und Dynamik steigen rasant
Die Iuk-Branche boomt. Im Sog der IuK-Branche gewinnt auch die Automatisierungs-
und Produktionstechnik-Branche rasant an Fahrt. IuK-Unternehmen entdecken
in der Automatisierungs- und Produktionstechnik neue strategische Geschäftsfelder,
die sie mit ihrem hohen technologischem Know-how spielend erobern könnten. Spin-
Offs drängen daher in den bestehenden Wettbewerb, nutzen Distributions- und Service-Netze
ihrer „alten Umgebung“ und agieren zu dem höchst preis- und vergleichsaggresiv
(bekannt aus der Telekommunikationsbranche)
S34b Konzentration auf weltweites Angebot
Im Sog der IuK-Branche gewinnt auch die Automatisierungs- und Produktionstechnik-Branche
rasant an Fahrt. Die neuen Möglichkeiten von weltweiten elektronischem
Handel machen sich vor allem die bestehenden Unternehmen der
Automatisierungs- und Produktionsbranche zu Nutzen. Unternehmen, die bisher noch
nicht auf dem Weltmarkt aktiv waren, suchen im weltweiten Vertrieb eine Chance zur
Stärkung ihrer Wettbewerbsfähigkeit. Allerdings können nicht alle entsprechende
Distributionsnetze aufbauen.
S34c E-Business wird ignoriert
Die Ausbreitung von E-Business bleibt in der Automatisierungs- und Produktionstechnik
hinter den Erwartungen zurück. Was für viele Konsumgüter Standard geworden
ist, setzt sich im Investitionsgüterbereich nur vereinzelt durch. Gründe hierfür
liegen zum einen in den erklärungsbedürftigen Produkten und zum anderen in den
langjährigen Kunden-Lieferanten Beziehungen, wo Qualität und Liefertreue kaufentscheidend
sind.
S35 Post Sales Services
S35a Intelligente Massenkomponenten
Die Forschungs- und Entwicklungsanstrengungen der Automatisierungs- und Produktionsunternehmen
erlauben, Produkte mit hoher Teilintelligenz kostengünstig herzustellen.
Fortschritte im Einsatz lokaler Expertensysteme und Multifunktionssensoren
sind hauptsächliche Ursachen. Eigendiagnose, Systemredundanzen und adaptive
Betriebsstrategien machen die Produkteinheiten relativ fehlerrobust. Die intelligenten
Produkte können aufgrund hoher Stückzahlen zu niedrigen Preisen angeboten wer-
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 135

den. Wartungsverträge werden kaum abgeschlossen. Das Service-Technikernetz wird
entscheidend verkleinert. Es herrscht die „Fire-and-Forget“ Strategie bei den Herrstellern
vor.
S35b Online Fehlerbehebung
Steuerungs- und Regeleinrichtungen sind in der Regel komplett vernetzt. Das Spektrum
der wirtschaftlich erfaßbaren physikalischen Größen erlaubt ein einfaches und
umfassendes Telemonitoring. Hersteller bieten online Fehlerbehandlungen mit steigendem
Erfolg an. Die ortsgebundene Wartung nimmt drastisch ab.
S35c Fehlerbeseitigung vor Ort
Trotz der weiten Verbreitung von IuK-Technologien, gelingt es nicht, ausreichende
Informationen für eine online Fehlerbehebung zu erfassen. Der Grund hierfür liegt
vor allem in der unwirtschaftlichen technischen Machbarkeit. Service-Techniker müssen
die Mehrzahl der Problemstellungen vor Ort lösen. Der Bedarf an Service-Verträgen,
die Unterstützung in Problemfällen zu sichern ist folglich hoch.
S36 Qualitäts- und Sicherheitsanforderungen
S36a Qualität schlägt sich im Preis nieder
Die überschaubare Komplexität der Produkte im Automatisierungs- und Produktionstechnikumfeld
steht nicht im Konflikt mit der Einhaltung von Qualitäts- und Sicherheitsanforderungen.
Allerdings sind diese Produkte preislich höher gelegen, da Q+S-
Standards kaufentscheidend sind und von den Kunden auch entsprechend bezahlt
werden.
S36b Hohe „Mean time between failure“ wird vorausgesetz
Die überschaubare Komplexität der Produkte im Automatisierungs- und Produktionstechnikumfeld
steht nicht im Konflikt mit der Einhaltung von Qualitäts- und Sicherheitsanforderungen.
Das sehen vor allem die Kunden so und setzen daher Qualität
voraus. Kennzahlen wie z.B. Mean time between failure werden zu kaufentscheidenden
Kriterien. Einen zusätzlicher Preis wird seitens der Kunden nicht akzeptiert und
ist wegen der vielen Anbieter auch nicht durchsetzbar.
S37 Wettbewerbsintensität
S37a Diversifizierte Märkte voller Nischenprodukte
Die Wachstumsraten in der Automatisierungs- und Produktionstechnik sind außerordentlich
hoch. Der Siegeszug der Informationstechnik zwingt die Unternehmen stetig
Innovationen zu bringen und die Variantenvielfalt zu erhöhen. Preisdruck herrscht
vornehmlich in vereinzelten Nischen. Insgesamt zeichnet sich ein diversifizierter
Markt ab.
S37b Konzentration des Angebot stärkt die Intensität
Die Automatisierungs- und Produktionstechnikbranche steht unter Druck. Die Kunden
wünschen einfache und günstige Komponenten, die schnell konfigurierbar sind.
Der Preisdruck zwingt die Unternehmen die Variantenvielfalt deutlich zu reduzieren.
Der härtere Wettbewerb ist überall zu spüren. Fusionen verschiedenster Unternehmen
versuchen das Produktprogramm bei geringen Varianten zu komplementieren, um so
die eigene Wettbewerbsposition zu stärken.
Zusätzliche Projektionen für die Verkehrstechnik
S38 Sicherheitsbewußtsein der Menschen
136 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

S38a Gesellschaft hat hohes Maß an Sicherheitsstreben
Die Gesellschaft ist grundsätzlich neuen Technologien positiv gegenüber eingestellt,
erwartet aber hohe Zuverlässigkeit und Sicherheit. Ebenso wie die innere Sicherheit
stark verfolgt wird, werden technische Systeme einer kritischen Prüfung unterzogen.
Unabhängige Überwachungsgremien wie der TÜV spielen dabei eine wichtige Rolle.
S38b Sicherheitsbewußtsein reagiert hoch empfindlich auf Katastrophen
Das Vertrauen der Gesellschaft in den technologischen Fortschritt ist durch mehrere
Katastrophen (Flugzeug, Schiene, etc.) arg gebeutelt. Schlechte Aufklärungspolitik ist
neben der polarisierenden Presse hauptverantwortlich für den Image-Schaden. Zuvor
unartikulierte Ängste der Bevölkerung werden organisiert gesammelt und Bürgerinitiativen
sowie Interessensvertretungen machen den Herstellern Druck, mehr Transparenz
in der Qualitätssicherung zu schaffen.
S38c Menschen akzeptieren Fehler in technischen Systemen
Das Ausbleiben von technischen GAUs sowie die technolgiegläubige, heranwachsende
junge Generation vermitteln ein Stimmungsbild der Sicherheit. Kleinere technische
Fehler werden stillschweigend akzeptiert. Die Freude über die neuen
Möglichkeiten überwiegen die kritischen Stimmen.
S39 Umweltpolitik
S39a Hohe Besteuerung von Energiestoffen
Die Energiepreise steigen erheblich an. Dies liegt zum einen an der starken Besteuerung
fossiler Brennstoffe und zum anderen am Rückgang fossiler Brennstoffe aufgrund
künstlicher Verknappung bzw. stockender Entwicklung alternativer
Energieträger.
S39b Deutschland als umweltpolitisches Vorbild mit innovativen Konzepten
Im internationalen Konzert der globalen Umweltplayer nimmt Deutschland die Spitzenstellung
ein. Mit vorbildlichen politischen Zielsystemen setzt die Industrie innovative
Produkte ein und um und erhöht stark die Exporte in Ländern mit strengen
umweltauflagen. Dadurch sichert die deutsche Industrie wichtige Wettbewerbsvorteile
im internationalen Geschäft.
S39c Umweltpolitik tritt in den Hintergrund
Die Bemühungen der internationalen Staatengemeinschaft den Umweltschutz stärker
in den Vordergrund zu spielen erweisen sich als unbedeutend. Umweltpolitische Entscheidungen
haben im wesentlichen nur nationalen Charakter. Die Unternehmen agieren
vor dem Hintergrund des globalen Wettbewerbs und reagieren mit entsprechenden
Maßnahmen die Auflagen zu umgehen. Umweltpolitik erreicht ihre Ziele nicht und
verliert an Wirkungskraft.
S40 Mobilität
S40a Die mobile Gesellschaft
Es besteht ein hoher Mobilitätsbedarf, der auch befriedigt werden kann. Insbesondere
der Individualverkehr ist treibende Kraft der mobilen Gesellschaft.
S40b Eingeschränkte Mobilität von Personen und Gütern
Das Angebot von Transporttechnologien entspricht nicht der Nachfrage nach Transportleistungen.
Diese Diskrepanz führt zu einer erheblichen Behinderung von Leistungs-
und Distributionsprozessen sowie der individuellen Mobilität.
S40c Sinkende Mobilität
Die Mobilität von Personen und Gütern geht zurück. Der Grund hierfür ist ein starker
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 137

Rückgang des Mobilitätsbedarfs aufgrund der vielfältigen Kommunikationsmöglichkeiten,
der damit verbundenen, neuen Formen der Arbeitsorganisation sowie der
Regionalisierung der Wirtschaftskreisläufe.
S41 Neue Märkte/Marktformen
S41a Innovative Vehikel auf dem Vormarsch
In der Verkehrstechnik sorgt die Automobilbranche für die höchste Dynamik aufgrund
der kürzeren Produktlebenszyklen im Vergleich zur Schiene oder Luft. Die
boomende IuK-Branche als Vorbild, entwickeln die Automobilisten neuartige Fahrzeugkonzepte
auf strenger Modulbauweise. Besonders im Stadtverkehr sind kleine
und leichte Autos beliebt. Diese können von den Kunden im „Hand umdrehen“ für
verschiedenste Transportzwecke umgerüstet werden. Die Umrüstung vom Sechs-Sitzer
zum Pick-up für den Transport sperriger Gütern ist so einfach wie das Öffnen
eines Cabrio-Faltdachs. Diese „Autosysteme“ werden insbesondere von der jüngeren
Generation bevorzugt gekauft.
S41b Wenige Anbieter mit modularen Varianten
In der Verkehrstechnik sorgt die Automobilbranche für die höchste Dynamik aufgrund
der kürzeren Produktlebenszyklen im Vergleich zur Schiene oder Luft. Die
starke Anbieterkonzentration der vergangenen Jahre hat die Position der Automobilisten
nachhaltig gestärkt. Sie bedienen den Markt auf Basis von Plattformstrategien
mit wenigen Baureihen, die aber in gewissen Grenzen kundenindividuell konfiguriert
werden können. Aus Synergiegründen wird steigende Modularisierung und Standardisierung
als Druckmittel gegen die Zulieferer verwendet. Damit können viele Varianten
zu akzeptablen Preisen angeboten werden.
S41c Klassische Produkte wehren übermäßige Innovationen ab
In der Verkehrstechnik sorgt die Automobilbranche für die höchste Dynamik aufgrund
der kürzeren Produktlebenszyklen im Vergleich zu Schiene oder Luft. Die
starke Anbieterkonzentration der vergangene Jahre hat die Position der Automobilisten
nachhaltig gestärkt. Sie setzen weiterhin auf konventionelle Massenfahrzeuge.
Die Kunden sind dank der moderaten Preise auch mit dem Angebot zufrieden.
S41d Individual Lösungen nicht in Sicht
In der Verkehrstechnik sorgt die Automobilbranche für die höchste Dynamik aufgrund
der kürzeren Produktlebenszyklen im Vergleich zur Schiene oder Luft. Die
boomende IuK-Branche als Vorbild, fordern die Kunden mehr verstärkte Individuallösungen
für ihren Mobilitätsbedarf. Die Komplexität der Fahrzeuge erlaubt aber
keine wirtschaftliche Versorgung der hohen Nachfrage nach "uniquen Vehikel".
S42 Post Sales Services
S42a Das Informationsvehikel
Die Informations- und Kommunikationstechnik hat das Automobil fest im Griff.
Keine Aktionen des Fahrers werden mehr ohne das Zutun von Computern ausgeführt.
Zusätzlich stehen den Insassen sämtliche Spielformen der modernen Kommunikation
auf großen wie kleinen Reisen zur Verfügung. Insbesondere Telematik-Dienste versorgen
den Fahrer mit Zusatzinformationen über Gefahren- und Verkehrssituationen.
Diese Dienste werden aber nur über entsprechende Post Sales Service Verträge aktiviert.
Im Schienen- und Luftverkehr setzen die Betreiber ebenfalls flächendeckende
Points-of-Information ein. Diese werden allerdings im Ticketpreis integriert. Wartungs-
und Reparaturarbeiten sind von dieser Entwicklung aber wenig betroffen.
S42b Online Service-Call-Center
138 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

Die massive Verbreitung von Informations- und Kommunikationstechnologien in
Automobilen bringt neben den Points-of-Information vor allem neuartige Unterstützung
zur Fehlerbehebung und Pannenunterstützung. Virtuelle Assistenzsysteme
(Avatare) helfen Fahrer ohne technische Kenntnisse kleinere Mängel direkt zu beheben.
Routinemäßige Checks werden automatisch per Funk von autonomen Computersystemen
durchgeführt. Service-Call-Center sind bei Bedarf direkt mit dem Auto
verbunden und liefern weiteren Support. Diese Dienste können beim Kauf gegen Aufpreis
erworben werden.
S42c Mobile Service-Werkstatt
Die Komplexität der modernen Vehikel steigt. Ihre schwere Beherrschbarkeit bringt
die Tele-Service Anwendungen nur wenig nach vorn. Service-Techniker werden
sogar noch mehr als zuvor benötigt. Die Automobilisten gestalten daher mit den
Werkstätten flächendeckende Netze von Service-Points. Der Service-Techniker ist
aber wesentlich mobiler als noch in den 90ern. Betriebsstörungen werden in der Regel
vor Ort innerhalb einer Stunde behoben.
S43 Qualitäts- und Sicherheitsanforderungen
S43a Latente Angst vor der technischen Beherrschbarkeit
Die aus der zunehmenden Komplexität der technischen Systeme folgenden schwerere
Beherrschbarkeit ist die Hauptursache für höhere Fehleranfälligkeit. Fehlende Möglichkeiten
das gesamte Zustandsverhalten zu validieren (aus technischen sowie
Kostengründen), führen zu einem unartikuliertem Grundmißtrauen gegenüber technischen
Vehikeln. Da die Kunden aber keine alternativen Fortbewegungsmittel zu Auto
und Flugzeug haben und die Unfallzahlen sich in vertretbaren Grenzen halten, gehen
sie aus ihrer Sicht ein kalkulierbares Risiko ein.
S43b Kunden fordern Transparenz
Die aus der zunehmenden Komplexität der technischen System folgenden schwerere
Beherrschbarkeit ist die Hauptursache für höhere Fehleranfälligkeit. Fehlende Möglichkeiten
das gesamte Zustandsverhalten zu validieren (aus technischen sowie
Kostengründen), führen zu einem artikuliertem Mißtrauen gegenüber technischen
Vehikeln. Statistiken mit steigenden Unfallzahlen aufgrund von technischen Defekten,
ermuntern Kunden, laut Transparenz in Qualitäts- und Sicherheitsstandards und
deren Überwachung zu fordern.
S43c Preis für Qualität und Sicherheit wird bezahlt
Die Kunden nehmen Qualitäts- und Sicherheitsmängel nicht mehr länger hin. Sie fordern
die strikte Einhaltung der Standards bzw. Erhöhung der Richtwerte und -linien.
Im Gegenzug sind sie aufgrund der Risikovermeidung bereit, den höheren Preis für
Sicherheit zu bezahlen.
S44 Wettbewerbsintensität
S44a Nischenaktivität noch wenig beachtet
Die Fusionswelle zu Beginn des neuen Jahrhunderts der Großen der Branche ebbt ab.
Die allgemeine Konjunkturflaute zwingt immer mehr mittlere Unternehmen an die
Existenzgarantie. Die Großkonzern haben dank ihrer Vermögen den längeren Atem
und zeigen sich wenig berührt. Ihre Marktleistungen bauen allerdings stark auf Synergien
auf, so daß kleine Nischenanbieter mit stark fokussierten Kernkompetenzen und
Differenzierung weitestgehend unbemerkt aber erfolgreich ihre Marktpositionen stetig
erweitern. Neue Anbieter wie im KFZ-Leichtbau erscheinen.
S44b Schlüsseltechnologien werden „eingekauft“
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 139

Die großen Konzerne setzen voll auf die Integration von Schlüsselkompetenzen. Um
in stark umkämpften Märkten bestehen zu können, werden mittlere und kleinere
Unternehmen mit ausgemachten Kernkompetenzen vor allem im Umfeld der Informationstechnik
in der Verkehrstechnikbranche „geschluckt“. Globaler Wettbewerb
zwingt aufgrund der erreichten Preisuntergrenze zum technischen „Feature-War“.
S44c Offener Wettbewerb der Kernkompetenzen
Das ursprüngliche Machtgefüge bricht auseinander. Als Folge der starken Konzentration
auf eigene Kernkompetenzen und Out-Sourcing-Strategien beherrschen Systemlieferanten
die entscheidenden Entwicklungsphasen in der Branche. Automobilisten
degradieren zu Montageunternehmen mit Designkompetenz und hohen Marketing-
Budgets. Die Branchenwertschöpfungskette zerbricht in viele Glieder. Es entsteht ein
offener Wettbewerb der Kernkompetenz-reduzierten Unternehmen.
8.4 Szenario-Bildung
8.4.1 Vorgehen
Szenarien sind konsistente Bilder einer möglichen Zukunft. Sie beruhen auf möglichst widerspruchsfreien
Kombinationen der in der Szenario-Prognostik ermittelten Zukunftsprojektionen.
In dieser Vordringlichen Aktion wurden zu drei verschiedenen Anwendungsdomänen
Szenarien erstellt. Dies erfolgte jeweils in den vier Schritten:
• Projektionsbündelung,
• Rohszenario-Bildung,
• Zukunftsraum-Mapping und
• Szenario-Beschreibung.
Projektionsbündelung
Es ist das Ziel der Projektionsbündelung, Kombinationen von Zukunftsprojektionen zu identifizieren
und nach geeigneten Kriterien zu bewerten. Von Interesse sind nur Kombinationen, in
denen von jedem Schlüsselfaktor genau eine Zukunftsprojektion vorkommt. Solche Kombinationen
werden als Projektionsbündel bezeichnet. Entscheidend für die Glaubwürdigkeit von
Zukunftsbildern ist deren Konsistenz, d.h. die Widerspruchsfreiheit der einzelnen Projektionen.
So ist ein Zukunftsbild beispielsweise unglaubwürdig, wenn es neben drastisch steigenden
Benzinpreisen einen Anstieg der individuellen Mobilität beschreibt. Solche inneren
Widersprüche werden als Inkonsistenzen bezeichnet. Demgegenüber ist die Verbindung von
Benzinpreisanstieg und Mobilitätsrückgang konsistent - ebenso wie die Verbindung von Benzinpreisrückgang
und Mobilitätsanstieg. Zukunftsbilder mit solchen Kombinationen sind folglich
besonders glaubwürdig. Bei der Entwicklung glaubwürdiger Szenarien ist es daher
wichtig, daß sich die Zukunftsprojektionen eines Szenarios nicht widersprechen. Zur Ermittlung
der Konsistenz der verschiedenen Projektionsbündel wird daher eine Konsistenzanalyse
durchgeführt, die in eine paarweise Konsistenzbewertung und eine bündelweise Konsistenzbetrachtung
gegliedert ist.
Paarweise Konsistenzbetrachtung: Um glaubwürdige Zukunftsbilder zu erhalten, müssen
die einzelnen Projektionspaare eines Projektionsbündels auf ihre Verträglichkeit hin überprüft
werden. Dazu wird unter Verwendung der folgenden Skala für jedes Projektionspaar ein Konsistenzwert
ermittelt:
140 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

• 1 = totale Inkonsistenz, d.h. die beiden Projektionen schließen einander absolut aus und
können nicht zusammen in einem glaubwürdigen Szenario vorkommen.
• 2 = partielle Inkonsistenz, d.h. die beiden Projektionen widersprechen einander. Ihr gemeinsames
Auftreten beeinträchtigt die Glaubwürdigkeit eines Szenarios.
• 3 = neutral oder unabhängig voneinander, d.h. die beiden Projektionen beeinflussen einander
nicht, und ihr gemeinsames Auftreten beeinflußt die Glaubwürdigkeit eines Szenarios
nicht.
• 4 = gegenseitiges Begünstigen, d.h. die beiden Projektionen können gut in einem Szenario
vorkommen.
• 5 = sehr starke gegenseitige Unterstützung, d.h. aufgrund des Eintretens der einen Projektion
kann auch mit dem Eintreten der anderen Projektion gerechnet werden.
Die paarweise Konsistenzbewertung erfolgt in einer Konsistenzmatrix, wie sie in Bild 45 dargestellt
ist. Es reicht aus, nur auf einer Seite der Matrix Konsistenzwerte anzugeben, da es sich
- im Gegensatz zur Einflußanalyse - nicht um gerichtete Beziehungen handelt.
Konsistenzmatrix
Fragestellung: »Wie verträgt sich
Zukunftsprojektion A (Zeile) mit
Zukunftsprojektion B (Spalte)?«
Bewertungsmaßstab (Konsistenzwert)
1 = totale Inkonsistenz
2 = partielle Inkonsistenz
3 = neutral oder voneinander unabhängig
4 = gegenseitiges Begünstigen
5 = starke gegenseitige Unterstützung
Bandbreite
d. Kommuni
kationnetze
Auton. vern.
mechatr.
Systeme
Tool
Support
HW/SW Co
Design
Struktur d.
SW Anbieter
1A
1B
1C Massenkom.netze ohne Hi-Tech
2A teure AMS Lös. für Spez.geb. 5 3 1
2B Mechatron. Ameisenhaufen 3 5 2
2C Massenware AMS
1 2 5
3A Feld, Wald&Wiesen Tools 3 1 5 3 3 4
3B Breite Pal.hochw.E-umgeb. 4 5 2 2 5 4
3C E-umgeb. für hoch.kompl. Prod. 5 2 1 5 2 1
4A “Bastelös.” stillen Bed.
3 2 4 4 3 3 5 1 3
4B
4C
Hochleist.netze zw.Hi-Tech Reg.
Glob. Hochleist.netze für Komm.
Hochleist.netze zw.Hi-Tech Reg.
Glob. Hochleist.netze für Komm.
1A
1B
Neu.Selbstver.der int.Sys-entwickl. 4
Int.Sys-entw. nicht stan.gem. 3
16A “Micros. vs Oracle Var.”
3 4 2 3 4 2 1 4 3 2 3 2
16B Einige KP m.- hoh. Reifegrad 4 3 2 4 3 3 3 5 4 2 4 3
16C Open Source vs. teure SW-Liz. 3 4 4 1 4 4 4 3 2 4 3 3
Abbildung 45. Konsistenzmatrix zur paarweisen Konsistenzanalyse
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 141
5
4
Massenkom.netze ohne Hi-Tech
teure AMS Lös. für Spez.geb.
1C
2A
2
3
2
3
Mechatron. Ameisenhaufen
2B
2C
5
1
Massenware AMS
Feld, Wald&Wiesen Tools
Breite Pal.hochw.E-umgeb.
E-umgeb. für hoch.kompl. Prod.
4
2
3A
3B
1
4
5
2
3C
3
4
“Bastelös.” stillen Bed.
4A
Neu.Selbstver.der int.Sys-entwickl.
Int.Sys-entw. nicht stan.gem.
4B
4C
“Micros. vs Oracle Var.”
16A
Einige KP m.- hoh. Reifegrad
16B
Open Source vs. teure SW-Liz.
16C

Bündelweise Konsistenzbetrachtung: Nach der Bewertung der einzelnen Projektionspaare
müssen im zweiten Schritt der Konsistenzanalyse alle möglichen Projektionsbündel hinsichtlich
ihrer Widerspruchsfreiheit beurteilt werden. Dabei handelt es sich um ein kombinatorisches
Problem, das für eine große Anzahl von Schlüsselfaktoren erhebliche Rechenzeit
erfordert. Als Ergebnis der Konsistenzanalyse ergeben sich für jedes Projektionsbündel mehrere
Kennwerte:
• Konsistenzwert des Projektionsbündels: Summe aus den Konsistenzwerten der einzelnen
Projektionspaare.
• Existenz totaler Inkonsistenzen in einem Projektionsbündel: Selbst Projektionsbündel mit
einem hohen Konsistenzwert müssen als unglaubwürdig verworfen werden, wenn sie ein
oder mehrere Projektionspaare mit totaler Inkonsistenz aufweisen.
• Anzahl partieller Inkonsistenzen: Weist ein Projektionsbündel zu viele Projektionspaare mit
partieller Inkonsistenz auf, so ist die Glaubwürdigkeit ebenfalls nicht gegeben.
Als Ergebnis der Konsistenzanalyse erhält man einen vorläufigen Projektionsbündel-Katalog.
Dieser enthält alle Projektionsbündel, die kein Projektionspaar mit totaler Inkonsistenz aufweisen.
In den meisten Fällen enthält dieser Katalog sehr viele Projektionsbündel. Eine große
Anzahl dieser hat nur einen geringen Konsistenzwert oder weist viele partielle Inkonsistenzen
auf. Damit solche qualitativ minderwertigen Zukunftsbilder die Aussagekraft der Szenarien
nicht beeinträchtigen, wird die Anzahl der Projektionsbündel reduziert. Dafür stehen verschiedene
Verfahren zur Verfügung1 .
Rohszenarien-Bildung
Bei der Projektionsbündelung können theoretisch bis zu 3 n Projektionsbündel entstehen - nämlich
dann, wenn für alle n Schlüsselfaktoren drei Zukunftsprojektionen vorliegen. Selbst wenn
diese Menge durch das Auftreten von totaler Inkonsistenz oder durch gezielte Begrenzung
reduziert wird, bleibt noch eine große Zahl von konsistenten Projektionsbündeln übrig. Sie ist
in der Regel wesentlich größer als die angestrebte Anzahl von Szenarien. Daher müssen aus
den im Projektionsbündel-Katalog enthaltenen Bündeln einige wenige Szenarien entwickelt
werden.
Dazu erfolgt zunächst eine schrittweise Zusammenfassung der Projektionsbündel zu sog.
Rohszenarien. Dies wird mittels Clusteranalyse durchgeführt. Bei der Zusammenfassung der
Projektionsbündel soll erreicht werden, daß die Cluster in sich möglichst homogen und untereinander
möglichst heterogen sind. Bei der Rohszenarien-Bildung bedeutet dies, daß die Projektionsbündel
innerhalb eines Rohszenarios möglichst ähnlich und die Rohszenarien selbst
bzw. die Projektionsbündel unterschiedlicher Rohszenarien möglichst verschieden sein sollen.
Ausgangspunkt für die Clusteranalyse sind die einzelnen Projektionsbündel, die jeweils als
einzelne Cluster aufgefaßt werden. Diese „feinste Partition“ ist in der schematischen Darstellung
der Clusteranalyse (Bild 46) als linke Spalte verzeichnet. Ausgehend von dieser feinsten
Partition werden solange jeweils die beiden ähnlichsten Cluster zusammengefaßt, bis die
gröbste Partition - nur noch ein einziger Cluster - erreicht ist. Diese ist in Bild 46 als rechte
Spalte zu sehen.
1. Gausemeier, J. / Fink, A. / Schlake, O.: Szenario-Management - Planen und Führen mit Szenarien. 2. Auflage,
Carl Hanser Verlag, München, 1996
142 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

»feinste Partition«
Alle Projektionsbündel
werden Clusteraufgefaßt. als einzelne
Cluster aufgefaßt.
Abbildung 46. Prinzip der Clusteranalyse
»gröbste Partition«
Alle Projektionsbündel
sind in einem Cluster
zusammengefaßt.
Mit jedem Clusterungsdurchgang geht Information verloren. Dieser Informationsverlust wird
aufsummiert und als Kennwert für die Güte einer einzelnen Partition verwendet. In
Abbildung 47 ist die Entwicklung dieses Partitionsniveaus in einem Scree-Diagramm dargestellt.
Mit dem vorletzten Clusterungsschritt wäre ein so großer Informationsverlust verbunden, daß
Durch die
Clusteranalyse
entstehender
Informationsverlust
»feinste Partition«
Alle Projektionsbündel
werden als einzelne
Cluster Clusteraufgefaßt. aufgefaßt.
»geeignete Partition«
Geeignete Kombination aus
geringer Clusteranzahl und
geringem Informationsverlust
»gröbste Partition«
Alle Projektionsbündel
sind in einem Cluster
zusammengefaßt.
Abbildung 47. Auswahl der geeigneten Partition mit Hilfe des Scree-Diagramms
das Partitionsniveau sprunghaft angestiegen wäre. Im Scree-Diagramm zeigt sich ein sog.
„Ellenbogen-Punkt. Er weist auf die geeignete Partition hin. In dem in Abbildung 47 gezeigtem
Beispiel würden daher drei Szenarien entwickelt.
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 143
I
II
III

Zukunftsraum-Mapping
Auch im Rahmen der Szenario-Bildung entstehen Tabellen und Zahlenkolonnen, die bei
umfangreichen Projekten leicht unübersichtlich werden und die Szenario-Erstellung als eine
„Geheimwissenschaft“ erscheinen lassen. Nicht wenige Akzeptanzprobleme der Szenario-
Technik entstehen dort, wo die Anwender einen Einblick in die Struktur des Zukunftsraumes
gewinnen wollen, aber stattdessen mit seitenlangen Tabellen abgespeist werden. Im Rahmen
des Zukunftsraum-Mappings werden daher die Projektionsbündel und Rohszenarien mit Hilfe
statistischer Verfahren visualisiert, so daß die Szenario-Ersteller einen kompakten Einblick in
die zukünftigen Möglichkeiten erhalten.
Szenario-Beschreibung
Ein Szenario ist eine Darstellung einer zukünftigen Situation sowie eines Weges, wie diese
erreicht werden könnte. In der Regel ähnelt ein Szenario einem „Science Fiction“ - die Zukunft
wird in erzählenden Sätzen beschrieben. Die Szenario-Beschreibung hat daher das Ziel - unter
Verwendung des vorliegenden Rohszenario-Katalogs und des Zukunftsraum-Mapping - mehrere
prägnante und leicht verständliche Szenarion „in Prosa“ zu entwickeln. Dies erfolgt in
zwei Schritten:
Zunächst werden aus dem Rohszenario-Katalog die Projektionen herausgefiltert, die für die
Beschreibung eines Szenarios relevant sind. Diese relevanten Projektionen eines Szenarios
werden als Ausprägungen bezeichnet und in Ausprägungslisten zusammengestellt.
Im letzten Schritt werden die Ausprägungen eines Szenarios unter Berücksichtigung der Mappings
so verknüpft, daß ein prägnantes aussagekräftiges und verständliches Zukunftsbild entsteht.
Dieses wird in vollständigen Sätzen beschrieben.
144 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion

9 Liste der beteiligten Unternehmen
Am Industriekreis der Vordringlichen Aktion beteiligen sich die folgenden Unternehmen:
• Adtranz DaimlerChrysler Rail System GmbH/TTC/Q
• Berner & Mattner Systemtechnik GmbH/Fachgebiet Embedded Systems
• Bizerba GmbH & Co. KG, Geschäftsbereich Technik
• Brückner/EE (Engineering Elektrik)
• Daimler Chrysler
• Endress + Hauser GmbH + Co/FEI
• Festo AG & Co /Elektronik-Systementwicklung
• HBM Me- und Systemtechnik/Entwicklung
• Heidelberger Druckmaschinen AG
• Hitex-Systementwicklug GmbH/Entwicklung
• HOMAG AG EST
• IMECH GmbH Robotik und Automation
• infoteam Software GmbH
• ISG - Industrielle Steuerungstechnik GmbH
• Klaschka GmbH
• KRONES AG Hermann Kronseder Maschinenfabrik/ Elektronik Entwicklung
• Kuhnke GmbH, Ltg. Systemtechnik
• Lachmann & Rink GmbH
• Leuze eletronic GmbH&Co./PES
• Moeller GmbH/Produktlinie Software (SES)
• Motorola
• Nagel Maschinen- und Werkzeugfabrik GmbH
• OCE Printing Systems
• PEP Modular Computers GmbH
• Pepperl + Fuchs GmbH, Abteilung FA-PG-SYS
• Robert Bosch GmbH, Abteilung K5/ESQ
• Rohde & Schwarz GmbH, Messtechnik, 1ESC2
• Samson AG/Abt. Elektrotechnik
• Scheidt & Bachmann GmbH
• Siemens AG
• Krupp Timtec Telematik
• Simotec GmbH
• Softing GmbH/BG3
Abschlußbericht Vordringliche Aktion Version vom 3. Februar 2000 145

• Software Factory
• SoHard GmbH
• TMG i-tec GmbH
• Trumpf GmbH&Co., Steuerungsentwicklung Technische Software
• Werner Riester GmbH&Co.KG
• Völker GmbH
• Weidmüller Connect GmbH & Co
• Xcc SOFTWARE AG
146 Version vom 3. Februar 2000 Abschlußbericht Vordringliche Aktion