Informatik 8: Schritte der Softwareentwicklung

← Zurück zur 8. Klasse

Worum geht es? Die Lerninhalte verbinden Entwicklungsphasen, Zwischenentscheidungen, typische Probleme und bewusste Rückschau, damit Softwareentwicklung nicht nur als Herstellen eines Endprodukts erscheint, sondern als nachvollziehbarer Prozess aus Planung, Umsetzung, Prüfung und wiederholter Verbesserung.

Lernziele

Nach diesem Kapitel kannst du:

• Phasen erkennen, Reihenfolgen erklären.
• Ziele prüfen, Anforderungen benennen.
• Entwürfe deuten, Entscheidungen begründen.
• Schritte vergleichen, Alternativen nennen.
• Tests planen, Fehler erkennen.
• Debugging erklären, Korrekturen beschreiben.
• Rollen benennen, Zusammenarbeit reflektieren.
• Fortschritt prüfen, Hindernisse benennen.
• Ergebnisse bewerten, Verbesserungen ableiten.
• Prozesse dokumentieren, Erfahrungen übertragen.

Anschluss an die 7. Klasse

Nach dem Durchführen eines Softwareprojekts blickst du systematisch auf die einzelnen Schritte zurück und beurteilst, wie Zielklärung, Entwurf, Umsetzung, Test, Zusammenarbeit und Dokumentation zusammenwirken.

Lerninhalte

Kompaktüberblick

Teilbereich	Kerngedanke
Softwareentwicklung als Folge zusammenhängender Schritte	Ein tragfähiges Verständnis entsteht dann, wenn Entwicklung nicht als einzelner Programmierschritt, sondern als Abfolge von Zielklärung, Entwurf, Umsetzung, Test und Überarbeitung gesehen wird, weil erst dadurch Sinn und Funktion jedes Abschnitts deutlich …
Zielklärung und Anforderungsanalyse reflektieren	Gute Reflexion beginnt häufig schon vor dem ersten Code, weil viele spätere Probleme darauf zurückgehen, dass Ziele unklar, Anforderungen zu umfangreich oder Zusatzideen zu früh wichtiger genommen wurden als die Grundfunktion.
Entwurf und Modellierung rückblickend betrachten	Die Qualität späterer Umsetzung wird oft schon im Entwurf vorbereitet, weil Skizzen, Schrittfolgen und Modelle festlegen, welche Struktur ein Produkt erhält und wie gut andere den Lösungsweg verstehen oder weiterentwickeln können.
Umsetzung als schrittweiser Aufbau	Softwareentwicklung verläuft in der Praxis meist erfolgreicher, wenn nicht alles gleichzeitig realisiert, sondern eine kleine funktionierende Basis geschaffen und danach gezielt erweitert wird, weil dadurch Fehler früher erkannt und Fortschritte klarer …
Testen und Debuggen als eigenständige Phase	Die Schritte der Softwareentwicklung werden erst vollständig verstanden, wenn Testen und Debuggen nicht als lästige Nacharbeit erscheinen, sondern als unverzichtbare Bestandteile, die Qualität sichern und oft neue Einsichten über den Entwurf selbst liefern.
Zusammenarbeit und Rollen im Entwicklungsprozess	Die Reflexion von Softwareentwicklung bleibt unvollständig, wenn Teamarbeit ausgeblendet wird, weil viele Entscheidungen, Missverständnisse und Verbesserungen gerade aus Rollenverteilung, Kommunikation und gemeinsamer Kontrolle entstehen.
Lineare und projektorientierte Lernpfade vergleichen	Die Schritte der Softwareentwicklung lassen sich besser reflektieren, wenn unterschiedliche Vorgehensweisen bewusst verglichen werden, weil je nach Aufgabe ein eher instruktionaler, kleinschrittiger oder ein stärker projektorientierter Zugang sinnvoller sein …
Dokumentation, Rückblick und Verbesserung	Nachhaltiges Lernen entsteht besonders dann, wenn Entwicklungsschritte nicht nur durchgeführt, sondern dokumentiert, besprochen und für spätere Projekte nutzbar gemacht werden, weil genau dadurch aus Einzelerfahrungen übertragbare Einsichten werden.

Merke: Softwareentwicklung ist selten streng linear. Erkenntnisse aus Tests und Rückmeldungen führen häufig zurück zu Entwurf, Anforderungen oder Umsetzung.

Softwareentwicklung als Folge zusammenhängender Schritte

Ein tragfähiges Verständnis entsteht dann, wenn Entwicklung nicht als einzelner Programmierschritt, sondern als Abfolge von Zielklärung, Entwurf, Umsetzung, Test und Überarbeitung gesehen wird, weil erst dadurch Sinn und Funktion jedes Abschnitts deutlich werden.

Daraus wird sichtbar, dass Software nicht einfach „geschrieben“ wird, sondern aus mehreren aufeinander bezogenen Arbeitsschritten entsteht. Auch im Sprint-Backlog werden nacheinander Recherche, Minimalfunktion, Skizze, Programmbeschreibung, Testkonfiguration, Prototyp und Fehleranalyse genannt.

Beispiele:

Ein Scratch-Spiel beginnt mit Ziel und Spielfigur, nicht mit allen Effekten zugleich.

Ein Formularprojekt startet mit Fragen und Auswertungsziel, bevor Gestaltung und Zusatzfunktionen ergänzt werden.

Ein kleines Python-Programm braucht zuerst eine klare Problemformulierung und dann eine prüfbare Schrittfolge.

Ziel, Planung

Entwurf, Umsetzung

Test, Korrektur

Prozess, Abfolge

Schritt, Zusammenhang

Entwicklung, Überblick

Zielklärung und Anforderungsanalyse reflektieren

Gute Reflexion beginnt häufig schon vor dem ersten Code, weil viele spätere Probleme darauf zurückgehen, dass Ziele unklar, Anforderungen zu umfangreich oder Zusatzideen zu früh wichtiger genommen wurden als die Grundfunktion.

Zur Reflexion dieser Phase gehört die Frage, ob das Problem präzise beschrieben war, ob die wichtigste Funktion früh genug festgelegt wurde und ob unnötige Zusatzwünsche den Start erschwert haben. Im Sprint-Backlog wird ausdrücklich gefordert, bestehende Produkte zu erkunden und die minimalste Funktionalität für einen Prototyp festzulegen. Gerade daran zeigt sich, wie wichtig eine bewusste Begrenzung zu Beginn ist.

Beispiele:

Ein Spielprojekt scheitert zunächst, weil zu viele Figuren und Regeln gleichzeitig geplant werden.

Ein Quiz wird einfacher umsetzbar, nachdem nur eine Frage und eine Rückmeldung als Startfunktion festgelegt werden.

Eine Web-Idee wird klarer, nachdem zuerst nur Startseite, Navigation und eine Kerninformation vorgesehen werden.

Ziel, Funktion

Bedarf, Grenze

Kernidee, Zusatzidee

Auswahl, Fokus

Anfang, Richtung

Reflexion, Präzision

Entwurf und Modellierung rückblickend betrachten

Die Qualität späterer Umsetzung wird oft schon im Entwurf vorbereitet, weil Skizzen, Schrittfolgen und Modelle festlegen, welche Struktur ein Produkt erhält und wie gut andere den Lösungsweg verstehen oder weiterentwickeln können.

Reflexion in dieser Phase fragt, ob die gewählte Darstellung hilfreich war: War eine Skizze ausreichend, hätte ein Ablaufdiagramm geholfen, waren Ein-und Ausgänge klar benannt, und wurde die Funktion verständlich beschrieben?

Beispiele:

Ein Ablauf wird verständlicher, wenn er zuerst als Reihenfolge mit Bedingungen notiert wird.

Ein Microcontroller-Projekt wird leichter umsetzbar, wenn Sensoren und Anzeigen früh im Schaltplan sichtbar sind.

Ein Scratch-Spiel bleibt übersichtlicher, wenn Figuren, Bühne und Reaktionen vorab getrennt geplant werden.

Skizze, Modell

Ablauf, Logik

Ein-Ausgänge, Struktur

Plan, Übersicht

Darstellung, Nutzen

Reflexion, Passung

Orientierung auf einen Blick

Als Nächstes	Kurz erklärt
Umsetzung als schrittweiser Aufbau	Softwareentwicklung verläuft in der Praxis meist erfolgreicher, wenn nicht alles gleichzeitig realisiert, sondern eine kleine funktionierende Basis geschaffen und danach gezielt erweitert wird, weil dadurch Fehler früher erkannt und Fortschritte klarer …
Testen und Debuggen als eigenständige Phase	Die Schritte der Softwareentwicklung werden erst vollständig verstanden, wenn Testen und Debuggen nicht als lästige Nacharbeit erscheinen, sondern als unverzichtbare Bestandteile, die Qualität sichern und oft neue Einsichten über den Entwurf selbst liefern.
Zusammenarbeit und Rollen im Entwicklungsprozess	Die Reflexion von Softwareentwicklung bleibt unvollständig, wenn Teamarbeit ausgeblendet wird, weil viele Entscheidungen, Missverständnisse und Verbesserungen gerade aus Rollenverteilung, Kommunikation und gemeinsamer Kontrolle entstehen.

Merke: Achte beim Weiterlesen darauf, wie die nächsten Teilaspekte mit den bereits behandelten Grundlagen zusammenhängen.

Umsetzung als schrittweiser Aufbau

Softwareentwicklung verläuft in der Praxis meist erfolgreicher, wenn nicht alles gleichzeitig realisiert, sondern eine kleine funktionierende Basis geschaffen und danach gezielt erweitert wird, weil dadurch Fehler früher erkannt und Fortschritte klarer überprüft werden können.

Die Materialien zum Programmierunterricht zeigen sowohl kleinschrittige Lernpfade als auch projektorientierte Aufgaben. Gerade im Rückblick wird sichtbar, welche Startstrategie sinnvoll war: Wurde zuerst eine Minimalversion gebaut, konnten einzelne Funktionen einzeln geprüft werden, und war der Ausbau kontrollierbar? Ein reflektierter Blick auf die Umsetzung fragt daher auch, ob der Weg eher über tragfähige Zwischenstände oder über zu große Sprünge führte.

Beispiele:

Zuerst Bewegung, danach Kollision, dann Punkte.

Zuerst Eingabe, danach Auswertung, dann Gestaltung.

Zuerst Testkonfiguration, danach Gesamtsystem.

Solche Reihenfolgen erleichtern die spätere Fehlersuche deutlich.

Basis, Ausbau

Schritt, Zwischenstand

Funktion, Erweiterung

Reihenfolge, Kontrolle

Umsetzung, Fortschritt

Reflexion, Aufbau

Testen und Debuggen als eigenständige Phase

Die Schritte der Softwareentwicklung werden erst vollständig verstanden, wenn Testen und Debuggen nicht als lästige Nacharbeit erscheinen, sondern als unverzichtbare Bestandteile, die Qualität sichern und oft neue Einsichten über den Entwurf selbst liefern.

Reflexion dieser Phase betrifft mehrere Fragen: Wurde früh genug getestet, gab es eine sinnvolle Testkonfiguration, wurden Fehler dokumentiert, und welche Ursachen steckten hinter Problemen? Im Sprint-Backlog wird eine Testkonfiguration ausdrücklich genannt, ebenso die Fehleranalyse. Damit wird deutlich, dass Prüfung und Korrektur geplant und nicht dem Zufall überlassen werden sollen.

Beispiele:

Ein Programm reagiert falsch, weil eine Bedingung fehlt.

Ein Spiel zählt Punkte doppelt, weil Ereignisse zu oft ausgelöst werden.

Ein Formular liefert unbrauchbare Ergebnisse, weil Antworttypen unpassend gewählt wurden.

Ein Gerät reagiert nicht, weil Ein-und Ausgänge falsch zugeordnet sind.

Test, Prüfung

Fehler, Ursache

Debugging, Korrektur

Konfiguration, Kontrolle

Qualität, Sicherheit

Reflexion, Lernen

Zusammenarbeit und Rollen im Entwicklungsprozess

Die Reflexion von Softwareentwicklung bleibt unvollständig, wenn Teamarbeit ausgeblendet wird, weil viele Entscheidungen, Missverständnisse und Verbesserungen gerade aus Rollenverteilung, Kommunikation und gemeinsamer Kontrolle entstehen.

Pair Programming zeigt diesen Aspekt besonders deutlich. Im Rückblick kann gefragt werden, ob die Rollen klar waren, ob die Zusammenarbeit Fehler verhindert hat und ob beide Personen aktiv am Denken beteiligt waren. Zudem wird betont, dass Pair Programming soziale Kompetenzen fordert und mit Think-Pair-Share oder Gruppenpuzzle kombiniert werden kann.

Beispiele:

Der Driver tippt den Code, der Navigator prüft Logik und Reihenfolge.

Ein Rollenwechsel nach einigen Minuten verhindert einseitige Arbeit.

Eine gute Absprache vor dem Coden spart spätere Korrekturen.

Ungeduld oder Eingreifen ohne Absprache erschweren die Zusammenarbeit.

Driver, Navigator

Wechsel, Absprache

Team, Rolle

Blick, Kontrolle

Zusammenarbeit, Fehlervermeidung

Reflexion, Sozialkompetenz

Zweiter Zwischenüberblick

Vertiefung	Wichtig dabei
Lineare und projektorientierte Lernpfade vergleichen	Die Schritte der Softwareentwicklung lassen sich besser reflektieren, wenn unterschiedliche Vorgehensweisen bewusst verglichen werden, weil je nach Aufgabe ein eher instruktionaler, kleinschrittiger oder ein stärker projektorientierter Zugang sinnvoller sein …
Dokumentation, Rückblick und Verbesserung	Nachhaltiges Lernen entsteht besonders dann, wenn Entwicklungsschritte nicht nur durchgeführt, sondern dokumentiert, besprochen und für spätere Projekte nutzbar gemacht werden, weil genau dadurch aus Einzelerfahrungen übertragbare Einsichten werden.

Merke: Die Teilaspekte gehören zusammen: Fachwissen wird besonders tragfähig, wenn du Zusammenhänge an konkreten Beispielen erklären kannst.

Lineare und projektorientierte Lernpfade vergleichen

Die Schritte der Softwareentwicklung lassen sich besser reflektieren, wenn unterschiedliche Vorgehensweisen bewusst verglichen werden, weil je nach Aufgabe ein eher instruktionaler, kleinschrittiger oder ein stärker projektorientierter Zugang sinnvoller sein kann.

Beide Wege haben Vor-und Nachteile.

Reflexion bedeutet hier, den eigenen Lern-und Entwicklungsweg auf Motivation, Hürden, Übersicht und Passung zur Gruppe zu prüfen.

Beispiele:

Ein kleinschrittiger Lernpfad hilft beim sicheren Einstieg in neue Werkzeuge.

Ein offeneres Projekt motiviert oft stärker, verlangt aber mehr Selbststeuerung.

Eine Kombination kann sinnvoll sein, wenn zuerst Grundlagen geübt und danach ein eigenes Projekt durchgeführt wird.

Top-down, Bottom-up

Lernpfad, Projekt

Anleitung, Offenheit

Sicherheit, Motivation

Einstieg, Erweiterung

Reflexion, Passung

Dokumentation, Rückblick und Verbesserung

Nachhaltiges Lernen entsteht besonders dann, wenn Entwicklungsschritte nicht nur durchgeführt, sondern dokumentiert, besprochen und für spätere Projekte nutzbar gemacht werden, weil genau dadurch aus Einzelerfahrungen übertragbare Einsichten werden.

Reflexion kann schriftlich, mündlich oder im Team erfolgen. Hilfreiche Fragen sind: Was war unser Ziel, welche Entscheidung war gut, wo haben wir Zeit verloren, welche Fehlannahme trat auf, und was würden wir beim nächsten Mal anders machen?

Auch in den Informatik-Beispielen wird praktische Übung mit anschließender Diskussion und Reflexion verbunden.

Beispiele:

Ein Team merkt, dass Tests zu spät eingeplant wurden.

Eine Gruppe erkennt, dass die Skizze zu ungenau war.

Ein Projekt lief besser, nachdem die Kernfunktion früher festgelegt wurde.

Eine spätere Aufgabe profitiert von diesen Einsichten.

Rückblick, Auswertung

Prozess, Erkenntnis

Fehler, Verbesserung

Entscheidung, Wirkung

Erfahrung, Transfer

Reflexion, Entwicklung

Begriffe und Zusammenhänge auf einen Blick

Thema	Das solltest du verbinden können
Softwareentwicklung als Folge zusammenhängender Schritte	Ein tragfähiges Verständnis entsteht dann, wenn Entwicklung nicht als einzelner Programmierschritt, sondern als Abfolge von Zielklärung, Entwurf, Umsetzung, Test und Überarbeitung gesehen wird, weil erst dadurch Sinn und Funktion jedes Abschnitts deutlich …
Entwurf und Modellierung rückblickend betrachten	Die Qualität späterer Umsetzung wird oft schon im Entwurf vorbereitet, weil Skizzen, Schrittfolgen und Modelle festlegen, welche Struktur ein Produkt erhält und wie gut andere den Lösungsweg verstehen oder weiterentwickeln können.
Testen und Debuggen als eigenständige Phase	Die Schritte der Softwareentwicklung werden erst vollständig verstanden, wenn Testen und Debuggen nicht als lästige Nacharbeit erscheinen, sondern als unverzichtbare Bestandteile, die Qualität sichern und oft neue Einsichten über den Entwurf selbst liefern.
Lineare und projektorientierte Lernpfade vergleichen	Die Schritte der Softwareentwicklung lassen sich besser reflektieren, wenn unterschiedliche Vorgehensweisen bewusst verglichen werden, weil je nach Aufgabe ein eher instruktionaler, kleinschrittiger oder ein stärker projektorientierter Zugang sinnvoller sein …

Merke: Nutze die Tabellen nicht nur zum Nachlesen: Versuche, jede Zeile mit einem eigenen Beispiel oder einer eigenen Begründung zu ergänzen.

Kurz zusammengefasst

Kernkompetenz	Das bedeutet konkret
Phasen erkennen, Reihenfolgen erklären	„Phasen“ in konkreten Beispielen anhand typischer Merkmale identifizieren und von ähnlichen Fällen abgrenzen. Den Zusammenhang „Reihenfolgen“ in eigenen Worten erläutern und an einem passenden Beispiel zeigen.
Ziele prüfen, Anforderungen benennen	„Ziele“ anhand festgelegter Kriterien kontrollieren und Fehler, Risiken oder Auffälligkeiten begründet benennen. Zum Thema „Anforderungen“ die wichtigsten Elemente oder Begriffe korrekt nennen und passende Beispiele zuordnen.
Entwürfe deuten, Entscheidungen begründen	Bei „Entwürfe“ die Bedeutung aus dem Kontext erklären und daraus passende Folgerungen ableiten. „Entscheidungen“ mit nachvollziehbaren Kriterien, Fakten oder Beispielen begründen.
Schritte vergleichen, Alternativen nennen	Varianten von „Schritte“ anhand sinnvoller Kriterien gegenüberstellen und relevante Gemeinsamkeiten sowie Unterschiede herausarbeiten. Zum Thema „Alternativen“ wesentliche Punkte nennen und mindestens ein passendes Beispiel anführen.
Tests planen, Fehler erkennen	Für „Tests“ Ziel, notwendige Schritte, Reihenfolge und wichtige Rahmenbedingungen festlegen. „Fehler“ in konkreten Beispielen anhand typischer Merkmale identifizieren und von ähnlichen Fällen abgrenzen.
Debugging erklären, Korrekturen beschreiben	Den Zusammenhang „Debugging“ in eigenen Worten erläutern und an einem passenden Beispiel zeigen. „Korrekturen“ mit den wesentlichen Merkmalen bzw. Schritten geordnet und verständlich darstellen.
Rollen benennen, Zusammenarbeit reflektieren	Zum Thema „Rollen“ die wichtigsten Elemente oder Begriffe korrekt nennen und passende Beispiele zuordnen. „Zusammenarbeit“ rückblickend anhand von Kriterien beurteilen und daraus Verbesserungen oder Konsequenzen ableiten.
Fortschritt prüfen, Hindernisse benennen	„Fortschritt“ anhand festgelegter Kriterien kontrollieren und Fehler, Risiken oder Auffälligkeiten begründet benennen. Zum Thema „Hindernisse“ die wichtigsten Elemente oder Begriffe korrekt nennen und passende Beispiele zuordnen.
Ergebnisse bewerten, Verbesserungen ableiten	„Ergebnisse“ anhand nachvollziehbarer Kriterien beurteilen und zu einem begründeten Urteil kommen. „Verbesserungen“ aus vorhandenen Informationen, Regeln oder Beobachtungen nachvollziehbar herleiten.
Prozesse dokumentieren, Erfahrungen übertragen	Prozesse so festhalten, dass Vorgehen, Änderungen und Ergebnis für andere nachvollziehbar bleiben. Erfahrungen auf eine neue Situation anwenden und zeigen, welche Teile des bisherigen Wissens weiterhin passen.

Merke: Die wichtigsten Inhalte solltest du nicht nur wiedergeben, sondern auf neue Situationen übertragen, begründet anwenden und kritisch beurteilen können.

Weiterführende Links

• GitHub Docs
• Scrum Guide
• Atlassian Agile

Passende LearningSnacks

• Algorithmus
• Python 3 - Grundlagen

Übungen

Die Aufgaben setzen die Inhalte praktisch um. Der konkrete Auftrag steht bei jeder Aufgabe ausdrücklich unter Arbeitsauftrag:.

Entwicklungsweg rekonstruieren

Arbeitsauftrag:

Bearbeite die Aufgabe „Entwicklungsweg rekonstruieren“ anhand der folgenden Vorgaben:

Die Lehrkraft zeigt ein kleines fertiges Produkt, etwa ein Scratch-Spiel, ein Formular, eine einfache Website oder ein Mini-Programm. Die Schülerinnen und Schüler rekonstruieren in Gruppen, welche Schritte wahrscheinlich durchlaufen wurden: Zielklärung, Anforderungsauswahl, Entwurf, Umsetzung, Test, Fehlerkorrektur und Verbesserung. Danach ordnen sie ihre Vermutungen in eine sinnvolle Reihenfolge und begründen, warum manche Schritte früher oder später stattgefunden haben müssen. In der Besprechung wird verglichen, wie unterschiedlich Entwicklungsprozesse aussehen können, obwohl das Endprodukt auf den ersten Blick einfach wirkt.

Hinweise aus der Aufgabe

• Produkt, Analyse
• Schritte, Reihenfolge
• Ziel, Entwurf
• Test, Verbesserung
• Produkte, Ablaufplan
• Wirkung, Prozessblick

Phasenkarten richtig ordnen

Arbeitsauftrag:

Bearbeite die Aufgabe „Phasenkarten richtig ordnen“ anhand der folgenden Vorgaben:

Die Lehrkraft bereitet Karten mit Begriffen wie Problem, Ziel, Anforderungen, Entwurf, Prototyp, Umsetzung, Test, Debugging, Dokumentation und Reflexion vor. Die Schülerinnen und Schüler ordnen die Karten zuerst allein oder in Partnerarbeit, danach in der Gruppe. Im zweiten Schritt ergänzen sie zu jeder Phase eine typische Handlung und ein mögliches Zwischenergebnis. Anschließend markieren sie Stellen, an denen Rücksprünge sinnvoll oder notwendig sind, etwa nach einem fehlerhaften Test.

Hinweise aus der Aufgabe

• Karten, Phasen
• Ordnung, Ablauf
• Handlung, Ergebnis
• Rücksprung, Schleife
• Produkte, Phasenmodell
• Wirkung, Überblick

Was lief schief?

Arbeitsauftrag:

Bearbeite die Aufgabe „Was lief schief?“ anhand der folgenden Vorgaben:

Die Lehrkraft gibt kurze Problemszenen vor, etwa „Das Spiel ist zu kompliziert geworden“, „Die Gruppe wusste nicht mehr, wer wofür zuständig ist“, „Der Fehler wurde erst ganz am Schluss entdeckt“ oder „Die App hatte zu viele Zusatzfunktionen und keine stabile Grundfunktion“. Die Schülerinnen und Schüler ordnen zu, in welcher Phase der Softwareentwicklung der Fehler wahrscheinlich entstanden ist und welche bessere Entscheidung dort möglich gewesen wäre. Danach formulieren sie Verbesserungsvorschläge für genau diesen Entwicklungsschritt.

Hinweise aus der Aufgabe

• Probleme, Szene
• Ursache, Phase
• Fehler, Entscheidung
• Lösung, Verbesserung
• Produkte, Zuordnung
• Wirkung, Einsicht

Entwicklungsjournal auswerten

Arbeitsauftrag:

Bearbeite die Aufgabe „Entwicklungsjournal auswerten“ anhand der folgenden Vorgaben:

Während eines kleinen Programmier-oder Softwareprojekts führen die Schülerinnen und Schüler ein einfaches Entwicklungsjournal. Darin notieren sie Ziel, bearbeitete Aufgabe, Probleme, Tests, Änderungen und offene Fragen. Nach Abschluss des Projekts werten sie das Journal aus und markieren Stellen, an denen Planung, Entwurf, Test oder Teamabsprache besonders wichtig waren. Danach schreiben sie eine kurze Prozessreflexion: Was lief gut, was war unnötig schwierig und was würde ich beim nächsten Mal früher oder anders machen? Die Aufgabe ist besonders lernstark, weil Prozessbewusstsein aus eigener Erfahrung entsteht.

Hinweise aus der Aufgabe

• Journal, Notizen
• Ziel, Problem
• Test, Änderung
• Rückblick, Erkenntnis
• Produkte, Reflexion
• Wirkung, Metakognition

Entwurf und Endprodukt vergleichen

Arbeitsauftrag:

Bearbeite die Aufgabe „Entwurf und Endprodukt vergleichen“ anhand der folgenden Vorgaben:

Die Lehrkraft fordert die Schülerinnen und Schüler auf, zu einem kleinen Softwareprodukt sowohl den ersten Entwurf als auch die fertige oder halbfertige Version bereitzuhalten. In Partnerarbeit vergleichen sie beide Stände und markieren Übereinstimmungen, Änderungen und neu hinzugekommene Funktionen. Danach besprechen sie, warum manche Ideen im Verlauf verworfen, vereinfacht oder umgebaut wurden.

Hinweise aus der Aufgabe

• Entwurf, Produkt
• Vergleich, Änderung
• Idee, Anpassung
• Funktion, Erweiterung
• Produkte, Vergleichsblatt
• Wirkung, Planverständnis

Testen vor dem Debuggen

Arbeitsauftrag:

Bearbeite die Aufgabe „Testen vor dem Debuggen“ anhand der folgenden Vorgaben:

Die Schülerinnen und Schüler erhalten ein kleines Programm, ein Scratch-Projekt oder einen Prototyp mit eingebauten Fehlern. Bevor sie Änderungen vornehmen dürfen, müssen sie zuerst formulieren, welche Funktion erwartet wird und welche Testfälle sinnvoll sind. Danach führen sie die Tests durch, dokumentieren Abweichungen und beginnen erst anschließend mit der Fehlersuche. In der Auswertung vergleichen sie, wie sich die Qualität der Fehlersuche verändert, wenn vorher geplant getestet wurde.

Hinweise aus der Aufgabe

• Funktion, Erwartung
• Testfall, Prüfung
• Fehler, Abweichung
• Suche, Korrektur
• Produkte, Testprotokoll
• Wirkung, Qualitätssinn

Rollenrückblick im Team

Arbeitsauftrag:

Bearbeite die Aufgabe „Rollenrückblick im Team“ anhand der folgenden Vorgaben:

Nach einer Teamarbeitsphase reflektieren die Schülerinnen und Schüler, welche Rollen sie übernommen haben, etwa Planung, Umsetzung, Test, Dokumentation oder Moderation. Sie notieren, welche Aufgaben gut verteilt waren, wo Unklarheiten bestanden und welche Rolle im Projektverlauf zu stark oder zu wenig vertreten war. Anschließend besprechen sie, wie sich diese Verteilung auf Zeit, Qualität und Arbeitsklima ausgewirkt hat. Die Aufgabe ist besonders lernstark, weil Projektreflexion nicht nur technische, sondern auch soziale und organisatorische Aspekte einschließt.

Hinweise aus der Aufgabe

• Rollen, Planung
• Rollen, Test
• Rollen, Doku
• Klarheit, Abstimmung
• Produkte, Rückblick
• Wirkung, Teamlernen

Zwei Entwicklungswege vergleichen

Arbeitsauftrag:

Bearbeite die Aufgabe „Zwei Entwicklungswege vergleichen“ anhand der folgenden Vorgaben:

Die Lehrkraft gibt zwei kurze Projektbeschreibungen vor. Ein Weg arbeitet eher linear mit klaren Phasen, der andere entwickelt eine Minimalversion und verbessert diese in mehreren Schleifen. Die Schülerinnen und Schüler vergleichen beide Wege hinsichtlich Übersicht, Fehlersuche, Motivation, Flexibilität und Zeitnutzung. Danach ordnen sie konkrete Projektsituationen zu, in denen der eine oder der andere Ansatz günstiger wäre.

Hinweise aus der Aufgabe

• Wege, linear
• Wege, iterativ
• Vergleich, Flexibilität
• Vergleich, Übersicht
• Produkte, Zuordnung
• Wirkung, Methodenverständnis

Retrospektive nach Mini-Projekt

Arbeitsauftrag:

Bearbeite die Aufgabe „Retrospektive nach Mini-Projekt“ anhand der folgenden Vorgaben:

Die Klasse führt ein kleines Softwareprojekt oder einen Entwicklungsabschnitt durch, etwa eine Scratch-Erweiterung, ein Formular oder eine kleine Programmfunktion. Danach bearbeiten die Gruppen eine Retrospektive mit Leitfragen: Was wollten wir erreichen, was haben wir geschafft, was hat uns gebremst, was hat gut funktioniert, was ändern wir beim nächsten Mal? Die Ergebnisse werden kurz visualisiert und vorgestellt.

Hinweise aus der Aufgabe

• Rückblick, Ziel
• Erfolg, Hindernis
• Änderung, Nächstes
• Team, Erfahrung
• Produkte, Retrospektive
• Wirkung, Prozesslernen

Entwicklungsprozess präsentieren

Arbeitsauftrag:

Bearbeite die Aufgabe „Entwicklungsprozess präsentieren“ anhand der folgenden Vorgaben:

Die Schülerinnen und Schüler bereiten zu einem eigenen oder vorgegebenen Projekt eine kurze Prozesspräsentation vor. Diese enthält Ausgangsidee, Anforderungsauswahl, Entwurf, Umsetzung, Testschritte, Fehlerkorrekturen und abschließende Reflexion. Die Zuhörenden stellen Rückfragen, etwa warum eine Funktion priorisiert wurde, weshalb ein Fehler spät entdeckt wurde oder welche Verbesserung für ein Folgeprojekt geplant wäre.

Hinweise aus der Aufgabe

• Idee, Planung
• Entwurf, Umsetzung
• Test, Fehler
• Korrektur, Reflexion
• Produkte, Präsentation
• Wirkung, Gesamtverständnis

Kompetenzcheck

Überprüfe am Ende selbst, ob du die zentralen Kompetenzen dieses Kapitels sicher anwenden kannst:

Ich kann …	Ja	Noch üben
die typischen Schritte der Softwareentwicklung in eine sinnvolle Reihenfolge bringen und ihre Funktion erklären.	☐	☐
Zielklärung und Anforderungsanalyse als Grundlage späterer Entwicklungsentscheidungen beurteilen.	☐	☐
Entwurf und Modellierung mit dem späteren Endprodukt vergleichen und Unterschiede begründen.	☐	☐
Umsetzung, Testen und Debuggen als getrennte, aber eng verbundene Phasen beschreiben.	☐	☐
Zusammenarbeit und Rollen im Entwicklungsprozess reflektieren sowie lineare und iterative Vorgehensweisen vergleichen.	☐	☐
Dokumentation und Rückblick nutzen, um einen Entwicklungsprozess nachvollziehbar zu erklären und Verbesserungspotenziale zu benennen.	☐	☐