IT-Berufe-Podcast

💼 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 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 ge...

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,

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.

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.

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,

Ü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

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,

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!?

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

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

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

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,

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.

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! :-D 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?

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.

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

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

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.