Qualitätsstandard
Technische Aussagen sind nur dann fachlich belastbar, wenn ihre Grundlage, ihr Geltungsbereich und ihre Grenzen nachvollziehbar sind. Deshalb werden Quellenart, Versionsstand, Untersuchungsgegenstand und fachliche Schlussfolgerung voneinander getrennt dokumentiert.
Quellenhierarchie
Externe Tatsachenbehauptungen werden möglichst auf die jeweils fachlich stärkste verfügbare Quelle gestützt. Die Auswahl orientiert sich an der konkreten Aussage: Für eine Git-Funktion ist die Git-Dokumentation näherliegend, für eine Normanforderung der maßgebliche Normtext. Die folgende Reihenfolge ist eine Suchpriorität, keine pauschale Rangordnung der Beweiskraft.
- Amtliche oder normative Primärquellen: beispielsweise veröffentlichte Rechtsquellen, Norminformationen oder Dokumente zuständiger Stellen, soweit sie für die technische Fragestellung erforderlich sind.
- Technische Primärquellen: Spezifikationen, Hersteller- oder Maintainer-Dokumentation, Protokolldokumentation und Originaldokumentation eingesetzter Technologien.
- Wissenschaftliche Originalarbeiten: insbesondere für empirische Grenzen, Fehlerraten und die Übertragbarkeit technischer Verfahren.
- Hochwertige Fachliteratur: zur Einordnung und Vertiefung, wenn eine Originalarbeit die konkrete Aussage nicht besser trägt.
- Eigene Fachliteratur: eigene Bücher und Fachbeiträge können Methoden, Denkweisen und fachliche Hintergründe vertiefen. Sie ersetzen keinen externen Nachweis für Tatsachen, die außerhalb der eigenen fachlichen Analyse liegen.
- Eigene sachverständige Analyse: die eigentliche Einordnung entsteht aus der konkreten technischen Fragestellung, den verfügbaren Unterlagen und den dokumentierten Untersuchungsmethoden.
Nicht veröffentlichte Arbeitsgrundlagen
Soweit eigene Manuskripte, Entwürfe, Lehrunterlagen oder sonstige Arbeitsmaterialien nicht veröffentlicht sind, können sie intern zur Strukturierung fachlicher Fragen und zur Entwicklung eigener Prüflogik herangezogen werden. Sie werden jedoch nicht als veröffentlichte oder unabhängige externe Quelle dargestellt.
Öffentliche Tatsachenbehauptungen werden, soweit hierfür ein externer Nachweis erforderlich ist, auf die jeweils tragende Primär-, Norm-, Hersteller-, wissenschaftliche oder sonstige geeignete Fachquelle zurückgeführt.
Quellenmatrix und wissenschaftlicher Audit
Für jede überprüfbare Kernaussage wird festgehalten, welche Quelle genau welchen Teil der Aussage trägt. Eine Quellenmatrix enthält Aussage oder Prüffrage, Dokumenttitel und Herausgeber, Fundstelle oder Abschnitt, Version beziehungsweise Publikationsstand, Prüfdatum, Quellenart, Übertragbarkeit auf den konkreten Fall und verbleibende Unsicherheit. Ein erreichbarer Link bestätigt zunächst nur die Erreichbarkeit der Quelle. Inhalt und Aussagebezug werden gesondert geprüft.
Im Audit werden außerdem Gegenhypothesen, fehlende Unterlagen, mögliche Interessenkonflikte und die Reproduzierbarkeit der wesentlichen Prüfschritte erfasst. Projektspezifische Belege bleiben vom öffentlichen Quellenverzeichnis getrennt.
Quellen sind nicht gleichbedeutend mit Fallbeweisen: Eine Spezifikation erklärt eine Funktion, eine Studie untersucht Grenzen unter ihren Versuchsbedingungen, und erst der dokumentierte technische Befund betrifft das konkrete System. Publikationsstand, Version und Prüfdatum werden getrennt geführt.
Arbeitslogik: Diagnose bis sachverständige Synthese
Nicolai Andler ordnet Problemlösungswerkzeuge und Kontrollfragen unter anderem den Phasen Diagnose, Zielformulierung, Analyse und Entscheidungsfindung zu. Für technische Gutachten wird diese Struktur hier eigenständig ausgewählt, verdichtet und angepasst:
- Diagnose: Sachverhalt, technische Unklarheit, verfügbare Unterlagen und offene Widersprüche erfassen.
- Zielformulierung: prüfbare technische Fragen, relevante Stände und Aussagegrenzen festlegen.
- Analyse: Verfahren auswählen, technische Artefakte prüfen, Befunde dokumentieren und alternative Erklärungen testen.
- Sachverständige Synthese: Befunde zur Fragestellung zusammenführen, Annahmen und Unsicherheiten offenlegen und die Reichweite der Schlussfolgerung angeben.
Die sachverständige Synthese ist eine Anpassung für diesen Wissensbereich; sie wird Andler nicht als eigene Phase zugeschrieben. Sie trifft keine rechtliche Entscheidung.
Von der Fragestellung zur Aussage
Was soll technisch geklärt werden?
Welches System, welche Version, welche Daten oder welche Dokumente werden tatsächlich geprüft?
Welche Unterlagen, Daten, Protokolle und technischen Artefakte stehen zur Verfügung?
Mit welcher dokumentierten Anforderung, Spezifikation oder Vergleichsbasis wird der Befund abgeglichen?
Mit welchen Verfahren wird die Fragestellung untersucht?
Was wurde beobachtet, gemessen oder dokumentiert?
Welche fachliche Bedeutung besitzt der Befund für die technische Fragestellung?
Welche Schlussfolgerung trägt der Befund gemessen am festgelegten Referenzmaßstab?
Welche Aussage lässt sich aufgrund der vorhandenen Daten gerade nicht treffen?
Vor einer Prüfung werden Arbeitshypothesen und plausible Gegenhypothesen benannt: Welcher Befund würde die erste Erklärung stützen, welcher würde sie widerlegen? Diese Frage begrenzt die Neigung, nur bestätigende Hinweise zu sammeln (Confirmation Bias). Fehlende Daten, Nachweisgrenzen des Verfahrens (Detection Limits), Messunsicherheit und mögliche Gegenbefunde gehören zum Ergebnis. Wo ein Ergebnis von Stichprobe, Schwellwert oder Werkzeug abhängt, werden Sensitivität und Robustheit geprüft. Datenstand, Versionen und Schritte werden so dokumentiert, dass eine fachkundige Person sie nachvollziehen kann.
Befund, Interpretation und Bewertung
Ein technischer Befund beschreibt zunächst, was festgestellt wurde. Die Interpretation ordnet diesen Befund fachlich ein. Eine weitergehende Bewertung muss erkennen lassen, nach welchen Kriterien und unter welchen Annahmen sie erfolgt.
Diese Trennung verhindert, dass Beobachtungen, Annahmen und Schlussfolgerungen unbemerkt miteinander vermischt werden.
| Ebene | Leitfrage | Typischer Nachweis | Zentrale Grenze |
|---|---|---|---|
| Befund | Was liegt technisch vor? | Messwert, Datei, Hash, Version oder reproduzierbare Beobachtung | Der Befund erklärt seine Ursache noch nicht. |
| Interpretation | Was kann der Befund bedeuten? | Kontext, Annahmen und Alternativerklärungen | Eine plausible Erklärung ist noch kein Beweis. |
| Bewertung | Welche fachliche Schlussfolgerung trägt die Evidenz? | Kriterien, Gegenbefunde und dokumentierter Referenzmaßstab | Die Schlussfolgerung darf nicht stärker sein als ihre Grundlage. |
| Aussagegrenze | Welche Schlussfolgerung ist nicht gedeckt? | Detection Limits, Datenlücken und nicht untersuchte Bereiche | Fehlende Evidenz darf nicht als Gegenbeweis umgedeutet werden. |
Technischer Nachweis und Freigabe
Ein bestandener Test, ein Messwert, ein erfolgreicher Build, eine reproduzierte Funktion oder ein anderer technischer Nachweis belegt zunächst nur den dokumentierten Sachverhalt unter den jeweiligen Prüfbedingungen.
Daraus folgt nicht automatisch eine Freigabe, Einsatzempfehlung, rechtliche Zulässigkeit oder vollständige Systemeignung. Solche weitergehenden Entscheidungen benötigen eigene Kriterien, Zuständigkeiten und gegebenenfalls weitere fachliche oder rechtliche Prüfungen.
Versions- und Zeitbezug
Technische Aussagen gelten häufig nur für einen bestimmten Versionsstand. Deshalb werden, soweit für die Aussage relevant, beispielsweise Softwareversion, Commit oder Release, Datenstand, Konfiguration und Prüfzeitpunkt festgehalten.
Bei Quellen mit veränderlichem Inhalt wird zusätzlich dokumentiert, wann die Quelle geprüft wurde.
Wann wird aus einer Quelle ein belastbarer Beleg?
Nicht die Anzahl der Links entscheidet über die Qualität einer Aussage. Entscheidend ist, ob eine konkrete Quelle die konkrete technische Behauptung tatsächlich trägt.
- Aussage und Fundstelle müssen einander eindeutig zugeordnet werden können.
- Version, Stand und technischer Geltungsbereich müssen zur Fragestellung passen.
- Gegenhypothesen und widersprechende Evidenz dürfen nicht ausgeblendet werden.
- Die Übertragungsgrenze einer allgemeinen Quelle auf den konkreten Einzelfall muss sichtbar bleiben.
Clean-Room-Prinzip
Fremde Webseiten und Wettbewerber können Hinweise auf Themen oder Suchintentionen liefern. Sie dienen jedoch nicht als Textquelle für die Beiträge. Formulierungen, Tabellen, Abbildungen, charakteristische Gliederungen oder fremde Praxisfälle werden nicht übernommen.
Die Darstellung entsteht aus Primärquellen, Fachquellen, eigener Fachliteratur und eigenständiger technischer Analyse.
Vertrauliche Mandats-, Kunden-, Angebots- und Repositorydaten werden weder als Textgrundlage noch als öffentliches Beispiel, Metadatum oder Download verwendet. Auch eine bloße Anonymisierung ersetzt keine gesonderte Freigabe.
Downloads und Rückverweise
Arbeitsvorlagen oder Checklisten werden erst veröffentlicht, wenn Herkunft, Rechte, fachlicher Stand, Dateiversion, Barrierefreiheit und Vertraulichkeit geprüft sind. Eine Downloadseite muss Geltungsbereich und Grenzen nennen und auf den zugehörigen Fachbeitrag zurückführen. Der Fachbeitrag verweist wiederum auf die jeweils gültige Vorlage. Bis zu dieser Prüfung bleiben Vorlagen intern.
Beispiele und Fallkonstellationen
Beispiele werden eindeutig eingeordnet. Konstruierten Beispielen werden keine realen Mandate, gerichtlichen Beauftragungen oder tatsächlich erzielten Ergebnisse zugeschrieben.
Aktualisierung
Eine Aktualitätsprüfung ist insbesondere erforderlich, wenn sich technische Spezifikationen, Normstände, Herstellerdokumentation oder regulatorische Rahmenbedingungen verändert haben können. Ein Änderungsdatum wird nur gesetzt, wenn eine inhaltliche Änderung tatsächlich erfolgt ist.
Dokumentationsstandard pro Beitrag
- technische Frage
- Untersuchungsgegenstand
- relevante Unterlagen oder Daten
- Versions- und Zeitbezug
- mögliche Untersuchungsmethoden
- technische Befunde
- fachliche Interpretation
- Aussagegrenzen und Unsicherheiten
- Quellen und Prüfdatum
- Abgrenzung zur rechtlichen Würdigung
Methodische Herkunft der Arbeitslogik und Kontrollfragen
Methodische Anregung ist Nicolai Andler, Tools für Projektmanagement, Workshops und Consulting – Kompendium der wichtigsten Techniken und Methoden, 6., überarbeitete und erweiterte Auflage, Publicis, Erlangen, 2015, ISBN 978-3-89578-453-8.
Von Andler stammen insbesondere der strukturierende Problemlösungszyklus aus Diagnose, Zielformulierung, Analyse und Entscheidungsfindung sowie Kontrollfragen unter anderem zu Projektplanung, Situationsdiagnose, Zielformulierung, Analyse, Entscheidungsfindung und Projektbeginn. Solche Kontrollfragen werden in diesem Wissensbereich nicht als eigene Erfindung dargestellt. Wo sie verwendet werden, werden sie für technische Sachverständigenfragen ausgewählt, verdichtet und in eigener Formulierung auf den jeweiligen Prüfkontext übertragen.
Die sachverständige Evidenz-, Prüf- und Bewertungslogik wird davon getrennt geführt. Dazu gehören insbesondere Untersuchungsgegenstand und Systemstand, Quellen- und Datenprovenienz, reproduzierbare Messung, technische Befunde, Gegenhypothesen und Gegenbefunde, fachliche Interpretation und Bewertung, Nachweisgrenzen sowie die dokumentierte Aussagegrenze. Diese technische Synthese wird Andler nicht zugeschrieben.
Die Entscheidungsfindung des allgemeinen Problemlösungszyklus wird bei einer unabhängigen Begutachtung nicht mit einer organisatorischen, wirtschaftlichen oder rechtlichen Entscheidung des Auftraggebers gleichgesetzt. Der Sachverständige liefert eine begründete technische Bewertungs- und Entscheidungsgrundlage; die zuständige Stelle trifft die weitergehende Entscheidung.
Eigene Fachliteratur und Veröffentlichungen
Die folgenden eigenen Arbeiten dienen der fachlichen Vertiefung und methodischen Einordnung. Sie ersetzen keine erforderlichen Primär-, Norm-, Hersteller- oder sonstigen unabhängigen Fachquellen. Unveröffentlichte Manuskripte, Entwürfe und Lehrunterlagen werden hier bewusst nicht als öffentliche Quellen ausgewiesen.
- Eigenes Fachbuch Kritisches Denken in Data Science mit Python – Vom Beobachten zur verantwortbaren Entscheidung
- Eigenes Fachbuch Von Daten zu Lösungen in Data Science mit Python – Vom Problem zur verantwortbaren Lösung
- Eigenes Fachbuch Von Modellen zu Entscheidungen in Machine Learning mit Python – Vom Modell zur verantwortbaren Entscheidung
- Eigenes Fachbuch Von Code zu Lösungen im Software Engineering mit Java – Vom Problem zur verantwortbaren Lösung
Technische Untersuchung statt pauschaler Bewertung
Die konkrete Aussagekraft eines Gutachtens hängt vom Untersuchungsgegenstand, den verfügbaren Unterlagen und der dokumentierten Prüfmethode ab.
Gutachtendokumentation ansehen