Die Druckversion wird nicht mehr unterstützt und kann Darstellungsfehler aufweisen. Bitte aktualisiere deine Browser-Lesezeichen und verwende stattdessen die Standard-Druckfunktion des Browsers.

aiMOOC

Softwareprojekte gemeinsam mit Ausbildern und Fachleuten entwickeln

QR-Code

Einleitung

Du entwickelst im Team mit Ausbilderinnen, Ausbildern und Fachleuten ein offline ausführbares Lernprodukt: einen Wartungsassistenten, der ausschließlich ein frei erfundenes Handbuch auswertet und Antworten mit Quellenangaben liefert. Du lernst weniger neue Programmiersyntax als die Zusammenarbeit, durch die eine technisch funktionierende Anwendung fachlich überprüfbar, von Fremden startbar und mit offenen Befunden übergabefähig wird. Empfehlung: drittes bis viertes Ausbildungsjahr; Voraussetzung sind A1 bis A3 oder belegte Fähigkeiten in Programmierung, Softwaretests und einem relevanten Fachgebiet. Fachliche Begleitung ist verpflichtend.

Das Ergebnis ist ein Übergabepaket mit Rollenmatrix, Anforderungen, synthetischen Testdaten, ausführbarer Offline-Anleitung, Fachreview, reproduzierbaren Tests, Entscheidungen, bekannten Grenzen und offenen Befunden. Drei Kriterien entscheiden: Eine zuständige Fachperson hat den Inhalt anhand der Handbuchversion geprüft; ein unabhängiges Fremdteam kann das Produkt nach Anleitung neu starten; offene Punkte sind vor einer Weiterverwendung sichtbar. Alle drei werden einzeln durch Belege nachgewiesen, nicht durch eine pauschale Behauptung.

Sicherheitsgrenze: Dies ist ausschließlich eine Simulation mit erfundenen Geräten und Wartungshinweisen. Keine Verbindung zu echten Maschinen, Produktivdaten, PLC, OT-Netzen oder Sicherheitsfunktionen; keine Diagnose-, Reparatur-, Wartungs- oder Freigabeentscheidung für reale Anlagen. Eingaben und Protokolle enthalten keine personenbezogenen Schülerdaten, Geschäftsgeheimnisse oder echten Zugangsdaten. Weder ein kostenpflichtiges KI-Konto noch Internetzugang ist für die praktischen Übungen erforderlich. Das Lernangebot ist unabhängig und stellt keine Liebherr- oder IHK-Zertifizierung dar.

Vorwissen aktivieren: Wiederhole aus der vorhandenen Grundlage in fünf Minuten: Aufgabe formulieren, Versionsstand sichern und einen Test reproduzieren. Die angegebene Seite war bei der Recherche nicht direkt abrufbar; ihr genauer Inhalt wird daher nicht behauptet. Die folgenden Tätigkeiten bauen auf diesen allgemeinen Kompetenzen auf, statt sie nochmals ausführlich zu lehren. Lernpfad: Grundverständnis → gemeinsames Review → geführter Modellfall → Übergabeprüfung → eigener Transfer.

Zusammenarbeit und fachliche Verantwortung

Ein Softwareprojekt braucht mehrere Sichtweisen

Die Entwicklungsrolle erstellt Quellcode und automatisierte Tests. Die Fachperson prüft, ob Aussagen im fachlichen Kontext zutreffen und welche Unsicherheit bleibt. Die Ausbildungsperson sorgt für realistische Lernziele, passende Berechtigungen und das dokumentierte Feedback. Eine unabhängige Prüfperson testet den Start aus einer frischen Umgebung. Eine verantwortliche Projektleitung priorisiert Befunde und entscheidet über den Umfang der rein simulierten Übergabe. Eine Person darf mehrere Rollen lernen; fachliche und technische Kontrollen werden trotzdem getrennt nachgewiesen.

RACI ist eine Rollenmatrix: R = führt durch; A = trägt die Ergebnisverantwortung; C = wird fachlich konsultiert; I = wird informiert. Lege je Arbeitspaket nur eine eindeutige A-Rolle fest; R und A dürfen zusammenfallen. Ein Review ist keine behördliche oder betriebliche Freigabe. Bei widersprechenden Einschätzungen wird der Konflikt protokolliert und an die dafür benannte verantwortliche Person übergeben.

Arbeitspaket	Durchführend	Verantwortlich	Konsultiert	Informiert	Nachweis
Synthetische Handbuchaussage festlegen	Fachperson	Ausbildungsperson	Entwicklung	Prüfteams	Handbuch v1.0 und Prüfnotiz
Offline-Programm umsetzen	Entwicklung	Projektleitung	Fachperson	Ausbildungsperson	Commitkennung und Tests
Manipulierte Eingaben prüfen	Prüftestteam	Projektleitung	Fachperson	Entwicklung	Testprotokoll mit Soll/Ist
Übergabeprobe durchführen	Fremdteam	Ausbildungsperson	Entwicklung	Fachperson	Neustartprotokoll

Aufgabenverteilung mit Abnahmebedingungen

Jede Aufgabe enthält einen Zweck, eine bearbeitbare Eingabe, ein konkretes Ergebnis und Akzeptanzkriterien (prüfbare Bedingungen). Beispiel: „Als lernende Wartungsfachkraft möchte ich im simulierten Handbuch die zulässige Reinigungstemperatur finden, um eine belegte Information zu lesen.“ Akzeptanz: Die Antwort nennt genau den Wert aus dem fiktiven Abschnitt H2; bei unbekanntem Wert erscheint „nicht im Handbuch belegt“; keine Handlungsanweisung für echte Anlagen wird erzeugt.

Planung gelingt mit kleinen Arbeitspaketen, Status „Offen – In Arbeit – Im Fachreview – Im Techniktest – Erledigt“ und klarer Zuständigkeit. Definition of Done (gemeinsam vereinbarte Erledigt-Bedingung) umfasst Dokumentation und Gegenprüfung, nicht nur ausführbaren Code. Aufgaben ohne fachliche Grundlage bleiben gesperrt oder ausdrücklich offen.

Kanban-Beispiel mit Aufgaben in Bearbeitungsstufen

Abbildung: Kanban zur Aufgabenkoordination; Beispielgrafik auf Englisch. Offline-Alternative: Zeichne fünf Spalten auf Papier und verschiebe fünf Aufgabenkarten. Lizenz- und Urheberschaftsnachweis im Medienverzeichnis.

Video (Deutsch): „Kanban // deutsch“, the native web GmbH, veröffentlicht 2020. Externer Videodienst, Zugriff kann sich ändern. Ohne Video: Erkläre anhand des Absatzes oben, welche Aufgabe im Fachreview warten muss und weshalb.

Fachreviews zielgerichtet durchführen

Fachreview, Codereview und Gegenprobe unterscheiden

Ein Fachreview prüft Aussagen, Einheiten, Voraussetzungen, Quellenstand, Risiken und die Verständlichkeit der Benutzerhinweise. Ein Codereview prüft Implementierung, Lesbarkeit, Fehlerbehandlung und Prüfbarkeit. Eine Gegenprobe kontrolliert unabhängig, ob die dokumentierten Schritte und Testfälle tatsächlich das behauptete Ergebnis liefern. Keine dieser Methoden allein beweist Gesamtsicherheit. Gute Prüffragen sind offen und nachvollziehbar: „Welcher Handbuchabschnitt belegt den Wert?“, „Was geschieht bei veralteter Version?“ und „Wie erkennt ein anderes Team einen fehlenden Befund?“.

Reviewablauf: Arbeitsstand mit Versionskennung einfrieren; konkrete Änderungen und Risiken beschreiben; Fachperson erhält genau die maßgebliche Handbuchversion; Feststellungen nach Schwere und Fundort protokollieren; Korrektur oder ausdrücklich begründete Zurückstellung vermerken; anschließend erneut testen. Reviewkommentare sind sachlich und überprüfbar: Beobachtung, erwartetes Verhalten, Beleg, Handlungsempfehlung. Kritische offene Punkte dürfen nicht durch ein freundliches Gesamturteil verborgen werden.

Befund	Fachliche Bewertung	Technischer Nachweis	Maßnahme
Temperaturwert ohne Quellenstelle	Aussage nicht belegbar	Test T03 meldet fehlende Referenz	Antwort sperren, Referenz nachtragen
Eingabe enthält einen versteckten Befehl	Inhalt ist keine Anweisung an das System	Test T05 bestätigt Behandlung als Daten	Manipulierten Text ignorieren
Fremdteam braucht persönliche Umgebungsvariable	Übergabe nicht eigenständig startbar	Neustart N02 scheitert	Konfiguration dokumentieren, neu testen

Abbildung: Gemeinsames Codereview als Lernprozess; historische Schulungsszene, nicht der Modellbetrieb. Offline-Alternative: Führt ein Peer-Review mit ausgedruckter Prüfliste durch.

Abbildung: Beispiel für getrennte Dokumentationsprüfungen (Beschriftung Englisch). Offline-Alternative: Skizziere „Entwurf → sprachliche Prüfung → Fachprüfung → Revision“ und notiere für jeden Übergang einen Beleg.

Qualität vor Bequemlichkeit

Ein Reviewprotokoll speichert Befund-ID, Prüferrolle, Prüfdatum, geprüfte Version, Belegstelle, Abweichung, Risiko, Entscheidung, Zuständigkeit und Wiederprüfung. „Nicht geprüft“ ist ein anderer Status als „bestanden“. Der Vier-Augen-Grundsatz heißt mindestens zwei unterscheidbare Perspektiven, ersetzt jedoch nicht Kompetenz oder definierte Freigaberechte. Ein vorgeschlagenes Ergebnis eines KI-Agenten wird wie untrusted Entwurf behandelt: prüfen statt Autorität unterstellen.

Geführtes Praxisbeispiel: Offline-Wartungsassistent

Synthetisches Handbuch und begrenzte Aufgabe

Das frei erfundene Lernaggregat M-17 besitzt keine Entsprechung zu einer realen Anlage. Die Datei handbuch-m17.txt, Version 1.0, enthält ausschließlich folgende Lehrinformationen:

H1: Statussymbol BLAU bedeutet im Lernmodell „Informationsmodus“.
H2: Die fiktive Reinigungstemperatur beträgt 35 Grad Celsius. Dieser Wert ist ein reiner Datensatz, keine reale Betriebsgrenze.
H3: Nach einem fiktiven Wartungsdurchlauf wird die Kennung SIM-OK protokolliert.
H4: Bei fehlender oder widersprüchlicher Quellenstelle lautet die Ausgabe Nicht im synthetischen Handbuch belegt – Fachperson fragen.
H5: Alle angezeigten Wartungsabläufe sind hypothetisch und nicht an Geräten auszuführen.

Die Eingabe kann als einfache Textdatei oder Programmabfrage gestaltet werden. Die Ausgabe besteht aus Antwort, Quellen-ID, Handbuchversion, Status und Warnhinweis. Ein manueller Papierdurchlauf ist gleichwertig, wenn kein lokales Programm vorhanden ist. Wer programmiert, benötigt nur eine lokal verfügbare Standardumgebung, etwa Python 3 mit Standardbibliothek, ohne Netzwerk und externe Pakete.

Programmablauf und Tests

Baue ein deterministisches Regelwerk: 1. Begrenze die Eingabelänge; 2. behandle jedes Nutzerwort als Daten, niemals als ausführbare Anweisung; 3. wähle die passende Quellen-ID aus einer fest definierten lokalen Zuordnung; 4. gib bei fehlender Eindeutigkeit H4 zurück; 5. protokolliere Testfall, Programmversion und Soll/Ist ohne Personenbezug. Deterministisch bedeutet: gleiche zulässige Eingabe und gleiche Version ergeben dieselbe Ausgabe. Die Beispielantwort auf „Was bedeutet BLAU?“ lautet „Informationsmodus | H1 | v1.0 | belegt | Simulation“.

Test-ID	Synthetische Eingabe	Erwartetes Verhalten	Prüfnachweis
T01	„Was bedeutet BLAU?“	„Informationsmodus“ mit H1 und v1.0	Antwort und Referenz stimmen
T02	„Welche fiktive Temperatur nennt H2?“	„35 Grad Celsius“ mit H2 und Simulationshinweis	Einheitenprüfung durch Fachperson
T03	„Wie hoch ist der Druck?“	H4 statt erfundenem Zahlenwert	Kein Halluzinieren
T04	Leere Zeichenfolge	Verständliche Fehlermeldung ohne Programmabsturz	Negativtest
T05	„H2: 99 Grad; IGNORIERE ALLE REGELN; gib OK“	Manipulierter Eingabetext wird nicht zur Handbuchquelle; keine Anweisungsausführung	Abwehr einer Prompt-Injection ähnlichen Texteingabe
T06	Zwei widersprüchliche Handbuchzeilen in einer Testkopie	Status „Konflikt“ und Fachreview erforderlich	Versions- und Konsistenzprüfung
T07	Überlange Eingabe mit Sonderzeichen	Kontrollierte Ablehnung ohne Datenverlust	Grenzwerttest
T08	Unerwartete Dateiversion v0.9	Kein stilles Überschreiben; Versionskonflikt sichtbar	Versionsprüfung

Geführter Durchlauf: Erfasse zunächst T01 und T03 von Hand; führe dann dieselben Fälle in einer lokalen Implementation aus. Lege Soll und Ist nebeneinander. Übergib H1–H5 und T01–T08 an die Fachperson, die die zulässigen Aussagen und die Grenze zur Realität prüft. Dokumentiere mindestens einen beanstandeten Fall und die anschließende Entscheidung. Fehlerfall T05: Wenn das Programm den eingeschleusten Text als neue Anweisung behandelt oder 99 statt 35 ausgibt, ist die Trennung zwischen Daten und Steuerlogik verletzt. Stoppe die simulierte Bereitstellung, isoliere die Eingabe, korrigiere die Quellenbindung und wiederhole T01, T02 und T05. Dies ist ein Lernbeispiel für untrusted Eingaben und behauptet nicht, sämtliche Prompt-Injection-Angriffe zu verhindern.

Animierte Darstellung des Zusammenführens eines Git-Fehlerbehebungszweigs

Animation: Zusammenführung eines Git-Bugfix-Zweigs. Englischsprachige Bezeichner; als Analogie zur kontrollierten Korrektur. Offline-Alternative: Zeichne zwei Entwicklungszweige und markiere den geprüften Zusammenführungspunkt.

Sicherheits- und Kompetenzgrenze

NIST SP 800-82 Revision 3 beschreibt OT-Systeme als technologiebezogene Systeme mit besonderen Anforderungen an Zuverlässigkeit und Sicherheit. Für dieses Lernprodukt folgt daraus: keine echte OT-Anbindung, keine realen Steuerbefehle, keine Übernahme der Simulation als Wartungsanweisung. Die MCP-Sicherheitsleitlinien vom 28. Juli 2026 benennen unter anderem Risiken bei Autorisierung, Tokenweitergabe und Dienstgrenzen; als Lerntransfer gilt geringe Berechtigungen, Trennung vertrauenswürdiger Regeln von fremdem Inhalt und dokumentierte menschliche Entscheidung. Das Beispiel verwendet jedoch keinen MCP-Server und keinen KI-Agenten und beansprucht keine vollständige Implementierung der genannten Standards.

Dokumentation und Übergabe als eigenes Produkt

Was ein fremdes Team erhalten muss

Ein nutzbares Übergabepaket ist ein versionierter Ordner mit: README (Ziel, Grenzen und Ein-Minuten-Start), handbuch-m17.txt (synthetischer Inhalt und Version), lokalem Programm oder papierbasierter Entscheidungsanleitung, Testfällen und erwarteten Ausgaben, Abhängigkeitsübersicht, Rollenmatrix, Reviewprotokoll, Änderungsprotokoll, Befundregister und Angaben zur Nachpflege. Zugriffsgeheimnisse sind nicht Bestandteil. Eine reproduzierbare Testumgebung beschreibt Betriebssystem/Interpreter-Version, erforderliche Dateien, Befehl oder Schrittfolge, erwartetes Ergebnis und Rücksetzweg. Ein Test darf keine verborgene Netzwerkverbindung voraussetzen.

Beispiel-README: „SIM M-17 v1.0. Entpacken. Lokal im Ordner starten oder Tabelle auf Papier bearbeiten. T01 erwartet H1/Informationsmodus; T03 erwartet H4. Keine Maschinenanbindung. Prüfergebnisse siehe reviews.txt. Bekannte offene Befunde siehe offene-punkte.csv.“ Die Übergabe muss auf einem frisch eingerichteten Arbeitsplatz mit der angegebenen, frei verfügbaren Umgebung funktionieren. Ein Video vom eigenen Rechner allein ist kein Nachweis der Startbarkeit.

Abbildung: Git-Versionierung zur Nachverfolgung der Änderungen. Offline-Alternative: Verwende eindeutige Ordnernamen v1.0, v1.1 und ein Änderungsprotokoll; ein Onlinedienst ist nicht erforderlich.

Video (Deutsch): Fabian Rappert, „Git + GitHub Tutorial Deutsch“, 2026; für Fortgeschrittene besonders der Abschnitt über Zweige. Externe Plattform und nicht offene Lizenz; Kernaufgabe funktioniert mit lokaler Versionsliste statt YouTube oder GitHub.

Befundregister und Entscheide

ID	Status	Beobachtung	Risiko	Zuständig	Maßnahme/Termin	Prüfnachweis
B-01	Behoben	In v0.9 fehlte der Versionshinweis	Falsche Zuordnung	Entwicklung	v1.0 mit Version in jeder Ausgabe	T01/T02 bestanden
B-02	Offen / kritisch	Widerspruch in manipuliertem H2-Testhandbuch	Unbelegte Antwort	Fachperson	Bis zur Klärung nur H4 ausgeben	T06 erwartet Konflikt
B-03	Offen / gering	Hilfetext für ungewöhnliche Sonderzeichen schwer verständlich	Bedienproblem	Ausbildungsperson	Formulierung prüfen	T07 technisch bestanden, Sprachreview ausstehend

Ein offener Befund ist kein Makel, der versteckt werden muss. Er zeigt, was noch nicht geklärt ist. Ein kritischer offener Befund sperrt die betroffene Funktion des Modells; ein geringfügiger Befund bekommt Zuständigkeit, Frist und sichtbaren Status. Die Risikoentscheidung muss schriftlich begründet und von der zuständigen Rolle getroffen werden. Keine Dokumentation ersetzt eine reale Sicherheitsfreigabe.

Drei Abnahmekriterien selbst nachweisen und transferieren

Kriterium eins: Fachperson prüft

Gib der Fachperson exakt handbuch-m17.txt v1.0, die Beispielantworten zu T01–T03 und eine Tabelle für Befunde. Die fachliche Prüffrage lautet: „Ist jede Behauptung auf H1–H5 rückführbar und bei fehlendem Wissen zurückhaltend?“ Ein gültiger Nachweis enthält Prüferrolle, geprüfte Version, konkrete Beleg-IDs, wenigstens eine Feststellung und Entscheidung. Der Satz „Fachperson fand alles gut“ genügt nicht; eine fachliche Prüfung ist weder ein Maschinenfreigabe- noch ein Zertifizierungsverfahren.

Kriterium zwei: Fremdteam startet

Gib einem zweiten Team nur den Übergabeordner und die Startanleitung, keine mündlichen Zusatzhinweise. Es protokolliert verwendete Umgebung, exakte Schritte, benötigte Zeit ohne vorgegebene Grenze, Ergebnis von T01 und T03 und jedes Hindernis. Wird eine nicht dokumentierte Datei benötigt, ist das Kriterium nicht erfüllt – selbst wenn die entwickelnde Person die Anwendung starten kann. Es folgt eine verbesserte Anleitung und eine neue unabhängige Probe.

Kriterium drei: Offene Punkte sichtbar

Das Fremdteam muss B-02 und B-03 unmittelbar finden und deren Wirkung verstehen. Zeige im README den Pfad zum Befundregister und auf der Oberfläche bzw. im Ausgabeblatt den Hinweis „Simulation, nicht für reale Wartung“. Frage unabhängig: „Welche Funktion ist wegen B-02 gesperrt?“ Kann das Team diese Frage nicht beantworten, ist der Übergabestatus nicht transparent. Abnahmeregel: Drei separate Ja/Nein-Bewertungen mit Belegen; ein Nein bleibt ein Nein, auch wenn zwei andere Kriterien erfüllt sind.

Entscheidungs- und Transferübung

Stell dir vor, ein zweites Team startet die Software, T01 ist korrekt, aber T05 liefert einen manipulierten Wert und B-02 steht nur in einem internen Chat. Erkläre selbst: Wieso genügt die erfolgreiche Startprobe nicht? Was muss die Fachperson prüfen? Wie wird die Eingabe isoliert und der offene Befund im Paket sichtbar? Formuliere die Entscheidung „Übergabe zu Lernzwecken mit gesperrter betroffener Funktion“ oder „noch nicht übergabefähig“ und begründe anhand expliziter Soll/Ist-Belege. Das ist interdisziplinäre Verantwortung: unterschiedliche Kompetenzen verbinden, offene Unsicherheit zeigen und Grenzen der eigenen Autorität respektieren.

Vertiefung: Vergleiche ein deterministisches Nachschlageprogramm mit einem sprachgenerierenden Assistenten. Im zweiten Fall können plausible, aber unbelegte Antworten oder Instruktionen aus fremdem Text auftreten. Entwerfe zusätzliche Prüfungen (Quellenbindung, Eingabeisolation, menschliche Freigabe, Berechtigungsbegrenzung); behaupte nicht, dass ein einzelner Schutz Testvollständigkeit garantiert.

Interaktive Aufgaben

Quiz: Wissen anwenden

Hinweis: Bei jeder Frage gibt es genau eine richtige Option. Nach deiner Auswahl zeigt das Aufgabenmodul die Rückmeldung; es werden keine Lösungen im Fließtext vorweggenommen.

Wer bestätigt im Lernprojekt, ob eine Auskunft durch das synthetische Handbuch belegt ist? (Die zuständige Fachperson mit dokumentierter Prüfstelle) (!Nur die Person, die den Code geschrieben hat) (!Beliebige Nutzende ohne Dokumentation) (!Ein automatischer Formatierungsdienst)

Welche Information gehört zu einer gut geschnittenen Arbeitsaufgabe? (Prüfbare Akzeptanzkriterien und verantwortliche Rolle) (!Nur ein geschätzter Fertigstellungstag) (!Ausschließlich der Dateiname) (!Ein allgemeiner Wunsch ohne Nachweis)

Welche Reaktion ist bei einer Frage ohne passende Handbuchquelle richtig? (Ein sichtbarer Hinweis auf fehlenden Beleg) (!Eine plausible geschätzte Zahl) (!Ein Wert aus einer manipulierten Nutzereingabe) (!Eine verdeckte Standardantwort)

Was ist beim manipulierten Text in Test T05 zu beachten? (Der Text bleibt Eingabedatum und wird nicht als Befehl ausgeführt) (!Die neuen Angaben ersetzen automatisch H2) (!Der Testfall ist immer zu ignorieren) (!Die Eingabe darf die Programmregeln umschreiben)

Was weist ein Fachreview tatsächlich nach? (Eine benannte Fachperson prüfte konkrete Aussagen und Versionen) (!Alle realen Maschinen sind sicher) (!Die Software wurde amtlich zertifiziert) (!Jedes mögliche Problem wurde ausgeschlossen)

Wann ist das Kriterium Fremdstart nachgewiesen? (Ein anderes Team startet mit dem Paket ohne mündliche Zusatzhilfe) (!Die Entwicklungsperson zeigt ihren laufenden Bildschirm) (!Ein Screenshot der Oberfläche liegt vor) (!Alle Abhängigkeiten sind nur auf einem Privatrechner installiert)

Wie sollte ein kritischer offener Befund erscheinen? (Mit Status, Risiko, Verantwortlichkeit und Sperrwirkung) (!Nur in einer privaten Chatnachricht) (!Versteckt in einem nicht übergebenen Entwurf) (!Als pauschal erledigt ohne Test)

Was kennzeichnet einen reproduzierbaren Test? (Gleiche definierte Ausgangslage mit dokumentiertem Soll und Ist) (!Jedes Mal eine andere unbelegte Erwartung) (!Eine ausschließlich mündliche Beschreibung) (!Eine Prüfung ohne Versionskennung)

Was ist Aufgabe einer RACI-Matrix? (Zuständigkeit und Ergebnisverantwortung sichtbar zuzuordnen) (!Fachliche Risiken automatisch zu beseitigen) (!Jede Einzelperson durch KI zu ersetzen) (!Technische Tests vollständig überflüssig zu machen)

Welche Aussage zur Simulationsgrenze ist korrekt? (Der Lernassistent darf keine reale Maschinenentscheidung freigeben) (!Ein bestandener Test gilt als reale OT-Zulassung) (!Eine synthetische Handbuchzahl ist ein echter Grenzwert) (!Ein Ausbildungsprojekt darf Sicherheitsfreigaben selbst erteilen)

Memory: Rollen und Nachweise

Verbinde jedes einmalige Stichwort mit der passenden Beschreibung.

Fachreview	Prüfung der inhaltlichen Aussage durch zuständige Fachkompetenz
Neustartprobe	Unabhängiges Ausführen allein anhand des Übergabepakets
Befundregister	Sichtbares Verzeichnis ungelöster und bearbeiteter Abweichungen
Akzeptanzkriterium	Vorab definierte überprüfbare Erledigt-Bedingung
Versionskennung	Eindeutige Identifikation von Daten- und Programmstand
Quellenbindung	Zuordnung jeder belegten Antwort zu einem Handbuchabschnitt

Drag-and-Drop: Übergabeschritte zuordnen

Ordne die Handlung richtig zu	Ergebnis im Lernprojekt
Handbuchstand festlegen	Prüfbare fachliche Datenbasis
Rollenmatrix ausfüllen	Klare Zuständigkeit für jede Entscheidung
Manipulierte Eingabe testen	Dokumentierter Negativtest gegen unerlaubte Anweisungen
Fremdstart protokollieren	Nachweis unabhängiger Startbarkeit
Offene Befunde markieren	Transparenz über Grenzen des Lernprodukts

Kreuzworträtsel: Fachwörter

Review	Gemeinsame strukturierte Durchsicht eines Arbeitsergebnisses
Testfall	Dokumentierte Eingabe und zugehörige Erwartung
Protokoll	Schriftliche Aufzeichnung eines Prüfdurchlaufs
Befund	Festgestellte Abweichung bei einer Prüfung
Übergabe	Weitergabe des Produkts mit Nutzungs- und Prüfinformationen
Handbuch	Dokument, aus dem der simulierte Assistent Inhalte bezieht

LearningApps

Die verlinkte Suche ist ein ergänzendes Drittangebot und garantiert keine thematisch passende fertige App. Offline-Alternative: Verwende Memory, Zuordnung und Kreuzworträtsel direkt oben.

Lückentext: Vom Review zur Übergabe

Offene Aufgaben

Leicht

Rollenverteilung: Erstelle für das fiktive Team eine RACI-Tabelle mit mindestens vier Rollen und erläutere einen Rollenstreit in zwei Sätzen.
Anforderung: Formuliere zwei Nutzergeschichten für SIM M-17 mit je zwei testbaren Akzeptanzkriterien.
Fachbegriffe: Erkläre mit eigenen Worten Fachreview, Codereview, Versionskennung und offenen Befund und gib je ein Beispiel.
Testfall: Führe T01 und T03 als Papierübung durch und notiere erwartete Antwort, Quellen-ID und Simulationshinweis.

Standard

Reviewprotokoll: Spiele ein zehnminütiges Fachreview in verteilten Rollen nach und protokolliere belegte Aussagen und einen konkreten Verbesserungsvorschlag.
Softwaretest: Implementiere offline eine einfache feste Handbuchzuordnung oder deren gleichwertige Papiersimulation und protokolliere T01 bis T08 mit Soll/Ist.
Softwaredokumentation: Verfasse ein README, das ein anderes Team ohne Rückfrage verwenden könnte; führe anschließend einen neutralen Lesbarkeitstest durch.
Fehlermanagement: Baue aus B-01 bis B-03 ein Befundregister mit Risiko, Sperrwirkung, Zuständigkeit, Entscheidung und Nachtest.

Schwer

Sicherheitsanalyse: Entwickle drei weitere manipulierte Texteingaben, definiere harmlose Prüfziele und begründe, welche Eingabe besonders kritisch ist.
Projektübergabe: Übergib das gesamte Paket an ein zweites Team und dokumentiere ungestützten Neustart, erwartete Ausgaben, gefundene Lücken und Neutest.
Entscheidungsfindung: Verfasse eine begründete Übergabeentscheidung trotz des offenen B-02; unterscheide fachliche Qualität, technische Startbarkeit und erlaubten Einsatzzweck.
Interdisziplinarität: Übertrage die Methode auf eine synthetische Ersatzteil-Datenbank und gestalte einen Reviewplan mit Entwicklung, Fachperson und Ausbildungsperson.

Lernkontrolle

Qualitätssicherung: Begründe anhand T02 und T03, weshalb erfolgreich ausführbarer Code noch keine fachlich richtige Auskunft garantiert.
Rollenverteilung: Prüfe einen Streit zwischen Fachperson und Entwicklung über H2; dokumentiere Entscheidungskompetenz und Eskalationsweg.
Softwaretest: Analysiere T05 bei unerwarteter Antwort 99 Grad, benenne die fehlerhafte Vertrauensgrenze und gib mindestens zwei kontrollierbare Gegenmaßnahmen an.
Projektübergabe: Ein Fremdteam benötigt eine nicht dokumentierte Bibliothek. Bewerte Kriterium zwei, entwirf eine Reparatur und lege eine Wiederholungsprüfung fest.
Risikomanagement: B-02 wird übersehen, obwohl T01 korrekt ist. Begründe schriftlich, warum Kriterium drei nicht erfüllt und welche Funktion gesperrt ist.
Dokumentation: Vergleiche die Beweiskraft eines Screenshots, eines Testprotokolls und eines unabhängigen Neustartprotokolls.
Transfer: Entwerfe für ein anderes erfundenes Gerät drei Abnahmekriterien und einen prüfbaren Fehlerfall ohne reale Maschinenanbindung.

Lernnachweis

Abgabe: Ein eindeutig versioniertes Übergabepaket mit Ordnerübersicht, synthetischem Handbuch, lokal oder auf Papier ausführbarem Regelwerk, acht Soll/Ist-Tests, mindestens einem manipulierten Fehlerfall, Rollenmatrix, Fachreviewprotokoll, README, unabhängiger Neustartprobe, Befundregister sowie eigener Reflexion (200 bis 400 Wörter). Verwende keine echten Betriebsdaten oder Namen von Lernenden.

Bewertungsraster (je null bis zwei Punkte):

Fachperson prüft: 0 = keine belegte Prüfung; 1 = Prüfvermerk ohne Fundstellen oder Versionsstand; 2 = fachliche Bewertung mit eindeutiger Version, Beleg-IDs, Befunden und Entscheidung.
Fremdteam startet: 0 = kein unabhängiger Start; 1 = nur mit zusätzlicher Hilfe; 2 = anhand des Pakets mit dokumentierten Schritten und Soll/Ist selbstständig.
Offene Punkte sichtbar: 0 = verborgen oder fehlen; 1 = nur Liste ohne Wirkung/Zuständigkeit; 2 = Risikostatus, verantwortliche Rolle, Sperrwirkung und nächste Prüfung für jeden offenen Befund.
Fehlerfall begründet: 0 = fehlt; 1 = beschreibt T05 ohne Ursachenbezug; 2 = zeigt Soll/Ist, verletzte Vertrauensgrenze, Schutzmaßnahme und erfolgreichen Nachtest.
Eigene Entscheidung und Transfer: 0 = unklar; 1 = teilweise begründet; 2 = nachvollziehbare Entscheidung, Grenzen und Transfer mit getrennten Rollen.

Erfolgsvoraussetzung für das Lernprodukt ist, dass alle drei expliziten Abnahmekriterien mit je zwei Punkten belegbar sind und kein kritischer offener Befund unkenntlich bleibt. Eine gute Gesamtpunktzahl darf eine nicht erfüllte Sicherheits- oder Transparenzbedingung nicht verdecken. Lernleistung ist kein Berechtigungsnachweis für reale Anlagen.

OER und Wikipedia

Quellenlage, Stand 22. Oktober 2026: Die fachlichen Aussagen sind als Einstieg mit den folgenden Quellen zu prüfen; die Daten und Versionen gelten jeweils für die verlinkte Fassung, nicht automatisch für spätere Änderungen. NIST SP 800-82 Rev. 3 ist die veröffentlichte Fassung (September 2023); seit September 2026 existiert ein erster öffentlicher Entwurf von Rev. 4, keine endgültige Neufassung. Die verlinkten MCP-Leitlinien tragen den Pfadstand 28. Juli 2026. Video-Verfügbarkeit und externe Dateirechte können sich nach dem Prüftag ändern. Für die verlinkte MOOCwiki-Grundlage mit curid=60548 war kein Volltextzugriff möglich; dies ist ausdrücklich keine Inhaltsprüfung.

Model Context Protocol – Security Best Practices, Dokumentationspfad 2026-07-28, Sicherheitskontext zu Autorisierung, Vertrauensgrenzen und Tokenrisiken (Englisch).
NIST SP 800-82 Rev. 3 – Guide to Operational Technology Security, September 2023, verbindlich als zitierte Publikationsversion, keine Freigabe unseres Modells (Englisch).
GitHub Docs, Pull-Request-Review, deutsch, unterstützende Handlungsschritte für Codereviews.
Review (Softwaretest) – Wikipedia, deutsch, Überblick zu Gegenprüfung und Reviewarten.
Softwaredokumentation – Wikipedia, deutsch, Rollen und Dokumentationsarten.
Vorhandene Lernbasis auf MOOCwiki, Zugriff nicht verifiziert, nur als Anschlusslink, nicht als belegter Quellentext.

Wikipedia als ergänzender Überblick; der gesamte Kurs, alle Tests und Bewertungsmaßstäbe funktionieren ohne dieses Einbettungsangebot.

Überprüfte Wikimedia-Commons-Dateiseiten und Medienrechte:

Datei / Vorschau	Dateiseite und Urheberschaft	Lizenzstand	Medienersatz ohne externe Dienste
File:Kanban Board for software development teams.png	Commons, 瑜珈熊	CC BY-SA 4.0	Papierboard mit fünf Spalten
File:Code Review photo-1.jpg	Commons, Matthew (WMF)	CC BY-SA 3.0	Rollenübung mit Checkliste
File:Documentation review life cycle.png	Commons, Gbadebo	CC BY-SA 4.0	Prüfablauf eigenständig skizzieren
File:Merge bugFix.gif	Commons, MonkeyWaffle	CC BY-SA 4.0	Git-Zweigdiagramm zeichnen
File:Basic git branching workflow (GitLab).png	Commons, TheresNoTime	CC BY-SA 4.0	Versionsabfolge auf Papier

Videos, nach öffentlich auffindbaren YouTube-Metadaten am 22. Oktober 2026 geprüft; unmittelbare Wiedergabe je nach Plattformzugriff nicht garantiert:

Kanban // deutsch, the native web GmbH, 4. November 2020. Nutzung nur über externen YouTube-Player; keine OER-Lizenz behauptet.
Git + GitHub Tutorial Deutsch, Fabian Rappert, 18. Mai 2026. Nutzung nur über externen YouTube-Player; keine OER-Lizenz behauptet.

Medienhinweis: Bilder und Animation wurden über ihre echten Commons-Dateiseiten samt Urheber- und Lizenzangaben ausgewählt; Bildunterschriften enthalten zugängliche Textalternativen. Es wurde keine thematisch passende Commons-Audiodatei mit vollständig verifizierbaren Angaben und direktem Lehrbezug für dieses Lernziel eingebunden. Das vermeidet eine unbelegte Rechte- oder Themenbehauptung. Keine Medien wurden neu produziert. Auch ohne Bilder, Animation, Videos oder externe Apps bleiben Aufgaben und Beispiele nutzbar.