Um die Relevanz von Pseudocode-Aufgaben in den IHK-Prüfungen für
Anwendungsentwickler:innen, aber auch für Systemintegrator:innen,
und wie man sie am besten löst geht es in der
einhundertfünfundneunzigsten Episode des IT-Berufe-Podcasts. Inhalt
In dieser Episode des IT-Berufe-Podcasts thematisiere ich
Pseudocode-Aufgaben, die häufig Teil der schriftlichen
IHK-Prüfungen sind, und das nicht nur für
Anwendungsentwicklerinnen, sondern auch für andere Fachinformatiker
und insb. Systemintegratoren. Ich gehe darauf ein, warum diese
Aufgaben so zentral für die IT-Ausbildung sind und welche Relevanz
sie für die Prüfenden haben. Die grundlegende Idee hinter den
Pseudocode-Aufgaben ist es, das algorithmische Denken der Prüflinge
zu fördern und zu prüfen. Mein Ziel ist es, dir zu helfen, dich
optimal auf solche Prüfungen vorzubereiten. Ich beginne damit, die
Bedeutung von Pseudocode in den IHK-Prüfungen zu erläutern.
Pseudocode stellt sicher, dass ein allgemeines Verständnis der
Programmierung abgefragt wird, unabhängig von spezifischen
Programmiersprachen. Dies ist wichtig, da die Prüfer in der Lage
sein müssen, die Lösungen zu verstehen, egal welche
Programmiersprache verwendet wird. Ich erkläre die grundlegenden
Bausteine des Pseudocodes sowie die Anforderungen an die Korrektur
durch die Prüfer. Im weiteren Verlauf bespreche ich Strategien, um
Pseudocode effektiv zu schreiben. Ich gebe dir Empfehlungen, wie du
deine Lösungen strukturieren und formulieren kannst, um die
maximale Punktzahl zu erzielen. Dabei sind klare Einrückungen und
der Verzicht auf komplizierte Syntax entscheidend. Es wird auch
geraten, grundlegende Algorithmen zu verwenden und keine
spezifischen Features aus einer bestimmten Programmiersprache zu
nutzen. Neben der technischen Ausführung gehe ich auch auf die
psychologischen Aspekte der Prüfungsvorbereitung ein. Ich ermutige
dich, alte Prüfungen zu bearbeiten und regelmäßig zu üben, um ein
Gefühl für die Aufgaben zu bekommen. Feedback von Ausbildern oder
KI kann dir helfen, deine Fähigkeiten weiterzuentwickeln und
häufige Fehler zu vermeiden. Ich teile häufige Problemstellungen,
die in der Vergangenheit in Prüfungen aufgetreten sind, und zeige,
wie du diese vermeiden kannst. Abschließend lege ich großen Wert
auf die Notwendigkeit, ein starkes algorithmisches Verständnis zu
entwickeln. Der Fokus sollte nicht darauf liegen, die perfekte
Programmiersprache zu beherrschen, sondern darum, Probleme
effizient zu lösen und zu verstehen, welche Algorithmen und Logiken
hinter den Aufgaben stehen. Ich hoffe, dass diese Episode dich
inspiriert und dir hilft, dich optimal auf deine bevorstehenden
Prüfungen vorzubereiten. Wie schreibt man Pseudocode? In letzter
Zeit habe ich von vielen Prüflingen die Frage gestellt bekommen, ob
ich nicht eine Einführung in das Schreiben von Pseudocode geben
könnte. Ich frage dann immer direkt zurück, was denn so schwierig
an Pseudocode sei. Ich würde für die Programmieraufgaben in der
Abschlussprüfung immer Pseudocode verwenden und niemals eine
grafische Darstellung wie das Aktivitätsdiagramm. Die Diagramme
sind meist deutlich aufwändiger zu erstellen und bei Fehlern sehr
schwer zu korrigieren. Mit Pseudocode ist das deutlich einfacher.
Dennoch scheinen viele Azubis Probleme mit Pseudocode zu haben.
Standards Erst durch eine Mail eines Zuhörers habe ich erfahren,
dass es sogar Standards für Pseudocode gibt (z.B. Jana,
Pascal-Style oder nach Leierson, siehe Pseudocode). Ich habe weder
in meiner eigenen Prüfung noch in der Prüfungsvorbereitung mit
meinen Azubis das Thema Pseudocode jemals intensiv behandelt. Ich
empfehle immer, anstatt sich eine eigene Syntax für den Pseudocode
auszudenken, einfach normalen Code in der Prüfung zu schreiben. Da
es für Pseudocode keine allgemeinverbindlichen Vorgaben in der
Prüfung gibt, kannst du auch einfach "echten" Quellcode in
irgendeiner Programmiersprache verwenden. Wichtig ist, dass die
Prüfenden verstehen, was du erreichen möchtest. Im Zweifel
verstehen Prüfende das mit einer echten Programmiersprache sogar
besser, als wenn du erzwungenen Pseudocode, den du dir selbst
ausgedacht hast, verwendest. Meine Empfehlung Um dir die Arbeit
etwas zu erleichtern, lass einfach alle geschweiften Klammern weg.
Auch sonstige Syntaxelemente wie Semikolons am Ende der Zeile sind
überflüssig. Achte darauf, dass dein Programm gut zu verstehen ist
und überfrachte den wenigen Platz, den du auf dem Lösungsbogen zur
Verfügung hast, nicht mit Textelementen, die zur eigentlichen Logik
nichts beitragen. Fokussiere dich stattdessen darauf, die gestellte
Aufgabe zu lösen, also den Algorithmus abzubilden. Niemand
interessiert sich in der Prüfung dafür, ob du die Syntax einer
Programmiersprache beherrschst. Das ist nur Handwerkszeug. Deine
eigentliche Fähigkeit, die du unter Beweis stellen musst, ist das
Lösen von Problemen. Ich bringe meinen Auszubildenden die
Programmierung meist erstmal bei, indem sie Aufgaben auf Papier
lösen sollen. Wenn du z.B. nicht einmal mit einem Bleistift auf
einem Blatt Papier die Quadratwurzel einer Zahl berechnen kannst,
wie willst du es dann einem Computer beibringen? Du musst das
Problem verstanden haben, und wissen, wie man es lösen kann. Wenn
du diesen Algorithmus in deinem Kopf hast, kannst du ihn auch in
ein Programm überführen. Die konkrete Syntax, mit der du dies tust,
ist dann irrelevant. Und darum geht es in der Prüfung. Meine ganz
einfache Empfehlung ist also: Benutze Java, und lass alle unnötigen
Elemente weg. Also Klammern, Semikolons und so weiter. Aber achte
auf eine korrekte Einrückung! Beispiel Aus diesem echten
Java-Programm: public int berechneAlter(Date datum, Date
geburtsdatum) { int alter = datum.getYear() -
geburtsdatum.getYear(); if (datum.getMonth() <
geburtsdatum.getMonth()) { alter--; } else { if (datum.getMonth()
== geburtsdatum.getMonth()) { if (datum.getDay() <
geburtsdatum.getDay()) { alter--; } } } return alter; } Wird dieser
"Pseudocode": int berechneAlter d, g alter = d.year - g.year if
d.month < g.month alter-- else if d.month == g.month if d.day
< g.day alter-- return alter Das könnte schon fast als Ruby-Code
durchgehen! Fazit Da Pseudocode nicht standardisiert ist, kannst du
in der Abschlussprüfung irgendeine Programmiersprache verwenden,
die dir gut bekannt ist und in der du dich wohlfühlst. Konzentriere
dich auf das Lösen des Problems und die nachvollziehbare
Beschreibung deiner Problemlösung. Dann werden die Prüfenden dir
alle notwendigen Punkte geben. Pseudocode vs. grafische Darstellung
In so ziemlich allen schriftlichen IHK-Prüfungen der letzten Jahre
(vgl. Themen der schriftlichen Prüfungen) 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 aller Anwendungsentwickler:innen
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. Spoiler: Beantworte
Programmieraufgaben immer mit Pseudocode und nie mit einem
Aktivitätsdiagramm (oder früher 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 oder einem Aktivitätsdiagramm 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 wie das Aktivitätsdiagramm vorgegeben. Früher
waren es mal Struktogramm (bzw. Nassi-Shneiderman-Diagramm) und
Programmablaufplan, für die es sogar DIN-Normen gibt. Welche
Variante man wählt, hat keine Auswirkung auf die Bewertung durch
die Prüfenden. Mit jeder Darstellungsform kann man die komplette
Punktzahl holen. Warum ist es nun aber sinnvoll, nicht die
Diagrammform zu verwenden, sondern Pseudocode zu schreiben? Meiner
Meinung nach sprechen drei 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....
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.