Pseudocode vs. Struktogramm und Programmablaufplan in der schriftlichen Abschlussprüfung

In so ziemlich allen schriftlichen IHK-Prüfungen der letzten Jahre (vgl. Themen der schriftlichen Prüfungen seit 2010) gab es mindestens eine „Programmieraufgabe“. Es sollte also ein Algorithmus für ein beliebiges Problem auf dem Papier „programmiert“ werden. Da Programmieren das Tagesgeschäft jedes Anwendungsentwicklers ist, finde ich diese Aufgaben auch absolut sinnvoll. Allerdings kommen in der Praxis häufig einige Fragen auf, wenn es um die Beantwortung dieser Aufgaben geht.

In diesem Artikel gebe ich eine Empfehlung zur Beantwortung der Programmieraufgaben: Beantworte Programmieraufgaben immer mit Pseudocode und nie mit Struktogramm oder Programmablaufplan.

Programmieraufgaben

Die Programmieraufgaben in der Abschlussprüfung haben meist einen komplexeren Algorithmus zum Inhalt (z.B. eine Prüfzifferberechnung, den Druck einer Kundenliste usw.). Daher sind die Aufgaben zeitintensiv und bringen viele Punkte (meist 25 für einen einzigen Algorithmus). Hin und wieder gibt es auch „kleinere“ Algorithmen (z.B. das rekursive Berechnen einer Quersumme) für weniger Punkte.

Auf das konkrete Thema der Aufgaben kann man sich natürlich nicht im Vorfeld der Prüfung vorbereiten, da die Inhalte (logischerweise) geheim sind. Aber gemein ist den Aufgaben immer, dass man sie entweder mittels Pseudocode, einem Struktogramm oder einem Progammablaufplan lösen kann. Niemals werden die Aufgaben eine bestimmte Programmiersprache fordern, da es nicht die eine Sprache gibt, die alle Azubis beherrschen. Selbst Java ist nicht überall Standard, da z.B. auch C# oder Pascal an Berufschulen gelehrt wird.

Es muss also prinzipiell jedem Prüfling möglich sein, die Aufgabe zu lösen. Daher werden standardisierte Darstellungsformen – Struktogramm (bzw. Nassi-Shneiderman-Diagramm) und Programmablaufplan, für beide gibt es DIN-Normen – bzw. Pseudocode vorgegeben.

Welche Variante man wählt, hat keine Auswirkung auf die Bewertung durch die Prüfer. Mit jeder Darstellungsform kann man die komplette Punktzahl holen. Warum ist es nun aber sinnvoll, nicht die beiden Diagrammformen zu verwenden, sondern Pseudocode zu schreiben? Meiner Meinung nach sprechen 4 Punkte gegen die Diagramme.

Diagramme sind sehr zeitaufwändig.

Die Diagramme vernünftig zu zeichnen kostet Zeit. Anstatt ein simples if zu schreiben, muss zusätzlich ein schönes Kästchen drumherum gemalt und auf genügend Platz für die Folgeelemente geachtet werden. Da die Programmieraufgaben ohnehin schon sehr zeitaufwändig sind und die allermeisten Prüflinge eher zu wenig als zu viel Zeit in der Prüfung haben, rate ich daher von aufwändigen Zeichnungen ab.

Diagramme sind nur umständlich nachträglich zu korrigieren.

Viele Prüflinge erstellen unter Zeitdruck nicht beim ersten Versuch die korrekte Lösung. Das ist auch kein Problem, wenn man am Ende der Prüfungszeit noch einmal korrigierend durch die Aufgaben geht. Allerdings lassen sich Diagramme im Nachhinein nur schwierig korrigieren. Einen vergessenen switch-Branch nachträglich ins Diagramm zu fummeln, kann nur nach hinten losgehen. Das Diagramm sieht danach hässlich aus, ist vielleicht nicht mehr verständlich und die Syntax ist ggfs. auch nicht mehr korrekt. Und mit Sternchen die fehlenden Teile im Diagramm zu kennzeichnen und auf der nächsten Seite nachzureichen trägt auch nicht zur Lesbarkeit bei. Das verwirrt die Prüflinge dann meist noch zusätzlich und sie verstehen ihre eigene Zeichnung nicht mehr.

Es gibt ggfs. Punktabzug für eine falsche Syntax.

Struktogramm und PAP sind standardisiert. Das heißt, es gibt eine verbindliche Syntax für die beiden Darstellungsformen. Und als Prüfer muss ich davon ausgehen, dass diese Darstellung bekannt ist. Wenn sie dann nicht standardkonform umgesetzt wird, weil z.B. ein Kreis anstelle eines Rechtecks verwendet wird, muss das eigentlich zu Punktabzug führen. Die Prüfer drücken sicherlich auch mal ein Auge zu, aber diese potentielle Fehlerquelle kann man sich sparen, indem man keine Diagramme nutzt.

Die Diagramme sind nicht mehr zeitgemäß.

Die genannten Diagramme stammen aus den 70er und 80er Jahren des letzten Jahrhunderts. Meiner Meinung nach sind sie heute nicht mehr zeitgemäß. Es gibt inzwischen Diagrammformen, z.B. aus der UML, die sinnvoller sind. Das heißt nicht, dass man sie als Prüfling nicht beherrschen muss. Nicht falsch verstehen: Ich rate nicht dazu, die Diagramme bei der Prüfungsvorbereitung zu ignorieren. Aber in der Praxis habe ich noch nie (!) eines der beiden Diagramme zur Modellierung oder zur Dokumentation genutzt. Wenn du also die Wahl hast (was bei den Programmieraufgaben der Fall ist), dann entscheide dich gegen die Diagramme.

Pseudocode

Sich gegen die Diagramme zu entscheiden, heißt, sich für Pseudocode zu entscheiden. Die Nachteile der Diagramme sind seine Vorteile:

  • Pseudocode ist schnell zu schreiben.
  • Pseudocode kann schnell und einigermaßen lesbar korrigiert werden.
  • Pseudocode ist nicht standardisiert und so ziemlich jede denkbare Syntax ist erlaubt.
  • Pseudocode ist nah an der echten Programmiersprache und damit immer zeitgemäß.

Der Vorteil für die Prüflinge beim Einsatz von Pseudocode ist ganz klar, dass man ihn fast „runterprogrammieren“ kann, wie man es aus der täglichen Arbeit gewohnt ist. Normalerweise wird z.B. kein Azubi Probleme mit der Definition einer for-Schleife haben. Und wenn man die Sytax aus der eigenen Programmiersprache kennt, kann man diese 1-zu-1 verwenden. Da Pseudocode wie gesagt nicht standardisiert ist, ist jede „echte“ Programmiersprache auch als Pseudocode verwendbar. Einfach die Klammern weglassen, um noch mehr Zeit zu sparen, und fertig ist der Pseudocode!

Allerdings wäre ich vorsichtig mit zu speziellen Sprachkonstrukten. Die Block-Syntax von Ruby oder das Pattern Matching aus F# würde ich nicht als allgemein bekannt bei den Prüfern voraussetzen. Also reduziere deinen Pseudocode auf die guten alten Bestandteile: Sequenz, Verzweigung, Wiederholung. Die meisten Aufgaben sind mit diesen Mitteln lösbar.

Fazit

Ich empfehle meinen Azubis grundsätzlich, Programmieraufgaben mit Pseudocode zu beantworten und keine komplizierten, zeitaufwändigen und schwer zu korrigierenden Diagramme zu zeichnen. In Podcast-Episode 4 gehe ich auch noch einmal auf das Thema Pseudocode vs. Stuktogramm/Programmablaufplan ein: Vorbereitung auf die schriftliche Abschlussprüfung.

Die genaue Syntax von Struktogramm und PAP kannst du übrigens im IT-Handbuch für Fachinformatiker* nachschlagen.

IT-Handbuch: IT-Systemelektroniker, -in, Fachinformatiker, -in*


Was hältst du von Pseudocode in Abschlussprüfungen? Kannst du meine Argumentation nachvollziehen oder setzt du eher auf eine Diagrammform?

Weitere Hilfen zur IHK-Prüfung

Du suchst noch mehr Tipps rund um die Vorbereitung auf die schriftliche IHK-Prüfung? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die schriftliche IHK-Prüfung.

Und kennst du schon meine Übungsaufgaben für die Abschlussprüfung? Unter dieperfekteihkpruefung.de kannst du sie herunterladen.

2 thoughts on “Pseudocode vs. Struktogramm und Programmablaufplan in der schriftlichen Abschlussprüfung

  1. Ich finde die Argumentation sehr gut und nachvollziehbar. Mir leuchten die genannten Vor- und Nachteile ein. Nun muss ich noch versuchen, dem Ausbildungsunternehmen zu vermitteln Pseudocode zu üben. Bisher wird das Nassi-Shneidermann-Diagramm als einzig akzeptiertes Format dargestellt. Demzufolge auch nichts anderes geübt. Auch wurde bisher nicht erwähnt, an welche Standards man sich dabei zu halten hat. Somit werde ich mich, im Anschluss an diesen Kommentar, ausführlich in meiner Freizeit damit beschäftigen. 🙂

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax