IT-Berufe-Podcast

Stefan Macke

Der Podcast rund um die Ausbildung in den IT-Berufen (insb. Fachinformatiker für Anwendungsentwicklung) von Stefan Macke.

  1. 18. MAI

    Mündliche Ergänzungsprüfung – Erklärung, Benotung, Inhalte und Vorbereitung – IT-Berufe-Podcast #197

    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): Gesamtergebnis von Teil 1 und Teil 2 mindestens ausreichend Ergebnis von Teil 2 mindestens ausreichend In mindestens drei Prüfungsbereichen von Teil 2 mindestens ausreichend 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

    19 Min.

  2. 11. MAI

    Umgang mit Fehlern in der Projektdokumentation in der Projektpräsentation – IT-Berufe-Podcast-Shorts #12

    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

    13 Min.

  3. 4. MAI

    Sinnvolle Prüfungsvorbereitung mit alten IHK-Prüfungen – IT-Berufe-Podcast-Shorts #11

    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: Prüfungskatalog besorgen Dort steht, welche Themen aktuell für AP1 oder AP2 in deinem Beruf relevant sind. Mit den neuesten Prüfungen anfangen Zuerst den Prüfungsteil bearbeiten, auf den du dich konkret vorbereitest. Dann chronologisch rückwärts arbeiten So lange, bis du bei den Prüfungen ab 2020 angekommen bist. Danach Prüfungstrainer nutzen Zum Beispiel die Prüfungstrainer aus dem U-Form-Verlag mit prüfungsnahen Aufgaben und Lösungen. 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 auc

    7 Min.

  4. 27. APR.

    Platzierung von Artefakten in der Projektdokumentation – IT-Berufe-Podcast-Shorts #10

    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 u

    18 Min.

  5. 20. APR.

    Sinnvolle Anzahl der Seiten der Projektdokumentation – IT-Berufe-Podcast-Shorts #9

    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 explizi

    19 Min.

  6. 13. APR.

    Stakeholder für deine IHK-Projektarbeit – IT-Berufe-Podcast-Shorts #8

    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: Stakeholder sammeln Überlege zuerst, wer Interesse an deinem Projekt haben könnte. Stakeholder gruppieren Zum Beispiel in intern und extern oder nach anderen sinnvollen Kriterien. Repräsentierende Personen auswählen Du kannst nicht mit allen sprechen, also such dir passende Ansprechpersonen oder Rollen aus, etwa Key-User:innen. Anforderungen erheben Das kann oft einfach über Gespräche passieren. Bei Gesetzen oder Spezialthemen kannst du auch Fachpersonen wie Datenschutz- oder Sicherheitsbeauftragte einbeziehen. Anforderungen dokumentieren und priorisieren Schreib die Anforderungen auf, formuliere sie einheitlich und priorisiere sie. Daraus kann zum Beispiel ein Lastenheft entstehen. 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 i

    24 Min.

  7. 6. APR.

    Eh-Da-Kosten und laufende Kosten bei der Projektarbeit – IT-Berufe-Podcast-Shorts #7

    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: Erstelle zuerst eine Liste aller genutzten Ressourcen. Prüfe dann, welche Kosten dafür im Unternehmen angesetzt werden. Nutze möglichst Pauschalen, Stundensätze oder Gemeinkosten statt eigener Detailrechnungen. Berücksichtige sowohl einmalige als auch laufende Kosten. Lege gemeinsam genutzte Ressourcen bei Bedarf anteilig auf dein Projekt um. 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. Oppo

    17 Min.

  8. 30. MÄRZ

    Darstellung von Code in Projektdokumentation und Projektpräsentation – IT-Berufe-Podcast-Shorts #6

    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: 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. 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. 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

    23 Min.
Alle anzeigen (224)

Bewertungen und Rezensionen

5
von 5
3 Bewertungen

Info

Der Podcast rund um die Ausbildung in den IT-Berufen (insb. Fachinformatiker für Anwendungsentwicklung) von Stefan Macke.

Informationen

  • Erstellt von
    Stefan Macke
  • Jahre aktiv
    2015 - 2026
  • Folgen
    224
  • Bewertung
    Unbedenklich
  • Copyright
    © Stefan Macke
  • Sendungswebsite
    IT-Berufe-Podcast

Das gefällt dir vielleicht auch