aiMOOC

Digitale Prüfprotokolle und Qualitätskontrollen entwickeln

QR-Code

Einleitung

Du entwickelst eine Prüfprotokoll-App für Variantenbauteile im fiktiven lokalen Prüf- und Wartungslabor. Das Produkt erfasst Werte, prüft definierte Grenzwerte und erhält jede fachlich begründete Korrektur als eigene Revision. Es steuert keine Maschine, erteilt keine Sicherheitsfreigabe und verarbeitet ausschließlich synthetische Datensätze.

Zielgruppe: Auszubildende, empfohlen für das 3. Ausbildungsjahr. Voraussetzungen: A1 und A2 sowie fachliche Grundlagen des Modellfalls: einfache Datentypen, Bedingungen, lokale Dateien und grundlegende Messbegriffe. Die vorhandene MOOCwiki-Grundlage dient als Wiederholung; ihr konkreter Seiteninhalt war bei der Recherche am 22.10.2026 technisch nicht abrufbar. Deshalb setzt dieser Kurs keine ungeprüften Details daraus voraus. Zeitbedarf: etwa 5 bis 8 Lerneinheiten einschließlich Programmierprojekt.

Lernziele: Du entwirfst verständliche Eingabemasken, bindest ein Prüfprotokoll an eine dokumentierte Bauteilvariante und eine festgelegte Spezifikationsversion, testest Grenzen, erkennst Doppelsendungen und erläuterst die unveränderbare Revisionsspur. Du kannst zwischen einer fachlichen Prüfung und einer formalen Freigabe unterscheiden.

Lernweg: Zuerst Grundlagen aktivieren, dann das Beispiel nachvollziehen, anschließend eigenständig übertragen. Alle Kernaufgaben sind offline mit Python 3 und seiner Standardbibliothek oder ersatzweise mit Papier, Tabellenblatt und Pseudocode lösbar. Ein kostenpflichtiges KI-Konto ist nicht erforderlich.

Modellfall und versionierte Prüfvorgaben

Prüfauftrag und Produktgrenze

Das fiktive Labor prüft die Breite von Kunststoff-Demobauteilen, ohne echte Maschinen, Kundendaten oder realen Qualitätsbescheid. Ein Prüfmerkmal ist eine messbare Eigenschaft, hier Breite in mm; ein Sollbereich beschreibt zulässige Werte. Eine Variante bestimmt die passende Spezifikation. Die Prüfprotokoll-App gibt allein das Simulationsergebnis innerhalb oder außerhalb des Modellgrenzwerts aus, keine reale Produkteignung.

Dokument	Version	Fiktiver Inhalt	Zweck
VARIANTS.csv	1.0	VX-A und VX-B, jeweils mit eindeutiger Kennung	Stammdaten
LIMITS.csv	1.0	VX-A: 19,80 bis 20,20 mm; VX-B: 29,70 bis 30,30 mm	Grenzwerte inkl. Randwerte
TESTCASES.csv	1.0	T01 bis T08 mit erwarteten Reaktionen	Nachweis
PROTOCOL_SCHEMA.md	1.0	Pflichtfelder, Feldtypen, Korrekturregeln	Datenvertrag
LIMITS.csv	1.1 (nur Transferbeispiel)	VX-B: 29,75 bis 30,25 mm	zukünftige Revision, nicht rückwirkend

Versionierte Dokumente werden nicht still geändert: jede Änderung erhält eine neue Versionskennung, Datum, Änderungsgrund und Verantwortungsrolle. Frühere Protokolle verweisen immer auf die damals verwendete Regelversion. Wichtig: Die Werte sind rein didaktisch und keine technischen Toleranzen realer Bauteile.

Grundlagen aktivieren: Datentyp, Referenz und Rückverfolgbarkeit

Eindeutige Identifikatoren unterscheiden Prüfvorgang und Bauteil. Metadaten beschreiben Datum, Prüfmethode, Einheiten und Version. Rückverfolgbarkeit bedeutet, dass du später begründen kannst, welcher Wert mit welcher Regel bewertet wurde. Beginne mit der Leitfrage: Warum reichen Messwert und Ampelfarbe allein nicht aus?

Bildgespräch: Das externe englische Beispiel zeigt eine einfache Strichliste; in unserer App kommen Identifikation, Regelversion und revisionsfähige Korrekturen hinzu. Ohne Bild: Eine Strichliste zählt Vorkommen, kann aber einzelne Änderungsvorgänge nicht zuverlässig belegen.

Eingabemasken und Datenintegrität

Von der Maske zum Datenvertrag

Eine Eingabemaske führt die prüfende Person durch Pflichtfelder. Vorschlag für die lokale App: Prüfvorgangs-ID, Bauteil-ID, ausgewählte Variante, auf dem Demobauteil angegebene tatsächliche Variante, Messwert, Einheit mm, Begründung bei Korrektur und synthetische Bearbeiterrolle. Die Regelversion wird aus der gewählten Variante fest abgeleitet und ist nicht frei eintippbar. Anzeigen unterscheiden Rohwert, Prüfergebnis und gespeicherte Revision.

Pflichtprüfung: ID nicht leer; Variante vorhanden; ausgewählte Variante stimmt mit der angegebenen Bauteilvariante überein; Messwert ist endlich, numerisch und in mm angegeben; höchstens zwei Nachkommastellen; Regelversion existiert. Beispiel: Ausgewählt VX-B, auf dem Übungsbauteil steht VX-A → ablehnen, ohne Prüfdatensatz anzulegen. Ein technisch korrektes Zahlformat macht keine unpassende Variante richtig.

Feld	Geeignete Maskenhilfe	Validierungsreaktion
Prüfvorgangs-ID	„Für dieselbe Übermittlung dieselbe ID verwenden“	Kollision erkennen
Bauteil-ID	„Nur fiktive Kennungen, z. B. B-101“	Nicht leer
Variante	Auswahl VX-A/VX-B	Gegen Typenschild des Modellfalls prüfen
Messwert	„mm, etwa 20,10“	Dezimalzahl und endlichen Wert prüfen
Korrekturgrund	„Was wurde korrigiert und weshalb?“	Für Revision zwingend

Medienalternative: Ein Messschieber liest eine Länge ab. Im Kurs werden die angezeigten Werte ausschließlich synthetisch eingetippt; weder Gerät noch Messung sind echt.

Nutzbarkeit und Fehlerkommunikation

Gute Masken besitzen sichtbare Beschriftungen, Tastaturbedienbarkeit, eindeutige Fehlermeldungen und Text zusätzlich zu Farben. Eine Warnung „Variante stimmt nicht überein: ausgewählt VX-B, erwartet VX-A“ hilft mehr als „Fehler 17“. Fehler sollen die Eingaben erhalten, aber keine ungültige Prüfung als akzeptiertes Protokoll speichern. Vertrauliche Daten gehören nicht in Lernprotokolle.

Grenzwertprüfungen korrekt begründen

Einheiten und inklusive Grenzen

Prüfe mit der Formel untere Grenze ≤ Messwert ≤ obere Grenze. Die Randwerte selbst gelten in diesem fiktiven Fall als innerhalb. Für VX-A ergibt 19,80 mm „innerhalb“, 20,20 mm ebenfalls „innerhalb“, 20,21 mm jedoch „außerhalb“. Für VX-B ergeben 29,95 mm „innerhalb“ und 30,31 mm „außerhalb“. Verwende für dezimale Vergleiche vorzugsweise Dezimalarithmetik statt unbedachter binärer Fließkomma-Grenzvergleiche.

Abgrenzung: Kalibrierung, Messunsicherheit, Temperatur, Wiederholmessungen und tatsächliche Normvorgaben können in der Praxis entscheidend sein. Sie sind in diesem Lernmodell nicht validiert; hier ersetzt die programmierte Grenzwertregel keine messtechnische oder sicherheitsrechtliche Beurteilung. Eine fehlende Spezifikationsversion führt zu einer Ablehnung, nicht zu einer geratenen Ersatzgrenze.

Animation ohne Medien: Werkstück anlegen, Messschenkel schließen, ablesen, Einheit und Messverfahren dokumentieren; anschließend eine fiktive Zahl in die Maske eintragen.

Geführte Fallanalyse

Test-ID	Bauteil	ausgewählt/tatsächlich	mm	erwartete Systemreaktion
T01	B-101	VX-A/VX-A	20,10	Revision 1, innerhalb
T02	B-102	VX-A/VX-A	20,20	Revision 1, innerhalb (Randwert)
T03	B-103	VX-A/VX-A	20,21	Revision 1, außerhalb
T04	B-104	VX-B/VX-B	29,95	Revision 1, innerhalb
T05	B-105	VX-B/VX-A	29,95	Ablehnung, kein Prüfdatensatz
T06	B-106	VX-B/VX-B	fehlend	Ablehnung, kein Prüfdatensatz
T07	B-101	unverändert wie T01	20,10	gleiche Vorgangs-ID, kein neuer Eintrag
T08	B-101	nach Korrektur VX-A	20,24	Revision 2, außerhalb, Revision 1 bleibt sichtbar

Geführter Ablauf: Ermittle zuerst die Variante und Dokumentversion. Vergleiche den Messwert mit beiden Grenzen. Formuliere dann das Ergebnis in Worten, bevor du einen Test ausführst. Begründe bei T05 die Ablehnung, auch wenn 29,95 in den VX-B-Bereich passt. Bei T07 muss nicht nur dieselbe Antwort erscheinen, sondern die Zahl der gespeicherten Prüfereignisse gleich bleiben.

Lokale Prüfprotokoll-App und idempotente Speicherung

Datenmodell und Ereignisprinzip

Idempotenz heißt: Eine identische wiederholte Übermittlung verändert den fachlichen Endzustand nicht nochmals. Eine Prüfvorgangs-ID dient als Idempotenzschlüssel. Ein Fingerabdruck des übermittelten Inhalts schützt vor der Wiederverwendung derselben ID für abweichende Daten. Bei derselben ID und gleichem Inhalt: ursprüngliches Ergebnis zurückgeben. Bei derselben ID und verändertem Inhalt: Konflikt melden. Eine Transaktion speichert Protokoll und Schlüssel gemeinsam oder beides nicht. Bei parallelen Eingaben verhindert zusätzlich eine Eindeutigkeitsregel Doppeleinträge.

Eine Revisionsspur speichert Änderungen als neue Ereignisse, anstatt einen alten Messwert still zu überschreiben. Ein Datensatz enthält Vorgang, Bauteil, Variante, Grenzwerte, Regelversion, Messwert, Ergebnis, Bearbeiterrolle, Änderungsgrund und Zeitstempel. Eine Korrektur referenziert die bisherige Revisionsnummer und erzeugt die nächste Nummer. Eine unbemerkte Änderung an der Originalrevision ist verboten.

Ohne Grafik: Eingabe → bestehende Vorgangs-ID? → bei identischem Inhalt Ergebnis wiedergeben; sonst bei Konflikt ablehnen → Varianten prüfen → Messwert prüfen → Grenzvergleich → Ereignis und Schlüssel atomar speichern.

Arbeitsfähiges Offline-Beispiel mit Python und SQLite

Du benötigst Python 3 mit Standardbibliothek und Schreibzugriff auf einen lokalen Übungsordner. Speichere die folgende Datei unter app.py. SQLite ist eine lokale Datenbankdatei; keine Netzanbindung ist vorgesehen. Das Beispiel implementiert den Anwendungskern, auf den du eine Maske mit tkinter oder eine textbasierte Eingabe aufsetzen kannst.

import sqlite3, json, hashlib
from decimal import Decimal, InvalidOperation
from datetime import datetime, timezone

SPECS = {
    "VX-A": ("1.0", "19.80", "20.20"),
    "VX-B": ("1.0", "29.70", "30.30")
}

def now():
    return datetime.now(timezone.utc).isoformat()

def number(text):
    try:
        value = Decimal(str(text).replace(",", "."))
        if not value.is_finite() or value != value.quantize(Decimal("0.01")):
            raise ValueError("Messwert: maximal zwei Nachkommastellen")
        return value
    except (InvalidOperation, TypeError):
        raise ValueError("Messwert muss eine endliche Dezimalzahl sein")

def verdict(value, lo, hi):
    return "innerhalb" if Decimal(lo) <= value <= Decimal(hi) else "ausserhalb"

db = sqlite3.connect("demolabor.sqlite", isolation_level=None)
db.execute("""CREATE TABLE IF NOT EXISTS requests (
    req_id TEXT PRIMARY KEY, fingerprint TEXT NOT NULL,
    record_id TEXT NOT NULL, outcome TEXT NOT NULL)""")
db.execute("""CREATE TABLE IF NOT EXISTS events (
    event_id INTEGER PRIMARY KEY AUTOINCREMENT,
    record_id TEXT NOT NULL, revision INTEGER NOT NULL,
    variant TEXT NOT NULL, spec_version TEXT NOT NULL,
    min_mm TEXT NOT NULL, max_mm TEXT NOT NULL,
    value_mm TEXT NOT NULL, outcome TEXT NOT NULL,
    actor TEXT NOT NULL, reason TEXT NOT NULL, created_at TEXT NOT NULL,
    UNIQUE(record_id, revision))""")

def submit(req_id, record_id, selected, actual, measured, actor="Demo"):
    payload = [record_id, selected, actual, str(measured), actor]
    blob = json.dumps(payload, ensure_ascii=False, separators=(",", ":"))
    fingerprint = hashlib.sha256(blob.encode("utf-8")).hexdigest()
    db.execute("BEGIN IMMEDIATE")
    try:
        old = db.execute(
            "SELECT fingerprint,outcome FROM requests WHERE req_id=?",
            (req_id,)).fetchone()
        if old:
            if old[0] != fingerprint:
                raise ValueError("Vorgangs-ID mit anderem Inhalt: Konflikt")
            db.commit()
            return "wiederholt: " + old[1]
        if not req_id or not record_id or not actor:
            raise ValueError("Pflichtfeld fehlt")
        if selected not in SPECS or actual != selected:
            raise ValueError("Falsche oder unbekannte Bauteilvariante")
        if db.execute("SELECT 1 FROM events WHERE record_id=?",
                      (record_id,)).fetchone():
            raise ValueError("Bauteil bereits geprüft: Korrektur benutzen")
        value = number(measured)
        spec, lo, hi = SPECS[selected]
        outcome = verdict(value, lo, hi)
        db.execute("""INSERT INTO events
            (record_id,revision,variant,spec_version,min_mm,max_mm,
             value_mm,outcome,actor,reason,created_at)
            VALUES (?,?,?,?,?,?,?,?,?,?,?)""",
            (record_id,1,selected,spec,lo,hi,str(value),outcome,
             actor,"Erstprüfung",now()))
        db.execute("INSERT INTO requests VALUES (?,?,?,?)",
                   (req_id,fingerprint,record_id,outcome))
        db.commit()
        return outcome
    except Exception:
        db.rollback()
        raise

def correct(record_id, expected_revision, measured, reason, actor="Demo"):
    if not reason.strip() or not actor.strip():
        raise ValueError("Korrekturgrund und Bearbeiterrolle fehlen")
    value = number(measured)
    db.execute("BEGIN IMMEDIATE")
    try:
        old = db.execute("""SELECT revision,variant,spec_version,min_mm,max_mm
            FROM events WHERE record_id=? ORDER BY revision DESC LIMIT 1""",
            (record_id,)).fetchone()
        if old is None or old[0] != expected_revision:
            raise ValueError("Unbekannter Datensatz oder Versionskonflikt")
        rev, variant, spec, lo, hi = old
        outcome = verdict(value, lo, hi)
        db.execute("""INSERT INTO events
            (record_id,revision,variant,spec_version,min_mm,max_mm,
             value_mm,outcome,actor,reason,created_at)
            VALUES (?,?,?,?,?,?,?,?,?,?,?)""",
            (record_id,rev+1,variant,spec,lo,hi,str(value),outcome,
             actor,reason,now()))
        db.commit()
        return outcome
    except Exception:
        db.rollback()
        raise

if __name__ == "__main__":
    print(submit("K-01","B-101","VX-A","VX-A","20.10"))
    print(submit("K-01","B-101","VX-A","VX-A","20.10"))
    print(correct("B-101",1,"20.24","Ablesefehler"))
    for event in db.execute(
        "SELECT record_id,revision,value_mm,outcome,reason FROM events ORDER BY event_id"
    ):
        print(event)

Erwartete Konsolenausgabe beim ersten Programmstart: innerhalb; wiederholt: innerhalb; ausserhalb; danach zwei Zeilen für B-101, Revision 1 und 2. Die Schreibweise „ausserhalb“ ist nur eine technische Statuskennung. Für weitere Versuche lösche nicht blind eine echte Datenbank: nutze eine eigene, fiktive Übungsdatei oder lege für jeden Test einen neuen Testordner an. Für die Wiederholung dieses Skripts mit vorhandener Datei ist die letzte Korrektur nach Revision 2 absichtlich ein Versionskonflikt; das macht unveränderte Testvoraussetzungen nötig.

Hinweis zur fachlichen Begrenzung: Dieses didaktische Beispiel besitzt keine Rollenberechtigungen, digitale Signaturen, dauerhafte Manipulationserkennung oder produktionsreife Absicherung. Für eine reale Prüfanwendung müssten unter anderem Zugriffsrechte, Datenschutz, sichere Backups, Freigabeprozesse, gesetzliche Aufbewahrung und nachvollziehbare Zeitsynchronisation geprüft werden. Die Zeitstempel der Übungsdatei können lokal beeinflusst werden und beweisen keine Unveränderlichkeit.

Eine Eingabemaske ergänzen

Skizziere in einem Formularentwurf die Felder und verbinde den Speichern-Knopf mit submit. Für die Korrektur richte einen getrennten Dialog ein, der den aktuellen Revisionsstand anzeigt und den Änderungsgrund verlangt. Eine kostenlose Standardbibliothek-Option ist tkinter; wer keine grafische Oberfläche nutzen kann, verwendet Eingabeaufforderungen in der Konsole. Fehler-UX: Einen ungültigen Eintrag nicht einfach verwerfen, sondern Feld, Ursache und zulässiges Format nennen. Bei jeder Aktion muss die App erkennbar zwischen „nicht gespeichert“, „gespeichert“, „identisch wiederholt“ und „Korrektur gespeichert“ unterscheiden.

Video (Deutsch): informatikZentrale, Einführung in SQLiteStudio (2020); Ergänzung zur lokalen Datenbank, nicht Voraussetzung. Ohne Video: Öffne eine SQLite-Datei und frage SELECT record_id, revision, value_mm FROM events ab. Die Recherche bestätigte den YouTube-Videodatensatz, nicht eine lückenlose regionale Wiedergabe- oder Einbettungsgarantie.

Teststrategie, Revisionen und Transfer

Drei verpflichtende Abnahmetests

Test A – doppelte Übermittlung: Beginne mit leerer Übungsdatei. submit mit K-01, B-101, VX-A, VX-A, 20.10. Wiederhole exakt. Erwartung: identische fachliche Antwort, genau eine Erstprüfung in events. Sende K-01 mit 20.11: Konflikt statt weiterer Revision. Begründe: Gleiche Schlüssel dürfen nicht neue Inhalte verstecken.

Test B – falsche Variante: Neue ID K-02, Bauteil B-105, Auswahl VX-B, tatsächliche Demo-Kennzeichnung VX-A, Wert 29.95. Erwartung: Ablehnung, keine events-Zeile für B-105. Begründe: die Grenzprüfung des falschen Typs wäre inhaltlich irreführend, selbst wenn die Zahl passt.

Test C – nachvollziehbare Korrektur: Nach K-01 korrigiere B-101 von 20.10 auf 20.24 mit Grund „Ablesefehler“ und erwarteter Revision 1. Erwartung: Revision 1 innerhalb bleibt erhalten, Revision 2 ausserhalb wird neu angehängt. Zweite Korrektur mit erwarteter Revision 1 wird abgewiesen. Begründe: Eine stillschweigende UPDATE-Änderung würde die ursprüngliche Aussage unsichtbar machen.

Prüfnachweis pro Fall: Eingabe, Ausgangszustand, erwartetes Verhalten, beobachtetes Verhalten, Anzahl der Datensätze, Screenshot oder Textausgabe, fachliche Begründung und begründeter Fehlerfall. Für Offline-Abgabe reichen kommentierte Konsolenausgaben oder ein unterschriebenes fiktives Prüfblatt ohne persönliche Daten.

Testmatrix für systematische Fehlerfälle

Kategorie	Beispiel	Erwartung
Unterer Rand	VX-A = 19,80	innerhalb
Oberer Rand	VX-A = 20,20	innerhalb
Knapp darüber	VX-A = 20,21	außerhalb
Falscher Typ	VX-B gewählt / VX-A vorhanden	ablehnen
Ungültiges Format	„keine Zahl“	ablehnen
Nicht endlicher Wert	„NaN“	ablehnen
Wiederholung	gleiche Vorgangs-ID und Nutzlast	keine zweite Speicherung
Schlüsselkollision	gleiche ID, andere Nutzlast	Konflikt
Revisionskonflikt	erwartete alte Revision	keine Änderung
Neue Dokumentversion	Limits 1.1	gilt nur für ausdrücklich neue Prüfserie

Vertiefung: Unterscheide Unit-Test (eine Funktion wie verdict), Integrationstest (Transaktion und SQLite) und Akzeptanztest (vollständiger Maskenablauf). Die bekannten scikit-learn-Fallstricke bei uneinheitlicher Vorverarbeitung und Data Leakage sind nur ein analoger Recherchehinweis: Prüfdaten dürfen nicht anders interpretiert werden als die dokumentierte fachliche Regel; ein ML-Modell ist hier weder erforderlich noch als Freigabeinstanz geeignet.

Ohne Diagramm: Anwender gibt Daten ein; Programm prüft Voraussetzungen und Grenzwerte; Ergebnis und Revisionsdatensatz werden getrennt sichtbar.

Video (Deutsch): Die Merkhilfe Wirtschaft, Total Quality Management und Qualitätsmanagement (2016). Es liefert Hintergrund zum Qualitätssystem, nicht die Implementierung der App. Ohne Video: Definiere Planen, Prüfen, Dokumentieren und Verbessern jeweils in einem Satz; ein lokal berechnetes „innerhalb“ bedeutet keine offizielle Zertifizierung.

Zukunftsakzent: Revisionsspur statt stiller Überschreibung

Zeige im letzten Review die Abfolge R1 → R2 samt Grund und Regelversion. Trenne die technische Historie von der Verantwortung für eine tatsächliche Entscheidung. Eine digitale Revisionsspur kann Transparenz verbessern, ersetzt aber ohne technische Schutzmaßnahmen keine manipulationssichere Archivierung. Diskutiere, wann ein Vieraugenprinzip, eine Freigabesignatur und unveränderbare Backups nötig wären. Ein digitaler Zwilling oder eine Verwaltungsschale könnte später strukturierte Metadaten austauschen; dieser Offline-Kurs behauptet keine Konformität zur IDTA-Spezifikation.

Transferauftrag: Entwirf unabhängig eine zusätzliche Variante VX-C mit eigener dokumentierter Grenzversion und zwei negativen Tests. Erkläre, weshalb neue Varianten niemals ungeprüft die Grenzen von VX-A erben dürfen.

Interaktive Aufgaben

Quiz: Prüfe dein Wissen

Wähle bei jeder Frage eine Antwort. Die korrekte Option wird im Quiz ausgewertet; die folgenden Hinweise verraten die Lösung nicht vorab.

Warum muss die Spezifikationsversion im Prüfprotokoll stehen? (Damit der damals verwendete Grenzbereich später nachvollziehbar bleibt) (!Damit alle Messwerte nachträglich verändert werden können) (!Damit man auf eine Bauteilkennung verzichten kann) (!Damit keine Einheiten mehr nötig sind)

Rückmeldung zum Nachdenken: Denke an eine Grenzwertänderung nach der ursprünglichen Prüfung.

Wie ist im Modell VX-A mit genau 20,20 mm zu beurteilen? (Innerhalb des inklusive definierten Bereichs) (!Stets außerhalb wegen des Randwerts) (!Nur nach einem Neustart gültig) (!Automatisch eine Sicherheitsfreigabe)

Rückmeldung zum Nachdenken: Beachte das mathematische Vergleichszeichen an beiden Grenzen.

Welche Eingabe muss vor dem Grenzvergleich abgelehnt werden? (Auswahl VX-B bei tatsächlicher Variante VX-A) (!VX-A mit 20,00 mm und passenden Angaben) (!VX-B mit 30,00 mm und korrekter Einheit) (!VX-A bei gültiger Vorgangs-ID)

Rückmeldung zum Nachdenken: Fachliche Identität des Bauteils geht vor einem plausiblen Zahlenwert.

Was muss beim erneuten Senden derselben Vorgangs-ID mit identischer Nutzlast passieren? (Kein zweiter Prüfdatensatz entsteht) (!Ein neuer Prüfdatensatz wird immer geschrieben) (!Der ursprüngliche Datensatz wird still überschrieben) (!Die Grenzwerte werden automatisch vergrößert)

Rückmeldung zum Nachdenken: Prüfe auch die Anzahl der gespeicherten Ereignisse.

Was ist bei derselben Vorgangs-ID und veränderter Nutzlast richtig? (Konflikt melden und keine neue Erstprüfung anlegen) (!Änderung automatisch als identische Wiederholung werten) (!Alte Eingabe ohne Protokoll ersetzen) (!Den Fingerabdruck ignorieren)

Rückmeldung zum Nachdenken: Überlege, warum ein Schlüssel kein Freibrief für neue Daten ist.

Was ist das Hauptmerkmal einer Revisionsspur? (Alte und neue Aussage bleiben mit Änderungsgrund nachvollziehbar) (!Nur der neueste Wert bleibt erhalten) (!Jede Revision löscht automatisch die vorherige) (!Alle Nutzer erhalten uneingeschränkte Schreibrechte)

Rückmeldung zum Nachdenken: Vergleiche zwei eigenständige Ereignisse mit einem Überschreiben.

Welche Information ist bei einer Messwertkorrektur notwendig? (Ein dokumentierter Korrekturgrund und Bezug zur Vorversion) (!Das Löschen sämtlicher Zeitstempel) (!Die freie Wahl einer rückwirkenden Grenzversion) (!Die automatische Änderung der Bauteilvariante)

Rückmeldung zum Nachdenken: Eine fachliche Änderung braucht Begründung und Vorgänger.

Warum werden Protokoll und Idempotenzschlüssel in einer Transaktion gespeichert? (Damit beide Änderungen gemeinsam erfolgreich sind oder ausbleiben) (!Damit nur die erste Hälfte dauerhaft wird) (!Damit die Datenbank ohne Eindeutigkeitsregeln auskommt) (!Damit keine Validierung nötig ist)

Rückmeldung zum Nachdenken: Stelle dir einen Abbruch genau zwischen zwei Speicherschritten vor.

Welche Aussage über das App-Ergebnis ist korrekt? (Es ist nur ein Ergebnis des fiktiven Simulationsmodells) (!Es ersetzt eine reale Sicherheitsfreigabe) (!Es belegt eine offizielle IHK-Zertifizierung) (!Es bestätigt eine Kalibrierung des Messgeräts)

Rückmeldung zum Nachdenken: Unterscheide die Übungsregel von der betrieblichen Verantwortung.

Welcher Test prüft direkt einen Versionskonflikt? (Korrektur mit einer inzwischen veralteten erwarteten Revisionsnummer) (!Eine korrekte erstmalige Eingabe mit neuer ID) (!Das bloße Öffnen der Bilddatei) (!Der Vergleich zweier verschiedener Bauteilkennungen)

Rückmeldung zum Nachdenken: Was geschieht, wenn jemand eine inzwischen geänderte Revision bearbeitet?

Memory

Verbinde jeden Begriff mit seiner Erklärung.

Idempotenz	Gleiche Anfrage bewirkt keinen zusätzlichen Prüfdatensatz
Revisionsspur	Historie mit unveränderten älteren Einträgen
Grenzwert	Festgelegte obere oder untere Bewertungsgrenze
Fingerabdruck	Prüfsumme des übermittelten Inhalts
Transaktion	Gemeinsam bestätigte oder verworfene Datenbankoperationen
Pflichtfeld	Angabe, die vor dem Speichern vorhanden sein muss

Drag-and-Drop

Ordne die Schritte ihren fachlichen Zielen zu.

Ordne den passenden Begriff zu.	Aufgabe
Variante prüfen	Falschen Bauteiltyp vor dem Grenzvergleich ausschließen
Zahl prüfen	Ungültige und nicht endliche Messwerte ablehnen
Grenzen vergleichen	Modellwert als innerhalb oder außerhalb einstufen
Schlüssel prüfen	Eine inhaltsgleiche Doppelübermittlung erkennen
Revision anhängen	Korrektur erhalten, ohne den Erstwert zu löschen

Kreuzworträtsel

Die Antworten sind einzelne Fachwörter.

Variante	Welche eindeutig beschriebene Bauart bestimmt die anzuwendende Prüfvorgabe?
Revision	Wie heißt ein neuer dokumentierter Stand nach einer Korrektur?
Messwert	Wie heißt das numerische Ergebnis eines Messvorgangs?
Grenzwert	Welche festgelegte Schranke entscheidet über innerhalb und außerhalb?
Protokoll	Wie heißt die strukturierte Niederschrift eines Prüfvorgangs?
Transaktion	Wie heißt die unteilbare gemeinsame Speicherung mehrerer Datenbankänderungen?

LearningApps

Weitere frei zugängliche Suchaufgaben zum Thema; die Trefferauswahl stammt vom externen Dienst und wird nicht als inhaltlich geprüft ausgegeben.

Ohne LearningApps: Lege zehn Begriffskarten an und ordne sie lokal den passenden Ablaufschritten zu.

Lückentext

Setze für jede Lücke genau einen passenden Begriff ein.

Offene Aufgaben

Bearbeite zwölf Aufgaben mit zunehmender Selbstständigkeit. Für jede Abgabe genügen ausschließlich synthetische Daten.

Leicht

Eingabemaske: Zeichne eine barrierearme Papiermaske mit allen Pflichtfeldern und einer klaren Fehleranzeige.
Messwert: Beurteile die Werte 19,80; 20,20; 20,21 mm für VX-A und begründe beide Grenzen.
Datenmodell: Beschreibe die Bedeutung von Prüf-ID, Bauteil-ID, Variante und Regelversion mit Beispielen.
Prüfprotokoll: Vervollständige ein fiktives Protokoll für T01 einschließlich einer verständlichen Textausgabe.

Standard

Python: Setze die Textmasken-Eingabe für die lokale App um, ohne reale Geräte anzubinden.
Softwaretest: Führe Test A zur Doppelsendung aus und belege per Datenbankabfrage die Zeilenzahl.
Qualitätsprüfung: Führe Test B zur falschen Variante aus und begründe die Ablehnung trotz passender Zahl.
Versionskontrolle: Führe Test C zur Korrektur aus; liefere eine zweizeilige Revisionsübersicht.

Schwer

Datenintegrität: Entwirf einen weiteren Konflikttest: gleiche Vorgangs-ID mit abweichendem Inhalt; erkläre die notwendige Reaktion.
Prüfplanung: Definiere VX-C mit dokumentierter Regelversion und einer Randwert-, einer Fehlformat- und einer Ablehnungsprobe.
Datenbank: Erweitere den Entwurf für zwei konkurrierende Korrekturen und prüfe die Versionssperre mit erwarteter Revision.
Qualitätsmanagement: Verfasse eine kritische Kurzbewertung der Grenzen von Simulationsprotokoll, Revisionsspur und echten Freigaben.

Lernkontrolle

Datenintegrität: Erkläre anhand T01/T07 den Unterschied zwischen identischer Wiederholung und fachlich neuem Vorgang.
Variantenmanagement: Beurteile T05 und formuliere eine aussagekräftige Fehlermeldung samt fachlicher Begründung.
Grenzwertprüfung: Leite für jede Variante mindestens drei Rand- und Negativtests aus LIMITS.csv v1.0 ab.
Revision: Beschreibe für T08, welche Felder im historischen Protokoll unverändert bleiben und welche ergänzt werden müssen.
Transaktion: Analysiere, welche Inkonsistenz entstünde, wenn das Speichern des Idempotenzschlüssels ausfiele.
Versionskontrolle: Vergleiche eine Prüfung nach Regel 1.0 mit einer neuen Prüfung nach Regel 1.1; untersage die rückwirkende Umdeutung des alten Protokolls.
Softwarequalität: Nenne mindestens drei Grenzen dieses Simulationscodes gegenüber einer realen dokumentationspflichtigen Anwendung.

Lernnachweis

Eigenständiges Produkt: Lege die lauffähige lokale Prüfprotokoll-App oder einen vollständig durchspielbaren Offline-Prototyp vor. Liefere die Versionen der Musterdokumente, Eingabeübersicht, gespeicherte Musterprotokolle und vollständige Revisionsspur.

Abnahmekriterien (alle verpflichtend): (A) identische doppelte Übermittlung erzeugt eine einzige Erstprüfung; derselbe Schlüssel mit anderem Inhalt wird abgelehnt. (B) falsche Variante wird erkannt und erzeugt keinen akzeptierten Prüfeintrag. (C) Korrektur nach dem Erstprotokoll erzeugt Revision 2 mit Grund, Zeit, Rolle und unverändert erhaltener Revision 1. Eine alte erwartete Revisionsnummer wird abgelehnt.

Abgabe: Quelltext oder Pseudocode, lokaler Start- und Testleitfaden, mindestens fünf bestandene dokumentierte Testfälle, ein begründeter negativer Fehlerfall und eine mündliche Kurzbegründung der drei Entscheidungen. Keine Klarnamen, keine realen Maschinen- oder Betriebsdaten. Für jede Abnahme sind Soll- und Ist-Ergebnis getrennt zu kennzeichnen.

Bewertungsraster: Fachliche Richtigkeit 30 %, robuste Validierung 20 %, Idempotenz und Speicherung 20 %, Revisionshistorie 20 %, Nachvollziehbarkeit und Barrierearmut 10 %. Ein fehlender Pflichtabnahmetest ist unabhängig von Punkten nachzuarbeiten. Eine erfolgreich getestete Simulation ist keine reale Sicherheits- oder Qualitätsfreigabe.

OER und Wikipedia

Recherche- und Versionsstand: 22.10.2026. Die folgenden Ressourcen dienen zum fachlichen Nachlesen; ihre jeweilige aktuelle Fassung ist bei der Nutzung nochmals zu prüfen.

MOOCwiki: bereits vorhandene Grundlage – vom Auftrag vorgegeben; Inhalt konnte zum Recherchezeitpunkt nicht geladen werden, daher keine Behauptung über die darin behandelten Lernschritte.
Industrial Digital Twin Association: Downloads und AAS Specifications – Einstieg in standardisierte Informationsmodelle. Beim Abruf war auch „Release 26-01“ aufgeführt; eine direkte Normkonformitätsprüfung dieser Übungs-App fand nicht statt.
scikit-learn: Common pitfalls and recommended practices – abgerufene stabile Dokumentation 1.9.1; nützlich als allgemeine Warnung zu konsistenter Datenverarbeitung, aber nicht Grundlage der hier verwendeten deterministischen Grenzwertentscheidung.
MDN: Idempotent und MDN: Idempotency-Key – Idempotenzverständnis und Schlüsselkonzepte; MDN bezeichnet den Header als nicht standardisiert/experimentell. Die lokale App nutzt keinen HTTP-Header.
Python-Dokumentation: sqlite3 und Python-Dokumentation: decimal – Standardbibliothek; Code an der tatsächlich installierten Python-Version überprüfen.
Wikipedia: Qualitätssicherung – einführender Überblick, kein Ersatz für Betriebsnormen.

Ohne Wikipedia-Einbettung: Lies die verlinkte Artikelseite oder arbeite ausschließlich mit den Definitionen im Kurs.

Mediennachweise und zugängliche Alternativen

Dateiseiten, Urheberangaben und Lizenzen wurden anhand der Commons-Dateibeschreibungen geprüft. Die Abbildungen stammen nicht aus dem fiktiven Labor. Vorschaubilder entstehen aus den eingebetteten Commons-Dateien; die Alternativtexte stehen jeweils unmittelbar an den Dateien. Werden externe Medien nicht angezeigt, sind die jeweiligen textlichen Beschreibungen und Beispieltabellen vollständig verwendbar.

Datei / Video	Original-Dateiseite	Urheberschaft	Nutzungsrecht oder Hinweis
File:Quality Control Checksheet Example.GIF	Commons-Dateiseite	Space Pirate 3000AD	CC BY-SA 3.0
File:Digital caliper.jpg	Commons-Dateiseite	Lior Streng	CC BY-SA 4.0
File:Using the caliper correct.gif	Commons-Dateiseite	Jollyroger	CC BY 2.5
File:Flowchart de.svg	Commons-Dateiseite	Erik Streb	CC BY-SA 3.0
File:Flowgorithm Input Process Output.svg	Commons-Dateiseite	Dave Braunschweig	CC BY-SA 4.0
File:De-Design Review Based on Failure Mode-article.ogg	Commons-Dateiseite	Sprecher Eilmeldung sowie Artikelautorinnen und -autoren	CC BY-SA 2.0 DE
https://www.youtube.com/watch?v=xYR6ZWCv9V4	YouTube-Videodatensatz	informatikZentrale	Auf YouTube eingebettet, keine CC-Nachlizenzierung behauptet; regionale Verfügbarkeit kann wechseln
https://www.youtube.com/watch?v=nIXPrC_jfhU	YouTube-Videodatensatz	Die Merkhilfe Wirtschaft	Auf YouTube eingebettet, keine CC-Nachlizenzierung behauptet; regionale Verfügbarkeit kann wechseln

Audio (Deutsch, freiwillige Vertiefung):

Gesprochener älterer Wikipedia-Artikel zur Designprüfung nach Fehlerarten; Alternativtext: Audio über systematische Fehlermodenprüfung.

Der Beitrag von 2006 behandelt eine verwandte Prüfmethodik, nicht moderne Software-Idempotenz. Ohne Audio: Benenne drei mögliche Fehlerarten (falscher Typ, Grenzverletzung, verdeckte Korrektur) und jeweils eine vorbeugende Prüfung.

Urheberrecht: Bei Weiterverwendung die jeweilige Originaldatei verlinken, Autor nennen, korrekte Lizenz und Bearbeitungen ausweisen; mögliche Share-Alike-Pflichten beachten. YouTube-Material wird nicht lokal kopiert. Unsicherheit: Die Bildrechte sind dateiseitig belegt, die dauerhafte technische Einbettbarkeit in jeder MOOCwiki-Konfiguration und die regionale YouTube-Wiedergabe sind nicht garantiert.

Verknüpfte Lernbereiche

Digitale Qualitätsdokumentation

Anschlusslernen: Messtechnik, Datenmodellierung, Benutzerschnittstellen, technische Kommunikation, Prozessdokumentation, Softwaretests und Datenschutz. Die Übung ist ein unabhängiges Bildungsangebot ohne offizielle Liebherr- oder IHK-Zertifizierung.