E4 – Informatikprojekt

Curriculare Leitidee des Themenfelds E.4

E.4 bündelt Projektaufgaben aus den Themenfeldern 1–3 und macht Informatik als kooperativen Entwicklungsprozess sichtbar: Fachwissen wird in gemeinsame, planbare Arbeit überführt.

• Arbeitsteilung und Rollenklärung im Team
• Prozesse, Absprachen und verlässliche Termine
• Einhalten von Vereinbarungen und Qualitätskriterien
• Zusammenführen von Teilergebnissen zu einem Produkt
• Beachtung von Datenschutz und Urheberrecht

Didaktisch bedeutet E4: Die Inhalte aus E1 bis E3 werden in Projektentscheidungen übersetzt, aber nicht technisch künstlich verschmolzen. Der Website-Pfad baut auf E1 und E2 auf: Webressourcen müssen erreichbar, sinnvoll verlinkt, strukturiert, gestaltet und rechtlich sauber eingebunden sein. Der Programmierpfad baut auf E3 auf: Eingaben, Verarbeitung, Ausgaben, Methoden, Testfälle und Fehlerbehandlung müssen geplant und überprüft werden.

Projektarbeit heißt hier deshalb nicht nur "etwas bauen", sondern Entscheidungen begründen: Wie organisiert ihr Arbeit? Wie prüft ihr Qualität? Wie führt ihr Ergebnisse zusammen? Genau dafür braucht ihr eine bewusste Wahl des Vorgehensmodells.

Ein Informatikprojekt ist ein zeitlich begrenztes Vorhaben mit einem klaren Ziel, das durch Arbeitsteilung zu einem überprüfbaren Ergebnisprodukt führt.

Kennzeichnend sind eine gemeinsame Zieldefinition, verbindliche Zuständigkeiten, koordiniertes Vorgehen und nachvollziehbare Qualitätskriterien.

Typische Merkmale eines Informatikprojekts in E4:

• Planung und Zieldefinition
• Arbeitsteilung in Teilaufgaben
• Test und Qualitätssicherung
• Dokumentation, Präsentation und Reflexion

Softwareprojekte sind oft unsicher: Anforderungen sind anfangs unvollständig, Rahmenbedingungen ändern sich, Zeit ist begrenzt und mehrere Personen arbeiten gleichzeitig an abhängigen Aufgaben. Ohne gemeinsame Struktur entstehen schnell Missverständnisse, Doppelarbeit und unklare Verantwortlichkeiten.

Ein Vorgehensmodell beantwortet zentrale Projektfragen: Was klären wir zuerst? Wann testen wir? Wer entscheidet über Änderungen? Wann holen wir Feedback ein? Wie machen wir Zwischenergebnisse für das Team sichtbar?

Vorgehensmodelle sind dabei keine Dogmen. Sie sind Orientierungs- und Auswahlmodelle: Ihr nutzt sie, um euer Projektproblem passgenau zu strukturieren, statt ein Modell starr "durchzuziehen".

Nachdem geklärt ist, warum Informatikprojekte Struktur brauchen, vergleicht ihr im nächsten Schritt unterschiedliche Vorgehensmodelle als Antworten auf unterschiedliche Projektsituationen.

Vorgehensmodelle sind keine konkurrierenden Wahrheiten, sondern Antworten auf unterschiedliche Projektsituationen. Ein Projekt mit stabilen Anforderungen, viel Erfahrung, klaren Übergaben und hohem Dokumentationsbedarf braucht eine andere Struktur als ein Lernprojekt, in dem Ideen erst während der Umsetzung klarer werden. Deshalb ist die Leitfrage nicht, welches Modell grundsätzlich überlegen ist, sondern welches Verhältnis von Planung, Qualitätssicherung, Feedback und Anpassung ein konkretes Projekt benötigt.

Die Entwicklungslinie lässt sich als Bewegung zwischen Planbarkeit und Veränderungsfähigkeit lesen. Klassische Modelle schaffen zunächst Ordnung: Sie teilen Arbeit in Phasen, Übergaben und Meilensteine. Das V-Modell ergänzt diese Ordnung um eine systematische Testperspektive. Agile Modelle wie Scrum verschieben den Schwerpunkt auf kurze Arbeitszyklen, sichtbare Zwischenstände und regelmäßiges Feedback. In der Praxis entstehen daraus häufig hybride Vorgehensweisen: außen ein verlässlicher Rahmen, innen iterative Sprintarbeit.

Die folgende Übersicht dient deshalb nicht als starres Bewertungsschema, sondern als Orientierung. Unterschiedliche Modelle passen zu unterschiedlichen Planungsfaktoren. Für E4 ist besonders wichtig, welche Idee ihr aus dem jeweiligen Modell für eure Projektarbeit übernehmen könnt.

Wasserfallmodell

Das Wasserfallmodell steht für eine lineare Sicht auf Projektarbeit. Zuerst werden Anforderungen geklärt, danach wird entworfen und umgesetzt, anschließend getestet und abgenommen. Diese Reihenfolge wirkt streng, hat aber einen nachvollziehbaren Kern: Wenn ein Projektziel früh stabil ist, viele Beteiligte koordiniert werden müssen und Übergaben dokumentiert sein sollen, schafft ein solcher Ablauf Orientierung. In großen Organisationen, bei gut bekannten Implementationsprojekten oder in Kontexten mit viel Erfahrung kann diese Planungslogik sinnvoll sein, weil sie Verantwortlichkeiten, Meilensteine und Abnahmen früh sichtbar macht.

Gerade diese Stärke ist aber auch die Grenze des Modells. Je später ein Fehler, ein Missverständnis oder eine veränderte Anforderung sichtbar wird, desto aufwendiger wird die Korrektur. Für offene Lern- und Entwicklungsprojekte ist ein reiner Wasserfall deshalb meist zu starr. Für E4 bleibt er dennoch wichtig: Er zeigt, warum ein Projekt nicht einfach mit Programmieren beginnt, sondern zunächst Ziele, Anforderungen, Aufgaben und Übergaben klären muss. Das Wasserfallmodell liefert also weniger den vollständigen Ablauf für euer Projekt als vielmehr die Einsicht, dass gute Entwicklung einen verlässlichen Planungsrahmen braucht.

V-Modell

Das V-Modell entwickelt die klassische Planungslogik weiter, indem es Entwicklung und Prüfung systematisch aufeinander bezieht. Jede Ebene der Entwicklung erhält eine passende Test- oder Abnahmeebene: Anforderungen müssen später überprüfbar sein, Entwürfe müssen sich gegen das geplante System prüfen lassen, und Implementierungen müssen getestet werden. Dadurch verschiebt sich der Blick von der bloßen Reihenfolge der Arbeit zur Frage, wie Qualität früh mitgedacht werden kann.

Besonders sinnvoll ist diese Perspektive dort, wo Systeme zuverlässig, nachvollziehbar und testbar sein müssen. Bei größeren Softwareprojekten, sicherheitskritischen Anwendungen oder Projekten mit festen Abnahmekriterien reicht es nicht, am Ende einmal zu prüfen, ob alles funktioniert. Schon beim Planen muss klar sein, woran das Ergebnis später gemessen wird. Für kleine Unterrichtsteams wäre ein vollständiges V-Modell allerdings schnell zu formal. Für E4 ist deshalb nicht die gesamte Form entscheidend, sondern der Grundgedanke: Wer entwickelt, muss von Anfang an überlegen, wie Anforderungen, Zwischenergebnisse und fertige Funktionen geprüft werden können.

Wasserfallmodell und V-Modell machen zwei wichtige Dinge sichtbar: Entwicklung braucht Planung, und Qualität muss überprüfbar sein. Viele Informatikprojekte zeigen jedoch, dass diese beiden Einsichten allein nicht ausreichen. Anforderungen sind oft nicht vollständig bekannt, Nutzerinnen und Nutzer verstehen erst an einem Zwischenstand, was sie wirklich brauchen, und technische Probleme werden erst beim Umsetzen sichtbar. An dieser Stelle werden agile Vorgehensweisen wichtig.

Agile Vorgehensmodelle

Agile Vorgehensmodelle reagieren auf die Erfahrung, dass Softwareentwicklung selten vollständig vorausgeplant werden kann. Statt das gesamte Produkt zuerst vollständig zu entwerfen und erst am Ende zu prüfen, wird in kurzen Abschnitten gearbeitet. In jedem Abschnitt entsteht ein nutzbarer Zwischenstand, der bewertet, verbessert und weiterentwickelt werden kann. Diese iterative Arbeitsweise ist für die Informatik besonders typisch: Programme, Webseiten, Datenmodelle oder Benutzeroberflächen werden entworfen, ausprobiert, getestet, verändert und erneut geprüft.

Scrum als Sprintzyklus

Scrum ist ein bekanntes Beispiel für diese Denkweise. Anforderungen und Ideen werden in einem Product Backlog gesammelt und priorisiert. Für einen Sprint wählt das Team einen realistischen Ausschnitt aus, formuliert ein klares Sprintziel und bearbeitet die Aufgaben in einem festen Arbeitsintervall. Kurze Abstimmungen, etwa als Daily, halten Hindernisse sichtbar. Am Ende wird im Review betrachtet, was entstanden ist; in der Retrospektive wird die Zusammenarbeit verbessert. Scrum ist damit nicht einfach flexibles Arbeiten, sondern eine disziplinierte Form iterativer Entwicklung.

Für schulische Projekte ist diese Logik gut anschlussfähig, weil Lernen und Entwickeln zusammenfallen. Ihr müsst nicht zu Beginn jedes Detail kennen, sondern könnt Zwischenergebnisse nutzen, um Entscheidungen zu verbessern. Gleichzeitig verlangt Scrum klare Sprintziele, sichtbare Aufgaben, verbindliche Zuständigkeiten und regelmäßige Reflexion; ohne diese Disziplin wird Agilität schnell beliebig. Extreme Programming (XP) betont ergänzend Entwicklungsdisziplinen wie häufiges Testen, kleine Releases und enge Teamkommunikation. Für E4 ist Scrum deshalb vor allem als Arbeitsrhythmus wichtig: planen, umsetzen, prüfen, reflektieren und im nächsten Sprint gezielter weiterarbeiten.

Hybrides Vorgehen als realistische Projektpraxis

In der Praxis stehen klassische und agile Vorgehensweisen selten als reine Alternativen nebeneinander. Große Projekte brauchen häufig einen äußeren Rahmen: Termine, Verantwortlichkeiten, Dokumentation, Qualitätskriterien und Abnahmepunkte müssen geklärt sein. Gleichzeitig entsteht die konkrete Lösung oft iterativ. Teams arbeiten an Teilfunktionen, testen Zwischenergebnisse, reagieren auf Feedback und passen Entscheidungen an. Hybrides Arbeiten verbindet deshalb Planbarkeit und Veränderungsfähigkeit.

Genau diese Verbindung ist für E4 besonders geeignet. Der Kurs gibt einen verbindlichen Rahmen vor: Ihr habt eine begrenzte Zeit, ein gemeinsames Projektziel, Rollen, Aufgaben, Qualitätsanforderungen und einen Präsentations- oder Abgabezeitpunkt. Innerhalb dieses Rahmens arbeitet ihr jedoch nicht starr linear, sondern in Sprints. Ihr formuliert ein Sprintziel, bearbeitet Aufgaben, testet Zwischenergebnisse, dokumentiert den Fortschritt und reflektiert die Zusammenarbeit. So entsteht eine schulische Form realitätsnaher Projektarbeit: nicht reiner Wasserfall, nicht reines Scrum, sondern ein hybrider Entwicklungsprozess.

Nach der Einordnung des Vorgehensmodells entscheidet ihr im nächsten Schritt, welches Produkt ihr entwickelt. Die Projektpfade unterscheiden den fachlichen Anwendungsraum, nicht das Vorgehensmodell.

Die Projektpfade unterscheiden nicht einfach Oberfläche und Verarbeitung. Beide Pfade enthalten Oberfläche, Eingabe, Verarbeitung und Ausgabe. Im Website-Pfad steht jedoch die Weboberfläche als strukturierte Dokument- und Nutzungsoberfläche im Vordergrund; Verarbeitung bleibt formularnah, einfach und ohne explizite JavaScript- oder Backend-Vertiefung. Im Programmierpfad steht die Verarbeitung stärker im Vordergrund: Eingaben werden gelesen, Zustände verändert, Methoden aufgerufen, Kontrollstrukturen genutzt, Datenstrukturen ausgewertet und Ausgaben über Konsole oder GUI sichtbar gemacht.

Die Matrix liefert den kompakten Vergleich der beiden Hauptpfade; die folgenden Kurzprofile konkretisieren typische Ziele, Qualitätsaspekte und Grenzen für die Umsetzung.

Website-/HTML-Projekt

Ein Website-Projekt ist mehr als eine Sammlung gestalteter Seiten. Aus E1 übernehmt ihr die Frage, wie Webressourcen über Browser, Pfade, Links und Dateien erreichbar werden. Aus E2 übernehmt ihr die strukturierte Oberfläche: Überschriften, Abschnitte, Navigation, Medien, CSS-Gestaltung, Quellen, Barrierearmut und gegebenenfalls Formulare als sichtbare Eingabestruktur. Die eigentliche Verarbeitung solcher Eingaben ist in E4 jedoch kein Pflichtziel.

Im Sprint-Werkzeug tragt ihr das anschließend als Tickets ein, zum Beispiel: Seitenstruktur anlegen, Navigation testen, Ressourcenpfade prüfen, Medien einbinden, Formularbereiche strukturieren, Quellen und Bildrechte kontrollieren, alt-Texte ergänzen und Benutzerführung im Review bewerten.

Java-/Programmierprojekt

Ein Programmierprojekt ist mehr als ein funktionierender Codeblock. Aus E3 übernehmt ihr die EVA-Logik: Eingaben werden gelesen, verarbeitet und als Ausgabe sichtbar gemacht. Methoden, Kontrollstrukturen, Datenstrukturen, Testfälle und Fehlerbehandlung werden so geplant, dass die Wirkung des Programms nachvollziehbar und prüfbar bleibt. Eine GUI kann dabei als programmierte Interaktionsoberfläche dienen; sie ist aber eine andere Art von Oberfläche als die HTML-Dokumentoberfläche aus E2.

Im Sprint-Werkzeug formuliert ihr dazu konkrete Tickets, etwa: Methoden planen, Programmlogik implementieren, Eingaben prüfen, GUI-Zustände abstimmen, Testfälle dokumentieren, Ausgabeverhalten kontrollieren und Fehler gezielt beheben.

Ausblick: spätere Verbindung von Weboberfläche, Verarbeitung und Daten

Die Verbindung von Weboberfläche, Auswertungslogik und gespeicherten Daten wird in E4 bewusst nicht als Pflichtprojekt verlangt. In E2 erscheinen Formulare zunächst als strukturierte Eingabeelemente einer Webseite; in E3 erscheinen GUI-Elemente als programmierte Komponenten mit Ereignissen und Zuständen. Erst später, besonders im Webdatenbankprojekt, werden diese Ebenen technisch verbunden: HTML/CSS für die Oberfläche, JavaScript oder PHP für Verarbeitung und Kommunikation, Datenbanken für persistente Speicherung.

Q1/Q2-Anschluss der Projektpfade

• Website-Projekte (E1 → E2 → E4): bereiten besonders spätere Web-, Datenbank- und Q2-Kontexte vor, weil Seitenstruktur, Pfade, Ressourcen, Formulare und Nutzungsführung dort fachlich weitergeführt werden.
• Programmierprojekte (E3 → E4): bereiten besonders Q1 vor, vor allem objektorientierte Modellierung, Algorithmik, Rekursion, Datenstrukturen und systematische Testarbeit.
• Ausblick auf spätere Schichtenintegration: Die technische Verbindung von Oberfläche, expliziter Verarbeitung und Datenhaltung folgt später; sie ist in E4 Orientierung, aber kein Projektziel.

Nachdem Produktpfad und Ziel geklärt sind, organisiert ihr die konkrete Arbeit im Sprintplanungswerkzeug. Das Werkzeug bildet die hybride Logik aus Kapitel 2 praktisch ab. Außen hält es den Rahmen fest: Projekt / Vorhaben, Projektgruppe, Rollen, Zeitplan und Qualitätskriterien. Innen organisiert es die Sprintarbeit: Sprintziel formulieren, Aufgaben/Tickets planen, Zuständigkeiten über Arbeitskürzel klären, Status pflegen, Zwischenergebnisse prüfen, Sprint-Rückblick nutzen und den nächsten Sprint anpassen.

Dabei gilt: E4 ist nicht "reines Scrum". Unterricht setzt feste Rahmenbedingungen, Termine, Bewertungsanforderungen und Reflexionspflichten. Innerhalb dieses Rahmens arbeitet ihr iterativ: Ihr formuliert ein Sprintziel, bearbeitet Aufgaben/Tickets, prüft Zwischenergebnisse, dokumentiert Entscheidungen und nutzt den Sprint-Rückblick für die nächste Arbeitsphase.

Projektzeitplan als Gantt-Diagramm

Das Gantt-Diagramm gibt in E4 den Überblick über Zeiträume, Abhängigkeiten und verantwortliche Arbeitskürzel. Es ersetzt aber nicht die Sprintarbeit: Die Detailpflege zu Aufgaben/Tickets, Status und Notizen geschieht im Sprintbereich des Werkzeugs, wo ihr die konkrete Entwicklung fortschreibt.

So wird aus der hybriden Idee ein praktischer Arbeitsfluss: Der äußere Rahmen gibt Orientierung, während die Sprintarbeit Schritt für Schritt sichtbar macht, was schon erreicht ist, was blockiert und was im nächsten Durchlauf besser geplant werden muss.

Organisationselemente

Organisation beginnt mit Arbeitskürzeln, Rollen und Aufgabenverteilung. Jedes Arbeitskürzel macht sichtbar, wer gerade koordiniert, umsetzt, testet oder dokumentiert; Rollen beschreiben dabei die Funktion im Projekt, nicht den Wert einzelner Beiträge.

Während eines Sprints halten Status und Aufgaben/Tickets den Arbeitsstand transparent. Nicht begonnen, in Arbeit, blockiert oder erledigt sind keine Bewertungen, sondern Hinweise darauf, wo die Projektgruppe abstimmen, unterstützen oder umplanen muss.

Review / Ergebnisvorstellung, Sprint-Rückblick, Test und Dokumentation schließen den Arbeitsabschnitt ab. Ihr zeigt Ergebnisse, wertet Rückmeldungen aus, prüft mit Testfällen und haltet Entscheidungen fest, damit der nächste Sprint gezielter startet.

Ablauf eines Sprints/Projektzyklus

In diesem Abschnitt klärt ihr also nicht nur Begriffe, sondern überführt Planung direkt in Handeln: im gemeinsamen Session-Code, mit transparenten Aufgaben/Tickets und mit regelmäßigen Sprint-Rückblicken auf den Arbeitsprozess.

Verbindliche Reflexionsfragen

Reflexion ist dabei nicht nur eine Bewertung am Ende, sondern ein Steuerungsinstrument für den nächsten Sprint. Die drei Sprint-Rückblickfelder aus dem Sprint-Werkzeug helfen euch, Verbesserungen unmittelbar in den folgenden Arbeitszyklus zu übernehmen.

Die Reflexion bezieht sich deshalb nicht nur auf Zusammenarbeit, sondern auch auf die fachliche Tragfähigkeit des gewählten Pfads: War das Website-Produkt erreichbar, gut strukturiert und nachvollziehbar gestaltet? War das Programmprodukt funktional, testbar und in seiner Verarbeitung erklärbar? Erst diese Verbindung aus Produktqualität, Prozessqualität und fachlicher Begründung macht E4 zu einem Informatikprojekt.

• Was lief gut? Welche Arbeitsweisen oder Absprachen solltet ihr beibehalten?
• Was war schwierig? Wo gab es Hindernisse, unklare Zuständigkeiten oder Zeitprobleme?
• Was nehmen wir in den nächsten Sprint mit? Welche konkrete Anpassung setzt ihr direkt um?

• Datenschutz: Welche personenbezogenen Daten werden erhoben, und ist das für den Zweck notwendig?
• Urheberrecht: Sind Medien, Texte, Icons und Codebeispiele rechtlich sauber genutzt und korrekt belegt?
• Verantwortliche Gestaltung: Ist das Produkt verständlich, fair, zugänglich und ohne irreführende Elemente gestaltet?

Nicht-Ziele in E4

• Kein JavaScript-Neueinstieg als Pflichtbestandteil.
• Keine echte Web-App-Auswertungslogik im Browser als Mindestanforderung.
• Kein Backend, keine Datenbank, keine PHP-Integration als Pflicht.
• Keine künstliche technische Integration von Java und HTML.
• Kein Brückenpfad als Pflicht- oder Hauptpfad; höchstens ein Ausblick auf spätere Webdatenbank- und Dynamik-Kontexte.

Am Ende wird sichtbar: E4 verlangt nicht nur ein fertiges Produkt, sondern einen nachvollziehbaren Projektprozess mit Planung, Umsetzung, Test, Dokumentation, Präsentation und Sprint-Rückblick.