{"id":6151,"date":"2015-09-30T06:00:30","date_gmt":"2015-09-30T05:00:30","guid":{"rendered":"http:\/\/www.johner-institut.de\/blog\/?p=6151"},"modified":"2023-02-06T12:24:09","modified_gmt":"2023-02-06T11:24:09","slug":"reviews","status":"publish","type":"post","link":"https:\/\/www.johner-institut.de\/blog\/regulatory-affairs\/reviews\/","title":{"rendered":"Informelles & Technisches Review: Nie gefordert und doch verlangt?"},"content":{"rendered":"
Ein Review ist eine manuelle Bewertung eines Artefakts (z.B. Code, Dokument), das abh\u00e4ngig von den formalen Anforderungen und den beteiligten Personen beispielsweise als Inspektion oder Walk-through bezeichnet wird.<\/div>\n
<\/div>\n

<\/p>\n

Ziele von Reviews<\/h2>\n

Reviews dienen dazu, Fehler in Dokumenten zu finden. Wenn das nicht gelingt, k\u00f6nnen die\u00a0Folgen\u00a0verheerend sein: Treffen wir zwei Annahmen, die ich als einigerma\u00dfen realistisch ansehe:<\/p>\n

    \n
  1. In jeder Phase Ihres Entwicklungsprozesses arbeiten Sie zu 80% korrekt. Beispielsweise haben Sie in der ersten Entwicklungsphase 80% aller Nutzungsanforderungen richtig erkannt, d.h. die Nutzungsanforderungen sind zu 80% vollst\u00e4ndig, korrekt, widerspruchsfrei usw.<\/li>\n
  2. Jede nachfolgende Phase ist doppelt so aufwendig wie die vorausgegangene. Beispielsweise bereitete es doppelt so viel Arbeit, eine Systemspezifikation zu erstellen wie die Nutzungsanforderungen zu erheben. Oder doppelt so viel Arbeit, eine Softwarearchitektur in Code zu \u00fcberf\u00fchren (zu programmieren) wie die Softwarearchitektur zu spezifizieren.<\/li>\n<\/ol>\n

    Wenn Sie diese Hypothese gelten lassen, erkennen Sie, weshalb Produkte\u00a0so fehlerhaft sind:<\/p>\n

    \"Fehlerexplosion\"

    Abb.1: Ohne Reviews kann die Anzahl der Fehler w\u00e4hrend der Entwicklung exponentiell wachsen.<\/p><\/div>\n

    Der Anteil der fehlerhaften Entwicklungsartefakte w\u00e4chst exponentiell! Bald gibt es mehr fehlerhafte als korrekte Inhalte.<\/p>\n

    Es gibt nur einen Weg, diesem Desaster zu entkommen: In jeder Phase m\u00fcssen Sie die Fehler, die in dieser und allen vorausgegangenen Phasen eingef\u00fchrt wurden, systematisch erkennen und eliminieren. Und hier sind \u2013 besonders in den konstruktiven Phasen des Entwicklungsprozesses \u2013 Reviews und andere Verifizierungsaktivit\u00e4ten Ihre einzige Rettung.<\/p>\n

    Regulatorische Anforderungen<\/h2>\n

    Keine Norm verlangt ein Review explizit als Methode. Einzig die ISO 13485<\/a> fordert Design Reviews<\/a>.<\/p>\n

    Die IEC 62304 fordert die Verifizierung der Aktivit\u00e4ten beispielsweise<\/p>\n