E4 – Informatikprojekt

Curriculare Leitidee des Themenfelds E.4

E.4 bündelt Projektaufgaben aus den Themenfeldern 1–3 und macht die Arbeitsweise der Informatik als kooperativen Entwicklungsprozess sichtbar.

• 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 das: Die Lernenden wechseln von isolierten Einzeltechniken (Internetgrundlagen, HTML-Strukturen, Programmierung) zu einer integrierten Projektpraxis mit Planungs-, Kommunikations- und Reflexionsanteilen.

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

Im Übergang von E1–E3 zu E4 werden technische Kompetenzen zusammengeführt: Aus Kenntnissen zu Internet und Webstruktur (E1/E2) sowie Programmierung (E3) entsteht eine strukturierte Teamarbeit.

Die Projektarbeit in E4 folgt dabei vier zusammenhängenden Bausteinen:

• Planung und Zieldefinition
• Umsetzung in Teilaufgaben
• Test und Qualitätssicherung
• Dokumentation und Präsentation

Softwareprojekte sind durch wechselnde Anforderungen, begrenzte Zeit, verschiedene Rollen und Qualitätsansprüche geprägt. Ohne gemeinsame Struktur entstehen leicht Missverständnisse, Doppelarbeit oder unklare Verantwortlichkeiten.

Vorgehensmodelle beschreiben, wie Teams Aufgaben ordnen, Kommunikation organisieren und Ergebnisse schrittweise absichern. Sie sind keine starren Dogmen, sondern Orientierungsrahmen, die an Projektkontext und Teamgröße angepasst werden.

Wasserfallmodell

Grundidee: Das Projekt wird in aufeinanderfolgende Phasen gegliedert (z. B. Analyse, Entwurf, Umsetzung, Test).

Typische Stärken: Hohe Planbarkeit, klare Dokumentation, eindeutige Meilensteine.

Typische Grenzen: Änderungen sind spät und mit Aufwand integrierbar; Feedback aus der Nutzung kommt oft erst am Ende.

V-Modell

Grundidee: Entwicklungsphasen werden systematisch mit zugehörigen Testphasen verbunden.

Typische Stärken: Qualitätsorientierung von Beginn an, frühe Testplanung, hohe Nachvollziehbarkeit.

Typische Grenzen: Kann bei kleinen Teams formal überladen wirken; schnelle Richtungswechsel sind begrenzt.

Agile Modelle arbeiten iterativ: In kurzen Zeitabschnitten entstehen nutzbare Zwischenstände, die mit Feedback überprüft und verbessert werden.

Scrum in Kurzform

• Sprint: festes Arbeitsintervall (Time-Box) mit klarem Ziel
• Product Backlog: priorisierte Liste der Anforderungen
• Daily: kurzes tägliches Abstimmungsformat
• Review: Vorstellung und Rückmeldung zum Ergebnisinkrement
• Retrospektive: Reflexion und Verbesserung der Zusammenarbeit

Extreme Programming (XP) ergänzt diesen Fokus unter anderem durch praktische Entwicklungsdisziplinen wie häufiges Testen, kleine Releases und enge Teamkommunikation.

Die zentrale Praxiserkenntnis lautet: Reale Softwareprojekte verlaufen häufig hybrid. Sie verbinden planungsorientierte Elemente (z. B. Meilensteine, Rollen, Dokumentation) mit agilen Arbeitsformen (z. B. kurze Iterationen, Reviews, Ticket-Boards).

So bleiben Verlässlichkeit und Flexibilität gleichzeitig erreichbar: Struktur gibt Orientierung, Iteration ermöglicht ein nutzbares Inkrement.

In E4 arbeitet ihr wie ein kleines Entwicklungsteam: Jede Person übernimmt eine klare Rolle, zum Beispiel Koordination, Umsetzung, Test oder Dokumentation. Rollen schaffen Verbindlichkeit, weil sichtbar wird, wer wofür verantwortlich ist.

Zu Beginn formuliert ihr ein gemeinsames Ziel und zerlegt es in Teilaufgaben, die in kurzer Zeit bearbeitet werden können. Jede Teilaufgabe braucht ein überprüfbares Ergebnis, etwa eine fertige Seite, eine funktionierende Programmroutine oder einen dokumentierten Test.

Für den Arbeitsstand nutzt ihr klare Statusangaben: nicht begonnen, in Arbeit, blockiert, erledigt. So erkennt das Team früh, wo Hilfe nötig ist, wo Abhängigkeiten bestehen und welche Aufgaben rechtzeitig abgeschlossen sind.

Regelmäßige Abstimmungen sind Pflicht: kurz berichten, Probleme benennen, nächste Schritte festlegen. Ohne diese Kommunikation entstehen Lücken zwischen Teilaufgaben und unnötige Doppelarbeit.

Am Ende jedes Sprints folgt ein Rückblick: Was hat fachlich funktioniert? Wo gab es Reibungen im Team? Welche Arbeitsweise sollte im nächsten Sprint beibehalten, verbessert oder ersetzt werden? Diese Reflexion macht das nächste Arbeitspaket messbar besser.

In E4 entscheidet nicht nur das Thema über den Projekterfolg, sondern die Projektlogik: Ziel klären, Aufgaben aufteilen, Rollen abstimmen, Ergebnisse testen und den Prozess reflektieren.

Website-Projekt

Ziel: Eine nutzbare Website mit klarer Struktur und verständlichen Inhalten veröffentlichen.
Typische Aufgaben: Seitenaufbau planen, Navigation umsetzen, Inhalte erstellen, Quellen prüfen.
Mögliche Rollen: Struktur/Design, Inhalt/Recherche, technische Umsetzung, Qualitätssicherung.
Test und Reflexion: Navigation und Lesbarkeit testen, Feedback aus Reviews übernehmen, Teamprozess im Sprint-Rückblick auswerten.

Kleines Programm

Ziel: Ein klar abgegrenztes Problem durch ein funktionierendes Programm lösen.
Typische Aufgaben: Anforderungen festlegen, Funktionen implementieren, Eingaben/Ausgaben prüfen, Fehler beheben.
Mögliche Rollen: Logik/Code, Testfall-Entwicklung, Fehlersuche, Dokumentation.
Test und Reflexion: Testfälle vorab definieren, Ergebnisse protokollieren, Ursachen von Fehlern im Rückblick besprechen.

Kombiniertes Web-/Code-Projekt

Ziel: Eine Weboberfläche mit einer programmierten Kernfunktion zu einem gemeinsamen Produkt verbinden.
Typische Aufgaben: Schnittstellen klären, Frontend und Programmlogik getrennt entwickeln, Teilergebnisse integrieren.
Mögliche Rollen: Frontend, Programmlogik, Integration/Tests, Projektkoordination.
Test und Reflexion: Zusammenspiel beider Teile systematisch prüfen, Integrationsprobleme dokumentieren, Zusammenarbeit nach jedem Sprint verbessern.