Explore every episode of the podcast IT-Berufe-Podcast

Um die realistische Dauer deiner IHK-Projektdokumentation geht es in der fünfzehnten Episode der Shorts des IT-Berufe-Podcasts.

Die wichtigste Aussage ist kurz: Plane für deine Projektdokumentation so viel Zeit ein, wie du bekommen kannst. Weil die Vorgaben der IHKen stark unterschiedlich sind und die Doku einen großen Einfluss auf deine Abschlussnote hat, lohnt es sich, deutlich mehr Zeit für Formulierung, Korrekturen, Feedback und saubere Aufbereitung einzuplanen. Die knappen "offiziellen" Zeitvorgaben für die umfangreiche Dokumentation sind unrealistisch, deshalb sollte die Doku in deiner Priorisierung weit oben stehen.

Inhalt Wie viel Zeit du für die Projektdokumentation einplanen solltest

Die kurze Antwort lautet: so viel Zeit, wie deine IHK dir erlaubt. Praktisch heißt das aber: Plane eher mehr Zeit ein, als offiziell irgendwo steht, weil die Projektdokumentation ein zentrales Prüfungsartefakt ist und einen großen Anteil an deiner Abschlussnote hat.

Unterschiedliche Vorgaben der IHKen

Ein zentrales Problem ist, dass die IHKen in Deutschland nicht überall gleich vorgehen.

• Manche IHKen erlauben, die Projektdokumentation innerhalb der offiziellen Projektzeit zu schreiben.
• Andere IHKen erlauben das nicht oder machen andere Vorgaben.
• Teilweise gibt es sogar feste Zeitanteile, zum Beispiel 15% der Projektzeit.
• Bei 80 Stunden Projektzeit in der Anwendungsentwicklung wären das dann 12 Stunden für die Dokumentation.
• Andere IHKen machen gar keine konkrete Zeitvorgabe, sodass du faktisch bis zur Abgabe daran arbeiten kannst.

Dadurch entstehen sehr unterschiedliche Voraussetzungen. Wenn eine Person nur 12 Stunden einplanen darf und eine andere faktisch deutlich mehr Zeit nutzen kann, wirkt sich das fast zwangsläufig auf die Qualität der Dokumentation aus.

Warum mehr Zeit sinnvoll ist

Die Projektdokumentation wird bewertet. Entscheidend ist am Ende nicht, ob du exakt eine vorgegebene Stundenzahl eingehalten hast, sondern wie gut das Ergebnis ist.

Deshalb sollte die Doku möglichst sauber und vollständig sein:

• Fehler korrigieren
• sauber formulieren
• Referenzen prüfen
• ein ordentliches Inhaltsverzeichnis erstellen
• Bilder und Artefakte sinnvoll in Anhang oder Dokument einbauen
• andere Personen Korrektur lesen lassen

Die Empfehlung ist deshalb klar: Nutze jede realistisch verfügbare Zeit, um die Dokumentation rund zu machen.

Offizielle Planung und praktische Realität

Wenn deine IHK eine feste Zeitvorgabe macht, sollte diese natürlich in Projektplanung, Antrag und Dokumentation auftauchen. Gleichzeitig ist die Empfehlung, in der Realität trotzdem alle sinnvollen Möglichkeiten zu nutzen, um die Doku zu verbessern.

Der Grund: Eine gute Note bekommst du nicht dafür, dass du nur wenig Zeit investiert hast, sondern dafür, dass die Dokumentation am Ende gut ist.

Warum knappe Zeitvorgaben unrealistisch sind

Gerade bei umfangreichen Dokumentationen mit zum Beispiel 40 oder 50 Seiten sind die sehr kleinen "offiziellen" Zeitvorgaben aus meiner Sicht unrealistisch.

Denn zur Arbeit an der Doku gehört mehr als nur Schreiben:

• viele Seiten Text formulieren
• Inhalte überarbeiten
• Layout und Struktur sauber setzen
• Anhänge, Bilder und weitere Artefakte einbauen
• zusätzliche Materialien teilweise erst erstellen

Eine umfangreiche, sauber gesetzte PDF-Dokumentation in nur 12 Stunden zu erstellen, ist nicht realistisch!

Priorisierung: Doku vor Perfektion im Projekt

Die klare Empfehlung lautet, deine Zeit nach dem Einfluss auf die Note zu priorisieren.

Das bedeutet im Zweifel:

• lieber etwas weniger programmieren, konfigurieren oder installieren
• dafür mehr Zeit in die Projektdokumentation stecken

Begründung:

• Die Doku hat einen sehr hohen Einfluss auf die Abschlussnote.
• Das eigentliche Projekt kannst du in Präsentation und Doku ohnehin nur ausschnittweise zeigen.
• Deshalb kann zusätzliche Zeit für Formulierung, Überarbeitung und Feinschliff bei der Doku mehr Wirkung auf die Bewertung haben als noch mehr Arbeit am eigentlichen Projekt.

Natürlich kann man diese Prüfungslogik kritisch sehen – und das tue ich selbst auch. Denn eine umfangreiche Dokumentation zeigt nicht automatisch, wie gut jemand beruflich handlungsfähig ist. Solange die Prüfungsstruktur aber so ist wie sie ist, sollte man als Prüfling das Beste daraus machen.

Zusätzlicher Zeitdruck in der Abschlussphase

Diese Empfehlung ist in der Praxis nicht immer leicht umzusetzen. Gegen Ende der Ausbildung kommen oft mehrere Belastungen zusammen:

• laufende Arbeit im Ausbildungsunternehmen
• teilweise keine vollständige Freistellung
• in manchen Fällen Projektarbeit außerhalb der Arbeitszeit
• Vorbereitung auf die AP2
• Vorbereitung auf Projektpräsentation und Fachgespräch
• Durchführung des eigentlichen Projekts
• Schreiben der Dokumentation

Trotzdem bleibt die Doku aus Bewertungssicht ein Schwerpunkt, den du bei deiner Zeitplanung besonders beachten solltest.

Abgrenzung: Projektdokumentation ist nicht dasselbe wie Benutzer- oder Entwicklerdoku

Zum Schluss unterscheide bitte nochmal ganz klar zwischen den verschiedenen "Dokumentationen".

Projektdokumentation

Das ist das Prüfungsartefakt, um das es im gesamten Podcast geht.

Fachliche Dokumentation im Projekt

Dazu gehören zum Beispiel:

• Benutzerhandbuch
• Entwicklerdokumentation
• Klassendiagramm
• Administrationsdokumentation
• Netzplan

Diese Unterlagen gehören ohnehin zum Projekt dazu und sind Pflichtbestandteile. Dafür gibt es bei vielen IHKen eigene Bewertungsanteile. Wenn solche Dokumentationen fehlen, kann sich das direkt negativ auf die Note auswirken.

Realistische Planung für diese fachlichen Doku-Anteile

Für diese projektbezogenen Dokumentationen sollte die Zeitplanung realistisch bleiben.

• Ein sehr umfangreiches Handbuch mit unrealistisch wenig angesetzter Zeit passt nicht.
• Kleinere Dokumentationsartefakte wie ein Netzplan oder ähnliche Unterlagen können dagegen mit wenigen Stunden realistisch geplant werden.

Fazit

Meine Kernaussage ist eindeutig: Investiere in die Projektdokumentation lieber mehr Zeit als zu wenig. Wegen der hohen Bedeutung für deine Note, der sehr unterschiedlichen IHK-Vorgaben und der unrealistischen offiziellen Zeitvorgaben lohnt es sich, genügend Zeit für Überarbeitung, Feedback und Feinschliff einzuplanen. Eine gute Dokumentation kann mehr Einfluss auf dein Ergebnis haben als zusätzliche Detailarbeit am eigentlichen Projekt.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts

Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode

[0:21] So, heute habe ich mal ein kleines Thema mitgebracht und ich glaube, heute wird es wirklich mal ein Short. Und die Frage, die ich heute behandeln möchte, ist, wie viel Zeit sollte ich für meine Projektdokumentation einplanen? Also du weißt schon, das Prüfungsartefakt, das, was du dem Prüfungsausschuss vorlegst, wo ein sehr, sehr großer Teil deiner Abschlussnote von abhängt. Ja, genau dieses Ding, was je nach IHK zwischen 20 und 60 Seiten lang sein kann oder vielleicht noch kleiner oder noch länger. Ich weiß das nicht von allen 79 IHK, aber sagen wir mal im Durchschnitt vielleicht 30, 40, 50 Seiten. Dieses Ding, was du dann wahrscheinlich über eine Online-Plattform einreichst oder ausgedruckt und gebunden und ja, auch das habe ich schon gehört, bei der IHK einreichst, damit das bewertet werden kann. Wie viel Zeit brauchst du dafür? Und das Too Long Didn’t Read, was ich immer Games by Einschieger mache, ist, ganz kurz gesagt, so viel wie deine IHK dir erlaubt. So, was soll das wieder heißen?

[1:18] Du weißt, 79 IHK gibt es in Deutschland. Jede macht wieder mal so ein bisschen ihr eigenes Ding, wenn sie möchte. Die meisten halten sich auch vielleicht eine einheitliche Vorgabe. Aber einige Sachen sind in den Berufsverordnungen der IT-Berufe halt nicht einheitlich geregelt. Zum Beispiel, ob die Projektdokumentationen überhaupt in deinen 80 oder 40 Stunden Projektzeit geschrieben werden dürfen. Einige IHK erlauben das, andere nicht. Und es kommt darauf an, wie man Gesetzestexte interpretiert und wer bei der IHK was entscheidet. Und ich weiß nicht, wovon es noch abhängt. Deswegen gibt es einfach ein Wir-Wahr an verschiedenen Lösungen und an verschiedenen Vorgaben und verschiedenen Wünschen, die IACAN so an diese Abschlussprojekte haben. Und da kann es dann durchaus sein, dass es da vielleicht auch harte Vorgaben gibt. Zum Beispiel innerhalb deiner Projektzeit ist das einzuplanen mit exakt 15 Prozent deiner Zeit. Und das wäre dann bei Anmerkungsentwicklung, wenn ich 80 Stunden habe, 12 Stunden der Projektzeit. Muss dann für die Projektdokumentationen. Eingesetzt werden. Andere IHK erlauben, dass man das einfach außerhalb der Projektzeit schreiben kann und geben gar keine Zeitvorgabe. Das heißt, da hast du quasi unendlich viel Zeit, also bis zur Abgabe der Doku natürlich, um deine Doku zu schreiben. Und da sieht man schon irgendwie, dass das ein bisschen unfair ist. Also wenn IHK einen Vorgaben machen, du darfst maximal zwölf Stunden dran sitzen und andere haben quasi unendlich viel Zeit.

[2:36] Wie unterschiedlich sehen diese Dokus dann wohl aus, wenn ich wirklich nur zwölf Stunden in dieses Dokument stecke? Das kann ich ja gar nicht. so gut formulieren, gestalten, die Referenzen prüfen und ich weiß nicht was alles, wie jemand, der unendlich Zeit dafür hat. Also, da sieht man schon irgendwie, dass das alleine schon unfair ist. Und deswegen muss ich ehrlich gesagt sagen, aus meiner Sicht als Prüfer empfehle ich das sogar, es ist ganz egal, was dein IHK dir für Vorgaben macht. Nutze einfach so viel Zeit, wie du kriegen kannst, und mach diese Dokumentation perfekt, in Anführungszeichen. Lass da jemanden Korrektur lesen, im besten Fall jemanden, der sich auskennt, Ausbilder, Ausbilderin vielleicht.

[3:15] Korrigiere alle Fehler, die dir auffallen, mach die Referenzen sauber, mach ein vernünftiges Inhaltsbezeichnis, pack alle Bilder in den Anhang etc. Mach das Ding rund. Das ist dein Prüfungsartefakt. Das Ding wird bewertet. Und am Ende wirst du nicht eine Eins dafür kriegen, weil du exakt zwölf Stunden daran gearbeitet hast, aber das Ding sieht aus wie Grütze, sondern die Leute werden dieses Ding nehmen, was aussieht wie Grütze und werden das bewerten. Und dann guckt auch keiner mehr danach, ob du zehn oder zwölf oder dreihundert Stunden dran gesessen hast, wenn es Mist ist. Das heißt, um allein diesen Nachteil auszugleichen, dass andere IHK den Prüfling quasi unendlich viel Zeit geben für die Bearbeitung, würde ich sagen, das ist schön, dass du da solche Vorgaben hast, das schreibst du dann auch schön in deine Projektplanung rein, in den Antrag und in der Doku wiederholst du es nochmal, aber in der Realität nutzt du bitte sämtliche Zeit, die du hast, um diese Doku rund zu machen. Alles andere wäre dumm.

[4:08] So, das ist meine persönliche Empfehlung. Deswegen sage ich, du hast so viel Zeit, wie deine IHK dir erlaubt, aber rechne mit deutlich mehr Zeit. Am Ende ist dieses eine Prüfungsartefakt, die Projektdokumentation, das Ding, was am meisten Anteil an deiner Abschlussnote hat. Also wäre es doch blöd, da so wenig Zeit wie möglich zu investieren. Ich würde stattdessen einfach so viel Zeit wie möglich investieren. Und ich würde sogar sagen, im Zweifel programmierst du ein bisschen weniger oder konfigurierst ein bisschen weniger oder installierst ein bisschen weniger und schreibst mehr an der Dokumente, weil das ist das Ding, was bewertet wird. Ist das gut, dass man IT-Berufe so bewertet? Darüber kann man streiten. Ich finde, das ist auch nicht die beste Wahl, um.

[4:51] Herauszufinden, ob jemand seinen Beruf beherrscht, dass man ein 40-seitiges Dokument darüber schreibt, vor allem mit Hilfe von KI zum Beispiel heute oder früher auch schon, gab es immer schon Ausbilder, die drüber geguckt haben und das korrigiert haben. Also wie viel Aussagekraft hat dieses Dokument da noch? Da kann man jetzt wirklich sehr schön drüber streiten und dann auch Vorschläge machen, dass das in Zukunft vielleicht anders ist. Aber solange das nicht passiert ist und wir diese Prüfungsordnung und Struktur noch so haben, würde ich sagen, halt dich dran und hol das Beste für dich raus. Ich sage es immer wieder, die Doku, das ist das Ding, was du in deiner Hand hast, aus meiner Vorgabe jetzt hier, nimm dir so viel Zeit, wie du brauchst. Du kannst das tausendmal Korrektur lesen, du kannst es eine Woche liegen lassen vor der Abgabe und dann nochmal drauf gucken. Du kannst jemand anderen drüber lesen lassen, Du kannst ganz viel Zeit investieren, bis das Ding halt vernünftig und rund ist. Und die würde ich auf jeden Fall auch investieren.

[5:42] Und ganz ehrlich, wenn jemand bei einer IHK sagt, ich erwarte von dir ein 50-seitiges, perfekt gesetztes PDF-Dokument innerhalb von maximal zwölf Stunden, da sind wir uns, glaube ich, alle einig, dass das absolut utopisch ist. Das wird niemand hinbekommen. Auch wenn du dein Projekt perfekt umgesetzt hast, allein die Formulierung von so vielen Seiten Text dauert definitiv länger als zwölf Stunden. Dann kommt noch hinzu, du musst vernünftig setzen, du musst die ganzen Artefakte, Anhänge, Bilder etc. da reinbauen. Die musst du teilweise für die Doku ja sogar noch anfertigen extra. Also das ist alles völlig unrealistisch. Da sind wir uns hoffentlich alle einig. Und wenn dann tatsächlich jemand kommt und sagt, Moment, wir wollten von dir 50 Seiten haben und du hast uns tatsächlich 50 Seiten geliefert, obwohl du nur 12 Stunden Zeit hattest, wie ist das denn überhaupt möglich?

[6:28] Dann tut mir leid, schneiden die Leute sich ins eigene Fleisch. Also da wird keiner nachfragen. Es wissen alle, die an dieser Prüfung beteiligt sind, dass diese Vorgaben absoluter Bullshit sind. Und deswegen geh davon aus, dass du die Zeit investieren kannst. Die Leute werden dich nicht danach fragen, wie lange du da dran gesessen hast, sondern werden das einigermaßen realistisch auch in der Zeitplanung, wenn es denn Vorgabe ist, der IHK berücksichtigt ist, dann wird da kein Mensch nachfragen, weil sowieso alle wissen, dass das alles ausgedachte Zahlen sind und deswegen nimm dir die Zeit, lass das Ding Korrektur lesen, mach das Ding rund und gib es dann ab und dann hast du alles getan, was du tun kannst, damit du da auch eine gute Note bekommst. Also, nimm dir so viel Zeit, wie du kriegen kannst, ganz blöd gesagt. Das hört sich jetzt so einfach an. Ich weiß, einige Prüflinge müssen neben dieser Projektarbeit auch noch richtig arbeiten. Das heißt, da ist das Ausbildungsunternehmen hinterher, dass man auch ein bisschen Geld verdient für das Unternehmen. Da wird man nicht freigestellt. Ich habe sogar schon von Unternehmen gehört, da muss man die Projektarbeit außerhalb der Arbeitszeit machen. Also gut, das ist jetzt heute hier nicht das Thema. Auf jeden Fall kann es ja sein, dass du in deinem Projektzeitraum noch ein bisschen Stress hast. Ach ja, da steht ja noch so eine AP2 an, für die du lernen musst. Projektpräsentation, Fachgespräch muss vorbereitet werden und dann auch noch tatsächlich eine Software entwickeln oder Netzwerk planen oder was auch immer du so machst und dann auch noch diese Doku schreiben. Also gegen Ende der Ausbildung wird es ein bisschen knapp zeitlich auch manchmal.

[7:46] Von daher wird es manchmal auch schwierig, sich die Zeit damit zu nehmen. Aber halt dir nochmal vor Augen, die Doku ist das eine Prüfungsartefakt mit dem höchsten Impact auf deine Note. Der größte Teil der Note, der geht von der Doku aus. Und demnach würde ich meine Zeiten auch priorisieren. Steck da die Zeit rein, das ist am Ende, ja, wie gesagt, hat mehr Impact, wirkt sich mehr auf deine Note aus, als die Software rund zu programmieren. Weil die kannst du in deiner kurzen Präsion und einer kurzen Doku sowieso nicht komplett zeigen. Also würde ich tatsächlich lieber ein bisschen mehr Text schreiben und ein bisschen den Text umformulieren, schöner machen, etc..

[8:24] Als die Zeit in das echte Projekt zu stecken. Wie gesagt, ich persönlich finde diese Empfehlung bescheuert, weil ich natürlich eigentlich will, dass die Leute beruflich handlungsfähig werden, weil das ist der Auftrag der beruflichen Ausbildung. Und nicht, dass man schön PDF-Dateien schreiben kann. Aber wie gesagt, solange die Prüfungsstruktur so ist, würde ich empfehlen, wenn du das Beste rausholen willst, investiere die Zeit in die Doku. Übrigens, kurze Abgrenzung zum Schluss, eine Benutzer-Dokumentation, Entwickler-Dokumentation, Admin-Dokumentation, was auch immer, gehört natürlich sowieso zum Projekt dazu. Also ein Handbuch für die Benutzer oder ein Klassendiagramm für die Entwickler oder ein Netzplan für die Physikollegen. Das ist sowieso Teil der Projektarbeit, das musst du eh immer machen. Das ist bei unserer IHK zum Beispiel, allein dafür kriegt man 15% der Note. Das heißt, wenn du ein Projekt abgibst, wo keine Dokumentation drin ist und nicht die Projektdokumentation, die hier gemein ist, sondern das, was ich eben aufgezählt habe, dann kannst du schon keine, was ist es, 15%, 85%, kriegst du noch eine 2, aber du kannst schon keine 1 mehr bekommen, wenn du keine Dokumentation drin hast. Also die gehört immer da rein. Dafür gibt es auch keine Ausnahme. Das ist Pflichtprogramm quasi, ein Pflichtartefakt aus meiner Sicht in jeder Projektarbeit.

[9:32] Und da muss es natürlich einigermaßen realistisch sein. Also du kannst nicht noch ein 70-seitiges Benutzerhandbuch zu deinem Projekt erstellen und dann in die Projektplanung schreiben, dafür habe ich vier Stunden gebraucht. Also das ist natürlich, das passt überhaupt nicht. Ja, so, also das muss einigermaßen realistisch sein, aber sind wir mal ganz ehrlich, ich habe jetzt irgendwie, ich habe zwei Wochen was programmiert oder ich habe eine Woche lang irgendwie was auch immer Netzwerk geplant oder so, da werde ich dann jetzt nicht noch 20 Stunden brauchen, um da jetzt einen Netzwerkplan für zu zeichnen. Also da sind wir dann mit wenigen Stunden dabei, zwei, drei Stunden oder sowas für die Doku, dann passt das.

[10:03] Aber die Projektdokumentation mit all die Artefakten etc., das ist ja wirklich ein, für viele Azubis tatsächlich, die größte Arbeit, die sie bis dahin geschrieben haben. Es gibt ja auch viele Azubis, die zum Beispiel kein Abi gemacht haben, keine Facharbeit oder sonst irgendwas geschrieben haben. Und das schreibt man nicht mal eben runter. So ein 50 Seiten Ding. Ja, also das ist völlig utopisch. Deswegen plan da vernünftig Zeit ein, plan auch Feedback schleifen ein, lass da jemanden rübergucken. Ich sag’s jetzt zum dritten Mal, deswegen würde ich sagen, wir hören das mal auf, weil ich fang mir an zu wiederholen. Also nimm dir so viel Zeit, wie die IHK erlaubt, aber mach lieber doch mehr, weil dieses eine Prüfungsartefakt ist so wichtig für deine Note. Es wäre dumm, wenn du die Zeit nicht investierst.

[10:43] So, das war’s für heute. Bis zum nächsten Mal.

Um die exakte Einhaltung der Projektbearbeitungszeit (40 bzw. 80 Stunden) beim Abschlussprojekt geht es in der vierzehnten Episode der Shorts des IT-Berufe-Podcasts.

Für die betriebliche Projektarbeit solltest du die vorgegebene Zeit von 40 Stunden bzw. 80 Stunden in der Anwendungsentwicklung praktisch exakt einhalten. Mehr Zeit kann zum Nichtbestehen führen, weniger Zeit ist zwar rechtlich grundsätzlich möglich, verschlechtert aber unnötig deine Prüfungsleistung. Wenn deine Planung oder die IHK-Vorgaben unklar sind, solltest du das vor dem Projektantrag klären und dein Projekt so darstellen, dass du am Ende genau auf die erlaubte Stundenzahl kommst.

Inhalt

Kernaussage

Für die betriebliche Projektarbeit gelten feste Zeitvorgaben: 40 Stunden in den meisten IT-Berufen und 80 Stunden in der Fachrichtung Anwendungsentwicklung. Diese Zeit solltest du im Projektantrag und in der Projektdurchführung möglichst exakt einhalten.

Zeitvorgaben: mehr geht nicht

Die rechtliche Grundlage – die Berufsverordnung – nennt für die betriebliche Projektarbeit eine Prüfungszeit von höchstens 80 Stunden. Daraus folgt:

• Weniger Zeit ist rechtlich grundsätzlich erlaubt.
• Mehr Zeit ist nicht erlaubt.
• Wenn du die erlaubte Zeit überschreitest, hältst du die Prüfungsvorgaben nicht ein und könntest dadurch durch die Prüfung fallen.

Deshalb sollte in deiner Zeitplanung am Ende genau die erlaubte Stundenzahl stehen:

• 40 Stunden in den meisten IT-Berufen
• 80 Stunden in der Anwendungsentwicklung

Warum die exakte Planung erwartet wird

Projektplanung gehört zu den Ausbildungsinhalten in allen IT-Berufen. Dazu gehört auch, zeitliche Vorgaben einzuhalten. Auch wenn eine Planung auf die Stunde genau in der Realität oft unrealistisch ist, wird in der Prüfung erwartet, dass du dich an die formalen Vorgaben hältst.

Dazu kommt:

• Prüfungsleistungen sollen vergleichbar sein.
• Ohne feste Obergrenze könnten einzelne Prüflinge deutlich mehr Zeit investieren als andere.
• Größere Projekte würden auch zu umfangreicheren Dokumentationen führen, die von Prüfenden gelesen werden müssten.

Weniger Zeit ist zwar erlaubt, aber unklug

Auch wenn das Gesetz "höchstens" sagt, ist weniger Zeit aus Sicht der Prüfungsleistung keine gute Idee. Wenn du freiwillig weniger Zeit nutzt,

• zeigst du weniger von deinen Fähigkeiten,
• nutzt deinen möglichen Bewertungsrahmen nicht aus,
• und stellst dich schlechter dar als jemand, der die volle Zeit sinnvoll ausschöpft.

Die Aussage dazu ist klar: Weniger Zeit zu planen oder zu nutzen ist möglich, aber für deine Note eher nachteilig.

Pufferzeit im Projektantrag

Manche planen im Antrag bewusst Pufferzeit ein, weil Projekte nie perfekt planbar sind. Dabei gilt aber:

• Ob das erlaubt oder sogar gewünscht ist, hängt von der IHK ab.
• Es gibt IHKs, die einen Puffer akzeptieren oder fordern.
• Es gibt auch Fälle, in denen ein Antrag mit eingeplanter Pufferzeit abgelehnt würde.

Die Empfehlung ist deshalb:

• Informiere dich vorher bei deiner IHK, welche Erwartungen gelten.
• Reiche den Antrag möglichst direkt passend ein, damit er nicht wegen solcher Punkte zurückkommt.

Warum ein abgelehnter Antrag problematisch ist

Wenn dein Projektantrag abgelehnt wird und du ihn überarbeiten musst,

• verlierst du Zeit durch Überarbeitung und erneute Prüfung,
• darfst du mit dem Projekt erst nach Genehmigung anfangen,
• und bekommst dadurch zusätzlichen Zeitdruck.

Deshalb ist es sinnvoll, die formalen Anforderungen vorab zu klären.

Abweichungen vom Projektantrag helfen bei Überziehung nicht

Auch wenn es in Projektdokumentationen oft ein Kapitel zu Abweichungen vom Projektantrag gibt, kannst du damit keine längere Projektzeit rechtfertigen. Wenn dein Projekt mit 80 oder 40 Stunden genehmigt wurde, bleibt diese Vorgabe bestehen.

Das heißt:

• Eine Überschreitung lässt sich nicht einfach dadurch retten, dass du sie in der Doku erwähnst.
• Der Prüfungsausschuss kann das als Verstoß gegen die Vorgaben werten.

Umgang mit Abweichungen während des Projekts

Wenn du in einer Projektphase mehr Zeit brauchst als geplant, solltest du in der Darstellung dafür sorgen, dass du diese Zeit in einer anderen Phase wieder einsparst, damit du am Ende insgesamt auf die erlaubte Stundenzahl kommst.

Typisch ist dann ein Soll-Ist-Vergleich, in dem beschrieben wird, dass an einer Stelle mehr Zeit nötig war und an anderer Stelle entsprechend weniger. Auch wenn das in der Realität oft konstruiert wirkt, ist genau das Teil des Prüfungssystems.

Fazit

Die Antwort auf die Ausgangsfrage ist eindeutig:

• Mehr als die erlaubten 40 bzw. 80 Stunden solltest du nicht haben.
• Weniger wäre zwar grundsätzlich möglich, ist für deine Prüfungsleistung aber nicht sinnvoll.
• Plane dein Projekt so, dass du am Ende genau auf die vorgegebene Stundenzahl kommst.
• Wenn es Unklarheiten zu Pufferzeiten oder Formvorgaben gibt, kläre das vorher mit deiner IHK.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• FIAusbV: Verordnung über die Berufsausbildung zum Fachinformatiker und zur Fachinformatikerin

Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode

[0:21] Heute habe ich mal ein Thema mitgebracht, woran ich immer denken muss, wenn ich mir wieder Projektanträge für die betriebliche Projektarbeit anschaue. Und zwar, muss ich eigentlich die vorgegebene Zeit für mein Projekt, nämlich 40 Stunden bei allen IT-Berufen und 80 Stunden bei der kleinen Ausnahme für AmnungsentwicklerInnen, muss ich diese Zeit eigentlich einhalten oder darf ich auch mehr oder weniger Zeit für mein Projekt haben?

[0:46] Und kurz vorweg gesagt, nein, du darfst nicht mehr oder weniger haben. Du solltest ziemlich genau exakt auf diese Zahl kommen. Etwas aufgeweicht, ja, du darfst auch weniger Zeit aufwenden, aber das wäre dumm, aber da kommen wir gleich drauf. Aber wenn du überziehst, hast du ein Problem, damit kannst du durch die Prüfung fallen. Das heißt, das solltest du auf keinen Fall machen. Deswegen nehmen wir erst mal das Daumenregel mit. In deiner Zeitplanung sollten unten exakt 40 Stunden für alle IT-Berufe außer Anbietungsentwicklung bzw. 80 Stunden für die Anbietungsentwicklung stehen. Alles andere ist nicht so sinnvoll. Und da gucken wir jetzt mal drauf, warum das so ist. Also Nummer 1, Abweichungen nach unten sind grundsätzlich okay, aber dumm. Aber wir gucken mal warum. Und zwar schauen wir als allererstes mal auf die gesetzliche Grundlage, die Berufsverordnung. Und da weißt du vielleicht, wir haben sieben verschiedene IT-Berufe, die alle einzelne Berufsverordnungen teilweise haben, beziehungsweise der Fachnummer hat gerade eine mit vier Unterpunkten für die einzelnen Fachrichtungen und so weiter. Aber du kannst dir die alle online angucken. Besetztes Texte sind frei verfügbar. Und ich nehme jetzt einfach mal den Paragraf 12, der FIE aus BF, also der Berufsverordnung für die Fachinformatiker. Und den findest du ziemlich genau, exakt so formuliert auch in allen anderen IT-Berufsverordnungen.

[2:01] Und da steht in Paragraf 12, Absatz 2, die Prüfungszeit beträgt für die betriebliche Projektarbeit und für die Dokumentation mit praxisbezogenen Unterlagenlagen, höchstens 80 Stunden. Die Prüfungszeit beträgt höchstens 80 Stunden. Kurz zusammengefasst. So, höchstens steht da. Da steht nicht, du musst exakt auf 80 Stunden kommen, was ja sowieso völlig unrealistisch ist. Kein Mensch kann ein Projekt so gut planen, dass er exakt genau 80 Stunden braucht. Sind wir uns alle einig, dass das sowieso Quatsch ist, glaube ich. Aber höchstens heißt, ich darf auch weniger. So steht es erstmal im Gesetz. Das heißt aber, höchstens heißt inklusive 80, aber darüber ist es vorbei. Das heißt, mehr ist nicht. Wenn du also länger gebraucht hast, dann hast du dich nicht an diese Vorgaben zur Prüfung gehalten und dann könntest du deswegen durch die Prüfung fallen.

[2:50] So wie mein Beispiel in meinem Prüfungskurs war, dein Chef gibt dir 100 Euro mit, um Brötchen zu kaufen und dann kommst du wieder und sagst, ja Chef, ich habe 110 ausgegeben. Ja, das ist schön, aber das war nicht dein Budget. Und was ist dann das Endergebnis? Du musst die 10 Euro auf deine eigenen Tasche zahlen, außer du hast einen vernünftigen Chef, der gibt dir das Geld dann wieder, weil dafür hast du leckere Brötchen geholt. Aber so mal als Beispiel, wenn du ein Budget hast, was du einhalten musst, dann kannst du auch nicht sagen, ja, sorry, ich habe es doppelt so viel ausgegeben. So, das geht nicht, kann man nicht machen. Und hier ist es auch so, wenn es exakte Vorgabe ist, halte ich an 80 Stunden, mehr geht nicht und du machst mehr. Ja, dann kann man dich deswegen durch die Prüfung fallen lassen, weil du einfach nicht an diese Vorgaben dich gehalten hast. Das ist nicht gut. So, vor allem gehört Projektplanung in allen IT-Berufen zu den Ausbildungsinhalten. Da steht ein Ausbildungsrahmenplan drin, Projektplanung, das gehört auf jeden Fall dazu, das muss man lernen in jedem IT-Beruf. Und früher war das sogar explizit in der Verordnung genannt unter dem Punkt zeitliche Vorgaben einhalten. Dieser Begriff, zeitliche Vorgaben ein, stand explizit in der Berufsordnung in allen IT-Berufen, was man da vermitteln musste. Heute ist es ein bisschen aufgeweicht und so ein bisschen schwammig, Projektplanung und so weiter. Aber gehört dazu. Ich kann, wenn ich Software-Entwicklungsprojekte zum Beispiel plane, auch nicht sagen, ich brauche irgendwas zwischen 100 und 1000 Personentagen.

[4:06] Die wollen das schon ein bisschen genauer wissen, die Leute, die das Geld dafür bezahlen. Und deswegen gehört das zum Ausführungsinhalt dazu. Und da kann ich auch nicht mal mein Abschlussprojekt sagen, irgendwas zwischen 10 und 100 Stunden. Das geht nicht. Man muss es schon vernünftig planen. So, wir sind uns alle einig, dass diese Planung sowieso utopisch, unrealistisch und meistens komplett überzogen wird in der Realität.

[4:28] Aber das heißt nicht, dass du das in deiner Doku auch so schreiben musst unter deinem Projektantrag, sondern da erwarten halt alle formale Vorgabe 80 Stunden. Also halt dich dran und mach nicht mehr.

[4:39] Also, machst du zu viel, kannst du durchfallen. Wenn du Glück hast und du hast die Planung schon im Projektantrag überzogen, dann wird man einfach deinen Projektantrag ablehnen und sagen, hier anpassen, maximal 80 Stunden, maximal 40 Stunden, was auch immer. Dann ist es gut. Aber angenommen, wir würden das erlauben, dass du mehr machen darfst, da könnte ja jeder Prüfling jetzt einfach lustig überziehen, wie er oder sie halt Bock hat. Und was haben wir dann für Projekte? Die dauern auf einmal 100 Stunden. Ja, okay, 200 Stunden. Ist das noch okay? 300 Stunden? Also wie lange wollen wir den Prüflingen denn erlauben, ihr Projekt zu machen? Und am Ende ist es dann ja auch nicht mehr vergleichbar. Einer, der 300 Stunden investiert hat und jemand, der 40 investiert hat, da muss ja was ganz anderes rauskommen von der Qualität her. Also man muss es irgendwie vereinheitlichen. Außerdem, das Projekt muss ja auch von Prüfenden, wie zum Beispiel mir, gelesen werden, die Dokumentation. Und wenn wir ein 300-Stunden-Projekt dokumentiert haben mit, wie viele Seiten sollen denn da rauskommen? 100 Seiten? Wer soll denn sowas lesen in seiner Freizeit? Das ist ja alles Ehrenamtlich, das Prüferamt. Das heißt, das funktioniert nicht, deswegen müssen wir immer eine Grenze setzen und die ist halt laut Gesetz bei 40 Stunden bis 80 Stunden gesetzt, also halt dich dran. Nach oben hin. So, jetzt steht aber ja höchstens im Gesetz, du darfst also weniger Stunden investieren, aber da frage ich jetzt einfach mal, warum willst du das machen? Warum solltest du das machen? Klar, du kannst sagen, ja, ich habe einfach keinen Bock zu arbeiten, ich mache einfach weniger. Ja, okay, Aber hier geht es ja um deine Prüfungsleiste und dafür kriegst du ja eine Note.

[6:03] Und wenn du jetzt freiwillig auf Zeit verzichtest, die du investieren könntest, um eine bessere Note zu bekommen, warum solltest du das tun? Ich habe auch mal einen Short aufgenommen zu der sinnvollen Anzahl an Seiten der Projektdokumentation. Wenn du eine erlaubte Vorgabe von 15 Seiten hast, warum willst du 13 abgeben? Das ist dumm, weil wenn du irgendwie eine schlechtere Note als 100 Prozent bekommst, wirst du dich ja immer fragen, so, hm, hat es an den zwei Seiten gelegen? Hätte ich noch was unterbringen können, was mir die Note verbessert hätte? Und die Antwort ist wahrscheinlich ja. Das heißt, hier ist es genauso. Warum willst du ein Projekt in weniger Zeit umsetzen? Dann kannst du ja weniger von deinem Beruf, von deinen Fähigkeiten zeigen, als jemand, der die 80 Stunden ausgereizt hat. Also du machst dich ja schlechter damit. Du stellst dich ja unter jemand anderen, der die Zeit ausgenutzt hat. Also warum solltest du das tun? Ist ja dumm einfach. Deswegen mach es nicht. Und in einigen Projektanträgen habe ich schon sowas gelesen, wie eine Pufferzeit eingeplant. Sowas wie, ich weiß ja nicht, was passiert. Ich kann ein Projekt nicht 100% perfekt genau planen, auch wenn es nur 80 oder 40 Stunden sind. Deswegen plane ich zwei Stunden Puffer ein, vier Stunden Puffer ein. Und auch hier wieder, wie bei sehr, sehr vielen anderen Dingen auch, kann das von deiner IHK abhängen, ob das okay ist oder nicht. Ich habe schon davon gehört, dass einige IHK’en sogar fordern, dass man einen Puffer einplant.

[7:23] Also das ist wieder völlig unterschiedlich. Wenn das bei mir jemand einplanen würde, würde ich einen Antrag ablehnen. Die Zeit ist komplett zu verplanen. Ende. Weiß ich, dass das unrealistisch ist? Ja. Will ich, dass jemand dann sagt, ja, ich plane vier Stunden Puffer ein, habe also nicht meine ganze Zeit ausgereizt und irgendwie fülle ich die ja schon, weil ich gehe davon aus, dass meine Planung sowieso schrottig ist und die Puffer werden auf jeden Fall benutzt. Also was ist das wieder für eine Aussage für eine Abschlussprüfung? Also wenn ich zeigen soll, dass ich ein Projekt verplanen kann und von Anfang an sage, ich bin mir aber unsicher und plane Puffer ein.

[7:54] Also ich weiß, das ist in der Realität vielleicht so, aber dann müssen wir halt ein bisschen gucken, das ist eine Prüfungsleistung und da muss man halt vielleicht das Optimum rausholen. Ja, man kann das Pro und Kontra argumentieren. Ist der Puffer jetzt gut oder schlecht? Und das ist jetzt müßig, darüber nachzudenken. Im Zweifel fragst du, wie bei allen Themen deine IHK, ob da ein Puffer nötig ist oder ob du auch weniger Zeit einplanen kannst. Warum auch immer du das machen willst, ich habe es ja gerade erklärt. Aber wenn deine IHK konkrete Vorgaben dazu hat oder irgendwas erwartet, wäre es natürlich gut, das zu wissen. Und bei einigen, wie gesagt, ich habe es gehört, da muss halt Zeit X als Puffer eingeplant werden, weil man halt, also ich finde es ja auch irgendwo nachvollziehbar, man weiß, dass es sowieso unrealistisch ist, sie planen und dann plant man halt Puffer ein. Okay, trotzdem erwarten die dann aber am Ende, dass der Puffer auch ausgenutzt wird. Also am Ende muss man trotzdem die 80 Stunden wieder gefüllt haben sinnvoll. Also das ist alles, ach, das ist auch alles ein bisschen konstruiert hier. Naja, es ist ja nun mal einfach eine Prüfungsleistung.

[8:49] So, okay. Dann sollte also normalerweise, wenn du dir nicht sicher bist oder dein IHK weiß das selber nicht oder sagt es dir nicht oder steht nicht im Internet oder wie auch immer, sollte es spätestens beim Prüfen des Projektantrags auffallen, wenn ein Prüfer, eine Prüferin den Antrag ablehnt und sagt, hier ist ein Puffer einzuplanen oder nicht, beziehungsweise planen sie die ganzen 80 Stunden ein, so wie wir das machen, dann weiß es halt. Und wenn dein Antrag durch ist, dann weißt du, dass du es richtig gemacht hast. Problem ist, wenn der Antrag abgelehnt wird und du ihn überarbeiten musst, dann brauchst du halt eine gewisse Zeit für die Überarbeitung und die erneute Prüfung und das geht alles von deiner Projektzeit ab. Deswegen würde ich gucken, dass du dich vorher informierst und den Antrag gleich so einreichst, dass er einfach genehmigt wird. Weil sonst machst du dir ohne Ende noch mehr Zeitdruck, weil du darfst ja erst mit dem Projekt anfangen, wenn dein Antrag genehmigt ist. Und wenn du noch einen neuen einreichen musst, dann dauert das teilweise zwei, manchmal sogar vier Wochen, bis du wieder ein Feedback kriegst. Und das geht natürlich alles von deiner Projektzeit ab. Deswegen informiere dich einfach vorher.

[9:43] So, und was du auch nicht machen kannst, das gibt es, hast du vielleicht schon mal ein paar Beispieldokus gesehen, auf meiner Website habe ich auch ein paar Beispieldokumentationen, da gibt es ein, ab und zu gibt es da mal ein Kapitel Abweichungen vom Projektantrag, daran könnte man begründen, warum man Dinge anders gemacht hat im tatsächlichen Projekt, wie als man sie auch im Projektantrag geplant hat, aber da kannst du auch nicht sagen, ja, Abweichen vom Projektantrag habe ich für mein Projekt 100 Stunden gebraucht. Nein, das geht nicht. Wenn dein Projekt mit 80 Stunden genehmigt ist, dann hast du auch 80 Stunden einzuhalten. Und Gesetz erlaubt sowieso nicht mehr. Das heißt, da kann man sich nicht rausreden und sagen, ja, ich habe es ja in die Doku geschrieben, ich habe mehr gebraucht und deswegen haben die mir jetzt 100 Stunden erlaubt. Nein, ist nicht der Fall. Dann würdest du im Zweifel, wenn du einen bösen Prüfungsausschuss hast, einfach durchfallen, weil du hast die Vorgaben nicht eingehalten. Also, halte dich dran und versuch nicht da irgendwie drum herum zu reden. Denn wenn du wirklich realistisch dein Projekt planen solltest und das wirklich mit dieser naiven Einstellung an deine Projektarbeit rangehst, dann ist es tatsächlich auch so, meinst du, du kannst es wirklich auf eine Stunde genau planen? Meinst du, 81 Stunden oder 80 Stunden sind dann wirklich so ein Riesenunterschied?

[10:54] Es ist sowieso alles unrealistisch. Das heißt, geh einfach von den 80 bis 40 Stunden aus und guck, dass du einfach genau bei der Zahl landest und dann ist dieses Prüfungsding einfach durch. So, sollte es jetzt aber dazu kommen, dass du während des Projektablaufs in irgendeiner Phase, die du da geplant hast, mehr Zeit brauchst, als du geplant hast, das wäre ja gefährlich, weil dann würdest du über die 80 Stunden kommen, dann kommt der magische Feen-Zauberstab und der, sorgt dann dafür, dass in einer anderen Phase, die später kommt, einfach ein bisschen Zeit eingespart wird und dann landest du einfach bei 40 oder 80 Stunden. So machst du das. Das heißt, wenn du also tatsächlich realistisch irgendwo mehr Zeit brauchst, dann musst du einfach dafür sorgen, dass du das magischerweise in einer anderen Phase wieder einsparst. So Klassiker ist dann so ein Soll-Ist-Vergleich. In der Projektdokur so steht, ja, in der Planungsphase habe ich etwas mehr Zeit gebraucht, weil der Prozess doch viel komplizierter war als erwartet. Dafür konnte ich in der Implementierungsphase die Zeit wieder einsparen, weil ich mir ja so viele Gedanken im Vorfeld gemacht habe. Blablabla. Wir wissen alle, dass das Bullshit ist. Sorry, ich muss das mal ganz offen sagen.

[11:59] Das passt einfach nicht. Und ich weiß, dass die meisten Prüflinge deutlich länger an ihrer Projektarbeit sitzen als die erlaubten 40 oder 80 Stunden. Machen wir uns da mal nichts vor. Vor allem, weil man auch die Zeit für die Projektdokumentation mit in diesen Zeitraum rein planen muss bei den meisten IHK. Da habe ich auch schon eine Podcast-Episode dazu gemacht. Das ist so unrealistisch. Es ist halt ein bisschen ein Prüfungskonstrukt hier. Trotzdem musst du dann, weil du das jetzt ja dann weißt, dich halt exakt an diese Vorgaben halten und magischerweise geht das am Ende alles auf. Dein Projekt wird perfekt umgesetzt und du sparst hier was ein, was du an anderer Stelle gut wieder investieren kannst, sodass du unterm Strich wieder genau auf 40 oder 80 Stunden landest. Das ist die Vorgabe. Das hätten wir gern.

[12:41] Ist das ein bisschen realitätsfern? Ja. Habe ich schon mal irgendein Projekt gesehen, wo es eine Abweichung gab, wo mehr Stunden rauskamen oder weniger und der Prüfling hat bestanden und eine Topnote bekommen? Nein. Also ich wäre nicht an deiner Stelle der Erste oder die Erste, der oder die es probieren möchte. Deswegen lass es einfach. Plan die Zeit genauso ein wie vorgegeben und dann passt das. Das ist mein Fazit für heute. Also Frage beantwortet. Musst du die Stunden exakt einhalten? Meine Antwort ja.

[13:11] Und das war’s für heute. Bis zum nächsten Mal.

Um das Einplanen der Projektdokumentation als Teil der Bearbeitungszeit des IHK-Abschlussprojekts (40h bzw. 80h) geht es in der dreizehnten Episode der Shorts des IT-Berufe-Podcasts.

Bei der Frage, ob die Zeit für die Projektdokumentation in die 40 bzw. 80 Stunden der Projektarbeit gehört, gibt es keine einheitliche Regelung, sondern es hängt von deiner IHK ab. Viele IHKen und auch der DIHK verlangen, dass diese Zeit mit eingeplant wird, auch wenn das in der Praxis oft als unrealistisch gesehen wird. Ich würde dir deshalb empfehlen, die Vorgaben deiner konkreten IHK zu prüfen und im Zweifel die Doku-Zeit vorsichtshalber in die Planung aufzunehmen.

Inhalt

Ob die Zeit für die Projektdokumentation zur offiziellen Projektzeit zählt, ist je nach IHK unterschiedlich geregelt. Eine einheitliche bundesweite Regelung gibt es dazu nicht, obwohl sich viele Prüflinge genau diese Klarheit wünschen. Nach der Recherche im Podcast erwarten die meisten IHKen, dass die Dokumentation innerhalb der vorgegebenen 40 oder 80 Stunden entsteht. Gleichzeitig wird das als praxisfern bewertet, weil die Projektzeit ohnehin oft knapp ist und umfangreiche Dokumentationen zusätzlich kaum realistisch in wenigen Stunden erstellt werden können.

Worum es bei der Frage geht

Gemeint ist die Zeit für die finale Projektdokumentation für den Prüfungsausschuss, also das ausformulierte Dokument mit Inhalt, Struktur, Formatierung, Bildern und Anhängen. Die zentrale Frage ist, ob diese Zeit offiziell Teil der Projektbearbeitungszeit ist oder außerhalb davon läuft.

Warum es dazu unterschiedliche Auffassungen gibt

In den Berufsverordnungen steht, dass der/die Prüfling eine betriebliche Projektarbeit durchführen und mit praxisbezogenen Unterlagen dokumentieren muss. Außerdem wird dort genannt, dass die Prüfungszeit für Projektarbeit und Dokumentation höchstens 80 Stunden beträgt, bezogen auf die Fachinformatiker:innen Anwendungsentwicklung.

FIAusbV §12 (2)

Der Prüfling hat eine betriebliche Projektarbeit durchzuführen und mit praxisbezogenen Unterlagen zu dokumentieren.

Die Prüfungszeit beträgt für die betriebliche Projektarbeit und für die Dokumentation mit praxisbezogenen Unterlagen höchstens 80 Stunden.

Im ersten Teil hat der Prüfling nachzuweisen, dass er in der Lage ist, […] die Planung und Durchführung des Projektes anforderungsgerecht zu dokumentieren.

Diese Formulierungen lassen sich unterschiedlich auslegen:

• Eine Auslegung ist, dass damit auch die finale Projektdokumentation für den Prüfungsausschuss gemeint ist.
• Die andere Auslegung ist, dass hier die fachliche Dokumentation gemeint ist, die ohnehin zum Projekt gehört, z.B.:
  • Entwickler:innen-Dokumentation
  • Benutzerhandbücher
  • Installationsprotokolle
  • Checklisten
  • Netzpläne

Nach dieser zweiten Sichtweise gehört die fachliche Dokumentation zum echten Projekt, nicht aber das spezielle Prüfungsartefakt für den Ausschuss.

Einschätzung zur Praxis

Es ist eigentlich offensichtlich, dass die vorgegebenen Projektzeiten oft schon für die eigentliche Umsetzung knapp sind. Wenn dann zusätzlich noch die vollständige Projektdokumentation in dieser Zeit erstellt werden soll, finde ich das sehr unrealistisch. Besonders kritisch sehe ich, dass manche IHKen für die Dokumentation nur etwa 10 bis 15 Prozent der Gesamtzeit vorsehen. Das wären bei 80 Stunden nur 8 bis 12 Stunden, bei 40 Stunden sogar nur 4 bis 6 Stunden.

Rolle von IHK und DIHK

Der DIHK hat eine Empfehlung beziehungsweise Vorgabe herausgegeben, nach der die Zeit für die Projektdokumentation mit eingeplant werden soll. Deshalb ist die Tendenz eher so, dass viele IHKen diese Zeit inzwischen in die Projektzeit einrechnen.

Trotzdem gibt es unterschiedliche Regelungen je nach Region:

• Nicht in der Zeit enthalten: z.B. Regensburg, Bayreuth, Stuttgart
• In der Zeit enthalten: z.B. Oldenburg, Gera, Berlin, Bonn

• Beispiele
  • Umsetzungsempfehlung DIHK: drin mit 20%, https://www.ihk.de/blueprint/servlet/resource/blob/6945168/0424ce44eab4c49eab8b0c078fe7d796/dihk-umsetzungshilfe-it-berufe-data.pdf
  • Regensburg und Bayreuth: nicht drin, https://www.ihk.de/blueprint/servlet/resource/blob/6637094/a7a0c7a26a07c581efc8f6784bdf0c3c/it-berufe-hinweise-stand-15-07-25-data.pdf
  • Stuttgart: nicht drin, "Auch das reine Dokumentieren des Projektverlaufs gehört zur Zeitplanung (nicht die Erstellung und Ausgestaltung der finalen Datei für den Prüfungsausschuss).", https://www.ihk.de/stuttgart/fuer-azubis/pruefungen/formulareneu6359/it-berufe-infos-ap2-6705038
  • Oldenburg, drin 15-20%, https://www.ihk.de/oldenburg/geschaeftsfelder/ausbildungweiterbildung/ausbildung/tipps-zur-ausbildung/it-berufe-leitfaden-abschlusspruefung-6733866
  • Gera, drin 20%, https://www.ihk.de/blueprint/servlet/resource/blob/3872458/df0b97a582369d0c4ae8bd448b1785aa/it-ihk-information-veroeffentlichung-internet-20170907-data.pdf
  • Berlin und Bonn, drin 15%, https://www.ihk-bonn.de/fileadmin/dokumente/Downloads/Ausbildung/IT-Berufe/IT-Handreichung_IHK_Bonn_Rhein-Sieg_2.pdf

In Oldenburg lehnen wir Projektanträge ab, wenn die Dokumentationszeit nicht in der Planung enthalten ist. Der Grund dafür ist die formale Vergleichbarkeit: Wer die Doku-Zeit nicht einplant, hätte auf dem Papier mehr Zeit für die eigentliche Entwicklung als andere Prüflinge.

Was du für deine Planung mitnehmen kannst

• Prüfe zuerst die Vorgaben deiner eigenen IHK.
• Suche auf der Website nach Handreichungen, Merkblättern oder FAQ.
• Wenn du nichts findest, frage direkt nach, z.B. per E-Mail oder telefonisch.
• Wenn du keine klare Auskunft bekommst, ist es sinnvoll, die Zeit für die Projektdokumentation vorsichtshalber mit einzuplanen.

Praktische Empfehlung

Auch wenn die Regelung kritisch gesehen wird, ist die wichtigste Empfehlung, dich an die Vorgaben deiner IHK zu halten. So vermeidest du formale Probleme, z.B. eine Ablehnung deines Projektantrags. Wenn dein Antrag genehmigt wird, kannst du davon ausgehen, dass deine Zeitplanung formal passt.

Fazit

Die Frage, ob die Projektdokumentation zur Projektzeit zählt, lässt sich nicht allgemeingültig beantworten. Viele IHKen rechnen sie inzwischen mit ein, andere nicht. Weil die Regelung regional unterschiedlich ist und der DIHK eher die Einplanung unterstützt, ist der sicherste Weg: bei deiner IHK nachfragen und die dortige Vorgabe konsequent umsetzen.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• FIAusbV: Verordnung über die Berufsausbildung zum Fachinformatiker und zur Fachinformatikerin
• Umsetzungsempfehlungen für die Durchführung der Abschlussprüfung in den IT‐Berufen (DIHK)

Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode

[0:21] Heute geht es um eine Frage, die sich viele Prüflinge stellen, wenn sie vor ihrer Projektdokumentation stehen. Und zwar soll ich die Zeit zum Erstellen der Projektdokumentation mit in die Bearbeitungszeit der Projektarbeit einplanen? Also ich erstelle die Projektdokumentation für den Prüfungsausschuss, das 20, 30, 40, 50 Seiten Dokument. Das muss ich ja auch irgendwie zusammenschreiben, formatieren etc. Die Zeit, die ich dafür brauche, gehört das mit in die 80 Stunden bzw. 40 Stunden meiner Projektzeit oder ist das extern und ich kann da so viel Zeit investieren, wie ich will? Und ja, es ist leider wieder so, dass die Antwort ist, es kommt drauf an. Und zwar auf die IHK. Wir haben ja 79 verschiedene in Deutschland. Und wie bei vielen anderen Themen, wo man sich fragen könnte, warum wird das nicht einfach zentral geregelt, ist es auch hier wieder so, dass jede IHK macht, was sie will, beziehungsweise machen kann, was sie will.

[1:22] Kurz vorweg, die meisten IHK, die ich recherchiert habe, ich habe nicht alle 79 recherchiert, nein, aber die meisten, die ich gefunden habe, erwarten, dass die Doku jetzt in der Projektzeit geschrieben wird. Und kurz vorweg, bevor ich jetzt in die Details gehe, meine persönliche Meinung. Ich finde das total schwachsinnig. Ich finde es total bescheuert, dass wir in 40 oder 80 Stunden, was ja sowieso sehr, sehr wenig ist, um ein einigermaßen passendes Projekt umzusetzen und wo wir uns alle.

[1:52] Ganz sicher sind, dass die meisten Prüflinge diese Zeit eh nicht einhalten, weil ihr Projekt deutlich länger dauert als diese 40 oder 80 Stunden, dass man dann auch noch erwartet, dass sie eine umfangreiche Projektdokumentation und bei manchen IHK’en sind das wirklich 50 Seiten mit Inhaltsverzeichnis, mit Anhang, mit Bildern, mit allem Pipapo, dann noch irgendwie damit reinquetschen. Und das muss natürlich dann an einen einigermaßen realistischen Anteil haben. Die Projektdoku darf natürlich nicht 90 Prozent der Zeit in Anspruch nehmen. Das heißt, dann gibt es so Vorgaben wie zwischen 10 und 15 Prozent. Das sind dann vielleicht, sagen wir mal, zwölf Stunden, also anderthalb Arbeitstage. Und dann kann man sich mal überlegen, wie realistisch das ist, dass ich 50 Seiten in anderthalb Arbeitstagen zusammenkriege. Ohne Fehler und wunderbar alle Referenzen aufgelöst und Bilder benannt und in der richtigen Reihenfolge und alles. Also das ist einfach utopisch unmöglich und absolut schwachsinnig, das in diese Zeit mit einzuplanen. Das ist meine persönliche Meinung zu diesem Thema. Und jetzt kommen wir zu der Meinung der IACAN. Und leider sehen viele IACAN das ein bisschen anders und sagen, nö, ist absolut sinnvoll und total realistisch, dass Prüflinge solche Dokumente auch noch innerhalb ihrer 40 oder 80 Stunden schreiben. Und deswegen ist das einzuplanen.

[3:06] So, vorweg, bevor wir jetzt weiter in die Details gehen. Das eine ist, was du laut Vorgabe zu planen hast. Das andere ist die reale Welt. Und wir sind uns eh alle einig, dass die Projekte sowieso meistens nicht in der Zeit umsetzbar sind. Zumindest, wenn du einigermaßen eine vernünftige Note haben willst. Deswegen, ehrlich gesagt…

[3:26] Drauf und schreibt das einfach außerhalb der Projektzeit. Und das tut mir in der Seele weh, dass ich Leuten empfehlen muss, die Regeln hier zu brechen. Ich bin ja auch Prüfer und muss dann am Ende bewerten, ob das Projekt hätte realistisch umgesetzt werden können, um dann eine Note daneben zu schreiben. Aber wenn du wirklich alles, was für dein Projekt nötig ist, in den 40 oder 80 Stunden ausschließlich umsetzen willst, dann machst du ein echt schlechtes Projekt. Das kann ich dir so schon mal sagen. Also Plan E, mehr Zeit für dein Projekt ein, als erlaubt ist. Ein offenes Geheimnis, das ich jetzt hier einfach mal ausspreche. Und wenn du dann noch 50 Seiten in anderthalb Tagen schreiben willst, also zum Leid, absolut utopisch und lächerlich. Gut, kommen wir nochmal jetzt zurück zum eigentlichen Thema. Warum gibt es überhaupt Missverständnisse? Warum kann es sein, dass die eine IHK das erlaubt und die andere nicht, dass die Zeit außerhalb der Projektzeit läuft? Es gibt ja eine Berufsverordnung und für jeden der IT-Berufe gibt es eine, für den Fachinformatiker zum Beispiel eine, die alle vier Fachrichtungen umfasst. Für die anderen Berufe gibt es eigene Berufsverordnungen. Und da steht dann im Text so etwas drin, dass man eben so ein Projekt umsetzen muss und das auch dokumentieren muss. Und da steht dann wortwörtlich zum Beispiel in Paragraf 12 Absatz 2, der Prüfling hat eine betriebliche Projektarbeit durchzuführen und mit praxisbezogenen Unterlagen zu dokumentieren.

[4:50] Das ist ein Punkt. Dann die Prüfungszeit beträgt für die betriebliche Projektarbeit und für die Dokumentation mit praxisbezogenen Unterlagen höchstens 80 Stunden. Ich bin jetzt beim Anwendungsentwickler, wie du gerade merkst, die anderen Berufe haben nur 40 Stunden. Und dann gibt es noch den Satz, im ersten Teil hat der Prüfling nachzuweisen, dass er in der Lage ist, kleine Auslassung, die Planung und Durchführung des Projektes anforderungsgerecht zu dokumentieren. Du siehst, ich habe jetzt hier mal ein paar Sätze rausgegriffen, wo der Begriff Dokumentation oder Dokumentieren drinsteht. Und jetzt kann man sagen, wenn man das so liest, ja, praxisbezogene Unterlagen, Dokumentation in höchstens 80 Stunden, ja, hört sich ja so an, als würde das da in die 80 Stunden reingehören. Ja, das kann man jetzt so sehen, weil da einfach der Begriff Dokumentation steht. Aber in vernünftigen IT-Projekten gibt es natürlich auch als Teil des Projekts eine Dokumentation. Zum Beispiel bei Anwendungsentwicklerinnen, für die Entwicklerkolleginnen, die sich mal in das Projekt einarbeiten sollen. Zum Beispiel ein Klassendiagramm. Oder bei Admins, die da irgendwie einen Server aufsetzen. Vielleicht ein Installationsprotokoll oder eine Checkliste, was man machen muss, um den Server zu klonen. Oder was auch immer. Oder ein Netzplan oder Sonstiges. Und wenn wir irgendwie eine Software bauen, zum Beispiel für Endanwenderinnen, da muss es vielleicht noch ein Benutzerhandbuch geben. Das ist auch eine Dokumentation.

[6:10] Und jetzt steht hier auch betriebliche Projektarbeit und die Dokumentation mit praxisbezogenen Unterlagen. Und deswegen interpretiere ich, und da bin ich übrigens nicht alleine, auch viele andere Prüfende interpretieren da rein, dass es hier um die Dokumentationsteile geht, die ganz normal als Teil des Projekts umgesetzt werden. Also Benutzer, Anwender, Admin, was auch immer Dokumentation. Und nicht das Prüfungsartefakt, was für den Prüfungsausschuss da ist. Ich meine, die Abschlussprüfung hat doch den Zweck, eine praxisbezogene Projektarbeit umzusetzen. Man soll zeigen, dass man nicht nur was aus dem Buch lernen kann, sondern dass man es auch umsetzen kann. Dass man ein Projekt von A bis Z umsetzt, inklusive Anforderungsaufnahme, lalalala, und inklusive Dokumentation, die wir natürlich in echten Projekten alle ständig machen, beziehungsweise durch KI machen lassen jetzt in Zukunft, wie auch immer. Auf jeden Fall gehört das einfach mit zum Projekt dazu und das soll man ja auch zeigen. Das soll ja auch ein echtes Projekt sein. Also wieso sollte man jetzt die Zeit, die man braucht, weil das hier eine Prüfungsleistung ist und dieses besondere Prüfungsartefakt hier zu erstellen ist, warum sollte man die Zeit mit in die 80 Stunden einplanen oder 40?

[7:16] Mir erschließt sich das nicht. Vor allem, wir haben ja in der Neuordnung 2020 die Zeit fürs Projekt erhöht. Von 70 auf 80 Stunden, beziehungsweise von 35 auf 40. Und jetzt kommt irgendeine IHK und sagt, ja, Moment, von den 10 zusätzlichen Stunden, liebe Anbietungsentwicklerinnen, müsst ihr aber 15 gleich wieder runternehmen, weil ihr müsst jetzt auch noch die Doku mit in die Zeit reinquetschen. So, das ist einfach kompletter, ich bin ganz ehrlich Bullshit. Das heißt, ich habe nach der Neuordnung weniger Zeit für mein Projekt als vorher, weil ich jetzt auch noch diese komische Prüfungsgeschichte damit unterbringen muss. Also ich kann mich da herrlich drüber aufregen, weil ich finde das so bescheuert, dass das ganze Ding Abschlussbreit steht sowieso ständig zur Diskussion, weil es unrealistisch ist und die Zeiten passen nicht und was. Und dann muss man da noch jetzt 15 Stunden abziehen, weil man eine Doku braucht. Also ich finde das ganz beknackt. Auf jeden Fall, es ist jetzt so, dass andere Leute halt der Meinung sind, dass in diesem Gesetzestext steht, ja, das ist offensichtlich Dokumentation, Projektdokumentation, also gehört das da rein, blablabla.

[8:12] Und übrigens, ich bin nicht alleine mit der einen Meinung, es gibt aber auch viele, die der anderen Meinung sind, dass die Projektdokumentationszeit halt mit da reingehört. Unter anderem auch der DIHK, also der Deutsche Industrie- und Handelskammer Tag, der hat tatsächlich eine offizielle Empfehlung herausgegeben, beziehungsweise Ansage, ich weiß es gar nicht, oder Vorgabe einfach, dass die Zeit da nun mit einzuplanen ist. Also von daher kann ich jetzt hier schlau schnacken. Trotzdem würde ich dir den direkten Tipp geben, frag bei deiner eigenen IHK nach, was da die Vorgaben sind. Denn ich weiß, Stand heute, ich nehme das gerade Mitte 2026 auf, kenne ich mindestens für beide Seiten zwei verschiedene IHK, die es so machen oder eben auch anders machen. Das heißt, wie bei vielen formalen Fragen zu deiner Projektarbeit gilt, frag deine IHK, was da Vorgabe ist. Wenn du keine Vorgabe findest, zum Beispiel im Internet, auf der Website irgendwelche Handreichungen, Merkblätter, was auch immer zur Abschlussdoku, dann frag nach, dann ruf an, dann schick eine E-Mail. Und wenn du dann immer noch keine Aussage kriegst, dann würde ich dir tatsächlich empfehlen, plan die Zeit mit ein, weil meiner persönlichen Rechercherfahrung nach jetzt ist es so, dass die meisten IHK inzwischen die Zeit inklusive Projektdokumentation haben wollen und weil der DIHK das ja auch vorgegeben hat, wird das wahrscheinlich auch tendenziell die Richtung sein, wo die meisten IHK sich hin entwickeln werden, wenn sie da jetzt noch nicht sind.

[9:37] Okay, wenn man dann guckt, was soll man denn für eine Zeit einplanen? Die meisten IHKN geben irgendwas zwischen 10 und 15 Prozent der Zeit an. Das heißt, da wären wir irgendwo bei 8 bis 12 Stunden. Alles, was da drüber liegt, ist dann wieder, also ich beziehe das immer auf die Anwendungsentwickler, da kannst du jetzt runterrechnen auf Fisis, dann bist du bei 4 bis 6 Stunden. Ja, herzlichen Glückwunsch, schreib mal 50 Seiten in 6 Stunden. Also das ist, ja, okay, lassen wir das Thema.

[10:03] So, trotzdem musst du natürlich in deiner Projektarbeit die gute alte Dokumentation, die ich meine, erstellen für Benutzende und Entwicklerinnen und ich weiß nicht was. Das gehört natürlich trotzdem auch noch dazu.

[10:14] Und ich meine, auch da braucht man ja ein paar Stündchen für, wenn man ein vernünftiges Benutzernbuch schreiben will. Also da siehst du, dass das alles völlig irrelevant ist. Naja, irrelevant, weil unrealistisch. Ja, ansonsten solltest du, wenn du es falsch machst, in Anführungszeichen, eigentlich sofort beim Prüfen des Projektantrags ein Feedback bekommen. Bei uns in Oldenburg wurde diese Regelung umgestellt. Vor der Neuordnung war die Projektarbeit außerhalb der Zeit und man konnte quasi Stunden und Wochen investieren, um seine Projektarbeit zu optimieren, sage ich mal. Inzwischen ist es explizit genauso, dass die IHK will, dass es in den 80 Stunden oder 40 Stunden mit drin ist. Und deswegen würden wir tatsächlich auch Projektanträge, wo das nicht der Fall ist, ablehnen. Also wenn jemand kommt und sagt, ich verplane hier meine 80 Stunden für die Softwareentwicklung komplett und die Doku ist nicht mit drin, dann lehnen wir den Projektantrag ab, weil das nicht den formalen Anforderungen entspricht. Das kannst du dir auch vorstellen, kommt ein Asubi, der quasi 10 bis 8 bis 12 Stunden mehr Zeit hat, Software zu entwickeln, weil dieses Prüfungsartefakt nicht eingepreist ist und jemand, der das dann macht und sich an die Regeln hält, hat weniger Zeit und kann demnach ja auch eigentlich nur ein kleineres Projekt umsetzen, was also vielleicht zu einer schlechten Note führt und das wäre natürlich unfair. Deswegen ist es bei uns so, wird abgelehnt, wenn es nicht zur Anforderung passt. Andere eher kann, vielleicht gucken die da gar nicht drauf oder winken das einfach durch oder wie auch immer, es dreht auch jeder sein eigenes Ding.

[11:36] Gut, ich habe einfach mal ein paar Beispiele mitgebracht, was jetzt Stand Mitte 2026 so ist. Die Umsetzungsempfehlung des DIHK und da steht drin, 20% der Zeit sollen eingeplant werden, sogar noch mehr. Ich verlinke das auch gerne mal in den Shownotes, dann kannst du das einfach angucken.

[11:53] Ich habe dann zum Beispiel zwei IHK gefunden, Regensburg und Bayreuth. Die sagen explizit, die Zeit ist nicht mit drin. Dann gibt es in Stuttgart, gut, Baden-Württemberg, die machen eh, was sie wollen. Das kennen wir ja schon von den Prüfungen. Aber da steht zum Beispiel auch, dass es nicht mit drin ist. Da steht dann zum Beispiel auch, das reine Dokumentieren des Projektverlaufs gehört zur Zeitplanung, aber nicht die Erstellung und Ausgestaltung der finalen Datei für den Prüfungsausschuss. Da ist also explizit nochmal das Prüfungsartefakt wieder ausgenommen. Ich habe natürlich meine eigene IHK Oldenburg, da ist es mit drin. Da haben wir 15 bis 20 Prozent angesetzt. Oh, ich hatte 10 bis 15 im Kopf. Na gut, ist egal, sogar noch mehr. Also 20 Prozent von 80 Stunden, das wären 16 Stunden. Das wären zwei komplette Arbeitstage, die mir fehlen. Ja, gut, egal. Und dann haben wir zum Beispiel noch Gera, sind es auch 20 Prozent. Berlin und Bonn sind 15 Prozent der Zeit vorzusehen. Also ich habe jetzt hier schon, ich habe für jede Seite sogar drei, vier Beispiele. Da siehst du, es geht mal so, mal so, je nachdem, bei welcher IHK du bist. Deswegen, ich empfehle dir dringend, frag bei deiner konkreten IHK nach, was muss ich machen. Und sonst, ja, siehst du spätestens beim Antrag, wenn der genehmigt ist, dann weißt du, hast du alles richtig gemacht.

[13:05] Also, wenn du nicht weißt, was Sache ist, ich würde dir empfehlen, nehme es mit rein in die Zeit. Die meisten IHKern werden es so machen, weil der DIHK es halt auch empfiehlt oder vorgibt. Und du kannst dich darüber ärgern und ärgern, so wie ich. Oder du sagst einfach, ja komm, trage ich da halt eine Zeit ein. Guckt sowieso keiner drauf. Die ganzen Zeiten sind sowieso unrealistisch. Und dann setzt du es einfach um. Ja, das war jetzt heute mein Rant zu diesem Thema, weil ich finde diese Entscheidung einfach so beknackt. Ich kann es gar nicht in Worte fassen. Aber gut, am Ende ist es auch nur eine Zahl. dir steht und weil wir eh alle wissen, dass das ausgedachte Zahlen manchmal auch sind, ist es vielleicht auch am Ende gar nicht so schlimm. Also halt dich einfach an die Vorgaben. Dann kannst du wenigstens nicht wegen solcher Formalia, weil du irgendwo eine Stunde zu wenig geplant hast, irgendwo, also durchfallen wirst du deswegen sowieso nicht. Aber zum Beispiel könnte der Progdantrag ja abgelehnt werden, dann musst du neu machen und dann hast du weniger Zeit für die Umsetzung wegen der Frist und tralla. Also ja, ich empfehle dir, frag nach, halt dich daran und dann war es das zu diesem Thema. Und ja, jetzt weißt du auch, wie ich das sehe und dass es wie viele andere Themen auch leider nicht deutschlandweit einheitlich geregelt ist, sondern viele IHK, einfach ihre eigenen Sachen durchziehen.

[14:15] Jo, das war’s für heute. Ich sag bis zum nächsten Mal. Ciao.

Um die mündliche Ergänzungsprüfung (MEP) inkl. Erklärung, Benotung, Inhalte und Vorbereitung geht es in der einhundertsiebenundneunzigsten Episode des IT-Berufe-Podcasts.

Die mündliche Ergänzungsprüfung (MEP) ist die letzte Möglichkeit, wenn du in einer schriftlichen Prüfung aus Teil 2 der Abschlussprüfung durchgefallen bist und dadurch das Bestehen noch retten kannst. Sie ist nur für einen einzigen schriftlichen Prüfungsbereich in AP2 möglich, dauert etwa 15 Minuten und wird im Verhältnis 2:1 mit dem bisherigen Ergebnis verrechnet, weshalb sie eine schlechte Note nur begrenzt ausgleichen kann. Wichtig ist vor allem: Kläre Ablauf, Antrag und Termin direkt mit deiner IHK und bereite dich inhaltlich wie auf die betroffene schriftliche Prüfung vor, aber mit Fokus auf mündliches Erklären.

Inhalt Mündliche Ergänzungsprüfung in den IT-Berufen

Ich fasse hier die Regeln zur mündlichen Ergänzungsprüfung (MEP) nach der seit 2020 geltenden Berufsverordnung zusammen. Die MEP betrifft nur Prüflinge, die in einem schriftlichen Prüfungsbereich von Teil 2 der Abschlussprüfung durchgefallen sind und die Prüfung dadurch eventuell noch bestehen können.

Wofür die MEP gedacht ist

Die MEP ist dafür da, eine nicht bestandene schriftliche Prüfung in Teil 2 auszugleichen. Sie ist nicht dafür da, einfach eine Note zu verbessern.

Wichtig dabei:

• AP1 kann nicht durch eine MEP ausgeglichen werden.
• Auch das Projekt in AP2 kann nicht durch eine MEP ausgeglichen werden.
• Die MEP ist nur für die drei schriftlichen Prüfungsbereiche von AP2 möglich:
  • die zwei berufsspezifischen schriftlichen Prüfungen
  • Wirtschafts- und Sozialkunde (WISO)

Wann die Abschlussprüfung bestanden ist

Die Abschlussprüfung ist bestanden, wenn folgende Bedingungen erfüllt sind (siehe Gewichtung der Prüfungsbereiche und Anforderungen für das Bestehen der Abschlussprüfung):

1. Gesamtergebnis von Teil 1 und Teil 2 mindestens ausreichend
2. Ergebnis von Teil 2 mindestens ausreichend
3. In mindestens drei Prüfungsbereichen von Teil 2 mindestens ausreichend
4. In keinem Prüfungsbereich von Teil 2 ungenügend

Für AP2 heißt das praktisch:

• Du hast vier Prüfungsbereiche in AP2:
  • Projekt
  • schriftlicher Bereich 1
  • schriftlicher Bereich 2
  • WISO
• In mindestens drei von diesen vier Bereichen musst du mindestens eine 4 haben.
• Wenn das Projekt bestanden ist, darfst du in den drei schriftlichen Prüfungen höchstens einmal durchfallen.

Das bedeutet:

• Eine 5 in einer schriftlichen Prüfung kann noch okay sein.
• Zwei 5en in den schriftlichen Prüfungen reichen nicht mehr.
• Eine 6 in einem Prüfungsbereich von Teil 2 ist ebenfalls nicht erlaubt.

Wann du in eine MEP musst

Eine MEP wird relevant, wenn du durch eine schriftliche Prüfung in AP2 das Bestehen verfehlst (siehe Mündliche Ergänzungsprüfung).

Typische Fälle:

• zwei 5en in den schriftlichen Prüfungen → eine davon muss ausgeglichen werden
• eine 6 → diese muss mindestens so verbessert werden, dass sie nicht als 6 stehen bleibt

Dabei gilt aber immer:

• Du musst mit der MEP überhaupt noch rechnerisch bestehen können.
• Wenn das nicht mehr möglich ist, gibt es keine MEP.

Wer die MEP beantragen muss

Rein rechtlich gilt:

• Der Prüfling beantragt die MEP selbst.

In der Praxis kann es sein, dass die IHK das automatisch anstößt. Verlassen solltest du dich darauf aber nicht. Wenn deine Noten knapp oder kritisch sind, solltest du direkt bei deiner IHK nachfragen, wie das bei dir geregelt ist.

In welchen Prüfungsbereichen die MEP möglich ist

Die MEP ist nur in einem einzigen schriftlichen Prüfungsbereich möglich.

Voraussetzungen:

• der Bereich muss zu den schriftlichen Prüfungen von AP2 gehören
• du musst dort schlechter als ausreichend sein, also unter 50 Punkten
• die MEP muss für das Bestehen der Abschlussprüfung überhaupt noch etwas ändern können

Nicht möglich ist:

• MEP im Projekt
• MEP in mehreren Prüfungsbereichen
• MEP zur reinen Notenverbesserung

Wie die MEP bewertet wird

Die MEP dauert in der Regel 15 Minuten.

Das Ergebnis wird zusammen mit der bisherigen schriftlichen Note im Verhältnis 2:1 verrechnet:

• schriftliches Ergebnis zählt zweifach
• Ergebnis der MEP zählt einfach

Das neue Ergebnis im Prüfungsbereich wird also so berechnet:

• (schriftlich × 2 + MEP) / 3

Was diese Gewichtung praktisch bedeutet

Die MEP hat nur begrenzte Hebelwirkung.

Beispiele:

• Bei 40 Punkten in der schriftlichen Prüfung brauchst du 70 Punkte in der MEP, um auf 50 Punkte insgesamt zu kommen.
• Bei 30 Punkten brauchst du 90 Punkte in der MEP, um noch auf 50 Punkte zu kommen.
• Bei 25 Punkten brauchst du sogar 100 Punkte in der MEP, um auf 50 Punkte zu kommen.
• Ab 24 Punkten oder weniger kannst du rechnerisch in diesem Prüfungsbereich nicht mehr auf 50 Punkte kommen.

Deshalb ist das Ziel bei einer sehr schlechten 6 oft nicht mehr, diesen Bereich noch auf eine 4 zu bringen, sondern die 6 wenigstens auf eine 5 zu heben, damit die Prüfung insgesamt vielleicht noch bestanden werden kann.

Wie der Ablauf organisiert ist

Dazu gibt es keine einheitliche Vorgabe in der Berufsverordnung. Deshalb ist der Ablauf von IHK zu IHK unterschiedlich.

Möglich ist zum Beispiel:

• MEP direkt am Tag der mündlichen Prüfung
• separater zusätzlicher Termin
• rein mündliches Fachgespräch
• kurze Vorbereitung auf Aufgaben
• Aufgaben an Tafel oder Papier mit anschließendem Gespräch

Entscheidend ist:

• Es muss eine mündliche Prüfung sein.
• Sie soll etwa 15 Minuten dauern.
• Alles Weitere kann je nach IHK und sogar je nach Prüfungsausschuss unterschiedlich sein.

Deshalb ist der wichtigste praktische Hinweis:

• Frag direkt bei deiner IHK nach.
• Verlass dich nicht auf Berichte aus dem Internet oder auf Erfahrungen von anderen Prüflingen.

Welche Inhalte in der MEP drankommen können

Die Fragen müssen zu dem Prüfungsbereich passen, in dem du durchgefallen bist.

Beispiele:

• bei WISO etwa Themen wie Arbeitsrecht, Tarifverhandlungen oder Jugendarbeitsschutz
• bei einer fachlichen Prüfung etwa SQL, Pseudocode, UML oder andere Inhalte des jeweiligen Prüfungsbereichs

Früher konnte der Themenbereich enger eingegrenzt werden. Das ist heute nicht mehr so. Maßgeblich ist jetzt der gesamte Prüfungsbereich, in dem du durchgefallen bist.

Das bedeutet:

• Du musst dich breit auf alle Themen dieses Bereichs vorbereiten.
• Du kannst nicht davon ausgehen, dass nur ein einzelnes Lieblingsthema gefragt wird.

Wie du dich vorbereiten kannst

Die inhaltliche Vorbereitung ist im Grunde dieselbe wie für die schriftliche Prüfung, in der du durchgefallen bist.

Sinnvoll ist dabei:

• alte Prüfungen durcharbeiten
• typische Themen des Prüfungsbereichs sammeln
• Antworten mündlich formulieren und erklären üben
• mit einer anderen Person üben, zum Beispiel mit dein:e Ausbilder:in, Lehrkraft oder einer erfahrenen Person

Wichtig ist der Unterschied zur schriftlichen Prüfung:

• In der MEP musst du die Inhalte mündlich verständlich erklären können.
• Du solltest also nicht nur Aufgaben lösen, sondern auch üben, wie du Begriffe, Abläufe und Zusammenhänge in Worten erklärst.

Einschätzung zur MEP

Die MEP ist keine einfache Notenrettung, weil die 2:1-Gewichtung rechnerisch viel verlangt. Trotzdem kann sie eine echte Chance sein, wenn das Bestehen noch möglich ist.

Dabei gilt:

• Die Prüfenden wollen in der Regel nicht, dass du scheiterst.
• In einer mündlichen Prüfung gibt es oft mehr Möglichkeiten, durch Nachfragen und Umschreibungen noch zu zeigen, was du kannst.
• Trotzdem bleibt die MEP deine letzte Chance, deshalb solltest du dich gezielt vorbereiten.

Wichtigstes Fazit

• Die MEP betrifft nur schriftliche Prüfungsbereiche von AP2.
• Sie ist nur möglich, wenn du in einem Bereich unter 50 Punkten liegst und damit das Bestehen noch retten kannst.
• Sie dauert etwa 15 Minuten.
• Die Bewertung erfolgt im Verhältnis 2:1 zugunsten der bisherigen schriftlichen Note.
• Der genaue Ablauf ist nicht einheitlich geregelt und hängt von deiner IHK ab.
• Wenn deine Noten kritisch sind, solltest du sofort selbst bei deiner IHK nachfragen, wie es weitergeht und ob du etwas beantragen musst.
• Für die Vorbereitung solltest du die Themen der betroffenen schriftlichen Prüfung wiederholen und vor allem das mündliche Erklären trainieren.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Themen der schriftlichen IHK-Prüfungen der IT-Berufe
• Gewichtung der Prüfungsbereiche und Anforderungen für das Bestehen der Abschlussprüfung
• Mündliche Ergänzungsprüfung
• Prüfungsrechner aller Berufe von A-Z

Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode

[0:21] Hallo und herzlich willkommen zur 197. Episode des IT-Brufe-Podcasts. Mein Name ist Stefan Macke und heute geht es um ein Thema, das ich vor langer, langer, langer Zeit schon mal im Podcast besprochen habe. Allerdings noch auf Basis der alten Berufsverordnung. Und die wurde ja 2020 komplett über den Haufen geworfen. Deswegen ist es dringend Zeit, das mal zu aktualisieren. Und zwar geht es heute um die mündliche Ergänzungsprüfung, die MEP. Was ist das? Warum braucht man das? Wann muss ich da rein? Wie wird die bewertet? Wie breite ich mich vor? Das soll heute das Thema sein. Die mündliche Ergänzungsprüfung betrifft vor allem die Prüflinge oder nicht nur vor allem, also nur die Prüflinge, die durch einen Teil, nee, nein, sorry, durch einen Bereich von Teil 2 der Prüfung durchgefallen sind. So, wir müssen aber genau auf die Begriffe hier achten.

[1:10] Die Abschlussprüfung besteht ja aus zwei Teilen, der AP1 und der AP2. Und diese Teile haben jeweils Prüfungsbereiche. Die AP1 hat nur einen Bereich, nämlich die schriftliche Prüfung, aber die AP2 hat mehrere Bereiche. Und zwar einmal das Projekt, das Abschlussprojekt, was man machen muss, was natürlich auch den größten Anteil an der Note hat. Und dann gibt es aber noch drei weitere Prüfungsteile in AP2. Und zwar die zwei berufsspezifischen Prüfungen. Für Armungsentwickler ist das zum Beispiel Entwickeln und Analysieren und Entwickeln von Algorithmen, heißt das, glaube ich. Und das andere Plan eines Softwareprodukts. Und für die anderen IT-Berufe heißen die halt irgendwie anders. Die weiß ich jetzt leider nicht alle auswendig. Und da gibt es auch den dritten Teil und das ist Wieso. Wirtschaft und Soziales, der ist ja für alle Berufe, nicht nur für IT-Berufe, sondern sogar für alle Berufe identisch. Und diese drei Prüfungsbereiche plus das Projekt, das sind die vier Prüfungsbereiche in AP2.

[2:03] Und wenn man durch diese schriftlichen Prüfungen, beziehungsweise eine davon oder auch zwei oder noch mehr, durchfällt, dann muss man eventuell in eine mündliche Ergänzungsprüfung, um diese schlechte Note auszugleichen. Darum geht es im Prinzip. Und was da jetzt genau die Voraussetzungen sind und wie so eine Prüfung abläuft, wenn man sich vorbereitet, das soll heute einmal das Thema sein. Es geht also darum, wenn ich eine schlechte Note habe, wenn ich irgendwo durchgefallen bin in einem der Prüfungsbereiche von AP Teil 2, wie läuft das denn ab und was mache ich da? Kurz schon mal vorweg, die AP 1, da kann man nicht durchfallen. Die AP 1, wenn du da eine schlechte Note hast, ja, dann hast du leider Pech gehabt, die kannst du nicht wiederholen. Das heißt, egal ob du eine 6 sogar hast, vielleicht auch in AP 1, du kannst trotzdem deine Prüfung insgesamt bestehen und du hast auch keine Chance, die Note wieder auszugleichen. Wenn du eine 6 hast, dann steht die da. Und auch wenn du am Ende bestanden hast, steht die 6 trotzdem auf dem Säugnis. Deswegen kann ich hier nochmal dafür ganz wichtig plädieren. Bereite dich gut auf die AP1 vor. Diese Note kriegst du nie wieder ausgeglichen, wenn die schlecht ist. Außer du wiederholst die komplette Prüfung nochmal, also deine ganze Ausbildung. Und das willst du sicherlich nicht.

[3:12] Also AP1, da sind wir komplett raus. Egal wie schlecht die Note, da kannst und musst und darfst du nichts wiederholen. Wir reden hier nur über die schriftliche Prüfung von Teil 2. Das Projekt, wenn du da durchfällst, hast du auch ein Problem. Da muss man nochmal in einer gesonderten Episode vielleicht drüber reden. Da gibt es auch keine Ergänzungsprüfung, sondern es geht hier nur um die drei Prüfungsbereiche, die schriftlichen Prüfungen von Teil 2, also die beiden berufsspezifischen und Wieso.

[3:38] So, dann würde ich sagen, werfen wir doch mal einen Blick in unsere Berufsverordnung und schauen einfach mal, wann man überhaupt die Prüfung besteht und was dafür nötig ist und kommen dann irgendwie darüber zur mündlichen Ergänzungsprüfung. Da schauen wir einfach mal in die FI aus PF, also die Verordnung über die Berufsausbildung zum Fachinformatiker und zur Fachinformatikerin, die FI aus PF. Die gleichen Sachen, die ich jetzt erzähle, gelten für alle IT-Berufe. Also wenn ich jetzt für die Fachinformatiker das sage, gibt es natürlich genauso eine Berufsverordnung für die anderen IT-Berufe, die Kaufmännischen und den Systemelektroniker und so weiter, sind exakt identisch aufgebaut, wörtlich eins zu eins identisch, bis auf eine Kleinigkeit. Und das ist auch der Grund, warum es tatsächlich für alle vier Fachinformatiker.

[4:23] Jeweils einzelne Paragrafen für das Bestehen der Prüfung und die Münchner Gänzungsprüfung gibt. Denn der einzige Unterschied ist, dass diese Prüfungsdienstechnik Bereiche ja etwas anders heißen. Ich habe es ja gerade schon gesagt, für Amix und Mikla, Bereich 1 und 2 der schriftlichen Prüfung ist halt Algorithmik und Plan eines Softwareprodukts und für die anderen IT-Berufe heißen die halt anders. Und deswegen muss man diese Paragrafen, die ich jetzt vorlese, siebenmal doppelt und dreifach definieren, weil ja diese kleine Geschichte sich ändert, also einfach der Name der Prüfung.

[4:52] Und des Prüfungsbereichs. Und für IT-Systemelektroniker kommt noch dazu, dass es ein Sperrfach gibt, aber das ist eine andere Geschichte, das gibt es für die anderen Archieberufe nicht. Worum es jetzt heute hier geht ist, wann bestehe ich die Prüfung und wann muss ich in der MEP. Und die Idee ist für alle IT-Berufe identisch, auch wenn sie in unterschiedlichen Paragrafen definiert sind. Ich fange einfach mal an mit dem Anwendungsentwickler, weil der steht einfach ganz vorne, das sind die ersten Paragrafen. Das heißt, wenn du in die VIE aus Pf in Paragraf 16 schaust, dann gibt es da die Gewichtung der Prüfungsbereiche und Anforderungen für das Bestehen der Abschlussprüfung. Und für die anderen drei Fachrichtungen gibt es die auch, bloß halt ein paar Paragrafen später und du wirst sehen, die sehen eins zu eins identisch aus. Und wenn du einen ganz anderen IT-Beruf machst, dann guckst du halt in deine Ausbildungsverordnung und wirst das sicherlich auch finden, ob es jetzt Paragraf 16 ist oder 17 oder 23. Das wirst du wohl herausfinden, ja. Also es gibt einen Paragrafen, der sagt, wie sind die Prüfungsbereiche zu gewichten und wann besteht man die. Und für die Anwendungsentwicklung ist das halt in Paragraf 16 definiert. Und hier wird auch nochmal einmal darauf hingewiesen, dass es diese zwei Prüfungsteile gibt mit jeweils unterschiedlichen Bereichen. Und jetzt gucken wir uns den Absatz 2 an. Und da steht drin, die Abschlussprüfung ist bestanden, wenn die Prüfungsleistungen, Achtung, auch unter Berücksichtigung einer mündlichen Ergänzungsprüfung nach § 17, da werden wir dann ja gleich darauf eingehen, wie folgt bewertet worden sind. Also alles, was jetzt kommt, musst du immer so verstehen, dass du eventuell auch noch eine MEP einschiebst, um eine deiner Noten zum Beispiel höher zu ziehen, auszugleichen, wie auch immer. Aber grundsätzlich bestehst du die Prüfung, wenn.

[6:20] Du im Gesamtergebnis von Teil 1 und 2 mindestens ausreichend hast. Das heißt, du nimmst das Gesamtergebnis von Teil 1 und von Teil 2, rechnest das zusammen und guckst, dass du da über 50% kommst. Bist du mal so größer gleich 50, ne? Ab 50% hast du bestanden. Gesamtergebnis von beiden 50%. Dann Punkt Nummer 2, im Ergebnis von Teil 2 mit mindestens ausreichend. Das heißt, hier wird nochmal explizit gesagt, in Teil 2 musst du eine 4 haben, 50%. Teil 1 irrelevant. Du kannst in Teil 1 eine 6, eine 5 haben, völlig egal, solange du im Gesamtergebnis über 50% kommst, alles gut. Aber in Teil 2 musst du insgesamt alleine auf ausreichend kommen, auf 50%. Da kannst du nicht einzeln durchfallen und dann trotzdem die Prüfung bestehen, das geht nicht.

[7:06] Also Gesamtergebnis Teil 1 und 2 zusammen 4, Teil 2 alleine auch mindestens 4. Und jetzt kommt der wichtige Punkt für die MEP, in mindestens drei Prüfungsbereichen von Teil 2 mit mindestens ausreichend. Das heißt, wir gucken nochmal, welche Prüfungsbereiche gibt es. Wir haben deine beiden fachspezifischen schriftlichen Prüfungen, die Wieso-Prüfung als dritte schriftliche Prüfung und wir haben das Projekt. Das Projekt ist auch Bereich von Teil 2. Das heißt, du musst in all diesen vier Prüfungsbereichen in mindestens dreien davon eine 4 haben, also 50%. Und diese Ergänzungsprüfung kann man aber jetzt ja nur für die schriftlichen Prüfungen machen und nicht fürs Projekt. Deswegen gucken wir uns im weiteren Fall jetzt einfach mal nur diese drei Bereiche an. Und weil ja drei von vier bestanden sein müssen und wenn wir das Projekt jetzt ausklammern, musst du in mindestens zwei der drei schriftlichen Prüfungen durch sein. Ausreichend haben, 50%. Geh mal davon aus, dass du das Projekt auf jeden Fall bestehen musst und wenn du dann noch drei schriftliche Prüfungen hast, musst du in zwei davon mindestens eine vier haben. Anders formuliert heißt das, du kannst in einer schriftlichen Prüfung durchfallen, aber das war’s. Also zwei Fünfen, du bist raus.

[8:20] Und jetzt kommt Punkt Nummer 4 hier noch. In keinem Prüfungsbereich von Teil 2 darfst du ungenügend haben. Das wäre die 6. Also wir drehen das jetzt mal um und machen das ganz konkret. Wenn du in den drei schriftlichen Abschlussprüfungen von Teil 2 eine 6 hast oder zwei 5, dann bist du raus. Dann bestehst du deine Prüfung nicht und musst wiederholen.

[8:42] Andersherum heißt das, wenn du eine 5 hast, kannst du noch bestehen. Das ist völlig in Ordnung, solange die anderen Sachen eingehalten sind. Also wenn du eine 5 hast, mit den gesamten anderen Noten aus Teil 2, aber insgesamt auf 50% kommst, auf eine 4, ist das völlig okay. Und das ist ja relativ einfach, sagen wir einfach mal. Wenn wir mal gucken, die zählen ungefähr, ne, die zählen ungefähr alle gleich, die drei schriftlichen Prüfungen zählen alle 10% der Note. Das heißt, machen wir es mal ganz konkret. Du hast in Wieso 60 Prozent und in deiner ersten schriftlichen Prüfung, die berufsspezifisch ist, 50 Prozent. Und in deiner zweiten hast du leider nur 40 Prozent. Dann hast du trotzdem bestanden, weil 40 plus 60 plus 50 sind 150. Geteilt durch drei sind 50 Prozent. Das heißt, du hast insgesamt in Teil zwei eine Vier, ein Ausreichend, hast damit bestanden. Auch wenn du eine Fünf hast, diese 40 Prozent, die kannst du quasi ausgleichen durch die 60 Prozent in der anderen Prüfung. aufaddiert, geteilt durch 3. Wenn du dann auf 50% kommst, dann hast du bestanden. So, das ist jetzt auf der Audiospur schwer zu erklären mit der ganzen Rechnerei und das ist schwer zu folgen. Deswegen guck dir einfach die Online-Rechner an. Da gibt es einen Haufen von verschiedenen Websites, die solche Online-Prüfungsrechner für die IT-Berufe haben. Es gibt übrigens auch in Anführungszeichen offizielle Rechner von der IHK. Von einer der IHK, besser gesagt.

[9:58] Verlinke ich auch in den Shownotes zu dieser Episode. Das ist einfach eine Excel-Datei. Kannst du dir runterladen und da ist dann quasi die offizielle Berechnung, kannst dir auch angucken, wie das gerundet wird und so weiter. Manchmal kommt es ja wirklich auf die Nachkommastelle an, auf ein halbes Prozent, ob das dann auf- oder abgerundet wird, um die Prüfung zu bestehen. Von daher zieh dir einfach die Excel-Datei, trag dir mal deine Daten ein und dann weißt du, ob du bestehst oder nicht. Damit rechnet auch deine IHK.

[10:21] Gut, also wir fassen nochmal zusammen. Hast du eine 5, kannst du bestehen. Hast du zwei Fünfen oder eine 6 in den schriftlichen Prüfungen, dann bist du auf jeden Fall raus. So und jetzt kommen wir nochmal zurück zum Einleitungssatz von Absatz 2 in der Vorrufsordnung. Auch unter Berücksichtigung einer mündlichen Ergänzungsprüfung. Das heißt, wenn du jetzt zwei Fünfen hast oder eine 6, dann kannst du trotzdem noch bestehen, indem du diese Note durch die Ergänzungsprüfung ausgleichst. Darum geht es. Das heißt, bei zwei Fünfen müsstest du mit der Ergänzungsprüfung eine Fünf loswerden, also die auf eine Vier heben. Bei einer Sechs müsstest du mit einer MEP mindestens die Sechs auf die Fünf heben, damit du bestehst. Weil mit einer Fünf ist ja okay, kannst du bestehen, aber die Sechs darf halt nicht stehen bleiben. Das heißt, wann musst du in eine Ergänzungsprüfung? Ganz einfache Kiste. Hast du zwei Fünfen, musst du eine davon ausgleichen. Hast du eine Sechs, musst du die auf jeden Fall ausgleichen. Ja, und wenn du natürlich noch eine Sechs und eine Fünf hast, Ist ja gut, dann wird es irgendwann schwierig. Also du musst diese anderen Vorgaben einhalten. Insgesamt 50 Prozent in allen Prüfungsbereichen von Teil 2. Und wenn du das hinkriegst, dann hast du die Prüfung bestanden. Und ich sage mal schon so, eine 6 auszugleichen auf eine 4, auf 50 Prozent ist schon extrem schwierig. Wir machen mal ein kurzes Brechenbeispiel. Das werde ich gleich dann auch mal an ein, zwei Beispielen wiederholen.

[11:40] Wir haben nämlich noch gar nicht den Paragrafen uns angeschaut zur Münchner Ergänzungsprüfung, wie das berechnet wird. Aber ich spoiler schon mal so ein bisschen, wenn du eine 6 hast, also zum Beispiel 30 Prozent in einem Prüfungsteil, dann musst du tatsächlich 90 Prozent in der Ergänzungsprüfung holen, um diese 6 auf eine 4 hochzuziehen. Das ist also schon heftig. Ich meine, wenn du eine 6 hast, das ist ja, wie soll ich das sagen, da hast du echt nicht viel gewusst. Und es ist jetzt relativ unrealistisch, dann in der Ergänzungsprüfung zum gleichen Thema auf einmal 90%, also eine sehr gute 2 zu holen, um dann insgesamt auf eine 4 zu kommen. Also das ist schon unrealistisch. Deswegen geht es wahrscheinlich bei einer 6 eher darum, dass du die 6 auf eine 5 hebst, um dann halt damit deine Prüfung zu bestehen. Das ist zwar kein guter Abschluss, in Anführungszeichen, aber das Ding auf eine 4 zu heben ist in den meisten Fällen utopisch. Und das mit den 90% funktioniert ja nur, wenn du exakt 30% hast, wenn du weniger hast. Und ja, ich nehme das jetzt hier Anfang 2026 auf. Wir haben gerade die schriftlichen Prüfungen korrigiert letzte Woche. Da waren einige Sechsen leider dabei in einem schriftlichen Teil. Und das sind dann manchmal 15 Punkte, 16 Punkte. Da ist es dann rein rechnerisch schon gar nicht mehr möglich, auf eine 4 zu kommen überhaupt.

[12:54] Das heißt, das funktioniert bis, ja, müsste ich jetzt mal im Kopf rechnen, ich glaube bis 25 Punkten. Wenn du 25 Punkte hast, also eine dicke 6, und dann 100% in die Ergänzungsprüfung holst, dann kommst du auf die 50%, aber das ist ja unrealistisch, schon 25 auf 100, ganz ehrlich. Also von daher, da geht es dann meistens darum, auf eine 5 zu kommen, um gerade so mit einem Auge durch die Prüfung zu kommen quasi. Und wenn du zwei 5 hast, dann musst du aber wirklich eine davon auf eine 4 heben, weil du darfst das halt nur eine 5 haben. So, das ist jetzt mal zur Einleitung mit ein bisschen Beispielen und Rechnerei und jetzt gucken wir uns mal die Paragraphen zur Ergänzungsprüfung an, was da so drin steht.

[13:34] So, in der Vieh-Ausbüffe ist direkt der nächste Paragraf, der Paragraf 17 der zur mündlichen Ergänzungsprüfung. Und der geht los mit dem ersten Absatz. Der Prüfling kann in einem Prüfungsbereich eine mündliche Ergänzungsprüfung beantragen. Das heißt, erster Punkt, der Prüfling ist selbst dafür verantwortlich, diese MEP zu beantragen. Man kriegt die nicht automatisch. So steht es im Gesetz. Wie es in der Realität läuft, ist natürlich eine andere Frage. Die meisten IHK werden automatisch, wenn man ein schlechtes Ergebnis hat, eine MEP ansetzen, weil die Leute wollen ja durch die Prüfung kommen und wenn das jetzt jeder einzeln beantragen müsste und die Leute vergessen das, dann sind sie durchgefallen, müssen ein halbes Jahr. Also die meisten IHK werden das wahrscheinlich von sich aus regeln, aber rein rechtlich müsstest du selbst diese Ergänzungsprüfung beantragen. Jetzt kommt Nummer zwei.

[14:20] Dem Antrag ist stattzugeben, wenn er für einen der folgenden Prüfungsbereiche gestellt worden ist. A. Und jetzt kommen die fachspezifischen Namen der Prüfung. Ich bin jetzt hier im Bereich Anwendungsentwicklung, also Planen eines Softwareprodukts. B. Entwicklung und Umsetzung von Algorithmen. Oder C. Wirtschaft und Sozialkunde. So, und hier würden jetzt halt in den anderen Paragraphen die Namen deiner jeweiligen Prüfungsteile stehen, wenn du nicht Anwendungsentwicklung wärst. Und hier siehst du schon, es muss also in einem der schriftlichen Prüfungen sein. Du kannst nicht das Projekt ausgleichen. Das ist nicht möglich. Projekt durch, dann bist du leider durch. Das ist so. Also da gibt es keine MEP. Nur in einer der drei schriftlichen Prüfungen kannst du eine MEP machen. Jetzt kommt Satz 2. Wenn der benannte Prüfungsbereich schlechter als mit ausreichend bewertet worden ist. Das heißt, auf Deutsch gesagt, du musst durchgefallen sein. Du musst unter 50 Prozent haben.

[15:12] Du kannst also mit einer MEP nicht deine Note aufbessern. Angenommen, du hast jetzt, weiß ich nicht, eine 4 oder eine 3 und willst aber eine 1. Das geht leider nicht. Also die MEP ist nur dafür da, deine Prüfung zu bestehen, wenn du eigentlich durchgefallen wärst. Du kannst sie nicht noch einfach mal munter beantragen, um deine Note hochzuziehen oder so, weil du Lust hast. Das funktioniert nicht. Es geht hier nur ums Bestehen oder nicht. Und Nummer drei, das ist auch nochmal wichtig, wenn die mündliche Ergänzungsprüfung für das Bestehen der Abschlussprüfung den Ausschlag geben kann. Auf Deutsch gesagt, du darfst nur eine MEP machen, wenn du danach auch die Prüfung bestehen kannst. Wenn du zum Beispiel schon drei Fünfen hast oder eine Fünf und eine Sechs oder so und es ist rein rechnerisch gar nicht mehr möglich, die Prüfung zu bestehen, dann wird dich auch keiner eine mündliche Ergänzungsprüfung machen lassen. Das ist ja vergebene Liebesmüh für dich und auch für den Prüfungsausschuss. Die prüfen dann irgendwas und am Ende bist du trotzdem durchgefallen. Also das wird nicht passieren. Das heißt, du darfst nur in einer der schriftlichen drei Prüfungen eine MEP beantragen, auch nur, wenn du da durchgefallen bist, also unter 50 Prozent hast, und auch nur, wenn du dann im Endergebnis noch bestehen kannst. Und wenn das nicht mehr möglich ist, gibt es auch keine MEP. Ganz einfach.

[16:19] So, jetzt kommt der nächste Punkt. Die mündliche Ergänzungsprüfung darf nur in einem einzigen Prüfungsbereich durchgeführt werden. Das heißt, wenn du durch drei Prüfungen durchfällst, kannst du nicht drei MEPs machen und bist dann trotzdem durch. Dann ist durchgefallen wirklich durchgefallen. Sondern du kannst eine einzige Ergänzungsprüfung machen, um eine 6 oder eine 5 hochzuziehen oder auszugleichen. Wenn du mehrere Probleme hast, dann kannst du dich schon auf einstellen, in einem halben Jahr nochmal die Prüfung zu machen. Da hast du keine Chance. Du kannst jetzt nicht nochmal drei MEPs machen, weil du alle 5 hast. Das funktioniert leider nicht. Eine einzige MEP ist möglich. Dann kommt Absatz 3, die mündliche Ergänzungsprüfung soll 15 Minuten dauern. Also quasi wie das Fachgespräch. Präsentation, Fachgespräch, MEP dauern alle 15 Minuten. Hier steht, soll 15 Minuten dauern.

[17:06] Kann auch mal 16 dauern oder 14, je nachdem, aber 15 ist das Richtmaß. Und dann kommt 4, bei der Ermittlung des Ergebnisses für den Prüfungsbereich sind das bisherige Ergebnis und das Ergebnis der mündlichen Ergänzungsprüfung im Verhältnis 2 zu 1 zu gewichten. Was bedeutet das? Da sehen wir jetzt, dass so eine MEP gar nicht so viel Hebelwirkung hat, denn dein bisheriges Ergebnis wird mal 2 genommen und das Ergebnis der MEP wird mal 1 genommen und das wird dann geteilt durch 3 dein neues Ergebnis. Beispiel von eben, wenn du 40% geschrieben hast, also eine 5, dann wird das mal 2 genommen, also 80 und dann kommt deine Ergänzungsprüfung dazu, angenommen du hast da 50% geholt, dann wird gerechnet 80 plus die 50, das sind 130 und jetzt müssen wir aber nochmal durch 3 teilen, um auf eine Note zu kommen und 130 durch 3 sind leider weniger als 50, das heißt du bist im Endergebnis trotzdem durchgefallen. Wie können wir jetzt ausrechnen, was du haben musst, damit du bestehst? Bleiben wir bei den 40%. Die 40%, die du geschrieben hast, wird verdoppelt, also 80. Und jetzt kann man ja ein bisschen mathematisch überlegen. Wenn am Ende das Ding geteilt durch 3 gerechnet wird und du dann auf 50% kommen musst, dann wäre ja das Minimum, was du erreichen musst, durch zweimal altes Ergebnis plus einmal neues, 150. Weil 150 geteilt durch 3 ist 50%, dann hättest du bestanden.

[18:32] Jetzt können wir das also einfach ein bisschen umstellen und ein bisschen rechnen. Wenn du 40 Prozent hast, nimmst du das Ding mal 2, sind die 80. Und jetzt musst du eigentlich nur noch die Differenz bis 150 erreichen. Das wäre 150 minus 80 sind 70. Das heißt, wenn du 40 geschrieben hast, musst du 70 Prozent in der MEP holen, damit du insgesamt auf 50 Prozent und damit auf das Bestehen kommst. Und du siehst schon, das ist ganz schön viel. 40 ist, naja, eine mittlere 5, ziemlich genau die Mitte der 5. Und jetzt musst du aber 70 Prozent, also eine, naja, schlechte 3 in der MEP holen, um das auszugleichen. Und von 5 auf 3, ich meine, das sind zwei Noten dazwischen. Das ist jetzt also nicht so einfach. Man kann jetzt also nicht sagen, ja, ich mache mal eben eine MEP und dann rette ich mir den Arsch. Auf Deutsch gesagt, du musst da ganz schön viele Punkte holen aufgrund dieses Verhältnisses, aufgrund der Gewichtung. Und deswegen mein Beispiel von vorhin, wenn du eine 6 hast, 30 Prozent, 30 mal 2 sind 60, 150 minus 60. Sind 90%. Das heißt, du musst eine gute 2 holen, um eine 6 ausgleichen zu können.

[19:38] Wenn wir das jetzt mal umdrehen und ein bisschen rechnen, wenn wir mal 2 nehmen und wir fangen mit 25% an, weil du eine gute 6 hast mit 25%, die geht da bis 0, dann hast du 25 mal 2 sind 50 und 150 minus 50 sind 100. Das heißt, das wäre das Maximum, wenn du in einer MEP 100% holst, also perfekt die MEP machst, dann kannst du maximal 25 Punkte in einer Prüfung ausgleichen. Anders formuliert, ab 24 Punkten ist vorbei. Wenn du 24 Punkte oder schlechter in einem dieser drei schriftlichen Prüfungen hast, dann kannst du nicht mehr auf 50% in dieser Prüfung kommen. Es ist nicht mehr möglich. Rein rechnerisch geht das nicht.

[20:21] Und wie gesagt, ich habe jetzt gerade schon erzählt, wir haben ein paar mehr Prüfungen dieses Jahr, die unter 24 Punkten waren, auf jeden Fall. Und da kann es dann wirklich nur noch darum gehen, aus der 6 eine 5 zu machen. Alles andere ist nicht realistisch. Und dann kann man nur die Daumen drücken, dass nicht in dem anderen Prüfungsteil noch irgendwo eine 5 da steht, weil sonst ist es halt vorbei. Das heißt, wenn man eine 6 hat und in den anderen Teilen eine 4 oder besser, dann kriegt man es noch hin, indem man die auf eine 5 hebt. Aber ansonsten ist man mit einer 6 leider raus, weil du es rechnerisch einfach nicht ausgleichen kannst. Funktioniert nicht.

[20:52] Also, es ist nicht immer das Ziel, in einer mündlichen Ergänzungsprüfung für diesen Prüfungsbereich auf 50 Prozent zu kommen, also auf eine 4, sondern es geht meistens darum, wenn man wirklich schlechte Prüfungen hat, dass man insgesamt noch auf diese 50 Prozent für alle Prüfungsbereiche kommt und nur eine 5 da stehen hat. Das ist eigentlich das Ziel, was viele Prüflinge haben werden. Es geht hier also nicht darum, oh, ich mache nochmal eben die MEB und am Ende habe ich doch noch eine 1. Na, nee. Allein durch diesen letzten Satz, die Nummer 4 in dem Paragrafen hier, das Verhältnis 2 zu 1, ist es rechnerisch unmöglich, auf eine wirklich gute Note noch zu kommen mit der MEP. Es funktioniert einfach nicht. Also, wir fassen nochmal zusammen. Du musst die MEP selbst beantragen. In der Realität wird deine IHK das aber sehr wahrscheinlich automatisch für dich machen. Es darf nur in einem der schriftlichen Prüfungsteile passieren. Diese Prüfung muss schlechter als 4 sein, also ab 49 abwärts. Und du darfst auch nur die MEP machen, wenn du insgesamt noch bestehen kannst. Und wir haben ja gerade schon ein paar Beispiele gesehen, dass das teilweise recht schwierig ist. Also in dem Fall kannst du dich eigentlich davon verabschieden, wenn du zwei Fünfen hast und nicht mehr ausgleichen kannst oder so eine schlechte Sechs. Dann musst du leider die Prüfung wiederholen in einem halben Jahr. Das geht nicht anders. Die mögliche Ergänzungsprüfung dauert 15 Minuten und Gewichtung ist 2 zu 1. So ein paar Berechnungsbeispiele hatten wir jetzt. Dürfte die formale Geschichte, sag ich mal, klar sein. Und jetzt kommen wir zum nächsten Teil.

[22:15] Und zwar stellen sich natürlich viele Prüflinge, die in eine MEP müssen, die Frage, oh Gott, wie läuft das denn ab? Gibt es einen separaten Termin? Wird das einfach nach der Prüfung gemacht? Etc. Und da kann ich leider nur die Antwort geben. Kommt drauf an. Und worauf kommt es an? Naja, auf eine der 79 IHK, bei der du geprüft wirst, weil das ist nicht geregelt. Ich habe jetzt alles aus dem Gesetz, aus der Berufsverordnung vorgelesen zur MEP. Hier steht also nirgends mehr drin, es ist am Tag der möglichen Prüfung durchzuführen oder Sonstiges. Es gibt keine weiteren Vorgaben. Das heißt, es liegt jetzt einfach an deiner IHK, wann und wo und wie du geprüft wirst.

[22:52] Es soll eine mündliche Prüfung sein von 15 Minuten. Das ist der einzige Teil, der vorgegeben ist. In unserem Fall, ich kann es von mir berichten, von IHK Hollenburg, wir machen es so, dass wir die MEPen, das ist ja eingeschränkt auf eine einzige, man kann ja nur eine einzige MEP machen, wie gerade vorgelesen. Und deswegen machen wir die immer direkt am Prüfungstag, wo der Prüfling auch vor Ort ist. In unserem Fall, wir haben ein großes Einzugsgebiet, da fahren die Leute teilweise eine Stunde, teilweise anderthalb Stunden bis zur Prüfung. Und wenn man da jetzt noch einen zweiten Termin macht, wo man nur für 15 Minuten herfahren muss. Das ist sowohl für den Prüfling, allerdings auch für den Prüfungsausschuss extrem nervig, weil wir kommen auch nicht alle aus Oldenburg selber und fahren teilweise ich selber zum Beispiel auch über eine Stunde zur Prüfung. Und das ist ja alles Ehrenamt und Freizeit, beziehungsweise geht bei den meisten Leuten von der Arbeitszeit ab und die Arbeitgeber stellen frei. Das heißt, da wollen wir nicht nochmal für 15 Minuten für eine Person irgendwo hinfahren. Das ist einfach viel zu aufwendig. Deswegen machen wir das einfach am gleichen Tag. Ich weiß aber, dass es bei anderen IHKern durchaus einen separaten Termin nur für Ergänzungsprüfung gibt. Also kurz gesagt wieder mal, es kommt drauf an. Frag bei deiner IHK, wie es da geregelt ist. Einige IHKern schicken dann sogar Einladungen raus, wo drin steht, hier und da und dort ist die Ergänzungsprüfung.

[24:04] Das ist wirklich ganz, ganz unterschiedlich. Und bitte verlass dich da weder auf meine Aussagen noch auf irgendwas anderes im Internet oder bei Reddit oder sonst wo. Frag bei deiner IHK nach. Das ist das einzige Verlässliche für deine Prüfung. Niemand anderes aus dem Internet kann dir da weiterhelfen. Und selbst wenn du einen Prüfling hast, der bei deiner IHK geprüft wurde, vielleicht ist das inzwischen verändert worden. Vielleicht macht der eine Ausschuss das so und der andere Ausschuss das so. Wir haben zum Beispiel in Oldenburg drei verschiedene Ausschüsse, die arbeiten weder am gleichen Standort noch nach exakt den gleichen Vorgaben im gleichen Raum etc. Das heißt, es kann von Ausschuss zu Ausschuss sogar noch unterschiedlich sein. Also bitte, bitte, bitte, frag bei deiner IHK nach und verlass dich nicht auf irgendwas anderes, was du sonst wo gelesen hast. Außer auf der offiziellen Seite deiner IHK. Wenn du da was liest, kannst du davon ausgehen, dass das stimmt.

[24:50] Okay, also kurz gesagt, wann und wo die stattfindet, kommt darauf an. In unserem Fall ist es so, dass wir es einfach nach den restlichen Prüfungen am Tag der mündlichen Prüfung machen, also nach Präsentation im Fachgespräch. Dann geht in unserem Fall der Prüfung nochmal einmal raus. Wir überlegen uns Fragen für die mündliche Ergänzungsprüfung und dann kommt der Prüfung wieder rein und dann geht er bloß. Die letzte MEP, die ich hatte, war tatsächlich im Bereich WISO. Da haben wir uns einige alte WISO-Prüfungen geschnappt, haben ein paar Themenbereiche rausgesucht und haben darüber halt ein zweites Fachgespräch geführt, wenn man so will. Und das war dann unsere MEP. Auch das kann von IHK zu IHK und von Ausschuss zu Ausschuss komplett unterschiedlich sein. Ich habe schon gehört von Ausschüssen, die erstmal schriftliche Aufgaben dem Prüfling geben, die er in Ruhe vorbereiten kann und dann wird darüber ein Fachgespräch geführt. Ich habe schon gehört von Aufgaben, die man an einer Tafel lösen musste. Sowas wie formulieren Sie ein SQL-Statement oder machen Sie dies und das im Pseudocode und dann an der Tafel. Also es gibt da ganz, ganz unterschiedliche Ausprägungen. Auch das kann ich dir nicht verbindlich für deine IHK und deinen Ausschuss sagen. Wenn die IHK dir das erzählt, wie das geht, dann ruf da an und frag nach. Aber im Zweifel wissen die das noch nicht mal, weil die Ausschüsse das unterschiedlich machen. Du musst immer daran denken, die IHK ist das Verwaltungsorgan, kümmert sich um die Termine und Einladungen und alles. Aber der Prüfungsausschuss, der bestimmt deine Note, der prüft dich. Und der hat im Prinzip die Freiheit, diese Prüfung zu gestalten, wie er möchte. Denn, wie wir gerade gesehen haben, im Gesetz ist da nichts vorgegeben, außer 15 Minuten unmündlich.

[26:15] Okay, also auch hier, da kannst du dich dann vielleicht an Erfahrungsberichten von anderen Prüflingen orientieren, vielleicht im Internet irgendwo mal gucken, im Forum, bei Reddit etc., ob irgendwer von deiner IHK schon mal eine MEP hatte. Und dann kannst du da fragen, wie es abgelaufen ist. Aber auch hier, bevor du im Internet einen Thread aufmachst, ruf doch mal bei der IHK an oder schick eine E-Mail hin. Denn die wissen wohl mit einer MEP, dass man da vielleicht ein bisschen nervös wird und tausend Fragen hat. Und da sollten die dann darauf reagieren und antworten. Dann als, weiß ich nicht, Ausbildungsberaterinnen gibt es dann, glaube ich, bei der IHK, die helfen dir dann.

[26:47] Die sind dafür zuständig. Das heißt, wenn du verlässliche Informationen zu deiner MEP haben willst, bitte, ich wiederhole es nochmal, weil ich sehe so viele Beiträge im Internet, wo du dann fragen, wie ist das dann bei der IHK XY, wie werde ich denn da geprüft? Ja, weiß ich nicht, keine Ahnung. Frag doch bitte bei der IHK nach. Wie gesagt, 79 verschiedene, alle machen es unterschiedlich. Also einmal anrufen, Hörer in der Hand nehmen oder Handy in der Hand nehmen, Hörer gibt es ja gar nicht mehr und ruf da mal an und frag mal nach. Also, in unserem Fall ist es dann so, Prüfling kommt rein, es wird rein mündlich gemacht, wir bereiten nichts vor, wir lassen die Leute auch nichts an der Tafel schreiben und es ist eine rein mündliche Prüfung quasi wie das Fachgespräch, nur eben, und das ist jetzt ganz wichtig, zu Themen aus dem Prüfungsbereich, wo der Prüfling eben durchgefallen ist. Das heißt zum Beispiel Wieso, habe ich gerade gesagt, dann stellen wir halt Fragen zu Mutterschutzgesetz oder zu Tarifverhandlungen oder zu Streikrecht oder weiß ich nicht, Jugendarbeitsschutzgesetz und was da alles halt drankommt in Wieso. Das kann jetzt halt von A nach B, können wir uns da irgendwas ausdenken, es muss halt zu diesem Prüfungsbereich passen. Oder wenn es zum Beispiel Entwicklung von Algorithmen ist, dann fragen wir irgendwas zu Pseudocode oder zu SQL oder zu irgendwelchen Ur-Mail-Diagrammen oder so etwas. Das muss halt zu dem Prüfungsbereich passen. Aus diesem Bereich kommen die Fragen. Und das wäre jetzt auch der letzte Punkt für heute. Wie bereite ich mich auf die MEP vor? Ja, quasi genauso wie auf den jeweiligen Prüfungsbereich, wo du durchgefallen bist. Das ist jetzt ein toller Tipp, weil du bist ja da durchgefallen. Also hat das offensichtlich nicht so gut funktioniert mit der Vorbereitung.

[28:13] Manchmal liegt es aber auch einfach an Zeitdruck in der Prüfung. Man schafft die Aufgaben nicht mehr und so weiter. Und deswegen ist es dann vielleicht für eine mündliche Ergänzungsprüfung gar nicht mal so schwierig, weil man kann sich da ein bisschen mehr Zeit lassen. Es ist mündlich, man kann umschreiben. Ja, man muss nicht auf den Punkt präzise, zack, auf den Text in drei Zeilen exakt genau das beschreiben. Das heißt, vielleicht fällt es dir einfach einfacher, so eine mündliche Ergänzungsprüfung zu machen, als es auf dem Papier zu machen. Aber falls das nicht der Fall ist und du dich einfach nur schlecht vorbereitet hast oder große Wissenslücken hast, dann wird es natürlich interessant. Dann musst du einfach die Themen nochmal nacharbeiten, die du dir schon für die schriftliche Prüfung hättest anschauen müssen. Ganz einfach. Und da kann ich dann nur empfehlen, guck dir die alten schriftlichen Prüfungen an. Inzwischen, wir sind im Jahr 2026, wo ich das hier aufnehme, gibt es elf oder zwölf alte Prüfungen und die kannst du rauf und runter dir durchschauen. Auf meiner Website habe ich noch eine große Liste mit bisherigen Themen in den schriftlichen Abschlussprüfungen, zumindest für Einwilligungsentwicklung, für die anderen Fachbereiche leider nicht. Aber du könntest dir die Prüfung einfach selber durchgucken. Und schauen, was kommen denn da so für Themen dran. Und darauf musst du dich vorbereiten. Und in diesem Fall dann eben nicht so, dass du sie schriftlich auf Papier bringst, sondern eben mündlich. Das heißt, du übst, wie du das formulierst.

[29:23] Vielleicht in unserem Beispiel jetzt SQL. Versuchst du mündlich mal SQL-Abfragen zu formulieren, ja? Falls du das so geprüft wirst. Wie gesagt, bei deiner IHK kann das halt anders laufen. Du musst es vielleicht doch noch auf Papier machen, ja? Aber im Kern ist es ja eine mündliche Prüfung. Das heißt, du musst üben, wie du diese Inhalte auf der Audiospur vernünftig und verständlich erklärst. Also im Prinzip von der Prüfungsart bereitest du dich genauso vor wie auf dem Fachgespräch. Von den Inhalten bereitest du dich so vor wie das, was in der schriftlichen Prüfung drankommt, wo du durchgefallen bist. Und im besten Fall hilft natürlich Ausbilder, Ausbilderinnen dabei, dass ihr sowas einfach mal simuliert. Also, was für Fragen könnten denn gestellt werden zum Thema SQL oder zum Thema, weiß ich nicht, Firewall, Netzplan, Wieso, wie gesagt, Mutterschutzgesetz oder was auch immer, ja, dann spiel das einfach mal durch. Das heißt, Vorbereitung würde ich genauso empfehlen wie das Fachgespräch mit einer anderen Person wirklich mal zu sprechen. Im besten Fall mit einer Person, die sich auskennt und die sagen kann, ob das richtig war oder nicht. Also, Ausbilder, Ausbilderin, dafür sind die ja da. Das ist ja eigentlich deren Job, das zu tun, ja. Und inhaltlich, wie gesagt, guck die alten Prüfungen durch, such dir ein, zwei Themen raus und sprich das dann einfach mal mit Ausbilder-Ausbauern durch.

[30:33] Früher war es so, vor der Neuordnung, dass der Prüfling sogar sich selber aussuchen konnte, in welchem Bereich man geprüft wird, also in welchem Themenbereich. Man konnte das also zum Beispiel runterdampfen auf Softwareentwicklung oder Datenbanken oder so etwas. Das ist inzwischen aber nicht mehr möglich. Inzwischen ist einfach das Thema der durchgefallenen Prüfung das Thema der MEP. Das heißt, genauso breit, wie die schriftliche Prüfung ist, ist das Themenfeld für die mündliche Ergänzungsprüfung. Du musst dich also auf alles vorbereiten. Du kannst nicht sagen, ach ja, ich bin in dem Teil durchgefahren, da werden die ja mich bestimmt SQL fragen. Nee, die Prüfer und Prüferinnen können sich halt selber aussuchen, was sie aus diesem Themengebiet abfragen. Das ist genauso wie in der schriftlichen Prüfung, da hast du auch keinen Einfluss drauf. Dann machst du den Umschlag auf und wunderst dich, oh, das kam dran, ja, super. Und genauso ist es in der MEP auch. Also bereite dich auf alle Themen vor, guck die alte Prüfung an und üb das Zeug auf der Audiospur mit Ausbilder, Ausbilderin, Lehrer, Lehrerin, wem auch immer, irgendein fertiger Azubi-Kollege, wenn du keine Ausbilder, Ausbilderin hast. Aber irgendwie bereite dich am besten darauf vor, dass du das mündlicher machen musst. Das ist durchaus was anderes. Ein Beispiel jetzt hier mal Use-Case-Diagramm der UML auf dem Papier zu zeichnen, oder auf der Audiospur zu erklären, wie du es zeichnen würdest. Ja, das ist ein bisschen was anderes.

[31:48] Würde ich jetzt als Prüfender ein UML-Use-Case-Diagramm in der möglichen Prüfung abfragen? Eher nicht, weil es ist ja halt eben ein visuelles Ding. Aber man könnte vielleicht sowas fragen wie, was ist denn überhaupt ein Use-Case-Diagramm? Und was ist denn ein Akteur? Oder wie würde der denn aussehen? Oder was ist denn überhaupt ein Use-Case? Solche Sachen könnte man fragen. Aber so nach dem Motto, zeichnen Sie mir mal hier in Ihren Gedanken ein Use-Case-Diagramm. Solche Aufgaben finde ich persönlich natürlich maximal dämlich. Das heißt aber nicht, dass irgendwelche anderen Prüfungsausschüsse das nicht genau so machen. Oder wie eben erklärt, das dann einfach an der Tafel machen lassen. Ist ja auch okay. Also, da sind die Prüfungsausschüsse völlig autonom und können sich selber ausdenken, wie sie diese Prüfung gestalten. Also, wenn du was zeichnen musst, ist das so. Da kannst du dich auch nicht beschweren oder sonst irgendwas, weil, wie gesagt, die einzige Vorgabe ist, mündlich und 15 Minuten.

[32:33] So, fassen wir nochmal zusammen. Du bereitest dich vor mit alten Prüfungen. Du bereitest dich aber so vor, dass du es mündlich vortragen kannst. Am besten mit einer anderen Person zusammen, Ausbilder, Ausbilderin. Und ja, dann war es das eigentlich. Bereit dich auf alle Themen vor, die in diesem jeweiligen Prüfungsteil drankommen können.

[32:51] So, jetzt haben wir glaube ich alles. Zu MEP. Fassen wir nochmal kurz zusammen. Die MEP musst du machen, wenn du zwei Fünfen oder eine Sechs hast. Du musst sie nutzen, um insgesamt in Teil 2 auf 50% zu kommen. Meistens ist das nicht möglich, zum Beispiel eine Sechs auszugleichen, sondern einfach nur auf eine Fünf zu kommen, damit du insgesamt auf die 50% kommst. Es geht hier nicht darum, irgendwelche aus deiner Sicht schlechten Prüfungsteile zu verbessern, sondern es geht nur, wenn du da auch wirklich durchgefallen bist. Und es gibt eine einzige Ergänzungsprüfung. Wenn du damit deine Note nicht ausgleichen kannst, dann bist du durchgefallen und musst leider in einem halben Jahr nochmal ran. Eine andere Möglichkeit gibt es nicht. Wann die durchgeführt wird, wo und wie, das ist völlig unterschiedlich, je nach IHK. Deswegen frag da vor Ort nach, wie das bei dir vielleicht ablaufen wird, ob du selber den Antrag stellen musst, ob die IHK das schon für dich macht. Das sind wichtige Fragen, die du dir stellen musst. Denn wenn du am Ende es beantragen hättest müssen und vergisst es und fällst deswegen durch, das wäre natürlich extrem schade. Also kümmere dich rechtzeitig, sobald du siehst, oh, meine Noten, da komme ich aber nicht mehr auf die 50. Dann ist das Erste, was du machen musst, anrufen bei deiner IHK und fragen, wie geht es jetzt weiter, was muss ich machen. Verlasse dich nicht darauf, dass das alles schon irgendwie automatisch man sich um dich kümmern wird, sondern werde selber aktiv, frag nach, was du machen musst und verlass dich nicht auf irgendwelche random Aussagen aus dem Internet, sondern frag bei deiner IHK nach. Ich kann es jetzt nur noch mal wiederholen, weil das so wichtig ist.

[34:21] Ruf da an, frag nach oder schick eine E-Mail, wenn du dich anrufen willst. Aber kümmere dich bei deiner IHK darum und nicht irgendwo anders im Internet. So, und dann ist ansonsten die mündliche Ergänzungsprüfung aus meiner Sicht aber recht entspannt, weil die Prüfenden, wie die dir da gegenüber sitzen, die wollen ja auch dein Bestes. Ich meine, die MEP ist dafür da, damit du gerade noch die Prüfung bestehen kannst und das wollen die Prüfenden auch. Die Prüfenden haben keinerlei Interesse daran, dich absichtlich durchfallen zu lassen, damit du im halben Jahr nochmal geprüft werden musst. Wir müssen die ganzen Prüfungen ja dann nochmal korrigieren und wir müssen dich nochmal zum Fachgespräch einladen etc. Also wir haben da ja auch nichts davon. Im Gegenteil. Das heißt, die Prüfenden wollen auch, dass du bestehst und wollen dir helfen.

[35:01] Etwas bessere Noten als die fünf oder sechs, die man geschrieben hat, hat durchaus realistisch. Im mündlichen kann man halt viel mehr umschreiben und irgendwo nochmal Punkte geben, als wenn man das hart auf Papier aufgeschrieben hat. Ja, das heißt, die Prüfenden sind ein bisschen nachsichtiger und werden dir sicherlich vielleicht auch nicht die allerhärtesten Fragen stellen, sondern halt so in die Richtung, dass du noch eine Chance hast, durch die Prüfung zu kommen. Davon musst du einfach mal ausgehen. Und wenn du einen Prüfungsausschuss hast, der es tatsächlich darauf anlegt, dich durchfallen zu lassen, okay, dann hast du Pech gehabt, aber dann sollten das vielleicht auch keine Prüfenden sein. Ja, die meisten Prüfenden sind pro Prüfling eingestellt und wollen dir helfen. Und ich glaube, es gibt eigentlich keinen Prüfungsbereich, wo das besser geht als in der mündlichen Prüfung. Weil da kann man mit geschickten Fragen und so weiter, kann man da schon den Prüfling auch mehr unterstützen, als wenn man, ja, wie gesagt, leeres Blatt Papier, da kann ich halt nur sechs draufschreiben. Aber mit ein bisschen Nachfragen im mündlichen Bereich kriegen wir dich schon in die richtige Richtung, sodass du die Prüfung bestehst. Ja, also mach dir da nicht zu viel Gedanken. Die Prüfenden sind normalerweise alle sehr nett und wollen dir helfen und wollen dich unterstützen.

[36:04] Du musst dich natürlich aber auch ein bisschen darauf vorbereiten. Es ist deine letzte Chance, die Prüfung noch zu bestehen. Das müsstest du keine machen. Also setz dich nochmal hin, reiß dir den Hintern auf, guck dir alle Themen nochmal an, üb das Ganze mit einer anderen Person, damit du da gut dastehst in der MEP. Und dann ist es auch durchaus realistisch, dass du mit der MEP deine Prüfung noch bestehst. Ja, das will ich da sagen. Also, wenn du in die MBP gehst, heißt das nicht automatisch, dass du es nicht mehr schaffen kannst, sonst würde die MBP gar nicht angeboten, sondern geh davon aus, dass man dir helfen will, die Prüfung noch zu bestehen, aber tu auch was dafür. Ja, das will ich damit sagen.

[36:38] So, jetzt haben wir heute alles, glaube ich. Ich denke, das war ein guter Refresher, ein gutes Upgrade für dieses häufig nachgefragte Thema der mündlichen Ergänzungsprüfung. Ich hoffe, es war für dich dabei. Falls du den MBP musst, ich drücke dir beide Daumen, dass du damit trotzdem noch deine Prüfung bestehst. Und ja, wenn ich dir geholfen habe, dann lass mir gerne einen Kommentar da, am besten direkt unter der Episode. Da freue ich mich auf dein Feedback. Und jetzt alles Gute für die Prüfung. Mach’s gut und bis zum nächsten Mal.

Um den Umgang mit Fehlern in der Projektdokumentation in der Projektpräsentation und im Fachgespräch geht es in der zwölften Episode der Shorts des IT-Berufe-Podcasts.

Wenn dir nach Abgabe deiner Projektdokumentation Fehler auffallen, solltest du in der Projektpräsentation immer mit der korrigierten Version arbeiten und größere inhaltliche Fehler offen, aber knapp ansprechen. Triviale Formfehler wie Rechtschreibung oder Kommas musst du nicht thematisieren. Entscheidend ist ein professioneller Umgang: Fehler nicht leugnen oder ignorieren, sondern zeigen, was du daraus gelernt hast, wie du sie korrigiert hast und welche Folgen sie für das Projekt haben.

Inhalt Umgang mit Fehlern nach Abgabe der Projektdokumentation

Wenn dir nach der Abgabe deiner Projektdokumentation noch Fehler auffallen, gilt grundsätzlich: korrigieren statt ignorieren. Kleine formale Fehler musst du nicht extra erwähnen, größere inhaltliche Fehler solltest du dagegen offen und professionell behandeln.

Grundidee

Die Projektdokumentation, die Projektpräsentation und das Fachgespräch sind getrennte Prüfungsleistungen. Deshalb solltest du Fehler aus der Doku nicht einfach in die Präsentation übernehmen, nur weil die Doku schon abgegeben ist. In der Präsentation solltest du immer die korrigierte Fassung zeigen.

Wichtig ist dabei:

• Fehler offen ansprechen, wenn sie relevant sind
• keinen großen Fokus auf die Fehler legen
• zeigen, wie du den Fehler erkannt und behoben hast
• deutlich machen, was du daraus gelernt hast

Warum Fehler oft erst später auffallen

Zwischen Abgabe der Dokumentation und Präsentation oder Fachgespräch liegen oft mehrere Wochen. In dieser Zeit bereitest du deine Präsentation vor und schaust dir Inhalte wie Kostenrechnung, Amortisation, Diagramme oder Projektplanung nochmal an. Dabei kann dir auffallen, dass etwas falsch gerechnet, unvollständig oder inhaltlich nicht mehr passend ist.

Welche Fehler du ignorieren kannst

Triviale formale Fehler musst du nicht ansprechen. Dazu gehören z.B.:

• Rechtschreibfehler
• fehlende Kommas
• falsche Seitenzahlen
• kleinere Verweisfehler

Solche Kleinigkeiten führen nicht dazu, dass du durchfällst, und sind in der Präsentation nicht relevant.

Welche Fehler du korrigieren und ggf. ansprechen solltest

Relevant sind inhaltliche Fehler, also alles, was Auswirkungen auf das Projekt oder die Bewertung haben kann. Beispiele aus dem Text sind:

• Rechenfehler in der Kosten- oder Amortisationsrechnung
• Fehler in der Zeit- oder Ressourcenplanung
• vergessene Arbeitsstunden von Mitarbeitenden
• falsche oder nicht mehr passende technische Entscheidungen
• fehlende oder falsche Diagramme
• geplante, aber nicht umgesetzte Features

Solche Fehler können zu einer anderen Einschätzung des Projekts führen. Deshalb solltest du sie professionell behandeln.

Professioneller Umgang mit Fehlern

Fehler zu machen ist normal, auch in echten IT-Projekten. Entscheidend ist nicht, dass nie etwas schiefläuft, sondern wie du damit umgehst. Genau das ist auch in der Prüfung relevant.

Ein professioneller Umgang bedeutet:

• den Fehler erkennen
• einschätzen, wie schwerwiegend er ist
• überlegen, ob und wie er korrigiert werden kann
• die Auswirkungen auf das Projekt benennen
• erklären, wie du solche Fehler künftig vermeiden willst

Das entspricht auch dem Verhalten im Berufsalltag. Wer merkt, dass sich ein Projekt später amortisiert oder länger dauert, darf das nicht verschweigen.

Was in die Präsentation gehört

In der Projektpräsentation solltest du nur dann auf einen Fehler eingehen, wenn er für die gezeigten Inhalte relevant ist.

Kleine Auswirkungen

Wenn sich durch einen Rechenfehler am Ergebnis praktisch nichts ändert, kannst du in der Präsentation einfach die korrigierte Version zeigen und den Fehler kurz mit einem Nebensatz erwähnen.

Beispiel aus dem Text:

• Die Amortisation verschiebt sich nur um wenige Monate.
• Die Entscheidung für das Projekt bleibt trotzdem gleich.

Dann reicht ein kurzer Hinweis, dass die Rechnung in der Doku leicht falsch war, das Endergebnis aber unverändert bleibt.

Größere Auswirkungen

Wenn ein Fehler deutliche Folgen hat, solltest du ihn klar benennen. Das kann z.B. sinnvoll sein, wenn:

• das Projekt sich gar nicht mehr amortisiert
• mehrere Features nicht umgesetzt wurden
• sich wesentliche Projektentscheidungen ändern

Dann kann es sogar sinnvoll sein, dafür eine eigene Folie einzuplanen und nachvollziehbar zu erklären:

• was anders gelaufen ist als geplant
• warum das passiert ist
• welche Konsequenzen das hatte
• wie du damit umgegangen bist

Was du nicht tun solltest

Unprofessionell wäre es,

• einen bekannten Fehler absichtlich in der Präsentation zu wiederholen
• Fehler zu ignorieren
• Fehler zu leugnen
• lange auf Fehlern herumzureiten
• in der Präsentation Fehler anzusprechen, die dort gar nicht vorkommen

Wenn ein fehlerhaftes Diagramm in der Präsentation gar nicht gezeigt wird, musst du es dort auch nicht thematisieren. Du sollst dich nicht unnötig schlechter machen.

Vorbereitung auf das Fachgespräch

Auch wenn du einen Fehler in der Präsentation nicht ansprichst, solltest du dich auf Fragen dazu im Fachgespräch vorbereiten. Mindestens ein Teil des Prüfungsausschusses hat die Doku gelesen und könnte den Fehler gefunden haben.

Dann ist eine gute Reaktion z.B.:

• den Fehler bestätigen
• sagen, dass er inzwischen erkannt und korrigiert wurde
• die Auswirkungen kurz erklären

So kann es sein, dass du in der Doku für den Fehler einen Punkt verlierst, im Fachgespräch aber einen positiven Eindruck hinterlässt, weil du professionell damit umgehst.

Besonderheit beim Prüfungsausschuss

Nicht alle Prüfenden haben deine Dokumentation zwingend gelesen. In vielen Ausschüssen wird die Arbeit aufgeteilt. Deshalb gilt für die Präsentation generell:

• geh nicht davon aus, dass alle deine Doku kennen
• erkläre dein Projekt so, dass auch neue Zuhörende folgen können
• verschwende keine Präsentationszeit mit langen Fehlererklärungen

Gerade deshalb solltest du Fehler nur kurz und zielgerichtet ansprechen.

Einfluss auf die Note

Ein einzelner Fehler führt normalerweise nicht dazu, dass du durchfällst. Das Projekt wird als Gesamtleistung bewertet. Auch mit kleineren oder sogar größeren Fehlern kannst du noch eine gute oder sehr gute Note erreichen.

Kritisch wird es eher dann, wenn du unprofessionell reagierst, also z.B.:

• Fehler bewusst verschweigst
• sie abstreitest
• Ausreden suchst

Zentrale Kernaussage

Wenn dir nach der Abgabe Fehler auffallen:

• bleib ruhig
• korrigiere inhaltliche Fehler
• zeige in der Präsentation immer die richtige Version
• sprich relevante Fehler kurz und offen an
• bereite dich auf Nachfragen im Fachgespräch vor
• zeige, was du daraus gelernt hast

Vorbeugung vor der Abgabe

Am besten ist es natürlich, Fehler schon vor der Abgabe zu vermeiden. Dafür kann es helfen, die Doku vor dem Einreichen noch einmal von anderen gegenlesen zu lassen, z.B. durch:

• dein:e Ausbilder:in
• andere Personen im Umfeld
• ein geeignetes KI-Tool für Rechtschreibung und Kommasetzung

Das Optimum ist immer der Fehler, den du gar nicht erst machst.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts

Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode

[0:20] Heute geht es um ein Thema, was wirklich sehr häufig gefragt wird, und zwar bezüglich der beiden Prüfungsleistungen, Projektdokumentation und Projektpräsentation und Fachgespräch. Wie soll ich damit umgehen, wenn ich in meiner Projektdokumentation Fehler finde, und zwar nachdem ich sie abgegeben habe? Soll ich das in der Projektpräsentation ansprechen? Soll ich die korrigieren? Soll ich darauf hinweisen? Soll ich das ignorieren? Soll ich es leugnen? Wie gehe ich mit Fehlern in der Doku um, nachdem die Doku abgegeben ist. Und es kommen dann ja noch zwei Prüfungsleistungen, nämlich die Präsentation und das Fachgespräch, wie gerade auch schon gesagt. Und es gibt ja verschiedene Möglichkeiten, wie ich mit diesen Fehlern umgehen kann. Und wie man am besten damit umgeht, ich würde erst mal sagen, wir fangen wieder mit dem Too Long den Read an. Ich würde sagen, immer korrigieren. Wenn dir Fehler auffallen, korrigiere sie im Nachhinein. Trivialitäten auf jeden Fall einfach stillschweigend sogar korrigieren. Und große Sachen explizit aber ansprechen, wenn sie irgendwie wichtig fürs Projekt sind und krass andere Entscheidungen zur Folge hätten oder das Projekt auf einmal drei Jahre länger braucht, um sich zu automatisieren oder Sonstiges.

[1:23] Das würde ich auf jeden Fall ansprechen, aber keinen Fokus auf die Fehler legen. Projektpräsentation und Fachgespräch sind separate Prüfungsleistungen. Die haben zwar mit dem gleichen Thema zu tun, nämlich dein Projekt, aber die Projektpräsentation ist eine eigenständige Prüfungsleistung, unabhängig von der Doku. Also auch wenn du der Doku durchfällst, mal als Beispiel, könntest du eine Projektpräsentation bestehen, weil das sind halt zwei getrennte Prüfungsleistungen. Also, kurz gesagt, sprich die Fehler an, geh offen damit um, kommuniziere das und sag, dass du was gelernt hast, aber leg nicht den Fokus auf die Fehler. Und was ich jetzt genau damit meine, da gehen wir jetzt in den nächsten Minuten drauf ein. Fangen wir mal vorne an. Um was für Fehler soll es heute überhaupt gehen und warum kann und darf oder muss man die überhaupt korrigieren? Ich glaube, das Zweite ist einfacher zu beantworten. Zwischen der Abgabe der Dokumentation und der Projektpräsentation und Fachgespräch liegen bei vielen Prüflingen tatsächlich mehrere Wochen. Also jetzt mal nur als Beispiel. Ich nehme das gerade 2026 auf. Da war die Prüfung Ende April und zum Beispiel bei meiner IHK war dann eine Woche später die Abgabe. Also Anfang Mai musste man die Projektdokumentation abgeben.

[2:28] Die Fachgespräche und Projektpräsentationen gehen aber bis Ende Juni. Das heißt, fast zwei Monate liegen eventuell dazwischen, zwischen Abgabe der Doku und dem mündlichen Prüfungstermin. Und in anderen Bundesländern, das richtet sich ja oft auch nach den Schulferien, wann die anfangen. Es sind ja auch immer Lehrer und Lehrerinnen mit im Prüfungsausschuss. Und die werden natürlich nur in den Schulzeiten eingesetzt. Das heißt, je nachdem, wann die Ferien starten, kann das halt noch später sein oder eben auch früher. Das kommt halt ganz auch so ein bisschen aus dem Bundesland an. Und natürlich auch noch auf die IHK die Räumlichkeiten haben muss, etc. Also eine Terminplanung mit so vielen Prüfenden und Prüflingen ist grundsätzlich sehr schwierig. Aber bei vielen Prüflingen wird es so sein, dass, ich sage mal, mehrere Wochen zwischen Projektdokumentation, Abgabe und den anderen beiden Prüfungen an Prüfungsleistungen liegen werden. So, und das kann natürlich dann sein, dass man in diesen Wochen nochmal auf sein Projekt schaut, vielleicht um die Projektpräsentation vorzubereiten. Überraschung. Da guckt man sich vielleicht die Sachen nochmal an. Da kommen ja auch wichtige Inhalte nochmal in die Präsi. sowas wie eine Kostenrechnung, Amortisation, irgendwelche Diagramme, die gezeichnet wurden, eine Projektplanung, eine Zeitplanung, etc. Das gehört natürlich auch alles in die Präsi. Habe ich schon genug Podcast-Debison zu gemacht zu dem Thema. Da guckt man sich dann vielleicht nochmal an, was habe ich eigentlich in der Doku da geschrieben? Vielleicht weiß man das nicht mehr auswendig, weil es schon ein paar Wochen her ist.

[3:41] Und dann stellt man fest, oh, da habe ich mich ja irgendwie verrechnet oder oh, das stimmt ja gar nicht oder ich habe ja gar nicht Framework X genommen, sondern inzwischen Y oder weiß der Geier was.

[3:50] Und jetzt ist die Frage, wie gehe ich dann mit solchen Sachen um? Und fangen wir mal mit den kleinen Fehlerchen an. So, ich habe irgendwo ein Komma vergessen oder ein Rechtschreibfehler oder Sonstiges. Das ist natürlich völlig… Es ist sinnfrei, das zu erwähnen. Ja, das kann jedem mal passieren. Selbst nach der Abgabe kann man auf der Titelseite noch einen Rechtsstaatfehler finden. Das habe ich auch schon oft genug gesehen. Also niemand, kein Mensch ist fehlerfrei und deswegen wirst du jetzt auch nicht durchfallen oder eine Note oder geschweige denn vielleicht nur einen Punkt abgezogen bekommen, weil irgendwo mal ein Komma fehlt. Also wenn wir das machen würden, dann würden reihenweise Leute durch die Prüfung fallen und das passiert nicht.

[4:23] Also solche Sachen sind, ich nenne die jetzt mal triviale Fehler oder es ist irgendwo, keine Ahnung, ein Verweis nicht richtig und eine Seitenzahl stimmt nicht oder sowas. Solche Trivialitäten interessieren natürlich keinen Menschen in der Projektpräsentation, da brauchst du gar nicht drauf hinweisen. Und das würde ich auch nicht ansprechen oder so. Das ist einfach, ja, ist passiert, fertig. Im Zweifel fällt das noch nicht mal im Prüfenden auf, dass irgendwo ein Komma fehlt. Also von daher, das ignorieren wir einfach. Aber wenn du jetzt solche Sachen gemacht hast, wie ich gerade schon gesagt habe, Kosten, eine Amortisationsrechnung zum Beispiel, du hast irgendwo falsch summiert Oder du hast irgendwo eine falsche Rechnung gemacht, hast falsche Zahlen benutzt oder so. Und dann stellt sich heraus, oh, das Projekt amortisiert sich doch erst drei Monate später und nicht nach dem ursprünglich ausgerechneten Termin oder so etwas. Oder du hast, keine Ahnung, ein Diagramm gezeichnet, was gar nicht zur Realität passt oder du hast dich irgendwo vertan. Oder, keine Ahnung, es gibt, sag ich mal, inhaltliche Fehler, die sich auch auf das Projekt auswirken. Da sehen die Oberflächen auf einmal anders aus, wie du bauen solltest. Oder das Projekt hat ein gewisses Feature gar nicht, was du eigentlich eingeplant hast. oder, keine Ahnung, statt drei Firewalls brauchst du doch nur zwei oder.

[5:23] Alles, was halt wirklich sich inhaltlich auf das Projekt bezieht, davon rede ich jetzt, wenn ich Fehler korrigieren sage. Alles andere formale Fehler wie Rechtschreibung etc. Kannst du auf jeden Fall ignorieren. Aber irgendwas, was vielleicht zu einer unterschiedlichen Einschätzung im Projekt geführt hätte, bei dir und auch bei den Prüfenden. Also zum Beispiel, wie gesagt, Rechenfehler, Planungsfehler in der Zeitplanung. Du hast Ressourcen vergessen, einen zu planen. Arbeitsstunden von Mitarbeitenden hast du nicht eingeplant. Zum Beispiel, da habe ich schon so oft gesehen, da schreibt jemand in seinem Text bei einem Anwendungsermittlungsprojekt, ja, ein Kollege hat noch drei Stunden ein Code-Review gemacht. Und dann gucke ich in die Kostenplanung und stelle fest so, hä, wo sind denn diese drei Stunden? Die tauchen da gar nicht auf. So sind einfach vergessen worden. Aber je nach Stundensatz macht das halt vielleicht mal 200 Euro schon aus insgesamt, wenn jemand drei Stunden auf so ein Projekt drauf guckt. Und das wurde einfach nicht mit eingeplant. Und das führt dann dazu, dass natürlich, wenn ich die Amortizierungsrechnung mache, das Ding sich später amortisiert, weil ich Kosten vergessen habe. Ganz einfach. Solche Sachen. Oder ich habe vielleicht bestimmte Frameworks, habe ich gerade schon mal angesprochen, benutzt, die sich inzwischen aber überholt haben, die ich gar nicht wirklich verwendet habe. Oder ich habe es anders gelöst. Oder ich habe vergessen, ein Diagramm einzufügen, was ich eigentlich gemalt habe. So, keine Ahnung. Ahnungsermittlung wieder beim Klassiker. Use-Case-Diagramm habe ich eigentlich erstellt. Ist aber gar nicht in der Doku zum Beispiel. Solche Sachen. Da ist jetzt die Frage, wie gehe ich damit um? Und grundsätzlich, habe ich ja gerade schon gesagt, jeder Mensch macht Fehler. Also erstmal Ruhe bewahren. Du fällst jetzt wegen einem Fehlerchen nicht durch die Prüfung. Klar, eventuell gibt es einen Punktabzug.

[6:51] Aber wahrscheinlich wird das nicht dazu führen, dass du jetzt hier ein arge Bedrängnis bekommst, nur weil du da irgendwo einen kleinen Inhalt mal vergessen hast oder so. Das kann halt passieren. Wir sind alle nur Menschen. So, jetzt ist aber die Frage, wie gehst du professionell mit diesem Fehler um? Und das ist ja auch etwas, was wir in der Prüfung auf jeden Fall bewerten. Wir gucken ja nicht nur darauf, dass du eine schöne Rechtschreibung hast, sondern vor allem geht es darum, wie sieht inhaltlich dein Projekt aus? Hast du das vernünftig geplant? Hat das einen passenden Umfang? Zeig das alles das, was du als Abschlussprüfung zeigen musst. Hast du alles gelernt, was für deinen Beruf wichtig war? Und dazu gehört natürlich auch eine Planung, eine Kostenkalkulation, Amortisation etc. Aber natürlich, auch in der Realität, können natürlich in Projekten Fehler passieren. Da wurde irgendwie was falsch geplant oder man hat sich verschätzt oder stellt sich raus, oh, mitten im Projekt gibt es eine neue Java-Version und ich muss hochziehen oder was auch immer. Und auf einmal passt alles von und hin nicht mehr. Das ist ja normal. Ich glaube nicht, dass es in der Realität irgendein Projekt gibt, was 100% so funktioniert, wie es geplant wurde. Das gibt es nicht. Und dann zeigt sich ja der Unterschied zwischen guten und schlechten Prüflingen darin, wie sie denn damit umgehen, mit solchen gefundenen Fehlern. Und das ist dann demnach eigentlich auch Teil der Prüfungsleistung, wenn so ein Fehler passiert, dass du vernünftig damit umgehst und dann genau wie im echten Leben auch überlegst, was wäre jetzt sinnvoll? Soll ich diesen Fehler einfach stillschweigend ignorieren und meinem Chef nicht sagen, dass sich das Projekt doch erst ein Jahr später amortisiert?

[8:14] Das wäre für die Realität auch keine gute Idee. Denn wenn der Chef dann irgendwann merkt, eigentlich hätten wir schon Kohle einnehmen müssen, aber ist noch nichts auf dem Konto. Was ist da los? Dann wird er ja auch zu dir kommen oder sie und sagen, was hast du denn da gemacht? Und dann ist natürlich uncool zu sagen, ach ja, das wusste ich zwar, aber ich habe es dir nicht gesagt, lieber Chef. Das ist gar keine gute Idee. Ja. Wenn wir mal überlegen, wie es in der Realität ist, du, keine Ahnung, du machst ein Projekt zum Einstieg und jemand anderes wartet darauf, dass du fertig bist und kann dann darauf aufbauend weitermachen, dann kannst du ja auch nicht einfach schweigen und sagen, ach ja, ich brauche zwar zwei Wochen länger, aber ich sage es keinem. Weil die Leute warten ja darauf. Und je früher du weißt, dass etwas zum Beispiel später fertig wird, desto früher musst du es auch weitergeben an die Leute, die darauf warten. Weil sonst verzögert sich alles Weitere und die Leute werden unruhig, das ganze Projekt wird vielleicht verschoben etc. Das können wir auf gar keinen Fall machen. Das heißt, wenn dir was auffällt, kommunizieren. So ist es in der Realität und so erwarten wir es auch in der Projektarbeit. Und wenn dir jetzt im Nachhinein ein Fehler auffällt, dann ist es sinnvoll, damit vernünftig umzugehen, zu sagen, ja, ich habe hier einen Fehler gemacht, ich habe das erkannt.

[9:18] Und nicht einfach, ja, ich habe es erkannt, Ende. Sondern viel wichtiger ist jetzt natürlich, was mache ich denn jetzt damit? Also vielleicht eine erste Einschätzung. War das ein schlimmer Fehler? Kann ich den korrigieren? Wenn ja, wie habe ich den korrigiert? Oder war das etwas, das ich gar nicht korrigieren kann, was so schlimm ist, dass das ganze Projekt jetzt auf einmal scheitert? Das ist natürlich blöd in so einer Abschlussprüfung, aber theoretisch könnte das ja auch passieren. Aber dann kannst du trotzdem immer noch die Prüfung bestehen. Ich mache nochmal eine andere Episode dazu, ob das Abschlussprojekt erfolgreich sein muss. Und Spoiler, nein, muss es nicht. Weil in der Realität scheitern ja auch. Was war das im Chaos-Report? Den gibt es, glaube ich, zu Projekten. Ich glaube, zwei Drittel aller Projekte scheitern in irgendeiner Form. Werden nicht rechtzeitig fertig, kosten mehr oder irgendwelche Features fehlen. Und von daher ist es eher die Normalität in der Realität, dass Projekte nicht erfolgreich sind. Jetzt mal, ja klar, in der Prüfung will man natürlich, dass das Projekt erfolgreich ist. Man denkt ja auch an die Note und so. Und ehrlich gesagt, ich habe noch keine Projekte dabei gelesen, wo das Projekt tatsächlich gescheitert ist.

[10:14] Überraschenderweise funktionieren die IHK-Projekte alle. Ja, es ist klar, es geht ja hier um eine Prüfung. Das ist vielleicht nicht so das echte Leben. Und man schreibt natürlich vielleicht auch nicht hundertprozentig alles auf, was nicht gut funktioniert hat. Das ist ja auch alles in Ordnung. Aber grundsätzlich wäre es kein Problem, wenn das Projekt in irgendeiner Form scheitert, weil das sogar eher realistisch ist, als alles schön zu reden und zu schreiben.

[10:35] So, also wir fassen nochmal zusammen. In der Realität musst du mit deinen Fehlern ja auch irgendwo umgehen. Das erwarten wir von einem professionellen Softwareentwickler, Administrator oder was auch immer du als IT-Beruf lernst. Und so erwarte ich das dann auch von dir in der Prüfung. Also wenn du jetzt merkst, Mensch, ich habe da einen Fehler gemacht, dann ist die Frage, was hätte ich denn tun können, um den zu vermeiden? Was mache ich, damit es beim nächsten Mal nicht nochmal passiert? Was habe ich jetzt im Nachhinein getan, um den Fehler zu beheben? Und das wäre dann ein Inhalt, der dann in der Projektpräsentation zum Beispiel kommen könnte, wenn der Fehler so groß ist, dass sich das lohnt oder wichtig ist, das anzusprechen. Bleiben wir nochmal bei meinem Beispiel mit meiner Amortisationsrechnung. Wenn sich das Ding erst drei Monate später amortisiert, aber das Projekt, weiß ich nicht, trotzdem zehn Jahre im Einsatz ist und es keinerlei Ausführung darauf hätte, das Projekt umzusetzen oder nicht, ob die Amortisation jetzt drei Monate später oder früher stattfindet. Also, das war jetzt ein komischer Satz. Also angenommen, egal ob du ein oder zwei Monate später dein Projekt erst amortisierst, wenn es keine Ausführung darauf gehabt hätte, dass du das Projekt auch umsetzt, weil das Projekt sowieso viel länger im Einsatz ist als diese ein, zwei Monate, dann ist das ja im Prinzip irrelevant für die Entscheidung, die du aus dieser Amortisationsrechnung triffst, nämlich das Projekt umzusetzen. Wenn sich jetzt herausstellt, oh, ich habe so viele Kosten vergessen, dass sich das Projekt niemals amortisieren wird, das ist natürlich ein anderes Thema. Das musst du dann natürlich nochmal ansprechen.

[11:54] Aber wenn es jetzt ein, zwei Monate, okay, du hast einen Rechenfehler drin, ja, dann würde ich sogar so weit gehen, in der Präsi einfach die korrigierte Amortisationsrechnung zu zeigen und eventuell mit einem kleinen Nebensatz darauf hinzuweisen. Ach, übrigens in der Projektmodellation habe ich mich hier ein bisschen verrechnet, das waren zwei Monate mehr oder weniger, was auch immer. Das Endergebnis ist aber das gleiche. Wir setzen das Projekt um, weil, lalalala, also eine Begründung wäre natürlich trotzdem interessant. Das heißt, in der Projektpräsentation auf jeden Fall immer die korrigierte Variante zeigen. Es ist absolut bescheuert, wenn du etwas Fehlerhaftes gefunden hast in deiner Doku, das dann fehlerhaft zu übernehmen in die nächste Prüfungsleistung, obwohl du weißt, dass es falsch ist. Das ist einfach dämlich. Das kannst du in der Realität auch nicht machen, wenn du weißt, das Projekt, ich bleibe immer bei diesem Beispiel, weil das so schön griffig ist mit der Amtionsrechnung, das kannst du auch auf alle möglichen anderen Inhalte deines Projekts beziehen. Wenn du weißt, dass das fehlerhaft ist und du zeigst es dann.

[12:47] Das ist doch super unprofessionell. Du musst es doch korrigieren, auch in der Realität. Weil die Leute werden ja vielleicht sogar, im besten Fall, werden sie das nachrechnen, was du da gezeigt hast und merken dann, hä, das ist ja fehlerhaft. Warum ist das denn nicht aufgefallen? Und dann musst du sagen, ach ja, eigentlich ist es mir aufgefallen, aber ich habe es nicht korrigiert. Ich meine, wie dumm ist das? Also du hast einen Fehler gemacht, dann musst du dazu stehen und dann musst du vor allem dafür sorgen, dass das Ding korrigiert wird und dass jetzt halt irgendwie nicht dein Unternehmen Geld verliert, weil du da irgendwo einen Fehler gemacht hast. Also, es ist, wie gesagt, es ist ja menschlich, Fehler zu machen, aber man muss halt damit umgehen und sie ausbügeln, sag ich mal. Also, bei den Prüfenden würde ich jetzt halt sagen, ja, kurz ansprechen, war falsch, ist aber egal quasi, weil Endergebnis ist das Gleiche und fertig. Wenn du jetzt richtig krasse Fehler gemacht hast in deinem Projekt, dann würde ich da vielleicht eine extra Folie für machen und sagen so, hier anders als geplant konnte ich diese drei Features nicht umsetzen, weil, so, und dann wird das halt vernünftig erklärt und dann musst du aber auch mit den Konsequenzen nehmen und sagen, ja, ich konnte die nicht umsetzen, dafür habe ich aber die Zeit in andere Sachen investiert oder es hat sich herausgestellt, es hat länger gedauert, dadurch sind die Features weggefallen, der Kunde war aber trotzdem zufrieden, weil das waren nur die Soll-Features und nicht die Muss-Features oder wie auch immer. Also du musst es halt auch erklären, was jetzt passiert. Und das unterscheidet halt, wie gesagt, einen professionellen ITler oder ITlerin von jemandem, der sagt, oh Fehler, interessiert mich nicht, ich mache nur, was man mir sagt, ich denke nicht nach. Ja, sowas wollen wir nicht.

[14:08] Okay, Hinweis nochmal zu den Prüfenden. Der Prüfungsausschuss muss ja paritätisch mit mindestens drei Menschen besetzt sein. Lehrer, Lehrerin, Arbeitnehmerin und Arbeitgeberin, Vertreter. Und jetzt ist es einfach so, du weißt, die machen das alle im Ehrenamt, kriegen dafür keine Kohle. Und in den meisten Prüfungsausschüssen wird es so sein, dass nicht alle Leute, die da sitzen, deine Dokumentation überhaupt gelesen haben. Also mindestens zwei sollten es schon sein, weil wenn ein Mensch alleine über die Note entscheidet, das ist ja auch nicht ganz richtig. Aber sind wir ehrlich, in der Realität muss das Ganze auch irgendwie in endlicher Zeit stattfinden. Und wenn ich mir vorstelle, ich habe glaube ich, dieses Jahr haben wir 40 Prüflinge, mündliche Prüfungen bei uns. Und wenn ich 40 Projektdokumentationen lesen müsste, wann soll ich das machen? Das ist ja mehr als eine ganze Arbeitswoche, die ich nur für das Lesen benötige. Das ist unmöglich, das darzustellen. Und das heißt, die meisten Prüflinge, nicht Prüfungsausschüsse in der Realität, werden die Arbeit in irgendeiner Form aufteilen. Und dann kann das so sein, dass zwei Leute aus dem Prüfungsausschuss deine Doku gelesen haben, aber die anderen, die da eventuell noch sitzen und mindestens eine Person ist das, die haben deine Doku eventuell gar nicht gesehen, gelesen.

[15:19] Das ist nochmal ein anderes Thema auch für die Präsentation. Geh davon aus, dass nicht alle Prüfenden deine Doku kennen. Das heißt, erzähl alles nochmal, als wenn da jemand sitzen würde, der es noch nie gehört hat. Aber das ist nochmal ein Thema für eine andere Episode. Aber heute geht es ja darum um die Fehler. Das heißt, wenn zwei Leute die Doku gelesen haben und zwei vielleicht diesen Fehler, den du gemacht hast, erkannt haben, die dritte Person, die weiß davon vielleicht noch gar nichts, weil sie deine Doku gar nicht kennt. Ja, manchmal sitzt übrigens noch mehr Leute im Prüfungsausschuss und die haben dann sicherlich auch alle die Doku nicht gelesen oder doch. Es kommt auf die IHK an. Also man kann es auch nicht pauschal sagen, aber meiner Erfahrung nach wird in den meisten Ausschüssen die Arbeit aufgeteilt, sodass nicht alle deine Projektdokumentation überhaupt kennen. Und dann kannst du dir überlegen, wenn du jetzt den Fehler lang und breit erklärst, wo eine Person mindestens dabei ist, die den Fehler noch gar nicht gesehen hat, dann ist das vielleicht ein bisschen verschenkte Zeit.

[16:05] Also fokussier dich nicht auf deine Fehler. Geh kurz darauf ein. Zeig, was du daraus gelernt hast und was du getan hast, um den Fehler zu korrigieren. Aber mach da jetzt nicht einen mega Aufstand von. Weil im Zweifel wissen gar nicht alle, dass du diesen Fehler überhaupt gemacht hast. Und selbst die Prüfenden, die deine Doku gelesen haben, denen ist der Fehler vielleicht auch gar nicht aufgefallen. Ich meine, das ist ja manchmal nicht so offensichtlich, dass da ein richtig krasser Schnitzer drin ist. Deswegen bitte nicht so den Fokus drauflegen. Aber wenn du es erkannt hast, dass es falsch war, dann bitte ansprechen. Und vor allem erzählen, was du daraus gelernt hast, wie du damit umgegangen bist.

[16:37] So, ansonsten, wenn du zum Beispiel einen Fehler gemacht hast bei irgendwas, was du in der Präsi gar nicht zeigen willst, auch nochmal ein Thema für eine andere Episode, die Präsi sind 15 Minuten, da kannst du nicht dein gesamtes Projekt zeigen. Es ist einfach viel zu kurz, das heißt, du hast weniger Möglichkeiten als in einer Doku. Jetzt mal nur ein Beispiel, du hast 10 Diagramme in einer Doku, in der Präsi kannst du aber nur 5 davon zeigen, weil die Zeit nicht reicht. Wenn du einen Fehler gemacht in einem der Diagramme, was du gar nicht zeigst, dann sollte es ein bisschen gesunder Menschenverstand sein, zu sagen, ich habe einen Fehler gemacht, den ich in der Präsi gar nicht zeige, dann brauche ich auch nicht darauf eingehen. Also du musst dich ja nicht selber schlechter machen, als du bist. Du musst ja deine Präsi nicht anfangen mit, ich habe übrigens hier und da und dort noch sieben Fehler gemacht, da gehe ich zwar heute gar nicht darauf ein, weil diese Artefakte interessieren hier in der Präsi niemanden, aber ich erzähle es euch trotzdem, dass ich Fehler gemacht habe. So, das ist natürlich Quatsch. Aber wenn du zum Beispiel, weiß ich nicht, in einem Verteilungsdiagramm einen Fehler in der Doku hattest und zeigst das Verteilungsdiagramm auch in der Präsentation, dann wäre es natürlich sinnvoll, dieses Diagramm zu korrigieren und kurz zu sagen, hey, in der Doku hatte ich das auch, da ist mir aber ein kleiner Fehler unterlaufen, so habe ich das korrigiert. So, das reicht ja schon. Du musst nicht stundenlang dich selber geißeln, sagen, oh Gott, ich habe es falsch gemacht, sondern es ist sehr wichtiger, wie gehst du damit um? Wie gesagt, immer der Blick auf die Zukunft. Was habe ich gemacht, damit es nicht normal vorkommt? Wie habe ich den Fehler korrigiert? Was ist das für eine Konsequenz für das Projekt gewesen? Das ist das, was wir da sehen wollen. Und dann kannst du sogar.

[17:55] Auch mit gemachten Fehlern trotzdem noch mit einem sehr gut aus der Präse oder dem Fachgespräch gehen. Weil das zeigt ja dann eine Professionalität, ich wiederhole mich glaube ich jetzt zum x-ten Mal, wie du mit den Fehlern umgegangen bist. Weil wir können Fehler nicht verhindern, selbst mit dem besten Entwicklungs- und ich weiß nicht was Prozess, können Fehler auftreten. Wir sind halt Menschen, wir sind keine Maschinen und selbst die können Fehler machen, wenn sie falsch programmiert sind. Also viel wichtiger, geh vernünftig mit dem Fehler um, anstatt den irgendwie an den Tisch fallen zu lassen oder noch besser zu leugnen, dass du ihm gedacht hast, nein, das stimmt ja nicht, nein, wo haben sie das denn gelesen? Nicht in meiner Doku. Habe ich auch schon gehabt. Tatsächlich in einer Präsentation, bis wir uns im Fachgespräch danach. Hä? Das weiß ich gar nicht mehr. Steht das so in meiner Doku wirklich? So nach dem Motto, wollen Sie mich gerade verarschen? Und also das geht überhaupt gar nicht. Also wenn du Fehler machst, dann steh dazu und erklär, was du daraus gelernt hast und wie du sie korrigiert hast. Das ist es. Und wenn die Inhalte aber nicht in einer Präsentation vorkommen, wie gesagt, Verteilungsdiagramm zeigst du gar nicht, dann sprich es auch nicht an.

[18:52] Aber bereite dich auf das Fachgespräch vor mit diesem Fehler. Denn natürlich haben mindestens zwei, würde ich mal behaupten, Prüfende deine Doku gelesen und vielleicht diesen Fehler gefunden. Und das vielleicht machen wir mal zu sehr wahrscheinlich haben sie diesen Fehler gefunden, weil das ist ja die Aufgabe der Prüfenden, deine Arbeit zu kontrollieren. Dann werden sie wahrscheinlich solche Fehler finden. Und dann werden sie dich vielleicht auch im Fachgespräch darauf ansprechen. Auch hier wieder, das ist alles vielleicht, vielleicht, vielleicht, weil das Fachgespräch sind ja auch nur 15 Minuten und da wollen wir auch noch viele andere Sachen fragen und nicht nur auf deinen Fehlern rum. Also wenn es jetzt ein krasser Schnitzer ist und ich habe den als Prüfender gefunden, dann spreche ich dich darauf an. Aber eventuell auch nicht, weil ich habe noch tausend andere Themen, die ich mit dir besprechen will in 15 Minuten und dann interessiert mich der Fehler gar nicht. Aber vorbereiten darauf kannst du dich trotzdem, weil wenn man dich dann anspricht, so hier, haben Sie ja nicht gesehen, in Ihrem Verteilungsdiagramm, da fehlt ja noch hier der Server und das passt ja so gar nicht. Dann kannst du sagen, oh ja, das ist richtig, das habe ich auch gesehen. Inzwischen ist es auch korrigiert und das hat folgende Konsequenz, bla bla bla.

[19:49] Und dann ist die Sache fein. Und dann kann man den eventuellen Fehler in der Doku dafür abziehen, dass du diesen, also kann man dir einen Punkt in der Doku dafür abziehen, dass du diesen Fehler gemacht hast. Aber im Fachgespräch kriegst du sogar einen Pluspunkt dafür, weil du dich darum bemüht hast, das zu korrigieren, das erkannt hast. Und das spricht ja auch für irgendeine Form von Qualitätssicherung, dass es im Nachhinein zumindest nochmal aufgefallen ist, dass der Fehler da war und dass du ihn auch korrigiert hast und so weiter.

[20:13] Also, ja, jetzt sind wir doch bei 20 Minuten gelandet. Ich wollte auf jeden Fall sagen, wenn du Fehler gemacht hast, steh dazu, Du sprichst sie gegebenenfalls sogar an, geh aktiv damit um, zeig, dass du professionell mit solchen Fehlern umgehen kannst, dass du was daraus gelernt hast, dass du irgendetwas tust, damit das in Zukunft nicht nochmal passiert. Das wäre vielleicht das Wichtigste, Learning, dass du das einmal zeigst. Aber du musst dich nicht auf deine Fehler fokussieren. Du musst nicht sagen, oh, das und das und das war alles falsch. Vor allem nicht beinhalten, die du eh nicht in der Präsentation hast. Aber bereite dich auf mögliche Fragen im Fachgespräch dazu vor. Das wäre auf jeden Fall sinnvoll. Also, ich hoffe, das hat dir jetzt ein bisschen geholfen. Wenn dir Fehler auffallen, dreh nicht durch. Auch im Nachhinein. Ich habe es schon eingangs gesagt, Dokus gehabt, wo direkt auf der Titelseite der Dokumentation Rechtschreibfehler war. Ja nun, das kann halt passieren. Das erkennt man meistens erst, nachdem man auf Absenden gedrückt hat und die Doku unwiderruflich hochgeladen wurde. Das ist manchmal so. Also mach dich nicht verrückt wegen solcher kleinen Fehler oder auch selbst wegen größerer Fehler, wenn du irgendwo zwei Stunden eine Zeitplanung vergessen hast. Deswegen fällst du nicht durch die Prüfung, deswegen kriegst du keine vier, sondern es ist immer ein großes Gesamtkunstwerk, dieses Projekt. Und da kann links und rechts mal ein kleines Fehlerchen auftreten, das ist überhaupt kein Problem. Trotzdem kannst du noch eine gute oder sehr gute Note bekommen. Für solche Sachen dreht dir da keiner den Hals um.

[21:33] Man dreht dir aber den Hals um, wenn du die Sachen ignorierst, wenn du sie bewusst leugnest, dass es den Fehler gibt oder so etwas. Das ist absolut unprofessionelles Verhalten. Überleg mal, das würdest du im Alltag auch nicht machen, wenn dein Chef zu dir kommt und sagt, sie haben hier aber was falsch gemacht. Nein, Chef, auf gar keinen Fall. Und es war jemand anders.

[21:51] Also wie lange willst du dann da noch arbeiten? Kannst du dir überlegen. Wenn du Fehler machst, steh dazu, überleg dir, wie du damit umgehst, wie du es in Zukunft verhinderst. Vielleicht kennst du den Spruch, ich weiß nicht, ist angeblich so ein Urban Myth, Ich glaube von so einem IBM-Manager, der irgendwie mal so einen Mitarbeitenden zu sich gerufen hat und gesagt hat, hier, was haben Sie denn da für einen Fehler gemacht? Das hat 100.000 Euro gekostet oder Dollar oder was auch immer. Und dann hat der Mitarbeiter schon befürchtet, oh Gott, der schmeißt mich raus und Hilfe. Und der Chef schmeißt ihn aber nicht raus. Und dann fragt er, wieso wäre ich denn jetzt nicht rausgeschmissen? Ja, weil ich gerade 100.000 Dollar in ihre Fortbildung investiert habe. So ganz blöd gesagt. Also wenn du aus den Fehlern lernst, dann ist das doch fürs Unternehmen am Ende gut, weil ganz sicher, vorausgesetzt du lernst wirklich daraus, wirst du diesen Fehler ja nicht nochmal machen. Jemand anders, der den Fehler aber nicht gemacht hat, der kann ihn vielleicht wiederholen und deswegen ist das tatsächlich auch eine Investition in dich als Mitarbeitenden, wenn man dir die Fehler verwendet.

[22:48] Wie soll ich das sagen? Durchgehen lässt sich blöd an. Natürlich wollen wir keine Fehler machen. Niemand ist daran interessiert, dass alle Mitarbeiter möglichst viele Fehler machen. Das ist ja Quatsch. Aber wenn mal ein Fehler passiert, dann sollte man daraus lernen und dann sollte das Unternehmen daraus lernen, wie man sowas in Zukunft verhindern kann. Das ist professionelles Vorgehen und Fehler zu leugnen und zu sagen, ich war es gar nicht oder das ist aber nicht meine Schuld, das bringt niemanden weiter und stellt dich auch in ein ganz schlechtes Licht und ja, das wollen wir auch, wir wollen ja die Prüfung möglichst realitätsnah haben und in der Realität wollen wir solche Mitarbeitenden auch nicht haben, also fang nicht an, irgendwas zu leugnen oder zu widersprechen oder ja, das kommt gar nicht gut an, weder in der Realität noch in der Prüfung. Steh dazu, lehren daraus, mach es beim nächsten Mal besser. Das ist die Kernaussage. So, ich glaube, jetzt habe ich alles. Ich hoffe, du hast meine Einstellung dazu verstanden. Und ja, wenn du anderer Meinung bist, schreib mir gerne einen Kommentar oder vielleicht hast du sogar Beispiele, wo du selber einen Fehler zugegeben hast und wo es positiv ausgegangen ist. Ganz besonders freuen würde ich mich natürlich auch über Gegenbeispiele. So, hey, ich habe einen Fehler zugegeben. Am Ende haben sie gesagt, du bist durchgefallen, wenn du einen Fehler gemacht hast. Das fände ich absolut realitätsfähig in der Prüfung. Aber bei 79 IHK mit jeweils x verschiedenen Prüfungsausschüssen kann das deutschlandweit natürlich auch noch ein bisschen anders gehandhabt werden. Also das hier ist jetzt meine Meinung für einen professionellen Umgang mit Fehlern. Wenn du andere Erfahrungen gemacht hast oder Geschichten gehört hast, kommentiere gerne unter der Episode, das würde mich sehr interessieren natürlich.

[24:10] Ansonsten hoffe ich, dass es heute ein bisschen geholfen hat. Ich wünsche dir viel Erfolg für deine Projektpräsentation und das Fachgespräch und falls du noch nicht abgegeben hast, auch die Doku. Und da nochmal, der beste Fehler ist der, den du gar nicht machst. Das heißt, wenn du vor Abgabe der Doku nochmal jedem mal über die Doku drüber gucken lässt, zum Beispiel Ausbilder, Ausbilderin oder im Jahr 2026 vielleicht auch die KI, die dann sowas wie Kommasetzungsfehler oder Rechtschreibung zumindest glatt ziehen würde, das wäre auf jeden Fall auch empfehlenswert.

[24:36] Denn wenn du einen Fehler gar nicht zugeben musst, weil du ihn nicht gemacht hast, ist das natürlich das Optimum. So, jetzt haben wir es aber auch. Vielen Dank fürs Zuhören und bis zum nächsten Mal.

Um eine sinnvolle Prüfungsvorbereitung mit alten IHK-Prüfungen geht es in der elften Episode der Shorts des IT-Berufe-Podcasts.

Ich empfehle dir, für die schriftliche Abschlussprüfung mit alten Prüfungen zu lernen und dabei mit den neuesten anzufangen. Wichtig ist aber, dass du immer den aktuell gültigen Prüfungskatalog prüfst, weil sich Inhalte durch Neuordnungen und Anpassungen verschieben oder wegfallen können. Für WiSo sind auch sehr alte Prüfungen sinnvoll, bei AP1 und AP2 musst du genauer schauen, welche alten Prüfungen thematisch noch zu deinem Prüfungsteil passen und dir idealerweise zusätzlich Feedback von deinem/deiner Ausbilder:in holen.

Inhalt

Alte Prüfungen sind grundsätzlich sinnvoll

Ich halte es für sehr sinnvoll, dich mit alten Prüfungen auf die schriftliche Abschlussprüfung vorzubereiten. Das gilt sowohl für AP1 als auch für AP2. Am besten startest du aber immer mit den neuesten Prüfungen und arbeitest dich dann chronologisch rückwärts vor. Je aktueller eine Prüfung ist, desto höher ist die Wahrscheinlichkeit, dass sie noch gut zu den heutigen Anforderungen passt.

Wichtig ist dabei eine Einschränkung: Du solltest alte Prüfungen nie blind durcharbeiten, sondern immer mit dem aktuell gültigen Prüfungskatalog abgleichen. Inhalte können sich durch die Neuordnung der IT-Berufe oder durch Änderungen am Prüfungskatalog verschieben, neu dazukommen oder wegfallen.

Was sich seit der Neuordnung verändert hat

Vor der Neuordnung 2020 gab es:

• eine Zwischenprüfung
• eine Abschlussprüfung mit:
  • GA1
  • GA2
  • WiSo

Alte Zwischenprüfung

Die frühere Zwischenprüfung ist mit den heutigen Prüfungen praktisch nicht mehr vergleichbar. Sie bestand stark aus Multiple Choice und behandelte allgemeine IT-Themen für alle IT-Berufe. Dieser Prüfungsteil wurde ersatzlos gestrichen. Deshalb ist er für deine Vorbereitung heute nicht mehr relevant.

WiSo

Beim WiSo-Teil hat sich im Grunde nichts Wesentliches verändert. Die Themen und die Art der Fragen sind seit vielen Jahren ähnlich geblieben. Es geht dort um allgemeine wirtschaftliche und soziale Inhalte wie:

• Wirtschaft, Rentabilität
• Märkte, Angebot und Nachfrage
• Arbeitsverträge
• Gewerkschaften, Streik, Betriebsrat

Deshalb kannst du für WiSo auch sehr alte Prüfungen verwenden, sogar viele Jahre zurück. Als Untergrenze empfehle ich mindestens die letzten fünf Jahre, also bei zwei Terminen pro Jahr etwa zehn Prüfungen.

Wie alte und neue Prüfungsteile zusammenhängen

Für die fachlichen Teile gibt es grobe Entsprechungen zwischen alt und neu:

• alte GA1 entspricht am ehesten der heutigen AP2
• alte GA2 entspricht am ehesten der heutigen AP1

Der Hintergrund:

• Die GA1 war berufsspezifisch, ähnlich wie die heutige AP2.
• Die GA2 war für alle IT-Berufe gleich und damit eher mit der heutigen AP1 vergleichbar.

Warum du immer den aktuellen Prüfungskatalog brauchst

Es gab nicht nur 2020 eine große Neuordnung, sondern auch weitere Änderungen:

• 2018: kleinere Reform mit Datenschutz und Datensicherheit in der Prüfung
• 2020: große Überarbeitung der IT-Berufe
• 2025: Anpassung der Prüfungskataloge

Dadurch kann es passieren, dass alte Prüfungen Themen enthalten, die heute nicht mehr geprüft werden, oder umgekehrt, dass heute Themen relevant sind, die in älteren Prüfungen noch gar nicht vorkamen.

Ein Beispiel dafür ist SQL:

• In der AP1 wurde SQL mit dem neuen Prüfungskatalog gestrichen.
• In der AP2 ist SQL heute relevant.
• Deshalb kann es sein, dass du für bestimmte Berufe oder Prüfungsteile passende SQL-Aufgaben nicht direkt in alten AP2-Prüfungen findest, sondern eher in älteren AP1-Prüfungen oder in AP2-Prüfungen anderer IT-Berufe, zum Beispiel der Anwendungsentwicklung.

Ein weiteres Beispiel ist RAID, das in der AP1 ebenfalls nicht mehr relevant ist, aber in älteren Prüfungen noch häufig vorkommt.

So gehst du bei alten Prüfungen sinnvoll vor

Ich empfehle dir dieses Vorgehen:

1. Prüfungskatalog besorgen

   • Dort steht, welche Themen aktuell für AP1 oder AP2 in deinem Beruf relevant sind.

2. Mit den neuesten Prüfungen anfangen

   • Zuerst den Prüfungsteil bearbeiten, auf den du dich konkret vorbereitest.

3. Dann chronologisch rückwärts arbeiten

   • So lange, bis du bei den Prüfungen ab 2020 angekommen bist.

4. Danach Prüfungstrainer nutzen

   • Zum Beispiel die Prüfungstrainer aus dem U-Form-Verlag mit prüfungsnahen Aufgaben und Lösungen.

5. Erst danach sehr alte Prüfungen ergänzend anschauen

   • Für AP2 eher alte GA1
   • Für AP1 eher alte GA2

Wichtig ist dabei immer: Wenn ein Thema heute neu in einem Prüfungsteil ist, kannst du auch in anderen alten Prüfungen nach passenden Aufgaben suchen, selbst wenn sie ursprünglich für einen anderen Prüfungsteil oder einen anderen IT-Beruf gedacht waren.

Lass dich von alten Aufgaben nicht verunsichern

Wenn du in älteren oder auch noch relativ neuen Prüfungen Aufgaben zu Themen findest, die laut aktuellem Prüfungskatalog nicht mehr drankommen sollen, ist das kein Widerspruch. Der Grund ist einfach, dass diese Prüfungen noch auf älteren Regelungen basieren.

Deshalb gilt:

• Nicht jede alte Aufgabe ist heute noch relevant.
• Nicht jedes heute relevante Thema ist in alten Prüfungen sofort leicht zu finden.
• Maßgeblich ist immer der aktuelle Prüfungskatalog.

Wenn dort ein Thema nicht mehr enthalten ist, musst du es bei knapper Zeit nicht gezielt für diesen Prüfungsteil lernen. Es ist natürlich trotzdem nicht falsch, solche Inhalte grundsätzlich zu können.

Lösungen nie nur stumpf vergleichen

Wenn du mit alten Prüfungen lernst, solltest du deine Antworten nicht nur mit den Lösungshinweisen vergleichen. Dabei gilt:

• Es gibt meist keine echten Musterlösungen, sondern nur Lösungsvorschläge oder Lösungshinweise.
• Gerade bei offenen Aufgaben kann es mehrere richtige Wege geben.
• Das betrifft zum Beispiel:
  • Datenbankmodellierung
  • Pseudocode
  • andere Aufgaben mit Transferleistung

Deshalb musst du nicht verzweifeln, wenn deine Lösung anders aussieht als auf dem Lösungbogen. AP1 und AP2 werden von Menschen korrigiert, die dabei einen Bewertungsspielraum haben.

Feedback ist ein wichtiger Teil der Vorbereitung

Ich finde es sinnvoll, alte Prüfungen gemeinsam mit deinem/deiner Ausbilder:in oder einer anderen fachkundigen Person durchzusprechen. So kannst du besser einschätzen:

• ob deine Lösung trotzdem Punkte bekommen würde
• wo deine Denkfehler liegen
• ob eine alternative Lösung fachlich in Ordnung ist

Besonders hilfreich ist das bei offenen Aufgaben, bei denen nicht nur eine einzige Formulierung korrekt sein kann. Im Ausbildungsalltag mit meinen eigenen Azubis wird etwa jeden Monat eine alte Prüfung bearbeitet und danach mit einem/einer Ausbildungsbeauftragten besprochen.

Fazit

Ja, du kannst auch mit ganz alten Prüfungen lernen. Ich würde aber nicht damit anfangen. Mein Vorschlag ist:

• zuerst die neuesten Prüfungen
• dann passende Prüfungstrainer
• danach bei Bedarf ältere Prüfungen
• und sehr alte Prüfungen nur ergänzend und gezielt

Für WiSo sind auch sehr alte Prüfungen gut nutzbar. Für AP1 und AP2 musst du dagegen genauer prüfen, welche Aufgaben heute noch zu deinem Prüfungskatalog passen. Alte Prüfungen sind ein wichtiger Bestandteil der Vorbereitung, am sinnvollsten zusammen mit Feedback und ergänzt durch eigenes Lesen, Umsetzen, Programmieren oder Administrieren.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Vorbereitung auf die schriftliche Abschlussprüfung
• Fachinformatiker Anwendungsentwicklung: Prüfungstrainer Abschlussprüfung Teil 2
• Fachinformatiker Systemintegration: Prüfungstrainer Abschlussprüfung Teil 2

Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode

[0:20] Heute geht es um ein Thema, was regelmäßig inzwischen viermal im Jahr immer wieder angefragt wird. Und zwar, wie bereite ich mich am besten auf die schriftliche Abschlussprüfung vor? Warum viermal im Jahr? Naja, es gibt vier Termine im Jahr. Es gibt zweimal die AP1 im Frühjahr und im Herbst und zweimal die AP2 im Sommer und im Winter. Und immer sind die Fragen dieselben. Wie bereite ich mich darauf vor? Was kommt dran? Etc. Ich habe, glaube ich, als allererste Folge oder eine meiner allerersten Folgen in diesem Podcast schon Tipps zur Prüfungsverwaltung gegeben und habe ich vor kurzem auch nochmal aktualisiert. Aber heute geht es um eine ganz spezielle Frage in diesem Zusammenhang. Und zwar kann, soll, muss ich auch mit älteren Prüfungen mich vorbereiten? Oder soll ich nur die neuesten Prüfungen durchgehen? Und ja, da möchte ich auch mal drauf eingehen. Kurz vorweg schon mal, guck dir am besten so viele alte Prüfungen wie möglich an. Das kann auf jeden Fall nicht schaden. Aber mit einer kleinen Einschränkung bedenke immer, was der aktuelle Umfang an Themen für deine konkrete Prüfung ist, die gerade vor dir steht, weil der kann sich ändern.

[1:23] So, und jetzt tun wir mal ein bisschen weiter aus. Vor der Neuordnung der IT-Berufe 2020 gab es eine Zwischenprüfung und eine schriftliche Abschlussprüfung. Die Zwischenprüfung, das sage ich schon mal gleich vorweg, die kannst du eigentlich mit keiner der heutigen Prüfungen mehr vergleichen. Das war ganz viel Multiple Choice und einmal rundum um alle möglichen IT-Sachen für alle Berufe, auch gleich für alle IT-Berufe. Und der Prüfungsteil ist tatsächlich einfach ersatzlos gestrichen und den brauchst du dir tatsächlich auch nicht mehr angucken. Das kannst du ad acta legen, das interessiert keinen Menschen mehr.

[1:53] Aber dann gab es noch die eigentliche Abschlussprüfung früher, war ja nicht aufgeteilt in 1 und 2, sondern eben die Zwischenprüfung und dann kam die Abschlussprüfung und da gab es zwei Teile. Einmal die sogenannten ganzheitlichen Aufgaben 1 und ganzheitliche Aufgaben 2, GA1 und GA2 oder GH1, GH2 abgekürzt. Und den Visoteil. Und den Visoteil, den Spoiler ich schon mal, der ist, da kannst du dir eigentlich alle Prüfungen auch von vor 20 Jahren angucken, weil die Themen sind halt im Großen und Ganzen gleich geblieben. Die Fragestellung ist gleich geblieben. Es ist Multiple Choice, genau wie früher. Es wird mal schnell ausgewertet. Also an der Prüfung hat sich eigentlich überhaupt gar nichts verändert. Und die ist ja noch nicht mal nur für die IT-Berufe gleich, sondern so ziemlich für alle anderen Berufe auch gleich. Es sind halt ganz allgemeine Fragestellungen zur Wirtschaft, zu Märkten, zu, weiß ich nicht, Arbeitsverträgen und einfach Wirtschaft und Soziales. Es hat halt eigentlich nichts mit IT zu tun. Das heißt, wenn du die Prüfung dir angucken willst, auch die letzten 20 Jahre rückwärts, mach das, super Idee. Ansonsten sage ich ja, mindestens die letzten 5 Jahre angucken und da hast du, weil es ja aktuell 2 Prüfungstermine pro Jahr gibt, schon mal 10 Prüfungen, auf jeden Fall locker und hast damit einen Großteil der Fragen, die dir gestellt werden, in deiner Visu-Prüfung wahrscheinlich abgedeckt. Also das ist das Ding, wo du am einfachsten für lernen kannst mit alten Prüfungen, würde ich sagen. So, und dann gab es aber noch die GA1 und GA2.

[3:13] Und damals war es halt auch schon so, dass wir einen Teil in der Prüfung hatten, der für alle IT-Berufe gleich war. Das war in diesem Fall die GA2. Und dann gab es den Teil, der für den jeweiligen Beruf fachspezifisch war, also Anbietungsentwicklung, Systemintegration, etc. Und das war die GA1. Und jetzt kann man am ehesten vergleichen die alte GA1 mit dem, was wir heute in der AP2 schreiben. Weil das ist ja rein fachspezifisch. Die AP2 ist komplett unterschiedlich für jeden IT-Beruf. Das ist das, was früher die GA1 war. Und die alte GA2 ist am ehesten vergleichbar mit dem, was wir heute in der AP1 schreiben. Also Inhalte für alle IT-Berufe gleich, eher oberflächlich, eher in die Breite.

[3:54] So, und jetzt kannst du dir natürlich vorstellen, wenn es diese alten Prüfungen gibt, vielleicht kann man die ja noch zum Lernen benutzen. Und ich würde sagen, ja klar, kannst du die dafür benutzen. Trotzdem würde ich natürlich empfehlen, mit den neuesten Prüfungen anzufangen. Ist ja klar, du machst eine neue Ausbildung im Jahr, weiß nicht, 2026, 2027, schreibst du die Prüfung. Da ist es vielleicht nicht sinnvoll, sich Prüfungen von 1997 anzugucken. Da hat sich inzwischen natürlich auch sehr viel geändert. Aber es ist ja nun mal so, in der IT gibt es mal eine Neuordnung. Die letzte war 2020. Davor tatsächlich, hat kaum jemand mitbekommen, aber 2018 gab es auch eine kleine Reform der IT-Berufe. Da wurde nämlich zum Beispiel Datenschutz und Datensicherheit mit in die Prüfung aufgenommen, was vorher gar nicht explizit drin war. So, das heißt, wir hatten 2018 eine kleine Anpassung, 2020 die große Überarbeitung der IT-Berufe. Und jetzt gibt es aber auch noch sowas wie die Anpassung der Prüfungskataloge. Und das hat jetzt 2025 zuletzt stattgefunden. Das heißt, da wurde nicht der Beruf überarbeitet, sondern nur die Liste der Themen, die in der Prüfung drankommen können. Sowas kann ja auch passieren. So, und jetzt haben wir halt folgende Situation. Egal, welche alte Prüfung du dir anguckst, es kann sein, dass sie nicht mehr zu dem passt, was du in deiner Prüfung abgefragt werden kannst, weil sich entweder der Beruf oder der Prüfungskatalog oder was auch immer sonst noch geändert hat. Das heißt, grundsätzlich musst du bei alten Prüfungen eh immer gucken, ist das für mich noch relevant und ist das für diese Prüfung, auf die ich mich gerade vorbereite, relevant. Du kannst dir auch alte AP1en angucken. Hilft dir nicht so viel, wenn du dich gerade auf die AP2 vorbereitest.

[5:20] Außer du nimmst eine AP1, in der noch SQL drin war, weil das wurde jetzt gestrichen mit dem neuen Prüfungskatalog 2055, ist aber heute auf jeden Fall in der AP2 überall drin. Das heißt, wenn du dir jetzt alte AP2en zum Beispiel anguckst als FISI, Hast du da vielleicht gar keinen SQL drin? Inzwischen ist das aber notwendig. Es gibt nur leider keine alte Prüfung, wo es drin ist, weil das ist ja erst seit einem Jahr so. Verstehst du das Problem? Ich hoffe, ja. Das heißt, du kannst dir anhand der alten Prüfung auf jeden Fall zu den jeweiligen Themen, die drankommen können, Beispielaufgaben angucken. Und das ist auch absolut sinnvoll, die durchzugehen. Und wenn du jetzt halt merkst, oh, als Fisi muss ich eigentlich SQL können, ja, dann suche ich mir doch alte Prüfungen raus, wo SQL-Aufgaben drin sind. Und das kann dann eine alte AP1 sein, das kann eine AP2 für Anwendungsentwickler sein, weil da war schon immer SQL drin. Also, es kommt halt ganz drauf an, auf welche Prüfung bereitest du dich vor und dann musst du dazu die passenden Prüfungen da anschauen.

[6:11] Ein Riesenthema für alle IT-Berufe gleich ist ja die AP1. Da hat sich jetzt durch einen neuen Prüfungskatalog einiges geändert. Da ist zum Beispiel SQL halt rausgeflogen und RAID zum Beispiel sind so zwei Sachen, die mir auswendig immer einfallen. Wenn du dich jetzt auf die AP1 aktuell vorbereitest, kannst du die beiden Themen streichen, wirst aber in den alten Prüfungen sehr viele Aufgaben dazu finden, weil das früher halt drin war. Und da kommt natürlich auch eine gewisse Unsicherheit. So, hä, im Prüfungskatalog steht es nicht drin, in den alten Prüfungen ist es aber. Ja, weil die halt auf einem alten Prüfungskatalog basierten. Und jetzt kann man natürlich im Internet sich tausend Gerüchte und Diskussionen anschauen. Kann SQL vielleicht doch wieder in der API 1 drankommen? Ja, potenziell ja. Ich habe keine Glaskugel, ich kann es nicht sagen. Aber wenn im offiziellen Prüfungskanalog steht, SQL ist raus.

[6:52] Dann musst du dich erstmal nicht darauf vorbereiten unter der Voraussetzung, dass du nicht genug Zeit hast, um das alles zu lernen. Ist es schlimm, wenn du SQL kannst? Nee, im Gegenteil. Ich finde es super, wenn jeder IT-Lehrerin SQL kann. Und dann ist mir auch egal, ob es zur AP1 oder AP2. Aber wenn du wenig Zeit hast und dich gezielt vorbereiten willst, dann brauchst du dich auf jeden Fall für die AP1 nicht mehr auf SQL vorbereiten. So, und das ist jetzt nur ein Thema. Das kann sich ja nächstes Jahr auch wieder verschieben. Vielleicht gibt es da noch einen neuen Prüfungstilolog. Und es gibt halt auch noch andere Themen außer SQL, die verschoben wurden.

[7:20] Und das will ich eigentlich damit sagen. Du musst einfach schauen, was ist für dich, für deine Prüfung relevant. Und dazu guckst du in den aktuell gültigen Prüfungskatalog. Den kannst du dir für 7,10 Euro, kostet der, glaube ich, beim U-Vorm Verlag kaufen oder von deinem Ausbildungsunternehmen kaufen lassen. Die haben den auch hoffentlich schon, wenn sie ein vernünftiger Ausbildungsbetrieb sind. Und da guckst du rein. Und da steht dann für AP1 musst du lernen, zack, zack, zack, zack. Und für deine AP2 in deinem Beruf musst du lernen, zack, zack, zack, zack. Das ist das, worauf du dich vorbereiten musst. Und dann gehst du alte Prüfungen durch, chronologisch rückwärts, fängst mit den neuesten an, weil da die Chance am größten ist, dass sie schon zu diesem Prüfungskatalog passen. Aber irgendwann wirst du feststellen, spätestens im Jahr 2024 sind Aufgaben drin, die es heute entweder nicht mehr gibt oder die es auf jeden Fall noch mehr geben wird, weil sich halt Themen vielleicht hin und her geschoben haben zwischen den Prüfungsteilen. Und wenn du jetzt alte Aufgaben brauchst für ein Thema, was jetzt neu in der AP2 zum Beispiel gekommen ist, kannst du in alte AP1 gucken oder sogar noch weiter zurück in alte GA2, wenn du für die AP1 lernst zum Beispiel. Also grundsätzlich finde ich es gut, mit allen alten Prüfungen zu lernen, aber es macht natürlich Sinn, mit den neuesten anzufangen. Das ist ja ganz klar.

[8:26] Also lass dich nicht verunsichern, wenn du dann in diesen neueren Prüfungen Aufgaben siehst zu Themen, die eigentlich gar nicht mehr drankommen sollen. Du weißt ja jetzt, woran es liegt. Die Prüfungen. Berufe, aber alle Berufe, nicht nur die Berufe, sind nicht starr. Da wird mal was überarbeitet, da wird mal was hin und her geschoben, was ja auch sinnvoll ist, finde ich. Nur bei den alten Prüfungen wird man dann halt als Prüfling, wenn man sich nicht damit auseinandersetzt, vielleicht ein bisschen verwirrt.

[8:48] Also meine Strategie, fang mit der letzten Prüfung für den Teil, für den du dich vorbereitest, AP1, AP2 an, und gehe dann rückwärts immer weiter zurück, bis du keine Prüfung mehr hast. Und das wird dann im Jahr 2020 sein. dann kannst du gerne zu den alten GA1 oder GA2 wechseln. Irgendwann wird es natürlich dann thematisch nicht mehr ganz so relevant, weil es dann immer mal zehn Jahre her ist. Dafür gibt es dann aber noch als Ergänzung die Prüfungstrainer aus dem U-Form Verlag. Vielleicht kennst du die. Das sind so DIN A4 Büchlein, wo halt auch nochmal, ich glaube, zehn IHK-Prüfungen drin sind. Also prüfungsnahe Aufgaben. Sind keine offiziellen Prüfungen, aber Aufgabenstellungen, die sehr, sehr ähnlich sind. Und natürlich gibt es dazu die entsprechenden Lösungen auch. Und die guckst du dir dann auch noch an. Und dann hast du, also ich nehme es jetzt 2026 hier auf, die Neuordnung war 2020. Das sind dann schon mindestens 10, 11 neue Prüfungen, zumindest nach der Neuordnung, die du machen kannst. Mindestens ein, zwei auch schon nach dem neuen Prüfungskatalog, die du machen kannst. Und wenn dir das dann immer noch nicht reicht, dann guckst du dir halt die alten Prüfungen an. Aber sogar vorher noch würde ich mir die Prüfungstrainer anschauen, weil die sind natürlich auch auf dem neuesten Stand. Also chronologisch rückwärts die letzten Prüfungen, dann die Prüfungstrainer. Und wenn du dann immer noch Zeit über hast, dann guckst du die in Anführungszeichen Uraltprüfungen von früher an und dann wäre die GA1 für die AP2 relevant und die GA2 für die AP1. Also die Zahlen genau umgedreht, wie es früher mal war.

[10:12] So, und wenn du jetzt mit den Prüfungen lernst, wäre es natürlich auch sinnvoll, dass du da auch irgendwie dir ein Feedback zu einholst. Du kannst natürlich in die Musterlösungen gucken, wobei Musterlösungen gibt es da ja nicht. Das sind immer nur Lösungsvorschläge oder Lösungshinweise.

[10:25] Deswegen verzweifle da nicht, wenn du es nicht exakt so formulierst oder exakt so zeichnest, wie es in der Lösung steht. Das sind immer nur Hinweise. Und zumindest die AP1 und AP2 wird von Menschen korrigiert, die da auch einen gewissen Entscheidungsrahmen haben, ob sie da Punkte vergeben oder nicht. Und deswegen würde ich dir den Tipp geben, das immer mit deiner Ausbilderin, mit deinem Ausbilder auch durchzusprechen, was du da an Lösungen hast. Wenn du natürlich die perfekte Muskellösung hingeschrieben hast, super.

[10:52] Aber wenn du Abweichung hast, und das passiert ganz schnell mal, wenn du was modellieren musst, eine Datenbank zum Beispiel, oder wenn du Pseudocode-Aufgaben hast oder so, wo man auch ein bisschen Transferleistung hat, da kriegt man vielleicht nicht die hundertprozentige Musterlösung hin oder hat einfach eine andere Idee, das Problem zu lösen. Stichwort Pseudocode. Gibt es gefühlt 700 verschiedene Wege, irgendwas zu programmieren. Und da ist vielleicht das Feedback von einem anderen Menschen, im besten Fall von jemandem, der sich auskennt, also Ausbilder, Ausbilderin vielleicht, ganz hilfreich, damit du nicht nur in deinem stillen Kämmerlein da irgendwie was lernst und dich ärgerst, wenn du nicht so dicht an der Musterlösung bist. Also, nur mal ein Beispiel, wie ich das oder wie wir das bei uns im Unternehmen mit unseren Azubis machen. Die sollen im Durchschnitt jeden Monat eine alte Prüfung durchgehen und sie dann aber auch nicht nur mit den Musterlösungen stumpf vergleichen, sondern es gibt dann immer auch einen Termin mit einem Ausbildungsbeauftragten bei uns, der das dann mit denen auch durchspricht. Und dann zum Beispiel bei so einer Frage, wie hätte ich hierfür noch einen Punkt gekriegt, auch eine Antwort geben kann. Das wäre natürlich super. Besonders toll wäre es natürlich, wenn diese Person auch Prüfender oder Prüfende ist. Dann kann ich es natürlich nochmal besser sagen, als jemand, der noch nie mit der Prüfung da zu tun hatte. Aber normalerweise sollte man es ja vielleicht ein bisschen einschätzen können, ob die Antwort da passen würde oder nicht.

[12:04] So, und dann wäre das auch mein Tipp, um sich mit alten Prüfungen vorzubereiten. Also Antwort auf die Frage, kannst du mit ganz alten Prüfungen lernen? Ja, wäre nicht mein präferierter Weg. Ich würde das miteinander anfangen, klar, aber je mehr du dich vorbereitest, desto besser, vorausgesetzt du hast genug Zeit dafür und dann kannst du auch mit den älteren Prüfungen lernen, wie gerade schon beschrieben. So, das war meine, ja, nicht ganz so kurze Antwort zur Frage, soll ich auch mit alten Prüfungen lernen, aber ich habe es ein bisschen erklärt, damit du auch weißt, was da der Hintergrund ist. Ich hoffe, es hilft dir ein bisschen bei deiner Prüfungsvorbereitung. Ich drücke dir auf jeden Fall die Daumen, egal, ob du noch die AP1 oder AP2 vor dir hast. Das wird schon. Guck dir die alten Prüfungen an, ergänze das Ganze um Feedback mit deinem Ausbilder, deine Ausbilderin. Natürlich darfst du auch gerne mal ein Buch lesen und auch selber was umsetzen und programmieren und administrieren.

[12:50] Genau, aber die Prüfungen sind sicherlich ein ganz wichtiger Bestandteil, also die alten, um sich auf die neuen Prüfungen vorzubereiten. Jo, das war’s dazu. Ich drück die Daumen für deine Prüfung. Mach’s gut, bis zum nächsten Mal.

Um die sinnvolle Platzierung von Artefakten in der Projektdokumentation geht es in der zehnten Episode der Shorts des IT-Berufe-Podcasts.

Inhalt

Ich empfehle dir für die Projektdokumentation als klare Daumenregel, Artefakte wie Diagramme, Tabellen, Code, Screenshots oder Berechnungen in den Anhang zu packen – besonders dann, wenn sie größer als eine halbe Seite sind. Im Fließtext sollte stattdessen stehen, warum du ein Artefakt erstellt hast, wie es dir im Projekt geholfen hat und was du daraus abgeleitet hast. Nur kleine, direkt erklärungsbedürftige Artefakte können aus Gründen der Lesbarkeit ausnahmsweise in den Fließtext.

Was ich mit Artefakten meine

Mit Artefakten sind alle Bestandteile der Projektdokumentation gemeint, die kein eigentlicher Fließtext sind. Dazu zählen zum Beispiel:

• Diagramme wie UML-Diagramme oder ER-Modelle
• Tabellen, etwa für Kosten oder Zeitplanung
• Code
• Netzwerkpläne
• Testprotokolle
• Berechnungen und Formeln
• Screenshots und Fotos

Zentrale Daumenregel

Meine Empfehlung ist klar:

• Alle Artefakte gehören grundsätzlich in den Anhang.
• Alles, was größer als eine halbe Seite ist, sollte auf jeden Fall in den Anhang.

Nur wenige Ausnahmen sprechen dafür, ein Artefakt direkt im Fließtext zu platzieren.

Warum Artefakte besser in den Anhang gehören

Der wichtigste Grund ist die begrenzte Seitenzahl für den Fließtext. Viele IHKs machen dafür klare Vorgaben, zum Beispiel 15 Seiten Fließtext und 25 Seiten Anhang. Diese Vorgaben unterscheiden sich aber je nach IHK teilweise deutlich.

Wichtig ist deshalb:

• Prüfe immer die konkreten Vorgaben deiner IHK.
• Verlasse dich nicht pauschal auf Angaben aus dem Internet.

Wenn du Artefakte in den Fließtext einbaust, verbrauchen sie dort Platz. Dadurch bleibt weniger Raum für erklärenden Inhalt, der in der Bewertung oft entscheidend ist. Eine Seite Klassendiagramm im Fließtext ist dann eben keine Seite Fließtext mehr.

Seitenzahl ist nicht das eigentliche Problem

Entscheidend ist nicht, ob am Ende 14 oder 15 Seiten dort stehen. Entscheidend ist, ob wichtige Inhalte fehlen.

Wenn zum Beispiel in einem Projekt ein bestimmtes Artefakt sinnvoll oder zu erwarten ist, dann fehlt ohne dieses Artefakt möglicherweise ein relevanter Inhalt. Umgekehrt hilft es auch nicht, die maximale Seitenzahl auszuschöpfen, wenn dabei inhaltlich etwas Wichtiges fehlt.

Die Seitenzahl ist also nur ein Rahmen. Bewertet werden am Ende die Inhalte, nicht bloß die Zahl auf der letzten Seite.

Ausnahme: Lesbarkeit

Der wichtigste Grund, ein Artefakt doch im Fließtext zu platzieren, ist die Lesbarkeit.

Das kann sinnvoll sein, wenn:

• ein Artefakt sehr erklärungsbedürftig ist
• der zugehörige Text direkt daneben stehen sollte
• ständiges Blättern oder Springen zwischen Text und Anhang das Verständnis erschwert

Beispiele dafür können sein:

• eine kurze, erklärungsintensive Code-Stelle
• eine kleine Berechnung oder Formel
• eine kompakte Kostenberechnung
• eine grobe Zeitplanung
• eine Amortisationsrechnung

Dabei bleibt die zweite Daumenregel bestehen:

• Ist das Artefakt größer als eine halbe Seite, gehört es trotzdem in den Anhang.

Denn wenn Erklärung und Artefakt ohnehin nicht mehr gemeinsam auf eine Seite passen, geht der Vorteil für die Lesbarkeit wieder verloren.

Artefakte nicht als Seitenfüller verwenden

Artefakte sollten nicht dazu dienen, den Fließtext künstlich aufzublähen, wenn dir sonst Inhalt fehlt.

Wenn große oder unpassende Artefakte ohne echten Grund im Fließtext stehen, kann das bei der Bewertung als Hinweis gesehen werden, dass dort eigentlich zu wenig sinnvoller Textinhalt vorhanden ist. Solche Artefakte werden inhaltlich nicht als Ersatz für fehlende Erklärungen gewertet.

Wichtig dabei:

• Es gibt nicht automatisch Punktabzug wegen einer bestimmten Seitenzahl.
• Punktabzug entsteht dann, wenn dadurch erkennbare inhaltliche Lücken bleiben.

Artefakte haben einen Zweck

Eine Projektdokumentation sollte nicht aus einer bloßen Sammlung von Artefakten bestehen.

Nicht ausreichend ist zum Beispiel:

• Überschrift
• ein Satz wie "Ich habe ein UML-Diagramm erstellt, siehe Anhang"
• sonst keine weitere Erklärung

Artefakte haben keinen Selbstzweck. Sie sollen zeigen, dass du methodisch gearbeitet hast und dir vor der Umsetzung Gedanken gemacht hast.

Beispiele:

• In der Anwendungsentwicklung helfen Klassendiagramme, ER-Modelle oder Architekturskizzen dabei, die Struktur vor der Implementierung zu planen.
• In der Systemintegration helfen Netzwerkpläne oder Sicherheitsüberlegungen dabei, Anforderungen und Rahmenbedingungen sauber zu analysieren.

Artefakte sollen also nicht nur für die Prüfung da sein, sondern einen praktischen Nutzen im Projekt haben.

Was in den Fließtext gehört

Im Fließtext sollte stehen:

• warum du ein Artefakt erstellt hast
• wie du dabei vorgegangen bist
• welche Besonderheiten dir dabei aufgefallen sind
• wie dir das Artefakt im weiteren Verlauf geholfen hat
• was du darauf aufbauend später gemacht hast

Ein gutes Beispiel wäre nicht nur zu schreiben, dass ein Klassendiagramm existiert, sondern zu beschreiben:

• welche Klassen notwendig waren
• welche Beziehungen oder Abstraktionen sich ergeben haben
• welche Erkenntnisse daraus entstanden sind
• wie das Diagramm später bei der Implementierung geholfen hat

Das Artefakt selbst kommt dann in den Anhang, der Kontext und die Einordnung gehören in den Fließtext.

Fazit

Die Kernaussage ist:

• Artefakte in den Anhang
• Erklärungen, Einordnung und Nutzen in den Fließtext

Ausnahmen im Fließtext sind nur dann sinnvoll, wenn kleine Artefakte direkt zum Verständnis beitragen. Für fast alles andere gilt: Anhang.

So nutzt du sowohl den Fließtext als auch den Anhang sinnvoll aus und zeigst nicht nur Ergebnisse, sondern auch dein methodisches Vorgehen.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts

Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode

[0:20] Heute geht es mal um eines meiner Lieblingsthemen, wenn ich wieder Projektdokumentation lese und bewerten darf. Und zwar um die Platzierung von Artefakten in der Projektdokumentation. Diesen Begriff Artefakt, den benutze ich ganz häufig im Blog, im Podcast, in meinen Videos. Was ist damit gemeint? Kurz zum Einstieg. Ich meine mit Artefakt alles, was in der Dokumentation oder in deiner Präsentation später auch, was kein Fließtext ist. Also Beispiel Projektdokumentation, irgendwelche Diagramme, UML-Sachen, ER-Modelle, Amortisationsrechnung, wenn du die grafisch machst, aber auch Tabellen, zum Beispiel Kostenaufstellung oder deine Zeitplanung. Code natürlich, wenn du Anwendungsentwicklung machst, irgendwelche Pläne, Netzwerkpläne oder Sonstiges oder ein Testprotokoll oder so. Oder auch wenn du Berechnungen machst, irgendwelche Formeln oder Sachen, die nacheinander berechnet werden, zum Beispiel bei der Amortisationsrechnung. Und selbstverständlich auch Screenshots, wenn du Fotos machst aus der echten Welt, solche Dinge, das sind für mich alles Artefakte. Also Dinge, die kein Text sind, wobei, ja, Code ist Text, okay. Aber ich glaube, du verstehst, worauf ich hinaus will. Fließtext im Verhältnis zu alles andere sind Artefakte. Und ich mache es gerne zum Einstieg nochmal, wie in anderen Episoden auch, so ein Too Long Didn’t Read oder Didn’t Here in diesem Fall. Meine Empfehlung ist, pack alle Artefakte in den Anhang. Es gibt wenig Gründe dafür, Artefakte in deinen Fließtext zu packen. Also du schreibst einen Satz, machst dann ein Artefakt da rein und schreibst dann weiter.

[1:48] Daumenregel sollte sein, alles in den Anhang. Und absolute Daumenregel aus meiner Sicht ist, alles was größer ist als eine halbe Seite, auf jeden Fall in den Anhang. So und jetzt gibt es vielleicht ein, zwei kleine Ausnahmen, wo man Artefakte auch in den Fließtext packen sollte oder darf oder vielleicht sogar muss. Da gehen wir gleich nochmal drauf ein. Aber als Daumenregel kannst du schon mal mitnehmen, alle Artefakte in den Anhang, insbesondere wenn sie größer sind als eine halbe Seite.

[2:13] So, jetzt gehen wir mal die Details da durch. Warum ist das so? Warum ist das sinnvoll? Also, vielleicht vorweg, die meisten IHK’n machen irgendwelche Vorgaben für deine Projektdokumentation, was die Seitenzahl angeht. Und das sind meistens Maximalforgaben, also zum Beispiel maximal 15 Seiten Fließtext und 25 Seiten Anhang. So ist es zum Beispiel bei der IHK Oldenburg, wo ich beschäftigt bin. Ganz wichtig vorweg, guck dir unbedingt die Vorgaben deiner IHK an. Es gibt nämlich 79 verschiedene in Deutschland und die machen im Zweifel alle unterschiedliche Vorgaben. Also orientier dich nicht an irgendwas, was du im Internet gehört oder gelesen hast, sondern frag bei deiner IHK nach, wo du deine Note nachher bekommst, was die Vorgaben sind. Ich gehe jetzt mal einfach davon aus, dass es 15 Seiten für Fließdecks sind und 25 für Anhang. So ist es bei uns. Aber das kann stark abweichen. Ich habe teilweise Vorgaben gesehen bis 10 Seiten runter plus nochmal 5 im Anhang oder so. Also wirklich deutlich weniger. Es gibt aber auch nach oben Abweichungen. Also guck einfach nach, was gilt für dich und dann orientierst du dich an diesen Zahlen. Ich gehe jetzt mal von den 15 Seiten aus und dann ist es üblicherweise so, dass du deine Seitenzahl maximal ausreizen möchtest. Dafür habe ich auch eine eigene Episode, einen kleinen Short aufgenommen, verlinke ich auch nochmal in den Shownotes, warum ich dann empfehlen würde, die Seitenzahl auszufüllen. Kurz gesagt, was ist, wenn du nicht alles ausfüllst? Kriegst du eine schlechte Note? Ja, dann hast du deine Chancen, die du hättest, halt nicht genutzt. Du hast zu wenig Inhalt geliefert, kriegst dafür einen Punktabzug. Blöd, ja? Also versuch die Seitenzahl auszunutzen und so gut es geht, alles mit sinnvollen Inhalten zu füllen.

[3:40] Und dann solltest du, wenn du sinnvolle Inhalte hast, sowas wie Lastenpflichtenheft, UML-Diagramme und ich weiß nicht, was du alles erstellen kannst für dein Projekt, auch dazu ein Hinweis in der verlinkten Episode, solltest du genug Inhalt haben, um deine Fließtext-Seiten zu füllen, aber auch um den Anhang zu füllen. Meistens sogar eher für den Anhang noch mehr, allein schon, wenn du was programmierst. Code-Beispiele, da kannst du ganz, ganz, ganz, ganz, ganz viel zeigen und Screenshots und ich weiß nicht mehr. Also normalerweise solltest du keine Probleme haben, um diese Seitenzahl zu erreichen. Es sollte eher ein Problem sein, zusammenzustreichen, um wieder auf die Seitenzahl runterzukommen, wenn du drüber bist. Das ist meine persönliche Einstellung. Wenn das nicht geht bei deinem Projekt, hast du vielleicht ein zu wenig umfangreiches Projekt oder du hast einfach einen Haufen Artefakte vergessen, die in der Prüfung möglicherweise erwartet werden, aber dazu auch mehr in einer anderen Episode. Heute geht es ja darum, wenn du diese ganzen Inhalte hast, wo packst du sie hin?

[4:32] Und ich würde halt sagen, dass du Fließtext locker füllen kannst und den Anhang genauso. Und wenn du jetzt Artefakte in deinen Fließtext packst, dann gehen die ja von der Seitenzahl für deinen Fließtext ab. Also keine Ahnung, du hast 15 Seiten Fließtext und mittendrin hast du aber eine ganze Seite Klassendiagramm. Dann hast du natürlich eine Seite weniger für den Text, weil das Klassendiagramm braucht dir auf, diese eine Seite. Das heißt, du hast also nicht wirklich 15 Seiten Fließtext, sondern nur 14, weil eine Seite davon ist halt ein Klassendiagramm.

[5:01] Und das ist ja blöd, weil auf dieser Seite Fließtext hättest du ja auch noch Inhalte unterbringen können, die jetzt vermutlich fehlen. Und hier auch nochmal, ich habe es in einer anderen Episode auch schon gesagt, wenn ich über Punktabzug oder Notenabzug oder Durchfallen spreche, dann hat das nie etwas damit zu tun, ob am Ende da 14 oder 15 Seiten stehen, sondern es hat immer etwas damit zu tun, dass Inhalte nicht da sind, die erwartet werden. Ja, dass du irgendwas Wichtiges nicht gezeigt hast. Keine Ahnung, wenn du zum Beispiel gar kein Klassendiagramm hast oder gar kein Code in einem Anwendungs-Ermütungsprojekt, würde ich sagen, da fehlt was, weil das würde ich schon ganz gern sehen. Ja, und da hilft es auch nicht, wenn du 15 Seiten Fließtext voll ausgereizt hast, aber du hast trotzdem kein Klassendiagramm gemacht. Und das ist jetzt nur ein Beispiel. Ja, es ist nicht für jedes Projekt ein Klassendiagramm sinnvoll. Es ist nur ein Beispiel. Aber wenn ich es erwarten würde in deinem Projekt, aber du hast es nicht gemacht und dafür trotzdem 15 Seiten geschrieben, dann fehlt mir halt trotzdem was. Ja. Und auch wenn du nur 14 hast und dir fehlt das Klassenlegramm, fehlt mir das Klassenlegramm. Also bitte, häng dich nicht an dieser Seitenzahl auf und denk auch nicht, dass die Prüfer dir Punkte abziehen, nur weil du nicht die richtige Seitenzahl hast.

[6:03] Sondern es geht immer um die jeweils fehlenden Inhalte. Und deswegen versuchen wir die Seiten möglichst mit sinnvollen Inhalten zu füllen und dann aber auch bis zum Maximum, weil sonst vergibst du dir halt die Chance, diese Inhalte zu zeigen.

[6:16] So, also Artefakte im Fließtext, die reduzieren deine verfügbaren Seiten für den Fließtext und das ist schlecht. Deswegen gehören die in den Anhang. Dafür ist auch meistens extra eine Vorgabe für die Anhangseiten gegeben, denn auch da müssen wir uns ein bisschen reduzieren und können ja einfach 100 Seiten Anhang hinterpacken. Ja, das geht einfach nicht. So, jetzt habe ich gesagt, alle Artefakte in den Anhang. Jetzt gibt es eine Sache, die du abwägen musst, und zwar die Lesbarkeit. Du musst dir ja vorstellen, deine Dokumentation wird von Menschen wie mir gelesen, korrigiert. Und die wollen natürlich auch verstehen können. Und wenn du jetzt sehr erklärungsintensive Artefakte in deiner Dokumentation hast, ich nehme mal ein Beispiel, weiß ich nicht, eine halbe Seite Quelltext mit super fancy Algorithmen, wo man wirklich jede zweite Zeile erklären muss, weil man die sonst nicht versteht. Oder du hast ein super kompliziertes Netzwerk-Therakum gezeichnet mit drei Firewalls, mit irgendwelchen Port-Forwardings und weiß der Geier was und du musst da ganz, ganz viel zu erklären. Dann kann es sinnvoll sein, das Artefakt direkt in den Text zu platzieren, weil dann kann ich auf einer Seite, die ich gerade offen habe oder mir sogar ausgedruckt habe, auch das gibt es noch bei Prüfenden im Jahr 2026, überhaupt keine Frage, weil korrigieren mit Rotstift kann man hervorragend auf Papier übrigens. Das hat sich nicht viel geändert in den letzten Jahrzehnten.

[7:30] Deswegen, wenn ich das alles auf einer Seite habe, kann ich das wunderbar auf einen Blick sehen, kann das verstehen, kann zwischen Text und Abbildung hin und her springen und kann das super nachvollziehen. Toll. Habe ich allerdings meinen Erklärungstext auf Seite 5 und mein Artefakt im Anhang auf Seite 27, dann muss ich halt immer hin und her blättern, was gar nicht mal so schlimm ist, das kriegt man schon mal hin, aber wenn Menschen wie ich, die das auf dem iPad zum Beispiel lesen, das dann vergleichen wollen, dann wird es schwierig, weil dann muss ich immer hin und her jumpen im Inhaltsverzeichnis und das dauert jedes Mal ein paar Sekunden, bis ich die Seite gefunden habe und so weiter und das ist einfach nervig. Das heißt, es ist nicht förderlich fürs Verständnis, wenn die Sachen so weit auseinander liegen.

[8:06] Jetzt ist es so, wenn du wirklich sehr erklärungsbedürftige Artefakte hast, kannst du die vielleicht in den Text packen. Da würde ich trotzdem meine zweite Daumenregel ziehen und sagen, wenn das Ding länger ist als eine halbe Seite, packe es trotzdem in den Anhang. warum? Angenommen, das Klassenlehrgramm von eben wäre eine ganze Seite groß, dann passt das ja eh nicht mehr auf die Seite, wo der Erklärtext steht. Also müsstest du sowieso beim Lesen scrollen. Auf Seite 14 ist die Erklärung, auf Seite 15 das Klassenlehrgramm. Ja, super, da muss ich ja trotzdem immer hin und her blättern, beziehungsweise hoch und runter scrollen. Da habe ich ja nichts gewonnen. Das heißt, größere Artefakte auf jeden Fall immer in den Anhang und kleinere und welche, die vielleicht auch wirklich nur sinnvoll sind in Verbindung mit dem Text, keine Ahnung. Deine Kostenberechnung, wo am Ende dann steht, das Projekt hat 2395 Euro gekostet und direkt darüber wäre es dann schön, vielleicht die Formel zu sehen, wie du es berechnet hast, damit ich nicht 20 Seiten hin und her springen muss, um diese winzige Kleinigkeit daraus zu ziehen. Also es gibt so ein paar Sachen, wie zum Beispiel die grobe Zeiteinplanung deiner 40 oder 80 Stunden oder eben deine Amortisationsrechnung, deine Kostenberechnung. Solche Dinge, die kann man auch im Fließtext platzieren. Die sind aber meistens auch nicht sehr lang. Die sind vielleicht eine Viertelseite, vielleicht maximal eine halbe Seite lang. Und wie gesagt, dann greift dann halt meine Regel, dass du das auch nach oben in den Fließtext packen kannst. Aber ansonsten würde ich sagen, alles in den Anhang. Also Lesbarkeit ist aus meiner Sicht der einzige Grund, warum man das in den Fließtext packen sollte.

[9:29] So, und jetzt nochmal gesagt, wenn du diese Fleece-Seiten quasi damit aufblähen möchtest, dass du sie mit Artefakten zukleisterst, weil dir einfach nicht einfällt, was du da an Fleece-Sext noch schreiben könntest.

[9:45] Dann würde ich sagen, tu das lieber nicht. Weil, ganz ehrlich, auch wenn vielleicht der Eindruck entsteht, die Prüfenden sind alle irgendwie alte, weiße Männer, jenseits der 60 und wissen eigentlich gar nicht mehr so genau, was da heute Phase ist in der IT. Ist nicht so. Die Prüfenden sind auch nicht doof. Die sind ja nicht umsonst Prüfende geworden. Haben also mindestens mal selber auch die Prüfung absolviert und sind meistens langjährig irgendwo beschäftigt, in der Ausbildung, Ausbilder oder Geschäftsführer, was auch immer. Also das sind ja keine Vollidionen, die da sitzen. Und wenn ich jetzt eine Doku lese, wo auf jeder zweiten Seite ein großes Bild ist, dann werde ich dir das einfach von der Seitenzahl abziehen. Ganz einfach. Also ich gehe am Ende, wenn ich die Doku gelesen habe, gehe ich den Fließtext durch und ziehe mir alle Artefakte von der Seitenzahl ab, die also mindestens größer als eine halbe Seite sind. Wenn sie quasi sinnfrei sind an der Stelle und nicht erklärungsbedürftig, würde ich sie auch abziehen, wenn sie kleiner als eine halbe Seite sind. Das heißt, ich gucke wirklich alle Fließtextseiten durch, sehe ich ein Artefakt, ziehe ich das ab und am Ende komme ich auf Seitenzahl 12 statt 15, auch wenn die letzte Seitenzahl 15 ist, weil halt einfach drei Seitenartefakte dazwischen waren. Ja, so mache ich das. Und jetzt nochmal zur Erklärung. Das heißt nicht, dass du deswegen jetzt eine Notabzug kriegst oder auch nur ein Prozentpünktchen Abzug bekommst, sondern für mich ist das nur ein Indiz. Ich sehe jetzt, oh, statt 15 Seiten hat er oder sie eigentlich nur 12 oder 13 Seiten gefüllt.

[10:59] Da kann ja dann irgendwo nur noch eine Lücke sein, was vielleicht noch fehlt in dem Projekt. Und dann gucke ich natürlich, welcher Inhalt fehlt denn und dafür gibt es dann den Punktabzug. Also nicht für die reine Seitenzahl. Ich kann es nur nochmal wiederholen. Also, denk nicht, dass die Prüfenden Idioten sind. Die haben normalerweise schon ein paar mehr Dokus gelesen und korrigiert und erkennen solche Tricks natürlich auch.

[11:24] Gut, also orientier dich am eigentlichen Problem, löst das Problem, pack sinnvollen Inhalt in die Doku und fülle deine Seiten nicht mit Rummel auf, mit irgendeinem Müll oder mit irgendwelchen aufgeblähten Artefakten oder damit du auf 15 Seiten kommst. Das funktioniert nicht, weil die Prüfenden das halt dann wieder abziehen, so wie ich zum Beispiel. So.

[11:44] Und dann nochmal vielleicht, weil ich das auch sehr oft sehe, Artefakte, schön und gut, sind auch sehr wichtig, aber deine Dokumentation sollte halt nicht einfach eine reine Ansammlung von Artefakten sein und dein Fiestext dann ausschließlich aus sowas bestehen wie, ja, ich habe ja auch noch ein UML-Diagramm gezeichnet, siehe Anhang. Ja, und dann kommt das UML-Diagramm im Anhang, das ist super, aber Vleecex gibt es dazu dann gar nicht, sondern da steht einfach nur Überschrift Softwarearchitektur und da steht da ein Satz, ich habe auch eine Architekturskizze gemacht, siehe Anhang 5.

[12:11] So, so füllt man den Vleecex nicht, denn Artefakte haben keinen Selbstzweck oder stehen einfach nur so da, sondern du machst sie aus irgendeinem Grund. Du sollst dir zeigen, dass du auch methodisch vorgegangen bist bei deiner Projektdurchführung. Und insbesondere mal bei der Softwareentwicklung, da fange ich halt nicht einfach an zu programmieren, sondern mache ich mir erst mal Gedanken, was ist denn vielleicht mit meiner Architektur? Welche Komponenten könnte es denn geben? Wie möchte ich die abstrahieren? Erzähl mal. Und als Fisi das Gleiche, da sage ich nicht einfach, ja, ich installiere jetzt hier mal die Firewall, dann gucken wir mal, sondern du musst erst mal analysieren, welcher Traffic muss da durch, welche Ports müssen freigegeben werden, was ist mehr Security und tralala. Das heißt, bevor du am Ende das Ding wirklich einbaust, hast du dir hoffentlich genug Gedanken im Vorfeld schon gemacht. Damit das am Ende auch funktioniert. Und genauso ist es bei der Softwareentwicklung ja auch. Das heißt, diese Artefakte, die haben einen Sinn. Ich zeichne ein ER-Modell nicht einfach nur für die Prüfung, weil die Prüfenden das sehen wollen, sondern weil mir das bei der Arbeit hilft. Wenn ich anfange zu programmieren und weiß noch nicht mal, welche Daten ich abbilden muss. So kann ich doch nicht vorgehen. Ich brauche doch ein Zielbild, wo ich hin will. Wie sollen meine Tabellen aussehen, meine Klassen in der Objektorientierung? Was gibt es denn? Woran muss ich denn denken? Welche Besonderheiten gibt es? Dafür sind die Artefakte da. Die sollen dir helfen. Und das sollst du auch in deiner Projektdokumentation und später in der Präsentation zeigen, dass die dir geholfen haben und dass du die absichtlich gemacht hast und nicht einfach nur gezeichnet hast, weil du ja auch noch eine Prüfungsleistung abgeben musst. Das heißt, die sind immer in einen Kontext zu setzen.

[13:29] Und im besten Fall beschreibst du diesen Kontext im Fließtext. Das heißt, anstatt zu sagen, ich habe hier ein Klassendiagramm, siehe Anhang, sagst du, bevor ich angefangen habe zu programmieren, habe ich mir Gedanken gemacht, welche Klassen ich brauche. Ich habe das Ganze in einem Klassendiagramm modelliert. Dabei ist mir schon aufgefallen, oh, hier gibt es aber eine Vererbungsbeziehung. Oder hier habe ich ein Interface eingezogen, weil die Abstraktion hier sinnvoll war. Und analog zum Netzwerkplan. Oh, hier ist mir aufgefallen, das ist ein ganz anderes Subnet. Da musste ich noch einen Router dazwischen setzen. Oder weiß der Geier was. Das heißt, so etwas sieht man ja in einem Diagramm viel offensichtlicher, als wenn man einfach anfängt und dann merkt, oh, habe ich gar nicht daran gedacht. So wollen wir nicht Software entwickeln, so wollen wir keine Systeme planen. Da brauchen wir diese Artefakte.

[14:07] Wie die dir geholfen haben, wie du die erstellt hast, was vielleicht die Besonderheiten an diesem konkreten Artefakt sind. Das sind Dinge, die du im Fließtext beschreiben musst, weil die kann man an dem Artefakt alleine nicht erkennen. Ich gucke mir dein Klassendiagramm an und denke mir, ja, das ist ein Klassendiagramm. Aber was hast du da mitgenommen? Was sind die Besonderheiten? Wie bist du darauf gekommen? Das ist etwas, wofür der Fließtext da ist. Das heißt, reine Artefaktsammlung, siehe Seite 15, bitte nicht machen, sondern vernünftige Erklärungen im Fließtext. Zumindest meine Herleitung und vielleicht auch einen Ausblick, was du damit dann getan hast. Klassendiagramm ist immer mein Lieblingsbeispiel. Ich zeichne eins, um dann später in der Implementierungsphrase mich daran zu orientieren und die Klassen zu programmieren. Dann ergibt das auch einen Sinn. Du hast das Klassendiagramm nicht einfach nur gemalt, sondern du hast es auch benutzt, um darauf aufbauend etwas anderes zu machen. Und im besten Fall ist dir das dann leichter gefallen. Es ging schneller oder war einfach besser, als hättest du das Diagramm nicht gezeichnet. In diese Richtung wollen wir was im Fließtext lesen. und dann gerne natürlich das Artefakt, aber eben halt im Anhang.

[15:05] So, das war mein Take, glaube ich, zu den Artefakten und wo die hingehören und warum du überhaupt welche machst. Und jetzt nochmal als Fazit für heute. Daumenregel nochmal zum Mitnehmen. Alle Artefakte in den Anhang packen, insbesondere wenn sie größer sind als eine halbe Seite. Dann auf jeden Fall. Dann gibt es eigentlich keinen Grund, die in den Fließtext zu packen. Es gibt wenige Ausnahmen, die ich ein bisschen aufgeführt habe. Vielleicht eine Kostenberechnung, eine Amortisationsrechnung, ein paar Formeln oder so etwas oder eine Zeitplanung, die grobe Zeitplanung. Das kann man vielleicht im Fließtext lassen, aber für fast alle anderen Artefakte würde ich sagen, immer einen Anhang. Bäm.

[15:41] Wichtig wäre, dass du die dann trotzdem in deinem Fließtext referenzierst, dass die Artefakte nicht einfach so im Anhang stehen und dann wundert man sich auch, Mensch, der hat ja auch ein Klassenergaben gezeichnet. Schön, dass ich davon gar nichts gelesen habe im Fließtext. Sondern die müssen natürlich alle referenziert und im besten Fall auch erklärt und eingeordnet werden. Was haben sie dir gebracht? Warum hast du das gemacht? Was hast du vielleicht aufbauen darauf später gemacht? Das gehört dann in den Fließtext dazu. Also Artefakte in den Anhang, Erklärungen, Einordnungen, Besonderheiten in den Fließtext. Und so kannst du auch locker, locker, locker deine Vorgaben füllen, was den Fließtext angeht und was den Anhang angeht. Also Seiten, leere Seiten, beziehungsweise Seiten, die du nicht ausgenutzt hast, müssen meiner Meinung nach nicht sein. Du kannst genug Inhalte produzieren, die dann aber auch wirklich einen Mehrwert für den Prüfenden bieten und dir dann hoffentlich auch eine gute Abschlussnote bestellen. Darum geht es ja am Ende.

[16:29] Also das war es zum Thema Artefakte in der Projektdokumentation. Ich hoffe, es hat dir ein bisschen geholfen. Ich wünsche dir auf jeden Fall viel Erfolg für deine Projektdokumentation und bis zum nächsten Mal.

Um eine sinnvolle Anzahl der Seiten der Projektdokumentation geht es in der neunten Episode der Shorts des IT-Berufe-Podcasts.

Ich würde dir bzgl. der Anzahl der Seiten deiner Projektdokumentation raten, dich immer zuerst an den konkreten Vorgaben deiner IHK zu orientieren, weil Umfang und Regeln je nach IHK unterschiedlich sein können. Die vorgegebene Seitenzahl ist in der Regel eine Obergrenze, die du nicht überschreiten solltest, gleichzeitig solltest du den verfügbaren Platz möglichst mit sinnvollen Inhalten nutzen, weil zu wenig Text meist nicht wegen der Seitenzahl, sondern wegen fehlender Inhalte zum Problem wird. Für mich gilt deshalb: nicht künstlich aufblasen, aber Fließtext und Anhang so gut wie möglich mit bewertbaren, fachlich passenden Inhalten füllen.

Inhalt

TL;DR: Schreib exakt so viele Seiten in deiner Projektdokumentation, wie es deine IHK erlaubt, und nutze den maximalen Umfang möglichst sinnvoll aus, ohne ihn zu überschreiten.

Erst auf die Vorgaben deiner IHK schauen

In Deutschland gibt es viele verschiedene IHKen und sie können bei der Projektdokumentation unterschiedliche Vorgaben haben. Deshalb solltest du dich nicht auf Aussagen aus Social Media oder aus "dem Internet" verlassen, sondern immer die Unterlagen deiner eigenen IHK prüfen.

Typische Unterschiede können sein:

• erlaubte Seitenzahl im Fließtext
• Regelungen zum Anhang
• Umgang mit Verzeichnissen
• Vorgaben zu Schriftgröße und Schriftart
• Pflicht zu Deckblatt oder bestimmten Bestandteilen

Mein Rat ist deshalb: Schau in die Merkblätter, Handreichungen oder Vorgaben deiner IHK und orientiere dich genau daran.

Die Seitenzahl ist normalerweise eine Maximalvorgabe

Die vorgegebene Seitenzahl meist eine Obergrenze. Es geht also nicht darum, die Seiten zwanghaft vollzumachen, sondern darum, nicht darüber zu liegen.

Der Hintergrund dafür ist aus meiner Sicht vor allem organisatorisch und fair:

• Prüfende müssen viele Dokumentationen in begrenzter Zeit lesen
• umfangreiche Dokumentationen sind in der Praxis schwer zu bewerten
• alle Prüflinge sollen unter vergleichbaren Bedingungen bewertet werden

Als typischen Rahmen gibt es meist 10 bis 20 Seiten Fließtext, je nach IHK. Oft gibt es zusätzlich eine eigene Begrenzung für den Anhang.

Ein Beispiel aus Oldenburg:

• 15 Seiten Fließtext maximal
• 25 Seiten Anhang maximal
• Verzeichnisse und bestimmte formale Bestandteile zählen dabei nicht mit

Zu viele Seiten können zu Abzügen führen

Wenn du die maximale Seitenzahl überschreitest, hast du die Vorgaben nicht eingehalten. Ich vergleiche das gerne mit einem Budget, das überschritten wird: Wenn 15 Seiten erlaubt sind, dann sind 16 eben formal zu viel.

Ich sage aber auch:

• wegen einer kleinen Überschreitung fällt man nicht automatisch durch
• die Folgen hängen von Bewertungskriterien und dem jeweiligen Prüfungsausschuss ab
• formale Fehler führen eher zu kleineren Abzügen als zu einem kompletten Duchfallen

Trotzdem bleibt mein Hinweis eindeutig: Überschreite die erlaubte Seitenzahl nicht.

Zu wenige Seiten sind nicht direkt das Problem

Ich betone hier nochmal, dass niemand allein deshalb Punkte abzieht, weil du weniger Seiten abgegeben hast als maximal erlaubt. Eine Dokumentation mit weniger Seiten ist formal erst einmal in Ordnung.

Das eigentliche Problem ist für mich etwas anderes:

• Wenn du deutlich weniger schreibst, fehlen oft wichtige Inhalte.
• Der Punktabzug kommt dann nicht wegen der Seitenzahl, sondern wegen nicht dokumentierter Inhalte.

Mein Beispiel dazu: Wenn ich bei einem Softwareprojekt ein Klassendiagramm erwarten würde und es fehlt, dann ziehe ich dafür Punkte ab. Nicht, weil noch freie Seiten übrig waren, sondern weil ein inhaltlich sinnvoller Bestandteil fehlt.

Mein praktischer Rat: Nutze den verfügbaren Platz aus

Ich empfehle dir, die erlaubte Seitenzahl möglichst vollständig zu nutzen, weil die Wahrscheinlichkeit hoch ist, dass sonst etwas Relevantes fehlt. Das heißt aber ausdrücklich nicht, dass du die Seiten mit beliebigem Material oder KI-generiertem Fülltext aufblasen sollst.

Wichtig ist mir dabei:

• keine inhaltsleeren Wiederholungen
• keine künstlich verlängerten Beschreibungen
• keine sinnlosen Diagramme ohne Aussagekraft
• stattdessen nur Inhalte, die einen fachlichen Mehrwert haben und bewertet werden können

Wie ich auf Seitenzahl und Inhalt schaue

Beim Lesen von Projektdokumentationen betrachte ich Artefakte im Fließtext gedanklich anders als reinen Fließtext. Dazu zähle ich zum Beispiel:

• Abbildungen
• Tabellen
• Diagramme
• Codeschnipsel
• Berechnungen

Wenn mitten im Fließtext viele solcher Elemente stehen, ist das für mich ein Hinweis darauf, dass der eigentliche beschreibende Text kürzer ausfällt. Das führt nicht automatisch zu einem Abzug, aber es kann ein Indiz sein, dass Inhalte eventuell zu knapp dargestellt wurden. Entscheidend bleibt für mich immer der Inhalt, nicht die nackte Seitenzahl.

Was du in eine Projektdokumentation aufnehmen könntest

Hier kommt eine ganze Reihe von Inhalten, die in einem typischen Projekt der Fachinformatiker:innen, besonders in der Anwendungsentwicklung, vorkommen können. Vieles davon gilt auch für andere IT-Berufe.

Anforderungen

• Anforderungsermittlung
• Lastenheft
• Pflichtenheft
• User Storys
• Product Backlog

Architektur und technische Modelle

• Architekturskizzen
• UML-Diagramme
• Klassendiagramme
• Sequenzdiagramme
• Zustandsdiagramme
• Komponentendiagramme
• Deployment-Diagramme

Infrastruktur und Systemdarstellung

• Netzwerkpläne
• Server-Erreichbarkeit
• Ports und technische Zusammenhänge

Datenmodellierung und Schnittstellen

• ER-Modelle
• relationale Tabellenmodelle
• JSON-Strukturen
• OpenAPI-Beschreibungen bei REST-APIs

Prozesse und Abläufe

• dokumentierte oder optimierte Prozesse
• Modellierung mit BPMN
• EPK
• Aktivitätsdiagramme

Umsetzungsnachweise

• Quellcode aus Produktivcode oder Testcode
• Screenshots
• Konfigurationsdateien
• Fotos von umgesetzten Arbeiten

Projektorganisation

• Vorgehensmodell wie Scrum, Wasserfall oder Kanban
• Beschreibung des Entwicklungsprozesses
• Ticket-System
• Code-Review
• Zusammenarbeit mit anderen Beteiligten
• organisatorische Abläufe

Planung und Wirtschaftlichkeit

• Zeitplanung für die 40 bzw. 80 Stunden
• Ressourcenplanung
• detaillierte Tabellen
• Kostenkalkulation
• Amortisationsrechnung
• Gegenüberstellung von Kosten und Einsparpotenzial

Mit dieser Liste will ich zeigen, dass bei einem normalen Projekt schnell viele sinnvolle Inhalte zusammenkommen können und 15 Seiten deshalb durchaus knapp werden können.

Meine abschließende Motivation für dich

Ich gebe dir am Ende noch einen Gedanken mit: Wenn du eine schlechte Note bekommst oder sogar durchfällst, obwohl du noch freie Seiten gehabt hättest, wirst du dich möglicherweise fragen, ob zusätzliche sinnvolle Inhalte den Unterschied gemacht hätten.

Deshalb mein Fazit:

• halte die Maximalvorgabe deiner IHK ein
• überschreite sie nicht
• nutze den verfügbaren Platz aber möglichst aus
• fülle ihn nur mit sinnvollen, bewertbaren Inhalten

Für mich ist genau das der sinnvolle Weg, damit deine Projektdokumentation zeigt, was du in deiner Ausbildung gelernt hast und was du im Projekt tatsächlich geleistet hast.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Inhalte der Projektdokumentation
• Gliederung der Projektdokumentation (Teil 1)

Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode

[0:20] Heute geht es um ein Thema, was immer wieder für Aufsehen sorgt oder Aufregung auf, vor allem im Internet, gerade bei TikTok, unter meinen letzten Videos, die ich gerade gepostet habe, während ich das hier aufnehme. Und zwar zum Thema Seitenzahlen in der Projektdokumentation bei dem Abschlussprojekt der IT-Berufe. Und ja, Kernfrage, die ich heute beantworten will, ist, wie viele Seiten sollte meine Projektdokumentation haben? Also vor allem Fließtext, aber auch Anhang, wie viele Seiten sind da sinnvoll? Und ich mache mal so ein Too-Long-Din’t-Read zum Einstieg. Wenn du nicht weiterhören willst als hier, schreib einfach genauso viele Seiten voll, wie deine IHK dir erlaubt. Das war’s. Und jetzt kommen wir kurze Erklärungen, warum das so ist. Fangen wir vielleicht mal ganz vorne an. Deine IHK erlaubt dir was? Hä? Ja, denn wir erinnern uns, wir haben in Deutschland 79 verschiedene IHKen. Und die machen für ihre Abschlussprojekte, für die IT-Brufe alle eventuell unterschiedliche Vorgaben. Einige machen auch keine Vorgaben oder haben einfach nichts online oder was auch immer, machen stillschweigend irgendwelche Vorgaben. Aber erstmal ist Fakt, wir haben verschiedene IHK’en und die machen potenziell unterschiedliche Vorgaben, was den Umfang einer Projektdokumentation angeht. Das heißt von, ich glaube, 10 bis 20 Seiten Fließtext habe ich schon verschiedene Vorgaben gesehen.

[1:34] Einige nehmen den Anhang mit dazu, andere nicht. Verzeichnen es raus oder doch nicht. Und es gibt überall die Möglichkeit für jede IHK, das individuell festzulegen. Es ist nicht deutschlandweit standardmäßig überall gleich. Das schon mal vorweg. Wie bei ganz vielen anderen Sachen auch übrigens zur Abschlusspräsentation und Projektdokumentation. Immer erstmal gucken, was die eigene IHK vorgibt. Weil das kann teilweise sehr krass unterschiedlich sein zu irgendwas, was du irgendwo anders im Internet liest oder gehört hast. Also guck immer, was deine IHK dir vorgibt. Daran musst du dich orientieren und nicht an irgendwas, was du irgendwo mal gehört hast bei TikTok, Instagram oder YouTube. Ja, deine IHK vergibt, nein, die IHK gibt dir nicht die Note, der Prüfungsausschuss gibt dir die Note, aber die orientieren sich natürlich an den Vorgaben der jeweiligen IHK. Also bitte erstmal darauf gucken. Und im einfachsten Fall guckst du auf der Website deine IHK, da gibt es normalerweise Merkblätter, Handreichungen, Vorgaben, was auch immer, zur Projektarbeit in den IT-Berufen. Ja, es gibt Projektarbeiten auch in anderen Berufen. Deswegen guck explizit nach den für deinen Beruf und nicht nach irgendwelchen. Vielleicht gibt es auch nur allgemeine Vorgaben. Also kurz gesagt, guck bei der IHK und recherchiere und find raus, was für deine Projektarbeit gilt. Punkt. Das ist erstmal das Allerwichtigste und daran orientierst du dich.

[2:48] Und wenn es eine Vorgabe gibt, dann steht da meistens sowas drin wie, wie die Schriftgröße sein soll, die Schriftfamilie, zum Beispiel Areal oder sonst irgendwas, ob es Verzeichnisse geben muss oder nicht, ob es ein Deckblatt geben muss und da gibt es ganz, ganz viele Vorgaben und insbesondere wird dort auch eben oft die Seitenzahl vorgegeben.

[3:07] Warum? Wenn ich mich an meine Ausbildung erinnere, und die ist jetzt echt lange her. Also ich habe meine Abschlussprüfung gemacht 2006, glaube ich. Also wenn ich das jetzt hier gerade aufnehme, 20 Jahre her. Und damals gab es bei meiner IHKF keine Vorgaben. Und meine Projektdokumentation war über 100 Seiten lang.

[3:25] Ganz viel Quelltext dran und noch und nöcher Datenverarbeitungskonzept allein, glaube ich, 10 Seiten. Also das war ein Riesending. Und wenn ich mir vorstelle, dass das irgendein Prüfender lesen und bewerten muss in endlicher Zeit, Kostenfrei in seiner Freizeit als Ehrenamt. Das ist echt nicht darstellbar, wenn man dann so wie wir zum Beispiel jetzt in diesem Prüfungsdurchgang über 100 Prüflinge haben. Es ist nicht möglich, das alles noch irgendwie zu stemmen. Deswegen muss man das reduzieren. Es geht also bei diesen Vorgaben nicht darum, dass du diese Seiten füllen musst, sondern es sind eigentlich immer maximal Vorgaben, also maximal 10 Seiten zum Beispiel. Das heißt nicht, dass du die komplett auffüllen musst, aber du darfst nicht drüber liegen, weil dann wird es halt auch irgendwann ein Problem für die Prüfenden und dann wäre es auch unfair, wenn der eine 10 Seiten abgibt, der andere aber 30 und beides ist okay. Ja gut, da kannst du ja ausrechnen, dass bei 30 Seiten irgendwie mehr bei rumkommt als bei 10. Überraschung. Deswegen gibt es immer eigentlich eine Maximalvorgabe und oft liegen die für normalen Fließtext der Projektdokumentation zwischen 10 und 20 Seiten. Vielleicht gibt es auch welche, die noch mehr, noch weniger vorgeben. Dann schreib es mir gerne als Kommentar. Würde mich natürlich interessieren. Ich kenne auch nicht alle 79 IHK-Vorgaben, aber üblicherweise so 10 bis 20 Seiten, davon kann man ausgehen.

[4:38] Und zusätzlich gibt es dann manchmal oder meistens auch noch weitere Vorgaben für den Anhang. Also hier wird meistens getrennt, Fließtext plus Anhang sind nochmal separate Seiten. Als Beispiel, und daran werde ich mich eigentlich auch immer orientieren jetzt im weiteren Verlauf, bei der IHK Oldenburg, da bin ich ja nun mal prüfender, da haben wir 15 Seiten maximal für den Fließtext plus 25 Seiten maximal für den Anhang. Das heißt insgesamt 40 Seiten für die Projektdokumentation und nicht mit drin sind da dann zum Beispiel noch die Inhaltsverzeichnisse und Tabellenverzeichnisse und alles, was davor halt noch kommt. Und das Deckblatt der IHK und so, das wird alles nicht berechnet. Ab Seite 1, wo du mit der Einleitung startest, 15 Seiten fließt, und danach kommt der Anhang und alles, was da drin ist, dafür hat man 25 Seiten. So, da gehe ich jetzt mal von aus. Andere IHK machen das ähnlich. Wie gesagt, plus, minus, X Seiten, alles möglich.

[5:28] So, es geht also nicht darum, diese Maximalvorgabe auf Teufel komm raus zu füllen, sondern nur, dass du nicht drüber liegst. Denn wenn du drüber liegst, dann müsste dir ein Prüfender dafür auch einen Punktabzug geben, weil du einfach nicht in der Lage warst, diese Vorgaben einzuhalten.

[5:41] Wenn man dir sagt, du musst, auch ein beliebtes Beispiel aus einem meiner Videos, du musst für 100 Euro Brötchen kaufen, aber kaufst welche für 110, dann kannst du am Ende nicht sagen, Chef hat aber 110 gekostet. Wenn die Vorgabe, also dein Budget 100 war, dann kannst du nicht 110 ausgeben. Das funktioniert nicht. Und hier ist es genauso, wenn die Prüfungsvorgabe ist maximal 15 Seiten und du gibst 16 ab, dann hast du die Vorgabe nicht eingehalten. Das wäre vergleichbar mit, du hast die Schriftgröße, den Seitenabstand oder was auch immer nicht eingehalten. Dafür muss es halt einen Punktabzug geben. Machen die Prüfer das immer? Wird man bei 15,5 Seiten gleich eine Noteabzug bekommen? Nein, natürlich nicht. Es gibt Bewertungskriterien, Bewertungsmatrizen, wo genau drin steht bei einigen IHK, wofür man wie viele Punkte kriegen kann oder auch nicht kriegen kann. Und für formale oder formelle Gestaltung gibt es bei ganz vielen IHK eine eigene Kategorie und das sind dann vielleicht, weiß ich nicht, 10% der Note. Weil natürlich kommt es bei der Projektdokumentation beim gesamten Projekt auf den Inhalt an und da wird es, wenn überhaupt, einen Abzug für irgendwelche Seitenzahlen oder so geben im unteren Prozentbereich. Da wird man sicherlich nicht eine Note dafür abziehen, wenn du eine Seite zu viel hast. Aber es muss im Vergleich zu jemandem, der die Seitenzahl eingehalten hat, ja irgendwie schlechter bewertet werden. Das ist doch sonst nicht mehr fair den anderen gegenüber, die sich an die Vorgaben gehalten haben. Das kann man ja so nicht machen. Also grundsätzlich abzugsfähig ist das, wenn du zu viele Seiten hast. Heißt das, dass du deswegen sofort durchfällst? Nein.

[7:11] Könnte man dich dafür durchfallen lassen? Ja, weil du hast die Vorgaben halt nicht eingehalten. Du kannst auch nicht sagen, ich habe 100 Stunden programmiert statt 80 als Anwendungsmeckler und kriegst dafür eine 1. Das funktioniert ja nicht, weil alle anderen haben 80 gebraucht und du 100. Sorry, Vorgaben nicht eingehalten. Also, muss man immer genau gucken, kriegt man jetzt wegen, wie gesagt, einer Zeile mehr eine Note, Punkt, Absatz, oder fällt durch? Eher nicht, aber die Chance ist halt da und theoretisch, formal, könnte man nicht durchfallen lassen dafür. Also, halt die obere Seitenzahl auf jeden Fall ein und schreib nicht mehr als erlaubt. Das wäre schon mal ganz wichtig.

[7:44] So, jetzt ist aber bei vielen Projektdokumentationen, die ich so lese und gelesen habe in der Vergangenheit, eher das Problem, dass sie zu wenig in Anführungszeichen füllen. Das heißt, in Anführungszeichen, in Anführungszeichen, zu wenig Seiten füllen. So, und zu wenig in Anführungszeichen, weil das ist ja nur eine Maximalvorgabe. Also du könntest auch eine Doku abgeben mit einer Seite, wenn du maximal 15 schreiben darfst. Alles okay. Das Problem, was jetzt nur daraus folgt, ist, wahrscheinlich ist auf der einen Seite nicht der gleiche Inhalt wie in einer anderen Doku mit 15 Seiten. Ich meine, das sollte offensichtlich sein, dass du keine so gute Projektarbeit dokumentieren kannst, wenn du einfach deutlich weniger Text ablieferst. Das funktioniert nicht. Deswegen ist mein Problem mit Dokus, die zu wenig Seiten haben, nicht, dass sie zu wenig Seiten haben, sondern dass einfach Inhalte fehlen, die auf diesen Seiten stehen würden. Und das bringt auch immer ganz viel durcheinander. Oder es ist dann so, wird jetzt hier schon eine Note abgezogen, wenn ich zwei Seiten zu wenig habe? Nein, dafür kriegt niemand eine Note abgezogen. Es ist ja, die Vorgaben sind eingehalten, dafür kann ich dir gar nichts abziehen. Das Problem ist, wenn du Inhalte nicht lieferst, die du aber hättest liefern können auf diesen fehlenden zwei Seiten. Dafür gibt es einen Punktabzug.

[8:51] Simples Beispiel, ich erwarte bei einer Programmieraufgabe ein Klassendiagramm und du hast keins drin. Dafür aber noch eine Seite frei bis zu deinen 15 erlaubten Seiten. Tut mir leid, dann ziehe ich dir einen Punkt ab, aber nicht für die fehlende Seite, sondern für das fehlende Klassendiagramm. So wird ein Schuh draus. Also kein Prüfender wird dir irgendwie einen Punkt abziehen, weil du zu wenig Text geschrieben hast, sondern es geht immer um den Inhalt, den du nicht geschrieben hast und nicht präsentiert hast. Darum geht es.

[9:16] Also deswegen allein schon mein Vorschlag, nutz immer die ganze Seitenzahl aus, die du zur Verfügung hast, weil sonst hast du sehr wahrscheinlich irgendwas, was dir fehlt einfach.

[9:26] So, und bitte verstehe das jetzt nicht so, dass du diese Seiten dann auffüllst mit Schrott, einfach nur, um auf die 15, 10 oder 20 zu kommen. Darum geht es nicht. Und vor allem bitte im Zeitalter von KI, generiere da nicht irgendeinen Schrotttext, nur um die Seiten zu füllen und der wird dann super umfangreich und ausschweifend und 37 Mal wiederholt, sondern du sollst natürlich sinnvolle Inhalte liefern. Also was zu deiner Arbeit beigetragen hast, was du gemacht hast, was bewertet werden kann. Sinnvolle Artefakte, Diagramme, die irgendwie auch einen Mehrwert bringen. Das sollst du da reinpacken und nicht einfach generierten Fließtext, wo du einfach nochmal ein Bild beschreibst, so nach dem Motto. Das ist hier nicht das, was gemacht werden soll, sondern du sollst sinnvolle Inhalte da reinpacken. Und ich habe gleich auch noch eine Liste, die man durchgehen kann für so ein übliches Projekt, bezogen auf Einwilligungsentwicklung, aber viele Inhalte gelten auch für alle anderen IT-Berufe, was man alles so in eine Doku packen könnte, damit du mal einen Eindruck davon hast, warum vielleicht auch 15 Seiten sogar schon knapp werden, wenn man ein entsprechend normales, umfangreiches Projekt hat.

[10:24] So, ich persönlich mache es tatsächlich so, wenn ich Projektarbeiten jetzt durchlese und korrigiere, dass ich alle Artefakte, die ich irgendwo noch zwischendrin finde in den Fließtextseiten, dass ich die von der Seitenzahl abziehe. Was meine ich mit Artefakten? Also zum Beispiel Abbildung oder Tabellen, Amortisationsrechnung, Code, Schnipsel, was auch immer. Also alles, was kein Fließtext ist, das ist bei mir Artefakte. Und da gehe ich die Doku wirklich durch. Und wenn ich da so eine Seite Klassendiagrammen mitten im Fließtext habe, dann wird das von der Seitenzahl abgezogen. Und dann gucke ich am Ende, oh, sind 13 Seiten gewesen. Okay, daraus folgert ja jetzt noch nicht, dass ich eine Note abziehe oder gar einen Punkt. 13 ist ja kleiner als die erlaubten 15, also passt das alles. Aber das ist für mich nochmal so ein Indiz, wenn ich jetzt sehe, oh, 13 Seiten statt der erlaubten 15, da ist ja die Chance recht hoch, dass irgendetwas fehlt. Und dann gucke ich natürlich nochmal hin, was hätte denn hier noch beschrieben werden können? Ist irgendwas ziemlich knapp oder unverständlich etc.? Und das ist für mich so ein Indiz, um nochmal genauer hinzugucken. Aber bitte nicht falsch verstehen, nur weil jemand 13 Seiten abgibt, mache ich in keinster Weise irgendeinen Punktabzug daran fest, sondern es geht immer um den Inhalt. Punktabzug höchstens, wenn es zu viele Seiten sind. Ich kann mich nur nochmal wiederholen.

[11:34] So, und jetzt würde ich mal überlegen, wenn du Schwierigkeiten hast, deine 15 oder 10 oder 20 Seiten, also die Vorgaben zu füllen, woran könnte das denn liegen? Vielleicht ist dein Projekt tatsächlich einfach nicht umfangreich genug, sollte eigentlich ausgeschlossen sein, dadurch, dass dein Projektantrag ja genehmigt wurde und Prüfende da schon drauf geguckt haben. Also normalerweise sollten die Projekte umfangreich genug sein, sonst wären sie nicht genehmigt worden. Aber vielleicht hast du ja einfach Sachen vergessen, die zu so einem Projekt üblicherweise dazugehören. Das hattest du aber vielleicht gar nicht auf dem Zettel oder man hat dir das nie gesagt. Und deswegen habe ich mal so ein paar Punkte hier auf der Liste, was du in einem üblichen Projekt für Anwendungsentwicklerinnen durchaus unterbringen könntest. Und gefühlt die Hälfte davon gilt auch für alle anderen IT-Berufe. Ich mache nur mal ein paar Beispiele. Irgendwie musst du Anforderungen erfassen. Was soll überhaupt in einem Projekt gemacht werden? Und das müssen übrigens alle IT-Berufe. Das heißt, es gibt irgendeine Form von Anforderungsermittlung. Sei es zum Beispiel ein Lastenheft, ein Pflichtenheft, User Stories, wie ein Product Backlog, wenn du Bock hast auf Scrum oder was auch immer. Irgendwo schreibst du Anforderungen auf, die kannst du da reinnehmen.

[12:32] Dann gibt es vielleicht für die Softwareentwicklung Architekturskizzen, UML-Diagramme, Klassendiagramme, Deployment-Diagramme, Komponentendiagramme. Das kann man wunderbar für Softwareentwicklung zeigen. Bei Fizis gibt es da vielleicht einen Netzwerkplan. Wo steht die Firewall, auf welchen Ports ist der Server erreichbar und was auch immer. Dann haben wir natürlich sowas wie Klassendiagramme, wenn du tiefer in den Code rein willst, Sequenz-Diagramme oder Zustandsdiagramme, wenn dein System Zustände hat. Also alles, was die UML hier gibt. Du kannst Datenbanken modellieren mit ER-Modell oder relationalem Tabellenmodell oder eine JSON-Struktur als Open API, wenn es REST API ist, dokumentieren oder modellieren oder was auch immer. Du hast vielleicht irgendwelche Prozesse, die du optimieren willst. Die müssen dokumentiert werden, die müssen vielleicht modelliert werden mit.

[13:17] BPMN oder einer EPK oder einem Aktivitätsdagramm aus der OML. Du hast, wenn du programmiert hast, irgendwelche Quelltexte von Produktivcode, von Testcode. Du hast Screenshots sicherlich. Du hast vielleicht Config-Files, wo du was angepackt hast. Du hast, weiß ich nicht, am Ende ein Foto gemacht von der Appliance-Firewall, die du in den Server-Rack eingebaut hast. Was auch immer du als Projekt gemacht hast. Also irgendwelche Nachweise, dass du es auch wirklich getan hast. Fotos, Screenshots, wie auch immer. Du hast irgendeine Form von Projektmanagement gemacht, einen Entwicklungsprozess, vielleicht hast du Scrum gemacht oder Wasserfall oder Kanban oder was auch immer, aber auch dazu kannst du Inhalte liefern, vielleicht ein Foto vom Kanban-Board, vielleicht einfach eine Beschreibung des Prozesses, wie ihr mit eurem Ticketsystem arbeitet, wer bei dir einen Code-Review gemacht hat, mit wem du zusammen den Server installiert hast, wer deine Rechnung freigegeben hat, was auch immer, irgendwas, was zum Organatorischen dazugehört.

[14:11] Und ganz sicher hast du in jedem Projekt, egal welcher IT-Beruf, eine Zeitplanung gemacht. Du hast deine 40 oder 80 Stunden aufgeteilt. Du hast eine detaillierte Aufnahme der nötigen Ressourcen gemacht. Du hast die Zeiten runtergebrochen mit einem schön ausgearbeiteten Plan in einer Tabelle, die du irgendwo unterbringen kannst. Und natürlich hast du auch deine Kosten kalkuliert und eine Amortisationsrechnung gemacht. Mit Kosten versus Einsparungspotenzial und ich weiß nicht was. Ein schönes Diagramm mit so einer Amortisationsrechnung, wo sich irgendwo die Linien dann kreuzen und so weiter. Also alles das sind schon mal Themen, die mir so spontan einfallen, die quasi in jedem Projekt untergebracht werden können. Und dann siehst du vielleicht, oh, da könnten 15 Seiten aber ja tatsächlich schon mal knapp werden, wenn du zu allem auch noch ein bisschen was schreibst, anstatt einfach nur das Artefakt einzubauen.

[14:55] So, und ich glaube, das war es jetzt von mir als letzte Motivation, nochmal darüber nachzudenken, die Seiten zu füllen. Was wäre, wenn du jetzt eine schlechte Note bekommst oder vielleicht sogar durchfällst in deiner Projektarbeit und hättest am Ende aber noch Platz gehabt, um was zu schreiben? Du hättest also noch Seiten übrig. Du hattest 15 als Vorgabe, hast nur 10 gefüllt und jetzt fällst du durch die Prüfung. Was wirst du dich dann dein Leben lang oder vielleicht auch nur bis zur nächsten Prüfung in einem halben Jahr fragen? Hätte ich es geschafft, wenn ich noch die fünf Seiten gefüllt hätte? Wenn ich hier noch den einen Text hinzugefügt hätte, dieses eine Testprotokoll, das eine Klassendiagramm, hätte ich dann vielleicht bestanden?

[15:30] Du weißt es nicht. Du hättest es vielleicht geschafft, aber du hast es leider nicht genutzt. Die Inhalte fehlen jetzt nun mal und deswegen bist du vielleicht durchgefallen oder hast eine schlechte Note. Und das wäre doch blöd, weil du nutzt ja diese Chance, die du hast, selber nicht. Niemand sitzt neben dir und guckt dir über die Schulter, während du das Ding hier schreibst, die Doku. Das ist alles in deiner Hand. Du kannst dir das Thema ausdenken, du kannst die Struktur, die Inhalte, das kannst du alles völlig frei gestalten und hast dafür auch im Vergleich zu so einer schriftlichen Prüfung relativ viel Zeit. Also nutzt sie doch auch aus. Du hast alles in deiner Hand. Das heißt aber auch, wenn du durchfällst und eine schlechte Note kriegst, ist niemand anderes außer dir dafür verantwortlich. Und wenn du dein Potenzial, was du hast, in diesem Fall die Seiten, nicht ausnutzt, ja, dann bist du am Ende leider selber schuld, wenn du die Inhalte nicht lieferst, obwohl du sie hättest liefern können. Also, das nochmal die letzte Motivation. Wäre doch blöd, wenn du eine schlechte Note hast und fragst dich dann dein Leben lang, hat es daran gelegen, dass ich noch zwei Seiten hätte schreiben können? Vielleicht hätte das ja den Ausschlag gegeben für die bessere Note. Also, Fazit für heute. Nutze die Seitenzahl, die du ausnutzen darfst, voll aus.

[16:36] Überziehe nicht, aber nutze es so weit es eben geht aus, die Seitenzahlen für Fließtext und Anhang. Aber fülle das bitte nur mit sinnvollen Inhalten. Füll das nicht mit irgendwelchen inhaltsleeren generierten Kram oder irgendwelchen, habe ich auch schon zum Beispiel gesehen, Klassendiagrammen mit zwei Klassen drauf. Das ist jetzt nicht übertrieben. Die füllen dann eine ganze Seite mit zwei Klassen. Das ist ein bisschen wenig. Das ist ein bisschen inhaltsleer. Das ist auch nicht spannend oder interessant und zeigt auch nicht deine tolle Leistung nach drei Jahren Ausbildung, sondern das ist so, ich musste hier halt irgendwas malen, weil ich muss ja auf die Seitenzahl kommen. Bitte so nicht verstehen, das meine ich nicht. Füll die Dokumentation mit sinnvollen Inhalten, die ich als Prüfender auch bewerten kann, wo ich dir eine Note für geben kann. Die zeigt, dass du deinen Job beherrschst. Darum geht es in dieser Abschlussprüfung.

[17:20] Das war’s für heute. Ich wünsche dir viel Erfolg bei deiner Dokumentation und hoffe, dass du deine Seitenvorgabe auch einhältst und mit sinnvollen Inhalten füllst. Mach’s gut!

Um Stakeholder für deine IHK-Projektarbeit geht es in der achten Episode der Shorts des IT-Berufe-Podcasts.

Ich zeige dir in diesem Podcast-Short, warum Stakeholder für jedes IHK-Abschlussprojekt zentral sind: Von ihnen kommen die Anforderungen, an denen sich später die Qualität deines Projekts misst. Dabei solltest du nicht nur an Kund:innen und Benutzer:innen denken, sondern auch zum Beispiel an Projektleitung, Betrieb, Support, Datenschutz, Gesetzgeber, Sicherheitsverantwortliche, Management, externe Dienstleistende oder technische Rahmenbedingungen. Ich empfehle dir, alle relevanten Stakeholder systematisch zu sammeln, ihre Anforderungen zu dokumentieren und zu priorisieren, damit dein Projekt nicht an übersehenen Anforderungen scheitert.

Stakeholder und Anforderungen im IHK-Abschlussprojekt

Ich erkläre dir, warum die Stakeholder-Analyse in praktisch jedem Abschlussprojekt für die IHK-Prüfung wichtig ist. Egal ob du in der Anwendungsentwicklung, Systemintegration oder in einem kaufmännischen IT-Beruf arbeitest: Du brauchst eine Anforderungsanalyse. Dabei geht es darum, herauszufinden, wer was von deinem Projekt erwartet und welche Anforderungen daraus entstehen.

Die Anforderungen musst du aufnehmen, dokumentieren, priorisieren und konkretisieren. Sie sind entscheidend für den Projekterfolg, denn Qualität bedeutet: Grad der Übereinstimmung mit den Anforderungen. Wenn Anforderungen fehlen, unklar sind oder übersehen wurden, kannst du am Ende nicht sicher sagen, ob dein Projekt wirklich erfolgreich ist.

Was Stakeholder sind

Ich fasse Stakeholder als alle Personen, Rollen, Institutionen oder auch Rahmenbedingungen auf, die:

• Interesse an deinem Projekt haben,
• Einfluss auf dein Projekt haben,
• oder von deinem Projekt betroffen sind.

Wichtig ist: Nicht alle denkbaren Stakeholder sind in jedem Projekt relevant. Die Liste soll dir helfen, mögliche Stakeholder nicht zu vergessen.

Warum Stakeholder oft übersehen werden

Ich beobachte häufig, dass Prüflinge nur an folgende Stakeholder denken:

• Kund:innen beziehungsweise Auftraggeber:innen
• Endbenutzer:innen

Dabei werden viele weitere Stakeholder vergessen, obwohl sie ebenfalls konkrete und teilweise harte Anforderungen an das Projekt haben. Wenn du nur einzelne Stakeholder berücksichtigst, kann dein Projekt später scheitern, weil wichtige Anforderungen fehlen.

Mögliche Stakeholder und ihre typischen Anforderungen Kund:innen oder Auftraggeber:innen

Diese Stakeholder bezahlen das Projekt oder geben es in Auftrag. Ihre typischen Interessen sind:

• Einhaltung des Budgets
• Einhaltung von Terminen
• Erreichen der Business-Ziele

Kund:innen sind nicht automatisch auch die Menschen, die das Ergebnis später benutzen.

Endbenutzer:innen

Das sind die Personen, die mit der Software oder dem System tatsächlich arbeiten. Ihre Anforderungen können ganz anders sein als die der Kund:innen, zum Beispiel:

• einfache Bedienung
• gute Performance
• Zuverlässigkeit

Das gilt nicht nur für Software, sondern auch für Systeme in der Systemintegration.

Projektleitung

Auch die Projektleitung ist ein Stakeholder. In deinem IHK-Projekt kannst das auch du selbst sein. Mögliche Anforderungen sind:

• Planungssicherheit
• Risikominimierung
• Reporting

Gerade im Prüfungsprojekt ist Planungssicherheit wichtig, weil du nur eine begrenzte Stundenzahl hast.

Entwickler:innen beziehungsweise Administrator:innen

Die Personen, die das System später weiterentwickeln oder betreiben, haben ebenfalls Anforderungen. Beispiele sind:

• wartbarer Code
• stabile Systeme
• gute Testbarkeit
• definierte Deployment-Prozesse
• stabile APIs
• eventuell Anforderungen an UX, UI oder Barrierefreiheit

Für die Systemintegration können zusätzlich wichtig sein:

• hohe Verfügbarkeit
• Skalierbarkeit
• Monitoring
• Alerts

IT-Betrieb und Support

Dieser Stakeholder wird oft vergessen, obwohl das System nach der Einführung meist über längere Zeit betrieben wird. Typische Anforderungen sind:

• Wartbarkeit im Betrieb
• Logging
• Dokumentation
• klare Prozesse für Fehlerfälle

Datenschutz und Compliance

Sobald dein Projekt in einem regulierten Umfeld stattfindet, können daraus verbindliche Anforderungen entstehen. Beispiele sind:

• DSGVO-Konformität
• Datensparsamkeit
• Zugriffskontrollen
• Monitoring
• weitere organisatorische oder technische Vorgaben

Ich nenne auch zusätzliche Vorschriften wie Code-Reviews, Vier-Augen-Prinzip oder neue regulatorische Anforderungen.

Staat und Gesetzgeber

Je nach Branche gelten weitere gesetzliche Vorgaben, zum Beispiel:

• Anforderungen an Barrierefreiheit
• Aufbewahrungspflichten
• revisionssichere Archivierung

Diese Vorgaben können sehr konkrete Anforderungen an Software oder Infrastruktur auslösen.

Sicherheitsverantwortliche

Im Unternehmen kann es Rollen geben, die Sicherheitsanforderungen vorgeben. Beispiele sind:

• Zugriffsschutz
• Verschlüsselung
• Pentests vor dem Go-live

Solche Punkte musst du bei Zeit, Budget und Planung berücksichtigen.

Kulturkreis

Wenn Software international eingesetzt wird, entstehen Anforderungen durch Sprache und Nutzungskontext, zum Beispiel:

• Übersetzungen
• unterschiedliche Schreibrichtungen
• Datumsformate
• Zahlenformate

Management oder Geschäftsführung

Diese Stakeholder interessieren sich vor allem für die wirtschaftliche und strategische Seite des Projekts, zum Beispiel:

• Amortisation
• Return on Investment
• strategische Passung
• Budget und Portfolio
• Skalierbarkeit

Externe Dienstleistende

Wenn externe Unternehmen beteiligt sind, können zusätzliche Anforderungen entstehen, etwa:

• technische oder organisatorische Schnittstellen
• Kommunikationswege
• Service-Level-Agreements

Hardware beziehungsweise vorhandene Infrastruktur

Auch technische Rahmenbedingungen können wie ein Stakeholder wirken. Beispiele sind:

• begrenzte CPU- oder RAM-Ressourcen
• Netzwerklatenzen
• begrenzter Speicherplatz

Diese Limitierungen beeinflussen direkt, wie du dein Projekt umsetzen kannst.

So kannst du in deinem Projekt vorgehen

Ich empfehle dir ein schrittweises Vorgehen:

1. Stakeholder sammeln
   Überlege zuerst, wer Interesse an deinem Projekt haben könnte.

2. Stakeholder gruppieren
   Zum Beispiel in intern und extern oder nach anderen sinnvollen Kriterien.

3. Repräsentierende Personen auswählen
   Du kannst nicht mit allen sprechen, also such dir passende Ansprechpersonen oder Rollen aus, etwa Key-User:innen.

4. Anforderungen erheben
   Das kann oft einfach über Gespräche passieren. Bei Gesetzen oder Spezialthemen kannst du auch Fachpersonen wie Datenschutz- oder Sicherheitsbeauftragte einbeziehen.

5. Anforderungen dokumentieren und priorisieren
   Schreib die Anforderungen auf, formuliere sie einheitlich und priorisiere sie. Daraus kann zum Beispiel ein Lastenheft entstehen.

6. Widersprüche und Prioritäten prüfen
   Später kannst du analysieren, welche Anforderungen besonders wichtig sind und ob es Konflikte zwischen ihnen gibt.

Beispiel aus einem kleinen Web-App-Projekt

Ich nenne zum Schluss ein einfaches Beispiel:

• Benutzer:innen wollen eine einfache Oberfläche
• Admins wollen zum Beispiel Rechteverwaltung, Security-Vorgaben und Logging
• gesetzliche Vorgaben wie DSGVO müssen bei personenbezogenen Daten eingehalten werden

Selbst bei einem kleinen Projekt kommen also schnell mehrere Stakeholder zusammen.

Fazit

Ich mache deutlich, dass du in deinem Projekt nicht nur an Kund:innen oder Benutzer:innen denken solltest. Es gibt viele weitere mögliche Stakeholder, deren Anforderungen dein Projekt beeinflussen. Wenn du diese Anforderungen frühzeitig sammelst, dokumentierst und priorisierst, reduzierst du das Risiko, dass dein Projekt an übersehenen Anforderungen scheitert. Genau daran entscheidet sich letztlich auch, wie erfolgreich und qualitativ dein Projekt ist.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts

Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode

[0:20] Heute möchte ich mich mal mit einem Thema beschäftigen, was in, ja, eigentlich allen IT-Abschlussprojekten für die IHK-Prüfung relevant ist, und zwar die Stakeholder bei deinem Projekt. Welche es da so gibt, was die für Anforderungen haben könnten und welche du vielleicht vergessen hast bei deiner Stakeholder-Analyse, darüber wollen wir heute mal sprechen, sehe ich nämlich ganz oft. Normalerweise gehört zu jedem IT-Projekt, egal welche Fachrichtung, Systemmitigation, Anwendungsentwicklung, kaufmännisch, ganz egal, müssen wir eine Ist-Analyse machen, eine Anforderungsanalyse, sorry, bringe ich ein bisschen durcheinander gerade, die Anforderungsanalyse. Um die soll es heute gehen. Das heißt, welche Anforderungen soll dein Projekt überhaupt umsetzen? Und das ist ganz egal, ob ich eine Software entwickle oder irgendein System installiere, konfiguriere oder irgendein Angebot berechne. Ganz egal, was ich für ein Abschlussprojekt habe, es geht immer darum, wer will eigentlich was haben und für wen mache ich das und was wollen diese, meistens sind es Menschen oder Rollen oder Organisationen, Institutionen können es auch sein, wir gleich nochmal sehen, was wollen die von mir? Was haben die für konkrete Anforderungen an mein Projekt? Und diese Anforderungen muss ich aufnehmen, die muss ich dokumentieren, die muss ich im besten Fall priorisieren, die muss ich verfeinern und konkretisieren. Mit diesen Anforderungen steht und fällt der Erfolg meines Projekts. Denn du kennst vielleicht noch aus einer der unzähligen anderen Episoden, wo ich das Thema angesprochen habe, die Definition von Qualität.

[1:39] Qualität ist der Grad der Übereinstimmung mit den Anforderungen. Und wenn ich keine Anforderungen habe oder die Anforderungen halb habe oder vergessen habe oder unklar habe, dann weiß ich gar nicht, ob ich qualitativ gearbeitet habe, ob ich fertig bin, ob das Projekt wirklich das tut, was es soll, weil ich eine Anforderung übersehen habe, vergessen habe etc. Und woher kriege ich die Anforderungen von meinen Stakeholdern? Da erzähle ich auch immer gerne die witzige Geschichte, dass ein Prüfling in der Projektpräsentation das mal mit E-A geschrieben hat, also Steak, wie das Steak, was ich auf den Grill lege. Aber darum geht es hier natürlich nicht, sondern es geht um das englische Wort Steak, was leider genauso ausgesprochen wird, aber anders geschrieben wird, nämlich S-T-A-K-E. Stake ist das englische Wort für sowas wie, ja, wie soll ich sagen, so ein Stock oder eine Begrenzung. Ich erkläre das immer so. Die Gründerväter der USA, die da in die Wildnis aufgebrochen sind und gesagt haben, so, das Land gehört jetzt mir, haben die so einen Stock in den Boden gerammt und gesagt, so, das ist jetzt die Grenze. So, Grenzsteine. Ab jetzt ist das meine Farm.

[2:36] Wir wollen nicht drüber reden, ob das eine gute Idee war da damals, aber so ist es halt gelaufen. Und diese Stakeholder, die diesen Stock in der Hand haben, die haben gesagt, so, das ist es jetzt und jetzt gehört es mir. Und diese Stakeholder übertragen wir jetzt mal auf mein Projekt und überlegen uns, welche Personen, Institutionen, wie auch immer gerade aufgelistet, haben Interesse an meinem Projekt und haben Anforderungen für mich und an mein Projekt. Und dann ist es meine Aufgabe, als Anbietungsentwicklerin, als FISI, als Kaufmanager, IT-Mensch, was auch immer, das auszuwerten, was für Stakeholder es überhaupt gibt und was die für Anforderungen haben. Und das schmeißen wir dann alles in ein großes Dokument. Sei es ein Lastenheft, wenn ich ganz klassisch im Wasserfall unterwegs bin. Seien es User-Stories für agile Projekte. Ganz egal, aber in irgendeiner Form werden wir die Anforderungen verwalten müssen. Das gilt für jedes Projekt, egal welcher Fachrichtung. Ich muss mir erstmal klar werden, was soll überhaupt gemacht werden. Denn wenn ich nicht weiß, wo ich hin soll, wie weiß ich dann, ob ich das Ziel erreicht habe. Geht nicht. Also, ich brauche die Anforderungen, gehört für mich in jedem, jedem, jedem Projekt dazu. So.

[3:40] Und jetzt haben wir oft das Projekt, das Projekt, das Problem, dass die Prüflinge leider vergessen, wen man denn vielleicht noch hätte fragen sollen zu so einem Projekt. Denn ganz oft denkt man nur an den Kunden, der, der das am Ende bezahlt oder an die Benutzer, die das am Ende benutzen, die Software. Auch okay. Übrigens nicht das gleiche, Kunde und Benutzer. Kommen wir gleich nochmal drauf. Und dann vergisst man halt die 27 anderen Stakeholder, die es theoretisch auch noch geben könnte, die aber vielleicht auch harte Anforderungen an meinem Projekt haben. Ja, und dann gehen wir gleich mal eine konkrete Liste durch mit einigen potenziellen Stakeholdern, an denen du dich dann so ein bisschen orientieren kannst und dich davon inspirieren lassen kannst. Ja, und was passiert, wenn ich nur einen Stakeholder frage? Ja, ich vergesse natürlich ganz viel und am Ende scheitert das Projekt, weil irgendwer sagt, Moment mal, hast du daran eigentlich auch gedacht? Oh, nö, den habe ich leider nicht gefragt. Ja, doof gelaufen. Da kannst du mal von vorne anfangen oder das Projekt umbauen oder es ist gescheitert oder wie auch immer. Das wollen wir natürlich nicht. Also, das Ziel soll sein, alle relevanten Stakeholder zu identifizieren und natürlich von denen auch die Anforderungen zu bekommen, damit dein Projekt dann auch genau weiß, was da zu tun ist. Ja, okay. Fangen wir ganz vorne an. Definition. Stakeholder. Was ist das eigentlich? Also ich habe gerade gesagt, wie er nicht geschrieben wird, wie das Stake.

[4:54] Also es ist halt irgendjemand, der oder die Interesse an deinem Projekt hat. So ganz allgemein formuliert. Einige sagen auch, es müssen Menschen sein, die irgendwie Einfluss auf dein Projekt haben. Ja, weiß nicht. Also ich würde das ganz allgemein formulieren, alle, die irgendetwas mit deinem Projekt zu tun haben, weil sie daran interessiert sind, weil sie vielleicht Einfluss drauf haben, weil sie davon betroffen sind. Beispiel, du baust eine Software und die Menschen müssen die Software am Ende benutzen, werden sie natürlich davon betroffen.

[5:22] Aber, und ich fasse das gleich schon mal weiter, auch alles, woran man vielleicht nicht offensichtlich denkt, zum Beispiel, wenn du dein IT-Projekt hier in Deutschland umsetzt, gelten deutsche Gesetze, an die du dich halten musst, zum Beispiel. Aber ich greife schon ein bisschen vorweg, die konkrete Liste, die ich dir vorstellen möchte, die gehen wir ja gleich einmal durch. Wichtig ist, wie gesagt, dass du an alles denkst. Sind die alle für dein Projekt immer relevant? Nein, genau. Du musst also jetzt nicht alle, ich weiß gar nicht, wie viele sind, 10, 15 Stakeholder, die ich gleich aufzähle, müssen nicht für dein Projekt gültig sein. Aber als Idee, denk mal dran, vielleicht hast du einen übersehen. Also bitte nicht so verstehen wie, ich muss jetzt diese Liste abarbeiten, sondern für bestimmte Projekte gibt es auch nicht alle diese Stakeholder. Ich will dir nur zeigen, welche es geben könnte, damit du keinen vergisst.

[6:07] Und jetzt gehen wir mal die Liste durch. Ich habe konkrete Stakeholder mal mitgebracht. Fangen wir ganz von an. Kunde, Auftraggeber. Und gerne auch Kundin oder Auftraggeberin natürlich. Und ich habe jetzt immer dazu aufgelistet, was für Interessen die haben könnten, beziehungsweise was für Anforderungen die haben können. Und Kunde, Kundin möchte natürlich gerne, dass das Budget eingehalten wird, weil, um das kurz abzugrenzen von dem nächsten Stakeholder, den ich mal eben vorgreife, nämlich Endbenutzerinnen, also die, die wirklich mit dem System am Ende arbeiten, wenn du eine Software programmierst, die, die mit der Software nachher rumklicken müssen, das sind die Endbenutzer. Und das sind nicht zwangsläufig die Kundinnen. Kundinnen sind die, die dir das Geld bezahlen, die sagen, so mach das mal bitte für mich. Das könnte zum Beispiel, Klischee, der Chef eines Unternehmens sein, der will, dass du da was programmierst, aber der Chef benutzt die Software am Ende gar nicht, sondern seine Mitarbeitende benutzen die, um das kurz abzugrenzen. Also, Kunde möchte Budget einhalten, Termine einhalten und vor allem die Business-Ziele erreichen. Ich will eine Rechnungswesen-Software programmiert haben, ja, dann sollte die am besten nachher auch Rechnungswesen können. Das wäre schon ganz gut. Also, das möchte der oder die Kundin von dir haben. Und der oder die Endbenutzerin, die am Ende damit arbeiten, die haben vielleicht ganz andere Anforderungen. Zum Beispiel wollen die, dass man das Ding einfach bedienen kann. Was interessiert die das eingehaltene Budget? Das müssen die ja nicht bezahlen. Aber wenn ich jeden Tag dreimal klicken muss, obwohl ich es auch mit einem Klick hätte machen können, das nervt die Leute natürlich. Also einfache Bedienung, Performance, Zuverlässigkeit. Wir sind jetzt hier so ein bisschen auch quasi schon bei den Softwarequalitätsmerkmalen aus der ISO-Norm.

[7:32] Ich muss jetzt so ein bisschen aufpassen, dass sich das hier nicht nur auf Softwareentwicklung bezieht. Das ist natürlich meine Stärke, keine Frage. Aber für alle anderen IT-Berufe ist es natürlich genauso. Es wird irgendeinen Endbenutzer, Endbenutzerin geben. Wenn ich als FISI ein neues System aufsetze, was auch immer mir da jetzt ein Fall fällt, ich installiere ein neues Active Directory, dann sind meine Endbenutzerinnen halt meine Admin-Kollegen, die den ganzen Tag damit arbeiten. Dann wollen die auch, dass das einfach zu bedienen ist, performant läuft und zuverlässig. Also es geht hier nicht nur um Softwareentwicklung, auch wenn sich viele Beispiele bei mir mal drauf beziehen. Also, die haben so Usability-Anforderungen mindestens mal an die Software. So, was haben wir noch für Stakeholder?

[8:11] Projektleitung. Naja, in deinem eigenen Projekt bist du das, aber auch du darfst natürlich Anforderungen an dein Projekt stellen. Das vergessen auch ganz viele. Es sind ja nicht immer nur Leute, die von extern kommen und sagen, ich will da was, sondern du als Umsetzende hast natürlich auch Anforderungen. Und bei der Projektleitung sieht man das. Zum Beispiel Planungssicherheit für dein IHK-Projekt von höchster Wichtigkeit. Du hast 80 oder 40 Stunden, mehr nicht. Wenn du jetzt irgendwas einplanst und deine Kollegen, Kolleginnen verspäten sich, externe Dienstleister kommen nicht in eine Pötte, was auch immer, und auf einmal sind deine 80 oder 40 Stunden bedroht, das ist schlecht, weil dann könntest du im Extremfall durch die Prüfung fallen. Das heißt, Planungssicherheit wäre vielleicht ganz wichtig und auch in echten Projekten natürlich, wollen die Leute, wenn am 1.1. Eingeführt werden soll, nicht, dass es erst am 3.1. fertig ist, ist klar. Ja, Risikominimierung, Reporting ist vielleicht auch interessant. Ich mache jetzt hier ein paar allgemeine Punkte, nicht nur fürs IHK-Projekt, deswegen ist davon vielleicht nicht alles relevant. Aber es gibt zum Beispiel auch Projekte in großen Konzernen, die umgesetzt werden. Da muss dann zum Beispiel auch ein Reporting stattfinden, irgendwie an den Vorgesetzten oder an die IT-Betriebsabteilung, dass da jetzt eine neue Ablikation fertig ist oder was auch immer. Das müsste man auch mit einplanen vielleicht.

[9:21] So, nächster Stakeholder oder Stakeholderin. Entwicklerinnen bzw. Die Admins, die ich gerade schon angesprochen habe. Also die, die die Systeme entweder weiterentwickeln oder im Betrieb nachher täglich sich drum kümmern müssen. Und die wollen dann zum Beispiel wartbaren Code. Ich will nicht irgendeine Grütze und heutzutage vor allem irgendeinen KI-Slop, der dahin generiert wurde und dann kümmert sich irgendwer anders die nächsten fünf Jahre darum, den Scheiß wieder aufzuräumen. Ich will jetzt nicht auf KI bashen. KI macht schon coolen Code. Auf jeden Fall geht es mir allgemein darum, wartbarer Code, damit nicht die nächsten fünf Jahre sich irgendwer jeden Tag die Haare ausreißt, wenn er diesen Code betreuen muss. Und stabile Systeme für die Upmands. Die wollen nicht fünfmal am Tag ein Server neu starten, weil du es schlecht programmiert hast oder schlecht installiert hast. Das wären so Beispiele für deren Anforderungen. Machen wir das konkret. Anwendungsentwicklerinnen, was wollen die noch haben? Die haben vielleicht auch UX, UI-Anforderungen. Das soll ja irgendwie schick aussehen zum Beispiel und natürlich gut bedienbar sein. Vielleicht haben wir Barrierefreiheit, dass wir mit einbauen müssen. Die Anwendungsentwicklung möchte natürlich, wenn du eine API baust, dass die stabil ist, dass sie sich nicht alle zwei Tage ändert. Oh, ich habe noch ein Parameter vergessen, tut mir leid. Das Ding soll natürlich testbar sein. Ich will nicht händisch alles durchklicken müssen nach einem Release, um zu gucken, ob es läuft. Ich will Unit-Tests anstellen oder ich brauche eine Bild-Pipeline, wo das durchläuft. Ich will das Ding automatisch deployen können. Ich will nicht einen Zip-File irgendwo hart auf der Produktion entpacken und dann in alten Ordner löschen und hoffen, dass alles läuft. Ich will einen definierten Deployment-Prozess zum Beispiel haben.

[10:43] Gehen wir konkret auf den nächsten Stakeholder, die Systemintegration. Was wollen die? Die wollen vielleicht von ihren Systemen, was auch immer, da geht es häufig um kritische Sachen wie Firewalls, Backup-Lösungen etc. Die wollen natürlich eine hohe Verfügbarkeit haben. Die wollen das Ding vielleicht skalieren können, wenn es zu langsam wird. Die brauchen natürlich ein Monitoring, ob das Teil noch läuft. Die wollen Alerts haben, wenn es nicht mehr läuft und so weiter. Das kann man alles auf harte Anforderungen auf dein Projekt ummünzen.

[11:07] Beispiel API-Stabilität für Anwendungsumwicklung. Da muss ich mir vielleicht mal vorher Gedanken machen, wie die API aussieht und nicht einfach irgendwas entwickeln und hoffen, dass ich nichts vergessen habe. Oder Monitoring. Muss ich halt dran denken, wenn ich eine Software zum Beispiel auswähle als Systemintegratorin, dass sie vielleicht auch definierte Standardschnittstellen anbietet, um in mein Monitoring-System eingehängt werden zu können und ich mir dann nicht irgendwie selber was zusammenzimmern muss.

[11:29] Dann, IT-Betrieb und Support wird häufig vergessen. Das Ding wird, wenn ich das eingeführt habe, normalerweise vielleicht ein bisschen laufen. Außer ich schmeiße das Projekt sofort weg, wenn es fertig ist. Aber ich hoffe nicht, dass das passiert. Das heißt, es wird vielleicht Jahre im Betrieb sein. Und in der Zeit, wer kümmert sich? Naja, wer ist erster Ansprechpartner, Ansprechpartnerin für unsere Mitarbeitenden oder die Kunden? Der Support. Und die wollen natürlich auch, dass das Ding wartbar ist. Die haben jetzt nicht Code-Wartbarkeit im Hintergrund, aber zum Beispiel, keine Ahnung, Das Ding legt ständig irgendwelche Temp-Dateien an, die ich händisch löschen muss. Wäre blöd, vielleicht sollte das Teil das lieber selber aufräumen. Ganz wichtig für den Betrieb, irgendeine Form von Logging, dass da irgendwie genau protokolliert wird, was ist schiefgelaufen, was war der Fehler, damit man im Fehlerfall auch reagieren kann und weiß, was passiert ist. Und natürlich auch die Dokumentation. Irgendwo ist ein Fehler, was ist jetzt überhaupt der Prozess, wen kann ich anrufen, wie kann ich das Ding, darf ich das Ding einfach neu starten oder muss ich bestimmte Schritte der Reihe nach durchführen? Also eine klassische Dokumentation, ganz wichtig für diesen Bereich.

[12:26] So, und jetzt kommen wir so ein bisschen zu Stakeholdern, die eher mal vergessen werden oder gar nicht auf dem Zettel sind, dass die überhaupt gibt. Und wir sind nun in der EU, zumindest in Deutschland, da gilt natürlich die DSGVO. Das heißt, Oberpunkt Datenschutz bzw. Compliance noch etwas weiter befasst. Und da gibt es, je nachdem, in welchem Unternehmen du arbeitest, hunderte von Vorgaben. Also, Datenschutz sind nur ein paar, aber zusätzlich, wenn man Compliance noch mit dazu nimmt, gibt es ja die wildesten Vorschriften und Regeln, die man einhalten muss. Das geht von erzwungene Code-Reviews, wenn du was programmierst oder Vier-Augen-Prinzip oder jetzt ganz neu die DORA, der Digital Operational Resilience Act. Du musst vielleicht sogar ein Monitoring mit einbauen, weil die EU das jetzt fordert für dein Projekt. Das heißt, da können solche Sachen rauskommen wie DSGVO-Konformität, Datensparsamkeit. Du darfst nicht einfach alles erfassen, was du willst. Du musst vielleicht explizit Zugriffskontrollen, Monitoring, Resilience-Zeug einbauen, weil irgendeine Vorgabe das von dir erfohlen wird. Ganz harte Vorgaben tatsächlich auch für Softwareprojekte.

[13:28] Um das noch weiter zu führen, Staat und Gesetzgeber würde ich darüber hinaus nochmal sehen, weil je nach Branche hast du auch ganz harte gesetzliche Vorgaben. Ich bin jetzt in einer privaten Krankenversicherung, da kommt gefühlt jedes Jahr irgendein neues Gesetz raus, das wieder irgendwelche harten Vorgaben für unsere Produkte und für unsere Softwareentwicklung insbesondere macht. Wir haben ganz neu, als ich das hier aufnehme, das Barrierefreiheitsstärkungsgesetz. Das heißt, du wirst eventuell verpflichtet, deine Software barrierefrei zu bauen oder, wenn du zum Beispiel fisi bist, eine auszuwählen, die barrierefrei ist, weil dein Unternehmen eben barrierefreie Sachen anbieten muss. Oder natürlich ganz klassisch Aufbewahrungspflichten, wenn du vom Finanzamt gefragt wirst, was war denn vor neun Jahren auf der Rechnung? Ja, da brauchst du vielleicht ein Archiv, ein revisionssicheres Archiv eventuell sogar für deine Daten. Das können alles harte Anforderungen vom Gesetzgeber sein. Und dann haben wir noch so eine Rolle im Unternehmen. Datenschutzbeauftragte hatten wir gerade schon, aber es gibt vielleicht auch Sicherheitsverantwortliche, die genaue Vorgaben machen für Zugrissschutz, für erzwungene Verschlüsselung vielleicht, für Pentests, die gemacht werden müssen, bevor so ein System online gehen kann. Ja, kann ja sein, was auch immer. Als Fisi suchst du dir eine neue Firewall aus, die du installierst, hast aber nicht daran gedacht, die zu patchen oder irgendwelche Sicherheitssachen richtig einzustellen. Dann wäre es ganz gut, wenn die zentrale Firewall des Unternehmens vielleicht, bevor sie live geht, mal so einen Pentest bekommen von externen, um zu gucken, dass du wirklich an alles gedacht hast. So, und das muss aber eingeplant werden. Das kostet Geld, das kostet Zeit, das muss alles mit in deine Projektplanung rein. Also, noch ein Punkt, an den man denken könnte.

[14:56] Und dann, das finde ich besonders interessant immer, der Kulturkreis. Das ist auch ein toller Stakeholder, denn wenn wir zum Beispiel in Deutschland unsere Software programmieren, dann ist ja für uns selbstverständlich, dass wir von links nach rechts lesen. Aber wenn wir zum Beispiel internationale Software bauen, weil wir in einem Konzern arbeiten und die Software wird weltweit eingesetzt, wie ist es denn dann mit Sprache? Muss das einfach nur übersetzt werden oder müssen wir vielleicht sogar die ganze Schreibrichtung ändern, von links nach rechts nach rechts nach links? Ich glaube, ich bin jetzt nicht so der Sprachexperte, aber ich glaube, Arabisch wird zum Beispiel von rechts nach links gelesen. Und ich meine, Japanisch oder Chinesisch wird auch, wie auch immer, wird von oben nach unten gelesen. Also spaltenweise, glaube ich. Korrigiert mich gern, wenn das falsch ist. Und da muss ich vielleicht meine ganze Software umgestalten, je nachdem, in welchem Land die gerade ausgerollt wird. Und ganz klassisch natürlich Datumsformate, Zahlenformate. Da ist ja, je nachdem, in welchem Land man ist, wird alles irgendwie unterschiedlich gemacht. Gemacht, insbesondere natürlich USA versus Europa, die allein die Datumsformate, also mich macht sowas immer verrückt. Wie kann man den, wie schreiben die das? Monat, Tag, Jahr, also das beknackteste Datumsformat ever.

[16:00] Oder kann man vielleicht überall einfach ISO-Datumsformat nehmen, das einzig Vernünftige. Je nachdem, wo ich mich befinde, kann es halt unterschiedlich sein. So, wen haben wir noch? Management oder Geschäftsführung dürfen wir auch nicht vergessen. Die wollen, dass sich das Ding irgendwann amortisiert. Hey, das machst du nicht nur für die IHK-Prüfenden, weil wenn du deinen Chef in Zukunft fragst, hey, darf ich dieses Projekt umsetzen, wird er auch als erstes fragen, was kostet das denn? Bzw. eigentlich, wenn ein schlauer Chef ist, was bringt uns das denn? Spart uns das Geld? Wann amortisiert sich das Ding? Ja, also Return on Investment ist hier das Stichwort. Wie gut, dass du eine Amortisationsrechnung für dein Projekt machst, nicht wahr? Ja, so außerdem gucken wir natürlich auf strategische Ziele, passt das Projekt gut in unser Budget, in unser Portfolio, nennt man es ja auch gerne, ist das überhaupt sinnvoll für das Unternehmen da zu investieren zum Beispiel und vielleicht auch Skalierbarkeit, ne, wenn die zum Beispiel sagen, ja mach mal hier die neue Ticket-Software für Eventim, ja, dann sollte die vielleicht skalieren zu Weihnachten zum Beispiel, ne.

[16:55] So, zwei habe ich noch. Externe Dienstleister. Wenn du mit irgendjemandem zusammenarbeitest, vielleicht gerade in FISI-Projekten, die stellen dir, weiß ich nicht, Hardware bereit oder installieren dir das Server oder die Cloud-Infrastruktur oder was auch immer. Da ist natürlich wichtig, Schnittstellen. Wie kommuniziert ihr? Gibt es technische Schnittstellen? Gibt es schriftliche Schnittstellen? Per E-Mail, Telefon, was auch immer. Sowas muss natürlich festgelegt werden. Gibt es Service-Level-Agreements, die ihr aushandeln müsst, vielleicht sogar während deiner Projektzeit. Das sind alles Themen, die mit externen geklärt werden müssen, mit internen vielleicht nicht so. Und letzter Punkt, Und vielleicht limitierender Faktor Hardware, beziehungsweise die vorhandene Infrastruktur. Das ist weder ein Mensch noch eine Institution, aber kann trotzdem ein Stakeholder sein. Denn wenn du da eben einen dicken Server hast, aber keinen zweiten, dann muss deine Applikation sich vielleicht daran orientieren, dass sie darauf läuft, dass sie die Ressourcen sparsam einsetzt und so weiter. Also vielleicht hast du konkrete Limitierungen. Deine Software darf maximal zwei CPUs benutzen, weil mehr haben wir nicht frei im VMware Cluster. Kann ja sein. Also Limitierung durch CPU oder RAM. Oder Netzwerklatenzen. Vielleicht habt ihr, keine Ahnung, nur eine Remote-Dial-In-Verbindung, weil deine Software am Südpol läuft. Ich weiß es nicht. Dann gibt es vielleicht Probleme mit der Netzwerklatenz und du musst darauf achten, dass du hohe Timeouts in deine Software einbaust oder so etwas. Und Storage natürlich. Vielleicht ist die nicht unendlich groß oder du protokollierst oder erzeugst riesengroße Datenmengen. Die müssen vielleicht auch irgendwo abgelegt werden können. Dafür brauchst du vielleicht genug Speicherplatz.

[18:19] Also, wir haben jetzt ganz viele Stakeholder gehört. Ich wiederhole nochmal kurz. Kunde, Kundin, Endbenutzerin, Projektleitung, Entwickler oder Administratoren. Dann haben wir den IT-Betrieb, Datenschutz, Staat und Gesetzgeber.

[18:32] Sicherheitsverantwortliche, Kulturkreis, Management, externe Dienstleistende, Hardware. Das sind so meine, die mir so eingefallen sind. Wahrscheinlich gibt es noch mehr, aber du siehst, es gibt nicht nur einen Stakeholder, sondern ein paar mehr, an die du denken musst unbedingt bei deinem Projekt. Denn sonst vergisst du vielleicht hinten was und hast eben kein qualitatives Projekt. denn wir erinnern uns Qualität, Übereinstimmung mit den Anforderungen.

[18:56] So, wie machst du das jetzt konkret für dein Projekt? Nummer eins, sammel erstmal die Stakeholder. Wer könnte Interesse an deinem Projekt haben? Heißt ja nicht, dass sie es haben müssen, aber erstmal eine Liste aufstellen, an wen du denken könntest. Und dann kannst du dir ja vielleicht schon mal sogar gruppieren. Beispiel, intern oder extern. Was sind Leute, mit denen ich eh zusammenarbeite? Da sind die Anforderungen vielleicht, ja, was auch immer die Folge ist. Vielleicht sind sie wichtiger als die externen, vielleicht unwichtiger. Das ist halt die Frage, wie du es jetzt gruppierst. Das kann ich für dein Projekt natürlich nicht vorgeben, was da sinnvoll ist. Das ist nur ein Beispiel, wie du das machen könntest. Und dann könntest du je nach Gruppe dir die Anforderungen abholen. Vielleicht hast du eine Person, die sogar mehrere Stakeholder abdeckt, weil sie gleichzeitig Kundin und Endbenutzerin ist. Als Beispiel könnte ja sein. Oder gleichzeitig Kundin und Management könnte ja auch sein. Dann sparst du dir quasi mit jedem einzelnen Menschen zu sprechen. Kannst du sowieso nicht. Du musst ja immer, wenn du zum Beispiel für 300 Benutzerinnen was programmierst, kannst du nicht mit 300 Leuten reden. Dann musst du sowieso eine Auswahl treffen. Ja, also gruppier die vielleicht, such dir dann passende Repräsentationen dieser Gruppen, zum Beispiel eine Key-Userin, die auch sonst in Firmenprojekten immer gut oder Eingebungen macht für Benutzerfreundlichkeit oder so. Dann fragst du die einfach, weil die kann das gut oder denkt an viele Sachen oder so.

[20:10] Also such dir die konkreten Personen raus oder wenn es keine Personen sind, such dir die konkreten Gesetze raus oder frag jemanden, der sich mit diesen Gesetzen auskennt. Stichwort Sicherheitsbeauftragter, Datenschutzbeauftragter etc. Und dann fragst du die einfach, Oder machst andere Dinge, um an die Anforderung zu kommen? Und ich glaube, das wird eine weitere Podcast-Episode, denn da habe ich mindestens zehn verschiedene Wege, wie man an diese Anforderung rankommt. Aber das soll heute nicht das Thema sein. Oft wird es halt vielleicht für so ein Projekt einfach erstmal ein Gespräch sein. Erzähl mir doch mal, was du haben willst. Also, hol dir die Anforderung von diesem Stakeholder, schreib die auf, priorisiere die, formuliere die einheitlich und dann hast du schon mal das erste Artefakt für deine Projektarbeit, nämlich etwas wie ein Lastenheft, hatte ich eingangs schon gesagt. Und dann sind wir weiter bei der Anforderungsanalyse, aber das schaffen wir heute auch alles nicht mehr. Du kannst dir angucken, gibt es widersprüchliche Anforderungen? Was sind denn jetzt die wichtigsten? Was sind muss, kann, sollte, nicht Anforderungen? Ja, das geht dann alles noch seinen Weg. Aber heute ging es ja erstmal darum, überhaupt an die Stakeholder zu denken und da ranzukommen. Und ich denke, das soll jetzt erstmal reichen für heute. Zum Abschluss ein kleines Mini-Beispiel. Angenommen, du baust eine klassische Web-App als Anwendungsermittlerin.

[21:15] Da hast du sicherlich mindestens mal Benutzerinnen. Die wollen vielleicht eine einfache UI. Du hast auf jeden Fall irgendeinen Admin, der was haben will. Sei es Security-Einschränkungen, Rechteverwaltung, Logging zum Beispiel. Der aber auch, oder das aber auch für den Betrieb natürlich interessant ist. Und natürlich hast du automatisch sowas wie den Staat, der dir das GVO vorgibt. Wenn du zum Beispiel eine Person mit zu den Daten hast, dann musst du die einhalten. Punkt. Da gibt es gar keine Widerrede. Du musst es einhalten. Es ist gesetzliche Vorgabe. So, das sind schon mal ein paar, die anfallen bei einem kleinen Mini-Web-App-Projekt.

[21:48] Und zum Fazit heute, ganz wichtig, denk bei deinem Projekt dran, es gibt viele potenzielle Stakeholder, nicht nur der oder die Kundin ist Stakeholder oder der oder die Benutzerin, sondern es gibt noch viele andere. Schau dir meine Liste nochmal an, überlege, was ist für dein Projekt sinnvoll, welche gibt es da, welche Personen sind auch entsprechend in der Rolle und wen kannst du fragen über diese Anforderungen. Denn die Anforderungen entscheiden über deinen Projekterfolg. Der Erfolg definiert sich danach, wie gut du die Anforderungen deiner Stakeholder umgesetzt hast. Also, es lohnt sich, da ein bisschen Zeit zu installieren, zu investieren. Ich bin schon hier, ich bin schon im Fiesi-Slagging angekommen. Also, mach dir eine Liste, sprich mit den Leuten und vergiss keine Anforderungen. Das ist ein Hauptgrund, warum Projekte scheitern, weil einfach Anforderungen nicht richtig umgesetzt wurden oder gar nicht umgesetzt wurden.

[22:39] So, ich hoffe, das hilft dir ein bisschen bei deiner Projektarbeit. Ich wünsche dir viel Erfolg bei Projektdokumentation und Präsentation und bis zum nächsten Mal.

Um „Eh-Da-Kosten“ und laufende Kosten bei der Projektarbeit geht es in der siebten Episode der Shorts des IT-Berufe-Podcasts.

Ich zeige dir, dass du in der Kostenbetrachtung deines Abschlussprojekts nicht nur neu angeschaffte Dinge einplanen solltest, sondern auch vorhandene Ressourcen wie Arbeitszeit, Server, VMs oder Lizenzen. Solche „EDA-Kosten“ sind nicht kostenlos, weil sie Ressourcen binden und damit Opportunitätskosten verursachen. Außerdem solltest du laufende Kosten wie Betrieb, Wartung, Strom, Lizenzen oder Support immer mit berücksichtigen und dir dafür möglichst Pauschalen oder Stundensätze aus deinem Unternehmen geben lassen.

Inhalt Worum es mir geht

Ich zeige dir, dass in Projektdokumentationen und Präsentationen oft wichtige Kosten vergessen werden. Dadurch wirkt ein Abschlussprojekt schnell zu günstig oder amortisiert sich unrealistisch schnell. Für eine realistische Kostenbetrachtung solltest du nicht nur neu angeschaffte Dinge berücksichtigen, sondern alle Kosten, die durch dein Projekt entstehen.

Vorhandene Ressourcen sind nicht kostenlos

Ein häufiger Fehler ist die Annahme, dass vorhandene Ressourcen nichts kosten, nur weil sie schon im Unternehmen da sind. Genau darum geht es bei den sogenannten "EDA-Kosten":

• der Server ist schon da
• die Lizenz ist schon bezahlt
• der/die Kolleg:in ist sowieso im Unternehmen
• du erhältst ohnehin deine Ausbildungsvergütung

Ich mache klar: Das ist keine sinnvolle Rechnung. Alles, was du für dein Projekt nutzt, kostet Geld und muss letztlich von Kund:innen mitfinanziert werden.

Opportunitätskosten

Ein wichtiger Gedanke dabei sind die Opportunitätskosten, also die Kosten der entgangenen Gelegenheit.

Beispiele:

• Wenn ein:e Softwareentwickler:in zwei Stunden deinen Code reviewt, kann diese Person in der Zeit nichts anderes für das Unternehmen leisten.
• Wenn dein Projekt auf einem vorhandenen Server läuft, stehen CPU, RAM, Storage oder Netzwerkkapazität nicht mehr vollständig für andere Anwendungen zur Verfügung.
• Wenn eine VM im Cluster Ressourcen belegt, können diese Ressourcen nicht für andere VMs genutzt werden.

Auch wenn diese Ressourcen schon vorhanden sind, entstehen deinem Projekt dadurch also reale Kosten.

Kosten fair und anteilig umlegen

Ich erkläre, dass Kosten nicht zufällig bei einem einzelnen Projekt landen dürfen. Wenn mehrere Projekte dieselbe Infrastruktur nutzen, sollten die Kosten fair verteilt werden.

Beispiel:

• Wenn auf einem Server bereits zehn Projekte laufen und durch das elfte ein neuer Server nötig wird, darf nicht nur dieses elfte Projekt die gesamten Kosten tragen.
• Stattdessen müssen die Kosten anteilig auf alle Projekte umgelegt werden, die diese Ressource nutzen.

Das gilt auch für:

• Server
• VMs
• Lizenzen
• Arbeitszeit von Kolleg:innen
• andere gemeinsam genutzte Ressourcen

Kosten nicht selbst im Detail berechnen

Ich empfehle dir, diese Kosten möglichst nicht selbst bis ins kleinste Detail auszurechnen. Besser ist es, dir Werte aus dem Unternehmen geben zu lassen, zum Beispiel von:

• Personalabteilung
• IT-Betrieb
• Rechnungswesen
• Buchhaltung
• Controlling

Sinnvoll sind zum Beispiel:

• Stundensätze für Mitarbeiter:innen
• Pauschalen für VMs oder Serverbetrieb
• Gemeinkostensätze
• anteilig umgelegte Lizenzkosten

So zeigst du, dass du an die Kosten gedacht hast, ohne unnötige Rechenfehler einzubauen.

Laufende Kosten nicht vergessen

Ein weiterer häufiger Fehler ist, nur die einmaligen Projektkosten zu betrachten. Ich mache deutlich, dass IT-Projekte fast immer auch laufende Kosten verursachen.

Dazu gehören zum Beispiel:

• Stromkosten
• Wartung
• Updates
• Lizenzkosten
• Cloud-Kosten
• Support-Verträge
• Betriebsaufwand durch Admins

Diese Kosten fallen auch nach Projektende weiter an. Wenn du sie nicht berücksichtigst, wird die Amortisationszeit zu kurz dargestellt und die Kalkulation unrealistisch.

Warum das für die Amortisation wichtig ist

Ich betone, dass eine längere Amortisationszeit nicht schlimm ist. Problematisch ist vielmehr, wenn laufende Kosten weggelassen werden. Dann scheint das Projekt wirtschaftlicher, als es tatsächlich ist. Auf Dauer würde ein Unternehmen Verluste machen, wenn solche laufenden Kosten bei allen Projekten ignoriert würden.

Beispiele für mögliche Kosten Für Systemintegration

Mögliche Kosten können sein:

• Server oder VM-Ressourcen
• CPU, RAM und Storage
• Backup-Systeme
• Monitoring
• Arbeitszeit von Admins für Einrichtung, Betrieb und Wartung

Für Anwendungsentwicklung

Mögliche Kosten können sein:

• IDE-Lizenzen
• weitere Software-Tools
• Testsysteme oder Staging-Systeme
• Datenbanken
• CI/CD-Pipelines oder Build-Server
• genutzte Infrastruktur-Ressourcen

Für andere IT-Berufe gilt sinngemäß dasselbe.

Meine Empfehlung für deine Projektdokumentation

Ich würde dir empfehlen:

1. Erstelle zuerst eine Liste aller genutzten Ressourcen.
2. Prüfe dann, welche Kosten dafür im Unternehmen angesetzt werden.
3. Nutze möglichst Pauschalen, Stundensätze oder Gemeinkosten statt eigener Detailrechnungen.
4. Berücksichtige sowohl einmalige als auch laufende Kosten.
5. Lege gemeinsam genutzte Ressourcen bei Bedarf anteilig auf dein Projekt um.
6. Verwende diese Werte anschließend für eine realistische Amortisationsrechnung.

Fazit

Meine Kernaussage ist: Nicht nur neue Anschaffungen verursachen Kosten, sondern auch alles, was bereits vorhanden ist und von deinem Projekt genutzt wird. Vorhandene Ressourcen sind nie kostenlos. Zusätzlich solltest du immer laufende Kosten mit einplanen. Wenn du das sauber machst, wirkt deine Kostenbetrachtung realistischer und vollständiger.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Betriebsabrechnungsbogen (BAB) für die IT-Berufe (AP1 und AP2)

Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode

[0:20] Heute möchte ich mich mal mit einem Thema beschäftigen, was ich sehr häufig falsch in Anführungszeichen in Projektdokus und Präsentationen wähle. Und zwar das Thema der EDA-Kosten, beziehungsweise auch der laufenden Kosten. Und ich bringe noch ein Passwort mit rein, die Opportunitätskosten. Heute soll es also um die Kostenbetrachtung deines Abschlussprojekts gehen. Und wir haben da oft ein Problem, dass nicht alle Kosten betrachtet werden. Und dass das Projekt sich dann super schnell amortisiert oder halt viel zu geringe Kosten einfach hat, um das irgendwie realistisch einplanen zu können in so einem Unternehmen. Und deswegen will ich da heute einmal kurz darauf eingehen, was da häufig vergessen wird, was das überhaupt ist, was ich damit meine und wie man das dann besser machen könnte. Also Nummer eins, es geht darum, bei deiner Projektarbeit dein Projekt auch realistisch einzuschätzen, was die Kosten angeht. Du sollst ja nicht einfach sagen, ja, ich habe da 80 Stunden als Zubi daran gesessen. Ich bin ja eh im Unternehmen, die bezahlen mir Ausbildungsvergütung. Ja, ich habe da so ein bisschen rumprogrammiert und ich habe da so ein paar Server installiert und ja, das hat das Unternehmen am Ende eigentlich nichts gekostet.

[1:20] Nee, so ist es nicht. Sondern alles, was du für dein Projekt machst und was auch im Unternehmen für dein Projekt gemacht wird, bereitgestellt etc., kostet irgendetwas. Das Geld dafür muss irgendwo herkommen. Auch deine Ausbildungsbegütung bezahlt ja irgendwer am Ende. Und ich spoiler schon mal, wer das macht, eure Kunden bezahlen das. Dein Chef überweist dir das zwar, aber der kriegt das Geld ja auch nicht aus dem, das fällt ja auch nicht vom Himmel, sondern das kommt von den Kunden, die am Ende dann eure Produkte kaufen oder eure Dienstleistungen in Anspruch nehmen, eure Waren kaufen, was auch immer. Und alle diese Kosten an deinem Projekt müssen auf die Kosten für die Kunden umgelegt werden, damit die am Ende das Ding bezahlen. Weil das Geld fällt nicht vom Himmel, auch wenn man das vielleicht glaubt. Das ist nicht so, das muss erwirtschaftet werden. Und ja, dein Projekt verursacht Kosten und die musst du einplanen. Und heute gehe ich mal auf die Kosten ein, die dabei gerne vergessen werden. Weil, was so die low hanging fruit ist, ich habe als Anwendungsentwickler zum Beispiel 80 Stunden gearbeitet, also plane ich mich 80 Stunden ein. Oder als Systemintegrator plane ich mich 40 Stunden ein. Ja, okay. Offensichtlich sind das Kosten natürlich anfallen, aber es gibt noch ganz viele mehr. Und da geht es halt eben nicht nur darum, was extra für dein Projekt zum Beispiel gekauft wurde. Also wenn extra für dein Projekt eine Hardware angeschafft wurde, ein Server gemietet wurde oder sowas. Das ist natürlich offensichtlich. Aber mir geht es heute um die vielleicht etwas versteckten Sachen, an die ganz viele Prüflinge leider nicht denken. und das sehe ich dann immer in den Dokus. Und zwar, ähm.

[2:42] Geht es mir um diese E-Da-Kosten. Das ist jetzt kein Fachbegriff. Ich weiß gar nicht, wo ich den selber mal gehört habe. Ich glaube, irgendwo im Rechnungswesenunterricht oder Vorlesung mal irgendwo. Also es geht darum, Dinge, die E-Da sind. Also es ist keine Abkürzung, sondern du formulierst das so, ja, der Server, der ist ja E-Da. Der steht ja unten im Keller, den haben wir ja E. Dann lasst uns doch nochmal eben mein Projekt da mit drauf installieren und fertig. Dann haben wir keine Kosten quasi. Also die Dinger sind ja E-Im-Unternehmen. Der Kollege sitzt da E. Der kriegt sein Gehalt. ja, also der muss ja nicht nur für mein Projekt jetzt mehr Geld bekommen. Deswegen, ja, EDA kostet nichts. Und das sind meine sogenannten EDA-Kosten. Und das ist leider Quatsch. Denn auch wenn die EDA sind, machen wir mal jetzt verschiedene Beispiele, den Softwareentwickler, der am Ende dein Projekt reviewen soll, ja. Der sitzt da vielleicht zwei Stunden dran. Und ja, der ist eh im Büro, die zwei Stunden. Aber in diesen zwei Stunden kann er ja nichts anderes machen, weil er ja deinen Code reviewt zum Beispiel, ne. Und das nennt man dann sogenannte Opportunitätskosten. Opportunity auf Englisch, Gelegenheit. Und das sind die Kosten der entgangenen Gelegenheit. Das heißt, während dieser Softwareentwickler zwei Stunden deinen Code reviewt, kann er eben nicht richtig coole Software fürs Unternehmen programmieren, mit der dann richtig Geld gemacht wird, sondern die zwei Stunden seiner Arbeitszeit sind dann halt weg, weil sie für dein Projekt draufgegangen sind. Oder machen wir was für die Systemintegratoren.

[3:59] Wir haben irgendwo einen Server stehen, auf dem eine neue Firewall installiert werden soll. Wenn die Firewall da läuft, kann der Server halt nicht noch 37 andere Applikationen hosten, Weil der vielleicht, keine Ahnung, so starkes Netzwerk eingebunden ist, dass gar keine andere Applikation mehr laufen kann, weil die gar keinen Netzwerktraffic mehr abkriegt. Oder die Firewall blockiert so viel CPU, dass einfach andere Applikationen auf dem Server nicht mehr laufen können. Und das heißt, der Server könnte für was anderes benutzt werden, wird er aber nicht, weil dein Projekt jetzt drauf läuft. Also sind das natürlich Kosten, die für dein Projekt anfallen. Auch wenn der Server eh schon da ist und nicht nochmal angeschafft werden muss. Aber jedes neue Projekt, was ich auf einen Server, ich bleibe jetzt mal bei dem Beispiel, installiere, belastet ja den Server. kostet CPUs, kostet RAM, kostet Strom und da kann in der Zeit halt vielleicht nichts anderes auf dem Server laufen, weil da ein Projekt draufläuft. Und jetzt überlegen wir mal weiter. Angenommen, alle Projekte würden das so machen. Ja, der Server ist ja eh da. Komm, ich installiere das mal mit drauf. Was glaubst du, wie lange kann man das machen? Also wie viele, ich sage jetzt mal, Software-Nemikungsprojekte, Web-Anwendungen oder so, kann ich auf dem Server installieren, bis der dann irgendwann mal die Grätsche macht, weil er eben keine CPU-RAM, was er auch immer mehr frei hat. Das kann man ja nicht unendlich betreiben. Die sind ja nicht unendlich skalierbar, diese Ressource, nur weil sie da sind.

[5:04] Und dann passiert Folgendes. Auf dem Server habe ich zehn Projekte laufen. Jetzt kommt das elfte Projekt und mit diesem elften Projekt kommt der Server jetzt an seine Grenzen. Was müssen wir machen? Neuen Server kaufen. Und wird jetzt die Anschaffung, der Anschaffungspreis für diesen Server, wird das jetzt auf dieses elfte Projekt gelegt. Das heißt, das elfte Projekt hat leider Pech gehabt, weil es aus Versehen das elfte Projekt war und hat jetzt zufällig einen neuen Server quasi zur Folge und muss dieses Projekt jetzt den kompletten Server bezahlen, einfach nur, weil es in der Reihenfolge zufällig an der falschen Position war. Sorry, so kann man noch nicht rechnen. Das geht nicht. Das heißt, jedes Projekt, jedes der elf Projekte muss anteilig diese Serverkosten tragen. Und das elfte übernimmt natürlich nicht die kompletten Kosten für den neuen Server, auf dem dann noch neun andere Applikationen wieder installiert werden können. Das muss natürlich verteilt werden. Und um wieder bei der Systemintegration auch mal ein Beispiel zu finden. Wir haben eine neue VM, die wir brauchen. Meintwegen die Firewall, da wird nichts mehr Hardware installiert, lassen wir auf einer VM laufen. Aber auch die VM braucht ja Ressourcen. Die blockiert vielleicht CPUs oder RAM im VMware-Cluster, der teuer lizenziert wird. Und für diese blockierten CPUs und RAM kann halt eben keine andere VM irgendwas anderes machen, was Geld einbringt zum Beispiel. Das heißt, diese Sachen kann man nicht einfach unter den Tisch fallen lassen. Die müssen einkalkuliert werden. Die müssen meistens anteilig einkalkuliert werden, weil halt meine Applikationen oft nicht die einzige auf dem Server ist. Da laufen halt noch andere. Aber ich darf diese Kosten halt nicht unter den Tisch fallen lassen.

[6:25] Es darf nicht Zufall sein, welches Projekt die Kosten trägt. Das muss fair sein, verteilt werden, anteilig über die Nutzung aller Projekte, die diese Ressource, ob es ein Mitarbeiter ist oder ein Server oder was auch immer. Meinetwegen auch eine Lizenz, die lese ich ja auch ganz oft bei Software-Mitglungs-Projekten, die ich ja nun mal hauptsächlich lese. Ja, wir haben eine IntelliJ-Lizenz, die packe ich zwar in meine Liste der Ressourcen, aber dafür setze ich keine Kosten an, weil die habe ich ja eh. Die IntelliJ-Lizenz kostet irgendwie, keine Ahnung, 1000 Euro im Jahr, aber für mein Projekt war die kostenfrei, weil die ist ja schon bezahlt. So kann man das, wie gesagt, nicht rechnen. Man muss das umlegen, anteilig. Ich spoilere das schon mal. Genau das ist die Lösung. Anteilig auf deinem Projekt umlegen. Das musst du im Zweifel auch nicht selber machen. Also keiner erwartet von dir in deiner Projektdokumentation, dass du jedes einzelne kostenanteiligstes Teilchen, was dir irgendwie einfällt in deinem Projekt, genau umlegst und Cent genau ausrechnest und so weiter. Dafür gibt es hoffentlich Mitarbeiter, Mitarbeiterinnen in deinem Unternehmen, die das machen, zum Beispiel im Rechnungswesen, in der Buchhaltung, im Personal, wo auch immer. Und die sagen dir dann einfach, was das pauschal kostet. So würde ich dir auch dringend empfehlen, das zu machen. Bitte berechnet das nicht selbst, da kannst du nur irgendwas vergessen, irgendwelche Fehler einbauen, noch eine Rundungsdifferenz und du hast irgendwas vergessen und das nehmen dir die Prüfenden dann auseinander, sondern lass dir einfach die Zahlen geben. Frag in der Personalabteilung, was kostet mich ein Softwareentwickler, eine Softwareentwicklerin pro Stunde?

[7:46] Zwei Stunden Code Review mal diesen Stundensatz, das sind die Kosten. Ende. Frag in deinem IT-Betrieb, in deinem Support, was kostet uns eigentlich eine VM im Jahr im Durchschnitt? Und dann kommt da raus, was auch immer, 100 Euro oder wie auch immer das da umgelegt wird. Und das packst du dann in deiner Projektkosten. Berechne das nicht selber, aber zeige, dass du dran gedacht hast und recherchiere die vernünftigen Zahlen in deinem Unternehmen und damit rechnest du dann. Genau das Gleiche eben bei meinem Lizenzbeispiel für IntelliJ. Das kann man ja auch umlegen. Das wird auch irgendwer wahrscheinlich gemacht haben. Da gibt es dann irgendeinen Kostenpunkt, den du noch mit reinnehmen kannst. Und im besten Fall machst du das nicht für jedes einzelne Ding, das da benutzt wird, sondern du kriegst einfach einen Gemeinkostensatz, den du dann mit in deine Projektkostenbrechnung mit einnimmst. Zum Beispiel anteilig auf deine Stunden aufgerechnet oder auf die der Kollegen, Kolleginnen, die mit dir da zusammen dran arbeiten. Das wäre meine Empfehlung dafür.

[8:38] Und dann, nächster Punkt, die laufenden Kosten. Die werden halt auch sehr oft vergessen. Jetzt haben wir diesen ganzen Kram da eingeplant. Ich habe meine Stundensätze, da sind auch die Gemeinkosten drin und alles super und Lizenzen umgelegt und tralala. Ja, aber dann ist es vorbei. So, dann kostet das Projekt einmalig 3.000 Euro. Beispiel ist eine Zahl, die sehr häufig vorkommt. Und dann amortisieren wir das und dann ist es fertig. Ja, und da wird dann vergessen, dass diese ganzen Ressourcen ja nicht umsonst laufen, wenn man sie einmal angeschafft hat. Beispiel, offensichtliches Beispiel, ein Server, der irgendwo steht, der verursacht Stromkosten, der muss gewartet werden, Updates müssen installiert werden, mal Stundensatz des IT-Admins, der das macht. Wir haben Lizenzen, wenn es ein Windows-Server ist zum Beispiel. Oder wenn das Ding nicht bei uns im Keller steht, in der Cloud, ja, die wird ja sogar stündlich oder täglich abgerechnet, was so ein Server da kostet, ja. Oder ich habe vielleicht Support-Verträge mit Dienstleistern, die für mich die Wartung machen, ja, so Full-Service-mäßig und so. Das sind alles Kosten, die auch anfallen, wenn dein Projekt beendet ist. Und angenommen, du hast jetzt ein Software-Dickle, die auf diesem Server läuft, der Server muss halt weiter betrieben werden, gepatcht werden. Der braucht Strom.

[9:36] Das heißt, auch das musst du natürlich einplanen in deine Kosten. Und das reduziert eventuell, nein, verlängert die Amortisationszeit. Aber das ist gar nicht schlimm. Im Gegenteil, es wäre schlimm, wenn du diese Kosten weglässt, weil das ist unrealistisch. Ich behaupte einfach, dass du kein IT-Projekt umsetzen kannst, was keine laufenden Kosten hat. Das ist einfach eine pauschale Aussage, die ich jetzt hier mal treffe, weil alles, was du entweder programmierst oder installierst oder konfigurierst oder was auch immer du machst in einem IT-Beruf, das wird nicht einmalig sein und dann wird das Ding ausgeschaltet, weggeschmissen, gelöscht, wie auch immer, sondern das wird ja dauerhaft laufen. Das ist hoffentlich die Idee deines Projekts. Und alles, was irgendwo läuft, verursacht wenigstens irgendwie Strom, Wartungs, Lizenzkosten, irgendwas fällt da ganz sicher an. Und es geht ja auch nicht darum, ob es vielleicht Cent-Beträge sind. Das ist ganz egal. Also es geht darum, dass du zeigst, dass du daran gedacht hast, dass diese Kosten anfallen. Ganz egal, wie hoch die sind. Aber du kannst nicht sagen, mein Projekt ist jetzt fertig und jetzt kümmere ich mich nicht mehr drum und jetzt verursacht das keine Kosten mehr. Doch. Und diese laufenden Kosten müssen halt eben auch von euren Kunden erwirtschaftet werden. Die muss irgendwer irgendwo mit einplanen, weil sonst kommt das Geld nicht rein und dann kostet dein Projekt im wahrsten Sinne des Wortes dein Unternehmen Geld, weil die Kunden über die Umlage das nicht wieder reinholen. Und das wollen wir vermeiden, weil wenn wir das alle machen würden, in allen Projekten, wäre das Unternehmen irgendwann pleite. Wenn alle sagen, so, das Projekt hat 5.000 Euro bezahlt, der Kunde bezahlt mir das jetzt einmalig, sagen wir mal mit Gewinnaufschlag, zahlt er 6.000 und dann ist es vorbei. Aber dass wir ihm jetzt noch jahrelang die Server betreiben müssen und einen monatlichen Betrag für uns fällig wird, habe ich leider vergessen.

[11:05] Ja, dann sind die Rechnungen alle bezahlt, aber nach zwei Monaten sind wir trotzdem insolvent, weil die ganzen Kosten, an die keiner gedacht hat, uns leider auffressen. So, das geht nicht. Also bitte auch die laufenden Kosten, und ich habe gerade ein paar genannt, immer mit einplanen, egal wie hoch und in die Riechse sind. Und da kannst du es ähnlich machen wie bei den EDA-Kosten. Du holst einfach Pauschalen. Beispiel hatte ich gerade schon. Was kostet denn der Betrieb einer VM im Jahr das Unternehmen zum Beispiel? Da wird dir hoffentlich ein IT-Admin irgendwie eine grobe Zahl nennen können. Und zur Not schätzt du die einfach. Im besten Fall lässt du sie von Kollegen schätzen, die da mehr Ahnung von haben, keine Frage. Aber wenn das nicht geht, gibt ja auch viele kleine Unternehmen, wo man vielleicht diese Zahlen gar nicht hat, dann schätzt du es halt selbst. Aber du musst jetzt nicht noch eine riesen BAB, so Betriebsabrechnungsbogen in deiner Prodoku machen, das will keiner sehen, das ist viel zu aufwendig. Aber wir wollen sehen, dass du diese Kosten gedacht hast. So, zum Abschluss jetzt noch mal ein paar konkrete Beispiele. Fangen wir mal mit System-Integration an. Was könnten solche Kosten jetzt sein, von denen ich heute rede und geredet habe? Wenn du einen neuen Server brauchst zum Beispiel, wenn du VM hast, was heute natürlich der Standard sein sollte oder Container, ganz egal. Auf jeden Fall brauchen die auch Ressourcen. CPU, RAM, irgendwie Storage vielleicht. Wir haben vielleicht ein Backup-System, was angebunden werden muss. Das wird auch belastet dadurch. Mehr Backup heißt, die Medien müssen vielleicht erweitert werden, weil du keinen Platz mehr hast und so weiter. Es gibt hoffentlich ein Monitoring-System für irgendwelche kritischen Sachen, die da laufen. Du hast natürlich auch die Zeit, vor allem deine eigene, aber auch die der Admins, die dann zum Beispiel Einrichtung, Wartung, eben den Betrieb übernehmen. Das sind alles Dinge, die dir anfallen können.

[12:34] Bei der Anwendungsentwicklung habe ich auch schon genannt. Die IDE, die meistens Geld kostet, manchmal auch nicht. Da musst du es natürlich nicht einen planen, klar. Aber irgendwelche anderen Software-Tools, die du noch im Einsatz hast. Vielleicht habt ihr ein dediziertes Testsystem, ein Staging-System. Das läuft auch nicht einfach so aus Spaß. Das kannst du anteilig mit reinnehmen. Du hast vielleicht eine Datenbank im Einsatz, die anteilig von dir genutzt wird. Eine CICD-Pipeline auf dem Bild-Server. Auch die kostet Ressourcen. Kann man vielleicht sogar genau sehen. Auch die läuft für fünf Minuten, kostet 20 Prozent CPU. Dann könntest du das ziemlich genau in Cent-Beträgen ausrechnen, was das kostet. Musst du nicht, wie gesagt, aber könntest du. Und das sind so ein paar Beispiele jetzt, an welche Kosten man denken kann für diese beiden Fachrichtungen.

[13:13] Für alle anderen IT-Berufe gilt das Ähnliche, aber im Kern geht es meist um solche Ressourcen, wie ihr genannt. So, was würde ich dir jetzt empfehlen für deine Projektdokumentation und Projektpräsentation? Nummer eins, mach erstmal eine Liste der Ressourcen. Das sehe ich auch in ganz vielen Projektdokumentationen, das ist für mich so ein Standardinhalt, finde ich auch gut. Was habe ich für Ressourcen gebraucht? Das geht vom Stuhl und Tisch, auf dem ich sitze, über den Laptop bis hin zu tatsächlich VM-Infrastruktur für mein Projekt am Ende. Alle diese Ressourcen erstmal auflisten. Und dann schaust du dir an, was kosten die denn? kriege ich vielleicht konkrete Kosten von meiner Personalabteilung für alle Menschen, von meinem IT-Betrieb oder aus dem Rechnungswesen oder aus dem Controlling für meine anderen Ressourcen oder kriege ich einfach einen pauschalen Satz genannt. Kann ja auch sein, dass man einfach die Sachen über Gemeinkosten auf die Stundensätze umlegt und dann hast du deinen Gemeinkostenzuschlag und damit ist alles abgedeckt. Ist ja auch okay. Hauptsache, du denkst dran und vergisst da nichts.

[14:05] Meistens wird es für die Projekte auf solche Stundensätze hinauslaufen. Da kannst du damit einplanen. Plus irgendwie eine Pauschale für den Betrieb pro Jahr oder so. Und dann hättest du ja normalerweise alles abgedeckt. Wie gesagt, du sollst das nicht alles im letzten kleinen Detail selber ausrechnen. Nimm am besten Pauschalen. Da kannst du am wenigsten falsch machen, aber zeigst trotzdem, dass du dran gedacht hast. Und wenn du dann noch irgendwie, keine Ahnung, dir den Server teilen musst mit fünf anderen Applikationen, dann kannst du das ja natürlich nochmal geteilt durch sechs machen. Dann hast du deine Anteile an diesen Kosten berechnet. Das ist ja manchmal nötig, habe ich aber noch nicht so oft gesehen. Wie gesagt, lass dir am besten Pauschalen geben und dann musst du da gar nicht so rumrechnen. So, und das planst du dann alles mit ein. Du hast deine einmaligen Kosten, wo dann hoffentlich schon diese EDA-Kosten anteilig mit drin sind, plus die laufenden Kosten. Und dann machst du eine ganz klassische Amortisationsrechnung, schaust dir an, wann habe ich diese Kosten wieder reingeholt. Aber das ist ein Thema für eine andere Episode.

[14:58] So, Fazit für heute. Kosten für dein Projekt. Denk dran, nicht nur das, was neu angeschafft wird für dein Projekt, sind Kosten, sondern auch alles, was schon da ist und was du nutzt, musst du potenziell mit einplanen in deinem Projektkosten. Die vorhandenen Ressourcen sind nie kostenlos. Genau diese EDA-Kosten, das ist ein geflügeltes Wort, weil die Leute sagen, es ist ja EDA. Ja, aber das muss trotzdem bezahlt werden. Die Dinger werden, und das haben wir heute noch gar nicht angesprochen, zum Beispiel, wenn du teure Hardware angeschafft hast, wird die abgeschrieben. Das heißt, über die Abschreibung wird der jährliche Wertverlust dieser Hardware zum Beispiel mit in deine Kostenplanung einfließen müssen.

[15:36] Also alles, was da ist, kostet auch Geld und muss mit eingeplant werden. Das ist die Kernauslage für heute. Und zweiter Punkt, laufende Kosten. Ich behaupte, dass jedes IT-Projekt irgendwelche laufenden Kosten produziert, außer es ist wirklich ein Wegwerfprojekt, was sofort gelöscht wird, nachdem es umgesetzt wurde. Aber das kann ich mir einfach nicht vorstellen.

[15:57] So, ich hoffe, du hast heute ein bisschen was mitgenommen, wie du deine Kosten für dein Projekt in deiner Projektdokumentation und Präsentation gut einplanst und sauber und ohne, dass du was vergisst, vorstellst. Und ja, dann wünsche ich dir viel Erfolg bei deiner Projektdokumentation und Präsentation.

Um die Darstellung von Code in Projektdokumentation und Projektpräsentation geht es in der sechsten Episode der Shorts des IT-Berufe-Podcasts.

Zusammenfassung der Episode

In der aktuellen Episode meiner Podcast-Shorts dreht sich alles um die Kunst der Codepräsentation in Dokumentationen und Präsentationen – ein Thema, das gerade in der Prüfungsphase viele Prüflinge beschäftigt. Ich gebe praktische Tipps, wie ihr euren Code optimal aufbereitet, um in euren Dokumentationen und Präsentationen zu glänzen.

Wir reden darüber, wie der Code in Dokumentationen anders aussehen sollte als in der IDE. Wichtig ist die Lesbarkeit: Setzt auf Struktur und Kontrast, und überlegt euch, ob der Dark Mode wirklich die beste Wahl ist. Ich erkläre, wie ihr den Fokus auf relevante Codeabschnitte legt und unwichtige Details ausblendet.

Außerdem teile ich meine besten Hacks für PowerPoint, damit ihr euren Code Schritt für Schritt einblenden könnt – so zieht ihr die Aufmerksamkeit eurer Prüfenden auf eure Erklärungen! Und natürlich gibt es noch Hinweise zur Farbgestaltung, denn Schwarz auf Weiß ist meist der beste Kontrast.

Hört rein, holt euch nützliche Tipps und bereitet euch bestens auf eure Prüfungen vor. Ich bin gespannt auf euer Feedback und wünsche euch viel Erfolg bei euren Projekten! ✨🎧

Inhalt Zusammenfassung

Die Episode behandelt die Frage, wie Quelltext in Projektdokumentationen und Projektpräsentationen einer Abschlussprüfung für Fachinformatiker Anwendungsentwicklung sinnvoll dargestellt werden sollte. Ausgangspunkt ist die Beobachtung, dass in Prüfungsunterlagen häufig Code-Screenshots aus der IDE verwendet werden, oft zusätzlich im Dark Mode. Die zentrale Aussage lautet, dass Code in der Prüfung nicht so präsentiert werden sollte, wie er in der Entwicklungsumgebung für die tägliche Arbeit angenehm ist, sondern so, dass er im jeweiligen Medium optimal lesbar, verständlich und bewertbar ist.

Ausgangslage und Prüfungsbezug

Im Kontext der AP2 und der anschließenden Projektdokumentation sowie Projektpräsentation spielt Code eine zentrale Rolle, da er den Kern der Arbeitsleistung von Anwendungsentwicklerinnen und Anwendungsentwicklern darstellt. Dabei wird der Begriff „Code“ weit gefasst: Gemeint ist nicht nur klassischer Programmcode in Sprachen wie Java, C# oder PHP, sondern auch andere textbasierte Artefakte wie Jenkinsfiles, Dockerfiles oder Konfigurationsdateien, sofern sie Teil der technischen Lösung sind.

Da diese Artefakte in Dokumentation und Präsentation bewertet werden, müssen sie so aufbereitet sein, dass Prüfende sie ohne unnötige Hürden erfassen können.

Zentrale Qualitätsziele

Für die Darstellung von Code in Prüfungsartefakten nennt die Episode drei Kernziele:

1. Lesbarkeit
   Der Code muss visuell gut erfassbar sein. Dazu gehören ausreichende Schriftgröße, geeigneter Kontrast und eine Darstellung, die sich an das Ausgabemedium anpasst.

2. Verständlichkeit
   Der gezeigte Ausschnitt muss in kurzer Zeit nachvollziehbar sein. Besonders in der Präsentation darf der Umfang nicht so groß sein, dass das Publikum während der Erklärung den Überblick verliert.

3. Bewertbarkeit
   Gezeigt werden sollte genau das, was die eigene Leistung belegt. Unwichtige oder automatisch erzeugte Inhalte erschweren die Beurteilung und lenken vom eigentlichen Beitrag ab.

Unterschied zwischen IDE und Prüfungsmedium

Ein zentraler Punkt ist die Trennung zwischen Entwicklungsumgebung und Prüfungsmedium. In der IDE wird Code unter anderen Bedingungen gelesen und bearbeitet als in einer Dokumentation oder Präsentation:

• In der IDE wird oft an einem Bildschirm mit individueller Konfiguration gearbeitet.
• Die Dokumentation kann auf Papier, Tablet oder Laptop gelesen werden.
• Die Präsentation findet typischerweise in einem hellen Raum statt, oft mit Beamer oder Monitor.

Daraus folgt, dass Formatierungsentscheidungen aus der IDE nicht automatisch für Doku oder Präsentation geeignet sind. Auch Seitenverhältnisse unterscheiden sich deutlich:

• Präsentationen meist im Format 16:9
• Dokumentationen typischerweise im DIN-A4-Format

Code sollte deshalb für jedes Medium separat aufbereitet werden, etwa durch angepasste Zeilenumbrüche und kompaktere Formatierung.

Kritik an Screenshots

Von Screenshots aus der IDE wird klar abgeraten. Dafür werden mehrere technische Gründe genannt:

• Screenshots sind nicht verlustfrei skalierbar; beim Zoomen werden sie unscharf oder pixelig.
• Text bleibt bei Vergrößerung nicht sauber lesbar.
• Screenshots enthalten oft störende IDE-Elemente wie Fehlermarkierungen, Warnungen, Refactoring-Hinweise oder Hinweise zur Code-Historie.
• Solche Einblendungen lenken von der eigentlichen Aussage ab und können im Prüfungskontext sogar unerwünschte Fragen auslösen.

Empfohlen wird daher, Code als echten Text in Dokumentation oder Präsentation einzufügen. Das verbessert Skalierbarkeit, Lesbarkeit und Bearbeitbarkeit deutlich.

Empfehlungen zur Formatierung

Für die Formatierung des Codes werden mehrere konkrete Hinweise gegeben:

• Verwendung einer Monospace-Schriftart, damit Einrückungen und Ausrichtung korrekt bleiben
• Anpassung von Zeilenlängen und Umbrüchen an das Zielmedium
• Gegebenenfalls Änderung von Code-Konventionen für die Darstellung, etwa geschweifte Klammern ans Zeilenende statt in eine separate Zeile zu setzen, um Platz zu sparen
• Nur die relevanten Ausschnitte zeigen, nicht vollständige, kompilierbare Dateien
• Schlüsselwörter oder Modifier wie public, static, final weglassen, wenn sie für die Aussage nicht relevant sind
• Syntax-Highlighting verwenden, aber nur in einer Form, die die Lesbarkeit unterstützt

Die Episode betont, dass Prüfungsunterlagen keine originalgetreue Abbildung der IDE sein müssen. Erlaubt und sinnvoll ist vielmehr eine auf das Publikum optimierte Darstellung.

Bewertung des Dark Mode

Ein Schwerpunkt der Episode ist die Kritik am Dark Mode in Dokumentation und Präsentation. Dabei wird ausdrücklich nicht der Dark Mode im Entwicklungsalltag kritisiert, sondern dessen Übertragung in Prüfungsunterlagen.

Für Dokumentationen

Gegen dunkle Hintergründe in der Dokumentation sprechen laut Episode mehrere Gründe:

• Schwarzer Text auf weißem Hintergrund bietet den besten Kontrast für das Lesen.
• Weißer oder farbiger Text auf schwarzem Hintergrund ist schlechter lesbar, insbesondere mit Syntax-Highlighting.
• Ausdrucke mit schwarzem Hintergrund verbrauchen unnötig viel Toner oder Tinte.
• Kommentare und Korrekturen auf ausgedruckten Seiten sind auf dunklem Hintergrund schlechter sichtbar.

Für Präsentationen

Auch in Präsentationen wird der Dark Mode als problematisch beschrieben:

• In hellen Räumen erscheint Schwarz oft eher grau, wodurch der Kontrast sinkt.
• Bei Displays oder Monitoren können dunkle Flächen stärker spiegeln.
• Reflektionen können die Sicht auf den Code zusätzlich erschweren.

Die pragmatische Empfehlung lautet daher: Code für die Prüfung möglichst dunkel auf hellem Hintergrund darstellen.

Verständlichkeit in der Präsentation

Für die Präsentation wird empfohlen, Code nicht in großen Blöcken auf einer Folie zu zeigen. Stattdessen sollte er schrittweise eingeblendet werden, etwa zeilenweise. Begründung:

• Das Publikum liest sonst sofort den gesamten Code und hört der Erklärung nicht mehr zu.
• Die Aufmerksamkeit lässt sich besser steuern.
• Relevante Teile können gezielt erläutert werden.

Diese Vorgehensweise ist mit Textobjekten in Präsentationstools deutlich einfacher als mit Screenshots.

Auswahl des gezeigten Codes

Besonders wichtig ist die Auswahl der Inhalte. Gezeigt werden sollte nur Code, der die eigene fachliche Leistung sichtbar macht. Nicht geeignet sind laut Episode insbesondere:

• generierte Getter und Setter
• Standard-Konstruktoren
• triviale Framework- oder Binding-Logik
• austauschbare Konfigurationsausschnitte ohne inhaltliche Tiefe
• HTML-Standardmarkup ohne projektspezifische Aussage

Stattdessen sollte der Fokus auf dem fachlich interessanten Teil des Projekts liegen, zum Beispiel:

• projektspezifische Logik
• ein selbst entwickelter Algorithmus
• zentrale Teile der Domäne
• nicht triviale Datenverarbeitung
• Logik, die klar die eigene Denk- und Entwicklungsleistung zeigt

Fazit der Episode

Die Episode versteht Code-Darstellung als Teil der Prüfungsleistung. Ziel ist nicht, die gewohnte IDE-Darstellung zu reproduzieren, sondern die Inhalte so aufzubereiten, dass Prüfende sie schnell erfassen und fair bewerten können. Entscheidend sind dabei eine textbasierte statt bildbasierte Darstellung, hohe Lesbarkeit, reduzierte und zielgerichtete Ausschnitte sowie die Konzentration auf den individuellen fachlichen Beitrag.

Die Kernaussage lässt sich so zusammenfassen: Für Dokumentation und Präsentation sollte Code mediengerecht vereinfacht, formatiert und ausgewählt werden, damit er die eigene Leistung klar und ohne Ablenkung zeigt. Höre dir jetzt die Podcast-Episode an!

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Kontrast und Farben

Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode

[0:20] Während ich das hier aufnehme, sind schon wieder viele Prüflinge im Prüfungsstress, denn die AP2 steht an. Und direkt danach ist bei vielen IHK ja schon die Abgabe der Projektdokumentation. Und danach kommt dann die Projektpräsentation und dann ist endlich die Ausbildung beendet. Und ich werde auch dieses Jahr wieder einige Artefakte mir anschauen dürfen, Projektdokumentation lesen, Projektpräsentation anschauen und natürlich dann bewerten. Und da ich ja nun mal Anwendungsentwicklerinnen prüfe, werde ich da natürlich, solange wir noch Code schreiben müssen, als Anwendungsentwicklerinnen auch Code präsentiert bekommen. Entweder in der Doku oder in der Präsi oder im besten Fall in beiden. Denn das ist ja nun mal der Kern unseres Ausführungsberufs und das gehört natürlich dazu.

[1:03] Und Code, damit meine ich nicht nur Programmiersprachencode, Java, C Sharp, PHP, was auch immer. Inzwischen gibt es ja viele andere Artefakte auch, die bei mir als Code durchgehen. Ob es jetzt ein Jenkins-File ist, ein Docker-File, irgendeine Config-Datei, irgendwas, wo halt Text drin geschrieben wird, der irgendwie vom Computer interpretiert wird. Das würde ich jetzt mal sagen, geht als Quelltext, als Code durch und der wird in vielen Dokumentationen und Präsentationen irgendwo gezeigt, weil er natürlich auch Teil des Projekts ist und Kern der Arbeit. Und das soll natürlich vernünftig dargestellt werden. Und ja, ich habe in den letzten Tagen und Wochen öfter auch mal ein paar TikTok-Videos gepostet. Vielleicht kennst du die auch schon. Und ich habe auch mal so eine kleine Doku auseinandergenommen. Und da bin ich dann gestolpert über die Darstellung des Codes in dieser Doku. Und da kamen gleich die wildesten Kommentare, weil ich gesagt habe, man sollte vielleicht nicht unbedingt den Dark Mode benutzen und Screenshots machen, um seinen Code in der Doku zu zeigen. Und deswegen wurde ich natürlich dann direkt auseinandergenommen, Ja, am besten gibt es noch eine Note dafür, weil der Prüfer die richtige Farbe im Hintergrund haben will und bla bla bla. Und naja, das geht alles so ein bisschen in eine Diskussion vorbei, denn eigentlich geht es mir immer darum, dass alle Artefakte in der Doku und der Präsi so aufbereitet werden, dass sie für das Publikum am besten verarbeitbar.

[2:18] Verständlich und ja, nachvollziehbar und bewertbar sind. Das ist eigentlich immer mein Kern. Und da geht es mir eigentlich ehrlich gesagt wenig darum, ob es ein schwarz oder weißer Hintergrund ist. Es geht einfach darum, ist das für das Medium passend. Und, Spoiler Alert, Dark Mode ist für die beiden Medien, über die ich jetzt rede, nämlich Doku und Präsi, in den seltensten Fällen passend. Werde ich gleich auch nochmal einmal kurz drauf eingeben. Und deswegen geht es mir heute darum, wie kann man Code vernünftig in einer Doku und in einer Präsi darstellen, damit die Prüfenden den gut bewerten können. Das sollte, glaube ich, das Ziel sein. Und das ist so mein Problem zum Einstieg. Die Präsi, die Doku, das sind halt andere Medien als die gute alte ID, in der wir programmieren. Da sitze ich nicht davor im, weiß nicht, dunkel beleuchteten Zimmer und programmiere vor mich hin, sondern ich habe eine Dokumentation, die ein Prüfender vielleicht ausgedruckt auf Papier liest, vielleicht auf dem iPad oder auf dem Laptop liest und bei einer Präsi bin ich als Prüfender halt Zuschauer und Zuschauerin in einem vielleicht gut beleuchteten, hell beleuchteten Raum und nehme da die Prüfung ab. Und für diese Situation muss der Code optimiert werden und nicht so, wie ich den als Entwickler, Entwicklerin in meiner IDE am liebsten habe. Das muss man einfach trennen. Das ist hier jetzt einfach ein anderes Medium, eine andere Darstellung, eine Prüfungsleistung. Und wenn man im Alltag gerne den Dark Mode benutzt, ich habe kein Problem damit. Mach es gerne, aber überlegst du dreimal, ob es vielleicht für die Doku und Präsi was anderes sein muss. Denn, erste Einschränkung, wir haben in der Doku und der Präsi ganz anderes Seitenverhältnis eventuell in der IDE.

[3:45] Präsi üblicherweise 16 zu 9. Das geht noch am ehesten zu unseren Whitescreen-Monitoren heute. Aber die Doku ist halt klassisch DIN A4-Format. Das sieht halt ganz anders aus als in der IDE. Und da muss man vielleicht auch mal ein bisschen umformatieren, damit das vernünftig lesbar ist. Also aus meiner Sicht Ziele für die Prüfung, Lesbarkeit. Die Prüfenden müssen den Code erstmal sehen, lesen, erkennen können. Das ist schon mal der erste Schritt. Da gehört dann sowas rein wie der Kontrast, die Schriftgröße, ja, dass man das einfach vernünftig lesen kann. Und Kontrast ist sowas wie schwarz auf weiß oder halt eben im Dark Mode weiß auf schwarz. Und was dann noch wichtig ist, Verständlichkeit. In der Doku habe ich vielleicht ein bisschen mehr Zeit, den Code in Ruhe zu lesen und zu verstehen. In einer 15-Minuten-Presi, wo du auch noch 27 andere Artefakte hast, ist der Code nur eins davon. Und dann muss man den schnell verstehen können. Und da geht es halt nicht, dass ich seitenweise Code durchgehe. Das kann kein Mensch nachvollziehen. Und dann können wir es auch nicht vernünftig bewerten. Das ist ja das Problem. Es muss bewertbar sein.

[4:39] Und deswegen sage ich immer, Fokus auf das Wesentliche. Wesentliche, zeige sinnvollen, spannenden, interessanten Code, der vor allem deine eigene Leistung demonstriert. Nichts, was heutzutage vielleicht durch KI generiert werden kann, aber schon seit zig Jahren auch in der IDE generiert werden kann. Wie zum Beispiel Getter, Setter, Konstruktoren. Das ist dummer Code, den niemand interessiert, weil das sowieso auf Knopfdruck erzeugt wird und in der Zukunft durch KI sogar noch viel stärker. Das heißt, zeig bitte deine eigene Leistung. Darauf kommt es an. Dann ist es ehrlich gesagt völlig egal, was du am liebsten in deiner IDI einstellst. Es geht hier darum, dass die Prüfenden dir optimal die Note dafür geben können. Das muss der Fokus sein. Also weg vom Ego, weg vom Dark Mode eventuell. Und ich wiederhole den Dark Mode heute noch gerne nochmal, weil das immer ein heißes Thema ist. Die Leute fühlen sich sofort angegriffen, wenn man über den Dark Mode herzieht.

[5:30] Ich weiß gar nicht warum. Es ist ja einfach, wie gesagt, ein anderes Prüfungsartefakt. Da muss man sich mal ein bisschen Gedanken machen. Und dazu zähle ich dann auch noch sowas wie Code-Konventionen oder auch die Vollständigkeit des Codes. Das meine ich damit, Code-Konventionen, wenn deine IDE, das ist mein Lieblingsbeispiel, die geschweiften Klammern, wenn du eine Sprache benutzt, wo die häufig verwendet werden, in der nächsten Zeile anfangen, anstatt am Zeilenende. Dann kann es durchaus sinnvoll sein, für die Doku oder Präsi das zu verändern und die Klammer einfach ans Ende der vorherigen Zeile zu packen, weil du dann weniger Platz verschwendest. Eine leere Zeile, in der nur eine Klammer steht quasi. Das ist in der IDE sicherlich gut. Ich benutze das übrigens im Alter auch, diesen Stil. Ich finde den super.

[6:07] Aber es ist halt für Doku und Präsi Zeilenverschwendung, bin ich mal ganz ehrlich. Das heißt, da musst du einfach anders formatieren, damit es in diesem Medium vernünftig aussieht. Und Vollständigkeit, es geht hier nicht darum, dass du Compiler spielst und dein Code komplett durchkompiliert mit allen Abhängigkeiten, sondern du zeigst nur Ausschnitte. Und dann darfst und sollst du auch gerne die Sachen weglassen, die niemanden interessieren. Und das sind manchmal sogar sowas wie, Bezeichner wollte ich schon sagen, wie irgendwelche Modifizierer, Public, Static, Tralala, alles, was man irgendwo vorschreiben kann, ist für das Verständnis der Logik des Codes erstmal irrelevant. Außer natürlich, du willst gerade irgendwas Architekturelles zeigen und es ist ganz wichtig, wie die Sichtbarkeit ist. Okay, ja. Aber im Kern kannst du im Prinzip alle Schlüsselwörter weglassen, die nicht das, was du da eigentlich zeigen willst, irgendwie unterstützen, unterstreichen. Die lenken dann nämlich nur ab und ich versuche die ganze Zeit zu überlegen, das ist eine Static-Methode, war das denn wohl die richtige Wahl? Hätte er oder sie das nicht doch noch anders machen können? Und schon bin ich abgelenkt und konzentriere mich gar nicht auf das, was du mir zeigen willst. Das heißt, schmeiß deine üblichen Standardsachen aus dem Alltag über Bord und konzentriere dich auf das Medium, das du da gerade vor dir hast und optimiere dafür den Code. Das ist eigentlich schon mal meine Kernaussage heute hier. Und jetzt gehe ich die einzelnen Punkte mal kurz durch, damit du ein bisschen was Konkretes mitnehmen kannst.

[7:21] Lesbarkeit, mein erster Punkt, was ich nicht lesen kann als Prüfender, kann ich nicht bewerten. Ja, doof gesagt. Und da geht es schon los, wenn ich zum Beispiel Screenshots habe aus der IDE, die skalieren halt nicht. Wenn ich einen Screenshot mache, speichere das als JPEG, dann ist das nicht mehr skalierbar. Zoome ich da rein, kriege ich alles pixellig, da kann ich nicht vernünftig lesen. Und selbst wenn ich meine Doku oder die Dokus der Prüfenden auf dem iPad lese, kann ich da rein zoomen, aber dadurch wird der Text halt nicht besser, weil es skaliert halt nicht mit. Deswegen mein Punkt, pack den Code wirklich als Text in dein Medium, in die Doku, in die Präsi. Und wenn du dann da reinzoomst, dann skaliert der Text perfekt mit und wird nicht pixellig. Das wäre schon der erste Grund aus meiner Sicht gegen einen Screenshot. Aber wie ihm auch sei, achte vor allem darauf, dass der Text groß genug ist. In der Doku reicht es, wenn er so groß ist wie der Rest deines Textes. In der Präsi sollte er möglichst groß sein, damit die Menschen, die da vorsetzen und dich bewerten, den halt lesen können. Das wäre schon mal der erste Punkt. Der Code wird natürlich genauso gesetzt, wie wir es aus der IDE kennen, also mit einem Monospace-Font, also nicht Proportionalschrift. Du kennst das, Carrier, Carrier New zum Beispiel, wo also jeder Buchstabe gleich breit ist. Denn bei Code kommt es darauf an, teilweise, dass Sachen exakt untereinander stehen, wie zum Beispiel Klammern. Also setz den Code jetzt nicht in Arial oder Times New Roman, sondern schon passend, wie es in der IDE auch aussieht. Aber deswegen musst du ja noch lange keinen Screenshot machen. Du kannst es ja auch in PowerPoint zum Beispiel einstellen, dass das einfach eine andere Front ist. Fertig.

[8:43] Ich habe es gerade schon gesagt, pass die Zeilen gerne an, brech die vernünftig um, pack die Klammern an eine andere Stelle, wenn es hilft. Ja, das sehe ich insbesondere in der Präsi, wenn dann ganz viele Sachen untereinander stehen. Es ist halt doof für die Präsi, wenn ich 16 zu 9 Format habe. Dann passt es halt nicht allzu viel auf die Folie. Und umgekehrt genau in der Doku, wenn ich die in der 4 Format habe, dann muss ich vielleicht eher optimieren, dass es vertikal gelesen wird, weil ich halt nach unten heraus mehr Platz habe als zur Seite. Also eventuell in der Präsi die Zeilen länger machen, in der Doku die Zeilen kürzer machen. damit ich den Platz vernünftig ausnutze. Und da darf man dann auch gerne mal einen zusätzlichen Umbruch einbauen. Jetzt mal, ich habe immer so ein bisschen Java-Code im Kopf, aber es ist ja in vielen Programmiersprachen auch ähnlich. Da habe ich sowas wie die ganzen Modifizierer und Final und Rückgabewert und Parameter. Und dann darf man ruhig auch mal vor den Parametern einen Zeilenumbruch machen. Klammer auf, Zeilenumbruch, wenn das besser lesbar ist. Throws Exception, vorher Zeilenumbruch, ja, in der Doku, wenn ich Platz nur nach unten hin habe und nicht zur Seite. Das meine ich damit. Gerne an das Medium passend den Code setzen.

[9:44] Und selbstverständlich wollen wir auch gerne Code-Highlighting haben. Das heißt jetzt nicht, ich will einfach nur schwarz auf weißen Code. Natürlich hilft es dem Verständnis, wenn Schlüsselwörter, Variablen und was auch immer vernünftig hervorgehoben sind und da behaupte ich einfach mal, das wirst du mit PowerPoint, das wirst du mit Word oder anderen Tools hinkriegen, dass du das vernünftig formatierst. Du kannst meistens sogar in Word, würde ich sagen, du kopierst es aus der IDE raus, dann nimmt er die Farbinformation schon mit aus der IDE. Ja, musst du bloß noch den schwarzen Hintergrund wieder ausstellen, wenn du Dark Mode nutzt und schon hast du schon schön, vernünftig formatierten Code. Das ist nicht viel Aufwand. Du musst nicht händisch jedes Wort selber formatieren. Das können die modernen Tools schon von alleine. So, jetzt nochmal zum Lieblingsthema Dark Mode. Also ich sag’s gerne nochmal, ich habe nichts gegen den Dark Mode. Wenn du den gut findest, nutz den. Das ist mir egal. Aber denk dran, dass das für die Doku und Präsi vielleicht nicht optimal ist. Warum? Der Kontrast auf Papier ist einfach auch nachgewiesen, dass Schwarz auf Weiß einfach der beste Kontrast ist. Weiß auf Schwarz ist der zweitbeste Kontrast. Er ist auch nicht sehr viel schlechter zu lesen, aber ein bisschen schlechter. Und dann würde ich doch einfach das Optimum nehmen. Also schwarz auf weiß ist das am besten zu lesen fürs menschliche Auge. Warum willst du was anderes machen, wenn Leute diesen Code lesen? Es geht hier ja nicht darum, zu programmieren bei wenig Licht, sondern wie gesagt, damit ich den Code vernünftig lesen kann. Und da ist schwarz auf weiß einfach das Beste.

[11:00] Und jetzt überlegen wir mal, eigentlich haben wir ja bei Code gar nicht schwarz auf weiß, weil wir haben ja das Syntax-Highlighting, hätte ich gerade schon gesagt. Das heißt, manchmal haben wir da vielleicht lila oder grün oder braun auf weiß. Und das kann man alles noch relativ gut lesen. Drehst du das jetzt aber um und machst das auf schwarz im Hintergrund, dann wird das sehr schwer zu lesen. Es wird ein schwerer Kontrast. Überleg dir einfach mal, du hast einen schwarzen Hintergrund und druckst das auf Papier aus und willst da drauf dann vielleicht etwas dunklere Schrift lesen. Das ist echt schwierig. Abgesehen davon verbraucht es natürlich ohne Ende Toner beziehungsweise Tinte, wenn ich den Kram ausdrucke. Einfach ein schwarzes Blatt. Und man muss ja gucken, das wenigste von diesem schwarzen Blatt ist tatsächlich Code. Das meiste ist der Hintergrund. Das heißt, du hast einfach ein schwarzes Blatt mit ein ganz bisschen Wörtern drauf. Und das ist eine riesen Papier- und Tonerverschwendung. Und ja, auch im Jahr 2026 drucken sich Prüfende die Dokus noch aus, weil sie vielleicht kein iPad haben mit einem Pencil. Und es geht ja darum, die Doku zu korrigieren. Also macht man sich Anmerkungen. Und das kann man schlecht am PC. Das geht bei vielen Menschen viel einfacher handschriftlich. Und dann gibt es noch Leute, die sich das ausdrucken. Und das ist auch gar nicht schlecht. Und wenn ich mir dann einen Kommentar in deinen Code machen will, auf einem schwarzen Blatt, ja, viel Spaß, das wiederzufinden. Der Rotstift, den ich habe, den sieht man auf dem schwarzen Hintergrund gar nicht, weil alles schwarz ist. Also, es gibt so viele Gründe, gerade in der Doku auf den Dark Mode zu verzichten. Macht das bitte einfach.

[12:20] Und auch zu Präsi, jetzt kann man ja sagen, Doku, okay, aber in der Präsi ist das ja nicht so. Ja, da habe ich aber einen Punkt, der dagegen spricht. Du wirst normalerweise irgendwann tagsüber präsentieren und meistens auch in einem gut beleuchteten Raum, würde ich jetzt einfach mal behaupten. Ja, Ausnahmestätigen Regeln, ja. Aber wenn das so ist, dann guck einfach mal, wenn du eine Präsi hast mit einem schwarzen Hintergrund und du bist in einem hellen Raum, dann wirst du nicht schwarzen Hintergrund haben, sondern grauen Hintergrund, weil das Licht einfach das schwarze ein bisschen aufhält. Und schon hast du nicht mehr weiß auf schwarz, sondern du hast weiß auf grau, mit grauem Hintergrund. Und das ist wieder ein schlechterer Kontrast. Das kann man einfach nicht gut lesen. Und wenn du jetzt ganz viel Pech hast, dann bist du in einem Raum, wo es wirklich so hell ist und du hast zum Beispiel einen Monitor, also ein selbstleuchtendes Medium, dann reflektiert dieses Medium. Und wenn du einen schwarzen Hintergrund hast, dann reflektiert das optimal. Das heißt, wenn du dann zum Beispiel auf diesen Monitor guckst, dann spiegeln sich, Das habe ich original mal in der Prüfung gesehen. Dann spiegeln sich die Prüfenden in dem Monitor, weil der Hintergrund schwarz ist. Wenn der weiß ist, spiegeln die sich auch, aber es fällt nicht so auf. Und dann hast du auf einmal in deiner Präsentation irgendwelche Köpfe, die du da siehst, aber siehst den Code gar nicht mehr, weil der schwarze Hintergrund halt so reflektiert. Also das sind alles Punkte aus meiner persönlichen Erfahrung, habe ich schon so oft gesehen. Mach es einfach nicht. Mach den Code schwarz auf weiß, dann gibt es keine Probleme. Alle können das gut lesen.

[13:40] Alle freuen sich und geben dir eine gute Note vor allem. So, jetzt habe ich gerade schon gesagt, Code-Highlighting würde ich auch empfehlen, auf jeden Fall. Aber immer geht die Lesbarkeit vor. Das heißt, wenn du gerne deine Kommentare in hellgrün hervorhebst, aber du einen weißen Hintergrund hast, dann ist hellgrün auf weiß vielleicht nicht der optimale Kontrast. Dann macht die Farben doch einen Ticken dunkler. Also bitte nicht eins zu eins die ID übernehmen, sondern guck, wie sieht das in dem Medium, was ich gerade gestalte, aus? Kann man das vernünftig lesen? Und wenn nicht, dann pass es an. Dann macht die Schrift dunkler oder heller oder was auch immer du machen musst.

[14:15] Wenn du den Text, äh, nein, wenn du den Code als Text in deiner Präsi zum Beispiel hast, kannst du es auch relativ einfach hinbekommen, den Code Schritt für Schritt einzublenden. So zeilenweise, ne? Das ist ja auch immer, habe ich gerade schon gesagt, die Verständlichkeit ist ganz wichtig. Und wenn du jetzt eine ganze Folie voll mit Code dahin klatschst, und die dann Zeile für Zeile erklärst, dann kannst du davon ausgehen, dass alle Prüfenden und nicht nur Prüfende, auch andere Menschen würden das so machen, sich erstmal den ganzen Code schön in Ruhe durchlesen und versuchen, den zu verstehen, während du dann auch am rumkaspern bist und irgendwas erklärst. Und das heißt, es hört dir keiner mehr zu. Also, mach das doch einfach Zeile für Zeile, das blendest du nacheinander ein und erklärst das dann. Und das kann man super einfach mit drei Klicks in PowerPoint, wenn alles einzelne Zeilen in Text sind. Das geht auch mit Screenshots überhaupt kein Problem. Es ist nur aufwendiger. Da musst du noch, weiß ich nicht, irgendwelche Rechtecke davor machen und die runterschieben oder ausblenden, damit der Code dann sichtbar ist. Und wenn das Text ist, wie gesagt, drei Klicks. Einblenden, Animation einfügen, bumm, läuft. Also macht ihr das Leben doch einfach.

[15:13] Wenn du das so machen möchtest. Was ich auch aus der Praxis schon oft gesehen habe, tatsächlich bei Screenshots aus der IDE, es werden natürlich alle Sachen gescreenshortet, nicht nur der Code. Das heißt zum Beispiel in IntelliJ gibt es immer so Hints an den Code-Zeiten, zum Beispiel wie oft die benutzt werden oder wer den letzten Code mitgemacht hat und solche Sachen. Ist natürlich für deine Präsentation völlig irrelevant und ablenkend, wenn man das immer sieht. Am schlimmsten wäre es natürlich, wenn da steht, Moment mal, die Code-Zelle wurde gar nicht vom Prüfling bearbeitet, sondern von irgendwem anders. Oh, oh, oh, das ist natürlich dann ganz problematisch. Aber auch wie, keine Ahnung, Fehler, die in der IDE gefunden wurden, irgendwelche Optimierungen, Rechtschreibfehler in Variablen Namen. Da ist ja alles zu sehen, auch diese kleinen Schlängelchen unter den Wörtern, wenn da irgendwie ein Fehler oder wenn die IDE irgendwas findet. Das ist ja alles mit drin. Und das habe ich original schon in so vielen Präsentationen gesehen, dass die Leute dann einfach gescreenshottet haben mit allen Schlängelchen und allen roten Hinweisen und so weiter da drin.

[16:05] Also Fehler, das wäre ja Vollkatastrophe. Aber zum Beispiel auch Refactoring-Tipps oder so. So, da wird quasi, da sagt die IDE, Achtung, Achtung, diese Variable wird nirgendwo benutzt. Ist jetzt nur ein Beispiel. Und dann machen die davon einen Screenshot und zeigen das in ihrer Prüfung. So, hey, ich habe eine Variable deklariert, die ich gar nicht benutze. Das ist doch keine gute Arbeitsleistung. Wenn die IDE einem das schon sagt, dann muss man nur einmal draufklicken und dann wird die Variable gelöscht. Und das ist jetzt wirklich nur ein Beispiel. Es gibt natürlich noch ganz viele andere Möglichkeiten, Refactorings zu zeigen. Und das willst du doch nicht in deiner Prüfung. Also, kopier den Text raus und mach keinen Screenshot. und wenn du Screenshots machst, dann geh wenigstens so weit und schmeiß diesen ganzen Kram, den niemand interessiert. Die Schlängelchen, die Fehler, die Vorschläge etc. Bitte einfach raus, weil das lenkt super ab und ich mache mir nur noch Gedanken, ob du das wirklich selber gemacht hast, ob da jemand mitgeholfen hat, ob du nicht gesehen hast, dass die IDE dir Vorschläge gemacht hat, dass du quasi gar nicht hingeguckt hast. War das vielleicht einfach nur gecopy-pasted? Du hast dich gleich damit auseinandergesetzt. Also ich stelle mir tausend Fragen, wenn ich diese Sachen sehe, die mich eigentlich nur von deinem Code ablenken. Also lass es doch bitte einfach weg.

[17:08] So, dann kommen wir auch gleich zum Thema Verständlichkeit. Hier kannst du gerne aus deinem Code, wie gesagt, alles rausschmeißen, was niemanden interessiert. Irgendwelche Modifizierer, Public, Final, Static, was auch immer. Interessiert doch nicht, wenn du gerade einen Algorithmus erklären willst, ja. Getter, Setter zum Beispiel. Oh Gott, lass das doch einfach weg. Du willst eine Klasse zeigen. Ja, dann konzentrier dich auf den wichtigen Kernalgorithmus, den du gebaut hast und nicht auf die generierten Getter und Setter, die alle aus einer Zeile Code bestehen. Das ist einfach langweilig, komme ich gleich nochmal zu, sowieso, aber es brauche ich auch nicht zum Verständnis. Also wenn ich in deinem Code, in deinem Algorithmus irgendwas lese wie GetName, dann kann ich mir wohl herleiten, dass das eine Methode ist, die den Namen zurückgibt. Ja, da brauchst du nicht erklären. Aber wenn du komplizierte Methoden aufrufst, wo es nicht sofort ersichtlich ist, dann solltest du es vielleicht einblenden. Also mach dir doch mal ein bisschen Gedanken. Jemand, der deinen Code noch nie gelesen hat, was braucht der oder die, um zu verstehen, was du da gerade gemacht hast? Und das sollte auf deiner Folie erscheinen. Und alles andere bitte nicht.

[18:04] Und dann komme ich zum letzten und aus meiner Sicht nochmal wichtigsten Punkt. Konzentrier dich auf deine eigene Leistung. Das ist hier eine Prüfungsleistung. Es geht hier nicht darum, coolen, fancy Code zu programmieren und keine Ahnung, du bist der geilste Coder, die geilste Coderin. Es geht um eine Prüfungsleistung, die bewertet wird. Und da möchte ich deine eigene Leistung sehen. Da möchte ich weder generierte Getter Setter sehen, da möchte ich auch keinen KI-generierten Code sehen, sondern möchte ich das sehen, was du gemacht hast. Es ist deine Prüfung. Du bekommst die Note. Du bist danach ausgebildete Fachinformatikerin. Deswegen zeig doch auch das Beste, was du gemacht hast. Zeig spannenden Code mit ein bisschen Logik drin, wo du einen kleinen Algorithmus gemacht hast. Das muss nichts Weltbewegendes sein. Das müssen nicht 100 Zeilen sein. Es reicht ein bisschen, weiß ich nicht, wenigstens If, Else und Schleife oder sowas. Oder wenn du in Java arbeitest, irgendwie mal eine kleine Stream-Logik mit Map, Filter, Reduce. Irgendwas, wo du auch selber ein bisschen überlegen musstest. Ja, im besten Fall irgendwie auch den Kern deines Problems, dass du nicht irgendeinen Random-Code im Frontend zeigst, der irgendwie Data-Binding macht, was in jedem Framework immer gleich ist, sondern etwas, was dein Projekt ausmacht. Etwas, was nur du in deinem Projekt gemacht hast, den Kern deiner Domäne. So etwas ist spannend. Ja, und nicht das x-te Mal erklären, wie im Frontend ein Feld an ein Input-Feld gebunden wird. So, das ist maximal generisch und langweilig. Das haben wir schon tausend Mal gesehen. sondern es geht darum, was du in deinem Projekt Besonderes gemacht hast. Das wäre meine Zentrale Empfehlung, damit ich deine Leistungen bewerten kann und dir dafür eine Note geben kann.

[19:32] Und ich nehme immer nur Getter und Zetter als Beispiel. Das gibt es in allen Sprachen oder so. Ich habe auch schon Präses gesehen mit Config-Files, mit Zeilenausschnitten aus Config-Files, wo einfach nur Werte gesetzt wurden. Oder HTML-Oberflächen. Ich meine, HTML ist schön und gut, das brauchen wir alles super, aber muss ich jetzt wirklich jedes P und A und Span und irgendwas tagt da sehen? Oder will ich nicht vielleicht das Interessante sehen, was dein Projekt besonders macht? Und Spoiler, natürlich will ich das Interessante sehen und nicht diesen langweiligen Standardkram.

[20:02] So, fassen wir nochmal zusammen. Es soll ja nur ein Short sein heute. Ich glaube, den Rahmen habe ich schon fast wieder gesprengt. Meine Empfehlung. Such dir spannenden Code, der deine Arbeitsleistung gut demonstriert und zu deiner Domäne passt. Nichts Generisches, also bitte nicht falsch verstehen, keine generischen Klassen. Darfst du gerne zeigen, wenn du welche gebaut hast, sondern allgemeinen Code, den jeder andere in irgendeinem Projekt auch hätte machen können. Das will keiner sehen, sondern das, was du für dein Projekt individuell besonders gemacht hast. Das ist interessant. Schmeiß alle uninteressanten oder ablenkenden Inhalte raus. Irgendwelche Overlays aus der IDE, am besten noch Fehlerschlängelchen, solche Sachen. Bitte alles rausschmeißen, damit das nicht ablenkt von dem, was du eigentlich zeigen willst. Und dann optimierst du den Code an das Medium. Setz ihn quasi hochkant für deine Projektdokumentation und eher zur Seite für die Projektpräsentation. Dafür darfst du auch gerne Umbrüche einfügen, rausnehmen, Zeilenlängen anpassen. Alles erlaubt, solange man das auf dem Medium gut lesen kann. Das ist der Fokus. Und dann ist es oft sinnvoll, in der Präsentation den Code Schritt für Schritt einzublenden, also Zeile für Zeile, während du es erklärst, damit die Leute nicht abgelenkt sind und den ganzen Code schon lesen.

[21:07] Und natürlich darfst du auch ein Syntax-Highlighting einfügen, aber kontrolliere am Ende nochmal, ob es dem Kontrast dienlich ist oder nicht.

[21:15] So, das wären meine Tipps für vernünftiges Darstellen von Code in der Projektpräsentation und Dokumentation. Ich hoffe, du konntest ein bisschen was mitnehmen. Und wenn du eine andere Meinung hast und sagst, ich will aber immer ein Datenbot benutzen, dann schreib mir gerne einen Kommentar. Erwarte aber nicht, dass ich darauf sinnvoll antworte, weil meine Erklärung, warum das nicht sinnvoll ist, in vielen Fällen, habe ich ja jetzt hiermit geliefert. Und damit würde ich sagen, viel Erfolg bei deiner Projektdokumentation und Präsentation.

In der einhundertsechsundneunzigsten Episode des IT-Berufe-Podcasts bespreche ich mit Thomas Schmidt von BZEcom (Bildungszentrum für E-Commerce und IT) die neuen IT-Weiterbildungen, die 2024 eingeführt wurden. Wir analysieren die Hintergründe der jüngsten Veränderungen im Weiterbildungssystem für IT-Fachkräfte, insbesondere die Einführung des Berufsspezialisten in IT auf DQR-Stufe 5 und Bachlor Professional auf DQR-Stufe 6. Thomas erläutert die Fachrichtungen wie Datenanalyse, IT-Beratung und Informationssicherheit, die spannende Karrieremöglichkeiten bieten. Wir gehen auch auf das Prüfungsverfahren des neuen Abschlusses und dessen Vereinbarkeit mit dem Berufsleben ein. Zudem diskutieren wir die Finanzierungsmöglichkeiten, einschließlich des Aufstiegs-BAföG, die angehenden Fachkräften im IT-Bereich Unterstützung bieten. Diese Episode bietet wertvolle Informationen für jede und jeden mit Interesse an der Weiterentwicklung im IT-Bereich.

Inhalt

In dieser Episode des IT-Berufe-Podcasts widmen wir uns einem äußerst spannenden Thema: IT-Weiterbildungen und den neuen Abschlüssen, die 2024 in Kraft getreten sind. Ich führe ein ausführliches Interview mit Thomas Schmidt, der beim Bildungszentrum für E-Commerce und IT tätig ist. Thomas bringt uns auf den neuesten Stand, was die Veränderungen im Weiterbildungssystem für IT-Fachkräfte betrifft und erläutert die neuen Möglichkeiten, die sich aus den Überarbeitungen ergeben.

Zunächst diskutieren wir die Hintergründe der Anpassungen, die notwendig wurden, weil die vorherigen Abschlüsse, insbesondere die sogenannten Operative Professionals am Markt nicht gut angenommen wurden. Die Reaktionen von Arbeitgebern waren klar: Sie benötigten Fachkräfte, die spezialisiert sind, aber nicht unbedingt Führungspositionen einnehmen. Daher wurde der Berufsspezialist in IT geschaffen, der auf Ebene 5 des deutschen Qualifikationsrahmens (DQR) angesiedelt ist und nun als attraktive Alternative für all diejenigen gilt, die ihre Ausbildung abgeschlossen haben und stoffliche Expertise nachweisen wollen.

Thomas erläutert die zahlreichen Fachrichtungen innerhalb dieses neuen Abschlusses: Darunter fallen die Spezialisierungen in Datenanalyse, IT-Beratung, Informationssicherheit, Softwareentwicklung und Systemintegration. Dieser Fokus auf spezielle Fachkompetenz eröffnet nicht nur zahlreiche Karrieremöglichkeiten, sondern erlaubt es auch, dass sich Fachinformatiker oder Kaufleute für Digitalisierungsmanagement nach der Ausbildung gezielt weiter qualifizieren, ohne den traditionellen Weg eines Universitätsstudiums gehen zu müssen.

Wir besprechen auch das Prüfungsverfahren für den Berufsabschluss sowie den Bachelor Professional in IT, der nun auf derselben DQR-Stufe wie ein Bachelorabschluss an Universitäten eingestuft ist. Thomas erklärt, dass die Prüfung sowohl schriftliche als auch praktische Bestandteile umfasst, einschließlich der Präsentation eines Projekts, was eine direkte Anwendung des erlernten Wissens im beruflichen Kontext darstellt. Dies ist besonders interessant für all jene, die bereits im Beruf stehen und sich fachlich verbessern möchten.

Ein weiterer zentraler Punkt ist die Vereinbarkeit der Weiterbildung mit dem Berufsleben. Thomas gibt Einblicke in dieFlexibilität der Kurse, die sowohl in Abendveranstaltungen als auch in kompakten Blockkursen angeboten werden. Zudem werden die Teilnehmer bei der Vorbereitung auf die IHK-Prüfung durch praxisnahe Fallstudien unterstützt, um sicherzustellen, dass sie nicht nur für die Prüfung lernen, sondern auch wertvolles Wissen für ihren späteren Berufsalltag erhalten.

Abschließend nimmt Thomas auch Bezug auf die Finanzierung dieser Weiterbildungen, einschließlich des Aufstiegs-BAföG, welches eine bedeutende Unterstützung für angehende Professionisten im IT-Bereich bietet. Er ermutigt alle, die an einer Weiterbildung interessiert sind, sich nicht nur um das persönliche Wachstum zu kümmern, sondern auch aktiv nach Anerkennung und Ermutigung von Arbeitgebern zu suchen.

Diese Episode bietet umfassende Einsichten und Anregungen für alle, die an IT-Weiterbildungen interessiert sind, und zeigt die vielfältigen Möglichkeiten auf, die sich durch neue Abschlüsse ergeben können.

Diese Fragen klären wir im gemeinsamen Gespräch:

• Wie kam es dazu, dass die bisherige IT-Weiterbildung modernisiert/überarbeitet wurde?
• Was sind die neuen IT-Berufsspezialisten bzw. Bachelor Professional in IT überhaupt?
• Für wen sind diese Abschlüsse geeignet und was bringen sie mir?
• Warum wurden die Abschlüsse neu entwickelt?
• Welche unterschiedlichen Berufsspezialisten gibt es?
• Wie ist der Zusammenhang von Berufsspezialisten und Bachelor Professional in IT?
• Was sind die Inhalte?
• Wie ist der Ablauf und die Dauer? Gibt es z.B. Blended Learning oder nur Präsenz/online?
• Wie sieht die Abschlussprüfung aus?
• Welche Qualifikationen sind Voraussetzung für die Weiterbildung?
• Warum sollte ich Bachelor Professional in IT werden und nicht einfach (dual) studieren gehen?
• Ist der Bachelor Professional in IT wirklich schon so anerkannt wie ein "richtiger" Bachelor, z.B. für Laufbahnen im öffentlichen Dienst?
• Wie bekannt/anerkannt sind die Abschlüsse bei Arbeitgebern?
• Welche Förderungen gibt es?
• Was ist das Aufstiegs-BAföG?
• Was fördert es genau?
• Wie läuft die Beantragung?
• Wie läuft die Rückzahlung?

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• IHK-Weiterbildung zum Operative Professional mit Simon Stork – Anwendungsentwickler-Podcast #127 (der inzwischen überholte Abschluss)
• Thomas Schmidt bei LinkedIn
• Website zur IT-Weiterbildung von BZEcom
• IT-Karriere leicht(er) gemacht – Weiterbildungssystem neu aufgestellt – Rechtsverordnungen seit Ende 2024 in Kraft
• Neuordnung des IT-Weiterbildungssystems (BiBB)
• Das Aufstiegs-BAföG: die attraktivste Aufstiegsförderung aller Zeiten

Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode Einführung in die IT-Weiterbildung

Stefan:
[0:22] Herzlich willkommen zum IT-Berufe-Podcast, dem Podcast rund um die Ausbildung in den IT-Berufen. In dieser Episode gibt es ein spannendes Interview zum Thema IT-Weiterbildungen, und zwar dem neuen Berufsspezialisten bzw. Bachelor Professional in IT. Viel Spaß!

Stefan:
[0:40] Hallo und herzlich willkommen zur 196. Episode des IT-Berufe-Podcasts. Mein Name ist Stefan Macke und heute habe ich ein spannendes Interview mitgebracht für dich, Und zwar geht es um die neuen IT-Weiterbildungen. Vielleicht hast du das schon mitbekommen. Es gibt ja nicht nur die Ausbildung in Deutschland, sondern darauf aufbauen kann man sich ja auch fort- und weiterbilden. Und gerade Ende 2024 wurde das Weiterbildungssystem in der IT total überarbeitet. Früher, das hast du vielleicht schon mal mitbekommen, ich habe sogar eine Podcast-Episode dazu gemacht, hieß das Ding, was man danach machen konnte, Operative Professional. Und das wurde aber wohl am Markt nicht ganz so gut angenommen, sage ich mal vorsichtig. Und deswegen wurde das jetzt komplett überarbeitet und ist seitdem tatsächlich auch gleichbedeutend mit zum Beispiel einem Bachelorabschluss, den du an einer Hochschule machen kannst. Das ist laut dem DQR, dem Qualifikationsrahmen, auf der gleichen Stufe wie ein Universitätsabschluss. Und deswegen denke ich, dass das auf jeden Fall spannend ist, falls du deine Ausbildung schon beendet hast oder kurz davor schlägst und dir überlegst, Mensch, was soll ich denn danach machen? Soll ich studieren gehen oder was eigentlich? Was ist denn überhaupt die Alternative? Und genau über diese Alternative wollen wir heute mal sprechen. Und dazu habe ich mir einen spannenden Gesprächspartner mitgebracht, den Thomas. Der stellt sich auch gleich einmal vor, was er dazu überhaupt zu sagen hat zu

Gespräch mit Thomas über IT-Weiterbildung

Stefan:
[1:58] diesem Thema und was so sein Hintergrund ist. Und ja, das war es mit vorgeplänkelt, würde ich sagen. Ich gehe mal direkt rein ins Interview. Viel Spaß dabei.

Stefan:
[2:08] Ja, erstmal hallo Thomas, schön, dass du heute da bist und mit mir über das spannende Thema der IT-Weiterbildung sprechen möchtest. Das habe ich bislang noch vernachlässigt, weil ich mich selber auch wirklich gar nicht gut damit auskenne. Da bin ich sehr froh, dass du euch hier bist und ein bisschen was darüber erzählen möchtest. Und bevor wir aber in das Thema eintauchen, würde ich mal so ein paar Standardfragen stellen. Und als allererstes natürlich frage ich dich, gut, wie du heißt, haben wir es gerade gehört, aber wer bist du, wo arbeitest du und warum bist du heute überhaupt hier? Erzähl doch mal ein bisschen was zu dir.

Thomas:
[2:32] Ja, hallo Stefan. Erstmal schön, dass ich da sein darf und was erzählen darf über die IT-Weiterbildung. Ja, Thomas Schmidt, also ich habe keinen Namen, sondern eine allgemeine Bezeichnung bekommen von meinen Eltern. Ich bin tatsächlich zuständig beim Bildungszentrum für E-Commerce und IT für Außenfortbildung. Ich habe tatsächlich IT nicht gelernt. Ich bin Politikwissenschaftler gelernt und habe mich aber immer mit Außenfortbildung beschäftigt und bin da tatsächlich jetzt in leitender Position zuständig, um das Unternehmen und Produktlandschaft weiterzuentwickeln.

Stefan:
[3:09] Okay, das heißt, du machst in der Außenweiterbildung nicht nur die IT, sondern auch noch, so als Beispiel, noch ein, zwei andere Berufe, irgendwas dabei?

Thomas:
[3:15] Genau, weil wir Bildungsanleitung für E-Commerce und IT sind, natürlich im E-Commerce-Bereich eben auch tätig, um dort für die Spezialisten im Online-Handel sozusagen noch was zu bieten.

Stefan:
[3:26] Okay, der Ausbildungsberuf gibt es inzwischen, glaube ich, Kaufmann, Frau für E-Commerce.

Thomas:
[3:30] Genau, Kaufmann, Kauffrau im E-Commerce ist die Seite, die tatsächlich dafür sorgen, dass der Shop funktioniert, dass die Produkte eingestellt werden, den ganzen Customer Journey Bereich funktioniert, Kennzahlen ausgewertet werden und die haben halt die Möglichkeit, sich weiterzuentwickeln und eben der andere IT-Bereich.

Stefan:
[3:53] Okay, klasse. Und wie kann man sich so deine Arbeit im Alltag vorstellen? Sonst frage ich ja immer gerne so, was programmierst du den ganzen Tag? Das kommt ja jetzt hier nicht in Frage, aber wie kann man sich vorstellen, was du den ganzen Tag machst?

Thomas:
[4:03] Das frage ich mich ab und zu auch. Spannenderweise tatsächlich, wie es denn irgendwann so ist, ich glaube, die Hälfte meiner Zeit verbringe ich in Videokonferenzen und in Absprachen, um Sachen zu planen und abzustimmen. Grundsätzlich ist tatsächlich, ich analysiere den Markt, gucke, wo gibt es Chancen, unser Portfolio weiter auszubauen, kann sich das für das Unternehmen rechnen, in welche Geschäftsfelder können wir eintreten, eben ganz viel Marktanalysen, Wettbewerbsanalysen, um dann nachher zu gucken, wer ist die Zielgruppe, wie können wir es verkaufen und legen wir das Marketing auf.

Stefan:
[4:40] Okay. Ja, sehr spannend. Das ist etwas, womit ich mich gar nicht so gut auskenne. Macht man mir eher die Programmierung, beziehungsweise die Ausbildung. Aber genau, deswegen bist du ja auch hier und erzählst heute ein bisschen was. Und zwar über die IT-Weiterbildung. Ich bin ja in meinem Podcast hauptsächlich für die Leute da, die noch in der Ausbildung sind. Ich habe natürlich auch ein paar oder mehrere Ausbilder, Ausbilderinnen, die zuhören. Aber ganz oft kriegt natürlich auch die Frage, was gibt es denn für Möglichkeiten eigentlich nach der Ausbildung? Und meine Standardantwort ist eigentlich immer, ja, kann man ja noch studieren, duales Studium, sowas in die Richtung. Und vor ein paar Jahren hatte ich schon mal jemanden im Podcast, der hat was zu den Operative Professional, ich glaube, es gab mehrere, vier verschiedene, glaube ich, berichtet. Und ich glaube, das ist aber ja nicht mehr so ganz zeitgemäß.

Neue Berufsspezialisten in der IT

Stefan:
[5:18] Und vielleicht kannst du uns ja mal kurz über das Thema einführen. Was gibt es denn da jetzt heute und worüber

Thomas:
[5:23] Reden wir heute eigentlich? Genau, wir wollen über die neuen Weiterbildungen, Fortbildungen, wie es bei der IHK heißt, sprechen, die eben jetzt die Möglichkeit schaffen sollen, nach der Ausbildung zum Fachinformatiker zum Beispiel, weiterzumachen, sich weiter zu qualifizieren und eben nicht unbedingt den Weg an die Uni gehen zu müssen.

Thomas:
[5:45] Die operativen Professionals, das hast du erwähnt, die waren tatsächlich leider bei den IT-Lern semi-erfolgreich, sodass die tatsächlich überarbeitet werden mussten, weil die auch einfach nicht zeitgemäß waren von den Inhalten und von den Zielrichtungen her, sodass man gemerkt hat, wir schaffen das gar nicht, mit der IHK unser Produkt an den Markt zu bringen und einen Bedarf zu wecken, sodass man glücklicherweise gesagt hat, komm, wir gehen mal in eine Überarbeitung und versuchen das auf neue, moderne Säulen einfach aufzustellen.

Thomas:
[6:17] Es hat verschiedene Aspekte, eben das A, ist es nicht angekommen, B, aber auch haben die Arbeitgeber gesagt, es ist mir teilweise, geht es einfach an meinem Bedarf vorbei, weil es von der Niveaustufe immer nur die Fortbildung auf sozusagen Bachelor-Niveau gab. Ich weiß nicht, ob es bekannt ist, es gibt ja diesen deutschen Qualifikationsrahmen, der Abschlüsse vergleichbar machen soll. Die klassische Ausbildung ist auf Stufe 4 und auf Stufe 6 gab es immer nur einen Fachwirt, einen Meister oder wie es heute heißt, Bachelor Professional. Was aber immer damit zu tun hat, dass ich eigentlich Führungsaufgaben lerne. Dann muss man irgendwann als Firma sagen, ist schön und gut, aber 20 Führungskräfte brauche ich in so einer IT-Abteilung vielleicht auch nicht. Das heißt, dieser Mittelbau fehlte auch einfach, sodass man jetzt eben von den Arbeitgebern auch zurückbekommen hatte, können wir da nicht irgendwie eine Ebene unterschaffen, weil ich brauche nicht 20 Führungskräfte, aber 20 Spezialisten wären schon ziemlich geil in dem Team. Und deswegen hat man jetzt auf der Mittelstufe, also Stufe 5 des deutschen Qualifikationsrahmens, den Berufsspezialisten in IT geschaffen, um eben diese Fachexpertise zu stärken.

Thomas:
[7:33] Deswegen gibt es da auch verschiedene Fachrichtungen. Es gibt eben mit Aufbauen auf dem, was ich gelernt habe in der Ausbildung, die Möglichkeit, Berufsspezialist für Datenanalyse zu werden, Berufsspezialist für IT-Beratung, für Informationssicherheit, für Softwareentwicklung oder Systemintegration und Vernetzung. So dass ich aus jedem Fachinformatikbereich oder eben aber auch Kaufleute für Digitalisierungsmanagement die Möglichkeit habe, mich im Rahmen der IHK weiterzuentwickeln und dort eben fortzubilden. Weil eben bis jetzt, ja, musste ich an die Uni gehen und mich dort irgendwie weiter bewegen, wenn ich irgendwas auch nachweisbar haben möchte.

Vorteile der neuen Abschlüsse

Thomas:
[8:20] Der Vorteil eben hier ist auch zusätzlich, dass eben, besonders wenn ich tarifgebunden bin, mit diesen Abschlüssen ich eine Qualifikation nachweisen kann, die mich innerhalb der Entgeltstufen nach vorne bringen kann, weil die einfach dann auch in den Tarifverträgen einfach mit eingespielt sind und ich dann eben sagen kann, guck mal, ich bin jetzt in Stufe aufgestiegen, ich habe die Möglichkeit, mich weiterzuentwickeln, um dort voranzugehen.

Stefan:
[8:50] Das heißt, wenn ich mal jetzt der Leiter nach weitergehe, Ausbildung ist vier, dann kommt mit fünf die, ich sage jetzt mal fachliche Stufe, die du gerade sagtest, der heißt jetzt Berufsspezialist, bin ich verstanden? Genau. Okay. Und auf der sechs sind wir dann bei diesem Bachelor Professional, was man, habe ich jetzt ausgehört, so vergleichen kann mit dem klassischen Meister, was man vielleicht aus dem Handwerk kennt.

Thomas:
[9:09] Genau, also das ist dieselbe Niveoebene, Meister oder wenn man aus dem Bürobereich kommt, den Wirtschaftsfach wird, den hat man vielleicht schon mal als Titel gehört. Und da ist eben auf derselben Stufe jetzt der Bachelor Professional in IT eingeordnet auch und erlassen worden. Wenn man die Stufe einfach der Vollständigkeit weitergeht, danach würde der Betriebswert IHK kommen als die höchste Ebene auf Masterniveau, die man über die IHK erreichen kann.

Stefan:
[9:36] Okay, und das ist auch so, wenn ich jetzt zum Beispiel diesen Bachelor Professional machen will, dann muss ich erst den Berufsspezialisten haben? Ist das so eine Leiter, die ich hochklettern muss?

Prüfungsstruktur und Anforderungen

Thomas:
[9:46] Jein, da kommt die IHK wieder so ein bisschen in Prüfungslogik durcheinander. Der erste Teil des Bachelor Professionals ist der Berufsspezialist. Also ich kann sagen, ich fange sofort den Bachelor Professional an, mache aber dann automatisch erstmal den Berufsspezialisten in der Qualifikation, die ich brauche, weil es dieselbe Prüfung ist. Das ist tatsächlich so ein bisschen seltsam bei der IHK von der Logik. Es hängt nämlich davon ab, wie ich mich zur Prüfung anmelde. Das ist spannenderweise. Wenn ich sage, ich will Bachelor Professional werden. Also ich will Bachelor Professional werden, du willst auch Bachelor Professional werden. Ich melde mich bei der IHK zur Prüfung als Bachelor Professional an und habe mich für die Wahlqualifikation Informationssicherheit entschieden. Dann schreibe ich die erste Teilprüfung Bachelor Professional und bestehe und kriege danach ein Teilnahmezertifikat. Du willst auch Bachelor Professional werden, schreibst auch die Spezialistin für Informationssicherheit, hast dich aber für den Berufsspezialisten für Informationssicherheit als Prüfung angemeldet. Du hast auch bestanden, bloß du kriegst eine Urkunde, dass du Berufsspezialist in Informationssicherheit bist, kannst dich damit bewerben und nachweisen, Ich hab nichts. Das ist die IHK Live.

Stefan:
[11:15] Okay. Okay, also ich habe verstanden, man macht diese ganzen Prüfungen dann in Anführungszeichen nur als Teil seiner eigentlichen Abschlussprüfung, die dann irgendwann später kommt, für diesen Bachelor Professional. Aber wenn ich den haben will, muss ich also schon vorher diese andere Abschlussprüfung mitmachen. Es ist also nicht nur eine am Ende,

Thomas:
[11:33] Es ist dann auch zwischendrin noch eine. Genau, ich muss dieselbe Prüfung schreiben, es ist nur die Frage, wo ich das Kreuzchen bei der Anmeldung setze, ob ich ein Dankeschön, dass du da was zettelt kriegst oder ob ich tatsächlich eine Urkunde habe, mit der ich was anfangen kann.

Stefan:
[11:46] Okay, gut. Aber wäre es dann nicht schlauer, das Kreuzchen so zu machen, dass ich direkt erstmal diesen Abfluss in der Tasche habe? Ja, klar. Dann habe ich ja zwei am Ende.

Thomas:
[11:54] Ja, definitiv.

Stefan:
[11:55] Okay. Das ist wirklich wieder sehr logisch gemacht. Okay. Ja, sehr schön. Okay, verstanden. Und wenn wir schon beim Thema Prüfung sind, vielleicht ein bisschen vorgegriffen, aber was ist das für ein Ding? Ist das rein schriftlich? Muss ich was Praktisches machen, wie bei der Ausbildung? Kann man das grob schon sagen? Das ist ungemischt.

Thomas:
[12:12] Wenn wir uns jetzt die Berufsspezialisten erstmal angucken, Das ist ja die erste Prüfung, die ich machen muss, auch wenn ich Bachelor Professional werden möchte, besteht aus Klausuren und einer Münchenprüfung. Also eigentlich so, wie man es tatsächlich kennt, die Klausur sind keine Multiple-Choice-Fragen mehr wie in der Ausbildung, sondern ich muss tatsächlich textlich was bearbeiten, Unternehmensszenarien bearbeiten, sodass ich da schriftlich das mache. Danach habe ich eine Präsentation, die ich halte. Da habe ich 30 Tage Zeit, eine Präsentation vorzubereiten. Und dann gehe ich zum Prüfungsausschuss, halte Präsentationen. Also eigentlich vergleichbar zu einer Ausbildung in dem Teil.

Thomas:
[12:57] Wenn ich dann zum Bachelor Professional weitergehe, dann kommt nochmal eine Klausur im Bereich, schriftliche Prüfung. IT-Projekte ist dabei, Prozessmanagement ist mit dabei, kommt auch BWL mit dazu, weil man ja auch unternehmerisch Wissen kriegen soll. Dann gibt es Klausuren zum Thema rein Personal, Management und Personalführung und Ausbildung. Dann gibt es eine mündliche Prüfung, eine Gesprächssimulation, wo man ein Personalgespräch durchführen muss. Also schon eine Herausforderung. Und dann schreibe ich tatsächlich noch eine Projektarbeit, die ich dann auch noch mal in einer Präsentation verteidigen muss. Also der Bachelor Professional hat da schon wirklich einen hohen Anspruch, weil man sagt, okay, du sollst aber auch in der Lage sein, deinen Unternehmensbereich, dein Team personal, wirtschaftlich, aber auch fachlich leiten zu können.

Stefan:
[13:54] Okay, dann. Du hattest es gerade auch noch gesagt, Personal und Ausbildung. Ich weiß, glaube ich, bei der Meisterprüfung muss man auch den Ausbilderschein quasi mitmachen oder der ist da mit drin? Wäre das hier jetzt auch so, dass man den quasi am Ende hat?

Thomas:
[14:07] Auch wie der IHK-Logik, man hat nur den schriftlichen Teil, weil das ist, was in der Prüfung mit abgefragt wird und da muss man quasi noch die mündliche Prüfung ablegen für den Ausbilderschein. Aber das ist ja auch schnell gemacht, muss man sagen. Das ist dann kein großer Aufwand mehr.

Stefan:
[14:23] Ja, okay. Ja, sonst würde sich gerade der Abschlussprüfungsteil für den Bachelor Professional doch eher BWL, Personal, weil unternehmenslastig an, in Anführungszeichen, was aber, glaube ich, am Meister ja auch gar nicht so viel anders ist. Da geht es

Thomas:
[14:36] Ja auch darum.

Stefan:
[14:36] Wie führe ich mein Unternehmen und bin ich der beste Maurer, Tischler, was auch immer.

Thomas:
[14:40] Also vergleichbar wahrscheinlich. Und ich habe ja im Voraus, der erste Teil ist ja meine Spezialisierung. Also ich habe ja die erste Prüfung, was ich versucht habe zu erklären, ist ja eigentlich die Berufsspezialistenprüfung und da geht es halt um mein Fachgebiet. Also entweder Informationssicherheit oder Systemintegration. Und da bin ich natürlich den Fachlich erstmal nochmal gefordert.

Dauer und Organisation der Weiterbildung

Stefan:
[15:01] Kannst du schon mal so ganz grob sagen, von was für einem Zeitaufwand man da redet? Also ist jetzt so, weiß nicht, der Berufsspezialist, ist das so ein Jahr und der Bachelor sind dann zwei Jahre insgesamt oder wie kann man das so grob sagen, wie lange das dauert?

Thomas:
[15:17] Man muss ja rechnen, so die Zeit, die ich brauche oder wir zum Beispiel brauchen, das Wissen zu vermitteln und dann gibt es das Prüfungsverfahren. Um den Inhalt für den Berufsspezialisten zu vermitteln, so circa sieben Monate. Wenn ich jetzt im Abendkurs, also es gibt immer Variante, sieben Monate zum Beispiel im Abendkurs, zweimal pro Woche abends Unterricht, 18 bis 21 Uhr wäre eine Variante. Es gibt auch die Möglichkeit, dass fünf Wochen am Stück, hat man wirklich Montag bis Freitag, acht bis siebzehn Unterricht, dann könnte man es in fünf Wochen das Wissen schaffen. und dann kommt die IHK mit ihrem Prüfungsverfahren. Die schriftliche Prüfung ist fix terminiert. Da gibt es zwei Prüfungstermine, so wie bei der Ausbildung auch. Wird bundesweit dieselbe Prüfung geschrieben, zum selben Zeitpunkt. Und dann danach legt die IHK aber die Münchenprüfungstermine selber fest. Da verlässt man dann schon die Planbarkeit. Aber in der Regel so ein bis drei Monate muss man ja auch mal für die Zeitrechnung dann je nach IHK, wann tatsächlich die Münchsprüfung ist, wann man als Berufsspeziales fertig ist.

Stefan:
[16:31] Und doore Frage vielleicht, aber ich weiß jetzt nicht, wie verbreitet die Sachen schon sind. Kann ich dann zu meiner lokalen IHK die Prüfung machen oder muss ich da eventuell auch irgendwo nach München, weil es zu wenig Prüflinge gibt?

Thomas:
[16:42] Im Moment muss man tatsächlich wahrscheinlich fahren, weil es von den knappen 80 IHKs, die es gibt, im Moment so sieben erst mal sind, die beim ersten Prüfungsdurchgang das anbieten, sodass man tatsächlich da jetzt im Moment noch Fahrzeit in Anspruch nehmen muss aber es werden jetzt immer mehr aber die IAKs waren tatsächlich auch ein bisschen überrascht, wie viele das sofort machen wollten, und waren da gar nicht so richtig drauf vorbereitet dass tatsächlich Prüflinge vor der Tür stehen.

Stefan:
[17:10] Aha das heißt, das wäre auch schon immer eine wichtige Frage es gibt auch schon Menschen, die das machen wollen und auch schon machen es gibt

Thomas:
[17:16] Schon laufende Kurse im Februar nächsten Jahres ist die erste Prüfung.

Stefan:
[17:22] Okay, also wirklich die allererste? Die allererste, genau.

Thomas:
[17:27] Das sind dann die allerersten ihrer Art, die dann in die Prüfung gehen und diese Nachweise abdecken können.

Stefan:
[17:36] Okay, klasse. Gut, dann hat man natürlich jetzt auch noch wenig Referenz, was da so in den Prüfungen drankommt. Aber wenn der erste Teil, jetzt der Berufsspezialist, eher technisch, eher fachlich ist und ich dann zum Beispiel Security, Datenanalyse habe ich mitgeschrieben, Systemintegration, Das wäre tatsächlich nochmal eine Möglichkeit, wenn ich nach der Ausbildung denke, also die Ausbildung ist ja inzwischen relativ breit, weil wir diese sieben Berufe haben, die ersten 18 Monate sind gleich. Wenn ich jetzt mal richtig Lust habe auf Security, und das war mir zu wenig in der Ausbildung, könnte ich ja gezielt in dem Bereich dann nochmal, wenn du jetzt sagst, ich sag mal so ganz grob über den Daumen, so ein Ja inklusive Vermittlung und der Prüfung, dann nochmal wirklich tief in das Thema rein, was mich auch interessiert. Ja, genau.

Thomas:
[18:13] Also das ist wirklich so, wo ich sage, ich will fachlich nochmal weiter, ich will es auch tatsächlich auf einem höheren Niveau nachweisen können. Dann geht es erstmal in diesen Berufsspezialisten rein und dann hat man da, wie schon gesagt, ein Jahr sollte man einfach durch sein, egal bei welcher IHK ich gelandet bin. Das ist eigentlich auch ein guter Abschnitt und dann kann ich halt weitermachen, wenn ich will, wann ich will auch, wenn ich diesen Berufsspezialisten zum Beispiel schon habe mit dem Bachelor Professional, um die Frage zu wenden, dann brauche ich ungefähr nochmal ein Jahr im Abendkurs für den Unterricht oder neun Wochen Vollzeit, um das ganze Wissen zu vermitteln. Und dann kommt dieses Prüfungsverfahren. Und das ist tatsächlich noch nicht so ganz absehbar, wie die IHKs das takten, wie schnell sie es durchführen können. Ja, aber da wird wahrscheinlich ein halbes Jahr das ganze Prüfungsverfahren einfach schlichtweg laufen. Weil auch bis die Prüfungen durchgeführt sind, die Klausuren ausgewertet sind. Und dann ist aber die Phase, den einen Punkt bestimmt man auch so ein bisschen selber mit, weil man hat dann ja die Projektarbeit, die man schreiben muss, man hat theoretisch ein Jahr Zeit. Projektarbeit abzugeben, hat aber eigentlich nur 30 Tage Bearbeitungszeit. Aber ich bin ja selber für zuständig zu sagen, wann lege ich mir diese 30 Tage hin.

Stefan:
[19:30] Okay. Aber so ein bisschen zeitlicher flexibel, wo es einem gerade, wenn es auch ein echtes Projekt sein soll, muss ja auch vielleicht der Bedarf im Unternehmen da sein und so weiter. Ist ja bei der IHK-Prüfung, für die Abschlussprüfung der Ausbildung auch immer so schwierig. Genau in diesem Zeitraum der drei Monate musst du ein Projekt haben. Das ist manchmal ja auch schwierig. Und wenn es vielleicht auch noch ein bisschen Größeres jetzt sein muss für diese Prüfung. Ja, okay. Ist ja schon mal gut.

Thomas:
[19:50] Kann man noch ein bisschen sich.

Stefan:
[19:51] Das selber gestalten. Wenn wir da jetzt eintauchen wollen und diese Vorbildung machen wollen, die Voraussetzung ist, dass ich einen einschlägigen Berufsabschluss habe oder kann das einfach jetzt jeder machen,

Zugangsvoraussetzungen zur Prüfung

Stefan:
[20:03] diese Berufsspezialist-IT oder muss ich eine IT-Ausbildung vorher haben?

Thomas:
[20:07] Du kannst auch Praktiker sein. Also da sagt auch die IHK, hey, wir wissen, es kann nicht jeder eine Fachinformatika-Ausbildung gemacht haben. Das funktioniert ja auch nicht. Ich kann da eben auch als Praktiker einsteigen und sagen, okay, jetzt will ich auch mal einen Nachweis haben zu dem, was ich vielleicht die letzten Jahre gemacht habe. Und dann ist tatsächlich die Frage, wie war mein Berufshintergrund? Zum Beispiel, keine Ahnung, Kaufmann für Berufsmanagement gelernt und dann ein Jahr Berufserfahrung in der Informationssicherheit gesammelt. Auch dann kann ich zur Prüfung gehen oder ich habe eine andere Ausbildung gemacht, die, keine Ahnung, meinetwegen auch Fachlager ist und habe in einem Jahr in dem Bereich gearbeitet. Ich kann auch ein Studium begonnen haben und 60 Punkte, ECTS-Punkte gesammelt haben und danach zwei Jahre gearbeitet haben. Oder du bist der Praktiker durch und durch und hast vier Jahre Berufserfahrung im IT-Bereich gesammelt, dann kannst du auch zur Prüfung zugelassen werden.

Stefan:
[21:20] Aber das ist ja eine coole Sache, gerade so für Querensteiger, die endlich nochmal was auf Papier haben wollen, was ja immer wichtig ist in Deutschland.

Thomas:
[21:26] Ja, wir in Deutschland mögen Urkunden und Papier und dann kann das tatsächlich jetzt eine gute Methode sein, einfach mal einen Nachweis zu haben über das, was ich eigentlich schon kann, aber ich muss es halt mit einer Urkunde nachweisen.

Chancen für Quereinsteiger

Stefan:
[21:40] Ja, und das finde ich jetzt ganz spannend, weil sonst müsste ich halt alternativ diese drei Jahre Ausbildung in Anführungszeichen machen und dafür dann die Prüfung machen, was mich im Bereich IT-Security auch nicht so richtig weiterbringt, weil ich dann nochmal irgendwie Hardware und ich weiß nicht, was von Anfang an lernen muss. Das finde ich auch eine schöne Alternative, gerade für Queer-Einsteiger. Jetzt hattest du eben schon gesagt, also wir haben jetzt auch gerade darüber geredet, Papier, Deutschland, wichtig, aber du hattest eben ganz am Anfang gesagt, dass die alten Operative Professionals abgelöst wurden, weil die Arbeitgeber das irgendwie gar nicht so richtig haben wollten oder vielleicht, weiß ich nicht, anerkannt haben, weiß ich nicht. Wie sieht es denn dann bei den neuen Abschlüssen aus? Weil das fragen sich natürlich auch alle. Also soll ich jetzt ein Jahr investieren und am Ende sagt der Arbeitgeber, hä, was hast du da denn gemacht, kann ich nicht?

Thomas:
[22:18] Das ist wahrscheinlich schwierig. Ich kann natürlich nicht für alle Arbeitgeber in Deutschland sprechen.

Anerkennung der neuen Abschlüsse

Thomas:
[22:22] Es ist natürlich jetzt auch persönliche Ansichten mit dabei. Das, was ich einfach sagen kann, dass Arbeitgeber an diesem Abschluss mitgearbeitet haben.

Thomas:
[22:35] Also die Inhalte bei der Bearbeitung waren sie mit dabei. und aber auch die Forderungen nach den Berufsspezialisten, insbesondere kamen aus dem Arbeitgeberbereich auch mit. Das heißt, das Grundinteresse ist von Arbeitgeberseite schon mal da. Ich kenne die Diskussion, die immer sagt, ja, aber ohne Studium bist du einfach nichts. Im IT-Bereich gab es bis jetzt auch nie eine Alternative. Und grundsätzlich ist es natürlich immer so, warum sollte sich etwas im IT-Bereich nicht durchsetzen, was auch in anderen Bereichen gang und gäbe ist. Ich muss ehrlich sein, wenn das Karriereziel ist, in einem Großunternehmen, in einer großen AG, Tätig zu sein und eine Führungskraft zu werden, wird man das ohne Studium in der Regel nicht schaffen. Ich will jetzt keine Namen nennen, aber wenn ich die großen Aktienkonzerne nehme, die groß tätig sind, da falle ich im Bewerbungsverfahren durch die computergestützten Verfahren einfach raus, wenn da kein Diplomokunde oder Masterbookkunde drin ist. Das ist einfach so. Wir haben aber ganz viele KMUs, kleine mittelständische Unternehmen in Deutschland.

Thomas:
[23:49] Da sind diese Fachwirte bekannt und gesetzt und öffnen Türen. So, und jetzt ist halt die Frage, warum soll sich das nicht durchsetzen? Insbesondere, weil man jetzt eben auch, finde ich, fachlich deutlich nachgeschärft hat und die Möglichkeiten geschaffen hat, sich fachlich zu qualifizieren und dann ja später tatsächlich noch diese Führungsperspektive einzunehmen, was vorher einfach nicht da war. Also dieser Abschluss hat es aber auch nie geschafft, bei den Teilnehmern anzukommen. Und was ich jetzt schon höre und auch von den Gesprächen, die wir mit verschiedenen IHKs hatten, im Moment noch ein Gefühl, lässt sich statistisch noch nicht nachweisen, aber scheint die Nachfrage jetzt schon höher zu sein, als in den ganzen Jahren vorher zu den anderen.

Stefan:
[24:32] Okay, krass.

Thomas:
[24:35] Wir sprechen über erste Prüfung nächstes Jahr im Frühjahr, aber trotzdem ist da jetzt schon anscheinend mehr Interesse einfach dahinter, als es vorher jemals bei den anderen Abschüssen gewesen ist.

Stefan:
[24:45] Ja, cool. Ja, finde ich gut. Also ich bin nun auch in der Versicherung und ich weiß, unsere Versicherungsazubis machen nach der Ausstellung auch ganz oft tatsächlich den Versicherungsfach wird. Da ist es eher die Ausnahme, dass man danach studieren geht und in der IT kenne ich es jetzt viel, dass die Leute halt nachher studieren gehen, aber ich habe jetzt in den letzten Jahren auch selber bei meinen eigenen Azubis auch welche dabei gehabt, die nicht sofort einfach studieren gehen, die aber sich vielleicht trotzdem noch irgendwie weiter qualifizieren wollen, aber jetzt halt irgendwie nicht drei, dreieinhalb Jahre nach Studium und dann wieder raus aus dem Job und das ist ja auch dann immer wahrscheinlich auch mit Einbußen beim Gehalt verbunden, weil man ja weniger arbeiten kann und so. Und wenn das jetzt hier, sag ich mal, berufsbegleitend, klar ist auch anstrengend am Abend, logisch, aber ich kann Vollzeit arbeiten, ich kann mich technisch in dem Bereich auch weiterentwickeln, wo ich auch wirklich was machen will. Also, was waren das? Sieben verschiedene Fachrichtungen habe ich, glaube ich, gerade mitgezählt. Da ist ja für jeden… Fünf. Für jeden was dabei. Ob Anwendungsentwicklung oder Systemorientation oder Analyse quasi. Also, das finde ich schon mal sehr interessant. Und… Ja, wenn ich dann noch weiter hoch möchte in Richtung Personal, Teamleitung, wie auch immer, kann ich ja dann noch den Bachelor direkt am Anschluss machen. Also den Bachelor Professional natürlich. Ja, das hört sich auch immer erstmal interessant an, würde ich sagen.

Ablauf der Weiterbildung und Kontaktmöglichkeiten

Stefan:
[25:54] Dann sind wir ja schon direkt bei der Frage, wie mache ich das jetzt? Also ihr bildet ja diese Menschen aus, habe ich jetzt so verstanden. Und wie läuft das dann ab? Also du hast jetzt schon gesagt, es gibt Abendkurse, es gibt so Blog, sage ich jetzt mal, Blogvermittlung. Ist das in eurem Fall deutschlandweit? Ist das lokal? Wie kannst du da ein bisschen was erzählen, wie das abläuft?

Thomas:
[26:13] Genau. Wir machen das tatsächlich alles online. Daher, egal wo man sitzt, es ist uns noch über die altbekannte Plattform Teams. Die wird jeder irgendwie kennen. Wir haben unsere Fachdozenten, die wir einkaufen, um eben dieses Fach-Know-how auch vermitteln zu können. Weil es natürlich, ja, um die IHK-Prüfung am Ende geht. Aber es soll ja auch fachlich was gelernt werden. Das ist zwischendurch, kann das mal ein Spannungsfeld sein, weil man weiß, ich muss dir jetzt gerade ein Verfahren beibringen, was du vielleicht in der Praxis nicht benutzen wirst, aber ich weiß, dass die IHK draufsteht.

Stefan:
[26:51] Das kennen wir schon aus der Ausbildung.

Thomas:
[26:53] Genau, also dieses Spannungsfeld haben wir da halt auch, aber trotzdem setzen wir natürlich Dozenten ein, die es auch praktisch anwenden können, die den Unterricht vermitteln. Und dann ist eben die Frage, genau, wie will ich das in mein Leben integrieren? Wie kann ich das am besten für mich umsetzen? Das ist eine Variante der Abendkurs, wo ich zweimal in der Woche abends von 18 bis 21 Uhr mich online einlogge. Der Dozent ist da, vermittelt das Wissen, Es werden Fragen beantwortet, Fragen geklärt, Aufgaben bearbeitet, sodass man auch diese Anwendung lernt. Oder eben die andere Variante, ich blogge mir das über Bildungsurlaub, ist eine Möglichkeit, und mache fünf Wochen am Stück frei, sozusagen von der Arbeit, um den Berufsspezialisten zum Beispiel zu machen, um mich dann vorzubereiten und dann zur Prüfung zu gehen. Das ist auch gut möglich mittlerweile bei fünf Wochen, ist das so ein Zeitansatz, besonders wenn ich Bildungsurlaub nehmen kann. Es sind in vielen Bundesländern sogar zwei Wochen, die ich über Bildungsurlaub dann einfach abfedern kann und vielleicht noch Überstunden oder noch ein bisschen Urlaub in den West reinbringen. Das ist auf jeden Fall stemmbar, finde ich, fünf Wochen ganz gut, um das eben abzuleisten. Und was wir dann immer noch dazugeben, nicht nur den Unterricht, wir haben Übungsaufgaben, die wir haben, wir haben Fallstudien und Klausuren, die wir an den IHK-Praxis ausrichten.

Thomas:
[28:22] Auch wenn das jetzt ein neuer Beruf ist, wissen wir sehr genau, wie die IHK die Fragen stellt auf dem Niveau. Das heißt, wir haben im Moment noch eigene Prüfungsszenarien, die wir schreiben, sodass man dieses Verfahren einfach kennenlernt, wie ich die IHK-Prüfung verstehen muss. Was erwarten die von einem, um da einfach vorbereitet zu werden? Und dann ist es tatsächlich auch so, bei den Münchenprüfungen, dass wir die auch simulieren. Das heißt, ich muss ja ein Thema abgeben, ich muss eine Präsentation vorbereiten. Es ist tatsächlich so, dass man jeder Prüfung eine Generalprobe hat, wo die Präsentation gehalten wird, so wie man sie halten möchte. Nur, dass es halt online ist, also wir treffen uns ja nicht, es ja bundesweit Teilnahme sein soll. Und wieder ein Feedback geben aus Sicht, was war gut, was stelle ich, wo könnte man vielleicht was verändern, wie könnte sich so ein Fachgespräch danach entwickeln, wonach kann man gucken. Da setzen wir in der Regel dann eben auch Leute mit Prüfungserfahrung ein, die wirklich auch bei der IHK Prüfer sind. Dann hat man halt nochmal das speziellere Auge drauf, was einen da so erwarten kann. Und dann wartet da so eine Prüfung auf einen, die man schreibt und dann natürlich hoffentlich gut besteht.

Stefan:
[29:40] Ja, cool. Jetzt haben wir gerade schon gehört, das ist ein bisschen ein zeitlicher Invest. Okay, das kriegt man für immer irgendwie hin. Jetzt ist das ja, also ich weiß nicht, wenn ich jetzt studieren gehen will, an der normalen Uni in Anführungszeichen, da gibt es vielleicht ein paar Studiengebühren, vielleicht auch mal nicht. Wenn ich dual studiere, okay, das sind natürlich utopische Summen, die die Unternehmen da für mich zahlen. Wie sieht es denn hier aus, wenn ich jetzt so einen Kurs bei euch zum Beispiel machen will? Der wird ja bestimmt noch nicht kostenfrei sein. Kann ich den, keine Ahnung, in 700 Raten zahlen? Gibt es da irgendwie Förderungen durch irgendwen? Wie funktioniert sowas?

Thomas:
[30:11] Also grundsätzlich, ich habe auch mein Leben zu finanzieren. Wir müssen Geld nehmen, sonst funktioniert es halt nicht und die Dozenten, die wir einsetzen, wollen eben auch Geld haben. Das ist immer so.

Finanzierung und Fördermöglichkeiten

Thomas:
[30:23] Aus Hobby macht das leider keiner. Das heißt, es kommt Geld auf einen zu und wir sprechen bei uns im Fall beim Berufsspezialisten über 3.500 Euro. Ich runde das mal kurz glatt, auch wenn wir knapp da unterliegen, die das kostet.

Stefan:
[30:43] Da habe ich natürlich die Möglichkeit,

Thomas:
[30:44] Vielleicht meinen Arbeitgeber zu motivieren, das zu bezahlen, weil ich sage, wir wollen langfristig gut zusammenarbeiten. Wie sieht es aus? Hast du was da für mich? Kannst du das für mich übernehmen? Und sonst gibt es für die Bezahlung des Ausstiegs-BAföG in Deutschland. Das Ausstiegs-BAföG bringt 75% Förderung, die dann einfach der Staat übernimmt. Was, finde ich, sehr attraktiv ist und ein sehr gutes Angebot ist. Und grundsätzlich ist es so… Es ist so geplant, dass es zwei Zeitungstermine gibt. Also die 1.500 Euro sind in zwei Raten zu bezahlen. Immer nach der Hälfte der Fortbildung zum Ende der Fortbildung, sodass man das auch gut vorbereiten kann. Und dass die Ämter, die das Ausstiegs-Bafög bewilligen, das hoffentlich bis dahin auch bearbeitet haben. Ja, auch richtig. Wobei man hier sagen muss, dass sich dann tatsächlich an einzelnen Ämtern, wenn es vielleicht länger dauert, Grundsätzlich ist nämlich die Antragstellung relativ einfach, weil es kaum Voraussetzungen gibt, Ausstiegs-BAföG zu bekommen. Jeder, der mit dem Studenten-BAföG zu tun hatte, den Herzinfarkt schon mal bitte beseitigen und zurückfahren, weil das ist ein komplett anderes Programm. Ich brauche genau drei Anträge, drei Zettel, die ich Formblätter, die ich abgeben muss. Und das war es schon. Und zwei davon muss man nicht selber ausfüllen.

Stefan:
[32:14] Ach, das ist gut.

Thomas:
[32:16] Und es gibt nämlich eigentlich erstmal eine Kernvoraussetzung, die ich erfüllen muss, um das Ganze zu bekommen. Und zwar, die IHK muss mir die Zulassungsvoraussetzung bestätigen. Das heißt, die IHK muss wirklich sagen, ja, ich lasse ich zur Prüfung zu. Sondern haben wir vorhin einmal besprochen, wenn man Fachinformatiker zum Beispiel ist, wird man zur Prüfung zugelassen. Weil man hat die Hauptvoraussetzung erfüllt oder vier Jahre Praxis im Bereich Softwareentwicklung kann ich auch zur Prüfung zugelassen werden. Habe ich den großen dicken Haken von der IHK bekommen, ja ich lasse dich zu.

Thomas:
[32:54] Und dann gibt es quasi nur noch zwei Ausschlusskriterien. Ausschlusskriterium eins, ich darf nicht schon Ausstiegs-BAföG bekommen haben für einen Abschluss, zum Beispiel hier auf D-Cur 5 Niveau. Oder wenn ich Bachelor Professional werden möchte, darf ich nicht schon mal Ausstiegs-BAföG bekommen haben für einen D-Cur 6 Abschluss. Zweiter Ausschluss, der da nicht da liegen darf, ich darf kein Masterstudium abgeschlossen haben. Wo man auch sagen muss, wenn ich ein Masterstudium abgeschlossen habe, warum sollte ich dann eine Berufsspezialistenfortbildung eigentlich noch machen. Aber es ist was anderes. Das heißt, IHK sagt ja und die anderen beiden Male sage ich nein, habe ich die Vorsetzung fürs Ausstiegs-Baföck erfüllt.

Förderung durch Ausstiegs-BAföG

Thomas:
[33:40] Es findet keine Einkommensprüfung statt, es findet keine Vermögensprüfung statt.

Stefan:
[33:48] Und dann würden die tatsächlich 75% einfach dieser Kosten erstellen.

Thomas:
[33:52] Genau. Zwei-stufig tatsächlich. Stufe 1 ist 50% Zuschuss, die ich bekomme. Und damit ist die erste Hälfte schon mal geklärt. Für die zweite Hälfte kriege ich ein zinsgünstiges Darlehen über die Kreditanstalt für Wiederaufbau, KfW.

Stefan:
[34:13] Okay.

Thomas:
[34:16] Mit dem Schreck immer, ich muss ein Darlehen aufnehmen. Ich muss es aber aufnehmen, um die volle Förderung zu bekommen, weil wenn ich nachher meinen Urkunden als Berufsspezialist zum Beispiel habe, wird mir die Hälfte des Darlehens erlassen. Das heißt, ich kriege 75% Förderung nur, wenn ich das Darlehen auch in Anspruch nehme. Wenn ich das Darlehen nicht nehmen würde, habe ich nur 50% Förderung.

Stefan:
[34:42] Und Förderung heißt es aber, ich kenne jetzt BAföG so, dass man das ja auch mal irgendwann zurückzahlen muss. Das ist jetzt hier wirklich

Thomas:
[34:47] Das Darlehen ist tatsächlich, weil es ein Darlehen ist, muss ich zurückbezahlen. Eben die Hälfte nur noch von dem, was ich bezahlt habe. Und ich habe zwei Jahre, es ist zins- und tilgungsfrei.

Stefan:
[35:00] Okay.

Thomas:
[35:01] Und dann liegt nachher die Mindestrate bei 128 Euro im Monat oder ich bezahle es halt auf einen Schlag.

Stefan:
[35:08] Okay. Ja, wobei man das sagen muss, also wenn wir jetzt hier von 300.000 Euro reden, selbst mit der ganzen Geschichte. Klar, das ist für viele Menschen trotzdem viel Geld, das ist keine Frage. Aber wenn ich in IT bin und schon eine Fortbildung habe und dann mit 128 Monaten bin ich ja nach, selbst wenn ich alles zahlen muss nach zwei Jahren durch, also es ist ja überschaubar. Und wenn ich jetzt sage so, also dreieinhalb Tausend, ich weiß, dass einige Hochschulen für ein duales Studium im Semester schon mehr nehmen. Also da sind wir ja schon bei einem, also ich finde jetzt mal, meine persönliche Meinung auf den ersten Blick jetzt ein recht humaner Betrag, dafür, dass

Thomas:
[35:36] Ich schon einen.

Stefan:
[35:36] Nächsten Abschluss habe nach dieser Zeit und nicht das Ganze mal sieben nehmen muss, bis ich den Bachelor abnehme.

Thomas:
[35:43] Man muss halt die Begleitkosten auch mit einbrechen. Ich kann halt in der Zeit, insbesondere wenn ich den Abendkurs zum Beispiel mache, einfach weiter arbeiten. Das heißt, ich habe dieses Problem nicht, wenn ich an eine Uni gehe, dass ich ja eigentlich ein Vollzeitstudium vielleicht mache und von null, also plötzlich auf null sitze, weil ich gar nicht mehr arbeite oder mir einen Nebenjob irgendwie suchen muss oder so. Das habe ich in diesem Fall einfach nicht. Das ist der große Luxus, der dabei entstehen kann. Wenn ich jetzt den Bachelor Professional vielleicht der Vorständigkeit habe, aber noch drauf rechne. Da sind wir bei 4.500 Euro, mal kurz glatt gerechnet, die noch dazukommen, um den nächsten Teil nachher noch zu absolvieren. Aber auch da kann ich wieder Ausschicksmafe kriegen. Das heißt, auch da 75% Förderung. Das heißt, ich kann wirklich beide Schritte machen. Spannenderweise beim Bachelor Professional, wenn ich den mache und ich noch aus einem guten Bundesland komme, kriege ich sogar noch Geld geschenkt nachher. Weil zum Beispiel in Bayern gibt es einen Meisterbonus. Da kriege ich 3000 Euro nachher von der IHK als Bewerb. Auszeichnung deiner Arbeit überwiesen und dann hast du sogar noch mehr Geld eigentlich am Ende als vorher.

Stefan:
[37:00] Okay. Ich kenne das jetzt, ich weiß auch nicht, ob alle IHK-Nas machen bei uns in Oldbrook, habe ich das schon öfter gesehen, wenn man zum Beispiel einen Einserabschluss in der Ausbildung gemacht hat, dann kriegt man auch so einen, ich weiß gar nicht, wie das dann, also ein Bildungsgutschein ist das falsche Wort, aber irgendwie so eine Art, hier, wenn du hier was einreichst, erstatten wir dir Weiterbildungskosten. Es darf kein Studium sein, aber dafür könnte man ja genau jetzt so diesen Bereich hier einschlagen.

Thomas:
[37:21] Das wäre die zweite Möglichkeit, das sogenannte Weiterbildungsstipendium oder die Begabtenförderung.

Stefan:
[37:26] Ja, das genau, Begabtenförderung,

Thomas:
[37:28] Ja. Genau, das ist im Notendurchschnitt besser als 1,9, wenn ich es jetzt gerade richtig im Kopf habe. Und da ist halt praktisch, da kriege ich ein Gesamtbudget von über 8.000 Euro, was ich für Fortbildung einsetzen kann. So, und dann, da ist tatsächlich die Förderquote 90 Prozent, da sagt die IHK 10 Prozent, musst du denn bitte schon gerne selber investieren.

Stefan:
[37:53] Das ist ja durchaus überschaubar, wenn man fertig ausgelenkt ist, das Geld verdient. Okay, klasse. Ja, also so in der Kombi, wenn ich eine, also es muss ja noch nicht mal eine sehr gute Ausbildung sein, 1,9, wie man die Note regnet. Und dann noch zusätzlich das Aufstiegs-Bafög, da ist man ja echt bei nicht mehr so ganz so viel, was am Ende ruhig bleibt. und dann hat man aber auch einen offiziellen Abschluss, der dann hoffentlich dann auch in Zukunft gut anerkannt

Zukunftsperspektiven nach der Weiterbildung

Stefan:
[38:16] ist bei den Arbeitgebern. Und ich kann vor allem, das finde ich, aus der Erfahrung wollen halt auch ganz viele IT-Hazouis, die wollen halt eben nicht dieses betriebswirtschaftliche und bla bla bla, sondern die wollen halt Technik. Und wenn man jetzt hier gerade im ersten Schritt auch die Technik vertiefen kann, ist das natürlich eine schöne Sache, finde ich. Also, hört sich echt

Thomas:
[38:33] Sehr aktiv an. Ich habe halt auch den Vorteil, dass ich einfach sagen kann, komm, ich will jetzt erstmal der Fachexperte Nein, ich will die Technik machen und mache den Berufsspezialisten. Und dann ist das mal gut. Und wenn ich fünf Jahre später feststelle, jetzt will ich doch noch mehr, ja, dann mache ich halt die Bachelor-Professionelle. Auch die Möglichkeit habe ich ja. Also ich muss ja gar nicht das sofort alles machen, weil das Leben verändert sich auch. Und vielleicht ist jetzt gerade das Thema, ich will mehr, ich will höher hinaus, nicht das Ding. Aber in ein paar Jahren weiß man ja nicht. Und dann habe ich halt immer noch die Möglichkeit zu sagen, und jetzt fange ich an der Stelle nochmal an und mache halt die Schritte, die mir noch fehlen, für einen Bachelor Professional.

Stefan:
[39:21] Aber wenn ich jetzt nochmal ganz weit weiter denke, ich weiß nicht, ob du das jetzt weißt, Aber wenn das jetzt nach dem DQR, der Bachelor Professional, wirklich wie ein Bachelor zu sehen ist, kann ich darauf aufbauen, dann vielleicht sogar noch ein Masterstudium wirklich machen, wenn ich dann doch noch in der Behörde durchstarten will oder geht das dann nicht?

Thomas:
[39:37] Also das hängt dann wieder von den Unis ab. Es gibt verschiedene Universitäten, die Sachen anrechnen und dies möglich machen, aber das sind tatsächlich immer Einzelfallprüfungen. Es gibt auch verschiedene Unis, die sagen, okay, du hast jetzt ein Bachelor mit Professional in IT, ich rechne dir x Trader-Points an für einen Bachelor. Oder es gibt eben auch tatsächlich vereinzelte Universitäten, die dann halt sagen, okay, du darfst jetzt direkt den Master machen. Und soweit die die Möglichkeiten haben, das ist auch eine Möglichkeit, weil das wäre vielleicht jetzt auch ein kleiner Pferdefuß im Moment noch an der Geschichte. Im öffentlichen Dienst tariflich ist es zwar anerkannt, wenn ich aber in die höhere Laufbahn möchte, brauche ich dieses universitäre Studium. Es kann mir zwar der Bachelor Professional bei der Bezahlung helfen, wenn ich aber wirklich in eine andere Laufbahn aufsteigen möchte, muss ich tatsächlich dieses klassische Studium an der Universität oder an der staatlichen Fachhochschule gemacht haben.

Stefan:
[40:43] Okay, aber wie du eben auch schon sagtest, ich meine, da arbeiten ja nicht alle Menschen in Behörden und in irgendwelchen Großkonzernen, wo das so viel so wichtig ist. In vielen anderen Unternehmen geht es ja darum, was ich kann, was ich fachlich mitbringe. Und wenn ich dann das noch, also ich sage ganz blöd, ich kenne von vielen Azubis, wenn wir die so fragen nach der Prüfung so, ja und wie geht es jetzt weiter und machen sie so was? Nö, erst mal arbeiten. Ich will erst mal Geld verdienen. Ich will erst mal das machen, was ich jetzt gelernt habe. Ich will erst mal anwenden, weil sind wir ganz ehrlich, nach der Ausbildung kann man auch jetzt noch nicht alles. Es hört das Lehren ja nicht auf. Und wenn ich dann mal irgendwie im Beruf wirklich jetzt ankommen will, als Junior, wie auch immer mich hocharbeiten will und dann aber trotzdem mich auch zusätzlich nochmal quasi, ich sage jetzt mal ganz blöd, durch so eine Berufsschule in Anführungszeichen, wie euch unterstützt, weiterqualifizieren will, dann habe ich da ja eine Möglichkeit, wo ich jetzt nicht wieder jede Woche zur Berufsschule muss, wo ich einen begrenzten Zeitraum habe, was von den Kosten her durchaus überschaubar ist. Dass ich am Ende aber einen richtigen Abschluss habe. Und ich kann, wenn, wie du sagst, schon sich das Leben irgendwann mal ändern, und ich will doch Teamleiter oder was auch immer werden, ja einfach weitermachen

Thomas:
[41:40] An der Stelle. Und muss dann nicht.

Stefan:
[41:42] Jetzt wieder einen ganz anderen Weg gehen und zurück an die Uni auf Null, so nach dem Motto. Deswegen gehört sich das jetzt erstmal, wie du auch sagtest, wenn die Arbeitgeber mit dabei gearbeitet haben bei der Neuordnung da, finde ich eine super Sache. Gerade für Leute, die halt wirklich mehr in die Praxis wollen.

Thomas:
[41:56] Und ja, wo.

Stefan:
[41:57] Ist der Haken, frage ich mich. So gibt es einen.

Thomas:
[42:03] Also aus meiner Sicht sind diese Haken, die Frage ist, wo will ich beruflich hin? Das, was ich schon erwähnt hatte, wenn ich weiß, ich will in die großen Konzerne, dann kann ich damit nicht weitergehen. Das ist einfach so. Und der Rest ist tatsächlich auch, ich glaube, diese Abschlüsse, ich kann nur in die Zukunft gucken, haben das Potenzial, sich durchzusetzen. Dafür sind wir aber alle zuständig. Also das sind die Arbeitgeber, das sind die IHKs, das sind aber auch alle Teilnehmer, die einfach dann auch zeigen müssen, das bringt doch auch was. Also den Nachweis hat man bei anderen Abschlüssen aus dem IHK-Bereich schon geführt. Sonst würden nicht zwischen 6.000 und 8.000 Leute ein Wirtschaftsfach, ein Handelsfach und solche Abschlüsse machen, wenn es keiner brauchen würde und es keinen Sinn machen würde. Und diesen Nachweis müssen wir natürlich jetzt irgendwie erst schaffen, aber wie gesagt, im nächsten Jahr sind die ersten Prüfungen. Und wenn alle mitmachen und auch zeigen, was dahinter steckt,

Abschlussgedanken und Ausblick

Thomas:
[43:12] uns auch nachher in die Praxis überführen können, wird das auf jeden Fall wirklich an den Markt ankommen. Aber da sind wir mit zuständig, das selber umzusetzen.

Stefan:
[43:25] Also ich habe zumindest aus Reihen der Politik öfter gehört, dass jetzt ja die Ausbildung in Deutschland auch gestärkt werden soll, Fachkräftemangel etc. Und da wird ja auch aktiv dran gearbeitet, dass eben dieser Bachelor Professional mit dem Bachelor der Uni gleichgestellt wird und ist ja jetzt nach dem Rahmen ja auch, aber die arbeiten auch dran, dass es in der Praxis irgendwie wirklich auch ankommt und nicht nur auf dem Papier so ist. Habe ich zumindest mitbekommen. Deswegen, ja, ich glaube, von der Seite gibt es auch eine Tendenz, dass das unterstützt werden soll oder auch wird. Und genau, wenn wir auch noch mitmachen, jo. Also ich finde es super, weil es ist in ganz vielen anderen Berufen und ob es jetzt Handwerk ist oder wie auch immer, diese klassische Techniker- Meister-Geschichte oder die Fachwerte gibt es halt überall. In der IT ist es halt immer so, jo, muss halt studieren. Obwohl, muss man ja nicht. Also ganz ehrlich, wenn ich jetzt, auch wenn ich Softwareentwickler bin, da muss ich jetzt nicht für studiert haben. Das ist auch ein Beruf, den man erlernen kann, wo man sich spezialisieren kann. Und dann muss ich jetzt nicht nochmal einen Bachelor machen, wo ich nochmal Mathematik 1, 2, 3 und Statistik mache. Dann hilft mir bei der Programmierung auch nicht so wirklich weiter. Und ich habe die Prüfung jetzt hier natürlich noch nicht gesehen, aber es hört sich auf jeden Fall inhaltlich so an, dass werden sie deutlich technischer, deutlich fachlicher ausgerichtet als dieses Allgemeine, was man ja auch im Studium oft noch mit dabei hat. Und deswegen, ja, ich kann es nochmal sagen, hört sich auf jeden Fall erstmal spannend an.

Thomas:
[44:32] Also die Prüfungen sollen tatsächlich, sag mal, situationsbezogen sein. Das heißt, Es wird immer eine Unternehmenssituation dargestellt mit einem Unternehmen mit einer bestimmten Problematik. Ein Dienstleister von Software. Dann ist da vielleicht das Szenario beschrieben, dass ein Kunde etwas Neues braucht, eine neue Software und dann kommen Aufgaben dazu, die sagen, wie können wir das jetzt vorgehen. Also bestimmte Informationen versteckt mit Rahmenbedingungen, die ich dann eben analysieren muss, um dann eben für dieses Unternehmen die richtige Lösung zu entwickeln. Das heißt, ich soll wirklich in diesen Prüfungen schon diese Anwendung schaffen, wo es dann eben geht, gewisse Programmiertechniken vorzuschlagen, was für diesen Zusammenhang das Sinnvollste wäre. Und dann geht die Story durch und dann bin ich ja tatsächlich nachher auch bei der Münchenprüfung schon bei meinem Projekt, beim Berufsspezialisten oder wenn ich nachher beim Bachelor Professional bin, wo ich sage, eine Projektarbeit, die ich schreiben muss über ein Thema aus der Arbeit, also das ist wirklich praxisbezogen durch und durch.

Stefan:
[45:56] Ja, finde ich auch gut. Das ist, glaube ich, auch das, was vielen andersherum jetzt, wenn wir Leute eingestellt haben, die quasi direkt aus der Uni kamen, die zum ersten Mal die Praxis sahen quasi und dann nochmal von vorne anfangen bei der Software. Jetzt mal nur als Beispiel, die haben noch nie in der Uni irgendwo Git oder sowas gesehen, was wir halt im Alltag jeden Tag einsetzen. Und das geht halt in der Ausbildung, kannst es nicht weglassen, weil du brauchst es einfach. Und das fehlt denen dann zum Beispiel auch. Und ich glaube, das wollen viele. Die wollen was machen, die wollen Technik, die wollen ran, aber die wollen halt auch nicht nur in Anführungszeichen auf ihrer Ausbildung sitzen bleiben. Und ich finde das jetzt eine gute Möglichkeit für die, die dann wirklich auch, so, dann habe ich eine Prüfung gemacht und kann jetzt aber auch nicht was im Unternehmen anwenden und habe jetzt nicht irgendwie, keine Ahnung, einen mathematischen Beweis geführt, was mir auch in der Praxis wenig bringt, außer ich möchte Mathematiker werden, aber ich will ja Informatiker bleiben. Und ja, also finde ich gut.

Thomas:
[46:42] Es gibt Sachen, die man an der Uni lernt, die man an der Uni lernt und nie wieder braucht. Habe ich natürlich auch bei der Ausbildung zwischendurch auch, muss man ja auch sagen, aber hier ist tatsächlich immer wieder dieses Ziel, es soll beruflich ja was bringen. Deswegen dieses IHK-System, um zu sagen, wir wollen eine berufliche Schiene haben und eben eine Möglichkeit außerhalb dieses Studiums zu schaffen.

Stefan:
[47:06] Ja, finde ich super. Und auch nicht falsch verstehen, ich habe ja auch selber studiert, ich finde Studium auch gut, es hat alles Vor- und Nachteile. Und es gibt aber auch viele Menschen, die wollen halt in diesem Bereich was machen und dafür gibt es jetzt was. Und das finde ich echt klasse. Und deswegen würde ich so, wir sind schon bei einer Dreiviertelstunde, echt cool, wir haben auch schon viel durch. Für Leute, die jetzt wirklich sagen, Mensch, ich bin mal fertig mit der Ausbildung, oder ich bin es schon und möchte da jetzt wirklich mich mal informieren, möchte da weitermachen. Jetzt hast du gesagt, ihr bietet da ja was an. Wie können wir dann da starten? Also kann man dich kontaktieren oder euer Unternehmen, um sich da mal so ein paar Infos reinzuziehen? Wie machen wir das?

Thomas:
[47:38] Am besten, am leichtesten bei uns auf die Website, www.bze.com.de. Wirst du vielleicht sogar auch noch verlinken.

Stefan:
[47:48] Auf jeden Fall, packe ich alles in die Show Notes.

Thomas:
[47:50] Und dann kann man einfach uns anrufen, einen Videocall vor allem mal, WhatsApp schreiben. Wenn man Fragen hat, die Informationen sind alle da zum Lesen. Und dann muss man nur den richtigen Kanal auswählen, um bei uns eine Info einzuholen, wenn irgendwas unklar ist.

Stefan:
[48:07] Ja, perfekt. Das hört sich sehr niederschwellig an. Vor allem auch der WhatsApp-Kanal. Ja, cool.

Thomas:
[48:12] Ja, aber witzigerweise benutzt ihn keiner. Also, das ist irgendwie ganz spannend. Haben wir auch gedacht, jetzt geht’s los. Aber in der Praxis interessiert sich da irgendwie keiner für. Aber egal, eine Möglichkeit ist da. Ich hoffe, wir stricken noch dran. Denn wird hoffentlich irgendwann unser KI-3D-Avatar da sein, der dann berät, die Erstberatung machen kann.

Stefan:
[48:38] Noch besser, da muss ich gar nicht mehr mit Menschen reden, perfekt das Ganze auch noch online, ja guck mal da muss ich nirgendwo hinfahren ja, war ein Spaß, man muss natürlich ein bisschen mit den Leuten natürlich kommunizieren, aber es gibt ja auch viele die da vielleicht vor Zurückschrecken dann irgendwo anzurufen oder so, ja, aber finde ich gut, habt ihr verschiedene Kontaktmöglichkeiten ja, ich packe es alles in die Shownotes, bze.com.de nochmal wiederholt aber genau, Link gibt es natürlich auch in den Shownotes und ja, ich glaube wir sind durch, Mensch, ich habe alles abgehakt

Letzte Worte und Kontaktinformationen

Stefan:
[49:06] von meiner Fragenliste rund um diese neuen Abschlüsse. Das hat mir sehr viel Spaß gemacht und mich auch weitergebracht. Ich hätte noch eine letzte Frage, aber ich weiß nicht,

Thomas:
[49:12] Ob du dazu was sagen kannst.

Stefan:
[49:13] Wer prüft denn diese Leute? Also sind das IHK-Prüfer, die sonst auch die Ausbildung prüfen oder ist das ein spezieller Bereich? Weil das ist ja ein anderer Abschluss.

Thomas:
[49:23] Die IHK hat auch da grundsätzlich den Anspruch, Leute aus der Praxis dabei zu haben. So, kann natürlich sein, dass die, weil du bist ja, glaube ich, selber Prüfer, kommst aus der Praxis. dass man dann sagt, hey, hast du nicht auch Lust, die Berufsspezialisten in der Einfachgebung zu prüfen? Das ist natürlich eine Möglichkeit. Oder man eben sagt, okay, schreibt verschiedene Firmen an, die man eben kennt und sagt, wir brauchen jetzt auf dem Bereich noch zu diesem Prüfer. Kann uns jemand helfen? Ja, okay.

Stefan:
[49:55] Ja, vielleicht also jetzt für alle, die zuhören, die selber Prüfer sind und da vielleicht eben unterstützen wollen. Wie du auch schon sagtest, wir müssen alle daran arbeiten, dass die Qualifizierung hier überall erkannt wird. Da brauchen wir auch Prüfer. Kann ich auch für die Ausbildung sprechen. Ohne die ehrenamtlichen Prüfverläufe gar nichts. Und Prüferinnen natürlich.

Thomas:
[50:07] Ja, spannend, spannend. Das könnte ja auch ein.

Stefan:
[50:09] Karrierepfad für Ausbildungsprüfer sein. dann noch den Berufsspezialisten dazu zu prüfen, auch wenn das natürlich alles sehr endanblich ist.

Thomas:
[50:15] Also es ist ja, man macht kein Geld damit, aber man triebt dabei einfach zu, dass sich das verbreitet. Ich bin selber Prüfer, zwar in anderen Abschlüssen, aber auch ich, im Vergleich zu den anderen Prüfern, die ich oftmals so kenne, bin ich noch jung. Man sieht mein Bild jetzt nicht, aber ich bin Mitte 40. Ich bin oftmals der Junge dabei und es wäre toll, wenn ich nicht mehr zu den Jungen gehören würde. Das wäre ganz toll, wenn sich da Leute finden, die sagen, ich bin dabei und ich unterstütze bei den IHKs und nehme diese Prüfung ab. Egal auf welcher Stufe Ausbildung, Fortbildung, das ist vollkommen egal. Aber eine Verjüngungskur aus meinem Eindruck wäre schon grandios.

Stefan:
[51:09] Ja, guck mal, das ist doch ein guter Aufruf bis zum Schluss. Mach damit, egal ob selber oder als Prüfer oder Prüfender, wie auch immer. Ja, finde ich echt gut. Dann sage ich nochmal vielen Dank, außer dir ist noch etwas eingefallen, was wir vergessen haben. Dann Feuer frei.

Thomas:
[51:25] Ich glaube, wir haben eine sehr kurzfreudige Zeit gehabt und wir haben über viel gesprochen. Also mir fällt tatsächlich gerade nichts mehr ein.

Stefan:
[51:34] Ich bin auch durch. Also ich glaube, wir haben einen guten Überblick gegeben, beziehungsweise du. Ich habe ja nur die Fragen gestellt. Deswegen nochmal vielen Dank. Ich packe den Link zu bzd.com.de nochmal in die Shownotes. Kontaktiert den Thomas gerne, wenn ihr Fragen habt rund um diese Fort- und Weiterbildung. Und ja, arbeiten wir doch alle gemeinsam dran, dass das gut anerkannt wird und in Zukunft vielleicht eine Alternative zu dem klassischen Studium ist. Das finde ich sehr gut.

Thomas:
[51:55] Dann sage ich vielen, vielen Dank nochmal.

Stefan:
[51:58] Und wenn du möchtest, darfst du letzte Worte an die Zuhörerschaft richten. Und sonst sage ich vielen Dank.

Thomas:
[52:03] Erstmal vielen Dank, Stefan, dass ich da sein durfte. Und wie schon gesagt, es liegt an uns, da was aufzubauen und das zukunftsfähig zu machen. Und ich freue mich über jeden, der auf welcher Seite auch immer mit dabei ist.

Stefan:
[52:18] Wunderbar. Das gehen wir so weiter. Dann vielen Dank und bis zum nächsten Mal. Tschüss.

Thomas:
[52:22] Tschüss.

Stefan:
[52:26] So, das war mein Interview zum Thema IT-Weiterbildung mit Thomas. Und ich hoffe, dass du ein bisschen was für dich mitnehmen konntest. Vielleicht stehst du ja wirklich bald vor der Entscheidung oder auch jetzt schon, was du nach der Ausbildung noch machen möchtest und hast jetzt für dich eine passende Alternative vielleicht zu dem Studium gefunden. Ich fand auf jeden Fall das Thema sehr spannend und ja, ich kann mir vorstellen, dass das in Zukunft eine gute Alternative wird für Leute, die nicht studieren gehen wollen. Warum auch? Muss man ja nicht. Es müssen nicht alle Leute studieren gehen,

Fazit und Ausblick auf die Zukunft

Stefan:
[52:54] aber wir haben jetzt lange genug über das Thema gesprochen. Also, ich finde es gut, dass wir mal so ein bisschen über diese Alternativen gesprochen haben, denn nach der Ausbildung ist vor der Weiterbildung. Denn ja, wenn du glaubst, nur mit deinem Ausbildungswissenstand durch 40 Jahre Berufsleben zu kommen, ich glaube, das wird äußerst schwierig. Und heute haben wir mal ein bisschen was darüber gehört, was man noch aufsatteln kann, um dann auch ein bisschen was Handfestes in der Tasche zu haben. Wie schon gesprochen, in Deutschland ist es ja immer wichtig, dass man irgendwo was auf dem Zettel stehen hat. Und das hier wäre jetzt der offizielle Weg. Also vielen Dank nochmal an Thomas und ja, viel Erfolg dir bei deinem beruflichen Fortkommen, vielleicht mit diesen neuen Weiterbildungen. Also falls du die Weiterbildung absolvierst oder absolviert hast,

Stefan:
[53:35] Schreib mir doch mal und Thomas vor allem auch gerne einen Kommentar zur Episode.

Stefan:
[53:39] Wir freuen uns natürlich über Feedback, wenn dir das hier geholfen hat, auch wenn du es ein paar Jahre später hörst. Wir antworten immer auf alles, was uns zugetragen wird. Und ja, in dem Sinne, du kannst gerne nochmal in die Shownotes gucken. Da habe ich alle erwähnten

Zusammenfassung der Episode: Prüfungsvorbereitung für die AP1 🎧
Hey Leute! Ich bin’s, Stefan Macke, euer Begleiter auf dem Weg zur AP1! 🙌 Heute dreht sich alles um die brandneue Prüfungsvorbereitung, die ich für euch ins Leben rufe. Wenn du deine Skills aufpolieren willst, bist du hier genau richtig!
Was erwartet dich?
Wir tauchen in wichtige Themen ein – vom ISO/OSI-Modell über UML-Diagramme bis hin zu Subnetting und IPv6. Keine Angst, ich mach das alles verständlich und hands-on! 😉 Besuche meine Seite

Inhalt Prüfungsvorbereitung für die AP1

In diesem Kurs werde ich zusammen mit dir wichtige prüfungsnahe Themen behandeln. Das könnten zum Beispiel Klassiker wie das ISO/OSI-Modell oder die „beliebten“ UML-Diagramme wie Klassendiagramme und Aktivitätsdiagramme sein! Aber keine Sorge, ich werde sicherstellen, dass wir auch für den Subnetting-Kram und die neuesten Aspekte von IPv6 fit werden. 🚀 Es geht also direkt ans Eingemachte!

Du fragst dich, wo du mehr Infos herbekommst? Einfach mal bei meiner Seite vorbeischauen: dieperfekteihkpruefung.de. Ich habe bereits einen Kurs zur AP2 für Anwendungsentwickler:innen erstellt, und nun wechsle ich auf die AP1, weil die nächsten Prüfungen schon bald anstehen! 👀

Ablauf der Vorbereitung

Der Plan ist, dass ich einmal pro Woche einen Live-Termin in Microsoft Teams anbiete, wo wir gemeinsam an prüfungsnahen Aufgaben arbeiten. Ich werde dir meine eigenen Aufgaben zur Verfügung stellen und wir lösen diese dann zusammen. 🎯 Dabei möchte ich, dass wir die Zeit effektiv nutzen, um zu lernen und unser Wissen anzuwenden – und nicht irgendwelche alten Sachen wiederzukäuen.

Und das Beste daran? Du kannst dich auf der Website über die genauen Termine informieren. Wir starten immer dienstags abends – optimal, um auch nach einem langen Arbeitstag noch den Kopf zusammenzustecken. 🔍 Wenn du an einem Termin nicht teilnehmen kannst, ist das auch nicht weiter schlimm. Alle Live-Sitzungen werden als Videos aufgezeichnet und sind danach jederzeit abrufbar!

Der Inhalt ist König!

Einige der Themen, die wir behandeln werden, sind unter anderem UML-Klassendiagramme, Aktivitätsdiagramme und das Entity-Relationship-Modell. Und natürlich steht auch Pseudocode auf der Liste!.

Ich bin überzeugt, dass wir mit diesem interaktiven Ansatz eine echt spannende und effektive Vorbereitungszeit haben werden. Du bekommst die Möglichkeit, Fragen zu stellen und direkt mit mir und deinen Mitazubis zu interagieren. Das macht das Lernen doch gleich viel angenehmer, oder?

Dein erster Schritt zur Vorbereitung

Also, wenn du Lust hast, mit mir an deiner AP1 zu arbeiten, melde dich an und vielleicht sehen wir uns dann schon bald zu unseren Live-Sessions, die Ende November starten. Ich freue mich riesig darauf, mit dir gemeinsam für die Prüfung zu lernen! 👋

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts

Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode

[0:20] Falls du dich gerade auf deine AP1 in einem IT-Beruf vorbereitest, dann bleib vielleicht mal kurz dran, denn ich starte bald einen Prüfungsvorbereitungskurs für die AP1. Und falls du mit meiner Hilfe ein paar prüfungsnahe Aufgaben bearbeiten willst, ein bisschen die üblichen Themen so durchkasten, man willst in der AP1 so drankommen, sei es das OSI-ISO-Modell, beziehungsweise ISO-OSI, oder UML-Klassendiagramme-Sequenzdiagramme, Nee, Sequenzierung bekomme ich gerade in der AP1. Nee, aber hier Aktivitätsdiagramme zum Beispiel. Oder natürlich Netzwerktechnik und so weiter.

[0:55] Dann, ja, guck doch mal vorbei auf meiner Seite. Vielleicht ist das ja ganz interessant für dich. Die Seite ist dieperfekteihkprüfung.de. Die Prüfung bitte mit UE schreiben. Ich weiß, es ist ein langes Wort. Dieperfekteihkprüfung.de. Alles zusammen ohne Bindelstrich. Kleingeschrieben natürlich und mit UE. Und da kannst du mal reingucken. Ich habe bislang einen Prüfungsvorwaltungskurs nur für die AP2 für Anwendungsentwicklerinnen gemacht.

[1:19] Da habe ich jetzt quasi ein halbes Jahr die Inhalte schon zur Verfügung gestellt. Falls dich das eher interessiert, dann kannst du da mal reingucken. Das ist jetzt quasi ein reiner Online-Kurs. Die ganzen Videos sind online, kannst du dir angucken. Und jetzt schwenke ich um auf die AP1, denn während ich das hier aufnehme, steht sehr bald die AP2 für Anwendungsentwicklerinnen an, im Jahr 2025. Deswegen ist es wenig sinnvoll, danach direkt weiterzumachen mit der Prozessvorbereitung.

[1:46] Ich würde es dann so machen, dass ich jetzt erst mal zur AP1 switche, denn die nächste, die jetzt ansteht, ist im Februar 2026. Und wenn die dann durch ist, switche ich wiederum zur AP2, weil dann kommt als nächstes im, ich glaube Ende April, Und 2026 die nächste AP2. Und dann switche ich wieder zur AP1. Also ich wechsle immer so zwischen den beiden Prüfungsteilen hin und her, je nachdem, welche als nächstes ansteht. Und jetzt wäre es aktuell so, dass ich switchen würde zur AP1 und fange jetzt mal mit den üblichen Netzwerkthemen an und Subnetting und IPv6 und IPv6, würde ich wohl eher sagen, und was sonst so ansteht. Und was ich so für Themen geplant habe, bislang kannst du auf der Website nachschauen. Die Idee ist, dass ich einmal wöchentlich einen Live-Termin mache in Microsoft Teams. und da sprechen wir dann prüfungsnahe Aufgaben durch, die ich mir natürlich selbst ausdenke und versuchen, die dann zu lösen. Die Vorbereitung auf die Termine gibt es dann quasi mit bereits bestehenden Podcast-Episoden oder YouTube-Episoden oder was auch immer. Denn ich möchte dann die Prüfungsvorbereitung wirklich dafür nutzen, um auch Aufgaben zu bearbeiten und nicht zum x-ten Mal das Wissen vorzukauen. Das kann man auch wie zum Beispiel in einem Podcast-Format oder YouTube-Video besser. Ja, wenn du Interesse hast, mit mir zusammen für die Prüfung zu lernen, AP1, Termine sind immer dienstags abends.

[2:56] Beziehungsweise, ich glaube, ein, zwei Ausweichtermine, weil ich da was anderes zu tun habe auf dem Mittwoch. Immer so gegen 18 Uhr und du kannst dir alle anstehenden Termine auch online einfach anschauen. Wie gesagt, dieperfekte.ihrk-prüfung.de kannst du mal reinschauen und wenn du dich für die AP2 schon vorbereitest, auch das, der Kurs ist auch online verfügbar, kannst du die Videos angucken. Ich habe auch schon zum Start des Kurses einige Videos aus meinem AP2 Vorbereitungskurs übernommen. Das heißt, auch wenn du jetzt da dich schon anmeldest, kannst du schon einige Stunden Videomaterial zu Themen, die auch in der AP1 dran kommen, dir anschauen. Zum Beispiel das UML-Klassendiagramm, das Aktivitätsdiagramm, ER-Modelle, das Entity-Relationship-Model, also Pseudocode vor allem, auch immer geringenommen. Das heißt, einige Inhalte kann ich quasi eins zu eins wiederverwenden und die gibt es jetzt schon online. Die restlichen Inhalte werden dann quasi nach jedem Live-Termin als Video dort zur Verfügung gestellt. Du musst also nicht immer zu den Terminen dabei sein, aber das lohnt sich natürlich, weil du dann Fragen stellen kannst. Das geht natürlich im Nachhinein dann schwierig.

[3:56] Ja, falls dich das Thema interessiert, guck gerne mal rein. Ich wiederhole es nochmal, die perfekte IHK-Prüfung.de und vielleicht sieht man sich dann ja ab Ende November 25. Dann geht es los mit dem ersten Termin in der Prüfungsvorbereitung zur AP1 für alle IT-Berufe. Würde mich freuen. Wir sehen uns vielleicht. Mach’s gut. Ciao.

💼 Der Stundensatz für deine Projektdokumentation – Berechne ihn bitte nicht selbst!

Hey, angehender IT-Profi! Heute dreht sich alles um ein Thema, das jeder Azubi kennt: den Stundensatz in der Projektdokumentation. Wie oft ich schon gefragt wurde, „Wie berechne ich meinen Stundensatz?“ – keine Sorge, ich hab’s auch mal durchgemacht! 🤷‍♂️

📊 Warum ist der Stundensatz wichtig?

Deine Projekte brauchen eine klare Kostenrechnung, egal ob sie klein oder groß sind. Wenn du über 80 Stunden arbeitest, kommt da so einiges zusammen! Doch solltest du deinen Stundensatz selbst berechnen? Klare Antwort: Lass es sein! 🚫 Das kann nur schiefgehen.

🏢 Arbeitgeber-Perspektive

Die Berechnung muss aus Sicht deines Arbeitgebers geschehen. Versicherungen, Gemeinkosten – da wird viel mehr aufgerufen, als du vielleicht denkst. Du willst dir da keine falschen Zahlen umhängen – schau dir lieber die Zahl an, die die Personalabteilung für dich hat.

🔍 Warum nicht selbst rechnen?

Die Wahrheit ist: Es gibt ganze Abteilungen, die sich mit solchen Kalkulationen beschäftigen. Wenn du versuchst, es selbst zu machen, könntest du auf die Nase fallen und unrealistische Stundensätze herausbekommen – 4 Euro? Unmöglich! 150 Euro? Nur in Ausnahmefällen! 🤦‍♂️

📋 Die einfache Lösung

Frag einfach bei deiner Personalabteilung nach – so sparst du dir den Stress. Halte fest, was im Stundensatz alles enthalten ist, und notiere das in deiner Dokumentation. Ein einfacher Satz reicht: „Der Stundensatz beträgt 40 Euro inklusive aller Kosten.“ 😊

🔑 Fazit: Mach’s dir leicht!

Zusammengefasst: Berechne deinen Stundensatz nicht selbst. Frag nach und nutze die Zahl, die dir dein Unternehmen gibt. Vielleicht interessiert dich mehr darüber, wie die Berechnung erfolgt – ich habe dafür auch einen Podcast gemacht! Also, hör rein, aber lass die Finger von der Selbstkalkulation! Viel Erfolg bei deiner Projektdokumentation! 🖥️✨

Inhalt 📊 Warum benötigst du einen Stundensatz?

Für deine Projektdokumentation ist es wichtig, eine Kostenrechnung zu machen. Das ist Pflichtprogramm, egal ob es sich um ein kleines oder großes Projekt handelt. Schließlich musst du auch deine Arbeitszeit berücksichtigen, und die kann bei 80 Stunden oder mehr schnell zusammenkommen! Das ist besonders relevant für Anwendungsentwickler und andere IT-Berufe.

Doch nun zur entscheidenden Frage: Solltest du diesen Stundensatz selbst berechnen? Klare Antwort: Nein! 🙅‍♂️ Der Prozess ist so komplex und zeitaufwendig, da kannst du nur etwas falsch machen. Viele Azubis greifen zum einfachsten Mittel – sie nehmen einfach ihre Ausbildungsvergütung und rechnen damit. Falsch! Das ist nur die Sicht auf deinen Nettoeinkommen. Aber dein Arbeitgeber hat noch viel mehr auf dem Zettel, was es zu beachten gilt.

🏢 Die Perspektive des Arbeitgebers

Die Berechnung des Stundensatzes muss also aus Sicht des Arbeitgebers erfolgen. Was deine Vergütung sind, ist lediglich die Spitze des Eisbergs. Arbeitgeber müssen Sozialversicherungen, zusätzliche Versicherungen und eine ganze Reihe von Gemeinkosten wie Hardware oder IT-Infrastruktur einpreisen. Diese Kosten werden dann auf deine Projektpreise umgelegt. Glaub mir, das dabei den Überblick zu behalten, ist kein Zuckerschlecken und sollte nicht in deine Hände gelegt werden!

🔍 Warum solltest du das nicht selbst tun?

Die Wahrheit ist: Da gibt es ganze Abteilungen, die sich mit dieser komplexen Kalkulation befassen – Buchhaltung, Controlling, Rechnungswesen – du hast bestimmt schon von ihnen gehört. Die sind dafür zuständig und nicht du! Wenn du also versuchst, selbst einen Stundensatz zu berechnen, wirst du mit großer Wahrscheinlichkeit wichtige Aspekte übersehen und dich in einem Schlamassel wiederfinden.

Das Schlimmste, was passieren kann? Du bekommst am Ende einen unrealistischen Stundensatz – von 4 Euro bis 150 Euro habe ich alles gesehen. Aber sei mal ehrlich, wie realistisch ist das? 4 Euro? Viel zu wenig, um damit leben zu können. Und die 150 Euro? Naja, in einem Großkonzern vielleicht, aber auch das ist eher die Ausnahme. 🤷‍♂️

📋 Die richtige Herangehensweise

Der Schlüssel ist, dass du einfach die Zahl von deiner Personalabteilung oder dem zuständigen Kollegen anfordest. So viel einfacher und weniger stressig. Notiere dir, was in diesem Stundensatz steckt – zum Beispiel: Ausbildungsvergütung, Lohnnebenkosten und Gemeinkosten. Das musst du in deiner Projektdokumentation anmerken, um zu zeigen, dass du verstehst, wie dieser Wert zustande kommt.

Schreib einfach einen kurzen Satz, z.B.: „Der vorgegebene Stundensatz beträgt 40 Euro und beinhaltet alle notwendigen Kosten.“ 😊 Wichtig ist, dass du nicht versuchst, diesen Stundensatz selbst zu potenzieren oder zu analysieren – das führt nur zu Verwirrungen und Zeitverschwendung!

🔑 Fazit: Mach es dir einfach!

Zusammengefasst heißt das: Berechne deinen Stundensatz nicht selbst. Frag einfach nach und nutze die Zahl, die dir dein Unternehmen bereitstellt. Und klar, es ist wichtig, dass du weißt, wie man diesen Stundensatz grundsätzlich berechnet. Aber du musst nicht ins Detail gehen und jede Kleinigkeit ausrechnen.

Wenn du mehr darüber erfahren möchtest, wie die Berechnung eigentlich funktioniert, habe ich dazu auch einen Podcast aufgenommen – schau dir das auf jeden Fall an, aber verabschiede dich von der Idee, es selbst in deiner Doku zu machen. Du kannst nur verlieren – und das will ja keiner, oder? 💪

Mach’s gut und viel Erfolg bei deiner Projektdokumentation! 🖥️✨

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Zusammensetzung des Stundensatzes – Häufige Fragen im Fachgespräch

Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode

[0:21] Wie berechne ich den Stundensatz für meine Projektdokumentation korrekt? Ich weiß nicht, ob es eine Frage gibt, die mir häufiger gestellt wurde in den letzten Jahren. Und meine Antwort ist immer dieselbe. Lass es einfach sein. Berechne deinen Stundensatz bitte nicht selbst. Und heute will ich mal kurz darauf eingehen, warum das meine Standardantwort ist. Fang vorhin an. Stundensatz, wofür brauchen wir den? Du musst natürlich für deine Projektarbeit, also für das Projekt, das du umsetzt, in deiner Projektdokumentation eine Kostenrechnung machen. Das gehört, würde ich einfach mal pauschal sagen, bei jedem Projekt dazu. Egal, ob es sich am Ende amortisiert oder nicht. Das ist eine ganz andere Frage. Werde ich an anderer Stelle nochmal beantworten. Aber dass du die Kosten betrachten musst, das ist aus meiner Sicht Pflichtprogramm und ich glaube auch aus Sicht vieler anderen Prüfenden. Und da ist meistens der größte Brocken dein Anteil. Das heißt, deine, im Fall von Anführungsentwicklerinnen, 80 Stunden Arbeit, in den anderen IT-Berufen halt 40 Stunden. Da kommt ganz gut was zusammen, wenn man so eine Woche beziehungsweise zwei arbeitet. Und das sollte man in die Kosten auf jeden Fall einplanen. Ja, wenn man jetzt nicht gerade eine riesen Serveranschaffung als Fisi macht zum Beispiel, dann wird da nicht mehr viel Großartiges dazukommen, außer die eigene Arbeitsleistung. Deswegen sollte man das auf jeden Fall vernünftig mit einrechnen. Überhaupt keine Frage. Jetzt ist nur die Frage, die für dich interessant ist. Solltest du das selber machen? Und da ist meine ganz klare Antwort Nein.

[1:41] Wenn du schon mal irgendwo in der Schule oder sonst irgendwo was zum Thema Stundensatz gehört hast, dann müsstest du wissen, wie kompliziert und umständlich und umfangreich es ist, einen richtigen Stundensatz für eine Person zu berechnen. Und was ich leider dann sehr, sehr häufig sehe in so einer Projektdokumentation, und das kann ich schon gar nicht mehr erzählen, wie oft ich das gesehen habe, dann nehmen dann halt einfach die Azubis ihre Azubi-Vergütung im dritten Ausbildungsjahr, teilen das durch ihre Arbeitstage, teilen das nochmal durch die Stunden pro Arbeitstag und schwupp, fertig ist der Stundenlohn. Stundenlohn, ich sage selber schon falsch, der Stundensatz natürlich. Übrigens Unterschied Lohn, Gehalt, Ausbildungsvergütung und Stundensatz. Solltest du dir unbedingt angucken für die Abschlussprüfung.

[2:18] Hier geht es um den Stundensatz. Und das ist natürlich nicht alles, was da drin steckt. Das ist so die, wie soll ich sagen, die Sicht eines Arbeitnehmenden, der sagt, ja, das Geld, was bei mir auf dem Konto landet, das ist ja mein Stundensatz, ist ja klar. Ja, nee, sondern du musst den Stundensatz natürlich aus Sicht deines Arbeitgebers berechnen. Und der zahlt natürlich noch einen Haufen mehr Geld, als nur das, was bei dir auf dem Konto landet. Und müsste man jetzt nochmal den Unterschied zwischen Netto und Brutto wiederholen. Das wollte ich mir heute sparen. Aber es geht eben nicht nur darum, was du bekommst, sondern es gibt noch einen Haufen weiterer Kosten, die dein Arbeitgeber für dich zahlen muss. Nummer eins wären zum Beispiel die Sozialversicherungen, die on top kommen. Da gibt es vielleicht noch zusätzliche Versicherungen, die für dich abgeschlossen werden. Es gibt vielleicht, weiß ich nicht, vermögenswirksame Leistungen. Es gibt ganz sicher einen Riesenhaufen an Gemeinkosten, die in deinem Stundensatz mit drin sein müssen. So zum Beispiel deine Hardware, dein PC, dein Laptop, mit dem du jeden Tag arbeitest, der fällt nicht vom Himmel und den schenkt dir dein Arbeitgeber auch nicht, sondern der muss den auch irgendwie finanziert bekommen. Und wie funktioniert das? Indem er alle diese Dinge in deinen Stundensatz einpreist und der Kunde, der dich dann bucht und dein Projekt bezahlt, das darüber finanziert. Das heißt, alles, was nicht im Stundensatz drin ist, muss dein Arbeitgeber aus seiner eigenen Tasche zahlen. Und das will er nicht oder sie.

[3:33] Das heißt, es ist kein kleines Unterfangen, mal eben einen Stundensatz für einen Entwickler oder einen Physi oder was auch immer auszurechnen. Dafür gibt es eigene Abteilungen, zum Beispiel Buchhaltung, Rechnungswesen, Controlling, wer auch immer das in eurem Unternehmen macht. Das heißt, es kann und soll nicht dein Anspruch sein, diese betriebswirtschaftliche Kalkulation mit allen Sonderfällen und allen Sonderzahlungen und hier muss auch noch der Firmenwagen mit rein und hier gibt es noch eine Abschreibung auf ein Gebäude und hier haben wir noch monatliche Stromkosten und ich weiß nicht, was da alles mit einkalkuliert werden muss. Da vergisst du 100%ig irgendetwas und dann hast du es halt falsch berechnet. Und schon müsste ich dir dafür theoretischen Punkt abziehen. Also lass es doch einfach.

[4:11] Es hat keiner den Anspruch an einen FISI, an einen Amuse-Entwickler, an irgendeinen IT-Beruf, dass du sauber bis aufs kleinste Detail einen Stundsatz ausrechnest. Mit zum Beispiel, hast du vielleicht schon mal gehört in der Berufsschule, dem Betriebsabrechnungsbogen, wo du alle Gemeinkosten aufschlüsseln musst, verteilen musst auf Kostenstellen etc. Pp. und runterrechnen. Das ist so aufwendig und umständlich, das kann niemand von dir verlangen für deine Projektdokumentation. Dann am Ende sollst du ja auch noch so ein bisschen den Kern deines Berufs zeigen, nämlich, dass du zum Beispiel Netzwerke zusammenbauen kannst oder dass du eine Software programmieren kannst oder was auch immer. Und der kaufmännische Anteil, bitte jetzt nicht falsch verstehen, der ist nicht uninteressant oder unwichtig, aber du sollst das nicht in seiner Detailtiefe darstellen, weil das kannst du gar nicht leisten in der kurzen Zeit. Du sollst dich auf das fokussieren, was technisch dein Projekt ausmacht. Aber du sollst natürlich die Kosten betrachten, nur dass du die Berechnung dieser Kosten, deines Stundensatzes nicht selber machen sollst. Was ist meine Antwort? Frag bei dir im Unternehmen, Chef, Personalleitung oder Personalabteilung, Rechnungswesen, Controlling, wen auch immer ihr da habt, der dafür zuständig ist, nach dem Stundensatz für einen Azubi im dritten Ausbildungsjahr. Fertig. Die geben dir eine Zahl. Und mit dieser Zahl rechnest du.

[5:24] Du wirst nicht hergehen und auch nur ansatzweise versuchen, solche Sachen wie deine Auszubildungsvergütung geteilt durch deine Tage und dann musst du noch die Urlaubstage und deine Krankheitstage mit einrechnen und dann noch die Sozialversicherung und dann noch die Gemeinkosten und dann noch den Gewinnzuschlag und da wirst du hundertprozentig was vergessen.

[5:41] Und es ist aber leider so, dass viele Prüflinge das berechnen wollen. Warum auch immer, weil sie das irgendwo gesehen haben oder irgendwer das gesagt hat. Und dann habe ich schon Stundensätze gesehen und das ist jetzt kein Spaß. Ich habe schon so viele Dokus gelesen ja auch. Von 4 Euro irgendwas bis hin zu 150 Euro für einen Azubi im dritten Ausbildungsjahr. Und ich würde behaupten, dass es beides extrem unrealistisch ist. 4 Euro, das ist weit unter Mindestlohn, da kann kein Mensch von leben. Und das ist niemals etwas, was dein Arbeitgeber dir oder für dich in Rechnung stellt. Das ist viel, viel, viel, viel, viel zu wenig. Und 150 Euro für eine Zubi im dritten Ausbildungsjahr, naja, wenn ich irgendwo in einem Riesenkonzern bin und ich weiß, aber auch das finde ich äußerst unrealistisch, aber sei es drum. Das ist auf jeden Fall realistischer als die 4 Euro irgendwas, die dabei rauskommen. Also lass es einfach sein. Hol dir die Zahl von dem Zuständigen, der ist zuständig bei euch im Unternehmen.

[6:33] Und dann musst du selbstverständlich für die Prüfung wissen, wie sich so ein Stundensatz denn berechnen würde. Aber du musst das niemals in seiner Vollumfänglichkeit in deiner Projektdokumentation demonstrieren. Du musst es vielleicht im Fachgespräch erklären, wenn du in einer Doku schreibst, ich habe als pauschalen Satz von meiner Personalabteilung genannt bekommen, 40 Euro für ein Azubi. Dann musst du natürlich aufschlüsseln können, was da drin ist, nämlich Bruttogehalt plus Lohnnebenkosten plus Gemeinkosten und alles, was noch dazugehört. Das ist natürlich ein wichtiger Prüfungsinhalt. Aber bitte verschwende nicht deine und meine Zeit als Prüfender in deiner Projektdokumentation und versuch da selber zu berechnen. Du kannst es einfach nur falsch machen.

[7:13] Was du natürlich auch nicht machen kannst, ist, hier, ich habe diesen Satz bekommen vom Personal und ich habe eigentlich gar keine Ahnung, was da so drinsteckt und warum der so ist, wie er ist, aber ich rechne einfach damit.

[7:22] So dumm stellen darfst du dich natürlich auch nicht, genauso wenig wie du, wenn dein Chef sagt, du musst aber Programmiersprache X nehmen, nicht sagen kannst, ja Chef, das mache ich, sondern auch vernünftig begründen solltest, warum das die richtige Wahl ist und wenn nicht, dann auch vielleicht etwas dazu sagen solltest, warum es vielleicht nicht die richtige Wahl ist. Und im Stundensatz genau das Gleiche. Da kannst du eine kleine Fußnote oder einen Nebensatz oder sonst irgendwas in einer Doku schreiben. Dieser Wert wurde mir vorgegeben, aber er beinhaltet im Kern die Ausbildungsvergütung, die Lohnnebenkosten und die Gemeinkosten oder was auch immer. Da reicht ja so ein kleiner Satz, um zu zeigen, hey, ich weiß, wie der sich zusammensetzt, aber ich weiß auch, dass es nicht mein Job ist, den zu berechnen, sondern ich rechne mit den Sachen, die mein Unternehmen mir vorgibt. Ja, das ist okay. Wie bei vielen anderen Fragen auch, Technologie etc. Sachen, die dir vorgegeben werden, völlig in Ordnung. Wir arbeiten nicht bei Wünsch dir was, sondern im Unternehmen, was der auch bestimmt Vorgaben machen wird und das ist auch völlig in Ordnung. Du musst als Prüfling aber in der Lage sein, das zu reflektieren und zu sagen, war es denn richtig, diese Entscheidung zu treffen oder könnte man es auch anders machen? Und beim Stundensatz eben nicht, war es richtig oder nicht, das kannst du schlecht kontrollieren, aber wie würdest du ihn denn berechnen, wenn du es machen müsstest? Das solltest du wissen, musst es aber nicht komplett in deiner Doku selber berechnen. Das kann nur zu Fehlern führen. So, zusammengefasst, lass es sein, berechne den Stundensatz nicht selbst, nimm einen vorgegebenen, der einigermaßen realistisch ist und wenn dein Unternehmen, letzter Einschub vielleicht noch, diesen Stundensatz nicht nach außen geben möchte, aus Gründen des Datenschutzes, dann…

[8:51] Das habe ich auch schon so oft gelesen in Dokumentation, musst du eigentlich auch links und rechts einen an den Ohren haben, weil das hat nichts mit Datenschutz zu tun. Wenn dein Unternehmen diese Stundensätze nicht nach draußen geben möchte, dann ist es, weil sie halt, weiß ich nicht, ihre Mitbewerber nicht darüber informieren wollen, was sie für Kostenstrukturen haben, eine Art Geschäftsgeheimnis, wie auch immer oder warum auch immer man sowas nicht preisgeben sollte, ist ja ganz egal, ist ja völlig legitim. Aber es hat 0,0 mit Datenschutz zu tun, denn dieser Stundensatz ist nicht individuell auf eine persönliche Person, wollte ich schon sagen, auf eine natürliche Person zurückzuführen. Das heißt, es ist kein Personenbeziehungsdatum, weil dieser Stundensatz gilt für, gehe ich jetzt einfach mal von aus, alle Azubis im dritten Ausbildungsjahr oder alle Entwicklerinnen oder alle Projektleiterinnen oder was auch immer. Und das sagt 0,0 darüber aus, was die Leute individuell zum Beispiel verdienen. Das ist ja ein Durchschnittsatz, der alle Kosten beinhaltet, inklusive Strom und Miete und ich weiß nicht was. Das heißt, es erlaubt überhaupt gar keinen Rückschluss auf irgendein individuelles Gehalt oder sonst etwas. Das heißt, Stundensätze haben einfach nichts mit Datenschutz zu tun. Das wäre auch der Unterschied zu einem Stundenlohn oder einem Gehalt in der Ausbildungsvergütung. Das wäre dann etwas anderes. Soll vielleicht nicht jeder wissen, wer genau was verdient. Aber der Stundensatz gehört eben nicht dazu. So, das war es zu meinem Lieblingsthema Stundensatz.

[10:10] Wie man den genau berechnet, wie gesagt, das solltest du ja wissen, dazu habe ich eine ausführliche Podcast-Ebisode aufgenommen, schon vor langer Zeit, die kannst du dir gerne nochmal anhören, aber bitte lass es sein, in deiner Doku den selber auszurechnen, du kannst es nur falsch machen. So, das war das Wort zum Stundensatz, nicht zum Sonntag und damit bin ich für heute durch.

In dieser Episode bespreche ich die Entwicklung meiner Online-Kurse zur Prüfungsvorbereitung für IT-Berufe und die Einführung eines kostenpflichtigen Modells zur Sicherstellung einer konstruktiven Lernumgebung. Ich teile die Struktur der Kurse, die über eine Plattform mit aufgezeichneten Sitzungen laufen, und lege besonderen Wert auf Interaktivität während der wöchentlichen Live-Sitzungen. Aktuell fokussiere ich mich auf die AP2-Anwendungsentwicklerinnen und plane die Integration praktischer Themen wie Pseudocode. Durch ein flexibles Abo-Modell haben Teilnehmer jederzeit Zugang zu Materialien und können aktiv an den Kursen teilnehmen. Ich lade Interessierte ein, sich unter https://dieperfekteihkpruefung.de zu informieren und bewerbe meine erschwinglichen Angebote zur gezielten Prüfungsvorbereitung.

Inhalt

In dieser Episode sprechen wir über die Entwicklung und die Fortschritte meiner Online-Kurse zur Prüfungsvorbereitung für IT-Berufe. Ich schildere die Gründe, warum ich im Jahr 2025 kostenlose Vorbereitungskurse angeboten habe und was schiefgelaufen ist. Der Herausforderungen im Chat und das Bedürfnis, eine konstruktive Lernumgebung zu schaffen, haben mich dazu bewogen, ein kostenpflichtiges Modell einzuführen, um ernsthafte Teilnehmende von Störenfrieden zu trennen. Ich erkläre, wie wichtig es ist, die Qualität des Unterrichts durch diese Maßnahme zu sichern und lade Interessierte ein, sich unter https://dieperfekteihkpruefung.de zu informieren und anzumelden.

Aktuell biete ich spezifisch für die AP2-Anwendungsentwicklerinnen einen Kurs an, da ich nach einer soliden Basis für die Teilnehmer suchen musste. Ich erläutere die Struktur der Kurse, die über eine Plattform laufen, auf der alle Sessions aufgezeichnet werden. So können sich die Teilnehmer die vergangenen Meetings jederzeit anschauen. Ich lege großen Wert auf Interaktivität und ermutige meine Teilnehmenden, Fragen zu stellen und aktiv zu diskutieren, insbesondere während der wöchentlichen Live-Sitzungen. Diese finden dienstags um 18 Uhr in Microsoft Teams statt, und ich betone die Notwendigkeit eines gültigen Teams-Kontos, um anonymen Störungen vorzubeugen.

Ich beschreibe, wie die Kursinhalte auf die praktischen Bedürfnisse der Teilnehmer abgestimmt sind. Beispielsweise plane ich, demnächst mit wichtigen Prüfungsthemen wie Pseudocode zu beginnen. Dabei ist es mein Ziel, passende Ressourcen zur Einarbeitung bereitzustellen und während der Live-Sitzungen gemeinsam an Aufgaben zu arbeiten. Es geht dabei nicht um das Wiederholen von Prüfungsfragen, sondern um eine interaktive Auseinandersetzung mit den Lerninhalten. Das Konzept eines umgedrehten Klassenzimmers steht hier im Zentrum; die Teilnehmer sollen sich die Erklärungen im Vorfeld anschauen und in den Live-Terminen aktiv an den Übungen teilnehmen.

Das Abo-Modell ermöglicht es den Teilnehmern, jederzeit einzusteigen und an laufenden Kursen teilzunehmen, ähnlich einem Streaming-Service. Dadurch haben sie Zugang zu sämtlichen Materialien, die im Laufe des Jahres erstellt werden, und profitieren von der Flexibilität, wann und wie sie lernen möchten. Mein Ziel ist es, eine erschwingliche und zielgerichtete Vorbereitung zu bieten, die den Bedürfnissen von Auszubildenden und Umschülern gerecht wird.

Zusammenfassend erläutere ich die flexiblen Strukturen meines Dauerangebots, die geringen Kosten und die Möglichkeit, sich jederzeit anzumelden oder abzumelden. Interessierte können sich auf meiner Webseite weiter informieren und ich hoffe, bald viele motivierte Teilnehmer begrüßen zu dürfen, um gemeinsam auf die Herausforderungen der Prüfungen hinzuarbeiten.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• https://dieperfekteihkpruefung.de

Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode

[0:20] Du hast doch mal Online-Kurse zur Prüfungsvorbereitung angeboten. Wann geht es damit eigentlich weiter? Die Frage wird mir in letzter Zeit auch oft per E-Mail gestellt. Und ja, es stimmt, ich habe 2025 mal mehrere Wochen lang kostenlose Prüfungsvorbereitungskurse angeboten. Zur AP1 für alle IT-Brufe und zur AP2 für Anwendungsentwicklerinnen. Leider, das ist nicht so gut ausgegangen. Es gab ziemlich ätzende Sachen im Chat. im Chat von Teilnehmenden und ja, das habe ich dann eingestellt. Und seitdem habe ich mir aber eine Alternative überlegt und biete kostenpflichtige Prüfungsvorbereitungskurse an, um einfach die Leute rauszusieben, die nur Stress machen wollen und Ärger machen wollen. Wenn du da dabei sein möchtest, kannst du mal gucken unter dieperfekteihkprüfung.de Prüfung mit UE, mit Ü soll das auch gehen, aber mach mal lieber mit UE. Und da kannst du dich anmelden. Aktuell habe ich nur einen Kurs für die AP2 für Anwendungsentwicklerinnen. Ich habe noch nichts für AP1 und auch nicht für die anderen IT-Berufe. Ich muss ja erst mal mit irgendwie was anfangen. Und das Ganze läuft über eine Kursplattform.

[1:32] Alle unsere Meetings werden aufgezeichnet, als Video online gestellt, auch mit Transkription und Zusammenfassung und allem Schnickschnack. Das habe ich alles mit KI soweit automatisiert, dass ich da nicht so viel Arbeit mit habe. Das heißt, du kannst dir alle bisherigen Termine jederzeit anschauen, sobald du dich anmeldest. Und ja, was heißt überhaupt Termin? Es gibt jede Woche einen regelmäßigen Termin mit mir. Das ist aktuell, wenn ich das hier aufnehme, 2025, immer der Dienstagabend um 18 Uhr für ein und eine Viertelstunde, also bis 19.15 Uhr. Und da treffen wir uns dann live in Microsoft Teams. Man braucht auch einen gültigen Teams-Account und kann nicht anonym teilnehmen. Wie gesagt, es gab da Ausfälle im Chat und das hätte ich nicht gerne nochmal. Deswegen brauchst du ein gültiges Teams-Konto und kannst dann jederzeit an diesem Termin teilnehmen. Was heißt jederzeit? Also Dienstagabend immer an dem Termin teilnehmen und dann kannst du auch live Fragen stellen zu dem Thema, was wir bearbeiten.

[2:27] Genau, wir haben auch schon live Präsentationen für die AP2 gemacht, also nicht die Schriftgeprüfung, sondern die Münchenprüfung, Präsentationen, die ich durchgeschaut habe und dann Feedback gegeben habe. Wir haben Fachgespräche schon geübt mit Teilnehmenden, die dann auch das Mikro anstellen durften und so weiter, aber normalerweise läuft das so, dass du dann chatten kannst. Und ich erzähle dann was zu einem Thema. Ich würde jetzt in den nächsten Wochen, also ich nehme das jetzt hier auf, im Juli 2025, in den nächsten Wochen würde ich dann quasi mit den Standardprüfungsthemen für die schriftliche Prüfung AP2-Anmeldungsentwicklerinnen wieder von vorne loslegen, in Anführungszeichen. Und zwar geht es weiter mit Pseudocode. Sicherlich ein Thema, was viele, viele Prüflinge interessiert und wo viele ein Problem mit haben. Und die Idee ist dann, dass ich im Vorfeld Ressourcen bereitstelle zur Einarbeitung im Pseudocode, zum Beispiel meine Podcast-Episode oder ein YouTube-Video oder sowas und dann wollen wir in diesen Terminen gemeinsam Aufgaben lösen, damit dann auch wirklich ein Mehrwert entsteht, weil sonst kann ich auch einfach, ja, das Zeug, was ich da erzähle, kann ich auch als Podcast aufnehmen. Also wo ist dann da der Mehrwert dieses Online-Kurses? Die Idee ist, dass man dann halt dann gemeinsam an den Aufgaben arbeitet, sich Feedback einholt, eigene Lösungsvorschläge macht und dann auch Feedback dazu kriegt und so weiter. Also wirklich interaktiv und dann halt eben Aufgaben zusammenbearbeitet. Das sind natürlich nicht die echten IHK-Aufgaben, das geht ja nicht, Copyright etc., sondern selbst Ausgedachte, die aber sehr dicht in der Prüfung dran sind. Ich mache das ja nun schon ein paar Jahre und ich weiß wohl, was da so ungefähr abgefragt wird.

[3:53] Und ja, die Idee ist dann das sogenannte, das wollte ich schon sagen, blended learning, aber ist es gar nicht, inverted classroom. Das heißt, man macht nicht zusammen eine Erklärung des Themas, sondern man kriegt die Erklärung vorher, zum Beispiel per Video und macht dann gemeinsam die Aufgaben. Deswegen inverted classroom, weil normalerweise ist ja im Unterricht, in der Schule, kennst du es bestimmt andersrum. Du machst deine Hausaufgaben alleine und hast keine Hilfe und der Lehrer erzählt dir das einfach nur oder die Lehrerin und wir drehen es halt um.

[4:21] Sodass das auch wirklich einen Mehrwert bietet, wenn du bei den Live-Terminen teilnimmst. Wenn du nicht kannst, wie gesagt, du kannst dir auch die Aufzeichnungen anschauen, aber ja, da kann man halt keine Fragen stellen. Das ist halt doof, ne? Ja. Und ich habe mir gedacht, wenn schon Prüfungsvorbereitungskurs, dann so, wie er vielleicht zur Zielgruppe passt, kennst vielleicht schon andere Prüfungsvorbereitungskurse von den IHK oder anderen Anbietern. Und da ist das dann halt immer eine recht große Summe für x Termine. Und das ist aber, finde ich, immer sehr kurzfristig vor den Prüfungen und also nicht auf langfristiges Lernen ausgelegt. Und es kostet halt auch immer eine Stange Geld. Deswegen habe ich mir das anders überlegt. Ich mache wöchentlich einen Präsenztermin, wo du dabei, also Präsenz in Microsoft Teams, alles online natürlich, wo du dabei sein kannst. und dann aber das ganze Jahr über quasi. Also nicht nur kurz vor der Prüfung, sondern du kannst jederzeit, auch wenn du das hier später hörst, jederzeit einsteigen und machst dann halt ab dem Termin live mit. Kannst dir aber auch, wie gesagt, alle bisherigen Aufzeichnungen anschauen, sobald du angemeldet bist. Also es ist so, ich vergleiche das so ein bisschen wie so ein Netflix-Abo oder Amazon Prime-Abo, ja. Du kannst einfach jederzeit dazukommen, guckst dir das an, was es schon gab und wenn du dich abmeldest, ja, dann kannst du es halt nicht mehr angucken und kommst halt auch nicht an die neuen Live-Termine.

[5:27] Und ja, damit das überhaupt funktioniert, ist das Ganze auch ein Abo-Modell. Das heißt, du kannst dir ja auf monatlicher Basis das Ding buchen oder auch wieder stornieren oder auch pausieren. Kannst auch, geht auch alles mit der Plattform. Das heißt, für einen geringen monatlichen Betrag kannst du langfristig dich in diesem Fall auf die AP2 für Fachinformatikerinnen in Anwendungsentwicklung vorbereiten. Und wenn du keinen Bock mehr hast, meldet sich wieder ab. Das heißt, der Invest ist auch relativ gering, denke ich mal, für so ein Azubi oder auch Umschüler, Umschülerin, denke ich mal, zu leisten. Und wenn dir selbst das noch zu teuer ist, kann ja auch sein, dann fragt das ein Ausbildungsunternehmen, ob das bezahlt wird. Bei den, finde ich, sehr geringen Preisen im Vergleich zu anderen Anbietern ist das vielleicht auch kein Problem, dass du es vielleicht sogar erstattet bekommst.

[6:08] Also, ich fasse mal zusammen. Mein Prüfungsverbreitungskurs läuft dauerhaft das ganze Jahr über mit einigen Urlaubsausnahmen. Das steht aber auch auf der Website, wann die sind. Und du kannst dich jederzeit an- und abmelden. Kostet einen geringen monatlichen Betrag und kannst ab diesem Zeitpunkt dir alle Videos angucken, die es bisher auch gab. So, ja, eben wie bei einem Streaming-Anbieter. Alles, was schon da ist, kannst du dir angucken. Und dann immer ab diesem Zeitpunkt, wo du das Abo abgeschlossen hast, an den Präsenzterminen mit mir in Microsoft Teams teilnehmen. Das ist so die Idee. Alle weiteren Informationen und die Buchungsmöglichkeit findest du unter dieperfekteihkprüfung.de. Und ja, vielleicht hast du ja Lust und bist bald dabei und stellst auch deine Fragen oder Lösungsvorschläge bei mir im Chat. Das würde mich freuen. Oder, ja, noch ganz cool, wenn du deine Präsi zeigen willst oder ein Fachgespräch mit mir üben willst, auch das haben wir schon ein paar Mal gemacht und kann man sich schon anschauen auf der Plattform.

[6:57] Ja, in dem Sinne, ich würde sagen, viel Erfolg bei der Prüfungsverwaltung, egal ob mit mir oder ohne mich. Und ja, dann vielleicht sehen wir uns ja bald.

In dieser Episode behandeln wir die oft gestellte Frage nach der idealen Anzahl von Folien für Projektpräsentationen. Ich erkläre, dass die Folienanzahl irrelevant ist für die Qualität der Präsentation. Entscheidender ist die Präsentationszeit von 15 Minuten, innerhalb der die Inhalte klar und strukturiert vermittelt werden sollten. Ich empfehle, visuelle Elemente zu nutzen und den Text auf Folien zu minimieren, um das Publikum anzusprechen. Animationen sollten sinnvoll eingesetzt werden, und es ist wichtig, einen roten Faden zu erkennen. Letztlich zählt der Inhalt, nicht die Anzahl der Folien. Übe intensiv, um sicher im Zeitrahmen zu bleiben und viel Erfolg bei deiner Präsentation!

Inhalt

In dieser Episode beleuchten wir die häufige Frage: Wie viele Folien sind ideal für eine Projektpräsentation? Dies ist ein Thema, das ich oft angesprochen bekomme, vor allem von Menschen, die sich unsicher sind, ob ihre Anzahl an Folien zu viel oder zu wenig ist. Vorab möchte ich klarstellen, dass die Anzahl der Folien für die Qualität einer Präsentation irrelevant ist. Ob es zwölf oder hundert Folien sind, hat keinen Einfluss auf die Bewertung oder die Inhalte, die präsentiert werden. Der Schlüssel liegt in der Präsentationszeit, die in den meisten Fällen 15 Minuten beträgt.

Es ist wichtig zu verstehen, dass die Folienanzahl nichts darüber aussagt, wie lange es dauert, sie zu präsentieren. Du kannst eine Folie zügig behandeln oder viel Zeit darauf verwenden. Das entscheidende Kriterium ist, ob du deine Präsentation in der vorgegebenen Zeit von 15 Minuten schaffst. Es spielt keine Rolle, ob du dies mit einer einzigen Folie oder mit vielen Folien tust, solange der Inhalt stimmt und die Präsentation strukturiert und verständlich ist.

Ich empfehle, den Präsentationsstil und die Technik so zu wählen, dass sie zu dir passen. Wenn du visuell präsentierst, werden deine Folien automatisch vielfältiger sein. Mein persönlicher Rat: Setze auf visuelle Elemente und halte Text auf den Folien auf ein Minimum. Dies fördert das Verständnis und macht deinen Vortrag ansprechender. Eigene Fotos sind oft besser geeignet als generische Bilder, da sie authentischer wirken und das Publikum schneller ansprechen.

Ich verdeutliche, dass es keine Vorschrift gibt, die besagt, dass Textfolien verboten oder Bildfolien vorgeschrieben sind. Der Stil sollte dir entsprechen und dir das Vertrauen geben, deine Präsentation in der Zeit zu bewältigen. Animationen auf Folien können unterstützend wirken, sollten aber sinnvoll eingesetzt werden. Egal, ob du ein paar Folien oder viele Folien verwendest, die Dauer deines Vortrags bleibt konstant und von entscheidender Bedeutung ist der Inhalt.

Zudem erlebe ich manchmal Präsentatoren, die während des Vortrags ununterbrochen klicken, ohne dass sich der Folientext ändert. Hier wird deutlich, dass es auch technische Aspekte gibt, die die Folienanzahl beeinflussen können. Der eigentliche Inhalt bleibt in beiden Fällen gleich, egal wie viele Folien verwendet werden. Lass dich nicht von anderen beeinflussen, wenn sie dir sagen, dass du zu viele oder zu wenige Folien hast. Wichtig ist, dass du deinen Vortrag klar und verständlich hältst, einen roten Faden erkennbar machst und die Zeit von 15 Minuten einhältst.

Zusammengefasst: Übe deine Präsentation intensiv, bis du sicher in der Zeit liegt. Die Anzahl der Folien ist dabei nicht das entscheidende Kriterium. Viel Erfolg bei deiner Projektpräsentation!

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts

Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode

[0:21] Wie viele Folien soll ich für meine Projektpräsentation erstellen? Diese Frage wird mir recht häufig gestellt in dieser oder anderer Form. Zum Beispiel, ich habe schon zwölf Folien für die Präsentation. Ist das zu viel? Oder ich habe gesehen, auf deiner Website gibt es Präsentationen mit 100 Folien. Wie kann man das überhaupt schaffen in der Zeit? Und ja, egal wie man die Frage stellt, die Antwort ist immer die gleiche. Es ist völlig irrelevant. Die Anzahl der Folien sagt genau 0,0 über die Qualität der Präsentation aus, über die Bewertung, über die Inhalte oder irgendwas. Die Anzahl ist völlig unwichtig, uninteressant, nebensächlich, ganz egal. Das wäre so meine Kernaussage erstmal. Warum ist das so?

[1:06] Die Anzahl der Folien sagt überhaupt gar nichts darüber aus, wie lange du brauchst, um die Folien vorzutragen. So simpel ist es. Du kannst eine Folie eine Minute lang offen lassen oder eine Sekunde. Das heißt, es ist völlig egal, ob du 12 oder 120 Folien hast. Denn das Wichtige, was du einhalten musst, und das ist die einzige Vorgabe, die du hast, du musst deine Präsentationszeit einhalten. Und das sind 15 Minuten. Und wenn du diese 15 Minuten einhältst, dann ist es egal, ob du es mit einer Folie machst oder mit gar keiner, weil du was an die Tafel malst oder mit 120 Folien und die aber 15 Minuten auf den Punkt exakt ablieferst. Das Einzige, woran du dich orientieren musst, ist, schaffe ich meine Präsentation in der vorgegebenen Zeit? Und dann ist es völlig egal, wie viele Folien nutzt, denn das hängt einfach von deinem Präsentationsstil ab, Nummer 1, aber Nummer 2 auch teilweise von der Technik, die du einsetzt. Darf mal abgesehen, dass es auch Präsentationssoftware gibt, die gar nicht mit Folien arbeitet, sondern irgendwie so rein-raus-zoomen und ich weiß nicht, was es da alle gibt, da ist die Folienzahl auch völlig egal.

[2:06] Aber wenn wir mal von den klassischen PowerPoint-Präsentationen ausgehen, was ja einfach ein Großteil der Projektpräsentationen in den IT-Berufen ist, ist ja klar. Und ob es jetzt PowerPoint oder Open-Source-Software ist oder auf Mac, ist völlig egal. Du weißt, was ich meine. Sondern es geht einfach darum, wenn du dir Folien vorstellst, musst du auf die Zeit kommen. Und das muss zu deinem Vortrag passen und deinen Vortrag unterstützen. Und wenn du jemand bist, der sehr visuell präsentiert, der viele Bilder hat, dann wirst du automatisch mehr Folien haben als jemand, der super viel Text auf die Folie packt, weil einfach das Vorlesen der Texte ja schon viel länger dauert, als ein paar Bilder durchzuklicken.

[2:39] Meine persönliche Meinung hast du im Podcast und auf der Website sicherlich schon oft gehört. Ich bin gar kein Freund von Text auf Folien. Ich mag es sehr, sehr visuell und deswegen meine ganz klare Empfehlung, mach mehr Folien, mach weniger Inhalt auf die Folien, mach es eher visuell, mach Bilder und so weiter. Haben wir beim letzten Mal schon drüber gesprochen, beziehungsweise ich, dass du dann am besten eigene Fotos machst und keine generierten Fotos benutzt. Und dann ist es auch viel, viel nachvollziehbar, was du da gemacht hast, weil ich die Bilder viel schneller erfassen kann zum Beispiel. Wenn ich deinen Text, lesen muss auf der Folie. Und deswegen ist es doch überhaupt nicht schlimm, wenn du eine Präsentation hast mit 100 Folien, solange, und das ist immer, immer, immer mein Credo, dein Punkt rüberkommt, deine Präsentation auf dem Punkt genau 15 Minuten lang ist und alles drin ist, was ich von deinem Projekt wissen will. Und dann kann dir niemand einen Punkt dafür abziehen, weil du eine Folie zu viel oder wenig hattest. Das ist völlig irrelevant. Sondern es geht darum, fehlt mir ein Inhalt. Und das sage ich immer wieder. Bitte verstehe diese Folge heute nicht falsch. Ich sage nicht, du darfst keine Textfolien benutzen oder du musst Bildfolien nehmen oder sonst irgendwas. Du musst vor allem einen Stil nehmen, der zu dir passt und wo du ganz sicher bist, dass du es in 15 Minuten schaffst und aber alle wichtigen Inhalte zu deinem Projekt rüberbringst. Das ist der Kern, der hier am wichtigsten ist. Und dafür ist völlig irrelevant deine Folienanzahl. Ich mache nochmal ein Beispiel für diese Technikabhängigkeit.

[4:01] Du kennst vielleicht Animationen in Folien. Kann man auch darüber sprechen, ob man die gut findet oder nicht. Das ist hier gar nicht der Punkt. Spoiler, ich finde es zum Beispiel gut, wenn sie den Vortrag unterstützen, habe ich überhaupt gar kein Problem mit Animationen. Und wenn sie wild in Anführungszeichen sind, dann heißt das meist, dass die Animationen einfach nur aufgrund der Animation genutzt wird, aber nicht, um irgendeinen Punkt hervorzuheben oder wirklich einen Mehrwert zu bringen. Solche Animationen sind Schrott. Aber wenn du gute, die deinen Vortrag unterstützen, benutzt, habe ich überhaupt kein Problem mit Animationen. Aber die Frage ist, wie du sie technisch umsetzt. Du kannst zum Beispiel auf einer PowerPoint-Folie mit diesem Animations, ich weiß gar nicht, wie das Ding da heißt, auf einer Folie 27 Schritte, wo irgendwelche Pfeile sich bewegen, auf einer einzigen Folie machen, dann ändert sich deine Folienzahl nicht. Trotzdem dauert das Ding fünf Minuten, wenn du es vorträgst. Du kannst aber auch jeden einzelnen Animationsschritt auf eine einzelne Folie packen, was dann zum Beispiel den Vorteil bietet, dass du das in einem Vorschaufenster siehst, im Präsentationsmodus und auch zurückklicken kannst und siehst, was passiert. Also es gibt verschiedene Pro- und Kontra-Argumente, entweder Animationen auf der Folie oder auf mehrere Folien zu machen. Am Ende ist es aber das gleiche Ergebnis. Das, was du vorträgst, die Animation, dauert exakt genau gleich lange, Nur einmal ist sie auf fünf Folien verteilt und einmal auf eine. So, wo ist da jetzt der Unterschied? Soll ich da jetzt einen Punkt dafür abziehen, weil du einmal fünf und einmal eine Folie benutzt hast? Das ist einfach Quatsch. Du siehst, das Wichtige ist, der Inhalt, dein Vortrag. Und wenn du was auf den Folien hast, sollen die den Vortrag unterstützen. Das muss rüberkommen. Anzahl irrelevant.

[5:25] Und was ich auch schon mal gesehen habe, das finde ich immer ein bisschen irritierend, aber habe ich zum Beispiel auch schon gesehen, da hat jemand was vorgetragen und dann währenddessen mit seinem Klicker weitergeklickt. Aber die Folie hat sich gar nicht verändert. Also das, was wir Prüfenden gesehen haben, hat sich nicht verändert. Und da war die Idee, er hat so lange auf der Folie gebraucht, dass er mehrere Notizenseiten dafür brauchte. Aber er konnte die nicht alle auf einer Folie unterbringen. Das heißt, er hat immer geklickt. Die Folie hat sich quasi ohne sich zu verändern dupliziert, aber die Notizen haben sich verändert. Das heißt auch hier, er hat eigentlich nur eine einzige Folie sichtbar gehabt, aber im Hintergrund waren es eigentlich drei, die sich aber nicht verändert haben, sondern die Notizen. Also auch da, Technik beeinflusst, wie viele Folien es sind. Der Inhalt ist in beiden Fällen identisch. Also, wie gesagt, ich kann es nur nochmal betonen, die Anzahl der Folien ist völlig relevant. Lass dir auch nicht von irgendwem erzählen, du hast aber zu viele Folien, dafür gibt es Punktabzug oder du hast zu wenig Folien oder was auch immer. Es kommt auf deinen Vortrag ran. Wenn du dich damit gut fühlst und du deinen Inhalt drüber bringst, eine Story erzählst, ein roter Faden erkennbar ist, dann ist die Anzahl der Folien irrelevant.

[6:27] Kümmer dich darum, dass du auf 15 Minuten kommst. Übe deine Präsentation rauf und runter und nochmal rauf und runter und das ganze 10 Mal, bis du auf 15 Minuten kommst. Und dann ist die Zahl der Folien egal. So, bevor ich mich jetzt zum hundertsten Mal wiederhole, das war’s. Also, ich wünsche dir viel Erfolg bei deiner Projektpräsentation und alles Gute für die Prüfung.

In dieser Episode des IT-Berufe-Podcasts beginne ich ein neues Format, in dem ich häufig gestellte Fragen beantworte. Zunächst diskutiere ich die Nutzung von KI-generierten Bildern in Projektpräsentationen und empfehle, diese zu meiden. Basierend auf persönlichen Erfahrungen betone ich, dass Stockfotos oft unpassend und austauschbar sind. Ich ermutige die Zuhörer, eigene Fotos zu erstellen, um Authentizität und Emotionen zu vermitteln. Zusätzlich gebe ich Tipps zur Verbesserung der Bildqualität und zeige alternative Darstellungen wie Screenshots oder Diagramme auf. Ziel ist es, die individuelle Geschichte jedes Präsentierenden hervorzuheben.

Inhalt

In dieser Episode beginne ich mit einem neuen Format des IT-Berufe-Podcasts, das auf die häufigsten Fragen eingeht, die ich regelmäßig über verschiedene Kanäle wie E-Mail, Instagram, YouTube und selbst TikTok erhalte. Anstatt wiederholt individuelle Antworten via Nachricht zu geben, möchte ich diese Informationen im Audio-Format aufbereiten, damit andere Hörer ebenfalls davon profitieren können. Die Idee ist, die Fragen prägnant und informativ zu beantworten, ohne in langen Gesprächsrunden zu versinken.

Die erste zentrale Frage, die ich behandle, bezieht sich auf die Verwendung von KI-generierten Bildern in Projektpräsentationen. Diese Frage wird mir häufig gestellt, insbesondere in Bezug auf deren Relevanz und Effektivität. Meine klare Antwort ist, dass Sie solche Bilder besser meiden sollten. Ich leite dies aus persönlichen Erfahrungen ab, die ich bereits vor Jahren in meinem Blog geteilt habe, wo ich dazu geraten habe, auf ClipArts zu verzichten, da sie visuell langweilig und emotionslos sind und oft als unpassendes Beiwerk fungieren.

Ich betone, dass die Verwendung von Stockfotos dieselben Probleme mit sich bringt – diese Bilder sind oft nicht einzigartig und stellen die Projekte nur unzureichend dar. In vielen Fällen können mehrere Präsentationen das identische Bild verwenden, was einen Eindruck von Austauschbarkeit erzeugt, während jedes Projekt doch eine individuelle Geschichte zu erzählen hat. Daher empfehle ich, eigene Fotos zu machen, um echte Emotionen und eine authentische Verbindung zu schaffen.

Heutzutage haben Smartphones eine exzellente Kameraqualität. Daher ist es einfach, selber Bilder zu erstellen, die speziell auf das eigene Projekt zugeschnitten sind. Dies zeigt nicht nur das tatsächliche Projektumfeld, sondern hebt auch die individuellen Leistungen hervor. Ich stelle klar, dass diese persönlichen Fotos wesentlich mehr Aussage haben und die Leidenschaft und Arbeit des Präsentierenden reflektieren, im Gegensatz zu jeglichen generierten Inhalten – sei es von einer KI oder aus Stockfoto-Datenbanken.

Ich gehe auch auf spezifische Szenarien ein, bei denen es sinnvoll sein kann, Screenshots oder Fotos des Codes oder von Diagrammen zu machen, anstatt abstrakte oder generische Bilder zu benutzen. Dies zeigt, dass sich der Präsentierende Gedanken über das Projekt gemacht hat und bereit ist, seinen eigenen Beitrag zu präsentieren. Zudem gebe ich Tipps, wie man mit einfachen Mitteln die Bildqualität verbessern kann, wie zum Beispiel der Einsatz von Tiefenunschärfe beim Fotografieren.

Zusammengefasst ist mein Hauptanliegen, darzulegen, dass die Nutzung von KI-generierten Bildern in der Projektpräsentation nicht empfehlenswert ist. Stattdessen empfehle ich, eigene Bilder anzufertigen, die direkt mit der eigenen Arbeit verbunden sind. Damit kann jeder Präsentierende seine eigene individuelle Geschichte erzählen und sein Engagement und seine Kreativität effektiv präsentieren. Dies war die erste Episode des IT-Berufe-Podcast short, in der ich hoffe, dass Sie wertvolle Einblicke gewinnen konnten.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts

Transkription der gesamten Episode Automatisch erzeugte Transkription der Episode

[0:20] Moin und herzlich willkommen zu einem neuen Format, was ich hier mal ausprobiere. Vielleicht warst du schon etwas irritiert, als du das Podcast-Intro gehört hast, was jetzt seit 195 Episoden ähnlich ist. Seit der Umbenennung von Anwendungsentwickler-Podcast auf IT-Berufe-Podcast hat sich ein bisschen geändert. Okay, aber sonst ist es gleich geblieben. Und jetzt habe ich mir einfach mal was Neues überlegt. Und zwar kriege ich relativ häufig per E-Mail bei Instagram, bei YouTube, wo auch immer man mich kontaktieren kann. Neuerdings auch bei TikTok übrigens immer mal wieder Fragen rund um die IT-Ausbildung. Und ich habe mir gedacht, bevor ich jetzt einzelne Leuten immer wieder per E-Mail antworte und immer wieder gleiche schreibe, könnte ich bestimmte Sachen, die mir häufig gestellt werden, auch einfach im Audio-Format bearbeiten. Dann haben nämlich auch andere was davon, zum Beispiel du, der das jetzt hier gerade hört. Deswegen fange ich doch jetzt mal mit diesem neuen Format an. Die Idee ist, dass ich jetzt hier nicht stundenlang irgendwas erzähle, sondern wirklich kurz und knackig auf eine Frage antworte. Kurz und knackig heißt bei mir natürlich trotzdem, dass es ein paar Minuten dauert.

[1:18] Aber wenigstens keine Stunde oder mehrere Stunden. Das ist auch ganz gut. Und ja, das war jetzt kurz die Erklärung zu diesem neuen Format. Und jetzt würde ich sagen, starten wir auch direkt mit der ersten Frage. Und die, die mir in letzter Zeit, ich nehme das jetzt hier 2025 auf, glaube ich, mit am häufigsten gestellt wurde, war, was mache ich in meiner Projektpräsentation mit KI-generierten Bildern? Oder allgemein auch KI-generierte Inhalte, aber ganz oft wird nach Bildern gefragt. Und ja, meine Antwort darauf, also sollte man KI-generierte Bilder in der Projektpräsentation benutzen, ja oder nein? Kurze Antwort, too long didn’t read, beziehungsweise too long didn’t listen to, wie auch immer man das nennen will. Nein, mach’s nicht. Und jetzt kommt die lange Antwort. Ich habe schon vor Jahren inzwischen, ich glaube, es war einer meiner allerersten Beiträge auf meinem Blog.

[2:00] Davon abgeraten, ClipArts in der Projektpräsentation zu benutzen. Was war damals meine Begründung? Die wirken absolut langweilig, überhaupt nicht emotionenweckend, haben nichts mit dem konkreten Projekt zu tun, sondern sind einfach so Beiwerk. Ich musste hier auf die Folie noch irgendwas Grafisches packen, weil mir irgendwer das gesagt hat und dann nehme ich einfach das erstbeste, was mir einfällt, ein ClipArt.

[2:22] Anstatt sich richtig hinzusetzen, sich richtig Gedanken zu machen, was zum Projekt passendes, vielleicht sogar ein eigenes Bild zu machen, wurden halt einfach Cliparts genutzt, die null Emotionen wecken. Ich habe auf meinem Blog so ein Beispiel von einem kleinen Hündchen, einmal als Clipart und einmal als echtes Foto. Und da wird jeder Mensch sofort sagen, egal ob man Hunde mag oder nicht, das ist nicht die Frage, aber emotional sprechender ist auf jeden Fall das Bild. Und das Clipart, er weckt genau null Emotionen. Und in den letzten Jahren hätte ich diesen Artikel jetzt umändern können von Clipart in Stockfotos, weil das war dann das, was als nächstes kam. Leute haben irgendwo gehört, es müssen Bilder in die Präsentation, also schmeißen sie die erstbeste Stockfotosuchmaschine an. Weiß ich nicht, was gibt es heutzutage, Pixabay und was es da sonst noch so gibt. Und suchen danach irgendwas und nehmen das erstbeste Foto. Und so kam es dann auch, dass ich in mehreren Präsentationen schon das exakt selbe Foto gesehen habe, weil zu so einem abstrakten Begriff wie, also abstrakt nicht, aber was mir gerade einfällt, ist ein Vergleich von zwei Frameworks zum Beispiel. Und da wurde halt einfach Vergleich oder Comparison in die Bildsuchmaschine eingegeben. Und was kam da immer als erstes? Ein Bild mit zwei Obstkörben. Und auf der einen Seite waren Äpfel drin und auf der anderen Seite waren Bieren drin. Also Äpfel mit Bieren vergleichen.

[3:35] Und das ist so das Erste, was einem einfällt, wenn man an einen Vergleich denkt. Und das ist absolut langweilig. Und ich will das gar nicht unbedingt abwerten, dass das so langweilig ist. Was ich viel schlimmer finde, ist, dass die Person, die präsentiert, sich halt null Gedanken gemacht hat. Sie zeigt halt nicht, dass sie sich Mühe gegeben hat, sondern einfach nur, dass sie das Erstbeste genommen hat, ihr eingefallen ist, beziehungsweise der Bildsuchmaschine eingefallen ist. Und diese tolle Idee haben auch viele andere Prüflinge gehabt. Und so kommt es dann, dass Präsentationen die gleichen Bilder verwenden. Was ich problematisch finde, weil es sind ja komplett unterschiedliche Projekte und es entsteht dann irgendwie der Eindruck, als hätten wir miteinander zu tun, aber ist ja gar nicht so. Also, warum zur Hölle will man Cliparts benutzen, will man Stockfotos benutzen oder im Jahr 2025 will man KI-generierte Bilder benutzen? Das ist das gleiche Prinzip. Die erwecken genau null Emotionen. Man sieht immer, dass sie KI generiert sind. Okay, das mag in Zukunft besser werden, dass man das nicht mehr erkennt, aber darum geht es mir nicht, sondern sie haben einfach nichts mit deiner Arbeit und deinem Projekt zu tun. Es ist halt etwas, was du nicht selber gemacht hast. Es ist immer etwas, was von draußen kommt, was nie hundertprozentig zu deinem Projekt passen wird und immer etwas gekünsteltes ist, was mit deiner eigentlichen Arbeit nichts zu tun hat. Und deswegen ist seit Jahren meine Empfehlung, mach doch einfach selber Fotos für deine Projektpräsentation. Du kannst einfach heutzutage mit jedem Handy, egal ob iPhone, Android oder was auch immer, jedes Handy hat eine vernünftige Kamera.

[4:58] Damit kannst du einfach kurz ein Foto machen, das dauert eine Sekunde, dann hast du ein Bild, was niemand anders auf der Welt außer dir so nachstellen kann. Das heißt, es ist eine ganz individuelle Geschichte, nur für dein Projekt und deine Projektpräsentation. Und es zeigt exakt genau das, was du gemacht hast. Dein Projektumfeld, dich als Person meinetwegen, dein Ausbildungsunternehmen, deinen Arbeitsplatz, deinen Prozess, den du automatisieren willst, deinen Drucker, den du angebunden hast, deinen, was auch immer du in deinem Projekt gemacht hast. Genau das zeigt dann dieses Bild. In der echten Umgebung, in deinem echten Unternehmen, in deinem echten Umfeld, PC, Hardware, was auch immer. Es zeigt genau dich und deine Leistung. Also warum willst du bei so einem geringen Aufwand, den das verursacht, irgendein anderes, nicht authentisches, nicht zu deinem Projekt passendes Bild benutzen? Diese Frage würde ich immer als Gegenfrage stellen.

[5:47] Und dann kommt ganz oft die Antwort, ja, aber ich habe so abstrakte Sachen, die ich zeigen muss. Zum Beispiel meinen Programmfluss. Ja, mein Gott, dann mach doch ein Screenshot. Wenn du zum Beispiel Code zeigst, da erwartet auch keiner, dass du den Code mit Bildern vorträgst oder tanzt, sondern wir wollen einfach den Code sehen. Also pack ein Screenshot rein. Wenn du dir Architektur zeigen willst, zeig dein UML-Diagramm. Wenn du deine Kundendoku zeigen willst, mach ein Screenshot deiner Kundendoku. Oder wenn du es cool machen willst, druckst du die Kundendoku auf Papier aus, legst es auf den Tisch und machst mit deinem Handy ein cooles Foto von dieser Dokumentation. Das ist alles tausendmal besser, als irgendein generiertes Stockfoto oder Clip-Up-Bild zu benutzen, was nichts mit deinem Projekt zu tun hat. Das ist meine Kernzusammenfassung. Auf die Antwort, soll ich KI-generierte Bilder benutzen? Die Antwort ist nein.

[6:33] Also, es gibt sehr, sehr viel, was du einfach mit dem Handy fotografieren kannst. Wenn du was am PC gemacht hast, und davon gehe ich aus, nimmst das Handy, hältst das so leicht schräg an dem Bildschirm, dass das vielleicht sogar, alles heute möglich mit Handys, so eine leichte Tiefenunschärfe hat, dass das sogar so ein bisschen spannend vielleicht sogar aussieht, vielleicht hältst du dich sogar an diese Drittelregel, dass die interessanten Inhalte genau ein Drittel sind, das dauert.

[6:53] Statt einer dann vielleicht drei Sekunden, bis du das perfekte Bild hast, dann drückst du einmal drauf und dann hast du das in optimaler Auflösung, das Bild, was genau dein Projekt zeigt. Und es geht aus meiner Sicht nichts darüber hinaus. Und du könntest dann sogar noch, wenn du möchtest, irgendwelche Sperenzien mit einbauen. Ich weiß nicht, bei meinen dazu ist es zum Beispiel so, unsere Projekte haben immer Tiernamen oder auch wahlweise Pokémon-Namen. Und wir haben dafür dann sogar so kleine Maskottchen, also einfach so kleine Kuscheltiere. Zum Beispiel, was fällt mir gerade ein? Eine Robbe, ein kleiner Krebs, ein Gepard. Also wir haben so einfach kleine Maskottchen für die Projekte und Projektchen und die könnte man dann sogar in dieses Bild mit einbauen. Wenn man wirklich nochmal einen kleinen humoristischen Ansatz oder irgendwie noch ein bisschen mehr Persönlichkeit in die Bilder reinbringen will, dann setzt man zum Beispiel die kleine Robbe einfach neben den Bildschirm, wenn man von dem Bildschirm ein Foto macht, wo der Code drauf ist oder was auch immer man da zeigen will. Diese Möglichkeiten hast du alle nicht, wenn du das irgendwie KI generierst. Und jetzt kannst du natürlich sagen, ja, aber die KI kann mir ja auch alles Mögliche generieren und bla. ja, das kann sie vielleicht, kommt beim allerersten Versuch das perfekte Bild raus? Wahrscheinlich nicht. Sind irgendwelche Fehler drin? Irgendwas nicht ganz, was du haben willst? Dann musst du die nächste Iteration machen, musst du wieder warten und noch mehr iterieren. Und am Ende brauchst du vielleicht für so ein Bild eine Stunde oder so, bis das wirklich fertig ist und einigermaßen zu dir passt, während du mit dem Handy das Ding in einer Minute eben knipsen kannst. Am Arbeitsplatz, an dem du wahrscheinlich sowieso den ganzen Tag sitzt.

[8:11] Also, noch mehr in die gleiche Richtung. Meine klare Empfehlung, nutz einfach eigene Bilder. Mach eigene Bilder von deiner Umgebung. Es geht nichts darüber hinaus, über das, was du selber gemacht hast, um deine Eigenleistung zu zeigen. So, das war heute mein erster IT-Berufe-Podcast short. Ich hoffe, du konntest ein bisschen was mitnehmen. Ich sage danke für die Aufmerksamkeit und bis zum nächsten Mal. Tschüss!

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. 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.

Die grafischen Darstellungsformen sind standardisiert. Das heißt, es gibt eine verbindliche Syntax für sie. Und als Prüfende:r 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üfenden drücken sicherlich auch mal ein Auge zu, aber diese potentielle Fehlerquelle kann man sich sparen, indem man keine Diagramme nutzt.

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.

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. Alle 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.

Links

• Permalink zu dieser Podcast-Episode
• Die perfekte IHK-Prüfung (mein Online-Kurs zur Vorbereitung auf die schriftliche IHK-Prüfung)
• Project Euler (kleine kniffelige Programmierprobleme zum Üben)

Transkription der gesamten Episode

[0:04] Herzlich Willkommen zum IT-Berufe-Podcast, dem Podcast rund um die Ausbildung in den IT-Berufen. In dieser Episode geht es um Pseudocode-Aufgaben in der schriftlichen IHK-Prüfung. Viel Spaß!

[0:20] Hallo und herzlich Willkommen zur 195. Episode des IT-Berufe-Podcasts. Mein Name ist Stefan Macke und heute geht es um eines meiner Lieblingsthemen in den schriftlichen Prüfungen. Und Lieblings in Anführungszeichen, bitte verstehen. Und zwar geht es um Pseudocode-Aufgaben in der IHK-Prüfung. Und wenn du dich jetzt fragst, ist das nicht nur für Anwendungsentwicklerinnen relevant? Nein, das ist für viele IT-Berufe interessant und vor allem für die FISIs, die Systemintegratorinnen. Die haben das nämlich auch relativ häufig in ihrer Abschlussprüfung Teil 2 tatsächlich. Hätte ich gar nicht so erwartet. Aber da gibt es relativ oft Aufgaben, so Skripte mal dies und das. Bau mal einen kleinen Mini-Algorithmus 4XY hier, keine Ahnung, in der Automatisierung, Netzwerk oder so etwas. Und im Prinzip sind das die gleichen Aufgaben wie für Anbietungsentwickler, plus vielleicht vom Umfang her nicht ganz so groß. Aber die geben auch doch durchaus ganz schön vier Punkte und kommen relativ häufig vor in der API 2. Hatte ich so auch gar nicht auf dem Zettel, dass das so ist. Und für die Anwendungsentwicklerin ist das natürlich Brot und Butter in der API 2. Pseudocode kommt ja wirklich in, also meines Wissens nach bislang in jeder API 2 dran, entweder im ersten oder zweiten Teil, also dem Entwickeln von Algorithmen oder dem Plan eines Softwareprodukts eher im zweiten Teil Entwickeln von Algorithmen.

[1:34] Passt ja auch irgendwie zum Titel der Prüfung, logisch. Aber auch in der AP1 sogar kann Programmierzeug drankommen. Mit dem neuen Prüfungskatalog 2025 wurde das ja nochmal so ein bisschen verschärft, dass man, also was heißt verschärft nicht, es wurde genauer, detaillierter spezifiziert, sagen wir mal so, was da abgefragt werden soll und was nicht. Haben so ein paar relativ abstrakte Sachen rausgenommen. Ich glaube, Vererbung oder sowas bei der Web-Dorientierung, das ist nicht mehr so interessant. Aber dafür die Grundlagen der Programmierung, die sind für alle IT-Berufe in der AP1 dran und werden da abgefragt. Und dann ist halt die Art der Aufgaben, wie man das abfragt, eigentlich immer eine Pseudocode-Aufgabe.

[2:14] Meistens kann man dann, wenn man so einen Algorithmus formuliert, auch noch eine Alternative wählen. Früher waren das immer Struktogramme zum Beispiel. Die sind aber jetzt rausgeflogen. Das würde man jetzt also durch ein Aktivitäts-Zirgramm der UML machen. Komme ich aber später nochmal darauf, warum ich das vielleicht nicht empfehlen würde. Und deswegen soll es heute um den Pseudocode gehen. Ist für alle IT-Berufe relevant, für FISIs und FIAEs, sogar für die AP2 höchstgradig relevant. Und ja, ich werde so oft nach dem Thema gefragt, wie man sich da vorbereiten kann, weil viele damit echt ein Problem haben mit diesen Aufgaben. Und deswegen dachte ich mir, ich nehme jetzt endlich mal was dazu auf. So meine allgemeine Empfehlung, wie gehe ich mit Pseudocode-Aufgaben um und wie hole ich da das Maximum vielleicht an Punkten raus, wie bereite ich mich da vor und so weiter. Darum soll es heute gehen. Und ich habe das mal so ein bisschen strukturiert. Wir fangen mal ganz vorne an. Warum gibt es überhaupt diese Pseudocode-Aufgaben? Warum werden die in der ERK-Prüfung abgefragt? Schauen wir uns mal ganz kurz ein Beispiel an, an dem wir uns dann so ein bisschen vielleicht später meine Erklärung immer wieder mal anschauen. Und dann geht es darum, was man überhaupt können muss für diese Pseudocode-Aufgaben. Also welche Teile von Programmierung sollte man sich da vielleicht anschauen. Und dann gucken wir uns mal an, was der Prüfungskatalog genau dazu sagt, wie das eigentlich in der Prüfung abgefragt werden soll. Und dann schauen wir uns an, was Pseudocode eigentlich ist, wie man den schreibt. Gibt es dafür Standards? Wie muss der aussehen? Und dann kommen wir auch schon zu meiner Empfehlung, wie ich das in der Prüfung schreiben würde. Und ja, dann nochmal, wie gerade schon angeteasert, Alternativen. Warum nicht einfach ein Aktivitäts-Dirgramm zeichnen?

[3:41] Und letzter Part der Episode ist dann, wie lerne ich das? Wie kann ich mich darauf vorbereiten, auf diese Aufgaben? Weil halt viele Prüflinge in der Prüfung echt Probleme mit diesen Aufgaben haben. Und deswegen machen wir ganz am Ende nochmal so häufige Fehler, die sich da vielleicht einschleichen meiner Erfahrung nach aus den Prüfungskorrekturen. Ja, das wäre so der Ablauf für heute. Und weil ich mir vorstellen könnte, dass das ein bisschen länger dauert, würde ich sagen, gehen wir direkt mitten rein und starten mal mit dem ersten Part.

[4:06] Warum werden überhaupt solche Pseudocode-Aufgaben in der IHK-Prüfung abgefragt? Das ist doch völlig weltfremd. Pseudocode, da muss ich eine neue Syntax lehren. Das ist ja wie eine neue Programmiersprache. Und warum können die nicht einfach, und hier bitte Programmiersprache X einsetzen, Python, Java, PHP, C, C Sharp, was auch immer, in der Prüfung abfragen. Warum muss ich Pseudocode lernen für die Prüfung? So im Kern ist das so ein bisschen immer die Frage, die mir gestellt wird. Oder wie kriege ich es eigentlich hin, dass ich diese Aufgaben richtig verstehe? Weil zugegebenerweise sind diese Aufgaben relativ lang. Zumindest in AP2 für Amnesty Mekla können die auch einfach mal eine DIN A4 Seite lang sein. Nur der Beschreibungstext. Und dann kommt die eigentliche Aufgabe. Also da kann man sich ja schon darüber streiten, warum jetzt diese Fragen in der Prüfung drankommen. Ich sage mal meine Meinung zu Beginn, ich finde diese Aufgaben eigentlich sehr sinnvoll, insbesondere in der AP2-Anwendungsentwicklung, weil das ja nun mal der Kern unseres Berufes ist und etwas ausgeweitet auch auf alle anderen IT-Berufe. Ich behaupte, ein ITler, eine ITlerin, die überhaupt gar nicht programmieren kann, wird es einfach in ihrem Job schwer haben. Und das ist ganz egal, ob ich eigentlich Systemintegration mache.

[5:15] Das ist mal nur ein blödes Beispiel. Aber will ich wirklich als Systemintegrator 23 neue User, die am 1.8. Anfangen, per Hand in mein Active Directory eintragen? Oder skripte ich das vielleicht nicht einfach schnell mit einer PowerShell in 10 Zeilen und dann habe ich das Ding erledigt in 5 Minuten, statt eine Stunde lang was abzutippen? Ja, also Programmierung ist halt Dreh- und Angelpunkt vieler Automatisierungsprobleme, die wir in der IT nun mal sehr häufig haben. Also das ist aus meiner Sicht Kern unseres Berufs und gerade als Anwendungsentwicklerin natürlich nochmal mehr, weil das ist ja genau das, was wir lernen sollen. Ich vergleiche das mal mit so einem Tischler. Der wird wahrscheinlich heutzutage in der Praxis seinen Tisch auch nicht mehr from scratch selber zimmern und da fünf Stunden investieren oder noch länger, sondern der wird wahrscheinlich irgendeiner Fräse, Säge, was auch immer, einem Programmierauftrag erteilen und sagt, hier schneiden wir den Tisch und fertig. Aber trotzdem ist es wahrscheinlich so, und ich habe keine Ahnung von der Tischler-Ausbildung, um ehrlich zu sein, aber ich könnte mir vorstellen, dass da irgendwo im Prüfungsanalog steht, ein Tischler muss ein Stück Holz so abfeilen, ist wahrscheinlich das falsche Wort, schleifen können, dass man sich da keine Splitter in den Finger jagt wahrscheinlich. Also so die Basics seines Berufs, irgendwie Holz schleifen, muss man wahrscheinlich trotzdem drauf haben, auch wenn man im Endeffekt dann der Maschine am Ende nur noch sagt, wie das genau gesägt werden soll. Und so sehe ich es in der Realität auch. Jetzt kann man sagen, so programmieren müssen wir eh nicht mehr, weil es gibt ja KI, die macht das für uns. Ja, in großen Teilen sicherlich auch richtig. Für so kleine Sachen kann ich mir das heute schon perfekt generieren lassen. Da muss ich gar nicht mehr viel programmieren.

[6:40] Aber was ist denn, wenn irgendwas nicht mehr läuft? Dann wird es halt ein Problem. Was ist, wenn die Säge nicht richtig gesägt hat? Dann muss ich halt trotzdem noch mal nacharbeiten. Und wenn die KI nicht richtig programmiert hat, dann muss ich halt trotzdem das mal korrigieren, dafür muss ich es verstehen. Und dann ist jetzt die Frage, wie prüfen wir.

[6:54] Diese Prüflinge in den IT-Berufen algorithmisches Verständnis haben. Denn genau darum geht es. Und das sage ich meinen Azubis auch. Das sind jetzt alles Anwendungsentwicklerinnen. Okay, aber das würde ich anderen ITlern und ITlerinnen genauso erzählen. Und zwar, unser Job ist eigentlich nicht Programmieren, sondern Probleme zu lösen. Und gerade im Zeitalter von KI kann ich vielen, ich war gerade gestern noch auf einer Jobmesse und zwei Menschen, die ich angesprochen habe, ob sie nicht eine Ausbildung machen wollen, haben mir schon gesagt, ja, habe ich mal überlegt, aber die KI wird das ja alles überflüssig machen. Also ich mache jetzt was anderes. Fand ich interessant, so als junger Mensch, dass man schon diese Einstellung hat. Und deswegen würde ich sagen, wenn man sich nur darauf versteift, eine Programmiersprache perfekt zu beherrschen, dann macht man sich vielleicht wirklich irgendwann überflüssig, weil die KI das ganz sicher besser kann. Die kann viel schneller, besser, umfangreicher diesen Code generieren. Also so ein bisschen abwertend kann man ja solche Menschen als Code-Affe bezeichnen. Hier sind die Anforderungen, programmieren wir das. Und so etwas kann die KI heute schon und es wird auch immer besser. Also da müssen wir uns nichts vormachen. Aber was eigentlich unser Job ist als Anwendungsentwicklerin und auch in den anderen IT-Berufen ist, Probleme zu lösen.

[8:01] Kein Fisi wird dafür bezahlt, dass der Benutzer im Active Directory anlegt, sondern das Ding dahinter, was das Unternehmen eigentlich haben will, ist, dass ich ein neuer Mitarbeiter anmelden kann und mit den Systemen arbeiten kann und Geld verdienen kann. Zum Beispiel, weil er in SAP irgendwelche Rechnungen eintragen muss oder so.

[8:16] Das ist immer der Hintergrund. Das dürfen wir nicht vergessen. Die IT-Berufe sind sehr häufig nicht oder eigentlich fast nie Selbstzweck, sondern wir sind immer Dienstleister und Dienstleisterinnen für die Bereiche, die das eigentliche Geld verdienen. Außer wenn ich jetzt eine Softwareentwicklungsbude bin, klar, dann verdiene ich Geld mit der Softwareentwicklung, logisch. Ja, aber in vielen anderen Bereichen sind wir Dienstleistende für die anderen Mitarbeiter, die eigentlich das Geld verdienen. So, sage ich mal ganz blöd. Und deswegen sage ich unseren Anbietungsentwicklerinnen immer, dein Job ist eigentlich Probleme zu lösen. Und wenn du dieses Problem mit einer Programmiersprache lösen kannst, super. Aber wenn nicht, dann such halt was anderes, um das Problem zu lösen. Und das ist etwas, was uns hoffentlich noch ein paar Jahre von der KI unterscheiden wird, dass die halt außer Programmieren nicht so viel kann und vielleicht nicht die Anforderungen genau analysieren kann, auseinandernehmen kann, nachfragen kann, war das wirklich so gemeint, was ist mit dieser Unsicherheit, hast du an diesen Edge-Case gedacht, etc. Und das ist auch heute schon und wird hoffentlich und vermutlich auch in Zukunft die Aufgabe von Anwendungsentwicklerinnen bleiben. Und ganz am Ende wird dann das Zeug in eine Programmier-Sprache gegossen. Und ob ich das dann selbst programmiere oder der KI sage, dass sie das für mich programmiert, ist dann am Ende fast egal. Das ist ein Werkzeug und am Ende muss der Computer das Ding ausführen, was ich mir da ausgedacht habe. Und genau darum geht es. Was habe ich mir da eigentlich ausgedacht? Wie will ich dieses Problem lösen, was mir da gestellt wird? Das wollen wir abprüfen in der Prüfung. Und das hat nichts mit einer konkreten Programmiersprache zu tun, die ich, na da gibt es ja heute schon 200 verschiedene von, ja.

[9:45] Sondern ich will wissen, ob dieses grundlegende Verständnis, wie man bei der Problemlösung vorgeht, ob das funktioniert, ob das der Prüfling oder die Zuprüfende kann. Darum geht es bei diesen Aufgaben. Und jetzt müssen wir da irgendeine Lösung finden, weil wir nicht nur in Deutschland, aber auf der Welt halt wirklich die 200 oder mehr Programmiersprachen haben. Da können wir jetzt nicht sagen, diese eine Sprache muss jeder ITler, jede ITlerin lernen. Das ist nicht möglich und das ist auch heute nicht so und auch nicht umsetzbar. Deswegen brauchen wir eine allgemeine Form, um Algorithmen zu formulieren. Und das ist der Pseudocode. Es geht in der Prüfung nicht darum, dass man eine Programmiersprache super beherrscht, sondern dass man irgendwie verständlich machen kann, wie man ein Problem lösen möchte. Und dafür nimmt man Pseudocode. Wir gehen ja später nochmal auf einen, wie der genau aussieht. Das spoiler ich jetzt mal noch nicht. Aber das ist der Kern des Ganzen. Und das muss man sich immer vor Augen führen. Kannst du ein Problem lösen? Das sollst du zeigen. Und deswegen fokussiere dich nicht so auf diesen Pseudocode, der da immer so ein paar Problemchen mit sich bringt, sondern lies die Aufgabe mal so und versuch zu verstehen, was ist eigentlich das Problem, was hier gelöst werden soll und wie würde ich da rangehen. Und wie wir das dann konkret machen, da gehen wir dann gleich nochmal drauf ein.

[10:54] Und ganz wichtig dabei ist, und deswegen Pseudocode und nicht eine konkrete Programmiersprache, diese Prüfung wird ja, in Klammern, noch von Menschen korrigiert. Wie zum Beispiel mir. Ja, ich bin jetzt seit fast 20 Jahren IHK-Prüfer und habe schon einige Prüfungen mit korrigiert. Und da ist das ganz wichtig, wenn du diese Prüfung schreibst, dass der Mensch, der das korrigiert, das verstehen muss, was du da schreibst. Und wenn du jetzt eine super komische Programmiersprache benutzt, die kaum jemand kennt und vor allem der Prüfende nicht, dann wird das ganz schwierig, deine Antwort zu bewerten. Ja, weil die Person kann ja gar nicht sagen, ob das jetzt richtig ist. Und jetzt sagen natürlich alle, ja, aber Java oder Python, das muss ja jeder kennen. Ja, das sagst du vielleicht, weil du in deiner Bubble, in deiner Welt das so siehst. Aber es gibt so viele andere Unternehmen auch in Deutschland, die ITler und ITlerinnen ausbilden und die teilweise Programmiersprachen einsetzen, davon hast du noch nie was gehört, ja. Es gibt genug Firmen, die zum Beispiel ABAP in SAP einsetzen, ja, hat überhaupt nichts, ganz wenig syntaktisch mit Java, C Sharp oder PHP zu tun, sieht ganz anders aus, ganz andere Struktur.

[11:56] Ganz andere Möglichkeiten der Sprache, aber es gibt auch viele noch kleinere Nischensprachen, es gibt immer noch genug kleine Unternehmen, die zum Beispiel Delphi einsetzen als Programmiersprache, ja, und, ähm, also wirklich, deswegen so ein bisschen auch über den Tellerrand mal gucken und nicht sowas sagen, wie, hey, ich finde das aber doof, dass das nicht in Java, Python, PHP gemacht wird. Stell dir einfach vor, du bist tatsächlich nicht der einzige Azubi in Deutschland, der die IT-Ausbildung macht. Wenn du ein bisschen mein Newsletter verfolgst, ich habe es vor kurzem rumgeschickt, es gibt, glaube ich, Stand 2025, 17.000 neue IT-Azubis, die diesen Ausbildungsvertrag unterschrieben haben. Und 17.000 Menschen in Deutschland machen diese Ausbildung und die lernen nicht alle die gleiche Programmiersprache. Ja, das ist einfach so. Wir haben noch gar nicht von den Berufsschulen geredet, die auch alle machen können, was sie wollen und das auch tun. Das heißt, es gibt nicht die eine Sprache, die alle können oder können müssen und deswegen brauchen wir was anderes und das ist der Pseudocode. Und wenn ich jetzt aus Prüfersicht da drauf schaue und du haust mir mit irgendeiner komischen Programmiersprache, die ich noch nie gesehen habe, eine Lösung dahin, dann kann ich das wahrscheinlich in großen Teilen verstehen, weil das ist ja alles kein Hexenwerk normalerweise. Aber wenn da irgendwelche Spezialitäten drin sind, die ich aus keiner anderen Sprache kennen kann oder mir herleiten kann, dann ist es halt schwierig, da einen Punkt für zu geben. Ja, und ich kann nicht bei der Korrektur der IHK-Prüfung nochmal nebenbei bei Google oder Chat-GPT recherchieren, was, wie, welche Programmiersprache macht. Das kann nicht meine Aufgabe sein. Es dauert eh schon sehr, sehr lange, diese Prüfung zu korrigieren.

[13:18] Also, ganz wichtig für dich, du musst deinen Algorithmus so formulieren, dass der Mensch, der das Ding am Ende liest, das verstehen, nachvollziehen und bewerten kann, ob das richtig ist. Darum geht’s. So, jetzt machen wir zum Einstieg gleich mal ein Beispiel, auf das ich mich dann vielleicht später immer mal wieder so ein bisschen fokussieren kann oder referenzieren kann. Und zwar, das war so, glaube ich, noch nicht in der RK-Prüfung, das habe ich mir selber ausgedacht. Das ist aber auch keine Wahnsinnsaufgabe, aber ähnliche Sachen kamen schon mal dran. Und zwar, berechne doch mal zu einer Zahl die Quersumme. So, das ist jetzt erstmal die Aufgabenstellung. Und jetzt ist das erste Problem, ich muss erstmal wissen, was die Quersumme überhaupt ist. Wenn ich nicht weiß, was die Quersumme ist, kann ich auch keinen Algorithmus erzeugen, um die Quersumme zu berechnen. Das heißt, ganz kurze Erklärung und das wäre dann ja in IHK-Prüfungen natürlich erklärt. Also da wird jetzt nicht irgendwas komisches vorausgesetzt.

[14:07] Quersumme könnte man jetzt behaupten, dass man das vielleicht sogar aus der Schule kennen sollte. Aber auch hier, ganz viele Prüflinge haben ja ganz unterschiedliche Schulbildung, die sie mitbringen vor der Prüfung. Also normalerweise wird hier alles erklärt, was man wissen muss, um ein Problem zu lösen. Und in diesem Fall, die Quersumme, was ist das? Wenn ich mir eine Zahl angucke, die aus mehreren Ziffern besteht, zum Beispiel die 123, besteht aus den Ziffern 1, 2 und 3. Und wenn ich jetzt diese Ziffern nehme und aufaddiere, dann ist das die Quersumme der Zahl. Das heißt, bei 123 habe ich die Ziffern 1, 2, 3. Und wenn ich 1 plus 2 plus 3 rechne, dann habe ich als Ergebnis 6. Und das ist die Quersumme der Zahl 123.

[14:46] Und jetzt ist die Frage, wie berechne ich das, indem ich einen Computer das machen lasse. Weil das wollen wir ja gerade haben. Wir wollen ja einen Algorithmus formulieren. Ein Algorithmus, eine allgemeingültige Problemlösungsvorschrift. Erinnern wir uns daran, was ein Algorithmus noch einmal ist. Und das muss ich so aufschreiben, dass dann der Computer das ausführen könnte. Und ich sage dann immer gern zum Einstieg, versuch das doch mal so zu formulieren, als würde nicht der Computer da vor dir sitzen, sondern als würde da ein Grundschüler, eine Grundschülerin sitzen, die jetzt diese Aufgabe für dich lösen soll. Gehen wir mal davon aus, dass die Grundschülerin die Basics der Arithmetik beherrscht, also plus minus mal geteilt und vielleicht noch Modulo und so ein paar Sachen wie zum Beispiel Arrays scanned und so, wo wir später nochmal drauf eingehen. Und dann musst du dieser Grundschülerin sagen, mach jetzt mal dies, das, jenes, um dann am Ende zur Quersumme zu kommen.

[15:35] Und wenn ich jetzt mal, ich habe ja gerade relativ schnell einfach formuliert, wie das berechnet wird. Mein anderes Lieblingsbeispiel, was ich auch jahrelang immer in Einstellungstests benutzt habe, ist, wie berechnet man das Alter eines Menschen? Und zwar nicht taggenau, sondern einfach, hey, wie alt bist du? 43. Okay, ja. Wie kommt man auf dieses Alter unter Angabe des Geburtsdatums und des Datums, zu dem ich das Alter berechnen möchte? Also zwei Datumsangaben rein, ein Integer raus quasi. Und das kann im Alltag gefühlt jeder im Kopf mal eben so machen. Aber sobald es dann losgeht, dass man das strukturiert aufschreiben muss, wie man wirklich für zwei beliebige Datumsangaben das berechnet, fangen echt viele Menschen an zu schwimmen. Und deswegen finde ich das so wichtig auch, dass man diesen Skill, sage ich mal, in der IHK-Prüfung prüft, weil das ist halt das Zentrale für unseren Beruf, dass wir so etwas können.

[16:23] Aber zurück zur Quersumme. Wie würde ich das jetzt machen? Ich würde mir das überlegen. Ich habe eine Zahl. Und um das kurz abzugrenzen, Zahl ist 123. Die Ziffer ist die einzelne Ziffer dieser Zahl. Also eine Zahl besteht aus mehreren Ziffern. Da geht es schon los mit der richtigen Nomenklatur. Wie nenne ich was? Und jetzt wäre die erste Aufgabe, und das ist gleich so ein bisschen vorgegriffen, wie man Probleme allgemein löst, nämlich nach dem Divide and Conquer Prinzip, also zerlege und herrsche. Divide et impera, hieß das glaube ich mal auf Latein, der geschätzte Herr Julius Caesar hat das damals gemacht.

[16:58] Zerschlage deine Feinde in möglichst kleine Gruppen und da haust du dann mit dem Hammer drauf und dann am Ende hast du alles erobert quasi. Und genau so geht es hier auch. Wenn ich nicht weiß, wie ich eine Quersumme berechne, dann fange ich erstmal an und zerlege mir das Problem in kleinere Schritte und die dann wieder in kleinere Schritte und wieder in kleinere, bis ich irgendwas habe, was ich einfach programmieren bzw. Durchführen kann. Und die Quasi, wenn wir berechnen, da geht es erstmal los. Ich brauche die einzelnen Ziffern. Das heißt, vielleicht wäre der erste Schritt, wie kann ich überhaupt eine Zahl in ihre Ziffern zerlegen? Und allein dafür gibt es schon drei verschiedene Varianten, die mir jetzt so einfallen würden, was man machen könnte. Nur als Beispiel. Ich könnte, und das habe ich ähnlich schon mal in Prüfungen gesehen, die Zahl, ich gehe jetzt mal davon aus, dass es ein Integer ist, in einen String umwandeln und dann zum Beispiel mit einer Schleife durch die einzelnen Buchstaben, in Anführungszeichen, die dann die Ziffern sind, durchiterieren. Ja, mit einer Schleife zum Beispiel. Könnte ich tun. Dann habe ich nur das Problem, dass ich erst in String umwandeln muss. Ich habe dann aber keine Ziffern, sondern einen Charakter. Den muss ich wieder in eine Zahl zurückwandeln. Das ist alles ein bisschen Frickelei, aber es wäre denkbar. Ja, es gibt auch eine andere Lösung und die würde ich in diesem Fall bevorzugen und zwar eine mathematische Lösung. Das heißt, wie kann ich der Reihe nach bei einer Zahl durch ihre Ziffern laufen?

[18:08] Da geht es schon los. Durch Laufen wird wohl irgendwas in Richtung Schleife sein. Ich könnte es aber auch anders lösen. Ich muss ja nur was wiederholen. Ich könnte auch rekursiv oder so arbeiten. Das ist erstmal ganz egal. Sondern ich muss erstmal eine Idee haben, wie ich das Problem überhaupt löse. Und wenn ich jetzt sage, ich zerlege die Zahl in ihre Ziffern und dann gehe ich jede einzelne Ziffer durch und… Ach ja, die muss ich ja aufsummieren. Ah, da brauche ich also noch irgendwas, wodrin ich mir diese Summe merke. Ah, nochmal zurück zum Reißbrett. Nummer 1.

[18:35] Definiere eine Variable, die Summe heißt und initialisiere sie mit 0. Das ist unser Startwert. Dann gehe jede einzelne Ziffer der Zahl durch. Und addiere die Ziffer auf die Summe. Und als letztes, gib die Summe zurück. So, das wäre zum Beispiel ein Algorithmus für die Quersumme. Wenn man jetzt aber genau reinguckt, reicht das für die Prüfung noch nicht aus, weil dieses Lauf mal durch die Ziffern der Zahl, ja, wie geht das denn jetzt? Also da gibt es, wie gesagt, drei verschiedene Möglichkeiten, die mir so ad hoc einfallen, die mit dem String habe ich gerade erklärt.

[19:06] Da geht es jetzt noch mal tiefer rein. Dieser Teilschritt ist noch nicht genau genug, weil du kannst zum Beispiel vielen Programmiersprachen nicht einfach sagen, hier hast du ein Integer, lauf mal die Ziffern durch. Bei einem String die Stellen durchlaufen, okay. Bei Integer die Ziffern durchlaufen, gibt es in keiner mir bekannten Sprache eingebaut. Vielleicht mit Libraries oder so.

[19:27] Und dieses Problem musst du jetzt selber lösen. Wie würdest du das machen, wenn man dir eine Zahl gibt? Wie läufst du durch die Ziffern? Und wie gesagt, du könntest das mit dem String machen oder du könntest es mathematisch machen. Und ich hatte schon gesagt, die basic arithmetischen Operationen, die sollten dir was sagen. Und die letzte, die ich aufgeführt habe, war der Modulo. Also Division mit Rest, die dir den Rest liefert. Und das kann man zum Beispiel hervorragend machen bei Integerzahlen. Da könntest du nämlich einfach Modulo 10 rechnen. Und Überraschung, dann kriegst du im Prinzip die letzte Ziffer der Zahl. Du gehst also nicht von vorne nach hinten durch die Zahl, sondern von rechts nach links. Wenn du eine Zahl Modulo 10 rechnest, teilst du die Zahl durch 10 und dir wird der Rest gegeben. Und wie du vielleicht noch aus der Schule kennst, jedes Vielfache von 10 ist natürlich durch 10 teilbar. Das heißt, ab der zweiten Stelle der Zahl ist alles, was links noch kommt, definitiv durch 10 teilbar. Aber nur das, was ganz, ganz hinten steht, die letzte Stelle, die ist nicht durch 10 teilbar, weil die ist ja kleiner als 10. Da passt die 10 nicht rein. Das heißt, wenn du bei irgendeiner ganzen Zahl Modulo 10 rechnest, bekommst du immer die letzte Stelle der Zahl. Weil alles vor der letzten Stelle ist durch 10 teilbar und fällt damit weg.

[20:39] Beispiel 123 Modulo 10, das Ergebnis ist 3.

[20:43] 127 Modulo 10, das Ergebnis ist 7. Das heißt, du könntest jetzt schon mal mit einer mathematischen Operation, die relativ basic ist, Modulo 10. Das ist eine Anweisung, die kannst du in jeder Programmiersprache so schreiben. Das ist eine Zeile Code, die kannst du auch nicht weiter runterbrechen und musst du auch nicht. Und das wäre jetzt der Ansatz zum Beispiel, um an die letzte Stelle zu kommen. Und jetzt musst du nur das nächste Problem lösen, wenn ich die letzte Stelle ermitteln kann. Wie kann ich denn jetzt von der ganzen Zahl diese letzte Ziffer so abschneiden, dass nur noch die übrigen Ziffern überbleiben? Weil wenn ich das jetzt auch noch kann, dann kann ich den Algorithmus ja quasi wieder von vorne starten. Nimm die letzte Ziffer, schneid die letzte Ziffer ab. Nimm die letzte Ziffer, schneid die letzte Ziffer ab. Und so lange, bis es keine Ziffer mehr gibt.

[21:25] Und das Schöne dabei ist, wenn du ein bisschen Mathematik beherrschst, kannst du die entsprechende Gegenoperation zum Modul nehmen, nämlich die Division, div heißt das in vielen Sprachen oder ganz normal einfach der geteilt durch Strich, das ist nämlich in so ziemlich jeder Sprache, die ich kenne, die ganzzahlige Division. Das heißt, wenn du ein Integer geteilt durch 10 rechnest, dann liefert der nicht als Ergebnis eine Kommazahl, sondern er schneidet den Kommateil ab, weil deine Zahl und 10 beides Integers sind. Und Integer geteilt durch Integer wird nicht magischerweise ein Double oder ein Float, sondern bleibt ein Int. Das heißt, es wird einfach die Nachkommastelle abgeschnitten, sozusagen. Und wenn du eine Zahl durch 10 teilst, ist das ja nichts anderes als das Komma, um eine Stelle zu verschieben. Wenn du 123 durch 10 teilst, kommt raus, 12,3. Das heißt, das Komma ist einfach 1 nach links gewandert. Und wenn du bei dieser Division aber jetzt die Nachkommastelle einfach abschneidest, bleibt als Ergebnis 12 aus 123 geteilt durch 10 wird 12. Und Überraschung, das sind genau die ersten beiden Ziffern der Zahl, 1 und 2. Das heißt, mit Modulo 10 kommst du an die 3 und mit geteilt durch 10 kommst du an die 1 und 2, also die verbleibende Zahl. Und damit kannst du wieder von vorne starten. Und dieser kleine Trick Führt jetzt dazu, dass unser Algorithmus so aussehen könnte. Definiere eine Variable mit dem Namen Summe und initialisiere sie mit 0.

[22:48] Dann, solange die Zahl nicht 0 ist, mach folgendes.

[22:55] Zu addierender Wert gleich Zahl modulo 10.

[23:00] Addiere den zu addierenden Wert auf die Summe. Setze die Zahl auf Zahl geteilt durch 10.

[23:07] Und das war der Algorithmus. Ganz am Ende müsstest du noch sowas sagen wie gib Summe zurück oder so, damit die auch zurückkommen. Aber das war’s. Was mir gerade einfällt, noch besser wäre, wenn du die Variable Quersumme genannt hättest und nicht Summe. Dann wäre das sogar noch ein bisschen sprechender. Das heißt, die Quersumme wird durch eine Schleife, die so lange läuft, wie die Zahl noch stellen hat, ganz blöd gesagt, solange sie nicht Null ist, immer wieder addiert durch den Wert der rechtesten Ziffer. Und das alles nur mit Mathematik, ohne String-Gefrickel oder so etwas.

[23:39] Hätte man das so lösen müssen? Nein, komme ich später auch nochmal drauf. Es geht nicht darum, die perfekte, super optimierte, tolle mathematische Lösung zu finden, sondern einfach erstmal nur das Problem zu lösen. Das heißt, wenn du es lieber mit einem String machst und sowas machst wie, ich versuche es nochmal, definiere eine Variable mit dem Namen Quersumme und initial siehe sie mit 0, dann wandle die Zahl in einen String um und für jeden Buchstaben in der Zahl, wandle den Buchstaben in eine Zahl um, addiere diese Zahl auf die Quersumme und geh zum nächsten Buchstaben. Das wäre es. Könnte man auch machen. Da muss man jetzt nur ein bisschen aufpassen, wie gesagt, mit der Typumwandlung dazwischen und so weiter. Aber Lösung wäre das trotzdem, die funktioniert. Das heißt, für diese Aufgaben als allererstes mal den Tipp, du musst überhaupt erstmal eine Lösung finden. Das wäre erstmal das Allerwichtigste. Wenn du im Kopf dieses Problem nicht lösen kannst, wenn du nicht erklären kannst, wie man die Quersumme bildet, Dann brauchst du es auch nicht zu programmieren, weil du weißt gar nicht, wie du es programmieren musst, wenn du keine Lösung hast. Das heißt, als allererstes suchst du dir eine funktionsfähige Lösung, egal ob die String-Geschichte oder die Modulo-Geschichte, völlig egal. Hauptsache, du hast erstmal eine Lösung im Kopf und dann überlegst du dir, wie du die als Algorithmus formulierst und das mit Pseudocode. Und das gucken wir uns im Nachgang jetzt weiter an, wie man das jetzt genau macht.

[24:56] So, kurzer Mini-Exkurs, was man so an Kenntnissen für die IHK-Persuchung mitbringen sollte, für die Aufgaben, die dort gestellt werden, üblicherweise auch schon für die AP1. Im Prinzip ist der Kern hier algorithmisch. Das heißt, es geht uns nicht um funktionale Programmierung, Objektorientierung, irgendwelche tiefer gehenden Konzepte, sondern um die Basisbestandteile von Algorithmen. Und wenn du das noch nie gehört hast, es gibt drei Bestandteile, aus denen man Algorithmen zusammensetzt und wenn man die kann, dann kann man jedes Problem, was sich berechnen lässt, auch lösen. Man braucht keine fancy, coolen zusätzlichen Sprachfeatures, es geht mit diesen drei Basic-Sachen. Und die definieren so ganz nebenbei auch, ob man überhaupt von einer Poamiersprache redet, weil eine Poamiersprache braucht alle diese drei Möglichkeiten, sonst darf sie sich nicht als solche bezeichnen. Und diese drei Algorithmen-Bausteine sind Sequenz, Verzweigung und Wiederholung. Sequenz bedeutet der Reihe nach etwas ausführen, also mach 1, mach 2, mach 3. Der Reihe nach von oben nach unten abarbeiten.

[25:54] Verzweigung ist eine Fallunterscheidung, das heißt entweder mache ich das eine oder ich mache das andere auf Basis einer Entscheidung. Zum Beispiel, wenn das Alter größer ist als 18, dann mache irgendwas, ansonsten mache was anderes. Fallunterscheidung. Und dann habe ich noch eine Wiederholung, also mache Dinge mehrfach hintereinander. Immer wieder gleichartig und dann aber 20 mal das Gleiche. Das wäre eine Wiederholung. So, und wenn ihr gut aufgepasst hast, habe ich jetzt hier nicht gesagt, wir haben Sequenz, If und Vorschleife, sondern ich nenne bewusst die allgemeinen Varianten Verzweigung und Wiederholung. Denn nicht in jeder Programmiersprache gibt es If und Vor, sondern das kann man auch anders lösen. Also gerade bei der Wiederholung, da gibt es nicht nur Schleifen, wie man Dinge wiederholen kann, sondern es gibt zum Beispiel auch noch die Rekursion. Auch mit Rekursion kann man Dinge wiederholen. Es gibt sogar noch ein drittes, nämlich mit Go-Tos. Die allerersten Programmiersprachen, die hatten weder Schleifen noch Rekursion. Da wurde mit Go-To gearbeitet. Also geh drei Zeilen wieder hoch, geh drei Zeilen wieder hoch. Das ist auch eine Wiederholung. Das heißt, ich bin hier ein Freund davon, die allgemeinen Sachen zu formulieren, denn manchmal kommen in der IHK-Prüfung auch rekursive Algorithmen dran. Und da ist der rekursive Aufruf das Mittel der Wahl, um Dinge zu wiederholen. Von daher, diese allgemeinen Sachen braucht eine Programmiersprache und die musst du kennen für Pseudocoach.

[27:11] Mehr ist es normalerweise nicht. Das heißt, ich habe üblicherweise irgendwie so ein paar Fallunterscheidungen, da ist da mal eine Wiederholung drin. Also meistens ist es eine Schleife und meistens ist es natürlich ein If, aber auch bei der Verzweigung. Es kann ja auch mehr Ververzweigungen geben. Zum Beispiel mit einem Switch oder so etwas.

[27:24] Und wenn ich jetzt noch einen Schritt weiter gehe, Verzweigung, könnte ich sogar eine Objektorientierung Polymorph lösen. Also es gibt auch hier, Verzweigung, Wiederholung kann ich auf verschiedene Arten umsetzen. Das ist nicht immer nur ein If-Statement und immer nur die Vorschleife. Es gibt auch andere Möglichkeiten.

[27:39] Also das solltest du kennen, Sequenz, Verzweigung, Wiederholung. Und dann, wie gerade schon erwähnt, so die basic mathematischen Sachen. Die plus, minus, mal geteilt und Modulo. Modulo würde ich dringend empfehlen, da solltest du dir unbedingt angucken, weil das in ganz vielen Aufgaben benötigt wird. oder du zumindest dir das Leben damit einfacher machen kannst. Und dann ist es in der IHK-Prüfung häufig so, dass irgendwas mit, Arrays dran kommt. Wahlweise auch Listen, also irgendwelche, ja, ich nenne sie mal allgemein Collections.

[28:04] Ja, was wäre denn ein schöner deutscher Begriff? Eine Liste hört sich dann wieder so an wie so ein List-Interface zum Beispiel in Java. Das meine ich aber gar nicht. Sondern einfach eine Liste mit mehreren Elementen. Und ob es jetzt ein Array ist oder eine List oder eine Array-List oder eine Linked-List oder so, ist erstmal egal. Sondern du sollst in vielen Aufgaben zeigen, dass du mit mehreren Elementen umgehen kannst. Und Spoiler, das machst du fast immer mit einer Schleife.

[28:27] Aber da kommen wir dann vielleicht später nochmal drauf. Also Arrays, wichtiges Thema. Und dann kann es sein, das ist dann aber eher für Anbietungsentwickler dann so, dass da ab und zu auch mal so ein bisschen Objektorientierung, ich sage immer gerne, so drauf, gestreuselt wird, dass dann zum Beispiel aus dem Array Sachen rausgefriemelt werden und dann sollen die als Objekt einer Klasse irgendwie zusammengebaut und instanziiert werden oder so. So ein kleiner, mini-objektorientierter Anteil. Oder manchmal sogar funktionale Programmierung eingestreut wird, Das heißt, in einer Prüfungsaufgabe war sowas wie ein Sortieralgorithmus und dann sollte das Kriterium, nachdem man sortiert, flexibel sein. Und das wurde dann mit so einer Art funktionalen Programmierung gemacht. Das heißt, anstatt hart zum Beispiel zwei Vornamen zu vergleichen, sollte der Vergleich an sich über eine Funktion, die hineingegeben wurde, durchgeführt werden. Das war jetzt von der Syntax her nicht sonderlich schwierig. Man hätte jetzt auch nicht zwangsläufig funktionale Programmierung verstehen müssen, um das lösen zu können. Aber zumindest sind Ansätze zu erkennen, auch diese, wie soll ich sagen, modernen Sachen in die Programmierung mit reinzugeben. Weil oft beschweren sich die Prüflinge natürlich, das ist ja Programmierung wie vor 100 Jahren, so gefühlt.

[29:33] Ja, okay, aber nochmal zurück zum Anfang. Es geht hier nicht um fancy Programmiersprachen-Features, sondern es geht um die Basics unseres Berufs, ein Problem zu lösen. Und jedes berechenbare Problem kannst du lösen mit Sequenz, Verzweigung und Wiederholung. Du brauchst keine Objekteorientierung, du brauchst keine Funktionalprogrammierung oder eben, du brauchst nur diese drei Sachen. Damit kannst du jedes Problem formulieren. Das ist so, dass das absolute Basic-Wissen, was alle ITlerinnen lernen sollten, völlig unabhängig von ihrer Programmiersprache.

[30:02] Deswegen, ehrlich gesagt, finde ich es auch gut, dass das in der Prüfung abgefragt wird und nicht irgendwelche Hardcore-Modernen in Anführungszeichen Sachen, weil du, wie gesagt, halt nicht, also selbst wenn du zum Beispiel, wie meine Azubis auch, Ausbildungen mit Java machst und du natürlich nicht, hoffentlich, auf Java Version 6 vor 15 Jahren arbeitest, sondern ein bisschen modernere Sachen machst, kannst du natürlich auch funktionale Programmiersprachensachen da einbauen. Das ist ja richtig cool. Das wollen wir auch im Alltag benutzen. Bitte verstehe mich nicht falsch. Ich erwarte nicht, dass du im Alltag prozedurales Zeug wie hier mit Verzweigung und Wiederholung programmierst. Darum geht es nicht. Ich erwarte, oder die Prüfenden erwarten, dass du einen Algorithmus formulieren kannst. Und dass du das in einem echten Projekt mit einer echten Programmiersprache noch cooler lösen kannst, ist ja super. Und mach das auch gerne. Das freut mich. Und da habe ich auch Bock drauf. Auf jeden Fall.

[30:48] Nur das ist halt eben nicht Teil der Prüfung. In der Prüfung sollst du nur zeigen, dass du den Algorithmus formulieren kannst. Und dafür müssen wir eine Sprache benutzen, die jeder andere Azubi auch spricht. Ganz blöd gesagt. Und leider macht nicht jeder Azubi in Deutschland mit der gleichen Programmiersprache seine Ausbildung und hat schon mal was von Streams und Optionals und irgendwas gehört. Das ist einfach nicht so. Und das kannst du jetzt wahlweise ersetzen durch irgendwelche Sachen in Python,

[31:10] die es vielleicht auch nicht in Java gibt oder so. Es ist völlig egal, welche Sprache. Wir können uns einfach nicht auf eine einigen. Und deswegen brauchen wir die absoluten Basics. Und das ist Sequenz, Verzweigung und Wiederholung. So, das zu dem Thema. Und jetzt machen wir weiter mit der Frage, was der Prüfungskatalog denn eigentlich zu der Lösung dieser Pseudocode-Aufgaben sagt.

[31:33] Da gibt es nämlich relativ exakte Vorgaben, wie man diese Aufgaben lösen soll. Und da steht extra nochmal erklärt, dass dort eben nicht in einer bestimmten Programmiersprache programmiert werden soll. eben genau vor dem Hintergrund, dass das ja vielleicht für einige Menschen nicht verständlich ist, wenn sie diese Sprache nicht kennen. Das ist einfach so. Du kannst auch nicht deine IHK-Prüfung auf Spanisch beantworten, nicht mal auf Englisch. Das geht nicht. Die Sprache der IHK-Prüfung ist Deutsch. Und ich weiß, dass man da jetzt selber drei Stunden drüber diskutieren kann, ob das so richtig ist, weil wir haben auch viele Menschen, die die Prüfung machen, die Deutsch nicht als Muttersprache haben. Das ist ein ganz anderes Problem. Und natürlich wäre das cool, wenn das anders wäre. Ist aber nicht so. Das heißt, wir müssen uns jetzt, solange die Prüfung halt so ist, daran orientieren, was da gefragt wird. Und im Prüfungskatalog steht explizit, der Code soll für Dritte ohne Kenntnis der verwendeten Programmiersprache lesbar sein. Das heißt, wenn du zum Beispiel den Teil aus deiner Java-Programmiersprache nimmst, der relativ sicher von vielen anderen Menschen auch verstanden werden kann, bist du gut dabei. Nimmst du aber irgendwelche.

[32:32] Funktionalen, Stream-basierten, Optional-irgendwas-Sachen, die man nicht sofort verstehen kann, ist es halt ein Problem. Also, das sagt der Prüfungskatalog. Dritte ohne Kenntnis der Sprache sollen das verstehen können. Das ist eine explizite Aussage. Dann steht auch explizit drin, der Code muss nicht kompilierbar oder ausführbar sein. Das heißt, es gibt nicht den Zwang, eine richtige Programmiersprache zu benutzen. Andersherum übrigens, spoiler ich schon mal, schließt das nicht aus, dass du auch einfach eine Programmiersprache nutzen kannst. Also du kannst, wenn du willst, deinen ganzen Code auch in Java schreiben. Das ist überhaupt kein Problem. Du kannst alle Klammern, alle Semikola, alles da eintragen. Das ist überhaupt kein Thema, solange Punkt 1 eingehalten wird, dass Dritte das ohne Kenntnis der Programmiersprache lesen können. Ganz einfach, ja? Also, das vielleicht schon mal vorweg. Wenn du Bedenken hast bei diesem Pseudocode, dann schreib es einfach in der Programmiersprache, die du den ganzen Tag benutzt. Das ist überhaupt kein Problem. Aber mit ein paar Einschränkungen, zu denen ich gleich noch komme, Namentlich, dass jeder andere Mensch das verstehen muss, auch wenn ich noch nicht seit drei Jahren Python programmiere. Das heißt, hier wieder runtergestrippt auf die Basics. Sequenz, Verzweigung, Wiederholung. Wenn du das benutzt aus deiner Sprache, schreibt Python, Java, C-Sharp, PHP, völlig egal, aber nutzt du irgendwelche fancy Sachen, die die anderen Leute außerhalb deiner Programmiersprachen-Bubble nicht kennen, dann kriegst du ein Problem.

[33:52] Also, es muss nicht kompilierbar sein. Gehen wir gleich auch nochmal bei meiner Empfehlung drauf ein, wie man Pseudocode schreibt. Ich spoiler schon mal, lass einfach alle Klammern und Semikolons weg. Muss ja nicht kompilierbar sein, viel zu viel Schreibarbeit, bringt niemanden weiter, also lass das Zeug weg. Dann steht sogar explizit drin, Syntaxfehler, wer denn toleriert? Das heißt, selbst wenn du, keine Ahnung, bei Array.length nicht length, sondern length schreibst, einfach zwei Buchstaben vertauscht hast, egal, darum geht es nicht in der Sprache. Wenn ich erkennen kann, dass du mit length wohl length, also die Länge meintest, dann ist das okay. Wenn du das auf Englisch nicht so gut schreiben kannst, kannst du auch sagen, Variable x gleich Länge des Arrays. Gültiger Absurdokode. Ich muss ja nur verstehen, dass du auf die Länge des Arrays zugreifen willst. Und ob du Leng oder Len oder Length oder Length, Hauptsache ich erkenne, dass es irgendwas mit der Länge zu tun hat. Das ist wichtig. Also Syntaxfehler werden toleriert.

[34:46] Und dann noch, finde ich, ein wichtiger Punkt, Kontrollstrukturen wie zum Beispiel durch Einrücken müssen ersichtlich sein. Das heißt, wenn du sowas wie ein If, eine Vorschleife und so weiter machst, ich hatte ja eben schon gesagt, Verzweigung, Wiederholung kann man auch anders machen, aber in 95 Prozent der Fälle wird es ja wahrscheinlich ein If und wahrscheinlich eine Vorschleife oder eine While-Schleife sein. Das ist ja klar. Ich will nur darauf hinweisen, dass es auch andere gibt, aber in den meisten Fällen wird es am Ende doch das If und wird die Vorschleife. Und dann wäre es durchaus sinnvoll, dass du den Kopf und den Rumpf der Schleife oder des If-Statements so absetzt, dass man auch erkennen kann, was wohin gehört. Das heißt, wenn nach der Schleife oder nach dem If noch weiterer Code kommt, dann muss der natürlich wieder ausgerückt werden, damit das nicht so aussieht, als würde er noch in die Schleife gehören. Solche Sachen müsstest du dann schon machen. Also wenn wir meinen Tipp von eben nehmen, lass die Klammern weg. Gut, lass die Klammern weg, aber dann rück auch wieder aus, wenn die Schleife vorbei ist. Und das habe ich leider auch schon gesehen in Lösungen in der K-Prüfung, dass Leute einfach immer am Zeilen anfangen, anfangen zu schreiben. Egal, ob ich gerade in der dritten verschachtelten Schleife bin oder nicht. Und das ist natürlich mega schwer nachvollziehbar. Nicht nur für uns als Prüfende, sondern auch für dich selber. Wenn du es dir selber nochmal anguckst, so hä, welche Ebene war das jetzt hier? Es fängt ja alles an der gleichen Stelle an in der Zeile. Das ist nicht gut. Das heißt, hier steht sogar explizit zum Beispiel durch Einrücken im Prüfungskatalog. Also mach das einfach. Das wäre auch gleich mein gespoileter Tipp. Lass die Semikolons und Klammern weg, aber rück deinen Kram so ein, dass man erkennt, was wozu gehört.

[36:14] So, das ist also das, was der Prüfungskatalog vorgibt. Und dann könnte man jetzt ja sagen, gut, dann nehmen wir den Pseudocode, wie er im Buche steht. Der wird das ja wohl alles einhalten. Und dann schreibe ich damit die Prüfung.

[36:26] Ja, wäre schön. Leider gibt es keine Definition vom Pseudocode. Es gibt keine Standard. Es gibt keine Norm. Es gibt nichts, wo du nachgucken kannst, wie Pseudocode auszusehen hat. Es gibt verschiedene Varianten, die man auch zum Beispiel bei der Wikipedia sich mal angucken kann. Da gibt es zum Beispiel die Jana. Na, das ist ein Pseudocode, der auf Java basiert. Oder es gibt einen Pascal-ähnlichen Pseudocode. Hast du vielleicht auch schon mal in Musterlösungen gesehen? Das ist sowas, was immer mit Beginn und End oder so anfängt, anstatt Klammern zu benutzen. Das wird relativ häufig zum Beispiel auch in den Musterlösungen benutzt, würde ich behaupten, diese Pascal-ähnliche Syntax. Ich habe eigentlich jetzt auch schon extra als Vorbereitung nochmal die Musterlösungen der letzten Jahre durchgeguckt und das ist mal so, mal so. Das heißt, auch da nicht mal in den Musterlösungen, es sind auch gar keine Musterlösungen, sondern ja Lösungserläuterungen. Ich bringe das immer selber durcheinander. Man kann nämlich jeden Algorithmus auch anders lösen, als der in der Musterlösung steht. Aber da kommen wir gleich nochmal drauf. Wichtig ist aber, dass du nicht mal in den Lösungen einheitliche Vorschläge hast. Also mal ist es sehr Java-ähnlich, mal ist es Pascal, mal ist es ganz was anderes. Also es gibt hier keinen Standard. Und deswegen sage ich auch immer gerne, wenn du keinen Bock auf Pseudocode hast, dann schreib den Kram in einer Programmiersprache, die du kennst. Fertig. Das ist gültiger Pseudocode, weil es keinen Standard dafür gibt, gegen den das irgendwie gewertet wird. Denk an die Vorgaben, der Prüfer, die Prüferin muss es verstehen können. Das ist alles. Mehr Anforderungen gibt es nicht.

[37:50] Und deswegen kommen wir jetzt zu meiner Empfehlung. Was würde ich dir jetzt für die Prüfung konkret empfehlen? Ich würde dir ehrlicherweise empfehlen, nimm eine Programmiersprache, die du kennst, die du jeden Tag benutzt. Wahrscheinlich hast du in deiner Ausbildung die letzten zwei, zweieinhalb, drei Jahre eine Programmiersprache hauptsächlich benutzt. Das hoffe ich zumindest, dass du nicht 27 verschiedene gelernt hast, sondern hauptsächlich erstmal eine und die dann gut. und mit der kennst du dich hoffentlich so gut aus, dass du die Syntax, wie soll ich das jetzt sagen, auswendig, ohne nachzugucken, einfach runterschreiben kannst. Weil wir haben eben schon gehört, die Aufgabenstellung ist manchmal eine DIN-A4-Seite lang. Das dauert einfach extrem lange, diese Aufgaben zu bearbeiten. Als es noch möglich war, vor der Neuordnung der T-Berufe, habe ich meinen eigenen Azubis empfohlen, die Pseudogood-Aufgaben zu streichen, weil die einfach extrem lange dauern, super fehleranfällig sind in der Lösung. Und ja, also man verballert einfach so viel Zeit damit. Deswegen war das echt eine Streichaufgabe. Haben viele Prüflinge auch immer so gemacht. Pseudocode-Aufgaben gestrichen. Jetzt nach der Neuordnung geht das ja nicht mehr. Das heißt, wenn du Pseudocode hast, dann musst du es auch lösen. Kommst nicht drumherum.

[38:55] Deswegen mach dir das Leben nicht noch schwerer mit irgendeiner Syntax, die du nicht beherrschst, weil du sie nie benutzt, sondern nimm einfach die Poemiersprache, die du jeden Tag benutzt. Dann hast du da schon mal ein Problem weniger, wie du es formulieren musst. Nimm einfach eine Poemiersprache, die du kennst. Und dann aber mach dir das Leben einfacher. Lass alles Unnötige, was nicht zum Verständnis beiträgt, weg. Das sind Klammern oder Ende von irgendwelchen Kontrollstrukturen, sowas wie if und endif. Das endif zum Beispiel könntest du weglassen. Die Klammern kannst du weglassen. Die Semikolons am Ende, wenn das an deiner Sprache nötig wäre, kannst du weglassen. Also alles, was nicht den Kern, sag ich mal, der Statements in der Zeile, was du beschreibst, betrifft, kannst du weglassen. Solange es dann halt noch für Außenstehende verständlich ist. Dann machst du dir das Leben nicht schwer, weil du kannst es runterschreiben, du kennst es aus deinem Alltag und lässt aber alles weg, was dich Zeit kostet. Weil du das ja nicht vergessen auf Papier schreiben musst und jeder Buchstabe, den du da schreiben musst, beziehungsweise jedes Zeichen kostet dich Zeit.

[39:56] Dann unbedingt darauf achten, einrücken. Also meine Empfehlung, statt Klammern oder if and if, einfach einrücken. Dann ist es offensichtlich und du sparst dir Zeit. Und wie eben schon gesagt, lass bitte alle coolen Features der Sprache weg. Ja, ich habe da gleich noch ein paar Beispiele, was ich damit meine, was ich an der Stelle weglassen würde. Sondern benutze nur die Basics. Sequenz, Verzweigung, Wiederholung. Ja, und schon bei Wiederholungen geht es los, dass viele Sprachen so coole, geile Sachen haben, um noch kürzer, noch prägnanter irgendwie durch was iterieren zu können. Aber bitte, bitte, der wichtigste Punkt ist, die Prüfenden müssen das verstehen. Und wenn du irgendeine Python-spezifische Syntax hast, wo du mit drei Zeichen durch ein Array laufen kannst, ist das ganz toll. Das darfst du im Alltag rauf und runter benutzen. Aber bitte nicht in der Prüfung.

[40:46] In der Prüfung geht es darum, verständlich den Algorithmus zu formulieren. Ich wiederhole mich, weil das so wichtig ist. Aber ich sehe es halt so häufig in den Prüfungen, dass Leute das nicht machen. Und deswegen gehe ich halt heute so darauf ein. Also lass den ganzen coolen, hippen Kram weg. Ich sage immer so, du sollst hier nicht zeigen, dass du der geilste Programmierer bist oder die coolste Programmiererin und dass er alles viel besser kann als die Prüfenden. Sondern du sollst einfach zeigen, dass du die Aufgabenstellung bearbeiten kannst und einen Algorithmus formulieren kannst. Fertig. Darum geht es. Und alles, was du mit den drei Algorithmenbausteinen lösen kannst, das machst du auch damit und lass die komischen Features weg.

[41:23] So, letzter Punkt. Meistens sind die Datentypen in der Prüfung irrelevant. Das heißt, anstatt zu sagen int Quersumme gleich 0, kannst du auch sagen, definiere Quersumme als 0.

[41:34] Du musst normalerweise keine Datentypen hinschreiben, weil sie für den Algorithmus sehr oft irrelevant sind. Für die Quersummen-Aufgabe von eben war es egal. In diesem Fall wird wahrscheinlich sogar vorgegeben sein. Definieren Sie die folgende Funktion. Berechne Quersumme in Klammern int x oder so. Dann ist sogar schon vorgegeben, dass es ein Integer ist. Musste sich um nichts mehr kümmern. Wenn du aber zum Beispiel den Algorithmus mit dem Umwandeln in einem String und Durchlaufen der Ziffern machst, dann sind die Datentypen natürlich schon wichtig, weil du mit einem String halt nicht rechnen kannst. Das funktioniert nicht. Das heißt, wenn du dich für eine Lösung entscheidest, wo du Datentypen spezifische Sachen machen musst, damit es funktioniert, dann musst du bitte natürlich auch die Datentypen hinschreiben. Klar, aber für die meisten Algorithmen, die ich aus Prüfungen kenne, sind die Datentypen völlig irrelevant. Deswegen kannst du sie weglassen. Also zusammengefasst, ganz blöd gesagt, stell dir vor, du arbeitest in deiner Programmiersprache, aber die wäre jetzt auf einmal dynamisch typisiert. Das heißt, du brauchst keine Datentypen und alles, was unnötig ist, wie Klammern und Semikolons, kannst du weglassen. So, dann kannst du das runterschreiben, weil du Syntax kannst, lässt alles weg, was du normalerweise hinschreiben musst, aber was dich jetzt hier Zeit kostet. Und Datentypen, egal, weil du sollst ja das Problem lösen.

[42:50] So, das wäre meine Empfehlung. Und jetzt kommen natürlich dann schnell die Fragen, kann man das nicht noch anders machen? Warum nicht irgendeine Sprache so und so?

[42:57] Und vor allem, warum nicht grafisch darstellen? Könnte man ja auch. Da gehen wir jetzt nochmal kurz auf ein. Und zwar war es bis zu dem neuen Prüfungskatalog 2025 gängig, dass die Pseudocode-Aufgaben auch mit einem Struktogramm oder einem Programmablaufplan hätten dargestellt werden können. Man hätte also nicht programmieren müssen, man hätte auch einfach ein Struktogramm zeichnen können. Gut, dass den Prüfungserstellern und Erstellerinnen jetzt aufgefallen ist, dass das vielleicht keiner mehr macht in der Realität und deswegen haben sie das jetzt gestrichen. Aber eine alternative Darstellung gibt es natürlich trotzdem. Und das wäre jetzt das UML-Aktivitätsdiagramm, weil das ja genau dafür da ist. Algorithmen oder Arbeitsabläufe in einem Unternehmen, was auch nichts anderes ist, als ein Schritt-für-Schritt-Prozess zu einem Ziel. Das ist jetzt der Standardweg, um das visuell darzustellen. Meine Empfehlung ist aber seit Jahren, inzwischen sogar Jahrzehnten, glaube ich gleich, und zwar mach es einfach nicht. Schreib bitte Pseudocode. Aktivitätsdiagramm, Struktogramm, Programmablaufparln haben eins gemeinsam. Die sind super umständlich zu zeichnen, sau schwierig zu korrigieren und deswegen würde ich sie dir einfach für eine schriftliche Prüfung auf Papier nicht empfehlen. Es ist einfach zu aufwendig. Du hast sowieso viel zu wenig Zeit normalerweise für diese Aufgabe hier. Wenn du es mal durchrechnest, meistens, zumindest für die Anwendungsentwickler in Teil 2, sind die Pseudocode-Aufgaben eine dicke Aufgabe. Also ein Pseudocode für 25 Punkte oder sowas.

[44:15] Dann kannst du dir grob ausrechnen, 90 Minuten Prüfungszeit geteilt durch deine Punkte, dass du ganz grob ungefähr pro Punkt der Aufgabe eine Minute Zeit hast in der Prüfung, um sowas hinzuschreiben. Das heißt, für so eine Pseudocode-Aufgabe hast du so knapp 25 Minuten, um den kompletten Text zu lesen und dann auch noch die Aufgabe hinzuschreiben und zu lösen. Und das wird extrem schwierig, wenn du dann noch am besten mit dem Lineal irgendwelche Diagramme aufzeichnen musst. Und was viel schlimmer ist, wenn du die dann korrigieren musst, weil du siehst, oh, ich habe mich hier einfach vertan. Und sind wir ganz ehrlich, das passiert vielen in der Prüfung. Sind aufgeregt, überlesen was, gucken nochmal drüber und stellen fest, oh, scheiße, letzten Satz habe ich nicht gelesen und so weiter. Das kommt so oft vor. Also nutzt doch bitte eine Darstellungsform, die du leicht korrigieren kannst. Und das ist bei Pseudocor so. Da machst du einfach an der Stelle, wo du das vergessen hast, ein Sternchen, schreibst ganz unten auf der Seite nochmal ein Sternchen und schreibst die Zeit, die du vergessen hast und bist fertig. Beim Aktivitäts-Zirgramm musst du vielleicht Pfeile durchstreichen, irgendwo noch was daneben malen, dann passt das. Nicht mehr aufs Blatt, dann machst du da ein Sternchen hin, dann rafft das aber keiner mehr und so. Also das ist einfach super schwierig, grafische Darstellungen auf Papier zu korrigieren. Das ist einfach meine Erfahrung. Deswegen bleibt meine Empfehlung. Mach es einfach nicht, sondern mach Pseudocode.

[45:30] So, und dann nochmal, wir hatten es eben schon, warum benutzen wir nicht in der Prüfung eine genaue Programmiersprache, zum Beispiel Java? Habe ich jetzt auch schon mehrfach gesagt, weil nicht jeder IT-Jazubi in Deutschland eine Sprache lernt. Deswegen brauchen wir was Allgemeines und das ist der Pseudocode. Also, die einzige echte Alternative wäre das Aktivitäts-Tilagramm, weil das ist Programmiersprachenunabhängig. Aber wie gerade erklärt, dauert das zu lange, das zu zeichnen. Deswegen würde ich es dir nicht empfehlen. Also, aus meiner Sicht gibt es keine Alternativen zu Pseudocode. Und auch, sehe ich zumindest so, fände ich es sehr unglücklich, wenn die solche Aufgaben in Zukunft nicht mehr machen würden, weil die halt den Kern unseres Berufes abbilden sollen, nämlich algorithmisches Denken.

[46:06] Also gehen wir mal davon aus, dass die noch ein paar Jährchen in der Prüfung bleiben, auch wenn wir KI einsetzen, weil wie gerade schon gesagt, am Ende kann man natürlich die KI in den Algorithmus vielleicht formulieren, wenn sie die Problemstellung versteht. Aber da zumindest sind wir Stand 2025 der KI noch überlegen, was die Problemlösung angeht. Also Probleme, für die es bislang noch keine Lösung gab, eine Lösung zu finden. Auch ja, ich weiß, man kann ERK-Prüfungen bei ChatGBT reinstellen, der löst die dir. Das ist alles ganz toll. Aber es geht darum, dass du erstmal die Probleme lösen kannst und verstehen kannst und dann zum Beispiel irgendwann später mal die KI überprüfst, ob sie das denn richtig gemacht hat. Da muss dann vielleicht doch nochmal irgendwie ein Mensch drüber gucken. Das heißt, du kommst einfach nicht drum herum, dieses algorithmische Verständnis weiterhin dir anzueignen. Das ist zumindest mein Stand im Jahr 2025. Vielleicht gibt es mich in fünf Jahren nicht mehr, weil es nur noch KI da gibt. Aber naja, wir werden sehen, wie sich das entwickelt. Bis dahin gehen wir mal

[46:58] davon aus, dass du weiterhin algorithmische Aufgaben in der Prüfung haben wirst. Und dann ist die Frage, wie bereitest du dich darauf vor?

[47:04] Weil gerade für die Anwendungsentwickler gibt es halt viele, viele Punkte für diese Aufgaben. Und für die Systemintegratorin übrigens auch, habe ich gesehen, gibt es durchaus auch einen dicken Batzen für so ein Skript, was man da programmieren muss. Und da ist mein ehrlich gemeinter Tipp, lernen einfach programmieren. Das hört sich jetzt fies an, aber wenn Leute mir eine Woche vor der Prüfung eine Mail schicken, ich kann diese Pseudocode-Aufgaben nicht lösen, was kann ich tun? Dann kann ich sagen, schwierig. Weil wenn du nicht programmieren kannst, weil Darum geht es. Ein Problem in Teilprobleme zu zerlegen und dann diese Probleme zu lösen. Das ist das, was wir beim Programmieren täglich machen. Dann liegt das nicht am Pseudocode, den du schreiben musst, sondern liegt das einfach am Verständnis, wie man solche Probleme löst. Und das ist aus meiner Sicht etwas, was du in der Ausbildung lernen musst. Und zwar nicht eine Woche vor der Prüfung, sondern eigentlich ab Tag 1, weil das ist der Kern des Berufs, Probleme zu lösen.

[47:54] Deswegen mache ich auch diesen Podcast in der Hoffnung, dass du es nicht eine Woche vor der Prüfung hörst, sondern rechtzeitig vorher, damit du genau das

[47:58] dir noch aneignen kannst. Das heißt, übe einfach programmieren. Es gibt so viele Websites online, ob es jetzt, wie heißen die Dinger, Hacker, Rank oder Code, Schlagmichtor, also ich weiß es gar nicht. Ich denke mir die Aufgaben immer selber aus meistens, aber es gibt halt viele, viele Websites, die sich genau darauf spezialisiert haben. Beispiel-Programmieraufgaben, kleine mathematische Probleme. Ich kenne zum Beispiel das Project Euler, finde ich richtig gut. Das geht so mit ganz super einfachen mathematischen Sachen los, die man programmiert und es wird immer schwieriger. Man muss immer mehr oder größere Probleme da lösen. Da habe ich zum Beispiel ein paar Aufgaben von durchgemacht, das fand ich sehr, sehr spannend. Und es gibt noch viele, viele weitere Sachen. Es gibt sogar kleine Spiele, mit denen du das lösen kannst. Zum Beispiel Human Resource Machine habe ich zum Beispiel ein paar Level durchgespielt, fand ich ganz cool. Da steuert man so eine kleine Person, die dann im Prinzip in Assembler programmiert wird, was sie machen soll. Also nimm die Zahl vom Boden, pack sie in diese Liste und solche Sachen. Also das ist auch ganz cool, kann man auch machen.

[48:52] Wichtig ist, aus meiner Sicht, üben, üben, üben, machen, machen, machen. Konkrete Probleme lösen und im besten Fall kriegst du dann zu deiner Lösung auch Feedback. Dafür sind ja eigentlich Ausbilder und Ausbilderinnen da, ne? Dass du dann was programmierst und dann sagen die dir hier, das und das hättest du anders machen können, besser machen können und so weiter. Und ich weiß leider auch, dass es viele Azubis gibt, die nicht so intensiv betreut werden, das kannst du dann ersatzweise eine KI machen lassen im Jahr 2025. Gib doch den Code irgendwo rein, irgendein Modell, ich will keines bevorzugen und frag einfach, was kann ich hier besser machen? Ist das so richtig? Habe ich was übersehen? Kann ich das noch optimieren, verbessern, verschönern, was auch immer? Da hat die KI heute ja echt einen Riesen-Benefit. Die kann dir quasi zumindest, was das Feedback zu deinem Code angeht, Ausbilder und Ausbilderinnen ersetzen in Anführungszeichen. Du kannst ja sogar mit der drüber chatten sowieso, aber auch sprechen. Du kannst dir das Ganze sogar noch auf dem Audio-Kanal erklären,

[49:43] was du da falsch gemacht hast. Also unbedingt Feedback einholen, um dich zu verbessern. Darum geht’s, ja? Und dann ist das grundlegende Vorgehen eigentlich wie immer bei der Programmierung das Divide and Conquer.

[49:54] Zerlege das Problem in Teilprobleme, solange bis du das einzelne Teilproblem mit einer Zeile Code lösen kannst. Ganz blöd gesagt, ja? und das muss man einfach immer wieder machen, durchspielen mit verschiedenen Problemen, weil du normalerweise nicht dich auf alle Probleme der Prüfung vorbereiten kannst und irgendeins davon kommt dann dran, sondern die Aufgabenersteller denken sich natürlich neue Probleme aus, weil genau darum soll es ja gehen. Es will in der Prüfung normalerweise keiner von dir wissen, wie funktioniert der Bubble Sort. Programmieren Sie genau den Bubble Sort mit dieser Datenstruktur hier.

[50:27] Sondern es geht darum, ich möchte diese Liste sortieren. Go. Das heißt, es gibt keine genaue Vorgabe, wie etwas zu tun hat, sondern nur was gemacht werden soll. Und das sollst du dann zeigen, dass du dieses Problem lösen kannst. Und dafür gibt es halt nicht eine Liste von 38 Algorithmen, die du auswendig lernen kannst. Und eine davon kommt dann in der Prüfung dran. Sondern es ist halt immer eine Mischung, um ein Echtweltbeispiel in der Prüfung lösen zu können. Um das, was du im Alltag ja auch jeden Tag machst, zeigen zu können. Es wird niemand, wahrscheinlich, wird dein Chef oder deine Chefin nie zu dir kommen und sagen, ich brauche unbedingt einen Bubble Sort. Sondern er wird mit einem Geschäftsproblem zu dir kommen, sowas wie, keine Ahnung, wir haben hier einen Stapel Rechnungen von unseren Kunden und das Finanzamt will die nach Rechnungsnummer sortiert haben. Mach das mal. So, und dann ist das die Aufgabe. Und dann musst du sagen, ach, dann nehme ich einen Sortieralgorithmus, und zwar den, den ich da zufällig gerade kenne oder den ich mir selber ausgedacht habe oder einen von den 23, die es gibt und programmiere das dann. Oder ich nehme einfach eine Bibliotheksfunktion, die es sortiert. Deinem Chef ist es egal, wie du es löst. Hauptsache, du löst das Problem, dass die Rechnungen nach Rechnungsnummer sortiert werden.

[51:28] Das soll zu zeigen. Und auf dem Niveau bewegen wir uns auch in der IRK-Prüfung. Es kann sein, dass wirklich solche Sachen wie Grundalgorithmen, nenne ich sie mal, in der Prüfung drankommen. Und das ist sogar sehr häufig so. Also irgendwas sortieren, irgendetwas suchen, irgendetwas rausfiltern aus einer Liste zum Beispiel.

[51:45] Solche Basic-Algorithmen können natürlich als Teil so einer großen Aufgabe mal drankommen. Da steht dann halt in so einem Halbsatz, ach übrigens, das Endergebnis soll nach Preisabsteigen sortiert sein oder so. Und das macht dann bei dir im Kopf hoffentlich Klick. Oh, an der Stelle muss ich einen Sortieralgorithmus programmieren. Und dann hast du hoffentlich einen parat, im einfachsten Fall den Bubble-Zort, und programmierst den eben in fünf Zeilen runter. Und dann ist die Aufgabe ja gelöst.

[52:11] So, und dieses Divide and Conquer, das mache ich mit meinen Azubis, wie gesagt, teilweise schon vor der Ausbildung, um zu gucken, ob das überhaupt was für die ist, mit diesem Altersbeispiel. Wie berechnest du dein Alter? Und da findet man schon schnell raus, ob Leute das beherrschen oder nicht. Weil, jetzt mal kurz gespoilert, wie macht man das? Man zieht erst mal das heutige, man zieht das Geburtsjahr vom heutigen Jahr ab. Ja, da habe ich erst mal schon das grobe Alter. Und das Alter kann jetzt noch um eins abweichen. Wenn ich in diesem Jahr nämlich noch nicht Geburtstag hatte, dann muss ich davon noch eins abziehen und ansonsten bleibt es dabei. Und wann hatte ich noch nicht Geburtstag? Naja, entweder, wenn mein Geburtsmonat in der Zukunft liegt oder wenn ich im Geburtsmonat bin, aber der Tag noch in der Zukunft liegt. Und das muss ich jetzt der Reihe nach abprüfen, um zu dem Ergebnis zu kommen. Und das kriegen viele einfach nicht so einfach hin. Und daran kann man schon gut, wie ich finde, nachvollziehen, ob jemand so ein bisschen dieses Verständnis hat.

[53:01] Und das kann man üben. Ich sage das dann immer ganz gern so. Versucht das doch mal einem Grundschüler, einer Grundschülerin zu erklären, die gerade Mathe gelernt hat. Also rechnen kann die oder er. Und jetzt sag mal, was genau diese Schülerin da rechnen soll, um das Alter auszurechnen. Und dann nimmst du das aktuelle Jahr minus das Geburtsjahr. Und das ist erst mal das vermeintliche Alter. Jetzt muss ich prüfen. Wenn der Geburtsmonat größer als der heutige Monat ist, dann ziehst du von dem Alter einen ab.

[53:31] Ansonsten, wenn der Geburtsmonat gleich dem heutigen Monat ist, dann prüf bitte noch, ob der Geburtstag nach dem heutigen Tag ist, weil dann musst du auch einen abziehen. Und wenn das alles nicht zutrifft, geben wir das Alter so zurück. Das war’s. Ungefähr so müsste der aussehen. Also ein bisschen if und dann hat man das schon. Aber um da erstmal hinzukommen, tun sich halt relativ viele Leute dabei schwer und da hilft es mir immer zu sagen, tu mal so, als wäre ich ein Grundschüler und erklär mir das mal, was ich jetzt der Reihe nach machen muss. Und wenn dann sowas steht, wie wenn dann zum Beispiel die Person sagt, ja, rechne doch einfach den Unterschied zwischen den Datumsangaben aus. Dann frage ich immer zurück, wie so ein dummer Computer, der das nicht kompilieren kann. Ja, wie berechne ich denn den Unterschied zwischen das bei Datumsangaben? Ich kann nur Zahlen voneinander subtrahieren, aber keine Datumsangaben. Und dann kommt, ach ja, man muss ja erstmal das Ja abziehen. Okay, das mache ich. Und dann tue ich so, ja, was soll ich jetzt tun? Ich habe jetzt das Ja subtrahiert, jetzt gebe ich dir zurück 43. Ja, aber nee, ist ja nicht richtig, weil du musst ja noch was prüfen. Ja, dann musst du mir das auch sagen. Ja, okay, dann mach folgendes. Nimm den Monat und zieh den anderen Monat ab. Und so mache ich das in so einem Gespräch, um zu erklären, wie es funktionieren würde. Und so kannst du es dir auch für die Prüfung mitnehmen. Also, was müsste ich der Reihe nach wie tun, um dieses Problem zu lösen? Darum geht es.

[54:48] So, das wäre jetzt so meine Empfehlung fürs Lernen. Und jetzt nochmal kurz, wenn du mit alten Prüfungen lernst, was ich dir dringend empfehlen würde, weil nur so kriegst du natürlich auch ein bisschen ein Händchen dafür, für diese Formulierung von Problemen, für den Umfang der Probleme, dass du es auch zeitlich ein bisschen besser bewerten kannst, ob du es lösen könntest. Und dann ganz wichtiger Tipp, wenn du dir diese Lösungsempfehlungen, Musterlösungen anguckst, dann sei bitte nicht traurig, wenn dein Code nicht exakt so aussieht wie die Musterlösung. Das ist nämlich in ganz vielen Fällen so, weil es ist halt eben nur ein Lösungsvorschlag und eben nicht die Musterlösung, die man exakt so nachprogrammieren muss, was übrigens für alle anderen Aufgaben auch gilt, sondern es sind nur Lösungshinweise, die man auch, glaube ich, aus genau diesem Grund nicht kaufen kann, weil sonst würden alle sagen, aber ich habe das doch so und so und nicht. Es ist nur ein Vorschlag und diese Prüfung wird von Menschen korrigiert und die müssen die Kompetenz haben, das zu bewerten, ob das richtig ist oder nicht. Und wenn du statt einer Vorschleife eine While-Schleife benutzt hast und ich als Prüfender aber sehe, dass das richtig ist, dann gebe ich dir natürlich die Punkte, auch wenn in der Lösungsvorschlagsaufgabe, Lösung, so, eine Vorschleife steht. Oder what, was hatte ich jetzt? Weiß ich nicht. Auf jeden Fall, natürlich gibt es verschiedene Möglichkeiten, um solche Probleme zu lösen. Es gibt nicht die eine Lösung. Beispiel Quersumme, die String-Geschichte oder die Modulo-Geschichte führt beides zum richtigen Ergebnis. Also kann nicht das eine richtig und das andere falsch sein. Das ist nicht der Fall. Wenn es funktioniert, wird es auch punktet. Überhaupt kein Problem.

[56:15] Jetzt kann es aber ja sein, dass du bei deinen Übungen etwas ganz anders löst, als es halt im Vorschlag steht. Dann ist natürlich blöd, weil dann kannst du dich ja selber gar nicht bewerten, ob es jetzt einen Punkt gegeben hätte. Und auch hier wieder der Hinweis, dafür wäre jetzt vielleicht ein Ausbilder oder eine Ausbilderin ganz cool, die da vielleicht die Erfahrung mitbringt und dann wie ein Prüfender das halt bewerten könnte. Würde hier an der Stelle auch eine Wildschleife statt einer Vorschleife funktionieren? Ja oder nein? Wenn du das nicht selber herausbekommen kannst, weil du das vielleicht noch nicht so oft gemacht hast, dann brauchst du Feedback. Also frag Ausbilder, Ausbilderin und wenn das nicht geht, nimm die KI. Ich habe es eben schon gesagt.

[56:50] Dieser Algorithmus ist die Lösung. Ich habe das hier programmiert. Würde das auch funktionieren? Oder wie auch immer du die KI danach fragen wolltest. Die wird dir dann bestimmt eine schöne Lösung dafür geben. So, also wie lerne ich jetzt Pseudocode-Aufgaben? Mit alten Prüfungen. Gehe die Übungen durch und versuche runterzubrechen, die weit entkonker. Nimm eine Programmiersprache, die du kennst, lass alles Überflüssige weg und am Ende hol dir bitte noch Feedback ein von irgendwem, einem Menschen oder einer KI, der oder die dir dann sagt, war richtig oder nicht oder was hast du falsch gemacht, was hast du vergessen etc. Etc. So. Und dann häufige Fehler.

[57:28] Letzter Punkt für heute. Ich habe auch schon mal ein paar Pseudocode-Aufgaben korrigiert. Auch wenn ich, ich bin ganz ehrlich, auch die Prüfenden wollen sich ja wie alle ITler und ITlerinnen das Leben einfach machen. Und ich habe gar keinen Bock auf Pseudocode-Aufgaben. Und zwar aus genau dem Grund eben. Denn man kann das halt auf 27 verschiedene Varianten lösen. Und ich muss, wenn ich die korrigiere, ja jede dieser Varianten im Kopf immer durchspielen, ob das funktioniert. Und ob das auch wirklich funktioniert. Oder ob in diesem einen Edge-Case vielleicht doch nicht funktioniert. und da muss ich dafür vielleicht einen Punkt abziehen oder auch nicht. Und das ist extrem aufwendig, zeitaufwendig und schwierig und gedanklich herausfordernd, diese Sachen zu korrigieren. Das heißt, das ist, wenn ich irgendwie die Wahl habe, nehme ich nicht die Pseudocode-Aufgaben zum Korrigieren, weil das halt mega anstrengend ist. Genauso wie es für dich schwierig ist, zu schreiben, ist es für die Prüfenden

[58:12] schwierig, die zu korrigieren. Das heißt, nicht meine Favorite-Aufgaben in der Prüfung, nicht nur die Prüflinge sehen das so, auch die Prüfenden. Ja, aber wenn wir uns jetzt mal so ein paar oder wenn ich mir mal so ein paar alte Sachen vorstelle, die ich mal korrigiert habe, was waren so die Fehler, die ich am häufigsten gesehen habe? Und da fangen wir an mit meinem Standardfehler, den du eigentlich bei jeder Aufgabe machen kannst und zwar nichts hinschreiben. Bei meinen Episoden oder Blockartikeln, ich weiß schon nicht mehr zu SQL-Aufgaben in der Prüfung, sage ich das auch immer wieder.

[58:38] Du darfst das Blatt nicht leer lassen. Wenigstens bei einer SQL-Abfrage könntest du Select, Spalten, From, Tabelle hinschreiben. Das wäre das absolute Minimum. Dafür musst du überhaupt nicht verstanden haben, was du in der Aufgabe eigentlich machen musst. Aber die Spalten und die Tabellen aus dem Bild abschreiben, das dürftest du immerhin bekommen. Und das Gleiche gilt beim Pseudocode. Irgendeinen Teil des Pseudocodes wirst du hinschreiben können. Irgendwo erkennst du vielleicht ein If oder eine Schleife. Und wenn es auch nur eine Ausgabe am Ende ist, bei der Quersumme zum Beispiel, gib die Quersumme zurück, ist dann ein Teil der Aufgabe, dann kannst du wenigstens hinschreiben, Return Quersumme. Auch wenn du davor überhaupt nichts berechnet hast, aber zumindest einen Teil des Algorithmus, nämlich die Rückgabe, die wirst du hinschreiben können.

[59:20] Und das wird dir bei jeder Aufgabe so gehen, egal wie schwierig die ist oder nicht. Es wird immer irgendwas geben, was du da hinschreiben kannst. Und wenn es die kleinste Fitzeligkeit ist, ganz egal, aber es ist alles besser, als das Blatt leer zu lassen. Aber wenn das Blatt leer ist, dann kann ich dir wirklich, im wahrsten Sinne des Wortes, nur null Punkte geben. Ich kann da nichts mehr herzaubern, wo ich sage, ach, in Ansätzen war ja was da. Nee, leeres Blatt heißt null Punkte. Da gibt es auch keine Diskussion. Das finde ich super für Prüfende, weil das ist mega einfach zu korrigieren. Null dran schreiben, next. Aber das ist für dich natürlich ein Problem, weil du willst natürlich so viele Punkte wie möglich bekommen.

[59:58] Ja, da kann ich nur empfehlen, schreib irgendetwas hin, was irgendwie mit der Aufgabe zu tun hat. Und wenn bei Divide and Conquer du nicht weiterkommst als zur ersten Ebene, dann schreib wenigstens das hin. Schreib einen Pseudo-Algorithmus super abstrakter Form hin, wie zum Beispiel bei der Quersumme von vorhin. Für jede Ziffer der Zahl addiere Zahl auf Quersumme, gib Quersumme zurück. So, du hast dann das Problem, wie komme ich an die Ziffern der Zahlen nicht gelöst. Okay, aber du hast erkannt, dass du die Ziffern durchlaufen musst. Du hast, das habe ich jetzt gerade vergessen, die Variable Quersumme definiert und die am Ende zurückgegeben. So, das heißt, keine Ahnung, angenommen es gäbe jetzt irgendwie 6, 7 Punkte für die Aufgabe, dann könnte ich dir 3 ja schon mal geben. Weil das Laufen durch die Ziffern hast du erkannt, du hast was zurückgegeben, du hast was aufsummiert. Das sind doch Bestandteile, die erstmal funktionieren. Und wenn du dann einen Teil des Algorithmus nicht perfekt ausformuliert hast, dann ziehe ich dir dafür Punkte ab, aber es ist doch alles besser, als null Punkte zu kriegen, weil da gar nichts steht. Ja, also bitte immer etwas hinschreiben. Das behaupte ich einfach, dass du das immer machen kannst.

[1:01:01] So, Problem Nummer zwei. Das ist dann sehr häufig der Fall, dass die Leute einfach die Aufgabenstellung nicht verstehen. Ja, ich weiß, die IHK-Aufgaben sind immer ein bisschen besonders, manchmal unnötig kompliziert. Beispiele sind ein bisschen komisch. Also da kann man sehr lange und häufig drüber streiten. Ich weiß, das ist blöd und noch schwieriger wird es, wenn man kein Muttersprachler ist. Ich weiß, das ist ein riesiges Problem. Nur wir können es leider nicht ändern. Und deswegen ist meine Empfehlung,

[1:01:29] übe das einfach mit alten Aufgaben. Und wenn du da irgendwas nicht verstehst, dann wende dich an Ausbilder, Ausbilderinnen oder KI, die dir ja nicht einfach nur die Lösung hinklatschen können und sollen, sondern dir das auch erklären können und sollen, wie man sich da hinarbeitet. Und im Endeffekt wird es immer die Wide & Conquer sein. Ich glaube nicht, dass man da viel anders rangehen kann. Aber diese Übung und das Feedback, das ist das, was dir da weiterhilft. Und deswegen besorgt dir die alten Prüfungen und macht die Prüfungsaufgaben. Das ist an der Stelle meine zentrale Empfehlung.

[1:01:59] Und wenn wir dann nochmal runtergehen auf das, was wirklich in der Programmierung am Ende häufig ein Problem ist, sind das ganz klassisch Plus-Minus-Eins-Fehler. Da wird dann zum Beispiel in Schleifen, wie gesagt, in vielen Aufgaben braucht man wirklich mal eine Vorschleife zum Beispiel, da wird dann halt einer zu wenig, einer zu viel gezählt, weil statt kleiner gleich wird kleiner gemacht oder größer oder einfach Vorzeichenfehler oder sonstige Sachen. Also immer diese klassischen Programmierfehler, wofür wir auch hoffentlich Unit-Tests programmieren, die kommen natürlich auch in diesen Algorithmen dran. Und das ist immer das Erste, wo ich auch hingucke, ob irgendwas falsch ist, wird richtig gezählt. Beginnt das Array bei 0 oder bei 1? Wo wird her angefangen? Wird zum Beispiel in der Vorschleife, wenn ich durch ein Array laufe und ich habe eine Programmiersprache, die 0 basiert ist, was 95% der Sprachen sind, wenn ich dann bis zu Array.length zähle, dann bin ich natürlich schon aus dem Array rausgelaufen, weil das letzte Element hat Array.length minus 1. Und das sind so klassische Fehler, die natürlich bei Schleifen sowohl in der Realität auftreten können, als natürlich auch in der Prüfung. Also gerade bei so Grenzwerten, Array-Länge oder Array-Index und Altersbestimmung oder sowas, wo es um Grenzwerte geht, größer 18 oder größer gleich 18, was ist denn jetzt richtig? Diese klassischen Plus-Minus-Eins-Fehler, unbedingt darauf achten, die werden sehr häufig falsch gemacht, weil sie halt auch im wahren Leben sehr häufig falsch gemacht werden. Das ist ja jetzt hier keine künstliche Situation, sondern diese Probleme sind für Menschen ja häufig schwierig sofort zu erkennen und das ist in der Prüfung nichts anderes als im wahren Leben.

[1:03:27] So, dann ein Problem, was ich sehr häufig sehe, was aber jetzt wirklich prüfungsspezifisch ist und zwar, dass Aufgaben zu abstrakt gelöst werden. Was meine ich damit? Du löst die Aufgabe nicht wirklich selbst, sondern du sagst, das macht der Computer für dich. Mein Beispiel wieder bei der Quersumme. Durchlaufe die Ziffern der Zahl.

[1:03:45] Das ist etwas, das meines Wissens nach ein Computer nicht tun kann, weil er das nicht eingebaut hat. Der kann Modulo und Div und Plus, kann er alles, aber durchlaufe die Ziffern einer Zahl ist etwas, was er einfach nicht tun kann. Der kennt diesen Befehl nicht. Das heißt, den musst du weiter runterbrechen. Und da kannst du dich als Prüfling nicht hinsetzen und sagen, durchlaufe die Ziffern der Zahlen, summiere alles und dann löst du einen Algorithmus, der eigentlich sieben Zeilen lang sein müsste, in zwei. Und hier nehme ich gerne mein Zitat, sei nicht schlauer als die Prüfenden. Es geht nicht darum zu zeigen, wie geil du deine Programmiersprache beherrschst. Ich meine das überhaupt nicht abwertend. In der wahren Welt darfst du das alles jeden Tag einsetzen und da würde ich das sogar begrüßen und fände das richtig gut. Aber nicht in der Prüfung. In der Prüfung sollst du zeigen, dass du die Basics der Algorithmik beherrschst und dass du weißt, der Computer kann nicht einfach durch Zahlen die Ziffern iterieren und der Computer kann auch nicht Datum minus Datum rechnen. Das geht nur mit Int und Double und so weiter. Das heißt, das ist genau der Punkt, wo du zeigen musst, dass du weißt, was zu tun ist und dann zum Beispiel eben diese Modulo-Geschichte oder String umwandeln und so weiter machst. Und dieses zu abstrakt gelöst, das ist häufig ein Problem. Wir haben in einigen Aufgaben, hatte ich vorhin schon gesagt, sowas wie, ach übrigens, die Liste soll noch sortiert werden am Ende. Und dann schreiben dann halt einige Schlaumeier dahin, als letztes Statement, list.sort oder array.sort.

[1:05:12] Und das ist genau das, was ich meine. Im Alltag würde niemand einen Sortieralgorithmus selber programmieren, weil das ist verschenkte Lebenszeit. Die gibt es halt fertig. Und deswegen macht man im Alltag natürlich Punktzort und interessiert sich meistens 0,0 dafür, welcher Algorithmus dahinter steckt. Ich will einfach nur die Liste sortiert haben. Aber in der Prüfung ist das halt anders. In der Prüfung sollst du halt zeigen, dass du selber eine Sortierung programmieren kannst. Und dann reicht es halt nicht, List.zort zu schreiben, sondern du brauchst halt ein Minimum irgendeinen ganz kurzen Sortieralgorithmus, und ich sage jetzt einfach mal so ein Bubblesort, je nachdem, wie prägnant du den schreiben kannst, sind vielleicht fünf, vielleicht sechs Zeilen. Du brauchst eine kleine verschachtelte Schleife mit einem Vergleich und einem Vertausch. Dann sind das vielleicht fünf, sechs, vielleicht sieben Zeilen. Und es ist halt eben nicht eine Zeile, List.sort.

[1:05:58] Wäre das in der Realität ein lauffähiges Programm? Ja. Kriegst du dafür Punkte? Nein. Ja, weil das ist nicht die Aufgabenstellung. Du sollst nicht mit möglichst wenig Code mit einer realen Programmiersprache dieses Problem lösen. Das ist nicht das, was du hier zeigen sollst. Du sollst zeigen, dass du das Problem selbst lösen kannst und formulieren kannst, wie man es allgemeingültig lösen kann. Und wenn dazu eine Sortierung gehört, dann wird von dir erwartet, diese Sortierung selber zu coden in Pseudocode und nicht zu sagen, hier nimmst du die Funktion und da nimmst du diese Funktion. Das nehme ich jetzt am Beispiel sortieren, weil das schön nachvollziehbar ist. Das habe ich aber an ganz, ganz vielen Stellen in diesen Sorte-Code-Aufgaben schon gesehen, weil es gibt natürlich in den Programmiersprachen, die wir heute einsetzen, Bibliotheken ohne Ende, die alles das, was du in der IHK-Prüfung brauchst, natürlich für dich machen mit einer Zeile-Code.

[1:06:48] Angenommen, die einzige Aufgabenstellung wäre für sieben Punkte, sortieren Sie diese Liste. Und du schreibst dann einfach hin Array.sort. Ich meine, wenn ich das dann sehe als Prüfling, da muss ich mir doch irgendwie überlegen, kriege ich wirklich für eine Zeile Code sieben Punkte? Kann das wirklich sein? Da muss es doch bei mir klingeln und sagen, okay, die wollen ja doch irgendwie was anderes haben. Das kann doch nicht sein, dass ich hier eine Zeile Code nur schreiben muss. Das ist vielleicht nochmal so ein Hinweis, der dir vielleicht auffallen sollte. Wenn du 25 Punkte für eine Programmieraufgabe kriegst und du löst die mit drei Zeilen, da kann irgendwas nicht stimmen. Das wollen wir dann wohl nicht sehen in dieser Aufgabe. Das heißt, in der Prüfung sollst du die absoluten Basic-Algorithmen sortieren, suchen, filtern, was auch immer. Die sollst du selber programmieren und die halt nicht an ein Framework delegieren. Weil sonst wäre, wenn du das dürftest, wäre ja die Frage, wo hören wir denn da auf?

[1:07:46] Sortieren, okay, wenn das ein Teilalgorithmus ist, ja, gut. Aber angenommen, das, was du da programmieren sollst, das gesamte Problem wäre in deiner Programmiersprache in einer Bibliotheksfunktion verfügbar. Was weiß ich, jetzt ein anderes Beispiel zum Sortieren, weiß ich nicht, die Wurzel ziehen oder sowas aus einer Zahl. Dann kannst du natürlich in Java sowas machen wie math.squareroot. Und dann bist du fertig. Ja, und das kann man jetzt natürlich auf alle möglichen Probleme ausweiten. Wenn jetzt zum Beispiel deine Programmiersprache eine Funktion hat, um einen Haufen Rechnungen nach Rechnungsnummer zu sortieren, dann könntest du diesen Algorithmus ja einfach mit einer Zeile Code in der Prüfung lösen. Aber dann zeigt sich ja wieder, das funktioniert nur in genau deiner Programmiersprache mit genau deinem Framework und deiner Bibliothek. Und das ist wieder etwas, was der Prüfer oder Prüfende nicht nachvollziehen kann, weil das ja wieder super spezifisch für diese eine Sprache ist. Und genau das wollen wir ja gerade nicht. Wir wollen ja was Allgemeingültiges. Ein Algorithmus, den du in jeder beliebigen Programmiersprache umsetzen könntest und eben nicht spezifische Python, Java, C Sharp Features dafür brauchst. Das ist der Hintergrund der Prüfung. Das macht dir bitte immer bewusst. Und deswegen sage ich, sei nicht schlauer als die Prüfenden. Zeig nicht, wie geil du deine Programmiersprache kennst. Das ist nicht gefragt, sondern zeig, dass du das Problem lösen kannst.

[1:09:01] Und anderes Beispiel, wo ich das wirklich schon häufig gesehen habe, das ist jetzt, das ist nur ein Beispiel und nur eine Kleinigkeit, aber es gibt Programmiersprachen, wenn ich zum Beispiel auf das letzte Element einer Liste oder eines Arrays zugreifen möchte, ja, dann kann ich sowas machen wie Array, eckige Klammer auf, minus 1, eckige Klammer zu. Also der Index minus 1 steht dann für das letzte Element des Arrays. In Java zum Beispiel geht das nicht. Da wäre Array minus 1 ein Fehler, weil minus 1 ist kein gültiger Index. Fängt bei 0 an, hört bei Länge minus 1 auf. Geht nicht. Aber es gibt halt Sprachen, die das anbieten. Und es gibt sogar recht viele Sprachen. Ich weiß es nicht auswendig, aber ich glaube Ruby, Python, JavaScript, da kann man es überall machen mit der minus 1. Bitte nicht darauf festnageln. So, und da sind wir jetzt bei einem Problem, weil das ist halt ein Feature, was es in vielen Sprachen gibt, aber eben nicht in allen. Und das erleichtert mir das Leben natürlich ungemein, weil ich kann einfach sagen Array minus 1 statt Array, Klammer auf, Array-Length minus 1. Ja, da muss ich halt weniger schreiben. Da machst du dir das Leben einfacher. Okay. Aber andersherum, wenn ich so eine Programmiersprache noch nie gesehen habe und zum Beispiel nur mit Java arbeite und überhaupt nicht weiß, dass es so etwas gibt.

[1:10:08] Gut, dann kann man sich fragen, müssten die Prüfer und Prüferinnen das nicht wissen? Ja, bla bla bla, andere Diskussionen. Aber wenn ich es nicht weiß und ich kann einfach nicht alles wissen, ganz ehrlich, ja, ich kann nicht alle Features aller Programmiersprachen der Welt kennen, um dann bewerten zu können, ob du es richtig gemacht hast. Das heißt, wenn du so ein kleines Feature benutzen möchtest, frage bitte dich selber dreimal, versteht jemand anders das auch, der vielleicht nicht seit drei Jahren mit meiner Programmiersprache arbeitet? Und da gehören so Kleinigkeiten wie letztes Element des Arrays dazu. Und wenn du keinen Bock hast, das mit Array in Klammern Array Länge minus 1 zu machen, dann schreib doch einfach hin, x gleich letztes Element des Arrays. Das wäre gültiger Observer Code. Ja, es ist nicht notwendig, dass du das mit einer Programmiersprachenähnlichen Syntax machst, sondern du kannst einfach sagen, ich will hier das letzte Element des Arrays haben. Punkt. So, das versteht jeder Prüfende. Dafür brauchst du keine speziellen Python-Kennnisse oder sonst irgendwas. Ja, und das wird auch in Java funktionieren, weil letztes Element des Arrays abfragen, da würde ich dann als Java-Entwickler halt wissen, wie ich das mache und programmiere das halt schnell. Aber das Array in Klammern minus 1, da wüsste ich im Zweifel noch nicht mal, was du überhaupt von mir willst. Und das ist ein Problem, ja? Also sei nicht schlauer als die Prüfenden. Wie soll ich sagen? Delegiere deine eigentliche Programmieraufgabe nicht an

[1:11:23] Bibliotheksfunktionen und verwende keine Schlaumeier-Funktionen in deiner Programmiersprache. Das wäre so kernzusammengefasst meine Empfehlung.

[1:11:32] Genau das Gleiche gilt halt für moderne Programmierwerkzeuge, wie zum Beispiel in Java die Streams oder Link in C-Sharp, hatte ich auch schon mal original die Frage, könnte ich diese Aufgabe hier in der JAK-Führung nicht auch mit einem Link-Statement lösen? Ja, könntest du. Gib dir aber keine Punkte. Weil du sollst ja den Algorithmus formulieren, imperativ, Sequenz, Verzweigung, Wiederholung. Und Streams und Link und ich weiß nicht, wie es in anderen Problemen heißt, also wenn ich diese quasi Art der funktionalen Programmierung habe. Ich kann zum Beispiel listen, filtern und mappen und reducen und so dieses Prinzip. Was in vielen Sprachen inzwischen funktioniert. Aber das ist ja eher eine deklarative Sprache.

[1:12:13] Und das ist ja auch cool, weil ich muss dann ja gar nicht wissen, wie das funktioniert. Und allein schon bei dieser Erklärung sollte dir klar werden, okay, ich muss gar nicht wissen, wie der Stream die Liste filtert, aber ich bin gerade in einer IHK-Prüfung, wo ich genau das zeigen soll, nämlich wie man eine Liste filtert. Dann musst du doch eigentlich auch hier irgendwo es klick machen und sagen, okay, das können die nicht von mir jetzt sehen wollen. Das heißt, wenn da sowas steht wie, sortier aus dieser Liste an Personen nur die männlichen raus, dann kann das nicht eine Zeile Code sein, Punkt Filter, where, Geschlecht gleich M oder so. Das wäre also der deklarative, in Anführungszeichen, wie ein SQL-Ansatz. Da musst du auch nicht wissen, wie die Datenbank das macht. Das macht SQL für dich. Aber hier geht es ja genau darum, zu zeigen, wie die Datenbank es machen würde, wenn du die Datenbank programmieren müsstest. Da kannst du nicht sagen, where, irgendwas, sondern musst du die gute alte Schleife rausholen, du musst die Elemente durchlaufen, du musst das Geschlecht vergleichen. Wenn ja, packst du es in die Liste, ansonsten nicht, und dann gibst du die Liste zurück. Und das ist der Algorithmus, den wir da sehen wollen.

[1:13:13] Also, nicht abstrakt, nicht deklarativ, keine programmierspezifischen Sachen, sondern einfach nur die Basic Sequenz Verzweigung Wiederholung. Das benutzt du in den Aufgaben. Und dann holst du auch das Maximum der Punkte, im besten Fall alle. So, der letzte Punkt, das habe ich jetzt nicht so häufig gesehen, aber das wurde ich auch schon ein paar Mal gefragt. Muss ich hier die perfekt optimierte, performance-optimierte Lösung abgeben? Antwort nein. Warum kam die Frage? Gleiche Aufgabe, die Liste sollte am Ende sortiert werden. Muss ich da jetzt einen QuickSort implementieren? Weil der ist ja viel schneller als ein BubbleSort. Und dann sage ich, sowohl für die Prüfung als auch für die Praxis, Nein, das musst du nicht. Das interessiert kein Mensch, in welchen Sortiergruppen es du da benutzt. Das ist ein Problem, was nur dann ein Problem ist, wenn es sich als Problem in der Realität äußert. Was heißt das?

[1:14:03] Wenn du eine Liste sortierst und in einem Webbrowser ausgeben willst über eine Web-Anwendung und es tatsächlich einen Unterschied macht in der Response-Time deiner Anwendung, ob du ein Quick-Sort oder ein Bubble-Sort nutzt, dann wird das ein Problem für dich.

[1:14:19] In 99,9999999% deiner Poemier-Aufgaben wird das wahrscheinlich niemals ein Problem sein. Du könntest den Sortier-Algorithmus rauf und runter optimieren und ersetzen und hier noch eine Vorschleife kürzen und dies und das kannst du alles machen. Und am Ende hast du dann 3 Millisekunden Laufzeit rausgeholt, weil du deine Vorschleife perfekt optimiert hast. Und dann wird aber das Ergebnis deiner Sortierung über einen schönen REST-Aufruf in den Browser per HTTP übertragen und dann nochmal von JavaScript rausgerendert und mit CSS versehen und bla. Und der ganze Aufruf dauert 10 Sekunden. Aber in deiner Vorschleife hast du 10 Millisekunden eingespart. Herzlichen Glückwunsch. Das nennt man Premature Optimization. Das heißt, du fängst an, deinen Code zu optimieren, obwohl es noch nicht mal ein Problem gibt. Und da kann man als Entwickler Stunden und Tage mit verschwenden, ein Problem zu lösen, was es nicht gibt, nämlich einen zu langsamen Sortieralgorithmus zu optimieren. Und ich behaupte einfach, für diese Anwendung, die wir üblicherweise in der Prüfung und auch in der Praxis, für den Großteil der Zuhörenden hier wird das sicherlich gelten, ist es völlig irrelevant, ob du ein Bubble, einen Quick, einen Insertion oder einen Selection Sort nutzt. Das wird keinerlei Auswirkung haben, weil wenn überhaupt, reden wir hier von Unterschieden im Millisekundenbereich und in den normalen Anwendungen wirst du das niemals merken, ob es drei oder drei zehn Millisekunden gedauert hat. Das ist völlig irrelevant.

[1:15:42] Solltest du zu der ganz besonderen Gruppe von Menschen gehören, die täglich mit drei Milliarden Datensätzen hantieren und die sortieren müssen, dann darfst du dich gerne mit den Vor- und Nachteilen der Sortierallgruppen auseinandersetzen. Ansonsten nimmst du einfach den Bubble Sort und gehst zum nächsten Problem. Und wenn irgendwann deine Anwender sagen, jetzt betreiben wir dieses ERP-System seit zehn Jahren und haben drei Millionen Datensätze in der Datenbank, jetzt wird es ein bisschen langsam. Dann kannst du dann in zehn Jahren den Sortierallgruppen optimieren. Aber nicht heute Stunden reinstecken, um Millisekunden rauszuholen. Das ist nicht nötig. Und vor allem ist es in der Prüfung nicht nötig. Wie gesagt, hier sollst du nur das Problem lösen, sortier die Liste. Und hier ist nicht das Problem, sortier die Liste möglichst schnell, sondern sortier die Liste. Und wenn du das mit einem Bubble Sort, den du auswendig in 10 Sekunden hinschreiben kannst, ich übertreibe jetzt, lösen kannst, dann machst du das. Weil dein Ziel in der Prüfung ist ja, möglichst viele Punkte zu holen und nicht einen Algorithmus auf Papier zu optimieren, den es sowieso nicht gibt, weil es gerade eine Prüfung ist. Das heißt, löst das Problem so einfach wie möglich. Es muss nicht schnell sein, es muss nicht schön sein. Es muss einfach nur funktionieren.

[1:16:51] Also verschwende keine Zeit in der Prüfung mit irgendeiner Optimierung, die nicht notwendig ist. Löse einfach das Problem. Ende.

[1:17:00] So, das war alles, was ich zu Pseudocode-Aufgaben zu sagen habe heute.

[1:17:07] Wir fassen nochmal zusammen. Pseudocode-Aufgaben sollen dein algorithmisches Verständnis zeigen. Das heißt, sei nicht schlauer als die Prüfenden, zerlege das Problem in Teilprobleme, die du dann irgendwann mal mit einer Zeile Code lösen kannst. Guck drauf, wenn es 25 Punkte gibt, dass du auch ein paar mehr Zeilen hast als drei, um auch auf diese Punkte zu kommen. Schreib immer etwas hin, auch wenn du nicht so Ahnung hast, wie das Problem an sich löst. Ein Teilproblem wirst du immer lösen können. Denk dran, dass das von Menschen korrigiert wird, die verstehen müssen, was du dahingeschrieben hast. Benutze keine komischen Sprachfeatures, die nur du kennst oder eine ausgewählte Gruppe an Python-Entwicklerinnen, sondern jeder Mensch, der sich einigermaßen mit Programmierung auskennt, muss das verstehen können. Es gibt keinen Standard-Pseudocode. Du kannst hinschreiben, was du willst. Meine Empfehlung, nimm deine Lieblingsprogrammiersprache. Lass alles Unnötige drumherum weg, wie Klammern und so weiter. Achte aber auf saubere Einrückungen, damit man die Struktur des Codes weiterhin erkennt. Lass alles coole und abstrakte deiner Sprache weg. Reduzier dich auf Sequenz, Verzweigung und Wiederholung. Mach es nicht mit einem Aktivitäts-Zirgramm. Es ist zu aufwendig und schlecht zu korrigieren. Und wie bereitest du dich vor? Üben, üben, üben. Am besten mit alten Prüfungsaufgaben oder mit Online-Plattformen, wo du einfach Algorithmik, kleine Programmieraufgaben, wie zum Beispiel Project Euler, üben kannst. Und hol dir Feedback ein. Im besten Fall von einem Menschen, im zweitbesten Fall von einer KI, die dir sagt, was du besser machen kannst. Und achte auf die üblichen Fehler. Plus, minus eins.

[1:18:31] Zu abstrakt gelöst. Gar nichts hinschreiben geht gar nicht. Immer was hinschreiben.

[1:18:35] Das wäre so kurz gesagt nochmal zusammengefasst die Episode heute.

[1:18:39] Ich hoffe, das hat dir ein bisschen geholfen. Vielleicht hat es dir auch ein bisschen die Angst vor den Aufgaben genommen. Aber im Endeffekt steht und fällt das, glaube ich, alles mit üben, üben, üben. Das heißt, fang nicht erst eine Woche vor der Prüfung an, die Dinger zu üben, sondern am besten, ehrlich gesagt, musst du sowas im ersten Ausbildungsjahr schon anfangen. Damit du bis zur Prüfung genug Zeit hast, das zu wiederholen, zu vertiefen, verschiedene Probleme auch schon mal gesehen hast, vielleicht sogar einen Teil wiedererkennst. Ach, das kann ich so und so machen, das habe ich schon mal gehabt und so weiter.

[1:19:08] Die kannst du sehr gut bearbeiten mit Erfahrung. Und dafür musst du es aber auch mal gemacht haben. Also fang früh genug damit an. Das wäre meine Empfehlung. So, ich hoffe, du kriegst viele Punkte für die Psorocode-Aufgaben in deinen Prüfungen. Egal ob AP1, AP2, FISI, FIAE, ganz egal. Sind alle sehr ähnlich aufgebaut. Und damit wünsche ich dir viel Erfolg für deine Prüfung. Wenn du Feedback für mich hast, lass es mir gerne da als Kommentar unter der Episode. Die Shownotes inklusive Transkription und allem, was dazugehört, findest du natürlich wie immer unter itberufepodcast.de slash 195.

[1:19:42] Und ja, wenn du es noch nicht gemacht hast, darfst du gerne meinen Newsletter abonnieren unter itberufepodcast.de slash Newsletter. Da bekommst du von mir eine Ausbildungsbegleitung über deine drei Ausbildungsjahre. Gilt übrigens auch für Ausbilder und Ausbilderinnen. Die kriegen dann auch immer regelmäßig E-Mails mindestens eine die Woche. Zum Beispiel zur Prüfungsvorbereitung. Das heißt, da solltest du normalerweise, zeitnah vor der Prüfung die Info kriegen, hey, hast du dich schon mal mit Pseudocode beschäftigt, damit du das nicht vergisst. Und das gibt es über die ganzen drei Jahre ungefähr einmal die Woche. Ist immer was dabei. Und ja, völlig kostenfrei. Kannst dich auch jederzeit wieder abmelden, wenn du keine Lust mehr drauf hast. Kannst dich also gern mal darum bemühen. Ja, und letzter Hinweis. Pseudocode ist natürlich eine super stark nachgefragte, Aufgabenvariante bei den Anwendungsentwicklerinnen, weil halt so schwierig und meistens viele Punkte.

[1:20:28] Und falls du dich damit wirklich noch intensiver beschäftigen möchtest und nicht noch andere Möglichkeiten hast, das zu üben, ich habe einen Online-Kurs zur Vorbereitung auf die AP2 für Anwendungsentwicklerinnen. Den findest du unter.

[1:20:43] Dieperfekteihkprüfung.de Das Üfung, bitte mit UE. Und da kannst du dich anmelden, wenn du Interesse hast. Da gibt es Stand heute zur Aufnahme nur ein paar Aufgaben zu Pseudocode, aber ich werde auch im Laufe der Zeit entsprechende Erklärvideos zu Pseudocode-Aufgaben dort hinterlegen, damit du es dir damit auch in Ruhe anschauen kannst. Ja, guck doch mal rein, wenn dich das interessiert und du die AP2 für Anmeldungsentwickler, ich sag’s nochmal ganz deutlich, noch vor dir hast. Ein paar andere Themen haben wir auch schon gemacht. Datenbankmodellierung, SQL natürlich und Testverfahren, Schreibtischtest, sowas, die sind auch schon online. Pseudocode wird auf jeden Fall zeitnah nachgereicht vor der nächsten AP2. Jetzt, wo ich das hier aufnehme, im Mai 2025 ist sie ja gerade erledigt. Aber ich denke mal, bis zur nächsten Winterprüfung wird es auf jeden Fall auch was zum Pseudocode dort geben. Ja, das war der letzte Hinweis und damit sage ich vielen Dank fürs Zuhören heute. Wir hören uns beim nächsten Mal und ja, bis denn. Tschüss.

Ich analysiere die erste AP1-Prüfung nach dem neuen Prüfungskatalog in der einhundertvierundneunzigsten Episode des IT-Berufe-Podcasts.

Inhalt

In dieser Episode des IT-Berufe-Podcasts analysiere ich die erste AP1-Prüfung nach dem neuen Prüfungskatalog, die am 25.03.2025 stattgefunden hat. Mein Ziel ist es, die Inhalte dieser Prüfung zu diskutieren und wertvolles Feedback für die zukünftigen Prüflinge zu geben. Ich beginne mit einem Überblick über die Reaktionen und Ängste, die in der Vorbereitungszeit zirkuliert sind, und stelle klar, dass viele Bedenken unbegründet waren. Die Prüfung selbst war im Großen und Ganzen machbar und entsprach den Vorgaben des neuen Katalogs, ohne unangekündigte Überraschungen.

Ich gehe im Detail auf die einzelnen Themen und Aufgaben ein. Hierzu zählen unter anderem die Nutzwertanalyse, Rechenaufgaben, Hardware-Zuordnungen und Subnetting. Besonders hervorheben möchte ich die Nutzwertanalyse, die auch in dieser Prüfung wieder zahlreiche Punkte eingebracht hat. Es hat sich gezeigt, dass viele Aufgaben, trotz anfänglicher Unsicherheiten, gut zu bewältigen waren. Ich erläutere, dass diese Aufgaben durch logisches Denken und grundlegendes IT-Wissen gelöst werden konnten.

Ein weiterer wichtiger Aspekt war die IT-Sicherheit, die in verschiedenen Aufgabenformaten behandelt wurde. Ich betone die Relevanz der DSGVO in der Datenverarbeitung, insbesondere im Hinblick auf die rechtlichen Vorgaben beim Versand von E-Mails. Auch das Thema KI kam zur Sprache, wobei ich den Prüflingen empfehle, sich mit grundsätzlichen Anwendungsfeldern und ethischen Fragestellungen auseinanderzusetzen.

Ich werfe einen Blick auf den Schreibtischtest, wo die Prüflinge einfache Programmiersprachen und Algorithmen durchgehen mussten. Hier war es entscheidend, den Code Zeile für Zeile zu analysieren und die richtige Auswertung vorzunehmen. Diese Aufgaben sind für viele Prüflinge möglicherweise eine Herausforderung, aber mit den richtigen Vorbereitungsmaterialien sind sie machbar.

Zusätzlich gehe ich auf die Relevanz von Protokollen wie IMAP und POP3 ein und kläre die Unterschiede zwischen diesen wichtigen Technologien. Ich erläutere weiter, dass der von der Prüfung geforderte Wissenstand sowohl spezifisches Detailwissen als auch allgemeines Verständnis für IT-Themen erforderte.

Zusammenfassend lässt sich sagen, dass die AP1 eine faire Prüfung war, die weitestgehend den Erwartungen entsprochen hat. Ich mache den Zuhörern Mut, sich ebenfalls auf die kommenden Prüfungen gut vorzubereiten und die Angebote meiner Website zu nutzen, um stets auf dem neuesten Stand zu bleiben. Die Themen und Inhalte sind aktuell und gewährleisten eine optimale Vorbereitung für die nächsten Prüfungszyklen.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Nutzwertanalyse in der Projektdokumentation
• Subnetting mit IPv4 für Fachinformatiker:innen – IT-Berufe-Podcast bei YouTube
• Datenschutz vs. Datensicherheit vs. Datensicherung – IT-Berufe-Podcast #157
• Kryptographie – Schutzziele und Verschlüsselung – Anwendungsentwickler-Podcast #131
• Kryptographie bzw. Verschlüsselung für IT-Berufe (AP1/AP2) – IT-Berufe-Podcast bei YouTube
• Kryptographie – Hashverfahren und elektronische Signatur – Anwendungsentwickler-Podcast #132
• Der eigene Webserver (Teil 2: Absicherung von SSH) – Anwendungsentwickler-Podcast #89
• Ports und Protokolle (Netzwerkgrundlagen) – Anwendungsentwickler-Podcast #141
• Normalisierung – Häufige Fragen im Fachgespräch – Anwendungsentwickler-Podcast #18

Transkription der gesamten Episode

[0:05] Einführung in die AP1 2025

[0:00] Herzlich willkommen zum IT-Berufe-Podcast, dem Podcast rund um die Ausbildung in den IT-Berufen. In dieser Episode gibt es einen Rückblick auf die AP1 im Frühjahr 2025 nach neuem Prüfungskatalog. Viel Spaß!

[0:13] Hallo und herzlich willkommen zur 194. Episode des IT-Berufe-Podcasts. Mein Name ist Stefan Macke und heute gibt es mal eine zeitnahe Episode im Gegensatz zu den sonstigen, eigentlich eher zeitlosen Episoden. Letzte Woche ging es ja hier noch um Miete, Leasing und Kauf. Das ist ja fast schon seit 100 Jahren zeitlos. Aber heute mal eine ganz aktuelle Episode, denn genau heute, wenn ich diesen Podcast auch veröffentliche, am 25.03.2025 wurde die erste AP1 nach neuem Prüfungskatalog geschrieben. Und dazu hatte ich ja vor ein paar Wochen schon mal ein paar Episoden, ich glaube zwei, aufgenommen zu AP1 und 2. Und auch meine Website, da gibt es jetzt ja einen neuen Bereich, wo die ganzen letzten Prüfungsthemen drinstehen und so weiter und so fort. Prüfungskatalog neu, meine Themenliste neu und so. Und ich habe ja auch noch in den letzten Wochen einen Prüfungsvorbereitungskurs gemacht mit mehreren Teilnehmenden rund um die AP1. Und da dachte ich mir, okay, das lohnt sich, dass wir vielleicht mal einmal

[1:10] Rückblick auf Prüfungsinhalte

[1:06] in der Rückschau auf diese besondere neue Prüfung draufschauen. Wobei so viel besonders ist sie gar nicht. Ich spoiler das schon mal. Die Themen waren jetzt keine Riesenüberraschung. Und es wurde auch nicht hintenrum doch nur was untergejubelt, was laut Katalog nicht mehr vorkommen durfte oder so. Also das war alles relativ human. Aber wenn natürlich im Vorfeld viele durchgedreht sind. Und oh mein Gott, ich werde die IHK verklagen. Ja, das hört man sonst eigentlich immer nur nach den Prüfungen. Jetzt gab es das auch schon vor den Prüfungen, weil dieser Prüfungskatalog ja verändert wurde und so.

[1:36] Und ja, ist natürlich alles nicht ganz so sinnvoll. Aber wie dem auch sei, es gilt der neue Prüfungskatalog. Und es hat sich auch gezeigt in dieser Prüfung, dass er tatsächlich galt und nicht, wie einige schon meinten. Also ich weiß ja nicht mehr, wo sowas herkommt dann. Aber diese Verschwörungsmythen rund um die Prüfung, das ist echt der Wahnsinn. Ja, ich habe aus internen Quellen gehört, dass die Prüfungen eigentlich schon zwei Jahre vor dem Termin feststehen und deswegen werden ja wahrscheinlich auch noch Themen drankommen, die laut neuem Prüfungskatalog gar nicht drankommen und da wurden irgendwelche Fristen versäumt und in Wirklichkeit sind das ganz andere Themen und kurz zusammengefasst, muss ich das alles noch lernen oder nicht? Und also es gibt da ja wirklich die wildesten Geschichten im Chat, auf den Websites und so weiter. Es ist wirklich verrückt. Also ich würde für die Zukunft, und das ist glaube ich so das Learning aus dieser Prüfung, mal einfach davon ausgehen, wenn auf einer offiziellen Website, nämlich namentlich dem IAKAKA steht, die nächste Prüfung ist nach diesem Prüfungskatalog zu schreiben.

[2:31] Dann darf man davon ausgehen, dass das auch stimmt. Ja, das heißt, anstatt sich stundenlang im Internet wütend zu reden oder zu schreiben, ob das denn alles überhaupt sein kann, einfach mal die Fakten akzeptieren und sich auf die Prüfung vorbereiten und fertig. Und ehrlich gesagt, ich glaube, das ist meine persönliche Vermutung. Ich kann natürlich nicht für alle Prüflinge sprechen, die die Prüfung geschrieben haben, aber wenn man sich die Prüfung im Detail anguckt… Könnte ich mir vorstellen, dass die meisten Prüflinge eher erleichtert waren und da jetzt nicht solche Hardcore-Hammer-Themen drin waren, dass alle sagen, oh mein Gott, es war die schwerste Prüfung ever. Im Gegenteil, ich habe jetzt schon von einigen Seiten gehört, dass es sogar fast mit eine der leichtesten Prüfungen der letzten Jahre war. Aber die Einschätzung ist immer subjektiv, da will ich auch gar nichts zu sagen. Vor allem, wenn man die Prüfung selber schreibt, da kann man immer schlau schnacken. Alle fanden die einfach, ja, aber ich saß da und musste die schreiben und für mich war es halt trotzdem schwierig so.

[3:19] Also von daher, solche subjektiven Sachen, da kann ich wenig zu sagen. Aber ich aus Prüfersicht würde auch die Aufgaben so einschätzen,

[3:29] Feedback zur Prüfungsstruktur

[3:26] dass sie alle machbar waren. Sie waren alle vom Prüfungskatalog abgedeckt. Übrigens auch vom alten Prüfungskatalog. Also es sind jetzt keine neuen Themen drin gewesen, die nicht schon seit Jahren hätten abgefragt werden können. Das mal kurz vorweg.

[3:37] Genau, aber es ist zumindest nicht so passiert, dass Sachen, die offiziell gestrichen wurden, sogar in der Einleitung des Prüfungskatalogs, zum Beispiel SQL und RAID, ist halt jetzt einfach in die API 2 verschoben worden. Und dazu kam auch nichts mehr dran. Dafür wurde halt sowas wie KI durchaus mit mehreren Punkten auch abgefragt. Ich glaube, es waren drei oder vier Teilaufgaben, insgesamt zwölf Punkte. Durchaus ein großer Anteil an so einer Prüfung. Allerdings noch getoppt vom Schreibtischtest. Ich glaube, den hatten jetzt nicht so viele so auf dem Zettel, vor allem, dass es dafür so viele Punkte gab, nämlich 14 Punkte. Es waren zwei Teilaufgaben. Ich glaube, wenn ich es richtig überblickt habe, war das der Themenbereich, der am meisten Punkte diese Prüfung gab. 14 Punkte Schreibtischtest. Wobei, Schreibtischtest war ja auch immer so das große Unbekannte. Oh mein Gott, was kommt da dran? Letztlich ist es genauso gekommen, wie ich es auch schon immer vermutet habe. Und ich glaube auch an mehreren Stellen im Kurs zumindest auch immer gesagt habe, Es gibt ein Stückchen Code, spielt den mit Eingaben durch und schreibt auf, was rauskommt. Und genau so war es auch. Also dafür muss man jetzt nicht großartig programmieren können. Und wenn man sich den Code anguckt, da ist gut, es sind ein paar verschachtelte If-Statements gewesen im zweiten Code. Aber das ist jetzt nicht so super schwierig, dass man den Algorithmus erstmal eine halbe Stunde verstehen muss. Also naja, nun, ich greife etwas vorweg.

[4:42] Warum mache ich das heute hier? Also ich möchte einfach so ein bisschen allgemeines Feedback nochmal zur Prüfung geben. Und es war ein einziges Thema dabei, was ich noch nicht auf meiner Themenliste explizit stehen habe und was ich auch nach Suche im Prüfungskatalog so nicht explizit gefunden habe. Und ich glaube, dafür gab es aber nur zwei Punkte oder drei. Und zwar das Thema Redundanz. Keine Angst, habe ich natürlich auf meiner Liste für die nächste AP1 schon ergänzt. Und übrigens, ich habe auch die Prüfung schon in meiner Themen der letzten IHK-Prüfungenseite aktualisiert. Das heißt, mit Punkteauswertung, wofür gab es welche Punkte und so, ist alles schon drin in der Liste, in der Datenbank. Das heißt unter itberufe-podcast.de slash Themen IHK. Es ist, glaube ich, mit großem T und großem IHK.

[5:22] Ansonsten, wie immer im Menü verlinkt, habe ich jetzt ja schon zahlreiche Visuen zugemacht. Da ist das schon mit eingebunden, die heutige Prüfung. Da sieht man auch noch mal grob, welche Themen heute dran kamen. Und ich würde einfach mal kurz ein paar Themen überfliegen und kurz mein Feedback dazu abgeben, was ich glaube, was vielleicht Probleme waren oder nochmal einfach kurz das Thema erklären, weil ich es bislang noch an keiner Stelle erwähnt habe. So, das war eigentlich mein Ziel für heute. Und was ich auch schon mal vorbereitet habe, kannst du in den Shownotes zu dieser Episode natürlich anschauen. Zum Großteil der Themen würde ich inzwischen schon sagen, obwohl ich die Punkte jetzt nicht gezählt habe, aber ich würde sagen, für die meisten Aufgaben habe ich tatsächlich schon passendes Lernmaterial online. schon teilweise seit Jahren, sei es eine Podcast-Episode oder ein YouTube-Video. Und ich habe mal einige auch in den Shownotes hier verlinkt, um das zu beweisen, in Anführungszeichen, dass das, was ich da die ganze Zeit mache, eigentlich auch tatsächlich prüfungsrelevant ist. Überraschung. Ich denke mir das nicht einfach aus, dass zum Beispiel Kryptografie und Verschlüsselung in so einer Prüfung drankommen kann. Die kam nämlich zufällig dran.

[6:18] So, das heißt, meine Website ist aktuell, Themenliste ist aktuell,

[6:23] Themenübersicht der AP1

[6:21] für die nächste API 1 ist alles aktuell, Punkte sind aktuell. Also ich habe meine Website aktualisiert und jetzt würden wir einfach mal von vorn bis hinten so ein bisschen die Prüfung durchgehen. Nein, keine Angst, ich gehe nicht jede Berechnung durch und erzähle, wo was genau rauskommt. Das ist ja wirklich völlig überflüssig. Sobald die Lösungen irgendwo verfügbar sind, ist diese Podcast Episode überflüssig. Also das will ich nicht machen. Sondern ich gehe einzelne Sachen durch und erkläre vielleicht nochmal kurz den Hintergrund. Wenn man jetzt heute geschrieben hat, dass man nochmal weiß, was man vielleicht hätte schreiben sollen. Aber ich gehe jetzt nicht jede Berechnung durch und sage, wo man 3% oder 4% hätte rechnen sollen. Also so genau will ich es nicht machen. Sondern es soll so ein bisschen Überflug über die Themen sein und ein kurzer Recap und ich hoffe mit ein bisschen Lessons Learn für die nächste API 1, für alle, die das noch vorhaben, damit man wenigstens auch in einem Jahr noch ein bisschen was mit dieser Episode anfangen kann. Das ist mein Ziel für heute. Mal gucken, wie gut das klappt. Ich würde sagen, wir legen los.

[7:09] Klassische Nutzwertanalyse

[7:10] So, dann starten wir doch einfach mit der ersten Aufgabe und das war so eine ganz klassische Nutzwertanalyse. Eigentlich war es keine Nutzwertanalyse, es war noch weniger als eine Nutzwertanalyse. Es war, wie heißt das Ding hier, Bewertungs- oder Entscheidungsmatrix. Aber es hatte einen ganz klaren Anschein an der Nutzwertanalyse. Deswegen habe ich das in meiner Themenliste und was gab, wie viele Punkte auch direkt unter Nutzwertanalyse zusammengefasst. Und das untermauert nochmal die Vormachtstellung der Nutzwertanalyse als Punktegeber Nummer 1 in den bisherigen AP1. Denn ja, der Abstand ist jetzt noch ein bisschen gewachsen. Also auf Platz 1 der Themen mit den meisten Punkten der AP1 bleibt die Nutzwertanalyse, weil ich diese Aufgabe dazu zähle. In diesem Fall ging es tatsächlich nicht darum, bestehende Zahlen einfach einzutragen, sondern selber auf Basis von Vorgaben, zum Beispiel, ich glaube es ging hier um Multifunktionsgeräte, um einen Drucker.

[7:58] Wenn da steht, wie schnell der druckt, wie viele Seiten, die Minuten und so weiter, dann drei verschiedene Geräte zu vergleichen und dem besten Gerät drei Punkte zu geben und dem schlechtesten eins oder irgendwie so etwas. Also es war quasi das Füllen der Nutzerwirtanalyse. Habe ich es so als Aufgabenstellung auch noch nicht gesehen. Ich meine, das war jetzt nicht großartig schwierig. Man musste gucken, wer hat die meisten Seite, die Minute und der kriegt dann die meisten Punkte und wer weniger hat, kriegt weniger. Also das war jetzt, ich bin jetzt mal, das hört sich immer blöd an, aus Prüfersicht kann man immer viel schnacken, aber ich finde, das waren absolut geschenkte Punkte, ganz ehrlich. Da muss man ja im Prinzip nichts mit IT wissen, sondern ich gucke mir einfach an, hier ist mal ganz blöd gesagt, was ist die größte Zahl oder was ist die kleinste Zahl in der Tabelle? Und dafür gebe ich dann entweder ein, zwei oder drei Punkte in der anderen Tabelle, wo ich sie eintragen muss. Und das aus meiner Sicht absolut geschenkte Punkte.

[8:45] Aber nichtsdestotrotz, Nutzwertanalyse bleibt auf Platz 1. Und dazu habe ich natürlich schon vor Jahren ein Blogartikel geschrieben, wie man die denn eigentlich richtig ausfüllt, die Nutzwertanalyse. da sie ja auch in Abschlussprojekten der IT-Berufe immer gern genutzt wird, gern mal reinschauen. Genau, ansonsten ging es weiter mit ein bisschen Rechenaufgaben und die überspringe ich jetzt tatsächlich komplett. Also ich werde jetzt hier nicht vorrechnen,

[9:06] Rechenaufgaben und Mathematik

[9:04] 10 Euro plus 11 Euro geteilt durch irgendwas. Das finde ich maximal sinnfrei für so einen Podcast, deswegen überspringe ich die nächste Aufgabe. Aber im Prinzip war es Basic Mathematik. Wie viele Seiten pro Monat mal Anzahl Tage mal Kosten und es war ein bisschen Multiplikation und dann summieren und das war’s. So, dann ging es in den Bereich Hardware, Es gab aber nur wenig Punkte, ehrlich gesagt. Und zwar sollte man Anschlüsse zuordnen. Und tatsächlich auch ein paar Anschlüsse, die vorher zumindest noch nicht in der Prüfung dran waren. Zum Beispiel so ein guter alter Stromanschluss. Und ehrlich gesagt, ich wusste nicht, wie der heißt. Tatsächlich, da habe ich auch was dazu gelernt. Der heißt wohl Kaltgerätebuchse. Habe ich noch nie gehört. Aber durch Ausschlussverfahren hätte man die anderen, da war dann sowas offensichtliches wie USB-C und RJ45 dabei, hätte man durch Ausschlussverfahren darauf kommen können, dass das Ding so heißt.

[9:50] Und da gab es noch zwei kleine Symbole, Wi-Fi-Symbol und Bluetooth und man sollte einfach daneben schreiben, wie die heißen. Also auch aus das, ja, wie soll ich sagen, geschenkte Punkt, wenn man es noch nicht gesehen hat, halt schwierig, aber ich würde behaupten, diese Anschlüsse sind im Alltag einfach auch so präsent und die Symbole vor allem auch. Also ich glaube, so ein WLAN-Symbol, das wird sogar meine Oma erkennen quasi und die hat nicht mal ein Handy. Also das ist ja so prominent, dafür muss man keine IT-Ausbildung machen. Und die anderen, gut, die sind dann halt eher etwas technischer. Aber USB-C, USB-A, glaube ich, hat, glaube ich, auch schon jeder Mensch inzwischen mal irgendwo in der Hand gehabt.

[10:23] Subnetting und IP-Adressen

[10:20] Zumindest, der mal einen Computer hatte. Deswegen so schwer war das jetzt nicht. So, und dann kommen wir zu einem meiner Lieblingsthemen, und zwar Subnetting. Eigentlich gab es da nur zwei Punkte für. Und ich finde ja manchmal einfach das Verhältnis von Text, was man lesen muss, um dann zwei Punkte zu bekommen, echt Wahnsinn. Und hier ist es auch so, es gibt ein Schaubild mit IP-Adressen und dann ist da was erklärt und so. Und am Ende gibt es dafür dann zwei Punkte, dass ich dann eine IP-Adresse eintrage. Also, das ist manchmal vom Verhältnis, ich glaube, in der Aufgabe davor, wo ich die Anschlüsse zuordnen musste, habe ich für jedes Wort auch einen Punkt gekriegt. Und hier muss ich erstmal eine halbe Seite Text lesen, um dann zwei Punkte zu kriegen. Also, das ist manchmal ja echt verrückt, was so Kosten-Nutzen-Effekt bei den Aufgaben ist. Und mit Kosten meine ich Lesezeit und Nutzen, die Punkte, die ich kriege.

[10:59] Naja, auf jeden Fall habe ich das Subnetting zugeordnet, weil es ging darum, einer Arbeitsstation, glaube ich, eine IP-Adresse zu vergeben. Und dazu muss man wissen, welche denn überhaupt erlaubt sind. Und dann stand einfach, geben Sie die letzte freie IP-Adresse. Aber ach nee, doch nicht. Die letzte wurde noch irgendwie für ein Gateway oder sowas benutzt. Das heißt, das Thema ist schon Subnetting, weil es war ein IP-Bereich mit Subnet-Maske angegeben. Und als erstes hätte man jetzt ausrechnen müssen, was ist denn überhaupt der frei vergebbare IP-Bereich? und das war eine Slash-26er-Maske. Das jetzt auf der Tonspur zu erklären, ist nicht so gut nachvollziehbar, deswegen spare ich mir das, aber das Vorgehen wäre gewesen. Subnet-Maske anwenden, in welchem Subnet sind wir und was ist die höchste und die niedrigste IP-Adresse und dann schauen wir uns an, was ist die Broadcast- und die Netzadresse. Das wissen wir hoffentlich noch aus IPv4 und zwar ist immer die geringste, die kleinste Adresse, also alle Bits auf 0, die Netzadresse und die, wo alle bis auf 1 sind, ist die Broadcast-Adresse. Die darf natürlich nicht vergeben werden beide.

[11:57] Deswegen nehmen wir dann quasi zwei weniger von den IP-Adressen, die wir vergeben können. Und jetzt war es hier so, dass davon die letzte Adresse schon vergeben war für ein Gateway. Das heißt, man hätte noch einen abziehen müssen. Und somit war das dann die vorletzte IP-Adresse. Und das hätte man jetzt einfach ausrechnen können. Zwei abziehen und dann wäre es das gewesen. Dafür musste ich aber das Hintergrundwissen haben, dass es eine Broadcast- und Netzadresse überhaupt gibt und dass die letzte Adresse dann halt schon minus 1 ist und ich deswegen minus 2 rechnen muss. Das heißt, ich zähle das ganz klar zu Subnetting, denn ohne dieses Hintergrundwissen hätte ich das nicht richtig beantworten können.

[12:31] IT-Security und Datenschutz

[12:31] So, dann nächster Punkt, da ging es um IT-Security, aber ich habe das bei meinem Stichwort unter Englisch zusammengefasst, weil es ist einfach ein englischer Text und man sollte ein paar Sachen da raussuchen. Also dafür muss ich ehrlich gesagt keine Ahnung von IT-Security haben. Ich konnte es einfach übersetzen und aufschreiben. Gut, dann vielleicht eine ganz interessante Frage, wie es ist, warum man Endbenutzern auf dem Rechner keine Admin-Rechte geben sollte. Das finde ich eigentlich ganz cool, habe ich so in Prüfung auch noch nicht gesehen. Selbst wenn man jetzt keinen Hintergrundwissen hätte, kann man sich überlegen, warum das nicht sinnvoll ist. Und Antwort ganz kurz und knapp, wenn ich mir eine Schadsoftware einfange, dann arbeite ich natürlich mit meinen Benutzerrechten. Und wenn ich Admin-Rechte habe, ja, dann kann diese Schadsoftware natürlich auf dem Rechner machen, was sie will. Kann alles löschen, umbenennen, Benutzer anlegen, sperren, was auch immer. Das heißt, Schadsoftware arbeitet immer in dem Kontext des Benutzers, der die Schadsoftware startet. Und wenn der Admin-Rechte hat, hat die Schadsoftware auch Admin-Rechte. Deswegen keine gute Idee, damit zu arbeiten. Joa, dann kommen wir schon zum zweiten Handlungsschritt, zur zweiten Aufgabe.

[13:28] Public Key Infrastructure

[13:26] Heißt das ja, ich habe im Kopf immer noch Handlungsschritte, weil das früher so hieß. Und hier ging es jetzt so ein bisschen um Security. Und dazu tatsächlich genau zu diesem Kram, was da abgefragt wurde, hatte ich ja schon vor Jahren auf jeden Fall. Nicht nur Podcast-Episoden, sondern auch noch inzwischen YouTube-Videos online, die das genau erklären mit PKI, also Public Key Infrastructure, also asymmetrische Verschlüsselung. Darum geht es.

[13:47] Was passiert oder wie kriege ich es hin, dass ich eine E-Mail an einen, in diesem Fall Geschäftspartner oder Mandanten, es ging hier irgendwie um Anwälte, die mit ihren Mandanten kommunizieren, wie kriege ich es hin, die E-Mail dahin zu verschlüsseln? Und dazu muss ich wissen, dass es zwei Schlüsselpaare gibt, mit welchen wird was verschlüsselt, wer schickt wo was hin. Also genau die Inhalte meines Erklärvideos habe ich natürlich in den Show Notes verlinkt. Übrigens, die findest du unter itberufe-podcast.de slash 194 für die heutige 194. Episode. So, einleitend in diesen Handlungsschritt ging es aber darum, folgendes Szenario, Rechtsanwalt und Mandant möchten gerne E-Mails austauschen. Gibt es dafür besondere Vorgaben rechtlicher Art? Also muss man irgendwas einhalten? Und die Antwort war, wie so oft bei solchen Fragen, Datenschutz. Das heißt, die rechtliche Grundlage ist natürlich die DSGVO. Und da werden natürlich besonders schützenswerte Daten definiert und sowas wie Mandantenverhältnis bei einem Rechtsanwalt zählt natürlich darunter. Da geht es nicht nur um die personenbezogene Daten der Mandanten, sondern natürlich auch, wenn es zum Beispiel um Straftaten geht oder so, natürlich extrem schützenswerte Daten. Das darf natürlich niemand anderes mitbekommen. Und deswegen, grundlage, rechtliche Grundlage ist DSGVO. Und dann war noch die Frage, was ist denn eigentlich der Zweck der DSGVO? Und ja, da geht es natürlich darum, personenbezogene Daten vor dem Missbrauch von Dritten zu schützen, wie in meiner Podcast-Episode zum Thema Datenschutz vor Jahren schon erklärt. Also auch hier wieder zeitloser Content, der immer mal wieder in der Prüfung rankommen kann. Sehr gut.

[15:08] So, dann hatten wir die Geschichte mit dem, also kurz um es zu erklären, der Anwalt soll jetzt dem Mandanten eine E-Mail schicken, wie kriegt er es hin und dass die verschlüsselt ankommt. Dazu muss erstmal der Mandant tätig werden und ein Public und Private Key Paar generieren und dann muss er seinen öffentlichen Schlüssel dem Anwalt zuschicken, damit der den hat. Das heißt, wenn ich dem Mandanten was schicken will, muss als erstes der Mandant etwas tun. Der muss mir nämlich seinen öffentlichen Schlüssel schicken. Und mit diesem Schlüssel kann ich dann die E-Mail in diesem Fall verschlüsseln. Und dann schicke ich die raus. Und dann ist ja durch Private Key Pair gewährleistet, dass diese E-Mail nur mit dem privaten Schlüssel des Mandanten wieder entschlüsselt werden kann. Und damit ist die Vertraulichkeit gewährleistet, weil nur der Mandant, der seinen privaten Schlüssel, den er natürlich nie, nie, nie aus der Hand gibt, damit diese E-Mail wieder entschlüsseln kann und nur er die lesen kann. Das ist so grob der Ablauf gewesen. Also Mandant sendet seinen öffentlichen, nicht privaten, öffentlichen Schlüssel rüber. Der Anwalt verschlüsselt die Mail damit, sendet die E-Mail rüber und der Mandant entschlüsselt mit seinem privaten Schlüssel. Und fertig. Und dann haben wir den Bezug zu den Schutzzielen der IT-Sicherheit hinbekommen. Alles natürlich in meinem Podcast zum Thema Datenschutz, Datensicherheit und Datensicherung erklärt. Und da gibt es die Schutzziele. Und was ist damit erreicht worden? Die Vertraulichkeit. Das ist das Schutzeil, was erreicht wird, denn nur der Mandant kann die E-Mail lesen. Das ist vertraulich. Und jetzt war noch die Frage ganz allgemein. Was sind Vor- und Nachteile der asymmetrischen und symmetrischen Verschlüsselung? Auch das habe ich natürlich alles schon mal erklärt, sogar im YouTube-Video.

[16:35] Und Vorteil der symmetrischen Verschlüsselung erstmal ist, dass sie grundsätzlich ein bisschen schneller ist, weil die Schlüssel nicht so lang sind. Die sind ja komplett geheim. Bei der symmetrischen Verschlüsselung gibt es nur einen einzigen Schlüssel, der beiden Seiten bekannt gemacht werden muss. Und da er wirklich komplett geheim ist, kann er kürzer sein. Also bei der asymmetrischen, denn dort wird eben mit privatem und öffentlichen Schlüssel gearbeitet, also mit einem Schlüsselpaar. Der Vorteil bei der asymmetrischen Verschlüsselung ist, dass ich diesen Public Key, den öffentlichen Schlüssel, halt durch die Gegend schicken kann und jeder den einsehen darf. Das heißt, der Schlüsselaustausch ist extrem einfach. Ich muss nämlich einfach nur den Schlüssel hinschicken und bin fertig. Das kann ich beim symmetrischen Verfahren nicht, weil dann hat jeder andere ja auch den Schlüssel und kann alles wieder entschlüsseln. Ja, also grundsätzlich wollen wir gerne symmetrisch verschlüsseln, weil das schneller ist, Aber der Schlüsselaustausch ist ein Problem und deswegen nutzen wir die asymmetrische Verschlüsselung, um einen symmetrischen Schlüssel auszutauschen. Das ist eigentlich die Idee, zum Beispiel bei HTTPS. In diesem Beispiel mit den E-Mails sparen wir uns jetzt den symmetrischen Schlüssel, sondern nehmen einfach den öffentlichen des Mandanten und dann ist da sichergestellt,

[17:37] Vor- und Nachteile der Verschlüsselung

[17:34] dass nur er das mit seinem privaten Schlüssel entschlüsseln kann und lesen kann. Das heißt, Vertraulichkeit wird auch da ausschließlich über das asymmetrische Verfahren gewährleistet. Aber hier ging es ja darum, ganz allgemein Vor- und Nachteile aufzuzeigen.

[17:47] So, dann kam noch was dran, was ich wirklich rein zufällig gestern Abend vor der Prüfung noch mit einem meiner Azubis durchgeführt habe, und zwar Open Source Software und proprietäre Software. Ach, herrlich, ich liebe es, wenn Sachen, die wir für die Prüfung lernen, auch in der Prüfung drankommen, das mag ich richtig gern. Und da ist jetzt die Frage, zwei Vor- und Nachteile dieser beiden Lizenzmodelle, also Open Source und Proprietär. Open Source heißt ja im Prinzip vom Wortsinn schon, der Source, der Quelltext der Software ist offen. Das heißt, ich kann da reinschauen, ich kann den gegebenenfalls auch anpassen, erweitern, korrigieren, wenn er fehlerhaft ist und vor allem verstehen. Und meistens bedeutet das auch, dass ich die Open-Source-Software kostenfrei nutzen kann. Das ist zumindest bei vielen Open-Source-Produkten so. Im engeren Sinne eigentlich nicht, weil es geht noch um die Lizenzen, die noch dahinter hängen. Aber Open-Source geht man erstmal davon aus, dass sie auch kostenfrei nutzbar ist. Während proprietäre Software von einem Hersteller kommt, der seine Spezifikationen zum Beispiel auch nicht offenlegt, der hat sich da einfach was Tolles ausgedacht und sagt es keinem weiter, wie es funktioniert.

[18:43] Dafür liefert er uns aber auch, natürlich gegen Zahlung von Lizenzgebühren, gegen Geld, Zum Beispiel Support dafür. Das heißt, als Beispiel, ich habe irgendein proprietäres Windows-Programm entwickelt, dann würde ich von diesem Hersteller dafür auch Support bekommen, weil ich kann es ja nicht selber heile machen, wenn es kaputt ist. Ich kann ja nicht in den Code gucken. Das heißt, ich kriege natürlich ein bisschen eine bessere Dienstleistung, sage ich mal. Ich muss mich auch nicht mit dem Source beschäftigen, wenn ich zum Beispiel kein Entwickler, keine Entwicklerin bin. Das heißt, ich habe es ein bisschen einfacher, aber das bezahle ich halt mit Lizenzgebühren. Also hat beides Vor- und Nachteile, haben wir jetzt ein paar genannt.

[19:13] Open Source vs. Proprietäre Software

[19:14] So, dann nochmal weiterhin zu IT-Security. Also das ist alles noch zum Thema

[19:20] Hash-Verfahren und Datenintegrität

[19:18] IT-Security, wobei die Lizenzen eigentlich nicht. Aber jetzt kommen wir nochmal zurück zur Security und zwar zum Hash-Verfahren. Es sollte erklärt werden, warum zum Beispiel auf einer Website, wenn ich da eine Datei runterlade und daneben steht der Hash dieser Datei, wobei mir das hilft oder warum die das auf die Website schreiben.

[19:33] Und die Idee ist, ein Hash-Verfahren ist ja eine mathematische Einwegfunktion, wo ich Daten beliebiger Länge reingeben kann und bekomme dann einen Hash-Wert fixer Länge wieder raus, der so eine Art Fingerabdruck dieser Daten ist. Und wenn sich jetzt eine Kleinigkeit an den Eingangsdaten ändert, ändert sich der Hash-Wert sehr deutlich, sodass ich quasi Veränderungen an den Daten sehr schnell und einfach erkennen kann, ohne die ganze Datei Bit für Bit vergleichen zu müssen, erst mal ganz blöd gesagt. Und genau darum geht es jetzt hier. Wenn ich mir so eine schöne Exe-Datei aus dem Internet runterlade und irgendwer hat da ein Virus dran geflanscht, dann wäre es halt ganz cool, wenn ich das möglichst schnell mitbekäme, dass da ein Virus da dran ist. und dafür könnte ich so ein Hash-Verfahren benutzen. Das heißt, ich nehme die unveränderte Datei und hashe die und merke mir diesen Hash und wenn ich jetzt eine Datei aus dem Internet runterlade, dann kann ich darüber wieder die Hash-Summe oder den Hash-Wert ermitteln und das dann mit dem bestehenden vorgegebenen Hash-Wert vergleichen. Und wenn der Hash-Wert sich verändert hat, weiß ich, oh, die Datei wurde verändert. Das muss ja gar nicht böse Absicht sein, da muss ja kein Virus drin sein. Kann ja auch sein, dass beim Download irgendwie ein bisschen was verloren gegangen ist und deswegen die Datei jetzt kaputt ist. Das kriege ich halt schnell raus, wenn ich das mit den Hashes mache, anstatt die beiden vielleicht auch sehr großen Dateien Bit für Bit vergleichen zu müssen. Wenn wir nochmal den, das steht jetzt nicht in der Prüfung, aber wenn wir nochmal den Rückschluss auf die Schutzziele ziehen, dann wäre ein Hash-Verfahren dafür da, die Integrität der Daten zu wahren. Wurde etwas an der Datei manipuliert, dann wäre die Datei nicht mehr integer und das würde man darüber dann herausbekommen.

[20:58] So, dann eine, ich glaube, eine meiner Lieblingsfragen in dieser Prüfung und zwar Unterschied zwischen IMAP und POP3, beziehungsweise es war eigentlich gar kein Unterschied, sondern der Anwalt möchte irgendwie auf E-Mails zugreifen oder irgendwie was und dann soll man sich entscheiden, entweder IMAP oder POP3 und es war schon vorgegeben, dass IMAP benutzt wird, man sollte bloß erklären, warum. Und es haben ja immer viele, auch vor der Prüfung gesagt, auch in meinem Prüfungsvorbereitungsgurs, ach, diese ganzen Protokolle und Ports und bla, die braucht man doch eigentlich gar nicht und jetzt ist hier der Beweis, dass man es doch mal brauchen kann. Zumindest sollte man wissen, was der Unterschied ist zwischen IMAP und POP3 und zu den Ports gleich auch nochmal, weil es gibt gleich noch eine Aufgabe, wo man dann auch einen Port angeben musste. Also zum Thema Netzwerk, Ports und Protokolle auf jeden Fall angucken, auch für die nächste API1. Und kurzer Spoiler, was ist da der Unterschied zwischen IMAP und POP3? Beide sind Protokolle zum E-Mail-Lesen. Es gibt noch ein drittes E-Mail-Protokoll und zwar SMTP, Simple Mail Transfer Protocol und das ist zum E-Mail-Versenden. Das heißt, wenn ich irgendwo von meinem Server eine E-Mail an einen anderen schicken will oder von meinem Client an meinen E-Mail-Server, dann nutze ich SMTP.

[21:59] Aber wenn ich E-Mails lesen will, also die, die ich bekommen habe in meinem E-Mail-Client, zum Beispiel Outlook oder Thunderbird oder so,

[22:09] E-Mail-Protokolle: IMAP und POP3

[22:06] dann wird dafür IMAP oder POP3 benutzt. Das ist quasi die Gegenrichtung. Und ich finde, dass man diese Abkürzung der Protokolle sehr gut auswendig lernen sollte und muss, weil in diesem Fall sagen sie tatsächlich exakt genau, wie die Protokolle funktionieren. POP3 steht für Post Office Protocol und IMAP steht für Internet Message Access Protocol und die sagen eins zu eins, was das ist. Denn POP Post Office Protocol, da verhält sich das Protokoll wie bei einem Postbüro, Post Office. Ich weiß nicht, wann du zuletzt mal wirklich einen echten Brief oder ein Paket bei der Post abgegeben hast, aber wenn du, also hier geht es ja noch nicht mal darum, was abzugeben, sondern das wäre ja SMTP, sondern du holst was von der Post. Also stellst dir vor, jemand hat den Brief geschickt und die stellen dir das nicht in deinen Briefkasten zu, sondern legen das am Postschalter ab, damit du das da abholst. Ich weiß, es ist ein bisschen länger her, dass die Post so funktioniert hat. Heutzutage landet das einfach im Briefkasten. Aber wenn das so wäre, würdest du zum Postschalter gehen, holst dir den Brief und danach hast du dann den Brief und die Post nicht mehr. Überraschung, weil du hast ihn ja abgeholt. Aber genauso funktioniert auch das POP-Protokoll, denn die E-Mails, die du mit POP3 abholst, liegen danach nicht mehr auf dem Server, sondern nur noch auf deinem Client.

[23:16] Bedeutet, wenn du jetzt mit einem zweiten Client zum Beispiel auf den gleichen Postkorb zugreifst, dann ist die E-Mail da nicht mehr sichtbar, weil sie wurde ja schon abgeholt. Die gibt es dann nicht mehr auf dem Server. Und ich würde behaupten, seit mehreren Jahren ist dieses Protokoll eigentlich überholt, weil heutzutage hat natürlich, was heißt natürlich, aber die meisten Leute haben halt mehrere Devices, um auf ihre E-Mails zu zugreifen. Und wäre halt blöd, wenn jede E-Mail immer nur auf genau einem Device ist und dann ist es meistens natürlich das, was ich gerade nicht in der Hand habe. Das heißt, wir wollen natürlich, dass die E-Mails auf dem Server bleiben und dass dann sowas wie diese E-Mail, habe ich schon gelesen, auch auf allen Geräten synchronisiert wird. Und dafür brauchen wir IMAP, weil das heißt ja Internet Message Access Protocol und Message Access, also der Zugriff auf die Nachrichten über das Internet. Das bedeutet, die Nachrichten bleiben auf dem Mail-Server und ich kann über das Internet darauf zugreifen. Ich kann meine Ordnerstruktur synchronisieren, meine gelesen Stati und alles Mögliche. Das geht über das IMAP und deswegen würde ich sagen, heute gibt es eigentlich keinen Grund mehr dafür. für POP3 zu nutzen. Außer irgendeinen technischen, wo ich sicherstellen will, dass E-Mails nur einmal verarbeitet werden oder sonst irgendwas. Für Endkunden, für Menschen ist IMAP eigentlich the way to go.

[24:22] Netzpläne und Projektmanagement

[24:22] So, nächste Aufgabe. Es gab noch mal ein paar mehr Punkte und zwar zehn insgesamt. Und zwar war das der gute alte Netzplan. Ach, wie schön. Und der Netzplan war allerdings schon fast vollständig vorgegeben. Man musste bloß noch ein paar Zahlen da eintragen. Also ich werde jetzt hier nicht auf der Tonspur was zum Netzplan erzählen. Das machen wir ganz sicher nochmal irgendwo später in einem YouTube-Video. Oder du guckst einfach an eines der vorhandenen an, die es im Internet gibt, Denn das waren aus meiner Sicht auch absolut geschenkte Punkte. Das ist ja nur Zahleneintragen. Aber auch da kann ich natürlich verstehen, wenn man noch nie Netzplan gesehen hat, wird es schwierig logischerweise. Aber Netzplan ist schon so lange auch in den Prüfungen drin. Und ich weiß es gerade gar nicht, ich muss mal eben parallel reinschauen. Ich glaube, der Netzplan ist inzwischen schon auf meiner Themenliste relativ weit oben zur AP1. Ich gucke direkt mal rein.

[25:05] Gesamtpunktzahl Einzelthemen, ja, ist auf Platz 2. Das heißt, Nutzwertanalyse auf Platz 1, also Stand heute 25, 45 Punkte bisher in den API-Einsen. Netzplan auf Platz 2 mit 29. Also doch mit ein bisschen mehr Abstand, 16 Punkte Unterschied bisher. Und danach käme dann SQL, was aber gestrichen wurde. Also Nutzwertanalyse, Netzplan, beides dicke Punktebringer und waren beide auch wieder in der Prüfung hier dran.

[25:28] Statische vs. Dynamische Webseiten

[25:29] So, dann kam noch mal was Neues, was so in der Form noch nicht in der API-Eins war, wenn ich mich recht entsinne. Und zwar sollte man erklären, den Unterschied zwischen einer statischen und einer dynamischen Webseite. Und wenn man das jetzt noch nie gehört hat, wie hätte man es sich herleiten können? Statisch bedeutet ja, ich mache immer gerne Analogien aus der Softwareentwicklung, weil ich ja Amazon-Entwicklerinnen ausbilde. Statisch ist immer, wenn sich nichts bewegt. Das heißt, ich programmiere gerade meinen Source-Code, drücke auf Kompilieren, aber dafür wird die Software noch nicht ausgeführt. Dynamisch bedeutet, ich starte die Software, interagiere damit, da bewegt sich was, ganz blöd gesagt. Und wenn ich die Idee mal übertrage auf Websites, ist eine statische Website eine, die sich nicht verändert. Ganz blöd gesagt, ich schreibe HTML und speichere das auf dem Webserver und es wird einfach HTML ausgeliefert, das immer gleich aussieht. Und da ändert sich nichts am Inhalt. Das ist eine sehr langweilige Website, weil die meisten sollen ja irgendwie neue Informationen vermitteln. Zum Beispiel in einem Blog soll ein Blogartikel dazukommen und nicht einfach die nächsten 100 Jahre immer der eine Blogartikel angezeigt werden. Das heißt, im Standard haben wir üblicherweise dynamische Websites, die also irgendwo aus dynamischem Inhalt, der meist aus einer Datenbank kommt, generiert werden. Das heißt, wenn ich die Seite aufmache, ist nicht sichergestellt, dass, wenn ich sie ein zweites Mal aufmache, ich die gleichen Inhalte sehe. Weil es könnte in der Zwischenzeit ja ein neuer Artikel dazu gekommen sein, zum Beispiel. Das ist also eigentlich das, was wir von so gut wie allen Websites kennen, das dynamische Verhalten. Aber erstmal, um den Unterschied zu erklären, hier in der Prüfung für drei Punkte, Hätte man jetzt sowas sagen können wie, statische Website heißt.

[26:50] Inhalte werden nicht dynamisch, ja, das habe ich schon mit dynamisch erklärt. Also statische Website heißt, die sieht immer gleich aus, sind immer die gleichen Inhalte, es ändert sich nichts. Und dynamisch werden die Inhalte halt neu generiert, zum Beispiel aus einer Datenbank, aus einer Textdatei, die ergänzt wird oder durch Benutzerinhalte oder sonst irgendwas. was. So, und dann war die nächste Frage. Also ich fand insgesamt auch recht Anwendungsentwicklerinnen freundlich, diese Prüfung, weil es kommt jetzt noch ein bisschen mehr zu Programmierung, zum Beispiel leider nur auf den Schreibtisch der ist. Aber die nächste Frage hier war jetzt auch, nennen Sie drei Programmiersprachen.

[27:20] Die man bei der Entwicklung von dynamischen Websites einsetzt. Und da bin ich mal sehr gespannt auf die Korrektur der Prüfung, was die Prüflinge da so alles geschrieben haben. Denn da wird, ich würde wetten, dass viele da zum Beispiel harte Meldungen geschrieben haben und CSS oder so. Und ja, das sind natürlich keine Programmiersprachen. Das sind natürlich Auszeichnungssprachen, bzw. CSS, zur Gestaltung der Inhalte. Und da dürfte man eigentlich keinen Punkt für geben. Weil hier steht explizit Programmiersprachen. Und Programmiersprachen habe ich, ich glaube, ich habe es in einem Video erklärt, was es eigentlich überhaupt ist, um das abzugrenzen. Weil es gibt zum Beispiel auch so etwas wie SQL, was auch keine Programmiersprache ist. Und ich erkläre es immer ganz einfach, wenn eine Sprache die drei Grundbausteine von Algorithmen anbietet. Und das sind Sequenzen, Verzweigungen und Wiederholungen. Dann habe ich eine Programmiersprache, denn dann kann ich damit Algorithmen formulieren und zwar beliebige Algorithmen und kann damit alle möglichen Probleme lösen. Und das kann weder HTML, da gibt es weder Verzweigung noch Wiederholung, noch CSS, noch HTML. Irgendwas, also HTML und CSS. Darum geht es mir eigentlich, weil Websites sagen natürlich viele HTML, CSS, aber sind da keine Programmiersprachen. Das heißt, was hätte man jetzt hier sagen können? Zum Beispiel die guten alten klassischen Skriptsprachen wie PHP, Python, Ruby. Man kann aber inzwischen auch ganz normale Programmiersprachen, also normal in Anführungszeichen, Java oder C Sharp oder ja, was gibt es denn noch?

[28:46] Programmiersprachen für Webentwicklung

[28:44] Im Prinzip kann man alles Mögliche an Programmiersprachen nennen. Hauptsache es ist eine echte Programmiersprache.

[28:49] Und damit programmiert man dann halt das Backend zum Beispiel und das gibt dann halt HTML aus, was der Browser dann rendern kann. Aber im Prinzip ist die Wahl der Programmiersprache egal. Man kann natürlich auch mit C eine Website programmieren. Das ist vielleicht nicht die erste Wahl, weil C dafür nicht so eine gute Unterstützung hat. Aber im Prinzip hätte man irgendwelche drei Programmiersprachen da hinschreiben können, die dafür verwendet werden. Aber natürlich gibt es Programmiersprachen, die sich besser eignen für Webentwicklung. Web-Entwicklung und das wäre jetzt aus meiner Sicht sowas wie JavaScript. Wird zwar auch kleinseitig natürlich ausgeführt, aber kann man ja auch serverseitig ausführen, wie zum Beispiel mit Node.js. Also das heißt, mit JavaScript kann ich auch die Grundlage der dynamischen Website, also das, was auf dem Server passiert, programmieren. Darum geht es ja hier, weil dynamisch heißt nicht, dass es im Client irgendwie lustig Dinge tut, sondern es soll ja dynamisch vom Server ausgeliefert werden und das wäre jetzt JavaScript. Aber ganz klassisch ist natürlich auch sowas wie PHP, Python, Ruby, aber eben auch Java oder C-Sharp, würde ich durchaus auch mit aufnehmen, weil halt auch viele Web-Anwendungen so damit entwickelt werden heutzutage.

[29:51] So, und dann hatten wir noch zwei sehr dankbare Aufgaben aus meiner Sicht. Auch hier kann ich verstehen, wenn einige Prüflinge das anders sehen. Hier haben wir einfach zwei vorgegebene Algorithmen in einer Pseudo-Programmiersprache, die sehr stark aussieht wie Ruby oder Python. Es könnte, glaube ich, eher Python sein, wegen der Einrückung und so weiter. Und da sollte man jetzt einfach mit gegebenen Werten, die dafür die Parameter definiert waren, einfach sagen, was kommt am Ende raus. Das heißt, ich habe es auch in meinem Prüfungskurs vorab so erklärt, Schreibtischtest, das ist sowas wie, ich spiele Computer. Ich habe diesen Code und ich tue jetzt so, als wäre ich der Computer und spiele das einfach Zeile für Zeile durch und gucke, was wird da berechnet und was kommt da raus. Und in diesem Fall war es eine relativ simple mathematische Aufgabe. Man hätte jetzt einfach nur die Argumente, die da reingegeben werden, dort einsetzen müssen, ein bisschen ausrechnen müssen und das war es dann. Das heißt, das war Teil 1 der Aufgabe und der zweite Teil, der noch ein paar mehr Punkte gab, da gab es halt einen etwas verschachtelteren Code mit vierfach verschachtelten If-Statements. Würde ich in der Realität so auch nicht programmieren, aber darum geht es ja hier nicht, sondern es war ein bewusst einfacher Code, zum Beispiel ohne Schleifen, auf der anderen Seite aber auch ein bisschen komplizierter, weil es halt so viele Verschachtelungen gab, aber im Prinzip war hier das gleiche Prinzip, im Prinzip war das gleiche Prinzip, ja genau, super.

[31:02] Das heißt, ich habe den Code gegeben, habe eine Angabe, mit welchen Argumenten ich den aufrufen soll, sollte das einmal durchspüren und sagen, was kommt am Ende raus. So, das war’s. Das heißt, wenn ich mich irgendwann mal ein bisschen mit Programmierung beschäftigt habe. Und im zweiten Fall war es sogar mehr oder weniger Pseudocode. Das heißt, ich musste noch nicht mal eine bestimmte Syntax verstehen, sondern eigentlich nur, wenn und dann und kleiner, gleich und so, also mathematisch war gleich und so, eine Variablenzuweisung. Also, wenn ich irgendwie das erste Berufsschuljahr überstanden habe, würde ich behaupten, dass jeder ITler diesen Code verstehen muss. Selbst wenn ich jetzt nicht nochmal Code wiederholt habe vor der Prüfung, weil das war wirklich so offensichtlich, meiner Meinung nach. Wenn man sich da jetzt noch beschwert über die bösen Pseudocode-Aufgaben, dann kann ich es irgendwo auch nicht mehr nachvollziehen, ganz ehrlich, weil das ist, das kann man, also ich würde behaupten, sogar meine Mutter würde das verstehen, wenn ich ihr das hinlege und die hat noch nie irgendwas programmiert. Das ist ja einfach nur, wenn so, dann das und das, wenn so, dann das und das. Ja, es war blöd verschachtelt, okay, aber das hätte ich jetzt, weiß ich nicht, das hätte ich jetzt mit so einem Lineal, Zeile für Zeile durchgehen können oder mit so einem Stift als Führungslinie, ja, und hätte das einfach

[32:13] Pseudocode und Programmierverständnis

[32:10] nur noch einsetzen müssen und gucken, was trifft zu und was nicht. Und deswegen waren das aus meiner Sicht geschenkte Punkte. Aber wie gesagt, ich kann auch nachvollziehen, wenn andere Prüflinge, andere Berufe das anders sehen.

[32:21] Künstliche Intelligenz in der Prüfung

[32:21] So, und dann kommen wir natürlich zur letzten Aufgabe, wo der große Aufschrei kam. KI, die künstliche Intelligenz. Da war ja schon vorab sehr viel gemunkelt, dass das wohl drankommt und kommt auch dran. War ja, glaube ich, viermal oder dreimal im neuen Prüfungskatalog. Also, das war ja nun mal der Hammer auf den Kopf. Wenn du das nicht anguckst, dann bist du selber schuld. Aber wenn man sich jetzt die Aufgaben anguckt, dann hätte man sich das vielleicht auch doch eigentlich gar nicht angucken müssen, weil im Prinzip war es ein bisschen gesunder Menschenverstand. Und so habe ich es auch immer vorher gesagt, auch in meinem Prüfungskurs. Diese Aufgaben sind ja vom Niveau her nicht so, dass man jetzt nochmal eben erklärt, wie ein neuronales Netz funktioniert oder was, weiß ich nicht. Wie heißt es noch? Beobachtbares Lernen, wo ich schon gab, begleitendes Lernen oder sowas ist. So tief geht das ja gar nicht, bei allen Themen übrigens, sondern es geht dann hier um die Anwendbarkeit. Das heißt, in diesem Fall war es der Kontext meiner Anwaltskanzlei, die möchte KI einsetzen. Wo genau könnten sie das denn tun? Was kann denn KI, um uns an bestimmten Stellen zu unterstützen? Zum Beispiel, wenn ein neuer Mandant sich meldet, was kann die KI für uns da tun? Die könnte zum Beispiel so eine Background-Recherche durchführen. Wer ist das denn überhaupt? Websites durchsuchen, aggregieren, zusammenfassen. So nach dem Motto, erstelle mir auf einer DIN-A4-Seite alles, was du über diesen Mandanten herausbekommen kannst. Als Beispiel.

[33:32] Oder wenn sich jemand bei uns meldet und hat eine Frage zu einem rechtlichen Problem, dann könnt ihr das ja auch erstmal mit einem Chatbot zum Beispiel besprechen, der einem erstmal so eine grobe Indikation gibt, ob sich es lohnt, dafür eine Klage aufzunehmen oder nicht. So, jetzt mal nur als Beispiel. Das heißt, ich werde zum Beispiel entkoppelt von meinem teuren Anwalt, indem ich erstmal mit dem Chatbot rede. Nur als Idee. Und hier war jetzt die konkrete Aufgabe so, dass es halt fünf Szenarien gab, in so einem, ich nenne es mal Betreuungsprozess bei einem Mandanten, von ich kenne den Mandanten noch gar nicht bis hin zu ich mache für den eine Klage, ganz blöd gesagt. Und wo kann da die KI zum Beispiel den Anwalt unterstützen? Da durfte ich mir ein bisschen was ausdenken tatsächlich. Also ich bin gespannt auf die Musterlösung, weil da hätte ich jetzt wirklich alles Mögliche mir ausdenken können, wo halt so eine KI mich unterstützen kann. Und wenn ich jetzt im Alltag schon mal irgendwie ein bisschen zum Beispiel mit ChatGBT gearbeitet habe und auch nur eine halbe Stunde damit rumexperimentiert habe, dann hätte ich diese Frage, glaube ich, schon beantworten können. Und ich gehe einfach mal davon aus, selbst wenn ihr, oder du, wenn du jetzt zuhörst, KI noch nie in der Berufsschule hattest, was ja immer so das Totschaftergument ist. Das hatten wir noch nie in der Schule. Ja, okay, aber muss ich das wirklich in der Schule durchgehen, was ich mit KI alles machen kann? Also KI ist so ein dominantes Thema. Ich glaube, sogar meine Oma hat das schon mal gehört. Die hat das vielleicht noch nicht benutzt, aber die hat schon mal was davon gehört. Und ich würde einfach mal behaupten, IT-Auszubilder oder Umschülerinnen, diese haben eine gewisse Affinität zu IT. Und wenn man jetzt im Jahr 2025 noch nie eine KI ausprobiert hat.

[34:56] Dann ist man vielleicht im falschen Beruf. Das ist jetzt vielleicht eine harte Aussage, aber das Niveau, von dem wir hier reden, geht nicht sonderlich hinaus über, ich weiß, was so eine KI für mich machen kann. Mehr ist es eigentlich nicht.

[35:08] Und dann, nächster Teil der Aufgabe, für allerdings nur zwei Punkte, war, was ich auch vorab vermutet habe, eine ethische Betrachtung. Und konkret ging es darum, einige Mitarbeitende haben vielleicht Probleme mit KI. Und was könnten da die Bedenken sein und was kann ich dagegen tun? Und in diesem Fall war einfach die Frage, was wäre denn ein Vorteil für die Mitarbeitenden? Anstatt zu erzählen, ja, dies und das und das ist doch eigentlich ganz gut. Hier geht es darum, einen konkreten Vorteil mal zu nennen. Und was wäre denn ein Vorteil? Naja, Nachteil wäre natürlich, ich verliere vielleicht meinen Arbeitsplatz, weil die KI meinen Job macht. Okay, auf der anderen Seite habe ich auch einen Vorteil. Ich muss vielleicht die ganzen blöden, langweiligen, wiederkehrenden Aufgaben nicht mehr machen, weil ich das der KI übergeben kann. Das heißt, vielleicht wird mein Job auch spannender dadurch, weil ich mir auf das Interessante konzentrieren kann und den langweiligen Quatsch durch die KI machen lassen kann. Das wäre jetzt ein Beispiel, was man da sicherlich hätte hinschreiben können. Also triviale oder wiederholbare Tätigkeiten auslagern, automatisieren. Gut, dann sind wir immer noch beim oa.ki, aber das nächste ist eine ganz klassische Rechenaufgabe. Hat eigentlich mit KI nichts mehr zu tun. Man sollte eigentlich nur noch ausrechnen,

[36:08] Kostenanalyse für KI-Anwendungen

[36:06] wie teuer der Einsatz von so einem Chatbot ist. Und das war im Prinzip vorgegeben, so und so viel kostet der im Monat, so viele Stunden pro Monat wird der eingesetzt oder was auch immer. Und dann musste das wieder multipliziert werden und summiert werden und das war’s. Also super simple Matheaufgabe unter dem Deckmantel von KI. Und auch das habe ich vorher prognostiziert, dass so etwas drankommen könnte, sage ich schon seit Jahren bei den ganzen Hype-Themen Erstmal genau hingucken, was man da machen muss. Und hier war es wirklich plain Mathematik. Hatte KI bloß in der Überschrift stehen und das war es.

[36:34] So, und dann ging es aber nochmal wieder zurück zur KI, wo man wirklich ein bisschen hätte wissen müssen. Und zwar, was sind denn Vor- und Nachteile eines Chatbots? Und ich bin mir nicht sicher, aber ich meine, dass genau diese Frage schon mal in einer Prüfung rankam. Da ging es dann auch um ein Chatbot. Und in dem Fall war es, glaube ich, so etwas wie IT-Support. Das heißt, hey, die Firma möchte Geld sparen und den IT-Supporter durch eine KI ablösen, nämlich einen Chatbot. Was sind die Vor- und Nachteile? Und hier ist es tatsächlich genau das Gleiche.

[37:02] Vor- und Nachteile von Chatbots

[37:02] Nur, dass der Kontext ein bisschen anders ist. Das heißt, anstatt, dass mein Kunde den Anwalt anruft, spricht der Kunde erstmal mit dem Chatbot. So, das heißt exakt gleiches, also nein, Szenario nicht, aber gleiche Konstellation, nur eine andere Branche. Aber die Frage ist exakt gleich zu beantworten, wie bei der vorherigen Prüfung. Und zwar, was sind die Vornachteile eines Chatbots? Und ganz simpel gesagt, ich mache jetzt nicht alle, die man da aufzählen kann, aber natürlich ist ein Chatbot nicht persönlich und Menschen, gerade wenn die Chatbots nicht so gut funktionieren, fühlen sich natürlich auch ein bisschen veralbert oder nicht ernst genommen. Das könnte also Kunden abschrecken zum Beispiel. Auf der anderen Seite entlastet es natürlich unsere teuren Anwälte von trivialen Fragen, wie kann ich meinen Nachbar verklagen, wenn seine Hecke zu hoch ist. Das kann auch ein Chatbot beantworten. Das heißt, beide Seiten immer betrachten und das sage ich ja auch immer, gerade bei neuen Hype-Themen, es geht nicht darum, die ein bisschen ins Detail erklären zu können, sondern die ein bisschen einzuordnen. Sollen wir das einsetzen? Wenn wir das machen, was sind die Vor- und Nachteile? Was haben wir davon? Was könnte das kosten? Um solche Sachen geht es und es geht hier nicht darum, einen Chatbot zu programmieren oder zu erklären, wie man den trainiert. Das ist einfach für die API 1 viel zu detailliert, viel zu genau. Das wird aus meiner Sicht so nicht abgefragt beim nächsten Hype-Thema. Ich weiß nicht, was das nächste Hype-Thema sein wird. Vor fünf Jahren war es die Blockchain, jetzt ist es KI. In fünf Jahren ist es was anderes. Aber da werden die Aufgaben genauso aussehen.

[38:19] Netzwerktechnik und SSH

[38:19] Allgemeine Fragen zu einer neuen Technologie, die ich heute noch nicht kenne.

[38:23] So, dann kommen wir zurück. Weiterhin unter dem Deckmantel der KI, aber ehrlich gesagt klassische Netzwerktechnik-Aufgabe. Und zwar läuft die KI zufällig auf einem Web-Server, den wir von außen administrieren wollen. Wir wollen uns mit dem Web-Server verbinden. Und jetzt ist die Frage, womit machen wir das? Und jetzt, also ich finde die Aufgabenstellung, ehrlich gesagt, ganz cool. Die haben jetzt hier so einen kleinen Screenshot von so einer, ja, wie soll ich sagen, von so einer Konfigurationsmaske gezeigt, wo man eine IP-Adresse und so eintragen kann. Also was muss ich eintragen, um mich mit dem Server zu verbinden? Finde ich, ehrlich gesagt, ganz cool. So ein bisschen praxisnah. Und man sollte jetzt aus dem Text, der darüber stand, hätte man jetzt ableiten müssen, was die IP-Adresse ist. Und die interessante Frage ist jetzt aber, Aber welches Protokoll nehme ich denn? Und zur Wahl stehen SSH, Serial und Telnet. Und ich sage ja immer, Leute, lernt eure Ports auswendig. In diesem Fall haben sie sogar das geschenkt, weil direkt nach der Aufgabe ist eine Tabelle mit den üblichen Ports und Telnet und SSH stehen beide drin. Das heißt, man muss doch nicht mal die Ports auswendig kennen und ich werde langsam wirklich traurig. Warum kann man nicht diese paar Ports auswendig lernen? Naja gut, man kann jetzt auch die Frage stellen, ist das noch zeitgemäß, solche Sachen auswendig zu lernen? Aber wenn ich sie auswendig gekannt hätte, hätte ich die Frage so runterschreiben können. In diesem Fall hätte ich halt mal drei Zeilen weiter unten gucken müssen, wie der Port ist und dann konnte ich sie auch lösen, ohne dass ich überhaupt wissen muss, was SSH eigentlich ist.

[39:37] Naja, das ist nicht ganz richtig, weil ich muss mich ja entscheiden. Nehme ich SSH, Telnet oder Serial? Kurz zum Hintergrund. Das steht sogar in der Tabelle drunter. SSH steht wortwörtlich, dass es eine verschlüsselte Fernwartung ist. Und Telnet steht daneben, unverschlüsseltes Protokoll. Also wie offensichtlich soll man es noch machen, dass es natürlich SSH sein muss? Und Serial? Okay, Serial steht nicht in der Tabelle. Das hätte man jetzt vielleicht wissen müssen oder aus dem Namen einfach ableiten sollen. Serial, Seriell. Was ist eine serielle Verbindung? Okay, ich sage, woher, wieso soll man das nicht wissen? Aber ich bin ja auch schon ein Ticken älter. Also serielle Verbindungen habe ich schon seit Jahren nicht mehr benutzt. Und selbst vor Jahren habe ich sie kaum benutzt. Einfach eine serielle Verbindung, Kabel direkt zwischen zwei Rechnern. Ja, ich wüsste nicht mal mehr, dass moderne Hardware überhaupt einen seriellen Port noch hat, wo ich das ranstecken kann. Aber man kann sich sowas vorstellen wie, bei mir habe ich einen USB-Stecker und auf dem anderen Rechner auch und ich stecke ein USB-Kabel dazwischen und dann können die miteinander reden. Ungefähr so kann man sich das vorstellen. Ich wüsste nicht, was das Serial hier sonst heißen soll. Also die Wahl ist ganz klar SSH, denn ich kann weder ein Kabel zu meinem Web-Server legen, noch möchte ich unverschlüsselt kommunizieren, also muss es SSH sein.

[40:46] So und dann war auch direkt die nächste Aufgabe, begründen sie, warum sie das genommen haben und dann wäre meine Begründung, ja weil es verschlüsselt ist und weil ich kein Kabel zum Server legen kann, also wenn ich ein Kabel zum Server legen könnte, würde ich vielleicht sogar das nehmen, weil dann habe ich noch zusätzlich quasi die Hardware-Schicht dazwischen, da man mich dann nicht abhören kann, müsste ich ja das Kabel irgendwie abhören, aber da das nun mal schlecht geht, dann nehme ich natürlich SSH.

[41:10] So und dann kommen die letzten beiden Fragen, die halt zu dem Thema kamen, die das noch nicht auf meine Website stand, und zwar Redundanzen. Und zwar war erstmal die Definition gefragt, was sind überhaupt Redundanzen? Und dann kommt die zweite Frage, was ist ein Problem, was durch Redundanzen entsteht? Und ich habe, natürlich nicht für die API 1, aber für die API 2 Amnestypikation schon vor, auch wieder vor Jahren, Episoden zum Thema Normalisierung einer Datenbank, zum Beispiel auch am Beispiel aufgenommen, aber auch noch ein YouTube-Video, wo ich normalisiere von einer Excel-Tabelle bis hin zur normalisierten relationalen Form. Und da werden wir natürlich auch am Anfang über Redundanz entsprechen, weil das ist der genaue Grund, warum wir überhaupt Datenbanken normalisieren, nämlich um Redundanz zu vermeiden. Das heißt, die Definition und dann natürlich eine sehr beliebte Fachgesprächsfrage für Anwendungsentwicklerinnen, nämlich was sind denn Probleme von Redundanz? Die Anomalien, die dadurch entstehen. Wenn ich Daten doppelt habe, was ich habe sogar geklärt, Redundanz heißt, ich habe Sachen mehrfach doppelt vorhanden. Und in einer Datenbank wäre das so, ich habe nicht nur einen Datensatz, sondern fünfmal den gleichen. Ja, und das Problem, was da entstehen kann, ist, wenn ich einen ändere, dann habe ich auf einmal inkonsistente Daten. Ja, das wäre die Änderungsanomalie. Es gibt noch zwei andere. Die Einfüge- und Löschanomalie, die will ich jetzt hier für die AP1 nicht erklären,

[42:23] Redundanzen in Datenbanken

[42:22] weil das ist irrelevant für die Prüfung. Habe ich aber alles schon in Video- und Podcastform für die AP2-Anbietungsentwicklung erklärt, denn da ist das natürlich höchstgradig prüfungsrelevant.

[42:31] So, das waren jetzt so die Themen der API 1. Wir sehen, grob zusammengefasst, es gab ein bisschen Security, es gab ein bisschen KI, es gab ein bisschen was zur Programmierung und ja, breites Themenfeld, die, wie soll ich sagen, die fachliche Tiefe der Aufgaben war, wie zu erwarten, relativ überflüssig, wollte ich schon sagen, oberflächlich, ja. Und ich behaupte, dass man sich viele Aufgaben auch einfach mit ein bisschen Nachdenken hätte erarbeiten können, gerade die KI-Aufgaben.

[42:57] Wofür könnte ich KI denn noch einsetzen? Das hört sich so an wie so ein Arbeitsauftrag in der Grundschule. Schreibe einen Aufsatz über, was kann man mit KI machen? Es ist jetzt übertrieben, ich weiß. Und wenn ich da sitze in der Prüfung, da fällt mir das vielleicht auch nicht ein. Ich kann das alles nachvollziehen, bitte nicht falsch verstehen. Aber ich glaube, selbst wenn ich noch nie KI selber programmiert habe oder sonst irgendwas, hätte ich diese Aufgaben ja locker lösen können, weil ich einfach nur ein bisschen überlegen muss, was ich damit machen kann in der Realität. So, das möchte ich damit sagen. Also aus meiner Sicht eine absolut machbare Prüfung. Ich habe auch schon von vielen gehört, die tatsächlich auch früher fertig waren, weil man wirklich auch nicht so viel schreiben musste. Das war ein bisschen auch was lesen, aber zum Beispiel auch die Zolle-Code-Aufgaben, da Schreibtisch-Test, da war die Antwort waren irgendwie zwei Zahlen oder sowas. Das geht ja theoretisch recht schnell, sodass viele auch Zeit hatten, das nochmal zu kontrollieren, ob das denn richtig war und so. Also ich glaube, es war eine faire Prüfung und finde ich aber auch wiederum ganz gut, wenn sie es absichtlich gemacht haben, die Prüfungsherstellerinnen. Denn nach dem ganzen Aufschrei wegen dem neuen Prüfungskatalog fand ich das hier eine absolut faire Prüfung.

[44:01] Abschluss und Ausblick auf Ergebnisse

[43:58] Keine super krassen Überraschungen drin, die halt eben nicht im Prüfungskatalog standen. Und wenn es neue Themen waren, dann wirklich sehr oberflächliche Aufgaben dazu, ohne tiefergehendes Wissen. Also aus meiner Sicht eine vernünftige AP1. Ich bin sehr gespannt auf den Durchschnitt der Ergebnisse. Wird noch ein paar Monate dauern, bis wir den rausbekommen. Da habe ich es bestimmt schon wieder vergessen. Aber ich könnte mir vorstellen, dass der Schnitt ganz gut aussieht. Ja, aber der Rest wird sich zeigen.

[44:23] Damit bin ich am Ende meiner heute sehr zeitnahen Episode zur AP1. Ich hoffe, es war ein bisschen was für dich dabei, was auch nach diesem Prüfungstermin noch relevant ist. Ich habe ja noch ein paar Sachen erklärt heute für die nächsten AP1. Und ja, ich sage vielen Dank fürs Zuhören. Und falls du noch mehr von mir hören willst, vor allem in schriftlicher Form, melde dich doch für meinen Newsletter an. Den nenne ich auch Ausbildungsbegleitung, weil du parallel zu deinen drei Jahren der Ausbildung immer wöchentlich Infos von mir bekommst. Zum Beispiel, wie du dich am besten auf die AP1 vorbereitest, wenn die ansteht oder für die AP2, die jetzt bald bei einigen ansteht. Und es ist alles kostenfrei, kannst du jederzeit abmelden. In jeder E-Mail findest du einen Link dazu. Von daher kannst du einfach auf der Website machen, itberufepodcast.de slash Newsletter. Und da habe ich dann ja zum Beispiel auch meine kostenfreien Prüfungskurse beworben, die es inzwischen leider nicht mehr gibt, aufgrund verschiedener Vorfälle leider. Aber ich arbeite schon an Alternative dazu und wenn es da was gibt, wird es natürlich auch über den Newsletter verbreitet. Das heißt, du bekommst da alle Informationen von mir, was ich für dich noch so anbiete, wenn du dich dort anmeldest. Das war es von mir für heute. Ich hoffe, die Episode hat dir gefallen. Wenn du die API 1 noch vor dir hast, drücke ich dir die Daumen dafür und du hast vielleicht ein bisschen was mitgenommen. Ich sage vielen Dank fürs Zuhören und bis zum nächsten Mal. Tschüss.

Über den Unterschied zwischen Kauf, Miete und Leasing zur Finanzierung in Unternehmen geht es in der einhundertdreiundneunzigsten Episode des IT-Berufe-Podcasts.

Miete, Leasing oder Kauf – Welche Finanzierung passt zum Unternehmen?

Wenn Unternehmen teure Güter anschaffen müssen, stellt sich die Frage, wie diese finanziert werden sollen. Für die AP1 der IT-Berufe sind hier insbesondere die Unterschiede zwischen Kauf, Miete und Leasing interessant.

In dieser Episode des IT-Berufe-Podcasts beleuchte ich die Unterschiede zwischen Kauf, Miete und Leasing, und warum dieses Thema auch für die IT-Abschlussprüfung von Bedeutung ist. Als kaufmännischer Teil der IT-Ausbildung ist es unerlässlich, die verschiedenen Finanzierungsoptionen zu verstehen, besonders wenn es um größere Investitionen wie Fahrzeuge, Maschinen oder Server geht.

Zunächst analysiere ich die Kaufoption. Der Kauf eines Vermögenswertes bietet den Vorteil, dass dieser nach der Zahlung des Kaufpreises vollständig in den Besitz des Unternehmens übergeht. Hier bespreche ich die Vor- und Nachteile, beginnend mit der hohen Anfangsinvestition, die oft notwendig ist. Ich erkläre, wie Kredite funktionieren, einschließlich der verschiedenen Zinsarten und Rückzahlungspläne, die in der Regel über mehrere Jahre laufen. Diese Art der Finanzierung bringt die Verpflichtung mit sich, sich um das gekaufte Gut zu kümmern, was Instandhaltungskosten mit sich bringt. Ich gehe auch auf die Themen Steuerabschreibung und Wertverluste ein, die beim Besitz eines Vermögenswertes zu berücksichtigen sind.

Anschließend wende ich mich dem Thema Miete zu. Hier zeige ich auf, wie Miete mehr Flexibilität bietet, da Unternehmen in der Lage sind, kurzfristig auf Bedürfnisse zu reagieren, ohne große Anfangsinvestitionen zu tätigen. Bei der Mietung eines Fahrzeugs beispielsweise entfällt die Verantwortung für Wartung und Versicherung, was für Start-ups oder junge Unternehmen eine kostengünstige Lösung darstellen kann. Allerdings erödemie ich auch, dass die Miete langfristig die teuerste Option sein kann, da regelmäßige Zahlungen anfallen, ohne dass ein Eigentum entsteht.

Schließlich bespreche ich das Leasing, das eine besondere Form der Miete darstellt. Leasingverträge ermöglichen es Unternehmen, teure Investitionen über längere Zeiträume zu finanzieren, oft zu geringeren monatlichen Raten als bei Mietverträgen. Ich erläutere die typischen Laufzeiten und die Vorkaufsoptionen, die dem Leasingnehmer die Möglichkeit geben, das geleaste Objekt nach Ablauf des Vertrages zu kaufen. Zugleich beleuchte ich die Nachteile des Leasings, insbesondere die langfristige Bindung und die Tatsache, dass Leasing insgesamt teurer ist als ein Kauf, wenn das Asset über längere Zeiträume genutzt wird.

Abschließend fasse ich die verschiedenen Aspekte zusammen, um den Zuhörern ein klares Bild davon zu geben, unter welchen Umständen welche Finanzierungsform sinnvoll ist. Besonders die Prüfungsvorbereitung wird durch konkretes Beispiel-Rechnen und das Verständnis der Kriterien erleichtert, die bei der Entscheidung zwischen diesen Optionen zu beachten sind.

Kauf

Definition: Einmalige Investition für Eigentum an einem Produkt oder einer Dienstleistung.

Vorteile:

• Langfristig günstiger als Miete oder Leasing
• Volle Kontrolle und keine Vertragsbindung
• Abschreibungen und steuerliche Vorteile möglich
• Keine Einschränkungen bei Nutzung oder Anpassungen

Nachteile:

• Hohe Anfangsinvestition nötig
• Risiko von Wertverlust und Veralterung (besonders bei IT-Hardware)
• Wartung und Reparaturen gehen zulasten des Käufers

Praxisbeispiel: Kauf von Firmenlaptops oder Produktionsmaschinen

Miete

Definition: Kurzfristige Nutzung gegen regelmäßige Zahlungen ohne Eigentumserwerb.

Vorteile:

• Hohe Flexibilität (monatlich kündbar, kurze Laufzeiten)
• Keine hohen Anfangsinvestitionen
• Wartung und Service oft inklusive
• Gut für kurzfristige oder projektbezogene Einsätze

Nachteile:

• Langfristig oft teurer als Kauf oder Leasing
• Kein Eigentum – Unternehmen hat keine Abschreibungsmöglichkeiten
• Eingeschränkte Individualisierungsmöglichkeiten

Praxisbeispiel: IT-Ausrüstung für temporäre Projekte

Leasing

Definition: Langfristige Miete mit festgelegten Raten, oft mit Kaufoption am Ende.

Vorteile:

• Geringe Anfangsinvestition
• Planbare Kosten über einen längeren Zeitraum
• Bilanzneutral (je nach Leasingart)
• Aktuelle Technik ohne hohe Einmalzahlung nutzbar

Nachteile:

• Vertragliche Bindung über Jahre
• Gesamtkosten oft höher als Direktkauf
• Eventuelle Restwertrisiken oder Zusatzkosten bei Rückgabe

Praxisbeispiel:: Leasing von Servern oder Firmenfahrzeugen

Vergleich und Entscheidungshilfe

Wann lohnt sich welche Finanzierungsform? Entscheidungskriterien: Budget, Nutzungsdauer, Flexibilität, steuerliche Aspekte

Beispielrechnung: Firmenwagen – Kauf, Miete oder Leasing?

Annahmen für den Vergleich:

• Fahrzeug: Mittelklasse-Firmenwagen
• Kaufpreis: 40.000 €
• Jährliche Fahrleistung: 30.000 km
• Wartung & Versicherung: 150 €/Monat (bei Kauf oder Leasing, in Miete oft enthalten)
• Finanzierungskosten: 3% p.a. (bei Kauf auf Kredit)
• Restwert nach 3 Jahren: 50% des Kaufpreises = 20.000 €

Kauf (mit 3% Kreditfinanzierung)

• Kreditbetrag: 40.000 €, Laufzeit 3 Jahre, 3% Zinsen
• Monatliche Rate (Annuitätendarlehen): 1.160 €
• Gesamtkosten für Kredit: 1.160 € × 36 Monate = 41.760 €
• Wartung & Versicherung über 3 Jahre: 150 € × 36 Monate = 5.400 €
• Wiederverkaufswert nach 3 Jahren: -20.000 €
• Gesamtkosten: 41.760 € + 5.400 € – 20.000 € = 27.160 €

✅ Vorteile: Langfristig günstiger, Eigenkapitalbildung

❌ Nachteile: Hohe Anfangsinvestition, Wertverlustrisiko

Miete (Auto-Abo)

• Monatliche Rate: 1.200 € (inkl. Wartung, Versicherung, Steuer)
• Gesamtkosten über 3 Jahre: 1.200 € × 36 Monate = 43.200 €

✅ Vorteile: Keine langfristige Bindung, alle Kosten enthalten

❌ Nachteile: Sehr teuer auf lange Sicht, kein Eigentum

Leasing

• Monatliche Leasingrate: 500 €
• Wartung & Versicherung: 150 €
• Gesamtkosten über 3 Jahre: (500 € + 150 €) × 36 Monate = 23.400 €
• Falls Kauf am Ende möglich: Restwertzahlung 20.000 €
  • Kosten ohne Kauf: 23.400 €
  • Kosten mit Kauf: 43.400 €

✅ Vorteile: Niedrige monatliche Kosten, steuerliche Vorteile

❌ Nachteile: Langfristige Verpflichtung, evtl. Mehrkosten bei Rückgabe

Vergleich der Gesamtkosten über 3 Jahre

• Kauf (Kreditfinanziert): 47.160 €
• Miete (Auto-Abo): 43.200 €
• Leasing (ohne Kauf): 23.400 €

• Leasing (mit Kauf): 43.400 €

• Kauf ist auf lange Sicht günstiger als Leasing mit Kaufoption, aber erfordert höhere Anfangsinvestitionen. Falls das Auto länger als 3 Jahre genutzt wird, wird Kauf noch attraktiver, da nach Kreditablösung keine monatlichen Raten mehr anfallen.

• Miete ist am teuersten, lohnt sich aber für maximale Flexibilität.

• Leasing ist am günstigsten, wenn das Auto nach 3 Jahren zurückgegeben wird.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts

Transkription der gesamten Episode

[0:00] Herzlich willkommen zum IT-Berufe-Podcast, dem Podcast rund um die Ausbildung in den IT-Berufen. In dieser Episode geht es um den Unterschied zwischen Kauf, Miete und Leasing. Viel Spaß!

[0:12] Hallo und herzlich willkommen zur 193. Episode des IT-Berufe-Podcasts.

[0:18] Mein Name ist Stefan Macke und heute geht es mal um ein ganz, ganz spannendes Thema, was allerdings wenig mit IT zu tun hat, aber was oft in der IT-Abschlussprüfung abgefragt wird. Und zwar den Unterschied zwischen Kauf, Miete und Leasing. Was hat das mit IT zu tun, fragt man sich, wenn man dieses Thema hört. Aber wie wir alle wissen, sind die IT-Berufe kaufmännische Berufe. Und deswegen müssen wir auch ein bisschen Rechnungswesen und so ein Zeug lernen. Und dazu gehört zum Beispiel auch die Frage, wenn ich was für mein Unternehmen anschaffen möchte, zum Beispiel ein Auto, eine Maschine oder auch Server, die sind ja auch nicht gerade günstig heutzutage.

[0:55] Was ist denn da am sinnvollsten? Soll ich das Ding kaufen? Soll ich da für einen Kredit aufnehmen? Miete ich mir die vielleicht oder lease die? Und was da so die Unterschiede sind zwischen diesen drei Arten der Finanzierung für Investitionen, wie zum Beispiel Serveranschaffung und so weiter. Das wollen wir uns heute mal anschauen oder anhören, besser gesagt. Und die Frage ist, wie bin ich jetzt auf dieses Thema gekommen? Ich habe ja in meiner letzten Episode die ganzen bisherigen Themen der AP1 und 2 für AnwendungsentwicklerInnen auseinandergenommen. Und da ist mir mit Erstaunen aufgefallen, dass tatsächlich auf Platz 6 Auf Platz 5 der Themen, die bisher die meisten Punkte brachten in den AP1en, steht tatsächlich Leasing. Und das ist dann oft sowas wie, vergleichen Sie Leasing mit Miete oder Kauf, was sind die Vor- und Nachteile, aber teilweise auch wirklich komplett ausgerechnet, das und das ist die Leasingrate, was kostet das nach x Jahren und so weiter und so fort. Also da kann man ganz viel mit verbinden. Sowohl schöne kleine Rechenaufgaben als auch so ein bisschen Wissensfragen.

[1:53] Was ist der Unterschied? Was heißt überhaupt Wiesing und so weiter? Und ja, das ist, da hätte ich jetzt nicht gedacht, dass es zu diesem Thema so viele Fragen schon gab. Deswegen ist es Zeit, das jetzt vielleicht mal aufzunehmen, weil wir wollen ja auch ein bisschen die Prüfungsvorbereitung natürlich machen. Und außerdem sind solche Fragen natürlich nicht nur für die Prüfung interessant, sondern auch für den Rest des Lebens. Wenn man vielleicht mal irgendwas anschaffen will, auch als Privatperson, ist es ja vielleicht ganz interessant, die Unterschiede zu kennen oder zumindest dann, worauf man achten kann oder soll, wenn man sich entscheidet, wie man es machen will.

[2:19] Ja, und so würde ich das heute einfach mal aufbauen. Wir gucken uns die drei Sachen an und ich würde anfangen mit dem Kauf. Dann gehen wir zur Miete und dann kommen wir zum Leasing. In der Reihenfolge würde ich mal durchgehen. Den jeweiligen Vor- und Nachteilen und was am Ende dann so die Kriterien sind, um zu entscheiden, was man am besten machen kann. Aber fangen wir mal ganz vorne an. Alle drei Formen sind Finanzierungsformen. Das heißt, ich möchte irgendetwas für mein Unternehmen anschaffen, sei es ein Haus, ein Grundstück, ein Auto, ein Server, ein was auch immer. Irgendwas will ich für mein Unternehmen anschaffen. und jetzt habe ich grundsätzlich ja immer die Möglichkeit, das Ding einfach im Laden zu kaufen oder zu bestellen bei einem Online-Shop oder was auch immer und mir das liefern zu lassen. Aber wenn es ein bisschen teurer wird, dann ist vielleicht die Frage, ob es da nicht noch Alternativen gibt, weil da muss man sich schon ein bisschen Gedanken machen. Wenn ich jetzt so ein Auto kaufe für, weiß ich nicht, 40.000 Euro.

[3:09] Habe ich das Geld Cash auf dem Konto und will das auch ausgeben dafür und das Geld damit quasi binden an diesem Auto oder will ich das vielleicht lieber doch nicht ausgeben, stattdessen aber zum Beispiel dann mieten und mit dem Geld, was ich jetzt auf der Bank rumliegen habe, halt was anderes machen. Zum Beispiel investieren oder noch was anderes kaufen, noch ein zweites Auto oder was weiß ich. So, das ist ja immer die Frage, was mache ich mit meinem Geld? Gebe ich das lieber aus? Hole ich mir einen Kredit? Binde ich mich da an irgendwelche langfristigen Verträge? Hau ich das einmal auf den Tisch? Das hat alles immer so Vor- und Nachteile und das muss man sich immer gut überlegen. Je nachdem, wie viel Geld ich vielleicht auch in den nächsten Monaten und Jahren brauche. So ein bisschen Liquiditätsplanung hängt dahinter und so weiter. Und diese drei grundsätzlichen Arten, die wir uns heute angucken.

[3:48] Kann man dabei so ein bisschen unterscheiden. Also wenn ich jetzt liquide genug bin und richtig viel Kohle auf dem Konto habe, dann ist es wahrscheinlich kein Problem zu sagen, komm, ich kaufe das Auto jetzt, dann gehört es mir, es ist bezahlt, ich habe keine langen Verträge oder so an der Hacken und bin fertig. Aber das ist meistens nicht der Fall, sagen wir immer so. Gerade vielleicht auch, wir machen ja auch in der Ausbildung viele Themen, die einem vielleicht auch später helfen, wenn man sich selbstständig machen will. Zum Beispiel als Freelancer oder wirklich komplett selbstständig unterwegs ist, vielleicht als, weiß ich nicht, Softwareentwickler oder so etwas. Und da muss man sich dann gut überlegen, wenn man gerade anfängt, kann ich mir so ein Auto leisten. Nur weil ich jetzt eine Firma bin oder habe, habe ich ja nicht einfach so, weiß ich nicht, 40.000 Euro rumflattern, um mir da so ein teures Auto zu kaufen zum Beispiel.

[4:29] Deswegen ist dann immer die Frage, was habe ich denn für Alternativen? Und wenn ich jetzt wie gesagt nicht das Geld einfach rumliegen habe, dann sprechen wir jetzt hier, wenn ich von Kauf als erste Option rede, davon, dass ich mir einen Bankkredit nehme und dann mit dem Geld das kaufe. Davon rede ich jetzt und nicht, ich habe das Geld so rumliegen. Dann brauche irgendwie uns, glaube ich, nicht so viele Gedanken über Miete oder so zu machen, weil dann haben wir genug Geld auf dem Konto, um das einfach so zu bezahlen. Aber das ist nicht das Thema. Also wenn ich mir ein Auto kaufen möchte, gehe ich zur Bank und sage hier, ich will ein Auto, 40.000 Euro, gebe dir mir einen Kredit dafür und wenn ich dann Bonität nachweise und so weiter und die mir das dann auch geben, dann äußert sich das bei mir so, dass ich ja monatlich diesen Kredit zurückzahlen muss. Das ist so die Idee eines Kredits. Irgendwann will die Bank das Geld ja wieder haben und das beginnt meistens sehr schnell. Das heißt, wir machen da normalerweise einen Kreditvertrag, der über ein paar Monate meistens aber eher Jahre läuft und damit es jetzt ein bisschen einfacher ist, machen wir einfach bei allen drei Finanzierungsformen einfach mal drei Jahre Laufzeit. Das heißt, ich will jetzt ein Auto kaufen für 40.000 Euro, geht zur Bank, gebt mir bitte 40.000 Euro und dann rechnen die aus, was ich monatlich so zahlen muss, damit nach den drei Jahren das Geld wieder an die Bank zurückgezahlt wurde. Aber das machen die natürlich nicht ganz kostenfrei. Die wollen ja nicht einfach nur ihr Geld zurück, sondern wir wollen auch was dann verdienen. Das heißt, wir bezahlen natürlich Zinsen dafür.

[5:42] Und jetzt ist es üblicherweise so, dass man, wenn man so einen Kredit hat, oder was heißt üblicherweise? Es ist oft so, man kann auch andere Sachen machen, aber oft ist es so, dass sich dann ein sogenanntes Annuitäten, Darlehen aufnehme, was bedeutet, dass ich über die drei Jahre der Laufzeit jeden Monat einen konstanten Betrag an die Bank zurückbezahle. Das heißt, das, was ich da jeden Monat überweisen muss oder was mir abgebucht wird, das ändert sich nicht alle paar Wochen oder einfach bei jeder Zahlung, sondern bleibt über die drei Jahre komplett identisch. Also beispielsweise nicht 1.000 Euro pro Monat und das bleibt von Monat 1 bis Monat 36 immer gleich. Das wäre ein Annuitätendarlehen.

[6:19] Annuität, wenn ich mich noch recht erinnere an meinen Rechnungswesenunterricht, kommt daher, weil Annus für Jahr steht und es ist immer eine gleichbleibende Zahlung, jedes Jahr identisch. So habe ich mir das damals mal gemerkt. Das wäre so das Übliche. Man kann auch variable Rückzahlraten vereinbaren, wo es dann zum Beispiel am Anfang hohe Beträge gibt, gegen Ende wird es dann weniger und so weiter und so fort. Wir gucken uns mal der einen Fall halber nur die Annuität an. Und das würde bedeuten, wenn ich über 36 Monate jeden Monat das Gleiche an Geld bezahle, dann verändert sich das Verhältnis zwischen Zinszahlung und dem Abtrag des Kredits. Denn das, was ich da an die Bank zurückbezahle, enthält ja beides. Zum einen muss ja der Kreditbetrag verringert werden, weil am Ende der 36 Monate will die Bank ja ihre 40.000 Euro zurückhaben. Auf der anderen Seite will die auch noch die Zinsen verdienen. Das heißt, in diesen Beträgen stecken immer beide Teile drin. Und wenn der über die Laufzeit immer gleich bleibt, der Betrag.

[7:13] Dann muss das heißen, dass zu Beginn der Laufzeit der Anteil der Zinsen höher ist und gegen Ende der Laufzeit der Anteil der Zinsen immer geringer wird. Das heißt, in meinen 1000 Euro, und das ist jetzt nur eine fiktive, ausgedachte Zahl, stecken vielleicht im ersten Monat 200 Euro Zinsen drin und im letzten Monat dann nur noch 20 Euro Zinsen. Und der Rest, der noch in den 1000 Euro drin ist, wird dann zum Abtrag des Kredits genommen, sodass sich jeden Monat meinen Restkreditbetrag, der noch offen ist, immer ein bisschen mehr reduziert. So läuft das üblicherweise ab, wenn ich was Teures anschaffe. Und diese Finanzierungsform, die hat jetzt bestimmte Vor- und Nachteile gegenüber Miete oder Leasing und die wollen wir uns jetzt einfach mal einmal anschauen. Wenn ich jetzt nämlich mit dem Kauf loslege und das Produkt erworben habe, dann gehört mir das. Das ist schon mal der erste wichtige Unterschied. Wenn ich jetzt mit den 40.000 Euro von der Bank zum Autohändler gehe und sage, hier, bar auf dem Tisch hast du die 40.000, wobei das ist heute nicht mehr so einfach möglich. Ich glaube ab 10.000 muss man Schwarzgeld prüfen und ich weiß nicht was. Also man überweist das dann eher oder man bezahlt die Rechnung per Banküberweisung.

[8:17] Aber wenn man das Ding dann gekauft hat, dann gehört einem das Auto. Das heißt, ich kann mit dem Auto dann machen, was ich will. Ich kann das auch gegen eine Wand fahren oder ich kann mir dann noch einen anderen, was auch immer, Audio-Player einbauen oder weiß der Geier. Das Ding gehört mir und ich kann damit machen, was ich will. Auf der anderen Seite muss ich aber auch alles Mögliche damit machen, wie zum Beispiel in die Werkstatt fahren, wenn es kaputt ist oder ich muss es reparieren. Also ja, in der Werkstatt reparieren, was auch immer. Auf jeden Fall hat das Ding ja Unterhaltskosten. Ich muss zum Beispiel auch die Versicherung selber bezahlen und so weiter, weil das Ding ja komplett mir gehört. Das heißt, ich habe alle Freiheiten, aber ich habe auch alle Verpflichtungen, die mit diesem Eigentum einhergehen. Ich muss mich halt in das Auto kümmern. Und wenn ich das nicht mache, dann macht es kein anderer. Das heißt, irgendwann wird das Ding dann klapprig, wenn ich das nicht regelmäßig zur Werkstatt bringe. Ganz blöd gesagt.

[9:01] Auf der anderen Seite kann ich halt alles mit dem Ding machen. Ich muss niemanden fragen, ob ich es umlackieren darf oder mir da noch einen dritten Auspuff anbauen darf. Ich kann damit machen, was ich will. Es gehört mir. Mit der Konsequenz, das ist auch Teil meines… Also es gehört übrigens nicht mir. wenn ich jetzt ich sage, reden wir natürlich immer vom Unternehmen. Also das Unternehmen ist natürlich dann Eigentümerin dieses Autos und das kann damit halt eben machen, was es will. Muss es dann aber zum Beispiel auch als Vermögen in der Bilanz aufführen, zum Beispiel. Also es ist dann wirklich ein Wertgegenstand, der Teil des Unternehmens ist und der muss damit aufgeführt werden und auch mit allen buchhalterischen Pflichten, die damit einhergehen, zum Beispiel eine Abschreibung machen. Weil das Auto verliert ja sehr stark auch an Wert, hast du vielleicht schon mal gehört. So, wenn man mit dem Auto vom Hof fährt, beim Autohändler ist es nur noch die Hälfte wert, so gefühlt. Ist ein bisschen übertrieben, aber ist auch ein bisschen was Wahres dran. Also Autos verlieren einfach extrem schnell an Wert. Das heißt, ich habe für 40.000 gerade ein Auto gekauft und ein Jahr später ist es, keine Ahnung, sagen wir mal noch 30.000 wert. Dann hast du zwar in der Bilanz noch ein teures Auto stehen, aber wenn du es verkaufen würdest, würdest du das Geld ja nie wieder reinbekommen. Das heißt, du hast eigentlich einen, ja, ich glaube, das nennt man dann nicht realisierten Verlust, weil du eigentlich einen Gegenstand in der Bilanz hast, der laut Buchhaltung teuer ist, aber wenn du ihn verkaufen würdest, das Geld gar nicht einbringen würde. Ja, das ist dann immer so ein bisschen blöd. Und wenn du dann kurzfristig zu Geld kommen musst, kriegst du auf jeden Fall nicht mehr das, was du eigentlich bekommen müsstest, damit das alles aufgeht.

[10:19] So, damit wir jetzt hier nicht ganz vom Pfad abweichen, dann gucke ich nochmal kurz auf meine Liste. Also Vorteil ist, das Ding gehört mir. Ich muss aber auch einige Pflichten, die damit einhergehen, umsetzen, kann es dann aber zum Beispiel auch abschreiben. Und Abschreibung ist, wie du hoffentlich schon mal gelernt hast oder wenn nicht, dann hörst du es jetzt, die Möglichkeit, wie du so einen Wertgegenstand über eine gewisse Dauer, nämlich über die Nutzungsdauer und das variiert je nachdem, was für einen Gegenstand ich da habe bei Autos. Ich weiß jetzt gar nicht auswendig, was die Nutzungsdauer ist. Ich sage jetzt einfach mal, fünf Jahre fährt man so ein Auto. Bei Häusern ist das ein bisschen anders. Die kann man auch nach 20 Jahren noch benutzen. Das heißt, je nachdem, was ich mir da gekauft habe. PCs sind, glaube ich, zwei oder drei Jahre Nutzungsdauer, bis das Ding quasi kaputt geht, ganz blöd gesagt. Wo man es ersetzen muss. Bis dahin kann ich das abschreiben. Das heißt, ich nehme den Anschaffungsbetrag und teile das durch die Nutzungsdauer in Jahren und dann kann ich jährlich diesen Betrag von der Steuer absetzen.

[11:10] Damit verringere ich quasi das Einkommen, was ich versteuern muss. Das ist also eine ganz nette Sache. Aber ich habe halt zusätzliche Kosten, weil ich Versicherung, Unterhalt und so weiter alle selber bezahlen muss. Und ich habe natürlich auch noch die Zinsen, die ich der Bank bezahlen muss. Darf man ja auch nicht vergessen. Die machen das ja auch nicht umsonst. Aber auch hier die Zinsen, die ich der Bank bezahle, weil das ja für einen Firmenwagen ist, kann ich die auch als Betriebsausgaben steuerlich absetzen. Das heißt, ich habe eigentlich steuerlich recht viele Möglichkeiten, wenn ich mir das Ding gekauft habe im Kredit. Ich kann es abschreiben und zusätzlich noch die Zinszahlung an die Bank steuerlich geltend machen. Also das hört sich erstmal ganz nett an, hat aber noch einen weiteren finanziellen Nachteil. Ich habe jetzt meinen Haufen Schulden, ganz blöd gesagt. Und so ein Auto, das ist jetzt mal ein schönes Beispiel, weil mit so einem Auto kann ich ja wirklich irgendwo gegen den Baum fahren, sagen wir mal. Und jetzt mal unabhängig davon, ob mir was passiert, da fangen wir mal aus, dass das glimpflich ausgeht. Aber wenn das Auto kaputt ist, dann habe ich jetzt ein Problem, weil ich schulde der Bank 40.000 Euro. Ich habe kein Auto mehr, mit dem ich rumfahren kann. Und jetzt stehe ich da. Was mache ich jetzt? Ich bin ja der Eigentümer des Autos. Das heißt, ich muss mich um alles kümmern. Das Ding ist kaputt. Jetzt habe ich schlechte Karten, weil ich jetzt einen Haufen Schulden habe und kein Auto, mit dem ich fahren kann. Das ist doof. Und ich kann jetzt auch keinem sagen, hey, das Auto ist kaputt. Ich hätte gerne ein neues. Stell mir das mal morgen da auf den Hof. Dann sagen die, bezahl nochmal die 40.000 Euro und dann machen wir das. Das heißt, da wird so ein bisschen klar, was jetzt die Vor- und Nachteile sind.

[12:28] Eigentum verpflichtet heißt es ja immer so schön. Und wenn ich so ein Auto gekauft habe, dann habe ich halt alle Vor- und Nachteile, weil es jetzt mir gehört. Und die Bank sagt nicht, ach, dein Auto ist kaputt. Ja Mensch, dann schenken wir dir jetzt den restlichen Kredit, den musst du nicht mehr zurückzahlen. Nee, das machen die leider nicht. Auch wenn dir ein Haus abbrennt, was du finanziert hast, musst du trotzdem deine Zinsen weiter bezahlen. Eins ist sicher, die Bank kriegt ihre Kohle wieder. Das ist auf jeden Fall mal klar. Und genau, das ist auf der einen Seite cool, so ein Kauf, weil ich kann komplett zum Beispiel auch selbst bestimmen, was für ein Auto ich eigentlich haben will. Ich kann die Farbe selbst bestimmen, die Ausstattung, das ist ja mein Auto. Ich gehe zum Auto hin und sage, ich will genau dieses Ding mit der Ausstattung, hier ist die Kohle. Das heißt, ich habe sehr viel Freiheit, aber eben auch diese Bindung, ich muss mich darum kümmern, es gehört jetzt mir, es steht in der Garage, es muss gepflegt werden und wenn es kaputt geht, muss ich mich auch darum kümmern und die Bank ist mir im Nacken, weil ich ständig Kreditzinsen zahlen muss und so weiter. Also das ist so in der Nutshell, was den Kauf ausmacht. Also grundsätzlich erstmal nicht gut oder schlecht. Es hat jede dieser Finanzierungsformen, die wir uns angucken, Vor- und Nachteile. Und die haben wir jetzt mal so grob für den Kauf durchgesprochen. Das heißt, fassen wir mal kurz zusammen. Wie sieht es beim Kauf aus?

[13:37] Normalerweise, das habe ich noch gar nicht erwähnt, ist ein Kauf immer günstiger als Liete oder Miesing. Ja genau, als Miete oder Leasing.

[13:46] Die anderen Formen gehen wir gleich nochmal durch. Aber langfristig kann man sagen, wenn ich das Auto über einen gewissen Zeitraum nutze, dann ist das grundsätzlich immer billiger als die andere Finanzierungsformen. Kannst du dir ganz einfach überlegen, auch wenn du das Auto deutlich länger nutzt, als du es vielleicht abschreibst, dann fährst du das Auto ja irgendwann für 0 Euro, ganz blöd gesagt. Alle Kreditzinsen sind zurückgezahlt, abgeschrieben. Du kannst das Auto aber trotzdem noch weiterfahren. Ein Auto muss nicht nach drei Jahren ersetzt werden. Das fährt auch mal 20 Jahre. Und in der Zeit, wo die Kreditzinsen abgezahlt sind, fährst du das Auto quasi für umsonst. Sprit und Versicherungszahlen sind natürlich trotzdem, klar. Aber die Finanzierung ist halt abgeschlossen. Und das hättest du bei Miete und oder Leasing nicht ein bisschen eingeschränkt. Da kommen wir gleich noch drauf. Also Kauf, wenn du es langfristig machen willst, günstiger als die anderen beiden Formen. Du hast die volle Kontrolle, du hast keinerlei Vertragsbindung oder sonst irgendwas. Du kannst genau sagen, was für ein Auto du haben willst und das morgen zum Umlackieren bringen. Ganz egal.

[14:40] Wie gerade schon gesagt, du kannst das Ding abschreiben, du kannst die Zinsen steuerlich geltend machen und du kannst auch mit dem Auto machen, was du willst. Also du hast zum Beispiel keine Einschränkung, dass du maximal, weiß ich nicht, 10.000 Kilometer im Jahr damit fahren darfst. Und du kannst damit machen, was du willst. Es ist dein Auto. Du kannst auch Urlaub im Ausland machen, sofern der Urlaub betrieblich Hintergründe hat natürlich. Ja, sonst gibt es mal wieder ganz andere steuerliche Probleme. Also wenn man jetzt wirklich mit dem Auto nur betrieblich unterwegs ist, dann gilt das ja alles. Fahre ich damit auch nur in Ansätzen mal privat durch die Gegend, dann haben wir ein ganz anderes Thema. Ich bin übrigens kein Steuerberater, sage ich mal ganz kurz zwischendurch. Aber hier geht es ja nur um das, was wir für die Prüfung wissen müssen und nicht, was nachher auf der Steuererklärung steht.

[15:16] So, ein Nachteil ist allerdings diese hohe Anfangsinvestition. Auto, 40.000 Euro muss ich erstmal auf den Tisch legen. Kann ich mir von der Bank holen? Ja. Aber wie gesagt, dann habe ich erstmal 40.000 Euro minus irgendwo auf dem Kreditkonto stehen. Da muss man auch mit umgehen können, dass man der Bank so viel Geld schuldet. Außerdem, wie gerade schon gesagt, fahre ich mit dem Auto von der Hof, ist es nur noch die Hälfte wert. Das heißt, ich habe einen hohen Wertverlust. Wenn ich an das Geld wieder ran will, kriege ich es kurzfristig zumindest nicht in der Höhe zurück, wie ich es bräuchte, weil das Auto halt einfach super schnell an Wert verliert. Noch schlimmer ist es ja bei, weiß nicht, wenn ich mir einen Laptop kaufe oder so. Die kann ich ja direkt verschrotten, ganz glücklich sagen, wer kauft sowas gebraucht für viel Geld. Das kriegt man ja einfach nie wieder, was man dafür ausgegeben hat. Und ich muss mich halt darum kümmern. Also Wartung, Versicherung etc. Ist alles bei mir. Das nimmt mir keiner ab. Das ist so zusammengefasst Vor- und Nachteile eines Kaufes.

[16:04] So, dann würde ich sagen, als nächstes kommen wir zur Miete. Und ich denke mal, dass du Miete irgendwo aus einem anderen Kontext sicherlich schon mal gehört hast. Also muss man wahrscheinlich nicht lange erklären, was das ist, wenn du eine Wohnung mietest oder eben ein Auto mietest. Macht man jetzt nicht so häufig als Privatperson, vielleicht mal für einen Urlaub oder so, mietet man sich ein Wohnmobil oder einen großen Van oder was auch immer. Also das ist damit gemeint. Es gibt hier keine Special-Miete für Unternehmen oder sonst irgendwas. Es geht einfach darum, ich glaube, das heißt dann sowas wie kurzfristige Nutzung gegen regelmäßige Zahlung oder irgendwie so ist das definiert oder Überlassung zur Nutzung oder irgendwie. Also es gibt da so einen lustigen rechtlichen Begriff, wie das dann definiert ist. Aber du weißt, was gemeint ist. Du leihst dir von irgendwem irgendwas, ein Auto, eine Wohnung, einen Computer und zahlst ihm dafür regelmäßig Geld. So, das ist erstmal die Miete und das hat erstmal einen großen Vorteil, was die Flexibilität angeht, weil du könntest relativ schnell auch sagen, ich habe keinen Bock mehr, das zu mieten, ich bin jetzt wieder raus. Bei einer Wohnung hat man da üblicherweise Kündigungsfristen, okay, keine Ahnung, drei Monate oder sowas, dann ist man raus, aber wenn du es jetzt vergleichst, du kaufst dir ein Haus oder du mietest ein Haus, dann bist du sicherlich sehr viel flexibler, wenn du es mietest, weil du einfach kurzfristig sagen kannst, so, ich ziehe um, ich will weg und dann bist du halt raus. Und kurzfristig drei Monate im Vergleich zu ich muss ein Haus verkaufen und.

[17:21] Kredit umschichten und ich weiß nicht, was da alles hinterhängt. Das ist alles andere als einfach und kurzfristig möglich. Also Miete, super flexibel. Ich kann heute sagen, hey, ich brauche heute Nachmittag einen Firmenwagen, weil ich irgendwie zu einer Messe fahren will. Und dann gehe ich zu irgendeinem großen Anbieter und miete mir da ein Auto, bezahle da ein bisschen Geld und dann habe ich das Auto und kann damit losfahren. Also super kurzfristig. Morgen bringe ich das Auto zurück, bin jetzt wieder los quasi. Das ist ein Riesenvorteil. Große Flexibilität Und normalerweise sind diese Mietverträge auch wirklich nicht langfristig, sondern eher kurzfristig. Also vielleicht Wochen, vielleicht Monate. Aber wir reden hier üblicherweise nicht von Jahren, sondern es sind deutlich kürzere Laufzeiten üblicherweise. Großer Vorteil ist dann natürlich, ich muss nicht Anfangsinvestitionen haben von x-tausend Euro, sondern Ich meine, Mietwagen sind jetzt auch nicht günstig. Vielleicht hast du ja immer schon mal einen gemietet irgendwo im Urlaub oder so. Da reden wir jetzt auch von zig oder eher 100 Euro am Tag oder so, wenn man ein vernünftiges Auto mietet. Aber es ist natürlich immer noch deutlich günstiger, als wenn ich erstmal 40.000 Cash auf den Tisch legen muss, um ein fertiges Auto zu kaufen. Ja, von daher, ich habe keinen hohen Anfangsinvest und das ist tatsächlich für viele Unternehmen wichtig, gerade vielleicht als Startup oder wenn du selber dich selbstständig machst. Wie gesagt, am Anfang 40.000 mal eben für so ein Auto, wo soll das Geld herkommen, wenn du gerade aus der Ausbildung kommst oder so? Ist schwierig, aber mal eben mieten, das ist dann schon eher drin, vor allem, wenn man es auch kurzfristig wieder zurückgeben kann und die Miete nicht mehr zahlen muss. Ja, ist sehr flexibel, wie gesagt.

[18:45] Außerdem, großer Vorteil, du musst dich normalerweise überhaupt nicht um die Instandhaltung kümmern. Kennst du vielleicht von der Wohnung, aber auch beim Auto ist es so, wenn du Miete, einen Mietwagen hast, du musst da am Ende nicht in die Werkstatt fahren, wenn es kaputt ist. Dann sagst du einfach, ich habe ein Auto gemietet, hier, ich hätte gerne Neues, das ist kaputt. Ja, dann bringst das zur Werkstatt und kriegst einen Ersatzwagen quasi. Das heißt, du musst dich nicht um die Versicherung, um die, weiß ich nicht, Kfz-Steuer und Schlagmilchtod kümmern. Du bezahlst einfach Betrag X und kriegst quasi Full Service. Hier ist das Auto, mach damit, was du willst. Sprit musst du meist noch bezahlen, okay, aber das war es dann auch. Das heißt, du musst dich um das Ding nicht kümmern. Und wenn es kaputt ist, ist ja nicht dein Auto. Genau wie in der Wohnung. Wenn in deiner Wohnung die Heizung kaputt geht, dann musst du dich auch nicht als Mieter darum kümmern, dich zu reparieren, sondern das macht der Vermieter, weil das ist ja seine Heizung, der das da vermietet.

[19:28] Und demnach hat das entsprechend auch Vorteile, wenn du halt irgendwie kurzfristig was brauchst, gehst du da hin, mietest das eben, ich weiß nicht, gibst eine Woche später zurück und sehr flexibel und üblicherweise auch nicht allzu teuer, diese Miete. Aber jetzt kommt der krasse Nachteil, wenn es dir um langfristige Sachen geht, ist die Miete normalerweise das Teuerste, was du machen kannst. Denn weil die Mietverträge meistens halt nur kurzlebig sind, wollen die natürlich auch ein bisschen Geld damit verdienen. Das ist natürlich viel cooler für jemanden, wenn er dir für fünf Jahre ein Auto vermietet und regelmäßig dieses Einkommen hat, was du da zahlen musst, als wenn irgendwie jede Woche jemand anders kommt und du dich auch noch darum kümmern musst, neue Kunden zu finden. Und dann ist das eine Woche mal nicht vermietet und dann kriegst du gar kein Geld und das ist natürlich für den Vermieter auch wieder schwierig. Deswegen ist normalerweise diese Flexibilität oder bezahlst du diese Flexibilität mit einer höheren Mietrate, als wenn du das Ding kaufst oder liest, wo wir dann gleich zukommen.

[20:23] Außerdem, Nachteil, wenn das für dich irgendwie relevant ist, du hast normalerweise gar kein Mitspracherecht, was das Auto angeht, wie es aussieht, du kannst dir da nicht einfach noch einen, ich habe keine Ahnung von Autos, einen zweiten Vergaser einbau, wollte ich gerade sagen, aber ich glaube nicht, dass das irgendeinen Sinn ergibt. Also du kannst es nicht umlackieren oder sonst was an dem Auto machen. Es gehört dir ja nicht. Du leistest dir nur aus. Du mietest es und du hast dementsprechend als Unternehmen auch keine Möglichkeit, das irgendwie abzusetzen oder so, weil es ist ja nicht dein Auto. Also abschreiben funktioniert nicht. Was du natürlich sehr wohl machen kannst steuerlich, ist die Mietraten. Die kannst du abschreiben. Das sind ja Zahlungen, die du für dein Unternehmen tätigst. Du brauchst dieses Firmenauto, damit du durch die Gegend fahren kannst. Und das kannst du genau wie die Kreditzinsen beim Kauf einfach steuerlich absetzen und das senkt dann dein Einkommen. Du musst halt weniger Steuern zahlen. Also das ist genauso möglich und weil die Mietraten ja auch relativ hoch sind, sparst du damit vielleicht dann entsprechend ein bisschen Steuern. Das kann halt sein.

[21:15] Ja, das wären so die Nachteile. Das heißt, wenn wir es nochmal zusammenfassen, so Miete, da geht es ja darum, es ist eher dafür ausgelegt, dass du kurzfristig irgendeinen Bedarf dort deckst, wie zum Beispiel beim Auto. Ich muss heute mal irgendwie eine Woche weg und nächste Woche brauche ich das Auto aber gar nicht mehr. Steht nur auf dem Hof. Ja, dann mietest du es dir halt. Das Auto gehört dir aber nicht. Das nochmal kurz, hatte ich glaube ich schon in einem anderen Podcast, den Unterschied zwischen Eigentum und, wie ist es, Besitz. Wenn ich eine Sache besitze, also in meinem Besitz befindlich ist, dann habe ich den Zugriff auf dieses Ding. Ich habe zum Beispiel einen Autoschlüssel und fahre mit dem Auto durch die Gegend. Aber das heißt, dass mir das Auto auch gehört. Das wäre dann das Eigentum. Und das Auto bleibt Eigentum des Vermieters. Du kannst 0,0 bestimmen, was der mit diesem Ding macht, ob er es wartet, versichert und repariert. Das ist alles nicht deine Aufgabe und du hast auch gar kein Recht. Du hast es dir nur ausgeliehen. Also in dem Moment bist du der Besitzer dieses Autos. Du fährst damit durch die Gegend, aber es gehört dir halt nicht. Und dementsprechend darfst du auch nichts bestimmen, was mit diesem Auto passieren soll langfristig. Ob es umlackiert wird oder nicht oder ob in eine andere Anlage eingebaut wird. Also für kurzfristige Sachen super. Es ist mega flexibel. Du kannst schnell wieder loswerden, aber es ist üblicherweise auch super teuer, wenn du es langfristig machen möchtest. Das wären so kurz zusammengefasst die Vor- und Nachteile von Mieten.

[22:35] So, dann kommen wir noch zum letzten Punkt und das ist ja der Grund, warum ich eigentlich heute hier die Podcast-Episode, ich habe es heute irgendwie, ich weiß auch nicht, aufnehme und zwar Leasing. Und ich habe das in der Reihenfolge gemacht, weil Leasing eigentlich nur eine besondere Form der Miete ist. Also es gibt da zwar Leasing-Verträge, aber eigentlich gibt es rechtlich, es gibt ja so ein paar Vertragsformen, dazu habe ich übrigens schon mal eine eigene Podcast-Episode gemacht, auch interessant für die RP1, sowas wie Kaufvertrag und Arbeitsvertrag und so weiter. Und es gibt keinen eigenen Leasing-Vertrag, sondern es ist eigentlich ein Mietvertrag mit besonderen Vereinbarungen. Das heißt, hier geht es darum, mal ganz kurz zusammengefasst, dass ich irgendein Ding und meistens ist es halt was Teureres, wie zum Beispiel ein Auto oder eine große Maschine. Aber man kann zum Beispiel, habe ich glaube ich auch gesehen, inzwischen Kaffeemaschinen leasen, also die teure. Hier die 1000 Euro Espresso, Schlag mich tot, Siebdruck. Siebdruckmaschine, Sieb. Wie heißt das? Ich habe keine Ahnung von Kaffee.

[23:30] Siebgussmaschine. Du weißt wahrscheinlich, was ich meine. Also teure Kaffeemaschine kann man inzwischen glaube ich auch leasen oder ein Thermomix. Eine Heizung kann man auch schon leasen im privaten Umfeld.

[23:41] Und es geht also grundsätzlich eher darum, dass ich ein bisschen teurere Sachen mir lease und dann eben auch langfristig, um das mal zu unterscheiden von der Miete. Wir hatten ja gerade gesehen, dass Miete sich relativ kurz vor sich anpassen lässt und es eher nicht dafür geeignet ist, dass ich mir ein Auto für 20 Jahre miete, weil dann kann ich es einfach viel besser kaufen. Sondern beim Leasen geht es darum, dass ich über schon eine längere Zeit etwas miete und dann auch üblicherweise feste Raten vereinbare. Und das ist auch ganz oft der Fall am Ende dieser Laufzeit, ich auch die Option bekomme, das Ding doch zu kaufen. Das heißt, wenn ich ein Auto lease und das läuft über drei Jahre zum Beispiel, dann kann ich nach den drei Jahren für den Restwert des Autos das Ding vom Verleaser, würde ich schon sagen, vom Leasinggeber kaufen. Übrigens, der dir das Ding verliest, heißt halt eben Leasinggeber. Und ich, wenn ich das Auto lease, bin ich der Leasingnehmer. Und ich habe als Leasingnehmer ganz oft, das ist nicht immer so, aber oft habe ich so eine Vorkaufsoption. Das heißt, wenn das Ding nach den drei Jahren verkauft werden soll, dann bin ich der Erste, der das vielleicht bekommt, wenn ich es denn möchte. Ich muss es aber nicht kaufen. Das ist ganz oft so, sondern ich kann es auch zurückgeben. Das heißt, ich könnte sowas machen wie alle drei Jahre lease ich mir ein neues Auto und dann habe ich halt alle drei Jahre ein neues Auto. Ja, ist doch ganz cool. Und danach gebe ich es zurück. Und wenn ich irgendwann sage, boah, das Auto gefällt mir so gut und es ist noch im Top-Zustand, ich will das jetzt kaufen, dann kann ich es halt für den Restwert noch kaufen. So ist so grob der Ablauf beim Leasing.

[25:04] Und weil es halt langfristig ist und der Leasinggeber halt dauerhaft quasi mit den Einkünften rechnen kann und nicht alle Nase lang das Ding neu vermieten muss zum Beispiel, sind die Raten üblicherweise auch deutlich geringer als bei Miete. Dafür habe ich halt eine längere Laufzeit. Das heißt, der Leasinggeber hat, sage ich mal, ein regelmäßiges Einkommen. Du als Leasingnehmer hast geringere Raten, hast aber auch weniger Flexibilität, weil die Laufzeit von einem Leasingvertrag ist halt üblicherweise, ich sage jetzt mal beim Auto, drei Jahre. Das heißt, du bist auf drei Jahre an den Vertrag gebunden. Du kannst dann auch nicht nach einem Jahr sagen, so jetzt habe ich keinen Bock mehr auf das Auto, ich gebe dir das zurück. Vertrag ist Vertrag, der läuft drei Jahre, also zahlst du auch drei Jahre und kommst dann nicht jetzt vorzeitig raus. Zumindest ist das ganz oft der Fall.

[25:44] Vorteile von diesem Leasing ist quasi in Teilen das, was du bei Miete hast, nämlich du hast eine geringe Anfangsinvestition, du musst wieder nichts auf den Tisch legen, du machst halt nur einen etwas längerfristigen Vertrag. Die Raten sind ein bisschen niedriger als bei der Miete, dafür halt eben längere Laufzeit. Ist etwas nachteilig, gerade wie schon gerade erklärt. Dafür hast du aber deutlich besser planbare Kosten, weil das hatte ich, glaube ich, gerade bei der Miete noch gar nicht gesagt. Aber Miete kann auch kurzfristig angehoben werden. Meistens ist das so. Kann auch gesenkt werden, aber meistens geht es nach oben. Das heißt, wenn der Vermieter sagt, so Leute, war schön mit dem Auto, aber ab nächster Woche kostest du das Doppelte, dann bezahlst du halt das Doppelte. Und das ist für dich als Mieter oder Mieterin nicht so schön damit zu planen. Man wünscht sich ja nicht, dass ständig da irgendwelche Kosten nach oben gehen. Und du wusstest das vorher nicht, kann bei der Miete aber theoretisch passieren, außer du hast irgendwo im Betrag vereinbart, dass das nicht passiert, aber das ist nicht üblich, soweit ich weiß. Das heißt, es kann sein, dass du auch über die Zeit immer mehr Miete zahlen musst. Beim Leasing ist es anders, da hast du einen festen Betrag, so ein bisschen wie beim Annuitätendarlehen. Du sagst, für die nächsten drei Jahre zahle ich monatlich x und dann bleibt das auch x und dann wird das nicht irgendwann x plus y, sondern es bleibt bei x. Das ist also schön planbar für dich, aber auch für den Leasinggeber natürlich.

[26:58] Die Kosten für die Leasingraten kannst du, genau wie bei der Miete übrigens und bei den Zinszahlungen beim Kauf, auch absetzen. Das heißt, wenn wieder Betriebsausgaben mindern dein Einkommen, weniger Steuern, aber halt nicht ganz so stark wie bei der Miete, weil die Mietzahlungen halt normalerweise höher sind als beim Leasing. Dafür ist aber der Vorteil, und deswegen machen das auch viele so gerade bei Firmenwagen, du könntest halt nach drei Jahren sagen, so ich lasse das Ding auslaufen, Auto geht zurück, ich hole nur das nächste Auto, das ich wieder lease. Das heißt, du hast theoretisch alle drei Jahre dann ein niegelnagel neues Auto stehen, mit dem du weitermachen kannst. Kannst du bei Miete natürlich auch, kannst sagen, komm, ich gebe den Mietwagen zurück und ob nächste Woche nehme ich eine Stufe besser oder ein anderes Auto oder was auch immer. Klar, geht auch. Das kannst du bei Miete halt sogar noch kurzfristiger. Aber wenn dein Plan fällt, ist das Ding etwas langfristiger zu nutzen. Beim Leasing ginge das auch, dann halt aber nur alle drei Jahre. Wenn der Vertrag drei Jahre läuft, gibt es ja auch welche, die kürzer oder länger laufen.

[27:51] Nachteil für dich, du hast halt über mehrere Jahre so einen Vertrag anhacken und gerade wenn es dir dann vielleicht wirtschaftlich mal nicht so gut geht, können auch die geringeren Leasingraten im Vergleich zur Miete immer noch ziemlich hoch sein. Das heißt, du bist dann wirklich gebunden und du kommst da auch nicht vorher raus, du musst das Ding weiter bezahlen und das sollte man sich halt gut überlegen, ob man hohe Kosten über so eine lange Laufzeit ohne irgendeine Möglichkeit hat, da rauszukommen. Das ist manchmal, ja, muss man sich gut überlegen, sagen wir so. Außerdem im Vergleich zum Kauf ist Leasing natürlich trotzdem teurer. Denn diese Vorkaufoption, was ich da gerade sagte, am Ende der drei Jahre, ist das Auto natürlich nicht mehr das wert, was es zu Beginn der Zeit war. Und natürlich kriegen die Leasinggeber, ich will da jetzt niemandem zu nahe treten, aber die kriegen das schon hin, dass sie das so rechnen, dass sie noch ein bisschen Gewinnball machen. Das ist klar. Also der Wertverfall, der darunter gerechnet wird, der ist in der Realität schon ein bisschen höher als das, was man am Ende dann noch zahlen muss. Das heißt, am Ende zahlst du schon ein Bewerb. Ein bisschen drauf, sagen wir mal so. Du musst jetzt nicht den vollen Preis bezahlen, aber du bezahlst auch nicht das, was das Ding noch wirklich wert ist, sondern schon noch ein bisschen mehr. Also im Vergleich zum Kauf zahlst du drauf, dafür hast du aber die Option, das Ding zu kaufen. Wenn du es nicht kaufen willst, gibst du es halt zurück. Also eine gewisse Flexibilität hast du da ja auch und kannst es dann aber auch übernehmen und dann alles, was damit einhergeht. Also kannst du noch den dritten Auspuff dran bauen und was auch immer.

[29:13] Und was aber jetzt das Leasing nochmal auch interessant macht, ist, dass man auch ein bisschen mehr Mitspracherecht hat. Weil wenn du halt so einen langfristigen Vertrag machst, zum Beispiel über drei Jahre, dann kannst du halt auch sagen, ich hätte gern das Auto mit dieser Ausstattung und hier noch einen Ledersitz und da noch einen fünften Auspuff. Und dann stellen die dir das Auto so ein bisschen so zusammen, als würdest du es kaufen.

[29:30] Weil du dich ja auch langfristig daran bindest. Deswegen hast du auch mehr Mitspracherecht. Und nicht so ein Ding, was du für eine Woche mietest. Da bauen wir dir nicht extra noch ein cooles Audiosystem ein, nur weil du es gerne mal mieten willst für eine Woche. Beim Leasing ist das anders. Das ist ein langfristiger Vertrag. Das heißt, da kann dann auch drinstehen, hier, wir mieten genau dieses Auto mit dieser Sonderausstattung etc. Und dann ist es halt auch noch attraktiver nach den drei Jahren, das Ding zu kaufen, weil es ja genau dem entspricht, was du dir mal ausgesucht hast. Also durchaus individualisierbar, aber zentraler Nachteil, lange vertragliche Bindung und insgesamt sind die Kosten höher. Also wenn du eh denkst, dass das Auto ein paar Jahre länger fährst als die drei Jahre, dann ist ein Kauf auf jeden Fall immer noch günstiger, als das mit Leasing zu finanzieren.

[30:10] So, das war jetzt erstmal die Theorie dieser drei Finanzierungsformen. Kauf, Miete und Leasing, wobei Leasing eigentlich nur so eine Special-Form von Miete ist. Und jetzt natürlich die Frage, wie können Aufgaben in der Prüfung aussehen? Also zum einen mal so ein bisschen den Hintergrund, weiß nicht, kleine Frage für zwei Punkte, was ist eigentlich Leasing oder was ist besser, Miete oder Leasing oder so? Und natürlich gibt es nicht das eine, das besser ist, sondern es kommt immer auf den… Konkreten Faller. Standardantwort kommt drauf an. Da muss man gucken, wie sieht es denn aus? Was ist das für ein Unternehmen? Wie lange wollen sie das Ding benutzen? Etc. Das heißt, man muss sich dann immer anschauen, wenn ich mir jetzt überlege, was mache ich denn jetzt?

[30:44] Welche Kriterien gibt es denn, um die Entscheidung zu treffen? Und dann kann ich mir sowas angucken, wie sieht denn das Budget aus? Wie viel Geld liegt denn auf dem Konto? Will ich 40.000 auf den Kopf hauen oder will ich das lieber in kleinen Raten zahlen? Will ich mich lange binden? Brauche ich eine Flexibilität? Wie lange will ich das Ding überhaupt benutzen? Brauche ich nur ein Auto, um einmal zur Messe zu fahren oder will ich das die nächsten zehn Jahre fahren? Brauche ich Flexibilität? Will ich alle drei Jahre oder sogar alle zwei Wochen ein neues Auto haben? Oder reicht mir das, für die nächsten 20 Jahre dasselbe Auto zu fahren, weil ich keinen großen Wert auf irgendwelche geilen neuen Features lege oder sowas? Und vor allem auch, wie sieht es denn steuerlich aus? Also kann ich das alles absetzen? Wie hoch genau ist das, was ich absetzen kann? Lohnt sich das für mich? Etc. Und das sind alles Kriterien, die ich mir anschauen sollte und die dann, wenn sowas in der Prüfung drankäme, auch sicherlich vorgegeben wären. Das weiß ich ja nicht, dass das Unternehmen dafür für Präferenzen hat, logischerweise. Also da muss man genau dann drauf schauen und dann kann man einen Vorschlag machen, was man dann vielleicht machen sollte.

[31:44] Alternativ gibt es auch Aufgabestellungen, wo das einfach mal ausgerechnet werden soll mit gegebenen Zahlen. Da stellen wir sowas wie hier, Sie vergleichen den Kauf für 40.000 Euro, drei Jahre, drei Prozent Zinsen oder sowas, vergleichen Sie mit einer Leasingrate von monatlich, weiß ich, 500 Euro. Mit Restwert so und so viel. Und da muss man einfach mal für die drei Jahre ausrechnen, was kostet er denn jetzt? Was zahle ich insgesamt an Leasing? Was zahle ich an Zinsen bei dem Kauf und so weiter? Und was sind dann meine Gesamtkosten am Ende? So ein bisschen dieses Total Cost of Ownership, TCO. Wenn ich jetzt Miete, Leasing, Kauf mache bei diesem Auto, was ist der Endbetrag, den ich nach den drei Jahren gezahlt habe? Und da kommt halt beim Kauf, zahle ich einmal was plus die Zinsen. Leasing zahle ich halt 36 Monate dasselbe. Miete kann vielleicht eine Mieterhöhung dazwischen sein oder wie auch immer. Das heißt, das sind unterschiedliche Berechnungsformen, was ich da machen muss. Am Ende ist es aber meistens nur ein bisschen multiplizieren und mal rechnen und Prozent rechnen. Also das sind jetzt keine schwierigen Matheaufgaben. Aber im Kontext von Miete, Kauf, Leasing kann man halt so schön, ja, kleine Rechenaufgaben einstreuen, die halt auch einen Bezug zur Realität haben. Und deswegen glaube ich, nehmen die das auch so gerne. Deswegen ist Leasing zumindest auf meiner Themenliste sehr weit oben. So würde ich mir das zumindest erklären.

[32:55] Und ja, ich habe jetzt auch mal für die Show Notes ein kleines Beispiel durchgerechnet. Das sind jetzt halt alles fiktive Zahlen. Also Zinssätze bei den Banken ändern sich ja täglich. Leasingraten grob zu schätzen ist auch super schwierig. Also da muss man sich schon konkrete Vergleichsangebote anholen. Also mit irgendwas muss man ja rechnen. So wäre es in der Prüfung dann auch. Also Beispiel, weiß ich nicht. mit der Miete anfange, kostet vielleicht meine Monatsmiete 1200 Euro und einfach nur, um das mal ins Verhältnis zu setzen, so eine Leasingrate läge dann vielleicht bei 500 Euro. Also es ist halt schon deutlich geringer, aber selbstverständlich findest du wahrscheinlich auch Mietwagen, die mehr oder weniger kosten als diese 1200 und Leasingverträge, die günstiger sind oder teurer auch. Nur, du musst halt immer auch gucken, was zahle ich noch zusätzlich, denn bei dir, da ist das erstmal ein teurer Betrag, aber ich muss ja auch nichts weiter bezahlen. Das ist ja quasi Full Service. Ich muss das Ding nicht warten. Ich brauche keine Versicherung, keine Steuer. Wenn das Ding kaputt ist, muss ich mich nicht kümmern. Beim Leasing ist das schon ein bisschen anders. Üblicherweise zahle ich dann so die Kosten für den Unterhalt wie Versicherung und Wartung schon selber. Beim Kauf bezahle ich aber zum Beispiel alles selber dann. Also auch wenn das Ding von Baum fährt und so. Das heißt, da muss ich mir schon wirklich Gedanken machen, was sind denn wirklich die Kosten, die da konkret überall anfallen.

[34:06] Und in diesem fiktiven Beispiel wäre es jetzt so, dass die Monatsmiete mit 1200 Euro zwar sehr hoch ist und wenn ich die über 36 Monate zahle, bin ich halt bei 1200 mal 36, also irgendwas mit 43.000 Euro oder so. Dafür habe ich aber gar keine langfristige Bindung. Ich kann jederzeit sagen, so Leute, kein Bock mehr auf das Auto, ich brauche es nicht mehr oder ich will ein anderes. Ich habe keine weitere Bürokratie mit irgendwelchen Steueranmeldungen und ich brauche noch ein Nummernschild und diesen ganzen bürokratischen Kram. Da muss ich mich null drum kümmern. Das darf man ja auch nicht vergessen. Das sind ja sogenannte Opportunitätskosten. Die Stunde, die der Unternehmer auf dem Amt steht und sein Nummernschild anmeldet, in der Stunde kann er kein Geld verdienen. Das heißt, theoretisch müsste er dafür seinen Stundensatz anrechnen für dieses, ich muss mal eine Stunde lang ein Kfz-Kennzeichen anmelden. Und das machen natürlich viele Leute nicht, aber eigentlich müsste man das machen, um wirklich realistische Preisvergleiche zu haben. Und dann ist Miete auf einmal gar nicht mehr so teuer, wenn man das alles auch noch mit einrechnet, wo man sich nicht kümmern muss. Die jährliche Versicherungsgeschichte und oh, die Versicherung ist teurer geworden, ich muss den Vertrag wechseln, da muss ich erstmal recherchieren. Und Eigentum verpflichtet. Eigentum hört sich toll an. In der Realität muss man aber auch viel Zeit da reinstecken. Und Zeit ist Geld. Kann man also auch gegenrechnen.

[35:18] Trotzdem hat Miete natürlich Nachteile. Ist super teuer. Langfristig keine Frage, wenn ich das Ding 20 Jahre fahre, 20 Jahre Mietwagen, da bezahlt man sich natürlich dumm und dusslich. Das ist keine Frage. Und man hat auch null Mitspracherecht, weil einem das Ding halt nicht gehört, wie eben schon beschrieben.

[35:31] Bei Leasing, angenommen, ich müsste 500 Euro Leasingrate zahlen jeden Monat.

[35:36] Da kommt aber noch was dazu für Wartung und Versicherung, muss ich halt selber übernehmen und deswegen, wenn ich das jetzt ausrechne, habe ich die Leasingrate plus alles, was ich selbst bezahle im Monat und nehme das mal 36 und dann bin ich jetzt mal in diesem fiktiven Beispiel irgendwie bei 23.000 statt 43, habe dann aber nach den drei Jahren vielleicht die Option, das Ding zu kaufen für, sagen wir mal, die Hälfte des Preises, also 20.000. Das ist jetzt alles ausgedacht, wie gesagt. Normalerweise ist der Preis wahrscheinlich ein bisschen über der Hälfte, weil der Leasinggeber will ja noch ein bisschen was verdienen. Und wenn ich das jetzt zusammenrechne, also Restwert, ich übernehme das Auto plus das, was ich vorher gezahlt habe, bin ich halt irgendwie auch so ungefähr bei 43.000. Mit dem kleinen Vorteil eigentlich, dass mir das Auto jetzt gehört und ich danach jetzt genau 0 Euro weiterzahlen muss, weil ich halt alles schon abgezahlt habe. Dafür hatte ich langfristig jetzt über die drei Jahre hinweg eine niedrigere monatliche Belastung im Vergleich zur Miete auf jeden Fall. Habe aber eben von Anfang an diesen Drei-Jahres-Vertrag unterschrieben. Und wenn jetzt irgendetwas Unvorhergesehenes passiert wäre, wäre ich aus dem Vertrag nicht rausgekommen. Hat also auch Nachteile, darf man nicht vergessen. Wenn ich das Auto zurückgebe und es nicht übernehme, heißt das auch nicht, dass ich da kostenfrei rauskomme. Denn wenn zum Beispiel, wie heißt das, im Vertrag steht dann üblich sowas wie, übliche Gebrauchspuren sind okay, aber wenn ich, weiß ich nicht, zum Beispiel einen Steinschlag im Auto habe oder es ist der Lack ein bisschen angekratzt oder so, dann wird der Leasinggeber bei dem Rücknehmen natürlich sagen, ach Mensch, hier, da muss aber neu lackiert werden.

[37:03] Also die wissen natürlich auch, wie sie Geld verdienen können. Das heißt nicht, dass ich nach den drei Jahren gar keine Kosten mehr habe, wenn ich das Auto zurückgebe. Je nachdem, wie pfleglich ich damit umgegangen bin. Muss man auch überlegen. Letzter Punkt, Kauf mit Kreditfinanzierung, rechnen wir mal 3%, auch wieder Laufzeit 3 Jahre, dann zahle ich den Kredit 40.000 Euro plus 3% Zinsen, 3 Jahre, zahle ich 1.160 Euro im Monat. Das ist jetzt ein Annuitätendarlehen, also immer gleichbleibender Betrag. Das heißt, insgesamt zahle ich für die 40.000 Euro 41.760 Euro. Das ist halt inklusive Zinsen. Aber auch da muss ich ja noch was dazu rechnen, nämlich Wartung und Versicherung zum Beispiel fürs Auto muss ich auch wieder selber bezahlen. Das bezahlt die Bank mir ja nicht oder sonst wer, weil das Auto gehört ja jetzt mir. Das heißt, da muss ich noch ein bisschen was draufrechnen. Das ist also auch gar nicht mal so günstig. Und jetzt kann ich mir natürlich überlegen, das Auto gehört mir. Wenn ich jetzt nach drei Jahren keine Lust mehr auf das Auto habe, ja, dann verkaufe ich das halt. Und dann ist halt die Frage, was kriege ich halt noch dafür?

[38:03] Und man kann ganz pauschal sagen, der Leasinggeber beim Leasing wird das Ding wahrscheinlich möglichst teuer rechnen. Und wenn ich das Ding jetzt aber verkaufe am Markt, werden meine Kunden mir das natürlich möglichst billig rechnen. Die wollen natürlich nicht viel Geld dafür bezahlen, das ist ja klar. Das heißt, es ist immer so eine gewisse Unbekannte. Wenn ich das Auto verkaufe, wie viel kriege ich wirklich noch dafür? Und wenn ich es dem Leasinggeber zurückgebe, was wird der denn noch dafür haben? Und der wird wahrscheinlich mehr nehmen, als ich bekommen würde, wenn ich es selber verkaufen würde. Von daher schwer zu sagen, aber angenommen, wir hätten den gleichen Wert wie beim Leasing, also auch 20.000 Euro.

[38:33] Dann würde ich die halt auf dem Markt dafür bekommen und dann hätte ich nach drei Jahren zwar kein Auto mehr, weil ich habe es ja gerade verkauft, dafür aber natürlich insgesamt auch den günstigsten Preis am Ende, nämlich 27.000 Euro. Das heißt, vergleichen wir jetzt so ein bisschen Äpfel mit Bieren, weil wenn ich beim Leasing das Auto kaufe und beim Kauf das Auto wieder verkaufe, das ist natürlich klar, dass das günstiger ist. Das ist schon logisch. Also wenn wir jetzt mal alles zusammenrechnen für die drei Jahre und ich behalte das Auto, dann ist tatsächlich der Kauf sogar noch am teuersten. Tatsächlich, weil ich habe einen hohen Anfangsinvest, ich habe die Zinsen, die ich zahlen muss, ich habe zusätzlich noch Wartung und Unterhalt und wenn ich es nicht verkaufe, ja, Dann kommt dann auch kein Geld wieder rein. Das heißt, wenn ich das jetzt direkt vergleiche, dann würde dabei rauskommen, Miete sind wir bei 43.000, Leasing ist bei 43.000 ungefähr und der Kauf ist sogar bei 47.000, also ein bisschen teurer. Aber jetzt ist halt die Frage, wenn ich das Auto eben nicht verkaufe, sondern auch die nächsten zehn Jahre weiterfahre, dann fahre ich halt beim Kauf ab jetzt kostenfrei. Muss ich nur noch die Wartung und so weiter übernehmen. Bei Leasing das Gleiche, da kann ich auch einfach weiterfahren und das gehört jetzt mir. Bei der Miete bin ich aber angeschmiert und zahle einfach so weiter und habe gar kein Eigentum. Man sieht das also so ein bisschen.

[39:49] Miete ist so das eine Extrem. Mir gehört nichts und es kostet ein Heidengeld. Kauf, mir gehört alles. Ich habe aber auch krasse Verantwortung. Und Leasing ist irgendwie so ein bisschen dazwischen. Ich habe eine lange Vertragsbindung. Ich zahle einen Teil selber, aber auch niedriger geraten. Muss mich aber trotzdem um die Wartung kümmern. Also es hat halt eben alles Vor- und Nachteile. Deswegen gibt es auch diese drei verschiedenen Varianten. Wenn das alles immer so einfach wäre und nur Vorteile hätte, würde man ja einfach sofort verkaufen oder leasen oder mieten. Aber es ist halt nicht so. Deswegen immer angucken, was ist der konkrete Anwendungsfall? Was will das Unternehmen mit dem Ding anstellen? Mit der Maschine, dem Auto, dem Laptop? Ich rede jetzt die ganze Zeit von Autos. Wie gesagt, du kannst auch irgendwas anderes leasen, was teuer genug ist und wo es einen Leasinggeber für gibt. Das muss ja irgendwer auch anbieten auf deiner Seite. Und dann rechnet man das mal durch. Und üblicherweise werden dir halt die Zahlen vorgegeben. So wie ich mir die jetzt hier ausgedacht habe, ist das in der Prüfung dann auch so. Dann rechnest du ein bisschen Prozent. und guckst dann am Ende, was am teuersten ist und empfiehlst halt das, was nicht am teuersten ist. So ist das meistens.

[40:47] Genau. Und jetzt haben wir alles durchgekaspert von Kauf mit Finanzierung, Bayer Bank, Miete und Leasing. Kennst jetzt hoffentlich die fachlichen Hintergründe und vielleicht kriegst du es jetzt auch in der Prüfung besser hin, das Zeug dann zu berechnen, wenn du verstanden hast, worum es hier eigentlich geht. Das war heute mein Anliegen. In diesem Sinne würde ich sagen, wir sind heute durch mit dem Thema für die AP1. Wir haben noch sehr viele andere Themen, spannende Themen für die AP1 auf dem Zettel und wenn ich die alle so lange behandle wie dieses Thema hier, dann habe ich noch ein paar Jahre was zu tun, auf jeden Fall. Aber ich habe es halt erstmal genommen, weil es so hoch auf meiner Punkteliste stand. Das war die Begründung.

[41:22] Ich hoffe, es hat dir heute gefallen. Wenn ja und wenn du noch mehr von mir rund um die Prüfungsvorbereitung und deine Ausbildung haben möchtest, dann melde dich doch für mein Newsletter an unter itbuchepodcast.de slash Newsletter. Kannst du das kostenfrei tun und dann kriegst du mindestens einmal die Woche von mir passend zu deinem aktuellen Stand, wenn du zum Beispiel dich gerade für die AP1 vorbereitest, gibt es ganz viele Infos zur AP1-Vorbereitung, für die AP2, dann für die AP2 und so weiter. Und auch wenn du Ausbilder oder Ausbilderin bist, habe ich einen Haufen an Zeug, da kriegst du sogar noch mehr Mails, als wenn du als Zubi dich anmeldest. Kannst du dich jederzeit wieder abmelden, kostet nix. Itwufepodcast.de slash Newsletter. Und wenn du nochmal hier die Beispielrechnung, die Shownotes sehen willst, die ich übrigens auch seit der letzten Podcast-Episode transkribieren lasse, das heißt, kann man jetzt auch nachlesen, wenn man möchte und da drin suchen, Die findest du unter itberufe-podcast.de slash 193 für die heutige 193. Episode. Und in diesem Sinne sage ich vielen Dank fürs Zuhören und bis zum nächsten Mal. Mach’s gut.

Ich analysiere die schriftlichen IHK-Prüfungen AP1 und AP2 für Anwendungsentwicklung und präsentiere eine umfassende Übersicht der Prüfungsinhalte seit 2020 in der einhundertzweiundneunzigsten Episode des IT-Berufe-Podcasts.

In dieser Episode des IT-Berufe-Podcasts fokussiere ich mich auf die schriftlichen IHK-Prüfungen AP1 und AP2 für Anwendungsentwicklung und präsentiere eine umfassende Analyse der bisherigen Prüfungsinhalte. Dabei habe ich alle Prüfungen seit 2020 durchgeschaut und alle Themen sowie die vergebenen Punkte systematisch erfasst. Diese Informationen sind jetzt in einer übersichtlichen Datenbank zusammengeführt, die dir bei der gezielten Prüfungsvorbereitung helfen kann.

Ich beginne mit der Vorstellung der allgemeinen Prüfungsinhalte von AP1, die für alle IT-Berufe identisch sind. Durch die Clusterung der Themen nach Häufigkeit und Punktvergabe ermögliche ich einen Überblick darüber, welche Themen in der Vergangenheit am häufigsten abgefragt wurden und welche besonders wertvoll für deine Vorbereitung sind. Hierbei stelle ich fest, dass Themen wie Hardware und Wirtschaftlichkeit konstant präsent waren, sodass eine gezielte Vorbereitung in diesen Bereichen besonders empfehlenswert ist.

Im Anschluss gehe ich speziell auf die AP2-Prüfungen für Anwendungsentwickler:innen ein. Durch die detaillierte Auswertung aller Aufgaben aus den Prüfungen hat sich herausgestellt, dass Pseudocode mit Abstand die meisten Punkte einbringt. Diese Erkenntnis ist besonders wertvoll für alle Prüflinge, die häufig Schwierigkeiten in diesem Bereich haben. Des Weiteren betrachte ich die Themen Datenbanken und Algorithmen, die ebenfalls häufig abgefragt werden, und gebe Tipps, wie man sich strukturiert auf diese Inhalte vorbereiten kann.

Zusätzlich biete ich den Zuhörer:innen die Möglichkeit, die aufbereiteten Statistiken direkt auf meiner Website einzusehen. Dort sind nicht nur die häufigsten Themen gelistet, sondern auch spezifische Aufgaben, die als besonders punkteträchtig identifiziert wurden. Ich ermutige alle Zuhörer:innen dazu, sich intensiv mit diesen Materialien auseinanderzusetzen und ihre Prüfungsstrategien entsprechend anzupassen.

Gemeinsam erarbeiten wir Ansätze, wie man das Lernen optimieren kann, um mit den erlangten Erkenntnissen in die prüfungsrelevanten Themen gezielt einzutauchen. Ich teile auch persönliche Empfehlungen zu Literaturempfehlungen und Vorbereitungsstrategien, die sich in der Praxis bewährt haben. Mein Ziel ist es, dir nicht nur die notwendigen Informationen an die Hand zu geben, sondern auch eine strukturierte Herangehensweise an die Prüfungsvorbereitung zu vermitteln.

Die Episode ist also nicht nur eine Auflistung von Themen, sondern bietet eine tiefere Einsicht in die Prüfungsdynamik der IHK und geht auf die richtige strategische Vorbereitung ein. Sei es als Auszubildender oder als Ausbilder, die gewonnenen Daten sind ein wertvolles Werkzeug zur Verbesserung der Prüflingsleistung. Damit möchte ich dich motivieren, deine Vorbereitung aktiv mit diesen Daten zu unterstützen, um deine Erfolgschancen signifikant zu erhöhen.

Literaturempfehlungen

Ich habe meine Literaturempfehlungen extra für diese Episode komplett aktualisiert: Literaturempfehlungen für die IT-Berufe.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Themen der schriftlichen IHK-Prüfungen der IT-Berufe

Podcast-Episode als Video bei YouTube

Transkript der gesamten Episode

• [0:07] Einleitung zur Prüfungsvorbereitung
• [0:02] Hallo und herzlich Willkommen zur 192. Episode des IT-Berufe-Podcasts. In dieser Episode geht es um die Themen der bisherigen schriftlichen IHK-Prüfung AP1 und AP2 für Anwendungsentwicklung. Viel Spaß!
• [0:19] Statistiken zu IHK-Prüfungen
• [0:20] Hallo und herzlich Willkommen zur 192. Episode des IT-Berufe-Podcasts. Mein Name ist Stefan Macke und heute habe ich mal eine Kleinigkeit für dich mitgebracht als Serviceleistung von mir. Und zwar habe ich die bisherigen Abschlussprüfungen, die schriftlichen Abschlussprüfungen der IT-Berufe, nämlich die AP1, die ja für alle IT-Berufe gleich ist, und die AP2 für Anwendungsentwicklung, weil das ja nun mal einfach mein Kerngebiet ist, komplett durchgeschaut von vorn bis hinten. Und ich habe mir jede Aufgabe einzeln angeguckt und mir dazu notiert, wie das Themengebiet ist, also zum Beispiel, weiß ich nicht, RAID, Softwareentwicklung, wie auch immer. Und mir dann noch dazu notiert, wie viele Punkte die Aufgabe gab. Und das Ganze habe ich dann in eine große Datenbank eingetragen und jetzt ein paar Statistiken darauf ausgeführt. Und diese Statistiken können dir vielleicht bei der Prüfungsverbreitung ein bisschen helfen. Und ja, das möchte ich heute einfach mal in der Episode kurz vorstellen. Und am besten kannst du dir das Ganze selber angucken auf der Website, itberufepodcast.de slash 192. Da findest du die Shownotes zur heutigen 192. Episode. Und da ist natürlich auch diese Themenliste verlinkt. Und da kannst du einfach mal selber reingucken. Ansonsten würde ich jetzt einfach mal anfangen und meine ersten Erkenntnisse der ersten paar Prüfungen hier vorstellen.
• [1:32] Also, ich habe alle bisherigen Prüfungen durchgeschaut seit 2020. Da wurden die IT-Berufe ja neu geordnet. Gab es eine neue Prüfungsordnung mit AP1 und AP2. Und ja, jetzt ist natürlich immer die spannende Frage, wenn ich mich auf eine Prüfung vorbereite, was soll ich denn lernen? Gerade für die AP1, für alle IT-Berufe, die Themen sind ja sehr, sehr breit gestreut. Und ich habe mir jetzt einfach mal die Mühe gemacht, alle einmal durchzugucken, alle Prüfungen. Und die so ein bisschen zu klastern, nach Themengebieten, aber auch nach konkreten Themen. Und vor allem habe ich dann halt eben auch die Punkte dazu notiert, sodass ich jetzt am Ende so etwas sagen kann wie, Thema X hat bislang in den Prüfungen die meisten Punkte erbracht. Und wenn du jetzt wenig Zeit hast, dich auf die Prüfung vorzubereiten, dann kannst du vielleicht mit den Themen anfangen, die bisher die meisten Punkte brachen. Könnte eine Strategie sein. Ich sage nicht, dass das die einzig sinnvolle Strategie ist oder überhaupt eine sinnvolle Strategie, denn wie es auch am Finanzmarkt ist, nur weil es in der Vergangenheit passiert ist oder in sich entwickelt hat, heißt das nicht, dass es auch in der Zukunft kommt. Also könnte natürlich jetzt sein, dass in den nächsten Prüfungen die bisher häufigsten Themen gar nicht wieder abgefragt werden. Ich kann es mir fast nicht vorstellen, denn so ein bisschen gesunder Menschenverstand, wenn man auf die Themen guckt, dann merkt man, das sind eigentlich die Kernthemen für die jeweiligen Prüfungen. Also ich könnte mir vorstellen, dass das auch in der Zukunft passiert, aber ich habe natürlich keinen Einfluss darauf. Ich weiß nicht, was in den zukünftigen Prüfungen passiert.
• [2:48] Aber ja, die Tendenz ist auf jeden Fall da und eine recht hohe Wahrscheinlichkeit, glaube ich. Und dann gucken wir doch einfach mal rein, was ich da jetzt gemacht habe. Also die Liste, von der ich jetzt hier spreche oder die Liste 10, findest du bei mir auf der Website. Wenn du nicht mehr in die Shownotes gehst, kannst du hier oben aufs Menü gehen. Da gibt es beliebte Seiten bei mir auf der Seite.
• [3:10] Literaturempfehlungen für die Prüfung
• [3:07] Und dann gibt es da den Unterpunkt Themen der schriftlichen IHK-Prüfung. Und wenn du das anklickst, dann findest du meine Liste, wo ich unter anderem als allererstes nochmal auch ein bisschen Literaturempfehlungen zusammengestellt habe. Das habe ich extra in Vorbereitung für diese Seite auch gemacht. Denn ich werde immer ganz oft gefragt, ja, jetzt sind da tausend Themen auf der Seite, aber wie lerne ich die denn?
• [3:26] Und ja, ich habe einfach mal alles zusammengestellt, was ich so an Büchern hauptsächlich meinen eigenen Azubis empfehle, die die auch immer selber bekommen und mir teilweise sogar zusammen lesen oder auch in der Schule durcharbeiten. Und verschiedene andere Sachen. Ganz oben auf der Liste steht selbstverständlich alte Prüfungen. Ich hoffe, das ist inzwischen angekommen, dass man am besten für die Prüfung lernt, indem man alte Prüfungen durchgeht, um auch so ein bisschen für die Fragestellung sich vorzubereiten. Und was die IHK, sage ich selber schon hier, natürlich der IHK-Erstellungsausschuss, da eigentlich von einem hören will. Aber das nur am Rande, das findest du halt auch ganz oben, wenn du dir das anschauen willst. Und dann kommen wir zum eigentlichen Inhalt. Ich hatte bislang auf der Seite schon tatsächlich früher mal händisch aus den sehr, sehr alten Prüfungen. 2010, 2011 etc. Habe ich das Ganze schon mal gemacht und so die Punkte rausgeschrieben. Auch für meine eigene Ausbildertätigkeit. Ich muss ja auch so ein bisschen wissen, was kam in welcher Prüfung dran. Oder als simples Beispiel, ich mache gerade mit meinen Azubis das Thema RAID. Jetzt hätte ich gerne eine echte Prüfungsaufgabe zum Thema RAID. Dann wäre halt cool, wenn ich irgendwo suchen kann und nicht in, weiß ich nicht, ganz vielen Blättern durchblättern muss, weil ich in irgendeiner Prüfung da meine Aufgabe gesehen habe und ich suche mir da einen Wolf quasi. Das heißt, das ist für mich eigentlich gewesen, diese Liste zu erstellen. Ich habe dann aber auch irgendwann aufgehört, 2018, das ist auch schon ein paar Jährchen her, ja. Und jetzt habe ich das Ganze mal auf die neuen Prüfungen angepasst. Und habe es dann jetzt halt mit einer Datenbank im Hintergrund gemacht. Das hat jetzt den Vorteil, wenn eine neue Prüfung kommt, dann kann ich die einmal erfassen, packe die in die Datenbank und diese Statistik auf der Seite ist automatisch aktuell. Es wird also wirklich aus einer Datenbank gespeist hier.
• [4:56] Und ja, wenn man auf die Seite geht, dann sieht man ein paar Statistiken. Ich habe das säuberlich getrennt. Einmal nach Teil 1 der Abschlussprüfung, AP1, weil der für alle IT-Berufe ja gleich ist. und dann den AP2-Teil, in meinem Fall halt nur für Anwendungsentwicklung, weil ich halt nur AnwendungsentwicklerInnen ausbilde. Und deswegen habe ich jetzt nicht auch noch Zeit und Lust, mich um die sechs anderen IT-Berufe zu kümmern.
• [5:19] Aber ganz ehrlich, wenn du da Zeit und Lust drauf hast und vielleicht zu dieser Datenbank beitragen willst, das fände ich natürlich mega cool, dann melde dich einfach bei mir, kannst mir eine Mail schreiben oder Kontaktformular auf der Website und dann sage ich dir, in welchem Format ich das brauche und dann haue ich das mit in die Datenbank. Und dann kann das vielleicht ein bisschen wachsen für alle Prüflinge, die in Zukunft noch kommen. So, ich habe da so ein paar Statistiken zusammengestellt. Nummer eins, erstmal die Liste aller bisher erfassten Prüfungen, weil, wie gesagt, kommt aus der Datenbank und da ist jetzt nicht sofort ersichtlich, von wann sind denn jetzt eigentlich die Inhalte? Sind die aktuell? Fehlt da noch was? Und so weiter. Deswegen erstmal ganz stumpf, welche Prüfungen habe ich überhaupt schon erfasst? Und aktuell, ich nehme es ja hier auf, so im Februar 2025, habe ich alle bisherigen AP1- und AP2- für Einbringungsentwicklungen, die bis heute durchgeführt wurden, erfasst. Also die letzte, die ich jetzt zum Beispiel erfasst habe, ist die AP1 im Herbst 2024.
• [6:06] Statistiken der bisherigen Prüfungen
• [6:06] Und alle seit der Einführung 2020 habe ich hier durchgeguckt und eingetragen. Da sieht man also sofort als erstes, ist das Ding schon aktuell auf die neueste Prüfung angepasst oder ist das noch nicht mit drin. So, und dann habe ich das, was ich für die uralten Prüfungen händisch gemacht habe, jetzt auch einmal datenbankgestützt gemacht und zwar einfach neben jede Prüfung geschrieben, welche Themen dran kamen. Kann man sich jetzt fragen, warum ist das interessant, ich kann mir die Prüfung ja auch einfach angucken. Ja, aber in den Prüfungen kannst du halt nicht so cool suchen, wie ich gerade schon sagte. Und wenn ich jetzt zum Beispiel für meine eigenen Azubis eine Prüfungsaufgabe brauche, wo es irgendwie um DHCP geht oder NAS und SAN oder.
• [6:45] Endpoint Security oder was auch immer, dann kann ich jetzt einfach auf dieser Seite hier Steuerung F suchen und dann finde ich zum Beispiel auch hier Gruppenrichtlinien und das war in der Prüfung dran, AP1 2023, Frühjahr. So, und dann kann ich die aus dem Schrank holen und habe dann eine passende Aufgabe, die ich mit meinen Azubis machen kann. Also, das finde ich immer interessant. Ich weiß nicht, ob das für dich in der Prüfungsverarbeitung interessant ist. Wobei, ja doch, eigentlich schon. Wenn du zum Beispiel im Prüfungskatalog siehst, oh, RAID kommt ja jetzt dran. Übrigens, Spoiler, nicht mehr in AP1, aber in AP2. Und du brauchst einfach eine Aufgabe für diese RAID-Geschichten. Dann kannst du hier halt einfach suchen, findest die passende Prüfung und hast eine echte Aufgabe, mit der du das dann machen kannst. Also, ist doch ganz cool, oder? Also für mich als Ausbilder super interessant, diese Liste. In der Prüfungsverbreitung vielleicht finde ich auch hilfreich. Ja, und dann kommt das, was mich eigentlich angetrieben hat, diese Geschichten hier zu erfassen. Und zwar wollte ich gerne mal wissen, was für Themen kommen eigentlich wirklich in der Prüfung dran? Wie oft und wie viele Punkte gibt es dafür? Weil es gibt natürlich immer so ein Bauchgefühl. Ja, da kommt relativ in der AP1, man spricht häufig Netzwerktechnik dran oder sowas. Aber so richtig mit Zahlen belegt hatte ich das bislang noch nie und das wollte ich einfach für mich selber auch mal verifizieren, ob das eigentlich so stimmt. Und deswegen habe ich jetzt folgendes gemacht. Ich habe ein paar Statistiken angelegt und zwar einmal die Häufigkeit der jeweiligen Themen in den bisherigen Prüfungen, dann die Gesamtpunktzahl der Themen in den bisherigen Prüfungen und dann sogar nochmal runtergebrochen auf einzelne Themen.
• [8:13] Was meine ich jetzt? Was ist hier der Unterschied? Wenn du meine Seite zur Prüfungsvorbereitung kennst und zwar findest du die auch unter beliebte Seiten und dann mögliche Themen von Teil 1 und mögliche Themen von Teil 2. Das ist die Seite, mit der ich auch mit meinen eigenen Azubis die Prüfungsvorbereitung mache. Und da habe ich die Struktur der Themen, die dort genannt werden, ein bisschen an meine Bedürfnisse angepasst und nicht wie die zum Beispiel im Prüfungskatalog stehen, wo dann mal als Beispiel irgendwas mit Datenbanken Datenbanken auf drei verschiedene Unterpunkte und Paragrafen verteilt ist. Ich habe aus allen möglichen Quellen was zusammengesucht. Da ist unter anderem der Prüfungskatalog dabei, aber auch die Umsetzungshilfe für die IT-Berufe, verschiedene Lernkarten, alte Prüfungen natürlich, die ich auch durchgeguckt habe. Und dann habe ich diese ganzen Themen auf einen Haufen geschmissen und dann geklastert. Das heißt, ich habe die fachlich gruppiert und nicht nach irgendwelchen Paragrafen, Sodass dann bei mir das zum Beispiel losgeht mit Projektmanagement. Also alles, was irgendwas mit Projektmanagement zu tun hat, steht dann an einer Stelle und nicht verstreut auf sieben Quellen. Und ich habe die Dinger dann Themencluster genannt und das ist meine persönliche Ausarbeitung. Das steht jetzt nicht in irgendeinem Buch, sondern das habe ich so gemacht, weil ich es besser finde, so zu lernen.
• [9:27] Bist du, weil ich glaube, dass meine Azubis das so besser lernen können, als wenn wir von Thema zu Thema springen und hin und her, einfach nur, weil es in irgendeinem Paragraphen steht. Also diese Einteilung ist von mir vorgenommen. Das ist keine offizielle Vorgabe von irgendeiner IHK oder irgendeinem Prüfungserstellungsausschuss, sondern es ist meine persönliche Einteilung, aber aus sehr, sehr vielen Quellen, die ich dafür auswähle.
• [9:46] Gewertet habe, ja? Unter anderem die alten Prüfungen. So, und diese Themencluster, das ist halt das, wo ich dann zum Beispiel meine Azubis bitte, Mensch, lad doch mal ein zur Lernzielkontrolle zum Thema Hardware, ja? Und dann kann man sich den Themencluster angucken zum Thema Hardware und dann steht da halt irgendwie alles drunter, was irgendwas mit Hardware zu tun hat und was in irgendeinem Prüfungskatalog, alter Prüfung oder Lernkarten stand. Zum Beispiel CPU-Prozessor von Neumann-Architektur Wärmeleitpaste. Wärmeleitpaste war schon mal eine Prüfungsaufgabe in der schriftlichen Prüfung zum Beispiel. Und so können wir uns halt an einem Termin komplett um die Hardware kümmern, beim nächsten um den nächsten Cluster und so weiter. Das ist meine eigene Idee gewesen hier. Und weil ich das halt nicht nur für die Gemeinschaft mache, so wie das jetzt hier, was ich ja gerne auch nach draußen gebe, aber ich benutze das ja auch selber. Eat your own dog food heißt das in der IT. Also das benutzen, was man auch selber verkaufen will, in Anführungszeichen. Und so mache ich das. Also mit der Seite übe ich auch meine eigenen Azubis.
• [10:40] Und weil ich halt mir selber auch das Leben einfacher machen möchte, habe ich halt diese Themencluster jetzt als Basis genommen, für die Statistiken
• [10:48] Themencluster und deren Bedeutung
• [10:47] der bisherigen IHK-Prüfung. Und jetzt kann man sehen, wie oft diese Themencluster, die ich da gebildet habe, in den bisherigen Prüfungen drankamen. Und da steht dann zum Beispiel bei der AP1 ganz oben Hardware und Wirtschaftlichkeit, was die Häufigkeit angeht. Und ich habe das dann so gemacht, in wie vielen Prüfungen war das bisher dran und wie ist die relative Häufigkeit. Und zum Beispiel Hardware und Wirtschaftlichkeit waren bisher in jeder AP1 dran. Das heißt 100% Häufigkeit. Dafür dann aber ein Thema, was ich persönlich die ich eigentlich auf Platz 1 erwartet hätte, nämlich Netzwerktechnik, ISO, OSI und der ganze Kram, kam nur in Anführungszeichen in sechs von sieben Prüfungen ran, also bisher in 86 Prozent.
• [11:27] So, und jetzt habe ich das halt für alle Themencluster gemacht. Und dann ist aber die Idee, ja, was bringt mir das jetzt? Ich weiß jetzt, Hardware kommt in fast jeder oder bisher, bisher in jeder Prüfung dran. Aber ist das denn eigentlich auch ein wichtiges Thema? Also nur weil das immer drankommt, heißt es ja nicht, dass es dafür immer 37 Punkte gibt. Kann auch sein, dass das nur so eine kleine Fitzel-Aufgabe ist. Und deswegen habe ich das nochmal anders aufgearbeitet und zwar mit den bisher vergebenen Punkten. Das heißt, ich habe für jede Aufgabe, Beispiel irgendwas mit ISO-OSI-Modell, gehört zum Themencluster Netzwerktechnik. Dafür gab es vier Punkte. Dann gab es noch eine zweite Aufgabe, die gehört auch zur Netzwerktechnik, gab drei Punkte und so weiter. Dann habe ich die alle aufsummiert und dann diesen Themenclustern zugeordnet. Kannst du mal als kleine Vorbereitung für die AP1 ja nicht mehr, weil SQL ist ja gestrichen aus AP1, aber für die AP2, ich habe gelernt, dass SQL jetzt auch in den AP2 zum Beispiel bei Fisis abgefragt wird, aber da kannst du dir mal überlegen, welches SQL-Statement ich dafür vermutlich benutzt habe.
• [12:20] Spoiler, Group By. Also alles nach Themencluster selected und dann gruppiert und die Punkte aufsummiert. Und das ist dann die Liste, die dabei rausgekommen ist. Ganz oben für die AP1 steht Hardware tatsächlich mit bisher über 100 Punkten in der bisherigen Prüfung. Und auf Platz 2 dann Projektmanagement, auf Platz 3 Netzwerktechnik, dann kommt IT-Sicherheit, Angebotsvergleich. So was wie eine Nutzwertanalyse oder solche Scherze. Dann kommt Softwareentwicklung und so weiter und so fort. Ich will jetzt nicht jeden Punkt hier durchgehen, weil bei der nächsten Prüfung vielleicht verändert sich da ja ein bisschen was und dann kann ich diese Liste jetzt hier vorlesen, aber das bringt ja niemanden weiter. Deswegen empfehle ich dir, geh einfach auf die Seite, guck die Liste an, die wird halt dann nach jeder Prüfung zeitnah aktualisiert. Übrigens zeitnah heißt dann, wann ich die Prüfung auch habe. Ich habe keine Magic-Quelle, die mir am Tag der Prüfung die Prüfung zu flattern lässt. Das gibt es nicht. Das heißt, ich bin auch darauf angewiesen, ganz normal wie jeder andere auch, diese Prüfung beim U-Form Verlag zu kaufen. Und dann kann ich, wenn ich die geliefert bekommen habe, die durchgucken. Also es wird nicht am Tag der Prüfung selber die Statistik aktualisiert. Das kann ich schon mal ganz sicher sagen. Im Gegenteil, das wird ein paar Wochen wahrscheinlich dauern, wenn die Prüfung vorbei ist. So, aber hiermit habe ich jetzt schon mal eine etwas bessere Aussagekraft. Ich weiß jetzt, bisher wurde das Thema Hardware halt oder für das Thema Hardware wurden bislang am meisten Punkte verteilt. Und da kann ich ja dann vielleicht schon was daraus ableiten und sagen, fange ich doch mal mit dem Thema an, bevor ich, ganz unten auf der Liste steht zum Beispiel Betriebssysteme mit vier Punkten.
• [13:45] Naja, also wenn Hardware bisher 25 mal mehr Punkte gebracht hat als Betriebssysteme.
• [13:50] Vielleicht fange ich dann mit Hardware an zu lernen und nicht mit Betriebssystemen. Das ist die Idee dieser Liste.
• [13:56] So, und jetzt habe ich das nochmal weiter runtergebrochen. Diese Themencluster, die sind ja von mir zusammengestellt für meine eigene Prüfungsverbreitung. Ich habe das Ganze jetzt aber nochmal weiter runtergebrochen auf die einzelnen Themen. Also bei Hardware zum Beispiel geht es da um Peripherie, CPU, RAM, Wärmeleitpaste, gehört zu CPU und so weiter. Und das habe ich jetzt so gemacht, dass jede Aufgabe durchaus auch mehrere solcher Themen zugeordnet bekommen kann. Beim Themencluster ist es immer eindeutig. Also eine Aufgabe gehört bei mir genau zu einem Themencluster. Das heißt, wenn ich alle Punkte, die hier vergeben wurden, aufsummiere, komme ich genau auf die Punktzahl aller bisherigen Prüfungen.
• [14:36] Einzelthemen und Punktvergabe
• [14:30] Bei den Einzelthemen kann es jetzt mehrere Schlagworte pro Aufgabe geben. So ein Thema bitte so verstehen wie so ein Schlagwort. Beispiel, ich habe eine Aufgabe zu einem RAID-System. Das ist dann vielleicht das Thema RAID, aber auch sowas wie Datensicherung oder so. Passt jetzt nicht so hundertprozentig, aber Beispiel SQL. Es gibt eine SQL-Aufgabe und da ist ein Insert drin. Das heißt, dann habe ich ein Schlagwort Insert und ein Schlagwort SQL. Dann zählt der Punkt quasi doppelt. Aber mich interessiert dann hier, welches Einzelthema muss ich mir besonders angucken, was hat bislang die meisten Punkte gebracht. Und das ist in der AP1 tatsächlich die Nutzwertanalyse mit weitem Abstand bisher. Hätte ich nicht gedacht, 38 Punkte bisher insgesamt und erst auf Platz zwei kommt SQL mit 26 Punkten. Also Nutzwertanalyse angucken, das wäre schon mal eine coole Sache.
• [15:21] Und ja, wie kann das sein? Ich habe auch, also das Coole ist, ich habe jetzt ja halt alle Prüfungen nochmal durchgeguckt und alle Aufgaben nochmal angeschaut und weiß jetzt auch so ein bisschen nochmal besser im aktuellen Kurz- und Langzeitgedächtnis, was da eigentlich so gefragt wurde. Und Nutzwertanalysen sind halt in der Prüfung relativ einfach, ehrlich gesagt. Man musste eigentlich noch nie eine from scratch zeichnen oder so, aber es gab immer eine, die vorgegeben war und da musste man halt ein paar Zahlen eintragen. Also ganz blöd gesagt könnte man sagen, das sind geschenkte Punkte. Das ist jetzt keine schwierige Aufgabe, aber dafür gab es dann halt einfach mal 10 Punkte, weil man halt irgendwie 10 Zahlen eintragen musste. Wenn man jetzt aber noch nie gehört hat, was eine Nutzwertanalyse ist, wird es halt schwierig. Aber so deswegen mache ich diese Liste und das hätte ich zum Beispiel nie auf dem Zettel gehabt, dass in der API 1 bislang so oft eine Nutzwetanalyse Thema war. Wusste ich einfach nicht. Und jetzt habe ich es einfach ausgewertet. Also da kommt halt sowas wie SQL, IPv6, IPv6. Ich habe zu viele Hunde offensichtlich.
• [16:14] IPv6, Netzplan. Ja, den hätte ich auch auf dem Zettel gehabt. Aber dann schon auf Platz 5, Leasing. Also dieser Klassiker, Kauf, Miete, Leasing. Was sind die Vor- und Nachteile und so? Kommt mega oder kam mega häufig dran. Hatte ich so auch nicht auf dem Zettel. So, und diese Liste ist dementsprechend auch ein bisschen länger, weil ich ja auch mehr Schlagworte für jede Aufgabe vergeben habe, die kannst du gerne mal durchscrollen. Da sind dann wirklich alle möglichen Themen dran, bis zu Thema wie zum Beispiel, was ist der kritische Pfad in einem Netzplan? Das war ein einziges Mal konkrete Frage und gab auch nur einen einzigen Punkt. Und so kannst du jetzt wirklich von ganz, ganz, ganz, ganz viel und häufig und mit vielen Punkten abgefragt bis hin zu kleinsten Einzelthemen, dir das hier einfach angucken und dann selber entscheiden, sollte ich mir das anschauen oder nicht. Ganz wichtig, meine Standardempfehlung ist eigentlich, guck dir alles an. Ich würde niemals sagen, komm, Lernen auf Lücke, scheißegal. Das ist nicht meine Strategie. Aber wenn du wenig Zeit hast, dann kannst du vielleicht mit dieser Liste entscheiden, womit du anfangen solltest. Was nicht heißt, dass du die anderen Sachen weglassen solltest.
• [17:15] So, gehen wir noch kurz die Teil 2 Liste durch. Die ist jetzt nur für AnwendungsentwicklerInnen interessant. Da habe ich auch alle Prüfungen erfasst. Da gibt es natürlich doppelt so viele, weil es gibt ja zwei Prüfungsteile. Für Einmachungsentwicklung ist das einmal entwickeln und an, oh Gott, jetzt weiß ich den Namen schon nicht mehr, auf jeden Fall einmal diese, da steht es ja, Entwicklung und Umsetzung von Algorithmen und das andere Ding heißt Planen eines Softwareprodukts. Und aus beiden Prüfungen habe ich jetzt das zusammengeschmissen. Ich habe das natürlich in der Datenbank fein säuberlich aufgeteilt, in welchem Prüfungsbereich welche Aufgabe war. Aber das ist ja hier jetzt irrelevant, weil beide Prüfungsteile zählen gleich viel. Also warum interessiert mich, in welchem Teil der jetzt genau abgefragt wurde? Ich muss eh beide machen. Und deswegen bin ich genau wie bei der API 1 auch wieder angefangen, habe erstmal die ganzen Themen wieder aufgeschrieben, dass du gucken kannst, Mensch, ich brauche eine Prüfungsaufgabe zur Code Coverage. Ach ja, das war ja in der API 2 2023 Sommer Entwicklung und Umsetzung von Algorithmen.
• [18:09] AP2: Häufigkeit und Punkte
• [18:06] Ja, das ist mein kleiner Service. Dann kommen wieder meine Themencluster. Und hier ist es jetzt tatsächlich so, dass in der AP2 Datenbanken auf Platz 1 sind. Die waren bislang am häufigsten dran. Danach kommen Algorithmen, also Pseudocode. Und dann kommen allgemeine Sachen, Softwareentwicklung, UML, SQL. Das ist so der Klassiker. Aber SQL zum Beispiel allein von der Häufigkeit, weil SQL immer nur in einem der beiden Prüfungsteile meistens abgefragt wird, kam das bislang nur in der Hälfte der Prüfung dran.
• [18:34] Datenbanken allerdings in fast jeder Prüfung und zwar auch in jedem der beiden Teile tatsächlich. Also, da die Prüfung Teil 2, da musst du ja alle Teile bestehen, beziehungsweise man darf mit zwei Fünfen und so, darf keine Sechs haben, ja okay, aber Datenbanken ist zum Beispiel ein Thema, wenn du das nicht kannst, dann hast du potenziell die Gefahr, durch zwei Prüfungsteile durchzufallen, weil es halt in beiden abgefragt werden kann, während SQL hauptsächlich in einem der Teile da ankommt. So, solche Schlussfolgerungen könnte man jetzt auch aus der Statistik ziehen. Und dann scrolle ich aber gerne nochmal runter, weil die Häufigkeit ist ja nicht so außerhalbkräftig. Wenn man jetzt nämlich guckt, Datenbanken war auf Platz 1. Bei der Punktvergabe ist aber mit großem Abstand ganz vorne Algorithmen. Also hauptsächlich Pseudo-Coach. Die dicken, fetten Programmieraufgaben, eine DIN-A4-Seite, 25 Punkte, dicker Pseudo-Coach. Das steht ganz weit oben. Danach kommen dann Datenbanken, also zum Beispiel sowas wie ER-Modell, Tabellenmodell erzeugen und so weiter. Also die sind sehr dicht beieinander, aber auf Platz 1 ist Pseudocode. Das heißt, wenn du dir ein Thema unbedingt angucken solltest, was aus meiner Erfahrung als IHK-Prüfer auch sehr häufig zu Punktabzug führt, guck dir Pseudocode an. Das gibt wirklich dicke Punkte. Und dann kommt UML, SQL und so weiter und so fort. Und das gleiche habe ich dann auch nicht nur für die Cluster gemacht, sondern auch für die Einzelthemen. Und da wird es nochmal krass deutlicher. Pseudocode ist mit Abstand, mit fast über 100 Punkten mehr auf Platz 1 vor SQL auf Platz 2. Das heißt, einzelne Themen für die bisherigen AP2 für Anwendungsentwicklung.
• [20:03] Pseudocode mit Abstand Nummer 1, was die Punkte angeht. Und SQL auf Platz 2. Und dann habe ich ja eben schon gesagt, ich habe das runtergebrochen. Also SQL und dann habe ich zusätzlich noch auf Select, Insert und so weiter runtergebrochen. Und auf Platz 3 ist dann Select. Das heißt, also SQL und der Großteil der SQL-Abfragen sind Select-Abfragen. Also wenn du dich fokussieren willst, guck dir Select an. Und dann, das fand ich dann ganz interessant, das bisher am häufigsten abgefragte UML-Diagramm, nein, falsch gesagt, ist ja nicht die Häufigkeit, sondern wofür es am meisten Punkte gab, ist tatsächlich das Aktivitätsdiagramm. Passt irgendwie auch ganz gut, weil Pseudocode, das ist ja auch einfach nur eine Darstellung eines Algorithmus und mit einem Aktivitätsdiagramm kann ich auch einen Algorithmus visualisieren. Passt also eigentlich auch sehr gut zu diesem Beruf. Hätte ich trotzdem nie auf dem Zettel gehabt, dass es für Aktivitätsdiagramme bisher von allen UML-Diagrammen, von den großen fünf, die mal abgefragt werden, am meisten Punkte gab.
• [20:54] Solche Schlussfolgerungen kann man jetzt super ziehen. Also ich wurde auch bei einigen Sachen definitiv überrascht bei dieser Liste. So, dann kommt das Relationale Datenmodell, Klassendiagramme, ER-Modell und so weiter. Und auch diese Liste kann man ganz, ganz, ganz nach oben scrollen und dann stellt man zum Beispiel fest, dass Datenbank-Trigger bisher ein einziges Mal abgefragt wurden und es gab zwei Punkte dafür. Also wenn du zum Beispiel so Special-Datenbank-Sachen wie zum Beispiel Stored Procedures und was ist ein Index und so überspringen möchtest, weil du keine Zeit hast, bislang hätte dich das nicht allzu viele Punkte gekostet. Kannst du Pseudocode und SQL und Aktivitätsdialgram nicht? Na, dann sieht’s schon schwieriger aus. Ja, so, das war jetzt also meine Liste der Themen der bisherigen IHK-Prüfung. Wenn dir das irgendwie helfen könnte bei deiner eigenen Prüfungsverbreitung oder vielleicht bist du ja auch Ausbilder oder Ausbilderin, hast eigene Azubis, dann guck doch einfach mal auf die Seite. Wie gesagt, itberufepodcast.de und dann beliebte Seiten und Themen der schriftlichen IHK-Prüfung. Da findest du diese Liste und die wird dann auch regelmäßig von mir aktualisiert. Ja, wenn dir das hier geholfen hat, würde mich freuen, wenn du mir einen Kommentar da lässt. Kannst du direkt in deiner Podcast-App machen oder schickst mir eine Mail oder über das Kontaktformular. Ich antworte auf alles, kann aber immer ein bisschen dauern, weil ich das alles ganz alleine mache hier und kein Team dahinter ist. Also bitte verzeih mir, wenn ich nicht sofort antworte auf jede Anfrage.
• [22:09] Wenn du möchtest, kannst du dich gerne auch für meinen Newsletter anmelden. Findest du natürlich auch auf der Website unter itwufopodcast.de slash Newsletter. Und da bekommst du dann von mir, wir sind ja heute beim Thema Prüfungsvorbereitung, auch immer passend zu deinen konkreten Prüfungsterminen die Tipps per E-Mail, wann und wie und womit du dich auf die Prüfung vorbereiten kannst. Also nur als kleinen Benefit über die ganzen drei Jahre deiner Ausbildung begleite ich dich dabei, sowohl als Azubi als auch als Ausbilder und Ausbilderin. Da kommen dann immer passend zu den einzelnen Lehrjahren die Infos per E-Mail. Also von daher, wenn du möchtest, melde dich gerne an, kannst dich jederzeit wieder abmelden, wenn du keine Lust mehr hast, kostet nichts. Ja, dann würde ich sagen, vielen Dank für deine Aufmerksamkeit heute und ich wünsche dir viel Erfolg bei deiner Prüfungsvorbereitung und bis zum nächsten Mal. Tschüss!

Um die Änderungen im Prüfungskatalog für die AP2 als Fachinformatiker Anwendungsentwicklung ab 2025 geht es in der einhunderteinundneunzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Zur AP2 (Gestreckte Abschlussprüfung Teil 2) als Fachinformatiker Anwendungsentwicklung im Sommer 2025 gilt ein neuer Prüfungskatalog. Ich habe die Unterschiede zusammengestellt.

Zusammenfassung

Die folgenden Punkte fassen die zentralen Änderungen (aus meiner Sicht) zusammen.

Zusätzliche bzw. genauer spezifizierte Inhalte

• Anomalien/Redundanzen in Datenbanken erkennen
• SQL (detailliertes Beiblatt)
• Last-/Performancetests
• potentielle Angriffe wie Man-in-the-Middle, SQL-Injection, DDoS-Attacke
• Kerberos
• ODBC
• Monitoring von Systemen
• Programm- und Konfigurationsdokumentation
• NAS und SAN
• Softwarequalitätsmerkmale
• Cyber-physische Systeme
• Test Driven Development (TDD)
• Scrum
• Architektur-Pattern
• Kapselung in der Objektorientierung
• Sortierverfahren wie Bubble/Selection/Insertion Sort

Gestrichene Inhalte

• „Trends“ wie Smart Grid, IoT, Industrie 4.0, KI, Blockchain, Big Data, Augmented Reality
• Struktogramm (Nassi-Shneiderman) und Programmablaufplan (PAP)
• Load Balancing
• Data Warehouse
• Programmierparadigmen

Detaillierter Vergleich der bisherigen und neuen Inhalte des Prüfungskatalogs für die AP2 als Fachinformatiker Anwendungsentwicklung

In der folgenden Tabelle habe ich alle Unterschiede zwischen altem (ab 2020) und neuem (ab 2025) Prüfungskatalog für die AP2 als Fachinformatiker Anwendungsentwicklung gegenübergestellt.

• Rote Punkte habe ich im neuen Prüfungskatalog nicht wiedergefunden. Sie werden daher in den neuen Prüfungen so nicht mehr erwartet.
• Grüne Punkte habe ich im alten Prüfungskatalog nicht wiedergefunden. Sie werden daher in den neuen Prüfungen zusätzlich erwartet.
• Wenn sich lediglich Formulierungen oder Aufteilungen geändert haben, aber die Punkte inhaltlich gleich geblieben sind, stehen sie gar nicht in der Tabelle.
• Wenn Punkte an andere Stellen im Prüfungskatalog verschoben wurden, habe ich das in den Spalten Alter Unterpunkt und Neuer Unterpunkt gekennzeichnet.
• Meine persönliche (!) Bewertung (hin und wieder leicht ironisch) der Änderungen stehen in der Spalte Kommentar.
• Ein „x“ in Spalte wichtig deutet auf eine zentrale Änderung hin, die sich meiner Meinung nach merklich auf die Prüfungsvorbereitung der Azubis auswirkt.
• Die Punkte haben Präfixe, weil sie sich sonst doppeln. FÜ steht für Fachrichtungsübergreifende berufsprofilgebende Fertigkeiten, Kenntnisse und Fähigkeiten und BP für Berufsprofilgebende Fertigkeiten, Kenntnisse und Fähigkeiten in der Fachrichtung Anwendungsentwicklung.

Unterpunkt Alter Inhalt Neuer Inhalt Alter Unterpunkt Neuer Unterpunkt Kommentar wichtig FÜ-01.02 BGB/HGB Chancen und Risiken der technischen Entwicklungen kennen und identifizieren können FÜ-02.01 die „Trends“ von gestern sind der Normalzustand heute Ausfallsicherheit, bspw. redundante Systeme, selbstkonfigurierende Systeme FÜ-02.01 Lebenslanges Lernen FÜ-02.01 wie soll man das auch abfragen!? Teilhabe, soziale Stabilität FÜ-02.01 wird hoffentlich in WiSo abgedeckt Veränderungen von Einsatzfeldern kennen und beurteilen können FÜ-02.02 Geräteklassen FÜ-02.02 schon in AP1 Vernetzung, Integration und Modularisierung, Zentralisierung/Dezentralisierung, Embedded Systems FÜ-02.02 Smart Grid FÜ-02.02 IoT, Industrie 4.0 FÜ-02.02 eher was für den FIDV Kl, autonome Systeme FÜ-02.02 das ist ja jetzt auch schon in AP1 drin Big Data FÜ-02.02 das fände ich schon noch wichtig für FIAE Cloud On Premises, Cloud … FÜ-02.02 BP-02.04 Block Chain, Smart Contracts FÜ-02.02 das war wirklich nur ein Hype Augmented Reality FÜ-02.02 eher was für den neuen Beruf „Gestalter/-in für immersive Medien“ FÜ-02.01 Komponententest, Funktionstest, Integrationstest Komponententest, Integrationstest, Systemtest FÜ-03.01 FÜ-02.01 FÜ-02.02 Abbildung der Kontrollstrukturen mittels Struktogramm, PAP oder Pseudocode als didaktisches Hilfsmittel Abbildung der Kontrollstrukturen mittels Aktivitätsdiagramm oder Pseudocode als didaktisches Hilfsmittel FÜ-03.02 FÜ-02.02 goodbye Struktogramm und PAP x FÜ-02.03 Anomalien/Redundanzen erkennen kann gefühlt in jedem Fachgespräch dran x FÜ-02.03 Tabellenstruktur (CREATE TABLE, ALTER TABLE), Index (CREATE INDEX), Manipulation (INSERT, UPDATE, DELETE), Projektion (SELECT FROM) Selektion (SELECT FROM …WHERE) und (SELECT … (SELECT …)), Sortieren (ORDER BY), Gruppieren (GROUP BY, HAVING) SQL (siehe Anhang des Prüfungskatalogs): Tabellenstruktur Index Manipulation, Projektion, Selektion, Sortieren, Gruppieren FÜ-03.03 also gut die Inhalte des Beiblatts lernen x FÜ-03.01 Software-Test, dynamische und statische Testverfahren (z. B. Black Box, White Box, Review, Extremwertetest, Testdaten) Software-Test, dynamische und statische Testverfahren (z. B. Black Box, White Box, Review, Extremwertetest, Testdaten, Last- und Performancetest) FÜ-04.01 FÜ-03.01 Netzwerkanalyse, Bandbreite, Reaktionszeiten FÜ-04.01 FÜ-03.02 Hardwaretest, z. B. Wareneingangskontrolle, mangelhafte Lieferung, Warenausgangskontrolle, Abnahmeprotokoll Abnahmeprotokoll FÜ-04.02 FÜ-04.04 Technisch Organisatorische Maßnahmen (TOM) FÜ-04.04 Bedrohungsszenarien, z. B. Man-in-the-Middle, SQL-Injection, DDoS-Attack die wichtigsten Angriffe sollte jede:r FIAE kennen x BP-01.02 Switch; Bridge; Router BP-01.03 Verschlüsselung (preshared key, RADIUS …) Zugriffskontrolle im Netzwerk (RADIUS, Kerberos …) x BP-01.03. Drahtlos: PAN/WLAN Drahtlos: PAN/WLAN/Mesh BP-01.03 Netzwerkplan Netzwerkplan BP-01.04 BP-01.03 Netzwerktopologie (FI DV/SI) Netzwerktopologie (FI DV/FI SI) BP-01.04 BP-01.04 Dateifreigaben, z. B, SMB/CIFS BP-01.04 Datenabruf, z. B. HTTP, ODBC x BP-01.07 Netzwerkrelevante Dienste administrieren können Netzwerkrelevante Dienste beschreiben können das ist für FIAE auch ausreichend BP-01.08 Anwendungsdienste sicherstellen können Anforderungen an Verfügbarkeit von Anwendungsdiensten beurteilen können BP-01.11 Festlegen der Monitoringdaten BP-01.11 Festlegen von Schwellwerten BP-01.11 Load Balancing BP-01.12 Incident Management (Ticketsystem) Incident Management (Ticketsystem) BP-01.11 BP-01.12 Eskalationsstufen BP-01.13 Programm- und Konfigurationsdokumentation wurde vorher tatsächlich nicht genannt x BP-01.13 Checklisten BP-02.02 Elementarrisiken, z. B. Feuer, Hochwasser BP-02.03 Verschlüsselung (TPM) Verschlüsselung, z. B. Bitlocker BP-02.04 Fog, Cloud On Premises, Cloud BP-02.04 SaaS, XaaS SaaS, laaS, PaaS Xaas enthielt ja eigentlich schon alle Varianten BP-02.05 Data Warehouse BP-02.05 Datenaustauschformate: XML, JSON, CSV u. a. die Formate stehen aber noch an zwei anderen Stellen BP-02.06 NAS; SAN BP-03.01 Anforderungen kundengerecht erfassen können Softwareanforderungen erfassen können BP-03.01 Änderbarkeit Änderbarkeit/Erweiterbarkeit an Liste der ISO25001 angepasst x BP-03.01 Wartbarkeit x BP-03.02 Relationales Datenbankmodell steht schon mehrfach im Katalog BP-03.03 Datenbankverbindung implementieren BP-03.03 API API, z.B. REST steht schon mehrfach im Katalog BP-03.04 Programmierparadigma (Skriptsprache, Compilersprache …) das erstaunt mich ein wenig BP-03.04 Aufwand BP-03.06 Cyber-physische Systeme beschreiben und erweitern können ich dachte dafür haben wir den FIDV x BP-03.06 CPS-Software; Auswahl von geeigneten Sensoren/Aktoren; Nutzung von Bibliotheken; Abfragerhythmus planen; Kenntnis des Zugriffs auf Sensoren und Aktoren x BP-03.08 Qualitätssicherung und Tests; Black Box-/White Box-Tests steht schon mehrfach im Katalog BP-03.08 Grundsätzliches Vorgehen beim Testen, z. B. print-Debugging, TDD, Unit-Test, E2E Test hurra, TDD! x BP-04.01 Lasten-/Pflichtenheft erstellen können BP-04.08 BP-04.02 Scrum stand vorher tatsächlich nicht explizit im Katalog x BP-04.07 Software-Entwicklungswerkzeuge aufgabenbezogen anwenden können Software-Entwicklungswerkzeuge aufgabenbezogen auswählen und anwenden können BP-04.06 BP-04.12 Design-Pattern anwenden können Architektur- und Design-Pattern anwenden können, z. B. ui, Architektur kommt dazu und Liste der Pattern ist nur beispielhaft x BP-04.16 Struktogramm; PAP endlich! x BP-04.17 Objektorientierte Programmiermethoden anwenden können, z. B. Objektorientierte Programmiermethodenkonzepte anwenden können, z. B. was für ein Wort! x BP-04.17 Kapselung wer das nicht gelernt hat, war selbst schuld x BP-04.18 Bubble Sort Elementares Sortieren, z, B. Bubble Sort, Selection Sort, Insertion Sort x BP-04.22 Datenbankabfrage, Datenpflege mit SQL erstellen können Datenbankabfrage, Datenpflege mit SQL erstellen können -> Verweis auf Belegsatz alles lernen, was im Belegsatz steht x BP-05.03 Modultests erstellen und durchführen können (Unit-Tests) BP-05.03 die einzelnen Punkte wurden zusammengefasst BP-05.03 Softwaretests erstellen, durchführen und die Ergebnisse analysieren können Softwaretests erstellen, durchführen und die Ergebnisse analysieren können BP-05.05 Literaturempfehlungen

Das hier ist der „offizielle“ Prüfungskatalog für den Fachinformatiker Anwendungsentwicklung:

• Fachinformatiker / Fachinformatikerin – Anwendungsentwicklung Prüfungskatalog für die IHK-Abschlussprüfung

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Ich habe meine Themenliste zur AP2 als FIAE natürlich passend zu den Änderungen aktualisiert: Mögliche Themen von Teil 2 der gestreckten Abschlussprüfung (GAP) für Fachinformatiker Anwendungsentwicklung

Um die Änderungen im Prüfungskatalog für die AP1 der IT-Berufe ab 2025 geht es in der einhundertneunzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Zur AP1 (Gestreckte Abschlussprüfung Teil 1) der IT-Berufe im Frühjahr 2025 gilt ein neuer Prüfungskatalog. Ich habe die Unterschiede zusammengestellt.

Zusammenfassung

Die folgenden Punkte fassen die zentralen Änderungen (aus meiner Sicht) zusammen.

Zusätzliche bzw. genauer spezifizierte Inhalte

• Projekte
  • Projektmerkmale
  • SMART-Prinzip
  • Wirtschaftlichkeit
  • Wasserfallmodell und Scrum
• Künstliche Intelligenz (KI)
• Software
  • Softwareprodukte wie ERP, SCM, CRM
  • Social Media
  • Barrierefreiheit auf Websites
• Netzwerkadministration
  • Einbindung eines PCs in eine Domäne
  • IPv4 und IPv6
• HDD vs. SSD
• Übertragungsraten, -zeiten und Datenmengen berechnen
• UML-Aktivitätsdiagramm
• Fehler in Code finden und Schreibtischtest durchführen
• IT-Sicherheit
  • Schutzziele (Vertraulichkeit, Verfügbarkeit, Integrität)
  • Hashverfahren
  • Zweifaktorauthentifizierung (2FA)
  • Härtung von Betriebssystemen
• Datenschutz
  • Betroffenenrechte nach DSGVO
  • Anonymisierung und Pseudonymisierung

Gestrichene Inhalte

• Projekte
  • Weitere Vorgehensmodelle außer Wasserfall und Scrum
  • SWOT-Analyse (Stärken/Schwächen)
• Hardware
  • SAN
  • RAID
• LTE und 5G
• Programmierung
  • Vererbung in der Objektorientierung
  • Struktogramm (Nassi-Shneiderman) und Programmablaufplan
  • Softwarequalitätskriterien
• Datenbanken
  • Alle nicht-relationalen Datenbanken
  • SQL
• ISO-Normen wie die 2700x
• Dokumentationen

Detaillierter Vergleich der bisherigen und neuen Inhalte des Prüfungskatalogs für die AP1 der IT-Berufe

In der folgenden Tabelle habe ich alle Unterschiede zwischen altem (ab 2020) und neuem (ab 2025) Prüfungskatalog für die AP1 der IT-Berufe gegenübergestellt.

• Rote Punkte habe ich im neuen Prüfungskatalog nicht wiedergefunden. Sie werden daher in den neuen Prüfungen nicht mehr erwartet.
• Grüne Punkte habe ich im alten Prüfungskatalog nicht wiedergefunden. Sie werden daher in den neuen Prüfungen zusätzlich erwartet.
• Wenn sich lediglich Formulierungen oder Aufteilungen geändert haben, aber die Punkte inhaltlich gleich geblieben sind, stehen sie gar nicht in der Tabelle.
• Wenn Punkte an andere Stellen im Prüfungskatalog verschoben wurden, habe ich das in den Spalten Alter Unterpunkt und Neuer Unterpunkt gekennzeichnet.
• Meine persönliche (!) Bewertung (hin und wieder leicht ironisch) der Änderungen stehen in der Spalte Kommentar.
• Ein „x“ in Spalte wichtig deutet auf eine zentrale Änderung hin, die sich meiner Meinung nach merklich auf die Prüfungsvorbereitung der Azubis auswirkt.

Unterpunkt Alter Inhalt Neuer Inhalt Alter Unterpunkt Neuer Unterpunkt Kommentar wichtig 01.01 Merkmale eines Projektes war vorher tatsächlich nicht explizit genannt 01.01 SMART-Prinzip 01.01 Projektphasen Projektphasen am Beispiel des Wasserfallmodells bzw. SCRUM definieren können 01.01 Vorgehensmodelle XP, Kanban etc. werden dann wohl nicht mehr benötigt x 01.01 Teambildung und -entwicklung Phasen der Teambildung und -entwicklung kennen 01.02 Machbarkeit von Projekten beurteilen können Machbarkeit und Wirtschaftlichkeit von Projekten beurteilen können sinnvoll auch für das Abschlussprojekt 01.02 Vor- und Nachkalkulation 01.02 Stammdaten und Bewegungsdaten naja, wer arbeitet schon mit Daten!? 01.02 Betriebswirtschaftliche Kennzahlen, z. B. Umsatz, Gewinn, Deckungsbeitrag 07.02 Deckungsbeitrag war wohl zu schwierig 01.03 KI-Unterstützung muss heutzutage halt sein x 01.03 Supportanfragen Support- und Serviceanfragen (First-, Second- und Thirdlevelsupport) sinnvoll, die einzelnen Typen zu nennen 02.01 Angebotsbewertung Quantitative und qualitative Angebotsbewertung 02.02 Benchmarking hat eh niemand verwendet 02.02 Fragetechnik, aktives Zuhören, bedarfs- und adressatengerechte Präsentation ist auch schwer schriftlich abzufragen 02.03 Medien zur Kundenpräsentation und -Information, z. B. Kundengespräch via Webinaren Situationsgerechte Kundenkommunikation 02.03 Eisbergmodell 02.03 Cross-Selling; Upselling ist ja auch sehr Sales-lastig 02.03 Kundenbedarf ermitteln und Angebote unterbreiten 02.03 Interpretation englischsprachiger Texte 02.04 Technische und nicht-technische Texte; Auswertung von englischen Texten Technische und kaufmännische Texte in deutscher und englischer Sprache 02.04 Digitale Suchabfragen unter Verwendung von Suchoperatoren finde ich trotz KI weiterhin wichtig 02.04 Qualitätsmerkmale von Präsentationen; Medienkompetenz Präsentation und Medienkompetenz 02.05 Stärken-/Schwächenanalyse schade um die gute alte SWOT-Analyse 03.01 Funktionale, ökonomische, ökologische, soziale Aspekte Funktionale, ökonomische und ökologische Aspekte, z. B. Ergonomie, Leistungsparameter, einmalige und laufende Kosten, Nutzungsdauer, Energieverbrauch, Recyclingfähigkeit 03.01 Hardwareprodukte, z. B. CPU, Motherboard, Speicher, Datenspeicher, Netzteile, Grafikkarte, Peripheriegeräte, Netzwerkkomponenten, WLAN Hardwareprodukte, z. B. CPU, Motherboard, Speicher, Datenspeicher, Netzteile, Grafikkarte, Peripheriegeräte, Sensoren, Netzwerkkomponenten wie z. B. WLAN-Router, Switch, Gateway, Accesspoint das IoT lässt grüßen 03.01 Standardsoftware, z. B. Office-Pakete, Datenbank-Managementsysteme, Browser 03.01 Branchensoftware, z. B. ERP-Systeme, Supply Chain Management, Customer Relationship 04.03 ich hätte schwören können, dass das vorher schon drin stand x 03.01 Systemsoftware 03.01 Entwicklungssysteme, z. B. Compiler, virtuelle Maschinen, Interpreter, Editoren und Debugger 04.06 03.01 KI-Software ok, wir haben es verstanden, KI ist wichtig x 03.01 Cloudlösungen (Software as a Service, Infrastructure as a Service, Platform as a Service) Cloudlösungen, z. B. Software as a Service, Desktop as a Service 03.01 Virtualisierungen Virtuelle Desktops (Cloud oder lokal) also keine virtuellen Server mehr!? 03.02 Einteilung und Klassifikation von Anwendungssystemen 03.01 damit waren wohl CRM usw. gemeint 03.02 Benutzeroberfläche 03.02 Datenbanksysteme 03.01 03.02 Kommunikationssysteme Kommunikationssysteme, z. B. Videokonferenzsysteme, Social-Media-Systeme Social Media ist fast so wichtig wie KI 03.02 Netzwerkkomponenten, z. B. Router, Switch, Accesspoint 03.01 03.02 Netzwerkprotokolle, z. B. OSI-Modell, DNS, SMB, NFS, SMTP/S, IMAP/S, HTTP/S, IPSEC, IP, TCP, UDP, SSH, DHCP, ARP, TLS Netzwerkprotokolle (z. B. Ethernet, IP, DNS) und OSI-Modell die Liste der vorher aufgezählten Protokolle veraltet wohl zu schnell 03.02 Client-Server-Systeme spannend, dass so ein grundlegender Inhalt vorher fehlte 03.02 Einbindung in einer Domäne 03.02 Mobile Geräte, z. B. Smartphone, Tablet 04.02 03.03 Kenngrößen, Leistungsdaten, Funktionsumfang, z. B. BIOS, UEFI, CPU, RAM, Datenspeicher, RAID, Filesysteme, Grafikkarte, Netzwerkkarte, Router, Switch, LWL, Ethernet Standards, WLAN Standards Kenngrößen, Leistungsdaten, Funktionsumfang, z. B. Einstellungsmöglichkeiten im BIOS, UEFI, CPU, RAM, Datenspeicher (SSD/HDD), Filesysteme (z. B. FAT32, NTFS, APFS, ext4), Grafikkarte, Netzwerkkarte, Gateway/Router, Switch, LWL, Ethernet Standards, WLAN-Standards goodbye RAID, hello SSD x 03.03 Barrierefreier Zugriff auf IT-Systeme Barrierefreier Zugriff auf IT-Systeme am Arbeitsplatz, z. B. Einstellungsmöglichkeiten auf Webseiten da hat wohl jemand was vom Barrierefreiheitsstärkungsgesetz gehört x 03.03 Übertragungsraten, -Zeiten, Datenmengen von digitalisierten Dokumenten, Videos usw. war gefühlt in jeder Prüfung, aber stand noch nie im Katalog x 03.04 Auslastung und Anpassungsfähigkeit/Erweiterbarkeit, Zukunftssicherheit 03.04 Wertschöpfung 04.01 Lasten- und Pflichtenheft Lasten- und Pflichtenheft (Zweck, Urheber, Inhalt) 04.01 Installation und Einrichtung von Systemen, z. B. Betriebssysteme, BIOS, UEFI, Partitionierungen/Formatierungen, Netzwerkanbindungen, IP-Konfiguration, Remotedesktop Installation und Einrichtung von Systemen, z. B. Betriebssysteme, BIOS, UEFI, Partitionierungen/Formatierungen, Netzwerkanbindungen, IP(v4/v6)-Konfiguration, Remote-Desktop, KI-Software klein und unscheinbar haben die hier IPv6 reingeschmuggelt x 04.02 Geräteklassen, z. B. Desktops, Notebooks, Tablets, Smartphones Geräteklassen, z. B. Desktops, Notebooks, All-in-One, Thin Clients, Tablets, Smartphones 04.02 Mobile und stationäre Arbeitsplatzsysteme wie PC, Terminals, LAN, WLAN, mobiler Datenfunk (LTE/5G) Mobile und stationäre Arbeitsplatzsysteme wie PC, Terminals, LAN, WLAN warum LTE und 5G rausfliegt, kann ich nicht nachvollziehen x 04.02 Barrierefreiheit, z. B. Arbeitsplatz mit zweitem Monitor ausstatten, Lautsprecher/Mikrofon zur Verfügung stellen Barrierefreiheit, Unterstützung durch zusätzliche Hardware, z. B. größerer Monitor, breitere Tastatur, Lautsprecher/Mikrofon zur Verfügung stellen 04.03 Betriebssysteme Betriebssysteme (Einsatzzweck, Filemanagement, Freigaben managen) der Punkt war vorher auch viel zu umfangreich 04.03 Branchensoftware 03.01 04.03 KI-Software wir haben es jetzt verstanden! 04.04 Grundlagen des Schutzes der Urheber 04.05 Konsolenbefehle für Dateioperationen und Netzwerktroubleshooting, z. B. dir, Is, mkdir, ipconfig, ifconfig, alias, iproute2, arp, del, cp, copy, chmod, ping, traceroute Konsolenbefehle für Dateioperationen und Netzwerktroubleshooting, z. B. dir, Is, mkdir, ipconfig, ifconfig/ip, alias, iproute2, arp, del, cp, copy, chmod, ping, traceroute, nslookup ip und nslookup hätte ich früher erwartet 04.06 Klassen, Vererbung, Methoden Klassen, Attribute, Objekte, Methoden, Sichtbarkeit ui, endlich private und public in der AP1, aber dafür keine Vererbung mehr x 04.06 Skriptsprachen, z. B. Shell-Skript, Macros Skriptsprachen, z. B. Shell-Skript 04.07 Abbildung der Kontrollstrukturen mittels Struktogramm, PAP oder Pseudocode als didaktisches Hilfsmittel Abbildung der Kontrollstrukturen, z. B. Verzweigungen, Schleife, mittels Pseudocode goodbye Struktogramm und PAP x 04.07 UML (Use Case, Klassendiagramm) UML (Use Case bzw. Anwendungsfalldiagramm, Klassendiagramm, Aktivitätsdiagramm) hello Aktivitätsdiagramm x 04.07 Entwurf der Bildschirmausgabemasken (Softwareergonomie, Barrierefreiheit) Entwurf der Bildschirmausgabemasken (Softwareergonomie, Corporate Identity, Barrierefreiheit) 04.07 Fehler in einem gegebenen Quellcode finden alle ITler:innen sollten Quellcode verstehen x 04.07 Schreibtischtest mit einem gegebenen Quellcode durchführen x 04.08 Grundlagen von Datenbanken kennen und anwenden können Grundlagen von relationalen Datenbanken kennen und anwenden können goodbye NoSQL x 04.08 SELECT bezogen auf eine Tabelle goodbye SQL x 05.01 Qualitätsbegriff nach ISO 9000 05.01 Audit 05.02 Maßnahmen zur Verbesserung der Prozessqualität 05.02 Maßnahmen zur Verbesserung der Arbeitsqualität 05.02 Maßnahmen zur Verbesserung der Produkt- und Dienstleistungsqualität 05.02 Kriterien der Softwarequalität, Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit, Übertragbarkeit zugegeben, das war sehr FIAE-lastig x 05.02 Testprotokoll für das Einrichten eines Arbeitsplatzes was soll das sein? x 06.01 Gewährleistung von Verfügbarkeit, Vertraulichkeit und Integrität der Daten die Schutzziele wurden vorher tatsächlich nicht genannt x 06.01 organisatorische Maßnahmen, z. B. IT-Sicherheitsbeauftragter im Betrieb, Erstellung einer IT-Sicherheitsrichtlinie, z. B. Passwort-Policy Technisch organisatorische Maßnahmen (TOM); Unterscheidung von IT-Sicherheitsbeauftragtem und Datenschutzbeauftragtem im Betrieb; Erläuterung von IT-Sicherheitsrichtlinien wie Passwort-Policy 06.01 technische Maßnahmen, z. B. Virenschutzsystem, Firewall, Anti-Spam Benennung von technischen Maßnahmen, z. B. Virenschutz, Personal Firewall, Verschlüsselung (inkl. Unterscheidung symmetrisch, asymmetrisch und hybrid) 06.04 anscheinend sind nur noch Personal Firewalls relevant 06.01 personelle Maßnahmen, Sicherheitsbewusstsein herstellen personelle Maßnahmen, Entwicklung des Sicherheitsbewusstseins 06.01 Normen und Branchenstandards zur Informationssicherheit, Z. B. 06.01 ISO 2700x ich finde keine ISO-Norm mehr im neuen Katalog 06.01 BSI IT-Grundschutz Auszüge aus BSI IT-Grundschutz-Kompendium das ganze Ding hat ja auch mehrere hundert Seiten 06.01 Datenschutzgesetze national und auf EU-Ebene, z. B. DSGVO, BDSG Einhaltung der Grundzüge der Datenschutzgesetze, national und auf EU-Ebene, z. B. DSGVO, BDSG überprüfen auch diese Gesetze sind sehr umfangreich 06.01 Rechte der Betroffenen, Konsequenzen der Einwilligung der Betroffenen kennen x 06.01 Maßnahmen wie Anonymisierung und Pseudonymisierung x 06.02 Schutzbedarfsanalyse im eigenen Arbeitsbereich durchführen Schutzbedarfsanalyse im eigenen Arbeitsbereich aufgrund betrieblicher Vorgaben nach BSI IT-Grundschutz durchführen 06.02 Räume Räume, Infrastruktur 06.03 Schutzbedarfskategorien (normal, hoch, sehr hoch) Schutzbedarfskategorien (normal, hoch, sehr hoch) ableiten und begründen 06.03 IT-Sicherheitsmanagementsystem implementieren Informations-Sicherheitsmanagementsystem (ISMS) kennen und unterstützen 06.03 Betrieblicher IT-Sicherheitsbeauftragter 06.01 06.03 Risiko-Klassifikation, z. B. mit Matrix 06.04 Sicherung der Verfügbarkeit, z. B. RAID-Systeme, SAN Sicherung der Verfügbarkeit, z. B. NAS goodbye RAID und SAN x 06.04 Verschlüsselungstechniken, symmetrische und asymmetrische Verschlüsselung, CAs, Zertifikate, Digitale Signaturen, Techniken wie https, TLS Verschlüsselungstechniken kennen (symmetrische, asymmetrische und hybride Verschlüsselung); Hashwerte, Zertifikate und digitale Signaturen verwenden Hashes wurden vorher tatsächlich auch nicht erwähnt x 06.04 Authentifizierung, Passwort-Policy Authentifizierung (z. B. Zweifaktor) kennen, Passwort-Policy bewerten 06.04 Firewall, SSH vs. Telnet Personal Firewall anpassen, z. B. Softwarezugriff auf Internet sperren 06.04 Härtung Betriebssystem (Schwachstellen schließen) das ist sinnvoll x 07.01 Vertragsbestandteile, z. B. Leistungsbeschreibung, Termine, Entgelte, Lasten- und Pflichtenheft, Konventionalstrafen Vertragsbestandteile, z. B. Leistungsbeschreibung, Termine, Entgelte, Sanktionen/Konventionalstrafen 07.01 Verzug Vertragsstörungen nicht mehr nur der Verzug ist wichtig x 07.02 Ökologisch Ökologisch, z. B. Ressourcenschonung, Nachhaltigkeit 07.02 Ökonomisch (z. B. prozentuale Marge) Ökonomisch, z. B. Umsatz und Gewinn 07.02 Sozial Sozial, z. B. Arbeitsbedingungen 07.03 Abstimmen der dokumentierten Vorgaben zur Leistungserbringung während des gesamten Zeitraums mit dem Auftraggeber da konnte ich mir eh nie etwas drunter vorstellen 07.03 Kontinuierliche Prüfung der vertraglich vereinbarten Vorgaben 07.03 Berücksichtigung der Stilllegung von Altsystemen und Inbetriebnahme der neuen Systeme 07.03 Aufbewahrung von Archivdaten 07.03 Vollständige Dokumentation der erbrachten Leistung 07.04 Kauf, Miete, Leasing 03.04 07.04 Rolloutprozesse 07.04 Vorbereitung (Kunden-Onboarding, Scope festlegen, Formalitäten); 07.04 Rolloutumsetzung (Integration von Schnittstellen, kundenspezifische Entwicklungen) 07.04 Ticketsystem 01.03 07.04 Einhaltung des Budgets als ob sich ITler für Budgets interessieren 07.07 Inhalt des Abnahmeprotokolls, z. B. Gegenstand der Abnahme; Beteiligte Personen; Ort, Datum und Uhrzeit Inhalt des Abnahmeprotokolls 07.07 Arten der zu übergebenden Dokumentation, z. B.; Benutzerdokumentation (Handbuch); Schnittstellendokumentation; Programmdokumentation (Source-Code); Netzwerkdokumentation; Testprotokolle richtig so! niemand braucht Dokumentationen 07.07 Schlechtleistung, z. B. fehlende Funktionalität Schlechtleistung 07.07 Falschlieferung, z. B. falsche Softwarepakete ausgeliefert Falschlieferung 07.07 Minderlieferung, z. B. nur Teile der Software geliefert Minderlieferung 07.08 Bestätigung erbrachter Leistungen 07.08 Nachkalkulation 07.08 Generierung von Nachfolgeaufträgen Literaturempfehlungen

Das hier sind die „offiziellen“ Prüfungskataloge für die vier Fachrichtungen des Fachinformatikers. Die Inhalte für AP1 sind natürlich überall identisch.

• Fachinformatiker / Fachinformatikerin – Anwendungsentwicklung Prüfungskatalog für die IHK-Abschlussprüfung
• Fachinformatiker / Fachinformatikerin – Systemintegration Prüfungskatalog für die IHK-Abschlussprüfung
• Fachinformatiker / Fachinformatikerin – Digitale Vernetzung Prüfungskatalog für die IHK-Abschlussprüfung
• Fachinformatiker / Fachinformatikerin – Daten- und Prozessanalyse Prüfungskatalog für die IHK-Abschlussprüfung

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Ich habe meine Themenliste zur AP1 natürlich passend zu den Änderungen aktualisiert: Mögliche Themen von Teil 1 der gestreckten Abschlussprüfung (GAP) in den IT-Berufen

Die Unterscheidung von Lastenheft und Pflichtenheft ist Thema der einhundertneunundachzigsten Episode des IT-Berufe-Podcasts.

Inhalt Kurzübersicht Lastenheft

• Definition laut DIN 69901-5: „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages“.
• Verfasst von: Auftraggeber, also aus Sicht des Kunden.
• Inhalt: Lösungsneutrale funktionale und nicht-funktionale Anforderungen an ein Produkt, eine zu erstellende Software oder ein Projektergebnis aus Sicht des Auftraggebers.
• Fragen: WAS soll erreicht werden? WARUM ist das wichtig? WOFÜR wird das benötigt? WER will das haben?
• Ziel: Basis, um Angebote von potenziellen Auftragnehmern einzuholen. Es bildet die Grundlage für das vom Auftragnehmer zu erstellende Pflichtenheft.
• Rechtliche Relevanz: keine
• Mögliche Inhalte
  • Anforderungen der Stakeholder (z.B. Fachlichkeit, Regualatorik, Usability, Performance, Hardware-/Netwerk-/Softwareumgebung)
  • Ist-Zustand und Soll-Zustand
  • Abnahmekriterien für die Prüfung, ob die Anforderungen erfüllt sind
  • Einschränkungen bei zu verwendenden Technologien
  • Anforderungen an den Auftragnehmer (z.B. Zertifizierung)
  • Schnittstellen
  • Sonstige Anforderungen (z.B. Dauer, Kosten, Meilensteine)

Kurzübersicht Pflichtenheft

• Definition laut DIN 69901-5: „vom Auftragnehmer erarbeitete[n] Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts“.
• Verfasst von: Auftragnehmer, also aus Sicht des Dienstleisters.
• Inhalt: Vorschlag für technische Lösung der Anforderungen aus dem Lastenheft.
• Fragen: WIE sollen die Anforderungen umgesetzt werden? WELCHE Technologien kommen zum Einsatz?
• Ziel: Konkretes Angebot eines Auftragnehmers, um die Anforderungen aus dem Lastenheft des Auftraggebers zu erfüllen. Basis für die Kalkulation von Kosten/Aufwänden und das Erstellen eines Angebots. Definiert die Vorgaben für die spätere Implementierung.
• Rechtliche Relevanz: wird Vertragsbestandteil und dient zur Abnahme der erbrachten Leistung
• Mögliche Inhalte
  • Spezifikationen des geplanten Ergebnisses bzw. die technische Realisierung, z.B. Architektur, Technologien, UML-Diagramme, ER-Modelle, geplante Prozessabläufe, UI-Entwürfe
  • Entwicklungsprozess, Projektplan mit Meilensteinen, Vorgaben zur Kommunikation
  • Ressourcen wie konkrete Personen, Subunternehmen, Technologien

Definitionen aus dem IT-Handbuch

Beginnen wir mit einer Definition der Begriffe. Dafür schaue ich immer gerne in das IT-Handbuch*, das bis vor einigen Jahren noch der „offizielle“ Prüfungsbegleiter war und als Nachschlagewerk mit in die Prüfung genommen werden durfte. Dort werden Lasten- und Pflichtenheft wie folgt definiert:

Lastenheft

Das Lastenheft enthält alle Forderungen des Auftraggebers (Kunden) an die Lieferungen und/oder Leistungen eines Auftragnehmers. Die Forderungen sind aus Anwendersicht einschließlich aller Randbedingungen zu beschreiben. Diese sollten quantifizierbar und prüfbar sein. Im Lastenheft wird definiert, was für eine Aufgabe vorliegt und wofür diese zu lösen ist.

Pflichtenheft

Das Pflichtenheft enthält das vom Auftragnehmer erarbeitete Realisierungsvorhaben auf der Grundlage des Lastenheftes. Das Pflichtenheft enthält als Anlage das Lastenheft. Im Pflichtenheft werden die Anwendervorgaben detailliert und in einer Erweiterung die Realisierungsforderungen unter Berücksichtigung konkreter Lösungsansätze beschrieben. Im Pflichtenheft wird definiert, wie und womit die Forderungen zu realisieren sind.

Gut verständlich finde ich auch die Erläuterungen in der Wikipedia, die sich auf die DIN 69901 stützen (die leider nicht kostenfrei verfügbar ist):

Lastenheft

Gemäß DIN 69901-5 […] beschreibt das Lastenheft die „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages“. Das Lastenheft beschreibt in der Regel somit, was und wofür etwas gemacht werden soll. [Herv. d. Verf.]

Pflichtenheft

Das Pflichtenheft beschreibt in konkreter Form, wie der Auftragnehmer die Anforderungen des Auftraggebers zu lösen gedenkt – das sogenannte wie und womit. […] Laut DIN 69901-5 umfasst das Pflichtenheft die „vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts“. [Herv. d. Verf.]

Vor- und Nachteile von Lasten- und Pflichtenheft

• Gute Planungssicherheit für den Auftraggeber. Er weiß genau, was er bekommt und wie teuer es wird.
• Eher starres Vorgehen ist nur geeignet für Projekte, die für einen langen Zeitraum unverändert bleiben (Wasserfallmodell).
• Das Erstellen der Dokumente ist sehr aufwändig und zeitintensiv.
• In agilen Vorgehensmodellen wie Scrum werden sie nicht verwendet.
• Alternative: Arbeit in Inkrementen, Minimum Viable Product

Relevanz für die Praxis und die IHK-Projektarbeit

Lasten- und Pflichtenheft sind zwei Artefakte, die ich in (fast) jeder IHK-Projektdokumentation erwarte. Da die Abschlussprojekte eine genaue Zeitvorgabe haben (40 bzw. 80 Stunden) und auch die Anforderungen zu Beginn komplett feststehen (sollten), eignen sich Lasten- und Pflichtenheft gut für die Dokumentation der Anforderungen.

Wenn man eine Priorisierung durchführen müsste, würde ich mehr Gewicht auf das Pflichtenheft legen, da dieses die Grundlage für den Vertrag zur Erstellung der Software ist. Das heißt, die Abnahme am Ende des Projekts erfolgt „gegen“ das Pflichtenheft. Was dort nicht enthalten ist, wird auch nicht umgesetzt.

Das ist übrigens auch eine häufige Frage im Fachgespräch: Warum ist das Pflichtenheft so wichtig? Weil es Vertragsbestandteil ist. Die Abgrenzung zwischen Lasten- und Pflichtenheft wird übrigens auch gerne als Prüfungsfrage (schriftlich und mündlich) genommen.

Aber auch im realen Leben haben Lasten- und Pflichtenheft ihre Daseinsberechtigung in bestimmten Projekten, z.B. wenn es um sicherheitskritische Produkte geht, die nicht „mal eben“ agil entwickelt werden können/dürfen.

Wer erstellt das Lasten- und Pflichtenheft?

Wie die Definitionen oben nahelegen, sollte im Rahmen des IHK-Abschlussprojekts das Lastenheft vom Kunden bzw. der Kundin erstellt werden und das Pflichtenheft vom Prüfling. Der/die Kund:in formuliert, was er/sie gerne hätte (also die fachlichen Anforderungen), und der Prüfling definiert die dazu passende konkrete technische Lösung.

In der Praxis ist es allerdings häufig so, dass Kunden ihre Anforderungen gar nicht genau kennen, geschweige denn sie so formulieren können, dass ein:e ITler:in sie versteht. Daher spricht nichts dagegen, dass Prüflinge schon beim Erstellen des Lastenhefts mitarbeiten.

Wenn du genau in die Zeitplanung von Gerdas und Markus‘ Dokumentation schaust, wirst du feststellen, dass bei uns im Unternehmen genau so gearbeitet wird. Es wurde nämlich im Rahmen der Projektplanung Zeit für die Unterstützung des Fachbereichs bei der Erstellung des Lastenhefts eingeplant. Die Entwickler:innen helfen den Kunden z.B. bei der Formulierung der Anforderungen, aber auch bei deren Identifikation. Gute Methoden dafür sind z.B. Brainstorming oder Interviews.

Aufbau und Formulierung

Zu Inhalt, Aufbau und (gerade für die Projektdokumentation interessant) Formulierung von Lasten- und Pflichtenheft gibt es keine harten Vorgaben. Letztlich bestehen beide Artefakte aus Prosa.

Lastenheft

Ich persönlich würde einen etwas „moderneren“ Ansatz wählen und im Lastenheft User-Storys verwenden (für Beispiele verweise ich wieder auf die beiden obigen Dokumentationen). Durch diese Vorgabe wird man bei der einheitlichen Formulierung unterstützt und muss sich nicht alles neu ausdenken.

Es gibt aber auch andere Ansätze, wie z.B. die richtig „enterprisey“ Volere-Templates. Da ist allein das Inhaltsverzeichnis aller möglichen Anforderungen schon ellenlang.

Pflichtenheft

Das Pflichtenheft sollte dann natürlich einige konkrete technische Artefakte beinhalten, da es ja so spezifisch wie möglich sein muss. Ich beschreibe es immer gerne so: Das Pflichtenheft muss man einem/einer Softwareentwickler:in ohne Kommentar auf den Tisch legen können und er/sie entwickelt dann allein auf dieser Basis die gewünschte Software. Dass das in der Praxis so nicht funktioniert (und auch nicht meine präferierte Umgangsweise ist) ist hoffentlich klar.

Man kann aber durchaus alle in der Entwurfsphase erstellten Artefakte ins Pflichtenheft packen: Use-Case-Diagramm, Klassendiagramm, Komponentendiagramm, ERM, Tabellenmodell, GUI-Mockups, Testszenarien usw. Wie gesagt: Was nicht im Pflichtenheft steht, wird nicht umgesetzt (und nicht bezahlt).

Berücksichtigung in der IHK-Projektdokumentation

Da sowohl Lasten-, als auch Pflichtenheft recht lang werden können, empfehle ich, in der Projektdokumentation ausschließlich Ausschnitte daraus abzubilden. Und damit meine ich nicht Deckblatt und Inhaltsverzeichnis (habe ich leider schon oft so gesehen), sondern die konkreten Anforderungen bzw. Lösungsvorschläge. Also zeig bitte interessante Inhalte und nicht unwichtigen Kram.

Da die Seiten in der Projektdokumentation begrenzt sind, kann man vielleicht sogar zwei Fliegen mit einer Klappe schlagen und Lasten-/Pflichtenheft sowie projektrelevante technische Inhalte daraus in nur einem Anhang zeigen. Beispiel: Das Pflichtenheft enthält ein Komponentendiagramm der geplanten Anwendung. Dann könnte der einseitige Auszug aus dem Pflichtenheft (die Seiten mit dem Komponentendiagramm) im Anhang der Dokumentation sowohl im Kapitel „Architektur“, als auch im Kapitel „Pflichtenheft“ referenziert werden. Einmal wird eben auf das Diagramm verwiesen und einmal auf das Pflichtenheft als erstelltes Artefakt.

Ich persönlich würde aber eher die für die Artefakte spezifischen Inhalte zeigen, also die formulierten Anforderungen. Denn das ist der eigentlich interessante Inhalt der beiden Dokumente im Rahmen der Projektdokumentation. Gerda und Markus haben das auch so gemacht.

Fazit

Lasten- und Pflichtenheft sind zwei wichtige Artefakte, die sowohl im richtigen Leben, als auch in der IHK-Abschlussprüfung relevant sind. Schau dir die Definitionen und einige Beispiele in Ruhe an und lerne sie auch für die Prüfung.

Literaturempfehlungen

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Was? Pflichtenheft und Lastenheft sind nicht dasselbe?
• DIN 69901 – Wikipedia
• Lastenheft – Wikipedia
• Pflichtenheft – Wikipedia

Um Teamarbeit bei der Softwareentwicklung geht es im Interview mit Christian Kranert in der einhundertachtundachzigsten Episode des IT-Berufe-Podcasts.

Inhalt Vorstellung Christian Kranert

Christian hat sich schon in Episode 164 des Podcasts über Softwarequalität ausführlich vorgestellt, aber hier noch einmal die wichtigsten Eckdaten.

• Christian Kranert
• seit 17 Jahren in der IT und Softwareentwicklung tätig
• angefangen mit Visual Basic 6 auf Windows 95
• Ausbildung zum Fachinformatiker für Anwendungsentwicklung absolviert
• viel im SAP-Umfeld mit ABAP entwickelt
• inzwischen hauptsächlich mit C# unterwegs
• lebt und arbeitet in Nürnberg bei Head On Solutions GmbH
• entwickelt dort Cloud-Software für lokale Geschäfte wie Friseur-Studios zum Planen von Terminen, Kassieren, Buchhaltung usw.
• ist Abteilungsleiter mit eigenem Team

Teamarbeit in der Softwareentwicklung Warum brauchen wir Teamarbeit bei der Softwareentwicklung?

• bei der Komplexität heutiger Software ist es fast undenkbar, diese alleine zu entwickeln
• heutige Webanwendungen enthalten z.B. sehr viel UI-Entwicklung und sind im Backend und Frontend sehr komplex, Stichwort: Full Stack
• Christians Unternehmen hat ein eigenes Team ausgelagert nur für VueJS im Frontend
• durch das Team entsteht auch bessere Software
• wir wollen doch die „echte Welt“ übersetzen in Code und dort gibt es auch mehr als einen Benutzer
• gemeinsam zu entwickeln macht mehr Spaß, ist sozial, man kann voneinander lernen, man kann sich weiterentwickeln
• die interdisziplinäre Zusammenarbeit mit dem Fachbereich bzw. Kunden ist auch extrem wichtig

Wie sieht erfolgreiche interdisziplinäre Zusammenarbeiten zwischen dem IT-/Entwicklungs-Team und anderen Abteilungen aus?

• der Fachbereich erklärt den Entwickler:innen die Fachlichkeit
• Entwickler:innen dürfen/müssen das aber auch hinterfragen und ggfs. bessere Lösungen vorschlagen
• man sollte erst über das Problem reden und nicht schon über Lösung
• es muss die generelle Bereitschaft zur Teamarbeit vorhanden sein und eine entsprechende Kultur

Welche Prozessmodelle (z.B. Wasserfall, Scrum) unterstützen/behindern die Teamarbeit?

• das klassische Wasserfallmodell ist eher hierarchisch aufgebaut mit Lasten-/Pflichtenheft und passt nicht so gut zur Teamarbeit
• Scrum ist aber auch kein Allheilmittel
• das Daily ist sehr wichtig, denn Kommunikation ist der Schlüssel zu erfolgreicher Teamarbeit

Wie sieht richtig gute Teamarbeit in der Softwareentwicklung aus?

• Kommunikation ist das A und O, z.B. wenn ein Feature fertig ist, damit die Kolleg:innen darauf aufsetzen können
• alle Teammitglieder:innen sollten auch aktiv Hilfe anbieten und einfordern
• die gesamte Softwareentwicklung ist Teamarbeit und die geht schon mit der Produktidee los
• dabei kann es helfen, verschiedene Perspektiven einzunehmen, um ein besseres Bild der Anforderungen zu bekommen
• auch weitere Aufgaben lassen sich besser im Team lösen: Risiken abschätzen, Prioritäten ableiten, Product Backlog füllen
• wenn das Verhältnis von Kosten und Nutzen passt, startet die Implementierung und Aufgaben werden im Team verteilt
• in Christians Team werden Konzepte z.B. gemeinsam erarbeitet, ganz einfach in OneNote*
• das Team startet mit einem Datenmodell als Diskussionsgrundlage und legt dann die Datentypen fest
• außerdem werden Mockups erstellt, um darüber gemeinsam zu diskutieren
• sehr wichtig ist auch das gemeinsame Festlegen von Namen im Team, denn viele Köpfe haben mehr (fachliches) Wissen als einer alleine
• der große Vorteil bei dieser Vorgehensweise ist, dass früh erkannte Fehler bei Anpassungen wenig kosten im Vergleich zu späteren Projektphasen, wenn alles schon umgesetzt ist

Warum ist die Teamkultur nicht nur beim Code Review wichtig und wie sieht sie aus?

• Christians Team entwickelt oft im Pair Programming zusammen und führt danach noch Code Reviews durch
• hier war oft insb. beim Testen die Einstellung, dass das doch jemand anders macht und nicht die Aufgabe der Softwareentwickler:innen sei
• aber gerade beim Testen ist die Abstimmung mit den Tester:innen wichtig, damit man nicht den kompletten Code umschreiben muss, wenn man am Test vorbei entwickelt hat

Wie stellt man sicher, dass alle Teammitglieder:innen sich aktiv einbringen und wie kann eine Führungskraft Teamarbeit fördern/behindern?

• die Führungskraft ist sehr wichtig, denn ihre zentrale Aufgabe ist die Pflege der Teamkultur
• die häufig anzutreffene Skepsis bei Entwickler:innen gegenüber Meetings muss von der Führungskraft abgebaut werden
• Meetings müssen aber natürlich auch einen Mehrwert für alle Teilnehmer:innen bieten und müssen vernünftig geplant und vorbereitet werden
• auch für Entwickler:innen sind Meetings wichtig, da sie helfen, offene Fragen zu klären und Entscheidungen herbeizuführen
• Teamarbeit kann die Teammitglieder:innen motivieren, wenn man gemeinsam eine gute Lösung findet und z.B. eine „harte Nuss“ knackt

Braucht ein Team eine Leitung?

• das kommt stark auf das Team an

Storming, Forming, Norming, Performing: gibt es das wirklich in der Praxis?

• Christian hat das mal in einem Buch gelesen, aber nur dunkel in Erinnerung
• in der Praxis durchlaufen die Teams diese Phasen wohl tatsächlich, aber intuitiv verhalten sich die Mitglieder:innen meist den Phasen entsprechend

Wie sieht häufig die (negative) Realität in Sachen Teamarbeit aus bzw. an welchen Fehlern scheitert Teamarbeit häufig?

• Juniors werden vernachlässigt und bekommen keine oder zu wenig Unterstützung
• Hierarchiedenken, gerade wenn Softwareentwicklung nicht das Kerngeschäft des Unternehmens ist
• Introvertiertheit der Teammitglieder:innen
• aber auch Extrovertiertheit bzw. Egozentrik bei Teammitglieder:innen
• Mangel an Diversität im Team

Wie wird man als Entwickler:in „teamfähig“?

• Persönlichkeitsentwicklung! dazu gibt es viele gute Bücher
• eine fördernde und fordernde Führungskraft ist wichtig für das Empowerment der Teammitglieder:innen
• die Führungskraft sollte z.B. One-on-Ones mit Mitarbeitenden führen, immer wieder nachfragen und auch die eigene Entwicklung aufzeigen
• loben und wertschätzen sollten bei jeder Führungskraft dazu gehören
• Empathie ist auch wichtig
• Konflikte sollten schnell gelöst werden

Wie wichtig ist eine gute Fehlerkultur?

• sehr wichtig
• Fehler müssen erlaubt sein und dürfen nicht „geahndet“ werden
• aber was ist eigentlich ein Fehler? Schludrigkeit ist sicherlich kein Fehler
• Checklisten können helfen, eine gewisse Basisqualität sicherzustellen

Wie können schon Azubis in die Teamarbeit integriert werden?

• einfach mal loslegen und sie an die Hand nehmen
• Azubis direkt in echte Projekte einbinden, aber ohne harten Deadlines oder großes Fehlerpotential
• viel loben
• Checklisten helfen auch hier beim Einstieg

Was sind die Folgen, wenn nicht im Team gearbeitet wird?

• Christian hat noch nie jemanden kennengelernt, der/die sich aktiv gewehrt hat gegen Teamarbeit
• eher haben die Kolleg:innen evtl. Angst mitzumachen
• den berühmten „10x-Develover“ gibt es nicht, aber Seniors können als Multiplikatoren im Team wirken und Juniors voranbringen und damit das gesamte Team

Wie/wo kann man dich erreichen?

• LinkedIn

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Qualitätssicherung bei der Softwareentwicklung mit Christian Kranert
• Christian Kranert bei LinkedIn
• Head-on Solutions GmbH bei LinkedIn

Um Datenbanktransaktionen, die ACID-Prinzipien und Alternativen dazu geht es in der einhundertsiebenundachzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Datenbanktransaktionen sollten jedem/jeder ITler:in etwas sagen, da wir fast täglich mit datenbankgestützten Anwendungen arbeiten, egal, ob wir selbst diese Anwendungen programmieren oder „nur“ Abfragen gegen eine Datenbank durchführen.

Was ist eine Datenbanktransaktion?

Eine Transaktion ist eine Menge aus mehreren zusammenhängenden Datenbankoperationen, die gemeinsam als eine Einheit durchgeführt werden müssen.

Beispiele für Datenbanktransaktionen:

• Banküberweisung von 100 EUR von Konto DE123 auf Konto DE432
  • UPDATE konto SET kontostand = kontostand - 100 WHERE iban = 'DE123';
  • UPDATE konto SET kontostand = kontostand + 100 WHERE iban = 'DE432';
• Neuen Tag katze zu einem Blog-Post mit ID 123 hinzufügen
  • INSERT INTO tag (id, name) VALUES (1, 'katze');
  • INSERT INTO tag_post (post_id, tag_id) VALUES (123, 1);
• Neue Bestellung für einen Kunden mit ID 324 erfassen für Artikel 253
  • INSERT INTO bestellung (id, datum, kunde_id) VALUES (123, '2024-04-10', 324);
  • INSERT INTO bestellposition (bestellung_id, artikel_id, menge, preis) VALUES (123, 253, 1, 123.92);
• Neuen Tarifsatz einer Versicherung anlegen und bisherigen beenden
  • UPDATE tarif SET gueltig_bis='2024-04-10' WHERE id=122;
  • INSERT INTO tarif (id, gueltig_ab, beitrag) VALUES (123, '2024-04-10', 143.23);

Begriffsabgrenzung

Eine Datenbanktransaktion ist nicht zu verwechseln mit einer Transaktion im Geschäftsbetrieb, z.B. einer Überweisung bei einer Bank, dem Kauf eines Autos oder der Buchung eines Fluges.

Die ACID-Prinzipien

Datenbanktransaktion müssen/sollen bestimmten Kriterien genügen, die als ACID-Prinzipien bekannt sind.

• Atomarität/Atomicity: Alle Datenbankoperationen werden entweder vollständig gemeinsam durchgeführt oder gar nicht. Es kann nicht sein, dass nur einige Operationen durchgeführt werden und andere nicht. Dazu werden die Datenbankoperationen in eine Transaktion „eingeklammert“.
  • Beispiel: Bei der Banküberweisung darf nicht nur Geld abgebucht oder gutgeschrieben werden, sondern beide Buchungen müssen gemeinsam durchgeführt werden.
• Konsistenz/Consistency: Wenn die Datenbank vor der Transaktion in einem konsistenten Zustand war, dann muss sie es auch nach der Transaktion sein.
  • Beispiel: Bei der Banküberweisung bleibt der Gesamtbetrag an Geld gleich. Es entsteht kein Geld aus dem Nichts und es geht auch kein Geld verloren.
• Isolation/Isolation: Mehrere Transaktionen dürfen sich nicht gegenseitig beeinflussen. Hierzu folgen weiter unten verschiedene Maßnahmen zur Umsetzung.
  • Beispiel: Bei zwei parallelen Banküberweisungen vom gleichen Konto müssen beide Beträge nacheinander abgebucht werden und nicht nur der der zuletzt durchgeführten Transaktion.
• Dauerhaftigkeit/Durability: Die Daten müssen nach Abschluss der Transaktion persistent gespeichert sein und z.B. auch einen Systemausfall überstehen. Das wird durch sogenannte Transaktionslogs sichergestellt.
  • Beispiel: Wenn nach dem Abschluss einer Transaktion der Datenbankprozess abstürzt, müssen auch nach dem Neustart der Datenbank die aktualisierten Daten vorhanden sein.

Maßnahmen zur Wahrung der Isolation von Transaktionen

Wenn Transaktionen nicht isoliert voneinander ablaufen, können verschiedene Probleme in der Datenbank auftreten.

• Dirty Read: Veränderte Daten einer noch offenen Transaktion werden von einer anderen Transaktion gelesen und weisen somit einen „dreckigen“ Zustand auf, weil er noch nicht final ist.
  • Beispiel: Bei einem Ticketkauf geht die zweite Buchung schon vom veränderten Bestand der ersten Transaktion aus.
• Lost Updates: Wenn zwei Transaktionen gleichzeitig denselben Datensatz verändern, „gewinnt“ die Änderung der zuletzt durchgeführten Transaktion und die der ersten ist verloren.
  • Beispiel: Bei zwei Banküberweisungen wird der Kontostand auf den Ursprungsstand abzgl. der zweiten Überweisung gesetzt, aber ohne die erste Überweisung abzuziehen.
• Non-Repeatable Read: Wiederholte Lesevorgänge innerhalb einer Transaktion liefern unterschiedliche Ergebnisse.
  • Beispiel: Bei einer Flugbuchung wird geprüft, ob noch ausreichend Plätze frei sind, aber durch eine parallele Buchung wird bei der zweiten Abfrage ein unterschiedliches Ergebnis geliefert.
• Phantom Read: Während eine Transaktion Datensätze nach einem bestimmten Kriterium liest, werden weitere Datensätze zum gleichen Kriterium hinzugefügt/gelöscht/verändert.
  • Beispiel: Während der Durchschnittsberechnung von Gehältern von Mitarbeiter:innen wird ein neuer Mitarbeiter hinzugefügt, der beim Summieren des Gehalts noch nicht berücksichtigt wird, aber beim Zählen der Datensätze dann schon.

Die Datenbank kann verschiedene Transaktionsisolationsebenen implementieren, um den obigen Problemen entgegenzuwirken. Grundsätzlich werden dabei Sperren verwendet, um die gleichzeitige Verarbeitung der Daten einzuschränken. Es kann dabei eine Lesesperre und/oder eine Schreibsperre gesetzt werden, wodurch das gleichzeitige Lesen bzw. Schreiben eingeschränkt wird.

• Read Uncommitted: Es werden keine Sperren verwenden. Quasi kein Schutz vor obigen Problemen. Vergleichbar mit NO ACTION bei referenzieller Integrität.
• Read Committed: Für die gesamte Transaktion werden Schreibsperren auf alle beteiligten Objekte gesetzt, die verändert werden sollen. Lesesperren werden aber nur kurzzeitig gesetzt. Es können Non-Repeatable Read und Phantom Read auftreten.
• Repeatable Read: Es werden für die gesamte Transaktion Lese- und Schreibsperren auf alle beteiligten Objekte gesetzt. Nur Phantom Reads können noch auftreten (weil dabei zwei lesende Operationen mit unterschiedlichen Kriterien durchgeführt werden).
• Serializable: Die Datenbank verhält sich so, als würden die Transaktionen komplett separiert nacheinander („seriell“) durchgeführt. Dabei kann keines der obigen Probleme mehr auftreten, aber Transaktionen müssen ggfs. abgebrochen werden. Starten z.B. zwei Flugbuchungen für zwei Sitzplätze parallel auf dem Sitzplatzbestand von 2, wird die erste Transaktion den Bestand auf 0 reduzieren und die zweite Transaktion (die „gewartet“ hat) muss abbrechen, weil die Sitzplätze nun nicht mehr ausreichen.

Umsetzung in SQL

Mit der Transaction Control Language (TCL) gibt es eine eigene Familie an SQL-Befehlen, die sich nur um die Transaktionssteuerung kümmert. Hiermit können Datenbankoperationen zu einer Transaktion zusammengefasst werden.

• BEGIN TRANSACTION: Startet eine Datenbanktransaktion.
• COMMIT: Beendet eine Datenbanktransaktion und schreibt die Änderungen fest.
• ROLLBACK: Rollt eine Datenbanktransaktion zurück und verwirft alle Änderungen.

In vielen Datenbanken muss man nicht explizit Transaktionen starten und beenden. Sie verwenden ein sogenanntes Auto-Commit. Dabei wird jedes Statement in einer eigenen Transaktion durchgeführt.

Umsetzung in ORMs

Brauche ich als Softwareentwickler:in überhaupt Wissen über Datenbanktransaktionen? In modernen Entwicklungsprojekten werden doch sowieso objektrelationale Mapper (ORM) verwendet. Doch auch diese ORMs können natürlich nicht zaubern, sondern verwenden unter der Haube die normalen Datenbankoperationen. Daher ist auch bei Verwendung eines ORMs wichtig zu wissen, welche Operationen in einer gemeinsamen Transaktion durchgeführt werden müssen.

Dafür bieten viele ORMs entsprechende Befehle an. Jakarta EE hat sogar einen eigenen Standard dafür: Jakarta Transactions (JTA). Dort wird z.B. Annotation @Transactional verwendet. Diese wird an eine Java-Methode geschrieben, die dann automatisch innerhalb einer Datenbanktransaktion ausgeführt wird. Im Fall einer aufgetretenen Exception wird dabei dann automatisch ein Rollback durchgeführt.

CAP und BASE

Transaktionen nach den ACID-Prinzipien sind ein wichtiger Bestandteil vieler Datenbanksysteme. Sobald die Datenbank jedoch auf mehrere Knoten verteilt wird, können Transaktionen zu einem Problem werden. Das sogenannte CAP-Theorem besagt, dass es in einem verteilten System nicht möglich ist, alle drei Eigenschaften Konsistenz, Verfügbarkeit und Ausfalltoleranz gleichzeitig zu garantieren.

• Konsistenz (Consistency): Die Konsistenz meint in diesem Kontext den einheitlichen Datenstand über alle Datenbankknoten hinweg (und nicht die Konsistenz vor/nach einer Transaktion). Egal, welcher Knoten abgefragt wird, es werden immer die gleichen Daten zurückgegeben.
• Verfügbarkeit (Availability): Die Datenbank antwortet in akzeptabler Zeit auf alle Anfragen. Dabei kann es jedoch sein, dass nicht immer die aktuellsten Daten geliefert werden.
• Partitionstoleranz (Partition tolerance): Die Datenbank arbeitet auch weiter, wenn einzelne Knoten ausfallen.

Angenommen, die verteilte Datenbank soll zu jedem Zeitpunkt in einem konsistenten Zustand sein (also alle Informationen auf allen Knoten sollen identisch sein), dann führt ein Ausfall eines Knoten automatisch dazu, dass eine Transaktion fehlschlagen muss, da der ausgefallene Knoten nicht sofort aktualisiert werden kann. Die Konsistenz wäre dann zwar gewährleistet, aber die Partitionstoleranz nicht.

Da heutzutage viele Anwendungen tatsächlich mit verteilten Datenbanken arbeiten, wurde mit BASE ein Gegenentwurf zu ACID geschaffen. Das Wort ist etwas konstruiert, um das Gegenstück zu ACID zu bilden. Aus der Chemie kennen wir den Unterschied zwischen Säure („acid“) und Lauge („base“). Im Kern stellt ACID die Konsistenz eines Systems sicher, während BASE die Verfügbarkeit in den Vordergrund stellt.

• Basically Available: Die Datenbank ist grundsätzlich für alle Benutzer jederzeit erreichbar (hohe Verfügbarkeit).
• Soft state: Daten können sich im Laufe der Zeit verändern und temporäre („weiche“) Zustände annehmen, wenn mehrere Änderungen parallel durchgeführt werden.
• Eventual consistency: Irgendwann einmal werden die Daten in der Datenbank einen konsistenten Zustand erreichen. Bis dahin können Anfragen unterschiedliche Ergebnisse produzieren.
  • Vorsicht „false friend“: „eventually“ heißt auf Deutsch „schlussendlich“ und nicht „eventuell“. Es wird also immer Konsistenz erreicht, nur eben nicht unmittelbar sofort.

Literaturempfehlungen

*

In Kapitel 13 gibt es eine gute und kurze Einführung in das Thema Datenbanken inkl. Transaktionen. Ich habe das Kapitel auch schon im Buchclub besprochen: Buchclub: Handbuch für Fachinformatiker (Teil 11: Datenbanken)

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• ACID – Wikipedia
• Isolation (Datenbank) – Wikipedia
• START TRANSACTION, COMMIT, and ROLLBACK Statements
• autocommit, Commit, and Rollback
• Jakarta Transactions 2.0
• Annotation @Transactional in Jakarta EE
• CAP-Theorem – Wikipedia
• Unterschied zwischen ACID- und BASE-Datenbanken

Um die angemessene fachliche bzw. technische Tiefe des Themas für das IHK-Abschlussprojekt für Anwendungsentwickler:innen geht es in der einhundertsechsundachzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Viele Projektanträge zum Abschlussprojekt werden abgelehnt, weil das umzusetzende Projekt nicht die nötige fachliche bzw. technische Tiefe aufweist. In unserem Prüfungssystem gibt es dafür sogar einen expliziten Ablehnungsgrund. Doch was heißt es genau, dass die fachliche Tiefe nicht erreicht wurde? Welche fachliche Tiefe ist überhaupt angemessen und wie erkenne ich als Prüfling, ob ich sie erreiche?

Mein Standardbeispiel: Projektverwaltung

Ich führe als Beispiel für eine übliche Projektarbeit für Anwendungsentwickler:innen immer eine klassische Web-Anwendung an. Nehmen wir das oft strapazierte Beispiel einer Zeiterfassungssoftware oder einer Projektverwaltung. Dabei handelt es sich um eine kleine Web-Anwendung mit ein paar Datenbanktabellen, etwas fachlicher Logik und ein paar netten Oberflächen.

In solch einer Anwendung kann ich als Anwendungsentwickler:in alles zeigen, was ich in meiner dreijährigen Ausbildung gelernt haben sollte. Soll ich ein Projekt enpfehlen, führe ich deswegen gerne dieses Beispiel für ein fachlich ausreichendes Projekt für die Abschlussprüfung an.

• Ich kann eine Datenbank modellieren, z.B. mit einem ERM oder Tabellenmodell.
• Ich kann ein Klassendesign entwerfen, z.B. mit einem Klassendiagramm oder gar mit Test Driven Development.
• Ich kann die Oberflächen gestalten, natürlich nach ergonomischen Gesichtspunkten und mit Mockups für den ersten Entwurf.
• Außerdem muss ich mich um das Zusammenspiel der Komponenten kümmern und brauche dafür eine tragfähige Architektur, z.B. MVC.

Kurz gesagt ist in solch einem Projekt alles Technische enthalten, was man heutzutage in der Programmierung können muss. Und ich kann mich vieler Methoden der Softwareentwicklung bedienen, die mein planvolles Vorgehen dokumentieren.

Hast du auch ein paar konkrete Zahlen?

Als ganz grobe Daumenregel für Anwendungsentwickler:innen führe ich immer ein „klassisches“ Webprojekt an: kleine Datenbank, ein bisschen Logik, Frontend drüber. Da kann man das volle Spektrum der Entwicklungstätigkeiten zeigen.

• ca. fünf Datenbanktabellen („eine Hand voll“)
• ca. fünf Oberflächen dazu
• ca. zehn Klassen (tendenziell eher mehr)

Sollte die Anwendung eine komplizierte Logik umsetzen, kann natürlich bei den anderen Komponenten entsprechend gekürzt werden. Diese grobe Richtlinie ist sicherlich nicht allgemeinverbindlich. Es kommt immer auf den Einzelfall an. Ich möchte nur deutlich machen, dass eine triviale Konsolenapplikation, die eine Textdatei einliest und wieder speichert, nicht ausreicht. Es sei denn, die Applikation verwendet dafür einen selbst programmierten Verschlüsselungsalgorithmus. 😉

Die Diagramme aus dem Titelbild dieser Episode sollten offensichtlich zeigen, dass dieser Umfang für ein Abschlussprojekt nicht ausreicht! 😂 Aber ich habe schon Artefakte in echten Dokus gesehen, die nicht viel umfangreicher waren (z.B. nur zwei Use-Cases oder drei Aktivitäten).

Brauche ich alle Komponenten – Datenbank, Logik, UI?

Das heißt nicht, dass jedes Abschlussprojekt alle genannten Komponenten umfassen muss. Nicht alle Unternehmen haben die Anforderung, Weboberflächen über Datenbanken zu gestalten. In vielen Betrieben wird eine bestehende Software erweitert, eine Oberfläche angepasst, oder eine Datenbank um zusätzliche Tabellen erweitert. Oft werden auch Programme benötigt, die gar keine grafische Oberfläche haben. Wenn es z.B. um den Datenabgleich zwischen ERP-System und Webshop geht, der nachts als Batchjob laufen soll, ist es völlig unnötig, eine schön gestaltete grafische Oberfläche dazu zu entwickeln. Auch werden inzwischen oft REST-APIs als Abschlussprojekt erstellt, die natürlich auch nicht von Menschen bedient werden. Daher ist es völlig legitim, auf die ein oder andere Komponente im Abschlussprojekt zu verzichten.

Auch heißt es umgekehrt nicht automatisch, dass man ein fachlich ausreichendes Projekt hat, nur weil alle Schichten Berücksichtigung finden. Eine Weboberfläche mit einem Formular, die simple CRUD-Operationen gegen eine Datenbanktabelle durchführt, ist selbstverständlich nicht umfangreich genug.

Mein Anti-Beispiel: SAP-Projekte

Dieses Problem haben meiner Erfahrung nach oftmals die Anwendungsentwickler:innen im SAP-Umfeld. Hier wird häufig nur sehr wenig tatsächlicher Code produziert, sondern viel mehr Zeit für die hochkomplexe Infrastruktur verbraten. Da gehen allein schon 7 Stunden drauf, bis man den richtigen Einstiegspunkt in die „Transaktion“ (oder wie auch immer das dort heißt) gefunden hat. 😉 Und die meisten Inhalte lassen sich dann mit SAP-Mitteln generieren, sodass der Entwickler eigentlich fast gar nichts mehr tun muss.

In eine ähnliche Richtung gehen heutzutage immer mehr die Low-Code- oder No-Code-Plattformen. Da wird kaum selbst programmiert, sondern einfach was zusammengeklickt. Und da muss ich mich dann schon fragen lassen, wie ich „Anwendungsentwickler:in“ werden will, wenn ich gar keine Anwendung entwickle.

Aber es gibt auch Negativbeispiele aus anderen Bereichen. Mein persönliches Highlight aus einer Abschlussprüfung war eine einzelne HTML-Seite, die mit 20 Zeilen JavaScript angereichert wurde. Das Problem war, dass der Prüfling selbst überhaupt nicht verstand, warum dieses Projekt nicht ausreichend war. Sein:e Ausbilder:in hatte ihn offensichtlich überhaupt nicht darauf vorbereitet. Und er war sehr enthusiastisch und freute sich richtig über sein Projekt. Das tat mir dann wirklich leid, da die Schuld für dieses unzureichende Projekt sicherlich nicht beim sehr motivierten Prüfling zu suchen war.

Methodik ist das A und O

Kurz gesagt sollte ein Abschlussprojekt zeigen, dass du methodisch Software entwickeln kannst, die eine gewisse Komplexität aufweist. Dazu habe ich in dieser Podcast-Episode noch viel mehr zu erzählen: Sinnvoller Aufbau/Ablauf eines IHK-Projekts in der Anwendungsentwicklung.

Es geht darum, dass du deine Fähigkeiten angemessen unter Beweis stellst. Du sollst methodisch Software entwickeln und die Projektarbeit wirtschaftlich umsetzen. Dazu gehört u.a. eine Betrachtung der Kosten und der Amortisation, der Einsatz von Modellierungs- oder Dokumentationsmethoden (z.B. ERM, UML, EPK, Mockups), das Erstellen sinnvoller Dokumentationen (z.B. für Kunden, Betrieb, Entwickler), das planvolle Vorgehen bei der Projektumsetzung (z.B. Projektplan, Iterationsplanung, Gantt-Chart), eine gute Qualitätssicherung (z.B. Unit-Tests, Abnahmeprotokoll) usw.

Individuelle Einschätzung

Wenn du dir nicht sicher bist, ob dein geplantes Programm als Abschlussprojekt ausreicht, dann frag deine:n Ausbilder:in oder deine:n Berufsschullehrer:in. Die sollten die nötige Erfahrung mitbringen und die Anforderungen der IHKen einschätzen können. Alternativ stell dein Projekt doch im Forum vor oder schreib mir eine Mail. Ich helfe dir gerne mit einer kurzen Einschätzung weiter – aber erst nachdem du diese Podcast-Episode gehört hast. 😊

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Sinnvoller Aufbau/Ablauf eines IHK-Projekts in der Anwendungsentwicklung

Um den sinnvollen Aufbau eines IHK-Abschlussprojekts für Fachinformatiker:innen Anwendungsentwicklung geht es in der einhundertfünfundachzigsten Episode des IT-Berufe-Podcasts.

Sinnvoller Aufbau/Ablauf eines IHK-Projekts in der Anwendungsentwicklung

Oft lese ich Projektdokumentationen für den Beruf Fachinformatiker:in Anwendungsentwicklung, die in sich einfach nicht stimmig sind. Der Projektablauf folgt keinem roten Faden und Artefakte werden wild durcheinandergewürfelt. Oft werden auch einfach nur Kapitel aus Dokumentationsvorlagen „ausgefüllt“, scheinbar ohne über ihre Sinnhaftigkeit nachzudenken.

In dieser Podcast-Episode gebe ich einen Überblick über einen – aus meiner Sicht – sinnvollen Ablauf eines IHK-Projekts im Bereich Anwendungsentwicklung inkl. möglicher Artefakte und ihrem Zweck. Dabei gehe ich nicht auf die Beschreibung des Projekts, die Wirtschaftlichkeitsbetrachtung, das Projektmanagement, die Ressourcenplanung usw. ein, sondern nur auf die Planung und Durchführung der eigentlichen Aufgabe: der Entwicklung einer Softwarelösung. Selbstverständlich gehören aber alle genannten Punkte auch in eine IHK-Projektdokumentation.

Wahl des Vorgehensmodells

Fast immer ist das Wasserfallmodell das einzig sinnvolle Vorgehensmodell, da das IHK-Projekt vom Prüfling alleine in einer fest vorgegebenen Zeit mit vorgegebenem (weil im Antrag genehmigten) Umfang umgesetzt werden muss.

Praxisbeispiele für unpassende Prozesse:

• Scrum gewählt, aber
  • klassische Wasserfallphasen durchgeführt/beschrieben
  • Lasten-/Pflichtenheft erstellt statt User Stories
  • Projekt alleine umgesetzt ohne Team/Scrum Master/Product Owner
  • gesamtes Projekt ist ein einziger Sprint
• XP gewählt, aber
  • keine Praktiken (z.B. Pair Programming, Test Driven Development) angewendet
• Kanban gewählt, aber
  • Lanes nur ToDo/Doing/Done

Artefakte methodisch sinnvoll einsetzen

• Software soll nicht einfach „runterprogrammiert“ werden, sondern methodisch entwickelt werden. Dabei helfen verschiedene Artefakte wie Entity-Relationship-Modelle, UML-Diagramme usw.
• Diagramme können oft auf zwei Arten eingesetzt werden: zur Modellierung (vor der Implementierung) und zur Dokumentation (nach der Implementierung). Sie haben keinen Selbstzweck, sondern sollen immer den jeweiligen Prozessschritt unterstützen.
• Ihr Einsatz muss zum gewählten Prozess passen. Ein Klassendiagramm zur Modellierung passt z.B. nicht so gut zu Test-Driven-Development, bei dem die Klassen sich erst bei der Implementierung ergeben.
• Die Artefakte müssen auch zeitlich sinnvoll im Projekt untergebracht werden. Die Anforderungen erst nach der Implementierung zu dokumentieren ist sinnfrei.
• Artefakte sollen im Prozess auch einen erkennbaren Mehrwert für die späteren Prozessschritte bieten. Mockups sind z.B. sehr hilfreich, um auf ihrer Basis ein Datenmodell zu erzeugen. Und auf Basis des Datenmodells können dann wiederum Klassen modelliert werden usw.
• Durch den passenden Einsatz der Artefakte in den jeweiligen Prozessschritten füllt sich die Projektdokumentation automatisch mit spannenden Inhalten für die Prüfer:innen! 😀

Anforderungen aufnehmen

• Ist-Analyse durchführen
  • Bisherige Lösung untersuchen, Schwachstellen aufdecken.
  • mögliche Ergebnisse: Aktivitätsdiagramm/EPK/BPMN, Screenshots/Fotos der bisherigen Lösung
• Anforderungen an neue Lösung strukturiert erfassen
  • Interviews mit Stakeholdern führen
  • Priorisierung der Anforderungen
  • Ergebnis: z.B. User Stories, MoSCoW
• Anwendungsfälle modellieren
  • Was wollen die Stakeholder mit der Anwendung fachlich machen/erreichen?
  • Ergebnis: Use-Case-Diagramm
• Anforderungen strukturiert dokumentieren
  • Ergebnis: Lastenheft

Lösung entwerfen

• Neuen Ablauf bzw. neue Lösung skizzieren
  • Was macht die (neue) Lösung besser? Welche Personen/Systeme sind wann/wie beteiligt?
  • mögliche Ergebnisse: Aktivitätsdiagramm/EPK/BPMN
• Plattform bzw. Art der Anwendung festlegen: GUI, Web, App etc.
  • Welche Anwendungsform löst das gestellte Problem am besten? Warum? Wie werden die Use-Cases umgesetzt?
• UI gestalten
  • Daraus ergeben sich u.a. die benötigten Daten der Anwendung.
  • Direkte Interaktion mit dem Kunden zur Abstimmung der Inhalte und Abläufe.
  • Mögliche Ergebnisse: Mockups, Wireframes, Screendesigns, Workflows, Corporate Design, Aktivitätsdiagramm
• Datenmodell entwerfen
  • Welche Entitätstypen mit welchen Attributen gibt es und wie hängen sie zusammen?
  • Welche Anwendungsfälle benötigten welche Daten?
  • Abstrakt und unabhängig von der konkreten späteren Speicherlösung modellieren.
  • Ergebnis: Entity-Relationship-Modell
• Architektur der Anwendung modellieren
  • Welche Architektur eignet sich am besten für die Umsetzung der Anforderungen?
  • Beispiele: Domain Driven Design, MVC, Client/Server, Monolith, REST etc.
  • Mögliche Ergebnisse: Komponentendiagramm, Klassendiagramm, Aktivitätsdiagramm, Sequenzdiagramm, Glossar
• Datenhaltung definieren
  • Welche Daten müssen wie/wo gespeichert und übertragen werden?
  • Beispiele: Datenbank, Dateien, Cloud, REST-API, JSON/XML etc.
  • mögliche Ergebnisse: Nutzwertanalyse
• Programmiersprache und Frameworks auswählen
  • Wenn eine Wahl möglich ist: Welche Sprachen/Frameworks eignen sich am besten für die Umsetzung? Warum?
  • Hat die getroffene Wahl eine Auswirkung auf die Architektur? Muss sich die Anwendung dem Framework anpassen?
  • Nach welchem Paradigma wird entwickelt? Wie wird getestet?
  • mögliche Ergebnisse: Liste der eingesetzten Technologien, Nutzwertanalyse
• Geschäftslogik und Domäne grob planen
  • Wie sollen die Anforderungen grob umgesetzt werden? Gibt es besonders „schwierige“ Probleme?
  • Welche Entitätstypen sind von zentraler Bedeutung? Wie hängen sie mit anderen zusammen?
  • Gibt es einen Workflow durch das System? Wie werden die Daten ausgetauscht?
  • Mögliche Ergebnisse: Aktivitätsdiagramm/EPK/BPMN, Sequenzdiagramm, Programmablaufplan, Struktogramm, Pseudocode, Klassendiagramm
• Build und Deployment modellieren
  • Welche Komponente (UI, Logik, DB etc.) läuft wo?
  • Wie/wo wird entwickelt?
  • Welches Build-Tool soll eingesetzt werden? Wo läuft der Build? Welche Build-Schritte sind nötig?
  • Welche Stages gibt es? Werden Container verwendet?
  • Mögliche Ergebnisse: Deploymentdiagramm, Aktivitätsdiagramm, Sequenzdiagramm, Build-Pipeline, Dockerfile, Buildfile
• Qualitätssicherung planen
  • Wie wird die Qualität bei der Softwareentwicklung sichergestellt? Welche Qualitätskriterien sind besonders wichtig?
  • Wie wird die fachliche Qualität sichergestellt? Wer testet wann die Anwendung? Was kann automatisiert werden?
  • Mögliche Ergebnisse: Testkonzept, Testplan, Branching-Strategie, Build-Pipeline, Schulungskonzept, zu erstellende Dokumentationen, statische Codeanalyse, Entwicklungsprozess (z.B. Pull Requests)
• Technische Lösung strukturiert dokumentieren
  • Ergebnis: Pflichtenheft

Lösung implementieren

• Vorgehen bei der Implementierung muss zum gewählten Prozess/Vorgehen passen
  • Code First vs. Database First, TDD
  • mögliche Ergebnisse: interessante Code-Beispiele: Frontend/Backend/SQL/HTML etc., Klassendiagramm, Sequenzdiagramm, Screenshots der Anwendung, Tabellenmodell, Screenshots der Projektstruktur
• Deployment auf Zielumgebung durchführen
  • mögliche Ergebnisse: Dockerfile, Screenshots Build-/Deployment-Pipeline, Ticketverlauf, Screenshots der finalen Umgebung

Qualitätssicherung

• Eigene Maßnahmen umsetzen (am besten schon während der Implementierung)
  • mögliche Ergebnisse: interessanter Code aus Unit-Tests/Integrationstests/Systemtests/Oberflächentests, Screenshots der Code Coverage oder statischen Codeanalyse
• Externe Unterstützung
  • mögliche Ergebnisse: Code-Reviews (was ist herausgekommen?), Pull-Requests, Code-Walkthroughs, Testprotokoll, Abnahmeprotokoll, Testsuite in Testtool

Dokumentation

• Langfristigen Betrieb der Lösung zielgruppengerecht dokumentieren
  • mögliche Ergebnisse: Kunden-/Benutzerdokumentation, Entwicklungsdokumentation, Administrationsdokumentation, Installationsanleitung, README, Verteilungsdiagramm, Wiki-Artikel, Build-Pipeline, Klassendiagramm, Tabellenmodell

Beispielablauf

Fiktives Beispiel: Es soll eine bestehende Excel-Lösung abgelöst werden durch eine Webanwendung.

• Ist-Analyse/Anforderungen: Gespräch mit bisherigen Anwender:innen, Ablauf als EPK dokumentieren, daran Schwachstellen (z.B. Medienbrüche) aufzeigen, Anforderungen währenddessen unstrukturiert als Notizen sammeln
  • Artefakte: EPK (alt), Screenshots der bisherigen Excel-Datei
• Anforderungen strukturieren: Notizen aufbereiten und um weitere Stakeholder (z.B. Entwickler:innen) ergänzen, einheitliche Formulierung als User Storys, Anwendungsfälle modellieren
  • Artefakte: Use-Case-Diagramm, Lastenheft (Liste der User Storys)
• Neue Lösung skizzieren: Prozess für Lösung des Problems als EPK modellieren (zum besseren Vergleich zur bisherigen Lösung)
  • Artefakt: EPK (neu)
• Plattform festlegen: Webanwendung, da am einfachsten zu deployen
• UI gestalten und mit Stakeholdern abstimmen, gerne low-level auf Papier oder dem iPad
  • Artefakt: Mockups
• Datenmodell aus den Mockups (und weiteren Anforderungen) ableiten
  • Artefakt: Entity-Relationship-Modell
• Architektur der Anwendung mit Domain Driven Design planen, Domäne ohne Abhängigkeiten und losgelöst von Infrastruktur
  • Artefakte: Komponentendiagramm, Glossar der zentralen Domänenbegriffe
• Datenhaltung definieren: MariaDB, weil schon etabliert im Unternehmen
• Programmiersprache und Frameworks auswählen: Java mit Quarkus, weil schon im Unternehmen etabliert und gut für Container geeignet
  • Artefakte: Liste der eingesetzten Technologien mit konkreten Versionsnummern
• Geschäftslogik und Domäne aus Datenmodell ableiten
  • Artefakte: grobes Klassendiagramm ohne Methoden zur Orientierung, Sequenzdiagramm für zentralen Algorithmus
• Build und Deployment modellieren: Build mit Gradle/Jenkins und Betrieb in Docker/Kubernetes
  • Artefakte: Deploymentdiagramm, Build-Pipeline (Code), Dockerfile (Code), Buildfile (Code)
• Qualitätssicherung planen: Implementierung mit TDD, technische Abnahme über Pull-Requests, statische Codeanalyse mit Sonarqube
• Obige Ergebnisse im im Pflichtenheft zusammenfassen
  • Artefakt: Pflichtenheft
• Implementierung Code-First durchführen mittels TDD orientiert am Datenmodell/Klassendiagramm/Komponentendiagramm mit Feature-Branches in Git
  • Artefakte: Code-Beispiele (Produktiv- und Testcode), Screenshots der Anwendung, Screenshot grünes Quality-Gate in Sonarqube, Screenshot Pull-Request, Kommentare aus dem Code-Review
• Deployment auf Zielumgebung durchführen mittels Pipeline in Jenkins
  • Artefakte: Screenshots der grünen Deployment-Pipeline
• Dokumentation für Anwender:innen und Entwickler:innen erstellen
  • Artefakte: Benutzerdokumentation, API-Dokumentation mit JavaDoc, README im Git-Repository, komplettes Klassendiagramm (generiert), Tabellenmodell (generiert)

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Word-Vorlage für die Projektdokumentation der IT-Berufe

Weitere Infos zur Projektdokumentation

Du suchst noch mehr Tipps rund um die Projektdokumentation? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die Projektdokumentation.

Kennst du schon meine Microsoft Word-/LibreOffice-Vorlage für die Projektdokumentation? Unter dieperfekteprojektdokumentation.de kannst du sie herunterladen.

Und wenn du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort meine Checkliste für die Projektdokumentation herunterladen.

Jetzt anmelden!

Um alles rund um Verträge als Vorbereitung auf die AP1 geht es in der einhundertvierundachzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Für die AP1 ist es sinnvoll, einige grundsätzliche Vertragsarten zu kennen und unterscheiden zu können. Sowohl auf Anbieter- als auch auf Nachfragerseite ist es wichtig zu verstehen, welche Art von Vertrag vorliegt, da daraus unterschiedliche Rechte und Pflichten entstehen können.

Disclaimer: Das hier ist keine Rechtsberatung! 🙂

Vertrag

Ein Vertrag ist die von zwei (oder mehr) Vertragsparteien erklärte Einigung über die Begründung eines Schuldverhältnisses (siehe § 311 BGB). Hierfür sind zwei übereinstimmende Willenserklärungen erforderlich. Beispiel: Angebot und Annahme, Bestellung und Lieferung.

Verträge können schriftlich, mündlich oder durch „konkludentes Handeln“ entstehen.

Vertragsarten

• Kaufvertrag: Verkäufer:in verkauft etwas an Käufer:in.
  • Beispiele in der IT: Hardware-/Softwarekauf
• Lizenzvertrag: Lizenzgeber:in räumt Lizenznehmer:in Rechte an einem geschützten Werk (z.B. Patent, Marke, Urheberrecht) ein.
  • Beispiele in der IT: Lizenzierung von Software, Bildrechte einkaufen
• Servicevertrag: Regelt die Erbringung produktbezogener Leistungen zwischen Anbieter:in und Kund:in.
  • Beispiele in der IT: Wartungsverträge für Software (z.B. für Patches und Updates) oder Hardware durch Dienstleister
• Mietvertrag: Vermieter:in überlässt Mieter:in eine bewegliche oder unbewegliche Sache zur zeitweisen Nutzung.
  • Beispiele in der IT: Miete eines Autos für eine Dienstreise, Miete von Software
• Leasingvertrag: Leasinggeber:in (Vermieter:in) überlässt Leasingnehmer:in (Mieter:in) eine Sache zur Nutzung wie bei der Miete, aber mit Fokus auf eine langfristige Nutzung mit der Möglichkeit des Erwerbs am Ende der Vertragslaufzeit. Außerdem sind bestimmte Sachverhalte anders geregelt, z.B. die Inspektion beim geleasten Auto oder die Wahl des konkreten Modells und der Ausstattung durch den/die Leasingnehmer:in.
  • Beispiele in der IT: Leasing teurer Hardware statt einmaligen Kaufs
• Werkvertrag: Unternehmer:in (Auftragnehmer:in) verpflichtet sich zur Herstellung eines bestimmten Werks für den/die Auftraggeber:in (Besteller:in). Hier muss das Endergebnis klar definiert sein („Werk“).
  • Beispiele in der IT: Programmierung einer kompletten Individualsoftware für eine Kundin
• Dienstvertrag: Schuldner:in verpflichtet sich zur Leistung eines Dienstes an den/die Gläubiger:in. Hierbei steht die Dienstleistung an sich im Vordergrund und nicht das Endergebnis.
  • Beispiele in der IT: Programmierung für einen Kunden auf Basis von Tagessätzen
• Fernabsatzvertrag: Bei Verträgen, die über Fernkommunikationsmittel (Internet, Telefon usw.) geschlossen werden, haben Verbraucher:innen besondere Rechte, insb. ein Widerrufsrecht.
• Arbeitsvertrag: Definiert die Rechte und Pflichten von Arbeitgeber:in und Arbeitnehmer:in.

Vertragsbestandteile

z.B. Leistungsbeschreibung, Termine/Fristen, fällige Entgelte, Lasten- und Pflichtenheft (insb. bei Softwareerstellung), Konventionalstrafen, Haftung

Allgemeine Geschäftsbedingungen (AGB)

Mit AGBs regeln Unternehmen ihre grundsätzliche Vertragsgestaltung, also Inhalte, die für alle Verträge gelten.

Beispielinhalte:

• Informationen zum Vertragsschluss (z.B. Telefon, E-Mail), Bestätigungen usw.
• Zahlungsbedingungen (z.B. Fristen, Zahlungsmöglichkeiten)
• Eigentumsvorbehalt
• Lieferungskonditionen und -möglichkeiten
• übliche Geschäftszeiten
• Gewährleistung/Garantie
• Haftung

Service-Level-Agreement (SLA)

Ein SLA legt fest, wie Auftraggeber:in und Dienstleister:in bei wiederkehrenden Dienstleistungen zusammenarbeiten und welche individuellen Verantwortlichkeiten sie tragen.

Beispielinhalte:

• Leistungsbeschreibung: z.B. Hosting einer Website
• Verfügbarkeit des Services: z.B. Verfügbarkeit 99%, vereinbarte Wartungsfenster
• Erreichbarkeit des Dienstleisters: z.B. Geschäftszeiten, Reaktionszeit bei unterschiedlich schweren Problemen
• Preisgestaltung: z.B. Abrechnung pro Aufruf oder Kontingente
• Rechtsfolgen bei Nichteinhaltung: z.B. Vertragsstrafen
• Vertragslaufzeit: z.B. monatlich, jährlich

Sonstiges

• Gewährleistung vs. Garantie: Gewährleistungsrechte bestehen aufgrund gesetzlicher Vorschriften gegenüber dem/der Verkäufer:in. Eine Garantie ist eine freiwillige Leistung eines/einer Hersteller:in und richtet sich nach dessen/deren Bedingungen.
• Archivierung: Jede:r Gewerbetreibende ist verpflichtet, geschäftliche Unterlagen (also auch Verträge) über einen bestimmten Zeitraum aufzubewahren. Die übliche Aufbewahrungsfrist beträgt 10 Jahre.
• Urheberrecht: Verleiht dem/der Inhaber:in das exklusive Nutzungsrecht am Werk, auch 70 Jahre über den Tod hinaus (Schutz geistigen Eigentums). Gilt automatisch für Bilder, Videos, Musik, Texte usw. mit einer gewissen Schöpfungshöhe. Das Urheberrecht ist nicht vertraglich abtretbar, aber Lizenzen können erteilt werden.
• Creative Commons: Gemeinnützige Organisation, die verschiedene Standard-Lizenzverträge veröffentlicht hat, mit denen Autor:innen der Öffentlichkeit auf einfache Weise Nutzungsrechte an ihren Werken einräumen können. Achtung: Lizenzen geben einzuhaltende Pflichten vor, z.B. die Namensnennung.
• Patent: Hoheitlich erteiltes gewerbliches Schutzrecht für eine (technisch geprägte) Erfindung. Dies verhindert eine schnelle Nachahmung durch Konkurrenten und motiviert die Forschung und Entwicklung neuer Erfindungen.
• Marke: Rechtlich geschütztes Zeichen, das dazu dient, Waren, Produkte oder Dienstleistungen eines Unternehmens von der Konkurrenz zu unterscheiden.

Literaturempfehlungen

*

Und dazu passend das Arbeitsbuch:

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Vertrag – Wikipedia
• Beispiel für AGBs: AGB von Mindfactory
• Abgemahnter Schlangenkuchen und Bilderrechte – Rechtsbelehrung Folge 1 (Jura-Podcast)

Um Softwarequalität nach ISO 9126 geht es in der einhundertdreiundachzigsten Episode des IT-Berufe-Podcasts.

Inhalt Definition von Qualität

Qualität ist der Grad der Übereinstimmung mit den Anforderungen.

Da verschiedene Stakeholder unterschiedliche Anforderungen an unser Projekt haben, ist die Qualität recht subjektiv. Alle Stakeholder zu 100% zufrieden zu stellen, wird in einem echten Projekt wohl nicht möglich sein.

Maßnahmen zur Qualitätssicherung

Die Softwarequalität kann mit verschiedenen konkreten Maßnahmen während der Entwicklung sichergestellt werden. Diese nicht vollständige Liste enthält einige Maßnahmen, die Prüflinge auch in ihrem eigenen Abschlussprojekt anwenden können.

• Audits
• Code Reviews
• Testmethoden
• Entwicklungsprozess
• Dokumentation
• Statische Codeanalyse
• Pair Programming
• Bugtracking
• Continuous Integration/Delivery/Deployment

Softwarequalität nach ISO 9126

• Funktionalität
  • Angemessenheit
  • Interoperabilität
  • Ordnungsmäßigkeit
  • Richtigkeit
  • Sicherheit
• Änderbarkeit
  • Analysierbarkeit
  • Modifizierbarkeit
  • Testbarkeit
  • Stabilität
• Übertragbarkeit
  • Anpassbarkeit
  • Austauschbarkeit
  • Installierbarkeit
  • Koexistenz
• Effizienz
  • Verbrauchsverhalten
  • Zeitverhalten
• Zuverlässigkeit
  • Fehlertoleranz
  • Reife
  • Wiederherstellbarkeit
• Benutzbarkeit
  • Attraktivität
  • Bedienbarkeit
  • Erlernbarkeit
  • Verständlichkeit

Literaturempfehlungen

Hier gibt es diese Podcast-Episode noch einmal als Video bei YouTube:

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Video zur Podcast-Episode bei YouTube
• ISO/IEC 9126 in der Wikipedia

Um Eigenschaften und Unterscheidungsmerkmale von Programmiersprachen geht es in der einhundertzweiundachzigsten Episode des IT-Berufe-Podcasts.

Inhalt Was ist eine Programmiersprache?

• Programmiersprache: „Eine Programmiersprache ist eine formale Sprache zur Formulierung von Datenstrukturen und Algorithmen, d.h. von Rechenvorschriften, die von einem Computer ausgeführt werden können.“ [Herv. d. Verf.]
• Bausteine von Algorithmen: Sequenz, Verzweigung (z.B. if, switch, aber auch Pattern Matching), Wiederholung (GOTO, Schleifen, Rekursion)
• Turing-complete: „[…] die Eigenschaft einer Programmiersprache oder eines anderen logischen Systems, sämtliche Funktionen berechnen zu können, die eine universelle Turingmaschine berechnen kann.“

Demnach sind keine Programmiersprachen: HTML/XML (Auszeichnungssprache), CSS (Stylesheet-Sprache), SQL (Datenbankabfragesprache).

Sprache vs. Plattform vs. Ökosystem

Programmiersprachen bringen meistens „eingebaute“ („native“) Funktionen mit, die direkt in der Syntax der Sprache formuliert werden können:

• Ein-/Ausgabe-Befehle, um Daten verarbeiten zu können
• Deklaration von Variablen zum Speichern von Informationen
• mathematische Funktionen wie Addition, Multiplikation usw.
• Steueranweisungen für Verzweigung und Wiederholung
• Möglichkeiten zur Programmunterteilung (z.B. Funktionen, Subprogramme)
• Einbinden von (externen) Bibliotheken zur Wiederverwendung

Viele Programmiersprachen bringen außerdem noch eine umfangreiche Bibliothek an vorgefertigten Implementierungen (z.B. in Form von Klassen in objektorientierten Sprachen) mit. Diese Bibliothek ist bei der Einarbeitung in eine neue Sprache meist schwieriger/langwieriger zu lernen als die Syntax. Oftmals teilen sich mehrere Programmiersprachen die Bibliotheken einer gemeinsamen Plattform, z.B. der JVM bei Java und Kotlin bzw. .NET bei C# und Visual Basic.

Darüber hinaus existiert meist auch noch ein ganzes Ökosystem rund um die Sprache/Plattform:

• Build-Tools, z.B. Maven, Gradle
• Dependency-Management, z.B. NPM, RubyGems
• Test-Frameworks, z.B. JUnit
• weitere Frameworks und Libraries, z.B. Spring, Jakarta EE, Rails, Blazor

Klassifizierung/Einsatzzweck(e)

Im Alltag sind die Identifikation und Auswahl einer für das jeweilige „Realweltproblem“ passenden Sprache wichtig. Viele Programmiersprachen haben Schwerpunkte bei ihrem Einsatz, weil sie für bestimmte Einsatzzwecke optimiert wurden oder dafür viele vorgefertigte Lösungen mitbringen.

• Einsatzzweck: Webanwendung (z.B. PHP), App (z.B. Swift), Desktop-Anwendung (z.B. C#), Server-Anwendung (z.B. Java)
• Frontend (browserseitig) vs. Backend
• Scriptsprachen: geringer Programmieraufwand für schnell sichtbare Ergebnisse, oft Interpretersprachen mit dynamischer Typisierung und laxer Syntaxprüfung (z.B. Semikolons optional), Beispiele: PowerShell, PHP
• Web-Programmiersprachen: bringen meist umfangreiche Bibliotheken und Frameworks für Webanwendungen mit, oftmals auch Scriptsprachen, Beispiele: PHP, Ruby, Python

Programmierparadigma

Ein Programmierparadigma gibt die grundsätzliche Art und Weise vor, wie mit einer Programmiersprache entwickelt wird. Es definiert grundlegende Herangehensweisen und Prinzipien bei der Softwareentwicklung, aber auch ganz konkrete syntaktische Vorgaben. So legt es z.B. fest, mit welchen Konstrukten das Programm hauptsächlich arbeitet (z.B. Objekte in der Objektorientierung bzw. Funktionen in der funktionalen Programmierung als sogenannte „First Class Citizens“), wie Programme modularisiert werden sollten und auf welche Art und Weise Algorithmen vorzugsweise formuliert werden sollten („idiomatische Programmierung“).

Viele Programmiersprachen sind heutzutage sogenannte Multiparadigmensprachen, bieten also Konzepte aus mehreren Paradigmen an, z.B. Objektorientierung und funktionale Programmierung. Meist haben sie aber ein definierendes Paradigma, z.B. Objektorientierung bei Java.

Imperativ vs. Deklarativ

Grundsätzlich kann man die imperative und deklarative Programmierung unterscheiden. Während bei der imperativen Programmierung (von lat. „imperare“ – befehlen) exakt vorgegeben wird, in welcher Reihenfolge der Computer welche Befehle wie ausführen muss, gibt man bei der deklarativen Programmierung (von lat. „declarare“ – erklären) lediglich vor, welches Ergebnis am Ende erreicht sein soll, und lässt den Computer den Weg dorthin selbst finden.

Beispiel:

// imperativ for (int i = 0; i < list.getSize(); i++) { System.out.println(list.get(i)); } // deklarativ list.forEach(System.out::println); Konkrete Programmierparadigmen

• unstrukturiert: Einsatz von GOTO führte dazu, dass konkrete Programmabläufe nicht mehr nachvollzogen werden konnten
• strukturiert: Verzicht auf GOTO und Einsatz von Kontrollstrukturen wie if und while
• prozedural: Programme werden in kleine, wiederverwendbare Einheiten („Prozeduren“) aufgespalten
• funktional: (mathematische) Funktionen bilden den Kern dieser Vorgehensweise, Higher Order Functions, Immutability und Rekursion als wichtige Merkmale
• objektorientiert: Objekte kapseln Eigenschaften und Funktionen zu einer Einheit, Vererbung und Polymorphie als wichtige Merkmale
• logisch: Programmierung auf Basis der mathematischen Aussagenlogik

Compiler vs. Interpreter

• Compiler: Übersetzt Quellcode in Maschinen- oder Bytecode, bevor das Programm ausgeführt wird.
  • JIT-Compiler: Just-In-Time-Compiler übersetzen z.B. Teile des Bytecodes zur Laufzeit in Maschinencode, um die Performance zu erhöhen.
• Interpreter: Interpretiert den Quellcode Zeile für Zeile und übersetzt ihn während der Ausführung in Maschinencode.

Typisierung

• statisch vs. dynamisch
  • statisch: Datentypen stehen schon zur Compile-Zeit fest.
  • dynamisch: Datentypen werden erst zur Laufzeit geprüft.
• stark vs. schwach: eher ein Spektrum („stärker/schwächer typisiert“) als eine harte Einteilung
  • stark: keine Typumwandlung möglich oder nur explizit („Cast“, (int)3.5)
  • schwach: implizite Typumwandlungen durch die Sprache, z.B. if (1) { ... }

Beispiele für alle Kombinationen

• statisch/stark: Java

> cat .\Main.java class Main { public static void main(String[] args) { double d = 1.5; int i = d; } } > javac .\Main.java .\Main.java:6: error: incompatible types: possible lossy conversion from double to int int i = d; ^ 1 error

• statisch/schwach: C

> cat test.c #include <stdio.h> int main() { int i = 1; if (i) { printf("Hallo\n"); } return 0; } > gcc test.c -o test > ./test Hallo

• dynamisch/stark: Ruby

> cat .\test.rb i = 1 s = "a" puts i + s > ruby .\test.rb ./test.rb:3:in `+': String can't be coerced into Integer (TypeError) from ./test.rb:3:in `<main>'</main>

• dynamisch/schwach: PHP

> cat test.php $i = "asdf"; if ($i) { echo "Hallo\n"; } > php test.php Hallo Syntax

Syntaktisch gibt es eigentlich nur die Unterscheidung zwischen Sprachen, die ähnlich zu C sind (insb. Klammern, Schlüsselwörter, Datentypen) oder eben nicht.

Beispiel Java (C-ähnlich):

void pruefePerson(int alter) { if (alter >= 18) { System.out.println("volljährig"); } }

Beispiel Ruby:

def pruefePerson(alter) puts "volljährig" if alter >= 18 end Grafisch vs. textuell

Die weitaus meisten Programmiersprachen sind textuelle Sprachen, aber es gibt auch grafische Programmiersprachen, bei denen die Algorithmen „zusammengeklickt“ werden können. Ein Beispiel ist Scratch.

Abstraktionsniveau/Sprachhöhe

• 1GL: Maschinensprache, Nullen und Einsen
• 2GL: Assembler, etwas abstrakter, aber immer noch kryptisch, an bestimmte Prozessoren gebunden
• 3GL: moderne Hochsprachen wie C, Java usw.
• 4GL: Sprachen mit Fokus auf einen bestimmten Anwendungsbereich, Ziel: wenig Code für häufig benötigte Funktionen, Beispiele: Natural, ABAP

General Purpose vs. Domain Specific

• General Purpose Language (GPL): Kann eingesetzt werden, um beliebige Probleme zu lösen, verwendet aber eine allgemeine Syntax. Beispiele: Java, C#, PHP etc.
• Domain Specific Language (DSL): Kann nur Probleme eines genau abgegrenzten Bereichs lösen, verwendet dafür aber eine perfekt passende Syntax. Es gibt interne (fachliche APIs der eigenen Komponenten) und externe (komplett separate Programmiersprachen mit Compiler usw.).

Weitere Unterscheidungsmöglichkeiten

• Portabilität/Laufzeitumgebung: hardwarenah (C, C++) vs. virtuelle Maschine (Java, C#)
• Managed vs. unmanaged: Manuelle Speicherverwaltung (C) vs. Garbage Collector (Java, C#)
• Performance/Speicherverbrauch: Durch die Kombination mehrerer der obigen Eigenschaften können sich deutliche Unterschiede bei der Performance einzelner Sprachen ergeben. So ist ein Programm in C, das speziell für die konkrete Laufzeitumgebung kompiliert wurde, sicherlich schneller als ein Java-Programm, das auf einer virtuellen Maschine interpretiert und ausgeführt wird. Aber das ist immer noch schneller als ein JavaScript-Programm, das zunächst noch interpretiert werden muss.

Beispiele für Programmiersprachen

Diese Liste ist nicht vollständig!

• Web
  • PHP: sehr verbreitete Web-Programmiersprache mit viel Unterstützung für übliche Anforderungen (z.B. Zugriff auf Query-String usw.)
  • Ruby: Basis von Ruby on Rails und geschaffen, um Entwickler:innen glücklich zu machen
  • Python: gerade im KI-Umfeld stark verbreitet
  • JavaScript: bislang die einzige (!) Programmiersprache für das Frontend im Browser
  • Typescript: statisch typisierte Alternative zu JavaScript
• Enterprise
  • Java: großes Ökosystem, Langlebigkeit, Abwärtskompatibilität, sehr performant
  • C#: stark verbreitet für Windows-Anwendungen
  • COBOL: alte, aber immer noch in vielen großen Unternehmen eingesetzte 4GL-Sprache für klassische Business-Anwendungen
  • ABAP: Programmiersprache von SAP
  • VBA: Makrosprache für Microsoft Office
• App
  • Kotlin: Standardsprache für Android-Anwendungen, läuft wie Java auf der JVM
  • Swift: Standardsprache für iOS-Anwendungen, „Nachfolger“ von Objective-C
• Hardware
  • Assembler: immer noch bei hochperformanten Anwendungen im Einsatz (z.B. Spiele)
  • C: Basis vieler eingebetteter Systeme und Betriebssysteme
  • C++: objektorientierter Aufsatz auf C
• Funktional
  • Haskell: die funktionale Programmiersprache, in der realen Welt nicht allzu verbreitet
  • F#: funktionale Sprache für .NET
  • Lisp: Urvater der modernen funktionalen Programmiersprachen
  • Elixir: basiert auf Erlang und ist stark bei nebenläufiger Programmierung
• Logisch
  • Prolog: Programmierung mit Prädikatenlogik, Backtracking usw.

Literatur

*

Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages (Pragmatic Programmers) (Affiliate)*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Turing-Vollständigkeit (Wikipedia)
• Programmiersprache (Wikipedia)
• Einführung in Build-Werkzeuge
• Unit-Tests – Häufige Fragen im Fachgespräch
• Java EE 7 (Lernzielkontrolle)
• HTML
• Buchclub: Handbuch für Fachinformatiker (Teil 9: XML)
• Buchclub: Handbuch für Fachinformatiker (Teil 7: HTML und CSS)
• SQL – Häufige Fragen im Fachgespräch
• Variablen und Operatoren (Lernzielkontrolle)
• Algorithmen und Methoden (Lernzielkontrolle)
• Objektorientierung Teil 1 (Lernzielkontrolle)
• Markus Amshove über Domänenspezifische Sprachen

In dieser Sonder-Episode des IT-Berufe-Podcasts geht es um eine Stellenausschreibung als Softwareentwickler:in (m/w/d) bei meinem Arbeitgeber, der ALTE OLDENBURGER Krankenversicherung AG in Vechta.

Inhalt

Bei meinem Arbeitgeber, der ALTE OLDENBURGER Krankenversicherung AG aus Vechta, suchen wir zum nächstmöglichen Zeitpunkt Unterstützung im IT-Bereich. Wir schreiben aktuell eine Stelle als Softwareentwickler:in aus. Selbstverständlich sind Bewerbungen von Personen aller Geschlechter erwünscht.

Kurzübersicht der Stelle

• Bezeichnung: Softwareentwickler (m/w/d)
• Art der Anstellung: unbefristete Festanstellung
• Arbeitsort: ALTE OLDENBURGER Krankenversicherung AG, Alte-Oldenburger-Platz 1, 49377 Vechta
• Homeoffice: bis zu 60% der wöchentlichen Arbeitszeit können im Homeoffice erbracht werden
• Beginn: schnellstmöglich
• Sonderleistungen: Urlaubs- und Weihnachtsgeld (14 Gehälter), Fahrtkostenzuschuss zur Arbeitsstelle, 40 EUR vermögenswirksame Leistungen pro Monat, Firmenfitness, Mitarbeiterrabatte für Versicherungen, betriebliche Altersvorsorge, Kinderbetreuungszuschuss
• Wöchentliche Arbeitszeit: 38 Stunden im Gleitzeitmodell ohne Kernarbeitszeit (bei einer Vollzeitbeschäftigung)
• Jährlicher Urlaubsanspruch: 30 Tage
• zusätzlicher Urlaub: Möglichkeit zur Umwandlung eines Teils des Urlaubsgelds in 5 Tage zusätzlichen Urlaub
• Weiterbildungsmöglichkeiten: (Duales) Studium (z.B. Wirtschaftsinformatik, technische Informatik), IHK-Weiterbildungen, externe Technologieschulungen, Konferenzbesuche
• Sonstiges: frisches Obst, kostenlose Kaffeespezialitäten, modern und ergonomisch ausgestattete Arbeitsplätze (überall höhenverstellbare Tische), betriebliche Gesundheitsförderung, eine kostenfreie Rückenmassage pro Monat (außerhalb der Arbeitszeit), ein hervorragendes Betriebsrestaurant mit bezuschussten Speisen, ein Employee-Assistance-Program, viele gemeinsame Aktivitäten wie z.B. Weihnachtsfeier, Betriebsausflug oder Spargelessen

Technische Highlights der Arbeit bei der AO

• Moderne IT-Infrastruktur
  • Windows 10 und SUSE Linux
  • Virtualisierung mit Citrix und VMware
• Moderne Softwareentwicklung
  • Continuous Integration und Deployment
  • Test Driven Development, Unit-Tests, Codeanalyse
  • Java, Jakarta EE, JBoss/Wildfly, Quarkus
• Fokus auf optimale Kollaboration
  • Code Reviews, Pair Programming, Pull Requests
• Fokus auf DevOps
  • Gute Zusammenarbeit zwischen Administration und Entwicklung
  • Auf- und Ausbau der Container-Infrastruktur mit Docker und Kubernetes
  • Tools: Gitea, Jenkins, Gradle, Artifactory, SonarQube

Detailinformationen zur Stelle

Unter dem folgenden Link kannst du dir alle Details zu der ausgeschriebenen Stelle anschauen und findest auch die notwendigen Daten für deine Bewerbung bei uns.

Softwareentwickler (m/w/d) für das Outputmanagementsystem und Drittanbieterschnittstellen

Softwareentwickler (m/w/d) für das Outputmanagementsystem und Drittanbieterschnittstellen

Wir suchen zum nächstmöglichen Zeitpunkt einen Softwareentwickler (m/w/d) in Festanstellung, der uns bei der Umsetzung von Fachbereichsanforderungen unterstützt und Systeme weiterentwickelt und optimiert. Deine Schwerpunkte liegen auf der Java-Plattform, sowie der Entwicklung in der Programmiersprache Natural der Software AG.

Deine Aufgaben

• Weiterentwicklung/Betreuung des Outputmanagementsystems
• Schnittstellen-Entwicklung zur Anbindung diverser Anwendungen an das Bestandsführungssystem
• Sicherstellung von Performance, Wartbarkeit und Skalierbarkeit der betreuten Anwendungen
• Selbstständige Mitarbeit in Projekten
• Zusammenarbeit mit den angrenzenden IT-Abteilungen und Fachbereichen

Deine neue Abteilung

Die Abteilung IT-Anwendungsintegration freut sich auf dich! Neben den genannten Tätigkeiten ist die Abteilung auch für den Betrieb und die Weiterentwicklung weiterer Drittanbietersoftwareprodukte verantwortlich (bspw. das Enterprise-Content-Management-System, das Inputmanagemensystem, diverse Spezialanwendungen für die Arbeit in den Fachabteilungen). Teile der Entwicklung des Bestandsführungsssystems werden auch in unserer Abteilung durchgeführt.

Zu Beginn deine Tätigkeit bei der AO bekommst du einen erfahrenen Mentor an die Seite gestellt, der dir alle Fragen beantworten kann und dich in die ersten Aufgaben und Projekte einführt. Sowohl die technischen Systeme, als auch das Unternehmen selbst und unsere Produkte werden dir in kurzen Schulungen nähergebracht. Fachlich wirst du von den jeweiligen Teammitgliedern betreut und in die Infrastruktur eingeführt.

Die ALTE OLDENBURGER gehört übrigens zu den Siegern der Arbeitgeber-Wettbewerbe des internationalen Forschungs- und Beratungsinstituts Great Place to Work. Die ALTE OLDENBURGER zählt zu den zehn „Besten Arbeitgebern Niedersachsen/Bremen 2023“ und wurde darüber hinaus sogar auch als einer von 100 „Deutschlands besten Arbeitgebern 2023“ ausgezeichnet.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Softwareentwickler (m/w/d) für das Outputmanagementsystem und Drittanbieterschnittstellen bei der ALTE OLDENBURGER Krankenversicherung AG in Vechta

Um Zahlensysteme, Zweierpotenzen und vor allem Binärzahlen geht es in der einhunderteinundachzigsten Episode des IT-Berufe-Podcasts. Der Inhalt ist auch als Video bei YouTube verfügbar.

Zahlensysteme, Zweierpotenzen und Binärzahlen

Zweierpotenzen und Binärzahlen begegnen uns in der IT-Ausbildung an vielen Stellen. In dieser Episode erkläre ich die Funktionsweise von Zahlensystemen (Binär, Oktal, Dezimal, Hexadezimal) und gebe Beispiele für den Praxiseinsatz.

Das Video zu dieser Episode findest du bei YouTube hier: Zahlensysteme, Zweierpotenzen und Binärzahlen.

Zahlen vs. Ziffern

Zahlen werden aus einzelnen Ziffern zusammengesetzt. Die Dezimalzahl 123 besteht z.B. aus den Ziffern 1, 2 und 3. Die bekannten Zahlensysteme haben unterschiedlich viele Ziffern:

• Dualsystem: 0 und 1
• Oktalsystem: 0 bis 7
• Dezimalsystem: 0 bis 9 (unsere bekannten arabischen Ziffern)
• Hexadezimalsystme: 0 bis 9 und A bis F

Römische Zahlen

Das römische Zahlsystem hat auch mehrere Ziffern:

• I = 1
• V = 5
• X = 10
• L = 50
• C = 100
• D = 500
• M = 1.000

Anders als in den anderen Zahlensystemen werden die einzelnen Ziffern hier einfach aufaddiert. So entspricht die Zahl III der Dezimalzahl 3, da I + I + I = 3.

Außerdem können Ziffern abhängig von ihrer Platzierung in der Zahl eine unterschiedliche Bedeutung haben. MCM entspricht z.B. der Dezimalzahl 1900, da das C vor dem M von diesem abgezogen werden muss, also 1000 - 100 = 900 ergibt. MCM = M + (M - C) = 1000 + (1000 - 100) = 1900.

Dezimalsystem und andere gebräuchliche Zahlensysteme

In den anderen Zahlensystemen, die wir in der Informatik häufig verwenden (nämlich Dualsystem, Oktalsystem, Dezimalsystem und Hexadezimalsystem), stehen die Ziffern einer Zahl immer für einen Faktor, der mit der Wertigkeit seiner Stelle multipliziert wird. Die Dezimalzahl 123 steht für 1 * 100 + 2 * 10 + 3 * 1.

Die Wertigkeit der Stelle ergibt sich aus ihrer Potenz mit der Basis des Zahlsystems. Die Basen der Zahlensysteme sind:

• Dual/Binär: 2
• Oktal: 8
• Dezimal: 10
• Hexadezimal: 16

Nun werden die Stellen der Zahlen von rechts nach links beginnend mit 0 immer um 1 im Exponenten erhöht, um die Wertigkeit der Stelle zu berechnen. Beispiel im Dezimalsystem:

• 10 ^ 0 = 1
• 10 ^ 1 = 10
• 10 ^ 2 = 100
• 10 ^ 3 = 1.000
• 10 ^ 4 = 10.000
• …

Dualsystem

Im Dualsystem oder Binärsystem ist die Basis 2, die Wertigkeiten der Stellen der Zahlen lauten also:

• 2 ^ 0 = 1
• 2 ^ 1 = 2
• 2 ^ 2 = 4
• 2 ^ 3 = 8
• 2 ^ 4 = 16
• 2 ^ 5 = 32
• …

Sie steigen also deutlich langsamer an als im Dezimalsystem. Mit jeder Stelle verdoppelt sich die Wertigkeit (im Vergleich zur Verzahnfachung im Dezimalsystem). Um den gleichen Zahlwert darstellen zu können, sind also deutlich mehr Ziffern nötig. Das wird noch deutlicher beim Hexadezimalsystem: Mit einer Ziffer können 16 verschiedene Werte dargestellt werden, also acht Mal so viele wie im Dualsystem.

Beispiel: Die Dezimalzahl 256 wird im Hexadezimalsystem als 100 (1 * 256 + 0 * 16 + 0 * 1) notiert, aber im Dualsystem als 100000000, hat dort also dreimal so viele Ziffern.

Im Dualsystem gibt es die Ziffern 0 und 1, die somit die „binary digits“ (binäre Ziffern) darstellen. Abgekürzt wird daraus Bit (binary digit).

Kombinationsmöglichkeiten

Oft stellen wir uns die Frage, wie viele Kombinationsmöglichkeiten – also unterschiedliche Zahlen – es für eine gegebene Anzahl an Stellen geben kann. Im Dualsystem haben wir pro Stelle zwei Möglichkeiten: 0 und 1, also ein Bit. Für eine Zahl mit einer Stelle ergeben sich also zwei Möglichkeiten: 0 und 1. Für eine Zahl mit zwei Stellen verdoppelt sich die Anzahl der Möglichkeiten:

• 00
• 01
• 10
• 11

Und mit jeder weiteren Stelle verdoppeln sich die Möglichkeiten wieder, da vor jede bisherige Kombination wieder 0 oder 1 geschrieben werden kann:

• 000
• 001
• 010
• 011
• 100
• 101
• 110
• 111

Die Anzahl der Kombinationsmöglichkeiten oder unterschiedlichen Zahlen für eine gegebene Anzahl an Stellen lässt sich berechnen als Potenz aus Basis des Zahlsystems hoch der Stellenzahl. Für eine 5-stellige Dualzahl sind 2 ^ 5 = 32 Kombinationen möglich, für eine 3-stellige Oktalzahl 8 ^ 3 = 512.

Beispiele für Zweierpotenzen

Da in der IT das Dualsystem sehr wichtig ist – denn Computer können nur mit Nullen und Einsen rechnen – begegnen uns in der Praxis häufig immer wieder Zweierpotenzen, da die Basis des Zahlsystems nunmal 2 ist. Daher ist es wichtig, zumindest grob überschlagen zu können, wie viele Kombinationsmöglichkeiten es für eine gegebene Anzahl an Bits gibt. Ein paar wichtige Zweierpotenzen sollte man auch auswendig lernen, damit man nicht jedes Mal wieder nachrechnen muss:

• 8 Bit = 256 Möglichkeiten: ein Byte, Farbtiefe von GIF-Bildern, Größe eines RGB-Kanals, Länge der Codierung ISO-8859-1
• 16 Bit = 65.536 Möglichkeiten: Samplingtiefe bei CD-Qualität, Größe eines Netzwerkports, Länge eines Shorts
• 24 Bit = ca. 16,7 Mio. Möglichkeiten: Standardfarbtiefe von JPG- oder PNG-Dateien (ohne Alpha-Kanal)
• 32 Bit = ca. 4,3 Mrd. Möglichkeiten: Länge eines Integers, Länge einer IPv4-Adresse, lange Zeit die übliche Verarbeitungsbreite von CPUs
• 48 Bit (2 * 24 Bit = ca. 16,7 Mio. * 16,7 Mio. Möglichkeiten): Länge einer MAC-Adresse
• 64 Bit: Länge eines Longs, übliche Verarbeitungsbreite moderner CPUs
• 128 Bit: Länge einer IPv6-Adresse

Zweierpotenzen im Vergleich

Zum Abschluss habe ich hier noch eine Liste aller Zweierpotenzen bis 128 mit einigen Anwendungsfällen bzw. Namen. Die Beispiele passen natürlich nicht hundertprozentig (z.B. gibt es nicht exakt 2 ^ 33 Menschen auf der Erde und 2 ^ 20 ist nicht genau eine Million), aber vermitteln einen Eindruck ihrer Größe im Verhältnis zu den anderen Zahlen und helfen beim Überschlagen von Ergebnissen.

• 2 ^ 1 = 2: 1 Bit
• 2 ^ 2 = 4
• 2 ^ 3 = 8
• 2 ^ 4 = 16
• 2 ^ 5 = 32
• 2 ^ 6 = 64: BASE64
• 2 ^ 7 = 128: ASCII
• 2 ^ 8 = 256: Byte, ISO-8859-1, GIF-Farben
• 2 ^ 9 = 512
• 2 ^ 10 = 1.024
• 2 ^ 11 = 2.048
• 2 ^ 12 = 4.096
• 2 ^ 13 = 8.192
• 2 ^ 14 = 16.384
• 2 ^ 15 = 32.768
• 2 ^ 16 = 65.536: UTF-16, Samplingtiefe CD, Größe Netzwerkport
• 2 ^ 17 = 131.072
• 2 ^ 18 = 262.144
• 2 ^ 19 = 524.288
• 2 ^ 20 = 1.048.576: Million
• 2 ^ 21 = 2.097.152
• 2 ^ 22 = 4.194.304
• 2 ^ 23 = 8.388.608
• 2 ^ 24 = 16.777.216: Farbtiefe JPG
• 2 ^ 25 = 33.554.432
• 2 ^ 26 = 67.108.864
• 2 ^ 27 = 134.217.728
• 2 ^ 28 = 268.435.456
• 2 ^ 29 = 536.870.912
• 2 ^ 30 = 1.073.741.824: Milliarde
• 2 ^ 31 = 2.147.483.648
• 2 ^ 32 = 4.294.967.296: Farben + Alpha PNG, Integer, IPv4
• 2 ^ 33 = 8.589.934.592: Anzahl Menschen
• 2 ^ 34 = 17.179.869.184
• 2 ^ 35 = 34.359.738.368
• 2 ^ 36 = 68.719.476.736
• 2 ^ 37 = 137.438.953.472: Elon Musks Vermögen, Sterne in unserer Galaxie
• 2 ^ 38 = 274.877.906.944
• 2 ^ 39 = 549.755.813.888
• 2 ^ 40 = 1.099.511.627.776: Billion
• 2 ^ 41 = 2.199.023.255.552
• 2 ^ 42 = 4.398.046.511.104
• 2 ^ 43 = 8.796.093.022.208
• 2 ^ 44 = 17.592.186.044.416
• 2 ^ 45 = 35.184.372.088.832
• 2 ^ 46 = 70.368.744.177.664
• 2 ^ 47 = 140.737.488.355.328
• 2 ^ 48 = 281.474.976.710.656: MAC
• 2 ^ 49 = 562.949.953.421.312
• 2 ^ 50 = 1.125.899.906.842.620: Billiarde
• 2 ^ 51 = 2.251.799.813.685.250
• 2 ^ 52 = 4.503.599.627.370.500
• 2 ^ 53 = 9.007.199.254.740.990
• 2 ^ 54 = 18.014.398.509.482.000
• 2 ^ 55 = 36.028.797.018.964.000
• 2 ^ 56 = 72.057.594.037.927.900
• 2 ^ 57 = 144.115.188.075.856.000
• 2 ^ 58 = 288.230.376.151.712.000
• 2 ^ 59 = 576.460.752.303.423.000
• 2 ^ 60 = 1.152.921.504.606.850.000: Trillion
• 2 ^ 61 = 2.305.843.009.213.690.000
• 2 ^ 62 = 4.611.686.018.427.390.000
• 2 ^ 63 = 9.223.372.036.854.780.000
• 2 ^ 64 = 18.446.744.073.709.600.000: Long
• 2 ^ 65 = 36.893.488.147.419.100.000: Kombinationsmöglichkeiten Rubik’s Cube
• 2 ^ 66 = 73.786.976.294.838.200.000
• 2 ^ 67 = 147.573.952.589.676.000.000
• 2 ^ 68 = 295.147.905.179.353.000.000
• 2 ^ 69 = 590.295.810.358.706.000.000: Quadratmillimeter Erdoberfläche
• 2 ^ 70 = 1.180.591.620.717.410.000.000: Trilliarde, Liter Wasser auf der Erde
• 2 ^ 71 = 2.361.183.241.434.820.000.000
• 2 ^ 72 = 4.722.366.482.869.650.000.000
• 2 ^ 73 = 9.444.732.965.739.290.000.000
• 2 ^ 74 = 18.889.465.931.478.600.000.000
• 2 ^ 75 = 37.778.931.862.957.200.000.000
• 2 ^ 76 = 75.557.863.725.914.300.000.000: Anzahl Sterne im sichtbaren Universum, Anzahl Sandkörner in der Sahara
• 2 ^ 77 = 151.115.727.451.829.000.000.000
• 2 ^ 78 = 302.231.454.903.657.000.000.000
• 2 ^ 79 = 604.462.909.807.315.000.000.000
• 2 ^ 80 = 1.208.925.819.614.630.000.000.000: Quadrillion
• 2 ^ 81 = 2.417.851.639.229.260.000.000.000
• 2 ^ 82 = 4.835.703.278.458.520.000.000.000
• 2 ^ 83 = 9.671.406.556.917.030.000.000.000
• 2 ^ 84 = 19.342.813.113.834.100.000.000.000
• 2 ^ 85 = 38.685.626.227.668.100.000.000.000
• 2 ^ 86 = 77.371.252.455.336.300.000.000.000
• 2 ^ 87 = 154.742.504.910.673.000.000.000.000
• 2 ^ 88 = 309.485.009.821.345.000.000.000.000
• 2 ^ 89 = 618.970.019.642.690.000.000.000.000
• 2 ^ 90 = 1.237.940.039.285.380.000.000.000.000: Quadrilliarde
• 2 ^ 91 = 2.475.880.078.570.760.000.000.000.000
• 2 ^ 92 = 4.951.760.157.141.520.000.000.000.000
• 2 ^ 93 = 9.903.520.314.283.040.000.000.000.000
• 2 ^ 94 = 19.807.040.628.566.100.000.000.000.000
• 2 ^ 95 = 39.614.081.257.132.200.000.000.000.000
• 2 ^ 96 = 79.228.162.514.264.300.000.000.000.000
• 2 ^ 97 = 158.456.325.028.529.000.000.000.000.000
• 2 ^ 98 = 316.912.650.057.057.000.000.000.000.000
• 2 ^ 99 = 633.825.300.114.115.000.000.000.000.000
• 2 ^ 100 = 1.267.650.600.228.230.000.000.000.000.000: Quintillion
• 2 ^ 101 = 2.535.301.200.456.460.000.000.000.000.000
• 2 ^ 102 = 5.070.602.400.912.920.000.000.000.000.000
• 2 ^ 103 = 10.141.204.801.825.800.000.000.000.000.000
• 2 ^ 104 = 20.282.409.603.651.700.000.000.000.000.000
• 2 ^ 105 = 40.564.819.207.303.300.000.000.000.000.000
• 2 ^ 106 = 81.129.638.414.606.700.000.000.000.000.000
• 2 ^ 107 = 162.259.276.829.213.000.000.000.000.000.000
• 2 ^ 108 = 324.518.553.658.427.000.000.000.000.000.000
• 2 ^ 109 = 649.037.107.316.853.000.000.000.000.000.000
• 2 ^ 110 = 1.298.074.214.633.710.000.000.000.000.000.000: Quintilliarde
• 2 ^ 111 = 2.596.148.429.267.410.000.000.000.000.000.000
• 2 ^ 112 = 5.192.296.858.534.830.000.000.000.000.000.000
• 2 ^ 113 = 10.384.593.717.069.700.000.000.000.000.000.000
• 2 ^ 114 = 20.769.187.434.139.300.000.000.000.000.000.000
• 2 ^ 115 = 41.538.374.868.278.600.000.000.000.000.000.000
• 2 ^ 116 = 83.076.749.736.557.200.000.000.000.000.000.000
• 2 ^ 117 = 166.153.499.473.114.000.000.000.000.000.000.000: Kombinationsmöglichkeiten Skatkarten
• 2 ^ 118 = 332.306.998.946.229.000.000.000.000.000.000.000
• 2 ^ 119 = 664.613.997.892.458.000.000.000.000.000.000.000
• 2 ^ 120 = 1.329.227.995.784.920.000.000.000.000.000.000.000: Sextillion
• 2 ^ 121 = 2.658.455.991.569.830.000.000.000.000.000.000.000
• 2 ^ 122 = 5.316.911.983.139.660.000.000.000.000.000.000.000
• 2 ^ 123 = 10.633.823.966.279.300.000.000.000.000.000.000.000
• 2 ^ 124 = 21.267.647.932.558.700.000.000.000.000.000.000.000
• 2 ^ 125 = 42.535.295.865.117.300.000.000.000.000.000.000.000
• 2 ^ 126 = 85.070.591.730.234.600.000.000.000.000.000.000.000
• 2 ^ 127 = 170.141.183.460.469.000.000.000.000.000.000.000.000
• 2 ^ 128 = 340.282.366.920.938.000.000.000.000.000.000.000.000: IPv6, MD5-Länge, UUID

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Video zur Podcast-Episode: Zahlensysteme, Zweierpotenzen und Binärzahlen bei YouTube

Um den Aufbau und den Ablauf der Abschlussprüfung in den IT-Berufen geht es in der einhundertachzigsten Episode des IT-Berufe-Pocasts.

Inhalt

• Die Teile der Abschlussprüfung sollten allen Auszubildenden und Ausbilder:innen geläufig sein, da die drei Jahre der Ausbildung hauptsächlich auf diese Prüfung hinarbeiten.
• Der Aufbau der Abschlussprüfung ist für alle IT-Berufe identisch, die Inhalte unterscheiden sich aber natürlich. Insbesondere die Dauer und die Inhalte der Projektarbeit sind berufsspezifisch.
• Es gibt insgesamt 7 verschiedene IT-Berufe.
  • Fachinformatiker:in
    • Anwendungsentwicklung
    • Systemintegration
    • Daten- und Prozessanalyse
    • Digitale Vernetzung
  • IT-System-Elektroniker:in
  • Kauf­mann/Kauffrau für Digitalisierungsmanagement
  • Kaufmann/Kauffrau für IT-System-Management
• Der Großteil (60%) der Inhalte der schriftlichen Prüfung (GAP Teil 1 und WiSo) ist für alle Berufe gleich.
• Achtung: Die IHK-Prüfungen sind bundesweit einheitlich, aber in Baden-Württemberg laufen sie anders als in den übrigen 15 Bundesländern. Die folgenden Ausführungen gelten daher ggfs. nicht für Prüfungen in Baden-Württemberg.

Aufbau der Abschlussprüfung

Wer es ganz genau wissen will, schaut am besten in die jeweilige Berufsverordnung:

• Fachinformatiker:in Anwendungsentwicklung
• Fachinformatiker:in Systemintegration
• Fachinformatiker:in Daten- und Prozessanalyse
• Fachinformatiker:in Digitale Vernetzung
• IT-System-Elektroniker:in
• Kauf­mann/Kauffrau für Digitalisierungsmanagement
• Kaufmann/Kauffrau für IT-System-Management

Die folgenden Zitate stammen aus der FIAusbV.

Teil 1 (der gestreckten Abschlussprüfung)

Teil 1 der gestreckten Abschlussprüfung findet im Prüfungsbereich Einrichten eines IT-gestützten Arbeitsplatzes statt. Dieser Prüfungsteil ist für alle IT-Berufe identisch.

Im Prüfungsbereich Einrichten eines IT-gestützten Arbeitsplatzes hat der Prüfling nachzuweisen, dass er in der Lage ist,
1. Kundenbedarfe zielgruppengerecht zu ermitteln,
2. Hard- und Software auszuwählen und ihre Beschaffung einzuleiten,
3. einen IT-Arbeitsplatz zu konfigurieren und zu testen und dabei die Bestimmungen und die betrieblichen Vorgaben zum Datenschutz, zur IT-Sicherheit und zur Qualitätssicherung einzuhalten,
4. Kunden und Kundinnen in die Nutzung des Arbeitsplatzes einzuweisen und
5. die Leistungserbringung zu kontrollieren und zu protokollieren.
(FIAusbV §9 Abs. 2)

Teil 1 der Prüfung ist eine schriftliche Prüfung über 90 Minuten, die nach 18 Monaten der Ausbildung absolviert werden muss. Inhalt sind alle im Ausbildungsrahmenplan (Teil der oben verlinkten Ausbildungsverordnung) und Rahmenlehrplan (für die Berufsschulen) bis zu diesem Zeitpunkt zu vermittelnden Inhalte.

• Rahmenlehrplan für die Ausbildungsberufe Fachinformatiker und Fachinformatikerin sowie IT-System-Elektroniker und IT-System-Elektronikerin
• Rahmenlehrplan für die Ausbildungsberufe Kaufmann für IT-System-Management, Kauffrau für IT-System-Management Kaufmann für Digitalisierungsmanagement sowie Kauffrau für Digitalisierungsmanagement

Das Ergebnis des ersten Prüfungsteils geht zu 20% in die Abschlussnote ein.

Tipps zur Vorbereitung auf die Prüfung gibt es in meinen entsprechenden Podcast-Episoden, z.B. Prüfungsvorbereitung auf Teil 1 der gestreckten Abschlussprüfung der IT-Berufe. Und hier habe ich eine große Liste mit allen potentiellen Prüfungsthemen für dich zusammengestellt: Mögliche Themen von Teil 1 der gestreckten Abschlussprüfung (GAP) in den IT-Berufen.

Teil 2 (der gestreckten Abschlussprüfung)

In Teil 2 der Prüfung sollen die bereits in Teil 1 abgefragten Inhalte nicht explizit erneut abgefragt werden, sie werden aber als bekannt vorausgesetzt.

Teil 2 der Prüfung teilt sich in vier konkrete Prüfungsteile auf:

• Projektarbeit
• Zwei fachspezifische schriftliche Prüfungen
• Wirtschaft- und Sozialkunde

Betriebliche Projektarbeit

Die betriebliche Projektarbeit ist in allen IT-Berufen durchzuführen. Sie unterscheidet sich aber je nach Beruf und Fachgebiet. Für die Umsetzung stehen 40 Stunden zur Verfügung, aber Anwendungsentwickler:innen haben 80 Stunden.

Der Prüfling hat eine betriebliche Projektarbeit durchzuführen und mit praxisbezogenen Unterlagen zu dokumentieren.
Vor der Durchführung der betrieblichen Projektarbeit hat er dem Prüfungsausschuss eine Projektbeschreibung zur Genehmigung vorzulegen.
In der Projektbeschreibung hat er die Ausgangssituation und das Projektziel zu beschreiben und eine Zeitplanung aufzustellen.
Die Prüfungszeit beträgt für die betriebliche Projektarbeit und für die Dokumentation mit praxisbezogenen Unterlagen höchstens 80 Stunden.
(FIAusbV §12 Abs. 2)

Zusätzlich zur Umsetzung der Projektarbeit und ihrer Dokumentation muss ein Prüfling in diesem Prüfungsteil nachweisen, dass er/sie in der Lage ist…

1. die Arbeitsergebnisse adressatengerecht zu präsentieren und
2. seine Vorgehensweise bei der Durchführung der betrieblichen Projektarbeit zu begründen
   (FIAusbV §12 Abs. 3)

Das heißt, es werden eine Projektpräsentation und ein anschließendes Fachgespräch durchgeführt. Dabei gilt:

Die Prüfungszeit beträgt insgesamt höchstens 30 Minuten.
Die Präsentation soll höchstens 15 Minuten dauern.
(FIAusbV §12 Abs. 3)

Die Gewichtung der einzelnen Prüfungsteile sieht so aus:

• Projektdokumentation: 50%
• Projektpräsentation und Fachgespräch: 50% (nur eine gemeinsame Note ohne Unterscheidung der beiden Teile)

Fachspezifische schriftliche Prüfung

Dieser Prüfungsteil ist für alle IT-Berufe unterschiedlich und fachspezifisch. Es werden zwei schriftliche Prüfungen zu je 90 Minuten geschrieben.

Die Themengebiete für die einzelnen Berufe sind:

• Fachinformatiker:in Anwendungsentwicklung
  • Planen eines Softwareproduktes
  • Entwicklung und Umsetzung von Algorithmen
• Fachinformatiker:in Systemintegration
  • Konzeption und Administration von IT-Systemen
  • Analyse und Entwicklung von Netzwerken
• Fachinformatiker:in Daten- und Prozessanalyse
  • Durchführen einer Prozessanalyse
  • Sicherstellen der Datenqualität
• Fachinformatiker:in Digitale Vernetzung
  • Diagnose und Störungsbeseitigung in vernetzten Systemen
  • Betrieb und Erweiterung von vernetzten Systemen
• IT-System-Elektroniker:in
  • Installation von und Service an IT-Geräten, IT-Systemen und IT-Infrastrukturen
  • Anbindung von Geräten, Systemen und Betriebsmitteln an die Stromversorgung
• Kauf­mann/Kauffrau für Digitalisierungsmanagement
  • Entwicklung eines digitalen Geschäftsmodells
  • Kaufmännische Unterstützungsprozesse
• Kaufmann/Kauffrau für IT-System-Management
  • Einführen einer IT-Systemlösung
  • Kaufmännische Unterstützungsprozesse

Beide Prüfungen werden mit jeweils 10% in die Endnote eingerechnet. Die Aufgaben sind schriftlich zu beantworten und werden manuell von Prüfer:innen korrigiert.

Wirtschaft- und Sozialkunde (WiSo)

Im letzten Prüfungsteil soll der Prüfling nachweisen, dass er in der Lage ist…

allgemeine wirtschaftliche und gesellschaftliche Zusammenhänge der Berufs- und Arbeitswelt darzustellen und zu beurteilen.
(FIAusbV §15 Abs. 1)

Diese schriftliche Prüfung dauert 60 Minuten und geht zu 10% in die Abschlussnote ein. Die Aufgaben sind durch Ankreuzen oder Eintragen von Zahlen zu beantworten und werden automatisiert korrigiert.

Gewichtung der Prüfungsteile

Die obigen Prüfungsteile gehen mit folgenden Gewichtungen in die Endnote ein (siehe FIAusbV §16 Abs. 1)

• Einrichten eines IT-gestützten Arbeitsplatzes (GAP Teil 1): 20%
• Betriebliche Projektarbeit: 50%
  • Davon 50% für die Projektdokumentation und 50% gemeinsam für Projektpräsentation und Fachgespräch
• Fachspezifische schriftliche Prüfung: jeweils 10%
• Wirtschafts- und Sozialkunde: 10%

Somit zählen alle schriftlichen Prüfungen zusammen 50% der Abschlussnote und das Projekt auch 50%. Die Hälfte der Punkte liegt damit in der Hand der Prüflinge, da sie ihr Abschlussprojekt selbst auswählen, planen und durchführen können.

Nicht-Bestehen der Prüfung

Die Abschlussprüfung ist bestanden, wenn die genannten Prüfungsleistungen wie folgt bewertet worden sind (siehe FIAusbV §16 Abs. 2):

• im Gesamtergebnis von Teil 1 und Teil 2 mindestens „ausreichend“ (also 50%)
• im Ergebnis von Teil 2 mindestens „ausreichend“ (also 50%)
• in mindestens drei Prüfungsbereichen von Teil 2 mindestens „ausreichend“ (also 50%)
• in keinem Prüfungsbereich von Teil 2 „ungenügend“ (also mind. 30%)

Das heißt, dass man quasi in Teil 1 der Prüfung nicht „durchfallen“ kann (sofern man die Note mit Teil 2 ausgleichen kann).

Ggfs. kannst du ein schlechtes Ergebnis im schriftlichen Teil 2 der Prüfung durch eine mündliche Ergänzungsprüfung ausgleichen.

Es gibt einen hervorragenden Notenrechner für die IT-Abschlussprüfung (AO2020).

Ablauf der Abschlussprüfung

Es gibt für Teil 1 der Prüfung eine Prüfung im Frühjahr und eine im Herbst, sowie für Teil 2 eine Sommer- und eine Winterprüfung. Die weitaus meisten Prüflinge nehmen an der Frühjahrs- bzw. Sommerprüfung teil. Auszubildende mit verkürzter Ausbildungszeit, duale Studierende oder Umschüler nehmen meist an der Herbst- bzw. Winterprüfung teil.

Die folgenden Termine sind grobe Richtwerte. Nur die Termine der schriftlichen Prüfungen werden deutschlandweit (bis auf Baden-Württemberg) einheitlich von der Aufgabenstelle für kaufmännische Abschluss- und Zwischenprüfungen festgelegt. Die anderen Termine bestimmen die örtlichen IHKen individuell. Meist werden die Noten den Prüflingen nicht vom Prüfungsausschuss mitgeteilt, sondern sie werden nach der Prüfung durch die IHK per Post versendet.

• Termine (Vgl. Termine der schriftlichen Abschlussprüfungen)
  • Teil 1: Februar/März (Frühjahr) bzw. September/Oktober (Herbst)
  • Teil 2: April/Mai (Sommer) bzw. November/Dezember (Winter)
  • Mündliche Prüfung (Präsentation/Fachgespräch): Mai/Juni/Juli (Sommer) bzw. Dezember/Januar (Winter)
• Betriebliche Projektarbeit
  • Abgabe des Antrags: Februar (Sommer) bzw. September (Winter)
  • Bearbeitungszeit: ab Genehmigung des Antrags durch den Prüfungsausschuss (meist einige Wochen nach Antragsstellung) bis zu einem festgelegten Termin
  • Abgabe der Dokumentation: meist eine Woche nach der schriftlichen Prüfung Teil 2
• Mitteilung der Prüfungsergebnisse
  • Teil 1: einige Wochen nach dem Prüfungstermin
  • Teil 2: einige Wochen nach dem Prüfungstermin, jedoch meist vor der mündlichen Prüfung
  • mündliche Prüfung: am Tag der mündlichen Prüfung
  • Gesamtergebnis: am Tag der mündlichen Prüfung

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Berufsverordnungen
  • FIAusbV: Verordnung über die Berufsausbildung zum Fachinformatiker und zur Fachinformatikerin
  • ITSEAusbV: Verordnung über die Berufsausbildung zum IT-System-Elektroniker und zur IT-System-Elektronikerin
  • DigiManKflAusbV: Verordnung über die Berufsausbildung zum Kaufmann für Digitalisierungsmanagement und zur Kauffrau für Digitalisierungsmanagement
  • ITSManKflAusbV: Verordnung über die Berufsausbildung zum Kaufmann für IT-System-Management und zur Kauffrau für IT-System-Management
• Rahmenlehrpläne
  • Rahmenlehrplan für die Ausbildungsberufe Fachinformatiker und Fachinformatikerin sowie IT-System-Elektroniker und IT-System-Elektronikerin (Beschluss der Kultusministerkonferenz vom 13.12.2019)
  • Rahmenlehrplan für die Ausbildungsberufe Kaufmann für IT-System-Management, Kauffrau für IT-System-Management Kaufmann für Digitalisierungsmanagement sowie Kauffrau für Digitalisierungsmanagement
• Prüfungsvorbereitung auf Teil 1
  • Prüfungsvorbereitung auf Teil 1 der gestreckten Abschlussprüfung der IT-Berufe
  • Mögliche Themen von Teil 1 der gestreckten Abschlussprüfung (GAP) in den IT-Berufen
• Notenrechner für die IT-Abschlussprüfung (AO2020)
• Termine der schriftlichen Abschlussprüfungen
• Ablauf der mündlichen Ergänzungsprüfung

Um das beliebte Prüfungsthema RAID geht es in der einhundertneunundsiebzigsten Episode des IT-Berufe-Podcasts.

Inhalt

• RAID: Redundant Array of Independent Disks (bzw. früher „inexpensive“ statt „independent)
• Idee: Mehrere Festplatten zu einem Verbund („array“) zusammenschließen
• Ziel: Ausfallsicherheit und höhere Verfügbarkeit (durch Einführung von Redundanz)
• Bei Ausfall einer Festplatte kann sie getauscht und das RAID-Array wiederhergestellt werden („Rebuild“), in dieser Phase ist das RAID durch die hohe Belastung aber anfälliger für einen weiteren Festplattenausfall.
• RAID ersetzt nicht die Datensicherung.
• Lösung: Hardware- oder Software-RAID
  • Hardware mit speziellen RAID-Controllern
  • Software meist schon ins Betriebssystem eingebaut (z.B. in Linux)
• Alternative: JBOD (just a bunch of disks)
• Es gibt verschiedene RAID-Level
  • Kriterien: Mindestanzahl Festplatten, Ausfallwahrscheinlichkeit, maximal verkraftbare ausgefallene Festplatten, Lese-/Schreibgeschwindigkeit, Nettokapazität

RAID 0: Striping

• keine Redundanz, Merksatz: „0 Redundanz“, „0 Sicherheit“
• mindestens 2 Festplatten nötig
• teilt Festplatten in gleich große Blöcke auf und verteilt die Daten darauf (stripes)
• Kapazität kann komplett genutzt werden
• dadurch kann schneller gelesen werden, da von mehreren Festplatten parallel gelesen wird
• auch das Schreiben geht schneller, da Daten parallel auf mehrere Festplatten geschrieben werden (aufgeteilt)
• fällt eine Festplatte aus, ist der gesamte Verbund defekt
• Ausfallwahrscheinlichkeit steigt, da Einzelwahrscheinlichkeiten multipliziert werden (z.B. bei 1% Ausfallwahrscheinlichkeit 2,97% gesamt)
• Einsatz: Streaming (viel Lesen, wenig Schreiben, Datenverlust verkraftbar bzw. anderweitig abgesichert), mehrere kleine zu einem großen Datenträger zusammenbauen
• Nachteil: hohe Ausfallwahrscheinlichkeit

RAID 1: Mirroring

• komplette Redundanz, Merksatz: „1-zu-1-Kopie“
• mindestens 2 Festplatten nötig
• Daten werden auf allen Festplatten identisch abgelegt
• Kapazität wird halbiert oder gedrittelt usw.
• Lesegeschwindigkeit kann erhöht werden, indem Daten parallel von mehreren Festplatten gelesen werden
• Schreiben dauert länger, weil Daten auf mehrere Platten geschrieben werden müssen (Redundanz)
• Verbund fällt erst aus, wenn alle Festplatten ausfallen
• Ausfallwahrscheinlichkeit sinkt deutlich, z.B. bei 1% je Platte auf 0,0001%
• auch Mirroring ist keine Datensicherung, Viren werden sofort auf alle Platten geschrieben
• Einsatz: Hochverfügbarkeitssysteme
• Nachteil: geringe Nettokapazität

RAID 5: Paritäten

• Teilredundanz durch Ablage von Paritätsinformationen
• mindestens 3 Festplatten nötig
• zusätzlich zu den auf mehrere Festplatten verteilten Daten werden auf allen Festplatten Paritätsinformationen (z.B. XOR) je Datenblock abgelegt
• Kapazität wird reduziert (z.B. 2/3 bei drei Festplatten)
• Lesegeschwindigkeit kann erhöht werden, indem Daten parallel von mehreren Festplatten gelesen werden
• Schreiben dauert durch Berechnung der Parität länger
• Verbund fällt erst aus, wenn zwei Festplatten defekt sind
• Ausfallwahrscheinlichkeit sinkt, z.B. bei 1% je Platte auf 0,0298%
• Nachteil: bei häufigen Schreibzugriffen durch Berechnung der Parität langsamer

Irrelevante RAID-Level

• RAID 2: Striping mit Fehlerkorrektur, nur bei Großrechnern eingesetzt
• RAID 3/4: wie RAID 5 nur mit dedizierter Paritätsfestplatte (die dadurch stark belastet und zum Flaschenhals wird), bei RAID 3 wird auf Byte-Ebene und bei RAID 4 auf Block-Ebene gestript
• RAID 6: wie 5 nur mit doppelter Parität

Kombinationen von RAID-Levels

• best of both worlds aus anderen RAID-Leveln
• immer von links nach rechts lesen und im Diagramm von unten nach oben: 01 -> zuerst werden zwei RAID 0 erstellt und dann zu einem RAID 1 zusammengebaut
• ein Leg ist das RAID-Array „unten“ im Bild, aus dem das übergeordnete zusammengesetzt wird
• es werden mind. 4 Festplatten benötigt
• Kapazität wird halbiert
• Verbund verträgt zwei Festplattenausfälle, aber es ist wichtig, welche Platten ausfallen

RAID 01

• zwei Festplatten im gleichen Leg dürfen ausfallen
• es kann nicht erkannt werden, welche Festplatte im RAID 0 ausgefallen ist, da dann das gesamte Array defekt ist
• bei Ausfall einer Festplatte muss das gesamte Stripeset des Legs neu aufgebaut werden

RAID 10

• zwei Festplatten in unterschiedlichen Legs dürfen ausfallen
• bei Ausfall weniger Aufwand für Rebuild, weil nur im Leg gemirrort werden muss
• Achtung: auch der RAID-Controller kann ausfallen

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Datensicherung
• RAID

Um das beliebte Prüfungsthema Datensicherung geht es in der einhundertachtundsiebzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Datensicherung ist quasi das deutsche Wort für Backup und behandelt das Sichern und Wiederherstellen von Daten auf Sicherungsmedien wie Magnetbändern, externen Festplatten oder der Cloud. Es geht hierbei um den Schutz vor Datenverlust.

• Abgrenzung von Datensicherung, Datensicherheit und Datenschutz. Siehe auch Datenschutz vs. Datensicherheit vs. Datensicherung.
  • Die Datensicherung ist ein Teil der Datensicherheit, der sich um das Schutzziel Verfügbarkeit kümmert.
• Warum können Daten verloren gehen?
  • Hardwaredefekte, Probleme im Stromnetz, Feuer/Wasser, Naturkatastrophen, menschliches Versagen oder Vorsatz (z.B. absichtliches Löschen oder Diebstahl), Ransomware
• Ein Datenverlust kann für Unternehmen (aber auch Privatpersonen) große negative Auswirkungen haben. In schlimmen Fällen kann das Unternehmen nicht weiter arbeiten und muss Insolvenz anmelden.
• Mitarbeiter sollten zum Thema Datenverlust sensibilisiert werden.
  • Was sind die Konsequenzen eines Datenverlustes für das Unternehmen und die Person selbst?
  • Dateien sofort abspeichern und nicht erst nach stundenlanger Arbeit.
  • Dateien regelmäßig speichern.
  • Nicht nur auf der eigenen Festplatte speichern, sondern im Netzwerk.
• Was sind sicherungswürdige Daten?
  • Daten, die man nicht ohne Weiteres wiederbeschaffen kann (z.B. selbst erstellte Dateien, Fotos, Dokumente, Arbeitsergebnisse).
  • Meist werden Betriebssystemdaten und Programminstallationen nicht gesichert.
  • Grundsätzlich kommt es darauf an, wie schnell Daten wiederhergestellt werden können müssen. Auch das Betriebssystem kann daher gesichert werden müssen, wenn eine Neuinstallation zu lange dauern würde.
  • Es gibt auch gesetzliche Aufbewahrungsfristen für Daten, aber bitte nicht mit Archivierung durcheinanderbringen.
• Wichtig bei der Datensicherung: auch die Datenwiederherstellung testen!
• Wie erkennt die Software, welche Daten zu sichern sind?
  • Metadaten wie letztes Änderungsdatum, Archiv-Flag oder Dateihash.
• Wie viele Daten werden gesichert und wie lange dauert die Wiederherstellung?
  • Trade Off zwischen geringem Speicherverbrauch bzw. langer Backuplaufzeit und schneller Wiederherstellungsdauer.
  • Unterschiedliche Verfahren: Vollbackup (alle Daten sichern), differenzielles Backup (nur geänderte Daten zum letzten Vollbackup werden gesichert) und inkrementelles Backup (geänderte Daten zum letzten Voll- oder inkrementellen Backup werden gesichert).
  • Vollbackup: Viel Speicherverbrauch, lange Backuplaufzeit, schnelle Wiederherstellung (nur 1 Backup nötig).
  • Differenzielles Backup: Mittelweg zwischen Speicherverbrauch/Backuplaufzeit und Wiederherstellung (2 Backups nötig).
  • Inkrementelles Backup: Geringster Speicherverbrauch, aber längste Wiederherstellung (z.B. 5 Backups nötig).
• Backup-Medien
  • Kriterien bei der Auswahl von Backupmedien: Kapazität, Transferrate, Zugriffsgeschwindigkeit, Kosten, Lebensdauer, Störanfälligkeit
  • Mögliche Medien: Magnetbänder, Festplatten/HDDs, SSDs, USB-Sticks, CDs/DVDs/BluRays, Cloud
• Generationenprinzip bzw. Großvater/Vater/Sohn
  • Auch Backup-Medien können kaputt gehen! Nur ein einziges Medium zu nutzen, ist daher nicht zu empfehlen.
  • Außerdem würden neue Sicherungen die alten überschreiben, enthalten aber ggfs. früher gelöschte Daten nicht mehr für eine spätere Wiederherstellung.
  • Zu viele Medien kosten aber unverhältnismäßig viel Geld. Daher ist ein Mittelweg nötig: ein Rotationsprinzip.
  • „Übliche“ Medien bei 5-Tage-Woche: 4 x Sohn (Mo – Do), 4 x Vater (Fr), 12 x Großvater (Monat)
• Hot/Cold Backup
  • Cold-Backup: Herunterfahren der zu sichernden Systeme nötig. Einfach, aber mit Downtime verbunden.
  • Hot-Backup: Systeme werden während des Betriebs gesichert. Schwierig (z.B. Redo-Logs bei Datenbanken), aber keine Downtime nötig.
• Mein privates Backup-Konzept
  • Nur eigene Dateien sichern, keine Betriebssystemdaten oder Programme.
  • Schritt 1: NAS* am lokalen Netzwerk.
  • Schritt 2: externe Festplatte* ohne Netzwerk/Strom.
  • Schritt 3: externe Festplatte außerhalb des Hauses.
  • Bestimmte Daten zum schnellen/einheitlichen Zugriff verschlüsselt in der (eigenen) Cloud.

Produktempfehlungen

Ich verwende seit Jahren die externen Festplatten von Western Digital* für meine privaten (!) Backups. Sie sind relativ günstig und benötigen lediglich einen USB-Anschluss am PC. Sie sind sehr klein und kompakt und auch recht leicht.

*

Zusammen mit einer praktischen Trage- und Schutztasche* kann man sie gut für Außer-Haus-Sicherungen nutzen. Dafür solltest du die Daten dann aber verschlüsseln, z.B. mit Bitlocker.

*

Für die schnelle Ad-hoc-Datensicherung zwischendurch nutze ich – ebenfalls seit einigen Jahren – ein NAS von Synology*. Das hat neben der Datensicherungsfunktion auch noch einen Haufen anderer Funktionen, wie z.B. Streamingserver für Multimedia, Webserver und viele weitere.

*

Zum Kopieren der Dateien nutze ich keine spezielle Backup-Software, sondern das kostenfreie SyncToy von Microsoft.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Externe Festplatte* für die private Datensicherung.
• NAS von Synology* für die schnelle Datensicherung im lokalen Netzwerk.
• Generationenprinzip
• Oracle Database Hot Backup and Recovery
• BitLocker
• SyncToy

Einen Rückblick auf die Fachgespräche (Fachinformatiker:in Anwendungsentwicklung) zu Teil 2 der gestreckten Abschlussprüfung im Sommer 2022 gibt es in der einhundertsiebenundsiebzigsten Episode des IT-Berufe-Podcasts.

Inhalt Fachgespräche Sommer 2022 (Fachinformatiker:in Anwendungsentwicklung)

• Disclaimer: Meine Erfahrungen aus den Prüfungen, an denen ich beteiligt war, ist nicht stellvertretend für alle Prüfungsausschüsse in Deutschland.
• Viele der genannten Themen für das Fachgespräch gelten 1-zu-1 in allen IT-Berufen, da sie gar nichts mit Anwendungsentwicklung zu tun haben (insb. die wirtschaftlichen Themen).
• Fast immer falsch beantwortet wurden Fragen nach Stundensatz, laufenden Kosten, Lösch-Anomalie, Lambda-Ausdrücken, generischen Klassen.

Häufige Fragen im Fachgespräch

Das hier ist meine Liste mit den häufigsten Fragen im Fachgespräch für Fachinformatiker:innen Anwendungsentwicklung, absteigend nach Anzahl sortiert.

Man erkennt deutlich, dass unter der Top-Themen sehr viele Wirtschaftsthemen sind, weil viele „Techniker:innen“ diesen Bereich bei der Prüfungsvorbereitung vernachlässigen und dementsprechend in Projektdokumentation und Projektpräsentation falsch machen, was dann entsprechende Fragen im Fachgespräch provoziert.

Viele der anderen Themen ergeben sich aus Technologien, die die Prüflinge selbst eingesetzt haben. Ich sage immer wieder: Alles, was man benutzt (oder in der Projektpräsentation erwähnt), muss man auch erklären können. Da viele Projekte aktuell als Single-Page-Application in JavaScript mit einer anderen Programmiersprache im Backend (z.B. Java) umgesetzt werden, kommen z.B. Fragen nach REST, OAuth, Typisierung und JavaScript-Spefizika immer öfter vor.

• Stundensatz (15)
  • Fast immer falsch berechnet (nur Brutto-Ausbildungsvergütung enthalten).
• Normalisierung (13)
  • Oft nicht sauber mit Fachbegriffen erklärt.
• Sozialversicherung (13)
  • Viele kennen den Arbeitgeberanteil nicht.
• Kapselung (11)
  • Getter/Setter, Sichtbarkeitsmodifizierer usw.
• Klasse vs. Objekt (11)
  • „Ein Objekt ist ein Teil einer Klasse“ usw.
• Lambda-Ausdrücke (11)
  • Werden ständig genutzt, aber nur sehr wenige Prüflinge können sie erklären.
• Vererbung (10)
  • Wir insb. in Frameworks häufig benötigt, aber zu den Details fehlen häufig Kenntnisse.
• Anomalien (Einfüge-/Änderungs-/Löschanomalie) (9)
  • Die Löschanomalie wurde dieses Jahr nicht einmal korrekt erklärt.
• Einzel- vs. Gemeinkosten (9)
  • Viele Prüflinge haben offensichtlich noch nie etwas von einem Kostenträger gehört.
• Polymorphie (9)
  • Viele Prüflinge werfen das mit Vererbung durcheinander und können es nicht sauber abgrenzen.
• Kardinalitäten (8)
  • Dieses Thema haben die meisten Prüflinge gut beantwortet, aber teilweise mit seltsamen Beispielen.
• Typisierung (8)
  • Die wenigsten Prüflinge können statisch/dynamisch und vor allem stark/schwach abgrenzen.
• Generische Klassen (7)
  • Sauber erklären können das die wenigsten Prüflinge.
• OAuth (6)
  • REST-APIs werden heute offensichtlich ohne jegliche Absicherung erstellt.
• Softwarequalität (6)
  • Die gute alte (und neue) ISO-Norm ist nur wenigen Prüflingen bekannt.
• fixe vs. variable Kosten (5)
  • Sie werden oft mit Einzel-/Gemeinkosten verwechselt.
• Hashverfahren (5)
  • Die Eigenschaften eines guten Hashverfahrens können die wenigsten Prüflinge nennen, wissen aber wenigstens, wofür man sie braucht.
• laufende Kosten (5)
  • In vielen Projekten gibt es keine (!) laufenden Kosten.
• Lohn vs. Gehalt (5)
  • Und natürlich darf auch die Ausbildungsvergütung nicht fehlen!
• MVC/MVVM/MVP usw. (5)
  • Die Architektur der eigenen Anwendung sollte man erklären und auch von Alternativen abgrenzen können.
• Redundanzen (5)
  • Der Feind jedes Datenbankmodellierers. Wird häufig richtig erklärt.
• REST (5)
  • Jeder nutzt es, kaum jemand kann es korrekt erklären.
• Scrum (5)
  • Quasi Grundwissen für alle IT-Berufe.
• Betriebsabrechnungsbogen (4)
  • Oft eine Anschlussfrage bei Einzel-/Gemeinkosten.
• Lastenheft/Pflichtenheft (4)
  • Viele Prüflinge verwechseln die Begriffe oder vergessen, dass das Pflichtenheft Vertragsbestandteil ist.
• referentielle Integrität (4)
  • Wird oft mit Redundanz durcheinander gebracht.
• Signatur (4)
  • Viele Prüflinge zählen die Sichtbarkeit, den Rückgabewert, static usw. mit zur Signatur.
• Testverfahren (4)
  • Es gibt soooo viele Testverfahren, aber meist sind nur Black- und White-Box-Test bekannt.
• Transaktionen (4)
  • Ja, auch die ACID-Kriterien darf man kennen.
• async/await (3)
  • Wenn man es benutzt, muss man es erklären können. Auch inkl. der technischen Umsetzung in der gewählten Programmiersprache.
• Fehlerarten bei der Programmierung (3)
  • Compile-Fehler, semantische Fehler, Laufzeitfehler usw. sollte man auseinanderhalten können.
• HTTP-Methoden (3)
  • Ganz oft werden POST, PUT und PATCH verwechselt.
• Kanban (3)
  • Für viele Prüflinge besteht der Prozess nur aus dem Kanban-Board.
• try/catch (3)
  • Das können die meisten Prüflinge erklären.
• Abschreibungen (2)
  • Meist eine Folgefrage zu Einzel-/Gemeinkosten. Mit ein wenig Hilfe kommen die meisten Prüflinge darauf.
• Datenschutz (2)
  • Traurig, wie wenige Prüflinge das sauber erklären und von Datensicherheit abgrenzen können.
• let/var/const in JavaScript (2)
  • Ein zentrales Feature von JavaScript, das auch häufig in Code-Beispielen der Prüflinge verwendet wird.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Zusammensetzung des Stundensatzes – Häufige Fragen im Fachgespräch
• Normalisierung – Häufige Fragen im Fachgespräch
• Erläuterung der Gehaltsabrechnung – Häufige Fragen im Fachgespräch
• Häufige Fragen im Fachgespräch – Kapselung
• Einführung in die Programmierung und Objektorientierung
• Häufige Fragen im Fachgespräch – Vererbung
• Häufige Fragen im Fachgespräch – Polymorphie
• Kryptographie – Hashverfahren und elektronische Signatur
• Scrum
• Lasten- und Pflichtenheft in der Projektdokumentation
• Algorithmen und Methoden (Lernzielkontrolle)
• Testverfahren für Software – Häufige Fragen im Fachgespräch
• Datenschutz vs. Datensicherheit vs. Datensicherung

Einen Rückblick auf die Projektpräsentationen (Fachinformatiker:in Anwendungsentwicklung) zu Teil 2 der gestreckten Abschlussprüfung im Sommer 2022 gibt es in der einhundertsechsundsiebzigsten Episode des IT-Berufe-Podcasts.

Inhalt Projektpräsentationen Sommer 2022 (Fachinformatiker:in Anwendungsentwicklung)

• Disclaimer: Meine Meinung ist nicht stellvertretend für alle Prüfungsausschüsse in Deutschland.
• Ich schaue insbesondere auf die Gestaltung der Folien und den Vortrag, aber wichtig sind natürlich auch die fachlichen/technischen Inhalte der Präsentation.
• Einzelne Punkte auf der folgenden Liste führen nicht zwangsläufig zu Punktabzug bei der Note, aber oft treten mehrere Punkte gemeinsam auf, was dann einen Punktabzug rechtfertigt.
• Viele „Probleme“ mit den Projektpräsentationen gelten 1-zu-1 in allen IT-Berufen, da sie gar nichts mit Anwendungsentwicklung zu tun haben.

Foliengestaltung und Vortrag

• Oft wurden Punktlisten nicht Schritt-für-Schritt eingeblendet, sondern sofort als Ganzes gezeigt.
• (Unnötige) Kopfzeile in einer Präsentation war winzig klein.
• Cliparts für die Darstellung des Ist-Zustands, anstatt eigene Fotos zu machen.
• Präsentationen vom selben Unternehmen sahen fast identisch aus und hatten auch einen sehr ähnlichen Aufbau.
• Der Text auf den Folien war oft sehr klein und kaum lesbar.
• (Offensichtliche) Rechtschreibfehler auf den Folien.
• Tortendiagramme sahen in fast allen Präsentationen identisch aus (Standardfarben von PowerPoint genutzt).
• Vorstellung des Prüflings: graue Silhouette statt Bild verwendet.
• Präsentation mit LaTeX erstellt, aber leider ausschließlich Textfolien.
• Code wurde durch Zeigen an der Leinwand erklärt, anstatt ihn visuell hervorzuheben.
• Prüfling kommentierte die Vorstellung des Unternehmens mit „hier habe ich mal statt des klassischen Bildes unsere Azubis genommen“.
• Ein Prüfling hat die Architektur seiner Anwendung an die Tafel gezeichnet.
• Einige Prüflinge haben stark abgelesen und kaum Blickkontakt zum Prüfungsausschuss gehabt.

Fehlende/unnötige Inhalte

• Oft wurden die Artefakte aus der Projektdokumentation nicht in der Projektpräsentation gezeigt.
• Oft werden Inhalte genannt, aber nicht visualisiert (z.B. 3-Schichten-Architektur ohne Grafik).
• Angeblich erstellte Artefakte werden erwähnt, aber nicht gezeigt.
• Teilweise wurde viel zu detailliert auf Code eingegangen.
• Das Ziel des Projekts wird oft nicht deutlich.
• Jedes genutzt JavaScript-Package wurde inkl. Versionsnummer aufgeführt und erklärt.
• Ein Prüfling hat jede verwendete Technologie ausführlich erklärt (z.B. Kafka und Kubernetes).
• Scrum wurde in einer Präsentation ausführlich erklärt.

Sonstiges

• Notepad++ als IDE verwendet.
• Deployment als Upload auf einen FTP-Server.
• Einige Prüflinge haben den Prüfungsausschuss geduzt.
• Prüfling mit Mac hatte keinen Adapter für HDMI dabei.
• Prüfling hat einen Programmablaufplan erstellt, anstatt ein UML-Diagramm zu nutzen.
• Einige Unternehmen entwickeln wohl auf Englisch, aber niemand schaut auf die korrekten Vokabeln.

Mögliche/erwartete Artefakte

Die folgenden Artefakte sind in einer Projektpräsentation möglich bzw. ich würde sie in einer „sehr guten“ Arbeit erwarten. Auch hier gilt: Wenn mal eines oder mehrere der Artefakte fehlen, heißt das nicht automatisch, dass eine schlechte Note folgt. Es geht immer auch um den Gesamteindruck der Präsentation inkl. Gestik, Mimik usw.

• Projektplanung: Zeitplanung, Ressourcen, Entwicklungsprozess, Kosten, Amortisation
• Ziel des Projekts: Use-Case-Diagramm, Aktivitätsdiagramm, Lasten-/Pflichtenheft, ereignisgesteuerte Prozesskette
• Architektur: Komponentendiagramm
• Technologien: Programmiersprache, Frameworks
• Implementierung: Source Code, Klassendiagramm, Sequenzdiagramm
• Datenmodellierung: Entity-Relationship-Modell, Tabellenmodell
• Test: Source Code, Testprotokoll
• User Interface: Mockups
• Qualitätssicherung: Code-Reviews, Entwicklungsprozess, statische Codeanalyse, CI/CD
• Dokumentation: Entwickler-/Kundendokumentation
• Ergebnis des Projekts: Screenshots
• Fazit: Soll-/Ist-Vergleich, Abnahme, Lessons Learned, Ausblick

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Cliparts werten die Folien auf! – Mythen der Projektpräsentation
• Foliennummern bzw. Seitenzahlen gehören auf jede Folie! – Mythen der Projektpräsentation
• Corporate Design ist Pflicht – Mythen der Projektpräsentation
• Sourcecode gehört nicht in die Präsentation – Mythen der Projektpräsentation
• Technische Inhalte kann man nicht mit Bildern illustrieren – Mythen der Projektpräsentation
• Inhalte der Projektpräsentation

Einen Rückblick auf die Projektdokumentationen (Fachinformatiker:in Anwendungsentwicklung) zu Teil 2 der gestreckten Abschlussprüfung im Sommer 2022 gibt es in der einhundertfünfundsiebzigsten Episode des IT-Berufe-Podcasts.

Inhalt Projektdokumentationen Sommer 2022 (Fachinformatiker:in Anwendungsentwicklung)

• Disclaimer: Meine Meinung ist nicht stellvertretend für alle Prüfungsausschüsse in Deutschland.
• Ich schaue oft auch auf die formellen Details, aber wichtiger sind natürlich immer die fachlichen/technischen Inhalte.
• Einzelne Punkte auf der folgenden Liste führen nicht zwangsläufig zu Punktabzug bei der Note, aber oft treten mehrere Punkte gemeinsam auf, was dann einen Punktabzug rechtfertigt.
• Viele „Probleme“ mit den Projektdokumentationen gelten 1-zu-1 in allen IT-Berufen, da sie gar nichts mit Anwendungsentwicklung zu tun haben.

Allgemeines

• Messaging wird in mehreren Projekten eingesetzt.
• Nur wenige Use-Case-Diagramme gesehen. -> Was macht das System eigentlich?
• Oft wurde ein Tabellenmodell ER-Modell genannt.
• Frameworks oder gar Programmiersprachen waren vor der Projektdurchführung nicht bekannt.

Formalia

• Abbildungen wurden mit ihrem Namen referenziert, anstatt mit der Seitenzahl.
• Einige Dokumentationen waren im Flattersatz gesetzt.
• Eine Dokumentation hatte 5 (!) Ebenen im Inhaltsverzeichnis, also z.B. bis Kapitel 4.2.4.1.2.
• Ein Kapitel bestand nur aus einem (!) Aufzählungspunkt.
• „Textmarke nicht definiert“ im Dokument.

Stundensatzberechnung

• Es wurden verschiedene Stundensätze für einzelne Mitarbeiter angegeben, dann aber nur mit einem einheitlichen gerechnet.
• Der Stundensatz wurde oft nur aus der Azubivergütung berechnet (z.B. Vergütung / 20 / 8 -> 6 EUR/h).
• Ein Prüfling hat explizit geschrieben, dass der Stundensatz sich nur aus der Azubivergütung berechnet, setzt dann aber 75 EUR/h an.
• Oft wird der Datenschutz als Begründung genutzt, die echten Stundensätze nicht nennen zu können.

Kosten

• Es wurden 500 EUR/Monat als laufende Kosten für einen (!) Server angesetzt.
• Die Abnahme wurde mit 3h eingeplant, aber nur mit 1h in den Kosten aufgeführt.
• Stunden des Fachbereichs tauchten nicht in den Kosten auf.
• Ein Prüfling hat die Stunden anderer Mitarbeiter mit in seine 70h aufsummiert.

Begründung von Entscheidungen

• Begründung für technische Entscheidung: „Ich soll das so machen.“
• Ein Prüfling hat durchgängig geschrieben, dass „man“ das Projekt umgesetzt hat.
• Es gab eine Nutzwertanalyse, bei der die Eigenentwicklung in allen (!) Kriterien die maximale Punktzahl hatte.

Anforderungsermittlung

• Im Lastenheft wurde vom Kunden angeblich Java 11 und Messaging gefordert.
• Ein Lastenheft bestand nur aus zwei Sätzen und das dazu passende Pflichtenheft war „nicht nötig“.
• Die Programmiersprache wurde in einer gesamten Dokumentation nicht genannt.

Fehlende oder überflüssige Inhalte

• Eine Dokumentation enthielt keinerlei Zeitplanung, Phasen oder Prozess.
• Die Qualitätssicherung fehlt oft komplett (z.B. Testen, CI/CD, Reviews).
• Auf 1/2 Seite wurde Scrum im Detail erklärt bzw. auf einer ganzen Seite REST.

Sonstiges

• Ein Prüfling hat sich eigene Diagrammformen ausgedacht, anstatt einfach UML zu nutzen.
• Beim Soll-Ist-Vergleich wurde Soll – Ist gerechnet.
• Security wurde bei SSH absichtlich ausgeschaltet.
• In einer Detailplanung war ein Block 23h lang.
• Es wurde mit einer Low-Code-Plattform gearbeitet, für die es eigentlich nichts zu programmieren gab.
• REST wird inzwischen sehr oft verwendet, aber die wenigsten Prüflinge wissen, wie man die APIs absichert.
• REST-APIs sehen oft sehr seltsam aus („GetById“ im Path).

Positiv aufgefallen

• Das Code-Review hat tatsächlich auch mögliche Optimierungen ergeben (Namen, Struktur).

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Datenbankmodellierung (Lernzielkontrolle zum relationalen Tabellenmodell)
• Datenbankmodellierung (Lernzielkontrolle zum Entity-Relationship-Modell)
• Welche Programmiersprache du für dein Abschlussprojekt verwenden solltest
• Berechnung des eigenen Stundensatzes in der Projektdokumentation (FAQ)
• Datenschutz vs. Datensicherheit vs. Datensicherung
• Nutzwertanalyse in der Projektdokumentation
• Lasten- und Pflichtenheft in der Projektdokumentation
• Scrum
• Einführung in Continuous Integration
• Unit-Tests – Häufige Fragen im Fachgespräch
• Elena Hollen über Code Reviews und Extreme Programming

Einen kurzen Rückblick auf Teil 1 der gestreckten Abschlussprüfung im Frühjahr 2022 gibt es in der einhundertvierundsiebzigsten Episode des IT-Berufe-Podcasts.

Inhalt Die Aufgaben

Aufgabe 1: So noch nie gesehen!

• Präsentationen erstellen: Folien und Notizen formulieren
• Schlagworte erklären: u.a. Big Data, Industrie 4.0, DSGVO
• Inhalte für ein Angebot begründen

Aufgabe 2: Sehr hardwarelastig mit vielen Bildern!

• Einbau einer CPU erklären
• Wärmeleitpaste erläutern
• RAM im Dual Channel betreiben
• SSD SATA und M.2 unterscheiden
• Grafikanschlüsse benennen
• USB-C vs. USB-A
• Erklären: logische Prozessoren, Cache
• GHz in Hertz umrechnen

Aufgabe 3: Netzwerkanalyse aus der Praxis.

• Wie kommt der Laptop ins WLAN?
• WPA-PSK vs. RADIUS
• ISO/OSI rauf und runter
• Infos aus Screenshot Schicht 1 zuordnen
• MAC und Local IPv6 erklären
• DHCP erkennen
• Netz-/Host-/Broadcast-Adresse ermitteln
• Fehler benennen

Aufgabe 4: Ein bisschen (!) was für Anwendungsentwickler:innen.

• Workspace-Management-Software
• Cloud vs. On-Premises
• Eigenfertigung vs. Lizenzen berechnen
• Struktogramm befüllen
• Uploaddauer berechnen

Meine „Highlights“

• RADIUS != Radius (halber Kreisdurchmesser)
• DHCP vs. DNS (oft durcheinander gebracht)
• Subnetting konnten fast alle

Tipps für zukünftige Prüfungen

• Standardinhalte anschauen (ISO/OSI, Algorithmen)
• Hardware und Netzwerktechnik wurde recht tiefgehend, aber auch praxisbezogen abgefragt
• Alle Seiten der Prüfung anschauen und nicht beim Konzeptpapier aufhören
• Aufgaben komplett lesen und alle Fragestellungen analog den Formulierungen beantworten
• nicht nur Theorie, sondern auch Praxis lernen (ipconfig etc.)
• alle Abkürzungen lernen (z.B. DHCP, RADIUS, DNS)
• Vorsilben wie Giga und Mega lernen und von Gibi und Mibi abgrenzen

Ergebnis

• schlechtes Ergebnis, schlechter Schnitt, kaum sehr gute Noten
• FISI und FIAE sehr ähnlich abgeschnitten
• FISI: Aufgabe 4 schlecht, FIAE: Aufgabe 3 schlecht
• Aufgabe 3 am schlechtesten insgesamt

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Das ISO/OSI-Modell (Teil 1) (erster Teil der Serie)
• URLs (Netzwerkgrundlagen) (erster Teil der Serie)
• Cloud Computing Teil 1 (On Premise und Virtuelle Maschinen) (erster Teil der Serie)

Um die Prüfungsvorbereitung auf Teil 1 der gestreckten Abschlussprüfung (GAP) der IT-Berufe im Bereich Projektmanagement geht es in der einhundertdreiundsiebzigsten Episode des IT-Berufe-Podcasts.

Planen, Vorbereiten und Durchführen von Arbeitsaufgaben in Abstimmung mit den kundenspezifischen Geschäfts- und Leistungsprozessen

Nachtrag zu Teil 1:

• Change Management (Prozess zur Umsetzung von Veränderungen in Unternehmen) z.B. nach Lewin (Unfreeze, Change, Refreeze)
• Kaizen, Continuous Improvement

1e: Probleme analysieren und als Aufgabe definieren sowie Lösungsalternativen entwickeln und beurteilen

• Analysieren im Sinne von Erkennen und Einordnen
• Problemlösungsvarianten entwickeln
• Probleme beseitigen durch, z.B.:
  • Situationsanalyse
  • Problemeingrenzung
  • Aufzeigen von Alternativen
  • Auswahl von Lösungen
  • Analysieren der Chancen und Risiken der ausgewählten Lösung anhand vorher definierter Beurteilungskriterien

• Root-Cause-Analysis
• 5 Whys

1f: Arbeits- und Organisationsmittel wirtschaftlich und ökologisch unter Berücksichtigung der vorhandenen Ressourcen und der Budgetvorgaben einsetzen

• Berücksichtigung der Formen von Arbeitsorganisation, z.B.:
  • Gruppenarbeit
  • Pair Programming
• Budgetplanung als Teil der Unternehmensplanung
• effektiver und effizienter Einsatz von Arbeits- und Organisationsmitteln
• Prüfung des Ressourceneinsatzes auf:
  • rechtliche Zulässigkeit
  • technische und organisatorische Machbarkeit
  • ökologische Nachhaltigkeit und Wirtschaftlichkeit
• Prüfung der Wirtschaftlichkeit mittels betriebswirtschaftlicher Methoden, z.B.:
  • Rentabilitätsrechnung
  • Amortisationsrechnung

• Machbarkeitsanalyse: technisch, organisatorisch, wirtschaftlich, zeitlich, rechtlich
• Make-or-buy-Entscheidung
• Effektivität: Die richtigen Dinge tun. Effizienz: Die Dinge richtig tun.
• Budget: die für einen bestimmten Zweck zur Verfügung stehenden Geldmittel
• Umsatz: Absatzmenge * Verkaufspreis
• Gewinn: Erlöse – Kosten
• Deckungsbeitrag: Stückpreis – variable Stückkosten
• Rentabilität: Gewinn / Kapital
• Amortisation: Investition / Ertrag pro Jahr

1g: Aufgaben im Team sowie mit internen und externen Kunden und Kundinnen planen und abstimmen

• Team als soziales Gefüge verstehen („social awareness“)
• Phasen der Teamentwicklung kennen und anwenden (Konflikt, Kontrakt, Kooperation)
• Methoden des sachbezogenen Verhandelns kennen und anwenden, z.B.:
  • Win-win-Strategie
  • Harvard-Konzept
• adressatengerechte Kommunikation

• Prozess der Teambildung nach Bruce Tuckman: Forming, Storming, Norming, Performing, (Adjourning)
• Win-win: Konfliktlösung ohne Verlierer
• Harvard-Konzept
  • Menschen und Interessen trennen
  • Fokus auf Interessen und nicht auf Positionen
  • Entscheidungsoptionen entwickeln
  • objektive Beurteilungskriterien anwenden
• BATNA: Best Alternative To a Negotiated Agreement
• Communication is what the listener does (Peter Drucker)

1h: betriebswirtschaftlich relevante Daten erheben und bewerten und dabei Geschäfts- und Leistungsprozesse berücksichtigen

• Bewerten anhand vorgegebener unternehmensspezifischer Daten

1i: eigene Vorgehensweise sowie die Aufgabendurchführung im Team reflektieren und bei der Verbesserung der Arbeitsprozesse mitwirken

• gemeinsame kritische Analyse der bisherigen Zusammenarbeit und der Ergebnisse („lessons learnt“)
• offenes Ansprechen von Erfolgen und Problemen
• gemeinsame Entwicklung von Maßnahmen zur Verbesserung, z.B. SCRUM-Retrospektive
• konstruktive Kritik

• Retrospektive: Wie kann der Prozess und die Zusammenarbeit im Team verbessert werden?
• konstruktive Kritik: konkrete Wahrnehmung schildern (nicht interpretieren, nicht verallgemeinern), Auswirkungen aufzeigen, Ich-Botschaft senden, Wunsch äußern

Literaturempfehlungen

Das hier ist die „Handreichung“, von der ich im Podcast spreche:

*

*

*

*

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• 7 Change Management Methoden, die du kennen solltest
• Mein Projekt amortisiert sich nicht
• Anforderungsermittlung (nicht nur für dein Abschlussprojekt)
• Manager Tools

Um die Prüfungsvorbereitung auf Teil 1 der gestreckten Abschlussprüfung (GAP) der IT-Berufe im Bereich Projektmanagement geht es in der einhundertzweiundsiebzigsten Episode des IT-Berufe-Podcasts.

Planen, Vorbereiten und Durchführen von Arbeitsaufgaben in Abstimmung mit den kundenspezifischen Geschäfts- und Leistungsprozessen 1a: Grundsätze und Methoden des Projektmanagements anwenden

• Initiieren, Planen, Steuern, Kontrollieren und Abschließen von Projekten nach aktuell gängigen Projektmanagementstandards
• Anwendung von Methoden, Hilfsmitteln, Techniken und Kompetenzen in einem Projekt, z.B.:
  • Projektplan
  • Meilensteine
  • Risikoanalyse
  • Standards und Normen
  • Projektmanagementsysteme
• Basiskenntnisse des Veränderungsmanagements
• Unterscheiden verschiedener Projektmanagementmethoden und Vorgehensmodelle, z.B.:
  • agiles Projektmanagement
  • V-Modell
  • Spiralmodell
  • Wasserfallmodell

• Projekt: zeitlich befristet, relativ innovativ, risikobehaftet, erhebliche Komplexität, erfordert ein Projektmanagement
  • nach DIN 69901: Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist
  • nach PRINCE2: a temporary organization that is created for the purpose of delivering one or more business products according to an agreed Business Case
• Magisches Dreieck: Qualität, Kosten, Zeit
• Qualität: Übereinstimmung mit Anforderungen
• SMARTe Ziele: spezifisch, messbar, attraktiv, realistisch, terminiert
• 4-Phasen-Modell
  • Projektdefinition
  • Projektplanung
  • Projektdurchführung und -controlling
  • Projektabschluss
• Kick-Off-Meeting
  • Nach erfolgter Planung vor Start der Projektdurchführung.
  • Projektstrukturplan wird erstellt.
• Meilensteine: wichtige Ereignisse des Projekts werden visualisiert und geplant
• Lasten- und Pflichtenheft
• Kritischer Pfad: Gesamtpuffer ist 0, bestimmt die gesamte Projektdauer
• Vorgehensmodelle
  • „klassisch“: Wasserfall, V-Modell, Spiralmodell
  • agil: Scrum, Kanban, Extreme Programming

1b: Auftragsunterlagen und Durchführbarkeit des Auftrags prüfen, insbesondere in Hinblick auf rechtliche, wirtschaftliche und terminliche Vorgaben, und den Auftrag mit den betrieblichen Prozessen und Möglichkeiten abstimmen

• Beachten der Voraussetzungen im eigenen Arbeitsumfeld
• Definieren von Aufgaben, Rollen und Verantwortlichkeiten für alle Projektbeteiligten, z.B.:
  • Projekt-Auftraggeber
  • Projektleiter
  • Projekt-Steuerkreis
  • Projektmitarbeiter

• Stakeholder: Gruppen oder Personen, die irgendein Interesse am Projekt haben.
• Aufgaben eines Projektleiters: Mitwirkung bei der Zieldefinition, Koordination des Teams, Aufgabenverteilung innerhalb des Teams, Überwachung der Projektfortschritte, Kommunikation, Projektcontrolling, Dokumentation, Aufwandschätzung, Vorlage der Ergebnisse beim Lenkungsausschuss, Eskalation von Konfliktsituationen, Erstellen des Projektabschlussberichtes

1c: Zeitplan und Reihenfolge der Arbeitsschritte für den eigenen Arbeitsbereich festlegen

• Definieren und Festlegen von Arbeitspaketen und Abhängigkeiten
• Erleichterung der Planung und der Fortschrittskontrolle durch Aufteilung des Arbeits- bzw. Projektverlaufs in überprüfbare Etappen mit Zwischenzielen
• Umsetzung der Arbeitspakete in konkrete Handlungen und Messen anhand von Prüfkriterien
• ggf. Ableiten einer Prognose für den weiteren Fortschritt bzw. den Endtermin

• Ticketsystem: Verteilung der Aufgaben, Koordination der Beteiligten, Historie, Dokumentation, Auswertungen
• Netzplan
  • Dauer der Aktivitäten
  • zeitliche und logische Abhängigkeiten werden gezeigt
  • Pufferzeiten und der kritische Pfad sind erkennbar
  • frühester/spätester Anfangszeitpunkt, frühester/spätester Endezeitpunkt, Gesamtpuffer, freier Puffer
• Gantt-Diagramm
  • zeitliche Reihenfolge der Aktivitäten auf einer Zeitachse (z.B. Kalenderwochen)
  • Parallelität sichtbar
  • Abhängigkeiten können visualisiert werden

1d: Termine planen und abstimmen sowie Terminüberwachung durchführen

• Nutzung verschiedener Projektmanagementsysteme
• Erstellung von Projektstrukturplänen zur Gliederung von Projekten in plan- und kontrollierbare Elemente
• vollständige Erfassung aller relevanten Tätigkeiten eines Projektes (funktionsorientierte, objektorientierte oder zeitorientierte Gliederung) im Top-down-, Bottom-up- oder Yo-Yo-Ansatz
• Visualisierung, z.B.:
  • Netzplantechnik
  • Scrum Board
  • Kanban Board
  • Gantt-Diagramme

• Projektstrukturplan
  • statische Sicht
  • Zerlegung des Gesamtprojekts in Teilschritte
  • Top-Down-Verfahren (deduktiv) vs. Bottom-Up-Verfahren (induktiv) vs. Yo-Yo-Verfahren (Gegenstromverfahren)
• Kanban-Board: WIP-Limit (work in progress), Pull statt Push, Spalten entsprechen Prozessschritten

Literaturempfehlungen

*

*

*

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Das agile Manifest
• Scrum

Um konkretere Tipps zur Prüfungsvorbereitung auf Teil 1 der gestreckten Abschlussprüfung (nach der Neuordnung der IT-Berufe 2020) geht es in der einhunderteinundsiebzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Als Ergänzung zu Episode #168: Prüfungsvorbereitung auf Teil 1 der gestreckten Abschlussprüfung der IT-Berufe kommen hier einige konkrete Tipps zur Prüfungsvorbereitung auf den ersten Teil der gestreckten Abschlussprüfung der IT-Berufe.

Inhalte der ersten Prüfung

• Handlungsschritt 1: Projektplanung
  • Was definiert ein Projekt?
  • SMARTe Ziele erklären
  • Netzplan vervollständigen, kritischen Pfad finden
• Handlungsschritt 2: Energiekosten
  • Vergleich des Stromverbrauchs verschiedener Netzteile
  • Amortisationsrechnung des Netzteils
  • Weitere Maßnahmen zum Stromsparen vorschlagen
  • Berechnung der erlaubten Geräte für eine Steckdose
  • Fehler in kurzem PowerShell-Script finden
• Handlungsschritt 3: Projektarbeit
  • Aufgaben im Projekt-Kickoff-Meeting
  • Kosten für Einsatz von externen Mitarbeitern berechnen
  • Dauer der Projektlaufzeit mit eigenen Mitarbeitern berechnen
  • Vor-/Nachteile Remote-Arbeit vs. Vor-Ort
  • Schulungsmaßnahmen erkläutern
  • RAID 0, 1 und 5 erklären
• Handlungsschritt 4: IT-Security und Datenschutz
  • Schutzmaßnahmen Vertraulichkeit, Integrität und Verfügbarkeit zuordnen und begründen
  • Konkrete Maßnahmen zu Sicherheitsmechanismen nennen
  • Schutzbedarfe verschiedener Anwendungen begründen
  • Rechtliche Grundlage des Datenschutzes nennen
  • Anforderungen an sichere Passwörter erläutern
  • Backup-Verfahren bewerten
  • Alternatives Backup-Verfahren vorschlagen

Meine Einschätzung und Feedback zu den Prüfungsinhalten

• Die Prüfung war für alle IT-Berufe identisch.
• Die Aufgaben sind alle im Freitext zu beantworten. Es gibt keine Multiple-Choice-Aufgaben mehr wie früher in der Zwischenprüfung.
• Es darf kein Handlungsschritt gestrichen werden.
• Die Handlungsschritte sind unterschiedlich gewichtet: zwischen 24 und 26 Punkten statt einheitlich 25 Punkten.
• Niveau der Prüfungsfragen vergleichbar mit früherer GA2 (Ganzheitliche Aufgaben 2, Kernqualifikationen für alle IT-Berufe).
• Nicht nur auswendig gelernte Inhalte abspulen, sondern erläutern, begründen und bewerten.
• Einige „Standardinhalte“ der ehemaligen GA2 wurden abgefragt.
• Durchaus triviale Rechenaufgaben (Multiplikation/Division, Dreisatz).
• Auch implizites Wissen zur Beantwortung der Fragen nötig (z.B. Umrechnung Watt/Ampere, Amortisation).
• Wenig Programmierung: nur Fehler in kurzem Code finden. Code eher FISI-lastig (PowerShell).
• Bei der Aufgabe zum Netzplan könnten sich Folgefehler ergeben, wenn die erste Teilaufgabe nicht korrekt beantwortet wurde.
• Eigener Handlungsschritt zu Security und Datenschutz.
• Nicht alle abgefragten Inhalte wurden bis zur Prüfung in der Berufsschule behandelt.
• Die ersten Ergebnisse waren durchwachsen (Noten 3-5).

Tipps zur Vorbereitung auf die Prüfung

• Alte IHK-Prüfungen vor 2021 durchgehen mit deutlichem Fokus auf GA2.
• Insbesondere die „neuen“ Inhalte des Ausbildungsrahmenplans (z.B. Security, Datenschutz) anschauen.
• Früh mit dem Lernen anfangen! Die Menge an Stoff ist sehr groß.
• Nicht nur auswendig lernen, sondern verstehen und mit eigenen Worten formulieren und anwenden lernen.
• Alte Zwischenprüfungen können als Ergänzung bearbeitet werden, helfen aber nicht wirklich weiter.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Neuordnungsverfahren der IT-Berufe: Interview mit Silvio Kennecke und Jörg Ferrando
• Datenschutz vs. Datensicherheit vs. Datensicherung
• Prüfungsstatistik der Industrie- und Handelskammer (Vorauswahl Oldenburg)

Über seine Arbeit als IT-Freelancer erzählt Christian Dröge in der einhundertsiebzigsten Episode des IT-Berufe-Podcasts.

Die Arbeit als IT-Freelancer Allgemeines zur Person

• Wie ist dein Name?
  • Christian Dröge, 43 Jahre alt, aus Frankfurt. Ich bin seit 2007 Freelancer in der IT.
• An welchen Projekten arbeitest du zur Zeit?
  • Als IT-Consultant bin ich zurzeit in einem Digitalisierungsprojekt bei einem internationalen Real Estate Asset Manager, der Immobilien-Fonds verwaltet.
  • Hier habe ich mit einem IT-Freelancer-Kollegen (Software Entwickler/Architekt) eine Art ERP (Enterprise Resource Planning) bzw. ein Portfolio Management System mit DWH (Data Warehouse) gebaut. Ziel des Projekts ist es, von der Excel-Welt via Datenbankanwendung zur Web-Anwendung zu kommen.
  • Technisch habe ich hier mit Microsoft SQL Server, Access und Excel also mit T-SQL und VBA viel zu tun. Mein Kollege programmiert sehr viel mit C# und PowerShell für Schnittstellen, um u.a. CSV- und XML-Dateien zu importieren und exportieren.
  • Ich beginne bald noch ein weiteres Projekt als Requirements Engineer bzw. Anforderungsmanager im öffentlichen Sektor, wo ich es mit Oracle-Datenbank, XML, BPMN und UML zu tun habe. Das bestehende Projekt bzw. System betreue ich dann ein bisschen nebenbei.
• Wie bist du zur Informatik gekommen?
  • Über das Computerspielen hatte ich schon in der Kindheit mit C64, Amiga 500 und PC immer schon viel Spaß mit dem Computer. Ende der 90er kam noch das Internet dazu.
  • In den 90ger-Jahren habe ich ein Fachabitur Wirtschaft und eine Ausbildung zum Groß- und Außenhandelskaufmann gemacht. Ich wollte unbedingt etwas Kreatives studieren, weil ich gerne zeichne und mir Comics und Brettspiele ausdenke. Aber mein Wunsch Kommunikationsdesign hat nicht geklappt.
  • Irgendwann wusste ich, dass ich etwas Kreatives bzw. Technisches erschaffen können muss, um langfristig erfolgreich und unabhängig zu sein. Als Kaufmann braucht man ja jemanden, der ein Produkt bzw. Dienstleistung erschaffen kann, um es verkaufen zu können.
• Welche Ausbildung bzw. welches Studium hast du im Bereich der Informatik absolviert?
  • Ich habe ein FH-Diplom in Wirtschaftsinformatik.
  • Angefangen habe ich mit Medieninformatik, aber darunter hatte ich mir etwas anderes vorgestellt.
  • Vor paar Jahren habe ich auch an der Uni Bamberg Wirtschaftsinformatik studiert, um einen Master berufsbegleitend zu machen. Habe ich aber nach 3 Jahren abgebrochen, da zu aufwändig und zu wenig Mehrwert für einen IT-Freelancer wie mich.
• Mit welcher/n Programmiersprache/n arbeitest du im Alltag?
  • Hauptsächlich VBA mit SQL.
• Was ist deine Lieblingsprogrammiersprache und warum?
  • Mir gefällt aus dem Studium Java und im Job bzw. Fortbildung C#, da einfacher als C++ (Studium). Aber ich kann aktuell nur noch VBA gut, da ich direkt bei den Fachabteilungen arbeite und die haben nur Microsoft Office und somit VBA im Einsatz.

IT-Freelancing

• Welche Dienstleistungen bietest du genau an?
  • IT-Beratung mit Schwerpunkt Business Analyse und Requirements Engineering für Datenmanagementlösungen also Datenbanken und Business Intelligence.
  • Vor Projekten berate ich die Kunden zu Business Cases oder Make-or-buy-Entscheidungen.
  • Ich berate auch dabei, welche Rollen für das Team benötigt werden. Und am Ende gibt es „Lessons Learned“.
  • Im klassischen Wasserfallmodell erstelle ich z.B. Pflichtenhefte. Hier wird oft DOORS eingesetzt.
  • Methodiken, die ich einsetze: Pflichtenheft, UML (Aktivität, UseCase), BPMN (SwimLanes, Prozessmodellierung).
  • PowerPoint setze ich auch gerne zum „Malen“ von Prozessen ein. Visio hat meist niemand, genau wie Microsoft Project. LucidCharts ist auch interessant für kleine Projekte.
  • Weiterer Schwerpunkt von mir: Datenbanken, Business Intelligence, Datenmodellierung, XML-Schnittstellen, relationale Datenbanken, Microsoft SQL Server/Oracle. Daten modellieren und für Fachbereich bereitstellen mit Excel/Access, PowerBI etc.
  • Bei „Make-or-buy“ schaue ich, ob es Lösungen am Markt gibt („best of breed“). Sonst bauen wir die selbst.
  • Prototyping ist dabei immer wichtig und macht auch viel Spaß.
  • Viele Kunden haben Daten noch in PDF-Dateien und Excel und sind noch längst nicht bei „Big Data“ angekommen!
• Wie sieht dein Alltag als Freelancer aus? 9-to-5 oder Überstunden ohne Ende?
  • Wenn die Familie versorgt ist, setze ich mich an den Computer und bearbeite meine E-Mails (erst die wichtigen des Freelancers, dann die der Kundenprojekte) oder fahre zum Kunden.
• Arbeitest du wirklich „selbst“ und „ständig“?
  • Ich arbeite in den Projekten selbst. Beim Drumherum (Büro, Papierkram, Buchhaltung, etc.) unterstützt mich meine Frau, die für mich seit 10 Jahren arbeitet.
  • Ständig arbeite ich nicht. Ich bin natürlich immer an Methoden, IT und Wirtschaft (also Prozessen und Management) interessiert. Ich arbeite nicht mehr als andere. 40 Stunden pro Woche.
• Wann und warum hast du den Entschluss gefasst, dich selbstständig zu machen?
  • Während meines ersten Projekts als festangestellter IT-Berater. Ein Kollege hat mir gesagt, er mache sich jetzt selbstständig, und mir empfohlen, das auch zu tun.
  • Mein Ziel war, selbst über die Projekte entscheiden zu können und natürlich auch mehr zu verdienen.
  • Vorher war ich Praktikant und habe mitbekommen, dass Berater 1.000 EUR Tagessatz haben. Das hat mich schon beeindruckt.
• Wie lange dauern deine Projekte?
  • Ich mache eher lange Projekte, also durchaus mehrere Jahre.
  • Oft gibt es auch Folgeprojekte, denn die Systeme haben eine lange Lebensdauer. Da kommen dann weitere Anforderungen dazu.
• Wie entscheidest du dich zwischen konkurrierenden Projekten?
  • Das Projekt, welches zur meiner Rolle, meinen Skills und zu meiner Lebenssituation passt, nehme ich an. Also IT-Berater (Datenbanken), Remote, langfristig (> 6 Monate) und höchster Stundensatz ist am interessantesten.
  • Ich habe meist ein Hauptprojekt und ein Nebenprojekt in „Teilzeit“.
• Wie findest du deine Kunden/Projekte?
  • XING, LinkedIn, Freelancermap, Lyncronize, Gulp, oder Personalberater (z.B. Hays) kontaktieren mich.
• Wie bist du in die Selbstständigkeit gestartet? Was war dein erstes Projekt?
  • Ein Kollege hat sich selbstständig gemacht und mich „inspiriert“.
  • Ich hatte einen „Deal“ mit meinem Arbeitgeber, dass ich 25% vom Tagessatz abgebe.
  • 2007 lag ich bei 67,50 EUR pro Stunde „all in“. Das war viel Geld für mich!
  • Als IT-Freelancer konnte ich innerhalb eines Monats mein Einkommen im Vergleich zu meinem Gehalt als festangestellter IT-Berater verdreifachen.
  • Festangestellt hatte ich zwar eine gewisse „Sicherheit“, aber ich habe es einfach ausprobiert und bin das Risiko eingegangen.
  • Seit 2007 war ich nicht einen Tag ohne Projekt!
• Ist der Freelancer krisenfester als eine Festanstellung?
  • IT wird immer gebraucht, aber es kommt auch auf das Unternehmen an.
  • Ich habe als Junior IT-Consultant im Jahr 2008 schon einmal über 20.000 EUR Umsatz im Monat durch viele Überstunden verdient. Das ist als Festangestellter nicht so einfach möglich.
• Was sind aus deiner Sicht die Vor- und Nachteile des Freelancings ggü. einer Festanstellung?
  • Mehr Freiheit (wo und was) und (viel) mehr Geld als Fachkraft.
  • Kein Geld bei Urlaub, Krankheit, wenn kein Projekt läuft und während Fortbildungen.
  • Wenn man oft krank ist, ist der Job Freelancer nichts! Und viel Urlaub ist meist auch nicht drin, denn in der Zeit verdient man nichts.
• Arbeitest du eher remote oder vor Ort bei Kunden?
  • Vor Corona vor Ort. Jetzt ca. 80% Remote.
• Wie hast du deinen (ersten) Stundensatz bestimmt?
  • Deal mit Arbeitgeber: Stundensatz – 25%
  • Ansonsten Durchschnitt IT-Freelancer-Marktpreis (Projektmanager, Berater, Entwickler, Admin, Tester, Support), immer mehr als jetzt und nicht weniger als aktuell, weniger nur, wenn es andere Vorteile gibt, wie z.B. 100% Remote.
  • 95 EUR ist aktuell der Marktdurchschnitt, geht aber 2021 wieder runter (ca. 10%) wegen 100% Remote-Arbeit.
  • Ein hoher Stundensatz heißt aber auch oft: „Den müssen wir schnell wieder loswerden!“ Daher eher am Markt orientieren. Dann ist man „ständig da“ und läuft unter dem Radar.
• Gibt es etwas, das du am Freelancing nicht magst (z.B. Buchhaltung, Akquise)?
  • Die Ungewissheit (Trends und Krisen), da ich mir die Projekte nicht selbst ausdenke.
  • Buchhaltung ist nichts für mich, aber dafür habe ich meine Frau eingestellt, die Finanzbuchhalterin ist. Wir machen das mit Lexware.
  • Lexoffice haben wir uns auch angeschaut, aber das ist nur für „neue“ Freelancer gut, da die Altdatenübernahme nicht so gut geht.
  • Website, Profil verwalten, Visitenkarten usw. mache ich alles selbst, weil es mir auch Spaß macht.
  • Mein Logo habe ich damals erstellen lassen.
• Wie ist das Verhältnis zwischen Fachlichkeit und dem „Drumherum“?
  • 90% meiner Zeit gehen in die Kernarbeit, die verrechenbar ist. 5% brauche ich für das Drumherum. Und nochmal 5% für Fortbildungen.
• Wie hältst du dich technologisch auf dem neusten Stand?
  • Recherche im Internet (Fachartikel), Bücher, LinkedIn-Learning und Udemy
  • Austausch mit anderen Experten
  • Instagram, Podcast
  • Ich habe gerne auch mal ein dickes Buch in der Hand.
  • Früher habe ich oft Seminare besucht, aber 5 Tage kosten viel und man verdient nichts in der Zeit.
  • Heute läuft alles online. Und der Austausch vor Ort war eh meist nicht gegeben, da auch nur ein Schulungsprogramm abgespielt wird.
  • Zertifikate kann man auch gut online machen.
  • Aktuell: relationale Datenbanken entwickeln sich Richtung Cloud und wieder ist alles neu. NoSQL ist auch wichtig.
• Machst du auch Weiterbildungen in der jeweiligen Domäne?
  • Ja, das kann nötig sein.
  • Ich unterscheide drei Bereiche: Methodik, Technik, Fachlichkeit/Branche.
  • Methodenwissen wie Scrum „hält“ lange im Gegensatz zu Technologie(-Trends). Vor 5 Jahren haben wir noch alles mit WPF umgesetzt, heute macht das keiner mehr, sondern Angular, React etc.
  • Teilweise ist es auch unmöglich, bei jeder Technologie (z.B. Webentwicklung, Cloud, KI etc.) mitreden zu können und auf dem neuesten Stand der Technik (Trends) zu sein.
  • Branchenwissen ist auch sehr wichtig. Und allgemeine Sachen wie DSGVO, Regularien, Fachbegriffe.
• Wie läuft die Einarbeitung in ein neues Projekt ab?
  • Immer gleich: Interview, Dokumentenanalyse, System-Archäologie, Glossar, Recherche.
  • Man muss sich schnell einarbeiten können als Freelancer und muss direkt Gas geben, weil man sonst weg vom Fenster ist. Man gibt 100% von Anfang an.
  • Daher habe ich viel Erfahrung mit analytischem Denken und kann mich schnell einarbeiten.
  • Ich sammle Dokumente und liste sie in Excel auf. Was gibt es schon und was fehlt? Dann führe ich Interviews, um fehlende Daten zu finden.
  • Fachbegriffe muss ich auch mal im Netz recherchieren, z.B. in einer Bank Derivate, „Value at Risk“ etc.
• Wo liegt dein Fokus? Bist du Generalist oder Spezialist?
  • Ich bin Generalist, aber beides ist gut möglich als Freelancer.
  • Der Spezialist (z.B. Entwickler) hat vielleicht eher ein Gewerk und daher kurze Projekte, aber höheren Stundensatz und ist sehr gefragt.
  • Ein Generalist (z.B. Projektmanager und Business Analyst) wird eher weniger gesucht, weil man keinen bestimmten Fokus hat, der gezielt benötigt wird.
  • Nachteil beim Spezialisten (z.B. Entwickler): Konkurrenz mit Osteuropa/Indien, die sehr gut sind, doch geringere Stundensätze haben.
  • Entwickler liegen aktuell bei ca. 80 EUR, Berater bei 90 EUR, Projektleiter bei 100 EUR.
  • Hohe Stundensätze (>100 EUR) gibt es insb. für „Trend-Themen“ (z.B. Azure Cloud, Cyber Security, KI, etc.), wenn man dort Architekt ist (also konzipieren und umsetzen kann).
  • Ich bin IT-Berater. Kundenkontakt ist mir wichtig. Ich möchte gar nicht 8 Stunden am Tag programmieren.
  • Aber auch Berater sollten Technik „können“, damit sie auch mal was umsetzen können und nicht nur „schnacken“.
• Welche Tipps würdest du heutigem IT-Nachwuchs geben, wenn sie Freelancer werden wollen?
  • Vorher die Nachfrage überprüfen. Sich selbst überprüfen, ob man Manager, Macher und Verkäufer-Qualitäten hat.
  • Altersvorsorge ist grundsätzlich wichtig, egal ob Freelancer oder nicht.
  • Viele machen das inzwischen erstmal nebenberuflich und tasten sich langsam ran.
  • Man kann z.B. ein eBook schreiben oder das Thema bei Instagram/LinkedIn pushen.
  • Aber Technologie ist eh immer gefragt! Die Digitalisierung lässt grüßen.
  • Viele Unternehmen hängen auch heute noch auf Excel fest, da gibt es viele Möglichkeiten/Aufgaben für Freelancer.
  • Spannende Trends: KI, Cloud, Low Code, Process Intelligence, IoT, Smart Factory.
  • Da ist es gar nicht so einfach, den Überblick zu behalten und auf dem Laufenden zu bleiben. Es werden hohe Anforderungen an Freelancer gestellt und man schafft nicht alles.
• Würdest du nochmal zurück in die Festanstellung?
  • Ich bleibe Freelancer solange es geht und werde immer (natürlich im Rentenalter weniger) arbeiten. Sonst wird mir langweilig.
  • Vielleicht werde ich noch Dozent und gebe mein Wissen weiter. Oder ich schreibe Bücher.
  • Eigentlich bin ich als Freelancer zur Überbrückung gestartet und wollte danach Abteilungsleiter werden (von der Fachkraft zur Führungskraft), aber als IT-Freelancer hat man die Chance als Fachkraft wie eine Führungskraft (>100.000 EUR Brutto) zu verdienen.
  • Einige machen das auch so: bis Alter 50 als Freelancer arbeiten und dann zurück in die Festanstellung als gut verdienender Abteilungsleiter.
  • Vielleicht werde ich auch irgendwann „müde“, immer etwas Neues zu suchen. Dann werde ich vielleicht besser Senior/Partner.
  • Aber aktuell würde ich noch zu wenig verdienen als Festangestellter.

Aus- und Weiterbildung

• Was ist dein absolutes Lieblingsbuch mit Bezug zur IT/Programmierung und warum?
  • Basiswissen Requirements Engineering* von Klaus Pohl und Chris Rupp.
• Welche Quellen kannst du für die Aus- und Weiterbildung im Bereich IT empfehlen und warum?
  • LinkedIn-Learning und Udemy*
  • *

Abschluss

• Wo können die Hörer mehr über dich erfahren bzw. dich kontaktieren?
  • Website, Xing, LinkedIn, Instagram

Literaturempfehlungen

Christian empfiehlt Basiswissen Requirements Engineering* von Klaus Pohl und Chris Rupp zum Einstieg in die Thematik. Er holt es immer wieder gerne hervor und schlägt Dinge nach.

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Stundensatz berechnen: Was Gründer*innen wissen sollten

Um die Frage, wie oder woran du ein gutes bzw. schlechtes Ausbildungsunternehmen erkennst, geht es in der einhundertneunundsechzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Viele angehende Azubis fragen sich (und auch mich), woran sie erkennen, ob sie sich bei einem „guten“ Ausbildungsunternehmen bewerben. Und auch Azubis, die schon eine Ausbildungsstelle haben, sollten in den ersten Monaten der Ausbildung – also in der Probezeit – genau prüfen, ob sie wirklich in den nächsten drei Jahren in ihrem Unternehmen vernünftig ausgebildet werden. Worauf man dabei achten kann, erzähle ich heute im Podcast.

Vorweg: Meiner Erfahrung nach bildet der Großteil der Ausbildungsunternehmen vernünftig aus! Trotzdem gibt es auch immer wieder schwarze Schafe, die Azubis nicht ausbilden, sondern ausbeuten. Und darunter leiden dann nicht die Unternehmen, sondern die Azubis, die oft insb. bei der Prüfungsvobereitung alleine gelassen werden und dementsprechend schlechte Prüfungsergebnisse abliefern.

Die möglichen Anzeichen für eine schlechte Ausbildung auf der folgenden Liste sind erstmal nur Indizien! Wenn einzelne Dinge davon ab und an mal in deinem Unternehmen vorkommen, muss das nichts heißen. Unter gewissen Umständen sind sogar dauerhafte „Probleme“ tragbar, wenn drumherum alles andere passt. Urteile also bitte nicht vorschnell, nur weil du hier ein bestimmtes Stichwort gelesen hast!

Und zu einer Ausbildung gehören immer zwei Seiten! Auch du musst deinen Teil zu einer guten Ausbildung beitragen und kannst nicht erwarten, alles auf dem Silbertablett serviert zu bekommen. Schließlich sollst du nach der Ausbildung selbstständig handlungsfähig sein und deinen Job machen können.

Was kannst du tun, wenn du nicht richtig ausgebildet wirst?

• Suche das Gespräch mit deinem/deiner Ausbilder:in/Chef:in.
• Geh mit deinem Ausbildungsnachweis zur IHK (Ausbildungsberater:in).
• Wechsle den Ausbildungsbetrieb (ggfs. mit Hilfe der IHK).

Immer gilt: Suche bei Problemen in der Ausbildung immer zuerst das Gespräch mit deinem/deiner Ausbilder:in und nimm nicht „hinter ihrem Rücken“ Kontakt zur IHK auf. Vielleicht gibt es eine gute Erklärung für die aktuelle Situation und sie dauert nicht länger an. Und alle Menschen – auch du und ich – machen mal Fehler, also erwarte nicht die „perfekte“ Ausbildung. Das ist unrealistisch.

Formelle Anforderungen an Ausbildungsunternehmen und Ausbilder:innen

Ausbildende haben

1. dafür zu sorgen, dass den Auszubildenden die berufliche Handlungsfähigkeit vermittelt wird, die zum Erreichen des Ausbildungsziels erforderlich ist, und die Berufsausbildung in einer durch ihren Zweck gebotenen Form planmäßig, zeitlich und sachlich gegliedert so durchzuführen, dass das Ausbildungsziel in der vorgesehenen Ausbildungszeit erreicht werden kann,
2. selbst auszubilden oder einen Ausbilder oder eine Ausbilderin ausdrücklich damit zu beauftragen,
3. Auszubildenden kostenlos die Ausbildungsmittel, insbesondere Werkzeuge, Werkstoffe und Fachliteratur zur Verfügung zu stellen, die zur Berufsausbildung und zum Ablegen von Zwischen- und Abschlussprüfungen, auch soweit solche nach Beendigung des Berufsausbildungsverhältnisses stattfinden, erforderlich sind,
4. Auszubildende zum Besuch der Berufsschule anzuhalten,
5. dafür zu sorgen, dass Auszubildende charakterlich gefördert sowie sittlich und körperlich nicht gefährdet werden.

(BBiG, §14, Absatz 1)

Die Punkte 1 bis 3 sagen im Prinzip aus, dass du vernünftig ausgebildet werden musst. Du sollst nach der Ausbildung in der Lage sein, deinen Beruf selbstständig auszuüben. Diese Aufgabe kann dein Unternehmen auch nicht delegieren, sondern muss sich selbst darum kümmern. Außerdem muss dein Unternehmen dich auch finanziell unterstützen, wenn du Ausbildungsmittel (in der IT z.B. Fachbücher) benötigst.

Die Ausbildung in Deutschland heißt nicht umsonst duale Ausbildung, denn ein wichtiger Teil dabei ist die Berufsschule. Klar, dass du am Unterricht teilnehmen können musst, oder?

Der letzte Punkt überrascht dich vielleicht, ist aber auch eine wichtige Aufgabe des Ausbildungsunternehmens. Es gibt ja durchaus auch Azubis, die mit 16 oder 17 Jahren in die Ausbildung starten. Da kann man wohl noch nicht von einem „gefestigten Charakter“ sprechen. 😉

Als Ergänzung zu 2.:

Eine Ausbildungsstätte, in der die erforderlichen beruflichen Fertigkeiten, Kenntnisse und Fähigkeiten nicht im vollen Umfang vermittelt werden können, gilt als geeignet, wenn diese durch Ausbildungsmaßnahmen außerhalb der Ausbildungsstätte vermittelt werden.

BBiG, §27, Absatz 2

Ausbildende haben Auszubildende zum Führen der Ausbildungsnachweise nach § 13 Satz 2 Nummer 7 anzuhalten und diese regelmäßig durchzusehen. Den Auszubildenden ist Gelegenheit zu geben, den Ausbildungsnachweis am Arbeitsplatz zu führen.

BBiG, §14, Absatz 2

Das sollte für sich selbst sprechen.

Auszubildenden dürfen nur Aufgaben übertragen werden, die dem Ausbildungszweck dienen und ihren körperlichen Kräften angemessen sind.

BBiG, §14, Absatz 3

„Azubi-Aufgaben“ (Kaffee kochen, Spülmaschine ausräumen etc.) dürfen nicht die Regel sein.

Auszubildende dürfen nur eingestellt und ausgebildet werden, wenn die Zahl der Auszubildenden in einem angemessenen Verhältnis zur Zahl der Ausbildungsplätze oder zur Zahl der beschäftigten Fachkräfte steht, es sei denn, dass anderenfalls die Berufsausbildung nicht gefährdet wird.

BBiG, §27, Absatz 1, Satz 2

Mehr Azubis als Mitarbeiter:innen sind ein schlechtes Zeichen.

Auszubildende darf nur einstellen, wer persönlich geeignet ist. Auszubildende darf nur ausbilden, wer persönlich und fachlich geeignet ist.

BBiG, §28, Absatz 1

Ausbilder:innen haben eine wichtige Aufgabe, für die sie entsprechend qualifiziert sein müssen, z.B. weil sie selbst eine Ausbildung oder ein Hochschulstudium in diesem Beruf absolviert haben. Es werden auch bestimmte pädagogische Anforderungen gestellt. Diese werden durch eine Ausbildung nach AEVO erworben. Außerdem sollte der/die Ausbilder:in eine „angemessene Zeit“ im Beruf praktisch gearbeitet haben. Wenn der gerade fertige Azubi direkt zum/zur Ausbilder:in wird, ist das also etwas seltsam.

Fachlich geeignet ist, wer die beruflichen sowie die berufs- und arbeitspädagogischen Fertigkeiten, Kenntnisse und Fähigkeiten besitzt, die für die Vermittlung der Ausbildungsinhalte erforderlich sind.

BBiG, §30, Absatz 1

Prüfung bereits im Bewerbungsprozess

• Wird erwartet, dass ich Ausbildungsinhalte schon vor der Ausbildung kann?
• Gibt es einen betrieblichen Ausbildungsplan?
• Gibt es eine:n „richtige:n“ Ausbilder:in mit Ausbilderschein (AEVO)?
• Welche Prüfungsleistungen haben die bisherigen Azubis erreicht?
• Wurden die bisherigen Azubis übernommen?
• Liegt die Höhe der Azubivergütung (deutlich) über dem Mindestlohn?
• Wie werden in der Ausbildung Lernerfolgskontrollen durchgeführt?
• Wie läuft die Prüfungsvorbereitung im Unternehmen ab?
• Welche Azubi-Projekte wurden in den letzten Jahren durchgeführt?
• Hat das Unternehmen mehr Azubis als Mitarbeiter:innen?

Während der Probezeit

• Herrscht ein vernünftiger Umgangston?
• Kümmert sich jemand um mich?
• Mache ich viel „Fließbandarbeit“?
• Habe ich immer etwas zu tun oder viel „Leerlauf“?
• Habe ich Zeit zum Lernen während der Arbeitszeit?
• Kann ich Fragen stellen?
• Ist mein:e Ausbilder:in fachlich kompetent?
• Bekomme ich Feedback zu meiner Arbeit?
• Ist ein strukturierter Ablauf der Ausbildung zu erkennen?
• Werden meine Bücher etc. bezahlt?
• Muss ich nur „Azubi-Tätigkeiten“ (Kaffee kochen, Rasen mähen etc.) durchführen?
• Muss ich viele Überstunden machen?
• Muss ich zu seltsamen Zeiten oder sehr unregelmäßig arbeiten?
• Werde ich pünktlich bezahlt?
• Werde ich für die Berufsschule freigestellt?
• Muss ich vor/nach der Berufsschule noch ins Unternehmen kommen?
• Darf ich das Berichtsheft während der Arbeitszeit führen?
• Wird das Berichtsheft regelmäßig kontrolliert und abgezeichnet?
• Muss ich im Berichtsheft lügen?

Literaturempfehlungen

Die Umsetzungshilfen für den jeweiligen Ausbildungsberuf kann ich absolut empfehlen. Sie enthalten viele Praxistipps für Ausbilder:innen in der IT, damit die Ausbildung eben nicht zur Ausbeutung wird.

BIBB-Umsetzungshilfen Fachinformatiker/Fachinformatikerin (Ausbildung gestalten)*

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Berufsbildungsgesetz (BBiG)

Um die Prüfungsvorbereitung auf Teil 1 der gestreckten Abschlussprüfung (nach der Neuordnung der IT-Berufe 2020) geht es in der einhundertachtundsechzigsten Episode des IT-Berufe-Podcasts.

Inhalt Art der Prüfung

Teil 1 der gestreckten Abschlussprüfung der IT-Berufe ist eine schriftliche Prüfung von 90 Minuten zum Themenbereich „Einrichten eines IT-gestützten Arbeitsplatzes“. Diese Prüfung ist für alle IT-Berufe identisch, da die gemeinsamen Qualifikationen geprüft werden, die in den ersten 18 Monaten der Ausbildung vermittelt werden müssen. Zulassungsvoraussetzung ist u.a. das ordnungsgemäße Führen des Ausbildungsnachweises.

Gewichtung des Prüfungsergebnisses

Der erste Teil der gestreckten Abschlussprüfung zählt – anders als die ehemalige Zwischenprüfung – voll zur Abschlussnote. Und ihr Anteil liegt sogar bei 20%. Das heißt, ein Fünftel der Abschlussnote wird bereits durch diese Prüfung festgelegt. Daher sollte man – weder als Azubi noch als Ausbilder:in – diesen Prüfungsteil unterschätzen, sondern sich gut darauf vorbereiten.

Die Abschlussprüfung ist bestanden, wenn die Prüfungsleistungen – auch unter Berücksichtigung einer mündlichen Ergänzungsprüfung nach § 17 – wie folgt bewertet worden sind:

1. im Gesamtergebnis von Teil 1 und Teil 2 mit mindestens „ausreichend“,
2. im Ergebnis von Teil 2 mit mindestens „ausreichend“,
3. in mindestens drei Prüfungsbereichen von Teil 2 mit mindestens „ausreichend“ und
4. in keinem Prüfungsbereich von Teil 2 mit „ungenügend“.

(FIAusbV, §16, Absatz 2)

Demnach kann man seinen Abschluss auch schaffen, wenn man in Teil 1 der Prüfung durchfällt, da lediglich das Gesamtergebnis „ausreichend“ sein muss und man eine schlechte Note in Teil 1 mit einer guten in Teil 2 „ausgleichen“ kann. Trotzdem ist schon ab einem Ergebnis von 55% oder schlechter in Teil 1 rein rechnerisch keine „sehr gute“ Gesamtnote mehr möglich! Rechne es dir gerne selbst nach: Notenrechner für die neue IT-Abschlussprüfung.

Allgemeine Prüfungsinhalte von Teil 1

Aufgrund der Wichtigkeit der Prüfung für die Abschlussnote empfehle ich, so früh wie möglich mit der Prüfungsvorbereitung anzufangen. Leider sind die Inhalte von Teil 1 aber wenig fachspezifisch und/oder technisch, sondern eher „allgemeiner“ Natur (z.B. Projektmanagement, Abrechnungen, Angebotsvergleich, Schulungen, Präsentationen, Datenschutz). Ein wenig Technik wird eigentlich nur durch die Grundlagen der Programmierung integriert. Insbesondere – meiner Meinung nach – grundlegende IT-Themen wie Netzwerke, VPN, RAID oder Backups sollen zwar laut Ausbildungsrahmenplan bereits im 1. Ausbildungsjahr vermittelt werden, sind aber nicht prüfungsrelevant. Nur die ersten sieben Absätze der „Fertigkeiten, Kenntnisse und Fähigkeiten der Berufsbildpositionen“ werden in Teil 1 der Prüfung abgefragt.

Teil 1 findet im vierten Ausbildungshalbjahr statt, Teil 2 am Ende der Berufsausbildung.

(FIAusbV, §7, Absatz 2)

Das heißt, dass die IT-Azubis den ersten Teil ihrer Ausbildung fast gar nicht mit den vermutlich für sie spannenderen Themen ihres Berufs oder ihrer Fachrichtung verbringen (z.B. Netzwerke beim FISI oder Machine Learning beim FIDP), was zu Frustration führen könnte. Ein:e Anwendungsentwickler:in, der/die im ersten Ausbildungsjahr nur Angebote einholt (überspitzt dargestellt), hat sich das sicherlich anders vorgestellt (kein Coooooode!). Und als Ausbilder:in bekommt man auch erst spät eine Einschätzung über die Eignung der Azubis für die eigentlich Kernthemen des Berufs. Daher schlage ich vor, zu Beginn der Ausbildung die Probezeit für diese Kernthemen zu nutzen und erst danach mit der parallelen Vermittlung der unten genannten Inhalte zu beginnen. Dann haben die Azubis noch gut ein Jahr Zeit, sich auf die Prüfung vorzubereiten und lernen trotzdem schon die für sie interessanten Inhalte des Berufs (z.B. Programmieren oder Netzwerkadministration).

Strategie zur Vorbereitung

Meine empfohlende Vorgehensweise zur Prüfungsvorbereitung auf Teil 1 der gestreckten Abschlussprüfung sieht wie folgt aus.

• Alte Prüfungen durchgehen!
  • Solange es noch keine bzw. wenige alte Prüfungen gibt (bis ca. 2023) mit alten IHK-Abschlussprüfungen und Zwischenprüfungen lernen.
  • Dabei insbesondere die Aufgaben bearbeiten, die den Inhalten der neuen Prüfung zuzuordnen sind.
  • Die erste Prüfung Teil 1 wird im Herbst 2021 stattfinden (für Verkürzer).
• Echte Projekte in der Praxis umsetzen und dabei die genannten Methodiken anwenden.
  • Die Reihenfolge und zeitliche Durchführung hängt vom gewählten Beruf und dem Unternehmen ab. Hier gibt es keine allgemeingültige Empfehlung oder Vorgabe.
• Mit Hilfe von (Schul-)Büchern und Beispielaufgaben gezielt Inhalte vertiefen, die vielleicht nicht in der Praxis vermittelt werden (können).
  • Für die Prüfungsinhalte von Teil 1 sind inzwischen einige (gute) Bücher verfügbar und auch einige „Standardwerke“ können in Teilen integriert werden.
• Regelmäßig üben (mit Feedback durch Ausbilder:in) und kein „Bulimie-Lernen“ kurz vor der Prüfung.
  • Azubis und Ausbilder:innen müssen sich diese Zeit auch reservieren (z.B. 2 von 5 Tagen Lernen/Prüfen, Rest Praxis).

Konkrete Prüfungsinhalte von Teil 1

Die Paragraphen, die für Teil 1 der gestreckten Abschlussprüfung relevant sind, können jeder Berufsverordnung der neuen IT-Berufe entnommen werden, da sie für alle IT-Berufe identisch sind. Beispiel: FIAusbV: Verordnung über die Berufsausbildung zum Fachinformatiker und zur Fachinformatikerin.

Teil 1 der Abschlussprüfung erstreckt sich auf

1. die im Ausbildungsrahmenplan für die ersten 18 Monate genannten Fertigkeiten, Kenntnisse und Fähigkeiten der Berufsbildpositionen nach § 4 Absatz 2 Nummer 1 bis 7 sowie
2. den im Berufsschulunterricht zu vermittelnden Lehrstoff, soweit er den im Ausbildungsrahmenplan genannten Fertigkeiten, Kenntnissen und Fähigkeiten entspricht.

(FIAusbV, §8)

Zusammengefasst ergeben sich folgende Prüfungsbereiche.

Im Prüfungsbereich Einrichten eines IT-gestützten Arbeitsplatzes hat der Prüfling nachzuweisen, dass er in der Lage ist,

1. Kundenbedarfe zielgruppengerecht zu ermitteln,
2. Hard- und Software auszuwählen und ihre Beschaffung einzuleiten,
3. einen IT-Arbeitsplatz zu konfigurieren und zu testen und dabei die Bestimmungen und die betrieblichen Vorgaben zum Datenschutz, zur IT-Sicherheit und zur Qualitätssicherung einzuhalten,
4. Kunden und Kundinnen in die Nutzung des Arbeitsplatzes einzuweisen und
5. die Leistungserbringung zu kontrollieren und zu protokollieren.

(FIAusbV, §9, Absatz 2)

Die den relativ allgemein und eher abstrakt gehaltenen Paragraphen zugeordneten konkreten Inhalte der folgenden Liste stammen aus den Umsetzungshilfen für Fachinformatiker/Fachinformatikerin des BIBB*. Die Lektüre der Umsetzungshilfen kann ich allen IT-Ausbilder:innen unbedingt empfehlen!

*

1 Planen, Vorbereiten und Durchführen von Arbeitsaufgaben in Abstimmung mit den kundenspezifischen Geschäfts- und Leistungsprozessen

Mein Vorschlag: Konkretes Projekt „von vorne bis hinten“ umsetzen und parallel die genannten Methoden anwenden.

1a: Grundsätze und Methoden des Projektmanagements anwenden

• Initiieren, Planen, Steuern, Kontrollieren und Abschließen von Projekten nach aktuell gängigen Projektmanagementstandards
• Anwendung von Methoden, Hilfsmitteln, Techniken und Kompetenzen in einem Projekt, z.B.:
  • Projektplan
  • Meilensteine
  • Risikoanalyse
  • Standards und Normen
  • Projektmanagementsysteme
• Basiskenntnisse des Veränderungsmanagements
• Unterscheiden verschiedener Projektmanagementmethoden und Vorgehensmodelle, z.B.:
  • agiles Projektmanagement
  • V-Modell
  • Spiralmodell
  • Wasserfallmodell

Konkrete Literaturempfehlungen

• Prüfungsvorbereitung aktuell Kapitel 2.1
• Grundstufe Lernfelder 1-5 Kapitel 5.3
• IT-Handbuch Kapitel 8
• IT-Handbuch für Fachinformatiker:innen Kapitel 11 (Software-Engineering)

1b: Auftragsunterlagen und Durchführbarkeit des Auftrags prüfen, insbesondere in Hinblick auf rechtliche, wirtschaftliche und terminliche Vorgaben, und den Auftrag mit den betrieblichen Prozessen und Möglichkeiten abstimmen

• Beachten der Voraussetzungen im eigenen Arbeitsumfeld
• Definieren von Aufgaben, Rollen und Verantwortlichkeiten für alle Projektbeteiligten, z.B.:
  • Projekt-Auftraggeber
  • Projektleiter
  • Projekt-Steuerkreis
  • Projektmitarbeiter

Konkrete Literaturempfehlungen

• Grundstufe Lernfelder 1-5 Kapitel 1.3
• IT-Handbuch Kapitel 8
• IT-Handbuch für Fachinformatiker:innen Kapitel 11 (Software-Engineering)

1c: Zeitplan und Reihenfolge der Arbeitsschritte für den eigenen Arbeitsbereich festlegen

• Definieren und Festlegen von Arbeitspaketen und Abhängigkeiten
• Erleichterung der Planung und der Fortschrittskontrolle durch Aufteilung des Arbeits- bzw. Projektverlaufs in überprüfbare Etappen mit Zwischenzielen
• Umsetzung der Arbeitspakete in konkrete Handlungen und Messen anhand von Prüfkriterien
• ggf. Ableiten einer Prognose für den weiteren Fortschritt bzw. den Endtermin

Konkrete Literaturempfehlungen

• Grundstufe Lernfelder 1-5 Kapitel 2.5
• IT-Handbuch Kapitel 2

1d: Termine planen und abstimmen sowie Terminüberwachung durchführen

• Nutzung verschiedener Projektmanagementsysteme
• Erstellung von Projektstrukturplänen zur Gliederung von Projekten in plan- und kontrollierbare Elemente
• vollständige Erfassung aller relevanten Tätigkeiten eines Projektes (funktionsorientierte, objektorientierte oder zeitorientierte Gliederung) im Top-down-, Bottom-up- oder Yo-Yo-Ansatz
• Visualisierung, z.B.:
  • Netzplantechnik
  • Scrum Board
  • Kanban Board
  • Gantt-Diagramme

Konkrete Literaturempfehlungen

• Grundstufe Lernfelder 1-5 Kapitel 2.5
• IT-Handbuch Kapitel 2
• IT-Handbuch Kapitel 6
• IT-Handbuch für Fachinformatiker:innen Kapitel 11 (Software-Engineering)

1e: Probleme analysieren und als Aufgabe definieren sowie Lösungsalternativen entwickeln und beurteilen

• Analysieren im Sinne von Erkennen und Einordnen
• Problemlösungsvarianten entwickeln
• Probleme beseitigen durch, z.B.:
  • Situationsanalyse
  • Problemeingrenzung
  • Aufzeigen von Alternativen
  • Auswahl von Lösungen
  • Analysieren der Chancen und Risiken der ausgewählten Lösung anhand vorher definierter Beurteilungskriterien

Konkrete Literaturempfehlungen

• IT-Handbuch Kapitel 3

1f: Arbeits- und Organisationsmittel wirtschaftlich und ökologisch unter Berücksichtigung der vorhandenen Ressourcen und der Budgetvorgaben einsetzen

• Berücksichtigung der Formen von Arbeitsorganisation, z.B.:
  • Gruppenarbeit
  • Pair Programming
• Budgetplanung als Teil der Unternehmensplanung
• effektiver und effizienter Einsatz von Arbeits- und Organisationsmitteln
• Prüfung des Ressourceneinsatzes auf:
  • rechtliche Zulässigkeit
  • technische und organisatorische Machbarkeit
  • ökologische Nachhaltigkeit und Wirtschaftlichkeit
• Prüfung der Wirtschaftlichkeit mittels betriebswirtschaftlicher Methoden, z.B.:
  • Rentabilitätsrechnung
  • Amortisationsrechnung

Konkrete Literaturempfehlungen

• Grundstufe Lernfelder 1-5 Kapitel 1.3
• Grundstufe Lernfelder 1-5 Kapitel 2.3
• Grundstufe Lernfelder 1-5 Kapitel 2.4
• IT-Handbuch Kapitel 1
• IT-Handbuch Kapitel 3
• IT-Handbuch Kapitel 10

1g: Aufgaben im Team sowie mit internen und externen Kunden und Kundinnen planen und abstimmen

• Team als soziales Gefüge verstehen („social awareness“)
• Phasen der Teamentwicklung kennen und anwenden (Konflikt, Kontrakt, Kooperation)
• Methoden des sachbezogenen Verhandelns kennen und anwenden, z.B.:
  • Win-win-Strategie
  • Harvard-Konzept
• adressatengerechte Kommunikation

Konkrete Literaturempfehlungen

• Grundstufe Lernfelder 1-5 Kapitel 1.5
• IT-Handbuch Kapitel 8

1h: betriebswirtschaftlich relevante Daten erheben und bewerten und dabei Geschäfts- und Leistungsprozesse berücksichtigen

• Bewerten anhand vorgegebener unternehmensspezifischer Daten

Konkrete Literaturempfehlungen

• Grundstufe Lernfelder 1-5 Kapitel 1.3
• IT-Handbuch Kapitel 1
• IT-Handbuch Kapitel 2

1i: eigene Vorgehensweise sowie die Aufgabendurchführung im Team reflektieren und bei der Verbesserung der Arbeitsprozesse mitwirken

• gemeinsame kritische Analyse der bisherigen Zusammenarbeit und der Ergebnisse („lessons learnt“)
• offenes Ansprechen von Erfolgen und Problemen
• gemeinsame Entwicklung von Maßnahmen zur Verbesserung, z.B. SCRUM-Retrospektive
• konstruktive Kritik

Konkrete Literaturempfehlungen

• Grundstufe Lernfelder 1-5 Kapitel 5.9
• IT-Handbuch Kapitel 2
• IT-Handbuch für Fachinformatiker:innen Kapitel 11 (Software-Engineering)

2 Informieren und Beraten von Kunden und Kundinnen

Mein Vorschlag: Beschaffungsprozess anhand eines echten Beispiels durchlaufen und parallel die genannten Methoden anwenden.

2a: im Rahmen der Marktbeobachtung Preise, Leistungen und Konditionen von Wettbewerbern vergleichen

• Primär- und Sekundärforschung
• Unterscheiden und Nutzen von Erhebungsmethoden, z.B.:
  • Benchmark
  • Befragungen
  • Data Mining
• Marktbeobachtung und Marktanalyse mit Marktdaten als Grundlage, z.B.:
  • Preisentwicklungen
  • Struktur der Anbieter
  • Produktqualitäten

Konkrete Literaturempfehlungen

• Grundstufe Lernfelder 1-5 Kapitel 1.4
• IT-Handbuch Kapitel 9

2b: Bedarfe von Kunden und Kundinnen feststellen sowie Zielgruppen unterscheiden

• Feststellung des Bedarfs an Waren, Dienstleistungen oder Personal in einer bestimmten Region, einer bestimmten Personengruppe oder in einem bestimmten Zeitraum, z.B.:
  • Zielgruppendefinitionen
  • Kundentypologien
  • Konsumverhalten

Konkrete Literaturempfehlungen

• Grundstufe Lernfelder 1-5 Kapitel 2.5
• Grundstufe Lernfelder 1-5 Kapitel 2.6
• IT-Handbuch Kapitel 9

2c: Kunden und Kundinnen unter Beachtung von Kommunikationsregeln informieren sowie Sachverhalte präsentieren und dabei deutsche und englische Fachbegriffe anwenden

• Argumentations- und Präsentationstechniken
• zielgruppengerechte und lösungsorientierte Vorstellung von Produkten und Ergebnissen

Konkrete Literaturempfehlungen

• Grundstufe Lernfelder 1-5 Kapitel 1.5
• Grundstufe Lernfelder 1-5 Kapitel 2.2
• IT-Handbuch Kapitel 3

2d: Maßnahmen für Marketing und Vertrieb unterstützen

• Stärken-Schwächen-Analyse (SWOT etc.)
• Begleiten von IT-Vertriebsprozessen
• Motive und Werte der Kunden

Konkrete Literaturempfehlungen

• Grundstufe Lernfelder 1-5 Kapitel 2.5
• IT-Handbuch Kapitel 9

2e: Informationsquellen auch in englischer Sprache aufgabenbezogen auswerten und für die Kundeninformation nutzen

• unterschiedliche Quellen nutzen und bewerten, z.B.:
  • Internet und Intranet
  • Fachliteratur
  • technische Dokumentationen
• kombinierte Suchabfragen unter Verwendung von Suchoperatoren
• Berücksichtigung der geltenden Compliance-Regelungen, Ethik

Konkrete Literaturempfehlungen

• IT-Handbuch Kapitel 3

3 Beurteilen marktgängiger IT-Systeme und kundenspezifischer Lösungen

Mein Vorschlag: Parallel mit 2) Beschaffungsprozess anhand eines echten Beispiels durchlaufen und die genannten Methoden anwenden.

3a: marktgängige IT-Systeme für unterschiedliche Einsatzbereiche hinsichtlich Leistungsfähigkeit, Wirtschaftlichkeit und Barrierefreiheit beurteilen

• IT-Systeme anhand ihres wirtschaftlichen Nutzens zum Unternehmenserfolg bewerten
• Gegenüberstellen von Kosten-Nutzen
• technische Leistungskriterien verschiedener IT-Systeme vergleichen und bewerten
• intuitive Bedienung
• barrierefreier Zugriff auf IT-Systeme, z.B.:
  • einfache Sprache
  • Braille
  • Spracheingabe- und -ausgabe

Konkrete Literaturempfehlungen

• Prüfungsvorbereitung aktuell Kapitel 2.5
• Prüfungsvorbereitung aktuell Kapitel 2.7
• Grundstufe Lernfelder 1-5 Kapitel 2.3
• Grundstufe Lernfelder 1-5 Kapitel 2.4
• IT-Handbuch Kapitel 5
• IT-Handbuch Kapitel 6
• IT-Handbuch Kapitel 7
• IT-Handbuch für Fachinformatiker:innen Kapitel 4 (Hardware)
• IT-Handbuch für Fachinformatiker:innen Kapitel 5 (Netzwerkgrundlagen)
• IT-Handbuch für Fachinformatiker:innen Kapitel 6 (Betriebssysteme)

3b: Angebote zu IT-Komponenten, IT-Produkten und IT-Dienstleistungen einholen und bewerten sowie Spezifikationen und Konditionen vergleichen

• Angebotsvergleiche, z.B. quantitative und qualitative Vergleiche
• Gegenüberstellung Eigenfertigung oder Fremdbezug (Make or buy)
• partieller/gewichteter Preisvergleich
• Ausschreibung von Leistungen
• Beschreibung von Leistungen, z.B.:
  • Pflichten- und Lastenheft
  • Leistungsverzeichnis
• Einholung bzw. Bewertung von Angeboten
• aus den Angeboten verschiedener Lieferanten das am besten geeignete Angebot identifizieren, z.B. mithilfe der Nutzwertanalyse

Konkrete Literaturempfehlungen

• Prüfungsvorbereitung aktuell Kapitel 2.8
• Grundstufe Lernfelder 1-5 Kapitel 2.7
• Grundstufe Lernfelder 1-5 Kapitel 2.8
• Grundstufe Lernfelder 1-5 Kapitel 2.9
• Grundstufe Lernfelder 1-5 Kapitel 5.1
• IT-Handbuch Kapitel 8
• IT-Handbuch Kapitel 9
• IT-Handbuch für Fachinformatiker:innen Kapitel 11 (Software-Engineering)

4 Entwickeln, Erstellen und Betreuen von IT-Lösungen

Mein Vorschlag: Konkretes (Programmier-)Projekt umsetzen und parallel die zusätzlichen Inhalte erarbeiten.

4a: IT-Systeme zur Bearbeitung betrieblicher Fachaufgaben analysieren sowie unter Beachtung insbesondere von Lizenzmodellen, Urheberrechten und Barrierefreiheit konzeptionieren, konfigurieren, testen und dokumentieren

• Potenziale von IT-Systemen bzw. einem Verbund verschiedener Arten erkennen
• Bestimmungen der Barrierefreiheit bei der Auswahl sowie der Einrichtung moderner Informations- und Kommunikationstechnik (Hard- und Software) berücksichtigen
• Basiswissen IT-Servicemanagement und darin verwendeter Methoden und Verfahren, z.B.:
  • ITIL
  • CobiT
  • MOF
  • ISO 20000
• Bestimmungen zur IT-Sicherheit (IT-Security) bei allen eingesetzten Hardware- und Softwaresystemen bzw. Infrastrukturen für eine Sicherheit der Informationsverarbeitung und auch der Kommunikation (Daten- bzw. Informationssicherheit) kennen und einhalten

Konkrete Literaturempfehlungen

• Grundstufe Lernfelder 1-5 Kapitel 2.4
• Grundstufe Lernfelder 1-5 Kapitel 3.2
• Grundstufe Lernfelder 1-5 Kapitel 3.4
• Grundstufe Lernfelder 1-5 Kapitel 3.8
• IT-Handbuch Kapitel 8

4b: Programmiersprachen, insbesondere prozedurale und objektorientierte Programmiersprachen, unterscheiden

• Vor- und Nachteile verschiedener Programmierparadigmen kennen und Programmiersprachen nach Sprachhöhe unterscheiden
• Identifikation und Auswahl einer für das jeweilige „Realweltproblem“ passenden Sprache
• Basiswissen Softwarelogik und grundlegende Programmelemente, z.B.:
  • Darstellungsformen für Programmabläufe
  • Aussagenlogik
  • Programmstrukturen
  • Datenstrukturen
  • Algorithmen
  • Objekte
  • Klassen
  • Variablen
  • Zuweisungen
  • Bedingungen/Verzweigungen
  • Schleifen

Konkrete Literaturempfehlungen

• Prüfungsvorbereitung aktuell Kapitel 2.6
• Grundstufe Lernfelder 1-5 Kapitel 5.2
• Grundstufe Lernfelder 1-5 Kapitel 5.3
• Grundstufe Lernfelder 1-5 Kapitel 5.5
• IT-Handbuch Kapitel 6
• IT-Handbuch für Fachinformatiker:innen Kapitel 2 (Mathematische Grundlagen)
• IT-Handbuch für Fachinformatiker:innen Kapitel 3 (Elektronische und technische Grundlagen)
• IT-Handbuch für Fachinformatiker:innen Kapitel 7 (Grundlagen der Programmierung)
• IT-Handbuch für Fachinformatiker:innen Kapitel 8 (Algorithmen und Datenstrukturen)
• IT-Handbuch für Fachinformatiker:innen Kapitel 9 (Weitere Konzepte der Programmierung)

5 Durchführen und Dokumentieren von qualitätssichernden Maßnahmen

Mein Vorschlag: Begleitend zu den obigen Projekten miteinfließen lassen.

5a: betriebliche Qualitätssicherungssysteme im eigenen Arbeitsbereich anwenden und Qualitätssicherungsmaßnahmen projektbegleitend durchführen und dokumentieren

• Nutzen der QS-Systeme im betriebseigenen Umfeld steht hier im Vordergrund
• an der ständigen Verbesserung des betriebseigenen QS-Systems mitarbeiten
• Modelle und Standards einordnen, z.B.:
  • EFQM
  • QS-Normen ISO 9000-9004
  • Six Sigma
• Verbesserung der Prozessqualität, der Arbeitsqualität und damit der Produktund Dienstleistungsqualität (Stichwort: prozessorientiertes QM-System)
• vorrangiges Ziel ist die Sicherstellung der vorgegebenen Qualität, ein höherwertiges Ergebnis ist nicht das primäre Ziel

Konkrete Literaturempfehlungen

• Prüfungsvorbereitung aktuell Kapitel 2.2
• Grundstufe Lernfelder 1-5 Kapitel 1.3
• IT-Handbuch Kapitel 8
• IT-Handbuch für Fachinformatiker:innen Kapitel 11 (Software-Engineering)

6 Umsetzen, Integrieren und Prüfen von Maßnahmen zur IT-Sicherheit und zum Datenschutz

Mein Vorschlag: Dieser Block lässt sich gut eigentständig lernen, aber auch parallel in die Praxis der Projekte integrieren.

6a: betriebliche Vorgaben und rechtliche Regelungen zur IT-Sicherheit und zum Datenschutz einhalten

• Nutzen und stetes Anwenden der betriebseigenen Regelungen zur IT-Sicherheit und für den Datenschutz
• Anwenden des organisationsinternen Prozesses zur Gewährleistung der IT-Sicherheit und des Datenschutzes (IT-Sicherheitsmanagement)
• normierte Vorgehensweise
• Verwendung von Standards

Konkrete Literaturempfehlungen

• Prüfungsvorbereitung aktuell Kapitel 2.3
• Grundstufe Lernfelder 1-5 Kapitel 2.3
• Grundstufe Lernfelder 1-5 Kapitel 4.1
• Grundstufe Lernfelder 1-5 Kapitel 4.2
• Grundstufe Lernfelder 1-5 Kapitel 4.3
• Grundstufe Lernfelder 1-5 Kapitel 5.2
• IT-Handbuch Kapitel 8
• IT-Handbuch für Fachinformatiker:innen Kapitel 21 (Computer- und Netzwerksicherheit)

6b: Sicherheitsanforderungen von IT-Systemen analysieren und Maßnahmen zur IT-Sicherheit ableiten, abstimmen, umsetzen und evaluieren

• Anwenden aktueller Standards, z.B.:
  • ISO 27001
  • ISO 27002
• Anwenden von Vorschriften, z.B.:
  • BDSG
  • Basel II und III
  • SOX
  • DSGVO
• Anwenden von Evaluierungstechniken zur IT-Sicherheit (IT-Grundschutz-Handbuch)
• Verhindern oder Abwehr von Gefahren für die Informationssicherheit oder Bedrohungen des Datenschutzes, z.B. durch Etablierung eines IT-Sicherheitsmanagements (ISMS) unter Verwendung von Standards wie IT-Grundschutz, ISO/IEC 27001
• Identifizieren und Umsetzen von Sicherheitsmaßnahmen
• Erreichen eines mittleren, angemessenen und ausreichenden Schutzniveaus für IT-Systeme durch technische Sicherheitsmaßnahmen und infrastrukturelle, organisatorische und personelle Schutzmaßnahmen

Konkrete Literaturempfehlungen

• Prüfungsvorbereitung aktuell Kapitel 2.3
• Grundstufe Lernfelder 1-5 Kapitel 2.3
• Grundstufe Lernfelder 1-5 Kapitel 4.1
• Grundstufe Lernfelder 1-5 Kapitel 4.2
• Grundstufe Lernfelder 1-5 Kapitel 4.3
• Grundstufe Lernfelder 1-5 Kapitel 4.4
• Grundstufe Lernfelder 1-5 Kapitel 5.2
• IT-Handbuch Kapitel 8
• IT-Handbuch für Fachinformatiker:innen Kapitel 21 (Computer- und Netzwerksicherheit)

7 Erbringen der Leistungen und Auftragsabschluss

Mein Vorschlag: Diese Punkte sollten mit abgedeckt werden, wenn obige Projekte (erfolgreich) umgesetzt und übergeben werden.

7a: Leistungen nach betrieblichen und vertraglichen Vorgaben dokumentieren

• Abstimmen der zu erwartenden Ergebnisse hinsichtlich betrieblicher und vertraglicher Rahmenbedingungen mit dem Auftraggeber
• Dokumentation der Vereinbarung, z.B. mittels Pflichtenheft oder Anforderungskatalog
• Dokumentation von Arbeits- und Projektzeiten (aktuell, flächendeckend und realistisch)
• Zeiterfassung als Bestandteil des Projektmanagements und Controllings
• Personaleinsatzplanung auf Basis der Arbeits- und Projektzeiterfassung

Konkrete Literaturempfehlungen

• Grundstufe Lernfelder 1-5 Kapitel 2.5
• Grundstufe Lernfelder 1-5 Kapitel 2.6
• Grundstufe Lernfelder 1-5 Kapitel 2.7
• Grundstufe Lernfelder 1-5 Kapitel 5.4
• IT-Handbuch Kapitel 3
• IT-Handbuch Kapitel 8

7b: Leistungserbringung unter Berücksichtigung der organisatorischen und terminlichen Vorgaben mit Kunden und Kundinnen abstimmen und kontrollieren

• Abstimmen der dokumentierten Vorgaben zur Leistungserbringung während des gesamten Zeitraums mit dem Auftraggeber
• kontinuierliche Prüfung der erfolgreichen Umsetzung und Ergebnisse sowie der zeitlichen Einhaltung
• ggf. Berücksichtigung der Stilllegung von Altsystemen und Inbetriebnahme der neuen Systeme
• Aufbewahrung von Archivdaten
• vollständige Dokumentation der erbrachten Leistung

Konkrete Literaturempfehlungen

• Grundstufe Lernfelder 1-5 Kapitel 2.10
• IT-Handbuch Kapitel 8

7c: Veränderungsprozesse begleiten und unterstützen

• motivierte Herangehensweise und Betonung der Chancen
• Anreichern mit eigenem Know-how
• Voranbringen schnell und in geeigneter Weise unterstützen
• Fragen beantworten, informieren und zuhören
• Darstellung der Veränderungsschritte, z.B. anhand der sieben Phasen eines Change-Prozesses

Konkrete Literaturempfehlungen

• IT-Handbuch Kapitel 2
• IT-Handbuch Kapitel 8

7d: Kunden und Kundinnen in die Nutzung von Produkten und Dienstleistungen einweisen

• Unterstützung bei der Umsetzung von Schulungsangeboten
• Durchführung von Einführungsveranstaltungen (auch begleitende Unterstützung vor Ort)
• Hervorhebung der Vorteile und Nutzen-Argumentation
• zielorientierte Vorgehensweise

Konkrete Literaturempfehlungen

• Grundstufe Lernfelder 1-5 Kapitel 2.1

7e: Leistungen und Dokumentationen an Kunden und Kundinnen übergeben sowie Abnahmeprotokolle anfertigen

• vor der Abnahme: Prüfung der Funktionsfähigkeit sowie Installation und Personalschulung
• Abnahmeprotokoll mit Angaben zu Vollständigkeit, Funktionseignung und Schadensfreiheit des geprüften Werks erstellen
• zusätzlich Aufnahme nicht geprüfter Abnahmekriterien
• nötige Unterlagen zur Einführung und Umsetzung der Ergebnisse bereitstellen und übergeben, z.B.:
  • Planungsunterlagen
  • Angaben zu genutzten Systemen und Daten
• Bedeutung und Moment der Abnahme verdeutlichen
• Abgleich mit der Sollspezifikation durchführen und protokollieren

Konkrete Literaturempfehlungen

• Grundstufe Lernfelder 1-5 Kapitel 2.10
• IT-Handbuch Kapitel 8

7f: Kosten für erbrachte Leistungen erfassen sowie im Zeitvergleich und im Soll-Ist-Vergleich bewerten

• Dokumentation der angefallenen Kosten anhand einer Kostenaufstellung und der wirtschaftlichen Leistungserbringung erstellen
• Bewerten und Dokumentieren der erbrachten Leistungen anhand der anfänglichen Abstimmung der betrieblichen und vertraglichen Vereinbarungen
• Erfüllen oder Abweichen von der Vereinbarung dokumentieren
• erbrachte Leistungen bestätigen lassen

Konkrete Literaturempfehlungen

• Grundstufe Lernfelder 1-5 Kapitel 2.8
• IT-Handbuch Kapitel 8

Literaturempfehlungen

In meinem IT-Berufe-Newsletter begleite ich dich ab dem ersten Ausbildungsjahr bei der Prüfungsvorbereitung und intensiviere diese im zweiten Ausbildungsjahr passend zum Prüfungstermin. Wenn du dabei sein möchtest, melde dich einfach unverbindlich an. Du bekommst dann passend zu deinem aktuellen Ausbildungsstand Mails von mir mit Hinweisen zur Vorbereitung auf Prüfungsthemen oder konkreten Tipps für die Integration in deinen Ausbildungsalltag.

Der „offizielle“ Prüfungskatalog enthält eine Liste der für Teil 1 der gestreckten Abschlussprüfung verbindlichen Inhalte. Ehrlich gesagt kann man diese Inhalte aber auch einfach der eigenen Berufsverordnung entnehmen.

Fachinformatiker/-in – Anwendungsentwicklung Prüfungskatalog für die IHK-Abschlussprüfung NEUORDNUNG

Wie schon erwähnt kann ich die Umsetzungshilfen für den jeweiligen Ausbildungsberuf absolut empfehlen. Hier werden konkrete Inhalte und Themen benannt zu den allgemeinen Paragraphen der zu vermittelnden Inhalte. Außerdem enthalten sie noch viele Praxistipps für Ausbilder:innen in der IT.

BIBB-Umsetzungshilfen Fachinformatiker/Fachinformatikerin (Ausbildung gestalten)*

*

Das passende Schulbuch zum ersten Teil der IT-Ausbildung. Hier werden die Inhalte des Rahmenlehrplans vermittelt (Achtung: das ist nicht der Ausbildungsrahmenplan!), also die Berufsschulinhalte. Viele Inhalte kann man aber 1-zu-1 auf die im Unternehmen zu vermittelnden Themen übertragen und sie sind auch sehr gut erklärt (ist ja auch ein Schulbuch).

IT-Berufe: Grundstufe Lernfelder 1-5: Schülerband*

*

Zum obigen Lehrwerk passend gibt es noch ein Arbeitsbuch mit praktischen Aufgaben. Die Lösungen bekommt man nur als Ausbilder:in nach einer Registrierung direkt beim Westermann-Verlag.

IT-Berufe: Lernsituationen Grundstufe Lernfelder 1-5: Arbeitsbuch*

*

Ein Übungsbuch zur Prüfungsvorbereitung, das viele der benötigten Themen abdeckt. Es ist eher ein Übungsbuch und weniger ein Lehrwerk, da hauptsächlich Aufgaben und ihre Lösungen enthalten sind, aber keine Herleitungen oder großartige Erklärungen. Solange es noch nicht viele „echte“ Prüfungen gibt, kann man damit aber erstmal gut arbeiten.

Prüfungsvorbereitung aktuell Teil 1 der gestreckten Abschlussprüfung: Einrichtung eines IT-gestützten Arbeitsplatzes*

*

Das gute alte IT-Handbuch ist meine Standardempfehlung als „Nachschlagewerk“. Kurz und knapp, aber immer korrekt und bezogen auf die Anforderungen der IHK-Prüfung. Hier sollen meine Azubis als erstes recherchieren, wenn sie sich in ein Thema einarbeiten, anstatt z.B. Internetquellen zu nutzen, deren Korrektheit sie oft (noch) nicht bewerten können.

IT-Handbuch: IT-Systemelektroniker/-in, Fachinformatiker/-in: Schülerband*

*

Und zu guter Letzt gibt es natürlich noch meine absolute Leseempfehlung für alle IT-Azubis: das IT-Handbuch für Fachinformatiker:innen. Hier sind zwar nur die technischen Inhalte enthalten, aber einige Kapitel davon passen auch zu den obigen Prüfungsinhalten und lassen sich gut in die Prüfungsvorbereitung integrieren. Übrigens: Direkt beim Rheinwerk-Verlag* bekommst du das Buch immer versandkostenfrei und hast auch die Möglichkeit, ein Bundle mit dem passenden eBook für nur ein paar Euro mehr zu kaufen.

IT-Handbuch für Fachinformatiker*innen*

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Umsetzungshilfe: Fachinformatiker/-in als PDF-Download beim BIBB
• Umsetzungshilfe: IT-System-Elektroniker:in
• Umsetzungshilfe: Kaufmann/-frau für Digitalisierungsmanagement
• Umsetzungshilfe: Kaufmann/-frau für IT-System-Management
• Neuordnungsverfahren der IT-Berufe: Interview mit zwei am Neuordnungsverfahren beteiligten Personen

Einen Rückblick auf Teil A (Projektarbeit) der IHK-Sommerprüfung 2021 gibt es in der einhundertsiebenundsechzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Ich gehe mein Highlights und „Lowlights“ der diesjährigen Sommerprüfungen durch. Trotz Corona liefen sie eigentlich ab wie immer, nur halt mit mehr Hygieneauflagen. Und die altbekannten Fehler in Dokumentation, Präsentation und Fachgespräch gab es auch immer noch! 🙂

Allgemeines

• Ein Prüfling hat seinen Personalausweis im Auto vergessen und brauchte 5min Verschnaufpause, nachdem er hektisch die Treppen hochgelaufen kam.
• Ein Abschlussprojekt wurde scheinbar schon 2019 begonnen, wenn man dem Berichtsheft trauen kann.
• Ein Berichtsheft wurde im Minutentakt (!) geschrieben.
• Viele Sprachen waren vertreten: Java, C#, Go, RPG, TypeScript, JavaScript, Ruby.
• Dominierende Technologie: SPA + Spring Boot im Backend.

Projektdokumentationen

• Die kürzeste Dokumentation war 9,5 Seiten lang bei einer Vorgabe von 15 Seiten.
• Lächerliche Inhalte, die wohl ausschließlich dem Füllen der Seiten dienten
  • Klassendiagramm aus einer einzigen Klasse
  • Screenshots der IntelliJ-Projektstruktur (drei Ordner)
  • Seitenweise langweiliger Quelltext auf schwarzem Hintergrund
  • „Auszug“ aus einem Lastenheft mit lediglich drei Aufzählungspunkten
  • Generierte „Entwicklerdokumentation“ ohne echte Kommentare
  • Standard-Dateispeicherdialog als Screenshot der Anwendung
  • Triviales Aktivitätsdiagramm mit einer einzigen Verzweigung
• Formelle Fehler
  • Kein Deckblatt
  • Keine Überschriften über Verzeichnissen
  • Abkürzungsverzeichnis nicht sortiert
  • Flattersatz statt Blocksatz verwendet
  • Farbe der Überschriften nicht exakt gleicher Farbton wie im Logo des Unternehmens
  • Erklärung grausig schlecht eingescannt (dunkel und schief)
• Inhaltliche/fachliche Fehler
  • Stundensatz 5 EUR (Azubivergütung / Arbeitszeit) ohne Arbeitgeberanteil zur Sozialversicherung, Gemeinkosten etc.
  • Unit-Tests, die gar nichts testen (kein assert() oder nur assertNotNull())
  • Use-Case-Diagramm war sehr (!) häufig fehlerhaft
  • „excludes“, seltsame Pfeile, keine Vererbung genutzt
  • Als Ablaufdiagramm missbraucht
• Unsinnige Inhalte, die Platz für wichtige Inhalte rauben
  • Für das Projekt unsinnige Kapitel (meiner Vorlage) ausgefüllt
  • Clean Architecture als Grafik im Anhang
  • Scrum, PHP und andere Grundlagen „erklärt“
• Positive Inhalte
  • Vernünftig gegenderte Dokumentation
  • Entscheidungstabelle für komplexe Logik modelliert
  • Pandemie in Amortisation einberechnet (Software für Sporttourniere)
  • Ergebnisse des Code Review erklärt (z.B. Variablen umbenannt)

Projektpräsentationen

• Die Präsentationen waren dieses Mal zwischen 11:10 Minuten und 16:15 Minuten lang.
• Eine Präsentation bestand aus nur 7 Folien und der Prüfling hat trotzdem die Zeit überzogen.
• Häufigstes Problem: keine oder zu wenige Artefakte gezeigt.
• Die Architektur wurde fast nie gezeigt. Das ist gerade bei SPA + REST ein Problem.
• Cliparts! Cliiiiiiiiparts!?
• Trivialer Code (for-Schleife mit if-Statement) wurde minutenlang erklärt.
• TDD/Scrum wurde erklärt.
• Absolut unnötige Fehler
  • Rechtschreibfehler auf den Folien.
  • deutlich sichtbare kaputte Formatierung (Zeileumbrüche mitten im Wort)
• Harte Pfade (C:\Users\Prüfling\...) im Test-Code, aber angeblich CI/CD benutzt.
• Viele Prüflinge haben bei ihrer Projektarbeit „viele Erfahrungen gesammelt“. Das heißt, dass viele von ihnen zum ersten Mal mit der eingesetzten Technologie gearbeitet haben.
• Es gab eine (sinnvoll) gegenderte Präsentation.
• Statt ein Use-Case-Diagramm zu zeigen, wurde eine Tabelle der Use-Cases mit Zuordnung zu Akteuren erstellt.
• Ein Prüfling hat „lol“ und „sounds fun“ laut in der Präsentation gesagt. *cringe*
• Positives
  • Foliengestaltung und insb. Agenda als „Browser-Tabs“ dargestellt mit „Klick“ auf Links im Burger-Menü.
  • Video eines Selenium-Testlaufs eingebaut.

Fachgespräche

• Fast immer (!) waren die selbst verwendeten Technologien nicht bekannt!
  • JavaScript: let/var/const, TypeScript vs. JavaScript
  • Java: Lambdas, Generics, Typinferenz
  • C#: using, String-Interpolation, out/ref, bool?
  • Go: Coroutines
  • DDD, CI/CD, PWA
• Jemand konnte tatsächlich Kanban erklären (Visualisierung, Pull-Prinzip, WIP-Limit).
• Wir haben zweimal nach Backup-Verfahren gefragt.
• Mehrere Prüflinge haben (angeblich) eine Codeanalyse gemacht, aber keine Ahnung, was dabei herausgekommen ist (z.B. Code Coverage, Smells).
• Frage eines Prüflings an meinen Prüferkollegen: „Kennen Sie sich mit IT aus?“

Häufigste Fragen im Fachgespräch

• Stundensatz, Gemeinkosten/BAB, Sozialversicherungen (fast in jedem Gespräch)
• Typisierung der verwendeten Sprache(n) (fast immer bei Backend + Frontend)
• REST, HTTP, Statuscodes, Methoden (insb. GET/POST) (fast in allen Web-/SPA-Projekten)
• Kardinalitäten
• Lambdas, Generische Klassen (insb. wenn sie verwendet wurden)
• Lastenheft vs. Pflichtenheft
• Datenschutz
• Datenbank-Transaktionen

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Checkliste für die Projektpräsentation und das Fachgespräch der IHK-Prüfung
• Zusammensetzung des Stundensatzes – Häufige Fragen im Fachgespräch
• Erläuterung der Gehaltsabrechnung – Häufige Fragen im Fachgespräch
• Datenbankmodellierung (Lernzielkontrolle zum Entity-Relationship-Modell)
• Datenschutz vs. Datensicherheit vs. Datensicherung
• Lasten- und Pflichtenheft in der Projektdokumentation

Weitere Infos zum Fachgespräch

Du suchst noch mehr Tipps rund um das Fachgespräch? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um das Fachgespräch.

Kennst du schon meine Hörbücher zur Vorbereitung auf das Fachgespräch? Unter dasperfektefachgespraech.de kannst du sie herunterladen. In insg. über 10 Stunden gehe ich über 200 Fragen im Detail durch und gebe Tipps für die Beantwortung.

Und wenn du dich für meinen Newsletter einträgst, bekommst du immer direkt alle Neuigkeiten von dieser Seite in dein Postfach geliefert.

Jetzt anmelden!

Um meine Ausbildungsbegleitung für die IT-Berufe per E-Mail geht es in der einhundertsechsundsechzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Bislang enthielt mein Newsletter nur Infos zu neuen Podcast-Episoden und Blogartikeln. Jetzt möchte ich einen Schritt weiter gehen und dich individuell bei deiner Ausbildung mit meinen E-Mails begleiten. Egal, in welchem Ausbildungsjahr du bist, oder ob du sogar selbst schon Azubis ausbildest: Ich schicke dir über das Jahr verteilt die jeweils passenden Themen zu deinem aktuellen Ausbildungsstand.

Vor der Ausbildung

Vor der Ausbildung unterstütze ich dich bei der Ausbildungsplatzsuche und gebe dir Bewerbungstipps. Außerdem zeige ich dir, wie du einen geeigneten Ausbildungsbetrieb findest und welcher IT-Job für dich der richtige ist.

• Tipps zur Bewerbung um eine Ausbildung
• Ablauf des Bewerbungsverfahrens für potentielle Azubis
• Ausbildung oder Umschulung?
• Wie erkenne ich einen guten Ausbildungsbetrieb?

1. Ausbildungsjahr

Im ersten Ausbildungsjahr geht es um einen erfolgreichen Einstieg in die Ausbildung. Hierbei geht es nicht nur um die fachlichen Fähigkeiten, sondern auch um das Miteinander im Ausbildungsbetrieb. Außerdem gehören berufsübergreifende Pflichten wie das Führen des Ausbildungsnachweises (Berichtsheft) dazu.

• Tipps zum erfolgreichen Einstieg in die Ausbildung
• Informationsquellen, Bücher und Podcasts für angehende ITler:innen
• Literaturempfehlungen
• Hilfreichsten Tools
• Erläuterung der Gehaltsabrechnung
• Produktivitätstipps
• Häufige Fragen zum Berichtsheft
• Verschiedene Buchclubs
• Ergonomie am Arbeitsplatz
• Einführung in die Versionsverwaltung mit Git
• Aufsetzen eines eigenen Webservers
• Einführung in die Programmierung und Objektorientierung
• Effektive Informationsrecherche mit Suchmaschinen

2. Ausbildungsjahr

Das zweite Ausbildungsjahr startet mit der Vorbereitung auf Teil 1 der gestreckten Abschlussprüfung. Hier wird es zum ersten Mal ernst, denn 20% der Abschlussnote stammen aus diesem Prüfungsteil. Aber auch die Vertiefung der bisherigen Ausbildungsinhalte und die Erweiterung um neue Themen gehören zum zweiten Ausbildungsjahr.

• Relationale Datenbanken, Normalisierung, SQL
• Zeichensätze und -kodierung
• HTML, CSS, XML
• Vertiefende Buchclubs
• Das ISO/OSI-Modell
• Cloud Computing, Docker/Kubernetes, Big Data
• Usability
• Kryptographie
• Vertiefende Themen der Programmierung, z.B. Unit-Tests, Mocks etc.
• Datenschutz vs. Datensicherheit vs. Datensicherung
• Das agile Manifest und Scrum

3. Ausbildungsjahr

Im dritten und letzten Ausbildungsjahr geht es natürlich um ein zentrales Thema: die IHK-Abschlussprüfung. Sowohl die schriftliche Prüfung als auch die praktische Projektarbeit sind wichtige Themen, auf die sich jeder Prüfling vorbereiten muss. Mit meiner Hilfe kommst du sicherlich gut durch beide Prüfungsteile.

• Aufbau und Ablauf der Abschlussprüfung
• Themenfindung für das Abschlussprojekt
• Professionelle Anforderungsermittlung
• Inhalte des Projektantrags
• Inhalte, Gliederung und Layout der Projektdokumentation
• Vorbereitung auf häufige Fragen im Fachgespräch
• Vorbereitung auf die schriftliche Abschlussprüfung
• Vorbereitung und ansprechende Gestaltung der Projektpräsentation

Nach der Ausbildung

Wenn du deine Ausbildung schon abgeschlossen hast, bekommst du von mir Tipps zur Jobsuche, Fort- und Weiterbildungen oder einfach allgemeinen Themen aus der IT. Vielleicht hast du sogar vor, selbst einmal Azubis auszubilden. Dann gebe ich dir noch mehr Tipps für deinen Weg zum Ausbilder.

• Bewerbungstipps und Recruiting-Prozess
• Continuous Improvement
• Teilnahme an User Groups und Fachkonferenzen
• Duales Studium und IHK-Weiterbildung zum Operative Professional
• Mögliche Karrierepfade (z.B. SAP-Consulting, Freelancer)

Für Ausbilder:innen

Wenn du selbst bereits Azubis ausbildest oder sie in Zukunft ausbilden möchtest, habe ich eine Vielzahl an Tipps aus meiner Ausbilderpraxis für dich zusammengestellt. Von der Einführung neuer Azubis bis hin zur Prüfungsvorbereitung begleite ich dich durch den gesamten Lebenszyklus eines Azubis in der IT.

• Ausbildung der Ausbilder (AEVO)
• Agile Ausbildung
• Erstellen des betrieblichen Ausbildungsplans
• Potentielle Ausbildungsinhalte
• Bewertung von Auszubildenden
• Verschiedene Maßnahmen für eine erfolgreiche Ausbildung
• Einführung eines neuen Azubis
• Mögliche Praktikumsinhalte in der IT
• Rechtliche Grundlagen wie das Berufsbildungsgesetz (BBiG) oder die Ausbildungsverordnungen

Jetzt anmelden

Um dich für meine ausbildungsbegleitenden Inhalte per E-Mail anzumelden, musst du lediglich ein kleines Formular ausfüllen. Du wirst dann Schritt für Schritt mit einigen Mails durch den Prozess geführt, um die für dich passenden Inhalte auszuwählen.

Anmelden zum IT-Berufe-Newsletter

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Vor der Ausbildung in den IT-Berufen
• Einstieg in die Ausbildung in den IT-Berufen
• Ausbildungsinhalte der IT-Berufe
• Vorbereitung auf die IHK-Abschlussprüfung der IT-Berufe
• Nach der Ausbildung in den IT-Berufen
• Für IT-Ausbilder:innen

Über das spannende Thema Big Data spreche ich mit Maurice Knopp in der einhundertfünfundsechzigsten Episode des IT-Berufe-Podcasts.

Inhalt Allgemeines zur Person

• Wie ist dein Name und wo arbeitest du (falls gewünscht)?
  • Name: Maurice Knopp
  • Beruf: Softwareentwickler seit über 16 Jahren; Anfangs Enterprise Software (Java, Backend), seit 4 Jahren Schwerpunkt Big Data Technologien.
  • Freiberufler in Zusammenarbeit mit der skillbyte GmbH aus Köln.
  • Hobbies: Podcaster f. skillbyte & OpenSource Entwickler (LaTeX-Vorlage für Abschlussarbeiten (Bachelor, Master, PhD))
• An welchen Projekten arbeitest du zur Zeit in deinem Tagesjob?
  • Konzeption von Big Data Architekturen (Data Lakes) & Big Data Softwareanwendungen (on premise; seit 2019 ausschließlich Cloud) für Großunternehmen (z.B. Medienbranche)
  • Implementierung von ETL-Strecken (Daten extrahieren, transformieren, laden in neuer DB oder Cloud Storage)
  • Enterprise Software (Java, Backend) (z.B. Energieversorger)
• Wie bist du zur Informatik bzw. Softwareentwicklung gekommen?
  • Bereits als Kind mit 6 Jahren von Technik fasziniert (GameBoy). Ich wollte immer verstehen, wie die Technik funktioniert. Erster PC MacIntosh + DOS: PC-Tuning. In den 2000ern Faszination für Internet und Linux entwickelt.
• Welche Ausbildung bzw. welches Studium hast du im Bereich der Informatik absolviert?
  • 2004-2008 Medieninformatik Bachelor an der TH Köln
  • 2008-2010 Wirtschaftinformatik Master an der TH Köln
  • viele Projekte nebenbei: Für Firmen Software und Webseiten erstellt, Abschlussarbeiten (B.SC. / M.SC.) stets in Unternehmen gemacht (Luxemburg / Köln).
• Mit welcher/n Programmiersprache/n arbeitest du im Alltag?
  • Java (riesiges Ökosystem, viele Data-Komponenten wurden in Java entwickelt (HDFS), super für threaded Entwicklung)
  • Python (Data Libs, Microservices)
  • Scala (Spark)
  • SQL (extrem wichtig, auf jeden Fall lernen)
  • Bash (Scripting)
  • Container + Orchestrierung: Docker + Kubernetes sind aktuell das große Ding (on-prem und cloud)
• Was ist deine Lieblingsprogrammiersprache und warum?
  • Java, top Entwicklungsumgebungsunterstützung, riesiges Ökosystem mit vielen frei verfügbaren Bausteinen, hoher Reifegrad, von App-Entwicklung bis Server-Softare alles möglich.
  • Aber: Keine religiöse Einstellung zur Programmiersprache! Ökosystem ist wichtiger, da eine gute IDE per Autocompletion viel Arbeit abnimmt. Man sollte die zum Anwendungsfall passende Sprache auswählen.
  • Die IDE ist ein wichtiges Werkzeug, dessen Benutzung man perfektionieren sollte. Macht einen großen Unterschied bei der Produktivität.
  • Wichtig ist, dass die gewählte Sprache lebt und sich weiterentwickelt. Gute Features werden eh mit der Zeit übernommen (z.B. aus Rails).

Big Data

• Was verbirgt sich hinter dem Begriff „Big Data“?
  • Die Frage wird meist von Kunden gestellt, um herauszufinden, ob sie „schon“ Big Data machen oder noch ganz normale Datenverarbeitung.
  • Wann wird aus Datenverarbeitung Big Data? Ab 1 Mio Datenzeilen? Ab 100 Mio?
  • Big Data bezeichnet Technologien zur Verarbeitung und Auswertung „riesiger Datenmengen“ -> 100 Mio von Datenpunkten.
  • In kurzer Zeit entstehen viele Datenpunkte, meist Millionen am Tag. Sie werden dann oft aggregiert in Dashboards.
  • Software zur massiven Parallelverarbeitung mit Standard-Hardware (Enterprise Grade Linux Server, Cloud VMs).
  • Big Data fängt an, wenn eine Maschine nicht mehr reicht für die Verarbeitung der Daten.
  • Beispiel: Aggregiere Verkaufsdaten in riesigen Datenbeständen (Divide-and-Conquer-Modell). Selbstfahrendes Auto liefert schnell viele Daten.
  • Viele DAX-Konzerne haben das im Einsatz, da bei ihnen viele Daten anfallen.
• Was verbirgt sich hinter den „vier Vs“ (velocity, volume, variety, veracity)?
  • Volume (Datenmenge): Big Data macht nur bei extrem großen Datenmengen Sinn. Für die Verarbeitung von 10-100 Mio Datensätzen reichen Standardwerkzeuge. 10-100 Mio Datensätzen pro Stunde -> da wird es interessant.
  • Variety (Vielfalt der Datenstrukturen): strukturiert (DB) vs. unstrukturiert (Text, PDF Dokumente, Bilder, Video).
  • Velocity (Geschwindigkeit): Wie schnell werden Daten erzeugt bzw. müssen verarbeitet werden, z.B. beim autonomen Fahren.
  • Veracity (Wahrhaftigkeit): Unsicherheit bzgl. der Datenqualität. Beispiele: unterschiedliche Zeitzonen, Umlaute, fehlende Daten, doppelte Daten, ungültige Daten etc.
• Veracity macht häufig Probleme bei Kunden. Kann das nur durch manuelle Arbeit gelöst werden?
  • Standardlösungen sind für häufige Probleme möglich (Kleinschreibung von Benutzernamen usw.).
  • Auf Hadoop gibt es viele Lösungen
  • Seit 2019 läuft alles in der Cloud und nicht mehr im eigenen RZ. Das sollte man aber vorher rechtlich klären.
• Warum wird so viel in der Cloud betrieben?
  • Die vier Vs schreien nach der Cloud. Dort ist z.B. NoSQL einfach verfügbar und scheinbar „unendlicher“ Speicher.
  • Skalierbarkeit ist in der Cloud auch optimal.
  • Realtime geht natürlich nur lokal.
• Hat die Cloud Big Data vorangetrieben?
  • Ja, da die Einstiegshürde nun geringer ist.
  • Hadoop ist als Open Source gestartet (Spielzeugelefant des Kindes des Entwicklers hieß so), aber man brauchte viele Server dafür.
  • Big Data startet oft klein und wächst dann schnell, daher ist Infrastruktur immer hinterher.
  • Hortonworks wurde gekauft von Cloudera. Dadurch gibt es jetzt hohe Lizenzkosten pro Node. Strategie ist nun, die Top-Kunden zu betreuen, die nicht in die Cloud dürfen/können.
• Warum ist das Thema Big Data aktuell und in Zukunft wichtig und interessant?
  • Daten sind das neue Öl (Treibstoff)!
  • Datenanalyse ist der Verbrennungsmotor (richtigen Schlüsse aus Daten ziehen).
  • Beispiele (Daten/Analyse)
  • Logdaten: Systemfehler finden. Wo können Kunden nicht bedient werden? Welche Prozesse schlagen fehl? Wo sind Antwortzeiten zu hoch?
  • Nutzerverhalten: Welche Funktionen werden genutzt, welche nicht? Dementsprechend Entwicklungsleistung konzentrieren. Welche Produkte werden nachgefragt? Wo brechen Kunden im Prozess ab? A/B-Tests verschiedener Varianten, um optimalen Kandidaten zu finden (z. B. bei der Buchung von Flügen).
  • Telemetriedaten von Systemen: Voraussage, wann Maschinenteile ausfallen werden (Ersatzteilbestellung optimieren, Ausfallzeiten minimieren). Voraussage von Technikereinsätzen. Festlegung von Wartungsintervallen.
• Welche Unternehmen sollten sich mit Big Data beschäftigen und warum?
  • Jedes Unternehmen sollte sich fragen:
  • In welchen Prozessen generieren wir heute schon viele Daten und welche Erkenntnisse könnten in diesen liegen?
  • Welche Prozesse erfassen noch zu wenig Daten?
  • Welche Erkenntnismöglichkeiten hätten wir, wenn wir alle Unternehmensdaten an einer zentralen Daten-Sammelstelle (Data Lake) bereitstellen würden, sodass wir Abfragen kreuz und quer über diese Daten fahren können?
  • Beispiele: Medienunternehmen -> User-Nutzungsdaten, Energieversorger -> Messzählerdaten etc.
  • Große Datenprobleme brauchen Big Data! Viele Daten müssen erfasst werden, meist bei Millionen von Kunden.
  • Aber generell steigt das Datenvolumen weltweit, auch der Mittelstand braucht irgendwann Big Data.
• Was sind übliche Use Cases für Big Data?
  • Beispiel: Industrieunternehmen hat Teile für Weltraumunternehmen gebaut auf sechs Fertigungsstraßen. Dabei durfte es nicht mehr als 2% Ausschuss geben, da sonst Verluste drohten.
  • Verschiedene Geräte arbeiteten zusammen: Öfen, CNC, etc. Alle hatten Sensoren, die aber nicht abgefragt wurden.
  • Irgendwann wurden dann diese Daten gesammelt und man näherte sich der 2%-Hürde. Durch die Daten wurde festgestellt, dass 90% des Ausschusses aus einem einzigen Ofen kamen. Der Hersteller wurde angerufen, der Ofen neu kalibriert und 0,1% als neuer Ausschuss erreicht.
• Wird bei Big Data meist etwas aus großen Datenmengen aggregiert?
  • Data Engineering befasst sich damit, Daten zusammenzufassen, zu planen, einen Data Lake mit normierten Daten zu erzeugen, ETL.
  • Data Science erzeugt statistische Modelle, KI, neuronale Netze mit dem Ziel, Erkenntnisse zu gewinnen, Muster/Ausreißer zu finden, Voraussagen zu treffen.
  • MTBF (mean time between failure) als Beispiel: besser schonmal vorher Ersatzteile bestellen, bevor etwas kaputt geht (Predictive Mainenance).
• ETL gab es schon vor Big Data! Was kann ich mit Big Data machen, was vorher nicht möglich war?
  • Kurz: 1) große Datenbestände überhaupt verarbeiten und 2) das zu vertretbaren Kosten tun.
  • Abrenzung „Data Science“ und „Data Engineering“
  • Data Science: Kernkompetenzen eines Data Scientists liegen in fortgeschrittenen Kenntnissen der Mathematik und Statistik, Machine Learning, Artificial Intelligence und erweiterter Fähigkeiten zu Datenanalyse. Oberstes Ziel eines Data Scientist ist es, die Auswertungsergebnisse in Hinblick auf die Nützlichkeit für ein Unternehmen oder Geschäftszweck zu untersuchen und diese verständlich zu präsentieren bzw. zu kommunizieren. Kommunikation und verständliche Visualisierung der Ergebnisse stellen eine Schlüsselqualifikation dar und sind genau so wichtig wie die Durchführung der Analysen selbst. Im Gegensatz zu einem Data Engineer ist ein Data Scientist viel mehr mit der Interpretation und der (visuellen) Aufbereitung der Daten befasst, trainiert Modelle bzw. Machine-Learning-Algorithmen und prüft diese fortlaufend auf Passgenauigkeit.
  • Data Engineering: Kernkompetenzen eines Data Engineers liegen im Bereich der angewandten, fortgeschrittenen Programmierung in Hochsprachen (Python, Scala, Java), dem Verständnis von verteilten Systemen und Datenflüssen in diesen. Datenanalyse und die Verwendung von Werkzeugen zur Datenextraktion und -transformation gehören ebenso zu dessen Fähigkeiten. Im Gegensatz zu einem Data Scientist stellt ein Data Engineer also Daten bereit und verarbeitet diese programmatisch.
  • ETL gibt es schon sehr lange, aber heute sind andere Werkzeuge und Möglichkeiten vorhanden. Trotzdem werden alte Konzepte übernommen (z.B. SQL).
  • Letzlich ist es eine Weiterentwicklung des klassischen Data Warehouses.
  • Ein Data Lake ist ein Pool mit viel Speicherplatz mit allen Rohdaten. Danach werden Aggregationen auf den Daten durchgeführt, die vorher vielleicht noch gar nicht bekannt waren. Hier sind Konzepte nötig, damit der Speicher nicht explodiert.
• Funktioniert Big Data auch mit „klassischen“ Datenbanken (relationale wie Oracle)?
  • Wenn es geht, dann ist es kein Big Data!
  • Big Data Cluster ist komplexer als eine „einfache“ Datenbank.
  • Viele Fragestellungen aus Big Data kann Oracle nicht lösen, weil es zu viele Daten sind.
  • 20.000 Maschinen hat Facebook nur für den Messenger im Einsatz, da viele/schnelle/sprunghafte Daten anfallen.
• Was muss ich als Entwickler:in anders machen, wenn ich mit Big Data arbeite?
  • Es gibt einen „Compatibility Layer“ für die Anwendung bestehenden Wissens, z.B. SQL statt Map/Reduce.
  • Ein Dienst zerlegt z.B. SQL in Map/Reduce, verteilt das auf den Cluster und fügt die Ergebnisse wieder zu einer „Tabelle“ zusammen.
  • Apache Spark mit Scala als Werkzeug, da Sprache Lambdas etc. unterstützt.
  • Man muss aber schon einiges neu lernen, vor allem die Konzepte etc.
  • Als Entwickler:in: Affinität zum Backend nötig, man „sieht“ nichts, man muss gerne „knobeln“.
  • Statistik, Deutung von Daten muss spannend sein.
  • Aufbereiten der Daten für Entscheider, einfache Visualisierung ist nötig.
• Man kann also auch etwas falsch machen, wie z.B. bei einem Full Table Scan in klassischen DBs?
  • Ja, die „Magic“ nimmt einem der Cluster ab, es gibt viele Abstraktionsschichten.
• Was sind (technische/organisatorische) Herausforderungen bei der Arbeit mit Big Data?
  • Technische Herausforderungen:
  • ETL-Prozesse aufsetzen (insb. unvollständige/fehlerhafte Daten).
  • Geduld bei Verarbeitungsvorgängen. Überlegen: wie kann ich schnell iterieren? Datensubset ausreichend für Test?
  • Organisatorische Herausforderungen:
  • DSGVO: Originaldaten und auch Extrakte oder verarbeitete Daten müssen zyklisch gelöscht werden.
  • Korrekte Pseudonymisierung von kritischen Daten (Logins/Passwörtern).
  • Zuganskontrolle zu Datentöpfen.
  • Bedeutung einzelner Daten (Wie werden die erfasst und was messen die Datenpunkte eigentlich?).
  • Größtes Problem: Datenhoheiten im Unternehmen werden neu verteilt. Domänenwissen und Silos werden aufgebrochen. Dieser Prozess ist mit vielen Widerständen verbunden, sodass Unterstützung aus dem Vorstand sinnvoll ist.
• Kann man das Ergebnis der Aggregationen als Mensch noch nachvollziehen?
  • Es gibt einen Strauß von Modellen für verschiedene Anwendungen. Das Modell wird mit Daten gefüttert, dann schaut man was rauskommt, passt iterativ die Parameter an und schaut sich die Veränderung an.
  • Im Gegensatz dazu steht ein neuronales Netz, das Hund/Katze unterscheidet. Da ist es nicht mehr nachvollziehbar, wie das Ergebnis entsteht.
• Ist Big Data gleich Künstliche Intelligenz?
  • Letztlich ist alles Mathematik!
  • KI ist heute ein Buzzword, eher für ein neuronales Netz, nicht für Big Data. Die Entscheidung ist nachher nicht mehr nachvollziehbar.
  • Wenn ein Problem algorithmisch lösbar ist, dann ist es keine KI.
  • Beispiel: Warenkörbe von Schwangeren ausgewertet und Prediction daraus abgeleitet -> KI, „Zauberei“.
• Ist Big Data die Grundlage für viele KI-Systeme?
  • Ja, die vielen Daten sind ein gutes Training für die KI, wie bei menschlicher Intelligenz.
• Welche Begriffe tauchen häufig im Zusammenhang mit Big Data auf (z.B. Data Science, Edge Computing)?
  • Date Lake, Hadoop, Cloud Services (Data Proc), 4Vs, Mengengerüste, Laufzeiten und „Big-O-Notation“, Python, Datenbanken (SQL/NoSQL), REST-Schnittstellen, Dashboards und Datenvisualisierung, Voraussagen immer sehr gefragt.
  • Edge Computing hat einen Schnitt mit Big Data, ist aber eigentlich ein eigener Bereich. Verarbeitung der Daten dort, wo sie anfallen (z.B. direkt beim Hochofen). Beim Auto: Kamera liefert an Computer (nicht Edge) vs. Kamera hat Chip, der schon vor Lieferung des Ergebnisses entscheidet. Die Reduktion der Datenmenge ist das Ziel. Beispiel: Kamera nimmt nur auf, wenn sich etwas bewegt.
• Welche Werkzeuge gibt es zum Umgang mit Big Data?
  • Hadoop ist wichtig. Das ist ein Ökosystem mit Hive (SQL-Service für HDFS), Apache Spark für performante Programme.
  • Es gibt viele Libraries, die man hier nachschauen kann: Übersicht über das Apache-Hadoop-Ökosystem.
  • Auch im Podcast habe ich schon darüber gesprochen: Podcast #3: Das Hadoop Ökosystem – Was leistet die bekannteste Big Data Platform?
  • Cloud-Services (DataProc bei Google wie Hive) bauen oft Hadoop nach.
  • Hadoop nutzt HDFS (verteiltes Dateisystem über mehrere Server). Das ist nutzbar wie ein normales Dateisystem, ähnlich wie ein NAS. „Größte Festplatte des Unternehmens“.
• Was ist Map/Reduce?
  • Bei großen Datenmengen folgen eigentlich immer zwei Schritte hintereinander: Map und Reduce.
  • Map: viele Datensätze in DB, aber nur Benutzername/Login interessant, also „mappen“ wir die gewünschte Spalten.
  • Reduce: sucht z.B. MAX-Wert für den letzten Login und aggregiert damit die Daten.
  • Vor Hive musste man Map/Reduce selbst schreiben, z.B. mit Scala, ähnlich wie bei MongoDB mit viel Drumherum, z.B. RAM nicht auslasten etc.
  • Mit Spark können Scala-Programme entwickelt werden, um die Daten zu verarbeiten.
• Wie fragt Hive Textdateien mit SQL ab?
  • Es gibt eine virtuelle Tabelle als Zwischenschicht.
  • Daten haben meist ein Standardformat wie CSV und HDFS „versteht“ das, dedupliziert die Daten usw.
• Was mache ich mit Daten, die HDFS nicht automatisch versteht?
  • Das entsprechende Programm muss die Daten selbst interpretieren.
• Warum wird so oft Python eingesetzt?
  • Python wird oft gelehrt an den Unis, es sind viele Libs verfügbar, es ist einfach lernbar, sieht „clean“ aus, wird oft in Naturwissenschaften eingesetzt, da einfach zu lernen.
  • PySpark übersetzt Python-Programme in Scala.
• Welche Ausbildung bzw. welches Studium empfiehlst du für das Einsatzgebiet Big Data?
  • Es gibt Studiengänge wie z.B. „(M.Sc.) Big Data & Business Analytics“ der FOM oder „Fernstudium Big Data Management (B.A.)“ der AKAD, die gibt es aber noch nicht sehr lange.
  • Praxisrelevant: Übung mit Kursen von Udemy (Frank Kane von Sundog Education).
  • Tools der Cloud Umgebungen: AWS, Azure, GCP.
  • Wenn man Data Scientist werden möchte, sind das oft promovierte Naturwissenschaftler. 90% wissenschaftliche Arbeit, wenig Softwareentwicklung, sondern eher Libs „zusammenstecken“.
  • Data Engineering ist eher „hands on“, viel Softwareentwicklung, nur halt mit Bezug auf Daten, kein Frontend etc.
  • ETL geht auch mit Ausbildung, man braucht einen Überblick über verfügbare Tools, wendet vorhandene Modelle/Tools an, löst gegebene Probleme mit Tools. Das ist ein eher iteratives Vorgehen.
• Heute fallen viele Fachbegriffe. Hast du eine Buchempfehlung zum Einstieg?
  • Martin Kleppmann: Designing Data Intensive Applications (O’Reilly) für einen detaillierten Einstieg.
  • Auch bei Udemy gibt es viele gute Kurse, z.B. von Frank Kane. Die sind didaktisch sehr gut und oft günstig zu kaufen.
• Kann Big Data in Unternehmen als Graswurzelbewegung entstehen?
  • Manche Unternehmen erkennen die Wichtigkeit von Daten, andere nicht. In letzteren wird es dann schwierig als Einzelner mit Big Data anzufangen.
  • Die Unterstützung durch den Vorstand ist immer wichtig. Viele Unternehmen tun sich schwer, weil alte Datensilos aufbrechen. Das gibt politisches Geplänkel, das geht nur mit Unterstützung.
  • Ansonsten auf jeden Fall! Überall fallen Daten an, auf denen man aufsetzen kann.
  • Eine Big-Data-Strategie bedeutet nur, fortlaufend zu prüfen und besser zu werden.
  • Es fallen in der Praxis einfach immer mehr Daten an und machen Big Data erst notwendig/sinnvoll.
  • Ein Einstieg mit etablierten Tools ist auch einfach/schnell möglich, es gibt oft Quick Wins.
• Haben wir noch Themen vergessen, die wir unbedingt besprechen sollten?
  • Ausbildung ist wichtig! Aber wie immer gilt: kontinuierlich weiterbilden ist Pflicht!
  • In den letzten Jahren ist so viel passiert. Es gibt immer mehr Daten.
  • Das älteste Big-Data-Problem ist wohl die Recommendation-Engine bei Amazon (Kunden kauften auch…).

Aus- und Weiterbildung

• Bildest du selbst Entwickler-Nachwuchs aus und wenn ja, wie ist das Vorgehen?
  • Ich habe selbst keine Azubis.
  • Ich habe aber einen Onboarding Track für neue Mitarbeiter (Tutorial).
  • Ansonsten: Podcast #48: Grundkenntnisse und Skills für ALLE IT-Fachkräfte
• Hast du Tipps für Ausbilder/-innen im IT-Bereich?
  • Fokus auf Backend legen, nicht auf das Frontend (fancy, bunte Frameworks etc.)
  • Das Datenthema ist eher abstrakt, Backend passt besser dazu, Bücher vermitteln das gut.
• Hast du Tipps zur Aus-/Weiterbildung für angehende Softwareentwickler/-innen?
  • Keine Berührungsängste haben! Einfach mal machen! VM aufsetzen, loslegen, ausprobieren!
  • Podcast #14: Big Data und Machine Learning Projekte richtig angehen
• Was ist das letzte Fachbuch mit Bezug zur Programmierung, das du selbst gelesen hast?
  • Martin Kleppmann: Designing Data-Intensive Applications
  • Mein Tipp: Baeldung.com Spring Kurs, Udemy Kurse, Linux Academy Kurse (oft zahlt AG oder Uni den Zugang)
  • Robert C. Martin: Clean Code
  • Joshua Bloch: Effective Java
• Was ist dein absolutes Lieblingsbuch mit Bezug zur IT/Programmierung und warum?
  • Joshua Bloch: Effective Java -> für Java-Entwicklung ein Muss.
• Welche Quellen kannst du für die Aus- und Weiterbildung im Bereich Programmierung empfehlen und warum?
  • Udemy, Linux Academy und natürlich StackOverflow
• Hast du Tipps zur Aus-/Weiterbildung für angehende Softwareentwickler/-innen?
  • Sucht euch eine exzellente Universität (auch im Ausland) für euer Fach! Eine gute Ausbildung und einflussreiche Kontakte sind der Turbo für eure Karriere!
  • Bildet euch weiter!
  • Generell: Versucht das Problem, welches ihr lösen möchtet, so genau wie möglich zu verstehen und ein Lösungskonzept zu erarbeiten. Wenn man das Problem klar verstanden hat, kann man eine zielgerichtete Lösung entwickeln, denn Komplexität tötet jedes System und jede Motivation. Siehe auch Podcast #9: Bull’s Eye Software Development – Einfach und fokussiert auf Unternehmensziele.
• Hast du Tipps für Ausbilder/-innen im IT-Bereich?
  • Möglichst viel Hands-on machen!
  • Möglichst enge Kooperation mit Unternehmen mit „echten“ Big-Data-Problemen und echten Projekten.

Abschluss

• Wo können die Hörer mehr über dich erfahren bzw. dich kontaktieren?
  • Ich bin sehr „nahbar“. Sucht mich und stellt gerne direkt eure Fragen.
  • Xing
  • LinkedIn
  • skillbyte Podcast (bei Spotify)

Literaturempfehlungen

Maurices Empfehlung für den Einstieg ins Thema Big Data ist Designing Data-Intensive Applications von Martin Kleppmann*.

*

Wer lieber Videokurse schaut, sollte sich Frank Kane bei Udemy anschauen.

Und völlig unabhängig von Big Data empfiehlt Maurice noch diese zwei Bücher für Entwickler:innen: Clean Code von Robert C. Martin* und Effective Java von Joshua Bloch*.

*

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Skillbyte Technologie Podcast (Maurices Podcast)
  • Podcast #3: Das Hadoop Ökosystem – Was leistet die bekannteste Big Data Platform?
  • Podcast #9: Bull’s Eye Software Development – Einfach und fokussiert auf Unternehmensziele
  • Podcast #14: Big Data und Machine Learning Projekte richtig angehen
  • Podcast #48: Grundkenntnisse und Skills für ALLE IT-Fachkräfte

Über verschiedene Möglichkeiten der Qualitätssicherung bei der Softwareentwicklung spreche ich mit Christian Kranert in der einhundertvierundsechzigsten Episode des IT-Berufe-Podcasts.

Inhalt Allgemeines zur Person

• Wie ist dein Name und wo arbeitest du (falls gewünscht)?
  • Christian Kranert, 31 Jahre alt, Nürnberg, ich arbeite bei der Head-on Solutions GmbH.
  • Wir entwickeln eine Software zum Cloud Management für Frisöre, Kosmetikstudios usw. für eine moderne Organisation: Terminbuchung, Kasse, Marketing.
  • Wir sind eine rein interne Entwicklungsabteilung.
• An welchen Projekten arbeitest du zur Zeit in deinem Tagesjob?
  • Die Software, die ich mit meinem Team der Head-on Solutions GmbH entwickle: studiolution.
• Wie bist du zur Informatik bzw. Softwareentwicklung gekommen?
  • Ich war schon immer fasziniert von Computern und hatte mit 12 Jahren meinen ersten eigenen PC
  • Darauf habe ich schnell ein erstes Programm erstellt mit Visual Basic 6.
  • Ich habe mir nie erträumt, ohne Studium programmieren zu können.
  • Zum Einstieg habe ich „Hello World“ programmiert und danach einen Paint-Klon.
• Welche Ausbildung bzw. welches Studium hast du im Bereich der Informatik absolviert?
  • Nach der Schule (die war nervig, weil ich schon wusste was ich will) habe ich die Ausbildung zum Fachinformatiker Anwendungsentwicklung gemacht.
  • Ich bin in der Automobilindustrie gestartet und habe bei der Brose Group eine sehr gute Ausbildung bekommen. Die hatten 200 Leute in der IT und ich konnte viele Abteilungen durchlaufen. Dort habe ich viel gesehen und gelernt.
  • Ich bin gestartet mit der SAP-Entwicklung, aber parallel habe ich mit .NET begonnen.
• Mit welcher/n Programmiersprache/n arbeitest du im Alltag?
  • Im Backend setzen wir auf C# in Kombination mit dem SQL Server.
  • Im Frontend setzen wir JavaScript ein, aber in Form von TypeScript. Für HTML/CSS nutzen wir SASS als Präprozessor.
  • TypeScript mag ich wegen der Typisierung.
• Was ist deine Lieblingsprogrammiersprache und warum?
  • ABAP habe ich in SAP zwar auch gemacht, aber C# ist meine Lieblingssprache. Ich mag die Typisierung und viele Features, die konsistent umgesetzt sind.
  • Java habe ich mir angeschaut für die SAP-Entwicklung.
  • Ich bin kein Freund der „religiösen“ Gefolgschaft von Programmiersprachen.

Qualitätssicherung bei der Softwareentwicklung

• Warum sollten wir uns überhaupt Gedanken zur Qualitätssicherung machen?
  • Das ist eine gute Frage, die man oft im Alltag beantworten muss, z.B. bei Diskussionen mit Kunden oder dem Chef.
  • Vergleich mit der Industrie: Teile müssen „perfekt“ sein, der Kunde soll am Ende glücklich sein.
  • Bei Software ist es genauso: das Release soll den Kunden zufrieden stellen.
  • Ansonsten muss man nachbessern und hat unzufriedene Kunden.
  • Die Behebung von Fehlern ist sehr teuer im Nachhinein.
  • Außerdem ist Kosteneffizienz und Mitarbeiterzufriedenheit wichtig für das Unternehmen.
• Welche Maßnahmen gibt es grundsätzlich zur Qualitätssicherung?
  • Wir setzen auf eine Art Stufensystem. Je früher Fehler behoben werden, desto billiger ist es.
  • Das beginnt beim Entwickler: wir haben eine Entwicklerselbstkontrolle, Stichpunkte, die die Entwickler:innen selbst durchgehen, z.B. Diff checken vor dem Commit. Das machen wir extra in einem externen Programm, damit eine andere Schriftart für eine andere Denkweise sorgt und Flüchtigkeitsfehler, vergessener Debugcode etc. vermieden werden.
  • Danach kommen die Unit-Tests, die die Entwickler:innen selbst schreiben.
  • Dann folgt ein Code Review durch eine andere Person.
  • Und zuletzt kommt noch ein manueller Test.
• Welche technischen Maßnahmen zur Qualitätssicherung gibt es auf Ebene einzelner Commits?
  • Die genannte Entwicklerselbstkontrolle.
  • Regelmäßige Routinen aus Checklisten sind auch in der Industrie gängig, dort haben wir das abgeschaut.
  • Das nimmt Komplexität aus dem Prozess und führt zu weniger „Mental Load“.
  • Wir haben auch weitere Checklisten, z.B. für Releases etc.
• Wo sind die Checklisten abgelegt?
  • Wir haben den DevBuddy, unsere interne Entwicklungsplattform für die Ablage. Dort haben wir auch mit HTML/JavaScript einen „Fortschrittsbalken“ gebaut, um ein wenig Gamifaction einzubauen.
• Wann und wofür verwendest du welche Tests: Unit-Tests, Snapshot-Tests, manuelle Tests?
  • Wir setzen kein TDD ein, die Mehrheit im Team glaubt nicht daran.
  • Aber unser Code muss immer mit Tests abgedeckt werden, auch wenn die Tests erst nach dem Code geschrieben werden.
• Warum setzt ihr nicht TDD ein?
  • Wir entwickeln agil und auch bei der Konzepterstellung wirkt das Team mit.
  • In diesem Prozess wird gerade zu Beginn viel am Code angepasst, daher hemmt TDD uns eher, z.B. bei Prototypen, bei denen der Test erstmal nicht implementiert wird.
  • TDD ist aktuell einfach nicht zuträglich, aber wir haben es auch nur einmal ausprobiert.
• Achtet ihr auf die Code Coverage?
  • Sie wird noch nicht automatisch ermittelt, geht aber mit Visual Studio ganz gut.
  • Bei der Line-/Branch-Coverage peilen wir 95% an. Durch wenig Boilerplate-Code schaffen wir das auch.
• Wie (gut) lassen sich Code Reviews in den Entwicklungsprozess integrieren?
  • Bei uns wird jede Zeile geprüft, alles braucht ein 4-Augen-Prinzip.
  • Direkt nach Implementierung folgt das Review, niemand darf länger als einen Tag entwickeln ohne Review.
  • Bei anderen Unternehmen wird oft nur über die Findings gesprochen und dann aber nichts gemacht. Wir erzwingen aber die Änderungen aus dem Review.
• Macht ihr das auch mit Checklisten?
  • Ja, aber sie dienen nur zur Einarbeitung neuer Kolleg:innen. Danach sind die Konventionen dann bekannt.
  • Alle Mitarbeiter machen ein Code Review, sogar Praktikanten bei erfahrenen Entwicklern. Das fördert die Teamkultur: viel und häufiges Feedback. Die Kritikfähigkeit wächst dadurch stark.
• Macht ihr Pull Requests? Oder wo/wie läuft das Review?
  • Das Review wird direkt auf dem Branch durchgeführt. Durch eine Verknüpfung zwischen Work Items und Commits geht das sehr gut.
  • Wir überlegen gerade, Pull Requests einzuführen, aber wegen der kurzen Zyklen hätten wir dabei wohl zu viel zu mergen.
• Wie sieht das Ergebnis der Reviews aus?
  • Die Findings werden im persönlichen Gespräch geklärt. Kleinigkeiten werden auch direkt von Reviewer gefixt, abhängig von Skill des Gereviewten (z.B. Flüchtigkeitsfehler).
  • Eine Diskussion über mögliche Alternativen geht persönlich besser und die Begründung ist enorm wichtig, da nur so ein Diskurs und eine bessere Lösung entsteht.
• Dann ist aber viel Zeit für Gespräche nötig, oder?
  • Kurze Wege sind dafür unbedingt nötig! Das Review muss beim Team akzeptiert sein und die Arbeitszeiten müssen zusammen passen.
• Dann kommen die manuellen Tests?
  • Unser Ziel ist die Automatisierung, aber komplett wegkommen werden wir nicht von den manuellen Tests. Sie decken Dinge auf wie Wording oder fachliche Fehler (z.B. negative Umsatzsteuer).
  • Manuelle Testfälle werden bei uns schon von den Entwicklern erstellt, da Tester den Code nicht kennen.
  • Jeder Entwickler ist verpflichtet, Tests zu formulieren, weil sonst Tests „verloren gehen“.
  • Ursprünglich haben wir das mit Excel gemacht, jetzt haben wir DevBuddy um ein Testtool erweitert mit Testrunner für ein wenig Gamification.
  • Das fördert auch die Kommunikation mit dem Kunden.
• Und dann sind wir schon beim Release?
  • Ja, danach kommt das Deployment, aber wir sind dann noch nicht fertig! Stichwort: Exception Logging.
• Wie behandelt/protokolliert ihr Laufzeitfehler?
  • Wir haben eine ganz einfache Methode: ein globaler Exception-Handler schickt Stacktraces per Mail an ein Postfach, das rotierend von Entwicklern beobachtet wird.
  • Das motiviert die Mitarbeiter, Fehler zu vermeiden/beheben.
  • Vorteile des Postfachs: man kann die Mails einfach weiterleiten und viele Infos transportieren.
  • Eigentlich war die Lösung nur ein Provisorium, aber inzwischen bleiben wir gerne dabei.
• Wie integrierst du Fehlersuche und Bugfixing in deine Arbeit?
  • Die Fehlerbehebung ist bei uns nur in bestimmten Phasen möglich, viele Fehler sind nicht „dringend“.
  • Teilweise beschäftigen wir uns wochenlang nicht mit Fehlern. Wir bündeln sie stattdessen und bearbeiten sie z.B. in separaten Sprints.
  • Wir legen den Fokus entweder auf Fehler oder die Entwicklung.
  • Fehler sind sehr teuer und müssen vermieden werden.
• Wer dokumentiert die Software und wann ist der beste Zeitpunkt dafür?
  • Viele Entwickler mögen Dokumentation nicht, aber sie ist das wichtigste Instrument, um Komplexität im Griff zu halten.
  • Wir entwickeln eine komplexe Anwendung mit vielen Teilen und Schnittstellen.
  • Daher ist Dokumentation enorm wichtig, weil man als Entwickler viel vergisst in 2-3 Monaten nach der Implementierung.
  • Das läuft bei uns auch im DevBuddy mit plain HTML, da unsere FullSTack-Devs damit gut klarkommen. Das ist selbst gestaltbar (Code-Highlighting, TOC etc.) und eine recht angenehme Arbeit. Außerdem befolgen wir die Idee des „eat your own dog food“.
  • Dokumentation muss schnell und kurzfristig erfolgen, da man sonst wieder viel vergisst. Die Dokumentation sieht anders aus, wenn sie erst rückblickend geschrieben wird.
  • Das zentrale Problem ist: Entwickler:innen werden dabei rausgerissen aus der Entwicklung (Flow), wenn sie sich zwischendruch und Dokumentation, Rechtschreibung usw. kümmern müssen. Das ist ineffizient durch einen nötigen Kontextwechsel im Gehirn.
  • Während des Codens werden daher nur Stichpunkte erfasst, damit es schnell geht. Die werden dann später ausformuliert.
• Welche Rolle spielen Best Practices und Pattern bei dir?
  • Im Rahmen des Produktkonzeptes wird das bei uns mitgemacht.
  • Wir bekommen nur lose Vorgabe aus dem Fachbereich, um das zu lösende Problem zu zeigen.
  • Die konkrete Lösung wird dann vom Team geschaffen und dabei wird die Architektur festgelegt.
  • Wir verwenden zwei Arten von Mustern: Design Pattern und Company Pattern, die wir selbst „gefunden“ haben für immer wieder auftretende Probleme.
  • Das kürzt die Kommunikation ab, denn jedem im Team sind die Pattern klar. Dadurch müssen nur nicht abgedeckte Bereiche diskutiert werden, wobei schon Namen von Methoden festgelegt werden usw.
• Wie gelangst du zu Konventionen, die vom gesamten Team mitgetragen werden?
  • Das Team legt die Pattern gemeinsam fest. Irgendjemandem fällt etwas auf und es gibt dann einen Impuls ans Team. Meist sind zwei verschiedene Lösungen für ein Problem der Anlass.
  • Beispiel: Es gibt viele Einstellungen in unserer Software, z.B. Default-Einstellungen vom Hersteller und Kunden-Einstellungen, die davon abweichen. Wie fragt man das im Code ab? Dieses Problem wurde nur einmal gelöst (das war gar nicht so einfach) und das Ergebnis ist unser Settings-Pattern, das seitdem fast überall genutzt wird und viel Erleichterung bringt.
• Welche Tipps zum Umgang mit wachsender Komplexität hast du?
  • Alle obigen Maßnahmen zahlen darauf ein, Komplexität zu vermeiden.
  • Komplexität ist eine große Gefahr bei großer Software. Sie wird schnell zu groß, die Entwicklung dauert dann länger und macht keinen Spaß mehr.
  • Unser Mantra ist: Keine unnötige Komplexität! Das gesamte Team muss Komplexität richtig hassen, auch im Kleinen, da sie schnell wachsen kann.
  • Beispiel: Schon ein ungünstiger Variablenname zählt dazu, lässt sich aber leicht beheben.
  • Diese Idee muss man tief im Prozess und im Team verankern.
  • Jede Erweiterung der Software führt zu mehr Komplexität.
  • Aussagekräftige Namen sind ein großer Hebel gegen unnötige Komplexität, denn sonst kann es zu aufwändigen Umbenennungen kommen.
• Wie gehst du mit Legacy Code um, der (noch) nicht den Qualitätsanforderungen entspricht?
  • Bevor wir die Software übernommen haben, wurde viel extern entwickelt. Seit 5 Jahren entwickeln wir nun inhouse, aber es ist noch viel Code von früher übrig, der nicht den Pattern entspricht.
  • Daran wird nicht weiter entwickelt, sondern er wird in die „neue Welt“ überführt, was eigentlich immer einen Rewrite bedeutet.
  • Auch alte Anwendungen müssen sich weiterentwickeln, da die Kunden neue Anforderungen haben.
• Refactoring oder Rewrite: Worauf achtest du bei der Entscheidung?
  • Rewrites machen wir eigentlich immer für nicht selbstgeschriebenen Code. Für der Erfolg ist aber wichtig zu wissen, wie man es grundsätzlich besser machen kann.
  • „Nur“ neu machen reicht nicht aus! Das ist kein Grund für einen Rewrite.
  • Ein Mittelweg ist auch möglich: nur ein Teil des Codes zieht um, wird refaktorisiert und Konventionen/Pattern werden eingeführt.
  • Reine Refactoring-Releases werden bei uns vermieden. Es muss immer der Mehrwert für den Benutzer erkennbar sein.
  • In den letzten 5 Jahren gab es max. drei Releases mit reiner Technik.
• Haben wir noch Themen vergessen, die wir unbedingt besprechen sollten?
  • Das Team ist am wichtigsten! Nach 13 Jahren ist das eine zentrale Erkenntnis. Nur gemeinsam kommt ein gutes Ergebnis raus!

Aus- und Weiterbildung

• Bildest du selbst Entwickler-Nachwuchs aus und wenn ja, wie ist das Vorgehen?
  • Wir sind IHK-Ausbildungsbetrieb, haben aber erst einen Azubi (FIAE) komplett ausgebildet.
  • Die dauerhafte Ausbildung ist aber in Arbeit, wir sind noch in der Findungsphase.
  • Meine eigene sehr gute Ausbildung bei der Brose Group (Fahrzeugteile) in Coburg ist jetzt auch mein eigener Anspruch.
  • Wir haben eine Kooperation mit der Hochschule Nürnberg. Jedes Semester haben wir Praktikant:innen für ein Praxissemester, wovon beide Seiten profitieren!
• Hast du Tipps für Ausbilder/-innen im IT-Bereich?
  • Viel Praxis! Kurze Theoriephase, dann früh ran ans echte Produkt! Es sollen alle Prozesse mitgemacht werden, insb. Code-Reviews usw.
  • Viele Erfolgserlebnisse gerade zu Beginn sind wichtig.
  • Feedback am Ende des Praktikums ist immer gut.
• Welche Quellen kannst du für die Aus- und Weiterbildung im Bereich Programmierung empfehlen und warum?
  • Das ist bei mir ein bunter Mix, für bestimmte Themen sind aber Bücher gut geeignet.
  • Das Buch Clean Code* hat mir am meisten gebracht.
  • Ich bin auch großer Fan von Videokursen, wie z.B. Pluralsight* und Rheinwerk*.
  • Wir haben Premium-Accounts bei Pluralsight für alle Entwicker:innen. Das ist auch hilfreich für Praktikant:innen.
  • Wir haben z.B. den Bedarf aus einem konkretem Projekt an VueJS direkt über einen Kurs auf der Plattform gelöst.
  • Am besten lernt man aber wohl „am lebenden Objekt“.
  • Auch die Effizienz durch die Kurse ist besser, als wenn Kolleg:innen das alles selbst erklären.

Abschluss

• Haben wir noch etwas vergessen?
  • Wir haben aktuell nur (männliche) Entwickler in unserem Team, aber diverse Teams sind sehr wichtig!
  • Wir hätten gerne mehr Entwicklerinnen! Also nichts wie los und bewerben!
• Wo können die Hörer mehr über dich erfahren bzw. dich kontaktieren?
  • Am besten bei LinkedIn.

Literaturempfehlungen

Ein sehr empfehlenswertes Buch laut Christian ist Clean Code von Robert C. Martin*. Es ist sprachunabhängig und vermittelt viele grundlegende Techniken, um Code qualitativer zu machen.

*

Bei Pluralsight* hat sein ganzes Team Accounts. Dort kann man professionelle Videokurse zu zahlreichen Technikthemen (auf Englisch) absolvieren.

Auch beim Rheinwerk-Verlag* gibt es hervorragende Literatur und Videokurse (auf Deutsch).

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Christian Kranert bei LinkedIn
• studiolution
• Brose Group bei LinkedIn