O'Reilly logo

Automotive SPICE in der Praxis: Interpretationshilfe für Anwender und Assessoren by Jörg Zimmer, Lars Dittmann, Klaus Hörmann, Markus Müller

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

31
2.3 ENG.1 Anforderungserhebung
2.2.4 Ausgewählte Arbeitsprodukte
08-16 Release plan – Releaseplan
Der Releaseplan umfasst generell:
Die zeitliche Planung aller Releases (Übersicht)
Regelungen zur Handhabung des Release wie Klassifizierung, Nummerie-
rungsschema, Build-Aktivitäten und Build-Umgebung etc.
Des Weiteren sind für jedes Release zu regeln:
Die funktionalen Inhalte (siehe hierzu Funktionsliste, Abb. 2–19)
Die zugehörigen Objekte (Softwarestand, Hardwarestand, Dokumentation
etc.) und Freigaben
Ein Mapping auf die Kundenanforderungen, die im jeweiligen Release erfüllt
werden
Sonstige Regelungen wie Support, Verpackung, Art und Medium der Lieferung
2.2.5 Besonderheiten Level 2
Zum Management der Prozessdurchführung
Auf Level 2 werden die Releaseplanung und deren Verfolgung sehr viel stringen-
ter und detaillierter (Prozessattribut PA 2.1) gehandhabt.
Zum Management der Arbeitsprodukte
Die Anforderungen von Prozessattribut PA 2.2 gelten insbesondere für das
Release selbst und alle zugehörigen Releaseobjekte. Die Prüfung des Release
erfolgt im Rahmen der Freigabeprüfungen. Außerdem sollte der Releaseplan
unter Konfigurationskontrolle stehen.
2.3 ENG.1 Anforderungserhebung
2.3.1 Zweck
Zweck des Prozesses ist es, sich entwickelnde Bedürfnisse und Anforderungen
des Kunden
21
über die gesamte Lebensdauer eines Produktes und/oder einer
Dienstleistung zu erfassen, zu verarbeiten und zu verfolgen, um dadurch eine
Baseline über alle Anforderungen zu erstellen, die als Basis für die Definition der
benötigten Arbeitsprodukte dient.
21. »Kunde« kann beispielsweise der OEM oder ein anderer (übergeordneter) Lieferant sein,
unabhängig davon, wer formal der Auftraggeber ist.
2 Interpretationen zur Prozessdimension
32
Werden Anforderungen nicht ausreichend sorgfältig erhoben, fehlt dem ganzen
Projekt die stabile Grundlage, und spätere Probleme sind vorprogrammiert. Die
schriftliche Niederlegung von Anforderungen macht in der Praxis oft Schwierig-
keiten oder ist mit Mängeln behaftet. Weitverbreitete Gründe sind:
Das Entwicklungsprojekt steht von vornherein unter immensem Zeitdruck,
Anforderungen werden aus Zeitdruck nur notdürftig beschrieben.
Der Auftraggeber kann oder will sich zu Beginn noch nicht auf alle Details
festlegen.
Es wird ein innovatives und komplexes System erstmals entwickelt, die
Anforderungen lassen sich zu Beginn nur schwer beschreiben.
Anforderungserhebungen, die in der Angebotsphase durchgeführt werden, sind
meist durch einen erheblichen Zeitdruck gekennzeichnet. Die Anforderungs-
analyse kann insbesondere bei einer Kunden-Lieferanten-Beziehung nicht so tief-
gründig wie erforderlich ausgeführt werden, weil der Abgabetermin des Angebo-
tes drängt und sich die Verantwortlichen auf das Wesentliche beschränken
müssen. Detaillierte Analysen können in diesem Fall erst nach Auftragserteilung
erfolgen, wobei es dann nicht selten zu Meinungsverschiedenheiten zwischen den
Partnern über den Inhalt der angebotenen Leistung kommt. Problematisch für
den weiteren Projektverlauf sind folgende Punkte:
Der Kunde beteiligt sich nicht an der Spezifizierung der Funktion des Systems,
der Spezifizierungsaufwand wird komplett dem Lieferanten überlassen. Der
Kunde äußert aber später im Projekt eine Vielzahl von Änderungswünschen
und neuen Anforderungen.
Der Lieferant versäumt es, sich die von ihm spezifizierten Anforderungen
durch den Kunden bestätigen zu lassen, oder dieser verweigert die Bestätigung.
Vereinzelt hat sich auch eine »arbeitssparende Praxis« etabliert, ein System »wie
beim Wettbewerber« oder »wie im Vorgängerprodukt, nur mit folgenden Ände-
rungen ...« zu bestellen. An dieser Stelle im Projekt wird bereits der Grundstein
für spätere Probleme gelegt.
Problematisch ist teilweise auch die Verwendung vorhandener und bereits fer-
tig entwickelter Plattformlösungen oder die Wiederverwendung von Applikatio-
nen für andere Auftraggeber. So wirtschaftlich interessant diese Konstellationen
bei Vergabe auch sind, können die im weiteren Verlauf erforderlichen Änderun-
gen und Anpassungen das Projekt schnell an den Rand des Scheiterns bringen und
später die Frage nach der Wirtschaftlichkeit von Wiederverwendung aufwerfen.
In der Praxis hat es sich mehrfach gezeigt, dass Firmen, die Plattformlösungen
anbieten, diese während des Projektes verworfen und völlig neu zu entwickeln
begonnen haben. Gründe sind, dass der Änderungsanteil zum bestehenden Umfang
zu groß wird oder die geplante Lösung aufgrund von Architekturproblemen so
nicht mehr umsetzbar ist. Der Erfolg hängt in diesen Fällen neben der Anforde-

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required