Einen Prüfablauf als Algorithmus entwerfen

Aus einer Arbeitsanweisung wird ein eindeutiger Ablauf

Die Elbwerk Gerätevermietung GmbH verleiht Messgeräte an Handwerksbetriebe. Bei der Rückgabe liest eine Station die Kennungen aller Geräte eines Auftrags ein. Bisher entscheidet eine Mitarbeiterin für jedes Gerät von Hand, ob es direkt wieder verfügbar ist oder zuerst geprüft werden muss. Das dauert nicht nur Zeit. Zwei Personen können dieselbe Rückgabe auch unterschiedlich behandeln.

Du sollst den Prüfablauf so beschreiben, dass er später automatisiert werden kann. Dafür brauchst du noch keine bestimmte Programmiersprache. Zuerst muss eindeutig sein, welche Schritte in welcher Reihenfolge geschehen und unter welchen Bedingungen sich der Ablauf ändert. Genau das leistet ein Algorithmus.

Nach dieser Lektion kannst du:

• eine Anforderung in Eingaben, Verarbeitung und Ausgaben zerlegen,
• Sequenzen, Verzweigungen und Schleifen passend einsetzen,
• einen Ablauf als sprachneutralen Pseudocode darstellen,
• Testfälle auswählen und den Ablauf Schritt für Schritt nachvollziehen,
• einen logischen Fehler mit einem konkreten Gegenbeispiel begründet korrigieren.

Du solltest Vergleiche wie groesser als und Wahrheitswerte wie wahr und falsch kennen. Kenntnisse einer konkreten Programmiersprache brauchst du nicht.

Kläre zuerst, was der Ablauf leisten soll

Ein Algorithmus ist eine eindeutige, endliche Folge von Schritten, die Eingaben verarbeitet und zu einem Ergebnis führt. “Geräte prüfen” ist noch kein brauchbarer Algorithmus. Die Formulierung lässt offen, welche Daten geprüft werden und wann welches Ergebnis entsteht.

Für Elbwerk gilt diese fachliche Regel:

1. Eine Rückgabe enthält eine Liste von Geräten.
2. Ein Gerät kommt in die Prüfliste, wenn es einen gemeldeten Schaden hat oder mehr als 400 Betriebsstunden seit der letzten Wartung aufweist.
3. Alle anderen Geräte werden als verfügbar markiert.
4. Am Ende werden die Anzahl verfügbarer Geräte und die Prüfliste ausgegeben.

Die Grenze ist absichtlich genau formuliert: Mehr als 400 Stunden bedeutet, dass ein Gerät mit genau 400 Stunden noch verfügbar bleibt. Ob diese betriebliche Regel sinnvoll ist, entscheidet der Fachbereich. Der Algorithmus setzt sie nur nachvollziehbar um.

Bevor du Pseudocode schreibst, trennst du drei Rollen:

Diese Trennung schützt vor einer häufigen Abkürzung: Wer sofort Code schreibt, entscheidet Details oft nebenbei. Eine klare Ein- und Ausgabe macht zuerst sichtbar, was der Ablauf fachlich schuldet.

Zerlege das Problem in überschaubare Schritte

Problemzerlegung bedeutet, einen großen Auftrag in kleinere, klar prüfbare Teilaufgaben aufzuteilen. Für die Rückgabe reichen zunächst vier Teilaufgaben:

1. Ergebniswerte vorbereiten.
2. Nächstes Gerät aus der Liste betrachten.
3. Prüfentscheidung treffen und Ergebnis aktualisieren.
4. Gesamtergebnis ausgeben.

Damit steht das Grundgerüst. Innerhalb dieses Gerüsts übernehmen drei Kontrollstrukturen unterschiedliche Aufgaben:

• Eine Sequenz führt Schritte nacheinander aus. Erst werden Ergebniswerte vorbereitet, am Ende werden sie ausgegeben.
• Eine Verzweigung entscheidet anhand einer Bedingung zwischen Wegen. Ein Gerät geht entweder in die Prüfliste oder wird verfügbar.
• Eine Schleife wiederholt Schritte. Dieselbe Entscheidung wird für jedes Gerät der Rückgabe ausgeführt.

Diese Strukturen beschreiben die Logik, nicht die Schreibweise einer Sprache. Ob eine spätere Umsetzung if, wenn oder ein grafisches Entscheidungssymbol verwendet, ändert den fachlichen Ablauf nicht.

Stelle die Logik unabhängig von einer Programmiersprache dar

Pseudocode beschreibt Programmlogik mit verständlichen, vereinbarten Formulierungen. Er muss nicht ausführbar sein. Er soll aber so eindeutig eingerückt und benannt sein, dass eine andere Person die Kontrollstrukturen erkennt und die Lösung in eine Programmiersprache übertragen kann.

ALGORITHMUS rueckgabePruefen(geraete)
    verfuegbarAnzahl <- 0
    pruefliste <- leere Liste

    FUER JEDES geraet IN geraete
        pruefungNoetig <- geraet.schadenGemeldet ODER
                          geraet.betriebsstunden > 400

        WENN pruefungNoetig DANN
            fuege geraet.kennung zu pruefliste hinzu
        SONST
            verfuegbarAnzahl <- verfuegbarAnzahl + 1
        ENDE WENN
    ENDE FUER

    GIB verfuegbarAnzahl, pruefliste ZURUECK
ENDE ALGORITHMUS

Die sprechenden Namen tragen das Verständnis. pruefungNoetig fasst die fachliche Entscheidung zusammen. Die Bedingung bleibt trotzdem sichtbar, sodass die Regel überprüft werden kann.

Der Ablauf lässt sich auch als Fluss darstellen:

Prüfe den Ablauf mit einem Schreibtischtest

Ein Schreibtischtest verfolgt einen Algorithmus mit festgelegten Eingaben Schritt für Schritt. Du notierst, wie sich wichtige Werte verändern. Der Test beweist nicht, dass der Ablauf für jede mögliche Eingabe korrekt ist. Er kann aber Annahmen sichtbar machen und mit einem einzigen Gegenbeispiel einen Fehler belegen.

Für die erste Prüfung nutzt du drei Geräte:

Der Trace, also die schrittweise Ablaufverfolgung, sieht so aus:

Die Ausgabe lautet damit 1 und [M-23, M-41]. Sie stimmt mit den Erwartungen der drei Testfälle überein.

Ein guter Testbestand deckt unterschiedliche Entscheidungen ab:

• Ein Normalfall zeigt einen typischen Ablauf, etwa ein unbeschädigtes Gerät mit 125 Stunden.
• Ein Randfall liegt an einer fachlichen Grenze, etwa genau 400 Stunden.
• Ein Fehlerfall enthält eine ungültige oder unvollständige Eingabe, etwa fehlende Betriebsstunden.

Für den Fehlerfall fehlt unserer Anforderung bisher eine Regel. Soll die gesamte Rückgabe abgebrochen werden? Soll nur dieses Gerät in eine Klärungsliste? Diese Entscheidung darf der Algorithmus nicht erfinden. Sie muss mit dem Fachbereich geklärt werden. Ein Test kann also auch eine Lücke in der Anforderung finden.

Nutze ein Gegenbeispiel für eine begründete Korrektur

Bei der Durchsicht schlägt ein Kollege eine kürzere Fassung vor. Sie soll jedes Gerät mit höchstens 400 Stunden sofort als verfügbar zählen:

FUER JEDES geraet IN geraete
    WENN geraet.betriebsstunden <= 400 DANN
        verfuegbarAnzahl <- verfuegbarAnzahl + 1
    SONST
        fuege geraet.kennung zu pruefliste hinzu
    ENDE WENN
ENDE FUER

Die Fassung wirkt auf den ersten Blick passend. Sie bildet aber nur eine der beiden fachlichen Bedingungen ab.

Das konkrete Gegenbeispiel lautet:

Kennung: M-23
schadenGemeldet: wahr
betriebsstunden: 80

Erwartung laut Fachregel: Prüfliste
Ergebnis des verkürzten Ablaufs: verfügbar

Die Korrektur lässt sich auf zwei gleichwertige Arten formulieren:

WENN geraet.schadenGemeldet ODER geraet.betriebsstunden > 400 DANN
    fuege geraet.kennung zu pruefliste hinzu
SONST
    verfuegbarAnzahl <- verfuegbarAnzahl + 1
ENDE WENN

Oder du formulierst die Verfügbarkeitsbedingung vollständig:

WENN NICHT geraet.schadenGemeldet UND geraet.betriebsstunden <= 400 DANN
    verfuegbarAnzahl <- verfuegbarAnzahl + 1
SONST
    fuege geraet.kennung zu pruefliste hinzu
ENDE WENN

Beide Varianten bilden dieselbe Regel ab. Die erste liegt näher an der fachlichen Aussage “Prüfung nötig, wenn …”. Dadurch kann sie bei einer späteren Änderung leichter mit der Anforderung verglichen werden. Kürzerer Pseudocode ist nicht automatisch besser. Entscheidend ist, ob die Logik vollständig, prüfbar und für andere verständlich bleibt.

Entwirf den Ablauf für einen neuen Prozess

fehlend <- leere Liste
gesperrt <- leere Liste

FUER JEDE kennung IN vorgesehen
    WENN kennung NICHT IN gescannt DANN
        fuege kennung zu fehlend hinzu
    SONST WENN pruefungOffen(kennung) DANN
        fuege kennung zu gesperrt hinzu
    ENDE WENN
ENDE FUER

freigegeben <- fehlend ist leer UND gesperrt ist leer
GIB freigegeben, fehlend, gesperrt ZURUECK

Was du aus dem Ablauf mitnehmen kannst

Ein tragfähiger Algorithmus beginnt nicht mit Syntax. Er beginnt mit einer eindeutigen fachlichen Regel. Daraus entsteht ein Ablauf:

1. Eingaben, Verarbeitung und Ausgaben bestimmen.
2. Das Problem in überschaubare Teilaufgaben zerlegen.
3. Sequenz, Verzweigung und Schleife passend einsetzen.
4. Die Logik in verständlichem Pseudocode oder einer Flussdarstellung festhalten.
5. Normal-, Rand- und Fehlerfälle auswählen.
6. Den Ablauf mit einem Trace nachvollziehen.
7. Einen Fehler mit einem Gegenbeispiel belegen und die Korrektur an der Anforderung ausrichten.

Damit kannst du den Ablauf mit anderen abstimmen, bevor Details einer Programmiersprache hinzukommen. Die spätere Implementierung braucht zusätzlich passende Datentypen, Schnittstellen, Fehlerbehandlung und automatisierte Tests. Diese Lektion grenzt sich bewusst davon ab.

Quellenbasis und Abgrenzung

Der KMK-Rahmenlehrplan ordnet das Anpassen datenverwaltender Software in Lernfeld 5 und das Realisieren von Anwendungsfunktionalität in Lernfeld 11a ein. Die Fachinformatikerausbildungsverordnung nennt das Formulieren von Algorithmen und Erstellen von Anwendungen, das Programmieren von Softwarelösungen sowie das Konzipieren kundenspezifischer Softwareanwendungen als Berufsbildpositionen. § 14 verankert für Fachinformatikerinnen und Fachinformatiker der Fachrichtung Anwendungsentwicklung außerdem das Übertragen von Algorithmen in eine Programmierlogik, ihre grafische Darstellung und die Auswahl von Testszenarien im Prüfungsbereich “Entwicklung und Umsetzung von Algorithmen”.

Der Prüfungskatalog 2026 konkretisiert diese Breite mit Kontrollstrukturen, Pseudocode, Ablaufverfolgung und Testdaten. Eine historische Beispielprüfung wurde nur auf wiederkehrende Aufgabenformen untersucht. Das Unternehmen, der Rückgabeprozess, alle Gerätekennungen, Regeln, Zahlen, Aufgaben und Lösungen dieser Lektion sind neu erstellt.

Die Lektion vermittelt den Entwurf eines überschaubaren, iterativen Algorithmus. Sie behandelt keine konkrete Programmiersprache, keine Datenstruktur- oder Laufzeitanalyse und keine Such-, Sortier- oder Rekursionsverfahren. Auch formale Korrektheitsbeweise und automatisierte Testframeworks gehören in eigene Lektionen. Die Inhalte sagen keine Aufgabe eines konkreten Prüfungstermins voraus.

Belegmatrix