Problem und Umfang eingrenzen
Sie müssen nicht alles selbst bauen.
Ein Dirigent spielt nicht jedes Instrument. Er weiß aber, wann welches Instrument gebraucht wird. Genauso arbeiten Sie hier: Sie verstehen die Aufgabe, wählen das richtige Werkzeug und prüfen das Ergebnis. Code ist nur ein Anschauungsbeispiel. Sie müssen ihn nicht auswendig lernen.
Ein starker Capstone beginnt mit einem engen Scope: ein Nutzer, eine Entscheidung, ein Evidence Flow und ein messbares Outcome. Begrenzung erhöht die Chance auf technische Vollständigkeit.
- scope
- Englischer Fachbegriff für das in diesem Abschnitt erklärte technische Konzept.
- non-goal
- Englischer Fachbegriff für das in diesem Abschnitt erklärte technische Konzept.
- evaluation specification
- Englischer Fachbegriff für das in diesem Abschnitt erklärte technische Konzept.
Non-goals schützen vor Feature Drift. Product Spec, Risk Spec und Evaluation Spec werden gemeinsam geschrieben, weil jede Qualitätsanforderung Architekturentscheidungen auslöst.
Zuerst verstehen. Dann entscheiden. Erst danach bauen.
Das Problem aus dem Alltag: Die Idee lautet: ‚Ein Assistent für alle.‘ Wir machen daraus eine kleine Aufgabe für eine bestimmte Person.
Die einfache Regel: Erst muss klar sein, was richtig sein soll. Danach wird geprüft, ob es wirklich richtig ist.
Sie müssen dafür nicht alles selbst programmieren. Sie müssen entscheiden, welche Aufgabe das normale Programm, die KI oder ein Mensch übernimmt.
Merksatz: Vertrauen ist gut. Ein sichtbarer Test ist besser.
Die Idee lautet: ‚Ein Assistent für alle.‘ Wir machen daraus eine kleine Aufgabe für eine bestimmte Person.
- 01
Wir schreiben in einem Satz auf, was am Ende richtig sein muss.
- 02
Wir bestimmen, wer diese Aufgabe übernimmt: das normale Programm, die KI oder ein Mensch.
- 03
Wir probieren zuerst einen gewöhnlichen Fall.
- 04
Danach probieren wir einen schwierigen oder fehlerhaften Fall.
- 05
Wir halten das Ergebnis fest. So können wir denselben Fehler später wieder prüfen.
Am Ende sehen wir klar: Was funktioniert? Was funktioniert noch nicht? Und wann muss ein Mensch übernehmen?
Erklären Sie die Kernidee mit Ihren eigenen Worten.
Nicht abschreiben. Ein oder zwei einfache Sätze genügen.
Noch mindestens 12 eigene Wörter in einem verständlichen SatzLösen Sie den konkreten Arbeitsauftrag „Problem und Umfang eingrenzen“. Zeigen Sie dabei in einem kleinen Beispiel, wie Sie die Regel „Ein starker Capstone beginnt mit einem engen Scope: ein Nutzer, eine Entscheidung, ein Evidence Flow und ein messbares Outcome. Begrenzung erhöht die Chance auf technische Vollständigkeit.“ anwenden. Prüfen Sie außerdem den häufigen Fehler: Non-goals schützen vor Feature Drift. Product Spec, Risk Spec und Evaluation Spec werden gemeinsam geschrieben, weil jede Qualitätsanforderung Architekturentscheidungen auslöst.
class CapstoneResult:
def __init__(self, output, evidence, trace, eval_scores):
self.output = output
self.evidence = evidence
self.trace = trace
self.eval_scores = eval_scores
# TODO: connect one complete vertical slice- Ein gewöhnlicher Fall wurde ausprobiert.
- Ein schwieriger oder fehlerhafter Fall wurde ausprobiert.
- Ein Fehler wird klar angezeigt.
- Sie können in eigenen Worten sagen, was das Programm, die KI und der Mensch tun.
Hilfe 1 anzeigen
Hinweis 1: Denken Sie an diesen Fall: Die Idee lautet: ‚Ein Assistent für alle.‘ Wir machen daraus eine kleine Aufgabe für eine bestimmte Person. Schreiben Sie nur auf, was am Ende sichtbar richtig sein muss.
Hilfe 2 anzeigen
Hinweis 2: Für „Problem und Umfang eingrenzen“ brauchen Sie einen normalen Fall und einen Fehlerfall. Ihr Nachweis lautet: Arbeitsprobe 8.1: ein sichtbares Ergebnis zu „Problem und Umfang eingrenzen“, ein passender Normaltest, ein Fehlerfall und zwei einfache Sätze zu Ihrer Entscheidung.
Hilfe 3 anzeigen
Hinweis 3: Vermeiden Sie diesen Denkfehler: Non-goals schützen vor Feature Drift. Product Spec, Risk Spec und Evaluation Spec werden gemeinsam geschrieben, weil jede Qualitätsanforderung Architekturentscheidungen auslöst. Bauen Sie zuerst den kleinsten Weg und prüfen Sie danach genau diese Annahme.
Erst verstehen, dann ändern.
Die Idee lautet: ‚Ein Assistent für alle.‘ Wir machen daraus eine kleine Aufgabe für eine bestimmte Person.
Reparieren Sie nicht sofort. Notieren Sie für „Problem und Umfang eingrenzen“: Was sehen Sie? Wo könnte der Fehler liegen? Welcher kleine Test trennt zwei mögliche Ursachen? Was müsste dabei herauskommen?
Diagnose und Reparaturprinzip anzeigen
Eine gute Lösung prüft die Annahme „Non-goals schützen vor Feature Drift. Product Spec, Risk Spec und Evaluation Spec werden gemeinsam geschrieben, weil jede Qualitätsanforderung Architekturentscheidungen auslöst.“. Sie macht den Fehler sichtbar, begrenzt den Schaden und bewahrt den Fall als Wiederholungstest auf.
Lösen Sie den konkreten Arbeitsauftrag „Problem und Umfang eingrenzen“. Zeigen Sie dabei in einem kleinen Beispiel, wie Sie die Regel „Ein starker Capstone beginnt mit einem engen Scope: ein Nutzer, eine Entscheidung, ein Evidence Flow und ein messbares Outcome. Begrenzung erhöht die Chance auf technische Vollständigkeit.“ anwenden. Prüfen Sie außerdem den häufigen Fehler: Non-goals schützen vor Feature Drift. Product Spec, Risk Spec und Evaluation Spec werden gemeinsam geschrieben, weil jede Qualitätsanforderung Architekturentscheidungen auslöst.
Arbeitsprobe 8.1: ein sichtbares Ergebnis zu „Problem und Umfang eingrenzen“, ein passender Normaltest, ein Fehlerfall und zwei einfache Sätze zu Ihrer Entscheidung.
Aufbau der Musterlösung anzeigen
- 1
Ziel: Ein starker Capstone beginnt mit einem engen Scope: ein Nutzer, eine Entscheidung, ein Evidence Flow und ein messbares Outcome. Begrenzung erhöht die Chance auf technische Vollständigkeit.
- 2
Praxisfall: Die Idee lautet: ‚Ein Assistent für alle.‘ Wir machen daraus eine kleine Aufgabe für eine bestimmte Person.
- 3
Vorgehen: Lösen Sie den konkreten Arbeitsauftrag „Problem und Umfang eingrenzen“. Zeigen Sie dabei in einem kleinen Beispiel, wie Sie die Regel „Ein starker Capstone beginnt mit einem engen Scope: ein Nutzer, eine Entscheidung, ein Evidence Flow und ein messbares Outcome. Begrenzung erhöht die Chance auf technische Vollständigkeit.“ anwenden. Prüfen Sie außerdem den häufigen Fehler: Non-goals schützen vor Feature Drift. Product Spec, Risk Spec und Evaluation Spec werden gemeinsam geschrieben, weil jede Qualitätsanforderung Architekturentscheidungen auslöst.
- 4
Prüfung: Testen Sie den normalen Fall und zusätzlich den beschriebenen Fehlerfall.
- 5
Nachweis: Arbeitsprobe 8.1: ein sichtbares Ergebnis zu „Problem und Umfang eingrenzen“, ein passender Normaltest, ein Fehlerfall und zwei einfache Sätze zu Ihrer Entscheidung. Nennen Sie außerdem offen, was noch unsicher ist.
Die Musterlösung ist ein Vergleich. Ihre Lösung darf anders aussehen, wenn sie dieselbe Aufgabe nachvollziehbar erfüllt.
Lösen Sie ohne Vorlage folgende Situation: Die Idee lautet: ‚Ein Assistent für alle.‘ Wir machen daraus eine kleine Aufgabe für eine bestimmte Person. Ihre Antwort muss die Grundidee anwenden, mindestens einen konkreten Test enthalten und ein sicheres Verhalten im Fehlerfall nennen.
Noch mindestens 35 unterschiedliche Wörter in drei verständlichen Sätzen; alle fünf Prüfpunkte markieren · Automatische Plausibilitätsprüfung, keine fachliche Bewertung.Was haben Sie entschieden – und warum?
Schreiben Sie: „Ich habe … gewählt, weil … Geprüft habe ich es mit … Unsicher ist noch …“
Noch mindestens 20 eigene Wörter in zwei verständlichen SätzenW8.1 · Problem und Umfang eingrenzen
Sammeln Sie diese Dinge. So kann eine andere Person Ihre Arbeit später verstehen:
- Arbeitsprobe 8.1: ein sichtbares Ergebnis zu „Problem und Umfang eingrenzen“, ein passender Normaltest, ein Fehlerfall und zwei einfache Sätze zu Ihrer Entscheidung.
- Eine Seite mit Ihrer Entscheidung
- Ergebnis des gewöhnlichen Falls
- Ergebnis des schwierigen Falls
- Was noch unsicher ist und was Sie als Nächstes prüfen würden