Realisierung eines Microcontroller-Projekts nach dem Wasserfall-Modell
https://bildung.social/@oerinformatik/
https://oer-informatik.de/wasserfall_mcu_projekt
Wasserfall-Modell, Microcontroller-Projekt, Vorgehensmodell, Projektphasen, Lastenheft, Pflichtenheft, Planungsphase, Qualitätssicherung, Abnahme, Projektdokumentation
tl/dr; (ca. 9 min Lesezeit): Für kleine Projekte, deren Ziel und Anforderungen von Beginn an feststehen, eignet sich ein phasenweises, dokumentengetriebenes Vorgehen, wie es das Wasserfall-Modell beschreibt. Dieser Einstieg in die Artikelreihe zeigt, wann das Modell zu einem Microcontroller-Projekt passt, welche sechs Phasen es durchläuft und welches Dokument am Ende jeder Phase steht – vom Lastenheft bis zum Übergabeprotokoll [AI-Assisted]. (Zuletzt geändert am 28.10.2026)
Dieser Artikel ist Teil einer Artikelreihe zur Realisierung eines Microcontroller-Projekts nach dem Wasserfall-Modell: Übersicht / Lastenheft / Pflichtenheft / Planungsphase / Übungsaufgaben zu Lastenheft und Pflichtenheft
Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast.
Als Vorgehensmodell-Grundlagen kann ich nach Durchlesen des Artikels…
… die sechs Phasen des Wasserfall-Modells für ein Microcontroller-Projekt in der richtigen Reihenfolge nennen.
… jeder Phase ihr Ergebnisdokument zuordnen (Lastenheft, Pflichtenheft, Planungsunterlagen, Schaltung und Quellcode, Test- und Abnahmeprotokoll, Übergabeunterlagen).
… erklären, warum eine Phase erst mit einem freigegebenen Dokument endet und die nächste darauf aufbaut.
… unterscheiden, welche Dokumente der Auftraggeber und welche der Auftragnehmer schreibt.
… begründen, unter welchen Bedingungen ein Microcontroller-Projekt gut nach dem Wasserfall-Modell geplant werden kann.
Darüber hinaus kann ich als Vorgehensmodell-Expertenwissen…
… die Grenzen des einfachen Wasserfall-Modells beurteilen und Gegenmaßnahmen nennen (Rücksprünge, Prototyp, frühe Tests).
… für ein eigenes Vorhaben entscheiden, ob ein klassisches oder ein agiles Vorgehen besser passt.
Ein Microcontroller soll in einem Seminarraum anzeigen, wann gelüftet werden muss, ein anderer soll Messwerte einer Werkstattmaschine erfassen: Solche Projekte sind überschaubar, haben aber schon alles, was ein „richtiges“ Projekt ausmacht – Anforderungen eines Auftraggebers, Hardware, die bestellt werden muss, Software, die geschrieben und getestet werden muss, ein Budget und einen festen Termin. Wer hier planlos loslegt, merkt oft erst beim Löten, dass der Sensor die falsche Schnittstelle hat, oder erst bei der Übergabe, dass eine wichtige Anforderung nie umgesetzt wurde.
Diese Artikelreihe zeigt, wie ein solches Projekt nach dem einfachsten klassischen Vorgehensmodell abläuft: dem Wasserfall-Modell. Die Grafik fasst zusammen, welche Phasen nacheinander durchlaufen werden und welches Dokument am Ende jeder Phase freigegeben wird.
Wann passt das Wasserfall-Modell zu einem Microcontroller-Projekt?
Im Wasserfall-Modell werden die Phasen eines Projekts streng nacheinander bearbeitet. Jede Phase endet mit einem Ergebnis – meist einem Dokument –, das geprüft und freigegeben wird und dann die Grundlage der nächsten Phase bildet. Wie das Modell entstanden ist und wie es sich von anderen Vorgehensmodellen unterscheidet, beschreibt der Artikel Vorgehensmodelle: klassisch und agil.
Für kleine Microcontroller-Projekte ist dieses Vorgehen gut geeignet, wenn
die Anforderungen von Beginn an feststehen und sich während des Projekts kaum ändern (z. B. „Messwert erfassen, mit Grenzwert vergleichen, anzeigen“),
Hardware früh bestellt werden muss: Lieferzeiten von mehreren Wochen und Kosten für Fehlkäufe machen späte Änderungen teuer – also lohnt sich eine gründliche Planung, bevor bestellt wird,
das Team klein und das Projekt kurz ist, sodass wenige, klar abgegrenzte Dokumente ausreichen,
ein fester Termin einzuhalten ist, zu dem das Gerät funktionieren muss,
die Dokumente selbst gebraucht werden, etwa als Grundlage für Angebot und Abnahme oder als Nachweis in der Ausbildung.
Weniger gut passt es, wenn die Anforderungen noch unklar sind oder sich das Ziel erst durch Ausprobieren ergibt. Dann fehlt die Rückkopplung: Fehler aus frühen Phasen fallen im reinen Wasserfall-Modell erst beim Testen auf. Schon Winston W. Royce hat deshalb 1970 Rücksprünge, einen Pilotversuch und die Einbindung des Kunden gefordert – nachzulesen im Artikel Royce’ Kritik am einfachen Phasenmodell. Bei Microcontroller-Projekten hilft ein früher Prototyp auf dem Steckbrett, solche Überraschungen klein zu halten.
Die Phasen und ihre Dokumente
Die klassische Darstellung des Wasserfall-Modells zeigt die Phasen als Kaskade, in der das Ergebnis jeder Stufe in die nächste „herabfällt“:
Für ein Microcontroller-Projekt bedeuten die sechs Phasen im Einzelnen:
1. Anforderungsdefinition: das Lastenheft
Der Auftraggeber beschreibt, was das System leisten soll und wofür er es braucht (customer requirements). Er formuliert seine Anforderungen lösungsneutral und mit prüfbaren Akzeptanzkriterien im Lastenheft. Wer das Lastenheft schreibt, was hineingehört und wie es abgestimmt wird, steht im Artikel Lastenheft für ein Microcontroller-Projekt.
2. Anforderungsanalyse: das Pflichtenheft
Der Auftragnehmer antwortet mit dem Pflichtenheft (developer requirements): Für jede Anforderung des Lastenhefts beschreibt er, wie und womit er sie umsetzen will, welche Testfälle er vorsieht und welchen Aufwand er erwartet. Dafür braucht es bereits einen Grobentwurf mit ersten Bauteilen. Das freigegebene Pflichtenheft wird oft Teil des Vertrags, siehe Pflichtenheft für ein Microcontroller-Projekt.
3. Planung und Entwurf: Stückliste, Pinbelegung, Kosten- und Zeitplan
Jetzt wird die Umsetzung in den drei Dimensionen Qualität, Kosten und Zeit geplant. Ergebnisse sind eine Stückliste mit den ausgewählten Sensoren und Aktoren, die Pinbelegung des Microcontrollers, ein Programmablauf (z. B. als Aktivitätsdiagramm oder Struktogramm), eine Kostenaufstellung und ein Zeitplan mit Meilensteinen. Wie das an einem durchgehenden Beispiel aussieht, zeigt der Artikel Planungsphase für ein Microcontroller-Projekt. Werkzeuge für die Zeitplanung erklären die Artikel Projektstrukturplan und Gantt-Diagramm und Netzplan; Risiken lassen sich mit einer Risikoanalyse bewerten.
4. Implementierung: Schaltung aufbauen und programmieren
In der Durchführungsphase wird die Schaltung erst als Prototyp, dann als fertiges Gerät aufgebaut und das Programm nach dem geplanten Ablauf geschrieben. Ergebnis sind die aufgebaute Schaltung und der Quellcode, idealerweise in einer Versionsverwaltung wie Git. Grundlagen zu Bauteilen und zum Programmentwurf bieten die Artikel Sensoren und Aktoren und Programmentwurf.
5. Qualitätssicherung: testen und abnehmen
Geprüft wird gegen die Akzeptanzkriterien und Testfälle aus dem Pflichtenheft: Einzelne Funktionen werden getestet, dann das Gesamtgerät unter realen Bedingungen. Ergebnisse sind das Testprotokoll und am Ende das Abnahmeprotokoll, mit dem der Auftraggeber bestätigt, dass seine Anforderungen erfüllt sind. Wie Testfälle systematisch entstehen, zeigen die Artikel Teststrategie, Blackbox-Tests und Unit-Tests.
6. Ausrollen und Übergabe
Zum Schluss wird das Gerät am Einsatzort in Betrieb genommen und an den Auftraggeber übergeben. Dazu gehören eine Bedienungsanleitung, eine kurze Einweisung der Nutzenden und ein Übergabeprotokoll. Mit dem Projektabschluss werden Erfahrungen für künftige Projekte festgehalten, siehe Projektorganisation.
Das durchgehende Beispiel der Reihe
Damit die Phasen greifbar werden, begleitet die Planungsphase ein durchgehendes Beispielprojekt: Für ein Barcamp am Ratz und Rübe Berufskolleg (RRB) in Bielefeld baut eine Projektgruppe neun CO2-Lüftungsampeln auf Basis eines ESP32. Jede Ampel misst die CO2-Konzentration in einem Seminarraum und zeigt mit grünem, gelbem oder rotem Licht an, wann gelüftet werden sollte. An diesem Gerät zeigt die Reihe, wie aus Anforderungen eine Stückliste, eine Pinbelegung, ein Programmablauf, ein Kostenplan und ein Zeitplan werden.
Lastenheft und Pflichtenheft werden in der Reihe zunächst allgemein und mit kleinen, eigenen Beispielen erklärt; Übungen dazu bietet der Artikel Übungsaufgaben zu Lastenheft und Pflichtenheft.
Leitfragen
- Welche Phasen durchläuft ein Microcontroller-Projekt nach dem Wasserfall-Modell, und in welcher Reihenfolge?
Anforderungsdefinition, Anforderungsanalyse, Planung und Entwurf, Implementierung, Qualitätssicherung sowie Ausrollen und Übergabe. Jede Phase baut auf dem freigegebenen Ergebnis der vorigen auf, siehe Abschnitt „Die Phasen und ihre Dokumente“.
- Welches Dokument steht am Ende welcher Phase?
Lastenheft (Anforderungsdefinition), Pflichtenheft (Anforderungsanalyse), Stückliste, Pinbelegung, Programmablauf, Kosten- und Zeitplan (Planung und Entwurf), Schaltung und Quellcode (Implementierung), Test- und Abnahmeprotokoll (Qualitätssicherung) sowie Bedienungsanleitung und Übergabeprotokoll (Übergabe), siehe Abschnitt „Die Phasen und ihre Dokumente“.
- Wer schreibt das Lastenheft, wer das Pflichtenheft?
Das Lastenheft schreibt der Auftraggeber (Was und wofür?), das Pflichtenheft der Auftragnehmer (Wie und womit?), siehe Abschnitt „1. Anforderungsdefinition: das Lastenheft“ und Abschnitt „2. Anforderungsanalyse: das Pflichtenheft“.
- Wann eignet sich das Wasserfall-Modell für ein Microcontroller-Projekt, und wann eher nicht?
Es eignet sich, wenn die Anforderungen feststehen, Hardware früh bestellt werden muss, Team und Projekt klein sind und ein fester Termin gilt. Bei unklaren oder sich ändernden Anforderungen fehlt die Rückkopplung; dann helfen Rücksprünge, ein früher Prototyp oder ein agiles Vorgehen, siehe Abschnitt „Wann passt das Wasserfall-Modell zu einem Microcontroller-Projekt?“.
- Warum hilft ein früher Prototyp auch in einem Wasserfall-Projekt?
Ein Prototyp auf dem Steckbrett zeigt früh, ob Sensoren, Schnittstellen und Programmablauf wie geplant zusammenspielen. So fallen Planungsfehler nicht erst beim Testen des fertigen Geräts auf – genau die Schwäche, die schon Royce am einfachen Phasenmodell kritisiert hat, siehe Artikel zu Royce’ Kritik.
Links und weitere Informationen
im Original: Winston W. Royce: „Managing the Development of Large Software Systems“, Proceedings of IEEE WESCON, 1970
Hinweis zur Nachnutzung als Open Educational Resource (OER)
Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Realisierung eines Microcontroller-Projekts nach dem Wasserfall-Modell” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/wasserfall_mcu_projekt veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/vorgehensmodelle/vorgehensmodelle. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 28.10.2026.
[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]
