Qpatch-Reviews detailliert (2024)

Was ist ein Qpatch Review?

Eine Review-Form, die Basis für stabile Entscheidungen im Produktentwicklungsprozess schafft. Denn ...

• Um entscheiden zu können braucht man Wissen
• Um in der Technik entscheiden zu können braucht man Wissen über die Zusammenhänge
• Um in komplexen technischen Aufgabenstellungen stabil entscheiden zu können braucht man Wissen über die Zusammenhänge mit ausreichender Qualität

Das ist die Aufgabe und das Ergebnis von Qpatch-Reviews.

WieimQpatch Logosymbolisch dargestellt,fragt man aus vier verschiedenen Sichten nach Artefakten für Zusammenhänge.

Und zwar aus der:

• Anforderungssicht
• Lösungssicht
• System-oder Randbedingungssicht
• Risikosicht

Die Fragestellungen sindje nach Sicht und Projektsituation unterschiedlich.Startet man zu Beginn eines Entwicklungsprojektesähneln sie den Fragen einer System- oder Projekt-Footprint Sitzung.Ein paar einfacheBeispielfragen:

Nach den "Quality-in-Design" Regelnwerden die Artefakte aus den Antworten dokumentiert undmiteinander verknüpft.

• Was haben die einzelnen Artefakte miteinander zu tun?
• Wie sind ihre Beziehung untereinander? Wer bedingt wen?
• Wieviel davon wissen wir und was wissen wir nicht?

Erst durch die qualitative Bewertung der Verknüpfungen im Projektkontextgeneriertdas Qpatch-Review seinen Nutzen.

... zur Qpatch-Review Schritt für Schritt Anleitung

Technisches Wissen in Qpatch-Reviews

Einen stabilen Entwicklungsprozess erlebt man, wenn auf Basis fundierter Kenntnisse oder Wissen die notwendigen Entscheidungen getroffen werden können.

Fundiert sind Kenntnisse oder Wissen, wenndieses vorhanden, nutzbar und in seiner Qualität bewertbar ist.

Vorhandenes Wissen ist gegeben ...

wenn das notwendige technische Wissen für eine Produktentwicklung explizit dokumentiert und gegliedert ist.

Lediglich implizit vorhandenesWissen ist dagegen schwerer auffindbar, selten eindeutig und eheraus singulären Sichtweisen oder Disziplinen heraus beschrieben.

Nutzbares Wissen ist gegeben ...

wenn es verständlich beschrieben und in seiner Beziehung zum Wissenszweck, also dem Entwicklungsziel, definiert ist.

Ohne diese Beziehungenzum Projektkontext bleibt das Wissen innerhalb der jeweiligen Disziplin und ist schwer nutzbar.

Ein Flickwerk im schlechten Sinn.

Bewertetes Wissen ist gegeben ...

wenn die Art der Beziehung zum Projektkontext bekannt und die Qualität des Wissens beschrieben ist. An der Art und Vollständigkeit derBeziehungen erkennt man die offenen oder losen Stellen und neue Anknüpfungspunkte.

Technisches Wissen besitzt dann die zur jeweiligen Entscheidung geforderte Qualität, wenn die Beziehungen zum Projektziel vollständig, die Beziehungsart eindeutig und das

Nicht-Wissen, rsp. die fehlende Qualität

beschrieben und hinsichtlich der Auswirkung auf das Projektziel bewertet ist.

Auch ein Flickwerk, aber im guten Sinn.

Über Quality-in-Design (QiD) Regeln

Mit derMethode QiD werden die bekannten Zusammenhänge oder Beziehungeneinertechnischen Aufgabenstellung odereines Projektes als Artefakte beschrieben, innerhalb dieses Kontextes nach definierten Regeln verknüpft und bewertet.

Die zu verknüpfenden Artefakttypen sind für die

• Anforderungssicht
  • die Kundenanforderungen,
  • Zulassungs- oder rechtliche Anforderungen,
  • Schnittstellenanforderungen,
  • Systemspezifikationen
  • ...
• Lösungssicht
  • Komponenten, Bauteile
  • Funktionen,
  • Features,
  • Charakteristiken, Merkmale,
  • ...
• System- oder Randbedingungssicht
  • Einflüsse durch die Anwendung,
  • Einflüsse durch den Kunden,
  • Betriebszustände,
  • Störgrössen,
  • ...
• Risikosicht
  • mögliche Fehlerursachen,
  • potentielle Funktionsrisiken,
  • die resultierenden Fehlerauswirkungen,
  • ...

Es existieren sowohl innerhalb, als auch Sichten übergreifend Zusammenhänge zwischen den Artefakten.

Aus der Dichte der Zusammenhänge und der Vollständigkeit in der Verknüpfung derZusammenhänge bemisst sich die Qualität des notwendigen Wissens.

Im Laufedes Projektes werden diese Beziehungendurch weitere Reviews ergänzt und detailliert. Man kann schliesslich nicht alles am Anfang wissen.

Damit zu jeder Projekt- oder Systemtechnischen Entscheidung das dafür notwendige Wissen in der jeweils geforderten Qualität verfügbar ist sollte man mit Qpatch-Reviews so früh wie möglich anfangen.

Um damit früh stabile Entscheidungen zu ermöglichen.

Wie dokumentiere ich Qpatch-Reviews?

Qpatch-Reviewsmit QiD erfordern zuerst einmal keine zusätzliche Software und kann auf vielen Software-Lösungen abgebildet und gepflegt werden.

Die einzigen Anforderungen an die Software zur Dokumentation von Qpatch-Reviews sinddabei

• die Möglichkeit unterschiedliche Artefakt-Typen aus den jeweiligen Sichten abzubilden
• und Beziehungen zwischen den Artefakten zu ermöglichen.

Software aus den Disziplinen:

• Taskmanagement,
• Anforderungs- oder
• Technischem Risikomanagement sowie
• Systems-engineering

bieten das in der Regel.

Meine Erfahrung mit Software unterstützten Qpatch-Reviews stützt sich auf bekannte Software-Produkte aus jeder dieser Kategorien.... mehr zu Qpatch-Reviews mit Software

Trotz der vielen Möglichkeiten empfehle ich die ersten Qpatch-Reviews nicht oder mit wenig Softwareunterstützung zu beginnen.

Das heisst: Flip-Chart oder Kartentechnik für die mutigen, das MS Office Paket mit Whiteboard und Excel odervergleichbaresgeht natürlich auch.

Wenn das Projekt-Team weiss, wieQpatch-Reviews in Ihrem Projekt aussehen sollen,muss man über die Dokumenten-Form und die unterstützende Software entscheiden.

In der Regel haben Organisationenein Software-Produkt, dass die Qpatch-Review Anforderungen erfüllt, schon im Haus und indie Entwicklungsprozesse implementiert, so dass man hier sinnvoll andocken sollte.... mehr zu Qpatch Software

Wie erkenne ich aus Qpatch-Reviews den sinnvollen Einsatz von Methoden?

Es ist gut zu wissen, was man nicht weiss.

VerknüpfteZusammenhänge nach QiD-Regeln beschreiben Wissen als Voraussetzung einer Funktion oder als Ergebnis einer Validierung, Verifikation.

In Qpatch-Reviews wird durch das Verknüpfen von bestehendem Wissen zu einem Ziel auch klar, was man noch nicht weiss. Durch eine Bewertung wie "Wissen noch nicht verifiziert".

Die Menge an nicht verifiziertem Wissen gleichen Typs oder die Anzahl an nicht verifiziertem Wissen pro Artefakt, aber ungleichen Typs weisen auf eine notwendige Systematik oder Methodik hin.

Sobald beschrieben ist wo und welche Wissenslücken existieren und nacheiner Bewertung des fehlenden Wissens hinsichtlich Projektrisiko, kann man den Bedarf an Methodik allgemein rsp. an einer bestimmten Methode einfach erkennen.

Feedback welcome...

Diese Websitebefindet sich im Aufbau. Die nächsten neuenBeiträgewerden Qpatch-Review Beispiele und die englischeÜbersetzung sein.

ÜberFeedback würde ich mich sehr freuen. Bitte schreibt mir Eure Anfragen, Kritiken oder Anregungen ins Kontakt-Formular.