Raumfahrt- Projektmanagement - DLR · ECSS-M-30-01A 1. September 1999 Vorwort Diese Norm gehört zu...

ECSS-M-30-01A 1. September 1999

Raumfahrt- Projektmanagement Vorbereitung und Durchführung von Reviews


Deutsche Übersetzung Herausgeber Deutsches Zentrum für Luft- und Raumfahrt e.V. Qualitäts- und Produktsicherung Nationales ECSS-Sekretariat Anschrift Porz-Wahnheide Linder Höhe D-51147 Köln Technische Bearbeitung Dr.-Ing. Andreas K. Jain Telefon (0 22 03) 6 01 - 29 54 Telefax (0 22 03) 6 01 - 32 35 E-Mail [email protected] Redaktion Ruth Opperbeck Telefon (0 22 03) 6 01 - 21 99 Telefax (0 22 03) 6 01 - 32 35 E-Mail [email protected] Preis 15 € Englische Originalausgabe

Herausgeber ESA Publications Division ESTEC, Postfach 299 2200AG Noordwijk Niederlande Copyright 1999 ©: European Space Agency für die Mitglieder von ECSS


Vorwort Diese Norm gehört zu einer Reihe von ECSS-Normen, die sich auf das Management, die Technik (Engineering) und die Produktsicherung bei Projekten und Anwendungen der Raumfahrt beziehen. ECSS ist ein Gremium, in dem die Europäische Raumfahrtagentur ESA, nationale Raumfahrtagenturen sowie europäische Industrieverbände mit dem Ziel zusammenarbeiten, einheitliche Normen zu erstellen und zu pflegen. Diese Norm legt Anforderungen als Ziele fest, die zu erreichen sind und nicht in Bezug auf die Organisation und Durchführung der erforderlichen Arbeiten. Dies ermöglicht es, bewährte Organisationsstrukturen und -verfahren beizubehalten und erlaubt gleichzeitig deren Weiterentwicklung, ohne dass die Normen überarbeitet werden müssen. Bei der Erarbeitung dieser Norm wurde die Normenreihe ISO 9000 berücksichtigt. Diese Norm wurde von der ECSS-Arbeitsgruppe M-30-01 erstellt, vom Technischen Ausschuss der ECSS geprüft und vom ECSS-Lenkungsgremium verabschiedet.

i


Inhaltsverzeichnis

Seite

Vorwort ..................................................................................................................... i

Einleitung ........................................................................................................................ .. 1

1 Zweck ............................................................................................................... .. 3

2 Normative Verweisungen .............................................................................. .. 5

3 Begriffe und Abkürzungen ............................................................................ .. 7 3.1 Begriffe .............................................................................................................. .. 7 3.2 Abkürzungen ..................................................................................................... .. 7

4 Grundsätze ...................................................................................................... .. 9 4.1 Allgemeines ....................................................................................................... .. 9 4.2 Reviewarten und Zeitpunkt für die Durchführung von Reviews........................... .. 9

5 Reviewprozess................................................................................................. 15 5.1 Allgemeines ....................................................................................................... 15 5.2 Teilnehmer an Reviews....................................................................................... 16 5.3 Aufgaben........................................................................................................... 17 5.4 Bedingungen für die Durchführung von Reviews................................................ 19 5.5 Reviewplan ........................................................................................................ 19 5.6 Sitzungen/Treffen im Rahmen eines Reviews ...................................................... 20 5.7 Review-Abweichungsmeldungen - Aufzeichnung und Behandlung .................... 21

6 Ergebnisse des Reviews und weiterführende Maßnahmen........................ 23 6.1 Abschlussbericht des Review-Ausschusses .......................................................... 23 6.2 Weiterführende Maßnahmen............................................................................. 23

Anhang A (informativ) Hilfsmittel zur Durchführung von Reviews ............................. 25

A.1 Allgemeines ..................................................................................................... 25

A.2 Template für Reviewplan ............................................................................... 25

A.3 Begleitdokumentation.................................................................................... 26

A.4 Review-Abweichungsmeldungen .................................................................. 28

Bilder Bild 1: Beziehungen und Schnittstellen zwischen Teilnehmern an Reviews (schematisch) .......................................................... 16 Bild 2: Ablaufdiagramm zur Behandlung von Review-Abweichungsmeldungen ....... 22 Tabellen Tabelle 1: Definition der Anforderungen – Tätigkeiten .................................................. 11 Tabelle 2: Verifikation – Tätigkeiten und Ergebnisse...................................................... 12 Tabelle 3: Bereitschaft und Betrieb – Tätigkeiten........................................................... 13

ii


ii


Einleitung Projektüberprüfungen (Projektreviews) sind Untersuchungen zum technischen Stand eines Projekts und zugehöriger Fragen zu einem bestimmten Zeitpunkt. Sie dienen einer umfassenden Beurteilung durch die Unabhängigkeit der am Review Beteiligten und der Unterstützung des Projekts in kritischen Phasen, wodurch es den Verantwortlichen Sicherheit in der Kenntnis des Projektfortschritts in technischer Hinsicht geben soll. Der Erfolg eines Reviews hängt von der Planung, Organisation und der Regelung der Zuständigkeiten vor dem Review sowie den Abläufen ab, die für die Durchführung der Maßnahmen, die sich aus Reviews ergeben, vorgesehen sind. Ein ungenügend vorbereitetes oder durchgeführtes Review hat wenig Aussicht auf Erfolg, und auch ein gut organisiertes Review wird wenig erreichen, wenn aufgetretene Fragen bzw. Probleme nicht in angemessener Zeit zur Zufriedenheit des Kunden beantwortet bzw. gelöst werden. Da unvorbereitete Teilnehmer an Reviews weder effektiv noch produktiv sind, ist sowohl für den Kunden als auch für den Lieferanten die richtige Vorbereitung eines Reviews von ausschlaggebender Bedeutung. Diese ECSS-Norm gehört zu der Normenreihe „Raumfahrt-Projektmanagement“ (siehe ECSS-M-00). Reviews werden nach Bild 1 von ECSS-M-30A während der Projektlebensdauer auf allen Ebenen von der System- bis zur Geräteebene durchgeführt. Zweck, Auftrag und Dokumentation eines Reviews variieren projektspezifisch sowie in Abhängigkeit von den Phasen bzw. Stufen eines Projekts.


2


1 Zweck Diese Norm liefert die Mittel zur Bestimmung und Strukturierung der Informationen und Tätigkeiten, die bei einem Projektreview erforderlich sind. Sie legt die Ziele der Information und Tätigkeiten fest, die für die Durchführung des Reviews erforderlich sind. Weiterhin gibt sie in Form einer Checkliste die Informationen und Tätigkeiten an, die für die bei den ECSS-Normen zum Projektmanagement genannten wichtigen Reviews erforderlich sind. Diese Norm schreibt kein bestimmtes Verfahren für die Durchführung von Reviews oder die entsprechende Organisationsstruktur vor, um die internen Richtlinien und Vorschriften des Kunden zu respektieren. Unter projektspezifischen Gesichtspunkten sollten die in dieser Norm definierten Anforderungen angepasst werden, um dem jeweiligen Projektprofil und den Projektumständen Rechnung zu tragen.

ANMERKUNG: Anpassung ist ein Prozess, in dem einzelne Anforderungen oder Spezifikationen, Normen und ähnliche Dokumente nach Bewertung für ein bestimmtes Projekt ausgewählt werden. Die einzelnen Vertragsbedingungen können eine Streichung, Ergänzung oder Modifikation der Anforderungen dieser Norm erforderlich machen.


4


2 Normative Verweisungen Die folgenden normativen Dokumente enthalten Festlegungen, die durch Verweisung in diesem Text Bestandteil dieser ECSS-Norm sind. Bei datierten Verweisungen gelten spätere Änderungen oder Überarbeitungen dieser Publikationen nicht. Anwender dieser ECSS-Norm werden jedoch gebeten, die Möglichkeit zu prüfen, die jeweils neuesten Ausgaben der nachfolgend angegebenen normativen Dokumente anzuwenden. Bei undatierten Verweisungen gilt die letzte Ausgabe der in Bezug genommenen Publikation. ECSS–P–001 Glossar ECSS–M–30A Raumfahrt-Projektmanagement – Projektphaseneinteilung und –planung.


6


3 Begriffe und Abkürzungen

3.1 Begriffe Ergänzend zu den Begriffen nach ECSS–P–001 gelten folgende Begriffe.

3.1.1 Missionsanforderungsdokument Dokument, das die Missionsparameter, die vom System geforderte Leistung und die Ziele festlegt.

3.1.2 Systemanforderungsdokument Dokument, das die Systemfunktion, Leistung des Systems, die vom Systemsegment zu erreichenden Ziele und die entsprechenden Schnittstellen definiert.

3.2 Abkürzungen In dieser Norm werden folgende Abkürzungen verwendet: Abkürzung Bedeutung

CI (Configuration Item) Konfigurationseinheit

CIDL (Configuration Item Data List) Verzeichnis der Konfigurationseinheiten

D&D (Design & Development) Design und Entwicklung

DRL (Document Requirements List) Liste der vertraglich geforderten Dokumente

EOLR (End-of-Life Review) Review am Ende der Lebensdauer

FQR (Flight Qualification Review) Flugqualifikationsreview

MDR (Mission Definition Review) Missionsdefinitionsreview

MRD (Mission Requirements Document) Missionsanforderungsdokument

ORR (Operational Readiness Review) Betriebsbereitschaftsreview

PA/S (Product Assurance/Safety) Produktsicherung/Sicherheit

RID (Review Item Discrepancy) Review-Abweichungsmeldung

SRD (System Requirements Document) Systemanforderungsdokument

SWCI (Software Configuration Item) Software-Konfigurationseinheit.


8


4 Grundsätze

4.1 Allgemeines Für Reviews bei europäischen Raumfahrtprojekten gilt der Grundsatz, dass eine sorgfältige Untersuchung des technischen Stands des Projekts in kritischen Phasen des Programms durchgeführt wird, was die Einschaltung unabhängiger Experten einschließt. In Reviews wird die von den an einem Projekt Beteiligten geleistete Arbeit anhand der gegebenen Projektanforderungen die richtige Anwendung dieser Anfor-derungen sowie von Normen und die Art der Durchführung der Arbeit beurteilt. Dabei ist es sehr wichtig, dass der Status aller Elemente des zu überprüfenden Systems und seine Schnittstellen (z. B. Startplattform, Raumfahrzeug, Bodensegment, Nutzlasten und Betriebsabläufe) betrachtet werden. Das Ziel von Reviews ist es, dem Kunden während des gesamten Programms die Überzeugung zu vermitteln, dass zum Zeitpunkt der einzelnen Reviews: • die Erfüllung der Ziele der Mission machbar erscheint; • Anforderungen hinreichend genau festgelegt sind, so dass bei deren Erfüllung die Missionsziele

erreicht werden; • die Designdefinition (einschließlich Hardware, Software, Betrieb) die festgelegten Anforderungen

einschließlich einschlägiger Normen für alle Teile des Systems erfüllt; • alle Einheiten der Konfiguration den Anforderungen hinsichtlich Design, Konfiguration und

Leistung entsprechen; • eine Verifizierung auf Erfüllung aller festgelegten Anforderungen von der Bauteilebene bis zur

Systemebene erfolgt ist; • kein ernst zu nehmendes Risiko übersehen wurde, das die Sicherheit und den Erfolg der Mission

gefährden oder einen starken Einfluss auf die terminlichen und finanziellen Aspekte des Programms haben könnte.

Ein Review stellt in einem Projekt einen Hauptmeilenstein dar, bei dem die Verantwortung des Managements besonders gefragt ist. In ihm werden mögliche Probleme in einem frühen Stadium ermittelt und es fällt - je nach Aufgabenstellung des Review-Ausschusses - Entscheidungen oder gibt Empfehlungen an das Projektmanagement zur Lösung dieser Probleme. Außerdem können die Ergebnisse von Projektreviews auch für den Lieferanten als Anhaltspunkt dafür dienen, inwieweit er gegebene Anforderungen erfüllt hat.

4.2 Reviewarten und Zeitpunkt für die Durchführung von Reviews Jedes Review sollte so geplant werden, dass es am Ende eines natürlichen Abschnitts im Arbeitsablauf und dann erfolgt, wenn genügend Informationen vorhanden sind, um die nächste Arbeitsphase sicher beginnen zu können. Von diesem Grundsatz kann projektspezifisch abgewichen werden. Nach ECSS-M-30A gilt der Grundsatz, dass Tätigkeiten übergreifend sein dürfen. Bei der Formulierung der geforderten Ziele für bestimmte Phasen mag eine engere Definition angebracht sein. Dies gilt insbesondere für die frühen Stufen eines Projekts und sollte in dem entsprechenden Projektanforderungsdokument festgelegt sein.


In dieser Norm wurde eine Reviewfolge festgelegt, die den Tätigkeiten nach ECSS-M-30A, Abschnitt 4, und dem Grundsatz nach Abschnitt 7 („definieren ‘top down’, produzieren und verifizieren ‘bottom up’“) entspricht. Dies bedeutet, dass: a) Anforderungen und Designdefinition von der Ebene der Missionsziele hinunter zur niedrigsten

Designebene festzulegen sind; b) die Verifizierung von der Konfigurationseinheit auf der niedrigsten Ebene bis hinauf zur Ebene, auf

der Missionsbereitschaft gegeben ist, durchzuführen ist. Die für die Reviews auf den verschiedenen Systemebenen geltenden Anforderungen nach ECSS-M-30A, Abschnitt 7, werden hier in den Tabellen 1, 2 und 3 ausführlich beschrieben. Projektreviews sind auf Systemebene durchzuführen, aber häufig auch auf niedrigeren Ebenen (Teilsysteme, Geräte, Softwareeinheiten) erforderlich. Art und Anzahl der Reviews hängen von der Projektgröße, der Komplexität, den technischen Risiken und davon ab, ob es sich um ein Produkt handelt, das mehrfach eingesetzt wird. Das kritische Design und das Abnahmereview für Teilsysteme und Geräte müssen vor Beginn des Reviews auf Systemebene abgeschlossen sein. An Reviews auf Systemebene sollten der Kunde sowie der Lieferant der ersten Ebene teilnehmen. An den Reviews auf niedrigerer Ebene sollten wiederum Lieferant der ersten Ebene und dessen Lieferanten (und so weiter) beteiligt werden. Der Kunde ist immer berechtigt, an einem Review auf niedrigerer Ebene teilzunehmen, was Reviews auf der Ebene seiner eigenen Lieferanten einschließt. Im letzteren Fall sollte der Kunde aufgrund seiner technischen Kenntnisse und Erfahrungen eher beratend teilnehmen. In bestimmten Fällen kann sich der Kunde jedoch direkt an Reviews auf niedrigerer Ebene beteiligen, um gewisse technische oder programmatische Risiken möglichst gering zu halten. Derartige Fälle sind vertraglich mit Angabe der Aufgaben und der Rechte des Kunden bei solchen Reviews zu benennen (d. h. Mitvorsitz in Reviewausschüssen). Entsprechend dem typischen Projektlebenszyklus nach ECSS-M-30 werden in dieser Norm die folgenden Reviews behandelt: • Systemanforderungsreview; • Vorläufige Designreviews; • Kritische Designreviews; • Qualifikationsreviews; • Abnahmereviews. Diese Reviews werden allgemein auf allen Produktebenen durchgeführt.

10

Tabelle 1: Definition der Anforderungen – Tätigkeiten

Abgeschlossene Tätigkeit Reviewbezeichnung (Systemebene)

Ergebnis für System Ergebnis für Teilsystem(e)

Ergebnis für Geräte

Ermittlung von Kundenanforderungen und Ausgangskonzept

Missionsdefinitions-review MDRa)

Bestätigung der Anforderungen an die Mission Entfällt Entfällt

Umwandlung der Kundenanforderungen bzw. Anforderung an die Mission in Systemanforderungen, (d. h. Prüfung der Mach-barkeit und Validierung der Systemarchitektur)

Vorläufiges Anfor-derungs-Review PRRb)

Bestätigung der Machbarkeit in Bezug auf das System und Freigabe der Spezifikation für Funktion.

Festlegung der Anforderungen an Systemschnittstellen durch Kunden auf der ersten Ebene

Zuordnung von Anforderungen an die Funktion des Teilsystems

Entfällt

Festlegung der Spezifikation für die Systemtechnik

Systemanforderungs-review SRRc)

Beurteilung der Leistung des Systems (vorläufig) entsprechend den Anforderungen an die Systemfunktion.

Auswertung der Hauptpläne (z. B. D&D, AIV, PA/S).

Überprüfung der Konfiguration. Freigabe der technischen Spezifikation für das System (einschließlich äußerer Schnittstellen)

Zuordnung von tech-nischen Anforderungen an die Teilsysteme

Ermittlung der tech-nischen Anforderungen im Falle kritischer Technologie

Festlegung der vorläufigen Designs

Vorläufiges Design-review PDR

Beurteilung der Leistung des Systems auf der Grundlage von Analyseergebnissen, Bestätigung der Bereitschaft und Verträglichkeit zwischen Design- und Kundenanforderungen in technischer Hinsicht, Genehmigung von Projektplänen (z. B. Qualifikations-plan, Verifizierungs- und Testplan) und Normen. Bestätigung der Verifikationsgrundsätze, Design von Sonderausführungen, Festlegung innerer Schnittstellen

Überprüfung der Konfiguration.

Definition von Test- und Verifikationsverfahren. Freigabe technischer Spezifikationen für Teilsysteme

Zuordnung von tech-nischen Anforderungen an die einzelnen Geräte. Definition von Test- und Verifikationsverfahren

a) Im Allgemeinen internes Review des Kunden. b) Im Allgemeinen internes Review des Kunden zur Bestätigung der Machbarkeit. c) Das Review auf Systemebene sollte die Grundlage für den Lieferanten der ersten Ebene zur Durchführung der eigenen Reviews für die von ihm gelieferten

Teilsysteme sein.

11

12

Tabelle 2: Verifikation – Tätigkeiten und Ergebnisse

Abgeschlossene Tätigkeit Reviewbezeichnung (Systemebene) Ergebnis für System Ergebnis für Teilsystem(e)

und Geräte

Durchführung von Entwicklungstests

Festlegung des Designs für den Lieferanten

Kritisches Design-Review CDRa)

Designbegründungsakte (z. B. mit Angaben zur Integration und der Prüfung von Test von Funktionsmodellen, Designanalysen, vorläufige Version der Kundendokumentation)

Dokumente mit Angaben der herzustellenden bzw. zu kaufenden Teilsysteme/Geräte, Testverfahren

Integration eines und Test an einem Qualifikationsmodell(s).

Für Bodenelemente technische Qualifikation (z. B. des Kontrollzentrums und der Bodenelemente des Kunden)

Qualifikationsreview QRb)

Qualifikation des Bodensystems durch den Kunden

Testergebnisse und -analysen

Berichte zur Designbegründung (Analyse- und Überprüfungsberichte) und Qualifikation

Kundendokumentation

Qualifikation der Bodenelemente

Grundsätze für Produktkonfiguration durch CIDL-Freigabe

Abschluss der Designverifikation (Test, Analysen und Über-prüfungen).

Grundsätze für Produktkonfi-guration durch CIDL-Freigabe

Integration eines und Test an einem Flugmodell(s) entspre-chend dem qualifizierten Design

Abnahmereview ARc)

Abnahme des Flugmodells, Analysen, Verifizierung und Zertifizierung

Verifikation der Produkte (Test, Überprüfungen)

a) Vor Durchführung dieses Reviews am System sollten die kritischen Designreviews für die Teilsysteme und das Designreviews für das/den Bodensegment/Bodenbetriebs durchgeführt sein.

b) In diesem Rahmen sollte auch das Review für die Implementierung des Bodensegments durchgeführt werden. c) Vor Durchführung des Abnahmereviews müssen die Abnahmereviews für die Teilsysteme durchgeführt sein.

Tabelle 3: Bereitschaft und Betrieb – Tätigkeiten

13

Abgeschlossene Tätigkeit Reviewbezeichnung (Systemebene) Ergebnis für System Ergebnis für Teilsystem(e) Ergebnis für

Geräte

Erreichen der Betriebsbereitschaft Betriebsbereit-schaftsreview ORR

Qualifikation für Betrieb und Erklärung der Betriebsbereitschaft

Angemessene Teamgröße ermittelt und Schulung, Prüfung des Betriebs unter Nennbedin-gungen und verschlechterten Bedingungen

Entfällt

Verträglichkeit und Bereitschaft des Bauteils für den Flug

Flugbereitschafts-review FRR

Bestätigung der korrekten Funktion bezüglich der Anforderungen an die Mission und Schnittstellen zwischen allen Elementen des Systems

Bestätigung der Konfiguration „wie hergestellt“

Entfällt

Startvorbereitung abgeschlossen und Eignung für die Mission verifiziert

Startbereitschafts-review LRR

Bestätigung, dass Betriebsbereitschafts- und Flugbereitschaftsreview ordnungsgemäß abgeschlossen sind

Erklärung der Startbereitschaft

Entfällt Entfällt

Test und Verifikation der tatsächlichen Leistung gegenüber den Anforderungen der Mission nach üblicher Zeit des Flugbetriebs oder Einsatzes

Flugqualifikations-review FQR

Qualifikation für den Betrieb des Systems oder nach Überprüfung im Orbit, Eignung zur Erfüllung der vorgesehenen Mission

Entfällt Entfällt

Ende der Betriebs- oder Einsatzzeit Review am Ende der Lebensdauer EOLR

Zustand und Verfahren für Endverwendung, Bergung und Wiedereintritt

Erfahrungen Erfahrungen


14


5 Reviewprozess

5.1 Allgemeines Für die Durchführung von Projektreviews bedarf es solider Fachkenntnisse und Unabhängigkeit, so dass sowohl die Interessen des Projektteams des Kunden als auch des Lieferanten berücksichtigt werden. Deshalb muss der Kunde darauf achten, dass in seinem Review-Ausschuss diese Unabhängigkeit und langjährige Erfahrung gegeben ist. Reviewausschüsse müssen Zugang zu allen zur Durchführung ihrer Aufgaben notwendigen Informationen erhalten. Für die Erreichung der Ziele eines Reviews sind die folgenden Faktoren besonders von Bedeutung: • rechtzeitige Definition der Inhalte des Datenpakets; • Zulieferung der Daten hinsichtlich der Ziele des Reviews und rechtzeitige Übergabe eines

vollständigen Datenpakets entsprechend den Vereinbarungen; • Überprüfung der Arbeitsdokumente; • eindeutige Identifizierung und Zuordnung der Aufgaben an den Review-Ausschuss; • Überprüfung der Dokumente durch den Review-Ausschuss mit nachfolgender Erstellung und

Weiterleitung von Review-Abweichungsmeldungen (siehe Abschnitt 5.7); • Zusammenfassung der Antworten des Auftragnehmers auf Fragen in einem frühen Stadium des

Reviewprozesses (z. B. 5 Arbeitstage nach Überprüfung des Datenpakets); • Bestätigung der vorgesehenen Vorgaben und von Empfehlungen des Ausschusses an den Kunden; • Entscheidungen des Kunden, sofern vorliegend; • Weiterverfolgung im Rahmen des Projekts und Bestätigung der ordnungsgemäßen Beendigung

bestimmter Tätigkeiten. Ein weiteres Ergebnis von Reviews kann eine Zusammenstellung von Angaben zu den dabei gewonnenen Erkenntnissen sein. Im Folgenden werden Anforderungen für die Vorbereitung und Durchführung von Reviews und zu den Aufgaben und Zuständigkeiten der Teilnehmer an Reviews festgelegt.

15


5.2 Teilnehmer an Reviews Zu den Teilnehmern eines Reviews gehören das Entscheidungsgremium, das Projektteam des Lieferanten und der Review-Ausschuss (siehe Bild 1).

Reviewantrag und Vorgaben (1)

Datenpaket (2)an Reviewausschussüber Projektteamdes Kunden

RIDs (3)

Dialog

Antworten (4)

Beratung,Optionen und

Empfehlungen (5)

Entscheidungen (6)(über Projektteam des Kunden)

Entscheidung

Entscheidungsgremium(der Kundenorganisation)

Beratung

Reviewausschuss

Arbeitsgremien

Durchführung

Projektteam desLieferanten

Review-Ausschuss

Review-Ausschuss

ANMERKUNG: Zahlen in Klammern zeigen den Verlauf des Informationsflusses.

Bild 1: Beziehungen und Schnittstellen zwischen Teilnehmern an Reviews (schematisch)

Das Entscheidungsgremium hat die führende Funktion im Reviewprozess. Organisatorisch kann es die Form eines Lenkungsausschusses, eines Programmausschusses oder eine andere Form haben. Es muss mit Verantwortlichen höherer Ebene besetzt sein, • die Weisungsbefugnis gegenüber den am Projekt Beteiligten haben; • die mit Vollmachten ausgestattet sind, um notwendige Entscheidungen treffen zu können, oder

leichten Zugang zu Personen mit diesen Vollmachten haben. Den Vorsitz in diesem Gremium, das alle ein Review betreffenden Fragen (z. B. Zweck des Reviews, Aufgabenstellung für den Review-Ausschuss, Planung und Organisation des Reviews, Empfehlungen des Ausschusses, Maßnahmen zur Fehlerbeseitigung) erörtern und einvernehmlich regeln soll, muss ein Vertreter der Organisation des Kunden einnehmen, wie auch mindestens der Projekt- oder Programmmanager des Kunden und das Management des Lieferanten vertreten sein müssen. Dem Projektteam des Lieferanten obliegt die Durchführung des Reviews. Mit der Bereitstellung der zu prüfenden Dokumentation dürfen einige der Teammitglieder beauftragt werden, während alle Mitglieder (einschließlich der Bereiche, die das Projektteam in technischer Hinsicht unterstützen) gehalten sind, dem Review-Ausschuss die gewünschten Informationen zu liefern und Fragen zu Review-Abweichungs-meldungen beantworten.

16


Der Review-Ausschuss hat beratende Funktion. Ihm sollten die Vertreter der Organisation des Kunden angehören, die nicht direkt an der Projektarbeit beteiligt sind, auch müssen ihm technische Fachleute und Vertreter der Produktsicherung angehören. Ebenso dürfen qualifizierte Fachleute von dritter Seite mit spezifischen, für das Review relevanten Kenntnissen, z. B. • Fachleute für die Entwicklung oder Herstellung der betreffenden Produktart (oder ähnlicher

Produkte); • Fachleute, die für den Betrieb und die Instandhaltung vergleichbarer Produkte verantwortlich sind; • Vertreter angrenzender Systeme, Bauteile oder Projekte vertreten sein. Der Review-Ausschuss sollte während der gesamten Projektdauer aus denselben Kernmitgliedern bestehen. Der/die Vorsitzende des Review-Ausschusses muss generell der Organisation des Kunden entstammen, er/sie darf jedoch nicht Mitglied von dessen Projektteam und diesem gegenüber weisungsbefugt sein. Er/sie bedarf der Ernennung durch das Entscheidungsgremium, muss dem Projekt- oder Programmmanager gegenüber gleich- oder höherrangig sein und führt während des Reviewprozesses die Fachaufsicht über den Review-Ausschuss. • In manchen Fällen darf der Review-Ausschuss auch am Entscheidungsprozess mitwirken. Dann ist

jedoch die Zusammensetzung von Entscheidungsgremium und Review-Ausschuss aufeinander abzustimmen.

• Das Projektteam des Kunden hat keine überprüfende Funktion. Für den Erfolg des Reviews ist

jedoch seine Unterstützung für den Review-Ausschuss und in gewissem Umfang auch für das Projektteam des Lieferanten von besonderer Bedeutung.

• Der Review-Ausschuss darf Arbeitsgruppen, Arbeitskreise usw. benennen, was von der Komplexität

des zu prüfenden Produkts abhängt.

5.3 Aufgaben

5.3.1 Entscheidungsgremium Das Entscheidungsgremium muss: a) die Ziele des Reviews definieren; b) die Vorgaben für den Review-Ausschuss festlegen; c) den Reviewplan bestätigen; d) die/den Vorsitzende/n des Review-Ausschusses ernennen; e) die Mitglieder des Review-Ausschusses in Abstimmung mit dem/der Vorsitzenden des Review-

Ausschusses bestätigen; f) den Abschlussbericht des Review-Ausschusses (der vom Vorsitzenden des Review-Ausschusses

vorgelegt wird) prüfen; g) die sich aus dem Review ergebenden Empfehlungen und erforderlichen Maßnahmen prüfen; h) die erforderlichen Entscheidungen treffen.

17


5.3.2 Projektteam des Lieferanten Das Projektteam des Lieferanten muss: a) den Reviewplan vorschlagen, falls es vom Projektmanager des Kunden gefordert wird; b) für die Durchführung der Sitzungen der Reviewteilnehmer die vom Projektteam des Kunden

gewünschten erforderlichen Voraussetzungen schaffen und die Treffen betreuen; c) sicherstellen, dass die erforderliche Dokumentation sowie alle notwendigen Mittel und

Informationen für das Review zur Verfügung stehen und auf dem aktuellen Stand sind; d) Review-Abweichungsmeldungen bearbeiten und einen Zeitplan für die Durchführung der

erforderlichen Maßnahmen vorschlagen; e) den Sekretär für das Review ernennen, wenn vom Projektteam des Kunden gewünscht.

5.3.3 Vorsitzender des Review-Ausschusses Die/der Vorsitzende des Review-Ausschusses muss: a) den Reviewplan bestätigen und diesen dem Entscheidungsgremium zuleiten; b) die Mitglieder des Review-Ausschusses auswählen und Vorschläge für die Mitgliedschaft im

Entscheidungsgremium machen; c) die Arbeit des Review-Ausschusses leiten; d) den Stand der Arbeiten aufgrund des vorhergehenden Reviews des Projekts prüfen; e) prüfen, ob die vorgelegte Dokumentation den Zielen des Reviews entspricht; f) Feststellungen über Review-Abweichungsmeldungen bestätigen; g) Antworten des Lieferanten zu Review-Abweichungsmeldungen einholen; h) den Review-Abschlussbericht (mit Empfehlungen) erstellen.

5.3.4 Mitglieder des Review-Ausschusses Die Mitglieder des Review-Ausschusses müssen unter Führung der/des Vorsitzenden: a) die vorgelegte Dokumentation prüfen; b) Probleme ermitteln oder auf dem Wege von Erläuterungen Review-Abweichungsmeldungen

anfordern (siehe Abschnitt 5.7); c) an Review-Abweichungsmeldungen abschließend mitwirken und ungelöste Probleme als größer

oder geringer klassifizieren; d) Empfehlungen geben, wenn die Antwort des Lieferanten auf eine Review-Abweichungsmeldung

als nicht ausreichend angesehen wird.

18


5.3.5 Aufgaben des Sekretärs für das Review Die Projektmanager des Kunden und des Lieferanten müssen der Ernennung eines Sekretärs für das Review, der der Organisation des Kunden oder des Lieferanten entstammen kann, zustimmen. Der Sekretär muss: a) den Reviewplan aufstellen und ihn dem Projektmanager des Lieferanten vorlegen (wenn der

Sekretär vom Lieferanten gestellt wird); b) Review-Abweichungsmeldungen verfolgen, archivieren und nummerieren; c) die Teilnehmern des Reviews bei ihrer Arbeit umfassend unterstützen.

5.4 Bedingungen für die Durchführung von Reviews

Vor der Verteilung des Reviewplans sollte der Vorsitzende des Review-Ausschusses in Zusammenarbeit mit den Projektmanagern des Kunden und des Lieferanten die vorgelegte Dokumentation wie auch die aufgrund früherer Reviews durchzuführenden Maßnahmen prüfen, um zu ermitteln, ob alle Voraussetzungen für das Review erfüllt sind. Ist dies der Fall, muss der Vorsitzende dem Entscheidungsgremium des Kunden folgende Alternativen zur Entscheidung vorlegen: a) das Review neu zu definieren und neue Ziele festzulegen; b) vor dem Review erforderliche Abhilfemaßnahmen zu ergreifen; c) das Review (ausnahmsweise) zu verschieben.

5.5 Reviewplan Es ist ein Reviewplan mit folgendem Inhalt aufzustellen: a) Ziele des Reviews; b) Zuständigkeiten der Teilnehmer am Review, mit Namen und organisatorischer Zugehörigkeit; c) Aufgabenstellung des Review-Ausschusses und seiner Arbeitsgremien (sofern vorhanden); d) Problemstellung und erforderliche Entscheidungen oder Anweisungen (z. B. Begründung von

Alternativlösungen); e) Verzeichnisse der an die Mitglieder des Review-Ausschusses zu verteilenden Dokumente und aller

sonstigen beim Review verwendeten Dokumente; f) Tagesordnung der Reviewsitzung mit Angabe zur Nummerierung, Verteilung und Behandlung von

Review-Abweichungsmeldungen; g) Zeitpläne für die Durchführung der Reviews mit Datum der Eröffnungssitzung, Beginn und Ende

der Sitzungen, Übergabedatum für Abschlussbericht sowie geplante Sitzungstermine für den Review-Ausschuss;

h) Stand der aufgrund früherer Reviews ergriffenen Maßnahmen; i) zu verwendende Formulare.

19


5.6 Sitzungen/Treffen im Rahmen eines Reviews

5.6.1 Eröffnungssitzung Zweck der Eröffnungssitzung ist: a) Vorlage von Reviewplan und -organisation; b) Vorstellung der Mitglieder des Review-Ausschusses und Entscheidung über die Bildung von

Arbeitsgremien; c) Angabe von Einzelheiten zum zu prüfenden Produkt unter Berücksichtigung der Reviewziele; d) Vorlage der zu prüfenden Dokumentation; e) Bestätigung der Eignung der Dokumentation für das Review; f) formelle Zustimmung zur Durchführung des Reviews.

5.6.2 Treffen von Review-Ausschuss und Lieferant Die Treffen zwischen dem Review-Ausschuss und dem Lieferanten (die üblicherweise beim Lieferanten stattfinden) bilden das Forum für den Austausch von Informationen und für Diskussionen zwischen den Mitgliedern des Review-Ausschusses und dem Projektteam des Lieferanten, bei denen Probleme (anhand von Review-Abweichungsmeldungen) erkannt und Lösungen vorgeschlagen oder weitere Vorgaben gemacht werden. Die Review-Abweichungsmeldungen dürfen vor solchen Treffen als „vorläufig“ bezeichnet werden. Jede/r Sitzung/Tag ist mit einer Zusammenkunft des betreffenden Arbeitsgremiums oder des Review-Ausschusses im kleineren Personenkreis zu beenden, bei der jeder Teilnehmer kurz über den Stand der erkannten Probleme informiert.

5.6.3 Abschlusssitzung des Review-Ausschusses Auf der Abschlusssitzung des Review-Ausschusses: a) muss eine abgestimmte Beurteilung des Standes des geprüften Produkts abgegeben werden; b) müssen Entscheidungen zu Empfehlungen oder zu treffenden Maßnahmen oder Entwürfe dafür

vorgelegt werden, wenn dies auf dem Abschlusstreffen nach Abschnitt 5.6.3 beschlossen wurde; c) müssen die vom Projektteam des Lieferanten bereits gebilligten Maßnahmen verabschiedet werden. Die Ergebnisse der Sitzung sind im Bericht des Review-Ausschusses aufzuführen und können dem Lieferanten und dem Projektteam des Kunden vorgelegt werden.

5.6.4 Sitzung des Entscheidungsgremiums Das Entscheidungsgremium muss unverzüglich nach Vorlage des Berichts des Review-Ausschusses zusammentreten. Der Vorsitzende des Ausschusses muss den Bericht persönlich vorlegen. Das Entscheidungsgremium hat die vom Projektteam des Lieferanten bereits gebilligten Maßnahmen zur Lösung der größeren Probleme zu prüfen und muss die Empfehlungen des Review-Ausschusses analysieren und über alle noch nicht vom Projektteam des Lieferanten gebilligten Maßnahmen entscheiden, die im Einzelnen zur Problemlösung vorgeschlagen werden.

20


5.7 Review-Abweichungsmeldung – Aufzeichnung und Behandlung Review-Abweichungsmeldungen sind zu verwenden, um bei der Auswertung der Dokumentation und beim Review selbst aufgetretene Fragen oder festgestellte Probleme festzuhalten. Ein Beispiel für einen entsprechenden Vordruck zeigt Anhang A.3. Falls der vorgesehene Platz nicht ausreicht, darf der Vordruck um weitere Seiten ergänzt werden. Review-Abweichungsmeldungen sollten nur verwendet werden, wenn es um Fragen von Bedeutung geht und nicht lediglich um die Klärung von Einzelheiten, die besser vom Projektteam außerhalb des Reviews erfolgen kann. In der Review-Abweichungsmeldung muss angeben werden, welche Anforderung durch das erkannte Problem nicht erfüllt wird. Geht es in der Review-Abweichungsmeldung um ein Problem der Qualität, Machbarkeit oder der Sicherheit, sind die Anforderungen anzugeben, deren Einhaltung am meisten gefährdet wird. Bild 2 zeigt das Ablaufdiagramm für die Behandlung von Review-Abweichungsmeldungen. Die Beratung des Review-Ausschusses über die Antworten des Projektteams des Lieferanten auf Review-Abweichungsmeldungen kann zu folgenden Schlussfolgerungen führen (siehe Bild 2). a) Die Review-Abweichungsmeldung nennt ein Problem, zu dem es eine sofortige und zufrieden

stellende Lösung gibt; die Review-Abweichungsmeldung wird damit als erledigt betrachtet. b) Die Review-Abweichungsmeldung nennt ein Problem von geringerer Bedeutung, das vom

Projektteam des Lieferanten durch eine entsprechende Maßnahme als lösbar betrachtet wird. c) Die Review-Abweichungsmeldung nennt ein Problem von geringerer Bedeutung, dessen

unmittelbare Lösung für das Projektteam des Lieferanten als nicht möglich angesehen wird. Eine solche Review-Abweichungsmeldung wird in den Bericht des Review-Ausschusses aufgenommen.

d) Die Review-Abweichungsmeldung nennt ein größeres Problem, das vom Projektteam des

Lieferanten durch entsprechende Maßnahmen als lösbar betrachtet wird. Eine solche Review-Abweichungsmeldung und die vereinbarten Maßnahmen sind in den Bericht des Review-Ausschusses aufzunehmen.

e) Die Review-Abweichungsmeldung nennt ein größeres Problem, zu dem entweder

Meinungsverschiedenheiten mit dem Projektteam des Lieferanten bestehen oder das Folgen hat (finanziell, terminlich, hinsichtlich der Schnittstellen, technisch usw.), die eine besondere Behandlung erfordern und auf höherer Ebene weiter zu erörtern sind. Die Folgen sind dem Entscheidungsgremium mitzuteilen und entsprechende Empfehlungen zu erarbeiten.

21


Nennung des Problems

Entwurf von RIDs

Prüfung durch Lieferantenund Erwiderung

Problem gelöst?(a) Ja

Nein

Fehlermeldung erledigt

Problem größeroder kleiner?

Größer

Kleiner

Maßnahmezur Lösungakzeptiert

Maßnahmezur Lösungakzeptiert

Ja

Ja

NeinNein

(c)

(d)

(b) Durchführung derMaßnahme

Geplante Maßnahme demReviewausschuss vorgelegtund in den Reviewbericht

aufgenommen

Zur Aufnahme in den Bericht des Review-Ausschusses Empfehlungen vorgelegt

und Maßnahmen vorgeschlagen

Regelung durchEntscheidungsgremium

des Kunden

(e)

Review-Abweichungs-meldung erledigt

Review-Ausschuss vorgelegt

Bild 2: Ablaufdiagramm zur Behandlung von Review-Abweichungsmeldungen

22


6 Ergebnisse des Reviews und weiterführende Maßnahmen

6.1 Abschlussbericht des Review-Ausschusses Der vom Review-Ausschuss erstellte Abschlussbericht sollte Folgendes enthalten: a) eine detaillierte Antwort zu jedem Reviewziel und jeder im Reviewplan aufgeworfenen Frage; b) eine Beurteilung der Qualität der zur Genehmigung zugeleiteten Dokumentation (Vollständigkeit,

technischer Inhalt und Übereinstimmung mit den Definitionen der Anforderungen an Dokumente) durch den Review-Ausschuss;

c) eine Zusammenstellung der während des Reviews ermittelten größeren Probleme (mit Hinweis auf

die jeweilige(n) RID-Nummer(n) und ermittelte(n) Lösung(en); d) eine Zusammenstellung der Empfehlungen des Review-Ausschusses für die Punkte, zu denen es

keine Einigkeit oder Lösung gab; e) einen Anhang mit allen RIDs einschließlich der Antworten des Lieferanten; f) eine Angabe, ob das Review seine Ziele insgesamt erreicht hat. Ist dies nicht der Fall, sollte der

Bericht entsprechende Empfehlungen abgeben, wie die Ziele zu erreichen sind.

6.2 Weiterführende Maßnahmen Die Ziele des Reviews sind erreicht, wenn die Empfehlungen befolgt und daraus resultierende Maßnahmen erfolgreich abgeschlossen oder im normalen betrieblichen Ablauf erledigt werden. Um dies sicherzustellen, sind folgende Vorkehrungen zu treffen: a) zur Durchführung der im Review festgelegten Maßnahmen wird aus dem Kreise der Mitglieder des

Projektteams des Kunden eine Arbeitsgruppe gebildet; b) alle Maßnahmen, die sich aus einer Zustimmung durch das Projektteam des Lieferanten oder aus

vom Entscheidungsgremium des Kunden angenommenen Empfehlungen ergeben, müssen in gleicher Weise durchgeführt werden;

c) die für die Durchführung von Maßnahmen verantwortlichen Personen sollten hinreichend

unterrichtet, ihre Zustimmung sollte zuvor eingeholt werden. d) alle durchgeführten Maßnahmen sollten dokumentiert werden.

23


24


Anhang A (informativ) Hilfsmittel zur Durchführung von Reviews

A.1 Allgemeines Diese Norm gilt für Projekte der Europäischen Raumfahrt unterschiedlicher Größenordnung, vom Großprojekt bis zu Verträgen zur technischen Entwicklung. Zur Entwicklung eines Modells, das dieser Vielfalt gerecht wird, wurde auf Erfahrungen mit in Europa durchgeführten Projektreviews zurückgegriffen. Im Folgenden wird eine Beschreibung von Hilfsmitteln zur Durchführung von Reviews in allgemeiner Form gegeben, die an die jeweiligen Anforderungen eines Projekts anzupassen sind.

A.2 Template für Reviewplan Ein typischer Reviewplan enthält die folgenden Angaben: 1 Bezeichnung von Review und Projekt 1.1 Benennung 1.2 Überprüftes System oder Produkt 2 Bezugsdokumente

Verzeichnis der für das Review erforderlichen Projektdokumentation 3 Ziele des Reviews 3.1 Zweck 3.2 Erwartete Ergebnisse 4 Organisation des Reviews 4.1 Reviewprozess 4.2 Teilnehmer 4.3 Sekretariatsführung 4.4 Review-Ausschuss 5 Zeitlicher Ablauf

Beschreibung des Arbeitsablaufs (Lieferung des Datenpakets, Sitzungen des Review-Ausschusses, weitere Termine)

6 Dokumentation 6.1 Für das Review zu lieferndes und zu prüfendes Dokument 6.2 Verfügbares Bezugsdokument 6.3 Zusammenfassende Beschreibung des Review-Gegenstands 7 Tagesordnung für 1. Sitzung 7.1 Vorstellung des Review-Ausschusses, Bericht 7.2 Vorstellung des Projekts (Inhalt, technische und organisatorische Anforderungen) 7.3 Vorstellung des Produkts (Definition, kritische Punkte, Funktion, Betrieb) 7.4 Empfehlungen des vorhergehenden Reviews (falls zutreffend) 8 Teilnehmer 8.1 Entscheidungsgremium 8.2 Vorsitzender, Sekretär und Mitglieder des Review-Ausschusses 8.3 Mitglieder des Projektteams

25


9 Logistik 9.1 Adresse und Kartenmaterial, Beförderungsmöglichkeiten (z. B. zum nächstgelegenen Flughafen) 9.2 Empfohlene Unterkünfte 9.3 Kontaktadressen 10 Anhänge 10.1 Vordruck für Review-Abweichungsmeldungen.

A.3 Begleitdokumentation Für ein Review vorgelegte Dokumente dienen der vertiefenden Information zum zu überprüfenden Design und - bei größeren Reviews und bei vorliegender Zustimmung - der Anpassung der entsprechenden festgelegten Grundlagen. Die Dokumente für Qualifikations- und Abnahmereviews werden auch zum Nachweis verwendet, dass die jeweilige Verifikation durchgeführt wurde. Für jedes Projekt ist eine detaillierte Aufstellung aller lieferbaren Dokumente bei den wichtigen Reviews in der Liste der vertraglich geforderten Dokumente (DRL) definiert, die gewöhnlich Vertragsbestandteil ist. Zusätzliche Dokumente sind nicht erforderlich mit Ausnahme von zur Präsentation des Reviews zugehörigen Handouts. Im Folgenden werden Beispiele für Dokumente gegeben, die für bestimmte Reviews typisch sind.

A.3.1 Missionsdefinitionsreview (MDR) Missionsanforderungsdokument (MRD).

A.3.2 Vorläufiges Anforderungs-Review (PRR) Systemanforderungsdokument (SRD).

A.3.3 Systemanforderungsreview (SRR) Systemanforderungsspezifikation (ergänzt das Systemanforderungsdokument, enthält Anforderungen zum Design und zur Software, legt Verifikationsmethoden fest und macht Angaben zum Lebenszyklus) (Elemente der integrierten Logistik).

A.3.4 Vorläufiges Designreview (PDR) a) Spezifikationen zur Entwicklung von CIs und SWCIs (alle Ebenen)

b) Schnittstellendokumentation (System-/Segmentebene)

c) Pläne für den Einsatz neuer/kritischer Technologie

d) Bericht zur Designanalyse

e) Langzeitpläne zur Materialbeschaffung

f) Dokument mit Testanforderungen

g) Managementpläne

h) Dokument zur Softwarearchitektur (für SWCIs)

i) Sicherheitspläne (vorläufig).

26


A.3.5 Kritisches Designreview CDR) a) Vorläufige Zeichnungen und zugehörige Stücklisten

b) Schnittstellendokumentation (CI- und SWCI-Ebene)

c) Verkäuferangaben (nur für gekaufte handelsübliche Produkte)

d) Designanalyse- und Entwicklungsprüfberichte

e) Pläne und Verfahren zur Integration von Teilsystemen/Systembauteilen/Haupteinheiten

f) Qualifikations- und Testpläne und -verfahren

g) Beschreibung von speziellen Werkzeugen und Hilfsmitteln

h) Dokumente mit Anforderungen an spezielle Einrichtungen/Geräte

i) Unterlagen zur Softwareentwicklung

j) Pläne zur Softwareintegration und zu Tests

k) Verzeichnis der Konfigurationseinheiten (CIDL)

l) Sicherheitspläne.

A.3.6 Qualifikationsreview (QR) a) Spezifikationen zur Produktentwicklung und mit Anforderungen an Software

b) Zeichnungen, Diagramme und Ablaufpläne, sofern erforderlich

c) Schnittstellenspezifikationen

d) Testpläne und -verfahren

e) Test- und Analyseberichte

f) Berichte zur Bezugsquellenqualifikation für handelsübliche Einheiten

g) Verzeichnis der Konfigurationseinheiten

h) Sicherheitsverfahren (vorläufig).

A.3.7 Abnahmereview (AR) a) Vollständiger Satz von Produktzeichnungen und zugehörigen Stücklisten

b) Schnittstellenzeichnungen

c) Test- und Analyseberichte

d) Berichte über gesondert hergestellte Bauteile

e) Liste kritischer Bauteile

f) Dokumente mit Anforderungen zur Kalibrierung

g) Dokumentation für Spezialwerkzeuge und Testeinrichtungen

h) Übersicht über die Lagerfähigkeit von Einheiten

i) Anfragen zur Genehmigung nichtgenormter Teile

j) Vorläufige Dokumentation zu Betrieb und Instandhaltung

k) Verzeichnis der Konfigurationseinheiten

l) Sicherheitsverfahren.

27


A.3.8 Flugbereitschaftsreview (FRR) a) Aufzeichnungen zum Status der Flugsegmentintegration und -qualifikation

b) Aufzeichnungen zum Status von Bodensegmentbetrieb und -qualifikation

c) Berichte über den Zustand kritischer Einheiten

d) Sicherheitsberichte

e) Plan und Verfahren für die Startvorbereitung.

A.3.9 Betriebsbereitschaftsreview (ORR) Pläne und Verfahren für den Betrieb, Berichte zur integrierten Logistik und zur Integration und Prüfung von Bodenhilfsausrüstungen

A.3.10 Startbereitschaftsreview (LRR) Aufzeichnungen zur Integration und Startvorbereitung

A.3.11 Flugqualifikationsreview (FQR) a) Berichte über Tests zur Inbetriebnahme von Fluggeräten

b) Berichte über Tests zur Inbetriebnahme von Bodengeräten

c) Erfahrungsberichte.

A.3.12 Review am Ende der Lebensdauer (EOLR) a) Pläne und Verfahren zur Endverwendung

b) Zeitpläne für Verschrottung

c) Anforderungen an Einrichtungen zur Verschrottung

d) Verfahren zur Behandlung von gefährlichen Stoffen/kontaminierten Teilen.

A.4 Review-Abweichungsmeldungen (siehe Vordruck auf folgender Seite)

28


Firma

Review-Abweichungsmeldung (RID)

1. Lfd. Nr.

Projekt

3. Kurzbezeichnung des Dokuments 2. System/Teilsystem

3b) Titel des Dokuments

4. Band, Abschnitt, Absatz, Seite

5. Bezeichnung der

6. Verfasser Datum

7. Abweichung/Betroffene Anforderung

8. Vorgeschlagene Lösung

9. Antwort des Lieferanten Vorgeschlagene Lösungen vertragsgemäß

nicht vertragsgemäß

Unterschrift des Lieferanten

10. Verfügung des Review-Ausschusses größeres Problem geringes Problem und Empfehlung

11. Zurückgezogen 12. Erledigt 13. Offen, ver-tragsgemäß

14. Offen, nicht vertragsgemäß

Unterschrift des Vorsitzenden des Review-Ausschusses

15. Verfügung des Entscheidungsgremiums

Genehmigt als vertragsgemäß

Unterschrift des Lieferanten

Termin für durchzuführende Maßnahmen

Genehmigt, obwohl nicht vertragsgemäß

Zurückgezogen Erledigt

Abschlussdatum

16. Referenz zum Erledigungsvermerk Unterschrift des Kunden

29


Hinweise zum Ausfüllen des Vordrucks Der Vordruck ist in englischer Sprache einzureichen. 7 Begründung für Review-Abweichungsmeldung mit detaillierter Angabe nachteiliger Folgen für

gegebenen Zustand. 8 Beschreibung der vorgeschlagenen Lösung in eindeutiger und möglichst detaillierter Form.

Begründung, falls kein Lösungsvorschlag gemacht wird. 9 Wird die vorgeschlagene Lösung nicht akzeptiert, ist ein Alternativvorschlag zu machen. 10 Der Review-Ausschuss muss das in der Review-Abweichungsmeldung behandelte Problem als

größer oder geringer klassifizieren und eine Empfehlung geben und ggf. die Meldung dem Entscheidungsgremium zuleiten.

11 Wenn der Verfasser der Review-Abweichungsmeldung die gegebene Antwort akzeptiert, wird die

Meldung zurückgezogen. 12 Wenn die Entscheidung des Review-Ausschusses zur Review-Abweichungsmeldung als angemessen

angesehen wird, gilt die Fehler-Abweichungsmeldung als erledigt. 13 Die Umsetzung der Empfehlung liegt innerhalb der vertraglichen Grenzen. 14 Die Umsetzung der Empfehlung gilt als zusätzliche Anforderung oder Modifikation von Design-

oder Testverfahren und damit außerhalb des Vertrages liegend. 15 RIDs von großer Wichtigkeit werden vom Entscheidungsgremium bearbeitet. Erledigung der

Review-Abweichungsmeldung wird durch Unterschrift sowohl des Lieferanten wie des Kunden dokumentiert.

16 Referenz zum Erledigungsvermerk und Datum sind nach Erledigung der Review-

Abweichungsmeldung einzutragen.

30


Verbesserungsvorschlag für ECSS-Dokumente

1. Dokumentnummer

ECSS–M–30–01A

2. Datum des Dokuments

1. September 1999

3. Titel des Dokuments

Vorbereitung und Durchführung von Reviews

4. Empfohlene Verbesserung (Abschnitte/Unterabschnitte angeben und geänderten Text und/oder geänderte graphische Darstellung aufnehmen; gegebenenfalls Anlagen beifügen)

5. Begründung

6. Antragsteller

Name: Organisation:

Adresse: Telefon:

Fax:

E-Mail:

7. Datum:

8. Zu senden an ECSS-Sekretariat

Name:

W. Kriedte

ESA-TOS/QR

Adresse:

ESTEC, PO Box 299

2200 AG Noordwijk

Niederlande

Tel.: + 31-71-565-3952

Fax: + 31-71-565-6839

E-Mail: Werner.Kriedte@ esa.int

Anmerkung: Der Antragsteller sollte Angaben zu den Punkten 4, 5, 6 und 7 machen.

Die englische Fassung dieses Formulars ist erhältlich als Word- und Wordperfect-Vordruck im Internet unter http://www.ecss.nl/

31

Raumfahrt- Projektmanagement - DLR · ECSS-M-30-01A 1. September 1999 Vorwort Diese Norm gehört zu...

Documents

Transcript of Raumfahrt- Projektmanagement - DLR · ECSS-M-30-01A 1. September 1999 Vorwort Diese Norm gehört zu...