Raumfahrt-Projektmanagement

Transkript

1 Raumfahrt-Projektmanagement Konfigurationsmanagement

2 Deutsche Übersetzung Herausgeber Deutsches Zentrum für Luft- und Raumfahrt e.v. Qualitäts- und Produktsicherung Nationales ECSS-Sekretariat Anschrift Technische Bearbeitung Telefon ( ) Telefax ( ) Redaktion Telefon ( ) Telefax ( ) Preis Porz-Wahnheide Linder Höhe D Köln Dr. Detlev Bohle Detlev.Bohle@dlr.de Ruth Opperbeck Ruth.Opperbeck@dlr.de 30 DM Englische Originalausgabe Herausgeber ESA Publications Division ESTEC, Postfach AG Noordwijk Niederlande Copyright 1996 : European Space Agency für die Mitglieder von ECSS

3 Vorwort Diese Norm gehört zu der Reihe von ECSS-Normen, die sich auf das Management, die Technik (Engineering) und die Produktsicherung in Raumfahrtprojekten und -anwendungen beziehen. ECSS ist eine Kooperation der Europäischen Raumfahrtagentur ESA, nationaler Raumfahrtagenturen und europäischer Industrievereinigungen mit dem Ziel der Ausarbeitung und Pflege von einheitlichen Normen. Diese Norm formuliert Anforderungen als Festlegungen dessen, was erreicht und weniger, wie die erforderliche Arbeit organisiert und durchgeführt werden soll. Dadurch können bestehende Organisationsstrukturen und -methoden beibehalten werden, wo sie effektiv sind, und sich weiterentwickeln - soweit erforderlich -, ohne die Normen neu abfassen zu müssen. Bei der Abfassung dieser Norm wurde die vorliegende ISO 9000-Normenreihe berücksichtigt. Diese Norm wurde von der ECSS-Normungsarbeitsgruppe "Management" ausgearbeitet, vom Technischen ECSS-Ausschuß überprüft und vom ECSS-Lenkungsgremium verabschiedet. i

4

5 Inhaltsverzeichnis Vorwort... i Einleitung Anwendungsbereich Verweisungen Normative Verweisungen Informative Verweisungen Definitionen und Abkürzungen Definitionen Abkürzungen Konfigurationsmanagementgrundsätze Zielsetzung Grundsätze und Verfahrensweise Aufgaben des Konfigurationsmanagements Implementierung des Konfigurationsmanagements Bezugskonfigurationen Konfigurationseinheiten Konfigurationsmanagementanforderungen Konfigurationsidentifizierung Konfigurationsüberwachung Konfigurations(status)buchführung Konfigurationsverifikation Umsetzungsmethoden: Implementierungsdokument für das Konfigurationsmanagement Bilder Bild 1: Übersichtsschema der Konfigurationsweiterentwicklung auf Systemebene Seite ii

6

7 Einleitung Das Konfigurationsmanagement ist eine Fachdisziplin mit zwei Hauptzielen: Identifizierung und Dokumentation der funktionalen und baulichen (physischen) Merkmale eines Produkts, Überwachung der Änderungen dieser Merkmale, Aufzeichnung und Berichterstattung über den Status der Änderungsbearbeitung und - durchführung sowie Verifizierung der Übereinstimmung mit der Geschäftsvereinbarung und anderen mitgeltenden Dokumenten, Benutzung identischer Daten mit gleichem Kontrollstatus durch alle Projektbeteiligten zu jedem beliebigen Zeitpunkt des Lebenszyklus. 1

8 2

9 1 Anwendungsbereich Dieses Dokument "Konfigurationsmanagement" gehört zu der Reihe von ECSS-Normen aus dem Managementbereich. Zweck dieser ECSS-Norm ist die Festlegung der Grundsätze und Anforderungen, die bezüglich des Konfigurationsmanagements von Produkten im Rahmen eines Raumfahrtprojekts zu beachten sind. Diese Managementnorm legt alle Regeln zum ordnungsgemäßen Konfigurationsmanagement fest. Die in dieser Norm festgelegten Anforderungen betreffen und gelten für Lieferanten und Kunden auf allen Ebenen, wenn der Nachweis der Fähigkeit zu Design und Lieferung konformer Produkte erbracht werden muß. Diese Anforderungen angepaßt, wie im entsprechenden Projektanforderungs-Dokument dargelegt sind von allen an einem Raumfahrtprojekt Beteiligten anzuwenden. 3

10 4

11 2 Verweisungen 2.1 Normative Verweisungen Diese ECSS-Norm enthält durch datierte und undatierte Verweisungen Festlegungen aus anderen Publikationen. Diese normativen Verweisungen sind an den jeweiligen Stellen im Text zitiert, und die Publikationen sind nachstehend aufgeführt. Bei datierten Verweisungen gehören spätere Änderungen oder Überarbeitungen dieser Publikationen nur zu dieser ECSS-Norm, falls sie durch Änderung oder Überarbeitung eingearbeitet sind. Bei undatierten Verweisungen gilt die letzte Ausgabe der in Bezug genommenen Publikation. Diese Norm gehört zu der Raumfahrt-Projektmanagement-Reihe, wie in der Norm ECSS-M-00 "Grundsätze und Verfahrensweisen" aufgeführt. Die nachstehend aufgelisteten Normen sind in Verbindung mit dem vorliegenden Dokument zu betrachten. ECSS-M-10 ECSS-M-20 ECSS-M-30 ECSS-M-50 ECSS-M-60 ECSS-M-70 ISO Projektstrukturen Projektorganisation Projektphaseneinteilung und -planung Informations-/Dokumentationsmanagement Kosten- und Zeitplanmanagement Integrierte Logistikunterstützung Qualitätsmanagement Leitfaden für Konfigurationsmanagement. Der maßgebende Änderungsstand ist der jeweils zum Zeitpunkt der Erstellung der Projektanforderungs-Dokumente gültige. 2.2 Informative Verweisungen RG Aéro CNES IM MR-P/01 ESA PSS Allgemeine Empfehlung für die Projektmanagementspezifikation Konfigurationsmanagement Managementanforderungen für gewerbliche Verträge (Ersatz für ESA PC/941904/TD/510) Konfigurationsmanagement und -überwachung für ESA-Raumfahrtsysteme. 5

12 6

13 3 Definitionen und Abkürzungen 3.1 Definitionen Für die Anwendung dieser Norm gelten die Definitionen nach ECSS-P-001, Ausgabe 1. Besonders beachtet werden sollte, daß die folgenden Benennungen in ECSS-Normen eine bestimmte Bedeutung haben. Arbeitsaufgliederungsstruktur Aufgabe Bezugskonfiguration Daten Dokument Dokumentation Entwicklung Geschäftsvereinbarung Implementierungsdokument Industrieorganisation Information Konfiguration Konfiguration "wie gebaut" Konfigurationsdokument Konfigurationseinheit Kosten Kunde Lieferant Phase (Projektphase) Produktbaum Produktzustand Projekt Projektanforderungs-Dokument Prozeß Raumfahrtelement Raumfahrtsystem Sonderfreigabe (nach Realisierung) Sonderfreigabe (vor Realisierung) System Technische Spezifikation Vertrag Weiterentwicklung (Work Breakdown Structure) (Task) (Configuration Baseline) (Data) (Document) (Documentation) (Development) (Business Agreement) (Implementation Document) (Industrial Organisation) (Information) (Configuration) (As-built Configuration) (Configuration Document) (Configuration Item) (Cost) (Customer) (Supplier) (Phase [Project Phase]) (Product Tree) (Product State) (Project) (Project Requirement Document) (Process) (Space Element) (Space System) (Waiver) (Deviation) (System) (Technical Specification) (Contract) (Evolution). Die folgenden Benennungen und Definitionen gelten speziell für diese Norm und sind entsprechend anzuwenden. "Technische Beschreibung Technische Festlegung eines Produktes in bezug auf Anforderungen, Design, Test- und Verifikationsdokumentation, Analysen, Zeichnungen, Produkte, Materialien, Prozesse und Werkzeuge, gültig für Hardware, Software und Dienstleistungen". 7

14 3.2 Abkürzungen Die folgenden Abkürzungen werden in dieser Norm erläutert und entsprechend benutzt: Abkürzung Bedeutung CDR Critical Design Review Kritisches Design-Review DJF Design Justification File Designbegründungsakte EIDP End Item Data Package Endeinheit-Datenpaket ICD Interface Control Document/Drawings Schnittstellenkontroll-Dokument/Zeichnungen PDR Preliminary Design Review Vorläufiges Design-Review PRR Preliminary Requirements Review Vorläufiges Anforderungs-Review QR Qualification Review Qualifikations-Review TS Technical Specification Technische Spezifikation WBS Work Breakdown Structure Arbeitsaufgliederungsstruktur. 8

15 4 Konfigurationsmanagementgrundsätze 4.1 Zielsetzung Das Konfigurationsmanagement hat zum Ziel: die technische Beschreibung eines Systems und seiner Bestandteile anhand der genehmigten Dokumentation jederzeit in Erfahrung zu bringen, die Weiterentwicklung der technischen Systembeschreibung zu überwachen, die Rückverfolgbarkeit der Weiterentwicklung der technischen Systembeschreibung zu sichern, die Abstimmung der Systembestandteile (Überwachung der externen Schnittstellen) und der Produkte, aus denen sich diese Bestandteile zusammensetzen (Überwachung der internen Schnittstellen), zu erleichtern, zu verifizieren, daß die Dokumentation das genaue Abbild der Produkte ist und bleibt, die sie beschreibt, die jeweils gültige Bezugskonfiguration und die Konfiguration "wie gebaut" zu identifizieren, um die in der Produktion, in der Lieferung oder im Betrieb des Produkts festgestellten Diskrepanzen behandeln zu können, jeden Anwender in die Lage zu versetzen, die Betriebsmöglichkeiten und -grenzen jeder Produkteinheit zu kennen und bei Nichtkonformitäten festzustellen, welche Einheiten betroffen sind. 4.2 Grundsätze und Verfahrensweise Das Konfigurationsmanagement wird definiert als Management der technischen Beschreibung eines Produkts, seiner Bestandteile und der kontrollierten, fortlaufenden Weiterentwicklung dieser Beschreibung. Die Beteiligten müssen ein Konfigurationsmanagement in Abstimmung mit der Genehmigung der Technischen Spezifikation (TS) der Produktelemente, für die sie die Designverantwortung übernommen haben, verwirklichen. Vor der formalen Konfigurationsüberwachung müssen die als Bezugsgrundlage dienenden Dokumente erstellt werden. Vorbereitende Tätigkeiten sind auszuführen durch: die Kunden in der Phase A, um das Projektanforderungs-Dokument für das Konfigurations-management als Basis für die Aufforderungen zur Angebotsabgabe für Verträge in späteren Phasen zu erstellen, die Lieferanten in der Phase B, um ihr Implementierungsdokument in Umsetzung des Projektanforderungs-Dokuments für das Konfigurationsmanagement zu erstellen. 9

16 4.3 Konfigurationsmanagementaufgaben Das Konfigurationsmanagement umfaßt die Organisation, Durchführung und Überwachung der folgenden Aufgaben: Identifizierung der Konfiguration, d. h. Identifizierung der betreffenden Systeme und Festlegung ihrer beschreibenden Dokumentation (Konfigurationsidentifizierung), Überwachung der Konfiguration, d. h. Festlegung der Bezugskonfigurationen, Einrichtung und Durchführung des Änderungsdienstes, Überwachung der Schnittstellen (Konfigurations-überwachung), Aufzeichnung und Verfolgung der Konfiguration, d. h. Aufzeichnung der verschiedenen Produktkonfigurationen und Zulassung ihrer Anwendung über den jeweiligen Konfigurationsstatus [Konfigurations(status)buchführung], Verifizierung, daß das den geforderten Attributen entsprechende Produktdesign angemessen dokumentiert ist, sowie Übereinstimmung des Verifikationsartikels mit dem Design zwecks Festlegung der Produktkonfiguration (Konfigurationsverifikation), Auditierung des Konfigurationsmanagementsystems, d.h. Verifizierung, daß das Konfigurations-managementsystem leistungsfähig ist und die Anforderungen erfüllt. 4.4 Implementierung des Konfigurationsmanagements Der Kunde ist verantwortlich für die Erstellung des Projektanforderungs-Dokuments für das Konfigurationsmanagement vor Beginn der Phase B. Es gilt für alle Projektbeteiligten entsprechend den Implementierungsanforderungen, die vom Kunden jeder Ebene seinem(seinen) Lieferanten vorgegeben werden. In Umsetzung der Anforderungen des Projektanforderungs-Dokuments für das Konfigurations-management auf jeder Ebene der Industrieorganisation ist jeder Beteiligte verantwortlich für die Erstellung, Genehmigungsvorlage und Ausführung seines eigenen Implementierungsdokuments für das Konfigurationsmanagement (vgl. 5.5). Zu Beginn der Phase B muß jeder Beteiligte die mit dem Konfigurationsmanagement innerhalb des Projekts beauftragte Organisation bestimmen. Ihre Aufgaben, Verantwortlichkeiten und Befugnisse sind nach ECSS-M-20 zu beschreiben. Unter Beachtung der Geschäftsvereinbarungen und des Produktbaums ist jeder Beteiligte gegenüber seinem Kunden für die Konfigurationsmanagementtätigkeiten seiner Lieferanten verantwortlich, die den Anforderungen des Projektanforderungs- Dokuments für das Konfigurationsmanagement entsprechen müssen. 4.5 Bezugskonfigurationen Die Grundsätze des Konfigurationsmanagements beruhen auf der Ausarbeitung von Konfigurations-bezugsgrundlagen, die den genehmigten Anforderungs- und Designstatus darstellen und den Ausgangs-punkt für Weiterentwicklungen bilden (siehe Bild 1). Diese Grundlagen werden "Bezugskonfigurationen" genannt. 10

17 Eine Bezugskonfiguration ist gekennzeichnet durch ein Dokument (einen Satz von Dokumenten), das (der) die Merkmale oder bestimmte Merkmale eines Produkts beschreibt. Dieses Dokument (Dieser Satz von Dokumenten) gilt formal als Konfigurationsbezug in einem grundlegenden Stadium des Produktlebenszyklus, entspricht somit einem Hauptereignis der Produktdefinition. Jede Änderung eines Produktattributs, das in diesem Dokument (Satz von Dokumenten) festgelegt oder aufgezeigt ist, muß Gegenstand eines formalen Änderungsverfahrens unter Einbeziehung aller betroffenen Beteiligten und Disziplinen sein, bevor sie berücksichtigt werden kann. Im Verlauf des Produktlebenszyklus werden die folgenden Bezugskonfigurationen in der nachstehend angegebenen Reihenfolge ausgearbeitet: Funktions-Bezugskonfiguration (auf Systemebene), die in der Funktionsspezifikation beschrieben wird. Dieses Dokument spezifiziert die Systemmerkmale unter dem Aspekt der Missions-leistungsfähigkeiten sowie die Annahmekriterien und entsprechenden Annahmegrenzlagen. Entwicklungs-Bezugskonfiguration, die in der Technischen Spezifikation (TS) beschrieben wird. Dieser Satz von Dokumenten spezifiziert die Produktmerkmale unter dem Aspekt der technischen Anforderungen und Vorgaben sowie ihre Verifikationsbedingungen. Die Entwicklungs-Bezugskonfiguration enthält auch die Designbegründungsakte (DJF). Produktions-Bezugskonfiguration, die in der Produktions-Stammakte (Production Master File) beschrieben wird. Dieser Satz von Dokumenten enthält im einzelnen alle Leistungs- und Designattribute, die für Produktion, Abnahme, Betrieb, Unterstützung und Entsorgung erforderlich sind. Die gültige Produktkonfigurationsdokumentation erstmalig bei Auslieferung oder je nach Weiterentwicklung zu einem bestimmten Zeitpunkt dient als Basis für die Eintragungen in die Lebenslaufakte (Log Book), die in der Betriebsphase geführt wird. Die Produktions-Bezugskonfiguration enthält die Endfassungen der Schnittstellenkontroll-Dokumente (ICD). Für den Software-Lebenszyklus werden vergleichbare Bezugskonfigurationen festgelegt, wobei speziell zu berücksichtigen ist, daß es keine eigentliche Herstellung von Software gibt. Die Zahl der betrachteten Bezugskonfigurationen richtet sich nach dem Lebenszyklus der Softwareentwicklung. In jedem Fall besteht die erste Bezugskonfiguration aus der Software-Funktionsspezifikation. Diese Bezugskonfiguration wird im Lauf der Entwicklung bis zur endgültigen Konfiguration aktualisiert, die alle Produktelemente (Quellcode, Generierungsdatei, Dokumentation...) enthält, die für Produktion, Installierung, Abnahme und Betrieb erforderlich sind. 4.6 Konfigurationseinheiten Eine Konfigurationseinheit ist eine Kombination von Hardware, Software, Dienstleistungen oder jede mögliche Unterteilung davon, auf die Konfigurationsmanagement angewendet werden soll und die im Konfigurationsmanagement-Prozeß als Einheit behandelt wird (ISO 10007). Konfigurationseinheiten werden auf verschiedenen Ebenen des Produktbaums identifiziert und mindestens in einer Technischen Spezifikation festgelegt. Die Zuordnung von Konfigurationseinheiten ermöglicht die Konfigurationsüberwachung des Systems einschließlich des Änderungsmanagements, der Leistungsverifizierung und der vertraglichen Grenzen. Außer den Konfigurationseinheiten kann es austauschbare Einheiten geben, die einer Konfigurationsüberwachung bedürfen, die auf eine Identifizierung durch Kennzeichnung oder Etikettierung begrenzt ist. 11

18 4.6.1 Entwickelte Konfigurationseinheit Eine entwickelte Konfigurationseinheit ist eine Einheit, die speziell für das Projekt entwickelt wird. Ihr Konfigurationsmanagement muß die Anforderungen der vorliegenden Norm erfüllen und von dem für die Entwicklung verantwortlichen Lieferanten durchgeführt werden. Ein von mehreren Projektbeteiligten benutztes gemeinsames Element muß eine Konfigurationseinheit sein. Der Kunde kann vorgeben, daß jedes beliebige Produkt eine Konfigurationseinheit wird Beschaffte Konfigurationseinheit Beschaffte Konfigurationseinheiten sind genormte oder "gängige" Produkte, die nicht eigens für das Projekt entwickelt werden; sie sind Gegenstand der Definitionsdokumentation der Lieferanten. Das Konfigurationsmanagement nach der vorliegenden Norm ist in dem zwischen Lieferant und Kunden ausgehandelten Umfang und bis zu dem Grad der Überwachung anzuwenden, wie es zur Gewährleistung eines angemessenen Konfigurationsmanagements für die Konfigurationseinheit der nächsthöheren Ebene, die nach den Konfigurationsmanagementanforderungen des Projekts entwickelt wird, erforderlich ist. Zu dieser Kategorie gehören auch Produkte, die für ein anderes Projekt mit vergleichbaren Vorgaben entwickelt und qualifiziert wurden und unverändert wiederverwendet werden. 12

19 ANMERKUNG: AR: Acceptance Review (Abnahme-Review) DJF: Design Justification File (Designbegründungsakte) FS: Functional Specification (Funktionsspezifikation) ICD: Interface Control Document (Schnittstellenkontroll-Dokument) PDR: Preliminary Design Review (Vorläufiges Design-Review) PMF: Production Master File (Produktions-Stammakte) PRR: Preliminary Requirements Review (Vorläufiges Anforderungs-Review) QR: Qualification Review (Qualifikations-Review) SRR: System Requirement Review (Systemanforderungs-Review) TS: Technical Specification (Technische Spezifikation) CDR: Critical Design Review (Kritisches Design-Review) EIDP: End Item Data Package (Endeinheit-Datenpaket) Bild 1: Übersichtsschema der Konfigurationsweiterentwicklung auf Systemebene 13

20 14

21 5 Konfigurationsmanagementanforderungen In dieser ECSS-Norm sind die Anforderungen nach Themen numeriert aufgeführt, um sie leichter auffinden und nachvollziehen zu können. Jede numerierte Anforderung besteht aus einem allgemeinen Wortlaut (Fettdruck) und oftmals einem erläuternden Text zur allgemeinen Anforderung und einem erwarteten Ergebnis (Kursivdruck). 5.1 Konfigurationsidentifizierung Die Konfigurationseinheiten sind im Produktbaum in Abstimmung mit der Genehmigung der Technischen Spezifikation zu identifizieren, wobei sicherzustellen ist, daß das komplette System kontrolliert wird. Jeder Lieferant muß eine Liste der von ihm zu liefernden Konfigurationseinheiten erstellen, von seinem Kunden genehmigen lassen und auf dem neuesten Stand halten. Liste der Konfigurationseinheiten a) Der Ausgangspunkt der formalen Konfigurationsüberwachung für die Funktionsspezifikation ist die vom Verbraucher genehmigte Funktionsspezifikation am Ende der Phase A (PRR). b) Der Ausgangspunkt der formalen Konfigurationsüberwachung für die Technische Spezifikation (TS) ist die nach dem Systemanforderungs-Review (SRR) genehmigte System-TS, die nach dem vorläufigen Design-Review (PDR) genehmigte Produkt-TS am Ende der Phase B. c) Der Ausgangspunkt der formalen Konfigurationsüberwachung der Designbegründungs-akte (DJF) ist die Ausgabe ihrer entsprechenden Technischen Spezifikation. d) Der Ausgangspunkt der formalen Konfigurationsüberwachung für die Schnittstellenkon-troll-Dokumente (ICD) ist die bei den kritischen Design-Reviews (CDR) fertiggestellte ICD-Fassung. e) Der Ausgangspunkt der formalen Konfigurationsüberwachung für die Produktions-Stammakte (PMF = Production Master File) ist die nach dem kritischen Design-Review (CDR) genehmigte PMF-Fassung. f) Der Ausgangspunkt der formalen Konfigurationsüberwachung des Anwenderhandbuchs ist die beim Qualifikations-Review (QR) fertiggestellte Fassung des Anwenderhandbuchs. g) Der Ausgangspunkt der formalen Konfigurationsüberwachung der Lebenslaufakte (Logbook) ist das Abnahme- Review (AR). 15

22 5.1.3 Jeder Konfigurationseinheit im Produktbaum ist ein Identifizierungsblock zuzuteilen. Diese Identifizierung bezieht sich auf den Produktbaum. Sie muß während der Produktlebensdauer unverändert bleiben, sofern die Austauschbarkeit nicht durch eine Änderung unterbrochen wird. ein Identifizierungsblock je Konfigurationseinheit Eine Konfigurationseinheit ist eindeutig auf die folgende Art und Weise festzulegen: vollständige Designbeschreibung, wenn sie für eine Raumfahrtanwendung entwickelt wird, Auflistung ihrer Leistungen und Schnittstellenmerkmale (oder ihre Beschaffungs-spezifikation), wenn es sich um ein beschafftes Produkt handelt, ihre Normbezeichnung, wenn es sich um ein beschafftes Produkt handelt, das in einer Norm aus dem öffentlichen Bereich festgelegt ist. Entsprechend dieser Festlegung wird die Liste der unter Konfigurationsüberwachung zu stellenden Bestandteile erstellt. technische Beschreibung der Konfigurationseinheit Alle nach identifizierten Bestandteile und alle anderen austauschbaren Einheiten sind zu kennzeichnen oder zu etikettieren. Die Kennzeichnung der Bestandteile muß die vollständige Identifizierung und Rückverfolgbarkeit sicherstellen Die Dokumente, die zur Überwachung einer Konfigurationseinheit benötigt werden, sind in der Phase B zu identifizieren und beim vorläufigen Design-Review des entsprechenden Produkts oder spätestens bei Unterzeichnung der Geschäftsvereinbarung über die Entwicklung zu bestätigen. ZIEL: Identifizierung aller für die Konfigurationsüberwachung benötigten Dokumente. 16

23 Für Produkte, die im wesentlichen aus Hardware bestehen, gehören folgende Dokumente zur Identifizierung der Bezugskonfiguration: Funktionsspezifikation, falls zutreffend, Technische Spezifikation und allgemeine Spezifikationen (Umgebung, Strahlung, Designregeln, Schnittstellen...), Schnittstellenkontroll-Dokument, Produktions-Stammakte, Liste der Konfigurationseinheiten, Montage-/Installations-, Anwender-, Betriebs-, Wartungs-/Instandhaltungshandbücher, für die Empfehlungen zum Inhalt in ECSS-M festgelegt sind. Für Produkte, die im wesentlichen aus Software bestehen, gehören folgende Dokumente zur Identifizierung der Bezugskonfiguration: Anforderungen des Anwenders/Nutzers, Funktionsspezifikation der Software, Design-Beschreibung, Liste der Konfigurationseinheiten (Liste der Module), Liste der Quellcodes, Konfigurationsbeschreibung der Entwicklungswerkzeuge (z. B. Kompilierer, Linker). Sie müssen zu jedem Zeitpunkt den jeweils aktuellen Zustand des Produkts wiedergeben. Konfigurationsdokumentation für die Konfigurationseinheiten in dem Umfang verfügbar, wie es zum Start der Phase C erforderlich ist Die Dokumentationsliste, die die Grundlage (Baseline) einer Konfigurationseinheit identifiziert, muß vom Kunden genehmigt werden. Die vorgeschriebene Konfigurationsdokumentation steht bei den Reviews zur Verfügung. Die erfolgreiche Durchführung des Reviews zeigt die Zustimmung des Kunden zu den Produktmerkmalen und ermöglicht somit die Einführung der Bezugskonfigurationen. Die Konfigurationsdokumente der Konfigurationseinheiten stehen für die nächste Phase zur Verfügung. 17

24 5.1.8 Der Lieferant muß die Grundlage (Baseline) der Produktzustände nach Bild 1 identifizieren und aktualisieren. Dies betrifft: Bezugskonfigurationen, Konfiguration für die zu liefernden Einheiten, Konfiguration bei Auslieferung der Produkte Der Verbraucher muß die Grundlage (Baseline) der Konfigurationseinheit während ihres Einsatzes oder Betriebs aufrechterhalten. Bei Hardware-Produkten besteht die Konfiguration während des Betriebs aus: Konfiguration bei Auslieferung, wie im Endeinheit-Datenpaket identifiziert, Änderungen während des Betriebs, die in der Lebenslaufakte aufgezeichnet sind, für deren Inhalt Empfehlungen in ECSS-M festgelegt sind. Bei Software-Produkten wird die Konfiguration während des Betriebs in der Software-Konfigurationsdatei identifiziert. Leitlinien für die Software-Konfigurationsdatei sind in ECSS-M enthalten. angemessene Identifizierung der Konfigurationseinheit während des gesamten Produktlebenszyklus Jedes Produkt, das eine Konfigurationseinheit darstellt, muß eine eindeutige Bezeichnung tragen, die auf seine technische Beschreibung rückverfolgbar ist. ZIEL: eindeutige Verknüpfungen zwischen Produktbaum und zugehöriger Konfigurationsdokumentation. einheitliches Produkt- und Dokumenten-Identifizierungssystem Die Verantwortlichkeiten bezüglich des Schnittstellenmanagements sind nach ECSS-M-10 festzulegen. Die Schnittstellen sind anhand von Schnittstellenspezifikationen und/oder Schnitt-stellenkontroll- Dokumenten/Zeichnungen zu überwachen. Die Schnittstellen sind nach den folgenden unterschiedlichen Arten zu überwachen: systemexterne Schnittstellen, Schnittstellen zwischen Bestandteilen des Systems, Schnittstellen zwischen Konfigurationseinheiten. 18

25 Die Schnittstellenanforderungen sind direkt oder indirekt in die Produkt-TS aufzunehmen und in gleicher Weise wie diese TS abzuwickeln. Schnittstellenkontroll-Dokumente/Zeichnungen Konfigurationsdokumente (einschließlich Änderungen) sind nach den Anforderungen von ECSS-M-50 freizugeben. ZIEL: Sicherstellung, daß nur freigegebene Konfigurationsdokumente verwendet werden. nur freigegebene Konfigurationsdokumente in Gebrauch. 5.2 Konfigurationsüberwachung Die Bezugskonfiguration eines Produkts ist durch genehmigte Dokumente zu identifizieren. Die Einführung einer Bezugskonfiguration bestimmt den Ausgangspunkt des formalen Weiterentwicklungsverfahrens für Produkte und Konfigurationsdokumente. dokumentierte Bezugskonfiguration Änderungen der Dokumente unterliegen den gleichen Genehmigungs- und Verteilungsbedingungen wie die ursprünglichen Dokumente. ZIEL: Sicherstellung, daß die Information nur geändert wird, wenn alle Anforderungen eingehalten und die Änderung den betroffenen Beteiligten mitgeteilt wurden. genehmigte oder vereinbarte Änderungen von Dokumenten Formale Schritte sind für die Genehmigung von Bezugskonfigurationen festzulegen. Die Genehmigung von Bezugskonfigurationen erfolgt durch die in ECSS-M-30 beschriebenen Reviews. Nach Abschluß eines Reviews wird die Konfigurationsdokumentation mit den genehmigten Empfehlungen (siehe ECSS-M-30-01) aktualisiert. 19

26 Für jedes Hardware-Produkt wird die Genehmigung von Bezugskonfigurationen wie folgt erlangt: für die Entwicklungskonfiguration nach dem vorläufigen Design-Review mit der Genehmigung der TS und DJF, für die Produktionskonfiguration nach dem kritischen Design-Review (CDR) durch Genehmigung der Produktions- Stammakte (PMF) und des Schnittstellenkontroll-Dokuments (ICD) und Bestätigung beim Qualifkations-Review (QR) durch Genehmigung der Anwenderhandbücher, Lebenslaufakten und EIDP der Qualifikationsmuster. Für Software-Produkte wird die Genehmigung der Bezugskonfiguration erlangt: am Ende des Softwareanforderungs-Reviews, am Ende der kritischen Design-Reviews, beim Testbereitschafts-Review und dem Review nach dem Test. Genehmigungsverfahren verfügbar zu den Reviews Ein Änderungsverfahren ist einzuführen, um eine Weiterentwicklung einer Bezugskonfiguration zu dokumentieren. Änderungsverfahren Die Weiterentwicklung einer Konfigurationseinheit gegenüber einer genehmigten Bezugskonfiguration ist von der beantragenden Partei zu beschreiben, zu begründen und einzustufen, dann der für die Überprüfung und Genehmigung verantwortlichen Organisation des Beteiligten vorzulegen. ZIEL: Sicherstellung, daß jede Weiterentwicklung überprüft wird und ihre Folgen allen betroffenen Beteiligten bekannt sind. Nur eine Weiterentwicklung gegenüber einer genehmigten Bezugskonfiguration wird nach dem Änderungsverfahren bearbeitet. Weiterentwicklungen sind vom Antragsteller vorzulegen und zu begründen. Sie sind von der für die Überprüfung und/oder Genehmigung verantwortlichen Organisation des Beteiligten zu analysieren. Die Entscheidung muß sich aus einem gezielten formalen Überprüfungsprozeß ableiten lassen. Zusammenhängende Weiterentwicklungen von mehreren Produkten aus einem gemeinsamen Änderungsbedarf sind gleichzeitig zu behandeln und zu gewähren. Die Weiterentwicklung eines "gemeinsamen Elements" ist allen betroffenen Beteiligten zur Analyse und Beurteilung der Auswirkungen vorzulegen. dokumentierte und genehmigte Weiterentwicklung einer Konfigurationseinheit. 20

27 5.2.6 Vorgeschlagenen Änderungen sind vom Antragsteller nach den Regeln der Geschäftsvereinbarung einzustufen. ZIEL: Die Einstufung vorgeschlagener Änderungen bestimmt die Ebene, die befugt ist, über die Genehmigung zu entscheiden. Zwei Änderungsklassen sind zu unterscheiden: Klasse 1 betrifft alle Änderungen, die sich auf genehmigte technische Spezifikationen (einschließlich Schnittstellen der gleichen Ebenen) oder auf Bedingungen der Geschäftsvereinbarung zwischen einem Kunden und seinem Lieferanten beziehen. Eine Änderung der Klasse 1 erfordert die Zustimmung des Kunden, bevor sie durchgeführt wird. Klasse2 betrifft alle Änderungen, die nicht die Kriterien der Klasse 1 erfüllen. Eine Änderung der Klasse2 wird vom Lieferanten genehmigt, jedoch muß jede Änderung der Klasse 2 stets dem nächsthöheren Kunden zur Information und eventuellen Neueinstufung vorgelegt werden. Je nach den Folgen seiner Auswirkung läuft ein Änderungsantrag durch die verschiedenen Organisationsebenen bis zu der für seine Anwendung zuständigen Entscheidungsebene, d. h. der Ebene, für die die Folgen der Weiterentwicklung keine Auswirkungen auf die dem Kunden gegenüber eingegangenen Verpflichtungen haben. Die Weiterentwicklung wird jedoch dem nächsthöheren Kunden zur Information vorgelegt. Einstufung der Änderungen Jede Weiterentwicklung einer Konfigurationseinheit gegenüber einer Bezugskonfiguration ist nach Prüfung einer Bewertung und Entscheidung durch die beauftragte Kontrollstelle zu unterziehen, und zwar in einem formalen Verfahren, zu dem die betroffenen Beteiligten beizutragen haben. ZIEL: Sicherstellung, daß jede Weiterentwicklung in voller Kenntnis seitens aller betroffenen Beteiligten zur Anwendung kommt. Eine Weiterentwicklung kann: vom Kunden beantragt werden (Weiterentwicklung von Anforderungen). Diese Beantragung erfordert eine Antwort des Lieferanten in einer in der Geschäftsvereinbarung festzulegenden Frist. Geänderte Anforderungen können nur nach Prüfung und Genehmigung der Antwort des Lieferanten über einen formalen Änderungsantrag angewandt werden; vom Lieferanten vorgeschlagen werden (selbst initiierte Designverbesserung). In diesem Fall kann die zuständige Genehmigungsstelle beim Kunden der ersten Ebene angesiedelt sein. 21

28 Die Entscheidungen sind: entweder eine Zustimmung. Diese muß den Geltungsbereich der Weiterentwicklung und den entsprechenden Anwendungsmodus festlegen, oder eine Ablehnung. Diese muß kurz die Gründe für die Ablehnung angeben, oder eine Zurückstellung, bis Zusatzinformationen vorliegen. bewertete und dokumentierte Auswirkung der Weiterentwicklung Über jede Weiterentwicklung der Bezugskonfiguration einer Konfigurationseinheit muß nach den Festlegungen der Geschäftsvereinbarung berichtet werden. Diese Weiterentwicklung einer Bezugskonfiguration muß formal belegt werden. ZIEL: Formalisierung der Produktweiterentwicklung und Einhaltung der Nachvollziehbarkeit. Für jede vom Kunden beantragte Weiterentwicklung muß der entsprechende Änderungsantrag folgendes enthalten: Beschreibung der Änderung der Anforderungsdokumente, die sich aus der Beantragung des Kunden und den Änderungen von Anforderungen ergibt, Änderungsbeschreibung für das Design einschließlich Risikobewertung und Begründung der Notwendigkeit der Weiterentwicklung. Für jede vom Lieferanten vorgeschlagene Weiterentwicklung muß der entsprechende Änderungsantrag folgendes enthalten: Änderungsbeschreibungen bezüglich der gewünschten Designweiterentwicklung, gegebenenfalls Änderungen der Anforderungsdokumente zwecks Angleichung an die Designänderungen, resultierende Änderungen der Logistikdokumentation einschließlich der Änderungsdatenpakete, Beschreibung eventueller Änderungen von Geschäftsvereinbarungsbestimmungen (z.b. Kosten, Zeitplan, Sonderklauseln, Datenanforderungen usw.) Änderungsantrag Der Kunde oder der Lieferant muß alle Änderungen einschließlich Kosten- und Zeitplanauswirkungen nach einem formalen Verfahren einleiten. ZIEL: Statusklärung der Geschäftsvereinbarungsfestlegungen. Änderungsantragsverfügung. 22

29 Jeder Projektbeteiligte muß innerhalb der in der Geschäftsvereinbarung festgelegten Fristen den ihm von seinem Kunden oder Lieferanten vorgelegten Antrag oder Vorschlag auf Weiterentwicklung einer Bezugskonfiguration prüfen. ZIEL: Durchführung einer gründlichen Bewertung der Änderungsauswirkungen unter den vorgegebenen Zeitplangrenzen. Jeder Beteiligte muß ein internes Verfahren einführen, das die Analyse und Verfügung der vorgeschlagenen Änderung ermöglicht. Schwerpunkte dieser Analyse müssen die Auswirkungen (vertragliche, technische, qualitäts-, zuverlässigkeits- und sicherheitsbezogene) auf alle Produkte sein, für die der Beteiligte innerhalb des Projekts zuständig ist. internes Verfahren für die Bewertung der Änderungsauswirkungen In allen Fällen, in denen ein ausgehandelter und angenommener Änderungsantrag direkt die Bedingungen der Bezugsgrundlage (Baseline) der Geschäftsvereinbarung betrifft, muß die neue Bezugsgrundlage durch einen Nachtrag in die Geschäftsvereinbarung aufgenommen werden. ZIEL: Angleichung der Geschäftsvereinbarung an die vereinbarte Bezugsgrundlage. Aktualisierung der Bezugsgrundlage der Geschäftsvereinbarung Der Lieferant muß einen Antrag auf Sonderfreigabe von Nichtkonformitäten mit Anforderungen oder Design gegenüber der als Bezugsgrundlage dienenden Konfigurationsidentifizierungs-Dokumentation stellen. ZIEL: Alle Abweichungen von Anforderungen oder Design der Bezugsgrundlage sind von der jeweiligen Kundenebene zu gewähren. Bei planmäßigen Abweichungen von Anforderungen oder Design muß der Lieferant einen Antrag auf Sonderfreigabe (vor Realisierung) stellen, der den Umfang beschreibt, in dem das jeweilige Produkt die als Bezugsgrundlage dienende Konfigurationsidentifizierungs-Dokumentation nicht erfüllen wird. Bei unplanmäßigen Abweichungen vom Design aufgrund von Herstellungs- oder Softwarekodierfehlern, die üblicherweise von der Produktsicherung über Nichtkonformitätsberichte erfaßt werden, muß der Lieferant einen ordnungsgemäß eingerichteten Material-Untersuchungsausschuß oder Software-Untersuchungsausschuß einberufen. Wenn ein solcher Ausschuß "Verwendung wie vorliegend" oder "Reparatur"/"Korrektur (Patchcode)" verfügt, muß der Lieferant einen Antrag auf Sonderfreigabe (nach Realisierung) stellen, der die Designabweichung in der gleichen Weise wie oben dargelegt beschreibt, nur daß das nichtkonforme Produkt bereits produziert wurde und auf Anwendungszulassung wie in der Sonderfreigabe beschrieben wartet. ERWARTETES ERBEBNIS: Antrag auf Sonderfreigabe (vor oder nach Realisierung). 23

30 Die Überwachung der baulichen (physischen) und funktionellen Schnittstellen muß auf jeder Ebene der Organisation umgesetzt und in die Projekttätigkeiten integriert werden. Jeder Lieferant muß die internen Schnittstellen seiner Produkte identifizieren und überwachen und die für die Überwachung der externen Schnittstellen benötigten Daten bereitstellen. Verfahren zur Erstellung und formalen Genehmigung der Schnittstellendokumentation muß es im Projekt geben. Schnittstellenkontroll-Dokumente Die Weiterentwicklung von Schnittstellen ist nach einem formalen Änderungsverfahren zu behandeln. Die Änderungsanträge für alle Produkte, die von einer Schnittstellen-Weiterentwicklung betroffen sind, sind gleichzeitig zu bearbeiten und allen Beteiligten, die von Anforderungen bezüglich der Überwachung von Weiterentwicklungen betroffen sind, vorzulegen. formales Änderungsverfahren für Schnittstellen-Weiterentwicklung. 5.3 Konfigurations(status)buchführung Die Konfigurations(status)buchführung ist so zu organisieren, daß sie über ein System, das die Aufzeichnung und Verwendung von Konfigurationsdaten ermöglicht, abwickelbar ist. ZIEL: Die auf Projekt- und Komponentenebene erforderliche Gesamtabstimmung er-fordert auf jeder Ebene die Kenntnis und Verfolgung der Daten bezüglich der Konfiguration der Einheiten. Jeder Beteiligte muß ein System umsetzen, das das Aufzeichnen der Konfigurationsdaten seiner Produkte und die vollständige Rückverfolgbarkeit ihrer Weiterentwicklung ermöglicht. Dieses System muß ohne Änderung einen schnellen Informationsfluß ermöglichen. Dieses System muß es jedem Lieferanten ermöglichen, Kenntnis zu erlangen über: Status der Konfigurationseinheiten, Status der Konfigurationsdokumentation, Status der Genehmigung von Änderungsanträgen und Stand ihrer Umsetzung in Produkten und Dokumenten, Status der Sonderfreigaben (nach Realisierung), Status der aus technischen Reviews und Konfigurationsverifizierungs-Reviews abgeleiteten Maßnahmen. 24

31 Das von jedem Beteiligten angewandte System ist zu beschreiben. dokumentiertes Statusbuchführungssystem Jeder Lieferant muß seinem Kunden Statusberichte über die Konfiguration der Produkte, für die er verantwortlich ist, liefern. Das Aufzeichnungssystem für das Konfigurationsmanagement muß folgendes enthalten: für jedes Produkt: Status der als Bezugsgrundlage dienenden Dokumente und Liste der genehmigten Weiterentwicklung, für jedes Einzelmodell: Status der gültigen und ausgeführten Änderungsanträge, Konfigurationsstatus, wobei für jedes Einzelmodell folgendes anzugeben ist: gültige Dokumente, Implementierungsstatus der genehmigten Weiterentwicklung, gültige Engineering-Sonderfreigaben (nach Realisierung) und ihr Status. Konfigurationsstatusberichte, Software-Konfigurationsdatei. 5.4 Konfigurationsverifikation Projektreviews müssen die Festlegung von Bezugskonfigurationen, wie in Abschnitt 4.5 definiert, zur Folge haben. Projektreviews und ihre Ziele sind in ECSS-M-30 festgelegt; Einzelheiten über ihre Organisation und Durchführung sind in ECSS- M angegeben. Dem Konfigurationsmanagement dienen sie zur Überprüfung der Produktkonfiguration und zur Feststellung und Genehmigung einer Bezugskonfiguration. Am Ende eines jeden Reviews werden die Dokumente, die die aktuelle Bezugskonfiguration identifizieren, mit den gemachten Empfehlungen aktualisiert und dann dem Kunden zur Genehmigung vorgelegt. Bezugskonfigurationen Audits zur Verifizierung der Anwendung von Konfigurationsmanagementanforderungen sind im Verlauf des Produktlebenszyklus durchzuführen. Jeder Kunde muß interne und externe Audits über Konfigurationsmanagementtätigkeiten durchführen. Planung und Berichte über diese Audits sind seinem Kunden zu übermitteln, der sich das Recht vorbehalten kann, an solchen Audits teilzunehmen. Auditbericht,, Festlegung und Verwirklichung von Abhilfemaßnahmen. 25

32 5.5 Umsetzungsmethoden: Implementierungsdokument für das Konfigurationsmanagement Jeder Beteiligte muß ein Implementierungsdokument für das Konfigurationsmanagement ausarbeiten und seinem Kunden zur Genehmigung vorlegen. Die Norm ECSS-M-30 legt die Projektphase fest, in der das Implementierungsdokument für das Konfigurationsmanagement erstellt und genehmigt werden muß. Das Implementierungsdokument (nach ECSS-M-40-01) jedes Beteiligten muß die Organisation, Methoden, Mittel und Verfahrensweise beschreiben, die zum Management der Konfiguration seiner Lieferungen in Übereinstimmung mit dem Projektanforderungsdokument für das Konfigurations-management eingesetzt werden. Auf jeder Organisationsebene ist jeder Kunde für die Annahme der Implementierungsdokumente seiner Lieferanten verantwortlich. Der Inhalt der Projekt-Implementierungsdokumente muß alle Konfigurationsmanagementaufgaben und -tätigkeiten ohne Redundanz, jedoch nicht ohne festgelegte Schnittstellen zwischen den Beteiligten, erfassen. Das Implementierungsdokument muß eine Konformitätsmatrix als Nachweis der Übereinstimmung mit zu den Anforderungen des Projektanforderungsdokuments für das Konfigurationsmanagement enthalten. Interne Verfahren, die zur Sicherstellung des Konfigurationsmanagements gemäß Implementierungs-dokument angewandt werden, sind je nach Bedarf im Werk des Lieferanten unter Beachtung der in ECSS-M-50 festgelegten Zugangsregeln darzulegen. Implementierungsdokument für das Konfigurationsmanagement. 26