Planungsphase für ein Microcontroller-Projekt

Planungsphase für ein Microcontroller-Projekt

https://bildung.social/@oerinformatik/

https://oer-informatik.de/wasserfall_mcu_projekt_planungsphase

Planungsphase, Wasserfall-Modell, Microcontroller-Projekt, Magisches Dreieck, Stückliste, Pinbelegung, Programmablauf, Kostenplanung, Zeitplanung, Gantt-Diagramm, ESP32

tl/dr; (ca. 21 min Lesezeit): Sind Lastenheft und Pflichtenheft freigegeben, wird die Umsetzung eines Microcontroller-Projekts in den drei Dimensionen des magischen Dreiecks geplant: Qualität (Hardware und Software), Kosten und Zeit. Am durchgehenden Beispiel einer CO₂-Lüftungsampel mit ESP32 zeigt der Artikel, wie Messprinzip und Bauteile ausgewählt, Stückliste und Pinbelegung erstellt, der Programmablauf und erste Testfälle entworfen sowie Kostenaufstellung und Zeitplan mit Meilensteinen aufgestellt werden [AI-Assisted]. (Zuletzt geändert am 29.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. Hier klicken, um Kann-Liste ein- oder auszublenden

Lastenheft und Pflichtenheft legen fest, was ein Projekt leisten soll und wie und womit das geschehen soll. Bevor jedoch Bauteile bestellt, Schaltungen gelötet oder Code geschrieben wird, folgt im Wasserfall-Modell die Planungsphase: Hier wird aus dem Grobentwurf des Pflichtenhefts ein Plan, nach dem die Umsetzung Schritt für Schritt ablaufen kann. Die Mindmap zeigt, welche Ergebnisse am Ende dieser Phase vorliegen.

Das Beispielprojekt: eine CO₂-Lüftungsampel

Damit die Planung greifbar wird, begleitet uns ein Beispiel durch den ganzen Artikel. Für das Barcamp am Ratz und Rübe Berufskolleg (RRB) in Bielefeld am Samstag, 13.03.2027, sollen die acht Seminarräume eine CO₂-Lüftungsampel bekommen; eine neunte Ampel dient als Reserve. Die CO₂-Konzentration der Raumluft ist ein guter Hinweis darauf, wie verbraucht die Luft ist: Das Umweltbundesamt bewertet Werte unter 1000 ppm als hygienisch unbedenklich, 1000 bis 2000 ppm als auffällig und über 2000 ppm als inakzeptabel.¹

Aus Lastenheft und Pflichtenheft sind die wichtigsten Anforderungen bereits bekannt; Realisierung, Testfälle und Aufwand dazu nennt der Beispielabschnitt des Pflichtenhefts:

Planung und Entwurf

Die Planungsphase ist die dritte Phase des Wasserfall-Modells. Sie baut auf den freigegebenen Dokumenten der beiden vorigen Phasen auf:

In der Planungsphase muss die Realisierung des Projekts vor allem in den drei Dimensionen vorbereitet werden:

• Zeit: Welche Meilensteine sollen bis wann erreicht werden, wie viel Zeit steht insgesamt zur Verfügung?

• Kosten/Budget: Welches Budget ist für das Projekt freigegeben, welche Mittel sind erforderlich und wofür werden sie ausgegeben?

• Qualität/Umfang: Welcher Umfang des Projekts kann realisiert werden? Welche Anforderungen werden umgesetzt? Ist das Projekt nachhaltig?

Diese drei Dimensionen beeinflussen sich gegenseitig – wird beispielsweise die Qualität erhöht, so hat dies direkt Folgen für die Kosten und die Zeit. Wir können nicht alle Dimensionen zeitgleich optimieren und müssen Entscheidungen treffen: Bei klassischen Projekten ist der Umfang vorgegeben, die Zeit und die Kosten bleiben flexibel. Dadurch geraten Kosten und Zeit oft aus dem Ruder. Bei agilen Projekten und Festpreisprojekten wird das magische Dreieck auf den Kopf gestellt: Die Projektdauer (Zeit) ist vorgegeben (damit häufig ein wesentlicher Teil der Kosten). Es muss dann jedoch allen Seiten klar sein, dass in diesem Fall die Qualität (der Umfang) zum Projektabschluss nicht im Vorhinein festgelegt werden kann.

Bei der Lüftungsampel ist die Zeit fest: Das Barcamp findet an einem festen Tag statt, eine Verschiebung ist ausgeschlossen. Auch das Materialbudget ist gedeckelt. Wird es eng, muss also beim Umfang nachgegeben werden – etwa indem der Summer entfällt (eine should-have-Anforderung), nicht aber die Anzeige (must-have).

Planung der Qualität – Hardware

In dieser Phase folgt zunächst die Auswahl der Komponenten, die für die Ein- und Ausgabe nötig sind.

• Welche Größen müssen gemessen und welche Eingaben müssen ermöglicht werden? (Eingabewerte)

  • Welche unterschiedlichen Techniken (physikalische Prinzipien) stehen zur Ermittlung dieser Größen zur Verfügung? Häufig gibt es unterschiedliche Wege, Größen zu messen.

  • Welche Technik wird favorisiert? Warum wurden die anderen Techniken nicht genutzt? Wären andere Techniken für Folgeprojekte denkbar, oder sind sie kategorisch ungeeignet?

  • Welche Bauteile setzen dieses Prinzip um? Welcher Hersteller bietet diese Komponenten an?

  • Welche Hardwareschnittstellen nutzen diese Komponenten, um mit dem Microcontroller zu kommunizieren? Wie erweiterbar ist diese Schnittstelle?

• Welche Aktoren müssen geschaltet werden und welche Werte müssen ausgegeben werden? (Ausgabewerte)

  • Welche unterschiedlichen Techniken gibt es, um die gewünschten Ausgaben zu erreichen? (Motoren, Relais, Lautsprecher …)

  • Welche Darstellungsformen zur Anzeige bieten sich an? Warum wurde sich gegen andere Darstellungsformen entschieden? (LED, mechanische Zeiger, akustische/haptische Rückmeldung, Displaytechniken, Webdashboards)

  • Welche Komponenten werden zur Anzeige benötigt? Wer bietet sie an?

  • Welche Hardwareschnittstellen nutzen diese Komponenten, um mit dem Microcontroller zu kommunizieren? Wie erweiterbar ist diese Schnittstelle?

Beispiel: Welches Messprinzip für CO₂?

Für die Lüftungsampel ist die wichtigste Eingabegröße die CO₂-Konzentration. Drei Sensorarten sind im Handel verbreitet:

Metalloxid-Sensoren scheiden aus, weil sie die geforderte Größe gar nicht messen. NDIR- und photoakustische Sensoren erfüllen die Anforderung; gewählt wird ein photoakustischer Sensor (Sensirion SCD41) auf einem Breakout-Modul, weil er klein ist, zusätzlich Temperatur und Luftfeuchte liefert (für ein Folgeprojekt interessant) und über I²C angeschlossen wird. Über denselben I²C-Bus ließen sich später weitere Sensoren ergänzen.

Für die Anzeige wird ein LED-Ring mit zwölf adressierbaren RGB-LEDs (WS2812B) gewählt: Er ist aus der Entfernung gut zu sehen, kann alle drei Ampelfarben darstellen und braucht nur eine Datenleitung. Ein Display wäre aus 5 m Entfernung kaum lesbar, ein reines Webdashboard würde im Raum niemand beachten. Ein passiver Piezo-Summer gibt den Signalton aus, ein Taster schaltet ihn stumm. Als Microcontroller dient ein ESP32-Entwicklungsboard: Es hat genug Pins, I²C in Hardware und WLAN, falls die Messwerte später zentral gesammelt werden sollen.

Stückliste

Neben der genauen Auswahl der erforderlichen Komponenten in Form einer Stückliste sollte hier bereits die genaue Verdrahtung geplant werden: Welcher Sensor und welcher Aktor wird wie mit dem Microcontroller verschaltet? Werden interne Pull-up-Widerstände genutzt und sollten später aktiviert werden?

Die Stückliste der Lüftungsampel nennt je Position Bauteil, Menge je Ampel und Richtpreis. Die Preise sind brutto und typische Händlerpreise (Stand 2026); sie schwanken je nach Bezugsquelle.

Verdrahtung und Pinbelegung

Das Hardwareschema zeigt, welche Komponente über welche Schnittstelle und an welchem Pin mit dem ESP32 verbunden wird:

Es bietet sich an, die Belegung der Pins direkt als Code-Tabelle zu erstellen, um sie später bei der Implementierung nutzen zu können. Für die Lüftungsampel ergibt sich aus dem Hardwareschema diese Pin-Tabelle. Die I²C-Pins 21 und 22 sind die Standardbelegung des ESP32; der Taster schaltet gegen GND und nutzt den internen Pull-up-Widerstand, ist also LOW-aktiv:

//-------------------------------------------------------------------------------------
// List of Input- and Output-devices and Pins (CO2 traffic light, ESP32-DevKitC)
//-------------------------------------------------------------------------------------
// Datatype | Name of Variable    | Pin No. connected | Name, Behaviour
const int     PIN_I2C_SDA         = 21;              // SCD41 SDA (I2C data), 3.3 V
const int     PIN_I2C_SCL         = 22;              // SCD41 SCL (I2C clock), 3.3 V
const int     PIN_LED_RING        = 18;              // WS2812B data in (via 330 Ohm)
const int     PIN_BUZZER          = 25;              // passive piezo, PWM output
const int     PIN_BUTTON_MUTE     = 4;               // push button to GND, internal pull-up, LOW = pressed

Planung der Qualität – Software

Auch die Software wird vor dem ersten Programmieren geplant. Dazu gehören der Programmablauf, die Struktur des Codes mit Bibliotheken und Konstanten sowie die Testfälle, mit denen später geprüft wird, ob die Anforderungen erfüllt sind.

Planung über den Programmablauf

Ein Microcontroller-Programm besteht meist aus zwei Teilen: Die Funktion setup() wird einmal nach dem Einschalten ausgeführt und initialisiert die Hardware. Danach wird die Funktion loop() endlos wiederholt – nach dem Muster Einlesen – Verarbeiten – Ausgeben. Für die Lüftungsampel zeigt das Aktivitätsdiagramm, wie die Messwerte in eine Ampelfarbe übersetzt werden und wann der Summer ertönt:

Aus dem Ablauf ergibt sich ein Programmgerüst, in dem jede Aktion des Diagramms zunächst nur als Kommentar bzw. als noch leerer Funktionsaufruf steht. In der Durchführungsphase werden diese Funktionen dann nacheinander mit Leben gefüllt:

void setup(){
    //konfigurierePins();

    //starteSensorMessung();

    //initialisiereWLANVerbindung();   // optional, for later projects

    //schalteLEDaufDefault();
}

void loop(){
    //Einlesen
    //warteAufNaechstenMesswert();     // SCD41: new value every 5 s
    //leseCO2Wert();
    //leseTaster();

    //Verarbeiten
    //bestimmeAmpelfarbe();            // < 1000 green, 1000..2000 yellow, > 2000 red

    //Ausgeben
    //setzeLEDRing();
    //gibSignaltonAusWennNoetig();
}

Bibliotheken, Konstanten und Codestruktur

Vor der Implementierung wird außerdem festgelegt:

• Bibliotheken: Welche fertigen Bibliotheken werden für Sensor und LED-Ring genutzt, in welcher Version? Eine festgehaltene Version verhindert, dass sich das Verhalten durch ein Update unbemerkt ändert.

• Konstanten statt „magischer Zahlen“: Grenzwerte und Zeiten stehen einmal zentral im Code, etwa const int CO2_LIMIT_YELLOW = 1000; und const int CO2_LIMIT_RED = 2000;. So lassen sich die Grenzen ändern, ohne den Code zu durchsuchen.

• Funktionen je Aufgabe: Einlesen, Verarbeiten und Ausgeben stehen in eigenen Funktionen. Die Funktion, die aus einem Messwert die Ampelfarbe bestimmt, braucht dann keine Hardware und lässt sich einzeln testen.

• Versionsverwaltung: Der Code liegt von Anfang an in einem Git-Repository, damit Änderungen nachvollziehbar bleiben und mehrere Personen parallel arbeiten können.

Testfälle schon jetzt planen

Die Akzeptanzkriterien aus dem Pflichtenheft geben vor, wie später getestet wird. Bei Grenzwerten lohnt es sich, Testfälle direkt an den Grenzen zu planen, weil dort Fehler wie > statt >= auffallen (Grenzwertanalyse). Für die Ampelfarbe ergeben sich zum Beispiel diese Testfälle:

Wie aus Anforderungen systematisch Testfälle entstehen, beschreibt der Artikel Blackbox-Tests.

Planung der Kosten

Die Kosten eines Microcontroller-Projekts setzen sich im Wesentlichen aus drei Teilen zusammen:

• Materialkosten: alle Positionen der Stückliste, multipliziert mit der Stückzahl, dazu Versandkosten.

• Personalkosten: die geplanten Arbeitsstunden aller Arbeitspakete, multipliziert mit einem Stundensatz. Auch wenn – wie bei einem Schulprojekt – niemand bezahlt wird, lohnt sich eine kalkulatorische Rechnung: Sie zeigt, was dasselbe Projekt bei einem Dienstleister kosten würde.

• Reserve: ein Zuschlag für Unvorhergesehenes, etwa defekte Bauteile, Preissteigerungen oder Mehraufwand. Wie hoch sie sein sollte, hängt von den Risiken des Projekts ab (siehe Risikoanalyse).

Für die Lüftungsampel ergeben sich bei zwei Bestellungen mit je 4,90 € Versand und einem kalkulatorischen Stundensatz von 45 € diese Werte:

Das Diagramm zeigt, wie sich die Kosten auf die einzelnen Positionen verteilen. Auffällig: Selbst bei einem Projekt mit sichtbarer Hardware ist die Arbeitszeit der größte Kostenblock, und unter den Bauteilen dominiert der Sensor.

Für das Barcamp zählt vor allem das Materialbudget aus dem Pflichtenheft: Material plus 10 % Reserve ergeben 617,30 € × 1,1 ≈ 679,03 € und bleiben damit unter der Grenze von 700 €. Die Arbeitszeit leistet die Projektgruppe im Unterricht.

Planung der Zeit/Ressourcen

Für die Zeitplanung wird das Projekt in Arbeitspakete zerlegt (siehe Projektstrukturplan und Gantt-Diagramm). Für jedes Paket werden zwei Größen geschätzt, die man nicht verwechseln darf:

• der Aufwand in Personenstunden – er geht in die Kostenplanung ein,

• die Dauer im Kalender – sie hängt davon ab, wie viele Stunden pro Woche zur Verfügung stehen, und enthält auch Wartezeiten ohne Aufwand, etwa die Lieferzeit der Bauteile.

Außerdem wird festgehalten, welches Paket auf welches andere warten muss (Abhängigkeiten), und welche Ressourcen gebraucht werden: Personen, Lötplätze, Messgeräte, ein 3D-Drucker für die Gehäuse.

Daraus entsteht ein Zeitplan als Gantt-Diagramm. Das Projekt startet am Montag, 11.01.2027; Wochenenden sind arbeitsfrei. Meilensteine markieren die Stellen, an denen ein Ergebnis freigegeben wird – im Wasserfall-Modell typischerweise das Ende einer Phase:

Der Plan endet mit der Dokumentation am Freitag, 05.03.2027. Bis zum Barcamp bleibt damit eine Woche Puffer: Fällt ein Sensor aus oder verzögert sich die Lieferung um ein paar Tage, wird der Termin trotzdem gehalten. Welche Pakete keinen Puffer haben und den Endtermin direkt verschieben würden (kritischer Pfad), lässt sich mit einem Netzplan bestimmen. Hier ist es die Kette A1 – A2 – B1 – B2 – C1 – D1. Das Paket A3 dagegen kann sich um zwei Wochen verspäten, der Serienbau B3 um eine Woche, ohne dass sich der Endtermin verschiebt.

Ende der Phase: Die Planung wird freigegeben

Am Ende der Planungsphase liegen Stückliste, Hardwareschema mit Pinbelegung, Programmablauf mit Programmgerüst, Testfälle, Kostenaufstellung und Zeitplan vor. Sie werden mit dem Auftraggeber abgestimmt und freigegeben. Im Beispiel werden Hardwareplanung und Kosten schon nach der ersten Woche freigegeben (Meilenstein „Bestellung freigegeben“), damit die Lieferzeit genutzt werden kann; die Softwareplanung wird währenddessen abgeschlossen. Erst mit der Freigabe wird bestellt. Ab jetzt sind Änderungen teuer: Jede neue Anforderung muss über ein geregeltes Änderungsverfahren laufen und ihre Folgen für Kosten und Zeit müssen neu bewertet werden. Wie die Phasen insgesamt zusammenhängen, zeigt die Übersicht der Artikelreihe.

Leitfragen

1. Welche drei Dimensionen werden in der Planungsphase geplant, und wie hängen sie zusammen? Antwort

Qualität bzw. Umfang, Kosten und Zeit bilden das magische Dreieck. Ändert sich eine Dimension, hat das Folgen für die anderen: Mehr Umfang kostet mehr Zeit und Geld; ist die Zeit fest wie bei der Lüftungsampel, muss bei Engpässen der Umfang nachgeben, siehe Abschnitt „Planung und Entwurf“.

2. Wie gehst Du vor, um einen Sensor für eine Messgröße auszuwählen? Antwort

Du sammelst die möglichen Messprinzipien, vergleichst sie nach Eignung für die Anforderung, Baugröße, Schnittstelle und Preis und begründest, warum Du Dich für eines entscheidest und die anderen verwirfst. Bei der Lüftungsampel scheiden Metalloxid-Sensoren aus, weil sie CO₂ nur schätzen, siehe Abschnitt „Beispiel: Welches Messprinzip für CO2?“.

3. Warum lohnt es sich, die Pinbelegung schon in der Planungsphase als Code-Tabelle zu notieren? Antwort

Die Verdrahtung und der Code müssen zusammenpassen. Eine Code-Tabelle mit Konstanten für alle Pins ist zugleich Planungsdokument und Teil des späteren Programms; Fehler wie doppelt belegte Pins oder vergessene Pull-up-Widerstände fallen so vor dem Löten auf, siehe Abschnitt „Verdrahtung und Pinbelegung“.

4. Wie ist ein typisches Microcontroller-Programm aufgebaut? Antwort

setup() initialisiert einmal die Hardware, danach wiederholt loop() endlos die Schritte Einlesen, Verarbeiten und Ausgeben. Den Ablauf planst Du vorab, etwa als Aktivitätsdiagramm, und leitest daraus ein Programmgerüst ab, siehe Abschnitt „Planung über den Programmablauf“.

5. Welche Testfälle planst Du für die Grenzwerte 1000 ppm und 2000 ppm der Lüftungsampel? Antwort

Testfälle direkt an den Grenzen: 999 ppm (grün), 1000 ppm (gelb), 2000 ppm (gelb) und 2001 ppm (rot), dazu ein Testfall ohne gültigen Messwert. Gerade an den Grenzen fallen Fehler wie > statt >= auf, siehe Abschnitt „Testfälle schon jetzt planen“.

6. Aus welchen Teilen setzen sich die Kosten eines Microcontroller-Projekts zusammen? Antwort

Aus Materialkosten (Stückliste mal Stückzahl plus Versand), Personalkosten (Aufwand in Stunden mal Stundensatz, bei Schulprojekten kalkulatorisch) und einer Reserve für Unvorhergesehenes. Bei der Lüftungsampel ist die Arbeitszeit mit 3.037,50 € der größte Block, siehe Abschnitt „Planung der Kosten“.

7. Worin unterscheiden sich Aufwand und Dauer eines Arbeitspakets, und warum ist das für den Zeitplan wichtig? Antwort

Der Aufwand gibt an, wie viele Personenstunden ein Paket kostet, die Dauer, wie lange es im Kalender läuft – einschließlich Wartezeiten wie der Lieferzeit, die keinen Aufwand verursacht. Der Zeitplan beruht auf den Dauern, die Kostenplanung auf dem Aufwand, siehe Abschnitt „Planung der Zeit/Ressourcen“.

8. Wozu dienen Meilensteine und Puffer im Zeitplan? Antwort

Meilensteine markieren überprüfbare Zwischenergebnisse wie „Bestellung freigegeben“ oder „Abnahme bestanden“. Ein Puffer vor einem festen Termin fängt Verzögerungen auf; bei der Lüftungsampel liegt eine Woche zwischen Dokumentation und Barcamp, siehe Abschnitt „Planung der Zeit/Ressourcen“.

Links und weitere Informationen

• Übersicht: Realisierung eines Microcontroller-Projekts nach dem Wasserfall-Modell

• Projektstrukturplan und Gantt-Diagramm, Netzplan und Risikoanalyse

• Sensoren und Aktoren einsetzen: Messprinzipien, A/D-Wandlung und Einplatinencomputer

• Blackbox-Testfälle

• als Nachschlagewerk: Ausschuss für Innenraumrichtwerte beim Umweltbundesamt: Hygienische Leitwerte für die Innenraumluft (darin die Leitwerte für Kohlendioxid von 2008)

• zum Sensor: Sensirion: Produktunterstützung zum CO₂-Sensor SCD4x (Datenblatt, Beispielcode)

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: “Planungsphase für ein Microcontroller-Projekt” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/wasserfall_mcu_projekt_planungsphase 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: 29.10.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]