Die meisten Schüler verlieren bei der IA nicht wegen schlechtem Code Punkte, sondern weil die schriftliche Ausarbeitung das Denken dahinter nicht zeigt. Prüfer bewerten nicht dein Programm. Sie bewerten, ob du ein Problem erklären, deine Designentscheidungen begründen und deine eigene Lösung ehrlich einschätzen kannst.
Fang mit einem echten Problem an, nicht mit einer coolen Idee. Die stärksten IAs lösen etwas Konkretes für einen konkreten Nutzer, nicht „eine App, die Schülern beim Lernen hilft". Wähle ein Problem, das du in einem Satz beschreiben kannst, und bei dem klar ist, wer genau davon profitiert.
Erfolgskriterien kommen vor dem Code. Schreib sie früh und halte sie konkret. „Das System soll benutzerfreundlich sein" bringt nichts. „Ein Trainer soll eine Auswechslung in unter 10 Sekunden erfassen können" schon, weil es überprüfbar ist.
Dokumentiere deine Designentscheidungen, während du sie triffst, nicht danach. Screenshots früher Prototypen, Notizen dazu, warum du eine Datenstruktur zugunsten einer anderen verworfen hast, Aufzeichnungen von Feedback. Hier stecken die meisten Punkte für „persönliches Engagement", und im Nachhinein lässt sich das kaum glaubwürdig nachbauen.
Teste gegen deine eigenen Erfolgskriterien, nicht gegen allgemeine Funktionalität. Zeig, dass das System funktioniert, und sei ehrlich darüber, was nicht klappt. Ein gut dokumentierter Fehlschlag mit klarer Erklärung wird oft besser bewertet als eine vage Behauptung, „alles funktioniert wie geplant".
Evaluation ist keine Zusammenfassung. Geh jedes Erfolgskriterium einzeln durch und sag, ob es erreicht wurde, woher du das weißt, und was du mit mehr Zeit anders machen würdest. Dieser Abschnitt ist in den meisten IAs zu kurz.
Die 35 Stunden sind schnell weg, sobald du programmierst. Plane echte Zeit für die schriftliche Ausarbeitung ein, nicht nur für den Bau.