Informatik 8: Die Schritte der Softwareentwicklung
16.1 Lernziele
- 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
16.2 Lerninhalte
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.
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. Im didaktischen Skriptum wird betont, dass Programmierunterricht von Algorithmen ausgeht und diese entworfen, dargestellt, implementiert und getestet werden sollen. 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.
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.
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? Das Skriptum nennt genau solche
vorbereitenden Schritte, etwa Skizzen, Schaltpläne, das Bestimmen von Ein- und Ausgängen sowie das Schritt-für-Schritt-Beschreiben der Programmlogik.
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
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.
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.
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. Das Skriptum beschreibt dabei die Rollen Driver und Navigator, den vorherigen Austausch über die Vorgehensweise und den regelmäßigen Rollenwechsel. 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.
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
Lineare und projektorientierte Lernwege 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. Das Skriptum beschreibt ein Spannungsfeld zwischen einem Top-down-Entwicklungsprozess, der von Algorithmen und Projekten ausgeht, und Bottom-up-Lernpfaden, bei denen zunächst Code-Fragmente schrittweise aufgebaut werden. 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.
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? Die Unterrichtsmodelle im didaktischen Skriptum enthalten mit „Auswerten“, „Kontrolle“ und „Anwenden“ ausdrücklich Phasen, in denen Ergebnisse und Prozesse rückblickend betrachtet und verbessert werden. Auch in den Informatik-Beispielen wird praktische Übung mit anschließender Diskussion und Reflexion verbunden.
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
16.3 Weiterführende Links
- BMBWF, Lehrpläne, Digitale Grundbildung
- Scrum Guides, Scrum Guide, Deutsch
- Scratch, Learning Library, Projekte
- GitHub Education, Foundations, Projektmanagement
16.4 Aufgaben für den Unterricht
16.4.1 Entwicklungsweg rekonstruieren
Diese Aufgabe stärkt Prozessverständnis besonders wirksam, weil die Lernenden einen fertigen oder halbfertigen Softwareentwurf rückwärts analysieren und dadurch erkennen, welche Entwicklungsschritte vor dem sichtbaren Endprodukt notwendig gewesen sein müssen. 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. Der hohe Lerneffekt entsteht, weil der Entwicklungsprozess aus dem Produkt heraus sichtbar gemacht wird.
- Produkt, Analyse
- Schritte, Reihenfolge
- Ziel, Entwurf
- Test, Verbesserung
- Produkte, Ablaufplan
- Wirkung, Prozessblick
16.4.2 Phasenkarten richtig ordnen
Diese Aufgabe macht die Abfolge der Softwareentwicklung besonders verständlich, weil die Lernenden typische Entwicklungsschritte in eine logische Struktur bringen und dabei direkt erkennen, wie Planung, Umsetzung und Überprüfung zusammenhängen. 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. Diese Aufgabe ist besonders lernwirksam, weil sie lineare Reihenfolge und iterative Schleifen gemeinsam sichtbar macht.
- Karten, Phasen
- Ordnung, Ablauf
- Handlung, Ergebnis
- Rücksprung, Schleife
- Produkte, Phasenmodell
- Wirkung, Überblick
16.4.3 Was lief schief?
Diese Aufgabe fördert reflektiertes Denken besonders nachhaltig, weil die Lernenden typische Projektprobleme nicht nur benennen, sondern auf bestimmte Entwicklungsschritte zurückführen und dadurch den Sinn früher Planung, Tests und klarer Anforderungen besser verstehen. 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. Der hohe Lerneffekt entsteht, weil aus typischen Schwierigkeiten klare Einsichten über die Bedeutung einzelner Phasen gewonnen werden.
- Probleme, Szene
- Ursache, Phase
- Fehler, Entscheidung
- Lösung, Verbesserung
- Produkte, Zuordnung
- Wirkung, Einsicht
16.4.4 Entwicklungsjournal auswerten
Diese Aufgabe vertieft Reflexionskompetenz besonders wirksam, weil die Lernenden ihren eigenen Arbeitsprozess dokumentieren und anschließend daraus ableiten, welche Schritte hilfreich waren, wo sie Zeit verloren haben und welche Vorgehensweise sie künftig verbessern
möchten. 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.
- Journal, Notizen
- Ziel, Problem
- Test, Änderung
- Rückblick, Erkenntnis
- Produkte, Reflexion
- Wirkung, Metakognition
16.4.5 Entwurf und Endprodukt vergleichen
Diese Aufgabe macht die Bedeutung des Entwurfs besonders deutlich, weil die Lernenden frühe Skizzen, Ablaufdiagramme oder Funktionslisten mit dem späteren Produkt vergleichen und dadurch erkennen, welche Planungsentscheidungen tragfähig waren und welche angepasst werden mussten. 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. Der hohe Lerneffekt entsteht, weil Planung nicht als starres Schema erscheint, sondern als hilfreiche, aber veränderbare Grundlage der Entwicklung.
- Entwurf, Produkt
- Vergleich, Änderung
- Idee, Anpassung
- Funktion, Erweiterung
- Produkte, Vergleichsblatt
- Wirkung, Planverständnis
16.4.6 Testen vor dem Debuggen
Diese Aufgabe stärkt Qualitätsbewusstsein besonders erfolgreich, weil die Lernenden erkennen, dass Fehlersuche nur dann gezielt möglich ist, wenn vorher klar festgelegt wurde, was eine Funktion eigentlich leisten soll und wie sie überprüft werden kann. 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. Diese Aufgabe ist besonders lernwirksam, weil Testen als eigenständiger Entwicklungsschritt gestärkt wird.
- Funktion, Erwartung
- Testfall, Prüfung
- Fehler, Abweichung
- Suche, Korrektur
- Produkte, Testprotokoll
- Wirkung, Qualitätssinn
16.4.7 Rollenrückblick im Team
Diese Aufgabe fördert Zusammenarbeit und Prozessreflexion besonders wirksam, weil die Lernenden ihre Rollen im Projekt bewusst auswerten und dadurch erkennen, wie stark klare Zuständigkeiten, Kommunikation und Rollenwechsel die Qualität eines Entwicklungsprozesses beeinflussen. 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.
- Rollen, Planung
- Rollen, Test
- Rollen, Doku
- Klarheit, Abstimmung
- Produkte, Rückblick
- Wirkung, Teamlernen
16.4.8 Zwei Entwicklungswege vergleichen
Diese Aufgabe vertieft das Verständnis für unterschiedliche Vorgehensweisen besonders nachhaltig, weil die Lernenden zwei Entwicklungswege gegenüberstellen und daraus ableiten, wann ein eher linearer oder ein eher iterativer Ansatz sinnvoll sein kann. 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. Der hohe Lerneffekt entsteht, weil Entwicklungsschritte nicht nur als Reihenfolge, sondern als
methodische Entscheidung verstanden werden.
- Wege, linear
- Wege, iterativ
- Vergleich, Flexibilität
- Vergleich, Übersicht
- Produkte, Zuordnung
- Wirkung, Methodenverständnis
16.4.9 Retrospektive nach Mini-Projekt
Diese Aufgabe macht Reflexion als festen Schritt der Softwareentwicklung besonders greifbar, weil die Lernenden nach einer abgeschlossenen Arbeitsphase gezielt auf Ablauf, Ergebnisse und Zusammenarbeit zurückblicken und daraus konkrete Verbesserungen für den nächsten Zyklus ableiten. 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. Diese Aufgabe ist besonders lernwirksam, weil Reflexion nicht als Zusatz, sondern als regulärer Projektschritt erfahren wird.
- Rückblick, Ziel
- Erfolg, Hindernis
- Änderung, Nächstes
- Team, Erfahrung
- Produkte, Retrospektive
- Wirkung, Prozesslernen
16.4.10 Entwicklungsprozess präsentieren
Diese Aufgabe verbindet Fachsprache, Rückblick und Bewertung besonders erfolgreich, weil die Lernenden nicht nur ihr Endprodukt zeigen, sondern den gesamten Entwicklungsweg mit Phasen, Entscheidungen, Tests und Verbesserungen nachvollziehbar erläutern müssen. 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. Der hohe Lerneffekt entsteht, weil die Schritte der Softwareentwicklung sprachlich geordnet, fachlich begründet und aus verschiedenen Blickwinkeln reflektiert werden.
- Idee, Planung
- Entwurf, Umsetzung
- Test, Fehler
- Korrektur, Reflexion
- Produkte, Präsentation
- Wirkung, Gesamtverständnis
Ich ergänze jetzt noch passende offizielle Weiterführungsangebote zu Entwicklungsumgebungen und Lernplattformen, damit Kapitel 17 direkt einsetzbar bleibt.
Grundlage: Informatik – Lehrband 8. Klasse, Final V1.2 (2026).