Dokumentenfreigabe – Vier-Augen-Prinzip notwendig?

Dienstag 19. März 2019

Eine effiziente Dokumentenfreigabe stellt eine der wichtigsten Voraussetzungen für ein wirkungsvolles Qualitätsmanagementsystem dar.

Lesen Sie in diesem Artikel, wie Sie mit einer effizienten Dokumentenfreigabe die Produktivität Ihres Teams verbessern und die Qualität Ihrer Produkte und Prozesse erhöhen können.

Dieser Artikel beschreibt, wie Sie Dokumente auch in der Entwicklung effizient prüfen und freigeben. Sie erfahren zudem, ob ein Vier-Augen-Prinzip notwendig ist.

1. Was man unter einer Dokumentenfreigabe versteht

Dokumente definiert die ISO 9000:2015 als „Information einschließlich des Trägermediums“. Sie nennt als Beispiele Aufzeichnungen und Vorgabedokumente z.B. Spezifikationen und Verfahrensanweisungen.

Dokumente unterliegen einem Dokumentenlebenszyklus (s. Abb. 1)

Dokumentenlenkung: Die Dokumentenprüfung und Dokumentenfreigabe sind Teile des Dokumenten-Lebenszyklus
Abb. 1: Dokumentenlenkung: Die Dokumentenprüfung und Dokumentenfreigabe sind Teile des Dokumenten-Lebenszyklus

Die Dokumentenprüfung soll sicherstellen, dass das Dokument konform mit zuvor gestellten Anforderungen ist. Diese Anforderungen stammen beispielsweise aus Normen oder eigenen Vorgaben wie Verfahrens- oder Arbeitsanweisungen.

Hingegen stellt die Dokumentenfreigabe eine Erlaubnis dar, dass man zur nächsten Stufe übergeht. Genauso definiert es auch die ISO 9000:2015:

Definition: Freigabe
„Erlaubnis, zur nächsten Stufe eines Prozesses oder zum nächsten Prozess überzugehen“
Quelle: ISO 9000:2015

Die Freigabe einer Software Requirements Specification kann beispielsweise die Erlaubnis darstellen, mit der Erstellung der Software-Architektur fortzufahren.

Die Norm merkt an, dass der englische Begriff („release“) im Zusammenhang mit Software und Dokumenten häufig mit der Version dieser Software bzw. dieses Dokuments verwendet wird. Auch die IEC 62304 nutzt den Begriff der Software-Freigabe („software release“) entsprechend.

Weiterführende Informationen

Lesen Sie hier mehr zum Thema Dokumentenlenkung.

2. Weshalb effiziente Dokumentenfreigaben wichtig sind

Unnötiges Warten

Mit einer schwergewichtigen Dokumentenfreigabe können Sie Ihr ganzes Team stilllegen: Es wartet auf die Prüfung und Freigabe durch überlastete Experten und Vorgesetzte. Das Projekt steht.

Fehlende „Quality Gates“

Schlimmer noch: Das Team wartet nicht und arbeitet (z.B. entwickelt) ohne den Schritt einer Prüfung und Freigabe einfach weiter. Die Dokumentation hat ihre Funktion als Element der Qualitätssicherung verloren.

QM-Bürokratie

Das Erstellen der Dokumente wird damit zu Recht als eine ebenso aufwändige wie sinnfreie Tätigkeit empfunden; als Auswüchse einer QM-Bürokratie.

Regulatorische Risiken

Wenn Hersteller die Dokumente nicht oder nicht zum richtigen Zeitpunkt prüfen oder freigegeben, verstoßen sie gegen die regulatorischen Anforderungen. Die Gefahr, dass dies zum Audit oder der Zulassung zum Problem wird, ist hoch.

Die Folgen sind aufwändige und kostspielige Nacharbeiten, verzögerte Zulassungen oder gar juristischer Ärger.

3. Regulatorische Anforderungen an die Dokumentenfreigabe

a) ISO 13485:2016

Die ISO 13485:2016 erwähnt den Begriff der Freigabe nicht bei der Dokumentenlenkung. Sie fordert allerdings im Kapitel 4.2.4 zur Dokumentenlenkung, dass die Dokumente sowohl bewertet als auch genehmigt werden müssen. Diese Genehmigung („approve“) entspricht der bzw. führt zur Freigabe.

Im Kapitel 7.3.4 fordert die Norm explizit die Genehmigung der Entwicklungsergebnisse vor der Freigabe des Produkts und die Bewertung der Entwicklungsergebnisse in Kapitel 7.3.5.

Mit Bezug zum Vier-Augen-Prinzip ist das Kapitel 5.5.1 relevant:

„Die oberste Leitung muss die gegenseitigen Beziehungen aller Personen dokumentieren, die Arbeiten, die sich auf die Qualität auswirken, leiten, durchführen und bewerten, und muss die erforderliche Unabhängigkeit und Befugnis zur Durchführung dieser Aufgaben sicherstellen.“

ISO 13485:2016. Kapitel 5.5.1

Damit ist ausgeschlossen, dass sich eine Person selbst überprüft.

b) IEC 62304

Die IEC 62304 verwendet den Begriff der Freigabe nicht mit Bezug auf die Dokumente, sondern mit Bezug zur Software. Die Norm verlangt aber explizit, dass die Hersteller im Entwicklungsplan festlegen:

„Für jedes identifizierte Dokument […] müssen […] referenziert werden […] Verfahren und Verantwortlichkeiten für Entwicklung, Überprüfung, Genehmigung und Änderung.“

DIN EN IEC 62304:2016, Kapitel 5.1.8

Die Genehmigung entspricht der Freigabe. Auf welche Kriterien hin die Dokumente zu prüfen (nicht freigeben) sind, beschreibt die IEC 62304 in den folgenden Kapiteln:

c) EU GMP

Die Leitlinien der EU zur „Good Manufacturing Practice“ (GMP) wenden sich zwar an die Hersteller von Arzneimitteln und nicht an die von Medizinprodukten. Dennoch stellen diese den Stand der Technik dar.

Im Kapitel 4 dieser Leitlinien fordert die EU beispielsweise:

  • Kapitel 4.3 „Erzeugung und Kontrolle der Dokumentation“: „Unterlagen, die Anweisungen enthalten, sollten von geeigneten, befugten Personen genehmigt, unterzeichnet und datiert werden.“
  • Kapitel 2.5 „Der Leiter der Herstellung“ und Kapitel 2.6 „Der Leiter der Qualitätskontrolle“ konkretisieren die Verantwortlichkeit des Schlüsselpersonals: „Genehmigung von Anweisungen … und anderen Verfahren [zur Qualitätskontrolle].“

d) FDA

Die FDA dokumentiert Ihre Anforderungen an die Dokumentenlenkung im 21 CFR part 820.40:

„Document approval and distribution. Each manufacturer shall designate an individual(s) to review for adequacy and approve prior to issuance all documents established to meet the requirements of this part. The approval, including the date and signature of the individual(s) approving the document, shall be documented.”

FDA: 21 CFR part 820.40

Im 21 CFR part 211.194 fordert die Behörde:

„(8) The initials or signature of a second person showing that the original records have been reviewed for accuracy, completeness, and compliance with established standards.“

FDA; 21 CFR part 211.194

Das ist die Forderung nach einem Vier-Augen-Prinzip. Diese wendet sich streng genommen aber nicht an Medizinproduktehersteller. Für diese ist allerdings 21 CR part 820.20(1) relevant:

„Responsibility and authority. Each manufacturer shall establish the appropriate responsibility, authority, and interrelation of all personnel who manage, perform, and assess work affecting quality, and provide the independence and authority necessary to perform these tasks.“

FDA: 21 CR part 820.20(1)

4. Gibt es die Forderung nach einem 4-Augen-Prinzip?

Auch wenn keine der regulatorischen Anforderungen den Begriff des 4-Augen-Prinzips verwendet, so ist doch klar, dass zumindest zwei Personen (vier Augen) notwendig sind, um ein Dokument zu schreiben, zu prüfen und freizugeben.

Es ist aber weder gefordert, dass mehrere Personen das Dokument prüfen, noch verbieten die Regularien, dass die Dokumentenprüfung und Dokumentenfreigabe von einer Person durchgeführt werden.

Wenn die Freigabe jedoch zum Ziel hat, die Korrektheit, Existenz und Vollständigkeit der Prüfung zu bewerten, dann kann man die geforderte Unabhängigkeit von Prüfer und „Freigebender“ nicht unterstellen, wenn das die gleiche Person ist.

Unabhängigkeit der zweiten Person

Häufig führt der Grad der Unabhängigkeit der zweiten Person zu Diskussionen. Einen Hinweis dazu gibt das FDA Guidance Document:

„In a small company, complete independence is very difficult to obtain. Within the context of formal design reviews, the practical solution is simply to ensure a fresh perspective, based on the principle that those who are too close to the design may overlook design errors. Thus, reviewers will often be from the same organization as the developers, but they should not have been significantly involved in the activities under review.“

Ein Leser (siehe Kommentare) schlussfolgerte:

Somit darf ein Software Entwickler, der an der gleichen Software arbeitet durchaus ein Review durchführen, er sollte aber keinen „signifikanten“ Anteil am Reviewobjekt geleistet haben. Wobei signifikant wieder ein dehnbarer Begriff ist.

5. Wie Sie herausfinden, ob Ihre Dokumentenfreigaben effizient sind

Wenn Sie herausfinden wollen, ob Sie die Effizienz Ihrer Prozesse durch schwergewichtige Freigaben behindern, dann prüfen Sie folgende Aspekte:

  • Verlangen Sie möglichst viele Unterschriften? Je mehr, umso „besser“.
  • Haben Sie darauf geachtet, dass alle Top-Level Manager und die Geschäftsführer unterschreiben müssen?
  • Haben Sie sichergestellt, dass diese Personen schlecht verfügbar sind, idealerweise selten vor Ort sind? Fehlende Stellvertreterregelungen wären ein weiterer „Tipp“.
  • Machen Sie die Freigaben auf Papier im Umlaufverfahren? Ideal wären mehrere Standorte.
  • Definieren Sie eine erneute Freigabe als Nicht-Erreichen eines bereits erreichten Meilensteins?
  • Lassen Sie das QM- oder Regulatory-Affairs über technische Inhalte entscheiden?
  • Nutzen Sie Werkzeuge zur Dokumentenverwaltung, die möglichst unbeliebt sind, beispielsweise weil sie niemand bedienen kann, weil sie regelmäßig nicht verfügbar sind und weil sie den Ausdruck und die manuelle Unterschrift nicht ersparen?

Klingt das zynisch? Wie viele dieser Punkte treffen bei Ihnen zu?

Das ist die Realität, die das Johner Institut häufig beobachtet.

6. Wie Sie Ihre Dokumentenfreigabe effizient gestalten

Die Gestaltung der Dokumentenfreigaben hängt ab von der Größe des Teams, dessen Verteilung, der Organisation der Firma, der Art der Produkte usw. Die folgenden Best Practices helfen aber unabhängig von diesen Faktoren.

a) Die richtigen Personen beteiligen

Dokumentenfreigabe

Mit der Freigabe wird die Erlaubnis erteilt, den nächsten Prozessschritt zu beginnen. Diese Freigabe kann eine Person bzw. eine Rolle erteilen beispielsweise der „Process Owner“ (z.B. Entwicklungsleiter), ein Projektleiter oder ein mit dem Prozess bzw. dem Projekt vertrauter Regulatory Affairs oder Qualitätsmanager.

Sie benötigen nur eine Person. Ein Vier-Augen-Prinzip ist weder vorgeschrieben noch sinnvoll. Wenn es nur eine Rolle gibt, ist diese verantwortlich. Es besteht keine Gefahr, dass sich jeder auf den anderen verlässt.

Dokumentenprüfung

Anders sieht das bei der vorausgegangenen Dokumentenprüfung aus. Bei solchen Reviews benötigen Sie mehrere Personen.

Doch auch hier sollten Sie die Anzahl der Personen so weit wie möglich reduzieren. Daran sollten bei Entwicklungsprojekten i.d.R. nur teilnehmen:

  • Der Autor bzw. die für die jeweilige Aktivität/Phase verantwortliche Person. Bei einer Software-Architektur wäre das der Software-Architekt.
  • Der Auftraggeber dieser Phase bzw. dieses Dokuments. Bei einer Software-Architektur ist das der- oder diejenige, der/die die Systemspezifikation geschrieben hat, beispielsweise ein Produktmanager.
  • Der Auftragnehmer dieser Phase bzw. dieses Dokuments. Um bei unserem Beispiel der Software-Architektur zu bleiben, wären das die Entwickler, die diese Architektur umsetzen müssen.
  • Die für die Tests verantwortliche Person, die prüfen kann, ob das Geschriebene auch testbar ist. Das wäre bei einer Software-Architektur der Integrationstester, falls es den gibt.

Sonderfall Qualitätsmanagement und Regulatory Affairs

Eine Sonderrolle kommt den Regulatory Affairs und Qualitätsmanagern zu: In die Freigabe von Produktanforderungen und Spezifikationen müssen diese ebenso wenig involviert werden wie die Geschäftsführung.

Wenn die Dokumente hingegen einen Prozessaspekt haben, sollten Sie die Qualitätsmanager und ggf. Regulatory Affairs Manager an der Prüfung beteiligen. Das betrifft insbesondere:

  1. Pläne: Entwicklungsplan, Software-Entwicklungsplan, Risikomanagementplan etc.
  2. Prozessbezogene Freigaben z.B. die Software-Freigabe gemäß IEC 62304 Kapitel 5.8
  3. Verfahrens- und Arbeitsanweisungen

Tester als Teil der Qualitätssicherung sind häufig dem Qualitätsmanagement organisatorisch zugeordnet. Dann ist das Qualitätsmanagement gemäß den obigen Tipps indirekt beteiligt.

Für das Qualitätsmanagement gibt es ein weiteres Instrument, um die „Process Compliance“ zu prüfen: Das Design Review.

Weiterführende Informationen

Lesen Sie hier mehr zum Thema Design Review.

Sonderfall Risikomanagement

Die Risikomanager können, aber müssen nicht eingebunden werden, das hängt in der Tat vom Projekt bzw. Produkt ab.

Fazit

An einem Review sollten nicht mehr als vier oder fünf Personen teilnehmen. Also ein etwa Acht-Augen-Prinzip :-).

Sie können in Ihrer SOP die zu beteiligenden Personen auch davon abhängig machen, ob das Dokument initial erstellt oder überarbeitet wurde.

Aus dem Review fliegt jede Rolle raus, die keinen Beitrag leisten kann, aber die Terminfindung erschwert.

b) Werkzeuge und Hilfsmittel nutzen

Erniedrigen Sie die Hürden für die Dokumentenprüfung und Dokumentenfreigabe durch einfache Werkzeuge.

Checklisten und Werkzeuge

Nutzen Sie Checklisten, die maximal ein beidseitig bedrucktes Blatt umfasst. Nutzen Sie entweder ein ALM-Werkzeug (z.B. MedPack oder JIRA) oder Papier.

Im letzteren Fall sollten die Checklisten ausgedruckt in einem Hängeordner oder einer Schublade bei jedem am Platz liegen. Dann bedarf es nur eines Handgriffs, um mit dem Review bzw. der Dokumentenfreigabe zu beginnen.

Nutzen Sie unseren Auditleitfaden, die Checkliste, die das Johner Institut für benannte Stellen entwickelt hat.

Insbesondere bei verteilten Teams sollten Sie auf webbasierte ALM-Werkzeuge zurückgreifen.

Binär entscheidbare Prüfkriterien

Gleich ob auf Papier oder im Werkzeug: Nehmen Sie nur ganz konkrete und überprüfbare Punkte mit in die Checklisten mit auf. Ein Punkt „Ist das Dokument vollständig?“ ist ziemlich wertlos.

Eine Frage „Gibt es am Ende des Dokuments eine zweispaltige Tabelle, in deren linker Spalte alle IDs der Systemanforderungen aufgeführt und in deren rechte Spalte ein Stichwort oder einen Halbsatz zur Umsetzung in der Architektur steht?“ lässt sich hingegen genau prüfen.

Kompakte Dokumente

Vermeiden Sie Monsterdokumente. Zerlegen Sie die Dokumente! Eine Systemarchitektur muss die Systemkomponenten (z.B. programmierbare elektronische Subsysteme PESS) und deren Zusammenspiel beschreiben. Die Anforderungen an die PESS hingegen lassen sich pro PESS formulieren. Analog gilt das für die Software-Architektur.

Je kleiner ein Dokument, umso schneller und besser ist es prüfbar. Dokumente, an denen mehrere Rollen mitschreiben, sollten Sie möglichst vermeiden.

Vermeiden Sie auch lange „Document Headers“. Alle Querschnittsaspekte wie Glossare gehören „rausfaktorisiert“. Das erschwert die Prüfung und Freigabe der Dokumente.

Bilder und Modelle

Vermeiden Sie langen Fließtext in den zu prüfenden und freizugebenden Dokumenten. Bilder, Tabellen, Modelle sind kompakter und lassen sich schneller und einfacher prüfen.

c) Prüfung und Freigabe sowie Produkt- und Prozessaspekte trennen

Trennen Sie Prüfungen und Freigaben. Bei der Prüfung geht es um die inhaltliche Vollständigkeit, Korrektheit und Verständlichkeit.

Bei der Freigabe geht es meist um die Projektsteuerung und um die „Process Compliance“.

Beide Aktivitäten bedürfen anderer Prüfkriterien. Für die beiden Aktivitäten sind unterschiedliche Rollen zuständig (s.o.).

e) Das richtige Setup wählen

Die Dokumentenprüfung und die Dokumentenfreigabe sind Aktivtäten, die einer hohen Konzentration bedürfen. Achten Sie daher auf das Folgende:

  • Alleine statt (nur) im Team
    Prüfen Sie zuerst alleine und nicht in großen Team-Meetings. Bei den Meetings tragen Sie die Ergebnisse der einzelnen Prüfer zusammen, gleichen diese ab und kommen zu einem abschließenden Urteil.
  • Regelmäßige kurze Prüfungen
    Bevorzugen Sie regelmäßige, zeitnahe und kurze Reviews (< 30 Minuten). Nach 45 Minuten intensiver Prüfung sind die meisten Hirne ermüdet.
  • Ungestörtes Arbeiten
    Schaffen Sie Orte, an denen man in Ruhe bzw. sich im Team zusammensetzen kann. Störungen durch Telefon oder E-Mail müssen tabu sein.

f) Wertschätzende Kultur schaffen

Als Geschäftsführer und Projektleiter drücken Sie Wertschätzung für diese Review-Tätigkeiten aus. Wenn Sie glauben, nur ein programmierender Programmierer sei ein guter Entwickler, sind Sie falsch auf Ihrem Posten.

Bei Google werden übrigens Reviews genauso hoch bewertet wie das Schreiben von Dokumenten und das Programmieren.

7. Fazit

Ineffiziente Prozesse durch ineffiziente Prüfungen und Freigaben

Mit einer schwergewichtigen Dokumentenfreigabe legen Sie Ihre ganze Firma still. Ineffiziente Prozesse haben meist etwas damit zu tun, dass die Prüfung und Freigabe der Dokumente nicht klug geregelt wurden.

Auf eine (rechtzeitige) Freigabe von Dokumenten zu verzichten, ist nicht klug:

  1. Man hat immer noch die Arbeit mit den Dokumenten.
  2. Man verzichtet auf den Nutzen, den eine präzise Prüfung und Freigabe im Sinne eines „Quality Gates“ hat.
  3. Man setzt sich hohen regulatorischen Risiken aus.

Vier-Augen-Prinzip

Verwechseln Sie Dokumentenprüfung nicht mit der Dokumentenfreigabe. An einer Prüfung sollten Sie mehrere Personen beteiligen. Hier ist das Vier-Augen-Prinzip ggf. hilfreich aber nicht zwingend vorgeschrieben. Bei einer Dokumentenfreigabe hingegen nicht.

Wenn die Freigabe die Überprüfung der Bewertung zum Ziel hat, dürfen der Freigebende und der Bewertende nicht die gleiche Person sein. Dann ist ein Vier-Augen-Prinzip de-facto vorgeschrieben, auch wenn die Regularien diesen Begriff nicht verwenden.

Der Ersteller und der Prüfer eines Dokuments dürfen nie die gleiche Person sein. Hier ist ein Vier-Augen-Prinzip unumgänglich.

Unterstützung

Haben Sie das Gefühl, dass Ihre Prozesse und Ihre Dokumentenprüfungen und -freigaben nicht effizient genug sind? Scheut Ihr Team diese Aktivitäten und schiebt sie deshalb vor sich her? Dann melden Sie sich bei uns. Wir helfen gerne, Ihre Prozesse schlanker zu gestalten und damit Ihre Produkte sicherer zu entwickeln und schneller in den Markt zu bringen.

Danke an Norbert Pauli und Markus Gehart für den wertvollen Input!
War dieser Artikel hilfreich? Bitte berwerten Sie:
1 Stern2 Sterne3 Sterne4 Sterne5 Sterne

Autor des Beitrags " Dokumentenfreigabe – Vier-Augen-Prinzip notwendig?

Johner Institut GmbH

Logo Johner Institut klein

Bewertung 0 von 5 bei 0 Bewertungen


Kategorien: QM-Systeme & ISO 13485
Tags:

5 Kommentare über “Dokumentenfreigabe – Vier-Augen-Prinzip notwendig?”

  1. Norbert Pauli schrieb:

    Guten Tag Herr Johner,
    ich habe an der Erstellung der IEC 62304 mitgewirkt, wir kennen uns aus entsprechenden Meetings bei der DKE in Frankfurt.
    Von Ihrem Beitrag zur Dokumentenfreigabe habe ich erfahren, weil ein Kollege ihn firmenintern zitiert hat, genauer gesagt den Abschnitt b).
    Da stieß mir dann doch Ihre Anmerkung zu der Einbindung von QM und RA auf Unverständnis. Ich denke, das liegt aber wahrscheinlich daran, dass Sie nur einen bestimmten Dokumententyp im Auge hatten, in etwa Softwarespezifikationen und ihre schrittweise Umsetzung in Code.
    Aus der Praxis heraus kann ich aber sagen, dass es für andere Dokumententypen und je nach Organisation des Herstellers es durchaus Dokumente im QM-System und gemäß IEC 62304 gibt, die inhaltlich vom QM/RA bewertet werden können, z.B. der Development Plan.
    Ich denke, es wäre sinnvoll und würde Missverständnisse vermeiden, wenn dies in Ihren Ausführungen Erwähnung finden könnte.
    Einen ähnlichen Aspekt sehe ich bei den konkret vorgeschlagen Teilnehmern für ein Review. Ihren Ansatz mit den abstrakten Rollen unterstütze ich voll und ganz. QM ist aber keine abstrakte Rolle mehr, sondern spiegelt die (jeweils unterschiedliche) Organisation eines Herstellers wider. Es könnte da z.B. sein, dass ein Tester dem QM organisatorisch zugeordnet ist.
    Bei Freigaben hat sich bei uns bewährt, dass für jede freigebende Rolle, z.B. im Rahmen der (elektronischen) Unterschrift, angegeben ist, welchen Aspekt des Dokuments die Freigabe durch diese spezifische Rolle abdeckt. Das soll auch, wie in der Praxis häufig gesehen, eine „kollektive“ Freigabe verhindern, wo jeder sich auf den anderen verlässt.

    Mit freundlichem Gruß
    Norbert Pauli

  2. Prof. Dr. Christian Johner schrieb:

    Lieber Herr Pauli,

    ich danke Ihnen herzlich für Ihren wichtigen Input! Ich stimme Ihnen absolut zu, dass einige Stellen missverständlich sein können, insbesondere wenn es um Rollen und Organisationseinheiten geht. Ich werde Ihren wertvollen Kommentar zum Anlass nehmen, ihn gleich am Wochenende zu überarbeiten. Ich würde Sie dann gleich mit einbeziehen. Ich fände es auch wertvoll, wenn man ggf. unterschiedliche Sichtweisen thematisiert. Insofern würde ich mich über Ihre weitere Unterstützung sehr freuen.

    Mit nochmaligem Dank, mit herzlichen Grüßen und bis sehr bald, Christian Johner

  3. Beat Keller schrieb:

    Guten Tag Herr Johner,
    was für uns und unsere Kunden immer wieder ein Diskussionspunkt ist, ist die Unabhängigkeit des zweiten Augenpaares. Muss der Reviewer komplett unabhängig sein? Sogar aus einem anderen Projektteam? Darf er an der gleichen Software gearbeitet haben? Hier hilft mir jeweils die FDA Design Control Guidance (https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm070642.pdf) wo auf Seite 26 steht:
    „In a small company, complete independence is very difficult to obtain. Within the context of formal design reviews, the practical solution is simply to ensure a fresh perspective, based on the principle that those who are too close to the design may overlook design errors. Thus, reviewers will often be from the same organization as the developers, but they should not have been significantly involved in the activities under review.“
    Somit darf ein Software Entwickler der an der gleichen Software arbeitet durchaus ein Review durchführen, er sollte aber keinen „signifikaten“ Anteil am Reviewobjekt geleistet haben. Wobei signifikant wieder ein dehnbarer Begriff ist.
    Vielleicht hilft dieser Guidance-Absatz einem anderen Leser ja auch.
    Grüsse
    Beat Keller

  4. Prof. Dr. Christian Johner schrieb:

    Lieber Herr Keller,

    das ist ein großartiger Hinweis, den ich so gleich ergänze!

    Vielen Dank!!

    Beste Grüße, Christian Johner

  5. Christian Baudis schrieb:

    Guten Morgen Herr Johner,

    ich weiß, dass in der Industrie gerne Begriffe verwässert, gedehnt und vermischt werden, bitte aber doch bestimmte Dinge zu unterscheiden.
    4-Augen-Prinzip/2-men-rule und die von der Norm geforderte unabhängige Freigabe sind nicht identisch.
    4-Augen bedeutet eigentlich 2 Paar „Prüfaugen“, idealerweise beauftragt mit der gleichen Prüfung (oder zumindest gleichen Kriterien, wenn verkürzt). Der Autor bzw. dessen Augen zählen grundsätzlich nie dazu, er ist nicht objektiv und zu nah dran („betriebsblind“), da seine Arbeit gereviewed wird.
    Die Norm fordert dementsprechend, wie Sie bereits in 4. schreiben, dass eine 2. Person mit einbezogen werden muss. Das 4-Augen-Prinzip ist eine noch höhere Stufe, gefolgt vom 6-Augen-, … , Mehraugenprinzip.
    Beispiele für 4-Augen-Prinzipien wären
    -Erst- und Zweitprüfer einer Dissertation oder
    -die doppelte Absicherung durch doppelte Verifikation eines Autorisierungsschlüssels vor Abschuss von Atomraketen.
    -die 2.Kontrolle der Prüfergebnisse durch einen erfahrenen QC-Kollegen bei einem neuen Kollegen

    [Autor alleine -> 0.Ebene]
    [Autor plus unabhängiger Prüfer -> 1. Ebene] (von der mind. Norm gefordert)
    [Autor plus 2 unabhängige Prüfer -> 2. Ebene] (4-Augen-Prinzip)

    Nimmt es genau, dann wäre durch die Redundanz der Prüfung die erhöhte Sicherheit gewährleistet, dementsprechend wäre bei nicht-rundundanten Prüfungen (formal, fachlich) nicht sicher, dass der eine fachliche Prüfer nicht etwas übersehen hat (und somit 1. Ebene).

    Beste Grüße,
    Christian Baudis

Kommentar schreiben