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.

*

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